From joelja@bogus.com Sun Sep 2 10:14:42 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3932021F84C9 for ; Sun, 2 Sep 2012 10:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.021 X-Spam-Level: X-Spam-Status: No, score=-102.021 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4O5W3-ANt9nk for ; Sun, 2 Sep 2012 10:14:41 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 5C16E21F84CE for ; Sun, 2 Sep 2012 10:14:41 -0700 (PDT) Received: from joels-MacBook-Air.local (52.sub-166-250-71.myvzw.com [166.250.71.52]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q82HDwtA000910 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sun, 2 Sep 2012 17:14:31 GMT (envelope-from joelja@bogus.com) Message-ID: <504392E0.8070802@bogus.com> Date: Sun, 02 Sep 2012 10:09:52 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120821 Thunderbird/15.0 MIME-Version: 1.0 To: "Fred Baker (fred)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sun, 02 Sep 2012 17:14:39 +0000 (UTC) Cc: v6ops WG Subject: [v6ops] Reminder: draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2012 17:14:42 -0000 Reminder, this WGLC runs through the 5th of September. On 8/21/12 8:45 AM, Fred Baker (fred) wrote: > This is to open a two week Working Group last Call on > > http://tools.ietf.org/html/draft-ietf-v6ops-464xlat > "464XLAT: Combination of Stateful and Stateless Translation", Masataka > Mawatari, Masanobu Kawashima, Cameron Byrne, 19-Aug-12 > > Please read it now. We are interested in, among other things, technical commentary on the draft and the working group's perception on its usefulness to its target audience. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From joelja@bogus.com Sun Sep 2 10:23:57 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81BFC21F84E4 for ; Sun, 2 Sep 2012 10:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.389 X-Spam-Level: X-Spam-Status: No, score=-101.389 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_20=-0.74, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZoS3sqg8EnOa for ; Sun, 2 Sep 2012 10:23:56 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id DEF2921F84C5 for ; Sun, 2 Sep 2012 10:23:56 -0700 (PDT) Received: from joels-MacBook-Air.local (52.sub-166-250-71.myvzw.com [166.250.71.52]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q82HNJcY000962 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sun, 2 Sep 2012 17:23:31 GMT (envelope-from joelja@bogus.com) Message-ID: <504395FE.70201@bogus.com> Date: Sun, 02 Sep 2012 10:23:10 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120821 Thunderbird/15.0 MIME-Version: 1.0 To: "Hemant Singh (shemant)" References: <75B6FA9F576969419E42BECB86CB1B89077DE7@xmb-rcd-x06.cisco.com> In-Reply-To: <75B6FA9F576969419E42BECB86CB1B89077DE7@xmb-rcd-x06.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sun, 02 Sep 2012 17:23:35 +0000 (UTC) Cc: Ray Hunter , "v6ops@ietf.org" Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2012 17:23:57 -0000 On 8/26/12 4:28 PM, Hemant Singh (shemant) wrote: > As for the tethered service, I think, there are still large cellular operators in the U.S. who support the IPhone and not any tethering. So why is a hack such as the ND Proxy being pushed for tethering? Why not just add DHCPv6 PD to the UE and then the CLAT also uses a prefix from the DHCPv6 PD? This seems like any uneceesarily specific observation. at&t/t-mobile/sprint/verizon all have tethered service offerings. how they market those and to which products they apply them is not germain to the discussion of how to offer the service. From despres.remi@laposte.net Mon Sep 3 08:18:05 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B450E21F8685 for ; Mon, 3 Sep 2012 08:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.063 X-Spam-Level: X-Spam-Status: No, score=-0.063 tagged_above=-999 required=5 tests=[AWL=-1.314, BAYES_50=0.001, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zhtxuBFnYFgj for ; Mon, 3 Sep 2012 08:17:59 -0700 (PDT) Received: from smtp25.services.sfr.fr (smtp25.services.sfr.fr [93.17.128.118]) by ietfa.amsl.com (Postfix) with ESMTP id 57BF521F8578 for ; Mon, 3 Sep 2012 08:17:58 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2519.sfr.fr (SMTP Server) with ESMTP id DA591700006A; Mon, 3 Sep 2012 17:17:57 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2519.sfr.fr (SMTP Server) with ESMTP id 8870E7000069; Mon, 3 Sep 2012 17:17:57 +0200 (CEST) X-SFR-UUID: 20120903151757558.8870E7000069@msfrf2519.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <504392E0.8070802@bogus.com> Date: Mon, 3 Sep 2012 17:17:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <448050D4-84F9-4F52-BF7E-347EA451A96C@laposte.net> References: <504392E0.8070802@bogus.com> To: joel jaeggli X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] Reminder: draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 15:18:07 -0000 2012-09-02 19:09, joel jaeggli : > Reminder, this WGLC runs through the 5th of September. Thanks for the reminder. If the WGLC is, like an IESG last call, "to make sure that no important = concerns have been missed or misunderstood" (RFC 2418), I think we = aren't quite at this stage yet. The current discussions on ND proxy and/or IANA-reserved IIDs is still = progressing, but AFAIK without clear conclusion. What is the normal procedure then is unclear to me, but trying to = quickly reach common WG understanding on this subject would certainly = make sense. Regards, RD >=20 > On 8/21/12 8:45 AM, Fred Baker (fred) wrote: >> This is to open a two week Working Group last Call on >>=20 >> http://tools.ietf.org/html/draft-ietf-v6ops-464xlat >> "464XLAT: Combination of Stateful and Stateless Translation", = Masataka >> Mawatari, Masanobu Kawashima, Cameron Byrne, 19-Aug-12 >>=20 >> Please read it now. We are interested in, among other things, = technical commentary on the draft and the working group's perception on = its usefulness to its target audience. >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From joelja@bogus.com Mon Sep 3 09:37:44 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C641E21F8648 for ; Mon, 3 Sep 2012 09:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.81 X-Spam-Level: X-Spam-Status: No, score=-101.81 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qqkqlZUpjR7W for ; Mon, 3 Sep 2012 09:37:44 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 3E4FF21F8647 for ; Mon, 3 Sep 2012 09:37:44 -0700 (PDT) Received: from joels-MacBook-Air.local (81.sub-166-250-68.myvzw.com [166.250.68.81]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q83GbdFC009295 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Mon, 3 Sep 2012 16:37:41 GMT (envelope-from joelja@bogus.com) Message-ID: <5044DCCF.1000609@bogus.com> Date: Mon, 03 Sep 2012 09:37:35 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120821 Thunderbird/15.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= References: <504392E0.8070802@bogus.com> <448050D4-84F9-4F52-BF7E-347EA451A96C@laposte.net> In-Reply-To: <448050D4-84F9-4F52-BF7E-347EA451A96C@laposte.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Mon, 03 Sep 2012 16:37:42 +0000 (UTC) Cc: v6ops WG Subject: Re: [v6ops] Reminder: draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 16:37:44 -0000 On 9/3/12 8:17 AM, Rémi Després wrote: > 2012-09-02 19:09, joel jaeggli : > >> Reminder, this WGLC runs through the 5th of September. > Thanks for the reminder. > > If the WGLC is, like an IESG last call, "to make sure that no important concerns have been missed or misunderstood" (RFC 2418), I think we aren't quite at this stage yet. > The current discussions on ND proxy and/or IANA-reserved IIDs is still progressing, but AFAIK without clear conclusion. It is not your job to determine what to do with the results. > > What is the normal procedure then is unclear to me, but trying to quickly reach common WG understanding on this subject would certainly make sense. > > Regards, > RD > > > >> On 8/21/12 8:45 AM, Fred Baker (fred) wrote: >>> This is to open a two week Working Group last Call on >>> >>> http://tools.ietf.org/html/draft-ietf-v6ops-464xlat >>> "464XLAT: Combination of Stateful and Stateless Translation", Masataka >>> Mawatari, Masanobu Kawashima, Cameron Byrne, 19-Aug-12 >>> >>> Please read it now. We are interested in, among other things, technical commentary on the draft and the working group's perception on its usefulness to its target audience. >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops From despres.remi@laposte.net Mon Sep 3 13:15:49 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA67721F8592; Mon, 3 Sep 2012 13:15:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.041 X-Spam-Level: X-Spam-Status: No, score=-0.041 tagged_above=-999 required=5 tests=[AWL=-1.292, BAYES_50=0.001, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y02hUWZ0LlrQ; Mon, 3 Sep 2012 13:15:49 -0700 (PDT) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.19]) by ietfa.amsl.com (Postfix) with ESMTP id 0959F21F8551; Mon, 3 Sep 2012 13:15:48 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2319.sfr.fr (SMTP Server) with ESMTP id 8435370000A9; Mon, 3 Sep 2012 22:15:47 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2319.sfr.fr (SMTP Server) with ESMTP id 17DC6700008A; Mon, 3 Sep 2012 22:15:46 +0200 (CEST) X-SFR-UUID: 20120903201547978.17DC6700008A@msfrf2319.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: <5044DCCF.1000609@bogus.com> Date: Mon, 3 Sep 2012 22:15:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <34ADB3AF-5C26-4690-8774-F36745660767@laposte.net> References: <504392E0.8070802@bogus.com> <448050D4-84F9-4F52-BF7E-347EA451A96C@laposte.net> <5044DCCF.1000609@bogus.com> To: joel jaeggli X-Mailer: Apple Mail (2.1084) Cc: v6ops WG , IESG Subject: Re: [v6ops] Reminder: draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 20:15:50 -0000 2012-09-03 18:37, joel jaeggli: > On 9/3/12 8:17 AM, R=E9mi Despr=E9s wrote: >> 2012-09-02 19:09, joel jaeggli : >>=20 >>> Reminder, this WGLC runs through the 5th of September. >> Thanks for the reminder. >>=20 >> If the WGLC is, like an IESG last call, "to make sure that no = important concerns have been missed or misunderstood" (RFC 2418), I = think we aren't quite at this stage yet. >> The current discussions on ND proxy and/or IANA-reserved IIDs is = still progressing, but AFAIK without clear conclusion. > It is not your job to determine what to do with the results. Didn't claim it was my job! My responsibility is limited to sharing important facts I know to be = true (or believe to be true).=20 What the chairs do with them is undoubtedly their responsibility. Provided IESG members can make their decisions with enough understanding = of debated issues, there is no problem. Regards, RD >>=20 >> What is the normal procedure then is unclear to me, but trying to = quickly reach common WG understanding on this subject would certainly = make sense. >>=20 >> Regards, >> RD >>=20 >>=20 >>=20 >>> On 8/21/12 8:45 AM, Fred Baker (fred) wrote: >>>> This is to open a two week Working Group last Call on >>>>=20 >>>> http://tools.ietf.org/html/draft-ietf-v6ops-464xlat >>>> "464XLAT: Combination of Stateful and Stateless Translation", = Masataka >>>> Mawatari, Masanobu Kawashima, Cameron Byrne, 19-Aug-12 >>>>=20 >>>> Please read it now. We are interested in, among other things, = technical commentary on the draft and the working group's perception on = its usefulness to its target audience. >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>=20 >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >=20 From ietfc@btconnect.com Tue Sep 4 02:07:59 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB7C421F84F9 for ; Tue, 4 Sep 2012 02:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GFHvAiZi4NJr for ; Tue, 4 Sep 2012 02:07:59 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id 25AD421F8466 for ; Tue, 4 Sep 2012 02:07:58 -0700 (PDT) Received: from mail226-tx2-R.bigfish.com (10.9.14.247) by TX2EHSOBE008.bigfish.com (10.9.40.28) with Microsoft SMTP Server id 14.1.225.23; Tue, 4 Sep 2012 09:07:56 +0000 Received: from mail226-tx2 (localhost [127.0.0.1]) by mail226-tx2-R.bigfish.com (Postfix) with ESMTP id B195124007E; Tue, 4 Sep 2012 09:07:56 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.224.141; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0702HT010.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -28 X-BigFish: PS-28(z4c5Izbb2dI98dI9371Ic89bh936eI542M1432I1447Izz1202hzz8275ch1033IL8275bh8275dhz2dh2a8h5a9h668h839hd24hf0ah107ah1177h1179h304l1155h) Received: from mail226-tx2 (localhost.localdomain [127.0.0.1]) by mail226-tx2 (MessageSwitch) id 134674967457814_4858; Tue, 4 Sep 2012 09:07:54 +0000 (UTC) Received: from TX2EHSMHS020.bigfish.com (unknown [10.9.14.248]) by mail226-tx2.bigfish.com (Postfix) with ESMTP id 0106894004A; Tue, 4 Sep 2012 09:07:53 +0000 (UTC) Received: from DB3PRD0702HT010.eurprd07.prod.outlook.com (157.55.224.141) by TX2EHSMHS020.bigfish.com (10.9.99.120) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 4 Sep 2012 09:07:52 +0000 Received: from AMSPRD0610HT001.eurprd06.prod.outlook.com (157.56.248.85) by pod51017.outlook.com (10.3.4.178) with Microsoft SMTP Server (TLS) id 14.15.108.4; Tue, 4 Sep 2012 09:07:45 +0000 Message-ID: <015601cd8a7c$0b905ac0$4001a8c0@gateway.2wire.net> From: t.petch To: joel jaeggli , =?iso-8859-1?Q?R=E9mi_Despr=E9s?= References: <504392E0.8070802@bogus.com><448050D4-84F9-4F52-BF7E-347EA451A96C@laposte.net> <5044DCCF.1000609@bogus.com> Date: Tue, 4 Sep 2012 10:02:32 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.248.85] Content-Transfer-Encoding: quoted-printable X-OriginatorOrg: btconnect.com Cc: v6ops WG Subject: Re: [v6ops] Reminder: draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 09:08:00 -0000 ----- Original Message ----- From: "joel jaeggli" To: "R=E9mi Despr=E9s" Cc: "v6ops WG" Sent: Monday, September 03, 2012 5:37 PM On 9/3/12 8:17 AM, R=E9mi Despr=E9s wrote: > 2012-09-02 19:09, joel jaeggli : > >> Reminder, this WGLC runs through the 5th of September. > Thanks for the reminder. > > If the WGLC is, like an IESG last call, "to make sure that no important concerns have been missed or misunderstood" (RFC 2418), I think we aren't quite at this stage yet. > The current discussions on ND proxy and/or IANA-reserved IIDs is still progressing, but AFAIK without clear conclusion. It is not your job to determine what to do with the results. Very true, for me as for Remi, but it does affect my views. Prior to the WGLC, the document looked ok, from the perspective of my predominantly 'wired' background. The extensive (intensive?) list discussion of technical matters seems to me to say that there are unresolved issues, that the I-D does not define well enough the environment into which it is going to slot (e.g. tethering, DHCPv6-PD). Hence it should not progress just yet. Trouble is, in coming to this conclusion, I am, inevitably, making my own rough consensus call on that list discussion, which I have to do without knowing what the official consensus call will later be. Tom Petch > What is the normal procedure then is unclear to me, but trying to quickly reach common WG understanding on this subject would certainly make sense. > > Regards, > RD > > > >> On 8/21/12 8:45 AM, Fred Baker (fred) wrote: >>> This is to open a two week Working Group last Call on >>> >>> http://tools.ietf.org/html/draft-ietf-v6ops-464xlat >>> "464XLAT: Combination of Stateful and Stateless Translation", Masataka >>> Mawatari, Masanobu Kawashima, Cameron Byrne, 19-Aug-12 >>> >>> Please read it now. We are interested in, among other things, technical commentary on the draft and the working group's perception on its usefulness to its target audience. >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From Carl.Wuyts@technicolor.com Tue Sep 4 06:46:18 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83DF921F84FC for ; Tue, 4 Sep 2012 06:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.56 X-Spam-Level: X-Spam-Status: No, score=-5.56 tagged_above=-999 required=5 tests=[AWL=1.038, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k20HuXf3jGUr for ; Tue, 4 Sep 2012 06:46:16 -0700 (PDT) Received: from na3sys009aog104.obsmtp.com (na3sys009aog104.obsmtp.com [74.125.149.73]) by ietfa.amsl.com (Postfix) with ESMTP id 4452521F84F8 for ; Tue, 4 Sep 2012 06:46:13 -0700 (PDT) Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob104.postini.com ([74.125.148.12]) with SMTP ID DSNKUEYGH5efaWSa/f0ikwQ1DctpIKktoABN@postini.com; Tue, 04 Sep 2012 06:46:16 PDT Received: from MOPESMAILHC02.eu.thmulti.com (141.11.100.29) by mail3.technicolor.com (141.11.253.22) with Microsoft SMTP Server (TLS) id 8.3.264.0; Tue, 4 Sep 2012 15:44:42 +0200 Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.14]) by MOPESMAILHC02.eu.thmulti.com ([141.11.100.29]) with mapi; Tue, 4 Sep 2012 15:44:45 +0200 From: Wuyts Carl To: "STARK, BARBARA H" , Ted Lemon , "Bernie Volz (volz)" Date: Tue, 4 Sep 2012 15:44:43 +0200 Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-10.txt Thread-Index: AQHNe8thBbFPT8Jz20arHpsDPdcX0pdc6sMAgAADxYD//8RvEIAdm4oA Message-ID: <867F4B6A1672E541A94676D556793ACD16E4E37386@MOPESMBX01.eu.thmulti.com> References: <20BACF78-57F2-4455-A0A5-F15822DB2015@nominum.com> <489D13FBFA9B3E41812EA89F188F018E0F4ECD56@xmb-rcd-x04.cisco.com> <9E042EC6-07B9-4F7C-A50B-6A9F01BCD668@nominum.com> <2D09D61DDFA73D4C884805CC7865E61116AD97@GAALPA1MSGUSR9N.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61116AD97@GAALPA1MSGUSR9N.ITServices.sbc.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_867F4B6A1672E541A94676D556793ACD16E4E37386MOPESMBX01eut_" MIME-Version: 1.0 Cc: Operations Operations Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-10.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 13:46:18 -0000 --_000_867F4B6A1672E541A94676D556793ACD16E4E37386MOPESMBX01eut_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 on Barbara's statement. 1. It isn't broken 2. Let's not (again) add extra requirements for the CPE to keep track= of the dhcp status on power outages or power down, keep it simple please Tx and regs Carl From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of S= TARK, BARBARA H Sent: donderdag 16 augustus 2012 19:50 To: Ted Lemon; Bernie Volz (volz) Cc: Operations Operations Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-10.txt Service providers have been dealing with "simultaneous" mass repowering of = routers for a long time. There currently exist requirements for multiple re= tries of all necessary protocols, at random intervals (within reasonable li= mits). I believe that all requirements necessary for such staggered retries= are in place, and are sufficient for dealing with mass coming-on-line. I a= lso believe that maintaining DHCP configuration across reboots is undesirab= le. If we were to say anything, I would prefer to forbid it, rather than ma= ndate it. But, I don't think we need to be saying anything at all, because,= thankfully, I'm not aware of devices that maintain DHCP config across rebo= ots. I don't believe that the scenario of mass power outage that takes out massi= ve quantities of CE routers + the DHCP server, but that leaves all other ac= cess network elements intact is a probable scenario. As such, I don't think= it's worthy of a requirement. It ain't broke. Please, let's not "fix" it. Barbara From: v6ops-bounces@ietf.org [mailto:v6ops-b= ounces@ietf.org] On Behalf Of Ted Lemon Sent: Thursday, August 16, 2012 1:07 PM To: Bernie Volz (volz) Cc: Operations Operations Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-10.txt On Aug 16, 2012, at 12:53 PM, Bernie Volz (volz) wrote: If this were to include power failures, how would the CPE know how much tim= e has elapsed while it was down which could cause more significant issues b= ecause of the lease time -- and having to maintain a clock via battery back= up is probably not a good idea. I'm specifically referring to power outages. If the CPE doesn't get a res= ponse from a Confirm, doesn't it get to use the address? The question abo= ut the clock is interesting, but it seems like a safe assumption that a pow= er cycle is short; if it's long, and wasn't the result of a power outage, t= he Confirm transaction will prevent anything bad from happening. --_000_867F4B6A1672E541A94676D556793ACD16E4E37386MOPESMBX01eut_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1 on Bar= bara’s statement.

1.       It isn’t broken

2.       <= ![endif]>Let’s not (again) add extra requirements for the CPE = to keep track of the dhcp status on power outages or power down, keep it si= mple please

 

Tx and regs

=

Carl

 

<= o:p> 

From: v6ops-bou= nces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of STARK, BA= RBARA H
Sent: donderdag 16 augustus 2012 19:50
To: Ted = Lemon; Bernie Volz (volz)
Cc: Operations Operations
Subject= : Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-10.txt

 

Service providers have been dealing with “simultaneous” mass r= epowering of routers for a long time. There currently exist requirements fo= r multiple retries of all necessary protocols, at random intervals (within = reasonable limits). I believe that all requirements necessary for such stag= gered retries are in place, and are sufficient for dealing with mass coming= -on-line. I also believe that maintaining DHCP configuration across reboots= is undesirable. If we were to say anything, I would prefer to forbid it, r= ather than mandate it. But, I don’t think we need to be saying anythi= ng at all, because, thankfully, I’m not aware of devices that maintai= n DHCP config across reboots.

 = ;

I don’t believe that the scenario of = mass power outage that takes out massive quantities of CE routers + the DHC= P server, but that leaves all other access network elements intact is a pro= bable scenario. As such, I don’t think it’s worthy of a require= ment.

 

It ain’t broke. Please, let’s not “fix” it.=

Barbara

 

From: v6ops-bounces@= ietf.org [mailto:v6ops-bounce= s@ietf.org] On Behalf Of Ted Lemon
Sent: Thursday, Aug= ust 16, 2012 1:07 PM
To: Bernie Volz (volz)
Cc: Operati= ons Operations
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-= 6204bis-10.txt

&= nbsp;

On Aug 16, 2012, at 12:53 PM,= Bernie Volz (volz) wrote:

If this were to include power failures, how would the CPE know how much = time has elapsed while it was down which could cause more significant issue= s because of the lease time -- and having to maintain a clock via battery b= ackup is probably not a good idea.

 

= I'm specifically referring to power outages.   If the CPE doesn't get = a response from a Confirm, doesn't it get to use the address?   The qu= estion about the clock is interesting, but it seems like a safe assumption = that a power cycle is short; if it's long, and wasn't the result of a power= outage, the Confirm transaction will prevent anything bad from happening.<= o:p>

 

= --_000_867F4B6A1672E541A94676D556793ACD16E4E37386MOPESMBX01eut_-- From Ted.Lemon@nominum.com Tue Sep 4 06:59:42 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4349F21F852A for ; Tue, 4 Sep 2012 06:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.298 X-Spam-Level: X-Spam-Status: No, score=-106.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gnC5s6nd7uo1 for ; Tue, 4 Sep 2012 06:59:41 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 8D4B221F850C for ; Tue, 4 Sep 2012 06:59:41 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKUEYJTRNBDX9bDKBS4wvsoZfLCjz82RGp@postini.com; Tue, 04 Sep 2012 06:59:41 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 45ACA1B8052 for ; Tue, 4 Sep 2012 06:59:40 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 3B85719005C; Tue, 4 Sep 2012 06:59:40 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Tue, 4 Sep 2012 06:59:41 -0700 From: Ted Lemon To: t.petch Thread-Topic: [v6ops] Reminder: draft-ietf-v6ops-464xlat WGLC Thread-Index: AQHNinwEADwY8/kMB0ykw3t0El8NX5d6q24A Date: Tue, 4 Sep 2012 13:59:39 +0000 Message-ID: References: <504392E0.8070802@bogus.com><448050D4-84F9-4F52-BF7E-347EA451A96C@laposte.net> <5044DCCF.1000609@bogus.com> <015601cd8a7c$0b905ac0$4001a8c0@gateway.2wire.net> In-Reply-To: <015601cd8a7c$0b905ac0$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_FF5EDA56621C4A9181FDD0A2E7EABA2Dnominumcom_" MIME-Version: 1.0 Cc: v6ops WG Subject: Re: [v6ops] Reminder: draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 13:59:42 -0000 --_000_FF5EDA56621C4A9181FDD0A2E7EABA2Dnominumcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Sep 4, 2012, at 5:02 AM, t.petch > wrote: Trouble is, in coming to this conclusion, I am, inevitably, making my own rough consensus call on that list discussion, which I have to do without knowing what the official consensus call will later be. Normally, if you are aware of problems with the document, or think it's a b= ad solution, you say so on the mailing list. You do not try to gauge cons= ensus=97you participate in the discussion, and by so doing, improve the doc= ument. That's how we get better documents! --_000_FF5EDA56621C4A9181FDD0A2E7EABA2Dnominumcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
On Sep 4, 2012, at 5:02 AM, t.petch <ietfc@btconnect.com> wrote:
Trouble is, in coming to this conclusion, I am, inevitably, making my
own rough consensus call on that list discussion, which I have to do without knowing what the official consensus call will later be.

Normally, if you are aware of problems with the document, or think it'= s a bad solution, you say so on the mailing list.   You do not try to = gauge consensus=97you participate in the discussion, and by so doing, impro= ve the document.   That's how we get better documents!

--_000_FF5EDA56621C4A9181FDD0A2E7EABA2Dnominumcom_-- From ietfc@btconnect.com Tue Sep 4 10:42:13 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA61121F86C2 for ; Tue, 4 Sep 2012 10:42:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.049 X-Spam-Level: X-Spam-Status: No, score=-3.049 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hv7Pw5O4O+5D for ; Tue, 4 Sep 2012 10:42:13 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe006.messaging.microsoft.com [213.199.154.209]) by ietfa.amsl.com (Postfix) with ESMTP id E17C921F86BE for ; Tue, 4 Sep 2012 10:42:12 -0700 (PDT) Received: from mail59-am1-R.bigfish.com (10.3.201.254) by AM1EHSOBE005.bigfish.com (10.3.204.25) with Microsoft SMTP Server id 14.1.225.23; Tue, 4 Sep 2012 17:42:05 +0000 Received: from mail59-am1 (localhost [127.0.0.1]) by mail59-am1-R.bigfish.com (Postfix) with ESMTP id 344B5200C1; Tue, 4 Sep 2012 17:42:05 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.224.141; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0702HT003.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: PS-25(z4c5Iz98dI9371Ic89bh542M1418Izz1202hzz8275ch1033IL8275bh8275dhz2dh2a8h5a9h668h839h946hd24hf0ah107ah1177h1179h304l1155h) Received: from mail59-am1 (localhost.localdomain [127.0.0.1]) by mail59-am1 (MessageSwitch) id 1346780523535303_1548; Tue, 4 Sep 2012 17:42:03 +0000 (UTC) Received: from AM1EHSMHS005.bigfish.com (unknown [10.3.201.230]) by mail59-am1.bigfish.com (Postfix) with ESMTP id 8069F240019; Tue, 4 Sep 2012 17:42:03 +0000 (UTC) Received: from DB3PRD0702HT003.eurprd07.prod.outlook.com (157.55.224.141) by AM1EHSMHS005.bigfish.com (10.3.207.105) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 4 Sep 2012 17:41:51 +0000 Received: from BY2PRD0710HT002.namprd07.prod.outlook.com (157.56.236.133) by pod51017.outlook.com (10.3.4.151) with Microsoft SMTP Server (TLS) id 14.15.108.4; Tue, 4 Sep 2012 17:41:49 +0000 Message-ID: <007c01cd8ac3$dc20b800$4001a8c0@gateway.2wire.net> From: t.petch To: Ted Lemon References: <504392E0.8070802@bogus.com><448050D4-84F9-4F52-BF7E-347EA451A96C@laposte.net> <5044DCCF.1000609@bogus.com> <015601cd8a7c$0b905ac0$4001a8c0@gateway.2wire.net> Date: Tue, 4 Sep 2012 18:36:36 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.236.133] Content-Transfer-Encoding: quoted-printable X-OriginatorOrg: btconnect.com Cc: v6ops WG Subject: Re: [v6ops] Reminder: draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 17:42:14 -0000 ---- Original Message ----- From: "Ted Lemon" To: "t.petch" Cc: "joel jaeggli" ; "R=E9mi Despr=E9s" ; "v6ops WG" Sent: Tuesday, September 04, 2012 2:59 PM On Sep 4, 2012, at 5:02 AM, t.petch wrote: Trouble is, in coming to this conclusion, I am, inevitably, making my own rough consensus call on that list discussion, which I have to do without knowing what the official consensus call will later be. Normally, if you are aware of problems with the document, or think it's a bad solution, you say so on the mailing list. You do not try to gauge consensus=97you participate in the discussion, and by so doing, improve the document. That's how we get better documents! I have already said, in response to Joel's question, that I think that the document should not go forward as is; rephrasing that statement, I am saying that there are problems with the document. Initially, I thought that the solution looked good but as more has come to light (e.g. about tethering, Proxy ND, DHCP-PD), the solution seems lacking, that there are unresolved issues that need to be resolved and I would expect this to be obvious to most of those who have followed the discussion; if it isn't, then simply restating what has been said here already is not going to change things. I do not have any more problems to add. So, based on the obvious, I think that this I-D is not yet ready to progress. Yes, that is a judgement call, but then so is is everyone else's view of whether or not this I-D should proceed which is the point at question. Some of it is based on engineering, some of it is not; that's life! Tom Petch From v6ops@globis.net Tue Sep 4 22:24:55 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D769121F866B for ; Tue, 4 Sep 2012 22:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5B+AqR4pPpj7 for ; Tue, 4 Sep 2012 22:24:55 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 166E521F85A8 for ; Tue, 4 Sep 2012 22:24:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 749EE8700AB; Wed, 5 Sep 2012 07:24:38 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qVqHqpKms+Mi; Wed, 5 Sep 2012 07:24:09 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id E86B2870061; Wed, 5 Sep 2012 07:24:08 +0200 (CEST) Message-ID: <5046E1F2.4010702@globis.net> Date: Wed, 05 Sep 2012 07:24:02 +0200 From: Ray Hunter User-Agent: Postbox 3.0.4 (Macintosh/20120616) MIME-Version: 1.0 To: joel jaeggli References: <504392E0.8070802@bogus.com> In-Reply-To: <504392E0.8070802@bogus.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops WG Subject: Re: [v6ops] Reminder: draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 05:24:55 -0000 I have read this draft and lurked the on-list discussion. Comments based on version 07 http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-07 Following all IMVVHO [I'm no XLAT expert] 1) The need for 464XLAT is clear. 2) The basic 464xlat architecture is sound and certainly worthy of advancement and further refinement. The authors have done a great job on what is a very tricky problem. 3) Inclusion of ND Proxy [RFC4389] is problematic for 2 reasons: Firstly ND Proxy is an experimental protocol, whereas the draft is aiming to become BCP. Secondly, ND Proxy has inadequate loop detection, prevention and mitigation, for it to be reliably deployed in tethered networks consisting of multiple devices. If 464XLAT is going to be effective, it will need to be incorporated into CPE devices. Section 4.1.3.3 of 4389 is a potential source of oscillation, instability, unpredictable behaviour, and provides a DoS vector, if 464XLAT were to be widely incorporated into consumer devices. [Authors claim multiple device working is out of scope, but this situation will likely happen in home use) ] 4) Section 8.3.2 does not adequately deprecate single /64 working, which I consider harmful (as per BCP157). 5) Assignment of a single special-purpose IANA IID is problematic for 2 reasons. I don't consider the document complies with the spirit of justifying the Modified EUI-64 identifier via expert review (RFC5342 Section 5.1), in that the argumentation for assignment is very opaque, and the use-case is not completely defined e.g. the IID SHOULD NOT be used for L2 addressing by the CLAT. There is no detection or protection for cascaded CLATs, where if the IPv6 address is assigned using the Modified EUI-64 identifier to a downstream CLAT, this will clash with the upstream CLAT if it has also used the Modified EUI-64 identifier to create its IPv6 address. Avoiding duplicate addresses was the base justification for assigning the Modified EUI-64 identifier. [The authors say this configuration is out of scope, but this situation will likely happen in home use.] Judging by the existing discussion on the WG, I don't think any of these problems are insoluble. regards, RayH joel jaeggli wrote: > Reminder, this WGLC runs through the 5th of September. > > On 8/21/12 8:45 AM, Fred Baker (fred) wrote: >> This is to open a two week Working Group last Call on >> >> http://tools.ietf.org/html/draft-ietf-v6ops-464xlat >> "464XLAT: Combination of Stateful and Stateless Translation", >> Masataka >> Mawatari, Masanobu Kawashima, Cameron Byrne, 19-Aug-12 >> >> Please read it now. We are interested in, among other things, >> technical commentary on the draft and the working group's perception >> on its usefulness to its target audience. >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > > From lorenzo@google.com Wed Sep 5 00:26:20 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DDB621F84F5 for ; Wed, 5 Sep 2012 00:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.975 X-Spam-Level: X-Spam-Status: No, score=-102.975 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aBt1vf5ZU2Xq for ; Wed, 5 Sep 2012 00:26:19 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 92A3E21F84F1 for ; Wed, 5 Sep 2012 00:26:19 -0700 (PDT) Received: by ieak13 with SMTP id k13so543600iea.31 for ; Wed, 05 Sep 2012 00:26:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=SrbPZ13JMqBIPLl0iqeesjKShh140c/0DAtmV8h04ZA=; b=VteJMAUl69JiIgylFXOgRSbcnF3nOrbRuybccvMLS4aA0gRopMpdno4GCT5loyGQyN X2o6QFnpd2NFupb9fHaqVO7xhBUiWmO/fyJVLkWr5I6qKdBcGRmv1fAyvO+bv4VymaLI Cv9kkKozSI18MpI46DZ8MtA+fkJJWjaklV6ivX3ULFszHWeQ7lKEzccwZWqVfAOZGCqp aOaR0CN8qMUBugvf12M7F0BcQiLlxnRqCbqKbs7G30jzR/6N9aHt7UW/XNM9h5ix7vca /OnhA/CWqM4kcVG2soSOUyRmgTMHcxjnEN1QnkftwlviVW/vUMeZpYRbbYely+E0pDsH lCxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=SrbPZ13JMqBIPLl0iqeesjKShh140c/0DAtmV8h04ZA=; b=Dfl6BMxIhwak+pSU1kKwiBF1D44KQhJXFzLpl9w6PLCUdsJj2w8+fCWHOmdW+IB900 /fPWhA4psfllJVzI3T9ZTCUoQnF5Eo86N64HPb4T6MIgF3joX+m1DdYzKCSoo2kFqd+4 tZOD7r2J5cqGl5cU5SSSTyAy+IEwqO6vQYFzPFhANaEYZxG9x0Ajlk9IANy/U2COOC+0 hhftiNzoXDv8UX3SQ00sGvhY57KpDNDd6uRMVdFR5cSApm8AuC9EH2J7vAm+9EMSevd1 X7EMB2JWkD1yr6NnRD7fdL/9sw2AORSnly/NibVXtbnhQi88oOObSUlx9JCnKJ96nPoY DkqQ== Received: by 10.60.170.229 with SMTP id ap5mr16533758oec.101.1346829978930; Wed, 05 Sep 2012 00:26:18 -0700 (PDT) Received: by 10.60.170.229 with SMTP id ap5mr16533751oec.101.1346829978754; Wed, 05 Sep 2012 00:26:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.187.8 with HTTP; Wed, 5 Sep 2012 00:25:57 -0700 (PDT) In-Reply-To: <5046E1F2.4010702@globis.net> References: <504392E0.8070802@bogus.com> <5046E1F2.4010702@globis.net> From: Lorenzo Colitti Date: Wed, 5 Sep 2012 16:25:57 +0900 Message-ID: To: Ray Hunter Content-Type: multipart/alternative; boundary=bcaec54b4ac074dec804c8ef4a10 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkZ8jIT7r6jWX8q6SeNsfs6ZfQVa+APvaI96zzA4dUwdd+zxlD2qVEwdrpkJ9lPeh8/U17fhwQs8XHvewStHq3hfYN4fzs7soLvVGl0jc/tKJo0BrnTyiYjYbncky058p7K9C44C9Ex+PZcEvnhRDpWXnJ7iatNioiL76IvUtgjaoSq+l4mekIGJn9aiUelgcOnDgdo Cc: v6ops WG Subject: Re: [v6ops] Reminder: draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 07:26:20 -0000 --bcaec54b4ac074dec804c8ef4a10 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Sep 5, 2012 at 2:24 PM, Ray Hunter wrote: > 3) Inclusion of ND Proxy [RFC4389] is problematic for 2 reasons: > [...] > Agreed. ND proxy is experimental, has problems, and isn't needed for the use case that the draft cites it for. It should be removed from the draft. > 4) Section 8.3.2 does not adequately deprecate single /64 working, which I > consider harmful (as per BCP157). > I disagree that it's harmful; actually, I think it's very useful. It allows a phone to offer IPv6 tethering without the carrier having to roll out a release 10 network (and having to implement separate provisioning / billing etc. for tethering). I agree that DHCPv6 PD is better, but in 3GPP networks that's years away. To understand why, consider that that most advanced carriers are just now rolling out LTE networks, and LTE is release 8. That said, sharing a /64 is likely to happen whatever we do. So we have three options: 1. Say that /64 sharing shouldn't be done and watch as it happens anyway 2. Say that if the CLAT wants to share the connection, it SHOULD use DHCPv6 PD, but if that's not available, then the CLAT MAY share a /64 (and potentially say how). 3. Remain silent and punt to another document. 5) Assignment of a single special-purpose IANA IID is problematic for 2 > reasons. > > I don't consider the document complies with the spirit of justifying the > Modified EUI-64 identifier via expert review (RFC5342 Section 5.1), in that > the argumentation for assignment is very opaque, and the use-case is not > completely defined e.g. the IID SHOULD NOT be used for L2 addressing by the > CLAT. > > There is no detection or protection for cascaded CLATs, where if the IPv6 > address is assigned using the Modified EUI-64 identifier to a downstream > CLAT, this will clash with the upstream CLAT if it has also used the > Modified EUI-64 identifier to create its IPv6 address. Avoiding duplicate > addresses was the base justification for assigning the Modified EUI-64 > identifier. [The authors say this configuration is out of scope, but this > situation will likely happen in home use.] > Agreed. As is, I think the reserved IID should be removed from the document. Remi's idea of allocating a /24 *block* of interface IDs and have the CLAT avoid translation by mapping 10.0.0.0/8 addresses 1:1 into this reserved black has promise, though. From a technical perspective it's a good solution, but I don't know if IANA has a) has enough space to allocate a whole /24 pr b) a process for doing so. --bcaec54b4ac074dec804c8ef4a10 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Sep 5, 2012 at 2:24 PM, Ray Hunter <v6ops@globis.net>= wrote:
3) Inclusion of ND Proxy [RFC4389] is problematic for 2 reasons:
[...]

Agreed. ND proxy is experimental, has pr= oblems, and isn't needed for the use case that the draft cites it for. = It should be removed from the draft.
=A0
4) Section 8.3.2 does not adeq= uately deprecate single /64 working, which I consider harmful (as per BCP15= 7).

I disagree that it's harmful; actually= , I think it's very useful. It allows a phone to offer IPv6 tethering w= ithout the carrier having to roll out a release 10 network (and having to i= mplement separate provisioning / billing etc. for tethering). I agree that = DHCPv6 PD is better, but in 3GPP networks that's years away. To underst= and why, consider that that most advanced carriers are just now rolling out= LTE networks, and LTE is release 8.

That said, sharing a /64 is=A0likely to happen whatever= we do. So we have three options:
  1. Say that /64 sharing sh= ouldn't be done and watch as it happens anyway
  2. Say that if the = CLAT wants to share the connection, it SHOULD use DHCPv6 PD, but if that= 9;s not available, then the CLAT MAY share a /64 (and potentially say how).=
  3. Remain silent and punt to another document.
5) Assignment of a single special-purpose IANA IID is pr= oblematic for 2 reasons.

I don't consider the document complies with the spirit of justifying th= e Modified EUI-64 identifier via expert review (RFC5342 Section 5.1), in th= at the argumentation for assignment is very opaque, and the use-case is not= completely defined e.g. the IID SHOULD NOT be used for L2 addressing by th= e CLAT.

There is no detection or protection for cascaded CLATs, where if the IPv6 a= ddress is assigned using the Modified EUI-64 identifier to a downstream CLA= T, this will clash with the upstream CLAT if it has also used the Modified = EUI-64 identifier to create its IPv6 address. Avoiding duplicate addresses = was the base justification for assigning the Modified EUI-64 identifier. [T= he authors say this configuration is out of scope, but this situation will = likely happen in home use.]

Agreed. As is, I think the reserved IID sh= ould be removed from the document.

Remi's idea= of allocating a /24 *block* of interface IDs and have the CLAT avoid trans= lation by mapping 10.0.0.0/8 addresses 1:= 1 into this reserved black has promise, though. From a technical perspectiv= e it's a good solution, but I don't know if IANA has a) has enough = space to allocate a whole /24 pr b) a process for doing so.
--bcaec54b4ac074dec804c8ef4a10-- From Carl.Wuyts@technicolor.com Wed Sep 5 00:54:19 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F79521F865C for ; Wed, 5 Sep 2012 00:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.902 X-Spam-Level: X-Spam-Status: No, score=-5.902 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ml3wF3QGea3j for ; Wed, 5 Sep 2012 00:54:18 -0700 (PDT) Received: from na3sys009aog104.obsmtp.com (na3sys009aog104.obsmtp.com [74.125.149.73]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC3B21F865B for ; Wed, 5 Sep 2012 00:54:16 -0700 (PDT) Received: from mopesedge02.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob104.postini.com ([74.125.148.12]) with SMTP ID DSNKUEcFKDdbT0AB/H9yyLMtjgOAFUCWwnna@postini.com; Wed, 05 Sep 2012 00:54:18 PDT Received: from MOPESMAILHC03.eu.thmulti.com (141.11.100.132) by mopesedge02.eu.thmulti.com (141.11.253.23) with Microsoft SMTP Server (TLS) id 8.3.264.0; Wed, 5 Sep 2012 09:52:58 +0200 Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.14]) by MOPESMAILHC03.eu.thmulti.com ([141.11.100.132]) with mapi; Wed, 5 Sep 2012 09:53:07 +0200 From: Wuyts Carl To: Marc Lampo , "v6ops@ietf.org" Date: Wed, 5 Sep 2012 09:53:05 +0200 Thread-Topic: [v6ops] RFC 6092 - RFC 6204 - ULA : query for clarification/advice Thread-Index: Ac2B6dsL+DWHinLPQqCHcy+dgZ+jYAJULhGA Message-ID: <867F4B6A1672E541A94676D556793ACD16E4E3748F@MOPESMBX01.eu.thmulti.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] RFC 6092 - RFC 6204 - ULA : query for clarification/advice X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 07:54:19 -0000 Hi Marc, I'm working in the CPE area, supporting ULA-usage. ULA indeed to be used for "internal" traffic only, this can also be traffic= over VPN within your company. I don't see why you drag NAT along, there's = no relation to NAT using ULA. I assume you make this link based upon priva= te addressing in IPv4 and its NAT appliance. A CPE typically uses a default route, hence the ULA-packet indeed will be d= ropped when destined to "the internet". There's no problem assigning ULA next to GUA address(es); this can be done = manual or just using the RTADV daemon of the CPE. Regs Carl -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of M= arc Lampo Sent: vrijdag 24 augustus 2012 13:16 To: v6ops@ietf.org Subject: [v6ops] RFC 6092 - RFC 6204 - ULA : query for clarification/advice Hello group, now read and reread both RFC's, but I feel not everything is said with resp= ect to ULA. Please clarify, suggest, advice considering the following : - 6092, REC-7 states : "by default, packets with ULA source ... should not be forwarded to ... e= xterior network." - 6204 recommends customer edge routers implement 6092 (in 4.4, Security Requirement #1) --> (implied) customer edge routers should not forward ULA sources to the= Internet. - 6204 also recommends the use of ULA, internally ! (cfr ULA-... requirements, and states (4.1 General Requirements) not to forward ULA over external inteface.) So, how do I interpret this : - ULA internally and NAT (network prefix rewriting) towards the external in= terface (which would satisfy the requirement of not forwarding ULA source IP over= external interface) ((and which offers the benefit of ISP independancy for internal equipment= )) or - ULA is for communication between internal devices exclusively. A device that needs Internet connectivity must have public IP (and ULA fo= r internal communication). --> is the (so far : static) address selection table capable of supportin= g this ? (I understand making address selection table configurable via SLAAC/DHCPv6 are draft's only ?) ((and if I interpret address selection RFC correctly, preference to ULA w= ould be given only if within the same /64 (if "label", in RFC3484 =3D=3D /64). )) Thanks for positive feedback on this ! Kind regards, Marc Lampo _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From brian.e.carpenter@gmail.com Wed Sep 5 01:11:05 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD47021F8698 for ; Wed, 5 Sep 2012 01:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.391 X-Spam-Level: X-Spam-Status: No, score=-101.391 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQXY5eS8JUP8 for ; Wed, 5 Sep 2012 01:11:05 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id C61BA21F86B3 for ; Wed, 5 Sep 2012 01:11:04 -0700 (PDT) Received: by eaai11 with SMTP id i11so75565eaa.31 for ; Wed, 05 Sep 2012 01:11:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=8L2pYi7CsUOEWMLvcpMPc3lvSddWnDi7h8CBP0kKZK0=; b=N7zNFYAu6ppCouTmP91oQmwf3gBhmjcpexIvQyK3Pnmhd2nFHT2H4G7OPs+zxqLBar Po/5UlAKdrsBEIJv86/hT9Qpg4v6QBG8ICgq0yOa8aPw/3IXqdIXlYFLZW0dzGa+RFHs EXrP3uaLIhb1voxf2R6M847NiQ13CwuhuFnUN8SK6awX9btuHI4WH7+5Bx+7m88J4WQx 3dgcgxfvjmPmYuod5NerLt6HMXd5aLERoDNWXBXkjiYHnrcQEC+vu/hS37pyriV/CBfz W5z7hOhCg1vc+3ojKPvbrG3XQfd8d8aNDNreT/euR9BInp4L0Ugl4GICKo6c7lUTUAro v6oA== Received: by 10.14.202.131 with SMTP id d3mr29827317eeo.32.1346832663200; Wed, 05 Sep 2012 01:11:03 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-216-127.as13285.net. [2.102.216.127]) by mx.google.com with ESMTPS id h42sm2042065eem.5.2012.09.05.01.11.00 (version=SSLv3 cipher=OTHER); Wed, 05 Sep 2012 01:11:01 -0700 (PDT) Message-ID: <5047091A.1000800@gmail.com> Date: Wed, 05 Sep 2012 09:11:06 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Wuyts Carl References: <867F4B6A1672E541A94676D556793ACD16E4E3748F@MOPESMBX01.eu.thmulti.com> In-Reply-To: <867F4B6A1672E541A94676D556793ACD16E4E3748F@MOPESMBX01.eu.thmulti.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] RFC 6092 - RFC 6204 - ULA : query for clarification/advice X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 08:11:06 -0000 Carl, I don't disagree with anything you say, but we shouldn't forget that some people are pushing ULAs with prefix translation (draft-bonica-v6-multihome). This is out of the scope of 6092, 6204 or 6204bis though. I prefer draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat personally. Regards Brian On 05/09/2012 08:53, Wuyts Carl wrote: > Hi Marc, > > I'm working in the CPE area, supporting ULA-usage. > > ULA indeed to be used for "internal" traffic only, this can also be traffic over VPN within your company. I don't see why you drag NAT along, there's no relation to NAT using ULA. I assume you make this link based upon private addressing in IPv4 and its NAT appliance. > > A CPE typically uses a default route, hence the ULA-packet indeed will be dropped when destined to "the internet". > > There's no problem assigning ULA next to GUA address(es); this can be done manual or just using the RTADV daemon of the CPE. > > Regs > Carl > > > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Marc Lampo > Sent: vrijdag 24 augustus 2012 13:16 > To: v6ops@ietf.org > Subject: [v6ops] RFC 6092 - RFC 6204 - ULA : query for clarification/advice > > Hello group, > > now read and reread both RFC's, but I feel not everything is said with respect to ULA. > Please clarify, suggest, advice considering the following : > - 6092, REC-7 states : > "by default, packets with ULA source ... should not be forwarded to ... exterior network." > > - 6204 recommends customer edge routers implement 6092 > (in 4.4, Security Requirement #1) > --> (implied) customer edge routers should not forward ULA sources to the Internet. > > - 6204 also recommends the use of ULA, internally ! > (cfr ULA-... requirements, and states (4.1 General Requirements) > not to forward ULA over external inteface.) > > > So, how do I interpret this : > - ULA internally and NAT (network prefix rewriting) towards the external interface > (which would satisfy the requirement of not forwarding ULA source IP over external interface) > ((and which offers the benefit of ISP independancy for internal equipment)) or > - ULA is for communication between internal devices exclusively. > A device that needs Internet connectivity must have public IP (and ULA for internal communication). > --> is the (so far : static) address selection table capable of supporting this ? > (I understand making address selection table configurable via > SLAAC/DHCPv6 are draft's only ?) > ((and if I interpret address selection RFC correctly, preference to ULA would be given > only if within the same /64 (if "label", in RFC3484 == /64). )) > > Thanks for positive feedback on this ! > Kind regards, > > Marc Lampo > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From Carl.Wuyts@technicolor.com Wed Sep 5 01:14:43 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ADD221F86A1 for ; Wed, 5 Sep 2012 01:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.038 X-Spam-Level: X-Spam-Status: No, score=-5.038 tagged_above=-999 required=5 tests=[AWL=-0.904, BAYES_00=-2.599, FRT_LOLITA1=1.865, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B7Nr3708Htef for ; Wed, 5 Sep 2012 01:14:42 -0700 (PDT) Received: from na3sys009aog123.obsmtp.com (na3sys009aog123.obsmtp.com [74.125.149.149]) by ietfa.amsl.com (Postfix) with ESMTP id 611FE21F84CD for ; Wed, 5 Sep 2012 01:14:40 -0700 (PDT) Received: from mopesedge02.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob123.postini.com ([74.125.148.12]) with SMTP ID DSNKUEcJ7yYAHcJ6EzbwOnNDuW3DtONCI2rM@postini.com; Wed, 05 Sep 2012 01:14:42 PDT Received: from MOPESMAILHC02.eu.thmulti.com (141.11.100.29) by mopesedge02.eu.thmulti.com (141.11.253.23) with Microsoft SMTP Server (TLS) id 8.3.264.0; Wed, 5 Sep 2012 10:13:54 +0200 Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.14]) by MOPESMAILHC02.eu.thmulti.com ([141.11.100.29]) with mapi; Wed, 5 Sep 2012 10:14:03 +0200 From: Wuyts Carl To: Brian E Carpenter Date: Wed, 5 Sep 2012 10:14:02 +0200 Thread-Topic: [v6ops] RFC 6092 - RFC 6204 - ULA : query for clarification/advice Thread-Index: Ac2LPgZczEkfplDGRMqv8oJhHJBwZgAAB4Rg Message-ID: <867F4B6A1672E541A94676D556793ACD16E4E374AD@MOPESMBX01.eu.thmulti.com> References: <867F4B6A1672E541A94676D556793ACD16E4E3748F@MOPESMBX01.eu.thmulti.com> <5047091A.1000800@gmail.com> In-Reply-To: <5047091A.1000800@gmail.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] RFC 6092 - RFC 6204 - ULA : query for clarification/advice X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 08:14:43 -0000 QWNrLg0KTWF5YmUgSSdtIGN1dHRpbmcgdG9vIG1hbnkgY29ybmVycyBoZXJlLCBidXQgSSdkIHNh eSB0aGF0IGFueXRoaW5nIHdpdGhvdXQgTkFUIGlzIGJldHRlciBpbiBJUHY2IDotKS4NCkJlaW5n IG9wZXJhdGlvbmFsIG1haW5seSBpbiByZXNpZGVudGlhbCAobWFuYWdlZCkgZ2F0ZXdheXMsIG11 bHRpLWhvbWluZyBpcyB1c3VhbGx5IG5vdCBwcmVzZW50LCBidXQgc2hvdWxkIG5vdCBiZSBpZ25v cmVkIG9mIGNvdXJzZS4NCg0KUmVncw0KQ2FybA0KDQoNCg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCkZyb206IEJyaWFuIEUgQ2FycGVudGVyIFttYWlsdG86YnJpYW4uZS5jYXJw ZW50ZXJAZ21haWwuY29tXSANClNlbnQ6IHdvZW5zZGFnIDUgc2VwdGVtYmVyIDIwMTIgMTA6MTEN ClRvOiBXdXl0cyBDYXJsDQpDYzogTWFyYyBMYW1wbzsgdjZvcHNAaWV0Zi5vcmcNClN1YmplY3Q6 IFJlOiBbdjZvcHNdIFJGQyA2MDkyIC0gUkZDIDYyMDQgLSBVTEEgOiBxdWVyeSBmb3IgY2xhcmlm aWNhdGlvbi9hZHZpY2UNCg0KQ2FybCwNCg0KSSBkb24ndCBkaXNhZ3JlZSB3aXRoIGFueXRoaW5n IHlvdSBzYXksIGJ1dCB3ZSBzaG91bGRuJ3QgZm9yZ2V0IHRoYXQgc29tZSBwZW9wbGUgYXJlIHB1 c2hpbmcgVUxBcyB3aXRoIHByZWZpeCB0cmFuc2xhdGlvbiAoZHJhZnQtYm9uaWNhLXY2LW11bHRp aG9tZSkuDQpUaGlzIGlzIG91dCBvZiB0aGUgc2NvcGUgb2YgNjA5MiwgNjIwNCBvciA2MjA0Ymlz IHRob3VnaC4NCg0KSSBwcmVmZXIgZHJhZnQtaWV0Zi12Nm9wcy1pcHY2LW11bHRpaG9taW5nLXdp dGhvdXQtaXB2Nm5hdCBwZXJzb25hbGx5Lg0KDQpSZWdhcmRzDQogICBCcmlhbg0KDQpPbiAwNS8w OS8yMDEyIDA4OjUzLCBXdXl0cyBDYXJsIHdyb3RlOg0KPiBIaSBNYXJjLA0KPiANCj4gSSdtIHdv cmtpbmcgaW4gdGhlIENQRSBhcmVhLCBzdXBwb3J0aW5nIFVMQS11c2FnZS4NCj4gDQo+IFVMQSBp bmRlZWQgdG8gYmUgdXNlZCBmb3IgImludGVybmFsIiB0cmFmZmljIG9ubHksIHRoaXMgY2FuIGFs c28gYmUgdHJhZmZpYyBvdmVyIFZQTiB3aXRoaW4geW91ciBjb21wYW55LiBJIGRvbid0IHNlZSB3 aHkgeW91IGRyYWcgTkFUIGFsb25nLCB0aGVyZSdzIG5vIHJlbGF0aW9uIHRvIE5BVCB1c2luZyBV TEEuICBJIGFzc3VtZSB5b3UgbWFrZSB0aGlzIGxpbmsgYmFzZWQgdXBvbiBwcml2YXRlIGFkZHJl c3NpbmcgaW4gSVB2NCBhbmQgaXRzIE5BVCBhcHBsaWFuY2UuDQo+IA0KPiBBIENQRSB0eXBpY2Fs bHkgdXNlcyBhIGRlZmF1bHQgcm91dGUsIGhlbmNlIHRoZSBVTEEtcGFja2V0IGluZGVlZCB3aWxs IGJlIGRyb3BwZWQgd2hlbiBkZXN0aW5lZCB0byAidGhlIGludGVybmV0Ii4NCj4gDQo+IFRoZXJl J3Mgbm8gcHJvYmxlbSBhc3NpZ25pbmcgVUxBIG5leHQgdG8gR1VBIGFkZHJlc3MoZXMpOyB0aGlz IGNhbiBiZSBkb25lIG1hbnVhbCBvciBqdXN0IHVzaW5nIHRoZSBSVEFEViBkYWVtb24gb2YgdGhl IENQRS4NCj4gDQo+IFJlZ3MNCj4gQ2FybA0KPiANCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+IEZyb206IHY2b3BzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzp2Nm9wcy1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgDQo+IE9mIE1hcmMgTGFtcG8NCj4gU2VudDogdnJpamRh ZyAyNCBhdWd1c3R1cyAyMDEyIDEzOjE2DQo+IFRvOiB2Nm9wc0BpZXRmLm9yZw0KPiBTdWJqZWN0 OiBbdjZvcHNdIFJGQyA2MDkyIC0gUkZDIDYyMDQgLSBVTEEgOiBxdWVyeSBmb3IgDQo+IGNsYXJp ZmljYXRpb24vYWR2aWNlDQo+IA0KPiBIZWxsbyBncm91cCwNCj4gDQo+IG5vdyByZWFkIGFuZCBy ZXJlYWQgYm90aCBSRkMncywgYnV0IEkgZmVlbCBub3QgZXZlcnl0aGluZyBpcyBzYWlkIHdpdGgg cmVzcGVjdCB0byBVTEEuDQo+IFBsZWFzZSBjbGFyaWZ5LCBzdWdnZXN0LCBhZHZpY2UgY29uc2lk ZXJpbmcgdGhlIGZvbGxvd2luZyA6DQo+IC0gNjA5MiwgUkVDLTcgc3RhdGVzIDoNCj4gICAiYnkg ZGVmYXVsdCwgcGFja2V0cyB3aXRoIFVMQSBzb3VyY2UgLi4uIHNob3VsZCBub3QgYmUgZm9yd2Fy ZGVkIHRvIC4uLiBleHRlcmlvciBuZXR3b3JrLiINCj4gDQo+IC0gNjIwNCByZWNvbW1lbmRzIGN1 c3RvbWVyIGVkZ2Ugcm91dGVycyBpbXBsZW1lbnQgNjA5Mg0KPiAgIChpbiA0LjQsIFNlY3VyaXR5 IFJlcXVpcmVtZW50ICMxKQ0KPiAgIC0tPiAoaW1wbGllZCkgY3VzdG9tZXIgZWRnZSByb3V0ZXJz IHNob3VsZCBub3QgZm9yd2FyZCBVTEEgc291cmNlcyB0byB0aGUgSW50ZXJuZXQuDQo+IA0KPiAt IDYyMDQgYWxzbyByZWNvbW1lbmRzIHRoZSB1c2Ugb2YgVUxBLCBpbnRlcm5hbGx5ICENCj4gICAo Y2ZyIFVMQS0uLi4gcmVxdWlyZW1lbnRzLCBhbmQgc3RhdGVzICg0LjEgR2VuZXJhbCBSZXF1aXJl bWVudHMpDQo+ICAgIG5vdCB0byBmb3J3YXJkIFVMQSBvdmVyIGV4dGVybmFsIGludGVmYWNlLikN Cj4gDQo+IA0KPiBTbywgaG93IGRvIEkgaW50ZXJwcmV0IHRoaXMgOg0KPiAtIFVMQSBpbnRlcm5h bGx5IGFuZCBOQVQgKG5ldHdvcmsgcHJlZml4IHJld3JpdGluZykgdG93YXJkcyB0aGUgZXh0ZXJu YWwgaW50ZXJmYWNlDQo+ICAgKHdoaWNoIHdvdWxkIHNhdGlzZnkgdGhlIHJlcXVpcmVtZW50IG9m IG5vdCBmb3J3YXJkaW5nIFVMQSBzb3VyY2UgSVAgb3ZlciBleHRlcm5hbCBpbnRlcmZhY2UpDQo+ ICAgKChhbmQgd2hpY2ggb2ZmZXJzIHRoZSBiZW5lZml0IG9mIElTUCBpbmRlcGVuZGFuY3kgZm9y IGludGVybmFsIA0KPiBlcXVpcG1lbnQpKSBvcg0KPiAtIFVMQSBpcyBmb3IgY29tbXVuaWNhdGlv biBiZXR3ZWVuIGludGVybmFsIGRldmljZXMgZXhjbHVzaXZlbHkuDQo+ICAgQSBkZXZpY2UgdGhh dCBuZWVkcyBJbnRlcm5ldCBjb25uZWN0aXZpdHkgbXVzdCBoYXZlIHB1YmxpYyBJUCAoYW5kIFVM QSBmb3IgaW50ZXJuYWwgY29tbXVuaWNhdGlvbikuDQo+ICAgLS0+IGlzIHRoZSAoc28gZmFyIDog c3RhdGljKSBhZGRyZXNzIHNlbGVjdGlvbiB0YWJsZSBjYXBhYmxlIG9mIHN1cHBvcnRpbmcgdGhp cyA/DQo+ICAgICAgICAoSSB1bmRlcnN0YW5kIG1ha2luZyBhZGRyZXNzIHNlbGVjdGlvbiB0YWJs ZSBjb25maWd1cmFibGUgdmlhDQo+IFNMQUFDL0RIQ1B2NiBhcmUgZHJhZnQncyBvbmx5ID8pDQo+ ICAgKChhbmQgaWYgSSBpbnRlcnByZXQgYWRkcmVzcyBzZWxlY3Rpb24gUkZDIGNvcnJlY3RseSwg cHJlZmVyZW5jZSB0byBVTEEgd291bGQgYmUgZ2l2ZW4NCj4gICAgIG9ubHkgaWYgd2l0aGluIHRo ZSBzYW1lIC82NCAoaWYgImxhYmVsIiwgaW4gUkZDMzQ4NCA9PSAvNjQpLiApKQ0KPiANCj4gVGhh bmtzIGZvciBwb3NpdGl2ZSBmZWVkYmFjayBvbiB0aGlzICENCj4gS2luZCByZWdhcmRzLA0KPiAN Cj4gTWFyYyBMYW1wbw0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4gdjZvcHNAaWV0Zi5vcmcNCj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4g djZvcHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92 Nm9wcw0KPiANCg== From despres.remi@laposte.net Wed Sep 5 01:41:29 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 902BD21F86C4 for ; Wed, 5 Sep 2012 01:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.849 X-Spam-Level: X-Spam-Status: No, score=-0.849 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, MIME_BAD_LINEBREAK=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hm8mtIaaiuTF for ; Wed, 5 Sep 2012 01:41:27 -0700 (PDT) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.3]) by ietfa.amsl.com (Postfix) with ESMTP id D33E721F86C1 for ; Wed, 5 Sep 2012 01:41:26 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2111.sfr.fr (SMTP Server) with ESMTP id E6A67700008C; Wed, 5 Sep 2012 10:41:24 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2111.sfr.fr (SMTP Server) with ESMTP id D69637000043; Wed, 5 Sep 2012 10:41:23 +0200 (CEST) X-SFR-UUID: 20120905084123879.D69637000043@msfrf2111.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/mixed; boundary=Apple-Mail-7--839904134 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <5046E1F2.4010702@globis.net> Date: Wed, 5 Sep 2012 10:41:23 +0200 Message-Id: <6D4F16ED-11D3-4129-9C9A-E4B0EBD5CDB8@laposte.net> References: <504392E0.8070802@bogus.com> <5046E1F2.4010702@globis.net> To: Ray Hunter X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] Reminder: draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 08:41:29 -0000 --Apple-Mail-7--839904134 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi, Ray, Good to see a synthetic comment on the draft. more comments inline. 2012-09-05 07:24, Ray Hunter : > I have read this draft and lurked the on-list discussion. >=20 > Comments based on version 07 = http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-07 >=20 > Following all IMVVHO [I'm no XLAT expert] >=20 > 1) The need for 464XLAT is clear. Agreed. > 2) The basic 464xlat architecture is sound and certainly worthy of = advancement and further refinement. > The authors have done a great job on what is a very tricky problem. Same view. > 3) Inclusion of ND Proxy [RFC4389] is problematic for 2 reasons: > Firstly ND Proxy is an experimental protocol, whereas the draft is = aiming to become BCP. +1 > Secondly, ND Proxy has inadequate loop detection, prevention and = mitigation, for it to be reliably deployed in tethered networks = consisting of multiple devices. If 464XLAT is going to be effective, it = will need to be incorporated into CPE devices. Section 4.1.3.3 of 4389 = is a potential source of oscillation, instability, unpredictable = behaviour, and provides a DoS vector, if 464XLAT were to be widely = incorporated into consumer devices. [Authors claim multiple device = working is out of scope, but this situation will likely happen in home = use) ] >=20 > 4) Section 8.3.2 does not adequately deprecate single /64 working, = which I consider harmful (as per BCP157). - I see no reason why, if technically feasible (as is the case AFAIK), a = node being delegated a /64 would be forbidden to use it on an IPv6 link, = and simultaneously for private IPv4 using 464XLAT. - BCP157 ? > 5) Assignment of a single special-purpose IANA IID is problematic for = 2 reasons. >=20 > I don't consider the document complies with the spirit of justifying = the Modified EUI-64 identifier via expert review (RFC5342 Section 5.1), = in that the argumentation for assignment is very opaque, and the = use-case is not completely defined e.g. the IID SHOULD NOT be used for = L2 addressing by the CLAT. Pros and cons of CLAT reserved IID can be clarified as much as needed = for experts to base their conclusions. Actually, extending reservation to one IID range per RFC1918 = private-IPv4 prefix permits a very substantial simplification of the = draft. With it, the original spirit of a trivial combination of a = stateless RFC 6145 in CLATs and stateful RFC 6146 in PLATs can be = restored by:=20 - suppressing the need for a variant with 464XLAT-specific IPv6 prefix, = and one without - suppressing the need for one variant without NAT44 and one with NAT44 - permitting safe operation in CLAT nodes that are delegated /64s=20 Here is an example of what the simplified draft might look like if the = approach is accepted.=20 --Apple-Mail-7--839904134 Content-Disposition: attachment; filename=Draft-07-modif-RD.txt Content-Type: text/plain; name="Draft-07-modif-RD.txt" Content-Transfer-Encoding: quoted-printable Internet Engineering Task Force M. Mawatari=0D= Internet-Draft Japan Internet Exchange Co.,Ltd.=0D= Intended status: BCP M. Kawashima=0D= Expires: March XX, 2013 NEC AccessTechnica, Ltd.=0D= C. Byrne=0D= T-Mobile USA=0D= September XX, 2012=0D= =0D=0D 464XLAT: Combination of Stateful and Stateless Translation=0D= draft-ietf-v6ops-464xlat-XX=0DAbstract=0D=0D = This document describes an architecture (464XLAT) for providing=0D = limited IPv4 connectivity across an IPv6-only network by combining=0D = existing and well-known stateful protocol translation RFC 6146 in the=0D = core and stateless protocol translation RFC 6145 at the edge. 464XLAT=0D= is a simple and scalable technique to quickly deploy limited IPv4=0D = access service to IPv6-only edge networks without encapsulation.=0D=0D= Status of this Memo=0D=0D This Internet-Draft is submitted in full = conformance with the=0D provisions of BCP 78 and BCP 79.=0D=0D = Internet-Drafts are working documents of the Internet Engineering=0D = Task Force (IETF). Note that other groups may also distribute=0D = working documents as Internet-Drafts. The list of current Internet-=0D = Drafts is at http://datatracker.ietf.org/drafts/current/.=0D=0D = Internet-Drafts are draft documents valid for a maximum of six months=0D = and may be updated, replaced, or obsoleted by other documents at any=0D= time. It is inappropriate to use Internet-Drafts as reference=0D = material or to cite them other than as "work in progress."=0D=0D This = Internet-Draft will expire on February 21, 2013.=0D=0DCopyright Notice=0D= =0D Copyright (c) 2012 IETF Trust and the persons identified as the=0D = document authors. All rights reserved.=0D=0D This document is = subject to BCP 78 and the IETF Trust's Legal=0D Provisions Relating to = IETF Documents=0D (http://trustee.ietf.org/license-info) in effect on = the date of=0D publication of this document. Please review these = documents=0D carefully, as they describe your rights and restrictions = with respect=0D=0D=0D=0DMawatari, et al. Expires February 21, = 2013 [Page 1]=0D =0D=0DInternet-Draft = 464XLAT August 2012=0D=0D=0D to this document. = Code Components extracted from this document must=0D include = Simplified BSD License text as described in Section 4.e of=0D the = Trust Legal Provisions and are provided without warranty as=0D = described in the Simplified BSD License.=0D=0D=0DTable of Contents=0D=0D = 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3=0D= 2. BCP Scenario . . . . . . . . . . . . . . . . . . . . . . . . . 3=0D= 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 3=0D= 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4=0D= 5. Motivation and Uniqueness of 464XLAT . . . . . . . . . . . . . 4=0D= 6. Network Architecture . . . . . . . . . . . . . . . . . . . . . 4=0D= 6.1. Wireline Network Architecture . . . . . . . . . . . . . . 5=0D= 6.2. Wireless 3GPP Network Architecture . . . . . . . . . . . . 6=0D= 7. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 7=0D= 7.1. Wireline Network Applicability . . . . . . . . . . . . . . 7=0D= 7.2. Wireless 3GPP Network Applicability . . . . . . . . . . . 7=0D= 8. Implementation Considerations . . . . . . . . . . . . . . . . 7=0D= 8.1. IPv6 Address Format . . . . . . . . . . . . . . . . . . . 8=0D= 8.2. IPv4/IPv6 Address Translation Chart . . . . . . . . . . . 8=0D= 8.3. IPv6 Prefix Handling . . . . . . . . . . . . . . . . . . . 12=0D= 8.4. DNS Proxy Implementation . . . . . . . . . . . . . . . . . 12=0D= 8.5. CLAT in a Gateway . . . . . . . . . . . . . . . . . . . . 13=0D= 8.6. CLAT to CLAT communications . . . . . . . . . . . . . . . 13=0D= 9. Deployment Considerations . . . . . . . . . . . . . . . . . . 13=0D= 9.1. Traffic Engineering . . . . . . . . . . . . . . . . . . . 13=0D= 9.2. Traffic Treatment Scenarios . . . . . . . . . . . . . . . 14=0D= 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14=0D= 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14=0D= 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15=0D= 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15=0D= 13.1. Normative References . . . . . . . . . . . . . . . . . . . 15=0D= 13.2. Informative References . . . . . . . . . . . . . . . . . . 15=0D= Appendix A. Examples of IPv4/IPv6 Address Translation . . . . . . 16=0D= Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19=0D= =0D=0D=0D=0D=0D=0D=0D=0D=0D=0DMawatari, et al. Expires February = 21, 2013 [Page 2]=0D =0D=0DInternet-Draft = 464XLAT August 2012=0D=0D=0D1. Introduction=0D=0D = With the exhaustion of the unallocated IPv4 address pools, it will be=0D= difficult for many networks to assign IPv4 addresses to end users.=0D=0D= This document describes an IPv4 over IPv6 solution as one of the=0D = techniques for IPv4 service extension and encouragement of IPv6=0D = deployment. 464XLAT is not a one-for-one replacement of full IPv4=0D = functionality. The 464XLAT architecture only supports IPv4 in the=0D = client server model, where the server has a global IPv4 address.=0D = This means it is not fit for IPv4 peer-to-peer communication or=0D = inbound IPv4 connections. 464XLAT builds on IPv6 transport and=0D = includes full any-to-any IPv6 communication.=0D=0D The 464XLAT = architecture described in this document uses IPv4/IPv6=0D translation = standardized in [RFC6145] and [RFC6146]. It does not=0D require DNS64 = [RFC6147] since an IPv4 host may simply send IPv4=0D packets, = including packets to an IPv4 DNS server, which will be=0D translated = on the customer side translator(CLAT) to IPv6 and back to=0D IPv4 on = the provider side translator(PLAT). 464XLAT networks may use=0D DNS64 = [RFC6147] to enable single stateful translation [RFC6146]=0D instead = of 464XLAT double translation where possible. The 464XLAT=0D = architecture encourages the IPv6 transition by making IPv4 services=0D = reachable across IPv6-only networks and providing IPv6 and IPv4=0D = connectivity to single-stack IPv4 or IPv6 servers and peers.=0D=0D By = combining 464XLAT with BIH [RFC6535], it is also possible to=0D = provide single IPv4 to IPv6 translation service, which will be needed=0D = in the future case of IPv6-only servers and peers to be reached from=0D= IPv4-only hosts across IPv6-only networks.=0D=0D=0D2. BCP Scenario=0D= =0D This BCP only applies when the following two criteria are present:=0D= =0D 1. There is an IPv6-only network that uses stateful translation=0D= [RFC6146] as the only mechanism for providing IPv4 access.=0D=0D = 2. There are IPv4-only applications or hosts that must communicate=0D = across the IPv6-only network to reach the IPv4 Internet.=0D=0D=0D3. = Requirements Language=0D=0D The key words "MUST", "MUST NOT", = "REQUIRED", "SHALL", "SHALL NOT",=0D "SHOULD", "SHOULD NOT", = "RECOMMENDED", "MAY", and "OPTIONAL" in this=0D document are to be = interpreted as described in [RFC2119].=0D=0D=0D=0DMawatari, et al. = Expires February 21, 2013 [Page 3]=0D =0D=0D= Internet-Draft 464XLAT August 2012=0D= =0D=0D4. Terminology=0D=0D PLAT: PLAT is Provider side = translator(XLAT) that complies with=0D [RFC6146]. It = translates N:1 global IPv6 addresses to global=0D IPv4 = addresses, and vice versa.=0D=0D CLAT: CLAT is Customer side = translator(XLAT) that complies with=0D [RFC6145]. It = algorithmically translates 1:1 private IPv4=0D addresses to = global IPv6 addresses, and vice versa. The CLAT=0D function = is applicable to a router or an end-node such as a=0D mobile = phone. The CLAT SHOULD perform router function to=0D = facilitate packets forwarding through the stateless=0D = translation even if it is an end-node. The CLAT as=0D a common = home router or wireless 3GPP router is expected to=0D perform = gateway functions such as DHCP server and DNS proxy=0D for = local clients. The CLAT does not comply with the=0D sentence = "Both IPv4-translatable IPv6 addresses and IPv4-=0D converted = IPv6 addresses SHOULD use the same prefix." that is=0D = described on Section 3.3 in [RFC6052] due to using different=0D = IPv6 prefixes for CLAT-side and PLAT-side IPv4 addresses.=0D=0D=0D5. = Motivation and Uniqueness of 464XLAT=0D=0D 1. Minimal IPv4 resource = requirements, maximum IPv4 efficiency=0D through statistical = multiplexing.=0D=0D 2. No new protocols required, quick deployment.=0D= =0D 3. IPv6-only networks are simpler and therefore less expensive to=0D= operate.=0D=0D=0D6. Network Architecture=0D=0D Examples of = 464XLAT architectures are show in the figures in the=0D following = sections.=0D=0D Wireline Network Architecture can fit in the = situations that there=0D are the clients behind the CLAT in the same = way regardless of the=0D type of access service, for example FTTH, = Cable, or WiFi.=0D=0D Wireless 3GPP Network Architecture can fit in = the situations that=0D client and node that terminate access network = is same host in the=0D same way.=0D=0D=0D=0DMawatari, et al. = Expires February 21, 2013 [Page 4]=0D =0D=0DInternet-Draft = 464XLAT August 2012=0D=0D=0D6.1. = Wireline Network Architecture=0D=0D The private IPv4 host on this = diagram can reach global IPv4 hosts via=0D translation on both CLAT = and PLAT. On the other hand, the IPv6 host=0D can reach other IPv6 = hosts on the Internet directly without=0D translation. This means = that the CPE/CLAT can not only have the=0D function of a CLAT but also = the function of an IPv6 native router for=0D native IPv6 traffic. The = v4p host behind the CLAT on this diagram=0D with the private IPv4 = addresses.=0D=0D=0D +------+=0D = | v6 |=0D | = host |=0D +--+---+=0D = |=0D .---+---.=0D = / \=0D / = IPv6 \=0D | Internet |=0D = \ /=0D = `----+----'=0D |=0D +------+ | = .---+---. .------.=0D | v6 +---+ = +------+ / \ +------+ / \=0D | host | | = | | / IPv6 \ | | / IPv4 \=0D +------+ = +---+ CLAT +---+ Network +---+ PLAT +---+ Internet |=0D = +--------+ | | | \ / | | \ /=0D = | v4p/v6 +-+ +------+ `---------' +------+ `----+----'=0D= | host | | |=0D = +--------+ | +--+---+=0D = +------+ | | v4g |=0D = | v4p +---+ | host |=0D = | host | | +------+=0D = +------+ |=0D=0D <- v4p -> XLAT <--------- v6 --------> XLAT = <- v4g ->=0D=0D v6 : Global IPv6=0D v4p : Private IPv4=0D = v4g : Global IPv4=0D=0D Figure 1: Wireline Network = Topology=0D=0D=0D=0D=0D=0D=0D=0D=0DMawatari, et al. Expires = February 21, 2013 [Page 5]=0D =0D=0DInternet-Draft = 464XLAT August 2012=0D=0D=0D6.2. Wireless = 3GPP Network Architecture=0D=0D The CLAT function on the User = Equipment (UE) provides an [RFC1918]=0D address and IPv4 default = route. The applications on the UE can use=0D the private IPv4 address = for reaching global IPv4 hosts via=0D translation on both CLAT and = PLAT. On the other hand, reaching IPv6=0D hosts (including host = presented via DNS64 [RFC6147]) does not require=0D the CLAT function = on the UE.=0D=0D=0D +------+=0D = | v6 |=0D | = host |=0D +--+---+=0D = |=0D .---+---.=0D = / \=0D / = IPv6 \=0D | Internet |=0D = \ /=0D UE / Mobile Phone = `---------'=0D +----------------------+ |=0D | +----+ | = | .---+---. .------.=0D | | v6 +----+ = +------+ / \ +------+ / \=0D | +----+ | = | | / IPv6 PDP \ | | / IPv4 \=0D | = +---+ CLAT +---+ Mobile Core +---+ PLAT +--+ Internet |=0D | = | | | \ GGSN / | | \ /=0D | = | +------+ \ ' +------+ `----+---'=0D | = +-----+ | | `-------' |=0D | | = v4p +---+ | +--+---+=0D | = +-----+ | | | v4g |=0D = +----------------------+ | host |=0D = +------+=0D=0D= <- v4p -> XLAT <--------- v6 --------> XLAT <- v4g ->=0D=0D = v6 : Global IPv6=0D v4p : Private IPv4=0D v4g : Global IPv4=0D= =0D=0D=0D Figure 2: Wireless 3GPP Network Topology=0D=0D=0D= =0D=0D=0D=0D=0D=0DMawatari, et al. Expires February 21, 2013 = [Page 6]=0D =0D=0DInternet-Draft 464XLAT = August 2012=0D=0D=0D7. Applicability=0D=0D7.1. Wireline = Network Applicability=0D=0D When an ISP has IPv6 access service and = provides 464XLAT, the ISP can=0D provide outgoing IPv4 service to end = users across an IPv6 access=0D network. The result is that edge = network growth is no longer tightly=0D coupled to the availability of = scarce IPv4 addresses.=0D=0D If another ISP operates the PLAT, the = edge ISP is only required to=0D deploy an IPv6 access network. All = ISPs do not need IPv4 access=0D networks. They can migrate their = access network to a simple and=0D highly scalable IPv6-only = environment.=0D=0D Incidentally, the effectiveness of 464XLAT was = confirmed in the WIDE=0D camp Spring 2012. The result is described in=0D= [I-D.hazeyama-widecamp-ipv6-only-experience].=0D=0D7.2. Wireless = 3GPP Network Applicability=0D=0D The vast majority of mobile networks = are compliant to Pre-Release 9=0D 3GPP standards. In Pre-Release 9 = 3GPP networks, GSM and UMTS=0D networks must signal and support both = IPv4 and IPv6 Packet Data=0D Protocol (PDP) attachments to access IPv4 = and IPv6 network=0D destinations [RFC6459]. Since there are two PDPs = required to support=0D two address families, this is double the number = of PDPs required to=0D support the status quo of one address family, = which is IPv4.=0D=0D For the IPv4 literal or IPv4 socket applications = that require IPv4=0D connectivity, the CLAT function on the UE = provides a private IPv4=0D address and IPv4 default route on the host = for the applications to=0D reference and bind to. Connections sourced = from the IPv4 interface=0D are immediately routed to the CLAT function = and passed to the IPv6-=0D only mobile network, destined for the PLAT. = In summary, the UE has=0D the CLAT function that does a stateless = translation [RFC6145], but=0D only when required. The mobile network = has a PLAT that does stateful=0D translation [RFC6146].=0D=0D = 464XLAT works with today's existing systems as much as possible.=0D = 464XLAT is compatible with existing network based deep packet=0D = inspection solutions like 3GPP standardized Policy and Charging=0D = Control (PCC) [TS.23203].=0D=0D=0D8. Implementation Considerations=0D=0D= =0D=0D=0D=0D=0DMawatari, et al. Expires February 21, 2013 = [Page 7]=0D =0D=0DInternet-Draft 464XLAT = August 2012=0D=0D=0D8.1. IPv6 Address Format=0D=0D The = IPv6 address format in 464XLAT is defined in Section 2.2 of=0D = [RFC6052].=0D=0D8.2. IPv4/IPv6 Address Translation Chart=0D=0D=0D=0D=0D=0D= =0D=0D=0D=0D=0D=0D=0D=0D=0D=0D=0D=0D=0D=0D=0D=0D=0D=0D=0D=0D=0D=0D=0D=0D=0D= =0D=0D=0D=0D=0D=0D=0D=0D=0DMawatari, et al. Expires February 21, = 2013 [Page 8]=0D =0D=0DInternet-Draft = 464XLAT August 2012=0D=0D=0D = Destination IPv4 address=0D = +----------------------------+=0D = | Global IPv4 address |=0D = | assigned to IPv4 server |=0D = +--------+ +----------------------------+=0D = | IPv4 | Source IPv4 address=0D = | server | +----------------------------+=0D = +--------+ | Global IPv4 address |=0D = ^ | assigned to IPv4 PLAT pool |=0D = | +----------------------------+=0D = +--------+=0D | PLAT | = Stateful XLATE(IPv4:IPv6=3D1:n)=0D = +--------+=0D ^=0D = |=0D (IPv6 cloud)=0D = Destination IPv6 address=0D = +--------------------------------------------------------------+=0D = | IPv4-Embedded IPv6 address |=0D = | defined in Section 2.2 of RFC6052 |=0D = +--------------------------------------------------------------+=0D= Source IPv6 address=0D = +--------------------------------------------------------------+=0D = | IPv4-Embedded IPv6 address |=0D = | defined in Section 2.2 of RFC6052 |=0D = +--------------------------------------------------------------+=0D= (IPv6 cloud)=0D = ^=0D |=0D = +--------+=0D | | In the = case the CLAT has a=0D | | = dedicated IPv6 prefix for=0D | CLAT | = translation, the CLAT can=0D | | = perform with only Stateless=0D | | = XLATE (IPv4:IPv6=3D1:1).=0D +--------+=0D = ^ Destination IPv4 address=0D = | +----------------------------+=0D = +--------+ | Global IPv4 address |=0D = | IPv4 | | assigned to IPv4 server |=0D= | client | +----------------------------+=0D= +--------+ Source IPv4 address=0D = +----------------------------+=0D = | Private IPv4 address |=0D = | assigned to IPv4 client |=0D = +----------------------------+=0D= =0D Case of enabling only stateless XLATE on CLAT=0D=0D=0D=0D= Mawatari, et al. Expires February 21, 2013 [Page 9]=0D= =0D=0DInternet-Draft 464XLAT = August 2012=0D=0D=0D=0D8.3. IPv6 Prefix Handling=0D=0D =46rom any /64 = routed to the CLAT, a /96 is dedicated to=0D source and receive IPv6 = packets associated with the stateless=0D translation [RFC6145], by = appending to it 0x02005E00, an interface ID prefix that no host = conforming to the IPv6 addressing architecture [RFC4291] may use = (Section 11). =0D=0D The CLAT MAY discover the Pref64::/n of the PLAT = via some method such=0D as DHCPv6 option, TR-069, DNS APL RR [RFC3123] = or=0D [I-D.ietf-behave-nat64-discovery-heuristic].=0D=0D=0D8.4. DNS = Proxy Implementation=0D=0D The CLAT SHOULD implement a DNS proxy as = defined in [RFC5625]. The=0D case of an IPv4-only node behind the = CLAT querying an IPv4 DNS server=0D is undesirable since it requires = both stateful and stateless=0D translation for each DNS lookup. The = CLAT SHOULD set itself as the=0D DNS server via DHCP or other means = and proxy DNS queries for IPv4 and=0D IPv6 LAN clients. Using the = CLAT enabled home router or UE as a DNS=0D=0D=0D=0DMawatari, et al. = Expires February 21, 2013 [Page 12]=0D =0D=0D= Internet-Draft 464XLAT August 2012=0D= =0D=0D proxy is a normal consumer gateway function and simplifies the=0D= traffic flow so that only IPv6 native queries are made across the=0D = access network. The CLAT SHOULD allow for a client to query any DNS=0D = server of its choice and bypass the proxy.=0D=0D8.5. CLAT in a = Gateway=0D=0D The CLAT is a stateless translation feature which can be = implemented=0D in a common home router or mobile phone that has a = tethering feature.=0D The router with CLAT function SHOULD provide = common router services=0D such as DHCP of [RFC1918] addresses, DHCPv6, = and DNS service.=0D=0D8.6. CLAT to CLAT communications=0D=0D While = CLAT to CLAT IPv4 communication may work when the client IPv4=0D = subnets do not overlap, this traffic flow is out of scope. 464XLAT is=0D = a hub and spoke architecture focused on enabling IPv4-only services=0D = over IPv6-only networks.=0D=0D=0D9. Deployment Considerations=0D=0D= 9.1. Traffic Engineering=0D=0D Even if the ISP for end users is = different from the PLAT provider=0D (e.g. another ISP), it can = implement traffic engineering=0D independently from the PLAT provider = Reason is that the ISP for end users can figure out IPv4 destination = address=0D from translated IPv6 packet header, so it can implement = traffic=0D engineering based on IPv4 destination address (e.g. = traffic=0D monitoring for each IPv4 destination address, packet = filtering=0D for each IPv4 destination address, etc.). The = tunneling methods=0D do not have such an advantage, without any = deep packet inspection=0D for processing the inner IPv4 packet of = the tunnel packet.=0D=0D=0D=0D=0D=0D=0DMawatari, et al. Expires = February 21, 2013 [Page 13]=0D =0D=0DInternet-Draft = 464XLAT August 2012=0D=0D=0D9.2. Traffic = Treatment Scenarios=0D=0D This 464XLAT architecture has capabilities. = One is a IPv4 -> IPv6 ->=0D IPv4 translation for sharing global IPv4 = addresses as a basic=0D function, another, if combined with BIH = [RFC6535], is a IPv4 -> IPv6=0D translation for reaching IPv6-only = servers from IPv4-only clients=0D that can not support IPv6. = IPv4-only clients must be support through=0D the long period of global = transition to IPv6.=0D=0D=0D = +--------+-------------+-----------------------+-------------+=0D = | Server | Application | Traffic Treatment | Location of |=0D = | | and Host | | Translation |=0D = +--------+-------------+-----------------------+-------------+=0D = | IPv6 | IPv6 | End-to-end IPv6 | None |=0D = +--------+-------------+-----------------------+-------------+=0D = | IPv4 | IPv6 | Stateful Translation | PLAT |=0D = +--------+-------------+-----------------------+-------------+=0D = | IPv4 | IPv4 | 464XLAT | PLAT/CLAT |=0D = +--------+-------------+-----------------------+-------------+=0D = | IPv6 | IPv4 | BIH | CLAT |=0D = +--------+-------------+-----------------------+-------------+=0D=0D = Traffic Treatment Scenarios=0D=0D The above chart = shows most common traffic types and traffic=0D treatment.=0D=0D=0D10. = Security Considerations=0D=0D To implement a PLAT, see security = considerations presented in Section=0D 5 of [RFC6146].=0D=0D To = implement a CLAT, see security considerations presented in Section=0D = 7 of [RFC6145]. The CLAT MAY comply with [RFC6092].=0D=0D=0D11. IANA = Considerations=0D=0D IANA is requested to reserve three ranges of = Interface IDs for 464XLAT. In order to never conflict with any host = address that complies with [RFC4291] they must belong to the EUI-64 IANA = range (section 2.2.2 of [RFC5342]). Next bits must be those of IPv4 = prefixes of [RFC1918], those found in private IPv4 addresses used in = CLAT sites. These prefixes being 10.0.0.0/8, 172.16.0.0/12, and = 192.168.0.0/16, and the EUI-64 IANA prefix being 0x02005E10, Interface = IDs to be assigned to 464XLAT CLATs can be (proposed values):=0D=0Do = 02-00-5E-10-0A-00-00-00 to 02-00-5E-10-0A-FF-FF-FF=0D=0Do = 02-00-5E-10-AC-10-00-00 to 02-00-5E-10-AC-1F-FF-FF=0D=0Do = 02-00-5E-10-C0-A8-00-00 to 02-00-5E-10-C0-A8-FF-FF=0D=0D =0D=0D=0D=0D=0D=0D= Mawatari, et al. Expires February 21, 2013 [Page 14]=0D= =0D=0DInternet-Draft 464XLAT = August 2012=0D=0D=0D12. Acknowledgements=0D=0D The authors would like = to thank JPIX NOC members, JPIX 464XLAT trial=0D service members, = Seiichi Kawamura, Dan Drown, Brian Carpenter, Rajiv=0D Asati, Washam = Fan, Behcet Sarikaya, Jan Zorz, Tatsuya Oishi, Lorenzo=0D Colitti, = Erik Kline, Ole Troan, Maoke Chen, Gang Chen, Tom Petch,=0D Jouni = Korhonen, and Bjoern A. Zeeb for their helpful comments.=0D Special = acknowledgments go to Remi Despres for his plentiful supports=0D and = suggestions, especially about using IANA's EUI-64 Interface ID ranges.=0D= We also would like to thank Fred Baker and Joel Jaeggli for their=0D = support.=0D=0D=0D13. References=0D=0D13.1. Normative References=0D=0D = [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate=0D = Requirement Levels", BCP 14, RFC 2119, March 1997.=0D=0D = [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.=0D = Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,=0D = October 2010.=0D=0D [RFC6144] Baker, F., Li, X., Bao, C., = and K. Yin, "Framework for=0D IPv4/IPv6 Translation", RFC = 6144, April 2011.=0D=0D [RFC6145] Li, X., Bao, C., and F. Baker, = "IP/ICMP Translation=0D Algorithm", RFC 6145, April 2011.=0D= =0D [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, = "Stateful=0D NAT64: Network Address and Protocol = Translation from IPv6=0D Clients to IPv4 Servers", RFC = 6146, April 2011.=0D=0D13.2. Informative References=0D=0D = [I-D.hazeyama-widecamp-ipv6-only-experience]=0D Hazeyama, = H., Hiromi, R., Ishihara, T., and O. Nakamura,=0D = "Experiences from IPv6-Only Networks with Transition=0D = Technologies in the WIDE Camp Spring 2012",=0D = draft-hazeyama-widecamp-ipv6-only-experience-01 (work in=0D = progress), March 2012.=0D=0D = [I-D.ietf-behave-nat64-discovery-heuristic]=0D Savolainen, = T., Korhonen, J., and D. Wing, "Discovery of=0D IPv6 Prefix = Used for IPv6 Address Synthesis",=0D = draft-ietf-behave-nat64-discovery-heuristic-11 (work in=0D = progress), July 2012.=0D=0D=0D=0DMawatari, et al. Expires = February 21, 2013 [Page 15]=0D =0D=0DInternet-Draft = 464XLAT August 2012=0D=0D=0D [RFC1918] = Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and=0D = E. Lear, "Address Allocation for Private Internets",=0D = BCP 5, RFC 1918, February 1996.=0D=0D [RFC3123] Koch, P., "A DNS RR = Type for Lists of Address Prefixes=0D (APL RR)", RFC 3123, = June 2001.=0D=0D [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix = Options for Dynamic=0D Host Configuration Protocol (DHCP) = version 6", RFC 3633,=0D December 2003.=0D=0D [RFC4389] = Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery=0D = Proxies (ND Proxy)", RFC 4389, April 2006.=0D=0D [RFC5342] Eastlake, = D., "IANA Considerations and IETF Protocol Usage=0D for = IEEE 802 Parameters", BCP 141, RFC 5342,=0D September 2008.=0D= =0D [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines",=0D = BCP 152, RFC 5625, August 2009.=0D=0D [RFC6092] Woodyatt, = J., "Recommended Simple Security Capabilities in=0D = Customer Premises Equipment (CPE) for Providing=0D = Residential IPv6 Internet Service", RFC 6092,=0D January = 2011.=0D=0D [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. = van=0D Beijnum, "DNS64: DNS Extensions for Network Address=0D= Translation from IPv6 Clients to IPv4 Servers", RFC 6147,=0D= April 2011.=0D=0D [RFC6459] Korhonen, J., Soininen, J., = Patil, B., Savolainen, T.,=0D Bajko, G., and K. Iisakkila, = "IPv6 in 3rd Generation=0D Partnership Project (3GPP) = Evolved Packet System (EPS)",=0D RFC 6459, January 2012.=0D=0D= [RFC6535] Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts=0D= Using "Bump-in-the-Host" (BIH)", RFC 6535, February 2012.=0D= =0D [TS.23203] 3GPP, "Policy and charging control architecture", 3GPP=0D= TS 23.203 10.7.0, June 2012.=0D=0D=0D=0DAppendix A. = Examples of IPv4/IPv6 Address Translation=0D=0D The following are = examples of IPv4/IPv6 Address Translation on the=0D 464XLAT = architecture.=0D=0D=0D=0DMawatari, et al. Expires February 21, = 2013 [Page 16]=0D =0D=0DInternet-Draft = 464XLAT August 2012=0D=0D=0D =0D=0D In the case = that an IPv6 prefix greater than /64 is assigned to an=0D end user by = such as DHCPv6-PD [RFC3633], only the Stateless XLATE=0D functionality = should be enabled on the CLAT as the CLAT can use a=0D dedicated /64 = from the assigned IPv6 prefix.=0D=0D=0D Host & configuration value=0D= +------------------------------+=0D | IPv4 server = |=0D | [198.51.100.1] | IP packet header=0D = +------------------------------+ +--------------------------------+=0D = ^ | Destination IP address |=0D= | | [198.51.100.1] |=0D= | | Source IP address |=0D= | | [192.0.2.1] |=0D= +------------------------------+ +--------------------------------+=0D= | PLAT | ^=0D | IPv4 pool = address | |=0D | [192.0.2.1 - = 192.0.2.100] | |=0D | PLAT-side XLATE IPv6 prefix = | |=0D | [2001:db8:1234::/96] | = |=0D +------------------------------+ = +--------------------------------+=0D ^ = | Destination IP address |=0D | = | [2001:db8:1234::198.51.100.1] |=0D | = | Source IP address |=0D | = | [2001:db8:aaaa:: 200:5e10:192. | =0D | = | 168.1.2] |=0D = +------------------------------+ +--------------------------------+=0D = | CLAT | ^=0D | PLAT-side = XLATE IPv6 prefix | |=0D | [2001:db8:1234::/96] = | |=0D | CLAT-side XLATE IPv6 prefix | = |=0D | [2001:db8:aaaa::/96] | |=0D = +------------------------------+ +--------------------------------+=0D= ^ | Destination IP address |=0D= | | [198.51.100.1] |=0D= | | Source IP address |=0D= | | [192.168.1.2] |=0D= +------------------------------+ +--------------------------------+=0D= | IPv4 client |=0D | [192.168.1.2/24] = |=0D +------------------------------+=0D Delegated IPv6 prefix for = client: 2001:db8:aaaa::/56=0D=0D=0D=0D=0D=0D=0D=0DMawatari, et al. = Expires February 21, 2013 [Page 17]=0D =0D=0D= Internet-Draft 464XLAT August 2012=0D= =0D=0D =0DAuthors' Addresses=0D=0D Masataka Mawatari=0D Japan = Internet Exchange Co.,Ltd.=0D KDDI Otemachi Building 19F, 1-8-1 = Otemachi,=0D Chiyoda-ku, Tokyo 100-0004=0D JAPAN=0D=0D Phone: +81 = 3 3243 9579=0D Email: mawatari@jpix.ad.jp=0D=0D=0D Masanobu = Kawashima=0D NEC AccessTechnica, Ltd.=0D 800, Shimomata=0D = Kakegawa-shi, Shizuoka 436-8501=0D JAPAN=0D=0D Phone: +81 537 23 = 9655=0D Email: kawashimam@vx.jp.nec.com=0D=0D=0D Cameron Byrne=0D = T-Mobile USA=0D Bellevue, Washington 98006=0D USA=0D=0D Email: = cameron.byrne@t-mobile.com=0D=0D=0D=0D=0D=0D=0D=0D=0D=0D=0D=0D=0D=0D= Mawatari, et al. Expires February 21, 2013 [Page 19]=0D= =0D=0D=0D=0D --Apple-Mail-7--839904134 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > There is no detection or protection for cascaded CLATs, where if the = IPv6 address is assigned using the Modified EUI-64 identifier to a = downstream CLAT, this will clash with the upstream CLAT if it has also = used the Modified EUI-64 identifier to create its IPv6 address. Avoiding = duplicate addresses was the base justification for assigning the = Modified EUI-64 identifier. [The authors say this configuration is out = of scope, but this situation will likely happen in home use.] Authors aren't alone to note that CLATs won't be cascaded.: - CLATs are IPv6-only upstream and "IPv6 + private IPv4" downstream (=3D> = not cascadable) - Trying to cascade would mean adding a PLAT function in a CLAT node, = but this requires a public IPv4 range in the CLAT node, which is = contrary to 464XLAT assumptions. > Judging by the existing discussion on the WG, I don't think any of = these problems are insoluble. Agreed, but with apparently a different approach. Regards, RD >=20 > regards, > RayH >=20 >=20 > joel jaeggli wrote: >> Reminder, this WGLC runs through the 5th of September. >>=20 >> On 8/21/12 8:45 AM, Fred Baker (fred) wrote: >>> This is to open a two week Working Group last Call on >>>=20 >>> http://tools.ietf.org/html/draft-ietf-v6ops-464xlat >>> "464XLAT: Combination of Stateful and Stateless Translation", = Masataka >>> Mawatari, Masanobu Kawashima, Cameron Byrne, 19-Aug-12 >>>=20 >>> Please read it now. We are interested in, among other things, = technical commentary on the draft and the working group's perception on = its usefulness to its target audience. >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>>=20 >>=20 >>=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail-7--839904134-- From lorenzo@google.com Wed Sep 5 02:00:04 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 113FE21F8627 for ; Wed, 5 Sep 2012 02:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.826 X-Spam-Level: X-Spam-Status: No, score=-102.826 tagged_above=-999 required=5 tests=[AWL=-0.149, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PbbpUiU1qbqh for ; Wed, 5 Sep 2012 02:00:03 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 798B221F8624 for ; Wed, 5 Sep 2012 02:00:03 -0700 (PDT) Received: by ieak13 with SMTP id k13so740091iea.31 for ; Wed, 05 Sep 2012 02:00:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=EaGgat6CK+zhez8C7B/ZOs4LSa8Yo2W3pBjHMS5otS8=; b=M7Zkg/oim0mSrc77Y+Ur+K2u2HqkDv2Oy+8Ft39+Co01o4rQ4X92DEef43ibZioZBy ZQvChuKiUQXrpMngo/Xpg9UZ163W4yZg+qFZFlfmgxrDYcMJRC+tgUkw5uMO0PNbziYr /fXCZDmR9JYRzC5yDnYMBBEea+FhdVi2Nsuj89Tj7UJyevvkWeFmnzyRR/gOsOSQ69QU cZIFPRVVslgZ4UpFyOLQeIUaBeO1MopVWxnk86bcnbrYDG5pRsXTe2NA2PCA8IdWBTPy ZIxKpNVBhmRmelrb8ark4PzJ38T6iB3cw/g+PL4L1ZJ4dIm+e9dCiqNS7vAdh2+Io0W3 lY9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=EaGgat6CK+zhez8C7B/ZOs4LSa8Yo2W3pBjHMS5otS8=; b=XwMwhJ5ttT/eK1yslMnyJkvb6UZG7hVvIh1yskrafdK6gI2iAvP5KttC/rmjYcJ/SM GciwoQzwN1e3ozDbsdWF+3AEE8AjkJh45JQS1RfnF80zRYo99YWqOctm3etzmV7ZCcuA YjDnr7CjTZXfeJEQapcCP0BYxo1zrjgOc3Gw2TwKOcE88HEolf9WysK//WtCApfcMpt9 jgdYlAeTy09wQGfl+IgfhKLnF3fbtze0OV7jVDtf6q9OTQgzfvVgXWtw64umsWNdzQqM UtlaZQTy7kmJv7jTxhX1Zt7/mB8QvgWLjNFYPcPKlRFbnSA6ga2giOW1fhO6QWFTl4uj bCCA== Received: by 10.60.13.231 with SMTP id k7mr16661667oec.74.1346835602677; Wed, 05 Sep 2012 02:00:02 -0700 (PDT) Received: by 10.60.13.231 with SMTP id k7mr16661662oec.74.1346835602592; Wed, 05 Sep 2012 02:00:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.187.8 with HTTP; Wed, 5 Sep 2012 01:59:42 -0700 (PDT) In-Reply-To: <6D4F16ED-11D3-4129-9C9A-E4B0EBD5CDB8@laposte.net> References: <504392E0.8070802@bogus.com> <5046E1F2.4010702@globis.net> <6D4F16ED-11D3-4129-9C9A-E4B0EBD5CDB8@laposte.net> From: Lorenzo Colitti Date: Wed, 5 Sep 2012 17:59:42 +0900 Message-ID: To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=e89a8fb1ee04a9d54f04c8f0997a X-System-Of-Record: true X-Gm-Message-State: ALoCoQmUvENIAiPFnt3KI51N+3+aohXHHEvQm6ENlifJ1RLFAS6JNAJcemZB/3XFByWDiZUrv4QsiksFN6evNIhgTfxwcOAMpJYEbFcgNsoHmFWbHv01n2vhbL2IkPFmvo6rm1UwgL4eUAMxLfRxDOSYvW5EFnTneot02GcAQDkig8RzMq7SMCfIWryd3fVXKXUfriFxcThO Cc: Ray Hunter , v6ops WG Subject: Re: [v6ops] Reminder: draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 09:00:04 -0000 --e89a8fb1ee04a9d54f04c8f0997a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Sep 5, 2012 at 5:41 PM, R=E9mi Despr=E9s = wrote: > Authors aren't alone to note that CLATs won't be cascaded.: > - CLATs are IPv6-only upstream and "IPv6 + private IPv4" downstream (=3D> > not cascadable) > - Trying to cascade would mean adding a PLAT function in a CLAT node, but > this requires a public IPv4 range in the CLAT node, which is contrary to > 464XLAT assumptions. > A lot of things that shouldn't happen happen in real life. No matter what you say, CLATs *will* be cascaded, because users will find ways to cascade them. The only question is: "when (not if) two CLATs are cascaded, will things still work"? --e89a8fb1ee04a9d54f04c8f0997a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Sep 5, 2012 at 5:41 PM, R=E9mi Despr=E9s <despres.remi@lapo= ste.net> wrote:
Authors aren't alone to note that CLATs won't be cascaded.:
- CLATs are IPv6-only upstream and "IPv6 + private IPv4" downstre= am (=3D> not cascadable)
- Trying to cascade would mean adding a PLAT function in a CLAT node, but t= his requires a public IPv4 range in the CLAT node, which is contrary to 464= XLAT assumptions.

A lot of things that shouldn'= ;t happen happen in real life.=A0No matter what you say,=A0CLATs *will* be = cascaded, because users will find ways to cascade them. The only question i= s: "when (not if) two CLATs are cascaded, will things still work"= ?
--e89a8fb1ee04a9d54f04c8f0997a-- From despres.remi@laposte.net Wed Sep 5 02:54:50 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B73F21F861F for ; Wed, 5 Sep 2012 02:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[AWL=0.549, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gfa1AxxjJPnT for ; Wed, 5 Sep 2012 02:54:49 -0700 (PDT) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1343F21F861D for ; Wed, 5 Sep 2012 02:54:48 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2118.sfr.fr (SMTP Server) with ESMTP id 131E37000122; Wed, 5 Sep 2012 11:54:48 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2118.sfr.fr (SMTP Server) with ESMTP id 92A3B70000FD; Wed, 5 Sep 2012 11:54:47 +0200 (CEST) X-SFR-UUID: 20120905095447600.92A3B70000FD@msfrf2118.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-8--835501802 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 5 Sep 2012 11:54:45 +0200 Message-Id: <17A05847-8302-405A-9B7F-CE2E28E59285@laposte.net> References: <504392E0.8070802@bogus.com> <5046E1F2.4010702@globis.net> <6D4F16ED-11D3-4129-9C9A-E4B0EBD5CDB8@laposte.net> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) Cc: Ray Hunter , v6ops WG Subject: Re: [v6ops] Reminder: draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 09:54:50 -0000 --Apple-Mail-8--835501802 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 2012-09-05 10:59, Lorenzo Colitti : > On Wed, Sep 5, 2012 at 5:41 PM, R=E9mi Despr=E9s = wrote: > Authors aren't alone to note that CLATs won't be cascaded.: > - CLATs are IPv6-only upstream and "IPv6 + private IPv4" downstream = (=3D> not cascadable) > - Trying to cascade would mean adding a PLAT function in a CLAT node, = but this requires a public IPv4 range in the CLAT node, which is = contrary to 464XLAT assumptions. >=20 > A lot of things that shouldn't happen happen in real life. No matter = what you say, CLATs *will* be cascaded, because users will find ways to = cascade them. The only question is: "when (not if) two CLATs are = cascaded, will things still work"? OK, fair enough. I have to agree that ways to cascade CLATs can be found. This requires a = IPv6-only router between the two cascaded CLATs, but is possible.=20 Here is an example: CLAT2--v6Link--v6onlyRouter--v4p&v6Link--CLAT1--v6Net--PLAT=20 Such configurations can work with the CLAT-reserved IID ranges now = proposed in = http://www.ietf.org/mail-archive/web/v6ops/current/msg14077.html. For = this, it suffices that the IPv6 prefix delegated to CLAT2 be other than = CLAT1 extended with 0s. Thus IPv6 addresses of CLAT1 and CLAT2 are all = different because they start with different prefixes. This can be documented by saying, for example: "In a CLAT site, prefix delegations to local nodes should be done only = with prefixes that are not the site prefix followed by null bits. This = is to permit IPv6-only subnets that may be configured in such sites to = support CLAT nodes using the same PLAT as the site entrance CLAT." Thoughts? RD= --Apple-Mail-8--835501802 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On Wed, = Sep 5, 2012 at 5:41 PM, R=E9mi Despr=E9s <despres.remi@laposte.net> wrote:
Authors aren't alone to note that CLATs won't be cascaded.:
- CLATs are IPv6-only upstream and "IPv6 + private IPv4" downstream = (=3D> not cascadable)
- Trying to cascade would mean adding a PLAT function in a CLAT node, = but this requires a public IPv4 range in the CLAT node, which is = contrary to 464XLAT assumptions.

A lot of = things that shouldn't happen happen in real life. No matter what = you say, CLATs *will* be cascaded, because users will find ways to = cascade them. The only question is: "when (not if) two CLATs are = cascaded, will things still work"?

OK, fair enough.
I have to agree = that ways to cascade CLATs can be found. This requires a IPv6-only = router between the two cascaded CLATs, but is = possible. 
Here is an = example:

CLAT2--v6Link--v6onlyRouter--v4p&v6L= ink--CLAT1--v6Net--PLAT 

Such = configurations can work with the CLAT-reserved IID ranges now proposed = in = http://www.ietf.org/mail-archive/web/v6ops/current/msg14077.html. = For this, it suffices that the IPv6 prefix delegated to CLAT2 be other = than CLAT1 extended with 0s. Thus IPv6 addresses of CLAT1 and CLAT2 are = all different because they start with different = prefixes.

This can be documented by saying, for = example:
"In a CLAT site, prefix delegations to local nodes = should be done only with prefixes that are not the site prefix followed = by null bits. This is to permit IPv6-only subnets that may be configured = in such sites to support CLAT nodes using the same PLAT as the site = entrance = CLAT."

Thoughts?
RD
= --Apple-Mail-8--835501802-- From gert@space.net Wed Sep 5 03:00:08 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EB7C21F861D for ; Wed, 5 Sep 2012 03:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V+wBivR64Zib for ; Wed, 5 Sep 2012 03:00:07 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id AB34021F8512 for ; Wed, 5 Sep 2012 03:00:06 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 51999F8D76 for ; Wed, 5 Sep 2012 12:00:05 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 28F82F8D6A for ; Wed, 5 Sep 2012 12:00:05 +0200 (CEST) Received: (qmail 64040 invoked by uid 1007); 5 Sep 2012 12:00:05 +0200 Date: Wed, 5 Sep 2012 12:00:05 +0200 From: Gert Doering To: Wuyts Carl Message-ID: <20120905100005.GG13776@Space.Net> References: <867F4B6A1672E541A94676D556793ACD16E4E3748F@MOPESMBX01.eu.thmulti.com> <5047091A.1000800@gmail.com> <867F4B6A1672E541A94676D556793ACD16E4E374AD@MOPESMBX01.eu.thmulti.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <867F4B6A1672E541A94676D556793ACD16E4E374AD@MOPESMBX01.eu.thmulti.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] RFC 6092 - RFC 6204 - ULA : query for clarification/advice X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 10:00:08 -0000 Hi, On Wed, Sep 05, 2012 at 10:14:02AM +0200, Wuyts Carl wrote: > Ack. > Maybe I'm cutting too many corners here, but I'd say that anything without NAT is better in IPv6 :-). > Being operational mainly in residential (managed) gateways, multi-homing is usually not present, but should not be ignored of course. Assume that multihoming will be present before too long - "DSL plus Cable" or "Cable + 3G" or whatever. Two cheap contracts, in the hope that the end result is more reliable than just one. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From Carl.Wuyts@technicolor.com Wed Sep 5 05:06:30 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88CE021F865C; Wed, 5 Sep 2012 05:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.82 X-Spam-Level: X-Spam-Status: No, score=-5.82 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PqIf3cR4c443; Wed, 5 Sep 2012 05:06:30 -0700 (PDT) Received: from na3sys009aog132.obsmtp.com (na3sys009aog132.obsmtp.com [74.125.149.250]) by ietfa.amsl.com (Postfix) with ESMTP id 2E96321F8534; Wed, 5 Sep 2012 05:06:28 -0700 (PDT) Received: from mopesedge02.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob132.postini.com ([74.125.148.12]) with SMTP ID DSNKUEdAP9QDBJ0ook0ORaC2G58Zil5UFubR@postini.com; Wed, 05 Sep 2012 05:06:29 PDT Received: from MOPESMAILHC02.eu.thmulti.com (141.11.100.29) by mopesedge02.eu.thmulti.com (141.11.253.23) with Microsoft SMTP Server (TLS) id 8.3.264.0; Wed, 5 Sep 2012 14:04:45 +0200 Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.14]) by MOPESMAILHC02.eu.thmulti.com ([141.11.100.29]) with mapi; Wed, 5 Sep 2012 14:04:55 +0200 From: Wuyts Carl To: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Date: Wed, 5 Sep 2012 14:04:54 +0200 Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-10.txt Thread-Index: Ac17yPTeN+U2P+MPTQerIyPPTp+71APlLJpw Message-ID: <867F4B6A1672E541A94676D556793ACD16E4E375A3@MOPESMBX01.eu.thmulti.com> References: <20120816160507.28949.98425.idtracker@ietfa.amsl.com> In-Reply-To: <20120816160507.28949.98425.idtracker@ietfa.amsl.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 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-10.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 12:06:30 -0000 Some small remarks on the changes: 1. The document also covers the IP transition technologies. technologies that = were available at the time this document was written. Two transition technologies in 6rd [RFC5969] and DS-Lite [RFC6333] are covered in the document. I'd say it might be useful to include RFC6334 into this sentence as well (a= s being referred as well later in the individual reqs), so something like The document also covers the IP transition technologies. technologies that = were available at the time this document was written. Two transition technologies in 6rd [RFC5969] and DS-Lite [RFC6333/RFC6334] are covered = in the document. 2. WAA-8: The CE router must support the SOL_MAX_RT option [I-D.droms-dhc-dhcpv6-solmaxrt-update] and request the SOL_MAX_RT option in an ORO. I've already sent an email to the DHC WG on this earlier this week. It is = ok for me to refer to a draft, but as there's no number assigned to the opt= ion (yet), no-one can become compliant... Regs Carl -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of i= nternet-drafts@ietf.org Sent: donderdag 16 augustus 2012 18:05 To: i-d-announce@ietf.org Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-10.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the IETF= . Title : Basic Requirements for IPv6 Customer Edge Routers Author(s) : Hemant Singh Wes Beebee Chris Donley Barbara Stark Filename : draft-ietf-v6ops-6204bis-10.txt Pages : 22 Date : 2012-08-16 Abstract: This document specifies requirements for an IPv6 Customer Edge (CE) router. Specifically, the current version of this document focuses on the basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it. The document also covers IP transition technologies. Two transition technologies in RFC 5969's 6rd and RFC 6333's DS-Lite are covered in the document. The document obsoletes RFC 6204, if approved. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-6204bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-6204bis-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From internet-drafts@ietf.org Wed Sep 5 06:56:14 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF7F21F8596; Wed, 5 Sep 2012 06:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.298 X-Spam-Level: X-Spam-Status: No, score=-102.298 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RiexPY7cL+Vh; Wed, 5 Sep 2012 06:56:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C826C21F8599; Wed, 5 Sep 2012 06:56:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120905135613.2634.37095.idtracker@ietfa.amsl.com> Date: Wed, 05 Sep 2012 06:56:13 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-ivi-icmp-address-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 13:56:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Stateless Source Address Mapping for ICMPv6 Packets Author(s) : Xing Li Congxiao Bao Dan Wing Ramji Vaithianathan Geoff Huston Filename : draft-ietf-v6ops-ivi-icmp-address-04.txt Pages : 6 Date : 2012-09-05 Abstract: A stateless IPv4/IPv6 translator may receive ICMPv6 packets containing non IPv4-translatable addresses as the source. These packets should be passed across the translator as ICMP packets directed to the IPv4 destination. This document presents recommendations for source address translation in ICMPv6 headers to handle such cases. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-ivi-icmp-address There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-ivi-icmp-address-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-ivi-icmp-address-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From wdec.ietf@gmail.com Wed Sep 5 08:07:34 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF4F21F84A1 for ; Wed, 5 Sep 2012 08:07:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.732 X-Spam-Level: X-Spam-Status: No, score=-0.732 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43u0C-YdzbtQ for ; Wed, 5 Sep 2012 08:07:33 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0A5B421F8497 for ; Wed, 5 Sep 2012 08:07:32 -0700 (PDT) Received: by eaai11 with SMTP id i11so241976eaa.31 for ; Wed, 05 Sep 2012 08:07:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=aSDa1ajul0MKQNeddL/+3tne+NpEE4GbJ2lvi2yfFOo=; b=tXv2YJKf7J5IIoPZp616rBb9JfCMxwY3suQJ+QC9W/8QFgVVpPwyhXjUG0p/XmQlVB cO94Hx81WT7/qzUPdVFqG3KeNmVswPlj5Q5G3pZqzqdh77U1X/LaZ/iu/rma+4yYj1nR BYMA0qBErGNh0d2rg/1bHgaJuHzlKyJVAVqyF9eg+jEQb49+5Dg/JEjnKt/UDICu32fT 7wn+3QQJjzgsqYezlCGwfa+B2ljAIDmrwga3Ud9pVaUpMSUhWgcyBDsCU1H/cvAIPhN+ khF/6MaUP4Zju6hRadRUeQDmibsMMR9k/YCWPqiuikghPKc7lwQg2xc8lct8PoxZ/znH rI0w== MIME-Version: 1.0 Received: by 10.14.213.201 with SMTP id a49mr31460006eep.4.1346857651897; Wed, 05 Sep 2012 08:07:31 -0700 (PDT) Received: by 10.14.45.68 with HTTP; Wed, 5 Sep 2012 08:07:31 -0700 (PDT) In-Reply-To: <504392E0.8070802@bogus.com> References: <504392E0.8070802@bogus.com> Date: Wed, 5 Sep 2012 17:07:31 +0200 Message-ID: From: Wojciech Dec To: joel jaeggli Content-Type: multipart/alternative; boundary=047d7b621e12e7849d04c8f5bb67 Cc: v6ops WG Subject: Re: [v6ops] Reminder: draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 15:07:34 -0000 --047d7b621e12e7849d04c8f5bb67 Content-Type: text/plain; charset=ISO-8859-1 A handful of comments: 1. Section 5 It would be useful to indicate how this solution differs from MAP-T ( http://tools.ietf.org/html/draft-ietf-softwire-map-01 or http://tools.ietf.org/html/draft-mdt-softwire-map-translation-01), as well as to note the architectural underpinnings of NAT464 of the xlat solution which it effectively validates. In that context the points that IMO could help are: - xlat adopts/assumes exclusively a stateful NAT64 PLAT core (map allows stateless or stateful NAT64) - xlat focuses on deployments where client provisioning of the public IPv4 address is not possible or viable (map requires explicit provisioning, xlat works on defaults) - An alternative of the last point could be that the solution focuses on deployments where the client does not require to be informed of the public IPv4 address, and that default values are assumed. 2. Section 8.2.2 - It would help recasting this section as the "routed" clat mode. I.e the clat is delegated a prefix for NAT64 usage, with this prefix being routed i) by the clat device towards the upstream device ii) routed by and not seen as directly connected by the upstream device. - NAT44 is mentioned as mapping from IPv4 to IPv6. I take that this should be that NAT44 is used to map several IPv4s to one external IPv4. - The figure reflects none of that; it shows 1:1 mapping between IPv4 and IPv6, and not the N:1 mapping between IPv4 and IPv4 which presumably is the role of NAT44. - It is not stated/specified what the external IPv4 address should be, or how it is acquired/picked. This should be defined. - What is currently also missing from this section is how the clat should determine that it is to work in "routed" or "host" mode (section 8.3.2). It is perfectly legitimate to have a PD and not use it for clat. 3. Section 8.3.2 - This section should be recast as xlat (clat) host mode for which the upstream node considers the clat and the upstream device share an "on-link" prefix. - The ND-proxy appears NOT to be required on 3gpp, so it may be worthwhile clarifying that. - Personally I think that adding ND-proxy is undesirable (as also stated by others) and harmful (eg for upstream devices such as BNGs). Devices on non 3gpp network should be directed to use the mode in section 8.3.2, which would eliminate the need to mention proxy-ND at all. Regards, Woj. On 2 September 2012 19:09, joel jaeggli wrote: > Reminder, this WGLC runs through the 5th of September. > > On 8/21/12 8:45 AM, Fred Baker (fred) wrote: > >> This is to open a two week Working Group last Call on >> >> http://tools.ietf.org/html/**draft-ietf-v6ops-464xlat >> "464XLAT: Combination of Stateful and Stateless Translation", Masataka >> Mawatari, Masanobu Kawashima, Cameron Byrne, 19-Aug-12 >> >> Please read it now. We are interested in, among other things, technical >> commentary on the draft and the working group's perception on its >> usefulness to its target audience. >> ______________________________**_________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/**listinfo/v6ops >> >> > ______________________________**_________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/**listinfo/v6ops > --047d7b621e12e7849d04c8f5bb67 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable A handful of comments:

1. Section 5
It would be useful to indicat= e how this solution differs from MAP-T (http://tools.ietf.org/html/draft-ietf-softwi= re-map-01 or http://tools.ietf.org/html/draft-mdt-softwire-map-transl= ation-01), as well as to note the architectural underpinnings of NAT464= of the xlat solution which it effectively validates.

In that context the points that IMO could help are:
- xlat adopts/as= sumes exclusively a stateful NAT64 PLAT core (map allows stateless or state= ful NAT64)
- xlat focuses on deployments where client provisioning of th= e public IPv4 address is not possible or viable (map requires explicit prov= isioning, xlat works on defaults)
- An alternative of the last point could be that the solution focuses on de= ployments where the client does not require to be informed of the public IP= v4 address, and that default values are assumed.

2. Section 8.2.2 - It would help recasting this section as the "routed" clat mode.= I.e the clat is delegated a prefix for NAT64 usage, with this prefix being= routed i) by the clat device towards the upstream device ii) routed by and= not seen as directly connected by the upstream device.
- NAT44 is mentioned as mapping from IPv4 to IPv6. I take that this should = be that NAT44 is used to map several IPv4s to one external IPv4.
- The f= igure reflects none of that; it shows 1:1 mapping between IPv4 and IPv6, an= d not the N:1 mapping between IPv4 and IPv4 which presumably is the role of= NAT44.
- It is not stated/specified what the external IPv4 address should be, or h= ow it is acquired/picked. This should be defined.
- What is currently al= so missing from this section is how the clat should determine that it is to= work in "routed" or "host" mode (section 8.3.2). It is= perfectly legitimate to have a PD and not use it for clat.=A0

3. Section 8.3.2
- This section should be recast as xlat (clat) host= mode for which the upstream node considers the clat and the upstream devic= e share an "on-link" prefix.
- The ND-proxy appears NOT to be = required on 3gpp, so it may be worthwhile clarifying that.
- Personally I think that adding ND-proxy is undesirable (as also stated by= others) and harmful (eg for upstream devices such as BNGs). Devices on non= 3gpp network should be directed to use the mode in section 8.3.2, which wo= uld eliminate the need to mention proxy-ND at all.

Regards,
Woj.



On 2 Septemb= er 2012 19:09, joel jaeggli <joelja@bogus.com> wrote:
Reminder, this WGLC runs through the 5th of September.

On 8/21/12 8:45 AM, Fred Baker (fred) wrote:
This is to open a two week Working Group last Call on

http://tools.ietf.org/html/draft-ietf-v6ops-464xlat
=A0 =A0"464XLAT: Combination of Stateful and Stateless Translation&quo= t;, Masataka
=A0 =A0Mawatari, Masanobu Kawashima, Cameron Byrne, 19-Aug-12

Please read it now. We are interested in, among other things, technical com= mentary on the draft and the working group's perception on its usefulne= ss to its target audience.
_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops


_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

--047d7b621e12e7849d04c8f5bb67-- From v6ops@globis.net Wed Sep 5 09:17:29 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88C4C21F8452 for ; Wed, 5 Sep 2012 09:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.299, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a7dqeDP3IJlS for ; Wed, 5 Sep 2012 09:17:28 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 833C421F844B for ; Wed, 5 Sep 2012 09:17:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id E6DC587005C; Wed, 5 Sep 2012 18:17:08 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RJT85Jb-fETF; Wed, 5 Sep 2012 18:16:38 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id AC66087004D; Wed, 5 Sep 2012 18:16:38 +0200 (CEST) Message-ID: <50477AE0.5050705@globis.net> Date: Wed, 05 Sep 2012 18:16:32 +0200 From: Ray Hunter User-Agent: Postbox 3.0.4 (Macintosh/20120616) MIME-Version: 1.0 To: Lorenzo Colitti References: <504392E0.8070802@bogus.com> <5046E1F2.4010702@globis.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops WG Subject: Re: [v6ops] Reminder: draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 16:17:29 -0000 I'd be very happy with your proposed option 2) Say that if the CLAT wants to share the connection, it SHOULD use DHCPv6 PD, but if that's not available, then the CLAT MAY share a /64 (and potentially say how). > Lorenzo Colitti > 5 September 2012 09:25 > On Wed, Sep 5, 2012 at 2:24 PM, Ray Hunter > wrote: > > 3) Inclusion of ND Proxy [RFC4389] is problematic for 2 reasons: > [...] > > > Agreed. ND proxy is experimental, has problems, and isn't needed for > the use case that the draft cites it for. It should be removed from > the draft. > > 4) Section 8.3.2 does not adequately deprecate single /64 working, > which I consider harmful (as per BCP157). > > > I disagree that it's harmful; actually, I think it's very useful. It > allows a phone to offer IPv6 tethering without the carrier having to > roll out a release 10 network (and having to implement separate > provisioning / billing etc. for tethering). I agree that DHCPv6 PD is > better, but in 3GPP networks that's years away. To understand why, > consider that that most advanced carriers are just now rolling out LTE > networks, and LTE is release 8. > > That said, sharing a /64 is likely to happen whatever we do. So we > have three options: > > 1. Say that /64 sharing shouldn't be done and watch as it happens anyway > 2. Say that if the CLAT wants to share the connection, it SHOULD use > DHCPv6 PD, but if that's not available, then the CLAT MAY share a > /64 (and potentially say how). > 3. Remain silent and punt to another document. > > 5) Assignment of a single special-purpose IANA IID is problematic > for 2 reasons. > > I don't consider the document complies with the spirit of > justifying the Modified EUI-64 identifier via expert review > (RFC5342 Section 5.1), in that the argumentation for assignment is > very opaque, and the use-case is not completely defined e.g. the > IID SHOULD NOT be used for L2 addressing by the CLAT. > > There is no detection or protection for cascaded CLATs, where if > the IPv6 address is assigned using the Modified EUI-64 identifier > to a downstream CLAT, this will clash with the upstream CLAT if it > has also used the Modified EUI-64 identifier to create its IPv6 > address. Avoiding duplicate addresses was the base justification > for assigning the Modified EUI-64 identifier. [The authors say > this configuration is out of scope, but this situation will likely > happen in home use.] > > > Agreed. As is, I think the reserved IID should be removed from the > document. > > Remi's idea of allocating a /24 *block* of interface IDs and have the > CLAT avoid translation by mapping 10.0.0.0/8 > addresses 1:1 into this reserved black has promise, though. From a > technical perspective it's a good solution, but I don't know if IANA > has a) has enough space to allocate a whole /24 pr b) a process for > doing so. > Ray Hunter > 5 September 2012 07:24 > I have read this draft and lurked the on-list discussion. > > Comments based on version 07 > http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-07 > > Following all IMVVHO [I'm no XLAT expert] > > 1) The need for 464XLAT is clear. > > 2) The basic 464xlat architecture is sound and certainly worthy of > advancement and further refinement. > The authors have done a great job on what is a very tricky problem. > > 3) Inclusion of ND Proxy [RFC4389] is problematic for 2 reasons: > Firstly ND Proxy is an experimental protocol, whereas the draft is > aiming to become BCP. > > Secondly, ND Proxy has inadequate loop detection, prevention and > mitigation, for it to be reliably deployed in tethered networks > consisting of multiple devices. If 464XLAT is going to be effective, > it will need to be incorporated into CPE devices. Section 4.1.3.3 of > 4389 is a potential source of oscillation, instability, unpredictable > behaviour, and provides a DoS vector, if 464XLAT were to be widely > incorporated into consumer devices. [Authors claim multiple device > working is out of scope, but this situation will likely happen in home > use) ] > > 4) Section 8.3.2 does not adequately deprecate single /64 working, > which I consider harmful (as per BCP157). > > 5) Assignment of a single special-purpose IANA IID is problematic for > 2 reasons. > > I don't consider the document complies with the spirit of justifying > the Modified EUI-64 identifier via expert review (RFC5342 Section > 5.1), in that the argumentation for assignment is very opaque, and the > use-case is not completely defined e.g. the IID SHOULD NOT be used for > L2 addressing by the CLAT. > > There is no detection or protection for cascaded CLATs, where if the > IPv6 address is assigned using the Modified EUI-64 identifier to a > downstream CLAT, this will clash with the upstream CLAT if it has also > used the Modified EUI-64 identifier to create its IPv6 address. > Avoiding duplicate addresses was the base justification for assigning > the Modified EUI-64 identifier. [The authors say this configuration is > out of scope, but this situation will likely happen in home use.] > > Judging by the existing discussion on the WG, I don't think any of > these problems are insoluble. > > regards, > RayH > > > > ------------------------------------------------------------------------ From fred@cisco.com Wed Sep 5 11:31:57 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA40F21F86B9 for ; Wed, 5 Sep 2012 11:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HijWmfhu-F72 for ; Wed, 5 Sep 2012 11:31:57 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id CD31D21F8669 for ; Wed, 5 Sep 2012 11:31:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=6508; q=dns/txt; s=iport; t=1346869916; x=1348079516; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=E6Cgi6LC9xd7hfw9uNH1vkF6xz29n74J3u9h9DVQAnA=; b=e6jKsgS8LD1JZPSoon4v/DG7zX2r/fwuWQW3PK/sbYy2tGGxHkZqesFJ 8LDMttp+kLWZgeKVy5QWi9ac7bcto2eo4cws0gVPxxvOqFd+ZKVv1tuiz qUS2Kb1SKDtUmPMT8ll6fQ/lrd8AYP49UGPcu5f6bm4b5Dea915CEy7vc 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAEaZR1CtJV2a/2dsb2JhbAA7CrslgQeCIAEBAQMBEgFhCgsCAQhGMiUCBDWHZQaaVaAuixEQhhJgA4gbjT6OM4FngmM X-IronPort-AV: E=Sophos;i="4.80,375,1344211200"; d="scan'208";a="118617662" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 05 Sep 2012 18:31:56 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q85IVtEN026132 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 5 Sep 2012 18:31:56 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.97]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0298.004; Wed, 5 Sep 2012 13:31:55 -0500 From: "Fred Baker (fred)" To: v6ops WG Thread-Topic: [v6ops] Reminder: draft-ietf-v6ops-464xlat WGLC Thread-Index: AQHNi5S52T/lyok6jE+lCzDjfs/5aQ== Date: Wed, 5 Sep 2012 18:31:54 +0000 Message-ID: References: <504392E0.8070802@bogus.com> <448050D4-84F9-4F52-BF7E-347EA451A96C@laposte.net> In-Reply-To: <448050D4-84F9-4F52-BF7E-347EA451A96C@laposte.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.212.142] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19166.001 x-tm-as-result: No--50.556000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: <5A4E4A491FE26D48881B8A3DE4C25888@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] Reminder: draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 18:31:58 -0000 On Sep 3, 2012, at 8:17 AM, R=E9mi Despr=E9s wrote: > If the WGLC is, like an IESG last call, "to make sure that no important c= oncerns have been missed or misunderstood" (RFC 2418), I think we aren't qu= ite at this stage yet. > The current discussions on ND proxy and/or IANA-reserved IIDs is still pr= ogressing, but AFAIK without clear conclusion. The purpose of a WGLC is, as you say, to ensure that important concerns hav= e not been missed or misunderstood. It is not to to prove or create unanimi= ty of viewpoint, although that would be a happy outcome. If in the opinion = of the chairs all opinions have been expressed and new issues are not being= raised, a single person or small group that disagrees with the outcome is = consistent with "rough consensus". I note that this morning we have additional comments from Ray and Woj, whic= h I think need to be heard and addressed. So I'll let the WGLC continue the= remainder of this week to see what additionally shakes loose. Note to the = authors: we will need a -08 as an outcome of the WGLC. Let me see if I can tease apart the issue of an IID, ND Proxy, and DHCP-PD = a bit. I have a view, which I will state, but as a contributor I'm not tryi= ng to impose my view as much as put the arguments all in one place and try = to tease out a resolution. If this helps, it helps, and if it doesn't, forg= et I said it. The purpose of an IID (or an Endpoint ID, which would be an IID used on all= interfaces) is to uniquely identify an interface (or system) within a loca= l domain below the Internet Layer. RFC 4291 describes how one might derive = it from an EUI-48 or EUI-64 number; RFC 3972 describes another mechanism ba= sed on cryptography, RFC 4941 describes a mechanism that uses a random numb= er generator, RFC 4291 and 6052 describe approaches derivative from IPv4 ad= dresses, and there is always the possibility of manual assignment. In no ca= se, as far as I am aware, does one start from the IID and generate a lower = layer address from it; the lower layer address, if it is used at all, is on= ly used as input to the IID generation algorithm. Regardless of the way the= IID is formed, it has some possibility of being a duplicate address, and t= he wise implementation will take the time to verify its uniqueness. Since t= here are so many ways an IID can be created, I personally find little use i= n mandating anything specific about it unless there is an interoperability = requirement in a specific implementation, such as exists in SEND. So the entire debate about an IANA-specified IID is, frankly, lost on me. I= have difficulty formulating the argument. It is, by any other description,= a more-or-less-random 64 bit number, and the only use of it once it is cre= ated is as a search key in the neighbor table. Regardless of how the IID is formed, there is a question of how the network= is formed. If we define a local network to include one or more router inte= rfaces connected to a set of clients over some form of media, there are two= broad classes of media - ones in which all clients communicate directly wi= th each other at the Internet Layer (such as in an Ethernet, switched or ot= herwise), and ones in which they communicate at the IP layer though an inte= rmediate device (such as a BRAS or CMTS). Neighbor Discovery is designed fo= r the Broadcast Multi-access case, and ND Proxy is designed for the Non-Bro= adcast Multi-access case. In both cases, IPv6 and Neighbor Discovery (direc= t or proxy) assume that, from the perspective of any given interface in tha= t local network, the local network operates as a simple star or multi-star = - traffic sent from one interface to another in the local network travels i= n sequence, may be lost en route, and apart from loss is conveyed in a reas= onably predictable fashion. It is possible for the client device to act as a switch or repeater to othe= r devices beyond it; analytically, the device might be viewed as incorporat= ing a switch for which the device is itself one of the clients. In this cas= e, the cascaded devices beyond it appear to be on the same local network as= the client itself. From an IP perspective, one would expect it to use the = same subnet prefix and require the use of ND or ND Proxy just as the client= itself does. The other view of the device is that it operates, for cascaded devices, not= as a switch but as a router. In this case, it needs a prefix assigned to i= t for the cascaded LAN or LANs, and DHCP-PD is a reasonable means for doing= so. So to me, the question of ND Proxy vs DHCP-PD comes down to the intended st= ructure of the network and the services it offers. If the structure of the = service provider's access network is non-broadcast multi-access, which I un= derstand wireless networks such as 3G/4G and LTE to be, then it either requ= ires the use of an ND Proxy or it must assign its client's addresses, in th= e interest of uniqueness - and DHCPv6 would still require DAD of the link-l= ocal address, which implies ND Proxy. If the service provides no capability= for cascading client networks, then the model of masquerade of an incorpor= ated switch, or stateful IPv6/IPv6 translation, is required to work around = the limitations of the service provider's service. If the service provider = is offering a service of connecting client networks - for which homenet bec= omes directly applicable - then DHCP-PD and some form of routing infrastruc= ture (at least dynamic static routing) becomes preferable for manageability= reasons. Following that line of reasoning, I might suggest that the document describ= e the non-broadcast multi-access nature of the service provider access netw= ork and require the implementation of ND Proxy within it, which I think it = already does. It might go on to describe the nature of the client networks = it expects, offering three cases - no cascaded devices (the service is to a= contracted instrument), a mobile hot spot (a small number of cascaded devi= ces treated as part of the service provider access network and uses the cli= ent instrument as a switch), or a cascaded network (which uses the client i= nstrument as a router, which in turn implies the use of DHCP-PD).=20 If that were done, would the proponents of the various views consider their= viewpoints adequately addressed?= From cb.list6@gmail.com Wed Sep 5 12:56:31 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45C6121F86D3 for ; Wed, 5 Sep 2012 12:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pGPMPAUAj1yp for ; Wed, 5 Sep 2012 12:56:30 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id E010F21F86D1 for ; Wed, 5 Sep 2012 12:56:29 -0700 (PDT) Received: by lahm15 with SMTP id m15so683431lah.31 for ; Wed, 05 Sep 2012 12:56:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=BHyqAkL33+3+C80ui+gXdsJ0BIBvkpIn1Q8riRgk0+Y=; b=hCC+G8ITfVKGhcBrcQpTFtxOAzuHu4WvHDyb3jelWR1OO4m2PWW4hiLvxnBd46LtMe OkM2MiqySRIPQqp85+SNq1abfnl4CrFHX0fQnsK9q3ufFkX7nOpsbVFzN+cb9ujGcLXs rU77LJgGg5E8qNH6Hqi7f/Y5v9KPcLHhiIE0Q0HAoQ/LHJiQGL1DFvNaApLjkqUdryei sDVY0qjumlKzJr7gtynJwHPRgvXunqbVsKMWxrlzYvVL9cj6i8oytBZynBJbk2RoaUDp 60bteEZXRftTUUjGW5dpAOdxIJqPigRUAjW9RaRaCpFqH62ZypgwfQUa5GRV1CVVv/CX kRXg== MIME-Version: 1.0 Received: by 10.152.132.133 with SMTP id ou5mr21228289lab.45.1346874988766; Wed, 05 Sep 2012 12:56:28 -0700 (PDT) Received: by 10.112.49.66 with HTTP; Wed, 5 Sep 2012 12:56:28 -0700 (PDT) In-Reply-To: References: <504392E0.8070802@bogus.com> <448050D4-84F9-4F52-BF7E-347EA451A96C@laposte.net> Date: Wed, 5 Sep 2012 12:56:28 -0700 Message-ID: From: Cameron Byrne To: "Fred Baker (fred)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops WG Subject: Re: [v6ops] Reminder: draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 19:56:31 -0000 On Wed, Sep 5, 2012 at 11:31 AM, Fred Baker (fred) wrote: > > On Sep 3, 2012, at 8:17 AM, R=E9mi Despr=E9s wrote: > >> If the WGLC is, like an IESG last call, "to make sure that no important = concerns have been missed or misunderstood" (RFC 2418), I think we aren't q= uite at this stage yet. >> The current discussions on ND proxy and/or IANA-reserved IIDs is still p= rogressing, but AFAIK without clear conclusion. > > > The purpose of a WGLC is, as you say, to ensure that important concerns h= ave not been missed or misunderstood. It is not to to prove or create unani= mity of viewpoint, although that would be a happy outcome. If in the opinio= n of the chairs all opinions have been expressed and new issues are not bei= ng raised, a single person or small group that disagrees with the outcome i= s consistent with "rough consensus". > > I note that this morning we have additional comments from Ray and Woj, wh= ich I think need to be heard and addressed. So I'll let the WGLC continue t= he remainder of this week to see what additionally shakes loose. Note to th= e authors: we will need a -08 as an outcome of the WGLC. > > > > Let me see if I can tease apart the issue of an IID, ND Proxy, and DHCP-P= D a bit. I have a view, which I will state, but as a contributor I'm not tr= ying to impose my view as much as put the arguments all in one place and tr= y to tease out a resolution. If this helps, it helps, and if it doesn't, fo= rget I said it. > > > The purpose of an IID (or an Endpoint ID, which would be an IID used on a= ll interfaces) is to uniquely identify an interface (or system) within a lo= cal domain below the Internet Layer. RFC 4291 describes how one might deriv= e it from an EUI-48 or EUI-64 number; RFC 3972 describes another mechanism = based on cryptography, RFC 4941 describes a mechanism that uses a random nu= mber generator, RFC 4291 and 6052 describe approaches derivative from IPv4 = addresses, and there is always the possibility of manual assignment. In no = case, as far as I am aware, does one start from the IID and generate a lowe= r layer address from it; the lower layer address, if it is used at all, is = only used as input to the IID generation algorithm. Regardless of the way t= he IID is formed, it has some possibility of being a duplicate address, and= the wise implementation will take the time to verify its uniqueness. Since= there are so many ways an IID can be created, I personally find little use= in mandating anything specific about it unless there is an interoperabilit= y requirement in a specific implementation, such as exists in SEND. > > So the entire debate about an IANA-specified IID is, frankly, lost on me.= I have difficulty formulating the argument. It is, by any other descriptio= n, a more-or-less-random 64 bit number, and the only use of it once it is c= reated is as a search key in the neighbor table. > > > Regardless of how the IID is formed, there is a question of how the netwo= rk is formed. If we define a local network to include one or more router in= terfaces connected to a set of clients over some form of media, there are t= wo broad classes of media - ones in which all clients communicate directly = with each other at the Internet Layer (such as in an Ethernet, switched or = otherwise), and ones in which they communicate at the IP layer though an in= termediate device (such as a BRAS or CMTS). Neighbor Discovery is designed = for the Broadcast Multi-access case, and ND Proxy is designed for the Non-B= roadcast Multi-access case. In both cases, IPv6 and Neighbor Discovery (dir= ect or proxy) assume that, from the perspective of any given interface in t= hat local network, the local network operates as a simple star or multi-sta= r - traffic sent from one interface to another in the local network travels= in sequence, may be lost en route, and apart from loss is conveyed in a re= asonably predictable fashion. > > It is possible for the client device to act as a switch or repeater to ot= her devices beyond it; analytically, the device might be viewed as incorpor= ating a switch for which the device is itself one of the clients. In this c= ase, the cascaded devices beyond it appear to be on the same local network = as the client itself. From an IP perspective, one would expect it to use th= e same subnet prefix and require the use of ND or ND Proxy just as the clie= nt itself does. > > The other view of the device is that it operates, for cascaded devices, n= ot as a switch but as a router. In this case, it needs a prefix assigned to= it for the cascaded LAN or LANs, and DHCP-PD is a reasonable means for doi= ng so. > > So to me, the question of ND Proxy vs DHCP-PD comes down to the intended = structure of the network and the services it offers. If the structure of th= e service provider's access network is non-broadcast multi-access, which I = understand wireless networks such as 3G/4G and LTE to be, then it either re= quires the use of an ND Proxy or it must assign its client's addresses, in = the interest of uniqueness - and DHCPv6 would still require DAD of the link= -local address, which implies ND Proxy. If the service provides no capabili= ty for cascading client networks, then the model of masquerade of an incorp= orated switch, or stateful IPv6/IPv6 translation, is required to work aroun= d the limitations of the service provider's service. If the service provide= r is offering a service of connecting client networks - for which homenet b= ecomes directly applicable - then DHCP-PD and some form of routing infrastr= ucture (at least dynamic static routing) becomes preferable for manageabili= ty reasons. > > > Following that line of reasoning, I might suggest that the document descr= ibe the non-broadcast multi-access nature of the service provider access ne= twork and require the implementation of ND Proxy within it, which I think i= t already does. It might go on to describe the nature of the client network= s it expects, offering three cases - no cascaded devices (the service is to= a contracted instrument), a mobile hot spot (a small number of cascaded de= vices treated as part of the service provider access network and uses the c= lient instrument as a switch), or a cascaded network (which uses the client= instrument as a router, which in turn implies the use of DHCP-PD). > > If that were done, would the proponents of the various views consider the= ir viewpoints adequately addressed? IMHO, trying to define how to construct IPv6 access networks sharing a /64 is out of scope for 464XLAT. As part of the inventing the 464XLAT service and how we could specify it from the ground up, we found it required to speak to ND proxy, Remi's reserved IID solutions, and others ... coming from 10,000 meters up and going back down to RFC level, at this point... i do not believe we need to specify these methods of extending a /64 or reserving IANA resources. Remi's and others ideas have been clever, and i believe they can be re-spun as more generic contributions to v6ops or HOMENET My hope is that the -08 can reach rough consensus by just saying that the CLAT SHOULD do DHCP-PD to acquire a /64 to be used exclusively for stateless translation. If DHCP-PD is not available, the CLAT MAY share the WAN /64 to the LAN in an appropriate way that does not cause address conflicts or loops. I believe this is the direction that Ray and Lorenzo have said they support. And just leave it at that. Today, /64 is shared between WAN and LAN in many ways, some are IETF specified (ND Proxy) and some are not such as behaving as Switch/Router. In the case of the Android CLAT code that was submitted to AOSP, the /64 is simply copied from the WAN 3G/4G interfaces to the LAN. No magic. No ND Proxy. No DHCP. But, it works for all known cases. 464XLAT, as stated in the introduction, is just combining stateless and stateful protocol translation to overcome some gaps that inhibit wider IPv6 adoption and IPv4 sunsetting. It is not anything else. CB From fibrib@gmail.com Wed Sep 5 18:56:59 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB60C21F84DA for ; Wed, 5 Sep 2012 18:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.732 X-Spam-Level: X-Spam-Status: No, score=-0.732 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bSa110PQpPlM for ; Wed, 5 Sep 2012 18:56:59 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8EEC221F84E2 for ; Wed, 5 Sep 2012 18:56:58 -0700 (PDT) Received: by eekb45 with SMTP id b45so510035eek.31 for ; Wed, 05 Sep 2012 18:56:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=alx2oKk6WtoGfnDXdtbwpbiExRn7WOLg1DoUvdHstGU=; b=XlJRrRFuwg7ummhPFYwIzcAGc6J0nnwht2HyeuQGtp+jd6JrMHfCFsL4ayaovGldZA SVxyKo50VPapSMGgLU+0zy4qmx4joXxZB9Dx/cHiO3wGZlF8JZrlI7u0VvZUtDNKreeB 1wxYvcrxYorP04rziTtR4RkZnGGCVH2N/sfzxKKUawOrOqsPUcMzFJoMmqen0P05Uijy Bor6QUI4eLZm1ZM9dsM4F/6qz1RJw0QnsM1WO6+EPFCJiL6jscur1VTL8EvDb/IOT7WY nibjtMU3/9KI6luuEu4cgvynJ7Jjst/vrBMUHxI0HKNRlH5GCFZZFIFa2oE/FhsHtDzq yN7g== MIME-Version: 1.0 Received: by 10.14.202.66 with SMTP id c42mr598479eeo.35.1346896617774; Wed, 05 Sep 2012 18:56:57 -0700 (PDT) Received: by 10.14.97.9 with HTTP; Wed, 5 Sep 2012 18:56:57 -0700 (PDT) In-Reply-To: References: <504392E0.8070802@bogus.com> Date: Thu, 6 Sep 2012 10:56:57 +0900 Message-ID: From: Maoke To: Wojciech Dec Content-Type: multipart/alternative; boundary=047d7b33daf4739f9d04c8feced4 Cc: v6ops WG Subject: Re: [v6ops] Reminder: draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 01:56:59 -0000 --047d7b33daf4739f9d04c8feced4 Content-Type: text/plain; charset=ISO-8859-1 hi Woj, +1 on your comment 1. 2012/9/6 Wojciech Dec > A handful of comments: > > 1. Section 5 > It would be useful to indicate how this solution differs from MAP-T ( > http://tools.ietf.org/html/draft-ietf-softwire-map-01 or > http://tools.ietf.org/html/draft-mdt-softwire-map-translation-01), as > well as to note the architectural underpinnings of NAT464 of the xlat > solution which it effectively validates. > > In that context the points that IMO could help are: > - xlat adopts/assumes exclusively a stateful NAT64 PLAT core (map allows > stateless or stateful NAT64) > - xlat focuses on deployments where client provisioning of the public IPv4 > address is not possible or viable (map requires explicit provisioning, xlat > works on defaults) > - An alternative of the last point could be that the solution focuses on > deployments where the client does not require to be informed of the public > IPv4 address, and that default values are assumed. > i am not sure but have another observation: 464xlat, using existing mechanism of RFC6145/6146 and address format of RFC6052, is used in within the same address planning autonomous system with the same prefix for the RFC6052 usage; while MAP can work in a "MAP domain" across over different prefixes even belonging to different autonomous systems with the cost of distributing rules among involved nodes. - maoke > > 2. Section 8.2.2 > - It would help recasting this section as the "routed" clat mode. I.e the > clat is delegated a prefix for NAT64 usage, with this prefix being routed > i) by the clat device towards the upstream device ii) routed by and not > seen as directly connected by the upstream device. > - NAT44 is mentioned as mapping from IPv4 to IPv6. I take that this should > be that NAT44 is used to map several IPv4s to one external IPv4. > - The figure reflects none of that; it shows 1:1 mapping between IPv4 and > IPv6, and not the N:1 mapping between IPv4 and IPv4 which presumably is the > role of NAT44. > - It is not stated/specified what the external IPv4 address should be, or > how it is acquired/picked. This should be defined. > - What is currently also missing from this section is how the clat should > determine that it is to work in "routed" or "host" mode (section 8.3.2). It > is perfectly legitimate to have a PD and not use it for clat. > > 3. Section 8.3.2 > - This section should be recast as xlat (clat) host mode for which the > upstream node considers the clat and the upstream device share an "on-link" > prefix. > - The ND-proxy appears NOT to be required on 3gpp, so it may be worthwhile > clarifying that. > - Personally I think that adding ND-proxy is undesirable (as also stated > by others) and harmful (eg for upstream devices such as BNGs). Devices on > non 3gpp network should be directed to use the mode in section 8.3.2, which > would eliminate the need to mention proxy-ND at all. > > Regards, > Woj. > > > > On 2 September 2012 19:09, joel jaeggli wrote: > >> Reminder, this WGLC runs through the 5th of September. >> >> On 8/21/12 8:45 AM, Fred Baker (fred) wrote: >> >>> This is to open a two week Working Group last Call on >>> >>> http://tools.ietf.org/html/**draft-ietf-v6ops-464xlat >>> "464XLAT: Combination of Stateful and Stateless Translation", Masataka >>> Mawatari, Masanobu Kawashima, Cameron Byrne, 19-Aug-12 >>> >>> Please read it now. We are interested in, among other things, technical >>> commentary on the draft and the working group's perception on its >>> usefulness to its target audience. >>> ______________________________**_________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/**listinfo/v6ops >>> >>> >> ______________________________**_________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/**listinfo/v6ops >> > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --047d7b33daf4739f9d04c8feced4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
hi Woj,
=A0
+1 on your comment 1.
2012/9/6 Wojciech Dec <wdec.ietf@gmail.com&g= t;
A handful of comments:

1. Section 5
It would be = useful to indicate how this solution differs from MAP-T (http://to= ols.ietf.org/html/draft-ietf-softwire-map-01 or htt= p://tools.ietf.org/html/draft-mdt-softwire-map-translation-01), as well= as to note the architectural underpinnings of NAT464 of the xlat solution = which it effectively validates.

In that context the points that IMO could help are:
- xlat adopts/as= sumes exclusively a stateful NAT64 PLAT core (map allows stateless or state= ful NAT64)
- xlat focuses on deployments where client provisioning of th= e public IPv4 address is not possible or viable (map requires explicit prov= isioning, xlat works on defaults)
- An alternative of the last point could be that the solution focuses on de= ployments where the client does not require to be informed of the public IP= v4 address, and that default values are assumed.
=A0
i am not sure but have another observation: 464xlat, using ex= isting mechanism of RFC6145/6146 and address format of RFC6052, is used in = within the same address planning autonomous system with the same prefix for= the RFC6052 usage; while MAP can work in a "MAP domain" across o= ver different prefixes even belonging to different autonomous systems with = the cost of distributing rules among involved nodes.
=A0
- maoke
=A0

2. Secti= on 8.2.2
- It would help recasting this section as the "routed" clat mode.= I.e the clat is delegated a prefix for NAT64 usage, with this prefix being= routed i) by the clat device towards the upstream device ii) routed by and= not seen as directly connected by the upstream device.
- NAT44 is mentioned as mapping from IPv4 to IPv6. I take that this should = be that NAT44 is used to map several IPv4s to one external IPv4.
- The f= igure reflects none of that; it shows 1:1 mapping between IPv4 and IPv6, an= d not the N:1 mapping between IPv4 and IPv4 which presumably is the role of= NAT44.
- It is not stated/specified what the external IPv4 address should be, or h= ow it is acquired/picked. This should be defined.
- What is currently al= so missing from this section is how the clat should determine that it is to= work in "routed" or "host" mode (section 8.3.2). It is= perfectly legitimate to have a PD and not use it for clat.=A0

3. Section 8.3.2
- This section should be recast as xlat (clat) host= mode for which the upstream node considers the clat and the upstream devic= e share an "on-link" prefix.
- The ND-proxy appears NOT to be = required on 3gpp, so it may be worthwhile clarifying that.
- Personally I think that adding ND-proxy is undesirable (as also stated by= others) and harmful (eg for upstream devices such as BNGs). Devices on non= 3gpp network should be directed to use the mode in section 8.3.2, which wo= uld eliminate the need to mention proxy-ND at all.

Regards,
Woj.



On 2 Septemb= er 2012 19:09, joel jaeggli <joelja@bogus.com> wrote:
Reminder, this WGLC runs through the 5th of September.

On 8/21/12 8:45 AM, Fred Baker (fred) wrote:
This is to open a two week Working Group last Call on

http://tools.ietf.org/html/draft-ietf-v6ops-464xlat
=A0 =A0"464XLAT: Combination of Stateful and Stateless Translation&quo= t;, Masataka
=A0 =A0Mawatari, Masanobu Kawashima, Cameron Byrne, 19-Aug-12

Please read it now. We are interested in, among other things, technical com= mentary on the draft and the working group's perception on its usefulne= ss to its target audience.
_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops


_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops


_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops


--047d7b33daf4739f9d04c8feced4-- From cb.list6@gmail.com Wed Sep 5 19:43:19 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30FB221F8526 for ; Wed, 5 Sep 2012 19:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NBuO90k1rMVZ for ; Wed, 5 Sep 2012 19:43:18 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id DD70421F8525 for ; Wed, 5 Sep 2012 19:43:17 -0700 (PDT) Received: by lahm15 with SMTP id m15so874454lah.31 for ; Wed, 05 Sep 2012 19:43:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eOsprMDNzRptQqvoNjIGpXXy2iqeC68vDpkUrVOFzs8=; b=FwNSpE+U1VJJKnAK/cw5IXaJ755xZ2h2DYK6G+st9jcolElC4FsDqEaPOaQW+NEZbB zS/PH8ah6sgRskVE12o85ppv+YLgWS1H7ev2RS9VuKHKuOB4Qvp9S3oHAqDTBgzHgNnQ ZDqtoKst6j5VrH9XiOTbM7DvN6p0JNK0lrjIDnJsOu3faY0L1ehd018qDrIJENRPvZQ8 GSDkEKqBm96GUcTZXD1cVNkIklw+4XMLBoj5XYZrNKZAYj/tVGtHGAqH0Pf72RsLlohB TCCmi2lVzZD1VfBheULXbmFJOuXO4PDNaA6pm+78gJIIDsiFTbdyHFuj3Mh2A8BeOWY/ Ei5g== MIME-Version: 1.0 Received: by 10.112.30.34 with SMTP id p2mr306116lbh.85.1346899396750; Wed, 05 Sep 2012 19:43:16 -0700 (PDT) Received: by 10.112.49.66 with HTTP; Wed, 5 Sep 2012 19:43:16 -0700 (PDT) In-Reply-To: References: <504392E0.8070802@bogus.com> Date: Wed, 5 Sep 2012 19:43:16 -0700 Message-ID: From: Cameron Byrne To: Wojciech Dec Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops WG Subject: Re: [v6ops] Reminder: draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 02:43:19 -0000 Woj, On Wed, Sep 5, 2012 at 8:07 AM, Wojciech Dec wrote: > A handful of comments: > > 1. Section 5 > It would be useful to indicate how this solution differs from MAP-T > (http://tools.ietf.org/html/draft-ietf-softwire-map-01 or > http://tools.ietf.org/html/draft-mdt-softwire-map-translation-01), as well > as to note the architectural underpinnings of NAT464 of the xlat solution > which it effectively validates. > No, we will not be casting 464XLAT in light of other solutions. The WG, AFAIK, concluded this here http://www.ietf.org/mail-archive/web/v6ops/current/msg13714.html And, AFAIK, MAP-T is not longer an actively pursued solution. A coin was flipped, and the IETF moved on. > In that context the points that IMO could help are: > - xlat adopts/assumes exclusively a stateful NAT64 PLAT core (map allows > stateless or stateful NAT64) MAP allows stateful sharing of public IPv4 addresses on NAT64? I am not sure how that can be given that Softwires does not have a charter for stateful solutions. And, AFAIK, the current MAP document does not reflect any stateful work for sharing public IPv4 addresses. Doing a search on draft-ietf-softwire-map-02 shows no references to RFC 6145 and RFC 6146, which are the core of 464XLAT. > - xlat focuses on deployments where client provisioning of the public IPv4 > address is not possible or viable (map requires explicit provisioning, xlat > works on defaults) Yes. i don't follow the rest of the comments and imagine the discussion will shift after we release -08 where perhaps these details are purposefully not specified and left to implementation discretion. CB > - An alternative of the last point could be that the solution focuses on > deployments where the client does not require to be informed of the public > IPv4 address, and that default values are assumed. > > 2. Section 8.2.2 > - It would help recasting this section as the "routed" clat mode. I.e the > clat is delegated a prefix for NAT64 usage, with this prefix being routed i) > by the clat device towards the upstream device ii) routed by and not seen as > directly connected by the upstream device. > - NAT44 is mentioned as mapping from IPv4 to IPv6. I take that this should > be that NAT44 is used to map several IPv4s to one external IPv4. > - The figure reflects none of that; it shows 1:1 mapping between IPv4 and > IPv6, and not the N:1 mapping between IPv4 and IPv4 which presumably is the > role of NAT44. > - It is not stated/specified what the external IPv4 address should be, or > how it is acquired/picked. This should be defined. > - What is currently also missing from this section is how the clat should > determine that it is to work in "routed" or "host" mode (section 8.3.2). It > is perfectly legitimate to have a PD and not use it for clat. > > 3. Section 8.3.2 > - This section should be recast as xlat (clat) host mode for which the > upstream node considers the clat and the upstream device share an "on-link" > prefix. > - The ND-proxy appears NOT to be required on 3gpp, so it may be worthwhile > clarifying that. > - Personally I think that adding ND-proxy is undesirable (as also stated by > others) and harmful (eg for upstream devices such as BNGs). Devices on non > 3gpp network should be directed to use the mode in section 8.3.2, which > would eliminate the need to mention proxy-ND at all. > > Regards, > Woj. > > > > > On 2 September 2012 19:09, joel jaeggli wrote: >> >> Reminder, this WGLC runs through the 5th of September. >> >> On 8/21/12 8:45 AM, Fred Baker (fred) wrote: >>> >>> This is to open a two week Working Group last Call on >>> >>> http://tools.ietf.org/html/draft-ietf-v6ops-464xlat >>> "464XLAT: Combination of Stateful and Stateless Translation", Masataka >>> Mawatari, Masanobu Kawashima, Cameron Byrne, 19-Aug-12 >>> >>> Please read it now. We are interested in, among other things, technical >>> commentary on the draft and the working group's perception on its usefulness >>> to its target audience. >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From fibrib@gmail.com Wed Sep 5 21:04:48 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF6821F852D for ; Wed, 5 Sep 2012 21:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.565 X-Spam-Level: X-Spam-Status: No, score=-1.565 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i8-hvADB8iMG for ; Wed, 5 Sep 2012 21:04:47 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id C5AEC21F852E for ; Wed, 5 Sep 2012 21:04:46 -0700 (PDT) Received: by eekb45 with SMTP id b45so528893eek.31 for ; Wed, 05 Sep 2012 21:04:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=e1nNhpeGr2r6S5IVvHCUzUnyYyP+fCZeKQ6XdDz3oX0=; b=vxsNWZKKoC10E92odDTWT6GUUVJNHZMtXdsyVeLIDE2RnxsxKjg79hxu43+PtSuF5p 5xhzjAN5faCcmVspsc5bQtbL50utjEitBKDjf5M2/Yvr461DfpzIJ292l9001f+tA3wA jYP+E1+pqMdYD2vD76wsoRbEedgUhN2Uq3d6Eg0AYs27qEP2R7eskwgVXVingfyV7LAe wYCDck52R1VY8eADYMBqQijNruV1D9Q5yoRL2tKl/JrAyq0rpdooI6KpONDmNN/icufM FWlSyUPtSM74gSyDEc9Pt9JmcvTCGtn3vnvoUIfQvu0jmelc2T3fw9IXalJgI59Agyr3 PRWg== MIME-Version: 1.0 Received: by 10.14.175.7 with SMTP id y7mr914281eel.29.1346904285912; Wed, 05 Sep 2012 21:04:45 -0700 (PDT) Received: by 10.14.97.9 with HTTP; Wed, 5 Sep 2012 21:04:45 -0700 (PDT) In-Reply-To: References: <504392E0.8070802@bogus.com> Date: Thu, 6 Sep 2012 13:04:45 +0900 Message-ID: From: Maoke To: Cameron Byrne Content-Type: multipart/alternative; boundary=047d7b62253882200904c9009774 Cc: v6ops WG Subject: Re: [v6ops] Reminder: draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 04:04:48 -0000 --047d7b62253882200904c9009774 Content-Type: text/plain; charset=ISO-8859-1 Cameron, 2012/9/6 Cameron Byrne > Woj, > > On Wed, Sep 5, 2012 at 8:07 AM, Wojciech Dec wrote: > > A handful of comments: > > > > 1. Section 5 > > It would be useful to indicate how this solution differs from MAP-T > > (http://tools.ietf.org/html/draft-ietf-softwire-map-01 or > > http://tools.ietf.org/html/draft-mdt-softwire-map-translation-01), as > well > > as to note the architectural underpinnings of NAT464 of the xlat solution > > which it effectively validates. > > > > No, we will not be casting 464XLAT in light of other solutions. The > WG, AFAIK, concluded this here > http://www.ietf.org/mail-archive/web/v6ops/current/msg13714.html > And, AFAIK, MAP-T is not longer an actively pursued solution. A coin > was flipped, and the IETF moved on. > i agree that 464xlat document doesn't need to compare with any other solutions. however, i guess you also support Woj's effort of sharing the understanding. and AFAIK, MAP-T, will be still the softwire WG document even the status might be experimental. further, in the MAP deployment draft that i am participating, we are obliged to include the understandings in order that the operators reading the deployment guidance may get a clear big picture of the relationship among all the stuffs in the solution space. i would like to share another point: maybe some people think the about one year effort of making MAP-T and -E a unified work is vain, maybe some think we should to do the coin toss one year ago, i don't agree. the effort of unification made out a common address mapping algorithm and the unified format, enabling operators change their mode of transport once they understand somewhere the double translation, compatible with single translation, is needed in their system architecture. such an understanding on the necessity of translation, AFAIK, is also significant to those who would like to deploy 464xlat. ;-) - maoke > > > In that context the points that IMO could help are: > > - xlat adopts/assumes exclusively a stateful NAT64 PLAT core (map allows > > stateless or stateful NAT64) > > MAP allows stateful sharing of public IPv4 addresses on NAT64? I am > not sure how that can be given that Softwires does not have a charter > for stateful solutions. And, AFAIK, the current MAP document does not > reflect any stateful work for sharing public IPv4 addresses. Doing a > search on draft-ietf-softwire-map-02 shows no references to RFC 6145 > and RFC 6146, which are the core of 464XLAT. > > > - xlat focuses on deployments where client provisioning of the public > IPv4 > > address is not possible or viable (map requires explicit provisioning, > xlat > > works on defaults) > > Yes. > > i don't follow the rest of the comments and imagine the discussion > will shift after we release -08 where perhaps these details are > purposefully not specified and left to implementation discretion. > > CB > > > - An alternative of the last point could be that the solution focuses on > > deployments where the client does not require to be informed of the > public > > IPv4 address, and that default values are assumed. > > > > 2. Section 8.2.2 > > - It would help recasting this section as the "routed" clat mode. I.e the > > clat is delegated a prefix for NAT64 usage, with this prefix being > routed i) > > by the clat device towards the upstream device ii) routed by and not > seen as > > directly connected by the upstream device. > > - NAT44 is mentioned as mapping from IPv4 to IPv6. I take that this > should > > be that NAT44 is used to map several IPv4s to one external IPv4. > > - The figure reflects none of that; it shows 1:1 mapping between IPv4 and > > IPv6, and not the N:1 mapping between IPv4 and IPv4 which presumably is > the > > role of NAT44. > > - It is not stated/specified what the external IPv4 address should be, or > > how it is acquired/picked. This should be defined. > > - What is currently also missing from this section is how the clat should > > determine that it is to work in "routed" or "host" mode (section 8.3.2). > It > > is perfectly legitimate to have a PD and not use it for clat. > > > > 3. Section 8.3.2 > > - This section should be recast as xlat (clat) host mode for which the > > upstream node considers the clat and the upstream device share an > "on-link" > > prefix. > > - The ND-proxy appears NOT to be required on 3gpp, so it may be > worthwhile > > clarifying that. > > - Personally I think that adding ND-proxy is undesirable (as also stated > by > > others) and harmful (eg for upstream devices such as BNGs). Devices on > non > > 3gpp network should be directed to use the mode in section 8.3.2, which > > would eliminate the need to mention proxy-ND at all. > > > > Regards, > > Woj. > > > > > > > > > > On 2 September 2012 19:09, joel jaeggli wrote: > >> > >> Reminder, this WGLC runs through the 5th of September. > >> > >> On 8/21/12 8:45 AM, Fred Baker (fred) wrote: > >>> > >>> This is to open a two week Working Group last Call on > >>> > >>> http://tools.ietf.org/html/draft-ietf-v6ops-464xlat > >>> "464XLAT: Combination of Stateful and Stateless Translation", > Masataka > >>> Mawatari, Masanobu Kawashima, Cameron Byrne, 19-Aug-12 > >>> > >>> Please read it now. We are interested in, among other things, technical > >>> commentary on the draft and the working group's perception on its > usefulness > >>> to its target audience. > >>> _______________________________________________ > >>> v6ops mailing list > >>> v6ops@ietf.org > >>> https://www.ietf.org/mailman/listinfo/v6ops > >>> > >> > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops > > > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --047d7b62253882200904c9009774 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cameron,
2012/9/6 Cameron Byrne <cb.list6@= gmail.com>
Woj,

On Wed, Sep 5, 2012 at 8:07 AM, Wojciech Dec <wdec.ietf@gmail.com> wrote:
> A handful of comments:
>
> 1. Section 5
> It would be useful to indicate how this solution differs from MAP-T > (http://tools.ietf.org/html/draft-ietf-softwire-map-01 or=
> http://tools.ietf.org/html/draft-mdt-softwire-map-= translation-01), as well
> as to note the architectural underpinnings of NAT464 of the xlat solut= ion
> which it effectively validates.
>

No, we will not be casting 464XLAT in light of other solutions. =A0Th= e
WG, AFAIK, concluded this here
http://www.ietf.org/mail-archive/web/v6ops/current/msg1= 3714.html
=A0
And, AFAIK, MAP-T =A0is not longer an actively pursued solution. =A0A coin<= br> was flipped, and the IETF moved on.
=A0
i ag= ree that 464xlat document doesn't need to compare with any other soluti= ons. however, i guess you also=A0support Woj's effort of sharing the un= derstanding. and AFAIK, MAP-T, will be still the softwire WG document even = the status=A0might be=A0experimental. further, in the MAP deployment draft = that i am participating, we are obliged to include the understandings in or= der that the operators reading the deployment guidance may get a clear big = picture of the relationship among all the stuffs in the solution space.
=A0
i would like to share another point: maybe some people t= hink the about one year effort of making MAP-T and -E a unified work is vai= n, maybe some think we should=A0to do the coin toss one year ago, i don'= ;t agree. the effort of unification made out a common address mapping algor= ithm and the unified format, enabling operators change their mode of transp= ort once they understand somewhere the double translation, compatible with = single translation, is needed in their system architecture.
=A0
such an understanding on the necessity of translation, A= FAIK, is also significant to those who would like to deploy 464xlat. ;-)
=A0
- maoke
=A0

> In that context the points that IMO could help are:
> - xlat adopts/assumes exclusively a stateful NAT64 PLAT core (map allo= ws
> stateless or stateful NAT64)

MAP allows stateful sharing of public IPv4 addresses on NAT64? =A0I a= m
not sure how that can be given that Softwires does not have a charter
for stateful solutions. =A0And, AFAIK, the current MAP document does not reflect any stateful work for sharing public IPv4 addresses. =A0Doing a
search on draft-ietf-softwire-map-02 shows no references to RFC 6145
and RFC 6146, which are the core of 464XLAT.

> - xlat focuses on deployments where client provisioning of the public = IPv4
> address is not possible or viable (map requires explicit provisioning,= xlat
> works on defaults)

Yes.

i don't follow the rest of the comments and imagine the discussion
will shift after we release -08 where perhaps these details are
purposefully not specified and left to implementation discretion.

CB

> - An alternative of the last point could be that the solution focuses = on
> deployments where the client does not require to be informed of the pu= blic
> IPv4 address, and that default values are assumed.
>
> 2. Section 8.2.2
> - It would help recasting this section as the "routed" clat = mode. I.e the
> clat is delegated a prefix for NAT64 usage, with this prefix being rou= ted i)
> by the clat device towards the upstream device ii) routed by and not s= een as
> directly connected by the upstream device.
> - NAT44 is mentioned as mapping from IPv4 to IPv6. I take that this sh= ould
> be that NAT44 is used to map several IPv4s to one external IPv4.
> - The figure reflects none of that; it shows 1:1 mapping between IPv4 = and
> IPv6, and not the N:1 mapping between IPv4 and IPv4 which presumably i= s the
> role of NAT44.
> - It is not stated/specified what the external IPv4 address should be,= or
> how it is acquired/picked. This should be defined.
> - What is currently also missing from this section is how the clat sho= uld
> determine that it is to work in "routed" or "host"= mode (section 8.3.2). It
> is perfectly legitimate to have a PD and not use it for clat.
>
> 3. Section 8.3.2
> - This section should be recast as xlat (clat) host mode for which the=
> upstream node considers the clat and the upstream device share an &quo= t;on-link"
> prefix.
> - The ND-proxy appears NOT to be required on 3gpp, so it may be worthw= hile
> clarifying that.
> - Personally I think that adding ND-proxy is undesirable (as also stat= ed by
> others) and harmful (eg for upstream devices such as BNGs). Devices on= non
> 3gpp network should be directed to use the mode in section 8.3.2, whic= h
> would eliminate the need to mention proxy-ND at all.
>
> Regards,
> Woj.
>
>
>
>
> On 2 September 2012 19:09, joel jaeggli <joelja@bogus.com> wrote:
>>
>> Reminder, this WGLC runs through the 5th of September.
>>
>> On 8/21/12 8:45 AM, Fred Baker (fred) wrote:
>>>
>>> This is to open a two week Working Group last Call on
>>>
>>> http://tools.ietf.org/html/draft-ietf-v6ops-464xlat=
>>> =A0 =A0"464XLAT: Combination of Stateful and Stateless Tr= anslation", Masataka
>>> =A0 =A0Mawatari, Masanobu Kawashima, Cameron Byrne, 19-Aug-12<= br> >>>
>>> Please read it now. We are interested in, among other things, = technical
>>> commentary on the draft and the working group's perception= on its usefulness
>>> to its target audience.
>>> _______________________________________________
>>> v6ops mailing list
>>> v6ops@ietf.org
>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>
_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

--047d7b62253882200904c9009774-- From v6ops@globis.net Wed Sep 5 22:30:56 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6DA021F852A for ; Wed, 5 Sep 2012 22:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id di5uKljwZvVw for ; Wed, 5 Sep 2012 22:30:56 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2893921F851E for ; Wed, 5 Sep 2012 22:30:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id C8A3A8700C7; Thu, 6 Sep 2012 07:30:39 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9OHmi7pBRfbE; Thu, 6 Sep 2012 07:30:11 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 088A88700AB; Thu, 6 Sep 2012 07:30:11 +0200 (CEST) Message-ID: <504834DD.3080901@globis.net> Date: Thu, 06 Sep 2012 07:30:05 +0200 From: Ray Hunter User-Agent: Postbox 3.0.4 (Macintosh/20120616) MIME-Version: 1.0 To: Cameron Byrne References: <504392E0.8070802@bogus.com> <448050D4-84F9-4F52-BF7E-347EA451A96C@laposte.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops WG Subject: Re: [v6ops] Reminder: draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 05:30:56 -0000 Agreed. Cameron Byrne wrote: > My hope is that the -08 can reach rough consensus by just saying > that the CLAT SHOULD do DHCP-PD to acquire a /64 to be used > exclusively for stateless translation. If DHCP-PD is not available, > the CLAT MAY share the WAN /64 to the LAN in an appropriate way that > does not cause address conflicts or loops. I believe this is the > direction that Ray and Lorenzo have said they support. And just leave > it at that. Today, /64 is shared between WAN and LAN in many ways, > some are IETF specified (ND Proxy) and some are not such as behaving > as Switch/Router. In the case of the Android CLAT code that was > submitted to AOSP, the /64 is simply copied from the WAN 3G/4G > interfaces to the LAN. No magic. No ND Proxy. No DHCP. But, it works > for all known cases. 464XLAT, as stated in the introduction, is just > combining stateless and stateful protocol translation to overcome some > gaps that inhibit wider IPv6 adoption and IPv4 sunsetting. It is not > anything else. CB From fibrib@gmail.com Wed Sep 5 23:09:48 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A02221F84D6 for ; Wed, 5 Sep 2012 23:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 tagged_above=-999 required=5 tests=[AWL=0.417, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7A8PyCXYW-Zi for ; Wed, 5 Sep 2012 23:09:47 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 17FAF21F84A5 for ; Wed, 5 Sep 2012 23:09:46 -0700 (PDT) Received: by eekb45 with SMTP id b45so552628eek.31 for ; Wed, 05 Sep 2012 23:09:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=I9Pr6eoDCv3a6WeXJ3lxAJMSCbb772Ueb7dsiXWOx0s=; b=Dsd0HPIzokRuQqxAshwKdqxW+QzxRPu+y0jkl/07SodbK1zU+eBQG0s/MX3bgL5NrA K/Pbhw6sJdWrc7ArALQSQkFoSr4wuUdHnMauXjBHnuhfmZeurcFhgjRbrmYiPER85etA 6VqNo4n6+EZjiLm2a39FFTwPLle9GCKZKCp85acwOupTPdiRvwAaxXS9z4t5+vICAkCp fVC02r27ybnpo9KCoVvQn/caR651dWlSk8x6y5Z25rAH2aeA+zFWsnGEYTUOVCX7jmXY +QfPdV3rapIYuoY2Sc8QXcJcDFE7jjZyAaKfg2QBZIjwMmlSmbcRy35pBCRWnccbcF7m 9kSw== MIME-Version: 1.0 Received: by 10.14.202.66 with SMTP id c42mr1185366eeo.35.1346911786113; Wed, 05 Sep 2012 23:09:46 -0700 (PDT) Received: by 10.14.97.9 with HTTP; Wed, 5 Sep 2012 23:09:46 -0700 (PDT) In-Reply-To: References: Date: Thu, 6 Sep 2012 15:09:46 +0900 Message-ID: From: Maoke To: "Fred Baker (fred)" Content-Type: multipart/alternative; boundary=047d7b33daf48e193204c9025642 Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 06:09:48 -0000 --047d7b33daf48e193204c9025642 Content-Type: text/plain; charset=ISO-8859-1 hi authors and all, i have objection on the statement that traffic flow of CLAT to CLAT communication is out of scope. an operator may deploy a domain with the address planning for the private addresses and surely in such a case CLAT to CLAT communication (mesh mode) is a natural result of the 464xlat. i don't think it is needed to exclude this usage from the document. when using private (static) addresses for in-domain servers, such a feature is very useful. stating that 464xlat focusing on hub&spokes leaves an uncertainty: once the CLAT to CLAT communication is needed, what is the wanted behavior: A) immediately deliver to the peer CLAT; B) hairpinning via PLAT? - maoke 2012/8/22 Fred Baker (fred) > I should note that the current thread has a subject line reading -06.txt, > but the current version is -07.txt. You may find the diffs (fairly > extensive) at > > http://tools.ietf.org/rfcdiff?url2=draft-ietf-v6ops-464xlat-07.txt > > > On Aug 21, 2012, at 8:45 AM, Fred Baker (fred) wrote: > > > This is to open a two week Working Group last Call on > > > > http://tools.ietf.org/html/draft-ietf-v6ops-464xlat > > "464XLAT: Combination of Stateful and Stateless Translation", Masataka > > Mawatari, Masanobu Kawashima, Cameron Byrne, 19-Aug-12 > > > > Please read it now. We are interested in, among other things, technical > commentary on the draft and the working group's perception on its > usefulness to its target audience. > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > ---------------------------------------------------- > The ignorance of how to use new knowledge stockpiles exponentially. > - Marshall McLuhan > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --047d7b33daf48e193204c9025642 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
hi authors and all,
=A0
i have objection on the s= tatement that traffic flow of CLAT to CLAT communication is out of scope. a= n operator may deploy a domain with the address planning for the private ad= dresses and surely in such a case CLAT to CLAT communication (mesh mode) is= a natural result of the 464xlat. i don't think it is needed to exclude= this usage from the document. when using private (static) addresses for in= -domain servers, such a feature is very useful. stating that 464xlat focusi= ng on hub&spokes leaves an uncertainty: once the CLAT to CLAT communica= tion is needed, what is the wanted behavior: A) immediately deliver to the = peer CLAT; B) hairpinning via PLAT?
=A0
- maoke
=A0
20= 12/8/22 Fred Baker (fred) <fred@cisco.com>
I should note that the current thread has a subject line reading -06.txt, b= ut the current version is -07.txt. You may find the diffs (fairly extensive= ) at

http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6o= ps-464xlat-07.txt


On Aug 21, 2012, at 8:45 AM, Fred Baker (fred) wrote:

> This is to open a two week Working Group last Call on
>
> http://tools.ietf.org/html/draft-ietf-v6ops-464xlat
> =A0"464XLAT: Combination of Stateful and Stateless Translation&qu= ot;, Masataka
> =A0Mawatari, Masanobu Kawashima, Cameron Byrne, 19-Aug-12
>
> Please read it now. We are interested in, among other things, technica= l commentary on the draft and the working group's perception on its use= fulness to its target audience.
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

----------------------------------------------------
The ignorance of how to use new knowledge stockpiles exponentially.
=A0 =A0- Marshall McLuhan

_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

--047d7b33daf48e193204c9025642-- From lorenzo@google.com Wed Sep 5 23:20:35 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 748D321F850D for ; Wed, 5 Sep 2012 23:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.601 X-Spam-Level: X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kHeSP1mzD4Ep for ; Wed, 5 Sep 2012 23:20:34 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id C647221F842F for ; Wed, 5 Sep 2012 23:20:34 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so1962601obb.31 for ; Wed, 05 Sep 2012 23:20:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=2GdEV0XaPLdBXZS2RxtycOzjy4Z0zNQHWz9GWyvarJk=; b=NBE4MiDboYcgnHocv7FCvTLEsrWz8+ujNtPUKmUm/vtY+HsgvpNJXahxAiTopXgEvF +EHd2Mi23NDTR+qjPViBQMrCDWfKQLQNLZX6anKiwrCK8OVpd4Era1jkQalezYBNmM7I gNcB1HXlvJlSxkphNzs84s2l+p/Hlcgy3Cz/SKpkcYbA/2ofwjLHJbGqYiHyaBjp1F8n sLCC9Rck0uD1Tv7nG8j+FgcWuyEY7W+tlWfsvnxuj6iWMSMdLYg+1x/3u/mIGjuCg5F1 xvfxazB8dRzNGVMFzz29N5n119QbuOrhhQ4D17aSDYJJjl6D+iNVuolA5P0oXNY9RuZ4 hFdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=2GdEV0XaPLdBXZS2RxtycOzjy4Z0zNQHWz9GWyvarJk=; b=nW0oxqwdoWOsKVcwsrraHx6arH0yW4vulw7DdRFdOSq86YYKpqVG+uXytCb8+daEzF PRNI6X8p7DadqdYfyPzAyz9iDn44d7te968ZHgJ2344yocr0+5JQAO2GJmXy+FtyGdTI dUILLqwnwri9wV7LGNNwIlZ8BOqHBJ1bU/65kMqeQnOve7zpTyJmSF1Rn1Cx6DfEVpqY Fio4xOtphmh9Y+xX/5aCqPY+50cSX0ZEmGXwzALfNE1ot2vLHba48lspP9mWyPtvJiio TgjawvWOGaxbju4RF48Y1278jH3dht1/kvcvmPEtPbWiGKdTp4rq+lQz4uKIGJ/4WAXA lEkQ== Received: by 10.182.131.98 with SMTP id ol2mr705105obb.69.1346912434315; Wed, 05 Sep 2012 23:20:34 -0700 (PDT) Received: by 10.182.131.98 with SMTP id ol2mr705096obb.69.1346912434090; Wed, 05 Sep 2012 23:20:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.187.8 with HTTP; Wed, 5 Sep 2012 23:20:12 -0700 (PDT) In-Reply-To: References: <504392E0.8070802@bogus.com> <448050D4-84F9-4F52-BF7E-347EA451A96C@laposte.net> From: Lorenzo Colitti Date: Thu, 6 Sep 2012 15:20:12 +0900 Message-ID: To: Cameron Byrne Content-Type: multipart/alternative; boundary=e89a8f5028be2d732f04c9027d65 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlITtbUas7tcCPk6XBPOXpoKBP9OwsvzoH0ZTTg+g66MLGiPa2kvjf5bP8CbolDbKKSPBtZ8SMgHC3ZKHJ/m2Pw4MHarXBU4v/SKpGh2hGpDQTpbQpZZyUj1PqXBhyqqF7WoIeta9BRvO9V+wNWZfU8cn6r4R1Vwggl4iWcn6wy/grIk+rHKPkwlO8uZF8R2Hs7wo2I Cc: v6ops WG Subject: Re: [v6ops] Reminder: draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 06:20:35 -0000 --e89a8f5028be2d732f04c9027d65 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Sep 6, 2012 at 4:56 AM, Cameron Byrne wrote: > IMHO, trying to define how to construct IPv6 access networks sharing a > /64 is out of scope for 464XLAT. As part of the inventing the 464XLAT > service and how we could specify it from the ground up, we found it > required to speak to ND proxy, Remi's reserved IID solutions, and > others ... coming from 10,000 meters up and going back down to RFC > level, at this point... i do not believe we need to specify these > methods of extending a /64 or reserving IANA resources. Remi's and > others ideas have been clever, and i believe they can be re-spun as > more generic contributions to v6ops or HOMENET > Saying "sharing a /64 with downstream devices is out of scope" is a perfectly valid position to take. However, if we decide to say that, then for consistency, we should probably also say "sharing an IPv4 address with downstream devices is out of scope". As you say, making these two statements and leaving address sharing to a future document would be a good way to remove all current disagreements and move ahead. However, even if we take that approach, we still have to decide *something* in this document. Specifically, we need to decide what IID the CLAT will use when sending its own packets - because that will have impact on how the /64 is shared in the future. So in some sense, we still need to decide something now. > My hope is that the -08 can reach rough consensus by just saying that > the CLAT SHOULD do DHCP-PD to acquire a /64 to be used exclusively for > stateless translation. If DHCP-PD is not available, the CLAT MAY > share the WAN /64 to the LAN in an appropriate way that does not cause > address conflicts or loops. I'm not one of the chairs, but it seems to me that given recent comments on the text of the draft, think you'll need a respin anyway. --e89a8f5028be2d732f04c9027d65 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Sep 6, 2012 at 4:56 AM, Cameron Byrne <cb.list6@gmail.com>= wrote:
IMHO, trying to define how to const= ruct IPv6 access networks sharing a
/64 is out of scope for 464XLAT. =A0As part of the inventing the 464XLAT service and how we could specify it from the ground up, we found it
required to speak to ND proxy, Remi's reserved IID solutions, and
others ... coming from 10,000 meters up and going back down to RFC
level, at this point... i do not believe we need to specify these
methods of extending a /64 or reserving IANA resources. =A0Remi's and others ideas have been clever, and i believe they can be re-spun as
more generic contributions to v6ops or HOMENET

Saying "sharing a /64 with downstream devices is out of scope&= quot; is a perfectly valid position to take. However, if we decide to say t= hat, then for consistency, we should probably also say "sharing an IPv= 4 address with downstream devices is out of scope". As you say, making= these two statements and leaving address sharing to a future document woul= d be a good way to remove all current disagreements and move ahead.

However, even if we take that approach, we still=A0have= to decide *something* in this document. Specifically, we need to decide wh= at IID the CLAT will use when sending its own packets - because that will h= ave impact on how the /64 is shared in the future. So in some sense, we sti= ll need to decide something now.
=A0
My hope is that the -08 can re= ach rough consensus by just saying that
the CLAT SHOULD do DHCP-PD to acquire a /64 to be used exclusively for
stateless translation. =A0If DHCP-PD is not available, the CLAT MAY
share the WAN /64 to the LAN in an appropriate way that does not cause
address conflicts or loops.

I'm not one= of the chairs, but it seems to me that given recent comments on the text o= f the draft, think you'll need a respin anyway.
--e89a8f5028be2d732f04c9027d65-- From despres.remi@laposte.net Thu Sep 6 00:20:49 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B651B21F8495 for ; Thu, 6 Sep 2012 00:20:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.374 X-Spam-Level: X-Spam-Status: No, score=-1.374 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5SZCsGsd+SF for ; Thu, 6 Sep 2012 00:20:49 -0700 (PDT) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.4]) by ietfa.amsl.com (Postfix) with ESMTP id CA29B21F8484 for ; Thu, 6 Sep 2012 00:20:48 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2116.sfr.fr (SMTP Server) with ESMTP id 2E61C70000EF; Thu, 6 Sep 2012 09:20:47 +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 E7C96700006D; Thu, 6 Sep 2012 09:20:46 +0200 (CEST) X-SFR-UUID: 20120906072046949.E7C96700006D@msfrf2116.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Thu, 6 Sep 2012 09:20:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <504392E0.8070802@bogus.com> <448050D4-84F9-4F52-BF7E-347EA451A96C@laposte.net> To: v6ops WG X-Mailer: Apple Mail (2.1084) Subject: [v6ops] 464XLAT - support of /64 delegated prefixes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 07:20:49 -0000 2012-09-05 21:56, Cameron Byrne : ... > IMHO, trying to define how to construct IPv6 access networks sharing a > /64 is out of scope for 464XLAT. As part of the inventing the 464XLAT > service and how we could specify it from the ground up, we found it > required to speak to ND proxy, Remi's reserved IID solutions, and > others ... coming from 10,000 meters up and going back down to RFC > level, at this point... i do not believe we need to specify these > methods of extending a /64 or reserving IANA resources. Remi's and > others ideas have been clever, and i believe they can be re-spun as > more generic contributions to v6ops or HOMENET >=20 > My hope is that the -08 can reach rough consensus by just saying that > the CLAT SHOULD do DHCP-PD to acquire a /64 to be used exclusively for > stateless translation. If DHCP-PD is not available, the CLAT MAY > share the WAN /64 to the LAN in an appropriate way that does not cause > address conflicts or loops. I believe this is the direction that Ray > and Lorenzo have said they support. >=20 > And just leave it at that. >=20 > Today, /64 is shared between WAN and LAN in many ways, some are IETF > specified (ND Proxy) and some are not such as behaving as > Switch/Router. In the case of the Android CLAT code that was > submitted to AOSP, the /64 is simply copied from the WAN 3G/4G > interfaces to the LAN. No magic. No ND Proxy. No DHCP. But, it works > for all known cases. Following recent technical discussions, let's focus on this /64 = WAN-prefix case, the only one that IMHO still needs a refinement in the = draft. Let's assume IANA has reserved for CLATs the following subranges of the = range available for allocation in RFC5342 section 2.2.2: =20 02-00-5E-10-0A-xx-xx-xx for CLATs using 10../8 02-00-5E-10-AC-1x-xx-xx for CLATs using 172.16../12 02-00-5E-10-C0-A8-xx-xx for CLATs using 192.168../16 Then, SIMPLY by using in CLATs RFC6052 addresses whose /96 has = 0x02005E10 after the /64: - No NAT44 is necessary ( CLATs are completely stateless, the originally = objective of 464XLAT). - No conflict can exist between any of the IPv4-embedded addresses used = by CLATs and any host address that has a standard-compliant IID (RFC = 6052). This is completely independent from what is done (or not done) if = a WAN address using the /64 is configured at the CLAT WAN interface. =20 =3D> It would be A PITY to miss this operational improvement of the BCP = (and its simplification by eliminating its NAT44 variant) if reasons for = that would be refusal to take the time to understand the subject, and/or = the unjustified belief that getting IANA to accept an IETF reservation = request would be difficult.=20 It can be checked with Dan Drown that the above is understandable by an = implementor. Best regards, =20 RD >=20 > 464XLAT, as stated in the introduction, is just combining stateless > and stateful protocol translation to overcome some gaps that inhibit > wider IPv6 adoption and IPv4 sunsetting. It is not anything else. >=20 > CB > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From fibrib@gmail.com Thu Sep 6 00:21:22 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D433921F849A for ; Thu, 6 Sep 2012 00:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.42 X-Spam-Level: X-Spam-Status: No, score=-2.42 tagged_above=-999 required=5 tests=[AWL=0.578, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5D3UIn0p0gEa for ; Thu, 6 Sep 2012 00:21:22 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id D6BCF21F84AE for ; Thu, 6 Sep 2012 00:21:21 -0700 (PDT) Received: by eekb45 with SMTP id b45so577666eek.31 for ; Thu, 06 Sep 2012 00:21:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZiqOYJ2xzKW5VbdjrHzHqbv7A/UhUuuTwDGdCbO0Oy4=; b=GpUzefRVBBonm8lHsMCrs+j8wbPVmYQ6+mMX/lizevnWoazw+Y+itISBq2icW3raAJ 6PDp0ClP6qw4fQ3PDBKGYHgJnf0vj5y6LhtnS35xVwEt7y45k0iu0Tl1vrs8HDslQWv5 sSIpeCf9CADFtOlYglRO2UxSt+Ruwcyi2QZOd6pGpunpjqj7q47ALqmdokMAt0e1Dacs MxRjD8NbJXJc/SanRgI4XoAkBVAJkUSzUoYSHWGownHGKCxLmOoqcqAuRuB8l6QmdFdd UyO1lVPjwbyMinBrHFEL0whMWkok9c6j4vOCTl+iOnQ7wNWPOwAjqhvDmxOYh5TjQn8E nCkQ== MIME-Version: 1.0 Received: by 10.14.202.71 with SMTP id c47mr1373505eeo.42.1346916080920; Thu, 06 Sep 2012 00:21:20 -0700 (PDT) Received: by 10.14.97.9 with HTTP; Thu, 6 Sep 2012 00:21:20 -0700 (PDT) In-Reply-To: References: Date: Thu, 6 Sep 2012 16:21:20 +0900 Message-ID: From: Maoke To: "Fred Baker (fred)" Content-Type: multipart/alternative; boundary=047d7b343e388ba67404c9035663 Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 07:21:22 -0000 --047d7b343e388ba67404c9035663 Content-Type: text/plain; charset=ISO-8859-1 another objection is, Section 9 states "another, if combined with BIH [RFC6535 ], is a IPv4 -> IPv6 translation for reaching IPv6-only servers from IPv4-only clients that can not support IPv6. " it sounds to me that 464xlat does suggest to apply BIH, as part of the best practice, for IPv4 client reaching IPv6-only servers. to my understanding, there could be several alternative ways to achieve that, why we should be bounded with BIH? sorry i didn't catch the discussion on this issue before. - maoke 2012/8/22 Fred Baker (fred) > I should note that the current thread has a subject line reading -06.txt, > but the current version is -07.txt. You may find the diffs (fairly > extensive) at > > http://tools.ietf.org/rfcdiff?url2=draft-ietf-v6ops-464xlat-07.txt > > > On Aug 21, 2012, at 8:45 AM, Fred Baker (fred) wrote: > > > This is to open a two week Working Group last Call on > > > > http://tools.ietf.org/html/draft-ietf-v6ops-464xlat > > "464XLAT: Combination of Stateful and Stateless Translation", Masataka > > Mawatari, Masanobu Kawashima, Cameron Byrne, 19-Aug-12 > > > > Please read it now. We are interested in, among other things, technical > commentary on the draft and the working group's perception on its > usefulness to its target audience. > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > ---------------------------------------------------- > The ignorance of how to use new knowledge stockpiles exponentially. > - Marshall McLuhan > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --047d7b343e388ba67404c9035663 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
=A0
another objection is, Section 9 states "another,=A0=A0 if combined with BIH [RFC6535], is a IPv4 -&g= t; IPv6 translation for
=A0=A0 reaching IPv6-only servers from IPv4-only clients that can not
= =A0=A0 support IPv6. "
=A0
it sounds to me that 46= 4xlat does suggest=A0to apply=A0BIH, as part of the best practice, for IPv4= client reaching IPv6-only servers. to my understanding, there could be sev= eral alternative ways to achieve that, why we should be bounded with BIH? <= /div>
=A0
sorry i didn't catch the discussion on this issue be= fore.
=A0
- maoke

2012/8/22 Fred Baker (fred) <fred@cisco.com>
I should note that the current thread has a subject line r= eading -06.txt, but the current version is -07.txt. You may find the diffs = (fairly extensive) at

http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6o= ps-464xlat-07.txt


On Aug 21, 2012, at 8:45 AM, Fred Baker (fred) wrote:

> This is to open a two week Working Group last Call on
>
> http://tools.ietf.org/html/draft-ietf-v6ops-464xlat
> =A0"464XLAT: Combination of Stateful and Stateless Translation&qu= ot;, Masataka
> =A0Mawatari, Masanobu Kawashima, Cameron Byrne, 19-Aug-12
>
> Please read it now. We are interested in, among other things, technica= l commentary on the draft and the working group's perception on its use= fulness to its target audience.
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

----------------------------------------------------
The ignorance of how to use new knowledge stockpiles exponentially.
=A0 =A0- Marshall McLuhan

_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

--047d7b343e388ba67404c9035663-- From lorenzo@google.com Thu Sep 6 00:48:55 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58B4B21F8545 for ; Thu, 6 Sep 2012 00:48:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.676 X-Spam-Level: X-Spam-Status: No, score=-102.676 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zDVmvzZijif3 for ; Thu, 6 Sep 2012 00:48:54 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id B459021F853E for ; Thu, 6 Sep 2012 00:48:54 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so2092373obb.31 for ; Thu, 06 Sep 2012 00:48:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=P6e/wKtciUGZTvy6BelyEYsrUo6DJ3/s1fdS0u8xxC8=; b=QSHIU+A/yPZ5NJTNR6eTujOsb+fIzsJIwrkc+phM6AP20v3mK8ZUmOrvsgUu6eolQj 47KfW1vtBB6LNjcznv2MA2uTrfj83XbG7XnytwRLdPgTt+vtModF7ItQdKDOuXue/PZ+ 19Yt5PSKhPGKDhjw472q07aR/kAqF1k84gEuHfK52+lM9A8dBA4l1EZyzWNxYr8I0XIJ OxNR305v25bGWF2M041+oN1guQceJF2ztoJDPGvJ4g52coDjlGflFElDPNOMLpB+Gus0 RAUXdMoDpbxO29UigG6YImRkAgvBkWLMdHqJ5i0YiVV+8EjDQ8drr7jtf3v7K+Hr5BZA wM6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=P6e/wKtciUGZTvy6BelyEYsrUo6DJ3/s1fdS0u8xxC8=; b=edC41rKlbHZiOmBV8w0r3OcE8CQmKEYHVO6Xjj6szSx1rwzEeU1Vidb0fCPhkgkgyJ bHphZJYlO8RGwDzu2k8m+2Gl+68cB2rlozD95uBY7wpaeLzuA0IjyuQ14oG/gpP74AEc J20tmlvikfP04YOeoCO6ajVA8KCb9Sbz9eKdDL6NXuwKr7jKp1tXlgGIxghgyaXVJBN1 JhHpuoqolpnsKaXyVy0T+5m2Ja7XTV59VhW27mR1HKsaEyKztcRIYORisKO2RqC9hk4H xxLIKRo3A7AAkABp1E4ksegF2mADxIaC2E6Gpplx5z6g0gp+1vkZELqEED46xhbKcB0o XebA== Received: by 10.60.4.163 with SMTP id l3mr662956oel.74.1346917734279; Thu, 06 Sep 2012 00:48:54 -0700 (PDT) Received: by 10.60.4.163 with SMTP id l3mr662947oel.74.1346917734133; Thu, 06 Sep 2012 00:48:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.187.8 with HTTP; Thu, 6 Sep 2012 00:48:32 -0700 (PDT) In-Reply-To: References: <504392E0.8070802@bogus.com> <448050D4-84F9-4F52-BF7E-347EA451A96C@laposte.net> From: Lorenzo Colitti Date: Thu, 6 Sep 2012 16:48:32 +0900 Message-ID: To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=e89a8fb2072a15aeb104c903b90b X-System-Of-Record: true X-Gm-Message-State: ALoCoQlKgi0RyleoRyAaEyqlj1vXSDLFl+YDhe87CmqhmSzpkM1xLsvsKOAlraxUJ9S2HWOrBjoDmhcrqbjdKPGaP911rQaWvYDQ7mBtFR5XiZzrnmco3uf9vp2CQjnYy2RLw+yApccCggY/Q9zCItknUOuD6hjKpwcjeSkaGeZagB2x+S41rYIuBpl5riF2r/18F02YflyW Cc: v6ops WG Subject: Re: [v6ops] 464XLAT - support of /64 delegated prefixes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 07:48:55 -0000 --e89a8fb2072a15aeb104c903b90b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Sep 6, 2012 at 4:20 PM, R=E9mi Despr=E9s = wrote: > Let's assume IANA has reserved for CLATs the following subranges of the > range available for allocation in RFC5342 section 2.2.2: > 02-00-5E-10-0A-xx-xx-xx for CLATs using 10../8 > 02-00-5E-10-AC-1x-xx-xx for CLATs using 172.16../12 > 02-00-5E-10-C0-A8-xx-xx for CLATs using 192.168../16 > Since assuming the impossible leads to failure, we first need to ensure that: 1. IANA has the authority to assign such address space. 2. IANA is willing to assign such address space 3. IANA has the techical capability (e.g., processes) to assign such address space. Without answers to the above questions, we cannot proceed. Remi, do you know the answers? --e89a8fb2072a15aeb104c903b90b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Sep 6, 2012 at 4:20 PM, R=E9mi Despr=E9s <despres.remi@lapo= ste.net> wrote:
Let's assume IANA has reserved for CLATs the following subranges of the= range available for allocation in RFC5342 section 2.2.2:
=A002-00-5E-10-0A-xx-xx-xx for CLATs using 10../8
=A002-00-5E-10-AC-1x-xx-xx for CLATs using 172.16../12
=A002-00-5E-10-C0-A8-xx-xx for CLATs using 192.168../16

Since assuming the impossible leads to failure, we first n= eed to ensure that:
  1. IANA has the authority to assign such= address space.
  2. IANA is willing to assign such address space
  3. IANA has the techi= cal capability (e.g., processes) to assign such address space.
Without answers to the above questions, we cannot proceed. Remi, do you k= now the answers?
--e89a8fb2072a15aeb104c903b90b-- From lorenzo@google.com Thu Sep 6 00:51:03 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0033921F854A for ; Thu, 6 Sep 2012 00:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.826 X-Spam-Level: X-Spam-Status: No, score=-102.826 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jYke7Eg-HJ8S for ; Thu, 6 Sep 2012 00:51:02 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 163DB21F8534 for ; Thu, 6 Sep 2012 00:51:01 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so2095270obb.31 for ; Thu, 06 Sep 2012 00:50:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=FuYbTl9oP/RcdJJiVg8kA/BMI1ajeKkN8RyyFuFxt0k=; b=LgLROWxyCp8kjvUIo/rQld4hEygLCOY+GWVHsNhMo+CLPWzkMepmGrW5nCJwzUdgKq 3TuhpscEdolwqjtaO3KB6w931cdVR2SCnFL9yRacVyNZr0SiU5uiEeGqkfV25nwZpVSZ OljjjhCalJLOdXaQKVDv8CJp/DZocRJ4EpfbGkWf6lClAEIf8Yo7UZ7pVoTrzEwQzXo+ wnJf/PY27FmbwhTmVBgQkfNuCNVX/F07jqVM8dxpgc6D7as62+iQRKacfv9cK3+gusqV oFT9Eto/VYKhivp1sdKbRwKdojd2PVUxfP1M2Knwbj8FFJHRHciIhu/K7y7BMsbgeqGS 8H9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=FuYbTl9oP/RcdJJiVg8kA/BMI1ajeKkN8RyyFuFxt0k=; b=ot67UYsakRnOSLiaqT8e0Fz9WJn8rGOzxsYXUpfeGlPBMoTnRStNJO6krMh/+9099b Z032Rzky2D46tEgUvAdNAGrwXeJbpHL9EYEjrOUf+4M9D6cF4PSI/bRHrpBk3s58c157 RHvUnZGumBZQI7Pz7lpwpdhbq71x4Q7/rBxr9M1Zj93m8iHrALKFnwHNuVlnU1lkSlo6 tpOR3bkmuyZYC8R69+dQ+mo4ZvobSamdpg/z6EqHnr2lOBfZ2hkm8X4Fx55ODXf3dqww 0ZR90B7y8u8KILIjO9VsCVJ8l5nw9PIrX+ZtvZyulIxV9bB4r5nRHVaJUEczMq7ReTjT tzPg== Received: by 10.182.1.72 with SMTP id 8mr869743obk.61.1346917852645; Thu, 06 Sep 2012 00:50:52 -0700 (PDT) Received: by 10.182.1.72 with SMTP id 8mr869739obk.61.1346917852519; Thu, 06 Sep 2012 00:50:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.187.8 with HTTP; Thu, 6 Sep 2012 00:50:32 -0700 (PDT) In-Reply-To: References: From: Lorenzo Colitti Date: Thu, 6 Sep 2012 16:50:32 +0900 Message-ID: To: Maoke Content-Type: multipart/alternative; boundary=f46d04462fe0241c1a04c903c00d X-System-Of-Record: true X-Gm-Message-State: ALoCoQknTYxtf4mUvIq757CbCBs8sQ/dPftMsCetjYJXnGNpcQVBBlHdzelNo/lAE1W5N2YefbkeAFiEGXLkHgpyCejegW353WxPGeYDYW8dPVxsp1ed+ld6um86E1dMkrAc7Agh4R+rIVKeRAk46SnxwdhO+5BQabhPTXYHNs4Txq4V1SWNh8yzVQbv3MLUNfAEqZ1E9ImL Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 07:51:03 -0000 --f46d04462fe0241c1a04c903c00d Content-Type: text/plain; charset=ISO-8859-1 On Thu, Sep 6, 2012 at 4:21 PM, Maoke wrote: > > another objection is, Section 9 states "another, > if combined with BIH [RFC6535 ], > is a IPv4 -> IPv6 translation for > reaching IPv6-only servers from IPv4-only clients that can not > support IPv6. " > > it sounds to me that 464xlat does suggest to apply BIH, as part of the > best practice, for IPv4 client reaching IPv6-only servers. to my > understanding, there could be several alternative ways to achieve that, why > we should be bounded with BIH? > > sorry i didn't catch the discussion on this issue before. > IIRC, that text was added to an earlier version to appease Remi, who was demanding it. I agree that it is superfluous to make that statement in this draft. --f46d04462fe0241c1a04c903c00d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Sep 6, 2012 at 4:21 PM, Maoke <fibrib@gmail.com> wrot= e:
=A0

IIRC, that text was added to an earl= ier version to appease Remi, who was demanding it.=A0I agree that it is sup= erfluous to make that statement in this draft.
--f46d04462fe0241c1a04c903c00d-- From fibrib@gmail.com Thu Sep 6 00:54:18 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F6E821F853E for ; Thu, 6 Sep 2012 00:54:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kgKbnEIGBfH6 for ; Thu, 6 Sep 2012 00:54:18 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id BAD4F21F853B for ; Thu, 6 Sep 2012 00:54:17 -0700 (PDT) Received: by eekb45 with SMTP id b45so592932eek.31 for ; Thu, 06 Sep 2012 00:54:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=b2sUXgR2Ir/TVYby6ZIgzyLlTdYdKDj+GLZYX91qUF0=; b=gX84A/NyOm33lcFNCz024vJC6U3GFy42Y53NM/DmeSb7sT9NHVC0qjPn3WSJjgdnwF IldXD9or0p3+qJ2wt8/CLb+UKmwr8YJG4tQCLDYyc4So4hvcrk68hyrmmFNsPrpQDofa jtdQR/+r7cdihDbfDgfjLlFHAwV+9+V4688NgQwKoAYkVfd044ydM3RAMS51lhDPM8td z/e4z6Klo2LS7lHuzHSwX7Bk2+xVR8QZI8cjNEI58d4S77MBSVmH2uG8efpnryMjlwmC SNc8wKX4OnbwPEp8gq/V54/6lERdJpxTpvGiO/u44VKRIRh6AgbYRKw+f1OfIKByXtA+ 9p3g== MIME-Version: 1.0 Received: by 10.14.172.129 with SMTP id t1mr1489207eel.34.1346918056601; Thu, 06 Sep 2012 00:54:16 -0700 (PDT) Received: by 10.14.97.9 with HTTP; Thu, 6 Sep 2012 00:54:16 -0700 (PDT) In-Reply-To: References: <504392E0.8070802@bogus.com> <448050D4-84F9-4F52-BF7E-347EA451A96C@laposte.net> Date: Thu, 6 Sep 2012 16:54:16 +0900 Message-ID: From: Maoke To: Lorenzo Colitti Content-Type: multipart/alternative; boundary=047d7b603c124e282504c903cc7b Cc: v6ops WG Subject: Re: [v6ops] 464XLAT - support of /64 delegated prefixes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 07:54:18 -0000 --047d7b603c124e282504c903cc7b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/9/6 Lorenzo Colitti > On Thu, Sep 6, 2012 at 4:20 PM, R=E9mi Despr=E9s wrote: > >> Let's assume IANA has reserved for CLATs the following subranges of the >> range available for allocation in RFC5342 section 2.2.2: >> 02-00-5E-10-0A-xx-xx-xx for CLATs using 10../8 >> 02-00-5E-10-AC-1x-xx-xx for CLATs using 172.16../12 >> 02-00-5E-10-C0-A8-xx-xx for CLATs using 192.168../16 >> > > Since assuming the impossible leads to failure, we first need to ensure > that: > > 1. IANA has the authority to assign such address space. > 2. IANA is willing to assign such address space > 3. IANA has the techical capability (e.g., processes) to assign such > address space. > 4. > > how can we ensure the above addresses do not conflict with any manually, arbitrarily configured addresses? i am lost. :P - maoke > Without answers to the above questions, we cannot proceed. Remi, do you > know the answers? > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --047d7b603c124e282504c903cc7b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
=A0
2012/9/6 Lor= enzo Colitti <lorenzo@google.com>
On Thu, Sep 6, 2012 at 4:20 PM, R=E9mi Despr=E9s <despres.remi@laposte.net> wrote:
Let's assume IANA has reserved for CLATs the following subranges of the= range available for allocation in RFC5342 section 2.2.2:
=A002-00-5E-10-0A-xx-xx-xx for CLATs using 10../8
=A002-00-5E-10-AC-1x-xx-xx for CLATs using 172.16../12
=A002-00-5E-10-C0-A8-xx-xx for CLATs using 192.168../16

Since assuming the impossible leads to failure, we f= irst need to ensure that:
  1. IANA has the authority to assig= n such address space.
  2. IANA is willing to assign such address space
  3. IANA has the techi= cal capability (e.g., processes) to assign such address space.
=A0
how=A0can we ensure the a= bove addresses=A0do not conflict with any manually, arbitrarily=A0configure= d addresses? i=A0am lost.=A0:P - maoke=A0

Without answers to the above= questions, we cannot proceed. Remi, do you know the answers?


_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops


--047d7b603c124e282504c903cc7b-- From despres.remi@laposte.net Thu Sep 6 01:01:58 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A45A21F843A for ; Thu, 6 Sep 2012 01:01:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.665 X-Spam-Level: X-Spam-Status: No, score=-1.665 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J1FMNrApgfWx for ; Thu, 6 Sep 2012 01:01:57 -0700 (PDT) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.4]) by ietfa.amsl.com (Postfix) with ESMTP id 448E921F8438 for ; Thu, 6 Sep 2012 01:01:56 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2117.sfr.fr (SMTP Server) with ESMTP id 1EBA1700004E; Thu, 6 Sep 2012 10:01:56 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2117.sfr.fr (SMTP Server) with ESMTP id B1E1E70000B6; Thu, 6 Sep 2012 10:01:55 +0200 (CEST) X-SFR-UUID: 20120906080155728.B1E1E70000B6@msfrf2117.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-16--755874709 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Thu, 6 Sep 2012 10:01:52 +0200 Message-Id: References: <504392E0.8070802@bogus.com> <448050D4-84F9-4F52-BF7E-347EA451A96C@laposte.net> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] 464XLAT - support of /64 delegated prefixes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 08:01:58 -0000 --Apple-Mail-16--755874709 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-09-06 =E0 09:48, Lorenzo Colitti a =E9crit : > On Thu, Sep 6, 2012 at 4:20 PM, R=E9mi Despr=E9s = wrote: > Let's assume IANA has reserved for CLATs the following subranges of = the range available for allocation in RFC5342 section 2.2.2: > 02-00-5E-10-0A-xx-xx-xx for CLATs using 10../8 > 02-00-5E-10-AC-1x-xx-xx for CLATs using 172.16../12 > 02-00-5E-10-C0-A8-xx-xx for CLATs using 192.168../16 >=20 > Since assuming the impossible leads to failure, we first need to = ensure that: > IANA has the authority to assign such address space. > IANA is willing to assign such address space > IANA has the techical capability (e.g., processes) to assign such = address space. > Without answers to the above questions, we cannot proceed. Remi, do = you know the answers? AFGAIK, IANA is responsible to maintain registries of number that need = to be assigned for IETF RFCs. Copy added to Ron who has more experience on this. RD --Apple-Mail-16--755874709 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On Thu, Sep 6, 2012 at 4:20 PM, R=E9mi Despr=E9s <despres.remi@laposte.net> wrote:
Let's assume IANA has reserved for CLATs the following subranges of the = range available for allocation in RFC5342 section 2.2.2:
 02-00-5E-10-0A-xx-xx-xx for CLATs using 10../8
 02-00-5E-10-AC-1x-xx-xx for CLATs using 172.16../12
 02-00-5E-10-C0-A8-xx-xx for CLATs using = 192.168../16

Since assuming the = impossible leads to failure, we first need to ensure = that:
  1. IANA has the authority to assign such address = space.
  2. IANA is willing to assign such address space
  3. IANA has the = techical capability (e.g., processes) to assign such address = space.
Without answers to the above questions, we cannot = proceed. Remi, do you know the answers?

AFGAIK, IANA is responsible to maintain = registries of number that need to be assigned for IETF = RFCs.
Copy added to Ron who has more experience on = this.

RD



<= /body>= --Apple-Mail-16--755874709-- From lorenzo@google.com Thu Sep 6 01:03:06 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1821221F84DF for ; Thu, 6 Sep 2012 01:03:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.856 X-Spam-Level: X-Spam-Status: No, score=-102.856 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NmAmIgWuBppu for ; Thu, 6 Sep 2012 01:03:05 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id E938221F84DE for ; Thu, 6 Sep 2012 01:03:04 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so2113586obb.31 for ; Thu, 06 Sep 2012 01:03:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=vQdSzxRYkwTwLfbWnGoNxOlXI0BH5f7u+YjlNfiEqPc=; b=QzI/XvK71k9Z2d1CeXtkvVTRlFWa+HptSscdE4mVDgjalcimxt0LzMzNXjBQlmAhXN p7LaBobxB3CJkZ/G4L1iVN7WZhVzDJx+ueZYXsZHkR613MxTm54fwwoT6Op8vvnxCEtM rHdz6zKQLhnV06TigYZrN7TWOKewYCS3nrK86c32Gkc6flEteG4ttFqgDt32J1U34ZkP pw55mBaQbirmVKcXBplR+QEqd6645pH4+A0JsgnxI4XkrtKHiao/RCqY+G6N0kZx8VKV bn8qNZVbIf9kp6RAEjIfvAMT17gF98mhvjTcYEOpdmJIz4soLhDDvT8mrmovDH7H3EIC 7EqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=vQdSzxRYkwTwLfbWnGoNxOlXI0BH5f7u+YjlNfiEqPc=; b=puNVvD6f3Ljta5OkNSS0dGI2EwWb8G325rTd1SffMwmqNu476C1YJmZKptzugrXhVX pn1SkUjQxXO11ELVh52bkwvaNArU7C7EEOSZsAuraFWaPOO9wjkJjIXa5ZZemzsT0Av0 Pn7TjggQwuRYQcMhAtQO4LKx9BmArdr5yAApJBhFhCwuSbuXNEQLhHtrjHh5zVVfOdCt OF35c5yEnDmEay2AibZ8C62AK/8pNQ2XzHyeRcYciceDYS1qdffUrbkXQVyMxFk/JuSv 2RNvY+oel0T72JDWd+XnnI1xA+zmBfAXZ84qsskiXCSuWWBk5ROHZlxqix0DRKgD/YFW kYgQ== Received: by 10.60.19.132 with SMTP id f4mr969837oee.17.1346918584612; Thu, 06 Sep 2012 01:03:04 -0700 (PDT) Received: by 10.60.19.132 with SMTP id f4mr969825oee.17.1346918584465; Thu, 06 Sep 2012 01:03:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.187.8 with HTTP; Thu, 6 Sep 2012 01:02:44 -0700 (PDT) In-Reply-To: References: <504392E0.8070802@bogus.com> <448050D4-84F9-4F52-BF7E-347EA451A96C@laposte.net> From: Lorenzo Colitti Date: Thu, 6 Sep 2012 17:02:44 +0900 Message-ID: To: Maoke Content-Type: multipart/alternative; boundary=e89a8ff1cb94c4b88304c903eb56 X-System-Of-Record: true X-Gm-Message-State: ALoCoQl1ohgwt1l9RhVOtSNt/w31u8B3MOkhKkDyl7h38UBqiMdSt4it/DfN9hlEYkJrYgs6uDPYHclN5obeK9A2NHt2XxOGSpbC13zBnX37a3xgYEY4pTngAwwCS6k+hPD/7pYnVjYVetdx/ZvVrMaiKv8fXsxsE3i9emzD/vygOLKgo7rSkq35zFE5tblHW7i643CVDn2c Cc: v6ops WG Subject: Re: [v6ops] 464XLAT - support of /64 delegated prefixes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 08:03:06 -0000 --e89a8ff1cb94c4b88304c903eb56 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Sep 6, 2012 at 4:54 PM, Maoke wrote: > how can we ensure the above addresses do not conflict with any manually, > arbitrarily configured addresses? i am lost. :P - maoke > AIUI, we say "conflicts are impossible, because this is a reserved range", and then we cross our fingers. --e89a8ff1cb94c4b88304c903eb56 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Sep 6, 2012 at 4:54 PM, Maoke <fibrib@gmail.com> wrot= e:
how=A0can we ensure the above addresses=A0do not= conflict with any manually, arbitrarily=A0configured addresses? i=A0am los= t.=A0:P - maoke=A0

AIUI, we say "= ;conflicts are impossible, because this is a reserved range", and then= we cross our fingers.
--e89a8ff1cb94c4b88304c903eb56-- From despres.remi@laposte.net Thu Sep 6 01:06:20 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8F721F856F for ; Thu, 6 Sep 2012 01:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.436 X-Spam-Level: X-Spam-Status: No, score=-1.436 tagged_above=-999 required=5 tests=[AWL=-0.088, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6mAaiOIzcU6y for ; Thu, 6 Sep 2012 01:06:19 -0700 (PDT) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.4]) by ietfa.amsl.com (Postfix) with ESMTP id 387EF21F856C for ; Thu, 6 Sep 2012 01:06:19 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2117.sfr.fr (SMTP Server) with ESMTP id 2C1D17000054; Thu, 6 Sep 2012 10:06:18 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2117.sfr.fr (SMTP Server) with ESMTP id DE52970000B6; Thu, 6 Sep 2012 10:06:17 +0200 (CEST) X-SFR-UUID: 20120906080617910.DE52970000B6@msfrf2117.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-17--755610058 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Thu, 6 Sep 2012 10:06:17 +0200 Message-Id: References: To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 08:06:20 -0000 --Apple-Mail-17--755610058 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-09-06 =E0 09:50, Lorenzo Colitti a =E9crit : > On Thu, Sep 6, 2012 at 4:21 PM, Maoke wrote: > =20 > another objection is, Section 9 states "another, > if combined with BIH [RFC6535], is a IPv4 -> IPv6 translation for > reaching IPv6-only servers from IPv4-only clients that can not > support IPv6. " > =20 > it sounds to me that 464xlat does suggest to apply BIH, as part of the = best practice, for IPv4 client reaching IPv6-only servers. to my = understanding, there could be several alternative ways to achieve that, = why we should be bounded with BIH? > =20 > sorry i didn't catch the discussion on this issue before. >=20 > IIRC, that text was added to an earlier version to appease Remi, who = was demanding it. I agree that it is superfluous to make that statement = in this draft. I didn't ask for this statement in particular, just to remove a = statement that suggested that 464XLAT would permit IPv4 applications to = reach IPv6-only servers (which happens to be in scope for BIH, not in = that of 464XLAT) Deleting this sentence is perfectly fine with me. RD > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail-17--755610058 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On Thu, Sep 6, 2012 at 4:21 PM, Maoke <fibrib@gmail.com> wrote:
 
another objection is, Section 9 states = "another,
   if combined with BIH [RFC6535], is a IPv4 -> IPv6 translation for
   reaching IPv6-only servers from IPv4-only clients that can = not
   support IPv6. "
 
it sounds = to me that 464xlat does suggest to apply BIH, as part of the = best practice, for IPv4 client reaching IPv6-only servers. to my = understanding, there could be several alternative ways to achieve that, = why we should be bounded with BIH?
 
sorry i didn't catch the discussion on this issue = before.

IIRC, that text was added to an = earlier version to appease Remi, who was demanding it. I agree that = it is superfluous to make that statement in this = draft.

I didn't ask for this = statement in particular, just to remove a statement that suggested that = 464XLAT would permit IPv4 applications to reach IPv6-only servers (which = happens to be in scope for BIH, not in that of = 464XLAT)
Deleting this sentence is perfectly fine with = me.

RD



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

= --Apple-Mail-17--755610058-- From despres.remi@laposte.net Thu Sep 6 01:21:38 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DC1D21F854A for ; Thu, 6 Sep 2012 01:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.419 X-Spam-Level: X-Spam-Status: No, score=-1.419 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d6bGhxM1Dpm1 for ; Thu, 6 Sep 2012 01:21:37 -0700 (PDT) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.81]) by ietfa.amsl.com (Postfix) with ESMTP id C530521F843A for ; Thu, 6 Sep 2012 01:21:36 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2418.sfr.fr (SMTP Server) with ESMTP id 744397000187; Thu, 6 Sep 2012 10:21:35 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2418.sfr.fr (SMTP Server) with ESMTP id 13A9E70000B0; Thu, 6 Sep 2012 10:21:35 +0200 (CEST) X-SFR-UUID: 20120906082135806.13A9E70000B0@msfrf2418.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: Date: Thu, 6 Sep 2012 10:21:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <73236354-CD24-491D-A177-1A45707CF07F@laposte.net> References: <504392E0.8070802@bogus.com> <448050D4-84F9-4F52-BF7E-347EA451A96C@laposte.net> To: Fred Baker (fred) X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] Reminder: draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 08:21:38 -0000 2012-09-05 20:31, Fred Baker (fred) : >=20 > On Sep 3, 2012, at 8:17 AM, R=E9mi Despr=E9s wrote: >=20 >> If the WGLC is, like an IESG last call, "to make sure that no = important concerns have been missed or misunderstood" (RFC 2418), I = think we aren't quite at this stage yet. >> The current discussions on ND proxy and/or IANA-reserved IIDs is = still progressing, but AFAIK without clear conclusion. >=20 > > The purpose of a WGLC is, as you say, to ensure that important = concerns have not been missed or misunderstood. It is not to to prove or = create unanimity of viewpoint, although that would be a happy outcome. = If in the opinion of the chairs all opinions have been expressed and new = issues are not being raised, a single person or small group that = disagrees with the outcome is consistent with "rough consensus". At this stage, there is still AFAIK an important "concern that has been = misunderstood": how to deal safely and simply with /64 delegated = prefixes. =20 Refs.: - www.ietf.org/mail-archive/web/v6ops/current/msg14093.html - (*) below.=20 >=20 > I note that this morning we have additional comments from Ray and Woj, = which I think need to be heard and addressed. So I'll let the WGLC = continue the remainder of this week to see what additionally shakes = loose. Note to the authors: we will need a -08 as an outcome of the = WGLC. > >=20 > > Let me see if I can tease apart the issue of an IID, ND Proxy, and = DHCP-PD a bit. I have a view, which I will state, but as a contributor = I'm not trying to impose my view as much as put the arguments all in one = place and try to tease out a resolution. If this helps, it helps, and if = it doesn't, forget I said it. >=20 >=20 > The purpose of an IID (or an Endpoint ID, which would be an IID used = on all interfaces) is to uniquely identify an interface (or system) = within a local domain below the Internet Layer. RFC 4291 describes how = one might derive it from an EUI-48 or EUI-64 number; RFC 3972 describes = another mechanism based on cryptography, RFC 4941 describes a mechanism = that uses a random number generator, RFC 4291 and 6052 describe = approaches derivative from IPv4 addresses, and there is always the = possibility of manual assignment. In no case, as far as I am aware, does = one start from the IID and generate a lower layer address from it; the = lower layer address, if it is used at all, is only used as input to the = IID generation algorithm. Regardless of the way the IID is formed, it = has some possibility of being a duplicate address, and the wise = implementation will take the time to verify its uniqueness. Since there = are so many ways an IID can be created, I personally find little use in = mandating anything specific about it unless there is an interoperability = requirement in a specific implementation, such as exists in SEND. Same understanding. > So the entire debate about an IANA-specified IID is, frankly, lost on = me. I have difficulty formulating the argument. It is, by any other = description, a more-or-less-random 64 bit number, and the only use of it = once it is created is as a search key in the neighbor table. (*) That's the point where AFAIK progress continues to be made to reach = common understanding. I may be wrong but I think that: - Dan Drown, who has implemented a CLAT, does understand how the = proposed solution works. - Lorenzo has seen its potential. (ref. the end of = www.ietf.org/mail-archive/web/v6ops/current/msg14073.html). He still = fears that reserving IID sub-ranges in a range that remains available in = RFC 5342 section 2.2.2 might be difficult, but this isn't AFAIK the = case.=20 > Regardless of how the IID is formed, there is a question of how the = network is formed. If we define a local network to include one or more = router interfaces connected to a set of clients over some form of media, = there are two broad classes of media - ones in which all clients = communicate directly with each other at the Internet Layer (such as in = an Ethernet, switched or otherwise), and ones in which they communicate = at the IP layer though an intermediate device (such as a BRAS or CMTS). = Neighbor Discovery is designed for the Broadcast Multi-access case, and = ND Proxy is designed for the Non-Broadcast Multi-access case. In both = cases, IPv6 and Neighbor Discovery (direct or proxy) assume that, from = the perspective of any given interface in that local network, the local = network operates as a simple star or multi-star - traffic sent from one = interface to another in the local network travels in sequence, may be = lost en route, and apart from loss is conveyed in a reasonably = predictable fashion. Same understanding. > It is possible for the client device to act as a switch or repeater to = other devices beyond it; analytically, the device might be viewed as = incorporating a switch for which the device is itself one of the = clients. In this case, the cascaded devices beyond it appear to be on = the same local network as the client itself. =46rom an IP perspective, = one would expect it to use the same subnet prefix and require the use of = ND or ND Proxy just as the client itself does. >=20 > The other view of the device is that it operates, for cascaded = devices, not as a switch but as a router. In this case, it needs a = prefix assigned to it for the cascaded LAN or LANs, and DHCP-PD is a = reasonable means for doing so. No cascading issue in the /64 case.=20 > So to me, the question of ND Proxy vs DHCP-PD comes down to the = intended structure of the network and the services it offers. If the = structure of the service provider's access network is non-broadcast = multi-access, which I understand wireless networks such as 3G/4G and LTE = to be, then it either requires the use of an ND Proxy or it must assign = its client's addresses, in the interest of uniqueness - and DHCPv6 would = still require DAD of the link-local address, which implies ND Proxy. If = the service provides no capability for cascading client networks, then = the model of masquerade of an incorporated switch, or stateful IPv6/IPv6 = translation, is required to work around the limitations of the service = provider's service. If the service provider is offering a service of = connecting client networks - for which homenet becomes directly = applicable - then DHCP-PD and some form of routing infrastructure (at = least dynamic static routing) becomes preferable for manageability = reasons. >=20 >=20 > Following that line of reasoning, I might suggest that the document = describe the non-broadcast multi-access nature of the service provider = access network and require the implementation of ND Proxy within it, = which I think it already does. It might go on to describe the nature of = the client networks it expects, offering three cases - no cascaded = devices (the service is to a contracted instrument), a mobile hot spot = (a small number of cascaded devices treated as part of the service = provider access network and uses the client instrument as a switch), or = a cascaded network (which uses the client instrument as a router, which = in turn implies the use of DHCP-PD).=20 >=20 > If that were done, would the proponents of the various views consider = their viewpoints adequately addressed? This would NOT be enough for the /64 issue to be be "adequately = addressed" (IMHO).=20 Regards, RD > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From wdec.ietf@gmail.com Thu Sep 6 01:38:30 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83B5421F8534 for ; Thu, 6 Sep 2012 01:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.565 X-Spam-Level: X-Spam-Status: No, score=-1.565 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GobSDU8gi8vG for ; Thu, 6 Sep 2012 01:38:29 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 03F5E21F8530 for ; Thu, 6 Sep 2012 01:38:28 -0700 (PDT) Received: by eaai11 with SMTP id i11so480528eaa.31 for ; Thu, 06 Sep 2012 01:38:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kR+j9WamZ0Q6W6bPgPlwkRE1wrvHAAiSOhxp79CjKRk=; b=krq+svEf0ysLnLJ3lgWHUPsp4dK5jZ9xHS0j+kO1qHXFZ3KW97pi3ycKhiu/z0dIwk d6TZtvjj6cp23Abd1Xk9lRY6/EQk+5XePZkMHTxtRjdpwny6tOQu75EZjs5IBIXhP6Cl al0s2RT9qp1PU3ndnGxUjJSLITI/rzLxxXvm48GcDyu2JbK9iDeQSzZ0bp9txFJG+xWg LRpvN0rXg6OVmAu9p5mL8TIylmiG+dMm5LbcYXYiFJ60CKWmu9uoB3MssCV4NxELlDuB aR4uXQvDnQKsu7ekl2mODIbEhe0ONMOha/wPTI+NPlsUZJJNAilLTvGtWPzgU/IZP521 Ct8w== MIME-Version: 1.0 Received: by 10.14.206.201 with SMTP id l49mr1736790eeo.3.1346920708071; Thu, 06 Sep 2012 01:38:28 -0700 (PDT) Received: by 10.14.45.68 with HTTP; Thu, 6 Sep 2012 01:38:27 -0700 (PDT) In-Reply-To: References: <504392E0.8070802@bogus.com> Date: Thu, 6 Sep 2012 10:38:27 +0200 Message-ID: From: Wojciech Dec To: Cameron Byrne , joel jaeggli Content-Type: multipart/alternative; boundary=047d7b343faa58614b04c9046afc Cc: v6ops WG Subject: Re: [v6ops] Reminder: draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 08:38:30 -0000 --047d7b343faa58614b04c9046afc Content-Type: text/plain; charset=ISO-8859-1 On 6 September 2012 04:43, Cameron Byrne wrote: > Woj, > > On Wed, Sep 5, 2012 at 8:07 AM, Wojciech Dec wrote: > > A handful of comments: > > > > 1. Section 5 > > It would be useful to indicate how this solution differs from MAP-T > > (http://tools.ietf.org/html/draft-ietf-softwire-map-01 or > > http://tools.ietf.org/html/draft-mdt-softwire-map-translation-01), as > well > > as to note the architectural underpinnings of NAT464 of the xlat solution > > which it effectively validates. > > > > No, we will not be casting 464XLAT in light of other solutions. The > WG, AFAIK, concluded this here > http://www.ietf.org/mail-archive/web/v6ops/current/msg13714.html > I didn't say that the xlat draft has to describe the MAP, what I did propose are listing points that make the xlat solution unique. It is a reasonable expectation of a draft from an SDO to at least contextualise to the reader as to how it relates to other drafts from that same SDO. This is very much in line with the conclusion in the mail you reference. At the moment the draft does not clarify that. > > And, AFAIK, MAP-T is not longer an actively pursued solution. A coin > was flipped, and the IETF moved on. > That is not correct. MAP-T remains an active Softwires WG draft, albeit with experimental status which is not definitive. The coin flip, was about one-draft or two drafts, not about MAP-T being "abandoned" > > > In that context the points that IMO could help are: > > - xlat adopts/assumes exclusively a stateful NAT64 PLAT core (map allows > > stateless or stateful NAT64) > > MAP allows stateful sharing of public IPv4 addresses on NAT64? I am > not sure how that can be given that Softwires does not have a charter > for stateful solutions. And, AFAIK, the current MAP document does not > reflect any stateful work for sharing public IPv4 addresses. Doing a > search on draft-ietf-softwire-map-02 shows no references to RFC 6145 > and RFC 6146, which are the core of 464XLAT. > map draft-02 is the "post coin flip" version for MAP-E. The equivalent MAP-T draft is being readied and we'll post it soon, but it will be as per http://tools.ietf.org/html/draft-ietf-softwire-map-01 where you will find abundant references to 6145. We have been here before. MAP and XLAT are both NAT464 architectures. A MAP CEs jsut like a clat has proven interoperability with a regular stateful NAT64 core element. The difference is that the MAP CE requires explicit provisioning. > > > - xlat focuses on deployments where client provisioning of the public > IPv4 > > address is not possible or viable (map requires explicit provisioning, > xlat > > works on defaults) > > Yes. > > i don't follow the rest of the comments and imagine the discussion > will shift after we release -08 where perhaps these details are > purposefully not specified and left to implementation discretion. > AFAIK the WG last call is for draft-08, not for some draft that has yet to be written. The comments below, which I kindly ask that they be addressed, focus on the key aspect of whether the clat operates on a host or routed mode. The draft currently confuses this as operating with NAT44 or without, which is totally orthogonal. And no, in my opinion it cannot be left to an implementation to decide whether to use this mode or another, as it directly leads to the choices of ND_proxy, etc. -Woj. > > CB > > > - An alternative of the last point could be that the solution focuses on > > deployments where the client does not require to be informed of the > public > > IPv4 address, and that default values are assumed. > > > > 2. Section 8.2.2 > > - It would help recasting this section as the "routed" clat mode. I.e the > > clat is delegated a prefix for NAT64 usage, with this prefix being > routed i) > > by the clat device towards the upstream device ii) routed by and not > seen as > > directly connected by the upstream device. > > - NAT44 is mentioned as mapping from IPv4 to IPv6. I take that this > should > > be that NAT44 is used to map several IPv4s to one external IPv4. > > - The figure reflects none of that; it shows 1:1 mapping between IPv4 and > > IPv6, and not the N:1 mapping between IPv4 and IPv4 which presumably is > the > > role of NAT44. > > - It is not stated/specified what the external IPv4 address should be, or > > how it is acquired/picked. This should be defined. > > - What is currently also missing from this section is how the clat should > > determine that it is to work in "routed" or "host" mode (section 8.3.2). > It > > is perfectly legitimate to have a PD and not use it for clat. > > > > 3. Section 8.3.2 > > - This section should be recast as xlat (clat) host mode for which the > > upstream node considers the clat and the upstream device share an > "on-link" > > prefix. > > - The ND-proxy appears NOT to be required on 3gpp, so it may be > worthwhile > > clarifying that. > > - Personally I think that adding ND-proxy is undesirable (as also stated > by > > others) and harmful (eg for upstream devices such as BNGs). Devices on > non > > 3gpp network should be directed to use the mode in section 8.3.2, which > > would eliminate the need to mention proxy-ND at all. > > > > Regards, > > Woj. > > > > > > > > > > On 2 September 2012 19:09, joel jaeggli wrote: > >> > >> Reminder, this WGLC runs through the 5th of September. > >> > >> On 8/21/12 8:45 AM, Fred Baker (fred) wrote: > >>> > >>> This is to open a two week Working Group last Call on > >>> > >>> http://tools.ietf.org/html/draft-ietf-v6ops-464xlat > >>> "464XLAT: Combination of Stateful and Stateless Translation", > Masataka > >>> Mawatari, Masanobu Kawashima, Cameron Byrne, 19-Aug-12 > >>> > >>> Please read it now. We are interested in, among other things, technical > >>> commentary on the draft and the working group's perception on its > usefulness > >>> to its target audience. > >>> _______________________________________________ > >>> v6ops mailing list > >>> v6ops@ietf.org > >>> https://www.ietf.org/mailman/listinfo/v6ops > >>> > >> > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops > > > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > --047d7b343faa58614b04c9046afc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 6 September 2012 04:43, Cameron Byrne= <cb.list6@gmail.com> wrote:
Woj,

On Wed, Sep 5, 2012 at 8:07 AM, Wojciech Dec <wdec.ietf@gmail.com> wrote:
> A handful of comments:
>
> 1. Section 5
> It would be useful to indicate how this solution differs from MAP-T > (http://tools.ietf.org/html/draft-ietf-softwire-map-01 or=
> http://tools.ietf.org/html/draft-mdt-softwire-map-= translation-01), as well
> as to note the architectural underpinnings of NAT464 of the xlat solut= ion
> which it effectively validates.
>

No, we will not be casting 464XLAT in light of other solutions. =A0Th= e
WG, AFAIK, concluded this here
http://www.ietf.org/mail-archive/web/v6ops/current/msg1= 3714.html

=A0I didn't say that the xlat dr= aft has to describe the MAP, what I did propose are listing points that mak= e the xlat solution unique. It is a reasonable expectation of a draft from = an SDO to at least contextualise to the reader as to how it relates to othe= r drafts from that same SDO. This is very much in line with the conclusion = in the mail you reference. At the moment the draft does not clarify that.
=A0

And, AFAIK, MAP-T =A0is not longer an actively pursued solution. =A0A coin<= br> was flipped, and the IETF moved on.

That is not co= rrect. MAP-T remains an active Softwires WG draft, albeit with experimental= status which is not definitive.
The coin flip, was about one-draft or t= wo drafts, not about MAP-T being "abandoned"
=A0

> In that context the points that IMO could help are:
> - xlat adopts/assumes exclusively a stateful NAT64 PLAT core (map allo= ws
> stateless or stateful NAT64)

MAP allows stateful sharing of public IPv4 addresses on NAT64? =A0I a= m
not sure how that can be given that Softwires does not have a charter
for stateful solutions. =A0And, AFAIK, the current MAP document does not reflect any stateful work for sharing public IPv4 addresses. =A0Doing a
search on draft-ietf-softwire-map-02 shows no references to RFC 6145
and RFC 6146, which are the core of 464XLAT.

map d= raft-02 is the "post coin flip" version for MAP-E. The equivalent= MAP-T draft is being readied and we'll post it soon, but it will be as= per http= ://tools.ietf.org/html/draft-ietf-softwire-map-01 where you will find a= bundant references to 6145.
We have been here before. MAP and XLAT are both NAT464 architectures. A MAP= CEs jsut like a clat has proven interoperability with a regular stateful N= AT64 core element. The difference is that the MAP CE requires explicit prov= isioning.

=A0

> - xlat focuses on deployments where client provisioning of the public = IPv4
> address is not possible or viable (map requires explicit provisioning,= xlat
> works on defaults)

Yes.

i don't follow the rest of the comments and imagine the discussion
will shift after we release -08 where perhaps these details are
purposefully not specified and left to implementation discretion.

AFAIK the WG last call is for draft-08, not for some draft = that has yet to be written.
The comments below, which I kindly ask that = they be addressed, focus on the key aspect of whether the clat operates on = a host or routed mode. The draft currently confuses this as operating with = NAT44 or without, which is totally orthogonal. And no, in my opinion it can= not be left to an implementation to decide whether to use this mode or anot= her, as it directly leads to the choices of ND_proxy, etc.

-Woj.
=A0

CB

> - An alternative of the last point could be that the solution focuses = on
> deployments where the client does not require to be informed of the pu= blic
> IPv4 address, and that default values are assumed.
>
> 2. Section 8.2.2
> - It would help recasting this section as the "routed" clat = mode. I.e the
> clat is delegated a prefix for NAT64 usage, with this prefix being rou= ted i)
> by the clat device towards the upstream device ii) routed by and not s= een as
> directly connected by the upstream device.
> - NAT44 is mentioned as mapping from IPv4 to IPv6. I take that this sh= ould
> be that NAT44 is used to map several IPv4s to one external IPv4.
> - The figure reflects none of that; it shows 1:1 mapping between IPv4 = and
> IPv6, and not the N:1 mapping between IPv4 and IPv4 which presumably i= s the
> role of NAT44.
> - It is not stated/specified what the external IPv4 address should be,= or
> how it is acquired/picked. This should be defined.
> - What is currently also missing from this section is how the clat sho= uld
> determine that it is to work in "routed" or "host"= mode (section 8.3.2). It
> is perfectly legitimate to have a PD and not use it for clat.
>
> 3. Section 8.3.2
> - This section should be recast as xlat (clat) host mode for which the=
> upstream node considers the clat and the upstream device share an &quo= t;on-link"
> prefix.
> - The ND-proxy appears NOT to be required on 3gpp, so it may be worthw= hile
> clarifying that.
> - Personally I think that adding ND-proxy is undesirable (as also stat= ed by
> others) and harmful (eg for upstream devices such as BNGs). Devices on= non
> 3gpp network should be directed to use the mode in section 8.3.2, whic= h
> would eliminate the need to mention proxy-ND at all.
>
> Regards,
> Woj.
>
>
>
>
> On 2 September 2012 19:09, joel jaeggli <joelja@bogus.com> wrote:
>>
>> Reminder, this WGLC runs through the 5th of September.
>>
>> On 8/21/12 8:45 AM, Fred Baker (fred) wrote:
>>>
>>> This is to open a two week Working Group last Call on
>>>
>>> http://tools.ietf.org/html/draft-ietf-v6ops-464xlat=
>>> =A0 =A0"464XLAT: Combination of Stateful and Stateless Tr= anslation", Masataka
>>> =A0 =A0Mawatari, Masanobu Kawashima, Cameron Byrne, 19-Aug-12<= br> >>>
>>> Please read it now. We are interested in, among other things, = technical
>>> commentary on the draft and the working group's perception= on its usefulness
>>> to its target audience.
>>> _______________________________________________
>>> v6ops mailing list
>>> v6ops@ietf.org
>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>

--047d7b343faa58614b04c9046afc-- From phdgang@gmail.com Thu Sep 6 02:47:44 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6834721F8497 for ; Thu, 6 Sep 2012 02:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MyXA1xeUY1DL for ; Thu, 6 Sep 2012 02:47:43 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4A7D721F848B for ; Thu, 6 Sep 2012 02:47:43 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so2274574vcb.31 for ; Thu, 06 Sep 2012 02:47:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AmiC7ZJiqLZLr4WTUf2Qkc+/WTzTJaJQ8UIIoyREfXI=; b=oEyad4TS9/c6BTBeB5Z9blMffMMa/+4Db1aVbUMXDQiC74Koupyxc+lWMlSCdX4LkT zki1lI+0msnki0wx3za2E5SStaubZQbDTf59FVjR9imJTu4iTagZhr6eNHh47Qk5ScMj fjYfkvwFwkgR7oQjDBx3u99mrjyGPV/I4QYawzYAKH0Smz9/G8zlZ/4+szrnwGvOBSNM zaEqrrJtjxvRJLo2H5ggvcN73x39IhoGzi5U9u4FSGLGtRqiz6h3juZBWtCDXOjmtSV6 wMZ5mF4ki9DuBN4SniTozc+cITcSexab7NLZ0GmFMYJrZ2J64c3YexmHJxetQUHqAvCv hbKQ== MIME-Version: 1.0 Received: by 10.58.102.48 with SMTP id fl16mr1338868veb.41.1346924862605; Thu, 06 Sep 2012 02:47:42 -0700 (PDT) Received: by 10.58.114.231 with HTTP; Thu, 6 Sep 2012 02:47:42 -0700 (PDT) In-Reply-To: References: Date: Thu, 6 Sep 2012 17:47:42 +0800 Message-ID: From: GangChen To: Maoke Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 09:47:44 -0000 2012/9/6, Maoke : > another objection is, Section 9 states "another, > if combined with BIH [RFC6535 ], is > a IPv4 -> IPv6 translation for > reaching IPv6-only servers from IPv4-only clients that can not > support IPv6. " > > it sounds to me that 464xlat does suggest to apply BIH, as part of the best > practice, for IPv4 client reaching IPv6-only servers. to my understanding, > there could be several alternative ways to achieve that, why we should be > bounded with BIH? > > sorry i didn't catch the discussion on this issue before. There was a quite long discussion, since you didn't follow that, I list the links below for your convenience. "A way forward for 464XLAT", started with http://www.ietf.org/mail-archive/web/v6ops/current/msg12521.html "A way forward for 464XLAT - using BIH", started with http://www.ietf.org/mail-archive/web/v6ops/current/msg12631.html "I-D Action: draft-ietf-v6ops-464xlat-02.txt" started with http://www.ietf.org/mail-archive/web/v6ops/current/msg12628.html " [v6ops] draft-ietf-v6ops-464xlat - which status?"started with http://www.ietf.org/mail-archive/web/v6ops/current/msg13035.html .... As Cameron indicated *The conclusion was that the 464XLAT is more complete by making a reference to BIH scenario.* BRs Gang > > 2012/8/22 Fred Baker (fred) > >> I should note that the current thread has a subject line reading -06.txt, >> but the current version is -07.txt. You may find the diffs (fairly >> extensive) at >> >> http://tools.ietf.org/rfcdiff?url2=draft-ietf-v6ops-464xlat-07.txt >> >> >> On Aug 21, 2012, at 8:45 AM, Fred Baker (fred) wrote: >> >> > This is to open a two week Working Group last Call on >> > >> > http://tools.ietf.org/html/draft-ietf-v6ops-464xlat >> > "464XLAT: Combination of Stateful and Stateless Translation", Masataka >> > Mawatari, Masanobu Kawashima, Cameron Byrne, 19-Aug-12 >> > >> > Please read it now. We are interested in, among other things, technical >> commentary on the draft and the working group's perception on its >> usefulness to its target audience. >> > _______________________________________________ >> > v6ops mailing list >> > v6ops@ietf.org >> > https://www.ietf.org/mailman/listinfo/v6ops >> >> ---------------------------------------------------- >> The ignorance of how to use new knowledge stockpiles exponentially. >> - Marshall McLuhan >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > From fibrib@gmail.com Thu Sep 6 04:04:40 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3680E21F8620 for ; Thu, 6 Sep 2012 04:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5nZMFs2+SQxG for ; Thu, 6 Sep 2012 04:04:36 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 9905121F861D for ; Thu, 6 Sep 2012 04:04:35 -0700 (PDT) Received: by wibhr14 with SMTP id hr14so1018334wib.13 for ; Thu, 06 Sep 2012 04:04:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RNBngN4zEfyVXpWoLRpVUykr/72YGPhvkAswf0ESJI0=; b=GXfe1xnxG/CkS6tYiLQcrSKCqNcUd/vkg6tf/55/OlvEdEO+hHr5o0U4SxEe8hMDWW N2tuo8k6KLqxUXvixYOyEF0oIQbwc16ZMKhooxzBipScGH7Ayjl4KrGmY6Fg3jrIPS6B xpevr5lbegaJBosXQj/bxoFJp0EHYnx6cNkbkYmbxa8gO+Mw5wsgRT61Z+ywubWxqh1u F1ZjyekQi+873IbFMCOV0OIZ4JxHYtcpCDarQFYC1x/PD4cwZHlz36epQMsrEvCudYFv xOCAQUByB7ZTYpoJJPP4Ss6SBbD/b9bH/OKSrBkxVJSJpT2nlxCSK2vwMHtzRS+8iVZO D99w== MIME-Version: 1.0 Received: by 10.180.79.229 with SMTP id m5mr4092780wix.13.1346929474519; Thu, 06 Sep 2012 04:04:34 -0700 (PDT) Received: by 10.223.37.78 with HTTP; Thu, 6 Sep 2012 04:04:34 -0700 (PDT) In-Reply-To: References: Date: Thu, 6 Sep 2012 20:04:34 +0900 Message-ID: From: Maoke To: GangChen Content-Type: multipart/alternative; boundary=f46d04182658ddc09b04c90674e1 Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 11:04:40 -0000 --f46d04182658ddc09b04c90674e1 Content-Type: text/plain; charset=ISO-8859-1 hi Gang, thanks for the links! 1. i don't think an early conclusion of the authors cannot be objected and thought over again, before the last call is closed. 2. i don't think it is a loss to state out of scope (or not to mention that at all) for IPv4-only app access to IPv6-only server. this could be achieved by simply configuring the IPv6-only server with an RFC6052 IPv4-translatable address and relying CLAT RFC6145 translation, or by a NAT64 located anywhere between the IPv4 app and the IPv6 domain implemented in anyway not necessarily the socket layer solution, even though BIH does possibly work, by a proxy (ALG), etc. 3. i don't think the author has tested the BIH with CLAT for an IPv6-only server, at least i have not seen any discussion/report from the authors or WG members about the test. to my understanding, the BIH/CLAT work here is not yet practiced. why we need/should put a stuff not yet practiced into a BCP?? (NOTE, the test result from you only illustrates that BIH itself is working, not the BIH/464xlat with IPv4-only app access to IPv6-only server. the tested applications, skype, MSN, etc. are none of business of the so-called IPv6-only servers). 4. i was even confused by the text "By combining 464XLAT with BIH [RFC6535], it is also possible to provide single IPv4/IPv6 translation service" itself. BIH has done the single IPv4/IPv6 translation right? what is the significance of such a "combination"? what is the add-on? integrating the compressor, condenser, expansion valve, evaporator into a fridge is an innovation (as the authors did for the 464xlat) but we cannot call a "fridge + microwave oven put on the top of the fridge" a new "architecture" of better practice. - maoke 2012/9/6 GangChen > 2012/9/6, Maoke : > > another objection is, Section 9 states "another, > > if combined with BIH [RFC6535 ], > is > > a IPv4 -> IPv6 translation for > > reaching IPv6-only servers from IPv4-only clients that can not > > support IPv6. " > > > > it sounds to me that 464xlat does suggest to apply BIH, as part of the > best > > practice, for IPv4 client reaching IPv6-only servers. to my > understanding, > > there could be several alternative ways to achieve that, why we should be > > bounded with BIH? > > > > sorry i didn't catch the discussion on this issue before. > > There was a quite long discussion, > since you didn't follow that, I list the links below for your convenience. > > "A way forward for 464XLAT", started with > http://www.ietf.org/mail-archive/web/v6ops/current/msg12521.html > "A way forward for 464XLAT - using BIH", started with > http://www.ietf.org/mail-archive/web/v6ops/current/msg12631.html > "I-D Action: draft-ietf-v6ops-464xlat-02.txt" started with > http://www.ietf.org/mail-archive/web/v6ops/current/msg12628.html > " [v6ops] draft-ietf-v6ops-464xlat - which status?"started with > http://www.ietf.org/mail-archive/web/v6ops/current/msg13035.html > .... > > As Cameron indicated *The conclusion was that the 464XLAT is more > complete by making a reference to BIH scenario.* > > BRs > > Gang > > > > > > 2012/8/22 Fred Baker (fred) > > > >> I should note that the current thread has a subject line reading > -06.txt, > >> but the current version is -07.txt. You may find the diffs (fairly > >> extensive) at > >> > >> http://tools.ietf.org/rfcdiff?url2=draft-ietf-v6ops-464xlat-07.txt > >> > >> > >> On Aug 21, 2012, at 8:45 AM, Fred Baker (fred) wrote: > >> > >> > This is to open a two week Working Group last Call on > >> > > >> > http://tools.ietf.org/html/draft-ietf-v6ops-464xlat > >> > "464XLAT: Combination of Stateful and Stateless Translation", > Masataka > >> > Mawatari, Masanobu Kawashima, Cameron Byrne, 19-Aug-12 > >> > > >> > Please read it now. We are interested in, among other things, > technical > >> commentary on the draft and the working group's perception on its > >> usefulness to its target audience. > >> > _______________________________________________ > >> > v6ops mailing list > >> > v6ops@ietf.org > >> > https://www.ietf.org/mailman/listinfo/v6ops > >> > >> ---------------------------------------------------- > >> The ignorance of how to use new knowledge stockpiles exponentially. > >> - Marshall McLuhan > >> > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops > >> > > > --f46d04182658ddc09b04c90674e1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
hi Gang,
=A0
thanks for the links!

1= . i don't think an early conclusion of the authors cannot be objected a= nd thought over again, before the last call is closed.
=A0
=
2. i don't think it is a loss to state out of scope (or not to mention = that at all) for IPv4-only app access to IPv6-only server. this could be ac= hieved by simply configuring the IPv6-only server with an RFC6052 IPv4-tran= slatable address and relying CLAT RFC6145 translation, or by a NAT64 locate= d anywhere between the IPv4 app and the IPv6 domain implemented in anyway n= ot necessarily the socket layer solution, even though BIH does possibly wor= k, by=A0a proxy (ALG), etc. =A0
=A0
3. i don't think the author has tested the BIH with = CLAT for an IPv6-only server, at least i have not=A0seen any discussion/rep= ort from the authors or WG members about the test. to my understanding, the= BIH/CLAT work here is not yet practiced. why we need/should put a stuff no= t yet practiced into a BCP??
=A0
(NOTE, the test result from=A0you only=A0illustrates tha= t BIH itself=A0is working, not the BIH/464xlat with IPv4-only app access to= IPv6-only server. the tested applications, skype, MSN, etc. are none of bu= siness of the so-called IPv6-only servers).
4. i was even confused by the text "By combining 464XL= AT with BIH [RFC6535], it is also possible to provide single IPv4/IPv6 tran= slation service" itself. BIH has done the single IPv4/IPv6 translation= right? what is the significance of such a "combination"? what is= the add-on?
=A0
integrating the compressor, condenser, expansion valve, = evaporator into a fridge is an innovation (as the authors did for the 464xl= at) but we cannot call a "fridge + microwave oven put on the top of th= e fridge" a new "architecture" of better practice.
=A0
- maoke
=A0
2012/9/6 GangChen <phdgang@gmail.com>
2012/9/6, Maoke <fibrib@gmail.com>:
> another objection is, Section 9 states "another= ,
> =A0 =A0if combined with BIH [RFC6535 <http://tools.ietf.org/html/rfc653= 5>], is
> a IPv4 -> IPv6 translation for
> =A0 =A0reaching IPv6-only servers from IPv4-only clients that can not<= br> > =A0 =A0support IPv6. "
>
> it sounds to me that 464xlat does suggest to apply BIH, as part of the= best
> practice, for IPv4 client reaching IPv6-only servers. to my understand= ing,
> there could be several alternative ways to achieve that, why we should= be
> bounded with BIH?
>
> sorry i didn't catch the discussion on this issue before.

There was a quite long discussion,
since you didn't follow that, I list the links below for your convenien= ce.

"A way forward for 464XLAT", started with
http://www.ietf.org/mail-archive/web/v6ops/current/msg1= 2521.html
"A way forward for 464XLAT - using BIH", started with
http://www.ietf.org/mail-archive/web/v6ops/current/msg1= 2631.html
"I-D Action: draft-ietf-v6ops-464xlat-02.txt" started with
http://www.ietf.org/mail-archive/web/v6ops/current/msg1= 2628.html
" [v6ops] draft-ietf-v6ops-464xlat - which status?"started with http://www.ietf.org/mail-archive/web/v6ops/current/msg1= 3035.html
....

As Cameron indicated *The conclusion was that the 464XLAT is more
complete by making a reference to BIH scenario.*

BRs

Gang


>
> 2012/8/22 Fred Baker (fred) <fred= @cisco.com>
>
>> I should note that the current thread has a subject line reading -= 06.txt,
>> but the current version is -07.txt. You may find the diffs (fairly=
>> extensive) at
>>
>> http://tools.ietf.org/rfcdiff?url2=3Ddraft= -ietf-v6ops-464xlat-07.txt
>>
>>
>> On Aug 21, 2012, at 8:45 AM, Fred Baker (fred) wrote:
>>
>> > This is to open a two week Working Group last Call on
>> >
>> > http://tools.ietf.org/html/draft-ietf-v6ops-464xlat
>> > =A0"464XLAT: Combination of Stateful and Stateless Trans= lation", Masataka
>> > =A0Mawatari, Masanobu Kawashima, Cameron Byrne, 19-Aug-12
>> >
>> > Please read it now. We are interested in, among other things,= technical
>> commentary on the draft and the working group's perception on = its
>> usefulness to its target audience.
>> > _______________________________________________
>> > v6ops mailing list
>> > v6ops@ietf.org
>> > https://www.ietf.org/mailman/listinfo/v6ops
>>
>> ----------------------------------------------------
>> The ignorance of how to use new knowledge stockpiles exponentially= .
>> =A0 =A0- Marshall McLuhan
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
>

--f46d04182658ddc09b04c90674e1-- From cb.list6@gmail.com Thu Sep 6 06:16:41 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F17021F85C3 for ; Thu, 6 Sep 2012 06:16:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1GJqkgREHuL for ; Thu, 6 Sep 2012 06:16:40 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7FEFF21F85C0 for ; Thu, 6 Sep 2012 06:16:40 -0700 (PDT) Received: by lbky2 with SMTP id y2so1288533lbk.31 for ; Thu, 06 Sep 2012 06:16:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=c7pzd0Cvv121a1VSU+SmSoFc/Iix+M6IUIzjhyay4Jk=; b=Ub/Cb0IzSeQph5CiHemItjDD7Ljs5Gt1YH/m+KWYMUDewIuFnjU/epa92PJFoSONVu ajbq/jXL1yt11R/N5mD3UpqhESumKwUAlKLBv4k/j+9tVuz/AyJSM/k4gKX+x7/L20z/ oQhQQS8SrM079SIISLXBshDZY7z03caUMjqzg9iRmqDsKbWkVoEv/1gKmnJ3oFc7Snmp cVKhikam7uC6VMk5c5lDTFY/kVIkj9Uu8xAHw8xusmuYFkmO8GXObt4IhIUi9h6wDN6J bkfFfDxowbDt799I6xL3fkf75k2FXX04rWSGmwtnBQ3dp9Y0owSJqfaVStWIdXKnHDO+ ydWQ== MIME-Version: 1.0 Received: by 10.112.83.170 with SMTP id r10mr845416lby.103.1346937399458; Thu, 06 Sep 2012 06:16:39 -0700 (PDT) Received: by 10.112.49.66 with HTTP; Thu, 6 Sep 2012 06:16:39 -0700 (PDT) Received: by 10.112.49.66 with HTTP; Thu, 6 Sep 2012 06:16:39 -0700 (PDT) In-Reply-To: References: <504392E0.8070802@bogus.com> <448050D4-84F9-4F52-BF7E-347EA451A96C@laposte.net> Date: Thu, 6 Sep 2012 06:16:39 -0700 Message-ID: From: Cameron Byrne To: Lorenzo Colitti Content-Type: multipart/alternative; boundary=f46d04016a673abd5404c9084dd9 Cc: v6ops WG Subject: Re: [v6ops] 464XLAT - support of /64 delegated prefixes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 13:16:41 -0000 --f46d04016a673abd5404c9084dd9 Content-Type: text/plain; charset=ISO-8859-1 On Sep 6, 2012 1:03 AM, "Lorenzo Colitti" wrote: > > On Thu, Sep 6, 2012 at 4:54 PM, Maoke wrote: >> >> how can we ensure the above addresses do not conflict with any manually, arbitrarily configured addresses? i am lost. :P - maoke > > > AIUI, we say "conflicts are impossible, because this is a reserved range", and then we cross our fingers. > I agree with Lorenzo's sarcasm. That said, we have been pushing this draft for a year trying to drive concensus. If we do not limit the scope to the core objective we will be here for another year while the issue of ipv4-only hosts and apps delays and hinders broader ipv6 deployment. CB > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --f46d04016a673abd5404c9084dd9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Sep 6, 2012 1:03 AM, "Lorenzo Colitti" <lorenzo@google.com> wrote:
>
> On Thu, Sep 6, 2012 at 4:54 PM, Maoke <fibrib@gmail.com> wrote:
>>
>> how=A0can we ensure the above addresses=A0do not conflict with any= manually, arbitrarily=A0configured addresses? i=A0am lost.=A0:P - maoke=A0=
>
>
> AIUI, we say "conflicts are impossible, because this is a reserve= d range", and then we cross our fingers.
>

I agree with Lorenzo's sarcasm.

That said, we have been pushing this draft for a year trying to drive co= ncensus. If we do not limit the scope to the core objective we will be here= for another year while the issue of ipv4-only hosts and apps delays and hi= nders broader ipv6 deployment.

CB
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops
>

--f46d04016a673abd5404c9084dd9-- From cb.list6@gmail.com Thu Sep 6 06:26:33 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5E4521F8569 for ; Thu, 6 Sep 2012 06:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E82NFMZxrNfz for ; Thu, 6 Sep 2012 06:26:32 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 55F1F21F855E for ; Thu, 6 Sep 2012 06:26:32 -0700 (PDT) Received: by lbky2 with SMTP id y2so1296587lbk.31 for ; Thu, 06 Sep 2012 06:26:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=81SqPxIwaKAjGXhQ1EfC0zd6LqhWFpSaa/PbH0/7lv8=; b=iAg7v65x1czwvQFOjp1b79enDCGugMz8URo4h37WXEYRcuTknrlXPso5iR4UMreSZF lzfcMqCwbUM0z9IknAg7CPDi680VWII30EZmmcHT9kJKmadArq/kHsC1kCfNVv16INa8 aikd49d0cmNsWuuB6uxYceukTVxzYESr9RrPo1XNNXrZgqsx4cuPIlabSejujF9HCdn6 dXsqbui970tING+LWu6zWtw8uPrVtLDAO/EZ+bMsfDWTdrESSeNwLNr6rO6nvK5xezb+ TiCjIKM9yMY1GbdLKFtLSaO3F9GeysMYzDCp3Wu0iW6A5aXbNNoWh68Evb+jhBHhYJFp GpZQ== MIME-Version: 1.0 Received: by 10.112.38.163 with SMTP id h3mr856347lbk.130.1346937991170; Thu, 06 Sep 2012 06:26:31 -0700 (PDT) Received: by 10.112.49.66 with HTTP; Thu, 6 Sep 2012 06:26:30 -0700 (PDT) Received: by 10.112.49.66 with HTTP; Thu, 6 Sep 2012 06:26:30 -0700 (PDT) In-Reply-To: References: <504392E0.8070802@bogus.com> Date: Thu, 6 Sep 2012 06:26:30 -0700 Message-ID: From: Cameron Byrne To: Wojciech Dec Content-Type: multipart/alternative; boundary=e0cb4efe2a7a7f8bb804c9087067 Cc: v6ops WG Subject: Re: [v6ops] Reminder: draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 13:26:34 -0000 --e0cb4efe2a7a7f8bb804c9087067 Content-Type: text/plain; charset=ISO-8859-1 On Sep 6, 2012 1:38 AM, "Wojciech Dec" wrote: > > > > On 6 September 2012 04:43, Cameron Byrne wrote: >> >> Woj, >> >> On Wed, Sep 5, 2012 at 8:07 AM, Wojciech Dec wrote: >> > A handful of comments: >> > >> > 1. Section 5 >> > It would be useful to indicate how this solution differs from MAP-T >> > (http://tools.ietf.org/html/draft-ietf-softwire-map-01 or >> > http://tools.ietf.org/html/draft-mdt-softwire-map-translation-01), as well >> > as to note the architectural underpinnings of NAT464 of the xlat solution >> > which it effectively validates. >> > >> >> No, we will not be casting 464XLAT in light of other solutions. The >> WG, AFAIK, concluded this here >> http://www.ietf.org/mail-archive/web/v6ops/current/msg13714.html > > > I didn't say that the xlat draft has to describe the MAP, what I did propose are listing points that make the xlat solution unique. It is a reasonable expectation of a draft from an SDO to at least contextualise to the reader as to how it relates to other drafts from that same SDO. This is very much in line with the conclusion in the mail you reference. At the moment the draft does not clarify that. > This was included before and has beeen removed because those words were not timeless or essential to a standards doc. That was thd WG feedback. > >> >> >> And, AFAIK, MAP-T is not longer an actively pursued solution. A coin >> was flipped, and the IETF moved on. > > > That is not correct. MAP-T remains an active Softwires WG draft, albeit with experimental status which is not definitive. > The coin flip, was about one-draft or two drafts, not about MAP-T being "abandoned" > >> >> >> > In that context the points that IMO could help are: >> > - xlat adopts/assumes exclusively a stateful NAT64 PLAT core (map allows >> > stateless or stateful NAT64) >> >> MAP allows stateful sharing of public IPv4 addresses on NAT64? I am >> not sure how that can be given that Softwires does not have a charter >> for stateful solutions. And, AFAIK, the current MAP document does not >> reflect any stateful work for sharing public IPv4 addresses. Doing a >> search on draft-ietf-softwire-map-02 shows no references to RFC 6145 >> and RFC 6146, which are the core of 464XLAT. > > > map draft-02 is the "post coin flip" version for MAP-E. The equivalent MAP-T draft is being readied and we'll post it soon, but it will be as per http://tools.ietf.org/html/draft-ietf-softwire-map-01 where you will find abundant references to 6145. > We have been here before. MAP and XLAT are both NAT464 architectures. A MAP CEs jsut like a clat has proven interoperability with a regular stateful NAT64 core element. The difference is that the MAP CE requires explicit provisioning. > We have been here before, as you noted. If you want text, suggest it. You know the difference between the 2, no? CB > >> >> >> > - xlat focuses on deployments where client provisioning of the public IPv4 >> > address is not possible or viable (map requires explicit provisioning, xlat >> > works on defaults) >> >> Yes. >> >> i don't follow the rest of the comments and imagine the discussion >> will shift after we release -08 where perhaps these details are >> purposefully not specified and left to implementation discretion. > > > AFAIK the WG last call is for draft-08, not for some draft that has yet to be written. > The comments below, which I kindly ask that they be addressed, focus on the key aspect of whether the clat operates on a host or routed mode. The draft currently confuses this as operating with NAT44 or without, which is totally orthogonal. And no, in my opinion it cannot be left to an implementation to decide whether to use this mode or another, as it directly leads to the choices of ND_proxy, etc. > > -Woj. > >> >> >> CB >> >> > - An alternative of the last point could be that the solution focuses on >> > deployments where the client does not require to be informed of the public >> > IPv4 address, and that default values are assumed. >> > >> > 2. Section 8.2.2 >> > - It would help recasting this section as the "routed" clat mode. I.e the >> > clat is delegated a prefix for NAT64 usage, with this prefix being routed i) >> > by the clat device towards the upstream device ii) routed by and not seen as >> > directly connected by the upstream device. >> > - NAT44 is mentioned as mapping from IPv4 to IPv6. I take that this should >> > be that NAT44 is used to map several IPv4s to one external IPv4. >> > - The figure reflects none of that; it shows 1:1 mapping between IPv4 and >> > IPv6, and not the N:1 mapping between IPv4 and IPv4 which presumably is the >> > role of NAT44. >> > - It is not stated/specified what the external IPv4 address should be, or >> > how it is acquired/picked. This should be defined. >> > - What is currently also missing from this section is how the clat should >> > determine that it is to work in "routed" or "host" mode (section 8.3.2). It >> > is perfectly legitimate to have a PD and not use it for clat. >> > >> > 3. Section 8.3.2 >> > - This section should be recast as xlat (clat) host mode for which the >> > upstream node considers the clat and the upstream device share an "on-link" >> > prefix. >> > - The ND-proxy appears NOT to be required on 3gpp, so it may be worthwhile >> > clarifying that. >> > - Personally I think that adding ND-proxy is undesirable (as also stated by >> > others) and harmful (eg for upstream devices such as BNGs). Devices on non >> > 3gpp network should be directed to use the mode in section 8.3.2, which >> > would eliminate the need to mention proxy-ND at all. >> > >> > Regards, >> > Woj. >> > >> > >> > >> > >> > On 2 September 2012 19:09, joel jaeggli wrote: >> >> >> >> Reminder, this WGLC runs through the 5th of September. >> >> >> >> On 8/21/12 8:45 AM, Fred Baker (fred) wrote: >> >>> >> >>> This is to open a two week Working Group last Call on >> >>> >> >>> http://tools.ietf.org/html/draft-ietf-v6ops-464xlat >> >>> "464XLAT: Combination of Stateful and Stateless Translation", Masataka >> >>> Mawatari, Masanobu Kawashima, Cameron Byrne, 19-Aug-12 >> >>> >> >>> Please read it now. We are interested in, among other things, technical >> >>> commentary on the draft and the working group's perception on its usefulness >> >>> to its target audience. >> >>> _______________________________________________ >> >>> v6ops mailing list >> >>> v6ops@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/v6ops >> >>> >> >> >> >> _______________________________________________ >> >> v6ops mailing list >> >> v6ops@ietf.org >> >> https://www.ietf.org/mailman/listinfo/v6ops >> > >> > >> > >> > _______________________________________________ >> > v6ops mailing list >> > v6ops@ietf.org >> > https://www.ietf.org/mailman/listinfo/v6ops >> > > > --e0cb4efe2a7a7f8bb804c9087067 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Sep 6, 2012 1:38 AM, "Wojciech Dec" <wdec.ietf@gmail.com> wrote:
>
>
>
> On 6 September 2012 04:43, Cameron Byrne <cb.list6@gmail.com> wrote:
>>
>> Woj,
>>
>> On Wed, Sep 5, 2012 at 8:07 AM, Wojciech Dec <wdec.ietf@gmail.com> wrote:
>> > A handful of comments:
>> >
>> > 1. Section 5
>> > It would be useful to indicate how this solution differs from= MAP-T
>> > (http://tools.ietf.org/html/draft-ietf-softwire-map-01 or
>> > http://tools.ietf.org/html/draft-mdt-softwire-map-translati= on-01), as well
>> > as to note the architectural underpinnings of NAT464 of the x= lat solution
>> > which it effectively validates.
>> >
>>
>> No, we will not be casting 464XLAT in light of other solutions. = =A0The
>> WG, AFAIK, concluded this here
>> http://www.ietf.org/mail-archive/web/v6ops/current/msg13714.html=
>
>
> =A0I didn't say that the xlat draft has to describe the MAP, what = I did propose are listing points that make the xlat solution unique. It is = a reasonable expectation of a draft from an SDO to at least contextualise t= o the reader as to how it relates to other drafts from that same SDO. This = is very much in line with the conclusion in the mail you reference. At the = moment the draft does not clarify that.
>

This was included before and has beeen removed because those words were = not timeless or essential to a standards doc. That was thd WG feedback.

> =A0
>>
>>
>> And, AFAIK, MAP-T =A0is not longer an actively pursued solution. = =A0A coin
>> was flipped, and the IETF moved on.
>
>
> That is not correct. MAP-T remains an active Softwires WG draft, albei= t with experimental status which is not definitive.
> The coin flip, was about one-draft or two drafts, not about MAP-T bein= g "abandoned"
> =A0
>>
>>
>> > In that context the points that IMO could help are:
>> > - xlat adopts/assumes exclusively a stateful NAT64 PLAT core = (map allows
>> > stateless or stateful NAT64)
>>
>> MAP allows stateful sharing of public IPv4 addresses on NAT64? =A0= I am
>> not sure how that can be given that Softwires does not have a char= ter
>> for stateful solutions. =A0And, AFAIK, the current MAP document do= es not
>> reflect any stateful work for sharing public IPv4 addresses. =A0Do= ing a
>> search on draft-ietf-softwire-map-02 shows no references to RFC 61= 45
>> and RFC 6146, which are the core of 464XLAT.
>
>
> map draft-02 is the "post coin flip" version for MAP-E. The = equivalent MAP-T draft is being readied and we'll post it soon, but it = will be as per http://tools.ietf.org/html/draft-ietf-softwire-map-01 where you w= ill find abundant references to 6145.
> We have been here before. MAP and XLAT are both NAT464 architectures. = A MAP CEs jsut like a clat has proven interoperability with a regular state= ful NAT64 core element. The difference is that the MAP CE requires explicit= provisioning.
>

We have been here before, as you noted. If you want text, suggest it. Yo= u know the difference between the 2, no?

CB
> =A0
>>
>>
>> > - xlat focuses on deployments where client provisioning of th= e public IPv4
>> > address is not possible or viable (map requires explicit prov= isioning, xlat
>> > works on defaults)
>>
>> Yes.
>>
>> i don't follow the rest of the comments and imagine the discus= sion
>> will shift after we release -08 where perhaps these details are >> purposefully not specified and left to implementation discretion.<= br> >
>
> AFAIK the WG last call is for draft-08, not for some draft that has ye= t to be written.
> The comments below, which I kindly ask that they be addressed, focus o= n the key aspect of whether the clat operates on a host or routed mode. The= draft currently confuses this as operating with NAT44 or without, which is= totally orthogonal. And no, in my opinion it cannot be left to an implemen= tation to decide whether to use this mode or another, as it directly leads = to the choices of ND_proxy, etc.
>
> -Woj.
> =A0
>>
>>
>> CB
>>
>> > - An alternative of the last point could be that the solution= focuses on
>> > deployments where the client does not require to be informed = of the public
>> > IPv4 address, and that default values are assumed.
>> >
>> > 2. Section 8.2.2
>> > - It would help recasting this section as the "routed&qu= ot; clat mode. I.e the
>> > clat is delegated a prefix for NAT64 usage, with this prefix = being routed i)
>> > by the clat device towards the upstream device ii) routed by = and not seen as
>> > directly connected by the upstream device.
>> > - NAT44 is mentioned as mapping from IPv4 to IPv6. I take tha= t this should
>> > be that NAT44 is used to map several IPv4s to one external IP= v4.
>> > - The figure reflects none of that; it shows 1:1 mapping betw= een IPv4 and
>> > IPv6, and not the N:1 mapping between IPv4 and IPv4 which pre= sumably is the
>> > role of NAT44.
>> > - It is not stated/specified what the external IPv4 address s= hould be, or
>> > how it is acquired/picked. This should be defined.
>> > - What is currently also missing from this section is how the= clat should
>> > determine that it is to work in "routed" or "h= ost" mode (section 8.3.2). It
>> > is perfectly legitimate to have a PD and not use it for clat.=
>> >
>> > 3. Section 8.3.2
>> > - This section should be recast as xlat (clat) host mode for = which the
>> > upstream node considers the clat and the upstream device shar= e an "on-link"
>> > prefix.
>> > - The ND-proxy appears NOT to be required on 3gpp, so it may = be worthwhile
>> > clarifying that.
>> > - Personally I think that adding ND-proxy is undesirable (as = also stated by
>> > others) and harmful (eg for upstream devices such as BNGs). D= evices on non
>> > 3gpp network should be directed to use the mode in section 8.= 3.2, which
>> > would eliminate the need to mention proxy-ND at all.
>> >
>> > Regards,
>> > Woj.
>> >
>> >
>> >
>> >
>> > On 2 September 2012 19:09, joel jaeggli <joelja@bogus.com> wrote:
>> >>
>> >> Reminder, this WGLC runs through the 5th of September. >> >>
>> >> On 8/21/12 8:45 AM, Fred Baker (fred) wrote:
>> >>>
>> >>> This is to open a two week Working Group last Call on=
>> >>>
>> >>> http://tools.ietf.org/html/draft-ietf-v6ops-464xlat
>> >>> =A0 =A0"464XLAT: Combination of Stateful and Sta= teless Translation", Masataka
>> >>> =A0 =A0Mawatari, Masanobu Kawashima, Cameron Byrne, 1= 9-Aug-12
>> >>>
>> >>> Please read it now. We are interested in, among other= things, technical
>> >>> commentary on the draft and the working group's p= erception on its usefulness
>> >>> to its target audience.
>> >>> _______________________________________________
>> >>> v6ops mailing list
>> >>> v6ops@ietf.org<= br> >> >>> https://www.ietf.org/mailman/listinfo/v6ops
>> >>>
>> >>
>> >> _______________________________________________
>> >> v6ops mailing list
>> >> v6ops@ietf.org
>> >> h= ttps://www.ietf.org/mailman/listinfo/v6ops
>> >
>> >
>> >
>> > _______________________________________________
>> > v6ops mailing list
>> > v6ops@ietf.org
>> > https= ://www.ietf.org/mailman/listinfo/v6ops
>> >
>
>

--e0cb4efe2a7a7f8bb804c9087067-- From wdec.ietf@gmail.com Thu Sep 6 06:47:31 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA57E21F84B8 for ; Thu, 6 Sep 2012 06:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 tagged_above=-999 required=5 tests=[AWL=0.417, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cg8L8CsR3e5f for ; Thu, 6 Sep 2012 06:47:30 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id B57A221F8455 for ; Thu, 6 Sep 2012 06:47:29 -0700 (PDT) Received: by eaai11 with SMTP id i11so599265eaa.31 for ; Thu, 06 Sep 2012 06:47:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tX0P7B3Fem5jBNvZXWNCWJZef6OanDQfuLcSnVs+PEQ=; b=hI4gnbmjU7/DFpPJa5olNPYM3e1sz/o7h8MBo1HWppa7gPXYGNTMdPz3dgLHePX+Qs XdA6pW9CxcGH9sgab+Z1HWldW+s9931ub2ULFevag9wdsRjiqaQCuY56cbzeeqBhSUCl cFmS1ZflkNG03M/tKEeYLkcvTj40BF2BfLJDQmTzLmrFRINOFDlav+tOfmPWYuS3USP6 +oWnaQcCyIL30gvsmgknxvPPZxiDdX+FzviPVECsyoVLKFtUZCbl3c6lKyljr+mjJSEI nw2eblRS5gSvCG+8F3OWwrCN/EYh3MrF2esd1BLlQWKr0J4IZjvHAClVipCtYeNplfvk AU7Q== MIME-Version: 1.0 Received: by 10.14.203.70 with SMTP id e46mr3111136eeo.2.1346939248829; Thu, 06 Sep 2012 06:47:28 -0700 (PDT) Received: by 10.14.45.68 with HTTP; Thu, 6 Sep 2012 06:47:28 -0700 (PDT) In-Reply-To: References: <504392E0.8070802@bogus.com> Date: Thu, 6 Sep 2012 15:47:28 +0200 Message-ID: From: Wojciech Dec To: Cameron Byrne Content-Type: multipart/alternative; boundary=047d7b3440f475e38204c908bb4c Cc: v6ops WG Subject: Re: [v6ops] Reminder: draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 13:47:31 -0000 --047d7b3440f475e38204c908bb4c Content-Type: text/plain; charset=ISO-8859-1 On 6 September 2012 15:26, Cameron Byrne wrote: > > On Sep 6, 2012 1:38 AM, "Wojciech Dec" wrote: > > > > > > > > On 6 September 2012 04:43, Cameron Byrne wrote: > >> > >> Woj, > >> > >> On Wed, Sep 5, 2012 at 8:07 AM, Wojciech Dec > wrote: > >> > A handful of comments: > >> > > >> > 1. Section 5 > >> > It would be useful to indicate how this solution differs from MAP-T > >> > (http://tools.ietf.org/html/draft-ietf-softwire-map-01 or > >> > http://tools.ietf.org/html/draft-mdt-softwire-map-translation-01), > as well > >> > as to note the architectural underpinnings of NAT464 of the xlat > solution > >> > which it effectively validates. > >> > > >> > >> No, we will not be casting 464XLAT in light of other solutions. The > >> WG, AFAIK, concluded this here > >> http://www.ietf.org/mail-archive/web/v6ops/current/msg13714.html > > > > > > I didn't say that the xlat draft has to describe the MAP, what I did > propose are listing points that make the xlat solution unique. It is a > reasonable expectation of a draft from an SDO to at least contextualise to > the reader as to how it relates to other drafts from that same SDO. This is > very much in line with the conclusion in the mail you reference. At the > moment the draft does not clarify that. > > > > This was included before and has beeen removed because those words were > not timeless or essential to a standards doc. That was thd WG feedback. > What was included? Certainly NOT the points i suggested. If you're seeking for words that are timeless, then I think that the whole of section 5, entitled "Motivation and Uniqueness" can be deleted. Overall, it may help if you actually took on board constructive feedback. The points I proposed indicate what is unique in xlat solution. > > >> > >> > >> And, AFAIK, MAP-T is not longer an actively pursued solution. A coin > >> was flipped, and the IETF moved on. > > > > > > That is not correct. MAP-T remains an active Softwires WG draft, albeit > with experimental status which is not definitive. > > The coin flip, was about one-draft or two drafts, not about MAP-T being > "abandoned" > > > >> > >> > >> > In that context the points that IMO could help are: > >> > - xlat adopts/assumes exclusively a stateful NAT64 PLAT core (map > allows > >> > stateless or stateful NAT64) > >> > >> MAP allows stateful sharing of public IPv4 addresses on NAT64? I am > >> not sure how that can be given that Softwires does not have a charter > >> for stateful solutions. And, AFAIK, the current MAP document does not > >> reflect any stateful work for sharing public IPv4 addresses. Doing a > >> search on draft-ietf-softwire-map-02 shows no references to RFC 6145 > >> and RFC 6146, which are the core of 464XLAT. > > > > > > map draft-02 is the "post coin flip" version for MAP-E. The equivalent > MAP-T draft is being readied and we'll post it soon, but it will be as per > http://tools.ietf.org/html/draft-ietf-softwire-map-01 where you will find > abundant references to 6145. > > We have been here before. MAP and XLAT are both NAT464 architectures. A > MAP CEs jsut like a clat has proven interoperability with a regular > stateful NAT64 core element. The difference is that the MAP CE requires > explicit provisioning. > > > > We have been here before, as you noted. If you want text, suggest it. You > know the difference between the 2, no? > Reposting the suggested text & changes: Section 5 - xlat adopts/assumes exclusively a stateful NAT64 PLAT core - xlat focuses on deployments where client provisioning of the public IPv4 address is not possible or viable - An alternative of the last point could be that the solution focuses on deployments where the client does not require to be informed of the public IPv4 address, and that default values are assumed. 2. Section 8.2.2 - It would help recasting this section as the "routed" clat mode. I.e the clat is delegated a prefix for NAT64 usage, with this prefix being routed i) by the clat device towards the upstream device ii) routed by and not seen as directly connected by the upstream device. - NAT44 is mentioned as mapping from IPv4 to IPv6. I take that this should be that NAT44 is used to map several IPv4s to one external IPv4. - The figure reflects none of that; it shows 1:1 mapping between IPv4 and IPv6, and not the N:1 mapping between IPv4 and IPv4 which presumably is the role of NAT44. - It is not stated/specified what the external IPv4 address should be, or how it is acquired/picked. This should be defined. - What is currently also missing from this section is how the clat should determine that it is to work in "routed" or "host" mode (section 8.3.2). It is perfectly legitimate to have a PD and not use it for clat. 3. Section 8.3.2 - This section should be recast as xlat (clat) host mode for which the upstream node considers the clat and the upstream device share an "on-link" prefix. - The ND-proxy appears NOT to be required on 3gpp, so it may be worthwhile clarifying that. - Personally I think that adding ND-proxy is undesirable (as also stated by others) and harmful (eg for upstream devices such as BNGs). Devices on non 3gpp network should be directed to use the mode in section 8.3.2, which would eliminate the need to mention proxy-ND at all. -Woj. > CB > > > > >> > >> > >> > - xlat focuses on deployments where client provisioning of the public > IPv4 > >> > address is not possible or viable (map requires explicit > provisioning, xlat > >> > works on defaults) > >> > >> Yes. > >> > >> i don't follow the rest of the comments and imagine the discussion > >> will shift after we release -08 where perhaps these details are > >> purposefully not specified and left to implementation discretion. > > > > > > AFAIK the WG last call is for draft-08, not for some draft that has yet > to be written. > > The comments below, which I kindly ask that they be addressed, focus on > the key aspect of whether the clat operates on a host or routed mode. The > draft currently confuses this as operating with NAT44 or without, which is > totally orthogonal. And no, in my opinion it cannot be left to an > implementation to decide whether to use this mode or another, as it > directly leads to the choices of ND_proxy, etc. > > > > -Woj. > > > >> > >> > >> CB > >> > >> > - An alternative of the last point could be that the solution focuses > on > >> > deployments where the client does not require to be informed of the > public > >> > IPv4 address, and that default values are assumed. > >> > > >> > 2. Section 8.2.2 > >> > - It would help recasting this section as the "routed" clat mode. I.e > the > >> > clat is delegated a prefix for NAT64 usage, with this prefix being > routed i) > >> > by the clat device towards the upstream device ii) routed by and not > seen as > >> > directly connected by the upstream device. > >> > - NAT44 is mentioned as mapping from IPv4 to IPv6. I take that this > should > >> > be that NAT44 is used to map several IPv4s to one external IPv4. > >> > - The figure reflects none of that; it shows 1:1 mapping between IPv4 > and > >> > IPv6, and not the N:1 mapping between IPv4 and IPv4 which presumably > is the > >> > role of NAT44. > >> > - It is not stated/specified what the external IPv4 address should > be, or > >> > how it is acquired/picked. This should be defined. > >> > - What is currently also missing from this section is how the clat > should > >> > determine that it is to work in "routed" or "host" mode (section > 8.3.2). It > >> > is perfectly legitimate to have a PD and not use it for clat. > >> > > >> > 3. Section 8.3.2 > >> > - This section should be recast as xlat (clat) host mode for which the > >> > upstream node considers the clat and the upstream device share an > "on-link" > >> > prefix. > >> > - The ND-proxy appears NOT to be required on 3gpp, so it may be > worthwhile > >> > clarifying that. > >> > - Personally I think that adding ND-proxy is undesirable (as also > stated by > >> > others) and harmful (eg for upstream devices such as BNGs). Devices > on non > >> > 3gpp network should be directed to use the mode in section 8.3.2, > which > >> > would eliminate the need to mention proxy-ND at all. > >> > > >> > Regards, > >> > Woj. > >> > > >> > > >> > > >> > > >> > On 2 September 2012 19:09, joel jaeggli wrote: > >> >> > >> >> Reminder, this WGLC runs through the 5th of September. > >> >> > >> >> On 8/21/12 8:45 AM, Fred Baker (fred) wrote: > >> >>> > >> >>> This is to open a two week Working Group last Call on > >> >>> > >> >>> http://tools.ietf.org/html/draft-ietf-v6ops-464xlat > >> >>> "464XLAT: Combination of Stateful and Stateless Translation", > Masataka > >> >>> Mawatari, Masanobu Kawashima, Cameron Byrne, 19-Aug-12 > >> >>> > >> >>> Please read it now. We are interested in, among other things, > technical > >> >>> commentary on the draft and the working group's perception on its > usefulness > >> >>> to its target audience. > >> >>> _______________________________________________ > >> >>> v6ops mailing list > >> >>> v6ops@ietf.org > >> >>> https://www.ietf.org/mailman/listinfo/v6ops > >> >>> > >> >> > >> >> _______________________________________________ > >> >> v6ops mailing list > >> >> v6ops@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/v6ops > >> > > >> > > >> > > >> > _______________________________________________ > >> > v6ops mailing list > >> > v6ops@ietf.org > >> > https://www.ietf.org/mailman/listinfo/v6ops > >> > > > > > > > --047d7b3440f475e38204c908bb4c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 6 September 2012 15:26, Cameron Byrne= <cb.list6@gmail.com> wrote:


On Sep 6, 2012 1:38 AM, "Wojciech Dec" <wdec.ietf@gmail.com> wrote:
>
>
>
> On 6 September 2012 04:43, Cameron Byrne <cb.list6@gmail.com> wrote:
>>
>> Woj,
>>
>> On Wed, Sep 5, 2012 at 8:07 AM, Wojciech Dec <wdec.ietf@gmail.com> wrote:<= br> >> > A handful of comments:
>> >
>> > 1. Section 5
>> > It would be useful to indicate how this solution differs from= MAP-T
>> > (http://tools.ietf.org/html/draft-ietf-softwire-map-= 01 or
>> > http://tools.ietf.org/html/draft-mdt-soft= wire-map-translation-01), as well
>> > as to note the architectural underpinnings of NAT464 of the x= lat solution
>> > which it effectively validates.
>> >
>>
>> No, we will not be casting 464XLAT in light of other solutions. = =A0The
>> WG, AFAIK, concluded this here
>> http://www.ietf.org/mail-archive/web/v6ops/cur= rent/msg13714.html
>
>
> =A0I didn't say that the xlat draft has to describe the MAP, what = I did propose are listing points that make the xlat solution unique. It is = a reasonable expectation of a draft from an SDO to at least contextualise t= o the reader as to how it relates to other drafts from that same SDO. This = is very much in line with the conclusion in the mail you reference. At the = moment the draft does not clarify that.
>

This was included before and has beeen removed because those words= were not timeless or essential to a standards doc. That was thd WG feedbac= k.

What was included? Certainly NOT the points i sugge= sted.
If you're seeking for words that are timeless, then I think that the wh= ole of section 5, entitled "Motivation and Uniqueness" can be del= eted.

Overall, it may help if you actually took on board constructiv= e feedback. The points I proposed indicate what is unique in xlat solution.=

> =A0
>>
>>
>> And, AFAIK, MAP-T =A0is not longer an actively pursued solution. = =A0A coin
>> was flipped, and the IETF moved on.
>
>
> That is not correct. MAP-T remains an active Softwires WG draft, albei= t with experimental status which is not definitive.
> The coin flip, was about one-draft or two drafts, not about MAP-T bein= g "abandoned"
> =A0
>>
>>
>> > In that context the points that IMO could help are:
>> > - xlat adopts/assumes exclusively a stateful NAT64 PLAT core = (map allows
>> > stateless or stateful NAT64)
>>
>> MAP allows stateful sharing of public IPv4 addresses on NAT64? =A0= I am
>> not sure how that can be given that Softwires does not have a char= ter
>> for stateful solutions. =A0And, AFAIK, the current MAP document do= es not
>> reflect any stateful work for sharing public IPv4 addresses. =A0Do= ing a
>> search on draft-ietf-softwire-map-02 shows no references to RFC 61= 45
>> and RFC 6146, which are the core of 464XLAT.
>
>
> map draft-02 is the "post coin flip" version for MAP-E. The = equivalent MAP-T draft is being readied and we'll post it soon, but it = will be as per http://tools.ietf.org/html/draft-ietf-softwire-map-= 01 where you will find abundant references to 6145.
> We have been here before. MAP and XLAT are both NAT464 architectures. = A MAP CEs jsut like a clat has proven interoperability with a regular state= ful NAT64 core element. The difference is that the MAP CE requires explicit= provisioning.
>

We have been here before, as you noted. If you want text, suggest = it. You know the difference between the 2, no?


Rep= osting the suggested text & changes:
Section 5
- xlat adopts/assu= mes exclusively a stateful NAT64 PLAT core
- xlat focuses on deployments where client provisioning of the public=20 IPv4 address is not possible or viable
- An alternative of the last point could be that the solution focuses on deployments where the client does not require to be informed of the=20 public IPv4 address, and that default values are assumed.

2. Section= 8.2.2
- It would help recasting this section as the "routed" clat mode.= I.e=20 the clat is delegated a prefix for NAT64 usage, with this prefix being=20 routed i) by the clat device towards the upstream device ii) routed by=20 and not seen as directly connected by the upstream device.
- NAT44 is mentioned as mapping from IPv4 to IPv6. I take that this=20 should be that NAT44 is used to map several IPv4s to one external IPv4.
= - The figure reflects none of that; it shows 1:1 mapping between IPv4 and IPv6, and not the N:1 mapping between IPv4 and IPv4 which presumably is the role of NAT44.
- It is not stated/specified what the external IPv4 address should be, or h= ow it is acquired/picked. This should be defined.
- What is currently also missing from this section is how the clat should determine that it is to work in "routed" or "host" mod= e (section=20 8.3.2). It is perfectly legitimate to have a PD and not use it for=20 clat.=A0

3. Section 8.3.2
- This section should be recast as xlat (clat)=20 host mode for which the upstream node considers the clat and the=20 upstream device share an "on-link" prefix.
- The ND-proxy appe= ars NOT to be required on 3gpp, so it may be worthwhile clarifying that. - Personally I think that adding ND-proxy is undesirable (as also stated by others) and harmful (eg for upstream devices such as BNGs). Devices=20 on non 3gpp network should be directed to use the mode in section 8.3.2, which would eliminate the need to mention proxy-ND at all.

-Woj.

CB


> =A0
>>
>>
>> > - xlat focuses on deployments where client provisioning of th= e public IPv4
>> > address is not possible or viable (map requires explicit prov= isioning, xlat
>> > works on defaults)
>>
>> Yes.
>>
>> i don't follow the rest of the comments and imagine the discus= sion
>> will shift after we release -08 where perhaps these details are >> purposefully not specified and left to implementation discretion.<= br> >
>
> AFAIK the WG last call is for draft-08, not for some draft that has ye= t to be written.
> The comments below, which I kindly ask that they be addressed, focus o= n the key aspect of whether the clat operates on a host or routed mode. The= draft currently confuses this as operating with NAT44 or without, which is= totally orthogonal. And no, in my opinion it cannot be left to an implemen= tation to decide whether to use this mode or another, as it directly leads = to the choices of ND_proxy, etc.
>
> -Woj.
> =A0
>>
>>
>> CB
>>
>> > - An alternative of the last point could be that the solution= focuses on
>> > deployments where the client does not require to be informed = of the public
>> > IPv4 address, and that default values are assumed.
>> >
>> > 2. Section 8.2.2
>> > - It would help recasting this section as the "routed&qu= ot; clat mode. I.e the
>> > clat is delegated a prefix for NAT64 usage, with this prefix = being routed i)
>> > by the clat device towards the upstream device ii) routed by = and not seen as
>> > directly connected by the upstream device.
>> > - NAT44 is mentioned as mapping from IPv4 to IPv6. I take tha= t this should
>> > be that NAT44 is used to map several IPv4s to one external IP= v4.
>> > - The figure reflects none of that; it shows 1:1 mapping betw= een IPv4 and
>> > IPv6, and not the N:1 mapping between IPv4 and IPv4 which pre= sumably is the
>> > role of NAT44.
>> > - It is not stated/specified what the external IPv4 address s= hould be, or
>> > how it is acquired/picked. This should be defined.
>> > - What is currently also missing from this section is how the= clat should
>> > determine that it is to work in "routed" or "h= ost" mode (section 8.3.2). It
>> > is perfectly legitimate to have a PD and not use it for clat.=
>> >
>> > 3. Section 8.3.2
>> > - This section should be recast as xlat (clat) host mode for = which the
>> > upstream node considers the clat and the upstream device shar= e an "on-link"
>> > prefix.
>> > - The ND-proxy appears NOT to be required on 3gpp, so it may = be worthwhile
>> > clarifying that.
>> > - Personally I think that adding ND-proxy is undesirable (as = also stated by
>> > others) and harmful (eg for upstream devices such as BNGs). D= evices on non
>> > 3gpp network should be directed to use the mode in section 8.= 3.2, which
>> > would eliminate the need to mention proxy-ND at all.
>> >
>> > Regards,
>> > Woj.
>> >
>> >
>> >
>> >
>> > On 2 September 2012 19:09, joel jaeggli <joelja@bogus.com> wrote:
>> >>
>> >> Reminder, this WGLC runs through the 5th of September. >> >>
>> >> On 8/21/12 8:45 AM, Fred Baker (fred) wrote:
>> >>>
>> >>> This is to open a two week Working Group last Call on=
>> >>>
>> >>> http://tools.ietf.org/html/draft-ietf-v6ops-46= 4xlat
>> >>> =A0 =A0"464XLAT: Combination of Stateful and Sta= teless Translation", Masataka
>> >>> =A0 =A0Mawatari, Masanobu Kawashima, Cameron Byrne, 1= 9-Aug-12
>> >>>
>> >>> Please read it now. We are interested in, among other= things, technical
>> >>> commentary on the draft and the working group's p= erception on its usefulness
>> >>> to its target audience.
>> >>> _______________________________________________
>> >>> v6ops mailing list
>> >>> v= 6ops@ietf.org
>> >>> https://www.ietf.org/mailman/listinfo/v6ops
>> >>>
>> >>
>> >> _______________________________________________
>> >> v6ops mailing list
>> >> v6ops= @ietf.org
>> >> https://www.ietf.org/mailman/listinfo/v6ops
>> >
>> >
>> >
>> > _______________________________________________
>> > v6ops mailing list
>> > v6ops@iet= f.org
>> > https://www.ietf.org/mailman/listinfo/v6ops
>> >
>
>


--047d7b3440f475e38204c908bb4c-- From internet-drafts@ietf.org Thu Sep 6 06:54:49 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5AD221F8671; Thu, 6 Sep 2012 06:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.388 X-Spam-Level: X-Spam-Status: No, score=-102.388 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WAOapFTLfZLW; Thu, 6 Sep 2012 06:54:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64CC421F863C; Thu, 6 Sep 2012 06:54:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120906135449.21676.5385.idtracker@ietfa.amsl.com> Date: Thu, 06 Sep 2012 06:54:49 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-ivi-icmp-address-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 13:54:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Stateless Source Address Mapping for ICMPv6 Packets Author(s) : Xing Li Congxiao Bao Dan Wing Ramji Vaithianathan Geoff Huston Filename : draft-ietf-v6ops-ivi-icmp-address-05.txt Pages : 7 Date : 2012-09-06 Abstract: A stateless IPv4/IPv6 translator may receive ICMPv6 packets containing non IPv4-translatable addresses as the source. These packets should be passed across the translator as ICMP packets directed to the IPv4 destination. This document presents recommendations for source address translation in ICMPv6 headers to handle such cases. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-ivi-icmp-address There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-ivi-icmp-address-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-ivi-icmp-address-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From brian.e.carpenter@gmail.com Thu Sep 6 07:04:23 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9861021F85ED for ; Thu, 6 Sep 2012 07:04:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.621 X-Spam-Level: X-Spam-Status: No, score=-101.621 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q50RxlRn4RWd for ; Thu, 6 Sep 2012 07:04:23 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id D668821F8546 for ; Thu, 6 Sep 2012 07:04:22 -0700 (PDT) Received: by eekb45 with SMTP id b45so789563eek.31 for ; Thu, 06 Sep 2012 07:04:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=7uAIuLPYF0knr7WsLiqnSQhcbtl6fbtECmXWz7H9lb0=; b=qmUkruTZY1F4IYiVc1dQBHJvOgpdB+1vPivzyes4q4iPKF9D/D6+l8CkoH9c8KVnNw Sp9eSM8liXTEzgrTlPI3fyN2n947o9bPwzgDEXPn6PTNeTTic28Uk1X49I0Pnqe+Wldo gHPQU5zFDZ37n/OHV9lYVbm/XsZ+STyR4NXYTWP1ZJ6zsemrjn0UmBYEU8K4g9RDrp0b F2X9wxXx1AJaoGD8TSJHafJX9PdzP47FYzUhqzaN+BcxDpB9Pwe2b9qo0cJLNgLab23h 0w6zFZ7UHCG7WBgEFGUjebBR/wvRQZYcj1sh3cMEj9kRncDkdS7W8+fkJSesONthCpOP w2Qw== Received: by 10.14.172.129 with SMTP id t1mr3121395eel.34.1346940261898; Thu, 06 Sep 2012 07:04:21 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-218-213.as13285.net. [2.102.218.213]) by mx.google.com with ESMTPS id e42sm4333263eem.8.2012.09.06.07.04.17 (version=SSLv3 cipher=OTHER); Thu, 06 Sep 2012 07:04:19 -0700 (PDT) Message-ID: <5048AD6A.7080601@gmail.com> Date: Thu, 06 Sep 2012 15:04:26 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: IPv6 Operations References: <5040646F.6000103@gmail.com> <50407CAB.4060903@redpill-linpro.com> <504094DD.9060708@gmail.com> <50409C2A.2060805@redpill-linpro.com> <5040AC38.5080505@gmail.com> <5040CA3B.4090602@bogus.com> <5040D84B.2060201@gmail.com> In-Reply-To: <5040D84B.2060201@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] [Fwd: I-D Action: draft-ietf-v6ops-icp-guidance-03.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 14:04:23 -0000 Hi again. Nobody answered my challenge to send text, so here is my own attempt at rewriting the contentious paragraphs (new and old versions below). Comments please - if this is OK, we can update the draft again. Regards Brian (speaking only for myself) PROPOSED NEW TEXT: 5.1. Address and subnet assignment An ICP must first decide whether to apply for its own Provider Independent (PI) address prefix for IPv6. This option is available for a fee either from an ISP that acts as a Local Internet Registry, or directly from the relevant Regional Internet Registry. The alternative is to obtain a Provider Aggregated (PA) prefix from an ISP. Both solutions are viable in IPv6. However, the scaling properties of the wide area routing system (BGP4) mean that the number of PI prefixes should be limited, so only large content providers can justify obtaining a PI prefix and convincing their ISPs to route it. Millions of enterprise networks, including smaller content providers, will use PA prefixes. In this case, a change of ISP would necessitate a change of the corresponding PA prefix, using the procedure outlined in [RFC4192]. An ICP that has connections via multiple ISPs, but does not have a PI prefix, would therefore have multiple PA prefixes, one from each ISP. This would result in multiple IPv6 addresses for the ICP's servers or load balancers. If one address fails due to an ISP malfunction, sessions using that address would be lost. At the time of this writing, there is very limited operational experience with this approach [I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat]. An ICP that has its service hosted by a colocation provider, cloud provider, or the like, will need to follow the addressing policy of that provider. OLD TEXT: 5.1. Address and subnet assignment An ICP must first decide whether to apply for its own Provider Independent (PI) address prefix for IPv6. This option is available to an ICP willing to deal directly with the relevant Regional Internet Registry and pay the associated fees. The alternative is to obtain a Provider Aggregated (PA) prefix from an ISP. Both solutions are viable in IPv6. However, the scaling properties of the wide area routing system (BGP4) limit the routing of PI prefixes, so only large content providers can justify the bother and expense of obtaining a PI prefix and convincing their ISPs to route it. Millions of enterprise networks, including smaller content providers, will use PA prefixes. In this case, a change of ISP would necessitate a change of the corresponding PA prefix, using the procedure outlined in [RFC4192]. An ICP that has connections via multiple ISPs, but does not have a PI prefix, would have multiple PA prefixes, one from each ISP. This would result in multiple IPv6 addresses for the ICP's servers or load balancers. If one address fails due to an ISP malfunction, sessions using that address would be lost. At the time of this writing, there is very limited operational experience with this approach [I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat]. From despres.remi@laposte.net Thu Sep 6 07:23:05 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E29621F85ED for ; Thu, 6 Sep 2012 07:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.407 X-Spam-Level: X-Spam-Status: No, score=-1.407 tagged_above=-999 required=5 tests=[AWL=-0.059, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gTZvNF-AN0-Y for ; Thu, 6 Sep 2012 07:23:04 -0700 (PDT) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.2]) by ietfa.amsl.com (Postfix) with ESMTP id DA5B921F849C for ; Thu, 6 Sep 2012 07:23:03 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2109.sfr.fr (SMTP Server) with ESMTP id A4C5370002C9; Thu, 6 Sep 2012 16:23:00 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2109.sfr.fr (SMTP Server) with ESMTP id 3EDC77000152; Thu, 6 Sep 2012 16:23:00 +0200 (CEST) X-SFR-UUID: 20120906142300257.3EDC77000152@msfrf2109.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-19--733007395 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Thu, 6 Sep 2012 16:22:59 +0200 Message-Id: <0AB559C2-855C-41F3-92D1-07F973EB760A@laposte.net> References: <504392E0.8070802@bogus.com> <448050D4-84F9-4F52-BF7E-347EA451A96C@laposte.net> To: Cameron Byrne X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] 464XLAT - support of /64 delegated prefixes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 14:23:05 -0000 --Apple-Mail-19--733007395 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 2012-09-06 15:16, Cameron Byrne : >=20 > On Sep 6, 2012 1:03 AM, "Lorenzo Colitti" wrote: > > > > On Thu, Sep 6, 2012 at 4:54 PM, Maoke wrote: > >> > >> how can we ensure the above addresses do not conflict with any = manually, arbitrarily configured addresses? i am lost. :P - maoke=20 > > > > > > AIUI, we say "conflicts are impossible, because this is a reserved = range", and then we cross our fingers. > > >=20 > I agree with Lorenzo's sarcasm. >=20 This "sarcasm" isn't deserved: one who manually configures a host with = an invalid address with regard to RFC 4291 should cross his fingers in = all cases, with 464XLAT or not. Besides, it is particularly unexpected from you, after you stated "In = the case of the Android CLAT code that was submitted to AOSP, the /64 is = simply copied from the WAN 3G/4G interfaces to the LAN. No magic. No ND = Proxy. No DHCP. But, it works for all known cases". With this, collisions between CLATs and host addresses are possible even = with well-behaved hosts =3D> The need to cross fingers is permanent ;-). By using the proposed IANA-EUI-64 based /96, this is avoided and, with a = MAY in the draft, the somewhat risky choice you have described remains = possible. > That said, we have been pushing this draft for a year trying to drive = concensus. If we do not limit the scope to the core objective we will be = here for another year while the issue of ipv4-only hosts and apps delays = and hinders broader ipv6 deployment. >=20 On this, we agree. Still convinced to be one of the best supporters of a good 464XLAT = without undue delay, Best regards, RD > CB > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail-19--733007395 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii


On Sep 6, 2012 1:03 AM, "Lorenzo Colitti" <lorenzo@google.com> wrote:
>
> On Thu, Sep 6, 2012 at 4:54 PM, Maoke <fibrib@gmail.com> wrote:
>>
>> how can we ensure the above addresses do not conflict = with any manually, arbitrarily configured addresses? i am = lost. :P - maoke 
>
>
> AIUI, we say "conflicts are impossible, because this is a reserved = range", and then we cross our fingers.
>

I agree with Lorenzo's sarcasm.

This = "sarcasm" isn't deserved: one who manually configures a host with = an invalid address with regard to RFC 4291 should cross his fingers in = all cases, with 464XLAT or not.

Besides, it is = particularly unexpected from you, after you stated "In the = case of the Android CLAT code that was submitted = to AOSP, the /64 is simply copied from the WAN 3G/4G interfaces = to the LAN. No magic. No ND Proxy. No DHCP.  But, it = works for all known cases".
With this, = collisions between CLATs and host = addresses are possible even with well-behaved = hosts =3D> The need to cross fingers is permanent = ;-).
By using the proposed IANA-EUI-64 = based /96, this is avoided and, with a MAY in the draft, the somewhat = risky choice you have described remains = possible.

That said, we have been pushing this draft for a year = trying to drive concensus. If we do not limit the scope to the core = objective we will be here for another year while the issue of ipv4-only = hosts and apps delays and hinders broader ipv6 = deployment.

On this, we = agree.

Still convinced to be one of the best = supporters of a good 464XLAT without undue delay,
Best = regards,
RD


CB
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/= mailman/listinfo/v6ops
>

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

= --Apple-Mail-19--733007395-- From wdec.ietf@gmail.com Thu Sep 6 07:51:44 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A74621F85AD for ; Thu, 6 Sep 2012 07:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3bXMY1WKPMtR for ; Thu, 6 Sep 2012 07:51:43 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 123FE21F8581 for ; Thu, 6 Sep 2012 07:51:42 -0700 (PDT) Received: by eekb45 with SMTP id b45so816473eek.31 for ; Thu, 06 Sep 2012 07:51:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=J57Xvmg0v4tbR49GgYr3eGgEwJ49rSElZXejDHBwezA=; b=XTagm2Tiwu6dFGjlPaSCGI/fOZ8jQvEDSS42vBDbIE7hf8HYCd/tO7HKgE+IOr34h7 UH9bejDzK2NZCLrwRRaCybWQ6SFHieJyNIXsJLE5bJwGZqpCRLj1B6oTDVfjCT4jrCZP CnMXu8ONjX5T4TZnHVCY+INcgsNttY/dOkIQYonQXcFwWSka0koeeIgLiZc21NvvDkpu NcJY/PlnIBm6GdBpi6bTC4XhaUrxoTVTWfgc4rrW+VdZBmc5ikF9TvXXiKiE2mwBRHwb 1NcIZIrwzaCyJCuqEfgdPXl/hvOLHQ6mLX0uasqGcEociOqx0YNLYVDPqTVZIYljyBpb uJRg== MIME-Version: 1.0 Received: by 10.14.224.73 with SMTP id w49mr3357937eep.37.1346943102168; Thu, 06 Sep 2012 07:51:42 -0700 (PDT) Received: by 10.14.45.68 with HTTP; Thu, 6 Sep 2012 07:51:42 -0700 (PDT) In-Reply-To: References: <504392E0.8070802@bogus.com> <448050D4-84F9-4F52-BF7E-347EA451A96C@laposte.net> Date: Thu, 6 Sep 2012 16:51:42 +0200 Message-ID: From: Wojciech Dec To: Cameron Byrne Content-Type: multipart/alternative; boundary=047d7b66fbc1232df904c909a165 Cc: v6ops WG Subject: Re: [v6ops] 464XLAT - support of /64 delegated prefixes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 14:51:44 -0000 --047d7b66fbc1232df904c909a165 Content-Type: text/plain; charset=ISO-8859-1 Just skip on shared prefix support in host mode. It's not needed for 3gpp usage. On other segments point to the PD/routed mode. No need of IANA special codes or ND-Proxy/whatever. -Woj. On 6 September 2012 15:16, Cameron Byrne wrote: > > On Sep 6, 2012 1:03 AM, "Lorenzo Colitti" wrote: > > > > On Thu, Sep 6, 2012 at 4:54 PM, Maoke wrote: > >> > >> how can we ensure the above addresses do not conflict with any > manually, arbitrarily configured addresses? i am lost. :P - maoke > > > > > > AIUI, we say "conflicts are impossible, because this is a reserved > range", and then we cross our fingers. > > > > I agree with Lorenzo's sarcasm. > > That said, we have been pushing this draft for a year trying to drive > concensus. If we do not limit the scope to the core objective we will be > here for another year while the issue of ipv4-only hosts and apps delays > and hinders broader ipv6 deployment. > > CB > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --047d7b66fbc1232df904c909a165 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Just skip on shared prefix support in host mode. It's not needed for 3g= pp usage.
On other segments point to the PD/routed mode.

No need = of IANA special codes or ND-Proxy/whatever.

-Woj.

On 6 September 2012 15:16, Cameron Byrne <cb.list6@gmail.com> wrote:


On Sep 6, 2012 1:03 AM, "Lorenzo Colitti" <lorenzo@google.com> wrote:
>
> On Thu, Sep 6, 2012 at 4:54 PM, Maoke <fibrib@gmail.com> wrote:
>>
>> how=A0can we ensure the above addresses=A0do not conflict with any= manually, arbitrarily=A0configured addresses? i=A0am lost.=A0:P - maoke=A0=
>
>
> AIUI, we say "conflicts are impossible, because this is a reserve= d range", and then we cross our fingers.
>

I agree with Lorenzo's sarcasm.

That said, we have been pushing this draft for a year trying to drive co= ncensus. If we do not limit the scope to the core objective we will be here= for another year while the issue of ipv4-only hosts and apps delays and hi= nders broader ipv6 deployment.

CB


> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org=
> https://www.ietf.org/mailman/listinfo/v6ops
>


_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops


--047d7b66fbc1232df904c909a165-- From phdgang@gmail.com Thu Sep 6 07:52:12 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9894321F865C for ; Thu, 6 Sep 2012 07:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rdFlRuOiCqkH for ; Thu, 6 Sep 2012 07:52:10 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3D61E21F857A for ; Thu, 6 Sep 2012 07:52:09 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so2719815vcb.31 for ; Thu, 06 Sep 2012 07:52:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=T7qrDauq9wqiMfxd6MDz64wF2f+kIKSliyQB8CrzPJc=; b=iyWTQj6+BW96YwWWhgixbvgXqnCa49TgfefWeGdClKsogri7oEveIV1fHVm6fY7WRT wWRRmF9JLdgLSnQ6+T+QOfb9UtaIRRUncqbjV00Lw3yiqxQesSBVNHhn9oAMEacVx5y0 9ppWKaA/4IGr+6VKSPg2L4IQwpUPt5mjuX9AGBoLpFkPkVjDlMp0pI+s1EI8at8ov0GV rq7URCWf/1N8/va5kzx8iOxKNB/w3DaTRr+h9wotTcMUOwqZ+13hCZPYNii6CRIzlpdT 3MPLRKglyCIrKaSatzggcnx4WyVZUWMBlgrchEHkgIKUSscdWyoW00wKltw8dO/zlLQh uCnw== MIME-Version: 1.0 Received: by 10.220.209.80 with SMTP id gf16mr2514303vcb.58.1346943127283; Thu, 06 Sep 2012 07:52:07 -0700 (PDT) Received: by 10.58.114.231 with HTTP; Thu, 6 Sep 2012 07:52:07 -0700 (PDT) In-Reply-To: References: Date: Thu, 6 Sep 2012 22:52:07 +0800 Message-ID: From: GangChen To: Maoke Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 14:52:12 -0000 2012/9/6, Maoke : > hi Gang, > > thanks for the links! > > 1. i don't think an early conclusion of the authors cannot be objected an= d > thought over again, before the last call is closed. Sure. If you do think several-months lasted discussion doesn't convince and would like to boil the ocean, we could re-open it. But please read the conversion happened before on the list to ensure new discussion is not backward. > 2. i don't think it is a loss to state out of scope (or not to mention th= at > at all) for IPv4-only app access to IPv6-only server. (*)Those arguments were discussed in the thread of "A way forward for 464XLAT - using BIH". The loss and gain have been well identified. The point is adding BIH only can be complementary to 464xlat scenario, no harm. If you have further point, please identify. > this could be > achieved by simply configuring the IPv6-only server with an RFC6052 > IPv4-translatable address and relying CLAT RFC6145 translation, 1) The IPv4-Embedded IPv6 address on CLAT is inserted with IPv4 private address. When the two IPv4-embedded IPv6 addresses with conflicted IPv4 address talk to an IPv4-translatable IPv6 address, it would be failed since IPv6-only server is confused that outgoing packages should send to which CLAT. 2) IPv6-only server with IPv4-translatable address would cause one public IPv4 address. Most people do IPv6 because IPv4 is limited, so doing this way does not really buy you anything. 3) There no RFC stated the solution what you called as RFC6052+RFC6145; whether that is a doable way need to be further justified. But BIH is a standard track > or by a > NAT64 located anywhere between the IPv4 app and the IPv6 domain implement= ed I don't get it. If there is NAT64, there is nothing to do with the scenario you are talking about. > in anyway not necessarily the socket layer solution, even though BIH does > possibly work, by a proxy (ALG), etc. Please note RFC6535 has two flavors, i.e. header translation and socket translation. It=92s really not necessarily the socket layer solution. > 3. i don't think the author has tested the BIH with CLAT for an IPv6-only > server, at least i have not seen any discussion/report from the authors o= r > WG members about the test. (**)I guess you will see the report soon, because we are coding that right = now. At this stage, what I can tell is most parts are same in the combining code= . > to my understanding, the BIH/CLAT work here is > not yet practiced. why we need/should put a stuff not yet practiced into = a > BCP?? Please don't do the arbitrary objection even you didn't evaluate it. It is a strange logic. "I don't do that. I even don't know that. So I think that is not practiced.= " That is an unfair argument. > (NOTE, the test result from you only illustrates that BIH itself is > working, not the BIH/464xlat with IPv4-only app access to IPv6-only serve= r. > the tested applications, skype, MSN, etc. are none of business of the > so-called IPv6-only servers). Please see the (**) and carefully read my report http://www.ietf.org/mail-archive/web/v6ops/current/msg12631.html The shared experiences are in 464 contexts. With 464xlat, we could easily do *combining 464XLAT with BIH*. It's of significance. > 4. i was even confused by the text "By combining 464XLAT with BIH > [RFC6535], it is also possible to provide single IPv4/IPv6 translation > service" itself. BIH has done the single IPv4/IPv6 translation right? wha= t > is the significance of such a "combination"? what is the add-on? Same comment with (*). If you have concrete point, please identify. Ambiguous arguments and arbitrary objections only can waste our energy and time. It doesn't help the document imho. > integrating the compressor, condenser, expansion valve, evaporator into a > fridge is an innovation (as the authors did for the 464xlat) but we canno= t > call a "fridge + microwave oven put on the top of the fridge" a new > "architecture" of better practice. I didn't fully get your point. 464xlat is not a fridge actually :) Again, please directly identify your technical points/concerns. BRs Gang > - maoke > > 2012/9/6 GangChen > >> 2012/9/6, Maoke : >> > another objection is, Section 9 states "another, >> > if combined with BIH [RFC6535 ]= , >> is >> > a IPv4 -> IPv6 translation for >> > reaching IPv6-only servers from IPv4-only clients that can not >> > support IPv6. " >> > >> > it sounds to me that 464xlat does suggest to apply BIH, as part of the >> best >> > practice, for IPv4 client reaching IPv6-only servers. to my >> understanding, >> > there could be several alternative ways to achieve that, why we should >> > be >> > bounded with BIH? >> > >> > sorry i didn't catch the discussion on this issue before. >> >> There was a quite long discussion, >> since you didn't follow that, I list the links below for your >> convenience. >> >> "A way forward for 464XLAT", started with >> http://www.ietf.org/mail-archive/web/v6ops/current/msg12521.html >> "A way forward for 464XLAT - using BIH", started with >> http://www.ietf.org/mail-archive/web/v6ops/current/msg12631.html >> "I-D Action: draft-ietf-v6ops-464xlat-02.txt" started with >> http://www.ietf.org/mail-archive/web/v6ops/current/msg12628.html >> " [v6ops] draft-ietf-v6ops-464xlat - which status?"started with >> http://www.ietf.org/mail-archive/web/v6ops/current/msg13035.html >> .... >> >> As Cameron indicated *The conclusion was that the 464XLAT is more >> complete by making a reference to BIH scenario.* >> >> BRs >> >> Gang >> >> >> > >> > 2012/8/22 Fred Baker (fred) >> > >> >> I should note that the current thread has a subject line reading >> -06.txt, >> >> but the current version is -07.txt. You may find the diffs (fairly >> >> extensive) at >> >> >> >> http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-464xlat-07.txt >> >> >> >> >> >> On Aug 21, 2012, at 8:45 AM, Fred Baker (fred) wrote: >> >> >> >> > This is to open a two week Working Group last Call on >> >> > >> >> > http://tools.ietf.org/html/draft-ietf-v6ops-464xlat >> >> > "464XLAT: Combination of Stateful and Stateless Translation", >> Masataka >> >> > Mawatari, Masanobu Kawashima, Cameron Byrne, 19-Aug-12 >> >> > >> >> > Please read it now. We are interested in, among other things, >> technical >> >> commentary on the draft and the working group's perception on its >> >> usefulness to its target audience. >> >> > _______________________________________________ >> >> > v6ops mailing list >> >> > v6ops@ietf.org >> >> > https://www.ietf.org/mailman/listinfo/v6ops >> >> >> >> ---------------------------------------------------- >> >> The ignorance of how to use new knowledge stockpiles exponentially. >> >> - Marshall McLuhan >> >> >> >> _______________________________________________ >> >> v6ops mailing list >> >> v6ops@ietf.org >> >> https://www.ietf.org/mailman/listinfo/v6ops >> >> >> > >> > From lorenzo@google.com Thu Sep 6 08:15:55 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1B7421F86B1 for ; Thu, 6 Sep 2012 08:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.876 X-Spam-Level: X-Spam-Status: No, score=-102.876 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2AJZ4trwDvT for ; Thu, 6 Sep 2012 08:15:55 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 38A2F21F8624 for ; Thu, 6 Sep 2012 08:15:54 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so2947075obb.31 for ; Thu, 06 Sep 2012 08:15:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=l6s75OZDdOZkFQiRfYEx2tRXX2EVIMYKXGfcL3m2PJo=; b=WIiM07Am0QOHXmvO39zswuw8cO6OC3RqBmFWVcJN1XUOcXz8Ii2n4mH7UTOgG6gLXi WqXMwu6VKcUNupSX6efdhdB71203PMSM8I045fCesH9g/hkNTglAejnvWru8mfbTBzXy jfqaC8XJsP5HgtM1+rz6Gq5d5CZd1yFKLyP92JAw4Sr1Z7Uz9p4oSjoEj95/CfEXGPrp jGJkfa9A2fC3W6gmaOzx0a/QrmjR77k6xNlPUXvUc31KJi79pvT2JWysoF9l7asqJL+C h0iF1XJcxcXL76BDbXvlF/W5B5uMAYv2NElgp+bSVWvEyMN94acTqpN7BSsOQ4k1L3sS 7nvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=l6s75OZDdOZkFQiRfYEx2tRXX2EVIMYKXGfcL3m2PJo=; b=Ual5X9vJ5lJlA4tnbx3+fipPWF6/X89CFgCuCYZAP50FBV1wVFv4UQ08ouMOA+bg19 jH1q6/bvBHJF2joLW2bBq3/pZK2syNYy4bjDvqYIQqQsqtwJaqOYeEgQykhmcygbQ2yz g4ipa270LeKPDnMfN270oVwLyfQcfaHm6W1PUmNVtEO7js6RPIlzyjo2Jv3IbiwUgkHA RRIV/UuRNG/N63WD5WajGiOKUra9ZX3IJmg/WIAeGQxA+MEyfOS8BJvfp1k9K4i4Hs3V xbJ/ipoFSam86eulvbIbLcZ+n1DLnpo71E7Mqu1nYoeGskDd73uSgykRh2tFKBjwUO8N LTsQ== Received: by 10.60.10.6 with SMTP id e6mr2563864oeb.45.1346944554642; Thu, 06 Sep 2012 08:15:54 -0700 (PDT) Received: by 10.60.10.6 with SMTP id e6mr2563852oeb.45.1346944554550; Thu, 06 Sep 2012 08:15:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.187.8 with HTTP; Thu, 6 Sep 2012 08:15:34 -0700 (PDT) In-Reply-To: References: From: Lorenzo Colitti Date: Fri, 7 Sep 2012 00:15:34 +0900 Message-ID: To: GangChen Content-Type: multipart/alternative; boundary=e89a8fb2028ab4c5f104c909f704 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmza6RTkRR4euj0Q5eQSV8GI2C5yPp9rtlX3lZR240qz/Cj2nH1OqtPPKTBdn3XOiBqhi9Vh64pw17kDASNqjLoSIvaR1zO829hcGw+0+zhqG5Zk0VjsTpnt91OI6amG2e07h4Mr1BWVR0zZJy+m3EOmGObQM4nmrX2Ah4XyiCPBwpNuCDh72GFe0Nf8CJ9Ghtmf+q6 Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 15:15:55 -0000 --e89a8fb2028ab4c5f104c909f704 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Sep 6, 2012 at 11:52 PM, GangChen wrote: > I didn't fully get your point. 464xlat is not a fridge actually :) > Again, please directly identify your technical points/concerns. > I think the comment was intended to mean: 2. BIH is not necessary for the operation of 464xlat, so it doesn't have to be in the draft. 3. The scenario that BIH is intended to solve is further in the future and we do not yet have as much operational experience with it. So it should not go into a BCP for 464xlat, which is a different transition mechanism. 4. Saying "you can use BIH with 464xlat" is not very useful by itself because 464xlat doesn't work together with BIH in any special way. It only provides connectivity. Yes, you can do BIH with 464xlat. But you can also do it with DS-Lite, or 6rd, or native dual-stack. Saying "you can use BIH with 464xlat" is like saying "you can run HTTP over TCP": it's true, but it doesn't need to go into the TCP RFC. For what it's worth, I agree. --e89a8fb2028ab4c5f104c909f704 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Sep 6, 2012 at 11:52 PM, GangChen <phdgang@gmail.com> wrote:
I didn't fully get your point. 464xlat is not a fridge actually :)
Again, please directly identify your technical points/concerns.

I think the comment was intended to mean:

2. BIH is not necessary for the operation of 464xlat, so i= t doesn't have to be in the draft.

3. The scenario that BIH is intended to solve is furthe= r in the future and we do not yet have as much operational experience with = it. So it should not go into a BCP for 464xlat, which is a different transi= tion mechanism.

4. Saying "you can use BIH with 464xlat" is n= ot very useful by itself because=A0464xlat doesn't work together with B= IH in any special way. It only provides connectivity. Yes, you can do BIH w= ith 464xlat. But you can also do it with DS-Lite, or 6rd, or native dual-st= ack. Saying "you can use BIH with 464xlat" is like saying "y= ou can run HTTP over TCP": it's true, but it doesn't need to g= o into the TCP RFC.

For what it's worth, I agree.
--e89a8fb2028ab4c5f104c909f704-- From gvandeve@cisco.com Thu Sep 6 08:26:20 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 207F421F86B6 for ; Thu, 6 Sep 2012 08:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.916 X-Spam-Level: X-Spam-Status: No, score=-9.916 tagged_above=-999 required=5 tests=[AWL=-0.232, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xN5dmziL8liW for ; Thu, 6 Sep 2012 08:26:19 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 3E4C821F84E1 for ; Thu, 6 Sep 2012 08:26:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3710; q=dns/txt; s=iport; t=1346945179; x=1348154779; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=S9U1Y/6/b0BiSWsLYm7xjb6ZIvWMTh++U2fZ+nVi/lc=; b=lCeBqjLe/ROkNS/ljGtdNE8tpZxPw/ahrPayWODXFt6SEzEXmaxF9wZe 6/+nL78BCY3aUleqZAkJo7BHid3mBly37NWLrcXbRZGzPQ3rrs5soxy5K zLYaqVEQdIdxjXcZ34/CijhgT0fG/58Pxw8e+2yIpbueVSDFxEaxdXy98 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALi/SFCtJXG9/2dsb2JhbABFux6BB4IgAQEBBAEBAQ8BJysJFwQCAQgRBAEBCxQJBycLFAkIAgQBEggTB4drC5p4oBwEixEUAYVQYAOkDIFngmOBWAE X-IronPort-AV: E=Sophos;i="4.80,380,1344211200"; d="scan'208";a="118947800" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-6.cisco.com with ESMTP; 06 Sep 2012 15:26:18 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q86FQI2c028193 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Sep 2012 15:26:18 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.191]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.001; Thu, 6 Sep 2012 10:26:18 -0500 From: "Gunter Van de Velde (gvandeve)" To: Brian E Carpenter , IPv6 Operations Thread-Topic: [v6ops] [Fwd: I-D Action: draft-ietf-v6ops-icp-guidance-03.txt] Thread-Index: AQHNh1bRjv0kb3+Bik+pUKIZVF+MRJd0D4OAgAAItQCAABMjAIAAI8eAgAAQw4CACVZLAP//wtQA Date: Thu, 6 Sep 2012 15:26:17 +0000 Message-ID: <67832B1175062E48926BF3CB27C49B24081378F3@xmb-aln-x12.cisco.com> References: <5040646F.6000103@gmail.com> <50407CAB.4060903@redpill-linpro.com> <504094DD.9060708@gmail.com> <50409C2A.2060805@redpill-linpro.com> <5040AC38.5080505@gmail.com> <5040CA3B.4090602@bogus.com> <5040D84B.2060201@gmail.com> <5048AD6A.7080601@gmail.com> In-Reply-To: <5048AD6A.7080601@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.83.57] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19166.005 x-tm-as-result: No--28.963100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] [Fwd: I-D Action: draft-ietf-v6ops-icp-guidance-03.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 15:26:20 -0000 Will read your draft,,, G/ -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of B= rian E Carpenter Sent: 06 September 2012 16:04 To: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action: draft-ietf-v6ops-icp-guidance-03.txt= ] Hi again. Nobody answered my challenge to send text, so here is my own attempt at rew= riting the contentious paragraphs (new and old versions below). Comments pl= ease - if this is OK, we can update the draft again. Regards Brian (speaking only for myself) PROPOSED NEW TEXT: 5.1. Address and subnet assignment An ICP must first decide whether to apply for its own Provider Independent (PI) address prefix for IPv6. This option is available for a fee either from an ISP that acts as a Local Internet Registry, or directly from the relevant Regional Internet Registry. The alternative is to obtain a Provider Aggregated (PA) prefix from an ISP. Both solutions are viable in IPv6. However, the scaling properties of the wide area routing system (BGP4) mean that the number of PI prefixes should be limited, so only large content providers can justify obtaining a PI prefix and convincing their ISPs to route it. Millions of enterprise networks, including smaller content providers, will use PA prefixes. In this case, a change of ISP would necessitate a change of the corresponding PA prefix, using the procedure outlined in [RFC4192]. An ICP that has connections via multiple ISPs, but does not have a PI prefix, would therefore have multiple PA prefixes, one from each ISP. This would result in multiple IPv6 addresses for the ICP's servers or lo= ad balancers. If one address fails due to an ISP malfunction, sessions using that address would be lost. At the time of this writing, there is very limited operational experience with this approach [I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat]. An ICP that has its service hosted by a colocation provider, cloud provider, or the like, will need to follow the addressing policy of that provider. OLD TEXT: 5.1. Address and subnet assignment An ICP must first decide whether to apply for its own Provider Independent (PI) address prefix for IPv6. This option is available to an ICP willing to deal directly with the relevant Regional Internet Registry and pay the associated fees. The alternative is to obtain a Provider Aggregated (PA) prefix from an ISP. Both solutions are viable in IPv6. However, the scaling properties of the wide area routing system (BGP4) limit the routing of PI prefixes, so only large content providers can justify the bother and expense of obtaining a PI prefix and convincing their ISPs to route it. Millions of enterprise networks, including smaller content providers, will use PA prefixes. In this case, a change of ISP would necessitate a change of the corresponding PA prefix, using the procedure outlined in [RFC4192]. An ICP that has connections via multiple ISPs, but does not have a PI prefix, would have multiple PA prefixes, one from each ISP. This would result in multiple IPv6 addresses for the ICP's servers or load balancers. If one address fails due to an ISP malfunction, sessions using that address would be lost. At the time of this writing, there is very limited operational experience with this approach [I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat]. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From cb.list6@gmail.com Thu Sep 6 08:27:34 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDE4B21F867B for ; Thu, 6 Sep 2012 08:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMYYDh04b6aK for ; Thu, 6 Sep 2012 08:27:33 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 4130421F8665 for ; Thu, 6 Sep 2012 08:27:33 -0700 (PDT) Received: by wibhr14 with SMTP id hr14so1280612wib.13 for ; Thu, 06 Sep 2012 08:27:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=r/D2ZgfftVPx3TZ8DOHwAKjTHjgrSaE3X66zhWeZGIc=; b=tl3ixa7jHWtwtY+7CJa4iKdLJaFlhy3Svd25wWquFxPr2OE/odA4SG8gfcDFbpuqYk EEFgJErfs1NsUoMXk78IoRvGD/QkFGu4pU28FZ+ZKFk1zoEE0wkohxFd2Q868Isbbw5e aT74asDt1geNEjgfLYxBB6zA8vqE+xSW9bNil/DtsGOLoWfiKEXXeIMk9N5KHwIbqWLX zeiUHlUgOWmsnvXxatSjhfJ6OLdv2XMHv7fOz3WglXcpev829U1R4jP2cJX4PhjjKJvU Fj/8Rg/luj0ajGebokWz9AJOK2kJ2+3DGlj8/WavuR6JJtYcpsPmJO/4AqQexlo7vrH8 jjMA== MIME-Version: 1.0 Received: by 10.180.93.68 with SMTP id cs4mr46483612wib.14.1346945251975; Thu, 06 Sep 2012 08:27:31 -0700 (PDT) Received: by 10.194.14.229 with HTTP; Thu, 6 Sep 2012 08:27:31 -0700 (PDT) In-Reply-To: <0AB559C2-855C-41F3-92D1-07F973EB760A@laposte.net> References: <504392E0.8070802@bogus.com> <448050D4-84F9-4F52-BF7E-347EA451A96C@laposte.net> <0AB559C2-855C-41F3-92D1-07F973EB760A@laposte.net> Date: Thu, 6 Sep 2012 08:27:31 -0700 Message-ID: From: Cameron Byrne To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops WG Subject: Re: [v6ops] 464XLAT - support of /64 delegated prefixes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 15:27:35 -0000 R=E9mi , On Thu, Sep 6, 2012 at 7:22 AM, R=E9mi Despr=E9s = wrote: > > 2012-09-06 15:16, Cameron Byrne : > > > On Sep 6, 2012 1:03 AM, "Lorenzo Colitti" wrote: >> >> On Thu, Sep 6, 2012 at 4:54 PM, Maoke wrote: >>> >>> how can we ensure the above addresses do not conflict with any manually= , >>> arbitrarily configured addresses? i am lost. :P - maoke >> >> >> AIUI, we say "conflicts are impossible, because this is a reserved range= ", >> and then we cross our fingers. >> > > I agree with Lorenzo's sarcasm. > > This "sarcasm" isn't deserved: one who manually configures a host with an > invalid address with regard to RFC 4291 should cross his fingers in all > cases, with 464XLAT or not. > Here are the facts as i see them: 1. Many people on the list, including me, say we must share a /64 from WAN to LAN 2. Multiple real world implementations of this /64 sharing exists in various types of nodes, including the AOSP Android code. Hermant also references he has experience with some CPE that share a /64 in production networks using ND Proxy. And there is also the case of a CPE that simply bridges WAN to LAN and has a logical / virtual place on that share /64. Lorenzo also specified a method here http://www.ietf.org/mail-archive/web/v6ops/current/msg13977.html 3. There is no standards track way to share a /64 from WAN to LAN, the party line is DHCP-PD is the solution. New protocol work happens in 6MAN. 4. Remi has provided, what i consider, to be a workable solution that avoids the case of NAT44. So, we have a problem since #1 and #3 are a challenge, and #2 exists #4 is workable, but it has opponents and requires "hard coding" and really is not core to 464XLAT. Removing the need for NAT44 is not a goal, the overhead of having NAT44 is inconsequential to a modern CPE, including smartphones. Related to hard coding, there is no RFC1918 address that we can pick. ISPs are now dictating how residential LANs must be configured so they do not overlap with the SP network's use of RFC1918 space ... http://keithbartholomew.com/2012/04/how-att-u-verse-broke-my-home-network/ > Besides, it is particularly unexpected from you, after you stated "In the > case of the Android CLAT code that was submitted to AOSP, the /64 is simp= ly > copied from the WAN 3G/4G interfaces to the LAN. No magic. No ND Proxy. N= o > DHCP. But, it works for all known cases". > With this, collisions between CLATs and host addresses are possible even > with well-behaved hosts =3D> The need to cross fingers is permanent ;-). No, NDP/DAD runs normally on the LAN side as a /64 and the WAN side is a /128 ... /128 on WAN is normal operations for a Android phone on a 3GPP network. The main takeaway from this: implementation specific solutions are ok and left to the implementer and network operator to consider pros and cons. The party line remains: DHCP-PD is best! While reality dictates and the 464XLAT I-D must reflect that /64 sharing exists. I am not confident that this group of folks who don't have a very good understanding of probability (manually configures 64 bit collisions?!) will come to a consensus on a general solution, and even if they can come to a consensus, 464XLAT is not the right vehicle for specifying how a /64 is shared across interfaces. Let us just say /64 sharing exists and move on. If we believe /64 must be codified on standards track, 6MAN may be the place for that with its own I-D. > By using the proposed IANA-EUI-64 based /96, this is avoided and, with a = MAY > in the draft, the somewhat risky choice you have described remains possib= le. > > That said, we have been pushing this draft for a year trying to drive > concensus. If we do not limit the scope to the core objective we will be > here for another year while the issue of ipv4-only hosts and apps delays = and > hinders broader ipv6 deployment. > > On this, we agree. > > Still convinced to be one of the best supporters of a good 464XLAT withou= t > undue delay, Thanks again! > Best regards, > RD > > > CB >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > From despres.remi@laposte.net Thu Sep 6 08:43:31 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B67B021F86FC for ; Thu, 6 Sep 2012 08:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hfLBVwiF5yIt for ; Thu, 6 Sep 2012 08:43:30 -0700 (PDT) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18E0121F86EC for ; Thu, 6 Sep 2012 08:43:27 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2119.sfr.fr (SMTP Server) with ESMTP id 1EB46700007F; Thu, 6 Sep 2012 17:43:25 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2119.sfr.fr (SMTP Server) with ESMTP id 9E2567000085; Thu, 6 Sep 2012 17:43:24 +0200 (CEST) X-SFR-UUID: 20120906154324647.9E2567000085@msfrf2119.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: Date: Thu, 6 Sep 2012 17:43:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <504392E0.8070802@bogus.com> <448050D4-84F9-4F52-BF7E-347EA451A96C@laposte.net> <0AB559C2-855C-41F3-92D1-07F973EB760A@laposte.net> To: Cameron Byrne X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] 464XLAT - support of /64 delegated prefixes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 15:43:31 -0000 2012-09-06 17:27, Cameron Byrne : > R=E9mi , >=20 > On Thu, Sep 6, 2012 at 7:22 AM, R=E9mi Despr=E9s = wrote: >>=20 >> 2012-09-06 15:16, Cameron Byrne : >>=20 >>=20 >> On Sep 6, 2012 1:03 AM, "Lorenzo Colitti" wrote: >>>=20 >>> On Thu, Sep 6, 2012 at 4:54 PM, Maoke wrote: >>>>=20 >>>> how can we ensure the above addresses do not conflict with any = manually, >>>> arbitrarily configured addresses? i am lost. :P - maoke >>>=20 >>>=20 >>> AIUI, we say "conflicts are impossible, because this is a reserved = range", >>> and then we cross our fingers. >>>=20 >>=20 >> I agree with Lorenzo's sarcasm. >>=20 >> This "sarcasm" isn't deserved: one who manually configures a host = with an >> invalid address with regard to RFC 4291 should cross his fingers in = all >> cases, with 464XLAT or not. >>=20 >=20 > Here are the facts as i see them: >=20 > 1. Many people on the list, including me, say we must share a /64 > from WAN to LAN >=20 > 2. Multiple real world implementations of this /64 sharing exists in > various types of nodes, including the AOSP Android code. Hermant also > references he has experience with some CPE that share a /64 in > production networks using ND Proxy. And there is also the case of a > CPE that simply bridges WAN to LAN and has a logical / virtual place > on that share /64. Lorenzo also specified a method here > http://www.ietf.org/mail-archive/web/v6ops/current/msg13977.html >=20 > 3. There is no standards track way to share a /64 from WAN to LAN, > the party line is DHCP-PD is the solution. New protocol work happens > in 6MAN. >=20 > 4. Remi has provided, what i consider, to be a workable solution that > avoids the case of NAT44. >=20 > So, we have a problem since #1 and #3 are a challenge, and #2 exists >=20 > #4 is workable, but it has opponents and requires "hard coding" and > really is not core to 464XLAT. Removing the need for NAT44 is not a > goal, the overhead of having NAT44 is inconsequential to a modern CPE, > including smartphones. Related to hard coding, there is no RFC1918 > address that we can pick. ISPs are now dictating how residential LANs > must be configured so they do not overlap with the SP network's use of > RFC1918 space ... > = http://keithbartholomew.com/2012/04/how-att-u-verse-broke-my-home-network/= >=20 >=20 >> Besides, it is particularly unexpected from you, after you stated "In = the >> case of the Android CLAT code that was submitted to AOSP, the /64 is = simply >> copied from the WAN 3G/4G interfaces to the LAN. No magic. No ND = Proxy. No >> DHCP. But, it works for all known cases". >> With this, collisions between CLATs and host addresses are possible = even >> with well-behaved hosts =3D> The need to cross fingers is permanent = ;-). >=20 > No, NDP/DAD runs normally on the LAN side as a /64 and the WAN side is > a /128 ... /128 on WAN is normal operations for a Android phone on a > 3GPP network. >=20 > The main takeaway from this: implementation specific solutions are ok > and left to the implementer and network operator to consider pros and > cons. >=20 > The party line remains: DHCP-PD is best! While reality dictates and > the 464XLAT I-D must reflect that /64 sharing exists. >=20 > I am not confident that this group of folks who don't have a very good > understanding of probability (manually configures 64 bit collisions?!) > will come to a consensus on a general solution, and even if they can > come to a consensus, 464XLAT is not the right vehicle for specifying > how a /64 is shared across interfaces. >=20 > Let us just say /64 sharing exists and move on. If we believe /64 > must be codified on standards track, 6MAN may be the place for that > with its own I-D. It seems to me, we should agree that: (a) How to share a /64 between WAN and LAN IS NOT a 464XLAT issue (your = detailed point above). (b) What remains a 464XLAT issue is to ensure that, whatever the chosen = solution for (a), 464XLAT can avoid to interfere with it. That's what is = achieved with the proposed reservation of three currently unused = IID-ranges, and the well-chosen /96 in CLAT addresses. RD >=20 >> By using the proposed IANA-EUI-64 based /96, this is avoided and, = with a MAY >> in the draft, the somewhat risky choice you have described remains = possible. >>=20 >> That said, we have been pushing this draft for a year trying to drive >> concensus. If we do not limit the scope to the core objective we will = be >> here for another year while the issue of ipv4-only hosts and apps = delays and >> hinders broader ipv6 deployment. >>=20 >> On this, we agree. >>=20 >> Still convinced to be one of the best supporters of a good 464XLAT = without >> undue delay, >=20 > Thanks again! >=20 >> Best regards, >> RD >>=20 >>=20 >> CB >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >>=20 From phdgang@gmail.com Thu Sep 6 09:22:59 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EDD521F8624 for ; Thu, 6 Sep 2012 09:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VqL8HYcam1ty for ; Thu, 6 Sep 2012 09:22:58 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4969721F8594 for ; Thu, 6 Sep 2012 09:22:58 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1790709vbb.31 for ; Thu, 06 Sep 2012 09:22:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=prcewfLUO+0cWbSgsN9D6KOeY1xExnTX9bfmd8AnGJE=; b=JL3wPENvISOgoPKQBAhqUQCrmzh/3Lv2njpA/kKUh17spbwr82QoPFDUwKVc/Hpjbo ZkZVYLR/TP9DNVPFtHEQ/e41n08MROWSflT8q8GoesrQOG+h2tzyYcznNAPjo/pZpzT/ zdLf2OqoI4GNzCZHCkgro2Sd5dVmoevOSPgDiMniA1e8agxW3u7s51urW58sTPbSsT42 3+WQmcZty3WKHk5EvlzVmY0PPCQrQKCpOjESzFI6hriNhp1wiIYnXqA4zFuuSU+SrT20 YL4aouqOiTouWDfTA/6YsgdUdaiJwsBPMFZJ9a3wmtbjnz9hQh9dc5amiqpf50LpZWEM PY9w== MIME-Version: 1.0 Received: by 10.220.141.202 with SMTP id n10mr2967868vcu.49.1346948577768; Thu, 06 Sep 2012 09:22:57 -0700 (PDT) Received: by 10.58.114.231 with HTTP; Thu, 6 Sep 2012 09:22:57 -0700 (PDT) In-Reply-To: References: Date: Fri, 7 Sep 2012 00:22:57 +0800 Message-ID: From: GangChen To: Lorenzo Colitti Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 16:22:59 -0000 2012/9/6, Lorenzo Colitti : > On Thu, Sep 6, 2012 at 11:52 PM, GangChen wrote: > >> I didn't fully get your point. 464xlat is not a fridge actually :) >> Again, please directly identify your technical points/concerns. >> > > I think the comment was intended to mean: > > 2. BIH is not necessary for the operation of 464xlat, so it doesn't have to > be in the draft. 464xlat is intended to support IPv4-only capable application. There is no limitation CLAT only can communicate with IPv4 server in the wild. Missing BIH is incomplete when communication with IPv6 is needed. > 3. The scenario that BIH is intended to solve is further in the future and > we do not yet have as much operational experience with it. So it should not > go into a BCP for 464xlat, which is a different transition mechanism. RFC6535 does exist on standard track. It's already approved it got significant community reviews and appears to enjoy enough community interest according to RFC2026. It's qualified to go into a BCP. More operational experiences are always needed for any technologies at any time. It should not be an obstacle to be adopted in a proper scenario. 464XLAT purpose is to facilitate deployments and use of IPv6-only networks. It does this better if combined there is BIH in CLAT nodes. It's indeed in the same building block > 4. Saying "you can use BIH with 464xlat" is not very useful by itself > because 464xlat doesn't work together with BIH in any special way. Supporting IPv4-only application is the same goal, under which 464xlat surely should work with BIH. > It only > provides connectivity. Yes, you can do BIH with 464xlat. But you can also > do it with DS-Lite, or 6rd, or native dual-stack. You can't. The requirements doing encapsulation and translation are likely exclusive. I don't think DS-lite and BIH could stay together from an operational point of view. 6rd even has reversed scenario, i.e. 646. Native dual-stack has both IPv4/IPv6 connection, but scenario of BIH is targeting to IPv6-only approach. As you indicated it's doable for BIH with 464xlat and the draft already identify the possibilities according to WG feedback, I don't understand why not intentionally allow them to be complementary. > Saying "you can use BIH > with 464xlat" is like saying "you can run HTTP over TCP": it's true, but it > doesn't need to go into the TCP RFC. Isn't our goal to identify the BCP? TCP is a standard, not BCP. BRs Gang > For what it's worth, I agree. > From wdec.ietf@gmail.com Thu Sep 6 09:39:03 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7169C21F86E5 for ; Thu, 6 Sep 2012 09:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.073 X-Spam-Level: X-Spam-Status: No, score=-3.073 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OVFtIKocGq9e for ; Thu, 6 Sep 2012 09:39:02 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4048121F86DF for ; Thu, 6 Sep 2012 09:39:02 -0700 (PDT) Received: by eekb45 with SMTP id b45so870878eek.31 for ; Thu, 06 Sep 2012 09:39:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Aw58OCKHASMvxkOz8lMA8A72gzdyjmlElhtxbz8EzaA=; b=YNqwdY0fX/DrXmJdk1Ltdz9O7xJl0rbKpb4vHN02AG7ioIhHTzrDfblLhSc6Q43DFF nZOCHxwqLg7IEQMiQERda24kS2Z0pro+Kh/twVdRo3Zag83orHxq9mJFc2jgOu7y0NG4 clikUAQvCO9UIvI+c3KbY8F6sxyCagUvqfNMj6gdUR12JGe5x5t+F8vG6sUfEsR/a+3p YhF7iPAf4SHErTNFUZScneJtkdxIlLYL31Qck3JQLNu7GYGruppLqhubiYArT6WjIUBX 0tijZlyoKgxR2fVNtB3HWf+IVVm25r5QE6Lm5IYw7exNgSmrwmeJ8/uEgV09VSimY+ZW kLeg== MIME-Version: 1.0 Received: by 10.14.205.6 with SMTP id i6mr4051220eeo.13.1346949541296; Thu, 06 Sep 2012 09:39:01 -0700 (PDT) Received: by 10.14.45.68 with HTTP; Thu, 6 Sep 2012 09:39:01 -0700 (PDT) In-Reply-To: References: Date: Thu, 6 Sep 2012 18:39:01 +0200 Message-ID: From: Wojciech Dec To: GangChen Content-Type: multipart/alternative; boundary=047d7b343b8af07b2804c90b20b2 Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 16:39:03 -0000 --047d7b343b8af07b2804c90b20b2 Content-Type: text/plain; charset=ISO-8859-1 On 6 September 2012 18:22, GangChen wrote: > 2012/9/6, Lorenzo Colitti : > > On Thu, Sep 6, 2012 at 11:52 PM, GangChen wrote: > > > >> I didn't fully get your point. 464xlat is not a fridge actually :) > >> Again, please directly identify your technical points/concerns. > >> > > > > I think the comment was intended to mean: > > > > 2. BIH is not necessary for the operation of 464xlat, so it doesn't have > to > > be in the draft. > > 464xlat is intended to support IPv4-only capable application. > There is no limitation CLAT only can communicate with IPv4 server in the > wild. > Missing BIH is incomplete when communication with IPv6 is needed. > Strictly speaking that is not true. The stateless NAT64 (4->6) characteristic of the clat gives 4-to-6 communication by default. What it doesn't give is 4-to-6-internet , which BIH can arguably provide, but it is certainly an additional option, rather than the core of what the xlat solution is primarily intended for. -Woj. > > > > 3. The scenario that BIH is intended to solve is further in the future > and > > we do not yet have as much operational experience with it. So it should > not > > go into a BCP for 464xlat, which is a different transition mechanism. > > RFC6535 does exist on standard track. It's already approved it got > significant community reviews and appears to enjoy enough community > interest according to RFC2026. It's qualified to go into a BCP. More > operational experiences are always needed for any technologies at any > time. It should not be an obstacle to be adopted in a proper scenario. > 464XLAT purpose is to facilitate deployments and use of IPv6-only > networks. It does this better if combined there is BIH in CLAT nodes. > It's indeed in the same building block > > > 4. Saying "you can use BIH with 464xlat" is not very useful by itself > > because 464xlat doesn't work together with BIH in any special way. > > Supporting IPv4-only application is the same goal, under which 464xlat > surely should work with BIH. > > > It only > > provides connectivity. Yes, you can do BIH with 464xlat. But you can also > > do it with DS-Lite, or 6rd, or native dual-stack. > > You can't. The requirements doing encapsulation and translation are > likely exclusive. I don't think DS-lite and BIH could stay together > from an operational point of view. 6rd even has reversed scenario, > i.e. 646. Native dual-stack has both IPv4/IPv6 connection, but > scenario of BIH is targeting to IPv6-only approach. As you indicated > it's doable for BIH with 464xlat and the draft already identify the > possibilities according to WG feedback, I don't understand why not > intentionally allow them to be complementary. > > > > Saying "you can use BIH > > with 464xlat" is like saying "you can run HTTP over TCP": it's true, but > it > > doesn't need to go into the TCP RFC. > > Isn't our goal to identify the BCP? TCP is a standard, not BCP. > > BRs > > Gang > > > For what it's worth, I agree. > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --047d7b343b8af07b2804c90b20b2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 6 September 2012 18:22, GangChen <ph= dgang@gmail.com> wrote:
2012/9/6, Lorenzo Colitti <lorenzo= @google.com>:
> On Thu, Sep 6, 2012 at 11:52 PM, GangChen <phdgang@gmail.com> wrote:
>
>> I didn't fully get your point. 464xlat is not a fridge actuall= y :)
>> Again, please directly identify your technical points/concerns. >>
>
> I think the comment was intended to mean:
>
> 2. BIH is not necessary for the operation of 464xlat, so it doesn'= t have to
> be in the draft.

464xlat is intended to support IPv4-only capable application.
There is no limitation CLAT only can communicate with IPv4 server in the wi= ld.
Missing BIH is incomplete when communication with IPv6 is needed.


Strictly speaking that is not true. The stateless NAT64= (4->6) characteristic of=A0 the clat gives 4-to-6 communication by defa= ult. What it doesn't give is 4-to-6-internet , which BIH can arguably p= rovide, but it is certainly an additional option, rather than the core of w= hat the xlat solution is primarily intended for.

-Woj.


> 3. The scenario that BIH is intended to solve is further in the future= and
> we do not yet have as much operational experience with it. So it shoul= d not
> go into a BCP for 464xlat, which is a different transition mechanism.<= br>
RFC6535 does exist on standard track. It's already approved it go= t
significant community reviews and appears to enjoy enough community
interest according to RFC2026. It's qualified to go into a BCP. More operational experiences are always needed for any technologies at any
time. It should not be an obstacle to be adopted in a proper scenario.
464XLAT purpose is to facilitate deployments and use of IPv6-only
networks. It does this better if combined there is BIH in CLAT nodes.
It's indeed in the same building block

> 4. Saying "you can use BIH with 464xlat" is not very useful = by itself
> because 464xlat doesn't work together with BIH in any special way.=

Supporting IPv4-only application is the same goal, under which 464xla= t
surely should work with BIH.

> It only
> provides connectivity. Yes, you can do BIH with 464xlat. But you can a= lso
> do it with DS-Lite, or 6rd, or native dual-stack.

You can't. The requirements doing encapsulation and translation a= re
likely exclusive. I don't think DS-lite and BIH could stay together
from an operational point of view. 6rd even has reversed scenario,
i.e. 646. Native dual-stack has both IPv4/IPv6 connection, but
scenario of BIH is targeting to IPv6-only approach. As you indicated
it's doable for BIH with 464xlat and the draft already identify the
possibilities according to WG feedback, =A0I don't understand why not intentionally allow them to be complementary.


> Saying "you can use BIH
> with 464xlat" is like saying "you can run HTTP over TCP"= ;: it's true, but it
> doesn't need to go into the TCP RFC.

Isn't our goal to identify the BCP? TCP is a standard, not BCP.
BRs

Gang

> For what it's worth, I agree.
>
_____________________________= __________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

--047d7b343b8af07b2804c90b20b2-- From despres.remi@laposte.net Thu Sep 6 10:23:13 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A69221F8568 for ; Thu, 6 Sep 2012 10:23:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.421 X-Spam-Level: X-Spam-Status: No, score=-1.421 tagged_above=-999 required=5 tests=[AWL=-0.073, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SAjKih-AqvwL for ; Thu, 6 Sep 2012 10:23:12 -0700 (PDT) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.2]) by ietfa.amsl.com (Postfix) with ESMTP id CCAB521F852C for ; Thu, 6 Sep 2012 10:23:11 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2108.sfr.fr (SMTP Server) with ESMTP id A9F547000106; Thu, 6 Sep 2012 19:23:10 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2108.sfr.fr (SMTP Server) with ESMTP id 4A0AE7000103; Thu, 6 Sep 2012 19:23:10 +0200 (CEST) X-SFR-UUID: 20120906172310303.4A0AE7000103@msfrf2108.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-21--722197351 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Thu, 6 Sep 2012 19:23:09 +0200 Message-Id: References: To: Wojciech Dec X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 17:23:13 -0000 --Apple-Mail-21--722197351 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-09-06 =E0 18:39, Wojciech Dec a =E9crit : >=20 >=20 > On 6 September 2012 18:22, GangChen wrote: > 2012/9/6, Lorenzo Colitti : > > On Thu, Sep 6, 2012 at 11:52 PM, GangChen wrote: > > > >> I didn't fully get your point. 464xlat is not a fridge actually :) > >> Again, please directly identify your technical points/concerns. > >> > > > > I think the comment was intended to mean: > > > > 2. BIH is not necessary for the operation of 464xlat, so it doesn't = have to > > be in the draft. >=20 > 464xlat is intended to support IPv4-only capable application. > There is no limitation CLAT only can communicate with IPv4 server in = the wild. > Missing BIH is incomplete when communication with IPv6 is needed. Although, as I have said, don't see the reference to BIH as absolutely = necessary in the 4X4XLAT draft, I think that not only it makes no harm = but also is useful to clarify how IPv4-only applications can = communicate, with standard-track RFCs, in IPv6-only environments . I therefore don't understand reasons to insist that the existing = complementarity of 464XLAT and BIH in this respect should no longer be = mentioned. At a time when there are still discussions on functional aspects of = 464XLAT, this particular discussion is IMHO a waste of time. Preferred approach: keep the sentence, and proceed.=20 FWIW. RD >=20 >=20 > Strictly speaking that is not true. The stateless NAT64 (4->6) = characteristic of the clat gives 4-to-6 communication by default. What = it doesn't give is 4-to-6-internet , which BIH can arguably provide, but = it is certainly an additional option, rather than the core of what the = xlat solution is primarily intended for. >=20 > -Woj. >=20 >=20 > > 3. The scenario that BIH is intended to solve is further in the = future and > > we do not yet have as much operational experience with it. So it = should not > > go into a BCP for 464xlat, which is a different transition = mechanism. >=20 > RFC6535 does exist on standard track. It's already approved it got > significant community reviews and appears to enjoy enough community > interest according to RFC2026. It's qualified to go into a BCP. More > operational experiences are always needed for any technologies at any > time. It should not be an obstacle to be adopted in a proper scenario. > 464XLAT purpose is to facilitate deployments and use of IPv6-only > networks. It does this better if combined there is BIH in CLAT nodes. > It's indeed in the same building block >=20 > > 4. Saying "you can use BIH with 464xlat" is not very useful by = itself > > because 464xlat doesn't work together with BIH in any special way. >=20 > Supporting IPv4-only application is the same goal, under which 464xlat > surely should work with BIH. >=20 > > It only > > provides connectivity. Yes, you can do BIH with 464xlat. But you can = also > > do it with DS-Lite, or 6rd, or native dual-stack. >=20 > You can't. The requirements doing encapsulation and translation are > likely exclusive. I don't think DS-lite and BIH could stay together > from an operational point of view. 6rd even has reversed scenario, > i.e. 646. Native dual-stack has both IPv4/IPv6 connection, but > scenario of BIH is targeting to IPv6-only approach. As you indicated > it's doable for BIH with 464xlat and the draft already identify the > possibilities according to WG feedback, I don't understand why not > intentionally allow them to be complementary. >=20 >=20 > > Saying "you can use BIH > > with 464xlat" is like saying "you can run HTTP over TCP": it's true, = but it > > doesn't need to go into the TCP RFC. >=20 > Isn't our goal to identify the BCP? TCP is a standard, not BCP. >=20 > BRs >=20 > Gang >=20 > > For what it's worth, I agree. > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail-21--722197351 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1


On 6 September 2012 = 18:22, GangChen <phdgang@gmail.com> = wrote:
2012/9/6, Lorenzo Colitti <lorenzo@google.com>:
> On Thu, Sep 6, 2012 at 11:52 PM, GangChen <phdgang@gmail.com> wrote:
>
>> I didn't fully get your point. 464xlat is not a fridge actually = :)
>> Again, please directly identify your technical = points/concerns.
>>
>
> I think the comment was intended to mean:
>
> 2. BIH is not necessary for the operation of 464xlat, so it doesn't = have to
> be in the draft.

464xlat is intended to support IPv4-only capable application.
There is no limitation CLAT only can communicate with IPv4 server in the = wild.
Missing BIH is incomplete when communication with IPv6 is = needed.

Although, = as I have said,  don't see the reference to BIH as absolutely = necessary in the 4X4XLAT draft, I think that not only it makes no harm = but also is useful to clarify how IPv4-only applications can = communicate, with standard-track RFCs, in IPv6-only = environments .
I therefore don't understand reasons to insist = that the existing complementarity of 464XLAT and BIH in this = respect should no longer be mentioned.

At a = time when there are still discussions on functional aspects of 464XLAT, = this particular discussion is IMHO a waste of time.
Preferred = approach: keep the sentence, and = proceed. 

FWIW.

RD<= /div>




Strictly speaking that is not true. = The stateless NAT64 (4->6) characteristic of  the clat gives = 4-to-6 communication by default. What it doesn't give is 4-to-6-internet = , which BIH can arguably provide, but it is certainly an additional = option, rather than the core of what the xlat solution is primarily = intended for.

-Woj.


> 3. The scenario that BIH is intended to solve is further in the = future and
> we do not yet have as much operational experience with it. So it = should not
> go into a BCP for 464xlat, which is a different transition = mechanism.

RFC6535 does exist on standard track. It's already approved it = got
significant community reviews and appears to enjoy enough community
interest according to RFC2026. It's qualified to go into a BCP. More
operational experiences are always needed for any technologies at = any
time. It should not be an obstacle to be adopted in a proper = scenario.
464XLAT purpose is to facilitate deployments and use of IPv6-only
networks. It does this better if combined there is BIH in CLAT = nodes.
It's indeed in the same building block

> 4. Saying "you can use BIH with 464xlat" is not very useful by = itself
> because 464xlat doesn't work together with BIH in any special = way.

Supporting IPv4-only application is the same goal, under which = 464xlat
surely should work with BIH.

> It only
> provides connectivity. Yes, you can do BIH with 464xlat. But you = can also
> do it with DS-Lite, or 6rd, or native dual-stack.

You can't. The requirements doing encapsulation and translation = are
likely exclusive. I don't think DS-lite and BIH could stay together
from an operational point of view. 6rd even has reversed scenario,
i.e. 646. Native dual-stack has both IPv4/IPv6 connection, but
scenario of BIH is targeting to IPv6-only approach. As you indicated
it's doable for BIH with 464xlat and the draft already identify the
possibilities according to WG feedback,  I don't understand why = not
intentionally allow them to be complementary.


> Saying "you can use BIH
> with 464xlat" is like saying "you can run HTTP over TCP": it's = true, but it
> doesn't need to go into the TCP RFC.

Isn't our goal to identify the BCP? TCP is a standard, not = BCP.

BRs

Gang

> For what it's worth, I agree.
>
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops

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

= --Apple-Mail-21--722197351-- From fibrib@gmail.com Thu Sep 6 19:34:00 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 306BD21F84E7 for ; Thu, 6 Sep 2012 19:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.848 X-Spam-Level: X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T5CjSKZl5l0K for ; Thu, 6 Sep 2012 19:33:59 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id AF90021F84F8 for ; Thu, 6 Sep 2012 19:33:58 -0700 (PDT) Received: by eaai11 with SMTP id i11so781806eaa.31 for ; Thu, 06 Sep 2012 19:33:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Kp1Gyb9yu5OrLFROEnhieRrqpQpMBc40mZ/CGzd3eW4=; b=QRti0p0PU5jthS4OqReOcTpmhCFVu6l92IbhQO/LHLxMmaHuHUowzqFj1BQypxFedi EIWngylzEFhRFkZQGjb5cLRKuQc5i8s/bjUU1nlNeaPPawq1uAmATQzDaw8YiNWFIH3A 39933RaUioSr8fpKVxUSnU0tewAFIG9ZmbNyrKJbxc04GDwWT4c/S3ejyl2H62IPFvSw LQiT5VKtQKEFt8mKrry12c2SnzUCUHBF631OijGk7HjGniMFr6cy/HE1UVK23YLtSQab WdoNoWhlO7iUTaOauhMaIDnf2WKodE7xHZ4+5uJGAtgqUQlKlbPggWW30IYbYbC43A6C UyEQ== MIME-Version: 1.0 Received: by 10.14.204.72 with SMTP id g48mr5710142eeo.45.1346985236953; Thu, 06 Sep 2012 19:33:56 -0700 (PDT) Received: by 10.14.97.9 with HTTP; Thu, 6 Sep 2012 19:33:56 -0700 (PDT) In-Reply-To: References: Date: Fri, 7 Sep 2012 11:33:56 +0900 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=047d7b343ccc90f9ee04c91370c3 Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 02:34:00 -0000 --047d7b343ccc90f9ee04c91370c3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable dear Remi, as we are talking about a BCP, if 464xlat doc states BIH is an indispensible part of the standard, our customers will require us to definitely provide such a function or such an option rather than any other alternatives in the service suite. i doubt this is the common floor the working group is on. (response to Gang's comment also...) yes, i did reviewed all the thread you linked to me. thanks again for the links. my observation is the authors accepted that phrase in order to move on. i fully understand that but we are obliged to share our understanding too, maybe late (if so i apologize). if we see something but not say out, we were irresponsible to the community. please also pay attention to the statement of the movitation in the Introduction of the 464xlat: The 464XLAT architecture only supports IPv4 in the client server model, where the server has a global IPv4 address. you argued that an IPv4 address is needed for the IPv6-translatable server address, it is true and here you are, and, as Wojciech mentioned, CLAT has supported that by default. we have no business with the IPv6-only server without holding a global IPv4 address, in the problem scope! on the other hand, *464xlat is indended to support IPv4-only application* - this of your understanding, MHO, is biased from the above 464xlat problem statement (it is also quite confusing me because, AFAIK, "BIH is indended to support IPv4-only applications" :P :P :P). therefore, IMHO, citing BIH is contradictory to the 464xlat problem statement, making the document itself inconsistent. - maoke 2012/9/7 R=E9mi Despr=E9s > > Le 2012-09-06 =E0 18:39, Wojciech Dec a =E9crit : > > > > On 6 September 2012 18:22, GangChen wrote: > >> 2012/9/6, Lorenzo Colitti : >> > On Thu, Sep 6, 2012 at 11:52 PM, GangChen wrote: >> > >> >> I didn't fully get your point. 464xlat is not a fridge actually :) >> >> Again, please directly identify your technical points/concerns. >> >> >> > >> > I think the comment was intended to mean: >> > >> > 2. BIH is not necessary for the operation of 464xlat, so it doesn't >> have to >> > be in the draft. >> >> 464xlat is intended to support IPv4-only capable application. >> There is no limitation CLAT only can communicate with IPv4 server in the >> wild. >> Missing BIH is incomplete when communication with IPv6 is needed. >> > > Although, as I have said, don't see the reference to BIH as absolutely > necessary in the 4X4XLAT draft, I think that not only it makes no harm bu= t > also is useful to clarify how IPv4-only applications can communicate, wit= h > standard-track RFCs, in IPv6-only environments . > I therefore don't understand reasons to insist that the > existing complementarity of 464XLAT and BIH in this respect should no > longer be mentioned. > > At a time when there are still discussions on functional aspects of > 464XLAT, this particular discussion is IMHO a waste of time. > Preferred approach: keep the sentence, and proceed. > > FWIW. > > RD > > > > > Strictly speaking that is not true. The stateless NAT64 (4->6) > characteristic of the clat gives 4-to-6 communication by default. What i= t > doesn't give is 4-to-6-internet , which BIH can arguably provide, but it = is > certainly an additional option, rather than the core of what the xlat > solution is primarily intended for. > > -Woj. > >> >> >> > 3. The scenario that BIH is intended to solve is further in the future >> and >> > we do not yet have as much operational experience with it. So it shoul= d >> not >> > go into a BCP for 464xlat, which is a different transition mechanism. >> >> RFC6535 does exist on standard track. It's already approved it got >> significant community reviews and appears to enjoy enough community >> interest according to RFC2026. It's qualified to go into a BCP. More >> operational experiences are always needed for any technologies at any >> time. It should not be an obstacle to be adopted in a proper scenario. >> 464XLAT purpose is to facilitate deployments and use of IPv6-only >> networks. It does this better if combined there is BIH in CLAT nodes. >> It's indeed in the same building block >> >> > 4. Saying "you can use BIH with 464xlat" is not very useful by itself >> > because 464xlat doesn't work together with BIH in any special way. >> >> Supporting IPv4-only application is the same goal, under which 464xlat >> surely should work with BIH. >> >> > It only >> > provides connectivity. Yes, you can do BIH with 464xlat. But you can >> also >> > do it with DS-Lite, or 6rd, or native dual-stack. >> >> You can't. The requirements doing encapsulation and translation are >> likely exclusive. I don't think DS-lite and BIH could stay together >> from an operational point of view. 6rd even has reversed scenario, >> i.e. 646. Native dual-stack has both IPv4/IPv6 connection, but >> scenario of BIH is targeting to IPv6-only approach. As you indicated >> it's doable for BIH with 464xlat and the draft already identify the >> possibilities according to WG feedback, I don't understand why not >> intentionally allow them to be complementary. >> >> >> > Saying "you can use BIH >> > with 464xlat" is like saying "you can run HTTP over TCP": it's true, >> but it >> > doesn't need to go into the TCP RFC. >> >> Isn't our goal to identify the BCP? TCP is a standard, not BCP. >> >> BRs >> >> Gang >> >> > For what it's worth, I agree. >> > >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --047d7b343ccc90f9ee04c91370c3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
dear Remi,
=A0
as we are talking about a BCP, if = 464xlat doc states BIH is an indispensible part of the standard, our custom= ers will require us to definitely provide such a function or such an option= rather than=A0any=A0other alternatives=A0in the service suite. i doubt=A0t= his is the common floor=A0the=A0working=A0group is=A0on.
=A0
(response to Gang's comment also...)
=A0
yes, i did reviewed all the thread you linked to me. thanks again = for the links. my observation is=A0the authors accepted that phrase in orde= r to move on. i=A0fully understand that but=A0we are=A0obliged to share=A0o= ur understanding too, maybe late (if so i apologize). if=A0we see something= but not say out,=A0we=A0were=A0irresponsible to the community. =A0
please also pay attention to the statement of the movitation in = the Introduction of the 464xlat:
=A0
=A0=A0 The 464XLA= T architecture only supports IPv4 in the
=A0=A0 client server model, whe= re the server has a global IPv4 address.
you argued=A0that an IPv4 address is needed for the IPv6-transla= table server address, it is true and=A0here you are, and, as Wojciech menti= oned, CLAT has supported that by=A0default. we have no business with the IP= v6-only server without holding a global IPv4 address, in the problem scope!=
=A0
on the other hand, *464xlat is indended to support IPv4-= only application* - this=A0of your understanding, MHO, is biased=A0from the= above 464xlat problem statement (it is also quite confusing me because, AF= AIK, "BIH is indended to support IPv4-only applications" :P :P :P= ).
=A0
therefore, IMHO, citing BIH is contradictory to the 464x= lat problem statement, making the document itself inconsistent.
= =A0
- maoke
=A0
2012/9= /7 R=E9mi Despr=E9s <despres.remi@laposte.net>

Le 2012-= 09-06 =E0 18:39, Wojciech Dec a =E9crit :



On 6 September 2012 18:22, GangChen <phdgang@gmail.com> wrote:
2012/9/6, Lorenzo Colitti <lorenzo@google.com>:
> On Thu, Sep 6, 2012 at 11:52 PM, GangChen <phdgang@gmail.com> wrote:
>
>> I didn't fully get your point. 464xlat is not a fridge actuall= y :)
>> Again, please directly identify your technical points/concerns. >>
>
> I think the comment was intended to mean:
>
> 2. BIH is not necessary for the operation of 464xlat, so it doesn'= t have to
> be in the draft.

464xlat is intended to support IPv4-only capable application.
There is no limitation CLAT only can communicate with IPv4 server in the wi= ld.
Missing BIH is incomplete when communication with IPv6 is needed.

Although, as I have sai= d, =A0don't see the reference to BIH as absolutely necessary in the 4X4= XLAT draft, I think that not only it makes no harm but also is useful to cl= arify how IPv4-only applications can communicate,=A0with standard-track RFC= s,=A0in IPv6-only environments .
I therefore don't understand reasons to insist that the existing= =A0complementarity of=A0464XLAT and BIH in this respect should no longer be= mentioned.

At a time when there are still discuss= ions on functional aspects of 464XLAT, this particular discussion is IMHO a= waste of time.
Preferred approach: keep the sentence, and proceed.=A0

<= /div>
FWIW.
RD



Strictly speaking that is not true.= The stateless NAT64 (4->6) characteristic of=A0 the clat gives 4-to-6 c= ommunication by default. What it doesn't give is 4-to-6-internet , whic= h BIH can arguably provide, but it is certainly an additional option, rathe= r than the core of what the xlat solution is primarily intended for.

-Woj.


> 3. The scenario that BIH is intended to solve is further in the future= and
> we do not yet have as much operational experience with it. So it shoul= d not
> go into a BCP for 464xlat, which is a different transition mechanism.<= br>
RFC6535 does exist on standard track. It's already approved it go= t
significant community reviews and appears to enjoy enough community
interest according to RFC2026. It's qualified to go into a BCP. More operational experiences are always needed for any technologies at any
time. It should not be an obstacle to be adopted in a proper scenario.
464XLAT purpose is to facilitate deployments and use of IPv6-only
networks. It does this better if combined there is BIH in CLAT nodes.
It's indeed in the same building block

> 4. Saying "you can use BIH with 464xlat" is not very useful = by itself
> because 464xlat doesn't work together with BIH in any special way.=

Supporting IPv4-only application is the same goal, under which 464xla= t
surely should work with BIH.

> It only
> provides connectivity. Yes, you can do BIH with 464xlat. But you can a= lso
> do it with DS-Lite, or 6rd, or native dual-stack.

You can't. The requirements doing encapsulation and translation a= re
likely exclusive. I don't think DS-lite and BIH could stay together
from an operational point of view. 6rd even has reversed scenario,
i.e. 646. Native dual-stack has both IPv4/IPv6 connection, but
scenario of BIH is targeting to IPv6-only approach. As you indicated
it's doable for BIH with 464xlat and the draft already identify the
possibilities according to WG feedback, =A0I don't understand why not intentionally allow them to be complementary.


> Saying "you can use BIH
> with 464xlat" is like saying "you can run HTTP over TCP"= ;: it's true, but it
> doesn't need to go into the TCP RFC.

Isn't our goal to identify the BCP? TCP is a standard, not BCP.
BRs

Gang

> For what it's worth, I agree.
>
_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

_______________________________________________
v6ops mailing list
v6ops@ietf.org
http= s://www.ietf.org/mailman/listinfo/v6ops


______________________________= _________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops


--047d7b343ccc90f9ee04c91370c3-- From fibrib@gmail.com Thu Sep 6 20:25:40 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B3AA21E805A for ; Thu, 6 Sep 2012 20:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.501 X-Spam-Level: X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id meBOIN8Sdien for ; Thu, 6 Sep 2012 20:25:39 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id AEE4921E8056 for ; Thu, 6 Sep 2012 20:25:38 -0700 (PDT) Received: by eekb45 with SMTP id b45so1023413eek.31 for ; Thu, 06 Sep 2012 20:25:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sDbRoOTMFeYsWnrk9RvV91fLnAe21Re5bcdkmV/hP54=; b=wNoKk+7MQ7N7oU8zOPVp3cfOE2wdSAsSR2IwuR+mOCc7+SM16XVxXU/PA1d8gB2Fke ILunoDTUWVsEfNow3NT1+ukH5JGx/6QRInCtfMKq+IP+RPlELP26XS1xww4y/V2JrKji 2hnYdPgawEaiemGUCUHZPvsudCPIqt+FmCM3RO633ODUSynfpfZoMvRm3TXb8VmDToLI Hf2Ur7U9cchWsb+h1IaUmX5mjTCgfJRmYIwZVavepSJkdW0ZtxaXEK5WwWLAHJV/9AK7 HWdWfnTo4zib5zNpzFqeLdg1WQN4P0902g3/mU0gCqb79xsDKmVg48k70qnZ8SEMTWeZ fOZQ== MIME-Version: 1.0 Received: by 10.14.172.129 with SMTP id t1mr5836399eel.34.1346988337690; Thu, 06 Sep 2012 20:25:37 -0700 (PDT) Received: by 10.14.97.9 with HTTP; Thu, 6 Sep 2012 20:25:37 -0700 (PDT) In-Reply-To: References: Date: Fri, 7 Sep 2012 12:25:37 +0900 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=047d7b603c1262768604c9142908 Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 03:25:40 -0000 --047d7b603c1262768604c9142908 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/9/7 R=E9mi Despr=E9s > > Le 2012-09-06 =E0 18:39, Wojciech Dec a =E9crit : > > > > On 6 September 2012 18:22, GangChen wrote: > >> 2012/9/6, Lorenzo Colitti : >> > On Thu, Sep 6, 2012 at 11:52 PM, GangChen wrote: >> > >> >> I didn't fully get your point. 464xlat is not a fridge actually :) >> >> Again, please directly identify your technical points/concerns. >> >> >> > >> > I think the comment was intended to mean: >> > >> > 2. BIH is not necessary for the operation of 464xlat, so it doesn't >> have to >> > be in the draft. >> >> 464xlat is intended to support IPv4-only capable application. >> There is no limitation CLAT only can communicate with IPv4 server in the >> wild. >> Missing BIH is incomplete when communication with IPv6 is needed. >> > > Although, as I have said, don't see the reference to BIH as absolutely > necessary in the 4X4XLAT draft, I think that not only it makes no harm bu= t > also is useful to clarify how IPv4-only applications can communicate, wit= h > standard-track RFCs, in IPv6-only environments . > I therefore don't understand reasons to insist that the > existing complementarity of 464XLAT and BIH in this respect should no > longer be mentioned. > > At a time when there are still discussions on functional aspects of > 464XLAT, this particular discussion is IMHO a waste of time. > > if we are not on the same floor of the problem statement and scope, discussion on fuctional aspects would be trivial and possibly confusing. - maoke > > Preferred approach: keep the sentence, and proceed. > > FWIW. > > RD > > > > > Strictly speaking that is not true. The stateless NAT64 (4->6) > characteristic of the clat gives 4-to-6 communication by default. What i= t > doesn't give is 4-to-6-internet , which BIH can arguably provide, but it = is > certainly an additional option, rather than the core of what the xlat > solution is primarily intended for. > > -Woj. > >> >> >> > 3. The scenario that BIH is intended to solve is further in the future >> and >> > we do not yet have as much operational experience with it. So it shoul= d >> not >> > go into a BCP for 464xlat, which is a different transition mechanism. >> >> RFC6535 does exist on standard track. It's already approved it got >> significant community reviews and appears to enjoy enough community >> interest according to RFC2026. It's qualified to go into a BCP. More >> operational experiences are always needed for any technologies at any >> time. It should not be an obstacle to be adopted in a proper scenario. >> 464XLAT purpose is to facilitate deployments and use of IPv6-only >> networks. It does this better if combined there is BIH in CLAT nodes. >> It's indeed in the same building block >> >> > 4. Saying "you can use BIH with 464xlat" is not very useful by itself >> > because 464xlat doesn't work together with BIH in any special way. >> >> Supporting IPv4-only application is the same goal, under which 464xlat >> surely should work with BIH. >> >> > It only >> > provides connectivity. Yes, you can do BIH with 464xlat. But you can >> also >> > do it with DS-Lite, or 6rd, or native dual-stack. >> >> You can't. The requirements doing encapsulation and translation are >> likely exclusive. I don't think DS-lite and BIH could stay together >> from an operational point of view. 6rd even has reversed scenario, >> i.e. 646. Native dual-stack has both IPv4/IPv6 connection, but >> scenario of BIH is targeting to IPv6-only approach. As you indicated >> it's doable for BIH with 464xlat and the draft already identify the >> possibilities according to WG feedback, I don't understand why not >> intentionally allow them to be complementary. >> >> >> > Saying "you can use BIH >> > with 464xlat" is like saying "you can run HTTP over TCP": it's true, >> but it >> > doesn't need to go into the TCP RFC. >> >> Isn't our goal to identify the BCP? TCP is a standard, not BCP. >> >> BRs >> >> Gang >> >> > For what it's worth, I agree. >> > >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --047d7b603c1262768604c9142908 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/9/7 R=E9mi Despr=E9s <despr= es.remi@laposte.net>

Le 2012-09-06 =E0 18:39, = Wojciech Dec a =E9crit :



On 6 September 2012 18:22, GangChen <= span dir=3D"ltr"><phdgang@gmail.com> wrote:
2012/9/6, Lorenzo Colitti <lorenzo@google.com>:
> On Thu, Sep 6, 2012 at 11:52 PM, GangChen <phdgang@gmail.com> wrote:
>
>> I didn't fully get your point. 464xlat is not a fridge actuall= y :)
>> Again, please directly identify your technical points/concerns. >>
>
> I think the comment was intended to mean:
>
> 2. BIH is not necessary for the operation of 464xlat, so it doesn'= t have to
> be in the draft.

464xlat is intended to support IPv4-only capable application.
There is no limitation CLAT only can communicate with IPv4 server in the wi= ld.
Missing BIH is incomplete when communication with IPv6 is needed.

Although, as I have sai= d, =A0don't see the reference to BIH as absolutely necessary in the 4X4= XLAT draft, I think that not only it makes no harm but also is useful to cl= arify how IPv4-only applications can communicate,=A0with standard-track RFC= s,=A0in IPv6-only environments .
I therefore don't understand reasons to insist that the existing= =A0complementarity of=A0464XLAT and BIH in this respect should no longer be= mentioned.

At a time when there are still discuss= ions on functional aspects of 464XLAT, this particular discussion is IMHO a= waste of time.
=A0
=A0
if we are not on = the same floor of the problem statement and scope, discussion on fuctional = aspects would be trivial and possibly confusing. - maoke
=A0
=A0
Preferred appro= ach: keep the sentence, and proceed.=A0

FWIW.

RD




Strictly speaking that is not true. The state= less NAT64 (4->6) characteristic of=A0 the clat gives 4-to-6 communicati= on by default. What it doesn't give is 4-to-6-internet , which BIH can = arguably provide, but it is certainly an additional option, rather than the= core of what the xlat solution is primarily intended for.

-Woj.


> 3. The scenario that BIH is intended to solve is further in the future= and
> we do not yet have as much operational experience with it. So it shoul= d not
> go into a BCP for 464xlat, which is a different transition mechanism.<= br>
RFC6535 does exist on standard track. It's already approved it go= t
significant community reviews and appears to enjoy enough community
interest according to RFC2026. It's qualified to go into a BCP. More operational experiences are always needed for any technologies at any
time. It should not be an obstacle to be adopted in a proper scenario.
464XLAT purpose is to facilitate deployments and use of IPv6-only
networks. It does this better if combined there is BIH in CLAT nodes.
It's indeed in the same building block

> 4. Saying "you can use BIH with 464xlat" is not very useful = by itself
> because 464xlat doesn't work together with BIH in any special way.=

Supporting IPv4-only application is the same goal, under which 464xla= t
surely should work with BIH.

> It only
> provides connectivity. Yes, you can do BIH with 464xlat. But you can a= lso
> do it with DS-Lite, or 6rd, or native dual-stack.

You can't. The requirements doing encapsulation and translation a= re
likely exclusive. I don't think DS-lite and BIH could stay together
from an operational point of view. 6rd even has reversed scenario,
i.e. 646. Native dual-stack has both IPv4/IPv6 connection, but
scenario of BIH is targeting to IPv6-only approach. As you indicated
it's doable for BIH with 464xlat and the draft already identify the
possibilities according to WG feedback, =A0I don't understand why not intentionally allow them to be complementary.


> Saying "you can use BIH
> with 464xlat" is like saying "you can run HTTP over TCP"= ;: it's true, but it
> doesn't need to go into the TCP RFC.

Isn't our goal to identify the BCP? TCP is a standard, not BCP.
BRs

Gang

> For what it's worth, I agree.
>
_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

_______________________________________________
v6ops mailing list
v6ops@ietf.org
http= s://www.ietf.org/mailman/listinfo/v6ops


______________________________= _________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops


--047d7b603c1262768604c9142908-- From phdgang@gmail.com Thu Sep 6 22:59:23 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F17421F86AF for ; Thu, 6 Sep 2012 22:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ktAeiESuF38B for ; Thu, 6 Sep 2012 22:59:22 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2E98D21F86AD for ; Thu, 6 Sep 2012 22:59:22 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2759145vbb.31 for ; Thu, 06 Sep 2012 22:59:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=3SC5z8b2KSrCpG9QSCmnL1cuI7PZgs2HoYo/+KBbCDQ=; b=VYqat6IXrkWJBpbbLFHvHgSGTWIo1YvXwBAEtuet5pPMdIHgN2ynRjzkodf9eAFBJ5 IbpF71A9IPlq0ct4G3du2QzDKyiseScUiJstaBJmZ2iaO791q4j6Psa8SSQGJYAz/nmD EMMOpWJPMfi7WnYaZSlKGlO3dVk74AIadcF2/GqbDwlmSzWBdAIGpZccxQdsgXlQVsgz jxeLR3wN4q0RnWYIaJFagAbKSiEqgwvy0215mhTXui6Q90i5/wJFwlfoNs3oO9M1Ux0g AgvpzLNaYizt6q04vPD/NTxvBLzLzBhYfOBQSxGBnwy68ayUIVgxVmez0HwZ914A9H6z t2Nw== MIME-Version: 1.0 Received: by 10.52.92.169 with SMTP id cn9mr4802028vdb.72.1346997561583; Thu, 06 Sep 2012 22:59:21 -0700 (PDT) Received: by 10.58.114.231 with HTTP; Thu, 6 Sep 2012 22:59:21 -0700 (PDT) In-Reply-To: References: Date: Fri, 7 Sep 2012 13:59:21 +0800 Message-ID: From: GangChen To: Maoke Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 05:59:23 -0000 Hello Maoke, 2012/9/7, Maoke : > dear Remi, > > as we are talking about a BCP, if 464xlat doc states BIH is an > indispensible part of the standard, our customers will require us to > definitely provide such a function Different understanding. As we discussed and claimed, BIH is a *complementary part* to 464xlat. That is only can make 464xlat better and no harm. With the table of "Traffic Treatment Scenarios" in section 9.2, it makes the applicability even more clear. Customers could have their choice depending on their specific situation. Don't do the definitive decision on behalf of your customer. > or such an option rather than any other > alternatives in the service suite. i doubt this is the common > floor the working group is on. The other alternatives you raised in other mail are identified as not true. I'm still waiting your reply, which is better to be point-by-point. > (response to Gang's comment also...) > > yes, i did reviewed all the thread you linked to me. thanks again for the > links. my observation is the authors accepted that phrase in order to mov= e > on. It is not our job to judge author decision. I believe their prestigious knowledges. What I know is that is wg feedback. >i fully understand that but we are obliged to share our understanding > too, maybe late (if so i apologize). if we see something but not say > out, we were irresponsible to the community. I fully agree the more arguments create the good document. However, groundless arguments can't help anything but waste our time. The discussion on BIH was already taken several months. If you haven't concrete argument and only insist on the claim, we will be here for another month while that would delay the work. Please to identify what the harm you see to object. . > please also pay attention to the statement of the movitation in the > Introduction of the 464xlat: > > The 464XLAT architecture only supports IPv4 in the > client server model, where the server has a global IPv4 address. > you argued that an IPv4 address is needed for the IPv6-translatable serve= r > address, it is true and here you are, The sentence doesn't say the global IPv4 address SHOULD be a part of IPv6-translatable server address. That is a IPv4 server staying on the IPv4 area. It=92s not what we are talking about. > and, as Wojciech mentioned, CLAT has > supported that by default. we have no business with the IPv6-only server > without holding a global IPv4 address, in the problem scope! Didn't you notice the woj comments of *what it doesn't give is 4-to-6-internet , which BIH can arguably provide* BTW, the statement of *The stateless NAT64 (4->6) characteristic of the clat gives 4-to-6 communication* is strictly not true. There is a condition that it's desirable to insert a global IPv4 addree. Otherwise, the feasibility should be discussed case by case. Only state the sentence without the condition is a biased argument. And I guess 464xlat situation can't be fall into the applicable scope. > on the other hand, *464xlat is indended to support IPv4-only application*= - > this of your understanding, MHO, is biased from the above 464xlat problem > statement No. it's identified in the draft in several places. Please search the key of *applications*. You would get a good answer I guess. (it is also quite confusing me because, AFAIK, "BIH is indended > to support IPv4-only applications" :P :P :P). Don't know what your confusion is. That is the same goal lets 464xlat&BIH could cooperate with each others. > > therefore, IMHO, citing BIH is contradictory to the 464xlat problem > statement, making the document itself inconsistent. I don't think that is a convinced conclusion. Please provide valid technical justifications. BRs Gang > - maoke > > 2012/9/7 R=E9mi Despr=E9s > >> >> Le 2012-09-06 =E0 18:39, Wojciech Dec a =E9crit : >> >> >> >> On 6 September 2012 18:22, GangChen wrote: >> >>> 2012/9/6, Lorenzo Colitti : >>> > On Thu, Sep 6, 2012 at 11:52 PM, GangChen wrote: >>> > >>> >> I didn't fully get your point. 464xlat is not a fridge actually :) >>> >> Again, please directly identify your technical points/concerns. >>> >> >>> > >>> > I think the comment was intended to mean: >>> > >>> > 2. BIH is not necessary for the operation of 464xlat, so it doesn't >>> have to >>> > be in the draft. >>> >>> 464xlat is intended to support IPv4-only capable application. >>> There is no limitation CLAT only can communicate with IPv4 server in th= e >>> wild. >>> Missing BIH is incomplete when communication with IPv6 is needed. >>> >> >> Although, as I have said, don't see the reference to BIH as absolutely >> necessary in the 4X4XLAT draft, I think that not only it makes no harm >> but >> also is useful to clarify how IPv4-only applications can communicate, >> with >> standard-track RFCs, in IPv6-only environments . >> I therefore don't understand reasons to insist that the >> existing complementarity of 464XLAT and BIH in this respect should no >> longer be mentioned. >> >> At a time when there are still discussions on functional aspects of >> 464XLAT, this particular discussion is IMHO a waste of time. >> Preferred approach: keep the sentence, and proceed. >> >> FWIW. >> >> RD >> >> >> >> >> Strictly speaking that is not true. The stateless NAT64 (4->6) >> characteristic of the clat gives 4-to-6 communication by default. What >> it >> doesn't give is 4-to-6-internet , which BIH can arguably provide, but it >> is >> certainly an additional option, rather than the core of what the xlat >> solution is primarily intended for. >> >> -Woj. >> >>> >>> >>> > 3. The scenario that BIH is intended to solve is further in the futur= e >>> and >>> > we do not yet have as much operational experience with it. So it >>> > should >>> not >>> > go into a BCP for 464xlat, which is a different transition mechanism. >>> >>> RFC6535 does exist on standard track. It's already approved it got >>> significant community reviews and appears to enjoy enough community >>> interest according to RFC2026. It's qualified to go into a BCP. More >>> operational experiences are always needed for any technologies at any >>> time. It should not be an obstacle to be adopted in a proper scenario. >>> 464XLAT purpose is to facilitate deployments and use of IPv6-only >>> networks. It does this better if combined there is BIH in CLAT nodes. >>> It's indeed in the same building block >>> >>> > 4. Saying "you can use BIH with 464xlat" is not very useful by itself >>> > because 464xlat doesn't work together with BIH in any special way. >>> >>> Supporting IPv4-only application is the same goal, under which 464xlat >>> surely should work with BIH. >>> >>> > It only >>> > provides connectivity. Yes, you can do BIH with 464xlat. But you can >>> also >>> > do it with DS-Lite, or 6rd, or native dual-stack. >>> >>> You can't. The requirements doing encapsulation and translation are >>> likely exclusive. I don't think DS-lite and BIH could stay together >>> from an operational point of view. 6rd even has reversed scenario, >>> i.e. 646. Native dual-stack has both IPv4/IPv6 connection, but >>> scenario of BIH is targeting to IPv6-only approach. As you indicated >>> it's doable for BIH with 464xlat and the draft already identify the >>> possibilities according to WG feedback, I don't understand why not >>> intentionally allow them to be complementary. >>> >>> >>> > Saying "you can use BIH >>> > with 464xlat" is like saying "you can run HTTP over TCP": it's true, >>> but it >>> > doesn't need to go into the TCP RFC. >>> >>> Isn't our goal to identify the BCP? TCP is a standard, not BCP. >>> >>> BRs >>> >>> Gang >>> >>> > For what it's worth, I agree. >>> > >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> >> > From lorenzo@google.com Thu Sep 6 23:14:14 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D914121E8084 for ; Thu, 6 Sep 2012 23:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.89 X-Spam-Level: X-Spam-Status: No, score=-102.89 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5De3G1kINbG0 for ; Thu, 6 Sep 2012 23:14:14 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2086E21E8082 for ; Thu, 6 Sep 2012 23:14:14 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so4332723obb.31 for ; Thu, 06 Sep 2012 23:14:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=4tWaYrZRfrvunjV5BBqunOpPTguX0EMwvMjxsupDu/k=; b=bcT9N90Vizrz0wCWldgSKIdu9XocuCC0sD746hqyV5y5fcIc4wGW0BngaT5s52FHOG QomnxwVthvAJnlBbwh+fBekdbhQPFxWiRq6Lq5I6tDiHF6r7vsyVLUkzYMsITa2n24OH alPNrcnhWGwgNJnSH/f7yQAr+a7/Kn7qq+x/HbckYUmQhYGN2PAjEbk9veCAFTpUKb8g lQ4sETIfCdwpMvNX9wOMLx68282pLPX/fg0X5LVB22to6RmnI2sV94TyfmhLBeEW/Nl/ a5tFW0fEqQfp/jqoCFr1TS4CdMV4VBO9e+xRnjeZToc2pTjsf/iz7dYoVrfKNy9Tgr5t fF8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=4tWaYrZRfrvunjV5BBqunOpPTguX0EMwvMjxsupDu/k=; b=MU3JVarERmPYbWdyYY3qzLN/iil0budWSygpQql74PZbbtjff0wCWpoazl0xOgLyCJ mBQVjOmAfHSRLCZ4l7bMnkJ34UHKNo655HU5tMeV2Fx4beH1K1QOEhP/duq8fY7gMrjL plv+14HqGeHS41onRrHH+TQCwt6cNjfTumAz8E0UJitzFbnQDne71t77CxxDZnBlM+mJ jfAekT7fvMC1z8IClIKDSskzkSSqc55wqpxUIKmD20h18Ql8AVYonOS2JXl/sbYE8H6r SYbDyhTQgmVkXFWUkKFS2EIGPBtLlcWQsJYo6zzs+oAPQ07k6gEOk3bLQtUgio2V5/dy WqxA== Received: by 10.60.5.229 with SMTP id v5mr4466639oev.70.1346998453517; Thu, 06 Sep 2012 23:14:13 -0700 (PDT) Received: by 10.60.5.229 with SMTP id v5mr4466633oev.70.1346998453376; Thu, 06 Sep 2012 23:14:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.187.8 with HTTP; Thu, 6 Sep 2012 23:13:53 -0700 (PDT) In-Reply-To: References: From: Lorenzo Colitti Date: Fri, 7 Sep 2012 15:13:53 +0900 Message-ID: To: GangChen Content-Type: multipart/alternative; boundary=e89a8f64315453973004c91684c6 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkQeourQcyVe8eVV1rlIWn7DM0xB70sqimZdHYVa/M/QrhhF/yCzufvkw2GFH4uZotBsLxJCQQAzVXX6oUETQ+zcSldasR2PzfhBDxHhLQCJ19qxFsJa8UXODuH3S3YQPZJk4wnHv8BG/+TNXTkgx1YwHJU+jywT+atFg7YYJGJ2r7C2hKNs0kZ8DqHoPrk9lhr/1U3 Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 06:14:15 -0000 --e89a8f64315453973004c91684c6 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Sep 7, 2012 at 1:22 AM, GangChen wrote: > > 2. BIH is not necessary for the operation of 464xlat, so it doesn't have > to > > be in the draft. > > 464xlat is intended to support IPv4-only capable application. > There is no limitation CLAT only can communicate with IPv4 server in the > wild. > Missing BIH is incomplete when communication with IPv6 is needed. > CLAT also cannot communicate with DECNET. Should the 464xlat BCP mention that CLAT can communicate with DECNET networks through a DECNET proxy? I don't think so. And before you say "CLAT is for providing IPv4 over IPv6, and so is BIH, so BIH is in scope" - no, CLAT does not provide IPv4 over IPv6, it supports IPv4 over IPv6 for a narrow subset of applications. Yes, it doesn't support IPv6-only servers... but it also doesn't support raw IP packets, incoming IPv4 connections, or IP options. Compared to those limitations, "doesn't support IPv6-only servers" is franl > 4. Saying "you can use BIH with 464xlat" is not very useful by itself > > because 464xlat doesn't work together with BIH in any special way. > > Supporting IPv4-only application is the same goal, under which 464xlat > surely should work with BIH. > The goal of 464xlat is to support IPv4-only clients. I would say that supporting IPv6-only servers is out of scope of this BCP. Yes, you can do it with BIH if you want. But you can also do it with transparent proxies, ALGs, and so on. This document is not qualified to make the call on which of these mechanisms to use. > > Saying "you can use BIH > > with 464xlat" is like saying "you can run HTTP over TCP": it's true, but > it > > doesn't need to go into the TCP RFC. > > Isn't our goal to identify the BCP? TCP is a standard, not BCP. > This is a BCP for running IPv4-only client applications on an IPv6-only network without encapsulation. This is not a BCP on how IPv4-only clients should communicate with IPv6-only servers. Adding four lines lines to this document that say "you can use BIH if you want" does not make it one. --e89a8f64315453973004c91684c6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Sep 7, 2012 at 1:22 AM, GangChen <phdgang@gmail.com>= wrote:
> 2. BIH is not necessary for the operation of 464xlat= , so it doesn't have to
> be in the draft.

464xlat is intended to support IPv4-only capable application.
There is no limitation CLAT only can communicate with IPv4 server in the wi= ld.
Missing BIH is incomplete when communication with IPv6 is needed.

CLAT also cannot communicate with DECNET. Should= the 464xlat BCP mention that CLAT can communicate with DECNET networks thr= ough a DECNET proxy? I don't think so.

And before you say "CLAT is for providing IPv4 ove= r IPv6, and so is BIH, so BIH is in scope" - no, CLAT does not provide= IPv4 over IPv6, it supports IPv4 over IPv6 for a narrow subset of applicat= ions.=A0Yes, it doesn't support IPv6-only servers... but it also doesn&= #39;t=A0support raw IP packets, incoming IPv4 connections, or IP options. C= ompared to those limitations, "doesn't support IPv6-only servers&q= uot; is franl

> 4. Say= ing "you can use BIH with 464xlat" is not very useful by itself > because 464xlat doesn't work together with BIH in any special way.=

Supporting IPv4-only application is the same goal, under which 464xla= t
surely should work with BIH.

The goal o= f 464xlat is to support IPv4-only clients. I would say that supporting IPv6= -only servers is out of scope of this BCP. Yes, you can do it with BIH if y= ou want. But you can also do it with transparent proxies, ALGs, and so on. = This document is not qualified to make the call on which of these mechanism= s to use.
=A0
> Saying "you can use BIH
> with 464xlat" is like saying "you can run HTTP over TCP"= ;: it's true, but it
> doesn't need to go into the TCP RFC.

Isn't our goal to identify the BCP? TCP is a standard, not BCP.

This is a BCP for running IPv4-only clie= nt applications on an IPv6-only network without encapsulation. This is not = a BCP on how IPv4-only clients should communicate with IPv6-only servers. A= dding four lines lines to this document that say "you can use BIH if y= ou want" does not make it one.
--e89a8f64315453973004c91684c6-- From lorenzo@google.com Thu Sep 6 23:28:10 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5773C21E8034 for ; Thu, 6 Sep 2012 23:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.901 X-Spam-Level: X-Spam-Status: No, score=-102.901 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2W8T0h7Nhxmk for ; Thu, 6 Sep 2012 23:28:09 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id ADE3511E808D for ; Thu, 6 Sep 2012 23:28:09 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so4349580obb.31 for ; Thu, 06 Sep 2012 23:28:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=cH6ZiWBoaXoudL8WhRhOEdGQY4aGYvwEiKVu03YSCDg=; b=pTsKtQoMlHB5MleybeiMZ70N7p7LkXdBpmMnt7dTJt/16cD+GLufb6gMPULA2TtHR/ RJ5uc8VG3BItR9+GuTPJlh9QR0aHmcDmUumxeEqkWfJNkv84yMmDHo3CM+5BTAd7mWBP dtRZpRcqLiPF5c+Ct0FJ06qs9qiMLaA32BMyl+u6JiqMkskhvbCofaN6S4FCOUEq5K4+ uqoVD36BS4glEcEWkN9akH/YD4vrmKWfbrInP98JExiFp3RB+gsUYXy19SyztTuZVeEa tb+GGtXS7xobz+JvmXOLNzZbKbNigQaAHXSBhUZMKB2LYjUUQFt80DAEOI1E4IazcpUE WUMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=cH6ZiWBoaXoudL8WhRhOEdGQY4aGYvwEiKVu03YSCDg=; b=BdO4AbudD7DhwyqMXNMwoMRktQhG34qywuGIzMZY1ovSmPQxwdW6xbAkNGYhqk9x7k w58EA6UnEEfH6z6Sq4/gOS4qzj5wfvOxXRYtMeobP4+Nro1AC0lla2ReiNwL/eNxZZJp bzwo7w8ORaTAcwLPsicDo/4N6w0CIu8ZijEoXgI586XxuKzrXO0xWn7d/d3s8pDhPQe/ QqUk3QB+5A636WEZ8GMF/P/ju+5eP/nJlfPLhcuEQ3hO/gNokYmA+BndGNgPNt0/0m1s SKX6PKXKTCt7M905iAmpusWMfgcf/QMks/UtxEtr/nfKqhtl3RR+kiHrCNtVpuT/TfMx lOOA== Received: by 10.182.1.72 with SMTP id 8mr4520160obk.61.1346999289240; Thu, 06 Sep 2012 23:28:09 -0700 (PDT) Received: by 10.182.1.72 with SMTP id 8mr4520154obk.61.1346999289141; Thu, 06 Sep 2012 23:28:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.187.8 with HTTP; Thu, 6 Sep 2012 23:27:47 -0700 (PDT) In-Reply-To: References: From: Lorenzo Colitti Date: Fri, 7 Sep 2012 15:27:47 +0900 Message-ID: To: GangChen Content-Type: multipart/alternative; boundary=f46d04462fe024596904c916b677 X-System-Of-Record: true X-Gm-Message-State: ALoCoQl8PhBFHi1lo7LN+WJw9UE0pHCsfUQR8lMPvIq02Om/yXLlVfmAGKmyw+ZIs9H4VKqnQw+39mjp/qXL4ZDiLQMvj/9aAdVLJF71qfcosAs8O8wSyNHA+IMa7kGylyQuEe29x7UGGjA72sMmL1+Meq+NbN9LKOxlMZYQovQhPLpuQhS3gPWMGoa7oqa0SmZ5A6Kgbhx1 Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 06:28:10 -0000 --f46d04462fe024596904c916b677 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Sep 7, 2012 at 2:59 PM, GangChen wrote: > If you haven't concrete argument and only insist on the claim, > we will be here for another month while that would delay the work. > Please to identify what the harm you see to object. . Ok, here's a concrete problem, then: the draft contradicts itself. Section 1 says: By combining 464XLAT with BIH [RFC6535], it is also possible to provide single IPv4 to IPv6 translation service, which will be needed in the future case of IPv6-only servers [...] But Section 2 says: This BCP only applies when the following two criteria are present: [...] 2. There are IPv4-only applications or hosts that must communicate across the IPv6-only network to reach the IPv4 Internet. So, one section mentions IPv6-only servers, and another section explicitly says "the IPv4 Internet" where by definition, there cannot be IPv6-only servers. So one section talks about IPv6-only servers, and another section of the same document declares them to be out of scope. In order to resolve the contradiction, either you modify Section 2 to expand the scope to include IPv6-only servers, or you modify Section 1 to remove the mention to BIH. Given the two choices I think it's better to remove BIH, because as soon as IPv6-only servers are in scope, this document will suddenly become a BCP on "how IPv4-only nodes should communicate with IPv6-only servers", and I don't think we have consensus that yet. --f46d04462fe024596904c916b677 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Sep 7, 2012 at 2:59 PM, GangChen <phdgang@gmail.com>= wrote:
If you haven't concrete argument and only insist on the claim,
we will be here for another month while that would delay the work.
Please to identify what the harm you see to object. =A0.
<= br>
Ok, here's a concrete problem, then: the draft contradict= s itself.

Section 1 says:

=A0 =A0By combining 464XLAT with BIH [RFC6535], it is also possible to=
=A0 =A0provide single IPv4 to IPv6 translation service, which wi= ll be needed
=A0 =A0in the future case of IPv6-only servers [...]=

But Section 2 says:=A0

= =A0 =A0This BCP only applies when the following two criteria are present:
[...]
=A0 =A02. =A0There are IPv4-only applic= ations or hosts that must communicate
=A0 =A0 =A0 =A0across the IPv6-only network to reach the IPv4 Internet= .

So, one section mentions IPv6-only servers= , and another section explicitly says "the IPv4 Internet" where b= y definition, there cannot be IPv6-only servers. So one section talks about= IPv6-only servers, and another section of the same document declares them = to be out of scope.

In order to resolve the contradiction, either you modif= y Section 2 to expand the scope to include IPv6-only servers, or you modify= Section 1 to remove the mention to BIH. Given the two choices I think it&#= 39;s better to remove BIH, because as soon as IPv6-only servers are in scop= e, this document will suddenly become a BCP on "how IPv4-only nodes sh= ould communicate with IPv6-only servers", and I don't think we hav= e consensus that yet.
--f46d04462fe024596904c916b677-- From fibrib@gmail.com Thu Sep 6 23:29:57 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1253D21E8082 for ; Thu, 6 Sep 2012 23:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.772 X-Spam-Level: X-Spam-Status: No, score=-2.772 tagged_above=-999 required=5 tests=[AWL=0.226, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uufssKx1kl16 for ; Thu, 6 Sep 2012 23:29:55 -0700 (PDT) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 121DC21E805D for ; Thu, 6 Sep 2012 23:29:54 -0700 (PDT) Received: by wgbfm10 with SMTP id fm10so162892wgb.1 for ; Thu, 06 Sep 2012 23:29:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oczqxqhEVAhi9mDNxMVPkzqrz1vbtsx3CTxvPTF2T9k=; b=GHs4P1FndIbs3KCovzFOwuWNYxFatJkByG1xUdM0TyVeQv8+X0iIPma9R9EqJPFk+4 G93+WHjn9tSzzICU2SYqsLkipyyUSniqJuzDUqpMeby/bBW/o4JOx+EJm109KpAC8GoE Ox2xa2crKd12RpR+YwSLn7ehTk0pZImOTQKZXXlBGmNCVqTO109Oykp+XKmQ9tF78jWY KMJ9pFIvxBebLa9UnlDwAyUl0ko/KMiki0Emz+TCE1bCi/2U76kedenKms5EljAP22E9 hZHUP0kbg26yaY8lPBLdYQemog5D4W0aCj79lz2VUmgoPuflJgg/msWaPaH+nMaxO+nG HscQ== MIME-Version: 1.0 Received: by 10.216.162.141 with SMTP id y13mr2561204wek.14.1346999394078; Thu, 06 Sep 2012 23:29:54 -0700 (PDT) Received: by 10.223.37.78 with HTTP; Thu, 6 Sep 2012 23:29:53 -0700 (PDT) In-Reply-To: References: Date: Fri, 7 Sep 2012 15:29:53 +0900 Message-ID: From: Maoke To: GangChen Content-Type: multipart/alternative; boundary=0016e65b5db265922904c916bc7a Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 06:29:57 -0000 --0016e65b5db265922904c916bc7a Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable this item is what you are waiting for my reply to, right? see inline. 2012/9/6 GangChen > 2012/9/6, Maoke : > > hi Gang, > > > > thanks for the links! > > > > 1. i don't think an early conclusion of the authors cannot be objected > and > > thought over again, before the last call is closed. > > Sure. If you do think several-months lasted discussion doesn't > convince and would like to boil the ocean, we could re-open it. > But please read the conversion happened before on the list to ensure > new discussion is not backward. > > > 2. i don't think it is a loss to state out of scope (or not to mention > that > > at all) for IPv4-only app access to IPv6-only server. > > (*)Those arguments were discussed in the thread of "A way forward for > 464XLAT - using BIH". > The loss and gain have been well identified. The point is adding BIH > only can be complementary to 464xlat scenario, no harm. > If you have further point, please identify. > putting a microwave oven on the top of a fridge has no harm at all, too. my point is simple: if 464xlat can solve the problem it identifies, then things are enough. we don't need anything more, even the "anything" has been standard, unless we change the scope of the problem. > > > > this could be > > achieved by simply configuring the IPv6-only server with an RFC6052 > > IPv4-translatable address and relying CLAT RFC6145 translation, > > 1) The IPv4-Embedded IPv6 address on CLAT is inserted with IPv4 > private address. When the two IPv4-embedded IPv6 addresses with conflicted IPv4 address > talk to an IPv4-translatable IPv6 address, it would be failed since > IPv6-only server is confused that outgoing packages should send to > which CLAT. > not very understand. conflicted IPv4 address either causes trouble or running as anycast. what's the scope? > 2) IPv6-only server with IPv4-translatable address would cause one > public IPv4 address. > Most people do IPv6 because IPv4 is limited, so doing this way does > not really buy you anything. > i (the server) may keep early customers from native IPv4 having access without knowing that i have changed my protocol stack and meanwhile increase my native IPv6-only customers. > 3) There no RFC stated the solution what you called as RFC6052+RFC6145; > copied from RFC6145: Readers of this document are expected to have read and understood the framework described in [RFC6144 ]. Implementations of this IPv4/IPv6 translation specification MUST also support the address translation algorithms in [RFC6052 ]. Implementations MAY also support stateful translation [RFC6146 ]. RFC6052 + RFC6145 is a MUST and both are standards. and RFC6219 gave you an example of using the both in the practice. > whether that is a doable way need to be further justified. But BIH is > a standard track > > > > or by a > > NAT64 located anywhere between the IPv4 app and the IPv6 domain > implemented > > I don't get it. If there is NAT64, there is nothing to do with the > scenario you are talking about. > > > > > in anyway not necessarily the socket layer solution, even though BIH do= es > > possibly work, by a proxy (ALG), etc. > > Please note RFC6535 has two flavors, i.e. header translation and > socket translation. It=92s really not necessarily the socket layer > solution. > > > 3. i don't think the author has tested the BIH with CLAT for an IPv6-on= ly > > server, at least i have not seen any discussion/report from the authors > or > > WG members about the test. > > (**)I guess you will see the report soon, because we are coding that righ= t > now. > At this stage, what I can tell is most parts are same in the combining > code. > > > to my understanding, the BIH/CLAT work here is > > not yet practiced. why we need/should put a stuff not yet practiced int= o > a > > BCP?? > > Please don't do the arbitrary objection even you didn't evaluate it. > It is a strange logic. > "I don't do that. I even don't know that. So I think that is not > practiced." > That is an unfair argument. > > > (NOTE, the test result from you only illustrates that BIH itself is > > working, not the BIH/464xlat with IPv4-only app access to IPv6-only > server. > > the tested applications, skype, MSN, etc. are none of business of the > > so-called IPv6-only servers). > > Please see the (**) and carefully read my report > http://www.ietf.org/mail-archive/web/v6ops/current/msg12631.html > The shared experiences are in 464 contexts. > With 464xlat, we could easily do *combining 464XLAT with BIH*. > It's of significance. > i think i don't misunderstand anything about your report. i read through the mail and also the doc of the testing. it is good but i think it said, BIH is working, no matter there is 464xlat or not. please identify the benefit of having BIH working together with 464xlat, i.e., what we gain through the combination rather than BIH and 464xlat themselves? more comprehensively, if 464xlat provides A, BIH provides B, and 464xlat + BIH provides A + B but nothing else, then i insist that it is not necessary to cite BIH in 464xlat at all. - maoke > > > 4. i was even confused by the text "By combining 464XLAT with BIH > > [RFC6535], it is also possible to provide single IPv4/IPv6 translation > > service" itself. BIH has done the single IPv4/IPv6 translation right? > what > > is the significance of such a "combination"? what is the add-on? > > Same comment with (*). If you have concrete point, please identify. > Ambiguous arguments and arbitrary objections only can waste our energy > and time. It doesn't help the document imho. > > > integrating the compressor, condenser, expansion valve, evaporator into= a > > fridge is an innovation (as the authors did for the 464xlat) but we > cannot > > call a "fridge + microwave oven put on the top of the fridge" a new > > "architecture" of better practice. > > I didn't fully get your point. 464xlat is not a fridge actually :) > Again, please directly identify your technical points/concerns. > > > BRs > > Gang > > > > > - maoke > > > > 2012/9/6 GangChen > > > >> 2012/9/6, Maoke : > >> > another objection is, Section 9 states "another, > >> > if combined with BIH [RFC6535 >], > >> is > >> > a IPv4 -> IPv6 translation for > >> > reaching IPv6-only servers from IPv4-only clients that can not > >> > support IPv6. " > >> > > >> > it sounds to me that 464xlat does suggest to apply BIH, as part of t= he > >> best > >> > practice, for IPv4 client reaching IPv6-only servers. to my > >> understanding, > >> > there could be several alternative ways to achieve that, why we shou= ld > >> > be > >> > bounded with BIH? > >> > > >> > sorry i didn't catch the discussion on this issue before. > >> > >> There was a quite long discussion, > >> since you didn't follow that, I list the links below for your > >> convenience. > >> > >> "A way forward for 464XLAT", started with > >> http://www.ietf.org/mail-archive/web/v6ops/current/msg12521.html > >> "A way forward for 464XLAT - using BIH", started with > >> http://www.ietf.org/mail-archive/web/v6ops/current/msg12631.html > >> "I-D Action: draft-ietf-v6ops-464xlat-02.txt" started with > >> http://www.ietf.org/mail-archive/web/v6ops/current/msg12628.html > >> " [v6ops] draft-ietf-v6ops-464xlat - which status?"started with > >> http://www.ietf.org/mail-archive/web/v6ops/current/msg13035.html > >> .... > >> > >> As Cameron indicated *The conclusion was that the 464XLAT is more > >> complete by making a reference to BIH scenario.* > >> > >> BRs > >> > >> Gang > >> > >> > >> > > >> > 2012/8/22 Fred Baker (fred) > >> > > >> >> I should note that the current thread has a subject line reading > >> -06.txt, > >> >> but the current version is -07.txt. You may find the diffs (fairly > >> >> extensive) at > >> >> > >> >> http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-464xlat-07.tx= t > >> >> > >> >> > >> >> On Aug 21, 2012, at 8:45 AM, Fred Baker (fred) wrote: > >> >> > >> >> > This is to open a two week Working Group last Call on > >> >> > > >> >> > http://tools.ietf.org/html/draft-ietf-v6ops-464xlat > >> >> > "464XLAT: Combination of Stateful and Stateless Translation", > >> Masataka > >> >> > Mawatari, Masanobu Kawashima, Cameron Byrne, 19-Aug-12 > >> >> > > >> >> > Please read it now. We are interested in, among other things, > >> technical > >> >> commentary on the draft and the working group's perception on its > >> >> usefulness to its target audience. > >> >> > _______________________________________________ > >> >> > v6ops mailing list > >> >> > v6ops@ietf.org > >> >> > https://www.ietf.org/mailman/listinfo/v6ops > >> >> > >> >> ---------------------------------------------------- > >> >> The ignorance of how to use new knowledge stockpiles exponentially. > >> >> - Marshall McLuhan > >> >> > >> >> _______________________________________________ > >> >> v6ops mailing list > >> >> v6ops@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/v6ops > >> >> > >> > > >> > > > --0016e65b5db265922904c916bc7a Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable this item is what you are waiting for my reply to, right? see inline.
<= br>
2012/9/6 GangChen <phdgang@gmail.com>=
2012/9/6, Maoke <fi= brib@gmail.com>:
> hi Gang,
>
> thanks for the links!
>
> 1. i don't think an early conclusion of the authors cannot be obje= cted and
> thought over again, before the last call is closed.

Sure. If you do think several-months lasted discussion doesn't convince and would like to boil the ocean, we could re-open it.
But please read the conversion happened before on the list to ensure
new discussion is not backward.

> 2. i don't think it is a loss to state out of scope (or not to men= tion that
> at all) for IPv4-only app access to IPv6-only server.

(*)Those arguments were discussed in the thread of "A way forwar= d for
464XLAT - using BIH".
The loss and gain have been well identified. The point is adding BIH
only can be complementary to 464xlat scenario, no harm.
If you have further point, please identify.
=A0
<= div>putting a microwave oven on the top of a fridge has no harm at all, too= . my point is simple: if 464xlat can solve the problem it identifies, then = things are enough. we don't need anything more, even the "anything= " has been standard, unless we change the scope of the problem.
=A0


> this could be
> achieved by simply configuring the IPv6-only server with an RFC6052 > IPv4-translatable address and relying CLAT RFC6145 translation,

1) The IPv4-Embedded IPv6 address on CLAT is inserted with IPv4
private address.=A0
When the two IPv4-embedded IPv6 addresses with conflicted IPv4 address
talk to an IPv4-translatable IPv6 address, it would be failed since
IPv6-only server is confused that outgoing packages should send to
which CLAT.
=A0
not very understand. conflic= ted IPv4 address either causes trouble or running as anycast. what's th= e scope?
=A0
2) IPv6-only server with IPv4-translatable address would cause one
public IPv4 address.
Most people do IPv6 because IPv4 is limited, so doing this way does
not really buy you anything.
=A0
i (the serv= er)=A0may keep early customers from native IPv4 having access without knowi= ng that i have=A0changed my protocol stack=A0and meanwhile increase my nati= ve IPv6-only customers.
=A0
3) There no RFC stated the solution what you called as RFC6052+RFC6145;
=
=A0
copied from RFC6145:
=A0
=A0=A0=A0Readers of this document are expected to have read and understoo= d the
=A0=A0 framework described in [RFC6144].= =A0 Implementations of this IPv4/IPv6
=A0=A0 translation specification M= UST also support the address translation
=A0=A0 algorithms in [RFC6052].=A0 I= mplementations MAY also support stateful
=A0=A0 translation [R= FC6146].
RFC6052 + RFC6145 is a MUST and both are standards.
= =A0
and RFC6219 gave you an example of using the both in the prac= tice.
=A0
whether that is a doable way need to be further justified. =A0But BIH is a standard track
=A0


> or by a
> NAT64 located anywhere between the IPv4 app and the IPv6 domain implem= ented

I don't get it. If there is NAT64, there is nothing to do with th= e
scenario you are talking about.



> in anyway not necessarily the socket layer solution, even though BIH d= oes
> possibly work, by a proxy (ALG), etc.

Please note RFC6535 has two flavors, i.e. header translation and
socket translation. It=92s really not necessarily the socket layer
solution.

> 3. i don't think the author has tested the BIH with CLAT for an IP= v6-only
> server, at least i have not seen any discussion/report from the author= s or
> WG members about the test.

(**)I guess you will see the report soon, because we are coding that = right now.
At this stage, what I can tell is most parts are same in the combining code= .

> to my understanding, the BIH/CLAT work here is
> not yet practiced. why we need/should put a stuff not yet practiced in= to a
> BCP??

Please don't do the arbitrary objection even you didn't evalu= ate it.
It is a strange logic.
"I don't do that. I even don't know that. So I think that is n= ot practiced."
That is an unfair argument.

> (NOTE, the test result from you only illustrates that BIH itself is > working, not the BIH/464xlat with IPv4-only app access to IPv6-only se= rver.
> the tested applications, skype, MSN, etc. are none of business of the<= br> > so-called IPv6-only servers).

Please see the (**) and carefully read my report
http://www.ietf.org/mail-archive/web/v6ops/current/msg1= 2631.html
The shared experiences are in 464 contexts.
With 464xlat, we could easily do *combining 464XLAT with BIH*.
It's of significance.
=A0
i think i don&= #39;t misunderstand anything about your report. i read through the mail and= also the doc of the testing. it is good but i think it said, BIH is workin= g, no matter there is 464xlat or not. please identify the benefit of having= BIH working together with 464xlat, i.e., what we gain through the combinat= ion rather than BIH and 464xlat themselves?
=A0
more comprehensively, if 464xlat provides A, BIH provide= s B, and 464xlat + BIH provides A + B but nothing else, then i insist that = it is not necessary to cite BIH in 464xlat at all.
=A0
- maoke
=A0

> 4. i was even confused by the text "By combining 464XLAT with BIH=
> [RFC6535], it is also possible to provide single IPv4/IPv6 translation=
> service" itself. BIH has done the single IPv4/IPv6 translation ri= ght? what
> is the significance of such a "combination"? what is the add= -on?

Same comment with (*). If you have concrete point, please identify. Ambiguous arguments and arbitrary objections only can waste our energy
and time. It doesn't help the document imho.

> integrating the compressor, condenser, expansion valve, evaporator int= o a
> fridge is an innovation (as the authors did for the 464xlat) but we ca= nnot
> call a "fridge + microwave oven put on the top of the fridge"= ; a new
> "architecture" of better practice.

I didn't fully get your point. 464xlat is not a fridge actually := )
Again, please directly identify your technical points/concerns.


BRs

Gang



> - maoke
>
> 2012/9/6 GangChen <phdgang@gma= il.com>
>
>> 2012/9/6, Maoke <fibrib@gma= il.com>:
>> > another objection is, Section 9 states "another,
>> > =A0 =A0if combined with BIH [RFC6535 <http://tools.ietf.org/html/rfc= 6535>],
>> is
>> > a IPv4 -> IPv6 translation for
>> > =A0 =A0reaching IPv6-only servers from IPv4-only clients that= can not
>> > =A0 =A0support IPv6. "
>> >
>> > it sounds to me that 464xlat does suggest to apply BIH, as pa= rt of the
>> best
>> > practice, for IPv4 client reaching IPv6-only servers. to my >> understanding,
>> > there could be several alternative ways to achieve that, why = we should
>> > be
>> > bounded with BIH?
>> >
>> > sorry i didn't catch the discussion on this issue before.=
>>
>> There was a quite long discussion,
>> since you didn't follow that, I list the links below for your<= br> >> convenience.
>>
>> "A way forward for 464XLAT", started with
>> http://www.ietf.org/mail-archive/web/v6ops/cur= rent/msg12521.html
>> "A way forward for 464XLAT - using BIH", started with >> http://www.ietf.org/mail-archive/web/v6ops/cur= rent/msg12631.html
>> "I-D Action: draft-ietf-v6ops-464xlat-02.txt" started wi= th
>> http://www.ietf.org/mail-archive/web/v6ops/cur= rent/msg12628.html
>> " [v6ops] draft-ietf-v6ops-464xlat - which status?"start= ed with
>> http://www.ietf.org/mail-archive/web/v6ops/cur= rent/msg13035.html
>> ....
>>
>> As Cameron indicated *The conclusion was that the 464XLAT is more<= br> >> complete by making a reference to BIH scenario.*
>>
>> BRs
>>
>> Gang
>>
>>
>> >
>> > 2012/8/22 Fred Baker (fred) <fred@cisco.com>
>> >
>> >> I should note that the current thread has a subject line = reading
>> -06.txt,
>> >> but the current version is -07.txt. You may find the diff= s (fairly
>> >> extensive) at
>> >>
>> >> http://tools.ietf.org/rfcdiff?url= 2=3Ddraft-ietf-v6ops-464xlat-07.txt
>> >>
>> >>
>> >> On Aug 21, 2012, at 8:45 AM, Fred Baker (fred) wrote:
>> >>
>> >> > This is to open a two week Working Group last Call o= n
>> >> >
>> >> > http://tools.ietf.org/html/draft-ietf-v6ops-4= 64xlat
>> >> > =A0"464XLAT: Combination of Stateful and Statel= ess Translation",
>> Masataka
>> >> > =A0Mawatari, Masanobu Kawashima, Cameron Byrne, 19-A= ug-12
>> >> >
>> >> > Please read it now. We are interested in, among othe= r things,
>> technical
>> >> commentary on the draft and the working group's perce= ption on its
>> >> usefulness to its target audience.
>> >> > _______________________________________________
>> >> > v6ops mailing list
>> >> > v6ops@ietf.org=
>> >> > https://www.ietf.org/mailman/listinfo/v6ops
>> >>
>> >> ----------------------------------------------------
>> >> The ignorance of how to use new knowledge stockpiles expo= nentially.
>> >> =A0 =A0- Marshall McLuhan
>> >>
>> >> _______________________________________________
>> >> v6ops mailing list
>> >> v6ops@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/v6ops
>> >>
>> >
>>
>

--0016e65b5db265922904c916bc7a-- From fibrib@gmail.com Thu Sep 6 23:54:52 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF3D21E8098 for ; Thu, 6 Sep 2012 23:54:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.1 X-Spam-Level: X-Spam-Status: No, score=-3.1 tagged_above=-999 required=5 tests=[AWL=0.498, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJzD0R04Noad for ; Thu, 6 Sep 2012 23:54:51 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0359021E8095 for ; Thu, 6 Sep 2012 23:54:50 -0700 (PDT) Received: by weyu54 with SMTP id u54so1670478wey.31 for ; Thu, 06 Sep 2012 23:54:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rWlDonV6FZnjh5JjM1n/uozld01/kTZZzqnrfrQuZdE=; b=krnOWxNuNl6XXhZkNURwNVkbUnL4jQZzT/KHpP9XqL+NuKk49mH1ITTLuGZuc7Ww70 +EvP1n5PQzu80mmRQScX4qvc/kFUH4YQ0CHlTeQD8h0jyHCOxiWSOEsIZCwvkBFb3Z0w Remy2CxcAy27KypePjrdI69/Cotbqju4eHuT/eb9d5kR8qjJT9VuW0zwyZDqjQDqFus/ WvbsG+EX+p9rzI58Xq/hcK1sTWvwydBeQT2usRnDCmWRQWJWfbZz6Mu7vnXygk4xq5Ib PSXQntu6kio1Y/sU13AiC2kjTQCM/DOflD6AugBGXNl5bunM24wD45AAIuYJqNvhgoVl TnaQ== MIME-Version: 1.0 Received: by 10.180.77.34 with SMTP id p2mr50978442wiw.0.1347000890148; Thu, 06 Sep 2012 23:54:50 -0700 (PDT) Received: by 10.223.37.78 with HTTP; Thu, 6 Sep 2012 23:54:49 -0700 (PDT) In-Reply-To: References: Date: Fri, 7 Sep 2012 15:54:49 +0900 Message-ID: From: Maoke To: Lorenzo Colitti Content-Type: multipart/alternative; boundary=f46d043c7dd491c6a404c917159c Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 06:54:52 -0000 --f46d043c7dd491c6a404c917159c Content-Type: text/plain; charset=ISO-8859-1 2012/9/7 Lorenzo Colitti > On Fri, Sep 7, 2012 at 2:59 PM, GangChen wrote: > >> If you haven't concrete argument and only insist on the claim, >> we will be here for another month while that would delay the work. >> Please to identify what the harm you see to object. . > > > Ok, here's a concrete problem, then: the draft contradicts itself. > > Section 1 says: > > By combining 464XLAT with BIH [RFC6535], it is also possible to > provide single IPv4 to IPv6 translation service, which will be needed > in the future case of IPv6-only servers [...] > > But Section 2 says: > > This BCP only applies when the following two criteria are present: > [...] > 2. There are IPv4-only applications or hosts that must communicate > across the IPv6-only network to reach the IPv4 Internet. > > So, one section mentions IPv6-only servers, and another section explicitly > says "the IPv4 Internet" where by definition, there cannot be IPv6-only > servers. So one section talks about IPv6-only servers, and another section > of the same document declares them to be out of scope. > > In order to resolve the contradiction, either you modify Section 2 to > expand the scope to include IPv6-only servers, or you modify Section 1 to > remove the mention to BIH. Given the two choices I think it's better to > remove BIH, because as soon as IPv6-only servers are in scope, this > document will suddenly become a BCP on "how IPv4-only nodes should > communicate with IPv6-only servers", and I don't think we have consensus > that yet. > +1 contradiction in text should be removed. we have had the consensus on the scope of the problem and the 464xlat itself is a best current practice regarding this specific problem. the complementary BIH is not necessary for this scope. - maoke --f46d043c7dd491c6a404c917159c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
=A0
2012/9/7 Lor= enzo Colitti <lorenzo@google.com>
On Fri, Sep 7, 2012 at 2:59 PM, GangChen <phdgang@gmail.= com> wrote:
If you haven't concrete argument and only insist on the claim,
we will be here for another month while that would delay the work.
Please to identify what the harm you see to object. =A0.
<= br>
Ok, here's a concrete problem, then: the draft cont= radicts itself.

Section 1 says:

=A0 =A0By combining 464XLAT with BIH [RFC6535], it is also possible to=
=A0 =A0provide single IPv4 to IPv6 translation service, wh= ich will be needed
=A0 =A0in the future case of IPv6-only servers= [...]

But Section 2 says:=A0

= =A0 =A0This BCP only applies when the following two criteria are present:
[...]
=A0 =A02. =A0There are IPv4-only applic= ations or hosts that must communicate
=A0 =A0 =A0 =A0across the IPv6-only network to reach the IPv4 Internet= .

So, one section mentions IPv6-on= ly servers, and another section explicitly says "the IPv4 Internet&quo= t; where by definition, there cannot be IPv6-only servers. So one section t= alks about IPv6-only servers, and another section of the same document decl= ares them to be out of scope.

In order to resolve the contradiction, either you modif= y Section 2 to expand the scope to include IPv6-only servers, or you modify= Section 1 to remove the mention to BIH. Given the two choices I think it&#= 39;s better to remove BIH, because as soon as IPv6-only servers are in scop= e, this document will suddenly become a BCP on "how IPv4-only nodes sh= ould communicate with IPv6-only servers", and I don't think we hav= e consensus that yet.

+1
=A0
contradiction in te= xt should be removed. we have had the consensus on the scope of the problem= and=A0the 464xlat itself=A0is a best current practice regarding this speci= fic problem. the complementary BIH is not necessary for this scope.
=A0
- maoke
--f46d043c7dd491c6a404c917159c-- From despres.remi@laposte.net Fri Sep 7 00:21:30 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4CC521F8567 for ; Fri, 7 Sep 2012 00:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.414 X-Spam-Level: X-Spam-Status: No, score=-0.414 tagged_above=-999 required=5 tests=[AWL=-1.065, BAYES_50=0.001, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2RIbGHoMQQjy for ; Fri, 7 Sep 2012 00:21:30 -0700 (PDT) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.19]) by ietfa.amsl.com (Postfix) with ESMTP id C576E21F8564 for ; Fri, 7 Sep 2012 00:21:29 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2318.sfr.fr (SMTP Server) with ESMTP id 98D4970000EB; Fri, 7 Sep 2012 09:21:28 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2318.sfr.fr (SMTP Server) with ESMTP id 652E970000E5; Fri, 7 Sep 2012 09:21:28 +0200 (CEST) X-SFR-UUID: 20120907072128414.652E970000E5@msfrf2318.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: Date: Fri, 7 Sep 2012 09:21:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <47F98720-3E3F-4920-A890-A5FD10843F0D@laposte.net> References: To: v6ops WG X-Mailer: Apple Mail (2.1084) Subject: [v6ops] 464XLAT and BIH X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 07:21:30 -0000 Le 2012-09-07 =E0 04:33, Maoke a =E9crit : ... > as we are talking about a BCP, if 464xlat doc states BIH is an = indispensible part of the standard, our customers will require us to = definitely provide such a function or such an option rather than any = other alternatives in the service suite. i doubt this is the common = floor the working group is on. ... 1. Stating that a combining 464XLAT with BIH is "possible" isn't stating = it is "indispensable". 2. Being part of a a "BCP" isn't being part of a "standard". 3. Authors initially wrote "It is also possible to provide single = IPv4/IPv6 translation service, which will be needed in the future case = of IPv6-only servers and peers to be reached from legacy IPv4-only = hosts." The added BIH reference better covers the original intent, by = just stating a fact useful to be known.=20 Confirmed stand: - At a time when there are still discussions on functional aspects of = 464XLAT, this particular discussion is IMHO a waste of time - Preferred approach: keep the sentence, and proceed. RD From brian.e.carpenter@gmail.com Fri Sep 7 00:26:32 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE4EB21F8604 for ; Fri, 7 Sep 2012 00:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.451 X-Spam-Level: X-Spam-Status: No, score=-101.451 tagged_above=-999 required=5 tests=[AWL=-0.360, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ELcGdiNWdy3 for ; Fri, 7 Sep 2012 00:26:31 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id A0A2321F85F3 for ; Fri, 7 Sep 2012 00:26:30 -0700 (PDT) Received: by eaai11 with SMTP id i11so833067eaa.31 for ; Fri, 07 Sep 2012 00:26:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=sKTyrYDczcirb+DJ0IhSC/FQp7PVAV5OT2P5HBtbpGY=; b=nheTgCGmNSmG0TeZBI2ucA74TlMf4MH1vluQfZWu6O0C/9qjB5/yfa6nLlrpIyghlV nDRysqT6+i+erNFhEdkjZyVwcnb1lAnFmiMaWQadILmRsSQrTFBYOp2VNTFN8TpTbN+A rxFEIClfAvoW9f8E61+cLwAdOjNRbywN19nhJci/LRc3MQT3zwBnA/pxLraDwI6h1sRb iOCkjPMD3GgZRQ4oSI4PwQMqGy9LI03G/68m8FYlTjzU4CPgXFzpgq+A50Yq0EzFarji oCWNeXBR1tI1GIi+WGh/z5iT/rXUcp6ZZk+oddZgzkc41VsmhRM6wLxKoK7zkrJsko1E WBSg== Received: by 10.14.178.72 with SMTP id e48mr835834eem.1.1347002789768; Fri, 07 Sep 2012 00:26:29 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-217-145.as13285.net. [2.102.217.145]) by mx.google.com with ESMTPS id e42sm10173608eem.8.2012.09.07.00.26.28 (version=SSLv3 cipher=OTHER); Fri, 07 Sep 2012 00:26:28 -0700 (PDT) Message-ID: <5049A1AF.9080202@gmail.com> Date: Fri, 07 Sep 2012 08:26:39 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Lorenzo Colitti References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 07:26:32 -0000 I have to say that I find any discussion of IPv6-only servers to be very premature. Who would seriously advise a content provider or application service provider to invest in IPv6-only services in the next few years? Let's keep the topic to how to support *legacy* clients reaching *legacy* services, which is a very real issue. Regards Brian On 07/09/2012 07:27, Lorenzo Colitti wrote: > On Fri, Sep 7, 2012 at 2:59 PM, GangChen wrote: > >> If you haven't concrete argument and only insist on the claim, >> we will be here for another month while that would delay the work. >> Please to identify what the harm you see to object. . > > > Ok, here's a concrete problem, then: the draft contradicts itself. > > Section 1 says: > > By combining 464XLAT with BIH [RFC6535], it is also possible to > provide single IPv4 to IPv6 translation service, which will be needed > in the future case of IPv6-only servers [...] > > But Section 2 says: > > This BCP only applies when the following two criteria are present: > [...] > 2. There are IPv4-only applications or hosts that must communicate > across the IPv6-only network to reach the IPv4 Internet. > > So, one section mentions IPv6-only servers, and another section explicitly > says "the IPv4 Internet" where by definition, there cannot be IPv6-only > servers. So one section talks about IPv6-only servers, and another section > of the same document declares them to be out of scope. > > In order to resolve the contradiction, either you modify Section 2 to > expand the scope to include IPv6-only servers, or you modify Section 1 to > remove the mention to BIH. Given the two choices I think it's better to > remove BIH, because as soon as IPv6-only servers are in scope, this > document will suddenly become a BCP on "how IPv4-only nodes should > communicate with IPv6-only servers", and I don't think we have consensus > that yet. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From lorenzo@google.com Fri Sep 7 00:36:50 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AED021F86AF for ; Fri, 7 Sep 2012 00:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.759 X-Spam-Level: X-Spam-Status: No, score=-102.759 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ZNRrZFO1XPZ for ; Fri, 7 Sep 2012 00:36:49 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id B3BEC21F86A8 for ; Fri, 7 Sep 2012 00:36:49 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so4437026obb.31 for ; Fri, 07 Sep 2012 00:36:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=BKwBCiVLBoUCe95xoYpBtU5PeYqJPUPORzqHYQCVa6s=; b=Pc8g+5YwFkPaSIB0J46QqZ6dAUWPhJbTFwy/SILi8EuFcqEKreOXX3YVlH3VM8YoRA gx+op8DZsb/pFD0HSnT8L/Fn7a1ssfbUT+siOtWZ2exEgHizPNggQtGFF5yK3WarIwfk +D5qXgSKDCjjIBTO9arJGcczBJMIrFl/RBlc3gw0qx9hkkO0W4wjBJlUNKnyZuVMia/w wH8MZWHHwbnbZ47M6otyK2Hl9skWY26psi6p2xsPhRcSMf9B4+v4xwENLlLhnIFNUoio Zshz6u6rDfzyUqZvZvTGBg7RRBs4p34swuUWoRxOKzhvCiQ0V54qIqGhGbo5kRr7J+At tFyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=BKwBCiVLBoUCe95xoYpBtU5PeYqJPUPORzqHYQCVa6s=; b=eCKlJPvhKA45g/f3YV605sHqY9KUwK6P8tXSctDd1IVa9fZknD5nigdvfxZNOgP+oH MngnzS+xYpVY/Hk1vEFyJ6Zxr+RBMRzSHcIa06hiXywCqLIKRR2DnS/la3Km3/azkUdY vnTC6Ly3EEQGqGQ8SOlm2zFOcfN8PfJIhhrc1k2tVHTcstiOEQmpOEDcqMgvK8KGoGBa G6sdQyiut/DkDVljgHwtjPy+RIVPtySisRSpgh6keV8D8azXqYotDviusyiSM3Mvt6nl mD8Z68aEhNZtlE9faiHpLrcVBDVL0mQ379H1Q9XUECCnXy9NoSFgIRacrKlDuLmSuR1d 6sIQ== Received: by 10.60.29.134 with SMTP id k6mr4662499oeh.5.1347003409180; Fri, 07 Sep 2012 00:36:49 -0700 (PDT) Received: by 10.60.29.134 with SMTP id k6mr4662496oeh.5.1347003409093; Fri, 07 Sep 2012 00:36:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.187.8 with HTTP; Fri, 7 Sep 2012 00:36:28 -0700 (PDT) In-Reply-To: <47F98720-3E3F-4920-A890-A5FD10843F0D@laposte.net> References: <47F98720-3E3F-4920-A890-A5FD10843F0D@laposte.net> From: Lorenzo Colitti Date: Fri, 7 Sep 2012 16:36:28 +0900 Message-ID: To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=e89a8fb200f4b5d30304c917abf8 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlA0gYgGuWyNGPUURbnWVj1GN/mXNbzhRQW7wf85yHSwdFnxLpAixrWmsefam9sRweGHYk7j9ATV0ffc5c4WRG97uKG8s53I9kig6qjPSfNcY/auUzTHbbVwMEOqugtxJwvAdqbKNmae2uEdGu2Edyu5cxC8EdRfe7G43/iIWptWrhxkn8j9jYVNrJxoe1k/OBfzPFn Cc: v6ops WG Subject: Re: [v6ops] 464XLAT and BIH X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 07:36:50 -0000 --e89a8fb200f4b5d30304c917abf8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Sep 7, 2012 at 4:21 PM, R=E9mi Despr=E9s = wrote: > Confirmed stand: > - At a time when there are still discussions on functional aspects of > 464XLAT, this particular discussion is IMHO a waste of time > - Preferred approach: keep the sentence, and proceed. > What does "confirmed stand" mean? --e89a8fb200f4b5d30304c917abf8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Sep 7, 2012 at 4:21 PM, R=E9mi Despr=E9s <despres.remi@lapo= ste.net> wrote:
Confirmed stand:
- At a time when there are still discussions on functional aspects of 464XL= AT, this particular discussion is IMHO a waste of time
- Preferred approach: keep the sentence, and proceed.
=
What does "confirmed stand" mean?
--e89a8fb200f4b5d30304c917abf8-- From fibrib@gmail.com Fri Sep 7 00:41:58 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33D5721F86DA for ; Fri, 7 Sep 2012 00:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.073 X-Spam-Level: X-Spam-Status: No, score=-3.073 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16KAXxONocYQ for ; Fri, 7 Sep 2012 00:41:57 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 1D89621F86D3 for ; Fri, 7 Sep 2012 00:41:56 -0700 (PDT) Received: by wibhr14 with SMTP id hr14so1901525wib.13 for ; Fri, 07 Sep 2012 00:41:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2nkyTqfd9kWqlWGzr2uCETjbBMz0ZNL7qAJbcrMFBIA=; b=h3wrASZ0yIc+jujtIgnZV+IIVgqxoyJoUUFtyAAlatLlID/O+KnXOweXDQ5yPztgv7 qsWenRxu758d8CIvmVE6hKiItIe4dFIFvl0EUklnS0DWWAw3I+4D4w7wJznqMYEMoKhD rq1nZU+7LicGhEGBH5FiU/2bRMnkQEI++eisDKBVvGD1Ry29cX111hW2yc9Mw3wleFA4 /ksa8O6grMgM//I7QWGKPy060alfgKcifYsoIuR7Yem3REn4QoFJCUGJsA2oUv8LwF/d rqWzDii7Ho+MPVIP3b0iVclTOVMSQ3hZGj45ovuseujVEG8OAlZyv4v5pUo4DpUm6Qx0 f+MA== MIME-Version: 1.0 Received: by 10.216.162.141 with SMTP id y13mr2663054wek.14.1347003716165; Fri, 07 Sep 2012 00:41:56 -0700 (PDT) Received: by 10.223.37.78 with HTTP; Fri, 7 Sep 2012 00:41:56 -0700 (PDT) In-Reply-To: <47F98720-3E3F-4920-A890-A5FD10843F0D@laposte.net> References: <47F98720-3E3F-4920-A890-A5FD10843F0D@laposte.net> Date: Fri, 7 Sep 2012 16:41:56 +0900 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=0016e65b5db20360ce04c917be34 Cc: v6ops WG Subject: Re: [v6ops] 464XLAT and BIH X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 07:41:58 -0000 --0016e65b5db20360ce04c917be34 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/9/7 R=E9mi Despr=E9s > > Le 2012-09-07 =E0 04:33, Maoke a =E9crit : > ... > > as we are talking about a BCP, if 464xlat doc states BIH is an > indispensible part of the standard, our customers will require us to > definitely provide such a function or such an option rather than any othe= r > alternatives in the service suite. i doubt this is the common floor the > working group is on. > ... > > 1. Stating that a combining 464XLAT with BIH is "possible" isn't stating > it is "indispensable". 2. Being part of a a "BCP" isn't being part of a "standard". > 3. Authors initially wrote "It is also possible to provide single > IPv4/IPv6 translation service, which will be needed in the future case of > IPv6-only servers and peers to be reached from legacy IPv4-only hosts." T= he > added BIH reference better covers the original intent, by just stating a > fact useful to be known. > it is interesting. i don't think the authors were originally intent to involve a helper for providing "single IPv4/IPv6 translation service". and surely the phrase is correct, because CLAT supports IPv4/IPv6 single translation without need anything more once the addressing support statelessness; it is also happens between an IPv4 host in the Internet having access to the native IPv6 server through the PLAT. adding the BIH, is actually adding another solution to the CLAT box for another problem, heavily biased from the original intent which contains CLAT stateless single translation service and the PLAT stateful translation service. > Confirmed stand: > - At a time when there are still discussions on functional aspects of > 464XLAT, this particular discussion is IMHO a waste of time > scope and problem is more important than solution. waste of time is not an execuse of passing misleading and confused sentences. > - Preferred approach: keep the sentence, and proceed > > i don't see this is the consensus of the WG. sorry. - maoke --0016e65b5db20360ce04c917be34 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/9/7 R=E9mi Despr=E9s <despr= es.remi@laposte.net>

Le 2012-09-07 =E0 04:33, Maoke a =E9crit :
...
> as we are talking about a BCP, if 464xlat doc states BIH is an indispe= nsible part of the standard, our customers will require us to definitely pr= ovide such a function or such an option rather than any other alternatives = in the service suite. i doubt this is the common floor the working group is= on.
...

1. Stating that a combining 464XLAT with BIH is "possible" isn= 9;t stating it is "indispensable".=A0
2. Being part of a a "BCP" isn't being part of a "standa= rd".
3. Authors initially wrote "It is also possible to provide single IPv4= /IPv6 translation service, which will be needed in the future case of IPv6-= only servers and peers to be reached from legacy IPv4-only hosts." The= added BIH reference better covers the original intent, by just stating a f= act useful to be known.
=A0
it is=A0interesting.=A0i don't think th= e authors=A0were originally intent to involve=A0a helper=A0for=A0providing = "single IPv4/IPv6 translation service". and surely the phrase is = correct, because CLAT supports IPv4/IPv6 single translation without need an= ything more once the addressing support statelessness; it is also happens b= etween an IPv4 host in the Internet having access to the native IPv6 server= through the PLAT.
=A0
adding the BIH, is actually adding another solution=A0to= the CLAT box=A0for another problem,=A0heavily biased=A0from the=A0original= intent which contains CLAT stateless single translation service and the PL= AT stateful translation service.
=A0
Confirmed stand:
- At a time when there are still discussions on functional aspects of 464XL= AT, this particular discussion is IMHO a waste of time
=A0
scope and problem is more important than solution. waste of = time is not an execuse of passing misleading and confused=A0sentences. =A0<= /div>
=A0

- Preferred approach: keep the sentence, and proceed
=A0


i don't see this is the consensus of= the WG. sorry.
=A0
- maoke
--0016e65b5db20360ce04c917be34-- From despres.remi@laposte.net Fri Sep 7 00:50:31 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEA1121F8715 for ; Fri, 7 Sep 2012 00:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.316 X-Spam-Level: X-Spam-Status: No, score=-0.316 tagged_above=-999 required=5 tests=[AWL=-0.968, BAYES_50=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1VhuWwbOey5 for ; Fri, 7 Sep 2012 00:50:29 -0700 (PDT) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.19]) by ietfa.amsl.com (Postfix) with ESMTP id ABA3221F869E for ; Fri, 7 Sep 2012 00:50:28 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2318.sfr.fr (SMTP Server) with ESMTP id DA599700019E; Fri, 7 Sep 2012 09:50:23 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2318.sfr.fr (SMTP Server) with ESMTP id 7EADF70000ED; Fri, 7 Sep 2012 09:50:23 +0200 (CEST) X-SFR-UUID: 20120907075023518.7EADF70000ED@msfrf2318.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-22--670164102 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Fri, 7 Sep 2012 09:50:23 +0200 Message-Id: <247EEFD9-7F5B-4B32-B5A0-39CE5F887DA5@laposte.net> References: <47F98720-3E3F-4920-A890-A5FD10843F0D@laposte.net> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] 464XLAT and BIH X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 07:50:31 -0000 --Apple-Mail-22--670164102 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-09-07 =E0 09:36, Lorenzo Colitti a =E9crit : > On Fri, Sep 7, 2012 at 4:21 PM, R=E9mi Despr=E9s = wrote: > Confirmed stand: > - At a time when there are still discussions on functional aspects of = 464XLAT, this particular discussion is IMHO a waste of time > - Preferred approach: keep the sentence, and proceed. >=20 > What does "confirmed stand" mean? Found in a dictionary: "stand" =3D "an attitude toward a particular = issue; a position taken in an argument". I was just confirming, in general about this argument, a position = previously expressed in a specific answer to Wojciech. (Sorry if my English isn't for you as good as it should be ;-).) =20 RD= --Apple-Mail-22--670164102 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On Fri, Sep 7, 2012 at 4:21 PM, R=E9mi Despr=E9s <despres.remi@laposte.net> wrote:
Confirmed stand:
- At a time when there are still discussions on functional aspects of = 464XLAT, this particular discussion is IMHO a waste of time
- Preferred approach: keep the sentence, and = proceed.

What does "confirmed stand" = mean?

Found in a dictionary: "stand" =3D  "an = attitude toward a particular issue; a position taken in an = argument".
I was just confirming, in general about this = argument, a position previously expressed in a specific answer to = Wojciech.
(Sorry if my English isn't for you as good as it = should be ;-).)
 
RD
= --Apple-Mail-22--670164102-- From phdgang@gmail.com Fri Sep 7 00:55:37 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8090621F8568 for ; Fri, 7 Sep 2012 00:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AxkZyJqvj0p5 for ; Fri, 7 Sep 2012 00:55:37 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id CCB6321F8575 for ; Fri, 7 Sep 2012 00:55:36 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2963614vbb.31 for ; Fri, 07 Sep 2012 00:55:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MqyBqVOdJRVcOx3qqXBMeUoW0CjZJzYqGzOdHzV+Jqk=; b=Hn8xKwgfc8PlCGS+MbU8hJSX4q+Y6w9EB9WoHP1kjSLkGHODBzGxFDVuSVlPrD5i/y TpAEaDMSdb10atyB+LmPXOVcnsFbLeOqY2a+HdbcwZ3cVkqozVde5R9Wyz8InzkEKGHV iegdppx7OrUy8dpyOHpgOreTrh6lnd3lfbDu5DWLM2RrlxancVoxo76IuzLhhHL2hsSq lleRnRab06rSkUo3lTacu1Y2Jv1vrrl6WxXo5D37GZ25KokOohmQpthdTtb7UnfhM1oe YaQKxoe6SiyjN+FnL1jq8OJllSnVXJWntCvZUrw/ScpoMC13wEVHQPeaZQ5ITq3Ok/ud 5q/A== MIME-Version: 1.0 Received: by 10.58.102.48 with SMTP id fl16mr6693827veb.41.1347004536184; Fri, 07 Sep 2012 00:55:36 -0700 (PDT) Received: by 10.58.114.231 with HTTP; Fri, 7 Sep 2012 00:55:36 -0700 (PDT) In-Reply-To: References: Date: Fri, 7 Sep 2012 15:55:36 +0800 Message-ID: From: GangChen To: Lorenzo Colitti Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 07:55:37 -0000 Hello Lorenzo, 2012/9/7, Lorenzo Colitti : > On Fri, Sep 7, 2012 at 2:59 PM, GangChen wrote: > >> If you haven't concrete argument and only insist on the claim, >> we will be here for another month while that would delay the work. >> Please to identify what the harm you see to object. . > > > Ok, here's a concrete problem, then: the draft contradicts itself. Thanks for providing the concrete point, I guess your intention is not to identify the technical problem after the reading > Section 1 says: > > By combining 464XLAT with BIH [RFC6535], it is also possible to > provide single IPv4 to IPv6 translation service, which will be needed > in the future case of IPv6-only servers [...] > > But Section 2 says: > > This BCP only applies when the following two criteria are present: > [...] > 2. There are IPv4-only applications or hosts that must communicate > across the IPv6-only network to reach the IPv4 Internet. > > So, one section mentions IPv6-only servers, Please note the condition is *combining 464XLAT with BIH*. The draft clearly identifies that. I don't see the harm if a draft to mention the possible relationship with other from that same SDO considering same goal they would like to achieve. > and another section explicitly > says "the IPv4 Internet" where by definition, there cannot be IPv6-only > servers. (*)The section 2 helps to justify the BCP applicability to 464xlat(i.e. IPv4 app through IPv6 network talk to IPv6 server). BIH doesn't need to be justified in this draft, because it already a standard track. It doesn't make sense to mix that with section 1 statement. To be clear, the logic is 1) 464xlat is a BCP in the scenario of IPv4 app through IPv6 network talking to IPv6 server. Section 2 help to answer that 2) BIH is a standard track solution in the scenario of IPv4 apps talking to IPv6. The applicabilities are already justified in RFC6535. But mentioned the possibilities of cooperation are informative/beneficial to readers. >So one section talks about IPv6-only servers, and another section > of the same document declares them to be out of scope. If 464 BCP means the draft is only granted to talk about 464, which exclude everything beyong the scope. I would like to ask why "DNS Proxy Implementation" is ranked with *SHOULD*. It should be out of the scope according to your logic. But it's not true I guess, beacause it provides a valuable effcient data path to 464xlat. It's verified no technical harm and makes 464xlat is better. The same reason is also applied to BIH. Compared to that, BIH is only *mentioned* > In order to resolve the contradiction, either you modify Section 2 to > expand the scope to include IPv6-only servers, or you modify Section 1 to > remove the mention to BIH. Given the two choices I think it's better to > remove BIH, because as soon as IPv6-only servers are in scope, this > document will suddenly become a BCP on "how IPv4-only nodes should > communicate with IPv6-only servers", and I don't think we have consensus > that yet. > I don't see the necessity. Please see(*) BRs Gang From despres.remi@laposte.net Fri Sep 7 00:59:22 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC1E121F8752 for ; Fri, 7 Sep 2012 00:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.236 X-Spam-Level: X-Spam-Status: No, score=-1.236 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A2dGWvmoxONQ for ; Fri, 7 Sep 2012 00:59:22 -0700 (PDT) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.19]) by ietfa.amsl.com (Postfix) with ESMTP id D646921F86FC for ; Fri, 7 Sep 2012 00:59:21 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2318.sfr.fr (SMTP Server) with ESMTP id 4144F70002C3; Fri, 7 Sep 2012 09:59:21 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2318.sfr.fr (SMTP Server) with ESMTP id EF5B670002C2; Fri, 7 Sep 2012 09:59:20 +0200 (CEST) X-SFR-UUID: 20120907075920980.EF5B670002C2@msfrf2318.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <5049A1AF.9080202@gmail.com> Date: Fri, 7 Sep 2012 09:59:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3C325619-F078-48A2-A8B4-3A9666DF0498@laposte.net> References: <5049A1AF.9080202@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 07:59:22 -0000 2012-09-07 09:26, Brian E Carpenter : > I have to say that I find any discussion of IPv6-only servers to be > very premature. Who would seriously advise a content provider or > application service provider to invest in IPv6-only services in > the next few years? Let's keep the topic to how to support *legacy* > clients reaching *legacy* services, which is a very real issue. As you may have noted, I fully agree that v4-only to v6-only isn't the = most pressing issue. Yet it is a fact the BIH RFC 6535 deals with it, and is on standard = track.=20 Just noting that BIH is complementary in a draft that deals with a = related issue isn't, IMHO, a problem that justifies this last minute = attack of a true statement. Regards, RD =20 >=20 > Regards > Brian >=20 > On 07/09/2012 07:27, Lorenzo Colitti wrote: >> On Fri, Sep 7, 2012 at 2:59 PM, GangChen wrote: >>=20 >>> If you haven't concrete argument and only insist on the claim, >>> we will be here for another month while that would delay the work. >>> Please to identify what the harm you see to object. . >>=20 >>=20 >> Ok, here's a concrete problem, then: the draft contradicts itself. >>=20 >> Section 1 says: >>=20 >> By combining 464XLAT with BIH [RFC6535], it is also possible to >> provide single IPv4 to IPv6 translation service, which will be = needed >> in the future case of IPv6-only servers [...] >>=20 >> But Section 2 says: >>=20 >> This BCP only applies when the following two criteria are present: >> [...] >> 2. There are IPv4-only applications or hosts that must communicate >> across the IPv6-only network to reach the IPv4 Internet. >>=20 >> So, one section mentions IPv6-only servers, and another section = explicitly >> says "the IPv4 Internet" where by definition, there cannot be = IPv6-only >> servers. So one section talks about IPv6-only servers, and another = section >> of the same document declares them to be out of scope. >>=20 >> In order to resolve the contradiction, either you modify Section 2 to >> expand the scope to include IPv6-only servers, or you modify Section = 1 to >> remove the mention to BIH. Given the two choices I think it's better = to >> remove BIH, because as soon as IPv6-only servers are in scope, this >> document will suddenly become a BCP on "how IPv4-only nodes should >> communicate with IPv6-only servers", and I don't think we have = consensus >> that yet. >>=20 >>=20 >>=20 >> = ------------------------------------------------------------------------ >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From fibrib@gmail.com Fri Sep 7 01:01:12 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7731621F8769 for ; Fri, 7 Sep 2012 01:01:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.155 X-Spam-Level: X-Spam-Status: No, score=-3.155 tagged_above=-999 required=5 tests=[AWL=0.443, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1AmGygjkEPVz for ; Fri, 7 Sep 2012 01:01:11 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 48B1621F872E for ; Fri, 7 Sep 2012 01:01:11 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so1481700wgb.13 for ; Fri, 07 Sep 2012 01:01:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ALIzX732V6fZM4iXrW5VxWvOhHmwLqLWobZSuleefMo=; b=Vbz1StQtEsxmZpulRZXfxwzkfNi1oIv1GIGvdhKmZ70sJCOabQoMUVn14GV4Bs2rLr OWRl5S0+8/oO5i4q1PUhSaHGzQ8btGjfB7riKRcLVL6BXnknGHyvDsOFIUER0zKit+TI P96Nnn5wlZFEO8275bxFUUeAfaOsHhn5dj1haH90Fd2B15u14SNU/04aHwkVJpQyh5yT u5fWKzz3UUhPiSE+pVbjOE8LNqL1U9FdgNjuwMfI77hx7Ju0tOTP09jIn6fTP+asX89M zeEVWjtkUThgAdPigaoY9WgQPEpBIjd0C7AV5FIO+W8/wEDZOpdQaYRHOMO9tpcj4/Ov 4NGQ== MIME-Version: 1.0 Received: by 10.216.153.207 with SMTP id f57mr2731800wek.196.1347004870207; Fri, 07 Sep 2012 01:01:10 -0700 (PDT) Received: by 10.223.37.78 with HTTP; Fri, 7 Sep 2012 01:01:10 -0700 (PDT) In-Reply-To: References: Date: Fri, 7 Sep 2012 17:01:10 +0900 Message-ID: From: Maoke To: GangChen Content-Type: multipart/alternative; boundary=0016e65a08aacca97004c91802e6 Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 08:01:12 -0000 --0016e65a08aacca97004c91802e6 Content-Type: text/plain; charset=ISO-8859-1 2012/9/7 GangChen > Hello Lorenzo, > > 2012/9/7, Lorenzo Colitti : > > On Fri, Sep 7, 2012 at 2:59 PM, GangChen wrote: > > > >> If you haven't concrete argument and only insist on the claim, > >> we will be here for another month while that would delay the work. > >> Please to identify what the harm you see to object. . > > > > > > Ok, here's a concrete problem, then: the draft contradicts itself. > > Thanks for providing the concrete point, I guess your intention is not > to identify the technical problem after the reading > > > Section 1 says: > > > > By combining 464XLAT with BIH [RFC6535], it is also possible to > > provide single IPv4 to IPv6 translation service, which will be needed > > in the future case of IPv6-only servers [...] > > > > But Section 2 says: > > > > This BCP only applies when the following two criteria are present: > > [...] > > 2. There are IPv4-only applications or hosts that must communicate > > across the IPv6-only network to reach the IPv4 Internet. > > > > So, one section mentions IPv6-only servers, > > Please note the condition is *combining 464XLAT with BIH*. The draft > clearly identifies that. > I don't see the harm if a draft to mention the possible relationship > with other from that same SDO considering same goal they would like to > achieve. > > > > and another section explicitly > > says "the IPv4 Internet" where by definition, there cannot be IPv6-only > > servers. > > (*)The section 2 helps to justify the BCP applicability to > 464xlat(i.e. IPv4 app through IPv6 network talk to IPv6 server). BIH > doesn't need to be justified in this draft, because it already a > standard track. It doesn't make sense to mix that with section 1 > statement. > To be clear, the logic is > 1) 464xlat is a BCP in the scenario of IPv4 app through IPv6 network > talking to IPv6 server. sorry, where in the Section 2 said 464xlat is a BCP in the scenario of IPv4 app through IPv6 network talking to *IPv6 server* ?? - maoke > Section 2 help to answer that > 2) BIH is a standard track solution in the scenario of IPv4 apps > talking to IPv6. The applicabilities are already justified in RFC6535. > But mentioned the possibilities of cooperation are > informative/beneficial to readers. > > > >So one section talks about IPv6-only servers, and another section > > of the same document declares them to be out of scope. > > If 464 BCP means the draft is only granted to talk about 464, which > exclude everything beyong the scope. > I would like to ask why "DNS Proxy Implementation" is ranked with > *SHOULD*. It should be out of the scope according to your logic. > But it's not true I guess, beacause it provides a valuable effcient > data path to 464xlat. > It's verified no technical harm and makes 464xlat is better. > The same reason is also applied to BIH. Compared to that, BIH is only > *mentioned* > > > > In order to resolve the contradiction, either you modify Section 2 to > > expand the scope to include IPv6-only servers, or you modify Section 1 to > > remove the mention to BIH. Given the two choices I think it's better to > > remove BIH, because as soon as IPv6-only servers are in scope, this > > document will suddenly become a BCP on "how IPv4-only nodes should > > communicate with IPv6-only servers", and I don't think we have consensus > > that yet. > > > I don't see the necessity. Please see(*) > > BRs > > Gang > --0016e65a08aacca97004c91802e6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/9/7 GangChen <= phdgang@gmail.com>
Hello Lorenzo,

2012/9/7, Lorenzo Colitti <lorenzo= @google.com>:
> On Fri, Sep 7, 2012 at 2:59 PM, GangChen <phdgang@gmail.com> wrote:
>
>> If you haven't concrete argument and only insist on the claim,=
>> we will be here for another month while that would delay the work.=
>> Please to identify what the harm you see to object. =A0.
>
>
> Ok, here's a concrete problem, then: the draft contradicts itself.=

Thanks for providing the concrete point, I guess your intention is no= t
to identify the technical problem after the reading

> Section 1 says:
>
> =A0 =A0By combining 464XLAT with BIH [RFC6535], it is also possible to=
> =A0 =A0provide single IPv4 to IPv6 translation service, which will be = needed
> =A0 =A0in the future case of IPv6-only servers [...]
>
> But Section 2 says:
>
> =A0 =A0This BCP only applies when the following two criteria are prese= nt:
> [...]
> =A0 =A02. =A0There are IPv4-only applications or hosts that must commu= nicate
> =A0 =A0 =A0 =A0across the IPv6-only network to reach the IPv4 Internet= .
>
> So, one section mentions IPv6-only servers,

Please note the condition is *combining 464XLAT with BIH*. The draft<= br> clearly identifies that.
I don't see the harm if a draft to mention the possible relationship with other from that same SDO considering same goal they would like to
achieve.


> and another section explicitly
> says "the IPv4 Internet" where by definition, there cannot b= e IPv6-only
> servers.

(*)The section 2 helps to justify the BCP applicability to
464xlat(i.e. IPv4 app through IPv6 network talk to IPv6 server). BIH
doesn't need to be justified in this draft, because it already a
standard track. It doesn't make sense to mix that with section 1
statement.
To be clear, the logic is
1) 464xlat is a BCP in the scenario of IPv4 app through IPv6 network
talking to IPv6 server.
=A0
sorry, where in the= Section 2 said 464xlat is a BCP in the scenario of IPv4 app through IPv6 n= etwork talking to *IPv6 server* ?? - maoke
=A0
Section 2 help to answer that
2) BIH is a standard track solution in the scenario of IPv4 apps
talking to IPv6. The applicabilities are already justified in RFC6535.
=A0But mentioned the possibilities of cooperation are
informative/beneficial to readers.


>So one section talks about IPv6-only servers, and another section
> of the same document declares them to be out of scope.

If 464 BCP means the draft is only granted to talk about 464, which exclude everything beyong the scope.
I would like to ask why "DNS Proxy Implementation" is ranked with=
*SHOULD*. It should be out of the scope according to your logic.
But it's not true I guess, beacause it provides a valuable effcient
data path to 464xlat.
It's verified no technical harm and makes 464xlat is better.
The same reason is also applied to BIH. =A0Compared to that, BIH is only *mentioned*


> In order to resolve the contradiction, either you modify Section 2 to<= br> > expand the scope to include IPv6-only servers, or you modify Section 1= to
> remove the mention to BIH. Given the two choices I think it's bett= er to
> remove BIH, because as soon as IPv6-only servers are in scope, this > document will suddenly become a BCP on "how IPv4-only nodes shoul= d
> communicate with IPv6-only servers", and I don't think we hav= e consensus
> that yet.
>
I don't see the necessity. Please see(*)

BRs

Gang

--0016e65a08aacca97004c91802e6-- From despres.remi@laposte.net Fri Sep 7 01:04:00 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEB4121F8683 for ; Fri, 7 Sep 2012 01:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[AWL=-0.341, BAYES_05=-1.11, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NwuHlMxf6d7b for ; Fri, 7 Sep 2012 01:04:00 -0700 (PDT) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.19]) by ietfa.amsl.com (Postfix) with ESMTP id C897421F8681 for ; Fri, 7 Sep 2012 01:03:59 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2318.sfr.fr (SMTP Server) with ESMTP id D33477000143; Fri, 7 Sep 2012 10:03:51 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2318.sfr.fr (SMTP Server) with ESMTP id 8C3B270002BD; Fri, 7 Sep 2012 10:03:51 +0200 (CEST) X-SFR-UUID: 20120907080351574.8C3B270002BD@msfrf2318.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-23--669355994 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Fri, 7 Sep 2012 10:03:51 +0200 Message-Id: <36B8743C-5758-4B7F-9C31-0A4CD02D772A@laposte.net> References: <47F98720-3E3F-4920-A890-A5FD10843F0D@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] 464XLAT and BIH X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 08:04:01 -0000 --Apple-Mail-23--669355994 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-09-07 =E0 09:41, Maoke a =E9crit : >=20 >=20 > 2012/9/7 R=E9mi Despr=E9s >=20 > Le 2012-09-07 =E0 04:33, Maoke a =E9crit : > ... > > as we are talking about a BCP, if 464xlat doc states BIH is an = indispensible part of the standard, our customers will require us to = definitely provide such a function or such an option rather than any = other alternatives in the service suite. i doubt this is the common = floor the working group is on. > ... >=20 > 1. Stating that a combining 464XLAT with BIH is "possible" isn't = stating it is "indispensable".=20 > 2. Being part of a a "BCP" isn't being part of a "standard". > 3. Authors initially wrote "It is also possible to provide single = IPv4/IPv6 translation service, which will be needed in the future case = of IPv6-only servers and peers to be reached from legacy IPv4-only = hosts." The added BIH reference better covers the original intent, by = just stating a fact useful to be known. > =20 > it is interesting. i don't think the authors were originally intent to = involve a helper for providing "single IPv4/IPv6 translation service". = and surely the phrase is correct, because CLAT supports IPv4/IPv6 single = translation without need anything more once the addressing support = statelessness; it is also happens between an IPv4 host in the Internet = having access to the native IPv6 server through the PLAT. > =20 > adding the BIH, is actually adding another solution to the CLAT box = for another problem, heavily biased from the original intent which = contains CLAT stateless single translation service and the PLAT stateful = translation service. > =20 > Confirmed stand: > - At a time when there are still discussions on functional aspects of = 464XLAT, this particular discussion is IMHO a waste of time > =20 > scope and problem is more important than solution. waste of time is = not an execuse of passing misleading and confused sentences. The sentence is AFAIK neither misleading nor confused. Yes, 464XLAT and BIH have complementary targets and can usefully be = combined. > =20 > =20 > - Preferred approach: keep the sentence, and proceed > =20 >=20 >=20 > i don't see this is the consensus of the WG. sorry. No claim there is a consensus. Just stating a preference (my right I suppose).=20 RD > =20 > - maoke --Apple-Mail-23--669355994 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1


2012/9/7 R=E9mi Despr=E9s <despres.remi@laposte.net>

Le 2012-09-07 =E0 04:33, Maoke a =E9crit :
...
> as we are talking about a BCP, if 464xlat doc states BIH is an = indispensible part of the standard, our customers will require us to = definitely provide such a function or such an option rather than any = other alternatives in the service suite. i doubt this is the common = floor the working group is on.
...

1. Stating that a combining 464XLAT with BIH is "possible" isn't stating = it is "indispensable". 
2. Being part of a a "BCP" isn't being part of a "standard".
3. Authors initially wrote "It is also possible to provide single = IPv4/IPv6 translation service, which will be needed in the future case = of IPv6-only servers and peers to be reached from legacy IPv4-only = hosts." The added BIH reference better covers the original intent, by = just stating a fact useful to be known.
 
it is interesting. i don't = think the authors were originally intent to involve a = helper for providing "single IPv4/IPv6 translation service". = and surely the phrase is correct, because CLAT supports IPv4/IPv6 single = translation without need anything more once the addressing support = statelessness; it is also happens between an IPv4 host in the Internet = having access to the native IPv6 server through the PLAT.
 
adding the BIH, is actually adding another = solution to the CLAT box for another problem, heavily = biased from the original intent which contains CLAT stateless = single translation service and the PLAT stateful translation service. =
 
Confirmed stand:
- At a time when there are still discussions on functional aspects of = 464XLAT, this particular discussion is IMHO a waste of = time
 
scope and problem is more = important than solution. waste of time is not an execuse of passing = misleading and confused sentences. =

The sentence is AFAIK neither = misleading nor confused.
Yes, 464XLAT and BIH have = complementary targets and can usefully be combined.
 
 

- Preferred approach: keep the sentence, and proceed
 


i don't see this is the consensus = of the WG. sorry.

No claim there is a = consensus.
Just stating a preference (my right I = suppose). 

RD


<= blockquote type=3D"cite">
 
- maoke

= --Apple-Mail-23--669355994-- From fibrib@gmail.com Fri Sep 7 01:09:26 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD3021F8682 for ; Fri, 7 Sep 2012 01:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.75 X-Spam-Level: X-Spam-Status: No, score=-2.75 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xRPYp99fmfaF for ; Fri, 7 Sep 2012 01:09:25 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 05AE921F8592 for ; Fri, 7 Sep 2012 01:09:24 -0700 (PDT) Received: by weyu54 with SMTP id u54so1709327wey.31 for ; Fri, 07 Sep 2012 01:09:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cc5OXh3IqSVXwxmpu4uQolA6c3H0XhiRvgAUAh+5vBo=; b=v/hE+fOrkWLYAva/ahun7IuzLVv6QhWolc8Y9johtLPsg3G/jvaiTcKwH8N0KURMnL HQw920tpmH7o/s9XJNf8716QpyQk0TMZo4FMLD4zAUqO3qQ+ITCtqBgcSoH2Hp7x2sjg NcOmKyOxXHvw/aneRt1dyvhYsjFAl9L34QA1KTm7ywWf5716oohGG/UEf7jxdusNXJ+A Pd8guO5V1Ya9hG/YV6QwXGRW38h++czsco9ZUF1iDvgmOi43W9iUUIfRuJ6Z0fT0c6kr 6YCSYmRwA7coPoDh7idSAYFQdYgkJA3Hbawi9UlgkWnz/txCYU7LUEzCsCrDNcHvHeum uY2Q== MIME-Version: 1.0 Received: by 10.180.76.36 with SMTP id h4mr51335515wiw.13.1347005364020; Fri, 07 Sep 2012 01:09:24 -0700 (PDT) Received: by 10.223.37.78 with HTTP; Fri, 7 Sep 2012 01:09:23 -0700 (PDT) In-Reply-To: <3C325619-F078-48A2-A8B4-3A9666DF0498@laposte.net> References: <5049A1AF.9080202@gmail.com> <3C325619-F078-48A2-A8B4-3A9666DF0498@laposte.net> Date: Fri, 7 Sep 2012 17:09:23 +0900 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=f46d043c09623ba73a04c9182079 Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 08:09:26 -0000 --f46d043c09623ba73a04c9182079 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable dear Remi, 2012/9/7 R=E9mi Despr=E9s > > 2012-09-07 09:26, Brian E Carpenter : > > > I have to say that I find any discussion of IPv6-only servers to be > > very premature. Who would seriously advise a content provider or > > application service provider to invest in IPv6-only services in > > the next few years? Let's keep the topic to how to support *legacy* > > clients reaching *legacy* services, which is a very real issue. > > As you may have noted, I fully agree that v4-only to v6-only isn't the > most pressing issue. > Yet it is a fact the BIH RFC 6535 deals with it, and is on standard track= . > Just noting that BIH is complementary in a draft that deals with a relate= d > issue isn't, IMHO, a problem that justifies this last minute attack of a > true statement. > we can have a lot of complementaries. BIH does work with itself. in practice it is fine if one would like to do that, but i doubt it should be the "best" practice. on the other hand, i share Brian's point that right now it is NOT the time to debate whether the BIH + 464xlat is a best practice regarding the issue of accessing IPv6-only servers. therefore i suggest we simply remove the statement and return to the common floor of the problem that 464xlat focuses. - maoke > > Regards, > RD > > > > > > > > Regards > > Brian > > > > On 07/09/2012 07:27, Lorenzo Colitti wrote: > >> On Fri, Sep 7, 2012 at 2:59 PM, GangChen wrote: > >> > >>> If you haven't concrete argument and only insist on the claim, > >>> we will be here for another month while that would delay the work. > >>> Please to identify what the harm you see to object. . > >> > >> > >> Ok, here's a concrete problem, then: the draft contradicts itself. > >> > >> Section 1 says: > >> > >> By combining 464XLAT with BIH [RFC6535], it is also possible to > >> provide single IPv4 to IPv6 translation service, which will be neede= d > >> in the future case of IPv6-only servers [...] > >> > >> But Section 2 says: > >> > >> This BCP only applies when the following two criteria are present: > >> [...] > >> 2. There are IPv4-only applications or hosts that must communicate > >> across the IPv6-only network to reach the IPv4 Internet. > >> > >> So, one section mentions IPv6-only servers, and another section > explicitly > >> says "the IPv4 Internet" where by definition, there cannot be IPv6-onl= y > >> servers. So one section talks about IPv6-only servers, and another > section > >> of the same document declares them to be out of scope. > >> > >> In order to resolve the contradiction, either you modify Section 2 to > >> expand the scope to include IPv6-only servers, or you modify Section 1 > to > >> remove the mention to BIH. Given the two choices I think it's better t= o > >> remove BIH, because as soon as IPv6-only servers are in scope, this > >> document will suddenly become a BCP on "how IPv4-only nodes should > >> communicate with IPv6-only servers", and I don't think we have consens= us > >> that yet. > >> > >> > >> > >> ----------------------------------------------------------------------= -- > >> > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --f46d043c09623ba73a04c9182079 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
dear Remi,
2012/9/7 R=E9mi Despr=E9s <despres.remi@laposte.net>

2012-09-07 09:26, Brian E Carpenter :

> I have to say that I find any discussion of IPv6-only servers to be > very premature. Who would seriously advise a content provider or
> application service provider to invest in IPv6-only services in
> the next few years? Let's keep the topic to how to support *legacy= *
> clients reaching *legacy* services, which is a very real issue.

As you may have noted, I fully agree that v4-only to v6-only isn'= t the most pressing issue.
Yet it is a fact the BIH RFC 6535 deals with it, and is on standard track.<= br> Just noting that BIH is complementary in a draft that deals with a related = issue isn't, IMHO, a problem that justifies this last minute attack of = a true statement.
=A0
we can have a lot of c= omplementaries. BIH does work with itself. in practice it is fine if one wo= uld like to do that, but i doubt it should be the "best" practice= . on the other hand, i share Brian's point that right now it is=A0NOT t= he time to debate whether the BIH + 464xlat is a best practice=A0regarding = the issue of accessing IPv6-only servers.
=A0
therefore i suggest we simply remove the statement and r= eturn to the common floor=A0of the problem that 464xlat focuses.
=A0
- maoke
=A0

Regards,
RD




>
> Regards
> =A0 Brian
>
> On 07/09/2012 07:27, Lorenzo Colitti wrote:
>> On Fri, Sep 7, 2012 at 2:59 PM, GangChen <phdgang@gmail.com> wrote:
>>
>>> If you haven't concrete argument and only insist on the cl= aim,
>>> we will be here for another month while that would delay the w= ork.
>>> Please to identify what the harm you see to object. =A0.
>>
>>
>> Ok, here's a concrete problem, then: the draft contradicts its= elf.
>>
>> Section 1 says:
>>
>> =A0 By combining 464XLAT with BIH [RFC6535], it is also possible t= o
>> =A0 provide single IPv4 to IPv6 translation service, which will be= needed
>> =A0 in the future case of IPv6-only servers [...]
>>
>> But Section 2 says:
>>
>> =A0 This BCP only applies when the following two criteria are pres= ent:
>> [...]
>> =A0 2. =A0There are IPv4-only applications or hosts that must comm= unicate
>> =A0 =A0 =A0 across the IPv6-only network to reach the IPv4 Interne= t.
>>
>> So, one section mentions IPv6-only servers, and another section ex= plicitly
>> says "the IPv4 Internet" where by definition, there cann= ot be IPv6-only
>> servers. So one section talks about IPv6-only servers, and another= section
>> of the same document declares them to be out of scope.
>>
>> In order to resolve the contradiction, either you modify Section 2= to
>> expand the scope to include IPv6-only servers, or you modify Secti= on 1 to
>> remove the mention to BIH. Given the two choices I think it's = better to
>> remove BIH, because as soon as IPv6-only servers are in scope, thi= s
>> document will suddenly become a BCP on "how IPv4-only nodes s= hould
>> communicate with IPv6-only servers", and I don't think we= have consensus
>> that yet.
>>
>>
>>
>> ------------------------------------------------------------------= ------
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

--f46d043c09623ba73a04c9182079-- From lorenzo@google.com Fri Sep 7 01:15:22 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D20F421F86C6 for ; Fri, 7 Sep 2012 01:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.751 X-Spam-Level: X-Spam-Status: No, score=-102.751 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xf5aLLwnRrvV for ; Fri, 7 Sep 2012 01:15:21 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0462621F86CA for ; Fri, 7 Sep 2012 01:15:20 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so4492641obb.31 for ; Fri, 07 Sep 2012 01:15:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=9433j6z7FWFlbKr/CXhbHpVpMoF3AV1aVHXobr0B34g=; b=YESN0FyVQMysdSBTVdR2d6iB14fZvwT3IZp+NOhKPEVYUizwtRQOG0uEMkUw9bmSE6 oU83QTrI/cQXZWSc80QByxVhzCzIoHA/LXObDQl/Eu8Y/4ZMHZrVqPKijyuWXBKTe/Ni xhAgOukkjClyOMng9VCqf/01TmveuQG7ZTeHHsGerZYq+HCHIgJuxUwFvR5goHJ87hmr O4as3URIjPZwZEinjJd42GBoR75DVGoolGcaBCzhrtJEI67uy8Osqvsm9dbuiMjOmXiY ZVaIWubj4JliPvxwRN9ZDosu7QCuOTEUOsaiIsq9aepuF7S08QncuEhJNBIIfNsDTC2g Y/4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=9433j6z7FWFlbKr/CXhbHpVpMoF3AV1aVHXobr0B34g=; b=gB3+teWN16qh6pVz/lXExiTQwnAO9PLaKpQjOPCCvtIm9gdqsA3JTRPhBJU5vqzUNN ygjMaE1dVllIh0XaU1i8MX9cCV3xhPoD35OeEESdoP1UGQZxbH5L26GdSKHZB7QPdM4Z YaOaL+ExqeiDhJWMA9I3cVd7o3eXl3ggPtVhrA9727shCt6fNK5Zya1g4orkKdCMTPOs We0TzcfNiWtBVeHrgueyRN93sM4K/GEgvfMX2iwHqTuW80hFEUHXjVRN8fDH6N9opwAt fTXaXnhQbMRhP8pH8YcClsh99h4jDJgPpj2OeVyUBhTFs+as5CXtPCP1kCORA1Iqz4LL NY0A== Received: by 10.182.110.40 with SMTP id hx8mr4825711obb.47.1347005719942; Fri, 07 Sep 2012 01:15:19 -0700 (PDT) Received: by 10.182.110.40 with SMTP id hx8mr4825700obb.47.1347005719854; Fri, 07 Sep 2012 01:15:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.187.8 with HTTP; Fri, 7 Sep 2012 01:14:59 -0700 (PDT) In-Reply-To: <247EEFD9-7F5B-4B32-B5A0-39CE5F887DA5@laposte.net> References: <47F98720-3E3F-4920-A890-A5FD10843F0D@laposte.net> <247EEFD9-7F5B-4B32-B5A0-39CE5F887DA5@laposte.net> From: Lorenzo Colitti Date: Fri, 7 Sep 2012 17:14:59 +0900 Message-ID: To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=f46d044516dd713e7b04c918355a X-System-Of-Record: true X-Gm-Message-State: ALoCoQkVsvsi+/s+8F5l3ge9+d0sBymufHYDtZFrFfLRP4AZATGT0g5jSN+HntBoKvxKHl+qgR0ul8h16tSCSwRPZX0TZ4IeXwupr6biEJP9tIP+lKR8baPCkXqqYOdoYUC1zYkJMDeh3k9u8puz1DxrdzeiLrDKKVMpNGPeZPjM0APgrlvVn9E3l34nKaXg9KkUyKilmJkj Cc: v6ops WG Subject: Re: [v6ops] 464XLAT and BIH X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 08:15:22 -0000 --f46d044516dd713e7b04c918355a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Sep 7, 2012 at 4:50 PM, R=E9mi Despr=E9s = wrote: > > Le 2012-09-07 =E0 09:36, Lorenzo Colitti a =E9crit : > > On Fri, Sep 7, 2012 at 4:21 PM, R=E9mi Despr=E9s wrote: > >> Confirmed stand: >> - At a time when there are still discussions on functional aspects of >> 464XLAT, this particular discussion is IMHO a waste of time >> - Preferred approach: keep the sentence, and proceed. >> > > What does "confirmed stand" mean? > > > Found in a dictionary: "stand" =3D "an attitude toward a particular issu= e; > a position taken in an argument". > I was just confirming, in general about this argument, a position > previously expressed in a specific answer to Wojciech. > (Sorry if my English isn't for you as good as it should be ;-).) > Ah. So it's *your* confirmed stand, and not anyone else's, right? In other words, you are expressing your opinion to the list? --f46d044516dd713e7b04c918355a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Sep 7, 2012 at 4:50 PM, R=E9mi Despr=E9s <despres.remi@lapo= ste.net> wrote:

Le 2012-09-07 =E0 09:36, = Lorenzo Colitti a =E9crit :

On Fri, Sep 7, 2012 at 4:21 PM, R=E9mi Despr=E9s <despre= s.remi@laposte.net> wrote:
Confirmed stand:
- At a time when there are still discussions on functional aspects of 464XL= AT, this particular discussion is IMHO a waste of time
- Preferred approach: keep the sentence, and proceed.
=
What does "confirmed stand" mean?

Found in a dictionary: "stand&= quot; =3D =A0"an attitude toward a p= articular issue; a position taken in an argument".
I was jus= t confirming, in general about this argument, a position previously express= ed in a specific answer to Wojciech.
(Sorry if my English isn't for you as good as it should be ;-).)

Ah. So it's *your* confirmed= stand, and not anyone else's, right? In other words, you are expressin= g your opinion to the list?
--f46d044516dd713e7b04c918355a-- From fibrib@gmail.com Fri Sep 7 01:18:19 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 191E921F86EE for ; Fri, 7 Sep 2012 01:18:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nCjj99kFoxgI for ; Fri, 7 Sep 2012 01:18:18 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id C9EB121F86E2 for ; Fri, 7 Sep 2012 01:18:17 -0700 (PDT) Received: by wibhr14 with SMTP id hr14so1928081wib.13 for ; Fri, 07 Sep 2012 01:18:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wes3LnnyTUspQ2BEuhqxQPtUEyRn0o4NRIv1AGkDBXo=; b=gCu6wbjbWc0HlWULG2RtimqYbNSS97FkqITjuaOkv+BNuDhsw67VhIAOb4jghVfYJh c7X7cRjz2HaYhuFZ7shCmN449ve44xWM+bksefM14mabAwB/Xuvg4EqAT2ed6QfGfff7 UY7hWvH6JondQa9CKa5p17scT743MPv/v/eyzahUmVcw6m+O7zpFEaF7q4Ahks/ZPJEb PciNr6xqKP52f/seFh5+R9krYrRHbofUA2aB5Aui0YziSSBNEoEyWknovu+jEtK/pun0 35TklniYORqZVELDs1vaexCzW2tcZye7FtCC4Qh5KgLMKijSQEymx4NZkEP7GBX9N1h1 vuZw== MIME-Version: 1.0 Received: by 10.216.209.87 with SMTP id r65mr2510297weo.42.1347005896845; Fri, 07 Sep 2012 01:18:16 -0700 (PDT) Received: by 10.223.37.78 with HTTP; Fri, 7 Sep 2012 01:18:16 -0700 (PDT) In-Reply-To: <36B8743C-5758-4B7F-9C31-0A4CD02D772A@laposte.net> References: <47F98720-3E3F-4920-A890-A5FD10843F0D@laposte.net> <36B8743C-5758-4B7F-9C31-0A4CD02D772A@laposte.net> Date: Fri, 7 Sep 2012 17:18:16 +0900 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=0016e6d6456efdeb3d04c9183f4e Cc: v6ops WG Subject: Re: [v6ops] 464XLAT and BIH X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 08:18:19 -0000 --0016e6d6456efdeb3d04c9183f4e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/9/7 R=E9mi Despr=E9s > > Le 2012-09-07 =E0 09:41, Maoke a =E9crit : > > > > 2012/9/7 R=E9mi Despr=E9s > >> >> Le 2012-09-07 =E0 04:33, Maoke a =E9crit : >> ... >> > as we are talking about a BCP, if 464xlat doc states BIH is an >> indispensible part of the standard, our customers will require us to >> definitely provide such a function or such an option rather than any oth= er >> alternatives in the service suite. i doubt this is the common floor the >> working group is on. >> ... >> >> 1. Stating that a combining 464XLAT with BIH is "possible" isn't stating >> it is "indispensable". > > 2. Being part of a a "BCP" isn't being part of a "standard". >> 3. Authors initially wrote "It is also possible to provide single >> IPv4/IPv6 translation service, which will be needed in the future case o= f >> IPv6-only servers and peers to be reached from legacy IPv4-only hosts." = The >> added BIH reference better covers the original intent, by just stating a >> fact useful to be known. >> > (#) following point is emphasized > > it is interesting. i don't think the authors were originally intent to > involve a helper for providing "single IPv4/IPv6 translation service". an= d > surely the phrase is correct, because CLAT supports IPv4/IPv6 single > translation without need anything more once the addressing support > statelessness; it is also happens between an IPv4 host in the Internet > having access to the native IPv6 server through the PLAT. > > adding the BIH, is actually adding another solution to the CLAT box for > another problem, heavily biased from the original intent which contains > CLAT stateless single translation service and the PLAT stateful translati= on > service. > > > (/#) end of emphasis > Confirmed stand: >> - At a time when there are still discussions on functional aspects of >> 464XLAT, this particular discussion is IMHO a waste of time >> > > scope and problem is more important than solution. waste of time is not a= n > execuse of passing misleading and confused sentences. > > > The sentence is AFAIK neither misleading nor confused. > Yes, 464XLAT and BIH have complementary targets and can usefully be > combined. > > AFAIK the sentence is misleading. 464 target is clearly described in Section 2. the original intent of mentioning the IPv4/IPv6 single translation was not a target, IMHO, but a natural result. it is fine not to include the original intent if we think that is out of scope. it is also fine to include that if we think that non-normative. but replacing the original intent with statement on BIH actually made things different. see my (#) that is emphasized above. i may change the question: what BIH can gain from being combined with 464xlat? anything? - maoke > > Just stating a preference (my right I suppose). > > RD > > > > - maoke > > > --0016e6d6456efdeb3d04c9183f4e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/9/7 R=E9mi Despr=E9s <despr= es.remi@laposte.net>

Le 2012-09-07 =E0 09:41, = Maoke a =E9crit :



2012/9/7 R=E9mi Despr=E9s <desp= res.remi@laposte.net>

Le 2012-09-07 =E0 04:33, Maoke a =E9crit :
...
> as we are talking about a BCP, if 464xlat doc states BIH is an indispe= nsible part of the standard, our customers will require us to definitely pr= ovide such a function or such an option rather than any other alternatives = in the service suite. i doubt this is the common floor the working group is= on.
...

1. Stating that a combining 464XLAT with BIH is "possible" isn= 9;t stating it is "indispensable".=A0
2. Being part of a a "BCP" isn't being part of a "standa= rd".
3. Authors initially wrote "It is also possible to provide single IPv4= /IPv6 translation service, which will be needed in the future case of IPv6-= only servers and peers to be reached from legacy IPv4-only hosts." The= added BIH reference better covers the original intent, by just stating a f= act useful to be known.
=A0
(#) =A0following point is emphasized
=A0
it is=A0intere= sting.=A0i don't think the authors=A0were originally intent to involve= =A0a helper=A0for=A0providing "single IPv4/IPv6 translation service&qu= ot;. and surely the phrase is correct, because CLAT supports IPv4/IPv6 sing= le translation without need anything more once the addressing support state= lessness; it is also happens between an IPv4 host in the Internet having ac= cess to the native IPv6 server through the PLAT.
=A0
adding the BIH, is actually adding another solution=A0to= the CLAT box=A0for another problem,=A0heavily biased=A0from the=A0original= intent which contains CLAT stateless single translation service and the PL= AT stateful translation service.
=A0
= =A0
(/#) end of emphasis=A0
Confirmed stand:
- At a time when there are still discussions on functional aspects of 464XL= AT, this particular discussion is IMHO a waste of time
=A0
scope and problem is more important than solution. waste of = time is not an execuse of passing misleading and confused=A0sentences.

The sentence is AFAIK neither= misleading nor confused.
Yes, 464XLAT and BIH have complementary= targets and can usefully be combined.
=A0
=A0
AFAIK the sentence is misleading. 464 target is clearly = described in Section 2. the original intent of mentioning the IPv4/IPv6 sin= gle translation was not a target, IMHO, but a natural result. it is fine no= t to include the original intent if we think that is out of scope. it is al= so fine to include that if we think that non-normative.
=A0
but replacing the original intent with statement on BIH = actually made things different. see my (#) that is emphasized=A0above.
=A0
i may change the question: what BIH can gain from bein= g combined with 464xlat? anything?
=A0
- maoke
=A0
=A0
Just stating a preference (my right I suppose).=A0
=

RD


=A0
- maoke


--0016e6d6456efdeb3d04c9183f4e-- From despres.remi@laposte.net Fri Sep 7 01:21:34 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D68C021F876C for ; Fri, 7 Sep 2012 01:21:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.532 X-Spam-Level: X-Spam-Status: No, score=-0.532 tagged_above=-999 required=5 tests=[AWL=-0.443, BAYES_20=-0.74, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxCwProLOvP2 for ; Fri, 7 Sep 2012 01:21:33 -0700 (PDT) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.3]) by ietfa.amsl.com (Postfix) with ESMTP id 75D9B21F86F1 for ; Fri, 7 Sep 2012 01:21:32 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2112.sfr.fr (SMTP Server) with ESMTP id 4F4E67000227; Fri, 7 Sep 2012 10:21:31 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2112.sfr.fr (SMTP Server) with ESMTP id DF0B3700021F; Fri, 7 Sep 2012 10:21:30 +0200 (CEST) X-SFR-UUID: 20120907082130913.DF0B3700021F@msfrf2112.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-24--668297056 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Fri, 7 Sep 2012 10:21:30 +0200 Message-Id: <41E07D8C-49E3-4A2B-9675-7313383A15BC@laposte.net> References: <47F98720-3E3F-4920-A890-A5FD10843F0D@laposte.net> <247EEFD9-7F5B-4B32-B5A0-39CE5F887DA5@laposte.net> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] 464XLAT and BIH X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 08:21:34 -0000 --Apple-Mail-24--668297056 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-09-07 =E0 10:14, Lorenzo Colitti a =E9crit : > On Fri, Sep 7, 2012 at 4:50 PM, R=E9mi Despr=E9s = wrote: >=20 > Le 2012-09-07 =E0 09:36, Lorenzo Colitti a =E9crit : >=20 >> On Fri, Sep 7, 2012 at 4:21 PM, R=E9mi Despr=E9s = wrote: >> Confirmed stand: >> - At a time when there are still discussions on functional aspects of = 464XLAT, this particular discussion is IMHO a waste of time >> - Preferred approach: keep the sentence, and proceed. >>=20 >> What does "confirmed stand" mean? >=20 > Found in a dictionary: "stand" =3D "an attitude toward a particular = issue; a position taken in an argument". > I was just confirming, in general about this argument, a position = previously expressed in a specific answer to Wojciech. > (Sorry if my English isn't for you as good as it should be ;-).) >=20 > Ah. So it's *your* confirmed stand, and not anyone else's, right? In = other words, you are expressing your opinion to the list? Indeed, as usual. (And surprised to be suspected to do otherwise!) RD --Apple-Mail-24--668297056 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On Fri, Sep 7, 2012 at 4:50 PM, R=E9mi Despr=E9s <despres.remi@laposte.net> wrote:

Le 2012-09-07 =E0 = 09:36, Lorenzo Colitti a =E9crit :

On Fri, Sep 7, 2012 at 4:21 = PM, R=E9mi Despr=E9s <despres.remi@laposte.net> wrote:
Confirmed stand:
- At a time when there are still discussions on functional aspects of = 464XLAT, this particular discussion is IMHO a waste of time
- Preferred approach: keep the sentence, and = proceed.

What does "confirmed stand" = mean?

Found in a dictionary: "stand" = =3D  "an attitude toward a = particular issue; a position taken in an argument".
I was just = confirming, in general about this argument, a position previously = expressed in a specific answer to Wojciech.
(Sorry if my English isn't for you as good as it should be = ;-).)

Ah. So it's *your* = confirmed stand, and not anyone else's, right? In other words, you are = expressing your opinion to the list?

Indeed, as usual.
(And surprised = to be suspected to do = otherwise!)
RD


= --Apple-Mail-24--668297056-- From despres.remi@laposte.net Fri Sep 7 01:41:20 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F3A321F865E for ; Fri, 7 Sep 2012 01:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.434 X-Spam-Level: X-Spam-Status: No, score=-1.434 tagged_above=-999 required=5 tests=[AWL=0.514, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RkEJveZ2ApZ7 for ; Fri, 7 Sep 2012 01:41:19 -0700 (PDT) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.19]) by ietfa.amsl.com (Postfix) with ESMTP id 3580321F8669 for ; Fri, 7 Sep 2012 01:41:18 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2318.sfr.fr (SMTP Server) with ESMTP id E4BE1700005A; Fri, 7 Sep 2012 10:41:17 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2318.sfr.fr (SMTP Server) with ESMTP id 6751B700009F; Fri, 7 Sep 2012 10:41:17 +0200 (CEST) X-SFR-UUID: 20120907084117423.6751B700009F@msfrf2318.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-25--667110215 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Fri, 7 Sep 2012 10:41:17 +0200 Message-Id: <9F02FD3E-46C5-4BBB-ACBB-BB59DD420F24@laposte.net> References: <47F98720-3E3F-4920-A890-A5FD10843F0D@laposte.net> <36B8743C-5758-4B7F-9C31-0A4CD02D772A@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] 464XLAT and BIH X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 08:41:20 -0000 --Apple-Mail-25--667110215 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-09-07 =E0 10:18, Maoke a =E9crit : >=20 >=20 > 2012/9/7 R=E9mi Despr=E9s >=20 > Le 2012-09-07 =E0 09:41, Maoke a =E9crit : >=20 >>=20 >>=20 >> 2012/9/7 R=E9mi Despr=E9s >>=20 >> Le 2012-09-07 =E0 04:33, Maoke a =E9crit : >> ... >> > as we are talking about a BCP, if 464xlat doc states BIH is an = indispensible part of the standard, our customers will require us to = definitely provide such a function or such an option rather than any = other alternatives in the service suite. i doubt this is the common = floor the working group is on. >> ... >>=20 >> 1. Stating that a combining 464XLAT with BIH is "possible" isn't = stating it is "indispensable".=20 >> 2. Being part of a a "BCP" isn't being part of a "standard". >> 3. Authors initially wrote "It is also possible to provide single = IPv4/IPv6 translation service, which will be needed in the future case = of IPv6-only servers and peers to be reached from legacy IPv4-only = hosts." The added BIH reference better covers the original intent, by = just stating a fact useful to be known. >=20 > =20 > (#) following point is emphasized >> =20 >> it is interesting. i don't think the authors were originally intent = to involve a helper for providing "single IPv4/IPv6 translation = service". and surely the phrase is correct, because CLAT supports = IPv4/IPv6 single translation without need anything more once the = addressing support statelessness; it is also happens between an IPv4 = host in the Internet having access to the native IPv6 server through the = PLAT. >> =20 >> adding the BIH, is actually adding another solution to the CLAT box = for another problem, heavily biased from the original intent which = contains CLAT stateless single translation service and the PLAT stateful = translation service. The current sentence has been coined by authors themselves.=20 It is therefore, presumably, compatible with their original intent. I would really prefer to hear from you about 464XLAT with /64 delegated = prefixes (and no NAT44 to be completely stateless), assuming you are = also interested in _technical choices_ to be made before publication. RD >> =20 >=20 > =20 > (/#) end of emphasis=20 >> Confirmed stand: >> - At a time when there are still discussions on functional aspects of = 464XLAT, this particular discussion is IMHO a waste of time >> =20 >> scope and problem is more important than solution. waste of time is = not an execuse of passing misleading and confused sentences. >=20 > The sentence is AFAIK neither misleading nor confused. > Yes, 464XLAT and BIH have complementary targets and can usefully be = combined. > =20 > =20 > AFAIK the sentence is misleading. 464 target is clearly described in = Section 2. the original intent of mentioning the IPv4/IPv6 single = translation was not a target, IMHO, but a natural result. it is fine not = to include the original intent if we think that is out of scope. it is = also fine to include that if we think that non-normative. > =20 > but replacing the original intent with statement on BIH actually made = things different. see my (#) that is emphasized above. > =20 > i may change the question: what BIH can gain from being combined with = 464xlat? anything? > =20 > - maoke > =20 > =20 > Just stating a preference (my right I suppose).=20 >=20 > RD >=20 >=20 >> =20 >> - maoke >=20 >=20 --Apple-Mail-25--667110215 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1


2012/9/7 R=E9mi Despr=E9s <despres.remi@laposte.net>

Le 2012-09-07 =E0 = 09:41, Maoke a =E9crit :



2012/9/7 R=E9mi Despr=E9s= <despres.remi@laposte.net>

Le 2012-09-07 =E0 04:33, Maoke a =E9crit :
...
> as we are talking about a BCP, if 464xlat doc states BIH is an = indispensible part of the standard, our customers will require us to = definitely provide such a function or such an option rather than any = other alternatives in the service suite. i doubt this is the common = floor the working group is on.
...

1. Stating that a combining 464XLAT with BIH is "possible" isn't stating = it is "indispensable". 
2. Being part of a a "BCP" isn't being part of a "standard".
3. Authors initially wrote "It is also possible to provide single = IPv4/IPv6 translation service, which will be needed in the future case = of IPv6-only servers and peers to be reached from legacy IPv4-only = hosts." The added BIH reference better covers the original intent, by = just stating a fact useful to be known.
=
 
(#)  following point is = emphasized
 
it = is interesting. i don't think the authors were originally = intent to involve a helper for providing "single = IPv4/IPv6 translation service". and surely the phrase is correct, = because CLAT supports IPv4/IPv6 single translation without need anything = more once the addressing support statelessness; it is also happens = between an IPv4 host in the Internet having access to the native IPv6 = server through the PLAT.
 
adding the BIH, is actually adding another = solution to the CLAT box for another problem, heavily = biased from the original intent which contains CLAT stateless = single translation service and the PLAT stateful translation service. =

The current sentence has been coined by = authors themselves. 
It is therefore, presumably, = compatible with their original intent.

I would = really prefer to hear from you about 464XLAT with /64 delegated prefixes = (and no NAT44 to be completely stateless), assuming you are also = interested in _technical choices_ to be made before = publication.


RD




=
 
<= div> 
(/#) end of emphasis 
Confirmed stand:
- At a time when there are still discussions on functional aspects of = 464XLAT, this particular discussion is IMHO a waste of = time
 
scope and problem is more = important than solution. waste of time is not an execuse of passing = misleading and confused sentences.

The sentence is AFAIK = neither misleading nor confused.
Yes, 464XLAT and BIH have = complementary targets and can usefully be = combined.
 
 
AFAIK the sentence is misleading. 464 target is = clearly described in Section 2. the original intent of mentioning the = IPv4/IPv6 single translation was not a target, IMHO, but a natural = result. it is fine not to include the original intent if we think that = is out of scope. it is also fine to include that if we think that = non-normative.
 
but replacing the original intent with statement = on BIH actually made things different. see my (#) that is = emphasized above.
 
i may change the = question: what BIH can gain from being combined with 464xlat? = anything?
 
- maoke
 
 
Just stating a preference (my right I = suppose). 

RD


<= blockquote type=3D"cite">
 
- maoke



= --Apple-Mail-25--667110215-- From lorenzo@google.com Fri Sep 7 01:45:13 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C46AC21F8692 for ; Fri, 7 Sep 2012 01:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.744 X-Spam-Level: X-Spam-Status: No, score=-102.744 tagged_above=-999 required=5 tests=[AWL=-0.068, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSmT6qykFXrT for ; Fri, 7 Sep 2012 01:45:12 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id AD3B121F8669 for ; Fri, 7 Sep 2012 01:45:12 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so4535232obb.31 for ; Fri, 07 Sep 2012 01:45:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=ZNE+JQdcjSnw8qxNunJ0Cp43m7Heq/12vubr2aYChlI=; b=hnBSLC8lSs5FhbrKCGdn6++IijjcukWceoRHWbW8kxKBpOxeKrVd75O/vy3SRgaAQW lKASwJxHHXlwNs9B+tXVFMs9Lw9haCPhECplOAhrD0gG2g/kpBANZwPFHHPspDO5ovUw KXcUPLyj1bqudhWAkF5dowiqU6qW/AcdcWQZX9wTomC8bOcfZ4tYn2MFaYD3cF+KdhW6 iKMyKCj/CyQIyHyeKTqVU43/LTfcWvRzX/95QOGzNUVeZxMyJLKlHCpfW0s0+u1xa5ZG y0MrXHE8jH7HUfQon04LI77oXKzT2rfOCjKz2P71EbOGodwajgwF7z0cPNpfkIzPys66 mAPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=ZNE+JQdcjSnw8qxNunJ0Cp43m7Heq/12vubr2aYChlI=; b=gqfDNafFvXiWXx+rQPu5TVw0+DGJE/KL0+xHWCYKmj9nm7ju8fh+IPEdjpS9Oba+K9 qCb4x+HGUvEohBEKBWHLYjfXN2yqFRbjQJIlveng5qieV55qQ2b+dH1g01gVGs3pcB5l ZsuUEFTgqESSCAf7bM+XEs1me9BsNpZStrETGHq76XoyTbU0SBZY9vaooI3pyZ9590BW Z3cBiqlglt9EMh2VatruOhTUgGeSun5jFcLWVFaic+biDteBLdt8xoWGY76xumQymNpn PcqdK+V1LP9F4OjBH6iw7xFAth03DB2CZxhdXvd41HUY5qTME2gZvKbU4qHCuS83+wJy 7zvw== Received: by 10.182.110.40 with SMTP id hx8mr4908212obb.47.1347007512154; Fri, 07 Sep 2012 01:45:12 -0700 (PDT) Received: by 10.182.110.40 with SMTP id hx8mr4908203obb.47.1347007512057; Fri, 07 Sep 2012 01:45:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.187.8 with HTTP; Fri, 7 Sep 2012 01:44:51 -0700 (PDT) In-Reply-To: <3C325619-F078-48A2-A8B4-3A9666DF0498@laposte.net> References: <5049A1AF.9080202@gmail.com> <3C325619-F078-48A2-A8B4-3A9666DF0498@laposte.net> From: Lorenzo Colitti Date: Fri, 7 Sep 2012 17:44:51 +0900 Message-ID: To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=f46d044516dd44184c04c918a0c1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnCkJiBbB7CTLFjgOyMYg36OiqiRI5WR5o/khm8WwTgZUme5drULMnF5IXV+FpK7gQK7uokjhsxwH1fND7REFHLOBmp3XMPoL17vS2q0r2kVtMLhSTPdhP4pZJrIIszETLOq0O/YmYm5oRErwD0SDaHt/NH5sSZK3YxFxBUU+7OpuK87p7BdTwu/8G4lwy6ZXmq9WgI Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 08:45:13 -0000 --f46d044516dd44184c04c918a0c1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Sep 7, 2012 at 4:59 PM, R=E9mi Despr=E9s = wrote: > Just noting that BIH is complementary in a draft that deals with a relate= d > issue isn't, IMHO, a problem that justifies this last minute attack of a > true statement. > It's not a last-minute attack, we have had this conversation before. One would imagine that last call is when unresolved disagreements need to be resolved. --f46d044516dd44184c04c918a0c1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Sep 7, 2012 at 4:59 PM, R=E9mi Despr=E9s <despres.remi@lapo= ste.net> wrote:
Just noting that BIH is complementary in a draft that deals with a related = issue isn't, IMHO, a problem that justifies this last minute attack of = a true statement.

It's not a last-m= inute attack, we have had this conversation before. One would imagine that = last call is when unresolved disagreements need to be resolved.
--f46d044516dd44184c04c918a0c1-- From fibrib@gmail.com Fri Sep 7 01:50:04 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E49821F86BE for ; Fri, 7 Sep 2012 01:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.208 X-Spam-Level: X-Spam-Status: No, score=-3.208 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LYDArYzWymDG for ; Fri, 7 Sep 2012 01:50:00 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id 6F37121F8709 for ; Fri, 7 Sep 2012 01:50:00 -0700 (PDT) Received: by wibhq12 with SMTP id hq12so329036wib.1 for ; Fri, 07 Sep 2012 01:49:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gSOdiCTeqUysFXuq+rlIVl5UGP8mbXx1Vgf9d2DovLA=; b=sDmAfgR4ZbUuBIWIngC+bkaxd53W7p1Ss3RhRfx1tfC2Aj52ugyWSDsjv9iwFXOvtQ AvYwdhd7lFV1UAJ+EOc3rhiiJ/syM/sNWLi5rUjEQm7dbtGZmiN4CE1ie54qVCUEdA7a ViWqeYHl1yvWcJ0PP2OpxDwS8E7bNT708TiAH6uK30lFVfFkkB9WeN/1+ONiv/1qYldj ey4keiwuLZ3vE2sFL2b7DOF9pUj8V0fQhV9yEUU7IwBjk6/lEzfxpBgrU/3bVc7po5St e8CFHhml8DqqD0j0pMYEWprXe7f/8+SKJ2qplMAW+D+zynirtNoDFwfKVhK9D1xNor1j ngiA== MIME-Version: 1.0 Received: by 10.180.79.229 with SMTP id m5mr10681139wix.13.1347007799462; Fri, 07 Sep 2012 01:49:59 -0700 (PDT) Received: by 10.223.37.78 with HTTP; Fri, 7 Sep 2012 01:49:59 -0700 (PDT) In-Reply-To: <9F02FD3E-46C5-4BBB-ACBB-BB59DD420F24@laposte.net> References: <47F98720-3E3F-4920-A890-A5FD10843F0D@laposte.net> <36B8743C-5758-4B7F-9C31-0A4CD02D772A@laposte.net> <9F02FD3E-46C5-4BBB-ACBB-BB59DD420F24@laposte.net> Date: Fri, 7 Sep 2012 17:49:59 +0900 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=f46d04182658658c4904c918b18e Cc: v6ops WG Subject: Re: [v6ops] 464XLAT and BIH X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 08:50:04 -0000 --f46d04182658658c4904c918b18e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/9/7 R=E9mi Despr=E9s > > Le 2012-09-07 =E0 10:18, Maoke a =E9crit : > > > > 2012/9/7 R=E9mi Despr=E9s > >> >> Le 2012-09-07 =E0 09:41, Maoke a =E9crit : >> >> >> >> 2012/9/7 R=E9mi Despr=E9s >> >>> >>> Le 2012-09-07 =E0 04:33, Maoke a =E9crit : >>> ... >>> > as we are talking about a BCP, if 464xlat doc states BIH is an >>> indispensible part of the standard, our customers will require us to >>> definitely provide such a function or such an option rather than any ot= her >>> alternatives in the service suite. i doubt this is the common floor the >>> working group is on. >>> ... >>> >>> 1. Stating that a combining 464XLAT with BIH is "possible" isn't statin= g >>> it is "indispensable". >> >> 2. Being part of a a "BCP" isn't being part of a "standard". >>> 3. Authors initially wrote "It is also possible to provide single >>> IPv4/IPv6 translation service, which will be needed in the future case = of >>> IPv6-only servers and peers to be reached from legacy IPv4-only hosts."= The >>> added BIH reference better covers the original intent, by just stating = a >>> fact useful to be known. >>> >> > (#) following point is emphasized > >> >> it is interesting. i don't think the authors were originally intent to >> involve a helper for providing "single IPv4/IPv6 translation service". a= nd >> surely the phrase is correct, because CLAT supports IPv4/IPv6 single >> translation without need anything more once the addressing support >> statelessness; it is also happens between an IPv4 host in the Internet >> having access to the native IPv6 server through the PLAT. >> >> adding the BIH, is actually adding another solution to the CLAT box for >> another problem, heavily biased from the original intent which contains >> CLAT stateless single translation service and the PLAT stateful translat= ion >> service. >> >> > The current sentence has been coined by authors themselves. > It is therefore, presumably, compatible with their original intent. > > i also didn't notice that there was actually the difference. so i will appreciate if the authors may clarify. > > I would really prefer to hear from you about 464XLAT with /64 delegated > prefixes (and no NAT44 to be completely stateless), assuming you are also > interested in _technical choices_ to be made before publication. > > i do not yet catch up in understanding the problem comprehensively of that thread and i must firstly identify if my use-case fits that scenario. i will do that as soon as possible. - maoke > > RD > > > > > >> >> > (/#) end of emphasis > >> Confirmed stand: >>> - At a time when there are still discussions on functional aspects of >>> 464XLAT, this particular discussion is IMHO a waste of time >>> >> >> scope and problem is more important than solution. waste of time is not >> an execuse of passing misleading and confused sentences. >> >> >> The sentence is AFAIK neither misleading nor confused. >> Yes, 464XLAT and BIH have complementary targets and can usefully be >> combined. >> >> > > AFAIK the sentence is misleading. 464 target is clearly described in > Section 2. the original intent of mentioning the IPv4/IPv6 single > translation was not a target, IMHO, but a natural result. it is fine not = to > include the original intent if we think that is out of scope. it is also > fine to include that if we think that non-normative. > > but replacing the original intent with statement on BIH actually made > things different. see my (#) that is emphasized above. > > i may change the question: what BIH can gain from being combined with > 464xlat? anything? > > - maoke > > >> >> Just stating a preference (my right I suppose). >> >> RD >> >> >> >> - maoke >> >> >> > > --f46d04182658658c4904c918b18e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/9/7 R=E9mi Despr=E9s <despr= es.remi@laposte.net>

Le 2012-09-07 =E0 10:18, = Maoke a =E9crit :


=
2012/9/7 R=E9mi Despr=E9s = <despres.r= emi@laposte.net>

Le 2012-09-07 =E0 09:41, = Maoke a =E9crit :



2012/9/7 R=E9mi Despr=E9s <despres.remi@lapo= ste.net>

Le 2012-09-07 =E0 04:33, Maoke a =E9crit :
...
> as we are talking about a BCP, if 464xlat doc states BIH is an indispe= nsible part of the standard, our customers will require us to definitely pr= ovide such a function or such an option rather than any other alternatives = in the service suite. i doubt this is the common floor the working group is= on.
...

1. Stating that a combining 464XLAT with BIH is "possible" isn= 9;t stating it is "indispensable".=A0
2. Being part of a a "BCP" isn't being part of a "standa= rd".
3. Authors initially wrote "It is also possible to provide single IPv4= /IPv6 translation service, which will be needed in the future case of IPv6-= only servers and peers to be reached from legacy IPv4-only hosts." The= added BIH reference better covers the original intent, by just stating a f= act useful to be known.
=A0
(#) =A0following point is emphasized
=A0
it is=A0interesting.=A0i do= n't think the authors=A0were originally intent to involve=A0a helper=A0= for=A0providing "single IPv4/IPv6 translation service". and surel= y the phrase is correct, because CLAT supports IPv4/IPv6 single translation= without need anything more once the addressing support statelessness; it i= s also happens between an IPv4 host in the Internet having access to the na= tive IPv6 server through the PLAT.
=A0
adding the BIH, is actually adding another solution=A0to= the CLAT box=A0for another problem,=A0heavily biased=A0from the=A0original= intent which contains CLAT stateless single translation service and the PL= AT stateful translation service.
=

The current sentence has been coined by authors t= hemselves.=A0
It is therefore, presumably, compatible with their = original intent.
=A0
=A0
i also didn't= notice that there was actually the difference. so=A0i will appreciate if t= he authors may clarify.
=A0
=A0
I would really = prefer to hear from you about 464XLAT with /64 delegated prefixes (and no N= AT44 to be completely stateless), assuming you are also interested in _tech= nical choices_ to be made before publication.
=A0
=
=A0
i do not yet catch up in unders= tanding the problem comprehensively of that thread and i=A0must firstly ide= ntify if my use-case fits that scenario. i will do that as soon as possible= .
=A0
- maoke
=A0

RD




=
=A0
= =A0
(/#) end of emphasis=A0
Confirmed stand:
- At a time when there are still discussions on functional aspects of 464XL= AT, this particular discussion is IMHO a waste of time
=A0
scope and problem is more important than solution. waste of = time is not an execuse of passing misleading and confused=A0sentences.

The sentence is AFAIK neither= misleading nor confused.
Yes, 464XLAT and BIH have complementary= targets and can usefully be combined.
=A0
=A0
AFAIK the sentence is misleading. 464 target is clearly = described in Section 2. the original intent of mentioning the IPv4/IPv6 sin= gle translation was not a target, IMHO, but a natural result. it is fine no= t to include the original intent if we think that is out of scope. it is al= so fine to include that if we think that non-normative.
=A0
but replacing the original intent with statement on BIH = actually made things different. see my (#) that is emphasized=A0above.
=A0
i may change the question: what BIH can gain from bein= g combined with 464xlat? anything?
=A0
- maoke
=A0
=A0
Just stating a preference (my right I suppose).=A0
=

RD


=A0
- maoke




--f46d04182658658c4904c918b18e-- From fibrib@gmail.com Fri Sep 7 01:53:10 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD95821F8687 for ; Fri, 7 Sep 2012 01:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.045 X-Spam-Level: X-Spam-Status: No, score=-3.045 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LTtnIzFz-hpx for ; Fri, 7 Sep 2012 01:53:10 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 837B521F8686 for ; Fri, 7 Sep 2012 01:53:09 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so1505406wgb.13 for ; Fri, 07 Sep 2012 01:53:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=35gKiWmUq7C//KgUj+mSlXnopjsLOmsKl/wCI1HmdR0=; b=C3MG7kZfaYcBpqsMBXkX8or0eYNThM228LkAgZhdIzbi6gf6CsNJyPKRSFHtnXWAyY TY1d9fDUm0eaWEsNp8Cyujx1us4+4dAuHXoFSQPiAeYTBf7833qm8W0S6L1sJI0hSVFK zryLZJ66uxoyfzywdjWCEXNuz4qMqDuhI2Azrdr/eSQrWpg9Vv9fhk1C4NxFGbbdiFhB zMpWuU/52Yf+gCviCfuTIyzPukQQfLWsNtXNV6AtW0DqXxm2S48xT4iFBGZwARMs0uTD IxsvFx79v6Zow/ejeDtS+wYrArsNTyz8qC1PoYjsFl14xBz5Zks4jIS6A7HyCu0MXUfE TVGQ== MIME-Version: 1.0 Received: by 10.180.83.66 with SMTP id o2mr10685736wiy.14.1347007988691; Fri, 07 Sep 2012 01:53:08 -0700 (PDT) Received: by 10.223.37.78 with HTTP; Fri, 7 Sep 2012 01:53:08 -0700 (PDT) In-Reply-To: References: <47F98720-3E3F-4920-A890-A5FD10843F0D@laposte.net> <36B8743C-5758-4B7F-9C31-0A4CD02D772A@laposte.net> <9F02FD3E-46C5-4BBB-ACBB-BB59DD420F24@laposte.net> Date: Fri, 7 Sep 2012 17:53:08 +0900 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=f46d04428e42acf1b604c918bc6c Cc: v6ops WG Subject: Re: [v6ops] 464XLAT and BIH X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 08:53:10 -0000 --f46d04428e42acf1b604c918bc6c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/9/7 Maoke > > > 2012/9/7 R=E9mi Despr=E9s > >> >> Le 2012-09-07 =E0 10:18, Maoke a =E9crit : >> >> >> >> 2012/9/7 R=E9mi Despr=E9s >> >>> >>> Le 2012-09-07 =E0 09:41, Maoke a =E9crit : >>> >>> >>> >>> 2012/9/7 R=E9mi Despr=E9s >>> >>>> >>>> Le 2012-09-07 =E0 04:33, Maoke a =E9crit : >>>> ... >>>> > as we are talking about a BCP, if 464xlat doc states BIH is an >>>> indispensible part of the standard, our customers will require us to >>>> definitely provide such a function or such an option rather than any o= ther >>>> alternatives in the service suite. i doubt this is the common floor th= e >>>> working group is on. >>>> ... >>>> >>>> 1. Stating that a combining 464XLAT with BIH is "possible" isn't >>>> stating it is "indispensable". >>> >>> 2. Being part of a a "BCP" isn't being part of a "standard". >>>> 3. Authors initially wrote "It is also possible to provide single >>>> IPv4/IPv6 translation service, which will be needed in the future case= of >>>> IPv6-only servers and peers to be reached from legacy IPv4-only hosts.= " The >>>> added BIH reference better covers the original intent, by just stating= a >>>> fact useful to be known. >>>> >>> >> (#) following point is emphasized >> >>> >>> it is interesting. i don't think the authors were originally intent to >>> involve a helper for providing "single IPv4/IPv6 translation service". = and >>> surely the phrase is correct, because CLAT supports IPv4/IPv6 single >>> translation without need anything more once the addressing support >>> statelessness; it is also happens between an IPv4 host in the Internet >>> having access to the native IPv6 server through the PLAT. >>> >>> adding the BIH, is actually adding another solution to the CLAT box for >>> another problem, heavily biased from the original intent which contains >>> CLAT stateless single translation service and the PLAT stateful transla= tion >>> service. >>> >>> >> The current sentence has been coined by authors themselves. >> It is therefore, presumably, compatible with their original intent. >> >> > > i also didn't notice that there was actually the difference. so i will > appreciate if the authors may clarify. > i mean i was not aware of that until recently. - maoke > > >> >> I would really prefer to hear from you about 464XLAT with /64 delegated >> prefixes (and no NAT44 to be completely stateless), assuming you are als= o >> interested in _technical choices_ to be made before publication. >> >> > > i do not yet catch up in understanding the problem comprehensively of tha= t > thread and i must firstly identify if my use-case fits that scenario. i > will do that as soon as possible. > > - maoke > > >> >> RD >> >> >> >> >> >>> >>> >> (/#) end of emphasis >> >>> Confirmed stand: >>>> - At a time when there are still discussions on functional aspects of >>>> 464XLAT, this particular discussion is IMHO a waste of time >>>> >>> >>> scope and problem is more important than solution. waste of time is not >>> an execuse of passing misleading and confused sentences. >>> >>> >>> The sentence is AFAIK neither misleading nor confused. >>> Yes, 464XLAT and BIH have complementary targets and can usefully be >>> combined. >>> >>> >> >> AFAIK the sentence is misleading. 464 target is clearly described in >> Section 2. the original intent of mentioning the IPv4/IPv6 single >> translation was not a target, IMHO, but a natural result. it is fine not= to >> include the original intent if we think that is out of scope. it is also >> fine to include that if we think that non-normative. >> >> but replacing the original intent with statement on BIH actually made >> things different. see my (#) that is emphasized above. >> >> i may change the question: what BIH can gain from being combined with >> 464xlat? anything? >> >> - maoke >> >> >>> >>> Just stating a preference (my right I suppose). >>> >>> RD >>> >>> >>> >>> - maoke >>> >>> >>> >> >> > --f46d04428e42acf1b604c918bc6c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/9/7 Maoke <fibrib@gmail.com>=


2012/9/7 R=E9mi Despr= =E9s <despres.remi@laposte.net>

Le 2012-09-07 =E0 10:18, = Maoke a =E9crit :



2012/9/7 R=E9mi Despr=E9s <despres.remi@laposte= .net>

Le 2012-09-07 =E0 09:41, = Maoke a =E9crit :



2012/9/7 R=E9mi Despr=E9s <despres.remi@lapo= ste.net>

Le 2012-09-07 =E0 04:33, Maoke a =E9crit :
...
> as we are talking about a BCP, if 464xlat doc states BIH is an indispe= nsible part of the standard, our customers will require us to definitely pr= ovide such a function or such an option rather than any other alternatives = in the service suite. i doubt this is the common floor the working group is= on.
...

1. Stating that a combining 464XLAT with BIH is "possible" isn= 9;t stating it is "indispensable".=A0
2. Being part of a a "BCP" isn't being part of a "standa= rd".
3. Authors initially wrote "It is also possible to provide single IPv4= /IPv6 translation service, which will be needed in the future case of IPv6-= only servers and peers to be reached from legacy IPv4-only hosts." The= added BIH reference better covers the original intent, by just stating a f= act useful to be known.
=A0
(#) =A0following point is emphasized
=A0
it is=A0interesting.=A0i do= n't think the authors=A0were originally intent to involve=A0a helper=A0= for=A0providing "single IPv4/IPv6 translation service". and surel= y the phrase is correct, because CLAT supports IPv4/IPv6 single translation= without need anything more once the addressing support statelessness; it i= s also happens between an IPv4 host in the Internet having access to the na= tive IPv6 server through the PLAT.
=A0
adding the BIH, is actually adding another solution=A0to= the CLAT box=A0for another problem,=A0heavily biased=A0from the=A0original= intent which contains CLAT stateless single translation service and the PL= AT stateful translation service.
=

The current sentence has been coined by authors t= hemselves.=A0
It is therefore, presumably, compatible with their = original intent.
=A0
=A0
i also didn= 't notice that there was actually the difference. so=A0i will appreciat= e if the authors may clarify.
=A0
i = mean i was not aware of that until recently. - maoke
=A0
=A0
=A0
I would really = prefer to hear from you about 464XLAT with /64 delegated prefixes (and no N= AT44 to be completely stateless), assuming you are also interested in _tech= nical choices_ to be made before publication.
=A0
=A0
i do not yet catch up in understanding the= problem comprehensively of that thread and i=A0must firstly identify if my= use-case fits that scenario. i will do that as soon as possible.
=A0
- maoke
=A0

RD
<= /font>




=A0
= =A0
(/#) end of emphasis=A0
Confirmed stand:
- At a time when there are still discussions on functional aspects of 464XL= AT, this particular discussion is IMHO a waste of time
=A0
scope and problem is more important than solution. waste of = time is not an execuse of passing misleading and confused=A0sentences.

The sentence is AFAIK neither= misleading nor confused.
Yes, 464XLAT and BIH have complementary= targets and can usefully be combined.
=A0
=A0
AFAIK the sentence is misleading. 464 target is clearly = described in Section 2. the original intent of mentioning the IPv4/IPv6 sin= gle translation was not a target, IMHO, but a natural result. it is fine no= t to include the original intent if we think that is out of scope. it is al= so fine to include that if we think that non-normative.
=A0
but replacing the original intent with statement on BIH = actually made things different. see my (#) that is emphasized=A0above.
=A0
i may change the question: what BIH can gain from bein= g combined with 464xlat? anything?
=A0
- maoke
=A0
=A0
Just stating a preference (my right I suppose).=A0
=

RD


=A0
- maoke





--f46d04428e42acf1b604c918bc6c-- From despres.remi@laposte.net Fri Sep 7 01:55:41 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84E8321F871E for ; Fri, 7 Sep 2012 01:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.49 X-Spam-Level: X-Spam-Status: No, score=-0.49 tagged_above=-999 required=5 tests=[AWL=-0.401, BAYES_20=-0.74, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VXDfdT2HwqeC for ; Fri, 7 Sep 2012 01:55:41 -0700 (PDT) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.19]) by ietfa.amsl.com (Postfix) with ESMTP id C8B3321F871A for ; Fri, 7 Sep 2012 01:55:40 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2318.sfr.fr (SMTP Server) with ESMTP id DB1C470002B5; Fri, 7 Sep 2012 10:55:39 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2318.sfr.fr (SMTP Server) with ESMTP id 84B02700019E; Fri, 7 Sep 2012 10:55:39 +0200 (CEST) X-SFR-UUID: 20120907085539543.84B02700019E@msfrf2318.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-26--666248045 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Fri, 7 Sep 2012 10:55:39 +0200 Message-Id: <29859876-163E-48E2-A3AE-04A7F50ABDD1@laposte.net> References: <5049A1AF.9080202@gmail.com> <3C325619-F078-48A2-A8B4-3A9666DF0498@laposte.net> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 08:55:41 -0000 --Apple-Mail-26--666248045 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-09-07 =E0 10:44, Lorenzo Colitti a =E9crit : > On Fri, Sep 7, 2012 at 4:59 PM, R=E9mi Despr=E9s = wrote: > Just noting that BIH is complementary in a draft that deals with a = related issue isn't, IMHO, a problem that justifies this last minute = attack of a true statement. >=20 > It's not a last-minute attack, we have had this conversation before. = One would imagine that last call is when unresolved disagreements need = to be resolved. This subject has AFAIK been stabilized for quite some time.=20 Newcomers make a big deal, now where hopefully WG conclusion is close, = of going backward by hiding a fact worth being known. Waste of time IMHO. RD --Apple-Mail-26--666248045 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On Fri, Sep 7, 2012 at 4:59 PM, R=E9mi Despr=E9s <despres.remi@laposte.net> wrote:
Just noting that BIH is complementary in a draft that deals with a = related issue isn't, IMHO, a problem that justifies this last minute = attack of a true statement.

It's not = a last-minute attack, we have had this conversation before. One would = imagine that last call is when unresolved disagreements need to be = resolved.

This subject has AFAIK been stabilized for = quite some time. 
Newcomers make a big deal, now where = hopefully WG conclusion is close, of going backward by hiding a fact = worth being known.
Waste of time = IMHO.

RD

= --Apple-Mail-26--666248045-- From phdgang@gmail.com Fri Sep 7 02:02:38 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F1E321F8567 for ; Fri, 7 Sep 2012 02:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.17 X-Spam-Level: X-Spam-Status: No, score=-3.17 tagged_above=-999 required=5 tests=[AWL=-0.171, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ytNcP5PZzH0l for ; Fri, 7 Sep 2012 02:02:37 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id EB48221F8593 for ; Fri, 7 Sep 2012 02:02:36 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so3097042vbb.31 for ; Fri, 07 Sep 2012 02:02:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=SaB4sx69P+CM2tqeM5/uRFq6BFCD1XK3R3XNwy3BM/g=; b=lvAN6BQLZfa9u8zEt1Dvz5GL2tIe54U8ZbdT1nxB75FuHf5uFUH57mZWkvtY8bedPj 2WjvedlbPNOIsn0LLqa/ZMtq7zKLm9/nhJsnjynAEb0Jhkymq3VT+B3jK6648cgwFmsP QEzPr35hCZZ0n6xyhARIkZ9f/+/tfG+6Mzgi0zapVDi0/abHn7GQIvAYIedZLDbEii8c uM1ya5CVGjyQPis3DaMLf1BBvxGP+xxwYFtYjLv9k20BHcb2/nfd+9Nbk7+DFCBU2hcO RMpdGqHznleDyrBbrSidckjhBECimsnmfLuMNxP/qLCR+crWpLtk7GwCmzmrBUqKXcKR PEjQ== MIME-Version: 1.0 Received: by 10.58.65.10 with SMTP id t10mr6820166ves.48.1347008548971; Fri, 07 Sep 2012 02:02:28 -0700 (PDT) Received: by 10.58.114.231 with HTTP; Fri, 7 Sep 2012 02:02:28 -0700 (PDT) In-Reply-To: References: Date: Fri, 7 Sep 2012 17:02:28 +0800 Message-ID: From: GangChen To: Maoke Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 09:02:38 -0000 2012/9/7, Maoke : > this item is what you are waiting for my reply to, right? see inline. > > 2012/9/6 GangChen > >> 2012/9/6, Maoke : >> > hi Gang, >> > >> > thanks for the links! >> > >> > 1. i don't think an early conclusion of the authors cannot be objected >> and >> > thought over again, before the last call is closed. >> >> Sure. If you do think several-months lasted discussion doesn't >> convince and would like to boil the ocean, we could re-open it. >> But please read the conversion happened before on the list to ensure >> new discussion is not backward. >> >> > 2. i don't think it is a loss to state out of scope (or not to mention >> that >> > at all) for IPv4-only app access to IPv6-only server. >> >> (*)Those arguments were discussed in the thread of "A way forward for >> 464XLAT - using BIH". >> The loss and gain have been well identified. The point is adding BIH >> only can be complementary to 464xlat scenario, no harm. >> If you have further point, please identify. >> > > putting a microwave oven on the top of a fridge has no harm at all, too. It's good to hear your confirmation on *NO harm* > my > point is simple: if 464xlat can solve the problem it identifies, then > things are enough. we don't need anything more, even the "anything" has > been standard No problem with 464xlat doing the best in 464. But the point is such 464 can't be guaranteed to be pure at different places and different times in the real life. *Mentioned* that can only be informative and benefit to reader. If we know the answer is good, why not do it? > unless we change the scope of the problem. No need. Please see my mail replying to Lorenzo. >> >> >> > this could be >> > achieved by simply configuring the IPv6-only server with an RFC6052 >> > IPv4-translatable address and relying CLAT RFC6145 translation, >> >> 1) The IPv4-Embedded IPv6 address on CLAT is inserted with IPv4 >> private address. > > When the two IPv4-embedded IPv6 addresses with conflicted IPv4 address >> talk to an IPv4-translatable IPv6 address, it would be failed since >> IPv6-only server is confused that outgoing packages should send to >> which CLAT. >> > > not very understand. conflicted IPv4 address either causes trouble or > running as anycast. what's the scope? The IPv4 embedded IPv6 address adopted by 464xlat is inserted with private IPv4 address. Those private IPv4 addresses are likely be same if two CLAT send packages to a IPv6 server. It's no problem with 464 communications because packages could be identified by different IPv6 prefixes. but it would be failed sending to a same IPv6 server, because replying packages can't distinguish which packages should send to which prefix. I hope you could understand. > >> 2) IPv6-only server with IPv4-translatable address would cause one >> public IPv4 address. >> Most people do IPv6 because IPv4 is limited, so doing this way does >> not really buy you anything. >> > > i (the server) may keep early customers from native IPv4 having access > without knowing that i have changed my protocol stack and meanwhile > increase my native IPv6-only customers. What I indicate is the needs to allocate the global IPv4 address to server. It's nothing to do native IPv4 customer. But you seems mean there is also need to customers assigning a global IPv4 address. It seems getting that worse. > >> 3) There no RFC stated the solution what you called as RFC6052+RFC6145; >> > > copied from RFC6145: > > Readers of this document are expected to have read and understood the > framework described in [RFC6144 ]. > Implementations of this IPv4/IPv6 > translation specification MUST also support the address translation > algorithms in [RFC6052 ]. > Implementations MAY also support stateful > translation [RFC6146 ]. > RFC6052 + RFC6145 is a MUST and both are standards. Please note RFC6145 is an algorithm block. There is no justification of scenario applicability > and RFC6219 gave you an example of using the both in the practice. RFC6219 is informational. According to RFC2026, "An "Informational" specification is published for the general information of the Internet community, and does not represent an Internet community consensus or recommendation. " But BIH is a standard. I guess what you have indentified is addressed totally. I guess we could agree BIH is best selction if IPv4-IPv6 mentioned? > >> whether that is a doable way need to be further justified. But BIH is >> a standard track >> > > >> >> > or by a >> > NAT64 located anywhere between the IPv4 app and the IPv6 domain >> implemented >> >> I don't get it. If there is NAT64, there is nothing to do with the >> scenario you are talking about. >> >> >> >> > in anyway not necessarily the socket layer solution, even though BIH >> > does >> > possibly work, by a proxy (ALG), etc. >> >> Please note RFC6535 has two flavors, i.e. header translation and >> socket translation. It=92s really not necessarily the socket layer >> solution. >> >> > 3. i don't think the author has tested the BIH with CLAT for an >> > IPv6-only >> > server, at least i have not seen any discussion/report from the author= s >> or >> > WG members about the test. >> >> (**)I guess you will see the report soon, because we are coding that >> right >> now. >> At this stage, what I can tell is most parts are same in the combining >> code. >> >> > to my understanding, the BIH/CLAT work here is >> > not yet practiced. why we need/should put a stuff not yet practiced >> > into >> a >> > BCP?? >> >> Please don't do the arbitrary objection even you didn't evaluate it. >> It is a strange logic. >> "I don't do that. I even don't know that. So I think that is not >> practiced." >> That is an unfair argument. >> >> > (NOTE, the test result from you only illustrates that BIH itself is >> > working, not the BIH/464xlat with IPv4-only app access to IPv6-only >> server. >> > the tested applications, skype, MSN, etc. are none of business of the >> > so-called IPv6-only servers). >> >> Please see the (**) and carefully read my report >> http://www.ietf.org/mail-archive/web/v6ops/current/msg12631.html >> The shared experiences are in 464 contexts. >> With 464xlat, we could easily do *combining 464XLAT with BIH*. >> It's of significance. >> > > i think i don't misunderstand anything about your report. i read through > the mail and also the doc of the testing. it is good but i think it said, > BIH is working, no matter there is 464xlat or not. No. What I reported is our experience of BIH because 464xlat is not appeared in that time. I have to do in the way if 464 is unavoidable, even it was recommended BIH should not work with NAT64 in RFC6535. With 464xlat it's really perfect for us to follow and it's approved that is a doable way and two technologies could benefit to each other. We share the experiences and confirmed by wg. Currently, you are coming here and say "Hi, I'm not happy with that for no technical reasons, please remove it" It's really unfair. >please identify the > benefit of having BIH working together with 464xlat, i.e., what we gain > through the combination rather than BIH and 464xlat themselves? 1) it gives the possibilities of 4-6 with a safe reference of standard trac= k 2)it facilitates IPv6-only deployment 3)it's complementary to support IPv4 application and etc. As I said it would be better if you could progress the work with the points that's didn't cover before Otherwise, we would repeat the show several months ago > more comprehensively, if 464xlat provides A, BIH provides B, and 464xlat = + > BIH provides A + B but nothing else, Please note A and B is closely realted. It has same goal/ mostly same code/ same strategie. A+B is doing a complete and concrete the use case to operators. > then i insist that it is not necessary > to cite BIH in 464xlat at all. That is surly known, even whatever happned in the wg and whatever we are discussing. Fortunately, it's approved that the adding BIH is no technial harm after our discussion. What needing clarification is already said on the list unless you create an new point. I intended to agree Remi comments - At a time when there are still discussions on functional aspects of 464XLAT, this particular discussion is IMHO a waste of time - Preferred approach: keep the sentence, and proceed. BRs Gang > > - maoke > > >> >> > 4. i was even confused by the text "By combining 464XLAT with BIH >> > [RFC6535], it is also possible to provide single IPv4/IPv6 translation >> > service" itself. BIH has done the single IPv4/IPv6 translation right? >> what >> > is the significance of such a "combination"? what is the add-on? >> >> Same comment with (*). If you have concrete point, please identify. >> Ambiguous arguments and arbitrary objections only can waste our energy >> and time. It doesn't help the document imho. >> >> > integrating the compressor, condenser, expansion valve, evaporator int= o >> > a >> > fridge is an innovation (as the authors did for the 464xlat) but we >> cannot >> > call a "fridge + microwave oven put on the top of the fridge" a new >> > "architecture" of better practice. >> >> I didn't fully get your point. 464xlat is not a fridge actually :) >> Again, please directly identify your technical points/concerns. >> >> >> BRs >> >> Gang >> >> >> >> > - maoke >> > >> > 2012/9/6 GangChen >> > >> >> 2012/9/6, Maoke : >> >> > another objection is, Section 9 states "another, >> >> > if combined with BIH [RFC6535 > >], >> >> is >> >> > a IPv4 -> IPv6 translation for >> >> > reaching IPv6-only servers from IPv4-only clients that can not >> >> > support IPv6. " >> >> > >> >> > it sounds to me that 464xlat does suggest to apply BIH, as part of >> >> > the >> >> best >> >> > practice, for IPv4 client reaching IPv6-only servers. to my >> >> understanding, >> >> > there could be several alternative ways to achieve that, why we >> >> > should >> >> > be >> >> > bounded with BIH? >> >> > >> >> > sorry i didn't catch the discussion on this issue before. >> >> >> >> There was a quite long discussion, >> >> since you didn't follow that, I list the links below for your >> >> convenience. >> >> >> >> "A way forward for 464XLAT", started with >> >> http://www.ietf.org/mail-archive/web/v6ops/current/msg12521.html >> >> "A way forward for 464XLAT - using BIH", started with >> >> http://www.ietf.org/mail-archive/web/v6ops/current/msg12631.html >> >> "I-D Action: draft-ietf-v6ops-464xlat-02.txt" started with >> >> http://www.ietf.org/mail-archive/web/v6ops/current/msg12628.html >> >> " [v6ops] draft-ietf-v6ops-464xlat - which status?"started with >> >> http://www.ietf.org/mail-archive/web/v6ops/current/msg13035.html >> >> .... >> >> >> >> As Cameron indicated *The conclusion was that the 464XLAT is more >> >> complete by making a reference to BIH scenario.* >> >> >> >> BRs >> >> >> >> Gang >> >> >> >> >> >> > >> >> > 2012/8/22 Fred Baker (fred) >> >> > >> >> >> I should note that the current thread has a subject line reading >> >> -06.txt, >> >> >> but the current version is -07.txt. You may find the diffs (fairly >> >> >> extensive) at >> >> >> >> >> >> http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-464xlat-07.t= xt >> >> >> >> >> >> >> >> >> On Aug 21, 2012, at 8:45 AM, Fred Baker (fred) wrote: >> >> >> >> >> >> > This is to open a two week Working Group last Call on >> >> >> > >> >> >> > http://tools.ietf.org/html/draft-ietf-v6ops-464xlat >> >> >> > "464XLAT: Combination of Stateful and Stateless Translation", >> >> Masataka >> >> >> > Mawatari, Masanobu Kawashima, Cameron Byrne, 19-Aug-12 >> >> >> > >> >> >> > Please read it now. We are interested in, among other things, >> >> technical >> >> >> commentary on the draft and the working group's perception on its >> >> >> usefulness to its target audience. >> >> >> > _______________________________________________ >> >> >> > v6ops mailing list >> >> >> > v6ops@ietf.org >> >> >> > https://www.ietf.org/mailman/listinfo/v6ops >> >> >> >> >> >> ---------------------------------------------------- >> >> >> The ignorance of how to use new knowledge stockpiles exponentially= . >> >> >> - Marshall McLuhan >> >> >> >> >> >> _______________________________________________ >> >> >> v6ops mailing list >> >> >> v6ops@ietf.org >> >> >> https://www.ietf.org/mailman/listinfo/v6ops >> >> >> >> >> > >> >> >> > >> > From lorenzo@google.com Fri Sep 7 02:30:32 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5C1C21F8703 for ; Fri, 7 Sep 2012 02:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.888 X-Spam-Level: X-Spam-Status: No, score=-102.888 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id veLlJP0ZFs6i for ; Fri, 7 Sep 2012 02:30:32 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2B2C121F86F4 for ; Fri, 7 Sep 2012 02:30:32 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so4607996obb.31 for ; Fri, 07 Sep 2012 02:30:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=XRagIXzAjfFstry/9B2yq7+lJuWqg2lAWONbr17r+Q4=; b=P1nmTfcCE3GJZ1PclI3zaGHu1ghwEL/65Ih5YrS71bz1kHvPuAyAJ3ilytvl9gLHvc e3UJ9JXejFbqNtZF3SwaAwdUqKmw9vQ8JvNJcSbssdvhgnV5l4IW8S5H3dzYtu0atVOS fgIj1Gx5VV3jCT9/+tUo6rG/71Vb1ehTuEJhgqS/yfKvgy3u6Iu8xccIxmay41WuubcA OqYmJlmBLHEyT6zM2/yTjMghPOY7rUJ3aSVkrG/6/YIG9nncu1pSG5e0Ps16LzXc/pDD OCKwsaAo84GxV08ehlr+bEYFAZcD7h74eQzNmlDTF/VczXtGJaLJoZg44hWQd04grNUJ sf5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=XRagIXzAjfFstry/9B2yq7+lJuWqg2lAWONbr17r+Q4=; b=fiLw/xHlzoYiMT9DKEu3bGxp4yRUxRt96FbQnrtBToKwVMYND5pt5bEExMzDop8gXI EcC2BKBb0vLa/54dgee7yvUctOUQrOhd/pTU3X1X1Fb+nv0RtT0c99YeVK8ZiCf0vKY7 OHS47NgNIo5NF2UL6x/y7VE5V+7eRiVk/G+Ocur+vy6F6jbeGFfu2gt0rXKlR1nynURS gUC2YbbDEld+qBOf6gWnI7qqlH8rZrgLjz81UoLd/x8/cohgzQzgKRZpfIRvBaf8WoCN x+x9C4bMkpyK8YFMVqk84yuT1E75P4OpBl7yPyQvCmHr8aHfBB2ad8bBitkINWNkAKQu oF6g== Received: by 10.182.1.72 with SMTP id 8mr4963372obk.61.1347010231769; Fri, 07 Sep 2012 02:30:31 -0700 (PDT) Received: by 10.182.1.72 with SMTP id 8mr4963361obk.61.1347010231647; Fri, 07 Sep 2012 02:30:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.187.8 with HTTP; Fri, 7 Sep 2012 02:30:11 -0700 (PDT) In-Reply-To: References: From: Lorenzo Colitti Date: Fri, 7 Sep 2012 18:30:11 +0900 Message-ID: To: GangChen Content-Type: multipart/alternative; boundary=f46d04462fe05dbdb104c9194250 X-System-Of-Record: true X-Gm-Message-State: ALoCoQln9b1+/czu86C3tPGAVHCkaf/zn8PGq/DytJ2qdpAFbTmqhiSGHc8WIeV+n3QDqT9aqzD26XFabRFF3/sDvHRPPDWIMf3rXmUAN5Q1cENlgwKHY4TuXWbZYHHY8uQkxVYVfXkjc3+ogdN9T5TiFTs0wkUKjvdM4R1382Blg65WcPc/4NCGsHIzJruilu68tYlda3Hs Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 09:30:32 -0000 --f46d04462fe05dbdb104c9194250 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Sep 7, 2012 at 6:02 PM, GangChen wrote: > No. What I reported is our experience of BIH because 464xlat is not > appeared in that time. > I have to do in the way if 464 is unavoidable, even it was recommended > BIH should not work with NAT64 in RFC6535. > With 464xlat it's really perfect for us to follow and it's approved > that is a doable way and two technologies could benefit to each other. > We share the experiences and confirmed by wg. > Currently, you are coming here and say "Hi, I'm not happy with that > for no technical reasons, please remove it" > It's really unfair. > But mentioning BIH in this document, when there are other ways for IPv4-only clients to talk to IPv6-only servers (e.g., transparent proxies) is unfair as well. If we want this document to include technologies to get IPv4-only clients to communicate with IPv6-only servers, then we should include those other ways as well. > more comprehensively, if 464xlat provides A, BIH provides B, and 464xlat + > > BIH provides A + B but nothing else, > > Please note A and B is closely realted. It has same goal/ mostly same > code/ same strategie. > A+B is doing a complete and concrete the use case to operators. > I disagree that they are closely related. They are different problems, that need to be solved on different timescales, using completely different technologies. Problem A (IPv4-only application on IPv6-only network) is a problem that operators are facing now. Problem B (IPv4-only client to IPv6-only server) is not currently a problem at all. We should not mix the two. --f46d04462fe05dbdb104c9194250 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Sep 7, 2012 at 6:02 PM, GangChen <phdgang@gmail.com>= wrote:
No. What I reported is our experience of BIH because 464xlat is not
appeared in that time.
I have to do in the way if 464 is unavoidable, even it was recommended
BIH should not work with NAT64 in RFC6535.
With 464xlat it's really perfect for us to follow and it's approved=
that is a doable way and two technologies could benefit to each other.
We share the experiences and confirmed by wg.
Currently, you are coming here and say "Hi, I'm not happy with tha= t
for no technical reasons, please remove it"
It's really unfair.

But mentioning = BIH in this document, when there are other ways for IPv4-only clients to ta= lk to IPv6-only servers (e.g., transparent proxies) is unfair as well.=A0If= we want this document to include technologies to get IPv4-only clients to = communicate with IPv6-only servers, then we should include those other ways= as well.

> more c= omprehensively, if 464xlat provides A, BIH provides B, and 464xlat +
> BIH provides A + B but nothing else,

Please note A and B is closely realted. It has same goal/ mostly same=
code/ same strategie.
A+B is doing a complete and concrete the use case to operators.

I disagree that they are closely related. They are= different problems, that need to be solved on different timescales, using = completely different technologies. Problem A (IPv4-only application on IPv6= -only network) is a problem that operators are facing now. Problem B (IPv4-= only client to IPv6-only server) is not currently a problem at all. We shou= ld not mix the two.
--f46d04462fe05dbdb104c9194250-- From fibrib@gmail.com Fri Sep 7 02:31:59 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 253C221F8769 for ; Fri, 7 Sep 2012 02:31:59 -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.218, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fXOt5vWr3Yby for ; Fri, 7 Sep 2012 02:31:57 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 99A4F21F876A for ; Fri, 7 Sep 2012 02:31:56 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so1523333wgb.13 for ; Fri, 07 Sep 2012 02:31:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=J56ybVE7AfLR6uhESTL1vr3Q9efuzI3cBxx3F/aGpek=; b=vzbvjnunAUtrJXwNuRIfAukET0WvHkRK18gi79MA6K6xFCIboJpFSiCuIfearjnC4c hbMEVUOO9ks8V91YNZkOFBhkiGxTFNcGt7pmMAy52v38INmVX1k4L+fiTZ1l17M87dU4 HiSgPznDthpvepbRqKfOeSe+LgIdL2QjOWSlXfHu4gQMR6ijOjLqJODNQ9U5afocV8ov VZWXa3mBTPET07P60OGNK7TAT2xtfuR2rgzv9SBOiTdwVbFHKT0sRU9LQgm/+OHDN6+p UYXZ0BWN0tImj7Vg+dtdAC3QBkeaaU+NZwL9xThC+6igu7qqsOjMqj/11Ben5hchstiF uN8A== MIME-Version: 1.0 Received: by 10.180.79.229 with SMTP id m5mr10928460wix.13.1347010315608; Fri, 07 Sep 2012 02:31:55 -0700 (PDT) Received: by 10.223.37.78 with HTTP; Fri, 7 Sep 2012 02:31:55 -0700 (PDT) In-Reply-To: References: Date: Fri, 7 Sep 2012 18:31:55 +0900 Message-ID: From: Maoke To: GangChen Content-Type: multipart/alternative; boundary=f46d041826585ee19004c9194741 Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 09:31:59 -0000 --f46d041826585ee19004c9194741 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 2012/9/7 GangChen > 2012/9/7, Maoke : > > this item is what you are waiting for my reply to, right? see inline. > > > > 2012/9/6 GangChen > > > >> 2012/9/6, Maoke : > >> > hi Gang, > >> > > >> > thanks for the links! > >> > > >> > 1. i don't think an early conclusion of the authors cannot be object= ed > >> and > >> > thought over again, before the last call is closed. > >> > >> Sure. If you do think several-months lasted discussion doesn't > >> convince and would like to boil the ocean, we could re-open it. > >> But please read the conversion happened before on the list to ensure > >> new discussion is not backward. > >> > >> > 2. i don't think it is a loss to state out of scope (or not to menti= on > >> that > >> > at all) for IPv4-only app access to IPv6-only server. > >> > >> (*)Those arguments were discussed in the thread of "A way forward for > >> 464XLAT - using BIH". > >> The loss and gain have been well identified. The point is adding BIH > >> only can be complementary to 464xlat scenario, no harm. > >> If you have further point, please identify. > >> > > > > putting a microwave oven on the top of a fridge has no harm at all, too= . > > It's good to hear your confirmation on *NO harm* > but we never see a fridge specification states or suggests: if you put your oven on the top of the fridge, you can have icecream and meanwhile roast your chicken. :P terrible specification if i have. > > > > my > > point is simple: if 464xlat can solve the problem it identifies, then > > things are enough. we don't need anything more, even the "anything" has > > been standard > > No problem with 464xlat doing the best in 464. But the point is such > 464 can't be guaranteed to be pure at different places and different > times in the real life. *Mentioned* that can only be informative and > benefit to reader. If we know the answer is good, why not do it? > as Lorenzo mentioned, we haven't confirm the answer is good or the best. as Brian pointed out, it is too premature to talk about this. why should we do it? > > > unless we change the scope of the problem. > > No need. Please see my mail replying to Lorenzo. > > >> > >> > >> > this could be > >> > achieved by simply configuring the IPv6-only server with an RFC6052 > >> > IPv4-translatable address and relying CLAT RFC6145 translation, > >> > >> 1) The IPv4-Embedded IPv6 address on CLAT is inserted with IPv4 > >> private address. > > > > When the two IPv4-embedded IPv6 addresses with conflicted IPv4 address > >> talk to an IPv4-translatable IPv6 address, it would be failed since > >> IPv6-only server is confused that outgoing packages should send to > >> which CLAT. > >> > > > > not very understand. conflicted IPv4 address either causes trouble or > > running as anycast. what's the scope? > > The IPv4 embedded IPv6 address adopted by 464xlat is inserted with > private IPv4 address. > Those private IPv4 addresses are likely be same if two CLAT send > packages to a IPv6 server. > It's no problem with 464 communications because packages could be > identified by different IPv6 prefixes. > but it would be failed sending to a same IPv6 server, because replying > packages can't distinguish which packages should send to which prefix. > I hope you could understand. > no. i don't know why the IPv6 server cannot distiguish the sources having different IPv6 prefixes. > > > > > >> 2) IPv6-only server with IPv4-translatable address would cause one > >> public IPv4 address. > >> Most people do IPv6 because IPv4 is limited, so doing this way does > >> not really buy you anything. > >> > > > > i (the server) may keep early customers from native IPv4 having access > > without knowing that i have changed my protocol stack and meanwhile > > increase my native IPv6-only customers. > > What I indicate is the needs to allocate the global IPv4 address to > server. It's nothing to do native IPv4 customer. But you seems mean > there is also need to customers assigning a global IPv4 address. It > seems getting that worse. > you misunderstood. i mean v4private client -> CLAT -> v6 server with IPv4-translatable (global) address v6 client (native) -> -> v6 server with IPv4-translatable (global) address is the result. never talk about global ipv4 address for customers. > > > > >> 3) There no RFC stated the solution what you called as RFC6052+RFC6145= ; > >> > > > > copied from RFC6145: > > > > Readers of this document are expected to have read and understood th= e > > framework described in [RFC6144 >]. > > Implementations of this IPv4/IPv6 > > translation specification MUST also support the address translation > > algorithms in [RFC6052 ]. > > Implementations MAY also support stateful > > translation [RFC6146 ]. > > RFC6052 + RFC6145 is a MUST and both are standards. > > Please note RFC6145 is an algorithm block. > There is no justification of scenario applicability > please argue this to the RFC6145 track. > > > > and RFC6219 gave you an example of using the both in the practice. > > RFC6219 is informational. According to RFC2026, "An "Informational" > specification > is published for the general information of the Internet community, > and does not represent an Internet community consensus or recommendation.= " > > But BIH is a standard. > > I guess what you have indentified is addressed totally. > I guess we could agree BIH is best selction if IPv4-IPv6 mentioned? > no. your guess is wrong. personally i don't agree. i would like to say it depends. it is a standard, but only a standard among an amount of. on other hand, i don't like to debate this problem with you right now. however, nobody stop you proposing a "BCP-target" draft for BIH usage, standing on the BIH itself rather than borrowing another, with different scope, as the ground of propaganda. > > > > >> whether that is a doable way need to be further justified. But BIH is > >> a standard track > >> > > > > > >> > >> > or by a > >> > NAT64 located anywhere between the IPv4 app and the IPv6 domain > >> implemented > >> > >> I don't get it. If there is NAT64, there is nothing to do with the > >> scenario you are talking about. > >> > >> > >> > >> > in anyway not necessarily the socket layer solution, even though BIH > >> > does > >> > possibly work, by a proxy (ALG), etc. > >> > >> Please note RFC6535 has two flavors, i.e. header translation and > >> socket translation. It=92s really not necessarily the socket layer > >> solution. > >> > >> > 3. i don't think the author has tested the BIH with CLAT for an > >> > IPv6-only > >> > server, at least i have not seen any discussion/report from the > authors > >> or > >> > WG members about the test. > >> > >> (**)I guess you will see the report soon, because we are coding that > >> right > >> now. > >> At this stage, what I can tell is most parts are same in the combining > >> code. > >> > >> > to my understanding, the BIH/CLAT work here is > >> > not yet practiced. why we need/should put a stuff not yet practiced > >> > into > >> a > >> > BCP?? > >> > >> Please don't do the arbitrary objection even you didn't evaluate it. > >> It is a strange logic. > >> "I don't do that. I even don't know that. So I think that is not > >> practiced." > >> That is an unfair argument. > >> > >> > (NOTE, the test result from you only illustrates that BIH itself is > >> > working, not the BIH/464xlat with IPv4-only app access to IPv6-only > >> server. > >> > the tested applications, skype, MSN, etc. are none of business of th= e > >> > so-called IPv6-only servers). > >> > >> Please see the (**) and carefully read my report > >> http://www.ietf.org/mail-archive/web/v6ops/current/msg12631.html > >> The shared experiences are in 464 contexts. > >> With 464xlat, we could easily do *combining 464XLAT with BIH*. > >> It's of significance. > >> > > > > i think i don't misunderstand anything about your report. i read throug= h > > the mail and also the doc of the testing. it is good but i think it sai= d, > > BIH is working, no matter there is 464xlat or not. > > No. What I reported is our experience of BIH because 464xlat is not > appeared in that time. > I have to do in the way if 464 is unavoidable, even it was recommended > BIH should not work with NAT64 in RFC6535. > With 464xlat it's really perfect for us to follow and it's approved > that is a doable way and two technologies could benefit to each other. > We share the experiences and confirmed by wg. > Currently, you are coming here and say "Hi, I'm not happy with that > for no technical reasons, please remove it" > i was talking about technical reasons but you never saw it. ;-) i cannot help if you think the point on technical problem statement is not technical. - maoke > It's really unfair. > > > >please identify the > > benefit of having BIH working together with 464xlat, i.e., what we gain > > through the combination rather than BIH and 464xlat themselves? > > 1) it gives the possibilities of 4-6 with a safe reference of standard > track > 2)it facilitates IPv6-only deployment > 3)it's complementary to support IPv4 application > and etc. > As I said it would be better if you could progress the work with the > points that's didn't cover before > Otherwise, we would repeat the show several months ago > > > > more comprehensively, if 464xlat provides A, BIH provides B, and 464xla= t > + > > BIH provides A + B but nothing else, > > Please note A and B is closely realted. It has same goal/ mostly same > code/ same strategie. > A+B is doing a complete and concrete the use case to operators. > > > > > then i insist that it is not necessary > > to cite BIH in 464xlat at all. > > That is surly known, even whatever happned in the wg and whatever we > are discussing. > Fortunately, it's approved that the adding BIH is no technial harm > after our discussion. > > What needing clarification is already said on the list unless you > create an new point. > > I intended to agree Remi comments > - At a time when there are still discussions on functional aspects of > 464XLAT, this particular discussion is IMHO a waste of time > - Preferred approach: keep the sentence, and proceed. > > > > BRs > > Gang > > > > - maoke > > > > > >> > >> > 4. i was even confused by the text "By combining 464XLAT with BIH > >> > [RFC6535], it is also possible to provide single IPv4/IPv6 translati= on > >> > service" itself. BIH has done the single IPv4/IPv6 translation right= ? > >> what > >> > is the significance of such a "combination"? what is the add-on? > >> > >> Same comment with (*). If you have concrete point, please identify. > >> Ambiguous arguments and arbitrary objections only can waste our energy > >> and time. It doesn't help the document imho. > >> > >> > integrating the compressor, condenser, expansion valve, evaporator > into > >> > a > >> > fridge is an innovation (as the authors did for the 464xlat) but we > >> cannot > >> > call a "fridge + microwave oven put on the top of the fridge" a new > >> > "architecture" of better practice. > >> > >> I didn't fully get your point. 464xlat is not a fridge actually :) > >> Again, please directly identify your technical points/concerns. > >> > >> > >> BRs > >> > >> Gang > >> > >> > >> > >> > - maoke > >> > > >> > 2012/9/6 GangChen > >> > > >> >> 2012/9/6, Maoke : > >> >> > another objection is, Section 9 states "another, > >> >> > if combined with BIH [RFC6535 < > http://tools.ietf.org/html/rfc6535 > >> >], > >> >> is > >> >> > a IPv4 -> IPv6 translation for > >> >> > reaching IPv6-only servers from IPv4-only clients that can not > >> >> > support IPv6. " > >> >> > > >> >> > it sounds to me that 464xlat does suggest to apply BIH, as part o= f > >> >> > the > >> >> best > >> >> > practice, for IPv4 client reaching IPv6-only servers. to my > >> >> understanding, > >> >> > there could be several alternative ways to achieve that, why we > >> >> > should > >> >> > be > >> >> > bounded with BIH? > >> >> > > >> >> > sorry i didn't catch the discussion on this issue before. > >> >> > >> >> There was a quite long discussion, > >> >> since you didn't follow that, I list the links below for your > >> >> convenience. > >> >> > >> >> "A way forward for 464XLAT", started with > >> >> http://www.ietf.org/mail-archive/web/v6ops/current/msg12521.html > >> >> "A way forward for 464XLAT - using BIH", started with > >> >> http://www.ietf.org/mail-archive/web/v6ops/current/msg12631.html > >> >> "I-D Action: draft-ietf-v6ops-464xlat-02.txt" started with > >> >> http://www.ietf.org/mail-archive/web/v6ops/current/msg12628.html > >> >> " [v6ops] draft-ietf-v6ops-464xlat - which status?"started with > >> >> http://www.ietf.org/mail-archive/web/v6ops/current/msg13035.html > >> >> .... > >> >> > >> >> As Cameron indicated *The conclusion was that the 464XLAT is more > >> >> complete by making a reference to BIH scenario.* > >> >> > >> >> BRs > >> >> > >> >> Gang > >> >> > >> >> > >> >> > > >> >> > 2012/8/22 Fred Baker (fred) > >> >> > > >> >> >> I should note that the current thread has a subject line reading > >> >> -06.txt, > >> >> >> but the current version is -07.txt. You may find the diffs (fair= ly > >> >> >> extensive) at > >> >> >> > >> >> >> > http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-464xlat-07.txt > >> >> >> > >> >> >> > >> >> >> On Aug 21, 2012, at 8:45 AM, Fred Baker (fred) wrote: > >> >> >> > >> >> >> > This is to open a two week Working Group last Call on > >> >> >> > > >> >> >> > http://tools.ietf.org/html/draft-ietf-v6ops-464xlat > >> >> >> > "464XLAT: Combination of Stateful and Stateless Translation", > >> >> Masataka > >> >> >> > Mawatari, Masanobu Kawashima, Cameron Byrne, 19-Aug-12 > >> >> >> > > >> >> >> > Please read it now. We are interested in, among other things, > >> >> technical > >> >> >> commentary on the draft and the working group's perception on it= s > >> >> >> usefulness to its target audience. > >> >> >> > _______________________________________________ > >> >> >> > v6ops mailing list > >> >> >> > v6ops@ietf.org > >> >> >> > https://www.ietf.org/mailman/listinfo/v6ops > >> >> >> > >> >> >> ---------------------------------------------------- > >> >> >> The ignorance of how to use new knowledge stockpiles > exponentially. > >> >> >> - Marshall McLuhan > >> >> >> > >> >> >> _______________________________________________ > >> >> >> v6ops mailing list > >> >> >> v6ops@ietf.org > >> >> >> https://www.ietf.org/mailman/listinfo/v6ops > >> >> >> > >> >> > > >> >> > >> > > >> > > > --f46d041826585ee19004c9194741 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

2012/9/7 GangChen <= phdgang@gmail.com>
2012/9/7, Maoke <fibrib@gmail.com>:
> this item is what you are waiting for my reply to, r= ight? see inline.
>
> 2012/9/6 GangChen <phdgang@gma= il.com>
>
>> 2012/9/6, Maoke <fibrib@gma= il.com>:
>> > hi Gang,
>> >
>> > thanks for the links!
>> >
>> > 1. i don't think an early conclusion of the authors canno= t be objected
>> and
>> > thought over again, before the last call is closed.
>>
>> Sure. If you do think several-months lasted discussion doesn't=
>> convince and would like to boil the ocean, we could re-open it. >> But please read the conversion happened before on the list to ensu= re
>> new discussion is not backward.
>>
>> > 2. i don't think it is a loss to state out of scope (or n= ot to mention
>> that
>> > at all) for IPv4-only app access to IPv6-only server.
>>
>> (*)Those arguments were discussed in the thread of "A way for= ward for
>> 464XLAT - using BIH".
>> The loss and gain have been well identified. The point is adding B= IH
>> only can be complementary to 464xlat scenario, no harm.
>> If you have further point, please identify.
>>
>
> putting a microwave oven on the top of a fridge has no harm at all, to= o.

It's good to hear your confirmation on *NO harm*
=
=A0
but we never see a fridge specification states or sugges= ts: if you put your oven on the top of the fridge, you can have icecream an= d meanwhile roast your chicken. :P terrible specification if i have.
=A0


> my
> point is simple: if 464xlat can solve the problem it identifies, then<= br> > things are enough. we don't need anything more, even the "any= thing" has
> been standard

No problem with 464xlat doing the best in 464. But the point is such<= br> 464 can't be guaranteed to be pure at different places and different times in the real life. *Mentioned* that can only be informative and
benefit to reader. If we know the answer is good, why not do it?
=A0
as Lorenzo mentioned, we haven't confirm the a= nswer is good or the best.
as Brian pointed out, it is too prema= ture to talk about this.
=A0
why should we do it?
=A0

> unless we change the scope of the problem.

No need. Please see my mail replying to Lorenzo.

>>
>>
>> > this could be
>> > achieved by simply configuring the IPv6-only server with an R= FC6052
>> > IPv4-translatable address and relying CLAT RFC6145 translatio= n,
>>
>> 1) The IPv4-Embedded IPv6 address on CLAT is inserted with IPv4 >> private address.
>
> When the two IPv4-embedded IPv6 addresses with conflicted IPv4 address=
>> talk to an IPv4-translatable IPv6 address, it would be failed sinc= e
>> IPv6-only server is confused that outgoing packages should send to=
>> which CLAT.
>>
>
> not very understand. conflicted IPv4 address either causes trouble or<= br> > running as anycast. what's the scope?

The IPv4 embedded IPv6 address adopted by 464xlat is inserted with private IPv4 address.
Those private IPv4 addresses are likely be same if two CLAT send
packages to a IPv6 server.
It's no problem with 464 communications because packages could be
identified by different IPv6 prefixes.
but it would be failed sending to a same IPv6 server, because replying
packages can't distinguish which packages should send to which prefix.<= br> I hope you could understand.
=A0
no. i don&#= 39;t know why the IPv6 server cannot distiguish the sources having differen= t IPv6 prefixes.
=A0


>
>> 2) IPv6-only server with IPv4-translatable address would cause one=
>> public IPv4 address.
>> Most people do IPv6 because IPv4 is limited, so doing this way doe= s
>> not really buy you anything.
>>
>
> i (the server) may keep early customers from native IPv4 having access=
> without knowing that i have changed my protocol stack and meanwhile > increase my native IPv6-only customers.

What I indicate is the needs to allocate the global IPv4 address to server. It's nothing to do native IPv4 customer. But you seems mean
there is also need to customers assigning a global IPv4 address. It
seems getting that worse.
=A0
you misunderst= ood. i mean
=A0
=A0=A0 v4private client=A0-> CLAT -= > v6 server=A0with IPv4-translatable (global)=A0address
=A0= =A0 v6 client (native) -> <native IPv6-only network> -> v6 serv= er with IPv4-translatable (global) address
=A0
is the result. never talk about global ipv4 address for = customers.
=A0

>
>> 3) There no RFC stated the solution what you called as RFC6052+RFC= 6145;
>>
>
> copied from RFC6145:
>
> =A0 =A0Readers of this document are expected to have read and understo= od the
> =A0 =A0framework described in [RFC6144 <http://tools.ietf.org/html/rfc6= 144>].
> Implementations of this IPv4/IPv6
> =A0 =A0translation specification MUST also support the address transla= tion
> =A0 =A0algorithms in [RFC6052 <http://tools.ietf.org/html/rfc6052&g= t;].
> Implementations MAY also support stateful
> =A0 =A0translation [RFC6146 <http://tools.ietf.org/html/rfc6146>= ].
> RFC6052 + RFC6145 is a MUST and both are standards.<= br>
Please note RFC6145 is an algorithm block.
There is no justification of scenario applicability
= =A0
please argue this to the RFC6145 track.
=A0
<= blockquote style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-c= olor:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class= =3D"gmail_quote">


> and RFC6219 gave you an example of using the both in the practice.

RFC6219 is informational. According to RFC2026, "An "Inform= ational"
specification
is published for the general information of the Internet community,
and does not represent an Internet community consensus or recommendation. &= quot;

But BIH is a standard.

I guess what you have indentified is addressed totally.
I guess we could agree BIH is best selction if IPv4-IPv6 mentioned?
=A0
no. your guess is wrong. personally i don't= agree. i would like to say it depends. it is a standard, but only a standa= rd among an amount of. on other hand, i don't like to debate this probl= em with you right now.
=A0
however,=A0nobody stop you proposing a "BCP-target&= quot; draft for BIH usage, standing on the BIH itself rather than borrowing= another, with different scope,=A0as the ground of propaganda.
= =A0

>
>> whether that is a doable way need to be further justified. =A0But = BIH is
>> a standard track
>>
>
>
>>
>> > or by a
>> > NAT64 located anywhere between the IPv4 app and the IPv6 doma= in
>> implemented
>>
>> I don't get it. If there is NAT64, there is nothing to do with= the
>> scenario you are talking about.
>>
>>
>>
>> > in anyway not necessarily the socket layer solution, even tho= ugh BIH
>> > does
>> > possibly work, by a proxy (ALG), etc.
>>
>> Please note RFC6535 has two flavors, i.e. header translation and >> socket translation. It=92s really not necessarily the socket layer=
>> solution.
>>
>> > 3. i don't think the author has tested the BIH with CLAT = for an
>> > IPv6-only
>> > server, at least i have not seen any discussion/report from t= he authors
>> or
>> > WG members about the test.
>>
>> (**)I guess you will see the report soon, because we are coding th= at
>> right
>> now.
>> At this stage, what I can tell is most parts are same in the combi= ning
>> code.
>>
>> > to my understanding, the BIH/CLAT work here is
>> > not yet practiced. why we need/should put a stuff not yet pra= cticed
>> > into
>> a
>> > BCP??
>>
>> Please don't do the arbitrary objection even you didn't ev= aluate it.
>> It is a strange logic.
>> "I don't do that. I even don't know that. So I think = that is not
>> practiced."
>> That is an unfair argument.
>>
>> > (NOTE, the test result from you only illustrates that BIH its= elf is
>> > working, not the BIH/464xlat with IPv4-only app access to IPv= 6-only
>> server.
>> > the tested applications, skype, MSN, etc. are none of busines= s of the
>> > so-called IPv6-only servers).
>>
>> Please see the (**) and carefully read my report
>> http://www.ietf.org/mail-archive/web/v6ops/cur= rent/msg12631.html
>> The shared experiences are in 464 contexts.
>> With 464xlat, we could easily do *combining 464XLAT with BIH*.
>> It's of significance.
>>
>
> i think i don't misunderstand anything about your report. i read t= hrough
> the mail and also the doc of the testing. it is good but i think it sa= id,
> BIH is working, no matter there is 464xlat or not.

No. What I reported is our experience of BIH because 464xlat is= not
appeared in that time.
I have to do in the way if 464 is unavoidable, even it was recommended
BIH should not work with NAT64 in RFC6535.
With 464xlat it's really perfect for us to follow and it's approved=
that is a doable way and two technologies could benefit to each other.
We share the experiences and confirmed by wg.
Currently, you are coming here and say "Hi, I'm not happy with tha= t
for no technical reasons, please remove it"
=A0
i was talking about technical reasons but you never saw it. ;-) i = cannot help if you think the point on technical problem statement is not te= chnical.
=A0
- maoke
=A0
It's really unfair.


>please identify the
> benefit of having BIH working together with 464xlat, i.e., what we gai= n
> through the combination rather than BIH and 464xlat themselves?

1) it gives the possibilities of 4-6 with a safe reference of standar= d track
2)it facilitates IPv6-only deployment
3)it's complementary to support IPv4 application
and etc.
As I said it would be better if you could progress the work with the
points that's didn't cover before
Otherwise, we would repeat the show several months ago


> more comprehensively, if 464xlat provides A, BIH provides B, and 464xl= at +
> BIH provides A + B but nothing else,

Please note A and B is closely realted. It has same goal/ mostly same=
code/ same strategie.
A+B is doing a complete and concrete the use case to operators.



> then i insist that it is not necessary
> to cite BIH in 464xlat at all.

That is surly known, even whatever happned in the wg and whatever we<= br> are discussing.
Fortunately, it's approved that the adding BIH is no technial harm
after our discussion.

What needing clarification is already said on the list unless you
create an new point.

I intended to agree Remi comments
- At a time when there are still discussions on functional aspects of
464XLAT, this particular discussion is IMHO a waste of ti= me
- Preferred approach: keep the sentence, and proceed.



BRs

Gang
>
> - maoke
>
>
>>
>> > 4. i was even confused by the text "By combining 464XLAT= with BIH
>> > [RFC6535], it is also possible to provide single IPv4/IPv6 tr= anslation
>> > service" itself. BIH has done the single IPv4/IPv6 trans= lation right?
>> what
>> > is the significance of such a "combination"? what i= s the add-on?
>>
>> Same comment with (*). If you have concrete point, please identify= .
>> Ambiguous arguments and arbitrary objections only can waste our en= ergy
>> and time. It doesn't help the document imho.
>>
>> > integrating the compressor, condenser, expansion valve, evapo= rator into
>> > a
>> > fridge is an innovation (as the authors did for the 464xlat) = but we
>> cannot
>> > call a "fridge + microwave oven put on the top of the fr= idge" a new
>> > "architecture" of better practice.
>>
>> I didn't fully get your point. 464xlat is not a fridge actuall= y :)
>> Again, please directly identify your technical points/concerns. >>
>>
>> BRs
>>
>> Gang
>>
>>
>>
>> > - maoke
>> >
>> > 2012/9/6 GangChen <ph= dgang@gmail.com>
>> >
>> >> 2012/9/6, Maoke <f= ibrib@gmail.com>:
>> >> > another objection is, Section 9 states "another= ,
>> >> > =A0 =A0if combined with BIH [RFC6535 <http://tools.ietf.org= /html/rfc6535
>> >],
>> >> is
>> >> > a IPv4 -> IPv6 translation for
>> >> > =A0 =A0reaching IPv6-only servers from IPv4-only cli= ents that can not
>> >> > =A0 =A0support IPv6. "
>> >> >
>> >> > it sounds to me that 464xlat does suggest to apply B= IH, as part of
>> >> > the
>> >> best
>> >> > practice, for IPv4 client reaching IPv6-only servers= . to my
>> >> understanding,
>> >> > there could be several alternative ways to achieve t= hat, why we
>> >> > should
>> >> > be
>> >> > bounded with BIH?
>> >> >
>> >> > sorry i didn't catch the discussion on this issu= e before.
>> >>
>> >> There was a quite long discussion,
>> >> since you didn't follow that, I list the links below = for your
>> >> convenience.
>> >>
>> >> "A way forward for 464XLAT", started with
>> >> http://www.ietf.org/mail-archive/web/= v6ops/current/msg12521.html
>> >> "A way forward for 464XLAT - using BIH", starte= d with
>> >> http://www.ietf.org/mail-archive/web/= v6ops/current/msg12631.html
>> >> "I-D Action: draft-ietf-v6ops-464xlat-02.txt" s= tarted with
>> >> http://www.ietf.org/mail-archive/web/= v6ops/current/msg12628.html
>> >> " [v6ops] draft-ietf-v6ops-464xlat - which status?&q= uot;started with
>> >> http://www.ietf.org/mail-archive/web/= v6ops/current/msg13035.html
>> >> ....
>> >>
>> >> As Cameron indicated *The conclusion was that the 464XLAT= is more
>> >> complete by making a reference to BIH scenario.*
>> >>
>> >> BRs
>> >>
>> >> Gang
>> >>
>> >>
>> >> >
>> >> > 2012/8/22 Fred Baker (fred) <fred@cisco.com>
>> >> >
>> >> >> I should note that the current thread has a subj= ect line reading
>> >> -06.txt,
>> >> >> but the current version is -07.txt. You may find= the diffs (fairly
>> >> >> extensive) at
>> >> >>
>> >> >> http://tools.ietf.org/rf= cdiff?url2=3Ddraft-ietf-v6ops-464xlat-07.txt
>> >> >>
>> >> >>
>> >> >> On Aug 21, 2012, at 8:45 AM, Fred Baker (fred) w= rote:
>> >> >>
>> >> >> > This is to open a two week Working Group la= st Call on
>> >> >> >
>> >> >> > http://tools.ietf.org/html/draft-iet= f-v6ops-464xlat
>> >> >> > =A0"464XLAT: Combination of Stateful a= nd Stateless Translation",
>> >> Masataka
>> >> >> > =A0Mawatari, Masanobu Kawashima, Cameron By= rne, 19-Aug-12
>> >> >> >
>> >> >> > Please read it now. We are interested in, a= mong other things,
>> >> technical
>> >> >> commentary on the draft and the working group= 9;s perception on its
>> >> >> usefulness to its target audience.
>> >> >> > ___________________________________________= ____
>> >> >> > v6ops mailing list
>> >> >> > v6ops@iet= f.org
>> >> >> > https://www.ietf.org/mailman/listinfo/v6ops<= /a>
>> >> >>
>> >> >> ------------------------------------------------= ----
>> >> >> The ignorance of how to use new knowledge stockp= iles exponentially.
>> >> >> =A0 =A0- Marshall McLuhan
>> >> >>
>> >> >> _______________________________________________<= br> >> >> >> v6ops mailing list
>> >> >> v6ops@ietf.org=
>> >> >> https://www.ietf.org/mailman/listinfo/v6ops >> >> >>
>> >> >
>> >>
>> >
>>
>

--f46d041826585ee19004c9194741-- From despres.remi@laposte.net Fri Sep 7 02:42:15 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3709E21F8736 for ; Fri, 7 Sep 2012 02:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.354 X-Spam-Level: X-Spam-Status: No, score=-0.354 tagged_above=-999 required=5 tests=[AWL=-0.495, BAYES_05=-1.11, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R9mSff0LZGNg for ; Fri, 7 Sep 2012 02:42:14 -0700 (PDT) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C9A521F871A for ; Fri, 7 Sep 2012 02:42:13 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2102.sfr.fr (SMTP Server) with ESMTP id 96DE17000226; Fri, 7 Sep 2012 11:42:12 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2102.sfr.fr (SMTP Server) with ESMTP id 1D791700021C; Fri, 7 Sep 2012 11:42:12 +0200 (CEST) X-SFR-UUID: 20120907094212120.1D791700021C@msfrf2102.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-27--663455522 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Fri, 7 Sep 2012 11:42:11 +0200 Message-Id: References: To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 09:42:15 -0000 --Apple-Mail-27--663455522 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 2012-09-07 11:30, Lorenzo Colitti : > On Fri, Sep 7, 2012 at 6:02 PM, GangChen wrote: > No. What I reported is our experience of BIH because 464xlat is not > appeared in that time. > I have to do in the way if 464 is unavoidable, even it was recommended > BIH should not work with NAT64 in RFC6535. > With 464xlat it's really perfect for us to follow and it's approved > that is a doable way and two technologies could benefit to each other. > We share the experiences and confirmed by wg. > Currently, you are coming here and say "Hi, I'm not happy with that > for no technical reasons, please remove it" > It's really unfair. >=20 > But mentioning BIH in this document, when there are other ways for = IPv4-only clients to talk to IPv6-only servers (e.g., transparent = proxies) is unfair as well. If we want this document to include = technologies to get IPv4-only clients to communicate with IPv6-only = servers, then we should include those other ways as well. BIH is the only IETF specification for an IPv4-only application in a = node attached to an IPv6-only network to reach an IPv6-only server = WITHOUT depending on any special node between the two (transparent proxy = or whatever).=20 As such, it gracefully complements 464XLAT to facilitate IPv6-only = deployments based on standard-track RFCs. Justifications to hide it remain obscure. RD=20 >=20 > > more comprehensively, if 464xlat provides A, BIH provides B, and = 464xlat + > > BIH provides A + B but nothing else, >=20 > Please note A and B is closely realted. It has same goal/ mostly same > code/ same strategie. > A+B is doing a complete and concrete the use case to operators. >=20 > I disagree that they are closely related. They are different problems, = that need to be solved on different timescales, using completely = different technologies. Problem A (IPv4-only application on IPv6-only = network) is a problem that operators are facing now. Problem B = (IPv4-only client to IPv6-only server) is not currently a problem at = all. We should not mix the two. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail-27--663455522 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
2012-09-07 11:30, Lorenzo Colitti :

On Fri, Sep 7, 2012 at 6:02 PM, GangChen <phdgang@gmail.com> wrote:
No. What I reported is our experience of BIH because 464xlat is not
appeared in that time.
I have to do in the way if 464 is unavoidable, even it was recommended
BIH should not work with NAT64 in RFC6535.
With 464xlat it's really perfect for us to follow and it's approved
that is a doable way and two technologies could benefit to each other.
We share the experiences and confirmed by wg.
Currently, you are coming here and say "Hi, I'm not happy with that
for no technical reasons, please remove it"
It's really unfair.

But mentioning BIH in this document, when there are other ways for IPv4-only clients to talk to IPv6-only servers (e.g., transparent proxies) is unfair as well. If we want this document to include technologies to get IPv4-only clients to communicate with IPv6-only servers, then we should include those other ways as well.

BIH is the only IETF specification for an IPv4-only application in a node attached to an IPv6-only network to reach an IPv6-only server WITHOUT depending on any special node between the two (transparent proxy or whatever). 
As such, it gracefully complements 464XLAT to facilitate IPv6-only deployments based on standard-track RFCs.

Justifications to hide it remain obscure.

RD 


> more comprehensively, if 464xlat provides A, BIH provides B, and 464xlat +
> BIH provides A + B but nothing else,

Please note A and B is closely realted. It has same goal/ mostly same
code/ same strategie.
A+B is doing a complete and concrete the use case to operators.

I disagree that they are closely related. They are different problems, that need to be solved on different timescales, using completely different technologies. Problem A (IPv4-only application on IPv6-only network) is a problem that operators are facing now. Problem B (IPv4-only client to IPv6-only server) is not currently a problem at all. We should not mix the two.
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops

--Apple-Mail-27--663455522-- From fibrib@gmail.com Fri Sep 7 02:43:18 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B29821F86D1 for ; Fri, 7 Sep 2012 02:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.749 X-Spam-Level: X-Spam-Status: No, score=-2.749 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7rBNkoFb48G for ; Fri, 7 Sep 2012 02:43:17 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2F03421F8703 for ; Fri, 7 Sep 2012 02:43:17 -0700 (PDT) Received: by eekb45 with SMTP id b45so1141767eek.31 for ; Fri, 07 Sep 2012 02:43:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2rg8lWvPqPcoDB8KlVQEgxSSAOt4c9WM39NxINC2nx8=; b=m4LOntQKXei5DAzKjlqbP1uldjtB7InILrnoIT0xykCaxiQPTPFLmdVcQEKsf4pZq8 YLULo/TBH/LFv/WOyuhgyUwvnnuknDjujtPdAKV6EU/qWzKUsP+8H4qqrsVxZ09i9lxv dyNTUrx7P24n0ji63V3v8epr06la9G15x03eeY2UMYtfhfxWg/D+zPxXXFsFhpxyyj2i GgQZi+B+bMSy8+c4gRdATzQjXJX+AyTKxd2TjTSJaC3Zu4coer1tlgkbLLB27t+J5LvV a85G9XpZAp+QSSZFolxLPqoKEevETrMylQpxRdHknVxQiOn0CwhcXCa7zc3mY/TnHPcb A1AA== MIME-Version: 1.0 Received: by 10.14.204.72 with SMTP id g48mr6926720eeo.45.1347010996045; Fri, 07 Sep 2012 02:43:16 -0700 (PDT) Received: by 10.14.97.9 with HTTP; Fri, 7 Sep 2012 02:43:15 -0700 (PDT) In-Reply-To: <29859876-163E-48E2-A3AE-04A7F50ABDD1@laposte.net> References: <5049A1AF.9080202@gmail.com> <3C325619-F078-48A2-A8B4-3A9666DF0498@laposte.net> <29859876-163E-48E2-A3AE-04A7F50ABDD1@laposte.net> Date: Fri, 7 Sep 2012 18:43:15 +0900 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=047d7b343ccced897804c9196f15 Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 09:43:18 -0000 --047d7b343ccced897804c9196f15 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/9/7 R=E9mi Despr=E9s > > Le 2012-09-07 =E0 10:44, Lorenzo Colitti a =E9crit : > > On Fri, Sep 7, 2012 at 4:59 PM, R=E9mi Despr=E9s wrote: > >> Just noting that BIH is complementary in a draft that deals with a >> related issue isn't, IMHO, a problem that justifies this last minute att= ack >> of a true statement. >> > > It's not a last-minute attack, we have had this conversation before. One > would imagine that last call is when unresolved disagreements need to be > resolved. > > > This subject has AFAIK been stabilized for quite some time. > Newcomers make a big deal, now where hopefully WG conclusion is close, of > going backward by hiding a fact worth being known. > > having BIH in this document will hide the fact, which is worth knowing, that the WG doesn't have consensus on what is the really best practice regarding the problem of IPv4-only to IPv6-only server, which is not the main motivation of the original 464xlat. > > Waste of time IMHO. > > newcomers waste your time. sorry for that. - maoke > RD > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --047d7b343ccced897804c9196f15 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/9/7 R=E9mi Despr=E9s <despr= es.remi@laposte.net>

Le 2012-09-07 =E0 10:44, = Lorenzo Colitti a =E9crit :

On Fri, Sep 7, 2012 at 4:59 PM, R=E9mi Despr=E9s &l= t;despres.rem= i@laposte.net> wrote:
Just noting that BIH is complementary in a draft that deals with a related = issue isn't, IMHO, a problem that justifies this last minute attack of = a true statement.

It's not a last-m= inute attack, we have had this conversation before. One would imagine that = last call is when unresolved disagreements need to be resolved.

This subject has AFAIK been stabilized fo= r quite some time.=A0
Newcomers make a big deal, now where hopefu= lly WG conclusion is close, of going backward by hiding a fact worth being = known.
=A0
=A0
having BIH in this docu= ment will hide the fact, which is worth=A0knowing,=A0that the WG doesn'= t have consensus on what is the really best practice regarding the problem = of IPv4-only to IPv6-only server, which is not the main motivation of the o= riginal 464xlat.
=A0
=A0=
Waste of time IMHO.
=A0
=A0
newcome= rs waste your time. sorry for that.
=A0
- maoke
<= div>=A0
RD


____________________________= ___________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops


--047d7b343ccced897804c9196f15-- From despres.remi@laposte.net Fri Sep 7 02:52:26 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6271F21F8578 for ; Fri, 7 Sep 2012 02:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.166 X-Spam-Level: X-Spam-Status: No, score=-0.166 tagged_above=-999 required=5 tests=[AWL=-0.632, BAYES_40=-0.185, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMnvHw-w3o8M for ; Fri, 7 Sep 2012 02:52:25 -0700 (PDT) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.1]) by ietfa.amsl.com (Postfix) with ESMTP id 488AF21F8574 for ; Fri, 7 Sep 2012 02:52:24 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2102.sfr.fr (SMTP Server) with ESMTP id 4BD9170001F5; Fri, 7 Sep 2012 11:52:24 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2102.sfr.fr (SMTP Server) with ESMTP id A7C2270001F2; Fri, 7 Sep 2012 11:52:23 +0200 (CEST) X-SFR-UUID: 20120907095223687.A7C2270001F2@msfrf2102.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-28--662843934 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Fri, 7 Sep 2012 11:52:23 +0200 Message-Id: <07FD332C-FD46-4E06-B6CA-AC5DB4FB6B1D@laposte.net> References: To: Maoke X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 09:52:26 -0000 --Apple-Mail-28--662843934 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-09-07 =E0 11:31, Maoke a =E9crit : >=20 >=20 > 2012/9/7 GangChen > 2012/9/7, Maoke : > > this item is what you are waiting for my reply to, right? see = inline. > > > > 2012/9/6 GangChen > > > >> 2012/9/6, Maoke : > >> > hi Gang, > >> > > >> > thanks for the links! > >> > > >> > 1. i don't think an early conclusion of the authors cannot be = objected > >> and > >> > thought over again, before the last call is closed. > >> > >> Sure. If you do think several-months lasted discussion doesn't > >> convince and would like to boil the ocean, we could re-open it. > >> But please read the conversion happened before on the list to = ensure > >> new discussion is not backward. > >> > >> > 2. i don't think it is a loss to state out of scope (or not to = mention > >> that > >> > at all) for IPv4-only app access to IPv6-only server. > >> > >> (*)Those arguments were discussed in the thread of "A way forward = for > >> 464XLAT - using BIH". > >> The loss and gain have been well identified. The point is adding = BIH > >> only can be complementary to 464xlat scenario, no harm. > >> If you have further point, please identify. > >> > > > > putting a microwave oven on the top of a fridge has no harm at all, = too. >=20 > It's good to hear your confirmation on *NO harm* > =20 > but we never see a fridge specification states or suggests: if you put = your oven on the top of the fridge, you can have icecream and meanwhile = roast your chicken. :P terrible specification if i have. > =20 >=20 >=20 > > my > > point is simple: if 464xlat can solve the problem it identifies, = then > > things are enough. we don't need anything more, even the "anything" = has > > been standard >=20 > No problem with 464xlat doing the best in 464. But the point is such > 464 can't be guaranteed to be pure at different places and different > times in the real life. *Mentioned* that can only be informative and > benefit to reader. If we know the answer is good, why not do it? > =20 > as Lorenzo mentioned, we haven't confirm the answer is good or the = best. Despite Lorenzo's comment, BIH is a standard-track RFC, and the only = IETF-specified solution that addresses v4-only applications to v6-only = servers, via v6-only networks, with the solution completely within the = v4-only-application node. > as Brian pointed out, it is too premature to talk about this. > =20 > why should we do it? Premature to give it a high priority, agreed, but not a reason for a = pointer to a relevant standard-track RFC to raise such insisting = objections. RD --Apple-Mail-28--662843934 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1


2012/9/7 GangChen <phdgang@gmail.com>
2012/9/7, Maoke <fibrib@gmail.com>:
> this item is what you are waiting for my reply = to, right? see inline.
>
> 2012/9/6 GangChen <phdgang@gmail.com>
>
>> 2012/9/6, Maoke <fibrib@gmail.com>:
>> > hi Gang,
>> >
>> > thanks for the links!
>> >
>> > 1. i don't think an early conclusion of the authors cannot = be objected
>> and
>> > thought over again, before the last call is closed.
>>
>> Sure. If you do think several-months lasted discussion = doesn't
>> convince and would like to boil the ocean, we could re-open = it.
>> But please read the conversion happened before on the list to = ensure
>> new discussion is not backward.
>>
>> > 2. i don't think it is a loss to state out of scope (or = not to mention
>> that
>> > at all) for IPv4-only app access to IPv6-only server.
>>
>> (*)Those arguments were discussed in the thread of "A way = forward for
>> 464XLAT - using BIH".
>> The loss and gain have been well identified. The point is = adding BIH
>> only can be complementary to 464xlat scenario, no harm.
>> If you have further point, please identify.
>>
>
> putting a microwave oven on the top of a fridge has no harm at all, = too.

It's good to hear your confirmation on *NO = harm*
 
but we never see a fridge = specification states or suggests: if you put your oven on the top of the = fridge, you can have icecream and meanwhile roast your chicken. :P = terrible specification if i have.
 


> my
> point is simple: if 464xlat can solve the problem it identifies, = then
> things are enough. we don't need anything more, even the "anything" = has
> been standard

No problem with 464xlat doing the best in 464. But the point is = such
464 can't be guaranteed to be pure at different places and different
times in the real life. *Mentioned* that can only be informative and
benefit to reader. If we know the answer is good, why not do = it?
 
as Lorenzo mentioned, we = haven't confirm the answer is good or the best. =

Despite Lorenzo's comment, = BIH is a standard-track RFC, and the only IETF-specified solution that = addresses v4-only applications to v6-only servers, via v6-only networks, = with the solution completely within the v4-only-application = node.


as Brian pointed out, it is too premature to = talk about this.
 
why should we do it? =

Premature to give it a high = priority, agreed, but not a reason for a pointer to a relevant = standard-track RFC to raise such insisting = objections.

RD



= --Apple-Mail-28--662843934-- From fibrib@gmail.com Fri Sep 7 02:55:48 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20FDD21F8745 for ; Fri, 7 Sep 2012 02:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.746 X-Spam-Level: X-Spam-Status: No, score=-2.746 tagged_above=-999 required=5 tests=[AWL=-0.048, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHnIoY2ZEBiP for ; Fri, 7 Sep 2012 02:55:47 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id B4C9E21F8574 for ; Fri, 7 Sep 2012 02:55:37 -0700 (PDT) Received: by eekb45 with SMTP id b45so1148201eek.31 for ; Fri, 07 Sep 2012 02:55:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1zOI/8eYLXVfcI85QieXUVB021UhYMdu2cLxmMWg6co=; b=hBHUY7awllmPfI1mjfhXMNGZ6C3kGZOOwE5TkYIrvje+y+SLKN4Wo/11BAarj9URu3 1XnldPhxbZLaa5Z8zR9+4OUARPYC9T3ydaG72xWnOduJQ2TcNIcJta3xIczJXLrYxAuL fUFkHciyAI6M9Oi7QpaHECvhnLO6ill9l10bja7vGxObm5WBEY2T7+6bBP/11hhqkvIV xe3Dak4a3JkB0e0ZsHVKuJ4vo8VWoxS5TscORBk3dCzuK0r4CFwJ+QAx3ILkFTWuphhA kdi6wQ7TvRqdvwBYkOc495yRJ83NruPjaWVHnXY2jEVI0sVMny5A/39d/bpLZoZmj7L8 RFWg== MIME-Version: 1.0 Received: by 10.14.218.134 with SMTP id k6mr7038199eep.14.1347011736907; Fri, 07 Sep 2012 02:55:36 -0700 (PDT) Received: by 10.14.97.9 with HTTP; Fri, 7 Sep 2012 02:55:36 -0700 (PDT) In-Reply-To: References: Date: Fri, 7 Sep 2012 18:55:36 +0900 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=047d7b6224c216306f04c9199c4f Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 09:55:48 -0000 --047d7b6224c216306f04c9199c4f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/9/7 R=E9mi Despr=E9s > > 2012-09-07 11:30, Lorenzo Colitti : > > On Fri, Sep 7, 2012 at 6:02 PM, GangChen wrote: > >> No. What I reported is our experience of BIH because 464xlat is not >> appeared in that time. >> I have to do in the way if 464 is unavoidable, even it was recommended >> BIH should not work with NAT64 in RFC6535. >> With 464xlat it's really perfect for us to follow and it's approved >> that is a doable way and two technologies could benefit to each other. >> We share the experiences and confirmed by wg. >> Currently, you are coming here and say "Hi, I'm not happy with that >> for no technical reasons, please remove it" >> It's really unfair. >> > > But mentioning BIH in this document, when there are other ways for > IPv4-only clients to talk to IPv6-only servers (e.g., transparent proxies= ) > is unfair as well. If we want this document to include technologies to ge= t > IPv4-only clients to communicate with IPv6-only servers, then we should > include those other ways as well. > > > BIH is the only IETF specification for an IPv4-only application in a node > attached to an IPv6-only network to reach an IPv6-only server WITHOUT > depending on any special node between the two (transparent proxy or > whatever). > > well, we see the scope changed by you again, different from Gang's statement "BIH is the best if IPv4-v6 is mentioned". AFAIK, the wg haven't discussed this scope in any thread up to now. on the other hand, it ignores special node CLAT has been there. on the other hand, it ignores what PLAT can provide. > > As such, it gracefully complements 464XLAT to facilitate IPv6-only > deployments based on standard-track RFCs. > > Justifications to hide it remain obscure. > > well, i prefer not to hide it too, by saying "BIH is a way for IPv4-only client having access to IPv6-only servers but it is different from the scope of this BCP, and therefore not yet identified as a best practice", explicitly. - maoke > > > RD > > > > more comprehensively, if 464xlat provides A, BIH provides B, and 464xla= t >> + >> > BIH provides A + B but nothing else, >> >> Please note A and B is closely realted. It has same goal/ mostly same >> code/ same strategie. >> A+B is doing a complete and concrete the use case to operators. >> > > I disagree that they are closely related. They are different problems, > that need to be solved on different timescales, using completely differen= t > technologies. Problem A (IPv4-only application on IPv6-only network) is a > problem that operators are facing now. Problem B (IPv4-only client to > IPv6-only server) is not currently a problem at all. We should not mix th= e > two. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --047d7b6224c216306f04c9199c4f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/9/7 R=E9mi Despr=E9s <despr= es.remi@laposte.net>

2012-09-07 11:30, Lorenzo= Colitti :

On Fri, Sep= 7, 2012 at 6:02 PM, GangChen <phdgang@gmail.com> wrote:
No. What I reported is our experience of BIH because 464xlat is not
appeared in that time.
I have to do in the way if 464 is unavoidable, even it was recommended
BIH should not work with NAT64 in RFC6535.
With 464xlat it's really perfect for us to follow and it's approved=
that is a doable way and two technologies could benefit to each other.
We share the experiences and confirmed by wg.
Currently, you are coming here and say "Hi, I'm not happy with tha= t
for no technical reasons, please remove it"
It's really unfair.

But mentioning = BIH in this document, when there are other ways for IPv4-only clients to ta= lk to IPv6-only servers (e.g., transparent proxies) is unfair as well.=A0If= we want this document to include technologies to get IPv4-only clients to = communicate with IPv6-only servers, then we should include those other ways= as well.

BIH is the only IETF specification = for an IPv4-only application in a node attached to an IPv6-only network to = reach an IPv6-only server WITHOUT depending on any special node between the= two (transparent proxy or whatever).=A0
=A0
=A0
well, we see the scope = changed by you again, different=A0from Gang's statement "BIH is th= e best if IPv4-v6 is mentioned". AFAIK,=A0the wg=A0haven't discuss= ed this scope in any thread up to now. on the other hand, it ignores specia= l node CLAT has been there. on the other hand, it ignores what PLAT can pro= vide.
=A0
=A0=
As such, it gracefully complements 464XLAT to facilitate IPv6-only dep= loyments based on standard-track RFCs.
=A0
Justifications to hide it remain o= bscure.
=A0
=A0
well, i pr= efer not to hide it too, by saying "BIH is a way for IPv4-only client = having access to IPv6-only servers but it is different from the scope of th= is BCP, and therefore not yet identified as a best practice", explicit= ly.
=A0
- maoke
=A0
=A0

RD=A0


> more comprehensively, if 464xlat = provides A, BIH provides B, and 464xlat +
> BIH provides A + B but nothing else,

Please note A and B is closely realted. It has same goal/ mostly same=
code/ same strategie.
A+B is doing a complete and concrete the use case to operators.

I disagree that they are closely related. They are= different problems, that need to be solved on different timescales, using = completely different technologies. Problem A (IPv4-only application on IPv6= -only network) is a problem that operators are facing now. Problem B (IPv4-= only client to IPv6-only server) is not currently a problem at all. We shou= ld not mix the two.
_______________________________________________
v6ops mailing list
v6ops@ietf.org
http= s://www.ietf.org/mailman/listinfo/v6ops


____________________________________= ___________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops


--047d7b6224c216306f04c9199c4f-- From lorenzo@google.com Fri Sep 7 03:04:03 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54A4521F86DC for ; Fri, 7 Sep 2012 03:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.745 X-Spam-Level: X-Spam-Status: No, score=-102.745 tagged_above=-999 required=5 tests=[AWL=-0.069, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nWvtQFiaeOOc for ; Fri, 7 Sep 2012 03:04:02 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id A231E21F86BE for ; Fri, 7 Sep 2012 03:04:02 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so4662552obb.31 for ; Fri, 07 Sep 2012 03:04:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=t/I58JVepFLnYMiAQLWXephUOnUx/DGz+8xb02sCx90=; b=DS4Eo9jn7hv3XjtkuIDuQcfVte0k+fjfNZk8Oz686si17Yuc4qx6sEvnEH8bs/MaXk zq85wXIX3JTooV5j+K8e3B7gYcTd6K5ZQjPbtPDBj34vkG85N9xsdPUeeW8NHeis0ou0 koF6DHA3xzeJXtfkF9Ntsz3FbOVlZxEenoQ8xxKSTfkoJRp5vWCW36agxUbPqkCsCg9f t3juDMI9YBIjkEuw+09L2uN6KJ0O7qvlGjo+aJCUiXRlBWlQA9hsPFSrhas4lLmWvv3D qlLxrkrWFuPZl4EynmAT1e9sRX0G6+aT/GXdTP0hqw9MEDomv0i+ocU1HSTGjGbEVJyL lT9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=t/I58JVepFLnYMiAQLWXephUOnUx/DGz+8xb02sCx90=; b=D1+cDP7HCgO/kNieHe82B4tnLpCtJyjy+wbNxa+7RMimuritKWyL4GCDA3DDn2H94E Nz+mlTRfmWbgqwPFzhOgXI8zvm6BhMutW8wv060n8nS14P3vFun/rDpSx3+OEwWWWBcE qCV8HBxjkuwTefITWnu6D7t9XRal2WUJk9ZfHmMMS7vahzCeVfm/cHkH/dPwmg1sarml wDOGnaV702bNbRb9gBQZozH9gin5JjVZoqFCFcbxvw+Pe0P7cR8aZtFG/zlWn+OcYp8u Dv4OvUI4SqXpd8ayccxYBKwpsNpqxIidXxjDCKXbvim0GYKSRPznaU2hDOUL9iWsWPfd MZNw== Received: by 10.60.10.6 with SMTP id e6mr5207625oeb.45.1347012242268; Fri, 07 Sep 2012 03:04:02 -0700 (PDT) Received: by 10.60.10.6 with SMTP id e6mr5207617oeb.45.1347012242178; Fri, 07 Sep 2012 03:04:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.187.8 with HTTP; Fri, 7 Sep 2012 03:03:41 -0700 (PDT) In-Reply-To: References: From: Lorenzo Colitti Date: Fri, 7 Sep 2012 19:03:41 +0900 Message-ID: To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=e89a8fb2028a34040004c919badf X-System-Of-Record: true X-Gm-Message-State: ALoCoQnpwv3ORGg7iAtlBDsxIXXlBWaF50/5GK6GL/YvfQe08YB+bwFX22axildK0fyQBFLQHzwDpbd2b1L1w3XcExiuf3ReIno6FIt1NVKNzb5gBd8aUBldttjcQvWFvPXRa4ra/cZwouEurXWw+lTkJvhhkF3F9QKAZq+f9LBeklMUIkRKxZzebDNkE079lyur/1mRY5D7 Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 10:04:03 -0000 --e89a8fb2028a34040004c919badf Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Sep 7, 2012 at 6:42 PM, R=E9mi Despr=E9s = wrote: > BIH is the only IETF specification for an IPv4-only application in a node > attached to an IPv6-only network to reach an IPv6-only server WITHOUT > depending on any special node between the two (transparent proxy or > whatever). > And yet, before the problem it solves actually becomes a problem, things could change substantially. New, better methods can come along. It could be obsoleted. It could change. And we'd be stuck with a BCP that endorses something that's not relevant any more. So if you really want to mention IPv6-only servers, I would suggest replacing the current text with the following: 464XLAT does not provide a means for IPv4-only applications to communicate with IPv6-only servers. If this capability is necessary, 464XLAT can be coupled with another transition mechanisms such as BIH [RFC6535]. That way it's clear that this document does not specify a best practice for IPv4-only clients to talk to IPv6-only servers, but only for IPv4-only apps on an IPv6-only network. In any case, I think the following points have to be resolved before we can make progress: 1. The conflict between section 1, which talks about IPv6-only servers, and section 2, which declares them out of scope, must be resolved. 2. Before we mention BIH in this document, we should ensure that at least one implementation of 464XLAT+BIH has been tested. We don't want to publish a BCP that suggests doing something that has never been tested. 3. If this document suggests using 464XLAT + BIH together, it needs to say why the text in the BIH RFC which says "Use of BIH together with a NAT64 is NOT RECOMMENDED" is not relevant to this case. --e89a8fb2028a34040004c919badf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Sep 7, 2012 at 6:42 PM, R=E9mi Despr=E9s <despres.remi@lapo= ste.net> wrote:
BIH is the only IETF specification for = an IPv4-only application in a node attached to an IPv6-only network to reac= h an IPv6-only server WITHOUT depending on any special node between the two= (transparent proxy or whatever).=A0

And yet, before the problem it solve= s actually becomes a problem, things could change substantially. New, bette= r methods can come along. It could be obsoleted. It could change. And we= 9;d be stuck with a BCP that endorses something that's not relevant any= more. So if you really want to mention IPv6-only servers, I would suggest = replacing the current text with the following:

464XLAT does not provide a means for IPv4-only applicat= ions to communicate with IPv6-only servers. If this capability is necessary= , 464XLAT can be coupled with another transition mechanisms such as BIH=A0[= RFC6535].

That way it's clear that this document does not spe= cify a best practice for IPv4-only clients to talk to IPv6-only servers, bu= t only for IPv4-only apps on an IPv6-only network.

In any case, I think the following points have to be resolved before w= e can make progress:

1. The conflict between secti= on 1, which talks about IPv6-only servers, and section 2, which declares th= em out of scope, must be resolved.
2.=A0Before we mention BIH in this document, we should ensure that at = least one implementation of 464XLAT+BIH has been tested. We don't want = to publish a BCP that suggests doing something that has never been tested.<= /div>
3. If this document suggests using 464XLAT + BIH together, it needs to= say why the text in the BIH RFC which says "Use of BIH together with = a=A0NAT64 is NOT RECOMMENDED" is not relevant to this case.
--e89a8fb2028a34040004c919badf-- From despres.remi@laposte.net Fri Sep 7 03:08:41 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA8E21F8668 for ; Fri, 7 Sep 2012 03:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.114 X-Spam-Level: X-Spam-Status: No, score=-0.114 tagged_above=-999 required=5 tests=[AWL=-0.625, BAYES_20=-0.74, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYvCDFZKzbFR for ; Fri, 7 Sep 2012 03:08:41 -0700 (PDT) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F15021F85F3 for ; Fri, 7 Sep 2012 03:08:39 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2102.sfr.fr (SMTP Server) with ESMTP id 55B3570001D7; Fri, 7 Sep 2012 12:08:39 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2102.sfr.fr (SMTP Server) with ESMTP id 0025D7000159; Fri, 7 Sep 2012 12:08:38 +0200 (CEST) X-SFR-UUID: 20120907100839687.0025D7000159@msfrf2102.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-29--661868558 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Fri, 7 Sep 2012 12:08:38 +0200 Message-Id: References: <5049A1AF.9080202@gmail.com> <3C325619-F078-48A2-A8B4-3A9666DF0498@laposte.net> <29859876-163E-48E2-A3AE-04A7F50ABDD1@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 10:08:41 -0000 --Apple-Mail-29--661868558 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-09-07 =E0 11:43, Maoke a =E9crit : >=20 >=20 > 2012/9/7 R=E9mi Despr=E9s >=20 > Le 2012-09-07 =E0 10:44, Lorenzo Colitti a =E9crit : >=20 >> On Fri, Sep 7, 2012 at 4:59 PM, R=E9mi Despr=E9s = wrote: >> Just noting that BIH is complementary in a draft that deals with a = related issue isn't, IMHO, a problem that justifies this last minute = attack of a true statement. >>=20 >> It's not a last-minute attack, we have had this conversation before. = One would imagine that last call is when unresolved disagreements need = to be resolved. >=20 > This subject has AFAIK been stabilized for quite some time.=20 > Newcomers make a big deal, now where hopefully WG conclusion is close, = of going backward by hiding a fact worth being known. > =20 > =20 > having BIH in this document will hide the fact, which is worth = knowing, that the WG doesn't have consensus on what is the really best = practice regarding the problem of IPv4-only to IPv6-only server, This is new!=20 Are you suggesting that v6ops objects to RFC 6535 being the = standard-track RFC for its scope? > which is not the main motivation of the original 464xlat. > =20 > =20 > Waste of time IMHO. > =20 > =20 > newcomers waste your time. sorry for that. Newcomers are most welcome, and in most cases don't waste WG time! But here, while the chair has insisted to close the discussion asap, = insistently presenting last-minute objections to a sentence that is = technically irreproachable, that just provides a useful information in = its context, and has been stabilized for quite some time, is IMHO a = waste of time for the WG. RD =20 > =20 > - maoke > =20 > RD >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 --Apple-Mail-29--661868558 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1


2012/9/7 R=E9mi Despr=E9s <despres.remi@laposte.net>

Le 2012-09-07 =E0 = 10:44, Lorenzo Colitti a =E9crit :

On Fri, Sep 7, 2012 at 4:59 PM, R=E9mi Despr=E9s <despres.remi@laposte.net> wrote:
Just noting that BIH is complementary in a draft that deals with a = related issue isn't, IMHO, a problem that justifies this last minute = attack of a true statement.

It's not = a last-minute attack, we have had this conversation before. One would = imagine that last call is when unresolved disagreements need to be = resolved.

This subject has AFAIK been stabilized = for quite some time. 
Newcomers make a big deal, now = where hopefully WG conclusion is close, of going backward by hiding a = fact worth being known.
 
 
having BIH in = this document will hide the fact, which is worth knowing, that = the WG doesn't have consensus on what is the really best practice = regarding the problem of IPv4-only to IPv6-only server, =

This is new! 
Are = you suggesting that v6ops objects to RFC 6535 being the standard-track = RFC for its scope?

which is not the main motivation of the = original 464xlat.

 
 
Waste of time IMHO.
 
&= nbsp;
newcomers waste your time. sorry for that. =

Newcomers are most welcome, = and in most cases don't waste WG time!

But = here, while the chair has insisted to close the discussion asap, = insistently presenting last-minute objections to a sentence that is = technically irreproachable, that just provides a useful information in = its context, and has been stabilized for quite some time, is IMHO a = waste of time for the = WG.

RD

 
=


 
- = maoke
 
=
RD


___________________________= ____________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops



= --Apple-Mail-29--661868558-- From phdgang@gmail.com Fri Sep 7 03:08:45 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFEF221F8758 for ; Fri, 7 Sep 2012 03:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jOWcLeGpVeyx for ; Fri, 7 Sep 2012 03:08:45 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 20FF421F8716 for ; Fri, 7 Sep 2012 03:08:45 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so3228481vbb.31 for ; Fri, 07 Sep 2012 03:08:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yGDUH+ZLzEd4BinMj4qMwYK3Ed+WILUKiTtFpOVVP6o=; b=p1+xBSXOkrdw2NmG8YLNuEkaOvlPBtXO+5J4E6wUQ8o3kI74S+E5vVIMhkNwlfRgDV JTH0W793oQr8iTx3pJoiJHGkgN4kJnN0xuc9dnYpQDyNzbdF10hA/EaaJwAjvzi2bDDO MDNqT/woJ6VgBCrvRRJk8NIMNMgTl/ckXmtpXc8P5eBUh1wceIQbOlTj7r+qBbGwHgu2 cyuHuAr7RtlrWVF+9+rB74UyFBanScBLbOFM8uH1vlgFcwl7qYxEyn8LTV9y7vzNnfZx VdOp6s6eHQrW5fpvoe88u7afd3PKys5ZZQIhqGSBkmlu6XQTrvPtQHbJbGm2PqP5nheC UbLg== MIME-Version: 1.0 Received: by 10.58.65.10 with SMTP id t10mr7018793ves.48.1347012524581; Fri, 07 Sep 2012 03:08:44 -0700 (PDT) Received: by 10.58.114.231 with HTTP; Fri, 7 Sep 2012 03:08:44 -0700 (PDT) In-Reply-To: References: Date: Fri, 7 Sep 2012 18:08:44 +0800 Message-ID: From: GangChen To: Lorenzo Colitti Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 10:08:45 -0000 Hello Lorenzo, 2012/9/7, Lorenzo Colitti : > On Fri, Sep 7, 2012 at 6:02 PM, GangChen wrote: > >> No. What I reported is our experience of BIH because 464xlat is not >> appeared in that time. >> I have to do in the way if 464 is unavoidable, even it was recommended >> BIH should not work with NAT64 in RFC6535. >> With 464xlat it's really perfect for us to follow and it's approved >> that is a doable way and two technologies could benefit to each other. >> We share the experiences and confirmed by wg. >> Currently, you are coming here and say "Hi, I'm not happy with that >> for no technical reasons, please remove it" >> It's really unfair. > > But mentioning BIH in this document, when there are other ways for > IPv4-only clients to talk to IPv6-only servers (e.g., transparent proxies) > is unfair as well. If we want this document to include technologies to get > IPv4-only clients to communicate with IPv6-only servers, then we should > include those other ways as well. 1) CLAT in 464xlat is doing network level translation (RFC6145), it's good compatible with BIH implementation (also RFC6145 is doing); But transparent proxies is doing different thing from an application level. I don't have experiences to say whether that is a feasible way doing that on a energy- constrained terminal (e.g. a phone). But it can't be confirmed the efficiency of network layer translation is advisable. 2) With my humble knowledge, I didn't find any standard track document to state the *transparent proxies*. Especially, the processes of IPv4->IPv6 translation. I have found one, i.e. RFC1919, which is informational and released in 1999. If you have another, I'd happy to read and evaluate it. >> more comprehensively, if 464xlat provides A, BIH provides B, and 464xlat >> + >> > BIH provides A + B but nothing else, >> >> Please note A and B is closely realted. It has same goal/ mostly same >> code/ same strategie. >> A+B is doing a complete and concrete the use case to operators. >> > > I disagree that they are closely related. I agree the word *closely* may not accurate. But can we agree it's related and has a possibility to cooperate to make the thing better in an IPv6 deployment network? >They are different problems, that > need to be solved on different timescales, using completely different > technologies. Problem A (IPv4-only application on IPv6-only network) is a *IPv4-only application on IPv6-only network * is indeed the goal of RFC6535 http://tools.ietf.org/html/rfc6535 > problem that operators are facing now. Problem B (IPv4-only client to > IPv6-only server) is not currently a problem at all. Yet. But the fact is (IPv4-only application on IPv6-only network) is a superset of (IPv4-only client to IPv6-only server). And It is a fact the BIH RFC 6535 deals with (IPv4-only client to IPv6-only server), and is on standard track > We should not mix the two. > We don't. As I clarified in http://www.ietf.org/mail-archive/web/v6ops/current/msg14132.html, it's clear. Hope we could accept. Many thanks Gang From fibrib@gmail.com Fri Sep 7 03:13:17 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94C6821F869C for ; Fri, 7 Sep 2012 03:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.742 X-Spam-Level: X-Spam-Status: No, score=-2.742 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qCb9bpl31wz0 for ; Fri, 7 Sep 2012 03:13:16 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 75BFC21F8690 for ; Fri, 7 Sep 2012 03:13:16 -0700 (PDT) Received: by eekb45 with SMTP id b45so1156352eek.31 for ; Fri, 07 Sep 2012 03:13:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wjOqb1xmxfvXNChxDGAM8iFIwfudHba48WfOBd8cjv4=; b=s34vRcFWc6o+eKSkakwBDhHyR12K/wgZ4oN58A4Ms+j8S/TVdrWtxVP1amPx/7Exm5 218uwnQWblDHEShCKdeZcZz0flPxopohz5XmJWK1QztSCe7+tW0PynPNBNTN8HVgUfJC iuMvxded5nT2YEVp/O3tSqwX+okdmj2ymlTmtV15PKKFpjZcFIFI/AZU6LM9E6q2wmpq 1601fnsIUSh8u8DRxZaRLZnh//QDtx+E2I+/RVZP3m/9BP5oDzbT4HCpXghweoDIVXd4 Hvs73+L9RrgiEXlhqFrtumhJGaAfoa/smr1hSLaawWxz438yG2p6A08hCseNmsTfNwKd iqBQ== MIME-Version: 1.0 Received: by 10.14.218.134 with SMTP id k6mr7110726eep.14.1347012795658; Fri, 07 Sep 2012 03:13:15 -0700 (PDT) Received: by 10.14.97.9 with HTTP; Fri, 7 Sep 2012 03:13:15 -0700 (PDT) In-Reply-To: References: <5049A1AF.9080202@gmail.com> <3C325619-F078-48A2-A8B4-3A9666DF0498@laposte.net> <29859876-163E-48E2-A3AE-04A7F50ABDD1@laposte.net> Date: Fri, 7 Sep 2012 19:13:15 +0900 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=047d7b6224c231724f04c919db13 Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 10:13:17 -0000 --047d7b6224c231724f04c919db13 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/9/7 R=E9mi Despr=E9s > > Le 2012-09-07 =E0 11:43, Maoke a =E9crit : > > > > 2012/9/7 R=E9mi Despr=E9s > >> >> Le 2012-09-07 =E0 10:44, Lorenzo Colitti a =E9crit : >> >> On Fri, Sep 7, 2012 at 4:59 PM, R=E9mi Despr=E9s wrote: >> >>> Just noting that BIH is complementary in a draft that deals with a >>> related issue isn't, IMHO, a problem that justifies this last minute at= tack >>> of a true statement. >>> >> >> It's not a last-minute attack, we have had this conversation before. One >> would imagine that last call is when unresolved disagreements need to be >> resolved. >> >> >> This subject has AFAIK been stabilized for quite some time. >> Newcomers make a big deal, now where hopefully WG conclusion is close, o= f >> going backward by hiding a fact worth being known. >> >> > > having BIH in this document will hide the fact, which is > worth knowing, that the WG doesn't have consensus on what is the really > best practice regarding the problem of IPv4-only to IPv6-only server, > > > This is new! > Are you suggesting that v6ops objects to RFC 6535 being the standard-trac= k > RFC for its scope? > > which scope? dear Remi, please you don't change the scope of RFC6535 too! it is not the best practice for any IPv4-only client having access to IPv6-only servers, IMHO, it might be best in some cases. i said, it depends. - maoke > > > which is not the main motivation of the original 464xlat. > > > > >> >> Waste of time IMHO. >> >> > > newcomers waste your time. sorry for that. > > > Newcomers are most welcome, and in most cases don't waste WG time! > > But here, while the chair has insisted to close the discussion asap, > insistently presenting last-minute objections to a sentence that is > technically irreproachable, that just provides a useful information in it= s > context, and has been stabilized for quite some time, is IMHO a waste of > time for the WG. > > RD > > > > > > > - maoke > > >> RD >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> >> > > --047d7b6224c231724f04c919db13 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/9/7 R=E9mi Despr=E9s <despr= es.remi@laposte.net>

Le 2012-09-07 =E0 11:43, = Maoke a =E9crit :


=
2012/9/7 R=E9mi Despr=E9s = <despres.r= emi@laposte.net>

Le 2012-09-07 =E0 10:44, = Lorenzo Colitti a =E9crit :

On Fri,= Sep 7, 2012 at 4:59 PM, R=E9mi Despr=E9s <despres.remi@laposte.net= > wrote:
Just noting that BIH is complementary in a draft that deals with a related = issue isn't, IMHO, a problem that justifies this last minute attack of = a true statement.

It's not a last-m= inute attack, we have had this conversation before. One would imagine that = last call is when unresolved disagreements need to be resolved.

This subject has AFAIK been stabilized fo= r quite some time.=A0
Newcomers make a big deal, now where hopefu= lly WG conclusion is close, of going backward by hiding a fact worth being = known.
=A0
=A0
having BIH in this docu= ment will hide the fact, which is worth=A0knowing,=A0that the WG doesn'= t have consensus on what is the really best practice regarding the problem = of IPv4-only to IPv6-only server,

This is new!=A0
Are you s= uggesting that v6ops objects to RFC 6535 being the standard-track RFC for i= ts scope?
=A0
=A0
which sc= ope? dear Remi, please you don't change the scope of RFC6535 too! it is= not the best practice for any IPv4-only client having access to IPv6-only = servers, IMHO, it might be best in some cases. i said, it depends. - maoke<= /div>
=A0
=A0=

which is not the main motivation of the original 464xlat.
<= /div>

=A0
=A0=
Waste of time IMHO.
=A0
<= /font>
=A0
newcomers waste your tim= e. sorry for that.

Newco= mers are most welcome, and in most cases don't waste WG time!

But here, while the chair has insisted to close the dis= cussion asap, insistently presenting last-minute objections to a sentence t= hat is technically irreproachable, that just provides a useful information = in its context, and has been stabilized for quite some time, is IMHO a wast= e of time for the WG.

RD
=

=A0



=A0
- maoke
=A0
RD


____________________________= ___________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops




--047d7b6224c231724f04c919db13-- From phdgang@gmail.com Fri Sep 7 03:15:24 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6750221F86D6 for ; Fri, 7 Sep 2012 03:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.466 X-Spam-Level: X-Spam-Status: No, score=-3.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LD7Li-iT+wK0 for ; Fri, 7 Sep 2012 03:15:23 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7EAA921F86F2 for ; Fri, 7 Sep 2012 03:15:23 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so3242185vbb.31 for ; Fri, 07 Sep 2012 03:15:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lQkf+8jWEciQknRoQkXatxScSkevSJTFdnU2a+7A2+I=; b=q4F+nI0SEo812xPd00w/ZaT7vRUgMph/xdiopNRRBbNzQj25td0kxM3ALfZ+/8e1mb 4IwVgRfRMs2zBsEWpGoz4pzLAnIdfz6niH1dyHKrYvbSc7iOorTFn4XZUk08FotdNQX1 RsVArvZqmSxf/vSs+NXqaMhM5Jhhx5fEnVgfVZFCKDjBV491CsI/fR2Xrhq7emEXoU8J BSbZuvqHnQDL5UbUb7v2YbV4rAyJRnZNH3ivQL3edNTWkYMzIFHAQrB7S/B9QXfaOX/k AQQOmasQ5n4Fcvis2mVzPpG2tvsVGN5FFFgK/D1SoQ2mLnvIt+QOKN0lpNTV6IRWr42g 1Z5Q== MIME-Version: 1.0 Received: by 10.52.34.204 with SMTP id b12mr5274112vdj.75.1347012922829; Fri, 07 Sep 2012 03:15:22 -0700 (PDT) Received: by 10.58.114.231 with HTTP; Fri, 7 Sep 2012 03:15:22 -0700 (PDT) In-Reply-To: References: Date: Fri, 7 Sep 2012 18:15:22 +0800 Message-ID: From: GangChen To: Maoke Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 10:15:24 -0000 2012/9/7, Maoke : > 2012/9/7 GangChen > >> Hello Lorenzo, >> >> 2012/9/7, Lorenzo Colitti : >> > On Fri, Sep 7, 2012 at 2:59 PM, GangChen wrote: >> > >> >> If you haven't concrete argument and only insist on the claim, >> >> we will be here for another month while that would delay the work. >> >> Please to identify what the harm you see to object. . >> > >> > >> > Ok, here's a concrete problem, then: the draft contradicts itself. >> >> Thanks for providing the concrete point, I guess your intention is not >> to identify the technical problem after the reading >> >> > Section 1 says: >> > >> > By combining 464XLAT with BIH [RFC6535], it is also possible to >> > provide single IPv4 to IPv6 translation service, which will be >> > needed >> > in the future case of IPv6-only servers [...] >> > >> > But Section 2 says: >> > >> > This BCP only applies when the following two criteria are present: >> > [...] >> > 2. There are IPv4-only applications or hosts that must communicate >> > across the IPv6-only network to reach the IPv4 Internet. >> > >> > So, one section mentions IPv6-only servers, >> >> Please note the condition is *combining 464XLAT with BIH*. The draft >> clearly identifies that. >> I don't see the harm if a draft to mention the possible relationship >> with other from that same SDO considering same goal they would like to >> achieve. >> >> >> > and another section explicitly >> > says "the IPv4 Internet" where by definition, there cannot be IPv6-only >> > servers. >> >> (*)The section 2 helps to justify the BCP applicability to >> 464xlat(i.e. IPv4 app through IPv6 network talk to IPv6 server). BIH >> doesn't need to be justified in this draft, because it already a >> standard track. It doesn't make sense to mix that with section 1 >> statement. >> To be clear, the logic is >> 1) 464xlat is a BCP in the scenario of IPv4 app through IPv6 network >> talking to IPv6 server. > > > sorry, where in the Section 2 said 464xlat is a BCP in the scenario of IPv4 > app through IPv6 network talking to *IPv6 server* ?? - maoke Please seriously read the rest of parts. No answer/reply would be treated as acknowleged. BRs Gang >> Section 2 help to answer that >> 2) BIH is a standard track solution in the scenario of IPv4 apps >> talking to IPv6. The applicabilities are already justified in RFC6535. >> But mentioned the possibilities of cooperation are >> informative/beneficial to readers. >> >> >> >So one section talks about IPv6-only servers, and another section >> > of the same document declares them to be out of scope. >> >> If 464 BCP means the draft is only granted to talk about 464, which >> exclude everything beyong the scope. >> I would like to ask why "DNS Proxy Implementation" is ranked with >> *SHOULD*. It should be out of the scope according to your logic. >> But it's not true I guess, beacause it provides a valuable effcient >> data path to 464xlat. >> It's verified no technical harm and makes 464xlat is better. >> The same reason is also applied to BIH. Compared to that, BIH is only >> *mentioned* >> >> >> > In order to resolve the contradiction, either you modify Section 2 to >> > expand the scope to include IPv6-only servers, or you modify Section 1 >> > to >> > remove the mention to BIH. Given the two choices I think it's better to >> > remove BIH, because as soon as IPv6-only servers are in scope, this >> > document will suddenly become a BCP on "how IPv4-only nodes should >> > communicate with IPv6-only servers", and I don't think we have >> > consensus >> > that yet. >> > >> I don't see the necessity. Please see(*) >> >> BRs >> >> Gang >> > From despres.remi@laposte.net Fri Sep 7 03:16:28 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1931E21F86D6 for ; Fri, 7 Sep 2012 03:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.315 X-Spam-Level: X-Spam-Status: No, score=-1.315 tagged_above=-999 required=5 tests=[AWL=0.633, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2D2IjdiD5Sj3 for ; Fri, 7 Sep 2012 03:16:27 -0700 (PDT) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.1]) by ietfa.amsl.com (Postfix) with ESMTP id C229121F8690 for ; Fri, 7 Sep 2012 03:16:26 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2102.sfr.fr (SMTP Server) with ESMTP id 295DE7000133; Fri, 7 Sep 2012 12:16:26 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2102.sfr.fr (SMTP Server) with ESMTP id CD5177000075; Fri, 7 Sep 2012 12:16:25 +0200 (CEST) X-SFR-UUID: 20120907101625841.CD5177000075@msfrf2102.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-30--661402082 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Fri, 7 Sep 2012 12:16:25 +0200 Message-Id: References: To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 10:16:28 -0000 --Apple-Mail-30--661402082 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 2012-09-07 12:03, Lorenzo Colitti : > On Fri, Sep 7, 2012 at 6:42 PM, R=E9mi Despr=E9s = wrote: > BIH is the only IETF specification for an IPv4-only application in a = node attached to an IPv6-only network to reach an IPv6-only server = WITHOUT depending on any special node between the two (transparent proxy = or whatever).=20 >=20 > And yet, before the problem it solves actually becomes a problem, = things could change substantially. New, better methods can come along. = It could be obsoleted. It could change. And we'd be stuck with a BCP = that endorses something that's not relevant any more. So if you really = want to mention IPv6-only servers, I would suggest replacing the current = text with the following: >=20 > 464XLAT does not provide a means for IPv4-only applications to = communicate with IPv6-only servers. If this capability is necessary, = 464XLAT can be coupled with another transition mechanisms such as BIH = [RFC6535]. >=20 > That way it's clear that this document does not specify a best = practice for IPv4-only clients to talk to IPv6-only servers, but only = for IPv4-only apps on an IPv6-only network. >=20 > In any case, I think the following points have to be resolved before = we can make progress: >=20 > 1. The conflict between section 1, which talks about IPv6-only = servers, and section 2, which declares them out of scope, must be = resolved. > 2. Before we mention BIH in this document, we should ensure that at = least one implementation of 464XLAT+BIH has been tested. We don't want = to publish a BCP that suggests doing something that has never been = tested. No new comment on the above. > 3. If this document suggests using 464XLAT + BIH together, it needs to = say why the text in the BIH RFC which says "Use of BIH together with a = NAT64 is NOT RECOMMENDED" is not relevant to this case. This is new consideration, but not a problem: - The RFC says that BIH should not send packets to NAT64s. - This doesn't prevent a node supporting BIH to also support 464XLAT = which, precisely is designed to send packets to PLATs, AKA NAT64s. This point underlines how complementary the two specifications are. RD --Apple-Mail-30--661402082 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On Fri, = Sep 7, 2012 at 6:42 PM, R=E9mi Despr=E9s <despres.remi@laposte.net> wrote:
BIH is the only IETF specification = for an IPv4-only application in a node attached to an IPv6-only network = to reach an IPv6-only server WITHOUT depending on any special node = between the two (transparent proxy or whatever). 

And yet, before the problem it = solves actually becomes a problem, things could change substantially. = New, better methods can come along. It could be obsoleted. It could = change. And we'd be stuck with a BCP that endorses something that's not = relevant any more. So if you really want to mention IPv6-only servers, I = would suggest replacing the current text with the following:

464XLAT does not provide a means for IPv4-only = applications to communicate with IPv6-only servers. If this capability = is necessary, 464XLAT can be coupled with another transition mechanisms = such as BIH [RFC6535].

That way it's clear that this document does not = specify a best practice for IPv4-only clients to talk to IPv6-only = servers, but only for IPv4-only apps on an IPv6-only = network.

In any case, I think the following points have to be resolved = before we can make progress:

1. The conflict = between section 1, which talks about IPv6-only servers, and section 2, = which declares them out of scope, must be resolved.
2. Before we mention BIH in this document, we should ensure = that at least one implementation of 464XLAT+BIH has been tested. We = don't want to publish a BCP that suggests doing something that has never = been tested.

No new comment = on the above.

3. If this document suggests using 464XLAT + BIH together, it needs = to say why the text in the BIH RFC which says "Use of BIH together with = a NAT64 is NOT RECOMMENDED" is not relevant to this = case.

This is new consideration, but not a = problem:
- The RFC says that BIH should not send packets to = NAT64s.
- This doesn't prevent a node supporting BIH to also = support 464XLAT which, precisely is designed to send packets to PLATs, = AKA NAT64s.

This point underlines how = complementary the two specifications = are.

RD


<= br>

= --Apple-Mail-30--661402082-- From fibrib@gmail.com Fri Sep 7 03:23:42 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA68321F8753 for ; Fri, 7 Sep 2012 03:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.373 X-Spam-Level: X-Spam-Status: No, score=-3.373 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dFI8hDDanvfI for ; Fri, 7 Sep 2012 03:23:42 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id A02E721F8731 for ; Fri, 7 Sep 2012 03:23:41 -0700 (PDT) Received: by eaai11 with SMTP id i11so894973eaa.31 for ; Fri, 07 Sep 2012 03:23:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=n7HnjcF9UihrseyiNrk0CKurJwJMo6XzY4t7FxLMwy8=; b=BQcHPmmd4O9+AlL+GV/YpsWq9CFbCOWTSY6TSq9RvSRqTCfaaybUddT6Muie9xnmyh IuDviA7s4R5MpjjkJ6ph6hwewzSGRpJOWaPTLP3xaRy66w+gRptsup3zlLfdlj+hqFdP oS1em3wz//z1o3bOpcZO4lDCd/B955PS9YYRTmtFDjsz3/GDelmEYri3pmLE3ORznWgo OHjPa/T8KMxVqcD9tdmr+HbPpNq3cDc1IugAXnFLpfvFVvpmu8XDEQT/mS52hG2ryaxw +tX2HSYqrRzUHa4cV3eydnC5YTglSwpoq4bIibuBpDgIRkoB/+IWXfXHPmjqYDuJAxsq j0LA== MIME-Version: 1.0 Received: by 10.14.202.66 with SMTP id c42mr7132880eeo.35.1347013418637; Fri, 07 Sep 2012 03:23:38 -0700 (PDT) Received: by 10.14.97.9 with HTTP; Fri, 7 Sep 2012 03:23:38 -0700 (PDT) In-Reply-To: References: Date: Fri, 7 Sep 2012 19:23:38 +0900 Message-ID: From: Maoke To: GangChen Content-Type: multipart/alternative; boundary=047d7b33daf453581a04c91a0027 Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 10:23:43 -0000 --047d7b33daf453581a04c91a0027 Content-Type: text/plain; charset=ISO-8859-1 2012/9/7 GangChen > 2012/9/7, Maoke : > > 2012/9/7 GangChen > > > >> Hello Lorenzo, > >> > >> 2012/9/7, Lorenzo Colitti : > >> > On Fri, Sep 7, 2012 at 2:59 PM, GangChen wrote: > >> > > >> >> If you haven't concrete argument and only insist on the claim, > >> >> we will be here for another month while that would delay the work. > >> >> Please to identify what the harm you see to object. . > >> > > >> > > >> > Ok, here's a concrete problem, then: the draft contradicts itself. > >> > >> Thanks for providing the concrete point, I guess your intention is not > >> to identify the technical problem after the reading > >> > >> > Section 1 says: > >> > > >> > By combining 464XLAT with BIH [RFC6535], it is also possible to > >> > provide single IPv4 to IPv6 translation service, which will be > >> > needed > >> > in the future case of IPv6-only servers [...] > >> > > >> > But Section 2 says: > >> > > >> > This BCP only applies when the following two criteria are present: > >> > [...] > >> > 2. There are IPv4-only applications or hosts that must communicate > >> > across the IPv6-only network to reach the IPv4 Internet. > >> > > >> > So, one section mentions IPv6-only servers, > >> > >> Please note the condition is *combining 464XLAT with BIH*. The draft > >> clearly identifies that. > >> I don't see the harm if a draft to mention the possible relationship > >> with other from that same SDO considering same goal they would like to > >> achieve. > >> > >> > >> > and another section explicitly > >> > says "the IPv4 Internet" where by definition, there cannot be > IPv6-only > >> > servers. > >> > >> (*)The section 2 helps to justify the BCP applicability to > >> 464xlat(i.e. IPv4 app through IPv6 network talk to IPv6 server). BIH > >> doesn't need to be justified in this draft, because it already a > >> standard track. It doesn't make sense to mix that with section 1 > >> statement. > >> To be clear, the logic is > >> 1) 464xlat is a BCP in the scenario of IPv4 app through IPv6 network > >> talking to IPv6 server. > > > > > > sorry, where in the Section 2 said 464xlat is a BCP in the scenario of > IPv4 > > app through IPv6 network talking to *IPv6 server* ?? - maoke > > Please seriously read the rest of parts. No answer/reply would be treated > as > acknowleged. > well. i answered here doesn't mean i didn't read the rest. the Section 2 doesn't talk about IPv6-only server and therefore MHO is your 1) and 2) are not qualified. - maoke > > BRs > > Gang > > > >> Section 2 help to answer that > >> 2) BIH is a standard track solution in the scenario of IPv4 apps > >> talking to IPv6. The applicabilities are already justified in RFC6535. > >> But mentioned the possibilities of cooperation are > >> informative/beneficial to readers. > >> > >> > >> >So one section talks about IPv6-only servers, and another section > >> > of the same document declares them to be out of scope. > >> > >> If 464 BCP means the draft is only granted to talk about 464, which > >> exclude everything beyong the scope. > >> I would like to ask why "DNS Proxy Implementation" is ranked with > >> *SHOULD*. It should be out of the scope according to your logic. > >> But it's not true I guess, beacause it provides a valuable effcient > >> data path to 464xlat. > >> It's verified no technical harm and makes 464xlat is better. > >> The same reason is also applied to BIH. Compared to that, BIH is only > >> *mentioned* > >> > >> > >> > In order to resolve the contradiction, either you modify Section 2 to > >> > expand the scope to include IPv6-only servers, or you modify Section 1 > >> > to > >> > remove the mention to BIH. Given the two choices I think it's better > to > >> > remove BIH, because as soon as IPv6-only servers are in scope, this > >> > document will suddenly become a BCP on "how IPv4-only nodes should > >> > communicate with IPv6-only servers", and I don't think we have > >> > consensus > >> > that yet. > >> > > >> I don't see the necessity. Please see(*) > >> > >> BRs > >> > >> Gang > >> > > > --047d7b33daf453581a04c91a0027 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/9/7 GangChen <= phdgang@gmail.com>
2012/9/7, Maoke <fibrib@gmail.com>:
> 2012/9/7 GangChen <phdgang@gmail.com>
>
>> Hello Lorenzo,
>>
>> 2012/9/7, Lorenzo Colitti <lorenzo@google.com>:
>> > On Fri, Sep 7, 2012 at 2:59 PM, GangChen <phdgang@gmail.com> wrote:
>> >
>> >> If you haven't concrete argument and only insist on t= he claim,
>> >> we will be here for another month while that would delay = the work.
>> >> Please to identify what the harm you see to object. =A0.<= br> >> >
>> >
>> > Ok, here's a concrete problem, then: the draft contradict= s itself.
>>
>> Thanks for providing the concrete point, I guess your intention is= not
>> to identify the technical problem after the reading
>>
>> > Section 1 says:
>> >
>> > =A0 =A0By combining 464XLAT with BIH [RFC6535], it is also po= ssible to
>> > =A0 =A0provide single IPv4 to IPv6 translation service, which= will be
>> > needed
>> > =A0 =A0in the future case of IPv6-only servers [...]
>> >
>> > But Section 2 says:
>> >
>> > =A0 =A0This BCP only applies when the following two criteria = are present:
>> > [...]
>> > =A0 =A02. =A0There are IPv4-only applications or hosts that m= ust communicate
>> > =A0 =A0 =A0 =A0across the IPv6-only network to reach the IPv4= Internet.
>> >
>> > So, one section mentions IPv6-only servers,
>>
>> Please note the condition is *combining 464XLAT with BIH*. The dra= ft
>> clearly identifies that.
>> I don't see the harm if a draft to mention the possible relati= onship
>> with other from that same SDO considering same goal they would lik= e to
>> achieve.
>>
>>
>> > and another section explicitly
>> > says "the IPv4 Internet" where by definition, there= cannot be IPv6-only
>> > servers.
>>
>> (*)The section 2 helps to justify the BCP applicability to
>> 464xlat(i.e. IPv4 app through IPv6 network talk to IPv6 server). B= IH
>> doesn't need to be justified in this draft, because it already= a
>> standard track. It doesn't make sense to mix that with section= 1
>> statement.
>> To be clear, the logic is
>> 1) 464xlat is a BCP in the scenario of IPv4 app through IPv6 netwo= rk
>> talking to IPv6 server.
>
>
> sorry, where in the Section 2 said 464xlat is a BCP in the scenario of= IPv4
> app through IPv6 network talking to *IPv6 server* ?? - maoke

Please seriously read the rest of parts. No answer/reply would = be treated as
acknowleged.
=A0
well. i answered here doesn= 't mean i didn't read the rest. the Section 2 doesn't talk abou= t IPv6-only server and therefore MHO is your 1) and 2) are not qualified.= =A0- maoke
=A0

BRs

Gang


>> Section 2 help to answer that
>> 2) BIH is a standard track solution in the scenario of IPv4 apps >> talking to IPv6. The applicabilities are already justified in RFC6= 535.
>> =A0But mentioned the possibilities of cooperation are
>> informative/beneficial to readers.
>>
>>
>> >So one section talks about IPv6-only servers, and another sect= ion
>> > of the same document declares them to be out of scope.
>>
>> If 464 BCP means the draft is only granted to talk about 464, whic= h
>> exclude everything beyong the scope.
>> I would like to ask why "DNS Proxy Implementation" is ra= nked with
>> *SHOULD*. It should be out of the scope according to your logic. >> But it's not true I guess, beacause it provides a valuable eff= cient
>> data path to 464xlat.
>> It's verified no technical harm and makes 464xlat is better. >> The same reason is also applied to BIH. =A0Compared to that, BIH i= s only
>> *mentioned*
>>
>>
>> > In order to resolve the contradiction, either you modify Sect= ion 2 to
>> > expand the scope to include IPv6-only servers, or you modify = Section 1
>> > to
>> > remove the mention to BIH. Given the two choices I think it&#= 39;s better to
>> > remove BIH, because as soon as IPv6-only servers are in scope= , this
>> > document will suddenly become a BCP on "how IPv4-only no= des should
>> > communicate with IPv6-only servers", and I don't thi= nk we have
>> > consensus
>> > that yet.
>> >
>> I don't see the necessity. Please see(*)
>>
>> BRs
>>
>> Gang
>>
>

--047d7b33daf453581a04c91a0027-- From lorenzo@google.com Fri Sep 7 03:36:28 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8193321F87AD for ; Fri, 7 Sep 2012 03:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.74 X-Spam-Level: X-Spam-Status: No, score=-102.74 tagged_above=-999 required=5 tests=[AWL=-0.064, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uhCKbfy72xkF for ; Fri, 7 Sep 2012 03:36:27 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 20E3D21F8799 for ; Fri, 7 Sep 2012 03:36:27 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so4717017obb.31 for ; Fri, 07 Sep 2012 03:36:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=TWoDAR8kWjeH7pK4SwT8vl1FAoivUd7l+EJmanyd9ys=; b=PwkbEHQogBH9XPnmENdWfs4WD9h3sBC7jm45K1cWR2nLEu7fNfupWB4MtBHDFs25s9 LV6kGV+GIx3tTlBdqK2hMNIcdfMSvMdyyJx0DobM8q+ivauWCEzQGVmxxEPNly8sboYZ xy29Gvb+44TQ2mMU8Ro/hNnTKzR9UTNgoGlHTcgI1DA58V8ptc4MPVRw/0g7Xk5n9lHr z7LqMvwQAO4GXKvKT9YVAyYfYBbSu8gWetWDBOkYNJ0EciEcYyf7jLkj9dQu5AU/4fVE 5PQ9nsaWTFMM9rwpPTMWhTIgO3jfxAtjw18j6Sd9LkbkJxZF+d3/XG0NT5bmazEt7M+4 Nnbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=TWoDAR8kWjeH7pK4SwT8vl1FAoivUd7l+EJmanyd9ys=; b=WSFvKTnd8vbtIxTT3sbQ6uLj2Z3L4m42ZpPreKR7T1la96QBYOaEiyVQKKkEWcvUzV SOI5Wny2MB8PuOLyTk5LJ/eTtpQ/gK7T7YHzoO4SfFgNordPCPbwci7A0QCZdYNWgT0E fZyEYLk3nI+dqndkj5mPsoQxr2snqBmwdm1FqQ7Fq3ihY1gXiGr+JQDo/pCN7kLsJNOD UPqV/lKnB+9RMedXzhWDlRVg+2ZQ818jApUUo0cUv4UYBTat3B8zhYxROtM1DqzkB7QR e7s0aokPzjjct3HdVe5amJPr/I2cwQsE/5C4nUMmk+fNswLdQ+qPddOziVJ2lveqf/1Q Yn6g== Received: by 10.182.110.40 with SMTP id hx8mr5242172obb.47.1347014186715; Fri, 07 Sep 2012 03:36:26 -0700 (PDT) Received: by 10.182.110.40 with SMTP id hx8mr5242168obb.47.1347014186617; Fri, 07 Sep 2012 03:36:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.187.8 with HTTP; Fri, 7 Sep 2012 03:36:05 -0700 (PDT) In-Reply-To: References: From: Lorenzo Colitti Date: Fri, 7 Sep 2012 19:36:05 +0900 Message-ID: To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=f46d044516dd19cabb04c91a2e94 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnCwwNIvPEmNi2dy32tS6CksZWEx09PULts6FNmx1AHXfbu0nR+bAuIGrxXULxgxiMheeq7ZKjZC2LTnacfk3LjyCaIKhKFOUBjZgG8jO83KL1aHWuxfo8WOA0cwFuE3kgdqQZLGxl5yx544xDXbqN8uJkovjZIxFYZaOMtwk8NdR5W04gAy3cLlONwNJK686FYpUOE Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 10:36:28 -0000 --f46d044516dd19cabb04c91a2e94 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Sep 7, 2012 at 7:16 PM, R=E9mi Despr=E9s = wrote: > 3. If this document suggests using 464XLAT + BIH together, it needs to sa= y > why the text in the BIH RFC which says "Use of BIH together with a NAT64 = is > NOT RECOMMENDED" is not relevant to this case. > > > This is new consideration, but not a problem: > - The RFC says that BIH should not send packets to NAT64s. > - This doesn't prevent a node supporting BIH to also support 464XLAT > which, precisely is designed to send packets to PLATs, AKA NAT64s. > If you don't want to remove BIH, then please suggest text to address this issue. The text that is currently in the draft does not do so, and since it's a conflict with a standards track RFC, we have to say something about it. --f46d044516dd19cabb04c91a2e94 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Sep 7, 2012 at 7:16 PM, R=E9mi Despr=E9s <despres.remi@lapo= ste.net> wrote:
3. If this document suggests using 464XLAT + B= IH together, it needs to say why the text in the BIH RFC which says "U= se of BIH together with a=A0NAT64 is NOT RECOMMENDED" is not relevant = to this case.

This is new consideration, but not a prob= lem:
- The RFC says that BIH should not send packets to NAT64s.
- This doesn't prevent a node supporting BIH to also support 4= 64XLAT which, precisely is designed to send packets to PLATs, AKA NAT64s.

If you don't want to remove BIH,= then please suggest text to address this issue. The text that is currently= in the draft does not do so, and since it's a conflict with a standard= s track RFC, we have to say something about it.
--f46d044516dd19cabb04c91a2e94-- From phdgang@gmail.com Fri Sep 7 03:45:45 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7282621F8686 for ; Fri, 7 Sep 2012 03:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.879 X-Spam-Level: X-Spam-Status: No, score=-2.879 tagged_above=-999 required=5 tests=[AWL=-0.480, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DnQtJCkRZOjv for ; Fri, 7 Sep 2012 03:45:44 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id EEEC621F85B1 for ; Fri, 7 Sep 2012 03:45:43 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so3302228vbb.31 for ; Fri, 07 Sep 2012 03:45:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=/et9v6r+evgYJFr2QodT1NDEvoP6ip2zL1tpSYqH4zY=; b=xtexeg/wlAhv3+lkRz7uhUT1BNpDF+Z6NS/TMZkyMtmW+Lbx6haq2nthJN3P3D6DrL oLCfhzzysN0vL+G7zVjViqmVse94j9krAXNay+TX+87sVsKYAFAmTVOv6BzziKAZ2fi1 zACXjUj0H3mGwbLgSWG5iBgV9/PIxE86oH6lFVzu1b/3Zg1HLI8pArKtTjixugUGwXZ+ ojbVWklujpqBx5aw72yAmQAkmPZdV8r1fx9ttO45Ln3AHhnR7UmEtKColCwKtVkTm6KI 8BfnWKOFrXoSJt1sazIYRqiAcNFL9IV7zZ8TELIWkGVuWRSWBDAK3zqhXpQFOJaJArPp /bng== MIME-Version: 1.0 Received: by 10.52.37.100 with SMTP id x4mr5344751vdj.56.1347014733273; Fri, 07 Sep 2012 03:45:33 -0700 (PDT) Received: by 10.58.114.231 with HTTP; Fri, 7 Sep 2012 03:45:33 -0700 (PDT) In-Reply-To: References: Date: Fri, 7 Sep 2012 18:45:33 +0800 Message-ID: From: GangChen To: Maoke Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 10:45:45 -0000 Hello Maoke, 2012/9/7, Maoke : > 2012/9/7 GangChen > >> 2012/9/7, Maoke : >> > this item is what you are waiting for my reply to, right? see inline. >> > >> > 2012/9/6 GangChen >> > >> >> 2012/9/6, Maoke : >> >> > hi Gang, >> >> > >> >> > thanks for the links! >> >> > >> >> > 1. i don't think an early conclusion of the authors cannot be >> >> > objected >> >> and >> >> > thought over again, before the last call is closed. >> >> >> >> Sure. If you do think several-months lasted discussion doesn't >> >> convince and would like to boil the ocean, we could re-open it. >> >> But please read the conversion happened before on the list to ensure >> >> new discussion is not backward. >> >> >> >> > 2. i don't think it is a loss to state out of scope (or not to >> >> > mention >> >> that >> >> > at all) for IPv4-only app access to IPv6-only server. >> >> >> >> (*)Those arguments were discussed in the thread of "A way forward for >> >> 464XLAT - using BIH". >> >> The loss and gain have been well identified. The point is adding BIH >> >> only can be complementary to 464xlat scenario, no harm. >> >> If you have further point, please identify. >> >> >> > >> > putting a microwave oven on the top of a fridge has no harm at all, >> > too. >> >> It's good to hear your confirmation on *NO harm* >> > > but we never see a fridge specification states or suggests: if you put yo= ur > oven on the top of the fridge, you can have icecream and meanwhile roast > your chicken. :P Beacause we are discussing the BCP in telecom area, not house decoration :) >terrible specification if i have. > >> >> >> > my >> > point is simple: if 464xlat can solve the problem it identifies, then >> > things are enough. we don't need anything more, even the "anything" ha= s >> > been standard >> >> No problem with 464xlat doing the best in 464. But the point is such >> 464 can't be guaranteed to be pure at different places and different >> times in the real life. *Mentioned* that can only be informative and >> benefit to reader. If we know the answer is good, why not do it? >> > > as Lorenzo mentioned, we haven't confirm the answer is good or the best. So that is the discussion to help the confirm > as Brian pointed out, it is too premature to talk about this. The point should better be discussed on the Behave But the fact is BIH is standard track, we should follow the guidance of RFC= 2026 > why should we do it? > > >> >> > unless we change the scope of the problem. >> >> No need. Please see my mail replying to Lorenzo. >> >> >> >> >> >> >> > this could be >> >> > achieved by simply configuring the IPv6-only server with an RFC6052 >> >> > IPv4-translatable address and relying CLAT RFC6145 translation, >> >> >> >> 1) The IPv4-Embedded IPv6 address on CLAT is inserted with IPv4 >> >> private address. >> > >> > When the two IPv4-embedded IPv6 addresses with conflicted IPv4 address >> >> talk to an IPv4-translatable IPv6 address, it would be failed since >> >> IPv6-only server is confused that outgoing packages should send to >> >> which CLAT. >> >> >> > >> > not very understand. conflicted IPv4 address either causes trouble or >> > running as anycast. what's the scope? what I mean is *replying packages*, because the destination would be same IPv4 address. >> The IPv4 embedded IPv6 address adopted by 464xlat is inserted with >> private IPv4 address. >> Those private IPv4 addresses are likely be same if two CLAT send >> packages to a IPv6 server. >> It's no problem with 464 communications because packages could be >> identified by different IPv6 prefixes. >> but it would be failed sending to a same IPv6 server, because replying >> packages can't distinguish which packages should send to which prefix. >> I hope you could understand. >> > > no. i don't know why the IPv6 server cannot distiguish the sources having > different IPv6 prefixes. > > >> >> >> > >> >> 2) IPv6-only server with IPv4-translatable address would cause one >> >> public IPv4 address. >> >> Most people do IPv6 because IPv4 is limited, so doing this way does >> >> not really buy you anything. >> >> >> > >> > i (the server) may keep early customers from native IPv4 having access >> > without knowing that i have changed my protocol stack and meanwhile >> > increase my native IPv6-only customers. >> >> What I indicate is the needs to allocate the global IPv4 address to >> server. It's nothing to do native IPv4 customer. But you seems mean >> there is also need to customers assigning a global IPv4 address. It >> seems getting that worse. >> > > you misunderstood. i mean > > v4private client -> CLAT -> v6 server with IPv4-translatable > (global) address ^^^^^^^^^^ that is what I talking about > v6 client (native) -> -> v6 server with > IPv4-translatable (global) address that is a native IPv6 communication. Why do you assign the IPv4-translatable (global)IPv6 address to server. BTW, I guess that is not the case we are talking about > is the result. never talk about global ipv4 address for customers. > > >> >> > >> >> 3) There no RFC stated the solution what you called as >> >> RFC6052+RFC6145; >> >> >> > >> > copied from RFC6145: >> > >> > Readers of this document are expected to have read and understood >> > the >> > framework described in [RFC6144 > >]. >> > Implementations of this IPv4/IPv6 >> > translation specification MUST also support the address translation >> > algorithms in [RFC6052 ]. >> > Implementations MAY also support stateful >> > translation [RFC6146 ]. >> > RFC6052 + RFC6145 is a MUST and both are standards. >> >> Please note RFC6145 is an algorithm block. >> There is no justification of scenario applicability >> > > please argue this to the RFC6145 track. Don't understand You mentioned that is qualified, so we need specific texts to approve the scenario applicability. > >> >> >> > and RFC6219 gave you an example of using the both in the practice. >> >> RFC6219 is informational. According to RFC2026, "An "Informational" >> specification >> is published for the general information of the Internet community, >> and does not represent an Internet community consensus or recommendation= . >> " >> >> But BIH is a standard. >> >> I guess what you have indentified is addressed totally. >> I guess we could agree BIH is best selction if IPv4-IPv6 mentioned? >> > > no. your guess is wrong. personally i don't agree. i would like to say it > depends. it is a standard, but only a standard among an amount of. Amount of what? Intentional avoiding could not help you to clarify. It's only can delay the work > on other > hand, i don't like to debate this problem with you right now. it's up to you. But the work still needs to progress. > > however, nobody stop you proposing a "BCP-target" draft for BIH usage, No. The justification of BIH usage was already done in RFC6535. There are no needs stated in this draft. > standing on the BIH itself rather than borrowing another, with different > scope, as the ground of propaganda. I did serious works to reply you point-by-point. BRs Gang >> >> > >> >> whether that is a doable way need to be further justified. But BIH i= s >> >> a standard track >> >> >> > >> > >> >> >> >> > or by a >> >> > NAT64 located anywhere between the IPv4 app and the IPv6 domain >> >> implemented >> >> >> >> I don't get it. If there is NAT64, there is nothing to do with the >> >> scenario you are talking about. >> >> >> >> >> >> >> >> > in anyway not necessarily the socket layer solution, even though BI= H >> >> > does >> >> > possibly work, by a proxy (ALG), etc. >> >> >> >> Please note RFC6535 has two flavors, i.e. header translation and >> >> socket translation. It=92s really not necessarily the socket layer >> >> solution. >> >> >> >> > 3. i don't think the author has tested the BIH with CLAT for an >> >> > IPv6-only >> >> > server, at least i have not seen any discussion/report from the >> authors >> >> or >> >> > WG members about the test. >> >> >> >> (**)I guess you will see the report soon, because we are coding that >> >> right >> >> now. >> >> At this stage, what I can tell is most parts are same in the combinin= g >> >> code. >> >> >> >> > to my understanding, the BIH/CLAT work here is >> >> > not yet practiced. why we need/should put a stuff not yet practiced >> >> > into >> >> a >> >> > BCP?? >> >> >> >> Please don't do the arbitrary objection even you didn't evaluate it. >> >> It is a strange logic. >> >> "I don't do that. I even don't know that. So I think that is not >> >> practiced." >> >> That is an unfair argument. >> >> >> >> > (NOTE, the test result from you only illustrates that BIH itself is >> >> > working, not the BIH/464xlat with IPv4-only app access to IPv6-only >> >> server. >> >> > the tested applications, skype, MSN, etc. are none of business of >> >> > the >> >> > so-called IPv6-only servers). >> >> >> >> Please see the (**) and carefully read my report >> >> http://www.ietf.org/mail-archive/web/v6ops/current/msg12631.html >> >> The shared experiences are in 464 contexts. >> >> With 464xlat, we could easily do *combining 464XLAT with BIH*. >> >> It's of significance. >> >> >> > >> > i think i don't misunderstand anything about your report. i read >> > through >> > the mail and also the doc of the testing. it is good but i think it >> > said, >> > BIH is working, no matter there is 464xlat or not. >> >> No. What I reported is our experience of BIH because 464xlat is not >> appeared in that time. >> I have to do in the way if 464 is unavoidable, even it was recommended >> BIH should not work with NAT64 in RFC6535. >> With 464xlat it's really perfect for us to follow and it's approved >> that is a doable way and two technologies could benefit to each other. >> We share the experiences and confirmed by wg. >> Currently, you are coming here and say "Hi, I'm not happy with that >> for no technical reasons, please remove it" >> > > i was talking about technical reasons but you never saw it. ;-) i cannot > help if you think the point on technical problem statement is not > technical. > > - maoke > > >> It's really unfair. >> >> >> >please identify the >> > benefit of having BIH working together with 464xlat, i.e., what we gai= n >> > through the combination rather than BIH and 464xlat themselves? >> >> 1) it gives the possibilities of 4-6 with a safe reference of standard >> track >> 2)it facilitates IPv6-only deployment >> 3)it's complementary to support IPv4 application >> and etc. >> As I said it would be better if you could progress the work with the >> points that's didn't cover before >> Otherwise, we would repeat the show several months ago >> >> >> > more comprehensively, if 464xlat provides A, BIH provides B, and >> > 464xlat >> + >> > BIH provides A + B but nothing else, >> >> Please note A and B is closely realted. It has same goal/ mostly same >> code/ same strategie. >> A+B is doing a complete and concrete the use case to operators. >> >> >> >> > then i insist that it is not necessary >> > to cite BIH in 464xlat at all. >> >> That is surly known, even whatever happned in the wg and whatever we >> are discussing. >> Fortunately, it's approved that the adding BIH is no technial harm >> after our discussion. >> >> What needing clarification is already said on the list unless you >> create an new point. >> >> I intended to agree Remi comments >> - At a time when there are still discussions on functional aspects of >> 464XLAT, this particular discussion is IMHO a waste of time >> - Preferred approach: keep the sentence, and proceed. >> >> >> >> BRs >> >> Gang >> > >> > - maoke >> > >> > >> >> >> >> > 4. i was even confused by the text "By combining 464XLAT with BIH >> >> > [RFC6535], it is also possible to provide single IPv4/IPv6 >> >> > translation >> >> > service" itself. BIH has done the single IPv4/IPv6 translation >> >> > right? >> >> what >> >> > is the significance of such a "combination"? what is the add-on? >> >> >> >> Same comment with (*). If you have concrete point, please identify. >> >> Ambiguous arguments and arbitrary objections only can waste our energ= y >> >> and time. It doesn't help the document imho. >> >> >> >> > integrating the compressor, condenser, expansion valve, evaporator >> into >> >> > a >> >> > fridge is an innovation (as the authors did for the 464xlat) but we >> >> cannot >> >> > call a "fridge + microwave oven put on the top of the fridge" a new >> >> > "architecture" of better practice. >> >> >> >> I didn't fully get your point. 464xlat is not a fridge actually :) >> >> Again, please directly identify your technical points/concerns. >> >> >> >> >> >> BRs >> >> >> >> Gang >> >> >> >> >> >> >> >> > - maoke >> >> > >> >> > 2012/9/6 GangChen >> >> > >> >> >> 2012/9/6, Maoke : >> >> >> > another objection is, Section 9 states "another, >> >> >> > if combined with BIH [RFC6535 < >> http://tools.ietf.org/html/rfc6535 >> >> >], >> >> >> is >> >> >> > a IPv4 -> IPv6 translation for >> >> >> > reaching IPv6-only servers from IPv4-only clients that can no= t >> >> >> > support IPv6. " >> >> >> > >> >> >> > it sounds to me that 464xlat does suggest to apply BIH, as part >> >> >> > of >> >> >> > the >> >> >> best >> >> >> > practice, for IPv4 client reaching IPv6-only servers. to my >> >> >> understanding, >> >> >> > there could be several alternative ways to achieve that, why we >> >> >> > should >> >> >> > be >> >> >> > bounded with BIH? >> >> >> > >> >> >> > sorry i didn't catch the discussion on this issue before. >> >> >> >> >> >> There was a quite long discussion, >> >> >> since you didn't follow that, I list the links below for your >> >> >> convenience. >> >> >> >> >> >> "A way forward for 464XLAT", started with >> >> >> http://www.ietf.org/mail-archive/web/v6ops/current/msg12521.html >> >> >> "A way forward for 464XLAT - using BIH", started with >> >> >> http://www.ietf.org/mail-archive/web/v6ops/current/msg12631.html >> >> >> "I-D Action: draft-ietf-v6ops-464xlat-02.txt" started with >> >> >> http://www.ietf.org/mail-archive/web/v6ops/current/msg12628.html >> >> >> " [v6ops] draft-ietf-v6ops-464xlat - which status?"started with >> >> >> http://www.ietf.org/mail-archive/web/v6ops/current/msg13035.html >> >> >> .... >> >> >> >> >> >> As Cameron indicated *The conclusion was that the 464XLAT is more >> >> >> complete by making a reference to BIH scenario.* >> >> >> >> >> >> BRs >> >> >> >> >> >> Gang >> >> >> >> >> >> >> >> >> > >> >> >> > 2012/8/22 Fred Baker (fred) >> >> >> > >> >> >> >> I should note that the current thread has a subject line readin= g >> >> >> -06.txt, >> >> >> >> but the current version is -07.txt. You may find the diffs >> >> >> >> (fairly >> >> >> >> extensive) at >> >> >> >> >> >> >> >> >> http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-464xlat-07.txt >> >> >> >> >> >> >> >> >> >> >> >> On Aug 21, 2012, at 8:45 AM, Fred Baker (fred) wrote: >> >> >> >> >> >> >> >> > This is to open a two week Working Group last Call on >> >> >> >> > >> >> >> >> > http://tools.ietf.org/html/draft-ietf-v6ops-464xlat >> >> >> >> > "464XLAT: Combination of Stateful and Stateless Translation"= , >> >> >> Masataka >> >> >> >> > Mawatari, Masanobu Kawashima, Cameron Byrne, 19-Aug-12 >> >> >> >> > >> >> >> >> > Please read it now. We are interested in, among other things, >> >> >> technical >> >> >> >> commentary on the draft and the working group's perception on >> >> >> >> its >> >> >> >> usefulness to its target audience. >> >> >> >> > _______________________________________________ >> >> >> >> > v6ops mailing list >> >> >> >> > v6ops@ietf.org >> >> >> >> > https://www.ietf.org/mailman/listinfo/v6ops >> >> >> >> >> >> >> >> ---------------------------------------------------- >> >> >> >> The ignorance of how to use new knowledge stockpiles >> exponentially. >> >> >> >> - Marshall McLuhan >> >> >> >> >> >> >> >> _______________________________________________ >> >> >> >> v6ops mailing list >> >> >> >> v6ops@ietf.org >> >> >> >> https://www.ietf.org/mailman/listinfo/v6ops >> >> >> >> >> >> >> > >> >> >> >> >> > >> >> >> > >> > From ietfc@btconnect.com Fri Sep 7 03:46:26 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C56D21F87C0 for ; Fri, 7 Sep 2012 03:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.024 X-Spam-Level: X-Spam-Status: No, score=-3.024 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id moYxnkGelArX for ; Fri, 7 Sep 2012 03:46:25 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe001.messaging.microsoft.com [216.32.180.184]) by ietfa.amsl.com (Postfix) with ESMTP id F043D21F87AE for ; Fri, 7 Sep 2012 03:46:24 -0700 (PDT) Received: from mail82-co1-R.bigfish.com (10.243.78.251) by CO1EHSOBE012.bigfish.com (10.243.66.75) with Microsoft SMTP Server id 14.1.225.23; Fri, 7 Sep 2012 10:46:23 +0000 Received: from mail82-co1 (localhost [127.0.0.1]) by mail82-co1-R.bigfish.com (Postfix) with ESMTP id CD3178A00C8; Fri, 7 Sep 2012 10:46:23 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.253.85; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0710HT005.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -26 X-BigFish: PS-26(zz98dI9371Ic89bh936eI542M1432I111aIzz1202hzz8275ch1033IL8275bh8275dhz2dh2a8h5a9h668h839hd24hf0ah107ah1177h1179h1288h304l1155h) Received: from mail82-co1 (localhost.localdomain [127.0.0.1]) by mail82-co1 (MessageSwitch) id 1347014781947346_18142; Fri, 7 Sep 2012 10:46:21 +0000 (UTC) Received: from CO1EHSMHS005.bigfish.com (unknown [10.243.78.254]) by mail82-co1.bigfish.com (Postfix) with ESMTP id DA1367C0048; Fri, 7 Sep 2012 10:46:21 +0000 (UTC) Received: from DB3PRD0710HT005.eurprd07.prod.outlook.com (157.56.253.85) by CO1EHSMHS005.bigfish.com (10.243.66.15) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 7 Sep 2012 10:46:21 +0000 Received: from DBXPRD0410HT001.eurprd04.prod.outlook.com (157.56.252.149) by pod51017.outlook.com (10.255.75.40) with Microsoft SMTP Server (TLS) id 14.16.190.9; Fri, 7 Sep 2012 10:46:14 +0000 Message-ID: <03e501cd8ce5$4ab52f80$4001a8c0@gateway.2wire.net> From: t.petch To: Cameron Byrne References: <504392E0.8070802@bogus.com><448050D4-84F9-4F52-BF7E-347EA451A96C@laposte.net><0AB559C2-855C-41F3-92D1-07F973EB760A@laposte.net> Date: Fri, 7 Sep 2012 11:38:44 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.252.149] Content-Transfer-Encoding: quoted-printable X-OriginatorOrg: btconnect.com Cc: v6ops WG Subject: [v6ops] 464XLAT - /64 sharing was support of /64 delegated prefixes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 10:46:26 -0000 Cameron Just to clarify, in your point 3), is the emphasis on 'standard', that is that ND-Proxy is not on standards track? I see sharing a /64 as just another example of NBMA, which IPv6 sort of supports. In this case, the 464 device is the hub and the IPv6 access network one spoke and the downstream devices another set of spokes. OK, the downstream devices may think that they are broadcast but they are not, they are NBMA in this case. Tom Petch ----- Original Message ----- From: "Cameron Byrne" To: "R=E9mi Despr=E9s" Cc: "v6ops WG" Sent: Thursday, September 06, 2012 4:27 PM Subject: Re: [v6ops] 464XLAT - support of /64 delegated prefixes R=E9mi , On Thu, Sep 6, 2012 at 7:22 AM, R=E9mi Despr=E9s wrote: > > 2012-09-06 15:16, Cameron Byrne : > > > On Sep 6, 2012 1:03 AM, "Lorenzo Colitti" wrote: >> >> On Thu, Sep 6, 2012 at 4:54 PM, Maoke wrote: >>> >>> how can we ensure the above addresses do not conflict with any manually, >>> arbitrarily configured addresses? i am lost. :P - maoke >> >> >> AIUI, we say "conflicts are impossible, because this is a reserved range", >> and then we cross our fingers. >> > > I agree with Lorenzo's sarcasm. > > This "sarcasm" isn't deserved: one who manually configures a host with an > invalid address with regard to RFC 4291 should cross his fingers in all > cases, with 464XLAT or not. > Here are the facts as i see them: 1. Many people on the list, including me, say we must share a /64 from WAN to LAN 2. Multiple real world implementations of this /64 sharing exists in various types of nodes, including the AOSP Android code. Hermant also references he has experience with some CPE that share a /64 in production networks using ND Proxy. And there is also the case of a CPE that simply bridges WAN to LAN and has a logical / virtual place on that share /64. Lorenzo also specified a method here http://www.ietf.org/mail-archive/web/v6ops/current/msg13977.html 3. There is no standards track way to share a /64 from WAN to LAN, the party line is DHCP-PD is the solution. New protocol work happens in 6MAN. 4. Remi has provided, what i consider, to be a workable solution that avoids the case of NAT44. So, we have a problem since #1 and #3 are a challenge, and #2 exists #4 is workable, but it has opponents and requires "hard coding" and really is not core to 464XLAT. Removing the need for NAT44 is not a goal, the overhead of having NAT44 is inconsequential to a modern CPE, including smartphones. Related to hard coding, there is no RFC1918 address that we can pick. ISPs are now dictating how residential LANs must be configured so they do not overlap with the SP network's use of RFC1918 space ... http://keithbartholomew.com/2012/04/how-att-u-verse-broke-my-home-networ k/ > Besides, it is particularly unexpected from you, after you stated "In the > case of the Android CLAT code that was submitted to AOSP, the /64 is simply > copied from the WAN 3G/4G interfaces to the LAN. No magic. No ND Proxy. No > DHCP. But, it works for all known cases". > With this, collisions between CLATs and host addresses are possible even > with well-behaved hosts =3D> The need to cross fingers is permanent ;-)= . No, NDP/DAD runs normally on the LAN side as a /64 and the WAN side is a /128 ... /128 on WAN is normal operations for a Android phone on a 3GPP network. The main takeaway from this: implementation specific solutions are ok and left to the implementer and network operator to consider pros and cons. The party line remains: DHCP-PD is best! While reality dictates and the 464XLAT I-D must reflect that /64 sharing exists. I am not confident that this group of folks who don't have a very good understanding of probability (manually configures 64 bit collisions?!) will come to a consensus on a general solution, and even if they can come to a consensus, 464XLAT is not the right vehicle for specifying how a /64 is shared across interfaces. Let us just say /64 sharing exists and move on. If we believe /64 must be codified on standards track, 6MAN may be the place for that with its own I-D. > By using the proposed IANA-EUI-64 based /96, this is avoided and, with a MAY > in the draft, the somewhat risky choice you have described remains possible. > > That said, we have been pushing this draft for a year trying to drive > concensus. If we do not limit the scope to the core objective we will be > here for another year while the issue of ipv4-only hosts and apps delays and > hinders broader ipv6 deployment. > > On this, we agree. > > Still convinced to be one of the best supporters of a good 464XLAT without > undue delay, Thanks again! > Best regards, > RD > > > CB >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From fibrib@gmail.com Fri Sep 7 03:54:54 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9597921F87C9 for ; Fri, 7 Sep 2012 03:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.955 X-Spam-Level: X-Spam-Status: No, score=-2.955 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wqSB3DkwH2Qu for ; Fri, 7 Sep 2012 03:54:53 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2FCD021F87C8 for ; Fri, 7 Sep 2012 03:54:53 -0700 (PDT) Received: by eaai11 with SMTP id i11so906208eaa.31 for ; Fri, 07 Sep 2012 03:54:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=E70y3Oa6AAp8k948LCcfZbePnW8jVH4QurgsUP/DTNc=; b=gA7ITglmtq/kC/MOehmObJIPx9BW5pwRMEjbvDsYqhpWCMgtEmoue6XzPAZO3qoQ2+ LF+oAV2+oqgl5/EvSwISWyMw8gApGQ4YxmRitHbecYnZO7+avwHLvQAcob3GOEG+bZ5S EywE2gQs3s/YddSgVjdWGtWGfUgfy3++ilTHdWaHgq4OYa12oExInDozXjNjlDPZ/HNw 1qyqADoJlPFtqN3DlOLNherqBGvSZvpgyGFWDUas63x4KmWnLBpgB/g63LItoe//Co// zvVkT40vG6SeY/VvPh0Tq24r2BKIyfUC976fouw2cp3ECuTcPrWkvN1INEds27G36eTd 456g== MIME-Version: 1.0 Received: by 10.14.202.71 with SMTP id c47mr7226729eeo.42.1347015292216; Fri, 07 Sep 2012 03:54:52 -0700 (PDT) Received: by 10.14.97.9 with HTTP; Fri, 7 Sep 2012 03:54:51 -0700 (PDT) In-Reply-To: References: Date: Fri, 7 Sep 2012 19:54:51 +0900 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=047d7b343e38ffe69804c91a6f55 Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 10:54:54 -0000 --047d7b343e38ffe69804c91a6f55 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/9/7 R=E9mi Despr=E9s > > 2012-09-07 12:03, Lorenzo Colitti : > > On Fri, Sep 7, 2012 at 6:42 PM, R=E9mi Despr=E9s wrote: > >> BIH is the only IETF specification for an IPv4-only application in a nod= e >> attached to an IPv6-only network to reach an IPv6-only server WITHOUT >> depending on any special node between the two (transparent proxy or >> whatever). >> > > And yet, before the problem it solves actually becomes a problem, things > could change substantially. New, better methods can come along. It could = be > obsoleted. It could change. And we'd be stuck with a BCP that endorses > something that's not relevant any more. So if you really want to mention > IPv6-only servers, I would suggest replacing the current text with the > following: > > 464XLAT does not provide a means for IPv4-only applications to communicat= e > with IPv6-only servers. If this capability is necessary, 464XLAT can be > coupled with another transition mechanisms such as BIH [RFC6535]. > > That way it's clear that this document does not specify a best practice > for IPv4-only clients to talk to IPv6-only servers, but only for IPv4-onl= y > apps on an IPv6-only network. > > In any case, I think the following points have to be resolved before we > can make progress: > > 1. The conflict between section 1, which talks about IPv6-only servers, > and section 2, which declares them out of scope, must be resolved. > 2. Before we mention BIH in this document, we should ensure that at least > one implementation of 464XLAT+BIH has been tested. We don't want to publi= sh > a BCP that suggests doing something that has never been tested. > > > No new comment on the above. > > 3. If this document suggests using 464XLAT + BIH together, it needs to sa= y > why the text in the BIH RFC which says "Use of BIH together with a NAT64 = is > NOT RECOMMENDED" is not relevant to this case. > > > This is new consideration, but not a problem: > > actually, Remi, i have to point out it is problem. this is related to my talk with you that the private addresses are also possibly used for a server. 0. the domain operator makes address planning with the private address in order to avoid potential conflict; 1. a host having private IPv4 address are located in a LAN behind BIH/CLAT box, with IPv6 prefixes configured with the box; 2. it is running a server and a client peer behind another CLAT, somehow, know the server's address (it is private but static); 3. the client sends out a request to the server's IPv4 address, both src and dst are translated by the CLAT statelessly; 4. the CLAT of the server side decodes the IPv4-converted addresses and delivered the translated packet to the server; 5. the server responds the request, while the reply arrives at the BIH/CLAT, trouble happens: which module to proceed? if it is the CLAT, fortunately, we are lucky, and things just worked as IVI with double translation. if BIH takes the session, well, what would happen? i don't think BIH is covering this case too with its synthetic IPv4 and the real IPv6 addresses because the peer (the client) is not IPv6 now at all. BIH state needs to be established by the initiator of the session but combining it with CLAT makes it uncertain when the initiation bypasses BIH at all. this is a very realistic case when we want to deploy an in-domain server group. and 464xlat itself can works well. but the combination of 464xlat to BIH may cause some trouble. Lorenzo and me argued that the combination was not tested. this is a real case of risk. of course, we may patch it, but it is definitely far beyond one paragraph stating that "combining them is useful". if we have time, i may find more and more cases where the combination introduces uncertainty. therefore i think it is safe to scope out the problem right now. - maoke > > - The RFC says that BIH should not send packets to NAT64s. > - This doesn't prevent a node supporting BIH to also support 464XLAT > which, precisely is designed to send packets to PLATs, AKA NAT64s. > > This point underlines how complementary the two specifications are. > > RD > > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --047d7b343e38ffe69804c91a6f55 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/9/7 R=E9mi Despr=E9s <despr= es.remi@laposte.net>

2012-09-07 12:03, Lorenzo= Colitti :

On Fri, Sep= 7, 2012 at 6:42 PM, R=E9mi Despr=E9s <despres.remi@laposte.net= > wrote:
BIH is the only IETF specification for = an IPv4-only application in a node attached to an IPv6-only network to reac= h an IPv6-only server WITHOUT depending on any special node between the two= (transparent proxy or whatever).=A0

And yet, before the problem it solve= s actually becomes a problem, things could change substantially. New, bette= r methods can come along. It could be obsoleted. It could change. And we= 9;d be stuck with a BCP that endorses something that's not relevant any= more. So if you really want to mention IPv6-only servers, I would suggest = replacing the current text with the following:

464XLAT does not provide a means for IPv4-only applicat= ions to communicate with IPv6-only servers. If this capability is necessary= , 464XLAT can be coupled with another transition mechanisms such as BIH=A0[= RFC6535].

That way it's clear that this document does not spe= cify a best practice for IPv4-only clients to talk to IPv6-only servers, bu= t only for IPv4-only apps on an IPv6-only network.

In any case, I think the following points have to be resolved before w= e can make progress:

1. The conflict between secti= on 1, which talks about IPv6-only servers, and section 2, which declares th= em out of scope, must be resolved.
2.=A0Before we mention BIH in this document, we should ensure that at = least one implementation of 464XLAT+BIH has been tested. We don't want = to publish a BCP that suggests doing something that has never been tested.<= /div>

No new comment on the above.

3. If this document suggests using 464XLAT + BIH together, it needs to= say why the text in the BIH RFC which says "Use of BIH together with = a=A0NAT64 is NOT RECOMMENDED" is not relevant to this case.

This is new consideration, but not a prob= lem:
=A0
=A0
actually, Rem= i, i have to point out it is problem. this is related to my talk with you t= hat the private addresses are also possibly used for a server.
=A0
0. the domain operator makes address planning with the p= rivate address in order to avoid potential conflict;
1.=A0a=A0ho= st=A0having private IPv4 address are located in a LAN behind BIH/CLAT box, = with IPv6 prefixes configured with the=A0box; =A0=A0
2.=A0it is running a server and=A0a client=A0peer behind another CLAT,= somehow, know the server's address (it is private but static);
<= div>3.=A0the client sends out a request to the server's IPv4 address, b= oth src and dst are translated by the CLAT statelessly;
4. the CLAT of the server side decodes the IPv4-converted addresses an= d delivered the translated packet to the server;
5. the server r= esponds the request, while the reply arrives at the BIH/CLAT, trouble happe= ns: which module to proceed? if it is the CLAT, fortunately, we are lucky, = and things just worked as IVI with double translation. if BIH takes the ses= sion, well, what would happen? i don't think BIH is covering this case = too with its synthetic IPv4 and the real IPv6 addresses because the peer (t= he client) is not IPv6 now at all. BIH state needs to be established by the= initiator of the session but combining it with CLAT makes it uncertain whe= n the initiation bypasses BIH at all.
=A0
this is a very realistic case when we want to deploy an = in-domain server group. and 464xlat itself can works well. but the combinat= ion of 464xlat to BIH may cause some trouble. Lorenzo and me argued that th= e combination was not tested. this is a real case of risk. of course, we ma= y patch it, but it is definitely far beyond one paragraph stating that &quo= t;combining them is useful".
=A0
if we have time, i may find more and more cases where th= e combination introduces uncertainty. therefore i think it is safe to scope= out the problem right now.
=A0
- maoke
=A0=
=A0
- T= he RFC says that BIH should not send packets to NAT64s.
- This doesn't prevent a node supporting BIH to also support 464XL= AT which, precisely is designed to send packets to PLATs, AKA NAT64s.
=

This point underlines how complementary the two specifi= cations are.

RD
=




<= /div>
_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops


--047d7b343e38ffe69804c91a6f55-- From ietfc@btconnect.com Fri Sep 7 04:01:25 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A48D921F8766 for ; Fri, 7 Sep 2012 04:01:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.166 X-Spam-Level: X-Spam-Status: No, score=-3.166 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iG7csNI+N67t for ; Fri, 7 Sep 2012 04:01:24 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe006.messaging.microsoft.com [213.199.154.144]) by ietfa.amsl.com (Postfix) with ESMTP id CB1BF21F8703 for ; Fri, 7 Sep 2012 04:01:23 -0700 (PDT) Received: from mail30-db3-R.bigfish.com (10.3.81.246) by DB3EHSOBE006.bigfish.com (10.3.84.26) with Microsoft SMTP Server id 14.1.225.23; Fri, 7 Sep 2012 11:01:22 +0000 Received: from mail30-db3 (localhost [127.0.0.1]) by mail30-db3-R.bigfish.com (Postfix) with ESMTP id 19A1A2E0253; Fri, 7 Sep 2012 11:01:22 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.249.213; KIP:(null); UIP:(null); IPV:NLI; H:AM2PRD0710HT001.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: PS-23(zz98dI9371Ic89bh542Mzz1202hzz8275ch1033IL8275bh8275dhz2dh2a8h5a9h668h839hd24hf0ah107ah1177h1179h1288h304l1155h) Received: from mail30-db3 (localhost.localdomain [127.0.0.1]) by mail30-db3 (MessageSwitch) id 1347015680112720_672; Fri, 7 Sep 2012 11:01:20 +0000 (UTC) Received: from DB3EHSMHS014.bigfish.com (unknown [10.3.81.241]) by mail30-db3.bigfish.com (Postfix) with ESMTP id 0E2D640054; Fri, 7 Sep 2012 11:01:20 +0000 (UTC) Received: from AM2PRD0710HT001.eurprd07.prod.outlook.com (157.56.249.213) by DB3EHSMHS014.bigfish.com (10.3.87.114) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 7 Sep 2012 11:01:16 +0000 Received: from DBXPRD0410HT004.eurprd04.prod.outlook.com (157.56.252.149) by pod51017.outlook.com (10.255.165.36) with Microsoft SMTP Server (TLS) id 14.16.190.9; Fri, 7 Sep 2012 11:01:12 +0000 Message-ID: <041e01cd8ce7$61aeebc0$4001a8c0@gateway.2wire.net> From: t.petch To: Lorenzo Colitti , =?iso-8859-1?Q?R=E9mi_Despr=E9s?= References: <504392E0.8070802@bogus.com><448050D4-84F9-4F52-BF7E-347EA451A96C@laposte.net> Date: Fri, 7 Sep 2012 11:55:57 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.252.149] Content-Transfer-Encoding: quoted-printable X-OriginatorOrg: btconnect.com Cc: v6ops WG Subject: Re: [v6ops] 464XLAT - support of /64 delegated prefixes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 11:01:25 -0000 ----- Original Message ----- From: "Lorenzo Colitti" To: "R=E9mi Despr=E9s" Cc: "v6ops WG" Sent: Thursday, September 06, 2012 8:48 AM On Thu, Sep 6, 2012 at 4:20 PM, R=E9mi Despr=E9s wrote: > Let's assume IANA has reserved for CLATs the following subranges of the > range available for allocation in RFC5342 section 2.2.2: > 02-00-5E-10-0A-xx-xx-xx for CLATs using 10../8 > 02-00-5E-10-AC-1x-xx-xx for CLATs using 172.16../12 > 02-00-5E-10-C0-A8-xx-xx for CLATs using 192.168../16 > Since assuming the impossible leads to failure, we first need to ensure that: 1. IANA has the authority to assign such address space. 2. IANA is willing to assign such address space 3. IANA has the techical capability (e.g., processes) to assign such address space. Without answers to the above questions, we cannot proceed. Remi, do you know the answers? My answer would be yes, or, more colloquially, 'RTFM':-) The cited section says " IANA EUI-64 identifier allocations under the IANA OUI must meet the following requirements: o must be for standards purposes (either for an IETF Standard or other standard related to IETF work), o must be for a block of a power-of-two identifiers starting at a boundary which is an equal or greater power of two, including the allocation of one (2**0) identifier, o must not be used to evade the requirement for vendors to obtain their own block of identifiers from the IEEE, and o must be documented in an Internet Draft or RFC. In addition, approval must be obtained as follows (see the procedure in Section 5.1): Small to medium allocations of a block of 1, 2, 4, ..., 134217728, 268435456 (2**0, 2**1, 2**2, ..., 2**27, 2**28) EUI-64 identifiers require Expert Review. Allocations of any size, including 536870912 (2**29) or more EUI-64 identifiers, may be made with IESG Ratification (see Section 5.1). To simplify record keeping, all allocations of 65536 (2**16) or less EUI-64 identifiers shall have the Group bit unspecified, that is, shall be allocations of parallel equal size blocks of multicast and unicast identifiers, even if one of these two types is not needed for the proposed use" so no problem with IANA. As at the time of this message, the indicated addresses are available. IANA calls them Ethernet numbers rather than OUI. Tom Petch From fibrib@gmail.com Fri Sep 7 04:09:26 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44C5F21F87DD for ; Fri, 7 Sep 2012 04:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=-0.192, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a1xVCqxfVY63 for ; Fri, 7 Sep 2012 04:09:24 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4E27321F87CB for ; Fri, 7 Sep 2012 04:09:23 -0700 (PDT) Received: by eekb45 with SMTP id b45so1183237eek.31 for ; Fri, 07 Sep 2012 04:09:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=teKhGzHOVNl9j/fWdodmdMB3U+IVhNQveZ0mrc11Jso=; b=TPRRtGMvSRSJ17OicvWG4NNr95rh8XfrSl6todZ+tbv2vlLbCc1zh9NBaKwMjwCl5Z 0GKoCx5t4zmtqdUxytxWCBw282djpuJTUMwRbwNzsYot0IAoBFoMNJaXynSYtfrtc4Ed vf+58JtFVDiaIC/g+xCc4pk0aLjGpOJcItkL2kaZbbSuESsrr5NdcxyPGHze7mcwBpx/ +G9BvUqawv8nHtfQpNAm+ThWQFZ0uvLzNWPDa4RPsOCwOLvVc8NVErkW7Ehom5tqhib0 QPkI7rh477jq9XfP4q57YcycJxHifhFEeDMRleIFarJn0jY9qEFk3bSSn/izHq5D+sDA Dctg== MIME-Version: 1.0 Received: by 10.14.202.66 with SMTP id c42mr7306810eeo.35.1347016162457; Fri, 07 Sep 2012 04:09:22 -0700 (PDT) Received: by 10.14.97.9 with HTTP; Fri, 7 Sep 2012 04:09:22 -0700 (PDT) In-Reply-To: References: Date: Fri, 7 Sep 2012 20:09:22 +0900 Message-ID: From: Maoke To: GangChen Content-Type: multipart/alternative; boundary=047d7b33daf4debbf704c91aa3b6 Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 11:09:26 -0000 --047d7b33daf4debbf704c91aa3b6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 2012/9/7 GangChen > Hello Maoke, > > 2012/9/7, Maoke : > > 2012/9/7 GangChen > > > >> 2012/9/7, Maoke : > >> > this item is what you are waiting for my reply to, right? see inline= . > >> > > >> > 2012/9/6 GangChen > >> > > >> >> 2012/9/6, Maoke : > >> >> > hi Gang, > >> >> > > >> >> > thanks for the links! > >> >> > > >> >> > 1. i don't think an early conclusion of the authors cannot be > >> >> > objected > >> >> and > >> >> > thought over again, before the last call is closed. > >> >> > >> >> Sure. If you do think several-months lasted discussion doesn't > >> >> convince and would like to boil the ocean, we could re-open it. > >> >> But please read the conversion happened before on the list to ensur= e > >> >> new discussion is not backward. > >> >> > >> >> > 2. i don't think it is a loss to state out of scope (or not to > >> >> > mention > >> >> that > >> >> > at all) for IPv4-only app access to IPv6-only server. > >> >> > >> >> (*)Those arguments were discussed in the thread of "A way forward f= or > >> >> 464XLAT - using BIH". > >> >> The loss and gain have been well identified. The point is adding BI= H > >> >> only can be complementary to 464xlat scenario, no harm. > >> >> If you have further point, please identify. > >> >> > >> > > >> > putting a microwave oven on the top of a fridge has no harm at all, > >> > too. > >> > >> It's good to hear your confirmation on *NO harm* > >> > > > > but we never see a fridge specification states or suggests: if you put > your > > oven on the top of the fridge, you can have icecream and meanwhile roas= t > > your chicken. :P > > Beacause we are discussing the BCP in telecom area, not house decoration = :) > > >terrible specification if i have. > > > >> > >> > >> > my > >> > point is simple: if 464xlat can solve the problem it identifies, the= n > >> > things are enough. we don't need anything more, even the "anything" > has > >> > been standard > >> > >> No problem with 464xlat doing the best in 464. But the point is such > >> 464 can't be guaranteed to be pure at different places and different > >> times in the real life. *Mentioned* that can only be informative and > >> benefit to reader. If we know the answer is good, why not do it? > >> > > > > as Lorenzo mentioned, we haven't confirm the answer is good or the best= . > > So that is the discussion to help the confirm > > > as Brian pointed out, it is too premature to talk about this. > > The point should better be discussed on the Behave > But the fact is BIH is standard track, we should follow the guidance of > RFC2026 > > > > > why should we do it? > > > > > >> > >> > unless we change the scope of the problem. > >> > >> No need. Please see my mail replying to Lorenzo. > >> > >> >> > >> >> > >> >> > this could be > >> >> > achieved by simply configuring the IPv6-only server with an RFC60= 52 > >> >> > IPv4-translatable address and relying CLAT RFC6145 translation, > >> >> > >> >> 1) The IPv4-Embedded IPv6 address on CLAT is inserted with IPv4 > >> >> private address. > >> > > >> > When the two IPv4-embedded IPv6 addresses with conflicted IPv4 addre= ss > >> >> talk to an IPv4-translatable IPv6 address, it would be failed since > >> >> IPv6-only server is confused that outgoing packages should send to > >> >> which CLAT. > >> >> > >> > > >> > not very understand. conflicted IPv4 address either causes trouble o= r > >> > running as anycast. what's the scope? > > what I mean is *replying packages*, because the destination would be > same IPv4 address. > they have different IPv6 prefixes and routing can guide them to different CLATs. what the problem? > > >> The IPv4 embedded IPv6 address adopted by 464xlat is inserted with > >> private IPv4 address. > >> Those private IPv4 addresses are likely be same if two CLAT send > >> packages to a IPv6 server. > >> It's no problem with 464 communications because packages could be > >> identified by different IPv6 prefixes. > >> but it would be failed sending to a same IPv6 server, because replying > >> packages can't distinguish which packages should send to which prefix. > >> I hope you could understand. > >> > > > > no. i don't know why the IPv6 server cannot distiguish the sources havi= ng > > different IPv6 prefixes. > > > > > >> > >> > >> > > >> >> 2) IPv6-only server with IPv4-translatable address would cause one > >> >> public IPv4 address. > >> >> Most people do IPv6 because IPv4 is limited, so doing this way does > >> >> not really buy you anything. > >> >> > >> > > >> > i (the server) may keep early customers from native IPv4 having acce= ss > >> > without knowing that i have changed my protocol stack and meanwhile > >> > increase my native IPv6-only customers. > >> > >> What I indicate is the needs to allocate the global IPv4 address to > >> server. It's nothing to do native IPv4 customer. But you seems mean > >> there is also need to customers assigning a global IPv4 address. It > >> seems getting that worse. > >> > > > > you misunderstood. i mean > > > > v4private client -> CLAT -> v6 server with IPv4-translatable > > (global) address > ^^^^^^^^^^ > > that is what I talking about > see above, what's the problem? > > > v6 client (native) -> -> v6 server with > > IPv4-translatable (global) address > > that is a native IPv6 communication. > Why do you assign the IPv4-translatable (global)IPv6 address to server. > BTW, I guess that is not the case we are talking about > i just answer your previous question why someone may be interested to deploy IPv6-only server with IPv4-translatable address. the reason is enlarging the connectivity to native IPv6 clients without losing the services to original IPv4 clients. yes, this is out of scope but try to share my understanding with answer your question. > > > > is the result. never talk about global ipv4 address for customers. > > > > > >> > >> > > >> >> 3) There no RFC stated the solution what you called as > >> >> RFC6052+RFC6145; > >> >> > >> > > >> > copied from RFC6145: > >> > > >> > Readers of this document are expected to have read and understood > >> > the > >> > framework described in [RFC6144 < > http://tools.ietf.org/html/rfc6144 > >> >]. > >> > Implementations of this IPv4/IPv6 > >> > translation specification MUST also support the address translati= on > >> > algorithms in [RFC6052 ]. > >> > Implementations MAY also support stateful > >> > translation [RFC6146 ]. > >> > RFC6052 + RFC6145 is a MUST and both are standards. > >> > >> Please note RFC6145 is an algorithm block. > >> There is no justification of scenario applicability > >> > > > > please argue this to the RFC6145 track. > > Don't understand > You mentioned that is qualified, so we need specific texts to approve > the scenario applicability. > i mean RFC6145 is working with RFC6052 -- this is a normative statement in the standard RFC6145. > > > > > >> > >> > >> > and RFC6219 gave you an example of using the both in the practice. > >> > >> RFC6219 is informational. According to RFC2026, "An "Informational" > >> specification > >> is published for the general information of the Internet community, > >> and does not represent an Internet community consensus or > recommendation. > >> " > >> > >> But BIH is a standard. > >> > >> I guess what you have indentified is addressed totally. > >> I guess we could agree BIH is best selction if IPv4-IPv6 mentioned? > >> > > > > no. your guess is wrong. personally i don't agree. i would like to say = it > > depends. it is a standard, but only a standard among an amount of. > > Amount of what? Intentional avoiding could not help you to clarify. > It's only can delay the work > com'on. an amount of standards. > > > on other > > hand, i don't like to debate this problem with you right now. > > it's up to you. But the work still needs to progress. > > > > however, nobody stop you proposing a "BCP-target" draft for BIH usage, > > No. The justification of BIH usage was already done in RFC6535. There > are no needs stated in this draft. > > > standing on the BIH itself rather than borrowing another, with differen= t > > scope, as the ground of propaganda. > > I did serious works to reply you point-by-point. > thanks a lot. i just try to make the answer as brief as possible because our discussion dispersed much. - maoke > > BRs > > Gang > >> > >> > > >> >> whether that is a doable way need to be further justified. But BIH > is > >> >> a standard track > >> >> > >> > > >> > > >> >> > >> >> > or by a > >> >> > NAT64 located anywhere between the IPv4 app and the IPv6 domain > >> >> implemented > >> >> > >> >> I don't get it. If there is NAT64, there is nothing to do with the > >> >> scenario you are talking about. > >> >> > >> >> > >> >> > >> >> > in anyway not necessarily the socket layer solution, even though > BIH > >> >> > does > >> >> > possibly work, by a proxy (ALG), etc. > >> >> > >> >> Please note RFC6535 has two flavors, i.e. header translation and > >> >> socket translation. It=92s really not necessarily the socket layer > >> >> solution. > >> >> > >> >> > 3. i don't think the author has tested the BIH with CLAT for an > >> >> > IPv6-only > >> >> > server, at least i have not seen any discussion/report from the > >> authors > >> >> or > >> >> > WG members about the test. > >> >> > >> >> (**)I guess you will see the report soon, because we are coding tha= t > >> >> right > >> >> now. > >> >> At this stage, what I can tell is most parts are same in the > combining > >> >> code. > >> >> > >> >> > to my understanding, the BIH/CLAT work here is > >> >> > not yet practiced. why we need/should put a stuff not yet practic= ed > >> >> > into > >> >> a > >> >> > BCP?? > >> >> > >> >> Please don't do the arbitrary objection even you didn't evaluate it= . > >> >> It is a strange logic. > >> >> "I don't do that. I even don't know that. So I think that is not > >> >> practiced." > >> >> That is an unfair argument. > >> >> > >> >> > (NOTE, the test result from you only illustrates that BIH itself = is > >> >> > working, not the BIH/464xlat with IPv4-only app access to IPv6-on= ly > >> >> server. > >> >> > the tested applications, skype, MSN, etc. are none of business of > >> >> > the > >> >> > so-called IPv6-only servers). > >> >> > >> >> Please see the (**) and carefully read my report > >> >> http://www.ietf.org/mail-archive/web/v6ops/current/msg12631.html > >> >> The shared experiences are in 464 contexts. > >> >> With 464xlat, we could easily do *combining 464XLAT with BIH*. > >> >> It's of significance. > >> >> > >> > > >> > i think i don't misunderstand anything about your report. i read > >> > through > >> > the mail and also the doc of the testing. it is good but i think it > >> > said, > >> > BIH is working, no matter there is 464xlat or not. > >> > >> No. What I reported is our experience of BIH because 464xlat is not > >> appeared in that time. > >> I have to do in the way if 464 is unavoidable, even it was recommended > >> BIH should not work with NAT64 in RFC6535. > >> With 464xlat it's really perfect for us to follow and it's approved > >> that is a doable way and two technologies could benefit to each other. > >> We share the experiences and confirmed by wg. > >> Currently, you are coming here and say "Hi, I'm not happy with that > >> for no technical reasons, please remove it" > >> > > > > i was talking about technical reasons but you never saw it. ;-) i canno= t > > help if you think the point on technical problem statement is not > > technical. > > > > - maoke > > > > > >> It's really unfair. > >> > >> > >> >please identify the > >> > benefit of having BIH working together with 464xlat, i.e., what we > gain > >> > through the combination rather than BIH and 464xlat themselves? > >> > >> 1) it gives the possibilities of 4-6 with a safe reference of standard > >> track > >> 2)it facilitates IPv6-only deployment > >> 3)it's complementary to support IPv4 application > >> and etc. > >> As I said it would be better if you could progress the work with the > >> points that's didn't cover before > >> Otherwise, we would repeat the show several months ago > >> > >> > >> > more comprehensively, if 464xlat provides A, BIH provides B, and > >> > 464xlat > >> + > >> > BIH provides A + B but nothing else, > >> > >> Please note A and B is closely realted. It has same goal/ mostly same > >> code/ same strategie. > >> A+B is doing a complete and concrete the use case to operators. > >> > >> > >> > >> > then i insist that it is not necessary > >> > to cite BIH in 464xlat at all. > >> > >> That is surly known, even whatever happned in the wg and whatever we > >> are discussing. > >> Fortunately, it's approved that the adding BIH is no technial harm > >> after our discussion. > >> > >> What needing clarification is already said on the list unless you > >> create an new point. > >> > >> I intended to agree Remi comments > >> - At a time when there are still discussions on functional aspects of > >> 464XLAT, this particular discussion is IMHO a waste of time > >> - Preferred approach: keep the sentence, and proceed. > >> > >> > >> > >> BRs > >> > >> Gang > >> > > >> > - maoke > >> > > >> > > >> >> > >> >> > 4. i was even confused by the text "By combining 464XLAT with BIH > >> >> > [RFC6535], it is also possible to provide single IPv4/IPv6 > >> >> > translation > >> >> > service" itself. BIH has done the single IPv4/IPv6 translation > >> >> > right? > >> >> what > >> >> > is the significance of such a "combination"? what is the add-on? > >> >> > >> >> Same comment with (*). If you have concrete point, please identify. > >> >> Ambiguous arguments and arbitrary objections only can waste our > energy > >> >> and time. It doesn't help the document imho. > >> >> > >> >> > integrating the compressor, condenser, expansion valve, evaporato= r > >> into > >> >> > a > >> >> > fridge is an innovation (as the authors did for the 464xlat) but = we > >> >> cannot > >> >> > call a "fridge + microwave oven put on the top of the fridge" a n= ew > >> >> > "architecture" of better practice. > >> >> > >> >> I didn't fully get your point. 464xlat is not a fridge actually :) > >> >> Again, please directly identify your technical points/concerns. > >> >> > >> >> > >> >> BRs > >> >> > >> >> Gang > >> >> > >> >> > >> >> > >> >> > - maoke > >> >> > > >> >> > 2012/9/6 GangChen > >> >> > > >> >> >> 2012/9/6, Maoke : > >> >> >> > another objection is, Section 9 states "another, > >> >> >> > if combined with BIH [RFC6535 < > >> http://tools.ietf.org/html/rfc6535 > >> >> >], > >> >> >> is > >> >> >> > a IPv4 -> IPv6 translation for > >> >> >> > reaching IPv6-only servers from IPv4-only clients that can > not > >> >> >> > support IPv6. " > >> >> >> > > >> >> >> > it sounds to me that 464xlat does suggest to apply BIH, as par= t > >> >> >> > of > >> >> >> > the > >> >> >> best > >> >> >> > practice, for IPv4 client reaching IPv6-only servers. to my > >> >> >> understanding, > >> >> >> > there could be several alternative ways to achieve that, why w= e > >> >> >> > should > >> >> >> > be > >> >> >> > bounded with BIH? > >> >> >> > > >> >> >> > sorry i didn't catch the discussion on this issue before. > >> >> >> > >> >> >> There was a quite long discussion, > >> >> >> since you didn't follow that, I list the links below for your > >> >> >> convenience. > >> >> >> > >> >> >> "A way forward for 464XLAT", started with > >> >> >> http://www.ietf.org/mail-archive/web/v6ops/current/msg12521.html > >> >> >> "A way forward for 464XLAT - using BIH", started with > >> >> >> http://www.ietf.org/mail-archive/web/v6ops/current/msg12631.html > >> >> >> "I-D Action: draft-ietf-v6ops-464xlat-02.txt" started with > >> >> >> http://www.ietf.org/mail-archive/web/v6ops/current/msg12628.html > >> >> >> " [v6ops] draft-ietf-v6ops-464xlat - which status?"started with > >> >> >> http://www.ietf.org/mail-archive/web/v6ops/current/msg13035.html > >> >> >> .... > >> >> >> > >> >> >> As Cameron indicated *The conclusion was that the 464XLAT is mor= e > >> >> >> complete by making a reference to BIH scenario.* > >> >> >> > >> >> >> BRs > >> >> >> > >> >> >> Gang > >> >> >> > >> >> >> > >> >> >> > > >> >> >> > 2012/8/22 Fred Baker (fred) > >> >> >> > > >> >> >> >> I should note that the current thread has a subject line > reading > >> >> >> -06.txt, > >> >> >> >> but the current version is -07.txt. You may find the diffs > >> >> >> >> (fairly > >> >> >> >> extensive) at > >> >> >> >> > >> >> >> >> > >> http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-464xlat-07.txt > >> >> >> >> > >> >> >> >> > >> >> >> >> On Aug 21, 2012, at 8:45 AM, Fred Baker (fred) wrote: > >> >> >> >> > >> >> >> >> > This is to open a two week Working Group last Call on > >> >> >> >> > > >> >> >> >> > http://tools.ietf.org/html/draft-ietf-v6ops-464xlat > >> >> >> >> > "464XLAT: Combination of Stateful and Stateless > Translation", > >> >> >> Masataka > >> >> >> >> > Mawatari, Masanobu Kawashima, Cameron Byrne, 19-Aug-12 > >> >> >> >> > > >> >> >> >> > Please read it now. We are interested in, among other thing= s, > >> >> >> technical > >> >> >> >> commentary on the draft and the working group's perception on > >> >> >> >> its > >> >> >> >> usefulness to its target audience. > >> >> >> >> > _______________________________________________ > >> >> >> >> > v6ops mailing list > >> >> >> >> > v6ops@ietf.org > >> >> >> >> > https://www.ietf.org/mailman/listinfo/v6ops > >> >> >> >> > >> >> >> >> ---------------------------------------------------- > >> >> >> >> The ignorance of how to use new knowledge stockpiles > >> exponentially. > >> >> >> >> - Marshall McLuhan > >> >> >> >> > >> >> >> >> _______________________________________________ > >> >> >> >> v6ops mailing list > >> >> >> >> v6ops@ietf.org > >> >> >> >> https://www.ietf.org/mailman/listinfo/v6ops > >> >> >> >> > >> >> >> > > >> >> >> > >> >> > > >> >> > >> > > >> > > > --047d7b33daf4debbf704c91aa3b6 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

2012/9/7 GangChen <= phdgang@gmail.com>
Hello Maoke,

2012/9/7, Maoke <fibrib@gmail.com>:
> 2012/9/7 GangChen <phdgang@gmail.com>
>
>> 2012/9/7, Maoke <fibrib@gma= il.com>:
>> > this item is what you are waiting for my reply to, right? see= inline.
>> >
>> > 2012/9/6 GangChen <ph= dgang@gmail.com>
>> >
>> >> 2012/9/6, Maoke <f= ibrib@gmail.com>:
>> >> > hi Gang,
>> >> >
>> >> > thanks for the links!
>> >> >
>> >> > 1. i don't think an early conclusion of the auth= ors cannot be
>> >> > objected
>> >> and
>> >> > thought over again, before the last call is closed.<= br> >> >>
>> >> Sure. If you do think several-months lasted discussion do= esn't
>> >> convince and would like to boil the ocean, we could re-op= en it.
>> >> But please read the conversion happened before on the lis= t to ensure
>> >> new discussion is not backward.
>> >>
>> >> > 2. i don't think it is a loss to state out of sc= ope (or not to
>> >> > mention
>> >> that
>> >> > at all) for IPv4-only app access to IPv6-only server= .
>> >>
>> >> (*)Those arguments were discussed in the thread of "= A way forward for
>> >> 464XLAT - using BIH".
>> >> The loss and gain have been well identified. The point is= adding BIH
>> >> only can be complementary to 464xlat scenario, no harm. >> >> If you have further point, please identify.
>> >>
>> >
>> > putting a microwave oven on the top of a fridge has no harm a= t all,
>> > too.
>>
>> It's good to hear your confirmation on *NO harm*
>>
>
> but we never see a fridge specification states or suggests: if you put= your
> oven on the top of the fridge, you can have icecream and meanwhile roa= st
> your chicken. :P

Beacause we are discussing the BCP in telecom area, not house d= ecoration :)

>terrible specification if i have.
>
>>
>>
>> > my
>> > point is simple: if 464xlat can solve the problem it identifi= es, then
>> > things are enough. we don't need anything more, even the = "anything" has
>> > been standard
>>
>> No problem with 464xlat doing the best in 464. But the point is su= ch
>> 464 can't be guaranteed to be pure at different places and dif= ferent
>> times in the real life. *Mentioned* that can only be informative a= nd
>> benefit to reader. If we know the answer is good, why not do it? >>
>
> as Lorenzo mentioned, we haven't confirm the answer is good or the= best.

So that is the discussion to help the confirm

> as Brian pointed out, it is too premature to talk about this.

The point should better be discussed on the Behave
But the fact is BIH is standard track, we should follow the guidance of RFC= 2026



> why should we do it?
>
>
>>
>> > unless we change the scope of the problem.
>>
>> No need. Please see my mail replying to Lorenzo.
>>
>> >>
>> >>
>> >> > this could be
>> >> > achieved by simply configuring the IPv6-only server = with an RFC6052
>> >> > IPv4-translatable address and relying CLAT RFC6145 t= ranslation,
>> >>
>> >> 1) The IPv4-Embedded IPv6 address on CLAT is inserted wit= h IPv4
>> >> private address.
>> >
>> > When the two IPv4-embedded IPv6 addresses with conflicted IPv= 4 address
>> >> talk to an IPv4-translatable IPv6 address, it would be fa= iled since
>> >> IPv6-only server is confused that outgoing packages shoul= d send to
>> >> which CLAT.
>> >>
>> >
>> > not very understand. conflicted IPv4 address either causes tr= ouble or
>> > running as anycast. what's the scope?

what I mean is *replying packages*, because the destination would be<= br> same IPv4 address.
=A0
they have different I= Pv6 prefixes and routing can guide them to different CLATs. what the proble= m?
=A0

>> The IPv4 embedded IPv6 address adopted by 464xlat is inserted with=
>> private IPv4 address.
>> Those private IPv4 addresses are likely be same if two CLAT send >> packages to a IPv6 server.
>> It's no problem with 464 communications because packages could= be
>> identified by different IPv6 prefixes.
>> but it would be failed sending to a same IPv6 server, because repl= ying
>> packages can't distinguish which packages should send to which= prefix.
>> I hope you could understand.
>>
>
> no. i don't know why the IPv6 server cannot distiguish the sources= having
> different IPv6 prefixes.
>
>
>>
>>
>> >
>> >> 2) IPv6-only server with IPv4-translatable address would = cause one
>> >> public IPv4 address.
>> >> Most people do IPv6 because IPv4 is limited, so doing thi= s way does
>> >> not really buy you anything.
>> >>
>> >
>> > i (the server) may keep early customers from native IPv4 havi= ng access
>> > without knowing that i have changed my protocol stack and mea= nwhile
>> > increase my native IPv6-only customers.
>>
>> What I indicate is the needs to allocate the global IPv4 address t= o
>> server. It's nothing to do native IPv4 customer. But you seems= mean
>> there is also need to customers assigning a global IPv4 address. I= t
>> seems getting that worse.
>>
>
> you misunderstood. i mean
>
> =A0 =A0v4private client -> CLAT -> v6 server with IPv4-translata= ble
> (global) address
^^^^^^^^^^

that is what I talking about
=A0
see above, = what's the problem?
=A0

> =A0 =A0v6 client (native) -> <native IPv6-only network> ->= v6 server with
> IPv4-translatable (global) address

that is a native IPv6 communication.
Why do you assign the IPv4-translatable (global)IPv6 address to server.
BTW, I guess that is not the case we are talking about
=A0
i just answer your previous question why someone may be inte= rested to deploy IPv6-only server with IPv4-translatable address. the reaso= n is enlarging the connectivity to native IPv6 clients without losing the s= ervices to original IPv4 clients. yes, this is out of scope but try to shar= e my understanding with answer your question.
=A0


> is the result. never talk about global ipv4 address for customers.
>
>
>>
>> >
>> >> 3) There no RFC stated the solution what you called as >> >> RFC6052+RFC6145;
>> >>
>> >
>> > copied from RFC6145:
>> >
>> > =A0 =A0Readers of this document are expected to have read and= understood
>> > the
>> > =A0 =A0framework described in [RFC6144 <http://tools.ietf.org/html/r= fc6144
>> >].
>> > Implementations of this IPv4/IPv6
>> > =A0 =A0translation specification MUST also support the addres= s translation
>> > =A0 =A0algorithms in [RFC6052 <http://tools.ietf.org/html/rfc6052>].
>> > Implementations MAY also support stateful
>> > =A0 =A0translation [RFC6146 <http://tools.ietf.org/html/rfc6146&= gt;].
>> > RFC6052 + RFC6145 is a MUST and both are standards.
>>
>> Please note RFC6145 is an algorithm block.
>> There is no justification of scenario applicability
>>
>
> please argue this to the RFC6145 track.

Don't understand
You mentioned that is qualified, so we need specific texts to approve
the scenario applicability.
=A0
i mean RFC61= 45 is working with RFC6052 -- this is a normative statement in the standard= RFC6145.
=A0


>
>>
>>
>> > and RFC6219 gave you an example of using the both in the prac= tice.
>>
>> RFC6219 is informational. According to RFC2026, "An "Inf= ormational"
>> specification
>> is published for the general information of the Internet community= ,
>> and does not represent an Internet community consensus or recommen= dation.
>> "
>>
>> But BIH is a standard.
>>
>> I guess what you have indentified is addressed totally.
>> I guess we could agree BIH is best selction if IPv4-IPv6 mentioned= ?
>>
>
> no. your guess is wrong. personally i don't agree. i would like to= say it
> depends. it is a standard, but only a standard among an amount of.

Amount of what? Intentional avoiding could not help you to clarify. It's only can delay the work
=A0
com'= ;on. an=A0amount of standards.
=A0

> on other
> hand, i don't like to debate this problem with you right now.

it's up to you. But the work still needs to progress.
>
> however, nobody stop you proposing a "BCP-target" draft for = BIH usage,

No. The justification of BIH usage was already done in RFC6535. There=
are no needs stated in this draft.
=A0

> standing on the BIH itself rather than borrowing another, with differe= nt
> scope, as the ground of propaganda.

I did serious works to reply you point-by-point.
=A0
thanks=A0a lot. i just try to make the answer as brief as po= ssible because our discussion dispersed much.
=A0
- ma= oke
=A0

BRs

Gang
>>
>> >
>> >> whether that is a doable way need to be further justified= . =A0But BIH is
>> >> a standard track
>> >>
>> >
>> >
>> >>
>> >> > or by a
>> >> > NAT64 located anywhere between the IPv4 app and the = IPv6 domain
>> >> implemented
>> >>
>> >> I don't get it. If there is NAT64, there is nothing t= o do with the
>> >> scenario you are talking about.
>> >>
>> >>
>> >>
>> >> > in anyway not necessarily the socket layer solution,= even though BIH
>> >> > does
>> >> > possibly work, by a proxy (ALG), etc.
>> >>
>> >> Please note RFC6535 has two flavors, i.e. header translat= ion and
>> >> socket translation. It=92s really not necessarily the soc= ket layer
>> >> solution.
>> >>
>> >> > 3. i don't think the author has tested the BIH w= ith CLAT for an
>> >> > IPv6-only
>> >> > server, at least i have not seen any discussion/repo= rt from the
>> authors
>> >> or
>> >> > WG members about the test.
>> >>
>> >> (**)I guess you will see the report soon, because we are = coding that
>> >> right
>> >> now.
>> >> At this stage, what I can tell is most parts are same in = the combining
>> >> code.
>> >>
>> >> > to my understanding, the BIH/CLAT work here is
>> >> > not yet practiced. why we need/should put a stuff no= t yet practiced
>> >> > into
>> >> a
>> >> > BCP??
>> >>
>> >> Please don't do the arbitrary objection even you didn= 't evaluate it.
>> >> It is a strange logic.
>> >> "I don't do that. I even don't know that. So= I think that is not
>> >> practiced."
>> >> That is an unfair argument.
>> >>
>> >> > (NOTE, the test result from you only illustrates tha= t BIH itself is
>> >> > working, not the BIH/464xlat with IPv4-only app acce= ss to IPv6-only
>> >> server.
>> >> > the tested applications, skype, MSN, etc. are none o= f business of
>> >> > the
>> >> > so-called IPv6-only servers).
>> >>
>> >> Please see the (**) and carefully read my report
>> >> http://www.ietf.org/mail-archive/web/= v6ops/current/msg12631.html
>> >> The shared experiences are in 464 contexts.
>> >> With 464xlat, we could easily do *combining 464XLAT with = BIH*.
>> >> It's of significance.
>> >>
>> >
>> > i think i don't misunderstand anything about your report.= i read
>> > through
>> > the mail and also the doc of the testing. it is good but i th= ink it
>> > said,
>> > BIH is working, no matter there is 464xlat or not.
>>
>> No. What I reported is our experience of BIH because 464xlat is no= t
>> appeared in that time.
>> I have to do in the way if 464 is unavoidable, even it was recomme= nded
>> BIH should not work with NAT64 in RFC6535.
>> With 464xlat it's really perfect for us to follow and it's= approved
>> that is a doable way and two technologies could benefit to each ot= her.
>> We share the experiences and confirmed by wg.
>> Currently, you are coming here and say "Hi, I'm not happy= with that
>> for no technical reasons, please remove it"
>>
>
> i was talking about technical reasons but you never saw it. ;-) i cann= ot
> help if you think the point on technical problem statement is not
> technical.
>
> - maoke
>
>
>> It's really unfair.
>>
>>
>> >please identify the
>> > benefit of having BIH working together with 464xlat, i.e., wh= at we gain
>> > through the combination rather than BIH and 464xlat themselve= s?
>>
>> 1) it gives the possibilities of 4-6 with a safe reference of stan= dard
>> track
>> 2)it facilitates IPv6-only deployment
>> 3)it's complementary to support IPv4 application
>> and etc.
>> As I said it would be better if you could progress the work with t= he
>> points that's didn't cover before
>> Otherwise, we would repeat the show several months ago
>>
>>
>> > more comprehensively, if 464xlat provides A, BIH provides B, = and
>> > 464xlat
>> +
>> > BIH provides A + B but nothing else,
>>
>> Please note A and B is closely realted. It has same goal/ mostly s= ame
>> code/ same strategie.
>> A+B is doing a complete and concrete the use case to operators. >>
>>
>>
>> > then i insist that it is not necessary
>> > to cite BIH in 464xlat at all.
>>
>> That is surly known, even whatever happned in the wg and whatever = we
>> are discussing.
>> Fortunately, it's approved that the adding BIH is no technial = harm
>> after our discussion.
>>
>> What needing clarification is already said on the list unless you<= br> >> create an new point.
>>
>> I intended to agree Remi comments
>> - At a time when there are still discussions on functional aspects= of
>> 464XLAT, this particular discussion is IMHO a waste of time
>> - Preferred approach: keep the sentence, and proceed.
>>
>>
>>
>> BRs
>>
>> Gang
>> >
>> > - maoke
>> >
>> >
>> >>
>> >> > 4. i was even confused by the text "By combinin= g 464XLAT with BIH
>> >> > [RFC6535], it is also possible to provide single IPv= 4/IPv6
>> >> > translation
>> >> > service" itself. BIH has done the single IPv4/I= Pv6 translation
>> >> > right?
>> >> what
>> >> > is the significance of such a "combination"= ;? what is the add-on?
>> >>
>> >> Same comment with (*). If you have concrete point, please= identify.
>> >> Ambiguous arguments and arbitrary objections only can was= te our energy
>> >> and time. It doesn't help the document imho.
>> >>
>> >> > integrating the compressor, condenser, expansion val= ve, evaporator
>> into
>> >> > a
>> >> > fridge is an innovation (as the authors did for the = 464xlat) but we
>> >> cannot
>> >> > call a "fridge + microwave oven put on the top = of the fridge" a new
>> >> > "architecture" of better practice.
>> >>
>> >> I didn't fully get your point. 464xlat is not a fridg= e actually :)
>> >> Again, please directly identify your technical points/con= cerns.
>> >>
>> >>
>> >> BRs
>> >>
>> >> Gang
>> >>
>> >>
>> >>
>> >> > - maoke
>> >> >
>> >> > 2012/9/6 GangChen <phdgang@gmail.com>
>> >> >
>> >> >> 2012/9/6, Maoke <fibrib@gmail.com>:
>> >> >> > another objection is, Section 9 states &quo= t;another,
>> >> >> > =A0 =A0if combined with BIH [RFC6535 < >> h= ttp://tools.ietf.org/html/rfc6535
>> >> >],
>> >> >> is
>> >> >> > a IPv4 -> IPv6 translation for
>> >> >> > =A0 =A0reaching IPv6-only servers from IPv4= -only clients that can not
>> >> >> > =A0 =A0support IPv6. "
>> >> >> >
>> >> >> > it sounds to me that 464xlat does suggest t= o apply BIH, as part
>> >> >> > of
>> >> >> > the
>> >> >> best
>> >> >> > practice, for IPv4 client reaching IPv6-onl= y servers. to my
>> >> >> understanding,
>> >> >> > there could be several alternative ways to = achieve that, why we
>> >> >> > should
>> >> >> > be
>> >> >> > bounded with BIH?
>> >> >> >
>> >> >> > sorry i didn't catch the discussion on = this issue before.
>> >> >>
>> >> >> There was a quite long discussion,
>> >> >> since you didn't follow that, I list the lin= ks below for your
>> >> >> convenience.
>> >> >>
>> >> >> "A way forward for 464XLAT", started w= ith
>> >> >> http://www.ietf.org/mail-arc= hive/web/v6ops/current/msg12521.html
>> >> >> "A way forward for 464XLAT - using BIH"= ;, started with
>> >> >> http://www.ietf.org/mail-arc= hive/web/v6ops/current/msg12631.html
>> >> >> "I-D Action: draft-ietf-v6ops-464xlat-02.tx= t" started with
>> >> >> http://www.ietf.org/mail-arc= hive/web/v6ops/current/msg12628.html
>> >> >> " [v6ops] draft-ietf-v6ops-464xlat - which = status?"started with
>> >> >> http://www.ietf.org/mail-arc= hive/web/v6ops/current/msg13035.html
>> >> >> ....
>> >> >>
>> >> >> As Cameron indicated *The conclusion was that th= e 464XLAT is more
>> >> >> complete by making a reference to BIH scenario.*=
>> >> >>
>> >> >> BRs
>> >> >>
>> >> >> Gang
>> >> >>
>> >> >>
>> >> >> >
>> >> >> > 2012/8/22 Fred Baker (fred) <fred@cisco.com>
>> >> >> >
>> >> >> >> I should note that the current thread h= as a subject line reading
>> >> >> -06.txt,
>> >> >> >> but the current version is -07.txt. You= may find the diffs
>> >> >> >> (fairly
>> >> >> >> extensive) at
>> >> >> >>
>> >> >> >>
>> http://tools.ietf.org/rfcdiff?url2=3Ddraft= -ietf-v6ops-464xlat-07.txt
>> >> >> >>
>> >> >> >>
>> >> >> >> On Aug 21, 2012, at 8:45 AM, Fred Baker= (fred) wrote:
>> >> >> >>
>> >> >> >> > This is to open a two week Working= Group last Call on
>> >> >> >> >
>> >> >> >> > http://tools.ietf.org/html/= draft-ietf-v6ops-464xlat
>> >> >> >> > =A0"464XLAT: Combination of S= tateful and Stateless Translation",
>> >> >> Masataka
>> >> >> >> > =A0Mawatari, Masanobu Kawashima, C= ameron Byrne, 19-Aug-12
>> >> >> >> >
>> >> >> >> > Please read it now. We are interes= ted in, among other things,
>> >> >> technical
>> >> >> >> commentary on the draft and the working= group's perception on
>> >> >> >> its
>> >> >> >> usefulness to its target audience.
>> >> >> >> > __________________________________= _____________
>> >> >> >> > v6ops mailing list
>> >> >> >> > = v6ops@ietf.org
>> >> >> >> > https://www.ietf.org/mailman/listin= fo/v6ops
>> >> >> >>
>> >> >> >> ---------------------------------------= -------------
>> >> >> >> The ignorance of how to use new knowled= ge stockpiles
>> exponentially.
>> >> >> >> =A0 =A0- Marshall McLuhan
>> >> >> >>
>> >> >> >> _______________________________________= ________
>> >> >> >> v6ops mailing list
>> >> >> >> v6ops= @ietf.org
>> >> >> >> https://www.ietf.org/mailman/listinfo/v6= ops
>> >> >> >>
>> >> >> >
>> >> >>
>> >> >
>> >>
>> >
>>
>

--047d7b33daf4debbf704c91aa3b6-- From phdgang@gmail.com Fri Sep 7 04:28:34 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77C4B21F87C3 for ; Fri, 7 Sep 2012 04:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.135 X-Spam-Level: X-Spam-Status: No, score=-3.135 tagged_above=-999 required=5 tests=[AWL=-0.136, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sIr6Vpt3JoKq for ; Fri, 7 Sep 2012 04:28:33 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id A2FF521F87B5 for ; Fri, 7 Sep 2012 04:28:07 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so3392428vbb.31 for ; Fri, 07 Sep 2012 04:28:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=QpCo9COBMPp2il0eSLqDc9yItcxI79ibi4CNFJAgSoM=; b=uHuMfNLU0Pcmz4jDgeASu41137/P4r1dJ7/At1AY/kmBgiVV2XxC2mqptqYLMk6wkx vw04fj3PiNfvU4QCZPP6PS9V0bInmw6MvC4CQY4LWpBMXVlUU46AaoAjg3NEiEGd8mZk l0IvldJKJYl57GhRQgwjBf61ROMdFaCV3p3VjqR3tGd3ftEe/4XXMxCnut/vtAxz1AfU wj6hyAxmEXyT5VZJwIl0EvoucfOy5TeCPqlfg1J4gF3h6LQ3e4ULvwI8agzSyhpaV9DG dsQ3igkMC2ykPh5Bod6GgFr1kXimVEEFLGs94dHNdhv+OZk7FbBL3EmCI1x0Rw/cNaHX KvEQ== MIME-Version: 1.0 Received: by 10.58.79.178 with SMTP id k18mr7455291vex.3.1347017286531; Fri, 07 Sep 2012 04:28:06 -0700 (PDT) Received: by 10.58.114.231 with HTTP; Fri, 7 Sep 2012 04:28:06 -0700 (PDT) In-Reply-To: References: Date: Fri, 7 Sep 2012 19:28:06 +0800 Message-ID: From: GangChen To: Maoke Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 11:28:34 -0000 2012/9/7, Maoke : > 2012/9/7 R=E9mi Despr=E9s > >> >> 2012-09-07 12:03, Lorenzo Colitti : >> >> On Fri, Sep 7, 2012 at 6:42 PM, R=E9mi Despr=E9s >> wrote: >> >>> BIH is the only IETF specification for an IPv4-only application in a >>> node >>> attached to an IPv6-only network to reach an IPv6-only server WITHOUT >>> depending on any special node between the two (transparent proxy or >>> whatever). >>> >> >> And yet, before the problem it solves actually becomes a problem, things >> could change substantially. New, better methods can come along. It could >> be >> obsoleted. It could change. And we'd be stuck with a BCP that endorses >> something that's not relevant any more. So if you really want to mention >> IPv6-only servers, I would suggest replacing the current text with the >> following: >> >> 464XLAT does not provide a means for IPv4-only applications to >> communicate >> with IPv6-only servers. If this capability is necessary, 464XLAT can be >> coupled with another transition mechanisms such as BIH [RFC6535]. >> >> That way it's clear that this document does not specify a best practice >> for IPv4-only clients to talk to IPv6-only servers, but only for >> IPv4-only >> apps on an IPv6-only network. >> >> In any case, I think the following points have to be resolved before we >> can make progress: >> >> 1. The conflict between section 1, which talks about IPv6-only servers, >> and section 2, which declares them out of scope, must be resolved. >> 2. Before we mention BIH in this document, we should ensure that at leas= t >> one implementation of 464XLAT+BIH has been tested. We don't want to >> publish >> a BCP that suggests doing something that has never been tested. >> >> >> No new comment on the above. >> >> 3. If this document suggests using 464XLAT + BIH together, it needs to >> say >> why the text in the BIH RFC which says "Use of BIH together with a NAT64 >> is >> NOT RECOMMENDED" is not relevant to this case. >> >> >> This is new consideration, but not a problem: >> >> > > actually, Remi, i have to point out it is problem. this is related to my > talk with you that the private addresses are also possibly used for a > server. > > 0. the domain operator makes address planning with the private address in > order to avoid potential conflict; > 1. a host having private IPv4 address are located in a LAN behind BIH/CLA= T > box, with IPv6 prefixes configured with the box; > 2. it is running a server and a client peer behind another CLAT, somehow, > know the server's address (it is private but static); > 3. the client sends out a request to the server's IPv4 address, both src > and dst are translated by the CLAT statelessly; > 4. the CLAT of the server side decodes the IPv4-converted addresses and > delivered the translated packet to the server; > 5. the server responds the request, while the reply arrives at the > BIH/CLAT, trouble happens: which module to proceed? if it is the CLAT, > fortunately, we are lucky, and things just worked as IVI with double > translation. if BIH takes the session, well, what would happen? i don't > think BIH is covering this case too with its synthetic IPv4 and the real > IPv6 addresses because the peer (the client) is not IPv6 now at all. BIH > state needs to be established by the initiator of the session but combini= ng > it with CLAT makes it uncertain when the initiation bypasses BIH at all. The packages are headed to CLAT is identified by the destination address with TUN IPv6 address; the packages heading to BIH are with IPv6 destination that matches the mapping table. That is implementation detailed. I believe there are multiple ways could do that. What the trouble you can see? BRs Gang > this is a very realistic case when we want to deploy an in-domain server > group. and 464xlat itself can works well. but the combination of 464xlat = to > BIH may cause some trouble. Lorenzo and me argued that the combination wa= s > not tested. this is a real case of risk. of course, we may patch it, but = it > is definitely far beyond one paragraph stating that "combining them is > useful". > > if we have time, i may find more and more cases where the combination > introduces uncertainty. therefore i think it is safe to scope out the > problem right now. > > - maoke > > >> >> - The RFC says that BIH should not send packets to NAT64s. >> - This doesn't prevent a node supporting BIH to also support 464XLAT >> which, precisely is designed to send packets to PLATs, AKA NAT64s. >> >> This point underlines how complementary the two specifications are. >> >> RD >> >> >> >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> >> > From phdgang@gmail.com Fri Sep 7 04:31:37 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA2121F87FA for ; Fri, 7 Sep 2012 04:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.424 X-Spam-Level: X-Spam-Status: No, score=-3.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hSayKSO8Vg5J for ; Fri, 7 Sep 2012 04:31:37 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id CA1BF21F87F5 for ; Fri, 7 Sep 2012 04:31:36 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so3399420vbb.31 for ; Fri, 07 Sep 2012 04:31:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+t7PQ9X3Pk03IMhjWRw2Nf7kGrvK7hg68qcEJr7fcKs=; b=HZpD9l/pVa45LvzBCmKM5qbQoBLysJ2/aWj2G8LHPAwcHeg0bzgN4zPbfrKu1xMHbw 6Koyk+914MZQkwraraAusjwnlrDAf/cKWvSaf9eHPyXurMd9COl7nwsvOyekIgw135HR Sy8q8ZitHBDDpMI0KFlExnUb6RvXKQUA7B0GiQxXDjWUOpQmwv3d/0yrs7Oy0ULKxfhK af+jCd8Edtpn7Gz15qaffoXsOdaxI6N9R4Yr2BKze+gCNSR+1oRLSQoUlx7WMEhSGbvM EyRvc8K2sywBZJxhnoJouICVJ6yTYsAH3yn1bHFcpP7X1RuBs1sRsqihz0jN0uJ2/Ja9 /Uxw== MIME-Version: 1.0 Received: by 10.52.34.204 with SMTP id b12mr5466195vdj.75.1347017496145; Fri, 07 Sep 2012 04:31:36 -0700 (PDT) Received: by 10.58.114.231 with HTTP; Fri, 7 Sep 2012 04:31:36 -0700 (PDT) In-Reply-To: References: Date: Fri, 7 Sep 2012 19:31:36 +0800 Message-ID: From: GangChen To: Maoke Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 11:31:37 -0000 2012/9/7, Maoke : > 2012/9/7 GangChen > >> 2012/9/7, Maoke : >> > 2012/9/7 GangChen >> > >> >> Hello Lorenzo, >> >> >> >> 2012/9/7, Lorenzo Colitti : >> >> > On Fri, Sep 7, 2012 at 2:59 PM, GangChen wrote: >> >> > >> >> >> If you haven't concrete argument and only insist on the claim, >> >> >> we will be here for another month while that would delay the work. >> >> >> Please to identify what the harm you see to object. . >> >> > >> >> > >> >> > Ok, here's a concrete problem, then: the draft contradicts itself. >> >> >> >> Thanks for providing the concrete point, I guess your intention is not >> >> to identify the technical problem after the reading >> >> >> >> > Section 1 says: >> >> > >> >> > By combining 464XLAT with BIH [RFC6535], it is also possible to >> >> > provide single IPv4 to IPv6 translation service, which will be >> >> > needed >> >> > in the future case of IPv6-only servers [...] >> >> > >> >> > But Section 2 says: >> >> > >> >> > This BCP only applies when the following two criteria are >> >> > present: >> >> > [...] >> >> > 2. There are IPv4-only applications or hosts that must >> >> > communicate >> >> > across the IPv6-only network to reach the IPv4 Internet. >> >> > >> >> > So, one section mentions IPv6-only servers, >> >> >> >> Please note the condition is *combining 464XLAT with BIH*. The draft >> >> clearly identifies that. >> >> I don't see the harm if a draft to mention the possible relationship >> >> with other from that same SDO considering same goal they would like to >> >> achieve. >> >> >> >> >> >> > and another section explicitly >> >> > says "the IPv4 Internet" where by definition, there cannot be >> IPv6-only >> >> > servers. >> >> >> >> (*)The section 2 helps to justify the BCP applicability to >> >> 464xlat(i.e. IPv4 app through IPv6 network talk to IPv6 server). BIH >> >> doesn't need to be justified in this draft, because it already a >> >> standard track. It doesn't make sense to mix that with section 1 >> >> statement. >> >> To be clear, the logic is >> >> 1) 464xlat is a BCP in the scenario of IPv4 app through IPv6 network >> >> talking to IPv6 server. >> > >> > >> > sorry, where in the Section 2 said 464xlat is a BCP in the scenario of >> IPv4 >> > app through IPv6 network talking to *IPv6 server* ?? - maoke >> >> Please seriously read the rest of parts. No answer/reply would be treated >> as >> acknowleged. >> > > well. i answered here doesn't mean i didn't read the rest. the Section 2 > doesn't talk about IPv6-only server and therefore MHO is your 1) and 2) are > not qualified. But the point is the applicabilities of BIH don't not need to be stated in 464xlat. It's already covered in RFC6535. > > >> >> BRs >> >> Gang >> >> >> >> Section 2 help to answer that >> >> 2) BIH is a standard track solution in the scenario of IPv4 apps >> >> talking to IPv6. The applicabilities are already justified in RFC6535. >> >> But mentioned the possibilities of cooperation are >> >> informative/beneficial to readers. >> >> >> >> >> >> >So one section talks about IPv6-only servers, and another section >> >> > of the same document declares them to be out of scope. >> >> >> >> If 464 BCP means the draft is only granted to talk about 464, which >> >> exclude everything beyong the scope. >> >> I would like to ask why "DNS Proxy Implementation" is ranked with >> >> *SHOULD*. It should be out of the scope according to your logic. >> >> But it's not true I guess, beacause it provides a valuable effcient >> >> data path to 464xlat. >> >> It's verified no technical harm and makes 464xlat is better. >> >> The same reason is also applied to BIH. Compared to that, BIH is only >> >> *mentioned* >> >> >> >> >> >> > In order to resolve the contradiction, either you modify Section 2 >> >> > to >> >> > expand the scope to include IPv6-only servers, or you modify Section >> >> > 1 >> >> > to >> >> > remove the mention to BIH. Given the two choices I think it's better >> to >> >> > remove BIH, because as soon as IPv6-only servers are in scope, this >> >> > document will suddenly become a BCP on "how IPv4-only nodes should >> >> > communicate with IPv6-only servers", and I don't think we have >> >> > consensus >> >> > that yet. >> >> > >> >> I don't see the necessity. Please see(*) >> >> >> >> BRs >> >> >> >> Gang >> >> >> > >> > From v6ops@globis.net Fri Sep 7 05:16:09 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B57D321F87D7 for ; Fri, 7 Sep 2012 05:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z7LqztQfT-Sl for ; Fri, 7 Sep 2012 05:16:08 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3146C21F87D6 for ; Fri, 7 Sep 2012 05:16:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id B98688700BC; Fri, 7 Sep 2012 14:15:51 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AM+fSHIS7SZe; Fri, 7 Sep 2012 14:15:22 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 578B287004D; Fri, 7 Sep 2012 14:15:22 +0200 (CEST) Message-ID: <5049E553.7080103@globis.net> Date: Fri, 07 Sep 2012 14:15:15 +0200 From: Ray Hunter User-Agent: Postbox 3.0.4 (Macintosh/20120616) MIME-Version: 1.0 To: "t.petch" References: <504392E0.8070802@bogus.com><448050D4-84F9-4F52-BF7E-347EA451A96C@laposte.net><0AB559C2-855C-41F3-92D1-07F973EB760A@laposte.net> <03e501cd8ce5$4ab52f80$4001a8c0@gateway.2wire.net> In-Reply-To: <03e501cd8ce5$4ab52f80$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: v6ops WG Subject: Re: [v6ops] 464XLAT - /64 sharing was support of /64 delegated prefixes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 12:16:09 -0000 Interesting perspective. Would you recommend sharing a NBMA network across an AS boundary where there are also potential parallel paths? What is then "downstream"? What is "upstream"? Which device is the "hub"? That's my concern with tethering one or more mobile phones to a home network, where there are also likely to be existing "uplinks" to other ISPs / IPv6 access networks. regards, RayH t.petch wrote: > Cameron > > Just to clarify, in your point 3), is the emphasis on 'standard', that > is that ND-Proxy is not on standards track? > > I see sharing a /64 as just another example of NBMA, which IPv6 sort of > supports. In this case, the 464 device is the hub and the IPv6 access > network one spoke and the downstream devices another set of spokes. OK, > the downstream devices may think that they are broadcast but they are > not, they are NBMA in this case. > > Tom Petch > > ----- Original Message ----- > From: "Cameron Byrne" > To: "Rémi Després" > Cc: "v6ops WG" > Sent: Thursday, September 06, 2012 4:27 PM > Subject: Re: [v6ops] 464XLAT - support of /64 delegated prefixes > > > Rémi , > > On Thu, Sep 6, 2012 at 7:22 AM, Rémi Després > wrote: >> 2012-09-06 15:16, Cameron Byrne : >> >> >> On Sep 6, 2012 1:03 AM, "Lorenzo Colitti" wrote: >>> On Thu, Sep 6, 2012 at 4:54 PM, Maoke wrote: >>>> how can we ensure the above addresses do not conflict with any > manually, >>>> arbitrarily configured addresses? i am lost. :P - maoke >>> AIUI, we say "conflicts are impossible, because this is a reserved > range", >>> and then we cross our fingers. >>> >> I agree with Lorenzo's sarcasm. >> >> This "sarcasm" isn't deserved: one who manually configures a host with > an >> invalid address with regard to RFC 4291 should cross his fingers in > all >> cases, with 464XLAT or not. >> > > Here are the facts as i see them: > > 1. Many people on the list, including me, say we must share a /64 > from WAN to LAN > > 2. Multiple real world implementations of this /64 sharing exists in > various types of nodes, including the AOSP Android code. Hermant also > references he has experience with some CPE that share a /64 in > production networks using ND Proxy. And there is also the case of a > CPE that simply bridges WAN to LAN and has a logical / virtual place > on that share /64. Lorenzo also specified a method here > http://www.ietf.org/mail-archive/web/v6ops/current/msg13977.html > > 3. There is no standards track way to share a /64 from WAN to LAN, > the party line is DHCP-PD is the solution. New protocol work happens > in 6MAN. > > 4. Remi has provided, what i consider, to be a workable solution that > avoids the case of NAT44. > > So, we have a problem since #1 and #3 are a challenge, and #2 exists > > #4 is workable, but it has opponents and requires "hard coding" and > really is not core to 464XLAT. Removing the need for NAT44 is not a > goal, the overhead of having NAT44 is inconsequential to a modern CPE, > including smartphones. Related to hard coding, there is no RFC1918 > address that we can pick. ISPs are now dictating how residential LANs > must be configured so they do not overlap with the SP network's use of > RFC1918 space ... > http://keithbartholomew.com/2012/04/how-att-u-verse-broke-my-home-networ > k/ > > >> Besides, it is particularly unexpected from you, after you stated "In > the >> case of the Android CLAT code that was submitted to AOSP, the /64 is > simply >> copied from the WAN 3G/4G interfaces to the LAN. No magic. No ND > Proxy. No >> DHCP. But, it works for all known cases". >> With this, collisions between CLATs and host addresses are possible > even >> with well-behaved hosts =The need to cross fingers is permanent ;-). > > No, NDP/DAD runs normally on the LAN side as a /64 and the WAN side is > a /128 ... /128 on WAN is normal operations for a Android phone on a > 3GPP network. > > The main takeaway from this: implementation specific solutions are ok > and left to the implementer and network operator to consider pros and > cons. > > The party line remains: DHCP-PD is best! While reality dictates and > the 464XLAT I-D must reflect that /64 sharing exists. > > I am not confident that this group of folks who don't have a very good > understanding of probability (manually configures 64 bit collisions?!) > will come to a consensus on a general solution, and even if they can > come to a consensus, 464XLAT is not the right vehicle for specifying > how a /64 is shared across interfaces. > > Let us just say /64 sharing exists and move on. If we believe /64 > must be codified on standards track, 6MAN may be the place for that > with its own I-D. > >> By using the proposed IANA-EUI-64 based /96, this is avoided and, with > a MAY >> in the draft, the somewhat risky choice you have described remains > possible. >> That said, we have been pushing this draft for a year trying to drive >> concensus. If we do not limit the scope to the core objective we will > be >> here for another year while the issue of ipv4-only hosts and apps > delays and >> hinders broader ipv6 deployment. >> >> On this, we agree. >> >> Still convinced to be one of the best supporters of a good 464XLAT > without >> undue delay, > > Thanks again! > >> Best regards, >> RD >> >> >> CB >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> >> > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > From despres.remi@laposte.net Fri Sep 7 06:06:38 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38B1E21E8041 for ; Fri, 7 Sep 2012 06:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.342 X-Spam-Level: X-Spam-Status: No, score=-1.342 tagged_above=-999 required=5 tests=[AWL=0.606, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c0UEyi9oF-kz for ; Fri, 7 Sep 2012 06:06:37 -0700 (PDT) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.2]) by ietfa.amsl.com (Postfix) with ESMTP id 27F6521F87DF for ; Fri, 7 Sep 2012 06:06:36 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2109.sfr.fr (SMTP Server) with ESMTP id 3443E700009C; Fri, 7 Sep 2012 15:06:35 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2109.sfr.fr (SMTP Server) with ESMTP id BBD6B7000089; Fri, 7 Sep 2012 15:06:34 +0200 (CEST) X-SFR-UUID: 20120907130634769.BBD6B7000089@msfrf2109.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-31--651192920 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Fri, 7 Sep 2012 15:06:34 +0200 Message-Id: <810EAE3D-8767-4E66-911D-3DBDFE8B9403@laposte.net> References: To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 13:06:38 -0000 --Apple-Mail-31--651192920 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-09-07 =E0 12:36, Lorenzo Colitti a =E9crit : > On Fri, Sep 7, 2012 at 7:16 PM, R=E9mi Despr=E9s = wrote: >> 3. If this document suggests using 464XLAT + BIH together, it needs = to say why the text in the BIH RFC which says "Use of BIH together with = a NAT64 is NOT RECOMMENDED" is not relevant to this case. >=20 > This is new consideration, but not a problem: > - The RFC says that BIH should not send packets to NAT64s. > - This doesn't prevent a node supporting BIH to also support 464XLAT = which, precisely is designed to send packets to PLATs, AKA NAT64s. >=20 > If you don't want to remove BIH, then please suggest text to address = this issue. The text that is currently in the draft does not do so, and = since it's a conflict with a standards track RFC, we have to say = something about it. As said, I don't think there is a problem in cohabitation of 464XLAT, by = design used with NAT64, and BIH whose use with a NAT64 isn't = recommended. Yet, if this covers your concern, and raises no objection from authors, = the last paragraph of section 1 could be completed, e.g. as follows: "By combining 464XLAT with BIH [RFC6535], it is also possible to provide = single IPv4 to IPv6 translation service, which will be needed in the = future case of IPv6-only servers and peers to be reached from IPv4-only = hosts across IPv6-only networks. By doing so, BIH continue to not be = used together with a NAT64, as recommended in [RFC6535], 464XLAT being = in charge of using NAT64s as PLATs." Could this be a way out of this endless debate? Regards, RD --Apple-Mail-31--651192920 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On Fri, Sep 7, 2012 at 7:16 PM, R=E9mi Despr=E9s <despres.remi@laposte.net> wrote:
3. If this document = suggests using 464XLAT + BIH together, it needs to say why the text in = the BIH RFC which says "Use of BIH together with a NAT64 is NOT = RECOMMENDED" is not relevant to this case.

This is new consideration, but not a = problem:
- The RFC says that BIH should not send packets to = NAT64s.
- This doesn't prevent a node supporting BIH to also = support 464XLAT which, precisely is designed to send packets to PLATs, = AKA NAT64s.

If you don't want to remove BIH, = then please suggest text to address this issue. The text that is = currently in the draft does not do so, and since it's a conflict with a = standards track RFC, we have to say something about it.

As said, I don't think there is a problem in = cohabitation of 464XLAT, by design used with NAT64, and BIH whose use = with a NAT64 isn't recommended.

Yet, = if this covers your concern, and raises no objection from = authors, the last paragraph of section 1 could be completed, e.g. = as follows:
"By combining 464XLAT with BIH [RFC6535], it is =
also possible to provide single IPv4 to IPv6 translation service, which =
will be needed in the future case of IPv6-only servers and peers to be =
reached from IPv4-only hosts across IPv6-only networks. By doing so, BIH =
continue to not be used together with a NAT64, as recommended in =
[RFC6535], 464XLAT being in charge of using NAT64s as PLATs."
Could this be a way out of this = endless debate?

Regards,
RD

= --Apple-Mail-31--651192920-- From cb.list6@gmail.com Fri Sep 7 06:41:11 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FFA421E805D for ; Fri, 7 Sep 2012 06:41:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.848 X-Spam-Level: X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3xuttxy3Rj1v for ; Fri, 7 Sep 2012 06:41:10 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8718921E8098 for ; Fri, 7 Sep 2012 06:41:09 -0700 (PDT) Received: by lahm15 with SMTP id m15so2046018lah.31 for ; Fri, 07 Sep 2012 06:41:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FrqG+ds9n4z24MJYXKAy0S6QueYSaHiAKsCwzmlvij0=; b=pVY1LE9c/ErRgbvR53ew52yrvTin4rMPlcwTQQIrttfuURLSGMQkmC9sDRgzZur4LW vrElXFLGmvBV0HinBGtsXWA/GBbH+9OdE8ofdBuFO2i49CXMXl+WdqKytZJ0NGiMl23K 1PqTfHIgEw5VKvs4BGPQaB0d/HMmyBJW/rfVW/v5ahvu4A8umUk9BUzycFLpCoL57Yqn 5MakkZewGGDKKai4UQEVclfQ0LBBCMzP8ycgP03G5FdAu5bUft/r5URpafBh6CSOouTu XFPmugsuRYt6J+yMphts2ssK+JMhaR1Oqv7LKSBc++lin76fbTKGeuUG17DQfC67RepR xvMg== MIME-Version: 1.0 Received: by 10.112.30.41 with SMTP id p9mr2238199lbh.26.1347025264231; Fri, 07 Sep 2012 06:41:04 -0700 (PDT) Received: by 10.112.49.66 with HTTP; Fri, 7 Sep 2012 06:41:04 -0700 (PDT) Received: by 10.112.49.66 with HTTP; Fri, 7 Sep 2012 06:41:04 -0700 (PDT) In-Reply-To: <03e501cd8ce5$4ab52f80$4001a8c0@gateway.2wire.net> References: <504392E0.8070802@bogus.com> <448050D4-84F9-4F52-BF7E-347EA451A96C@laposte.net> <0AB559C2-855C-41F3-92D1-07F973EB760A@laposte.net> <03e501cd8ce5$4ab52f80$4001a8c0@gateway.2wire.net> Date: Fri, 7 Sep 2012 06:41:04 -0700 Message-ID: From: Cameron Byrne To: "t.petch" Content-Type: multipart/alternative; boundary=bcaec554d94c60c44b04c91cc26c Cc: v6ops WG Subject: Re: [v6ops] 464XLAT - /64 sharing was support of /64 delegated prefixes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 13:41:11 -0000 --bcaec554d94c60c44b04c91cc26c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sep 7, 2012 3:46 AM, "t.petch" wrote: > > Cameron > > Just to clarify, in your point 3), is the emphasis on 'standard', that > is that ND-Proxy is not on standards track? > Yes. > I see sharing a /64 as just another example of NBMA, which IPv6 sort of > supports. In this case, the 464 device is the hub and the IPv6 access > network one spoke and the downstream devices another set of spokes. OK, > the downstream devices may think that they are broadcast but they are > not, they are NBMA in this case. > Interesting. Is there an existing standards track doc that describes this behavior for ipv6 accross L3 interfaces? Is there an implementation to reference? This is a fair case, but i tend to think it is another very feasible implementation option that is best for the implementers to balance. I do not believe there is an easy case for this behavior to be described generically in 464xlat. CB > Tom Petch > > ----- Original Message ----- > From: "Cameron Byrne" > To: "R=E9mi Despr=E9s" > Cc: "v6ops WG" > Sent: Thursday, September 06, 2012 4:27 PM > Subject: Re: [v6ops] 464XLAT - support of /64 delegated prefixes > > > R=E9mi , > > On Thu, Sep 6, 2012 at 7:22 AM, R=E9mi Despr=E9s > wrote: > > > > 2012-09-06 15:16, Cameron Byrne : > > > > > > On Sep 6, 2012 1:03 AM, "Lorenzo Colitti" wrote: > >> > >> On Thu, Sep 6, 2012 at 4:54 PM, Maoke wrote: > >>> > >>> how can we ensure the above addresses do not conflict with any > manually, > >>> arbitrarily configured addresses? i am lost. :P - maoke > >> > >> > >> AIUI, we say "conflicts are impossible, because this is a reserved > range", > >> and then we cross our fingers. > >> > > > > I agree with Lorenzo's sarcasm. > > > > This "sarcasm" isn't deserved: one who manually configures a host with > an > > invalid address with regard to RFC 4291 should cross his fingers in > all > > cases, with 464XLAT or not. > > > > Here are the facts as i see them: > > 1. Many people on the list, including me, say we must share a /64 > from WAN to LAN > > 2. Multiple real world implementations of this /64 sharing exists in > various types of nodes, including the AOSP Android code. Hermant also > references he has experience with some CPE that share a /64 in > production networks using ND Proxy. And there is also the case of a > CPE that simply bridges WAN to LAN and has a logical / virtual place > on that share /64. Lorenzo also specified a method here > http://www.ietf.org/mail-archive/web/v6ops/current/msg13977.html > > 3. There is no standards track way to share a /64 from WAN to LAN, > the party line is DHCP-PD is the solution. New protocol work happens > in 6MAN. > > 4. Remi has provided, what i consider, to be a workable solution that > avoids the case of NAT44. > > So, we have a problem since #1 and #3 are a challenge, and #2 exists > > #4 is workable, but it has opponents and requires "hard coding" and > really is not core to 464XLAT. Removing the need for NAT44 is not a > goal, the overhead of having NAT44 is inconsequential to a modern CPE, > including smartphones. Related to hard coding, there is no RFC1918 > address that we can pick. ISPs are now dictating how residential LANs > must be configured so they do not overlap with the SP network's use of > RFC1918 space ... > http://keithbartholomew.com/2012/04/how-att-u-verse-broke-my-home-networ > k/ > > > > Besides, it is particularly unexpected from you, after you stated "In > the > > case of the Android CLAT code that was submitted to AOSP, the /64 is > simply > > copied from the WAN 3G/4G interfaces to the LAN. No magic. No ND > Proxy. No > > DHCP. But, it works for all known cases". > > With this, collisions between CLATs and host addresses are possible > even > > with well-behaved hosts =3D> The need to cross fingers is permanent ;-)= . > > No, NDP/DAD runs normally on the LAN side as a /64 and the WAN side is > a /128 ... /128 on WAN is normal operations for a Android phone on a > 3GPP network. > > The main takeaway from this: implementation specific solutions are ok > and left to the implementer and network operator to consider pros and > cons. > > The party line remains: DHCP-PD is best! While reality dictates and > the 464XLAT I-D must reflect that /64 sharing exists. > > I am not confident that this group of folks who don't have a very good > understanding of probability (manually configures 64 bit collisions?!) > will come to a consensus on a general solution, and even if they can > come to a consensus, 464XLAT is not the right vehicle for specifying > how a /64 is shared across interfaces. > > Let us just say /64 sharing exists and move on. If we believe /64 > must be codified on standards track, 6MAN may be the place for that > with its own I-D. > > > By using the proposed IANA-EUI-64 based /96, this is avoided and, with > a MAY > > in the draft, the somewhat risky choice you have described remains > possible. > > > > That said, we have been pushing this draft for a year trying to drive > > concensus. If we do not limit the scope to the core objective we will > be > > here for another year while the issue of ipv4-only hosts and apps > delays and > > hinders broader ipv6 deployment. > > > > On this, we agree. > > > > Still convinced to be one of the best supporters of a good 464XLAT > without > > undue delay, > > Thanks again! > > > Best regards, > > RD > > > > > > CB > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops > >> > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --bcaec554d94c60c44b04c91cc26c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Sep 7, 2012 3:46 AM, "t.petch" <ietfc@btconnect.com> wrote:
>
> Cameron
>
> Just to clarify, in your point 3), is the emphasis on 'standard= 9;, that
> is that ND-Proxy is not on standards track?
>

Yes.

> I see sharing a /64 as just another example of NBMA, which IPv6 sor= t of
> supports. =A0In this case, the 464 device is the hub and the IPv6 acce= ss
> network one spoke and the downstream devices another set of spokes. = =A0OK,
> the downstream devices may think that they are broadcast but they are<= br> > not, they are NBMA in this case.
>

Interesting. Is there an existing standards track doc that describes thi= s behavior for ipv6 accross L3 interfaces?

Is there an implementation to reference?

This is a fair case, but i tend to think it is another very feasible imp= lementation option that is best for the implementers to balance. I do not b= elieve there is an easy case for this behavior to be described generically = in 464xlat.

CB

> Tom Petch
>
> ----- Original Message -----
> From: "Cameron Byrne" <cb.list6@gmail.com>
> To: "R=E9mi Despr=E9s" <despres.remi@laposte.net>
> Cc: "v6ops WG" <v6ops@i= etf.org>
> Sent: Thursday, September 06, 2012 4:27 PM
> Subject: Re: [v6ops] 464XLAT - support of /64 delegated prefixes
>
>
> R=E9mi ,
>
> On Thu, Sep 6, 2012 at 7:22 AM, R=E9mi Despr=E9s <despres.remi@laposte.net>
> wrote:
> >
> > 2012-09-06 15:16, Cameron Byrne :
> >
> >
> > On Sep 6, 2012 1:03 AM, "Lorenzo Colitti" <lorenzo@google.com> wrote:
> >>
> >> On Thu, Sep 6, 2012 at 4:54 PM, Maoke <fibrib@gmail.com> wrote:
> >>>
> >>> how can we ensure the above addresses do not conflict wit= h any
> manually,
> >>> arbitrarily configured addresses? i am lost. :P - maoke > >>
> >>
> >> AIUI, we say "conflicts are impossible, because this is = a reserved
> range",
> >> and then we cross our fingers.
> >>
> >
> > I agree with Lorenzo's sarcasm.
> >
> > This "sarcasm" isn't deserved: one who manually con= figures a host with
> an
> > invalid address with regard to RFC 4291 should cross his fingers = in
> all
> > cases, with 464XLAT or not.
> >
>
> Here are the facts as i see them:
>
> 1. =A0Many people on the list, including me, say we must share a /64 > from WAN to LAN
>
> 2. =A0Multiple real world implementations of this /64 sharing exists i= n
> various types of nodes, including the AOSP Android code. =A0Hermant al= so
> references he has experience with some CPE that share a /64 in
> production networks using ND Proxy. And there is also the case of a > CPE that simply bridges WAN to LAN and has a logical / virtual place > on that share /64. =A0Lorenzo also specified a method here
> http://www.ietf.org/mail-archive/web/v6ops/current/msg13977.html=
>
> 3. =A0There is no standards track way to share a /64 from WAN to LAN,<= br> > the party line is DHCP-PD is the solution. =A0New protocol work happen= s
> in 6MAN.
>
> 4. =A0Remi has provided, what i consider, to be a workable solution th= at
> avoids the case of NAT44.
>
> So, we have a problem since #1 and #3 are a challenge, and #2 exists >
> #4 is workable, but it has opponents and requires "hard coding&qu= ot; and
> really is not core to 464XLAT. =A0Removing the need for NAT44 is not a=
> goal, the overhead of having NAT44 is inconsequential to a modern CPE,=
> including smartphones. =A0Related to hard coding, there is no RFC1918<= br> > address that we can pick. =A0ISPs are now dictating how residential LA= Ns
> must be configured so they do not overlap with the SP network's us= e of
> RFC1918 space ...
> http://keithbartholomew.com/2012/04/how-att-u-verse-broke-my= -home-networ
> k/
>
>
> > Besides, it is particularly unexpected from you, after you stated= "In
> the
> > case of the Android CLAT code that was submitted to AOSP, the /64= is
> simply
> > copied from the WAN 3G/4G interfaces to the LAN. No magic. No ND<= br> > Proxy. No
> > DHCP. =A0But, it works for all known cases".
> > With this, collisions between CLATs and host addresses are possib= le
> even
> > with well-behaved hosts =3D> The need to cross fingers is perm= anent ;-).
>
> No, NDP/DAD runs normally on the LAN side as a /64 and the WAN side is=
> a /128 ... =A0/128 on WAN is normal operations for a Android phone on = a
> 3GPP network.
>
> The main takeaway from this: =A0implementation specific solutions are = ok
> and left to the implementer and network operator to consider pros and<= br> > cons.
>
> The party line remains: =A0DHCP-PD is best! =A0While reality dictates = and
> the 464XLAT I-D must reflect =A0that /64 sharing exists.
>
> I am not confident that this group of folks who don't have a very = good
> understanding of probability (manually configures 64 bit collisions?!)=
> =A0will come to a consensus on a general solution, and even if they ca= n
> come to a consensus, 464XLAT is not the right vehicle for specifying > how a /64 is shared across interfaces.
>
> Let us just say /64 sharing exists and move on. =A0If we believe /64 > must be codified on standards track, 6MAN may be the place for that > with its own I-D.
>
> > By using the proposed IANA-EUI-64 based /96, this is avoided and,= with
> a MAY
> > in the draft, the somewhat risky choice you have described remain= s
> possible.
> >
> > That said, we have been pushing this draft for a year trying to d= rive
> > concensus. If we do not limit the scope to the core objective we = will
> be
> > here for another year while the issue of ipv4-only hosts and apps=
> delays and
> > hinders broader ipv6 deployment.
> >
> > On this, we agree.
> >
> > Still convinced to be one of the best supporters of a good 464XLA= T
> without
> > undue delay,
>
> Thanks again!
>
> > Best regards,
> > RD
> >
> >
> > CB
> >> _______________________________________________
> >> v6ops mailing list
> >> v6ops@ietf.org
> >> https= ://www.ietf.org/mailman/listinfo/v6ops
> >>
> >
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.org
> > https://w= ww.ietf.org/mailman/listinfo/v6ops
> >
> >
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops
>
>

--bcaec554d94c60c44b04c91cc26c-- From despres.remi@laposte.net Fri Sep 7 06:59:53 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 415E321F87F7 for ; Fri, 7 Sep 2012 06:59:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.068 X-Spam-Level: X-Spam-Status: No, score=-1.068 tagged_above=-999 required=5 tests=[AWL=0.280, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sVCkjD+7+te8 for ; Fri, 7 Sep 2012 06:59:52 -0700 (PDT) Received: from smtp25.services.sfr.fr (smtp25.services.sfr.fr [93.17.128.118]) by ietfa.amsl.com (Postfix) with ESMTP id A071021F87EA for ; Fri, 7 Sep 2012 06:59:51 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2502.sfr.fr (SMTP Server) with ESMTP id D5426700008E; Fri, 7 Sep 2012 15:59:50 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2502.sfr.fr (SMTP Server) with ESMTP id 4B9B37000050; Fri, 7 Sep 2012 15:59:50 +0200 (CEST) X-SFR-UUID: 20120907135950309.4B9B37000050@msfrf2502.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-32--647997225 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Fri, 7 Sep 2012 15:59:50 +0200 Message-Id: References: To: Maoke X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 13:59:53 -0000 --Apple-Mail-32--647997225 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Maoke, Your scenario below is out of scope (see reasons below), but it has the = interesting advantage of pointing out that a correction is needed, in = the current draft, in the paragraph about BIH: BIH scope is IPv4-only = APPLICATIONS that reach IPv6-only servers, not IPv4-only HOSTS as = written.=20 Dealing also with Lorenzo's point, this paragraph could then become: "By combining 464XLAT with BIH [RFC6535], it is also possible to provide = single IPv4 to IPv6 translation service, which will be needed in the = future case of IPv6-only servers to be reached across IPv6-only networks = from IPv4-only applications in CLAT nodes. (By doing so, BIH continue to = not be used together with a NAT64, as recommended in [RFC6535], 464XLAT = being in charge of using NAT64s as PLATs.)" Two points make your scenario off-cope: - as reminded above, BIH is not for applications in IPv4-only hosts = (only for applications in hosts that support BIH). - CLATs only treat outgoing connections, thus excluding CLAT-to-CLAT = scenarios. Yet, thanks for this detailed case. It proved to be useful. Regards, RD =20 =20 Le 2012-09-07 =E0 12:54, Maoke a =E9crit : >=20 >=20 > 2012/9/7 R=E9mi Despr=E9s >=20 > 2012-09-07 12:03, Lorenzo Colitti : >=20 >> On Fri, Sep 7, 2012 at 6:42 PM, R=E9mi Despr=E9s = wrote: >> BIH is the only IETF specification for an IPv4-only application in a = node attached to an IPv6-only network to reach an IPv6-only server = WITHOUT depending on any special node between the two (transparent proxy = or whatever).=20 >>=20 >> And yet, before the problem it solves actually becomes a problem, = things could change substantially. New, better methods can come along. = It could be obsoleted. It could change. And we'd be stuck with a BCP = that endorses something that's not relevant any more. So if you really = want to mention IPv6-only servers, I would suggest replacing the current = text with the following: >>=20 >> 464XLAT does not provide a means for IPv4-only applications to = communicate with IPv6-only servers. If this capability is necessary, = 464XLAT can be coupled with another transition mechanisms such as BIH = [RFC6535]. >>=20 >> That way it's clear that this document does not specify a best = practice for IPv4-only clients to talk to IPv6-only servers, but only = for IPv4-only apps on an IPv6-only network. >>=20 >> In any case, I think the following points have to be resolved before = we can make progress: >>=20 >> 1. The conflict between section 1, which talks about IPv6-only = servers, and section 2, which declares them out of scope, must be = resolved. >> 2. Before we mention BIH in this document, we should ensure that at = least one implementation of 464XLAT+BIH has been tested. We don't want = to publish a BCP that suggests doing something that has never been = tested. >=20 > No new comment on the above. >=20 >> 3. If this document suggests using 464XLAT + BIH together, it needs = to say why the text in the BIH RFC which says "Use of BIH together with = a NAT64 is NOT RECOMMENDED" is not relevant to this case. >=20 > This is new consideration, but not a problem: > =20 > =20 > actually, Remi, i have to point out it is problem. this is related to = my talk with you that the private addresses are also possibly used for a = server. > =20 > 0. the domain operator makes address planning with the private address = in order to avoid potential conflict; > 1. a host having private IPv4 address are located in a LAN behind = BIH/CLAT box, with IPv6 prefixes configured with the box; =20 > 2. it is running a server and a client peer behind another CLAT, = somehow, know the server's address (it is private but static); > 3. the client sends out a request to the server's IPv4 address, both = src and dst are translated by the CLAT statelessly; > 4. the CLAT of the server side decodes the IPv4-converted addresses = and delivered the translated packet to the server; > 5. the server responds the request, while the reply arrives at the = BIH/CLAT, trouble happens: which module to proceed? if it is the CLAT, = fortunately, we are lucky, and things just worked as IVI with double = translation. if BIH takes the session, well, what would happen? i don't = think BIH is covering this case too with its synthetic IPv4 and the real = IPv6 addresses because the peer (the client) is not IPv6 now at all. BIH = state needs to be established by the initiator of the session but = combining it with CLAT makes it uncertain when the initiation bypasses = BIH at all. > =20 > this is a very realistic case when we want to deploy an in-domain = server group. and 464xlat itself can works well. but the combination of = 464xlat to BIH may cause some trouble. Lorenzo and me argued that the = combination was not tested. this is a real case of risk. of course, we = may patch it, but it is definitely far beyond one paragraph stating that = "combining them is useful".=20 > =20 > if we have time, i may find more and more cases where the combination = introduces uncertainty. therefore i think it is safe to scope out the = problem right now. > =20 > - maoke > =20 > =20 > - The RFC says that BIH should not send packets to NAT64s. > - This doesn't prevent a node supporting BIH to also support 464XLAT = which, precisely is designed to send packets to PLATs, AKA NAT64s. >=20 > This point underlines how complementary the two specifications are. >=20 > RD >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 --Apple-Mail-32--647997225 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 "By combining 464XLAT with BIH [RFC6535], it is also = possible to provide single IPv4 to IPv6 translation service, which will = be needed in the future case of IPv6-only servers to be = reached across IPv6-only networks = from IPv4-only applications in CLAT nodes. (By = doing so, BIH continue to not be used together with a NAT64, as = recommended in [RFC6535], 464XLAT being in charge of using NAT64s as = PLATs.)"

Two points make your = scenario off-cope:
- as reminded above, BIH is not for = applications in IPv4-only hosts (only for applications in hosts that = support BIH).
- CLATs only treat outgoing connections, thus = excluding CLAT-to-CLAT scenarios.
Yet, thanks for this = detailed case. It proved to be = useful.

Regards,
RD
 

 
Le 2012-09-07 =E0 12:54, = Maoke a =E9crit :



2012/9/7 R=E9mi = Despr=E9s <despres.remi@laposte.net>

2012-09-07 12:03, = Lorenzo Colitti :

On = Fri, Sep 7, 2012 at 6:42 PM, R=E9mi Despr=E9s <despres.remi@laposte.net> wrote:
BIH is the only IETF specification = for an IPv4-only application in a node attached to an IPv6-only network = to reach an IPv6-only server WITHOUT depending on any special node = between the two (transparent proxy or whatever). 

And yet, before the problem it = solves actually becomes a problem, things could change substantially. = New, better methods can come along. It could be obsoleted. It could = change. And we'd be stuck with a BCP that endorses something that's not = relevant any more. So if you really want to mention IPv6-only servers, I = would suggest replacing the current text with the following:

464XLAT does not provide a means for IPv4-only = applications to communicate with IPv6-only servers. If this capability = is necessary, 464XLAT can be coupled with another transition mechanisms = such as BIH [RFC6535].

That way it's clear that this document does not = specify a best practice for IPv4-only clients to talk to IPv6-only = servers, but only for IPv4-only apps on an IPv6-only = network.

In any case, I think the following points have to be resolved = before we can make progress:

1. The conflict = between section 1, which talks about IPv6-only servers, and section 2, = which declares them out of scope, must be resolved.
2. Before we mention BIH in this document, we should ensure = that at least one implementation of 464XLAT+BIH has been tested. We = don't want to publish a BCP that suggests doing something that has never = been tested.

No new comment on the = above.

3. If this document suggests using 464XLAT + BIH together, it needs = to say why the text in the BIH RFC which says "Use of BIH together with = a NAT64 is NOT RECOMMENDED" is not relevant to this = case.

This is new consideration, but not a = problem:
 
 
ac= tually, Remi, i have to point out it is problem. this is related to my = talk with you that the private addresses are also possibly used for a = server.
 
0. the domain operator makes address planning with = the private address in order to avoid potential conflict; =
1. a host having private IPv4 address are = located in a LAN behind BIH/CLAT box, with IPv6 prefixes configured with = the box;   
2. it is running a server and a client peer behind = another CLAT, somehow, know the server's address (it is private but = static);
3. the client sends out a request to the = server's IPv4 address, both src and dst are translated by the CLAT = statelessly;
4. the CLAT of the server side decodes the IPv4-converted addresses = and delivered the translated packet to the server;
5. the = server responds the request, while the reply arrives at the BIH/CLAT, = trouble happens: which module to proceed? if it is the CLAT, = fortunately, we are lucky, and things just worked as IVI with double = translation. if BIH takes the session, well, what would happen? i don't = think BIH is covering this case too with its synthetic IPv4 and the real = IPv6 addresses because the peer (the client) is not IPv6 now at all. BIH = state needs to be established by the initiator of the session but = combining it with CLAT makes it uncertain when the initiation bypasses = BIH at all.
 
this is a very realistic case when we want to = deploy an in-domain server group. and 464xlat itself can works well. but = the combination of 464xlat to BIH may cause some trouble. Lorenzo and me = argued that the combination was not tested. this is a real case of risk. = of course, we may patch it, but it is definitely far beyond one = paragraph stating that "combining them is useful".
 
if we have time, i may find more and more cases = where the combination introduces uncertainty. therefore i think it is = safe to scope out the problem right now.
 
- = maoke
 
 
- The RFC says that = BIH should not send packets to NAT64s.
- This doesn't prevent a node supporting BIH to also support = 464XLAT which, precisely is designed to send packets to PLATs, AKA = NAT64s.

This point underlines how complementary = the two specifications are.

RD





__________________= _____________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops



= --Apple-Mail-32--647997225-- From fibrib@gmail.com Fri Sep 7 07:21:39 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C870221E80AC for ; Fri, 7 Sep 2012 07:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J82wKEbixLLP for ; Fri, 7 Sep 2012 07:21:38 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4E51421E8051 for ; Fri, 7 Sep 2012 07:21:38 -0700 (PDT) Received: by eaai11 with SMTP id i11so978450eaa.31 for ; Fri, 07 Sep 2012 07:21:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2c8upbx1rKUj11ar82rGeHDRe99L7QkLb8mnVNRLCOE=; b=C8s/4D2Ha3fXQgRm55daMU/ssUhhIg5N28ZT5lu0jwQibUJ57R+STVpbp4PGTmDxWK 2wDzE3k6bsYZfLBWt31FugU5kE6RH7tHX00i/+Ez98jknsex7M+Ladtxg5ZUBF7b2vn3 bGLEOVGWpr5TxxbLP3GcG+ldR0vzbC+3lMBrd/ZSR+9Ezwsv8YiBlUmjAvsq9uYqLEzK DyXo2kyBgz/aqLsVjLjcUgA3X48ZkqltlRuztQjNSU895NqElfLe6GVrCSk1tpPvNm2T 7aEp2gewORDJHoAjxg0iic+v2MZ89JZpU8n17+VEd4Im7IZHWHWq1KpGhyOG+G3h7ovf 8qIQ== MIME-Version: 1.0 Received: by 10.14.202.66 with SMTP id c42mr8247216eeo.35.1347027697288; Fri, 07 Sep 2012 07:21:37 -0700 (PDT) Received: by 10.14.97.9 with HTTP; Fri, 7 Sep 2012 07:21:37 -0700 (PDT) In-Reply-To: References: Date: Fri, 7 Sep 2012 23:21:37 +0900 Message-ID: From: Maoke To: GangChen Content-Type: multipart/alternative; boundary=047d7b33daf466463104c91d5310 Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 14:21:39 -0000 --047d7b33daf466463104c91d5310 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable =D4=DA 2012=C4=EA9=D4=C27=C8=D5=D0=C7=C6=DA=CE=E5=A3=ACGangChen =D0=B4=B5= =C0=A3=BA > 2012/9/7, Maoke >: > > 2012/9/7 R=A8=A6mi Despr=A8=A6s > > > > >> > >> 2012-09-07 12:03, Lorenzo Colitti : > >> > >> On Fri, Sep 7, 2012 at 6:42 PM, R=A8=A6mi Despr=A8=A6s > >> >wrote: > >> > >>> BIH is the only IETF specification for an IPv4-only application in a > >>> node > >>> attached to an IPv6-only network to reach an IPv6-only server WITHOUT > >>> depending on any special node between the two (transparent proxy or > >>> whatever). > >>> > >> > >> And yet, before the problem it solves actually becomes a problem, thin= gs > >> could change substantially. New, better methods can come along. It cou= ld > >> be > >> obsoleted. It could change. And we'd be stuck with a BCP that endorses > >> something that's not relevant any more. So if you really want to menti= on > >> IPv6-only servers, I would suggest replacing the current text with the > >> following: > >> > >> 464XLAT does not provide a means for IPv4-only applications to > >> communicate > >> with IPv6-only servers. If this capability is necessary, 464XLAT can b= e > >> coupled with another transition mechanisms such as BIH [RFC6535]. > >> > >> That way it's clear that this document does not specify a best practic= e > >> for IPv4-only clients to talk to IPv6-only servers, but only for > >> IPv4-only > >> apps on an IPv6-only network. > >> > >> In any case, I think the following points have to be resolved before w= e > >> can make progress: > >> > >> 1. The conflict between section 1, which talks about IPv6-only servers= , > >> and section 2, which declares them out of scope, must be resolved. > >> 2. Before we mention BIH in this document, we should ensure that at > least > >> one implementation of 464XLAT+BIH has been tested. We don't want to > >> publish > >> a BCP that suggests doing something that has never been tested. > >> > >> > >> No new comment on the above. > >> > >> 3. If this document suggests using 464XLAT + BIH together, it needs to > >> say > >> why the text in the BIH RFC which says "Use of BIH together with a NAT= 64 > >> is > >> NOT RECOMMENDED" is not relevant to this case. > >> > >> > >> This is new consideration, but not a problem: > >> > >> > > > > actually, Remi, i have to point out it is problem. this is related to m= y > > talk with you that the private addresses are also possibly used for a > > server. > > > > 0. the domain operator makes address planning with the private address = in > > order to avoid potential conflict; > > 1. a host having private IPv4 address are located in a LAN behind > BIH/CLAT > > box, with IPv6 prefixes configured with the box; > > 2. it is running a server and a client peer behind another CLAT, someho= w, > > know the server's address (it is private but static); > > 3. the client sends out a request to the server's IPv4 address, both sr= c > > and dst are translated by the CLAT statelessly; > > 4. the CLAT of the server side decodes the IPv4-converted addresses and > > delivered the translated packet to the server; > > 5. the server responds the request, while the reply arrives at the > > BIH/CLAT, trouble happens: which module to proceed? if it is the CLAT, > > fortunately, we are lucky, and things just worked as IVI with double > > translation. if BIH takes the session, well, what would happen? i don't > > think BIH is covering this case too with its synthetic IPv4 and the rea= l > > IPv6 addresses because the peer (the client) is not IPv6 now at all. BI= H > > state needs to be established by the initiator of the session but > combining > > it with CLAT makes it uncertain when the initiation bypasses BIH at all= . > > The packages are headed to CLAT is identified by the destination > address with TUN IPv6 address; the packages heading to BIH are with > IPv6 destination that matches the mapping table. That is > implementation detailed. I believe there are multiple ways could do > that. What the trouble you can see? 1. no business with TUN in 464xlat, IMHO. 2. "you believe" is not an approval for a BCP. enough. - maoke > > BRs > > Gang > > > > this is a very realistic case when we want to deploy an in-domain serve= r > > group. and 464xlat itself can works well. but the combination of 464xla= t > to > > BIH may cause some trouble. Lorenzo and me argued that the combination > was > > not tested. this is a real case of risk. of course, we may patch it, bu= t > it > > is definitely far beyond one paragraph stating that "combining them is > > useful". > > > > if we have time, i may find more and more cases where the combination > > introduces uncertainty. therefore i think it is safe to scope out the > > problem right now. > > > > - maoke > > > > > >> > >> - The RFC says that BIH should not send packets to NAT64s. > >> - This doesn't prevent a node supporting BIH to also support 464XLAT > >> which, precisely is designed to send packets to PLATs, AKA NAT64s. > >> > >> This point underlines how complementary the two specifications are. > >> > >> RD > >> > >> > >> > >> > >> > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops > >> > >> > > > --047d7b33daf466463104c91d5310 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable

=D4=DA 2012=C4=EA9=D4=C27=C8=D5=D0=C7=C6=DA=CE=E5=A3=ACGangChen = =D0=B4=B5=C0=A3=BA
2012/9/7, Maoke <fibrib@gmail.com>:
> 2012/9/7 R=A8=A6mi Despr=A8=A6s <despres.= remi@laposte.net>
>
>>
>> 2012-09-07 12:03, Lorenzo Colitti :
>>
>> On Fri, Sep 7, 2012 at 6:42 PM, R=A8=A6mi Despr=A8=A6s
>> <despres.remi@laposte.net>wrote:=
>>
>>> BIH is the only IETF specification for an IPv4-only applicatio= n in a
>>> node
>>> attached to an IPv6-only network to reach an IPv6-only server = WITHOUT
>>> depending on any special node between the two (transparent pro= xy or
>>> whatever).
>>>
>>
>> And yet, before the problem it solves actually becomes a problem, = things
>> could change substantially. New, better methods can come along. It= could
>> be
>> obsoleted. It could change. And we'd be stuck with a BCP that = endorses
>> something that's not relevant any more. So if you really want = to mention
>> IPv6-only servers, I would suggest replacing the current text with= the
>> following:
>>
>> 464XLAT does not provide a means for IPv4-only applications to
>> communicate
>> with IPv6-only servers. If this capability is necessary, 464XLAT c= an be
>> coupled with another transition mechanisms such as BIH [RFC6535].<= br> >>
>> That way it's clear that this document does not specify a best= practice
>> for IPv4-only clients to talk to IPv6-only servers, but only for >> IPv4-only
>> apps on an IPv6-only network.
>>
>> In any case, I think the following points have to be resolved befo= re we
>> can make progress:
>>
>> 1. The conflict between section 1, which talks about IPv6-only ser= vers,
>> and section 2, which declares them out of scope, must be resolved.=
>> 2. Before we mention BIH in this document, we should ensure that a= t least
>> one implementation of 464XLAT+BIH has been tested. We don't wa= nt to
>> publish
>> a BCP that suggests doing something that has never been tested. >>
>>
>> No new comment on the above.
>>
>> 3. If this document suggests using 464XLAT + BIH together, it need= s to
>> say
>> why the text in the BIH RFC which says "Use of BIH together w= ith a NAT64
>> is
>> NOT RECOMMENDED" is not relevant to this case.
>>
>>
>> This is new consideration, but not a problem:
>>
>>
>
> actually, Remi, i have to point out it is problem. this is related to = my
> talk with you that the private addresses are also possibly used for a<= br> > server.
>
> 0. the domain operator makes address planning with the private address= in
> order to avoid potential conflict;
> 1. a host having private IPv4 address are located in a LAN behind BIH/= CLAT
> box, with IPv6 prefixes configured with the box;
> 2. it is running a server and a client peer behind another CLAT, someh= ow,
> know the server's address (it is private but static);
> 3. the client sends out a request to the server's IPv4 address, bo= th src
> and dst are translated by the CLAT statelessly;
> 4. the CLAT of the server side decodes the IPv4-converted addresses an= d
> delivered the translated packet to the server;
> 5. the server responds the request, while the reply arrives at the
> BIH/CLAT, trouble happens: which module to proceed? if it is the CLAT,=
> fortunately, we are lucky, and things just worked as IVI with double > translation. if BIH takes the session, well, what would happen? i don&= #39;t
> think BIH is covering this case too with its synthetic IPv4 and the re= al
> IPv6 addresses because the peer (the client) is not IPv6 now at all. B= IH
> state needs to be established by the initiator of the session but comb= ining
> it with CLAT makes it uncertain when the initiation bypasses BIH at al= l.

The packages are headed to CLAT is identified by the destination
address with TUN IPv6 address; the packages heading to BIH are with
IPv6 destination that matches the mapping table. That is
implementation detailed. I believe there are multiple ways could do
that. What the trouble you can see?

1. no b= usiness with TUN in 464xlat, IMHO.
2. "you believe" is = not an approval for a BCP.

enough. 

- maoke
 

BRs

Gang


> this is a very realistic case when we want to deploy an in-domain serv= er
> group. and 464xlat itself can works well. but the combination of 464xl= at to
> BIH may cause some trouble. Lorenzo and me argued that the combination= was
> not tested. this is a real case of risk. of course, we may patch it, b= ut it
> is definitely far beyond one paragraph stating that "combining th= em is
> useful".
>
> if we have time, i may find more and more cases where the combination<= br> > introduces uncertainty. therefore i think it is safe to scope out the<= br> > problem right now.
>
> - maoke
>
>
>>
>> - The RFC says that BIH should not send packets to NAT64s.
>> - This doesn't prevent a node supporting BIH to also support 4= 64XLAT
>> which, precisely is designed to send packets to PLATs, AKA NAT64s.=
>>
>> This point underlines how complementary the two specifications are= .
>>
>> RD
>>
>>
>>
>>
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
>>
>
--047d7b33daf466463104c91d5310-- From ietfc@btconnect.com Fri Sep 7 07:25:18 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB36621F853C for ; Fri, 7 Sep 2012 07:25:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.049 X-Spam-Level: X-Spam-Status: No, score=-3.049 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yttfOFGcmkWK for ; Fri, 7 Sep 2012 07:25:17 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe002.messaging.microsoft.com [216.32.180.12]) by ietfa.amsl.com (Postfix) with ESMTP id 6D4D921E8051 for ; Fri, 7 Sep 2012 07:25:17 -0700 (PDT) Received: from mail91-va3-R.bigfish.com (10.7.14.247) by VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id 14.1.225.23; Fri, 7 Sep 2012 14:25:16 +0000 Received: from mail91-va3 (localhost [127.0.0.1]) by mail91-va3-R.bigfish.com (Postfix) with ESMTP id 10A8F320129; Fri, 7 Sep 2012 14:25:16 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.253.197; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0710HT004.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -26 X-BigFish: PS-26(zz98dI9371Ic89bh936eI542M1432I111aIzz1202hzz8275ch1033IL8275bh8275dhz2dh2a8h5a9h668h839hd24hf0ah107ah1177h1179h1288h304l1155h) Received: from mail91-va3 (localhost.localdomain [127.0.0.1]) by mail91-va3 (MessageSwitch) id 1347027913939236_25976; Fri, 7 Sep 2012 14:25:13 +0000 (UTC) Received: from VA3EHSMHS009.bigfish.com (unknown [10.7.14.240]) by mail91-va3.bigfish.com (Postfix) with ESMTP id E1AB74A0046; Fri, 7 Sep 2012 14:25:13 +0000 (UTC) Received: from DBXPRD0710HT004.eurprd07.prod.outlook.com (157.56.253.197) by VA3EHSMHS009.bigfish.com (10.7.99.19) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 7 Sep 2012 14:25:10 +0000 Received: from DBXPRD0410HT001.eurprd04.prod.outlook.com (157.56.252.149) by pod51017.outlook.com (10.255.79.167) with Microsoft SMTP Server (TLS) id 14.16.190.9; Fri, 7 Sep 2012 14:25:01 +0000 Message-ID: <05e901cd8d04$abcc7020$4001a8c0@gateway.2wire.net> From: t.petch To: Cameron Byrne References: <504392E0.8070802@bogus.com><448050D4-84F9-4F52-BF7E-347EA451A96C@laposte.net><0AB559C2-855C-41F3-92D1-07F973EB760A@laposte.net><03e501cd8ce5$4ab52f80$4001a8c0@gateway.2wire.net> Date: Fri, 7 Sep 2012 15:25:38 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.252.149] Content-Transfer-Encoding: quoted-printable X-OriginatorOrg: btconnect.com Cc: v6ops WG Subject: Re: [v6ops] 464XLAT - /64 sharing was support of /64 delegated prefixes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 14:25:18 -0000 ----- Original Message ----- From: "Cameron Byrne" To: "t.petch" Cc: "v6ops WG" Sent: Friday, September 07, 2012 2:41 PM On Sep 7, 2012 3:46 AM, "t.petch" wrote: > > Cameron > > Just to clarify, in your point 3), is the emphasis on 'standard', that > is that ND-Proxy is not on standards track? Yes. > I see sharing a /64 as just another example of NBMA, which IPv6 sort of > supports. In this case, the 464 device is the hub and the IPv6 access > network one spoke and the downstream devices another set of spokes. OK, > the downstream devices may think that they are broadcast but they are > not, they are NBMA in this case. Interesting. Is there an existing standards track doc that describes this behavior for ipv6 accross L3 interfaces? Is there an implementation to reference? Sorry no, no standard or implementation as far as I know, rather it is how I view it analytically (as perhaps does Fred when he said "ND Proxy is designed for the Non-Broadcast Multi-access case."). There may be a tendency to view the world radiating out from the ISP, from the CLAT, whereas sometimes it makes more sense (to me) to view the PLAT as the centre of the world. Tom Petch This is a fair case, but i tend to think it is another very feasible implementation option that is best for the implementers to balance. I do not believe there is an easy case for this behavior to be described generically in 464xlat. CB > Tom Petch > > ----- Original Message ----- > From: "Cameron Byrne" > To: "R=E9mi Despr=E9s" > Cc: "v6ops WG" > Sent: Thursday, September 06, 2012 4:27 PM > Subject: Re: [v6ops] 464XLAT - support of /64 delegated prefixes > > > R=E9mi , > > On Thu, Sep 6, 2012 at 7:22 AM, R=E9mi Despr=E9s > wrote: > > > > 2012-09-06 15:16, Cameron Byrne : > > > > > > On Sep 6, 2012 1:03 AM, "Lorenzo Colitti" wrote: > >> > >> On Thu, Sep 6, 2012 at 4:54 PM, Maoke wrote: > >>> > >>> how can we ensure the above addresses do not conflict with any > manually, > >>> arbitrarily configured addresses? i am lost. :P - maoke > >> > >> > >> AIUI, we say "conflicts are impossible, because this is a reserved > range", > >> and then we cross our fingers. > >> > > > > I agree with Lorenzo's sarcasm. > > > > This "sarcasm" isn't deserved: one who manually configures a host with > an > > invalid address with regard to RFC 4291 should cross his fingers in > all > > cases, with 464XLAT or not. > > > > Here are the facts as i see them: > > 1. Many people on the list, including me, say we must share a /64 > from WAN to LAN > > 2. Multiple real world implementations of this /64 sharing exists in > various types of nodes, including the AOSP Android code. Hermant also > references he has experience with some CPE that share a /64 in > production networks using ND Proxy. And there is also the case of a > CPE that simply bridges WAN to LAN and has a logical / virtual place > on that share /64. Lorenzo also specified a method here > http://www.ietf.org/mail-archive/web/v6ops/current/msg13977.html > > 3. There is no standards track way to share a /64 from WAN to LAN, > the party line is DHCP-PD is the solution. New protocol work happens > in 6MAN. > > 4. Remi has provided, what i consider, to be a workable solution that > avoids the case of NAT44. > > So, we have a problem since #1 and #3 are a challenge, and #2 exists > > #4 is workable, but it has opponents and requires "hard coding" and > really is not core to 464XLAT. Removing the need for NAT44 is not a > goal, the overhead of having NAT44 is inconsequential to a modern CPE, > including smartphones. Related to hard coding, there is no RFC1918 > address that we can pick. ISPs are now dictating how residential LANs > must be configured so they do not overlap with the SP network's use of > RFC1918 space ... > http://keithbartholomew.com/2012/04/how-att-u-verse-broke-my-home-networ > k/ > > > > Besides, it is particularly unexpected from you, after you stated "In > the > > case of the Android CLAT code that was submitted to AOSP, the /64 is > simply > > copied from the WAN 3G/4G interfaces to the LAN. No magic. No ND > Proxy. No > > DHCP. But, it works for all known cases". > > With this, collisions between CLATs and host addresses are possible > even > > with well-behaved hosts =3D> The need to cross fingers is permanent ;-). > > No, NDP/DAD runs normally on the LAN side as a /64 and the WAN side is > a /128 ... /128 on WAN is normal operations for a Android phone on a > 3GPP network. > > The main takeaway from this: implementation specific solutions are ok > and left to the implementer and network operator to consider pros and > cons. > > The party line remains: DHCP-PD is best! While reality dictates and > the 464XLAT I-D must reflect that /64 sharing exists. > > I am not confident that this group of folks who don't have a very good > understanding of probability (manually configures 64 bit collisions?!) > will come to a consensus on a general solution, and even if they can > come to a consensus, 464XLAT is not the right vehicle for specifying > how a /64 is shared across interfaces. > > Let us just say /64 sharing exists and move on. If we believe /64 > must be codified on standards track, 6MAN may be the place for that > with its own I-D. > > > By using the proposed IANA-EUI-64 based /96, this is avoided and, with > a MAY > > in the draft, the somewhat risky choice you have described remains > possible. > > > > That said, we have been pushing this draft for a year trying to drive > > concensus. If we do not limit the scope to the core objective we will > be > > here for another year while the issue of ipv4-only hosts and apps > delays and > > hinders broader ipv6 deployment. > > > > On this, we agree. > > > > Still convinced to be one of the best supporters of a good 464XLAT > without > > undue delay, > > Thanks again! > > > Best regards, > > RD > > > > > > CB > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops > >> > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > From fibrib@gmail.com Fri Sep 7 07:37:46 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE0B21F844B for ; Fri, 7 Sep 2012 07:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.803 X-Spam-Level: X-Spam-Status: No, score=-1.803 tagged_above=-999 required=5 tests=[AWL=-0.955, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ffs9eql-IeJR for ; Fri, 7 Sep 2012 07:37:45 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2408F21F8419 for ; Fri, 7 Sep 2012 07:37:44 -0700 (PDT) Received: by eekb45 with SMTP id b45so1288424eek.31 for ; Fri, 07 Sep 2012 07:37:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yRo0r1tQXEglELJjVfq+QsB37HuN3VdYh7a9OwG59l4=; b=vSRVyQtYWfAGkYzPxhkjpDjYroq5b+bmnuQkPhRJxHkyAkl5uE9mnobNo4dQUVeP4Z 5kB01JDqQxsX/PU44ZyUKGM7ME/oVQmEjEkixScqJ2phWBFDBNHgnTt+rrzoS1764SwM mU/81dwtYsOhGjTInENNVETLW5EyoflrjZZzCP9Dfl8WR54EEOKM8JPxNaH4gl60H5lv W1/Tsn38+SVSbtDCvc7iZIRkToaUwxr/c4zz8W5meBAt63GAssUJ3xGt36XHSGXtXah0 q7Dke6ogniWl00rKE4/UCrMUmItPBKb297lNqGDsuF5BrVXreJby/1tguRq47Ce6YpBB ToZA== MIME-Version: 1.0 Received: by 10.14.184.134 with SMTP id s6mr8176308eem.46.1347028664284; Fri, 07 Sep 2012 07:37:44 -0700 (PDT) Received: by 10.14.97.9 with HTTP; Fri, 7 Sep 2012 07:37:44 -0700 (PDT) In-Reply-To: References: Date: Fri, 7 Sep 2012 23:37:44 +0900 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=047d7b3a7ff80977ad04c91d8d70 Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 14:37:46 -0000 --047d7b3a7ff80977ad04c91d8d70 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable =D4=DA 2012=C4=EA9=D4=C27=C8=D5=D0=C7=C6=DA=CE=E5=A3=ACR=A8=A6mi Despr=A8= =A6s =D0=B4=B5=C0=A3=BA > Maoke, > > Your scenario below is out of scope (see reasons below), > what i propased is always out of scope. what you proposed is always in. well, i said the combination is harmful technically. even if the wg agrees the scenario is out of scope, i require a paragraph stating that: the 464xlat itself, even out of scope of the design motivation, can also naturally support mesh communication once the private addresses are planned and statically assigned to in-domain servers. if it is combined with BIH, however, such a naturally enabled feature would be in trouble. with such a explicit explanation, i could accept what you seggest below. otherwise i don't accept the confusion. sorry to the chair and the authors! - maoke > but it has the interesting advantage of pointing out that a correction is > needed, in the current draft, in the paragraph about BIH: BIH scope is > IPv4-only APPLICATIONS that reach IPv6-only servers, not IPv4-only HOSTS = as > written. > > Dealing also with Lorenzo's point, this paragraph could then become: > "By combining 464XLAT with BIH [RFC6535], it is also possible to provide > single IPv4 to IPv6 translation service, which will be needed in the futu= re > case of IPv6-only servers to be reached across IPv6-only networks fromti > IPv4-only applications in CLAT nodes. (By doing so, BIH continue to not b= e > used together with a NAT64, as recommended in [RFC6535], 464XLAT being in > charge of using NAT64s as PLATs.)" > > Two points make your scenario off-cope: > - as reminded above, BIH is not for applications in IPv4-only hosts (only > for applications in hosts that support BIH). > - CLATs only treat outgoing connections, thus excluding CLAT-to-CLAT > scenarios. > Yet, thanks for this detailed case. It proved to be useful. > > Regards, > RD > > > > Le 2012-09-07 =A8=A4 12:54, Maoke a =A8=A6crit : > > > > 2012/9/7 R=A8=A6mi Despr=A8=A6s > > > 2012-09-07 12:03, Lorenzo Colitti : > > On Fri, Sep 7, 2012 at 6:42 PM, R=A8=A6mi Despr=A8=A6s wrote: > > BIH is the only IETF specification for an IPv4-only application in a node > attached to an IPv6-only network to reach an IPv6-only server WITHOUT > depending on any special node between the two (transparent proxy or > whatever). > > > And yet, before the problem it solves actually becomes a problem, things > could change substantially. New, better methods can come along. It could = be > obsoleted. It could change. And we'd be stuck with a BCP that endorses > something that's not relevant any more. So if you really want to mention > IPv6-only servers, I would suggest replacing the current text with the > following: > > 464XLAT does not provide a means for IPv4-only applications to communicat= e > with IPv6-only servers. If this capability is necessary, 464XLAT can be > coupled with another transition mechanisms such as BIH [RFC6535]. > > That way it's clear that this document does not specify a best practice > for IPv4-only clients to talk to IPv6-only servers, but only for IPv4-onl= y > apps on an IPv6-only network. > > In any case, I think the following points have to be resolved before we > can make progress: > > 1. The conflict between section 1, which talks about IPv6-only servers, > and section 2, which declares them out of scope, must be resolved. > 2. Before we mention BIH in this document, we should ensure that at least > one implementation of 464XLAT+BIH has been tested. We don't want to publi= sh > a BCP that suggests doing something that has never been tested. > > > No new comment on the above. > > 3. If this document suggests using 464XLAT + BIH together, it needs to sa= y > why the text in the BIH RFC which says "Use of BIH together with a NAT64 = is > NOT RECOMMENDED" is not relevant to this case. > > > This is new consideration, but not a problem: > > > > actually, Remi, i have to point out it is problem. this is related to my > talk with you that the private addresses are also possibly used for a > server. > > 0. the domain operator makes address planning with the private address in > order to avoid potential conflict; > 1. a host having private IPv4 address are located in a LAN behind BIH/CLA= T > box, with IPv6 prefixes configured with the box; > 2. it is running a server and a client peer behind another CLAT, somehow, > know the server's address (it is private but static); > 3. the client sends out a request to the server's IPv4 address, both src > and dst are translated by the CLAT statelessly; > 4. the CLAT of the server side decodes the IPv4-converted addresses and > delivered the translated packet to the server; > 5. the server responds the request, while the reply arrives at the > BIH/CLAT, trouble happens: which module to proceed? if it is the CLAT, > fortunately, we are lucky, and things just worked as IVI with double > translation. if BIH takes the session, well, what would happen? i don't > think BIH is covering this case too with its synthetic IPv4 and the real > IPv6 addresses because the peer (the client) is not IPv6 now at all. BIH > state needs to be established by the initiator of the session but combini= ng > it with CLAT makes it uncertain when the initiation bypasses BIH at all. > > this is a very realistic case when we want to deploy an in-domain server > group. and 464xlat itself can works well. but the combination of 464xlat = to > BIH may cause some trouble. Lorenzo and me argued that the combination wa= s > not tested. this is a real case of risk. of course, we may patch it, but = it > is definitely far beyond one paragraph stating that "combining them is > useful". > > if we have time, i may find more and more cases where the combination > introduces uncertainty. therefore i think it is safe to scope out the > problem right now. > > > > --047d7b3a7ff80977ad04c91d8d70 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable

=D4=DA 2012=C4=EA9=D4=C27=C8=D5=D0=C7=C6=DA=CE=E5=A3=ACR=A8=A6mi De= spr=A8=A6s =D0=B4=B5=C0=A3=BA
Maoke,

Your scenario below i= s out of scope (see reasons below), 

what i propased is always= out of scope. what you proposed is always in. well, i said the combination= is harmful technically. even if the wg agrees the scenario is out of scope= , i require a paragraph stating that: 

  the 464xlat itself, even out of scope of the des= ign motivation, can also naturally support mesh communication once the priv= ate addresses are planned and statically assigned to in-domain servers. if = it is combined with BIH, however, such a naturally enabled feature would be= in trouble. 

with such a explicit explanation, i could accept what y= ou seggest below. otherwise i don't accept the confusion. sorry to the = chair and the authors!

- maoke
 
but it has the interesting advantage of pointing out that a c= orrection is needed, in the current draft, in the paragraph about BIH: &nbs= p;BIH scope is IPv4-only APPLICATIONS that reach IPv6-only servers, not IPv= 4-only HOSTS as written. 

Dealing also with Lorenzo's point, this  parag= raph could then become:
"By combining 464XLAT with BIH [RFC6535], it is also= possible to provide single IPv4 to IPv6 translation service, which will be= needed in the future case of IPv6-only servers to be reached <= span style=3D"font-family:monospace;white-space:pre-wrap">across IPv6-only = networks = fromti IPv4-only applications in CLAT nodes. (By doing so, BIH continue to = not be used together with a NAT64, as recommended in [RFC6535], 464XLAT bei= ng in charge of using NAT64s as PLATs.)"

Two points make your scenario off-cope:
- as reminded above, BIH is not for applications in IPv4-only ho= sts (only for applications in hosts that support BIH).
- CLATs on= ly treat outgoing connections, thus excluding CLAT-to-CLAT scenarios.
Yet, thanks for this detailed case. It proved to be useful.
=
Regards,
RD
 

<= div> 
Le 2012-09-07 =A8=A4 12:54, Maoke a =A8=A6crit :


2012/9/7 R=A8=A6mi Despr=A8=A6s <despr= es.remi@laposte.net>

2012-09-07 12:03, Lorenzo= Colitti :

On Fri, Sep 7, 2012 at 6= :42 PM, R=A8=A6mi Despr=A8=A6s <despres.remi@lapost= e.net> wrote:
BIH is the only IETF specification for = an IPv4-only application in a node attached to an IPv6-only network to reac= h an IPv6-only server WITHOUT depending on any special node between the two= (transparent proxy or whatever). 

And yet, before the problem it solve= s actually becomes a problem, things could change substantially. New, bette= r methods can come along. It could be obsoleted. It could change. And we= 9;d be stuck with a BCP that endorses something that's not relevant any= more. So if you really want to mention IPv6-only servers, I would suggest = replacing the current text with the following:

464XLAT does not provide a means for IPv4-only applicat= ions to communicate with IPv6-only servers. If this capability is necessary= , 464XLAT can be coupled with another transition mechanisms such as BIH&nbs= p;[RFC6535].

That way it's clear that this document does not spe= cify a best practice for IPv4-only clients to talk to IPv6-only servers, bu= t only for IPv4-only apps on an IPv6-only network.

In any case, I think the following points have to be resolved before w= e can make progress:

1. The conflict between secti= on 1, which talks about IPv6-only servers, and section 2, which declares th= em out of scope, must be resolved.
2. Before we mention BIH in this document, we should ensure that = at least one implementation of 464XLAT+BIH has been tested. We don't wa= nt to publish a BCP that suggests doing something that has never been teste= d.

No new comment on the above.

3. If this document suggests using 464XLAT + BIH together, it needs to= say why the text in the BIH RFC which says "Use of BIH together with = a NAT64 is NOT RECOMMENDED" is not relevant to this case.

This is new consideration, but not a prob= lem:
 
 
actuall= y, Remi, i have to point out it is problem. this is related to my talk with= you that the private addresses are also possibly used for a server.
 
0. the domain operator makes address planning with th= e private address in order to avoid potential conflict;
1. = a host having private IPv4 address are located in a LAN behind BI= H/CLAT box, with IPv6 prefixes configured with the box;   
2. it is running a server and a client peer behind anot= her CLAT, somehow, know the server's address (it is private but static)= ;
3. the client sends out a request to the server's IPv= 4 address, both src and dst are translated by the CLAT statelessly;
4. the CLAT of the server side decodes the IPv4-converted addresses an= d delivered the translated packet to the server;
5. the server r= esponds the request, while the reply arrives at the BIH/CLAT, trouble happe= ns: which module to proceed? if it is the CLAT, fortunately, we are lucky, = and things just worked as IVI with double translation. if BIH takes the ses= sion, well, what would happen? i don't think BIH is covering this case = too with its synthetic IPv4 and the real IPv6 addresses because the peer (t= he client) is not IPv6 now at all. BIH state needs to be established by the= initiator of the session but combining it with CLAT makes it uncertain whe= n the initiation bypasses BIH at all.
 
this is a very realistic case when we want to deploy = an in-domain server group. and 464xlat itself can works well. but the combi= nation of 464xlat to BIH may cause some trouble. Lorenzo and me argued that= the combination was not tested. this is a real case of risk. of course, we= may patch it, but it is definitely far beyond one paragraph stating that &= quot;combining them is useful".
 
if we have time, i may find more and more cases where= the combination introduces uncertainty. therefore i think it is safe to sc= ope out the problem right now.
 

--047d7b3a7ff80977ad04c91d8d70-- From phdgang@gmail.com Fri Sep 7 07:44:20 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02A0721E80AD for ; Fri, 7 Sep 2012 07:44:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[AWL=-1.363, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SgEYN5R+puTb for ; Fri, 7 Sep 2012 07:44:19 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id DD7D121E8051 for ; Fri, 7 Sep 2012 07:44:18 -0700 (PDT) Received: by ggnh4 with SMTP id h4so561830ggn.31 for ; Fri, 07 Sep 2012 07:44:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ht3ATr9CfuTUKvOBnAyTHDWv4VHm+WlWOt9xgfF+XZw=; b=J03aUALD/5uKByrIeB+HcIic0TtiIXnBlBanyvvjWK3sOFulydBgtmQVgNlfOIi1Ye Zq0V+IEH+TidPDQ5Smr/69gqYWcgdVdFjItakPdNclLXsYKDAH2ki83B39+W3LV0uiS2 pg60sgVrLjhbKk4n//ECfquCPE5eiCM2qP3qgsaZnPKaUFZRYRs/SlbJoFCkC3qtFQNH WrzlZBiB71OMJXXeAb9rC059f9BzZ+6aIVL+O60V0RBMS5mYz4jVg3SC/71GtkonDpoQ xI6GXor3EH99aYpHpZxXso4fpGMPc4FHcrns2Q/HMW/eq+R1apAp/lrcCW8TETzXbmA6 73Sw== MIME-Version: 1.0 Received: by 10.220.37.194 with SMTP id y2mr7346430vcd.44.1347029058414; Fri, 07 Sep 2012 07:44:18 -0700 (PDT) Received: by 10.58.114.231 with HTTP; Fri, 7 Sep 2012 07:44:18 -0700 (PDT) In-Reply-To: References: Date: Fri, 7 Sep 2012 22:44:18 +0800 Message-ID: From: GangChen To: Maoke Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 14:44:20 -0000 2012/9/7, Maoke : > =D4=DA 2012=C4=EA9=D4=C27=C8=D5=D0=C7=C6=DA=CE=E5=A3=ACGangChen =D0=B4=B5= =C0=A3=BA > >> 2012/9/7, Maoke >: >> > 2012/9/7 R=A8=A6mi Despr=A8=A6s > >> > >> >> >> >> 2012-09-07 12:03, Lorenzo Colitti : >> >> >> >> On Fri, Sep 7, 2012 at 6:42 PM, R=A8=A6mi Despr=A8=A6s >> >> >wrote: >> >> >> >>> BIH is the only IETF specification for an IPv4-only application in a >> >>> node >> >>> attached to an IPv6-only network to reach an IPv6-only server WITHOU= T >> >>> depending on any special node between the two (transparent proxy or >> >>> whatever). >> >>> >> >> >> >> And yet, before the problem it solves actually becomes a problem, >> >> things >> >> could change substantially. New, better methods can come along. It >> >> could >> >> be >> >> obsoleted. It could change. And we'd be stuck with a BCP that endorse= s >> >> something that's not relevant any more. So if you really want to >> >> mention >> >> IPv6-only servers, I would suggest replacing the current text with th= e >> >> following: >> >> >> >> 464XLAT does not provide a means for IPv4-only applications to >> >> communicate >> >> with IPv6-only servers. If this capability is necessary, 464XLAT can >> >> be >> >> coupled with another transition mechanisms such as BIH [RFC6535]. >> >> >> >> That way it's clear that this document does not specify a best >> >> practice >> >> for IPv4-only clients to talk to IPv6-only servers, but only for >> >> IPv4-only >> >> apps on an IPv6-only network. >> >> >> >> In any case, I think the following points have to be resolved before >> >> we >> >> can make progress: >> >> >> >> 1. The conflict between section 1, which talks about IPv6-only >> >> servers, >> >> and section 2, which declares them out of scope, must be resolved. >> >> 2. Before we mention BIH in this document, we should ensure that at >> least >> >> one implementation of 464XLAT+BIH has been tested. We don't want to >> >> publish >> >> a BCP that suggests doing something that has never been tested. >> >> >> >> >> >> No new comment on the above. >> >> >> >> 3. If this document suggests using 464XLAT + BIH together, it needs t= o >> >> say >> >> why the text in the BIH RFC which says "Use of BIH together with a >> >> NAT64 >> >> is >> >> NOT RECOMMENDED" is not relevant to this case. >> >> >> >> >> >> This is new consideration, but not a problem: >> >> >> >> >> > >> > actually, Remi, i have to point out it is problem. this is related to >> > my >> > talk with you that the private addresses are also possibly used for a >> > server. >> > >> > 0. the domain operator makes address planning with the private address >> > in >> > order to avoid potential conflict; >> > 1. a host having private IPv4 address are located in a LAN behind >> BIH/CLAT >> > box, with IPv6 prefixes configured with the box; >> > 2. it is running a server and a client peer behind another CLAT, >> > somehow, >> > know the server's address (it is private but static); >> > 3. the client sends out a request to the server's IPv4 address, both >> > src >> > and dst are translated by the CLAT statelessly; >> > 4. the CLAT of the server side decodes the IPv4-converted addresses an= d >> > delivered the translated packet to the server; >> > 5. the server responds the request, while the reply arrives at the >> > BIH/CLAT, trouble happens: which module to proceed? if it is the CLAT, >> > fortunately, we are lucky, and things just worked as IVI with double >> > translation. if BIH takes the session, well, what would happen? i don'= t >> > think BIH is covering this case too with its synthetic IPv4 and the >> > real >> > IPv6 addresses because the peer (the client) is not IPv6 now at all. >> > BIH >> > state needs to be established by the initiator of the session but >> combining >> > it with CLAT makes it uncertain when the initiation bypasses BIH at >> > all. >> >> The packages are headed to CLAT is identified by the destination >> address with TUN IPv6 address; the packages heading to BIH are with >> IPv6 destination that matches the mapping table. That is >> implementation detailed. I believe there are multiple ways could do >> that. What the trouble you can see? > > > 1. no business with TUN in 464xlat, IMHO. AFAICS, http://www.ietf.org/mail-archive/web/v6ops/current/msg12664.html > 2. "you believe" is not an approval for a BCP. > > enough. > > - maoke > > >> >> BRs >> >> Gang >> >> >> > this is a very realistic case when we want to deploy an in-domain >> > server >> > group. and 464xlat itself can works well. but the combination of >> > 464xlat >> to >> > BIH may cause some trouble. Lorenzo and me argued that the combination >> was >> > not tested. this is a real case of risk. of course, we may patch it, >> > but >> it >> > is definitely far beyond one paragraph stating that "combining them is >> > useful". >> > >> > if we have time, i may find more and more cases where the combination >> > introduces uncertainty. therefore i think it is safe to scope out the >> > problem right now. >> > >> > - maoke >> > >> > >> >> >> >> - The RFC says that BIH should not send packets to NAT64s. >> >> - This doesn't prevent a node supporting BIH to also support 464XLAT >> >> which, precisely is designed to send packets to PLATs, AKA NAT64s. >> >> >> >> This point underlines how complementary the two specifications are. >> >> >> >> RD >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> v6ops mailing list >> >> v6ops@ietf.org >> >> https://www.ietf.org/mailman/listinfo/v6ops >> >> >> >> >> > >> > From ietfc@btconnect.com Fri Sep 7 07:54:00 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9705B21E80B2 for ; Fri, 7 Sep 2012 07:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.339 X-Spam-Level: X-Spam-Status: No, score=-3.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JDGOqaFfOApb for ; Fri, 7 Sep 2012 07:53:59 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe005.messaging.microsoft.com [216.32.180.188]) by ietfa.amsl.com (Postfix) with ESMTP id 2120621E8051 for ; Fri, 7 Sep 2012 07:53:59 -0700 (PDT) Received: from mail127-co1-R.bigfish.com (10.243.78.234) by CO1EHSOBE010.bigfish.com (10.243.66.73) with Microsoft SMTP Server id 14.1.225.23; Fri, 7 Sep 2012 14:53:58 +0000 Received: from mail127-co1 (localhost [127.0.0.1]) by mail127-co1-R.bigfish.com (Postfix) with ESMTP id 2E96FA800B5; Fri, 7 Sep 2012 14:53:58 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.249.85; KIP:(null); UIP:(null); IPV:NLI; H:AMSPRD0710HT004.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: PS-24(z4c5Iz98dI9371Ic89bh542Mzz1202hzz1033IL8275bh8275dhz2dh2a8h5a9h668h839hd24hf0ah107ah1177h1179h1288h304l1155h) Received: from mail127-co1 (localhost.localdomain [127.0.0.1]) by mail127-co1 (MessageSwitch) id 1347029636739437_5019; Fri, 7 Sep 2012 14:53:56 +0000 (UTC) Received: from CO1EHSMHS017.bigfish.com (unknown [10.243.78.234]) by mail127-co1.bigfish.com (Postfix) with ESMTP id A7E4D98022E; Fri, 7 Sep 2012 14:53:56 +0000 (UTC) Received: from AMSPRD0710HT004.eurprd07.prod.outlook.com (157.56.249.85) by CO1EHSMHS017.bigfish.com (10.243.66.27) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 7 Sep 2012 14:53:54 +0000 Received: from DBXPRD0410HT005.eurprd04.prod.outlook.com (157.56.252.149) by pod51017.outlook.com (10.255.160.167) with Microsoft SMTP Server (TLS) id 14.16.190.9; Fri, 7 Sep 2012 14:53:39 +0000 Message-ID: <05f901cd8d08$ab6cc720$4001a8c0@gateway.2wire.net> From: t.petch To: "Fred Baker (fred)" , v6ops WG References: <504392E0.8070802@bogus.com><448050D4-84F9-4F52-BF7E-347EA451A96C@laposte.net> Date: Fri, 7 Sep 2012 15:54:11 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.252.149] Content-Transfer-Encoding: quoted-printable X-OriginatorOrg: btconnect.com Subject: Re: [v6ops] Reminder: draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 14:54:00 -0000 ----- Original Message ----- From: "Fred Baker (fred)" To: "v6ops WG" Sent: Wednesday, September 05, 2012 7:31 PM On Sep 3, 2012, at 8:17 AM, R=E9mi Despr=E9s wrote: > If the WGLC is, like an IESG last call, "to make sure that no important concerns have been missed or misunderstood" (RFC 2418), I think we aren't quite at this stage yet. > The current discussions on ND proxy and/or IANA-reserved IIDs is still progressing, but AFAIK without clear conclusion. The purpose of a WGLC is, as you say, to ensure that important concerns have not been missed or misunderstood. It is not to to prove or create unanimity of viewpoint, although that would be a happy outcome. If in the opinion of the chairs all opinions have been expressed and new issues are not being raised, a single person or small group that disagrees with the outcome is consistent with "rough consensus". I note that this morning we have additional comments from Ray and Woj, which I think need to be heard and addressed. So I'll let the WGLC continue the remainder of this week to see what additionally shakes loose. Note to the authors: we will need a -08 as an outcome of the WGLC. Based on what has emerged in the WGLC, there are two points I would like to see strengthened in the I-D. One is that while DHCPv6-PD can be expected in a 'wired' environment, the same is not true in a 'weird' environment, at least for the foreseeable future. Perhaps in s.8.2.1, add "While DHCPv6-PD is the most straightforward way to implement 464XLAT, this function is not widely available in current 3GPP networks nor is it likely to be for some time, perhaps years, to come." Second, support for tethering is a necessity but cascading 464XLAT is not. I am not sure where this should go, perhaps s.6 after "Wireless 3GPP Network Architecture can fit in the situations that client and node that terminate access network is same host in the same way" (which itself is a sentence I would like reworded - I don't know what it means:-( Something like "In a wireless environment, 464XLAT provides support for tethered devices but this does not extend to the cascading of 464XLAT devices" I want to see this I-D progress but switched my view from 'support' to 'more work needed' based on what emerged in WGLC. These two points are - shock horror - not based on my own external experience but on my judgement of what has been expressed on this list during WGLC, that is that they need incorporating somewhere. Tom Petch From cb.list6@gmail.com Fri Sep 7 08:00:10 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE3421F84D3 for ; Fri, 7 Sep 2012 08:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.723 X-Spam-Level: X-Spam-Status: No, score=-2.723 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0AREZj8hmis6 for ; Fri, 7 Sep 2012 08:00:09 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id A3D9621E80BA for ; Fri, 7 Sep 2012 08:00:08 -0700 (PDT) Received: by lahm15 with SMTP id m15so2103083lah.31 for ; Fri, 07 Sep 2012 08:00:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=deAvoCvS6fCFotBkpGp3zph49I5TBVWGmOvb0IqOnkA=; b=o7XdtQvGCpBxZWDYDAU2lv3rtfYPXOfX2DhX1ZKm/oX2xvjcyaB1NaZRCIGBw1rdTA Uzc1A7nhn54ypkiDQuRunRm88WasIHUvRpmqnVZPGEAW9BcIWKwZEJoURTBcbdK/Nh4h rTttmoL0FS4pvmVSFScsJowg5FJFQymt1uwIJluQAMCTzd6YuEwFE5b7k7yvHikZme8c qa0vSujgYfH5RzOUo3AC+qF5w+DKO1mj3ZDSJiNClXHzhs362rjxem02J4M0THoWXZpx gTGRGLhUKYpP+XIv9MpNlEmsNkqtatpCWVXgehbghTha2z8t1CiQJR/FZsaZO887c6Qu NzBw== MIME-Version: 1.0 Received: by 10.152.104.172 with SMTP id gf12mr5643582lab.56.1347030007338; Fri, 07 Sep 2012 08:00:07 -0700 (PDT) Received: by 10.112.49.66 with HTTP; Fri, 7 Sep 2012 08:00:07 -0700 (PDT) Received: by 10.112.49.66 with HTTP; Fri, 7 Sep 2012 08:00:07 -0700 (PDT) In-Reply-To: <9F02FD3E-46C5-4BBB-ACBB-BB59DD420F24@laposte.net> References: <47F98720-3E3F-4920-A890-A5FD10843F0D@laposte.net> <36B8743C-5758-4B7F-9C31-0A4CD02D772A@laposte.net> <9F02FD3E-46C5-4BBB-ACBB-BB59DD420F24@laposte.net> Date: Fri, 7 Sep 2012 08:00:07 -0700 Message-ID: From: Cameron Byrne To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=f46d04088d0d16d76e04c91ddd9f Cc: v6ops WG Subject: Re: [v6ops] 464XLAT and BIH X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 15:00:10 -0000 --f46d04088d0d16d76e04c91ddd9f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sep 7, 2012 1:41 AM, "R=E9mi Despr=E9s" wrote= : > > > Le 2012-09-07 =E0 10:18, Maoke a =E9crit : > >> >> >> 2012/9/7 R=E9mi Despr=E9s >>> >>> >>> Le 2012-09-07 =E0 09:41, Maoke a =E9crit : >>> >>>> >>>> >>>> 2012/9/7 R=E9mi Despr=E9s >>>>> >>>>> >>>>> Le 2012-09-07 =E0 04:33, Maoke a =E9crit : >>>>> ... >>>>> > as we are talking about a BCP, if 464xlat doc states BIH is an indispensible part of the standard, our customers will require us to definitely provide such a function or such an option rather than any other alternatives in the service suite. i doubt this is the common floor the working group is on. >>>>> ... >>>>> >>>>> 1. Stating that a combining 464XLAT with BIH is "possible" isn't stating it is "indispensable". >>>>> >>>>> 2. Being part of a a "BCP" isn't being part of a "standard". >>>>> 3. Authors initially wrote "It is also possible to provide single IPv4/IPv6 translation service, which will be needed in the future case of IPv6-only servers and peers to be reached from legacy IPv4-only hosts." The added BIH reference better covers the original intent, by just stating a fact useful to be known. >> >> >> (#) following point is emphasized >>>> >>>> >>>> it is interesting. i don't think the authors were originally intent to involve a helper for providing "single IPv4/IPv6 translation service". and surely the phrase is correct, because CLAT supports IPv4/IPv6 single translation without need anything more once the addressing support statelessness; it is also happens between an IPv4 host in the Internet having access to the native IPv6 server through the PLAT. >>>> >>>> adding the BIH, is actually adding another solution to the CLAT box for another problem, heavily biased from the original intent which contains CLAT stateless single translation service and the PLAT stateful translation service. > > > The current sentence has been coined by authors themselves. > It is therefore, presumably, compatible with their original intent. > Confirmed. In the best interest of making a complete bcp for the stated scope that is timeless, as represented by the traffic treatment table, bih fills a hole that makes that table symmetric and complete. Removing or adding bih does not change the scope or motivation, the reference to bih is just a pointer for future scenarios that was discussed on the list and vetted some time back. Pardon me for being synical. It is my fear that we are not actually having a discussion about 464xlat but a proxy fight with a "competing" i-d. Otherwise, i cannot understand so many last minute passionate debates over truly fringe issues. .. And calls for defining 464xlat in terms of map-t and not any other solution. Once again, pardon me, i hope it is not the case. CB > I would really prefer to hear from you about 464XLAT with /64 delegated prefixes (and no NAT44 to be completely stateless), assuming you are also interested in _technical choices_ to be made before publication. > > > RD > > > > >>>> >> >> >> (/#) end of emphasis >>>>> >>>>> Confirmed stand: >>>>> - At a time when there are still discussions on functional aspects of 464XLAT, this particular discussion is IMHO a waste of time >>>> >>>> >>>> scope and problem is more important than solution. waste of time is not an execuse of passing misleading and confused sentences. >>> >>> >>> The sentence is AFAIK neither misleading nor confused. >>> Yes, 464XLAT and BIH have complementary targets and can usefully be combined. >>> >> >> >> AFAIK the sentence is misleading. 464 target is clearly described in Section 2. the original intent of mentioning the IPv4/IPv6 single translation was not a target, IMHO, but a natural result. it is fine not to include the original intent if we think that is out of scope. it is also fine to include that if we think that non-normative. >> >> but replacing the original intent with statement on BIH actually made things different. see my (#) that is emphasized above. >> >> i may change the question: what BIH can gain from being combined with 464xlat? anything? >> >> - maoke >> >>> >>> >>> Just stating a preference (my right I suppose). >>> >>> RD >>> >>> >>>> >>>> - maoke >>> >>> >> > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --f46d04088d0d16d76e04c91ddd9f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Sep 7, 2012 1:41 AM, "R=E9mi Despr=E9s" <despres.remi@laposte.net> wrote:
>
>
> Le 2012-09-07 =E0 10:18, Maoke a =E9crit :
>
>>
>>
>> 2012/9/7 R=E9mi Despr=E9s <despres.remi@laposte.net>
>>>
>>>
>>> Le 2012-09-07 =E0 09:41, Maoke a =E9crit :
>>>
>>>>
>>>>
>>>> 2012/9/7 R=E9mi Despr=E9s <despres.remi@laposte.net>
>>>>>
>>>>>
>>>>> Le 2012-09-07 =E0 04:33, Maoke a =E9crit :
>>>>> ...
>>>>> > as we are talking about a BCP, if 464xlat doc sta= tes BIH is an indispensible part of the standard, our customers will requir= e us to definitely provide such a function or such an option rather than an= y other alternatives in the service suite. i doubt this is the common floor= the working group is on.
>>>>> ...
>>>>>
>>>>> 1. Stating that a combining 464XLAT with BIH is "= possible" isn't stating it is "indispensable".=A0
>>>>>
>>>>> 2. Being part of a a "BCP" isn't being p= art of a "standard".
>>>>> 3. Authors initially wrote "It is also possible t= o provide single IPv4/IPv6 translation service, which will be needed in the= future case of IPv6-only servers and peers to be reached from legacy IPv4-= only hosts." The added BIH reference better covers the original intent= , by just stating a fact useful to be known.
>>
>> =A0
>> (#) =A0following point is emphasized
>>>>
>>>> =A0
>>>> it is=A0interesting.=A0i don't think the authors=A0wer= e originally intent to involve=A0a helper=A0for=A0providing "single IP= v4/IPv6 translation service". and surely the phrase is correct, becaus= e CLAT supports IPv4/IPv6 single translation without need anything more onc= e the addressing support statelessness; it is also happens between an IPv4 = host in the Internet having access to the native IPv6 server through the PL= AT.
>>>> =A0
>>>> adding the BIH, is actually adding another solution=A0to t= he CLAT box=A0for another problem,=A0heavily biased=A0from the=A0original i= ntent which contains CLAT stateless single translation service and the PLAT= stateful translation service.
>
>
> The current sentence has been coined by authors themselves.=A0
> It is therefore, presumably, compatible with their original intent. >

Confirmed.

In the best interest of making a complete bcp for the stated scope that = is timeless, as represented by the traffic treatment table, bih fills a hol= e that makes that table symmetric and complete. Removing or adding bih does= not change the scope or motivation, the reference to bih is just a pointer= for future scenarios that was discussed on the list and vetted some time b= ack.

Pardon me for being synical. It is my fear that we are not actually havi= ng a discussion about 464xlat but a proxy fight with a "competing"= ; i-d. Otherwise, i cannot understand so many last minute passionate debate= s over truly fringe issues. .. And calls for defining 464xlat in terms of m= ap-t and not any other solution.

Once again, pardon me, i hope it is not the case.

CB

> I would really prefer to hear from you about 464XLAT with /64 deleg= ated prefixes (and no NAT44 to be completely stateless), assuming you are a= lso interested in _technical choices_ to be made before publication.
>
>
> RD
>
>
>
>
>>>> =A0
>>
>> =A0
>> (/#) end of emphasis=A0
>>>>>
>>>>> Confirmed stand:
>>>>> - At a time when there are still discussions on functi= onal aspects of 464XLAT, this particular discussion is IMHO a waste of time=
>>>>
>>>> =A0
>>>> scope and problem is more important than solution. waste o= f time is not an execuse of passing misleading and confused=A0sentences. >>>
>>>
>>> The sentence is AFAIK neither misleading nor confused.
>>> Yes, 464XLAT and BIH have complementary targets and can useful= ly be combined.
>>> =A0
>>
>> =A0
>> AFAIK the sentence is misleading. 464 target is clearly described = in Section 2. the original intent of mentioning the IPv4/IPv6 single transl= ation was not a target, IMHO, but a natural result. it is fine not to inclu= de the original intent if we think that is out of scope. it is also fine to= include that if we think that non-normative.
>> =A0
>> but replacing the original intent with statement on BIH actually m= ade things different. see my (#) that is emphasized=A0above.
>> =A0
>> i may change the question: what BIH can gain from being combined w= ith 464xlat? anything?
>> =A0
>> - maoke
>> =A0
>>>
>>> =A0
>>> Just stating a preference (my right I suppose).=A0
>>>
>>> RD
>>>
>>>
>>>> =A0
>>>> - maoke
>>>
>>>
>>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops
>

--f46d04088d0d16d76e04c91ddd9f-- From fibrib@gmail.com Fri Sep 7 08:00:49 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA8221F84EB for ; Fri, 7 Sep 2012 08:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=-1.006, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3kLonoqRxaCx for ; Fri, 7 Sep 2012 08:00:48 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 637CE21F84DC for ; Fri, 7 Sep 2012 08:00:48 -0700 (PDT) Received: by eaai11 with SMTP id i11so991886eaa.31 for ; Fri, 07 Sep 2012 08:00:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bU7mPK09V3OeQGIqIC3rrpdhXQgmWim+INSdhJeMYKg=; b=NVGgIITDPwAY+iulsFawNaal0t0cUfbyV61Uzp3pr2uQ42aTw5SvJOZ7ZbUTeQR35Z 0O6dZwBK75Br3Dc9mDVOTbDkX8TigBLwXCzsJJ982j7PLeHp5vorvqz2Obd6p+XjmXKa ea+1WthutTMtg3RQTAf2rIGcOxEA5JI6cVN6iQSIRKMFwSYzSEW1IEkbnZXoBIFPRzzP u0XwM84kjHxlS7T391M4AVssfyHwnfvHw4GzL5ILkfup2qS+5ybj2wbyWxenZJuxddZa 9Lrnsr53WkM2JPtGlw8/hajbD/zE6ygsP2q15BOOmUpuYrkLEzz8ZH1TuQIYSIixvm60 ln7A== MIME-Version: 1.0 Received: by 10.14.202.66 with SMTP id c42mr8412530eeo.35.1347030047571; Fri, 07 Sep 2012 08:00:47 -0700 (PDT) Received: by 10.14.97.9 with HTTP; Fri, 7 Sep 2012 08:00:47 -0700 (PDT) In-Reply-To: <810EAE3D-8767-4E66-911D-3DBDFE8B9403@laposte.net> References: <810EAE3D-8767-4E66-911D-3DBDFE8B9403@laposte.net> Date: Sat, 8 Sep 2012 00:00:47 +0900 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=047d7b33daf47cc0ae04c91ddff2 Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 15:00:49 -0000 --047d7b33daf47cc0ae04c91ddff2 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable hi Lorenzo, =D4=DA 2012=C4=EA9=D4=C27=C8=D5=D0=C7=C6=DA=CE=E5=A3=ACR=A8=A6mi Despr=A8= =A6s =D0=B4=B5=C0=A3=BA > > Le 2012-09-07 =A8=A4 12:36, Lorenzo Colitti a =A8=A6crit : > > On Fri, Sep 7, 2012 at 7:16 PM, R=A8=A6mi Despr=A8=A6s > > wrote: > >> 3. If this document suggests using 464XLAT + BIH together, it needs to >> say why the text in the BIH RFC which says "Use of BIH together with >> a NAT64 is NOT RECOMMENDED" is not relevant to this case. >> >> >> This is new consideration, but not a problem: >> - The RFC says that BIH should not send packets to NAT64s. >> - This doesn't prevent a node supporting BIH to also support 464XLAT >> which, precisely is designed to send packets to PLATs, AKA NAT64s. >> > > If you don't want to remove BIH, then please suggest text to address this > issue. The text that is currently in the draft does not do so, and since > it's a conflict with a standards track RFC, we have to say something abou= t > it. > > > As said, I don't think there is a problem in cohabitation of 464XLAT, by > design used with NAT64, and BIH whose use with a NAT64 isn't recommended. > > Yet, if this covers your concern, and raises no objection from > authors, the last paragraph of section 1 could be completed, e.g. as > follows: > > "By combining 464XLAT with BIH [RFC6535], it is also possible to provide = single IPv4 to IPv6 translation service, which will be needed in the future= case of IPv6-only servers and peers to be reached from IPv4-only hosts acr= oss IPv6-only networks. By doing so, BIH continue to not be used together w= ith a NAT64, as recommended in [RFC6535], 464XLAT being in charge of using = NAT64s as PLATs." > > thanks for the composing. it is constructive. however, single ipv4 to ipv6 translation service is provides by any standard fitting RFC6144 framework. 464xlat itself can provide this with special addressing. BIH can provide this independently too. and i didn't see any effort and benefit of the "combination" rather than only putting them together. my suggestion: "464xlat is not designed to cover the case of IPv4-only applications having access to IPv6-only servers, which will be possibly needed in the future. Together using it with BIH [RFC6535] can be a feasible solution, if this demand becomes true, and we leave the details of the co-existance to the implemantaion. By doing so, BIH continue to not be used together with a NAT64, as recommended in [RFC6535], while 464xlat is being in charge of using NAT64s as PLATs." if this is acceptable, i end debating soon. - maoke > Could this be a way out of this endless debate? > > Regards, > RD > > --047d7b33daf47cc0ae04c91ddff2 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable hi Lorenzo,

=D4=DA 2012=C4=EA9=D4=C27=C8=D5=D0=C7=C6=DA=CE=E5=A3=AC= R=A8=A6mi Despr=A8=A6s =D0=B4=B5=C0=A3=BA

Le 2012-09-07 =A8=A4 12= :36, Lorenzo Colitti a =A8=A6crit :

On Fri, Sep 7, 2012 at 7:16 PM, R=A8=A6mi Des= pr=A8=A6s <despres.remi@lapo= ste.net> wrote:
3. If this document suggests using 464XLAT + B= IH together, it needs to say why the text in the BIH RFC which says "U= se of BIH together with a NAT64 is NOT RECOMMENDED" is not releva= nt to this case.

This is new consideration, but not a prob= lem:
- The RFC says that BIH should not send packets to NAT64s.
- This doesn't prevent a node supporting BIH to also support 4= 64XLAT which, precisely is designed to send packets to PLATs, AKA NAT64s.

If you don't want to remove BIH,= then please suggest text to address this issue. The text that is currently= in the draft does not do so, and since it's a conflict with a standard= s track RFC, we have to say something about it.

As said, I don't think there is a problem i= n cohabitation of 464XLAT, by design used with NAT64, and BIH whose use wit= h a NAT64 isn't recommended.

Yet, if this= covers your concern, and raises no objection from authors, the last p= aragraph of section 1 could be completed, e.g. as follows:
"By combining 464XLAT with BIH [RFC6535], it is a=
lso possible to provide single IPv4 to IPv6 translation service, which will=
 be needed in the future case of IPv6-only servers and peers to be reached =
from IPv4-only hosts across IPv6-only networks. By doing so, BIH continue t=
o not be used together with a NAT64, as recommended in [RFC6535], 464XLAT b=
eing in charge of using NAT64s as PLATs."
thanks for the composing. it is = constructive. however, 

single ipv4 to ipv6 t= ranslation service is provides by any standard fitting RFC6144 framework. 4= 64xlat itself can provide this with special addressing. BIH can provide thi= s independently too. and i didn't see any effort and benefit of the &qu= ot;combination" rather than only putting them together. 

my suggestion: 

"464xlat is not designed to cover the case of= IPv4-only applications having access to IPv6-only servers, which will be p= ossibly needed in the future. Together using it with BIH [RFC6535] can be a= feasible solution, if this demand becomes true, and we leave the details o= f the co-existance to the implemantaion. By doing so, BIH continue to not b= e used together with a NAT64, as recommended in [RFC6535], while 464xlat is= being in charge of using NAT64s as PLATs."
 
if this is acceptable, i end debating soon. 

- maoke 
Could this be a way out of this endless debat= e?

Regards,
RD

--047d7b33daf47cc0ae04c91ddff2-- From despres.remi@laposte.net Fri Sep 7 08:04:54 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD41F21F84DD for ; Fri, 7 Sep 2012 08:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.079 X-Spam-Level: X-Spam-Status: No, score=-1.079 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MaSebthFsRX1 for ; Fri, 7 Sep 2012 08:04:53 -0700 (PDT) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.2]) by ietfa.amsl.com (Postfix) with ESMTP id 4596621F84DC for ; Fri, 7 Sep 2012 08:04:52 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2107.sfr.fr (SMTP Server) with ESMTP id B71CC700006D; Fri, 7 Sep 2012 17:04:51 +0200 (CEST) Received: from [192.168.0.21] (unknown [88.166.221.144]) by msfrf2107.sfr.fr (SMTP Server) with ESMTP id F0ED470000A3; Fri, 7 Sep 2012 17:04:50 +0200 (CEST) X-SFR-UUID: 20120907150450986.F0ED470000A3@msfrf2107.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-33--644104654 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Fri, 7 Sep 2012 17:04:42 +0200 Message-Id: References: To: Maoke X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 15:04:55 -0000 --Apple-Mail-33--644104654 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Le 2012-09-07 =C3=A0 16:37, Maoke a =C3=A9crit : >=20 >=20 > =E5=9C=A8 2012=E5=B9=B49=E6=9C=887=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94=EF= =BC=8CR=C3=A9mi Despr=C3=A9s =E5=86=99=E9=81=93=EF=BC=9A > Maoke, >=20 > Your scenario below is out of scope (see reasons below),=20 >=20 > what i propased is always out of scope. what you proposed is always = in. It would be nicer if you could refrain from such statements (undeserved = IMHO). > well, i said the combination is harmful technically. even if the wg = agrees the scenario is out of scope, i require a paragraph stating that:=20= >=20 > the 464xlat itself, even out of scope of the design motivation, can = also naturally support mesh communication once the private addresses are = planned and statically assigned to in-domain servers. if it is combined = with BIH, however, such a naturally enabled feature would be in trouble.=20= CLATs send ALL translated packets to PLATs, aka NAT64s, where they are = translated to IPv4 enter the IPv4 Internet, a purely hub&spoke topology = . In this context your sentence would AFAIK not add any useful = clarification, and would confuse readers. > with such a explicit explanation, i could accept what you seggest = below. otherwise i don't accept the confusion. sorry to the chair and = the authors! I hope that after thinking it over, you can release your condition to = acceptance. RD >=20 > - maoke > =20 > but it has the interesting advantage of pointing out that a correction = is needed, in the current draft, in the paragraph about BIH: BIH scope = is IPv4-only APPLICATIONS that reach IPv6-only servers, not IPv4-only = HOSTS as written.=20 >=20 > Dealing also with Lorenzo's point, this paragraph could then become: > "By combining 464XLAT with BIH [RFC6535], it is also possible to = provide single IPv4 to IPv6 translation service, which will be needed in = the future case of IPv6-only servers to be reached across IPv6-only = networks fromti IPv4-only applications in CLAT nodes. (By doing so, BIH = continue to not be used together with a NAT64, as recommended in = [RFC6535], 464XLAT being in charge of using NAT64s as PLATs.)" >=20 > Two points make your scenario off-cope: > - as reminded above, BIH is not for applications in IPv4-only hosts = (only for applications in hosts that support BIH). > - CLATs only treat outgoing connections, thus excluding CLAT-to-CLAT = scenarios. > Yet, thanks for this detailed case. It proved to be useful. >=20 > Regards, > RD > =20 >=20 > =20 > Le 2012-09-07 =C3=A0 12:54, Maoke a =C3=A9crit : >=20 >>=20 >>=20 >> 2012/9/7 R=C3=A9mi Despr=C3=A9s >>=20 >> 2012-09-07 12:03, Lorenzo Colitti : >>=20 >>> On Fri, Sep 7, 2012 at 6:42 PM, R=C3=A9mi Despr=C3=A9s = wrote: >>> BIH is the only IETF specification for an IPv4-only application in a = node attached to an IPv6-only network to reach an IPv6-only server = WITHOUT depending on any special node between the two (transparent proxy = or whatever).=20 >>>=20 >>> And yet, before the problem it solves actually becomes a problem, = things could change substantially. New, better methods can come along. = It could be obsoleted. It could change. And we'd be stuck with a BCP = that endorses something that's not relevant any more. So if you really = want to mention IPv6-only servers, I would suggest replacing the current = text with the following: >>>=20 >>> 464XLAT does not provide a means for IPv4-only applications to = communicate with IPv6-only servers. If this capability is necessary, = 464XLAT can be coupled with another transition mechanisms such as BIH = [RFC6535]. >>>=20 >>> That way it's clear that this document does not specify a best = practice for IPv4-only clients to talk to IPv6-only servers, but only = for IPv4-only apps on an IPv6-only network. >>>=20 >>> In any case, I think the following points have to be resolved before = we can make progress: >>>=20 >>> 1. The conflict between section 1, which talks about IPv6-only = servers, and section 2, which declares them out of scope, must be = resolved. >>> 2. Before we mention BIH in this document, we should ensure that at = least one implementation of 464XLAT+BIH has been tested. We don't want = to publish a BCP that suggests doing something that has never been = tested. >>=20 >> No new comment on the above. >>=20 >>> 3. If this document suggests using 464XLAT + BIH together, it needs = to say why the text in the BIH RFC which says "Use of BIH together with = a NAT64 is NOT RECOMMENDED" is not relevant to this case. >>=20 >> This is new consideration, but not a problem: >> =20 >> =20 >> actually, Remi, i have to point out it is problem. this is related to = my talk with you that the private addresses are also possibly used for a = server. >> =20 >> 0. the domain operator makes address planning with the private = address in order to avoid potential conflict; >> 1. a host having private IPv4 address are located in a LAN behind = BIH/CLAT box, with IPv6 prefixes configured with the box; =20 >> 2. it is running a server and a client peer behind another CLAT, = somehow, know the server's address (it is private but static); >> 3. the client sends out a request to the server's IPv4 address, both = src and dst are translated by the CLAT statelessly; >> 4. the CLAT of the server side decodes the IPv4-converted addresses = and delivered the translated packet to the server; >> 5. the server responds the request, while the reply arrives at the = BIH/CLAT, trouble happens: which module to proceed? if it is the CLAT, = fortunately, we are lucky, and things just worked as IVI with double = translation. if BIH takes the session, well, what would happen? i don't = think BIH is covering this case too with its synthetic IPv4 and the real = IPv6 addresses because the peer (the client) is not IPv6 now at all. BIH = state needs to be established by the initiator of the session but = combining it with CLAT makes it uncertain when the initiation bypasses = BIH at all. >> =20 >> this is a very realistic case when we want to deploy an in-domain = server group. and 464xlat itself can works well. but the combination of = 464xlat to BIH may cause some trouble. Lorenzo and me argued that the = combination was not tested. this is a real case of risk. of course, we = may patch it, but it is definitely far beyond one paragraph stating that = "combining them is useful". >> =20 >> if we have time, i may find more and more cases where the combination = introduces uncertainty. therefore i think it is safe to scope out the = problem right now. >> =20 >=20 --Apple-Mail-33--644104654 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8


=E5=9C=A8 2012=E5=B9=B49=E6=9C=887=E6=97=A5=E6=98=9F= =E6=9C=9F=E4=BA=94=EF=BC=8CR=C3=A9mi Despr=C3=A9s = =E5=86=99=E9=81=93=EF=BC=9A
Maoke,

Your scenario = below is out of scope (see reasons below), 

what i propased is = always out of scope. what you proposed is always in. =

It would be nicer if you could = refrain from such statements (undeserved IMHO).

well, i said the combination is harmful technically. = even if the wg agrees the scenario is out of scope, i require a = paragraph stating that: 

  the 464xlat itself, even out of scope of the = design motivation, can also naturally support mesh communication once = the private addresses are planned and statically assigned to in-domain = servers. if it is combined with BIH, however, such a naturally enabled = feature would be in = trouble. 

CLATs send ALL = translated packets to PLATs, aka NAT64s, where they are translated to = IPv4 enter the IPv4 Internet, a purely hub&spoke topology = .
In this context your sentence would AFAIK not add any = useful clarification, and would confuse = readers.


with such a explicit explanation, i could accept what you seggest = below. otherwise i don't accept the confusion. sorry to the chair and = the authors!

I hope that after thinking = it over, you can release your condition to = acceptance.

RD



- = maoke
 
but it has the interesting advantage = of pointing out that a correction is needed, in the current draft, in = the paragraph about BIH:  BIH scope is IPv4-only APPLICATIONS that = reach IPv6-only servers, not IPv4-only HOSTS as written. 

Dealing also with Lorenzo's point, this =  paragraph could then become:
"By combining = 464XLAT with BIH [RFC6535], it is also possible to provide single IPv4 = to IPv6 translation service, which will be needed in the future case of = IPv6-only servers to be reached across IPv6-only = networks fromti IPv4-only = applications in CLAT nodes. (By doing so, BIH continue to not be used = together with a NAT64, as recommended in [RFC6535], 464XLAT being in = charge of using NAT64s as PLATs.)"

Two points make your scenario = off-cope:
- as reminded above, BIH is not for = applications in IPv4-only hosts (only for applications in hosts that = support BIH).
- CLATs only treat outgoing connections, thus = excluding CLAT-to-CLAT scenarios.
Yet, thanks for this detailed case. It proved to be = useful.

Regards,
RD
 

 
Le 2012-09-07 =C3=A0 12:54, = Maoke a =C3=A9crit :



2012/9/7 R=C3=A9mi Despr=C3=A9s <despres.remi@laposte.net>

2012-09-07 12:03, = Lorenzo Colitti :

On Fri, Sep 7, = 2012 at 6:42 PM, R=C3=A9mi Despr=C3=A9s <despres.remi@laposte.net> wrote:
BIH is the only IETF specification = for an IPv4-only application in a node attached to an IPv6-only network = to reach an IPv6-only server WITHOUT depending on any special node = between the two (transparent proxy or whatever). 

And yet, before the problem it = solves actually becomes a problem, things could change substantially. = New, better methods can come along. It could be obsoleted. It could = change. And we'd be stuck with a BCP that endorses something that's not = relevant any more. So if you really want to mention IPv6-only servers, I = would suggest replacing the current text with the following:

464XLAT does not provide a means for IPv4-only = applications to communicate with IPv6-only servers. If this capability = is necessary, 464XLAT can be coupled with another transition mechanisms = such as BIH [RFC6535].

That way it's clear that this document does not = specify a best practice for IPv4-only clients to talk to IPv6-only = servers, but only for IPv4-only apps on an IPv6-only = network.

In any case, I think the following points have to be resolved = before we can make progress:

1. The conflict = between section 1, which talks about IPv6-only servers, and section 2, = which declares them out of scope, must be resolved.
2. Before we mention BIH in this document, we should ensure = that at least one implementation of 464XLAT+BIH has been tested. We = don't want to publish a BCP that suggests doing something that has never = been tested.

No new comment on the = above.

3. If this document suggests using 464XLAT + BIH together, it needs = to say why the text in the BIH RFC which says "Use of BIH together with = a NAT64 is NOT RECOMMENDED" is not relevant to this = case.

This is new consideration, but not a = problem:
 
 
ac= tually, Remi, i have to point out it is problem. this is related to my = talk with you that the private addresses are also possibly used for a = server.
 
0. the domain operator makes address planning with = the private address in order to avoid potential conflict; =
1. a host having private IPv4 address are = located in a LAN behind BIH/CLAT box, with IPv6 prefixes configured with = the box;   
2. it is running a server and a client peer behind = another CLAT, somehow, know the server's address (it is private but = static);
3. the client sends out a request to the = server's IPv4 address, both src and dst are translated by the CLAT = statelessly;
4. the CLAT of the server side decodes the IPv4-converted addresses = and delivered the translated packet to the server;
5. the = server responds the request, while the reply arrives at the BIH/CLAT, = trouble happens: which module to proceed? if it is the CLAT, = fortunately, we are lucky, and things just worked as IVI with double = translation. if BIH takes the session, well, what would happen? i don't = think BIH is covering this case too with its synthetic IPv4 and the real = IPv6 addresses because the peer (the client) is not IPv6 now at all. BIH = state needs to be established by the initiator of the session but = combining it with CLAT makes it uncertain when the initiation bypasses = BIH at all.
 
this is a very realistic case when we want to = deploy an in-domain server group. and 464xlat itself can works well. but = the combination of 464xlat to BIH may cause some trouble. Lorenzo and me = argued that the combination was not tested. this is a real case of risk. = of course, we may patch it, but it is definitely far beyond one = paragraph stating that "combining them is useful".
 
if we have time, i may find more and more cases = where the combination introduces uncertainty. therefore i think it is = safe to scope out the problem right now. =
 


= --Apple-Mail-33--644104654-- From despres.remi@laposte.net Fri Sep 7 08:17:45 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1D4221F8554 for ; Fri, 7 Sep 2012 08:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.691 X-Spam-Level: X-Spam-Status: No, score=-0.691 tagged_above=-999 required=5 tests=[AWL=-0.139, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XaTACHtsy7c0 for ; Fri, 7 Sep 2012 08:17:45 -0700 (PDT) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.84]) by ietfa.amsl.com (Postfix) with ESMTP id CABEB21F854E for ; Fri, 7 Sep 2012 08:17:44 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2414.sfr.fr (SMTP Server) with ESMTP id 832E17000139; Fri, 7 Sep 2012 17:17:43 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2414.sfr.fr (SMTP Server) with ESMTP id 073BB7000085; Fri, 7 Sep 2012 17:17:42 +0200 (CEST) X-SFR-UUID: 20120907151743297.073BB7000085@msfrf2414.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-34--643330510 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Fri, 7 Sep 2012 17:17:36 +0200 Message-Id: <8064A6B0-75EC-4CCD-99C9-82DCEA59F4DF@laposte.net> References: <810EAE3D-8767-4E66-911D-3DBDFE8B9403@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 15:17:46 -0000 --Apple-Mail-34--643330510 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Le 2012-09-07 =C3=A0 17:00, Maoke a =C3=A9crit : > hi Lorenzo, >=20 > =E5=9C=A8 2012=E5=B9=B49=E6=9C=887=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94=EF= =BC=8CR=C3=A9mi Despr=C3=A9s =E5=86=99=E9=81=93=EF=BC=9A >=20 > Le 2012-09-07 =C3=A0 12:36, Lorenzo Colitti a =C3=A9crit : >=20 >> On Fri, Sep 7, 2012 at 7:16 PM, R=C3=A9mi Despr=C3=A9s = wrote: >>> 3. If this document suggests using 464XLAT + BIH together, it needs = to say why the text in the BIH RFC which says "Use of BIH together with = a NAT64 is NOT RECOMMENDED" is not relevant to this case. >>=20 >> This is new consideration, but not a problem: >> - The RFC says that BIH should not send packets to NAT64s. >> - This doesn't prevent a node supporting BIH to also support 464XLAT = which, precisely is designed to send packets to PLATs, AKA NAT64s. >>=20 >> If you don't want to remove BIH, then please suggest text to address = this issue. The text that is currently in the draft does not do so, and = since it's a conflict with a standards track RFC, we have to say = something about it. >=20 > As said, I don't think there is a problem in cohabitation of 464XLAT, = by design used with NAT64, and BIH whose use with a NAT64 isn't = recommended. >=20 > Yet, if this covers your concern, and raises no objection from = authors, the last paragraph of section 1 could be completed, e.g. as = follows: > "By combining 464XLAT with BIH [RFC6535], it is also possible to = provide single IPv4 to IPv6 translation service, which will be needed in = the future case of IPv6-only servers and peers to be reached from = IPv4-only hosts across IPv6-only networks. By doing so, BIH continue to = not be used together with a NAT64, as recommended in [RFC6535], 464XLAT = being in charge of using NAT64s as PLATs." > thanks for the composing. it is constructive. however,=20 >=20 > single ipv4 to ipv6 translation service is provides by any standard = fitting RFC6144 framework. 464xlat itself can provide this with special = addressing. BIH can provide this independently too. and i didn't see any = effort and benefit of the "combination" rather than only putting them = together.=20 >=20 > my suggestion:=20 >=20 > "464xlat is not designed to cover the case of IPv4-only applications = having access to IPv6-only servers, which will be possibly needed in the = future. Together using it with BIH [RFC6535] can be a feasible solution, = if this demand becomes true, and we leave the details of the = co-existance to the implemantaion. By doing so, BIH continue to not be = used together with a NAT64, as recommended in [RFC6535], while 464xlat = is being in charge of using NAT64s as PLATs." > =20 > if this is acceptable, i end debating soon.=20 I wouldn't oppose this wording as is, but think it can be improved by = deleting "which will be possibly needed in the future" and "if this = demand becomes true". Reasons are that RFC6535 has no such caveat, and that some WG members = think this need can usefully be satisfied now. Regards, RD >=20 > - maoke=20 > Could this be a way out of this endless debate? >=20 >=20 > Regards, > RD >=20 --Apple-Mail-34--643330510 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
hi Lorenzo,

=E5=9C=A8 = 2012=E5=B9=B49=E6=9C=887=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94=EF=BC=8CR=C3=A9= mi Despr=C3=A9s =E5=86=99=E9=81=93=EF=BC=9A

Le 2012-09-07 =C3=A0 12:36, = Lorenzo Colitti a =C3=A9crit :

On Fri, Sep 7, 2012 at 7:16 PM, R=C3=A9mi = Despr=C3=A9s <despres.remi@laposte.net> wrote:
3. If this document = suggests using 464XLAT + BIH together, it needs to say why the text in = the BIH RFC which says "Use of BIH together with a NAT64 is NOT = RECOMMENDED" is not relevant to this case.

This is new consideration, but not a = problem:
- The RFC says that BIH should not send packets to = NAT64s.
- This doesn't prevent a node supporting BIH to also = support 464XLAT which, precisely is designed to send packets to PLATs, = AKA NAT64s.

If you don't want to remove BIH, = then please suggest text to address this issue. The text that is = currently in the draft does not do so, and since it's a conflict with a = standards track RFC, we have to say something about it.

As said, I don't think there is a problem in = cohabitation of 464XLAT, by design used with NAT64, and BIH whose use = with a NAT64 isn't recommended.

Yet, = if this covers your concern, and raises no objection from = authors, the last paragraph of section 1 could be completed, e.g. = as follows:
"By combining =
464XLAT with BIH [RFC6535], it is also possible to provide single IPv4 =
to IPv6 translation service, which will be needed in the future case of =
IPv6-only servers and peers to be reached from IPv4-only hosts across =
IPv6-only networks. By doing so, BIH continue to not be used together =
with a NAT64, as recommended in [RFC6535], 464XLAT being in charge of =
using NAT64s as PLATs."
thanks for the composing. it = is constructive. however, 

single ipv4 to = ipv6 translation service is provides by any standard fitting RFC6144 = framework. 464xlat itself can provide this with special addressing. BIH = can provide this independently too. and i didn't see any effort and = benefit of the "combination" rather than only putting them = together. 

my suggestion: 

"464xlat is not designed to cover = the case of IPv4-only applications having access to IPv6-only servers, = which will be possibly needed in the future. Together using it with BIH = [RFC6535] can be a feasible solution, if this demand becomes true, and = we leave the details of the co-existance to the implemantaion. By doing = so, BIH continue to not be used together with a NAT64, as recommended in = [RFC6535], while 464xlat is being in charge of using NAT64s as = PLATs."
 
if this is acceptable, i end debating = soon. 

I wouldn't = oppose this wording as is, but think it can be improved by deleting = "which will be possibly needed in the future" and "if this demand = becomes true".
Reasons are that RFC6535 has no such caveat, = and that some WG members think this need can usefully be satisfied = now.

Regards,
RD


- = maoke 
Could this be a way = out of this endless debate?

Regards,
RD


= --Apple-Mail-34--643330510-- From denghui02@gmail.com Fri Sep 7 08:27:51 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AEF521F86A7 for ; Fri, 7 Sep 2012 08:27:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.114 X-Spam-Level: X-Spam-Status: No, score=-102.114 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VNoM1F9BUHIx for ; Fri, 7 Sep 2012 08:27:49 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id BFFED21F86A5 for ; Fri, 7 Sep 2012 08:27:48 -0700 (PDT) Received: by qadz3 with SMTP id z3so2380909qad.10 for ; Fri, 07 Sep 2012 08:27:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+AE9Yx5vsei4fVDTDkHYDRYWk218M3hxrUSqw2KLsPg=; b=EOTkBdGJFB+oktByju8xd4+u2u7lw/LRYdvLUmApFYtrYH7JoGa72gyb8ITJd7BVUR vy++QBh7sXIh3H6HQ/FVmsuKE9Afb3C/tlR7Ktw/L2TSvKEOsvtjWIiCd8wSn29doukh uL8OCXRztRhx70W+7ArlqapT36EnMe1avm1B+JBboVcYc8GOUev/g52emL1vVXEup+xO p64Zlh31/msl6R2BnqpqY7cbJ742fM+m6mbrjVdxJUOPzXKepaPgxL1IkqGKIHpv5ckX hGLww54TjCt1jFam6SGfaRZz4RuMDLuvEhnvpgZYOrDBbpgyVl0rLrk8M6WLGDkY0e5t aqHw== MIME-Version: 1.0 Received: by 10.229.69.87 with SMTP id y23mr1924951qci.114.1347031667997; Fri, 07 Sep 2012 08:27:47 -0700 (PDT) Received: by 10.49.49.3 with HTTP; Fri, 7 Sep 2012 08:27:47 -0700 (PDT) In-Reply-To: References: <47F98720-3E3F-4920-A890-A5FD10843F0D@laposte.net> <36B8743C-5758-4B7F-9C31-0A4CD02D772A@laposte.net> <9F02FD3E-46C5-4BBB-ACBB-BB59DD420F24@laposte.net> Date: Fri, 7 Sep 2012 23:27:47 +0800 Message-ID: From: Hui Deng To: Cameron Byrne Content-Type: multipart/alternative; boundary=00032557b58e127a6704c91e400e Cc: v6ops WG Subject: Re: [v6ops] 464XLAT and BIH X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 15:27:51 -0000 --00032557b58e127a6704c91e400e Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Those people haven=92t been involved in contributing any text and never showing up for the disucssion about xlat464, but working on some other solution, that is not appropriate for them to jump in the last minute, we need to respect IETF. -Hui 2012/9/7 Cameron Byrne > > On Sep 7, 2012 1:41 AM, "R=E9mi Despr=E9s" wro= te: > > > > > > Le 2012-09-07 =E0 10:18, Maoke a =E9crit : > > > >> > >> > >> 2012/9/7 R=E9mi Despr=E9s > >>> > >>> > >>> Le 2012-09-07 =E0 09:41, Maoke a =E9crit : > >>> > >>>> > >>>> > >>>> 2012/9/7 R=E9mi Despr=E9s > >>>>> > >>>>> > >>>>> Le 2012-09-07 =E0 04:33, Maoke a =E9crit : > >>>>> ... > >>>>> > as we are talking about a BCP, if 464xlat doc states BIH is an > indispensible part of the standard, our customers will require us to > definitely provide such a function or such an option rather than any othe= r > alternatives in the service suite. i doubt this is the common floor the > working group is on. > >>>>> ... > >>>>> > >>>>> 1. Stating that a combining 464XLAT with BIH is "possible" isn't > stating it is "indispensable". > >>>>> > >>>>> 2. Being part of a a "BCP" isn't being part of a "standard". > >>>>> 3. Authors initially wrote "It is also possible to provide single > IPv4/IPv6 translation service, which will be needed in the future case of > IPv6-only servers and peers to be reached from legacy IPv4-only hosts." T= he > added BIH reference better covers the original intent, by just stating a > fact useful to be known. > >> > >> > >> (#) following point is emphasized > >>>> > >>>> > >>>> it is interesting. i don't think the authors were originally intent > to involve a helper for providing "single IPv4/IPv6 translation service". > and surely the phrase is correct, because CLAT supports IPv4/IPv6 single > translation without need anything more once the addressing support > statelessness; it is also happens between an IPv4 host in the Internet > having access to the native IPv6 server through the PLAT. > >>>> > >>>> adding the BIH, is actually adding another solution to the CLAT > box for another problem, heavily biased from the original intent which > contains CLAT stateless single translation service and the PLAT stateful > translation service. > > > > > > The current sentence has been coined by authors themselves. > > It is therefore, presumably, compatible with their original intent. > > > > Confirmed. > > In the best interest of making a complete bcp for the stated scope that i= s > timeless, as represented by the traffic treatment table, bih fills a hole > that makes that table symmetric and complete. Removing or adding bih does > not change the scope or motivation, the reference to bih is just a pointe= r > for future scenarios that was discussed on the list and vetted some time > back. > > Pardon me for being synical. It is my fear that we are not actually havin= g > a discussion about 464xlat but a proxy fight with a "competing" i-d. > Otherwise, i cannot understand so many last minute passionate debates ove= r > truly fringe issues. .. And calls for defining 464xlat in terms of map-t > and not any other solution. > > Once again, pardon me, i hope it is not the case. > > CB > > > I would really prefer to hear from you about 464XLAT with /64 delegated > prefixes (and no NAT44 to be completely stateless), assuming you are also > interested in _technical choices_ to be made before publication. > > > > > > RD > > > > > > > > > >>>> > >> > >> > >> (/#) end of emphasis > >>>>> > >>>>> Confirmed stand: > >>>>> - At a time when there are still discussions on functional aspects > of 464XLAT, this particular discussion is IMHO a waste of time > >>>> > >>>> > >>>> scope and problem is more important than solution. waste of time is > not an execuse of passing misleading and confused sentences. > >>> > >>> > >>> The sentence is AFAIK neither misleading nor confused. > >>> Yes, 464XLAT and BIH have complementary targets and can usefully be > combined. > >>> > >> > >> > >> AFAIK the sentence is misleading. 464 target is clearly described in > Section 2. the original intent of mentioning the IPv4/IPv6 single > translation was not a target, IMHO, but a natural result. it is fine not = to > include the original intent if we think that is out of scope. it is also > fine to include that if we think that non-normative. > >> > >> but replacing the original intent with statement on BIH actually made > things different. see my (#) that is emphasized above. > >> > >> i may change the question: what BIH can gain from being combined with > 464xlat? anything? > >> > >> - maoke > >> > >>> > >>> > >>> Just stating a preference (my right I suppose). > >>> > >>> RD > >>> > >>> > >>>> > >>>> - maoke > >>> > >>> > >> > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --00032557b58e127a6704c91e400e Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable

Those people haven’t been involved in contributing any text and never showing up for the disucssion about xlat464, but working= on some other solution, that is not appropriate for them to jump= in the last minute, we need to respect IETF.

 

-Hui



2012/9/7 Cameron Byrne <cb.lis= t6@gmail.com>


On Sep 7, 2012 1:41 AM, "R=A8=A6mi Despr=A8=A6s" <despres.remi@laposte.net<= /a>> wrote:
>
>
> Le 2012-09-07 =A8=A4 10:18, Maoke a =A8=A6crit :
>
>>
>>
>> 2012/9/7 R=A8=A6mi Despr=A8=A6s <despres.remi@laposte.net>
>>>
>>>
>>> Le 2012-09-07 =A8=A4 09:41, Maoke a =A8=A6crit :
>>>
>>>>
>>>>
>>>> 2012/9/7 R=A8=A6mi Despr=A8=A6s <despres.remi@laposte.net> >>>>>
>>>>>
>>>>> Le 2012-09-07 =A8=A4 04:33, Maoke a =A8=A6crit :
>>>>> ...
>>>>> > as we are talking about a BCP, if 464xlat doc sta= tes BIH is an indispensible part of the standard, our customers will requir= e us to definitely provide such a function or such an option rather than an= y other alternatives in the service suite. i doubt this is the common floor= the working group is on.
>>>>> ...
>>>>>
>>>>> 1. Stating that a combining 464XLAT with BIH is "= possible" isn't stating it is "indispensable". 
>>>>>
>>>>> 2. Being part of a a "BCP" isn't being p= art of a "standard".
>>>>> 3. Authors initially wrote "It is also possible t= o provide single IPv4/IPv6 translation service, which will be needed in the= future case of IPv6-only servers and peers to be reached from legacy IPv4-= only hosts." The added BIH reference better covers the original intent= , by just stating a fact useful to be known.
>>
>>  
>> (#)  following point is emphasized
>>>>
>>>>  
>>>> it is interesting. i don't think the authors=  were originally intent to involve a helper for providi= ng "single IPv4/IPv6 translation service". and surely the phrase = is correct, because CLAT supports IPv4/IPv6 single translation without need= anything more once the addressing support statelessness; it is also happen= s between an IPv4 host in the Internet having access to the native IPv6 ser= ver through the PLAT.
>>>>  
>>>> adding the BIH, is actually adding another solution t= o the CLAT box for another problem, heavily biased from the&= nbsp;original intent which contains CLAT stateless single translation servi= ce and the PLAT stateful translation service.
>
>
> The current sentence has been coined by authors themselves. 
> It is therefore, presumably, compatible with their original intent. >

Confirmed.

In the best interest of making a complete bcp for the stated scope that = is timeless, as represented by the traffic treatment table, bih fills a hol= e that makes that table symmetric and complete. Removing or adding bih does= not change the scope or motivation, the reference to bih is just a pointer= for future scenarios that was discussed on the list and vetted some time b= ack.

Pardon me for being synical. It is my fear that we are not actually havi= ng a discussion about 464xlat but a proxy fight with a "competing"= ; i-d. Otherwise, i cannot understand so many last minute passionate debate= s over truly fringe issues. .. And calls for defining 464xlat in terms of m= ap-t and not any other solution.

Once again, pardon me, i hope it is not the case.

CB

> I would really prefer to hear from = you about 464XLAT with /64 delegated prefixes (and no NAT44 to be completel= y stateless), assuming you are also interested in _technical choices_ to be= made before publication.
>
>
> RD
>
>
>
>
>>>>  
>>
>>  
>> (/#) end of emphasis 
>>>>>
>>>>> Confirmed stand:
>>>>> - At a time when there are still discussions on functi= onal aspects of 464XLAT, this particular discussion is IMHO a waste of time=
>>>>
>>>>  
>>>> scope and problem is more important than solution. waste o= f time is not an execuse of passing misleading and confused sentences.=
>>>
>>>
>>> The sentence is AFAIK neither misleading nor confused.
>>> Yes, 464XLAT and BIH have complementary targets and can useful= ly be combined.
>>>  
>>
>>  
>> AFAIK the sentence is misleading. 464 target is clearly described = in Section 2. the original intent of mentioning the IPv4/IPv6 single transl= ation was not a target, IMHO, but a natural result. it is fine not to inclu= de the original intent if we think that is out of scope. it is also fine to= include that if we think that non-normative.
>>  
>> but replacing the original intent with statement on BIH actually m= ade things different. see my (#) that is emphasized above.
>>  
>> i may change the question: what BIH can gain from being combined w= ith 464xlat? anything?
>>  
>> - maoke
>>  
>>>
>>>  
>>> Just stating a preference (my right I suppose). 
>>>
>>> RD
>>>
>>>
>>>>  
>>>> - maoke
>>>
>>>
>>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org=
> https://www.ietf.org/mailman/listinfo/v6ops
>


_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops


--00032557b58e127a6704c91e400e-- From fibrib@gmail.com Fri Sep 7 08:30:15 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F03821F85ED for ; Fri, 7 Sep 2012 08:30:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.128 X-Spam-Level: X-Spam-Status: No, score=-3.128 tagged_above=-999 required=5 tests=[AWL=0.470, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hnVnqFSH4P76 for ; Fri, 7 Sep 2012 08:30:12 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4EF7E21F846A for ; Fri, 7 Sep 2012 08:30:11 -0700 (PDT) Received: by eaai11 with SMTP id i11so1002664eaa.31 for ; Fri, 07 Sep 2012 08:30:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=axTzgvFDLjRu0qc10/HnvsesCfOMSsnbPnp0wSaJaMM=; b=hyOABwIqwP4sUPVdUW1QTQo+0UQltb/KOryn956RRzGmrVyaZxiidyy7nGuajv8LnS Cm5A6GmGEMD6VirRQKBz5pSdK1q2d0SjWzhfIABCGC4ADJ+bSx+pUOBH5PtNGDGLhnYi jKXRViexsckANAfjjMvletGUozmOKHVmLZYT3P6Y03kLK2fbTGmTDH6OblDaci4UQklx 7bhpsNx620sz7M7iwSJ6b9RCcAceSKPQbNo8cZauL8T0qhF2ADLFBbndKV/cTldVAD7M Y9qUJDyOchVxSiYoU8K8LGYvH2jSTqCU/HvPG3b3FG09iY6rctPBA6hdnfQOlI/DfESo VdvA== MIME-Version: 1.0 Received: by 10.14.218.134 with SMTP id k6mr8595688eep.14.1347031811214; Fri, 07 Sep 2012 08:30:11 -0700 (PDT) Received: by 10.14.97.9 with HTTP; Fri, 7 Sep 2012 08:30:11 -0700 (PDT) In-Reply-To: References: <47F98720-3E3F-4920-A890-A5FD10843F0D@laposte.net> <36B8743C-5758-4B7F-9C31-0A4CD02D772A@laposte.net> <9F02FD3E-46C5-4BBB-ACBB-BB59DD420F24@laposte.net> Date: Sat, 8 Sep 2012 00:30:11 +0900 Message-ID: From: Maoke To: Cameron Byrne Content-Type: multipart/alternative; boundary=047d7b6224c29bced104c91e483e Cc: v6ops WG Subject: Re: [v6ops] 464XLAT and BIH X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 15:30:15 -0000 --047d7b6224c29bced104c91e483e Content-Type: text/plain; charset=ISO-8859-1 dear Cameron, well, fringe issues...last minutes... i can "mitfuelen" but a little disappointed. as i am free, no MAP-T, no my company, no any other persons, asking me to fight in the last minutes. the timing is just because i was too busy. the one who should say pardon is me. pardon me for not proposing this issue in the earlier discussions. pardon me, especially to Remi, that i always dislike the "out of scope" but you were possibly right. but honestly speaking, i now have to choose MAP-T for my company as we have the demand of the mesh communications for in-domain servers that originally 464xlat could support. just a little pity. have a nice weekend to everyone!! - maoke P.S., i responded to Lorenzo's proposal on the modified text. now i show my respect to the authors' understanding. 2012/9/8 Cameron Byrne > Confirmed. > > In the best interest of making a complete bcp for the stated scope that is > timeless, as represented by the traffic treatment table, bih fills a hole > that makes that table symmetric and complete. Removing or adding bih does > not change the scope or motivation, the reference to bih is just a pointer > for future scenarios that was discussed on the list and vetted some time > back. > > Pardon me for being synical. It is my fear that we are not actually having > a discussion about 464xlat but a proxy fight with a "competing" i-d. > Otherwise, i cannot understand so many last minute passionate debates over > truly fringe issues. .. And calls for defining 464xlat in terms of map-t > and not any other solution. > > Once again, pardon me, i hope it is not the case. > > CB > --047d7b6224c29bced104c91e483e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
dear Cameron,

well, fringe issues...last minutes... i c= an "mitfuelen" but a little disappointed. as i am free, no MAP-T,= no my company, no any other persons, asking me to fight in the last minute= s. the timing is just because i was too busy.
=A0
the one who should say pardon is me. pardon me for not p= roposing this issue in the earlier discussions. pardon me, especially to Re= mi, that i always dislike the "out of scope" but you were possibl= y right.
=A0
but honestly speaking, i now have to choose MAP-T for my= company as we have the demand of the mesh communications for in-domain ser= vers that originally 464xlat could support. just a little pity.
=A0
have a nice weekend to everyone!!
=A0
- m= aoke
=A0
P.S., i responded to Lorenzo's proposal on= the modified text. now i show my respect to the authors' understanding= .
2012/9/8 Cameron Byrne &= lt;cb.list6@gmail.c= om>
Confirmed.

In the best interest of making a complete bcp for the stated scope that = is timeless, as represented by the traffic treatment table, bih fills a hol= e that makes that table symmetric and complete. Removing or adding bih does= not change the scope or motivation, the reference to bih is just a pointer= for future scenarios that was discussed on the list and vetted some time b= ack.

Pardon me for being synical. It is my fear that we are not actually havi= ng a discussion about 464xlat but a proxy fight with a "competing"= ; i-d. Otherwise, i cannot understand so many last minute passionate debate= s over truly fringe issues. .. And calls for defining 464xlat in terms of m= ap-t and not any other solution.

Once again, pardon me, i hope it is not the case.

CB

--047d7b6224c29bced104c91e483e-- From fibrib@gmail.com Fri Sep 7 08:32:44 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 257FE21F8622 for ; Fri, 7 Sep 2012 08:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.796 X-Spam-Level: X-Spam-Status: No, score=-1.796 tagged_above=-999 required=5 tests=[AWL=-0.948, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PVcH3A5P2pFc for ; Fri, 7 Sep 2012 08:32:43 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id DD5C321F86F9 for ; Fri, 7 Sep 2012 08:32:42 -0700 (PDT) Received: by eaai11 with SMTP id i11so1003890eaa.31 for ; Fri, 07 Sep 2012 08:32:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8UZmBqGqbawRYpktwkeJlStBlCJZhlx1RE1Nzc4Y430=; b=tEgVSqam+m++HgxFQdkA8a/uuc7fPCUwFuyqh59utU87RFt7asHHt5gtXR8WPkyrWQ zW/kEP0mek7KquaOryHlrViGPLsAAfZiWNycL7eY6cSt+6LnYNbhNDyHx51dXBHsv1cc E0YU1sYotssxuznoYdB8uDqzieboasgvq/K2ipPS9H4QUQ/sM7W8dxk1kZrIfY+pV/D1 yfbVKUEEThLhPX8Uw4dlnv8rP0U3tl8q43CpXRfVe544lNiQZs9spwfOKNQjlyw33XwE w098iIgQOYcQAq+cezYh9KaTEWBYIuFR2O4REwmNTpn27sSMzTHfao/6oHGWwT1xfOBE vvtg== MIME-Version: 1.0 Received: by 10.14.218.134 with SMTP id k6mr8616500eep.14.1347031962070; Fri, 07 Sep 2012 08:32:42 -0700 (PDT) Received: by 10.14.97.9 with HTTP; Fri, 7 Sep 2012 08:32:41 -0700 (PDT) In-Reply-To: <8064A6B0-75EC-4CCD-99C9-82DCEA59F4DF@laposte.net> References: <810EAE3D-8767-4E66-911D-3DBDFE8B9403@laposte.net> <8064A6B0-75EC-4CCD-99C9-82DCEA59F4DF@laposte.net> Date: Sat, 8 Sep 2012 00:32:41 +0900 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=047d7b6224c299af1404c91e510b Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 15:32:44 -0000 --047d7b6224c299af1404c91e510b Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable 2012/9/8 R=A8=A6mi Despr=A8=A6s > > Le 2012-09-07 =A8=A4 17:00, Maoke a =A8=A6crit : > > hi Lorenzo, > > =D4=DA 2012=C4=EA9=D4=C27=C8=D5=D0=C7=C6=DA=CE=E5=A3=ACR=A8=A6mi Despr=A8= =A6s =D0=B4=B5=C0=A3=BA > >> >> Le 2012-09-07 =A8=A4 12:36, Lorenzo Colitti a =A8=A6crit : >> >> On Fri, Sep 7, 2012 at 7:16 PM, R=A8=A6mi Despr=A8=A6s wrote: >> >>> 3. If this document suggests using 464XLAT + BIH together, it needs to >>> say why the text in the BIH RFC which says "Use of BIH together with >>> a NAT64 is NOT RECOMMENDED" is not relevant to this case. >>> >>> >>> This is new consideration, but not a problem: >>> - The RFC says that BIH should not send packets to NAT64s. >>> - This doesn't prevent a node supporting BIH to also support 464XLAT >>> which, precisely is designed to send packets to PLATs, AKA NAT64s. >>> >> >> If you don't want to remove BIH, then please suggest text to address thi= s >> issue. The text that is currently in the draft does not do so, and since >> it's a conflict with a standards track RFC, we have to say something abo= ut >> it. >> >> >> As said, I don't think there is a problem in cohabitation of 464XLAT, by >> design used with NAT64, and BIH whose use with a NAT64 isn't recommended= . >> >> Yet, if this covers your concern, and raises no objection from >> authors, the last paragraph of section 1 could be completed, e.g. as >> follows: >> >> "By combining 464XLAT with BIH [RFC6535], it is also possible to provide= single IPv4 to IPv6 translation service, which will be needed in the futur= e case of IPv6-only servers and peers to be reached from IPv4-only hosts ac= ross IPv6-only networks. By doing so, BIH continue to not be used together = with a NAT64, as recommended in [RFC6535], 464XLAT being in charge of using= NAT64s as PLATs." >> >> thanks for the composing. it is constructive. however, > > single ipv4 to ipv6 translation service is provides by any standard > fitting RFC6144 framework. 464xlat itself can provide this with special > addressing. BIH can provide this independently too. and i didn't see any > effort and benefit of the "combination" rather than only putting them > together. > > my suggestion: > > "464xlat is not designed to cover the case of IPv4-only applications > having access to IPv6-only servers, which will be possibly needed in the > future. Together using it with BIH [RFC6535] can be a feasible solution, = if > this demand becomes true, and we leave the details of the co-existance to > the implemantaion. By doing so, BIH continue to not be used together with= a > NAT64, as recommended in [RFC6535], while 464xlat is being in charge of > using NAT64s as PLATs." > > if this is acceptable, i end debating soon. > > > I wouldn't oppose this wording as is, but think it can be improved by > deleting "which will be possibly needed in the future" and "if this deman= d > becomes true". > Reasons are that RFC6535 has no such caveat, and that some WG members > think this need can usefully be satisfied now. > > acceptable. i appreciate your kindness. - maoke > Regards, > RD > > > > - maoke > >> Could this be a way out of this endless debate? >> >> Regards, >> RD >> >> > --047d7b6224c299af1404c91e510b Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
 
2012/9/8 = R=A8=A6mi Despr=A8=A6s <despres.remi@laposte.net>
=

Le 2012-09-07 =A8=A4 17:0= 0, Maoke a =A8=A6crit :

hi Lorenzo,

=D4=DA 2012=C4=EA9=D4=C27=C8=D5=D0=C7=C6=DA=CE= =E5=A3=ACR=A8=A6mi Despr=A8=A6s =D0=B4=B5=C0=A3=BA

Le 2012-09-07 =A8=A4 12:3= 6, Lorenzo Colitti a =A8=A6crit :

On Fri, Sep 7, 2012 at 7:16 PM, R=A8=A6mi Des= pr=A8=A6s <despres.remi@laposte.net> = wrote:
3. If this document suggests using 464XLAT + B= IH together, it needs to say why the text in the BIH RFC which says "U= se of BIH together with a NAT64 is NOT RECOMMENDED" is not releva= nt to this case.

This is new consideration, but not a prob= lem:
- The RFC says that BIH should not send packets to NAT64s.
- This doesn't prevent a node supporting BIH to also support 4= 64XLAT which, precisely is designed to send packets to PLATs, AKA NAT64s.

If you don't want to remove BIH,= then please suggest text to address this issue. The text that is currently= in the draft does not do so, and since it's a conflict with a standard= s track RFC, we have to say something about it.

As said, I don't think there is a problem i= n cohabitation of 464XLAT, by design used with NAT64, and BIH whose use wit= h a NAT64 isn't recommended.

Yet, if this= covers your concern, and raises no objection from authors, the last p= aragraph of section 1 could be completed, e.g. as follows:
"By combining 464XLAT with BIH [RFC6535], it is a=
lso possible to provide single IPv4 to IPv6 translation service, which will=
 be needed in the future case of IPv6-only servers and peers to be reached =
from IPv4-only hosts across IPv6-only networks. By doing so, BIH continue t=
o not be used together with a NAT64, as recommended in [RFC6535], 464XLAT b=
eing in charge of using NAT64s as PLATs."
thanks for the composing. it is = constructive. however, 

single ipv4 to ipv6 t= ranslation service is provides by any standard fitting RFC6144 framework. 4= 64xlat itself can provide this with special addressing. BIH can provide thi= s independently too. and i didn't see any effort and benefit of the &qu= ot;combination" rather than only putting them together. 

my suggestion: 

"46= 4xlat is not designed to cover the case of IPv4-only applications having ac= cess to IPv6-only servers, which will be possibly needed in the future. Tog= ether using it with BIH [RFC6535] can be a feasible solution, if this deman= d becomes true, and we leave the details of the co-existance to the implema= ntaion. By doing so, BIH continue to not be used together with a NAT64, as = recommended in [RFC6535], while 464xlat is being in charge of using NAT64s = as PLATs."
 
if this is acceptable, i end debating soon. 

I wouldn't oppose this = wording as is, but think it can be improved by deleting "which will be= possibly needed in the future" and "if this demand becomes true&= quot;.
Reasons are that RFC6535 has no such caveat, and that some WG members = think this need can usefully be satisfied now.
 
=
 
acceptable. i appreciate your= kindness. - maoke 
 
=
Regards,
RD



- maoke 
Could this be a way out of this endless debat= e?

Regards,
RD



--047d7b6224c299af1404c91e510b-- From despres.remi@laposte.net Fri Sep 7 08:34:32 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70D2321F8722 for ; Fri, 7 Sep 2012 08:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.455 X-Spam-Level: X-Spam-Status: No, score=-0.455 tagged_above=-999 required=5 tests=[AWL=-0.366, BAYES_20=-0.74, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VMfiLNnHHen6 for ; Fri, 7 Sep 2012 08:34:32 -0700 (PDT) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.20]) by ietfa.amsl.com (Postfix) with ESMTP id B100821F8717 for ; Fri, 7 Sep 2012 08:34:31 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2308.sfr.fr (SMTP Server) with ESMTP id E3BB170002B5; Fri, 7 Sep 2012 17:34:30 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2308.sfr.fr (SMTP Server) with ESMTP id 6D5B17000072; Fri, 7 Sep 2012 17:34:30 +0200 (CEST) X-SFR-UUID: 20120907153430448.6D5B17000072@msfrf2308.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-35--642317194 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Fri, 7 Sep 2012 17:34:30 +0200 Message-Id: <9A67DF4B-5019-45C8-A43C-A804CC8CE3FD@laposte.net> References: <810EAE3D-8767-4E66-911D-3DBDFE8B9403@laposte.net> <8064A6B0-75EC-4CCD-99C9-82DCEA59F4DF @laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 15:34:32 -0000 --Apple-Mail-35--642317194 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-09-07 =E0 17:32, Maoke a =E9crit : ... >> ... >> my suggestion:=20 >>=20 >> "464xlat is not designed to cover the case of IPv4-only applications = having access to IPv6-only servers, which will be possibly needed in the = future. Together using it with BIH [RFC6535] can be a feasible solution, = if this demand becomes true, and we leave the details of the = co-existance to the implemantaion. By doing so, BIH continue to not be = used together with a NAT64, as recommended in [RFC6535], while 464xlat = is being in charge of using NAT64s as PLATs." >> =20 >> if this is acceptable, i end debating soon.=20 >=20 > I wouldn't oppose this wording as is, but think it can be improved by = deleting "which will be possibly needed in the future" and "if this = demand becomes true". > Reasons are that RFC6535 has no such caveat, and that some WG members = think this need can usefully be satisfied now. > =20 > =20 > acceptable. i appreciate your kindness. - maoke=20 I see this as a breakthrough. Hope authors can agree. Have a nice WE. RD= --Apple-Mail-35--642317194 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
...
my = suggestion: 

"464xlat is not designed to = cover the case of IPv4-only applications having access to IPv6-only = servers, which will be possibly needed in the future. Together using it = with BIH [RFC6535] can be a feasible solution, if this demand becomes = true, and we leave the details of the co-existance to the implemantaion. = By doing so, BIH continue to not be used together with a NAT64, as = recommended in [RFC6535], while 464xlat is being in charge of using = NAT64s as PLATs."
 
if this is acceptable, i end debating = soon. 

I = wouldn't oppose this wording as is, but think it can be improved by = deleting "which will be possibly needed in the future" and "if this = demand becomes true".
Reasons are that RFC6535 has no such caveat, and that some WG = members think this need can usefully be satisfied = now.
 
 
= acceptable. i appreciate your kindness. - = maoke 

I see this as a = breakthrough.
Hope authors can = agree.

Have a nice = WE.
RD
= --Apple-Mail-35--642317194-- From fibrib@gmail.com Fri Sep 7 08:41:29 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 590CD21F8568 for ; Fri, 7 Sep 2012 08:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.65 X-Spam-Level: X-Spam-Status: No, score=-2.65 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aL8kLq9nreC0 for ; Fri, 7 Sep 2012 08:41:28 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4625221F855A for ; Fri, 7 Sep 2012 08:41:28 -0700 (PDT) Received: by eaai11 with SMTP id i11so1007674eaa.31 for ; Fri, 07 Sep 2012 08:41:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZatZpaM7JlgRoovww+RC9DzwyD+UneJnsVwVq2QPOlo=; b=CEJrfKw5zLdi0y+2ta+Nm8vmyS30KnrXVcJgmtG+dS9xA3xIYF2G5SnYzA2VyRL+ZO ya1/RKuZSrqSA5b/jExkUMUZxJUzg6qP/O0ZbBj/1vC4Y/hzLJlzo56hvKOBY/xv6x1i 3903UrOoPZ06op0htjOXQJhagPULilQ45p8zDMpJ8ubUIKmVQXytl2Pm2hJPrZBn+6jV 6cZ2Xr+yAO9U29XatQBAPLZWOy5JbdKrebIZ33highNYyZrvhG/REv+myXfEWTSuOPoG WAiaVi1BgmVVS3vkoWACVSSPXytgq75bknkzRfkWcp++hlJa1k850wV7ftAtsPmaMYme 0iRA== MIME-Version: 1.0 Received: by 10.14.202.71 with SMTP id c47mr8657272eeo.42.1347032487421; Fri, 07 Sep 2012 08:41:27 -0700 (PDT) Received: by 10.14.97.9 with HTTP; Fri, 7 Sep 2012 08:41:27 -0700 (PDT) In-Reply-To: References: <47F98720-3E3F-4920-A890-A5FD10843F0D@laposte.net> <36B8743C-5758-4B7F-9C31-0A4CD02D772A@laposte.net> <9F02FD3E-46C5-4BBB-ACBB-BB59DD420F24@laposte.net> Date: Sat, 8 Sep 2012 00:41:27 +0900 Message-ID: From: Maoke To: Hui Deng Content-Type: multipart/alternative; boundary=047d7b343e38e9e8f204c91e7067 Cc: v6ops WG Subject: Re: [v6ops] 464XLAT and BIH X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 15:41:29 -0000 --047d7b343e38e9e8f204c91e7067 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hui, 2012/9/8 Hui Deng > Those people haven=92t been involved in contributing any text and never > showing up for the disucssion about xlat464, but working on some other > solution, that is not appropriate for them to jump in the last minute, we > need to respect IETF. > > > > -Hui > > i really won't like to debate with you on this childish statement, especially i am friend of you for more than 10 years. :) just execuse me for participating late. - maoke --047d7b343e38e9e8f204c91e7067 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
Hui,
2012/9/8 Hui Deng <dengh= ui02@gmail.com>

Those people haven’t been involved in contributing any text and never showing up for the disucssion about xlat464, but working= on some other solution, that is not appropriate for them to jump= in the last minute, we need to respect IETF.

 

-Hui

&= nbsp;
 
i really won't like= to debate with you on this childish statement, especially i am friend of y= ou for more than 10 years. :) just execuse me for participating late. =
 
- maoke   
--047d7b343e38e9e8f204c91e7067-- From fibrib@gmail.com Fri Sep 7 08:43:26 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC8C321F86BE for ; Fri, 7 Sep 2012 08:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.975 X-Spam-Level: X-Spam-Status: No, score=-2.975 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dnXxaqISNqdU for ; Fri, 7 Sep 2012 08:43:25 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0E5EE21F86B1 for ; Fri, 7 Sep 2012 08:43:21 -0700 (PDT) Received: by eekb45 with SMTP id b45so1326773eek.31 for ; Fri, 07 Sep 2012 08:43:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rdTZUo+3iGRxTQONfsUMEYU+6ofT/FVfVcMswoqD97o=; b=myreTVSCMWRPGk+fl8HsSW58m9Do8rz6WJ8Or0gf9HjYPR0GFwKHz3OM/fXoHrfAu9 wyLbri4jkU5c2zFuUyByjf/4GvQpqWpxB6FLEhvwXAMIo/u/Acs+US5A6zGleLFoe1cl q9DkghoAPmT5AxuFrlAZsk6O5ihJNBDHf74hzYXVsoOoCJ9KsLtV0/D4WD6Q5cc3GbTK jPKbxUfqbfNi5q+Y2cBzCkWj3tSG50t41ElrsnAp1j9yDR8SmCRyoRDVDjMIWcwX6RhT 5w0xVtrBzyAJnqmwfib0isLEb5DmCvklw1cTtkmBYhq4adS/kV9lNKT0q7RjZkYvxPv2 5Ohg== MIME-Version: 1.0 Received: by 10.14.172.129 with SMTP id t1mr8672937eel.34.1347032601267; Fri, 07 Sep 2012 08:43:21 -0700 (PDT) Received: by 10.14.97.9 with HTTP; Fri, 7 Sep 2012 08:43:21 -0700 (PDT) In-Reply-To: <9A67DF4B-5019-45C8-A43C-A804CC8CE3FD@laposte.net> References: <810EAE3D-8767-4E66-911D-3DBDFE8B9403@laposte.net> <9A67DF4B-5019-45C8-A43C-A804CC8CE3FD@laposte.net> Date: Sat, 8 Sep 2012 00:43:21 +0900 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=047d7b603c12b30f3b04c91e774b Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 15:43:26 -0000 --047d7b603c12b30f3b04c91e774b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/9/8 R=E9mi Despr=E9s > > Le 2012-09-07 =E0 17:32, Maoke a =E9crit : > ... > > ... >> my suggestion: >> >> "464xlat is not designed to cover the case of IPv4-only applications >> having access to IPv6-only servers, which will be possibly needed in the >> future. Together using it with BIH [RFC6535] can be a feasible solution,= if >> this demand becomes true, and we leave the details of the co-existance t= o >> the implemantaion. By doing so, BIH continue to not be used together wit= h a >> NAT64, as recommended in [RFC6535], while 464xlat is being in charge of >> using NAT64s as PLATs." >> >> if this is acceptable, i end debating soon. >> >> >> I wouldn't oppose this wording as is, but think it can be improved by >> deleting "which will be possibly needed in the future" and "if this dema= nd >> becomes true". >> Reasons are that RFC6535 has no such caveat, and that some WG members >> think this need can usefully be satisfied now. >> >> > > acceptable. i appreciate your kindness. - maoke > > > I see this as a breakthrough. > Hope authors can agree. > > Have a nice WE. > > same to you. and please accept my sorry for the impolite wording before (i know me but i sometimes less controlled) and sorry for the late participation in the discussion. - maoke > > RD > --047d7b603c12b30f3b04c91e774b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/9/8 R=E9mi Despr=E9s <despr= es.remi@laposte.net>

Le 2012-09-07 =E0 17:32, = Maoke a =E9crit :
...

...
my suggestion:=A0
"464xlat is not designed to cover the case of IPv4-only a= pplications having access to IPv6-only servers, which will be possibly need= ed in the future. Together using it with BIH [RFC6535] can be a feasible so= lution, if this demand becomes true, and we leave the details of the co-exi= stance to the implemantaion. By doing so, BIH continue to not be used toget= her with a NAT64, as recommended in [RFC6535], while 464xlat is being in ch= arge of using NAT64s as PLATs."
=A0
if this is acceptable, i end debating soon.=A0

I wouldn&= #39;t oppose this wording as is, but think it can be improved by deleting &= quot;which will be possibly needed in the future" and "if this de= mand becomes true".
Reasons are that RFC6535 has no such caveat, and that some WG members = think this need can usefully be satisfied now.
=A0
=A0
acceptable. i=A0= appreciate your kindness. - maoke=A0

I see this as a breakthrough.<= /div>
Hope authors can agree.

Have a nice WE.<= /div>
=A0
=A0
same to you.= and please accept my sorry for the impolite wording before (i know me but = i sometimes less controlled) and sorry for the late participation in the di= scussion. - maoke
=A0
=A0
RD
<= /div>

--047d7b603c12b30f3b04c91e774b-- From despres.remi@laposte.net Fri Sep 7 08:46:58 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 427DD21F8717 for ; Fri, 7 Sep 2012 08:46:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.371 X-Spam-Level: X-Spam-Status: No, score=-1.371 tagged_above=-999 required=5 tests=[AWL=0.577, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hd01G8YQFTJp for ; Fri, 7 Sep 2012 08:46:57 -0700 (PDT) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.20]) by ietfa.amsl.com (Postfix) with ESMTP id 4A7B921F86B1 for ; Fri, 7 Sep 2012 08:46:57 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2308.sfr.fr (SMTP Server) with ESMTP id A89A270000A6; Fri, 7 Sep 2012 17:46:56 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2308.sfr.fr (SMTP Server) with ESMTP id 5253A700009F; Fri, 7 Sep 2012 17:46:56 +0200 (CEST) X-SFR-UUID: 20120907154656338.5253A700009F@msfrf2308.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-37--641571228 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Fri, 7 Sep 2012 17:46:56 +0200 Message-Id: References: <810EAE3D-8767-4E66-911D-3DBDFE8B9403@laposte.net> <9A67DF4B-5019-45C8-A43C-A804CC8CE3FD@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 15:46:58 -0000 --Apple-Mail-37--641571228 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-09-07 =E0 17:43, Maoke a =E9crit : >=20 >=20 > 2012/9/8 R=E9mi Despr=E9s >=20 > Le 2012-09-07 =E0 17:32, Maoke a =E9crit : > ... >=20 >>> ... >>> my suggestion:=20 >>>=20 >>> "464xlat is not designed to cover the case of IPv4-only applications = having access to IPv6-only servers, which will be possibly needed in the = future. Together using it with BIH [RFC6535] can be a feasible solution, = if this demand becomes true, and we leave the details of the = co-existance to the implemantaion. By doing so, BIH continue to not be = used together with a NAT64, as recommended in [RFC6535], while 464xlat = is being in charge of using NAT64s as PLATs." >>> =20 >>> if this is acceptable, i end debating soon.=20 >>=20 >> I wouldn't oppose this wording as is, but think it can be improved by = deleting "which will be possibly needed in the future" and "if this = demand becomes true". >> Reasons are that RFC6535 has no such caveat, and that some WG members = think this need can usefully be satisfied now. >> =20 >> =20 >> acceptable. i appreciate your kindness. - maoke=20 >=20 > I see this as a breakthrough. > Hope authors can agree. >=20 > Have a nice WE. > =20 > =20 > same to you. and please accept my sorry for the impolite wording = before (i know me but i sometimes less controlled) and sorry for the = late participation in the discussion. - maoke No problem between us.=20 As usual, something useful can be achieved at the end. RD =20 > =20 > =20 > RD >=20 --Apple-Mail-37--641571228 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1


2012/9/8 R=E9mi Despr=E9s <despres.remi@laposte.net>

Le 2012-09-07 =E0 = 17:32, Maoke a =E9crit :
...

...
my = suggestion: 

"464xlat is not designed to = cover the case of IPv4-only applications having access to IPv6-only = servers, which will be possibly needed in the future. Together using it = with BIH [RFC6535] can be a feasible solution, if this demand becomes = true, and we leave the details of the co-existance to the implemantaion. = By doing so, BIH continue to not be used together with a NAT64, as = recommended in [RFC6535], while 464xlat is being in charge of using = NAT64s as PLATs."
 
if this is acceptable, i end debating = soon. 

I wouldn't oppose this wording as is, but think it can = be improved by deleting "which will be possibly needed in the future" = and "if this demand becomes true".
Reasons are that RFC6535 has no such caveat, and that some WG = members think this need can usefully be satisfied = now.
 
 
acceptable. i appreciate your = kindness. - maoke 

I see this as a = breakthrough.
Hope authors can = agree.

Have a nice = WE.
 
 
s= ame to you. and please accept my sorry for the impolite wording before = (i know me but i sometimes less controlled) and sorry for the late = participation in the discussion. - = maoke

No problem between = us. 
As usual, something useful can be achieved at the = end.
RD
 
 
 
RD


= --Apple-Mail-37--641571228-- From cb.list6@gmail.com Fri Sep 7 08:47:33 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65D7521E805A for ; Fri, 7 Sep 2012 08:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.17 X-Spam-Level: X-Spam-Status: No, score=-3.17 tagged_above=-999 required=5 tests=[AWL=0.429, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id arNsj5-cXWDK for ; Fri, 7 Sep 2012 08:47:32 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 934C821E8039 for ; Fri, 7 Sep 2012 08:47:32 -0700 (PDT) Received: by lahm15 with SMTP id m15so2136892lah.31 for ; Fri, 07 Sep 2012 08:47:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9UKqf6e/UyG4QF7bdHy6OczqdlGJcknU2DYPDQH6PHA=; b=k/npEdx2v9l6na6SvjoBqj7y9PUa9GX4Qyx7kqCO8gq8j7y1E83/yqRy5MbPOzP1M4 xqYbuNJjNsMl7qCjeTSBDMBbDdcmtI2UNl9IvZiLfOEy0TVk68GE26iP2xFV5tBIlDpa wNKDk5bWWAaoUHuKGQIZ+3EdI9S13hWbTBSlmSTBdqziE2TInbHsKbVI/6yk+34z8DzP 0UYb+2Ex3unHV/XjpfbmpD74J2Ta8Lyn3Qqb/ztVEVvvxcuBxkFB9wheaZ+VBNpQ3soE ExkOc+pYyyCt8JuXAjOFR2dtn2HTUe6iP5Mk3rbeJYjqkESO7FnmHOAuQZzPl/Xnaz9w vERw== MIME-Version: 1.0 Received: by 10.112.83.170 with SMTP id r10mr2319937lby.103.1347032851502; Fri, 07 Sep 2012 08:47:31 -0700 (PDT) Received: by 10.112.49.66 with HTTP; Fri, 7 Sep 2012 08:47:31 -0700 (PDT) In-Reply-To: References: <47F98720-3E3F-4920-A890-A5FD10843F0D@laposte.net> <36B8743C-5758-4B7F-9C31-0A4CD02D772A@laposte.net> <9F02FD3E-46C5-4BBB-ACBB-BB59DD420F24@laposte.net> Date: Fri, 7 Sep 2012 08:47:31 -0700 Message-ID: From: Cameron Byrne To: Maoke Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops WG Subject: Re: [v6ops] 464XLAT and BIH X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 15:47:33 -0000 On Fri, Sep 7, 2012 at 8:30 AM, Maoke wrote: > dear Cameron, > > well, fringe issues...last minutes... i can "mitfuelen" but a little > disappointed. as i am free, no MAP-T, no my company, no any other persons, > asking me to fight in the last minutes. the timing is just because i was too > busy. > I do appreciate feedback at any time, it makes us all stronger, thanks again for taking the time to review and even more for suggesting text. Text is always the best since it makes the desired outcomes clearest. > the one who should say pardon is me. pardon me for not proposing this issue > in the earlier discussions. pardon me, especially to Remi, that i always > dislike the "out of scope" but you were possibly right. > > but honestly speaking, i now have to choose MAP-T for my company as we have > the demand of the mesh communications for in-domain servers that originally > 464xlat could support. just a little pity. > Yes, there must be many solutions. If we had all moved to IPv6 10 years ago .... maybe this would be easier :) > have a nice weekend to everyone!! > > - maoke > > P.S., i responded to Lorenzo's proposal on the modified text. now i show my > respect to the authors' understanding. > 2012/9/8 Cameron Byrne >> >> Confirmed. >> >> In the best interest of making a complete bcp for the stated scope that is >> timeless, as represented by the traffic treatment table, bih fills a hole >> that makes that table symmetric and complete. Removing or adding bih does >> not change the scope or motivation, the reference to bih is just a pointer >> for future scenarios that was discussed on the list and vetted some time >> back. >> >> Pardon me for being synical. It is my fear that we are not actually having >> a discussion about 464xlat but a proxy fight with a "competing" i-d. >> Otherwise, i cannot understand so many last minute passionate debates over >> truly fringe issues. .. And calls for defining 464xlat in terms of map-t and >> not any other solution. >> >> Once again, pardon me, i hope it is not the case. >> >> CB From despres.remi@laposte.net Fri Sep 7 08:56:10 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9769721F86A5 for ; Fri, 7 Sep 2012 08:56:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.091 X-Spam-Level: X-Spam-Status: No, score=-1.091 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T7zpSxwIiE5Y for ; Fri, 7 Sep 2012 08:56:09 -0700 (PDT) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.20]) by ietfa.amsl.com (Postfix) with ESMTP id 2EC7121F8670 for ; Fri, 7 Sep 2012 08:56:08 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2308.sfr.fr (SMTP Server) with ESMTP id 3AEBF70000F3; Fri, 7 Sep 2012 17:56:08 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2308.sfr.fr (SMTP Server) with ESMTP id F211B700006C; Fri, 7 Sep 2012 17:56:07 +0200 (CEST) X-SFR-UUID: 20120907155607991.F211B700006C@msfrf2308.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?= X-Priority: 3 In-Reply-To: <041e01cd8ce7$61aeebc0$4001a8c0@gateway.2wire.net> Date: Fri, 7 Sep 2012 17:56:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <504392E0.8070802@bogus.com><448050D4-84F9-4F52-BF7E-347EA451A96C@laposte.net> <041e01cd8ce7$61aeebc0$4001a8c0@gateway.2wire.net> To: t.petch X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] 464XLAT - support of /64 delegated prefixes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 15:56:10 -0000 Hi, Tom,=20 Thanks for the clarification about IANA vocabulary (I hadn't checked = www.iana.org/assignments/ethernet-numbers/ethernet-numbers.xml#ethernet-nu= mbers-4). With the IANA-related FUD eliminated, and with the common wish to = support /64 delegated prefixes, do you agree that, with the reserved = ranges below, 464XLAT can be implemented: - without interfering with the approach chosen for tethering and /64 - completely statelessly (no NAT44 needed). If not, requests for clarification are welcome. =20 Regards, RD=20 Le 2012-09-07 =E0 12:55, t.petch a =E9crit : > ----- Original Message ----- > From: "Lorenzo Colitti" > To: "R=E9mi Despr=E9s" > Cc: "v6ops WG" > Sent: Thursday, September 06, 2012 8:48 AM > On Thu, Sep 6, 2012 at 4:20 PM, R=E9mi Despr=E9s > wrote: >=20 >> Let's assume IANA has reserved for CLATs the following subranges of > the >> range available for allocation in RFC5342 section 2.2.2: >> 02-00-5E-10-0A-xx-xx-xx for CLATs using 10../8 >> 02-00-5E-10-AC-1x-xx-xx for CLATs using 172.16../12 >> 02-00-5E-10-C0-A8-xx-xx for CLATs using 192.168../16 >>=20 >=20 > Since assuming the impossible leads to failure, we first need to = ensure > that: >=20 > 1. IANA has the authority to assign such address space. > 2. IANA is willing to assign such address space > 3. IANA has the techical capability (e.g., processes) to assign such > address space. ... > so no problem with IANA. >=20 > As at the time of this message, the indicated addresses are available. > IANA calls them Ethernet numbers rather than OUI. >=20 > Tom Petch >=20 >=20 From wdec.ietf@gmail.com Fri Sep 7 09:14:29 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5461221F8713 for ; Fri, 7 Sep 2012 09:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.42 X-Spam-Level: X-Spam-Status: No, score=-2.42 tagged_above=-999 required=5 tests=[AWL=0.578, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OdoJEMm+hVuP for ; Fri, 7 Sep 2012 09:14:28 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9F0D921F855E for ; Fri, 7 Sep 2012 09:14:27 -0700 (PDT) Received: by eaai11 with SMTP id i11so1022405eaa.31 for ; Fri, 07 Sep 2012 09:14:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BkKtmriEd7xBXkulpXyu0S8u5tPpCoK0u/nL1zZVCX0=; b=O8u/owbkniqxJTYSwNpu7oV0uUxBOUTIBpLIl9oCYyUhNd/+0xvjT9jvefd9Yxsz9h +zLyUzDfs0RIfuOtGuf/pf8XDzMyNQ81+0/t35UOELL5ExW3Ns0uQYfgXaGF+oBADblL 230hwSDjM3Ej9JHbS/RcUp+GFSYCqun9vdVR47pUJmZblH5HxUnpEynuvXpc2lOAE8tv HMzLnRKl/ubdAg/f9u2Lqk4HCB1rGe1VvoQGSOysAxu8etV5w2dbqjkFdgF/VPTXMbZD QiGSPe3MBtBDt9odCTXKpYX0p5uhiezyJ6aw6IvgxqI++ArZtfMLFj/0I89z7APgF7Cb 9Bxg== MIME-Version: 1.0 Received: by 10.14.205.6 with SMTP id i6mr8868254eeo.13.1347034466775; Fri, 07 Sep 2012 09:14:26 -0700 (PDT) Received: by 10.14.45.68 with HTTP; Fri, 7 Sep 2012 09:14:26 -0700 (PDT) In-Reply-To: References: <47F98720-3E3F-4920-A890-A5FD10843F0D@laposte.net> <36B8743C-5758-4B7F-9C31-0A4CD02D772A@laposte.net> <9F02FD3E-46C5-4BBB-ACBB-BB59DD420F24@laposte.net> Date: Fri, 7 Sep 2012 18:14:26 +0200 Message-ID: From: Wojciech Dec To: Cameron Byrne Content-Type: multipart/alternative; boundary=047d7b343b8ae472b204c91ee646 Cc: v6ops WG Subject: Re: [v6ops] 464XLAT and BIH X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 16:14:29 -0000 --047d7b343b8ae472b204c91ee646 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 7 September 2012 17:00, Cameron Byrne wrote: > > On Sep 7, 2012 1:41 AM, "R=E9mi Despr=E9s" wro= te: > > > > > > Le 2012-09-07 =E0 10:18, Maoke a =E9crit : > > > >> > >> > >> 2012/9/7 R=E9mi Despr=E9s > >>> > >>> > >>> Le 2012-09-07 =E0 09:41, Maoke a =E9crit : > >>> > >>>> > >>>> > >>>> 2012/9/7 R=E9mi Despr=E9s > >>>>> > >>>>> > >>>>> Le 2012-09-07 =E0 04:33, Maoke a =E9crit : > >>>>> ... > >>>>> > as we are talking about a BCP, if 464xlat doc states BIH is an > indispensible part of the standard, our customers will require us to > definitely provide such a function or such an option rather than any othe= r > alternatives in the service suite. i doubt this is the common floor the > working group is on. > >>>>> ... > >>>>> > >>>>> 1. Stating that a combining 464XLAT with BIH is "possible" isn't > stating it is "indispensable". > >>>>> > >>>>> 2. Being part of a a "BCP" isn't being part of a "standard". > >>>>> 3. Authors initially wrote "It is also possible to provide single > IPv4/IPv6 translation service, which will be needed in the future case of > IPv6-only servers and peers to be reached from legacy IPv4-only hosts." T= he > added BIH reference better covers the original intent, by just stating a > fact useful to be known. > >> > >> > >> (#) following point is emphasized > >>>> > >>>> > >>>> it is interesting. i don't think the authors were originally intent > to involve a helper for providing "single IPv4/IPv6 translation service". > and surely the phrase is correct, because CLAT supports IPv4/IPv6 single > translation without need anything more once the addressing support > statelessness; it is also happens between an IPv4 host in the Internet > having access to the native IPv6 server through the PLAT. > >>>> > >>>> adding the BIH, is actually adding another solution to the CLAT > box for another problem, heavily biased from the original intent which > contains CLAT stateless single translation service and the PLAT stateful > translation service. > > > > > > The current sentence has been coined by authors themselves. > > It is therefore, presumably, compatible with their original intent. > > > > Confirmed. > > In the best interest of making a complete bcp for the stated scope that i= s > timeless, as represented by the traffic treatment table, bih fills a hole > that makes that table symmetric and complete. Removing or adding bih does > not change the scope or motivation, the reference to bih is just a pointe= r > for future scenarios that was discussed on the list and vetted some time > back. > > Pardon me for being synical. It is my fear that we are not actually havin= g > a discussion about 464xlat but a proxy fight with a "competing" i-d. > Otherwise, i cannot understand so many last minute passionate debates ove= r > truly fringe issues. .. And calls for defining 464xlat in terms of map-t > and not any other solution. > You'll likely find that the discussion is about the WG last call, which often prompts people to actually read drafts. Now, this thread specifically appears to be about BIH which does not appear to be a core component of xlat, but an add-on. No problem if someone wants to use BIH, but it is as someone said before effectively as "putting a toaster on a fridge" (or perhaps inside it). In terms of the relationship to other work, perhaps it would be good to put to rest the fact that there is the notion of a NAT464 architecture that is not unique to xlat, and describe in the draft what the xlat solution uniquely delivers in that. As per text suggested elsewhere, xlat appears to have some unique points. Cheers, Woj. > Once again, pardon me, i hope it is not the case. > > CB > > > I would really prefer to hear from you about 464XLAT with /64 delegated > prefixes (and no NAT44 to be completely stateless), assuming you are also > interested in _technical choices_ to be made before publication. > > > > > > RD > > > > > > > > > >>>> > >> > >> > >> (/#) end of emphasis > >>>>> > >>>>> Confirmed stand: > >>>>> - At a time when there are still discussions on functional aspects > of 464XLAT, this particular discussion is IMHO a waste of time > >>>> > >>>> > >>>> scope and problem is more important than solution. waste of time is > not an execuse of passing misleading and confused sentences. > >>> > >>> > >>> The sentence is AFAIK neither misleading nor confused. > >>> Yes, 464XLAT and BIH have complementary targets and can usefully be > combined. > >>> > >> > >> > >> AFAIK the sentence is misleading. 464 target is clearly described in > Section 2. the original intent of mentioning the IPv4/IPv6 single > translation was not a target, IMHO, but a natural result. it is fine not = to > include the original intent if we think that is out of scope. it is also > fine to include that if we think that non-normative. > >> > >> but replacing the original intent with statement on BIH actually made > things different. see my (#) that is emphasized above. > >> > >> i may change the question: what BIH can gain from being combined with > 464xlat? anything? > >> > >> - maoke > >> > >>> > >>> > >>> Just stating a preference (my right I suppose). > >>> > >>> RD > >>> > >>> > >>>> > >>>> - maoke > >>> > >>> > >> > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --047d7b343b8ae472b204c91ee646 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 7 September 2012 17:00, Cameron Byrne= <cb.list6@gmail.com> wrote:


On Sep 7, 2012 1:41 AM, "R=E9mi Despr=E9s" <despres.remi@laposte.net>= ; wrote:
>
>
> Le 2012-09-07 =E0 10:18, Maoke a =E9crit :
>
>>
>>
>> 2012/9/7 R=E9mi Despr=E9s <despres.remi@laposte.net>
>>>
>>>
>>> Le 2012-09-07 =E0 09:41, Maoke a =E9crit :
>>>
>>>>
>>>>
>>>> 2012/9/7 R=E9mi Despr=E9s <despres.remi@laposte.net>
>>>>>
>>>>>
>>>>> Le 2012-09-07 =E0 04:33, Maoke a =E9crit :
>>>>> ...
>>>>> > as we are talking about a BCP, if 464xlat doc sta= tes BIH is an indispensible part of the standard, our customers will requir= e us to definitely provide such a function or such an option rather than an= y other alternatives in the service suite. i doubt this is the common floor= the working group is on.
>>>>> ...
>>>>>
>>>>> 1. Stating that a combining 464XLAT with BIH is "= possible" isn't stating it is "indispensable".=A0
>>>>>
>>>>> 2. Being part of a a "BCP" isn't being p= art of a "standard".
>>>>> 3. Authors initially wrote "It is also possible t= o provide single IPv4/IPv6 translation service, which will be needed in the= future case of IPv6-only servers and peers to be reached from legacy IPv4-= only hosts." The added BIH reference better covers the original intent= , by just stating a fact useful to be known.
>>
>> =A0
>> (#) =A0following point is emphasized
>>>>
>>>> =A0
>>>> it is=A0interesting.=A0i don't think the authors=A0wer= e originally intent to involve=A0a helper=A0for=A0providing "single IP= v4/IPv6 translation service". and surely the phrase is correct, becaus= e CLAT supports IPv4/IPv6 single translation without need anything more onc= e the addressing support statelessness; it is also happens between an IPv4 = host in the Internet having access to the native IPv6 server through the PL= AT.
>>>> =A0
>>>> adding the BIH, is actually adding another solution=A0to t= he CLAT box=A0for another problem,=A0heavily biased=A0from the=A0original i= ntent which contains CLAT stateless single translation service and the PLAT= stateful translation service.
>
>
> The current sentence has been coined by authors themselves.=A0
> It is therefore, presumably, compatible with their original intent. >

Confirmed.

In the best interest of making a complete bcp for the stated scope that = is timeless, as represented by the traffic treatment table, bih fills a hol= e that makes that table symmetric and complete. Removing or adding bih does= not change the scope or motivation, the reference to bih is just a pointer= for future scenarios that was discussed on the list and vetted some time b= ack.

Pardon me for being synical. It is my fear that we are not actually havi= ng a discussion about 464xlat but a proxy fight with a "competing"= ; i-d. Otherwise, i cannot understand so many last minute passionate debate= s over truly fringe issues. .. And calls for defining 464xlat in terms of m= ap-t and not any other solution.

You'll likely find that the discussion is about the W= G last call, which often prompts people to actually read drafts.
Now,=A0= this thread specifically appears to be about BIH which does not appear to = be a core component of xlat, but an add-on. No problem if someone wants to = use BIH, but it is as someone said before effectively as "putting a to= aster on a fridge" (or perhaps inside it).
In terms of the relationship to other work, perhaps it would be good to put= to rest the fact that there is the notion of a NAT464 architecture that is= not unique to xlat, and describe in the draft what the xlat solution uniqu= ely delivers in that. As per text suggested elsewhere, xlat appears to have= some unique points.

Cheers,
Woj.

Once again, pardon me, i hope it is not the case.

CB

> I would really prefer to hear from you about = 464XLAT with /64 delegated prefixes (and no NAT44 to be completely stateles= s), assuming you are also interested in _technical choices_ to be made befo= re publication.
>
>
> RD
>
>
>
>
>>>> =A0
>>
>> =A0
>> (/#) end of emphasis=A0
>>>>>
>>>>> Confirmed stand:
>>>>> - At a time when there are still discussions on functi= onal aspects of 464XLAT, this particular discussion is IMHO a waste of time=
>>>>
>>>> =A0
>>>> scope and problem is more important than solution. waste o= f time is not an execuse of passing misleading and confused=A0sentences. >>>
>>>
>>> The sentence is AFAIK neither misleading nor confused.
>>> Yes, 464XLAT and BIH have complementary targets and can useful= ly be combined.
>>> =A0
>>
>> =A0
>> AFAIK the sentence is misleading. 464 target is clearly described = in Section 2. the original intent of mentioning the IPv4/IPv6 single transl= ation was not a target, IMHO, but a natural result. it is fine not to inclu= de the original intent if we think that is out of scope. it is also fine to= include that if we think that non-normative.
>> =A0
>> but replacing the original intent with statement on BIH actually m= ade things different. see my (#) that is emphasized=A0above.
>> =A0
>> i may change the question: what BIH can gain from being combined w= ith 464xlat? anything?
>> =A0
>> - maoke
>> =A0
>>>
>>> =A0
>>> Just stating a preference (my right I suppose).=A0
>>>
>>> RD
>>>
>>>
>>>> =A0
>>>> - maoke
>>>
>>>
>>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org=
> https://www.ietf.org/mailman/listinfo/v6ops
>


_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops


--047d7b343b8ae472b204c91ee646-- From wdec.ietf@gmail.com Fri Sep 7 09:25:17 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE9421E8043 for ; Fri, 7 Sep 2012 09:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.115 X-Spam-Level: X-Spam-Status: No, score=-2.115 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iKCAkZFyBlqq for ; Fri, 7 Sep 2012 09:25:16 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5C64621E8034 for ; Fri, 7 Sep 2012 09:25:16 -0700 (PDT) Received: by eaai11 with SMTP id i11so1027089eaa.31 for ; Fri, 07 Sep 2012 09:25:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CnO1IRyT4sH5w6WBP/FQBqsY0ABGc6TeauOJrygSuxE=; b=enUm1LBnqbLMRB3EHB6IbPd2qV5U5PXfEpx3s3sLiPQehwdtO9HFehGwscNgM2c3Mn aCWDVYv+B9OjtTMj/+RfiChvPeZcDvvc5FoDoEvcoOAfPuILh1ZlsFes5Wk8kU9usGr0 BAN0z8rnQFibj0oWqmQsFtim/0hSztEeeK6amDzFEuXFvMnoBO64vHXmzAr2VimOt6AO 51Ntz7OuE1iO2eSmdRAmkbGaPFvCQHEumePzgr//pOt+wsrGAJk+iFuMvtdyRfPjQ2wj lMs7jw0WgF1tjHADCSE8MPEM/gOSYUqhFu7n4aWKsh6CNcVcCKgyAa1QqCwiAsSbwq+1 94mg== MIME-Version: 1.0 Received: by 10.14.205.6 with SMTP id i6mr8943424eeo.13.1347035114010; Fri, 07 Sep 2012 09:25:14 -0700 (PDT) Received: by 10.14.45.68 with HTTP; Fri, 7 Sep 2012 09:25:13 -0700 (PDT) In-Reply-To: References: <504392E0.8070802@bogus.com> <448050D4-84F9-4F52-BF7E-347EA451A96C@laposte.net> <041e01cd8ce7$61aeebc0$4001a8c0@gateway.2wire.net> Date: Fri, 7 Sep 2012 18:25:13 +0200 Message-ID: From: Wojciech Dec To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=047d7b343b8a78774304c91f0d7f Cc: v6ops WG Subject: Re: [v6ops] 464XLAT - support of /64 delegated prefixes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 16:25:17 -0000 --047d7b343b8a78774304c91f0d7f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable You may want to re-read: "must be for standards purposes (either for an IETF Standard ..." Such an assignment is a standards action item, and last I checked we were not defining a new standard here. Furthermore, the actual call for such a reservation appears not to be needed, if we get over the fact that a routed mode + pd is better at handling this case. Cheers, -Woj. On 7 September 2012 17:56, R=E9mi Despr=E9s wrot= e: > Hi, Tom, > > Thanks for the clarification about IANA vocabulary (I hadn't checked > www.iana.org/assignments/ethernet-numbers/ethernet-numbers.xml#ethernet-n= umbers-4 > ). > > With the IANA-related FUD eliminated, and with the common wish to support > /64 delegated prefixes, do you agree that, with the reserved ranges below= , > 464XLAT can be implemented: > - without interfering with the approach chosen for tethering and /64 > - completely statelessly (no NAT44 needed). > > If not, requests for clarification are welcome. > > Regards, > RD > > Le 2012-09-07 =E0 12:55, t.petch a =E9crit : > > > ----- Original Message ----- > > From: "Lorenzo Colitti" > > To: "R=E9mi Despr=E9s" > > Cc: "v6ops WG" > > Sent: Thursday, September 06, 2012 8:48 AM > > On Thu, Sep 6, 2012 at 4:20 PM, R=E9mi Despr=E9s > > wrote: > > > >> Let's assume IANA has reserved for CLATs the following subranges of > > the > >> range available for allocation in RFC5342 section 2.2.2: > >> 02-00-5E-10-0A-xx-xx-xx for CLATs using 10../8 > >> 02-00-5E-10-AC-1x-xx-xx for CLATs using 172.16../12 > >> 02-00-5E-10-C0-A8-xx-xx for CLATs using 192.168../16 > >> > > > > Since assuming the impossible leads to failure, we first need to ensure > > that: > > > > 1. IANA has the authority to assign such address space. > > 2. IANA is willing to assign such address space > > 3. IANA has the techical capability (e.g., processes) to assign such > > address space. > ... > > so no problem with IANA. > > > > As at the time of this message, the indicated addresses are available. > > IANA calls them Ethernet numbers rather than OUI. > > > > Tom Petch > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --047d7b343b8a78774304c91f0d7f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable You may want to re-read:

"must be for standards purposes (eithe= r for an IETF Standard ..."

Such an assignment is a standards a= ction item, and last I checked we were not defining a new standard here. Furthermore, the actual call for such a reservation appears not to be neede= d, if we get over the fact that a routed mode + pd is better at handling th= is case.

Cheers,
-Woj.

On 7 Sep= tember 2012 17:56, R=E9mi Despr=E9s <despres.remi@laposte.net&g= t; wrote:
Hi, Tom,

Thanks for the clarification about IANA vocabulary (I hadn't checked www.iana.org/assignments/ethernet= -numbers/ethernet-numbers.xml#ethernet-numbers-4).

With the IANA-related FUD eliminated, and with the common wish to support /= 64 delegated prefixes, do you agree that, with the reserved ranges below, 4= 64XLAT can be implemented:
- without interfering with the approach chosen for tethering and /64
- completely statelessly (no NAT44 needed).

If not, requests for clarification are welcome.

Regards,
RD

Le 2012-09-07 =E0 12:55, t.petch a =E9crit :

> ----- Original Message -----
> From: "Lorenzo Colitti" <lorenzo@google.com>
> To: "R=E9mi Despr=E9s" <despres.remi@laposte.net>
> Cc: "v6ops WG" <v6ops@i= etf.org>
> Sent: Thursday, September 06, 2012 8:48 AM
> On Thu, Sep 6, 2012 at 4:20 PM, R=E9mi Despr=E9s
> <despres.remi@laposte.n= et>wrote:
>
>> Let's assume IANA has reserved for CLATs the following subrang= es of
> the
>> range available for allocation in RFC5342 section 2.2.2:
>> 02-00-5E-10-0A-xx-xx-xx for CLATs using 10../8
>> 02-00-5E-10-AC-1x-xx-xx for CLATs using 172.16../12
>> 02-00-5E-10-C0-A8-xx-xx for CLATs using 192.168../16
>>
>
> Since assuming the impossible leads to failure, we first need to ensur= e
> that:
>
> =A0 1. IANA has the authority to assign such address space.
> =A0 2. IANA is willing to assign such address space
> =A0 3. IANA has the techical capability (e.g., processes) to assign su= ch
> =A0 address space.
...
> so no problem with IANA.
>
> As at the time of this message, the indicated addresses are available.=
> IANA calls them Ethernet numbers rather than OUI.
>
> Tom Petch
>
>
_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

--047d7b343b8a78774304c91f0d7f-- From despres.remi@laposte.net Fri Sep 7 10:18:41 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5200821F8623 for ; Fri, 7 Sep 2012 10:18:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yMduIwlPvGib for ; Fri, 7 Sep 2012 10:18:40 -0700 (PDT) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.2]) by ietfa.amsl.com (Postfix) with ESMTP id BE97F21F8620 for ; Fri, 7 Sep 2012 10:18:32 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2106.sfr.fr (SMTP Server) with ESMTP id C7F8570000AF; Fri, 7 Sep 2012 19:18:31 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2106.sfr.fr (SMTP Server) with ESMTP id 572C070000BA; Fri, 7 Sep 2012 19:18:31 +0200 (CEST) X-SFR-UUID: 20120907171831357.572C070000BA@msfrf2106.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-38--636076256 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Fri, 7 Sep 2012 19:18:31 +0200 Message-Id: <2808F812-B159-4F99-A7A1-C6B159EABBA0@laposte.net> References: <504392E0.8070802@bogus.com> <448050D4-84F9-4F52-BF7E-347EA451A96C@laposte.net> <041e01cd8ce7$61aeebc0$4001a8c0@gateway.2wire.net> To: Wojciech Dec X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] 464XLAT - support of /64 delegated prefixes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 17:18:41 -0000 --Apple-Mail-38--636076256 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 2012-09-07 18:25, Wojciech Dec : > You may want to re-read: >=20 > "must be for standards purposes (either for an IETF Standard ..." >=20 > Such an assignment is a standards action item, and last I checked we = were not defining a new standard here. !!! Let's hope its isn't on purpose, to support an unjustified argument, = that you truncated the quoted sentence of RFC5342.=20 The full sentence is: "must be for standards purposes (either for an IETF Standard or other = standard related to IETF work)". A BCP isn't a standard, agreed, but publishing a BCP does qualify for = being part of "other standard related to IETF work".=20 > Furthermore, the actual call for such a reservation appears not to be = needed, if we get over the fact that a routed mode + pd is better at = handling this case. As said, if the three IID ranges below are reserved, 464XLAT can be = added to nodes that support tethering with /64s without interfering with = the chosen approach for this support. This is IMHO good enough a motivation to just reserve three subranges in = a range "available for allocation" in RFC 5342. This is in my understanding what we are discussing right now. RD =20 >=20 > Cheers, > -Woj. >=20 > On 7 September 2012 17:56, R=E9mi Despr=E9s = wrote: > Hi, Tom, >=20 > Thanks for the clarification about IANA vocabulary (I hadn't checked = www.iana.org/assignments/ethernet-numbers/ethernet-numbers.xml#ethernet-nu= mbers-4). >=20 > With the IANA-related FUD eliminated, and with the common wish to = support /64 delegated prefixes, do you agree that, with the reserved = ranges below, 464XLAT can be implemented: > - without interfering with the approach chosen for tethering and /64 > - completely statelessly (no NAT44 needed). >=20 > If not, requests for clarification are welcome. >=20 > Regards, > RD >=20 > Le 2012-09-07 =E0 12:55, t.petch a =E9crit : >=20 > > ----- Original Message ----- > > From: "Lorenzo Colitti" > > To: "R=E9mi Despr=E9s" > > Cc: "v6ops WG" > > Sent: Thursday, September 06, 2012 8:48 AM > > On Thu, Sep 6, 2012 at 4:20 PM, R=E9mi Despr=E9s > > wrote: > > > >> Let's assume IANA has reserved for CLATs the following subranges of > > the > >> range available for allocation in RFC5342 section 2.2.2: > >> 02-00-5E-10-0A-xx-xx-xx for CLATs using 10../8 > >> 02-00-5E-10-AC-1x-xx-xx for CLATs using 172.16../12 > >> 02-00-5E-10-C0-A8-xx-xx for CLATs using 192.168../16 > >> > > > > Since assuming the impossible leads to failure, we first need to = ensure > > that: > > > > 1. IANA has the authority to assign such address space. > > 2. IANA is willing to assign such address space > > 3. IANA has the techical capability (e.g., processes) to assign = such > > address space. > ... > > so no problem with IANA. > > > > As at the time of this message, the indicated addresses are = available. > > IANA calls them Ethernet numbers rather than OUI. > > > > Tom Petch > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --Apple-Mail-38--636076256 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
You may = want to re-read:

"must be for standards purposes (either for an = IETF Standard ..."

Such an assignment is a standards action item, = and last I checked we were not defining a new standard = here.

!!!
Let's hope its = isn't on purpose, to support an unjustified argument, that you truncated = the quoted sentence of RFC5342. 
The full sentence = is:
"must be for standards purposes (either for an IETF = Standard or other standard related to IETF = work)".
A BCP isn't a standard, agreed, but = publishing a BCP does qualify for being part of "other standard = related to IETF work".

Furthermore, the actual call for such a reservation = appears not to be needed, if we get over the fact that a routed mode + = pd is better at handling this = case.

As said, if the three = IID ranges below are reserved, 464XLAT can be added to nodes that = support tethering with /64s without interfering with the chosen approach = for this support.
This is IMHO good enough a motivation to = just reserve three subranges in a range "available for allocation" in = RFC 5342.

This is in my understanding what we = are discussing right = now.


RD

<= br>

 

Cheers,
-Woj.

On = 7 September 2012 17:56, R=E9mi Despr=E9s <despres.remi@laposte.net> wrote:
Hi, Tom,

Thanks for the clarification about IANA vocabulary (I hadn't checked www.iana.org/assignments/ethernet-numbers/ethernet-numbe= rs.xml#ethernet-numbers-4).

With the IANA-related FUD eliminated, and with the common wish to = support /64 delegated prefixes, do you agree that, with the reserved = ranges below, 464XLAT can be implemented:
- without interfering with the approach chosen for tethering and /64
- completely statelessly (no NAT44 needed).

If not, requests for clarification are welcome.

Regards,
RD

Le 2012-09-07 =E0 12:55, t.petch a =E9crit :

> ----- Original Message -----
> From: "Lorenzo Colitti" <lorenzo@google.com>
> To: "R=E9mi Despr=E9s" <despres.remi@laposte.net><= br> > Cc: "v6ops WG" <v6ops@ietf.org>
> Sent: Thursday, September 06, 2012 8:48 AM
> On Thu, Sep 6, 2012 at 4:20 PM, R=E9mi Despr=E9s
> <despres.remi@laposte.net>w= rote:
>
>> Let's assume IANA has reserved for CLATs the following = subranges of
> the
>> range available for allocation in RFC5342 section 2.2.2:
>> 02-00-5E-10-0A-xx-xx-xx for CLATs using 10../8
>> 02-00-5E-10-AC-1x-xx-xx for CLATs using 172.16../12
>> 02-00-5E-10-C0-A8-xx-xx for CLATs using 192.168../16
>>
>
> Since assuming the impossible leads to failure, we first need to = ensure
> that:
>
>   1. IANA has the authority to assign such address space.
>   2. IANA is willing to assign such address space
>   3. IANA has the techical capability (e.g., processes) to = assign such
>   address space.
...
> so no problem with = IANA.
>
> As at the time of this message, the indicated addresses are = available.
> IANA calls them Ethernet numbers rather than OUI.
>
> Tom Petch
>
>
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops


= --Apple-Mail-38--636076256-- From wdec.ietf@gmail.com Fri Sep 7 10:47:46 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F3F621E805F for ; Fri, 7 Sep 2012 10:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.361 X-Spam-Level: X-Spam-Status: No, score=-2.361 tagged_above=-999 required=5 tests=[AWL=-0.862, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_62=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dRMVPJ56bZJf for ; Fri, 7 Sep 2012 10:47:45 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id EA5BA21E804C for ; Fri, 7 Sep 2012 10:47:44 -0700 (PDT) Received: by eekb45 with SMTP id b45so1411776eek.31 for ; Fri, 07 Sep 2012 10:47:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eiT9AuiaRQTsBHU4y9mOoklPb8txg5Xg8LiPlRERYmc=; b=h93Tovr62uuDF52VyH4HZTjHPNa1+DFxqWtD7DEvw2LEh7p/Nx3oEgdTkGZH+kHdQM m5phF36TbobsjxdNG+Z9n7MHdObE9OEanc0k+C+7l41WH/HwOXC2kJSP5yF4UgCKi/rc bBYwf9AB0Eu+B0uuRjdLF95p+4Elm3s445g/I6eakEZPAk9UzhPO7rT3BQ7rLcZHK/H/ YeyQQxa9PdCJRBuZoKYYewN/FDtXIpbEdZl8+9imCOgTt1OPZVeSewBM5q8ahJqf8Qpt L9lfOpifekrmsOfLIlhnMP4+hzrQ9creGeQuTuAx1UhGaPz3pyjwR9kBsx7jCY6JSndG mprA== MIME-Version: 1.0 Received: by 10.14.224.73 with SMTP id w49mr9305063eep.37.1347040063928; Fri, 07 Sep 2012 10:47:43 -0700 (PDT) Received: by 10.14.45.68 with HTTP; Fri, 7 Sep 2012 10:47:43 -0700 (PDT) In-Reply-To: <2808F812-B159-4F99-A7A1-C6B159EABBA0@laposte.net> References: <504392E0.8070802@bogus.com> <448050D4-84F9-4F52-BF7E-347EA451A96C@laposte.net> <041e01cd8ce7$61aeebc0$4001a8c0@gateway.2wire.net> <2808F812-B159-4F99-A7A1-C6B159EABBA0@laposte.net> Date: Fri, 7 Sep 2012 19:47:43 +0200 Message-ID: From: Wojciech Dec To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=047d7b66fbc182388004c92034df Cc: v6ops WG Subject: Re: [v6ops] 464XLAT - support of /64 delegated prefixes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 17:47:46 -0000 --047d7b66fbc182388004c92034df Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 7 September 2012 19:18, R=E9mi Despr=E9s wrot= e: > > 2012-09-07 18:25, Wojciech Dec : > > You may want to re-read: > > "must be for standards purposes (either for an IETF Standard ..." > > Such an assignment is a standards action item, and last I checked we were > not defining a new standard here. > > > !!! > Let's hope its isn't on purpose, to support an unjustified argument, that > you truncated the quoted sentence of RFC5342. > The full sentence is: > "must be for standards purposes (either for an IETF Standard or other > standard related to IETF work)". > A BCP isn't a standard, agreed, but publishing a BCP does qualify for > being part of "other standard related to IETF work". > "... other standard related to IETF work", means, to me at least: standard work done outside of the IETF, but related to IETF standards, which would not appear to apply here. > > Furthermore, the actual call for such a reservation appears not to be > needed, if we get over the fact that a routed mode + pd is better at > handling this case. > > > As said, if the three IID ranges below are reserved, 464XLAT can be added > to nodes that support tethering with /64s without interfering with the > chosen approach for this support. > This is IMHO good enough a motivation to just reserve three subranges in = a > range "available for allocation" in RFC 5342. > Well, it still has "holes". You will get conflicts among devices even if you reserve a range. The only save way is to stop doing this and assign a unique /64 for each device, which the routed+pd mode of operation would accomplish. Given that it is to be supported anyway, it seems like a far better way than the seeking IANA allocations, etc. Cheers, Woj. > > This is in my understanding what we are discussing right now. > > > RD > > > > > > > Cheers, > -Woj. > > On 7 September 2012 17:56, R=E9mi Despr=E9s wr= ote: > >> Hi, Tom, >> >> Thanks for the clarification about IANA vocabulary (I hadn't checked >> www.iana.org/assignments/ethernet-numbers/ethernet-numbers.xml#ethernet-= numbers-4 >> ). >> >> With the IANA-related FUD eliminated, and with the common wish to suppor= t >> /64 delegated prefixes, do you agree that, with the reserved ranges belo= w, >> 464XLAT can be implemented: >> - without interfering with the approach chosen for tethering and /64 >> - completely statelessly (no NAT44 needed). >> >> If not, requests for clarification are welcome. >> >> Regards, >> RD >> >> Le 2012-09-07 =E0 12:55, t.petch a =E9crit : >> >> > ----- Original Message ----- >> > From: "Lorenzo Colitti" >> > To: "R=E9mi Despr=E9s" >> > Cc: "v6ops WG" >> > Sent: Thursday, September 06, 2012 8:48 AM >> > On Thu, Sep 6, 2012 at 4:20 PM, R=E9mi Despr=E9s >> > wrote: >> > >> >> Let's assume IANA has reserved for CLATs the following subranges of >> > the >> >> range available for allocation in RFC5342 section 2.2.2: >> >> 02-00-5E-10-0A-xx-xx-xx for CLATs using 10../8 >> >> 02-00-5E-10-AC-1x-xx-xx for CLATs using 172.16../12 >> >> 02-00-5E-10-C0-A8-xx-xx for CLATs using 192.168../16 >> >> >> > >> > Since assuming the impossible leads to failure, we first need to ensur= e >> > that: >> > >> > 1. IANA has the authority to assign such address space. >> > 2. IANA is willing to assign such address space >> > 3. IANA has the techical capability (e.g., processes) to assign such >> > address space. >> ... >> > so no problem with IANA. >> > >> > As at the time of this message, the indicated addresses are available. >> > IANA calls them Ethernet numbers rather than OUI. >> > >> > Tom Petch >> > >> > >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > > > --047d7b66fbc182388004c92034df Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 7 September 2012 19:18, R=E9mi Despr= =E9s <despres.remi@laposte.net> wrote:

2012-09-07 18:25, Wojciec= h Dec :

You may want t= o re-read:

"must be for standards purposes (either for an IETF = Standard ..."

Such an assignment is a standards action item, and last I checked we we= re not defining a new standard here.

<= div>!!!
Let's hope its isn't on purpose, to support an un= justified argument, that you truncated the quoted sentence of RFC5342.=A0
The full sentence is:
<= font face=3D"monospace">"= must be for standards purposes (either for an IETF Standard or other standa= rd related to IETF work)".
A BCP isn't a standard, agree= d, but publishing a BCP does qualify for being part of "other standard related to IETF work".

"... other standard related to IETF = work", means, to me at least: standard work done outside of the IETF, = but related to IETF standards, which would not appear to apply here.

Furthermore, = the actual call for such a reservation appears not to be needed, if we get = over the fact that a routed mode + pd is better at handling this case.

As said, if the three IID rang= es below are reserved, 464XLAT can be added to nodes that support tethering= with /64s without interfering with the chosen approach for this support.
This is IMHO good enough a motivation to just reserve three subranges = in a range "available for allocation" in RFC 5342.

Well, it still has "holes". You will get confl= icts among devices even if you reserve a range. The only save way is to sto= p doing this and assign a unique /64 for each device, which the routed+pd m= ode of operation would accomplish. Given that it is to be supported anyway,= it seems like a far better way than the seeking IANA allocations, etc.

Cheers,
Woj.

This is in my understanding what w= e are discussing right now.


RD


=A0

Chee= rs,
-Woj.

On 7 September 2012 17:56, R=E9mi D= espr=E9s <despres.remi@laposte.net> wrote:
Hi, Tom,

Thanks for the clarification about IANA vocabulary (I hadn't checked www.iana.org/assignments/ethernet= -numbers/ethernet-numbers.xml#ethernet-numbers-4).

With the IANA-related FUD eliminated, and with the common wish to support /= 64 delegated prefixes, do you agree that, with the reserved ranges below, 4= 64XLAT can be implemented:
- without interfering with the approach chosen for tethering and /64
- completely statelessly (no NAT44 needed).

If not, requests for clarification are welcome.

Regards,
RD

Le 2012-09-07 =E0 12:55, t.petch a =E9crit :

> ----- Original Message -----
> From: "Lorenzo Colitti" <lorenzo@google.com>
> To: "R=E9mi Despr=E9s" <despres.remi@laposte.net>
> Cc: "v6ops WG" <v6ops@ietf.org>
> Sent: Thursday, September 06, 2012 8:48 AM
> On Thu, Sep 6, 2012 at 4:20 PM, R=E9mi Despr=E9s
> <desp= res.remi@laposte.net>wrote:
>
>> Let's assume IANA has reserved for CLATs the following subrang= es of
> the
>> range available for allocation in RFC5342 section 2.2.2:
>> 02-00-5E-10-0A-xx-xx-xx for CLATs using 10../8
>> 02-00-5E-10-AC-1x-xx-xx for CLATs using 172.16../12
>> 02-00-5E-10-C0-A8-xx-xx for CLATs using 192.168../16
>>
>
> Since assuming the impossible leads to failure, we first need to ensur= e
> that:
>
> =A0 1. IANA has the authority to assign such address space.
> =A0 2. IANA is willing to assign such address space
> =A0 3. IANA has the techical capability (e.g., processes) to assign su= ch
> =A0 address space.
...
> so no problem with IANA.
>
> As at the time of this message, the indicated addresses are available.=
> IANA calls them Ethernet numbers rather than OUI.
>
> Tom Petch
>
>
_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops



--047d7b66fbc182388004c92034df-- From ietfc@btconnect.com Fri Sep 7 10:53:04 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31ACC21F8587 for ; Fri, 7 Sep 2012 10:53:04 -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.533, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wvCRfe9H4DI5 for ; Fri, 7 Sep 2012 10:53:03 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe006.messaging.microsoft.com [213.199.154.209]) by ietfa.amsl.com (Postfix) with ESMTP id EB1FE21F8581 for ; Fri, 7 Sep 2012 10:53:02 -0700 (PDT) Received: from mail97-am1-R.bigfish.com (10.3.201.246) by AM1EHSOBE006.bigfish.com (10.3.204.26) with Microsoft SMTP Server id 14.1.225.23; Fri, 7 Sep 2012 17:53:01 +0000 Received: from mail97-am1 (localhost [127.0.0.1]) by mail97-am1-R.bigfish.com (Postfix) with ESMTP id 8D822380135; Fri, 7 Sep 2012 17:53:01 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.253.197; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0710HT004.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -27 X-BigFish: PS-27(zz98dI9371Ic89bh936eI542M1432I1418I1447Izz1202hzz8275ch1033IL8275bh8275dhz2dh2a8h5a9h668h839hd24hf0ah107ah1177h1179h1288h304l1155h) Received: from mail97-am1 (localhost.localdomain [127.0.0.1]) by mail97-am1 (MessageSwitch) id 1347040380172077_14751; Fri, 7 Sep 2012 17:53:00 +0000 (UTC) Received: from AM1EHSMHS005.bigfish.com (unknown [10.3.201.228]) by mail97-am1.bigfish.com (Postfix) with ESMTP id 283C23A0113; Fri, 7 Sep 2012 17:53:00 +0000 (UTC) Received: from DBXPRD0710HT004.eurprd07.prod.outlook.com (157.56.253.197) by AM1EHSMHS005.bigfish.com (10.3.207.105) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 7 Sep 2012 17:52:55 +0000 Received: from AMXPRD0610HT002.eurprd06.prod.outlook.com (157.56.248.213) by pod51017.outlook.com (10.255.79.167) with Microsoft SMTP Server (TLS) id 14.16.190.9; Fri, 7 Sep 2012 17:52:55 +0000 Message-ID: <001501cd8d21$b62c34c0$4001a8c0@gateway.2wire.net> From: t.petch To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= , Wojciech Dec References: <504392E0.8070802@bogus.com> <448050D4-84F9-4F52-BF7E-347EA451A96C@laposte.net> <041e01cd8ce7$61aeebc0$4001a8c0@gateway.2wire.net> <2808F812-B159-4F99-A7A1-C6B159EABBA0@laposte.net> Date: Fri, 7 Sep 2012 18:53:30 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.248.213] Content-Transfer-Encoding: quoted-printable X-OriginatorOrg: btconnect.com Cc: v6ops WG Subject: Re: [v6ops] 464XLAT - support of /64 delegated prefixes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 17:53:04 -0000 ----- Original Message ----- From: "R=E9mi Despr=E9s" To: "Wojciech Dec" Cc: "t.petch" ; "v6ops WG" Sent: Friday, September 07, 2012 6:18 PM 2012-09-07 18:25, Wojciech Dec : > You may want to re-read: > > "must be for standards purposes (either for an IETF Standard ..." > > Such an assignment is a standards action item, and last I checked we were not defining a new standard here. !!! Let's hope its isn't on purpose, to support an unjustified argument, that you truncated the quoted sentence of RFC5342. The full sentence is: "must be for standards purposes (either for an IETF Standard or other standard related to IETF work)". A BCP isn't a standard, agreed, but publishing a BCP does qualify for being part of "other standard related to IETF work". I think that that qualification is fine; the standing of a BCP does get called into question at times - does it count as a standard even though it is not technically on the standards track - but I have not known it stop an allocation from a registry defined as this one is. Go back to the bible of IANA actions, RFC5226, and the magic phrase is 'Standards Action' - that is what calls for a standards track RFC, nothing else does. And that phrase is absent from RFC5342 (guess what it is? yes, a BCP) > Furthermore, the actual call for such a reservation appears not to be needed, if we get over the fact that a routed mode + pd is better at handling this case. As said, if the three IID ranges below are reserved, 464XLAT can be added to nodes that support tethering with /64s without interfering with the chosen approach for this support. This is IMHO good enough a motivation to just reserve three subranges in a range "available for allocation" in RFC 5342. This is in my understanding what we are discussing right now. I can see no reason why this is not a good idea that will work well. I express it thus cautiously because I have had one or two surprises along the way with this work, not so much in the 'wired' environment as in the 'weird' environment (as it sometimes seems to me:-). So I think we wait to see if anyone can see an engineering defect therein. Tom Petch RD > > Cheers, > -Woj. > > On 7 September 2012 17:56, R=E9mi Despr=E9s wrote: > Hi, Tom, > > Thanks for the clarification about IANA vocabulary (I hadn't checked www.iana.org/assignments/ethernet-numbers/ethernet-numbers.xml#ethernet- numbers-4). > > With the IANA-related FUD eliminated, and with the common wish to support /64 delegated prefixes, do you agree that, with the reserved ranges below, 464XLAT can be implemented: > - without interfering with the approach chosen for tethering and /64 > - completely statelessly (no NAT44 needed). > > If not, requests for clarification are welcome. > > Regards, > RD > > Le 2012-09-07 =E0 12:55, t.petch a =E9crit : > > > ----- Original Message ----- > > From: "Lorenzo Colitti" > > To: "R=E9mi Despr=E9s" > > Cc: "v6ops WG" > > Sent: Thursday, September 06, 2012 8:48 AM > > On Thu, Sep 6, 2012 at 4:20 PM, R=E9mi Despr=E9s > > wrote: > > > >> Let's assume IANA has reserved for CLATs the following subranges of > > the > >> range available for allocation in RFC5342 section 2.2.2: > >> 02-00-5E-10-0A-xx-xx-xx for CLATs using 10../8 > >> 02-00-5E-10-AC-1x-xx-xx for CLATs using 172.16../12 > >> 02-00-5E-10-C0-A8-xx-xx for CLATs using 192.168../16 > >> > > > > Since assuming the impossible leads to failure, we first need to ensure > > that: > > > > 1. IANA has the authority to assign such address space. > > 2. IANA is willing to assign such address space > > 3. IANA has the techical capability (e.g., processes) to assign such > > address space. > ... > > so no problem with IANA. > > > > As at the time of this message, the indicated addresses are available. > > IANA calls them Ethernet numbers rather than OUI. > > > > Tom Petch > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From cb.list6@gmail.com Fri Sep 7 11:11:54 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E450A21E80AC for ; Fri, 7 Sep 2012 11:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.324 X-Spam-Level: X-Spam-Status: No, score=-2.324 tagged_above=-999 required=5 tests=[AWL=-0.525, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4aXNGldNRpoj for ; Fri, 7 Sep 2012 11:11:48 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 113A021E80B4 for ; Fri, 7 Sep 2012 11:11:47 -0700 (PDT) Received: by lbky2 with SMTP id y2so15734lbk.31 for ; Fri, 07 Sep 2012 11:11:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=5TVqiYjxIt6ZvSmEjYJ/ZShAGUAf3nJiebb9xVfy9Fg=; b=fgdBeuPDwVxFzkfitsGERssIM/jFDm7hgMj2u3QuqsP5O7tbczP+nuDc+8+y8X11SB CkJyww+9KdClAgCQWVhRN7Vj3Rtmxd23paPiy//2dzVqPtRAeecA4PmE8zQhe3l143vR IUlob8bJ5ENFC2e9Mt5MmmBJIBW9er2+8FupX7C1n/dqEZ3gkmE/IeW+jpxdHfkFm94n Jpb2ta89GSybg3WdVvXiqJAPEa/HLR7VKxNbAO+SGkWUDwbDa/mac+nst3n4jAVqJO6J sSNUobz8qX+FV3/2wjweD90xPYNx84RYNTX3kqhX9bafurf77p3OEAukBk8+PwDEOtm4 FJWA== MIME-Version: 1.0 Received: by 10.152.132.133 with SMTP id ou5mr6054920lab.45.1347041506860; Fri, 07 Sep 2012 11:11:46 -0700 (PDT) Received: by 10.112.49.66 with HTTP; Fri, 7 Sep 2012 11:11:46 -0700 (PDT) In-Reply-To: References: <504392E0.8070802@bogus.com> <448050D4-84F9-4F52-BF7E-347EA451A96C@laposte.net> <041e01cd8ce7$61aeebc0$4001a8c0@gateway.2wire.net> <2808F812-B159-4F99-A7A1-C6B159EABBA0@laposte.net> Date: Fri, 7 Sep 2012 11:11:46 -0700 Message-ID: From: Cameron Byrne To: Wojciech Dec Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops WG Subject: Re: [v6ops] 464XLAT - support of /64 delegated prefixes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 18:11:55 -0000 On Fri, Sep 7, 2012 at 10:47 AM, Wojciech Dec wrote: > > > On 7 September 2012 19:18, R=E9mi Despr=E9s wr= ote: >> >> >> 2012-09-07 18:25, Wojciech Dec : >> >> You may want to re-read: >> >> "must be for standards purposes (either for an IETF Standard ..." >> >> Such an assignment is a standards action item, and last I checked we wer= e >> not defining a new standard here. >> >> >> !!! >> Let's hope its isn't on purpose, to support an unjustified argument, tha= t >> you truncated the quoted sentence of RFC5342. >> The full sentence is: >> "must be for standards purposes (either for an IETF Standard or other >> standard related to IETF work)". >> A BCP isn't a standard, agreed, but publishing a BCP does qualify for >> being part of "other standard related to IETF work". > > > "... other standard related to IETF work", means, to me at least: standar= d > work done outside of the IETF, but related to IETF standards, which would > not appear to apply here. >> >> >> Furthermore, the actual call for such a reservation appears not to be >> needed, if we get over the fact that a routed mode + pd is better at >> handling this case. >> >> >> As said, if the three IID ranges below are reserved, 464XLAT can be adde= d >> to nodes that support tethering with /64s without interfering with the >> chosen approach for this support. >> This is IMHO good enough a motivation to just reserve three subranges in= a >> range "available for allocation" in RFC 5342. > > > Well, it still has "holes". You will get conflicts among devices even if = you > reserve a range. The only save way is to stop doing this and assign a uni= que > /64 for each device, which the routed+pd mode of operation would accompli= sh. > Given that it is to be supported anyway, it seems like a far better way t= han > the seeking IANA allocations, etc. > > Cheers, > Woj. Woj, 4 points: 1. The AD (Ron) has already said in the Vancouver meeting that the IANA request is "Fine". Let's not go over this again. http://www.ietf.org/proceedings/84/minutes/minutes-84-v6ops 2. Sharing the /64 is a clear requirement. Several people have stated it is requirement, it will not be given up. 3. I remain of the opinion that we must just acknowledge the /64 sharing exists and it is for the implementation to determine how best that must happen. That said, i am not opposed to reserving the IID for the sake of enabling a technically astute solution proposed by R=E9mi, but maybe that is best for a more general draft after /64 sharing than 464XLAT I-D. 4. Regarding holes. I agree, we can corner case this to death if we try to specify a general solution for all cases, and there is a serious scope issue. Hence my point in #3. Don't solve for all use cases in all scenarios. There is no requirement that we have one universal approach, but we do state DHCP-PD takes priority. 464XLAT defines it self as an architecture in the first sentence, not a detailed design. CB >> >> >> This is in my understanding what we are discussing right now. >> >> >> RD >> >> >> >> >> >> >> Cheers, >> -Woj. >> >> On 7 September 2012 17:56, R=E9mi Despr=E9s w= rote: >>> >>> Hi, Tom, >>> >>> Thanks for the clarification about IANA vocabulary (I hadn't checked >>> www.iana.org/assignments/ethernet-numbers/ethernet-numbers.xml#ethernet= -numbers-4). >>> >>> With the IANA-related FUD eliminated, and with the common wish to suppo= rt >>> /64 delegated prefixes, do you agree that, with the reserved ranges bel= ow, >>> 464XLAT can be implemented: >>> - without interfering with the approach chosen for tethering and /64 >>> - completely statelessly (no NAT44 needed). >>> >>> If not, requests for clarification are welcome. >>> >>> Regards, >>> RD >>> >>> Le 2012-09-07 =E0 12:55, t.petch a =E9crit : >>> >>> > ----- Original Message ----- >>> > From: "Lorenzo Colitti" >>> > To: "R=E9mi Despr=E9s" >>> > Cc: "v6ops WG" >>> > Sent: Thursday, September 06, 2012 8:48 AM >>> > On Thu, Sep 6, 2012 at 4:20 PM, R=E9mi Despr=E9s >>> > wrote: >>> > >>> >> Let's assume IANA has reserved for CLATs the following subranges of >>> > the >>> >> range available for allocation in RFC5342 section 2.2.2: >>> >> 02-00-5E-10-0A-xx-xx-xx for CLATs using 10../8 >>> >> 02-00-5E-10-AC-1x-xx-xx for CLATs using 172.16../12 >>> >> 02-00-5E-10-C0-A8-xx-xx for CLATs using 192.168../16 >>> >> >>> > >>> > Since assuming the impossible leads to failure, we first need to ensu= re >>> > that: >>> > >>> > 1. IANA has the authority to assign such address space. >>> > 2. IANA is willing to assign such address space >>> > 3. IANA has the techical capability (e.g., processes) to assign suc= h >>> > address space. >>> ... >>> > so no problem with IANA. >>> > >>> > As at the time of this message, the indicated addresses are available= . >>> > IANA calls them Ethernet numbers rather than OUI. >>> > >>> > Tom Petch >>> > >>> > >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >> >> >> > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From wdec.ietf@gmail.com Fri Sep 7 11:32:45 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5752121E80AE for ; Fri, 7 Sep 2012 11:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.338 X-Spam-Level: X-Spam-Status: No, score=-2.338 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3KGYFpenskUs for ; Fri, 7 Sep 2012 11:32:44 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9C92321E80C4 for ; Fri, 7 Sep 2012 11:32:43 -0700 (PDT) Received: by eekb45 with SMTP id b45so1436954eek.31 for ; Fri, 07 Sep 2012 11:32:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Al3hx9W1WEsfmWR2+D1VQp1/PaRQXSMynqueBwtkCOY=; b=MqWzuXYqLDaBS5R2gjWnMHuScOPcN4rG7sFE4Wijwn/GevvrKgSoUuKZDxez7tWA3m Zrr+SBrtU9p8FUjTNGRhkdmtrVMG/W6XPNxSHDTiLZXsCy7ATMl7rFJrTfgHJoE+ijyi TvgpdWDPyiw0k5sU8Yersa2cMWzPK8TbXzaw/KR1bZHmFaFAaY48H+JB/cYgG5r+bA5T 43oNOOI5QZHE1ZpVqTc98rhQqtCYn5Yf3aTHGMcWFRL+IkD2p4z39p4qELDnsZ0p/Bez TGmjBKjfmnQg6wAXOAjls81Nd5t0nb2xP7CGFA2gPEwNYEFbLjiP2gRI+nWdWh957xLT FOXw== MIME-Version: 1.0 Received: by 10.14.207.9 with SMTP id m9mr9444076eeo.5.1347042762743; Fri, 07 Sep 2012 11:32:42 -0700 (PDT) Received: by 10.14.45.68 with HTTP; Fri, 7 Sep 2012 11:32:42 -0700 (PDT) In-Reply-To: References: <504392E0.8070802@bogus.com> <448050D4-84F9-4F52-BF7E-347EA451A96C@laposte.net> <041e01cd8ce7$61aeebc0$4001a8c0@gateway.2wire.net> <2808F812-B159-4F99-A7A1-C6B159EABBA0@laposte.net> Date: Fri, 7 Sep 2012 20:32:42 +0200 Message-ID: From: Wojciech Dec To: Cameron Byrne Content-Type: multipart/alternative; boundary=047d7b33dc305eddfd04c920d510 Cc: v6ops WG Subject: Re: [v6ops] 464XLAT - support of /64 delegated prefixes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 18:32:45 -0000 --047d7b33dc305eddfd04c920d510 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 7 September 2012 20:11, Cameron Byrne wrote: > On Fri, Sep 7, 2012 at 10:47 AM, Wojciech Dec wrote= : > > > > > > On 7 September 2012 19:18, R=E9mi Despr=E9s > wrote: > >> > >> > >> 2012-09-07 18:25, Wojciech Dec : > >> > >> You may want to re-read: > >> > >> "must be for standards purposes (either for an IETF Standard ..." > >> > >> Such an assignment is a standards action item, and last I checked we > were > >> not defining a new standard here. > >> > >> > >> !!! > >> Let's hope its isn't on purpose, to support an unjustified argument, > that > >> you truncated the quoted sentence of RFC5342. > >> The full sentence is: > >> "must be for standards purposes (either for an IETF Standard or other > >> standard related to IETF work)". > >> A BCP isn't a standard, agreed, but publishing a BCP does qualify for > >> being part of "other standard related to IETF work". > > > > > > "... other standard related to IETF work", means, to me at least: > standard > > work done outside of the IETF, but related to IETF standards, which wou= ld > > not appear to apply here. > >> > >> > >> Furthermore, the actual call for such a reservation appears not to be > >> needed, if we get over the fact that a routed mode + pd is better at > >> handling this case. > >> > >> > >> As said, if the three IID ranges below are reserved, 464XLAT can be > added > >> to nodes that support tethering with /64s without interfering with the > >> chosen approach for this support. > >> This is IMHO good enough a motivation to just reserve three subranges > in a > >> range "available for allocation" in RFC 5342. > > > > > > Well, it still has "holes". You will get conflicts among devices even i= f > you > > reserve a range. The only save way is to stop doing this and assign a > unique > > /64 for each device, which the routed+pd mode of operation would > accomplish. > > Given that it is to be supported anyway, it seems like a far better way > than > > the seeking IANA allocations, etc. > > > > Cheers, > > Woj. > > Woj, > > 4 points: > > 1. The AD (Ron) has already said in the Vancouver meeting that the > IANA request is "Fine". Let's not go over this again. > http://www.ietf.org/proceedings/84/minutes/minutes-84-v6ops > > 2. Sharing the /64 is a clear requirement. Several people have > stated it is requirement, it will not be given up. > > 3. I remain of the opinion that we must just acknowledge the /64 > sharing exists and it is for the implementation to determine how best > that must happen. That said, i am not opposed to reserving the IID > for the sake of enabling a technically astute solution proposed by > R=E9mi, but maybe that is best for a more general draft after /64 > sharing than 464XLAT I-D. > > 4. Regarding holes. I agree, we can corner case this to death if we > try to specify a general solution for all cases, and there is a > serious scope issue. Hence my point in #3. Don't solve for all use > cases in all scenarios. There is no requirement that we have one > universal approach, but we do state DHCP-PD takes priority. > It's a basic case of two clat's on a shared /64 both starting/trying to use one of the "reserved" addresses. It will fail for one. We could go into DAD/algorithmic solutions for this problem, but frankly, the solution that appears to be more sensible is just not to do it and leave this to the PD mode, rather than standardizing a new way of doing SLAAC (which coincidentally this appears to be). This would also allow the design to move directly away from the proxy-nd or some non-ietf methods (hacks), or nd cache ugliness that we would like to stay clear of. -Woj. > > 464XLAT defines it self as an architecture in the first sentence, not > a detailed design. > > CB > > >> > >> > >> This is in my understanding what we are discussing right now. > >> > >> > >> RD > >> > >> > >> > >> > >> > >> > >> Cheers, > >> -Woj. > >> > >> On 7 September 2012 17:56, R=E9mi Despr=E9s > wrote: > >>> > >>> Hi, Tom, > >>> > >>> Thanks for the clarification about IANA vocabulary (I hadn't checked > >>> > www.iana.org/assignments/ethernet-numbers/ethernet-numbers.xml#ethernet-n= umbers-4 > ). > >>> > >>> With the IANA-related FUD eliminated, and with the common wish to > support > >>> /64 delegated prefixes, do you agree that, with the reserved ranges > below, > >>> 464XLAT can be implemented: > >>> - without interfering with the approach chosen for tethering and /64 > >>> - completely statelessly (no NAT44 needed). > >>> > >>> If not, requests for clarification are welcome. > >>> > >>> Regards, > >>> RD > >>> > >>> Le 2012-09-07 =E0 12:55, t.petch a =E9crit : > >>> > >>> > ----- Original Message ----- > >>> > From: "Lorenzo Colitti" > >>> > To: "R=E9mi Despr=E9s" > >>> > Cc: "v6ops WG" > >>> > Sent: Thursday, September 06, 2012 8:48 AM > >>> > On Thu, Sep 6, 2012 at 4:20 PM, R=E9mi Despr=E9s > >>> > wrote: > >>> > > >>> >> Let's assume IANA has reserved for CLATs the following subranges o= f > >>> > the > >>> >> range available for allocation in RFC5342 section 2.2.2: > >>> >> 02-00-5E-10-0A-xx-xx-xx for CLATs using 10../8 > >>> >> 02-00-5E-10-AC-1x-xx-xx for CLATs using 172.16../12 > >>> >> 02-00-5E-10-C0-A8-xx-xx for CLATs using 192.168../16 > >>> >> > >>> > > >>> > Since assuming the impossible leads to failure, we first need to > ensure > >>> > that: > >>> > > >>> > 1. IANA has the authority to assign such address space. > >>> > 2. IANA is willing to assign such address space > >>> > 3. IANA has the techical capability (e.g., processes) to assign > such > >>> > address space. > >>> ... > >>> > so no problem with IANA. > >>> > > >>> > As at the time of this message, the indicated addresses are > available. > >>> > IANA calls them Ethernet numbers rather than OUI. > >>> > > >>> > Tom Petch > >>> > > >>> > > >>> _______________________________________________ > >>> v6ops mailing list > >>> v6ops@ietf.org > >>> https://www.ietf.org/mailman/listinfo/v6ops > >> > >> > >> > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > --047d7b33dc305eddfd04c920d510 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 7 September 2012 20:11, Cameron Byrne= <cb.list6@gmail.com> wrote:
On Fri, Sep 7, 2012 at 10:47 AM, Wo= jciech Dec <wdec.ietf@gmail.com> wrote:
>
>
> On 7 September 2012 19:18, R=E9mi Despr=E9s <despres.remi@laposte.net> wrote:
>>
>>
>> 2012-09-07 18:25, Wojciech Dec :
>>
>> You may want to re-read:
>>
>> "must be for standards purposes (either for an IETF Standard = ..."
>>
>> Such an assignment is a standards action item, and last I checked = we were
>> not defining a new standard here.
>>
>>
>> !!!
>> Let's hope its isn't on purpose, to support an unjustified= argument, that
>> you truncated the quoted sentence of RFC5342.
>> The full sentence is:
>> "must be for standards purposes (either for an IETF Standard = or other
>> standard related to IETF work)".
>> A BCP isn't a standard, agreed, but publishing a BCP does qual= ify for
>> being part of "other standard related to IETF work".
>
>
> "... other standard related to IETF work", means, to me at l= east: standard
> work done outside of the IETF, but related to IETF standards, which wo= uld
> not appear to apply here.
>>
>>
>> Furthermore, the actual call for such a reservation appears not to= be
>> needed, if we get over the fact that a routed mode + pd is better = at
>> handling this case.
>>
>>
>> As said, if the three IID ranges below are reserved, 464XLAT can b= e added
>> to nodes that support tethering with /64s without interfering with= the
>> chosen approach for this support.
>> This is IMHO good enough a motivation to just reserve three subran= ges in a
>> range "available for allocation" in RFC 5342.
>
>
> Well, it still has "holes". You will get conflicts among dev= ices even if you
> reserve a range. The only save way is to stop doing this and assign a = unique
> /64 for each device, which the routed+pd mode of operation would accom= plish.
> Given that it is to be supported anyway, it seems like a far better wa= y than
> the seeking IANA allocations, etc.
>
> Cheers,
> Woj.

Woj,

4 points:

1. =A0The AD (Ron) has already said in the Vancouver meeting that the
IANA request is "Fine". =A0Let's not go over this again.
http://www.ietf.org/proceedings/84/minutes/minutes-84-v6ops<= /a>

2. =A0Sharing the /64 is a clear requirement. =A0Several people have
stated it is requirement, it will not be given up.

3. =A0I remain of the opinion that we must just acknowledge the /64
sharing exists and it is for the implementation to determine how best
that must happen. =A0That said, i am not opposed to reserving the IID
for the sake of enabling a technically astute solution proposed by
R=E9mi, but maybe that is best for a more general draft =A0after /64
sharing than 464XLAT I-D.

4. Regarding holes. =A0I agree, we can corner case this to death if we
try to specify a general solution for all cases, and there is a
serious scope issue. =A0Hence my point in #3. =A0Don't solve for all us= e
cases in all scenarios. =A0There is no requirement that we have one
universal approach, but we do state DHCP-PD takes priority.

It's a basic case of two clat's on a shared /64 both star= ting/trying to use one of the "reserved" addresses. It will fail = for one. We could go into DAD/algorithmic solutions for this problem, but f= rankly, the solution that=A0 appears to be more sensible is just not to do = it and leave this to the PD mode, rather than standardizing a new way of do= ing SLAAC (which coincidentally this appears to be).=A0
This would also allow the design to move directly away from the proxy-nd or= some non-ietf methods (hacks), or nd cache ugliness that we would like to = stay clear of.

-Woj.
=A0

464XLAT defines it self as an architecture in the first sentence, not
a detailed design.

CB

>>
>>
>> This is in my understanding what we are discussing right now.
>>
>>
>> RD
>>
>>
>>
>>
>>
>>
>> Cheers,
>> -Woj.
>>
>> On 7 September 2012 17:56, R=E9mi Despr=E9s <despres.remi@laposte.net> wrote:
>>>
>>> Hi, Tom,
>>>
>>> Thanks for the clarification about IANA vocabulary (I hadn'= ;t checked
>>> www.iana.org/assig= nments/ethernet-numbers/ethernet-numbers.xml#ethernet-numbers-4).
>>>
>>> With the IANA-related FUD eliminated, and with the common wish= to support
>>> /64 delegated prefixes, do you agree that, with the reserved r= anges below,
>>> 464XLAT can be implemented:
>>> - without interfering with the approach chosen for tethering a= nd /64
>>> - completely statelessly (no NAT44 needed).
>>>
>>> If not, requests for clarification are welcome.
>>>
>>> Regards,
>>> RD
>>>
>>> Le 2012-09-07 =E0 12:55, t.petch a =E9crit :
>>>
>>> > ----- Original Message -----
>>> > From: "Lorenzo Colitti" <lorenzo@google.com>
>>> > To: "R=E9mi Despr=E9s" <despres.remi@laposte.net>
>>> > Cc: "v6ops WG" <v6ops@ietf.org>
>>> > Sent: Thursday, September 06, 2012 8:48 AM
>>> > On Thu, Sep 6, 2012 at 4:20 PM, R=E9mi Despr=E9s
>>> > <despres.r= emi@laposte.net>wrote:
>>> >
>>> >> Let's assume IANA has reserved for CLATs the foll= owing subranges of
>>> > the
>>> >> range available for allocation in RFC5342 section 2.2= .2:
>>> >> 02-00-5E-10-0A-xx-xx-xx for CLATs using 10../8
>>> >> 02-00-5E-10-AC-1x-xx-xx for CLATs using 172.16../12 >>> >> 02-00-5E-10-C0-A8-xx-xx for CLATs using 192.168../16<= br> >>> >>
>>> >
>>> > Since assuming the impossible leads to failure, we first = need to ensure
>>> > that:
>>> >
>>> > =A0 1. IANA has the authority to assign such address spac= e.
>>> > =A0 2. IANA is willing to assign such address space
>>> > =A0 3. IANA has the techical capability (e.g., processes)= to assign such
>>> > =A0 address space.
>>> ...
>>> > so no problem with IANA.
>>> >
>>> > As at the time of this message, the indicated addresses a= re available.
>>> > IANA calls them Ethernet numbers rather than OUI.
>>> >
>>> > Tom Petch
>>> >
>>> >
>>> _______________________________________________
>>> v6ops mailing list
>>> v6ops@ietf.org
>>> https://www.ietf.org/mailman/listinfo/v6ops
>>
>>
>>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>

--047d7b33dc305eddfd04c920d510-- From cb.list6@gmail.com Fri Sep 7 12:36:56 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66C2321F861F for ; Fri, 7 Sep 2012 12:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.165 X-Spam-Level: X-Spam-Status: No, score=-3.165 tagged_above=-999 required=5 tests=[AWL=0.434, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4tEo6bduMKHI for ; Fri, 7 Sep 2012 12:36:55 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8B72121F861E for ; Fri, 7 Sep 2012 12:36:55 -0700 (PDT) Received: by lahm15 with SMTP id m15so2263721lah.31 for ; Fri, 07 Sep 2012 12:36:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=y02byQle5An6bYuiHQloAH7/2Pmz84PREaTw1fkAoDw=; b=jqxrr2l0pnv7dUo+bftuyxKfUSKw/BdeDjaMwI4L6vJghGK8rdpvTblXDh3LtM7RFv AQtpRpyYQ4yeFlXZZ/8H9I5edzZiTsTOqVJ1Af6cU6yHpvsoy939A6WtA8halrwJcFpn BFPEd1lWuvWCXhl1CzhgIPzp/XWu/ZrwkIRv1+Lg/bL4/w85RD4mmdM2evVu04x4MeFL x89VLSqC2xbKuTDTgVFzcxWXd8GFIlGZRv3qdg7vWY9siXUaSn1jkCxtA0g/HtQXs4vA XEYx06BbjOqGWRDFLWYxz/ga/NeupzpNlRNp89wMteqtRIeuK3jt15XZsqVgSFLXN4KR 3WSA== MIME-Version: 1.0 Received: by 10.152.106.139 with SMTP id gu11mr6136346lab.57.1347046614432; Fri, 07 Sep 2012 12:36:54 -0700 (PDT) Received: by 10.112.49.66 with HTTP; Fri, 7 Sep 2012 12:36:54 -0700 (PDT) Date: Fri, 7 Sep 2012 12:36:54 -0700 Message-ID: From: Cameron Byrne To: IPv6 Ops WG Content-Type: text/plain; charset=ISO-8859-1 Subject: [v6ops] 464XLAT removing IPv6 LAN scope X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 19:36:56 -0000 Folks, I hope we can all see the scope issue related /64 sharing across interfaces, it is simply not germane to the function of 464XLAT and it should be removed. A much more workable solution, from IETF perspective, is to simply say that 464XLAT supports the DHCP-PD scenario for a dedicated translation prefix (no challenges that i know of), and in the case of no DHCP-PD available the CLAT does normal CLAT function for IPv4 with NAT44 as described in section 8.3.2 Meaning, there is an IPv6-only WAN and an IPv4 capable LAN, no bridging or sharing of IPv6 across the CLAT is specified. I would like to move forward with 464XLAT by simply stating that DHCP-PD is the best choice for acquiring a dedicated /64 to be used with stateless translation. http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-07#section-8.3.2 For section 8.3.2 we can retain how IPv4 is treated with NAT44, but simply remove how IPv6 is treated. If the CLAT cannot perform ND Proxy [RFC4389] due to the restriction of the implementation, the CLAT may use a dedicated IANA assigned EUI-64 ID for creating a translated IPv6 address to be used in stateless translation [RFC6145]. This will allow the CLAT to avoid possible IPv6 address duplication issues between an IPv6 address for stateless translation [RFC6145] in the CLAT and an IPv6 address assigned to native IPv6 nodes behind the CLAT. This document describes an example for this case in Example 2. of the Appendix A. The CLAT MAY discover the Pref64::/n of the PLAT via some method such as TR-069, DNS APL RR [RFC3123] or [I-D.ietf-behave-nat64-discovery-heuristic]. We can also remove the IANA section and remove reference to ND proxy. If implementations choose to extend a /64 from WAN to LAN in cases where DHCP-PD is not available, they may, but it is out of scope for *THIS* I-D. Hopefully some of the discussion here can feed further work in this area that appears to be needed. I believe this brings us back to pure 464XLAT which is an architecture for double translation, not /64 cross-interface extensions and not a CPE router specification. Any technical issues with this approach? CB From despres.remi@laposte.net Sun Sep 9 23:44:46 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6FF21F852A for ; Sun, 9 Sep 2012 23:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hO++V-nTUi6g for ; Sun, 9 Sep 2012 23:44:45 -0700 (PDT) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.2]) by ietfa.amsl.com (Postfix) with ESMTP id 3591921F8513 for ; Sun, 9 Sep 2012 23:44:44 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2108.sfr.fr (SMTP Server) with ESMTP id DACDA70000BB; Mon, 10 Sep 2012 08:44:42 +0200 (CEST) Received: from [192.168.1.73] (221.204.170.89.rev.sfr.net [89.170.204.221]) by msfrf2108.sfr.fr (SMTP Server) with ESMTP id 83ADD7000098; Mon, 10 Sep 2012 08:44:42 +0200 (CEST) X-SFR-UUID: 20120910064442539.83ADD7000098@msfrf2108.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: Date: Mon, 10 Sep 2012 08:44:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Cameron Byrne X-Mailer: Apple Mail (2.1084) Cc: IPv6 Ops WG Subject: Re: [v6ops] 464XLAT removing IPv6 LAN scope X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 06:44:46 -0000 Le 2012-09-07 =E0 21:36, Cameron Byrne a =E9crit : > Folks, >=20 > I hope we can all see the scope issue related /64 sharing across > interfaces, it is simply not germane to the function of 464XLAT and it > should be removed. >=20 > A much more workable solution, from IETF perspective, is to simply say > that 464XLAT supports the DHCP-PD scenario for a dedicated translation > prefix (no challenges that i know of), and in the case of no DHCP-PD > available the CLAT does normal CLAT function for IPv4 with NAT44 as > described in section 8.3.2 >=20 > Meaning, there is an IPv6-only WAN and an IPv4 capable LAN, no > bridging or sharing of IPv6 across the CLAT is specified. >=20 > I would like to move forward with 464XLAT by simply stating that > DHCP-PD is the best choice for acquiring a dedicated /64 to be used > with stateless translation. >=20 > http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-07#section-8.3.2 >=20 > For section 8.3.2 we can retain how IPv4 is treated with NAT44, but > simply remove how IPv6 is treated. >=20 > >=20 > If the CLAT cannot perform ND Proxy [RFC4389] due to the restriction > of the implementation, the CLAT may use a dedicated IANA assigned > EUI-64 ID for creating a translated IPv6 address to be used in > stateless translation [RFC6145]. This will allow the CLAT to avoid > possible IPv6 address duplication issues between an IPv6 address for > stateless translation [RFC6145] in the CLAT and an IPv6 address > assigned to native IPv6 nodes behind the CLAT. This document > describes an example for this case in Example 2. of the Appendix A. >=20 > The CLAT MAY discover the Pref64::/n of the PLAT via some method = such > as TR-069, DNS APL RR [RFC3123] or > [I-D.ietf-behave-nat64-discovery-heuristic]. >=20 >=20 > >=20 >=20 > We can also remove the IANA section and remove reference to ND proxy. > If implementations choose to extend a /64 from WAN to LAN in cases > where DHCP-PD is not available, they may, but it is out of scope for > *THIS* I-D. Hopefully some of the discussion here can feed further > work in this area that appears to be needed. Not sure to understand what you mean by "extend a /64 from WAN to LAN in = cases where DHCP-PD is not available". (If a site only has a /64, there can be a LAN, but no prefix can be = further delegated on this LAN, independently of code being available to = support DHCP-PD.) > I believe this brings us back to pure 464XLAT which is an architecture > for double translation, not /64 cross-interface extensions and not a > CPE router specification. In my recollection, NAT44s were introduced in the draft for = LAN-supporting /64 sites. Since then, we found that, with reserved IID ranges for CLATs, NAT44s = are no longer needed for such sites. =20 Then, could you clarify your intention: Is it to exclude /64-sites from the 464XLAT scope?=20 - If YES, 464XLAT would IMHO miss an important part of its natural = target. - If NO, are you intending to keep NAT44s in the draft? . If YES, the 464XLAT BCP includes CLAT nodes that aren't completely = stateless. This is contrary to the announced objective, and can't be = justified, IMHO, as it an be avoided just with three CLAT IID subranges. = (This reservation is to be made in a range already available for such = reservations, and is to be registered by IANA as usual if needed for an = IETF BCP). > Any technical issues with this approach? See above. Regards, RD =20 From despres.remi@laposte.net Sun Sep 9 23:47:46 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E554B21F846B for ; Sun, 9 Sep 2012 23:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oa9OSHV3HcCo for ; Sun, 9 Sep 2012 23:47:46 -0700 (PDT) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.2]) by ietfa.amsl.com (Postfix) with ESMTP id 09F5221F8448 for ; Sun, 9 Sep 2012 23:47:46 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2108.sfr.fr (SMTP Server) with ESMTP id 690167000064; Mon, 10 Sep 2012 08:47:45 +0200 (CEST) Received: from [192.168.1.73] (221.204.170.89.rev.sfr.net [89.170.204.221]) by msfrf2108.sfr.fr (SMTP Server) with ESMTP id 2D15B70000B0; Mon, 10 Sep 2012 08:47:45 +0200 (CEST) X-SFR-UUID: 20120910064745184.2D15B70000B0@msfrf2108.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: Date: Mon, 10 Sep 2012 08:47:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7298FD2A-55D5-4437-A890-53AF041AB03D@laposte.net> References: <504392E0.8070802@bogus.com> <448050D4-84F9-4F52-BF7E-347EA451A96C@laposte.net> <041e01cd8ce7$61aeebc0$4001a8c0@gateway.2wire.net> <2808F812-B159-4F99-A7A1-C6B159EABBA0@laposte.net> To: Wojciech Dec X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] 464XLAT - support of /64 delegated prefixes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 06:47:47 -0000 2012-09-07 =E0 20:32, Wojciech Dec : ... > It's a basic case of two clat's on a shared /64 both starting/trying = to use one of the "reserved" addresses. It will fail for one. As already discussed, this isn't true.=20 - Nothing "fails" (as you say), if CLAT addresses WAN side use IIDs in a = reserved range, and all hosts are standard-compliant (RFC4291).=20 . CLAT addresses aren't configured on any IPv6-link interface.=20 . Nothing is needed on the LAN side (DAD or otherwise) to prevent CLAT = addresses to be used.=20 - If some hosts are manually configured with standard-infringing = addresses, many failures are indeed possible. But responsibility isn't = that of 464XLAT. If your doubt would remain after checking the above, a detailed example = justifying it would be needed to justify it. RD From lorenzo@google.com Mon Sep 10 01:08:57 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03E1321F84EF for ; Mon, 10 Sep 2012 01:08:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.435 X-Spam-Level: X-Spam-Status: No, score=-102.435 tagged_above=-999 required=5 tests=[AWL=-0.360, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rxMyRlVdU9z7 for ; Mon, 10 Sep 2012 01:08:56 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1547821F84EB for ; Mon, 10 Sep 2012 01:08:55 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so2807720obb.31 for ; Mon, 10 Sep 2012 01:08:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=ZGrtBu6nPT+CmP0FUdkbdbvaYicgYAkS4TBOXK8v+ps=; b=IjaItpGuGIPV/ZjRH03t+8XstPHUxkqVQMoz5XTkkuVoyHL1+9YJV7va9LbFcOpOhL 9/kbCeTyHG/m5noRR1wRVhfeMa2t64wfOQJ6NBnYJkrZWJ7CjH4Z6iy6Rbbwwl60vTl9 gmfFj6D0CvR7JBFuvn2cHEcJITzZdyx+mOcidb9OJc6ZG4xvl7+0yOJiDSeWNP5GWyFC fin8OJP4nrp2+PuBlBmgaXKbMwZB0MMIddrhFjq9ExBc0DEFYJ0B0fo4eBgBvJbE7dTy R30hQTO2c1VaRkLSOAE5gvFzS3BeNslxxQPYQT8cxPjxNLYvcq+Y/ZasjjoFeAet2jgv nNwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=ZGrtBu6nPT+CmP0FUdkbdbvaYicgYAkS4TBOXK8v+ps=; b=iYxuzwwHNfVCcy/g8pNTlPRuEYE5961VKRuEWTZgqDBrsE7HkmGonrQaswVq5U4eKI SG7MC5c55xVjA5aCa5eNYzpwFujnyio9g7SEvN/WYKwFblLrqaKM+9pMCt8FwAw4P47E 0iJcs12Ou+Q1bY+xutHRuN20GvD03wvedTOvrt0MeT3iuRxSBvPd4aD1Sm2ZykbWISB2 cvMj1og5ii2Eqmjpfu8De92dmlf0UVqzTec7J47yAmGSYrzkmBiIF6/rFCZuMVF8ba/x XV/UYRbd72w3QniGrZO6scMUIWbdM+KXeybZhAiAMvH5KAuzoUlC0BDZN8wPzctRXd/e j6LA== Received: by 10.60.5.229 with SMTP id v5mr12857825oev.70.1347264535624; Mon, 10 Sep 2012 01:08:55 -0700 (PDT) Received: by 10.60.5.229 with SMTP id v5mr12857820oev.70.1347264535492; Mon, 10 Sep 2012 01:08:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.187.8 with HTTP; Mon, 10 Sep 2012 01:08:35 -0700 (PDT) In-Reply-To: <7298FD2A-55D5-4437-A890-53AF041AB03D@laposte.net> References: <504392E0.8070802@bogus.com> <448050D4-84F9-4F52-BF7E-347EA451A96C@laposte.net> <041e01cd8ce7$61aeebc0$4001a8c0@gateway.2wire.net> <2808F812-B159-4F99-A7A1-C6B159EABBA0@laposte.net> <7298FD2A-55D5-4437-A890-53AF041AB03D@laposte.net> From: Lorenzo Colitti Date: Mon, 10 Sep 2012 17:08:35 +0900 Message-ID: To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=e89a8f6431540e7a2504c9547802 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnHgavyhZ+7E4ABIgl0qCRWm1JHtXKi79KpxRseVx/Gv4AAJepoQaHzYjcEW+vJ4AjkiLYo0LqSSkMt2n0ad0jeU14MCfMvcRY40JQlBqBL9TnFW73ujuPXpGxRxETCBW3qgMw9Joq/q6m7GR/8KdUf7TqI+wTiv1VQunyqR6m3lt4hAk9sgrBhhoQ8l6rt4hh3xfJQ Cc: v6ops WG Subject: Re: [v6ops] 464XLAT - support of /64 delegated prefixes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 08:08:57 -0000 --e89a8f6431540e7a2504c9547802 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Remi, Cameron, Woj, I think you're talking past each other here. I believe that what Remi is proposing is: 0. If the CLAT wants to share its connection to downstream devices, it SHOULD attempt to obtain a DHCPv6 prefix delegation, but if it has an IPv6 /64, it MAY share that /64 with downstream devices. 1. IANA is requested to reserve three IID ranges for /64 sharing: - A 24-bit range to be used to map 10.0.0.0/8 - A 20-bit range to be used to map 172.16.0.0/12 - A 16-bit range to be used to map 192.168.0.0/16 2. When translating packets to and from hosts connected to the CLAT's downstream interface, the CLAT statelessly maps a.b.c.d into ::ab:cd. 3. The CLAT's own IPv6 address is determined by statelessly mapping the CLAT's downstream private IPv4 address as per point 2. That way you can only have IPv6 address conflicts only if you have IPv4 address conflicts - in which case you're probably in trouble already. Of course, this breaks if you put one CLAT behind the other and you have, for example, 10.0.1.100 in two places in the topology. However, that scenario is already broken because of the issues detailed in the ND proxy RFC. I think we can avoid that by saying, additionally: 4. The CLAT MUST NOT share the /64 unless its northbound interface is a point-to-point interface. With this scheme, the only real concern I see is excessive use of IID space. If we're not worried about that, then it seems a good idea to me. On Mon, Sep 10, 2012 at 3:47 PM, R=E9mi Despr=E9s wrote: > > 2012-09-07 =E0 20:32, Wojciech Dec : > ... > > > It's a basic case of two clat's on a shared /64 both starting/trying to > use one of the "reserved" addresses. It will fail for one. > > As already discussed, this isn't true. > - Nothing "fails" (as you say), if CLAT addresses WAN side use IIDs in a > reserved range, and all hosts are standard-compliant (RFC4291). > . CLAT addresses aren't configured on any IPv6-link interface. > . Nothing is needed on the LAN side (DAD or otherwise) to prevent CLAT > addresses to be used. > - If some hosts are manually configured with standard-infringing > addresses, many failures are indeed possible. But responsibility isn't th= at > of 464XLAT. > > If your doubt would remain after checking the above, a detailed example > justifying it would be needed to justify it. > > RD > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --e89a8f6431540e7a2504c9547802 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Remi, Cameron, Woj,

I think you're talking past each= other here. I believe that what Remi is proposing is:

=
0. If the CLAT wants to share its connection to downstream devices, it= SHOULD attempt to obtain a DHCPv6 prefix delegation, but if it has an IPv6= /64, it MAY share that /64 with downstream devices.
1. IANA is requested to reserve three IID ranges for /64 sharing:
=A0 - A 24-bit range to be used to map 10.0.0.0/8
=A0 - A 20-bit range to be used = to map 172.16.0.0/12=
=A0 - A 16-bit range to be used to map 192.168.0.0/16
2. When translating packets= to and from hosts connected to the CLAT's downstream interface, the CL= AT statelessly maps a.b.c.d into </64>:<iana-resvd>:ab:cd.
3. The CLAT's own IPv6 address is determined by statelessly mappin= g the CLAT's downstream private IPv4 address as per point 2.
=
That way you can only have IPv6 address conflicts only= if you have IPv4 address conflicts - in which case you're probably in = trouble already.

Of course, this breaks if you put one CLAT behind the o= ther and you have, for example, 10.0.1.100 in two places in the topology. H= owever, that scenario is already broken because of the issues detailed in t= he ND proxy RFC. I think we can avoid that by saying, additionally:

4. The CLAT MUST NOT share the /64 unless its northboun= d interface is a point-to-point interface.

With th= is scheme, the only real concern I see is excessive use of IID space. If we= 're not worried about that, then it seems a good idea to me.

On Mon, Sep 10, 2012 at 3:47= PM, R=E9mi Despr=E9s <despres.remi@laposte.net> wrot= e:

2012-09-07 =E0 20:32, Wojciech Dec :
...

> It's a basic case of two clat's on a shared /64 both starting/= trying to use one of the "reserved" addresses. It will fail for o= ne.

As already discussed, this isn't true.
- Nothing "fails" (as you say), if CLAT addresses WAN side use II= Ds in a reserved range, and all hosts are standard-compliant (RFC4291).
=A0. CLAT addresses aren't configured on any IPv6-link interface.
=A0. Nothing is needed on the LAN side (DAD or otherwise) to prevent CLAT a= ddresses to be used.
- If some hosts are manually configured with standard-infringing addresses,= many failures are indeed possible. But responsibility isn't that of 46= 4XLAT.

If your doubt would remain after checking the above, a detailed example jus= tifying it would be needed to justify it.

RD

_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

--e89a8f6431540e7a2504c9547802-- From lorenzo@google.com Mon Sep 10 02:42:21 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4E3321F85E7 for ; Mon, 10 Sep 2012 02:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.863 X-Spam-Level: X-Spam-Status: No, score=-102.863 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LKPtBca0lsmR for ; Mon, 10 Sep 2012 02:42:21 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB8A21F8585 for ; Mon, 10 Sep 2012 02:42:21 -0700 (PDT) Received: by ieak13 with SMTP id k13so2950319iea.31 for ; Mon, 10 Sep 2012 02:42:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=C9o3NwKlgpggeoUjneB5Q2hRPSctAIxhOLlyM1NiL1c=; b=SoRc31qa/lNdXcqdmR3iem2FStd52ksj96bzuTMIUOD2J7snD+r41OA9JIQtSHpAD8 CdlFhUwQJ/8gxjhiKet2//5Dn02Yu4VSQvrOrDesL418hHkMs41iq7LlnBxgGKX8rAzI PmIwRq76NwM7K/v7RVkN9DYUWQ+oiwLfwQw0Bjf7Eq4WckoDD7nRT5WWj6WGktNt6Q7I EqiFs5wVyYsW5AoPUKoOL12WtXSSmsqoz8PsKiz76weB30ifvocHrhl5wiqZOzcFhZQg NBQ8T9dYc8SvYiqbmQJnuCqM73Qh7a+lcZgjDsHFuTQNr67ra+HjFr+C5QOCDCGTa1vW tyyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=C9o3NwKlgpggeoUjneB5Q2hRPSctAIxhOLlyM1NiL1c=; b=C2RZ413Xmjh7I93EdVPcMEmFwSztsnKIL578JU+PQ4wcCxSGXp2Zw3CY+VQdd60Txz aFcPBzUYOmIdxXZBevRGm2PpVO02XYvIx6wwyrMUoDF1YvjzWA+FHwN3ebXzorp4ud8d rtBre4jmms+s5ujd236jmaSoV0snU0bPUicA7jJ3QdWU2N1L3NipnAtXUw4GYAj9mX6/ ML/E8iXEISJL5S/aL4jtXCMQd+eO0Nr+kDJWU+od/EFYKhX7kYCVXOkseEQjVOqMDLDK 6eJaGvFuehg6xutxrZLJ+xkEmXyPfVySD1b27EWg3ZTT0ecpUx6iEMMio7rpNE+6HvCV emOg== Received: by 10.50.220.170 with SMTP id px10mr15019790igc.0.1347270140634; Mon, 10 Sep 2012 02:42:20 -0700 (PDT) Received: by 10.50.220.170 with SMTP id px10mr15019775igc.0.1347270140533; Mon, 10 Sep 2012 02:42:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.246.2 with HTTP; Mon, 10 Sep 2012 02:41:59 -0700 (PDT) In-Reply-To: References: <810EAE3D-8767-4E66-911D-3DBDFE8B9403@laposte.net> From: Lorenzo Colitti Date: Mon, 10 Sep 2012 18:41:59 +0900 Message-ID: To: Maoke Content-Type: multipart/alternative; boundary=f46d0415580c249a5104c955c6ea X-System-Of-Record: true X-Gm-Message-State: ALoCoQlV5gwMPAdEcWhzdz2DDU74v1wzcns+WLB5KEGxGQGHmFymDl9ElY8tgeAfCBCcDhDkZvAavKul9cX4M0QVO2fOnObP8MY2GXI0C2jVvGgqvNPWbLqFzqsTCYqbVh1OzfclYV0HglHwVdL5xCwuPKc0qNznHsLLHzQbkz0VueONtA14/bgymaOZyTXLqRbUiClrSYrV Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 09:42:21 -0000 --f46d0415580c249a5104c955c6ea Content-Type: text/plain; charset=ISO-8859-1 On Sat, Sep 8, 2012 at 12:00 AM, Maoke wrote: > my suggestion: > > "464xlat is not designed to cover the case of IPv4-only applications > having access to IPv6-only servers, which will be possibly needed in the > future. Together using it with BIH [RFC6535] can be a feasible solution, if > this demand becomes true, and we leave the details of the co-existance to > the implemantaion. > I still disagree with this text, because it gives the impression that using BIH with 464xlat is a best practice, when in fact nobody has even tested it yet. What about the original suggestion of saying that "464xlat is not designed to cover the case of IPv4-only applications having access to IPv6-only servers. If that is needed, another transition mechanism such as BIH must be employed" ? By doing so, BIH continue to not be used together with a NAT64, as > recommended in [RFC6535], while 464xlat is being in charge of using NAT64s > as PLATs." > The way I read that sentence is, "There's a NAT64 in the architecture, and the BIH packets can go through that NAT64, but we're not using BIH with a NAT64. We're not because we say we're not. Really." That's pretty bad. We need to at least say thatif BIH is used, then it SHOULD NOT be used through the NAT64? I still don't see why BIH appears in this document at all. There's no reason to cite it. It's an RFC. People can implement it, deploy it, whatever - without us having to cite it in this RFC. There are lots of things you can use with CLAT, like IP-in-UDP-tunneling. But we're not putting IP-in-UDP-tunneling in this document. Why? --f46d0415580c249a5104c955c6ea Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, Sep 8, 2012 at 12:00 AM, Maoke <fibrib@gmail.com> wro= te:
my suggestion:=A0

"464xlat is not = designed to cover the case of IPv4-only applications having access to IPv6-= only servers, which will be possibly needed in the future. Together using i= t with BIH [RFC6535] can be a feasible solution, if this demand becomes tru= e, and we leave the details of the co-existance to the implemantaion.

I still disagree with this text, because i= t gives the impression that using BIH with 464xlat is a best practice, when= in fact nobody has even tested it yet. What about the original suggestion = of saying that "464xlat is not designed to cover the case of IPv4-only= applications having access to IPv6-only servers. If that is needed, anothe= r transition mechanism such as BIH must be employed" ?

By doing so, BIH = continue to not be used together with a NAT64, as recommended in [RFC6535],= while 464xlat is being in charge of using NAT64s as PLATs."

The way I read that sentence is, "The= re's a NAT64 in the architecture, and the BIH packets can go through th= at NAT64, but we're not using BIH with a NAT64. We're not because w= e say we're not. Really."=A0That's pretty bad. We need to at l= east say thatif BIH is used, then it SHOULD NOT be used through the NAT64?<= /div>

I still don't see why BIH appears in this document = at all. There's no reason to cite it. It's an RFC. People can imple= ment it, deploy it, whatever - without us having to cite it in this RFC. Th= ere are lots of things you can use with CLAT, like IP-in-UDP-tunneling. But= we're not putting IP-in-UDP-tunneling in this document. Why?
--f46d0415580c249a5104c955c6ea-- From despres.remi@laposte.net Mon Sep 10 03:10:19 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D882321F862A for ; Mon, 10 Sep 2012 03:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[AWL=0.550, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0P+l3Ng-O+m for ; Mon, 10 Sep 2012 03:10:19 -0700 (PDT) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.22]) by ietfa.amsl.com (Postfix) with ESMTP id AB28021F853B for ; Mon, 10 Sep 2012 03:10:18 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2316.sfr.fr (SMTP Server) with ESMTP id B080B7000058; Mon, 10 Sep 2012 12:10:16 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2316.sfr.fr (SMTP Server) with ESMTP id 37D55700007C; Mon, 10 Sep 2012 12:10:16 +0200 (CEST) X-SFR-UUID: 20120910101016228.37D55700007C@msfrf2316.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-40--402571125 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Mon, 10 Sep 2012 12:10:16 +0200 Message-Id: References: <810EAE3D-8767-4E66-911D-3DBDFE8B9403@laposte.net> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 10:10:20 -0000 --Apple-Mail-40--402571125 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-09-10 =E0 11:41, Lorenzo Colitti a =E9crit : > On Sat, Sep 8, 2012 at 12:00 AM, Maoke wrote: > my suggestion:=20 >=20 > "464xlat is not designed to cover the case of IPv4-only applications = having access to IPv6-only servers, which will be possibly needed in the = future. Together using it with BIH [RFC6535] can be a feasible solution, = if this demand becomes true, and we leave the details of the = co-existance to the implemantaion. >=20 > I still disagree with this text, because it gives the impression that = using BIH with 464xlat is a best practice, when in fact nobody has even = tested it yet. What about the original suggestion of saying that = "464xlat is not designed to cover the case of IPv4-only applications = having access to IPv6-only servers. If that is needed, another = transition mechanism such as BIH must be employed" ? Support for either of: (a) "464xlat is not designed to cover the case of IPv4-only applications = having access to IPv6-only servers. Using it together with BIH [RFC6535] = can be a feasible solution, and we leave the details of the co-existance = to the implementation." (already agreed by Maoke and myself). (b) "464xlat is not designed to cover the case of IPv4-only applications = having access to IPv6-only servers. If that is needed, another = transition mechanism such as BIH must be employed" (your proposal) (c) "464xlat is not designed to cover the case of IPv4-only applications = having access to IPv6-only servers. If that is needed, BIH of [RFC6535] = provides a solution." (your proposal, somewhat improved IMHO) >=20 > By doing so, BIH continue to not be used together with a NAT64, as = recommended in [RFC6535], while 464xlat is being in charge of using = NAT64s as PLATs." >=20 > The way I read that sentence is, "There's a NAT64 in the architecture, = and the BIH packets can go through that NAT64, but we're not using BIH = with a NAT64. We're not because we say we're not. Really." That's pretty = bad. We need to at least say thatif BIH is used, then it SHOULD NOT be = used through the NAT64? >=20 > I still don't see why BIH appears in this document at all. There's no = reason to cite it. It's an RFC. People can implement it, deploy it, = whatever - without us having to cite it in this RFC. There are lots of = things you can use with CLAT, like IP-in-UDP-tunneling. But we're not = putting IP-in-UDP-tunneling in this document. Why? Compromise sentences like the above are a way to put an end to this = already too long discussion. If Maoke accepts (b), or if he accepts (c) and you accept it too, we = hopefully are done. RD --Apple-Mail-40--402571125 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On Sat, Sep 8, 2012 at 12:00 AM, Maoke <fibrib@gmail.com> wrote:
my suggestion: 

"464xlat is not = designed to cover the case of IPv4-only applications having access to = IPv6-only servers, which will be possibly needed in the future. Together = using it with BIH [RFC6535] can be a feasible solution, if this demand = becomes true, and we leave the details of the co-existance to the = implemantaion.

I still disagree with this text, = because it gives the impression that using BIH with 464xlat is a best = practice, when in fact nobody has even tested it yet. What about the = original suggestion of saying that "464xlat is not designed to cover the = case of IPv4-only applications having access to IPv6-only servers. If = that is needed, another transition mechanism such as BIH must be = employed" ?

Support for = either of:
(a) "464xlat is not designed to cover the case = of IPv4-only applications having access to IPv6-only servers. Using it = together with BIH [RFC6535] can be a feasible solution, and we leave the = details of the co-existance to the implementation." (already agreed by = Maoke and myself).
(b) "464xlat is not designed to cover = the case of IPv4-only applications having access to IPv6-only servers. = If that is needed, another transition mechanism such as BIH must be = employed" (your proposal)
(c) "464xlat is not = designed to cover the case of IPv4-only applications having access to = IPv6-only servers. If that is needed, BIH of [RFC6535] = provides a solution." (your proposal, somewhat improved = IMHO)


By doing = so, BIH continue to not be used together with a NAT64, as recommended in = [RFC6535], while 464xlat is being in charge of using NAT64s as = PLATs."

The way I read that sentence is, = "There's a NAT64 in the architecture, and the BIH packets can go through = that NAT64, but we're not using BIH with a NAT64. We're not because we = say we're not. Really." That's pretty bad. We need to at least say = thatif BIH is used, then it SHOULD NOT be used through the NAT64?

I still don't see why BIH appears in this document = at all. There's no reason to cite it. It's an RFC. People can implement = it, deploy it, whatever - without us having to cite it in this RFC. = There are lots of things you can use with CLAT, like = IP-in-UDP-tunneling. But we're not putting IP-in-UDP-tunneling in this = document. Why?

Compromise sentences like the above are a = way to put an end to this already too long discussion.
If = Maoke accepts (b), or if he accepts (c) and you accept it too, we = hopefully are = done.

RD


=

= --Apple-Mail-40--402571125-- From fibrib@gmail.com Mon Sep 10 03:26:52 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E68021F862B for ; Mon, 10 Sep 2012 03:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.142 X-Spam-Level: X-Spam-Status: No, score=-3.142 tagged_above=-999 required=5 tests=[AWL=0.456, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ii-hPpMknDBt for ; Mon, 10 Sep 2012 03:26:51 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id DFCCD21F862A for ; Mon, 10 Sep 2012 03:26:50 -0700 (PDT) Received: by eekb45 with SMTP id b45so995899eek.31 for ; Mon, 10 Sep 2012 03:26:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KjYvnT56ponsrUzSmX7TaUh8vOFFy+ks6Of9RFfovH8=; b=cpv2BjzN04eLprR+hAFXZv7o1p5QmmRYa7elerpshbKeOkP2MX9rFryDgja3U37kKH G2o+BhE/IBOTXEPbnaHBsTtVA7WHSEouBEGtwH8BmCi84BfrNoE1RgEnfJswSE0B6WjN L5HE/qCwWBKrBKI9j49b6UFcg7Tgk/57PTrXWmjIdpGi4K6H59ANHjcPI7mnDum5KWjU RyNOlcFg/Tb7+hq2rKbUqBDe70vL7YLjKP1LtoY3u/frbFaBfhoOJdE1XPEd+ecxBYCG cWmZszm1soCvdAyEOpWWJOGoBDY5f5V74DZmci1pnykAuYkeqoCbXY7ud1j4/+tas8p1 whwA== MIME-Version: 1.0 Received: by 10.14.175.7 with SMTP id y7mr18698190eel.29.1347272810089; Mon, 10 Sep 2012 03:26:50 -0700 (PDT) Received: by 10.14.97.9 with HTTP; Mon, 10 Sep 2012 03:26:49 -0700 (PDT) In-Reply-To: References: <810EAE3D-8767-4E66-911D-3DBDFE8B9403@laposte.net> Date: Mon, 10 Sep 2012 19:26:49 +0900 Message-ID: From: Maoke To: Lorenzo Colitti Content-Type: multipart/alternative; boundary=047d7b62253842ce6204c9566552 Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 10:26:52 -0000 --047d7b62253842ce6204c9566552 Content-Type: text/plain; charset=ISO-8859-1 2012/9/10 Lorenzo Colitti > On Sat, Sep 8, 2012 at 12:00 AM, Maoke wrote: > >> my suggestion: >> >> "464xlat is not designed to cover the case of IPv4-only applications >> having access to IPv6-only servers, which will be possibly needed in the >> future. Together using it with BIH [RFC6535] can be a feasible solution, if >> this demand becomes true, and we leave the details of the co-existance to >> the implemantaion. >> > > I still disagree with this text, because it gives the impression that > using BIH with 464xlat is a best practice, when in fact nobody has even > tested it yet. What about the original suggestion of saying that "464xlat > is not designed to cover the case of IPv4-only applications having access > to IPv6-only servers. If that is needed, another transition mechanism such > as BIH must be employed" ? > > i share the same feeling. and i support your this suggestion. +1 > > > >> By doing so, BIH continue to not be used together with a NAT64, as >> recommended in [RFC6535], while 464xlat is being in charge of using NAT64s >> as PLATs." >> > > The way I read that sentence is, "There's a NAT64 in the architecture, and > the BIH packets can go through that NAT64, but we're not using BIH with a > NAT64. We're not because we say we're not. Really." That's pretty bad. We > need to at least say thatif BIH is used, then it SHOULD NOT be used through > the NAT64? > > i also doubt there is really not uncertainty to put BIH with CLAT together. i proposed a case where BIH/CLAT is poorly running for an in-domain server (which is a naturally established use-case of the CLAT without BIH) but it is argued this case is out of scope. so it is sounds to me that people prefer to attach this weird BIH with CLAT, even sacrifycing the possibly extended scope of usage. on the other hand, as i have seen that the *combination* is harmful at least for one case, even it is out of scope, i doubt there is definitely no in-scope trouble of this putting-together. a very detailed discussion is here: 1. a host behind the BIH/CLAT is to send out a request to a server, who has both AAAA and A type resolutions. 2. NOTE BIH is working since the stage of DNS because the host behind is possibly IPv4-only. if BIH cannot get an AAAA, it could be silent as there needed double-translation, fine. however, once BIH can get the AAAA type of the server, it traslates that AAAA to an A type resolution with an IPv4 address under its configuration. 3. then the host possibly receive two A type resolutions: the one of the genuine A of the server (let's note it as A#1); the one of what is translated by the BIH (A#2). it might randomly select one to send out the request. 4. the request arrives at the BIH/CLAT, uncertainty happens: - who take over the work? the BIH module or the CLAT module? - if it is the BIH, but the host actually selects A#1, then BIH has no state about this A#1, it has to drop the request; - if it is the CLAT module, but it happens that the host choose A#2, then the CLAT will send the request to nowhere. i don't know what we still need to make the *combination* of BIH and 464xlat safe in this document. > > I still don't see why BIH appears in this document at all. There's no > reason to cite it. It's an RFC. People can implement it, deploy it, > whatever - without us having to cite it in this RFC. There are lots of > things you can use with CLAT, like IP-in-UDP-tunneling. But we're not > putting IP-in-UDP-tunneling in this document. Why? > same view. but they argued that we are newcomers claiming, too late, at a *trivial* question already *well*-discussed in the WG and the authors also would like to push the things forward. :( if the above uncertainty is certain, the working group is making a mistake. - maoke --047d7b62253842ce6204c9566552 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
2012/9/10 Lorenzo Colitti = <lorenzo@google.= com>
On Sat, Sep 8, 2012 at 12:00 AM, Maoke = <fibrib@gmail.com<= /a>> wrote:
my suggestion:=A0

"464xlat is not = designed to cover the case of IPv4-only applications having access to IPv6-= only servers, which will be possibly needed in the future. Together using i= t with BIH [RFC6535] can be a feasible solution, if this demand becomes tru= e, and we leave the details of the co-existance to the implemantaion.

=A0

=A0
By doing so, BIH continue to not be used together with a NAT64, as r= ecommended in [RFC6535], while 464xlat is being in charge of using NAT64s a= s PLATs."

The way I read that sentence is, &qu= ot;There's a NAT64 in the architecture, and the BIH packets can go thro= ugh that NAT64, but we're not using BIH with a NAT64. We're not bec= ause we say we're not. Really."=A0That's pretty bad. We need t= o at least say thatif BIH is used, then it SHOULD NOT be used through the N= AT64?
=A0
=A0
so it is sounds to me that people prefer to attach this = weird BIH with CLAT, even sacrifycing the possibly extended scope of usage.=
=A0
on the other hand, as i have seen that the *combi= nation* is harmful at least for one case, even it is out of scope, i doubt = there is definitely no in-scope trouble of this putting-together.
=A0
a very detailed discussion is here:=A0
=A0
1. a host behind the BIH/CLAT is to send out a request to a server,= =A0who has both AAAA and A type resolutions. =A0
2. NOTE BIH is w= orking since the stage of DNS because the host behind is possibly IPv4-only= . if BIH cannot get an AAAA, it could be silent as there needed=A0double-tr= anslation, fine.=A0however, once=A0BIH can get=A0the AAAA type of=A0the ser= ver, it traslates that AAAA to an A type resolution with an IPv4 address un= der its configuration.
3. then the host possibly receive two A type resolutions: the one of t= he genuine A of the server (let's note it as A#1); the one of what is t= ranslated by the BIH (A#2). it might randomly select one to send out the re= quest.
4. the request arrives at the BIH/CLAT, uncertainty happens:
=A0=A0=A0 - who take over the work? the BIH module or the CLAT module?
=A0=A0=A0 - if it is the BIH, but the host actually selects A#1, the= n BIH has no state about this A#1, it has to drop the request;
=A0=A0=A0 - if it is the CLAT module, but=A0it=A0happens=A0that the ho= st=A0choose=A0A#2, then the CLAT will send the=A0request to nowhere. =A0
=A0
i don't know what we still need to make the *comb= ination* of BIH and 464xlat safe in this document.
=A0
=A0
I still don't see why BIH appears in this document at all. There'= s no reason to cite it. It's an RFC. People can implement it, deploy it= , whatever - without us having to cite it in this RFC. There are lots of th= ings you can use with CLAT, like IP-in-UDP-tunneling. But we're not put= ting IP-in-UDP-tunneling in this document. Why?

same view. but they argued that we are newcomer= s claiming, too late, at a=A0*trivial*=A0question already *well*-discussed = in the WG and the authors also would like to push the things forward. :( if= the above uncertainty is certain, the working group is making a mistake. <= /div>
=A0
- maoke
--047d7b62253842ce6204c9566552-- From fibrib@gmail.com Mon Sep 10 03:42:27 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84E3221F843A for ; Mon, 10 Sep 2012 03:42:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.983 X-Spam-Level: X-Spam-Status: No, score=-2.983 tagged_above=-999 required=5 tests=[AWL=0.315, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aUKbqY9Q3Vf8 for ; Mon, 10 Sep 2012 03:42:26 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2FAF121F8413 for ; Mon, 10 Sep 2012 03:42:26 -0700 (PDT) Received: by eaai11 with SMTP id i11so814531eaa.31 for ; Mon, 10 Sep 2012 03:42:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=65ZxemrYgteJKCvJ2JXYLAHReXY6Gw/Kxn2tI/2Rj5I=; b=VGICg7VEwV8ykn3z7Y1OlYVXDbwwR4gqCOECFhYEns7PDn0guTbz1QgsgNk3keOVDM 0R3eLEHe4fVeDwH6UaMuNDQRp106fmp6kI9wqZxe5jZI0TeGHYnW6QHR6oMWYpq1Ba6r pzZazHJ2qfO8/QKVZyFu2CR5uvm+GW7nHEM9eW5t7ZiUvOHJo3f4+4Jeksmab1S1zIoi 5m/JC9S08DixZ0Fqu4WcwikJcpv68cp6Oa+am4ESJDpMzvbb7mL1WGKB0atI1pxN3pPL NsXJZ8/ECo63nX0CzVN5q8eAmURq7WmjiVs9cLq+R12mEemu8S3aSFawef7bH4I+1FU9 TkxQ== MIME-Version: 1.0 Received: by 10.14.211.3 with SMTP id v3mr18815884eeo.43.1347273730190; Mon, 10 Sep 2012 03:42:10 -0700 (PDT) Received: by 10.14.97.9 with HTTP; Mon, 10 Sep 2012 03:42:09 -0700 (PDT) In-Reply-To: References: <810EAE3D-8767-4E66-911D-3DBDFE8B9403@laposte.net> Date: Mon, 10 Sep 2012 19:42:09 +0900 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=047d7b621e921a6c1c04c9569cda Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 10:42:27 -0000 --047d7b621e921a6c1c04c9569cda Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable dear Remi, please take some time to review the case that i propose in the previous reply. if you suggest we move forward but leave that case an open discussion. i suggest a text based on (b) or (c) (almost same to me) and some of (a): 464xlat is not designed to cover the case of IPv4-only applications having access to IPv6-only servers. If that is needed, BIH [RFC6535] possibly provides a solution. This BCP doesn't guarantee the integrity of putting 464xlat and BIH together, and we leave the details of the co-existance to the implementation. - maoke 2012/9/10 R=E9mi Despr=E9s > > Le 2012-09-10 =E0 11:41, Lorenzo Colitti a =E9crit : > > On Sat, Sep 8, 2012 at 12:00 AM, Maoke wrote: > >> my suggestion: >> >> "464xlat is not designed to cover the case of IPv4-only applications >> having access to IPv6-only servers, which will be possibly needed in the >> future. Together using it with BIH [RFC6535] can be a feasible solution,= if >> this demand becomes true, and we leave the details of the co-existance t= o >> the implemantaion. >> > > I still disagree with this text, because it gives the impression that > using BIH with 464xlat is a best practice, when in fact nobody has even > tested it yet. What about the original suggestion of saying that "464xlat > is not designed to cover the case of IPv4-only applications having access > to IPv6-only servers. If that is needed, another transition mechanism suc= h > as BIH must be employed" ? > > > Support for either of: > (a) "464xlat is not designed to cover the case of IPv4-only applications > having access to IPv6-only servers. Using it together with BIH [RFC6535] > can be a feasible solution, and we leave the details of the co-existance = to > the implementation." (already agreed by Maoke and myself). > (b) "464xlat is not designed to cover the case of IPv4-only applications > having access to IPv6-only servers. If that is needed, another transition > mechanism such as BIH must be employed" (your proposal) > (c) "464xlat is not designed to cover the case of IPv4-only applications > having access to IPv6-only servers. If that is needed, BIH of [RFC6535] > provides a solution." (your proposal, somewhat improved IMHO) > > > By doing so, BIH continue to not be used together with a NAT64, as >> recommended in [RFC6535], while 464xlat is being in charge of using NAT6= 4s >> as PLATs." >> > > The way I read that sentence is, "There's a NAT64 in the architecture, an= d > the BIH packets can go through that NAT64, but we're not using BIH with a > NAT64. We're not because we say we're not. Really." That's pretty bad. We > need to at least say thatif BIH is used, then it SHOULD NOT be used throu= gh > the NAT64? > > I still don't see why BIH appears in this document at all. There's no > reason to cite it. It's an RFC. People can implement it, deploy it, > whatever - without us having to cite it in this RFC. There are lots of > things you can use with CLAT, like IP-in-UDP-tunneling. But we're not > putting IP-in-UDP-tunneling in this document. Why? > > > Compromise sentences like the above are a way to put an end to this > already too long discussion. > If Maoke accepts (b), or if he accepts (c) and you accept it too, we > hopefully are done. > > RD > > > > > --047d7b621e921a6c1c04c9569cda Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
dear Remi,
=A0
please take some time to review th= e case that i propose in the previous reply. if you suggest we move forward= but leave that case an open discussion. i suggest a text based on (b) or (= c) (almost same to me)=A0and some of (a):
=A0
=A0=A0 464xlat is not designed to cover the case of IPv4= -only applications
=A0=A0 having access to IPv6-only servers. If= that is needed, BIH [RFC6535]
=A0=A0 possibly provides a soluti= on. This BCP doesn't=A0guarantee=A0the integrity
=A0=A0 of putting 464xlat and BIH together, and we leave the details o= f the
=A0=A0=A0co-existance to the implementation.
= =A0
- maoke
2012/9/10 R=E9mi = Despr=E9s <despres.remi@laposte.net>

Le 2012-= 09-10 =E0 11:41, Lorenzo Colitti a =E9crit :

On Sat, Sep 8, 2012 at 12:0= 0 AM, Maoke <fibrib@gmail.com> wrote:
my suggestion:=A0

"464xlat is not = designed to cover the case of IPv4-only applications having access to IPv6-= only servers, which will be possibly needed in the future. Together using i= t with BIH [RFC6535] can be a feasible solution, if this demand becomes tru= e, and we leave the details of the co-existance to the implemantaion.

I still disagree with this text, because i= t gives the impression that using BIH with 464xlat is a best practice, when= in fact nobody has even tested it yet. What about the original suggestion = of saying that "464xlat is not designed to cover the case of IPv4-only= applications having access to IPv6-only servers. If that is needed, anothe= r transition mechanism such as BIH must be employed" ?

Support for either of:
(a) "464xlat is not designed to cover the case of IPv4-only ap= plications having access to IPv6-only servers. Using it together with BIH [= RFC6535] can be a feasible solution, and we leave the details of the co-exi= stance to the implementation." (already agreed by Maoke and myself).
(b)=A0"464xlat is not designed to cover the case of IPv4-only app= lications having access to IPv6-only servers. If that is needed, another tr= ansition mechanism such as BIH must be employed" (your proposal)
(c)=A0"464xlat is not designed to cover the case of IPv4-on= ly applications having access to IPv6-only servers. If that is needed, BIH = of=A0[RFC6535] provides=A0a solution." (your proposal, somewhat improv= ed IMHO)


By doing so, BIH continue to no= t be used together with a NAT64, as recommended in [RFC6535], while 464xlat= is being in charge of using NAT64s as PLATs."

The way I read that sentence is, "The= re's a NAT64 in the architecture, and the BIH packets can go through th= at NAT64, but we're not using BIH with a NAT64. We're not because w= e say we're not. Really."=A0That's pretty bad. We need to at l= east say thatif BIH is used, then it SHOULD NOT be used through the NAT64?<= /div>

I still don't see why BIH appears in this document = at all. There's no reason to cite it. It's an RFC. People can imple= ment it, deploy it, whatever - without us having to cite it in this RFC. Th= ere are lots of things you can use with CLAT, like IP-in-UDP-tunneling. But= we're not putting IP-in-UDP-tunneling in this document. Why?

Compromise sentences like the above are a= way to put an end to this already too long discussion.
If Maoke = accepts (b), or if he accepts (c) and you accept it too, we hopefully are d= one.

RD
=





--047d7b621e921a6c1c04c9569cda-- From despres.remi@laposte.net Mon Sep 10 05:09:37 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71A0A21F8670 for ; Mon, 10 Sep 2012 05:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.415 X-Spam-Level: X-Spam-Status: No, score=-1.415 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KrXbrMh9H7ig for ; Mon, 10 Sep 2012 05:09:36 -0700 (PDT) Received: from smtp25.services.sfr.fr (smtp25.services.sfr.fr [93.17.128.118]) by ietfa.amsl.com (Postfix) with ESMTP id 5EA2C21F8668 for ; Mon, 10 Sep 2012 05:09:35 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2504.sfr.fr (SMTP Server) with ESMTP id AB2CF70000FE; Mon, 10 Sep 2012 14:09:34 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2504.sfr.fr (SMTP Server) with ESMTP id 32819700005E; Mon, 10 Sep 2012 14:09:34 +0200 (CEST) X-SFR-UUID: 20120910120934206.32819700005E@msfrf2504.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-42--395413317 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Mon, 10 Sep 2012 14:09:33 +0200 Message-Id: References: <810EAE3D-8767-4E66-911D-3DBDFE8B9403@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 12:09:37 -0000 --Apple-Mail-42--395413317 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 2012-09-10 12:26, Maoke : >=20 > 2012/9/10 Lorenzo Colitti > On Sat, Sep 8, 2012 at 12:00 AM, Maoke wrote: > my suggestion:=20 >=20 > "464xlat is not designed to cover the case of IPv4-only applications = having access to IPv6-only servers, which will be possibly needed in the = future. Together using it with BIH [RFC6535] can be a feasible solution, = if this demand becomes true, and we leave the details of the = co-existance to the implemantaion. >=20 > I still disagree with this text, because it gives the impression that = using BIH with 464xlat is a best practice, when in fact nobody has even = tested it yet. What about the original suggestion of saying that = "464xlat is not designed to cover the case of IPv4-only applications = having access to IPv6-only servers. If that is needed, another = transition mechanism such as BIH must be employed" ? > =20 > =20 > i share the same feeling. and i support your this suggestion. +1 +1 (As said in another mail, this sentence is one of those I accept.) Now that there is an agreement between Lorenzo, you and me. Let's hope it will be final this time. RD --Apple-Mail-42--395413317 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
2012-09-10 12:26, Maoke :


2012/9/10 Lorenzo Colitti <lorenzo@google.com>
On Sat, Sep 8, 2012 at 12:00 AM, Maoke <fibrib@gmail.com> wrote:
my suggestion: 

"464xlat is not designed to cover the case of IPv4-only applications having access to IPv6-only servers, which will be possibly needed in the future. Together using it with BIH [RFC6535] can be a feasible solution, if this demand becomes true, and we leave the details of the co-existance to the implemantaion.

I still disagree with this text, because it gives the impression that using BIH with 464xlat is a best practice, when in fact nobody has even tested it yet. What about the original suggestion of saying that "464xlat is not designed to cover the case of IPv4-only applications having access to IPv6-only servers. If that is needed, another transition mechanism such as BIH must be employed" ?
 
 
i share the same feeling. and i support your this suggestion. +1

+1
(As said in another mail, this sentence is one of those I accept.)

Now that there is an agreement between Lorenzo, you and me.
Let's hope it will be final this time.

RD


--Apple-Mail-42--395413317-- From phdgang@gmail.com Mon Sep 10 05:12:58 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FE2A21F8650 for ; Mon, 10 Sep 2012 05:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.34 X-Spam-Level: X-Spam-Status: No, score=-3.34 tagged_above=-999 required=5 tests=[AWL=0.259, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OO65m03LL6Mz for ; Mon, 10 Sep 2012 05:12:57 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8482721F8646 for ; Mon, 10 Sep 2012 05:12:57 -0700 (PDT) Received: by vbbfc26 with SMTP id fc26so489489vbb.31 for ; Mon, 10 Sep 2012 05:12:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3lo0dOdttdDee2WmBxZFiamLe3MYiwu8UY0s9jvCUEw=; b=yg7mufrzaGVemOzPIsMebd9OiS4Rx4tIP6ETqE7Sgq1IcWWLQln/Kgjf5Eb+iteT1m jrbEvR6daTMf22BG5gF6Q2ne6mKSeyBqU6cv2aYIUOFIDsK0paKwcbcNyCJmu8kNOTAV mLR5qr82rMU6aL+DBtgBCvSb43ivBEMN7CcWzRsd/N2tlnzkxWrR82eec5/voERdiNk+ R4LafCb5bE6dxmXK4mNCcjL93+lsZqqlSqYuw3UtHgZeHZJiCABjZlYkJuEebrJoQ7qn 2eslCj/Y1LWUKAMucto2tf41n2bZxQMX65tGWWIQvkhLWdd5BOEzP2JkEINFzrSB8m3T prpg== MIME-Version: 1.0 Received: by 10.58.74.3 with SMTP id p3mr20995931vev.27.1347279176784; Mon, 10 Sep 2012 05:12:56 -0700 (PDT) Received: by 10.58.114.231 with HTTP; Mon, 10 Sep 2012 05:12:56 -0700 (PDT) In-Reply-To: References: <810EAE3D-8767-4E66-911D-3DBDFE8B9403@laposte.net> Date: Mon, 10 Sep 2012 20:12:56 +0800 Message-ID: From: GangChen To: Lorenzo Colitti Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 12:12:58 -0000 Hello Lorenzo, 2012/9/10, Lorenzo Colitti : > On Sat, Sep 8, 2012 at 12:00 AM, Maoke wrote: > >> my suggestion: >> >> "464xlat is not designed to cover the case of IPv4-only applications >> having access to IPv6-only servers, which will be possibly needed in the >> future. Together using it with BIH [RFC6535] can be a feasible solution, >> if >> this demand becomes true, and we leave the details of the co-existance to >> the implemantaion. >> > > I still disagree with this text, because it gives the impression that using > BIH with 464xlat is a best practice, when in fact nobody has even tested it > yet. We admit the test because that is actually an ongoing work. >What about the original suggestion of saying that "464xlat is not > designed to cover the case of IPv4-only applications having access to > IPv6-only servers. If that is needed, another transition mechanism such as > BIH must be employed" ? I'm not sure what is *another transition mechanism* you indicate. The fact is we tried to verify that last week. The outcome is that BIH is the standard track which specified IPv4->IPv6. So it's worth to be improved like Remi's proposal (c) "464xlat is not designed to cover the case of IPv4-only applications having access to IPv6-only servers. If that is needed, BIH of [RFC6535] provides a solution." (your proposal, somewhat improved IMHO). > By doing so, BIH continue to not be used together with a NAT64, as >> recommended in [RFC6535], while 464xlat is being in charge of using >> NAT64s >> as PLATs." >> > > The way I read that sentence is, "There's a NAT64 in the architecture, and > the BIH packets can go through that NAT64, but we're not using BIH with a > NAT64. We're not because we say we're not. Really." That's pretty bad. We > need to at least say thatif BIH is used, then it SHOULD NOT be used through > the NAT64? The statement was already identified in RFC6535. With the reference of [RFC6535], it gives sufficient information to reader. Not sure we need to restate that in the 464xlat. Many thanks Gang From fibrib@gmail.com Mon Sep 10 05:22:53 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D48421F8437 for ; Mon, 10 Sep 2012 05:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.779 X-Spam-Level: X-Spam-Status: No, score=-1.779 tagged_above=-999 required=5 tests=[AWL=-0.931, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gKd9AuVHm2sg for ; Mon, 10 Sep 2012 05:22:37 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id DACB221F84CD for ; Mon, 10 Sep 2012 05:22:33 -0700 (PDT) Received: by eaai11 with SMTP id i11so871679eaa.31 for ; Mon, 10 Sep 2012 05:22:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=a2f+aGORrG65vRxzASrimUVhSLk0JFmRY3nG4WI/Awk=; b=meCMadK5vIBVBNITCIrbLhfko9IVjo9fhZZmqs1wYBdBEfwC7SV52dpZarTOQfJHT2 654XQ2LzEa97QRKk3boyMOTaO6CkJZHtjOtWVwfOnhEN2NtW6f+JJqBJqhkaVZ5UlDmW dW1WPsI8d67OL2MW1E3kEoxodrU+SPtOpWM8DPpfz24XP+L8rCpWAJbc0hALqn4ovI8z aKYKJVEur/DsXnifLUDQUuNOBuNusVWL3bM2qTxd2xUY536Y4/USbdhwWyvXrtq/9Hbk 9v0ouPxQXFf41lQ7F0o0Y1Xt2wyrSMGH9ew4uYex6MFFtvia2am5DQGy/DGeZniR5AdZ 11EA== MIME-Version: 1.0 Received: by 10.14.218.134 with SMTP id k6mr19536037eep.14.1347279753001; Mon, 10 Sep 2012 05:22:33 -0700 (PDT) Received: by 10.14.97.9 with HTTP; Mon, 10 Sep 2012 05:22:32 -0700 (PDT) In-Reply-To: References: <810EAE3D-8767-4E66-911D-3DBDFE8B9403@laposte.net> Date: Mon, 10 Sep 2012 21:22:32 +0900 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=047d7b6224c21738e704c9580301 Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 12:22:53 -0000 --047d7b6224c21738e704c9580301 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable =D4=DA 2012=C4=EA9=D4=C210=C8=D5=D0=C7=C6=DA=D2=BB=A3=ACR=A8=A6mi Despr=A8= =A6s =D0=B4=B5=C0=A3=BA > > 2012-09-10 12:26, Maoke : > > > 2012/9/10 Lorenzo Colitti 'lorenzo@google.com');>> > >> On Sat, Sep 8, 2012 at 12:00 AM, Maoke >> > wrote: >> >>> my suggestion: >>> >>> "464xlat is not designed to cover the case of IPv4-only applications >>> having access to IPv6-only servers, which will be possibly needed in th= e >>> future. Together using it with BIH [RFC6535] can be a feasible solution= , if >>> this demand becomes true, and we leave the details of the co-existance = to >>> the implemantaion. >>> >> >> I still disagree with this text, because it gives the impression that >> using BIH with 464xlat is a best practice, when in fact nobody has even >> tested it yet. What about the original suggestion of saying that "464xla= t >> is not designed to cover the case of IPv4-only applications having acces= s >> to IPv6-only servers. If that is needed, another transition mechanism su= ch >> as BIH must be employed" ? >> >> > > i share the same feeling. and i support your this suggestion. +1 > > > +1 > (As said in another mail, this sentence is one of those I accept.) > > Now that there is an agreement between Lorenzo, you and me. > Let's hope it will be final this time. > not yet until you have answered me about the uncertainty just discovered. i guess you truncated the message too quickly.. - maoke > > RD > > > --047d7b6224c21738e704c9580301 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable

=D4=DA 2012=C4=EA9=D4=C210=C8=D5=D0=C7=C6=DA=D2=BB=A3=ACR=A8=A6mi D= espr=A8=A6s =D0=B4=B5=C0=A3=BA

2012-09-10 12:26, Maoke :


2012/9/10 Lore= nzo Colitti <lorenzo@google.com>
my suggestion: 

"464xlat is n= ot designed to cover the case of IPv4-only applications having access to IP= v6-only servers, which will be possibly needed in the future. Together usin= g it with BIH [RFC6535] can be a feasible solution, if this demand becomes = true, and we leave the details of the co-existance to the implemantaion.

I still disagree with this text, bec= ause it gives the impression that using BIH with 464xlat is a best practice= , when in fact nobody has even tested it yet. What about the original sugge= stion of saying that "464xlat is not designed to cover the case of IPv= 4-only applications having access to IPv6-only servers. If that is needed, = another transition mechanism such as BIH must be employed" ?
 
 
i share the same = feeling. and i support your this suggestion. +1

+1
(As said in another mail, this sentence is o= ne of those I accept.)

Now that there is an agreement between Lorenz= o, you and me.
Let's hope it will be final this time.

not yet until you have answered = me about the uncertainty just discovered. i guess you truncated the message= too quickly.. - maoke 
 

RD


--047d7b6224c21738e704c9580301-- From fibrib@gmail.com Mon Sep 10 05:30:06 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9E2C21F869D for ; Mon, 10 Sep 2012 05:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.72 X-Spam-Level: X-Spam-Status: No, score=-1.72 tagged_above=-999 required=5 tests=[AWL=-0.872, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ibCK50kfhYUb for ; Mon, 10 Sep 2012 05:30:06 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB7221F8692 for ; Mon, 10 Sep 2012 05:30:05 -0700 (PDT) Received: by eaai11 with SMTP id i11so876068eaa.31 for ; Mon, 10 Sep 2012 05:30:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vJJIVwQS7l8ChokAHZweThY/dexyt5JGU6YiulPQ8ro=; b=DOR+Ddtsed5d6Q7MOQ2p5lwDX8OkjyudnfgjbTuIVVwOQbAjWBLI8jN96JQGn9+t5O reDQyt2CugIWAKa8kijSty/bYEjxLyda4G3T89r5uuC5h0eg9zXMSuNgwXLU/m52Q44j hjN45g8mvfxc27j43XruMTKykHJ6Iz5mqmAy/xt0/pdWl+gWXpUNAU9IUKA4xnkoTbCr stuCRWCDaBEf7qFwtghgHfmlUQXM2g2KfkXne7ePLzgGzxIhHrT4ZubAjvegn+GT7qt6 yO/+O7CEPYgK5TQgH+3FXp7AOutGqe+Q1esKn0srDSNXmIf2OkIc7UdIwx6SoKA2PtgC l2EQ== MIME-Version: 1.0 Received: by 10.14.202.71 with SMTP id c47mr19592617eeo.42.1347280205272; Mon, 10 Sep 2012 05:30:05 -0700 (PDT) Received: by 10.14.97.9 with HTTP; Mon, 10 Sep 2012 05:30:04 -0700 (PDT) In-Reply-To: References: <810EAE3D-8767-4E66-911D-3DBDFE8B9403@laposte.net> Date: Mon, 10 Sep 2012 21:30:04 +0900 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=047d7b343e380c558804c9581e02 Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 12:30:06 -0000 --047d7b343e380c558804c9581e02 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable i will raise a thread for that uncertainty when i get home as my text among the replies was hard to follow. - maoke =D4=DA 2012=C4=EA9=D4=C210=C8=D5=D0=C7=C6=DA=D2=BB=A3=ACMaoke =D0=B4=B5=C0= =A3=BA > > > =D4=DA 2012=C4=EA9=D4=C210=C8=D5=D0=C7=C6=DA=D2=BB=A3=ACR=A8=A6mi Despr= =A8=A6s =D0=B4=B5=C0=A3=BA > >> >> Now that there is an agreement between Lorenzo, you and me. >> Let's hope it will be final this time. >> > > not yet until you have answered me about the uncertainty just discovered. > i guess you truncated the message too quickly.. - maoke > > >> >> RD >> >> >> --047d7b343e380c558804c9581e02 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable

i will raise a thread for that uncertainty when i get home a= s my text among the replies was hard to follow. - maoke
=D4=DA 2012=C4=EA9=D4=C210=C8=D5=D0=C7=C6=DA=D2=BB=A3=ACMaoke =D0=B4=B5= =C0=A3=BA


=D4=DA 2012=C4=EA9=D4=C210=C8=D5=D0=C7=C6=DA=D2=BB=A3=ACR=A8=A6mi D= espr=A8=A6s =D0=B4=B5=C0=A3=BA

Now that there is an&n= bsp;agreement between Lorenzo, you and me.
Let's hope it will be final this time.

not yet until you have answered me about the uncerta= inty just discovered. i guess you truncated the message too quickly.. - mao= ke 
 

RD


--047d7b343e380c558804c9581e02-- From despres.remi@laposte.net Mon Sep 10 05:56:33 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84F8B21F86A2 for ; Mon, 10 Sep 2012 05:56:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.733 X-Spam-Level: X-Spam-Status: No, score=-0.733 tagged_above=-999 required=5 tests=[AWL=-0.181, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BfF7Y6x2PUlL for ; Mon, 10 Sep 2012 05:56:32 -0700 (PDT) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.12]) by ietfa.amsl.com (Postfix) with ESMTP id 5107321F86A1 for ; Mon, 10 Sep 2012 05:56:32 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2211.sfr.fr (SMTP Server) with ESMTP id DC19E7000051; Mon, 10 Sep 2012 14:56:30 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2211.sfr.fr (SMTP Server) with ESMTP id 6494270000A4; Mon, 10 Sep 2012 14:56:30 +0200 (CEST) X-SFR-UUID: 20120910125630412.6494270000A4@msfrf2211.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-44--392597394 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Mon, 10 Sep 2012 14:56:29 +0200 Message-Id: References: <810EAE3D-8767-4E66-911D-3DBDFE8B9403@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 12:56:33 -0000 --Apple-Mail-44--392597394 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Le 2012-09-10 =C3=A0 14:22, Maoke a =C3=A9crit : >=20 >=20 > =E5=9C=A8 2012=E5=B9=B49=E6=9C=8810=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=80=EF= =BC=8CR=C3=A9mi Despr=C3=A9s =E5=86=99=E9=81=93=EF=BC=9A >=20 > 2012-09-10 12:26, Maoke : >=20 >>=20 >> 2012/9/10 Lorenzo Colitti >> On Sat, Sep 8, 2012 at 12:00 AM, Maoke wrote: >> my suggestion:=20 >>=20 >> "464xlat is not designed to cover the case of IPv4-only applications = having access to IPv6-only servers, which will be possibly needed in the = future. Together using it with BIH [RFC6535] can be a feasible solution, = if this demand becomes true, and we leave the details of the = co-existance to the implemantaion. >>=20 >> I still disagree with this text, because it gives the impression that = using BIH with 464xlat is a best practice, when in fact nobody has even = tested it yet. What about the original suggestion of saying that = "464xlat is not designed to cover the case of IPv4-only applications = having access to IPv6-only servers. If that is needed, another = transition mechanism such as BIH must be employed" ? >> =20 >> =20 >> i share the same feeling. and i support your this suggestion. +1 >=20 > +1 > (As said in another mail, this sentence is one of those I accept.) >=20 > Now that there is an agreement between Lorenzo, you and me. > Let's hope it will be final this time. >=20 > not yet until you have answered me about the uncertainty just = discovered. i guess you truncated the message too quickly.. - maoke=20 Is this to mean that you +1, and support of Lorenzo's suggestion, wasn't = real? If yes that's a disappointment. I didn't react to your further comments because I felt it wasn't = necessary for the conclusion to be acceptable, and I am currently busy = on too many subjects.=20 This isn't to say I won't react later on but, when you have agreed on a = sentence, it would be nice if you wouldn't retract your agreement when = someone else agrees too. Now, BIH is standard track. If 464XLAT would conflict with it, 464XLAT = should be modified to avoid that. (Fortunately, this isn't the case.)=20 RD =20 =20 > =20 >=20 > RD >=20 >=20 --Apple-Mail-44--392597394 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8


=E5=9C=A8 2012=E5=B9=B49=E6=9C=8810=E6=97=A5=E6=98=9F= =E6=9C=9F=E4=B8=80=EF=BC=8CR=C3=A9mi Despr=C3=A9s = =E5=86=99=E9=81=93=EF=BC=9A

2012-09-10 12:26, Maoke = :


2012/9/10 = Lorenzo Colitti <lorenzo@google.com>
On Sat, Sep 8, 2012 at 12:00 AM, Maoke <fibrib@gmail.com> wrote:
my suggestion: 

"464xlat is not = designed to cover the case of IPv4-only applications having access to = IPv6-only servers, which will be possibly needed in the future. Together = using it with BIH [RFC6535] can be a feasible solution, if this demand = becomes true, and we leave the details of the co-existance to the = implemantaion.

I still disagree with this text, = because it gives the impression that using BIH with 464xlat is a best = practice, when in fact nobody has even tested it yet. What about the = original suggestion of saying that "464xlat is not designed to cover the = case of IPv4-only applications having access to IPv6-only servers. If = that is needed, another transition mechanism such as BIH must be = employed" ?
 
 
i share the = same feeling. and i support your this suggestion. +1 =

+1
(As said in = another mail, this sentence is one of those I accept.)

Now that there is an agreement = between Lorenzo, you and me.
Let's hope it will be final = this time.

not yet = until you have answered me about the uncertainty just discovered. i = guess you truncated the message too quickly.. - = maoke 

Is this to mean that you = +1, and support of Lorenzo's suggestion, wasn't real?
If yes = that's a disappointment.

I didn't react to your = further comments because I felt it wasn't necessary for the conclusion = to be acceptable, and I am currently busy on too many = subjects. 

This isn't to say I won't react = later on but, when you have agreed on a sentence, it would be nice if = you wouldn't retract your agreement when someone else agrees = too.
Now, BIH is standard track. If 464XLAT would conflict = with it, 464XLAT should be modified to avoid that. (Fortunately, this = isn't the = case.) 


RD

  

 
 

RD

<= br>

= --Apple-Mail-44--392597394-- From tjc@ecs.soton.ac.uk Mon Sep 10 06:24:32 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D467F21F862B for ; Mon, 10 Sep 2012 06:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qap3vriF2F-e for ; Mon, 10 Sep 2012 06:24:31 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 948CE21F8600 for ; Mon, 10 Sep 2012 06:24:30 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q8ADOPZ3003801 for ; Mon, 10 Sep 2012 14:24:27 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk q8ADOPZ3003801 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1347283467; bh=v+ef8HruWR6HrqL1wyEsEspf3hs=; h=From:Mime-Version:Subject:Date:References:To:In-Reply-To; b=EVpinw+oyP3bMT2sGSpzZpgdp3n30s0y88olfVAf0XotE7jBJKVbGEjtB5dDC3CXR UR4TsjElRHxcg9zB4gz0v83r42fClJiRPRjOjBC8nwKUha82JVKLbcdYUnArBohok3 ejYKC0bHDhqHR1g1PQLXdDJjdyoLHYIJhnIwgs78= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id o89EOP0430613633Jy ret-id none; Mon, 10 Sep 2012 14:24:27 +0100 Received: from ip-204-037.eduroam.soton.ac.uk (ip-204-037.eduroam.soton.ac.uk [152.78.204.37]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q8ADOMoW031303 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 10 Sep 2012 14:24:22 +0100 From: Tim Chown Content-Type: multipart/alternative; boundary="Apple-Mail=_64CCCAD3-6F3A-4497-8CE4-45C0E89963B2" Message-ID: Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) Date: Mon, 10 Sep 2012 14:24:22 +0100 References: <810EAE3D-8767-4E66-911D-3DBDFE8B9403@laposte.net> <302B3918-AD28-405D-AFDC-CFD42ABF7476@ecs.soton.ac.uk> To: v6ops WG In-Reply-To: X-Mailer: Apple Mail (2.1486) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=o89EOP043061363300; tid=o89EOP0430613633Jy; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: q8ADOPZ3003801 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 13:24:33 -0000 --Apple-Mail=_64CCCAD3-6F3A-4497-8CE4-45C0E89963B2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 10 Sep 2012, at 10:41, Lorenzo Colitti wrote: > On Sat, Sep 8, 2012 at 12:00 AM, Maoke wrote: > my suggestion:=20 >=20 > "464xlat is not designed to cover the case of IPv4-only applications = having access to IPv6-only servers, which will be possibly needed in the = future. Together using it with BIH [RFC6535] can be a feasible solution, = if this demand becomes true, and we leave the details of the = co-existance to the implemantaion. >=20 > I still disagree with this text, because it gives the impression that = using BIH with 464xlat is a best practice, when in fact nobody has even = tested it yet. What about the original suggestion of saying that = "464xlat is not designed to cover the case of IPv4-only applications = having access to IPv6-only servers. If that is needed, another = transition mechanism such as BIH must be employed" ? I would only say "another transition mechanism is needed", given this is = a BCP text. > I still don't see why BIH appears in this document at all. There's no = reason to cite it. It's an RFC. People can implement it, deploy it, = whatever - without us having to cite it in this RFC. There are lots of = things you can use with CLAT, like IP-in-UDP-tunneling. But we're not = putting IP-in-UDP-tunneling in this document. Why? I agree with this view. This document is not aimed at access to v6 = servers (and there is big a clue in the name :) so please let's keep it = focused to the original problem, which is also stated clearly earlier in = the document. If you want to do a v4-only to v6-only access statement, which in my = view should be Informational not BCP, then I would suggest you write a = new draft and we can discuss that separately in v6ops. Tim --Apple-Mail=_64CCCAD3-6F3A-4497-8CE4-45C0E89963B2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 lorenzo@google.com> = wrote:

On Sat, Sep 8, 2012 at 12:00 AM, Maoke <fibrib@gmail.com> wrote:
my suggestion: 

"464xlat is not = designed to cover the case of IPv4-only applications having access to = IPv6-only servers, which will be possibly needed in the future. Together = using it with BIH [RFC6535] can be a feasible solution, if this demand = becomes true, and we leave the details of the co-existance to the = implemantaion.

I still disagree with this text, = because it gives the impression that using BIH with 464xlat is a best = practice, when in fact nobody has even tested it yet. What about the = original suggestion of saying that "464xlat is not designed to cover the = case of IPv4-only applications having access to IPv6-only servers. If = that is needed, another transition mechanism such as BIH must be = employed" ?

I would only say = "another transition mechanism is needed", given this is a BCP = text.

I still don't see why BIH appears in this = document at all. There's no reason to cite it. It's an RFC. People can = implement it, deploy it, whatever - without us having to cite it in this = RFC. There are lots of things you can use with CLAT, like = IP-in-UDP-tunneling. But we're not putting IP-in-UDP-tunneling in this = document. Why?

I agree with this = view.  This document is not aimed at access to v6 servers (and = there is big a clue in the name :) so please let's keep it focused to = the original problem, which is also stated clearly earlier in the = document.

If you want to do a v4-only to = v6-only access statement, which in my view should be Informational not = BCP, then I would suggest you write a new draft and we can discuss that = separately in = v6ops.

Tim

= --Apple-Mail=_64CCCAD3-6F3A-4497-8CE4-45C0E89963B2-- From fibrib@gmail.com Mon Sep 10 06:25:26 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BEFE21F8678 for ; Mon, 10 Sep 2012 06:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.669 X-Spam-Level: X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=-0.821, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVZO44rhefZi for ; Mon, 10 Sep 2012 06:25:25 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id EC9C421F866E for ; Mon, 10 Sep 2012 06:25:24 -0700 (PDT) Received: by eaai11 with SMTP id i11so908865eaa.31 for ; Mon, 10 Sep 2012 06:25:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=V/EC+p8c1Eo5q9Cr3GD3b7P8vnk4eVxhfk8zJ7jq8Q8=; b=yz5IG/irbQ7H6QtquJNgDa721rKsf2pAg9rbbxHIUSJ0AQgof6z4i50vXX2eeIh5wD YV8dIPOSZVBsRNKDaT3unLHcRWnGvB7LB7el31TH/XqCLaLtZE6wZpIM6Av/KBkot1oE 2zFcsSaqoecPUpDNdN8yUW7oVEJoiUA+hc6OJ1iG2Zqp3AH/deA1rSwGbfyB9870ypsy G2Sk0N/Vja8Lb8gxBp90yepPZ1ZS8DW+HmrAgcgpnIRzXN70NbmhrRnlhI5B36/9/C7S lWsRd1W4nwAf3M1EvAyRMT0e0ZP1jtF5dn6OQbGiV2OCMHE/snh6wdSxP6y/JIPvhzif qRmA== MIME-Version: 1.0 Received: by 10.14.172.129 with SMTP id t1mr19846828eel.34.1347283524061; Mon, 10 Sep 2012 06:25:24 -0700 (PDT) Received: by 10.14.97.9 with HTTP; Mon, 10 Sep 2012 06:25:23 -0700 (PDT) In-Reply-To: References: <810EAE3D-8767-4E66-911D-3DBDFE8B9403@laposte.net> Date: Mon, 10 Sep 2012 22:25:23 +0900 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=047d7b603c12dd0b9704c958e39b Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 13:25:26 -0000 --047d7b603c12dd0b9704c958e39b Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable 2012/9/10 R=A8=A6mi Despr=A8=A6s > > Le 2012-09-10 =A8=A4 14:22, Maoke a =A8=A6crit : > > > > =D4=DA 2012=C4=EA9=D4=C210=C8=D5=D0=C7=C6=DA=D2=BB=A3=ACR=A8=A6mi Despr= =A8=A6s =D0=B4=B5=C0=A3=BA > >> >> 2012-09-10 12:26, Maoke : >> >> >> 2012/9/10 Lorenzo Colitti >> >>> On Sat, Sep 8, 2012 at 12:00 AM, Maoke wrote: >>> >>>> my suggestion: >>>> >>>> "464xlat is not designed to cover the case of IPv4-only applications >>>> having access to IPv6-only servers, which will be possibly needed in t= he >>>> future. Together using it with BIH [RFC6535] can be a feasible solutio= n, if >>>> this demand becomes true, and we leave the details of the co-existance= to >>>> the implemantaion. >>>> >>> >>> I still disagree with this text, because it gives the impression that >>> using BIH with 464xlat is a best practice, when in fact nobody has even >>> tested it yet. What about the original suggestion of saying that "464xl= at >>> is not designed to cover the case of IPv4-only applications having acce= ss >>> to IPv6-only servers. If that is needed, another transition mechanism s= uch >>> as BIH must be employed" ? >>> >>> >> >> i share the same feeling. and i support your this suggestion. +1 >> >> >> +1 >> (As said in another mail, this sentence is one of those I accept.) >> >> Now that there is an agreement between Lorenzo, you and me. >> Let's hope it will be final this time. >> > > not yet until you have answered me about the uncertainty just discovered. > i guess you truncated the message too quickly.. - maoke > > > Is this to mean that you +1, and support of Lorenzo's suggestion, wasn't > real? > If yes that's a disappointment. > > i have a modified version. you may see if it is acceptable. on the other hand, i think you hold the same technical faith as i do that, if we find it is wrong, even at the last minute, we should correct. > > I didn't react to your further comments because I felt it wasn't necessar= y > for the conclusion to be acceptable, and I am currently busy on too many > subjects. > > i see this displomatic, sorry. but i can understand you are busy. > > This isn't to say I won't react later on but, when you have agreed on a > sentence, it would be nice if you wouldn't retract your agreement when > someone else agrees too. > > i still agree that sentence but i think that is not yet comprehensive enough. see my suggested modification. > > Now, BIH is standard track. If 464XLAT would conflict with it, 464XLAT > should be modified to avoid that. (Fortunately, this isn't the case.) > > i argued that 464xlat should be running independently. BIH cannot be running together with 464xlat is not the fault of the original 464xlat. don't cut feet to fit the shoes. are you suggest me to insist adding a text stating: NOT TO USE BIH with 464xlat? - maoke > > > > RD > > > > > > > >> >> RD >> >> >> > --047d7b603c12dd0b9704c958e39b Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
 
2012/9/10= R=A8=A6mi Despr=A8=A6s <despres.remi@laposte.net>

Le 2012-09-10 =A8=A4 14:2= 2, Maoke a =A8=A6crit :



=D4=DA 2012=C4=EA9=D4=C210=C8=D5=D0=C7=C6=DA=D2=BB=A3=ACR=A8= =A6mi Despr=A8=A6s =D0=B4=B5=C0=A3=BA

2012-09-10 12:26, Maoke :=


2012/9/10 Lore= nzo Colitti <lorenzo@google.com>
On Sat, Sep 8, 2012 at 12:00 AM, Maoke <fibrib= @gmail.com> wrote:
my suggestion: 

"464xlat is n= ot designed to cover the case of IPv4-only applications having access to IP= v6-only servers, which will be possibly needed in the future. Together usin= g it with BIH [RFC6535] can be a feasible solution, if this demand becomes = true, and we leave the details of the co-existance to the implemantaion.

I still disagree with this text, bec= ause it gives the impression that using BIH with 464xlat is a best practice= , when in fact nobody has even tested it yet. What about the original sugge= stion of saying that "464xlat is not designed to cover the case of IPv= 4-only applications having access to IPv6-only servers. If that is needed, = another transition mechanism such as BIH must be employed" ?
 
 
i share the same = feeling. and i support your this suggestion. +1

+1
(As said in another mail, this sentence is o= ne of those I accept.)

Now that there is an agreement between Lorenz= o, you and me.
Let's hope it will be final this time.

not yet until you have answered = me about the uncertainty just discovered. i guess you truncated the message= too quickly.. - maoke 

Is this to mean that you +1, and su= pport of Lorenzo's suggestion, wasn't real?
If yes that&#= 39;s a disappointment.
 
 =
i have a modified version. you may see if it is acceptable. on the oth= er hand, i think you hold the same technical faith as i do that, if we find= it is wrong, even at the last minute, we should correct.
 =
 
= I didn't react to your further comments because I felt it wasn't ne= cessary for the conclusion to be acceptable, and I am currently busy on too= many subjects. 
 
 
i see this displo= matic, sorry. but i can understand you are busy.
 
 
This isn't to= say I won't react later on but, when you have agreed on a sentence, it= would be nice if you wouldn't retract your agreement when someone else= agrees too.
 
 
i still agree tha= t sentence but i think that is not yet comprehensive enough. see my suggest= ed modification.
 
 
Now, BIH is stand= ard track. If 464XLAT would conflict with it, 464XLAT should be modified to= avoid that. (Fortunately, this isn't the case.) 
 =
 
i argued that 464xlat should be running independ= ently. BIH cannot be running together with 464xlat is not the fault of= the original 464xlat. don't cut feet to fit the shoes. are y= ou suggest me to insist adding a text stating: NOT TO USE BIH wit= h 464xlat?
 
- maoke
 
 


RD

=
  

 
 
=

RD




--047d7b603c12dd0b9704c958e39b-- From wdec.ietf@gmail.com Mon Sep 10 06:38:53 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE2921F8671 for ; Mon, 10 Sep 2012 06:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.848 X-Spam-Level: X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MmmfFHL9sO4S for ; Mon, 10 Sep 2012 06:38:52 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 27B8221F84DF for ; Mon, 10 Sep 2012 06:38:52 -0700 (PDT) Received: by eekb45 with SMTP id b45so1180222eek.31 for ; Mon, 10 Sep 2012 06:38:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ujI7lJtRGPItddllNS6Gy3ILKRk7SZYrNEP3a+SY87k=; b=krZ7kgrQd6333iyap6dcMwGiM1ye8is3pxPMS8CE3mN6fmaX30SHG0DY95Tsq8mExX aT4sD/LA1DDGDcUJtLarQUY+Hs4NR5aHFfH0NpUYenqrT1YBAY4H8Knf9KrkX4u7wItK hOFe4sdPUELwt031GbXTonAkXH6k2QSvcB0jrb7uyFN8xnpcwjxA9AG++hsHsQ/RNtPv 7lHc5sewFaRvEFGsBEt9RzolU4F3g1mCCF9G/PoympwFcq79B0vP2pG97fp5WxOPb749 2K2uAPoE38Z14Iw4QCCMVb+FQKWi7innA0GNKpEnfMuzA9a0aevuezCkbkuet/2/sRmr fhNw== MIME-Version: 1.0 Received: by 10.14.224.4 with SMTP id w4mr19983895eep.21.1347284331181; Mon, 10 Sep 2012 06:38:51 -0700 (PDT) Received: by 10.14.45.68 with HTTP; Mon, 10 Sep 2012 06:38:50 -0700 (PDT) In-Reply-To: References: <504392E0.8070802@bogus.com> <448050D4-84F9-4F52-BF7E-347EA451A96C@laposte.net> <041e01cd8ce7$61aeebc0$4001a8c0@gateway.2wire.net> <2808F812-B159-4F99-A7A1-C6B159EABBA0@laposte.net> <7298FD2A-55D5-4437-A890-53AF041AB03D@laposte.net> Date: Mon, 10 Sep 2012 15:38:50 +0200 Message-ID: From: Wojciech Dec To: Lorenzo Colitti Content-Type: multipart/alternative; boundary=047d7b6227d2f8b78c04c9591300 Cc: v6ops WG Subject: Re: [v6ops] 464XLAT - support of /64 delegated prefixes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 13:38:53 -0000 --047d7b6227d2f8b78c04c9591300 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Lorenzo, On 10 September 2012 10:08, Lorenzo Colitti wrote: > Remi, Cameron, Woj, > > I think you're talking past each other here. I believe that what Remi is > proposing is: > > 0. If the CLAT wants to share its connection to downstream devices, it > SHOULD attempt to obtain a DHCPv6 prefix delegation, but if it has an IPv= 6 > /64, it MAY share that /64 with > downstream devices. > Well, the sharing I am thinking of are further subtended IPv6 devices, possibly clats and this is where the "sharing" of the /64 downstream gets messy as in "it requires ND tricks, or hacks". It is the same case for a shared link really. > 1. IANA is requested to reserve three IID ranges for /64 sharing: > - A 24-bit range to be used to map 10.0.0.0/8 > - A 20-bit range to be used to map 172.16.0.0/12 > - A 16-bit range to be used to map 192.168.0.0/16 > 2. When translating packets to and from hosts connected to the CLAT's > downstream interface, the CLAT statelessly maps a.b.c.d into > ::ab:cd. > 3. The CLAT's own IPv6 address is determined by statelessly mapping the > CLAT's downstream private IPv4 address as per point 2. > > That way you can only have IPv6 address conflicts only if you have IPv4 > address conflicts - in which case you're probably in trouble already. > > Of course, this breaks if you put one CLAT behind the other and you have, > for example, 10.0.1.100 in two places in the topology. However, that > scenario is already broken because of the issues detailed in the ND proxy > RFC. I think we can avoid that by saying, additionally: > > 4. The CLAT MUST NOT share the /64 unless its northbound interface is a > point-to-point interface. > Right, but on a point-point link, one doesn't need the reserved IANA range anyway. That /64 is there for the device, and it can map anything into the IID, and strictly speaking it doesn't need to be limited to the ranges above. So in summary, as far as I see it is as follows: - If we're covering the p2p link case and subtended IPv4 devices, a single /64 is enough and no need of IANA assignments. Whatever the hosts will use is determined by the DHCPv4 assignment the clat device will (presumably) give. - If we're talking about subtended IPv6 devices and sharing a /64, then the IANA assignment lead to ND hacks, some new form of SLAAC; best left for handling via DHCP PD. Regards, Woj. > With this scheme, the only real concern I see is excessive use of IID > space. If we're not worried about that, then it seems a good idea to me. > > On Mon, Sep 10, 2012 at 3:47 PM, R=E9mi Despr=E9s wrote: > >> >> 2012-09-07 =E0 20:32, Wojciech Dec : >> ... >> >> > It's a basic case of two clat's on a shared /64 both starting/trying t= o >> use one of the "reserved" addresses. It will fail for one. >> >> As already discussed, this isn't true. >> - Nothing "fails" (as you say), if CLAT addresses WAN side use IIDs in a >> reserved range, and all hosts are standard-compliant (RFC4291). >> . CLAT addresses aren't configured on any IPv6-link interface. >> . Nothing is needed on the LAN side (DAD or otherwise) to prevent CLAT >> addresses to be used. >> - If some hosts are manually configured with standard-infringing >> addresses, many failures are indeed possible. But responsibility isn't t= hat >> of 464XLAT. >> >> If your doubt would remain after checking the above, a detailed example >> justifying it would be needed to justify it. >> >> RD >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > > --047d7b6227d2f8b78c04c9591300 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Lorenzo,

On 10 September 2012 10:08, L= orenzo Colitti <lorenzo@google.com> wrote:
Remi, Cameron, Woj,

I think you're talking past each= other here. I believe that what Remi is proposing is:

=
0. If the CLAT wants to share its connection to downstream devices, it= SHOULD attempt to obtain a DHCPv6 prefix delegation, but if it has an IPv6= /64, it MAY share that /64 with
downstream devi= ces.

Well, the sharing I am thinking of are furt= her subtended IPv6 devices, possibly clats and this is where the "shar= ing" of the /64 downstream gets messy as in "it requires ND trick= s, or hacks". It is the same case for a shared link really.
1. IANA is requested to reserve three IID ranges for /64 sharing:
=A0 - A 24-bit range to be used to map 10.0.0.0/8
=A0 - A 20-bit range to be used = to map 172.16.0.0/12=
=A0 - A 16-bit range to be used to map 192.168.0.0/16
2. When translating packets= to and from hosts connected to the CLAT's downstream interface, the CL= AT statelessly maps a.b.c.d into </64>:<iana-resvd>:ab:cd.
3. The CLAT's own IPv6 address is determined by statelessly mappin= g the CLAT's downstream private IPv4 address as per point 2.
=
That way you can only have IPv6 address conflicts only= if you have IPv4 address conflicts - in which case you're probably in = trouble already.

Of course, this breaks if you put one CLAT behind the o= ther and you have, for example, 10.0.1.100 in two places in the topology. H= owever, that scenario is already broken because of the issues detailed in t= he ND proxy RFC. I think we can avoid that by saying, additionally:

4. The CLAT MUST NOT share the /64 unless its northboun= d interface is a point-to-point interface.

Right= , but on a point-point link, one doesn't need the reserved IANA range a= nyway. That /64 is there for the device, and it can map anything into the I= ID, and strictly speaking it doesn't need to be limited to the ranges a= bove.

So in summary, as far as I see it is as follows:
- If we're cove= ring the p2p link case and subtended IPv4 devices, a single /64 is enough a= nd no need of IANA assignments. Whatever the hosts will use is determined b= y the DHCPv4 assignment the clat device will (presumably) give.
- If we're talking about subtended IPv6 devices and sharing a /64, then= the IANA assignment lead to ND hacks, some new form of SLAAC; best left fo= r handling via DHCP PD.

Regards,
Woj.


With this scheme, the only real concern I see is excess= ive use of IID space. If we're not worried about that, then it seems a = good idea to me.

On Mo= n, Sep 10, 2012 at 3:47 PM, R=E9mi Despr=E9s <despres.remi@laposte= .net> wrote:

2012-09-07 =E0 20:32, Wojciech Dec :
...

> It's a basic case of two clat's on a shared /64 both starting/= trying to use one of the "reserved" addresses. It will fail for o= ne.

As already discussed, this isn't true.
- Nothing "fails" (as you say), if CLAT addresses WAN side use II= Ds in a reserved range, and all hosts are standard-compliant (RFC4291).
=A0. CLAT addresses aren't configured on any IPv6-link interface.
=A0. Nothing is needed on the LAN side (DAD or otherwise) to prevent CLAT a= ddresses to be used.
- If some hosts are manually configured with standard-infringing addresses,= many failures are indeed possible. But responsibility isn't that of 46= 4XLAT.

If your doubt would remain after checking the above, a detailed example jus= tifying it would be needed to justify it.

RD

_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops


--047d7b6227d2f8b78c04c9591300-- From wdec.ietf@gmail.com Mon Sep 10 06:40:47 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0B2721F8673 for ; Mon, 10 Sep 2012 06:40:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.869 X-Spam-Level: X-Spam-Status: No, score=-2.869 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zqn764TtnSwx for ; Mon, 10 Sep 2012 06:40:46 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 158BA21F866E for ; Mon, 10 Sep 2012 06:40:45 -0700 (PDT) Received: by eekb45 with SMTP id b45so1182706eek.31 for ; Mon, 10 Sep 2012 06:40:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=k7/CTYZNvPOnrd1BLKA4QlEHkIoK6yxj3fdM4xw30yg=; b=tD4YBVO+nfXyIpv3eB0nBAml8ltObyNOz18SAPLGIf6cq/5tD4jTxzWx1SrYmrS2oz rxVIWpnqjWK5hBckowsfwGzCopcOI7b3B0nBZDO7DE9hdmj2ALonFCEyiZ1WxgcgRjcX HPCQ1K/DvgmFkQOoG4WK2njptzzAQtWWbT00soWYIoaeQe7XDgKzZL4Xx26Rli3gSWD0 TTonwEuF6+7fVGIcRc9S3hbp/RaRL0K2H6ImxstyoFtvsOc/YbK1pMjlVtlOh7lSLTwp h32JQBwumFCl4Od/of2OMFgBu2hIv8piHBuXG7Gi3hsk8mBtFUO9p3L8/3c79CM2tk5z MPqQ== MIME-Version: 1.0 Received: by 10.14.224.4 with SMTP id w4mr19992715eep.21.1347284439357; Mon, 10 Sep 2012 06:40:39 -0700 (PDT) Received: by 10.14.45.68 with HTTP; Mon, 10 Sep 2012 06:40:39 -0700 (PDT) In-Reply-To: References: <810EAE3D-8767-4E66-911D-3DBDFE8B9403@laposte.net> Date: Mon, 10 Sep 2012 15:40:39 +0200 Message-ID: From: Wojciech Dec To: Lorenzo Colitti Content-Type: multipart/alternative; boundary=047d7b6227d26b5a2804c9591a8d Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 13:40:47 -0000 --047d7b6227d26b5a2804c9591a8d Content-Type: text/plain; charset=ISO-8859-1 +1 On 10 September 2012 11:41, Lorenzo Colitti wrote: > On Sat, Sep 8, 2012 at 12:00 AM, Maoke wrote: > >> my suggestion: >> >> "464xlat is not designed to cover the case of IPv4-only applications >> having access to IPv6-only servers, which will be possibly needed in the >> future. Together using it with BIH [RFC6535] can be a feasible solution, if >> this demand becomes true, and we leave the details of the co-existance to >> the implemantaion. >> > > I still disagree with this text, because it gives the impression that > using BIH with 464xlat is a best practice, when in fact nobody has even > tested it yet. What about the original suggestion of saying that "464xlat > is not designed to cover the case of IPv4-only applications having access > to IPv6-only servers. If that is needed, another transition mechanism such > as BIH must be employed" ? > > By doing so, BIH continue to not be used together with a NAT64, as >> recommended in [RFC6535], while 464xlat is being in charge of using NAT64s >> as PLATs." >> > > The way I read that sentence is, "There's a NAT64 in the architecture, and > the BIH packets can go through that NAT64, but we're not using BIH with a > NAT64. We're not because we say we're not. Really." That's pretty bad. We > need to at least say thatif BIH is used, then it SHOULD NOT be used through > the NAT64? > > I still don't see why BIH appears in this document at all. There's no > reason to cite it. It's an RFC. People can implement it, deploy it, > whatever - without us having to cite it in this RFC. There are lots of > things you can use with CLAT, like IP-in-UDP-tunneling. But we're not > putting IP-in-UDP-tunneling in this document. Why? > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --047d7b6227d26b5a2804c9591a8d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1

On 10 September 2012 11:41, Lorenzo Co= litti <lorenzo@google.com> wrote:
On Sat, Sep 8, 2012 at 12:00 AM, Maoke = <fibrib@gmail.com<= /a>> wrote:
my suggestion:=A0

"464xlat is not = designed to cover the case of IPv4-only applications having access to IPv6-= only servers, which will be possibly needed in the future. Together using i= t with BIH [RFC6535] can be a feasible solution, if this demand becomes tru= e, and we leave the details of the co-existance to the implemantaion.


By doing so, BIH = continue to not be used together with a NAT64, as recommended in [RFC6535],= while 464xlat is being in charge of using NAT64s as PLATs."

The way I read that sentence is, &qu= ot;There's a NAT64 in the architecture, and the BIH packets can go thro= ugh that NAT64, but we're not using BIH with a NAT64. We're not bec= ause we say we're not. Really."=A0That's pretty bad. We need t= o at least say thatif BIH is used, then it SHOULD NOT be used through the N= AT64?

I still don't see why BIH appears in this document = at all. There's no reason to cite it. It's an RFC. People can imple= ment it, deploy it, whatever - without us having to cite it in this RFC. Th= ere are lots of things you can use with CLAT, like IP-in-UDP-tunneling. But= we're not putting IP-in-UDP-tunneling in this document. Why?

_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops


--047d7b6227d26b5a2804c9591a8d-- From fibrib@gmail.com Mon Sep 10 06:43:44 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3579C21F84F1 for ; Mon, 10 Sep 2012 06:43:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.165 X-Spam-Level: X-Spam-Status: No, score=-3.165 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6iC9diPKP4T8 for ; Mon, 10 Sep 2012 06:43:43 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2871D21F84DF for ; Mon, 10 Sep 2012 06:43:43 -0700 (PDT) Received: by eekb45 with SMTP id b45so1185768eek.31 for ; Mon, 10 Sep 2012 06:43:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=G88cUiU/nKUh+cwM7jI2MfjN6dCvQw1YEqk0KcFB0u0=; b=Uzy2SkAqBEtGvoshy5REruR3l4H4oo72J/gHJr8hd+kRgO/5wMx1az+LWohruvajhC a5xRrwzuSRiFJZj8q8J5DNZbHv2k03Nh8ERi2F0LJH1n2orSgJ72VffDg5oEDuU/PgOK NOkHbHFxXlOsUadqnrOL76O+YUPguMWqZDROGJwSVJYbV8OYi9+4ki+70CxglMUHnD8S YKEPZRh+xoLZFbRsLNz+gEN7Ah1JAvrxgn/7bjqq6n9v6rSiFME24RNmfrKCF5552UjM UAc8YpPUlo40L+0ei28axgkV6VcwwaHuyvmqXNggEbUT3HmmgLLgFn4SAY7qevoJ2Nky 5sYA== MIME-Version: 1.0 Received: by 10.14.218.134 with SMTP id k6mr19937833eep.14.1347284622372; Mon, 10 Sep 2012 06:43:42 -0700 (PDT) Received: by 10.14.97.9 with HTTP; Mon, 10 Sep 2012 06:43:42 -0700 (PDT) Date: Mon, 10 Sep 2012 22:43:42 +0900 Message-ID: From: Maoke To: v6ops WG Content-Type: multipart/alternative; boundary=047d7b6224c253efa104c959256b Subject: [v6ops] 464xlat WGLC: BIH/CLAT behavior is uncertain X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 13:43:44 -0000 --047d7b6224c253efa104c959256b Content-Type: text/plain; charset=ISO-8859-1 hi all, sorry but raise this topic at the last minute of the last call. i doubt there is really not uncertainty to put BIH with CLAT together. i proposed a case where BIH/CLAT is poorly running for an in-domain server (which is a naturally established use-case of the CLAT without BIH) but it is argued this case is out of scope. however, there is a very detailed discussion, in scope: 1. a host behind the BIH/CLAT is to send out a request to a server, who has both AAAA and A type resolutions. 2. NOTE BIH is working since the stage of DNS because the host behind is possibly IPv4-only. if BIH cannot get an AAAA, it could be silent as there needed double-translation, fine. however, once BIH can get the AAAA type of the server, it traslates that AAAA to an A type resolution with an IPv4 address, i.e., the synthetic IPv4 address, under its configuration. 3. then the host possibly receive two A type resolutions: the one of the genuine A of the server (let's note it as A#1); the one of the synthetic version made by the BIH (A#2). it might randomly select one to send out the request. 4. the request arrives at the BIH/CLAT, uncertainty happens: - who takes over the work? the BIH module or the CLAT module? (not specified yet) - if it is the BIH, but the host actually selects A#1, then BIH has no state about this A#1, it has to drop the request; - if it is the CLAT module, but it happens that the host choose A#2, then the CLAT will send the request to nowhere. i don't know what we still need to make the *combination* of BIH and 464xlat safe in this document. according to this observation and the discussion above, i suggest modifying the last paragraph of Section 1 to the following (d) and revise other text regarding the BIH. (d) 464xlat is not designed to cover the case of IPv4-only applications having access to IPv6-only servers. If that is needed, another transition mechanism is needed. if someone insist to cite BIH, we can add either following (e) or (f) to (d) (e) This BCP doesn't guarantee the integrity of putting 464xlat and BIH[RFC6535] together. If operator would like to do so, we leave the details of the co-existance an open issue. (f) It is not recommended to use 464xlat together with BIH [RFC6535] at the CLAT. - maoke --047d7b6224c253efa104c959256b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
=A0
hi all,
=A0
sorry but raise this to= pic at the last minute of the last call.

i doubt there is re= ally not uncertainty to put BIH with CLAT together. i proposed a case where= BIH/CLAT is poorly running for an in-domain server (which is a naturally e= stablished use-case of the CLAT without BIH) but it is argued this case is = out of scope.

however, there is a very detailed discussion, in scope:

1. a host= behind the BIH/CLAT is to send out a request to a server, who has both AAA= A and A type resolutions.=A0

2. NOTE BIH is working since the stage = of DNS because the host behind is possibly IPv4-only. if BIH cannot get an = AAAA, it could be silent as there needed double-translation, fine. however,= once BIH can get the AAAA type of the server, it traslates that AAAA to an= A type resolution=A0with an IPv4 address,=A0i.e., the synthetic IPv4 addre= ss,=A0under its configuration.

3. then the host possibly receive two A type resolutions: the one of the= genuine A of the server (let's note it as A#1); the one of=A0the=A0syn= thetic version made=A0by the BIH (A#2). it might randomly select one to sen= d out the request.

4. the request arrives at the BIH/CLAT, uncertainty happens:

=A0= =A0=A0 - who takes over the work? the BIH module or the CLAT module? (not s= pecified yet)

=A0=A0=A0 - if it is the BIH, but the host actually s= elects A#1, then BIH has no state about this A#1, it has to drop the reques= t;

=A0=A0=A0 - if it is the CLAT module, but it happens that the host cho= ose A#2, then the CLAT will send the request to nowhere.=A0
=A0<= /div>
i don't know what we still need to make the *combination* of = BIH and 464xlat safe in this document.
=A0
=A0
according to this observation and the disc= ussion above, i suggest modifying the last paragraph of=A0Section 1=A0to th= e following (d) and revise other text regarding the BIH.
=A0
(d)
=A0
=A0=A0 464xlat is not designed to cover the case of IP= v4-only applications
=A0=A0 having access to IPv6-only servers. = If that is needed, another transition
=A0=A0=A0mechanism is need= ed.
=A0
if someone insist to cite BIH, we can add either following (e= ) or (f) to (d)
=A0
(e)
=A0
=A0 T= his BCP doesn't guarantee the integrity=A0of putting 464xlat and BIH[RF= C6535]
=A0 together. If=A0operator would like to do so, we leave the=A0detail= s of the=A0co-existance
=A0 an open issue.
=A0
(f)
=A0=A0It is not recommended to use 464xlat together with B= IH [RFC6535] at the CLAT.
=A0
- maoke
--047d7b6224c253efa104c959256b-- From despres.remi@laposte.net Mon Sep 10 07:02:06 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4525321F856F for ; Mon, 10 Sep 2012 07:02:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.426 X-Spam-Level: X-Spam-Status: No, score=-1.426 tagged_above=-999 required=5 tests=[AWL=0.522, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXBLFxI0fr6a for ; Mon, 10 Sep 2012 07:02:05 -0700 (PDT) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.12]) by ietfa.amsl.com (Postfix) with ESMTP id F3F2E21F8510 for ; Mon, 10 Sep 2012 07:02:04 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2211.sfr.fr (SMTP Server) with ESMTP id 313387000156; Mon, 10 Sep 2012 16:02:04 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2211.sfr.fr (SMTP Server) with ESMTP id 820817000151; Mon, 10 Sep 2012 16:02:03 +0200 (CEST) X-SFR-UUID: 20120910140203532.820817000151@msfrf2211.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-45--388664187 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Mon, 10 Sep 2012 16:02:03 +0200 Message-Id: <1795093C-91EB-4FE2-864E-88343EB40BFA@laposte.net> References: <810EAE3D-8767-4E66-911D-3DBDFE8B9403@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 14:02:06 -0000 --Apple-Mail-45--388664187 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Le 2012-09-10 =C3=A0 15:25, Maoke a =C3=A9crit : > =20 > 2012/9/10 R=C3=A9mi Despr=C3=A9s >=20 > Le 2012-09-10 =C3=A0 14:22, Maoke a =C3=A9crit : >=20 >>=20 >>=20 >> =E5=9C=A8 2012=E5=B9=B49=E6=9C=8810=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=80= =EF=BC=8CR=C3=A9mi Despr=C3=A9s =E5=86=99=E9=81=93=EF=BC=9A >>=20 >> 2012-09-10 12:26, Maoke : >>=20 >>>=20 >>> 2012/9/10 Lorenzo Colitti >>> ... What about the original suggestion of saying that "464xlat is = not designed to cover the case of IPv4-only applications having access = to IPv6-only servers. If that is needed, another transition mechanism = such as BIH must be employed" ? >>> =20 >>> =20 >>> i share the same feeling. and i support your this suggestion. +1 >>=20 >> +1 >> (As said in another mail, this sentence is one of those I accept.) >>=20 >> Now that there is an agreement between Lorenzo, you and me. >> Let's hope it will be final this time. >>=20 >> not yet until you have answered me about the uncertainty just = discovered. i guess you truncated the message too quickly.. - maoke=20 >=20 > Is this to mean that you +1, and support of Lorenzo's suggestion, = wasn't real? > If yes that's a disappointment. > =20 > =20 > i have a modified version. you may see if it is acceptable. on the = other hand, i think you hold the same technical faith as i do that, if = we find it is wrong, even at the last minute, we should correct. (*) Sorry, I am lost. Which is the sentence you now accept? (And I am disappointed to discover that, in the same mail, you expressed = an agreement and had further text which, you later said, needs = resolution before your agreement is valid.) > I didn't react to your further comments because I felt it wasn't = necessary for the conclusion to be acceptable, and I am currently busy = on too many subjects.=20 > =20 > =20 > i see this displomatic, sorry. but i can understand you are busy. It wasn't diplomatic. I was really hoping not to study the very detailed example you have = documented for Lorenzo. > This isn't to say I won't react later on but, when you have agreed on = a sentence, it would be nice if you wouldn't retract your agreement when = someone else agrees too. > =20 > =20 > i still agree that sentence but i think that is not yet comprehensive = enough. see my suggested modification. Which one? (see (*) above) > Now, BIH is standard track. If 464XLAT would conflict with it, 464XLAT = should be modified to avoid that. (Fortunately, this isn't the case.)=20 > =20 > =20 > i argued that 464xlat should be running independently. BIH cannot be = running together with 464xlat is not the fault of the original 464xlat. = don't cut feet to fit the shoes. are you suggest me to insist adding a = text stating: NOT TO USE BIH with 464xlat? Yes, they "should be running independently". It is FALSE that BIH cannot run together with 464XLAT. (I will soon = comment the example you provided as a reason for FUD against this = running together).=20 I wish I hadn't seen the last sentence. RD > =20 > - maoke > =20 > =20 >=20 >=20 > RD >=20 > =20 >=20 > =20 >> =20 >>=20 >> RD >>=20 >>=20 >=20 >=20 --Apple-Mail-45--388664187 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
 
2012/9/10 R=C3=A9mi Despr=C3=A9s <despres.remi@laposte.net>

Le 2012-09-10 =C3=A0 = 14:22, Maoke a =C3=A9crit :



=E5=9C=A8 2012=E5=B9=B49=E6=9C=8810=E6=97=A5=E6=98=9F= =E6=9C=9F=E4=B8=80=EF=BC=8CR=C3=A9mi Despr=C3=A9s = =E5=86=99=E9=81=93=EF=BC=9A

2012-09-10 12:26, = Maoke :


2012/9/10 = Lorenzo Colitti <lorenzo@google.com>
... What about the original suggestion of saying that "464xlat is = not designed to cover the case of IPv4-only applications having access = to IPv6-only servers. If that is needed, another transition mechanism = such as BIH must be employed" ?
 
 
i share the = same feeling. and i support your this suggestion. +1 =

+1
(As said in = another mail, this sentence is one of those I accept.)

Now that there is an agreement = between Lorenzo, you and me.
Let's hope it will be final = this time.

not yet = until you have answered me about the uncertainty just discovered. i = guess you truncated the message too quickly.. - maoke 

Is this to mean that you +1, and = support of Lorenzo's suggestion, wasn't real?
If yes that's a = disappointment.
 
 
=
i have a modified version. you may see if it is acceptable. on the = other hand, i think you hold the same technical faith as i do that, if = we find it is wrong, even at the last minute, we should correct. =

(*)
Sorry, I am = lost.
Which is the sentence you now = accept?

(And I am disappointed to discover = that, in the same mail, you expressed an agreement and had further text = which, you later said, needs resolution before your agreement is = valid.)



I didn't react to your further = comments because I felt it wasn't necessary for the conclusion to be = acceptable, and I am currently busy on too many subjects. 
 
 
i see this = displomatic, sorry. but i can understand you are busy. =

It wasn't = diplomatic.
I was really hoping not to study the very detailed = example you have documented for Lorenzo.

This isn't to say I won't react = later on but, when you have agreed on a sentence, it would be nice if = you wouldn't retract your agreement when someone else agrees too.
 
 
i still agree = that sentence but i think that is not yet comprehensive enough. see my = suggested modification.

Which = one?
(see (*) above)

Now, BIH is standard track. If = 464XLAT would conflict with it, 464XLAT should be modified to avoid = that. (Fortunately, this isn't the = case.) 
 
 
i argued that 464xlat should be running = independently. BIH cannot be running together with 464xlat is not = the fault of the original 464xlat. don't cut feet to fit the = shoes. are you suggest me to insist adding a text = stating: NOT TO USE BIH with = 464xlat?

Yes, they "should = be running independently".
It is FALSE that BIH cannot run = together with 464XLAT. (I will soon comment the example you provided as = a reason for FUD against this running together). 
I wish = I hadn't seen the last = sentence.

RD


 
- maoke
 
=
 


RD

  

 
 

RD





= --Apple-Mail-45--388664187-- From despres.remi@laposte.net Mon Sep 10 07:06:05 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26B6C21F8593 for ; Mon, 10 Sep 2012 07:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.441 X-Spam-Level: X-Spam-Status: No, score=-1.441 tagged_above=-999 required=5 tests=[AWL=0.507, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oYz1RICv0Fb9 for ; Mon, 10 Sep 2012 07:06:04 -0700 (PDT) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.12]) by ietfa.amsl.com (Postfix) with ESMTP id CE5DB21F8510 for ; Mon, 10 Sep 2012 07:06:03 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2211.sfr.fr (SMTP Server) with ESMTP id D7553700014D; Mon, 10 Sep 2012 16:06:02 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2211.sfr.fr (SMTP Server) with ESMTP id 814D770000EC; Mon, 10 Sep 2012 16:06:02 +0200 (CEST) X-SFR-UUID: 20120910140602529.814D770000EC@msfrf2211.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-46--388425392 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Mon, 10 Sep 2012 16:06:01 +0200 Message-Id: References: <810EAE3D-8767-4E66-911D-3DBDFE8B9403@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 14:06:05 -0000 --Apple-Mail-46--388425392 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Maoke, After your insisting that I comment the detailed example below you had = addressed to lorenzo, let me do it first priority, for the sake of = 464XLAT quick progress. Your example has an IPv4-only host that is supposed to get a public A = record and another A record that would be derived from a AAAA by a BIH. This isn't AFAIK a realistic scenario for at least the following = reasons: (1) BIH address mapping doesn't apply when both AAAA and A records are = received and the A address in not an excluded one (section 2.4 of = RFC6535). (2) BIH is only for applications that are in the BIH node itself. As = such, it must not forward AAAA-derived IPv4 addresses to any other node. = (These addresses are taken in a private address pool). RD Le 2012-09-10 =E0 12:26, Maoke a =E9crit : >=20 > 2012/9/10 Lorenzo Colitti > On Sat, Sep 8, 2012 at 12:00 AM, Maoke wrote: > my suggestion:=20 >=20 > "464xlat is not designed to cover the case of IPv4-only applications = having access to IPv6-only servers, which will be possibly needed in the = future. Together using it with BIH [RFC6535] can be a feasible solution, = if this demand becomes true, and we leave the details of the = co-existance to the implemantaion. >=20 > I still disagree with this text, because it gives the impression that = using BIH with 464xlat is a best practice, when in fact nobody has even = tested it yet. What about the original suggestion of saying that = "464xlat is not designed to cover the case of IPv4-only applications = having access to IPv6-only servers. If that is needed, another = transition mechanism such as BIH must be employed" ? > =20 > =20 > i share the same feeling. and i support your this suggestion. +1 > =20 >=20 > =20 > By doing so, BIH continue to not be used together with a NAT64, as = recommended in [RFC6535], while 464xlat is being in charge of using = NAT64s as PLATs." >=20 > The way I read that sentence is, "There's a NAT64 in the architecture, = and the BIH packets can go through that NAT64, but we're not using BIH = with a NAT64. We're not because we say we're not. Really." That's pretty = bad. We need to at least say thatif BIH is used, then it SHOULD NOT be = used through the NAT64? > =20 > =20 > i also doubt there is really not uncertainty to put BIH with CLAT = together. i proposed a case where BIH/CLAT is poorly running for an = in-domain server (which is a naturally established use-case of the CLAT = without BIH) but it is argued this case is out of scope. > =20 > so it is sounds to me that people prefer to attach this weird BIH with = CLAT, even sacrifycing the possibly extended scope of usage. > =20 > on the other hand, as i have seen that the *combination* is harmful at = least for one case, even it is out of scope, i doubt there is definitely = no in-scope trouble of this putting-together. > =20 > a very detailed discussion is here:=20 > =20 > 1. a host behind the BIH/CLAT is to send out a request to a server, = who has both AAAA and A type resolutions. =20 > 2. NOTE BIH is working since the stage of DNS because the host behind = is possibly IPv4-only. if BIH cannot get an AAAA, it could be silent as = there needed double-translation, fine. however, once BIH can get the = AAAA type of the server, it traslates that AAAA to an A type resolution = with an IPv4 address under its configuration. > 3. then the host possibly receive two A type resolutions: the one of = the genuine A of the server (let's note it as A#1); the one of what is = translated by the BIH (A#2). it might randomly select one to send out = the request. > 4. the request arrives at the BIH/CLAT, uncertainty happens: > - who take over the work? the BIH module or the CLAT module? > - if it is the BIH, but the host actually selects A#1, then BIH = has no state about this A#1, it has to drop the request; > - if it is the CLAT module, but it happens that the host choose = A#2, then the CLAT will send the request to nowhere. =20 > =20 > i don't know what we still need to make the *combination* of BIH and = 464xlat safe in this document. > =20 > =20 > I still don't see why BIH appears in this document at all. There's no = reason to cite it. It's an RFC. People can implement it, deploy it, = whatever - without us having to cite it in this RFC. There are lots of = things you can use with CLAT, like IP-in-UDP-tunneling. But we're not = putting IP-in-UDP-tunneling in this document. Why? >=20 > same view. but they argued that we are newcomers claiming, too late, = at a *trivial* question already *well*-discussed in the WG and the = authors also would like to push the things forward. :( if the above = uncertainty is certain, the working group is making a mistake. > =20 > - maoke --Apple-Mail-46--388425392 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

2012/9/10 Lorenzo Colitti <lorenzo@google.com>
On Sat, Sep 8, 2012 at 12:00 AM, Maoke <fibrib@gmail.com> wrote:
my suggestion: 

"464xlat is not = designed to cover the case of IPv4-only applications having access to = IPv6-only servers, which will be possibly needed in the future. Together = using it with BIH [RFC6535] can be a feasible solution, if this demand = becomes true, and we leave the details of the co-existance to the = implemantaion.

I still disagree with this text, = because it gives the impression that using BIH with 464xlat is a best = practice, when in fact nobody has even tested it yet. What about the = original suggestion of saying that "464xlat is not designed to cover the = case of IPv4-only applications having access to IPv6-only servers. If = that is needed, another transition mechanism such as BIH must be = employed" ?
 
 
i share the = same feeling. and i support your this suggestion. +1 =
 

 
By doing so, BIH continue to not be used together with a NAT64, = as recommended in [RFC6535], while 464xlat is being in charge of using = NAT64s as PLATs."

The way I read that sentence is, = "There's a NAT64 in the architecture, and the BIH packets can go through = that NAT64, but we're not using BIH with a NAT64. We're not because we = say we're not. Really." That's pretty bad. We need to at least say = thatif BIH is used, then it SHOULD NOT be used through the NAT64?
 
 
i also doubt = there is really not uncertainty to put BIH with CLAT together. i = proposed a case where BIH/CLAT is = poorly running for an in-domain server (which is a = naturally established use-case of the CLAT without BIH) but = it is argued this case is out of scope.
 
so it is sounds to me that people prefer to attach = this weird BIH with CLAT, even sacrifycing the possibly extended scope = of usage.
 
on the other hand, as i have seen = that the *combination* is harmful at least for one case, even it is out = of scope, i doubt there is definitely no in-scope trouble of this = putting-together.
 
a very detailed discussion is = here: 
 
1. a host behind the BIH/CLAT is = to send out a request to a server, who has both AAAA and A type = resolutions.  
2. NOTE BIH is working since the stage of = DNS because the host behind is possibly IPv4-only. if BIH cannot get an = AAAA, it could be silent as there needed double-translation, = fine. however, once BIH can get the AAAA type of the = server, it traslates that AAAA to an A type resolution with an IPv4 = address under its configuration.
3. then the host possibly receive two A type resolutions: the one = of the genuine A of the server (let's note it as A#1); the one of what = is translated by the BIH (A#2). it might randomly select one to send out = the request.
4. the request arrives at the BIH/CLAT, uncertainty = happens:
    - who take over the work? the BIH = module or the CLAT module?
    - if it is the = BIH, but the host actually selects A#1, then BIH has no state about this = A#1, it has to drop the request;
    - if it is the CLAT module, = but it happens that the host choose A#2, then = the CLAT will send the request to nowhere. =  
 
i don't know what we still need to = make the *combination* of BIH and 464xlat safe in this document.
 
 
I still don't see why BIH = appears in this document at all. There's no reason to cite it. It's an = RFC. People can implement it, deploy it, whatever - without us having to = cite it in this RFC. There are lots of things you can use with CLAT, = like IP-in-UDP-tunneling. But we're not putting IP-in-UDP-tunneling in = this document. Why?

same view. but they argued that we are = newcomers claiming, too late, at a *trivial* question already = *well*-discussed in the WG and the authors also would like to push the = things forward. :( if the above uncertainty is certain, the working = group is making a mistake.
 
- maoke

= --Apple-Mail-46--388425392-- From fibrib@gmail.com Mon Sep 10 07:29:25 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34B1D21F8699 for ; Mon, 10 Sep 2012 07:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.848 X-Spam-Level: X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d7qn5r2cPxtz for ; Mon, 10 Sep 2012 07:29:24 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id AC59B21F867E for ; Mon, 10 Sep 2012 07:29:23 -0700 (PDT) Received: by wibhr14 with SMTP id hr14so1689505wib.13 for ; Mon, 10 Sep 2012 07:29:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ooDM+CE122EdjlMu410W82xE5iJiexkDcBQhS8RJFHE=; b=IHiv17vdpHMat4z6tYfiZ2WSNFl66L7p4w4Zw5V3exAtn6KHvdFpkbsqAkgVug3V80 3vxtcvygJu9GzX8KUJ61Ch9nTj6406MoFE9AfHyHbMvVbGgBI0WwhVy+6GwlqPxlY8Wn JxXMUr+6iI/R3VRu6d6hb7NYoQIGosdCRd+bmOeZ7dgj8fTeF+//4y6p9Vd+vxSHqbaS NkaQDn83Lhs9clX/Kc6rbszhAZx7v5MIbkuZVi/ZuI16noPsF/w3SAzUAp8mv2kR+VO5 FM5L3E2o6EAtqNE4hHa8IfRnhKEDOL8gdtmDR53rub74hTe98aqWd7OfPx6DnvzjRZmt RcTQ== MIME-Version: 1.0 Received: by 10.180.109.129 with SMTP id hs1mr17678555wib.0.1347287362627; Mon, 10 Sep 2012 07:29:22 -0700 (PDT) Received: by 10.223.37.78 with HTTP; Mon, 10 Sep 2012 07:29:22 -0700 (PDT) In-Reply-To: References: <810EAE3D-8767-4E66-911D-3DBDFE8B9403@laposte.net> Date: Mon, 10 Sep 2012 23:29:22 +0900 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=e89a8f13ea88a8e9c504c959c873 Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 14:29:25 -0000 --e89a8f13ea88a8e9c504c959c873 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/9/10 R=E9mi Despr=E9s > Maoke, > > After your insisting that I comment the detailed example below you had > addressed to lorenzo, let me do it first priority, for the sake of 464XLA= T > quick progress. > > i reply Lorenzo but cc to the WG and i suppose that the text that i would like to share to all. thanks a lot for taking it in priority. > > > Your example has an IPv4-only host that is supposed to get a public A > record and another A record that would be derived from a AAAA by a BIH. > This isn't AFAIK a realistic scenario for at least the following reasons: > (1) BIH address mapping doesn't apply when both AAAA and A records are > received and the A address in not an excluded one (section 2.4 of RFC6535= ). > > thanks for the link of the text. i didn't notice that. but this only prevents CLAT sending things to A#2. what if the packet is delivered to the BIH module? actually the missing part is, when we are talking "combining" two things, we should at least specify they are working parallel, selected by the path decision mechanism, or serially. if parallel, how to select the path; if serial, who is in front who is behind? > > (2) BIH is only for applications that are in the BIH node itself. As such= , > it must not forward AAAA-derived IPv4 addresses to any other node. (These > addresses are taken in a private address pool). > > confusing to me. CLAT is able to work for a subnet where the hosts are. what the applications does the BIH/CLAT box itself have in the 464xlat architecture. and according to the discussion linked by Gang to me, there was the discussion that people said the BIH was not designed for forwarding but replies stated it was able to do so. - maoke > > > RD > > Le 2012-09-10 =E0 12:26, Maoke a =E9crit : > > > 2012/9/10 Lorenzo Colitti > >> On Sat, Sep 8, 2012 at 12:00 AM, Maoke wrote: >> >>> my suggestion: >>> >>> "464xlat is not designed to cover the case of IPv4-only applications >>> having access to IPv6-only servers, which will be possibly needed in th= e >>> future. Together using it with BIH [RFC6535] can be a feasible solution= , if >>> this demand becomes true, and we leave the details of the co-existance = to >>> the implemantaion. >>> >> >> I still disagree with this text, because it gives the impression that >> using BIH with 464xlat is a best practice, when in fact nobody has even >> tested it yet. What about the original suggestion of saying that "464xla= t >> is not designed to cover the case of IPv4-only applications having acces= s >> to IPv6-only servers. If that is needed, another transition mechanism su= ch >> as BIH must be employed" ? >> >> > > i share the same feeling. and i support your this suggestion. +1 > > >> >> >> >>> By doing so, BIH continue to not be used together with a NAT64, as >>> recommended in [RFC6535], while 464xlat is being in charge of using NAT= 64s >>> as PLATs." >>> >> >> The way I read that sentence is, "There's a NAT64 in the architecture, >> and the BIH packets can go through that NAT64, but we're not using BIH w= ith >> a NAT64. We're not because we say we're not. Really." That's pretty bad.= We >> need to at least say thatif BIH is used, then it SHOULD NOT be used thro= ugh >> the NAT64? >> >> > > i also doubt there is really not uncertainty to put BIH with CLAT > together. i proposed a case where BIH/CLAT is poorly running for an > in-domain server (which is a naturally established use-case of the CLAT > without BIH) but it is argued this case is out of scope. > > so it is sounds to me that people prefer to attach this weird BIH with > CLAT, even sacrifycing the possibly extended scope of usage. > > on the other hand, as i have seen that the *combination* is harmful at > least for one case, even it is out of scope, i doubt there is definitely = no > in-scope trouble of this putting-together. > > a very detailed discussion is here: > > 1. a host behind the BIH/CLAT is to send out a request to a server, who > has both AAAA and A type resolutions. > 2. NOTE BIH is working since the stage of DNS because the host behind is > possibly IPv4-only. if BIH cannot get an AAAA, it could be silent as ther= e > needed double-translation, fine. however, once BIH can get the AAAA type > of the server, it traslates that AAAA to an A type resolution with an IPv= 4 > address under its configuration. > 3. then the host possibly receive two A type resolutions: the one of the > genuine A of the server (let's note it as A#1); the one of what is > translated by the BIH (A#2). it might randomly select one to send out the > request. > 4. the request arrives at the BIH/CLAT, uncertainty happens: > - who take over the work? the BIH module or the CLAT module? > - if it is the BIH, but the host actually selects A#1, then BIH has n= o > state about this A#1, it has to drop the request; > - if it is the CLAT module, but it happens that the host choose A#2, > then the CLAT will send the request to nowhere. > > i don't know what we still need to make the *combination* of BIH and > 464xlat safe in this document. > > >> >> I still don't see why BIH appears in this document at all. There's no >> reason to cite it. It's an RFC. People can implement it, deploy it, >> whatever - without us having to cite it in this RFC. There are lots of >> things you can use with CLAT, like IP-in-UDP-tunneling. But we're not >> putting IP-in-UDP-tunneling in this document. Why? >> > > same view. but they argued that we are newcomers claiming, too late, at > a *trivial* question already *well*-discussed in the WG and the authors > also would like to push the things forward. :( if the above uncertainty i= s > certain, the working group is making a mistake. > > - maoke > > > --e89a8f13ea88a8e9c504c959c873 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
2012/9/10 R=E9mi Despr=E9s <despres.= remi@laposte.net>
Maoke,

After your in= sisting that I comment the detailed example below you had addressed to lore= nzo,=A0let me do it first priority, for the sake of 464XLAT quick progress.=
=A0
=A0
i reply Lorenzo but cc = to the WG and i suppose that the text that i would like to share to all. th= anks a lot for taking it in priority.
=A0
=A0

Your = example has an IPv4-only host that is supposed to get a public A record and= another A record that would be derived from =A0a AAAA by a BIH.
= This isn't AFAIK a realistic scenario for at least the following reason= s:
(1)=A0BIH address mapping doesn't apply when both AAAA and A recor= ds are received and the A address in not an excluded one (section 2.4 of RF= C6535).
=A0
=A0
thanks for= the link of the text. i didn't notice that. but this only prevents CLA= T sending things to A#2. what if the packet is delivered to the BIH module?=
=A0
actually the missing part is, when we are talking "= combining" two things, we should at least specify they are working par= allel, selected by the path decision mechanism, or serially. if parallel, h= ow to select the path; if serial, who is in front who is behind?
=A0
=A0=
(2)=A0BIH is only for applications that are in the BIH node itself. As= such, it must not forward AAAA-derived IPv4 addresses to any other node. (= These addresses are taken in a private address pool).
=A0
=A0
confusing to me. CLAT is able to work for a= subnet where the hosts are. what the applications does the BIH/CLAT box it= self have=A0in the 464xlat architecture.
=A0
and accor= ding to the discussion linked by Gang to me, there was the discussion that = people said the BIH was not designed for forwarding but replies stated it w= as able to do so.
=A0
- maoke
=A0
=A0

RD

Le 2012-09-10 = =E0 12:26, Maoke a =E9crit :


2012/9/10 Lorenzo Colitti <lor= enzo@google.com>
On Sat, Sep 8, 2012 at 12:00 AM, Maoke <fibrib@gmail.com> wrote:
my suggestion:=A0

"464xlat is not = designed to cover the case of IPv4-only applications having access to IPv6-= only servers, which will be possibly needed in the future. Together using i= t with BIH [RFC6535] can be a feasible solution, if this demand becomes tru= e, and we leave the details of the co-existance to the implemantaion.

I still disagree with this text, bec= ause it gives the impression that using BIH with 464xlat is a best practice= , when in fact nobody has even tested it yet. What about the original sugge= stion of saying that "464xlat is not designed to cover the case of IPv= 4-only applications having access to IPv6-only servers. If that is needed, = another transition mechanism such as BIH must be employed" ?
=A0
=A0
i share the same feelin= g. and i support your this suggestion. +1
=A0

=A0
By doing so, BIH continue to not be used together with a NAT64, as r= ecommended in [RFC6535], while 464xlat is being in charge of using NAT64s a= s PLATs."

The way I read that sentence is, &qu= ot;There's a NAT64 in the architecture, and the BIH packets can go thro= ugh that NAT64, but we're not using BIH with a NAT64. We're not bec= ause we say we're not. Really."=A0That's pretty bad. We need t= o at least say thatif BIH is used, then it SHOULD NOT be used through the N= AT64?
=A0
=A0
i also doubt there is r= eally not uncertainty to put BIH with=A0CLAT together. i proposed a case wh= ere BIH/CLAT=A0is poorly=A0running=A0for=A0an in-domain server=A0(which is = a naturally established=A0use-case of the CLAT without BIH) but it=A0is arg= ued this case is out of scope.
=A0
so it is sounds to me that people prefer to attach this = weird BIH with CLAT, even sacrifycing the possibly extended scope of usage.=
=A0
on the other hand, as i have seen that the *combi= nation* is harmful at least for one case, even it is out of scope, i doubt = there is definitely no in-scope trouble of this putting-together.
=A0
a very detailed discussion is here:=A0
=A0
1. a host behind the BIH/CLAT is to send out a request to a server,= =A0who has both AAAA and A type resolutions. =A0
2. NOTE BIH is w= orking since the stage of DNS because the host behind is possibly IPv4-only= . if BIH cannot get an AAAA, it could be silent as there needed=A0double-tr= anslation, fine.=A0however, once=A0BIH can get=A0the AAAA type of=A0the ser= ver, it traslates that AAAA to an A type resolution with an IPv4 address un= der its configuration.
3. then the host possibly receive two A type resolutions: the one of t= he genuine A of the server (let's note it as A#1); the one of what is t= ranslated by the BIH (A#2). it might randomly select one to send out the re= quest.
4. the request arrives at the BIH/CLAT, uncertainty happens:
=A0=A0=A0 - who take over the work? the BIH module or the CLAT module?
=A0=A0=A0 - if it is the BIH, but the host actually selects A#1, the= n BIH has no state about this A#1, it has to drop the request;
=A0=A0=A0 - if it is the CLAT module, but=A0it=A0happens=A0that the ho= st=A0choose=A0A#2, then the CLAT will send the=A0request to nowhere. =A0
=A0
i don't know what we still need to make the *comb= ination* of BIH and 464xlat safe in this document.
=A0
=A0
I still don't see why BIH appears in this document at all. There'= s no reason to cite it. It's an RFC. People can implement it, deploy it= , whatever - without us having to cite it in this RFC. There are lots of th= ings you can use with CLAT, like IP-in-UDP-tunneling. But we're not put= ting IP-in-UDP-tunneling in this document. Why?

same view. but they argued that we are newcomer= s claiming, too late, at a=A0*trivial*=A0question already *well*-discussed = in the WG and the authors also would like to push the things forward. :( if= the above uncertainty is certain, the working group is making a mistake. <= /div>
=A0
- maoke


--e89a8f13ea88a8e9c504c959c873-- From fibrib@gmail.com Mon Sep 10 07:36:57 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3F8E21F8699 for ; Mon, 10 Sep 2012 07:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.872 X-Spam-Level: X-Spam-Status: No, score=-2.872 tagged_above=-999 required=5 tests=[AWL=0.426, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hmHYJPxv2zCo for ; Mon, 10 Sep 2012 07:36:55 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 40BBE21F852A for ; Mon, 10 Sep 2012 07:36:55 -0700 (PDT) Received: by wibhr14 with SMTP id hr14so1698114wib.13 for ; Mon, 10 Sep 2012 07:36:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rJTQ0LtGNmNmucVmT1ztJ99TdeYfI+EOaxb9Kuzg91o=; b=RBe5nSuisHgh7/1NxWcceAbQ7Hvljpwzd6pEufSn13vJroBx9AiQOK3yqntt+B1UdK YaDV2wklhH2wrBPpURuCFdPq7qx63UKK4poHfwRNnsa9htbYt2uogyHxeXN/QyMWtWVA 4mHvnBlRxrWe4EPVLf36qI2XRCDHqa6Ktv6GDhhVmiCC7EWQJcIGrBASTfhYJ9qy6VB2 xJc9CZnQYZqmYS2RmibztDYrYHLEyb//U1ST6GcxFIAGMxhrAr9ciyGH3Xa/AvqXPzu1 tTIH7jh0Hck/FO7kZkYcyzwmwCXT5eVxhGOuLCQzlfrj2pJWFNB9l9Y0DYnIf2Xb9UFD zStg== MIME-Version: 1.0 Received: by 10.180.109.129 with SMTP id hs1mr17722464wib.0.1347287813937; Mon, 10 Sep 2012 07:36:53 -0700 (PDT) Received: by 10.223.37.78 with HTTP; Mon, 10 Sep 2012 07:36:53 -0700 (PDT) In-Reply-To: References: <810EAE3D-8767-4E66-911D-3DBDFE8B9403@laposte.net> Date: Mon, 10 Sep 2012 23:36:53 +0900 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=e89a8f13ea888f5ae204c959e3b0 Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 14:36:57 -0000 --e89a8f13ea888f5ae204c959e3b0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/9/10 Maoke > > 2012/9/10 R=E9mi Despr=E9s > >> Maoke, >> >> After your insisting that I comment the detailed example below you had >> addressed to lorenzo, let me do it first priority, for the sake of 464XL= AT >> quick progress. >> >> > > i reply Lorenzo but cc to the WG and i suppose that the text that i would > like to share to all. thanks a lot for taking it in priority. > > >> >> >> Your example has an IPv4-only host that is supposed to get a public A >> record and another A record that would be derived from a AAAA by a BIH. >> This isn't AFAIK a realistic scenario for at least the following reasons= : >> (1) BIH address mapping doesn't apply when both AAAA and A records are >> received and the A address in not an excluded one (section 2.4 of RFC653= 5). >> >> > > thanks for the link of the text. i didn't notice that. but this only > prevents CLAT sending things to A#2. what if the packet is delivered to t= he > BIH module? > > i mean: what if the packet with destination A#1 has been delivered to BIH module? - maoke > > > actually the missing part is, when we are talking "combining" two things, > we should at least specify they are working parallel, selected by the pat= h > decision mechanism, or serially. if parallel, how to select the path; if > serial, who is in front who is behind? > > >> >> (2) BIH is only for applications that are in the BIH node itself. As >> such, it must not forward AAAA-derived IPv4 addresses to any other node. >> (These addresses are taken in a private address pool). >> >> > > confusing to me. CLAT is able to work for a subnet where the hosts are. > what the applications does the BIH/CLAT box itself have in the 464xlat > architecture. > > and according to the discussion linked by Gang to me, there was the > discussion that people said the BIH was not designed for forwarding but > replies stated it was able to do so. > > - maoke > > >> >> >> RD >> >> Le 2012-09-10 =E0 12:26, Maoke a =E9crit : >> >> >> 2012/9/10 Lorenzo Colitti >> >>> On Sat, Sep 8, 2012 at 12:00 AM, Maoke wrote: >>> >>>> my suggestion: >>>> >>>> "464xlat is not designed to cover the case of IPv4-only applications >>>> having access to IPv6-only servers, which will be possibly needed in t= he >>>> future. Together using it with BIH [RFC6535] can be a feasible solutio= n, if >>>> this demand becomes true, and we leave the details of the co-existance= to >>>> the implemantaion. >>>> >>> >>> I still disagree with this text, because it gives the impression that >>> using BIH with 464xlat is a best practice, when in fact nobody has even >>> tested it yet. What about the original suggestion of saying that "464xl= at >>> is not designed to cover the case of IPv4-only applications having acce= ss >>> to IPv6-only servers. If that is needed, another transition mechanism s= uch >>> as BIH must be employed" ? >>> >>> >> >> i share the same feeling. and i support your this suggestion. +1 >> >> >>> >>> >>> >>>> By doing so, BIH continue to not be used together with a NAT64, as >>>> recommended in [RFC6535], while 464xlat is being in charge of using NA= T64s >>>> as PLATs." >>>> >>> >>> The way I read that sentence is, "There's a NAT64 in the architecture, >>> and the BIH packets can go through that NAT64, but we're not using BIH = with >>> a NAT64. We're not because we say we're not. Really." That's pretty bad= . We >>> need to at least say thatif BIH is used, then it SHOULD NOT be used thr= ough >>> the NAT64? >>> >>> >> >> i also doubt there is really not uncertainty to put BIH with CLAT >> together. i proposed a case where BIH/CLAT is poorly running for an >> in-domain server (which is a naturally established use-case of the CLAT >> without BIH) but it is argued this case is out of scope. >> >> so it is sounds to me that people prefer to attach this weird BIH with >> CLAT, even sacrifycing the possibly extended scope of usage. >> >> on the other hand, as i have seen that the *combination* is harmful at >> least for one case, even it is out of scope, i doubt there is definitely= no >> in-scope trouble of this putting-together. >> >> a very detailed discussion is here: >> >> 1. a host behind the BIH/CLAT is to send out a request to a server, who >> has both AAAA and A type resolutions. >> 2. NOTE BIH is working since the stage of DNS because the host behind is >> possibly IPv4-only. if BIH cannot get an AAAA, it could be silent as the= re >> needed double-translation, fine. however, once BIH can get the AAAA type >> of the server, it traslates that AAAA to an A type resolution with an IP= v4 >> address under its configuration. >> 3. then the host possibly receive two A type resolutions: the one of the >> genuine A of the server (let's note it as A#1); the one of what is >> translated by the BIH (A#2). it might randomly select one to send out th= e >> request. >> 4. the request arrives at the BIH/CLAT, uncertainty happens: >> - who take over the work? the BIH module or the CLAT module? >> - if it is the BIH, but the host actually selects A#1, then BIH has >> no state about this A#1, it has to drop the request; >> - if it is the CLAT module, but it happens that the host choose A#2, >> then the CLAT will send the request to nowhere. >> >> i don't know what we still need to make the *combination* of BIH and >> 464xlat safe in this document. >> >> >>> >>> I still don't see why BIH appears in this document at all. There's no >>> reason to cite it. It's an RFC. People can implement it, deploy it, >>> whatever - without us having to cite it in this RFC. There are lots of >>> things you can use with CLAT, like IP-in-UDP-tunneling. But we're not >>> putting IP-in-UDP-tunneling in this document. Why? >>> >> >> same view. but they argued that we are newcomers claiming, too late, at >> a *trivial* question already *well*-discussed in the WG and the authors >> also would like to push the things forward. :( if the above uncertainty = is >> certain, the working group is making a mistake. >> >> - maoke >> >> >> > --e89a8f13ea888f5ae204c959e3b0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/9/10 Maoke <fibrib@gmail.com>= ;

2012/9/10 R=E9mi Despr=E9s= <despres.remi@laposte.net>
Maoke,

After your in= sisting that I comment the detailed example below you had addressed to lore= nzo,=A0let me do it first priority, for the sake of 464XLAT quick progress.=
=A0
=A0
i reply Lorenzo b= ut cc to the WG and i suppose that the text that i would like to share to a= ll. thanks a lot for taking it in priority.
= =A0
=A0

Your = example has an IPv4-only host that is supposed to get a public A record and= another A record that would be derived from =A0a AAAA by a BIH.
= This isn't AFAIK a realistic scenario for at least the following reason= s:
(1)=A0BIH address mapping doesn't apply when both AAAA and A recor= ds are received and the A address in not an excluded one (section 2.4 of RF= C6535).
=A0
=A0
than= ks for the link of the text. i didn't notice that. but this only preven= ts CLAT sending things to A#2. what if the packet is delivered to the BIH m= odule?
=A0
=A0
i mean: what if the pac= ket with destination A#1 has been delivered to BIH module? - maoke
=A0
=A0
=A0
actually the missing part is, when we are talking "= combining" two things, we should at least specify they are working par= allel, selected by the path decision mechanism, or serially. if parallel, h= ow to select the path; if serial, who is in front who is behind?
=A0
=A0=
(2)=A0BIH is only for applications that are in the BIH node itself. As= such, it must not forward AAAA-derived IPv4 addresses to any other node. (= These addresses are taken in a private address pool).
=A0
=A0
confusing to me. CLAT is able to work= for a subnet where the hosts are. what the applications does the BIH/CLAT = box itself have=A0in the 464xlat architecture.
=A0
and= according to the discussion linked by Gang to me, there was the discussion= that people said the BIH was not designed for forwarding but replies state= d it was able to do so.
=A0
- maoke
= =A0
=A0

RD

Le 2012-09-10 = =E0 12:26, Maoke a =E9crit :

<= br>
2012/9/10 Lorenzo Colitti &= lt;lorenzo@google.c= om>
On Sat, Sep 8, 2012 at 12:00 AM, Maoke <fibrib@gmail.com> wrote:
my suggestion:=A0

"464xlat is not = designed to cover the case of IPv4-only applications having access to IPv6-= only servers, which will be possibly needed in the future. Together using i= t with BIH [RFC6535] can be a feasible solution, if this demand becomes tru= e, and we leave the details of the co-existance to the implemantaion.

I still disagree with this text, bec= ause it gives the impression that using BIH with 464xlat is a best practice= , when in fact nobody has even tested it yet. What about the original sugge= stion of saying that "464xlat is not designed to cover the case of IPv= 4-only applications having access to IPv6-only servers. If that is needed, = another transition mechanism such as BIH must be employed" ?
=A0
=A0
i share the same feelin= g. and i support your this suggestion. +1
=A0

=A0
By doing so, BIH continue to not be used together with a NAT64, as r= ecommended in [RFC6535], while 464xlat is being in charge of using NAT64s a= s PLATs."

The way I read that sentence is, &qu= ot;There's a NAT64 in the architecture, and the BIH packets can go thro= ugh that NAT64, but we're not using BIH with a NAT64. We're not bec= ause we say we're not. Really."=A0That's pretty bad. We need t= o at least say thatif BIH is used, then it SHOULD NOT be used through the N= AT64?
=A0
=A0
i also doubt there is r= eally not uncertainty to put BIH with=A0CLAT together. i proposed a case wh= ere BIH/CLAT=A0is poorly=A0running=A0for=A0an in-domain server=A0(which is = a naturally established=A0use-case of the CLAT without BIH) but it=A0is arg= ued this case is out of scope.
=A0
so it is sounds to me that people prefer to attach this = weird BIH with CLAT, even sacrifycing the possibly extended scope of usage.=
=A0
on the other hand, as i have seen that the *combi= nation* is harmful at least for one case, even it is out of scope, i doubt = there is definitely no in-scope trouble of this putting-together.
=A0
a very detailed discussion is here:=A0
=A0
1. a host behind the BIH/CLAT is to send out a request to a server,= =A0who has both AAAA and A type resolutions. =A0
2. NOTE BIH is w= orking since the stage of DNS because the host behind is possibly IPv4-only= . if BIH cannot get an AAAA, it could be silent as there needed=A0double-tr= anslation, fine.=A0however, once=A0BIH can get=A0the AAAA type of=A0the ser= ver, it traslates that AAAA to an A type resolution with an IPv4 address un= der its configuration.
3. then the host possibly receive two A type resolutions: the one of t= he genuine A of the server (let's note it as A#1); the one of what is t= ranslated by the BIH (A#2). it might randomly select one to send out the re= quest.
4. the request arrives at the BIH/CLAT, uncertainty happens:
=A0=A0=A0 - who take over the work? the BIH module or the CLAT module?
=A0=A0=A0 - if it is the BIH, but the host actually selects A#1, the= n BIH has no state about this A#1, it has to drop the request;
=A0=A0=A0 - if it is the CLAT module, but=A0it=A0happens=A0that the ho= st=A0choose=A0A#2, then the CLAT will send the=A0request to nowhere. =A0
=A0
i don't know what we still need to make the *comb= ination* of BIH and 464xlat safe in this document.
=A0
=A0
I still don't see why BIH appears in this document at all. There'= s no reason to cite it. It's an RFC. People can implement it, deploy it= , whatever - without us having to cite it in this RFC. There are lots of th= ings you can use with CLAT, like IP-in-UDP-tunneling. But we're not put= ting IP-in-UDP-tunneling in this document. Why?

same view. but they argued that we are newcomer= s claiming, too late, at a=A0*trivial*=A0question already *well*-discussed = in the WG and the authors also would like to push the things forward. :( if= the above uncertainty is certain, the working group is making a mistake. <= /div>
=A0
- maoke



--e89a8f13ea888f5ae204c959e3b0-- From fibrib@gmail.com Mon Sep 10 07:42:23 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE8F21F85B4 for ; Mon, 10 Sep 2012 07:42:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.668 X-Spam-Level: X-Spam-Status: No, score=-1.668 tagged_above=-999 required=5 tests=[AWL=-0.820, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xG5oMxMJqnWP for ; Mon, 10 Sep 2012 07:42:22 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id D104B21F8578 for ; Mon, 10 Sep 2012 07:42:21 -0700 (PDT) Received: by wibhr14 with SMTP id hr14so1704320wib.13 for ; Mon, 10 Sep 2012 07:42:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TjlgXkhhXyKGVMrCH4h2sUc/R/+JrqIHjLRRoQvQur8=; b=j/VR2fel4qW4ZhwN6YQEq6tssJCgXt6qCPrQbuggCIGkR+T6HEPc3TAgrug+vjigk6 y/7tNk5i+vVDxmVJnEg7CzVvW00smpZwGjbwHc0cJCQDT9fmBS/aU4dQcl4dVwhuM+16 qxCK/pKw7Dm/S3xqKOR3J7sQe4v87bwq02KoS0VkJrqxCBGcHQDjrOTz8OulUQUrziFV 7zY2RImI7RF3Dr1vzIz7vFu+FmeELzfgqwdkXhAp79DFNJwZB+LlDuHlwNZqWWaa40KO TiyAMtw6y0RcCOgf54EmbNgzoBvPPHkCLoXf7bD7fMf8fwUXn/ZaSb2HtmQ0X9v0DYAi 7ItQ== MIME-Version: 1.0 Received: by 10.216.209.87 with SMTP id r65mr7526978weo.42.1347288140973; Mon, 10 Sep 2012 07:42:20 -0700 (PDT) Received: by 10.223.37.78 with HTTP; Mon, 10 Sep 2012 07:42:20 -0700 (PDT) In-Reply-To: <1795093C-91EB-4FE2-864E-88343EB40BFA@laposte.net> References: <810EAE3D-8767-4E66-911D-3DBDFE8B9403@laposte.net> <1795093C-91EB-4FE2-864E-88343EB40BFA@laposte.net> Date: Mon, 10 Sep 2012 23:42:20 +0900 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=0016e6d6456e0d870204c959f750 Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 14:42:23 -0000 --0016e6d6456e0d870204c959f750 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable 2012/9/10 R=A8=A6mi Despr=A8=A6s > > Le 2012-09-10 =A8=A4 15:25, Maoke a =A8=A6crit : > > > 2012/9/10 R=A8=A6mi Despr=A8=A6s > >> >> Le 2012-09-10 =A8=A4 14:22, Maoke a =A8=A6crit : >> >> >> >> =D4=DA 2012=C4=EA9=D4=C210=C8=D5=D0=C7=C6=DA=D2=BB=A3=ACR=A8=A6mi Despr= =A8=A6s =D0=B4=B5=C0=A3=BA >> >>> >>> 2012-09-10 12:26, Maoke : >>> >>> >>> 2012/9/10 Lorenzo Colitti >>> >>>> ... What about the original suggestion of saying that "464xlat is not >>>> designed to cover the case of IPv4-only applications having access to >>>> IPv6-only servers. If that is needed, another transition mechanism suc= h as >>>> BIH must be employed" ? >>>> >>>> >>> >>> i share the same feeling. and i support your this suggestion. +1 >>> >>> >>> +1 >>> (As said in another mail, this sentence is one of those I accept.) >>> >>> Now that there is an agreement between Lorenzo, you and me. >>> Let's hope it will be final this time. >>> >> >> not yet until you have answered me about the uncertainty just discovered= . >> i guess you truncated the message too quickly.. - maoke >> >> >> Is this to mean that you +1, and support of Lorenzo's suggestion, wasn't >> real? >> If yes that's a disappointment. >> >> > > i have a modified version. you may see if it is acceptable. on the other > hand, i think you hold the same technical faith as i do that, if we find = it > is wrong, even at the last minute, we should correct. > > > (*) > Sorry, I am lost. > Which is the sentence you now accept? > > well. sorry for the confusion. i has clarified my concern and suggested text in a separated thread. - maoke > > > (And I am disappointed to discover that, in the same mail, you expressed > an agreement and had further text which, you later said, needs resolution > before your agreement is valid.) > > > > I didn't react to your further comments because I felt it wasn't necessar= y >> for the conclusion to be acceptable, and I am currently busy on too many >> subjects. >> >> > > i see this displomatic, sorry. but i can understand you are busy. > > > It wasn't diplomatic. > I was really hoping not to study the very detailed example you have > documented for Lorenzo. > > > This isn't to say I won't react later on but, when you have agreed on a >> sentence, it would be nice if you wouldn't retract your agreement when >> someone else agrees too. >> >> > > i still agree that sentence but i think that is not yet comprehensive > enough. see my suggested modification. > > > Which one? > (see (*) above) > > Now, BIH is standard track. If 464XLAT would conflict with it, 464XLAT >> should be modified to avoid that. (Fortunately, this isn't the case.) >> >> > > i argued that 464xlat should be running independently. BIH cannot be > running together with 464xlat is not the fault of the original 464xlat. > don't cut feet to fit the shoes. are you suggest me to insist adding a te= xt > stating: NOT TO USE BIH with 464xlat? > > > Yes, they "should be running independently". > It is FALSE that BIH cannot run together with 464XLAT. (I will soon > comment the example you provided as a reason for FUD against this running > together). > I wish I hadn't seen the last sentence. > > RD > > > > - maoke > > >> >> >> >> RD >> >> >> >> >> >> >> >>> >>> RD >>> >>> >>> >> > > --0016e6d6456e0d870204c959f750 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable

2012/9/10 R=A8=A6mi Despr=A8=A6s <despres.remi@laposte.net>

Le 2012-09-10 =A8=A4 15:2= 5, Maoke a =A8=A6crit :

 
2012/9/10 R=A8=A6mi Despr= =A8=A6s <despres.remi@laposte.net>

Le 2012= -09-10 =A8=A4 14:22, Maoke a =A8=A6crit :



=D4=DA 2012=C4=EA9=D4=C210=C8= =D5=D0=C7=C6=DA=D2=BB=A3=ACR=A8=A6mi Despr=A8=A6s =D0=B4=B5=C0=A3=BA

2012-09-10 12:26, Maoke :=


2012/9/10 Lore= nzo Colitti <lorenzo@google.com>
... What about the original suggestion of saying that "464xlat is= not designed to cover the case of IPv4-only applications having access to = IPv6-only servers. If that is needed, another transition mechanism such as = BIH must be employed" ?
 
 
i share the same feeling. and i support your this suggestion. +1

+1
(A= s said in another mail, this sentence is one of those I accept.)

Now that there is an agreement between Lorenz= o, you and me.
Let's hope it will be final this time.

not yet = until you have answered me about the uncertainty just discovered. i guess y= ou truncated the message too quickly.. - maoke 

Is this to = mean that you +1, and support of Lorenzo's suggestion, wasn't real?=
If yes that's a disappointment.
 
 
i have a modified version. you may see if it is acceptable. on the oth= er hand, i think you hold the same technical faith as i do that, if we find= it is wrong, even at the last minute, we should correct.

(*)
Sorry, I am lost.
Which is the sentence you now accept?
 
 
well. sorry for the confusion. i has clarified m= y concern and suggested text in a separated thread. - maoke
 
=  

(And I am disappointed to discover that, in the same ma= il, you expressed an agreement and had further text which, you later said, = needs resolution before your agreement is valid.)



I didn't react to your further= comments because I felt it wasn't necessary for the conclusion to be a= cceptable, and I am currently busy on too many subjects. 
 
 
i see this displo= matic, sorry. but i can understand you are busy.
<= div>
It wasn't diplomatic.
I was really hoping= not to study the very detailed example you have documented for Lorenzo.

This isn't to say I won't react later on but, when you have ag= reed on a sentence, it would be nice if you wouldn't retract your agree= ment when someone else agrees too.
 
 
i still agree tha= t sentence but i think that is not yet comprehensive enough. see my suggest= ed modification.

Which one?
(see (*) above)

<= div class=3D"gmail_quote">
Now, BIH is standard track. If 464= XLAT would conflict with it, 464XLAT should be modified to avoid that. (For= tunately, this isn't the case.) 
 
 
i argued that 464xlat should be running independ= ently. BIH cannot be running together with 464xlat is not the fault of= the original 464xlat. don't cut feet to fit the shoes. are y= ou suggest me to insist adding a text stating: NOT TO USE BIH wit= h 464xlat?

Yes, they "should be runn= ing independently".
It is FALSE that BIH cannot run together= with 464XLAT. (I will soon comment the example you provided as a reason fo= r FUD against this running together). 
I wish I hadn't seen the last sentence.

R= D


 
- maoke
 
 


RD

=
  

 
 
=

RD






--0016e6d6456e0d870204c959f750-- From despres.remi@laposte.net Mon Sep 10 07:59:21 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4AE121F865D for ; Mon, 10 Sep 2012 07:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.455 X-Spam-Level: X-Spam-Status: No, score=-1.455 tagged_above=-999 required=5 tests=[AWL=0.493, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aHj6NA4S5agp for ; Mon, 10 Sep 2012 07:59:21 -0700 (PDT) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.84]) by ietfa.amsl.com (Postfix) with ESMTP id 1AC2221F859A for ; Mon, 10 Sep 2012 07:59:20 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2414.sfr.fr (SMTP Server) with ESMTP id C4B97700011F; Mon, 10 Sep 2012 16:59:19 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2414.sfr.fr (SMTP Server) with ESMTP id 6DA46700010D; Mon, 10 Sep 2012 16:59:19 +0200 (CEST) X-SFR-UUID: 20120910145919449.6DA46700010D@msfrf2414.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-47--385231443 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Mon, 10 Sep 2012 16:59:15 +0200 Message-Id: References: <810EAE3D-8767-4E66-911D-3DBDFE8B9403@laposte.net> <1795093C-91EB-4FE2-864E-88343EB40BFA@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 14:59:21 -0000 --Apple-Mail-47--385231443 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 2012-09-10 16:42, Maoke : ... >> i have a modified version. you may see if it is acceptable. on the = other hand, i think you hold the same technical faith as i do that, if = we find it is wrong, even at the last minute, we should correct. >=20 > (*) > Sorry, I am lost. > Which is the sentence you now accept? > =20 > =20 > well. sorry for the confusion. i has clarified my concern and = suggested text in a separated thread. - maoke Still lost. Which sentence, on which thread? Thanks, RD --Apple-Mail-47--385231443 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
2012-09-10 16:42, Maoke :
...
i have a modified version. you may see if it is acceptable. on the other hand, i think you hold the same technical faith as i do that, if we find it is wrong, even at the last minute, we should correct.

(*)
Sorry, I am lost.
Which is the sentence you now accept?
 
 
well. sorry for the confusion. i has clarified my concern and suggested text in a separated thread. - maoke

Still lost.
Which sentence, on which thread?

Thanks,
RD


--Apple-Mail-47--385231443-- From fibrib@gmail.com Mon Sep 10 08:19:44 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B05EF21F86F3 for ; Mon, 10 Sep 2012 08:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.854 X-Spam-Level: X-Spam-Status: No, score=-2.854 tagged_above=-999 required=5 tests=[AWL=0.444, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id szuxTld0sZCq for ; Mon, 10 Sep 2012 08:19:44 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 948CD21F86C5 for ; Mon, 10 Sep 2012 08:19:43 -0700 (PDT) Received: by wibhr14 with SMTP id hr14so1750108wib.13 for ; Mon, 10 Sep 2012 08:19:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FNXtKtEnoWqNlclDnGqSQrSuYsc4tHwuyzcUcsMFUEo=; b=LcG538P31GSSC1CZ4zQwDIJK0mmVm7nL/CRgSRY1GjMfY7WLqwe6qToR6L1aOBkGxf oeu6eK531ZhQSsZVxDHQAAP9Vtt7juRR0lIjTfmvlQk1W8d37Jl2e1Oks/R1IIkUKKVh n+OdE5QizbR7ucu8qfs7hdvr23NUtMLjnGIw+rgqKkZVIykRrTVBMwJk9DF20UCcnspD szrrlUOx7WXmKTMbfhRa9qWmgrHABqsEiQxUg9/5APVyeoaXAmOcOyaVMg7wLBvUkBz1 NKfYopmVDg7q/6vBNAbouqFvfNyzCqqqkoG+ay9Trjrzmly1ILfiWCwr0FDrjEXyi6uU yzBQ== MIME-Version: 1.0 Received: by 10.180.104.200 with SMTP id gg8mr17884513wib.14.1347290382630; Mon, 10 Sep 2012 08:19:42 -0700 (PDT) Received: by 10.223.37.78 with HTTP; Mon, 10 Sep 2012 08:19:42 -0700 (PDT) In-Reply-To: References: Date: Tue, 11 Sep 2012 00:19:42 +0900 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=f46d04430404aa805b04c95a7ced Cc: v6ops WG Subject: Re: [v6ops] 464xlat WGLC: BIH/CLAT behavior is uncertain X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 15:19:44 -0000 --f46d04430404aa805b04c95a7ced Content-Type: text/plain; charset=ISO-8859-1 hi Remi, sorry but i didn't explained clearly. here you are. see below my suggestion. (d) + (e) might be acceptable to all. but in the middle, you have clarified that BIH doesn't do the systhesis when A and AAAA are simultaneously resolved. this has not yet reflected in the following text. - maoke 2012/9/10 Maoke > > hi all, > > sorry but raise this topic at the last minute of the last call. > > i doubt there is really not uncertainty to put BIH with CLAT together. i > proposed a case where BIH/CLAT is poorly running for an in-domain server > (which is a naturally established use-case of the CLAT without BIH) but it > is argued this case is out of scope. > > however, there is a very detailed discussion, in scope: > > 1. a host behind the BIH/CLAT is to send out a request to a server, who > has both AAAA and A type resolutions. > > 2. NOTE BIH is working since the stage of DNS because the host behind is > possibly IPv4-only. if BIH cannot get an AAAA, it could be silent as there > needed double-translation, fine. however, once BIH can get the AAAA type of > the server, it traslates that AAAA to an A type resolution with an IPv4 > address, i.e., the synthetic IPv4 address, under its configuration. > > 3. then the host possibly receive two A type resolutions: the one of the > genuine A of the server (let's note it as A#1); the one of the synthetic > version made by the BIH (A#2). it might randomly select one to send out the > request. > > 4. the request arrives at the BIH/CLAT, uncertainty happens: > - who takes over the work? the BIH module or the CLAT module? (not > specified yet) > > - if it is the BIH, but the host actually selects A#1, then BIH has no > state about this A#1, it has to drop the request; > - if it is the CLAT module, but it happens that the host choose A#2, > then the CLAT will send the request to nowhere. > > i don't know what we still need to make the *combination* of BIH and > 464xlat safe in this document. > > > according to this observation and the discussion above, i suggest > modifying the last paragraph of Section 1 to the following (d) and revise > other text regarding the BIH. > > (d) > > 464xlat is not designed to cover the case of IPv4-only applications > having access to IPv6-only servers. If that is needed, another > transition > mechanism is needed. > > if someone insist to cite BIH, we can add either following (e) or (f) to > (d) > > (e) > > This BCP doesn't guarantee the integrity of putting 464xlat and > BIH[RFC6535] > together. If operator would like to do so, we leave the details of > the co-existance > an open issue. > > (f) > It is not recommended to use 464xlat together with BIH [RFC6535] at the > CLAT. > > - maoke > --f46d04430404aa805b04c95a7ced Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
hi Remi,
=A0
sorry but i didn't explained cle= arly. here you are. see below my suggestion. (d) + (e) might be acceptable = to all. but in the middle, you have clarified that BIH doesn't do the s= ysthesis when A and AAAA are simultaneously resolved. this has not yet refl= ected in the following text.
=A0
- maoke

2012/9/1= 0 Maoke <fibrib@gmail.com>
=A0
hi all,
=A0
sorry but raise this to= pic at the last minute of the last call.

i doubt there is re= ally not uncertainty to put BIH with CLAT together. i proposed a case where= BIH/CLAT is poorly running for an in-domain server (which is a naturally e= stablished use-case of the CLAT without BIH) but it is argued this case is = out of scope.

however, there is a very detailed discussion, in scope:

1. a host= behind the BIH/CLAT is to send out a request to a server, who has both AAA= A and A type resolutions.=A0

2. NOTE BIH is working since the stage = of DNS because the host behind is possibly IPv4-only. if BIH cannot get an = AAAA, it could be silent as there needed double-translation, fine. however,= once BIH can get the AAAA type of the server, it traslates that AAAA to an= A type resolution=A0with an IPv4 address,=A0i.e., the synthetic IPv4 addre= ss,=A0under its configuration.

3. then the host possibly receive two A type resolutions: the one of the= genuine A of the server (let's note it as A#1); the one of=A0the=A0syn= thetic version made=A0by the BIH (A#2). it might randomly select one to sen= d out the request.

4. the request arrives at the BIH/CLAT, uncertainty happens:

=A0= =A0=A0 - who takes over the work? the BIH module or the CLAT module? (not s= pecified yet)

=A0=A0=A0 - if it is the BIH, but the host actually s= elects A#1, then BIH has no state about this A#1, it has to drop the reques= t;

=A0=A0=A0 - if it is the CLAT module, but it happens that the host cho= ose A#2, then the CLAT will send the request to nowhere.=A0
=A0<= /div>
i don't know what we still need to make the *combination* of = BIH and 464xlat safe in this document.
=A0
=A0
according to this observation and the disc= ussion above, i suggest modifying the last paragraph of=A0Section 1=A0to th= e following (d) and revise other text regarding the BIH.
=A0
(d)
=A0
=A0=A0 464xlat is not designed to cover the case of IP= v4-only applications
=A0=A0 having access to IPv6-only servers. = If that is needed, another transition
=A0=A0=A0mechanism is need= ed.
=A0
if someone insist to cite BIH, we can add either following (e= ) or (f) to (d)
=A0
(e)
=A0
=A0 T= his BCP doesn't guarantee the integrity=A0of putting 464xlat and BIH[RF= C6535]
=A0 together. If=A0operator would like to do so, we leave the=A0detail= s of the=A0co-existance
=A0 an open issue.
=A0
(f)
=A0=A0It is not recommended to use 464xlat together with B= IH [RFC6535] at the CLAT.
=A0
- maoke

--f46d04430404aa805b04c95a7ced-- From despres.remi@laposte.net Mon Sep 10 08:24:27 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E922D21F86C5 for ; Mon, 10 Sep 2012 08:24:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.468 X-Spam-Level: X-Spam-Status: No, score=-1.468 tagged_above=-999 required=5 tests=[AWL=0.480, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 84C-9ZDGc2ZW for ; Mon, 10 Sep 2012 08:24:27 -0700 (PDT) Received: from smtp25.services.sfr.fr (smtp25.services.sfr.fr [93.17.128.119]) by ietfa.amsl.com (Postfix) with ESMTP id DACA421F86F3 for ; Mon, 10 Sep 2012 08:24:26 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2509.sfr.fr (SMTP Server) with ESMTP id 6AFC170000E6; Mon, 10 Sep 2012 17:24:25 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2509.sfr.fr (SMTP Server) with ESMTP id E46F970000E4; Mon, 10 Sep 2012 17:24:24 +0200 (CEST) X-SFR-UUID: 20120910152424935.E46F970000E4@msfrf2509.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-48--383724605 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Mon, 10 Sep 2012 17:24:22 +0200 Message-Id: <4730A653-CD11-4A08-9254-2C80C739D646@laposte.net> References: <810EAE3D-8767-4E66-911D-3DBDFE8B9403@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 15:24:28 -0000 --Apple-Mail-48--383724605 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 2012-09-10 16:29, Maoke : >=20 > 2012/9/10 R=E9mi Despr=E9s > Maoke, >=20 > After your insisting that I comment the detailed example below you had = addressed to lorenzo, let me do it first priority, for the sake of = 464XLAT quick progress. > =20 > =20 > i reply Lorenzo but cc to the WG and i suppose that the text that i = would like to share to all. thanks a lot for taking it in priority. > =20 > =20 >=20 > Your example has an IPv4-only host that is supposed to get a public A = record and another A record that would be derived from a AAAA by a BIH. > This isn't AFAIK a realistic scenario for at least the following = reasons: > (1) BIH address mapping doesn't apply when both AAAA and A records are = received and the A address in not an excluded one (section 2.4 of = RFC6535). > =20 > =20 > thanks for the link of the text. i didn't notice that. but this only = prevents CLAT sending things to A#2. what if the packet is delivered to = the BIH module? BIH doesn't apply AT ALL when both an A and a AAAA are received for a = server. Your example being AFAIK in this case, no conflict between BIH and = anything else can exist.=20 > =20 > actually the missing part is, when we are talking "combining" two = things, we should at least specify they are working parallel, selected = by the path decision mechanism, or serially. if parallel, how to select = the path; if serial, who is in front who is behind? 464XLAT applies to reach public IPv4 addresses, and BIH to reach servers = that have no public IPv4 address. The order in which their applicability is tested is therefore = irrelevant. > (2) BIH is only for applications that are in the BIH node itself. As = such, it must not forward AAAA-derived IPv4 addresses to any other node. = (These addresses are taken in a private address pool). > =20 > =20 > confusing to me. CLAT is able to work for a subnet where the hosts = are. what the applications does the BIH/CLAT box itself have in the = 464xlat architecture. Let's leave this aside, at least for the time being, the point above = being sufficient (if you authorize me to work withy high priority only = on points that condition decisions to be made ;-)) =20 > =20 > and according to the discussion linked by Gang to me, there was the = discussion that people said the BIH was not designed for forwarding but = replies stated it was able to do so. Can we please limit this discussion about what BIH does to what there is = in the RFC itself (at least in a first step, which hopefully will be = sufficient). RD --Apple-Mail-48--383724605 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

2012/9/10 R=E9mi Despr=E9s <despres.remi@laposte.net>
Maoke,

After your = insisting that I comment the detailed example below you had addressed to = lorenzo, let me do it first priority, for the sake of 464XLAT quick = progress.
 
 
i reply = Lorenzo but cc to the WG and i suppose that the text that i would like = to share to all. thanks a lot for taking it in priority. =
 
 

Your = example has an IPv4-only host that is supposed to get a public A record = and another A record that would be derived from  a AAAA by a = BIH.
This isn't AFAIK a realistic scenario for at least the = following reasons:
(1) BIH address mapping doesn't apply when both AAAA and A = records are received and the A address in not an excluded one (section = 2.4 of = RFC6535).
 
 
t= hanks for the link of the text. i didn't notice that. but this only = prevents CLAT sending things to A#2. what if the packet is delivered to = the BIH module?

BIH doesn't = apply AT ALL when both an A and a AAAA are received for a = server.
Your example being AFAIK in this case, no conflict = between BIH and anything else can exist. 

 
actually the missing part is, when we are talking = "combining" two things, we should at least specify they are working = parallel, selected by the path decision mechanism, or serially. if = parallel, how to select the path; if serial, who is in front who is = behind?

464XLAT applies to = reach public IPv4 addresses, and BIH to reach servers that have no = public IPv4 address.
The order in which their applicability is = tested is therefore irrelevant.


(2) BIH is only for applications that are in the BIH node = itself. As such, it must not forward AAAA-derived IPv4 addresses to any = other node. (These addresses are taken in a private address = pool).
 
 
confusing to me. CLAT is able to work = for a subnet where the hosts are. what the applications does the = BIH/CLAT box itself have in the 464xlat architecture. =

Let's leave this aside, at least = for the time being, the point above being sufficient (if you authorize = me to work withy high priority only on points that condition decisions = to be made ;-))
 
 
and according to the = discussion linked by Gang to me, there was the discussion that people = said the BIH was not designed for forwarding but replies stated it was = able to do so.

Can we = please limit this discussion about what BIH does to what there = is in the RFC itself (at least in a first step, which hopefully will be = sufficient).

RD


= --Apple-Mail-48--383724605-- From fibrib@gmail.com Mon Sep 10 08:34:46 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFFC921F8717 for ; Mon, 10 Sep 2012 08:34:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.036 X-Spam-Level: X-Spam-Status: No, score=-3.036 tagged_above=-999 required=5 tests=[AWL=0.262, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O1OVv0OEESUA for ; Mon, 10 Sep 2012 08:34:46 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8765221F8718 for ; Mon, 10 Sep 2012 08:34:45 -0700 (PDT) Received: by weyu54 with SMTP id u54so1403240wey.31 for ; Mon, 10 Sep 2012 08:34:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=L/V3EUHPFY4t2OSHBuTuSH2tVbQ4bByCHVC6Sd6pN/8=; b=nh1gIF4K66e1lSxnRXC+TOygcQV+amgh5CPzkgqNxse6fd6+LDQGh096VGw7RLedyO /7ykAVXZiUCjRmryI4rdlpUevzBYyLJNJPprn/HpHgRCjyTAIN2obIvfl0cCPjbXPXWz VjhMwpZSX8x/1Ve2KHeswrNeGCRcNcmPGly5yK6B6tOtOeuVzM7dp1J03TLSSa7lena8 dllWCt26acjTMlnFF3q4cuIhwDpHf6exu9yftPwuJsNtPRPbQwnY90EwxPB6JBUJ6r3o 5Sa/hMcQo+GaK+JV57QJfwM4rW7zOtjSp2GLRAzFUgicmiuRJ6WbcTrMnsdHLFhwFJLe u8ZA== MIME-Version: 1.0 Received: by 10.180.77.34 with SMTP id p2mr18049500wiw.0.1347291284573; Mon, 10 Sep 2012 08:34:44 -0700 (PDT) Received: by 10.223.37.78 with HTTP; Mon, 10 Sep 2012 08:34:44 -0700 (PDT) In-Reply-To: <4730A653-CD11-4A08-9254-2C80C739D646@laposte.net> References: <810EAE3D-8767-4E66-911D-3DBDFE8B9403@laposte.net> <4730A653-CD11-4A08-9254-2C80C739D646@laposte.net> Date: Tue, 11 Sep 2012 00:34:44 +0900 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=f46d043c7dd46d0f0a04c95ab26e Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 15:34:46 -0000 --f46d043c7dd46d0f0a04c95ab26e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/9/11 R=E9mi Despr=E9s > > 2012-09-10 16:29, Maoke : > > > 2012/9/10 R=E9mi Despr=E9s > >> Maoke, >> >> After your insisting that I comment the detailed example below you had >> addressed to lorenzo, let me do it first priority, for the sake of 464XL= AT >> quick progress. >> >> > > i reply Lorenzo but cc to the WG and i suppose that the text that i would > like to share to all. thanks a lot for taking it in priority. > > >> >> >> Your example has an IPv4-only host that is supposed to get a public A >> record and another A record that would be derived from a AAAA by a BIH. >> This isn't AFAIK a realistic scenario for at least the following reasons= : >> (1) BIH address mapping doesn't apply when both AAAA and A records are >> received and the A address in not an excluded one (section 2.4 of RFC653= 5). >> >> > > thanks for the link of the text. i didn't notice that. but this only > prevents CLAT sending things to A#2. what if the packet is delivered to t= he > BIH module? > > > BIH doesn't apply AT ALL when both an A and a AAAA are received for a > server. > Your example being AFAIK in this case, no conflict between BIH and > anything else can exist. > > > actually the missing part is, when we are talking "combining" two things, > we should at least specify they are working parallel, selected by the pat= h > decision mechanism, or serially. if parallel, how to select the path; if > serial, who is in front who is behind? > > > 464XLAT applies to reach public IPv4 addresses, and BIH to reach servers > that have no public IPv4 address. > > the first DNS request is taken by BIH or by 464xlat? it is highly possible to be 464xlat, no matter the result is A or AAAA, right? how the BIH can get the information about that AAAA and/or A? the path seems to me has no business with the BIH though. if i missed anything, please specify further. it is fine to me that the below is left aside. - maoke > > The order in which their applicability is tested is therefore irrelevant. > > > (2) BIH is only for applications that are in the BIH node itself. As >> such, it must not forward AAAA-derived IPv4 addresses to any other node. >> (These addresses are taken in a private address pool). >> >> > > confusing to me. CLAT is able to work for a subnet where the hosts are. > what the applications does the BIH/CLAT box itself have in the 464xlat > architecture. > > > Let's leave this aside, at least for the time being, the point above bein= g > sufficient (if you authorize me to work withy high priority only on point= s > that condition decisions to be made ;-)) > > > > and according to the discussion linked by Gang to me, there was the > discussion that people said the BIH was not designed for forwarding but > replies stated it was able to do so. > > > Can we please limit this discussion about what BIH does to what there is > in the RFC itself (at least in a first step, which hopefully will be > sufficient). > > RD > > > --f46d043c7dd46d0f0a04c95ab26e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/9/11 R=E9mi Despr=E9s <desp= res.remi@laposte.net>

2012-09-10 16:29, Maoke :=


2012/9/10 R=E9mi Despr=E9s <despres.remi@laposte.net&= gt;
Maoke,

After your in= sisting that I comment the detailed example below you had addressed to lore= nzo,=A0let me do it first priority, for the sake of 464XLAT quick progress.=
=A0
=A0
i reply Lorenzo but cc = to the WG and i suppose that the text that i would like to share to all. th= anks a lot for taking it in priority.
=A0
=A0

Your = example has an IPv4-only host that is supposed to get a public A record and= another A record that would be derived from =A0a AAAA by a BIH.
= This isn't AFAIK a realistic scenario for at least the following reason= s:
(1)=A0BIH address mapping doesn't apply when both AAAA and A recor= ds are received and the A address in not an excluded one (section 2.4 of RF= C6535).
=A0
=A0
thanks for= the link of the text. i didn't notice that. but this only prevents CLA= T sending things to A#2. what if the packet is delivered to the BIH module?=

BIH doesn't apply AT ALL w= hen both an A and a AAAA are received for a server.
Your example = being AFAIK in this case, no conflict between BIH and anything else can exi= st.=A0

=A0
actually the missing part is, when we are talking "= combining" two things, we should at least specify they are working par= allel, selected by the path decision mechanism, or serially. if parallel, h= ow to select the path; if serial, who is in front who is behind?

464XLAT applies to reach publi= c IPv4 addresses, and BIH to reach servers that have no public IPv4 address= .
=A0
=A0
the first = DNS request is taken by BIH or by 464xlat? it is highly possible to=A0be 46= 4xlat, no matter the result is A or AAAA, right? how the BIH can get the in= formation about that AAAA and/or A? the path seems to me has no business wi= th the BIH though.
=A0
if i missed anything, please specify further. it is fine= to me that the below is left aside.
=A0
- maoke
=
=A0
=A0
The order in wh= ich their applicability is tested is therefore irrelevant.


(2)=A0BIH is only for applications that are in the BIH node itself. As= such, it must not forward AAAA-derived IPv4 addresses to any other node. (= These addresses are taken in a private address pool).
=A0
=A0
confusing to me. CLAT is able to work for a= subnet where the hosts are. what the applications does the BIH/CLAT box it= self have=A0in the 464xlat architecture.

Let's leave this aside, at least for the time being, the po= int above being sufficient (if you authorize me to work withy high priority= only on points that condition decisions to be made ;-))
=A0
=A0
<= div>and according to the discussion linked by Gang to me, there was the dis= cussion that people said the BIH was not designed for forwarding but replie= s stated it was able to do so.

Can we please=A0limit this=A0d= iscussion about what BIH does to what there is in the RFC itself (at least = in a first step, which hopefully will be sufficient).

RD



--f46d043c7dd46d0f0a04c95ab26e-- From phdgang@gmail.com Mon Sep 10 08:35:43 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 881BB21F86F2 for ; Mon, 10 Sep 2012 08:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.357 X-Spam-Level: X-Spam-Status: No, score=-3.357 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JBEvF7R10ig7 for ; Mon, 10 Sep 2012 08:35:42 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 649AF21F86F3 for ; Mon, 10 Sep 2012 08:35:42 -0700 (PDT) Received: by vbbfc26 with SMTP id fc26so829855vbb.31 for ; Mon, 10 Sep 2012 08:35:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=3AxUOPwcecEt3ZryUr+aMazmUJg+nnNl1YZITbE7NO0=; b=vasoHuqY6Uazuwxa4OGahqbaWuA9Fpf2wVVYpAeX+clVthRzbzkikBoxNeDUh6kQqG b0gbB24NkG4Lwt0eengv8HG19fzUt+6Yv7OOfIHGw0k8aNuugKrbFbCBr43n6y7jv108 bCkBzgazkI+yBMm8kMsO188MwytNMpS2gp68wzndROzpe1Q+iXwYj7EW9dnicxZ2Fai7 L9ja1suFutGwDghuqEO6+Ofp1K8zZcpN5uoI32Q0Tf06+6v1WhkoHRh2CZvBrshaNui8 AJieJhc4HghMFFQ0qfAKzHpB91IZKNu/QovxXm5m0AwQDgrdI02CEBzcIfAnvzwnRKU3 SDRw== MIME-Version: 1.0 Received: by 10.220.157.16 with SMTP id z16mr20151021vcw.29.1347291341689; Mon, 10 Sep 2012 08:35:41 -0700 (PDT) Received: by 10.58.114.231 with HTTP; Mon, 10 Sep 2012 08:35:41 -0700 (PDT) In-Reply-To: References: <810EAE3D-8767-4E66-911D-3DBDFE8B9403@laposte.net> Date: Mon, 10 Sep 2012 23:35:41 +0800 Message-ID: From: GangChen To: Maoke Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 15:35:43 -0000 2012/9/10, Maoke : > 2012/9/10 R=E9mi Despr=E9s > >> Maoke, >> >> After your insisting that I comment the detailed example below you had >> addressed to lorenzo, let me do it first priority, for the sake of >> 464XLAT >> quick progress. >> >> > > i reply Lorenzo but cc to the WG and i suppose that the text that i would > like to share to all. thanks a lot for taking it in priority. > > >> >> >> Your example has an IPv4-only host that is supposed to get a public A >> record and another A record that would be derived from a AAAA by a BIH. >> This isn't AFAIK a realistic scenario for at least the following reasons= : >> (1) BIH address mapping doesn't apply when both AAAA and A records are >> received and the A address in not an excluded one (section 2.4 of >> RFC6535). >> >> > > thanks for the link of the text. i didn't notice that. but this only > prevents CLAT sending things to A#2. what if the packet is delivered to t= he > BIH module? The packet with destination A#1 would naturally not be processed by BIH, because destination A#1 can't match any item in BIH mapping table. > actually the missing part is, when we are talking "combining" two things, > we should at least specify they are working parallel, selected by the pat= h > decision mechanism, or serially. if parallel, how to select the path; if > serial, who is in front who is behind? > > >> >> (2) BIH is only for applications that are in the BIH node itself. As >> such, >> it must not forward AAAA-derived IPv4 addresses to any other node. (Thes= e >> addresses are taken in a private address pool). >> >> > > confusing to me. CLAT is able to work for a subnet where the hosts are. > what the applications does the BIH/CLAT box itself have in the 464xlat > architecture. > > and according to the discussion linked by Gang to me, there was the > discussion that people said the BIH was not designed for forwarding but > replies stated it was able to do so. I hope that is not on-purpose. If that isn't clear to you, I could restate the answers to you. BIH is doing the work only for IPv4 APPLICATION. There is nothing to do with tethered IPv4 HOSTs. In the previous discussion, you are talking about CLAT-CLAT case, which is identified as out of the scope. Gang >> >> >> RD >> >> Le 2012-09-10 =E0 12:26, Maoke a =E9crit : >> >> >> 2012/9/10 Lorenzo Colitti >> >>> On Sat, Sep 8, 2012 at 12:00 AM, Maoke wrote: >>> >>>> my suggestion: >>>> >>>> "464xlat is not designed to cover the case of IPv4-only applications >>>> having access to IPv6-only servers, which will be possibly needed in >>>> the >>>> future. Together using it with BIH [RFC6535] can be a feasible solutio= n, >>>> if >>>> this demand becomes true, and we leave the details of the co-existance >>>> to >>>> the implemantaion. >>>> >>> >>> I still disagree with this text, because it gives the impression that >>> using BIH with 464xlat is a best practice, when in fact nobody has even >>> tested it yet. What about the original suggestion of saying that >>> "464xlat >>> is not designed to cover the case of IPv4-only applications having >>> access >>> to IPv6-only servers. If that is needed, another transition mechanism >>> such >>> as BIH must be employed" ? >>> >>> >> >> i share the same feeling. and i support your this suggestion. +1 >> >> >>> >>> >>> >>>> By doing so, BIH continue to not be used together with a NAT64, as >>>> recommended in [RFC6535], while 464xlat is being in charge of using >>>> NAT64s >>>> as PLATs." >>>> >>> >>> The way I read that sentence is, "There's a NAT64 in the architecture, >>> and the BIH packets can go through that NAT64, but we're not using BIH >>> with >>> a NAT64. We're not because we say we're not. Really." That's pretty bad= . >>> We >>> need to at least say thatif BIH is used, then it SHOULD NOT be used >>> through >>> the NAT64? >>> >>> >> >> i also doubt there is really not uncertainty to put BIH with CLAT >> together. i proposed a case where BIH/CLAT is poorly running for an >> in-domain server (which is a naturally established use-case of the CLAT >> without BIH) but it is argued this case is out of scope. >> >> so it is sounds to me that people prefer to attach this weird BIH with >> CLAT, even sacrifycing the possibly extended scope of usage. >> >> on the other hand, as i have seen that the *combination* is harmful at >> least for one case, even it is out of scope, i doubt there is definitely >> no >> in-scope trouble of this putting-together. >> >> a very detailed discussion is here: >> >> 1. a host behind the BIH/CLAT is to send out a request to a server, who >> has both AAAA and A type resolutions. >> 2. NOTE BIH is working since the stage of DNS because the host behind is >> possibly IPv4-only. if BIH cannot get an AAAA, it could be silent as >> there >> needed double-translation, fine. however, once BIH can get the AAAA type >> of the server, it traslates that AAAA to an A type resolution with an >> IPv4 >> address under its configuration. >> 3. then the host possibly receive two A type resolutions: the one of the >> genuine A of the server (let's note it as A#1); the one of what is >> translated by the BIH (A#2). it might randomly select one to send out th= e >> request. >> 4. the request arrives at the BIH/CLAT, uncertainty happens: >> - who take over the work? the BIH module or the CLAT module? >> - if it is the BIH, but the host actually selects A#1, then BIH has >> no >> state about this A#1, it has to drop the request; >> - if it is the CLAT module, but it happens that the host choose A#2, >> then the CLAT will send the request to nowhere. >> >> i don't know what we still need to make the *combination* of BIH and >> 464xlat safe in this document. >> >> >>> >>> I still don't see why BIH appears in this document at all. There's no >>> reason to cite it. It's an RFC. People can implement it, deploy it, >>> whatever - without us having to cite it in this RFC. There are lots of >>> things you can use with CLAT, like IP-in-UDP-tunneling. But we're not >>> putting IP-in-UDP-tunneling in this document. Why? >>> >> >> same view. but they argued that we are newcomers claiming, too late, at >> a *trivial* question already *well*-discussed in the WG and the authors >> also would like to push the things forward. :( if the above uncertainty >> is >> certain, the working group is making a mistake. >> >> - maoke >> >> >> > From fibrib@gmail.com Mon Sep 10 08:37:13 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A403F21F8712 for ; Mon, 10 Sep 2012 08:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.198 X-Spam-Level: X-Spam-Status: No, score=-3.198 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UAkRtBoFdzba for ; Mon, 10 Sep 2012 08:37:12 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD3621F8711 for ; Mon, 10 Sep 2012 08:37:11 -0700 (PDT) Received: by weyu54 with SMTP id u54so1404940wey.31 for ; Mon, 10 Sep 2012 08:37:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oo9WYIBdm2RiODAe9fwXK2DptS/ROmUuhBfptZl7dVs=; b=BITeS3MlUEHkcUEyTUwXkEKLT+RhBIs6dRHBg9T0jH0BQNq1uR4iXudxD45I9oLI+K +4TCEgENQ2E8JYVeKgMs+bCfGkENtSDJF2IfmKALVpoxWtRberlkRGLZdwrN1VNazG+O DLcDA80+vs61aczqeeHUKI+qGJWSryll/cF6zHaSlumRpeJc+bSLzKC6a8vcDZ+j/nyk hk+T4UocUPzglQg6B06m2Br2Y1nCQhfYU7piUDfDGebCmHnekI6z1omST49F/vWFsc+1 Mx1ZW49vjmG6D1xSqIDHddJNQ2j/PsYwpKdWKJFA7cMDlZtryUYmM5sMYcB28FzqOkNI jQZA== MIME-Version: 1.0 Received: by 10.180.109.129 with SMTP id hs1mr18070635wib.0.1347291430263; Mon, 10 Sep 2012 08:37:10 -0700 (PDT) Received: by 10.223.37.78 with HTTP; Mon, 10 Sep 2012 08:37:10 -0700 (PDT) In-Reply-To: References: <810EAE3D-8767-4E66-911D-3DBDFE8B9403@laposte.net> Date: Tue, 11 Sep 2012 00:37:10 +0900 Message-ID: From: Maoke To: GangChen Content-Type: multipart/alternative; boundary=e89a8f13ea881c1cf804c95abbd1 Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 15:37:13 -0000 --e89a8f13ea881c1cf804c95abbd1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/9/11 GangChen > 2012/9/10, Maoke : > > 2012/9/10 R=E9mi Despr=E9s > > > >> Maoke, > >> > >> After your insisting that I comment the detailed example below you had > >> addressed to lorenzo, let me do it first priority, for the sake of > >> 464XLAT > >> quick progress. > >> > >> > > > > i reply Lorenzo but cc to the WG and i suppose that the text that i wou= ld > > like to share to all. thanks a lot for taking it in priority. > > > > > >> > >> > >> Your example has an IPv4-only host that is supposed to get a public A > >> record and another A record that would be derived from a AAAA by a BI= H. > >> This isn't AFAIK a realistic scenario for at least the following > reasons: > >> (1) BIH address mapping doesn't apply when both AAAA and A records are > >> received and the A address in not an excluded one (section 2.4 of > >> RFC6535). > >> > >> > > > > thanks for the link of the text. i didn't notice that. but this only > > prevents CLAT sending things to A#2. what if the packet is delivered to > the > > BIH module? > > The packet with destination A#1 would naturally not be processed by > BIH, because destination A#1 can't match any item in BIH mapping > table. > > > actually the missing part is, when we are talking "combining" two thing= s, > > we should at least specify they are working parallel, selected by the > path > > decision mechanism, or serially. if parallel, how to select the path; i= f > > serial, who is in front who is behind? > > > > > >> > >> (2) BIH is only for applications that are in the BIH node itself. As > >> such, > >> it must not forward AAAA-derived IPv4 addresses to any other node. > (These > >> addresses are taken in a private address pool). > >> > >> > > > > confusing to me. CLAT is able to work for a subnet where the hosts are. > > what the applications does the BIH/CLAT box itself have in the 464xlat > > architecture. > > > > and according to the discussion linked by Gang to me, there was the > > discussion that people said the BIH was not designed for forwarding but > > replies stated it was able to do so. > > I hope that is not on-purpose. If that isn't clear to you, I could > restate the answers to you. BIH is doing the work only for IPv4 > APPLICATION. There is nothing to do with tethered IPv4 HOSTs. In the > previous discussion, you are talking about CLAT-CLAT case, which is > identified as out of the scope. > in current discussion it is not about CLAT-CLAT and it is in scope. - maoke > > Gang > > >> > >> > >> RD > >> > >> Le 2012-09-10 =E0 12:26, Maoke a =E9crit : > >> > >> > >> 2012/9/10 Lorenzo Colitti > >> > >>> On Sat, Sep 8, 2012 at 12:00 AM, Maoke wrote: > >>> > >>>> my suggestion: > >>>> > >>>> "464xlat is not designed to cover the case of IPv4-only applications > >>>> having access to IPv6-only servers, which will be possibly needed in > >>>> the > >>>> future. Together using it with BIH [RFC6535] can be a feasible > solution, > >>>> if > >>>> this demand becomes true, and we leave the details of the co-existan= ce > >>>> to > >>>> the implemantaion. > >>>> > >>> > >>> I still disagree with this text, because it gives the impression that > >>> using BIH with 464xlat is a best practice, when in fact nobody has ev= en > >>> tested it yet. What about the original suggestion of saying that > >>> "464xlat > >>> is not designed to cover the case of IPv4-only applications having > >>> access > >>> to IPv6-only servers. If that is needed, another transition mechanism > >>> such > >>> as BIH must be employed" ? > >>> > >>> > >> > >> i share the same feeling. and i support your this suggestion. +1 > >> > >> > >>> > >>> > >>> > >>>> By doing so, BIH continue to not be used together with a NAT64, as > >>>> recommended in [RFC6535], while 464xlat is being in charge of using > >>>> NAT64s > >>>> as PLATs." > >>>> > >>> > >>> The way I read that sentence is, "There's a NAT64 in the architecture= , > >>> and the BIH packets can go through that NAT64, but we're not using BI= H > >>> with > >>> a NAT64. We're not because we say we're not. Really." That's pretty > bad. > >>> We > >>> need to at least say thatif BIH is used, then it SHOULD NOT be used > >>> through > >>> the NAT64? > >>> > >>> > >> > >> i also doubt there is really not uncertainty to put BIH with CLAT > >> together. i proposed a case where BIH/CLAT is poorly running for an > >> in-domain server (which is a naturally established use-case of the CLA= T > >> without BIH) but it is argued this case is out of scope. > >> > >> so it is sounds to me that people prefer to attach this weird BIH with > >> CLAT, even sacrifycing the possibly extended scope of usage. > >> > >> on the other hand, as i have seen that the *combination* is harmful at > >> least for one case, even it is out of scope, i doubt there is definite= ly > >> no > >> in-scope trouble of this putting-together. > >> > >> a very detailed discussion is here: > >> > >> 1. a host behind the BIH/CLAT is to send out a request to a server, wh= o > >> has both AAAA and A type resolutions. > >> 2. NOTE BIH is working since the stage of DNS because the host behind = is > >> possibly IPv4-only. if BIH cannot get an AAAA, it could be silent as > >> there > >> needed double-translation, fine. however, once BIH can get the AAAA ty= pe > >> of the server, it traslates that AAAA to an A type resolution with an > >> IPv4 > >> address under its configuration. > >> 3. then the host possibly receive two A type resolutions: the one of t= he > >> genuine A of the server (let's note it as A#1); the one of what is > >> translated by the BIH (A#2). it might randomly select one to send out > the > >> request. > >> 4. the request arrives at the BIH/CLAT, uncertainty happens: > >> - who take over the work? the BIH module or the CLAT module? > >> - if it is the BIH, but the host actually selects A#1, then BIH ha= s > >> no > >> state about this A#1, it has to drop the request; > >> - if it is the CLAT module, but it happens that the host choose A#= 2, > >> then the CLAT will send the request to nowhere. > >> > >> i don't know what we still need to make the *combination* of BIH and > >> 464xlat safe in this document. > >> > >> > >>> > >>> I still don't see why BIH appears in this document at all. There's no > >>> reason to cite it. It's an RFC. People can implement it, deploy it, > >>> whatever - without us having to cite it in this RFC. There are lots o= f > >>> things you can use with CLAT, like IP-in-UDP-tunneling. But we're not > >>> putting IP-in-UDP-tunneling in this document. Why? > >>> > >> > >> same view. but they argued that we are newcomers claiming, too late, a= t > >> a *trivial* question already *well*-discussed in the WG and the author= s > >> also would like to push the things forward. :( if the above uncertaint= y > >> is > >> certain, the working group is making a mistake. > >> > >> - maoke > >> > >> > >> > > > --e89a8f13ea881c1cf804c95abbd1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/9/11 GangChen <= ;phdgang@gmail.com>
2012/9/10, Maoke <fibrib@gmail.com>:
> 2012/9/10 R=E9mi Despr=E9s <despres.remi@laposte.net>
>
>> Maoke,
>>
>> After your insisting that I comment the detailed example below you= had
>> addressed to lorenzo, let me do it first priority, for the sake of=
>> 464XLAT
>> quick progress.
>>
>>
>
> i reply Lorenzo but cc to the WG and i suppose that the text that i wo= uld
> like to share to all. thanks a lot for taking it in priority.
>
>
>>
>>
>> Your example has an IPv4-only host that is supposed to get a publi= c A
>> record and another A record that would be derived from =A0a AAAA b= y a BIH.
>> This isn't AFAIK a realistic scenario for at least the followi= ng reasons:
>> (1) BIH address mapping doesn't apply when both AAAA and A rec= ords are
>> received and the A address in not an excluded one (section 2.4 of<= br> >> RFC6535).
>>
>>
>
> thanks for the link of the text. i didn't notice that. but this on= ly
> prevents CLAT sending things to A#2. what if the packet is delivered t= o the
> BIH module?

The packet with destination A#1 would naturally not be processed by BIH, because destination A#1 can't match any item in BIH mapping
table.

> actually the missing part is, when we are talking "combining"= ; two things,
> we should at least specify they are working parallel, selected by the = path
> decision mechanism, or serially. if parallel, how to select the path; = if
> serial, who is in front who is behind?
>
>
>>
>> (2) BIH is only for applications that are in the BIH node itself. = As
>> such,
>> it must not forward AAAA-derived IPv4 addresses to any other node.= (These
>> addresses are taken in a private address pool).
>>
>>
>
> confusing to me. CLAT is able to work for a subnet where the hosts are= .
> what the applications does the BIH/CLAT box itself have in the 464xlat=
> architecture.
>
> and according to the discussion linked by Gang to me, there was the > discussion that people said the BIH was not designed for forwarding bu= t
> replies stated it was able to do so.

I hope that is not on-purpose. If that isn't clear to you, I coul= d
restate the answers to you. BIH is doing the work only for IPv4
APPLICATION. There is nothing to do with tethered IPv4 HOSTs. In the
previous discussion, you are talking about CLAT-CLAT case, which is
identified as out of the scope.
=A0
in curre= nt discussion it is not about CLAT-CLAT and it is in scope. - maoke
=A0

Gang

>>
>>
>> RD
>>
>> Le 2012-09-10 =E0 12:26, Maoke a =E9crit :
>>
>>
>> 2012/9/10 Lorenzo Colitti <lorenzo@google.com>
>>
>>> On Sat, Sep 8, 2012 at 12:00 AM, Maoke <fibrib@gmail.com> wrote:
>>>
>>>> my suggestion:
>>>>
>>>> "464xlat is not designed to cover the case of IPv4-on= ly applications
>>>> having access to IPv6-only servers, which will be possibly= needed in
>>>> the
>>>> future. Together using it with BIH [RFC6535] can be a feas= ible solution,
>>>> if
>>>> this demand becomes true, and we leave the details of the = co-existance
>>>> to
>>>> the implemantaion.
>>>>
>>>
>>> I still disagree with this text, because it gives the impressi= on that
>>> using BIH with 464xlat is a best practice, when in fact nobody= has even
>>> tested it yet. What about the original suggestion of saying th= at
>>> "464xlat
>>> is not designed to cover the case of IPv4-only applications ha= ving
>>> access
>>> to IPv6-only servers. If that is needed, another transition me= chanism
>>> such
>>> as BIH must be employed" ?
>>>
>>>
>>
>> i share the same feeling. and i support your this suggestion. +1 >>
>>
>>>
>>>
>>>
>>>> =A0By doing so, BIH continue to not be used together with = a NAT64, as
>>>> recommended in [RFC6535], while 464xlat is being in charge= of using
>>>> NAT64s
>>>> as PLATs."
>>>>
>>>
>>> The way I read that sentence is, "There's a NAT64 in = the architecture,
>>> and the BIH packets can go through that NAT64, but we're n= ot using BIH
>>> with
>>> a NAT64. We're not because we say we're not. Really.&q= uot; That's pretty bad.
>>> We
>>> need to at least say thatif BIH is used, then it SHOULD NOT be= used
>>> through
>>> the NAT64?
>>>
>>>
>>
>> i also doubt there is really not uncertainty to put BIH with CLAT<= br> >> together. i proposed a case where BIH/CLAT is poorly running for a= n
>> in-domain server (which is a naturally established use-case of the= CLAT
>> without BIH) but it is argued this case is out of scope.
>>
>> so it is sounds to me that people prefer to attach this weird BIH = with
>> CLAT, even sacrifycing the possibly extended scope of usage.
>>
>> on the other hand, as i have seen that the *combination* is harmfu= l at
>> least for one case, even it is out of scope, i doubt there is defi= nitely
>> no
>> in-scope trouble of this putting-together.
>>
>> a very detailed discussion is here:
>>
>> 1. a host behind the BIH/CLAT is to send out a request to a server= , who
>> has both AAAA and A type resolutions.
>> 2. NOTE BIH is working since the stage of DNS because the host beh= ind is
>> possibly IPv4-only. if BIH cannot get an AAAA, it could be silent = as
>> there
>> needed double-translation, fine. however, once BIH can get the AAA= A type
>> of the server, it traslates that AAAA to an A type resolution with= an
>> IPv4
>> address under its configuration.
>> 3. then the host possibly receive two A type resolutions: the one = of the
>> genuine A of the server (let's note it as A#1); the one of wha= t is
>> translated by the BIH (A#2). it might randomly select one to send = out the
>> request.
>> 4. the request arrives at the BIH/CLAT, uncertainty happens:
>> =A0 =A0 - who take over the work? the BIH module or the CLAT modul= e?
>> =A0 =A0 - if it is the BIH, but the host actually selects A#1, the= n BIH has
>> no
>> state about this A#1, it has to drop the request;
>> =A0 =A0 - if it is the CLAT module, but it happens that the host c= hoose A#2,
>> then the CLAT will send the request to nowhere.
>>
>> i don't know what we still need to make the *combination* of B= IH and
>> 464xlat safe in this document.
>>
>>
>>>
>>> I still don't see why BIH appears in this document at all.= There's no
>>> reason to cite it. It's an RFC. People can implement it, d= eploy it,
>>> whatever - without us having to cite it in this RFC. There are= lots of
>>> things you can use with CLAT, like IP-in-UDP-tunneling. But we= 're not
>>> putting IP-in-UDP-tunneling in this document. Why?
>>>
>>
>> same view. but they argued that we are newcomers claiming, too lat= e, at
>> a *trivial* question already *well*-discussed in the WG and the au= thors
>> also would like to push the things forward. :( if the above uncert= ainty
>> is
>> certain, the working group is making a mistake.
>>
>> - maoke
>>
>>
>>
>

--e89a8f13ea881c1cf804c95abbd1-- From phdgang@gmail.com Mon Sep 10 08:43:39 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D16DB21F8733 for ; Mon, 10 Sep 2012 08:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.372 X-Spam-Level: X-Spam-Status: No, score=-3.372 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gAXmp40lPP7f for ; Mon, 10 Sep 2012 08:43:38 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id B0E5021F84DE for ; Mon, 10 Sep 2012 08:43:37 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so1643554vcb.31 for ; Mon, 10 Sep 2012 08:43:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=PGftYOPY4FlVTBEI1rwNawyUMe5vjbpKJgEyqjP33O8=; b=Hnq5z649PKH3IKVeC9kyg0ZULSMmmmNMJBYzQtrLp7Jv4FagnC+fKGc/UOcE3xf2ue SrtohJff0hAMo/W8H4ZUxUa1fwnetWIopceo6PDEcbeQ7NXNIX/C0SFuvX1OrtTXFQgF nWmC0ILEh7X42x+I5RfPBvXor5NhjUTYY+3LONpN8wK7dnpoHJd6rRi+QLRobfbyVM/n q6iVQBUsX0RejAI/7JVJH4rTsobJxxG+EQqzTk/bZJC2U9F7ilit4iI6x7FQkF72uwmp fPcGNIWSQu2kOLQxkzCJZ9QOD75oC3YccdLSq6Tt+ke1XhfpuODCXNDb0PlwrstcqJP/ Sahg== MIME-Version: 1.0 Received: by 10.52.37.100 with SMTP id x4mr16292173vdj.56.1347291816917; Mon, 10 Sep 2012 08:43:36 -0700 (PDT) Received: by 10.58.114.231 with HTTP; Mon, 10 Sep 2012 08:43:36 -0700 (PDT) In-Reply-To: References: <810EAE3D-8767-4E66-911D-3DBDFE8B9403@laposte.net> Date: Mon, 10 Sep 2012 23:43:36 +0800 Message-ID: From: GangChen To: Maoke Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 15:43:39 -0000 2012/9/10, Maoke : > 2012/9/11 GangChen > >> 2012/9/10, Maoke : >> > 2012/9/10 R=E9mi Despr=E9s >> > >> >> Maoke, >> >> >> >> After your insisting that I comment the detailed example below you ha= d >> >> addressed to lorenzo, let me do it first priority, for the sake of >> >> 464XLAT >> >> quick progress. >> >> >> >> >> > >> > i reply Lorenzo but cc to the WG and i suppose that the text that i >> > would >> > like to share to all. thanks a lot for taking it in priority. >> > >> > >> >> >> >> >> >> Your example has an IPv4-only host that is supposed to get a public A >> >> record and another A record that would be derived from a AAAA by a >> >> BIH. >> >> This isn't AFAIK a realistic scenario for at least the following >> reasons: >> >> (1) BIH address mapping doesn't apply when both AAAA and A records ar= e >> >> received and the A address in not an excluded one (section 2.4 of >> >> RFC6535). >> >> >> >> >> > >> > thanks for the link of the text. i didn't notice that. but this only >> > prevents CLAT sending things to A#2. what if the packet is delivered t= o >> the >> > BIH module? >> >> The packet with destination A#1 would naturally not be processed by >> BIH, because destination A#1 can't match any item in BIH mapping >> table. >> >> > actually the missing part is, when we are talking "combining" two >> > things, >> > we should at least specify they are working parallel, selected by the >> path >> > decision mechanism, or serially. if parallel, how to select the path; >> > if >> > serial, who is in front who is behind? >> > >> > >> >> >> >> (2) BIH is only for applications that are in the BIH node itself. As >> >> such, >> >> it must not forward AAAA-derived IPv4 addresses to any other node. >> (These >> >> addresses are taken in a private address pool). >> >> >> >> >> > >> > confusing to me. CLAT is able to work for a subnet where the hosts are= . >> > what the applications does the BIH/CLAT box itself have in the 464xlat >> > architecture. >> > >> > and according to the discussion linked by Gang to me, there was the >> > discussion that people said the BIH was not designed for forwarding bu= t >> > replies stated it was able to do so. >> >> I hope that is not on-purpose. If that isn't clear to you, I could >> restate the answers to you. BIH is doing the work only for IPv4 >> APPLICATION. There is nothing to do with tethered IPv4 HOSTs. In the >> previous discussion, you are talking about CLAT-CLAT case, which is >> identified as out of the scope. >> > > in current discussion it is not about CLAT-CLAT and it is in scope. - mao= ke Given you know there are differences, why do you point the previous discussion and intentionally mix it. If you like the mess, please Don't DO that here. > >> >> Gang >> >> >> >> >> >> >> RD >> >> >> >> Le 2012-09-10 =E0 12:26, Maoke a =E9crit : >> >> >> >> >> >> 2012/9/10 Lorenzo Colitti >> >> >> >>> On Sat, Sep 8, 2012 at 12:00 AM, Maoke wrote: >> >>> >> >>>> my suggestion: >> >>>> >> >>>> "464xlat is not designed to cover the case of IPv4-only application= s >> >>>> having access to IPv6-only servers, which will be possibly needed i= n >> >>>> the >> >>>> future. Together using it with BIH [RFC6535] can be a feasible >> solution, >> >>>> if >> >>>> this demand becomes true, and we leave the details of the >> >>>> co-existance >> >>>> to >> >>>> the implemantaion. >> >>>> >> >>> >> >>> I still disagree with this text, because it gives the impression tha= t >> >>> using BIH with 464xlat is a best practice, when in fact nobody has >> >>> even >> >>> tested it yet. What about the original suggestion of saying that >> >>> "464xlat >> >>> is not designed to cover the case of IPv4-only applications having >> >>> access >> >>> to IPv6-only servers. If that is needed, another transition mechanis= m >> >>> such >> >>> as BIH must be employed" ? >> >>> >> >>> >> >> >> >> i share the same feeling. and i support your this suggestion. +1 >> >> >> >> >> >>> >> >>> >> >>> >> >>>> By doing so, BIH continue to not be used together with a NAT64, as >> >>>> recommended in [RFC6535], while 464xlat is being in charge of using >> >>>> NAT64s >> >>>> as PLATs." >> >>>> >> >>> >> >>> The way I read that sentence is, "There's a NAT64 in the >> >>> architecture, >> >>> and the BIH packets can go through that NAT64, but we're not using >> >>> BIH >> >>> with >> >>> a NAT64. We're not because we say we're not. Really." That's pretty >> bad. >> >>> We >> >>> need to at least say thatif BIH is used, then it SHOULD NOT be used >> >>> through >> >>> the NAT64? >> >>> >> >>> >> >> >> >> i also doubt there is really not uncertainty to put BIH with CLAT >> >> together. i proposed a case where BIH/CLAT is poorly running for an >> >> in-domain server (which is a naturally established use-case of the >> >> CLAT >> >> without BIH) but it is argued this case is out of scope. >> >> >> >> so it is sounds to me that people prefer to attach this weird BIH wit= h >> >> CLAT, even sacrifycing the possibly extended scope of usage. >> >> >> >> on the other hand, as i have seen that the *combination* is harmful a= t >> >> least for one case, even it is out of scope, i doubt there is >> >> definitely >> >> no >> >> in-scope trouble of this putting-together. >> >> >> >> a very detailed discussion is here: >> >> >> >> 1. a host behind the BIH/CLAT is to send out a request to a server, >> >> who >> >> has both AAAA and A type resolutions. >> >> 2. NOTE BIH is working since the stage of DNS because the host behind >> >> is >> >> possibly IPv4-only. if BIH cannot get an AAAA, it could be silent as >> >> there >> >> needed double-translation, fine. however, once BIH can get the AAAA >> >> type >> >> of the server, it traslates that AAAA to an A type resolution with an >> >> IPv4 >> >> address under its configuration. >> >> 3. then the host possibly receive two A type resolutions: the one of >> >> the >> >> genuine A of the server (let's note it as A#1); the one of what is >> >> translated by the BIH (A#2). it might randomly select one to send out >> the >> >> request. >> >> 4. the request arrives at the BIH/CLAT, uncertainty happens: >> >> - who take over the work? the BIH module or the CLAT module? >> >> - if it is the BIH, but the host actually selects A#1, then BIH >> >> has >> >> no >> >> state about this A#1, it has to drop the request; >> >> - if it is the CLAT module, but it happens that the host choose >> >> A#2, >> >> then the CLAT will send the request to nowhere. >> >> >> >> i don't know what we still need to make the *combination* of BIH and >> >> 464xlat safe in this document. >> >> >> >> >> >>> >> >>> I still don't see why BIH appears in this document at all. There's n= o >> >>> reason to cite it. It's an RFC. People can implement it, deploy it, >> >>> whatever - without us having to cite it in this RFC. There are lots >> >>> of >> >>> things you can use with CLAT, like IP-in-UDP-tunneling. But we're no= t >> >>> putting IP-in-UDP-tunneling in this document. Why? >> >>> >> >> >> >> same view. but they argued that we are newcomers claiming, too late, >> >> at >> >> a *trivial* question already *well*-discussed in the WG and the >> >> authors >> >> also would like to push the things forward. :( if the above >> >> uncertainty >> >> is >> >> certain, the working group is making a mistake. >> >> >> >> - maoke >> >> >> >> >> >> >> > >> > From fibrib@gmail.com Mon Sep 10 08:50:42 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70D5C21F86F8 for ; Mon, 10 Sep 2012 08:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.215 X-Spam-Level: X-Spam-Status: No, score=-3.215 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KcpcXmifPK+E for ; Mon, 10 Sep 2012 08:50:42 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id B775821F86F0 for ; Mon, 10 Sep 2012 08:50:41 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so1285086wgb.13 for ; Mon, 10 Sep 2012 08:50:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=U7nEJKDM4HXsQUr1JjOSHMVn6qwMu0MnE2gWVgR2/ys=; b=OYGu/yRijlnDWoVYZI/SkGDWmvXy1leuclo8S6UO9HaSyJsjvY+hpVA2ljclDuHm9B 87pggm8a2Zpo38PUQN4ChaDr9UYCLQLu38cBq5XbBiCRzoURyiIN4HtUZ/WfOR1qTzzA 84liOwPXfTDzU0MlyJCIrv3nmjS3EvLI31VV58mcEdvZHc1e63YaM/B8/0bI9m7smfM+ iSB8iMMKDNNn/LYAk2SPm/Nm5x+uHzoYAfpjK2t3joy+YzN5SzfYonDCqrhj9WaC7ScA kUpciRBMV3Mqy1uh/EJv3g6P43hlA2SVW/0m4DZrhFufMulNeREgF645ypd6JCb1er9c kDyw== MIME-Version: 1.0 Received: by 10.180.104.200 with SMTP id gg8mr18058060wib.14.1347292240870; Mon, 10 Sep 2012 08:50:40 -0700 (PDT) Received: by 10.223.37.78 with HTTP; Mon, 10 Sep 2012 08:50:40 -0700 (PDT) In-Reply-To: References: <810EAE3D-8767-4E66-911D-3DBDFE8B9403@laposte.net> Date: Tue, 11 Sep 2012 00:50:40 +0900 Message-ID: From: Maoke To: GangChen Content-Type: multipart/alternative; boundary=f46d044304046cfec904c95aeb74 Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 15:50:42 -0000 --f46d044304046cfec904c95aeb74 Content-Type: text/plain; charset=ISO-8859-1 2012/9/11 GangChen > > > Given you know there are differences, why do you point the previous > discussion and intentionally mix it. If you like the mess, please > Don't DO that here. > > > sorry but i don't comment on this "intentionally mix it" and "mess". out of scope of the technical discussion. - maoke --f46d044304046cfec904c95aeb74 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
2012/9/11 GangChen <phdgang@gmail.com&g= t;
=A0

Given you know there are differenc= es, why do you point the previous
discussion and intentionally mix it. If you like the mess, please
Don't DO that here.

=A0

=A0
sorry = but i don't comment on this "intentionally mix it" and "= mess".=A0out of scope of the technical discussion. - maoke=A0
--f46d044304046cfec904c95aeb74-- From despres.remi@laposte.net Mon Sep 10 09:01:13 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2210E21F8758 for ; Mon, 10 Sep 2012 09:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.481 X-Spam-Level: X-Spam-Status: No, score=-1.481 tagged_above=-999 required=5 tests=[AWL=0.467, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AgPYQASGzw25 for ; Mon, 10 Sep 2012 09:01:12 -0700 (PDT) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.2]) by ietfa.amsl.com (Postfix) with ESMTP id D599421F8707 for ; Mon, 10 Sep 2012 09:01:11 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2109.sfr.fr (SMTP Server) with ESMTP id BE5BF7000101; Mon, 10 Sep 2012 18:01:09 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2109.sfr.fr (SMTP Server) with ESMTP id 356767000053; Mon, 10 Sep 2012 18:01:09 +0200 (CEST) X-SFR-UUID: 20120910160109218.356767000053@msfrf2109.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-49--381518684 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Mon, 10 Sep 2012 18:01:08 +0200 Message-Id: References: <810EAE3D-8767-4E66-911D-3DBDFE8B9403@laposte.net> <4730A653-CD11-4A08-9254-2C80C739D646@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 16:01:13 -0000 --Apple-Mail-49--381518684 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-09-10 =E0 17:34, Maoke a =E9crit : >=20 >=20 > 2012/9/11 R=E9mi Despr=E9s >=20 > 2012-09-10 16:29, Maoke : >=20 >>=20 >> 2012/9/10 R=E9mi Despr=E9s >> Maoke, >>=20 >> After your insisting that I comment the detailed example below you = had addressed to lorenzo, let me do it first priority, for the sake of = 464XLAT quick progress. >> =20 >> =20 >> i reply Lorenzo but cc to the WG and i suppose that the text that i = would like to share to all. thanks a lot for taking it in priority. >> =20 >> =20 >>=20 >> Your example has an IPv4-only host that is supposed to get a public A = record and another A record that would be derived from a AAAA by a BIH. >> This isn't AFAIK a realistic scenario for at least the following = reasons: >> (1) BIH address mapping doesn't apply when both AAAA and A records = are received and the A address in not an excluded one (section 2.4 of = RFC6535). >> =20 >> =20 >> thanks for the link of the text. i didn't notice that. but this only = prevents CLAT sending things to A#2. what if the packet is delivered to = the BIH module? >=20 > BIH doesn't apply AT ALL when both an A and a AAAA are received for a = server. > Your example being AFAIK in this case, no conflict between BIH and = anything else can exist.=20 >=20 >> =20 >> actually the missing part is, when we are talking "combining" two = things, we should at least specify they are working parallel, selected = by the path decision mechanism, or serially. if parallel, how to select = the path; if serial, who is in front who is behind? >=20 > 464XLAT applies to reach public IPv4 addresses, and BIH to reach = servers that have no public IPv4 address. > =20 > =20 > the first DNS request is taken by BIH or by 464xlat? it is highly = possible to be 464xlat, no matter the result is A or AAAA, right? how = the BIH can get the information about that AAAA and/or A? the path seems = to me has no business with the BIH though. A DNS request from an IPv4-only host has, as you say, "no business with = the BIH" (like any packet from such a host to a public IPv4 address). > if i missed anything, please specify further. it is fine to me that = the below is left aside. Unless I miss something, this puts an end of the technical concern that = 464XLAT and BIH might not gracefully coexist.=20 Preferred sentence is then: "464XLAT is not designed to cover the case of IPv4-only applications = having access to IPv6-only servers. If that is needed, BIH of [RFC6535] = provides a solution." Acceptable? RD > =20 > - maoke > =20 > =20 > The order in which their applicability is tested is therefore = irrelevant. >=20 >=20 >> (2) BIH is only for applications that are in the BIH node itself. As = such, it must not forward AAAA-derived IPv4 addresses to any other node. = (These addresses are taken in a private address pool). >> =20 >> =20 >> confusing to me. CLAT is able to work for a subnet where the hosts = are. what the applications does the BIH/CLAT box itself have in the = 464xlat architecture. >=20 > Let's leave this aside, at least for the time being, the point above = being sufficient (if you authorize me to work withy high priority only = on points that condition decisions to be made ;-)) > =20 >> =20 >> and according to the discussion linked by Gang to me, there was the = discussion that people said the BIH was not designed for forwarding but = replies stated it was able to do so. >=20 > Can we please limit this discussion about what BIH does to what there = is in the RFC itself (at least in a first step, which hopefully will be = sufficient). >=20 > RD >=20 >=20 >=20 --Apple-Mail-49--381518684 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1


2012/9/11 R=E9mi Despr=E9s <despres.remi@laposte.net>

2012-09-10 16:29, = Maoke :


2012/9/10 R=E9mi Despr=E9s <despres.remi@laposte.net>
Maoke,

After your = insisting that I comment the detailed example below you had addressed to = lorenzo, let me do it first priority, for the sake of 464XLAT quick = progress.
 
 
i reply = Lorenzo but cc to the WG and i suppose that the text that i would like = to share to all. thanks a lot for taking it in priority. =
 
 

Your = example has an IPv4-only host that is supposed to get a public A record = and another A record that would be derived from  a AAAA by a = BIH.
This isn't AFAIK a realistic scenario for at least the = following reasons:
(1) BIH address mapping doesn't apply when both AAAA and A = records are received and the A address in not an excluded one (section = 2.4 of = RFC6535).
 
 
t= hanks for the link of the text. i didn't notice that. but this only = prevents CLAT sending things to A#2. what if the packet is delivered to = the BIH module?

BIH doesn't apply AT ALL = when both an A and a AAAA are received for a server.
Your = example being AFAIK in this case, no conflict between BIH and anything = else can exist. 

 
actually the missing part is, when we are talking = "combining" two things, we should at least specify they are working = parallel, selected by the path decision mechanism, or serially. if = parallel, how to select the path; if serial, who is in front who is = behind?

464XLAT applies to reach = public IPv4 addresses, and BIH to reach servers that have no public IPv4 = address.
 
 
<= div>the first DNS request is taken by BIH or by 464xlat? it is highly = possible to be 464xlat, no matter the result is A or AAAA, right? = how the BIH can get the information about that AAAA and/or A? the path = seems to me has no business with the BIH though. =

A DNS request from an = IPv4-only host has, as you say, "no business with the BIH" (like any = packet from such a host to a public IPv4 = address).


if i missed anything, please specify further. it is fine to me that = the below is left aside. =

Unless I miss something, = this puts an end of the technical concern that 464XLAT and BIH might not = gracefully coexist. 
Preferred sentence is = then:
"464XLAT is not designed to cover the case of IPv4-only = applications having access to IPv6-only servers. If that is needed, BIH = of [RFC6535] provides a = solution."

Acceptable?
RD


 
- = maoke
 
 
The order = in which their applicability is tested is therefore = irrelevant.


(2) BIH is only for applications that are in the BIH node = itself. As such, it must not forward AAAA-derived IPv4 addresses to any = other node. (These addresses are taken in a private address = pool).
 
 
confusing to me. CLAT is able to work = for a subnet where the hosts are. what the applications does the = BIH/CLAT box itself have in the 464xlat architecture. =

Let's leave this aside, at least for the time being, the = point above being sufficient (if you authorize me to work withy high = priority only on points that condition decisions to be made = ;-))
 
 
and according to the = discussion linked by Gang to me, there was the discussion that people = said the BIH was not designed for forwarding but replies stated it was = able to do so.

Can we please limit = this discussion about what BIH does to what there is in the RFC = itself (at least in a first step, which hopefully will be = sufficient).
=
RD


<= /div>


= --Apple-Mail-49--381518684-- From fibrib@gmail.com Mon Sep 10 09:22:53 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E23D21F8735 for ; Mon, 10 Sep 2012 09:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.875 X-Spam-Level: X-Spam-Status: No, score=-2.875 tagged_above=-999 required=5 tests=[AWL=0.423, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NyxAn5FHCIfT for ; Mon, 10 Sep 2012 09:22:52 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9C62121F8722 for ; Mon, 10 Sep 2012 09:22:51 -0700 (PDT) Received: by wibhi8 with SMTP id hi8so1887917wib.13 for ; Mon, 10 Sep 2012 09:22:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=K3ZjYCuowoIZKoA1BetGFEa3fTUemXDhkyif8JPNW9w=; b=HYtKUzv/iMHJor8cgcRVB516lxgqW9ODC+eGLwZ3trljgoidxid6oRRXvEvj5BIlKL bK1qEIfN1aycPxpRRz60f3loQcI+MBJk930oHrxe8qhD4Zi7rjq20vwr3x2w8J1K23EA 0CR1LZSEvzVJ+CHgxA/QzoSL/a2OBALykDs5s4LVLbCsWHq547y9mBihxHpI0xAmzWBW A3WWsNFlxaofIg336GUxygPNmMZp3fWekDRhy5FWHm0yvB5x2mp3Ci0b4+PoD3HRKj/N i9Ds8vhLnhuqy8hSu87qrn6ZD0BKEwe+prrfmZtnfudotsBLAxsZlkZh0cD6A1zSwe1M O04Q== MIME-Version: 1.0 Received: by 10.180.104.200 with SMTP id gg8mr18235628wib.14.1347294170654; Mon, 10 Sep 2012 09:22:50 -0700 (PDT) Received: by 10.223.37.78 with HTTP; Mon, 10 Sep 2012 09:22:50 -0700 (PDT) In-Reply-To: References: <810EAE3D-8767-4E66-911D-3DBDFE8B9403@laposte.net> <4730A653-CD11-4A08-9254-2C80C739D646@laposte.net> Date: Tue, 11 Sep 2012 01:22:50 +0900 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=f46d0443040473288b04c95b5efe Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 16:22:53 -0000 --f46d0443040473288b04c95b5efe Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/9/11 R=E9mi Despr=E9s > > Le 2012-09-10 =E0 17:34, Maoke a =E9crit : > > > > 2012/9/11 R=E9mi Despr=E9s > >> >> 2012-09-10 16:29, Maoke : >> >> >> 2012/9/10 R=E9mi Despr=E9s >> >>> Maoke, >>> >>> After your insisting that I comment the detailed example below you had >>> addressed to lorenzo, let me do it first priority, for the sake of 464X= LAT >>> quick progress. >>> >>> >> >> i reply Lorenzo but cc to the WG and i suppose that the text that i woul= d >> like to share to all. thanks a lot for taking it in priority. >> >> >>> >>> >>> Your example has an IPv4-only host that is supposed to get a public A >>> record and another A record that would be derived from a AAAA by a BIH= . >>> This isn't AFAIK a realistic scenario for at least the following reason= s: >>> (1) BIH address mapping doesn't apply when both AAAA and A records are >>> received and the A address in not an excluded one (section 2.4 of RFC65= 35). >>> >>> >> >> thanks for the link of the text. i didn't notice that. but this only >> prevents CLAT sending things to A#2. what if the packet is delivered to = the >> BIH module? >> >> >> BIH doesn't apply AT ALL when both an A and a AAAA are received for a >> server. >> Your example being AFAIK in this case, no conflict between BIH and >> anything else can exist. >> >> >> actually the missing part is, when we are talking "combining" two things= , >> we should at least specify they are working parallel, selected by the pa= th >> decision mechanism, or serially. if parallel, how to select the path; if >> serial, who is in front who is behind? >> >> >> 464XLAT applies to reach public IPv4 addresses, and BIH to reach servers >> that have no public IPv4 address. >> >> > > the first DNS request is taken by BIH or by 464xlat? it is highly possibl= e > to be 464xlat, no matter the result is A or AAAA, right? how the BIH can > get the information about that AAAA and/or A? the path seems to me has no > business with the BIH though. > > > A DNS request from an IPv4-only host has, as you say, "no business with > the BIH" (like any packet from such a host to a public IPv4 address). > > not only that. then the IPv4 host may possibly get a AAAA-type reply from the DNS system (surely an IPv4 DNS server can reply AAAA-type for a request). then the reply will be sent by the IPv4 DNS server (through PLAT and CLAT) to the host, right? there's no business of BIH even if the target server is IPv6-only. and therefore the IPv4-only host, getting the AAAA stuff, can do nothing with it. only when the BIH stands between the IPv4-only host and the CLAT, it is possible that the BIH hijack the AAAA reply and synthesize a A reply for the host. but there should be a dilemma in such a serial workflow: if there is the genuine A reply, BIH module needs to transparently deliver that to the host and accepts the further packets from the host and transparently forward that to the CLAT module. does BIH work as a transparent router to genuine IPv4 destinations? (i don't understand RFC6535 saying so but need to confirm) > > > > if i missed anything, please specify further. it is fine to me that the > below is left aside. > > > Unless I miss something, this puts an end of the technical concern that > 464XLAT and BIH might not gracefully coexist. > Preferred sentence is then: > "464XLAT is not designed to cover the case of IPv4-only applications > having access to IPv6-only servers. If that is needed, BIH of [RFC6535] > provides a solution." > > Acceptable? > > i prefer Tim's suggestion not to mention any specific protocol here but only "... If that is needed, another transition mechanism should be considered". if we are definitely to cite the BIH explicitly here, i think we are obliged to state: "This BCP doesn't guarantee that they are gracefully working together while leave the co-existance details as an open issue." - maoke > > RD > > > > > - maoke > > >> >> The order in which their applicability is tested is therefore irrelevant= . >> >> >> (2) BIH is only for applications that are in the BIH node itself. As >>> such, it must not forward AAAA-derived IPv4 addresses to any other node= . >>> (These addresses are taken in a private address pool). >>> >>> >> >> confusing to me. CLAT is able to work for a subnet where the hosts are. >> what the applications does the BIH/CLAT box itself have in the 464xlat >> architecture. >> >> >> Let's leave this aside, at least for the time being, the point above >> being sufficient (if you authorize me to work withy high priority only o= n >> points that condition decisions to be made ;-)) >> >> >> >> and according to the discussion linked by Gang to me, there was the >> discussion that people said the BIH was not designed for forwarding but >> replies stated it was able to do so. >> >> >> Can we please limit this discussion about what BIH does to what there is >> in the RFC itself (at least in a first step, which hopefully will be >> sufficient). >> >> RD >> >> >> > > --f46d0443040473288b04c95b5efe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/9/11 R=E9mi Despr=E9s <desp= res.remi@laposte.net>

Le 2012-09-10 =E0 17:34, = Maoke a =E9crit :



2012/9/11 R=E9mi Despr=E9s <despres.remi@laposte= .net>

2012-09-10 16:29, Maoke :=


201= 2/9/10 R=E9mi Despr=E9s <despres.remi@laposte.net>
Maoke,

After your in= sisting that I comment the detailed example below you had addressed to lore= nzo,=A0let me do it first priority, for the sake of 464XLAT quick progress.=
=A0
=A0
i reply Lorenzo but cc = to the WG and i suppose that the text that i would like to share to all. th= anks a lot for taking it in priority.
=A0
=A0

Your = example has an IPv4-only host that is supposed to get a public A record and= another A record that would be derived from =A0a AAAA by a BIH.
= This isn't AFAIK a realistic scenario for at least the following reason= s:
(1)=A0BIH address mapping doesn't apply when both AAAA and A recor= ds are received and the A address in not an excluded one (section 2.4 of RF= C6535).
=A0
=A0
thanks for= the link of the text. i didn't notice that. but this only prevents CLA= T sending things to A#2. what if the packet is delivered to the BIH module?=

BIH doesn't apply AT ALL w= hen both an A and a AAAA are received for a server.
Your example = being AFAIK in this case, no conflict between BIH and anything else can exi= st.=A0

=A0
actually the missing part is, when we are talking "= combining" two things, we should at least specify they are working par= allel, selected by the path decision mechanism, or serially. if parallel, h= ow to select the path; if serial, who is in front who is behind?

464XLAT applies to reach publi= c IPv4 addresses, and BIH to reach servers that have no public IPv4 address= .
=A0
=A0
the first = DNS request is taken by BIH or by 464xlat? it is highly possible to=A0be 46= 4xlat, no matter the result is A or AAAA, right? how the BIH can get the in= formation about that AAAA and/or A? the path seems to me has no business wi= th the BIH though.

A DNS request from an IPv4-onl= y host has, as you say, "no business with the BIH" (like any pack= et from such a host to a public IPv4 address).
=A0
=A0
not only that. then the IPv4 host may possi= bly get a AAAA-type reply from the DNS system (surely an IPv4 DNS server ca= n reply AAAA-type for a request). then the reply will be sent by the IPv4 D= NS server (through PLAT and CLAT) to the host, right? there's no busine= ss of BIH even if the target server is IPv6-only.
=A0
and therefore the IPv4-only host, getting the AAAA stuff= , can do nothing with it. only when the BIH stands between the IPv4-only ho= st and the CLAT, it is possible that the BIH hijack the AAAA reply and synt= hesize a A reply for the host.
=A0
but there should be a dilemma in such a serial workflow:= if there is the genuine A reply, BIH module needs to transparently deliver= that to the host and accepts the further packets from the host and transpa= rently forward that to the CLAT module. does BIH work=A0as a transparent ro= uter to=A0genuine IPv4 destinations?=A0(i don't understand RFC6535 sayi= ng so but need to confirm)
=A0
=A0


if i missed anything, please specify further. it is fine to me that th= e below is left aside.

U= nless I miss something, this puts an end of the technical concern that 464X= LAT and BIH might not gracefully=A0coexist.=A0
Preferred sentence is then:
"464XLAT is not designed to= cover the case of IPv4-only applications having access to IPv6-only server= s. If that is needed, BIH of=A0[RFC6535] provides=A0a solution."

Acceptable?
=A0
=A0
i prefer Tim's suggestion not to mention any specif= ic protocol here but only
=A0=A0=A0=A0 "... If that is need= ed, another transition mechanism should be considered".=A0
=A0
if we=A0are definitely to=A0cite the BIH explicitly=A0he= re, i think we are obliged to=A0state:
=A0=A0=A0 =A0"This BC= P doesn't guarantee that=A0they are gracefully working together=A0while= leave the co-existance details=A0as an open issue."
=A0
- maoke
=A0
=A0
RD



<= div>=A0
- maoke
=A0
=A0
The order in wh= ich their applicability is tested is therefore irrelevant.
<= br>

(2)=A0BIH is only for applications that are in the BIH node itself. As= such, it must not forward AAAA-derived IPv4 addresses to any other node. (= These addresses are taken in a private address pool).
=A0
=A0
confusing to me. CLAT is able to work for a= subnet where the hosts are. what the applications does the BIH/CLAT box it= self have=A0in the 464xlat architecture.

Let's leave this aside, at least for the time being, the po= int above being sufficient (if you authorize me to work withy high priority= only on points that condition decisions to be made ;-))
=A0
=A0
<= div>and according to the discussion linked by Gang to me, there was the dis= cussion that people said the BIH was not designed for forwarding but replie= s stated it was able to do so.

Can we please=A0limit this=A0d= iscussion about what BIH does to what there is in the RFC itself (at least = in a first step, which hopefully will be sufficient).

RD





--f46d0443040473288b04c95b5efe-- From phdgang@gmail.com Mon Sep 10 09:45:00 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 618F421F8607 for ; Mon, 10 Sep 2012 09:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.386 X-Spam-Level: X-Spam-Status: No, score=-3.386 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4o+K1qYrUkwc for ; Mon, 10 Sep 2012 09:44:59 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4FDB421F859C for ; Mon, 10 Sep 2012 09:44:59 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so1751793vcb.31 for ; Mon, 10 Sep 2012 09:44:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=S5zDi6pIerJ6l9hQ8frTyhYolrLjte9zHv63geHDAW8=; b=yNnlMXtmoQoJhge6ZR14XyVyiv//9+qQHjMgkF+dwbj7M0I9c1VFw4FfJkp1V0AZde VhexvmsjFhb8GlPgbieNmY6j2gBe4H5SXqlkEkYwP6+No5CHdby+TyWzjjtpvJMw2mr9 9UKoQC11+H6sp+KlJ275ECkAH4sOpQuffBZKv8/igo9xMgma3pjBfSDKzodUisuAKqtj ynmgJMz2JPp3KBF/YtR9dK1VfGWTca3Pzt5v97bj+LRNdiemd1NK0lUSTJ6mHCt0tSCH iVprQypPagH26B2Jt63fIJDPhrkPP2vuVyfpcDyNlYx1T4rcVGQ/6IBLuhKxuMJNceiq zNLQ== MIME-Version: 1.0 Received: by 10.52.92.169 with SMTP id cn9mr16968109vdb.72.1347295498505; Mon, 10 Sep 2012 09:44:58 -0700 (PDT) Received: by 10.58.114.231 with HTTP; Mon, 10 Sep 2012 09:44:58 -0700 (PDT) In-Reply-To: References: <810EAE3D-8767-4E66-911D-3DBDFE8B9403@laposte.net> <4730A653-CD11-4A08-9254-2C80C739D646@laposte.net> Date: Tue, 11 Sep 2012 00:44:58 +0800 Message-ID: From: GangChen To: Maoke Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 16:45:00 -0000 2012/9/11, Maoke : > 2012/9/11 R=E9mi Despr=E9s > >> >> Le 2012-09-10 =E0 17:34, Maoke a =E9crit : >> >> >> >> 2012/9/11 R=E9mi Despr=E9s >> >>> >>> 2012-09-10 16:29, Maoke : >>> >>> >>> 2012/9/10 R=E9mi Despr=E9s >>> >>>> Maoke, >>>> >>>> After your insisting that I comment the detailed example below you had >>>> addressed to lorenzo, let me do it first priority, for the sake of >>>> 464XLAT >>>> quick progress. >>>> >>>> >>> >>> i reply Lorenzo but cc to the WG and i suppose that the text that i >>> would >>> like to share to all. thanks a lot for taking it in priority. >>> >>> >>>> >>>> >>>> Your example has an IPv4-only host that is supposed to get a public A >>>> record and another A record that would be derived from a AAAA by a >>>> BIH. >>>> This isn't AFAIK a realistic scenario for at least the following >>>> reasons: >>>> (1) BIH address mapping doesn't apply when both AAAA and A records are >>>> received and the A address in not an excluded one (section 2.4 of >>>> RFC6535). >>>> >>>> >>> >>> thanks for the link of the text. i didn't notice that. but this only >>> prevents CLAT sending things to A#2. what if the packet is delivered to >>> the >>> BIH module? >>> >>> >>> BIH doesn't apply AT ALL when both an A and a AAAA are received for a >>> server. >>> Your example being AFAIK in this case, no conflict between BIH and >>> anything else can exist. >>> >>> >>> actually the missing part is, when we are talking "combining" two >>> things, >>> we should at least specify they are working parallel, selected by the >>> path >>> decision mechanism, or serially. if parallel, how to select the path; i= f >>> serial, who is in front who is behind? >>> >>> >>> 464XLAT applies to reach public IPv4 addresses, and BIH to reach server= s >>> that have no public IPv4 address. >>> >>> >> >> the first DNS request is taken by BIH or by 464xlat? it is highly >> possible >> to be 464xlat, no matter the result is A or AAAA, right? how the BIH can >> get the information about that AAAA and/or A? the path seems to me has n= o >> business with the BIH though. >> >> >> A DNS request from an IPv4-only host has, as you say, "no business with >> the BIH" (like any packet from such a host to a public IPv4 address). >> >> > > not only that. then the IPv4 host may possibly get a AAAA-type reply from > the DNS system (surely an IPv4 DNS server can reply AAAA-type for a > request). then the reply will be sent by the IPv4 DNS server (through PLA= T > and CLAT) to the host, right? there's no business of BIH even if the targ= et > server is IPv6-only. > > and therefore the IPv4-only host, getting the AAAA stuff, can do nothing > with it. only when the BIH stands between the IPv4-only host and the CLAT= , > it is possible that the BIH hijack the AAAA reply and synthesize a A repl= y > for the host. Wait... you are intending to change the behavior of RFC6535 according to your imagination. Can I ask you to re-read the 464xlat and RFC6535? Otherwise, I can see nothing we could achieve through the discussion. > but there should be a dilemma in such a serial workflow: if there is the > genuine A reply, BIH module needs to transparently deliver that to the ho= st > and accepts the further packets from the host and transparently forward > that to the CLAT module. does BIH work as a transparent router to genuine > IPv4 destinations? (i don't understand RFC6535 saying so but need to > confirm) > > >> >> >> >> if i missed anything, please specify further. it is fine to me that the >> below is left aside. >> >> >> Unless I miss something, this puts an end of the technical concern that >> 464XLAT and BIH might not gracefully coexist. >> Preferred sentence is then: >> "464XLAT is not designed to cover the case of IPv4-only applications >> having access to IPv6-only servers. If that is needed, BIH of [RFC6535] >> provides a solution." >> >> Acceptable? >> >> > > i prefer Tim's suggestion not to mention any specific protocol here but > only > "... If that is needed, another transition mechanism should be > considered". > > if we are definitely to cite the BIH explicitly here, i think we are > obliged to state: > "This BCP doesn't guarantee that they are gracefully working > together while leave the co-existance details as an open issue." > > - maoke > > >> >> RD >> >> >> >> >> - maoke >> >> >>> >>> The order in which their applicability is tested is therefore >>> irrelevant. >>> >>> >>> (2) BIH is only for applications that are in the BIH node itself. As >>>> such, it must not forward AAAA-derived IPv4 addresses to any other >>>> node. >>>> (These addresses are taken in a private address pool). >>>> >>>> >>> >>> confusing to me. CLAT is able to work for a subnet where the hosts are. >>> what the applications does the BIH/CLAT box itself have in the 464xlat >>> architecture. >>> >>> >>> Let's leave this aside, at least for the time being, the point above >>> being sufficient (if you authorize me to work withy high priority only >>> on >>> points that condition decisions to be made ;-)) >>> >>> >>> >>> and according to the discussion linked by Gang to me, there was the >>> discussion that people said the BIH was not designed for forwarding but >>> replies stated it was able to do so. >>> >>> >>> Can we please limit this discussion about what BIH does to what there i= s >>> in the RFC itself (at least in a first step, which hopefully will be >>> sufficient). >>> >>> RD >>> >>> >>> >> >> > From despres.remi@laposte.net Mon Sep 10 09:48:11 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD7C21F8581 for ; Mon, 10 Sep 2012 09:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.493 X-Spam-Level: X-Spam-Status: No, score=-1.493 tagged_above=-999 required=5 tests=[AWL=0.455, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n660xdBXzICM for ; Mon, 10 Sep 2012 09:48:10 -0700 (PDT) Received: from smtp25.services.sfr.fr (smtp25.services.sfr.fr [93.17.128.119]) by ietfa.amsl.com (Postfix) with ESMTP id DF77121F84D6 for ; Mon, 10 Sep 2012 09:48:09 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2509.sfr.fr (SMTP Server) with ESMTP id C19FB70000F5; Mon, 10 Sep 2012 18:48:08 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2509.sfr.fr (SMTP Server) with ESMTP id 0BEAF70000F3; Mon, 10 Sep 2012 18:48:08 +0200 (CEST) X-SFR-UUID: 20120910164808490.0BEAF70000F3@msfrf2509.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-50--378699948 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Mon, 10 Sep 2012 18:48:07 +0200 Message-Id: <88D1CFAA-0D4A-4B98-AD50-B10CEC5B4933@laposte.net> References: <810EAE3D-8767-4E66-911D-3DBDFE8B9403@laposte.net> <4730A653-CD11-4A08-9254-2C80C739D646@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 16:48:11 -0000 --Apple-Mail-50--378699948 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-09-10 =E0 18:22, Maoke a =E9crit : >=20 >=20 > 2012/9/11 R=E9mi Despr=E9s >=20 > Le 2012-09-10 =E0 17:34, Maoke a =E9crit : >=20 >>=20 >>=20 >> 2012/9/11 R=E9mi Despr=E9s >>=20 >> 2012-09-10 16:29, Maoke : >>=20 >>>=20 >>> 2012/9/10 R=E9mi Despr=E9s >>> Maoke, >>>=20 >>> After your insisting that I comment the detailed example below you = had addressed to lorenzo, let me do it first priority, for the sake of = 464XLAT quick progress. >>> =20 >>> =20 >>> i reply Lorenzo but cc to the WG and i suppose that the text that i = would like to share to all. thanks a lot for taking it in priority. >>> =20 >>> =20 >>>=20 >>> Your example has an IPv4-only host that is supposed to get a public = A record and another A record that would be derived from a AAAA by a = BIH. >>> This isn't AFAIK a realistic scenario for at least the following = reasons: >>> (1) BIH address mapping doesn't apply when both AAAA and A records = are received and the A address in not an excluded one (section 2.4 of = RFC6535). >>> =20 >>> =20 >>> thanks for the link of the text. i didn't notice that. but this only = prevents CLAT sending things to A#2. what if the packet is delivered to = the BIH module? >>=20 >> BIH doesn't apply AT ALL when both an A and a AAAA are received for a = server. >> Your example being AFAIK in this case, no conflict between BIH and = anything else can exist.=20 >>=20 >>> =20 >>> actually the missing part is, when we are talking "combining" two = things, we should at least specify they are working parallel, selected = by the path decision mechanism, or serially. if parallel, how to select = the path; if serial, who is in front who is behind? >>=20 >> 464XLAT applies to reach public IPv4 addresses, and BIH to reach = servers that have no public IPv4 address. >> =20 >> =20 >> the first DNS request is taken by BIH or by 464xlat? it is highly = possible to be 464xlat, no matter the result is A or AAAA, right? how = the BIH can get the information about that AAAA and/or A? the path seems = to me has no business with the BIH though. >=20 > A DNS request from an IPv4-only host has, as you say, "no business = with the BIH" (like any packet from such a host to a public IPv4 = address). > =20 > =20 > not only that. then the IPv4 host may possibly get a AAAA-type reply = from the DNS system (surely an IPv4 DNS server can reply AAAA-type for a = request). then the reply will be sent by the IPv4 DNS server (through = PLAT and CLAT) to the host, right? there's no business of BIH even if = the target server is IPv6-only. > =20 > and therefore the IPv4-only host, getting the AAAA stuff, can do = nothing with it. only when the BIH stands between the IPv4-only host and = the CLAT, it is possible that the BIH hijack the AAAA reply and = synthesize a A reply for the host. > =20 > but there should be a dilemma in such a serial workflow: if there is = the genuine A reply, BIH module needs to transparently deliver that to = the host and accepts the further packets from the host and transparently = forward that to the CLAT module. does BIH work as a transparent router = to genuine IPv4 destinations? (i don't understand RFC6535 saying so but = need to confirm) > =20 > =20 >=20 >=20 >> if i missed anything, please specify further. it is fine to me that = the below is left aside. >=20 > Unless I miss something, this puts an end of the technical concern = that 464XLAT and BIH might not gracefully coexist.=20 > Preferred sentence is then: > "464XLAT is not designed to cover the case of IPv4-only applications = having access to IPv6-only servers. If that is needed, BIH of [RFC6535] = provides a solution." >=20 > Acceptable? > =20 > =20 > i prefer Tim's suggestion not to mention any specific protocol here = but only > "... If that is needed, another transition mechanism should be = considered".=20 You say you "prefer" this other wording (which hides useful information) = but, in view of your next sentence below, you even refuse the wording = that you don't prefer! Frankly, this is one more disappointment after so much effort to teach = you what BIH does. > if we are definitely to cite the BIH explicitly here, i think we are = obliged to state: > "This BCP doesn't guarantee that they are gracefully working = together while leave the co-existance details as an open issue." There is absolutely no justification for such a negative sentence! - If you no reason is identified why 464XLAT and BIH wouldn't gracefully = coexist, suggesting one exists is unacceptable. - Especially since=20 . Some others who have carefully studied both 464XLAT and BIH for quite = some time have found no reason to doubt.=20 . One an implementation is in progress. . All your past reasons to doubt have been answered. So, let me ask again whether you can consider the following sentence as = ACCEPTABLE? "464XLKAT is not designed to cover the case of IPv4-only applications = having access to IPv6-only servers. If that is needed, BIH of [RFC6535] = provides a solution." RD > =20 > - maoke > =20 > =20 > RD >=20 >=20 >=20 >> =20 >> - maoke >> =20 >> =20 >> The order in which their applicability is tested is therefore = irrelevant. >>=20 >>=20 >>> (2) BIH is only for applications that are in the BIH node itself. As = such, it must not forward AAAA-derived IPv4 addresses to any other node. = (These addresses are taken in a private address pool). >>> =20 >>> =20 >>> confusing to me. CLAT is able to work for a subnet where the hosts = are. what the applications does the BIH/CLAT box itself have in the = 464xlat architecture. >>=20 >> Let's leave this aside, at least for the time being, the point above = being sufficient (if you authorize me to work withy high priority only = on points that condition decisions to be made ;-)) >> =20 >>> =20 >>> and according to the discussion linked by Gang to me, there was the = discussion that people said the BIH was not designed for forwarding but = replies stated it was able to do so. >>=20 >> Can we please limit this discussion about what BIH does to what there = is in the RFC itself (at least in a first step, which hopefully will be = sufficient). >>=20 >> RD >>=20 >>=20 >>=20 >=20 >=20 --Apple-Mail-50--378699948 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1


2012/9/11 R=E9mi Despr=E9s <despres.remi@laposte.net>

Le 2012-09-10 =E0 = 17:34, Maoke a =E9crit :



2012/9/11 R=E9mi = Despr=E9s <despres.remi@laposte.net>

2012-09-10 16:29, = Maoke :


2012/9/10 R=E9mi Despr=E9s <despres.remi@laposte.net>
Maoke,

After your = insisting that I comment the detailed example below you had addressed to = lorenzo, let me do it first priority, for the sake of 464XLAT quick = progress.
 
 
i reply = Lorenzo but cc to the WG and i suppose that the text that i would like = to share to all. thanks a lot for taking it in priority. =
 
 

Your = example has an IPv4-only host that is supposed to get a public A record = and another A record that would be derived from  a AAAA by a = BIH.
This isn't AFAIK a realistic scenario for at least the = following reasons:
(1) BIH address mapping doesn't apply when both AAAA and A = records are received and the A address in not an excluded one (section = 2.4 of = RFC6535).
 
 
t= hanks for the link of the text. i didn't notice that. but this only = prevents CLAT sending things to A#2. what if the packet is delivered to = the BIH module?

BIH doesn't apply AT ALL = when both an A and a AAAA are received for a server.
Your = example being AFAIK in this case, no conflict between BIH and anything = else can exist. 

 
actually the missing part is, when we are talking = "combining" two things, we should at least specify they are working = parallel, selected by the path decision mechanism, or serially. if = parallel, how to select the path; if serial, who is in front who is = behind?

464XLAT applies to reach = public IPv4 addresses, and BIH to reach servers that have no public IPv4 = address.
 
 
<= div>the first DNS request is taken by BIH or by 464xlat? it is highly = possible to be 464xlat, no matter the result is A or AAAA, right? = how the BIH can get the information about that AAAA and/or A? the path = seems to me has no business with the BIH though.

A DNS request from an = IPv4-only host has, as you say, "no business with the BIH" (like any = packet from such a host to a public IPv4 = address).
 
 
not only that. then the IPv4 host may = possibly get a AAAA-type reply from the DNS system (surely an IPv4 DNS = server can reply AAAA-type for a request). then the reply will be sent = by the IPv4 DNS server (through PLAT and CLAT) to the host, right? = there's no business of BIH even if the target server is IPv6-only. =
 
and therefore the IPv4-only host, getting the AAAA = stuff, can do nothing with it. only when the BIH stands between the = IPv4-only host and the CLAT, it is possible that the BIH hijack the AAAA = reply and synthesize a A reply for the host.
 
but there should be a dilemma in such a serial = workflow: if there is the genuine A reply, BIH module needs to = transparently deliver that to the host and accepts the further packets = from the host and transparently forward that to the CLAT module. does = BIH work as a transparent router to genuine IPv4 = destinations? (i don't understand RFC6535 saying so but need to = confirm)
 
 


if i missed anything, please specify further. it is fine to me that = the below is left aside. =

Unless I miss = something, this puts an end of the technical concern that 464XLAT and = BIH might not gracefully coexist. 
Preferred sentence is then:
"464XLAT is not designed to = cover the case of IPv4-only applications having access to IPv6-only = servers. If that is needed, BIH of [RFC6535] provides a = solution."
=

Acceptable?
 
 
i prefer Tim's suggestion not to mention any = specific protocol here but only
     "... = If that is needed, another transition mechanism should be = considered". 

You say = you "prefer" this other wording (which hides useful information) but, in = view of your next sentence below, you even refuse the wording that you = don't prefer!

Frankly, this is one more = disappointment after so much effort to teach you what BIH = does.


if we are definitely to cite the BIH = explicitly here, i think we are obliged = to state:
     "This BCP doesn't = guarantee that they are gracefully working together while = leave the co-existance details as an open issue." =

There is absolutely no = justification for such a negative sentence!
- If you no reason = is identified why 464XLAT and BIH wouldn't gracefully coexist, = suggesting one exists is unacceptable.
- Especially = since 
 . Some others who have carefully studied = both 464XLAT and BIH for quite some time have found no reason to = doubt. 
 . One an implementation is in = progress.
 . All your past reasons to doubt have been = answered.

So, let me ask again whether you can = consider the following sentence as ACCEPTABLE?
"464XLKAT is = not designed to cover the case of IPv4-only applications having access = to IPv6-only servers. If that is needed, BIH of [RFC6535] = provides a = solution."

RD


=


 
- maoke
 
 
RD


=

 
- = maoke
 
 
The order = in which their applicability is tested is therefore = irrelevant.


(2) BIH is only for applications that are in the BIH node = itself. As such, it must not forward AAAA-derived IPv4 addresses to any = other node. (These addresses are taken in a private address = pool).
 
 
confusing to me. CLAT is able to work = for a subnet where the hosts are. what the applications does the = BIH/CLAT box itself have in the 464xlat architecture. =

Let's leave this aside, at least for the time being, the = point above being sufficient (if you authorize me to work withy high = priority only on points that condition decisions to be made = ;-))
 
 
and according to the = discussion linked by Gang to me, there was the discussion that people = said the BIH was not designed for forwarding but replies stated it was = able to do so.

Can we please limit = this discussion about what BIH does to what there is in the RFC = itself (at least in a first step, which hopefully will be = sufficient).
=
RD


<= /div>




= --Apple-Mail-50--378699948-- From gert@space.net Mon Sep 10 11:02:35 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 186D221F84E1 for ; Mon, 10 Sep 2012 11:02:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N+mDL0foWiZt for ; Mon, 10 Sep 2012 11:02:34 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5255721F84D5 for ; Mon, 10 Sep 2012 11:02:33 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id D9588F902F for ; Mon, 10 Sep 2012 20:02:31 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id A0F2FF9029 for ; Mon, 10 Sep 2012 20:02:31 +0200 (CEST) Received: (qmail 70962 invoked by uid 1007); 10 Sep 2012 20:02:31 +0200 Date: Mon, 10 Sep 2012 20:02:31 +0200 From: Gert Doering To: Maoke Message-ID: <20120910180231.GV13776@Space.Net> References: <810EAE3D-8767-4E66-911D-3DBDFE8B9403@laposte.net> <4730A653-CD11-4A08-9254-2C80C739D646@laposte.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 18:02:35 -0000 Hi, On Tue, Sep 11, 2012 at 01:22:50AM +0900, Maoke wrote: > and therefore the IPv4-only host, getting the AAAA stuff, can do nothing > with it. only when the BIH stands between the IPv4-only host and the CLAT, > it is possible that the BIH hijack the AAAA reply and synthesize a A reply > for the host. What, exactly, does this have to do with the draft at hand? There are no IPv*4*-only hosts here. There's an IPv6-only host, which can do IPv4 by help of 464xlat. So BIH does not apply at all. I really wonder if this is getting anywhere - as soon as one crazy reason why this draft can not proceed has been silenced with 200+ e-mails, the next one springs up. Could people please focus on this draft, and not on "what other byzantine migration schemes might exist or not, and might want to be mentioned or should not mentioned in this draft"? I already deleted about a 100 unread mails in this thread today, because some of us really have work to do. Gert Doering -- IPv6 Operator, hoping to see IPv6 deployment in mobile networks, and *this* is an important piece. -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From internet-drafts@ietf.org Mon Sep 10 13:20:07 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 854EC21F84F3; Mon, 10 Sep 2012 13:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.506 X-Spam-Level: X-Spam-Status: No, score=-102.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A96SM2BOfPfm; Mon, 10 Sep 2012 13:20:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B74C821F84AE; Mon, 10 Sep 2012 13:20:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120910202006.17433.36469.idtracker@ietfa.amsl.com> Date: Mon, 10 Sep 2012 13:20:06 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-wireline-incremental-ipv6-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 20:20:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Wireline Incremental IPv6 Author(s) : Victor Kuarsingh Lee Howard Filename : draft-ietf-v6ops-wireline-incremental-ipv6-06.txt Pages : 29 Date : 2012-09-10 Abstract: Operators worldwide are in various stages of preparing for, or deploying IPv6 into their networks. The operators often face difficult challenges related to both IPv6 introduction along with those related to IPv4 run out. Operators will need to meet the simultaneous needs of IPv6 connectivity and continue support for IPv4 connectivity for legacy devices with a stagnant supply of IPv4 addresses. The IPv6 transition will take most networks from an IPv4- only environment to an IPv6 dominant environment with long transition period varying by operator. This document helps provide a framework for wireline providers who are faced with the challenges of introducing IPv6 along with meeting the legacy needs of IPv4 connectivity utilizing well defined and commercially available IPv6 transition technologies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-wireline-incremental-ipv6 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-wireline-incremental-ipv6-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-wireline-incremental-ip= v6-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From fibrib@gmail.com Mon Sep 10 15:20:43 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85D9121F8710 for ; Mon, 10 Sep 2012 15:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.231 X-Spam-Level: X-Spam-Status: No, score=-3.231 tagged_above=-999 required=5 tests=[AWL=0.367, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tLhlnTgPpIVU for ; Mon, 10 Sep 2012 15:20:42 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6E41C21F865B for ; Mon, 10 Sep 2012 15:20:41 -0700 (PDT) Received: by eekb45 with SMTP id b45so1585161eek.31 for ; Mon, 10 Sep 2012 15:20:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=aDRrFvc14C2fI/h73fpwO5Ko4QnDJC0T5FCe6aWCAsk=; b=G3BLgTENQFhcDMKLBrx8RWkCGOwrmto7o9LkmoSa8LtapxufJE7Nhv1mJlmPouz1Iz YL6N9+n4gJlDq3iTXK9HNvIbaoudtGNqE8J3ljCODx1PiAN6pRykIrfBpKGO7zFfy4Mn oc9U+GcKcNXBvHRUeIvY7mh5YxQQ8BJXEGH9J+bW+v9wyxlVBhE6gqq21wd2NO90//Ru W+efnLGfTetF4F4qvJuMc0FGS/fcp7KE+rADFJUUllUrjBVTFL92fgYOaFvfLOy7chG0 1NFYlWoaeMP0zhb2nnoTkfuTAJsIc9W4p6RiShMbCUPZK0qP4LcfJqwJe8bwaA0VwPLq bNTg== MIME-Version: 1.0 Received: by 10.14.172.129 with SMTP id t1mr22186963eel.34.1347315631642; Mon, 10 Sep 2012 15:20:31 -0700 (PDT) Received: by 10.14.97.9 with HTTP; Mon, 10 Sep 2012 15:20:31 -0700 (PDT) In-Reply-To: <20120910180231.GV13776@Space.Net> References: <810EAE3D-8767-4E66-911D-3DBDFE8B9403@laposte.net> <4730A653-CD11-4A08-9254-2C80C739D646@laposte.net> <20120910180231.GV13776@Space.Net> Date: Tue, 11 Sep 2012 07:20:31 +0900 Message-ID: From: Maoke To: Gert Doering Content-Type: multipart/alternative; boundary=047d7b603c129fd7a104c9605d29 Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 22:20:43 -0000 --047d7b603c129fd7a104c9605d29 Content-Type: text/plain; charset=ISO-8859-1 2012/9/11 Gert Doering > Hi, > > On Tue, Sep 11, 2012 at 01:22:50AM +0900, Maoke wrote: > > and therefore the IPv4-only host, getting the AAAA stuff, can do nothing > > with it. only when the BIH stands between the IPv4-only host and the > CLAT, > > it is possible that the BIH hijack the AAAA reply and synthesize a A > reply > > for the host. > > What, exactly, does this have to do with the draft at hand? > > There are no IPv*4*-only hosts here. There's an IPv6-only host, which > can do IPv4 by help of 464xlat. So BIH does not apply at all. > the current version have this +--------+-------------+-----------------------+-------------+ | Server | Application | Traffic Treatment | Location of | | | and Host | | Translation | +--------+-------------+-----------------------+-------------+ | IPv6 | IPv6 | End-to-end IPv6 | None | +--------+-------------+-----------------------+-------------+ | IPv4 | IPv6 | Stateful Translation | PLAT | +--------+-------------+-----------------------+-------------+ | IPv4 | IPv4 | 464XLAT | PLAT/CLAT | +--------+-------------+-----------------------+-------------+ | IPv6 | IPv4 | BIH | CLAT | +--------+-------------+-----------------------+-------------+ for the last line, i just want to identify how the work is done since the very beginning, i.e. the DNS resolution. if you mean: when BIH is applied, it is ONLY the case that the CLAT is playing as a host rather than the router for a subnet, then i may finalize. the following words are none of my business, sorry. - maoke > > I really wonder if this is getting anywhere - as soon as one crazy reason > why this draft can not proceed has been silenced with 200+ e-mails, the > next one springs up. > > Could people please focus on this draft, and not on "what other byzantine > migration schemes might exist or not, and might want to be mentioned or > should not mentioned in this draft"? > > I already deleted about a 100 unread mails in this thread today, because > some of us really have work to do. > > Gert Doering > -- IPv6 Operator, hoping to see IPv6 deployment in mobile networks, > and *this* is an important piece. > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 > --047d7b603c129fd7a104c9605d29 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/9/11 Gert Doering <gert@space.net= >
Hi,

On Tue, Sep 11, 2012 at 01:22:50AM +0900, Maoke wrote:
> and therefore the IPv4-only host, getting the AAAA stuff, can do nothi= ng
> with it. only when the BIH stands between the IPv4-only host and the C= LAT,
> it is possible that the BIH hijack the AAAA reply and synthesize a A r= eply
> for the host.

What, exactly, does this have to do with the draft at hand?

There are no IPv*4*-only hosts here. =A0There's an IPv6-only host, whic= h
can do IPv4 by help of 464xlat. =A0So BIH does not apply at all.
=A0
the current version have this
=A0
=
=A0=A0=A0=A0=A0 +--------+-------------+-----------------------+------= -------+
=A0=A0=A0=A0=A0=A0=A0 | Server | Application |=A0=A0 Traffic Treatment=A0= =A0 | Location of |
=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0 | and H= ost=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 | Translation |
=A0=A0=A0=A0=A0=A0=A0 +--------+-------------+---= --------------------+-------------+
=A0=A0=A0=A0=A0=A0=A0 |=A0 IPv6=A0 |=A0=A0=A0 IPv6=A0=A0=A0=A0 |=A0=A0=A0 E= nd-to-end IPv6=A0=A0=A0 |=A0=A0=A0 None=A0=A0=A0=A0 |
=A0=A0=A0=A0=A0=A0= =A0 +--------+-------------+-----------------------+-------------+
=A0= =A0=A0=A0=A0=A0=A0 |=A0 IPv4=A0 |=A0=A0=A0 IPv6=A0=A0=A0=A0 | Stateful Tran= slation=A0 |=A0=A0=A0 PLAT=A0=A0=A0=A0 |
=A0=A0=A0=A0=A0=A0=A0 +--------+-------------+-----------------------+-----= --------+
=A0=A0=A0=A0=A0=A0=A0 |=A0 IPv4=A0 |=A0=A0=A0 IPv4=A0=A0=A0=A0= |=A0=A0=A0=A0=A0=A0=A0 464XLAT=A0=A0=A0=A0=A0=A0=A0 |=A0 PLAT/CLAT=A0 |=A0=A0=A0=A0=A0=A0=A0 +--------+-------------+-----------------------+----= ---------+
=A0=A0=A0=A0=A0=A0=A0 |=A0 IPv6=A0 |=A0=A0=A0 IPv4=A0=A0=A0=A0 |=A0=A0=A0= =A0=A0=A0=A0=A0=A0 BIH=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0 CLAT=A0=A0=A0= =A0 |
=A0=A0=A0=A0=A0=A0=A0 +--------+-------------+--------------------= ---+-------------+

for the last line, i just want to identify how th= e work is done since the very=A0beginning, i.e. the DNS resolution.
=A0
if you mean: when BIH is applied, it is ONLY the case th= at the CLAT is playing as a host rather than the router for a subnet, then= =A0i may finalize. the following words are none of my business, sorry.
=A0
- maoke
=A0

I really wonder if this is getting anywhere - as soon as one crazy reason why this draft can not proceed has been silenced with 200+ e-mails, the
next one springs up.

Could people please focus on this draft, and not on "what other byzant= ine
migration schemes might exist or not, and might want to be mentioned or
should not mentioned in this draft"?

I already deleted about a 100 unread mails in this thread today, because some of us really have work to do.

Gert Doering
=A0 =A0 =A0 =A0 -- IPv6 Operator, hoping to see IPv6 deployment in mobile n= etworks,
=A0 =A0 =A0 =A0 =A0 =A0and *this* is an important piece.
--
have you enabled IPv6 on something today...?

SpaceNet AG =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Vorstand: Sebast= ian v. Bomhard
Joseph-Dollinger-Bogen 14 =A0 =A0 =A0 =A0 =A0Aufsichtsratsvors.: A. Grundne= r-Culemann
D-80807 Muenchen =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 HRB: 136055 (AG Muench= en)
Tel: += 49 (89) 32356-444 =A0 =A0 =A0 =A0 =A0 =A0USt-IdNr.: DE813185279

--047d7b603c129fd7a104c9605d29-- From fibrib@gmail.com Mon Sep 10 15:32:42 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7DBF21F86A3 for ; Mon, 10 Sep 2012 15:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.096 X-Spam-Level: X-Spam-Status: No, score=-3.096 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5T2uIpZd4Zh for ; Mon, 10 Sep 2012 15:32:41 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id DC3FF21F869A for ; Mon, 10 Sep 2012 15:32:40 -0700 (PDT) Received: by eekb45 with SMTP id b45so1589271eek.31 for ; Mon, 10 Sep 2012 15:32:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zbBo8iseNaMo+un3IkSEIicOGZZ/i8hIG/sMwxI7Dgs=; b=dDeIWjR53buiiISLNOSnl5F8SkeRThIkCEu4hHI4xYCAcHDj5jSohohxnGvb4uVGAW 8BlUl8vTXY+R7QTLXUWn/BuSOKFT2nyHs4r2NhuWfFUuBAVfo0sU1/bfhrHkCqCoeZ96 kTIQ4FNwG2aBmqv8n3w/aqftwOMoxU3opalwqCYOzaI4BzpeQwoeEDjlzbVbkXFfkxTU i5AZdSyCzmgnBA/IJRs16h7ajUbK+mZXo3EqN41YMIWV/ypZTo0A2V4KlJB3M2T6bcPE fuzeqFTo482cezyCrRpV0imqGD02MBLFxZknH6n3BoQGdw/0S9FVXviyF+NOKwo0maZ3 U2SQ== MIME-Version: 1.0 Received: by 10.14.172.129 with SMTP id t1mr22231515eel.34.1347316360041; Mon, 10 Sep 2012 15:32:40 -0700 (PDT) Received: by 10.14.97.9 with HTTP; Mon, 10 Sep 2012 15:32:39 -0700 (PDT) In-Reply-To: <88D1CFAA-0D4A-4B98-AD50-B10CEC5B4933@laposte.net> References: <810EAE3D-8767-4E66-911D-3DBDFE8B9403@laposte.net> <4730A653-CD11-4A08-9254-2C80C739D646@laposte.net> <88D1CFAA-0D4A-4B98-AD50-B10CEC5B4933@laposte.net> Date: Tue, 11 Sep 2012 07:32:39 +0900 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=047d7b603c120a565a04c9608912 Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 22:32:42 -0000 --047d7b603c120a565a04c9608912 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/9/11 R=E9mi Despr=E9s > > Le 2012-09-10 =E0 18:22, Maoke a =E9crit : > > > > 2012/9/11 R=E9mi Despr=E9s > >> >> Le 2012-09-10 =E0 17:34, Maoke a =E9crit : >> >> >> >> 2012/9/11 R=E9mi Despr=E9s >> >>> >>> 2012-09-10 16:29, Maoke : >>> >>> >>> 2012/9/10 R=E9mi Despr=E9s >>> >>>> Maoke, >>>> >>>> After your insisting that I comment the detailed example below you had >>>> addressed to lorenzo, let me do it first priority, for the sake of 464= XLAT >>>> quick progress. >>>> >>>> >>> >>> i reply Lorenzo but cc to the WG and i suppose that the text that i >>> would like to share to all. thanks a lot for taking it in priority. >>> >>> >>>> >>>> >>>> Your example has an IPv4-only host that is supposed to get a public A >>>> record and another A record that would be derived from a AAAA by a BI= H. >>>> This isn't AFAIK a realistic scenario for at least the following >>>> reasons: >>>> (1) BIH address mapping doesn't apply when both AAAA and A records are >>>> received and the A address in not an excluded one (section 2.4 of RFC6= 535). >>>> >>>> >>> >>> thanks for the link of the text. i didn't notice that. but this only >>> prevents CLAT sending things to A#2. what if the packet is delivered to= the >>> BIH module? >>> >>> >>> BIH doesn't apply AT ALL when both an A and a AAAA are received for a >>> server. >>> Your example being AFAIK in this case, no conflict between BIH and >>> anything else can exist. >>> >>> >>> actually the missing part is, when we are talking "combining" two >>> things, we should at least specify they are working parallel, selected = by >>> the path decision mechanism, or serially. if parallel, how to select th= e >>> path; if serial, who is in front who is behind? >>> >>> >>> 464XLAT applies to reach public IPv4 addresses, and BIH to reach server= s >>> that have no public IPv4 address. >>> >>> >> >> the first DNS request is taken by BIH or by 464xlat? it is highly >> possible to be 464xlat, no matter the result is A or AAAA, right? how th= e >> BIH can get the information about that AAAA and/or A? the path seems to = me >> has no business with the BIH though. >> >> >> A DNS request from an IPv4-only host has, as you say, "no business with >> the BIH" (like any packet from such a host to a public IPv4 address). >> >> > > not only that. then the IPv4 host may possibly get a AAAA-type reply from > the DNS system (surely an IPv4 DNS server can reply AAAA-type for a > request). then the reply will be sent by the IPv4 DNS server (through PLA= T > and CLAT) to the host, right? there's no business of BIH even if the targ= et > server is IPv6-only. > > and therefore the IPv4-only host, getting the AAAA stuff, can do nothing > with it. only when the BIH stands between the IPv4-only host and the CLAT= , > it is possible that the BIH hijack the AAAA reply and synthesize a A repl= y > for the host. > > but there should be a dilemma in such a serial workflow: if there is the > genuine A reply, BIH module needs to transparently deliver that to the ho= st > and accepts the further packets from the host and transparently forward > that to the CLAT module. does BIH work as a transparent router to genuine > IPv4 destinations? (i don't understand RFC6535 saying so but need to > confirm) > > > > dear Remi, is it hard for you to teach me a little more about the above rather than asking me "acceptable"? if you think this is trivial, please do it offline. i really want to know. i don't care about the draft wording anymore. i don't think all the RFC are good in the same quality in the history -- it is acceptable. had i not noticed the problem the WG would have processed it. if others are silent, i don't need to make things difficult for everyone. or you may totally ignore my *noise*. okay. though you are very busy, i make the deal: you promise to teach me about the above behavior offline; i stop my objection no matter what i get to understand through the education. acceptable? - maoke > > >> >> >> >> if i missed anything, please specify further. it is fine to me that the >> below is left aside. >> >> >> Unless I miss something, this puts an end of the technical concern that >> 464XLAT and BIH might not gracefully coexist. >> Preferred sentence is then: >> "464XLAT is not designed to cover the case of IPv4-only applications >> having access to IPv6-only servers. If that is needed, BIH of [RFC6535] >> provides a solution." >> >> Acceptable? >> >> > > i prefer Tim's suggestion not to mention any specific protocol here but > only > "... If that is needed, another transition mechanism should be > considered". > > > You say you "prefer" this other wording (which hides useful information) > but, in view of your next sentence below, you even refuse the wording tha= t > you don't prefer! > > Frankly, this is one more disappointment after so much effort to teach yo= u > what BIH does. > > > if we are definitely to cite the BIH explicitly here, i think we are > obliged to state: > "This BCP doesn't guarantee that they are gracefully working > together while leave the co-existance details as an open issue." > > > There is absolutely no justification for such a negative sentence! > - If you no reason is identified why 464XLAT and BIH wouldn't gracefully > coexist, suggesting one exists is unacceptable. > - Especially since > . Some others who have carefully studied both 464XLAT and BIH for quite > some time have found no reason to doubt. > . One an implementation is in progress. > . All your past reasons to doubt have been answered. > > So, let me ask again whether you can consider the following sentence as > ACCEPTABLE? > "464XLKAT is not designed to cover the case of IPv4-only applications > having access to IPv6-only servers. If that is needed, BIH of [RFC6535] > provides a solution." > > RD > > > > > > - maoke > > >> >> RD >> >> >> >> >> - maoke >> >> >>> >>> The order in which their applicability is tested is therefore irrelevan= t. >>> >>> >>> (2) BIH is only for applications that are in the BIH node itself. As >>>> such, it must not forward AAAA-derived IPv4 addresses to any other nod= e. >>>> (These addresses are taken in a private address pool). >>>> >>>> >>> >>> confusing to me. CLAT is able to work for a subnet where the hosts are. >>> what the applications does the BIH/CLAT box itself have in the 464xlat >>> architecture. >>> >>> >>> Let's leave this aside, at least for the time being, the point above >>> being sufficient (if you authorize me to work withy high priority only = on >>> points that condition decisions to be made ;-)) >>> >>> >>> >>> and according to the discussion linked by Gang to me, there was the >>> discussion that people said the BIH was not designed for forwarding but >>> replies stated it was able to do so. >>> >>> >>> Can we please limit this discussion about what BIH does to what there i= s >>> in the RFC itself (at least in a first step, which hopefully will be >>> sufficient). >>> >>> RD >>> >>> >>> >> >> > > --047d7b603c120a565a04c9608912 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/9/11 R=E9mi Despr=E9s <desp= res.remi@laposte.net>

Le 2012-09-10 =E0 18:22, = Maoke a =E9crit :



2012/9/11 R=E9mi Despr=E9s <des= pres.remi@laposte.net>

Le 2012-09-10 =E0 17:34, = Maoke a =E9crit :



2012/9/11 R=E9mi Despr=E9s <despres.remi@laposte= .net>

2012-09-10 16:29, Maoke :=


201= 2/9/10 R=E9mi Despr=E9s <despres.remi@laposte.net>
Maoke,

After your in= sisting that I comment the detailed example below you had addressed to lore= nzo,=A0let me do it first priority, for the sake of 464XLAT quick progress.=
=A0
=A0
i reply Lorenzo but cc = to the WG and i suppose that the text that i would like to share to all. th= anks a lot for taking it in priority.
=A0
=A0

Your = example has an IPv4-only host that is supposed to get a public A record and= another A record that would be derived from =A0a AAAA by a BIH.
= This isn't AFAIK a realistic scenario for at least the following reason= s:
(1)=A0BIH address mapping doesn't apply when both AAAA and A recor= ds are received and the A address in not an excluded one (section 2.4 of RF= C6535).
=A0
=A0
thanks for= the link of the text. i didn't notice that. but this only prevents CLA= T sending things to A#2. what if the packet is delivered to the BIH module?=

BIH doesn't apply AT ALL w= hen both an A and a AAAA are received for a server.
Your example = being AFAIK in this case, no conflict between BIH and anything else can exi= st.=A0

=A0
actually the missing part is, when we are talking "= combining" two things, we should at least specify they are working par= allel, selected by the path decision mechanism, or serially. if parallel, h= ow to select the path; if serial, who is in front who is behind?

464XLAT applies to reach publi= c IPv4 addresses, and BIH to reach servers that have no public IPv4 address= .
=A0
=A0
the first = DNS request is taken by BIH or by 464xlat? it is highly possible to=A0be 46= 4xlat, no matter the result is A or AAAA, right? how the BIH can get the in= formation about that AAAA and/or A? the path seems to me has no business wi= th the BIH though.

A DNS request from an IPv4-onl= y host has, as you say, "no business with the BIH" (like any pack= et from such a host to a public IPv4 address).
=A0
=A0
not only that. then the IPv4 host may possi= bly get a AAAA-type reply from the DNS system (surely an IPv4 DNS server ca= n reply AAAA-type for a request). then the reply will be sent by the IPv4 D= NS server (through PLAT and CLAT) to the host, right? there's no busine= ss of BIH even if the target server is IPv6-only.
=A0
and therefore the IPv4-only host, getting the AAAA stuff= , can do nothing with it. only when the BIH stands between the IPv4-only ho= st and the CLAT, it is possible that the BIH hijack the AAAA reply and synt= hesize a A reply for the host.
=A0
but there should be a dilemma in such a serial workflow:= if there is the genuine A reply, BIH module needs to transparently deliver= that to the host and accepts the further packets from the host and transpa= rently forward that to the CLAT module. does BIH work=A0as a transparent ro= uter to=A0genuine IPv4 destinations?=A0(i don't understand RFC6535 sayi= ng so but need to confirm)
=A0
=A0
=A0
dear Remi, is it hard for you to teach me a lit= tle more about the above rather than asking me "acceptable"? if y= ou think this is trivial, please do it offline. i really want to know.
=A0
i don't care about the draft wording anymore.=A0i=A0= don't think all the RFC are good in the same quality=A0in the history= =A0--=A0it is acceptable.=A0had i not=A0noticed the problem the=A0WG=A0woul= d have=A0processed it.=A0if=A0others are silent, i don't need to make t= hings difficult for everyone. or you may totally ignore my *noise*.
=A0
okay. though you are very busy, i make the deal: you pro= mise to teach me=A0about the above behavior offline;=A0i stop my objection= =A0no matter what=A0i=A0get to understand through the education. acceptable= ?
=A0
- maoke
=A0
=A0


if i missed anything, please specify further. it is fine to me that th= e below is left aside.

U= nless I miss something, this puts an end of the technical concern that 464X= LAT and BIH might not gracefully=A0coexist.=A0
Preferred sentence is then:
"464XLAT is not designed to= cover the case of IPv4-only applications having access to IPv6-only server= s. If that is needed, BIH of=A0[RFC6535] provides=A0a solution."

Acceptable?
=A0
=A0
i prefer Tim's suggestion not to mention any specif= ic protocol here but only
=A0=A0=A0=A0 "... If that is need= ed, another transition mechanism should be considered".=A0

You say you "prefer= " this other wording (which hides useful information) but, in view of = your next sentence below, you even refuse the wording that you don't pr= efer!

Frankly, this is one more disappointment after so much = effort to teach you what BIH does.


if we=A0are definitely to=A0cite the BIH explicitly=A0here, i think we= are obliged to=A0state:
=A0=A0=A0 =A0"This BCP doesn't = guarantee that=A0they are gracefully working together=A0while leave the co-= existance details=A0as an open issue."

There is absolutely no justifi= cation for such a negative sentence!
- If you no reason is identi= fied why 464XLAT and BIH wouldn't gracefully coexist, suggesting one ex= ists is unacceptable.
- Especially since=A0
=A0. Some others who have carefully st= udied both 464XLAT and BIH for quite some time have found no reason to doub= t.=A0
=A0. One an implementation is in progress.
=A0. A= ll your past reasons to doubt have been answered.

So, let me ask again whether you can consider the follo= wing sentence as ACCEPTABLE?
"464XLKAT is not designed to co= ver the case of IPv4-only applications having access to IPv6-only servers. = If that is needed, BIH of=A0[RFC6535] provides=A0a solution."

RD
=




=A0
- maoke
=A0
=A0
RD



<= div>=A0
- maoke
=A0
=A0
The order in wh= ich their applicability is tested is therefore irrelevant.
<= br>

(2)=A0BIH is only for applications that are in the BIH node itself. As= such, it must not forward AAAA-derived IPv4 addresses to any other node. (= These addresses are taken in a private address pool).
=A0
=A0
confusing to me. CLAT is able to work for a= subnet where the hosts are. what the applications does the BIH/CLAT box it= self have=A0in the 464xlat architecture.

Let's leave this aside, at least for the time being, the po= int above being sufficient (if you authorize me to work withy high priority= only on points that condition decisions to be made ;-))
=A0
=A0
<= div>and according to the discussion linked by Gang to me, there was the dis= cussion that people said the BIH was not designed for forwarding but replie= s stated it was able to do so.

Can we please=A0limit this=A0d= iscussion about what BIH does to what there is in the RFC itself (at least = in a first step, which hopefully will be sufficient).

RD







--047d7b603c120a565a04c9608912-- From internet-drafts@ietf.org Mon Sep 10 16:52:42 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12B6921F8595; Mon, 10 Sep 2012 16:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.5 X-Spam-Level: X-Spam-Status: No, score=-102.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1I+X5sENqjE7; Mon, 10 Sep 2012 16:52:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA9B21F8540; Mon, 10 Sep 2012 16:52:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120910235241.16095.66733.idtracker@ietfa.amsl.com> Date: Mon, 10 Sep 2012 16:52:41 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-ivi-icmp-address-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 23:52:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Stateless Source Address Mapping for ICMPv6 Packets Author(s) : Xing Li Congxiao Bao Dan Wing Ramji Vaithianathan Geoff Huston Filename : draft-ietf-v6ops-ivi-icmp-address-06.txt Pages : 7 Date : 2012-09-10 Abstract: A stateless IPv4/IPv6 translator may receive ICMPv6 packets containing non IPv4-translatable addresses as the source. These packets should be passed across the translator as ICMP packets directed to the IPv4 destination. This document presents recommendations for source address translation in ICMPv6 headers to handle such cases. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-ivi-icmp-address There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-ivi-icmp-address-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-ivi-icmp-address-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From lorenzo@google.com Mon Sep 10 21:30:00 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5460021E803F for ; Mon, 10 Sep 2012 21:30:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.87 X-Spam-Level: X-Spam-Status: No, score=-102.87 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zzeo0gxeZOPF for ; Mon, 10 Sep 2012 21:29:59 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5E7E221E803D for ; Mon, 10 Sep 2012 21:29:48 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so140423obb.31 for ; Mon, 10 Sep 2012 21:29:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=VcgLmy9K4L5rqk1J7Fp0R28zd6PvVT/jdP/OlFYsLCs=; b=odC/XdjnxWJSZu8UmntJWiW14w3HTNdvlnepCF8JjgTAeT1nuUeqI+JnMwcJTwXS2S JxN5r8xdY5er9DtO95GzQUG1iU9cZBuGdqenqMAPIEo2b04Vn4obNkdvLV5MjpYwdUc1 dKFbNTPf6qE7FNU+Z+C4LqfXT9SKk4rpPRf4D5iu7HdMRHv4sohUjSuyMIIKuPfB3xUJ C8/adFrvrSHOjeyJ83vHq4y7T8IGQx69/UYrTXuFTQLArRY6wXjkeMgGyz2NaSDsd4j5 TiIuQOH4ljUrnv7hBWkqnfSLPoMveQv2sFNPWiTvyGin1wfyjA6Kfshe9yeLKzuZiTrB UFPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=VcgLmy9K4L5rqk1J7Fp0R28zd6PvVT/jdP/OlFYsLCs=; b=kT7Rw/RIT6tqrn8r8eYZYw1r7R5qHGbTOkY1B+nux9s3MjilqIF86FhhBB5vI+yw87 S4bBjGusC6g1Vk7w2PPL9VkhRUsSjrGnVCAoMPefi0LOykx2IjUtcHQchFnClsLsADIm ymS9sn4HRkEkqi76a5004vFcSJQEqg/t4hI/nAy79lrsdjjczWSZd58YdOOSTz6X3ue/ OTPGVvM8V+JucvyONxDoOPW87kfsphNhGv4kJdo+M8s1rKtNt5ZonU4KCO6d+1pdtnBs d1oeAHT2ah/njvIAvhVPMlZjcxuVlESQZ2jWuN2RBKCK0Cl2+gHqdwX4QJzxu+IsBF8o mfsQ== Received: by 10.60.170.229 with SMTP id ap5mr16359944oec.101.1347337788394; Mon, 10 Sep 2012 21:29:48 -0700 (PDT) Received: by 10.60.170.229 with SMTP id ap5mr16359936oec.101.1347337788289; Mon, 10 Sep 2012 21:29:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.187.8 with HTTP; Mon, 10 Sep 2012 21:29:28 -0700 (PDT) In-Reply-To: References: <504392E0.8070802@bogus.com> <448050D4-84F9-4F52-BF7E-347EA451A96C@laposte.net> <041e01cd8ce7$61aeebc0$4001a8c0@gateway.2wire.net> <2808F812-B159-4F99-A7A1-C6B159EABBA0@laposte.net> <7298FD2A-55D5-4437-A890-53AF041AB03D@laposte.net> From: Lorenzo Colitti Date: Tue, 11 Sep 2012 13:29:28 +0900 Message-ID: To: Wojciech Dec Content-Type: multipart/alternative; boundary=bcaec54b4ac04372b204c965869c X-System-Of-Record: true X-Gm-Message-State: ALoCoQlWO16SC2EVfs/sAQgGSDevt1q8Mvsj2AJ7ffJ2ByJhYJahRyj+Okz0wvJ5P3H8vbI2I2yz2e/H5S0BebGxZ9UsPQAo/pNvZQWq7nB4aXJk8rLhY6c1FUrgvwX5GLFPdXEyka10CJdXZqp3Wntyvzfkwxsm1urQkNWHKDX/f7gXZFvkMu9OaWa3lPVFTtJqtP9QbfCB Cc: v6ops WG Subject: Re: [v6ops] 464XLAT - support of /64 delegated prefixes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 04:30:00 -0000 --bcaec54b4ac04372b204c965869c Content-Type: text/plain; charset=ISO-8859-1 On Mon, Sep 10, 2012 at 10:38 PM, Wojciech Dec wrote: > - If we're talking about subtended IPv6 devices and sharing a /64, then > the IANA assignment lead to ND hacks, some new form of SLAAC; best left for > handling via DHCP PD. > Not sure I agree with this last point, because I'm not sure what you mean. I assert that the following scenario: - CLAT with only one public IPv6 /64 - With a p2p northbound interface and a broadcast downstream interface - Sharing the /64 to directly connected downstream clients Can be done robustly, with no ND proxy hacks at all (with or without IANA assignment). Do you agree? I agree that IPv6 more than one level deep, (e.g., with cascading CLATs), cannot be done without hacks, and that these hacks don't really work. For this situation we must require DHCPv6 PD. --bcaec54b4ac04372b204c965869c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Sep 10, 2012 at 10:38 PM, Wojciech Dec <wdec.ietf@gmail.com&= gt; wrote:
- If we're talking about subtended IPv6= devices and sharing a /64, then the IANA assignment lead to ND hacks, some= new form of SLAAC; best left for handling via DHCP PD.

Not sure I agree with this last point, because I'm = not sure what you mean.=A0I assert that the following scenario:
<= ul>
  • CLAT with only one public IPv6 /64
  • With a p2p northbound int= erface and a broadcast downstream interface
  • Sharing the /64 to directly connected downstream clients
    • = Can be done robustly, with no ND proxy hacks at all (with or without IANA a= ssignment). Do you agree?

    I agree that IPv6 = more than one level deep, (e.g., with cascading CLATs), cannot be done with= out hacks, and that these hacks don't really work. For this situation w= e must require DHCPv6 PD.
    --bcaec54b4ac04372b204c965869c-- From tjc@ecs.soton.ac.uk Mon Sep 10 23:43:43 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A33621F8724 for ; Mon, 10 Sep 2012 23:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hnASIGShBMZP for ; Mon, 10 Sep 2012 23:43:42 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 1533621F857E for ; Mon, 10 Sep 2012 23:43:41 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q8B6hZF8010057; Tue, 11 Sep 2012 07:43:35 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk q8B6hZF8010057 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1347345815; bh=39OEcnl55vPtakc+W+A2lsCHSgg=; h=References:In-Reply-To:Mime-Version:Cc:From:Subject:Date:To; b=bEd4MbuYPDXgWieIC29E8NpVhzRXsSZ3KOoQi17MKdMfK6HLsUUQARdD+/YWAcHzH Xq+V4qzrH79c1CTtutMINZtAuCFyfC2X2L6+2AFeHltjFH5uzXXFZPOTLoWzsWf9RE yD9cH1OhnYm8iosVPG4nhW/TKMSbIbWvL8yHj4w8= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id o8A7hZ0430618354PW ret-id none; Tue, 11 Sep 2012 07:43:35 +0100 Received: from [192.168.1.101] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q8B6hUF9003756 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 11 Sep 2012 07:43:31 +0100 References: <810EAE3D-8767-4E66-911D-3DBDFE8B9403@laposte.net> <4730A653-CD11-4A08-9254-2C80C739D646@laposte.net> <20120910180231.GV13776@Space.Net> <7AB4B335-22DE-497C-A854-ACB560F2DE64@ecs.soton.ac.uk> In-Reply-To: <20120910180231.GV13776@Space.Net> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-ID: X-Mailer: iPad Mail (9B206) From: Tim Chown Date: Tue, 11 Sep 2012 07:44:40 +0100 To: Gert Doering X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=o8A7hZ043061835400; tid=o8A7hZ0430618354PW; client=relay,ipv6; mail=; rcpt=; nrcpt=3:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: q8B6hZF8010057 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 06:43:43 -0000 On 10 Sep 2012, at 19:02, Gert Doering wrote: > Hi, >=20 > On Tue, Sep 11, 2012 at 01:22:50AM +0900, Maoke wrote: >> and therefore the IPv4-only host, getting the AAAA stuff, can do nothing >> with it. only when the BIH stands between the IPv4-only host and the CLAT= , >> it is possible that the BIH hijack the AAAA reply and synthesize a A repl= y >> for the host. >=20 > What, exactly, does this have to do with the draft at hand? >=20 > There are no IPv*4*-only hosts here. There's an IPv6-only host, which > can do IPv4 by help of 464xlat. So BIH does not apply at all. >=20 > I really wonder if this is getting anywhere - as soon as one crazy reason > why this draft can not proceed has been silenced with 200+ e-mails, the > next one springs up. >=20 > Could people please focus on this draft, and not on "what other byzantine > migration schemes might exist or not, and might want to be mentioned or > should not mentioned in this draft"? >=20 > I already deleted about a 100 unread mails in this thread today, because > some of us really have work to do. This.=20 Please do not add a reference to BIH or any other similar solution to a docu= ment that is a BCP addressing a completely different problem. If you want to consider BIH's applicability to different problem then write a= n Informational draft on BIH in this context. Tim= From fred@cisco.com Tue Sep 11 00:07:50 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0557421F8539 for ; Tue, 11 Sep 2012 00:07:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QMEowilSKhh5 for ; Tue, 11 Sep 2012 00:07:49 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 611B221F8534 for ; Tue, 11 Sep 2012 00:07:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=337; q=dns/txt; s=iport; t=1347347269; x=1348556869; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=CB0J2H5PBEfdmMwRcxqqgJT25p4wDmHGPEz/Ma3wpsg=; b=DOboXYfoiMpSsNZ4VAMLZYoWdOIIsSww4GUCcgU4Wxbtyp69mNh9XYBV KHkw35rK/PDOv/ZKH6zqW9hn3CB7z1Jj8p7qhqy68duT99853mD0q6mbP zfmadF+9txUaAWOtB7s5SDg4MJ3NmlnX++o7kg3pRGuTuqIO6rbdtpOUx Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmoFAHPiTlCtJV2b/2dsb2JhbABFhUC2D4EHgicSASc0HQE+QicENYduC5oxgSigOQSLDIVWYAOVXY42gWeCZg X-IronPort-AV: E=Sophos;i="4.80,402,1344211200"; d="scan'208";a="120284140" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 11 Sep 2012 07:07:49 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q8B77meF004253 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 11 Sep 2012 07:07:49 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.97]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.001; Tue, 11 Sep 2012 02:07:48 -0500 From: "Fred Baker (fred)" To: v6ops WG Thread-Topic: Get yer drafts in... Thread-Index: AQHNj+wlhX0uzEcEoEOg6yTml+M14w== Date: Tue, 11 Sep 2012 07:07:47 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.244.221] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19176.004 x-tm-as-result: No--27.108300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [v6ops] Get yer drafts in... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 07:07:50 -0000 The last date to file a -00 draft for IETF 85 will be 10/15/2012, says http= s://www.ietf.org/meeting/cutoff-dates-2012.html#IETF85. Since you will want= to get working group discussion on the mailing list (which is how you get = air time during the meeting), I'd suggest you be thinking about them and po= sting them this month.= From phdgang@gmail.com Tue Sep 11 00:22:11 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 888FC21E8041 for ; Tue, 11 Sep 2012 00:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.098 X-Spam-Level: X-Spam-Status: No, score=-3.098 tagged_above=-999 required=5 tests=[AWL=-0.099, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TpO1iV8FWPHm for ; Tue, 11 Sep 2012 00:22:11 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id D99BB21E803F for ; Tue, 11 Sep 2012 00:22:10 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so259094vcb.31 for ; Tue, 11 Sep 2012 00:22:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=O5m6hTSyYOymSPgxCI0nTm7Sx+jjcwjtaAqEPnQfnDU=; b=lQu6nlKFpqUtKxV1beYGp3bOK2t1Ak2g2nNlzZGH6v+JDQgIroFdG4Ltmod2qB811U HdpeUvRFyLTEVJB/sRJX48HzCkGUnEh3hE37yn2TNTl6SkShYtJgtw64ecYfmYbiQ60V /GLHsZfLsalfjS2Pb4nNAU9JD784wDSZuLIVaRQTXBEdALJHGfhr+FCP2m+fghbbZyIl 5p+rOzXUGxnBXqgc5954sxiU9bc21vxesPmZCtdmsWZRu6e4A2OQkuMYs/DeO8zte4rX 1NQwDYkCGDc8L2sVomzahtvOfBDZfFUIYgdxgIEGFSDGprCe9XiReuG0Bn6MZpQtMESe 7LyQ== MIME-Version: 1.0 Received: by 10.220.209.80 with SMTP id gf16mr23623945vcb.58.1347348130303; Tue, 11 Sep 2012 00:22:10 -0700 (PDT) Received: by 10.58.114.231 with HTTP; Tue, 11 Sep 2012 00:22:10 -0700 (PDT) In-Reply-To: References: <810EAE3D-8767-4E66-911D-3DBDFE8B9403@laposte.net> <4730A653-CD11-4A08-9254-2C80C739D646@laposte.net> <7AB4B335-22DE-497C-A854-ACB560F2DE64@ecs.soton.ac.uk> <20120910180231.GV13776@Space.Net> Date: Tue, 11 Sep 2012 15:22:10 +0800 Message-ID: From: GangChen To: Tim Chown Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 07:22:11 -0000 Hello Tim, 2012/9/11, Tim Chown : > On 10 Sep 2012, at 19:02, Gert Doering wrote: > >> Hi, >> >> On Tue, Sep 11, 2012 at 01:22:50AM +0900, Maoke wrote: >>> and therefore the IPv4-only host, getting the AAAA stuff, can do nothing >>> with it. only when the BIH stands between the IPv4-only host and the >>> CLAT, >>> it is possible that the BIH hijack the AAAA reply and synthesize a A >>> reply >>> for the host. >> >> What, exactly, does this have to do with the draft at hand? >> >> There are no IPv*4*-only hosts here. There's an IPv6-only host, which >> can do IPv4 by help of 464xlat. So BIH does not apply at all. >> >> I really wonder if this is getting anywhere - as soon as one crazy reason >> why this draft can not proceed has been silenced with 200+ e-mails, the >> next one springs up. >> >> Could people please focus on this draft, and not on "what other byzantine >> migration schemes might exist or not, and might want to be mentioned or >> should not mentioned in this draft"? >> >> I already deleted about a 100 unread mails in this thread today, because >> some of us really have work to do. > > This. > > Please do not add a reference to BIH or any other similar solution to a > document that is a BCP addressing a completely different problem. I can't agree with your arguments. There are not only discussions of 100+ mails, but dedicated implementation efforts. It doesn't make sense to ignore people's efforts that make the solution more complete without any identified issues. > If you want to consider BIH's applicability to different problem then write > an Informational draft on BIH in this context. BIH didn't apply to different problem, which is already clarified with current proposal *464XLKAT is not designed to cover the case of IPv4-only applications having access to IPv6-only servers. If that is needed, BIH of [RFC6535] provides a solution.* BIH is indeed qualified to the context statement and already justified in RFC6535, no informational part needed IMHO. BRs Gang > Tim > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From fibrib@gmail.com Tue Sep 11 00:44:15 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1779821F8700 for ; Tue, 11 Sep 2012 00:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.743 X-Spam-Level: X-Spam-Status: No, score=-2.743 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGG50Nf1nLvR for ; Tue, 11 Sep 2012 00:44:14 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id E164121F8701 for ; Tue, 11 Sep 2012 00:44:13 -0700 (PDT) Received: by eaai11 with SMTP id i11so95166eaa.31 for ; Tue, 11 Sep 2012 00:44:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eVVgi88hKv7F1EoZWG7ESoLb+tCK3neVxNMwN1yscng=; b=OTK1ZBjcSWmteBMLiql/2OtZkuRJYI5lyNv9Z1cAnCuWLdIV8vzoQtYPv85BIP0zNL 4iVUnBO5jGC8Npu0Z+diGcV16RLBvv69+A0cKeoNnGkst0mDqbDgBlDjHgS/YRgBw43j 2DiAFEXtaqx3gtccAElwsjKonJYTw9WygBEZZCR1jJlo5TKSrammd2VVWR9YF+RGTX9X Pn48orojZjVEKOCQ/vJ0R/Ju2+ZoHP2OTU9eLnOwrdVC/CF/DjHNHH+EXbem8kYxK3uM hzISd3c+zZjyoa7b5eIrAxMWaGlkA3geu2suA6pNHUOMr9x/O+IcRQUA2to/9qsPgVz6 bbew== MIME-Version: 1.0 Received: by 10.14.184.134 with SMTP id s6mr23799208eem.46.1347349452961; Tue, 11 Sep 2012 00:44:12 -0700 (PDT) Received: by 10.14.97.9 with HTTP; Tue, 11 Sep 2012 00:44:12 -0700 (PDT) In-Reply-To: References: <810EAE3D-8767-4E66-911D-3DBDFE8B9403@laposte.net> <4730A653-CD11-4A08-9254-2C80C739D646@laposte.net> <7AB4B335-22DE-497C-A854-ACB560F2DE64@ecs.soton.ac.uk> <20120910180231.GV13776@Space.Net> Date: Tue, 11 Sep 2012 16:44:12 +0900 Message-ID: From: Maoke To: GangChen Content-Type: multipart/alternative; boundary=047d7b3a7ff8883a9c04c9683dff Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 07:44:15 -0000 --047d7b3a7ff8883a9c04c9683dff Content-Type: text/plain; charset=ISO-8859-1 2012/9/11 GangChen > Hello Tim, > > 2012/9/11, Tim Chown : > > On 10 Sep 2012, at 19:02, Gert Doering wrote: > > > >> Hi, > >> > >> On Tue, Sep 11, 2012 at 01:22:50AM +0900, Maoke wrote: > >>> and therefore the IPv4-only host, getting the AAAA stuff, can do > nothing > >>> with it. only when the BIH stands between the IPv4-only host and the > >>> CLAT, > >>> it is possible that the BIH hijack the AAAA reply and synthesize a A > >>> reply > >>> for the host. > >> > >> What, exactly, does this have to do with the draft at hand? > >> > >> There are no IPv*4*-only hosts here. There's an IPv6-only host, which > >> can do IPv4 by help of 464xlat. So BIH does not apply at all. > >> > >> I really wonder if this is getting anywhere - as soon as one crazy > reason > >> why this draft can not proceed has been silenced with 200+ e-mails, the > >> next one springs up. > >> > >> Could people please focus on this draft, and not on "what other > byzantine > >> migration schemes might exist or not, and might want to be mentioned or > >> should not mentioned in this draft"? > >> > >> I already deleted about a 100 unread mails in this thread today, because > >> some of us really have work to do. > > > > This. > > > > Please do not add a reference to BIH or any other similar solution to a > > document that is a BCP addressing a completely different problem. > > I can't agree with your arguments. > There are not only discussions of 100+ mails, but dedicated > implementation efforts. > It doesn't make sense to ignore people's efforts that make the > solution more complete without any identified issues. > > > If you want to consider BIH's applicability to different problem then > write > > an Informational draft on BIH in this context. > > BIH didn't apply to different problem, which is already clarified with > current proposal *464XLKAT is not designed to cover the case of > IPv4-only applications having access to IPv6-only servers. If that is > needed, BIH of [RFC6535] provides a solution.* > i am still waiting for your and Remi's offline discussion as the condition to accept the proposed text. i won't object anymore if you just do the offline discussion. if you don't, sorry, seeing "already clarified" is not yet qualified for the time being. - maoke > BIH is indeed qualified to the context statement and already justified > in RFC6535, no informational part needed IMHO. > > BRs > > Gang > > > > Tim > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --047d7b3a7ff8883a9c04c9683dff Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

    2012/9/11 GangChen <= ;phdgang@gmail.com>
    Hello Tim,

    2012/9/11, Tim Chown <    tjc@ecs.sot= on.ac.uk>:
    > On 10 Sep 2012, at 19:02, Gert Doering <gert@space.net> wrote:
    >
    >> Hi,
    >>
    >> On Tue, Sep 11, 2012 at 01:22:50AM +0900, Maoke wrote:
    >>> and therefore the IPv4-only host, getting the AAAA stuff, can = do nothing
    >>> with it. only when the BIH stands between the IPv4-only host a= nd the
    >>> CLAT,
    >>> it is possible that the BIH hijack the AAAA reply and synthesi= ze a A
    >>> reply
    >>> for the host.
    >>
    >> What, exactly, does this have to do with the draft at hand?
    >>
    >> There are no IPv*4*-only hosts here. =A0There's an IPv6-only h= ost, which
    >> can do IPv4 by help of 464xlat. =A0So BIH does not apply at all. >>
    >> I really wonder if this is getting anywhere - as soon as one crazy= reason
    >> why this draft can not proceed has been silenced with 200+ e-mails= , the
    >> next one springs up.
    >>
    >> Could people please focus on this draft, and not on "what oth= er byzantine
    >> migration schemes might exist or not, and might want to be mention= ed or
    >> should not mentioned in this draft"?
    >>
    >> I already deleted about a 100 unread mails in this thread today, b= ecause
    >> some of us really have work to do.
    >
    > This.
    >
    > Please do not add a reference to BIH or any other similar solution to = a
    > document that is a BCP addressing a completely different problem.

    I can't agree with your arguments.
    There are not only discussions of 100+ mails, but dedicated
    implementation efforts.
    It doesn't make sense to ignore people's efforts that make the
    solution more complete without any identified issues.

    > If you want to consider BIH's applicability to different problem t= hen write
    > an Informational draft on BIH in this context.

    BIH didn't apply to different problem, which is already clarified= with
    current proposal *464XLKAT is not designed to cover the case of
    IPv4-only applications having access to IPv6-only servers= . If that is
    needed, BIH of [RFC6535] provides a solution.*
    = =A0
    i am still waiting for your and Remi's offline discussion= as the condition to accept the proposed text. i won't object anymore i= f you just do the offline discussion. if you don't, sorry,=A0seeing &qu= ot;already clarified" is not yet=A0qualified for the time being.=A0- m= aoke
    =A0
    BIH is indeed qualified to the context statement and already justified
    in RFC6535, no informational part needed IMHO.

    BRs

    Gang


    > Tim
    > _______________________________________________
    > v6ops mailing list
    > v6ops@ietf.org
    > https://www.ietf.org/mailman/listinfo/v6ops
    >
    _______________________________________________
    v6ops mailing list
    v6ops@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/v6ops

    --047d7b3a7ff8883a9c04c9683dff-- From despres.remi@laposte.net Tue Sep 11 00:55:33 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46A1221F873B for ; Tue, 11 Sep 2012 00:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.504 X-Spam-Level: X-Spam-Status: No, score=-1.504 tagged_above=-999 required=5 tests=[AWL=0.444, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6MyVvpYcFF5 for ; Tue, 11 Sep 2012 00:55:32 -0700 (PDT) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.10]) by ietfa.amsl.com (Postfix) with ESMTP id 83D4021F8581 for ; Tue, 11 Sep 2012 00:55:31 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2202.sfr.fr (SMTP Server) with ESMTP id B66E07000147; Tue, 11 Sep 2012 09:55:30 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2202.sfr.fr (SMTP Server) with ESMTP id 4955370000B2; Tue, 11 Sep 2012 09:55:30 +0200 (CEST) X-SFR-UUID: 20120911075530300.4955370000B2@msfrf2202.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-52--324257399 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 11 Sep 2012 09:55:29 +0200 Message-Id: <26281E0F-99B2-4B3A-AB6E-8316A5D764C3@laposte.net> References: <504392E0.8070802@bogus.com> <448050D4-84F9-4F52-BF7E-347EA451A96C@laposte.net> <041e01cd8ce7$61aeebc0$4001a8c0@gateway.2wire.net> <2808F812-B159-4F99-A7A1-C6B159EABBA0@laposte.net> <7298FD2A-55D5-4437-A890-53AF041AB03D@laposte.net> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] 464XLAT - support of /64 delegated prefixes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 07:55:33 -0000 --Apple-Mail-52--324257399 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 2012-09-11 06:29, Lorenzo Colitti : > On Mon, Sep 10, 2012 at 10:38 PM, Wojciech Dec = wrote: > - If we're talking about subtended IPv6 devices and sharing a /64, = then the IANA assignment lead to ND hacks, some new form of SLAAC; best = left for handling via DHCP PD. >=20 > Not sure I agree with this last point, because I'm not sure what you = mean. I assert that the following scenario: > CLAT with only one public IPv6 /64 > With a p2p northbound interface and a broadcast downstream interface > Sharing the /64 to directly connected downstream clients > Can be done robustly, with no ND proxy hacks at all (with or without = IANA assignment). Do you agree? Without IANA registered assignment, a link has to be created between DAD = and CLAT modules, in order to exclude on the LAN addresses used by the = CLAT. This isn't necessary with CLAT-resreved IID ranges. Anything missed? >=20 > I agree that IPv6 more than one level deep, (e.g., with cascading = CLATs), cannot be done without hacks, and that these hacks don't really = work. For this situation we must require DHCPv6 PD. With only a /64, cascading prefix delegations isn't possible, an = therefore cascading CLATs. Anything missed? RD --Apple-Mail-52--324257399 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
    2012-09-11 06:29, Lorenzo Colitti :

    On Mon, Sep 10, 2012 at 10:38 PM, Wojciech Dec <wdec.ietf@gmail.com> wrote:
    - If we're talking about subtended IPv6 devices and sharing a /64, then the IANA assignment lead to ND hacks, some new form of SLAAC; best left for handling via DHCP PD.

    Not sure I agree with this last point, because I'm not sure what you mean. I assert that the following scenario:
    • CLAT with only one public IPv6 /64
    • With a p2p northbound interface and a broadcast downstream interface
    • Sharing the /64 to directly connected downstream clients
    Can be done robustly, with no ND proxy hacks at all (with or without IANA assignment). Do you agree?

    Without IANA registered assignment, a link has to be created between DAD and CLAT modules, in order to exclude on the LAN addresses used by the CLAT.
    This isn't necessary with CLAT-resreved IID ranges.
    Anything missed?



    I agree that IPv6 more than one level deep, (e.g., with cascading CLATs), cannot be done without hacks, and that these hacks don't really work. For this situation we must require DHCPv6 PD.

    With only a /64, cascading prefix delegations isn't possible, an therefore cascading CLATs.
    Anything missed?

    RD

    --Apple-Mail-52--324257399-- From phdgang@gmail.com Tue Sep 11 01:01:15 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0793721F8793 for ; Tue, 11 Sep 2012 01:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.092 X-Spam-Level: X-Spam-Status: No, score=-3.092 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYkNQPXFIYRy for ; Tue, 11 Sep 2012 01:01:14 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3794521F8786 for ; Tue, 11 Sep 2012 01:01:14 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so302344vcb.31 for ; Tue, 11 Sep 2012 01:01:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RcccIpfvehp3RaGKlpasVS8TqJiCQb2qVMmInlDMe/8=; b=k+BqUguEvf6Z/MDzOixFWNS2ItvQxOKPzYI5Yz9W8MFoqo6gwSGsA9fSE/bvLfSySg fA9aEx5Yzn5TXzAP0NxIwlncrHPbaCq9juR1mgxa3jI/+Mo6TBbmJvkDAGis3q6qPM9g IwKj1qOnceWhMT0s9/ZanN6o4NWiV0niJ9loryaVJf6r+SyigYDrnywUCTK4Y+dwGhT6 xtaS5TKRZ5REppKlPWpIEMeQWWCMPRIChsXp/171CESQ5QC5BHeUROG9sXRAyO70oCcD iRdOcLV5x/PuuF4xS5tApcziYcIYOdAzyIcIUHOBqXKByTuIYqjpYDeTpJwHQIslRGRh T0Qg== MIME-Version: 1.0 Received: by 10.220.157.16 with SMTP id z16mr1678386vcw.29.1347350473488; Tue, 11 Sep 2012 01:01:13 -0700 (PDT) Received: by 10.58.114.231 with HTTP; Tue, 11 Sep 2012 01:01:13 -0700 (PDT) In-Reply-To: References: <810EAE3D-8767-4E66-911D-3DBDFE8B9403@laposte.net> <4730A653-CD11-4A08-9254-2C80C739D646@laposte.net> <7AB4B335-22DE-497C-A854-ACB560F2DE64@ecs.soton.ac.uk> <20120910180231.GV13776@Space.Net> Date: Tue, 11 Sep 2012 16:01:13 +0800 Message-ID: From: GangChen To: Maoke Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 08:01:15 -0000 Hello Maoke, 2012/9/11, Maoke : > 2012/9/11 GangChen > >> Hello Tim, >> >> 2012/9/11, Tim Chown : >> > On 10 Sep 2012, at 19:02, Gert Doering wrote: >> > >> >> Hi, >> >> >> >> On Tue, Sep 11, 2012 at 01:22:50AM +0900, Maoke wrote: >> >>> and therefore the IPv4-only host, getting the AAAA stuff, can do >> nothing >> >>> with it. only when the BIH stands between the IPv4-only host and the >> >>> CLAT, >> >>> it is possible that the BIH hijack the AAAA reply and synthesize a A >> >>> reply >> >>> for the host. >> >> >> >> What, exactly, does this have to do with the draft at hand? >> >> >> >> There are no IPv*4*-only hosts here. There's an IPv6-only host, which >> >> can do IPv4 by help of 464xlat. So BIH does not apply at all. >> >> >> >> I really wonder if this is getting anywhere - as soon as one crazy >> reason >> >> why this draft can not proceed has been silenced with 200+ e-mails, >> >> the >> >> next one springs up. >> >> >> >> Could people please focus on this draft, and not on "what other >> byzantine >> >> migration schemes might exist or not, and might want to be mentioned >> >> or >> >> should not mentioned in this draft"? >> >> >> >> I already deleted about a 100 unread mails in this thread today, >> >> because >> >> some of us really have work to do. >> > >> > This. >> > >> > Please do not add a reference to BIH or any other similar solution to a >> > document that is a BCP addressing a completely different problem. >> >> I can't agree with your arguments. >> There are not only discussions of 100+ mails, but dedicated >> implementation efforts. >> It doesn't make sense to ignore people's efforts that make the >> solution more complete without any identified issues. >> >> > If you want to consider BIH's applicability to different problem then >> write >> > an Informational draft on BIH in this context. >> >> BIH didn't apply to different problem, which is already clarified with >> current proposal *464XLKAT is not designed to cover the case of >> IPv4-only applications having access to IPv6-only servers. If that is >> needed, BIH of [RFC6535] provides a solution.* >> > > i am still waiting for your and Remi's offline discussion as the condition > to accept the proposed text. i won't object anymore if you just do the > offline discussion. if you don't, sorry, seeing "already clarified" is not > yet qualified for the time being. - maoke The concerns you raised have been addressed. Given there are intensive discussions, I'm not sure what we should discuss offline. But if you insist, I can help to make that happened . BRs Gang > >> BIH is indeed qualified to the context statement and already justified >> in RFC6535, no informational part needed IMHO. >> >> BRs >> >> Gang >> >> >> > Tim >> > _______________________________________________ >> > v6ops mailing list >> > v6ops@ietf.org >> > https://www.ietf.org/mailman/listinfo/v6ops >> > >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > From lorenzo@google.com Tue Sep 11 01:21:57 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9843621F87A5 for ; Tue, 11 Sep 2012 01:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.876 X-Spam-Level: X-Spam-Status: No, score=-102.876 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id svZrL8qMXE7K for ; Tue, 11 Sep 2012 01:21:57 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1C05321F8678 for ; Tue, 11 Sep 2012 01:21:56 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so412349obb.31 for ; Tue, 11 Sep 2012 01:21:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=U7Lgpt9c9UVdUcWQbvVBWMXTTeSoR3AvE8xPBfXUG84=; b=C9yvWv8ZQ978g0Ct8a0gg87Vic3UQb8qqFhjrgZ6KpR7Af4sSCFzXqvtZoCM4uPbk7 LqrcIIGgaFULCtIJYQJdLCYPM7okoIdFCfZhkM+8eomoxBZIKpeumYVa0tZneno6Wtjk ml93gIGS7LiVpRj90qSC6KnHER8JrSR7szkoeBllLH8rzgL1jb26V11YpqfzQB09y0fS nV5MjX6YlKqI0Jtust5qXuuyyYsgLvPxxa2xGxepAn95ujWOmnTowEVrfmyoFpjlNSto 7123EOQkunyfkR0QgUdrS0TsA1b6DGokbdqLpwOQKGh805hNQawnemnVC15NHkMYUYoP wkfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=U7Lgpt9c9UVdUcWQbvVBWMXTTeSoR3AvE8xPBfXUG84=; b=kZjHuSsC7YCPWY/d6NkoH5B/82iH+oYM2Ydhh+aKXWjCkRaz4e4MWte5jdaK6utIfY jwGzpoO6lxZTxwKH+QwAq+uU38sAqcRur1lGCcqbdNY8jARywe3TS39k7o92pXYa+Wv/ pMv6Ap/Gd+5xOKx9EAAZNSvf0YvTKKDJYioRJ5mF3RU/rsotCV4E2v/V9GSVsZcpujbV 2IGjq7Agi5XEiN/RHvM4VP6suSOxX0j7EKF6QIPrY/G06PP9SJ5Ww8HILYJxhskg4Yeu 2ST5DyJVm35tQ7uXPpyrj74qfm/k/SjcuPxlJJVxlTXn/Ru3P4vtKZbvkt/zShCavO7u ly2g== Received: by 10.60.10.6 with SMTP id e6mr17228480oeb.45.1347351716605; Tue, 11 Sep 2012 01:21:56 -0700 (PDT) Received: by 10.60.10.6 with SMTP id e6mr17228476oeb.45.1347351716512; Tue, 11 Sep 2012 01:21:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.187.8 with HTTP; Tue, 11 Sep 2012 01:21:36 -0700 (PDT) In-Reply-To: References: <810EAE3D-8767-4E66-911D-3DBDFE8B9403@laposte.net> <4730A653-CD11-4A08-9254-2C80C739D646@laposte.net> <7AB4B335-22DE-497C-A854-ACB560F2DE64@ecs.soton.ac.uk> <20120910180231.GV13776@Space.Net> From: Lorenzo Colitti Date: Tue, 11 Sep 2012 17:21:36 +0900 Message-ID: To: Tim Chown Content-Type: multipart/alternative; boundary=e89a8fb2028a73455a04c968c43f X-System-Of-Record: true X-Gm-Message-State: ALoCoQnInJKGqb7oG6rHSOrLAd6YijE4Gvze5h0bbb/fOloomNrC64QNhWa6PuZtGTTFY069nLFjfEP0sUaEihli8fKjdMokk1+mb8GA2YF9rXJRL9NV8fAqbofCa95S5frXv764v+Ebq8MYdOE972cQmOfOP6pSxq+jjQUS+ZC7L6uUNMD6GYOzQ/NqVLR0Pi4s9lHbjl59 Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 08:21:57 -0000 --e89a8fb2028a73455a04c968c43f Content-Type: text/plain; charset=ISO-8859-1 On Tue, Sep 11, 2012 at 3:44 PM, Tim Chown wrote: > Please do not add a reference to BIH or any other similar solution to a > document that is a BCP addressing a completely different problem. > > If you want to consider BIH's applicability to different problem then > write an Informational draft on BIH in this context. > Amen. --e89a8fb2028a73455a04c968c43f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Sep 11, 2012 at 3:44 PM, Tim Chown <tjc@ecs.soton.ac.uk><= /span> wrote:
    Please do not add a reference to BIH or any other similar= solution to a document that is a BCP addressing a completely different pro= blem.

    If you want to consider BIH's applicability to different problem then w= rite an Informational draft on BIH in this context.
    Amen.=A0
    --e89a8fb2028a73455a04c968c43f-- From despres.remi@laposte.net Tue Sep 11 01:27:48 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47B3021F857D for ; Tue, 11 Sep 2012 01:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.215 X-Spam-Level: X-Spam-Status: No, score=-1.215 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EosFHXPv7kv9 for ; Tue, 11 Sep 2012 01:27:47 -0700 (PDT) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.10]) by ietfa.amsl.com (Postfix) with ESMTP id 7B80121F8552 for ; Tue, 11 Sep 2012 01:27:47 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2202.sfr.fr (SMTP Server) with ESMTP id BD4D870000B1; Tue, 11 Sep 2012 10:27:46 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2202.sfr.fr (SMTP Server) with ESMTP id 4C36F700009C; Tue, 11 Sep 2012 10:27:46 +0200 (CEST) X-SFR-UUID: 20120911082746312.4C36F700009C@msfrf2202.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: Date: Tue, 11 Sep 2012 10:27:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <810EAE3D-8767-4E66-911D-3DBDFE8B9403@laposte.net> <4730A653-CD11-4A08-9254-2C80C739D646@laposte.net> <20120910180231.GV13776@Space.Net> <7AB4B335-22DE-497C-A854-ACB560F2DE64@ecs.soton.ac.uk> To: Tim Chown X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 08:27:48 -0000 Hi, Tim, A complaint just arrived that the past discussion on 464XLAT and BIH has = been too long. Fair enough, but it was with serious technical = considerations, and among seriously involved participants.=20 Now, at a time when these participants seem to reach conclusion, Gert = and yourself come in to restart the discussion! Th latest version of the proposed sentence is "464XLKAT is not designed = to cover the case of IPv4-only applications having access to IPv6-only = servers. If that is needed, BIH of [RFC6535] provides a solution": - It is true - It expresses that, contrary to some doubts recently expressed, there = is no contradiction between 464XLAT and BIH (RFC 6536 on BIH is little = known, but does exist on standard-track). - It is a correction of a wrong statement of draft-00 suggesting that, = with 464XLAT, "it is also possible to provide single IPv4/IPv6 = translation service, which will be needed in the future case of = IPv6-only servers and peers to be reached from legacy IPv4-only hosts". - It is an improved version of a sentence which has been in the draft = for quite some time.=20 Expressing NOW objections to the result of the discussion amounts to = restarting this discussion. Is this really what you wish? Hoping you can accept whatever participants to the long discussion have = agreed on, Regards, RD =20 Le 2012-09-11 =E0 08:44, Tim Chown a =E9crit : > On 10 Sep 2012, at 19:02, Gert Doering wrote: >=20 >> Hi, >>=20 >> On Tue, Sep 11, 2012 at 01:22:50AM +0900, Maoke wrote: >>> and therefore the IPv4-only host, getting the AAAA stuff, can do = nothing >>> with it. only when the BIH stands between the IPv4-only host and the = CLAT, >>> it is possible that the BIH hijack the AAAA reply and synthesize a A = reply >>> for the host. >>=20 >> What, exactly, does this have to do with the draft at hand? >>=20 >> There are no IPv*4*-only hosts here. There's an IPv6-only host, = which >> can do IPv4 by help of 464xlat. So BIH does not apply at all. >>=20 >> I really wonder if this is getting anywhere - as soon as one crazy = reason >> why this draft can not proceed has been silenced with 200+ e-mails, = the >> next one springs up. >>=20 >> Could people please focus on this draft, and not on "what other = byzantine >> migration schemes might exist or not, and might want to be mentioned = or >> should not mentioned in this draft"? >>=20 >> I already deleted about a 100 unread mails in this thread today, = because >> some of us really have work to do. >=20 > This.=20 >=20 > Please do not add a reference to BIH or any other similar solution to = a document that is a BCP addressing a completely different problem. >=20 > If you want to consider BIH's applicability to different problem then = write an Informational draft on BIH in this context. >=20 > Tim > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From lorenzo@google.com Tue Sep 11 01:32:04 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2839121F8716 for ; Tue, 11 Sep 2012 01:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.731 X-Spam-Level: X-Spam-Status: No, score=-102.731 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQ9ui2J20qwV for ; Tue, 11 Sep 2012 01:32:03 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9438B21F8742 for ; Tue, 11 Sep 2012 01:32:03 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so426027obb.31 for ; Tue, 11 Sep 2012 01:32:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=sVzsIQ2L7sBdX0o5X6z7fqGQuBzIGhPTHHJm1w1V5OU=; b=hzyBBCpQbGkSjeT/HnQIKwkd/pnXqYelCPxHBJrY4q7+ZTApm/60k/dZs8BzgpvJcF tUdJIBNXjnzX07V1uNQgPO2aLw/TUjsDiZitv/eC/uOZoyGpHmLUl4ekm5iteT88trtg nk4c9WhdFRxlV8VA5X66SI/KzAZ6AJuD0VRLVndbbxW2I/lbsB4xQFUjF7/OGjnTAMHN 6TaAlHRMX1Lc8+3p0cSrbhesSX+8CxVra5lfVFgCAsns6lkFGQIBXi8ETU6gJ5/Zjm3O U16qU4kd8MgadGKxRAoNOORDok2sFQ5YxuXYpULaood7X8/Um/z/VXID7PrspfChi1mA wQdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=sVzsIQ2L7sBdX0o5X6z7fqGQuBzIGhPTHHJm1w1V5OU=; b=Mnki2vpkTJHlerNGbr8qrpoWYbiUg8eR7kcnt0g6tllPgfioHXTeh/O0YfdIXi1ga7 GW5xdCjhXwLyBdjeWzXQkX9g5YSLZUkd7ValrM02yEnxYQKJFdOJNuv9EXDGvKDBZOCP m6T3m5hvKdzutKj8SktWDoAifwWljlRwRpJYOBKo2RRtNnYpXzrfeafW2aT8tQVyGHPx YdpEZVfhZPwQIxIT1n+atNPCD8NQZsSdajTG/DupcjQOhQqlVjpTmdHZOMwTgCehDFLC XkeamgxwT78zW4iEmgiXrDRGIXi/HAiKTr98kJMj3wvi+2ImYAwL07XEpkpHxRtoSJcf XNdg== Received: by 10.60.170.47 with SMTP id aj15mr16983523oec.29.1347352323201; Tue, 11 Sep 2012 01:32:03 -0700 (PDT) Received: by 10.60.170.47 with SMTP id aj15mr16983515oec.29.1347352323118; Tue, 11 Sep 2012 01:32:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.187.8 with HTTP; Tue, 11 Sep 2012 01:31:42 -0700 (PDT) In-Reply-To: References: <810EAE3D-8767-4E66-911D-3DBDFE8B9403@laposte.net> <4730A653-CD11-4A08-9254-2C80C739D646@laposte.net> <20120910180231.GV13776@Space.Net> <7AB4B335-22DE-497C-A854-ACB560F2DE64@ecs.soton.ac.uk> From: Lorenzo Colitti Date: Tue, 11 Sep 2012 17:31:42 +0900 Message-ID: To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=bcaec54c52289b56b404c968e82f X-System-Of-Record: true X-Gm-Message-State: ALoCoQke4oXf+gLU8esxqgEXfSEe7NkljS6bdJeSOD3wymy0wuh/H8JAOMN4oLKvQ5DnnBWe/kD9QXy78/bj59ssrlITzHZKQ4wr0cwrdjrypzj8oZLVSJTBp/wxcgMui2MF2MuysjESIEbxichum4ZBi9VN63Y8i58ipRpjWjBV0IEbUmAXxoDdEatEQem5im3C0Y4s7QEN Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 08:32:04 -0000 --bcaec54c52289b56b404c968e82f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Sep 11, 2012 at 5:27 PM, R=E9mi Despr=E9s wrote: > Expressing NOW objections to the result of the discussion amounts to > restarting this discussion. > Is this really what you wish? > I think if you read his email carefully, you'll conclude that what he would like to see is: a) the discussion stops, b) the reference to BIH is taken out, and c) we move on. I agree. --bcaec54c52289b56b404c968e82f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Sep 11, 2012 at 5:27 PM, R=E9mi Despr=E9s <despres.remi@lap= oste.net> wrote:
    Expressing NOW objections to the result of the discussion amounts to restar= ting this discussion.
    Is this really what you wish?

    I think i= f you read his email carefully, you'll conclude that what he would like= to see is: a) the discussion stops, b) the reference to BIH is taken out, = and c) we move on. I agree.
    --bcaec54c52289b56b404c968e82f-- From phdgang@gmail.com Tue Sep 11 01:40:45 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE2B21F874C for ; Tue, 11 Sep 2012 01:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.388 X-Spam-Level: X-Spam-Status: No, score=-3.388 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hg8EIkphJ-vo for ; Tue, 11 Sep 2012 01:40:45 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC8421F8718 for ; Tue, 11 Sep 2012 01:40:44 -0700 (PDT) Received: by vbbfc26 with SMTP id fc26so341689vbb.31 for ; Tue, 11 Sep 2012 01:40:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=K9QdYS3BrnDUmiN7HWOK0jhqvQRY3k2kf/zhMl2cGWQ=; b=cO0Zb1WF0BL82DFZdM5Mjpcpj0PT2zbTSZvs0tiqyIZnqlKuvjTs8UEzHSeliuO0HE FZ7SalHCAR5A9cg71Qrn+pJlraTQCvHkITm74Ir3JI4AMfMvM9HBvHd3sXjkNB58urWU au7n6jf8H9SLx31gDBzpMV5kYn7O0G0D7vCZ0f1U9x1wMUHyl9uu69Dz/ct3Sao/rddg 3S+2hbEO8JZVvxJj91AvvH9Nz+5gm5TXodxQSsCidPM55seNnYMVivZuohh4yEX5tcAo Xu3c8C+GjmouYcrha1+yuaxL6zIqk9QnT3Rf0eN+cByr6kx4/stU2Ak8Su+73IUwecUD /42w== MIME-Version: 1.0 Received: by 10.59.1.162 with SMTP id bh2mr26548019ved.13.1347352844458; Tue, 11 Sep 2012 01:40:44 -0700 (PDT) Received: by 10.58.114.231 with HTTP; Tue, 11 Sep 2012 01:40:44 -0700 (PDT) In-Reply-To: References: <810EAE3D-8767-4E66-911D-3DBDFE8B9403@laposte.net> <4730A653-CD11-4A08-9254-2C80C739D646@laposte.net> <20120910180231.GV13776@Space.Net> <7AB4B335-22DE-497C-A854-ACB560F2DE64@ecs.soton.ac.uk> Date: Tue, 11 Sep 2012 16:40:44 +0800 Message-ID: From: GangChen To: Lorenzo Colitti Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 08:40:45 -0000 Hello Lerenzo, If the rough consensus should be respected, if the past discussions should be respected, if some implementation efforts should be respected, I hope you conclude a) the discussion stops, b) take current proposal, and c) we move on. BRs Gang 2012/9/11, Lorenzo Colitti : > On Tue, Sep 11, 2012 at 5:27 PM, R=E9mi Despr=E9s > wrote: > >> Expressing NOW objections to the result of the discussion amounts to >> restarting this discussion. >> Is this really what you wish? >> > > I think if you read his email carefully, you'll conclude that what he wou= ld > like to see is: a) the discussion stops, b) the reference to BIH is taken > out, and c) we move on. I agree. > From gert@space.net Tue Sep 11 01:41:22 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D74E21F877E for ; Tue, 11 Sep 2012 01:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zbi1w7gHDi2x for ; Tue, 11 Sep 2012 01:41:21 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5A32C21F877B for ; Tue, 11 Sep 2012 01:41:21 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 267A2F9131 for ; Tue, 11 Sep 2012 10:41:20 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id F06BCF9125 for ; Tue, 11 Sep 2012 10:41:18 +0200 (CEST) Received: (qmail 24645 invoked by uid 1007); 11 Sep 2012 10:41:18 +0200 Date: Tue, 11 Sep 2012 10:41:18 +0200 From: Gert Doering To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Message-ID: <20120911084118.GA13776@Space.Net> References: <4730A653-CD11-4A08-9254-2C80C739D646@laposte.net> <20120910180231.GV13776@Space.Net> <7AB4B335-22DE-497C-A854-ACB560F2DE64@ecs.soton.ac.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GM/p8XWaonmYtdwv" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 08:41:22 -0000 --GM/p8XWaonmYtdwv Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Tue, Sep 11, 2012 at 10:27:46AM +0200, R=E9mi Despr=E9s wrote: > Hoping you can accept whatever participants to the long discussion have a= greed on, I seem to have missed that anyone agreed on anything. It was certainly not clear to me from the mail I commented on that agreement was near. If you are in agreement, all the better, this document is needed. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 --GM/p8XWaonmYtdwv Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iQCVAwUBUE75LqkuBuNlUUl1AQIQgwP/TEQOdP0rQDytQGcSMTrJ+H/8KUE2Yyd+ X7yyyf2wnO+EH9OvAt3yu1RbcE3lVBH3/Jp3k+3wS9Bl0+P1akbG+hH5q/JVaoDp 089M3HZW+Qj5ZLFW83FhOfFv1F4w7p8txG7BMpUU6Y9BkzmY9ytowfjlDFaneX0D V/6ZkdE32GI= =94X0 -----END PGP SIGNATURE----- --GM/p8XWaonmYtdwv-- From fibrib@gmail.com Tue Sep 11 01:41:41 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5AF421F879F for ; Tue, 11 Sep 2012 01:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.604 X-Spam-Level: X-Spam-Status: No, score=-2.604 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fe+4zMRaa0hg for ; Tue, 11 Sep 2012 01:41:40 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 71AEC21F87AE for ; Tue, 11 Sep 2012 01:41:40 -0700 (PDT) Received: by wibhi8 with SMTP id hi8so2590178wib.13 for ; Tue, 11 Sep 2012 01:41:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PTwrg3bFcCzUMul4L2+C0h9spdh7ioa8I/SPAaw508w=; b=0crWAa+fIkoDFGLyMpdWu9PGOlufnMwqyJaC2l44KRk4TgLNMBOQ+NNpPpIGED2aUk zXrWIHmA3mQcbayLPPtTJgHxy7/eFg7UFDW4OLNiMhsXtWMNnq9oFB1Q9/zeRcuaa/iH k5MbVJrkc3tW6gL9jUEXGUdt95quCpNlwDDtNEDNbM4unW/ePaEBzUs8K2FCHouWNczs 1vRsH7DsBVbGkDm9V7/sFHt2khgCqrcqAZF48c5zSEnv17AAmzn5m872+nRZASXNTjQV x8fVaHKa5onAANHVal7n+WUmsrqm6MNWihr78YrH6cMKWmtF8uSKuuNnI+KH2yIgm7Bs WKQA== MIME-Version: 1.0 Received: by 10.180.19.166 with SMTP id g6mr23485545wie.13.1347352899446; Tue, 11 Sep 2012 01:41:39 -0700 (PDT) Received: by 10.223.37.78 with HTTP; Tue, 11 Sep 2012 01:41:39 -0700 (PDT) In-Reply-To: References: <810EAE3D-8767-4E66-911D-3DBDFE8B9403@laposte.net> <4730A653-CD11-4A08-9254-2C80C739D646@laposte.net> <7AB4B335-22DE-497C-A854-ACB560F2DE64@ecs.soton.ac.uk> <20120910180231.GV13776@Space.Net> Date: Tue, 11 Sep 2012 17:41:39 +0900 Message-ID: From: Maoke To: GangChen , =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=bcaec53f3a05f569f604c9690aa0 Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 08:41:41 -0000 --bcaec53f3a05f569f604c9690aa0 Content-Type: text/plain; charset=ISO-8859-1 dear Gang, Remi, Lorenzo and all, hereby, as Remi has accept the offline discussion (and thanks to Gang and Lorenzo who are also doing so), i must keep my promise to stop my objection here. sorry that i occupied a lot of the WG time but only for my own understanding. try to do this offline now. my answer to Remi's question is: yes, it is acceptable for me to state ""464XLAT is not designed to cover the case of IPv4-only applications having access to IPv6-only servers. If that is needed, BIH of [RFC6535] provides a solution." (typo is corrected) - maoke 2012/9/11 GangChen > Hello Maoke, > > 2012/9/11, Maoke : > > 2012/9/11 GangChen > > > >> Hello Tim, > >> > >> 2012/9/11, Tim Chown : > >> > On 10 Sep 2012, at 19:02, Gert Doering wrote: > >> > > >> >> Hi, > >> >> > >> >> On Tue, Sep 11, 2012 at 01:22:50AM +0900, Maoke wrote: > >> >>> and therefore the IPv4-only host, getting the AAAA stuff, can do > >> nothing > >> >>> with it. only when the BIH stands between the IPv4-only host and the > >> >>> CLAT, > >> >>> it is possible that the BIH hijack the AAAA reply and synthesize a A > >> >>> reply > >> >>> for the host. > >> >> > >> >> What, exactly, does this have to do with the draft at hand? > >> >> > >> >> There are no IPv*4*-only hosts here. There's an IPv6-only host, > which > >> >> can do IPv4 by help of 464xlat. So BIH does not apply at all. > >> >> > >> >> I really wonder if this is getting anywhere - as soon as one crazy > >> reason > >> >> why this draft can not proceed has been silenced with 200+ e-mails, > >> >> the > >> >> next one springs up. > >> >> > >> >> Could people please focus on this draft, and not on "what other > >> byzantine > >> >> migration schemes might exist or not, and might want to be mentioned > >> >> or > >> >> should not mentioned in this draft"? > >> >> > >> >> I already deleted about a 100 unread mails in this thread today, > >> >> because > >> >> some of us really have work to do. > >> > > >> > This. > >> > > >> > Please do not add a reference to BIH or any other similar solution to > a > >> > document that is a BCP addressing a completely different problem. > >> > >> I can't agree with your arguments. > >> There are not only discussions of 100+ mails, but dedicated > >> implementation efforts. > >> It doesn't make sense to ignore people's efforts that make the > >> solution more complete without any identified issues. > >> > >> > If you want to consider BIH's applicability to different problem then > >> write > >> > an Informational draft on BIH in this context. > >> > >> BIH didn't apply to different problem, which is already clarified with > >> current proposal *464XLKAT is not designed to cover the case of > >> IPv4-only applications having access to IPv6-only servers. If that is > >> needed, BIH of [RFC6535] provides a solution.* > >> > > > > i am still waiting for your and Remi's offline discussion as the > condition > > to accept the proposed text. i won't object anymore if you just do the > > offline discussion. if you don't, sorry, seeing "already clarified" is > not > > yet qualified for the time being. - maoke > > The concerns you raised have been addressed. Given there are intensive > discussions, I'm not sure what we should discuss offline. But if you > insist, I can help to make that happened . > > BRs > > Gang > > > > > > > > >> BIH is indeed qualified to the context statement and already justified > >> in RFC6535, no informational part needed IMHO. > >> > >> BRs > >> > >> Gang > >> > >> > >> > Tim > >> > _______________________________________________ > >> > v6ops mailing list > >> > v6ops@ietf.org > >> > https://www.ietf.org/mailman/listinfo/v6ops > >> > > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops > >> > > > --bcaec53f3a05f569f604c9690aa0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

    dear Gang, Remi, Lorenzo and all,
    =A0
    hereby,= as Remi has accept the offline discussion=A0 (and thanks to Gang=A0and Lor= enzo who=A0are also doing so), i must keep my promise to stop my objection = here. sorry that i occupied a lot of the WG time but only for my own unders= tanding. try to do this offline now.
    =A0
    my=A0answer to Remi's question is: yes, it is accept= able for me to state ""464XLAT is not designed to cover the case = of IPv4-only applications having access to IPv6-only servers. If that is ne= eded, BIH of [RFC6535] provides a solution." (typo is corrected)
    =A0
    - maoke
    2012/9/11 G= angChen <phdgang@gmail.com>
    Hello Maoke,

    2012/9/11, Maoke <fibrib@gmail.com>:
    > 2012/9/11 GangChen <phdgang@gmail.com>
    >
    >> Hello Tim,
    >>
    >> 2012/9/11, Tim Chown <tj= c@ecs.soton.ac.uk>:
    >> > On 10 Sep 2012, at 19:02, Gert Doering <gert@space.net> wrote:
    >> >
    >> >> Hi,
    >> >>
    >> >> On Tue, Sep 11, 2012 at 01:22:50AM +0900, Maoke wrote: >> >>> and therefore the IPv4-only host, getting the AAAA st= uff, can do
    >> nothing
    >> >>> with it. only when the BIH stands between the IPv4-on= ly host and the
    >> >>> CLAT,
    >> >>> it is possible that the BIH hijack the AAAA reply and= synthesize a A
    >> >>> reply
    >> >>> for the host.
    >> >>
    >> >> What, exactly, does this have to do with the draft at han= d?
    >> >>
    >> >> There are no IPv*4*-only hosts here. =A0There's an IP= v6-only host, which
    >> >> can do IPv4 by help of 464xlat. =A0So BIH does not apply = at all.
    >> >>
    >> >> I really wonder if this is getting anywhere - as soon as = one crazy
    >> reason
    >> >> why this draft can not proceed has been silenced with 200= + e-mails,
    >> >> the
    >> >> next one springs up.
    >> >>
    >> >> Could people please focus on this draft, and not on "= ;what other
    >> byzantine
    >> >> migration schemes might exist or not, and might want to b= e mentioned
    >> >> or
    >> >> should not mentioned in this draft"?
    >> >>
    >> >> I already deleted about a 100 unread mails in this thread= today,
    >> >> because
    >> >> some of us really have work to do.
    >> >
    >> > This.
    >> >
    >> > Please do not add a reference to BIH or any other similar sol= ution to a
    >> > document that is a BCP addressing a completely different prob= lem.
    >>
    >> I can't agree with your arguments.
    >> There are not only discussions of 100+ mails, but dedicated
    >> implementation efforts.
    >> It doesn't make sense to ignore people's efforts that make= the
    >> solution more complete without any identified issues.
    >>
    >> > If you want to consider BIH's applicability to different = problem then
    >> write
    >> > an Informational draft on BIH in this context.
    >>
    >> BIH didn't apply to different problem, which is already clarif= ied with
    >> current proposal *464XLKAT is not designed to cover the case of >> IPv4-only applications having access to IPv6-only servers. If that= is
    >> needed, BIH of [RFC6535] provides a solution.*
    >>
    >
    > i am still waiting for your and Remi's offline discussion as the c= ondition
    > to accept the proposed text. i won't object anymore if you just do= the
    > offline discussion. if you don't, sorry, seeing "already clar= ified" is not
    > yet qualified for the time being. - maoke

    The concerns you raised have been addressed. Given there are in= tensive
    discussions, I'm not sure what we should discuss offline. But if you insist, I can help to make that happened .

    BRs

    Gang





    >
    >> BIH is indeed qualified to the context statement and already justi= fied
    >> in RFC6535, no informational part needed IMHO.
    >>
    >> BRs
    >>
    >> Gang
    >>
    >>
    >> > Tim
    >> > _______________________________________________
    >> > v6ops mailing list
    >> > v6ops@ietf.org
    >> > https://www.ietf.org/mailman/listinfo/v6ops
    >> >
    >> _______________________________________________
    >> v6ops mailing list
    >> v6ops@ietf.org
    >> https://www.ietf.org/mailman/listinfo/v6ops
    >>
    >

    --bcaec53f3a05f569f604c9690aa0-- From lorenzo@google.com Tue Sep 11 01:49:58 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33F3521F87B4 for ; Tue, 11 Sep 2012 01:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.878 X-Spam-Level: X-Spam-Status: No, score=-102.878 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JG1MtJmWyqw1 for ; Tue, 11 Sep 2012 01:49:57 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9B88321F87A5 for ; Tue, 11 Sep 2012 01:49:57 -0700 (PDT) Received: by oagk14 with SMTP id k14so140599oag.31 for ; Tue, 11 Sep 2012 01:49:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=1Jc5XAfccqSlwbNEJB/wSwLwFDo4nf7V9hg1PIWJY7U=; b=c1jIsDnBrhlf3MKYP7oLcQaQTF+hhR/AybPTzDrzV3OmQOKn5holxUfBtEPDyC21T9 yKdXXUNYwQv+BBAYdMWDXD0sltcP7bpXPCo3OcyWUWTolTlVYweJiw8uUjjL8jHZVBSK EM3l0u6OIs1Rfw7PRE//7DrLmkbMhLdxm+xm4xGDcIGSUYZQehJ0cwuOYNDksJmH5/au RR7MEN7opvncX+KccVye345fRH2WW6ZT4NMnsSO07rbiSKMpHK79Iapf9WtSwgF/iCnL DyqRMT/hgoPJfEAvaKZ5WeKXxE9DcHwT+qcQ/rZ1Mc1HxhTfI0jrOCDqHms56cbcv5CM CXuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=1Jc5XAfccqSlwbNEJB/wSwLwFDo4nf7V9hg1PIWJY7U=; b=RpQhgBHdIqx3S6EtFdxJ5cDGpIWGnukXeLwOg8IcGZ3/GCXaZL5xRN5aOTrismK682 CoscHUSzZ5Px0FGeDuREpVq0agNRwTMb+0DVNG9j7CQO0a3OWUCATriYkHJPgVbIE3V4 P7ukYIiR4yb1QtsQxWGATXArE/xQp7hx6kZRXYc+3vEGivtA+j9WCxmkfsseo7Tl492c dhPF/QKRrJO77l40IYdJ6haNGdFADTtKIvuvZX0e2Vl4Rqyzrj55OtYaSXfJehykG/ec ujTthFr24w8gaJkieviCCLd6bzqkjhEm11ni4zg3hQuNo9LZizaLK6D9bXOOhc8dXANH k8pg== Received: by 10.60.5.229 with SMTP id v5mr16728463oev.70.1347353397309; Tue, 11 Sep 2012 01:49:57 -0700 (PDT) Received: by 10.60.5.229 with SMTP id v5mr16728452oev.70.1347353397087; Tue, 11 Sep 2012 01:49:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.187.8 with HTTP; Tue, 11 Sep 2012 01:49:36 -0700 (PDT) In-Reply-To: References: <810EAE3D-8767-4E66-911D-3DBDFE8B9403@laposte.net> <4730A653-CD11-4A08-9254-2C80C739D646@laposte.net> <20120910180231.GV13776@Space.Net> <7AB4B335-22DE-497C-A854-ACB560F2DE64@ecs.soton.ac.uk> From: Lorenzo Colitti Date: Tue, 11 Sep 2012 17:49:36 +0900 Message-ID: To: GangChen Content-Type: multipart/alternative; boundary=e89a8f6431549ecc3004c9692846 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlka3e50UXhR5NYWMu19I+Ct0kHSh7u4ir4D/xodoOi4Zd1T0jbIIMP165ejWRnmhTQSUCo9U/nirYdT+nxKYPuretxofcmkvQfTms7J55erafUlcVZ0ii8WAAWzt928ejIhnjsXvL3ePapix+pnX6UorrkpG1UJgoYzUOG/vnqvTstwCQrt3kF9/Fm45laKEi5FSQy Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 08:49:58 -0000 --e89a8f6431549ecc3004c9692846 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Sep 11, 2012 at 5:40 PM, GangChen wrote: > If the rough consensus should be respected, if the past discussions > should be respected, if some implementation efforts should be > respected, I hope you conclude a) the discussion stops, b) take > current proposal, and c) we move on. > I don't see rough consensus. It seems to me that you and Remi want BIH to be mentioned, Maoke does not, I prefer not, and Gert and Tim don't want it to be mentioned. Where is the consensus there? --e89a8f6431549ecc3004c9692846 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Sep 11, 2012 at 5:40 PM, GangChen <phdgang@gmail.com> wrote:
    If the rough consensus should be respected, if the past discussions
    should be respected, if some implementation efforts should be
    respected, I hope you conclude a) the discussion stops, b) take
    current proposal, and c) we move on.

    I = don't see rough consensus. It seems to me that you and Remi want BIH to= be mentioned, Maoke does not, I prefer not, and Gert and Tim don't wan= t it to be mentioned. Where is the consensus there?
    --e89a8f6431549ecc3004c9692846-- From phdgang@gmail.com Tue Sep 11 02:02:37 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF61B21F8574 for ; Tue, 11 Sep 2012 02:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gUfB969wS1Ti for ; Tue, 11 Sep 2012 02:02:36 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id B3B2C21F842D for ; Tue, 11 Sep 2012 02:02:34 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so374306vcb.31 for ; Tue, 11 Sep 2012 02:02:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HwK5GCQAlT9iOseAzQlBdpXcLyxKQqS0ltZeqA14cS4=; b=myYQ7VnbXuCTGKKRTAVBWCiUX57lnqkkdFaKZ668YaYbHEe29NiLbKpCAMVDzwf3FQ 3EwE40xk1hG/O2RxFUqvbFBuwZjcZjTQt7pvuvA8qOJsq/faLvCn9Y+ZXKriozG8Ih0B v2818KfBDrncJWKCmVTs8gWopDaRQWIo8WGHfFv/pMCc1hvuVtOsBWpWBP8dlPv10c6X Szd4z2XooSFjSwKKQnsdBkWqTu6WSGtCSs9jzo9aVgz4jdtcX0xD/jvq7wjbiQGW8sTu mrp7P049oSYSkuiobTWCHMxxz/QjR5pgY4VqLdXDGI1vvsDwzr5+FGE5meQ88G/a6PFx yL4A== MIME-Version: 1.0 Received: by 10.52.20.138 with SMTP id n10mr19438037vde.129.1347354152208; Tue, 11 Sep 2012 02:02:32 -0700 (PDT) Received: by 10.58.114.231 with HTTP; Tue, 11 Sep 2012 02:02:32 -0700 (PDT) In-Reply-To: References: <810EAE3D-8767-4E66-911D-3DBDFE8B9403@laposte.net> <4730A653-CD11-4A08-9254-2C80C739D646@laposte.net> <20120910180231.GV13776@Space.Net> <7AB4B335-22DE-497C-A854-ACB560F2DE64@ecs.soton.ac.uk> Date: Tue, 11 Sep 2012 17:02:32 +0800 Message-ID: From: GangChen To: Lorenzo Colitti Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 09:02:37 -0000 2012/9/11, Lorenzo Colitti : > On Tue, Sep 11, 2012 at 5:40 PM, GangChen wrote: > >> If the rough consensus should be respected, if the past discussions >> should be respected, if some implementation efforts should be >> respected, I hope you conclude a) the discussion stops, b) take >> current proposal, and c) we move on. >> > > I don't see rough consensus. It seems to me that you and Remi want BIH to > be mentioned, Maoke does not, I prefer not, and Gert and Tim don't want it > to be mentioned. Where is the consensus there? I saw the consensus, because 1) It has been documented in current draft and confirmed through several versions 2) Authors acknowledged that and think that is a complementary part to the draft 3) The intention have been thoroughly discussed on the list, no issues identified If you claim there is no consensus so far on this thread, that is another story BRs Gang From despres.remi@laposte.net Tue Sep 11 02:02:54 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35DA821F8688 for ; Tue, 11 Sep 2012 02:02:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.518 X-Spam-Level: X-Spam-Status: No, score=-1.518 tagged_above=-999 required=5 tests=[AWL=0.430, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NaF6MX91Bf8x for ; Tue, 11 Sep 2012 02:02:53 -0700 (PDT) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.10]) by ietfa.amsl.com (Postfix) with ESMTP id 5C7C521F8533 for ; Tue, 11 Sep 2012 02:02:52 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2202.sfr.fr (SMTP Server) with ESMTP id D00E17000166; Tue, 11 Sep 2012 11:02:51 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2202.sfr.fr (SMTP Server) with ESMTP id 654407000163; Tue, 11 Sep 2012 11:02:51 +0200 (CEST) X-SFR-UUID: 20120911090251414.654407000163@msfrf2202.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-54--320216200 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 11 Sep 2012 11:02:51 +0200 Message-Id: <70F404EE-3F5C-4B1C-B7B7-315F1A498B08@laposte.net> References: <810EAE3D-8767-4E66-911D-3DBDFE8B9403@laposte.net> <4730A653-CD11-4A08-9254-2C80C739D646@laposte.net> <20120910180231.GV13776@Space.Net> <7AB4B335-22DE-497C-A854-ACB560F2DE64@ecs.soton.ac.uk> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 09:02:54 -0000 --Apple-Mail-54--320216200 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 2012-09-11 10:31, Lorenzo Colitti : > On Tue, Sep 11, 2012 at 5:27 PM, R=E9mi Despr=E9s = wrote: > Expressing NOW objections to the result of the discussion amounts to = restarting this discussion. > Is this really what you wish? >=20 > I think if you read his email carefully, you'll conclude that what he = would like to see is: a) the discussion stops, b) the reference to BIH = is taken out, and c) we move on. I agree. I did read his email carefully, and did understand it. Your several-times expressed _preference_ for deleting the sentence has = also been well understood.=20 But we recently had, in this long discussion, sentences acceptable by = both of us, by Gang, and _almost_ by Maoke. The best candidate = (mentioned in my mail to Tim) is: "464XLKAT is not designed to cover the case of IPv4-only applications = having access to IPv6-only servers. If that is needed, BIH of [RFC6535] = provides a solution" Maoke's concerns are now being resolved as: - he said today "i make the deal: you promise to teach me about the = above behavior offline; i stop my objection no matter what i get to = understand through the education". - I did may part of the deal. Hope we can conclude on this... and move on. RD --Apple-Mail-54--320216200 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
    On Tue, = Sep 11, 2012 at 5:27 PM, R=E9mi Despr=E9s <despres.remi@laposte.net> wrote:
    Expressing NOW objections to the result of the discussion amounts to = restarting this discussion.
    Is this really what you wish?

    I = think if you read his email carefully, you'll conclude that what he = would like to see is: a) the discussion stops, b) the reference to BIH = is taken out, and c) we move on. I agree.

    I did read his email carefully, and did = understand it.
    Your several-times expressed _preference_ for = deleting the sentence has also been well = understood. 

    But we recently had, in this = long discussion, sentences acceptable by both of us, by Gang, and = _almost_ by Maoke. The best candidate (mentioned in my mail to Tim) = is:
    "464XLKAT is not designed to cover the case = of IPv4-only applications having access to IPv6-only servers. If = that is needed, BIH of [RFC6535] provides a = solution"

    Maoke's concerns are now being = resolved as:
    - he said today "i make the deal: you promise to = teach me about the above behavior offline; i stop my = objection no matter what i get to understand through the = education".
    - I did may part of the = deal.

    Hope we can conclude on this... and move = on.

    RD



    = --Apple-Mail-54--320216200-- From despres.remi@laposte.net Tue Sep 11 02:34:10 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D250721F8799 for ; Tue, 11 Sep 2012 02:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.228 X-Spam-Level: X-Spam-Status: No, score=-1.228 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wLLwHBa04cyF for ; Tue, 11 Sep 2012 02:34:10 -0700 (PDT) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.13]) by ietfa.amsl.com (Postfix) with ESMTP id F06F721F8790 for ; Tue, 11 Sep 2012 02:34:09 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2216.sfr.fr (SMTP Server) with ESMTP id 28F9B70000E8; Tue, 11 Sep 2012 11:33:24 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2216.sfr.fr (SMTP Server) with ESMTP id 23A2270000AE; Tue, 11 Sep 2012 11:33:23 +0200 (CEST) X-SFR-UUID: 20120911093323146.23A2270000AE@msfrf2216.sfr.fr From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-55--318384505 Date: Tue, 11 Sep 2012 11:33:22 +0200 References: To: Cameron Byrne , Mawatari Masataka , Masanobu Kawashima Message-Id: <5A99DF4A-AE52-4067-B4C2-065DE5F88FE9@laposte.net> X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: [v6ops] Compromise text on 464XLAT and BIH X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 09:34:10 -0000 --Apple-Mail-55--318384505 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Dear authors of the 464XLAT draft, The compromise now reached, among active participants of a long = discussion on the relation between 464XLAT and BIH, is the following: "464XLAT is not designed to cover the case of IPv4-only applications = having access to IPv6-only servers. If that is needed, BIH of [RFC6535] = provides a solution." Unless the discussion is restarted, it can replace the current wording = of the draft. Thanks, and best regards, RD > De : Maoke > Date : 2012-09-11 10:41 > =C0 : GangChen , R=E9mi Despr=E9s = > Cc : v6ops WG > Objet : R=E9p : [v6ops] draft-ietf-v6ops-464xlat WGLC >=20 >=20 > dear Gang, Remi, Lorenzo and all, > =20 > hereby, as Remi has accept the offline discussion (and thanks to Gang = and Lorenzo who are also doing so), i must keep my promise to stop my = objection here. sorry that i occupied a lot of the WG time but only for = my own understanding. try to do this offline now. > =20 > my answer to Remi's question is: yes, it is acceptable for me to state = ""464XLAT is not designed to cover the case of IPv4-only applications = having access to IPv6-only servers. If that is needed, BIH of [RFC6535] = provides a solution." (typo is corrected) > =20 > - maoke=20 ... --Apple-Mail-55--318384505 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Dear = authors of the 464XLAT draft,

    The compromise now = reached, among active participants of a long discussion on the relation = between 464XLAT and BIH, is the following:
    "464XLAT is not designed = to cover the case of IPv4-only applications having access to IPv6-only = servers. If that is needed, BIH of [RFC6535] provides a = solution."

    Unless the discussion is restarted, = it can replace the current wording  of the = draft.

    Thanks, and best = regards,
    RD




    De : Maoke <fibrib@gmail.com>
    =
    Date : 2012-09-11 = 10:41
    =C0 : GangChen <phdgang@gmail.com>, R=E9mi = Despr=E9s <despres.remi@laposte.net><= br>
    Cc : v6ops WG <v6ops@ietf.org>
    Objet : R=E9p : [v6ops] = draft-ietf-v6ops-464xlat WGLC


    dear = Gang, Remi, Lorenzo and all,
     
    hereby, as Remi = has accept the offline discussion  (and thanks to Gang and = Lorenzo who are also doing so), i must keep my promise to stop my = objection here. sorry that i occupied a lot of the WG time but only for = my own understanding. try to do this offline now.
     
    my answer to Remi's question is: yes, it is = acceptable for me to state ""464XLAT is not designed to cover the case = of IPv4-only applications having access to IPv6-only servers. If that is = needed, BIH of [RFC6535] provides a solution." (typo is corrected)
     
    - = maoke 
    ...

    = --Apple-Mail-55--318384505-- From lorenzo@google.com Tue Sep 11 02:39:38 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F062521F8744 for ; Tue, 11 Sep 2012 02:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.733 X-Spam-Level: X-Spam-Status: No, score=-102.733 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hnuJYIgASd5o for ; Tue, 11 Sep 2012 02:39:37 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 628BD21F8742 for ; Tue, 11 Sep 2012 02:39:37 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so521965obb.31 for ; Tue, 11 Sep 2012 02:39:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=HQvrXrHp8Jm5QoLafHXga0AuyIHO0t0AULTg1F/59vQ=; b=JBJfBg8RhyHnti1ZK58V2Fm0nkudegg0nD9iR2nLXXy5M5bN+xJ8cPqFDtiop9i4jK mvRCETXLZRewIlijWw3QoSGkJk6i/W2MOT11S7pqmme45CqK67ZIANF8yp3elYwb2cFn P0t3R5A9dF0DrJfvwwmGUgrofZmrMl0X9BOEMud7q8NC9XrnQOTjxffTObjsVQeTf8lf EwwN0Ouu54tO3WA3qozMTYFGNcOhipHS39xaffVhb9N84T9GsV9W6eGft4ITdYAMce+p yw/ppTfmF30LQeiQuXamAjMjSTIYRq5GZXS7Q96J89NLhwf2USJzvggbEvVue8P1wFeg mKYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=HQvrXrHp8Jm5QoLafHXga0AuyIHO0t0AULTg1F/59vQ=; b=dB3HLae+3MtojiFx+09NRK/DPtzag5XvbcF1iK6MdrzAqxqlXa3vNinbfPJn/uL/OX X3ZptrXCp2AbwleJqGawjyrzRsSi59wHqzOaCCsNXP5oLgmWvNrD0P3WrdZYe4tam33P Dcl+Au1GdB00l27sNnWG8Sisx3iaNia4LWEIN5EKiINCh0GIsqFPC76EscILQ3VPhMGm VRaRjVn4Cbt5Y81YHilbyhvReYuO48RaaZuIsJP5YmP281saJ03h9VW5lZbNJYJr+3hP lggj37hT6EFUr3pQzIceKvjFe3yhW1A2ZFUna7nNbRpp9eG/fe+V/49LO1ouH+2os4LX 2LeA== Received: by 10.182.72.8 with SMTP id z8mr9539239obu.87.1347356376927; Tue, 11 Sep 2012 02:39:36 -0700 (PDT) Received: by 10.182.72.8 with SMTP id z8mr9539230obu.87.1347356376841; Tue, 11 Sep 2012 02:39:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.187.8 with HTTP; Tue, 11 Sep 2012 02:39:16 -0700 (PDT) In-Reply-To: <5A99DF4A-AE52-4067-B4C2-065DE5F88FE9@laposte.net> References: <5A99DF4A-AE52-4067-B4C2-065DE5F88FE9@laposte.net> From: Lorenzo Colitti Date: Tue, 11 Sep 2012 18:39:16 +0900 Message-ID: To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=f46d0447893f3a3de304c969daf6 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmAFMiBzMgnkyi37ndDLL5PIkaq3aZ1gpAynbjXnHSRI4JtIIXakaZhCsrF9cbMSfHu5EeExf9G88Ryfff1FcgbCzhZSx+XvygODzSO2xqwMwS+q+Flg/Uu//v4niSWuJlH+Fu03U5hglrv/mi+LjYIg1kL6fj9esPps1EoXPB3CNW5aKpY30FPvKtoZJAGOZm4pBRy Cc: v6ops WG Subject: Re: [v6ops] Compromise text on 464XLAT and BIH X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 09:39:38 -0000 --f46d0447893f3a3de304c969daf6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Sep 11, 2012 at 6:33 PM, R=E9mi Despr=E9s wrote: > The compromise now reached, among active participants of a long discussio= n > on the relation between 464XLAT and BIH, is the following: > "464XLAT is not designed to cover the case of IPv4-only applications > having access to IPv6-only servers. If that is needed, BIH of [RFC6535] > provides a solution." > > Unless the discussion is restarted, it can replace the current wording o= f > the draft. > I don't see why we need this text at all. I don't think "restarting the discussion" is going to help convince me, I think it's more likely that it will only alienate the people who don't care= . Obviously, since proceeding only requies rough consensus, not unanimity, the WG is free to ignore my opinion if it is not shared by others. --f46d0447893f3a3de304c969daf6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Sep 11, 2012 at 6:33 PM, R=E9mi Despr=E9s <despres.remi@lap= oste.net> wrote:
    The compromise now reached, among = active participants of a long discussion on the relation between 464XLAT an= d BIH, is the following:
    "464XLAT is not designed to cover the cas= e of IPv4-only applications having access to IPv6-only servers. If that is = needed, BIH of [RFC6535] provides a solution."

    Unless the discussion is restarted, it can replace the = current wording =A0of the draft.

    I don't see why we need this text at all.

    I=A0don't think "restarting the discussion" is going to = help convince me, I think it's more likely that it will only alienate t= he people who don't care.

    Obviously, since pro= ceeding only requies rough consensus, not unanimity, the WG is=A0free to ig= nore my opinion if it is not shared by others.
    --f46d0447893f3a3de304c969daf6-- From ietfc@btconnect.com Tue Sep 11 03:41:41 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7068821F87C6 for ; Tue, 11 Sep 2012 03:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.306 X-Spam-Level: X-Spam-Status: No, score=-3.306 tagged_above=-999 required=5 tests=[AWL=0.293, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RKLSeufFXsoc for ; Tue, 11 Sep 2012 03:41:41 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by ietfa.amsl.com (Postfix) with ESMTP id DABEC21F87C3 for ; Tue, 11 Sep 2012 03:41:40 -0700 (PDT) Received: from mail34-va3-R.bigfish.com (10.7.14.246) by VA3EHSOBE002.bigfish.com (10.7.40.22) with Microsoft SMTP Server id 14.1.225.23; Tue, 11 Sep 2012 10:41:37 +0000 Received: from mail34-va3 (localhost [127.0.0.1]) by mail34-va3-R.bigfish.com (Postfix) with ESMTP id CB90B2A00C4; Tue, 11 Sep 2012 10:41:37 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.253.85; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0710HT002.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: PS-24(zz98dI9371I542M1432Izz1202h1d1ahzz1033IL8275bh8275dhz2dh2a8h5a9h668h839hd24hf0ah107ah1177h1179h1288h12a5h12a9h12bdh304l1155h) Received: from mail34-va3 (localhost.localdomain [127.0.0.1]) by mail34-va3 (MessageSwitch) id 1347360095336134_17246; Tue, 11 Sep 2012 10:41:35 +0000 (UTC) Received: from VA3EHSMHS009.bigfish.com (unknown [10.7.14.235]) by mail34-va3.bigfish.com (Postfix) with ESMTP id 4E2781E0046; Tue, 11 Sep 2012 10:41:35 +0000 (UTC) Received: from DB3PRD0710HT002.eurprd07.prod.outlook.com (157.56.253.85) by VA3EHSMHS009.bigfish.com (10.7.99.19) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 11 Sep 2012 10:41:35 +0000 Received: from DB3PRD0610HT003.eurprd06.prod.outlook.com (157.56.252.53) by pod51017.outlook.com (10.255.75.37) with Microsoft SMTP Server (TLS) id 14.16.190.9; Tue, 11 Sep 2012 10:41:30 +0000 Message-ID: <046f01cd900a$18dcab00$4001a8c0@gateway.2wire.net> From: t.petch To: Lorenzo Colitti References: Date: Tue, 11 Sep 2012 11:41:23 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.252.53] X-OriginatorOrg: btconnect.com Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 10:41:41 -0000 ----- Original Message ----- From: "Lorenzo Colitti" To: "GangChen" Cc: "v6ops WG" Sent: Tuesday, September 11, 2012 9:49 AM > On Tue, Sep 11, 2012 at 5:40 PM, GangChen wrote: > > > If the rough consensus should be respected, if the past discussions > > should be respected, if some implementation efforts should be > > respected, I hope you conclude a) the discussion stops, b) take > > current proposal, and c) we move on. > > > I don't see rough consensus. It seems to me that you and Remi want BIH to > be mentioned, Maoke does not, I prefer not, and Gert and Tim don't want it > to be mentioned. Where is the consensus there? In the hope that it may help those responsible for judging consensus, I too would be happy to see BIH removed altogether. I note that Cameron was also of this view on the 8th May, albeit a few thousand e-mails ago. Tom Petch From phdgang@gmail.com Tue Sep 11 04:50:54 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CE1E21F87D0 for ; Tue, 11 Sep 2012 04:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.807 X-Spam-Level: X-Spam-Status: No, score=-2.807 tagged_above=-999 required=5 tests=[AWL=-0.408, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qerzmgRz1YUT for ; Tue, 11 Sep 2012 04:50:53 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3524721F87CC for ; Tue, 11 Sep 2012 04:50:46 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so574041vcb.31 for ; Tue, 11 Sep 2012 04:50:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=18WaOiMP3txdpdh4oB+dICr+UMwzwJG0C3U73sHR09A=; b=HTBCeVAjCM2qq/5qsgHHsxzbCFlmmnDYZILiiEpeejO0/3fcFYFmaFUYqQLhcCdj+p mv1+fNSOpiW65lasOXdKg7bioXQugmrXVjhnRHeZdT7jw3LdcOsbjkzpdyq3t/1MLjzJ kvkErR9YU0cgr2XC9Jb4bF1g2YclLWQcggUu5DR6znxOmPK/o0Qcf7uiU8eUTWeOzwg/ DqNJ1D8hPEzLlA7aGez2SJf1BlH2XVIYglF0iTMjo/ATLQFb7o3LgUXNE8pYO1T3SoJ3 5cy2e/kIDi4zxLMHNpTysrBu8UJD8FxEEjcJrIMBegW0H+ZF8kZ2Z4ZmHM91P1m2RUKJ u4rw== MIME-Version: 1.0 Received: by 10.52.34.204 with SMTP id b12mr19927405vdj.75.1347364245482; Tue, 11 Sep 2012 04:50:45 -0700 (PDT) Received: by 10.58.114.231 with HTTP; Tue, 11 Sep 2012 04:50:45 -0700 (PDT) In-Reply-To: <046f01cd900a$18dcab00$4001a8c0@gateway.2wire.net> References: <046f01cd900a$18dcab00$4001a8c0@gateway.2wire.net> Date: Tue, 11 Sep 2012 19:50:45 +0800 Message-ID: From: GangChen To: "t.petch" Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 11:50:54 -0000 Hello Tom, 2012/9/11, t.petch : > ----- Original Message ----- > From: "Lorenzo Colitti" > To: "GangChen" > Cc: "v6ops WG" > Sent: Tuesday, September 11, 2012 9:49 AM >> On Tue, Sep 11, 2012 at 5:40 PM, GangChen wrote: >> >> > If the rough consensus should be respected, if the past discussions >> > should be respected, if some implementation efforts should be >> > respected, I hope you conclude a) the discussion stops, b) take >> > current proposal, and c) we move on. >> > >> I don't see rough consensus. It seems to me that you and Remi want BIH > to >> be mentioned, Maoke does not, I prefer not, and Gert and Tim don't > want it >> to be mentioned. Where is the consensus there? > > In the hope that it may help those responsible for judging consensus, I > too would be happy to see BIH removed altogether. > > I note that Cameron was also of this view on the 8th May, albeit a few > thousand e-mails ago. As you noted, that was the situation long-time before. The past discussions help to achieve the consensus which was documented in the draft. For what I can see, Cameron claimed the position in http://www.ietf.org/mail-archive/web/v6ops/current/msg14176.html several days ago Just claming the appeal and length discussion without justification really doesn't benefit everybody's timing here as mentioned in the list BRs Gang > Tom Petch > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From tom.taylor.stds@gmail.com Tue Sep 11 05:49:43 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97D3721F87C6 for ; Tue, 11 Sep 2012 05:49:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7osOeriSbCj1 for ; Tue, 11 Sep 2012 05:49:43 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0E63121F87EA for ; Tue, 11 Sep 2012 05:49:42 -0700 (PDT) Received: by vbbfc26 with SMTP id fc26so655204vbb.31 for ; Tue, 11 Sep 2012 05:49:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-antivirus:x-antivirus-status; bh=uU2f3z7rSPe2Q3xLv9EaYaFLyr6aBAweWpzAHw6/igo=; b=Cr4oFVAD7aIB6TOF3zA6mu4zzyOwCs1ufmxC9wye0ODjaYE7xezZ18+A5LNeseIBZi KTAj2eGePFmqFnqhphvhrbgW9vvrIX2p99MrZNN4rLITeFe/WtotFMzU61hTzbe9mu+z lHsXKKjS8NHtgZX1hL/ygfWnD0zli7viz+njDap3yUacXSo46vN27qVqubkJ8hWZULl4 1rkirpt0nSNEvIjikK5/6s8H40RmYrJyVHHck9DbmIMRI3P1pMp51ZshYWCMq7U4uBNP KK1FMCMikBW+LdCBngJwo0974gfQuHHt5iYsTlSRCi3vF041S6joMZRYNx6brxtv1pKj 0GmA== Received: by 10.58.74.196 with SMTP id w4mr26988616vev.7.1347367782461; Tue, 11 Sep 2012 05:49:42 -0700 (PDT) Received: from [127.0.0.1] ([207.112.101.149]) by mx.google.com with ESMTPS id t12sm5284253vdi.18.2012.09.11.05.49.40 (version=SSLv3 cipher=OTHER); Tue, 11 Sep 2012 05:49:41 -0700 (PDT) Message-ID: <504F3362.6040801@gmail.com> Date: Tue, 11 Sep 2012 08:49:38 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Lorenzo Colitti References: <810EAE3D-8767-4E66-911D-3DBDFE8B9403@laposte.net> <4730A653-CD11-4A08-9254-2C80C739D646@laposte.net> <20120910180231.GV13776@Space.Net> <7AB4B335-22DE-497C-A854-ACB560F2DE64@ecs.soton.ac.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 120911-0, 11/09/2012), Outbound message X-Antivirus-Status: Clean Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 12:49:43 -0000 So do I. Rémi, truth is a necessary but not a sufficient condition for relevance. And sheer persistence does not demonstrate consensus. Tom T. On 11/09/2012 4:31 AM, Lorenzo Colitti wrote: > On Tue, Sep 11, 2012 at 5:27 PM, Rémi Després > wrote: > > Expressing NOW objections to the result of the discussion amounts to > restarting this discussion. > Is this really what you wish? > > > I think if you read his email carefully, you'll conclude that what he > would like to see is: a) the discussion stops, b) the reference to BIH > is taken out, and c) we move on. I agree. > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From despres.remi@laposte.net Tue Sep 11 06:11:18 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88D5721F8803 for ; Tue, 11 Sep 2012 06:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.931 X-Spam-Level: X-Spam-Status: No, score=-0.931 tagged_above=-999 required=5 tests=[AWL=-0.182, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ahfhQpfNndcR for ; Tue, 11 Sep 2012 06:11:18 -0700 (PDT) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.3]) by ietfa.amsl.com (Postfix) with ESMTP id CC2E121F8800 for ; Tue, 11 Sep 2012 06:11:17 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2112.sfr.fr (SMTP Server) with ESMTP id 0B135700009F; Tue, 11 Sep 2012 15:11:17 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2112.sfr.fr (SMTP Server) with ESMTP id E211F7000109; Tue, 11 Sep 2012 15:11:15 +0200 (CEST) X-SFR-UUID: 20120911131115926.E211F7000109@msfrf2112.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?= X-Priority: 3 In-Reply-To: <046f01cd900a$18dcab00$4001a8c0@gateway.2wire.net> Date: Tue, 11 Sep 2012 15:11:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8798C55B-E2C9-4E80-84CA-A01661730C2D@laposte.net> References: <046f01cd900a$18dcab00$4001a8c0@gateway.2wire.net> To: t.petch X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 13:11:18 -0000 Le 2012-09-11 =E0 12:41, t.petch a =E9crit : > ----- Original Message ----- > From: "Lorenzo Colitti" > To: "GangChen" > Cc: "v6ops WG" > Sent: Tuesday, September 11, 2012 9:49 AM >> On Tue, Sep 11, 2012 at 5:40 PM, GangChen wrote: >>=20 >>> If the rough consensus should be respected, if the past discussions >>> should be respected, if some implementation efforts should be >>> respected, I hope you conclude a) the discussion stops, b) take >>> current proposal, and c) we move on. >>>=20 >> I don't see rough consensus. It seems to me that you and Remi want = BIH > to >> be mentioned, Maoke does not, I prefer not, and Gert and Tim don't > want it >> to be mentioned. Where is the consensus there? >=20 > In the hope that it may help those responsible for judging consensus, = I > too would be happy to see BIH removed altogether. >=20 > I note that Cameron was also of this view on the 8th May, albeit a few > thousand e-mails ago. Lorenzo has indeed been clear that he didn't favor any statement about = BIH, but he also has expressed openness to keeping one. (See "if you = don't want to remove BIH, then please suggest text to address this = issue..." at least at the end of = /www.ietf.org/mail-archive/web/v6ops/current/msg14159.html) Since the detailed discussion has finally clarified that there is = nothing contentious in the proposed statement, I think there is no need = to refuse the compromise, and no need to restart a debate as though it = hadn't already taken place. Regards, RD >=20 > Tom Petch >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From despres.remi@laposte.net Tue Sep 11 06:19:57 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD22F21F87E0 for ; Tue, 11 Sep 2012 06:19:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.227 X-Spam-Level: X-Spam-Status: No, score=-1.227 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LaGTtxNzI54l for ; Tue, 11 Sep 2012 06:19:57 -0700 (PDT) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.3]) by ietfa.amsl.com (Postfix) with ESMTP id DB57321F87D8 for ; Tue, 11 Sep 2012 06:19:56 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2112.sfr.fr (SMTP Server) with ESMTP id 13BF070000E3; Tue, 11 Sep 2012 15:19:56 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2112.sfr.fr (SMTP Server) with ESMTP id 4E90270000BF; Tue, 11 Sep 2012 15:19:55 +0200 (CEST) X-SFR-UUID: 20120911131955321.4E90270000BF@msfrf2112.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: <504F3362.6040801@gmail.com> Date: Tue, 11 Sep 2012 15:19:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7D651C45-00CF-4406-A416-C8B2CAB098B4@laposte.net> References: <810EAE3D-8767-4E66-911D-3DBDFE8B9403@laposte.net> <4730A653-CD11-4A08-9254-2C80C739D646@laposte.net> <20120910180231.GV13776@Space.Net> <7AB4B335-22DE-497C-A854-ACB560F2DE64@ecs.soton.ac.uk> <504F3362.6040801@gmail.com> To: Tom Taylor X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 13:19:57 -0000 2012-09-11 =E0 14:49, Tom Taylor : > So do I. >=20 > R=E9mi, truth is a necessary but not a sufficient condition for = relevance. And sheer persistence does not demonstrate consensus. Tim: No need to explain what I have know for years ;-). As said about the sentence that mentions complementarity of 4X4XLAT and = BIH, in particular in = www.ietf.org/mail-archive/web/v6ops/current/msg14244.html: - It is true - It expresses that, contrary to some doubts recently expressed, there = is no contradiction between 464XLAT and BIH (RFC 6536 on BIH is little = known, but does exist on standard-track). - It is a correction of a wrong statement of draft-00 suggesting that, = with 464XLAT, "it is also possible to provide single IPv4/IPv6 = translation service, which will be needed in the future case of = IPv6-only servers and peers to be reached from legacy IPv4-only hosts". - It is an improved version of a sentence which has been in the draft = for quite some time.=20 Objections to this sentence are essentially based on "we don't care, and = would be happy if those who care would stop doing it". Hope it helps to move on without restarting a long debate. RD >=20 > Tom T. >=20 > On 11/09/2012 4:31 AM, Lorenzo Colitti wrote: >> On Tue, Sep 11, 2012 at 5:27 PM, R=E9mi Despr=E9s = > > wrote: >>=20 >> Expressing NOW objections to the result of the discussion amounts = to >> restarting this discussion. >> Is this really what you wish? >>=20 >>=20 >> I think if you read his email carefully, you'll conclude that what he >> would like to see is: a) the discussion stops, b) the reference to = BIH >> is taken out, and c) we move on. I agree. >>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 From ietfc@btconnect.com Tue Sep 11 10:19:42 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F68121F869C for ; Tue, 11 Sep 2012 10:19:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.062 X-Spam-Level: X-Spam-Status: No, score=-3.062 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-ve7W9XBkEv for ; Tue, 11 Sep 2012 10:19:41 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id 6C22521F8773 for ; Tue, 11 Sep 2012 10:19:41 -0700 (PDT) Received: from mail40-ch1-R.bigfish.com (10.43.68.253) by CH1EHSOBE011.bigfish.com (10.43.70.61) with Microsoft SMTP Server id 14.1.225.23; Tue, 11 Sep 2012 17:19:40 +0000 Received: from mail40-ch1 (localhost [127.0.0.1]) by mail40-ch1-R.bigfish.com (Postfix) with ESMTP id B9FD430015F; Tue, 11 Sep 2012 17:19:40 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.249.213; KIP:(null); UIP:(null); IPV:NLI; H:AM2PRD0710HT005.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: PS-25(zzbb2dI98dI9371I542M1432Izz1202h1d1ahzz1033IL17326ah8275bh8275dhz2dh2a8h5a9h668h839hd24hf0ah107ah1177h1179h1288h12a5h12a9h12bdh304l1155h) Received: from mail40-ch1 (localhost.localdomain [127.0.0.1]) by mail40-ch1 (MessageSwitch) id 1347383978856811_21663; Tue, 11 Sep 2012 17:19:38 +0000 (UTC) Received: from CH1EHSMHS017.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.240]) by mail40-ch1.bigfish.com (Postfix) with ESMTP id C561B46004F; Tue, 11 Sep 2012 17:19:38 +0000 (UTC) Received: from AM2PRD0710HT005.eurprd07.prod.outlook.com (157.56.249.213) by CH1EHSMHS017.bigfish.com (10.43.70.17) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 11 Sep 2012 17:19:37 +0000 Received: from BL2PRD0410HT001.namprd04.prod.outlook.com (157.56.240.85) by pod51017.outlook.com (10.255.165.40) with Microsoft SMTP Server (TLS) id 14.16.190.9; Tue, 11 Sep 2012 17:19:30 +0000 Message-ID: <00cf01cd9041$b23b09e0$4001a8c0@gateway.2wire.net> From: t.petch To: GangChen References: <046f01cd900a$18dcab00$4001a8c0@gateway.2wire.net> Date: Tue, 11 Sep 2012 18:19:39 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.240.85] X-OriginatorOrg: btconnect.com Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 17:19:42 -0000 ----- Original Message ----- From: "GangChen" To: "t.petch" Cc: "Lorenzo Colitti" ; "v6ops WG" Sent: Tuesday, September 11, 2012 12:50 PM > Hello Tom, > > 2012/9/11, t.petch : > > ----- Original Message ----- > > From: "Lorenzo Colitti" > > To: "GangChen" > > Cc: "v6ops WG" > > Sent: Tuesday, September 11, 2012 9:49 AM > >> On Tue, Sep 11, 2012 at 5:40 PM, GangChen wrote: > >> > >> > If the rough consensus should be respected, if the past discussions > >> > should be respected, if some implementation efforts should be > >> > respected, I hope you conclude a) the discussion stops, b) take > >> > current proposal, and c) we move on. > >> > > >> I don't see rough consensus. It seems to me that you and Remi want BIH > > to > >> be mentioned, Maoke does not, I prefer not, and Gert and Tim don't > > want it > >> to be mentioned. Where is the consensus there? > > > > In the hope that it may help those responsible for judging consensus, I > > too would be happy to see BIH removed altogether. > > > > I note that Cameron was also of this view on the 8th May, albeit a few > > thousand e-mails ago. > > As you noted, that was the situation long-time before. > The past discussions help to achieve the consensus which was > documented in the draft. May is not that long ago, and it is a concern of mine just how many twists and turns there have been in the course of this year, of changes to solution, scenario and so on. That suggests to me that there is something wrong here, even if I cannot put my finger on it more precisely. On BIH in particular, I would expect a BIH memo to say what it has to say about itself, I fail to see why a 464XLAT memo should refer to it at all, a point which has been made on a number of occasions on this list. As to where the consensus lies on such a point, I leave that to others more expert in judging such matters than I to decide. Tom Petch > For what I can see, Cameron claimed the position in > http://www.ietf.org/mail-archive/web/v6ops/current/msg14176.html > several days ago > > Just claming the appeal and length discussion without justification > really doesn't benefit everybody's timing here as mentioned in the > list > > BRs > > Gang > > > Tom Petch From iesg-secretary@ietf.org Tue Sep 11 12:52:05 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D52D21F870F; Tue, 11 Sep 2012 12:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SeORUqo0oLqQ; Tue, 11 Sep 2012 12:52:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CFE021F86FC; Tue, 11 Sep 2012 12:51:54 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120911195154.12873.14196.idtracker@ietfa.amsl.com> Date: Tue, 11 Sep 2012 12:51:54 -0700 Cc: v6ops@ietf.org Subject: [v6ops] Last Call: (Stateless Source Address Mapping for ICMPv6 Packets) to Best Current Practice X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 19:52:06 -0000 The IESG has received a request from the IPv6 Operations WG (v6ops) to consider the following document: - 'Stateless Source Address Mapping for ICMPv6 Packets' as Best Current Practice 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 2012-09-25. 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 A stateless IPv4/IPv6 translator may receive ICMPv6 packets containing non IPv4-translatable addresses as the source. These packets should be passed across the translator as ICMP packets directed to the IPv4 destination. This document presents recommendations for source address translation in ICMPv6 headers to handle such cases. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-v6ops-ivi-icmp-address/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-v6ops-ivi-icmp-address/ballot/ No IPR declarations have been submitted directly on this I-D. From tjc@ecs.soton.ac.uk Tue Sep 11 12:57:27 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69E7E21F8467 for ; Tue, 11 Sep 2012 12:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YY463kU-DW5g for ; Tue, 11 Sep 2012 12:57:26 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF5F21F860F for ; Tue, 11 Sep 2012 12:57:26 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q8BJvN3b024815 for ; Tue, 11 Sep 2012 20:57:23 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk q8BJvN3b024815 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1347393443; bh=pZOost2Fuh6CtBK3msV2TID5Pv8=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=P3PQuLyMj36r17AdXmMDd98IkV7IPNvLFxtP/9J78Ll4J45t2HRgPa+crMfxG4J/1 JqgyFinA7EgbufjGjYCF7q2g+38tv14JwViNO/ay3/VnUTL5bwkha2y2gkJqMnZXlR FvUrqlLnfZWA9H0PAir3Yhy3VZmL5uFF3MxvFmZQ= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id o8AKvN0430624211l2 ret-id none; Tue, 11 Sep 2012 20:57:23 +0100 Received: from [192.168.1.102] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q8BJvJNZ028299 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 11 Sep 2012 20:57:19 +0100 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Tim Chown In-Reply-To: Date: Tue, 11 Sep 2012 20:57:21 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <810EAE3D-8767-4E66-911D-3DBDFE8B9403@laposte.net> <4730A653-CD11-4A08-9254-2C80C739D646@laposte.net> <20120910180231.GV13776@Space.Net> <7AB4B335-22DE-497C-A854-ACB560F2DE64@ecs.soton.ac.uk> <38B39C58-7E74-4E76-A5D7-5B9E69CCE716@ecs.soton.ac.uk> To: v6ops WG X-Mailer: Apple Mail (2.1486) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=o8AKvN043062421100; tid=o8AKvN0430624211l2; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: q8BJvN3b024815 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 19:57:27 -0000 On 11 Sep 2012, at 09:27, R=E9mi Despr=E9s = wrote: > Th latest version of the proposed sentence is "464XLKAT is not = designed to cover the case of IPv4-only applications having access to = IPv6-only servers. If that is needed, BIH of [RFC6535] provides a = solution": > - It is true > - It expresses that, contrary to some doubts recently expressed, there = is no contradiction between 464XLAT and BIH (RFC 6536 on BIH is little = known, but does exist on standard-track). > - It is a correction of a wrong statement of draft-00 suggesting that, = with 464XLAT, "it is also possible to provide single IPv4/IPv6 = translation service, which will be needed in the future case of = IPv6-only servers and peers to be reached from legacy IPv4-only hosts". > - It is an improved version of a sentence which has been in the draft = for quite some time.=20 >=20 > Expressing NOW objections to the result of the discussion amounts to = restarting this discussion. > Is this really what you wish? Hi Remi, The WGLC invites comments, and thus some of us have made such comments = against adding a reference to BIH in this BCP document. You yourself say = above it's a 'future case', and it's not one that I believe was = originally targeted by the text, hence my suggestion for a separate = Informational document on its use for IPv6-only servers. I have no significant issues with the rest of the text, which I think is = a useful document. Tim From cb.list6@gmail.com Tue Sep 11 14:30:44 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB77A21F86B8 for ; Tue, 11 Sep 2012 14:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.794 X-Spam-Level: X-Spam-Status: No, score=-2.794 tagged_above=-999 required=5 tests=[AWL=-0.095, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xFnLotfI-hVw for ; Tue, 11 Sep 2012 14:30:44 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9DDD921F86B3 for ; Tue, 11 Sep 2012 14:30:43 -0700 (PDT) Received: by lahm15 with SMTP id m15so706594lah.31 for ; Tue, 11 Sep 2012 14:30:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=tcH0LqgEFC/GteWQ08UipGEW5Esh/m9qwjHmJPD7eWg=; b=wkvfA45Z3vKDlZBvmYHqplrVktEWwXnwfCOHwlcEp9xivW/rTufGB59UudR027XoZg Yv77otnrC6wFfmixKnYIVi9EVE5Xv1DkjIfMxeOfbGtafGJ4jNX6I0vaKPhWSXwpWIWd vJptuenibb3hUtflpGhVhA/mm3JoWZsFTt1vsfBSC48nQna0dS4V26FsYG2xkopM06/M hipfN8XaxN6DlWFsiTBqOsqs9oZ2ZGsY3pA0Y5VwXdfCi1DArXDBg1fNtNR7QEVwtngS 2m3oZJxUdbAnffFZTnYFJI8yYSTj8A5xjGzK0c2p8RGKKJb7fmajlXXVBt/wyalawOhy MZGA== MIME-Version: 1.0 Received: by 10.112.51.205 with SMTP id m13mr6490459lbo.75.1347399042565; Tue, 11 Sep 2012 14:30:42 -0700 (PDT) Received: by 10.112.49.66 with HTTP; Tue, 11 Sep 2012 14:30:42 -0700 (PDT) In-Reply-To: References: Date: Tue, 11 Sep 2012 14:30:42 -0700 Message-ID: From: Cameron Byrne To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Ops WG Subject: Re: [v6ops] 464XLAT removing IPv6 LAN scope X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 21:30:45 -0000 R=E9mi, On Sun, Sep 9, 2012 at 11:44 PM, R=E9mi Despr=E9s wrote: > > Le 2012-09-07 =E0 21:36, Cameron Byrne a =E9crit : > >> Folks, >> >> I hope we can all see the scope issue related /64 sharing across >> interfaces, it is simply not germane to the function of 464XLAT and it >> should be removed. >> >> A much more workable solution, from IETF perspective, is to simply say >> that 464XLAT supports the DHCP-PD scenario for a dedicated translation >> prefix (no challenges that i know of), and in the case of no DHCP-PD >> available the CLAT does normal CLAT function for IPv4 with NAT44 as >> described in section 8.3.2 >> >> Meaning, there is an IPv6-only WAN and an IPv4 capable LAN, no >> bridging or sharing of IPv6 across the CLAT is specified. >> >> I would like to move forward with 464XLAT by simply stating that >> DHCP-PD is the best choice for acquiring a dedicated /64 to be used >> with stateless translation. >> >> http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-07#section-8.3.2 >> >> For section 8.3.2 we can retain how IPv4 is treated with NAT44, but >> simply remove how IPv6 is treated. >> >> >> >> If the CLAT cannot perform ND Proxy [RFC4389] due to the restriction >> of the implementation, the CLAT may use a dedicated IANA assigned >> EUI-64 ID for creating a translated IPv6 address to be used in >> stateless translation [RFC6145]. This will allow the CLAT to avoid >> possible IPv6 address duplication issues between an IPv6 address for >> stateless translation [RFC6145] in the CLAT and an IPv6 address >> assigned to native IPv6 nodes behind the CLAT. This document >> describes an example for this case in Example 2. of the Appendix A. >> >> The CLAT MAY discover the Pref64::/n of the PLAT via some method such >> as TR-069, DNS APL RR [RFC3123] or >> [I-D.ietf-behave-nat64-discovery-heuristic]. >> >> >> >> >> >> We can also remove the IANA section and remove reference to ND proxy. >> If implementations choose to extend a /64 from WAN to LAN in cases >> where DHCP-PD is not available, they may, but it is out of scope for >> *THIS* I-D. Hopefully some of the discussion here can feed further >> work in this area that appears to be needed. > > Not sure to understand what you mean by "extend a /64 from WAN to LAN in = cases where DHCP-PD is not available". > (If a site only has a /64, there can be a LAN, but no prefix can be furth= er delegated on this LAN, independently of code being available to support = DHCP-PD.) > > >> I believe this brings us back to pure 464XLAT which is an architecture >> for double translation, not /64 cross-interface extensions and not a >> CPE router specification. > > In my recollection, NAT44s were introduced in the draft for LAN-supportin= g /64 sites. > Since then, we found that, with reserved IID ranges for CLATs, NAT44s are= no longer needed for such sites. > > Then, could you clarify your intention: > Is it to exclude /64-sites from the 464XLAT scope? > - If YES, 464XLAT would IMHO miss an important part of its natural target= . > - If NO, are you intending to keep NAT44s in the draft? Yes, we can define NAT44 on the LAN but we cannot define how to share a /64 from WAN to LAN. Thus, the draft can only cleanly state how to make a NAT44 LAN work with an IPv6-only WAN when DHCPv6 PD is not available. It's the state we find ourselves in. > . If YES, the 464XLAT BCP includes CLAT nodes that aren't completely sta= teless. This is contrary to the announced objective, and can't be justified= , IMHO, as it an be avoided just with three CLAT IID subranges. (This reser= vation is to be made in a range already available for such reservations, an= d is to be registered by IANA as usual if needed for an IETF BCP). > It is stateless at the CLAT in the case of DHCPv6 PD where a dedicated /64 translation prefix exists. DHCP-PD is a SHOULD. In the unfortunate case, but common in 3GPP today, where DHCPv6 PD does not exist, the CLAT can do stateful NAT44 from the LAN so that all IPv4 client packets are translated to 1 IPv4 address, and that 1 IPv4 address is then translated to 1 IPv6 address which is owned and defended with DAD by the CLAT. Thus, in a 3GPP network, IPv4 tethering can be supported across an IPv6-only network using 464XLAT double translation and NAT44. IPv6 tethering may also be supported by some method, but it will not mentioned in the draft since the WG cannot come to an agreed approach and it may be outside the scope of 464XLAT. R=E9mi -- your solution is elegant and good. But, you must agree that, for reasons i don't understand, it is unpopular in the eyes of the WG. As one of the 464XLAT authors, i agreed to add it in previous version of the I-D, but to move forward we must now remove it, and refocus the scope of 464XLAT on 464 translation and not on managing LAN addresses. I would very much like to see your idea of reserved IID specified for general application here in v6ops or 6MAN. CB > >> Any technical issues with this approach? > > See above. > > Regards, > RD > > > From phdgang@gmail.com Wed Sep 12 00:10:28 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5254F21F84E1 for ; Wed, 12 Sep 2012 00:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.181 X-Spam-Level: X-Spam-Status: No, score=-3.181 tagged_above=-999 required=5 tests=[AWL=-0.182, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EE5TmdOsozVb for ; Wed, 12 Sep 2012 00:10:27 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8F51421F84D6 for ; Wed, 12 Sep 2012 00:10:27 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so1873525vcb.31 for ; Wed, 12 Sep 2012 00:10:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=X10wpYyWbCxhwLDEUP/WK6mk16pYvB5P8I2ufcIc8ho=; b=h2X54XMs1ZWpOgU/sd6gEpYo9TVmOJeo3xZHSnPWWqWt24slnAny/2TxPRMcsH/q4j 71gQrryGPQQ9gKSfUzY9gsQJXDNeSD04kOW+8grL/yqm+KeP1+aMI59xN5xPZbb6REKZ K/5lIBlSqaBhEPDTMtoY5icp98/6bNyxcRbkxJ7I3W8lTAgM1pzmk5DBuLKC12L+CmLA 6QRVXaLKU8PffgiQwobJNckJkbgtB00cOLJNC6F0ubu//O1rSLX2W0RrxjNZiWp2Igb5 zghXlB9SEyYCGs/ueDztfQvskkDLVqDm+wBzZzZiiSOaFu4qfWw8SEPn465N+G7mIYkb VH/w== MIME-Version: 1.0 Received: by 10.59.1.162 with SMTP id bh2mr30863561ved.13.1347433826975; Wed, 12 Sep 2012 00:10:26 -0700 (PDT) Received: by 10.58.114.231 with HTTP; Wed, 12 Sep 2012 00:10:26 -0700 (PDT) In-Reply-To: <00cf01cd9041$b23b09e0$4001a8c0@gateway.2wire.net> References: <046f01cd900a$18dcab00$4001a8c0@gateway.2wire.net> <00cf01cd9041$b23b09e0$4001a8c0@gateway.2wire.net> Date: Wed, 12 Sep 2012 15:10:26 +0800 Message-ID: From: GangChen To: "t.petch" Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 07:10:28 -0000 2012/9/12, t.petch : > ----- Original Message ----- > From: "GangChen" > To: "t.petch" > Cc: "Lorenzo Colitti" ; "v6ops WG" > Sent: Tuesday, September 11, 2012 12:50 PM >> Hello Tom, >> >> 2012/9/11, t.petch : >> > ----- Original Message ----- >> > From: "Lorenzo Colitti" >> > To: "GangChen" >> > Cc: "v6ops WG" >> > Sent: Tuesday, September 11, 2012 9:49 AM >> >> On Tue, Sep 11, 2012 at 5:40 PM, GangChen > wrote: >> >> >> >> > If the rough consensus should be respected, if the past > discussions >> >> > should be respected, if some implementation efforts should be >> >> > respected, I hope you conclude a) the discussion stops, b) take >> >> > current proposal, and c) we move on. >> >> > >> >> I don't see rough consensus. It seems to me that you and Remi want > BIH >> > to >> >> be mentioned, Maoke does not, I prefer not, and Gert and Tim don't >> > want it >> >> to be mentioned. Where is the consensus there? >> > >> > In the hope that it may help those responsible for judging > consensus, I >> > too would be happy to see BIH removed altogether. >> > >> > I note that Cameron was also of this view on the 8th May, albeit a > few >> > thousand e-mails ago. >> >> As you noted, that was the situation long-time before. >> The past discussions help to achieve the consensus which was >> documented in the draft. > > May is not that long ago, and it is a concern of mine just how many > twists and turns there have been in the course of this year, of changes > to solution, scenario and so on. That suggests to me that there is > something wrong here, even if I cannot put my finger on it more > precisely. > > On BIH in particular, I would expect a BIH memo to say what it has to > say about itself, I fail to see why a 464XLAT memo should refer to it at > all, a point which has been made on a number of occasions on this list. Leaving aside the particular 464 context, the same goal (i.e. advancing IPv6-only deployment) is targeted by BIH and 464xlat. The past discussion helps us to identify the complementary relationship between those two. Ongoing efforts are dedicatedly expended under such guidance. That is the significance of *mentioned* texts. At this stage, I can't accept removing the texts just because some observations of "twists and turns". You could even help to identify the particular concerns that prevent those two from cooperation. That even is of value to teach people there is a lesson "don't do such combining thing". However, ignoring the fact without justifications and silence about the combination is irresponsible to the ongoing efforts and potential efforts of others. BRs Gang > As to where the consensus lies on such a point, I leave that to others > more expert in judging such matters than I to decide. > > Tom Petch > >> For what I can see, Cameron claimed the position in >> http://www.ietf.org/mail-archive/web/v6ops/current/msg14176.html >> several days ago >> >> Just claming the appeal and length discussion without justification >> really doesn't benefit everybody's timing here as mentioned in the >> list >> >> BRs >> >> Gang >> >> > Tom Petch > > > From despres.remi@laposte.net Wed Sep 12 01:02:14 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF10321F864D for ; Wed, 12 Sep 2012 01:02:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.23 X-Spam-Level: X-Spam-Status: No, score=-1.23 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uC4jn27jpL7J for ; Wed, 12 Sep 2012 01:02:14 -0700 (PDT) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.3]) by ietfa.amsl.com (Postfix) with ESMTP id A578C21F853F for ; Wed, 12 Sep 2012 01:02:13 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2113.sfr.fr (SMTP Server) with ESMTP id D732A70000AF; Wed, 12 Sep 2012 10:02:11 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2113.sfr.fr (SMTP Server) with ESMTP id 74FAE7000099; Wed, 12 Sep 2012 10:02:11 +0200 (CEST) X-SFR-UUID: 20120912080211479.74FAE7000099@msfrf2113.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: Date: Wed, 12 Sep 2012 10:02:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Cameron Byrne X-Mailer: Apple Mail (2.1084) Cc: IPv6 Ops WG Subject: Re: [v6ops] 464XLAT removing IPv6 LAN scope X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 08:02:14 -0000 Cameron, Thanks for the clarification. Unless I misunderstand, your currently favored plan is that, concerning = tethering in /64 sites, the draft: - supports it ONLY for IPv4 - imposes NAT44s to do it (stateful CLAT nodes) Yet, with three currently unused IID ranges reserved for CLATs, the = draft could, for /64 sites: - Avoid imposing NAT44s (=3D> completely stateless CLAT nodes) - Apply to sites that already do IPv6 tethering (independently of how = they do it). I don't share the view that a rough consensus with this solution would = be impossible: (a) The solution is AFAIK well understood by those who took the time to = see how it works. (b) Relevance of the solution has recently been supported by several = contributors (including yourself here below in your last comment, and by = the fact that, although you personally believe it is "unpopular in the = WG", you qualify it with "for reasons i don't understand".) =20 (c) A number of objections have indeed been expressed, but all have been = proven to be unjustified: problems with cascaded CLATs (not applicable = to /64 sites), problems with dual homing (precisely eliminated with = reserved IID ranges), uncertainty of IANA acceptance (answered by Ron in = Vancouver).=20 (d) Incorporating it is particularly easy (see a proposal in = www.ietf.org/mail-archive/web/v6ops/current/msg14077.html), bringing a = simplification (no need for NAT44 sections), and an important scope = extension (applicability to /64 sites that have their way to do IPv6 = tethering).=20 Conclusions: - I still hope the WG won't refuse progress for reasons that at least = neither you nor me can understand - If the rough consensus reached would nevertheless be to refuse this = progress, it will be without me. Best regards, RD=20 =20 2012-09-11 23:30, Cameron Byrne : > R=E9mi, >=20 > On Sun, Sep 9, 2012 at 11:44 PM, R=E9mi Despr=E9s = wrote: >>=20 >> Le 2012-09-07 =E0 21:36, Cameron Byrne a =E9crit : >>=20 >>> Folks, >>>=20 >>> I hope we can all see the scope issue related /64 sharing across >>> interfaces, it is simply not germane to the function of 464XLAT and = it >>> should be removed. >>>=20 >>> A much more workable solution, from IETF perspective, is to simply = say >>> that 464XLAT supports the DHCP-PD scenario for a dedicated = translation >>> prefix (no challenges that i know of), and in the case of no DHCP-PD >>> available the CLAT does normal CLAT function for IPv4 with NAT44 as >>> described in section 8.3.2 >>>=20 >>> Meaning, there is an IPv6-only WAN and an IPv4 capable LAN, no >>> bridging or sharing of IPv6 across the CLAT is specified. >>>=20 >>> I would like to move forward with 464XLAT by simply stating that >>> DHCP-PD is the best choice for acquiring a dedicated /64 to be used >>> with stateless translation. >>>=20 >>> http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-07#section-8.3.2 >>>=20 >>> For section 8.3.2 we can retain how IPv4 is treated with NAT44, but >>> simply remove how IPv6 is treated. >>>=20 >>> >>>=20 >>> If the CLAT cannot perform ND Proxy [RFC4389] due to the restriction >>> of the implementation, the CLAT may use a dedicated IANA assigned >>> EUI-64 ID for creating a translated IPv6 address to be used in >>> stateless translation [RFC6145]. This will allow the CLAT to avoid >>> possible IPv6 address duplication issues between an IPv6 address = for >>> stateless translation [RFC6145] in the CLAT and an IPv6 address >>> assigned to native IPv6 nodes behind the CLAT. This document >>> describes an example for this case in Example 2. of the Appendix A. >>>=20 >>> The CLAT MAY discover the Pref64::/n of the PLAT via some method = such >>> as TR-069, DNS APL RR [RFC3123] or >>> [I-D.ietf-behave-nat64-discovery-heuristic]. >>>=20 >>>=20 >>> >>>=20 >>>=20 >>> We can also remove the IANA section and remove reference to ND = proxy. >>> If implementations choose to extend a /64 from WAN to LAN in cases >>> where DHCP-PD is not available, they may, but it is out of scope for >>> *THIS* I-D. Hopefully some of the discussion here can feed further >>> work in this area that appears to be needed. >>=20 >> Not sure to understand what you mean by "extend a /64 from WAN to LAN = in cases where DHCP-PD is not available". >> (If a site only has a /64, there can be a LAN, but no prefix can be = further delegated on this LAN, independently of code being available to = support DHCP-PD.) >>=20 >>=20 >>> I believe this brings us back to pure 464XLAT which is an = architecture >>> for double translation, not /64 cross-interface extensions and not a >>> CPE router specification. >>=20 >> In my recollection, NAT44s were introduced in the draft for = LAN-supporting /64 sites. >> Since then, we found that, with reserved IID ranges for CLATs, NAT44s = are no longer needed for such sites. >>=20 >> Then, could you clarify your intention: >> Is it to exclude /64-sites from the 464XLAT scope? >> - If YES, 464XLAT would IMHO miss an important part of its natural = target. >> - If NO, are you intending to keep NAT44s in the draft? >=20 > Yes, we can define NAT44 on the LAN but we cannot define how to share > a /64 from WAN to LAN. Thus, the draft can only cleanly state how to > make a NAT44 LAN work with an IPv6-only WAN when DHCPv6 PD is not > available. >=20 > It's the state we find ourselves in. >=20 >> . If YES, the 464XLAT BCP includes CLAT nodes that aren't completely = stateless. This is contrary to the announced objective, and can't be = justified, IMHO, as it an be avoided just with three CLAT IID subranges. = (This reservation is to be made in a range already available for such = reservations, and is to be registered by IANA as usual if needed for an = IETF BCP). >>=20 >=20 > It is stateless at the CLAT in the case of DHCPv6 PD where a dedicated > /64 translation prefix exists. DHCP-PD is a SHOULD. >=20 > In the unfortunate case, but common in 3GPP today, where DHCPv6 PD > does not exist, the CLAT can do stateful NAT44 from the LAN so that > all IPv4 client packets are translated to 1 IPv4 address, and that 1 > IPv4 address is then translated to 1 IPv6 address which is owned and > defended with DAD by the CLAT. >=20 > Thus, in a 3GPP network, IPv4 tethering can be supported across an > IPv6-only network using 464XLAT double translation and NAT44. IPv6 > tethering may also be supported by some method, but it will not > mentioned in the draft since the WG cannot come to an agreed approach > and it may be outside the scope of 464XLAT. >=20 > R=E9mi -- your solution is elegant and good. But, you must agree = that, > for reasons i don't understand, it is unpopular in the eyes of the WG. > As one of the 464XLAT authors, i agreed to add it in previous version > of the I-D, but to move forward we must now remove it, and refocus the > scope of 464XLAT on 464 translation and not on managing LAN addresses. >=20 > I would very much like to see your idea of reserved IID specified for > general application here in v6ops or 6MAN. >=20 > CB >=20 >>=20 >>> Any technical issues with this approach? >>=20 >> See above. >>=20 >> Regards, >> RD >>=20 >>=20 >>=20 From despres.remi@laposte.net Wed Sep 12 01:27:37 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A6DD21F84E4 for ; Wed, 12 Sep 2012 01:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.232 X-Spam-Level: X-Spam-Status: No, score=-1.232 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gF4+K9qIghV3 for ; Wed, 12 Sep 2012 01:27:36 -0700 (PDT) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.3]) by ietfa.amsl.com (Postfix) with ESMTP id 4606721F84E6 for ; Wed, 12 Sep 2012 01:27:36 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2113.sfr.fr (SMTP Server) with ESMTP id 708707000079; Wed, 12 Sep 2012 10:27:35 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2113.sfr.fr (SMTP Server) with ESMTP id 14ED470000B0; Wed, 12 Sep 2012 10:27:35 +0200 (CEST) X-SFR-UUID: 20120912082735858.14ED470000B0@msfrf2113.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: Date: Wed, 12 Sep 2012 10:27:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9AD650AE-B9B8-4D70-86BD-E1830A46439B@laposte.net> References: <810EAE3D-8767-4E66-911D-3DBDFE8B9403@laposte.net> <4730A653-CD11-4A08-9254-2C80C739D646@laposte.net> <20120910180231.GV13776@Space.Net> <7AB4B335-22DE-497C-A854-ACB560F2DE64@ecs.soton.ac.uk> <38B39C58-7E74-4E76-A5D7-5B9E69CCE716@ecs.soton.ac.uk> To: Tim Chown X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] draft-ietf-v6ops-464xlat WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 08:27:37 -0000 2012-09-11 21:57, Tim Chown : > On 11 Sep 2012, at 09:27, R=E9mi Despr=E9s = wrote: >=20 >> Th latest version of the proposed sentence is "464XLKAT is not = designed to cover the case of IPv4-only applications having access to = IPv6-only servers. If that is needed, BIH of [RFC6535] provides a = solution": >> - It is true >> - It expresses that, contrary to some doubts recently expressed, = there is no contradiction between 464XLAT and BIH (RFC 6536 on BIH is = little known, but does exist on standard-track). >> - It is a correction of a wrong statement of draft-00 suggesting = that, with 464XLAT, "it is also possible to provide single IPv4/IPv6 = translation service, which will be needed in the future case of = IPv6-only servers and peers to be reached from legacy IPv4-only hosts". >> - It is an improved version of a sentence which has been in the draft = for quite some time.=20 >>=20 >> Expressing NOW objections to the result of the discussion amounts to = restarting this discussion. >> Is this really what you wish? >=20 > Hi Remi, >=20 > The WGLC invites comments, and thus some of us have made such comments = against adding a reference to BIH in this BCP document. You yourself say = above it's a 'future case', and it's not one that I believe was = originally targeted by the text, hence my suggestion for a separate = Informational document on its use for IPv6-only servers. 1. I would personally have preferred to avoid words such as "in the = future case" but, in a sense of compromise with views expressed by = others, in particular by Brian Carpenter on this ML, I confirm I can = _accept_ them. The important fact that remains is that BIH is specified = in an existing standard-track RFC. Checking compatibility with it = therefore makes sense even if deployments may all be in the future = (which I don't know). 2. Contrary to your belief, this case WAS "originally targeted by the = text". Introduction of version -00 had "it is also possible to provide = single IPv4/IPv6 translation service, which will be needed in the future = case of IPv6-only servers and peers to be reached from legacy IPv4-only = hosts". It later appeared that BIH was the already specified tool for = that. RD >=20 > I have no significant issues with the rest of the text, which I think = is a useful document. >=20 > Tim >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From cb.list6@gmail.com Wed Sep 12 05:58:38 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F207E21F8575 for ; Wed, 12 Sep 2012 05:58:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.786 X-Spam-Level: X-Spam-Status: No, score=-2.786 tagged_above=-999 required=5 tests=[AWL=-0.088, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7g10viSqlWEm for ; Wed, 12 Sep 2012 05:58:36 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3E01021F8564 for ; Wed, 12 Sep 2012 05:58:36 -0700 (PDT) Received: by lbky2 with SMTP id y2so1231848lbk.31 for ; Wed, 12 Sep 2012 05:58:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fZsJZCoRxew24bLyLF+AsM35pXB6yaxO0he4wesUkhE=; b=AbjSDf9pExljENOq0z4JofqfWYTvPLcBk8GHc8azF2F4lGmDKlCTtQ4p7dLQL3c8b9 f0iiOGaWNub/EQQjf4b6M1pTQMZdDq+WtKGEKXg/I0VK07O0Sz3a7zi3pQ3rQOAgpiMz wtR0sjW/C2Rw61pIRNkB1e+q736T0DPKjEam56jOA6u20wvb0UrPeDMcVXySZ9VtlGh/ dQjaOrRFcTernfHPLWKVqhLWxrz/sYYlsjC0tzXvP/hAXHPRVnqn2wbieTN9fIda/fo3 LyRMi0qcAgxfVM213bFGuKDp4atRls5pkkMQMm2tpZCHpODAxyq+K9GwWLUyIX7Qhymr NgPQ== MIME-Version: 1.0 Received: by 10.152.104.202 with SMTP id gg10mr1800636lab.56.1347454715007; Wed, 12 Sep 2012 05:58:35 -0700 (PDT) Received: by 10.112.49.66 with HTTP; Wed, 12 Sep 2012 05:58:34 -0700 (PDT) Received: by 10.112.49.66 with HTTP; Wed, 12 Sep 2012 05:58:34 -0700 (PDT) In-Reply-To: References: Date: Wed, 12 Sep 2012 05:58:34 -0700 Message-ID: From: Cameron Byrne To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=f46d04089017a392b304c980bf88 Cc: IPv6 Ops WG Subject: Re: [v6ops] 464XLAT removing IPv6 LAN scope X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 12:58:38 -0000 --f46d04089017a392b304c980bf88 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sep 12, 2012 1:02 AM, "R=E9mi Despr=E9s" wrot= e: > > Cameron, > > Thanks for the clarification. > Unless I misunderstand, your currently favored plan is that, concerning tethering in /64 sites, the draft: > - supports it ONLY for IPv4 > - imposes NAT44s to do it (stateful CLAT nodes) > > Yet, with three currently unused IID ranges reserved for CLATs, the draft could, for /64 sites: > - Avoid imposing NAT44s (=3D> completely stateless CLAT nodes) > - Apply to sites that already do IPv6 tethering (independently of how they do it). > > I don't share the view that a rough consensus with this solution would be impossible: > (a) The solution is AFAIK well understood by those who took the time to see how it works. > (b) Relevance of the solution has recently been supported by several contributors (including yourself here below in your last comment, and by the fact that, although you personally believe it is "unpopular in the WG", you qualify it with "for reasons i don't understand".) > (c) A number of objections have indeed been expressed, but all have been proven to be unjustified: problems with cascaded CLATs (not applicable to /64 sites), problems with dual homing (precisely eliminated with reserved IID ranges), uncertainty of IANA acceptance (answered by Ron in Vancouver). > (d) Incorporating it is particularly easy (see a proposal in www.ietf.org/mail-archive/web/v6ops/current/msg14077.html), bringing a simplification (no need for NAT44 sections), and an important scope extension (applicability to /64 sites that have their way to do IPv6 tethering). > > Conclusions: > - I still hope the WG won't refuse progress for reasons that at least neither you nor me can understand > - If the rough consensus reached would nevertheless be to refuse this progress, it will be without me. > > Best regards, > RD > All that said, is the wg ok with accepting with Remi's solution? Silence means no support. CB > > > 2012-09-11 23:30, Cameron Byrne : > > > R=E9mi, > > > > On Sun, Sep 9, 2012 at 11:44 PM, R=E9mi Despr=E9s wrote: > >> > >> Le 2012-09-07 =E0 21:36, Cameron Byrne a =E9crit : > >> > >>> Folks, > >>> > >>> I hope we can all see the scope issue related /64 sharing across > >>> interfaces, it is simply not germane to the function of 464XLAT and i= t > >>> should be removed. > >>> > >>> A much more workable solution, from IETF perspective, is to simply sa= y > >>> that 464XLAT supports the DHCP-PD scenario for a dedicated translatio= n > >>> prefix (no challenges that i know of), and in the case of no DHCP-PD > >>> available the CLAT does normal CLAT function for IPv4 with NAT44 as > >>> described in section 8.3.2 > >>> > >>> Meaning, there is an IPv6-only WAN and an IPv4 capable LAN, no > >>> bridging or sharing of IPv6 across the CLAT is specified. > >>> > >>> I would like to move forward with 464XLAT by simply stating that > >>> DHCP-PD is the best choice for acquiring a dedicated /64 to be used > >>> with stateless translation. > >>> > >>> http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-07#section-8.3.2 > >>> > >>> For section 8.3.2 we can retain how IPv4 is treated with NAT44, but > >>> simply remove how IPv6 is treated. > >>> > >>> > >>> > >>> If the CLAT cannot perform ND Proxy [RFC4389] due to the restriction > >>> of the implementation, the CLAT may use a dedicated IANA assigned > >>> EUI-64 ID for creating a translated IPv6 address to be used in > >>> stateless translation [RFC6145]. This will allow the CLAT to avoid > >>> possible IPv6 address duplication issues between an IPv6 address for > >>> stateless translation [RFC6145] in the CLAT and an IPv6 address > >>> assigned to native IPv6 nodes behind the CLAT. This document > >>> describes an example for this case in Example 2. of the Appendix A. > >>> > >>> The CLAT MAY discover the Pref64::/n of the PLAT via some method suc= h > >>> as TR-069, DNS APL RR [RFC3123] or > >>> [I-D.ietf-behave-nat64-discovery-heuristic]. > >>> > >>> > >>> > >>> > >>> > >>> We can also remove the IANA section and remove reference to ND proxy. > >>> If implementations choose to extend a /64 from WAN to LAN in cases > >>> where DHCP-PD is not available, they may, but it is out of scope for > >>> *THIS* I-D. Hopefully some of the discussion here can feed further > >>> work in this area that appears to be needed. > >> > >> Not sure to understand what you mean by "extend a /64 from WAN to LAN in cases where DHCP-PD is not available". > >> (If a site only has a /64, there can be a LAN, but no prefix can be further delegated on this LAN, independently of code being available to support DHCP-PD.) > >> > >> > >>> I believe this brings us back to pure 464XLAT which is an architectur= e > >>> for double translation, not /64 cross-interface extensions and not a > >>> CPE router specification. > >> > >> In my recollection, NAT44s were introduced in the draft for LAN-supporting /64 sites. > >> Since then, we found that, with reserved IID ranges for CLATs, NAT44s are no longer needed for such sites. > >> > >> Then, could you clarify your intention: > >> Is it to exclude /64-sites from the 464XLAT scope? > >> - If YES, 464XLAT would IMHO miss an important part of its natural target. > >> - If NO, are you intending to keep NAT44s in the draft? > > > > Yes, we can define NAT44 on the LAN but we cannot define how to share > > a /64 from WAN to LAN. Thus, the draft can only cleanly state how to > > make a NAT44 LAN work with an IPv6-only WAN when DHCPv6 PD is not > > available. > > > > It's the state we find ourselves in. > > > >> . If YES, the 464XLAT BCP includes CLAT nodes that aren't completely stateless. This is contrary to the announced objective, and can't be justified, IMHO, as it an be avoided just with three CLAT IID subranges. (This reservation is to be made in a range already available for such reservations, and is to be registered by IANA as usual if needed for an IETF BCP). > >> > > > > It is stateless at the CLAT in the case of DHCPv6 PD where a dedicated > > /64 translation prefix exists. DHCP-PD is a SHOULD. > > > > In the unfortunate case, but common in 3GPP today, where DHCPv6 PD > > does not exist, the CLAT can do stateful NAT44 from the LAN so that > > all IPv4 client packets are translated to 1 IPv4 address, and that 1 > > IPv4 address is then translated to 1 IPv6 address which is owned and > > defended with DAD by the CLAT. > > > > Thus, in a 3GPP network, IPv4 tethering can be supported across an > > IPv6-only network using 464XLAT double translation and NAT44. IPv6 > > tethering may also be supported by some method, but it will not > > mentioned in the draft since the WG cannot come to an agreed approach > > and it may be outside the scope of 464XLAT. > > > > R=E9mi -- your solution is elegant and good. But, you must agree that, > > for reasons i don't understand, it is unpopular in the eyes of the WG. > > As one of the 464XLAT authors, i agreed to add it in previous version > > of the I-D, but to move forward we must now remove it, and refocus the > > scope of 464XLAT on 464 translation and not on managing LAN addresses. > > > > I would very much like to see your idea of reserved IID specified for > > general application here in v6ops or 6MAN. > > > > CB > > > >> > >>> Any technical issues with this approach? > >> > >> See above. > >> > >> Regards, > >> RD > >> > >> > >> --f46d04089017a392b304c980bf88 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


    On Sep 12, 2012 1:02 AM, "R=E9mi Despr=E9s" <despres.remi@laposte.net> wrote:
    >
    > Cameron,
    >
    > Thanks for the clarification.
    > Unless I misunderstand, your currently favored plan is that, concernin= g tethering in /64 sites, the draft:
    > - supports it ONLY for IPv4
    > - imposes NAT44s to do it (stateful CLAT nodes)
    >
    > Yet, with three currently unused IID ranges reserved for CLATs, the dr= aft could, for /64 sites:
    > - Avoid imposing NAT44s (=3D> completely stateless CLAT nodes)
    > - Apply to sites that already do IPv6 tethering (independently of how = they do it).
    >
    > I don't share the view that a rough consensus with this solution w= ould be impossible:
    > (a) The solution is AFAIK well understood by those who took the time t= o see how it works.
    > (b) Relevance of the solution has recently been supported by several c= ontributors (including yourself here below in your last comment, and by the= fact that, although you personally believe it is "unpopular in the WG= ", you qualify it with "for reasons i don't understand".= )
    > (c) A number of objections have indeed been expressed, but all have be= en proven to be unjustified: problems with cascaded CLATs (not applicable t= o /64 sites), problems with dual homing (precisely eliminated with reserved= IID ranges), uncertainty of IANA acceptance (answered by Ron in Vancouver)= .
    > (d) Incorporating it is particularly easy (see a proposal in www.i= etf.org/mail-archive/web/v6ops/current/msg14077.html), bringing a simpl= ification (no need for NAT44 sections), and an important scope extension (a= pplicability to /64 sites that have their way to do IPv6 tethering).
    >
    > Conclusions:
    > - I still hope the WG won't refuse progress for reasons that at le= ast neither you nor me can understand
    > - If the rough consensus reached would nevertheless be to refuse this = progress, it will be without me.
    >
    > Best regards,
    > RD
    >

    All that said, is the wg ok with accepting with Remi's solution?

    Silence means no support.

    CB

    >
    >
    > 2012-09-11 23:30, Cameron Byrne :
    >
    > > R=E9mi,
    > >
    > > On Sun, Sep 9, 2012 at 11:44 PM, R=E9mi Despr=E9s <despres.remi@laposte.net> wrote: > >>
    > >> Le 2012-09-07 =E0 21:36, Cameron Byrne a =E9crit :
    > >>
    > >>> Folks,
    > >>>
    > >>> I hope we can all see the scope issue related /64 sharing= across
    > >>> interfaces, it is simply not germane to the function of 4= 64XLAT and it
    > >>> should be removed.
    > >>>
    > >>> A much more workable solution, from IETF perspective, is = to simply say
    > >>> that 464XLAT supports the DHCP-PD scenario for a dedicate= d translation
    > >>> prefix (no challenges that i know of), and in the case of= no DHCP-PD
    > >>> available the CLAT does normal CLAT function for IPv4 wit= h NAT44 as
    > >>> described in section 8.3.2
    > >>>
    > >>> Meaning, there is an IPv6-only WAN and an IPv4 capable LA= N, no
    > >>> bridging or sharing of IPv6 across the CLAT is specified.=
    > >>>
    > >>> I would like to move forward with 464XLAT by simply stati= ng that
    > >>> DHCP-PD is the best choice for acquiring a dedicated /64 = to be used
    > >>> with stateless translation.
    > >>>
    > >>> http://tools.ietf.org/html/draft-ietf-v6ops-464xlat= -07#section-8.3.2
    > >>>
    > >>> For section 8.3.2 we can retain how IPv4 is treated with = NAT44, but
    > >>> simply remove how IPv6 is treated.
    > >>>
    > >>> <removed text>
    > >>>
    > >>> If the CLAT cannot perform ND Proxy [RFC4389] due to the = restriction
    > >>> =A0of the implementation, the CLAT may use a dedicated IA= NA assigned
    > >>> =A0EUI-64 ID for creating a translated IPv6 address to be= used in
    > >>> =A0stateless translation [RFC6145]. =A0This will allow th= e CLAT to avoid
    > >>> =A0possible IPv6 address duplication issues between an IP= v6 address for
    > >>> =A0stateless translation [RFC6145] in the CLAT and an IPv= 6 address
    > >>> =A0assigned to native IPv6 nodes behind the CLAT. =A0This= document
    > >>> =A0describes an example for this case in Example 2. of th= e Appendix A.
    > >>>
    > >>> =A0The CLAT MAY discover the Pref64::/n of the PLAT via s= ome method such
    > >>> =A0as TR-069, DNS APL RR [RFC3123] or
    > >>> =A0[I-D.ietf-behave-nat64-discovery-heuristic].
    > >>>
    > >>>
    > >>> </removed text>
    > >>>
    > >>>
    > >>> We can also remove the IANA section and remove reference = to ND proxy.
    > >>> If implementations choose to extend a /64 from WAN to LAN= in cases
    > >>> where DHCP-PD is not available, they may, but it is out o= f scope for
    > >>> *THIS* I-D. =A0Hopefully some of the discussion here can = feed further
    > >>> work in this area that appears to be needed.
    > >>
    > >> Not sure to understand what you mean by "extend a /64 fr= om WAN to LAN in cases where DHCP-PD is not available".
    > >> (If a site only has a /64, there can be a LAN, but no prefix = can be further delegated on this LAN, independently of code being available= to support DHCP-PD.)
    > >>
    > >>
    > >>> I believe this brings us back to pure 464XLAT which is an= architecture
    > >>> for double translation, not /64 cross-interface extension= s and not a
    > >>> CPE router specification.
    > >>
    > >> In my recollection, NAT44s were introduced in the draft for L= AN-supporting /64 sites.
    > >> Since then, we found that, with reserved IID ranges for CLATs= , NAT44s are no longer needed for such sites.
    > >>
    > >> Then, could you clarify your intention:
    > >> Is it to exclude /64-sites from the 464XLAT scope?
    > >> - If YES, 464XLAT would IMHO miss an important part of its na= tural target.
    > >> - If NO, are you intending to keep NAT44s in the draft?
    > >
    > > Yes, we can define NAT44 on the LAN but we cannot define how to s= hare
    > > a /64 from WAN to LAN. =A0Thus, the draft can only cleanly state = how to
    > > make a NAT44 LAN work with an IPv6-only WAN when DHCPv6 PD is not=
    > > available.
    > >
    > > It's the state we find ourselves in.
    > >
    > >> . If YES, the 464XLAT BCP includes CLAT nodes that aren't= completely stateless. This is contrary to the announced objective, and can= 't be justified, IMHO, as it an be avoided just with three CLAT IID sub= ranges. (This reservation is to be made in a range already available for su= ch reservations, and is to be registered by IANA as usual if needed for an = IETF BCP).
    > >>
    > >
    > > It is stateless at the CLAT in the case of DHCPv6 PD where a dedi= cated
    > > /64 translation prefix exists. DHCP-PD is a SHOULD.
    > >
    > > In the unfortunate case, but common in 3GPP today, where DHCPv6 P= D
    > > does not exist, the CLAT can do stateful NAT44 from the LAN so th= at
    > > all IPv4 client packets are translated to 1 IPv4 address, and tha= t 1
    > > IPv4 address is then translated to 1 IPv6 address which is owned = and
    > > defended with DAD by the CLAT.
    > >
    > > Thus, in a 3GPP network, IPv4 tethering can be supported across a= n
    > > IPv6-only network using 464XLAT double translation and NAT44. =A0= IPv6
    > > tethering may also be supported by some method, but it will not > > mentioned in the draft since the WG cannot come to an agreed appr= oach
    > > and it may be outside the scope of 464XLAT.
    > >
    > > R=E9mi -- your solution is elegant and good. =A0But, you must agr= ee that,
    > > for reasons i don't understand, it is unpopular in the eyes o= f the WG.
    > > As one of the 464XLAT authors, i agreed to add it in previous ver= sion
    > > of the I-D, but to move forward we must now remove it, and refocu= s the
    > > scope of 464XLAT on 464 translation and not on managing LAN addre= sses.
    > >
    > > I would very much like to see your idea of reserved IID specified= for
    > > general application here in v6ops or 6MAN.
    > >
    > > CB
    > >
    > >>
    > >>> Any technical issues with this approach?
    > >>
    > >> See above.
    > >>
    > >> Regards,
    > >> RD
    > >>
    > >>
    > >>

    --f46d04089017a392b304c980bf88-- From lorenzo@google.com Wed Sep 12 06:54:40 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 787BD21F85A4 for ; Wed, 12 Sep 2012 06:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.88 X-Spam-Level: X-Spam-Status: No, score=-102.88 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IEYSWZSGhUzb for ; Wed, 12 Sep 2012 06:54:39 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7A26A21F85AE for ; Wed, 12 Sep 2012 06:54:31 -0700 (PDT) Received: by ieak13 with SMTP id k13so3305274iea.31 for ; Wed, 12 Sep 2012 06:54:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=xSeGryaI2rHITNvYIz/QBm6Fo01gheaeATM0/j7tWoE=; b=BCF6IfP8QamDsDVtS6MqZtAWhu46jgTMcmtFqPZEYyi8+fpCNimjYAMz5cj+MQfHok vaZGzU15W4c8y70y/iwSUISy46iQ5VJHSvKfDPXhV4FNaaIBXilvVrE4pG49+vz1ul8w 5ZQUyNtw4OgKQY9pNbRhwYf1XT1LLUaBHeFVGeIqvU0VIi7uHqUn0otEiIMPOFkuYnvK NHalrWv8v10zWuwzqucus62uPAKVMbO9Kkb2RGRq+22pHvBkwTPh/D+gG6Ii/Dhcq3gE 0mPwG4+39ZUzWaOcxV5nhBIJOonpemwiYF2E1c9jupmwYZoN/znONXeBQdPFCxROQS5E mcwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=xSeGryaI2rHITNvYIz/QBm6Fo01gheaeATM0/j7tWoE=; b=kVDRRrzEGwph5YkitdO5ypU5TSrtTdPwPcjzQuzewZsk5IhJZePiYuHw0ShX5H+FfZ oO/WiUYU2z+8zbgjDnxCjFYQGxxcYn1c0SoURSoC6dTQaLpZHrgtK+WsocSQ4anwpRai psknZykVV2Icg3KVUI5QeXoXvr6nxxVpdHwtmnvhtrps4BEETXuPGUH8plKP5fTXk2ka fPrlLAhd6edYYURobAPf3xwPPiHNhonVAfuCyZEbxkBaGqaGPpjnEUuHeL7CaC3Q+7sT kwvbbrVeV5WEbbFkJlugeopKae9bYdUCDBGRr5cduVEfBFttFJuNYYOLFTDN+FKIj8hi 6tPA== Received: by 10.50.95.230 with SMTP id dn6mr21028575igb.16.1347458070982; Wed, 12 Sep 2012 06:54:30 -0700 (PDT) Received: by 10.50.95.230 with SMTP id dn6mr21028562igb.16.1347458070746; Wed, 12 Sep 2012 06:54:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.246.2 with HTTP; Wed, 12 Sep 2012 06:54:10 -0700 (PDT) In-Reply-To: References: From: Lorenzo Colitti Date: Wed, 12 Sep 2012 22:54:10 +0900 Message-ID: To: Cameron Byrne Content-Type: multipart/alternative; boundary=e89a8f23438ba8180004c98187f4 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmS7vzCF0tHjMBfdToixneFzf8JhNC7du7PRvwsZN2bNc4cvgiOWPXRg6CxJK2JITafkfBcORgapdtg/XwKEtfsggHtJo/2jtqNudovmY3K0ot4ca4tZAckAlbeg8SFpQXlJ4hsHoUVLmANDg3z7EtznjeDc9xEx/7QEwh9c+uBFf9v8DO1uagZMpgKPAQLUnkLpDo2 Cc: IPv6 Ops WG Subject: Re: [v6ops] 464XLAT removing IPv6 LAN scope X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 13:54:40 -0000 --e89a8f23438ba8180004c98187f4 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Sep 12, 2012 at 9:58 PM, Cameron Byrne wrote: > All that said, is the wg ok with accepting with Remi's solution? > > Silence means no support. > If we can make it work, I think it has advantages. But it requires that the text be written and that we as a WG think the issues through, try to figure out if there are any corner cases, etc. DAD is simple and we know how it works, but we haven't devoted much thought to Remi's solution because it hasn't even been written in the draft yet. Realistically, what that means is that the draft will be delayed. What are the alternatives? 1. Stay silent on sharing one /64 and let implementations do their thing. 2. Decide that for now it's more practical to share a /64 with DAD. 3. Remi's "reserve 3 IID ranges" proposal. Anything else? --e89a8f23438ba8180004c98187f4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Sep 12, 2012 at 9:58 PM, Cameron Byrne <cb.list6@gmail.com>= ; wrote:

    All that said, is the wg ok with accepting with Remi&#= 39;s solution?

    Silence means no support.

    If we can make it work, I= think it has advantages. But it requires that the text be written and that= we as a WG think the issues through, try to figure out if there are any co= rner cases, etc. =A0DAD is simple and we know how it works, but we haven= 9;t devoted much thought to Remi's solution because it hasn't even = been written in the draft yet.

    Realistically, what that means is that the draft will b= e delayed.

    What are the alternatives?
    1. Stay silent on sharing one /64 and let implementations do t= heir thing.
    2. Decide that for now it's more practical to share a /64 with DAD= .
    3. Remi's "reserve 3 IID ranges" proposal.
    <= div>
    Anything else?
    --e89a8f23438ba8180004c98187f4-- From cb.list6@gmail.com Wed Sep 12 07:00:57 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7AF821F85A4 for ; Wed, 12 Sep 2012 07:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.229 X-Spam-Level: X-Spam-Status: No, score=-3.229 tagged_above=-999 required=5 tests=[AWL=0.369, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IXS+81TpaIaJ for ; Wed, 12 Sep 2012 07:00:57 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id D171421F8549 for ; Wed, 12 Sep 2012 07:00:56 -0700 (PDT) Received: by lbky2 with SMTP id y2so1282397lbk.31 for ; Wed, 12 Sep 2012 07:00:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xpmbOJKMsnAFtjn52EZJFXIEL7rzEiH96ji1GZVWxmQ=; b=mI4wou8GkbhSUL1WOMzt87tSIXfNRA9qGJhmqCzFbUvB5UE+4ONHerbO2T7t09OYZO sNwT8i755KwxroDMC/EMrPJN4Mg5NzeHoBebhKD5L0VL+h3gGZkyJMjhJqCBXa9LLEGh RoDOnSEkT85UiM6/ipWUEQMfUmKxk/vfjVow1d6JM/FQMWCQ3taIyCrsdPSELC9Ekj6J AiFxQVqzRGydsbbS6Oq6WXSR/HVg7+Qu9xt0b99wA4JqJ1T+GCj84hd8wGGxDZ3SRTUQ iZDoQq1uoGYpa9liaRqu/dXh7cNeBvf7sZi29aaERSuEyPWzkMN+LN/8Ml1EHmSuILwV nIQg== MIME-Version: 1.0 Received: by 10.152.103.146 with SMTP id fw18mr19075950lab.30.1347458455800; Wed, 12 Sep 2012 07:00:55 -0700 (PDT) Received: by 10.112.49.66 with HTTP; Wed, 12 Sep 2012 07:00:55 -0700 (PDT) Received: by 10.112.49.66 with HTTP; Wed, 12 Sep 2012 07:00:55 -0700 (PDT) In-Reply-To: References: Date: Wed, 12 Sep 2012 07:00:55 -0700 Message-ID: From: Cameron Byrne To: Lorenzo Colitti Content-Type: multipart/alternative; boundary=f46d040714cf9b8aa804c9819e07 Cc: IPv6 Ops WG Subject: Re: [v6ops] 464XLAT removing IPv6 LAN scope X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 14:00:58 -0000 --f46d040714cf9b8aa804c9819e07 Content-Type: text/plain; charset=ISO-8859-1 On Sep 12, 2012 6:54 AM, "Lorenzo Colitti" wrote: > > On Wed, Sep 12, 2012 at 9:58 PM, Cameron Byrne wrote: >> >> All that said, is the wg ok with accepting with Remi's solution? >> >> Silence means no support. > > If we can make it work, I think it has advantages. But it requires that the text be written and that we as a WG think the issues through, try to figure out if there are any corner cases, etc. DAD is simple and we know how it works, but we haven't devoted much thought to Remi's solution because it hasn't even been written in the draft yet. > > Realistically, what that means is that the draft will be delayed. > > What are the alternatives? > > 1. Stay silent on sharing one /64 and let implementations do their thing. > 2. Decide that for now it's more practical to share a /64 with DAD. > 3. Remi's "reserve 3 IID ranges" proposal. > > Anything else? Yes. Don't delay or bend the scope of 464xlat with Remi's good idea. Instead, offer Remi's method as a generic solution for /64 sharing with a broader scope and applicability than 464xlat. I would be happy to support or work on that worthy effort. CB I --f46d040714cf9b8aa804c9819e07 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


    On Sep 12, 2012 6:54 AM, "Lorenzo Colitti" <lorenzo@google.com> wrote:
    >
    > On Wed, Sep 12, 2012 at 9:58 PM, Cameron Byrne <cb.list6@gmail.com> wrote:
    >>
    >> All that said, is the wg ok with accepting with Remi's solutio= n?
    >>
    >> Silence means no support.
    >
    > If we can make it work, I think it has advantages. But it requires tha= t the text be written and that we as a WG think the issues through, try to = figure out if there are any corner cases, etc. =A0DAD is simple and we know= how it works, but we haven't devoted much thought to Remi's soluti= on because it hasn't even been written in the draft yet.
    >
    > Realistically, what that means is that the draft will be delayed.
    >
    > What are the alternatives?
    >
    > 1. Stay silent on sharing one /64 and let implementations do their thi= ng.
    > 2. Decide that for now it's more practical to share a /64 with DAD= .
    > 3. Remi's "reserve 3 IID ranges" proposal.
    >
    > Anything else?

    Yes.=A0 Don't delay or bend the scope of 464xlat with Remi's goo= d idea. Instead, offer Remi's method as a generic solution for /64 shar= ing with a broader scope and applicability than 464xlat. I would be happy t= o support or work on that worthy effort.

    CB

    I

    --f46d040714cf9b8aa804c9819e07-- From cb.list6@gmail.com Wed Sep 12 07:06:54 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6376721F863B for ; Wed, 12 Sep 2012 07:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.255 X-Spam-Level: X-Spam-Status: No, score=-3.255 tagged_above=-999 required=5 tests=[AWL=0.343, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VDg2WENMAbvy for ; Wed, 12 Sep 2012 07:06:53 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id A833221F861F for ; Wed, 12 Sep 2012 07:06:52 -0700 (PDT) Received: by lahm15 with SMTP id m15so1231608lah.31 for ; Wed, 12 Sep 2012 07:06:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SZHVi5VsLToKjoQjOfydhkbXsOT2jg8vS5oIns5qCy0=; b=IBPk1jnq6wDvzMBVtfJgLE6Q6YrCotYuPO83LjoYhz+pJ897+xFx9wHcNhRQoLbWO3 Zs1A22SXG8Abuo6/aiJhWcH15oI7icZK9WGwzsbG4BP2MTftYSYvzCQxl/gWiM7erC7A KP3NnKaRUCP8+eJNnqMHDlgAYZH3ZyWcIIQMug3FeMdATcCU+60gW+hwuyq9RU/VF6DN rAh9vdCVF+SruutfeexHgBhGV+7IcfwMCoIZCc7h/xCGoUYlIopn6VwY0pv1OmpVpP5+ YTNAyy9GNTTWfl50Zfd2ITL97pBD8UQzE279v1EuWKixAuj4cUZfiuto6tqcxJAVi9ib HPyQ== MIME-Version: 1.0 Received: by 10.152.103.146 with SMTP id fw18mr19097744lab.30.1347458808382; Wed, 12 Sep 2012 07:06:48 -0700 (PDT) Received: by 10.112.49.66 with HTTP; Wed, 12 Sep 2012 07:06:47 -0700 (PDT) Received: by 10.112.49.66 with HTTP; Wed, 12 Sep 2012 07:06:47 -0700 (PDT) In-Reply-To: References: Date: Wed, 12 Sep 2012 07:06:47 -0700 Message-ID: From: Cameron Byrne To: Lorenzo Colitti Content-Type: multipart/alternative; boundary=f46d040714cf9f856504c981b36b Cc: IPv6 Ops WG Subject: Re: [v6ops] 464XLAT removing IPv6 LAN scope X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 14:06:54 -0000 --f46d040714cf9f856504c981b36b Content-Type: text/plain; charset=ISO-8859-1 On Sep 12, 2012 6:54 AM, "Lorenzo Colitti" wrote: > > On Wed, Sep 12, 2012 at 9:58 PM, Cameron Byrne wrote: >> >> All that said, is the wg ok with accepting with Remi's solution? >> >> Silence means no support. > > If we can make it work, I think it has advantages. But it requires that the text be written and that we as a WG think the issues through, try to figure out if there are any corner cases, etc. DAD is simple and we know how it works, but we haven't devoted much thought to Remi's solution because it hasn't even been written in the draft yet. > > Realistically, what that means is that the draft will be delayed. > > What are the alternatives? > > 1. Stay silent on sharing one /64 and let implementations do their thing. Yes, stay silent in 464xlat draft. A new dedicated draft would be strongly supported by me. Implementers will always do their thing. One good example is Dan's code that was submitted to AOSP. It works perfectly for sharing the /64, breaks nothing, and is super simple. That code benefits from 464xlat staying silent. CB > 2. Decide that for now it's more practical to share a /64 with DAD. > 3. Remi's "reserve 3 IID ranges" proposal. > > Anything else? --f46d040714cf9f856504c981b36b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


    On Sep 12, 2012 6:54 AM, "Lorenzo Colitti" <lorenzo@google.com> wrote:
    >
    > On Wed, Sep 12, 2012 at 9:58 PM, Cameron Byrne <cb.list6@gmail.com> wrote:
    >>
    >> All that said, is the wg ok with accepting with Remi's solutio= n?
    >>
    >> Silence means no support.
    >
    > If we can make it work, I think it has advantages. But it requires tha= t the text be written and that we as a WG think the issues through, try to = figure out if there are any corner cases, etc. =A0DAD is simple and we know= how it works, but we haven't devoted much thought to Remi's soluti= on because it hasn't even been written in the draft yet.
    >
    > Realistically, what that means is that the draft will be delayed.
    >
    > What are the alternatives?
    >
    > 1. Stay silent on sharing one /64 and let implementations do their thi= ng.

    Yes, stay silent in 464xlat draft. A new dedicated draft would be strong= ly supported by me.

    Implementers will always do their thing. One good example is Dan's c= ode that was submitted to AOSP. It works perfectly for sharing the /64, bre= aks nothing, and is super simple. That code benefits from 464xlat staying s= ilent.

    CB

    > 2. Decide that for now it's more practical to share a /64 with = DAD.
    > 3. Remi's "reserve 3 IID ranges" proposal.
    >
    > Anything else?

    --f46d040714cf9f856504c981b36b-- From despres.remi@laposte.net Wed Sep 12 07:08:28 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BDE421F8621 for ; Wed, 12 Sep 2012 07:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.534 X-Spam-Level: X-Spam-Status: No, score=-1.534 tagged_above=-999 required=5 tests=[AWL=0.414, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hMer0Gas01VS for ; Wed, 12 Sep 2012 07:08:28 -0700 (PDT) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.84]) by ietfa.amsl.com (Postfix) with ESMTP id BFA4C21F8604 for ; Wed, 12 Sep 2012 07:08:27 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2416.sfr.fr (SMTP Server) with ESMTP id 1FD107000190; Wed, 12 Sep 2012 16:08:26 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2416.sfr.fr (SMTP Server) with ESMTP id B52887000133; Wed, 12 Sep 2012 16:08:25 +0200 (CEST) X-SFR-UUID: 20120912140825742.B52887000133@msfrf2416.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-66--215486893 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 12 Sep 2012 16:08:20 +0200 Message-Id: <6BD4EF08-99CE-4485-80FA-23A77564DDDB@laposte.net> References: To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) Cc: IPv6 Ops WG Subject: Re: [v6ops] 464XLAT removing IPv6 LAN scope X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 14:08:28 -0000 --Apple-Mail-66--215486893 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 2012-09-12 15:54, Lorenzo Colitti: > On Wed, Sep 12, 2012 at 9:58 PM, Cameron Byrne = wrote: > All that said, is the wg ok with accepting with Remi's solution? >=20 > Silence means no support. >=20 > If we can make it work, I think it has advantages. But it requires = that the text be written and that we as a WG think the issues through, = try to figure out if there are any corner cases, etc. DAD is simple and = we know how it works, but we haven't devoted much thought to Remi's = solution because it hasn't even been written in the draft yet. Note that, as reminded to Cameron in the mast mail I sent, a text of = what the draft could become remains available in = www.ietf.org/mail-archive/web/v6ops/current/msg14077.html. RD > Realistically, what that means is that the draft will be delayed. >=20 > What are the alternatives? >=20 > 1. Stay silent on sharing one /64 and let implementations do their = thing. > 2. Decide that for now it's more practical to share a /64 with DAD. > 3. Remi's "reserve 3 IID ranges" proposal. >=20 > Anything else? --Apple-Mail-66--215486893 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
    2012-09-12 15:54, Lorenzo Colitti:

    On Wed, Sep 12, 2012 at 9:58 PM, Cameron Byrne <cb.list6@gmail.com> wrote:

    All that said, is the wg ok with accepting with Remi's solution?

    Silence means no support.

    If we can make it work, I think it has advantages. But it requires that the text be written and that we as a WG think the issues through, try to figure out if there are any corner cases, etc.  DAD is simple and we know how it works, but we haven't devoted much thought to Remi's solution because it hasn't even been written in the draft yet.

    Note that, as reminded to Cameron in the mast mail I sent, a text of what the draft could become remains available in www.ietf.org/mail-archive/web/v6ops/current/msg14077.html.

    RD


    Realistically, what that means is that the draft will be delayed.

    What are the alternatives?

    1. Stay silent on sharing one /64 and let implementations do their thing.
    2. Decide that for now it's more practical to share a /64 with DAD.
    3. Remi's "reserve 3 IID ranges" proposal.

    Anything else?

    --Apple-Mail-66--215486893-- From phdgang@gmail.com Wed Sep 12 07:32:36 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B0E421F84EF for ; Wed, 12 Sep 2012 07:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.174 X-Spam-Level: X-Spam-Status: No, score=-3.174 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OrQwls1pvaKe for ; Wed, 12 Sep 2012 07:32:35 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8652521F8497 for ; Wed, 12 Sep 2012 07:32:35 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so2364691vcb.31 for ; Wed, 12 Sep 2012 07:32:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=NvJsXg9IIyrTrn4lm+rj+dQHevxzgKs23heHoSE43sM=; b=VI88VdP1b7DLmDDGTIu22bADwxiE1+jIljSS1v8zcfar0FtfbaeRbYg6nI+lcgXzGT c5tJE7aoVWv2vveVCQXkXC2kPNYa/yif9Ij9WdTxwqwQSYTd2qAprNyXVdBFBz45S2Fa CdUy5lTtjKomDce6RiO9RAoJc00ZI5xjgmKHHiqrkVfyhnlKA5UGFUU9hhkJkj0PFBko ZVmVE4jVlzUBbSrp3/iL3qDs4i+FUNdRH1ksE4VA4fg19ruZNMJgr1avvpEa1cesC9zr j8rPiN2BEzlWwAE72m9tVbFoY/4qvAKBhGtJBsE4bM8uBdYT7MgGG3s7KlZnrUFnxr4f WS8A== MIME-Version: 1.0 Received: by 10.52.20.138 with SMTP id n10mr23151270vde.129.1347460354898; Wed, 12 Sep 2012 07:32:34 -0700 (PDT) Received: by 10.58.114.231 with HTTP; Wed, 12 Sep 2012 07:32:34 -0700 (PDT) In-Reply-To: References: Date: Wed, 12 Sep 2012 22:32:34 +0800 Message-ID: From: GangChen To: Cameron Byrne Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Ops WG Subject: Re: [v6ops] 464XLAT removing IPv6 LAN scope X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 14:32:36 -0000 2012/9/12, Cameron Byrne : > On Sep 12, 2012 1:02 AM, "R=E9mi Despr=E9s" wr= ote: >> >> Cameron, >> >> Thanks for the clarification. >> Unless I misunderstand, your currently favored plan is that, concerning > tethering in /64 sites, the draft: >> - supports it ONLY for IPv4 >> - imposes NAT44s to do it (stateful CLAT nodes) >> >> Yet, with three currently unused IID ranges reserved for CLATs, the draf= t > could, for /64 sites: >> - Avoid imposing NAT44s (=3D> completely stateless CLAT nodes) >> - Apply to sites that already do IPv6 tethering (independently of how > they do it). >> >> I don't share the view that a rough consensus with this solution would b= e > impossible: >> (a) The solution is AFAIK well understood by those who took the time to > see how it works. >> (b) Relevance of the solution has recently been supported by several > contributors (including yourself here below in your last comment, and by > the fact that, although you personally believe it is "unpopular in the WG= ", > you qualify it with "for reasons i don't understand".) >> (c) A number of objections have indeed been expressed, but all have been > proven to be unjustified: problems with cascaded CLATs (not applicable to > /64 sites), problems with dual homing (precisely eliminated with reserved > IID ranges), uncertainty of IANA acceptance (answered by Ron in Vancouver= ). >> (d) Incorporating it is particularly easy (see a proposal in > www.ietf.org/mail-archive/web/v6ops/current/msg14077.html), bringing a > simplification (no need for NAT44 sections), and an important scope > extension (applicability to /64 sites that have their way to do IPv6 > tethering). >> >> Conclusions: >> - I still hope the WG won't refuse progress for reasons that at least > neither you nor me can understand >> - If the rough consensus reached would nevertheless be to refuse this > progress, it will be without me. >> >> Best regards, >> RD >> > > All that said, is the wg ok with accepting with Remi's solution? > > Silence means no support. > Just want to share what we are doing for 464xlat. We are quite following the draft, including the idea of "reserved IID" Best Regards Gang > CB > >> >> >> 2012-09-11 23:30, Cameron Byrne : >> >> > R=E9mi, >> > >> > On Sun, Sep 9, 2012 at 11:44 PM, R=E9mi Despr=E9s >> > > wrote: >> >> >> >> Le 2012-09-07 =E0 21:36, Cameron Byrne a =E9crit : >> >> >> >>> Folks, >> >>> >> >>> I hope we can all see the scope issue related /64 sharing across >> >>> interfaces, it is simply not germane to the function of 464XLAT and >> >>> it >> >>> should be removed. >> >>> >> >>> A much more workable solution, from IETF perspective, is to simply >> >>> say >> >>> that 464XLAT supports the DHCP-PD scenario for a dedicated >> >>> translation >> >>> prefix (no challenges that i know of), and in the case of no DHCP-PD >> >>> available the CLAT does normal CLAT function for IPv4 with NAT44 as >> >>> described in section 8.3.2 >> >>> >> >>> Meaning, there is an IPv6-only WAN and an IPv4 capable LAN, no >> >>> bridging or sharing of IPv6 across the CLAT is specified. >> >>> >> >>> I would like to move forward with 464XLAT by simply stating that >> >>> DHCP-PD is the best choice for acquiring a dedicated /64 to be used >> >>> with stateless translation. >> >>> >> >>> http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-07#section-8.3.2 >> >>> >> >>> For section 8.3.2 we can retain how IPv4 is treated with NAT44, but >> >>> simply remove how IPv6 is treated. >> >>> >> >>> >> >>> >> >>> If the CLAT cannot perform ND Proxy [RFC4389] due to the restriction >> >>> of the implementation, the CLAT may use a dedicated IANA assigned >> >>> EUI-64 ID for creating a translated IPv6 address to be used in >> >>> stateless translation [RFC6145]. This will allow the CLAT to avoid >> >>> possible IPv6 address duplication issues between an IPv6 address fo= r >> >>> stateless translation [RFC6145] in the CLAT and an IPv6 address >> >>> assigned to native IPv6 nodes behind the CLAT. This document >> >>> describes an example for this case in Example 2. of the Appendix A. >> >>> >> >>> The CLAT MAY discover the Pref64::/n of the PLAT via some method >> >>> such >> >>> as TR-069, DNS APL RR [RFC3123] or >> >>> [I-D.ietf-behave-nat64-discovery-heuristic]. >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> We can also remove the IANA section and remove reference to ND proxy= . >> >>> If implementations choose to extend a /64 from WAN to LAN in cases >> >>> where DHCP-PD is not available, they may, but it is out of scope for >> >>> *THIS* I-D. Hopefully some of the discussion here can feed further >> >>> work in this area that appears to be needed. >> >> >> >> Not sure to understand what you mean by "extend a /64 from WAN to LAN > in cases where DHCP-PD is not available". >> >> (If a site only has a /64, there can be a LAN, but no prefix can be > further delegated on this LAN, independently of code being available to > support DHCP-PD.) >> >> >> >> >> >>> I believe this brings us back to pure 464XLAT which is an >> >>> architecture >> >>> for double translation, not /64 cross-interface extensions and not a >> >>> CPE router specification. >> >> >> >> In my recollection, NAT44s were introduced in the draft for > LAN-supporting /64 sites. >> >> Since then, we found that, with reserved IID ranges for CLATs, NAT44s > are no longer needed for such sites. >> >> >> >> Then, could you clarify your intention: >> >> Is it to exclude /64-sites from the 464XLAT scope? >> >> - If YES, 464XLAT would IMHO miss an important part of its natural > target. >> >> - If NO, are you intending to keep NAT44s in the draft? >> > >> > Yes, we can define NAT44 on the LAN but we cannot define how to share >> > a /64 from WAN to LAN. Thus, the draft can only cleanly state how to >> > make a NAT44 LAN work with an IPv6-only WAN when DHCPv6 PD is not >> > available. >> > >> > It's the state we find ourselves in. >> > >> >> . If YES, the 464XLAT BCP includes CLAT nodes that aren't completely > stateless. This is contrary to the announced objective, and can't be > justified, IMHO, as it an be avoided just with three CLAT IID subranges. > (This reservation is to be made in a range already available for such > reservations, and is to be registered by IANA as usual if needed for an > IETF BCP). >> >> >> > >> > It is stateless at the CLAT in the case of DHCPv6 PD where a dedicated >> > /64 translation prefix exists. DHCP-PD is a SHOULD. >> > >> > In the unfortunate case, but common in 3GPP today, where DHCPv6 PD >> > does not exist, the CLAT can do stateful NAT44 from the LAN so that >> > all IPv4 client packets are translated to 1 IPv4 address, and that 1 >> > IPv4 address is then translated to 1 IPv6 address which is owned and >> > defended with DAD by the CLAT. >> > >> > Thus, in a 3GPP network, IPv4 tethering can be supported across an >> > IPv6-only network using 464XLAT double translation and NAT44. IPv6 >> > tethering may also be supported by some method, but it will not >> > mentioned in the draft since the WG cannot come to an agreed approach >> > and it may be outside the scope of 464XLAT. >> > >> > R=E9mi -- your solution is elegant and good. But, you must agree that= , >> > for reasons i don't understand, it is unpopular in the eyes of the WG. >> > As one of the 464XLAT authors, i agreed to add it in previous version >> > of the I-D, but to move forward we must now remove it, and refocus the >> > scope of 464XLAT on 464 translation and not on managing LAN addresses. >> > >> > I would very much like to see your idea of reserved IID specified for >> > general application here in v6ops or 6MAN. >> > >> > CB >> > >> >> >> >>> Any technical issues with this approach? >> >> >> >> See above. >> >> >> >> Regards, >> >> RD >> >> >> >> >> >> > From dan-v6ops@drown.org Wed Sep 12 07:53:54 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9B0A21F8582 for ; Wed, 12 Sep 2012 07:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.741 X-Spam-Level: X-Spam-Status: No, score=-0.741 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2E-bMJ7TEGzR for ; Wed, 12 Sep 2012 07:53:54 -0700 (PDT) Received: from vps3.drown.org (vps3.drown.org [IPv6:2600:3c00::f03c:91ff:fedf:5654]) by ietfa.amsl.com (Postfix) with ESMTP id 8386321F854C for ; Wed, 12 Sep 2012 07:53:54 -0700 (PDT) Received: by vps3.drown.org (Postfix, from userid 48) id A211DC0BD; Wed, 12 Sep 2012 10:53:53 -0400 (EDT) Received: from 2001:470:b88f:c8f6:224:1dff:fe16:eb3b ([2001:470:b88f:c8f6:224:1dff:fe16:eb3b]) by mail.drown.org (Horde Framework) with HTTP; Wed, 12 Sep 2012 09:53:53 -0500 Message-ID: <20120912095353.16694hpff0oaxbeo@mail.drown.org> Date: Wed, 12 Sep 2012 09:53:53 -0500 From: Dan Drown To: v6ops@ietf.org References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.9) Subject: Re: [v6ops] 464XLAT removing IPv6 LAN scope X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 14:53:55 -0000 Quoting Cameron Byrne : > All that said, is the wg ok with accepting with Remi's solution? > > Silence means no support. From the android implementation standpoint: 1. IPv6 tethering - having a reserved IID or IID range means not having to worry about having to DAD/answer NDs for the CLAT address on the "tethered" (downstream) interface. 2. NAT44 + 464XLAT vs 464XLAT - having a reserved IID range would mean not needing NAT44 on top of 464xlat These are both nice to have but are not required to get 464xlat working on android. From despres.remi@laposte.net Wed Sep 12 08:05:25 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F09521F8622 for ; Wed, 12 Sep 2012 08:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.543 X-Spam-Level: X-Spam-Status: No, score=-1.543 tagged_above=-999 required=5 tests=[AWL=0.405, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rgq3JV6e5Kgp for ; Wed, 12 Sep 2012 08:05:24 -0700 (PDT) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.84]) by ietfa.amsl.com (Postfix) with ESMTP id 971EB21F860D for ; Wed, 12 Sep 2012 08:05:17 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2416.sfr.fr (SMTP Server) with ESMTP id 50A2D7000071; Wed, 12 Sep 2012 17:05:17 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2416.sfr.fr (SMTP Server) with ESMTP id E36837000086; Wed, 12 Sep 2012 17:05:16 +0200 (CEST) X-SFR-UUID: 20120912150516931.E36837000086@msfrf2416.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-67--212074193 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 12 Sep 2012 17:05:13 +0200 Message-Id: <82F3BACA-A8D8-48CE-96A6-4E573257F668@laposte.net> References: To: Cameron Byrne X-Mailer: Apple Mail (2.1084) Cc: IPv6 Ops WG Subject: Re: [v6ops] 464XLAT removing IPv6 LAN scope X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 15:05:25 -0000 --Apple-Mail-67--212074193 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-09-12 =E0 16:00, Cameron Byrne a =E9crit : >=20 > On Sep 12, 2012 6:54 AM, "Lorenzo Colitti" wrote: > > > > On Wed, Sep 12, 2012 at 9:58 PM, Cameron Byrne = wrote: > >> > >> All that said, is the wg ok with accepting with Remi's solution? > >> > >> Silence means no support. > > > > If we can make it work, I think it has advantages. But it requires = that the text be written and that we as a WG think the issues through, = try to figure out if there are any corner cases, etc. DAD is simple and = we know how it works, but we haven't devoted much thought to Remi's = solution because it hasn't even been written in the draft yet. > > > > Realistically, what that means is that the draft will be delayed. > > > > What are the alternatives? > > > > 1. Stay silent on sharing one /64 and let implementations do their = thing. > > 2. Decide that for now it's more practical to share a /64 with DAD. > > 3. Remi's "reserve 3 IID ranges" proposal. > > > > Anything else? >=20 > Yes. Don't delay or bend the scope of 464xlat with Remi's good idea. = Instead, offer Remi's method as a generic solution for /64 sharing with = a broader scope and applicability than 464xlat. I would be happy to = support or work on that worthy effort. >=20 If this becomes the conclusion (and it seems now clear it will be), I = will see it as a missed opportunity for timely progress, caused by = disproportionate FUD, but that's all. Progress on this subject remains indeed possible in a second step, but = it will have to be in your hands: having started working on something = else in the field of operating systems, I will terminate active work in = IETF (passionate but uncompensated) as soon as reasonably feasible.=20 Congratulation to you and co-authors for what you achieved. Good luck, and best regards, RD --Apple-Mail-67--212074193 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1


    On Sep 12, 2012 6:54 AM, "Lorenzo Colitti" <lorenzo@google.com> wrote:
    >
    > On Wed, Sep 12, 2012 at 9:58 PM, Cameron Byrne <cb.list6@gmail.com> wrote:
    >>
    >> All that said, is the wg ok with accepting with Remi's = solution?
    >>
    >> Silence means no support.
    >
    > If we can make it work, I think it has advantages. But it requires = that the text be written and that we as a WG think the issues through, = try to figure out if there are any corner cases, etc.  DAD is = simple and we know how it works, but we haven't devoted much thought to = Remi's solution because it hasn't even been written in the draft = yet.
    >
    > Realistically, what that means is that the draft will be = delayed.
    >
    > What are the alternatives?
    >
    > 1. Stay silent on sharing one /64 and let implementations do their = thing.
    > 2. Decide that for now it's more practical to share a /64 with = DAD.
    > 3. Remi's "reserve 3 IID ranges" proposal.
    >
    > Anything else?

    Yes.  Don't delay or bend the scope of = 464xlat with Remi's good idea. Instead, offer Remi's method as a generic = solution for /64 sharing with a broader scope and applicability than = 464xlat. I would be happy to support or work on that worthy = effort.

    If this becomes the conclusion (and it = seems now clear it will be), I will see it as a missed opportunity = for timely progress, caused by disproportionate FUD, but that's = all.

    Progress on this subject remains = indeed possible in a second step, but it will have to be in your = hands: having started working on something else in the field = of operating systems, I will terminate active work in IETF = (passionate but uncompensated) as soon as reasonably = feasible. 

    Congratulation to you and = co-authors for what you achieved.
    Good luck, and best = regards,

    RD




    = --Apple-Mail-67--212074193-- From iesg-secretary@ietf.org Wed Sep 12 08:29:27 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6C4021F863B; Wed, 12 Sep 2012 08:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtywbEXfuCjU; Wed, 12 Sep 2012 08:29:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2259021F863F; Wed, 12 Sep 2012 08:29:27 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120912152927.28027.82461.idtracker@ietfa.amsl.com> Date: Wed, 12 Sep 2012 08:29:27 -0700 Cc: v6ops mailing list , v6ops chair , RFC Editor Subject: [v6ops] Document Action: 'Wireline Incremental IPv6' to Informational RFC (draft-ietf-v6ops-wireline-incremental-ipv6-06.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 15:29:28 -0000 The IESG has approved the following document: - 'Wireline Incremental IPv6' (draft-ietf-v6ops-wireline-incremental-ipv6-06.txt) as Informational RFC This document is the product of the IPv6 Operations Working Group. The IESG contact persons are Ronald Bonica and Benoit Claise. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-v6ops-wireline-incremental-ipv6/ Technical Summary Operators worldwide are in various stages of preparing for, or deploying IPv6 into their networks. The operators often face difficult challenges related to both IPv6 introduction along with those related to IPv4 run out. Operators will need to meet the simultaneous needs of IPv6 connectivity and continue support for IPv4 connectivity for legacy devices with a stagnant supply of IPv4 addresses. The IPv6 transition will take most networks from an IPv4- only environment to an IPv6 dominant environment with long transition period varying by operator. This document helps provide a framework for wireline providers who are faced with the challenges of introducing IPv6 along with meeting the legacy needs of IPv4 connectivity utilizing well defined and commercially available IPv6 transition technologies. Working Group Summary The working group process was pretty straightforward. To the shepherd's knowledge, while every operator has not taken (or considered) taking every step laid out, there is no dissent regarding the approach. What the framework lays out is what steps make sense at the various decision points and how they should be thought through. Document Quality The framework is well written and has stood up under review. Personnel The Document Shepherd is Fred Baker. The Responsible AD is Ron Bonica. From v6ops@globis.net Wed Sep 12 09:24:44 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5647321F8600 for ; Wed, 12 Sep 2012 09:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lnb57Ufszc5h for ; Wed, 12 Sep 2012 09:24:43 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED2121F85F3 for ; Wed, 12 Sep 2012 09:24:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 641C28700EE; Wed, 12 Sep 2012 18:24:27 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MmrNq13gxWQ1; Wed, 12 Sep 2012 18:23:58 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 3651E8700AE; Wed, 12 Sep 2012 18:23:58 +0200 (CEST) Message-ID: <5050B718.5050003@globis.net> Date: Wed, 12 Sep 2012 18:23:52 +0200 From: Ray Hunter User-Agent: Postbox 3.0.4 (Macintosh/20120616) MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= References: <6BD4EF08-99CE-4485-80FA-23A77564DDDB@laposte.net> In-Reply-To: <6BD4EF08-99CE-4485-80FA-23A77564DDDB@laposte.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: IPv6 Ops WG Subject: Re: [v6ops] 464XLAT removing IPv6 LAN scope X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 16:24:44 -0000 The idea certainly has merit, but I'm not yet fully convinced about combining this with the 464XLAT draft. The draft started off reserving one single IANA IID for IPv4 to IPv6 translation. Now the reservation has expanded to cover the RFC1918 space. If the IPv4 range used on networks behind the CLAT is limited to RFC1918 space, and it is indeed kept strictly local, why do we need to reserve the complete 3 RFC1918 ranges for use as IID's (to be used to create unique IPv6 addresses when the IPv6 prefix assigned to the CLAT)? Why can't everyone just use the identical set of 192.168/16 IPv4 prefixes behind their own CLAT? On the other extreme: if 464XLAT were to allow inbound PLAT to CLAT IPv4 - IPv4 sessions (and not just support a hub and spoke model for outbound only sessions via the PLAT) why not reserve the entire /32 IPv4 address space as IANA IID's for use in generating unique IPv6 addresses for IPv4 nodes located behind a CLAT? An equivalent approach has certainly been applied successfully in other transition mechanisms. IHMO I think a lack of a clear answer to these extreme cases demonstrates it's simply too early to reserve IANA IID space right now. regards, RayH Rémi Després wrote: > > 2012-09-12 15:54, Lorenzo Colitti: > >> On Wed, Sep 12, 2012 at 9:58 PM, Cameron Byrne > > wrote: >> >> All that said, is the wg ok with accepting with Remi's solution? >> >> Silence means no support. >> >> If we can make it work, I think it has advantages. But it requires >> that the text be written and that we as a WG think the issues >> through, try to figure out if there are any corner cases, etc. DAD >> is simple and we know how it works, but we haven't devoted much >> thought to Remi's solution because it hasn't even been written in the >> draft yet. > > Note that, as reminded to Cameron in the mast mail I sent, a text of > what the draft could become remains available in > www.ietf.org/mail-archive/web/v6ops/current/msg14077.html > . > > RD > > >> Realistically, what that means is that the draft will be delayed. >> >> What are the alternatives? >> >> 1. Stay silent on sharing one /64 and let implementations do their thing. >> 2. Decide that for now it's more practical to share a /64 with DAD. >> 3. Remi's "reserve 3 IID ranges" proposal. >> >> Anything else? > From despres.remi@laposte.net Wed Sep 12 10:00:26 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 490C521F85B8 for ; Wed, 12 Sep 2012 10:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[AWL=0.398, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5krOgixIfu2A for ; Wed, 12 Sep 2012 10:00:24 -0700 (PDT) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.81]) by ietfa.amsl.com (Postfix) with ESMTP id E42EF21F857D for ; Wed, 12 Sep 2012 10:00:16 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2404.sfr.fr (SMTP Server) with ESMTP id 20C3570001CF; Wed, 12 Sep 2012 19:00:16 +0200 (CEST) Received: from [192.168.0.21] (unknown [88.166.221.144]) by msfrf2404.sfr.fr (SMTP Server) with ESMTP id B600A70001C9; Wed, 12 Sep 2012 19:00:15 +0200 (CEST) X-SFR-UUID: 20120912170015745.B600A70001C9@msfrf2404.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: <5050B718.5050003@globis.net> Date: Wed, 12 Sep 2012 19:00:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <501971BC-EEE8-4D31-BA6A-8D7E2A592F81@laposte.net> References: <6BD4EF08-99CE-4485-80FA-23A77564DDDB@laposte.net> <5050B718.5050003@globis.net> To: Ray Hunter X-Mailer: Apple Mail (2.1084) Cc: IPv6 Ops WG Subject: Re: [v6ops] 464XLAT removing IPv6 LAN scope X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 17:00:26 -0000 2012-09-12 18:23, Ray Hunter : > The idea certainly has merit, but I'm not yet fully convinced about = combining this with the 464XLAT draft. >=20 > The draft started off reserving one single IANA IID for IPv4 to IPv6 = translation. Now the reservation has expanded to cover the RFC1918 = space. >=20 > If the IPv4 range used on networks behind the CLAT is limited to = RFC1918 space, and it is indeed kept strictly local, why do we need to = reserve the complete 3 RFC1918 ranges for use as IID's (to be used to = create unique IPv6 addresses when the IPv6 prefix assigned to the CLAT)? >=20 > Why can't everyone just use the identical set of 192.168/16 IPv4 = prefixes behind their own CLAT? Simply to avoid imposing an unnecessary constraint. If a wireline sites needs more that 2^16 addresses, 192.168/16 isn't = enough; OTOH, there are implementations based on 192.168/1. No need to impose a = change. >=20 > On the other extreme: if 464XLAT were to allow inbound PLAT to CLAT = IPv4 - IPv4 sessions (and not just support a hub and spoke model for = outbound only sessions via the PLAT) why not reserve the entire /32 IPv4 = address space as IANA IID's for use in generating unique IPv6 addresses = for IPv4 nodes located behind a CLAT? An equivalent approach has = certainly been applied successfully in other transition mechanisms. Out of scope AFAIAC. > IHMO I think a lack of a clear answer to these extreme cases = demonstrates it's simply too early to reserve IANA IID space right now. In my understanding, just reserving 0.4 % of an IID range, already = available in IANA for such reservation, wouldn't have been premature at = all since at least some people understand how it permits to eliminate = NAT44s in /64 sites that do IPv6 tethering. Yet, I have stopped personally to argue against the too many who aren't = ready to share this understanding (ref = www.ietf.org/mail-archive/web/v6ops/current/msg14273.html). Best regards, RD=20 >=20 > regards, > RayH >=20 > R=E9mi Despr=E9s wrote: >>=20 >> 2012-09-12 15:54, Lorenzo Colitti: >>=20 >>> On Wed, Sep 12, 2012 at 9:58 PM, Cameron Byrne > wrote: >>>=20 >>> All that said, is the wg ok with accepting with Remi's solution? >>>=20 >>> Silence means no support. >>>=20 >>> If we can make it work, I think it has advantages. But it requires = that the text be written and that we as a WG think the issues through, = try to figure out if there are any corner cases, etc. DAD is simple and = we know how it works, but we haven't devoted much thought to Remi's = solution because it hasn't even been written in the draft yet. >>=20 >> Note that, as reminded to Cameron in the mast mail I sent, a text of = what the draft could become remains available in = www.ietf.org/mail-archive/web/v6ops/current/msg14077.html = . >>=20 >> RD >>=20 >>=20 >>> Realistically, what that means is that the draft will be delayed. >>>=20 >>> What are the alternatives? >>>=20 >>> 1. Stay silent on sharing one /64 and let implementations do their = thing. >>> 2. Decide that for now it's more practical to share a /64 with DAD. >>> 3. Remi's "reserve 3 IID ranges" proposal. >>>=20 >>> Anything else? >>=20 From fred@cisco.com Wed Sep 12 10:07:34 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94B6021F8623 for ; Wed, 12 Sep 2012 10:07:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.855 X-Spam-Level: X-Spam-Status: No, score=-109.855 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qr+GMrxMd-ns for ; Wed, 12 Sep 2012 10:07:33 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id A476A21F861E for ; Wed, 12 Sep 2012 10:07:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2102; q=dns/txt; s=iport; t=1347469653; x=1348679253; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=aOtHou33W81nJ9VnuP0EOb44zk8ap6SbDM5VQHchCyw=; b=WkIhDkUWSPLjOWN/EZJEFVq6LFpyfUMyD45ZIPBoY60q1YpdOu9FjXaa eZRxdroNADOMTdnhSKp3TD5JyANcvKG0N2VEsMrox4d490WuT0R0F5bGM jFcYZhSQro6oPjNblQGHI9flyDu9xpd1yjk+tp1KQz9L7nka2T6aqXx5K Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAFfAUFCtJV2d/2dsb2JhbABFu02BB4IgAQEBAwESASc/BQsCAQg2EDIlAgQODhmHZQYLm3qgL4sQGoVIYAOVX4EUjSKBaYJmgWM0 X-IronPort-AV: E=Sophos;i="4.80,410,1344211200"; d="scan'208";a="117871902" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP; 12 Sep 2012 17:07:33 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q8CH7X5c002802 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Sep 2012 17:07:33 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.97]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.001; Wed, 12 Sep 2012 12:07:32 -0500 From: "Fred Baker (fred)" To: Joel Jaeggli Thread-Topic: [v6ops] V6OPS WG Interim Meeting, September 29, 2012 Thread-Index: AQHNkQkYkmR6CoN1J0+I/v3jYW3eMg== Date: Wed, 12 Sep 2012 17:07:32 +0000 Message-ID: References: <20120831160458.25436.40986.idtracker@ietfa.amsl.com> In-Reply-To: <20120831160458.25436.40986.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.244.221] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19178.005 x-tm-as-result: No--33.839500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <3B29BA7660F2B34F9F9DC3827FB9605A@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: v6ops WG Subject: Re: [v6ops] V6OPS WG Interim Meeting, September 29, 2012 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 17:07:34 -0000 On Aug 31, 2012, at 9:04 AM, IESG Secretary wrote: > I think we should plan to maintain an interim document submission > deadline two weeks out from the meeting itself. To be considered for > inclusion in the interim agenda new or revised documented should be > submitted to the IETF document system by 23:59 UTC on Sept 14th. This is what I have seen since IETF-84 to date. We have two more days for u= pdated drafts for the construction of that agenda. At IETF-84, we discussed possibly discussing the following in the interim m= eeting: http://tools.ietf.org/html/draft-ietf-v6ops-enterprise-incremental-ipv6 "Enterprise Incremental IPv6", KK Chittimaneni, Tim Chown, Lee Howard, Victor Kuarsingh, Yanick Pouffary, Eric Vyncke, 8-Aug-12 http://tools.ietf.org/html/draft-lopez-v6ops-dc-ipv6 "A Reference Framework for DC Migration to IPv6", Zhonghua Chen, Diego Lopez, Tina Tsou, Cathy Zhou, 19-Jun-12 http://tools.ietf.org/html/draft-matthews-v6ops-design-guidelines "Design Guidelines for IPv6 Networks", Philip Matthews, 29-Jun-12 At this point, only *enterprise-incremental-ipv6 has been updated. active drafts updated since IETF 84: -rw-rw-r-- 1 fred fred 35674 Aug 7 00:31 draft-ietf-v6ops-nat64-experie= nce-00.txt -rw-rw-r-- 1 fred fred 66223 Aug 7 18:32 draft-ietf-v6ops-enterprise-in= cremental-ipv6-00.txt -rw-rw-r-- 1 fred fred 15230 Aug 17 02:10 draft-smith-v6ops-larger-ipv6-= loopback-prefix-01.txt -rw-rw-r-- 1 fred fred 42778 Aug 19 22:59 draft-ietf-v6ops-464xlat-07.tx= t Finished WGLC, looking for further comments on -03 and on text proposed in = http://www.ietf.org/mail-archive/web/v6ops/current/msg14109.html: -rw-rw-r-- 1 fred fred 60136 Aug 30 23:57 draft-ietf-v6ops-icp-guidance-= 03.txt In IESG: -rw-rw-r-- 1 fred fred 49667 Aug 16 09:04 draft-ietf-v6ops-6204bis-10.tx= t -rw-rw-r-- 1 fred fred 12249 Sep 10 16:51 draft-ietf-v6ops-ivi-icmp-addr= ess-06.txt In RFC Editor's queue: -rw-rw-r-- 1 fred fred 71741 Sep 10 13:19 draft-ietf-v6ops-wireline-incr= emental-ipv6-06.txt From fred@cisco.com Wed Sep 12 11:38:49 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E15021F86BB for ; Wed, 12 Sep 2012 11:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.029 X-Spam-Level: X-Spam-Status: No, score=-110.029 tagged_above=-999 required=5 tests=[AWL=0.270, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7xIHkWP3j06P for ; Wed, 12 Sep 2012 11:38:48 -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 3373921F86B8 for ; Wed, 12 Sep 2012 11:38:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=548; q=dns/txt; s=iport; t=1347475128; x=1348684728; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=27IV4ug+3omSPrfpFdIa8z0o6MinknIQuO6adcOemRQ=; b=NKDqxVnqZuCgh1Xj9KDACklRElJpRNbsOHk00IG4PIv3iFG2+k8oeSOc CtKevCo+zeE+WThQmcQHjPLLrN/XgAmroFIALooYSrHhTwYI0wM281S++ DxBTvi/kXNtkha2TzWbXjnhYxVnvBBmR06AI0EUuCE4nt+pJ7vpO8PEQG Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAK/VUFCtJV2a/2dsb2JhbABFu0+BB4IhAQEEEgFmEAIBCEYyJQIEDieHa5wAoDSQcmADiCCNP442gWmCZoIX X-IronPort-AV: E=Sophos;i="4.80,411,1344211200"; d="scan'208";a="120951466" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 12 Sep 2012 18:38:45 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q8CIcjcB031635 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Sep 2012 18:38:45 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.97]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0298.004; Wed, 12 Sep 2012 13:38:44 -0500 From: "Fred Baker (fred)" To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Thread-Topic: [v6ops] 464XLAT removing IPv6 LAN scope Thread-Index: AQHNkRXWcl0fYn4YCE2pDNXbqtkKBg== Date: Wed, 12 Sep 2012 18:38:44 +0000 Message-ID: References: <6BD4EF08-99CE-4485-80FA-23A77564DDDB@laposte.net> <5050B718.5050003@globis.net> <501971BC-EEE8-4D31-BA6A-8D7E2A592F81@laposte.net> In-Reply-To: <501971BC-EEE8-4D31-BA6A-8D7E2A592F81@laposte.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.244.221] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19180.000 x-tm-as-result: No--24.524400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPv6 Ops WG Subject: Re: [v6ops] 464XLAT removing IPv6 LAN scope X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 18:38:49 -0000 R=E9mi: I think that there are two consensuses that we have reached. One is that 46= 4XLAT, although we still need a -08 to finalize it, enjoys a rough consensu= s; you are the primary person objecting to it. The other is that your propo= sal should be discussed on its merits. Would you be willing to describe you= r proposal in a draft that can be discussed separately from 464XLAT, and co= uld perhaps update the specification if/when agreed to? I'll note that netw= orks that are *not* using 464XLAT may also find it useful. Fred= From despres.remi@laposte.net Wed Sep 12 13:02:43 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1404121F8533 for ; Wed, 12 Sep 2012 13:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.259 X-Spam-Level: X-Spam-Status: No, score=-1.259 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LBaswR21VG2t for ; Wed, 12 Sep 2012 13:02:40 -0700 (PDT) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.2]) by ietfa.amsl.com (Postfix) with ESMTP id 3F7F221F8504 for ; Wed, 12 Sep 2012 13:02:39 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2106.sfr.fr (SMTP Server) with ESMTP id 4F37E7000057; Wed, 12 Sep 2012 22:02:38 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2106.sfr.fr (SMTP Server) with ESMTP id E66787000053; Wed, 12 Sep 2012 22:02:37 +0200 (CEST) X-SFR-UUID: 20120912200237943.E66787000053@msfrf2106.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: Date: Wed, 12 Sep 2012 22:02:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <614BB92F-9FFD-478A-9DBF-8221AF8903D6@laposte.net> References: <6BD4EF08-99CE-4485-80FA-23A77564DDDB@laposte.net> <5050B718.5050003@globis.net> <501971BC-EEE8-4D31-BA6A-8D7E2A592F81@laposte.net> To: Fred Baker (fred) X-Mailer: Apple Mail (2.1084) Cc: IPv6 Ops WG Subject: Re: [v6ops] 464XLAT removing IPv6 LAN scope X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 20:02:43 -0000 Hi, Fred,=20 As my efforts to contribute to progress in v6ops have come to an end = (ref. www.ietf.org/mail-archive/web/v6ops/current/msg14273.html), I no = longer object to any version of the 464XLAT draft.=20 You let me feel, sometimes, that you didn't liked much of my = contributions. Yet I believe you after all attributed some value to some = of them, enough to have no regret. All my wishes for the future, and best regards, RD =20 2012-09-12 =E0 20:38, Fred Baker (fred) : > R=E9mi: >=20 > I think that there are two consensuses that we have reached. One is = that 464XLAT, although we still need a -08 to finalize it, enjoys a = rough consensus; you are the primary person objecting to it. The other = is that your proposal should be discussed on its merits. Would you be = willing to describe your proposal in a draft that can be discussed = separately from 464XLAT, and could perhaps update the specification = if/when agreed to? I'll note that networks that are *not* using 464XLAT = may also find it useful. >=20 > Fred From lorenzo@google.com Wed Sep 12 17:53:31 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 586B421F866D for ; Wed, 12 Sep 2012 17:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.885 X-Spam-Level: X-Spam-Status: No, score=-102.885 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kbULXxkFhMph for ; Wed, 12 Sep 2012 17:53:30 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id CAB3021F8666 for ; Wed, 12 Sep 2012 17:53:30 -0700 (PDT) Received: by oagk14 with SMTP id k14so1600866oag.31 for ; Wed, 12 Sep 2012 17:53:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=0R35MpGDMkKjxlJ7apVwBQz9Q7ea2+hqKP//+/r5sxc=; b=Nfak7UJ5oQ2k+Nms1u4rA3wpy5Yva9ZSAG9ggSLocWNQdLeIPtMG4o057tgdjgBeS/ K2H7F/KXthRrD+iME5bP7FD04TTSXRm+HOWxaMu+xLqhnObd4niCJuwUnBOAcF106vzs ca108zcxV5dSgo9F2NPk99bk2mXSb6ET0WQbht0A0JJTOmJLHiM0qry2CIVBbKdT9ZVo vjnVRCJhLnUCebxOcr6SweYkAWQ3V2s9IN+1AxlfnlUfOAhnmVWEFf5rNw0+MsDUmKh7 DNoUmLOEM1a6YgtswJSM7Xd+okerZl/ZGg9qEHJofR2qeUykjuIRrjBtECHylHCNdVqq c4/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=0R35MpGDMkKjxlJ7apVwBQz9Q7ea2+hqKP//+/r5sxc=; b=AZCt3dcUGBvg0E2912uHpYhxBerPINbpfJKJFfOaRD1I70eYw0yIDlLhez/Q/b/Bfs tBbrAPUCsYmdtTEl67LicUE+KqKrqB5m4kA7ijvUW8/VVjPAq5Bb8NPfXi4QbPtlHjOw XwKNuEFbwYEXdPmPqxtvANEYIkAaAAd+cqvwCy9x7zQMktFeCIcRy/R8aBjCC5QXIxLE QSKMzp3R0QrHi1IEEvuDByaZ3ordWBM0RqgpiMtMomZKWzna+fnqejN33bLFa0R7VnLV 2x5Lk5EOlM8VPe1J77raWMfi5ePtsmZlS8SQWzSKV0eEUNHANWQCRJuVHNyFbBhFd5Sm m4/A== Received: by 10.60.10.6 with SMTP id e6mr251811oeb.45.1347497610474; Wed, 12 Sep 2012 17:53:30 -0700 (PDT) Received: by 10.60.10.6 with SMTP id e6mr251805oeb.45.1347497610397; Wed, 12 Sep 2012 17:53:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.237.6 with HTTP; Wed, 12 Sep 2012 17:53:10 -0700 (PDT) In-Reply-To: <20120912095353.16694hpff0oaxbeo@mail.drown.org> References: <20120912095353.16694hpff0oaxbeo@mail.drown.org> From: Lorenzo Colitti Date: Thu, 13 Sep 2012 09:53:10 +0900 Message-ID: To: Dan Drown Content-Type: multipart/alternative; boundary=e89a8fb2028a6748b404c98abc5a X-System-Of-Record: true X-Gm-Message-State: ALoCoQkYftPX/YvF7AWD+ApGSHO6bedWNWBLKwncW+3GjEwPnE9ncOSPmO7O3ybFdQr6ighiiSVe+z9ToAD+ytNL3W6S57lBEK6oYNe8VS8zkb4fcgVgebZf7qfyQDkrrxYjdKJpeXJIWId1yHx3SykoBQN+PoqEELC/lTg0O/UgvpoMNDjRlc76Ys/bwn4hBpxA36bjzLJY Cc: v6ops@ietf.org Subject: Re: [v6ops] 464XLAT removing IPv6 LAN scope X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 00:53:31 -0000 --e89a8fb2028a6748b404c98abc5a Content-Type: text/plain; charset=ISO-8859-1 On Wed, Sep 12, 2012 at 11:53 PM, Dan Drown wrote: > These are both nice to have but are not required to get 464xlat working on > android. > Speaking as an implementer, do you think it would be better for implementers to implement Remi's idea and put it in the draft before it becomes final, or ship the draft now and possibly fix up the implementations later? --e89a8fb2028a6748b404c98abc5a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Sep 12, 2012 at 11:53 PM, Dan Drown <dan-v6ops@drown.org&g= t; wrote:
    These are both nice to have but are not required to get 4= 64xlat working on android.
    =A0
    Speaking as= an implementer, do you think it would be better for implementers to implem= ent Remi's idea and put it in the draft before it becomes final, or shi= p the draft now and possibly fix up the implementations later?
    --e89a8fb2028a6748b404c98abc5a-- From lorenzo@google.com Wed Sep 12 18:06:54 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74AE321F8694 for ; Wed, 12 Sep 2012 18:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.888 X-Spam-Level: X-Spam-Status: No, score=-102.888 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tvEwP9-Wjoeo for ; Wed, 12 Sep 2012 18:06:53 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id C4D7A21F8692 for ; Wed, 12 Sep 2012 18:06:53 -0700 (PDT) Received: by oagk14 with SMTP id k14so1608111oag.31 for ; Wed, 12 Sep 2012 18:06:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=vRMILT+yFW1TKZyUwJSiDfWBqbQ3xl97GyBYJ2hJDjs=; b=d0rijFQwIGWbhy1RjWLPKn6d8KzK/ru/9r+blQEyBP4yVXGcKEHf+xcs/wGM2c+9IR ZcEyz+GCBfwCwEGmAd1FWq3D5wsT3+iuXIInjai273hc9tWILlfh11UcJhxMJIQKthel dKmZjD4gZ+38k6kzuRrlksJSsUqWl7ULmdVnRtxvYFVjYjnQItLFM+XLzFVCSH0qyK6g pBWgvqUqi4K0vR69/+Aasnja7DA8XaZzRndcpqf55+udvZdILdrrbz+VW/zTYVx5HFsg wyCM353Nl4OcXi6chXM8R1fNB6qsQPdXGOsE1wuJoMMn/C1pqscz0RniaHLD/yb7N23L FRdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=vRMILT+yFW1TKZyUwJSiDfWBqbQ3xl97GyBYJ2hJDjs=; b=jqin/4h7V4a81j98D6/zg7sRdTRAMEnVelS5K7HJ5NCy18cFXJLh2JWjndNIVaBZaI NJkRVrbOvoDYteMR2+pmFF6TBxeACmnE4NepPYyxt7t7afm2EXTyPohT8okynL8aJUHi 9rgbduuW1skiYzvrnh8JG6rQYM4ijCZLxRi5b7JCOS3tcn2YNR9B5eK99Iji2WTlO+IO 2FTuVukJ5febauQUmXJ2ZhYydjGTjtAU4AoJbsgPxkoQLwIEIZ/fKdvzQjR6x7eBhupk FXxKzkWmQ1jS3kX2I+5RWx2pFIABv0iDdRGQa7mygzrN36+EG8uv8kALPCWTGhRDwAWb y0Fw== Received: by 10.182.202.1 with SMTP id ke1mr242662obc.51.1347498413335; Wed, 12 Sep 2012 18:06:53 -0700 (PDT) Received: by 10.182.202.1 with SMTP id ke1mr242655obc.51.1347498413242; Wed, 12 Sep 2012 18:06:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.237.6 with HTTP; Wed, 12 Sep 2012 18:06:32 -0700 (PDT) In-Reply-To: References: <6BD4EF08-99CE-4485-80FA-23A77564DDDB@laposte.net> <5050B718.5050003@globis.net> <501971BC-EEE8-4D31-BA6A-8D7E2A592F81@laposte.net> From: Lorenzo Colitti Date: Thu, 13 Sep 2012 10:06:32 +0900 Message-ID: To: "Fred Baker (fred)" Content-Type: multipart/alternative; boundary=e89a8f64369041b7e004c98aec34 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlBqBobH7wDC4V9h5X5PdIeYjJ9hc7REP85AOdKgFvMi1+xbqMyxnC5bPKka0Os85idcXGY4f9Br2jsfn5LSEi6GYgeteWcdFJg8yzQwbLkPQP8bydPzqWqm6a6G6BbI8O/nsQtLI7MpR4glKP3cs+3YHstKbTDY8lzwJQUENTBkpvV+MCVPFqChpr2oLHgaLm+XXS8 Cc: IPv6 Ops WG Subject: Re: [v6ops] 464XLAT removing IPv6 LAN scope X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 01:06:54 -0000 --e89a8f64369041b7e004c98aec34 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Sep 13, 2012 at 3:38 AM, Fred Baker (fred) wrote: > I think that there are two consensuses that we have reached. One is that > 464XLAT, although we still need a -08 to finalize it, enjoys a rough > consensus; you are the primary person objecting to it. It definitely looks like we're approaching rough consensus, but it seems to me that there are two contentious points which we are still split on: 1. Whether to ask IANA to reserve IIDs, and if so, how many (1, 2^32, or 2^24+2^20+2^16) 2. Whether to mention BIH or not. What would be your guidance to the authors on these points? > The other is that your proposal should be discussed on its merits. Would > you be willing to describe your proposal in a draft that can be discussed > separately from 464XLAT, and could perhaps update the specification if/when > agreed to? I'll note that networks that are *not* using 464XLAT may also > find it useful. > Which parts are you suggesting breaking out? The "ask IANA to reserve IIDs in order to avoid having to rely on DAD" part? What IID do you think the phone should use when operating as a standalone CLAT? Even if we break out Remi's proposal to another draft, it would still be good to ensure that the IIDs used there don't conflict with the ones used by a standalone CLAT. --e89a8f64369041b7e004c98aec34 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Sep 13, 2012 at 3:38 AM, Fred Baker (fred) <fred@cisco.com> wrote:
    I think that there are two consensuses that we have reached. One is that 46= 4XLAT, although we still need a -08 to finalize it, enjoys a rough consensu= s; you are the primary person objecting to it.

    It definitely looks like we're approaching rough consensus, but it= seems to me that there are two contentious points which we are still split= on:

    1. Whether to ask IANA to reserve IIDs, and i= f so, how many (1, 2^32, or 2^24+2^20+2^16)
    2. Whether to mention BIH or not.

    What would = be your guidance to the authors on these points?
    =A0
    The other is that your proposal should be discussed on its merits. Would y= ou be willing to describe your proposal in a draft that can be discussed se= parately from 464XLAT, and could perhaps update the specification if/when a= greed to? I'll note that networks that are *not* using 464XLAT may also= find it useful.

    Which parts are you suggesting breaking ou= t? The "ask IANA to reserve IIDs in order to avoid having to rely on D= AD" part? What IID do you think the phone should use when operating as= a standalone CLAT? Even if we break out Remi's proposal to another dra= ft, it would still be good to ensure that the IIDs used there don't con= flict with the ones used by a standalone CLAT.
    --e89a8f64369041b7e004c98aec34-- From joelja@bogus.com Wed Sep 12 18:19:32 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7E421E8034 for ; Wed, 12 Sep 2012 18:19:32 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2CguNxp75BVl for ; Wed, 12 Sep 2012 18:19:32 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 1920611E808A for ; Wed, 12 Sep 2012 18:19:32 -0700 (PDT) Received: from joels-MacBook-Air.local (adsl-71-134-231-113.dsl.pltn13.pacbell.net [71.134.231.113]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q8D1JS8u066352 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 13 Sep 2012 01:19:29 GMT (envelope-from joelja@bogus.com) Message-ID: <5051349B.5080301@bogus.com> Date: Wed, 12 Sep 2012 18:19:23 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120821 Thunderbird/15.0 MIME-Version: 1.0 To: Lorenzo Colitti References: <6BD4EF08-99CE-4485-80FA-23A77564DDDB@laposte.net> <5050B718.5050003@globis.net> <501971BC-EEE8-4D31-BA6A-8D7E2A592F81@laposte.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Thu, 13 Sep 2012 01:19:29 +0000 (UTC) Cc: IPv6 Ops WG Subject: Re: [v6ops] 464XLAT removing IPv6 LAN scope X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 01:19:32 -0000 On 9/12/12 6:06 PM, Lorenzo Colitti wrote: > On Thu, Sep 13, 2012 at 3:38 AM, Fred Baker (fred) > wrote: > > I think that there are two consensuses that we have reached. One > is that 464XLAT, although we still need a -08 to finalize it, > enjoys a rough consensus; you are the primary person objecting to it. > > > 1. Whether to ask IANA to reserve IIDs, and if so, how many (1, 2^32, > or 2^24+2^20+2^16) with my wg chair hat off, I don't see this as desirable. > 2. Whether to mention BIH or not. again in the same role, I think specifying it should be outside the scope of the document. mentioning it is not the same as specifying it. From ietfc@btconnect.com Thu Sep 13 02:25:59 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E62B421F8568 for ; Thu, 13 Sep 2012 02:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.056 X-Spam-Level: X-Spam-Status: No, score=-3.056 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p078tbV69JzL for ; Thu, 13 Sep 2012 02:25:59 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe010.messaging.microsoft.com [216.32.180.30]) by ietfa.amsl.com (Postfix) with ESMTP id 3441021F8554 for ; Thu, 13 Sep 2012 02:25:59 -0700 (PDT) Received: from mail261-va3-R.bigfish.com (10.7.14.251) by VA3EHSOBE004.bigfish.com (10.7.40.24) with Microsoft SMTP Server id 14.1.225.23; Thu, 13 Sep 2012 09:25:58 +0000 Received: from mail261-va3 (localhost [127.0.0.1]) by mail261-va3-R.bigfish.com (Postfix) with ESMTP id 074F21300094; Thu, 13 Sep 2012 09:25:58 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.249.85; KIP:(null); UIP:(null); IPV:NLI; H:AMSPRD0710HT003.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: PS-24(zz98dI9371I542M1432I1418Id6f1izz1202h1d1ah1d2ahzz1033IL8275bh8275dhz2dh2a8h5a9h668h839hd24hf0ah107ah1177h1179h1288h12a5h12a9h12bdh304l1155h) Received: from mail261-va3 (localhost.localdomain [127.0.0.1]) by mail261-va3 (MessageSwitch) id 1347528356525118_18103; Thu, 13 Sep 2012 09:25:56 +0000 (UTC) Received: from VA3EHSMHS002.bigfish.com (unknown [10.7.14.253]) by mail261-va3.bigfish.com (Postfix) with ESMTP id 740EBFC004B; Thu, 13 Sep 2012 09:25:56 +0000 (UTC) Received: from AMSPRD0710HT003.eurprd07.prod.outlook.com (157.56.249.85) by VA3EHSMHS002.bigfish.com (10.7.99.12) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 13 Sep 2012 09:25:54 +0000 Received: from DB3PRD0510HT003.eurprd05.prod.outlook.com (157.56.252.37) by pod51017.outlook.com (10.255.160.166) with Microsoft SMTP Server (TLS) id 14.16.190.9; Thu, 13 Sep 2012 09:25:44 +0000 Message-ID: <008f01cd9191$d66a7980$4001a8c0@gateway.2wire.net> From: t.petch To: Lorenzo Colitti , "Fred Baker (fred)" References: <6BD4EF08-99CE-4485-80FA-23A77564DDDB@laposte.net><5050B718.5050003@globis.net><501971BC-EEE8-4D31-BA6A-8D7E2A592F81@laposte.net> Date: Thu, 13 Sep 2012 10:26:14 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.252.37] X-OriginatorOrg: btconnect.com Cc: IPv6 Ops WG Subject: Re: [v6ops] 464XLAT removing IPv6 LAN scope X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 09:26:00 -0000 ----- Original Message ----- From: "Lorenzo Colitti" To: "Fred Baker (fred)" Cc: "IPv6 Ops WG" Sent: Thursday, September 13, 2012 2:06 AM > On Thu, Sep 13, 2012 at 3:38 AM, Fred Baker (fred) wrote: > > > I think that there are two consensuses that we have reached. One is that > > 464XLAT, although we still need a -08 to finalize it, enjoys a rough > > consensus; you are the primary person objecting to it. > > It definitely looks like we're approaching rough consensus, but it seems to > me that there are two contentious points which we are still split on: > > 1. Whether to ask IANA to reserve IIDs, and if so, how many (1, 2^32, or > 2^24+2^20+2^16) > 2. Whether to mention BIH or not. > > What would be your guidance to the authors on these points? Lorenzo, I agree, that these two points seem to me to be unresolved. When you ask what guidance a WG Chair should give to an author, I would prefer that the WG Chair be asked what they perceive to be the consensus on these specific points, which, as you say, remain contentious (IMO). And if the WG Chair cannot perceive a consensus, then I would like them to be asked to take such steps as they need to in order to be able to perceive a consensus and then declare it. As I said before, I think - BIH should not get a mention - reserved IIDs is superior to a stateful NAT44 approach (the clue is in the word stateful). Tom Petch > > > The other is that your proposal should be discussed on its merits. Would > > you be willing to describe your proposal in a draft that can be discussed > > separately from 464XLAT, and could perhaps update the specification if/when > > agreed to? I'll note that networks that are *not* using 464XLAT may also > > find it useful. > > > > Which parts are you suggesting breaking out? The "ask IANA to reserve IIDs > in order to avoid having to rely on DAD" part? What IID do you think the > phone should use when operating as a standalone CLAT? Even if we break out > Remi's proposal to another draft, it would still be good to ensure that the > IIDs used there don't conflict with the ones used by a standalone CLAT. > ------------------------------------------------------------------------ -------- > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From phdgang@gmail.com Thu Sep 13 04:49:40 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B092C21F855D for ; Thu, 13 Sep 2012 04:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.867 X-Spam-Level: X-Spam-Status: No, score=-2.867 tagged_above=-999 required=5 tests=[AWL=-0.468, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id htHizsx+KZtj for ; Thu, 13 Sep 2012 04:49:40 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id EF68C21F854F for ; Thu, 13 Sep 2012 04:49:39 -0700 (PDT) Received: by vbbfc26 with SMTP id fc26so3724978vbb.31 for ; Thu, 13 Sep 2012 04:49:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OQxV8MyKCP/BZWJemfTeyHkD1WMQKPwXLOMDNHRd0S8=; b=znf7lhSBkiB+ZIRj7vYx8f/IdiI3UmAp6l0WfRPFWWo2QaBSzbf7I9zaQukd/cgp8s nX9v5Ti0MAqIK8zeR8WY2jt9n6S7ilsZg27vbwwwEKCbanr0M2a2Jw6/3m0/DMBkYxId +f0QmxHxH+q8r+OvruBGzVWIPP56VJEXKTlX44SRf8/nBnKw/ybB4rH6q3VQleqnyUe6 u8LvxbfBwLA4Y+bljY4bl2W1DPgJ1yv6TRrxnUPbzm3Cl1T0pnTRCn5RqX8p2VfP6bDG 65V/suvSwmUZQnZouCMsFKG41YrS4ECQx+tra23P3ZldAYgiS8PeQySDTNIcAYKY5Jh4 kTTg== MIME-Version: 1.0 Received: by 10.59.1.162 with SMTP id bh2mr1148265ved.13.1347536979359; Thu, 13 Sep 2012 04:49:39 -0700 (PDT) Received: by 10.58.114.231 with HTTP; Thu, 13 Sep 2012 04:49:39 -0700 (PDT) In-Reply-To: <008f01cd9191$d66a7980$4001a8c0@gateway.2wire.net> References: <6BD4EF08-99CE-4485-80FA-23A77564DDDB@laposte.net> <5050B718.5050003@globis.net> <501971BC-EEE8-4D31-BA6A-8D7E2A592F81@laposte.net> <008f01cd9191$d66a7980$4001a8c0@gateway.2wire.net> Date: Thu, 13 Sep 2012 19:49:39 +0800 Message-ID: From: GangChen To: "t.petch" Content-Type: text/plain; charset=ISO-8859-1 Cc: IPv6 Ops WG Subject: Re: [v6ops] 464XLAT removing IPv6 LAN scope X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 11:49:40 -0000 2012/9/13, t.petch : > ----- Original Message ----- > From: "Lorenzo Colitti" > To: "Fred Baker (fred)" > Cc: "IPv6 Ops WG" > Sent: Thursday, September 13, 2012 2:06 AM >> On Thu, Sep 13, 2012 at 3:38 AM, Fred Baker (fred) > wrote: >> >> > I think that there are two consensuses that we have reached. One is > that >> > 464XLAT, although we still need a -08 to finalize it, enjoys a rough >> > consensus; you are the primary person objecting to it. >> >> It definitely looks like we're approaching rough consensus, but it > seems to >> me that there are two contentious points which we are still split on: >> >> 1. Whether to ask IANA to reserve IIDs, and if so, how many (1, 2^32, > or >> 2^24+2^20+2^16) >> 2. Whether to mention BIH or not. >> >> What would be your guidance to the authors on these points? > > Lorenzo, > > I agree, that these two points seem to me to be unresolved. > > When you ask what guidance a WG Chair should give to an author, I would > prefer that the WG Chair be asked what they perceive to be the consensus > on these specific points, which, as you say, remain contentious (IMO). > > And if the WG Chair cannot perceive a consensus, then I would like them > to be asked to take such steps as they need to in order to be able to > perceive a consensus and then declare it. > > As I said before, I think > - BIH should not get a mention As far as I can say after several months discussions, 1) "Mentioning it is not the same as specifying it" 2) IPv4-IPv6 communication was the case 464xlat originally targeted since it was introduced in draft -00. And BIH was identified as the standard track RFC afterwards 3) The previous consensus was achieved to mention it. The recent discussions re-open it (I hope we could achieve new consensus here) 4) Many more people are aware of the combination since such statement was carried through several versions 5) *Mentioned or not* maybe important to some people who already followed the draft and made implementation in parallel. It maybe "don't matter" to others 6) Technical concerns about the combination have been answered unless there is new point > - reserved IIDs is superior to a stateful NAT44 approach (the clue is in > the word stateful). Current implementation is using the single reserved IID, at least we can try the three ranges Best Regards Gang > Tom Petch > >> >> > The other is that your proposal should be discussed on its merits. > Would >> > you be willing to describe your proposal in a draft that can be > discussed >> > separately from 464XLAT, and could perhaps update the specification > if/when >> > agreed to? I'll note that networks that are *not* using 464XLAT may > also >> > find it useful. >> > >> >> Which parts are you suggesting breaking out? The "ask IANA to reserve > IIDs >> in order to avoid having to rely on DAD" part? What IID do you think > the >> phone should use when operating as a standalone CLAT? Even if we break > out >> Remi's proposal to another draft, it would still be good to ensure > that the >> IIDs used there don't conflict with the ones used by a standalone > CLAT. >> > > > ------------------------------------------------------------------------ > -------- > > >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From cb.list6@gmail.com Thu Sep 13 08:50:47 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 187B321F85F4 for ; Thu, 13 Sep 2012 08:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.279 X-Spam-Level: X-Spam-Status: No, score=-3.279 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JP8Nshq12LXX for ; Thu, 13 Sep 2012 08:50:46 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4F7C421F84DF for ; Thu, 13 Sep 2012 08:50:46 -0700 (PDT) Received: by lbky2 with SMTP id y2so2228817lbk.31 for ; Thu, 13 Sep 2012 08:50:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=yFs3dyzfIaRBP3zUXAVCryLxC6XkTWWeapwix63XS0c=; b=UPJzKnH/6l4/O80j1AnFhSv+kRhrVyZIDb+MmTI8Ogjfm6sDvmi2WgMTsQUz/kGLyM Un8tspbZEA6luObTWzJO2cr9qm18Zn2k8hA0p6WWU4nW0T6A+N62D5z0cG+6Y5f+1bIn QNLNM0YKTHhO2ojWNpjx2q3gNAMgy45OVuajQ1s86l9EoD4F10bpjpwHbfHgfk1c8mtL 0/tp+K0iqEUsf9DKwJES3CIiJQMG7Ue+3r8ilekk78sKhPmjWy5kUwf2PnPdW4amSvyN MWZ4Z/EsavXcH8pJO1eDkEfDVbwMHOTHG7BQIUeGxxMvwpV3EWvOdaQRmPpovTtCPlcm n87A== MIME-Version: 1.0 Received: by 10.112.38.163 with SMTP id h3mr18359lbk.130.1347551445153; Thu, 13 Sep 2012 08:50:45 -0700 (PDT) Received: by 10.112.49.66 with HTTP; Thu, 13 Sep 2012 08:50:45 -0700 (PDT) Date: Thu, 13 Sep 2012 08:50:45 -0700 Message-ID: From: Cameron Byrne To: IPv6 Ops WG Content-Type: text/plain; charset=ISO-8859-1 Subject: [v6ops] BIH pointer in 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 15:50:47 -0000 Joel wrote: ---------- Forwarded message ---------- From: joel jaeggli Date: Wed, Sep 12, 2012 at 6:19 PM Subject: Re: [v6ops] 464XLAT removing IPv6 LAN scope To: Lorenzo Colitti Cc: IPv6 Ops WG On 9/12/12 6:06 PM, Lorenzo Colitti wrote: > > On Thu, Sep 13, 2012 at 3:38 AM, Fred Baker (fred) > wrote: > > I think that there are two consensuses that we have reached. One > is that 464XLAT, although we still need a -08 to finalize it, > enjoys a rough consensus; you are the primary person objecting to it. > > > 1. Whether to ask IANA to reserve IIDs, and if so, how many (1, 2^32, or 2^24+2^20+2^16) with my wg chair hat off, I don't see this as desirable. > 2. Whether to mention BIH or not. again in the same role, I think specifying it should be outside the scope of the document. mentioning it is not the same as specifying it. Regarding 1, the plan is to remove prefix sharing and move the ideas learned there with reserved IID to a specific and seperate I-D Regarding 2, the authors would like to mention BIH for completeness to provide a pointer to how the ietf has defined all stateful v4 and v6 translation permutations, as shown in the traffic treatment table http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-07#section-9.2 Since this is a wg doc, we need the wg view. I believe Remi's text is acceptable. Others' thoughts? http://www.ietf.org/mail-archive/web/v6ops/current/msg14252.html CB From denghui02@gmail.com Thu Sep 13 10:26:28 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF4021F846C for ; Thu, 13 Sep 2012 10:26:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.442, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BsoQGi1qrS42 for ; Thu, 13 Sep 2012 10:26:27 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9330421F84D3 for ; Thu, 13 Sep 2012 10:26:27 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so5423469obb.31 for ; Thu, 13 Sep 2012 10:26:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pXgKGPjzuP74j/8M52oU9x2sNOtEt/Ii3gd+zAoPGu4=; b=IaoW7WO7HI0qUXAf1PaObnbetbmHo8w428XEOr1LVEe4XqQK2dsIVV72w/G4ae0Yx+ 2FTghgq/WxdMJ1vOHWmMcVQK6fbfF2M998fYa9BUXJhSAd8a0rzhVIZtWbVmf9ffvR7R +NF2lbr+6EK3fgEkCyCRqZk5eutjl77V6i961KmxaVbZ8A7AKIafpn6EqYx97YnXmNbd vP2Jm4WWc7lpwHj9rxU1NWnPRywOyfjxRyXCIeWYKlvGhD5ovSv8Mm6f/zuRlo/E8uiJ kCwgzrhmNC7tvzp7jo9gbgb3XMnnse0p22Q3z2jpdbDjEMeXURcjt++VUolM8ELWM4fB 0Glg== MIME-Version: 1.0 Received: by 10.60.7.197 with SMTP id l5mr3637986oea.33.1347557187132; Thu, 13 Sep 2012 10:26:27 -0700 (PDT) Received: by 10.182.212.8 with HTTP; Thu, 13 Sep 2012 10:26:27 -0700 (PDT) In-Reply-To: References: Date: Thu, 13 Sep 2012 18:26:27 +0100 Message-ID: From: Hui Deng To: Cameron Byrne Content-Type: multipart/alternative; boundary=e89a8f83a16374201804c9989b85 Cc: IPv6 Ops WG Subject: Re: [v6ops] BIH pointer in 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 17:26:28 -0000 --e89a8f83a16374201804c9989b85 Content-Type: text/plain; charset=ISO-8859-1 For 2, I second Cameron's recommendation here. I don't see the reasonable exucse to change this unnormative text, and those text which has been adopted before with the discussion. For the operation consideration, it's quite clear that two future users (operators) of this specification expressed they want this. -Hui 2012/9/13 Cameron Byrne > Joel wrote: > > > ---------- Forwarded message ---------- > From: joel jaeggli > Date: Wed, Sep 12, 2012 at 6:19 PM > Subject: Re: [v6ops] 464XLAT removing IPv6 LAN scope > To: Lorenzo Colitti > Cc: IPv6 Ops WG > > > On 9/12/12 6:06 PM, Lorenzo Colitti wrote: > > > > On Thu, Sep 13, 2012 at 3:38 AM, Fred Baker (fred) fred@cisco.com>> wrote: > > > > I think that there are two consensuses that we have reached. One > > is that 464XLAT, although we still need a -08 to finalize it, > > enjoys a rough consensus; you are the primary person objecting to it. > > > > > > 1. Whether to ask IANA to reserve IIDs, and if so, how many (1, 2^32, or > 2^24+2^20+2^16) > > with my wg chair hat off, I don't see this as desirable. > > > 2. Whether to mention BIH or not. > > again in the same role, I think specifying it should be outside the > scope of the document. mentioning it is not the same as specifying it. > > > Regarding 1, the plan is to remove prefix sharing and move the ideas > learned there with reserved IID to a specific and seperate I-D > > Regarding 2, the authors would like to mention BIH for completeness to > provide a pointer to how the ietf has defined all stateful v4 and v6 > translation permutations, as shown in the traffic treatment table > http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-07#section-9.2 > > Since this is a wg doc, we need the wg view. > > I believe Remi's text is acceptable. Others' thoughts? > > http://www.ietf.org/mail-archive/web/v6ops/current/msg14252.html > > CB > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --e89a8f83a16374201804c9989b85 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    For 2, I second Cameron's recommendation here.
    =A0
    =
    I don't see the reasonable exucse to change this=A0unnormative tex= t, and those text=A0which has been adopted before with the discussion. For = the operation consideration, it's quite clear that two future users (op= erators)=A0of this specification expressed they want this.
    -Hui
    2012/9/13 Cameron Byrne= <cb.list6@gmail.com>
    Joel wrote:


    ---------- Forwarded message ----------
    From: joel jaeggli <joelja@bogus.com= >
    Date: Wed, Sep 12, 2012 at 6:19 PM
    Subject: Re: [v6ops] 464XLAT removing IPv6 LAN scope
    To: Lorenzo Colitti <lorenzo@googl= e.com>
    Cc: IPv6 Ops WG <v6ops@ietf.org>= ;


    On 9/12/12 6:06 PM, Lorenzo Colitti wrote:
    >
    > On Thu, Sep 13, 2012 at 3:38 AM, Fred Baker (fred) <fred@cisco.com <mailto:fred@cisco.com>> wrote:
    >
    > =A0 =A0 I think that there are two consensuses that we have reached. O= ne
    > =A0 =A0 is that 464XLAT, although we still need a -08 to finalize it,<= br> > =A0 =A0 enjoys a rough consensus; you are the primary person objecting= to it.
    >
    >
    > 1. Whether to ask IANA to reserve IIDs, and if so, how many (1, 2^32, = or 2^24+2^20+2^16)

    with my wg chair hat off, I don't see this as desirable.

    > 2. Whether to mention BIH or not.

    again in the same role, I think specifying it should be outside the
    scope of the document. mentioning it is not the same as specifying it.


    Regarding 1, the plan is to remove prefix sharing and move the ideas
    learned there with reserved IID to a specific and seperate I-D

    Regarding 2, the authors would like to mention BIH for completeness to
    provide a pointer to how the ietf has defined all stateful v4 and v6
    translation permutations, as shown in the traffic treatment table
    http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-0= 7#section-9.2

    Since this is a wg doc, we need the wg view.

    I believe Remi's text is acceptable. =A0Others' thoughts?

    http://www.ietf.org/mail-archive/web/v6ops/current/msg1= 4252.html

    CB
    _______________________________________________
    v6ops mailing list
    v6ops@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/v6ops

    --e89a8f83a16374201804c9989b85-- From lorenzo@google.com Thu Sep 13 17:46:15 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB8821F8685 for ; Thu, 13 Sep 2012 17:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.592 X-Spam-Level: X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 81T1DlJl3Nch for ; Thu, 13 Sep 2012 17:46:14 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9DAC221F866C for ; Thu, 13 Sep 2012 17:46:14 -0700 (PDT) Received: by ieak13 with SMTP id k13so6520776iea.31 for ; Thu, 13 Sep 2012 17:46:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=W8vkaessBSdTbYJoCiYOmXXAM0HHGfj64UKwKHRFL0c=; b=QHsigS8UyoKriMQRFTGzthA2jQ/hYrml7gudbK2uiKw7l1hH+XRsTjdAFvj1um0cGf ++kg08Ssu6RDkY8+NdX//702K32ggq1KX1eU+iTbyMbGM2a9We0VrCxONKeVe+t7Q3FX so3Fk8enmmq6Cw7xQhMHwt24a2vMkq9vYfIjZ8sYKWxJ83zJds44ubQEJStYOFEsL9q9 fAp/OGHdpXlwAhLMsbfpE8GyvMenwXqbhLw1+iovmBL4cyhWO7WX37tHEb3ci1AOd3yX P52su7GYDpKU4m9q1XaUhX48Uz2Pgow1YMhdPix0nx5qoGElkvHZmQEb7ReWAl6Mk+PN jQTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=W8vkaessBSdTbYJoCiYOmXXAM0HHGfj64UKwKHRFL0c=; b=ir/kL7aWVC+YJJ1kldX+VFUdHvgDw0cu87AffRUMFMHktEQrScZLSGiK9FxFPgi6YU x6055k4EMAJVEQBIeG7qSLdk6L/XxGBMyXGU3wG3F+exaqV/18MTqLFjOGaIXPOmVZDc X9lMv9r67+B2VyWtKt1iMUxQ5/9XCXAptmE4C4P5nMUlF8eUSKjYxtdn3GMV0vQlhyrT XNh9359TJvcsDaL4dFylMP4HdFj8J+mnf9nfVrodkIf/5E6hmwSvrS805Oa2Jg/yJyQi Yktj+2Y3F9WmSDF26c5aMC5mxif2HwqQ/rLmzNBXn2nOQVyc1Ms/MydtSnlQt/obhrbr 15AQ== Received: by 10.50.12.168 with SMTP id z8mr964171igb.74.1347583574185; Thu, 13 Sep 2012 17:46:14 -0700 (PDT) Received: by 10.50.12.168 with SMTP id z8mr964158igb.74.1347583573836; Thu, 13 Sep 2012 17:46:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.246.2 with HTTP; Thu, 13 Sep 2012 17:45:53 -0700 (PDT) In-Reply-To: References: From: Lorenzo Colitti Date: Fri, 14 Sep 2012 09:45:53 +0900 Message-ID: To: Hui Deng Content-Type: multipart/alternative; boundary=14dae93409b339450804c99ec0b6 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnvXX+26WmWlzn8Xd9i7mqzKiS1noZlNsSLgf2IE6o876KnAaV6XmN9kkQuE+XKp3p68lUQJl1nx1TI3LYXhaL5dj8QKdBNM0zZEJPOH6sYjyuhwYYBnuKs+LXqAKLgq8ABUwbfqhJQpXgIxFfSx0u6aNMDyuZjOIEEI+VXQclRCPU1az3y6KTk28/VlpdqxH6XFE9e Cc: IPv6 Ops WG Subject: Re: [v6ops] BIH pointer in 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 00:46:15 -0000 --14dae93409b339450804c99ec0b6 Content-Type: text/plain; charset=ISO-8859-1 I disagree. As I said before, I see no reason to mention BIH in this specification. The reason is that the suggested text provides no useful information. All it says is "you can use BIH with 464xlat if you want". This is superfluous. BIH is a standards track RFC. Operators are welcome to deploy it, either with 464xlat or without. We don't need to state that obvious fact here. If there was some useful text on *how* to integrate the two, or caveats on how *not* to integrate the two, I could see value in mentioning BIH. As it is, all we have is an advertisement for another transition method (whose applicability, as many have noted in this thread, is far in the future). As for the specific points in this email: 1. Saying "we agreed to this text in the past, so we cannot remove it now" not relevant for two reasons. First, the text was not agreed to by the WG. It was put in by the authors on the suggestion of some WG participants, but other WG participants are disagreeing to it. Secondly, if we agreed to some text in the past, but don't agree to it now, then we should change it. Internet-drafts are work in progress, and the WG must be able to change the draft as it sees fit up to the close of last call. If we don't agree on the text now, we should not shrink from removing it just to save face. 2. Saying "operators want to use BIH" is not a reason to cite BIH. If operators want to use BIH, they are free to deploy it. It's a standards track RFC. On Fri, Sep 14, 2012 at 2:26 AM, Hui Deng wrote: > For 2, I second Cameron's recommendation here. > > I don't see the reasonable exucse to change this unnormative text, and > those text which has been adopted before with the discussion. For the > operation consideration, it's quite clear that two future users > (operators) of this specification expressed they want this. > -Hui > 2012/9/13 Cameron Byrne > >> Joel wrote: >> >> >> ---------- Forwarded message ---------- >> From: joel jaeggli >> Date: Wed, Sep 12, 2012 at 6:19 PM >> Subject: Re: [v6ops] 464XLAT removing IPv6 LAN scope >> To: Lorenzo Colitti >> Cc: IPv6 Ops WG >> >> >> On 9/12/12 6:06 PM, Lorenzo Colitti wrote: >> > >> > On Thu, Sep 13, 2012 at 3:38 AM, Fred Baker (fred) > fred@cisco.com>> wrote: >> > >> > I think that there are two consensuses that we have reached. One >> > is that 464XLAT, although we still need a -08 to finalize it, >> > enjoys a rough consensus; you are the primary person objecting to >> it. >> > >> > >> > 1. Whether to ask IANA to reserve IIDs, and if so, how many (1, 2^32, >> or 2^24+2^20+2^16) >> >> with my wg chair hat off, I don't see this as desirable. >> >> > 2. Whether to mention BIH or not. >> >> again in the same role, I think specifying it should be outside the >> scope of the document. mentioning it is not the same as specifying it. >> >> >> Regarding 1, the plan is to remove prefix sharing and move the ideas >> learned there with reserved IID to a specific and seperate I-D >> >> Regarding 2, the authors would like to mention BIH for completeness to >> provide a pointer to how the ietf has defined all stateful v4 and v6 >> translation permutations, as shown in the traffic treatment table >> http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-07#section-9.2 >> >> Since this is a wg doc, we need the wg view. >> >> I believe Remi's text is acceptable. Others' thoughts? >> >> http://www.ietf.org/mail-archive/web/v6ops/current/msg14252.html >> >> CB >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --14dae93409b339450804c99ec0b6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I disagree. As I said before, I see no reason to mention BIH in this specif= ication.

    The reason is that the suggested text provides = no useful information. All it says is "you can use BIH with 464xlat if= you want". This is superfluous.=A0BIH is a standards track RFC. Opera= tors are welcome to deploy it, either with 464xlat or without. We don't= need to state that obvious fact here.=A0If there was some useful text on *= how* to integrate the two, or caveats on how *not* to integrate the two, I = could see value in mentioning BIH. As it is, all we have is an advertisemen= t for another transition method (whose applicability, as many have noted in= this thread, is far in the future).

    As for the specific points in this email:
    1. Saying "we agreed to this text in the past, so we canno= t remove it now" not relevant for two reasons. First, the text was not= agreed to by the WG. It was put in by the authors on the suggestion of som= e WG participants, but other WG participants are disagreeing to it. Secondl= y, if we agreed to some text in the past, but don't agree to it now, th= en we should change it. Internet-drafts are work in progress, and the WG mu= st be able to change the draft as it sees fit up to the close of last call.= If we don't agree on the text now, we should not shrink from removing = it just to save face.

    2. Saying "operators want to use BIH&quo= t; is not a reason to cite BIH. If operators want to use BIH, they are free= to deploy it. It's a standards track RFC.

    On Fri, Sep 14, 2012 at 2:26 AM, Hui Deng <denghui02@gmail.com> wrote:
    For 2, I second Cameron's recommendation here.
    =A0
    =
    I don't see the reasonable exucse to change this=A0unnormative tex= t, and those text=A0which has been adopted before with the discussion. For = the operation consideration, it's quite clear that two future users (op= erators)=A0of this specification expressed they want this.
    -Hu= i
    2012/9/13 Cameron Byrne <cb.list6@gmail.com>
    Joel wrote:


    ---------- Forwarded message ----------
    From: joel jaeggli <joelja@bogus.com>
    Date: Wed, Sep 12, 2012 at 6:19 PM
    Subject: Re: [v6ops] 464XLAT removing IPv6 LAN scope
    To: Lorenzo Colitti <lorenzo@google.com>
    Cc: IPv6 Ops WG <v6o= ps@ietf.org>


    On 9/12/12 6:06 PM, Lorenzo Colitti wrote:
    >
    > On Thu, Sep 13, 2012 at 3:38 AM, Fred Baker (fred) <fred@cisco.com <mailto:fred@cisco.com>> wro= te:
    >
    > =A0 =A0 I think that there are two consensuses that we have reached. O= ne
    > =A0 =A0 is that 464XLAT, although we still need a -08 to finalize it,<= br> > =A0 =A0 enjoys a rough consensus; you are the primary person objecting= to it.
    >
    >
    > 1. Whether to ask IANA to reserve IIDs, and if so, how many (1, 2^32, = or 2^24+2^20+2^16)

    with my wg chair hat off, I don't see this as desirable.

    > 2. Whether to mention BIH or not.

    again in the same role, I think specifying it should be outside the
    scope of the document. mentioning it is not the same as specifying it.


    Regarding 1, the plan is to remove prefix sharing and move the ideas
    learned there with reserved IID to a specific and seperate I-D

    Regarding 2, the authors would like to mention BIH for completeness to
    provide a pointer to how the ietf has defined all stateful v4 and v6
    translation permutations, as shown in the traffic treatment table
    http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-0= 7#section-9.2

    Since this is a wg doc, we need the wg view.

    I believe Remi's text is acceptable. =A0Others' thoughts?

    http://www.ietf.org/mail-archive/web/v6ops/current/msg1= 4252.html

    CB
    _______________________________________________
    v6ops mailing list
    v6ops@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/v6ops


    _______________________________________________
    v6ops mailing list
    v6ops@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/v6ops


    --14dae93409b339450804c99ec0b6-- From phdgang@gmail.com Thu Sep 13 20:53:18 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F276521F86B9 for ; Thu, 13 Sep 2012 20:53:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.15 X-Spam-Level: X-Spam-Status: No, score=-3.15 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qDl42k-5qEt0 for ; Thu, 13 Sep 2012 20:53:17 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0467E21F86B8 for ; Thu, 13 Sep 2012 20:53:16 -0700 (PDT) Received: by vbbfc26 with SMTP id fc26so4842655vbb.31 for ; Thu, 13 Sep 2012 20:53:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=I0BJWDXW21AmpwMMvLnYjSdYocw5D7fHzIHHa7bKla8=; b=cwX9wJyuWUA9a0Gnqa9chC8He5DAj+zpaRc1uyJo0+zQLDzOYxg5CaZvN9ACsA0+U8 Hp/PdXrsGuBOGQOhSMr7reun5sIDMyW7J51f50MrRaWK1yOQAOQxAF21eVkA2SsnfTgp UpZeSXl8C06QyNCCXR6EOhvBLEjWnXEFTkvsfC3ZAy9hThriy/MQ+NjEc+Mi1RMwHvn5 oK7k2BLIMrpSW+uqSz8R22VZJwlLUQt0N+3irRR02gg79W3ev703ogxTu90tbCVrNErS atlDMJ31b6vtiyM+GEVUJ06h3/CNzGWEdSVFLdDDnt5T/miGkqnMA4I3KGgDOLoGxfN4 9BQA== MIME-Version: 1.0 Received: by 10.220.153.142 with SMTP id k14mr929364vcw.7.1347594796168; Thu, 13 Sep 2012 20:53:16 -0700 (PDT) Received: by 10.58.114.231 with HTTP; Thu, 13 Sep 2012 20:53:16 -0700 (PDT) In-Reply-To: References: Date: Fri, 14 Sep 2012 11:53:16 +0800 Message-ID: From: GangChen To: Lorenzo Colitti Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Ops WG Subject: Re: [v6ops] BIH pointer in 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 03:53:18 -0000 Your statement just helps to confirm the divergence from original texts is unreasonable, but the draft needs to progress. Every time you say "disagree", there are plenty of technical answers provided to clarify. However, whatever we said you just ignore it without justifications and definitely would say *I disagree* in next time, like you said *I don't think "restarting the discussion" is going to help convince me * I don't want to manage to convince you. But your statement below somehow lets me think what you have described is FUD, and you suggest that because "we cannot have it, since somebody would take the advantage of advertisement". I have no idea of the "advertisement", but the truth is the draft originally covers the table and would like to fill out it. Afterwards, a participant (no business with "advertisement" intention) technically proposed the RFC6535 fill the gap. And the authors agreed and you acquiesce it (at lease it doesn't matter to you). Some operators who doing those things see such chance and put efforts like to progress the work better. But last minute, you say "Stop it, don't do the thing". Saying "If there was some useful text on *how* to integrate the two, or caveats on how *not* to integrate the two, I could see value in mentioning BIH.=94 It's worth to note current words are actually coming from your suggestion http://www.ietf.org/mail-archive/web/v6ops/current/msg14200.html. What have to say already sufficiently clarified after the intensive discussions. Leaving aside the operators things and all FUD, please note people just want to fill out the table technically using IETF technology. This table was appeared since draft-00. And people who want adoptions of 464xlat really expect the progress. Many thanks Gang 2012/9/14, Lorenzo Colitti : > I disagree. As I said before, I see no reason to mention BIH in this > specification. > > The reason is that the suggested text provides no useful information. All > it says is "you can use BIH with 464xlat if you want". This is > superfluous. BIH is a standards track RFC. Operators are welcome to deplo= y > it, either with 464xlat or without. We don't need to state that obvious > fact here. If there was some useful text on *how* to integrate the two, o= r > caveats on how *not* to integrate the two, I could see value in mentionin= g > BIH. As it is, all we have is an advertisement for another transition > method (whose applicability, as many have noted in this thread, is far in > the future). > > As for the specific points in this email: > > 1. Saying "we agreed to this text in the past, so we cannot remove it now= " > not relevant for two reasons. First, the text was not agreed to by the WG= . > It was put in by the authors on the suggestion of some WG participants, b= ut > other WG participants are disagreeing to it. Secondly, if we agreed to so= me > text in the past, but don't agree to it now, then we should change it. > Internet-drafts are work in progress, and the WG must be able to change t= he > draft as it sees fit up to the close of last call. If we don't agree on t= he > text now, we should not shrink from removing it just to save face. > > 2. Saying "operators want to use BIH" is not a reason to cite BIH. If > operators want to use BIH, they are free to deploy it. It's a standards > track RFC. > > On Fri, Sep 14, 2012 at 2:26 AM, Hui Deng wrote: > >> For 2, I second Cameron's recommendation here. >> >> I don't see the reasonable exucse to change this unnormative text, and >> those text which has been adopted before with the discussion. For the >> operation consideration, it's quite clear that two future users >> (operators) of this specification expressed they want this. >> -Hui >> 2012/9/13 Cameron Byrne >> >>> Joel wrote: >>> >>> >>> ---------- Forwarded message ---------- >>> From: joel jaeggli >>> Date: Wed, Sep 12, 2012 at 6:19 PM >>> Subject: Re: [v6ops] 464XLAT removing IPv6 LAN scope >>> To: Lorenzo Colitti >>> Cc: IPv6 Ops WG >>> >>> >>> On 9/12/12 6:06 PM, Lorenzo Colitti wrote: >>> > >>> > On Thu, Sep 13, 2012 at 3:38 AM, Fred Baker (fred) >>> > >> fred@cisco.com>> wrote: >>> > >>> > I think that there are two consensuses that we have reached. One >>> > is that 464XLAT, although we still need a -08 to finalize it, >>> > enjoys a rough consensus; you are the primary person objecting to >>> it. >>> > >>> > >>> > 1. Whether to ask IANA to reserve IIDs, and if so, how many (1, 2^32, >>> or 2^24+2^20+2^16) >>> >>> with my wg chair hat off, I don't see this as desirable. >>> >>> > 2. Whether to mention BIH or not. >>> >>> again in the same role, I think specifying it should be outside the >>> scope of the document. mentioning it is not the same as specifying it. >>> >>> >>> Regarding 1, the plan is to remove prefix sharing and move the ideas >>> learned there with reserved IID to a specific and seperate I-D >>> >>> Regarding 2, the authors would like to mention BIH for completeness to >>> provide a pointer to how the ietf has defined all stateful v4 and v6 >>> translation permutations, as shown in the traffic treatment table >>> http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-07#section-9.2 >>> >>> Since this is a wg doc, we need the wg view. >>> >>> I believe Remi's text is acceptable. Others' thoughts? >>> >>> http://www.ietf.org/mail-archive/web/v6ops/current/msg14252.html >>> >>> CB >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> >> > From lorenzo@google.com Thu Sep 13 21:01:27 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5224D21F86C6 for ; Thu, 13 Sep 2012 21:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.884 X-Spam-Level: X-Spam-Status: No, score=-102.884 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2BHTDHwfof9A for ; Thu, 13 Sep 2012 21:01:26 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id C187921F86B8 for ; Thu, 13 Sep 2012 21:01:26 -0700 (PDT) Received: by ieak13 with SMTP id k13so6724782iea.31 for ; Thu, 13 Sep 2012 21:01:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=C9boCWS+fAjHw0Lw3yTOjA6vINcaErmtVikxhISNa74=; b=aiqa2M3xZKFhIvllCCTWe49hFGnki0bRnhmfUIALSfyOmx2Nu1RFE/uVn6AJ9ArG2Y IyJ9cck1fcrIwTilXedSGoeNiXo9/db83m4lPkZUp6hKmgZJJrRNKuK6RKJdo+o5QZlP PyNw3dM7N6TMqQwlFbKr9lxQ6tZCU9V+n9hp7fZ0t6FW9QXyekCvuMMszyIkLqFifrE/ JRYo6GgVlBfJkFEXKN53Ca1pCsnNT3n6sp5CV03SnyC1gL6wf8CCoz8HuimmNYkyj0li WOaX8nzjlA+kmunJFJNy3NHoA9SVM4aPEb+EE4+LTBnlIbwBXws9hJe/t8jn/4xZl4XD RXhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=C9boCWS+fAjHw0Lw3yTOjA6vINcaErmtVikxhISNa74=; b=GLYIpT9of8AkT/wdQOGHlMlECwP0cum2rFxIc6hIX4Ex1aouMTPNjAgANhZohEVSMm Jdrk9buKqlvu2v6S/HoFF+ZXOkJwc7etjIW/SAC90Ch+zfueqf3yywQoAE2HbJucog0Q RpExvbYgkpkmrFiSELQzuDTZUBDnHNTYez/LAGX3kVzKIZYwKLk5SoBVqYXcvmbWQsMJ G4NHMM6m6D5rtLK1pQbgz9vsgevJTfFhqlyLZhyxY0DeALaMwllhXVriPmCLUFP2XFym MvTPxSHJV1u7f7GkZGcjlvazMupFoPmY6EspKsR9BaRzMiziCnHOcBepul6UMpO/pJ2p 3VHg== Received: by 10.50.95.230 with SMTP id dn6mr1448161igb.16.1347595286227; Thu, 13 Sep 2012 21:01:26 -0700 (PDT) Received: by 10.50.95.230 with SMTP id dn6mr1448149igb.16.1347595286058; Thu, 13 Sep 2012 21:01:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.246.2 with HTTP; Thu, 13 Sep 2012 21:01:05 -0700 (PDT) In-Reply-To: References: From: Lorenzo Colitti Date: Fri, 14 Sep 2012 13:01:05 +0900 Message-ID: To: joel jaeggli , Fred Baker Content-Type: multipart/alternative; boundary=e89a8f23438b53951704c9a17a54 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlXYyZSRlTDRkKdGOgIVaKeedf2Zpyn71nF6cYStzvxvKm6MPHPRRPaugxXmBnChEwq6P76tpZsCEmUfsAiu5iHl7W8SEKiMh5Yr4+WnjzkJpQ75PKgWor8GpQ4iQjZml8Eufdto5lwEVuNii/q7ps5V6GggB2zISOWQYOnaiQw7IbM7jdLo0m/d359mJy0MIrXe1Xn Cc: IPv6 Ops WG Subject: Re: [v6ops] BIH pointer in 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 04:01:27 -0000 --e89a8f23438b53951704c9a17a54 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Sep 14, 2012 at 12:53 PM, GangChen wrote: > What have to say already sufficiently clarified after the intensive > discussions. Ok then. Let's stop this discussion and ask the chairs to gauge whether they see consensus on this. If the chairs say they think there is, then we can all shut up and move on. Fred, Joel: is it your determination as chairs that there is consensus within the WG to include mention of BIH in this document? Cheers, Lorenzo --e89a8f23438b53951704c9a17a54 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Sep 14, 2012 at 12:53 PM, GangChen <phdgang@gmail.com> wrote:
    What have to say already sufficiently clarified after the intensive
    discussions.

    Ok then. Let's stop this d= iscussion and ask the chairs to gauge whether they see consensus on this. I= f the chairs say they think there is, then we can all shut up and move on.<= /div>

    Fred, Joel: is it your determination as chairs that the= re is consensus within the WG to include mention of BIH in this document?

    Cheers,
    Lorenzo
    --e89a8f23438b53951704c9a17a54-- From phdgang@gmail.com Thu Sep 13 22:03:12 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 898F321F84D2 for ; Thu, 13 Sep 2012 22:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.445 X-Spam-Level: X-Spam-Status: No, score=-3.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xc+TFY+Fyzn6 for ; Thu, 13 Sep 2012 22:03:11 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9067321F8621 for ; Thu, 13 Sep 2012 22:03:11 -0700 (PDT) Received: by vbbfc26 with SMTP id fc26so4885114vbb.31 for ; Thu, 13 Sep 2012 22:03:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rrGHZ8ie1agNkoWaeZIIO+fQYzD6TwPCW/Oi+OXTHe4=; b=nMASQYEmtMikuyd4KTTf4t+ECaTxv27v6J9tHaXXOJ0LLIUM8LMoo3jB4/R95iXtRr kVKdgztA99eKPwVIgXcLU8VCijCAJSaGBI4EQp1NmWbBlQEIO8lpHsWHCHWH1nUVvYRR LsWsVMGkYS/GovXlaV3STr2vOO+qjdc0s/6U+G9oaRbeEfdV7XEWh6OG36qRcR57OuYE /tuUsg1Hs+Si+ZE4+wKEIPlxqSZTOFwM9xMBha5ajIHpmq514zLovIOuSjwccd4GtN8q fKce4BTnQSI35LWzOp+XJnUXqxwi7yM2OdGFM3PVaLHxbZERZiN/bhrWj6PMw56Xzvx9 CYng== MIME-Version: 1.0 Received: by 10.58.102.48 with SMTP id fl16mr992255veb.41.1347598990763; Thu, 13 Sep 2012 22:03:10 -0700 (PDT) Received: by 10.58.114.231 with HTTP; Thu, 13 Sep 2012 22:03:10 -0700 (PDT) In-Reply-To: References: Date: Fri, 14 Sep 2012 13:03:10 +0800 Message-ID: From: GangChen To: Lorenzo Colitti Content-Type: text/plain; charset=ISO-8859-1 Cc: IPv6 Ops WG Subject: Re: [v6ops] BIH pointer in 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 05:03:12 -0000 2012/9/14, Lorenzo Colitti : > On Fri, Sep 14, 2012 at 12:53 PM, GangChen wrote: > >> What have to say already sufficiently clarified after the intensive >> discussions. > > > Ok then. Let's stop this discussion and ask the chairs to gauge whether > they see consensus on this. If the chairs say they think there is, then we > can all shut up and move on. > > Fred, Joel: is it your determination as chairs that there is consensus > within the WG to include mention of BIH in this document? To be fair, the questions should be 1) Is consensus within the WG to keep the mention of BIH in this document? 2) Is consensus within the WG to remove the mention of BIH in this document? Best Regards Gang > Cheers, > Lorenzo > From randy@psg.com Thu Sep 13 22:20:49 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27C2E21F86EF for ; Thu, 13 Sep 2012 22:20:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3hZZpW9xZZzl for ; Thu, 13 Sep 2012 22:20:48 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id AA7D921F86EC for ; Thu, 13 Sep 2012 22:20:48 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80 (FreeBSD)) (envelope-from ) id 1TCOKb-000My0-6R; Fri, 14 Sep 2012 05:20:45 +0000 Date: Fri, 14 Sep 2012 14:20:44 +0900 Message-ID: From: Randy Bush To: Lorenzo Colitti In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: IPv6 Ops WG Subject: Re: [v6ops] BIH pointer in 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 05:20:49 -0000 >> What have to say already sufficiently clarified after the intensive >> discussions. > > Ok then. Let's stop this discussion and ask the chairs to gauge whether > they see consensus on this. -1 to the bih text, does not make an already complex subject easier to understand randy From tjc@ecs.soton.ac.uk Thu Sep 13 23:54:54 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0A1F21F84FD for ; Thu, 13 Sep 2012 23:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.727 X-Spam-Level: X-Spam-Status: No, score=-1.727 tagged_above=-999 required=5 tests=[AWL=-0.523, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wpxye6VXnhMt for ; Thu, 13 Sep 2012 23:54:54 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id D2D2921F84FC for ; Thu, 13 Sep 2012 23:54:53 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q8E6sj9L030739; Fri, 14 Sep 2012 07:54:45 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk q8E6sj9L030739 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1347605686; bh=dMOzXi4Tj6X/5UM+297vjhJQH+I=; h=References:In-Reply-To:Mime-Version:Cc:From:Subject:Date:To; b=q4kdXk7J3VdaR1MTD+5ehP7O2Qnxd7kWMBRdqBTypKGeHg6ZFlHACEHmxeBcWALPd tan+g3yAOg4ms+r5HO0mCrUgQXI9JvyF9icHU4PXaQBnX7nMLd09dVlFZIt8qyLzz6 yeEumDoIOLDkoea7BMHdOt66SEze+430R9DtrSuI= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id o8D7sj0430642750YN ret-id none; Fri, 14 Sep 2012 07:54:46 +0100 Received: from [192.168.1.101] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q8E6sf6O003003 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 14 Sep 2012 07:54:42 +0100 References: <91A2FBD2-4BDB-4712-95E4-5D2B1EB9A0C6@ecs.soton.ac.uk> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-ID: X-Mailer: iPad Mail (9B206) From: Tim Chown Date: Fri, 14 Sep 2012 07:55:58 +0100 To: Lorenzo Colitti X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=o8D7sj043064275000; tid=o8D7sj0430642750YN; client=relay,ipv6; mail=; rcpt=; nrcpt=3:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: q8E6sj9L030739 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: IPv6 Ops WG Subject: Re: [v6ops] BIH pointer in 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 06:54:54 -0000 On 14 Sep 2012, at 01:45, Lorenzo Colitti wrote: > I disagree. As I said before, I see no reason to mention BIH in this speci= fication. +1 Were this text Informational, I would be more relaxed about mentioning BIH, b= ut since it's a BCP the bar to include such references should be much higher= . Hence my suggestion to write a separate Informational text on the applicabil= ity of BIH - and perhaps other alternatives - in this context. Tim= From denghui02@gmail.com Fri Sep 14 00:06:30 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6441621F85ED for ; Fri, 14 Sep 2012 00:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.877 X-Spam-Level: X-Spam-Status: No, score=-101.877 tagged_above=-999 required=5 tests=[AWL=-0.679, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_82=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-lz63umC12n for ; Fri, 14 Sep 2012 00:06:29 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4222021F85EA for ; Fri, 14 Sep 2012 00:06:29 -0700 (PDT) Received: by qcac10 with SMTP id c10so3009135qca.31 for ; Fri, 14 Sep 2012 00:06:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WOncg3l7NarP4qWX0hcAT2xjYGwkeo7+SE+qLpPm9bI=; b=Cz1a7MbJ6ch7ee7Wrt/QTh/QirWeLlclpvRTbrt9b/ZOUOCBkpUFCONmzjLvOOg3jD 1KgNd8yBQf50tld1lg/WPOzmBIJMUpawDrgke48m4SrWjX/Aum6wD1WEqXqSPy7tO6TE ao8vlUU08UZJZHtWL3VZa7S4Nl24VxmXyPYpiL9iXqUMcSUgeAh3WAqxG9xNkMs2JhnO UZt+toELPs14mHyNNT7ocpuSiTVe2WJkIp0/SSI4mJWtv4gfOtQEmWTttTd3OalANRpv u8dO6UTjItwCyYPhUT50zu07V8fP4XxHp4Da79q+IJ67YvEmQv3e6BzE6FQlq2a+o7CE xZfA== MIME-Version: 1.0 Received: by 10.224.200.130 with SMTP id ew2mr5006510qab.92.1347606388521; Fri, 14 Sep 2012 00:06:28 -0700 (PDT) Received: by 10.49.49.3 with HTTP; Fri, 14 Sep 2012 00:06:28 -0700 (PDT) In-Reply-To: References: Date: Fri, 14 Sep 2012 08:06:28 +0100 Message-ID: From: Hui Deng To: Lorenzo Colitti Content-Type: multipart/alternative; boundary=20cf300fac8b15bad804c9a410bc Cc: IPv6 Ops WG Subject: Re: [v6ops] BIH pointer in 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 07:06:30 -0000 --20cf300fac8b15bad804c9a410bc Content-Type: text/plain; charset=ISO-8859-1 I am the only author of BIH discussing here, guess Cameron and Remi are not, advertisement is overstated and may not be appropriate here. And the only real users of those specification had said they want this. I would expect others's comment would better "if you don't use this, please dont' comment on this unnormative text here" I agree " If there was some useful text on *how* to integrate the two, or caveats on how *not* to integrate the two, " Here is proposal: When 464xlat integrates with other IPv6only access transition technology such as BIH, IPv4-only app with BIHprocessing could communicate with IPv6-server. A DNS query initiated by theapplication would be processed by BIH ENR to generate both A and AAAA and needsconsidering below 1) When A responses are received, 464xlatwould take the role 2) When A and AAAA responses are received,464xlat would take the role 3) When only AAAA responses are received,it's the case of IPv4-IPv6 communication. ENR embedded in BIH would interceptsAAAA records and create the synthetic IPv4 address and corresponding themapping. Afterwards, IPv4 applications send the packages to the synthetic IPv4address. Protocol translator would take the rule of IPv4-IPv6 translation andachieve IPv4-IPv6 communication. I am in the business trip out of China and will take long time flight shortly, so may not reply in time. thanks a lot -Hui 2012/9/14 Lorenzo Colitti > I disagree. As I said before, I see no reason to mention BIH in this > specification. > > The reason is that the suggested text provides no useful information. All > it says is "you can use BIH with 464xlat if you want". This is > superfluous. BIH is a standards track RFC. Operators are welcome to deploy > it, either with 464xlat or without. We don't need to state that obvious > fact here. If there was some useful text on *how* to integrate the two, or > caveats on how *not* to integrate the two, I could see value in mentioning > BIH. As it is, all we have is an advertisement for another transition > method (whose applicability, as many have noted in this thread, is far in > the future). > > As for the specific points in this email: > > 1. Saying "we agreed to this text in the past, so we cannot remove it now" > not relevant for two reasons. First, the text was not agreed to by the WG. > It was put in by the authors on the suggestion of some WG participants, but > other WG participants are disagreeing to it. Secondly, if we agreed to some > text in the past, but don't agree to it now, then we should change it. > Internet-drafts are work in progress, and the WG must be able to change the > draft as it sees fit up to the close of last call. If we don't agree on the > text now, we should not shrink from removing it just to save face. > > 2. Saying "operators want to use BIH" is not a reason to cite BIH. If > operators want to use BIH, they are free to deploy it. It's a standards > track RFC. > > On Fri, Sep 14, 2012 at 2:26 AM, Hui Deng wrote: > >> For 2, I second Cameron's recommendation here. >> >> I don't see the reasonable exucse to change this unnormative text, and >> those text which has been adopted before with the discussion. For the >> operation consideration, it's quite clear that two future users >> (operators) of this specification expressed they want this. >> -Hui >> 2012/9/13 Cameron Byrne >> >>> Joel wrote: >>> >>> >>> ---------- Forwarded message ---------- >>> From: joel jaeggli >>> Date: Wed, Sep 12, 2012 at 6:19 PM >>> Subject: Re: [v6ops] 464XLAT removing IPv6 LAN scope >>> To: Lorenzo Colitti >>> Cc: IPv6 Ops WG >>> >>> >>> On 9/12/12 6:06 PM, Lorenzo Colitti wrote: >>> > >>> > On Thu, Sep 13, 2012 at 3:38 AM, Fred Baker (fred) >> fred@cisco.com>> wrote: >>> > >>> > I think that there are two consensuses that we have reached. One >>> > is that 464XLAT, although we still need a -08 to finalize it, >>> > enjoys a rough consensus; you are the primary person objecting to >>> it. >>> > >>> > >>> > 1. Whether to ask IANA to reserve IIDs, and if so, how many (1, 2^32, >>> or 2^24+2^20+2^16) >>> >>> with my wg chair hat off, I don't see this as desirable. >>> >>> > 2. Whether to mention BIH or not. >>> >>> again in the same role, I think specifying it should be outside the >>> scope of the document. mentioning it is not the same as specifying it. >>> >>> >>> Regarding 1, the plan is to remove prefix sharing and move the ideas >>> learned there with reserved IID to a specific and seperate I-D >>> >>> Regarding 2, the authors would like to mention BIH for completeness to >>> provide a pointer to how the ietf has defined all stateful v4 and v6 >>> translation permutations, as shown in the traffic treatment table >>> http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-07#section-9.2 >>> >>> Since this is a wg doc, we need the wg view. >>> >>> I believe Remi's text is acceptable. Others' thoughts? >>> >>> http://www.ietf.org/mail-archive/web/v6ops/current/msg14252.html >>> >>> CB >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> >> > --20cf300fac8b15bad804c9a410bc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    I am the only author of BIH discussing here, guess Cameron and Remi ar= e not, advertisement is overstated and may=A0not be=A0appropriate here. And= the only real users of those specification had said they want this. I woul= d expect=A0others's comment would better "if you don't use thi= s, please dont' comment on this unnormative text here"
    =A0
    I agree " If there was some useful text on *how* to= integrate the two, or caveats on how *not* to integrate the two, "Here is proposal:
    =A0
    When 464xlat integrates with oth= er IPv6only access transition technology such as BIH, IPv4-only app with BI= Hprocessing could communicate with IPv6-server. A DNS query initiated by th= eapplication would be processed by BIH ENR to generate both A and AAAA and = needsconsidering below

    1) When A responses are received, 464xlatwould take the role
    2) Whe= n A and AAAA responses are received,464xlat would take the role
    3) When = only AAAA responses are received,it's the case of IPv4-IPv6 communicati= on. ENR embedded in BIH would interceptsAAAA records and create the synthet= ic IPv4 address and corresponding themapping. Afterwards, IPv4 applications= send the packages to the synthetic IPv4address. Protocol translator would = take the rule of IPv4-IPv6 translation andachieve IPv4-IPv6 communication.<= br> =A0
    I am in the business trip out of China and will take long time fligh= t shortly, so may not reply in time.
    =A0
    thanks a lot
    =A0
    -Hui
    =A0
    2= 012/9/14 Lorenzo Colitti <lorenzo@google.com>
    I disagree. As I said before, I see no reason to mention B= IH in this specification.

    The reason is that the suggested text provides no useful inf= ormation. All it says is "you can use BIH with 464xlat if you want&quo= t;. This is superfluous.=A0BIH is a standards track RFC. Operators are welc= ome to deploy it, either with 464xlat or without. We don't need to stat= e that obvious fact here.=A0If there was some useful text on *how* to integ= rate the two, or caveats on how *not* to integrate the two, I could see val= ue in mentioning BIH. As it is, all we have is an advertisement for another= transition method (whose applicability, as many have noted in this thread,= is far in the future).

    As for the specific points in this email:
    1. Saying "we agreed to this text in the past, so we canno= t remove it now" not relevant for two reasons. First, the text was not= agreed to by the WG. It was put in by the authors on the suggestion of som= e WG participants, but other WG participants are disagreeing to it. Secondl= y, if we agreed to some text in the past, but don't agree to it now, th= en we should change it. Internet-drafts are work in progress, and the WG mu= st be able to change the draft as it sees fit up to the close of last call.= If we don't agree on the text now, we should not shrink from removing = it just to save face.

    2. Saying "operators want to use BIH&quo= t; is not a reason to cite BIH. If operators want to use BIH, they are free= to deploy it. It's a standards track RFC.

    On Fri, Sep 14, 2012 at 2:26 AM, Hui Deng <denghui02@gmail.com> wrote:
    For 2, I second Cameron's recommendation here.
    =A0
    =
    I don't see the reasonable exucse to change this=A0unnormative tex= t, and those text=A0which has been adopted before with the discussion. For = the operation consideration, it's quite clear that two future users (op= erators)=A0of this specification expressed they want this.
    -Hui
    2012/9/13 Cameron Byrne <cb.= list6@gmail.com>
    Joel wrote:


    ---------- Forwarded message ----------
    From: joel jaeggli <joelja@bogus.com>
    Date: Wed, Sep 12, 2012 at 6:19 PM
    Subject: Re: [v6ops] 464XLAT removing IPv6 LAN scope
    To: Lorenzo Colitti <lorenzo@google.com>
    Cc: IPv6 Ops WG <v6o= ps@ietf.org>


    On 9/12/12 6:06 PM, Lorenzo Colitti wrote:
    >
    > On Thu, Sep 13, 2012 at 3:38 AM, Fred Baker (fred) <fred@cisco.com <mailto:fred@cisco.com>> wro= te:
    >
    > =A0 =A0 I think that there are two consensuses that we have reached. O= ne
    > =A0 =A0 is that 464XLAT, although we still need a -08 to finalize it,<= br> > =A0 =A0 enjoys a rough consensus; you are the primary person objecting= to it.
    >
    >
    > 1. Whether to ask IANA to reserve IIDs, and if so, how many (1, 2^32, = or 2^24+2^20+2^16)

    with my wg chair hat off, I don't see this as desirable.

    > 2. Whether to mention BIH or not.

    again in the same role, I think specifying it should be outside the
    scope of the document. mentioning it is not the same as specifying it.


    Regarding 1, the plan is to remove prefix sharing and move the ideas
    learned there with reserved IID to a specific and seperate I-D

    Regarding 2, the authors would like to mention BIH for completeness to
    provide a pointer to how the ietf has defined all stateful v4 and v6
    translation permutations, as shown in the traffic treatment table
    http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-0= 7#section-9.2

    Since this is a wg doc, we need the wg view.

    I believe Remi's text is acceptable. =A0Others' thoughts?

    http://www.ietf.org/mail-archive/web/v6ops/current/msg1= 4252.html

    CB
    _______________________________________________
    v6ops mailing list
    v6ops@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/v6ops


    _______________________________________________
    v6ops mailing list
    v6ops@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/v6ops



    --20cf300fac8b15bad804c9a410bc-- From lorenzo@google.com Fri Sep 14 00:22:36 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F9D921F84F6 for ; Fri, 14 Sep 2012 00:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.987 X-Spam-Level: X-Spam-Status: No, score=-101.987 tagged_above=-999 required=5 tests=[AWL=-0.811, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_82=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x4UkWSxrvIed for ; Fri, 14 Sep 2012 00:22:36 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id DBFD521F8528 for ; Fri, 14 Sep 2012 00:22:35 -0700 (PDT) Received: by oagk14 with SMTP id k14so2867628oag.31 for ; Fri, 14 Sep 2012 00:22:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=5UIEZqQpai+QAqjr4zHZH4w8dUodHxjTBEri0GHeCrA=; b=I/CAM8uj+9aeGUwn5sZT2KYfPb3srv/p/Vs6pV2040Bbu733+rlFDk1eOM2sRHgRp+ rnGAPPz97d68evAGXBkeYQu41TDboM29HsIT2XTASrjbBYONGY4DKwiuwJk3DrpCTB/t GQF1YIbcGZtE1W1R0UDO3MlKGJCoOPzvWfbiVooW7LDHD1J+P3DjfkxEvKmQJVdIsBF7 QHC661KF8C2KZltjfw9H+iwJhpK1zA7yuS+0r2hHN3p5RT07i7O+gypfixsJhDTqSNTp jBh2OW3PdjyRTXxIrBvapNy9CJ7F1josXtPmVW2Teg0mxzU/jmMZ1z0kaBbL3nusFP5x b1OA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=5UIEZqQpai+QAqjr4zHZH4w8dUodHxjTBEri0GHeCrA=; b=RkmMXi1s+JOEiHUd1YyvUV798Gg19fe9GoFFqn/yTqVFIwDPfPjgRTitIY+7GEil5s syYjd+0V5ZvFUcOZaEwp5hj6myQ5KrL0Po97uEl3TRCpqk9RTPVkeP/eQGHw1jdHejPL B/VnYFmsJUIcD5YVoQnepUFmoiz9eiymit1PWgQhuMq8IJFhdRdAU5nhUJYC0vbjVZI0 AAsC2G8apf/h5lrT7nlaU88yU6jTAB00pJBIaRKAuyfsO+EWCxBnkQRAYFg+ATQlkRVn oWbXoG71BJq0JsefavaVhTYjhN3PvwyiFM81WNy9EYRNRNEtwh3vVsvSuwZY4LjEvYUd 5ZAQ== Received: by 10.60.29.134 with SMTP id k6mr1780268oeh.5.1347607355295; Fri, 14 Sep 2012 00:22:35 -0700 (PDT) Received: by 10.60.29.134 with SMTP id k6mr1780254oeh.5.1347607355116; Fri, 14 Sep 2012 00:22:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.237.6 with HTTP; Fri, 14 Sep 2012 00:22:14 -0700 (PDT) In-Reply-To: References: From: Lorenzo Colitti Date: Fri, 14 Sep 2012 16:22:14 +0900 Message-ID: To: Hui Deng Content-Type: multipart/alternative; boundary=e89a8fb200f4b2cc9904c9a449ce X-System-Of-Record: true X-Gm-Message-State: ALoCoQmtO2nkqUo88kding7mzrPcEmnsKsiHXLn7PIuB00NBRSQu6ShBkQNbwxKO8OisDzVV3i4eud92I3ErnQ15UyR0F1YWg4kwJqvlZlRz+FPuNMm/dl0PF/0i/UQhyfxijf3FQyAB+pvIhjZeK2dFZjdiJoX8Sy4c1g9TNsWJkL3mgqJJF7Z1Qemo7Bp4lpj6mc7l8xnc Cc: IPv6 Ops WG Subject: Re: [v6ops] BIH pointer in 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 07:22:36 -0000 --e89a8fb200f4b2cc9904c9a449ce Content-Type: text/plain; charset=ISO-8859-1 On Fri, Sep 14, 2012 at 4:06 PM, Hui Deng wrote: > When 464xlat integrates with other IPv6only access transition technology > such as BIH, IPv4-only app with BIHprocessing could communicate with > IPv6-server. A DNS query initiated by theapplication would be processed by > BIH ENR to generate both A and AAAA and needsconsidering below > > 1) When A responses are received, 464xlatwould take the role > 2) When A and AAAA responses are received,464xlat would take the role > 3) When only AAAA responses are received,it's the case of IPv4-IPv6 > communication. ENR embedded in BIH would interceptsAAAA records and create > the synthetic IPv4 address and corresponding themapping. Afterwards, IPv4 > applications send the packages to the synthetic IPv4address. Protocol > translator would take the rule of IPv4-IPv6 translation andachieve > IPv4-IPv6 communication. > Has this been tested and verified to work? Is there an implementation? We should not include text in a BCP if it has never been implemented or tested. --e89a8fb200f4b2cc9904c9a449ce Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Sep 14, 2012 at 4:06 PM, Hui Deng <denghui02@gmail.com> wrote:
    When 464xlat integrates with other IPv6only access transition technolo= gy such as BIH, IPv4-only app with BIHprocessing could communicate with IPv= 6-server. A DNS query initiated by theapplication would be processed by BIH= ENR to generate both A and AAAA and needsconsidering below

    1) When A responses are received, 464xlatwould take the role
    2) Whe= n A and AAAA responses are received,464xlat would take the role
    3) When = only AAAA responses are received,it's the case of IPv4-IPv6 communicati= on. ENR embedded in BIH would interceptsAAAA records and create the synthet= ic IPv4 address and corresponding themapping. Afterwards, IPv4 applications= send the packages to the synthetic IPv4address. Protocol translator would = take the rule of IPv4-IPv6 translation andachieve IPv4-IPv6 communication.<= br>

    Has this been tested and verified to= work? Is there an implementation?

    We should not i= nclude text in a BCP if it has never been implemented or tested.
    --e89a8fb200f4b2cc9904c9a449ce-- From despres.remi@laposte.net Fri Sep 14 00:37:51 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5875E21F854A for ; Fri, 14 Sep 2012 00:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.36 X-Spam-Level: X-Spam-Status: No, score=-0.36 tagged_above=-999 required=5 tests=[AWL=-0.812, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_82=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7oKGEv5Bg+8F for ; Fri, 14 Sep 2012 00:37:50 -0700 (PDT) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.3]) by ietfa.amsl.com (Postfix) with ESMTP id 446DF21F8528 for ; Fri, 14 Sep 2012 00:37:50 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2111.sfr.fr (SMTP Server) with ESMTP id 1E313700089A; Fri, 14 Sep 2012 09:37:49 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2111.sfr.fr (SMTP Server) with ESMTP id ABF6D7000898; Fri, 14 Sep 2012 09:37:48 +0200 (CEST) X-SFR-UUID: 20120914073748704.ABF6D7000898@msfrf2111.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-71--66118906 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Fri, 14 Sep 2012 09:37:48 +0200 Message-Id: <5E8DD04D-7007-4C4F-8A21-985CA63B208F@laposte.net> References: To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) Cc: IPv6 Ops WG Subject: Re: [v6ops] BIH pointer in 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 07:37:51 -0000 --Apple-Mail-71--66118906 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-09-14 =E0 09:22, Lorenzo Colitti a =E9crit : > On Fri, Sep 14, 2012 at 4:06 PM, Hui Deng wrote: > When 464xlat integrates with other IPv6only access transition = technology such as BIH, IPv4-only app with BIHprocessing could = communicate with IPv6-server. A DNS query initiated by theapplication = would be processed by BIH ENR to generate both A and AAAA and = needsconsidering below >=20 > 1) When A responses are received, 464xlatwould take the role > 2) When A and AAAA responses are received,464xlat would take the role > 3) When only AAAA responses are received,it's the case of IPv4-IPv6 = communication. ENR embedded in BIH would interceptsAAAA records and = create the synthetic IPv4 address and corresponding themapping. = Afterwards, IPv4 applications send the packages to the synthetic = IPv4address. Protocol translator would take the rule of IPv4-IPv6 = translation andachieve IPv4-IPv6 communication. >=20 > Has this been tested and verified to work? Is there an implementation? >=20 > We should not include text in a BCP if it has never been implemented = or tested. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail-71--66118906 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
    On Fri, Sep 14, 2012 at 4:06 PM, Hui Deng <denghui02@gmail.com> wrote:
    When 464xlat integrates with other IPv6only access transition = technology such as BIH, IPv4-only app with BIHprocessing could = communicate with IPv6-server. A DNS query initiated by theapplication = would be processed by BIH ENR to generate both A and AAAA and = needsconsidering below

    1) When A responses are received, 464xlatwould take the role
    2) = When A and AAAA responses are received,464xlat would take the role
    3) = When only AAAA responses are received,it's the case of IPv4-IPv6 = communication. ENR embedded in BIH would interceptsAAAA records and = create the synthetic IPv4 address and corresponding themapping. = Afterwards, IPv4 applications send the packages to the synthetic = IPv4address. Protocol translator would take the rule of IPv4-IPv6 = translation andachieve IPv4-IPv6 communication.

    Has this been tested and verified = to work? Is there an implementation?

    We should = not include text in a BCP if it has never been implemented or = tested.
    _______________________________________________
    v6ops mailing = list
    v6ops@ietf.org
    https://www.ietf.org/= mailman/listinfo/v6ops

    = --Apple-Mail-71--66118906-- From despres.remi@laposte.net Fri Sep 14 00:41:24 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E2EE21F857D for ; Fri, 14 Sep 2012 00:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.345 X-Spam-Level: X-Spam-Status: No, score=-0.345 tagged_above=-999 required=5 tests=[AWL=-0.797, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_82=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nwLjFDtHmf5Z for ; Fri, 14 Sep 2012 00:41:23 -0700 (PDT) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.3]) by ietfa.amsl.com (Postfix) with ESMTP id 414BE21F851A for ; Fri, 14 Sep 2012 00:41:23 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2111.sfr.fr (SMTP Server) with ESMTP id A133A700088F; Fri, 14 Sep 2012 09:41:22 +0200 (CEST) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2111.sfr.fr (SMTP Server) with ESMTP id 5EEB57000877; Fri, 14 Sep 2012 09:41:22 +0200 (CEST) X-SFR-UUID: 20120914074122388.5EEB57000877@msfrf2111.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-72--65905278 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <5E8DD04D-7007-4C4F-8A21-985CA63B208F@laposte.net> Date: Fri, 14 Sep 2012 09:41:22 +0200 Message-Id: <4EAF623F-AD65-4E9E-80A0-B3F7AA59C42C@laposte.net> References: <5E8DD04D-7007-4C4F-8A21-985CA63B208F@laposte.net> To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1084) Cc: IPv6 Ops WG Subject: Re: [v6ops] BIH pointer in 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 07:41:24 -0000 --Apple-Mail-72--65905278 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 OOPS, I was just reading this mail, without intention to send an answer. Le 2012-09-14 =E0 09:37, R=E9mi Despr=E9s a =E9crit : >=20 > Le 2012-09-14 =E0 09:22, Lorenzo Colitti a =E9crit : >=20 >> On Fri, Sep 14, 2012 at 4:06 PM, Hui Deng = wrote: >> When 464xlat integrates with other IPv6only access transition = technology such as BIH, IPv4-only app with BIHprocessing could = communicate with IPv6-server. A DNS query initiated by theapplication = would be processed by BIH ENR to generate both A and AAAA and = needsconsidering below >>=20 >> 1) When A responses are received, 464xlatwould take the role >> 2) When A and AAAA responses are received,464xlat would take the role >> 3) When only AAAA responses are received,it's the case of IPv4-IPv6 = communication. ENR embedded in BIH would interceptsAAAA records and = create the synthetic IPv4 address and corresponding themapping. = Afterwards, IPv4 applications send the packages to the synthetic = IPv4address. Protocol translator would take the rule of IPv4-IPv6 = translation andachieve IPv4-IPv6 communication. >>=20 >> Has this been tested and verified to work? Is there an = implementation? >>=20 >> We should not include text in a BCP if it has never been implemented = or tested. >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail-72--65905278 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 OOPS, = I was just reading this mail, without intention to send an = answer.

    Le 2012-09-14 =E0 09:37, R=E9mi Despr=E9s a = =E9crit :


    Le = 2012-09-14 =E0 09:22, Lorenzo Colitti a =E9crit :

    On Fri, = Sep 14, 2012 at 4:06 PM, Hui Deng <denghui02@gmail.com> wrote:
    When 464xlat integrates with other IPv6only access transition = technology such as BIH, IPv4-only app with BIHprocessing could = communicate with IPv6-server. A DNS query initiated by theapplication = would be processed by BIH ENR to generate both A and AAAA and = needsconsidering below

    1) When A responses are received, 464xlatwould take the role
    2) = When A and AAAA responses are received,464xlat would take the role
    3) = When only AAAA responses are received,it's the case of IPv4-IPv6 = communication. ENR embedded in BIH would interceptsAAAA records and = create the synthetic IPv4 address and corresponding themapping. = Afterwards, IPv4 applications send the packages to the synthetic = IPv4address. Protocol translator would take the rule of IPv4-IPv6 = translation andachieve IPv4-IPv6 communication.

    Has this been tested and verified = to work? Is there an implementation?

    We should = not include text in a BCP if it has never been implemented or = tested.
    _______________________________________________
    v6ops mailing = list
    v6ops@ietf.org
    https://www.ietf.org/= mailman/listinfo/v6ops

    _______________= ________________________________
    v6ops mailing list
    v6ops@ietf.org
    https://www.ietf.org/= mailman/listinfo/v6ops

    = --Apple-Mail-72--65905278-- From denghui02@gmail.com Fri Sep 14 03:10:30 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A74D21F85EA for ; Fri, 14 Sep 2012 03:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.951 X-Spam-Level: X-Spam-Status: No, score=-101.951 tagged_above=-999 required=5 tests=[AWL=-0.153, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_82=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9AoaMaqNMqG2 for ; Fri, 14 Sep 2012 03:10:30 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA4B21F8555 for ; Fri, 14 Sep 2012 03:10:29 -0700 (PDT) Received: by qadz3 with SMTP id z3so2934756qad.10 for ; Fri, 14 Sep 2012 03:10:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rwN0g/EDIgUgbsP2iZ4Sqg9uC81pJJlFPxq4xkf7ltY=; b=Pmm1i+xgG9/KDHOv2vpNHKPHiqHtS440SahmGGz+EAEkOZwZAIufqBGgeGQBzgxk5L 20fRYfSntjZqrq8v0FcklVYiBEJP4GV3ruhtjEQNjB+PiMIuevUIiIMl/8MYcDS9DOTL VG2e/wgNZCKAuLGX+Dn+dNNUf0IkzY7v4x8F8sIdTNuyV5PRABiqGf0hqvwIFVKNyTus 9B3JrcWCpTru+9N7TAghQBzsWfTqaCeJLaKgpDjNA9T1c3xfTddX0XbswsU+y/Od2Idp HFAMgcPWukYyI1QIVCu+SXaorXr9xp8gItNZdxeKz+wpHV7Vx9uVcOd7Mh+lBb7lOm+7 Gb3w== MIME-Version: 1.0 Received: by 10.229.69.87 with SMTP id y23mr1391468qci.114.1347617429457; Fri, 14 Sep 2012 03:10:29 -0700 (PDT) Received: by 10.49.49.3 with HTTP; Fri, 14 Sep 2012 03:10:29 -0700 (PDT) In-Reply-To: References: Date: Fri, 14 Sep 2012 11:10:29 +0100 Message-ID: From: Hui Deng To: Lorenzo Colitti Content-Type: multipart/alternative; boundary=00032557b58e2d09d604c9a6a29d Cc: IPv6 Ops WG Subject: Re: [v6ops] BIH pointer in 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 10:10:30 -0000 --00032557b58e2d09d604c9a6a29d Content-Type: text/plain; charset=ISO-8859-1 2012/9/14 Lorenzo Colitti > On Fri, Sep 14, 2012 at 4:06 PM, Hui Deng wrote: > >> When 464xlat integrates with other IPv6only access transition technology >> such as BIH, IPv4-only app with BIHprocessing could communicate with >> IPv6-server. A DNS query initiated by theapplication would be processed by >> BIH ENR to generate both A and AAAA and needsconsidering below >> >> 1) When A responses are received, 464xlatwould take the role >> 2) When A and AAAA responses are received,464xlat would take the role >> 3) When only AAAA responses are received,it's the case of IPv4-IPv6 >> communication. ENR embedded in BIH would interceptsAAAA records and create >> the synthetic IPv4 address and corresponding themapping. Afterwards, IPv4 >> applications send the packages to the synthetic IPv4address. Protocol >> translator would take the rule of IPv4-IPv6 translation andachieve >> IPv4-IPv6 communication. >> > > Has this been tested and verified to work? Is there an implementation? > > We should not include text in a BCP if it has never been implemented or > tested. > > ==> we are working on the integration of this two code, and for current proposed text about this logic part, it has been implemented and works, I believe our code could finish before this draft moving to RFC editor. thanks, -Hui --00032557b58e2d09d604c9a6a29d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

    2012/9/14 Lorenzo Colitti <lorenzo@goo= gle.com>
    On Fri, Sep 14, 2012 at 4:06 PM, Hui Deng <denghui02@g= mail.com> wrote:
    When 464xlat integrates with other IPv6only access transition technolo= gy such as BIH, IPv4-only app with BIHprocessing could communicate with IPv= 6-server. A DNS query initiated by theapplication would be processed by BIH= ENR to generate both A and AAAA and needsconsidering below

    1) When A responses are received, 464xlatwould take the role
    2) Whe= n A and AAAA responses are received,464xlat would take the role
    3) When = only AAAA responses are received,it's the case of IPv4-IPv6 communicati= on. ENR embedded in BIH would interceptsAAAA records and create the synthet= ic IPv4 address and corresponding themapping. Afterwards, IPv4 applications= send the packages to the synthetic IPv4address. Protocol translator would = take the rule of IPv4-IPv6 translation andachieve IPv4-IPv6 communication.<= br>

    Has this been tested and verif= ied to work? Is there an implementation?

    We should= not include text in a BCP if it has never been implemented or tested.
    =A0
    =A0
    =3D=3D> we are working on the inte= gration of this two code, and for current proposed=A0text about this logic = part, it has been implemented and works, I believe our code could finish be= fore this draft moving to RFC editor.
    =A0
    thanks,
    =A0
    -Hui
    --00032557b58e2d09d604c9a6a29d-- From wdec.ietf@gmail.com Fri Sep 14 03:20:50 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FC6221F8578 for ; Fri, 14 Sep 2012 03:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.885 X-Spam-Level: X-Spam-Status: No, score=-2.885 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n7nrwZOXAi8g for ; Fri, 14 Sep 2012 03:20:48 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 47EEF21F859E for ; Fri, 14 Sep 2012 03:20:48 -0700 (PDT) Received: by eekb45 with SMTP id b45so2453897eek.31 for ; Fri, 14 Sep 2012 03:20:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BohD3XXzBdK2TIPvQ4rzjLZcVdLZZHY0B2ErPDaACus=; b=TUL0Fe7tDy46MpObl5k00vhPVHqnRTf/l8+G8Xz5l/xkddRJSpWvzJUl4SySGBycYN RoXYcDekmpF5HwFkP8oeeFgwXX1s4+mUqVFWUuZqu/i1SM1aE9WPTkCnlDHW1LLWZBkM Xtzo38ZcE0algwxOw4PsR75RO/Xda6YrOZly+8b/yxMkmBJFfCWDfjECL8vf254zzmv7 sEpksX2XUHDRYn5gFjYCTSmaH6XtpDN+N6KuQpHCsifjH2iTti7EdEhml71OSCVM3arp m69KxlENbzII3Mg7mRcCmaZ1NhELJ2PocGgaVAwB0pfy5MGJOytpP7dr+jNwGjBH4usG BOWg== MIME-Version: 1.0 Received: by 10.14.203.70 with SMTP id e46mr2977124eeo.2.1347618042985; Fri, 14 Sep 2012 03:20:42 -0700 (PDT) Received: by 10.14.45.68 with HTTP; Fri, 14 Sep 2012 03:20:42 -0700 (PDT) In-Reply-To: References: Date: Fri, 14 Sep 2012 12:20:42 +0200 Message-ID: From: Wojciech Dec To: Lorenzo Colitti Content-Type: multipart/alternative; boundary=047d7b3440f4bebc1804c9a6c61a Cc: IPv6 Ops WG Subject: Re: [v6ops] BIH pointer in 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 10:20:50 -0000 --047d7b3440f4bebc1804c9a6c61a Content-Type: text/plain; charset=ISO-8859-1 Fully agree with Lorenzo. -Woj. On 14 September 2012 02:45, Lorenzo Colitti wrote: > I disagree. As I said before, I see no reason to mention BIH in this > specification. > > The reason is that the suggested text provides no useful information. All > it says is "you can use BIH with 464xlat if you want". This is > superfluous. BIH is a standards track RFC. Operators are welcome to deploy > it, either with 464xlat or without. We don't need to state that obvious > fact here. If there was some useful text on *how* to integrate the two, or > caveats on how *not* to integrate the two, I could see value in mentioning > BIH. As it is, all we have is an advertisement for another transition > method (whose applicability, as many have noted in this thread, is far in > the future). > > As for the specific points in this email: > > 1. Saying "we agreed to this text in the past, so we cannot remove it now" > not relevant for two reasons. First, the text was not agreed to by the WG. > It was put in by the authors on the suggestion of some WG participants, but > other WG participants are disagreeing to it. Secondly, if we agreed to some > text in the past, but don't agree to it now, then we should change it. > Internet-drafts are work in progress, and the WG must be able to change the > draft as it sees fit up to the close of last call. If we don't agree on the > text now, we should not shrink from removing it just to save face. > > 2. Saying "operators want to use BIH" is not a reason to cite BIH. If > operators want to use BIH, they are free to deploy it. It's a standards > track RFC. > > On Fri, Sep 14, 2012 at 2:26 AM, Hui Deng wrote: > >> For 2, I second Cameron's recommendation here. >> >> I don't see the reasonable exucse to change this unnormative text, and >> those text which has been adopted before with the discussion. For the >> operation consideration, it's quite clear that two future users >> (operators) of this specification expressed they want this. >> -Hui >> 2012/9/13 Cameron Byrne >> >>> Joel wrote: >>> >>> >>> ---------- Forwarded message ---------- >>> From: joel jaeggli >>> Date: Wed, Sep 12, 2012 at 6:19 PM >>> Subject: Re: [v6ops] 464XLAT removing IPv6 LAN scope >>> To: Lorenzo Colitti >>> Cc: IPv6 Ops WG >>> >>> >>> On 9/12/12 6:06 PM, Lorenzo Colitti wrote: >>> > >>> > On Thu, Sep 13, 2012 at 3:38 AM, Fred Baker (fred) >> fred@cisco.com>> wrote: >>> > >>> > I think that there are two consensuses that we have reached. One >>> > is that 464XLAT, although we still need a -08 to finalize it, >>> > enjoys a rough consensus; you are the primary person objecting to >>> it. >>> > >>> > >>> > 1. Whether to ask IANA to reserve IIDs, and if so, how many (1, 2^32, >>> or 2^24+2^20+2^16) >>> >>> with my wg chair hat off, I don't see this as desirable. >>> >>> > 2. Whether to mention BIH or not. >>> >>> again in the same role, I think specifying it should be outside the >>> scope of the document. mentioning it is not the same as specifying it. >>> >>> >>> Regarding 1, the plan is to remove prefix sharing and move the ideas >>> learned there with reserved IID to a specific and seperate I-D >>> >>> Regarding 2, the authors would like to mention BIH for completeness to >>> provide a pointer to how the ietf has defined all stateful v4 and v6 >>> translation permutations, as shown in the traffic treatment table >>> http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-07#section-9.2 >>> >>> Since this is a wg doc, we need the wg view. >>> >>> I believe Remi's text is acceptable. Others' thoughts? >>> >>> http://www.ietf.org/mail-archive/web/v6ops/current/msg14252.html >>> >>> CB >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> >> > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --047d7b3440f4bebc1804c9a6c61a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Fully agree with Lorenzo.

    -Woj.

    On= 14 September 2012 02:45, Lorenzo Colitti <lorenzo@google.com> wrote:
    I disagree. As I said before, I see no reaso= n to mention BIH in this specification.

    The reason is th= at the suggested text provides no useful information. All it says is "= you can use BIH with 464xlat if you want". This is superfluous.=A0BIH = is a standards track RFC. Operators are welcome to deploy it, either with 4= 64xlat or without. We don't need to state that obvious fact here.=A0If = there was some useful text on *how* to integrate the two, or caveats on how= *not* to integrate the two, I could see value in mentioning BIH. As it is,= all we have is an advertisement for another transition method (whose appli= cability, as many have noted in this thread, is far in the future).

    As for the specific points in this email:
    1. Saying "we agreed to this text in the past, so we canno= t remove it now" not relevant for two reasons. First, the text was not= agreed to by the WG. It was put in by the authors on the suggestion of som= e WG participants, but other WG participants are disagreeing to it. Secondl= y, if we agreed to some text in the past, but don't agree to it now, th= en we should change it. Internet-drafts are work in progress, and the WG mu= st be able to change the draft as it sees fit up to the close of last call.= If we don't agree on the text now, we should not shrink from removing = it just to save face.

    2. Saying "operators want to use BIH&quo= t; is not a reason to cite BIH. If operators want to use BIH, they are free= to deploy it. It's a standards track RFC.

    On Fri, Sep 14, 2012 at 2:26 AM, Hui Deng <denghui02@gmail.com> wrote:
    For 2, I second Cameron's recommendation here.
    =A0
    =
    I don't see the reasonable exucse to change this=A0unnormative tex= t, and those text=A0which has been adopted before with the discussion. For = the operation consideration, it's quite clear that two future users (op= erators)=A0of this specification expressed they want this.
    -Hui
    2012/9/13 Cameron Byrne <cb.= list6@gmail.com>
    Joel wrote:


    ---------- Forwarded message ----------
    From: joel jaeggli <joelja@bogus.com>
    Date: Wed, Sep 12, 2012 at 6:19 PM
    Subject: Re: [v6ops] 464XLAT removing IPv6 LAN scope
    To: Lorenzo Colitti <lorenzo@google.com>
    Cc: IPv6 Ops WG <v6o= ps@ietf.org>


    On 9/12/12 6:06 PM, Lorenzo Colitti wrote:
    >
    > On Thu, Sep 13, 2012 at 3:38 AM, Fred Baker (fred) <fred@cisco.com <mailto:fred@cisco.com>> wro= te:
    >
    > =A0 =A0 I think that there are two consensuses that we have reached. O= ne
    > =A0 =A0 is that 464XLAT, although we still need a -08 to finalize it,<= br> > =A0 =A0 enjoys a rough consensus; you are the primary person objecting= to it.
    >
    >
    > 1. Whether to ask IANA to reserve IIDs, and if so, how many (1, 2^32, = or 2^24+2^20+2^16)

    with my wg chair hat off, I don't see this as desirable.

    > 2. Whether to mention BIH or not.

    again in the same role, I think specifying it should be outside the
    scope of the document. mentioning it is not the same as specifying it.


    Regarding 1, the plan is to remove prefix sharing and move the ideas
    learned there with reserved IID to a specific and seperate I-D

    Regarding 2, the authors would like to mention BIH for completeness to
    provide a pointer to how the ietf has defined all stateful v4 and v6
    translation permutations, as shown in the traffic treatment table
    http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-0= 7#section-9.2

    Since this is a wg doc, we need the wg view.

    I believe Remi's text is acceptable. =A0Others' thoughts?

    http://www.ietf.org/mail-archive/web/v6ops/current/msg1= 4252.html

    CB
    _______________________________________________
    v6ops mailing list
    v6ops@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/v6ops


    _______________________________________________
    v6ops mailing list
    v6ops@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/v6ops



    _______________________________________________
    v6ops mailing list
    v6ops@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/v6ops


    --047d7b3440f4bebc1804c9a6c61a-- From ietfc@btconnect.com Fri Sep 14 03:25:08 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D52E21F85A1 for ; Fri, 14 Sep 2012 03:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.351 X-Spam-Level: X-Spam-Status: No, score=-3.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jj2TJao2qqIa for ; Fri, 14 Sep 2012 03:25:07 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by ietfa.amsl.com (Postfix) with ESMTP id 2F7B221F8578 for ; Fri, 14 Sep 2012 03:25:07 -0700 (PDT) Received: from mail131-va3-R.bigfish.com (10.7.14.246) by VA3EHSOBE011.bigfish.com (10.7.40.61) with Microsoft SMTP Server id 14.1.225.23; Fri, 14 Sep 2012 10:25:05 +0000 Received: from mail131-va3 (localhost [127.0.0.1]) by mail131-va3-R.bigfish.com (Postfix) with ESMTP id 9F36224011D; Fri, 14 Sep 2012 10:25:05 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.249.85; KIP:(null); UIP:(null); IPV:NLI; H:AMSPRD0710HT001.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: PS-25(zzbb2dI98dI9371I542M1432I1418Id6f1izz1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dhz2dh2a8h5a9h668h839hd24hf0ah107ah1177h1179h1288h12a5h12a9h12bdh1315h304l1155h) Received: from mail131-va3 (localhost.localdomain [127.0.0.1]) by mail131-va3 (MessageSwitch) id 1347618304389325_10330; Fri, 14 Sep 2012 10:25:04 +0000 (UTC) Received: from VA3EHSMHS015.bigfish.com (unknown [10.7.14.237]) by mail131-va3.bigfish.com (Postfix) with ESMTP id 5BB07C0042; Fri, 14 Sep 2012 10:25:04 +0000 (UTC) Received: from AMSPRD0710HT001.eurprd07.prod.outlook.com (157.56.249.85) by VA3EHSMHS015.bigfish.com (10.7.99.25) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 14 Sep 2012 10:25:02 +0000 Received: from BY2PRD0510HT004.namprd05.prod.outlook.com (157.56.236.101) by pod51017.outlook.com (10.255.160.164) with Microsoft SMTP Server (TLS) id 14.16.190.9; Fri, 14 Sep 2012 10:24:59 +0000 Message-ID: <016701cd9263$470463a0$4001a8c0@gateway.2wire.net> From: t.petch To: Lorenzo Colitti References: Date: Fri, 14 Sep 2012 11:22:15 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.236.101] X-OriginatorOrg: btconnect.com Cc: IPv6 Ops WG Subject: Re: [v6ops] BIH pointer in 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 10:25:08 -0000 ----- Original Message ----- From: "Lorenzo Colitti" To: "Hui Deng" Cc: "IPv6 Ops WG" Sent: Friday, September 14, 2012 1:45 AM > I disagree. As I said before, I see no reason to mention BIH in this > specification. > > The reason is that the suggested text provides no useful information. All > it says is "you can use BIH with 464xlat if you want". This is > superfluous. BIH is a standards track RFC. Operators are welcome to deploy > it, either with 464xlat or without. We don't need to state that obvious > fact here. If there was some useful text on *how* to integrate the two, or > caveats on how *not* to integrate the two, I could see value in mentioning > BIH. As it is, all we have is an advertisement for another transition > method (whose applicability, as many have noted in this thread, is far in > the future). Lorenzo, I agree, and would go further. I think that text such as that proposed gets close to being an endorsement of BIH, which I do not believe that I, we, are in a position to give. This area of melding two disparate technologies is a difficult one, one where there are likely to be pitfalls. Thus DHCPv6-PD is an excellent solution - ah, not available just yet. Proxy ND looks good - ah, sets up loops. This information comes from discussions on the list, discussions which we have not yet had about BIH; it has gotten a mention and that is it. So what is wrong with BIH? I believe that we do not yet know - the RFC is Feb 2012 - and so should be wary about saying anything that has overtones of 'here is another good solution'. Play safe, stick to what we have discussed and omit BIH. Tom Petch > > As for the specific points in this email: > > 1. Saying "we agreed to this text in the past, so we cannot remove it now" > not relevant for two reasons. First, the text was not agreed to by the WG. > It was put in by the authors on the suggestion of some WG participants, but > other WG participants are disagreeing to it. Secondly, if we agreed to some > text in the past, but don't agree to it now, then we should change it. > Internet-drafts are work in progress, and the WG must be able to change the > draft as it sees fit up to the close of last call. If we don't agree on the > text now, we should not shrink from removing it just to save face. > > 2. Saying "operators want to use BIH" is not a reason to cite BIH. If > operators want to use BIH, they are free to deploy it. It's a standards > track RFC. > > On Fri, Sep 14, 2012 at 2:26 AM, Hui Deng wrote: > > > For 2, I second Cameron's recommendation here. > > > > I don't see the reasonable exucse to change this unnormative text, and > > those text which has been adopted before with the discussion. For the > > operation consideration, it's quite clear that two future users > > (operators) of this specification expressed they want this. > > -Hui > > 2012/9/13 Cameron Byrne > > > >> Joel wrote: > >> > >> > >> ---------- Forwarded message ---------- > >> From: joel jaeggli > >> Date: Wed, Sep 12, 2012 at 6:19 PM > >> Subject: Re: [v6ops] 464XLAT removing IPv6 LAN scope > >> To: Lorenzo Colitti > >> Cc: IPv6 Ops WG > >> > >> > >> On 9/12/12 6:06 PM, Lorenzo Colitti wrote: > >> > > >> > On Thu, Sep 13, 2012 at 3:38 AM, Fred Baker (fred) >> fred@cisco.com>> wrote: > >> > > >> > I think that there are two consensuses that we have reached. One > >> > is that 464XLAT, although we still need a -08 to finalize it, > >> > enjoys a rough consensus; you are the primary person objecting to > >> it. > >> > > >> > 1. Whether to ask IANA to reserve IIDs, and if so, how many (1, 2^32, > >> or 2^24+2^20+2^16) > >> > >> with my wg chair hat off, I don't see this as desirable. > >> > >> > 2. Whether to mention BIH or not. > >> > >> again in the same role, I think specifying it should be outside the > >> scope of the document. mentioning it is not the same as specifying it. > >> > >> Regarding 1, the plan is to remove prefix sharing and move the ideas > >> learned there with reserved IID to a specific and seperate I-D > >> > >> Regarding 2, the authors would like to mention BIH for completeness to > >> provide a pointer to how the ietf has defined all stateful v4 and v6 > >> translation permutations, as shown in the traffic treatment table > >> http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-07#section-9.2 > >> > >> Since this is a wg doc, we need the wg view. > >> > >> I believe Remi's text is acceptable. Others' thoughts? > >> > >> http://www.ietf.org/mail-archive/web/v6ops/current/msg14252.html > >> > >> CB From wdec.ietf@gmail.com Fri Sep 14 03:25:12 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9803521F8618 for ; Fri, 14 Sep 2012 03:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.898 X-Spam-Level: X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hpgXmqf8ciyV for ; Fri, 14 Sep 2012 03:25:11 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7912021F85F9 for ; Fri, 14 Sep 2012 03:25:11 -0700 (PDT) Received: by eekb45 with SMTP id b45so2456282eek.31 for ; Fri, 14 Sep 2012 03:25:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TylESKg7RedwloxsMZ/euaH0ToJfL6DhGxcTXjSF6gU=; b=uhr210cZb+D+4cw7rd/TkwzSkxeWehIpyeBkgs9UuB9JCUiCkU6p0qhro5I7v4z0VW VlcPzGUCxaRSok+/k7YYDYq/dzD5LxJqFPW0/hIkj2y8mIIAjDW74OUD9iqraM3EJJJm gBnT6D31WuLW8dH+A1QMM7cWdCrNA4yiYLZuKSExAastuDyV17PXP9zMaPTc1x0Qpeve 9xiOR9RGnBwYeWEj8bS4Wr1XVpJXCEQdda3WPg81J+TTmcmlf3S0k89yeKlc4c46SGea twBnO1wRYxpadbCW/TyYwniA1Vbi+WiitpfhNxxf110ERkOx0Va7DlUX0ILllY1gZ6Ri eVug== MIME-Version: 1.0 Received: by 10.14.206.201 with SMTP id l49mr2993339eeo.3.1347618310636; Fri, 14 Sep 2012 03:25:10 -0700 (PDT) Received: by 10.14.45.68 with HTTP; Fri, 14 Sep 2012 03:25:10 -0700 (PDT) In-Reply-To: References: Date: Fri, 14 Sep 2012 12:25:10 +0200 Message-ID: From: Wojciech Dec To: Cameron Byrne Content-Type: multipart/alternative; boundary=047d7b343faab2c4c604c9a6d68a Cc: IPv6 Ops WG Subject: Re: [v6ops] 464XLAT removing IPv6 LAN scope X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 10:25:12 -0000 --047d7b343faab2c4c604c9a6d68a Content-Type: text/plain; charset=ISO-8859-1 Hi Cameron, your proposal works for me. Regards, Woj. On 7 September 2012 21:36, Cameron Byrne wrote: > Folks, > > I hope we can all see the scope issue related /64 sharing across > interfaces, it is simply not germane to the function of 464XLAT and it > should be removed. > > A much more workable solution, from IETF perspective, is to simply say > that 464XLAT supports the DHCP-PD scenario for a dedicated translation > prefix (no challenges that i know of), and in the case of no DHCP-PD > available the CLAT does normal CLAT function for IPv4 with NAT44 as > described in section 8.3.2 > > Meaning, there is an IPv6-only WAN and an IPv4 capable LAN, no > bridging or sharing of IPv6 across the CLAT is specified. > > I would like to move forward with 464XLAT by simply stating that > DHCP-PD is the best choice for acquiring a dedicated /64 to be used > with stateless translation. > > http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-07#section-8.3.2 > > For section 8.3.2 we can retain how IPv4 is treated with NAT44, but > simply remove how IPv6 is treated. > > > > If the CLAT cannot perform ND Proxy [RFC4389] due to the restriction > of the implementation, the CLAT may use a dedicated IANA assigned > EUI-64 ID for creating a translated IPv6 address to be used in > stateless translation [RFC6145]. This will allow the CLAT to avoid > possible IPv6 address duplication issues between an IPv6 address for > stateless translation [RFC6145] in the CLAT and an IPv6 address > assigned to native IPv6 nodes behind the CLAT. This document > describes an example for this case in Example 2. of the Appendix A. > > The CLAT MAY discover the Pref64::/n of the PLAT via some method such > as TR-069, DNS APL RR [RFC3123] or > [I-D.ietf-behave-nat64-discovery-heuristic]. > > > > > > We can also remove the IANA section and remove reference to ND proxy. > If implementations choose to extend a /64 from WAN to LAN in cases > where DHCP-PD is not available, they may, but it is out of scope for > *THIS* I-D. Hopefully some of the discussion here can feed further > work in this area that appears to be needed. > > I believe this brings us back to pure 464XLAT which is an architecture > for double translation, not /64 cross-interface extensions and not a > CPE router specification. > > Any technical issues with this approach? > > CB > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --047d7b343faab2c4c604c9a6d68a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Cameron,


    your proposal works for me.

    Regards,
    Woj.<= br>
    On 7 September 2012 21:36, Cameron Byrne = <cb.list6@gmail.com> wrote:
    Folks,

    I hope we can all see the scope issue related /64 sharing across
    interfaces, it is simply not germane to the function of 464XLAT and it
    should be removed.

    A much more workable solution, from IETF perspective, is to simply say
    that 464XLAT supports the DHCP-PD scenario for a dedicated translation
    prefix (no challenges that i know of), and in the case of no DHCP-PD
    available the CLAT does normal CLAT function for IPv4 with NAT44 as
    described in section 8.3.2

    Meaning, there is an IPv6-only WAN and an IPv4 capable LAN, no
    bridging or sharing of IPv6 across the CLAT is specified.

    I would like to move forward with 464XLAT by simply stating that
    DHCP-PD is the best choice for acquiring a dedicated /64 to be used
    with stateless translation.

    http://tools.ietf.org/html/draft-ietf-v6ops-464xlat= -07#section-8.3.2

    For section 8.3.2 we can retain how IPv4 is treated with NAT44, but
    simply remove how IPv6 is treated.

    <removed text>

    If the CLAT cannot perform ND Proxy [RFC4389] due to the restriction
    =A0 =A0of the implementation, the CLAT may use a dedicated IANA assigned =A0 =A0EUI-64 ID for creating a translated IPv6 address to be used in
    =A0 =A0stateless translation [RFC6145]. =A0This will allow the CLAT to avoi= d
    =A0 =A0possible IPv6 address duplication issues between an IPv6 address for=
    =A0 =A0stateless translation [RFC6145] in the CLAT and an IPv6 address
    =A0 =A0assigned to native IPv6 nodes behind the CLAT. =A0This document
    =A0 =A0describes an example for this case in Example 2. of the Appendix A.<= br>
    =A0 =A0The CLAT MAY discover the Pref64::/n of the PLAT via some method suc= h
    =A0 =A0as TR-069, DNS APL RR [RFC3123] or
    =A0 =A0[I-D.ietf-behave-nat64-discovery-heuristic].


    </removed text>


    We can also remove the IANA section and remove reference to ND proxy.
    If implementations choose to extend a /64 from WAN to LAN in cases
    where DHCP-PD is not available, they may, but it is out of scope for
    *THIS* I-D. =A0Hopefully some of the discussion here can feed further
    work in this area that appears to be needed.

    I believe this brings us back to pure 464XLAT which is an architecture
    for double translation, not /64 cross-interface extensions and not a
    CPE router specification.

    Any technical issues with this approach?

    CB
    _______________________________________________
    v6ops mailing list
    v6ops@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/v6ops

    --047d7b343faab2c4c604c9a6d68a-- From wdec.ietf@gmail.com Fri Sep 14 05:35:00 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF05B21F8512 for ; Fri, 14 Sep 2012 05:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.208 X-Spam-Level: X-Spam-Status: No, score=-3.208 tagged_above=-999 required=5 tests=[AWL=0.390, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FMwU5LfDU94x for ; Fri, 14 Sep 2012 05:35:00 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id B66D521F850D for ; Fri, 14 Sep 2012 05:34:59 -0700 (PDT) Received: by eekb45 with SMTP id b45so2525052eek.31 for ; Fri, 14 Sep 2012 05:34:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=m+7l10d0r1H6pmCCJUlUXMnGuqqEFKPg2IdNWKEWgQA=; b=C+YvcI/JWO2esAYLvvnodedrZAud/RGwtwVcVEPH607k4MVFSBi1XFxglWNv/ov01+ GPxXxlXQ2JB8tFwWZZSq8MdSaMKKb7xxaLwpjv+Tlvw6z+8rcuiQOSh+0sufSOEODc9E zNpe2BXb2LRsTAWSA69oF+7YudEm7mU/LbB+BbLy9mtzuDjyHbDgknew0JMY6fa/XG6g RGf9FsUId1TgMwXctlwOBU1kLZVJdu9fyat8N5NxwG6aCbi47aEOSdiA0pOjIeRu7eyC 54T/8Ws33elVomSffk3mYjntzT+C4CYMxSFLiDm0Uubuu1gjVRXaSE6Yc9VRbJQ5x8GG fJzQ== MIME-Version: 1.0 Received: by 10.14.0.198 with SMTP id 46mr3299569eeb.30.1347626098945; Fri, 14 Sep 2012 05:34:58 -0700 (PDT) Received: by 10.14.45.68 with HTTP; Fri, 14 Sep 2012 05:34:58 -0700 (PDT) In-Reply-To: References: <504392E0.8070802@bogus.com> <448050D4-84F9-4F52-BF7E-347EA451A96C@laposte.net> <041e01cd8ce7$61aeebc0$4001a8c0@gateway.2wire.net> <2808F812-B159-4F99-A7A1-C6B159EABBA0@laposte.net> <7298FD2A-55D5-4437-A890-53AF041AB03D@laposte.net> Date: Fri, 14 Sep 2012 14:34:58 +0200 Message-ID: From: Wojciech Dec To: Lorenzo Colitti Content-Type: multipart/alternative; boundary=047d7b62275eeaecb004c9a8a688 Cc: v6ops WG Subject: Re: [v6ops] 464XLAT - support of /64 delegated prefixes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 12:35:00 -0000 --047d7b62275eeaecb004c9a8a688 Content-Type: text/plain; charset=ISO-8859-1 Hi Lorenzo, On 11 September 2012 06:29, Lorenzo Colitti wrote: > On Mon, Sep 10, 2012 at 10:38 PM, Wojciech Dec wrote: > >> - If we're talking about subtended IPv6 devices and sharing a /64, then >> the IANA assignment lead to ND hacks, some new form of SLAAC; best left for >> handling via DHCP PD. >> > > Not sure I agree with this last point, because I'm not sure what you > mean. I assert that the following scenario: > > - CLAT with only one public IPv6 /64 > - With a p2p northbound interface and a broadcast downstream interface > - Sharing the /64 to directly connected downstream clients > > Can be done robustly, with no ND proxy hacks at all (with or without IANA > assignment). Do you agree? > In my opinion this setup does require something not obvious to developers and that it risks "polluting" the notion of an iPv6 link and subnet (ie developers getting it wrong, and then further architectures be built on this). The device in the middle (eg CLAT) would have its upstream (p2p) and downstream (broadcast) interfaces all effectively on the same /64 and I'm assuming "on-link". This then becomes either a case of some translational bridging in action (the p2p upstream has a different link layer than the bcast downstream), or a proxy-something (eg ND), virtual interfaces, etc. This can indeed be made to work and be robust, but it doesn't change the fact that this setup is not exactly simple, and it is not how one would these days link up two different media-types along with IP routing. > > I agree that IPv6 more than one level deep, (e.g., with cascading CLATs), > cannot be done without hacks, and that these hacks don't really work. For > this situation we must require DHCPv6 PD. > Agreed. -Woj. --047d7b62275eeaecb004c9a8a688 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Lorenzo,

    On 11 September 2012 06:29, L= orenzo Colitti <lorenzo@google.com> wrote:
    On Mon, Sep 10, 2012 at 10:38 PM, Wojciech Dec <wdec.= ietf@gmail.com> wrote:
    - If we're talking about subtended IPv6= devices and sharing a /64, then the IANA assignment lead to ND hacks, some= new form of SLAAC; best left for handling via DHCP PD.

    Not sure I agree with this last point, because I&= #39;m not sure what you mean.=A0I assert that the following scenario:
    =
    • CLAT with only one public IPv6 /64
    • With a p2p northbou= nd interface and a broadcast downstream interface
    • Sharing the /64 to directly connected downstream clients
    = Can be done robustly, with no ND proxy hacks at all (with or without IANA a= ssignment). Do you agree?

    In my opin= ion this setup does require something not obvious to developers and that it= risks "polluting" the notion of an iPv6 link and subnet (ie deve= lopers getting it wrong, and then further architectures be built on this). = The device in the middle (eg CLAT) would have its upstream (p2p) and downst= ream (broadcast) interfaces all effectively on the same /64 and I'm ass= uming "on-link". This then becomes either a case of some translat= ional bridging in action (the p2p upstream has a different link layer than = the bcast downstream), or a proxy-something (eg ND), virtual interfaces, et= c.=A0 This can indeed be made to work and be robust, but it doesn't cha= nge the fact that this setup is not exactly simple, and it is not how one w= ould these days link up two different media-types along with IP routing.

    I agree that IPv6 more than one level deep, (e.g., with cascading = CLATs), cannot be done without hacks, and that these hacks don't really= work. For this situation we must require DHCPv6 PD.

    Agreed.

    -Woj.

    --047d7b62275eeaecb004c9a8a688-- From sarikaya2012@gmail.com Fri Sep 14 09:20:32 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA9B921F850D for ; Fri, 14 Sep 2012 09:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.775 X-Spam-Level: X-Spam-Status: No, score=-2.775 tagged_above=-999 required=5 tests=[AWL=-0.376, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kAJJOaoREB99 for ; Fri, 14 Sep 2012 09:20:31 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7640321F8503 for ; Fri, 14 Sep 2012 09:20:31 -0700 (PDT) Received: by ieak13 with SMTP id k13so7905394iea.31 for ; Fri, 14 Sep 2012 09:20:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=X1ut48lhxBiC9CKR9ZwSknbbjvqty1icFzcVAEF1aiY=; b=FXWlkN+CvcQppKoIdGsucvUeMEmuFrUmaublCYENfwZ6s2E1Wp/96IJADyUvc1iut5 c/Mk+vjeeQA5iTp8hMcgw9M+f3xrv2L+lSKwoUcf9wmHS5w2Z6uDjMAZra/Z+ieFFCYA yNFUtiuZzKwJdORsGbNtIzr3otWZiYPs/+MjKL/0bAYMcfrXuoCRfPQ0fGwPmGN+sWqk A6vy8YMzfCy3h80inYYcWyxiGq8VmurILDPOqcQC3abJZF02pXRFDBcLqAkSrpKJyyA1 MhBYH7PqwsGnmVzy+GtMFfrJu8xIbBR6vt0kM4eL7Ur5KCwUoC8skQjHFHQccV9CqHMe Wv7A== MIME-Version: 1.0 Received: by 10.50.17.133 with SMTP id o5mr3713091igd.41.1347639630947; Fri, 14 Sep 2012 09:20:30 -0700 (PDT) Received: by 10.231.55.70 with HTTP; Fri, 14 Sep 2012 09:20:30 -0700 (PDT) In-Reply-To: <016701cd9263$470463a0$4001a8c0@gateway.2wire.net> References: <016701cd9263$470463a0$4001a8c0@gateway.2wire.net> Date: Fri, 14 Sep 2012 11:20:30 -0500 Message-ID: From: Behcet Sarikaya To: "t.petch" Content-Type: text/plain; charset=ISO-8859-1 Cc: IPv6 Ops WG Subject: Re: [v6ops] BIH pointer in 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 16:20:32 -0000 I favor keeping BIH text. The authors believe in it that's why they included the text. Reading Hui's mail, there is at least one implementation, which removes Lorenzo's concern, I think. Regards, Behcet On Fri, Sep 14, 2012 at 5:22 AM, t.petch wrote: > ----- Original Message ----- > From: "Lorenzo Colitti" > To: "Hui Deng" > Cc: "IPv6 Ops WG" > Sent: Friday, September 14, 2012 1:45 AM > >> I disagree. As I said before, I see no reason to mention BIH in this >> specification. >> >> The reason is that the suggested text provides no useful information. > All >> it says is "you can use BIH with 464xlat if you want". This is >> superfluous. BIH is a standards track RFC. Operators are welcome to > deploy >> it, either with 464xlat or without. We don't need to state that > obvious >> fact here. If there was some useful text on *how* to integrate the > two, or >> caveats on how *not* to integrate the two, I could see value in > mentioning >> BIH. As it is, all we have is an advertisement for another transition >> method (whose applicability, as many have noted in this thread, is far > in >> the future). > > Lorenzo, > > I agree, and would go further. I think that text such as that proposed > gets close to being an endorsement of BIH, which I do not believe that > I, we, are in a position to give. This area of melding two disparate > technologies is a difficult one, one where there are likely to be > pitfalls. Thus DHCPv6-PD is an excellent solution - ah, not available > just yet. Proxy ND looks good - ah, sets up loops. This information > comes from discussions on the list, discussions which we have not yet > had about BIH; it has gotten a mention and that is it. So what is wrong > with BIH? I believe that we do not yet know - the RFC is Feb 2012 - and > so should be wary about saying anything that has overtones of 'here is > another good solution'. Play safe, stick to what we have discussed and > omit BIH. > > Tom Petch > >> >> As for the specific points in this email: >> >> 1. Saying "we agreed to this text in the past, so we cannot remove it > now" >> not relevant for two reasons. First, the text was not agreed to by the > WG. >> It was put in by the authors on the suggestion of some WG > participants, but >> other WG participants are disagreeing to it. Secondly, if we agreed to > some >> text in the past, but don't agree to it now, then we should change it. >> Internet-drafts are work in progress, and the WG must be able to > change the >> draft as it sees fit up to the close of last call. If we don't agree > on the >> text now, we should not shrink from removing it just to save face. >> >> 2. Saying "operators want to use BIH" is not a reason to cite BIH. If >> operators want to use BIH, they are free to deploy it. It's a > standards >> track RFC. >> >> On Fri, Sep 14, 2012 at 2:26 AM, Hui Deng wrote: >> >> > For 2, I second Cameron's recommendation here. >> > >> > I don't see the reasonable exucse to change this unnormative text, > and >> > those text which has been adopted before with the discussion. For > the >> > operation consideration, it's quite clear that two future users >> > (operators) of this specification expressed they want this. >> > -Hui >> > 2012/9/13 Cameron Byrne >> > >> >> Joel wrote: >> >> >> >> >> >> ---------- Forwarded message ---------- >> >> From: joel jaeggli >> >> Date: Wed, Sep 12, 2012 at 6:19 PM >> >> Subject: Re: [v6ops] 464XLAT removing IPv6 LAN scope >> >> To: Lorenzo Colitti >> >> Cc: IPv6 Ops WG >> >> >> >> >> >> On 9/12/12 6:06 PM, Lorenzo Colitti wrote: >> >> > >> >> > On Thu, Sep 13, 2012 at 3:38 AM, Fred Baker (fred) > > >> fred@cisco.com>> wrote: >> >> > >> >> > I think that there are two consensuses that we have reached. > One >> >> > is that 464XLAT, although we still need a -08 to finalize it, >> >> > enjoys a rough consensus; you are the primary person > objecting to >> >> it. >> >> > >> >> > 1. Whether to ask IANA to reserve IIDs, and if so, how many (1, > 2^32, >> >> or 2^24+2^20+2^16) >> >> >> >> with my wg chair hat off, I don't see this as desirable. >> >> >> >> > 2. Whether to mention BIH or not. >> >> >> >> again in the same role, I think specifying it should be outside the >> >> scope of the document. mentioning it is not the same as specifying > it. >> >> >> >> Regarding 1, the plan is to remove prefix sharing and move the > ideas >> >> learned there with reserved IID to a specific and seperate I-D >> >> >> >> Regarding 2, the authors would like to mention BIH for completeness > to >> >> provide a pointer to how the ietf has defined all stateful v4 and > v6 >> >> translation permutations, as shown in the traffic treatment table >> >> http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-07#section-9.2 >> >> >> >> Since this is a wg doc, we need the wg view. >> >> >> >> I believe Remi's text is acceptable. Others' thoughts? >> >> >> >> http://www.ietf.org/mail-archive/web/v6ops/current/msg14252.html >> >> >> >> CB > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From ietf-secretariat@ietf.org Fri Sep 14 11:17:14 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57D6D21F8549; Fri, 14 Sep 2012 11:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.475 X-Spam-Level: X-Spam-Status: No, score=-102.475 tagged_above=-999 required=5 tests=[AWL=-0.476, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kgpL5Prv7WQl; Fri, 14 Sep 2012 11:17:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C67921F853E; Fri, 14 Sep 2012 11:17:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120914181713.8337.93189.idtracker@ietfa.amsl.com> Date: Fri, 14 Sep 2012 11:17:13 -0700 Cc: iaoc@ietf.org, opsec@ietf.org, sidr@ietf.org, v6ops@ietf.org, wgchairs@ietf.org Subject: [v6ops] IETF Large Interim Meeting - OPSEC, SIDR and V6OPS X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 18:17:14 -0000 OPSEC, SIDR and V6OPS Interim Meeting Amsterdam, The Netherlands 29 September 2012 Venue: Hotel Okura Amsterdam (www.okura.nl) Ferdinand Bolstraat 333 1072 LH Amsterdam The Netherlands 1. Registration 2. Accommodations 3. Meeting Schedule 1. Registration A. Fee: $100 USD B. Register online at: http://www.ietf.org/registration/lim2012/ietfre= g.py C. Online Registration and Payment closes on 28 September 2012 D. On Site Registration starting Saturday, 29 September at 8:00 AM 2. Accommodations The IETF is holding a block of rooms at the Hotel Okura. The Hotel is not c= urrently ready to accept reservations but we hope to be able to provide boo= king details early next week (the week of 17 September). 3. Meeting Schedule 0900-1700 CEST SIDR 0900-1130 CEST OPSEC 1330-1630 CEST V6OPS From joelja@bogus.com Fri Sep 14 17:04:06 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0F2121F84F6 for ; Fri, 14 Sep 2012 17:04:06 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V0vgxcU0HYIk for ; Fri, 14 Sep 2012 17:04:06 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 3A46A21F8497 for ; Fri, 14 Sep 2012 17:04:06 -0700 (PDT) Received: from user-64-9-235-75.googlewifi.com (user-64-9-235-75.googlewifi.com [64.9.235.75]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q8F045As091381 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Sat, 15 Sep 2012 00:04:05 GMT (envelope-from joelja@bogus.com) Message-ID: <5053C5F0.3000401@bogus.com> Date: Fri, 14 Sep 2012 17:04:00 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120821 Thunderbird/15.0 MIME-Version: 1.0 To: IPv6 Ops WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sat, 15 Sep 2012 00:04:05 +0000 (UTC) Subject: [v6ops] reminder document deadline for interim meeting. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Sep 2012 00:04:06 -0000 Our proposed document submission deadline is/was tomorrow, saturday. I don't think it's definitive, but It's two weeks out from the 29th. So if you have material you'd like brought up there whether you'll be present, remote or not attending that would be heplful to start thinking about soon. Thanks joel From denghui02@gmail.com Fri Sep 14 17:51:12 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3E0921F84FA for ; Fri, 14 Sep 2012 17:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.943 X-Spam-Level: X-Spam-Status: No, score=-99.943 tagged_above=-999 required=5 tests=[AWL=-2.084, BAYES_05=-1.11, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_82=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ly-ajPa3EKKq for ; Fri, 14 Sep 2012 17:51:12 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4E63821F84F9 for ; Fri, 14 Sep 2012 17:51:12 -0700 (PDT) Received: by qcac10 with SMTP id c10so3759363qca.31 for ; Fri, 14 Sep 2012 17:51:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Z60VSJbw9sv4fyspV7L9A46U3kQ0Ox4sI2Xnr08QuaE=; b=ZaC8iO96LkT8jo7bKFAWg/kyx8Vzx1t64ykMaw2y5PWB8bvsaygDhYzEEE6kxlNRUL r/Z2djtSHj2VpKOE3yUIovBUx51+wqAUWS3ar58bxvwBPQBSZc86Am/ljkaT/FZKtKIa +ZU/R+q3+puCNQZz+qaL+EW7N+V7yE8WQzmMNk7JkaMT4eDKXepX5ux48/NlINEMjjRO cYOF/CzcjHIoUyXBc5a+SSGZuYt+kEYBnhV5uuiraHv/Uh7zqaAlMZ8nePm9Y3y6W6wV yi8cPIrwCqhVd4soHCfsnsQyDMVOgsomm2CkKoDPXn21O3j9y5KX0KZsX2159C5p7lpz njEg== MIME-Version: 1.0 Received: by 10.224.185.148 with SMTP id co20mr11471755qab.4.1347670271620; Fri, 14 Sep 2012 17:51:11 -0700 (PDT) Received: by 10.49.49.3 with HTTP; Fri, 14 Sep 2012 17:51:11 -0700 (PDT) In-Reply-To: References: Date: Sat, 15 Sep 2012 02:51:11 +0200 Message-ID: From: Hui Deng To: Lorenzo Colitti Content-Type: multipart/alternative; boundary=485b397dd697d0781604c9b2efe8 Cc: IPv6 Ops WG Subject: Re: [v6ops] BIH pointer in 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Sep 2012 00:51:12 -0000 --485b397dd697d0781604c9b2efe8 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable we are working on the integration of two works, for this written text part, it has finished and works thanks, -Hui =D4=DA 2012=C4=EA9=D4=C214=C8=D5=D0=C7=C6=DA=CE=E5=A3=ACLorenzo Colitti =D0=B4=B5=C0=A3=BA > On Fri, Sep 14, 2012 at 4:06 PM, Hui Deng wrote: >> >> When 464xlat integrates with other IPv6only access transition technology such as BIH, IPv4-only app with BIHprocessing could communicate with IPv6-server. A DNS query initiated by theapplication would be processed by BIH ENR to generate both A and AAAA and needsconsidering below >> 1) When A responses are received, 464xlatwould take the role >> 2) When A and AAAA responses are received,464xlat would take the role >> 3) When only AAAA responses are received,it's the case of IPv4-IPv6 communication. ENR embedded in BIH would interceptsAAAA records and create the synthetic IPv4 address and corresponding themapping. Afterwards, IPv4 applications send the packages to the synthetic IPv4address. Protocol translator would take the rule of IPv4-IPv6 translation andachieve IPv4-IPv6 communication. > > Has this been tested and verified to work? Is there an implementation? > We should not include text in a BCP if it has never been implemented or tested. --485b397dd697d0781604c9b2efe8 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable we are working on the integration of two works, for this written text part,= it has finished and works

    thanks,

    -Hui

    =D4=DA 2012=C4= =EA9=D4=C214=C8=D5=D0=C7=C6=DA=CE=E5=A3=ACLorenzo Colitti <lorenzo@google.com> =D0=B4=B5=C0=A3=BA
    > On Fri, Sep 14, 2012 at 4:06 PM, Hui Deng <denghui02@gmail.com> wrote:
    >>
    >> W= hen 464xlat integrates with other IPv6only access transition technology suc= h as BIH, IPv4-only app with BIHprocessing could communicate with IPv6-serv= er. A DNS query initiated by theapplication would be processed by BIH ENR t= o generate both A and AAAA and needsconsidering below
    >> 1) When A responses are received, 464xlatwould take the role
    &g= t;> 2) When A and AAAA responses are received,464xlat would take the rol= e
    >> 3) When only AAAA responses are received,it's the case of= IPv4-IPv6 communication. ENR embedded in BIH would interceptsAAAA records = and create the synthetic IPv4 address and corresponding themapping. Afterwa= rds, IPv4 applications send the packages to the synthetic IPv4address. Prot= ocol translator would take the rule of IPv4-IPv6 translation andachieve IPv= 4-IPv6 communication.
    >
    > Has this been tested and verified to work? Is there an impleme= ntation?
    > We should not include text in a BCP if it has never been i= mplemented or tested. --485b397dd697d0781604c9b2efe8-- From internet-drafts@ietf.org Sat Sep 15 11:05:04 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57EBE21F84B5; Sat, 15 Sep 2012 11:05:04 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R36W0FhOdDii; Sat, 15 Sep 2012 11:05:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C322421F84BF; Sat, 15 Sep 2012 11:05:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120915180503.23774.22275.idtracker@ietfa.amsl.com> Date: Sat, 15 Sep 2012 11:05:03 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-enterprise-incremental-ipv6-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Sep 2012 18:05:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Enterprise IPv6 Deployment Guidelines Author(s) : Kiran K. Chittimaneni Tim Chown Lee Howard Victor Kuarsingh Yanick Pouffary Eric Vyncke Filename : draft-ietf-v6ops-enterprise-incremental-ipv6-01.txt Pages : 28 Date : 2012-09-15 Abstract: Enterprise network administrators worldwide are in various stages of preparing for or deploying IPv6 into their networks. The administrators face different challenges than operators of Internet access providers, and have reasons for different priorities. The overall problem for many administrators will be to offer Internet- facing services over IPv6, while continuing to support IPv4, and while introducing IPv6 access within the enterprise IT network. The overall transition will take most networks from an IPv4-only environment to a dual stack network environment and potentially an IPv6-only operating mode. This document helps provide a framework for enterprise network architects or administrators who may be faced with many of these challenges as they consider their IPv6 support strategies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-enterprise-incremental-ip= v6 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-enterprise-incremental-ipv6-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-enterprise-incremental-= ipv6-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From achatz@forthnetgroup.gr Sun Sep 16 03:05:32 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A273621F84DC for ; Sun, 16 Sep 2012 03:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.141 X-Spam-Level: X-Spam-Status: No, score=-1.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rMEM866wVBep for ; Sun, 16 Sep 2012 03:05:31 -0700 (PDT) Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.107]) by ietfa.amsl.com (Postfix) with ESMTP id 4615621F84D5 for ; Sun, 16 Sep 2012 03:05:30 -0700 (PDT) Received: from mx-av-03.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-05.forthnet.gr (8.14.4/8.14.4) with ESMTP id q8GA5SjP019850; Sun, 16 Sep 2012 13:05:28 +0300 Received: from MX-IN-02.forthnet.gr (mx-in-02.forthnet.gr [193.92.150.185]) by mx-av-03.forthnet.gr (8.14.3/8.14.3) with ESMTP id q8GA5Scu019317; Sun, 16 Sep 2012 13:05:28 +0300 Received: from [192.168.1.2] (178.128.252.222.dsl.dyn.forthnet.gr [178.128.252.222]) (authenticated bits=0) by MX-IN-02.forthnet.gr (8.14.4/8.14.4) with ESMTP id q8GA5CNb002653; Sun, 16 Sep 2012 13:05:18 +0300 Authentication-Results: MX-IN-02.forthnet.gr smtp.mail=achatz@forthnetgroup.gr; auth=pass (PLAIN) Message-ID: <5055A457.9070408@forthnetgroup.gr> Date: Sun, 16 Sep 2012 13:05:11 +0300 From: Tassos Chatzithomaoglou User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120909 Firefox/15.0.1 SeaMonkey/2.12.1 MIME-Version: 1.0 To: v6ops@ietf.org References: <201208091245.q79Cj1g08088@ftpeng-update.cisco.com> In-Reply-To: <201208091245.q79Cj1g08088@ftpeng-update.cisco.com> Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: draft-ietf-v6ops-enterprise-incremental-ipv6@tools.ietf.org Subject: [v6ops] comments about draft-ietf-v6ops-enterprise-incremental-ipv6-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Sep 2012 10:05:32 -0000

    Generally i like the phased approach of this draft.
    We have done similar phases in our own corporate network, although not all sub-phases apply to us.

    Here are my general comments...

    3.6 should be moved in the beginning. Project (not program) planning should be the first thing to do.

    Security parts got me a little bit confused. There are things are are repeated many times, although applicable at all of them.
    Maybe put them under a general security section and just add differences per phase.
    Also it would be better if the security section was in the same position at every phase (i.e. last or first).

    I didn't see any reference (or better warning) on operational costs vs needs. Introduction includes 1-2 sentences, but i don't find them always applicable.
    This may be an easy job for some networks, but in same cases it will take time and effort...without having a good reason.
    I understand that this might push back the willing of an enterprise to move to IPv6, but every case should be examined under a general umbrella.
    An administrator might be considering IPv6 on his own, but this doesn't necessarily apply to the whole enterprise.

    I got the impressions throughout the text that translation is preferred vs tunneling, something i agree with in most cases, and especially in isp environments.
    But there are many enterprises, where the tunneling approach might be a better/easier/cheaper solution.

    Lastly, until IPv6 is fully implemented into the enterprise, a recommendation should be made about the expansion/maintenance of IPv4 network/systems in such a way that the IPv6 deployment is taken into account.


    And some specific comments....


     The most common drivers are due
   to the fact that when Internet service providers, including mobile
   wireless carriers, run out of IPv4 addresses, they will provide
   native IPv6 and non-native IPv4.
    I don't think most enterprises will fall under this type (non-native IPv4) of connectivity.
    ISPs are mostly facing issues with residential services in terms of address availability.


     The non-native IPv4 service may be
   NAT64, NAT444, Dual-stack Lite, or other transition technology, but
   whether tunneled or translated, the native traffic will be perform
   better and more reliably than non-native.
    This assumption poses questions whether all those translation/tunneling solutions by IETF are worth considering.
    Maybe add a probability factor there.


      A specific case of congruence is the IPv6 ULA [RFC4193] and IPv4
   private addressing [RFC1918] that do not provide any security by
   'magic'.  In both case, the edge router must apply strict data plane
   and routing policy to block those private addresses to leave and
   enter the network.  This filtering can be done by the enterprise or
   by the ISP.
    IPv6 addresses can be spoofed as easily as IPv4 addresses and there
   are packets with bogons IPv6 addresses (see [CYMRU]).  The anti-bogon
   filtering must be done in the data and routing planes.  It can be
   done by the enterprise or by the ISP.

    case = > cases
    edge router => border routers

    Might want to rephrase "data" as "forwarding" or "routing" as "control" in order to use common wording.

    Some recommendations are expressed like "can be done by the enterprise or by the ISP". I think it should be noted that the enterprise should always try to do these, regardless of the ISP. Ok, it might not be always easy for the enterprise to do these (due to expertise, costs, etc), but i don't think the enterprise should solely depend on the ISP doing these.

    An alternative is to try to prevent the use
   of privacy extension addresses is to send the Router Advertisement
   with the M-bit set (to force the use of DHCPv6 to get an address) and
   with all advertized prefixes without the A-bit set (to prevent the
   use of stateless auto-configuration); this technique requires that
   all hosts support stateful DHCPv6.
    I think it's better to remove the M-bit reference and just refer DHCPv6.
    If i remember right, there was a talk about the M/O bits being controversial lately

    Another DoS
   vulnerabilities are related to NDP cache exhaustion
   ([I-D.gashinsky-v6ops-v6nd-problems]) and they can be mitigated by
   careful tuning of the NDP cache.  In 2012, there are already several
   vendors offering those features on their switches.
    RFC 6583 proposes various options for mitigation of NDP issues; i think a general reference should be made instead.


    The enterprise administrator will want to evaluate whether the
   enterprise will request address space from its ISP (or Local Internet
   Registry (LIR)), or whether to request address space from the local
   Internet Registry (whether a Regional Internet Registry such as
   AfriNIC, APNIC, ARIN, LACNIC, or RIPE-NCC, or a National Internet
   Registry, operated in some countries).

    Probably it should be rewritten as

    The enterprise administrator will want to evaluate whether the
   enterprise will request address space from a LIR (Local Internet
   Registry, such as an ISP), a RIR (Regional Internet Registry, such as
   AfriNIC, APNIC, ARIN, LACNIC, or RIPE-NCC) or a NIR (National Internet Registry, operated in some countries).



    Each location, no matter how small, should get at least a /48.
    Does this apply to every enterprise?
    Maybe add a reference to RFC6177 & RFC 5375?


       All user access networks MUST be a /64.  Point-to-point links without
   MAC addresses (this is where Neighbor Discovery Protocol does not
   run) SHOULD be a /127 (see also [RFC6164]).

    Why a reference on mac-addresses? Can't ethernet p2p links use /127?



    Also, for any part of the network where
   DNS (or reverse DNS) zones may be delegated, it is important to
   delegate addresses on nibble boundaries (this is on a multiple of 4
   bits), to ensure propose name delegation.

    propose => proposed?
    Maybe want to explain this a little bit more?

       ** Add some comment about setting MTU to 1280 to avoid tunnel pMTUd
   black holes? **

    Personally, i don't like the idea of setting the MTU to the minimum. It's better to describe the issues and the importance of ICMP/pMTUd and leave the MTU minimization as a last resort.

     The security policies must be congruent for IPv4
   and IPv6 (else the attacker will use the less protected protocol
   stack) except that ICMPv6 messages must be allowed through and to the
   filtering device (see [RFC4890]):

    except that ICMPv6 messages => except that some ICMPv6 messages 

    The peering router must also implement anti-spoofing technique based
   on [RFC2827].

    What's a peering router in the enterprise? There is only a single reference of it. Are you referring to border routers?


    This includes the use of IP flow export
   [RFC5102] to detect abnormal traffic pattern (such as port scanning,
   SYN-flooding)

    IP flow export => IP Flow Information eXport (IPFIX)



    While
   technology and process transformations are taking place is it
   critical that people training takes place as well.

    is it critical => it is critical

       malevolent person has now two attack vectors: IPv4 and IPv6.  This
   simply means that all routers and hosts operating in a dual-stack
   environment with both protocol families enabled (even if by default)
   must have a congruent security policy for both protocol version.

    version => versions


     There may be a registration
   fee for requesting provider-independent (PI) space from and NIR/RIR,
    and => a

    In the case of PI, the organization will need to support BGP based
   connectivity for the most part since the address space is assigned
   direction from the Regional Registry to the local network.
    direction => directly

    Native IPv6
   connectivity is preferred since it provides the most rebuts form of
   connectivity.

    rebuts => robust ?


    --
Tassos

    From internet-drafts@ietf.org Mon Sep 17 06:46:04 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6692921F8685; Mon, 17 Sep 2012 06:46:04 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c5kwWXJA1LpE; Mon, 17 Sep 2012 06:46:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 006AB21F8680; Mon, 17 Sep 2012 06:46:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120917134603.12963.35955.idtracker@ietfa.amsl.com> Date: Mon, 17 Sep 2012 06:46:03 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-icp-guidance-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 13:46:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : IPv6 Guidance for Internet Content and Application Servi= ce Providers Author(s) : Brian Carpenter Sheng Jiang Filename : draft-ietf-v6ops-icp-guidance-04.txt Pages : 24 Date : 2012-09-17 Abstract: This document provides guidance and suggestions for Internet Content Providers and Application Service Providers who wish to offer their service to both IPv6 and IPv4 customers. Many of the points will also apply to hosting providers, or to any enterprise network preparing for IPv6 users. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-icp-guidance There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-icp-guidance-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-icp-guidance-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From brian.e.carpenter@gmail.com Mon Sep 17 06:52:09 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E578521F867F for ; Mon, 17 Sep 2012 06:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.299 X-Spam-Level: X-Spam-Status: No, score=-103.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zsqnE3vR1RRj for ; Mon, 17 Sep 2012 06:52:07 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id F3A1421F863F for ; Mon, 17 Sep 2012 06:52:06 -0700 (PDT) Received: by iec9 with SMTP id 9so1416571iec.31 for ; Mon, 17 Sep 2012 06:52:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=qe5ZVSpd1Ilvyi4uRWnOrf7R3cuOb3aleRuljaSoCd0=; b=0o4hawvn+K00Ssq/Siyk8VXbUitqOtRWQrkIjrT/9AoLLmPpncQQInWJi+MWX19d65 RcSi9wgX83cchztaNBVOZGfQJ4DKlX8bMqeZ3ajw8mHwelZqYpykDWhc7cGis/FfjNRG GmJv6QliEQfvD4r2AJ2i7x1mGKANUzUMnU41RO8U5tfRSK646ZeiVVQJlD0W+sHlOj4S ooQ0Vdw8FYm34bqOnzprmh4+KVQerTeQXL+1FlD/+qGRVrqx7E2RtiKFE+dFh679sth4 uSbx9Xli3Lqbxdmvvdzs52s9B2EGrft0ocLyI5vUa3sngIq2QmI18Ln8lKbj5PWsN1ZN RJ0g== Received: by 10.50.159.201 with SMTP id xe9mr6977035igb.63.1347889926323; Mon, 17 Sep 2012 06:52:06 -0700 (PDT) Received: from [10.255.25.102] (50-76-68-140-static.hfc.comcastbusiness.net. [50.76.68.140]) by mx.google.com with ESMTPS id ez8sm10427200igb.17.2012.09.17.06.52.04 (version=SSLv3 cipher=OTHER); Mon, 17 Sep 2012 06:52:05 -0700 (PDT) Message-ID: <50572B04.8080006@gmail.com> Date: Mon, 17 Sep 2012 14:52:04 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: v6ops@ietf.org References: <20120917134603.12963.35955.idtracker@ietfa.amsl.com> In-Reply-To: <20120917134603.12963.35955.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-icp-guidance-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 13:52:09 -0000 Hi, This version includes the change to the text on PI addresses that I sent to the list on Sept. 6 and a couple of other minor changes from the end of the WGLC discussion. Chairs: the authors believe that this satisfies all the comments received from the WG to date. Regards Brian + Sheng On 17/09/2012 14:46, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IPv6 Operations Working Group of the IETF. > > Title : IPv6 Guidance for Internet Content and Application Service Providers > Author(s) : Brian Carpenter > Sheng Jiang > Filename : draft-ietf-v6ops-icp-guidance-04.txt > Pages : 24 > Date : 2012-09-17 > > Abstract: > This document provides guidance and suggestions for Internet Content > Providers and Application Service Providers who wish to offer their > service to both IPv6 and IPv4 customers. Many of the points will > also apply to hosting providers, or to any enterprise network > preparing for IPv6 users. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-icp-guidance > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-v6ops-icp-guidance-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-icp-guidance-04 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From ietf-secretariat@ietf.org Mon Sep 17 12:56:20 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B54F821E8044; Mon, 17 Sep 2012 12:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.35 X-Spam-Level: X-Spam-Status: No, score=-102.35 tagged_above=-999 required=5 tests=[AWL=-0.351, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i4UhwGWYibXz; Mon, 17 Sep 2012 12:56:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3640221E8037; Mon, 17 Sep 2012 12:56:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120917195620.22823.34712.idtracker@ietfa.amsl.com> Date: Mon, 17 Sep 2012 12:56:20 -0700 Cc: iaoc@ietf.org, opsec@ietf.org, sidr@ietf.org, v6ops@ietf.org, wgchairs@ietf.org Subject: [v6ops] IETF Large Interim Meeting - Accommodations Information X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 19:56:20 -0000 OPSEC, SIDR and V6OPS Interim Meeting Amsterdam, The Netherlands 29 September 2012 Venue: Hotel Okura Amsterdam (www.okura.nl) Ferdinand Bolstraat 333 1072 LH Amsterdam The Netherlands 1. Registration 2. Accommodations - Information now available! 3. Meeting Schedule 1. Registration A. Fee: $100 USD B. Register online at: http://www.ietf.org/registration/lim2012/ietfre= g.py C. Online Registration and Payment closes on 28 September 2012 D. On Site Registration starting Saturday, 29 September at 8:00 AM 2. Accommodations A block of rooms is being held at the Hotel Okura Amsterdam (meeting ve= nue) for the nights of September 28 and 29. Rate: 195 EUR [256 USD; 20,065 JPY] Rate includes breakfast and guest room wireless internet. To make your reservation on line, please go to: www.okura.nl Group Code: IETF2012 Reservations cut-off date: 21 September 2012 Guest Cancellation: - Reservations may=C2=A0be changed up to 1 week prior to the event with= out penalty. - 50% of reservation value penalty for cancellation less than 14 days a= nd greater than 7 days prior to event. - 80% of reservation value penalty for cancellation less than 7 days an= d greater than 3 days prior to event. - 100% of reservation value penalty for cancellation less than 3 days p= rior to event or non-arrival or no-show. - In case of early departure, the full value of the reservation will be= charged to the guest. If you have any problems making your reservation, please send a message to = agenda@ietf.org 3. Meeting Schedule 0900-1700 CEST SIDR 0900-1130 CEST OPSEC 1330-1630 CEST V6OPS From ietfc@btconnect.com Tue Sep 18 02:20:54 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF0F21F874C for ; Tue, 18 Sep 2012 02:20:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.207 X-Spam-Level: X-Spam-Status: No, score=-3.207 tagged_above=-999 required=5 tests=[AWL=-0.208, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0BQlFESaH8LL for ; Tue, 18 Sep 2012 02:20:54 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe002.messaging.microsoft.com [216.32.180.12]) by ietfa.amsl.com (Postfix) with ESMTP id B505C21F874A for ; Tue, 18 Sep 2012 02:20:53 -0700 (PDT) Received: from mail112-va3-R.bigfish.com (10.7.14.243) by VA3EHSOBE014.bigfish.com (10.7.40.64) with Microsoft SMTP Server id 14.1.225.23; Tue, 18 Sep 2012 09:20:52 +0000 Received: from mail112-va3 (localhost [127.0.0.1]) by mail112-va3-R.bigfish.com (Postfix) with ESMTP id B9C443800EB; Tue, 18 Sep 2012 09:20:52 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.249.85; KIP:(null); UIP:(null); IPV:NLI; H:AMSPRD0710HT005.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -27 X-BigFish: PS-27(zz98dI9371Ic89bh936eI168aJ542M1432I1418Id6f1izz1202h1d1ah1d2ahzz8275ch1033IL17326ah8275bh8275dhz2dh2a8h5a9h668h839hd24hf0ah107ah1177h1179h1288h12a5h12a9h12bdh304l1155h) Received: from mail112-va3 (localhost.localdomain [127.0.0.1]) by mail112-va3 (MessageSwitch) id 1347960051186756_4137; Tue, 18 Sep 2012 09:20:51 +0000 (UTC) Received: from VA3EHSMHS029.bigfish.com (unknown [10.7.14.240]) by mail112-va3.bigfish.com (Postfix) with ESMTP id 2B387360045; Tue, 18 Sep 2012 09:20:51 +0000 (UTC) Received: from AMSPRD0710HT005.eurprd07.prod.outlook.com (157.56.249.85) by VA3EHSMHS029.bigfish.com (10.7.99.39) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 18 Sep 2012 09:20:48 +0000 Received: from CH1PRD0710HT004.namprd07.prod.outlook.com (157.56.245.5) by pod51017.outlook.com (10.255.160.168) with Microsoft SMTP Server (TLS) id 14.16.190.9; Tue, 18 Sep 2012 09:20:41 +0000 Message-ID: <01d101cd957e$f22a78a0$4001a8c0@gateway.2wire.net> From: t.petch To: Ray Hunter References: <6BD4EF08-99CE-4485-80FA-23A77564DDDB@laposte.net> <5050B718.5050003@globis.net> Date: Tue, 18 Sep 2012 10:21:04 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.245.5] Content-Transfer-Encoding: quoted-printable X-OriginatorOrg: btconnect.com Cc: IPv6 Ops WG Subject: Re: [v6ops] 464XLAT removing IPv6 LAN scope X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 09:20:54 -0000 ----- Original Message ----- From: "Ray Hunter" To: "R=E9mi Despr=E9s" Cc: "IPv6 Ops WG" Sent: Wednesday, September 12, 2012 5:23 PM The idea certainly has merit, but I'm not yet fully convinced about combining this with the 464XLAT draft. The draft started off reserving one single IANA IID for IPv4 to IPv6 translation. Now the reservation has expanded to cover the RFC1918 space. If the IPv4 range used on networks behind the CLAT is limited to RFC1918 space, and it is indeed kept strictly local, why do we need to reserve the complete 3 RFC1918 ranges for use as IID's (to be used to create unique IPv6 addresses when the IPv6 prefix assigned to the CLAT)? Why can't everyone just use the identical set of 192.168/16 IPv4 prefixes behind their own CLAT? On the other extreme: if 464XLAT were to allow inbound PLAT to CLAT IPv4 - IPv4 sessions (and not just support a hub and spoke model for outbound only sessions via the PLAT) why not reserve the entire /32 IPv4 address space as IANA IID's for use in generating unique IPv6 addresses for IPv4 nodes located behind a CLAT? An equivalent approach has certainly been applied successfully in other transition mechanisms. IHMO I think a lack of a clear answer to these extreme cases demonstrates it's simply too early to reserve IANA IID space right now. Ray I never saw a direct response to your questions. I think that the answer is clear but that it depends on the assumptions made. You could reserve the entire /32 IPv4 space and then you could allow anyone to attach anything downstream. You could limit downstream IPv4 attachments to 192.168/16 but that may prove unduly restrictive - it depends on what is out there - I know of uses of 10/8 in other contexts and there could be some here. Allowing all RFC1918 addresses looks like a good compromise, that an awful lot of 'CPE' boxes use this range and so by allowing that range, most uses are covered. Probably not all, but probably enough for most if not almost all cases. This is, for me, a judgement call (based, in my case, on limited data:-(. Tom Petch regards, RayH R=E9mi Despr=E9s wrote: > > 2012-09-12 15:54, Lorenzo Colitti: > >> On Wed, Sep 12, 2012 at 9:58 PM, Cameron Byrne > > wrote: >> >> All that said, is the wg ok with accepting with Remi's solution? >> >> Silence means no support. >> >> If we can make it work, I think it has advantages. But it requires >> that the text be written and that we as a WG think the issues >> through, try to figure out if there are any corner cases, etc. DAD >> is simple and we know how it works, but we haven't devoted much >> thought to Remi's solution because it hasn't even been written in the >> draft yet. > > Note that, as reminded to Cameron in the mast mail I sent, a text of > what the draft could become remains available in > www.ietf.org/mail-archive/web/v6ops/current/msg14077.html > . > > RD > > >> Realistically, what that means is that the draft will be delayed. >> >> What are the alternatives? >> >> 1. Stay silent on sharing one /64 and let implementations do their thing. >> 2. Decide that for now it's more practical to share a /64 with DAD. >> 3. Remi's "reserve 3 IID ranges" proposal. >> >> Anything else? > _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From internet-drafts@ietf.org Tue Sep 18 08:05:29 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC1421E80D2; Tue, 18 Sep 2012 08:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.502 X-Spam-Level: X-Spam-Status: No, score=-102.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQOKGtSLYZt4; Tue, 18 Sep 2012 08:05:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B690221E80D3; Tue, 18 Sep 2012 08:05:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120918150528.29819.71058.idtracker@ietfa.amsl.com> Date: Tue, 18 Sep 2012 08:05:28 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-08.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 15:05:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : 464XLAT: Combination of Stateful and Stateless Translati= on Author(s) : Masataka Mawatari Masanobu Kawashima Cameron Byrne Filename : draft-ietf-v6ops-464xlat-08.txt Pages : 14 Date : 2012-09-18 Abstract: This document describes an architecture (464XLAT) for providing limited IPv4 connectivity across an IPv6-only network by combining existing and well-known stateful protocol translation RFC 6146 in the core and stateless protocol translation RFC 6145 at the edge. 464XLAT is a simple and scalable technique to quickly deploy limited IPv4 access service to IPv6-only edge networks without encapsulation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-464xlat There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-464xlat-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From cb.list6@gmail.com Tue Sep 18 08:29:52 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0577621F874F for ; Tue, 18 Sep 2012 08:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.046 X-Spam-Level: X-Spam-Status: No, score=-3.046 tagged_above=-999 required=5 tests=[AWL=-0.047, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RfY-BL0yYhhL for ; Tue, 18 Sep 2012 08:29:51 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 15AFF21F8754 for ; Tue, 18 Sep 2012 08:29:50 -0700 (PDT) Received: by lahm15 with SMTP id m15so5387535lah.31 for ; Tue, 18 Sep 2012 08:29:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=F1IZOFFeOm4vR1sH8X4r7tYLUUt4O/DGI6cIWPQ34FQ=; b=i+cjKUSj+Wjee9HignVqgQ+yUchWt07LyeVarxgBUbnvmk4CpEPfp0u4FReEF4C672 /LayCB74CI2/5kUR/Nkx1WNZBsJeqaYxwPgUA3Ww99sgIfwlLz4wOqF0tbiCQEHvpKdx qvKcJ21LAfK8eNZ2c0Hv9WID8zCjC+eKXbEaYDuT4k2K+D4eMwhea2XoRtz9AgAInbtx VI39i1xqOlmdUycZQFyol4mETwr8buyP2EdCH8cakol4xYcaeBNPUk2a6HN5ucdrAWTi R0qDdTEJoOmt+tuqe59i6TIfWdHXNcoc8MCr61w5UkeT1KPuD3mJZODHMftEeRGxlGn1 4stw== MIME-Version: 1.0 Received: by 10.152.106.81 with SMTP id gs17mr227571lab.2.1347982190003; Tue, 18 Sep 2012 08:29:50 -0700 (PDT) Received: by 10.112.49.66 with HTTP; Tue, 18 Sep 2012 08:29:49 -0700 (PDT) In-Reply-To: <20120918150528.29819.71058.idtracker@ietfa.amsl.com> References: <20120918150528.29819.71058.idtracker@ietfa.amsl.com> Date: Tue, 18 Sep 2012 08:29:49 -0700 Message-ID: From: Cameron Byrne To: IPv6 Ops WG Content-Type: text/plain; charset=ISO-8859-1 Subject: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-464xlat-08.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 15:29:52 -0000 Dear v6ops WG, We have submitted -08 of 464XLAT. Since this is a WG document, we feel obliged to make the following changes in the -08 version of the 464XLAT I-D to reflect the rough consensus of ideas. The following 2 material changes have been made: 1. BIH reference has been removed. Tim, Woj, Maoke, Lorenzo, Joel, Randy, Tom, and others have requested that BIH reference be removed. The authors believe BIH is a worthy and complimentary technology for 464XLAT. Thank you Gang and Hui for helping us understand BIH and the implementation progress. We believe a reference to BIH adds no harm to 464XLAT. Yet, BIH is its own standard track RFC. It is unfortunate that we cannot reference the 464XLAT reader to BIH. We think this idea will be needed and useful, but it appears the WG objects to the reference. 2. IPv6 WAN address sharing has been removed, including IANA references and ND Proxy references. Hermant, Woj, and others have found issue with /64 address sharing with ND Proxy. Remi's method is clever and technically astute, but it did not gain WG support. That said, reflecting on the I-D, we could not include any references to /64 sharing since that is not the core of the I-D and rightfully should be its own I-D. We strongly encourage the lesson learned and analysis of this area be carried forward in a properly scoped separate I-D. We originally added Remi's method and BIH because we found them to be technically worthy, and we are removing them not because of revelation about their worthiness, but due to rough consensus of the WG and a greater focus on the narrow scope of 464XLAT. Thanks again to all the WG participants for taking the time to make this I-D better. We believe these edits address the feedback received in last call. CB ---------- Forwarded message ---------- From: Date: Tue, Sep 18, 2012 at 8:05 AM Subject: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-08.txt To: i-d-announce@ietf.org Cc: v6ops@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : 464XLAT: Combination of Stateful and Stateless Translation Author(s) : Masataka Mawatari Masanobu Kawashima Cameron Byrne Filename : draft-ietf-v6ops-464xlat-08.txt Pages : 14 Date : 2012-09-18 Abstract: This document describes an architecture (464XLAT) for providing limited IPv4 connectivity across an IPv6-only network by combining existing and well-known stateful protocol translation RFC 6146 in the core and stateless protocol translation RFC 6145 at the edge. 464XLAT is a simple and scalable technique to quickly deploy limited IPv4 access service to IPv6-only edge networks without encapsulation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-464xlat There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-464xlat-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From sarikaya2012@gmail.com Tue Sep 18 09:12:38 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD35E21E80E2 for ; Tue, 18 Sep 2012 09:12:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.05 X-Spam-Level: X-Spam-Status: No, score=-3.05 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qwEUF2txh7o for ; Tue, 18 Sep 2012 09:12:35 -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 43C5D21E80DB for ; Tue, 18 Sep 2012 09:12:35 -0700 (PDT) Received: by iabz21 with SMTP id z21so18624iab.31 for ; Tue, 18 Sep 2012 09:12:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=gIHsVz1V84UPGlOb167DZ+oxwOZvDG/saiyJqZe5JjU=; b=kkwLWRyS3mAuSFf4L3/f2U6JJrzmbfRLRt0UYpl7eLHzLZ6z3rx3krakxphgxMwZ3p M5dfpXCpq89SclxsnBU+a6PrXDtnha03iUmjWUtC2vc3Ms4bNzI297qcapBJH+qH4u7i 7/7dOdHVOSYCeeSh50zhp03zI8I91HQ1YnQqNCftyNVXKTuW24DKgPzBWwEkuGyH2L92 KUOkKWsDz0nwugiJdMMn6riN5YKGrhgR/tOmxJQAN8gL1+80LRXfv+tPratbbU01Mnxu DtqsNBg7WA6iuz6JNbH6riDYC/gorLB6Vy23Awut5BXIa/GcIkn2M98Po4mQoUx94Tad CxFA== MIME-Version: 1.0 Received: by 10.50.95.231 with SMTP id dn7mr139627igb.37.1347984754687; Tue, 18 Sep 2012 09:12:34 -0700 (PDT) Received: by 10.231.55.70 with HTTP; Tue, 18 Sep 2012 09:12:34 -0700 (PDT) In-Reply-To: References: <20120918150528.29819.71058.idtracker@ietfa.amsl.com> Date: Tue, 18 Sep 2012 11:12:34 -0500 Message-ID: From: Behcet Sarikaya To: Cameron Byrne Content-Type: text/plain; charset=ISO-8859-1 Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-464xlat-08.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 16:12:38 -0000 Hi Cameron, We like whatever you do :-). But this one I have concerns. On Tue, Sep 18, 2012 at 10:29 AM, Cameron Byrne wrote: > Dear v6ops WG, > > We have submitted -08 of 464XLAT. > > Since this is a WG document, we feel obliged to make the following > changes in the -08 version of the 464XLAT I-D to reflect the rough > consensus of ideas. > > The following 2 material changes have been made: > > > 1. BIH reference has been removed. > > Tim, Woj, Maoke, Lorenzo, Joel, Randy, Tom, and others have requested > that BIH reference be removed. The authors believe BIH is a worthy > and complimentary technology for 464XLAT. Thank you Gang and Hui for > helping us understand BIH and the implementation progress. We believe > a reference to BIH adds no harm to 464XLAT. > > Yet, BIH is its own standard track RFC. It is unfortunate that we > cannot reference the 464XLAT reader to BIH. We think this idea will > be needed and useful, but it appears the WG objects to the reference. > Such consensus judgements are done by the chairs in IETF. Besides, my understanding was that Lorenzo had removed his objection because of an implementation, at least just finished or in the works, or whatever. Regards, Behcet From joelja@bogus.com Tue Sep 18 09:43:50 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4448121F860D for ; Tue, 18 Sep 2012 09:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8tXVhxu66scY for ; Tue, 18 Sep 2012 09:43:49 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id A207621F8600 for ; Tue, 18 Sep 2012 09:43:49 -0700 (PDT) Received: from joels-MacBook-Air.local (host-64-47-153-50.masergy.com [64.47.153.50]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q8IGhk84041216 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 18 Sep 2012 16:43:46 GMT (envelope-from joelja@bogus.com) Message-ID: <5058A4BD.90003@bogus.com> Date: Tue, 18 Sep 2012 09:43:41 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120821 Thunderbird/15.0 MIME-Version: 1.0 To: Cameron Byrne References: <20120918150528.29819.71058.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Tue, 18 Sep 2012 16:43:46 +0000 (UTC) Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-464xlat-08.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 16:43:50 -0000 Thank you. joel On 9/18/12 8:29 AM, Cameron Byrne wrote: > Dear v6ops WG, > > We have submitted -08 of 464XLAT. > > Since this is a WG document, we feel obliged to make the following > changes in the -08 version of the 464XLAT I-D to reflect the rough > consensus of ideas. > > The following 2 material changes have been made: > > > 1. BIH reference has been removed. > > Tim, Woj, Maoke, Lorenzo, Joel, Randy, Tom, and others have requested > that BIH reference be removed. The authors believe BIH is a worthy > and complimentary technology for 464XLAT. Thank you Gang and Hui for > helping us understand BIH and the implementation progress. We believe > a reference to BIH adds no harm to 464XLAT. > > Yet, BIH is its own standard track RFC. It is unfortunate that we > cannot reference the 464XLAT reader to BIH. We think this idea will > be needed and useful, but it appears the WG objects to the reference. > > > 2. IPv6 WAN address sharing has been removed, including IANA > references and ND Proxy references. > > Hermant, Woj, and others have found issue with /64 address sharing > with ND Proxy. Remi's method is clever and technically astute, but it > did not gain WG support. That said, reflecting on the I-D, we could > not include any references to /64 sharing since that is not the core > of the I-D and rightfully should be its own I-D. We strongly > encourage the lesson learned and analysis of this area be carried > forward in a properly scoped separate I-D. > > We originally added Remi's method and BIH because we found them to be > technically worthy, and we are removing them not because of revelation > about their worthiness, but due to rough consensus of the WG and a > greater focus on the narrow scope of 464XLAT. > > Thanks again to all the WG participants for taking the time to make > this I-D better. We believe these edits address the feedback received > in last call. > > CB > > > > ---------- Forwarded message ---------- > From: > Date: Tue, Sep 18, 2012 at 8:05 AM > Subject: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-08.txt > To: i-d-announce@ietf.org > Cc: v6ops@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IPv6 Operations Working Group of the IETF. > > Title : 464XLAT: Combination of Stateful and > Stateless Translation > Author(s) : Masataka Mawatari > Masanobu Kawashima > Cameron Byrne > Filename : draft-ietf-v6ops-464xlat-08.txt > Pages : 14 > Date : 2012-09-18 > > Abstract: > This document describes an architecture (464XLAT) for providing > limited IPv4 connectivity across an IPv6-only network by combining > existing and well-known stateful protocol translation RFC 6146 in the > core and stateless protocol translation RFC 6145 at the edge. 464XLAT > is a simple and scalable technique to quickly deploy limited IPv4 > access service to IPv6-only edge networks without encapsulation. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-464xlat > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-08 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-464xlat-08 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From ietf-secretariat@ietf.org Tue Sep 18 12:01:58 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F9D821E8103; Tue, 18 Sep 2012 12:01:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.315 X-Spam-Level: X-Spam-Status: No, score=-102.315 tagged_above=-999 required=5 tests=[AWL=-0.316, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bE2gWA4GHP33; Tue, 18 Sep 2012 12:01:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5FA221E80C1; Tue, 18 Sep 2012 12:01:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120918190157.21518.15763.idtracker@ietfa.amsl.com> Date: Tue, 18 Sep 2012 12:01:57 -0700 Cc: iaoc@ietf.org, opsec@ietf.org, sidr@ietf.org, v6ops@ietf.org, wgchairs@ietf.org Subject: [v6ops] IETF Large Interim Meeting - OPSEC, SIDR and V6OPS X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 19:01:58 -0000 OPSEC, SIDR and V6OPS Interim Meeting Amsterdam, The Netherlands 29 September 2012 Venue: Hotel Okura Amsterdam (www.okura.nl) Ferdinand Bolstraat 333 1072 LH Amsterdam The Netherlands 1. Registration 2. Accommodations - Reservations Cutoff: 21 September 3. Meeting Schedule 1. Registration A. Fee: $100 USD B. Register online at: http://www.ietf.org/registration/lim2012/ietfreg= .py C. Online Registration and Payment closes on 28 September 2012 D. On Site Registration starting Saturday, 29 September at 8:00 AM 2. Accommodations A block of rooms is being held at the Hotel Okura Amsterdam (meeting ven= ue) for the nights of September 28 and 29. Rate: 195 EUR [256 USD; 20,065 JPY] Rate includes breakfast and guest room wireless internet but excludes = 5% city tax. To make your reservation on line, please go to: www.okura.nl Group Code: IETF2012 Reservations cut-off date: 21 September 2012 Guest Cancellation: - Reservations may be changed up to 1 week prior to the event without pe= nalty. (You can change, not cancel, the reservation, i.e. change arrival, departure dates or name, up to 1 week without penalty but not cancel the reservation without penalty.) - 50% of reservation value penalty for cancellation less than 14 days an= d greater than 7 days prior to event. If you cancel, not change, the reserv= ation less than 14 days but more than 7 days prior to the event you will be= charged 50% of the total reservation fee. - 80% of reservation value penalty for cancellation less than 7 days and= greater than 3 days prior to event. If you cancel, not change, the reserva= tion less than 7 days prior to the event you will be charged 80% of the tot= al reservation fee. - 100% of reservation value penalty for cancellation less than 3 days pr= ior to event or non-arrival or no-show. - In case of early departure, the full value of the reservation will be = charged to the guest. If you have any problems making your reservation, please send a message to = agenda@ietf.org 3. Meeting Schedule 0900-1700 CEST SIDR 0900-1130 CEST OPSEC 1330-1630 CEST V6OPS From joelja@bogus.com Wed Sep 19 08:19:21 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDE3021F8622 for ; Wed, 19 Sep 2012 08:19:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oPGIxF9p8tz9 for ; Wed, 19 Sep 2012 08:19:21 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 48B3C21F8650 for ; Wed, 19 Sep 2012 08:19:21 -0700 (PDT) Received: from joels-MacBook-Air.local (105.sub-166-250-38.myvzw.com [166.250.38.105]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q8JFIpPj055471 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 19 Sep 2012 15:19:17 GMT (envelope-from joelja@bogus.com) Message-ID: <5059E257.8020804@bogus.com> Date: Wed, 19 Sep 2012 08:18:47 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120821 Thunderbird/15.0 MIME-Version: 1.0 To: Cameron Byrne References: <20120918150528.29819.71058.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Wed, 19 Sep 2012 15:19:18 +0000 (UTC) Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-464xlat-08.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2012 15:19:21 -0000 diff2 is here: http://tools.ietf.org/rfcdiff?url2=draft-ietf-v6ops-464xlat-08.txt We've got 873 or so messages documenting this discussion 195 of which are from one person. I think we have a pretty idea where all the active parties stand, we just need to capture that. On 9/18/12 8:29 AM, Cameron Byrne wrote: > Dear v6ops WG, > > We have submitted -08 of 464XLAT. > > Since this is a WG document, we feel obliged to make the following > changes in the -08 version of the 464XLAT I-D to reflect the rough > consensus of ideas. > > The following 2 material changes have been made: > > > 1. BIH reference has been removed. > > Tim, Woj, Maoke, Lorenzo, Joel, Randy, Tom, and others have requested > that BIH reference be removed. The authors believe BIH is a worthy > and complimentary technology for 464XLAT. Thank you Gang and Hui for > helping us understand BIH and the implementation progress. We believe > a reference to BIH adds no harm to 464XLAT. > > Yet, BIH is its own standard track RFC. It is unfortunate that we > cannot reference the 464XLAT reader to BIH. We think this idea will > be needed and useful, but it appears the WG objects to the reference. > > > 2. IPv6 WAN address sharing has been removed, including IANA > references and ND Proxy references. > > Hermant, Woj, and others have found issue with /64 address sharing > with ND Proxy. Remi's method is clever and technically astute, but it > did not gain WG support. That said, reflecting on the I-D, we could > not include any references to /64 sharing since that is not the core > of the I-D and rightfully should be its own I-D. We strongly > encourage the lesson learned and analysis of this area be carried > forward in a properly scoped separate I-D. > > We originally added Remi's method and BIH because we found them to be > technically worthy, and we are removing them not because of revelation > about their worthiness, but due to rough consensus of the WG and a > greater focus on the narrow scope of 464XLAT. > > Thanks again to all the WG participants for taking the time to make > this I-D better. We believe these edits address the feedback received > in last call. > > CB > > > > ---------- Forwarded message ---------- > From: > Date: Tue, Sep 18, 2012 at 8:05 AM > Subject: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-08.txt > To: i-d-announce@ietf.org > Cc: v6ops@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IPv6 Operations Working Group of the IETF. > > Title : 464XLAT: Combination of Stateful and > Stateless Translation > Author(s) : Masataka Mawatari > Masanobu Kawashima > Cameron Byrne > Filename : draft-ietf-v6ops-464xlat-08.txt > Pages : 14 > Date : 2012-09-18 > > Abstract: > This document describes an architecture (464XLAT) for providing > limited IPv4 connectivity across an IPv6-only network by combining > existing and well-known stateful protocol translation RFC 6146 in the > core and stateless protocol translation RFC 6145 at the edge. 464XLAT > is a simple and scalable technique to quickly deploy limited IPv4 > access service to IPv6-only edge networks without encapsulation. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-464xlat > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-08 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-464xlat-08 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From mohamed.boucadair@orange.com Thu Sep 20 00:00:42 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E29321F84D4 for ; Thu, 20 Sep 2012 00:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.066 X-Spam-Level: X-Spam-Status: No, score=-2.066 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599, HELO_EQ_FR=0.35, SARE_SUB_OBFU_Q1=0.227, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6aSrVuS-d33i for ; Thu, 20 Sep 2012 00:00:41 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 9B47521F84C8 for ; Thu, 20 Sep 2012 00:00:41 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 5B16922C90B for ; Thu, 20 Sep 2012 09:00:40 +0200 (CEST) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 2E39B238119 for ; Thu, 20 Sep 2012 09:00:40 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Thu, 20 Sep 2012 09:00:39 +0200 From: To: IPv6 Ops WG Date: Thu, 20 Sep 2012 09:00:38 +0200 Thread-Topic: draft-binet-v6ops-cellular-host-reqs-rfc3316update Thread-Index: Ac2WZk6bkygjt2tHRWm0TALPSDGcNgAlw55w Message-ID: <94C682931C08B048B7A8645303FDC9F36E5A40D46C@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.19.115414 Subject: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 07:00:42 -0000 Dear all, We submitted this new I-D.=20 Review and comments are more than welcome. Cheers, Med -----Message d'origine----- De : i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] D= e la part de internet-drafts@ietf.org Envoy=E9 : mercredi 19 septembre 2012 14:57 =C0 : i-d-announce@ietf.org Objet : I-D Action: draft-binet-v6ops-cellular-host-reqs-rfc3316update-00.t= xt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Internet Protocol Version 6 (IPv6) for Cellular Hosts Author(s) : David Binet Mohamed Boucadair Filename : draft-binet-v6ops-cellular-host-reqs-rfc3316update-00.tx= t Pages : 14 Date : 2012-09-19 Abstract: This document lists a set of IPv6-related requirements to be supported by cellular hosts. This document updates RFC3316. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-binet-v6ops-cellular-host-reqs-rfc33= 16update There's also a htmlized version available at: http://tools.ietf.org/html/draft-binet-v6ops-cellular-host-reqs-rfc3316upda= te-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From phdgang@gmail.com Thu Sep 20 01:24:28 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 884FB21F86DF for ; Thu, 20 Sep 2012 01:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.15 X-Spam-Level: X-Spam-Status: No, score=-3.15 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6QTccgyoTCFN for ; Thu, 20 Sep 2012 01:24:27 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id C145921F845E for ; Thu, 20 Sep 2012 01:24:27 -0700 (PDT) Received: by vbbfc26 with SMTP id fc26so2419362vbb.31 for ; Thu, 20 Sep 2012 01:24:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EjW97XpyM59HvKvaYgtWzmkJmxqHANA253ZOTiZ+e8o=; b=TFptww5iQ56MjHVGKRd0+Vnkg4gfjv61yUhXW/5LJtmsuuRNnlS4EurjWA0JG407UY 0qEJvpS+Y9J3pg5z3k3TsWG4wFmmNS2avpLh7a5Q274ZQUllKKvAxUaN86m20Unufme9 6lMLm9zIKjRmYfTs9I76tcyjkt+b+RWThUZ4KTI7IkG6F0uoo/Wb9jxL4BajRx3OPSKw y1owXTEJptAtvJlFcb5CJH4IBeh5yghw7ZqYPX8YL2pft2x8LUvH/kwUn8Gy6TMq+oMs 4E+0VkZycEmvBp51PUummTOX3UOBhVI3ycPTmc+kEenuJ4Gsnvwrx5CUk0MjnsA3Cujc amCA== MIME-Version: 1.0 Received: by 10.58.74.3 with SMTP id p3mr669789vev.27.1348129467188; Thu, 20 Sep 2012 01:24:27 -0700 (PDT) Received: by 10.58.114.231 with HTTP; Thu, 20 Sep 2012 01:24:27 -0700 (PDT) In-Reply-To: References: <20120918150528.29819.71058.idtracker@ietfa.amsl.com> Date: Thu, 20 Sep 2012 16:24:27 +0800 Message-ID: From: GangChen To: Cameron Byrne Content-Type: text/plain; charset=ISO-8859-1 Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-464xlat-08.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 08:24:28 -0000 Hello Cameron and all, Thanks for the efforts and sufficient discussions. I respect the rough consensus. Hopefully, our implementation could be done before WGLC so there is something useful to this technology. Best Regards Gang 2012/9/18, Cameron Byrne : > Dear v6ops WG, > > We have submitted -08 of 464XLAT. > > Since this is a WG document, we feel obliged to make the following > changes in the -08 version of the 464XLAT I-D to reflect the rough > consensus of ideas. > > The following 2 material changes have been made: > > > 1. BIH reference has been removed. > > Tim, Woj, Maoke, Lorenzo, Joel, Randy, Tom, and others have requested > that BIH reference be removed. The authors believe BIH is a worthy > and complimentary technology for 464XLAT. Thank you Gang and Hui for > helping us understand BIH and the implementation progress. We believe > a reference to BIH adds no harm to 464XLAT. > > Yet, BIH is its own standard track RFC. It is unfortunate that we > cannot reference the 464XLAT reader to BIH. We think this idea will > be needed and useful, but it appears the WG objects to the reference. > > > 2. IPv6 WAN address sharing has been removed, including IANA > references and ND Proxy references. > > Hermant, Woj, and others have found issue with /64 address sharing > with ND Proxy. Remi's method is clever and technically astute, but it > did not gain WG support. That said, reflecting on the I-D, we could > not include any references to /64 sharing since that is not the core > of the I-D and rightfully should be its own I-D. We strongly > encourage the lesson learned and analysis of this area be carried > forward in a properly scoped separate I-D. > > We originally added Remi's method and BIH because we found them to be > technically worthy, and we are removing them not because of revelation > about their worthiness, but due to rough consensus of the WG and a > greater focus on the narrow scope of 464XLAT. > > Thanks again to all the WG participants for taking the time to make > this I-D better. We believe these edits address the feedback received > in last call. > > CB > > > > ---------- Forwarded message ---------- > From: > Date: Tue, Sep 18, 2012 at 8:05 AM > Subject: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-08.txt > To: i-d-announce@ietf.org > Cc: v6ops@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IPv6 Operations Working Group of the > IETF. > > Title : 464XLAT: Combination of Stateful and > Stateless Translation > Author(s) : Masataka Mawatari > Masanobu Kawashima > Cameron Byrne > Filename : draft-ietf-v6ops-464xlat-08.txt > Pages : 14 > Date : 2012-09-18 > > Abstract: > This document describes an architecture (464XLAT) for providing > limited IPv4 connectivity across an IPv6-only network by combining > existing and well-known stateful protocol translation RFC 6146 in the > core and stateless protocol translation RFC 6145 at the edge. 464XLAT > is a simple and scalable technique to quickly deploy limited IPv4 > access service to IPv6-only edge networks without encapsulation. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-464xlat > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-08 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-464xlat-08 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From lorenzo@google.com Thu Sep 20 01:39:25 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCBF921F86AA for ; Thu, 20 Sep 2012 01:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.858 X-Spam-Level: X-Spam-Status: No, score=-102.858 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 97dq1+cmpQEV for ; Thu, 20 Sep 2012 01:39:25 -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 F30FC21F86B1 for ; Thu, 20 Sep 2012 01:39:24 -0700 (PDT) Received: by iabz21 with SMTP id z21so1675032iab.31 for ; Thu, 20 Sep 2012 01:39:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=utO0p3AOfS/Nnj0iz8pn5GQ6S64eR79GqYM2oVIGYEI=; b=ewhvgtk5x8Pk4ARQXTtkx+EnVWadOwgzLodyKjKJrGaWJY2QcMjb/w8C3snGq738ns UEk7Oij55JdpA5/ecB/3w0lzFlchqIhmtwYx1kyjwL4pAS99rgyetBfkHySz7Hw0iIZA D2TPZsq0ASGWQjaMXpnweTNODgWK8vi+drB872hs/VQzaAhWxaUqHWPp7KDDI2X9ZqGy 8mLYcmHoMSW2kPg1y/B4r0YvEU0iUJlr2m2euU3MYLaS6SU2+2By4ynBl/Iguaxp1n1h 2qCqaYMdtPDv/l4QeQyCMJFiX30qQgYsI6LI2NaGzXeXfYAkZ4Ch6s+1+Wy973Y7BXUt +vfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=utO0p3AOfS/Nnj0iz8pn5GQ6S64eR79GqYM2oVIGYEI=; b=T2znauREoX6dpX9+Xp99LOwIcZSfuZoEgvtLiKHh+TTga3iTeLednfIodIv8giaOu+ HarBNr/ZJr7KyqkpU9PTnNGkC4xqJQyKZM6KWgQ6WsSMZMqZDYadgQep6aH9L3e6vQfX V+AtoZIgyXJ7od15F4bR8Xr7EHIteITvdQLwELrBsYE/hJ/COdu4ckfkwi1G1+cA6bT3 VhiU9ljCMkQk8EZ+dY6LmPx2wEqf38gdHwtHVhBhUhOASR1vbarV/mOiKXpWLutEqVZA OFsBOOpqs3mU32JsSSPqrRxXkwaaxInDgHb+WAhRZRhH2941RWdukYzDF2K5nLSHxgrK oIiQ== Received: by 10.50.152.243 with SMTP id vb19mr1059308igb.4.1348130364344; Thu, 20 Sep 2012 01:39:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.246.2 with HTTP; Thu, 20 Sep 2012 01:39:04 -0700 (PDT) In-Reply-To: References: <20120918150528.29819.71058.idtracker@ietfa.amsl.com> From: Lorenzo Colitti Date: Thu, 20 Sep 2012 17:39:04 +0900 Message-ID: To: sarikaya@ieee.org Content-Type: multipart/alternative; boundary=e89a8f3b9df37a4aa104ca1e0f57 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlVj0SAJCihV0lligt17p5AOr7lDmbmW92BN/86ldf2EcWyphg2XmxJ+PkrUNmksiSIfXUMrEeR9IlQNj5+X2MNyBBGF+Wym4P0h2BjblnGfGuTmMSpyPrgbsLKcLjbYvZKDOMyypI7SDqit15Zr52kkuG9FzlHT3+vjzqwoZRhQqsel6gxdAGFlM7LoseMiRRDWSfF Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-464xlat-08.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 08:39:26 -0000 --e89a8f3b9df37a4aa104ca1e0f57 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Sep 19, 2012 at 1:12 AM, Behcet Sarikaya wrote: > Besides, my understanding was that Lorenzo had removed his objection > because of an implementation, at least just finished or in the works, > or whatever. > To clarify: Cameron is correct that object to mentioning BIH (on the grounds that it is unnecessary). The existence of an implementation does not remove my objection. --e89a8f3b9df37a4aa104ca1e0f57 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Sep 19, 2012 at 1:12 AM, Behcet Sarikaya <sarikaya2012@gmail.= com> wrote:
    Besides, my understanding was that Lorenzo had removed his objection
    because of an implementation, at least just finished or in the works,
    or whatever.

    To clarify: Cameron is cor= rect that object to mentioning BIH (on the grounds that it is unnecessary).= The existence of an implementation does not remove my objection.
    --e89a8f3b9df37a4aa104ca1e0f57-- From fred@cisco.com Thu Sep 20 05:45:03 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A2CC21F87FE for ; Thu, 20 Sep 2012 05:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.372 X-Spam-Level: X-Spam-Status: No, score=-110.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dGEFv83rpL35 for ; Thu, 20 Sep 2012 05:45:02 -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 8507921F87F4 for ; Thu, 20 Sep 2012 05:45:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=152; q=dns/txt; s=iport; t=1348145102; x=1349354702; h=date:from:message-id:to:subject:cc; bh=vK6P2FJ0wC8nXgrFqP3ra3+yahqvP+4f1L5QYcSmNlQ=; b=GAN9ZwGB+uQMNeVG5OZ+R2pqLUUO7muRS5dEn2LjRM+CgF/LzJc3+xfB SXIKJCH/RHYcOjnfDrgS0hg7hGiIi2YD+Py7gpNrnIS8xZB6HpEiKN5NW VWJB5deWdp6x7IkXBQwXqEotDnNopvAUtVEi/zS+WwLrgHgQfqslqf2r4 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoYIAEMPW1CrRDoI/2dsb2JhbABFhUOmGAGROIEIgjkBZjwtgQqHYAyZaaASjj6DHwOIVo4ijSSBaYMG X-IronPort-AV: E=Sophos;i="4.80,453,1344211200"; d="scan'208";a="58892267" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 20 Sep 2012 12:45:01 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q8KCj1l1025918; Thu, 20 Sep 2012 12:45:01 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id q8KCj1R00553; Thu, 20 Sep 2012 05:45:01 -0700 (PDT) Date: Thu, 20 Sep 2012 05:45:01 -0700 (PDT) From: Message-Id: <201209201245.q8KCj1R00553@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-binet-v6ops-cellular-host-reqs-rfc3316update@tools.ietf.org Subject: [v6ops] new draft: draft-binet-v6ops-cellular-host-reqs-rfc3316update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 12:45:03 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-binet-v6ops-cellular-host-reqs-rfc3316update. Please take a look at it and comment. From Fred.L.Templin@boeing.com Thu Sep 20 07:36:44 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B96821F8793 for ; Thu, 20 Sep 2012 07:36:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZZKoYO7xLe2 for ; Thu, 20 Sep 2012 07:36:43 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF3521F8525 for ; Thu, 20 Sep 2012 07:36:42 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q8KEadoE015026 for ; Thu, 20 Sep 2012 09:36:40 -0500 Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q8KEab1x014975 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 20 Sep 2012 09:36:38 -0500 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-11.nw.nos.boeing.com ([130.247.25.114]) with mapi; Thu, 20 Sep 2012 07:36:30 -0700 From: "Templin, Fred L" To: "v6ops@ietf.org" Date: Thu, 20 Sep 2012 07:36:17 -0700 Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-enterprise-incremental-ipv6-01.txt Thread-Index: Ac2TbKu5RsOBkQyvT/KNe2DuTjdt8QDzuZLQ Message-ID: References: <20120915180503.23774.22275.idtracker@ietfa.amsl.com> In-Reply-To: <20120915180503.23774.22275.idtracker@ietfa.amsl.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-TM-AS-MML: No Cc: "lee.howard@twcable.com" , "victor.kuarsingh@rci.rogers.com" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-enterprise-incremental-ipv6-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 14:36:44 -0000 Here are my comments on this document: Fred fred.l.templin@boeing.com 1) Section 1, s/will be perform better/may perform better 2) Section 1, "It is thus in the enterprise's interests to deploy native IPv6 itself." - This statement is not necessarily true for all enterprises, and the fact that the ISP may provide native IPv6 services has no bearing on whether the enterprise should also provide native IPv6 services. Suggest deleting this sentence. 3)Section 1.3, "Reasons for a Phased Approach", in this section there should be a statement to the effect that, although some of the RFC1687 reasons for not deploying IPv6 are still valid, many of the reasons given in this section are new since the publication of RFC1687 and do give good reasons for transition. 4) Section 1.3, the statement: "it can be expected that new applications will only support IPv6." Please change to: "it can be expected that some new applications will only support IPv6." ^^^^ 5) Section 1.3, "which means that with IPv6 merging networks (after two organizations merged) is much easier and faster." This statement needs to be backed up with a citation - perhaps something from the RENUM working group, or from "Renumbering Without a Flag Day". 6) Section 3.1.2, "...communicates of the network" - should it be: "...communicates on the network" ? 7) Section 3.1.2, second paragraph, somewhere this paragraph should cite RFC6724 - "Default Address Selection for Internet Protocol Version 6 (IPv6)". 8) Section 3.3, final sentence: "Either way IPv6 introduces the opportunity to rationalize the environment and to architect it for growth." - is not true, because IPv6 is an inanimate object and cannot "introduce" anything. Maybe you are meaning to say (sic) since the network administrators are considering an introduction of IPv6 they might also be inclined to review their existing architecture for its growth potential while they are at it? Plus, this statement and the previous paragraph are out of place in a section that is supposed to talk about routing. 9) Section 3.5, the sentence: "The enterprise administrator will want to evaluate whether the enterprise will request address space from its ISP (or Local Internet Registry (LIR)), or whether to request address space from the local Internet Registry..." - the term "local Internet registry" is being used redundantly here in a way that may confuse the reader. 10) Section 3.5, "Each location, no matter how small, should get at least a /48." - there has been quite a bit of discussion about sites being able to request a smaller size such as /56. Also, the size of the minimum site prefix is outside the scope of this document. Perhaps change this to something like: "Each location, no matter how small, should get the largest practical IPv6 prefix delegation.". 11) Section 4.1, "may need to communist with the outside world", "communist" is probably not the correct word here. 12) Section 4.1, "Add some comment about setting MTU to 1280 to avoid tunnel pMTUd black holes?" - This is out of scope for this document, and goes against recommendations in some of the tunneling documents. Plus, 1280 may not be any safer than something larger like 1480 in many cases. 13) Section 5, the phrase "Dual Stack when you can, tunnel when you must" may be inappropriate for some or perhaps even many enterprise network use cases. The subsequent sentence also contains subjective advice. Suggest rewording the first two sentences of this paragraph to something like: "An important design paradigm to consider during this phase is to determine where Dual Stack and/or tunnel should be used". Dual stacking when possible allows you to build a native IPv6 network capability that should be preferred over tunnels." 14) Section 5.1, "An important design choice to be made is what IGP to use inside the network." - Doesn't this text belong back in Section 3.3 ("Routing")? Or if not, should Section 3.3 be deleted and its text moved here? 15) Section 5.1, final sentence, "In the long term, DHCPv6 makes most sense for use in a managed environment." would almost certainly raise prolonged and undesirable debate. The previous sentences articulated the SLAAC and DHCPv6 considerations very well, so it would be better to just leave this sentence out. 16) Section 5.2, "It is important to note that most operating systems will, by default, prefer to use native IPv6 over IPv4 when enabled." - this may not be true for OSes that implement RFC6724 default address selections. In that case, IPv6 and/or IPv4 would be preferred based on the address selection algorithm instead of based on some static configuration. 17) Section 5.2, "Furthermore, some OSes may have tunneling mechanisms turned on by default...". Change to: Furthermore, some OSes may have unmanaged tunneling mechanisms turned on by default..." ^^^^^^^^^=20 18) Sections 6.2 and 7 seem to be preliminary in nature, and seem to be in need of substantial editing and/or new text added. It is too early to comment on these sections. > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Saturday, September 15, 2012 11:05 AM > To: i-d-announce@ietf.org > Cc: v6ops@ietf.org > Subject: [v6ops] I-D Action: draft-ietf-v6ops-enterprise-incremental-ipv6= - > 01.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IPv6 Operations Working Group of the > IETF. >=20 > Title : Enterprise IPv6 Deployment Guidelines > Author(s) : Kiran K. Chittimaneni > Tim Chown > Lee Howard > Victor Kuarsingh > Yanick Pouffary > Eric Vyncke > Filename : draft-ietf-v6ops-enterprise-incremental-ipv6- > 01.txt > Pages : 28 > Date : 2012-09-15 >=20 > Abstract: > Enterprise network administrators worldwide are in various stages of > preparing for or deploying IPv6 into their networks. The > administrators face different challenges than operators of Internet > access providers, and have reasons for different priorities. The > overall problem for many administrators will be to offer Internet- > facing services over IPv6, while continuing to support IPv4, and > while introducing IPv6 access within the enterprise IT network. The > overall transition will take most networks from an IPv4-only > environment to a dual stack network environment and potentially an > IPv6-only operating mode. This document helps provide a framework > for enterprise network architects or administrators who may be faced > with many of these challenges as they consider their IPv6 support > strategies. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-enterprise-incremental- > ipv6 >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-v6ops-enterprise-incremental-ipv6-0= 1 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-enterprise-incrementa= l- > ipv6-01 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From phdgang@gmail.com Thu Sep 20 08:12:46 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B226121F84A6 for ; Thu, 20 Sep 2012 08:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.031 X-Spam-Level: X-Spam-Status: No, score=-3.031 tagged_above=-999 required=5 tests=[AWL=-0.259, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xYWbTxw5ONeJ for ; Thu, 20 Sep 2012 08:12:46 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 02FAF21F84A0 for ; Thu, 20 Sep 2012 08:12:45 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so2898284vcb.31 for ; Thu, 20 Sep 2012 08:12:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=F8S0PQegOnUNBc2r2tln3SFw+svbC7ow6Z4ogb4fyQ4=; b=KcbB6OnD83aX6S2FY+M+6GZpa/Fiy/OUOv5DqM9IQnUyjpLZsonuODy7ogkqsX/tyn oaFGHeeGD4x2r5bEO/vKaaQZ3Tn2hdtEEWUfK7Wscj3fGNH1mR7er3kJwcel0I/uhAWs 5H3GCYrqnghfqzk5Tk07p65WYjsBkooaIDyn77boedmPTywVtoV8/QjETnB3+XIvSwO4 0AObSHGubg3pjEwqX8qVmrYFojEC+vj9NRbmK4AIb4wmylWgaaDUi/wirVl81/ZVOf37 ZOHkFJJzJ/QYh7eYAR/SnHXFUxPDn+UKumuYQnq3/d+vp0FqfGRiLhosYK1lAmcI9/YP ixgA== MIME-Version: 1.0 Received: by 10.220.37.194 with SMTP id y2mr1196979vcd.44.1348153965402; Thu, 20 Sep 2012 08:12:45 -0700 (PDT) Received: by 10.58.114.231 with HTTP; Thu, 20 Sep 2012 08:12:45 -0700 (PDT) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E5A40D46C@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E5A40D46C@PUEXCB1B.nanterre.francetelecom.fr> Date: Thu, 20 Sep 2012 23:12:45 +0800 Message-ID: From: GangChen To: mohamed.boucadair@orange.com Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 15:12:46 -0000 Hello Med, Thanks for the work. I read the draft. In general, the requirements have been structured as Basic Connectivity, Advanced and APIs & Applications Just wondering to know what release of cellular host the requirements are targeting? What=92s the consideration to frame the context of each section? I have noticed that some basic IPv6 capability is mentioned in the part of Advanced Requirements. That seems to me should belong to the Basic part. More details are as following. 2. Basic Connectivity Requirements REQ#1, REQ#2, REQ#3 and REQ#4 were already specified in 3GPP. Not sure it would add much discussions to the draft. REQ#6 and REQ#7 should be combined IMHO, because it provides same outcome solving the issues related to compatibility of IPv4 applications. REQ#8: I don't understand the purpose of embed a DNS64 function. Especially, the sentence of "This allows to be compatible with DNSSEC" REQ#10 I guess I-D.ietf-behave-nat64-discovery-heuristic should be ranked as first priority compared to I-D.boucadair-pcp-nat64-prefix64-option REQ#11: Preferring native IPv6 doesn't always achieve good effect. It may cause additional charge in some cases. Please refer to http://tools.ietf.org/html/draft-ietf-mif-happy-eyeballs-extension-00#page-= 3 case 4 for further information One additional requirement maybe worth to add for the completeness: REQ#XX The cellular device SHOULD embed a BIH function [RFC6535] facilitating the communication between IPv4 application and IPv6 server 2.1. WiFi Connectivity It may be complementary to add one additional requirement, like REQ#XX Prefix Delegation capabilities [RFC3633] MUST be supported on the Wi-Fi interface. 3. Advanced Requirements REQ#16, REQ#17, REQ#18, REQ#19 and REQ#20 may be proper to be shifted to "2. Basic Connectivity Requirements", since those features are basic IPv6 capability REQ#22: it maybe proper to change the *SHOULD* to *MAY* Best Regards Gang 2012/9/20, mohamed.boucadair@orange.com : > Dear all, > > We submitted this new I-D. > > Review and comments are more than welcome. > > Cheers, > Med > > > -----Message d'origine----- > De : i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org]= De > la part de internet-drafts@ietf.org > Envoy=E9 : mercredi 19 septembre 2012 14:57 > =C0 : i-d-announce@ietf.org > Objet : I-D Action: > draft-binet-v6ops-cellular-host-reqs-rfc3316update-00.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Internet Protocol Version 6 (IPv6) for Cellular Hosts > Author(s) : David Binet > Mohamed Boucadair > Filename : > draft-binet-v6ops-cellular-host-reqs-rfc3316update-00.txt > Pages : 14 > Date : 2012-09-19 > > Abstract: > This document lists a set of IPv6-related requirements to be > supported by cellular hosts. > > This document updates RFC3316. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-binet-v6ops-cellular-host-reqs-rfc= 3316update > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-binet-v6ops-cellular-host-reqs-rfc3316up= date-00 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From Ted.Lemon@nominum.com Thu Sep 20 08:32:47 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CAFB21F849B for ; Thu, 20 Sep 2012 08:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.435 X-Spam-Level: X-Spam-Status: No, score=-106.435 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNH0bDkB7F3j for ; Thu, 20 Sep 2012 08:32:46 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id A31B121F84A7 for ; Thu, 20 Sep 2012 08:32:46 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKUFs3HhcdTOp7yh4wLIN2iHo0RW2vVshK@postini.com; Thu, 20 Sep 2012 08:32:46 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id B5EC01B829F for ; Thu, 20 Sep 2012 08:32:45 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id A5A9019005C; Thu, 20 Sep 2012 08:32:45 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Thu, 20 Sep 2012 08:32:45 -0700 From: Ted Lemon To: GangChen Thread-Topic: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update Thread-Index: Ac2WZk6bkygjt2tHRWm0TALPSDGcNgAlw55wAB/smYD//5A9Vg== Date: Thu, 20 Sep 2012 15:32:44 +0000 Message-ID: <91BE181A-163D-43CC-8BDD-49D6E10AE8FF@nominum.com> References: <94C682931C08B048B7A8645303FDC9F36E5A40D46C@PUEXCB1B.nanterre.francetelecom.fr>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 15:32:47 -0000 On Sep 20, 2012, at 11:13 AM, "GangChen" wrote: > REQ#8: I don't understand the purpose of embed a DNS64 function. > Especially, the sentence of "This allows to be compatible with DNSSEC" Because a DNS64 translator has to spoof records in a zone, by definition it= 's impossible for these spoofed records to be validated. So in order for DN= SSEC to function with NAT64, it is required that the resolver on the end de= vice do the DNS64 translation.=20 Of course, in order for it to do this, it needs to know the NAT64 prefix... From joelja@bogus.com Thu Sep 20 14:13:35 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 875A121E8093; Thu, 20 Sep 2012 14:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IdhKaIgpSJEQ; Thu, 20 Sep 2012 14:13:34 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id A9ED221E805F; Thu, 20 Sep 2012 14:13:28 -0700 (PDT) Received: from joels-MacBook-Air.local (host-64-47-153-50.masergy.com [64.47.153.50]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q8KLDR93074793 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 20 Sep 2012 21:13:27 GMT (envelope-from joelja@bogus.com) Message-ID: <505B86F1.6020602@bogus.com> Date: Thu, 20 Sep 2012 14:13:21 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20120828 Thunderbird/16.0 MIME-Version: 1.0 To: IPv6 Ops WG , "ipv6@ietf.org 6man" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Thu, 20 Sep 2012 21:13:27 +0000 (UTC) Subject: [v6ops] FWD: I-D Action: draft-gashinsky-6man-v6nd-enhance-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 21:13:35 -0000 Greetings, On the heals of work on draft-ietf-6man-impatient-nud-02 and rfc 6583 the authors have decided to take a lot at their proposal for gratuitous neighbor advertisement. We believe that this approach has the potential to ameliorate some problems experienced today in large broadcast domains where control plane processors may spend a significant chunk of their cpu cycles mananging NDP even under normal circumstances. There is some real world experience of meltdowns not caused by deliberate DOS that we ascribe to the current handling of NDP so we'd like to see some additional effort in this area. A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Neighbor Discovery Enhancement for DOS mititgation Author(s) : Warren Kumari Filename : draft-gashinsky-6man-v6nd-enhance-01.txt Pages : 10 Date : 2012-09-20 Abstract: In IPv4, subnets are generally small, made just large enough to cover the actual number of machines on the subnet. In contrast, the default IPv6 subnet size is a /64, a number so large it covers trillions of addresses, the overwhelming number of which will be unassigned. Consequently, simplistic implementations of Neighbor Discovery can be vulnerable to denial of service attacks whereby they attempt to perform address resolution for large numbers of unassigned addresses. Such denial of attacks can be launched intentionally (by an attacker), or result from legitimate operational tools that scan networks for inventory and other purposes. As a result of these vulnerabilities, new devices may not be able to "join" a network, it may be impossible to establish new IPv6 flows, and existing IPv6 transported flows may be interrupted. This document describes a modification to the [RFC4861] neighbor discovery protocol aimed at improving the resilience of the neighbor discovery process. We call this process Gratuitous neighbor discovery and it derives inspiration in part from analogous IPv4 gratuitous ARP implementation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-gashinsky-6man-v6nd-enhance There's also a htmlized version available at: http://tools.ietf.org/html/draft-gashinsky-6man-v6nd-enhance-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-gashinsky-6man-v6nd-enhance-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From joelja@bogus.com Thu Sep 20 16:05:50 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8099121E8034 for ; Thu, 20 Sep 2012 16:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.199 X-Spam-Level: X-Spam-Status: No, score=-102.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gkDSsw-kfDbL for ; Thu, 20 Sep 2012 16:05:50 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id B29BF21E804C for ; Thu, 20 Sep 2012 16:05:49 -0700 (PDT) Received: from joels-MacBook-Air.local (host-64-47-153-50.masergy.com [64.47.153.50]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q8KN5mE4075962 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Thu, 20 Sep 2012 23:05:49 GMT (envelope-from joelja@bogus.com) Message-ID: <505BA147.1040003@bogus.com> Date: Thu, 20 Sep 2012 16:05:43 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20120828 Thunderbird/16.0 MIME-Version: 1.0 To: IPv6 Ops WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Thu, 20 Sep 2012 23:05:49 +0000 (UTC) Subject: [v6ops] remote participation at Sept 29th LIM X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 23:05:50 -0000 Remote participation in the v6ops LIM meeting 1330-1630 CESTwill be enabled by meetecho. If you haven't familiarized yourself with the client, you might want to cruise the instructions available from ietf 83. http://ietf83.conf.meetecho.com/index.php/Web_Client In particular I'd note that if you have a mac running 10.7 or 10.8 you should probably make sure that java is installed since it's no longer packaged with the os install by default. From cb.list6@gmail.com Thu Sep 20 20:20:59 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00C1721F8667 for ; Thu, 20 Sep 2012 20:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.344 X-Spam-Level: X-Spam-Status: No, score=-3.344 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7iwsb1VMZoVn for ; Thu, 20 Sep 2012 20:20:58 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id B626421F869C for ; Thu, 20 Sep 2012 20:20:57 -0700 (PDT) Received: by lboj14 with SMTP id j14so3034274lbo.31 for ; Thu, 20 Sep 2012 20:20:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=HRUDDm9H9KHrZ3WgN6K3m1udcUlT7HG6pSCQVWA9sZo=; b=MjT3EfV6dufyYzcETW6umT/715vP+5hVhtxIp0OXcGb8N8/JBL9EoQsKbNiTZtgZC2 fsdTU6sv0x9OsqW7bWdxuEJjhtDnUTBSbEGGKtB06MB/kYTsmACoyCTUVYwf3IhIMlmG Vm2YGLDtcduuJwi92N3MHecGxgndINwEPoKoRgGLTfuESaBV07v+vYGyStY9Uhdpvbuy 41lp8x9BuPMzqcgYUS9Cu2JT1q8MT3W/T1wJnW0Eqy2Md1t9TyxqyXsW7c8N7Wg28T5y /Qel3ofz6GyREDj4iuOaErRqEu4JqPpjht9e7JtZQDIqbzOXr1NbC5xRy6EGtH3xqTqM SpfA== MIME-Version: 1.0 Received: by 10.152.132.133 with SMTP id ou5mr3114261lab.45.1348197656692; Thu, 20 Sep 2012 20:20:56 -0700 (PDT) Received: by 10.112.49.66 with HTTP; Thu, 20 Sep 2012 20:20:56 -0700 (PDT) Date: Thu, 20 Sep 2012 20:20:56 -0700 Message-ID: From: Cameron Byrne To: IPv6 Ops WG Content-Type: text/plain; charset=ISO-8859-1 Subject: [v6ops] IPv6 LTE teathering without PD on iPad X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 03:20:59 -0000 Sounds like the iPad shares the LTE interfaces /64 to the WLAN tether, no DHCP-PD used. Just a note from the front lines: http://mailman.nanog.org/pipermail/nanog/2012-September/052043.html From mohamed.boucadair@orange.com Thu Sep 20 22:56:39 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE0CC21F8613 for ; Thu, 20 Sep 2012 22:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.615 X-Spam-Level: X-Spam-Status: No, score=-0.615 tagged_above=-999 required=5 tests=[AWL=-1.494, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, MANGLED_EXTNSN=2.3, SARE_SUB_OBFU_Q1=0.227, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yNzsLeGrWYnQ for ; Thu, 20 Sep 2012 22:56:38 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 9501121F8555 for ; Thu, 20 Sep 2012 22:56:38 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 35F1526458D; Fri, 21 Sep 2012 07:56:37 +0200 (CEST) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 1CAFE4C086; Fri, 21 Sep 2012 07:56:37 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Fri, 21 Sep 2012 07:56:36 +0200 From: To: GangChen Date: Fri, 21 Sep 2012 07:56:35 +0200 Thread-Topic: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update Thread-Index: Ac2XQmRwvgB9eKq4TDyGJOoGmWYBegABlmmg Message-ID: <94C682931C08B048B7A8645303FDC9F36E5B12338F@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E5A40D46C@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: 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.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.9.21.40316 Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 05:56:39 -0000 Hi Gang, Thanks for the review.=20 Please see inline. Cheers, Med=20 >-----Message d'origine----- >De : GangChen [mailto:phdgang@gmail.com]=20 >Envoy=E9 : jeudi 20 septembre 2012 17:13 >=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >Cc : IPv6 Ops WG >Objet : Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update > >Hello Med, > >Thanks for the work. I read the draft. >In general, the requirements have been structured as Basic >Connectivity, Advanced and APIs & Applications >Just wondering to know what release of cellular host the requirements >are targeting? >What's the consideration to frame the context of each section? >I have noticed that some basic IPv6 capability is mentioned in the >part of Advanced Requirements. That seems to me should belong to the >Basic part. > >More details are as following. > >2. Basic Connectivity Requirements >REQ#1, >REQ#2, >REQ#3 and REQ#4 were already specified in 3GPP. >Not sure it would add much discussions to the draft. Med: The purpose of the draft is to have one place where an IPv6 profile fo= r cellular device is device. There are several requirements on the UEs spre= ad in various specification document. Listing those 3GPP spec is one part o= f the puzzle to define an IPv6 profile for cellular hosts. > >REQ#6 and REQ#7 should be combined IMHO, because it provides same >outcome solving the issues related to compatibility of IPv4 >applications.> >REQ#8: I don't understand the purpose of embed a DNS64 function. >Especially, the sentence of "This allows to be compatible with DNSSEC" Med: I see Ted already answered to this comment.=20 > >REQ#10 I guess I-D.ietf-behave-nat64-discovery-heuristic should be >ranked as first priority compared to >I-D.boucadair-pcp-nat64-prefix64-option Med: Please refer to http://www.ietf.org/mail-archive/web/pcp/current/msg02= 273.html for the discussion I had with Teemu on this item. > >REQ#11: Preferring native IPv6 doesn't always achieve good effect. It >may cause additional charge in some cases. Please refer to >http://tools.ietf.org/html/draft-ietf-mif-happy-eyeballs-extens >ion-00#page-3 >case 4 for further information Med: I added a pointer to the MIF draft to record the issue. > >One additional requirement maybe worth to add for the completeness: > >REQ#XX The cellular device SHOULD embed a BIH function [RFC6535] >facilitating the communication between IPv4 application and IPv6 >server Med: As we have CLAT already listed there, what would be the motivation to = include BIH? I added a discussion note to the draft to record this point. =20 > >2.1. WiFi Connectivity > >It may be complementary to add one additional requirement, like > >REQ#XX Prefix Delegation capabilities [RFC3633] MUST be supported on >the Wi-Fi interface. Med: Wouldn't this be redundant with what is the features discussed in Sect= ion 4? > > >3. Advanced Requirements > > REQ#16, > REQ#17, > REQ#18, > REQ#19 and REQ#20 may be proper to be shifted to "2. Basic >Connectivity Requirements", since those features are basic IPv6 >capability Med: I will check. > >REQ#22: it maybe proper to change the *SHOULD* to *MAY* Med: What is the rationale behind that change? > >Best Regards > >Gang > >2012/9/20, mohamed.boucadair@orange.com : >> Dear all, >> >> We submitted this new I-D. >> >> Review and comments are more than welcome. >> >> Cheers, >> Med >> >> >> -----Message d'origine----- >> De : i-d-announce-bounces@ietf.org=20 >[mailto:i-d-announce-bounces@ietf.org] De >> la part de internet-drafts@ietf.org >> Envoy=E9 : mercredi 19 septembre 2012 14:57 >> =C0 : i-d-announce@ietf.org >> Objet : I-D Action: >> draft-binet-v6ops-cellular-host-reqs-rfc3316update-00.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : Internet Protocol Version 6 (IPv6)=20 >for Cellular Hosts >> Author(s) : David Binet >> Mohamed Boucadair >> Filename : >> draft-binet-v6ops-cellular-host-reqs-rfc3316update-00.txt >> Pages : 14 >> Date : 2012-09-19 >> >> Abstract: >> This document lists a set of IPv6-related requirements to be >> supported by cellular hosts. >> >> This document updates RFC3316. >> >> >> >> The IETF datatracker status page for this draft is: >>=20 >https://datatracker.ietf.org/doc/draft-binet-v6ops-cellular-hos >t-reqs-rfc3316update >> >> There's also a htmlized version available at: >>=20 >http://tools.ietf.org/html/draft-binet-v6ops-cellular-host-reqs >-rfc3316update-00 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> >= From hesham@elevatemobile.com Thu Sep 20 23:08:14 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B7C621F8634 for ; Thu, 20 Sep 2012 23:08:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iH+Qu+-j+HFQ for ; Thu, 20 Sep 2012 23:08:13 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by ietfa.amsl.com (Postfix) with ESMTP id 3B36C21F84D3 for ; Thu, 20 Sep 2012 23:08:12 -0700 (PDT) Received: from [203.219.211.243] (helo=[192.168.0.4]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1TEwPG-0001IU-HH; Fri, 21 Sep 2012 16:08:06 +1000 User-Agent: Microsoft-MacOutlook/14.2.3.120616 Date: Fri, 21 Sep 2012 16:08:02 +1000 From: Hesham Soliman To: Cameron Byrne , IPv6 Ops WG Message-ID: Thread-Topic: [v6ops] IPv6 LTE teathering without PD on iPad In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-User: hesham@elevatemobile.com Subject: Re: [v6ops] IPv6 LTE teathering without PD on iPad X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 06:08:14 -0000 Of course. It's the easiest way to make it work, get a /64, share it and defend your addresses on the mobile interface even when DAD..etc is received on the hotspot interface. Internal proxying of ND basically (or a different implementation with the same effect). PD is a complete overkill if you only want to support one link. Hesham -----Original Message----- From: Cameron Byrne Date: Friday, 21 September 2012 1:20 PM To: IPv6 Ops WG Subject: [v6ops] IPv6 LTE teathering without PD on iPad >Sounds like the iPad shares the LTE interfaces /64 to the WLAN tether, >no DHCP-PD used. > >Just a note from the front lines: > >http://mailman.nanog.org/pipermail/nanog/2012-September/052043.html >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From swmike@swm.pp.se Thu Sep 20 23:16:16 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5E9B21F84F3 for ; Thu, 20 Sep 2012 23:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lvi2Q8WwhhAc for ; Thu, 20 Sep 2012 23:16:16 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id D075A21F8639 for ; Thu, 20 Sep 2012 23:16:15 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 75A4C9C; Fri, 21 Sep 2012 08:16:11 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 729939A; Fri, 21 Sep 2012 08:16:11 +0200 (CEST) Date: Fri, 21 Sep 2012 08:16:11 +0200 (CEST) From: Mikael Abrahamsson To: Hesham Soliman In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IPv6 Ops WG Subject: Re: [v6ops] IPv6 LTE teathering without PD on iPad X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 06:16:17 -0000 On Fri, 21 Sep 2012, Hesham Soliman wrote: > Of course. It's the easiest way to make it work, get a /64, share it and > defend your addresses on the mobile interface even when DAD..etc is > received on the hotspot interface. Internal proxying of ND basically (or a > different implementation with the same effect). As far as I understand, there is nobody else on the mobile interface than you on that /64, so there is no reason to defend yourself there. -- Mikael Abrahamsson email: swmike@swm.pp.se From hesham@elevatemobile.com Fri Sep 21 00:04:44 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED0711E808A for ; Fri, 21 Sep 2012 00:04: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vj4Q+x18qyko for ; Fri, 21 Sep 2012 00:04:43 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by ietfa.amsl.com (Postfix) with ESMTP id E6C1A21F86B2 for ; Fri, 21 Sep 2012 00:04:42 -0700 (PDT) Received: from [60.242.128.199] (helo=[192.168.0.6]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1TExHu-0008PQ-Gu; Fri, 21 Sep 2012 17:04:35 +1000 User-Agent: Microsoft-MacOutlook/14.2.3.120616 Date: Fri, 21 Sep 2012 17:04:24 +1000 From: Hesham Soliman To: Mikael Abrahamsson Message-ID: Thread-Topic: [v6ops] IPv6 LTE teathering without PD on iPad In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-User: hesham@elevatemobile.com Cc: IPv6 Ops WG Subject: Re: [v6ops] IPv6 LTE teathering without PD on iPad X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 07:04:44 -0000 > >> Of course. It's the easiest way to make it work, get a /64, share it and >> defend your addresses on the mobile interface even when DAD..etc is >> received on the hotspot interface. Internal proxying of ND basically >>(or a >> different implementation with the same effect). > >As far as I understand, there is nobody else on the mobile interface than >you on that /64, so there is no reason to defend yourself there. => That's right, it's a point-to-point link and each mobile gets a /64. Hesham > >-- >Mikael Abrahamsson email: swmike@swm.pp.se From lorenzo@google.com Fri Sep 21 00:07:35 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FCE921F84D9 for ; Fri, 21 Sep 2012 00:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.862 X-Spam-Level: X-Spam-Status: No, score=-102.862 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JN0OTOJwKIoo for ; Fri, 21 Sep 2012 00:07:31 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id C5C9611E808A for ; Fri, 21 Sep 2012 00:07:31 -0700 (PDT) Received: by oagn5 with SMTP id n5so2729960oag.31 for ; Fri, 21 Sep 2012 00:07:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=d5Tl4nUHBCUmD1z/dj2EUGANsTNaZzMHlna89Be4kVM=; b=dMCfEmiFCJDSBWCbZHxUMbtrRnUmdnfVecYxCLWSO54NZVsgxcauF+TxeMOU0XhSdX st4C2ohfb5ACP8kSfGKi9be37ASp2GbjYiGbJ1dAH8/YETHD+LYmb8cwxeF8XySyMXnW 2jmv5vPKZyu2Wq1RGiT34YATwnEz66dgCj8eeEJChuTuucrz7SfP2GfM/22PafcZZZJq wSyPLvSu0dy+gc8c3YkZ39xkpf25bgY7oz6asHFL6jrEEeyBtwDHu7HPOT76zwv98TFy OkgPXe3zTiS7Sqz0WiRZM5WAdONU2sPxNJqRZKy9KrItO272WuptqZ9MmvHDkEc3mn0Y ZrTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=d5Tl4nUHBCUmD1z/dj2EUGANsTNaZzMHlna89Be4kVM=; b=ckZoOk1jdrC0Y3P0Qfw/kLi0GJz/CSWc1H399Noh5Q1oD+d+jozsXP44PZfQKORht/ CtwwRqi/ZXqthzCLNJnaCP5iTpex/1OGvLrZ9aTB8vqMsBdMw6gEOp49j41zqeYdgbqs DkFCfCpMbx/Faw/72LpWoYpt4efO8koLEDla7RmC+QoOkLlQYuV7KHbbonGHZ5qqXctA HVFYH8ntSwzebbkFyCTxdbxOdFDKpIo47J8ealrNQpny+Vy53OqBK01M85kOfgtXC/5Z xvVyu44RPoS6Qgf5H423XSK+ag9M1JydIhcnqHAlFA59mTvtVAiqOK2o6bgqCOjRDgrt zEeg== Received: by 10.182.217.38 with SMTP id ov6mr3141311obc.33.1348211251317; Fri, 21 Sep 2012 00:07:31 -0700 (PDT) Received: by 10.182.217.38 with SMTP id ov6mr3141304obc.33.1348211251225; Fri, 21 Sep 2012 00:07:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.225.98 with HTTP; Fri, 21 Sep 2012 00:07:11 -0700 (PDT) In-Reply-To: References: From: Lorenzo Colitti Date: Fri, 21 Sep 2012 16:07:11 +0900 Message-ID: To: Mikael Abrahamsson Content-Type: multipart/alternative; boundary=f46d044472d1b623cf04ca30e409 X-System-Of-Record: true X-Gm-Message-State: ALoCoQl//Rv+fs9QT1UWFdQI0OIR55eX2QPw1TT34dBADcNRCyqkMLbFPT7E/zDJiItCY+512JWFV6DCDDu1IHo1hFGG6TtnM6xXoZSo3L6N4cFW8CgPbxZpedfey17qFVJ8wFP1hdUOJtjglRXz5UCb/YNibrhk+yRRH7CjBgyB/L9cU21RTevcQTeD45AUc0SgkFF9JAVP Cc: IPv6 Ops WG Subject: Re: [v6ops] IPv6 LTE teathering without PD on iPad X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 07:07:35 -0000 --f46d044472d1b623cf04ca30e409 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Sep 21, 2012 at 3:16 PM, Mikael Abrahamsson wrote: > As far as I understand, there is nobody else on the mobile interface than > you on that /64, so there is no reason to defend yourself there. > You don't need to do DAD on the mobile interface, but you need to defend the mobile interface's IPv6 address on the wifi interface. --f46d044472d1b623cf04ca30e409 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Sep 21, 2012 at 3:16 PM, Mikael Abrahamsson <<= a href=3D"mailto:swmike@swm.pp.se" target=3D"_blank">swmike@swm.pp.se&g= t; wrote:
    As far as I understand, there is nobody else on the mobil= e interface than you on that /64, so there is no reason to defend yourself = there.

    You don't need to do DAD on the= mobile interface, but you need to defend the mobile interface's IPv6 a= ddress on the wifi interface.
    --f46d044472d1b623cf04ca30e409-- From lorenzo@google.com Fri Sep 21 00:18:45 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D64B021F862A for ; Fri, 21 Sep 2012 00:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.752 X-Spam-Level: X-Spam-Status: No, score=-102.752 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5UetagGER4gO for ; Fri, 21 Sep 2012 00:18:44 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7CBD821F84A0 for ; Fri, 21 Sep 2012 00:18:44 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so3314139obb.31 for ; Fri, 21 Sep 2012 00:18:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=FdUNJA4BK2t3j/E287R8cIeTFMQJDjnrNXXRoZDGHTA=; b=gBpjUJ+xprxzKY8e9+DEjAmdpWATqWK+a8Ms1BaTITVFsffLVjAhfrUrrJO5Grru81 vCV2Naltkour+0FglihfmhJuRAhdEpTlK8GCTYo+EKns7/AmuGZEfKESXGKWiVkD0dxK /Z6xh7yCgtU7hfv3pRNaxGGPHRpGqmZ9Uee96Wru+qBWD0lXWCMJAYVseCyPBgnR1+G5 EsAQctQ2ZzmsJXMalOL6eeJd9m7xoT+l0Atxv33N3l/LXLejGkGXxeqj/+FeM2YWAW+Z MCrygDWbuQsljnp8zTaRLWNwioxp48wRk/BMoN9+sDSVeOk8T22cs6uYQSP8Ffs86vvq vKtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=FdUNJA4BK2t3j/E287R8cIeTFMQJDjnrNXXRoZDGHTA=; b=m1WtIpoEFydRQ5aLUvSajo3zg2jFL8YmF8jXn/WjQUkG2tWDle2Z9Pz6NILwWUVTjy a5Pfx/OD9G0NGxxH2ZUrkyzaH8OZNQkgAFLDiz4Bbl2r5Kz4cOWEgqjf6GgUQUvwQxt7 Oxdn3i5HURLN7rITeuaxOSKXjo3RuhTpGkGAb60nVI8tOScm2DIkUWBKZi9HIIh7GK/Z C08/+KgWaXBaA9WjR6YO6jNPWswB1i4fU38BAgOsY38FLAdqfDQx857cXHCcidBB/E2O dYdLg3wS4PwD/J/4VwW/DW91Mv34ZVmQICJXx4q+73KvqX+3us69FkdzQ2sknipMoaTX EKXg== Received: by 10.60.29.202 with SMTP id m10mr3151963oeh.11.1348211924107; Fri, 21 Sep 2012 00:18:44 -0700 (PDT) Received: by 10.60.29.202 with SMTP id m10mr3151959oeh.11.1348211923996; Fri, 21 Sep 2012 00:18:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.225.98 with HTTP; Fri, 21 Sep 2012 00:18:23 -0700 (PDT) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E5A40D46C@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E5A40D46C@PUEXCB1B.nanterre.francetelecom.fr> From: Lorenzo Colitti Date: Fri, 21 Sep 2012 16:18:23 +0900 Message-ID: To: mohamed.boucadair@orange.com Content-Type: multipart/alternative; boundary=e89a8ff1c144cfd11504ca310c2f X-System-Of-Record: true X-Gm-Message-State: ALoCoQk/eVx6WMOz89DhWLKeLZkt75u9d7g4gMFUafi4TOreRN1WsFJlRdX4Y8m/5BsrnONngJFIpQqjp2Hx9W+JXOUFfKNrx1yalYIQIoN5GCZhmZRfMA1osF7WqXj7gxhELwNVFapQZJDk/9IkDF0SpY8tZfbpcrOFRFsHEEY1y5zzDJjUtz171G1A71zDTQ6mqaYlESm4 Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 07:18:46 -0000 --e89a8ff1c144cfd11504ca310c2f Content-Type: text/plain; charset=ISO-8859-1 On Thu, Sep 20, 2012 at 4:00 PM, wrote: > Review and comments are more than welcome. > A couple of comments, having skimmed the draft: 1. Did you consider a requirement to support RFC 4191? Many people are asking for the ability to support more-specific routes, especially in the MIF working group. 2. REQ#28 says the device MUST (no less!) support ND proxy. I don't think it's appropriate to say that an experimental RFC is a requirement. Additionally, ND proxy is not fully baked, and it has issues with certain topologies. We need a better solution than that. 3. REQ#32 says the device must also be an RFC-6204 compliant IPv6 CE router. Are there no conflicts? --e89a8ff1c144cfd11504ca310c2f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Sep 20, 2012 at 4:00 PM, <mohamed.boucadair@orange.com= > wrote:
    Review and comments are more than welcome.

    <= div>A couple of comments, having skimmed the draft:

    1. Did you consider a requirement to support RFC 4191? Many people are as= king for the ability to support more-specific routes, especially in the MIF= working group.
    2. REQ#28 says the device MUST (no less!) support ND proxy. I don'= t think it's appropriate to say that an experimental RFC is a requireme= nt. Additionally, ND proxy is not fully baked, and it has issues with certa= in topologies. We need a better solution than that.
    3. REQ#32 says the device must also be an RFC-6204 compliant IPv6 CE r= outer. Are there no conflicts?
    --e89a8ff1c144cfd11504ca310c2f-- From mohamed.boucadair@orange.com Fri Sep 21 00:37:19 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26B6F21F8489 for ; Fri, 21 Sep 2012 00:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, SARE_SUB_OBFU_Q1=0.227, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mmaBl6sIYxzJ for ; Fri, 21 Sep 2012 00:37:18 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 5138F21F847A for ; Fri, 21 Sep 2012 00:37:18 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id E12A922C60C; Fri, 21 Sep 2012 09:37:16 +0200 (CEST) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id BBE0035C079; Fri, 21 Sep 2012 09:37:16 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Fri, 21 Sep 2012 09:37:16 +0200 From: To: Lorenzo Colitti Date: Fri, 21 Sep 2012 09:37:14 +0200 Thread-Topic: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update Thread-Index: Ac2XyVbKFShBZeRZT5SmItB66EOwdwAAE88Q Message-ID: <94C682931C08B048B7A8645303FDC9F36E5B1233CA@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E5A40D46C@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: 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_94C682931C08B048B7A8645303FDC9F36E5B1233CAPUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.9.1.82415 Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 07:37:19 -0000 --_000_94C682931C08B048B7A8645303FDC9F36E5B1233CAPUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Lorenzo, Please see inline. Cheers, Med ________________________________ De : Lorenzo Colitti [mailto:lorenzo@google.com] Envoy=E9 : vendredi 21 septembre 2012 09:18 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : IPv6 Ops WG Objet : Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update On Thu, Sep 20, 2012 at 4:00 PM, > wrote: Review and comments are more than welcome. A couple of comments, having skimmed the draft: 1. Did you consider a requirement to support RFC 4191? Many people are aski= ng for the ability to support more-specific routes, especially in the MIF w= orking group. [Med] We didn't considered it because there are some assumptions to be made= : e.g., do we expect all interfaces are connected to networks managed by th= e same administrative entity? How to manage conflicts if distinct policies = are sent? etc. 2. REQ#28 says the device MUST (no less!) support ND proxy. I don't think i= t's appropriate to say that an experimental RFC is a requirement. Additiona= lly, ND proxy is not fully baked, and it has issues with certain topologies= . We need a better solution than that. [Med] RFC4389 is the best reference we can quote at this stage. Do you have= a pointer to an I-D where these issues are discussed? We can add a pointer= to that I-D. 3. REQ#32 says the device must also be an RFC-6204 compliant IPv6 CE router= . Are there no conflicts? [Med] We didn't done that analysis as we are considering also scenarios for= fixed-mobile convergence where a CPE can be connected to a fixed network b= y default and in case of failure switch to the 3GPP network or scenario. I would see some conflicts if we added a REQ for RFC6204-bis as it lists so= me transition mechanisms which are not required for mobile networks. --_000_94C682931C08B048B7A8645303FDC9F36E5B1233CAPUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    Dear Lorenzo,
     
    Please see inline.
     
    Cheers,
    Med

    De : Lorenzo Colitti=20 [mailto:lorenzo@google.com]
    Envoy=E9 : vendredi 21 septem= bre=20 2012 09:18
    =C0 : BOUCADAIR Mohamed=20 OLNC/NAD/TIP
    Cc : IPv6 Ops WG
    Objet : Re:=20 [v6ops]=20 draft-binet-v6ops-cellular-host-reqs-rfc3316update

    On Thu, Sep 20, 2012 at 4:00 PM, <mohamed.boucadair@orange.com> wrote:
    Review and comments are more than welcome.

    A couple of comments, having skimmed the draft:

    1. Did you consider a requirement to support RFC 4191? Many people a= re=20 asking for the ability to support more-specific routes, especially in the= MIF=20 working group.
    [Med] We didn't considered it because there are= some=20 assumptions to be made: e.g., do we expect all interfaces are connected t= o=20 networks managed by the same administrative entity? How to manage conflic= ts if=20 distinct policies are sent? etc.
     
    2. REQ#28 says the device MUST (no less!) support ND proxy. I don't = think=20 it's appropriate to say that an experimental RFC is a requirement.=20 Additionally, ND proxy is not fully baked, and it has issues with certain= =20 topologies. We need a better solution than that.
    [Med] RFC4389 is the best reference we can quot= e at=20 this stage. Do you have a pointer to an I-D where these issues are discus= sed?=20 We can add a pointer to that I-D.
     
    3. REQ#32 says the device must also be an RFC-6204 compliant IPv6 CE= =20 router. Are there no conflicts?
    [Med] We didn't&n= bsp;done=20 that analysis as we are considering also scenarios for fixed-mobile= =20 convergence where a CPE can be connected to a fixed network by= =20 default and in case of failure switch to the 3GPP network or scenari= o.=20
    I would see some conflicts if we added a REQ for=20 RFC6204-bis as it lists some transition mechanisms which are no= t=20 required for mobile networks.
     
       
    --_000_94C682931C08B048B7A8645303FDC9F36E5B1233CAPUEXCB1Bnante_-- From hesham@elevatemobile.com Fri Sep 21 00:38:51 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B14EA21F86B1 for ; Fri, 21 Sep 2012 00:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n5zcO0acZBDb for ; Fri, 21 Sep 2012 00:38:51 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by ietfa.amsl.com (Postfix) with ESMTP id 22B5921F86A1 for ; Fri, 21 Sep 2012 00:38:43 -0700 (PDT) Received: from [60.242.128.199] (helo=[192.168.0.6]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1TExot-0003nX-Mw; Fri, 21 Sep 2012 17:38:39 +1000 User-Agent: Microsoft-MacOutlook/14.2.3.120616 Date: Fri, 21 Sep 2012 17:38:32 +1000 From: Hesham Soliman To: Message-ID: Thread-Topic: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-User: hesham@elevatemobile.com Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 07:38:51 -0000 A few quick comments on the drat having gone through it quickly. 1. Requirements 1 and 2 are sort of redundant in an IETF document. The purpose od RFC 3316 was t specify IETF protocols that should be supported by the cellular host. PDP context has nothing to do with IETF protocols and functionally speaking it's outside of the IP stack. Therefore, I see no reason for specifying this in an RFC. It's not harmful, but since it's specified elsewhere, having such redundancy can lead to confusion if 3GPP specs change for example. So it's best to remove them. 2. Same goes for the PCO. out of scope. It's no different than the IP stack "finding" these parameters in a file that come from "somewhere". 3. Req 5, I suggest a MAY instead of a SHOULD. 4. for req 6 and 7. Are we sure this is a SHOULD? Are we effectively requiring these functions for all deployments? It seems like a big mandate, who's pushing for this? Just need to see that we have consensus on this. I think Req 8 has the right keyword "MAY" and the same should apply to 6 and 7 IMO. 5. REQ 9 and 10 are also too strong. This is a MAY by the definition of keywords. It's an optimisation. 6. REQ 18 repeats 3316, although the reference has changed, so it's redundant. 7. REQ 19 conflicts with REQ 5, MAY Vs SHOULD. If they're both MAY I'm ok with that. 8. REQ 21 is completely redundant because this behaviour is mentioned in RFC 3314, 3316 and 3GPP specs. 9. REQ 27: For 3GPP specs there are defined standards for discovering their servers. Why would you list another mechanism not related to 3GPP? The purpose of the draft is to address a specific deployment. General IETF specs are available to all implementers and they can decide for themselves what they want to implement on top of the base. 10. I disagree with REQ 28. This is an experimental RFC. If someone does it that's fine, but no need to mandate it here. 11. REQ#29: "The cellular device MUST support Prefix Delegation capabilities [RFC3633 ]. Particularly, it MUST behave as a Requesting Router." => Why? Where did this come from? I disagree with this requirement. It's up to each implementation to decide that. At best, you could have a MAY but it's completely redundant. And as a consequence, so is REQ 30. 12. REQ#31: The cellular device SHOULD support Customer Side Translator (CLAT) [I-D.ietf-v6ops-464xlat ]. => Why? Why SHOULD? Again, at best a MAY. Thanks, Hesham From lorenzo@google.com Fri Sep 21 00:52:30 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7097121F8623 for ; Fri, 21 Sep 2012 00:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.752 X-Spam-Level: X-Spam-Status: No, score=-102.752 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s6u8NYOQ7sFC for ; Fri, 21 Sep 2012 00:52:29 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id C70D221F8444 for ; Fri, 21 Sep 2012 00:52:29 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so3339970obb.31 for ; Fri, 21 Sep 2012 00:52:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=tmIOJd4MGBwdx0fkn4rcjbjyuPpWp/7mLn+oFfumt/A=; b=gPKpknqqunK1Ff2pC0ORu1QsgoRn0+O3DJs/wnx5+922qSx3QjjS6RG+COMmKqP2pX 6L0lPi8A1ymmrlOJF7alTO6D9/qnBSCGTuS3EtU4fF5J1+zkG47TZhJeE57HK6w86oZa J0SRGI9Evzh/0SzcD8DaKUgaEv4vOh7I56Ip9yIC/D7Nrzn6K+3bad4kIscA58eoab3b 4A3VsraUdGZpIXJnJwOlweJL0+XTkuulI6G9HIQ24llwWRIDK3zIVWfPnqlRd0LfFPqJ uXMggdGJGZeuZYwk7hbhEKCNGAIhbAAFNdSY6dsaejdKqCRM+A2JR9gFqJb38wBP3HFG NiVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=tmIOJd4MGBwdx0fkn4rcjbjyuPpWp/7mLn+oFfumt/A=; b=CF8iM454kfg5jwptiH/W/dijYctKlgycTN8+Uks0tbRzJgkY3SUaoek6R6jYjGWGXd MHNLWQK4qJFR+weIOeK0HH7S4jZ6fCgTOT6SvfwuWeppzhRA+dNI1Tfu9k7I3jgEAwPp pb3/bbxYDd0OLBgqE/7woqD/xCElTK/QbAcQkAM8q8UjKqGgLJMVfoCfWfZRX4XpeGBG grQRVkSYjK2OiaQZhqZL2fVKHCa6ZK4OdgyL9XDpSWa4jAJUlYo0ndXzL8fJIlpFicL5 twdGycI8O4+ri4dApDtf/yQ7YJmMLWxjrfE3acBjEpCtYD+Hq59/QI0YANpZWKSaTSgA qlNg== Received: by 10.60.22.71 with SMTP id b7mr3201835oef.6.1348213949369; Fri, 21 Sep 2012 00:52:29 -0700 (PDT) Received: by 10.60.22.71 with SMTP id b7mr3201827oef.6.1348213949229; Fri, 21 Sep 2012 00:52:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.225.98 with HTTP; Fri, 21 Sep 2012 00:52:09 -0700 (PDT) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E5B1233CA@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E5A40D46C@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E5B1233CA@PUEXCB1B.nanterre.francetelecom.fr> From: Lorenzo Colitti Date: Fri, 21 Sep 2012 16:52:09 +0900 Message-ID: To: mohamed.boucadair@orange.com Content-Type: multipart/alternative; boundary=e89a8f839e8f866b9b04ca3185ab X-System-Of-Record: true X-Gm-Message-State: ALoCoQnT2dKUTr+7rI6EVmqnGFacnsqA25kQC41uVzXmLBR7F9X6ditsqk7h0sLkdYMl7uXd093HCibRUEXFrkcUKHjQRSyiI+aJbCQ2ed/+16A2DW8znXfBvR4XE7+/LCzn4EMDIdQzZcVH3omZhdsf6Lc6SMpkldsXCsnOkeazjOlaI5+wnr3w6XymXoMUZc9JpkbF89tD Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 07:52:30 -0000 --e89a8f839e8f866b9b04ca3185ab Content-Type: text/plain; charset=ISO-8859-1 On Fri, Sep 21, 2012 at 4:37 PM, wrote: > ** > > 1. Did you consider a requirement to support RFC 4191? Many people are > asking for the ability to support more-specific routes, especially in the > MIF working group. > [Med] We didn't considered it because there are some assumptions to be > made: e.g., do we expect all interfaces are connected to networks managed > by the same administrative entity? How to manage conflicts if distinct > policies are sent? etc. > > I don't understand. An interface is connected to only network, and the cellular link is point-to-point. By definition, there can only be one entity on the other side. Where's the conflict? > 2. REQ#28 says the device MUST (no less!) support ND proxy. I don't > think it's appropriate to say that an experimental RFC is a requirement. > Additionally, ND proxy is not fully baked, and it has issues with certain > topologies. We need a better solution than that. > [Med] RFC4389 is the best reference we can quote at this stage. Do you > have a pointer to an I-D where these issues are discussed? We can add a > pointer to that I-D. > > There is no working solution at this time. This can be made to work when tethering over the cellular link, but the ND proxy RFC is not the way to do it. I think we need a new document to specify this. --e89a8f839e8f866b9b04ca3185ab Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Sep 21, 2012 at 4:37 PM, <mohamed.boucadair@orange.com= > wrote:
    1. Did you consider a requirement to support RFC 4191? Many p= eople are=20 asking for the ability to support more-specific routes, especially in the= MIF=20 working group.
    [M= ed]=A0We didn't considered it because there are some=20 assumptions to be made: e.g., do we expect all interfaces are connected t= o=20 networks managed by the same administrative entity? How to manage conflic= ts if=20 distinct policies are sent? etc.

    I don't understand.=A0An interface= is connected to only network, and the cellular link is point-to-point. By = definition, there can only be one entity on the other side. Where's the= conflict?
    =A0
    =A02. REQ#28 says the device MUST (no less!) support ND= proxy. I don't think=20 it's appropriate to say that an experimental RFC is a requirement.=20 Additionally, ND proxy is not fully baked, and it has issues with certain= =20 topologies. We need a better solution than that.
    [Med]=A0RFC4389 is the best reference = we can quote at=20 this stage. Do you have a pointer to an I-D where these issues are discus= sed?=20 We can add a pointer to that I-D.
    <= /div>
    There is no working solution at this time. This can = be made to work when tethering over the cellular link, but the ND proxy RFC= is not the way to do it. I think we need a new document to specify this.
    --e89a8f839e8f866b9b04ca3185ab-- From hesham@elevatemobile.com Fri Sep 21 01:00:08 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9666521F87B4 for ; Fri, 21 Sep 2012 01:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.429 X-Spam-Level: X-Spam-Status: No, score=-2.429 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8WupvDjB8U09 for ; Fri, 21 Sep 2012 01:00:08 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by ietfa.amsl.com (Postfix) with ESMTP id 0273321F847A for ; Fri, 21 Sep 2012 01:00:07 -0700 (PDT) Received: from [60.242.128.199] (helo=[192.168.0.6]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1TEy9b-000097-2d; Fri, 21 Sep 2012 18:00:03 +1000 User-Agent: Microsoft-MacOutlook/14.2.3.120616 Date: Fri, 21 Sep 2012 17:59:57 +1000 From: Hesham Soliman To: Lorenzo Colitti , Message-ID: Thread-Topic: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-User: hesham@elevatemobile.com Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 08:00:08 -0000 > > > > 2. REQ#28 says the device MUST (no less!) support ND proxy. I don't >think > it's appropriate to say that an experimental RFC is a requirement. > Additionally, ND proxy is not fully baked, and it has issues with >certain > topologies. We need a better solution than that. >[Med] RFC4389 is the best reference we can quote at > this stage. Do you have a pointer to an I-D where these issues are >discussed? > We can add a pointer to that I-D. > > > > > > >There is no working solution at this time. This can be made to work when >tethering over the cellular link, but the ND proxy RFC is not the way to >do it. I think we need a new document to specify this. => We don't even need a new document. It's implementation specific. As per another thread iPad already has it. We should just remove the ND proxy from this draft. People don't need us to tell them how to tether over a single hop. Hesham > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From mohamed.boucadair@orange.com Fri Sep 21 01:04:26 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B64921F85C7 for ; Fri, 21 Sep 2012 01:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, SARE_SUB_OBFU_Q1=0.227, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LfSd4ugep+2l for ; Fri, 21 Sep 2012 01:04:25 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 4A19E21F8543 for ; Fri, 21 Sep 2012 01:04:25 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 7980A18C77A; Fri, 21 Sep 2012 10:04:24 +0200 (CEST) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 512EA27C0C1; Fri, 21 Sep 2012 10:04:24 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Fri, 21 Sep 2012 10:04:24 +0200 From: To: Lorenzo Colitti Date: Fri, 21 Sep 2012 10:04:23 +0200 Thread-Topic: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update Thread-Index: Ac2Xzg1He8xWfaxnTKyEVAEEe+lxxQAANr+g Message-ID: <94C682931C08B048B7A8645303FDC9F36E5B123404@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E5A40D46C@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E5B1233CA@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: 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_94C682931C08B048B7A8645303FDC9F36E5B123404PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.19.115414 Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 08:04:26 -0000 --_000_94C682931C08B048B7A8645303FDC9F36E5B123404PUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re-, Please see inline. Cheers, Med ________________________________ De : Lorenzo Colitti [mailto:lorenzo@google.com] Envoy=E9 : vendredi 21 septembre 2012 09:52 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : IPv6 Ops WG Objet : Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update On Fri, Sep 21, 2012 at 4:37 PM, > wrote: 1. Did you consider a requirement to support RFC 4191? Many people are aski= ng for the ability to support more-specific routes, especially in the MIF w= orking group. [Med] We didn't considered it because there are some assumptions to be made= : e.g., do we expect all interfaces are connected to networks managed by th= e same administrative entity? How to manage conflicts if distinct policies = are sent? etc. I don't understand. An interface is connected to only network, and the cell= ular link is point-to-point. By definition, there can only be one entity on= the other side. Where's the conflict? [Med] Consider the case the MIFed device is connected to both a 3G network = and WiFI hotspot simultaneously: if the hotspot and the 3G are managed by t= he same provider, then policies to offload (some of traffic) can be enforce= d using specific routes. But if these networks are not managed by same enti= ties and each of them are sending specific routes, wouldn't be there potent= ial conflict in the policies? What would be the behaviour of the device? 2. REQ#28 says the device MUST (no less!) support ND proxy. I don't think = it's appropriate to say that an experimental RFC is a requirement. Addition= ally, ND proxy is not fully baked, and it has issues with certain topologie= s. We need a better solution than that. [Med] RFC4389 is the best reference we can quote at this stage. Do you have= a pointer to an I-D where these issues are discussed? We can add a pointer= to that I-D. There is no working solution at this time. This can be made to work when te= thering over the cellular link, but the ND proxy RFC is not the way to do i= t. I think we need a new document to specify this. --_000_94C682931C08B048B7A8645303FDC9F36E5B123404PUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    Re-,
     
    Please see inline.
     
    Cheers,
    Med

    De : Lorenzo Colitti=20 [mailto:lorenzo@google.com]
    Envoy=E9 : vendredi 21 septem= bre=20 2012 09:52
    =C0 : BOUCADAIR Mohamed=20 OLNC/NAD/TIP
    Cc : IPv6 Ops WG
    Objet : Re:=20 [v6ops]=20 draft-binet-v6ops-cellular-host-reqs-rfc3316update

    On Fri, Sep 21, 2012 at 4:37 PM, <mohamed.boucadair@orange.com> wrote:
    1. Did you consider a requirement to support RFC 4191= ? Many=20 people are asking for the ability to support more-specific routes,=20 especially in the MIF working group.
    [Med] We didn't considered it because there= are=20 some assumptions to be made: e.g., do we expect all interfaces are=20 connected to networks managed by the same administrative entity? How = to=20 manage conflicts if distinct policies are sent?=20 etc.

    I don't understand. An interface is connected to only network, = and=20 the cellular link is point-to-point. By definition, there can only be one= =20 entity on the other side. Where's the conflict?
    [Med] Consider the case the MIFed dev= ice is=20 connected to both a 3G network and WiFI hotspot simultaneously: if t= he=20 hotspot and the 3G are managed by the same provider, then policies to=20 offload (some of traffic) can be enforced using specific routes= . But=20 if these networks are not managed by same entities and each of them are=20 sending specific routes, wouldn't be there potential confl= ict=20 in the policies? What would be the behaviour of the=20 device? 
     
     2. REQ#28 says the device MUST (no less!) sup= port=20 ND proxy. I don't think it's appropriate to say that an experimental = RFC=20 is a requirement. Additionally, ND proxy is not fully baked, and it h= as=20 issues with certain topologies. We need a better solution than that.<= /DIV>
    [Med] RFC4= 389 is=20 the best reference we can quote at this stage. Do you have a pointer = to an=20 I-D where these issues are discussed? We can add a pointer to that=20 I-D.
    There is no working solution at this time. This can be made to work = when=20 tethering over the cellular link, but the ND proxy RFC is not the way to = do=20 it. I think we need a new document to specify=20 this.
    --_000_94C682931C08B048B7A8645303FDC9F36E5B123404PUEXCB1Bnante_-- From mohamed.boucadair@orange.com Fri Sep 21 01:09:57 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0799A21F8658 for ; Fri, 21 Sep 2012 01:09:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, HELO_EQ_FR=0.35, SARE_SUB_OBFU_Q1=0.227, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dET8UNMt2EXo for ; Fri, 21 Sep 2012 01:09:55 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 137A221F8673 for ; Fri, 21 Sep 2012 01:09:55 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id EB70322C8C8; Fri, 21 Sep 2012 10:09:53 +0200 (CEST) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id D055C27C0C1; Fri, 21 Sep 2012 10:09:53 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Fri, 21 Sep 2012 10:09:53 +0200 From: To: Hesham Soliman , Lorenzo Colitti Date: Fri, 21 Sep 2012 10:09:52 +0200 Thread-Topic: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update Thread-Index: Ac2Xzx55AGY7X9kOQFCUsa/h+kjK+AAALOgw Message-ID: <94C682931C08B048B7A8645303FDC9F36E5B12340E@PUEXCB1B.nanterre.francetelecom.fr> References: In-Reply-To: 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.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.9.21.73318 Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 08:09:57 -0000 Re-, It is not only for tethering but for CPE-like service offering (e.g., http:= //www.flybox-tn.com/).=20 REQ#28 is under "device with LAN capabilities" section. We need to have a p= ointer to a solution to be embedded in the CPE for that case.=20 Is there any reason what this should we left it implementation-specific? Thanks.=20 Cheers, Med >-----Message d'origine----- >De : Hesham Soliman [mailto:hesham@elevatemobile.com]=20 >Envoy=E9 : vendredi 21 septembre 2012 10:00 >=C0 : Lorenzo Colitti; BOUCADAIR Mohamed OLNC/NAD/TIP >Cc : IPv6 Ops WG >Objet : Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update > >> >> >> >> 2. REQ#28 says the device MUST (no less!) support ND proxy. I don't >>think=20 >> it's appropriate to say that an experimental RFC is a requirement. >> Additionally, ND proxy is not fully baked, and it has issues with >>certain=20 >> topologies. We need a better solution than that. >>[Med] RFC4389 is the best reference we can quote at >> this stage. Do you have a pointer to an I-D where these issues are >>discussed?=20 >> We can add a pointer to that I-D. >> >> >> >> >> >> >>There is no working solution at this time. This can be made=20 >to work when >>tethering over the cellular link, but the ND proxy RFC is not=20 >the way to >>do it. I think we need a new document to specify this. > >=3D> We don't even need a new document. It's implementation=20 >specific. As per >another thread iPad already has it. We should just remove the ND proxy >from this draft. People don't need us to tell them how to tether over a >single hop.=20 > >Hesham > > > >> >>_______________________________________________ >>v6ops mailing list >>v6ops@ietf.org >>https://www.ietf.org/mailman/listinfo/v6ops > > >= From hesham@elevatemobile.com Fri Sep 21 01:14:12 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF6521F869F for ; Fri, 21 Sep 2012 01:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.41 X-Spam-Level: X-Spam-Status: No, score=-2.41 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94m+RBwFUKlb for ; Fri, 21 Sep 2012 01:14:11 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by ietfa.amsl.com (Postfix) with ESMTP id 2020E21F8681 for ; Fri, 21 Sep 2012 01:14:10 -0700 (PDT) Received: from [60.242.128.199] (helo=[192.168.0.6]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1TEyNA-0001Xs-Pl; Fri, 21 Sep 2012 18:14:05 +1000 User-Agent: Microsoft-MacOutlook/14.2.3.120616 Date: Fri, 21 Sep 2012 18:13:58 +1000 From: Hesham Soliman To: , Lorenzo Colitti Message-ID: Thread-Topic: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E5B12340E@PUEXCB1B.nanterre.francetelecom.fr> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Authenticated-User: hesham@elevatemobile.com Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 08:14:12 -0000 > >It is not only for tethering but for CPE-like service offering (e.g., >http://www.flybox-tn.com/). > >REQ#28 is under "device with LAN capabilities" section. We need to have a >pointer to a solution to be embedded in the CPE for that case. > >Is there any reason what this should we left it implementation-specific? =3D> Yes. For tethering, nothing is needed as it is implementation specific, i.e. it is solved within one node. As for other offers, there are two good reasons to not include this: 1. It's an experimental RFC. 2. Our role in this work is not to try to suggest new commercial offers for these devices, it is to explain which of the _current_ IETF specifications need to be supported to maintain a base level of communication.=20 Hesham > >Thanks.=20 > >Cheers, >Med > > >>-----Message d'origine----- >>De : Hesham Soliman [mailto:hesham@elevatemobile.com] >>Envoy=E9 : vendredi 21 septembre 2012 10:00 >>=C0 : Lorenzo Colitti; BOUCADAIR Mohamed OLNC/NAD/TIP >>Cc : IPv6 Ops WG >>Objet : Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update >> >>> >>> >>> >>> 2. REQ#28 says the device MUST (no less!) support ND proxy. I don't >>>think=20 >>> it's appropriate to say that an experimental RFC is a requirement. >>> Additionally, ND proxy is not fully baked, and it has issues with >>>certain=20 >>> topologies. We need a better solution than that. >>>[Med] RFC4389 is the best reference we can quote at >>> this stage. Do you have a pointer to an I-D where these issues are >>>discussed?=20 >>> We can add a pointer to that I-D. >>> >>> >>> >>> >>> >>> >>>There is no working solution at this time. This can be made >>to work when >>>tethering over the cellular link, but the ND proxy RFC is not >>the way to >>>do it. I think we need a new document to specify this. >> >>=3D> We don't even need a new document. It's implementation >>specific. As per >>another thread iPad already has it. We should just remove the ND proxy >>from this draft. People don't need us to tell them how to tether over a >>single hop.=20 >> >>Hesham >> >> >> >>> >>>_______________________________________________ >>>v6ops mailing list >>>v6ops@ietf.org >>>https://www.ietf.org/mailman/listinfo/v6ops >> >> From lorenzo@google.com Fri Sep 21 01:14:46 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25BA721F87B5 for ; Fri, 21 Sep 2012 01:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.752 X-Spam-Level: X-Spam-Status: No, score=-102.752 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A6NBphQ0mRVq for ; Fri, 21 Sep 2012 01:14:45 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7A62221F86F0 for ; Fri, 21 Sep 2012 01:14:44 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so3356608obb.31 for ; Fri, 21 Sep 2012 01:14:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=3mxFSlIBvcCTU7LmsvfV1wR/kks9Vgw1LfrasMeIpjA=; b=QHTetnr9qZHpebgtloYraUIS/jLLE8fsw3v28iLx8u/05YH3PhP6fIxejHSmm/pS/Z qgqrFm6rSXvRG6ePuCpswJZmPLFOq8KcIh/D+iBcmLYC2uNWc50n28mLCKpqnAY21T5h Zvb5j9wuK1loyqaZ3pCrF9TZAwhuLCVUjqvwZa1W2+w5xYm6DskKhq8U3Zysess9saY+ t1pKOisB8pcxozIjLee0JSUSPooj2dTqhM6h1QsrTvp5efEM906apC29IZ5r41gQ/JAp 8F6sC+GhnYpiu0tYLG8XKcMyzgAGG6IPEKkZerISdGa8K6aRK605wAvTfhgER7zeMzRK /jBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=3mxFSlIBvcCTU7LmsvfV1wR/kks9Vgw1LfrasMeIpjA=; b=kEfkngevMHsyosgLsWuJ5T+F7IexF2Yioy2+DoTy4fXav3061joEQyCqQcmns8lDOo wQ4ZyXytMcslz5Q572msTXDF0HRzzhgvbQokNeC5b7RwR4L6A1/G7B1TC0/gKTRkX7qi mhoHntEKAFteVYuI11PwBblN3gPmfdnLgH7zghG/XyGnS8NWXyTC70JIQ4SgrTjvGbTc G8+hfMNJU9lwF8ocVV8S3KU7hAqDjuB9BHBPGWVi+SGeB4eDUlXj2TUw/eUrHi9yXa4n 6e3D/nbPlpP27pJ79+xLFpKn7ytw3aIPsRRyPldO9HdjpLnOdHT4Vx0jz6yohgztPulu egEg== Received: by 10.182.52.42 with SMTP id q10mr3289814obo.46.1348215283837; Fri, 21 Sep 2012 01:14:43 -0700 (PDT) Received: by 10.182.52.42 with SMTP id q10mr3289808obo.46.1348215283717; Fri, 21 Sep 2012 01:14:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.225.98 with HTTP; Fri, 21 Sep 2012 01:14:23 -0700 (PDT) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E5B123404@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E5A40D46C@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E5B1233CA@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E5B123404@PUEXCB1B.nanterre.francetelecom.fr> From: Lorenzo Colitti Date: Fri, 21 Sep 2012 17:14:23 +0900 Message-ID: To: mohamed.boucadair@orange.com Content-Type: multipart/alternative; boundary=14dae93990711114af04ca31d51a X-System-Of-Record: true X-Gm-Message-State: ALoCoQlA9t+4CdLuAgncmljb4EcXjFfGccFRA8g6DNCH/4CeC/tBC6roKN7xPdxp9FTmKf/LX1oaTFdzt90C8MFu7EyoORMdjukNRV0vWlvq445HWsimAeIQ7erxuUC8IZw2C8N0v+OAsuIFpEjgJ9Pp7aLhqlBKo4z68QwBPWhftRPbcsbyPJ1Sujc7YDJqosBBLTKGWbSs Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 08:14:46 -0000 --14dae93990711114af04ca31d51a Content-Type: text/plain; charset=ISO-8859-1 On Fri, Sep 21, 2012 at 5:04 PM, wrote: > ** > > [Med] Consider the case the MIFed device is connected to both a 3G network > and WiFI hotspot simultaneously: if the hotspot and the 3G are managed by > the same provider, then policies to offload (some of traffic) can be > enforced using specific routes. But if these networks are not managed by > same entities and each of them are sending specific routes, wouldn't be > there potential conflict in the policies? What would be the behaviour of > the device? > > Longest-prefix match, just like it is today. If you want the wifi to have preference, just announce more specifics on the wifi and you're done. --14dae93990711114af04ca31d51a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Sep 21, 2012 at 5:04 PM, <mohamed.boucadair@orange.com= > wrote:
    [Med]=A0Consider the case=A0the MIFed=A0device is=20 connected to both a 3G network and=A0WiFI hotspot simultaneously: if the= =20 hotspot and the 3G are managed by the same provider, then policies to=20 offload=A0(some of traffic) can be enforced using specific=A0routes. But= =20 if these networks are not managed by same entities and each of them are= =20 sending=A0specific routes,=A0wouldn't be there=A0potential conflict= =20 in the policies? What=A0would be the behaviour of the=20 device?=A0
    Longest= -prefix match, just like it is today. If you want the wifi to have preferen= ce, just announce more specifics on the wifi and you're done.
    --14dae93990711114af04ca31d51a-- From phdgang@gmail.com Fri Sep 21 02:35:03 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03A5A21F871A for ; Fri, 21 Sep 2012 02:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.873 X-Spam-Level: X-Spam-Status: No, score=-1.873 tagged_above=-999 required=5 tests=[AWL=-1.401, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MANGLED_EXTNSN=2.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CTBmNiNtYqsO for ; Fri, 21 Sep 2012 02:35:02 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 16E5521F8723 for ; Fri, 21 Sep 2012 02:35:02 -0700 (PDT) Received: by vbbfc26 with SMTP id fc26so3927950vbb.31 for ; Fri, 21 Sep 2012 02:35:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=K0Gm5ryMqLONBTnuol1MqbwTeW2MzsI5OQW8T0OmuWM=; b=xaXGnBDvFV0hl5KMM4J9G6lbbp/Vu3UVLEhp98A0anL74uSbIWn/y7ZnSO6qzjf+4w G+SzWk9VPVFm3ZMDYyV59Se6pPy5PBpMl83f8998+w9xUi15CIpx/Uk1unrcP7W8Ffhz vpka152oZiJO6HpbKUnDoHsMXAXf+2bLK4PS5pI4QKfkUOtMwBfNDCw387DgsfNmB2cQ rfZeB8V/7t+lqK9ZCvkGBCtZGfK9fe0SyH/IVv3OLGO2g6zFoUDH/mK0rAX5Vr0V6sz9 BLxhURn0ZAOcKcFVCt/J/QoIL6g29Mi6Vhv3HbSO2I8GR0TRMYAcvjfF42HxrSbWs3dH cfCw== MIME-Version: 1.0 Received: by 10.58.79.178 with SMTP id k18mr2801633vex.3.1348220101533; Fri, 21 Sep 2012 02:35:01 -0700 (PDT) Received: by 10.58.114.231 with HTTP; Fri, 21 Sep 2012 02:35:01 -0700 (PDT) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E5B12338F@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E5A40D46C@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E5B12338F@PUEXCB1B.nanterre.francetelecom.fr> Date: Fri, 21 Sep 2012 17:35:01 +0800 Message-ID: From: GangChen To: mohamed.boucadair@orange.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 09:35:03 -0000 Hello Med, 2012/9/21, mohamed.boucadair@orange.com : > Hi Gang, > > Thanks for the review. > > Please see inline. > > Cheers, > Med > >>-----Message d'origine----- >>De : GangChen [mailto:phdgang@gmail.com] >>Envoy=E9 : jeudi 20 septembre 2012 17:13 >>=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >>Cc : IPv6 Ops WG >>Objet : Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update >> >>Hello Med, >> >>Thanks for the work. I read the draft. >>In general, the requirements have been structured as Basic >>Connectivity, Advanced and APIs & Applications >>Just wondering to know what release of cellular host the requirements >>are targeting? In a cellular context, the IPv6 capability is closely depending on 3GPP Rel= ease. I guess it would help if the draft could identify the particular context. >>What's the consideration to frame the context of each section? >>I have noticed that some basic IPv6 capability is mentioned in the >>part of Advanced Requirements. That seems to me should belong to the >>Basic part. >> >>More details are as following. >> >>2. Basic Connectivity Requirements >>REQ#1, >>REQ#2, >>REQ#3 and REQ#4 were already specified in 3GPP. >>Not sure it would add much discussions to the draft. Acknowledged. However, I guess the draft is supposed to document something IETF-specific.Those requirements seem to belong 3GPP scope. > Med: The purpose of the draft is to have one place where an IPv6 profile = for > cellular device is device. There are several requirements on the UEs spre= ad > in various specification document. Listing those 3GPP spec is one part of > the puzzle to define an IPv6 profile for cellular hosts. > >> >>REQ#6 and REQ#7 should be combined IMHO, because it provides same >>outcome solving the issues related to compatibility of IPv4 >>applications.> Answer is expected on this point. >>REQ#8: I don't understand the purpose of embed a DNS64 function. >>Especially, the sentence of "This allows to be compatible with DNSSEC" > > Med: I see Ted already answered to this comment. Yes. That answers my question. Thanks >>REQ#10 I guess I-D.ietf-behave-nat64-discovery-heuristic should be >>ranked as first priority compared to >>I-D.boucadair-pcp-nat64-prefix64-option > > Med: Please refer to > http://www.ietf.org/mail-archive/web/pcp/current/msg02273.html for the > discussion I had with Teemu on this item. I-D.boucadair-pcp-nat64-prefix64-option is a individual I-D Only concern is we can't tell what would be available in the future. >> >>REQ#11: Preferring native IPv6 doesn't always achieve good effect. It >>may cause additional charge in some cases. Please refer to >>http://tools.ietf.org/html/draft-ietf-mif-happy-eyeballs-extens >>ion-00#page-3 >>case 4 for further information > > Med: I added a pointer to the MIF draft to record the issue. > >> >>One additional requirement maybe worth to add for the completeness: >> >>REQ#XX The cellular device SHOULD embed a BIH function [RFC6535] >>facilitating the communication between IPv4 application and IPv6 >>server > > Med: As we have CLAT already listed there, what would be the motivation t= o > include BIH? > I added a discussion note to the draft to record this point. They are working in a complementary way but different cases. 464xlat is working for an IPv4 application talking to IPv4 servers going through IPv6 network. BIH is to enable an IPv4 application talking to IPv6 servers within an IPv6 network. >> >>2.1. WiFi Connectivity >> >>It may be complementary to add one additional requirement, like >> >>REQ#XX Prefix Delegation capabilities [RFC3633] MUST be supported on >>the Wi-Fi interface. > > Med: Wouldn't this be redundant with what is the features discussed in > Section 4? It's not redundant because the requirements of DHCP-PD would apply to different chips. BRs Gang >> >> >>3. Advanced Requirements >> >> REQ#16, >> REQ#17, >> REQ#18, >> REQ#19 and REQ#20 may be proper to be shifted to "2. Basic >>Connectivity Requirements", since those features are basic IPv6 >>capability > > Med: I will check. > >> >>REQ#22: it maybe proper to change the *SHOULD* to *MAY* > > Med: What is the rationale behind that change? >> >>Best Regards >> >>Gang >> >>2012/9/20, mohamed.boucadair@orange.com : >>> Dear all, >>> >>> We submitted this new I-D. >>> >>> Review and comments are more than welcome. >>> >>> Cheers, >>> Med >>> >>> >>> -----Message d'origine----- >>> De : i-d-announce-bounces@ietf.org >>[mailto:i-d-announce-bounces@ietf.org] De >>> la part de internet-drafts@ietf.org >>> Envoy=E9 : mercredi 19 septembre 2012 14:57 >>> =C0 : i-d-announce@ietf.org >>> Objet : I-D Action: >>> draft-binet-v6ops-cellular-host-reqs-rfc3316update-00.txt >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> >>> >>> Title : Internet Protocol Version 6 (IPv6) >>for Cellular Hosts >>> Author(s) : David Binet >>> Mohamed Boucadair >>> Filename : >>> draft-binet-v6ops-cellular-host-reqs-rfc3316update-00.txt >>> Pages : 14 >>> Date : 2012-09-19 >>> >>> Abstract: >>> This document lists a set of IPv6-related requirements to be >>> supported by cellular hosts. >>> >>> This document updates RFC3316. >>> >>> >>> >>> The IETF datatracker status page for this draft is: >>> >>https://datatracker.ietf.org/doc/draft-binet-v6ops-cellular-hos >>t-reqs-rfc3316update >>> >>> There's also a htmlized version available at: >>> >>http://tools.ietf.org/html/draft-binet-v6ops-cellular-host-reqs >>-rfc3316update-00 >>> >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> >> From hesham@elevatemobile.com Fri Sep 21 02:41:26 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE2121F8780 for ; Fri, 21 Sep 2012 02:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sboo8Y-fX4fc for ; Fri, 21 Sep 2012 02:41:25 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by ietfa.amsl.com (Postfix) with ESMTP id AD51A21F874A for ; Fri, 21 Sep 2012 02:41:24 -0700 (PDT) Received: from [60.242.128.199] (helo=[192.168.0.6]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1TEzje-0005lZ-Cb; Fri, 21 Sep 2012 19:41:22 +1000 User-Agent: Microsoft-MacOutlook/14.2.3.120616 Date: Fri, 21 Sep 2012 19:41:14 +1000 From: Hesham Soliman To: Hesham Soliman , Message-ID: Thread-Topic: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-User: hesham@elevatemobile.com Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 09:41:26 -0000 one more comment, I believe RFC 5555 is mentioned in LTE specs. It should be listed as a MAY IMO. Hesham -----Original Message----- From: Hesham Soliman Date: Friday, 21 September 2012 5:38 PM To: Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update >A few quick comments on the drat having gone through it quickly. > >1. Requirements 1 and 2 are sort of redundant in an IETF document. The >purpose od RFC 3316 was t specify IETF protocols that should be supported >by the cellular host. PDP context has nothing to do with IETF protocols >and functionally speaking it's outside of the IP stack. Therefore, I see >no reason for specifying this in an RFC. It's not harmful, but since it's >specified elsewhere, having such redundancy can lead to confusion if 3GPP >specs change for example. So it's best to remove them. > >2. Same goes for the PCO. out of scope. It's no different than the IP >stack "finding" these parameters in a file that come from "somewhere". > >3. Req 5, I suggest a MAY instead of a SHOULD. > >4. for req 6 and 7. Are we sure this is a SHOULD? Are we effectively >requiring these functions for all deployments? It seems like a big >mandate, who's pushing for this? Just need to see that we have consensus >on this. I think Req 8 has the right keyword "MAY" and the same should >apply to 6 and 7 IMO. > >5. REQ 9 and 10 are also too strong. This is a MAY by the definition of >keywords. It's an optimisation. > >6. REQ 18 repeats 3316, although the reference has changed, so it's >redundant. > >7. REQ 19 conflicts with REQ 5, MAY Vs SHOULD. If they're both MAY I'm ok >with that. > >8. REQ 21 is completely redundant because this behaviour is mentioned in >RFC 3314, 3316 and 3GPP specs. > >9. REQ 27: For 3GPP specs there are defined standards for discovering >their servers. Why would you list another mechanism not related to 3GPP? >The purpose of the draft is to address a specific deployment. General IETF >specs are available to all implementers and they can decide for themselves >what they want to implement on top of the base. > >10. I disagree with REQ 28. This is an experimental RFC. If someone does >it that's fine, but no need to mandate it here. > >11. REQ#29: "The cellular device MUST support Prefix Delegation > capabilities [RFC3633 ]. >Particularly, it MUST behave as a > Requesting Router." > >=> Why? Where did this come from? I disagree with this requirement. It's >up to each implementation to decide that. At best, you could have a MAY >but it's completely redundant. And as a consequence, so is REQ 30. > > >12. REQ#31: The cellular device SHOULD support Customer Side Translator > (CLAT) [I-D.ietf-v6ops-464xlat >d >ate-00#ref-I-D.ietf-v6ops-464xlat>]. > >=> Why? Why SHOULD? Again, at best a MAY. > >Thanks, >Hesham > > > > > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From jouni.nospam@gmail.com Fri Sep 21 03:27:59 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B103F21F8688 for ; Fri, 21 Sep 2012 03:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.186 X-Spam-Level: X-Spam-Status: No, score=-3.186 tagged_above=-999 required=5 tests=[AWL=-0.413, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ri1yorsKhHU for ; Fri, 21 Sep 2012 03:27:59 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id A302421F8687 for ; Fri, 21 Sep 2012 03:27:57 -0700 (PDT) Received: by bkty12 with SMTP id y12so1600376bkt.31 for ; Fri, 21 Sep 2012 03:27:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=tnF10FcyKXA99VfflQqZ1sOIn7xTyDDvLAxSU/03VAs=; b=ggvkHV3SjJ6kxRcyTbeeWgd2FjshPjx83UxSqgkldKsUrnV+z5mY4h0xzm5BT87xCh eDEN19sADA/QviJsY7KneuFKc21OLbZsC1MMenJyvGSMrE1wICeNgo8fk7+HZq2HufUl zUXUnFSmemMWyiPpXyihg7zUDFr4FX++EMwmp7zNTskre8zWC24u2dKiiRPHir+yk1tI KERFhczzoAZ3h+i0Y4Br0VzG4Koc5H38+K9HisKyuTKABfiaR2+ThPkfHeRTyS5xjiDj sByl6tgvSEKW8dSR84IXxDBdSZm53Ursij0m1jv/FuIT6VkbR6ZwuWBTx/Jf3nPZ/eU4 ozuA== Received: by 10.205.120.16 with SMTP id fw16mr1878760bkc.102.1348223276707; Fri, 21 Sep 2012 03:27:56 -0700 (PDT) Received: from ?IPv6:2001:6e8:2100:100:223:32ff:fec9:7938? ([2001:6e8:2100:100:223:32ff:fec9:7938]) by mx.google.com with ESMTPS id t23sm5941730bks.4.2012.09.21.03.27.51 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 21 Sep 2012 03:27:53 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E5B123404@PUEXCB1B.nanterre.francetelecom.fr> Date: Fri, 21 Sep 2012 13:27:49 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <765A5155-1D90-4F1F-B5CD-E2E3CD18633B@gmail.com> References: <94C682931C08B048B7A8645303FDC9F36E5A40D46C@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E5B1233CA@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E5B123404@PUEXCB1B.nanterre.francetelecom.fr> To: X-Mailer: Apple Mail (2.1084) Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 10:27:59 -0000 Med, On Sep 21, 2012, at 11:04 AM, = wrote: >=20 > I don't understand. An interface is connected to only network, and the = cellular link is point-to-point. By definition, there can only be one = entity on the other side. Where's the conflict? > [Med] Consider the case the MIFed device is connected to both a 3G = network and WiFI hotspot simultaneously: if the hotspot and the 3G are = managed by the same provider, then policies to offload (some of traffic) = can be enforced using specific routes. But if these networks are not = managed by same entities and each of them are sending specific routes, = wouldn't be there potential conflict in the policies? What would be = the behaviour of the device?=20 RFC4191 also brings in router preferences. You do not need to bother too = much with specific routes. Simple example to make cellular preference low and = others stay on default. More specific routes can be installed on those = destinations=20 you definitely want to flow through your cellular infra. We got some = good results with that, specifically when you configure your mobile to allow RC4191 = extensions only from your cellular interface (trivial e.g. on any Linux based = device). So the mobile operator still has the control. That has been dealt several times = in Mif. - Jouni > =20 > 2. REQ#28 says the device MUST (no less!) support ND proxy. I don't = think it's appropriate to say that an experimental RFC is a requirement. = Additionally, ND proxy is not fully baked, and it has issues with = certain topologies. We need a better solution than that. > [Med] RFC4389 is the best reference we can quote at this stage. Do you = have a pointer to an I-D where these issues are discussed? We can add a = pointer to that I-D. > There is no working solution at this time. This can be made to work = when tethering over the cellular link, but the ND proxy RFC is not the = way to do it. I think we need a new document to specify this. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From mohamed.boucadair@orange.com Fri Sep 21 05:07:40 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62C7321F87AD for ; Fri, 21 Sep 2012 05:07:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.71 X-Spam-Level: X-Spam-Status: No, score=-1.71 tagged_above=-999 required=5 tests=[AWL=-0.289, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, SARE_SUB_OBFU_Q1=0.227, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z9lJSt047oA3 for ; Fri, 21 Sep 2012 05:07:39 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 83B7321F87AA for ; Fri, 21 Sep 2012 05:07:39 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 4BD0D18C1CD; Fri, 21 Sep 2012 14:07:38 +0200 (CEST) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 20A7835C082; Fri, 21 Sep 2012 14:07:38 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Fri, 21 Sep 2012 14:07:37 +0200 From: To: Hesham Soliman Date: Fri, 21 Sep 2012 14:07:36 +0200 Thread-Topic: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update Thread-Index: Ac2XzCJCMXxYqqT4Q9WsPBMFm+3X4AAADd2w Message-ID: <94C682931C08B048B7A8645303FDC9F36E5B1235A3@PUEXCB1B.nanterre.francetelecom.fr> References: In-Reply-To: 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.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.9.1.82415 Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 12:07:40 -0000 Dear Hesham, Thanks for the review. Please see inline.=20 Cheers, Med=20 >-----Message d'origine----- >De : Hesham Soliman [mailto:hesham@elevatemobile.com]=20 >Envoy=E9 : vendredi 21 septembre 2012 09:39 >=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >Cc : IPv6 Ops WG >Objet : Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update > >A few quick comments on the drat having gone through it quickly. > >1. Requirements 1 and 2 are sort of redundant in an IETF document. The >purpose od RFC 3316 was t specify IETF protocols that should=20 >be supported >by the cellular host. PDP context has nothing to do with IETF protocols >and functionally speaking it's outside of the IP stack.=20 >Therefore, I see >no reason for specifying this in an RFC. It's not harmful, but=20 >since it's >specified elsewhere, having such redundancy can lead to=20 >confusion if 3GPP >specs change for example. So it's best to remove them. Med: I see the point but we consider it from another perspective: We tried = to answer to the question "What a device should support in order to be IPv6= -compliant + be able to be connected to a3GPP network". There is no single = document defining an IPv6 profile for cellular hosts/devices. We wanted a s= ingle document listed both IETF and 3GPP specification.=20 > >2. Same goes for the PCO. out of scope. It's no different than the IP >stack "finding" these parameters in a file that come from "somewhere". Med: Same as above. > >3. Req 5, I suggest a MAY instead of a SHOULD. Med: I just found this req conflicts with REQ#19. I will double check.=20 > >4. for req 6 and 7. Are we sure this is a SHOULD? Are we effectively >requiring these functions for all deployments? It seems like a big >mandate, who's pushing for this? Just need to see that we have=20 >consensus >on this. I think Req 8 has the right keyword "MAY" and the same should >apply to 6 and 7 IMO. Med: These are important features to support if we want IPv6-only connectiv= ity model to fly.=20 > >5. REQ 9 and 10 are also too strong. This is a MAY by the definition of >keywords. It's an optimisation. Med: There are various reasons to have PCP as SHOULD: save the battery cons= umption, reduce keepalive message, Control and retrieve the lifetime of NAT= bindings, ease NAT and firewall traversal for application embedding IP add= ress and/or port number(s) in the application payload, allow for successful= inbound communications and for the capability to control outgoing connecti= ons, control and retrieve the lifetime of NAT bindings (including implicit = ones), allow NAT binding recovery, trigger applications to repairs their bi= ndings whenever this is required. > >6. REQ 18 repeats 3316, although the reference has changed, so it's >redundant.=20 > >7. REQ 19 conflicts with REQ 5, MAY Vs SHOULD. If they're both=20 >MAY I'm ok >with that.=20 Med: Thanks for catching this. > >8. REQ 21 is completely redundant because this behaviour is=20 >mentioned in >RFC 3314, 3316 and 3GPP specs. > >9. REQ 27: For 3GPP specs there are defined standards for discovering >their servers. Why would you list another mechanism not=20 >related to 3GPP? Med: This is an optional feature which would solve an issue of bootstrappin= g in a non-3GPP network. I have added a note in http://tools.ietf.org/html/= draft-binet-v6ops-cellular-host-reqs-rfc3316update-01:=20 [DISCUSSION NOTE: Since this is still an individual submission, should we remove this item?] >The purpose of the draft is to address a specific deployment.=20 >General IETF >specs are available to all implementers and they can decide=20 >for themselves >what they want to implement on top of the base. > >10. I disagree with REQ 28. This is an experimental RFC. If=20 >someone does >it that's fine, but no need to mandate it here. Med: This is for a CPE-like service. We need a solution for the issue discu= ssed in that REQ. RFC4389 is what we have now. If there is any better ref, = I can add it. > >11. REQ#29: "The cellular device MUST support Prefix Delegation > capabilities [RFC3633 ]. >Particularly, it MUST behave as a > Requesting Router." > >=3D> Why? Where did this come from? I disagree with this=20 >requirement. It's >up to each implementation to decide that. At best, you could have a MAY >but it's completely redundant. And as a consequence, so is REQ 30. > Med: REQ#29 and REQ#30 have been merged in -01 (http://tools.ietf.org/html/= draft-binet-v6ops-cellular-host-reqs-rfc3316update-01) > >12. REQ#31: The cellular device SHOULD support Customer Side=20 >Translator > (CLAT) [I-D.ietf-v6ops-464xlat >s-rfc3316upd >ate-00#ref-I-D.ietf-v6ops-464xlat>]. > >=3D> Why? Why SHOULD? Again, at best a MAY. Med: This is for the case where there is an IPv4 host connected behind the = cellular CPE. > >Thanks, >Hesham >= From Ted.Lemon@nominum.com Fri Sep 21 05:14:49 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0C2721F873C for ; Fri, 21 Sep 2012 05:14:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.427 X-Spam-Level: X-Spam-Status: No, score=-106.427 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zz5dQvzFx1UM for ; Fri, 21 Sep 2012 05:14:49 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id 3D0EA21F871A for ; Fri, 21 Sep 2012 05:14:49 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKUFxaOOhHWnKobgTY8AE+hAkBJDX7hA/B@postini.com; Fri, 21 Sep 2012 05:14:49 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 522011B829C for ; Fri, 21 Sep 2012 05:14:48 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 41CB919005C; Fri, 21 Sep 2012 05:14:48 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0247.003; Fri, 21 Sep 2012 05:14:42 -0700 From: Ted Lemon To: "mohamed.boucadair@orange.com" Thread-Topic: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update Thread-Index: Ac2WZk6bkygjt2tHRWm0TALPSDGcNgAlw55wAEGmCYAAALQnAAAJZaUA//+Moj4= Date: Fri, 21 Sep 2012 12:14:42 +0000 Message-ID: <316C3D1C-DC6C-422D-8105-763A936A693A@nominum.com> References: , <94C682931C08B048B7A8645303FDC9F36E5B1235A3@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E5B1235A3@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 12:14:49 -0000 On Sep 21, 2012, at 8:07 AM, "mohamed.boucadair@orange.com" wrote: >> 4. for req 6 and 7. Are we sure this is a SHOULD? Are we effectively >> requiring these functions for all deployments? It seems like a big >> mandate, who's pushing for this? Just need to see that we have=20 >> consensus >> on this. I think Req 8 has the right keyword "MAY" and the same should >> apply to 6 and 7 IMO. >=20 > Med: These are important features to support if we want IPv6-only connect= ivity model to fly.=20 My general reaction to the document is that the requirements are too weak a= nd I would like to see them strengthened. I think requirement 8, for exampl= e, should be a SHOULD, not a MAY. implementors can still ignore a SHOULD, = but in doing so they are clearly leaving out an important feature, not just= skipping something nobody cares very much about. = From mohamed.boucadair@orange.com Fri Sep 21 05:15:06 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2ED021F8797 for ; Fri, 21 Sep 2012 05:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, HELO_EQ_FR=0.35, SARE_SUB_OBFU_Q1=0.227, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7Gj3e2axgnb for ; Fri, 21 Sep 2012 05:15: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 1938621F8790 for ; Fri, 21 Sep 2012 05:15:05 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 4DD543B4151; Fri, 21 Sep 2012 14:15:04 +0200 (CEST) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 3298427C046; Fri, 21 Sep 2012 14:15:04 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Fri, 21 Sep 2012 14:15:04 +0200 From: To: Hesham Soliman Date: Fri, 21 Sep 2012 14:15:03 +0200 Thread-Topic: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update Thread-Index: Ac2X3UZnWODRlUSuSDSbZJZ87uGevgAFIlrg Message-ID: <94C682931C08B048B7A8645303FDC9F36E5B1235AB@PUEXCB1B.nanterre.francetelecom.fr> References: In-Reply-To: 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.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.19.115414 Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 12:15:06 -0000 Re-, I'm neutral on the support of this one. I added this new REQ to Section 3 t= o record it in the I-D: "REQ#28: The cellular host MAY support [RFC5555]." Thanks. Cheers, Med=20 >-----Message d'origine----- >De : Hesham Soliman [mailto:hesham@elevatemobile.com]=20 >Envoy=E9 : vendredi 21 septembre 2012 11:41 >=C0 : Hesham Soliman; BOUCADAIR Mohamed OLNC/NAD/TIP >Cc : IPv6 Ops WG >Objet : Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update > >one more comment, I believe RFC 5555 is mentioned in LTE=20 >specs. It should >be listed as a MAY IMO. > >Hesham > >-----Original Message----- >From: Hesham Soliman >Date: Friday, 21 September 2012 5:38 PM >To: >Cc: IPv6 Ops WG >Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update > >>A few quick comments on the drat having gone through it quickly. >> >>1. Requirements 1 and 2 are sort of redundant in an IETF document. The >>purpose od RFC 3316 was t specify IETF protocols that should=20 >be supported >>by the cellular host. PDP context has nothing to do with IETF=20 >protocols >>and functionally speaking it's outside of the IP stack.=20 >Therefore, I see >>no reason for specifying this in an RFC. It's not harmful,=20 >but since it's >>specified elsewhere, having such redundancy can lead to=20 >confusion if 3GPP >>specs change for example. So it's best to remove them. >> >>2. Same goes for the PCO. out of scope. It's no different than the IP >>stack "finding" these parameters in a file that come from "somewhere". >> >>3. Req 5, I suggest a MAY instead of a SHOULD. >> >>4. for req 6 and 7. Are we sure this is a SHOULD? Are we effectively >>requiring these functions for all deployments? It seems like a big >>mandate, who's pushing for this? Just need to see that we=20 >have consensus >>on this. I think Req 8 has the right keyword "MAY" and the same should >>apply to 6 and 7 IMO. >> >>5. REQ 9 and 10 are also too strong. This is a MAY by the=20 >definition of >>keywords. It's an optimisation. >> >>6. REQ 18 repeats 3316, although the reference has changed, so it's >>redundant.=20 >> >>7. REQ 19 conflicts with REQ 5, MAY Vs SHOULD. If they're=20 >both MAY I'm ok >>with that.=20 >> >>8. REQ 21 is completely redundant because this behaviour is=20 >mentioned in >>RFC 3314, 3316 and 3GPP specs. >> >>9. REQ 27: For 3GPP specs there are defined standards for discovering >>their servers. Why would you list another mechanism not=20 >related to 3GPP? >>The purpose of the draft is to address a specific deployment.=20 >General IETF >>specs are available to all implementers and they can decide=20 >for themselves >>what they want to implement on top of the base. >> >>10. I disagree with REQ 28. This is an experimental RFC. If=20 >someone does >>it that's fine, but no need to mandate it here. >> >>11. REQ#29: "The cellular device MUST support Prefix Delegation >> capabilities [RFC3633 ]. >>Particularly, it MUST behave as a >> Requesting Router." >> >>=3D> Why? Where did this come from? I disagree with this=20 >requirement. It's >>up to each implementation to decide that. At best, you could=20 >have a MAY >>but it's completely redundant. And as a consequence, so is REQ 30. >> >> >>12. REQ#31: The cellular device SHOULD support Customer Side=20 >Translator >> (CLAT) [I-D.ietf-v6ops-464xlat >>qs-rfc3316up >>d >>ate-00#ref-I-D.ietf-v6ops-464xlat>]. >> >>=3D> Why? Why SHOULD? Again, at best a MAY. >> >>Thanks, >>Hesham >> >> >> >> >> >>_______________________________________________ >>v6ops mailing list >>v6ops@ietf.org >>https://www.ietf.org/mailman/listinfo/v6ops > > >= From mohamed.boucadair@orange.com Fri Sep 21 05:21:32 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF12421F878B for ; Fri, 21 Sep 2012 05:21:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, HELO_EQ_FR=0.35, SARE_SUB_OBFU_Q1=0.227, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93MltQxaKQGL for ; Fri, 21 Sep 2012 05:21:32 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 2A55421F87AA for ; Fri, 21 Sep 2012 05:21:32 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 7BC4F3245AD; Fri, 21 Sep 2012 14:21:31 +0200 (CEST) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 60ED84C06C; Fri, 21 Sep 2012 14:21:31 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Fri, 21 Sep 2012 14:21:31 +0200 From: To: Ted Lemon Date: Fri, 21 Sep 2012 14:21:30 +0200 Thread-Topic: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update Thread-Index: Ac2WZk6bkygjt2tHRWm0TALPSDGcNgAlw55wAEGmCYAAALQnAAAJZaUA//+Moj7///+ZIA== Message-ID: <94C682931C08B048B7A8645303FDC9F36E5B1235B4@PUEXCB1B.nanterre.francetelecom.fr> References: , <94C682931C08B048B7A8645303FDC9F36E5B1235A3@PUEXCB1B.nanterre.francetelecom.fr> <316C3D1C-DC6C-422D-8105-763A936A693A@nominum.com> In-Reply-To: <316C3D1C-DC6C-422D-8105-763A936A693A@nominum.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.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.19.115414 Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 12:21:33 -0000 Dear Ted, I fully agree with this comment.=20 We need input from the WG to "tune" the requirements. Cheers, Med=20 >-----Message d'origine----- >De : Ted Lemon [mailto:Ted.Lemon@nominum.com]=20 >Envoy=E9 : vendredi 21 septembre 2012 14:15 >=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >Cc : Hesham Soliman; IPv6 Ops WG >Objet : Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update > >On Sep 21, 2012, at 8:07 AM, "mohamed.boucadair@orange.com"=20 > wrote: >>> 4. for req 6 and 7. Are we sure this is a SHOULD? Are we effectively >>> requiring these functions for all deployments? It seems like a big >>> mandate, who's pushing for this? Just need to see that we have=20 >>> consensus >>> on this. I think Req 8 has the right keyword "MAY" and the=20 >same should >>> apply to 6 and 7 IMO. >>=20 >> Med: These are important features to support if we want=20 >IPv6-only connectivity model to fly.=20 > >My general reaction to the document is that the requirements=20 >are too weak and I would like to see them strengthened. I=20 >think requirement 8, for example, should be a SHOULD, not a=20 >MAY. implementors can still ignore a SHOULD, but in doing so=20 >they are clearly leaving out an important feature, not just=20 >skipping something nobody cares very much about. = From mohamed.boucadair@orange.com Fri Sep 21 05:25:05 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFFCB21F87E4 for ; Fri, 21 Sep 2012 05:25:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.702 X-Spam-Level: X-Spam-Status: No, score=-1.702 tagged_above=-999 required=5 tests=[AWL=-0.281, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, SARE_SUB_OBFU_Q1=0.227, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rEI+5gnz-XcF for ; Fri, 21 Sep 2012 05:25: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 2B76121F878B for ; Fri, 21 Sep 2012 05:25:05 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 8849B18C475; Fri, 21 Sep 2012 14:25:04 +0200 (CEST) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 683BF35C05A; Fri, 21 Sep 2012 14:25:04 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Fri, 21 Sep 2012 14:25:04 +0200 From: To: jouni korhonen Date: Fri, 21 Sep 2012 14:25:02 +0200 Thread-Topic: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update Thread-Index: Ac2X48aEwFMWLtL5RA27/hgaeADdQwAD+tlw Message-ID: <94C682931C08B048B7A8645303FDC9F36E5B1235B9@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E5A40D46C@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E5B1233CA@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E5B123404@PUEXCB1B.nanterre.francetelecom.fr> <765A5155-1D90-4F1F-B5CD-E2E3CD18633B@gmail.com> In-Reply-To: <765A5155-1D90-4F1F-B5CD-E2E3CD18633B@gmail.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.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.9.1.82415 Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 12:25:06 -0000 Hi Jouni, That makes sense.=20 I added a new REQ to Section 3 for RFC4191. Thanks.=20 Cheers, Med=20 >-----Message d'origine----- >De : jouni korhonen [mailto:jouni.nospam@gmail.com]=20 >Envoy=E9 : vendredi 21 septembre 2012 12:28 >=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >Cc : Lorenzo Colitti; IPv6 Ops WG >Objet : Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update > > >Med, > >On Sep 21, 2012, at 11:04 AM, =20 > wrote: > >>=20 >> I don't understand. An interface is connected to only=20 >network, and the cellular link is point-to-point. By=20 >definition, there can only be one entity on the other side.=20 >Where's the conflict? >> [Med] Consider the case the MIFed device is connected to=20 >both a 3G network and WiFI hotspot simultaneously: if the=20 >hotspot and the 3G are managed by the same provider, then=20 >policies to offload (some of traffic) can be enforced using=20 >specific routes. But if these networks are not managed by same=20 >entities and each of them are sending specific routes,=20 >wouldn't be there potential conflict in the policies? What=20 >would be the behaviour of the device?=20 > >RFC4191 also brings in router preferences. You do not need to=20 >bother too much >with specific routes. Simple example to make cellular=20 >preference low and others >stay on default. More specific routes can be installed on=20 >those destinations=20 >you definitely want to flow through your cellular infra. We=20 >got some good results >with that, specifically when you configure your mobile to=20 >allow RC4191 extensions >only from your cellular interface (trivial e.g. on any Linux=20 >based device). So the >mobile operator still has the control. That has been dealt=20 >several times in Mif. > >- Jouni > > > > >> =20 >> 2. REQ#28 says the device MUST (no less!) support ND proxy.=20 >I don't think it's appropriate to say that an experimental RFC=20 >is a requirement. Additionally, ND proxy is not fully baked,=20 >and it has issues with certain topologies. We need a better=20 >solution than that. >> [Med] RFC4389 is the best reference we can quote at this=20 >stage. Do you have a pointer to an I-D where these issues are=20 >discussed? We can add a pointer to that I-D. >> There is no working solution at this time. This can be made=20 >to work when tethering over the cellular link, but the ND=20 >proxy RFC is not the way to do it. I think we need a new=20 >document to specify this. >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > >= From hesham@elevatemobile.com Fri Sep 21 06:04:25 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4779921F8710 for ; Fri, 21 Sep 2012 06:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[AWL=-0.323, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VRTZ3p2VblH3 for ; Fri, 21 Sep 2012 06:04:24 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by ietfa.amsl.com (Postfix) with ESMTP id 6059621F8568 for ; Fri, 21 Sep 2012 06:04:23 -0700 (PDT) Received: from [60.242.128.199] (helo=[192.168.0.6]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1TF2u3-0004Fs-Gj; Fri, 21 Sep 2012 23:04:20 +1000 User-Agent: Microsoft-MacOutlook/14.2.3.120616 Date: Fri, 21 Sep 2012 23:04:08 +1000 From: Hesham Soliman To: Message-ID: Thread-Topic: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E5B1235A3@PUEXCB1B.nanterre.francetelecom.fr> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-User: hesham@elevatemobile.com Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 13:04:25 -0000 >> >>A few quick comments on the drat having gone through it quickly. >> >>1. Requirements 1 and 2 are sort of redundant in an IETF document. The >>purpose od RFC 3316 was t specify IETF protocols that should >>be supported >>by the cellular host. PDP context has nothing to do with IETF protocols >>and functionally speaking it's outside of the IP stack. >>Therefore, I see >>no reason for specifying this in an RFC. It's not harmful, but >>since it's >>specified elsewhere, having such redundancy can lead to >>confusion if 3GPP >>specs change for example. So it's best to remove them. > >Med: I see the point but we consider it from another perspective: We >tried to answer to the question "What a device should support in order to >be IPv6-compliant + be able to be connected to a3GPP network". => So why don't you talk about the radio interface? :) It's out of scope. The PDP context is the same. It's out of scope for IETF. >There is no single document defining an IPv6 profile for cellular >hosts/devices. We wanted a single document listed both IETF and 3GPP >specification. => There is, RFC 3316, which you're trying to update and it doesn't talk about link layers. > >> >>4. for req 6 and 7. Are we sure this is a SHOULD? Are we effectively >>requiring these functions for all deployments? It seems like a big >>mandate, who's pushing for this? Just need to see that we have >>consensus >>on this. I think Req 8 has the right keyword "MAY" and the same should >>apply to 6 and 7 IMO. > >Med: These are important features to support if we want IPv6-only >connectivity model to fly. => But they're not the only way to support IPv6-only. There are many different variations therefore SHOULD/MUST is way too strong. Please check the definitions of should and must. > > >> >>5. REQ 9 and 10 are also too strong. This is a MAY by the definition of >>keywords. It's an optimisation. > >Med: There are various reasons to have PCP as SHOULD: save the battery >consumption, reduce keepalive message, Control and retrieve the lifetime >of NAT bindings, ease NAT and firewall traversal for application >embedding IP address and/or port number(s) in the application payload, >allow for successful inbound communications and for the capability to >control outgoing connections, control and retrieve the lifetime of NAT >bindings (including implicit ones), allow NAT binding recovery, trigger >applications to repairs their bindings whenever this is required. => I wasn't discussing the features of PCP, it's more about the keyword used. Should means you basically have to support it unless you know better. In practice everyone follows a should. It's not optional. >> >>8. REQ 21 is completely redundant because this behaviour is >>mentioned in >>RFC 3314, 3316 and 3GPP specs. >> >>9. REQ 27: For 3GPP specs there are defined standards for discovering >>their servers. Why would you list another mechanism not >>related to 3GPP? > >Med: This is an optional feature which would solve an issue of >bootstrapping in a non-3GPP network. I have added a note in >http://tools.ietf.org/html/draft-binet-v6ops-cellular-host-reqs-rfc3316upd >ate-01: > > [DISCUSSION NOTE: Since this is still an individual submission, > should we remove this item?] > > >>The purpose of the draft is to address a specific deployment. >>General IETF >>specs are available to all implementers and they can decide >>for themselves >>what they want to implement on top of the base. >> >>10. I disagree with REQ 28. This is an experimental RFC. If >>someone does >>it that's fine, but no need to mandate it here. > >Med: This is for a CPE-like service. We need a solution for the issue >discussed in that REQ. RFC4389 is what we have now. If there is any >better ref, I can add it. => I think I responded to this separately. > >> >>11. REQ#29: "The cellular device MUST support Prefix Delegation >> capabilities [RFC3633 ]. >>Particularly, it MUST behave as a >> Requesting Router." >> >>=> Why? Where did this come from? I disagree with this >>requirement. It's >>up to each implementation to decide that. At best, you could have a MAY >>but it's completely redundant. And as a consequence, so is REQ 30. >> > >Med: REQ#29 and REQ#30 have been merged in -01 >(http://tools.ietf.org/html/draft-binet-v6ops-cellular-host-reqs-rfc3316up >date-01) > >> >>12. REQ#31: The cellular device SHOULD support Customer Side >>Translator >> (CLAT) [I-D.ietf-v6ops-464xlat >>>s-rfc3316upd >>ate-00#ref-I-D.ietf-v6ops-464xlat>]. >> >>=> Why? Why SHOULD? Again, at best a MAY. > >Med: This is for the case where there is an IPv4 host connected behind >the cellular CPE. => Again, I'm objecting to the level of support not the use case. Hesham > >> >>Thanks, >>Hesham From Ted.Lemon@nominum.com Fri Sep 21 06:13:58 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F18721F8776 for ; Fri, 21 Sep 2012 06:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.427 X-Spam-Level: X-Spam-Status: No, score=-106.427 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nSn08bshcPba for ; Fri, 21 Sep 2012 06:13:58 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id D546521F8770 for ; Fri, 21 Sep 2012 06:13:57 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKUFxoFfp/Yj4KuwRYLHl6bdqYwAkuJ/f5@postini.com; Fri, 21 Sep 2012 06:13:57 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 401501B82AD for ; Fri, 21 Sep 2012 06:13:57 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 374E819005C; Fri, 21 Sep 2012 06:13:57 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Fri, 21 Sep 2012 06:13:57 -0700 From: Ted Lemon To: Hesham Soliman Thread-Topic: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update Thread-Index: Ac2WZk6bkygjt2tHRWm0TALPSDGcNgAlw55wAEGmCYAAALQnAAAJZaUAAAH5cwAAAFd4gA== Date: Fri, 21 Sep 2012 13:13:56 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 13:13:58 -0000 On Sep 21, 2012, at 9:04 AM, Hesham Soliman wrote: > =3D> But they're not the only way to support IPv6-only. There are many > different variations therefore SHOULD/MUST is way too strong. Please chec= k > the definitions of should and must. This response seems to be based on the assumption that many different devic= e implementors will make many different choices, and that operators will th= erefore have to support every possible set of choices that may have been ma= de when implementing each specific device. This is the exact opposite of = what a requirements document like this one is supposed to achieve. The po= int of these requirements is to create a reasonable baseline set of expecta= tions that operators can have about devices that will connect to their netw= orks. If, as a device implementor, you don't want to have to implement th= e recommended functionality, that's fine, but then you can't claim to suppo= rt the requirements in the document. Of course, a SHOULD requirement doesn't prevent you from claiming you suppo= rt the document, unfortunately. But at least is gives you a strong hint t= hat the functionality is desirable, and its absence will mean that your dev= ice may not provide a good feature set on some operator networks. From ietf-secretariat@ietf.org Fri Sep 21 06:17:47 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1193C21F880C; Fri, 21 Sep 2012 06:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.286 X-Spam-Level: X-Spam-Status: No, score=-102.286 tagged_above=-999 required=5 tests=[AWL=-0.287, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WbnflMjE5-O5; Fri, 21 Sep 2012 06:17:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E19421F87E5; Fri, 21 Sep 2012 06:17:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120921131746.9793.61038.idtracker@ietfa.amsl.com> Date: Fri, 21 Sep 2012 06:17:46 -0700 Cc: iaoc@ietf.org, opsec@ietf.org, sidr@ietf.org, v6ops@ietf.org, wgchairs@ietf.org Subject: [v6ops] IETF Large Interim Meeting - OPSEC, SIDR and V6OPS X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 13:17:47 -0000 OPSEC, SIDR and V6OPS Interim Meeting Amsterdam, The Netherlands 29 September 2012 Venue: Hotel Okura Amsterdam (www.okura.nl) Ferdinand Bolstraat 333 1072 LH Amsterdam The Netherlands 1. Registration 2. Accommodations - Reservations Cutoff: 21 September 3. Meeting Schedule 1. Registration A. Fee: $100 USD B. Register online at: http://www.ietf.org/registration/lim2012/ietfreg.= py C. Online Registration and Payment closes on 28 September 2012 D. On Site Registration starting Saturday, 29 September at 8:00 AM 2. Accommodations A block of rooms is being held at the Hotel Okura Amsterdam (meeting venu= e) for the nights of September 28 and 29. Rate: 195 EUR [256 USD; 20,065 JPY] Rate includes breakfast and guest room wireless internet but excludes 5= % city tax. To make your reservation on line, please go to: www.okura.nl Group Code: IETF2012 Reservations cut-off date: 21 September 2012 Guest Cancellation: - Reservations may be changed up to 1 week prior to the event without pen= alty. (You can change, not cancel, the reservation, i.e. change arrival, departure dates or name, up to 1 week without penalty but not cancel the reservation without penalty.) - 50% of reservation value penalty for cancellation less than 14 days and= greater than 7 days prior to event. If you cancel, not change, the reserva= tion less than 14 days but more than 7 days prior to the event you will be = charged 50% of the total reservation fee. - 80% of reservation value penalty for cancellation less than 7 days and = greater than 3 days prior to event. If you cancel, not change, the reservat= ion less than 7 days prior to the event you will be charged 80% of the tota= l reservation fee. - 100% of reservation value penalty for cancellation less than 3 days pri= or to event or non-arrival or no-show. - In case of early departure, the full value of the reservation will be c= harged to the guest. If you have any problems making your reservation, please send a message to = agenda@ietf.org 3. Meeting Schedule 0900-1700 CEST SIDR 0900-1130 CEST OPSEC 1330-1630 CEST V6OPS From hesham@elevatemobile.com Fri Sep 21 06:19:49 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C78F221F8589 for ; Fri, 21 Sep 2012 06:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.341 X-Spam-Level: X-Spam-Status: No, score=-2.341 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2XLcpi+UUsh2 for ; Fri, 21 Sep 2012 06:19:49 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by ietfa.amsl.com (Postfix) with ESMTP id BEB6321F8629 for ; Fri, 21 Sep 2012 06:19:47 -0700 (PDT) Received: from [60.242.128.199] (helo=[192.168.0.6]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1TF38s-00054H-KZ; Fri, 21 Sep 2012 23:19:39 +1000 User-Agent: Microsoft-MacOutlook/14.2.3.120616 Date: Fri, 21 Sep 2012 23:19:30 +1000 From: Hesham Soliman To: Ted Lemon Message-ID: Thread-Topic: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-User: hesham@elevatemobile.com Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 13:19:49 -0000 > >On Sep 21, 2012, at 9:04 AM, Hesham Soliman > wrote: >> => But they're not the only way to support IPv6-only. There are many >> different variations therefore SHOULD/MUST is way too strong. Please >>check >> the definitions of should and must. > >This response seems to be based on the assumption that many different >device implementors will make many different choices, and that operators >will therefore have to support every possible set of choices that may >have been made when implementing each specific device. This is the >exact opposite of what a requirements document like this one is supposed >to achieve. The point of these requirements is to create a reasonable >baseline set of expectations that operators can have about devices that >will connect to their networks. => And has there been on consensus on that mechanism? Because if there is consensus on one approach then lets remove a few more requirements. The current draft seems to select two approaches from what I remember. >If, as a device implementor, you don't want to have to implement the >recommended functionality, that's fine, but then you can't claim to >support the requirements in the document. > >Of course, a SHOULD requirement doesn't prevent you from claiming you >support the document, unfortunately. But at least is gives you a strong >hint that the functionality is desirable, and its absence will mean that >your device may not provide a good feature set on some operator networks. => Of course, but some IETF consensus needs to be established before selecting a couple of mechanisms and saying that's it! Speaking of which, I'm assuming the IPv6 WG is going to review this draft as well. Hesham > From mohamed.boucadair@orange.com Fri Sep 21 06:27:09 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8706F21F875C for ; Fri, 21 Sep 2012 06:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.694 X-Spam-Level: X-Spam-Status: No, score=-1.694 tagged_above=-999 required=5 tests=[AWL=-0.273, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, SARE_SUB_OBFU_Q1=0.227, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bpHa2nxvKRlH for ; Fri, 21 Sep 2012 06:27:08 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 709E921F86F3 for ; Fri, 21 Sep 2012 06:27:01 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id A4A9A3B43BB; Fri, 21 Sep 2012 15:27:00 +0200 (CEST) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 87D6C27C067; Fri, 21 Sep 2012 15:27:00 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Fri, 21 Sep 2012 15:27:00 +0200 From: To: Hesham Soliman Date: Fri, 21 Sep 2012 15:26:58 +0200 Thread-Topic: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update Thread-Index: Ac2X+aCk4RbGIyqQT+GS35Ym6UM/bQAAkwiA Message-ID: <94C682931C08B048B7A8645303FDC9F36E5B123633@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E5B1235A3@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: 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.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.19.115414 Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 13:27:09 -0000 Re-, Please see inline.=20 Cheers, Med=20 >-----Message d'origine----- >De : Hesham Soliman [mailto:hesham@elevatemobile.com]=20 >Envoy=E9 : vendredi 21 septembre 2012 15:04 >=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >Cc : IPv6 Ops WG >Objet : Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update > >>> >>>A few quick comments on the drat having gone through it quickly. >>> >>>1. Requirements 1 and 2 are sort of redundant in an IETF=20 >document. The >>>purpose od RFC 3316 was t specify IETF protocols that should >>>be supported >>>by the cellular host. PDP context has nothing to do with=20 >IETF protocols >>>and functionally speaking it's outside of the IP stack. >>>Therefore, I see >>>no reason for specifying this in an RFC. It's not harmful, but >>>since it's >>>specified elsewhere, having such redundancy can lead to >>>confusion if 3GPP >>>specs change for example. So it's best to remove them. >> >>Med: I see the point but we consider it from another perspective: We >>tried to answer to the question "What a device should support=20 >in order to >>be IPv6-compliant + be able to be connected to a3GPP network". > >=3D> So why don't you talk about the radio interface? :) Med: is this related to IPv6? ;-) It's=20 >out of scope. >The PDP context is the same. It's out of scope for IETF. > > >>There is no single document defining an IPv6 profile for cellular >>hosts/devices. We wanted a single document listed both IETF and 3GPP >>specification. > >=3D> There is, RFC 3316, which you're trying to update and it=20 >doesn't talk >about link layers.=20 Med: This is not a reason to not include it in the update.=20 >> >>> >>>4. for req 6 and 7. Are we sure this is a SHOULD? Are we effectively >>>requiring these functions for all deployments? It seems like a big >>>mandate, who's pushing for this? Just need to see that we have >>>consensus >>>on this. I think Req 8 has the right keyword "MAY" and the=20 >same should >>>apply to 6 and 7 IMO. >> >>Med: These are important features to support if we want IPv6-only >>connectivity model to fly. > >=3D> But they're not the only way to support IPv6-only. There are many >different variations therefore SHOULD/MUST is way too strong.=20 >Please check >the definitions of should and must. Med: I'm aware of the definitions. If we indicate all important features as= MAY, then there is little chance to see the feature supported.=20 >> >>> >>>5. REQ 9 and 10 are also too strong. This is a MAY by the=20 >definition of >>>keywords. It's an optimisation. >> >>Med: There are various reasons to have PCP as SHOULD: save the battery >>consumption, reduce keepalive message, Control and retrieve=20 >the lifetime >>of NAT bindings, ease NAT and firewall traversal for application >>embedding IP address and/or port number(s) in the application payload, >>allow for successful inbound communications and for the capability to >>control outgoing connections, control and retrieve the lifetime of NAT >>bindings (including implicit ones), allow NAT binding=20 >recovery, trigger >>applications to repairs their bindings whenever this is required. > >=3D> I wasn't discussing the features of PCP, it's more about the keyword >used. Should means you basically have to support it unless you know >better. In practice everyone follows a should. It's not optional. > >>> >>>8. REQ 21 is completely redundant because this behaviour is >>>mentioned in >>>RFC 3314, 3316 and 3GPP specs. >>> >>>9. REQ 27: For 3GPP specs there are defined standards for discovering >>>their servers. Why would you list another mechanism not >>>related to 3GPP? >> >>Med: This is an optional feature which would solve an issue of >>bootstrapping in a non-3GPP network. I have added a note in >>http://tools.ietf.org/html/draft-binet-v6ops-cellular-host-req >s-rfc3316upd >>ate-01:=20 >> >> [DISCUSSION NOTE: Since this is still an individual=20 >submission, >> should we remove this item?] >> >> >>>The purpose of the draft is to address a specific deployment. >>>General IETF >>>specs are available to all implementers and they can decide >>>for themselves >>>what they want to implement on top of the base. >>> >>>10. I disagree with REQ 28. This is an experimental RFC. If >>>someone does >>>it that's fine, but no need to mandate it here. >> >>Med: This is for a CPE-like service. We need a solution for the issue >>discussed in that REQ. RFC4389 is what we have now. If there is any >>better ref, I can add it. > >=3D> I think I responded to this separately. > >> >>> >>>11. REQ#29: "The cellular device MUST support Prefix Delegation >>> capabilities [RFC3633 ]. >>>Particularly, it MUST behave as a >>> Requesting Router." >>> >>>=3D> Why? Where did this come from? I disagree with this >>>requirement. It's >>>up to each implementation to decide that. At best, you could=20 >have a MAY >>>but it's completely redundant. And as a consequence, so is REQ 30. >>> >> >>Med: REQ#29 and REQ#30 have been merged in -01 >>(http://tools.ietf.org/html/draft-binet-v6ops-cellular-host-re >qs-rfc3316up >>date-01) >> >>> >>>12. REQ#31: The cellular device SHOULD support Customer Side >>>Translator >>> (CLAT) [I-D.ietf-v6ops-464xlat >>>>>s-rfc3316upd >>>ate-00#ref-I-D.ietf-v6ops-464xlat>]. >>> >>>=3D> Why? Why SHOULD? Again, at best a MAY. >> >>Med: This is for the case where there is an IPv4 host connected behind >>the cellular CPE. > >=3D> Again, I'm objecting to the level of support not the use case. Med: From a SP standpoint, I do think this disserves a "SHOULD". It seems w= e disagree on the level of the requirement. I need to hear from other WG me= mbers on what exact word to use.=20 > >Hesham > >> >>> >>>Thanks, >>>Hesham > > >= From hesham@elevatemobile.com Fri Sep 21 06:34:09 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0169121F87AE for ; Fri, 21 Sep 2012 06:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.045 X-Spam-Level: X-Spam-Status: No, score=-2.045 tagged_above=-999 required=5 tests=[AWL=-0.273, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OYbr0bXEaBn9 for ; Fri, 21 Sep 2012 06:34:08 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by ietfa.amsl.com (Postfix) with ESMTP id 5C8D521F878B for ; Fri, 21 Sep 2012 06:34:08 -0700 (PDT) Received: from [60.242.128.199] (helo=[192.168.0.6]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1TF3Mr-0006Bg-Sm; Fri, 21 Sep 2012 23:34:06 +1000 User-Agent: Microsoft-MacOutlook/14.2.3.120616 Date: Fri, 21 Sep 2012 23:34:00 +1000 From: Hesham Soliman To: Message-ID: Thread-Topic: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E5B123633@PUEXCB1B.nanterre.francetelecom.fr> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-User: hesham@elevatemobile.com Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 13:34:09 -0000 >>>> >>>> >>>> >>>>A few quick comments on the drat having gone through it quickly. >>>> >>>>1. Requirements 1 and 2 are sort of redundant in an IETF >>document. The >>>>purpose od RFC 3316 was t specify IETF protocols that should >>>>be supported >>>>by the cellular host. PDP context has nothing to do with >>IETF protocols >>>>and functionally speaking it's outside of the IP stack. >>>>Therefore, I see >>>>no reason for specifying this in an RFC. It's not harmful, but >>>>since it's >>>>specified elsewhere, having such redundancy can lead to >>>>confusion if 3GPP >>>>specs change for example. So it's best to remove them. >>> >>>Med: I see the point but we consider it from another perspective: We >>>tried to answer to the question "What a device should support >>in order to >>>be IPv6-compliant + be able to be connected to a3GPP network". >> >>=> So why don't you talk about the radio interface? :) > >Med: is this related to IPv6? ;-) > > It's >>out of scope. >>The PDP context is the same. It's out of scope for IETF. >> >> >>>There is no single document defining an IPv6 profile for cellular >>>hosts/devices. We wanted a single document listed both IETF and 3GPP >>>specification. >> >>=> There is, RFC 3316, which you're trying to update and it >>doesn't talk >>about link layers. > >Med: This is not a reason to not include it in the update. => But you're not responding to the reasons I stated above. It's out of scope because it's not defined in IETF. >>=> But they're not the only way to support IPv6-only. There are many >>different variations therefore SHOULD/MUST is way too strong. >>Please check >>the definitions of should and must. > >Med: I'm aware of the definitions. If we indicate all important features >as MAY, then there is little chance to see the feature supported. => I wasn't commenting on "all important features" I'm talking about specific requirements. Please respond to the comment without generalising it to something I didn't say. Hesham From gilbert_kim@vanguard.com Fri Sep 21 06:46:53 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93F0721F8826 for ; Fri, 21 Sep 2012 06:46:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.74 X-Spam-Level: X-Spam-Status: No, score=-4.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tW2lfLRAVlmK for ; Fri, 21 Sep 2012 06:46:53 -0700 (PDT) Received: from pslna865.vanguard.com (pslna865.vanguard.com [192.175.194.33]) by ietfa.amsl.com (Postfix) with ESMTP id DF45221F8702 for ; Fri, 21 Sep 2012 06:46:52 -0700 (PDT) Received: from pslna812.vanguard.com (pslna812.vanguard.com [10.221.33.198]) by pslna865.vanguard.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.1.1) with ESMTP id q8LDkpof009613 for ; Fri, 21 Sep 2012 09:46:52 -0400 X-DKIM: OpenDKIM Filter v2.1.3 pslna865.vanguard.com q8LDkpof009613 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=vanguard.com; s=vanguard; t=1348235212; bh=0I57Sgj/h4X4WqmqzyH+AdjI0y4=; l=823; h=Subject:From:To:Message-ID:Date:MIME-Version:Content-type; b=KbN0YF9Qkrk5/spdLhoidVnZTD/2FqF6ONW0CoqyoPc+i17QFmePQvu8570hQUHag 9Um4gr7HyYuFjeUm5rQDQ== Received: from pslva867.vanguard.com (pslva867.vanguard.com [10.17.9.44]) by pslna812.vanguard.com (8.14.4/8.14.4) with ESMTP id q8LDkpmK027120 for ; Fri, 21 Sep 2012 09:46:51 -0400 Received: from vgi4mail.vanguard.com (pvnva784.Vanguard.COM [10.17.128.144]) by pslva867.vanguard.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.1.1) with ESMTP id q8LDipFi005970 for ; Fri, 21 Sep 2012 09:44:51 -0400 Auto-Submitted: auto-generated From: gilbert_kim@vanguard.com To: v6ops@ietf.org Message-ID: Date: Fri, 21 Sep 2012 09:44:49 -0400 X-MIMETrack: Serialize by Router on VGI4Mail/VGI(Release 8.5.2FP2|March 22, 2011) at 09/21/2012 09:44:15 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: [v6ops] Gilbert Kim is out of office. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 13:46:53 -0000 I will be out of the office starting 09/21/2012 and will not return until 09/24/2012. I am currently out of the country with limited access to email. If you need immediate assistance please contact Scott Yarosh. ---------------------------------------------------------------------- CONFIDENTIALITY STATEMENT. The information contained in this e-mail message, including attachments, is the confidential information of, and/or is the property of, Vanguard. The information is intended for use solely by the individual or entity named in the message. If you are not an intended recipient or you received this in error, then any review, printing, copying, or distribution of any such information is prohibited, and please notify the sender immediately by reply e-mail and then delete this e-mail from your system. From mohamed.boucadair@orange.com Fri Sep 21 06:47:59 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A470721F8717 for ; Fri, 21 Sep 2012 06:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.686 X-Spam-Level: X-Spam-Status: No, score=-1.686 tagged_above=-999 required=5 tests=[AWL=-0.265, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, SARE_SUB_OBFU_Q1=0.227, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mtmXYMy41Scc for ; Fri, 21 Sep 2012 06:47:59 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id EAA3621F845C for ; Fri, 21 Sep 2012 06:47:58 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 5C45D3B442C; Fri, 21 Sep 2012 15:47:58 +0200 (CEST) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 3A76423807F; Fri, 21 Sep 2012 15:47:58 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Fri, 21 Sep 2012 15:47:58 +0200 From: To: Hesham Soliman Date: Fri, 21 Sep 2012 15:47:56 +0200 Thread-Topic: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update Thread-Index: Ac2X/cjHKhpc8MX3R3q5KqWn6frexAAACRJQ Message-ID: <94C682931C08B048B7A8645303FDC9F36E5B12365F@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E5B123633@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: 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.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.9.21.114516 Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 13:47:59 -0000 Re-, Please see inline.=20 Cheers, Med=20 >-----Message d'origine----- >De : Hesham Soliman [mailto:hesham@elevatemobile.com]=20 >Envoy=E9 : vendredi 21 septembre 2012 15:34 >=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >Cc : IPv6 Ops WG >Objet : Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update > >>>>> >>>>> >>>>> >>>>>A few quick comments on the drat having gone through it quickly. >>>>> >>>>>1. Requirements 1 and 2 are sort of redundant in an IETF >>>document. The >>>>>purpose od RFC 3316 was t specify IETF protocols that should >>>>>be supported >>>>>by the cellular host. PDP context has nothing to do with >>>IETF protocols >>>>>and functionally speaking it's outside of the IP stack. >>>>>Therefore, I see >>>>>no reason for specifying this in an RFC. It's not harmful, but >>>>>since it's >>>>>specified elsewhere, having such redundancy can lead to >>>>>confusion if 3GPP >>>>>specs change for example. So it's best to remove them. >>>> >>>>Med: I see the point but we consider it from another perspective: We >>>>tried to answer to the question "What a device should support >>>in order to >>>>be IPv6-compliant + be able to be connected to a3GPP network". >>> >>>=3D> So why don't you talk about the radio interface? :) >> >>Med: is this related to IPv6? ;-) >> >> It's=20 >>>out of scope. >>>The PDP context is the same. It's out of scope for IETF. >>> >>> >>>>There is no single document defining an IPv6 profile for cellular >>>>hosts/devices. We wanted a single document listed both IETF and 3GPP >>>>specification. >>> >>>=3D> There is, RFC 3316, which you're trying to update and it >>>doesn't talk >>>about link layers. >> >>Med: This is not a reason to not include it in the update. > > >=3D> But you're not responding to the reasons I stated above. It's out of >scope because it's not defined in IETF. Med: Should we care about frontiers between SDOs when the goal is to ensure= interoperability? IMHO, we should not. What we want to achieve with this d= ocument is to list a basic set of IPv6 requirements for cellular hosts no m= atter if the requirement is defined in IETF or 3GPP.=20 My current take is: it is useful to have in one common place both IETF and = non-IETF REQs. I see you don't agree with this position.=20 This is still an individual submission. If the WG adopts this work, then we= will record whatever the WG wants us to do: If the consensus is to drop th= ose 3GPP-related requirements, then we will do it. From Ted.Lemon@nominum.com Fri Sep 21 06:56:38 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1C7E21F8838 for ; Fri, 21 Sep 2012 06:56:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.125 X-Spam-Level: X-Spam-Status: No, score=-106.125 tagged_above=-999 required=5 tests=[AWL=-0.353, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fF1YEyfB89wJ for ; Fri, 21 Sep 2012 06:56:38 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id AE2B321F8839 for ; Fri, 21 Sep 2012 06:56:34 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKUFxyCxD3pDk6sIOugi+hA55KgU6gk8s6@postini.com; Fri, 21 Sep 2012 06:56:34 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 65BB61B829A for ; Fri, 21 Sep 2012 06:56:27 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 5CE0019005C for ; Fri, 21 Sep 2012 06:56:27 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Fri, 21 Sep 2012 06:56:27 -0700 From: Ted Lemon To: IPv6 Ops WG Thread-Topic: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update Thread-Index: Ac2WZk6bkygjt2tHRWm0TALPSDGcNgAlw55wAEGmCYAAALQnAAAJZaUAAAH5cwAAAFd4gAAAMesAAAFKEIA= Date: Fri, 21 Sep 2012 13:56:26 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <3A426EF285D71946A3D281DE307B04BB@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 13:56:38 -0000 On Sep 21, 2012, at 9:19 AM, Hesham Soliman wrot= e: > And has there been on consensus on that mechanism? Because if there is > consensus on one approach then lets remove a few more requirements. The > current draft seems to select two approaches from what I remember. It would be inappropriate for the v6ops working group to pick a winner. W= e are just supposed to talk about operations. In that context, saying "yo= u probably ought to support DNS64" is meaningful advice, because a device t= hat doesn't support it isn't going to be able to do DNSSEC. This would ru= le out an entire transition technology, or else rule out DNSSEC. The situation is similar for other recommendations this document makes. C= an you maybe offer some motivation for your resistance to these requirement= s other than "this is too strong"? From sarikaya2012@gmail.com Fri Sep 21 07:54:47 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F166F21F872E for ; Fri, 21 Sep 2012 07:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.211 X-Spam-Level: X-Spam-Status: No, score=-3.211 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P4DQyUiCqWJF for ; Fri, 21 Sep 2012 07:54:46 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0D69821F872D for ; Fri, 21 Sep 2012 07:54:43 -0700 (PDT) Received: by iec9 with SMTP id 9so6448530iec.31 for ; Fri, 21 Sep 2012 07:54:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=ssX7CzjCHU/JRRX9X8Hbsq3/696FSD2IFLPYdkPRNDU=; b=mu6cIAp3TTgDyqGNUSytc3op1uSPfjP86A8csRC7vEYjzUS+2Rfjt5AtgyCqI659J6 WJBnfVg+x2+khQpTmj1qsEhSMsyFuFzX04GrYA+wzMwMSFaviflgxLHqWL6kSIQOJ62h 9WR+HkX+svOOuDboD1fCLSitEQu7zqa9W7ZliW1Cm2B+sd7vEzRl6HzqgtCFaywiWodM UxEnqSQInpjB9YaJ3lMeaDX0Cf/qAqDTPifiUK5RuK5z5ygAin+yX8AAT9LmoS9vBZIl BRrjJJA9pdBGPN9fKd6+tP19i3xJsqjJvVeKgYWJYcdZ25dgyGDo1WfdK3PwTogLM9bB Dnng== MIME-Version: 1.0 Received: by 10.42.18.193 with SMTP id y1mr4167325ica.0.1348239282551; Fri, 21 Sep 2012 07:54:42 -0700 (PDT) Received: by 10.231.55.70 with HTTP; Fri, 21 Sep 2012 07:54:42 -0700 (PDT) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E5B1233CA@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E5A40D46C@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E5B1233CA@PUEXCB1B.nanterre.francetelecom.fr> Date: Fri, 21 Sep 2012 09:54:42 -0500 Message-ID: From: Behcet Sarikaya To: mohamed.boucadair@orange.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 14:54:47 -0000 Hi Med, Please kindly see inline. Regards, Behcet On Fri, Sep 21, 2012 at 2:37 AM, wrote: > Dear Lorenzo, > > Please see inline. > > Cheers, > Med > > ________________________________ > De : Lorenzo Colitti [mailto:lorenzo@google.com] > Envoy=E9 : vendredi 21 septembre 2012 09:18 > > =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP > Cc : IPv6 Ops WG > Objet : Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update > > On Thu, Sep 20, 2012 at 4:00 PM, wrote: >> >> Review and comments are more than welcome. > > > A couple of comments, having skimmed the draft: > > 1. Did you consider a requirement to support RFC 4191? Many people are > asking for the ability to support more-specific routes, especially in the > MIF working group. > [Med] We didn't considered it because there are some assumptions to be ma= de: > e.g., do we expect all interfaces are connected to networks managed by th= e > same administrative entity? How to manage conflicts if distinct policies = are > sent? etc. > I support Lorenzo on this. I think that RFC 4191 should be considered. We have a draft on improving RFC 4191 which will make it more relevant to UEs: http://tools.ietf.org/html/draft-sarikaya-mif-6man-ra-route-01 > 2. REQ#28 says the device MUST (no less!) support ND proxy. I don't think > it's appropriate to say that an experimental RFC is a requirement. > Additionally, ND proxy is not fully baked, and it has issues with certain > topologies. We need a better solution than that. > [Med] RFC4389 is the best reference we can quote at this stage. Do you ha= ve > a pointer to an I-D where these issues are discussed? We can add a pointe= r > to that I-D. > > 3. REQ#32 says the device must also be an RFC-6204 compliant IPv6 CE rout= er. > Are there no conflicts? > [Med] We didn't done that analysis as we are considering also scenarios f= or > fixed-mobile convergence where a CPE can be connected to a fixed network = by > default and in case of failure switch to the 3GPP network or scenario. I am confused about this fmc scenario. When the device is connected to a fixed network, it does not need to be CE router because in the fixed network there is already a CE router. What you are considering is a complicated scenario where the device (UE) was CE router (because some IPv4-IPv6 transition technology required it) and then it connects to a fixed network. I am not sure if we should consider such scenarios. All I can say that in fmc, UE needs to be UE not a CE router. From mohamed.boucadair@orange.com Fri Sep 21 08:07:49 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89D8E21F8574 for ; Fri, 21 Sep 2012 08:07:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HELO_EQ_FR=0.35, SARE_SUB_OBFU_Q1=0.227, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pba5aHmGLqCj for ; Fri, 21 Sep 2012 08:07:49 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 6B26221F885B for ; Fri, 21 Sep 2012 08:07:34 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id C54EA22C635; Fri, 21 Sep 2012 17:07:33 +0200 (CEST) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 1CE2D4C078; Fri, 21 Sep 2012 17:07:33 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Fri, 21 Sep 2012 17:07:32 +0200 From: To: "sarikaya@ieee.org" Date: Fri, 21 Sep 2012 17:07:31 +0200 Thread-Topic: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update Thread-Index: Ac2YCQkGaaasQ/f6Tpq2XQmokCdJsgAADulQ Message-ID: <94C682931C08B048B7A8645303FDC9F36E5B1236EC@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E5A40D46C@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E5B1233CA@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: 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.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.19.115414 Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 15:07:49 -0000 Hi Behcet, Please see inline.=20 Cheers, Med=20 >-----Message d'origine----- >De : Behcet Sarikaya [mailto:sarikaya2012@gmail.com]=20 >Envoy=E9 : vendredi 21 septembre 2012 16:55 >=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >Cc : IPv6 Ops WG >Objet : Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update > >Hi Med, > >Please kindly see inline. > >Regards, > >Behcet > >On Fri, Sep 21, 2012 at 2:37 AM, wrote: >> Dear Lorenzo, >> >> Please see inline. >> >> Cheers, >> Med >> >> ________________________________ >> De : Lorenzo Colitti [mailto:lorenzo@google.com] >> Envoy=E9 : vendredi 21 septembre 2012 09:18 >> >> =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP >> Cc : IPv6 Ops WG >> Objet : Re: [v6ops]=20 >draft-binet-v6ops-cellular-host-reqs-rfc3316update >> >> On Thu, Sep 20, 2012 at 4:00 PM,=20 > wrote: >>> >>> Review and comments are more than welcome. >> >> >> A couple of comments, having skimmed the draft: >> >> 1. Did you consider a requirement to support RFC 4191? Many=20 >people are >> asking for the ability to support more-specific routes,=20 >especially in the >> MIF working group. >> [Med] We didn't considered it because there are some=20 >assumptions to be made: >> e.g., do we expect all interfaces are connected to networks=20 >managed by the >> same administrative entity? How to manage conflicts if=20 >distinct policies are >> sent? etc. >> > >I support Lorenzo on this. I think that RFC 4191 should be considered. >We have a draft on improving RFC 4191 which will make it more relevant >to UEs: > >http://tools.ietf.org/html/draft-sarikaya-mif-6man-ra-route-01 Med: I added a REQ for 4191 as indicated here: http://www.ietf.org/mail-arc= hive/web/v6ops/current/msg14349.html.=20 > >> 2. REQ#28 says the device MUST (no less!) support ND proxy.=20 >I don't think >> it's appropriate to say that an experimental RFC is a requirement. >> Additionally, ND proxy is not fully baked, and it has issues=20 >with certain >> topologies. We need a better solution than that. >> [Med] RFC4389 is the best reference we can quote at this=20 >stage. Do you have >> a pointer to an I-D where these issues are discussed? We can=20 >add a pointer >> to that I-D. >> >> 3. REQ#32 says the device must also be an RFC-6204 compliant=20 >IPv6 CE router. >> Are there no conflicts? >> [Med] We didn't done that analysis as we are considering=20 >also scenarios for >> fixed-mobile convergence where a CPE can be connected to a=20 >fixed network by >> default and in case of failure switch to the 3GPP network or=20 >scenario. > >I am confused about this fmc scenario. >When the device is connected to a fixed network, it does not need to >be CE router because in the fixed network there is already a CE >router. Med: I'm referring to a CPE which can be connected to cellular network on p= urpose. > >What you are considering is a complicated scenario where the device >(UE) was CE router (because some IPv4-IPv6 transition technology >required it) and then it connects to a fixed network. > >I am not sure if we should consider such scenarios. All I can say that >in fmc, UE needs to be UE not a CE router. Med: As you know, the notion of FMC is too vague. Applogies if I used that = term which induced confusion. The scenario I was describing is: a CPE can c= onnect to both fixed and wirelss network based on the some criteria (failur= e, offload via mobile or fixed, etc.).=20 From hesham@elevatemobile.com Fri Sep 21 18:01:41 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD3821F8484 for ; Fri, 21 Sep 2012 18:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[AWL=-0.239, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vE8IYc0gLCWq for ; Fri, 21 Sep 2012 18:01:40 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by ietfa.amsl.com (Postfix) with ESMTP id CE37421F8487 for ; Fri, 21 Sep 2012 18:01:37 -0700 (PDT) Received: from [60.242.128.199] (helo=[192.168.0.6]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1TFE6A-0000XC-5k; Sat, 22 Sep 2012 11:01:34 +1000 User-Agent: Microsoft-MacOutlook/14.2.3.120616 Date: Sat, 22 Sep 2012 11:01:26 +1000 From: Hesham Soliman To: Ted Lemon , IPv6 Ops WG Message-ID: Thread-Topic: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-User: hesham@elevatemobile.com Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Sep 2012 01:01:41 -0000 > >On Sep 21, 2012, at 9:19 AM, Hesham Soliman >wrote: >> And has there been on consensus on that mechanism? Because if there is >> consensus on one approach then lets remove a few more requirements. The >> current draft seems to select two approaches from what I remember. > >It would be inappropriate for the v6ops working group to pick a winner. >We are just supposed to talk about operations. In that context, saying >"you probably ought to support DNS64" is meaningful advice, because a >device that doesn't support it isn't going to be able to do DNSSEC. >This would rule out an entire transition technology, or else rule out >DNSSEC. > >The situation is similar for other recommendations this document makes. >Can you maybe offer some motivation for your resistance to these >requirements other than "this is too strong"? => My point is that we're effectively picking a winner. I didn't see any discussion before about which mechanisms would be recommended and suddenly we're saying CLAT is effectively a must implement in devices. The consequences if this are grave and that's why we need to have consensus on one or two approaches that would be recommended. If you think this WG can't pick a winner then let BEHAVE do it with IPv6 for example. The outcome of this draft should be a couple of mechanisms at most. So there needs to be a discussion about what those are with 3GPP as well. My argument doesn't boil down to "this is too strong" as you put it. It boils down to "where is the consensus on chosen mechanisms?" where is the discussion with other WGs and 3GPP? This needs to happen as it happened with similar RFCs in the past like 3314, 3316 or 3574. Hesham > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From hesham@elevatemobile.com Fri Sep 21 18:05:37 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6A2A21E80C1 for ; Fri, 21 Sep 2012 18:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.285 X-Spam-Level: X-Spam-Status: No, score=-2.285 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9x3jO+27l8gE for ; Fri, 21 Sep 2012 18:05:37 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by ietfa.amsl.com (Postfix) with ESMTP id ADB5921E8053 for ; Fri, 21 Sep 2012 18:05:34 -0700 (PDT) Received: from [60.242.128.199] (helo=[192.168.0.6]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1TFE9v-0008S2-Ho; Sat, 22 Sep 2012 11:05:31 +1000 User-Agent: Microsoft-MacOutlook/14.2.3.120616 Date: Sat, 22 Sep 2012 11:05:22 +1000 From: Hesham Soliman To: Message-ID: Thread-Topic: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E5B12365F@PUEXCB1B.nanterre.francetelecom.fr> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-User: hesham@elevatemobile.com Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Sep 2012 01:05:37 -0000 >>>> >>>> >>>>>There is no single document defining an IPv6 profile for cellular >>>>>hosts/devices. We wanted a single document listed both IETF and 3GPP >>>>>specification. >>>> >>>>=> There is, RFC 3316, which you're trying to update and it >>>>doesn't talk >>>>about link layers. >>> >>>Med: This is not a reason to not include it in the update. >> >> >>=> But you're not responding to the reasons I stated above. It's out of >>scope because it's not defined in IETF. > >Med: Should we care about frontiers between SDOs when the goal is to >ensure interoperability? IMHO, we should not. => Huh? Of course we should. This is _how_ you ensure interoperability by telling people where to read the relevant specs for their implementation! If you decide one algorithm here for PDP type selection and 3GPP decides on another, what then? So, best to avoid decisions for documents that you don't own. It's a straight forward thing. What motivation do you have for putting this in an IETF spec? >What we want to achieve with this document is to list a basic set of IPv6 >requirements for cellular hosts no matter if the requirement is defined >in IETF or 3GPP. > >My current take is: it is useful to have in one common place both IETF >and non-IETF REQs. I see you don't agree with this position. >This is still an individual submission. If the WG adopts this work, then >we will record whatever the WG wants us to do: If the consensus is to >drop those 3GPP-related requirements, then we will do it. => Sure, I'm assuming that you want it to be a WG draft and RFC later, hence this is part of the consensus to accept it as a WG draft. Hesham > From shemant@cisco.com Sat Sep 22 07:19:53 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C23321F8687 for ; Sat, 22 Sep 2012 07:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.285 X-Spam-Level: X-Spam-Status: No, score=-10.285 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7omMXaKA2fZ for ; Sat, 22 Sep 2012 07:19:49 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 098D221F8624 for ; Sat, 22 Sep 2012 07:19:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6876; q=dns/txt; s=iport; t=1348323589; x=1349533189; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=mICNuSG+tPTfKA4B65YWz/n9xJ35tq34U1v5MAdJKAo=; b=i67X77chDjuhnwJV29luij+I9aHzLeGuGMb2oQYkO3mTfnPZvzbPPpwT tZFXHdBCWHnj8Y5LPKei/xPTK6z/tYGVd7CCwoo2tGWgZFMBJuJvauacJ FXM0EgQkcUA24sX/XGJelVdFcgEqIDOXvaYo/wndBCR6h33HUqSLPALtO c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAHzIXVCtJV2c/2dsb2JhbABFgku7YIEIgiABAQEEEgEaRwUQAgEIEQQBAQsdBzIUCQgCBAENBQgBEgeHYwuYU590ixwahTBgA6QfgWmCZ4FjNA X-IronPort-AV: E=Sophos;i="4.80,467,1344211200"; d="scan'208,217";a="124261690" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 22 Sep 2012 14:19:48 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q8MEJmDE028034 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 22 Sep 2012 14:19:48 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.230]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0298.004; Sat, 22 Sep 2012 09:19:48 -0500 From: "Hemant Singh (shemant)" To: "mohamed.boucadair@orange.com" , "Lorenzo Colitti" Thread-Topic: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update Thread-Index: AQHNl8lIvgB9eKq4TDyGJOoGmWYBepeUvBUAgAGtoXA= Date: Sat, 22 Sep 2012 14:19:47 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B890901DD@xmb-rcd-x06.cisco.com> References: <94C682931C08B048B7A8645303FDC9F36E5A40D46C@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E5B1233CA@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E5B1233CA@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.251.15] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19202.004 x-tm-as-result: No--37.748600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_75B6FA9F576969419E42BECB86CB1B890901DDxmbrcdx06ciscocom_" MIME-Version: 1.0 Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Sep 2012 14:19:53 -0000 --_000_75B6FA9F576969419E42BECB86CB1B890901DDxmbrcdx06ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Med, In the xlat document review it has been discussed numerous times that ND Pr= oxy is an Experimental RFC and the Experimental tag is enough to disqualify= the RFC as a reference in an Information document. Other details have al= so been provided as to why the ND Proxy document is Experimental! See http://www.ietf.org/mail-archive/web/v6ops/current/msg13904.html Hemant From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of m= ohamed.boucadair@orange.com Sent: Friday, September 21, 2012 3:37 AM To: Lorenzo Colitti Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update 2. REQ#28 says the device MUST (no less!) support ND proxy. I don't think i= t's appropriate to say that an experimental RFC is a requirement. Additiona= lly, ND proxy is not fully baked, and it has issues with certain topologies= . We need a better solution than that. [Med] RFC4389 is the best reference we can quote at this stage. Do you have= a pointer to an I-D where these issues are discussed? We can add a pointer= to that I-D. --_000_75B6FA9F576969419E42BECB86CB1B890901DDxmbrcdx06ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Med,

     <= /p>

    In the xlat document revi= ew it has been discussed numerous times that ND Proxy is an Experimental RF= C and the Experimental tag is enough to disqualify the RFC as a reference in an Information document.   Other details have = also been provided as to why the ND Proxy document is Experimental!  S= ee

     <= /p>

    http://www.ietf.org/mail-archive/web/v6ops/curr= ent/msg13904.html

     <= /p>

    Hemant<= /p>

     <= /p>

    From: v6ops-bo= unces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com
    Sent: Friday, September 21, 2012 3:37 AM
    To: Lorenzo Colitti
    Cc: IPv6 Ops WG
    Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316upd= ate

     

     

    2. REQ#28 says the device MUST (no less!) support ND= proxy. I don't think it's appropriate to say that an experimental RFC is a= requirement. Additionally, ND proxy is not fully baked, and it has issues = with certain topologies. We need a better solution than that.
    [Med] RFC4389 is the best reference we can quote at this stage. D= o you have a pointer to an I-D where these issues are discussed? We can add= a pointer to that I-D.

     

    --_000_75B6FA9F576969419E42BECB86CB1B890901DDxmbrcdx06ciscocom_-- From kkumar@google.com Sun Sep 23 17:17:32 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C80121F8523 for ; Sun, 23 Sep 2012 17:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.505 X-Spam-Level: X-Spam-Status: No, score=-102.505 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WOxfxOzDg1dc for ; Sun, 23 Sep 2012 17:17:31 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id E4EB721F853B for ; Sun, 23 Sep 2012 17:17:29 -0700 (PDT) Received: by lbok13 with SMTP id k13so152078lbo.31 for ; Sun, 23 Sep 2012 17:17:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=BrDZNYz/33daX3ys14IsgyNDBzS8YphTcp4ABP4ydaQ=; b=ERgeoiqa+D282jwH0d2leFU7YDukE/ovQdqV5cS1FgTrvTeJLLoVuW+w8bnV9f0cr6 OD4V47BLZkJTyvxRug5AceNemkPvZjzP0XIzvhBjoI6w8r3FB7NiDidCV3N26TjYkaOw RIxfS5lRRqEXPigURPjvsdopf+GmpS0aWb2Y/ngYGQm+cbT056JQegtKQt8WgwF3BrbD QCYRfD1c0dqFQAjRjvOgI1QWCpHYrFjQ9bfhO/ngKZ9nFkdK2ZwW1u7s25mwEqtKbq+W aF8GZrap+3l0ahq3C/wZc4ZWjE53H1K6duGq8sGbV2GmDqTedIaxETJydH+2nJDZ/ewb pWQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=BrDZNYz/33daX3ys14IsgyNDBzS8YphTcp4ABP4ydaQ=; b=EF8i6JoJRqHPlbV+gCJSvEL1L3Juapm4qh2flUQestHiwFO4i1D4Yv2zoNiBorNTW/ NCAWNv8d0eXscaOocDZH8A/JprcOLVB7Tu+FZjSQsiMMsSUOYamaTS5gPG7DJLRm3ljq Vwhy4wj3iA/seaXLr75UR5ulA70wG1NJ/0eUuXm8JTeyVS5niOQp1N5z94eWn+uorsZm /o/P429ltc5qi7h+zHFs8wdtZYhEVZvIaCR5EGeXogoklnt16Eu14jUBM3mpTweLcSV7 9zai1qWU9s6VTkUm6nQs3bX/FknQ92tbrML3N0gqqKsQ9G3N8Msx+eQergLZ+mRke8hL ZWRA== Received: by 10.112.29.104 with SMTP id j8mr3722766lbh.127.1348445848604; Sun, 23 Sep 2012 17:17:28 -0700 (PDT) Received: by 10.112.29.104 with SMTP id j8mr3722757lbh.127.1348445848306; Sun, 23 Sep 2012 17:17:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.66.42 with HTTP; Sun, 23 Sep 2012 17:17:08 -0700 (PDT) In-Reply-To: <5055A457.9070408@forthnetgroup.gr> References: <201208091245.q79Cj1g08088@ftpeng-update.cisco.com> <5055A457.9070408@forthnetgroup.gr> From: KK Date: Sun, 23 Sep 2012 17:17:08 -0700 Message-ID: To: Tassos Chatzithomaoglou Content-Type: multipart/alternative; boundary=f46d04016a31c983d104ca6783ab X-System-Of-Record: true X-Gm-Message-State: ALoCoQksflIauxk0iVvv+5m1vyC/EDJvYAhUT62OpSkAkov7PYNpODpE3UCUe/X7SqFezaenmZCae5I7kPUrgDGytk6bzExTKYpG81H01749l1DGznBu+Rf/bRlObQ8tLTEscqT7hhtZ8D/4TnjCxC/uXzZjmTOErMlvvH1aEZB+BhfsqerA5ikyxkgv1c0xk9xPAWXHmRLJ Cc: v6ops , draft-ietf-v6ops-enterprise-incremental-ipv6@tools.ietf.org Subject: Re: [v6ops] comments about draft-ietf-v6ops-enterprise-incremental-ipv6-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 00:17:32 -0000 --f46d04016a31c983d104ca6783ab Content-Type: text/plain; charset=ISO-8859-7 Tassos, Thank you very much for your detailed feedback and apologies for the delayed response. There are many good points that you raise here. We will go through these individually and come back to you with further clarifications as we incorporate your suggested changes in the next rev. Regards, KK On Sun, Sep 16, 2012 at 3:05 AM, Tassos Chatzithomaoglou < achatz@forthnetgroup.gr> wrote: > > Generally i like the phased approach of this draft. > We have done similar phases in our own corporate network, although not all > sub-phases apply to us. > > Here are my general comments... > > 3.6 should be moved in the beginning. Project (not program) planning > should be the first thing to do. > > Security parts got me a little bit confused. There are things are are > repeated many times, although applicable at all of them. > Maybe put them under a general security section and just add differences > per phase. > Also it would be better if the security section was in the same position > at every phase (i.e. last or first). > > I didn't see any reference (or better warning) on operational costs vs > needs. Introduction includes 1-2 sentences, but i don't find them always > applicable. > This may be an easy job for some networks, but in same cases it will take > time and effort...without having a good reason. > I understand that this might push back the willing of an enterprise to > move to IPv6, but every case should be examined under a general umbrella. > An administrator might be considering IPv6 on his own, but this doesn't > necessarily apply to the whole enterprise. > > I got the impressions throughout the text that translation is preferred vs > tunneling, something i agree with in most cases, and especially in isp > environments. > But there are many enterprises, where the tunneling approach might be a > better/easier/cheaper solution. > > Lastly, until IPv6 is fully implemented into the enterprise, a > recommendation should be made about the expansion/maintenance of IPv4 > network/systems in such a way that the IPv6 deployment is taken into > account. > > > And some specific comments.... > > > The most common drivers are due > to the fact that when Internet service providers, including mobile > wireless carriers, run out of IPv4 addresses, they will provide > native IPv6 and non-native IPv4. > > I don't think most enterprises will fall under this type (non-native > IPv4) of connectivity. > ISPs are mostly facing issues with residential services in terms of > address availability. > > > The non-native IPv4 service may be > NAT64, NAT444, Dual-stack Lite, or other transition technology, but > whether tunneled or translated, the native traffic will be perform > better and more reliably than non-native. > > This assumption poses questions whether all those translation/tunneling > solutions by IETF are worth considering. > Maybe add a probability factor there. > > > A specific case of congruence is the IPv6 ULA [RFC4193 ] and IPv4 > private addressing [RFC1918 ] that do not provide any security by > 'magic'. In both case, the edge router must apply strict data plane > and routing policy to block those private addresses to leave and > enter the network. This filtering can be done by the enterprise or > by the ISP. > > IPv6 addresses can be spoofed as easily as IPv4 addresses and there > are packets with bogons IPv6 addresses (see [CYMRU ]). The anti-bogon > filtering must be done in the data and routing planes. It can be > done by the enterprise or by the ISP. > > > case = > cases > edge router => border routers > > Might want to rephrase "data" as "forwarding" or "routing" as "control" in > order to use common wording. > > Some recommendations are expressed like "can be done by the enterprise or > by the ISP". I think it should be noted that the enterprise should always > try to do these, regardless of the ISP. Ok, it might not be always easy for > the enterprise to do these (due to expertise, costs, etc), but i don't > think the enterprise should solely depend on the ISP doing these. > > An alternative is to try to prevent the use > of privacy extension addresses is to send the Router Advertisement > with the M-bit set (to force the use of DHCPv6 to get an address) and > with all advertized prefixes without the A-bit set (to prevent the > use of stateless auto-configuration); this technique requires that > all hosts support stateful DHCPv6. > > I think it's better to remove the M-bit reference and just refer DHCPv6. > If i remember right, there was a talk about the M/O bits being > controversial lately > > Another DoS > vulnerabilities are related to NDP cache exhaustion > ([I-D.gashinsky-v6ops-v6nd-problems ]) and they can be mitigated by > careful tuning of the NDP cache. In 2012, there are already several > vendors offering those features on their switches. > > RFC 6583 proposes various options for mitigation of NDP issues; i think a > general reference should be made instead. > > > The enterprise administrator will want to evaluate whether the > enterprise will request address space from its ISP (or Local Internet > Registry (LIR)), or whether to request address space from the local > Internet Registry (whether a Regional Internet Registry such as > AfriNIC, APNIC, ARIN, LACNIC, or RIPE-NCC, or a National Internet > Registry, operated in some countries). > > > Probably it should be rewritten as > > The enterprise administrator will want to evaluate whether the > enterprise will request address space from a LIR (Local Internet > Registry, such as an ISP), a RIR (Regional Internet Registry, such as > AfriNIC, APNIC, ARIN, LACNIC, or RIPE-NCC) or a NIR (National Internet Registry, operated in some countries). > > > > Each location, no matter how small, should get at least a /48. > > Does this apply to every enterprise? > Maybe add a reference to RFC6177 & RFC 5375? > > > All user access networks MUST be a /64. Point-to-point links without > MAC addresses (this is where Neighbor Discovery Protocol does not > run) SHOULD be a /127 (see also [RFC6164 ]). > > > Why a reference on mac-addresses? Can't ethernet p2p links use /127? > > > > Also, for any part of the network where > DNS (or reverse DNS) zones may be delegated, it is important to > delegate addresses on nibble boundaries (this is on a multiple of 4 > bits), to ensure propose name delegation. > > > propose => proposed? > Maybe want to explain this a little bit more? > > ** Add some comment about setting MTU to 1280 to avoid tunnel pMTUd > black holes? ** > > > Personally, i don't like the idea of setting the MTU to the minimum. It's > better to describe the issues and the importance of ICMP/pMTUd and leave > the MTU minimization as a last resort. > > The security policies must be congruent for IPv4 > and IPv6 (else the attacker will use the less protected protocol > stack) except that ICMPv6 messages must be allowed through and to the > filtering device (see [RFC4890 ]): > > > except that ICMPv6 messages => except that some ICMPv6 messages > > The peering router must also implement anti-spoofing technique based > on [RFC2827 ]. > > > What's a peering router in the enterprise? There is only a single > reference of it. Are you referring to border routers? > > > This includes the use of IP flow export > [RFC5102 ] to detect abnormal traffic pattern (such as port scanning, > SYN-flooding) > > > IP flow export => IP Flow Information eXport (IPFIX) > > > > While > technology and process transformations are taking place is it > critical that people training takes place as well. > > > is it critical => it is critical > > malevolent person has now two attack vectors: IPv4 and IPv6. This > simply means that all routers and hosts operating in a dual-stack > environment with both protocol families enabled (even if by default) > must have a congruent security policy for both protocol version. > > > version => versions > > > There may be a registration > fee for requesting provider-independent (PI) space from and NIR/RIR, > > and => a > > In the case of PI, the organization will need to support BGP based > connectivity for the most part since the address space is assigned > direction from the Regional Registry to the local network. > > direction => directly > > Native IPv6 > connectivity is preferred since it provides the most rebuts form of > connectivity. > > > rebuts => robust ? > > > -- > Tassos > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --f46d04016a31c983d104ca6783ab Content-Type: text/html; charset=ISO-8859-7 Content-Transfer-Encoding: quoted-printable Tassos,

    Thank you very much for your detailed feedback a= nd apologies for the delayed response.

    There are m= any good points that you raise here. We will go through these individually = and come back to you with further clarifications as we incorporate your sug= gested changes in the next rev. =A0

    Regards,
    KK



    On Sun, Sep 16, 2012 at 3:= 05 AM, Tassos Chatzithomaoglou <achatz@forthnetgroup.gr> wrote:
    =20 =20 =20

    Generally i like the phased approach of this draft.
    We have done similar phases in our own corporate network, although not all sub-phases apply to us.

    Here are my general comments...

    3.6 should be moved in the beginning. Project (not program) planning should be the first thing to do.

    Security parts got me a little bit confused. There are things are are repeated many times, although applicable at all of them.
    Maybe put them under a general security section and just add differences per phase.
    Also it would be better if the security section was in the same position at every phase (i.e. last or first).

    I didn't see any reference (or better warning) on operational costs vs needs. Introduction includes 1-2 sentences, but i don't find them always applicable.
    This may be an easy job for some networks, but in same cases it will take time and effort...without having a good reason.
    I understand that this might push back the willing of an enterprise to move to IPv6, but every case should be examined under a general umbrella.
    An administrator might be considering IPv6 on his own, but this doesn't necessarily apply to the whole enterprise.

    I got the impressions throughout the text that translation is preferred vs tunneling, something i agree with in most cases, and especially in isp environments.
    But there are many enterprises, where the tunneling approach might be a better/easier/cheaper solution.

    Lastly, until IPv6 is fully implemented into the enterprise, a recommendation should be made about the expansion/maintenance of IPv4 network/systems in such a way that the IPv6 deployment is taken into account.


    And some specific comments....


     The most common drivers are due
   to the fact that when Internet service providers, including mobile
   wireless carriers, run out of IPv4 addresses, they will provide
   native IPv6 and non-native IPv4.
    I don't think most enterprises will fall under this type (non-native IPv4) of connectivity.
    ISPs are mostly facing issues with residential services in terms of address availability.


     The non-native IPv4 service may be
   NAT64, NAT444, Dual-stack Lite, or other transition technology, but
   whether tunneled or translated, the native traffic will be perform
   better and more reliably than non-native.
    This assumption poses questions whether all those translation/tunneling solutions by IETF are worth considering.
    Maybe add a probability factor there.


      A specific case of congruence is the IPv6 ULA [RFC4193] and IPv4
   private addressing [RFC1918] that do not provide any security by
   'magic'.  In both case, the edge router must apply strict data p=
lane
   and routing policy to block those private addresses to leave and
   enter the network.  This filtering can be done by the enterprise or
   by the ISP.
    IPv6 addresses can be spoofed as easily as IPv4 addresses and =
there
   are packets with bogons IPv6 addresses (see [CYMRU]).  The an=
ti-bogon
   filtering must be done in the data and routing planes.  It can be
   done by the enterprise or by the ISP.

    case =3D > cases
    edge router =3D> border routers

    Might want to rephrase "data" as "forwarding" or = "routing" as "control" in order to use common wording.

    Some recommendations are expressed like "can be done by the enterprise or by the ISP". I think it should be noted that the enterprise should always try to do these, regardless of the ISP. Ok, it might not be always easy for the enterprise to do these (due to expertise, costs, etc), but i don't think the enterprise should solely depend on the ISP doing these.

    An alternative is to try to prevent the use
   of privacy extension addresses is to send the Router Advertisement
   with the M-bit set (to force the use of DHCPv6 to get an address) and
   with all advertized prefixes without the A-bit set (to prevent the
   use of stateless auto-configuration); this technique requires that
   all hosts support stateful DHCPv6.
    I think it's better to remove the M-bit reference and just refer DHCPv6.
    If i remember right, there was a talk about the M/O bits being controversial lately

    Another DoS
   vulnerabilities are related to NDP cache exhaustion
   ([I-=
D.gashinsky-v6ops-v6nd-problems]) and they can be mitigated by
   careful tuning of the NDP cache.  In 2012, there are already several
   vendors offering those features on their switches.
    RFC 6583 proposes various options for mitigation of NDP issues; i think a general reference should be made instead.


    The enterprise administrator will want to evaluate whether the
   enterprise will request address space from its ISP (or Local Internet
   Registry (LIR)), or whether to request address space from the local
   Internet Registry (whether a Regional Internet Registry such as
   AfriNIC, APNIC, ARIN, LACNIC, or RIPE-NCC, or a National Internet
   Registry, operated in some countries).

    Probably it should be rewritten as

    The enterprise administrator will want to evaluate whether the
   enterprise will request address space from a LIR (Local Internet
   Registry, such as an ISP), a RIR (Regional Internet Registry, such as
   AfriNIC, APNIC, ARIN, LACNIC, or RIPE-NCC) or a NIR (National Internet R=
egistry, operated in some countries).



    Each location, no matter how small, should get at least a /48.=
    Does this apply to every enterprise?
    Maybe add a reference to RFC6177 & RFC 5375?


       All user access networks MUST be a /64.  Point-to-point lin=
ks without
   MAC addresses (this is where Neighbor Discovery Protocol does not
   run) SHOULD be a /127 (see also [RFC6164]).

    Why a reference on mac-addresses? Can't ethernet p2p links use /127?



    Also, for any part of the network where
   DNS (or reverse DNS) zones may be delegated, it is important to
   delegate addresses on nibble boundaries (this is on a multiple of 4
   bits), to ensure propose name delegation.

    propose =3D> proposed?
    Maybe want to explain this a little bit more?

       ** Add some comment about setting MTU to 1280 to avoid tunn=
el pMTUd
   black holes? **

    Personally, i don't like the idea of setting the MTU to the minimum. It's better to describe the issues and the importance of ICMP/pMTUd and leave the MTU minimization as a last resort.

     The security policies must be congruent for IPv4
   and IPv6 (else the attacker will use the less protected protocol
   stack) except that ICMPv6 messages must be allowed through and to the
   filtering device (see [RFC4890]):

    except that ICMPv6 messages =3D> except that some ICMPv6 messages 

    The peering router must also implement anti-spoofing technique=
 based
   on [RFC2827].

    What's a peering router in the enterprise? There is only a single reference of it. Are you referring to border routers?


    This includes the use of IP flow export
   [RFC5102] to detect abnormal traffic pattern (such as port scanning,
   SYN-flooding)

    IP flow export =3D> IP Flow Information eXport (IPFIX)



    While
   technology and process transformations are taking place is it
   critical that people training takes place as well.

    is it critical =3D> it is critical

       malevolent person has now two attack vectors: IPv4 and IPv6=
.  This
   simply means that all routers and hosts operating in a dual-stack
   environment with both protocol families enabled (even if by default)
   must have a congruent security policy for both protocol version.

    version =3D> versions


     There may be a registration
   fee for requesting provider-independent (PI) space from and NIR/RIR,
    and =3D> a

    In the case of PI, the organization will need to support BGP b=
ased
   connectivity for the most part since the address space is assigned
   direction from the Regional Registry to the local network.
    direction =3D> directly

    Native IPv6
   connectivity is preferred since it provides the most rebuts form of
   connectivity.

    rebuts =3D> robust ?


    --
Tassos


    _______________________________________________
    v6ops mailing list
    v6ops@ietf.org
    h= ttps://www.ietf.org/mailman/listinfo/v6ops


    --f46d04016a31c983d104ca6783ab-- From kkumar@google.com Sun Sep 23 18:18:34 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C12E21F845E for ; Sun, 23 Sep 2012 18:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.489 X-Spam-Level: X-Spam-Status: No, score=-102.489 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pGapgf7r6Q42 for ; Sun, 23 Sep 2012 18:18:33 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id B05E821F8459 for ; Sun, 23 Sep 2012 18:18:32 -0700 (PDT) Received: by lbok13 with SMTP id k13so189752lbo.31 for ; Sun, 23 Sep 2012 18:18:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=oAXZFSCkfuleH1AKiyxtRTC08viAWBnqtn0725CSZbs=; b=RjuSBqxUuw6DIfwcfZssuDr0yzRd4CNwNkeKnXe6D0Y6bRb2f/ds6027zc7LsX5sd/ cuoUP1+3nxRaUlUEYNIl8PHdh5U4qnGqpltW0oGF8TDEnKr/MB7MNEWoCwMCKU0iuJvU O7FX8rFevTkcSpY49x9OBobJNu6cHLClMK8QeeRAPi+uxBlQffXO+xwys2FbaECNljBK OD+QT0z92Nfyn768Xdj1J9fr3LMa7mr3yJNAzW2rIOgFcpmv7Si1Cj/1JC+igG4MUj5n qNVPXvu0u9r9tg5vmudY1r9iYAWWyOVS91wVLwtGg+XspfV2Dw0zqheux2sTQZ8nG8/M 3kpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=oAXZFSCkfuleH1AKiyxtRTC08viAWBnqtn0725CSZbs=; b=gE7q7dIj+J8o1i1JgfjteKCwpEXBKsPp0uFjt+2oZBPg/un+da1WSn3BCQ2j2wnTTf qeJ6nqm4I7Lglt6wiuE6K1wPSNgyZxND8vlboCv34t3E0uxsn6ArfMatwJh6zZdjoJmW TlHeipgIZmW4Zr8aEIAOPe4Ck9DmXTOo1yh6MtBHIQ/+p9xuwslnpoaAeugrCHPdYIIg zLnxRxidzGWaWG7jRnlAq5LjDy8CG5xXf2qifsztJqET4F2WaSTDYmdaWL2UkghF6bJ9 J9i+MWFJYW4Nszj8VX6S46FoKcD9b+uUWUldCaYzQo/GwQYMPlJaMBjgqhgQbA41hUwm lvXw== Received: by 10.112.101.194 with SMTP id fi2mr3779749lbb.104.1348449511545; Sun, 23 Sep 2012 18:18:31 -0700 (PDT) Received: by 10.112.101.194 with SMTP id fi2mr3779735lbb.104.1348449511307; Sun, 23 Sep 2012 18:18:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.66.42 with HTTP; Sun, 23 Sep 2012 18:18:10 -0700 (PDT) In-Reply-To: References: <20120915180503.23774.22275.idtracker@ietfa.amsl.com> From: KK Date: Sun, 23 Sep 2012 18:18:10 -0700 Message-ID: To: "Templin, Fred L" Content-Type: multipart/alternative; boundary=f46d040169b51e7b6d04ca685e63 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkn/gb8myow6Sm8nGGU4tWgCjfJbk5Vq4OWfo4KrP04VAY5nXUYimN+8WAlycLxXZZhq6hbRihPrikCmxkToNSOK8Bo2f8k1+PqaDxiVR6R6lGsy7z34nHDp7cFgAI/H5v1eUBpf5YizzxC3IDk2rHKwkbnXCgbg0rszafJjNsALQ5sqDj64G+34s4Up0/aJOqgDQb0 Cc: "lee.howard@twcable.com" , "v6ops@ietf.org" , "victor.kuarsingh@rci.rogers.com" Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-enterprise-incremental-ipv6-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 01:18:34 -0000 --f46d040169b51e7b6d04ca685e63 Content-Type: text/plain; charset=ISO-8859-1 Fred, Thank you for your detailed comments and apologies for a delayed response. This is very useful feedback! We will work on incorporating these changes into the next revision. Regards, KK On Thu, Sep 20, 2012 at 7:36 AM, Templin, Fred L wrote: > Here are my comments on this document: > > Fred > fred.l.templin@boeing.com > > > 1) Section 1, s/will be perform better/may perform better > > 2) Section 1, "It is thus in the enterprise's interests to > deploy native IPv6 itself." - This statement is not necessarily > true for all enterprises, and the fact that the ISP may provide > native IPv6 services has no bearing on whether the enterprise > should also provide native IPv6 services. Suggest deleting this > sentence. > > 3)Section 1.3, "Reasons for a Phased Approach", in this > section there should be a statement to the effect that, > although some of the RFC1687 reasons for not deploying > IPv6 are still valid, many of the reasons given in this > section are new since the publication of RFC1687 and do > give good reasons for transition. > > 4) Section 1.3, the statement: "it can be expected that > new applications will only support IPv6." Please change > to: "it can be expected that some new applications will > only support IPv6." ^^^^ > > 5) Section 1.3, "which means that with IPv6 merging networks > (after two organizations merged) is much easier and faster." > This statement needs to be backed up with a citation - perhaps > something from the RENUM working group, or from "Renumbering > Without a Flag Day". > > 6) Section 3.1.2, "...communicates of the network" - should it > be: "...communicates on the network" ? > > 7) Section 3.1.2, second paragraph, somewhere this paragraph > should cite RFC6724 - "Default Address Selection for Internet > Protocol Version 6 (IPv6)". > > 8) Section 3.3, final sentence: "Either way IPv6 introduces > the opportunity to rationalize the environment and to architect > it for growth." - is not true, because IPv6 is an inanimate > object and cannot "introduce" anything. Maybe you are meaning > to say (sic) since the network administrators are considering > an introduction of IPv6 they might also be inclined to review > their existing architecture for its growth potential while they > are at it? Plus, this statement and the previous paragraph are > out of place in a section that is supposed to talk about routing. > > 9) Section 3.5, the sentence: "The enterprise administrator will > want to evaluate whether the enterprise will request address space > from its ISP (or Local Internet Registry (LIR)), or whether to > request address space from the local Internet Registry..." - the > term "local Internet registry" is being used redundantly here in > a way that may confuse the reader. > > 10) Section 3.5, "Each location, no matter how small, should get > at least a /48." - there has been quite a bit of discussion about > sites being able to request a smaller size such as /56. Also, the > size of the minimum site prefix is outside the scope of this > document. Perhaps change this to something like: "Each location, > no matter how small, should get the largest practical IPv6 prefix > delegation.". > > 11) Section 4.1, "may need to communist with the outside world", > "communist" is probably not the correct word here. > > 12) Section 4.1, "Add some comment about setting MTU to 1280 to > avoid tunnel pMTUd black holes?" - This is out of scope for this > document, and goes against recommendations in some of the tunneling > documents. Plus, 1280 may not be any safer than something larger > like 1480 in many cases. > > 13) Section 5, the phrase "Dual Stack when you can, tunnel when > you must" may be inappropriate for some or perhaps even many > enterprise network use cases. The subsequent sentence also > contains subjective advice. Suggest rewording the first two > sentences of this paragraph to something like: "An important > design paradigm to consider during this phase is to determine > where Dual Stack and/or tunnel should be used". Dual stacking > when possible allows you to build a native IPv6 network > capability that should be preferred over tunnels." > > 14) Section 5.1, "An important design choice to be made is what > IGP to use inside the network." - Doesn't this text belong back > in Section 3.3 ("Routing")? Or if not, should Section 3.3 be > deleted and its text moved here? > > 15) Section 5.1, final sentence, "In the long term, DHCPv6 makes > most sense for use in a managed environment." would almost > certainly raise prolonged and undesirable debate. The previous > sentences articulated the SLAAC and DHCPv6 considerations very > well, so it would be better to just leave this sentence out. > > 16) Section 5.2, "It is important to note that most operating > systems will, by default, prefer to use native IPv6 over IPv4 > when enabled." - this may not be true for OSes that implement > RFC6724 default address selections. In that case, IPv6 and/or > IPv4 would be preferred based on the address selection > algorithm instead of based on some static configuration. > > 17) Section 5.2, "Furthermore, some OSes may have tunneling > mechanisms turned on by default...". Change to: Furthermore, > some OSes may have unmanaged tunneling mechanisms turned on > by default..." ^^^^^^^^^ > > 18) Sections 6.2 and 7 seem to be preliminary in nature, and > seem to be in need of substantial editing and/or new text added. > It is too early to comment on these sections. > > > > -----Original Message----- > > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of > > internet-drafts@ietf.org > > Sent: Saturday, September 15, 2012 11:05 AM > > To: i-d-announce@ietf.org > > Cc: v6ops@ietf.org > > Subject: [v6ops] I-D Action: > draft-ietf-v6ops-enterprise-incremental-ipv6- > > 01.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the IPv6 Operations Working Group of the > > IETF. > > > > Title : Enterprise IPv6 Deployment Guidelines > > Author(s) : Kiran K. Chittimaneni > > Tim Chown > > Lee Howard > > Victor Kuarsingh > > Yanick Pouffary > > Eric Vyncke > > Filename : draft-ietf-v6ops-enterprise-incremental-ipv6- > > 01.txt > > Pages : 28 > > Date : 2012-09-15 > > > > Abstract: > > Enterprise network administrators worldwide are in various stages of > > preparing for or deploying IPv6 into their networks. The > > administrators face different challenges than operators of Internet > > access providers, and have reasons for different priorities. The > > overall problem for many administrators will be to offer Internet- > > facing services over IPv6, while continuing to support IPv4, and > > while introducing IPv6 access within the enterprise IT network. The > > overall transition will take most networks from an IPv4-only > > environment to a dual stack network environment and potentially an > > IPv6-only operating mode. This document helps provide a framework > > for enterprise network architects or administrators who may be faced > > with many of these challenges as they consider their IPv6 support > > strategies. > > > > > > The IETF datatracker status page for this draft is: > > > https://datatracker.ietf.org/doc/draft-ietf-v6ops-enterprise-incremental- > > ipv6 > > > > There's also a htmlized version available at: > > > http://tools.ietf.org/html/draft-ietf-v6ops-enterprise-incremental-ipv6-01 > > > > A diff from the previous version is available at: > > > http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-enterprise-incremental- > > ipv6-01 > > > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > --f46d040169b51e7b6d04ca685e63 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Fred,

    Thank you for your detailed comments and apologies= for a delayed response.

    This is very useful feedback! We will wor= k on incorporating these changes into the next revision.=A0

    Regards,
    KK

    <= /div>



    On Thu, Sep 2= 0, 2012 at 7:36 AM, Templin, Fred L <Fred.L.Templin@boeing.com= > wrote:
    Here are my comments on this document:

    Fred
    fred.l.templin@boeing.com<= br>

    1) Section 1, s/will be perform better/may perform better

    2) Section 1, "It is thus in the enterprise's interests to
    deploy native IPv6 itself." - This statement is not necessarily
    true for all enterprises, and the fact that the ISP may provide
    native IPv6 services has no bearing on whether the enterprise
    should also provide native IPv6 services. Suggest deleting this
    sentence.

    3)Section 1.3, "Reasons for a Phased Approach", in this
    section there should be a statement to the effect that,
    although some of the RFC1687 reasons for not deploying
    IPv6 are still valid, many of the reasons given in this
    section are new since the publication of RFC1687 and do
    give good reasons for transition.

    4) Section 1.3, the statement: "it can be expected that
    new applications will only support IPv6." Please change
    to: "it can be expected that some new applications will
    only support IPv6." =A0 =A0 =A0 =A0 =A0^^^^

    5) Section 1.3, "which means that with IPv6 merging networks
    (after two organizations merged) is much easier and faster."
    This statement needs to be backed up with a citation - perhaps
    something from the RENUM working group, or from "Renumbering
    Without a Flag Day".

    6) Section 3.1.2, "...communicates of the network" - should it be: "...communicates on the network" ?

    7) Section 3.1.2, second paragraph, somewhere this paragraph
    should cite RFC6724 - "Default Address Selection for Internet
    Protocol Version 6 (IPv6)".

    8) Section 3.3, final sentence: "Either way IPv6 introduces
    the opportunity to rationalize the environment and to architect
    it for growth." - is not true, because IPv6 is an inanimate
    object and cannot "introduce" anything. Maybe you are meaning
    to say (sic) since the network administrators are considering
    an introduction of IPv6 they might also be inclined to review
    their existing architecture for its growth potential while they
    are at it? Plus, this statement and the previous paragraph are
    out of place in a section that is supposed to talk about routing.

    9) Section 3.5, the sentence: "The enterprise administrator will
    want to evaluate whether the enterprise will request address space
    from its ISP (or Local Internet Registry (LIR)), or whether to
    request address space from the local Internet Registry..." - the
    term "local Internet registry" is being used redundantly here in<= br> a way that may confuse the reader.

    10) Section 3.5, "Each location, no matter how small, should get
    at least a /48." - there has been quite a bit of discussion about
    sites being able to request a smaller size such as /56. Also, the
    size of the minimum site prefix is outside the scope of this
    document. Perhaps change this to something like: "Each location,
    no matter how small, should get the largest practical IPv6 prefix
    delegation.".

    11) Section 4.1, "may need to communist with the outside world",<= br> "communist" is probably not the correct word here.

    12) Section 4.1, "Add some comment about setting MTU to 1280 to
    avoid tunnel pMTUd black holes?" - This is out of scope for this
    document, and goes against recommendations in some of the tunneling
    documents. Plus, 1280 may not be any safer than something larger
    like 1480 in many cases.

    13) Section 5, the phrase "Dual Stack when you can, tunnel when
    you must" may be inappropriate for some or perhaps even many
    enterprise network use cases. The subsequent sentence also
    contains subjective advice. Suggest rewording the first two
    sentences of this paragraph to something like: "An important
    design paradigm to consider during this phase is to determine
    where Dual Stack and/or tunnel should be used". =A0Dual stacking
    when possible allows you to build a native IPv6 network
    capability that should be preferred over tunnels."

    14) Section 5.1, "An important design choice to be made is what
    IGP to use inside the network." - Doesn't this text belong back in Section 3.3 ("Routing")? Or if not, should Section 3.3 be
    deleted and its text moved here?

    15) Section 5.1, final sentence, "In the long term, DHCPv6 makes
    most sense for use in a managed environment." would almost
    certainly raise prolonged and undesirable debate. The previous
    sentences articulated the SLAAC and DHCPv6 considerations very
    well, so it would be better to just leave this sentence out.

    16) Section 5.2, "It is important to note that most operating
    systems will, by default, prefer to use native IPv6 over IPv4
    when enabled." - this may not be true for OSes that implement
    RFC6724 default address selections. In that case, IPv6 and/or
    IPv4 would be preferred based on the address selection
    algorithm instead of based on some static configuration.

    17) Section 5.2, "Furthermore, some OSes may have tunneling
    mechanisms turned on by default...". Change to: Furthermore,
    some OSes may have unmanaged tunneling mechanisms turned on
    by default..." =A0 =A0 ^^^^^^^^^

    18) Sections 6.2 and 7 seem to be preliminary in nature, and
    seem to be in need of substantial editing and/or new text added.
    It is too early to comment on these sections.


    > -----Original Message-----
    > From: v6ops-bounces@ietf.org= [mailto:v6ops-bounces@ietf.o= rg] On Behalf Of
    > internet-drafts@ietf.org
    > Sent: Saturday, September 15, 2012 11:05 AM
    > To:     i-d-announce@ietf.org=
    > Cc: v6ops@ietf.org
    > Subject: [v6ops] I-D Action: draft-ietf-v6ops-enterprise-incremental-i= pv6-
    > 01.txt
    >
    >
    > A New Internet-Draft is available from the on-line Internet-Drafts
    > directories.
    > =A0This draft is a work item of the IPv6 Operations Working Group of t= he
    > IETF.
    >
    > =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Enterprise IPv6 Deployment Gui= delines
    > =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Kiran K. Chittimaneni
    > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Tim Chown
    > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Lee Howard
    > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Victor Kuarsingh > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Yanick Pouffary > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Eric Vyncke
    > =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-v6ops-enterprise-incr= emental-ipv6-
    > 01.txt
    > =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 28
    > =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-09-15
    >
    > Abstract:
    > =A0 =A0Enterprise network administrators worldwide are in various stag= es of
    > =A0 =A0preparing for or deploying IPv6 into their networks. =A0The
    > =A0 =A0administrators face different challenges than operators of Inte= rnet
    > =A0 =A0access providers, and have reasons for different priorities. = =A0The
    > =A0 =A0overall problem for many administrators will be to offer Intern= et-
    > =A0 =A0facing services over IPv6, while continuing to support IPv4, an= d
    > =A0 =A0while introducing IPv6 access within the enterprise IT network.= =A0The
    > =A0 =A0overall transition will take most networks from an IPv4-only > =A0 =A0environment to a dual stack network environment and potentially= an
    > =A0 =A0IPv6-only operating mode. =A0This document helps provide a fram= ework
    > =A0 =A0for enterprise network architects or administrators who may be = faced
    > =A0 =A0with many of these challenges as they consider their IPv6 suppo= rt
    > =A0 =A0strategies.
    >
    >
    > The IETF datatracker status page for this draft is:
    > https://datatracker.ietf.org/doc/draft-ie= tf-v6ops-enterprise-incremental-
    > ipv6
    >
    > There's also a htmlized version available at:
    > http://tools.ietf.org/html/draft-ietf-v6= ops-enterprise-incremental-ipv6-01
    >
    > A diff from the previous version is available at:
    > http://www.ietf.org/rfcdiff?url2=3Ddraf= t-ietf-v6ops-enterprise-incremental-
    > ipv6-01
    >
    >
    > Internet-Drafts are also available by anonymous FTP at:
    > ftp:= //ftp.ietf.org/internet-drafts/
    >
    > _______________________________________________
    > v6ops mailing list
    > v6ops@ietf.org
    > https://www.ietf.org/mailman/listinfo/v6ops

    --f46d040169b51e7b6d04ca685e63-- From joelja@bogus.com Sun Sep 23 20:09:15 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D6CE21F845F for ; Sun, 23 Sep 2012 20:09:15 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rhTl5CurbZt2 for ; Sun, 23 Sep 2012 20:09:15 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0402A21F845E for ; Sun, 23 Sep 2012 20:09:14 -0700 (PDT) Received: from joels-MacBook-Air.local (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q8O39CXQ019614 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Mon, 24 Sep 2012 03:09:12 GMT (envelope-from joelja@bogus.com) Message-ID: <505FCED7.4030106@bogus.com> Date: Sun, 23 Sep 2012 20:09:11 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20120828 Thunderbird/16.0 MIME-Version: 1.0 To: IPv6 Ops WG , V6ops Chairs Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Mon, 24 Sep 2012 03:09:14 +0000 (UTC) Subject: [v6ops] Proposed Agenda 9/29/2012 13:30 16:30 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 03:09:15 -0000 Other items or proposals still accepted. - Agenda * Old Business * Draft status * 6204bis * Current business * post-last-call update to 464xlat * draft-ietf-v6ops-enterprise-incremental-ipv6 * draft-gashinsky-6man-v6nd-enhance-01 * draft-binet-v6ops-cellular-host-reqs-rfc3316update From mohamed.boucadair@orange.com Sun Sep 23 22:58:01 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C15F221F8555 for ; Sun, 23 Sep 2012 22:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.68 X-Spam-Level: X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[AWL=-0.259, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, SARE_SUB_OBFU_Q1=0.227, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gAbYkT8fVG5k for ; Sun, 23 Sep 2012 22:58:01 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id AE80821F8557 for ; Sun, 23 Sep 2012 22:57:59 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 7FCB52DC235; Mon, 24 Sep 2012 07:57:58 +0200 (CEST) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 6462835C04E; Mon, 24 Sep 2012 07:57:58 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Mon, 24 Sep 2012 07:57:58 +0200 From: To: Hesham Soliman , Ted Lemon , IPv6 Ops WG Date: Mon, 24 Sep 2012 07:57:57 +0200 Thread-Topic: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update Thread-Index: Ac2YXdrU1PY8f7b1TUm2tt4pn8YUYQBumN1g Message-ID: <94C682931C08B048B7A8645303FDC9F36E5B1237E1@PUEXCB1B.nanterre.francetelecom.fr> References: In-Reply-To: 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.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.9.24.43322 Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 05:58:01 -0000 Dear Hesham, Which alternative(s) to CLAT you are referring to?=20 Thanks.=20 Cheers, Med=20 >-----Message d'origine----- >De : v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] De=20 >la part de Hesham Soliman >Envoy=E9 : samedi 22 septembre 2012 03:01 >=C0 : Ted Lemon; IPv6 Ops WG >Objet : Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update > >> >>On Sep 21, 2012, at 9:19 AM, Hesham Soliman >>wrote: >>> And has there been on consensus on that mechanism? Because=20 >if there is >>> consensus on one approach then lets remove a few more=20 >requirements. The >>> current draft seems to select two approaches from what I remember. >> >>It would be inappropriate for the v6ops working group to pick=20 >a winner. >>We are just supposed to talk about operations. In that=20 >context, saying >>"you probably ought to support DNS64" is meaningful advice, because a >>device that doesn't support it isn't going to be able to do DNSSEC. >>This would rule out an entire transition technology, or else rule out >>DNSSEC. >> >>The situation is similar for other recommendations this=20 >document makes. >>Can you maybe offer some motivation for your resistance to these >>requirements other than "this is too strong"? > >=3D> My point is that we're effectively picking a winner. I=20 >didn't see any >discussion before about which mechanisms would be recommended=20 >and suddenly >we're saying CLAT is effectively a must implement in devices. The >consequences if this are grave and that's why we need to have=20 >consensus on >one or two approaches that would be recommended. If you think this WG >can't pick a winner then let BEHAVE do it with IPv6 for example. The >outcome of this draft should be a couple of mechanisms at=20 >most. So there >needs to be a discussion about what those are with 3GPP as well. > >My argument doesn't boil down to "this is too strong" as you put it. It >boils down to "where is the consensus on chosen mechanisms?"=20 >where is the >discussion with other WGs and 3GPP? This needs to happen as it happened >with similar RFCs in the past like 3314, 3316 or 3574. > >Hesham > >> >>_______________________________________________ >>v6ops mailing list >>v6ops@ietf.org >>https://www.ietf.org/mailman/listinfo/v6ops > > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops >= From hesham@elevatemobile.com Sun Sep 23 23:09:17 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 727F421F856C for ; Sun, 23 Sep 2012 23:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.136 X-Spam-Level: X-Spam-Status: No, score=0.136 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_ILLEGAL_IP=1.908, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bHmZGPdO8BUp for ; Sun, 23 Sep 2012 23:09:17 -0700 (PDT) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by ietfa.amsl.com (Postfix) with ESMTP id C7F9B21F841A for ; Sun, 23 Sep 2012 23:09:15 -0700 (PDT) Received: from [1.158.56.102] (helo=[172.20.10.2]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1TG1qu-000495-AY; Mon, 24 Sep 2012 16:09:09 +1000 User-Agent: Microsoft-MacOutlook/14.2.3.120616 Date: Mon, 24 Sep 2012 16:09:00 +1000 From: Hesham Soliman To: , Ted Lemon , IPv6 Ops WG Message-ID: Thread-Topic: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E5B1237E1@PUEXCB1B.nanterre.francetelecom.fr> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Authenticated-User: hesham@elevatemobile.com Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 06:09:17 -0000 >Dear Hesham, > >Which alternative(s) to CLAT you are referring to? =3D> I don't think I suggested alternatives to CLAT specifically, can't see that in the email quoted anyway. I was questioning the wisdom/concensus/debate/ that went on before those mechanisms were selected. I didn't see any discussion, especially in other WGs who own those docs. As to alternatives to CLAT specifically I don't really care what they are, I don't like the approach being taken to create requirements on cellular hosts without any serious debate or IETF/3GPP consensus behind it. Hesham >=20 > >Thanks.=20 > >Cheers, >Med=20 > >>-----Message d'origine----- >>De : v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] De >>la part de Hesham Soliman >>Envoy=E9 : samedi 22 septembre 2012 03:01 >>=C0 : Ted Lemon; IPv6 Ops WG >>Objet : Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update >> >>> >>>On Sep 21, 2012, at 9:19 AM, Hesham Soliman >>>wrote: >>>> And has there been on consensus on that mechanism? Because >>if there is >>>> consensus on one approach then lets remove a few more >>requirements. The >>>> current draft seems to select two approaches from what I remember. >>> >>>It would be inappropriate for the v6ops working group to pick >>a winner. >>>We are just supposed to talk about operations. In that >>context, saying >>>"you probably ought to support DNS64" is meaningful advice, because a >>>device that doesn't support it isn't going to be able to do DNSSEC. >>>This would rule out an entire transition technology, or else rule out >>>DNSSEC. >>> >>>The situation is similar for other recommendations this >>document makes. >>>Can you maybe offer some motivation for your resistance to these >>>requirements other than "this is too strong"? >> >>=3D> My point is that we're effectively picking a winner. I >>didn't see any >>discussion before about which mechanisms would be recommended >>and suddenly >>we're saying CLAT is effectively a must implement in devices. The >>consequences if this are grave and that's why we need to have >>consensus on >>one or two approaches that would be recommended. If you think this WG >>can't pick a winner then let BEHAVE do it with IPv6 for example. The >>outcome of this draft should be a couple of mechanisms at >>most. So there >>needs to be a discussion about what those are with 3GPP as well. >> >>My argument doesn't boil down to "this is too strong" as you put it. It >>boils down to "where is the consensus on chosen mechanisms?" >>where is the >>discussion with other WGs and 3GPP? This needs to happen as it happened >>with similar RFCs in the past like 3314, 3316 or 3574. >> >>Hesham >> >>> >>>_______________________________________________ >>>v6ops mailing list >>>v6ops@ietf.org >>>https://www.ietf.org/mailman/listinfo/v6ops >> >> >>_______________________________________________ >>v6ops mailing list >>v6ops@ietf.org >>https://www.ietf.org/mailman/listinfo/v6ops From david.binet@orange.com Mon Sep 24 01:43:07 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08B2A21F85C4 for ; Mon, 24 Sep 2012 01:43:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.421 X-Spam-Level: X-Spam-Status: No, score=-1.421 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, SARE_SUB_OBFU_Q1=0.227, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yYrKH9WhNLfh for ; Mon, 24 Sep 2012 01:43: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 049CF21F85C0 for ; Mon, 24 Sep 2012 01:43:05 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id DFB653241F8; Mon, 24 Sep 2012 10:43:04 +0200 (CEST) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 83F5A27C06F; Mon, 24 Sep 2012 10:43:04 +0200 (CEST) Received: from PUEXCB1A.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Mon, 24 Sep 2012 10:42:59 +0200 From: To: Hesham Soliman , BOUCADAIR Mohamed OLNC/NAD/TIP , Ted Lemon , IPv6 Ops WG Date: Mon, 24 Sep 2012 10:42:58 +0200 Thread-Topic: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update Thread-Index: Ac2aGyT+QMEm6fXDTC+Bk12HoL8QmwAFDJmg Message-ID: <24244_1348476184_50601D18_24244_3652_1_1B2E7539FECD9048B261B791B1B24A7C3EBE4581B0@PUEXCB1A.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E5B1237E1@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: 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.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.9.23.145415 Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 08:43:07 -0000 Dear Hesham, Some answer below BR David > -----Message d'origine----- > De : v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org]=20 > De la part de Hesham Soliman > Envoy=E9 : lundi 24 septembre 2012 08:09 > =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; Ted Lemon; IPv6 Ops WG > Objet : Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update >=20 >=20 >=20 >=20 > >Dear Hesham, > > > >Which alternative(s) to CLAT you are referring to? >=20 > =3D> I don't think I suggested alternatives to CLAT=20 > specifically, can't see that in the email quoted anyway. > I was questioning the wisdom/concensus/debate/ that went on=20 > before those mechanisms were selected. I didn't see any=20 > discussion, especially in other WGs who own those docs. As to=20 > alternatives to CLAT specifically I don't really care what=20 > they are, I don't like the approach being taken to create=20 > requirements on cellular hosts without any serious debate or=20 > IETF/3GPP consensus behind it. Actually, you are right that there is a lack of IETF/3GPP debate about requ= irements on cellular hosts.=20 The goal of this draft is to instantiate this debate and to get an updated = RFC about IPv6 cellular hosts profile.=20 Regarding CLAT support, we are thinking it could be a solution to ensure th= at IPv4 communications can still be enabled when some IPv6 only connectivit= y is provided to the UE. We want to tackle IPv4 service continuity requirem= ent while some IPv6 connectivity is set up and we are open to alternative s= olutions if any.=20 >=20 >=20 > Hesham >=20 > >=20 > > > >Thanks.=20 > > > >Cheers, > >Med > > > >>-----Message d'origine----- > >>De : v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org]=20 > De la part=20 > >>de Hesham Soliman Envoy=E9 : samedi 22 septembre 2012 03:01 =C0 : Ted= =20 > >>Lemon; IPv6 Ops WG Objet : Re: [v6ops]=20 > >>draft-binet-v6ops-cellular-host-reqs-rfc3316update > >> > >>> > >>>On Sep 21, 2012, at 9:19 AM, Hesham Soliman=20 > >>> > >>>wrote: > >>>> And has there been on consensus on that mechanism? Because > >>if there is > >>>> consensus on one approach then lets remove a few more > >>requirements. The > >>>> current draft seems to select two approaches from what I=20 > remember. > >>> > >>>It would be inappropriate for the v6ops working group to pick > >>a winner. > >>>We are just supposed to talk about operations. In that > >>context, saying > >>>"you probably ought to support DNS64" is meaningful=20 > advice, because a=20 > >>>device that doesn't support it isn't going to be able to do DNSSEC. > >>>This would rule out an entire transition technology, or=20 > else rule out=20 > >>>DNSSEC. > >>> > >>>The situation is similar for other recommendations this > >>document makes. > >>>Can you maybe offer some motivation for your resistance to these=20 > >>>requirements other than "this is too strong"? > >> > >>=3D> My point is that we're effectively picking a winner. I=20 > didn't see=20 > >>any discussion before about which mechanisms would be=20 > recommended and=20 > >>suddenly we're saying CLAT is effectively a must implement=20 > in devices.=20 > >>The consequences if this are grave and that's why we need to have=20 > >>consensus on one or two approaches that would be=20 > recommended. If you=20 > >>think this WG can't pick a winner then let BEHAVE do it=20 > with IPv6 for=20 > >>example. The outcome of this draft should be a couple of=20 > mechanisms at=20 > >>most. So there needs to be a discussion about what those=20 > are with 3GPP=20 > >>as well. > >> > >>My argument doesn't boil down to "this is too strong" as=20 > you put it.=20 > >>It boils down to "where is the consensus on chosen mechanisms?" > >>where is the > >>discussion with other WGs and 3GPP? This needs to happen as it=20 > >>happened with similar RFCs in the past like 3314, 3316 or 3574. > >> > >>Hesham > >> > >>> > >>>_______________________________________________ > >>>v6ops mailing list > >>>v6ops@ietf.org > >>>https://www.ietf.org/mailman/listinfo/v6ops > >> > >> > >>_______________________________________________ > >>v6ops mailing list > >>v6ops@ietf.org > >>https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From david.binet@orange.com Mon Sep 24 04:27:31 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32C6421F860D for ; Mon, 24 Sep 2012 04:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.721 X-Spam-Level: X-Spam-Status: No, score=-1.721 tagged_above=-999 required=5 tests=[AWL=0.299, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, SARE_SUB_OBFU_Q1=0.227, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AjOUS3y7Qc-c for ; Mon, 24 Sep 2012 04:27:30 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id D9BFF21F860B for ; Mon, 24 Sep 2012 04:27:29 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 4931922C26B; Mon, 24 Sep 2012 13:27:28 +0200 (CEST) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 29FB64C06C; Mon, 24 Sep 2012 13:27:28 +0200 (CEST) Received: from PUEXCB1A.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Mon, 24 Sep 2012 13:27:23 +0200 From: To: "Hemant Singh (shemant)" , BOUCADAIR Mohamed OLNC/NAD/TIP , "Lorenzo Colitti" Date: Mon, 24 Sep 2012 13:27:22 +0200 Thread-Topic: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update Thread-Index: AQHNl8lIvgB9eKq4TDyGJOoGmWYBepeUvBUAgAGtoXCAAtv7kA== Message-ID: <7543_1348486048_506043A0_7543_3376_1_1B2E7539FECD9048B261B791B1B24A7C3EBE458308@PUEXCB1A.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E5A40D46C@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E5B1233CA@PUEXCB1B.nanterre.francetelecom.fr> <75B6FA9F576969419E42BECB86CB1B890901DD@xmb-rcd-x06.cisco.com> In-Reply-To: <75B6FA9F576969419E42BECB86CB1B890901DD@xmb-rcd-x06.cisco.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_1B2E7539FECD9048B261B791B1B24A7C3EBE458308PUEXCB1Anante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.9.24.101516 Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 11:27:31 -0000 --_000_1B2E7539FECD9048B261B791B1B24A7C3EBE458308PUEXCB1Anante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Hemant, Please see inline David ________________________________ De : v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] De la part de H= emant Singh (shemant) Envoy=E9 : samedi 22 septembre 2012 16:20 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; Lorenzo Colitti Cc : IPv6 Ops WG Objet : Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update Med, In the xlat document review it has been discussed numerous times that ND Pr= oxy is an Experimental RFC and the Experimental tag is enough to disqualify= the RFC as a reference in an Information document. Other details have al= so been provided as to why the ND Proxy document is Experimental! See http://www.ietf.org/mail-archive/web/v6ops/current/msg13904.html [David] ND proxy solution as specified in RFC4389 is not the best solution= for such need but until Prefix Delegation solution can be deployed in SP n= etworks. Without such solution and before Prefix Delegation can be used, IPv6 only c= onnectivity for cellular hosts with LAN interface is not possible. We can add some text about limitations of such solution if it can help and = recommend to deploy and use Prefix Delegation ASAP. Hemant From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of m= ohamed.boucadair@orange.com Sent: Friday, September 21, 2012 3:37 AM To: Lorenzo Colitti Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update 2. REQ#28 says the device MUST (no less!) support ND proxy. I don't think i= t's appropriate to say that an experimental RFC is a requirement. Additiona= lly, ND proxy is not fully baked, and it has issues with certain topologies= . We need a better solution than that. [Med] RFC4389 is the best reference we can quote at this stage. Do you have= a pointer to an I-D where these issues are discussed? We can add a pointer= to that I-D. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. --_000_1B2E7539FECD9048B261B791B1B24A7C3EBE458308PUEXCB1Anante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    Hi Hemant,
     
    Please see inline
    = David    =
    De : v6ops-bounces@ietf.org=20 [mailto:v6ops-bounces@ietf.org] De la part de Hemant Singh=20 (shemant)
    Envoy=E9 : samedi 22 septembre 2012=20 16:20
    =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; Lorenzo=20 Colitti
    Cc : IPv6 Ops WG
    Objet : Re: [v6ops= ]=20 draft-binet-v6ops-cellular-host-reqs-rfc3316update

    Med,

     

    In=20 the xlat document review it has been discussed numerous times that ND Pro= xy is=20 an Experimental RFC and the Experimental tag is enough to disqualify the = RFC=20 as a reference in an Information document.   Other details have= also=20 been provided as to why the ND Proxy document is Experimental! =20 See

     

    http://www.ietf.org/mail-archive/web/v6ops/current/msg13904.html

    [David]  ND proxy solution as specified in = RFC4389=20 is not the best solution for such need but until Prefix=20 Delegation solution can be deployed in SP networks.

    Without such solution and before Prefix Delegati= on can be=20 used, IPv6 only connectivity for cellular hosts with LAN interface i= s not=20 possible. 

    We can add some text about limitations of s= uch=20 solution if it can help and recommend to deploy and use Prefix Deleg= ation=20 ASAP.

     

     

    Hemant

     

    From:=20 v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of=20 mohamed.boucadair@orange.com
    Sent: Friday, September 21, 20= 12=20 3:37 AM
    To: Lorenzo Colitti
    Cc: IPv6 Ops=20 WG
    Subject: Re: [v6ops]=20 draft-binet-v6ops-cellular-host-reqs-rfc3316update

    <= /DIV>

     

     

    2. REQ#28 says the device MUST (no less!) support = ND=20 proxy. I don't think it's appropriate to say that an experimental RFC i= s a=20 requirement. Additionally, ND proxy is not fully baked, and it has issu= es=20 with certain topologies. We need a better solution than that.
    [Med= ] RFC4389=20 is the best reference we can quote at this stage. Do you have a pointer= to=20 an I-D where these issues are discussed? We can add a pointer to that= =20 I-D.

     

    ______________________________________________________________=
___________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.
    --_000_1B2E7539FECD9048B261B791B1B24A7C3EBE458308PUEXCB1Anante_-- From mohamed.boucadair@orange.com Mon Sep 24 06:12:58 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E394B21F869D for ; Mon, 24 Sep 2012 06:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, SARE_SUB_OBFU_Q1=0.227, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oB-ezAvywEZS for ; Mon, 24 Sep 2012 06:12:58 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 3123421F8679 for ; Mon, 24 Sep 2012 06:12:58 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 6897C22C3A3 for ; Mon, 24 Sep 2012 15:12:57 +0200 (CEST) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 4ACC84C09A for ; Mon, 24 Sep 2012 15:12:57 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Mon, 24 Sep 2012 15:12:57 +0200 From: To: IPv6 Ops WG Date: Mon, 24 Sep 2012 15:12:56 +0200 Thread-Topic: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update Thread-Index: AQHNl8lIvgB9eKq4TDyGJOoGmWYBepeUvBUAgAGtoXCAAtv7kIAANPxQ Message-ID: <94C682931C08B048B7A8645303FDC9F36E5B123A8C@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E5A40D46C@PUEXCB1B.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E5B1233CA@PUEXCB1B.nanterre.francetelecom.fr> <75B6FA9F576969419E42BECB86CB1B890901DD@xmb-rcd-x06.cisco.com> <1B2E7539FECD9048B261B791B1B24A7C3EBE458308@PUEXCB1A.nanterre.francetelecom.fr> In-Reply-To: <1B2E7539FECD9048B261B791B1B24A7C3EBE458308@PUEXCB1A.nanterre.francetelecom.fr> 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_94C682931C08B048B7A8645303FDC9F36E5B123A8CPUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.19.115414 Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 13:12:59 -0000 --_000_94C682931C08B048B7A8645303FDC9F36E5B123A8CPUEXCB1Bnante_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re-, We submitted a new version of the I-D integrating the comments received in = the list. In particular, the following changes are made in -02: * DNS64 requirement is now a SHOULD as suggested by Ted * Add a new requirement to RFC5555 as suggested by H. Soliman * Remove the requirement about ND Proxy but instead a new paragraph has bee= n added to describe the problem raised to share /64 * Add a new requirement for RFC4191 as suggested by L. Colliti, Behcet and = Jouni * Correct a typo about DHCP client (3315). * Welcome new co-authors A detailed diff is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-b= inet-v6ops-cellular-host-reqs-rfc3316update-02 The new version is available at: http://tools.ietf.org/id/draft-binet-v6ops= -cellular-host-reqs-rfc3316update-02.txt Cheers, Med --_000_94C682931C08B048B7A8645303FDC9F36E5B123A8CPUEXCB1Bnante_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    Re-,
     
    We submitted a new version of the I-D integrating the= =20 comments received in the list. In=20 particular, the following changes are made in -02:
     
    * DNS64 requirement is now a SHOULD as suggested by=20 Ted
    * Add a new requirement to RFC5555 as suggested by H.= =20 Soliman
    * Remove the requirement about ND Proxy but instead a = new=20 paragraph has been added to describe the problem raised to share=20 /64
    * Add a new requirement for RFC4191 as suggested by L.= =20 Colliti, Behcet and Jouni
    * Correct a typo about DHCP client (3315).=20
    * Welcome new co-authors
     
    A detailed diff is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-binet-v6ops= -cellular-host-reqs-rfc3316update-02
     
    The new version is available at: http://tools.ietf.org/id/draft-binet-v6ops-cellular-host-r= eqs-rfc3316update-02.txt
     
    Cheers,
    Med
    --_000_94C682931C08B048B7A8645303FDC9F36E5B123A8CPUEXCB1Bnante_-- From stefan.marksteiner@joanneum.at Mon Sep 24 11:03:17 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E97D21F86A4 for ; Mon, 24 Sep 2012 11:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.984 X-Spam-Level: X-Spam-Status: No, score=0.984 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VzPBVVPH8a9E for ; Mon, 24 Sep 2012 11:03:17 -0700 (PDT) Received: from rzjgate.joanneum.ac.at (rzjgate.joanneum.ac.at [143.224.185.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABFE121F8686 for ; Mon, 24 Sep 2012 11:03:16 -0700 (PDT) Received: from RZJS078.jr1.local (rzjs078.joanneum.ac.at [143.224.71.19]) by rzjgate.joanneum.ac.at (8.13.8/8.13.8) with ESMTP id q8OI37oH008605 for ; Mon, 24 Sep 2012 20:03:07 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joanneum.at; s=sel3; t=1348509787; bh=/3GkLc1meiVtLirFawl/VeNu501eBUQc8sRyqwoD4bQ=; h=From:To:Date:Subject:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=JLn+/ZNU9StP08ttQfXvbkOsL/p9hZQ4FK/YpSOU9ld3sVI92jG6qxeliVvc/E50V kNuT9VMoAo3ONEC013fajH3nLez0cQhT1o8yvtjEax4hHhFANU0k/UyY6HTFe0B0Wq vWFGHzCk9AyUStOIp1V5nKRpg5fZrD4pWXRwcXcY= Received: from RZJC1EX.jr1.local ([169.254.2.9]) by RZJS078.jr1.local ([143.224.71.19]) with mapi; Mon, 24 Sep 2012 20:03:07 +0200 From: "Marksteiner, Stefan" To: IPv6 Ops WG Date: Mon, 24 Sep 2012 20:03:06 +0200 Thread-Topic: Operational guidelines for a company/organization IPv6 address scheme supplemental to RFC5157 Thread-Index: AQHNmn5MFe6QqDDTL0+ZXCwWs+E2YQ== Message-ID: <8A317FD8C00FEE448E52D4EE5B56BB3E0232A086D8FF@RZJC1EX.jr1.local> Accept-Language: de-DE, de-AT Content-Language: de-AT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, de-AT Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [v6ops] Operational guidelines for a company/organization IPv6 address scheme supplemental to RFC5157 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 18:03:17 -0000 Hi Folks, RFC5157 presents hazards of sequentially numbering IPv6 networks and techni= cal means (like CGAs and privacy extensions) to mitigate them. Unfortunatel= y these mitigation methods may be deemed difficult to handle for administra= tors (SEND may be too complicated to implement, PEs bring difficulties to k= eep track of IP addresses). Therefore there may be demand for an addressing= scheme (rather than a technical method) that makes IPv6 addresses easy to = predict for tech staff but difficult to do so by outsiders, building a low-= end supplement for the methods mentioned in RFC5157. What I have in mind is an simple mental arithmetic operation, which generat= es an address out of a company fixed part plus a sequential number for host= . Alternatively a Hash-Operation consisting again of a secret organisationa= l plus a sequential host number. The first requires the scheme to be slight= ly different in every organisation in order to have a negative impact on IP= v6 scanning from external sources, the second is more secure but requires a= n internal web site or smartphone app in order for field engineers to calcu= late an address out of the sequential information. My question is, in your opinion, would this be worthwhile to be formulated = as an ID an be drafted or does this idea sound absurd? Cheers, Stefan= From markzzzsmith@yahoo.com.au Mon Sep 24 13:37:24 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7090A21F88E8 for ; Mon, 24 Sep 2012 13:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.915 X-Spam-Level: X-Spam-Status: No, score=0.915 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lKvLdrr7f8rC for ; Mon, 24 Sep 2012 13:37:23 -0700 (PDT) Received: from nm2.bullet.mail.ne1.yahoo.com (nm2.bullet.mail.ne1.yahoo.com [98.138.90.65]) by ietfa.amsl.com (Postfix) with SMTP id 8D30521F88E7 for ; Mon, 24 Sep 2012 13:37:23 -0700 (PDT) Received: from [98.138.90.54] by nm2.bullet.mail.ne1.yahoo.com with NNFMP; 24 Sep 2012 20:37:14 -0000 Received: from [98.138.87.9] by tm7.bullet.mail.ne1.yahoo.com with NNFMP; 24 Sep 2012 20:37:14 -0000 Received: from [127.0.0.1] by omp1009.mail.ne1.yahoo.com with NNFMP; 24 Sep 2012 20:37:14 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 945054.46818.bm@omp1009.mail.ne1.yahoo.com Received: (qmail 75375 invoked by uid 60001); 24 Sep 2012 20:37:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1348519034; bh=JzRan45Q1NOgcfXNfNn7w6EpasfIrE/9g894h2EuTCM=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=nF+n9A3iWZEmtq8QsJ2KHyVrKwKmjQnGyYEhD+VB+YWhVy7G7zby863mxo9DtKgvTOluI3l6sHjr73j1OULq48C5LeCDp6APRlOEIJA4iPdpBGO9OOGOkCMvQX2V1evmBMV5bNcVRiIGvjKuIGLhj/r1faFwAKp5TZz7QnyrN1o= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=L1EKxK5jEhe2w5RGOMoiSQOfCX6Kt7yrK9s2dGM60w+MRRVqIPLRIHSLNu9LqPiX2CoGPmQXaaO4S7RyecOQgEI1wf8YCfu7IO9hgmPILp90IJoY0PNpEkfNjXl6SSwMaTAuPzw8B9qzpYvGCTcFmaphP2K3SdRAMmY+aiJbTts=; X-YMail-OSG: f5Hei64VM1kkbNPDlxFreoHtnG1IVwqgntASEqO7w98IxmR msYv3zIpSTqVG_tdVtI6qkiiNbd..i1J5jXmMSYwuhZna5S0wL1rc2DE_GTe wewJX7GEyRYzfYCXqnyJ7nX1z7GjizLlgWF9SGTn_gCCmnwefDILQDlSKCiF mElcxOEF5lkjD9kFjLwAnCIWfHRjOk4TVyKva7NZAUT1KbYlBttShhDLI17P v8UbfxmVYd0zW0IXmDieaA5pXFbXJoVZgoauRnK29YBO_re5TVhV1ytaEw1a JmSAtFHLVQl1oWD5VlWLjykCFfg2wOKdlLGbUfwLOlBrYQthy.Z5c.3bMTWz 2fpMJ.SvfJt7khGMrVpjUGstlkcaMKuzRWsi12hQynd6vQrXUcGvfG0MXTVX DFjxky58n3XNcrQ_NK0SDIhqQWWhuyJiqdYMqQBhfCHBy3sRUNZKmFU1Suz3 aGQgBz8W1UHg3sa_xLvxxYHXwbLRepEUFGNvfOTDI8tBFnP_g9EbSc2G0Xa9 L1g-- Received: from [150.101.221.237] by web32503.mail.mud.yahoo.com via HTTP; Mon, 24 Sep 2012 13:37:14 PDT X-Mailer: YahooMailWebService/0.8.121.434 References: <8A317FD8C00FEE448E52D4EE5B56BB3E0232A086D8FF@RZJC1EX.jr1.local> Message-ID: <1348519034.47465.YahooMailNeo@web32503.mail.mud.yahoo.com> Date: Mon, 24 Sep 2012 13:37:14 -0700 (PDT) From: Mark ZZZ Smith To: "Marksteiner, Stefan" , IPv6 Ops WG In-Reply-To: <8A317FD8C00FEE448E52D4EE5B56BB3E0232A086D8FF@RZJC1EX.jr1.local> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [v6ops] Operational guidelines for a company/organization IPv6 address scheme supplemental to RFC5157 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 20:37:24 -0000 Hi Stefan,=0A=0A----- Original Message -----=0A=0A> From: "Marksteiner, Ste= fan" =0A> To: IPv6 Ops WG = =0A> Cc: =0A> Sent: Tuesday, 25 September 2012 4:03 AM=0A> Subject: [v6ops]= Operational guidelines for a company/organization IPv6 address scheme supp= lemental to RFC5157=0A> =0A> =0A> Hi Folks,=0A> =0A> RFC5157 presents hazar= ds of sequentially numbering IPv6 networks and technical =0A> means (like C= GAs and privacy extensions) to mitigate them. Unfortunately these =0A> miti= gation methods may be deemed difficult to handle for administrators (SEND = =0A> may be too complicated to implement, PEs bring difficulties to keep tr= ack of IP =0A> addresses). Therefore there may be demand for an addressing = scheme (rather than =0A> a technical method) that makes IPv6 addresses easy= to predict for tech staff but =0A> difficult to do so by outsiders, buildi= ng a low-end supplement for the methods =0A> mentioned in RFC5157.=0A=0A=0A= I think it might be worth having a bit more of a think about who might be i= nclined to attack you - for a typical non-Internet services organisation, I= think it's more likely going to be=A0=0Adisgruntled ex-staff, and it'll be= hard to make them forget "numbers" / addresses or prevent them copying the= mapping application if they have an=A0inkling=A0they're going to get fired= .=0A=0A=0A>=A0=0A=0A> What I have in mind is an simple mental arithmetic op= eration, which generates an =0A> address out of a company fixed part plus a= sequential number for host. =0A> Alternatively a Hash-Operation consisting= again of a secret organisational plus =0A> a sequential host number. The f= irst requires the scheme to be slightly different =0A> in every organisatio= n in order to have a negative impact on IPv6 scanning from =0A> external so= urces, the second is more secure but requires an internal web site or =0A> = smartphone app in order for field engineers to calculate an address out of = the =0A> sequential information.=0A>=A0=0A=0AIt sounds like here you're tal= king about a subnet numbering scheme. The common prefix size for most organ= isations is going to be /56 or 256 /64 subnets, or /48 or 65K /64 subnets. = Many providers seem to be leaning towards /56s unless their customers ask f= or a /48, which provides very little address space to effectively hide the = in-use subnet numbers from a scanning based attack (and that's one of the r= easons why I'd be giving customers /48s from the outset). One advantage tho= ugh of IPv6 is that it is possible to phase in and phase out addressing usi= ng the address/prefix lifetimes mechanism, so it would be possible to chang= e assigned in your network prefixes on e.g. a weekly basis.=0A=0AIf your fu= ndamental goal is to make internal links unreachable from the Internet, the= y can be not assigned a global prefix, and numbered from either the ULA add= ress space (RFC4193) or left as=A0link-locals only ("unnumbered"). You may = be interested in the following, which discusses link-local only addressing = -=0A=0A"Using Only Link-Local Addressing Inside an IPv6 Network"=0Ahttp://t= ools.ietf.org/html/draft-behringer-lla-only-01=0A=0A=0ARegards,=0A=0AMark.= =0A=0A> My question is, in your opinion, would this be worthwhile to be for= mulated as an=A0=0A> ID an be drafted or does this idea sound absurd?=0A>= =A0=0A>=A0=0A=0A> Cheers,=0A> =0A> Stefan=0A> _____________________________= __________________=0A> v6ops mailing list=0A> v6ops@ietf.org=0A> https://ww= w.ietf.org/mailman/listinfo/v6ops=0A> From mawatari@jpix.ad.jp Mon Sep 24 21:39:05 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA3F21F890F for ; Mon, 24 Sep 2012 21:39:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.137 X-Spam-Level: X-Spam-Status: No, score=0.137 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S3SsUe49KEjh for ; Mon, 24 Sep 2012 21:39:04 -0700 (PDT) Received: from mx20.jpix.ad.jp (mx20.jpix.ad.jp [210.171.225.78]) by ietfa.amsl.com (Postfix) with ESMTP id 8156621F8911 for ; Mon, 24 Sep 2012 21:39:03 -0700 (PDT) Received: from [10.10.31.235] (eth3-1-bb-fw-34.jpix.ad.jp [210.171.226.102]) by mx20.jpix.ad.jp (Postfix) with ESMTP id 8AF6AFC0BA; Tue, 25 Sep 2012 13:39:00 +0900 (JST) Date: Tue, 25 Sep 2012 13:39:00 +0900 From: MAWATARI Masataka To: mohamed.boucadair@orange.com In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E5B123A8C@PUEXCB1B.nanterre.francetelecom.fr> References: <1B2E7539FECD9048B261B791B1B24A7C3EBE458308@PUEXCB1A.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E5B123A8C@PUEXCB1B.nanterre.francetelecom.fr> Message-Id: <20120925133859.15A2.8FE1F57E@jpix.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.61.01 [ja] Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 04:39:05 -0000 Dear authors, I read throuth your draft. Comment about REQ#6 and REQ#7 on -02 version regarding conveying DNS server. I heard that both of DHCPv6 client and RA options is not common on 3GPP mobile network at least for now. This document describes that if RA options is not supported, the cellular host should embed DHCPv6 client. Will RA options have more appreciated than DHCPv6 client on mobile? However, both requirements have same SHOULD. Such a document should provide the clear preference and reasons about that, in my opinion. Kind Regards, Masataka MAWATARI * On Mon, 24 Sep 2012 15:12:56 +0200 * wrote: > Re-, > > We submitted a new version of the I-D integrating the comments received in the list. In particular, the following changes are made in -02: > > * DNS64 requirement is now a SHOULD as suggested by Ted > * Add a new requirement to RFC5555 as suggested by H. Soliman > * Remove the requirement about ND Proxy but instead a new paragraph has been added to describe the problem raised to share /64 > * Add a new requirement for RFC4191 as suggested by L. Colliti, Behcet and Jouni > * Correct a typo about DHCP client (3315). > * Welcome new co-authors > > A detailed diff is available at: http://www.ietf.org/rfcdiff?url2=draft-binet-v6ops-cellular-host-reqs-rfc3316update-02 > > The new version is available at: http://tools.ietf.org/id/draft-binet-v6ops-cellular-host-reqs-rfc3316update-02.txt > > Cheers, > Med From jouni.nospam@gmail.com Tue Sep 25 01:04:08 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E60A21F8905 for ; Tue, 25 Sep 2012 01:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[AWL=-0.376, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQU2tkaILXP7 for ; Tue, 25 Sep 2012 01:04:07 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 845B721F8934 for ; Tue, 25 Sep 2012 01:04:07 -0700 (PDT) Received: by bkty12 with SMTP id y12so3305335bkt.31 for ; Tue, 25 Sep 2012 01:04:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=FYumEyNiGC+DYSAOlg5evquRySTWq+iH6MCJQEeP+jQ=; b=QNb2RSB4WemPCpUmfQE5o1+8DMQBhqXEewx+rvyvePxwsHXq6nhiatUcRmCBCU8DKn oi/3OZp0RiG3VWc6AOwAppjeCgRMTE+ZoRqjFi2QdOmpVSsrTFm3tscETQgJuJNGC10Y FFFiUYYCkJEsj8PlyKqW3qsA43ATbE/nihqRZBjbhdYWEaowpPmjD+xf8KklCb/zPuWS pefyjHQK12lMWzfsnLPPB+CrBWR6zWwDALQXNXsLYJZcvejNwSQ4ZtATSxDBuE7Ii+/N +GxqKhMbeasUi8yIEaFYzX87mG2R72eGiww2sI/mOaTE4JCKjzvaDzNRe7/yO+wGOHbK 8NKw== Received: by 10.204.4.129 with SMTP id 1mr5662763bkr.58.1348560246584; Tue, 25 Sep 2012 01:04:06 -0700 (PDT) Received: from ?IPv6:2001:67c:64:42:226:bbff:fe18:6e9c? ([2001:67c:64:42:226:bbff:fe18:6e9c]) by mx.google.com with ESMTPS id n5sm11711673bkv.14.2012.09.25.01.04.05 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 25 Sep 2012 01:04:05 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <20120925133859.15A2.8FE1F57E@jpix.ad.jp> Date: Tue, 25 Sep 2012 11:04:03 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <523CF185-5C72-4299-B4DA-3CEDBA7466D3@gmail.com> References: <1B2E7539FECD9048B261B791B1B24A7C3EBE458308@PUEXCB1A.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E5B123A8C@PUEXCB1B.nanterre.francetelecom.fr> <20120925133859.15A2.8FE1F57E@jpix.ad.jp> To: MAWATARI Masataka X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 08:04:08 -0000 On Sep 25, 2012, at 7:39 AM, MAWATARI Masataka wrote: > Dear authors, >=20 > I read throuth your draft. >=20 > Comment about REQ#6 and REQ#7 on -02 version regarding conveying > DNS server. >=20 > I heard that both of DHCPv6 client and RA options is not common on > 3GPP mobile network at least for now. Specific to 3GPP, its "NAS" layer can deliver the mobile the DNS server address among several other configuration things. Since NAS is in 3GPP's hands it somehow gets preferred.. Currently as for Release-11 DHCPv6 is still optional and RDNS is not there at all. > This document describes that if RA options is not supported, the > cellular host should embed DHCPv6 client. Will RA options have > more appreciated than DHCPv6 client on mobile? However, both > requirements have same SHOULD. >=20 > Such a document should provide the clear preference and reasons > about that, in my opinion. The preference ordering is in the text already in a way in req#7 it seems but could be more clear/strict. - Jouni >=20 >=20 > Kind Regards, > Masataka MAWATARI >=20 >=20 > * On Mon, 24 Sep 2012 15:12:56 +0200 > * wrote: >=20 >> Re-, >>=20 >> We submitted a new version of the I-D integrating the comments = received in the list. In particular, the following changes are made in = -02: >>=20 >> * DNS64 requirement is now a SHOULD as suggested by Ted >> * Add a new requirement to RFC5555 as suggested by H. Soliman >> * Remove the requirement about ND Proxy but instead a new paragraph = has been added to describe the problem raised to share /64 >> * Add a new requirement for RFC4191 as suggested by L. Colliti, = Behcet and Jouni >> * Correct a typo about DHCP client (3315). >> * Welcome new co-authors >>=20 >> A detailed diff is available at: = http://www.ietf.org/rfcdiff?url2=3Ddraft-binet-v6ops-cellular-host-reqs-rf= c3316update-02 >>=20 >> The new version is available at: = http://tools.ietf.org/id/draft-binet-v6ops-cellular-host-reqs-rfc3316updat= e-02.txt >>=20 >> Cheers, >> Med >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From stefan.marksteiner@joanneum.at Tue Sep 25 02:42:56 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CFA021F888E for ; Tue, 25 Sep 2012 02:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.822 X-Spam-Level: X-Spam-Status: No, score=0.822 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_05=-1.11, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P0OwAbPZ+d9I for ; Tue, 25 Sep 2012 02:42:55 -0700 (PDT) Received: from rzjgate.joanneum.ac.at (rzjgate.joanneum.ac.at [143.224.185.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBD7921F87EF for ; Tue, 25 Sep 2012 02:42:52 -0700 (PDT) Received: from RZJS078.jr1.local (rzjs078.joanneum.ac.at [143.224.71.19]) by rzjgate.joanneum.ac.at (8.13.8/8.13.8) with ESMTP id q8P9ghri024120; Tue, 25 Sep 2012 11:42:43 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joanneum.at; s=sel3; t=1348566164; bh=p1euodXC9wfVCwvKOvNqdajYlg1lT4UKvDUuwYQea1o=; h=From:To:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=Gi7tfjKiEbLOyyyZkQvNRtedoE4Pdq3J22qucx494xBFpbbtN91tC6A7gDiZ+q3oY jFu7nB8rXydr3E4yf7rfjX5/Jduizc1o1hXXMcyKcfNZDgQ3xbclZvk4RzNejWtaCb qNe35U5VNBz2diX9Ced7fSIe7rWGlwYWvIdZ6XJc= Received: from RZJC1EX.jr1.local ([169.254.2.9]) by RZJS078.jr1.local ([143.224.71.19]) with mapi; Tue, 25 Sep 2012 11:42:43 +0200 From: "Marksteiner, Stefan" To: Mark ZZZ Smith , IPv6 Ops WG Date: Tue, 25 Sep 2012 11:42:42 +0200 Thread-Topic: [v6ops] Operational guidelines for a company/organization IPv6 address scheme supplemental to RFC5157 Thread-Index: Ac2alGOmRXLD95pFS5uNww+GZ/7kNQAZ3azR Message-ID: <8A317FD8C00FEE448E52D4EE5B56BB3E0232A086D902@RZJC1EX.jr1.local> References: <8A317FD8C00FEE448E52D4EE5B56BB3E0232A086D8FF@RZJC1EX.jr1.local>, <1348519034.47465.YahooMailNeo@web32503.mail.mud.yahoo.com> In-Reply-To: <1348519034.47465.YahooMailNeo@web32503.mail.mud.yahoo.com> Accept-Language: de-DE, de-AT Content-Language: de-AT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, de-AT Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] Operational guidelines for a company/organization IPv6 address scheme supplemental to RFC5157 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 09:42:56 -0000 Hi Mark, First of all I think I've forgotten to clarify that I'm talking about IIDs,= sorry ;) The aim of my thoughts would be to make it harder for externals to scan for= attackable addresses. One often cited (mostly by marketeers) benefit of IP= v6 is the vast amount of addresses per subnet making it seemingly harder to= scan, which would be nullified if companies used simple sequential address= ing. You're of course right that most (potential) attackers are insiders - but t= hey likely wouldn't have to scan anyway, instead the would probably already= have knowledge of alive (and maybe even vulnerable) hosts. Thus, they aren= 't my focus in this matter, but instead are "black box"-scanners and Intern= et worms.=20 ULA/LLA are, as you've correctly stated, the best choice if you don't need = Internet connection, but what about workstations for employees needing the = Internet? I'm suggesting to recommend companies to use a different scheme as ::1;::2 = or ::BABE;::CAFE or even ::4593;4594 and so on which according to some stud= ies (e.g. [1], pp.65-75, especially 68) most administrators unfortunately d= o. What might be needed to change this would be a scheme which is practicably = administrable in the easiest possible way. This would have, in my opinion, two benefits. Firstly it would render stand= ard scanning procedures for IPv6 like sequential scanning and scanning for = "funny" addresses pretty much useless. Secondly, if the numbers are, seen f= rom the outside, seemingly random, it wouldn't help a scanner or worm if he= or it discovered a single address by chance (e.g. by a log entry) and took= it as a starting point for further scanning. I'm aware of the discussions about security by obscurity and that a good fi= rewall is needed anyway to secure internal assets, but I would find it nice= if the often cited "security argument" that IPv6 subnets are merely imposs= ible to scan would be true (again) :) Cheers, Stefan [1]http://www.mh-sec.de/downloads/mh-ipv6_vulnerabilities.pdf ________________________________________ Von: Mark ZZZ Smith [markzzzsmith@yahoo.com.au] Gesendet: Montag, 24. September 2012 22:37 An: Marksteiner, Stefan; IPv6 Ops WG Betreff: Re: [v6ops] Operational guidelines for a company/organization IPv6= address scheme supplemental to RFC5157 Hi Stefan, ----- Original Message ----- > From: "Marksteiner, Stefan" > To: IPv6 Ops WG > Cc: > Sent: Tuesday, 25 September 2012 4:03 AM > Subject: [v6ops] Operational guidelines for a company/organization IPv6 a= ddress scheme supplemental to RFC5157 > > > Hi Folks, > > RFC5157 presents hazards of sequentially numbering IPv6 networks and tech= nical > means (like CGAs and privacy extensions) to mitigate them. Unfortunately = these > mitigation methods may be deemed difficult to handle for administrators (= SEND > may be too complicated to implement, PEs bring difficulties to keep track= of IP > addresses). Therefore there may be demand for an addressing scheme (rathe= r than > a technical method) that makes IPv6 addresses easy to predict for tech st= aff but > difficult to do so by outsiders, building a low-end supplement for the me= thods > mentioned in RFC5157. I think it might be worth having a bit more of a think about who might be i= nclined to attack you - for a typical non-Internet services organisation, I= think it's more likely going to be disgruntled ex-staff, and it'll be hard to make them forget "numbers" / add= resses or prevent them copying the mapping application if they have an inkl= ing they're going to get fired. >=A0 > What I have in mind is an simple mental arithmetic operation, which gener= ates an > address out of a company fixed part plus a sequential number for host. > Alternatively a Hash-Operation consisting again of a secret organisationa= l plus > a sequential host number. The first requires the scheme to be slightly di= fferent > in every organisation in order to have a negative impact on IPv6 scanning= from > external sources, the second is more secure but requires an internal web = site or > smartphone app in order for field engineers to calculate an address out o= f the > sequential information. >=A0 It sounds like here you're talking about a subnet numbering scheme. The com= mon prefix size for most organisations is going to be /56 or 256 /64 subnet= s, or /48 or 65K /64 subnets. Many providers seem to be leaning towards /56= s unless their customers ask for a /48, which provides very little address = space to effectively hide the in-use subnet numbers from a scanning based a= ttack (and that's one of the reasons why I'd be giving customers /48s from = the outset). One advantage though of IPv6 is that it is possible to phase i= n and phase out addressing using the address/prefix lifetimes mechanism, so= it would be possible to change assigned in your network prefixes on e.g. a= weekly basis. If your fundamental goal is to make internal links unreachable from the Int= ernet, they can be not assigned a global prefix, and numbered from either t= he ULA address space (RFC4193) or left as link-locals only ("unnumbered"). = You may be interested in the following, which discusses link-local only add= ressing - "Using Only Link-Local Addressing Inside an IPv6 Network" http://tools.ietf.org/html/draft-behringer-lla-only-01 Regards, Mark. > My question is, in your opinion, would this be worthwhile to be formulate= d as an > ID an be drafted or does this idea sound absurd? >=A0 >=A0 > Cheers, > > Stefan > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From rajiva@cisco.com Tue Sep 25 04:53:19 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A09621F844C for ; Tue, 25 Sep 2012 04:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.186 X-Spam-Level: X-Spam-Status: No, score=-10.186 tagged_above=-999 required=5 tests=[AWL=-0.413, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zToEYr6o5nLz for ; Tue, 25 Sep 2012 04:53:18 -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 3BA9421F844F for ; Tue, 25 Sep 2012 04:53:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2882; q=dns/txt; s=iport; t=1348573998; x=1349783598; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=lNxoj+lDuOOLJrGhbdhShESb8POEYkYwNmDnyRWw7Ng=; b=hJ2L57ybUjFXZ4JooZxIBhkMP2OEw324cL6R2sH3esqRKvUbPBNhH5MN 7eRdeTPazznMCoTiIjxG1feP+gxRU6lUkrKFu0UemTdHc1+Jcf8ql9Z6d ULylbkPx55bbMTkD+PK8rNAt8x8byt0knKxWl0OLu0hDteAeFK4+AAe+J 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIOaYVCtJV2Y/2dsb2JhbABFvmiBCIIgAQEBAwEBAQEPASc0CxACAQgYHhAhBgslAgQOBQkZh1EDCQYLmCePV4ciDYlTijlihWJgA5QQgVWBFYoFgyGBaYJn X-IronPort-AV: E=Sophos;i="4.80,481,1344211200"; d="scan'208";a="125037697" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 25 Sep 2012 11:53:15 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q8PBrEx9004028 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Sep 2012 11:53:14 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.230]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0298.004; Tue, 25 Sep 2012 06:53:13 -0500 From: "Rajiv Asati (rajiva)" To: jouni korhonen Thread-Topic: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update Thread-Index: AQHNl8lIkygjt2tHRWm0TALPSDGcNpeUvBUAgAGtoXCAAtv7kIAANPxQgAFY7wCAADlKgP//7DZA Date: Tue, 25 Sep 2012 11:53:13 +0000 Message-ID: References: <1B2E7539FECD9048B261B791B1B24A7C3EBE458308@PUEXCB1A.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E5B123A8C@PUEXCB1B.nanterre.francetelecom.fr> <20120925133859.15A2.8FE1F57E@jpix.ad.jp>, <523CF185-5C72-4299-B4DA-3CEDBA7466D3@gmail.com> In-Reply-To: <523CF185-5C72-4299-B4DA-3CEDBA7466D3@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19208.004 x-tm-as-result: No--41.163500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 11:53:19 -0000 Jouni, Trying to make sense of 3GPP's thought process here - =20 * rel 10 includes DHCPv6 for PD, rel 11 keeps DHCPv6 (for NA!) optional. * SLAAC is included (rel 8 onwards!), but complimentary RDNS stays excluded= . I guess 'simplification' is very subjective. ;-) Cheers, Rajiv Sent from my Phone On Sep 25, 2012, at 4:04 AM, "jouni korhonen" wrot= e: >=20 > On Sep 25, 2012, at 7:39 AM, MAWATARI Masataka wrote: >=20 >> Dear authors, >>=20 >> I read throuth your draft. >>=20 >> Comment about REQ#6 and REQ#7 on -02 version regarding conveying >> DNS server. >>=20 >> I heard that both of DHCPv6 client and RA options is not common on >> 3GPP mobile network at least for now. >=20 > Specific to 3GPP, its "NAS" layer can deliver the mobile the DNS server > address among several other configuration things. Since NAS is in 3GPP's > hands it somehow gets preferred.. Currently as for Release-11 DHCPv6 is > still optional and RDNS is not there at all. >=20 >> This document describes that if RA options is not supported, the >> cellular host should embed DHCPv6 client. Will RA options have >> more appreciated than DHCPv6 client on mobile? However, both >> requirements have same SHOULD. >>=20 >> Such a document should provide the clear preference and reasons >> about that, in my opinion. >=20 > The preference ordering is in the text already in a way in req#7 it > seems but could be more clear/strict. >=20 > - Jouni >=20 >=20 >=20 >>=20 >>=20 >> Kind Regards, >> Masataka MAWATARI >>=20 >>=20 >> * On Mon, 24 Sep 2012 15:12:56 +0200 >> * wrote: >>=20 >>> Re-, >>>=20 >>> We submitted a new version of the I-D integrating the comments received= in the list. In particular, the following changes are made in -02: >>>=20 >>> * DNS64 requirement is now a SHOULD as suggested by Ted >>> * Add a new requirement to RFC5555 as suggested by H. Soliman >>> * Remove the requirement about ND Proxy but instead a new paragraph has= been added to describe the problem raised to share /64 >>> * Add a new requirement for RFC4191 as suggested by L. Colliti, Behcet = and Jouni >>> * Correct a typo about DHCP client (3315). >>> * Welcome new co-authors >>>=20 >>> A detailed diff is available at: http://www.ietf.org/rfcdiff?url2=3Ddra= ft-binet-v6ops-cellular-host-reqs-rfc3316update-02 >>>=20 >>> The new version is available at: http://tools.ietf.org/id/draft-binet-v= 6ops-cellular-host-reqs-rfc3316update-02.txt >>>=20 >>> Cheers, >>> Med >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From brian.e.carpenter@gmail.com Tue Sep 25 06:27:57 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9026C21F8694 for ; Tue, 25 Sep 2012 06:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.278 X-Spam-Level: X-Spam-Status: No, score=-103.278 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VjAPOgn1A6Kz for ; Tue, 25 Sep 2012 06:27:56 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 64EE421F8690 for ; Tue, 25 Sep 2012 06:27:56 -0700 (PDT) Received: by iec9 with SMTP id 9so15310896iec.31 for ; Tue, 25 Sep 2012 06:27:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=LFtqFkPks5s4JxsY7Kj/AaYLk9qIo7CdeRqg9/TC4DI=; b=qPOL5MZar/JCyO9FqXvPVj5lsLr5cNjabaw+y1+/RzrMKmpDOFrrzP3rOqj0mUZ8ix Mxn/n/jt8z+NEcReaoIn1MOLVk1/JTCfLUz4RNbHlKA3QeGWX0LVItOqXcDaZ4zobKTV qYIf6U4er14LujD8NHXXYZ31bnr4g8VzwWYbFkOwjSf3OAVwA0u0YiUsFaa5pNIuiK2H CYRuzGbipOpJJvMc5AWM4CEf2XaGZ2/WpTNT6Fpzk86+9zJCmCXH4bQlUba0XRUhZ/EU g+TUdui0kXSdW5K1C8M6mb5pHwtieUSd4m0cjj9Oj8TM7VdF95BFUmsV9s2a0rPAU8Iw vB7g== Received: by 10.50.173.100 with SMTP id bj4mr8100981igc.35.1348579675925; Tue, 25 Sep 2012 06:27:55 -0700 (PDT) Received: from [10.255.25.102] (50-76-68-140-static.hfc.comcastbusiness.net. [50.76.68.140]) by mx.google.com with ESMTPS id bp8sm212164igb.12.2012.09.25.06.27.54 (version=SSLv3 cipher=OTHER); Tue, 25 Sep 2012 06:27:55 -0700 (PDT) Message-ID: <5061B157.1090106@gmail.com> Date: Tue, 25 Sep 2012 14:27:51 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Marksteiner, Stefan" References: <8A317FD8C00FEE448E52D4EE5B56BB3E0232A086D8FF@RZJC1EX.jr1.local>, <1348519034.47465.YahooMailNeo@web32503.mail.mud.yahoo.com> <8A317FD8C00FEE448E52D4EE5B56BB3E0232A086D902@RZJC1EX.jr1.local> In-Reply-To: <8A317FD8C00FEE448E52D4EE5B56BB3E0232A086D902@RZJC1EX.jr1.local> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] Operational guidelines for a company/organization IPv6 address scheme supplemental to RFC5157 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 13:27:57 -0000 On 25/09/2012 10:42, Marksteiner, Stefan wrote: > Hi Mark, > > First of all I think I've forgotten to clarify that I'm talking about IIDs, sorry ;) > The aim of my thoughts would be to make it harder for externals to scan for attackable addresses. One often cited (mostly by marketeers) benefit of IPv6 is the vast amount of addresses per subnet making it seemingly harder to scan, which would be nullified if companies used simple sequential addressing. > > You're of course right that most (potential) attackers are insiders - but they likely wouldn't have to scan anyway, instead the would probably already have knowledge of alive (and maybe even vulnerable) hosts. Thus, they aren't my focus in this matter, but instead are "black box"-scanners and Internet worms. > > ULA/LLA are, as you've correctly stated, the best choice if you don't need Internet connection, but what about workstations for employees needing the Internet? > > I'm suggesting to recommend companies to use a different scheme as ::1;::2 or ::BABE;::CAFE or even ::4593;4594 and so on which according to some studies (e.g. [1], pp.65-75, especially 68) most administrators unfortunately do. > What might be needed to change this would be a scheme which is practicably administrable in the easiest possible way. It depends what you mean by "administrable" but SLAAC doesn't need a scheme and therefore doesn't need administration. For machines that are in public DNS it doesn't matter anyway, so any scheme will do. Brian > This would have, in my opinion, two benefits. Firstly it would render standard scanning procedures for IPv6 like sequential scanning and scanning for "funny" addresses pretty much useless. Secondly, if the numbers are, seen from the outside, seemingly random, it wouldn't help a scanner or worm if he or it discovered a single address by chance (e.g. by a log entry) and took it as a starting point for further scanning. > > I'm aware of the discussions about security by obscurity and that a good firewall is needed anyway to secure internal assets, but I would find it nice if the often cited "security argument" that IPv6 subnets are merely impossible to scan would be true (again) :) > > > Cheers, > > Stefan > > > [1]http://www.mh-sec.de/downloads/mh-ipv6_vulnerabilities.pdf > ________________________________________ > Von: Mark ZZZ Smith [markzzzsmith@yahoo.com.au] > Gesendet: Montag, 24. September 2012 22:37 > An: Marksteiner, Stefan; IPv6 Ops WG > Betreff: Re: [v6ops] Operational guidelines for a company/organization IPv6 address scheme supplemental to RFC5157 > > Hi Stefan, > > ----- Original Message ----- > >> From: "Marksteiner, Stefan" >> To: IPv6 Ops WG >> Cc: >> Sent: Tuesday, 25 September 2012 4:03 AM >> Subject: [v6ops] Operational guidelines for a company/organization IPv6 address scheme supplemental to RFC5157 >> >> >> Hi Folks, >> >> RFC5157 presents hazards of sequentially numbering IPv6 networks and technical >> means (like CGAs and privacy extensions) to mitigate them. Unfortunately these >> mitigation methods may be deemed difficult to handle for administrators (SEND >> may be too complicated to implement, PEs bring difficulties to keep track of IP >> addresses). Therefore there may be demand for an addressing scheme (rather than >> a technical method) that makes IPv6 addresses easy to predict for tech staff but >> difficult to do so by outsiders, building a low-end supplement for the methods >> mentioned in RFC5157. > > > I think it might be worth having a bit more of a think about who might be inclined to attack you - for a typical non-Internet services organisation, I think it's more likely going to be > disgruntled ex-staff, and it'll be hard to make them forget "numbers" / addresses or prevent them copying the mapping application if they have an inkling they're going to get fired. > > >> > >> What I have in mind is an simple mental arithmetic operation, which generates an >> address out of a company fixed part plus a sequential number for host. >> Alternatively a Hash-Operation consisting again of a secret organisational plus >> a sequential host number. The first requires the scheme to be slightly different >> in every organisation in order to have a negative impact on IPv6 scanning from >> external sources, the second is more secure but requires an internal web site or >> smartphone app in order for field engineers to calculate an address out of the >> sequential information. >> > > It sounds like here you're talking about a subnet numbering scheme. The common prefix size for most organisations is going to be /56 or 256 /64 subnets, or /48 or 65K /64 subnets. Many providers seem to be leaning towards /56s unless their customers ask for a /48, which provides very little address space to effectively hide the in-use subnet numbers from a scanning based attack (and that's one of the reasons why I'd be giving customers /48s from the outset). One advantage though of IPv6 is that it is possible to phase in and phase out addressing using the address/prefix lifetimes mechanism, so it would be possible to change assigned in your network prefixes on e.g. a weekly basis. > > If your fundamental goal is to make internal links unreachable from the Internet, they can be not assigned a global prefix, and numbered from either the ULA address space (RFC4193) or left as link-locals only ("unnumbered"). You may be interested in the following, which discusses link-local only addressing - > > "Using Only Link-Local Addressing Inside an IPv6 Network" > http://tools.ietf.org/html/draft-behringer-lla-only-01 > > > Regards, > > Mark. > >> My question is, in your opinion, would this be worthwhile to be formulated as an >> ID an be drafted or does this idea sound absurd? >> >> > >> Cheers, >> >> Stefan >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From stefan.marksteiner@joanneum.at Tue Sep 25 07:20:20 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 510D321F8557 for ; Tue, 25 Sep 2012 07:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.004 X-Spam-Level: X-Spam-Status: No, score=-0.004 tagged_above=-999 required=5 tests=[AWL=0.826, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qpCIBJ32V5aD for ; Tue, 25 Sep 2012 07:20:19 -0700 (PDT) Received: from rzjgate.joanneum.ac.at (rzjgate.joanneum.ac.at [143.224.185.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA0AF21F889D for ; Tue, 25 Sep 2012 07:20:18 -0700 (PDT) Received: from RZJS077.jr1.local (rzjs077.joanneum.ac.at [143.224.71.18]) by rzjgate.joanneum.ac.at (8.13.8/8.13.8) with ESMTP id q8PEK82w013388; Tue, 25 Sep 2012 16:20:09 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joanneum.at; s=sel3; t=1348582809; bh=l/heH+bE72ZT+rLDCUdZCgKOM3nALNaVm/xBRLjMGGo=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=rmuUS7XnSYZCiPAaku/09UkUewkF89qyfPNhapJ8z8WLwCWMcEMssGZvmb1iWDfvE 1xHgkdcQmnSXCQZ6Yldo4/ew3Xe6yVxdCVRChcif78DvpjqTVHhMk3JAAZ3PdMKAGj LNMnmBp39NaTBMgsAAToJbMJ9qS7yhNaHAj3Z1QU= Received: from RZJC1EX.jr1.local ([169.254.2.9]) by RZJS077.jr1.local ([143.224.71.18]) with mapi; Tue, 25 Sep 2012 16:20:08 +0200 From: "Marksteiner, Stefan" To: IPv6 Ops WG Date: Tue, 25 Sep 2012 16:18:59 +0200 Thread-Topic: [v6ops] Operational guidelines for a company/organization IPv6 address scheme supplemental to RFC5157 Thread-Index: Ac2bIan9fJkY23LORwWxgmEFHWwGPAABwrdL Message-ID: <8A317FD8C00FEE448E52D4EE5B56BB3E0232A086D90A@RZJC1EX.jr1.local> References: <8A317FD8C00FEE448E52D4EE5B56BB3E0232A086D8FF@RZJC1EX.jr1.local>, <1348519034.47465.YahooMailNeo@web32503.mail.mud.yahoo.com> <8A317FD8C00FEE448E52D4EE5B56BB3E0232A086D902@RZJC1EX.jr1.local>, <5061B157.1090106@gmail.com> In-Reply-To: <5061B157.1090106@gmail.com> Accept-Language: de-DE, de-AT Content-Language: de-AT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, de-AT Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] Operational guidelines for a company/organization IPv6 address scheme supplemental to RFC5157 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 14:20:20 -0000 Hi Brian, SLAAC is *somewhat* predictable, especially when you already have one addre= ss as a starting point (then you've got a vendor ID plus a probable batch w= hich narrows the scanning address room significantly). Of course I assume workstation machines not to be in public a DNS zone... Regards, Stefan ________________________________________ Von: Brian E Carpenter [brian.e.carpenter@gmail.com] Gesendet: Dienstag, 25. September 2012 15:27 An: Marksteiner, Stefan Cc: Mark ZZZ Smith; IPv6 Ops WG Betreff: Re: [v6ops] Operational guidelines for a company/organization IPv6= address scheme supplemental to RFC5157 On 25/09/2012 10:42, Marksteiner, Stefan wrote: > Hi Mark, > > First of all I think I've forgotten to clarify that I'm talking about IID= s, sorry ;) > The aim of my thoughts would be to make it harder for externals to scan f= or attackable addresses. One often cited (mostly by marketeers) benefit of = IPv6 is the vast amount of addresses per subnet making it seemingly harder = to scan, which would be nullified if companies used simple sequential addre= ssing. > > You're of course right that most (potential) attackers are insiders - but= they likely wouldn't have to scan anyway, instead the would probably alrea= dy have knowledge of alive (and maybe even vulnerable) hosts. Thus, they ar= en't my focus in this matter, but instead are "black box"-scanners and Inte= rnet worms. > > ULA/LLA are, as you've correctly stated, the best choice if you don't nee= d Internet connection, but what about workstations for employees needing th= e Internet? > > I'm suggesting to recommend companies to use a different scheme as ::1;::= 2 or ::BABE;::CAFE or even ::4593;4594 and so on which according to some st= udies (e.g. [1], pp.65-75, especially 68) most administrators unfortunately= do. > What might be needed to change this would be a scheme which is practicabl= y administrable in the easiest possible way. It depends what you mean by "administrable" but SLAAC doesn't need a scheme and therefore doesn't need administration. For machines that are in public = DNS it doesn't matter anyway, so any scheme will do. Brian > This would have, in my opinion, two benefits. Firstly it would render sta= ndard scanning procedures for IPv6 like sequential scanning and scanning fo= r "funny" addresses pretty much useless. Secondly, if the numbers are, seen= from the outside, seemingly random, it wouldn't help a scanner or worm if = he or it discovered a single address by chance (e.g. by a log entry) and to= ok it as a starting point for further scanning. > > I'm aware of the discussions about security by obscurity and that a good = firewall is needed anyway to secure internal assets, but I would find it ni= ce if the often cited "security argument" that IPv6 subnets are merely impo= ssible to scan would be true (again) :) > > > Cheers, > > Stefan > > > [1]http://www.mh-sec.de/downloads/mh-ipv6_vulnerabilities.pdf > ________________________________________ > Von: Mark ZZZ Smith [markzzzsmith@yahoo.com.au] > Gesendet: Montag, 24. September 2012 22:37 > An: Marksteiner, Stefan; IPv6 Ops WG > Betreff: Re: [v6ops] Operational guidelines for a company/organization IP= v6 address scheme supplemental to RFC5157 > > Hi Stefan, > > ----- Original Message ----- > >> From: "Marksteiner, Stefan" >> To: IPv6 Ops WG >> Cc: >> Sent: Tuesday, 25 September 2012 4:03 AM >> Subject: [v6ops] Operational guidelines for a company/organization IPv6 = address scheme supplemental to RFC5157 >> >> >> Hi Folks, >> >> RFC5157 presents hazards of sequentially numbering IPv6 networks and tec= hnical >> means (like CGAs and privacy extensions) to mitigate them. Unfortunately= these >> mitigation methods may be deemed difficult to handle for administrators = (SEND >> may be too complicated to implement, PEs bring difficulties to keep trac= k of IP >> addresses). Therefore there may be demand for an addressing scheme (rath= er than >> a technical method) that makes IPv6 addresses easy to predict for tech s= taff but >> difficult to do so by outsiders, building a low-end supplement for the m= ethods >> mentioned in RFC5157. > > > I think it might be worth having a bit more of a think about who might be= inclined to attack you - for a typical non-Internet services organisation,= I think it's more likely going to be > disgruntled ex-staff, and it'll be hard to make them forget "numbers" / a= ddresses or prevent them copying the mapping application if they have an in= kling they're going to get fired. > > >> > >> What I have in mind is an simple mental arithmetic operation, which gene= rates an >> address out of a company fixed part plus a sequential number for host. >> Alternatively a Hash-Operation consisting again of a secret organisation= al plus >> a sequential host number. The first requires the scheme to be slightly d= ifferent >> in every organisation in order to have a negative impact on IPv6 scannin= g from >> external sources, the second is more secure but requires an internal web= site or >> smartphone app in order for field engineers to calculate an address out = of the >> sequential information. >> > > It sounds like here you're talking about a subnet numbering scheme. The c= ommon prefix size for most organisations is going to be /56 or 256 /64 subn= ets, or /48 or 65K /64 subnets. Many providers seem to be leaning towards /= 56s unless their customers ask for a /48, which provides very little addres= s space to effectively hide the in-use subnet numbers from a scanning based= attack (and that's one of the reasons why I'd be giving customers /48s fro= m the outset). One advantage though of IPv6 is that it is possible to phase= in and phase out addressing using the address/prefix lifetimes mechanism, = so it would be possible to change assigned in your network prefixes on e.g.= a weekly basis. > > If your fundamental goal is to make internal links unreachable from the I= nternet, they can be not assigned a global prefix, and numbered from either= the ULA address space (RFC4193) or left as link-locals only ("unnumbered")= . You may be interested in the following, which discusses link-local only a= ddressing - > > "Using Only Link-Local Addressing Inside an IPv6 Network" > http://tools.ietf.org/html/draft-behringer-lla-only-01 > > > Regards, > > Mark. > >> My question is, in your opinion, would this be worthwhile to be formulat= ed as an >> ID an be drafted or does this idea sound absurd? >> >> > >> Cheers, >> >> Stefan >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From internet-drafts@ietf.org Tue Sep 25 08:19:33 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2156121F886F; Tue, 25 Sep 2012 08:19:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id shhMM3BVma19; Tue, 25 Sep 2012 08:19:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 441E121F889D; Tue, 25 Sep 2012 08:19:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120925151932.27238.7903.idtracker@ietfa.amsl.com> Date: Tue, 25 Sep 2012 08:19:32 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-11.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 15:19:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Basic Requirements for IPv6 Customer Edge Routers Author(s) : Hemant Singh Wes Beebee Chris Donley Barbara Stark Filename : draft-ietf-v6ops-6204bis-11.txt Pages : 22 Date : 2012-09-25 Abstract: This document specifies requirements for an IPv6 Customer Edge (CE) router. Specifically, the current version of this document focuses on the basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it. The document also covers IP transition technologies. Two transition technologies in RFC 5969's 6rd and RFC 6333's DS-Lite are covered in the document. The document obsoletes RFC 6204, if approved. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-6204bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-6204bis-11 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jouni.nospam@gmail.com Tue Sep 25 09:05:51 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B76921F87E1 for ; Tue, 25 Sep 2012 09:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.117 X-Spam-Level: X-Spam-Status: No, score=-3.117 tagged_above=-999 required=5 tests=[AWL=-0.345, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGF5TGoTt6+s for ; Tue, 25 Sep 2012 09:05:50 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC8A21F87C9 for ; Tue, 25 Sep 2012 09:05:49 -0700 (PDT) Received: by eaak13 with SMTP id k13so847166eaa.31 for ; Tue, 25 Sep 2012 09:05:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=pp1tfQY7CrsmuuPlchR2tWqIHodb5S4kUoIHVRFLyvM=; b=wqhv9YXJhepsfG6s2S8EtTTk59+zJtpMvvvcfofpBX9KZFevm+4Gte9/HZirch7QHy lHUq5nIkJgsvtnVynUSMBJDgKQrF9thpAPaO91+O41Ndzh9K5vHVy1s7GkgkGOB0IKJE ZKf7WuVLODolsOH4eUzmkWjAqV0zk6yn0kO4sjhWFWa9fuRAmDSvgwrBNHe1531O79ce 0UQu5IZzLiwJnquqqXDoZm3HMUybhjn0sADyDljsQeTyZ+bnSlt2wIGccBXY7oKeFw7l 70J0IlOtTB2HNkRFLGR1PK9OakuWKyjPAbFL7l7EH/p1iAVp+NONlVjSRZXL9ubhXg6h Lnjw== Received: by 10.14.205.9 with SMTP id i9mr9602008eeo.21.1348589148944; Tue, 25 Sep 2012 09:05:48 -0700 (PDT) Received: from ?IPv6:2001:67c:64:42:226:bbff:fe18:6e9c? ([2001:67c:64:42:226:bbff:fe18:6e9c]) by mx.google.com with ESMTPS id n17sm896072bks.6.2012.09.25.09.05.34 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 25 Sep 2012 09:05:46 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Tue, 25 Sep 2012 19:05:31 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <9324A213-CC67-4BB1-A99E-E40AA537853E@gmail.com> References: <1B2E7539FECD9048B261B791B1B24A7C3EBE458308@PUEXCB1A.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E5B123A8C@PUEXCB1B.nanterre.francetelecom.fr> <20120925133859.15A2.8FE1F57E@jpix.ad.jp>, <523CF185-5C72-4299-B4DA-3CEDBA7466D3@gmail.com> To: Rajiv Asati (rajiva) X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 16:05:51 -0000 Rajiv, On Sep 25, 2012, at 2:53 PM, Rajiv Asati (rajiva) wrote: > Jouni, >=20 > Trying to make sense of 3GPP's thought process here - =20 Is there any sense in it?=20 > * rel 10 includes DHCPv6 for PD, rel 11 keeps DHCPv6 (for NA!) = optional. >=20 > * SLAAC is included (rel 8 onwards!), but complimentary RDNS stays = excluded. SLAAC has been there since like rel-99. > I guess 'simplification' is very subjective. ;-) ;) - Jouni >=20 > Cheers, > Rajiv >=20 > Sent from my Phone >=20 > On Sep 25, 2012, at 4:04 AM, "jouni korhonen" = wrote: >=20 >>=20 >> On Sep 25, 2012, at 7:39 AM, MAWATARI Masataka wrote: >>=20 >>> Dear authors, >>>=20 >>> I read throuth your draft. >>>=20 >>> Comment about REQ#6 and REQ#7 on -02 version regarding conveying >>> DNS server. >>>=20 >>> I heard that both of DHCPv6 client and RA options is not common on >>> 3GPP mobile network at least for now. >>=20 >> Specific to 3GPP, its "NAS" layer can deliver the mobile the DNS = server >> address among several other configuration things. Since NAS is in = 3GPP's >> hands it somehow gets preferred.. Currently as for Release-11 DHCPv6 = is >> still optional and RDNS is not there at all. >>=20 >>> This document describes that if RA options is not supported, the >>> cellular host should embed DHCPv6 client. Will RA options have >>> more appreciated than DHCPv6 client on mobile? However, both >>> requirements have same SHOULD. >>>=20 >>> Such a document should provide the clear preference and reasons >>> about that, in my opinion. >>=20 >> The preference ordering is in the text already in a way in req#7 it >> seems but could be more clear/strict. >>=20 >> - Jouni >>=20 >>=20 >>=20 >>>=20 >>>=20 >>> Kind Regards, >>> Masataka MAWATARI >>>=20 >>>=20 >>> * On Mon, 24 Sep 2012 15:12:56 +0200 >>> * wrote: >>>=20 >>>> Re-, >>>>=20 >>>> We submitted a new version of the I-D integrating the comments = received in the list. In particular, the following changes are made in = -02: >>>>=20 >>>> * DNS64 requirement is now a SHOULD as suggested by Ted >>>> * Add a new requirement to RFC5555 as suggested by H. Soliman >>>> * Remove the requirement about ND Proxy but instead a new paragraph = has been added to describe the problem raised to share /64 >>>> * Add a new requirement for RFC4191 as suggested by L. Colliti, = Behcet and Jouni >>>> * Correct a typo about DHCP client (3315). >>>> * Welcome new co-authors >>>>=20 >>>> A detailed diff is available at: = http://www.ietf.org/rfcdiff?url2=3Ddraft-binet-v6ops-cellular-host-reqs-rf= c3316update-02 >>>>=20 >>>> The new version is available at: = http://tools.ietf.org/id/draft-binet-v6ops-cellular-host-reqs-rfc3316updat= e-02.txt >>>>=20 >>>> Cheers, >>>> Med >>>=20 >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops From markzzzsmith@yahoo.com.au Tue Sep 25 12:42:24 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 417BD21F8897 for ; Tue, 25 Sep 2012 12:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.292 X-Spam-Level: X-Spam-Status: No, score=-0.292 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xtHT735uMkXM for ; Tue, 25 Sep 2012 12:42:22 -0700 (PDT) Received: from nm7-vm0.bullet.mail.ac4.yahoo.com (nm7-vm0.bullet.mail.ac4.yahoo.com [98.139.52.228]) by ietfa.amsl.com (Postfix) with SMTP id 5B2EC21F8873 for ; Tue, 25 Sep 2012 12:42:22 -0700 (PDT) Received: from [98.139.52.194] by nm7.bullet.mail.ac4.yahoo.com with NNFMP; 25 Sep 2012 19:42:15 -0000 Received: from [98.139.52.154] by tm7.bullet.mail.ac4.yahoo.com with NNFMP; 25 Sep 2012 19:42:15 -0000 Received: from [127.0.0.1] by omp1037.mail.ac4.yahoo.com with NNFMP; 25 Sep 2012 19:42:15 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 760757.44403.bm@omp1037.mail.ac4.yahoo.com Received: (qmail 74280 invoked by uid 60001); 25 Sep 2012 19:42:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1348602135; bh=PLQUdb4bis+PFuX725ZEVGwSDe403fRA6YsvlzDGtL0=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=xOVHaTQ0I0v9PnbyAi8FgNH/c2OIbDs5/7Jj/KDUhEtZoL9Su8ubUWBuU3DF2wNoYaTQqIVZYXeXrGwKdG+Daj4sI4xup8/SJSeiMlYhX/C7+23b6RILsdRXwrOh89nRpmPHUwqEDjIQWU/k2mxp6uYVaZgAWARmO5QnCmJxAfw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=D0ZAIlABbQt4RucgWWfeEFiNeZ+ES+bJjKUFL2yzXIeIkz7ORqWxu5AJMxwSbNhg5svCeNJRRmeUZrXsTMOu1oMnBudziQ6KUjawcNSIrp3NZHf6GOWcreMM3jisS27sWWF+cAXBA+6WuXv5rvtIzBGnvZwkCpd53+Z3IKe7c8U=; X-YMail-OSG: MR35_6YVM1k_tGGZFxUO9gwUKMFhpnLp6os2yJXkLF1Skqk XudI3I_YPZOpURXVLQaXxNic3lzG9HvfXiS5KLD7rOVW8K0SfJHpUDAzdmFg Ryb2mkkFxAa5aG_5FzvPJOnbZwCdd_dTB_rh2obGrKPLg0OQkkEOsF3Hh0IB pps4hIy2_V9L59BDGWM4ujbTVnuE6huTTu3tXVrU_xwZjGO6DjBnkX4vH6Sp 8zabUODr94UWYZCl3GSKeAB8zEoZtonN6jVK4HU0sfS7A3kBWMfPbWCwc_B8 xbEAQgNbbbUMOMmRgMQ63fEJCdBhi5FYhOjBgdyTfY3FvKwh4E871vMEfgcX ZuRfdZv9yFPEVp7MNf6op7gc6m7iOrBDon0RCKn_Nge9eSZnCIWOeD6Yrjsl DdDeWP4nw3o9ODvJeVavLEAo8WV5dmMTTgR57XrYc50kqfdFZR0R_eH_jV9y bKtPgFrdHpGEVkXYO6wqQy3AhYlvCzRsz_yk7vZsUflSuees_9DMZVLASU6J 8gw2.bpxuul2jq6EdDOb4njA6TpQcg68WehHS8BDK7axZYN_u2CzLHRCBKSS z.euqRPh2SIFf0b59GDHq9ztOocOhbs6gZHZk6ZmJxowOQn2JEd5InXxPlQ- - Received: from [150.101.221.237] by web32505.mail.mud.yahoo.com via HTTP; Tue, 25 Sep 2012 12:42:14 PDT X-Mailer: YahooMailWebService/0.8.121.434 References: <8A317FD8C00FEE448E52D4EE5B56BB3E0232A086D8FF@RZJC1EX.jr1.local>, <1348519034.47465.YahooMailNeo@web32503.mail.mud.yahoo.com> <8A317FD8C00FEE448E52D4EE5B56BB3E0232A086D902@RZJC1EX.jr1.local>, <5061B157.1090106@gmail.com> <8A317FD8C00FEE448E52D4EE5B56BB3E0232A086D90A@RZJC1EX.jr1.local> Message-ID: <1348602134.63605.YahooMailNeo@web32505.mail.mud.yahoo.com> Date: Tue, 25 Sep 2012 12:42:14 -0700 (PDT) From: Mark ZZZ Smith To: "Marksteiner, Stefan" , IPv6 Ops WG In-Reply-To: <8A317FD8C00FEE448E52D4EE5B56BB3E0232A086D90A@RZJC1EX.jr1.local> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [v6ops] Operational guidelines for a company/organization IPv6 address scheme supplemental to RFC5157 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Mark ZZZ Smith List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 19:42:24 -0000 =0A=0A=0A=0A----- Original Message -----=0A> From: "Marksteiner, Stefan" =0A> To: IPv6 Ops WG =0A> Cc:= Mark ZZZ Smith =0A> Sent: Wednesday, 26 Septemb= er 2012 12:18 AM=0A> Subject: AW: [v6ops] Operational guidelines for a comp= any/organization IPv6 address scheme supplemental to RFC5157=0A> =0A> Hi Br= ian,=0A> =0A> SLAAC is *somewhat* predictable, especially when you already = have one address as =0A> a starting point (then you've got a vendor ID plus= a probable batch which =0A> narrows the scanning address room significantl= y).=0A> Of course I assume workstation machines not to be in public a DNS z= one...=0A>=A0=0A=0ASo if you want unpredictable, you use privacy addresses.= They're not hard to enable, and in some cases (recent Windows OSes, Fedora= 17) they're enabled by default.=0A=0AIf you've chosen to go down the state= ful DHCPv6 path, I'd verify what sort of allocation scheme it uses or can b= e enabled - there may and perhaps will likely be a "random" option.=0A=0AWh= at problem are you trying to solve by having technical staff being able to = determine addresses? Is it to record addresses in use? Or address utilisati= on within the subnet?=0A=0ARegards,=0AMark.=0A=0A> Regards,=0A> =0A> Stefan= =0A> =0A> =0A> ________________________________________=0A> Von: Brian E Ca= rpenter [brian.e.carpenter@gmail.com]=0A> Gesendet: Dienstag, 25. September= 2012 15:27=0A> An: Marksteiner, Stefan=0A> Cc: Mark ZZZ Smith; IPv6 Ops WG= =0A> Betreff: Re: [v6ops] Operational guidelines for a company/organization= IPv6 =0A> address scheme supplemental to RFC5157=0A> =0A> On 25/09/2012 10= :42, Marksteiner, Stefan wrote:=0A>> Hi Mark,=0A>> =0A>> First of all I t= hink I've forgotten to clarify that I'm talking =0A> about IIDs, sorry ;)= =0A>> The aim of my thoughts would be to make it harder for externals to s= can for =0A> attackable addresses. One often cited (mostly by marketeers) b= enefit of IPv6 is =0A> the vast amount of addresses per subnet making it se= emingly harder to scan, =0A> which would be nullified if companies used sim= ple sequential addressing.=0A>> =0A>> You're of course right that most (po= tential) attackers are insiders - =0A> but they likely wouldn't have to sca= n anyway, instead the would probably =0A> already have knowledge of alive (= and maybe even vulnerable) hosts. Thus, they =0A> aren't my focus in this m= atter, but instead are "black =0A> box"-scanners and Internet worms.=0A>> = =0A>> ULA/LLA are, as you've correctly stated, the best choice if you =0A>= don't need Internet connection, but what about workstations for employees = =0A> needing the Internet?=0A>> =0A>> I'm suggesting to recommend companie= s to use a different scheme as =0A> ::1;::2 or ::BABE;::CAFE or even ::4593= ;4594 and so on which according to some =0A> studies (e.g. [1], pp.65-75, e= specially 68) most administrators unfortunately =0A> do.=0A>> What might b= e needed to change this would be a scheme which is practicably =0A> adminis= trable in the easiest possible way.=0A> =0A> It depends what you mean by "a= dministrable" but SLAAC doesn't need =0A> a scheme=0A> and therefore doesn'= t need administration. For machines that are in public =0A> DNS=0A> it does= n't matter anyway, so any scheme will do.=0A> =0A> =A0 =A0 Brian=0A> =0A>> = This would have, in my opinion, two benefits. Firstly it would render =0A>= standard scanning procedures for IPv6 like sequential scanning and scannin= g for =0A> "funny" addresses pretty much useless. Secondly, if the numbers = are, =0A> seen from the outside, seemingly random, it wouldn't help a scann= er or worm =0A> if he or it discovered a single address by chance (e.g. by = a log entry) and took =0A> it as a starting point for further scanning.=0A>= > =0A>> I'm aware of the discussions about security by obscurity and that = a =0A> good firewall is needed anyway to secure internal assets, but I woul= d find it =0A> nice if the often cited "security argument" that IPv6 subnet= s are =0A> merely impossible to scan would be true (again) :)=0A>> =0A>> = =0A>> Cheers,=0A>> =0A>> Stefan=0A>> =0A>> =0A>> [1]http://www.mh-sec.de= /downloads/mh-ipv6_vulnerabilities.pdf=0A>> ______________________________= __________=0A>> Von: Mark ZZZ Smith [markzzzsmith@yahoo.com.au]=0A>> Gese= ndet: Montag, 24. September 2012 22:37=0A>> An: Marksteiner, Stefan; IPv6 = Ops WG=0A>> Betreff: Re: [v6ops] Operational guidelines for a company/orga= nization IPv6 =0A> address scheme supplemental to RFC5157=0A>> =0A>> Hi St= efan,=0A>> =0A>> ----- Original Message -----=0A>> =0A>>> From: "Markstei= ner, Stefan" =0A> =0A>>> To: IPv6 Ops WG <= v6ops@ietf.org>=0A>>> Cc:=0A>>> Sent: Tuesday, 25 September 2012 4:03 AM= =0A>>> Subject: [v6ops] Operational guidelines for a company/organization = IPv6 =0A> address scheme supplemental to RFC5157=0A>>> =0A>>> =0A>>> Hi Fo= lks,=0A>>> =0A>>> RFC5157 presents hazards of sequentially numbering IPv6 = networks and =0A> technical=0A>>> means (like CGAs and privacy extensions)= to mitigate them. =0A> Unfortunately these=0A>>> mitigation methods may b= e deemed difficult to handle for administrators =0A> (SEND=0A>>> may be to= o complicated to implement, PEs bring difficulties to keep =0A> track of IP= =0A>>> addresses). Therefore there may be demand for an addressing scheme = =0A> (rather than=0A>>> a technical method) that makes IPv6 addresses easy= to predict for tech =0A> staff but=0A>>> difficult to do so by outsiders,= building a low-end supplement for the =0A> methods=0A>>> mentioned in RFC= 5157.=0A>> =0A>> =0A>> I think it might be worth having a bit more of a th= ink about who might be =0A> inclined to attack you - for a typical non-Inte= rnet services organisation, I =0A> think it's more likely going to be=0A>> = disgruntled ex-staff, and it'll be hard to make them forget =0A> "numbers"= / addresses or prevent them copying the mapping application =0A> if they h= ave an inkling they're going to get fired.=0A>> =0A>> =0A>>> =0A>> =0A>>> = What I have in mind is an simple mental arithmetic operation, which =0A> ge= nerates an=0A>>> address out of a company fixed part plus a sequential num= ber for host.=0A>>> Alternatively a Hash-Operation consisting again of a s= ecret =0A> organisational plus=0A>>> a sequential host number. The first r= equires the scheme to be slightly =0A> different=0A>>> in every organisati= on in order to have a negative impact on IPv6 =0A> scanning from=0A>>> ext= ernal sources, the second is more secure but requires an internal =0A> web = site or=0A>>> smartphone app in order for field engineers to calculate an = address out =0A> of the=0A>>> sequential information.=0A>>> =0A>> =0A>> I= t sounds like here you're talking about a subnet numbering scheme. The =0A>= common prefix size for most organisations is going to be /56 or 256 /64 su= bnets, =0A> or /48 or 65K /64 subnets. Many providers seem to be leaning to= wards /56s unless =0A> their customers ask for a /48, which provides very l= ittle address space to =0A> effectively hide the in-use subnet numbers from= a scanning based attack (and =0A> that's one of the reasons why I'd be giv= ing customers /48s from the =0A> outset). One advantage though of IPv6 is t= hat it is possible to phase in and =0A> phase out addressing using the addr= ess/prefix lifetimes mechanism, so it would =0A> be possible to change assi= gned in your network prefixes on e.g. a weekly basis.=0A>> =0A>> If your f= undamental goal is to make internal links unreachable from the =0A> Interne= t, they can be not assigned a global prefix, and numbered from either the = =0A> ULA address space (RFC4193) or left as link-locals only =0A> ("unnumbe= red"). You may be interested in the following, which =0A> discusses link-lo= cal only addressing -=0A>> =0A>> "Using Only Link-Local Addressing Inside = an IPv6 Network"=0A>> http://tools.ietf.org/html/draft-behringer-lla-only-= 01=0A>> =0A>> =0A>> Regards,=0A>> =0A>> Mark.=0A>> =0A>>> My question is= , in your opinion, would this be worthwhile to be =0A> formulated as an=0A>= >> ID an be drafted or does this idea sound absurd?=0A>>> =0A>>> =0A>> =0A= >>> Cheers,=0A>>> =0A>>> Stefan=0A>>> __________________________________= _____________=0A>>> v6ops mailing list=0A>>> v6ops@ietf.org=0A>>> https:= //www.ietf.org/mailman/listinfo/v6ops=0A>>> =0A>> ________________________= _______________________=0A>> v6ops mailing list=0A>> v6ops@ietf.org=0A>> = https://www.ietf.org/mailman/listinfo/v6ops=0A>> =0A> From stefan.marksteiner@joanneum.at Wed Sep 26 00:16:23 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D040821F868A for ; Wed, 26 Sep 2012 00:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.28 X-Spam-Level: X-Spam-Status: No, score=-0.28 tagged_above=-999 required=5 tests=[AWL=0.550, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jO5uEqev7-nu for ; Wed, 26 Sep 2012 00:16:22 -0700 (PDT) Received: from rzjgate.joanneum.ac.at (rzjgate.joanneum.ac.at [143.224.185.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA6821F8679 for ; Wed, 26 Sep 2012 00:16:21 -0700 (PDT) Received: from RZJS077.jr1.local (rzjs077.joanneum.ac.at [143.224.71.18]) by rzjgate.joanneum.ac.at (8.13.8/8.13.8) with ESMTP id q8Q7GCcD001529; Wed, 26 Sep 2012 09:16:13 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joanneum.at; s=sel3; t=1348643773; bh=CdxtiR8OFY8ZztjYAU1tHx5vds2ECR4Ee00SOxfCQws=; h=From:To:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=Abc5pEs/qHqUAIDu34A6ihPuFYynpn38IvMOzQPqb0JA7Q6VJy1q/SysfYQmriRGd 5dj49Z8jAgiCdxGex9lL54jyaGzx0DHFith76r+soYaM3vlAe2WFPIiBIxDwDEXN8n ylpLpbuKQbLpFbpojPkwKIqpo1NHfOjvNHFFwAZs= Received: from RZJC1EX.jr1.local ([169.254.2.9]) by RZJS077.jr1.local ([143.224.71.18]) with mapi; Wed, 26 Sep 2012 09:16:12 +0200 From: "Marksteiner, Stefan" To: "'Mark ZZZ Smith'" , "'IPv6 Ops WG'" Date: Wed, 26 Sep 2012 09:16:12 +0200 Thread-Topic: AW: [v6ops] Operational guidelines for a company/organization IPv6 address scheme supplemental to RFC5157 Thread-Index: Ac2bVeBEtEsgndt0SaaK3WVOyspJ9QAXugkg Message-ID: <8A317FD8C00FEE448E52D4EE5B56BB3E0232A08499BB@RZJC1EX.jr1.local> References: <8A317FD8C00FEE448E52D4EE5B56BB3E0232A086D8FF@RZJC1EX.jr1.local>, <1348519034.47465.YahooMailNeo@web32503.mail.mud.yahoo.com> <8A317FD8C00FEE448E52D4EE5B56BB3E0232A086D902@RZJC1EX.jr1.local>, <5061B157.1090106@gmail.com> <8A317FD8C00FEE448E52D4EE5B56BB3E0232A086D90A@RZJC1EX.jr1.local> <1348602134.63605.YahooMailNeo@web32505.mail.mud.yahoo.com> In-Reply-To: <1348602134.63605.YahooMailNeo@web32505.mail.mud.yahoo.com> Accept-Language: de-DE, de-AT Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, de-AT Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] Operational guidelines for a company/organization IPv6 address scheme supplemental to RFC5157 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 07:16:24 -0000 Hi, There's a variety of reasons to keep track of addresses from usage and stat= istics to forensic purposes in security incidents (also those which are per= petrated from inside sources to outside targets). Privacy extensions would perhaps be too unpredictable to manage, but statef= ul DHCPv6 combined with a suitable IPAM-solution would probably do the tric= k. Maybe I have been stuck in my mindset a little, as we use only static addr= esses in our productive IPv4 network.=20 Thanks :) Cheers, Stefan -----Urspr=FCngliche Nachricht----- Von: Mark ZZZ Smith [mailto:markzzzsmith@yahoo.com.au]=20 Gesendet: Dienstag, 25. September 2012 21:42 An: Marksteiner, Stefan; IPv6 Ops WG Betreff: Re: AW: [v6ops] Operational guidelines for a company/organization = IPv6 address scheme supplemental to RFC5157 ----- Original Message ----- > From: "Marksteiner, Stefan" > To: IPv6 Ops WG > Cc: Mark ZZZ Smith > Sent: Wednesday, 26 September 2012 12:18 AM > Subject: AW: [v6ops] Operational guidelines for a company/organization=20 > IPv6 address scheme supplemental to RFC5157 >=20 > Hi Brian, >=20 > SLAAC is *somewhat* predictable, especially when you already have one=20 > address as a starting point (then you've got a vendor ID plus a=20 > probable batch which narrows the scanning address room significantly). > Of course I assume workstation machines not to be in public a DNS zone... >=A0 So if you want unpredictable, you use privacy addresses. They're not hard t= o enable, and in some cases (recent Windows OSes, Fedora 17) they're enable= d by default. If you've chosen to go down the stateful DHCPv6 path, I'd verify what sort = of allocation scheme it uses or can be enabled - there may and perhaps will= likely be a "random" option. What problem are you trying to solve by having technical staff being able t= o determine addresses? Is it to record addresses in use? Or address utilisa= tion within the subnet? Regards, Mark. > Regards, >=20 > Stefan >=20 >=20 > ________________________________________ > Von: Brian E Carpenter [brian.e.carpenter@gmail.com] > Gesendet: Dienstag, 25. September 2012 15:27 > An: Marksteiner, Stefan > Cc: Mark ZZZ Smith; IPv6 Ops WG > Betreff: Re: [v6ops] Operational guidelines for a company/organization=20 > IPv6 address scheme supplemental to RFC5157 >=20 > On 25/09/2012 10:42, Marksteiner, Stefan wrote: >> Hi Mark, >>=20 >> First of all I think I've forgotten to clarify that I'm talking > about IIDs, sorry ;) >> The aim of my thoughts would be to make it harder for externals to=20 >> scan for > attackable addresses. One often cited (mostly by marketeers) benefit=20 > of IPv6 is the vast amount of addresses per subnet making it seemingly=20 > harder to scan, which would be nullified if companies used simple sequent= ial addressing. >>=20 >> You're of course right that most (potential) attackers are insiders=20 >> - > but they likely wouldn't have to scan anyway, instead the would=20 > probably already have knowledge of alive (and maybe even vulnerable)=20 > hosts. Thus, they aren't my focus in this matter, but instead are=20 > "black box"-scanners and Internet worms. >>=20 >> ULA/LLA are, as you've correctly stated, the best choice if you > don't need Internet connection, but what about workstations for=20 > employees needing the Internet? >>=20 >> I'm suggesting to recommend companies to use a different scheme as > ::1;::2 or ::BABE;::CAFE or even ::4593;4594 and so on which according=20 > to some studies (e.g. [1], pp.65-75, especially 68) most=20 > administrators unfortunately do. >> What might be needed to change this would be a scheme which is=20 >> practicably > administrable in the easiest possible way. >=20 > It depends what you mean by "administrable" but SLAAC doesn't need a=20 > scheme and therefore doesn't need administration. For machines that=20 > are in public DNS it doesn't matter anyway, so any scheme will do. >=20 > =A0 =A0 Brian >=20 >> This would have, in my opinion, two benefits. Firstly it would=20 >> render > standard scanning procedures for IPv6 like sequential scanning and=20 > scanning for "funny" addresses pretty much useless. Secondly, if the=20 > numbers are, seen from the outside, seemingly random, it wouldn't help=20 > a scanner or worm if he or it discovered a single address by chance=20 > (e.g. by a log entry) and took it as a starting point for further scannin= g. >>=20 >> I'm aware of the discussions about security by obscurity and that a > good firewall is needed anyway to secure internal assets, but I would=20 > find it nice if the often cited "security argument" that IPv6 subnets=20 > are merely impossible to scan would be true (again) :) >>=20 >>=20 >> Cheers, >>=20 >> Stefan >>=20 >>=20 >> [1]http://www.mh-sec.de/downloads/mh-ipv6_vulnerabilities.pdf >> ________________________________________ >> Von: Mark ZZZ Smith [markzzzsmith@yahoo.com.au] >> Gesendet: Montag, 24. September 2012 22:37 >> An: Marksteiner, Stefan; IPv6 Ops WG >> Betreff: Re: [v6ops] Operational guidelines for a=20 >> company/organization IPv6 > address scheme supplemental to RFC5157 >>=20 >> Hi Stefan, >>=20 >> ----- Original Message ----- >>=20 >>> From: "Marksteiner, Stefan"=20 > >>> To: IPv6 Ops WG >>> Cc: >>> Sent: Tuesday, 25 September 2012 4:03 AM >>> Subject: [v6ops] Operational guidelines for a company/organization=20 >>> IPv6 > address scheme supplemental to RFC5157 >>>=20 >>>=20 >>> Hi Folks, >>>=20 >>> RFC5157 presents hazards of sequentially numbering IPv6 networks=20 >>> and > technical >>> means (like CGAs and privacy extensions) to mitigate them.=20 > Unfortunately these >>> mitigation methods may be deemed difficult to handle for=20 >>> administrators > (SEND >>> may be too complicated to implement, PEs bring difficulties to keep > track of IP >>> addresses). Therefore there may be demand for an addressing scheme > (rather than >>> a technical method) that makes IPv6 addresses easy to predict for=20 >>> tech > staff but >>> difficult to do so by outsiders, building a low-end supplement for=20 >>> the > methods >>> mentioned in RFC5157. >>=20 >>=20 >> I think it might be worth having a bit more of a think about who=20 >> might be > inclined to attack you - for a typical non-Internet services=20 > organisation, I think it's more likely going to be >> disgruntled ex-staff, and it'll be hard to make them forget > "numbers" / addresses or prevent them copying the mapping application=20 > if they have an inkling they're going to get fired. >>=20 >>=20 >>>=20 >>=20 >>> What I have in mind is an simple mental arithmetic operation, which > generates an >>> address out of a company fixed part plus a sequential number for host. >>> Alternatively a Hash-Operation consisting again of a secret > organisational plus >>> a sequential host number. The first requires the scheme to be=20 >>> slightly > different >>> in every organisation in order to have a negative impact on IPv6 > scanning from >>> external sources, the second is more secure but requires an=20 >>> internal > web site or >>> smartphone app in order for field engineers to calculate an address=20 >>> out > of the >>> sequential information. >>>=20 >>=20 >> It sounds like here you're talking about a subnet numbering scheme.=20 >> The > common prefix size for most organisations is going to be /56 or 256=20 > /64 subnets, or /48 or 65K /64 subnets. Many providers seem to be=20 > leaning towards /56s unless their customers ask for a /48, which=20 > provides very little address space to effectively hide the in-use=20 > subnet numbers from a scanning based attack (and that's one of the=20 > reasons why I'd be giving customers /48s from the outset). One=20 > advantage though of IPv6 is that it is possible to phase in and phase=20 > out addressing using the address/prefix lifetimes mechanism, so it would = be possible to change assigned in your network prefixes on e.g. a weekly ba= sis. >>=20 >> If your fundamental goal is to make internal links unreachable from=20 >> the > Internet, they can be not assigned a global prefix, and numbered from=20 > either the ULA address space (RFC4193) or left as link-locals only=20 > ("unnumbered"). You may be interested in the following, which=20 > discusses link-local only addressing - >>=20 >> "Using Only Link-Local Addressing Inside an IPv6 Network" >> http://tools.ietf.org/html/draft-behringer-lla-only-01 >>=20 >>=20 >> Regards, >>=20 >> Mark. >>=20 >>> My question is, in your opinion, would this be worthwhile to be > formulated as an >>> ID an be drafted or does this idea sound absurd? >>>=20 >>>=20 >>=20 >>> Cheers, >>>=20 >>> Stefan >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >=20 From otroan@employees.org Wed Sep 26 04:13:03 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F94921F87AA for ; Wed, 26 Sep 2012 04:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.17 X-Spam-Level: X-Spam-Status: No, score=-2.17 tagged_above=-999 required=5 tests=[AWL=-0.471, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVZyTlV-84+U for ; Wed, 26 Sep 2012 04:13:02 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id CFECD21F8698 for ; Wed, 26 Sep 2012 04:13:02 -0700 (PDT) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id AA9905D96 for ; Wed, 26 Sep 2012 04:13:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :content-type:message-id:mime-version:subject:date:references:to :in-reply-to; s=selector1; bh=Xa2YFB/o9FX+IaYT1migaNTFA+I=; b=gf 4gTqF5eiQERydfa+Kec6lo2uuCiRr/+lLOqJuvB1TmD1GeWsfDUCDiA3lwypHQKk kWmY8QOSqj0+n7i5r2c3onQNSM3+/K34KclVwb3KSccG339sWnruOq6crSdDnN+k 5HH8JpiCIJeCn4YFg+cKK+yPBGL4tQXi/Dhe5Co80= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :content-type:message-id:mime-version:subject:date:references:to :in-reply-to; q=dns; s=selector1; b=cQx1p+SMvLzp3cjWx9HsE0t0v0VF 1taDPm5cxchw2BaIfhqUbnZNaSjwlqN5M+pSw+qFtWs2yC58GGiLfcVsVwVrKZ3e Ug7fBbp+nZWLVPKhWTWeEY6xFOl9tETGFDAqLUN3+GJhR9aISVEaF4bICD4mGR4T j+cj8gexqSVNUaI= Received: from dhcp-lys01-vla250-10-147-112-179.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 134895DC5 for ; Wed, 26 Sep 2012 04:13:00 -0700 (PDT) From: =?iso-8859-1?Q?Ole_Tr=F8an?= Content-Type: multipart/signed; boundary="Apple-Mail=_0BB564A4-0441-4A14-BEBE-DA235D9ABDEA"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: <7E131056-FA46-492B-BDA3-FA7EA5CDE7C3@employees.org> Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) Date: Wed, 26 Sep 2012 13:12:57 +0200 References: <20120925151932.27238.7903.idtracker@ietfa.amsl.com> To: v6ops@ietf.org In-Reply-To: <20120925151932.27238.7903.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.1498) Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-11.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 11:13:03 -0000 --Apple-Mail=_0BB564A4-0441-4A14-BEBE-DA235D9ABDEA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii from the diffset: "Even though this document has Informational status, it = specifies=09 requirements using RFC 2119 language, but not strictly for = the=09 purpose of interoperability. Some requirements are = intentionally=09 specified for the purpose of establishing industry-common = baseline=09 functionality. As such, the document points to several other=09= specifications (preferable in RFC or stable form) to provide=09= additional guidance to implementers regarding any protocol=09 implementation required to produce a successful CPE router = that=09 interoperates successfully with a particular subset of = currently=09 deploying and planned common IPv6 access networks." can we make the document "Proposed Standard" instead? WAA-5: why the change, which in my opinion is just a clumsy fyi = addition? cheers, Ole On Sep 25, 2012, at 17:19 , internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the IPv6 Operations Working Group of the = IETF. >=20 > Title : Basic Requirements for IPv6 Customer Edge = Routers > Author(s) : Hemant Singh > Wes Beebee > Chris Donley > Barbara Stark > Filename : draft-ietf-v6ops-6204bis-11.txt > Pages : 22 > Date : 2012-09-25 >=20 > Abstract: > This document specifies requirements for an IPv6 Customer Edge (CE) > router. Specifically, the current version of this document focuses > on the basic provisioning of an IPv6 CE router and the provisioning > of IPv6 hosts attached to it. The document also covers IP = transition > technologies. Two transition technologies in RFC 5969's 6rd and RFC > 6333's DS-Lite are covered in the document. The document obsoletes > RFC 6204, if approved. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-6204bis >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-11 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-6204bis-11 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_0BB564A4-0441-4A14-BEBE-DA235D9ABDEA Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMNjCCBUAw ggQooAMCAQICEGaZIlj/wiu8ZryksFIoEYswDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMjA4MDgwMDAwMDBaFw0x MjEwMDcyMzU5NTlaMIIBAzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEmMCQGA1UECxMdRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUxEjAQBgNVBAMU CU9sZSBUcvhhbjEjMCEGCSqGSIb3DQEJARYUb3Ryb2FuQGVtcGxveWVlcy5vcmcwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQC03pLE1GnPvefnf0B0ZI3TpY/FJatqxd6P2bERWXj0bVj6 SKO/HWyK6Bai3b16kDZew5FDUu6+DsEhh9+bxsiCCstTE+121pcEKgU8F4tazGy05x1Z60Xo1Lkl ki/3OtYCie+VfmQkjmH+y9UuJWPgZcnzTpIC8ztdAzvvrrD0/oIWIwkpSvS4VHE0It1xRGDs3pb2 IEgCEOUEg5wNvxMHbLwa15EZYK4p4LypgF+ObeR+JklVes2pObQCLuyGa8TXYJsIIpm5D3NthBEw UvdS+/I3EzSeVTDw0dwfzW82XQls1CwKNI/IUS0huB5ZBaThB8LbEaThwU44/osFcyTNAgMBAAGj gdIwgc8wCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEW HGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMEBggrBgEFBQcDAjBQBgNVHR8ESTBHMEWgQ6BBhj9odHRwOi8vaW5kYzFkaWdpdGFsaWQt ZzMtY3JsLnZlcmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC1HMy5jcmwwDQYJKoZIhvcNAQEFBQAD ggEBAIJIENsyJjrFsF3StCcQWSFBGL6ddUZPfF0vkXmDJujOFnIcv0V9UBiWKkBGxI/J/1faLOWz LJYk25GZv83tPYrXKCuUL0vEtVswc+qLw0EeVbKlr6bILZvcj7P4aJePWYMoJCuWnC60HnEndAOm T1/d7xCRCcBjFmZDyM0FSO17VTjP6+Kxg3IGujWu+/sB0OD8CkipsjJikeIxIY/ujK8waMg2ePgz 4UQjTG1K2r5PfWeXHcG09Gcu5qBN9q0YKNfWMYwSIEfs61J/0cbrh399X+1+9uc3ygBs2F6NR0kM 0cDe/DfyWPwvnwXlzEXuC5xRMXNrWQ6cWQd0mryIZ5owggbuMIIF1qADAgECAhBxFWYFSuSRIU3p vET5rNPcMA0GCSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5 IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlT aWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAe Fw0wOTA1MDEwMDAwMDBaFw0xOTA0MzAyMzU5NTlaMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMO VmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsT MlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYD VQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5k aXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDtxEffKigdfAZru9chMslsE4/psY1BTjT32gvjavpliCALERPpm+BJTotv1QHQXw1HkYpaTHQ+ P8aRCbtMNJ6NbqGCUWL3aXZYlgevnhQYB09avZ/SMbJUGXNGahlCEewScyGN9dwwzeXZVgoxxTZt KRSXvS3aiUcZiNhLBD3rtjxnHnQAEw3QhtqTZ/gzA64aPGtpePbALI7hgz93+Zn//p9SWsK0hwrY bKlHwVQpZUM+SsCWH8Gt93evbLEEXr7BtpQtl5AtJ9K7HumDaoT2xLKuIwZlJqUnWCsHIrRvpmJI Gnfy1VAnminTlvso9bokdmLjjFnr+27VQsS+Qcf1AgMBAAGjggK5MIICtTA0BggrBgEFBQcBAQQo MCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/ AgEAMHAGA1UdIARpMGcwZQYLYIZIAYb4RQEHFwEwVjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL2NwczAqBggrBgEFBQcCAjAeGhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEtZzMuY3Js MA4GA1UdDwEB/wQEAwIBBjBuBggrBgEFBQcBDARiMGChXqBcMFowWDBWFglpbWFnZS9naWYwITAf MAcGBSsOAwIaBBRLa7kolgYMu9BSOJsprEsHiyEFGDAmFiRodHRwOi8vbG9nby52ZXJpc2lnbi5j b20vdnNsb2dvMS5naWYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJlbDQtMjA0 OC0xMTgwHQYDVR0OBBYEFHlHYQhB/TgEokvntcz1Q/ZJKxH4MIHxBgNVHSMEgekwgeahgdCkgc0w gcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3Ig YXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczghEAi1t1VoRUhQsAz684SM6xpDANBgkq hkiG9w0BAQUFAAOCAQEAOU3PQZmBtakFtVI46TmEiWzkNKha59hsCUwkGrpZpIc7cyHxk4HPv2hj Wmf+NYUrocNdo0rCOhndMNbMTe/x0oGXylRaQ783i3qOGY0PQ6iM8q9gsxWKs5WcPOCesyeYpDVy F+X8Kl2H04oNwtFFKvjA9KwqkzrVrhJwCOv7O+J37OgrZDV2zbra4NHLFNZxWJu+1T59ttnoJMUk ZkxdkR92sxc+fw3GIYkvsze4of9csm1J3mVSQvsOiNLtSh2/S+P4zHL6SA5ljknI1viZmDu3lD4x cQaH+mxZUy7X3yvtX2MArBXtA7hVFozGaAPnIqhzC7G8oNpSWN0KDn/BgjGCBIswggSHAgEBMIHy MIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52 ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1 BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGaZ Ilj/wiu8ZryksFIoEYswCQYFKw4DAhoFAKCCAm0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAc BgkqhkiG9w0BCQUxDxcNMTIwOTI2MTExMjU4WjAjBgkqhkiG9w0BCQQxFgQUPdksuQR46526Clce 8d7bjstMqn4wggEDBgkrBgEEAYI3EAQxgfUwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMy VGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQZpkiWP/CK7xmvKSwUigRizCCAQUGCyqGSIb3DQEJ EAILMYH1oIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRw czovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxp ZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENB IC0gRzMCEGaZIlj/wiu8ZryksFIoEYswDQYJKoZIhvcNAQEBBQAEggEAFIzfJSF3eY+paRTUuiMT kv+HgTt/iq27SMTU2DmSoaJ70GdXnhxDrdzXd0qr5iOR83JKhRCW8ISQusGVStFmuVMGj7cTx0xy BMFv0yYnRe3KjhI4L7nx8+fEajpCC/2Eua99CT1ew9vxcm04hRD/4CelzHxxCYNegmjtlKexXStw m3/akpBz6k4BRFjXGBavwqjzK8V7wk/qLFisNlcx+Q8iT+X1CvqqHf99eKvOfLYEQesSwergIfeN dJWx8KqFEPRO4KfHhYoOF2qVvForC4Ta+BAPY3EKzPXOBnZAuwQgeJkBuhWJFeh+asqWkSyra1vA HvhL2doXr0KZp9P5dgAAAAAAAA== --Apple-Mail=_0BB564A4-0441-4A14-BEBE-DA235D9ABDEA-- From brian.e.carpenter@gmail.com Wed Sep 26 05:15:12 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FB7721F87F3 for ; Wed, 26 Sep 2012 05:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.262 X-Spam-Level: X-Spam-Status: No, score=-103.262 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kMiGNY4XMvm7 for ; Wed, 26 Sep 2012 05:15:10 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id B207B21F858F for ; Wed, 26 Sep 2012 05:15:10 -0700 (PDT) Received: by iec9 with SMTP id 9so1383420iec.31 for ; Wed, 26 Sep 2012 05:15:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=nrbSPQS5gq0eYM56Ak7cvIbGi+zOC2gqlkeMS6/Kf3o=; b=LShI9JecoWye/mFwOmnF4bbM4k/+YqxDlF/2//hry2ls8FWQAI/eng39RvnRnURD7X Q357/oaIuLGnSMp6s/LEUAL+ScRJwnB8q0hJR96kYePVB6uKyKFhHNOoHCOwsw5AGwan dX2GfsYfZ4u7mwY45E7Twc/+9tUayJC+4mMZEwZQ8jVIj/wBgNsRrSlAbQpqy6jIh+BZ LlsGDLicP0fWHG1TZYKYKN9FAe+2hBUsikSB2bE66SJun9sEr1dUsHAsa01qs01eQ6gN frnAMCQQcQe6prZ5V20of2E0TpnONLAN6Jlme0UCRSGViXZ17xfo5Vdom6c4z7E7GpDp Rycw== Received: by 10.50.57.194 with SMTP id k2mr295790igq.17.1348661710164; Wed, 26 Sep 2012 05:15:10 -0700 (PDT) Received: from [10.255.25.102] (50-76-68-140-static.hfc.comcastbusiness.net. [50.76.68.140]) by mx.google.com with ESMTPS id hz10sm10194077igc.12.2012.09.26.05.15.09 (version=SSLv3 cipher=OTHER); Wed, 26 Sep 2012 05:15:09 -0700 (PDT) Message-ID: <5062F1D3.2030601@gmail.com> Date: Wed, 26 Sep 2012 13:15:15 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Marksteiner, Stefan" References: <8A317FD8C00FEE448E52D4EE5B56BB3E0232A086D8FF@RZJC1EX.jr1.local>, <1348519034.47465.YahooMailNeo@web32503.mail.mud.yahoo.com> <8A317FD8C00FEE448E52D4EE5B56BB3E0232A086D902@RZJC1EX.jr1.local>, <5061B157.1090106@gmail.com> <8A317FD8C00FEE448E52D4EE5B56BB3E0232A086D90A@RZJC1EX.jr1.local> <1348602134.63605.YahooMailNeo@web32505.mail.mud.yahoo.com> <8A317FD8C00FEE448E52D4EE5B56BB3E0232A08499BB@RZJC1EX.jr1.local> In-Reply-To: <8A317FD8C00FEE448E52D4EE5B56BB3E0232A08499BB@RZJC1EX.jr1.local> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: 'IPv6 Ops WG' Subject: Re: [v6ops] Operational guidelines for a company/organization IPv6 address scheme supplemental to RFC5157 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 12:15:12 -0000 On 26/09/2012 08:16, Marksteiner, Stefan wrote: > Hi, >=20 > There's a variety of reasons to keep track of addresses from usage and = statistics to forensic purposes in security incidents (also those which a= re perpetrated from inside sources to outside targets). > Privacy extensions would perhaps be too unpredictable to manage, but st= ateful DHCPv6 combined with a suitable IPAM-solution would probably do th= e trick. And if you care about easy-to-guess addresses, use a pseudorandom method = to assign the IID part of the addresses. > Maybe I have been stuck in my mindset a little, as we use only static = addresses in our productive IPv4 network.=20 We do need to get away from that as much as possible (see 6renum WG for m= ore). Brian > Thanks :) >=20 > Cheers, >=20 > Stefan >=20 >=20 > -----Urspr=C3=BCngliche Nachricht----- > Von: Mark ZZZ Smith [mailto:markzzzsmith@yahoo.com.au]=20 > Gesendet: Dienstag, 25. September 2012 21:42 > An: Marksteiner, Stefan; IPv6 Ops WG > Betreff: Re: AW: [v6ops] Operational guidelines for a company/organizat= ion IPv6 address scheme supplemental to RFC5157 >=20 >=20 >=20 >=20 >=20 > ----- Original Message ----- >> From: "Marksteiner, Stefan" >> To: IPv6 Ops WG >> Cc: Mark ZZZ Smith >> Sent: Wednesday, 26 September 2012 12:18 AM >> Subject: AW: [v6ops] Operational guidelines for a company/organization= =20 >> IPv6 address scheme supplemental to RFC5157 >> >> Hi Brian, >> >> SLAAC is *somewhat* predictable, especially when you already have one = >> address as a starting point (then you've got a vendor ID plus a=20 >> probable batch which narrows the scanning address room significantly).= >> Of course I assume workstation machines not to be in public a DNS zone= =2E.. >> =20 >=20 > So if you want unpredictable, you use privacy addresses. They're not ha= rd to enable, and in some cases (recent Windows OSes, Fedora 17) they're = enabled by default. >=20 > If you've chosen to go down the stateful DHCPv6 path, I'd verify what s= ort of allocation scheme it uses or can be enabled - there may and perhap= s will likely be a "random" option. >=20 > What problem are you trying to solve by having technical staff being ab= le to determine addresses? Is it to record addresses in use? Or address u= tilisation within the subnet? >=20 > Regards, > Mark. >=20 >> Regards, >> >> Stefan >> >> >> ________________________________________ >> Von: Brian E Carpenter [brian.e.carpenter@gmail.com] >> Gesendet: Dienstag, 25. September 2012 15:27 >> An: Marksteiner, Stefan >> Cc: Mark ZZZ Smith; IPv6 Ops WG >> Betreff: Re: [v6ops] Operational guidelines for a company/organization= =20 >> IPv6 address scheme supplemental to RFC5157 >> >> On 25/09/2012 10:42, Marksteiner, Stefan wrote: >>> Hi Mark, >>> >>> First of all I think I've forgotten to clarify that I'm talking >> about IIDs, sorry ;) >>> The aim of my thoughts would be to make it harder for externals to=20 >>> scan for >> attackable addresses. One often cited (mostly by marketeers) benefit=20 >> of IPv6 is the vast amount of addresses per subnet making it seemingly= =20 >> harder to scan, which would be nullified if companies used simple sequ= ential addressing. >>> You're of course right that most (potential) attackers are insiders = >>> - >> but they likely wouldn't have to scan anyway, instead the would=20 >> probably already have knowledge of alive (and maybe even vulnerable)=20 >> hosts. Thus, they aren't my focus in this matter, but instead are=20 >> "black box"-scanners and Internet worms. >>> ULA/LLA are, as you've correctly stated, the best choice if you >> don't need Internet connection, but what about workstations for=20 >> employees needing the Internet? >>> I'm suggesting to recommend companies to use a different scheme as >> ::1;::2 or ::BABE;::CAFE or even ::4593;4594 and so on which according= =20 >> to some studies (e.g. [1], pp.65-75, especially 68) most=20 >> administrators unfortunately do. >>> What might be needed to change this would be a scheme which is=20 >>> practicably >> administrable in the easiest possible way. >> >> It depends what you mean by "administrable" but SLAAC doesn't need a=20 >> scheme and therefore doesn't need administration. For machines that=20 >> are in public DNS it doesn't matter anyway, so any scheme will do. >> >> Brian >> >>> This would have, in my opinion, two benefits. Firstly it would=20 >>> render >> standard scanning procedures for IPv6 like sequential scanning and=20 >> scanning for "funny" addresses pretty much useless. Secondly, if the=20 >> numbers are, seen from the outside, seemingly random, it wouldn't help= =20 >> a scanner or worm if he or it discovered a single address by chance=20 >> (e.g. by a log entry) and took it as a starting point for further scan= ning. >>> I'm aware of the discussions about security by obscurity and that a >> good firewall is needed anyway to secure internal assets, but I would = >> find it nice if the often cited "security argument" that IPv6 subnets = >> are merely impossible to scan would be true (again) :) >>> >>> Cheers, >>> >>> Stefan >>> >>> >>> [1]http://www.mh-sec.de/downloads/mh-ipv6_vulnerabilities.pdf >>> ________________________________________ >>> Von: Mark ZZZ Smith [markzzzsmith@yahoo.com.au] >>> Gesendet: Montag, 24. September 2012 22:37 >>> An: Marksteiner, Stefan; IPv6 Ops WG >>> Betreff: Re: [v6ops] Operational guidelines for a=20 >>> company/organization IPv6 >> address scheme supplemental to RFC5157 >>> Hi Stefan, >>> >>> ----- Original Message ----- >>> >>>> From: "Marksteiner, Stefan"=20 >> >>>> To: IPv6 Ops WG >>>> Cc: >>>> Sent: Tuesday, 25 September 2012 4:03 AM >>>> Subject: [v6ops] Operational guidelines for a company/organization = >>>> IPv6 >> address scheme supplemental to RFC5157 >>>> >>>> Hi Folks, >>>> >>>> RFC5157 presents hazards of sequentially numbering IPv6 networks=20 >>>> and >> technical >>>> means (like CGAs and privacy extensions) to mitigate them.=20 >> Unfortunately these >>>> mitigation methods may be deemed difficult to handle for=20 >>>> administrators >> (SEND >>>> may be too complicated to implement, PEs bring difficulties to keep= >> track of IP >>>> addresses). Therefore there may be demand for an addressing scheme >> (rather than >>>> a technical method) that makes IPv6 addresses easy to predict for=20 >>>> tech >> staff but >>>> difficult to do so by outsiders, building a low-end supplement for = >>>> the >> methods >>>> mentioned in RFC5157. >>> >>> I think it might be worth having a bit more of a think about who=20 >>> might be >> inclined to attack you - for a typical non-Internet services=20 >> organisation, I think it's more likely going to be >>> disgruntled ex-staff, and it'll be hard to make them forget >> "numbers" / addresses or prevent them copying the mapping application = >> if they have an inkling they're going to get fired. >>> >>>> What I have in mind is an simple mental arithmetic operation, which= >> generates an >>>> address out of a company fixed part plus a sequential number for ho= st. >>>> Alternatively a Hash-Operation consisting again of a secret >> organisational plus >>>> a sequential host number. The first requires the scheme to be=20 >>>> slightly >> different >>>> in every organisation in order to have a negative impact on IPv6 >> scanning from >>>> external sources, the second is more secure but requires an=20 >>>> internal >> web site or >>>> smartphone app in order for field engineers to calculate an address= =20 >>>> out >> of the >>>> sequential information. >>>> >>> It sounds like here you're talking about a subnet numbering scheme. = >>> The >> common prefix size for most organisations is going to be /56 or 256=20 >> /64 subnets, or /48 or 65K /64 subnets. Many providers seem to be=20 >> leaning towards /56s unless their customers ask for a /48, which=20 >> provides very little address space to effectively hide the in-use=20 >> subnet numbers from a scanning based attack (and that's one of the=20 >> reasons why I'd be giving customers /48s from the outset). One=20 >> advantage though of IPv6 is that it is possible to phase in and phase = >> out addressing using the address/prefix lifetimes mechanism, so it wou= ld be possible to change assigned in your network prefixes on e.g. a week= ly basis. >>> If your fundamental goal is to make internal links unreachable from = >>> the >> Internet, they can be not assigned a global prefix, and numbered from = >> either the ULA address space (RFC4193) or left as link-locals only=20 >> ("unnumbered"). You may be interested in the following, which=20 >> discusses link-local only addressing - >>> "Using Only Link-Local Addressing Inside an IPv6 Network" >>> http://tools.ietf.org/html/draft-behringer-lla-only-01 >>> >>> >>> Regards, >>> >>> Mark. >>> >>>> My question is, in your opinion, would this be worthwhile to be >> formulated as an >>>> ID an be drafted or does this idea sound absurd? >>>> >>>> >>>> Cheers, >>>> >>>> Stefan >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From stefan.marksteiner@joanneum.at Wed Sep 26 08:01:46 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A08121F8694 for ; Wed, 26 Sep 2012 08:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.417 X-Spam-Level: X-Spam-Status: No, score=-0.417 tagged_above=-999 required=5 tests=[AWL=0.413, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ETRG-2Nyvjcc for ; Wed, 26 Sep 2012 08:01:45 -0700 (PDT) Received: from rzjgate1.joanneum.ac.at (rzjgate1.joanneum.ac.at [143.224.185.3]) by ietfa.amsl.com (Postfix) with ESMTP id 01D9A21F8629 for ; Wed, 26 Sep 2012 08:01:44 -0700 (PDT) Received: from RZJS077.jr1.local (rzjs077.joanneum.ac.at [143.224.71.18]) by rzjgate1.joanneum.ac.at (8.14.4/8.14.4) with ESMTP id q8QF1doQ026179; Wed, 26 Sep 2012 17:01:39 +0200 Received: from RZJC1EX.jr1.local ([169.254.2.9]) by RZJS077.jr1.local ([143.224.71.18]) with mapi; Wed, 26 Sep 2012 17:01:39 +0200 From: "Marksteiner, Stefan" To: Brian E Carpenter Date: Wed, 26 Sep 2012 16:59:54 +0200 Thread-Topic: [v6ops] Operational guidelines for a company/organization IPv6 address scheme supplemental to RFC5157 Thread-Index: Ac2b4JS8U98NjujjSQSLqE/k/k/BSwAFwGGJ Message-ID: <8A317FD8C00FEE448E52D4EE5B56BB3E0232A086D90F@RZJC1EX.jr1.local> References: <8A317FD8C00FEE448E52D4EE5B56BB3E0232A086D8FF@RZJC1EX.jr1.local>, <1348519034.47465.YahooMailNeo@web32503.mail.mud.yahoo.com> <8A317FD8C00FEE448E52D4EE5B56BB3E0232A086D902@RZJC1EX.jr1.local>, <5061B157.1090106@gmail.com> <8A317FD8C00FEE448E52D4EE5B56BB3E0232A086D90A@RZJC1EX.jr1.local> <1348602134.63605.YahooMailNeo@web32505.mail.mud.yahoo.com> <8A317FD8C00FEE448E52D4EE5B56BB3E0232A08499BB@RZJC1EX.jr1.local>, <5062F1D3.2030601@gmail.com> In-Reply-To: <5062F1D3.2030601@gmail.com> Accept-Language: de-DE, de-AT Content-Language: de-AT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, de-AT Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 'IPv6 Ops WG' Subject: Re: [v6ops] Operational guidelines for a company/organization IPv6 address scheme supplemental to RFC5157 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 15:01:46 -0000 Hi, >And if you care about easy-to-guess addresses, use a pseudorandom method t= o assign the >IID part of the addresses. yes, that's exactly my point. >We do need to get away from that as much as possible (see 6renum WG for mo= re). I strongly agree. Regards, Stefan ________________________________________ Von: Brian E Carpenter [brian.e.carpenter@gmail.com] Gesendet: Mittwoch, 26. September 2012 14:15 An: Marksteiner, Stefan Cc: 'Mark ZZZ Smith'; 'IPv6 Ops WG' Betreff: Re: [v6ops] Operational guidelines for a company/organization IPv6= address scheme supplemental to RFC5157 On 26/09/2012 08:16, Marksteiner, Stefan wrote: > Hi, > > There's a variety of reasons to keep track of addresses from usage and st= atistics to forensic purposes in security incidents (also those which are p= erpetrated from inside sources to outside targets). > Privacy extensions would perhaps be too unpredictable to manage, but stat= eful DHCPv6 combined with a suitable IPAM-solution would probably do the tr= ick. And if you care about easy-to-guess addresses, use a pseudorandom method to= assign the IID part of the addresses. > Maybe I have been stuck in my mindset a little, as we use only static ad= dresses in our productive IPv4 network. We do need to get away from that as much as possible (see 6renum WG for mor= e). Brian > Thanks :) > > Cheers, > > Stefan > > > -----Urspr=FCngliche Nachricht----- > Von: Mark ZZZ Smith [mailto:markzzzsmith@yahoo.com.au] > Gesendet: Dienstag, 25. September 2012 21:42 > An: Marksteiner, Stefan; IPv6 Ops WG > Betreff: Re: AW: [v6ops] Operational guidelines for a company/organizatio= n IPv6 address scheme supplemental to RFC5157 > > > > > > ----- Original Message ----- >> From: "Marksteiner, Stefan" >> To: IPv6 Ops WG >> Cc: Mark ZZZ Smith >> Sent: Wednesday, 26 September 2012 12:18 AM >> Subject: AW: [v6ops] Operational guidelines for a company/organization >> IPv6 address scheme supplemental to RFC5157 >> >> Hi Brian, >> >> SLAAC is *somewhat* predictable, especially when you already have one >> address as a starting point (then you've got a vendor ID plus a >> probable batch which narrows the scanning address room significantly). >> Of course I assume workstation machines not to be in public a DNS zone..= . >> > > So if you want unpredictable, you use privacy addresses. They're not hard= to enable, and in some cases (recent Windows OSes, Fedora 17) they're enab= led by default. > > If you've chosen to go down the stateful DHCPv6 path, I'd verify what sor= t of allocation scheme it uses or can be enabled - there may and perhaps wi= ll likely be a "random" option. > > What problem are you trying to solve by having technical staff being able= to determine addresses? Is it to record addresses in use? Or address utili= sation within the subnet? > > Regards, > Mark. > >> Regards, >> >> Stefan >> >> >> ________________________________________ >> Von: Brian E Carpenter [brian.e.carpenter@gmail.com] >> Gesendet: Dienstag, 25. September 2012 15:27 >> An: Marksteiner, Stefan >> Cc: Mark ZZZ Smith; IPv6 Ops WG >> Betreff: Re: [v6ops] Operational guidelines for a company/organization >> IPv6 address scheme supplemental to RFC5157 >> >> On 25/09/2012 10:42, Marksteiner, Stefan wrote: >>> Hi Mark, >>> >>> First of all I think I've forgotten to clarify that I'm talking >> about IIDs, sorry ;) >>> The aim of my thoughts would be to make it harder for externals to >>> scan for >> attackable addresses. One often cited (mostly by marketeers) benefit >> of IPv6 is the vast amount of addresses per subnet making it seemingly >> harder to scan, which would be nullified if companies used simple sequen= tial addressing. >>> You're of course right that most (potential) attackers are insiders >>> - >> but they likely wouldn't have to scan anyway, instead the would >> probably already have knowledge of alive (and maybe even vulnerable) >> hosts. Thus, they aren't my focus in this matter, but instead are >> "black box"-scanners and Internet worms. >>> ULA/LLA are, as you've correctly stated, the best choice if you >> don't need Internet connection, but what about workstations for >> employees needing the Internet? >>> I'm suggesting to recommend companies to use a different scheme as >> ::1;::2 or ::BABE;::CAFE or even ::4593;4594 and so on which according >> to some studies (e.g. [1], pp.65-75, especially 68) most >> administrators unfortunately do. >>> What might be needed to change this would be a scheme which is >>> practicably >> administrable in the easiest possible way. >> >> It depends what you mean by "administrable" but SLAAC doesn't need a >> scheme and therefore doesn't need administration. For machines that >> are in public DNS it doesn't matter anyway, so any scheme will do. >> >> Brian >> >>> This would have, in my opinion, two benefits. Firstly it would >>> render >> standard scanning procedures for IPv6 like sequential scanning and >> scanning for "funny" addresses pretty much useless. Secondly, if the >> numbers are, seen from the outside, seemingly random, it wouldn't help >> a scanner or worm if he or it discovered a single address by chance >> (e.g. by a log entry) and took it as a starting point for further scanni= ng. >>> I'm aware of the discussions about security by obscurity and that a >> good firewall is needed anyway to secure internal assets, but I would >> find it nice if the often cited "security argument" that IPv6 subnets >> are merely impossible to scan would be true (again) :) >>> >>> Cheers, >>> >>> Stefan >>> >>> >>> [1]http://www.mh-sec.de/downloads/mh-ipv6_vulnerabilities.pdf >>> ________________________________________ >>> Von: Mark ZZZ Smith [markzzzsmith@yahoo.com.au] >>> Gesendet: Montag, 24. September 2012 22:37 >>> An: Marksteiner, Stefan; IPv6 Ops WG >>> Betreff: Re: [v6ops] Operational guidelines for a >>> company/organization IPv6 >> address scheme supplemental to RFC5157 >>> Hi Stefan, >>> >>> ----- Original Message ----- >>> >>>> From: "Marksteiner, Stefan" >> >>>> To: IPv6 Ops WG >>>> Cc: >>>> Sent: Tuesday, 25 September 2012 4:03 AM >>>> Subject: [v6ops] Operational guidelines for a company/organization >>>> IPv6 >> address scheme supplemental to RFC5157 >>>> >>>> Hi Folks, >>>> >>>> RFC5157 presents hazards of sequentially numbering IPv6 networks >>>> and >> technical >>>> means (like CGAs and privacy extensions) to mitigate them. >> Unfortunately these >>>> mitigation methods may be deemed difficult to handle for >>>> administrators >> (SEND >>>> may be too complicated to implement, PEs bring difficulties to keep >> track of IP >>>> addresses). Therefore there may be demand for an addressing scheme >> (rather than >>>> a technical method) that makes IPv6 addresses easy to predict for >>>> tech >> staff but >>>> difficult to do so by outsiders, building a low-end supplement for >>>> the >> methods >>>> mentioned in RFC5157. >>> >>> I think it might be worth having a bit more of a think about who >>> might be >> inclined to attack you - for a typical non-Internet services >> organisation, I think it's more likely going to be >>> disgruntled ex-staff, and it'll be hard to make them forget >> "numbers" / addresses or prevent them copying the mapping application >> if they have an inkling they're going to get fired. >>> >>>> What I have in mind is an simple mental arithmetic operation, which >> generates an >>>> address out of a company fixed part plus a sequential number for host= . >>>> Alternatively a Hash-Operation consisting again of a secret >> organisational plus >>>> a sequential host number. The first requires the scheme to be >>>> slightly >> different >>>> in every organisation in order to have a negative impact on IPv6 >> scanning from >>>> external sources, the second is more secure but requires an >>>> internal >> web site or >>>> smartphone app in order for field engineers to calculate an address >>>> out >> of the >>>> sequential information. >>>> >>> It sounds like here you're talking about a subnet numbering scheme. >>> The >> common prefix size for most organisations is going to be /56 or 256 >> /64 subnets, or /48 or 65K /64 subnets. Many providers seem to be >> leaning towards /56s unless their customers ask for a /48, which >> provides very little address space to effectively hide the in-use >> subnet numbers from a scanning based attack (and that's one of the >> reasons why I'd be giving customers /48s from the outset). One >> advantage though of IPv6 is that it is possible to phase in and phase >> out addressing using the address/prefix lifetimes mechanism, so it would= be possible to change assigned in your network prefixes on e.g. a weekly b= asis. >>> If your fundamental goal is to make internal links unreachable from >>> the >> Internet, they can be not assigned a global prefix, and numbered from >> either the ULA address space (RFC4193) or left as link-locals only >> ("unnumbered"). You may be interested in the following, which >> discusses link-local only addressing - >>> "Using Only Link-Local Addressing Inside an IPv6 Network" >>> http://tools.ietf.org/html/draft-behringer-lla-only-01 >>> >>> >>> Regards, >>> >>> Mark. >>> >>>> My question is, in your opinion, would this be worthwhile to be >> formulated as an >>>> ID an be drafted or does this idea sound absurd? >>>> >>>> >>>> Cheers, >>>> >>>> Stefan >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From ietf-secretariat@ietf.org Wed Sep 26 08:07:06 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F163F21F8658; Wed, 26 Sep 2012 08:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.242 X-Spam-Level: X-Spam-Status: No, score=-102.242 tagged_above=-999 required=5 tests=[AWL=-0.243, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N3PS-G0yrdGj; Wed, 26 Sep 2012 08:07:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8087F21F84C4; Wed, 26 Sep 2012 08:07:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: opsec@ietf.org, v6ops@ietf.org, sidr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120926150705.8596.75260.idtracker@ietfa.amsl.com> Date: Wed, 26 Sep 2012 08:07:05 -0700 Subject: [v6ops] IETF Large Interim Meeting - OPSEC, SIDR and V6OPS X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 15:07:06 -0000 OPSEC, SIDR and V6OPS Interim Meeting Amsterdam, The Netherlands 29 September 2012 Venue: Hotel Okura Amsterdam (www.okura.nl) Ferdinand Bolstraat 333 1072 LH Amsterdam The Netherlands 1. Registration 2. Accommodations 3. Meeting Schedule 1. Registration A. Fee: $100 USD B. Register online at: http://www.ietf.org/registration/lim2012/ietfreg.py C. Online Registration and Payment closes on 28 September 2012 D. On Site Registration starting Saturday, 29 September at 8:00 AM 2. Accommodations A block of rooms is being held at the Hotel Okura Amsterdam (meeting venue= ) for the nights of September 28 and 29. Rate: 195 EUR [256 USD; 20,065 JPY] Rate includes breakfast and guest room wireless internet but excludes 5%= city tax. To make your reservation on line, please go to: www.okura.nl Group Code: IETF2012 Guest Cancellation: - Reservations may be changed up to 1 week prior to the event without pena= lty. (You can change, not cancel, the reservation, i.e. change arrival, departure dates or name, up to 1 week without penalty but not cancel the reservation without penalty.) - 50% of reservation value penalty for cancellation less than 14 days and = greater than 7 days prior to event. If you cancel, not change, the reservat= ion less than 14 days but more than 7 days prior to the event you will be c= harged 50% of the total reservation fee. - 80% of reservation value penalty for cancellation less than 7 days and g= reater than 3 days prior to event. If you cancel, not change, the reservati= on less than 7 days prior to the event you will be charged 80% of the total= reservation fee. - 100% of reservation value penalty for cancellation less than 3 days prio= r to event or non-arrival or no-show. - In case of early departure, the full value of the reservation will be ch= arged to the guest. If you have any problems making your reservation, please send a message to = agenda@ietf.org 3. Meeting Agenda 0800-1700 Okura Foyer Registration 0830-0900 Okura Foyer AM Coffee 0900-1130 Room: Otter SIDR 0900-1130 Room: Heian I OPSEC 1030-1100 Okura Foyer AM Break 1130-1330 On Own Lunch Break 1330-1700 Room: Otter SIDR 1330-1700 Room: Heian I V6OPS 1500-1530 Okura Foyer PM Break From pkern@hub.kern.lc Wed Sep 26 15:27:48 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF8B21F8551 for ; Wed, 26 Sep 2012 15:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gEPjbLfYKPOA for ; Wed, 26 Sep 2012 15:27:48 -0700 (PDT) Received: from hub.kern.lc (hub.kern.lc [IPv6:2a00:1158:3::c7]) by ietfa.amsl.com (Postfix) with ESMTP id DC37A21F854F for ; Wed, 26 Sep 2012 15:27:47 -0700 (PDT) Received: from pkern by hub.kern.lc with local (Exim 4.80) (envelope-from ) id 1TH053-0008FK-63; Thu, 27 Sep 2012 00:27:45 +0200 Date: Thu, 27 Sep 2012 00:27:45 +0200 From: Philipp Kern To: "Marksteiner, Stefan" Message-ID: <20120926222745.GA31684@hub.kern.lc> References: <8A317FD8C00FEE448E52D4EE5B56BB3E0232A086D8FF@RZJC1EX.jr1.local> <1348519034.47465.YahooMailNeo@web32503.mail.mud.yahoo.com> <8A317FD8C00FEE448E52D4EE5B56BB3E0232A086D902@RZJC1EX.jr1.local> <5061B157.1090106@gmail.com> <8A317FD8C00FEE448E52D4EE5B56BB3E0232A086D90A@RZJC1EX.jr1.local> <1348602134.63605.YahooMailNeo@web32505.mail.mud.yahoo.com> <8A317FD8C00FEE448E52D4EE5B56BB3E0232A08499BB@RZJC1EX.jr1.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8A317FD8C00FEE448E52D4EE5B56BB3E0232A08499BB@RZJC1EX.jr1.local> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Philipp Kern Cc: 'IPv6 Ops WG' Subject: Re: [v6ops] Operational guidelines for a company/organization IPv6 address scheme supplemental to RFC5157 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 22:27:48 -0000 On Wed, Sep 26, 2012 at 09:16:12AM +0200, Marksteiner, Stefan wrote: > There's a variety of reasons to keep track of addresses from usage and > statistics to forensic purposes in security incidents (also those which are > perpetrated from inside sources to outside targets). Wouldn't it be better to track the tables of your switches and routers (possibly with port info) instead? Because everybody can infer the subnet from one stateful DHCPv6 reply and just use another address. Well, unless your hardware can already do DHCPv6 snooping at the edge, which seems to be sort of rare. Kind regards Philipp Kern From john.mann@monash.edu Wed Sep 26 16:23:54 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEFAA21F84FC for ; Wed, 26 Sep 2012 16:23:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aPKJyRGwcQ7w for ; Wed, 26 Sep 2012 16:23:54 -0700 (PDT) Received: from na3sys009aog122.obsmtp.com (na3sys009aog122.obsmtp.com [74.125.149.147]) by ietfa.amsl.com (Postfix) with ESMTP id 91CCA21F84DC for ; Wed, 26 Sep 2012 16:23:53 -0700 (PDT) Received: from mail-ee0-f44.google.com ([74.125.83.44]) (using TLSv1) by na3sys009aob122.postini.com ([74.125.148.12]) with SMTP ID DSNKUGOOiYQUK6mec/9Liykh54SkBZAgTCGG@postini.com; Wed, 26 Sep 2012 16:23:53 PDT Received: by eekd4 with SMTP id d4so649223eek.31 for ; Wed, 26 Sep 2012 16:23:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=b9bqOCXwU3fgG4EhQeAJEtceuRMwfL+pRQbIXb86F1I=; b=fiEag4x6crh3kMr8FGlVfbAtaW/rDPK4Xe31aZjaF8WNFYUgGSU9ZMTzllxnvfGGG3 YRwDC1V2SrT5JC8XynsxxBTo4t7e+Q2wcqpz2dFujGDFNtEJYRP5qrDMBayrKTkUGv9P 9DnNZ5PzREw1bjju0gh/z3MajEtA23hL13VnbqEY74SAwSfsp5tPiWP/E9ssa0XPS531 tyy513NBiV3HjSlcaZk5lFh+0BBgmy2T4V7DZKns24zcMrNyiKBoVTJWy4n3IBN1hba5 LsRRUMSTGvqdr/tOuDP5nxDhT195/XfCnk3tKgdr4k8LLYzTVNWEwU+ioOgdN1DUjNHh B+Tg== Received: by 10.14.215.69 with SMTP id d45mr3634778eep.16.1348701831742; Wed, 26 Sep 2012 16:23:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.96.72 with HTTP; Wed, 26 Sep 2012 16:23:31 -0700 (PDT) In-Reply-To: <20120926222745.GA31684@hub.kern.lc> References: <8A317FD8C00FEE448E52D4EE5B56BB3E0232A086D8FF@RZJC1EX.jr1.local> <1348519034.47465.YahooMailNeo@web32503.mail.mud.yahoo.com> <8A317FD8C00FEE448E52D4EE5B56BB3E0232A086D902@RZJC1EX.jr1.local> <5061B157.1090106@gmail.com> <8A317FD8C00FEE448E52D4EE5B56BB3E0232A086D90A@RZJC1EX.jr1.local> <1348602134.63605.YahooMailNeo@web32505.mail.mud.yahoo.com> <8A317FD8C00FEE448E52D4EE5B56BB3E0232A08499BB@RZJC1EX.jr1.local> <20120926222745.GA31684@hub.kern.lc> From: John Mann Date: Thu, 27 Sep 2012 09:23:31 +1000 Message-ID: To: Philipp Kern Content-Type: multipart/alternative; boundary=047d7b621f5496c69304caa31d7d X-Gm-Message-State: ALoCoQngjHwLOS8Gfl9MwbP+rHcX07qebTEpzIlS6uT+QBf9jRu5+R3v3KTB8b6OBC0KqkNIxBI5 Cc: IPv6 Ops WG Subject: Re: [v6ops] Operational guidelines for a company/organization IPv6 address scheme supplemental to RFC5157 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2012 23:23:54 -0000 --047d7b621f5496c69304caa31d7d Content-Type: text/plain; charset=ISO-8859-1 Hi, On 27 September 2012 08:27, Philipp Kern wrote: > On Wed, Sep 26, 2012 at 09:16:12AM +0200, Marksteiner, Stefan wrote: > > There's a variety of reasons to keep track of addresses from usage and > > statistics to forensic purposes in security incidents (also those which > are > > perpetrated from inside sources to outside targets). > > Wouldn't it be better to track the tables of your switches and routers > (possibly with port info) instead? Because everybody can infer the subnet > from > one stateful DHCPv6 reply and just use another address. Well, unless your > hardware can already do DHCPv6 snooping at the edge, which seems to be > sort of > rare. > I'm trying a) to track which addresses are used by which hosts for forensics and Internet authentication, and b) allow for some basic network-level filtering (e.g. only allow those PCs to ssh into this host) Currently PCs get 1) MAC-based SLAAC addresses 2) a new Privacy IPv6 addresses every day -- that lasts for n days There is no global event (like DHCPv4 traffic or RADIUS 802.1x) that signifies when a new SLAAC or privacy address starts or stops being used. Polling all routers for IPv6 neighbour tables (e.g. every hour) is certainly possible, but it leads to lots of data. It helps to do a FF02::1 multicast ping out each Vlan to refresh the tables first, but many PCs have firewalls that drop all pings ... If a PC is using a Privacy address for outbound communication, do you ever see the MAC-based address? As a test, I ran a ISC dhcpd to do stateful DHCPv6 address assignment to get some sticky-ness to the IPv6 address used by a PC when connected to a particular Vlan, and 3) the test PCs got an *extra* DHCPv6-assigned IPv6 address But the PCs still preferred Privacy addresses for new outbound connections!! To get PCs to use DHCPv6-assigned addresses instead of Privacy addresses, do I need to change the RAs to disable all use of SLACC addresses and then risk breaking IPv6 for any devices that don't support DHCPv6?? I'm at a University and have no control over the mixed BYOD fleet, just over the network and DHCPv* servers. Thanks, John --047d7b621f5496c69304caa31d7d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

    On 27 September 2012 08:27, Philipp K= ern <phil@philkern.de> wrote:
    On Wed, Sep 26, 2012 at 09:16:12AM +0200, Marksteiner, St= efan wrote:
    > There's a variety of reasons to keep track of addresses from usage= and
    > statistics to forensic purposes in security incidents (also those whic= h are
    > perpetrated from inside sources to outside targets).

    Wouldn't it be better to track the tables of your switches and ro= uters
    (possibly with port info) instead? Because everybody can infer the subnet f= rom
    one stateful DHCPv6 reply and just use another address. Well, unless your hardware can already do DHCPv6 snooping at the edge, which seems to be sort= of
    rare.

    I'm trying
    a) to tr= ack which addresses are used by which hosts for forensics and Internet auth= entication, and
    b) allow for some basic network-level filtering (= e.g. only allow those PCs to ssh into this host)

    Currently PCs get=A0
    1) MAC-based SLAAC addre= sses
    2) a new Privacy IPv6 addresses every day -- that lasts for = n days

    There is no global event (like DHCPv4 traff= ic or RADIUS 802.1x) that signifies when a new SLAAC or privacy address sta= rts or stops being used.

    Polling all routers for IPv6 neighbour tables (e.g. eve= ry hour) is certainly possible, but it leads to lots of data.
    It = helps to do a FF02::1 multicast ping out each Vlan to refresh the tables fi= rst, but many PCs have firewalls that drop all pings ...
    If a PC is using a Privacy address for outbound communication, do you = ever see the MAC-based address?

    As a test, I ran a= ISC dhcpd to do stateful DHCPv6 address assignment to get some sticky-ness= to the IPv6 address used by a PC when connected to a particular Vlan, and<= /div>
    3) the test PCs got an *extra* DHCPv6-assigned IPv6 address
    = But the PCs still preferred Privacy addresses for new outbound connections!= !

    To get PCs to use DHCPv6-assigned addresses inst= ead of Privacy addresses, do I need to change the RAs to disable all use of= SLACC addresses
    and then risk breaking IPv6 for any devices that don't support DHC= Pv6??

    I'm at a University and have no control = over the mixed BYOD fleet, just over the network and DHCPv* servers.

    Thanks,
    =A0 =A0 John
    --047d7b621f5496c69304caa31d7d-- From joelja@bogus.com Wed Sep 26 21:26:18 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE7E21F8470 for ; Wed, 26 Sep 2012 21:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.149 X-Spam-Level: X-Spam-Status: No, score=-102.149 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w6sA0J5X8wMV for ; Wed, 26 Sep 2012 21:26:17 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id C237321F85DA for ; Wed, 26 Sep 2012 21:26:17 -0700 (PDT) Received: from joels-MacBook-Air.local (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q8R4QF2e064670 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 27 Sep 2012 04:26:16 GMT (envelope-from joelja@bogus.com) Message-ID: <5063D567.8020903@bogus.com> Date: Wed, 26 Sep 2012 21:26:15 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20120905 Thunderbird/16.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Ole_Tr=F8an?= References: <20120925151932.27238.7903.idtracker@ietfa.amsl.com> <7E131056-FA46-492B-BDA3-FA7EA5CDE7C3@employees.org> In-Reply-To: <7E131056-FA46-492B-BDA3-FA7EA5CDE7C3@employees.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Thu, 27 Sep 2012 04:26:16 +0000 (UTC) Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-11.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2012 04:26:18 -0000 On 9/26/12 4:12 AM, Ole Trřan wrote: > from the diffset: > > "Even though this document has Informational status, it specifies > requirements using RFC 2119 language, but not strictly for the > purpose of interoperability. Some requirements are intentionally > specified for the purpose of establishing industry-common baseline > functionality. As such, the document points to several other > specifications (preferable in RFC or stable form) to provide > additional guidance to implementers regarding any protocol > implementation required to produce a successful CPE router that > interoperates successfully with a particular subset of currently > deploying and planned common IPv6 access networks." > > can we make the document "Proposed Standard" instead? That's been hashed out on this list and the minutes of the meetings already. The language change is to satisfy an IESG discuss not change the status of the document. > WAA-5: why the change, which in my opinion is just a clumsy fyi addition? also the product of a discuss. > > cheers, > Ole > > > > On Sep 25, 2012, at 17:19 , internet-drafts@ietf.org wrote: > >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the IPv6 Operations Working Group of the IETF. >> >> Title : Basic Requirements for IPv6 Customer Edge Routers >> Author(s) : Hemant Singh >> Wes Beebee >> Chris Donley >> Barbara Stark >> Filename : draft-ietf-v6ops-6204bis-11.txt >> Pages : 22 >> Date : 2012-09-25 >> >> Abstract: >> This document specifies requirements for an IPv6 Customer Edge (CE) >> router. Specifically, the current version of this document focuses >> on the basic provisioning of an IPv6 CE router and the provisioning >> of IPv6 hosts attached to it. The document also covers IP transition >> technologies. Two transition technologies in RFC 5969's 6rd and RFC >> 6333's DS-Lite are covered in the document. The document obsoletes >> RFC 6204, if approved. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-v6ops-6204bis >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-11 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-6204bis-11 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From mohamed.boucadair@orange.com Wed Sep 26 23:04:10 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DC0B21F8699 for ; Wed, 26 Sep 2012 23:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, SARE_SUB_OBFU_Q1=0.227, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cQtQZQOcofvB for ; Wed, 26 Sep 2012 23:04:09 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 9A19521F8698 for ; Wed, 26 Sep 2012 23:04:07 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 8FB713245F4; Thu, 27 Sep 2012 08:04:06 +0200 (CEST) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 72B1635C0EB; Thu, 27 Sep 2012 08:04:06 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Thu, 27 Sep 2012 08:04:06 +0200 From: To: jouni korhonen , MAWATARI Masataka Date: Thu, 27 Sep 2012 08:04:04 +0200 Thread-Topic: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update Thread-Index: Ac2a9Fg0xU7CsV8fTFK/AO1252ou4ABgMHlA Message-ID: <94C682931C08B048B7A8645303FDC9F36E5E44DED0@PUEXCB1B.nanterre.francetelecom.fr> References: <1B2E7539FECD9048B261B791B1B24A7C3EBE458308@PUEXCB1A.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E5B123A8C@PUEXCB1B.nanterre.francetelecom.fr> <20120925133859.15A2.8FE1F57E@jpix.ad.jp> <523CF185-5C72-4299-B4DA-3CEDBA7466D3@gmail.com> In-Reply-To: <523CF185-5C72-4299-B4DA-3CEDBA7466D3@gmail.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.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.9.27.52416 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2012 06:04:10 -0000 Dear Masataka, Jouni, Please see inline.=20 Cheers, Med=20 >-----Message d'origine----- >De : jouni korhonen [mailto:jouni.nospam@gmail.com]=20 >Envoy=E9 : mardi 25 septembre 2012 10:04 >=C0 : MAWATARI Masataka >Cc : BOUCADAIR Mohamed OLNC/NAD/TIP; v6ops@ietf.org >Objet : Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update > > >On Sep 25, 2012, at 7:39 AM, MAWATARI Masataka wrote: > >> Dear authors, >>=20 >> I read throuth your draft. >>=20 >> Comment about REQ#6 and REQ#7 on -02 version regarding conveying >> DNS server. >>=20 >> I heard that both of DHCPv6 client and RA options is not common on >> 3GPP mobile network at least for now. > >Specific to 3GPP, its "NAS" layer can deliver the mobile the DNS server >address among several other configuration things. Since NAS is=20 >in 3GPP's >hands it somehow gets preferred.. Currently as for Release-11 DHCPv6 is >still optional and RDNS is not there at all. > >> This document describes that if RA options is not supported, the >> cellular host should embed DHCPv6 client. Will RA options have >> more appreciated than DHCPv6 client on mobile? However, both >> requirements have same SHOULD. >>=20 >> Such a document should provide the clear preference and reasons >> about that, in my opinion. > >The preference ordering is in the text already in a way in req#7 it >seems but could be more clear/strict. Med: The new text for REQ#7 is: REQ#7: The cellular host SHOULD embed a DHCPv6 client [RFC3736] If [RFC6106] is not supported, the cellular host SHOULD retrieve DNS information using stateless DHCPv6 [RFC3736]. If the cellular host receives the DNS information in several channels, the following preference order MUST be followed: 1. PCO 2. RA 3. DHCPv6 > >- Jouni > > > >>=20 >>=20 >> Kind Regards, >> Masataka MAWATARI >>=20 >>=20 >> * On Mon, 24 Sep 2012 15:12:56 +0200 >> * wrote: >>=20 >>> Re-, >>>=20 >>> We submitted a new version of the I-D integrating the=20 >comments received in the list. In particular, the following=20 >changes are made in -02: >>>=20 >>> * DNS64 requirement is now a SHOULD as suggested by Ted >>> * Add a new requirement to RFC5555 as suggested by H. Soliman >>> * Remove the requirement about ND Proxy but instead a new=20 >paragraph has been added to describe the problem raised to share /64 >>> * Add a new requirement for RFC4191 as suggested by L.=20 >Colliti, Behcet and Jouni >>> * Correct a typo about DHCP client (3315). >>> * Welcome new co-authors >>>=20 >>> A detailed diff is available at:=20 >http://www.ietf.org/rfcdiff?url2=3Ddraft-binet-v6ops-cellular-hos >t-reqs-rfc3316update-02 >>>=20 >>> The new version is available at:=20 >http://tools.ietf.org/id/draft-binet-v6ops-cellular-host-reqs-r >fc3316update-02.txt >>>=20 >>> Cheers, >>> Med >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > >= From lorenzo@google.com Thu Sep 27 05:24:48 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF6721F845D for ; Thu, 27 Sep 2012 05:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.752 X-Spam-Level: X-Spam-Status: No, score=-102.752 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NoDvVA-1+Qap for ; Thu, 27 Sep 2012 05:24:46 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0988821F845C for ; Thu, 27 Sep 2012 05:24:45 -0700 (PDT) Received: by oagn5 with SMTP id n5so2076362oag.31 for ; Thu, 27 Sep 2012 05:24:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=27rJDrzQCbz6wKcStnTZOlP9+4/LhYiZoQWYB3KiCAw=; b=Ff/OGSlG79kz2TlyQ/hL7+i3cCWjubjoQy3CVOVd2tByAYQbwryae9zL9+K5tuHqjN 2X/EcnFS7LX7TxEbXa7noaGzH8TngQQ9CJF6VF8RisNHUOzygfnCi9eKIzoFQQLmNa4u Jz1IJn7ydzo5Dd+IsqLZuSC8Ar1l+gtvn5Jo6CXD9juYEFeui/RkUcd6IvPr5Ba+w2LI wv4xSfuMpriTyvafWSfUnRI0B3YbjiEZGkP1NUZEqNFt9/qojL+/nv9UGLdXraZjJHJ8 rpcNLr0qchxqj08QO8WxIPgnh1XnVxRxxzwWrN9PYfpvrpvbBtmMqplV00HoXkOMduVJ zGSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=27rJDrzQCbz6wKcStnTZOlP9+4/LhYiZoQWYB3KiCAw=; b=AJ2h/uNKG8gzfqbawBXfQNRfs9DusXJR39Bznnasi4LlJQStLEEk9Wzp3pWVyllwS+ oUeHPGjdpSnllJdSpG/7vEqM0mItPQDbSLmAlO4NHRn3NILpPE1v3pK1yUxD14brKfQD rXQT9E1NAl8Liy3jyGJna16rCjE68vuQRW2/sv4QS4+osnRBKlFLx7sRJUHwtP+YcJWB V69cmkWmSo+iLw7/e3n05ML4Onl7OEYgZaDvorKe9iG8ceKqIi3eearKgPRQzekB3XB2 hfITQ2xrkx0vH8ZrldB5ZYrXvcMKg30H/qrxBLEaRImKfEPqbjcMk5euaGFQJcJ4MrqM uGIQ== Received: by 10.60.29.202 with SMTP id m10mr2966638oeh.11.1348748685604; Thu, 27 Sep 2012 05:24:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.225.98 with HTTP; Thu, 27 Sep 2012 05:24:25 -0700 (PDT) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E5E44DED0@PUEXCB1B.nanterre.francetelecom.fr> References: <1B2E7539FECD9048B261B791B1B24A7C3EBE458308@PUEXCB1A.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E5B123A8C@PUEXCB1B.nanterre.francetelecom.fr> <20120925133859.15A2.8FE1F57E@jpix.ad.jp> <523CF185-5C72-4299-B4DA-3CEDBA7466D3@gmail.com> <94C682931C08B048B7A8645303FDC9F36E5E44DED0@PUEXCB1B.nanterre.francetelecom.fr> From: Lorenzo Colitti Date: Thu, 27 Sep 2012 21:24:25 +0900 Message-ID: To: mohamed.boucadair@orange.com Content-Type: multipart/alternative; boundary=e89a8ff1c1444bf63904caae06b7 X-System-Of-Record: true X-Gm-Message-State: ALoCoQn38Hxvhutw3hGeZg8cdO/akVrHAwpESIAOVkpkgjcfdvdwwqpMaRKHUzbKCPbY2tl4RxzGujo7v1iNE3y3RFXnPU1+kumB6O8Qb19lJGAz85yt0Ee+2sWB2nZcRr42oSnG8RsIFFcynDvIju/O97Y6MY6v4p2kOQ2qHdZsDGX4uSYwcp+YoP+lOowrRv7nCddz9Hsi Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2012 12:24:48 -0000 --e89a8ff1c1444bf63904caae06b7 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Sep 27, 2012 at 3:04 PM, wrote: > If the cellular host receives the DNS information in > several channels, the following preference order MUST > be followed: > 1. PCO > 2. RA > 3. DHCPv6 Why does this order need to be specified in this document? --e89a8ff1c1444bf63904caae06b7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Sep 27, 2012 at 3:04 PM, <mohamed.boucadair@orange.com= > wrote:
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0If the cellular host receives the DNS in= formation in
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0several channels, the following preferen= ce order MUST
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0be followed:
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A01. =A0 =A0 PCO
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A02. =A0 =A0 RA
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A03. =A0 =A0 DHCPv6

    <= /div>
    Why does this order need to be specified in this document?
    <= /div> --e89a8ff1c1444bf63904caae06b7-- From mohamed.boucadair@orange.com Thu Sep 27 05:38:53 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 353D021F860F for ; Thu, 27 Sep 2012 05:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.972 X-Spam-Level: X-Spam-Status: No, score=-1.972 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, SARE_SUB_OBFU_Q1=0.227, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o78hsW-6aDqK for ; Thu, 27 Sep 2012 05:38:52 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 565EB21F85A8 for ; Thu, 27 Sep 2012 05:38:52 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 3533122C68C; Thu, 27 Sep 2012 14:38:51 +0200 (CEST) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id F3EFB35C0DE; Thu, 27 Sep 2012 14:38:50 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Thu, 27 Sep 2012 14:38:50 +0200 From: To: Lorenzo Colitti Date: Thu, 27 Sep 2012 14:38:49 +0200 Thread-Topic: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update Thread-Index: Ac2cqxY9eSEM6wG3Qi2fPnF0ft+ZbQAAGOHQ Message-ID: <94C682931C08B048B7A8645303FDC9F36E5E44E1D7@PUEXCB1B.nanterre.francetelecom.fr> References: <1B2E7539FECD9048B261B791B1B24A7C3EBE458308@PUEXCB1A.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E5B123A8C@PUEXCB1B.nanterre.francetelecom.fr> <20120925133859.15A2.8FE1F57E@jpix.ad.jp> <523CF185-5C72-4299-B4DA-3CEDBA7466D3@gmail.com> <94C682931C08B048B7A8645303FDC9F36E5E44DED0@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: 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_94C682931C08B048B7A8645303FDC9F36E5E44E1D7PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.9.27.113630 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2012 12:38:53 -0000 --_000_94C682931C08B048B7A8645303FDC9F36E5E44E1D7PUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Lonezo, As there are several channels which may be used to provision the dns info, = we thought it is useful to provide a guideline for the host which informati= on to select. This modification is only added in my local copy. If you think this is not = a good idea or it does not make senses, etc, your comment is welcome. Cheers, Med ________________________________ De : Lorenzo Colitti [mailto:lorenzo@google.com] Envoy=E9 : jeudi 27 septembre 2012 14:24 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : jouni korhonen; MAWATARI Masataka; v6ops@ietf.org Objet : Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update On Thu, Sep 27, 2012 at 3:04 PM, > wrote: If the cellular host receives the DNS information in several channels, the following preference order MUST be followed: 1. PCO 2. RA 3. DHCPv6 Why does this order need to be specified in this document? --_000_94C682931C08B048B7A8645303FDC9F36E5E44E1D7PUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    Dear Lonezo,
     
    As there are several channels which may be us= ed to=20 provision the dns info, we thought it is useful to provide a guid= eline=20 for the host which information to select.
     
    This modification is only added in my local c= opy. If=20 you think this is not a good idea or it does not make senses, etc, your com= ment=20 is welcome.
     
    Cheers,
    Med
     

    De : Lorenzo Colitti=20 [mailto:lorenzo@google.com]
    Envoy=E9 : jeudi 27 septembre= 2012=20 14:24
    =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP
    Cc := =20 jouni korhonen; MAWATARI Masataka; v6ops@ietf.org
    Objet : = Re:=20 [v6ops]=20 draft-binet-v6ops-cellular-host-reqs-rfc3316update

    On Thu, Sep 27, 2012 at 3:04 PM, <mohamed.boucadair@orange.com> wrote:
                  &nbs= p;=20  If the cellular host receives the DNS information in
      &n= bsp;=20              several channels, the=20 following preference order MUST
              &= nbsp;=20      be followed:
             = =20        1.     PCO
         = =20            2.     RA
     = =20                3.    = =20 DHCPv6

    Why does this order need to be specified in this=20 document?
    --_000_94C682931C08B048B7A8645303FDC9F36E5E44E1D7PUEXCB1Bnante_-- From rajiva@cisco.com Thu Sep 27 06:37:51 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C95221F8512 for ; Thu, 27 Sep 2012 06:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.185 X-Spam-Level: X-Spam-Status: No, score=-10.185 tagged_above=-999 required=5 tests=[AWL=-0.414, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qiC64ghD0oW for ; Thu, 27 Sep 2012 06:37:46 -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 5A95E21F84EB for ; Thu, 27 Sep 2012 06:37:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6471; q=dns/txt; s=iport; t=1348753066; x=1349962666; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=pIHuVSjKcpaSAFejiUw0UV+7eCVmKPtXtps9uA8Q4p0=; b=bo9HAfyRTH//6lZY1h+Ucd+/DH22Jsq5/tHjfHg0RYFqQr9ZxH1qKG+Q S3ftv8IND++L4WthHK8tsIkgKfqHCeRrxkcwqKw2mBfW/uA/jDUDOJwV0 r4RBBFmFj7W6nPPUD121HXAChSPabzMPZhOh6L+78uy1Sy1lnd4RTl4Nu U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EACRWZFCtJV2Y/2dsb2JhbABFvgWBCIIhAQEEAQEBDwFbCxACAQg/BycLFBEBAQQOBSKHYwuYJJ97BIsYhT1gA4gjihWDMY5CgWmCZw X-IronPort-AV: E=Sophos;i="4.80,495,1344211200"; d="scan'208,217";a="125947904" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP; 27 Sep 2012 13:37:46 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q8RDbjAl018102 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 27 Sep 2012 13:37:45 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.230]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0298.004; Thu, 27 Sep 2012 08:37:45 -0500 From: "Rajiv Asati (rajiva)" To: "mohamed.boucadair@orange.com" Thread-Topic: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update Thread-Index: Ac2a9Fg0kygjt2tHRWm0TALPSDGcNgBgMHlAABf1q4AAAIC/gP//vKTd Date: Thu, 27 Sep 2012 13:37:44 +0000 Message-ID: <7070F69F-060D-44BF-9B05-A95E876F241D@cisco.com> References: <1B2E7539FECD9048B261B791B1B24A7C3EBE458308@PUEXCB1A.nanterre.francetelecom.fr> <94C682931C08B048B7A8645303FDC9F36E5B123A8C@PUEXCB1B.nanterre.francetelecom.fr> <20120925133859.15A2.8FE1F57E@jpix.ad.jp> <523CF185-5C72-4299-B4DA-3CEDBA7466D3@gmail.com> <94C682931C08B048B7A8645303FDC9F36E5E44DED0@PUEXCB1B.nanterre.francetelecom.fr> , <94C682931C08B048B7A8645303FDC9F36E5E44E1D7@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E5E44E1D7@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19214.004 x-tm-as-result: No--35.908500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_7070F69F060D44BF9B05A95E876F241Dciscocom_" MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2012 13:37:51 -0000 --_000_7070F69F060D44BF9B05A95E876F241Dciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I actually don't mind this being listed, given that it is bout Cheers, Rajiv Sent from my Phone On Sep 27, 2012, at 8:39 AM, "mohamed.boucadair@orange.com" > wrote: Dear Lonezo, As there are several channels which may be used to provision the dns info, = we thought it is useful to provide a guideline for the host which informati= on to select. This modification is only added in my local copy. If you think this is not = a good idea or it does not make senses, etc, your comment is welcome. Cheers, Med ________________________________ De : Lorenzo Colitti [mailto:lorenzo@google.com] Envoy=E9 : jeudi 27 septembre 2012 14:24 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : jouni korhonen; MAWATARI Masataka; v6ops@ietf.org Objet : Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update On Thu, Sep 27, 2012 at 3:04 PM, > wrote: If the cellular host receives the DNS information in several channels, the following preference order MUST be followed: 1. PCO 2. RA 3. DHCPv6 Why does this order need to be specified in this document? _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops --_000_7070F69F060D44BF9B05A95E876F241Dciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    I actually don't mind this being listed, given that it is bout 
    Cheers,
    Rajiv

    Sent from my Phone

    On Sep 27, 2012, at 8:39 AM, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com> wrote:

    Dear Lonezo,<= /div>
     
    As there are several channe= ls which may be used to provision the dns info, we thought it is usefu= l to provide a guideline for the host which information to select.
     
    This modification is only a= dded in my local copy. If you think this is not a good idea or it does not = make senses, etc, your comment is welcome.
     
    Cheers,
    Med
     

    De : Lorenzo Colitti [mailto:l= orenzo@google.com]
    Envoy=E9 : jeudi 27 septembre 2012 14:24
    =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP
    Cc : jouni korhonen; MAWATARI Masataka; v6ops@ietf.org
    Objet : Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc331= 6update

    On Thu, Sep 27, 2012 at 3:04 PM, <mohamed.boucadair@orange.com<= /a>> wrote:
                     If the cellul= ar host receives the DNS information in
                     several chann= els, the following preference order MUST
                     be followed:<= br>                  1.   &nb= sp; PCO
                     2.   &nb= sp; RA
                     3.   &nb= sp; DHCPv6

    Why does this order need to be specified in this document?
    --_000_7070F69F060D44BF9B05A95E876F241Dciscocom_-- From fgont@si6networks.com Thu Sep 27 11:26:43 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 502CD21F866B for ; Thu, 27 Sep 2012 11:26:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cH7PsKOhKO-r for ; Thu, 27 Sep 2012 11:26:41 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id AFCB021F8685 for ; Thu, 27 Sep 2012 11:26:39 -0700 (PDT) Received: from 217.64.252.202.mactelecom.net ([217.64.252.202] helo=[10.4.2.187]) by web01.jbserver.net with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1THInC-00054q-MJ; Thu, 27 Sep 2012 20:26:34 +0200 Message-ID: <50649A58.20705@si6networks.com> Date: Thu, 27 Sep 2012 20:26:32 +0200 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: "Marksteiner, Stefan" References: <8A317FD8C00FEE448E52D4EE5B56BB3E0232A086D8FF@RZJC1EX.jr1.local>, <1348519034.47465.YahooMailNeo@web32503.mail.mud.yahoo.com> <8A317FD8C00FEE448E52D4EE5B56BB3E0232A086D902@RZJC1EX.jr1.local> In-Reply-To: <8A317FD8C00FEE448E52D4EE5B56BB3E0232A086D902@RZJC1EX.jr1.local> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] Operational guidelines for a company/organization IPv6 address scheme supplemental to RFC5157 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2012 18:26:43 -0000 Stefan, On 09/25/2012 11:42 AM, Marksteiner, Stefan wrote: > First of all I think I've forgotten to clarify that I'm talking about > IIDs, sorry ;) The aim of my thoughts would be to make it harder for > externals to scan for attackable addresses. If so, you should implement draft-ietf-6man-stable-privacy-addresses > One often cited (mostly > by marketeers) benefit of IPv6 is the vast amount of addresses per > subnet making it seemingly harder to scan, which would be nullified > if companies used simple sequential addressing. It's also nullified for other reasons. Please see: > I'm suggesting to recommend companies to use a different scheme as > ::1;::2 or ::BABE;::CAFE or even ::4593;4594 and so on which > according to some studies (e.g. [1], pp.65-75, especially 68) most > administrators unfortunately do. What might be needed to change this > would be a scheme which is practicably administrable in the easiest > possible way. draft-ietf-6man-stable-privacy-addresses aims at exactly that. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fgont@si6networks.com Thu Sep 27 11:43:17 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 054A921F84C5 for ; Thu, 27 Sep 2012 11:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NyglSY7TcivC for ; Thu, 27 Sep 2012 11:43:14 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 63EB121F84FE for ; Thu, 27 Sep 2012 11:43:14 -0700 (PDT) Received: from 217.64.252.202.mactelecom.net ([217.64.252.202] helo=[10.4.2.187]) by web01.jbserver.net with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1THJ3G-0005X1-Ny; Thu, 27 Sep 2012 20:43:10 +0200 Message-ID: <50649E3D.6090402@si6networks.com> Date: Thu, 27 Sep 2012 20:43:09 +0200 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: "Marksteiner, Stefan" References: <8A317FD8C00FEE448E52D4EE5B56BB3E0232A086D8FF@RZJC1EX.jr1.local>, <1348519034.47465.YahooMailNeo@web32503.mail.mud.yahoo.com> <8A317FD8C00FEE448E52D4EE5B56BB3E0232A086D902@RZJC1EX.jr1.local>, <5061B157.1090106@gmail.com> <8A317FD8C00FEE448E52D4EE5B56BB3E0232A086D90A@RZJC1EX.jr1.local> <1348602134.63605.YahooMailNeo@web32505.mail.mud.yahoo.com> <8A317FD8C00FEE448E52D4EE5B56BB3E0232A08499BB@RZJC1EX.jr1.local> In-Reply-To: <8A317FD8C00FEE448E52D4EE5B56BB3E0232A08499BB@RZJC1EX.jr1.local> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 'IPv6 Ops WG' Subject: Re: [v6ops] Operational guidelines for a company/organization IPv6 address scheme supplemental to RFC5157 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2012 18:43:17 -0000 On 09/26/2012 09:16 AM, Marksteiner, Stefan wrote: > There's a variety of reasons to keep track of addresses from usage > and statistics to forensic purposes in security incidents (also those > which are perpetrated from inside sources to outside targets). You might want to use ipv6mon for that: > Privacy extensions would perhaps be too unpredictable to manage, but > stateful DHCPv6 combined with a suitable IPAM-solution would probably > do the trick. Maybe I have been stuck in my mindset a little, as we > use only static addresses in our productive IPv4 network. Either the above, and/or implement draft-ietf-6man-stable-privacy-addresses Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From akapoor@cisco.com Thu Sep 27 23:35:43 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 941CE21F854F for ; Thu, 27 Sep 2012 23:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.372 X-Spam-Level: X-Spam-Status: No, score=-10.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZBNsafMw7ptp for ; Thu, 27 Sep 2012 23:35:42 -0700 (PDT) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id 050AC21F84F1 for ; Thu, 27 Sep 2012 23:35:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1400; q=dns/txt; s=iport; t=1348814142; x=1350023742; h=from:to:cc:subject:references:date:in-reply-to: message-id:mime-version; bh=Ej/dohIIQodfkKHGQyuqdfguKwQQWSqDulxxjIxF9lc=; b=YYoxHeYH9FxO3ilV1nB5wcdRVEI30j4tdgDHzxyigrPF9t4NgsHtDLVB 6+ThDurdCy06525kseOhYyZ1c+sUA/xgWTQkKbn5DBC2FH2XLhJKVy9nE +nIAH1G5mcy6Lt3cV1Qd9l9EoJwKMUIa7hF21dUuDZDJSoUZPYxw3LxQI g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0EAOFDZVBIo8UY/2dsb2JhbABFvxaCIQEBBBIBZhALIQQPEg8BBEkLKodjmDmgI44fgyADiFaNE45CgWmCbw X-IronPort-AV: E=Sophos;i="4.80,499,1344211200"; d="scan'208";a="18060622" Received: from vla196-nat.cisco.com (HELO bgl-core-4.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 28 Sep 2012 06:35:39 +0000 Received: from fatcat.cisco.com ([64.103.156.27]) by bgl-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q8S6ZcuN010594 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 28 Sep 2012 06:35:39 GMT From: Anupam Kapoor To: References: <94C682931C08B048B7A8645303FDC9F36E5A40D46C@PUEXCB1B.nanterre.francetelecom.fr> Date: Fri, 28 Sep 2012 12:05:38 +0530 In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E5A40D46C@PUEXCB1B.nanterre.francetelecom.fr> (mohamed boucadair's message of "Thu, 20 Sep 2012 09:00:38 +0200") Message-ID: <87txuifydh.fsf@fatcat.cisco.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2012 06:35:43 -0000 ,----[ mohamed.boucadair ] | Review and comments are more than welcome. `---- ,----[ draft-binet-v6ops-cellular-host-reqs-rfc3316update ] | REQ#3: The cellular host MUST comply with the behavior defined in | [TS.23060] and [TS.24008] in terms of requested PDP context type. | In particular the cellular host MUST request an IPv6 PDP context | if the cellular host is IPv6-only and requesting an IPv4v6 PDP | context if the cellular host is dual stack or when the cellular | host is not aware of connectivity types requested by devices | connected to it (e.g., cellular host with LAN capabilities): | | * If the requested PDP context IPv4v6 is not supported but IPv4 | and IPv6 PDP types are allowed, the cellular host is configured | with an IPv4 address or an IPv6 prefix. It MAY initiate | another PDP request than the one already activated for a given | APN. | | * If the requested PDP type and subscription data allows only one | IP address family (IPv4 or IPv6), the cellular host MUST NOT | request a second PDP context to the same APN for the other IP | address family. `---- multiple pdn connections to the same apn is allowed from the same ue. may you please explain the reasoning for the second item above ? thank you kind regards anupam From david.binet@orange.com Fri Sep 28 00:18:47 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A08521F8567 for ; Fri, 28 Sep 2012 00:18:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.571 X-Spam-Level: X-Spam-Status: No, score=-1.571 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, SARE_SUB_OBFU_Q1=0.227, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q8jpJTVu0Fa8 for ; Fri, 28 Sep 2012 00:18:47 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id A984F21F8518 for ; Fri, 28 Sep 2012 00:18:45 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 66D8922C4B7; Fri, 28 Sep 2012 09:18:44 +0200 (CEST) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 4C3104C069; Fri, 28 Sep 2012 09:18:44 +0200 (CEST) Received: from PUEXCB1A.nanterre.francetelecom.fr ([10.101.44.12]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Fri, 28 Sep 2012 09:18:42 +0200 From: To: Anupam Kapoor , BOUCADAIR Mohamed OLNC/NAD/TIP Date: Fri, 28 Sep 2012 09:18:40 +0200 Thread-Topic: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update Thread-Index: Ac2dQ4Q7QRt2U8qZRwml+bDWEqgsOgABPygg Message-ID: <23168_1348816724_50654F54_23168_1007_1_1B2E7539FECD9048B261B791B1B24A7C3EBFDBEFA6@PUEXCB1A.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36E5A40D46C@PUEXCB1B.nanterre.francetelecom.fr> <87txuifydh.fsf@fatcat.cisco.com> In-Reply-To: <87txuifydh.fsf@fatcat.cisco.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.19.115414 Cc: IPv6 Ops WG Subject: Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2012 07:18:47 -0000 Hi Anupam The second item does not question the capability to establish multiple pdn = connexions for a given apn but as far as IPv6 introduction is concerned, th= e cellular host must not request a new PDN connexion for the other version = of IP protocol (let say IPv4 for example) if registration data mandates onl= y one IP adress family (IPv6 for example) for this cellular host.=20 David=20=20 > -----Message d'origine----- > De : v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org]=20 > De la part de Anupam Kapoor > Envoy=E9 : vendredi 28 septembre 2012 08:36 > =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP > Cc : IPv6 Ops WG > Objet : Re: [v6ops] draft-binet-v6ops-cellular-host-reqs-rfc3316update >=20 >=20 > ,----[ mohamed.boucadair ] > | Review and comments are more than welcome. > `---- > ,----[ draft-binet-v6ops-cellular-host-reqs-rfc3316update ] > | REQ#3: The cellular host MUST comply with the behavior=20 > defined in > | [TS.23060] and [TS.24008] in terms of requested PDP=20 > context type. > | In particular the cellular host MUST request an IPv6=20 > PDP context > | if the cellular host is IPv6-only and requesting an IPv4v6 PDP > | context if the cellular host is dual stack or when=20 > the cellular > | host is not aware of connectivity types requested by devices > | connected to it (e.g., cellular host with LAN capabilities): > |=20 > | * If the requested PDP context IPv4v6 is not=20 > supported but IPv4 > | and IPv6 PDP types are allowed, the cellular host=20 > is configured > | with an IPv4 address or an IPv6 prefix. It MAY initiate > | another PDP request than the one already activated=20 > for a given > | APN. > |=20 > | * If the requested PDP type and subscription data=20 > allows only one > | IP address family (IPv4 or IPv6), the cellular=20 > host MUST NOT > | request a second PDP context to the same APN for=20 > the other IP > | address family. > `---- > multiple pdn connections to the same apn is allowed from the=20 > same ue. may you please explain the reasoning for the second=20 > item above ? >=20 > thank you > kind regards > anupam > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From phdgang@gmail.com Fri Sep 28 04:13:52 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9836521F85C4 for ; Fri, 28 Sep 2012 04:13:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.093 X-Spam-Level: X-Spam-Status: No, score=-3.093 tagged_above=-999 required=5 tests=[AWL=-0.094, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8t-b6ObE5iq1 for ; Fri, 28 Sep 2012 04:13:51 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 53E2E21F85C2 for ; Fri, 28 Sep 2012 04:13:51 -0700 (PDT) Received: by vbbfc26 with SMTP id fc26so3372355vbb.31 for ; Fri, 28 Sep 2012 04:13:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dcFyFL9hJlWAJxo5HPH89ZquJKCMbxsoab4mMUE7nJg=; b=wJOpECi8MDsGFF77ZHsQzAHaVAG35eIH6IMq7vF2LyorG0X4P3urBoce7FVqmgo8Mi luK8qWEVloHqv6HXg3g/bBYcNJL8NhBd8Jhl/ljnIFIX/ROwJIHLJZzxnbjoZ8v4e/tP rNzBpHTegf+fm9O4zf4HhYjInHAwrTcJUEL7T/Odjdalg0Vf/ziyo/0wtKzcClUM6Zda bKMepFE2KdMUukiXyGzUOn+wXj2gH9cb9Tu+Nf6qlMJOStoFBuI1N+C5kyBhLWzIzzff aRstR5VmbjZXqX2Bnaedy0WIzxAQ8PsNnKLwKxtXMuCk06vnVAH8rhKBA42dB8ABQrjd 7+HQ== MIME-Version: 1.0 Received: by 10.52.23.199 with SMTP id o7mr1614381vdf.129.1348830830415; Fri, 28 Sep 2012 04:13:50 -0700 (PDT) Received: by 10.58.114.231 with HTTP; Fri, 28 Sep 2012 04:13:50 -0700 (PDT) In-Reply-To: <505BA147.1040003@bogus.com> References: <505BA147.1040003@bogus.com> Date: Fri, 28 Sep 2012 19:13:50 +0800 Message-ID: From: GangChen To: joel jaeggli Content-Type: text/plain; charset=ISO-8859-1 Cc: IPv6 Ops WG Subject: Re: [v6ops] remote participation at Sept 29th LIM X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2012 11:13:52 -0000 Is there anyone aware of the meetecho link to this remote participation? Many thanks Gang 2012/9/21, joel jaeggli : > Remote participation in the v6ops LIM meeting 1330-1630 CESTwill be > enabled by meetecho. > > If you haven't familiarized yourself with the client, you might want to > cruise the instructions available from ietf 83. > > http://ietf83.conf.meetecho.com/index.php/Web_Client > > In particular I'd note that if you have a mac running 10.7 or 10.8 you > should probably make sure that java is installed since it's no longer > packaged with the os install by default. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From evyncke@cisco.com Fri Sep 28 04:59:18 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B327821F85EF; Fri, 28 Sep 2012 04:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4tXsN4ODdQgL; Fri, 28 Sep 2012 04:59:17 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 6691121F84EA; Fri, 28 Sep 2012 04:59:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3291; q=dns/txt; s=iport; t=1348833557; x=1350043157; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=k8zPZFA7G99PmhW631upai5SKi7Lf/BeFjiqFV9Oa+4=; b=WIo2F57sH9ClwZy+PiH0dHclLwMx6rd3xtf1MgOi6009Je9fe9zabzLZ 8SoDx+kxXVvm80l8h54BrowHV7vqDNbfbu0wJ41pjc63/z+oiUcPg4DPW oQ0iKv1Wrznzz/ZLwvHx0gGU00uAMt4Wb7oA72bw031qI76WvIZLQthi8 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAD+QZVCtJXG9/2dsb2JhbABFvg6BCIIgAQEBBAEBAQ8BNiUXBAIBCBEEAQELHQcnCxQJCAIEARIIARmHYwuXbqAqixiFR2ADiCOcCIFpgmeBWgQ5 X-IronPort-AV: E=Sophos;i="4.80,502,1344211200"; d="scan'208,223";a="126330244" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-7.cisco.com with ESMTP; 28 Sep 2012 11:59:17 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q8SBxGAo002588 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 28 Sep 2012 11:59:16 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.26]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0298.004; Fri, 28 Sep 2012 06:59:16 -0500 From: "Eric Vyncke (evyncke)" To: IETF Secretariat , "opsec@ietf.org" , "v6ops@ietf.org" Thread-Topic: [OPSEC] IETF Large Interim Meeting - OPSEC, SIDR and V6OPS Thread-Index: AQHNm/ic4ZMPgDd4lECEBlqdIyqPGJefqIHw Date: Fri, 28 Sep 2012 11:59:15 +0000 Message-ID: <97EB7536A2B2C549846804BBF3FD47E11183738F@xmb-aln-x02.cisco.com> References: <20120926150705.8596.75260.idtracker@ietfa.amsl.com> In-Reply-To: <20120926150705.8596.75260.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.90.219] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19216.004 x-tm-as-result: No--48.802400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] [OPSEC] IETF Large Interim Meeting - OPSEC, SIDR and V6OPS X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2012 11:59:18 -0000 >From what I gathered, the agenda for OPSEC and V6OPS will be shorter than t= heir allocated length. If this is the case, then may I suggest to group OPSEC & V6OPS on the Satur= day morning slot? This would probably allow several people to return home e= arlier (especially after 5 days of RIPE) and would also allow for a more ef= ficient use of our time. Just my 0,01 EUR -=E9ric > -----Original Message----- > From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] On Behalf Of > IETF Secretariat > Sent: mercredi 26 septembre 2012 17:07 > To: opsec@ietf.org; v6ops@ietf.org; sidr@ietf.org > Subject: [OPSEC] IETF Large Interim Meeting - OPSEC, SIDR and V6OPS >=20 > OPSEC, SIDR and V6OPS Interim Meeting > Amsterdam, The Netherlands > 29 September 2012 > Venue: Hotel Okura Amsterdam (www.okura.nl) > Ferdinand Bolstraat 333 > 1072 LH Amsterdam > The Netherlands >=20 > 1. Registration > 2. Accommodations > 3. Meeting Schedule >=20 > 1. Registration > A. Fee: $100 USD > B. Register online at: http://www.ietf.org/registration/lim2012/ietfreg= .py > C. Online Registration and Payment closes on 28 September 2012 D. On = Site > Registration starting Saturday, 29 September at 8:00 AM >=20 > 2. Accommodations > A block of rooms is being held at the Hotel Okura Amsterdam (meeting ven= ue) > for the nights of September 28 and 29. > Rate: 195 EUR [256 USD; 20,065 JPY] > Rate includes breakfast and guest room wireless internet but excludes = 5% > city tax. > To make your reservation on line, please go to: www.okura.nl > Group Code: IETF2012 >=20 > Guest Cancellation: > - Reservations may be changed up to 1 week prior to the event without > penalty. (You can change, not cancel, the reservation, i.e. change arriva= l, > departure dates or name, up to 1 week without penalty but not cancel the > reservation without penalty.) > - 50% of reservation value penalty for cancellation less than 14 days an= d > greater than 7 days prior to event. If you cancel, not change, the > reservation less than 14 days but more than 7 days prior to the event you > will be charged 50% of the total reservation fee. > - 80% of reservation value penalty for cancellation less than 7 days and > greater than 3 days prior to event. If you cancel, not change, the > reservation less than 7 days prior to the event you will be charged 80% o= f > the total reservation fee. > - 100% of reservation value penalty for cancellation less than 3 days pr= ior > to event or non-arrival or no-show. > - In case of early departure, the full value of the reservation will be > charged to the guest. >=20 > If you have any problems making your reservation, please send a message t= o > agenda@ietf.org >=20 > 3. Meeting Agenda > 0800-1700 Okura Foyer Registration > 0830-0900 Okura Foyer AM Coffee > 0900-1130 Room: Otter SIDR > 0900-1130 Room: Heian I OPSEC > 1030-1100 Okura Foyer AM Break >=20 > 1130-1330 On Own Lunch Break >=20 > 1330-1700 Room: Otter SIDR > 1330-1700 Room: Heian I V6OPS > 1500-1530 Okura Foyer PM Break > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec From aservin@lacnic.net Fri Sep 28 05:29:31 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C2B321F85EF for ; Fri, 28 Sep 2012 05:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.3 X-Spam-Level: X-Spam-Status: No, score=-3.3 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qwo19dF3KRdt for ; Fri, 28 Sep 2012 05:29:30 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB9221F85BB for ; Fri, 28 Sep 2012 05:29:30 -0700 (PDT) Received: from 85-7-200.lacnic.net.uy (unknown [IPv6:2001:13c7:7001:5128:d011:eb92:96d5:d581]) by mail.lacnic.net.uy (Postfix) with ESMTP id 3485A30841C for ; Fri, 28 Sep 2012 09:29:22 -0300 (UYT) Message-ID: <50659822.5030808@lacnic.net> Date: Fri, 28 Sep 2012 09:29:22 -0300 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: v6ops@ietf.org References: <505BA147.1040003@bogus.com> In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Subject: Re: [v6ops] remote participation at Sept 29th LIM X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2012 12:29:31 -0000 Here: http://ietf-lim.conf.meetecho.com/ Regards, as On 28/09/2012 08:13, GangChen wrote: > Is there anyone aware of the meetecho link to this remote participation? > > Many thanks > > Gang > > 2012/9/21, joel jaeggli : >> Remote participation in the v6ops LIM meeting 1330-1630 CESTwill be >> enabled by meetecho. >> >> If you haven't familiarized yourself with the client, you might want to >> cruise the instructions available from ietf 83. >> >> http://ietf83.conf.meetecho.com/index.php/Web_Client >> >> In particular I'd note that if you have a mac running 10.7 or 10.8 you >> should probably make sure that java is installed since it's no longer >> packaged with the os install by default. >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From cb.list6@gmail.com Fri Sep 28 20:09:14 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E13C21F8606 for ; Fri, 28 Sep 2012 20:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.367 X-Spam-Level: X-Spam-Status: No, score=-3.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yeZee4h-vnkk for ; Fri, 28 Sep 2012 20:09:13 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 26C2821F8646 for ; Fri, 28 Sep 2012 20:09:12 -0700 (PDT) Received: by lbok13 with SMTP id k13so2879217lbo.31 for ; Fri, 28 Sep 2012 20:09:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=gMJc5PhIHC6+DXvo+i8ZOztQveYPNd0uko2Yyagjz78=; b=zhCBDWCRK8SySzWR3eFD+t9yjGeR0nm6VvYXBjAe3Wk8LDzhQktxSYNmTtu+i2wQnY SvgQ5Fn6dUauZ9LE6DJyCZh1pxkayjdhuD/LfmNHfxNqXSKUYAS5S8AqLv+MzlDyTWUs 4B/+5ElEIexMCCVRrJxCnnzhqRsqwaPFm+ukacWlg83PswyDMac0sCXDcm8+56LZ8YvC zkf/mEk2VTB8kRAE6X2+59kdMz03//MIIozvZGHGZLz71vjBQvM8Fw8cqoCOnHb56PJL CUJpIvXeA2dmSKlXqnfKLY6cZ905fqWOMPGXXTfMak5m6o4QhgfzP8wFRkv1OJDHvRBl ED9g== MIME-Version: 1.0 Received: by 10.112.48.226 with SMTP id p2mr3303423lbn.26.1348888151995; Fri, 28 Sep 2012 20:09:11 -0700 (PDT) Received: by 10.112.49.66 with HTTP; Fri, 28 Sep 2012 20:09:11 -0700 (PDT) In-Reply-To: <1F4ED938D73A4242BBBB1E7DD492EA0C1687714D47@PMBX03.gsm1900.org> References: <20120928212008.5747.11082.idtracker@ietfa.amsl.com> <1F4ED938D73A4242BBBB1E7DD492EA0C1687714D47@PMBX03.gsm1900.org> Date: Fri, 28 Sep 2012 20:09:11 -0700 Message-ID: From: Cameron Byrne To: IPv6 Ops WG Content-Type: text/plain; charset=ISO-8859-1 Subject: [v6ops] Fwd: FW: New Version Notification for draft-byrne-v6ops-64share-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Sep 2012 03:09:14 -0000 v6ops, As many of you may recall, there was a lot of list traffic on solving the issue how to share a 3GPP mobile interface /64 to a tethered LAN. There was also a clear message that DHCPv6 was a far way off and an interim solution was needed to share the /64 from 3GPP interface to local LAN. This problem was removed from the scope of 464XLAT, and Dan and I wrote an I-D documenting what Dan has submitted to Android Open Source Project for solving this problem. This method is known to work on the T-Mobile USA network using a slightly modified version of Android (link to Nexus S build below). It is also worth noting that Verizon Wireless has been reported to be sharing the 3GPP /64 to tethered LANs, i have no first hand knowledge of how this is achieved. The external behavior sounds the same as this draft, but i cannot confirm. Android code submission https://android-review.googlesource.com/#/c/38390/ Functional IPv6 WLAN tethering Android builds for Nexus S http://dan.drown.org/android/clat/ -00 I-D, your review and comments welcome http://tools.ietf.org/html/draft-byrne-v6ops-64share-00 Thanks, Cameron ________________________________________ From: internet-drafts@ietf.org [internet-drafts@ietf.org] Sent: Friday, September 28, 2012 2:20 PM To: Byrne, Cameron Cc: dan@drown.org Subject: New Version Notification for draft-byrne-v6ops-64share-00.txt A new version of I-D, draft-byrne-v6ops-64share-00.txt has been successfully submitted by Cameron Byrne and posted to the IETF repository. Filename: draft-byrne-v6ops-64share Revision: 00 Title: Sharing /64 3GPP Mobile Interface Subnet to a LAN Creation date: 2012-09-28 WG ID: Individual Submission Number of pages: 5 URL: http://www.ietf.org/internet-drafts/draft-byrne-v6ops-64share-00.txt Status: http://datatracker.ietf.org/doc/draft-byrne-v6ops-64share Htmlized: http://tools.ietf.org/html/draft-byrne-v6ops-64share-00 Abstract: This document describes a known and implemented method of sharing a /64 IPv6 subnet from a 3GPP interface to a tethered LAN. The IETF Secretariat From joelja@bogus.com Fri Sep 28 21:34:22 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90CB821F85C4 for ; Fri, 28 Sep 2012 21:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dKKuj1E6lulB for ; Fri, 28 Sep 2012 21:34:22 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id EE90721F8611 for ; Fri, 28 Sep 2012 21:34:21 -0700 (PDT) Received: from unknown-70-56-81-c1-ee-37.lan (ip56572456.direct-adsl.nl [86.87.36.86]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q8T4YJHr093069 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Sat, 29 Sep 2012 04:34:21 GMT (envelope-from joelja@bogus.com) Message-ID: <50667A45.5020300@bogus.com> Date: Fri, 28 Sep 2012 21:34:13 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20120905 Thunderbird/16.0 MIME-Version: 1.0 To: IPv6 Ops WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sat, 29 Sep 2012 04:34:21 +0000 (UTC) Subject: [v6ops] updated slides for the interim X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Sep 2012 04:34:22 -0000 If anyone else has slides they'd llike to have as part of the record for the meeting can you plesae send them to me in the next couple of hours. Thanks joel From joelja@bogus.com Fri Sep 28 22:06:36 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88F3721F8530 for ; Fri, 28 Sep 2012 22:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1jiGqQOH9ONC for ; Fri, 28 Sep 2012 22:06:35 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 32A8621F852B for ; Fri, 28 Sep 2012 22:06:35 -0700 (PDT) Received: from unknown-70-56-81-c1-ee-37.lan (ip56572456.direct-adsl.nl [86.87.36.86]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q8T56Wmi093756 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Sat, 29 Sep 2012 05:06:34 GMT (envelope-from joelja@bogus.com) Message-ID: <506681D4.2030406@bogus.com> Date: Fri, 28 Sep 2012 22:06:28 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20120905 Thunderbird/16.0 MIME-Version: 1.0 To: IPv6 Ops WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sat, 29 Sep 2012 05:06:34 +0000 (UTC) Subject: [v6ops] meetecho support for the LIM meeting X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Sep 2012 05:06:36 -0000 is here: http://ietf-lim.conf.meetecho.com/ this provides a syncronized view of the jabber room as well as slides and audio. the jabber room is located at: xmpp:v6ops@jabber.ietf.org?join From fred@cisco.com Sat Sep 29 00:25:53 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57A3521F83EF; Sat, 29 Sep 2012 00:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K2-vvWc2CYKM; Sat, 29 Sep 2012 00:25:51 -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 5F50721F8504; Sat, 29 Sep 2012 00:25:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=284; q=dns/txt; s=iport; t=1348903549; x=1350113149; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=WKxCZMC5jufLFOtm0SggHZzxKT9oDNlFtvuXxatwRho=; b=W0ZyOuq/V4Y4yHM2aKyiHjsM/RQugzrkeC/oSQQv4w9jh2L7Wgb1yfCe WcWDEiMSRI17Fs1HhBDtGwBIUvyICI29qXd2kETxpg2wD2zkH44Xo9elX Ml3nr9zzcSsWd1bdEKH3c9tmG71DDTjvf6S21Zojlj8opAj8Hs/tw9V5c A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkwFAEigZlCtJXG8/2dsb2JhbABFhUS4bYEIgicSASc/EgE+QicEDieHYwuZEaALkQpgA5VpgRWNLYFpgmeCFw X-IronPort-AV: E=Sophos;i="4.80,506,1344211200"; d="scan'208";a="126633503" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-5.cisco.com with ESMTP; 29 Sep 2012 07:25:48 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q8T7PmKG026546 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 29 Sep 2012 07:25:48 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.97]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.001; Sat, 29 Sep 2012 02:25:48 -0500 From: "Fred Baker (fred)" To: IPv6 Ops WG Thread-Topic: Review requested, especially from operators Thread-Index: AQHNnhOlCheRYAsFwEyGJ5OK73TSGw== Date: Sat, 29 Sep 2012 07:25:47 +0000 Message-ID: <9995D494-0818-461B-BBC0-53A1974BCA94@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.251.134] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19220.001 x-tm-as-result: No--25.051600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <9AEE9463227A9F4CADFCE34AF71B618B@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "opsec@ietf.org" Subject: [v6ops] Review requested, especially from operators X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Sep 2012 07:25:53 -0000 The authors of http://tools.ietf.org/html/draft-ietf-opsec-v6 "Operational Security Considerations for IPv6 Networks", KK Chittimaneni, Merike Kaeo, Eric Vyncke, 21-Sep-12 are requesting operational review of the document and specific comments. Pl= ease post to opsec.= From fred@cisco.com Sat Sep 29 05:45:02 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CED4121F859E for ; Sat, 29 Sep 2012 05:45:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.486 X-Spam-Level: X-Spam-Status: No, score=-110.486 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HEPQmBPUGnAZ for ; Sat, 29 Sep 2012 05:45: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 0D82121F8476 for ; Sat, 29 Sep 2012 05:45:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=127; q=dns/txt; s=iport; t=1348922700; x=1350132300; h=date:from:message-id:to:subject:cc; bh=1+vR2mRpEWOkQDy9gLTzi4SdvVRA+JJwjTdbwBXqFLU=; b=bs8njhneJzM8Sge8S/afDII0fYgbJ44Dbdyv8jButwXPjCnPOwZ8c79U uuxdMcuz+ukUghagJYJgRxbDzG/YP5OpyIuGJSVSzPMFbU6Yr5y9cLuUR qldKyeNEgCHpRmqLyXMCzIf/AIXbyduIzLaT+Vest6A4CWYdVMW50zY0/ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuAHALvsZlCrRDoH/2dsb2JhbABFhUSnHAGRUIEIgjkBZjwtgQqHYgyZep9xjkqDIAOIWI4mjS2BaYMH X-IronPort-AV: E=Sophos;i="4.80,507,1344211200"; d="scan'208";a="56738036" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 29 Sep 2012 12:45:00 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q8TCj0xB010767; Sat, 29 Sep 2012 12:45:00 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id q8TCj0P22972; Sat, 29 Sep 2012 05:45:00 -0700 (PDT) Date: Sat, 29 Sep 2012 05:45:00 -0700 (PDT) From: Message-Id: <201209291245.q8TCj0P22972@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-byrne-v6ops-64share@tools.ietf.org Subject: [v6ops] new draft: draft-byrne-v6ops-64share X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Sep 2012 12:45:02 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-byrne-v6ops-64share. Please take a look at it and comment. From swmike@swm.pp.se Sat Sep 29 10:35:50 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66D9821F8501 for ; Sat, 29 Sep 2012 10:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rztxH7bTB7I5 for ; Sat, 29 Sep 2012 10:35:50 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id D254321F84FF for ; Sat, 29 Sep 2012 10:35:48 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id BCC359C; Sat, 29 Sep 2012 19:35:39 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id AE4B89A; Sat, 29 Sep 2012 19:35:39 +0200 (CEST) Date: Sat, 29 Sep 2012 19:35:39 +0200 (CEST) From: Mikael Abrahamsson To: fred@cisco.com In-Reply-To: <201209291245.q8TCj0P22972@ftpeng-update.cisco.com> Message-ID: References: <201209291245.q8TCj0P22972@ftpeng-update.cisco.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: v6ops@ietf.org, draft-byrne-v6ops-64share@tools.ietf.org Subject: Re: [v6ops] new draft: draft-byrne-v6ops-64share X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Sep 2012 17:35:50 -0000 On Sat, 29 Sep 2012, fred@cisco.com wrote: > A new draft has been posted, at http://tools.ietf.org/html/draft-byrne-v6ops-64share. Please take a look at it and comment. I have read it and support that it's a valuable topic to publicise an RFC on. The last paragraph of section 3 about MTU makes sense, but I would like to see a little bit more elaboration on why 1440 was chosen (rationale). I understand the rationale, but I am not sure all readers of the document do. -- Mikael Abrahamsson email: swmike@swm.pp.se From evyncke@cisco.com Sat Sep 29 10:58:29 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB91E21F84C2 for ; Sat, 29 Sep 2012 10:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.224 X-Spam-Level: X-Spam-Status: No, score=-10.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQepISO0mghT for ; Sat, 29 Sep 2012 10:58:29 -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 44FF221F8475 for ; Sat, 29 Sep 2012 10:58:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1151; q=dns/txt; s=iport; t=1348941509; x=1350151109; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=moWjNdbfDBD98WM2XuYgOqTDnWXzuDgAhil7e4F6cak=; b=htNJXIyPVRMHOv89owiccYWSSzlk+whfI1cLMrXYgblD62sx5rEWyMmw UtZaN7ERaWy0dFuAih90adL110MxpfA0WjshVGf3PzqQwFZ3LzmAsd8C7 D1IzV9QNy0rMJSHqaWrBhSU60c+5hBxb7zrIvWFLi56OqdODQJPPcopxw w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANs1Z1CtJV2Z/2dsb2JhbABFvjCBCIIgAQEBBAEBAQ8BJzQLDAQCAQgOAwQBAQEKFAkHJwsUCQgCBAENBQgah2MLmiafVosfhWtgA5Z+jS2BaYJngWM0 X-IronPort-AV: E=Sophos;i="4.80,508,1344211200"; d="scan'208";a="126714007" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 29 Sep 2012 17:58:28 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q8THwSnX023235 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 29 Sep 2012 17:58:28 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.62]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.001; Sat, 29 Sep 2012 12:58:28 -0500 From: "Eric Vyncke (evyncke)" To: Mikael Abrahamsson , "Fred Baker (fred)" Thread-Topic: [v6ops] new draft: draft-byrne-v6ops-64share Thread-Index: AQHNnkCsI4aDwSWkh0+ZiGfaWx1r95eh6P6A//+yUuA= Date: Sat, 29 Sep 2012 17:58:27 +0000 Message-ID: <97EB7536A2B2C549846804BBF3FD47E111845262@xmb-aln-x02.cisco.com> References: <201209291245.q8TCj0P22972@ftpeng-update.cisco.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.104.144] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19220.001 x-tm-as-result: No--43.962100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" , "draft-byrne-v6ops-64share@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-byrne-v6ops-64share X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Sep 2012 17:58:30 -0000 Good and concise document indeed, there is a typo in the addresses 2001:db8= :: becomes 2001:db80:: :-) > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Mikael Abrahamsson > Sent: samedi 29 septembre 2012 19:36 > To: Fred Baker (fred) > Cc: v6ops@ietf.org; draft-byrne-v6ops-64share@tools.ietf.org > Subject: Re: [v6ops] new draft: draft-byrne-v6ops-64share >=20 > On Sat, 29 Sep 2012, fred@cisco.com wrote: >=20 > > A new draft has been posted, at http://tools.ietf.org/html/draft-byrne- > v6ops-64share. Please take a look at it and comment. >=20 > I have read it and support that it's a valuable topic to publicise an RFC= on. >=20 > The last paragraph of section 3 about MTU makes sense, but I would like t= o > see a little bit more elaboration on why 1440 was chosen (rationale). I > understand the rationale, but I am not sure all readers of the document d= o. >=20 > -- > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From cb.list6@gmail.com Sat Sep 29 12:26:06 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 979BE21F85BB for ; Sat, 29 Sep 2012 12:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.077 X-Spam-Level: X-Spam-Status: No, score=-3.077 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zcEKn6RmI0xT for ; Sat, 29 Sep 2012 12:26:05 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 657CD21F85B4 for ; Sat, 29 Sep 2012 12:26:05 -0700 (PDT) Received: by lbok13 with SMTP id k13so3336911lbo.31 for ; Sat, 29 Sep 2012 12:26:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4kWmyDNTkhu13Wg8IkgOPuXhK2iJlCNWxWjrqMOSQEo=; b=Ukg9DACkTEREt7zAJTPxnEamgeouaX0kJiCDco/I/Ky7TEnx7VjiQK/9tk3vjs6t+4 VRH8d3704sQ+OxeFske9y0Wn5QEPtPX/KhpRPchwGQzFCUZG6+ek11z0Jo/GTFuZ+RJR VQGiURlJjDhypbRfhQRQTEi4CzGGtsNqw1IPtObjjUahvAl3nbJ02VamhgLt+JBxvD70 nKxr54YAWeirSHoOGRFp6RHHNhqB8pYRR8eKKW0lmIwa/7yhVdDjM4jtuRAGQ+mar725 wa4hYn412lFwRNlu5NIZaLqP8XrGNUYwv46i22cUAku02pM1kMGxRMUu9KzfvvpXqYCO kSQw== MIME-Version: 1.0 Received: by 10.152.132.133 with SMTP id ou5mr8497686lab.45.1348946764290; Sat, 29 Sep 2012 12:26:04 -0700 (PDT) Received: by 10.112.49.66 with HTTP; Sat, 29 Sep 2012 12:26:04 -0700 (PDT) In-Reply-To: References: <201209291245.q8TCj0P22972@ftpeng-update.cisco.com> Date: Sat, 29 Sep 2012 12:26:04 -0700 Message-ID: From: Cameron Byrne To: Mikael Abrahamsson Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops@ietf.org, draft-byrne-v6ops-64share@tools.ietf.org Subject: Re: [v6ops] new draft: draft-byrne-v6ops-64share X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Sep 2012 19:26:06 -0000 On Sat, Sep 29, 2012 at 10:35 AM, Mikael Abrahamsson wrote: > On Sat, 29 Sep 2012, fred@cisco.com wrote: > >> A new draft has been posted, at >> http://tools.ietf.org/html/draft-byrne-v6ops-64share. Please take a look at >> it and comment. > > > I have read it and support that it's a valuable topic to publicise an RFC > on. > > The last paragraph of section 3 about MTU makes sense, but I would like to > see a little bit more elaboration on why 1440 was chosen (rationale). I > understand the rationale, but I am not sure all readers of the document do. > I tried to keep it concise, and the MTU issue is quite important and does require explanation, as you mentioned ... but on thinking it over more, it would be better to simply reference this behavior in the more comprehensive draft-binet-v6ops-cellular-host-reqs-rfc3316update So, i will remove the MTU bit from draft-byrne-v6ops-64share and just make sure it gets covered well in draft-binet-v6ops-cellular-host-reqs-rfc3316update FYI to folks that might be lost here. The 3GPP architecture is heavily reliant on IP-in-IP/UDP tunnels called GTP (GPRS tunneling protocol). More often than not, the infrastructure links are set at 1500 bytes, the cell phone interface is 1500 bytes, and therefore the GTP tunnels packets need to fragmented since they are carrying 1500 byte tunneled packets within an IP packet that will no longer fit on a 1500 byte link. Not pretty. So, sometimes the carriers get the handsets manually set to a lower MTU. And, sometimes the HTTP proxies reset the MSS to avoid fragments. Given that RA can advertise MTU, this is a good opportunity to properly and dynamically set the mobile device's MTU without causing lots of fragment reassembly state in the network or otherwise mucking with MSS. This will also be relevant and true for devices on the tethered LAN since all those packets will be put into the MTU constrained GTP tunnels on their way through the mobile provider and to the Internet. CB > -- > Mikael Abrahamsson email: swmike@swm.pp.se > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From evyncke@cisco.com Sat Sep 29 14:27:19 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2698221F8681 for ; Sat, 29 Sep 2012 14:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.149 X-Spam-Level: X-Spam-Status: No, score=-10.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UvlOEXijJ-Em for ; Sat, 29 Sep 2012 14:27:18 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2BDFA21F867A for ; Sat, 29 Sep 2012 14:27:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3100; q=dns/txt; s=iport; t=1348954038; x=1350163638; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=i4neSGcqt2ezQ66maVn31t3iONUx3luSR+IEJDERweA=; b=GE8LuQ+L9yRMfQ2hZTqur5SQwc+TRZKAi06OpEXwzgLntSX8Gyty0rHF zPACPZ6FNUAg/6XJrtzuZvGwt5ctQSH2XR+39N54uII72wlCQh5sP64nG oMes1wU7QvNAJGuJ/3wG0t7bZD5oX9/44oNZcM2tV+5KH+0epvgmk+A7S Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAAFnZ1CtJV2b/2dsb2JhbABFvjOBCIIgAQEBBAEBAQ8BVAcLDAQCAQgOAwEDAQEBCh0HJwsUAwYIAgQBDQUIGodjC5o/nz2LH4VrYAOII45bjS2BaYJngWM0 X-IronPort-AV: E=Sophos;i="4.80,509,1344211200"; d="scan'208";a="126735033" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 29 Sep 2012 21:27:17 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q8TLRHRa014098 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 29 Sep 2012 21:27:17 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.62]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.001; Sat, 29 Sep 2012 16:27:16 -0500 From: "Eric Vyncke (evyncke)" To: Cameron Byrne , Mikael Abrahamsson Thread-Topic: [v6ops] new draft: draft-byrne-v6ops-64share Thread-Index: AQHNnkCsI4aDwSWkh0+ZiGfaWx1r95eh6P6AgAAe2gD//826IA== Date: Sat, 29 Sep 2012 21:27:16 +0000 Message-ID: <97EB7536A2B2C549846804BBF3FD47E11184A36D@xmb-aln-x02.cisco.com> References: <201209291245.q8TCj0P22972@ftpeng-update.cisco.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.185.66] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19220.001 x-tm-as-result: No--53.537500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" , "draft-byrne-v6ops-64share@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-byrne-v6ops-64share X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Sep 2012 21:27:19 -0000 Isn't it easier to copy the MTU option from the RA received by the handset = to the RA sent on the LAN? Of course, when there is no MTU option in the re= ceived RA on the WAN link, then, a SHOULD set MTU option to 1480 seems good -=E9ric > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Cameron Byrne > Sent: samedi 29 septembre 2012 21:26 > To: Mikael Abrahamsson > Cc: v6ops@ietf.org; draft-byrne-v6ops-64share@tools.ietf.org > Subject: Re: [v6ops] new draft: draft-byrne-v6ops-64share >=20 > On Sat, Sep 29, 2012 at 10:35 AM, Mikael Abrahamsson > wrote: > > On Sat, 29 Sep 2012, fred@cisco.com wrote: > > > >> A new draft has been posted, at > >> http://tools.ietf.org/html/draft-byrne-v6ops-64share. Please take a > >> look at it and comment. > > > > > > I have read it and support that it's a valuable topic to publicise an > > RFC on. > > > > The last paragraph of section 3 about MTU makes sense, but I would > > like to see a little bit more elaboration on why 1440 was chosen > > (rationale). I understand the rationale, but I am not sure all readers = of > the document do. > > >=20 > I tried to keep it concise, and the MTU issue is quite important and does > require explanation, as you mentioned ... but on thinking it over more, i= t > would be better to simply reference this behavior in the more comprehensi= ve > draft-binet-v6ops-cellular-host-reqs-rfc3316update >=20 > So, i will remove the MTU bit from draft-byrne-v6ops-64share and just mak= e > sure it gets covered well in draft-binet-v6ops-cellular-host-reqs- > rfc3316update >=20 > FYI to folks that might be lost here. The 3GPP architecture is heavily > reliant on IP-in-IP/UDP tunnels called GTP (GPRS tunneling protocol). > More often than not, the infrastructure links are set at 1500 bytes, the = cell > phone interface is 1500 bytes, and therefore the GTP tunnels packets need= to > fragmented since they are carrying 1500 byte tunneled packets within an I= P > packet that will no longer fit on a 1500 byte link. Not pretty. So, > sometimes the carriers get the handsets manually set to a lower MTU. And, > sometimes the HTTP proxies reset the MSS to avoid fragments. >=20 > Given that RA can advertise MTU, this is a good opportunity to properly a= nd > dynamically set the mobile device's MTU without causing lots of fragment > reassembly state in the network or otherwise mucking with MSS. This will > also be relevant and true for devices on the tethered LAN since all those > packets will be put into the MTU constrained GTP tunnels on their way thr= ough > the mobile provider and to the Internet. >=20 > CB >=20 > > -- > > Mikael Abrahamsson email: swmike@swm.pp.se > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From cb.list6@gmail.com Sat Sep 29 14:50:53 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D486D21F866B for ; Sat, 29 Sep 2012 14:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.074 X-Spam-Level: X-Spam-Status: No, score=-3.074 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yGlpGKxFwlpn for ; Sat, 29 Sep 2012 14:50:51 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8003021F8669 for ; Sat, 29 Sep 2012 14:50:50 -0700 (PDT) Received: by lbok13 with SMTP id k13so3389196lbo.31 for ; Sat, 29 Sep 2012 14:50:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=grGn6WUo6buzPD1u52Jr0LBVzf5k5NFrw6KjXPXv4CM=; b=ITYXDxlUU4Q976QH/h0Uri1wZrr+Hoy7QX1fg2/Rn8ZWA9zlNqmBziFJaTFqbPoHgk hnaCQJ+TTqjwRp9/X/Wce3FCIYl+f/TzA/uULHdWb+/7T8UOxEvIC6At0URwkTvYzzkX hEWHdWj4I9FFIZ6ntDWKAxIE2/6AFqsmN04XRIzDSiU7Wz1Akhcc5fQ6smeUNwP8WXin bh3DHWpbqnyB0c14SaKB8UEdUdzDh/lX0skDCtT1+4yuYM7POBSP3tMM/KgaSfHTnjXz aU5fECpc+6LjzStVIb7P85r+iCu0hSqZNOL3ojVAQJjNH09K1Bi6xHowHzmI6VTV/fOW wnUA== MIME-Version: 1.0 Received: by 10.152.112.233 with SMTP id it9mr8489963lab.40.1348955449443; Sat, 29 Sep 2012 14:50:49 -0700 (PDT) Received: by 10.112.49.66 with HTTP; Sat, 29 Sep 2012 14:50:49 -0700 (PDT) In-Reply-To: <97EB7536A2B2C549846804BBF3FD47E11184A36D@xmb-aln-x02.cisco.com> References: <201209291245.q8TCj0P22972@ftpeng-update.cisco.com> <97EB7536A2B2C549846804BBF3FD47E11184A36D@xmb-aln-x02.cisco.com> Date: Sat, 29 Sep 2012 14:50:49 -0700 Message-ID: From: Cameron Byrne To: "Eric Vyncke (evyncke)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" , "draft-byrne-v6ops-64share@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-byrne-v6ops-64share X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Sep 2012 21:50:54 -0000 On Sat, Sep 29, 2012 at 2:27 PM, Eric Vyncke (evyncke) wrote: > Isn't it easier to copy the MTU option from the RA received by the handse= t to the RA sent on the LAN? Of course, when there is no MTU option in the = received RA on the WAN link, then, a SHOULD set MTU option to 1480 seems go= od > Yes, this will be the logic that we will bring to the text of draft-binet-v6ops-cellular-host-reqs-rfc3316update CB > -=E9ric > >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf O= f >> Cameron Byrne >> Sent: samedi 29 septembre 2012 21:26 >> To: Mikael Abrahamsson >> Cc: v6ops@ietf.org; draft-byrne-v6ops-64share@tools.ietf.org >> Subject: Re: [v6ops] new draft: draft-byrne-v6ops-64share >> >> On Sat, Sep 29, 2012 at 10:35 AM, Mikael Abrahamsson >> wrote: >> > On Sat, 29 Sep 2012, fred@cisco.com wrote: >> > >> >> A new draft has been posted, at >> >> http://tools.ietf.org/html/draft-byrne-v6ops-64share. Please take a >> >> look at it and comment. >> > >> > >> > I have read it and support that it's a valuable topic to publicise an >> > RFC on. >> > >> > The last paragraph of section 3 about MTU makes sense, but I would >> > like to see a little bit more elaboration on why 1440 was chosen >> > (rationale). I understand the rationale, but I am not sure all readers= of >> the document do. >> > >> >> I tried to keep it concise, and the MTU issue is quite important and doe= s >> require explanation, as you mentioned ... but on thinking it over more, = it >> would be better to simply reference this behavior in the more comprehens= ive >> draft-binet-v6ops-cellular-host-reqs-rfc3316update >> >> So, i will remove the MTU bit from draft-byrne-v6ops-64share and just ma= ke >> sure it gets covered well in draft-binet-v6ops-cellular-host-reqs- >> rfc3316update >> >> FYI to folks that might be lost here. The 3GPP architecture is heavily >> reliant on IP-in-IP/UDP tunnels called GTP (GPRS tunneling protocol). >> More often than not, the infrastructure links are set at 1500 bytes, the= cell >> phone interface is 1500 bytes, and therefore the GTP tunnels packets nee= d to >> fragmented since they are carrying 1500 byte tunneled packets within an = IP >> packet that will no longer fit on a 1500 byte link. Not pretty. So, >> sometimes the carriers get the handsets manually set to a lower MTU. And= , >> sometimes the HTTP proxies reset the MSS to avoid fragments. >> >> Given that RA can advertise MTU, this is a good opportunity to properly = and >> dynamically set the mobile device's MTU without causing lots of fragment >> reassembly state in the network or otherwise mucking with MSS. This wil= l >> also be relevant and true for devices on the tethered LAN since all thos= e >> packets will be put into the MTU constrained GTP tunnels on their way th= rough >> the mobile provider and to the Internet. >> >> CB >> >> > -- >> > Mikael Abrahamsson email: swmike@swm.pp.se >> > >> > _______________________________________________ >> > v6ops mailing list >> > v6ops@ietf.org >> > https://www.ietf.org/mailman/listinfo/v6ops >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops From alh-ietf@tndh.net Sat Sep 29 19:56:36 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57A6921F85B1 for ; Sat, 29 Sep 2012 19:56:36 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace (char 20 hex): X-Spam-Report: ...that system for details.\n \n Content previ[...] X-Spam-Flag: NO X-Spam-Score: -0.246 X-Spam-Level: X-Spam-Status: No, score=-0.246 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, J_CHICKENPOX_13=0.6, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bIxGPoKONOdE for ; Sat, 29 Sep 2012 19:56:35 -0700 (PDT) Received: from express.tndh.net (75-149-170-53-Washington.hfc.comcastbusiness.net [75.149.170.53]) by ietfa.amsl.com (Postfix) with ESMTP id A446121F85A8 for ; Sat, 29 Sep 2012 19:56:35 -0700 (PDT) Received: from [172.20.144.31] (helo=eaglet) by express.tndh.net with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1TI9hf-000Cp9-Aa; Sat, 29 Sep 2012 19:56:29 -0700 From: "Tony Hain" To: "'Cameron Byrne'" , "'Eric Vyncke \(evyncke\)'" References: <201209291245.q8TCj0P22972@ftpeng-update.cisco.com> <97EB7536A2B2C549846804BBF3FD47E11184A36D@xmb-aln-x02.cisco.com> In-Reply-To: Date: Sat, 29 Sep 2012 19:56:23 -0700 Message-ID: <001b01cd9eb7$2d05c8d0$87115a70$@tndh.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQCCjUkCDWJaE+GGCckXzwpVUj5WFgLe8JlVAg06E6MBnvDJ2wIVWHFDmfNOoYA= Content-Language: en-us X-SA-Exim-Connect-IP: 172.20.144.31 X-SA-Exim-Mail-From: alh-ietf@tndh.net X-SA-Exim-Scanned: No (on express.tndh.net); SAEximRunCond expanded to false Cc: v6ops@ietf.org, draft-byrne-v6ops-64share@tools.ietf.org Subject: Re: [v6ops] new draft: draft-byrne-v6ops-64share X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Sep 2012 02:56:36 -0000 It is not required that the same address be assigned on both interfaces, just that the UE must defend and respond for the address used on the wan interface as if it was connected to the lan. I can't think of any cases where using the duplicated address breaks anything, but it does seem = like there might be some diagnostic benefit to having a predictable offset on = the lan interface address. It is not like there is a shortage of addresses = and we need to duplicate as a conservation measure... ;) Tony > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Cameron Byrne > Sent: Saturday, September 29, 2012 2:51 PM > To: Eric Vyncke (evyncke) > Cc: v6ops@ietf.org; draft-byrne-v6ops-64share@tools.ietf.org > Subject: Re: [v6ops] new draft: draft-byrne-v6ops-64share >=20 > On Sat, Sep 29, 2012 at 2:27 PM, Eric Vyncke (evyncke) > wrote: > > Isn't it easier to copy the MTU option from the RA received by the > > handset to the RA sent on the LAN? Of course, when there is no MTU > > option in the received RA on the WAN link, then, a SHOULD set MTU > > option to 1480 seems good > > >=20 > Yes, this will be the logic that we will bring to the text of draft-binet-v6ops- > cellular-host-reqs-rfc3316update >=20 > CB >=20 > > -=E9ric > > > >> -----Original Message----- > >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On > >> Behalf Of Cameron Byrne > >> Sent: samedi 29 septembre 2012 21:26 > >> To: Mikael Abrahamsson > >> Cc: v6ops@ietf.org; draft-byrne-v6ops-64share@tools.ietf.org > >> Subject: Re: [v6ops] new draft: draft-byrne-v6ops-64share > >> > >> On Sat, Sep 29, 2012 at 10:35 AM, Mikael Abrahamsson > >> > >> wrote: > >> > On Sat, 29 Sep 2012, fred@cisco.com wrote: > >> > > >> >> A new draft has been posted, at > >> >> http://tools.ietf.org/html/draft-byrne-v6ops-64share. Please = take > >> >> a look at it and comment. > >> > > >> > > >> > I have read it and support that it's a valuable topic to = publicise > >> > an RFC on. > >> > > >> > The last paragraph of section 3 about MTU makes sense, but I = would > >> > like to see a little bit more elaboration on why 1440 was chosen > >> > (rationale). I understand the rationale, but I am not sure all > >> > readers of > >> the document do. > >> > > >> > >> I tried to keep it concise, and the MTU issue is quite important = and > >> does require explanation, as you mentioned ... but on thinking it > >> over more, it would be better to simply reference this behavior in > >> the more comprehensive > >> draft-binet-v6ops-cellular-host-reqs-rfc3316update > >> > >> So, i will remove the MTU bit from draft-byrne-v6ops-64share and = just > >> make sure it gets covered well in > >> draft-binet-v6ops-cellular-host-reqs- > >> rfc3316update > >> > >> FYI to folks that might be lost here. The 3GPP architecture is > >> heavily reliant on IP-in-IP/UDP tunnels called GTP (GPRS tunneling > protocol). > >> More often than not, the infrastructure links are set at 1500 = bytes, > >> the cell phone interface is 1500 bytes, and therefore the GTP = tunnels > >> packets need to fragmented since they are carrying 1500 byte = tunneled > >> packets within an IP packet that will no longer fit on a 1500 byte > >> link. Not pretty. So, sometimes the carriers get the handsets > >> manually set to a lower MTU. And, sometimes the HTTP proxies reset = the > MSS to avoid fragments. > >> > >> Given that RA can advertise MTU, this is a good opportunity to > >> properly and dynamically set the mobile device's MTU without = causing > >> lots of fragment reassembly state in the network or otherwise = mucking > >> with MSS. This will also be relevant and true for devices on the > >> tethered LAN since all those packets will be put into the MTU > >> constrained GTP tunnels on their way through the mobile provider = and to > the Internet. > >> > >> CB > >> > >> > -- > >> > Mikael Abrahamsson email: swmike@swm.pp.se > >> > > >> > _______________________________________________ > >> > v6ops mailing list > >> > v6ops@ietf.org > >> > https://www.ietf.org/mailman/listinfo/v6ops > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From dr@cluenet.de Sun Sep 30 17:03:56 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B285321F8514 for ; Sun, 30 Sep 2012 17:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4xnHmg54lLT for ; Sun, 30 Sep 2012 17:03:56 -0700 (PDT) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by ietfa.amsl.com (Postfix) with ESMTP id 3215321F850D for ; Sun, 30 Sep 2012 17:03:55 -0700 (PDT) Received: by mail1.cluenet.de (Postfix, from userid 500) id 12364108672; Mon, 1 Oct 2012 02:03:54 +0200 (CEST) Date: Mon, 1 Oct 2012 02:03:54 +0200 From: Daniel Roesen To: v6ops@ietf.org, "draft-byrne-v6ops-64share@tools.ietf.org" Message-ID: <20121001000354.GA25686@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org, "draft-byrne-v6ops-64share@tools.ietf.org" References: <201209291245.q8TCj0P22972@ftpeng-update.cisco.com> <97EB7536A2B2C549846804BBF3FD47E11184A36D@xmb-aln-x02.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <97EB7536A2B2C549846804BBF3FD47E11184A36D@xmb-aln-x02.cisco.com> X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [v6ops] new draft: draft-byrne-v6ops-64share X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 00:03:56 -0000 On Sat, Sep 29, 2012 at 09:27:16PM +0000, Eric Vyncke (evyncke) wrote: > Isn't it easier to copy the MTU option from the RA received by the > handset to the RA sent on the LAN? Why on earth should the WAN link MTU influence the LAN MTU? The LAN has a fixed MTU and shall never get modified ad hoc because of MTU properties changing on other links. This is just a broken concept. Please don't ever go down that road. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From dr@cluenet.de Sun Sep 30 17:08:09 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1C0721F8523 for ; Sun, 30 Sep 2012 17:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QP-hxUWKNRvu for ; Sun, 30 Sep 2012 17:08:09 -0700 (PDT) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by ietfa.amsl.com (Postfix) with ESMTP id 5B9FC21F850D for ; Sun, 30 Sep 2012 17:08:09 -0700 (PDT) Received: by mail1.cluenet.de (Postfix, from userid 500) id BCAFC1087AE; Mon, 1 Oct 2012 02:08:08 +0200 (CEST) Date: Mon, 1 Oct 2012 02:08:08 +0200 From: Daniel Roesen To: v6ops@ietf.org, "draft-byrne-v6ops-64share@tools.ietf.org" Message-ID: <20121001000808.GB25686@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org, "draft-byrne-v6ops-64share@tools.ietf.org" References: <201209291245.q8TCj0P22972@ftpeng-update.cisco.com> <97EB7536A2B2C549846804BBF3FD47E11184A36D@xmb-aln-x02.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [v6ops] new draft: draft-byrne-v6ops-64share X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 00:08:10 -0000 On Sat, Sep 29, 2012 at 02:50:49PM -0700, Cameron Byrne wrote: > On Sat, Sep 29, 2012 at 2:27 PM, Eric Vyncke (evyncke) > wrote: > > Isn't it easier to copy the MTU option from the RA received by the handset to the RA sent on the LAN? Of course, when there is no MTU option in the received RA on the WAN link, then, a SHOULD set MTU option to 1480 seems good > > Yes, this will be the logic that we will bring to the text of > draft-binet-v6ops-cellular-host-reqs-rfc3316update I strongly disagree with that. Let PMTUD do its work, it's there for that. I really really don't want to see routers on a LAN arbitrarily mucking around with the LAN MTU to work around random problems of upstream infrastructure. This artificial MTU lowering in the LAN also breaks connectivity with nodes statically configured, disregarding RAs. Suddenly you have nodes with interface MTU=1500 trying to communicated with other nodes on the same LAN with other, RA-derrived lower MTUs... Best regards, Daniel From rajiva@cisco.com Sun Sep 30 17:53:56 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6377221F8518 for ; Sun, 30 Sep 2012 17:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.092 X-Spam-Level: X-Spam-Status: No, score=-10.092 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O48U5NZqhYla for ; Sun, 30 Sep 2012 17:53:55 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id ADF5121F8514 for ; Sun, 30 Sep 2012 17:53:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1455; q=dns/txt; s=iport; t=1349052835; x=1350262435; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=XporaTrNJcREkchWEoVhjDm6FbuNckFS4U/lOukTXxA=; b=EdjO7P/ATReYcjOSP+9+1BTSnWUm0+n8pJLRcKA0bycWjE2M6cKEoZVv l+X/MZFMN5QLLhf5+S0YwTgAjDbWIY1hL+2hIXRdNOST5Ozo+haAIrpJv Dwg5gD+ZmSCM1zxWVhmMUCId3cxDNzwhXiZoQGPiwyCLpUiSIpXA+4MPE 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAAHpaFCtJV2d/2dsb2JhbABFvjeBCIIgAQEBAwEBAQEPASc0CwULAgEIDgoeECcLJQIEDgUih10GC5oSnwsEix+Fa2ADlWmOQoFpgmc X-IronPort-AV: E=Sophos;i="4.80,514,1344211200"; d="scan'208";a="126893428" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP; 01 Oct 2012 00:53:55 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q910rtVx029037 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 1 Oct 2012 00:53:55 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.34]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.001; Sun, 30 Sep 2012 19:53:54 -0500 From: "Rajiv Asati (rajiva)" To: Daniel Roesen Thread-Topic: [v6ops] new draft: draft-byrne-v6ops-64share Thread-Index: AQHNnkCskO8xr8n+okaOe5un/NeX25eh6P6AgAAe2gCAACHdAIAABpSAgAG4swD//7j4gg== Date: Mon, 1 Oct 2012 00:53:54 +0000 Message-ID: <1161ED51-A0B3-4059-9E72-AF015DB4F519@cisco.com> References: <201209291245.q8TCj0P22972@ftpeng-update.cisco.com> <97EB7536A2B2C549846804BBF3FD47E11184A36D@xmb-aln-x02.cisco.com> , <20121001000808.GB25686@srv03.cluenet.de> In-Reply-To: <20121001000808.GB25686@srv03.cluenet.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19222.004 x-tm-as-result: No--40.174700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" , "draft-byrne-v6ops-64share@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-byrne-v6ops-64share X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 00:53:56 -0000 +1.=20 As attractive/feasible as relying on WAN MTU for LAN MTU purposes, I also d= isagree to that.=20 Cheers, Rajiv Sent from my Phone On Sep 30, 2012, at 8:08 PM, "Daniel Roesen" wrote: > On Sat, Sep 29, 2012 at 02:50:49PM -0700, Cameron Byrne wrote: >> On Sat, Sep 29, 2012 at 2:27 PM, Eric Vyncke (evyncke) >> wrote: >>> Isn't it easier to copy the MTU option from the RA received by the hand= set to the RA sent on the LAN? Of course, when there is no MTU option in th= e received RA on the WAN link, then, a SHOULD set MTU option to 1480 seems = good >>=20 >> Yes, this will be the logic that we will bring to the text of >> draft-binet-v6ops-cellular-host-reqs-rfc3316update >=20 > I strongly disagree with that. Let PMTUD do its work, it's there > for that. I really really don't want to see routers on a LAN > arbitrarily mucking around with the LAN MTU to work around random > problems of upstream infrastructure. >=20 > This artificial MTU lowering in the LAN also breaks connectivity with > nodes statically configured, disregarding RAs. Suddenly you have nodes > with interface MTU=3D1500 trying to communicated with other nodes on the > same LAN with other, RA-derrived lower MTUs... >=20 >=20 > Best regards, > Daniel >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From cb.list6@gmail.com Sun Sep 30 18:49:54 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3603021F850D for ; Sun, 30 Sep 2012 18:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.071 X-Spam-Level: X-Spam-Status: No, score=-3.071 tagged_above=-999 required=5 tests=[AWL=-0.072, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BjWL6fHMt6Cz for ; Sun, 30 Sep 2012 18:49:53 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 25DE321F84FF for ; Sun, 30 Sep 2012 18:49:52 -0700 (PDT) Received: by lbok13 with SMTP id k13so4025063lbo.31 for ; Sun, 30 Sep 2012 18:49:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=RkTA4E0Bg+zPAGRPTPtqqgHXQU5x5QleqAdOEmS2Hyg=; b=GXHwnfdxCJYnwP6++oQAu5WTmsPnw4wJFDqzJxd+2w06lXbMHACFzyNCyl1T7v+YrG ut2XK7NIANF7jqrFr/wIKW9eRxThQDP/ll/GPFuNbQB58BXFiobx3SSVXQY5REr1NCq8 /Adz0eRY6vg8qC1mNL9kkZFM19CU1NIFthMyZX6ptdRFFbsZqYELEfbWU7gHxIPik5gY /DKVOJUPhOwKWpZQd8VI5Zxd2ntF/oKn7EQY6C5MMqSxrBYdkplq6PlPH+k5Qp9PWFaT 47QF5hyq9xEr4SHt/pgvJYCMWCRM/uinihybqZd9obIfNqfG00KXR4F8yKo7Id3Jaoyg ApSg== MIME-Version: 1.0 Received: by 10.112.49.226 with SMTP id x2mr603671lbn.85.1349056192139; Sun, 30 Sep 2012 18:49:52 -0700 (PDT) Received: by 10.112.49.66 with HTTP; Sun, 30 Sep 2012 18:49:52 -0700 (PDT) In-Reply-To: <20121001000808.GB25686@srv03.cluenet.de> References: <201209291245.q8TCj0P22972@ftpeng-update.cisco.com> <97EB7536A2B2C549846804BBF3FD47E11184A36D@xmb-aln-x02.cisco.com> <20121001000808.GB25686@srv03.cluenet.de> Date: Sun, 30 Sep 2012 18:49:52 -0700 Message-ID: From: Cameron Byrne To: v6ops@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [v6ops] new draft: draft-byrne-v6ops-64share X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 01:49:54 -0000 Daniel, On Sun, Sep 30, 2012 at 5:08 PM, Daniel Roesen wrote: > On Sat, Sep 29, 2012 at 02:50:49PM -0700, Cameron Byrne wrote: >> On Sat, Sep 29, 2012 at 2:27 PM, Eric Vyncke (evyncke) >> wrote: >> > Isn't it easier to copy the MTU option from the RA received by the handset to the RA sent on the LAN? Of course, when there is no MTU option in the received RA on the WAN link, then, a SHOULD set MTU option to 1480 seems good >> >> Yes, this will be the logic that we will bring to the text of >> draft-binet-v6ops-cellular-host-reqs-rfc3316update > > I strongly disagree with that. Let PMTUD do its work, it's there ACK. PMTU must do it's job. > for that. I really really don't want to see routers on a LAN > arbitrarily mucking around with the LAN MTU to work around random > problems of upstream infrastructure. > Allow me to reiterate that this is something for draft-binet-v6ops-cellular-host-reqs-rfc3316update and not draft-byrne-v6ops-64share (it will be removed ) That said, it is not "arbitrarily mucking around with the LAN MTU to work around random problems" It is in fact deterministicly working around a systemic problem in 3GPP network using the correct IETF tools to do so: RA MTU info. Keep in mind, this problem is "solved" today by "adjusting" the MSS in HTTP proxies, which are also common in 3GPP networks. Nobody asked for the IETF's permission for this pervasive yet effective technique (which is also common in DSL network, and will soon popup in DS-lite networks... but IPv4 does not have RA to communicate the MTU) Yes, PMTU will discover the correct MTU. But why not start out in the right place? If the 3GPP network operator knows that the MTU is of the WAN link is 1440, why not cascade the information down via RA ? RA has this ability and it has clear benefits of not having to exercise PMTU or adjust for it's brokeness. Furthermore, specific to 3GPP networks, the fragmentation will not be seen by any endpoints and PMTU will not be used. The fragmentation in question here happens at the GTP IPv6 in IPv4/UDP tunnel. So, the 3GPP network operator is trying to clamp MTU of the end nodes to avoid the IPv6 in IPv4/UDP GTP mobility tunnel from being fragmented... not the IP packets that the end nodes see. > This artificial MTU lowering in the LAN also breaks connectivity with > nodes statically configured, disregarding RAs. Suddenly you have nodes > with interface MTU=1500 trying to communicated with other nodes on the > same LAN with other, RA-derrived lower MTUs... > PMTU will be quicker and more effective in a LAN than a WAN if this problem occurs. CB > > Best regards, > Daniel > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From lorenzo@google.com Sun Sep 30 23:18:03 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1A8021F856C for ; Sun, 30 Sep 2012 23:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.866 X-Spam-Level: X-Spam-Status: No, score=-102.866 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwVi8B+sa0Da for ; Sun, 30 Sep 2012 23:18:03 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id A175421F8568 for ; Sun, 30 Sep 2012 23:18:02 -0700 (PDT) Received: by oagn5 with SMTP id n5so5695383oag.31 for ; Sun, 30 Sep 2012 23:17:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:x-system-of-record; bh=23y4PeOrxG8QpD3UtuI5tZ33qK1niylacPlUGDNTjUE=; b=JUb/Aj/Twc5dGyyGFoRoyH0U7EUiAm7yB5Q3H6mk+U6OOnDfukIYjHmrYuzIr3Au7d MqYCQZbQhQqtus+cONc3gRRnHV8Uhm9UDKmDAJ5gEfIbRMDaDFPasSymTKCXBB2qpHRW gFIbYX7K11w3/Z60/vuFCPvjp6wM5EyoYst1YeQlkUO1odVAz3sI8Gm0AkVEewIsUV0M Q5Dl0sH/pGVhij8AYeMUWcoPnNY/7nOC8z1ZWCAMbZdPFIMeFFLP7xGy7opRbSSYN4vW 2iCv7JvW6g/WIB3EXfgNsIWR+HRZCBL+caOFyENDCBjCzilna89F+wNRyoMmGR/B3LJb 4M+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:x-system-of-record:x-gm-message-state; bh=23y4PeOrxG8QpD3UtuI5tZ33qK1niylacPlUGDNTjUE=; b=ZbdsXmpjqLVVyYUNlcXfF4/FcsKay+/L1bbKOFRHZdvNAtCJWwPsgpz85dyWL0u9gG ppp6EacbZViATv4WK7bOMmwKmki4qAvj9Ysptk7izXJOLKb6jVGeDhDGKXK31hnVb2lt 4iN4MQiTKq1CtSAHKG4T2Eq1xoiREAOjuHTFvDNwY/oHeoPGXEuqRtvbb11bj58+G6mx 4dwFlE0jmu+obmiJpMtV6L7aMI24ngMmg3Ngp3fB9ESRIwD2Lf2Mc/LS0LP56iZvP89R 5nLAUI2auJdmh90Jqs5bqQ0X4HZJugY6/sBf6LLqjPNZD1qwnr+geh73i0BOFAWTSg5H 6nDw== Received: by 10.60.22.71 with SMTP id b7mr10829737oef.6.1349072273818; Sun, 30 Sep 2012 23:17:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.225.98 with HTTP; Sun, 30 Sep 2012 23:17:33 -0700 (PDT) In-Reply-To: <20121001000808.GB25686@srv03.cluenet.de> References: <201209291245.q8TCj0P22972@ftpeng-update.cisco.com> <97EB7536A2B2C549846804BBF3FD47E11184A36D@xmb-aln-x02.cisco.com> <20121001000808.GB25686@srv03.cluenet.de> From: Lorenzo Colitti Date: Mon, 1 Oct 2012 15:17:33 +0900 Message-ID: To: v6ops@ietf.org, "draft-byrne-v6ops-64share@tools.ietf.org" Content-Type: multipart/alternative; boundary=e89a8f839e8fa8440a04caf95d34 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmh4OU/J/sVWKtE6Jjoeoisnqw3e8IRrY27DnJda4OUDzXJerVjWqTxnrlLDz6lWntrjF6EVKvXbjeWQGqivrkaDhdlS30aNVf5zulTYVRsABpKy+Tzf+gRcFuDNgA9cHpd4JBTZuJZaIPq97UYgSadoJb3LVVpq7WJfIOdWzyo2sAwwRISMHwa5K/A9xxNeMNa62/h Subject: Re: [v6ops] new draft: draft-byrne-v6ops-64share X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 06:18:04 -0000 --e89a8f839e8fa8440a04caf95d34 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Oct 1, 2012 at 9:08 AM, Daniel Roesen wrote: > I strongly disagree with that. Let PMTUD do its work, it's there > for that. I really really don't want to see routers on a LAN > arbitrarily mucking around with the LAN MTU to work around random > problems of upstream infrastructure. > Bad idea. PMTUD causes a ~1 RTT latency hit to every new server you talk to= . Why do you need 1500 anyway? So that devices talking to each other via the phone's hotspot (!) can use 1500-byte packets instead of 1480-byte packets, thus gaining a whopping 0.05% performance boost? ((1440=F71500) / (1420=F71= 480) - 1) That's really not worth the latency hit. Even if you could to use jumbo frames of infinite size, that's still only a 1.4% performance boost. > This artificial MTU lowering in the LAN also breaks connectivity with > nodes statically configured, disregarding RAs. Suddenly you have nodes > with interface MTU=3D1500 trying to communicated with other nodes on the > same LAN with other, RA-derrived lower MTUs... > Statically configured addresses on the tethering hotspot? How would that even happen, given that in most cases your prefix is dynamically assigned? If you don't know the prefix in advance, you can't configure the address. --e89a8f839e8fa8440a04caf95d34 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Oct 1, 2012 at 9:08 AM, Daniel Roesen <dr@cluenet.de> wr= ote:
    I strongly disagree with that. Let PMTUD do its work, it&= #39;s there
    for that. I really really don't want to see routers on a LAN
    arbitrarily mucking around with the LAN MTU to work around random
    problems of upstream infrastructure.

    Ba= d idea. PMTUD causes a ~1 RTT latency hit to every new server you talk to.<= /div>

    Why do you need 1500 anyway? So that devices talki= ng to each other via the phone's hotspot (!) can use 1500-byte packets = instead of 1480-byte packets, thus gaining a whopping 0.05% performance boo= st? ((1440=F71500) / (1420=F71480) - 1) That's really not worth the lat= ency hit. Even if you could to use jumbo frames of infinite size, that'= s still only a 1.4% performance boost.
    =A0
    This artificial MTU lowering i= n the LAN also breaks connectivity with
    nodes statically configured, disregarding RAs. Suddenly you have nodes
    with interface MTU=3D1500 trying to communicated with other nodes on the same LAN with other, RA-derrived lower MTUs...

    Statically configured addresses on the tethering hotspot? How would= that even happen, given that in most cases your prefix is dynamically assi= gned? If you don't know the prefix in advance, you can't configure = the address.
    --e89a8f839e8fa8440a04caf95d34--