From diego@tid.es Sun Jul 1 06:10: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 A17B311E80C7 for ; Sun, 1 Jul 2012 06:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.135 X-Spam-Level: X-Spam-Status: No, score=-5.135 tagged_above=-999 required=5 tests=[AWL=-0.395, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTJVRqBSIu57 for ; Sun, 1 Jul 2012 06:10:11 -0700 (PDT) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id 879B211E808C for ; Sun, 1 Jul 2012 06:10:11 -0700 (PDT) Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M6H001ATGL0SA@tid.hi.inet> for v6ops@ietf.org; Sun, 01 Jul 2012 15:10:12 +0200 (MEST) Received: from tid (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id AC.E8.26499.43C40FF4; Sun, 01 Jul 2012 15:10:12 +0200 (CEST) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0M6H001APGKZSA@tid.hi.inet> for v6ops@ietf.org; Sun, 01 Jul 2012 15:10:12 +0200 (MEST) Received: from EX10-MB1-MAD.hi.inet ([fe80::a473:4f3e:f8db:1855]) by ex10-htcas3-mad.hi.inet ([::1]) with mapi id 14.02.0298.004; Sun, 01 Jul 2012 15:10:11 +0200 Date: Sun, 01 Jul 2012 13:10:11 +0000 From: "Diego R. Lopez" In-reply-to: X-Originating-IP: [10.95.64.115] To: Arturo Servin Message-id: Content-id: <0EE1E2F904A16D4B9EDF606F02322ED9@hi.inet> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-US Thread-topic: [v6ops] Draft on DC migration to IPv6 Thread-index: AQHNUqhbgWRF7Aew1UKq7qhHvsQ1MZcM3AKAgAJZwwCAAF67gIAEuliA X-AuditID: 0a5f4068-b7f206d000006783-31-4ff04c34783c X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDKsWRmVeSWpSXmKPExsXCFe/ApWvi88HfYPYrIYvTx/YyOzB6LFny kymAMYrLJiU1J7MstUjfLoEro+/FG9aCi3wVNyZfYW5g3MvdxcjJISFgIvHt1Xo2CFtM4sI9 EJuLQ0hgI6PEks43rBDOT0aJLQt/s0M4SxklVq+fwgLSwiKgKnH0zmpmEJsNyH7UDFLEwSEs YCTxfZIXSJhTwFbiWddGqA0KEn/OPWYBKRER0JbYeUYNJMwM1Dlv3SmwibwClhIH375jgoib Seyddp4JIi4o8WPyPRaIuI5E7/dvzBC2uERz602ouLbEk3cXWEFsRqBnvp9awwSxyljiyD5B kLCIgJvE0aYGqGsEJJbsOc8MYYtKvHz8D+rd84wSX8+9YJnAKDELyRmzkJwxC8kZs5CcMQvJ GQsYWVcxihUnFWWmZ5TkJmbmpBsY6mVk6mXmpZZsYoREXcYOxuU7VQ4xCnAwKvHwctx46y/E mlhWXJl7iFGSg0lJlLfG44O/EF9SfkplRmJxRnxRaU5q8SFGCQ5mJRHep8ff+wvxpiRWVqUW 5cOkZDg4lCR4e7yB2gSLUtNTK9Iyc4CpBSbNxMEJ0s4D1J4HUsNbXJCYW5yZDpE/xSgpJc6b CpIQAElklObB9b5iFAc6UpjXByTLA0yCcF2vgAYyAQ18vvodyMCSRISUVANj/fuiSe2978yk Q9+593Mumb796EcGrejNaxhOfAk0ubNg9sz2K817TfIUeKQmb3u8QUkwlVX+poJd3qx6wTWX OB3VJTtmiduyzJLLE4yqfF/bJ5c+77mPnplWq6vZZX9LWbPTz2faZNzIPRTiwHi2v5bPOiNB TkKZQ8z4qJAam1by9C08VkosxRmJhlrMRcWJAAflVnM/AwAA References: <28DC472D-01D4-4534-97A9-6AE52BE9CC58@tid.es> <7EC83C63-AE66-4FD1-8EFE-2C2CF41F5106@gmail.com> Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Draft on DC migration to IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 01 Jul 2012 13:10:12 -0000 Hi Arturo, On 28 Jun 2012, at 14:58 , Arturo Servin wrote: >> The maturity level 1 corresponds to a datacenter in which all traffic it= is v4-based, >> and translation from and to the v6 Internet is provided at the border. O= ur take is >> that this is the most common case nowadays. > > Do you have some examples? Personally I haven't seen any (but I hav= e seen just a few DC with v6, so I am not expert. I am just curious about t= he basis of your claim). Precisely one of the references in the document describes one of these case= s: draft-sunq-v6ops-contents-transition-03 > I have seen load balancers in front of webservers, but that I think= is different. > > For now the most common that I have seen are load balancers in DS a= nd webservers in v4; and dual stack DCs where some services (i.e web, dns a= nd sometimes email ) are in v6 and some others (legacy applications, video = streaming, etc.) are in v4. I think both of them would be cases for level 2 (the one based on LBs es de= scribed in Figure 3, as far as I can tell) and the other one is a case that, as I s= aid in my previous reply, should be included in level 2 as well and mentioned as w= ell. Be goode, -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego@tid.es Tel: +34 913 129 041 Mobile: +34 682 051 091 ----------------------------------------- ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx From liushucheng@huawei.com Mon Jul 2 01:44: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 ACAC921F8B0B for ; Mon, 2 Jul 2012 01:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mR4obJGvu9Pb for ; Mon, 2 Jul 2012 01:44:24 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id F33D921F8ADB for ; Mon, 2 Jul 2012 01:44:23 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHQ47088; Mon, 02 Jul 2012 04:44:28 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 2 Jul 2012 01:44:00 -0700 Received: from SZXEML423-HUB.china.huawei.com (10.82.67.162) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 2 Jul 2012 01:44:01 -0700 Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.75]) by szxeml423-hub.china.huawei.com ([10.82.67.162]) with mapi id 14.01.0323.003; Mon, 2 Jul 2012 16:43:53 +0800 From: "Will Liu (Shucheng)" To: "v6ops@ietf.org" Thread-Topic: New draft: draft-zhang-v6ops-ipv6oa-iwf-00.txt Thread-Index: AQHNWC7OsYXSoN5YvUyvFLUsZHdmkw== Date: Mon, 2 Jul 2012 08:43:51 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.79.130] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [v6ops] New draft: draft-zhang-v6ops-ipv6oa-iwf-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: Mon, 02 Jul 2012 08:44:24 -0000 Rm9sa3MsDQoNCldlIGhhdmUgc3VibWl0dGVkIGEgbmV3IGRyYWZ0IGVudGl0bGVkICIgSVB2NiBv dmVyIEFUTSBpbnRlcndvcmtpbmcgZnVuY3Rpb24gIi4gVGhlIGludGVudCBvZiB0aGUgZHJhZnQg aXMgdG8gYWRkcmVzcyB0aGUgaXNzdWUgb2YgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIGxlZ2FjeSBB VE0vU0RIIGFuZCBJUHY2IG92ZXIgRXRoZXJuZXQgd2hlbiBuZXR3b3JrIG1pZ3JhdGVzIHRvIElQ djYsIHRvIGRpc2N1c3MgcG9zc2libGUgc29sdXRpb25zIGFuZCBwb3RlbnRpYWwgcmVsYXRlZCBp c3N1ZXMuDQoNClRoZSBsYXRlc3QgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo8IGh0dHA6Ly93 d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXpoYW5nLXY2b3BzLWlwdjZvYS1pd2Yt MDAudHh0ID4NCg0KQW55IGNvbW1lbnRzIHdpbGwgYmUgYXBwcmVjaWF0ZWQuDQoNClJlZ2FyZHMs DQpXaWxsDQoNCkJlZ2luIGZvcndhcmRlZCBtZXNzYWdlOg0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IFNhdHVyZGF5LCBKdW5lIDMwLCAyMDEyIDc6MDggUE0N ClRvOiBXaWxsIExpdSAoU2h1Y2hlbmcpDQpDYzogc3VuanBAc3R0cmkuY29tLmNuOyBlc3RyZWxs YXpoYW5nMjAxMkBnbWFpbC5jb207IFRpbmEgVFNPVQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90 aWZpY2F0aW9uIGZvciBkcmFmdC16aGFuZy12Nm9wcy1pcHY2b2EtaXdmLTAwLnR4dA0KDQoNCkEg bmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC16aGFuZy12Nm9wcy1pcHY2b2EtaXdmLTAwLnR4dA0K aGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBXaWxsIExpdSBhbmQgcG9zdGVkIHRv IHRoZQ0KSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZToJIGRyYWZ0LXpoYW5nLXY2b3BzLWlw djZvYS1pd2YNClJldmlzaW9uOgkgMDANClRpdGxlOgkJIElQdjYgb3ZlciBBVE0gaW50ZXJ3b3Jr aW5nIGZ1bmN0aW9uDQpDcmVhdGlvbiBkYXRlOgkgMjAxMi0wNi0zMA0KV0cgSUQ6CQkgSW5kaXZp ZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDgNClVSTDogICAgICAgICAgICAgaHR0 cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtemhhbmctdjZvcHMtaXB2Nm9h LWl3Zi0wMC50eHQNClN0YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC16aGFuZy12Nm9wcy1pcHY2b2EtaXdmDQpIdG1saXplZDogICAgICAgIGh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpoYW5nLXY2b3BzLWlwdjZvYS1pd2YtMDANCg0K DQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgaW50ZXJ3b3JraW5nIGZ1 bmN0aW9uIGJldHdlZW4gSVB2NiBvdmVyIEFUTQ0KICAgKEFzeW5jaHJvbm91cyBUcmFuc2ZlciBN b2RlKSBhbmQgSVB2NiBvdmVyIEV0aGVybmV0LiAgVGhlcmUgYXJlDQogICBkaWZmZXJlbnQgc3Rh dGVzIGZvciBJUHY2IG92ZXIgQVRNIGFuZCBFdGhlcm5ldC4gIFRoZSBpbnRlcndvcmtpbmcNCiAg IGZ1bmN0aW9uIG5lZWQgbWFpbnRhaW4gdGhlIHN0YXRlcyBmcm9tIGJvdGggQVRNIGFuZCBFdGhl cm5ldCB0byBtYWtlDQogICBzdXJlIHRoZSBuZXR3b3JrIGNhbiBiZSBjb21tdW5pY2F0ZWQgYmV0 d2VlbiBBVE0gYW5kIEV0aGVybmV0Lg0KDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0K DQpUaGUgSUVURiBTZWNyZXRhcmlhdA0K From internet-drafts@ietf.org Mon Jul 2 20:45: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 AB0CB21F85C9; Mon, 2 Jul 2012 20:45:23 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4MTqP0GotYjZ; Mon, 2 Jul 2012 20:45:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 496F921F853D; Mon, 2 Jul 2012 20:45:22 -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.21p1 Message-ID: <20120703034522.1902.94338.idtracker@ietfa.amsl.com> Date: Mon, 02 Jul 2012 20:45:22 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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: Tue, 03 Jul 2012 03:45:24 -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-05.txt Pages : 19 Date : 2012-07-02 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-05 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-464xlat-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From kawashimam@vx.jp.nec.com Mon Jul 2 20:50: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 DD9A511E8116 for ; Mon, 2 Jul 2012 20:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[AWL=2.200, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HwVBPSooIc1Q for ; Mon, 2 Jul 2012 20:50:31 -0700 (PDT) Received: from tyo202.gate.nec.co.jp (TYO202.gate.nec.co.jp [202.32.8.206]) by ietfa.amsl.com (Postfix) with ESMTP id 5A67011E8119 for ; Mon, 2 Jul 2012 20:50:31 -0700 (PDT) Received: from mailgate3.nec.co.jp ([10.7.69.192]) by tyo202.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id q633obe9001817 for ; Tue, 3 Jul 2012 12:50:37 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id q633obx04420 for v6ops@ietf.org; Tue, 3 Jul 2012 12:50:37 +0900 (JST) Received: from mail03.kamome.nec.co.jp (mail03.kamome.nec.co.jp [10.25.43.7]) by mailsv.nec.co.jp (8.13.8/8.13.4) with ESMTP id q633oa1Y002591 for ; Tue, 3 Jul 2012 12:50:36 +0900 (JST) Received: from kameyata.jp.nec.com ([10.26.220.29] [10.26.220.29]) by mail03.kamome.nec.co.jp with ESMTP id BT-MMP-188261; Tue, 3 Jul 2012 12:49:50 +0900 Received: from siznecatg159185 ([10.3.159.185] [10.3.159.185]) by mail.jp.nec.com with ESMTPA id BT-MMP-27911; Tue, 3 Jul 2012 12:49:50 +0900 To: v6ops@ietf.org In-reply-to: <20120703034522.1902.94338.idtracker@ietfa.amsl.com> Message-Id: <20120703124949kawashimam@mail.jp.nec.com> References: <20120703034522.1902.94338.idtracker@ietfa.amsl.com> Mime-Version: 1.0 X-Mailer: StarOffice21/MailClient[4.65 Step9] From: Masanobu Kawashima Date: Tue, 3 Jul 2012 12:49:48 +0900 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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: Tue, 03 Jul 2012 03:50:33 -0000 Hi all, We have published draft-ietf-v6ops-464xlat-05. We think this version is enough to do WGLC. Changes are: - adding the issues related to mobile network in the section of "Wireless 3GPP Network Applicability". - adding [TS23.203] in the section of "Informative References". - adding Tom-san and Jouni-san to acknowledgements. All comments are welcome. Regards, Masanobu > >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-05.txt > Pages : 19 > Date : 2012-07-02 > >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-05 > >A diff from previous version is available at: >http://tools.ietf.org/rfcdiff?url2=draft-ietf-v6ops-464xlat-05 > > >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 ======================================== NEC AccessTechnica, Ltd. Product Development Department Masanobu Kawashima kawashimam@vx.jp.nec.com http://www.necat.co.jp/ ======================================== From despres.remi@laposte.net Tue Jul 3 01:39: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 3DCA321F8762 for ; Tue, 3 Jul 2012 01:39:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RMlIp+F3DUTR for ; Tue, 3 Jul 2012 01:39:31 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id E189321F8752 for ; Tue, 3 Jul 2012 01:39:28 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 8CEEF940108; Tue, 3 Jul 2012 10:39:28 +0200 (CEST) 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: <20120703124949kawashimam@mail.jp.nec.com> Date: Tue, 3 Jul 2012 10:39:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120703034522.1902.94338.idtracker@ietfa.amsl.com> <20120703124949kawashimam@mail.jp.nec.com> To: Masanobu Kawashima X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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: Tue, 03 Jul 2012 08:39:32 -0000 2012-07-03 05:49, Masanobu Kawashima: >=20 > Hi all, >=20 > We have published draft-ietf-v6ops-464xlat-05. > We think this version is enough to do WGLC. >=20 > Changes are: >=20 > - adding the issues related to mobile network in the section > of "Wireless 3GPP Network Applicability". >=20 > - adding [TS23.203] in the section of "Informative References". >=20 > - adding Tom-san and Jouni-san to acknowledgements. But again ignoring = http://www.ietf.org/mail-archive/web/v6ops/current/msg13314.html Support for to WGLC if changed to Informational (or Experimental). But objection to WGLC is confirmed if BCP is the maintained status. A good reason to refuse Informational or Experimental hasn't been seen = on this list. Regards, RD=20 >=20 > All comments are welcome. >=20 > Regards, > Masanobu >=20 >=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 : 464XLAT: Combination of Stateful and Stateless = Translation >> Author(s) : Masataka Mawatari >> Masanobu Kawashima >> Cameron Byrne >> Filename : draft-ietf-v6ops-464xlat-05.txt >> Pages : 19 >> Date : 2012-07-02 >>=20 >> 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. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-v6ops-464xlat >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-05 >>=20 >> A diff from previous version is available at: >> http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-464xlat-05 >>=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 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > NEC AccessTechnica, Ltd. =20 > Product Development Department =20 > Masanobu Kawashima =20 > kawashimam@vx.jp.nec.com =20 > http://www.necat.co.jp/ =20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From internet-drafts@ietf.org Tue Jul 3 02:45: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 7E26821F87F3; Tue, 3 Jul 2012 02:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.473 X-Spam-Level: X-Spam-Status: No, score=-102.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QWhxJSLASb43; Tue, 3 Jul 2012 02:45:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15F3021F873D; Tue, 3 Jul 2012 02:45: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.21p1 Message-ID: <20120703094549.14140.23639.idtracker@ietfa.amsl.com> Date: Tue, 03 Jul 2012 02:45:49 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-ivi-icmp-address-02.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, 03 Jul 2012 09:45:59 -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-02.txt Pages : 6 Date : 2012-07-03 Abstract: A stateless IPv4/IPv6 translator may receive ICMPv6 packets containing non IPv4-translatable addresses as the source that should be passed across the translator as an ICMP packet directed to the IPv4-translatable destination. This document presents recommendations for source address translation in ICMPv6 headers for 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-02 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-ivi-icmp-address-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From philip_matthews@magma.ca Tue Jul 3 12:26: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 0262111E81C8 for ; Tue, 3 Jul 2012 12:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 49ATOrvocNfs for ; Tue, 3 Jul 2012 12:26:43 -0700 (PDT) Received: from mail-06.primus.ca (mail16.primus.ca [216.254.141.183]) by ietfa.amsl.com (Postfix) with ESMTP id 21E3611E81BE for ; Tue, 3 Jul 2012 12:26:43 -0700 (PDT) Received: from [74.198.165.90] (helo=[172.20.10.2]) by mail-06.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1Sm8kL-0000yy-0V; Tue, 03 Jul 2012 15:26:51 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Philip Matthews In-Reply-To: Date: Tue, 3 Jul 2012 15:26:43 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <78B3D13C-8AEB-434E-B933-6FF755F626A2@magma.ca> References: <20120629134643.1308.69156.idtracker@ietfa.amsl.com> <6BCCA339-F0B1-4CAC-A1FA-B2B3DF887D66@magma.ca> To: Randy Bush X-Mailer: Apple Mail (2.1084) X-Authenticated: philip_matthews - ([172.20.10.2]) [74.198.165.90] Cc: IETF v6ops list Subject: Re: [v6ops] New draft: draft-matthews-v6ops-design-guidelines-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: Tue, 03 Jul 2012 19:26:44 -0000 Thanks! If the working group decided to take this effort up, then my instinct is = telling me that the best we will be able to do for most questions is = simply list pros and cons. There will probably be a few questions where = we can agree that "this is best practice", but I suspect those will be = few. So all I really want to do is capture people's thoughts/opinions = for or against each option for a question, so that someone else can read = them and make up his/her own mind. As well as my own thoughts, I spent some time searching mailing lists = and presentations, trying to find arguments for or against a choice. But = I am sure I have missed things for my existing questions (not to = mention the areas I have not even covered yet). I did see the (quite = good and helpful) slide presentation that you and others have been = presenting at various *NOG meetings recently and took some arguments = from there. However, since I was only reading slides, I didn't get the = arguments behind some of the statements made there. If have additional = arguments for or against a choice, I would love to hear it. - Philip On 2012-06-29, at 20:38 , Randy Bush wrote: >>> A new version of I-D, draft-matthews-v6ops-design-guidelines-00.txt >>> has been successfully submitted by Philip Matthews and posted to the >>> IETF repository. >>>=20 >>> Filename: draft-matthews-v6ops-design-guidelines >>> Revision: 00 >>> Title: Design Guidelines for IPv6 Networks >>> Creation date: 2012-06-29 >>> WG ID: Individual Submission >>> Number of pages: 10 >>> URL: = http://www.ietf.org/internet-drafts/draft-matthews-v6ops-design-guidelines= -00.txt >>> Status: = http://datatracker.ietf.org/doc/draft-matthews-v6ops-design-guidelines >>> Htmlized: = http://tools.ietf.org/html/draft-matthews-v6ops-design-guidelines-00 >=20 > i read this document prepared to laugh and/or puke. i was pleasantly > surprised. this is generally quite good advice without getting > religious, and a darned good start. congrats! >=20 > randy >=20 From philip_matthews@magma.ca Tue Jul 3 12:41: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 7BBE111E81F0 for ; Tue, 3 Jul 2012 12:41:19 -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.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z624mS4lEz8o for ; Tue, 3 Jul 2012 12:41:18 -0700 (PDT) Received: from mail-08.primus.ca (mail16.primus.ca [216.254.141.183]) by ietfa.amsl.com (Postfix) with ESMTP id A7EF911E81EB for ; Tue, 3 Jul 2012 12:41:18 -0700 (PDT) Received: from [74.198.165.90] (helo=[172.20.10.2]) by mail-08.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1Sm8yR-0005ry-2i; Tue, 03 Jul 2012 15:41:25 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Philip Matthews In-Reply-To: Date: Tue, 3 Jul 2012 15:41:18 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1EC54670-58AA-4758-B3BE-754309288B87@magma.ca> References: <20120629134643.1308.69156.idtracker@ietfa.amsl.com> <6BCCA339-F0B1-4CAC-A1FA-B2B3DF887D66@magma.ca> To: Tina TSOU X-Mailer: Apple Mail (2.1084) X-Authenticated: philip_matthews - ([172.20.10.2]) [74.198.165.90] Cc: IETF v6ops list Subject: Re: [v6ops] New draft: draft-matthews-v6ops-design-guidelines-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: Tue, 03 Jul 2012 19:41:19 -0000 Thanks. I also have not come up with anything yet for OSPFv3. One thing I am thinking of covering in a future revision was the "I am = currently running IGP X for IPv4, should I run IGP Y for IPv6?" = question. (Note: I want to do this WITHOUT covering the "which is = better: OSPF or ISIS?" question, because that question is not specific = to IPv6). =20 - Philip On 2012-06-29, at 21:20 , Tina TSOU wrote: > 8. OSPF >=20 > (TBD) >=20 > I used basic OSPFv3 functionalities in IPv6 at my enterprise. Nothing = special was found. >=20 > Tina > @ 2001:db8:1:ffff:e8e2:7822:9d12:e12e >=20 >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On = Behalf Of >> Randy Bush >> Sent: Friday, June 29, 2012 5:39 PM >> To: Philip Matthews >> Cc: IETF v6ops list >> Subject: Re: [v6ops] New draft: = draft-matthews-v6ops-design-guidelines- >> 00.txt >>=20 >>>> A new version of I-D, draft-matthews-v6ops-design-guidelines-00.txt >>>> has been successfully submitted by Philip Matthews and posted to = the >>>> IETF repository. >>>>=20 >>>> Filename: draft-matthews-v6ops-design-guidelines >>>> Revision: 00 >>>> Title: Design Guidelines for IPv6 Networks >>>> Creation date: 2012-06-29 >>>> WG ID: Individual Submission >>>> Number of pages: 10 >>>> URL: = http://www.ietf.org/internet-drafts/draft-matthews- >> v6ops-design-guidelines-00.txt >>>> Status: = http://datatracker.ietf.org/doc/draft-matthews-v6ops- >> design-guidelines >>>> Htmlized: http://tools.ietf.org/html/draft-matthews-v6ops- >> design-guidelines-00 >>=20 >> i read this document prepared to laugh and/or puke. i was pleasantly >> surprised. this is generally quite good advice without getting >> religious, and a darned good start. congrats! >>=20 >> randy >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 From randy@psg.com Tue Jul 3 13:20: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 B325721F8638 for ; Tue, 3 Jul 2012 13:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lTqO3Dy25V2b for ; Tue, 3 Jul 2012 13:20:12 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 4E67421F861F for ; Tue, 3 Jul 2012 13:20:09 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Sm9Zz-00008O-4j; Tue, 03 Jul 2012 20:20:11 +0000 Date: Wed, 04 Jul 2012 05:20:10 +0900 Message-ID: From: Randy Bush To: Philip Matthews In-Reply-To: <1EC54670-58AA-4758-B3BE-754309288B87@magma.ca> References: <20120629134643.1308.69156.idtracker@ietfa.amsl.com> <6BCCA339-F0B1-4CAC-A1FA-B2B3DF887D66@magma.ca> <1EC54670-58AA-4758-B3BE-754309288B87@magma.ca> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: IETF v6ops list Subject: Re: [v6ops] New draft: draft-matthews-v6ops-design-guidelines-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: Tue, 03 Jul 2012 20:20:12 -0000 > Thanks. I also have not come up with anything yet for OSPFv3. is-is From Jean-Francois.TremblayING@videotron.com Wed Jul 4 06:14: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 8182B21F87F7 for ; Wed, 4 Jul 2012 06:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x57FJBPt6ocG for ; Wed, 4 Jul 2012 06:14:41 -0700 (PDT) Received: from mx01.videotron.com (mx01.videotron.com [24.201.243.152]) by ietfa.amsl.com (Postfix) with ESMTP id E92D321F87C8 for ; Wed, 4 Jul 2012 06:14:40 -0700 (PDT) In-Reply-To: <201206301245.q5UCj1c07569@ftpeng-update.cisco.com> To: v6ops@ietf.org MIME-Version: 1.0 X-KeepSent: D11FB203:D6FE4461-85257A31:00458DBA; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 Message-ID: From: Jean-Francois.TremblayING@videotron.com Date: Wed, 4 Jul 2012 09:14:40 -0400 X-MIMETrack: Serialize by Router on DOMMSG01/SRV/GVL(Release 8.5.3FP1|March 07, 2012) at 07/04/2012 09:14:40, Serialize complete at 07/04/2012 09:14:40 Content-Type: text/plain; charset="US-ASCII" Received-SPF: none Subject: [v6ops] RE new draft: draft-matthews-v6ops-design-guidelines X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 04 Jul 2012 13:14:41 -0000 > A new draft has been posted, at http://tools.ietf.org/html/draft- > matthews-v6ops-design-guidelines. Please take a look at it and comment. Useful, although coming a bit late for most ISPs. Some guidelines also apply to enterprises. A few additionnal comments/ideas: 3.2 Adressing Global vs ULA arguments could also be considered. A disadvantage of ULA is the lack of reverse DNS, unless the reverse zone is added locally. Advantage of ULA is simplicity to filter. Possibly less administrativa. 4.1 Next-hop Some early implementations of next hop redundancy protocols supported a or b exclusively. 6. iBGP Some protocols require a specific combination of AF and transport. For example, 6PE/6vPE requires IPv6 and VPNv6 address families over IPv4 transport. Native IPv6 routes should be over IPv6 transport. 7. ISIS Multi-topology vs single topology Some implementations of ISIS have issues running IPv6 with a single topology. Multi-topology is recommended, even if IPv4 is not carried in LSPs. /JF From phdgang@gmail.com Thu Jul 5 00:30: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 E187921F854B for ; Thu, 5 Jul 2012 00:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5X+xOTiYKUdI for ; Thu, 5 Jul 2012 00:30:22 -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 0469B21F8522 for ; Thu, 5 Jul 2012 00:30:21 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so14582301obb.31 for ; Thu, 05 Jul 2012 00:30: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 :content-type; bh=iiJ1zNAwg4uWAvvz6Gqpw+5QM1t+ADwMFFVeIVhMlSk=; b=uf8SjUVsjxs/zW89ENJeF8AQ6AgTF//qXlr+2F/o7fkARtkhlrdl7Vltl1+y1onPK0 mOVrzlwtnc85kOfBHWuAN/DuJQnJ6f9k8NCltNQ3FTMDolVZRyIr4mtKHl1l/tsBcSt2 PwJTVw6XbkMb5Xx34GeCJ1CNmtufsWdrncQDLYuVJJW2YCvY6k6JL/dyJ5qy+naVG2ZX bxfhHkWl88DhzPvUUKaufzbAj63vhl42jO2TWc4MiipbC8lgyJtPovIZ4qKGumfYcrVm JwkNJYBFyJgu901A3MdnVonVgxCtoUWIMJM7VIgGl+G43Tmzrv4WVscMeDAfpqgfBCmb yfRg== MIME-Version: 1.0 Received: by 10.60.12.37 with SMTP id v5mr25495012oeb.25.1341473434687; Thu, 05 Jul 2012 00:30:34 -0700 (PDT) Received: by 10.182.152.101 with HTTP; Thu, 5 Jul 2012 00:30:34 -0700 (PDT) In-Reply-To: <20120704091946.23623.47219.idtracker@ietfa.amsl.com> References: <20120704091946.23623.47219.idtracker@ietfa.amsl.com> Date: Thu, 5 Jul 2012 15:30:34 +0800 Message-ID: From: GangChen To: v6ops Content-Type: text/plain; charset=ISO-8859-1 Subject: [v6ops] Fwd: I-D Action: draft-chen-v6ops-nat64-experience-02.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, 05 Jul 2012 07:30:23 -0000 Hello all, We have updated draft of NAT64 experiences regarding the discussions on the previous submission. It's expected that the draft could serve a role to generalize NAT64 experiences and advocate IPv6-only deployment. Current draft is a joined effort from several operators who is actively progressing IPv6 deployment. We are thankful for the kind reviews from the list. The comments have been seriously considered and updated in the draft. The authors hope the draft is of value to the community. It's highly appreciated for further comments and potential adoption. URL: http://www.ietf.org/internet-drafts/draft-chen-v6ops-nat64-experience-02.txt Diff: http://tools.ietf.org/rfcdiff?url2=draft-chen-v6ops-nat64-experience-02 Many thanks Gang ---------- Forwarded message ---------- From: internet-drafts@ietf.org Date: Wed, 04 Jul 2012 02:19:46 -0700 Subject: I-D Action: draft-chen-v6ops-nat64-experience-02.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : NAT64 Operational Experiences Author(s) : Gang Chen Zhen Cao Cameron Byrne Chongfeng Xie David Binet Filename : draft-chen-v6ops-nat64-experience-02.txt Pages : 15 Date : 2012-07-04 Abstract: This document summarizes some stateful NAT64 deployment scenarios and operational experiences for NAT64-CGN and NAT64-CE. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-chen-v6ops-nat64-experience There's also a htmlized version available at: http://tools.ietf.org/html/draft-chen-v6ops-nat64-experience-02 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=draft-chen-v6ops-nat64-experience-02 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 achatz@forthnetgroup.gr Thu Jul 5 04:52: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 2955721F869A; Thu, 5 Jul 2012 04:52:11 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kskOaffXs9KG; Thu, 5 Jul 2012 04:52:10 -0700 (PDT) Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.107]) by ietfa.amsl.com (Postfix) with ESMTP id 4174421F869C; Thu, 5 Jul 2012 04:52:09 -0700 (PDT) Received: from mx-av-04.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-01.forthnet.gr (8.14.4/8.14.4) with ESMTP id q65BqKOJ007796; Thu, 5 Jul 2012 14:52:20 +0300 Received: from MX-IN-01.forthnet.gr (mx-in-01.forthnet.gr [193.92.150.23]) by mx-av-04.forthnet.gr (8.14.4/8.14.4) with ESMTP id q65BqKTL000812; Thu, 5 Jul 2012 14:52:20 +0300 Received: from [62.1.48.75] (achatz.forthnet.gr [62.1.48.75]) (authenticated bits=0) by MX-IN-01.forthnet.gr (8.14.4/8.14.4) with ESMTP id q65BqKHj008550; Thu, 5 Jul 2012 14:52:20 +0300 Authentication-Results: MX-IN-01.forthnet.gr smtp.mail=achatz@forthnetgroup.gr; auth=pass (PLAIN) Message-ID: <4FF57FF4.7010304@forthnetgroup.gr> Date: Thu, 05 Jul 2012 14:52:20 +0300 From: Tassos Chatzithomaoglou Organization: Forthnet User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120615 Firefox/13.0.1 SeaMonkey/2.10.1 MIME-Version: 1.0 To: v6ops@ietf.org, softwires@ietf.org Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [v6ops] DS-Lite & DNS X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 05 Jul 2012 11:52:11 -0000
Hi all,

I'm reading in RFC 6333:

 
5.5.  DNS

   A B4 element is only configured from the service provider with IPv6.
   As such, it can only learn the address of a DNS recursive server
   through DHCPv6 (or other similar method over IPv6).  As DHCPv6 only
   defines an option to get the IPv6 address of such a DNS recursive
   server, the B4 element cannot easily discover the IPv4 address of
   such a recursive DNS server, and as such will have to perform all DNS
   resolution over IPv6.

   The B4 element can pass this IPv6 address to downstream IPv6 nodes,
   but not to downstream IPv4 nodes.  As such, the B4 element SHOULD
   implement a DNS proxy, following the recommendations of [RFC5625].


6.4.  DNS

   As noted previously, a DS-Lite node implementing a B4 element will
   perform DNS resolution over IPv6.  As a result, DNS packets are not
   expected to go through the AFTR element.

What would be the expected behavior if i configure manually an IPv4 DNS server to a host attached to the CPE?
According to RFC5625:
 
Except when required to enforce an active security or network policy
   (such as maintaining a pre-authentication "walled garden"), end-users
   SHOULD be able to send their DNS queries to specified upstream
   resolvers, thereby bypassing the proxy altogether.  In this case, the
   gateway SHOULD NOT modify the DNS request or response packets in any
   way.

Does this mean that the 6.4 statement "DNS packets are not expected to go through the AFTR element." is not always valid?

Also, can draft-ietf-dhc-dhcpv4-over-ipv6 be considered an alternative option for passing IPv4 info to clients over IPv6 in DS-Lite networks?


 
--
Tassos
From Carl.Wuyts@technicolor.com Thu Jul 5 05:06: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 CE39C21F8694; Thu, 5 Jul 2012 05:06:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kaaIel3kvJwV; Thu, 5 Jul 2012 05:06:00 -0700 (PDT) Received: from na3sys009aog133.obsmtp.com (na3sys009aog133.obsmtp.com [74.125.149.82]) by ietfa.amsl.com (Postfix) with ESMTP id 2DC8721F8480; Thu, 5 Jul 2012 05:05:53 -0700 (PDT) Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob133.postini.com ([74.125.148.12]) with SMTP ID DSNKT/WDKTAJJDwHYVbBNGOYwvkls3kUdbMi@postini.com; Thu, 05 Jul 2012 05:06:11 PDT Received: from MOPESMAILHC01.eu.thmulti.com (141.11.100.25) by mail3.technicolor.com (141.11.253.22) with Microsoft SMTP Server (TLS) id 8.3.264.0; Thu, 5 Jul 2012 14:01:37 +0200 Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.192]) by MOPESMAILHC01.eu.thmulti.com ([141.11.100.25]) with mapi; Thu, 5 Jul 2012 14:01:44 +0200 From: Wuyts Carl To: Tassos Chatzithomaoglou , "v6ops@ietf.org" , "softwires@ietf.org" Date: Thu, 5 Jul 2012 14:01:42 +0200 Thread-Topic: [v6ops] DS-Lite & DNS Thread-Index: Ac1apK1fN+XmL3B5TDyv5XoLrhZ4QAAAHRAw Message-ID: <867F4B6A1672E541A94676D556793ACD149FA79734@MOPESMBX01.eu.thmulti.com> References: <4FF57FF4.7010304@forthnetgroup.gr> In-Reply-To: <4FF57FF4.7010304@forthnetgroup.gr> 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_867F4B6A1672E541A94676D556793ACD149FA79734MOPESMBX01eut_" MIME-Version: 1.0 Subject: Re: [v6ops] DS-Lite & DNS X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 05 Jul 2012 12:06:00 -0000 --_000_867F4B6A1672E541A94676D556793ACD149FA79734MOPESMBX01eut_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SEksDQoNCkZpcnN0IG9mIGFsbCwgYXNzaWduaW5nIEROUyBpbmZvIHRvIGhvc3QgYmVoaW5kIGEg Q1BFIGRvZXNu4oCZdCBsb29rIGEgc2NhbGFibGUgdGhpbmcvc29sdXRpb24gdG8gbWUsIGFsdGhv dWdoIHBvc3NpYmxlIG9mIGNvdXJzZS4NClNlY29uZGx5LCBJIHRoaW5rIHRoZSBpc3N1ZSBzdGF0 ZWQgaW4gdGhlIFJGQyBpcyBvbiBob3cgdG8gZ2V0IEROUyBpbmZvIHRvIHRoZSBDUEUvaG9zdHMs IHJhdGhlciB0aGFuIGhvdyB0aGUgbWVzc2FnZSBmbG93IGlzIGZvciBETlMgcXVlcmllcyAodjQv djYpLg0KV2l0aCBhIEROUyBQcm94eSwgeW91ciBETnMgcXVlcnksIG5vIG1hdHRlciBBL0FBQSBv ciB2NC92NiB0cmFuc3BvcnQsIHdpbGwgYmUgc2VudCB0byB0aGUgQ1BFIHdoaWNoIGluIGl0cyB0 dXJuIGNhbiBmb3J3YXJkIGl0IHRvIGl0cyBhdmFpbGFibGUgRE5TIHNlcnZlcnMgKHdoaWNoIGhl IHBvdGVudGlhbGx5IGNhbiBnZXQgdGhyb3VnaCBkaWZmZXJlbnQgY2hhbm5lbHMgbGlrZSBQUFAs IERIQ1B2NCBhbmQgdjYsIHN0YXRpYywgIOKApjsgZm9yIGRzbGl0ZSBzb2x1dGlvbiBpdOKAmWxs IGJlIHN0YXRpYyBvciBkaGNwdjYgbW9zdCBsaWtlbHkpLg0KSW4geW91ciB1c2UgY2FzZSwgdGhl IGhvc3Qga25vd3MgYWJvdXQgdGhlIEROUyBzZXJ2ZXIsIHNvIG5vIG5lZWQgdG8gcGFzcyB0aGUg cmVxdWVzdCB0aHJvdWdoIHRoZSBDUEUgYW5kIGFzayB0byBDUEUgdG8gaGFuZGxlIGl0LCBidXQg anVzdCByb3V0ZSB0aGUgcGFja2V0IHRvIGl0cyBkZXN0aW5hdGlvbi4gIEluIHRoaXMgY2FzZSwg dGhlIHF1ZXN0aW9uIHdpbGwgYmU6IGRvZXMgdGhlIENQRSBoYXMgYSByb3V0ZSB0byBpdHMgZGVz dGluYXRpb24gPyAgSWYgc28gKGUuZy4gZGVmYXVsdCByb3V0ZSB0byBEU0xpdGUgdHVubmVsIGZv ciB2NCB0cmFmZmljKSB0aGUgcGFja2V0IHdpbGwganVzdCBiZSByb3V0ZWQsIGlmIG5vdCwgcGFj a2V0IHdpbGwgYmUgZHJvcHBlZC4NCg0KcmVncw0KQ2FybA0KRnJvbTogdjZvcHMtYm91bmNlc0Bp ZXRmLm9yZyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBUYXNz b3MgQ2hhdHppdGhvbWFvZ2xvdQ0KU2VudDogZG9uZGVyZGFnIDUganVsaSAyMDEyIDEzOjUyDQpU bzogdjZvcHNAaWV0Zi5vcmc7IHNvZnR3aXJlc0BpZXRmLm9yZw0KU3ViamVjdDogW3Y2b3BzXSBE Uy1MaXRlICYgRE5TDQoNCg0KSGkgYWxsLA0KDQpJJ20gcmVhZGluZyBpbiBSRkMgNjMzMzoNCjUu NTxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2MzMzI3NlY3Rpb24tNS41Pi4gIEROUw0K DQoNCg0KICAgQSBCNCBlbGVtZW50IGlzIG9ubHkgY29uZmlndXJlZCBmcm9tIHRoZSBzZXJ2aWNl IHByb3ZpZGVyIHdpdGggSVB2Ni4NCg0KICAgQXMgc3VjaCwgaXQgY2FuIG9ubHkgbGVhcm4gdGhl IGFkZHJlc3Mgb2YgYSBETlMgcmVjdXJzaXZlIHNlcnZlcg0KDQogICB0aHJvdWdoIERIQ1B2NiAo b3Igb3RoZXIgc2ltaWxhciBtZXRob2Qgb3ZlciBJUHY2KS4gIEFzIERIQ1B2NiBvbmx5DQoNCiAg IGRlZmluZXMgYW4gb3B0aW9uIHRvIGdldCB0aGUgSVB2NiBhZGRyZXNzIG9mIHN1Y2ggYSBETlMg cmVjdXJzaXZlDQoNCiAgIHNlcnZlciwgdGhlIEI0IGVsZW1lbnQgY2Fubm90IGVhc2lseSBkaXNj b3ZlciB0aGUgSVB2NCBhZGRyZXNzIG9mDQoNCiAgIHN1Y2ggYSByZWN1cnNpdmUgRE5TIHNlcnZl ciwgYW5kIGFzIHN1Y2ggd2lsbCBoYXZlIHRvIHBlcmZvcm0gYWxsIEROUw0KDQogICByZXNvbHV0 aW9uIG92ZXIgSVB2Ni4NCg0KDQoNCiAgIFRoZSBCNCBlbGVtZW50IGNhbiBwYXNzIHRoaXMgSVB2 NiBhZGRyZXNzIHRvIGRvd25zdHJlYW0gSVB2NiBub2RlcywNCg0KICAgYnV0IG5vdCB0byBkb3du c3RyZWFtIElQdjQgbm9kZXMuICBBcyBzdWNoLCB0aGUgQjQgZWxlbWVudCBTSE9VTEQNCg0KICAg aW1wbGVtZW50IGEgRE5TIHByb3h5LCBmb2xsb3dpbmcgdGhlIHJlY29tbWVuZGF0aW9ucyBvZiBb UkZDNTYyNTxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1NjI1Pl0uDQoNCg0KDQo2LjQ8 aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjMzMyNzZWN0aW9uLTYuND4uICBETlMNCg0K DQoNCiAgIEFzIG5vdGVkIHByZXZpb3VzbHksIGEgRFMtTGl0ZSBub2RlIGltcGxlbWVudGluZyBh IEI0IGVsZW1lbnQgd2lsbA0KDQogICBwZXJmb3JtIEROUyByZXNvbHV0aW9uIG92ZXIgSVB2Ni4g IEFzIGEgcmVzdWx0LCBETlMgcGFja2V0cyBhcmUgbm90DQoNCiAgIGV4cGVjdGVkIHRvIGdvIHRo cm91Z2ggdGhlIEFGVFIgZWxlbWVudC4NCg0KDQoNCldoYXQgd291bGQgYmUgdGhlIGV4cGVjdGVk IGJlaGF2aW9yIGlmIGkgY29uZmlndXJlIG1hbnVhbGx5IGFuIElQdjQgRE5TIHNlcnZlciB0byBh IGhvc3QgYXR0YWNoZWQgdG8gdGhlIENQRT8NCkFjY29yZGluZyB0byBSRkM1NjI1Og0KDQpFeGNl cHQgd2hlbiByZXF1aXJlZCB0byBlbmZvcmNlIGFuIGFjdGl2ZSBzZWN1cml0eSBvciBuZXR3b3Jr IHBvbGljeQ0KDQogICAoc3VjaCBhcyBtYWludGFpbmluZyBhIHByZS1hdXRoZW50aWNhdGlvbiAi d2FsbGVkIGdhcmRlbiIpLCBlbmQtdXNlcnMNCg0KICAgU0hPVUxEIGJlIGFibGUgdG8gc2VuZCB0 aGVpciBETlMgcXVlcmllcyB0byBzcGVjaWZpZWQgdXBzdHJlYW0NCg0KICAgcmVzb2x2ZXJzLCB0 aGVyZWJ5IGJ5cGFzc2luZyB0aGUgcHJveHkgYWx0b2dldGhlci4gIEluIHRoaXMgY2FzZSwgdGhl DQoNCiAgIGdhdGV3YXkgU0hPVUxEIE5PVCBtb2RpZnkgdGhlIEROUyByZXF1ZXN0IG9yIHJlc3Bv bnNlIHBhY2tldHMgaW4gYW55DQoNCiAgIHdheS4NCg0KRG9lcyB0aGlzIG1lYW4gdGhhdCB0aGUg Ni40IHN0YXRlbWVudCAiRE5TIHBhY2tldHMgYXJlIG5vdCBleHBlY3RlZCB0byBnbyB0aHJvdWdo IHRoZSBBRlRSIGVsZW1lbnQuIiBpcyBub3QgYWx3YXlzIHZhbGlkPw0KDQpBbHNvLCBjYW4gZHJh ZnQtaWV0Zi1kaGMtZGhjcHY0LW92ZXItaXB2NiBiZSBjb25zaWRlcmVkIGFuIGFsdGVybmF0aXZl IG9wdGlvbiBmb3IgcGFzc2luZyBJUHY0IGluZm8gdG8gY2xpZW50cyBvdmVyIElQdjYgaW4gRFMt TGl0ZSBuZXR3b3Jrcz8NCg0KDQoNCg0KLS0NCg0KVGFzc29zDQoNCg0K --_000_867F4B6A1672E541A94676D556793ACD149FA79734MOPESMBX01eut_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KaDMNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk7DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRpbmcgMyBDaGFyIjsNCgltc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ow0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTMuNXB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnR0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0 ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNl cmlmIjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1z dHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpD b25zb2xhczsNCgljb2xvcjpibGFjazt9DQpzcGFuLmgzDQoJe21zby1zdHlsZS1uYW1lOmgzO30N CnNwYW4uSGVhZGluZzNDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIZWFkaW5nIDMgQ2hhciI7DQoJ bXNvLXN0eWxlLXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRpbmcgMyI7DQoJZm9u dC1mYW1pbHk6IkNhbWJyaWEiLCJzZXJpZiI7DQoJY29sb3I6IzRGODFCRDsNCglmb250LXdlaWdo dDpib2xkO30NCnNwYW4uRW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3 RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0 IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v biBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6Ymxh Y2s7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4w cHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgYmdjb2xvcj13aGl0ZSBs YW5nPUVOLVVTIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1Xb3JkU2VjdGlvbjE+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SEksPG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj MUY0OTdEJz5GaXJzdCBvZiBhbGwsIGFzc2lnbmluZyBETlMgaW5mbyB0byBob3N0IGJlaGluZCBh IENQRSBkb2VzbuKAmXQgbG9vayBhIHNjYWxhYmxlIHRoaW5nL3NvbHV0aW9uIHRvIG1lLCBhbHRo b3VnaCBwb3NzaWJsZSBvZiBjb3Vyc2UuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlNlY29uZGx5LCBJIHRoaW5rIHRoZSBpc3N1 ZSBzdGF0ZWQgaW4gdGhlIFJGQyBpcyBvbiBob3cgdG8gZ2V0IEROUyBpbmZvIHRvIHRoZSBDUEUv aG9zdHMsIHJhdGhlciB0aGFuIGhvdyB0aGUgbWVzc2FnZSBmbG93IGlzIGZvciBETlMgcXVlcmll cyAodjQvdjYpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMUY0OTdEJz5XaXRoIGEgRE5TIFByb3h5LCB5b3VyIEROcyBxdWVyeSwgbm8gbWF0 dGVyIEEvQUFBIG9yIHY0L3Y2IHRyYW5zcG9ydCwgd2lsbCBiZSBzZW50IHRvIHRoZSBDUEUgd2hp Y2ggaW4gaXRzIHR1cm4gY2FuIGZvcndhcmQgaXQgdG8gaXRzIGF2YWlsYWJsZSBETlMgc2VydmVy cyAod2hpY2ggaGUgcG90ZW50aWFsbHkgY2FuIGdldCB0aHJvdWdoIGRpZmZlcmVudCBjaGFubmVs cyBsaWtlIFBQUCwgREhDUHY0IGFuZCB2Niwgc3RhdGljLCDCoOKApjsgZm9yIGRzbGl0ZSBzb2x1 dGlvbiBpdOKAmWxsIGJlIHN0YXRpYyBvciBkaGNwdjYgbW9zdCBsaWtlbHkpLsKgIDxvOnA+PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5J biB5b3VyIHVzZSBjYXNlLCB0aGUgaG9zdCBrbm93cyBhYm91dCB0aGUgRE5TIHNlcnZlciwgc28g bm8gbmVlZCB0byBwYXNzIHRoZSByZXF1ZXN0IHRocm91Z2ggdGhlIENQRSBhbmQgYXNrIHRvIENQ RSB0byBoYW5kbGUgaXQsIGJ1dCBqdXN0IHJvdXRlIHRoZSBwYWNrZXQgdG8gaXRzIGRlc3RpbmF0 aW9uLiDCoEluIHRoaXMgY2FzZSwgdGhlIHF1ZXN0aW9uIHdpbGwgYmU6IGRvZXMgdGhlIENQRSBo YXMgYSByb3V0ZSB0byBpdHMgZGVzdGluYXRpb24gP8KgIElmIHNvIChlLmcuIGRlZmF1bHQgcm91 dGUgdG8gRFNMaXRlIHR1bm5lbCBmb3IgdjQgdHJhZmZpYykgdGhlIHBhY2tldCB3aWxsIGp1c3Qg YmUgcm91dGVkLCBpZiBub3QsIHBhY2tldCB3aWxsIGJlIGRyb3BwZWQuPG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0 OTdEJz5yZWdzPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O2NvbG9yOiMxRjQ5N0QnPkNhcmw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PGRpdj48ZGl2IHN0eWxl PSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw dCAwY20gMGNtIDBjbSc+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjtjb2xvcjp3aW5kb3d0 ZXh0Jz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO2NvbG9yOndpbmRvd3RleHQnPiB2Nm9wcy1ib3Vu Y2VzQGlldGYub3JnIFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZ10gPGI+T24gQmVoYWxm IE9mIDwvYj5UYXNzb3MgQ2hhdHppdGhvbWFvZ2xvdTxicj48Yj5TZW50OjwvYj4gZG9uZGVyZGFn IDUganVsaSAyMDEyIDEzOjUyPGJyPjxiPlRvOjwvYj4gdjZvcHNAaWV0Zi5vcmc7IHNvZnR3aXJl c0BpZXRmLm9yZzxicj48Yj5TdWJqZWN0OjwvYj4gW3Y2b3BzXSBEUy1MaXRlICZhbXA7IEROUzxv OnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4m bmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEy LjBwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Iic+PGJyPjx0dD5IaSBhbGwsPC90dD48YnI+PGJyPjx0dD5JJ20gcmVhZGluZyBpbiBSRkMg NjMzMzo8L3R0Pjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48aDM+PGEgbmFtZT1zZWN0aW9uLTUuNT48 L2E+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjMzMyNzZWN0aW9uLTUu NSI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPjUuNTwvc3Bhbj48L2E+ PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPi7CoCBETlM8bzpwPjwvbzpw Pjwvc3Bhbj48L2gzPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPsKgwqAgQSBCNCBl bGVtZW50IGlzIG9ubHkgY29uZmlndXJlZCBmcm9tIHRoZSBzZXJ2aWNlIHByb3ZpZGVyIHdpdGgg SVB2Ni48bzpwPjwvbzpwPjwvcHJlPjxwcmU+wqDCoCBBcyBzdWNoLCBpdCBjYW4gb25seSBsZWFy biB0aGUgYWRkcmVzcyBvZiBhIEROUyByZWN1cnNpdmUgc2VydmVyPG86cD48L286cD48L3ByZT48 cHJlPsKgwqAgdGhyb3VnaCBESENQdjYgKG9yIG90aGVyIHNpbWlsYXIgbWV0aG9kIG92ZXIgSVB2 NikuwqAgQXMgREhDUHY2IG9ubHk8bzpwPjwvbzpwPjwvcHJlPjxwcmU+wqDCoCBkZWZpbmVzIGFu IG9wdGlvbiB0byBnZXQgdGhlIElQdjYgYWRkcmVzcyBvZiBzdWNoIGEgRE5TIHJlY3Vyc2l2ZTxv OnA+PC9vOnA+PC9wcmU+PHByZT7CoMKgIHNlcnZlciwgdGhlIEI0IGVsZW1lbnQgY2Fubm90IGVh c2lseSBkaXNjb3ZlciB0aGUgSVB2NCBhZGRyZXNzIG9mPG86cD48L286cD48L3ByZT48cHJlPsKg wqAgc3VjaCBhIHJlY3Vyc2l2ZSBETlMgc2VydmVyLCBhbmQgYXMgc3VjaCB3aWxsIGhhdmUgdG8g cGVyZm9ybSBhbGwgRE5TPG86cD48L286cD48L3ByZT48cHJlPsKgwqAgcmVzb2x1dGlvbiBvdmVy IElQdjYuPG86cD48L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHByZT7C oMKgIFRoZSBCNCBlbGVtZW50IGNhbiBwYXNzIHRoaXMgSVB2NiBhZGRyZXNzIHRvIGRvd25zdHJl YW0gSVB2NiBub2Rlcyw8bzpwPjwvbzpwPjwvcHJlPjxwcmU+wqDCoCBidXQgbm90IHRvIGRvd25z dHJlYW0gSVB2NCBub2Rlcy7CoCBBcyBzdWNoLCB0aGUgQjQgZWxlbWVudCBTSE9VTEQ8bzpwPjwv bzpwPjwvcHJlPjxwcmU+wqDCoCBpbXBsZW1lbnQgYSBETlMgcHJveHksIGZvbGxvd2luZyB0aGUg cmVjb21tZW5kYXRpb25zIG9mIFs8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9y ZmM1NjI1IiB0aXRsZT0iJnF1b3Q7RE5TIFByb3h5IEltcGxlbWVudGF0aW9uIEd1aWRlbGluZXMm cXVvdDsiPlJGQzU2MjU8L2E+XS48bzpwPjwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286 cD48L3ByZT48aDM+PGEgbmFtZT1zZWN0aW9uLTYuND48L2E+PGEgaHJlZj0iaHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvcmZjNjMzMyNzZWN0aW9uLTYuNCI+PHNwYW4gc3R5bGU9J2ZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyInPjYuNDwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyInPi7CoCBETlM8bzpwPjwvbzpwPjwvc3Bhbj48L2gzPjxwcmU+PG86cD4m bmJzcDs8L286cD48L3ByZT48cHJlPsKgwqAgQXMgbm90ZWQgcHJldmlvdXNseSwgYSBEUy1MaXRl IG5vZGUgaW1wbGVtZW50aW5nIGEgQjQgZWxlbWVudCB3aWxsPG86cD48L286cD48L3ByZT48cHJl PsKgwqAgcGVyZm9ybSBETlMgcmVzb2x1dGlvbiBvdmVyIElQdjYuwqAgQXMgYSByZXN1bHQsIERO UyBwYWNrZXRzIGFyZSBub3Q8bzpwPjwvbzpwPjwvcHJlPjxwcmU+wqDCoCBleHBlY3RlZCB0byBn byB0aHJvdWdoIHRoZSBBRlRSIGVsZW1lbnQuPG86cD48L286cD48L3ByZT48cHJlPjxvOnA+Jm5i c3A7PC9vOnA+PC9wcmU+PHAgY2xhc3M9TXNvTm9ybWFsPjxicj48dHQ+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQnPldoYXQgd291bGQgYmUgdGhlIGV4cGVjdGVkIGJlaGF2aW9yIGlmIGkg Y29uZmlndXJlIG1hbnVhbGx5IGFuIElQdjQgRE5TIHNlcnZlciB0byBhIGhvc3QgYXR0YWNoZWQg dG8gdGhlIENQRT88L3NwYW4+PC90dD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseToiQ291cmllciBOZXciJz48YnI+PHR0PkFjY29yZGluZyB0byBSRkM1NjI1OjwvdHQ+ PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwcmU+RXhjZXB0IHdoZW4gcmVxdWlyZWQgdG8gZW5mb3Jj ZSBhbiBhY3RpdmUgc2VjdXJpdHkgb3IgbmV0d29yayBwb2xpY3k8bzpwPjwvbzpwPjwvcHJlPjxw cmU+wqDCoCAoc3VjaCBhcyBtYWludGFpbmluZyBhIHByZS1hdXRoZW50aWNhdGlvbiAmcXVvdDt3 YWxsZWQgZ2FyZGVuJnF1b3Q7KSwgZW5kLXVzZXJzPG86cD48L286cD48L3ByZT48cHJlPsKgwqAg U0hPVUxEIGJlIGFibGUgdG8gc2VuZCB0aGVpciBETlMgcXVlcmllcyB0byBzcGVjaWZpZWQgdXBz dHJlYW08bzpwPjwvbzpwPjwvcHJlPjxwcmU+wqDCoCByZXNvbHZlcnMsIHRoZXJlYnkgYnlwYXNz aW5nIHRoZSBwcm94eSBhbHRvZ2V0aGVyLsKgIEluIHRoaXMgY2FzZSwgdGhlPG86cD48L286cD48 L3ByZT48cHJlPsKgwqAgZ2F0ZXdheSBTSE9VTEQgTk9UIG1vZGlmeSB0aGUgRE5TIHJlcXVlc3Qg b3IgcmVzcG9uc2UgcGFja2V0cyBpbiBhbnk8bzpwPjwvbzpwPjwvcHJlPjxwcmU+wqDCoCB3YXku PG86cD48L286cD48L3ByZT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+PGJyPjx0dD5Eb2VzIHRoaXMgbWVh biB0aGF0IHRoZSA2LjQgc3RhdGVtZW50ICZxdW90O0ROUyBwYWNrZXRzIGFyZSBub3QgZXhwZWN0 ZWQgdG8gZ28gdGhyb3VnaCB0aGUgQUZUUiBlbGVtZW50LiZxdW90OyBpcyBub3QgYWx3YXlzIHZh bGlkPzwvdHQ+PGJyPjxicj48dHQ+QWxzbywgY2FuIGRyYWZ0LWlldGYtZGhjLWRoY3B2NC1vdmVy LWlwdjYgYmUgY29uc2lkZXJlZCBhbiBhbHRlcm5hdGl2ZSBvcHRpb24gZm9yIHBhc3NpbmcgSVB2 NCBpbmZvIHRvIGNsaWVudHMgb3ZlciBJUHY2IGluIERTLUxpdGUgbmV0d29ya3M/PC90dD48YnI+ PGJyPjxicj48YnI+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwcmU+LS08bzpwPjwvbzpwPjwvcHJl PjxwcmU+VGFzc29zPG86cD48L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+ PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_867F4B6A1672E541A94676D556793ACD149FA79734MOPESMBX01eut_-- From achatz@forthnetgroup.gr Thu Jul 5 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 F0EE121F869D; Thu, 5 Jul 2012 06:06:37 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nAo9tK8sUdmQ; Thu, 5 Jul 2012 06:06:37 -0700 (PDT) Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.107]) by ietfa.amsl.com (Postfix) with ESMTP id C40B421F8630; Thu, 5 Jul 2012 06:06:36 -0700 (PDT) Received: from mx-av-06.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-06.forthnet.gr (8.14.4/8.14.4) with ESMTP id q65D6mkX019553; Thu, 5 Jul 2012 16:06:48 +0300 Received: from MX-IN-01.forthnet.gr (mx-in-01.forthnet.gr [193.92.150.23]) by mx-av-06.forthnet.gr (8.14.4/8.14.4) with ESMTP id q65D6nDq016724; Thu, 5 Jul 2012 16:06:49 +0300 Received: from [62.1.48.75] (achatz.forthnet.gr [62.1.48.75]) (authenticated bits=0) by MX-IN-01.forthnet.gr (8.14.4/8.14.4) with ESMTP id q65D6mL9025511; Thu, 5 Jul 2012 16:06:48 +0300 Authentication-Results: MX-IN-01.forthnet.gr smtp.mail=achatz@forthnetgroup.gr; auth=pass (PLAIN) Message-ID: <4FF59168.3030600@forthnetgroup.gr> Date: Thu, 05 Jul 2012 16:06:48 +0300 From: Tassos Chatzithomaoglou Organization: Forthnet User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120615 Firefox/13.0.1 SeaMonkey/2.10.1 MIME-Version: 1.0 To: Wuyts Carl References: <4FF57FF4.7010304@forthnetgroup.gr> <867F4B6A1672E541A94676D556793ACD149FA79734@MOPESMBX01.eu.thmulti.com> In-Reply-To: <867F4B6A1672E541A94676D556793ACD149FA79734@MOPESMBX01.eu.thmulti.com> Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "softwires@ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] DS-Lite & DNS X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 05 Jul 2012 13:06:38 -0000
Since i (as an operator) manage the CPE but not the host, i got a little bit worried and confused by the statement "DNS packets are not expected to go through the AFTR element", since the subscriber can easily send such packets.
So my understanding is that this is a supported scenario, but probably not a recommended one.

Wuyts Carl wrote on 05/07/2012 15:01:

HI,

 

First of all, assigning DNS info to host behind a CPE doesn’t look a scalable thing/solution to me, although possible of course.

Secondly, I think the issue stated in the RFC is on how to get DNS info to the CPE/hosts, rather than how the message flow is for DNS queries (v4/v6).

With a DNS Proxy, your DNs query, no matter A/AAA or v4/v6 transport, will be sent to the CPE which in its turn can forward it to its available DNS servers (which he potentially can get through different channels like PPP, DHCPv4 and v6, static,  …; for dslite solution it’ll be static or dhcpv6 most likely). 

In your use case, the host knows about the DNS server, so no need to pass the request through the CPE and ask to CPE to handle it, but just route the packet to its destination.  In this case, the question will be: does the CPE has a route to its destination ?  If so (e.g. default route to DSLite tunnel for v4 traffic) the packet will just be routed, if not, packet will be dropped.

 

regs

Carl

From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Tassos Chatzithomaoglou
Sent: donderdag 5 juli 2012 13:52
To: v6ops@ietf.org; softwires@ietf.org
Subject: [v6ops] DS-Lite & DNS

 


Hi all,

I'm reading in RFC 6333:

5.5.  DNS

 
   A B4 element is only configured from the service provider with IPv6.
   As such, it can only learn the address of a DNS recursive server
   through DHCPv6 (or other similar method over IPv6).  As DHCPv6 only
   defines an option to get the IPv6 address of such a DNS recursive
   server, the B4 element cannot easily discover the IPv4 address of
   such a recursive DNS server, and as such will have to perform all DNS
   resolution over IPv6.
 
   The B4 element can pass this IPv6 address to downstream IPv6 nodes,
   but not to downstream IPv4 nodes.  As such, the B4 element SHOULD
   implement a DNS proxy, following the recommendations of [RFC5625].
 

6.4.  DNS

 
   As noted previously, a DS-Lite node implementing a B4 element will
   perform DNS resolution over IPv6.  As a result, DNS packets are not
   expected to go through the AFTR element.
 


What would be the expected behavior if i configure manually an IPv4 DNS server to a host attached to the CPE?
According to RFC5625:

Except when required to enforce an active security or network policy
   (such as maintaining a pre-authentication "walled garden"), end-users
   SHOULD be able to send their DNS queries to specified upstream
   resolvers, thereby bypassing the proxy altogether.  In this case, the
   gateway SHOULD NOT modify the DNS request or response packets in any
   way.


Does this mean that the 6.4 statement "DNS packets are not expected to go through the AFTR element." is not always valid?

Also, can draft-ietf-dhc-dhcpv4-over-ipv6 be considered an alternative option for passing IPv4 info to clients over IPv6 in DS-Lite networks?



--
Tassos
 


From yiu_lee@cable.comcast.com Thu Jul 5 09:26: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 82F1B21F870F; Thu, 5 Jul 2012 09:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.272 X-Spam-Level: X-Spam-Status: No, score=-103.272 tagged_above=-999 required=5 tests=[AWL=0.562, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xPl9hoVI4aEc; Thu, 5 Jul 2012 09:26:47 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 8D21121F8703; Thu, 5 Jul 2012 09:26:47 -0700 (PDT) Received: from ([24.40.56.116]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.23912679; Thu, 05 Jul 2012 10:09:09 -0600 Received: from PACDCEXMB05.cable.comcast.com ([169.254.7.115]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%13]) with mapi id 14.02.0309.002; Thu, 5 Jul 2012 12:26:44 -0400 From: "Lee, Yiu" Thread-Topic: [Softwires] [v6ops] DS-Lite & DNS Thread-Index: AQHNWsr3bLQq679MMUCPWZ0Id4LKKQ== Date: Thu, 5 Jul 2012 16:26:44 +0000 Message-ID: In-Reply-To: <4FF59168.3030600@forthnetgroup.gr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 x-originating-ip: [24.40.55.70] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3424336003_9715749" MIME-Version: 1.0 To: Tassos Chatzithomaoglou , Wuyts Carl Cc: "softwires@ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] [Softwires] DS-Lite & DNS X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 05 Jul 2012 16:26:48 -0000 --B_3424336003_9715749 Content-type: multipart/alternative; boundary="B_3424336003_9732321" --B_3424336003_9732321 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Since the DNS server at home only manages its own dns-domain, the dns-server should still use the CPE's IP for external dns query. If user decides not to use the CPE's IP, all dns packets would use the tunnel. If an operator wants to block this, in theory this will require implementing ACL to block dns in AFTR. In practice, this would probably make the user very unhappy. Draft-ietf-dns-dhcpv4-over-ipv6 addresses a different use case. This will be used when the CPE will be provisioned with a full public IPv4 address (i.e. No NAT in the AFTR). From: Tassos Chatzithomaoglou Organization: Forthnet Date: Thursday, July 5, 2012 9:06 AM To: Wuyts Carl Cc: "softwires@ietf.org" , "v6ops@ietf.org" Subject: Re: [Softwires] [v6ops] DS-Lite & DNS Since i (as an operator) manage the CPE but not the host, i got a little bit worried and confused by the statement "DNS packets are not expected to go through the AFTR element", since the subscriber can easily send such packets. So my understanding is that this is a supported scenario, but probably not a recommended one. Also, can draft-ietf-dhc-dhcpv4-over-ipv6 be considered an alternative option for passing IPv4 info to clients over IPv6 in DS-Lite networks? --B_3424336003_9732321 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Since the DNS server at home= only manages its own dns-domain, the dns-server should still use the CPE's = IP for external dns query. If user decides not to use the CPE's IP, all dns = packets would use the tunnel. If an operator wants to block this, in theory = this will require implementing ACL to block dns in AFTR. In practice, this w= ould probably make the user very unhappy.

Draft-iet= f-dns-dhcpv4-over-ipv6 addresses a different use case. This will be used whe= n the CPE will be provisioned with a full public IPv4 address (i.e. No NAT i= n the AFTR).


= From: Tassos Chatzithomaoglou <achatz@forthnetgroup.gr>
Org= anization: Forthnet
Date: = Thursday, July 5, 2012 9:06 AM
To: = Wuyts Carl <Carl.Wuyts@techn= icolor.com>
Cc: "softwires@ietf.org" <softwires@ietf.org>, "v= 6ops@ietf.org" <v6ops@ietf.org>= ;
Subject: Re: [Softwires] [v6ops]= DS-Lite & DNS

Since i (as an = operator) manage the CPE but not the host, i got a little bit worried and co= nfused by the statement "DNS packets are not expected to go through the AFTR= element", since the subscriber can easily send such packets.
So my under= standing is that this is a supported scenario, but probably not a recommende= d one.


Also, can dr= aft-ietf-dhc-dhcpv4-over-ipv6 be considered an alternative option for passin= g IPv4 info to clients over IPv6 in DS-Lite networks?
--B_3424336003_9732321-- --B_3424336003_9715749 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVlwYJKoZIhvcNAQcCoIIViDCCFYQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EzAwggUzMIIEG6ADAgECAhBTm5vcGTrcIPdnvVTe3rDkMA0GCSqGSIb3DQEBBQUAMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTEyMDIxNDAwMDAwMFoX DTEzMDIxMzIzNTk1OVowKjEoMCYGCSqGSIb3DQEJARYZeWl1X2xlZUBjYWJsZS5jb21jYXN0 LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANOm2q1Oat5U5a79IA1Yx+oa djvccI4HQYLkQtDXj9an1bz7JT52yBADiZJ42pTJ35L4yPzYRY/4b1k7RCsodmRzu4F2n1wA Xjg3hkRygwiAVrEv7p1FM4Wsr4nY6utC6/dhrJFkTtLzMmQXcSeVF1gpoaDKzf9UNvXNZCy8 dpLhdP4v8t7JOhfPyR3LBOo7vKk4WIv7ugGVgyLXwGSwu0rEVNOwLtPdoTJW0pi+ATaJeAuf WVIKLRVjK56vKBeA3ms3BJNOp5zkfAk5j3IymZZMD156Tib5ViL8dCTycYZyMNWBOrDPC/yn c4itE6q05Wh94QYGp6GcsZkiHEXFZrUCAwEAAaOCAekwggHlMB8GA1UdIwQYMBaAFHoTTgB0 W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTdz82GEvcyRLU/wx9KzuYvjgUddzAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQED BQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9u YW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0 cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1 cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCQG A1UdEQQdMBuBGXlpdV9sZWVAY2FibGUuY29tY2FzdC5jb20wDQYJKoZIhvcNAQEFBQADggEB AFeEfwmWgj/jpA3+ctSoBsbvHGnWLz00p8NBX2+qzz8QjgDpZT5T1Fux5MV6qlVJpND12pzq ziUyFCBdv6QOMyiOrn5RxooXY9W6Hpa8qBD4v9BXy5qtP7gi4xJhFufXdNZXEw2RwNyjBzfV /F2Q8HSwlyOwS+fHKYZZ9gy/KneVP//YcrC4icG1ipJQ2+gCUs+uUAouz0xF0uBYE/bQRTss oRTY6D/X5lxarw28oocfr38v4Ro5bmsZlsEF22OvpKZX5tfz1aOL5U9nhXixY7Sd9B9BGHl7 mrybVUl7NnguWGIAhHiVD9ce1u4jJ1PnNmrNkvwJouS/7zYCId8000cwggUaMIIEAqADAgEC AhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRS VVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UE AxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTEx MDQyODAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY 1F4vi6ThQMijU1hfZmXxMk73nzJ9VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFp ruUgG+TLY15gyqJB9mrho/+43x9IbWVDjCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVU gK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLSTNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/ FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsyfuNK4aVScmQmkU6lkg//4LFg/RpvaFGZ Y40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//BAgMBAAGjggFLMIIBRzAfBgNVHSME GDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUehNOAHRbxnhjZCfBL+KgW7x5 xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwEQYDVR0gBAowCDAGBgRV HSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tVVNF UkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsGAQUFBwEBBGgw ZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRydXN0Q2xp ZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkq hkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5 yv7ikR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080z X5vQvWBqszv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG 1l1XBxunML5LSUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u 5zCCBJ0wggOFoAMCAQICEDQ96SusJzT/j8s0lPvMcFQwDQYJKoZIhvcNAQEFBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRl cm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAe Fw0wNTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UE CBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMt VVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxq mNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPM yaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbN oKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcR Wdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/ MLbu9mIwFIws6wIDAQABo4H0MIHxMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1Qa MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0T AQH/BAUwAwEB/zARBgNVHSAECjAIMAYGBFUdIAAwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDov L2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDUGCCsGAQUF BwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAAbyc42MosPMxAcLfe91ioAGdIzEPnJJzU1HqH0z61p/Eyi9nfngzD3QW uZGHkfWKJvpkcADYHvkLBGJQh5OB1Nr1I9s0u4VWtHA0bniDNx6FHMURFZJfhxe9rGr98cLR zIlfsXzwPlHyNfN87GCYazor4O/fs32G67Ub9VvsonyYE9cAULnRLXPeA3h04QWFMV7Lmrmd lMa5lDd1ctxE+2fo8PolHlKn2iXpR+CgxzygTrEKNvt3SJ/vl4r7tP7jlBSog7xcLT/SYHFg 7sJxggzpiDbj2iC0o6BsqpZLuICOdcpJB/Y7FLrf3AXZn9vgsuZNoHgm5+ctbn9fxh6IFTCC BDYwggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoT C0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEi MCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0y MDA1MzAxMDQ4MzhaMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0 IEV4dGVybmFsIENBIFJvb3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz 5vIABC054E5b7R+8bA/Ntfojts7emxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl6 2y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKedMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pO rwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCrTLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1B X3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXEXSp9t7TWxO6szRNEt8kr3UMAJfphuWlq WCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPVNFonAgMBAAGjgdwwgdkwHQYDVR0O BBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIBBjAPBgNVHRMBAf8EBTADAQH/ MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOkcTBvMQswCQYDVQQGEwJT RTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRU UCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290ggEBMA0GCSqG SIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7rEFsR2CD UbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEULY69 FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvh jJiDyx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYE MYICLzCCAisCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkw NwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEFObm9wZOtwg92e9VN7esOQwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBT3GxRC TwAdSJwPBtF/65hhgCSGrDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0xMjA3MDUxNjI2NDNaMA0GCSqGSIb3DQEBAQUABIIBAFfSoVjFDqR4aEcvzEZwYBXq Rjv6BCwhicViTBQXKuUn9q4EMBuUS/obOmzk/QSNjEFogcF2eCWZUy2x7ygjqnrAeDt4tyPu Jit2ott7KtIXioSddTmFysrMbfhTgHPlrehnjfpSZy4tdQ3enQB8jcd5endGii8HNSHP8sXV tH7a7yePNOkzM6POXeEeAqtn4q4o2+Z8CqNAOLJohgLLPJkJU0uENTogvcXgbon8ZXKR/u4V YGydaYk+qrX8XIKgm+Qg4q8c//KtIvN2U0/tNUEb1kBh/8Hzmu5Mxlo+35riUBBNZMGXbO3U aD4Iy8E+RXUNS++BAdicFNDrdcx7+Wg= --B_3424336003_9715749-- From philip_matthews@magma.ca Fri Jul 6 05:58: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 8703321F8763 for ; Fri, 6 Jul 2012 05:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.58 X-Spam-Level: X-Spam-Status: No, score=-1.58 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2TS6r90Llhy for ; Fri, 6 Jul 2012 05:58:33 -0700 (PDT) Received: from mail-01.primus.ca (smtp2.primus.ca [209.216.129.142]) by ietfa.amsl.com (Postfix) with ESMTP id DC13621F86EA for ; Fri, 6 Jul 2012 05:58:32 -0700 (PDT) Received: from [74.198.165.123] (helo=[172.20.10.2]) by mail-01.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1Sn87Q-00036j-2x; Fri, 06 Jul 2012 08:58:48 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Philip Matthews In-Reply-To: Date: Fri, 6 Jul 2012 08:58:38 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3F7BC6E6-10C6-464D-9F9D-3769F432728B@magma.ca> References: To: Jean-Francois.TremblayING@videotron.com X-Mailer: Apple Mail (2.1084) X-Authenticated: philip_matthews - ([172.20.10.2]) [74.198.165.123] Cc: v6ops@ietf.org Subject: Re: [v6ops] RE new draft: draft-matthews-v6ops-design-guidelines X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Jul 2012 12:58:33 -0000 Thanks very much for your helpful comments and your interest in the = draft. Some comments inline. - Philip On 2012-07-04, at 9:14 , Jean-Francois.TremblayING@videotron.com wrote: >> A new draft has been posted, at http://tools.ietf.org/html/draft- >> matthews-v6ops-design-guidelines. Please take a look at it and = comment. >=20 > Useful, although coming a bit late for most ISPs. Some guidelines also=20= > apply to enterprises.=20 >=20 > A few additionnal comments/ideas:=20 >=20 > 3.2 Adressing > Global vs ULA arguments could also be considered. A disadvantage of = ULA=20 > is the lack of reverse DNS, unless the reverse zone is added locally.=20= > Advantage of ULA is simplicity to filter. Possibly less = administrativa.=20 My thought is that the draft should focus on design choices about IPv6 = (or the combination of IPv4 and IPv6) that do not come up with pure = IPv4. Otherwise, the possible topics to cover in the draft become much = bigger, and the draft no longer seems to fall within the charter of = V6OPS. So what I am wondering is: do ULAs provide a design choice that 1918 = addresses do not provide in IPv4? Right now, I don't see any, but maybe = I am missing something. I will think about this some more. >=20 > 4.1 Next-hop > Some early implementations of next hop redundancy protocols supported=20= > a or b exclusively.=20 Perhaps it wasn't clear that section 4.1 is supposed to talk about = next-hop addresses for _static routes_, and not next hops in general. = I will try to make this clearer in the next version. However, your comment points out that the draft does not currently cover = VRRP. Thanks! I will add that in future revision, as VRRP does seem = to have a few interesting design topics. >=20 > 6. iBGP > Some protocols require a specific combination of AF and transport. For=20= > example, 6PE/6vPE requires IPv6 and VPNv6 address families over IPv4=20= > transport. Native IPv6 routes should be over IPv6 transport.=20 Yes. I am trying to figure out how to handle iBGP, as saying something = interesting about it really depends on what you are trying to do with = it. I am starting to think that I should not cover it in isolation, but = rather in some larger context (e.g., in the context of talking about 6PE = or 6VPE)=20 >=20 > 7. ISIS > Multi-topology vs single topology > Some implementations of ISIS have issues running IPv6 with a single=20 > topology. Multi-topology is recommended, even if IPv4 is not carried = in=20 > LSPs.=20 I agree. I will cover this in a future revision. >=20 > /JF >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From joelja@bogus.com Fri Jul 6 08:42: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 9E44C21F8666 for ; Fri, 6 Jul 2012 08:42:41 -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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l1+-xZdxvh-z for ; Fri, 6 Jul 2012 08:42:41 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0D0B421F8661 for ; Fri, 6 Jul 2012 08:42:41 -0700 (PDT) Received: from Joels-MacBook-Pro.local (c-71-193-176-225.hsd1.wa.comcast.net [71.193.176.225]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q66FgvD8019194 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Fri, 6 Jul 2012 15:42:57 GMT (envelope-from joelja@bogus.com) Message-ID: <4FF7077B.5050703@bogus.com> Date: Fri, 06 Jul 2012 08:42:51 -0700 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: IPv6 Ops WG References: <0B2FA58F71A34C199446380DA654FB07@LENOVO1E4798BB> <1DFE8BF4-885E-4F2F-AA1B-4FC1658BA688@cisco.com> In-Reply-To: <1DFE8BF4-885E-4F2F-AA1B-4FC1658BA688@cisco.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 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]); Fri, 06 Jul 2012 15:42:57 +0000 (UTC) Subject: [v6ops] Call for Adoption, was Re: New draft waiting for adoption: draft-chen-v6ops-nat64-experience-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Jul 2012 15:42:41 -0000 The following message commences a 1 week call for opinions on the adoption of draft-chen-v6ops-nat64-experience-02 http://tools.ietf.org/html/draft-chen-v6ops-nat64-experience-02 Friday 7/13/2012 is the deadline for this particular call. Thank you. joel >> ä¼ä¸šæ ‡å‡†çš„文本格å¼ï¼ˆæ¨¡ç‰ˆï¼‰ >> >> Dear Chairs, >> >> >> >> We have posted new draft of NAT64 experiences. >> >> Current draft is a joined effort from four operators (China Mobile, >> T-mobile USA, China Telecom and France Telecom) >> >> who is actively progressing IPv6 deployment depending on the practices. >> >> Several experts encourage us to continue the work after their kind review >> >> >> >> For now, we have addressed all comments. >> >> The draft is ready for the adoption. >> >> The authors would like to consult your opinions and look forward your >> guidance. >> >> >> >> >> >> Many thanks >> >> >> >> Authors >> >> >> >> ===================================================== >> >> A new version of I-D, draft-chen-v6ops-nat64-experience-02.txt >> >> has been successfully submitted by Gang Chen and posted to the >> >> IETF repository. >> >> >> >> Filename: draft-chen-v6ops-nat64-experience >> >> Revision: 02 >> >> Title: NAT64 Operational Experiences >> >> Creation date: 2012-07-04 >> >> WG ID: Individual Submission >> >> Number of pages: 15 >> >> URL: >> http://www.ietf.org/internet-drafts/draft-chen-v6ops-nat64-experience-02.txt >> >> Status: >> http://datatracker.ietf.org/doc/draft-chen-v6ops-nat64-experience >> >> Htmlized: >> http://tools.ietf.org/html/draft-chen-v6ops-nat64-experience-02 >> >> Diff: >> http://tools.ietf.org/rfcdiff?url2=draft-chen-v6ops-nat64-experience-02 >> >> >> >> Abstract: >> >> This document summarizes some stateful NAT64 deployment scenarios and >> >> operational experiences for NAT64-CGN and NAT64-CE. >> >> >> >> >> > From Jean-Francois.TremblayING@videotron.com Fri Jul 6 08:53: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 6E68321F85AE for ; Fri, 6 Jul 2012 08:53:01 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTbp9Fu1f0ii for ; Fri, 6 Jul 2012 08:53:00 -0700 (PDT) Received: from mx01.videotron.com (mx01.videotron.com [24.201.243.152]) by ietfa.amsl.com (Postfix) with ESMTP id 835D321F859A for ; Fri, 6 Jul 2012 08:53:00 -0700 (PDT) In-Reply-To: <3F7BC6E6-10C6-464D-9F9D-3769F432728B@magma.ca> To: philip_matthews@magma.ca MIME-Version: 1.0 X-KeepSent: AE24712B:7FF7157A-85257A33:005706AE; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 Message-ID: From: Jean-Francois.TremblayING@videotron.com Date: Fri, 6 Jul 2012 11:53:11 -0400 X-MIMETrack: Serialize by Router on DOMMSG01/SRV/GVL(Release 8.5.3FP1|March 07, 2012) at 07/06/2012 11:53:11, Serialize complete at 07/06/2012 11:53:11 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Received-SPF: none Cc: v6ops@ietf.org Subject: Re: [v6ops] RE new draft: draft-matthews-v6ops-design-guidelines X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Jul 2012 15:53:01 -0000 Philip Matthews a =E9crit sur 06/07/2012 08:58= :38=20 AM : > > 3.2 Adressing > > Global vs ULA arguments could also be considered. A disadvantage of=20 ULA=20 > > is the lack of reverse DNS, unless the reverse zone is added locally.=20 > > Advantage of ULA is simplicity to filter. Possibly less=20 administrativa.=20 >=20 > My thought is that the draft should focus on design choices about=20 > IPv6 (or the combination of IPv4 and IPv6) that do not come up with=20 > pure IPv4. Otherwise, the possible topics to cover in the draft=20 > become much bigger, and the draft no longer seems to fall within the > charter of V6OPS. >=20 > So what I am wondering is: do ULAs provide a design choice that 1918 > addresses do not provide in IPv4? Right now, I don't see any, but=20 > maybe I am missing something. I will think about this some more. =20 Not sure I'm following your reasoning here. Choosing to number part=20 of your network with global vs ULA adressing is an IPv6 design choice. /JF From christian.jacquenet@orange.com Fri Jul 6 09:06: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 9E01821F87B4 for ; Fri, 6 Jul 2012 09:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nf9Volnc8ChQ for ; Fri, 6 Jul 2012 09:06:32 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 5B77321F87A8 for ; Fri, 6 Jul 2012 09:06:32 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 00DA832416E; Fri, 6 Jul 2012 18:06:48 +0200 (CEST) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id D09814C06E; Fri, 6 Jul 2012 18:06:47 +0200 (CEST) Received: from PUEXCB1C.nanterre.francetelecom.fr ([10.233.200.25]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Fri, 6 Jul 2012 18:06:47 +0200 From: To: Joel jaeggli , IPv6 Ops WG Date: Fri, 6 Jul 2012 18:06:45 +0200 Thread-Topic: [v6ops] Call for Adoption, was Re: New draft waiting for adoption: draft-chen-v6ops-nat64-experience-02 Thread-Index: Ac1bjg37q2VMRgLaQ9mNiBmSJF8qUAAAxRQA Message-ID: <23024_1341590807_4FF70D17_23024_1783_30_983A1D8DA0DA5F4EB747BF34CBEE5CD15A104C59D1@PUEXCB1C.nanterre.francetelecom.fr> References: <0B2FA58F71A34C199446380DA654FB07@LENOVO1E4798BB> <1DFE8BF4-885E-4F2F-AA1B-4FC1658BA688@cisco.com> <4FF7077B.5050703@bogus.com> In-Reply-To: <4FF7077B.5050703@bogus.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="utf-8" Content-Transfer-Encoding: base64 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] Call for Adoption, was Re: New draft waiting for adoption: draft-chen-v6ops-nat64-experience-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Jul 2012 16:06:33 -0000 V0csDQoNCkkgc3VwcG9ydCB0aGUgYWRvcHRpb24gb2YgZHJhZnQtY2hlbi12Nm9wcy1uYXQ2NC1l eHBlcmllbmNlLTAyIGFzIGEgdjZvcHMgV0cgZG9jdW1lbnQuDQoNCkNoZWVycywNCg0KQ2hyaXN0 aWFuLg0KDQotLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCkRlIDogdjZvcHMtYm91bmNlc0Bp ZXRmLm9yZyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgSm9l bCBqYWVnZ2xpDQpFbnZvecOpIDogdmVuZHJlZGkgNiBqdWlsbGV0IDIwMTIgMTc6NDMNCsOAIDog SVB2NiBPcHMgV0cNCk9iamV0IDogW3Y2b3BzXSBDYWxsIGZvciBBZG9wdGlvbiwgd2FzIFJlOiBO ZXcgZHJhZnQgd2FpdGluZyBmb3IgYWRvcHRpb246IGRyYWZ0LWNoZW4tdjZvcHMtbmF0NjQtZXhw ZXJpZW5jZS0wMg0KDQpUaGUgZm9sbG93aW5nIG1lc3NhZ2UgY29tbWVuY2VzIGEgMSB3ZWVrIGNh bGwgZm9yIG9waW5pb25zIG9uIHRoZSBhZG9wdGlvbiBvZiBkcmFmdC1jaGVuLXY2b3BzLW5hdDY0 LWV4cGVyaWVuY2UtMDINCg0KIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNoZW4t djZvcHMtbmF0NjQtZXhwZXJpZW5jZS0wMg0KDQpGcmlkYXkgNy8xMy8yMDEyIGlzIHRoZSBkZWFk bGluZSBmb3IgdGhpcyBwYXJ0aWN1bGFyIGNhbGwuDQoNClRoYW5rIHlvdS4NCmpvZWwNCg0KPj4g 5LyB5Lia5qCH5YeG55qE5paH5pys5qC85byP77yI5qih54mI77yJDQo+Pg0KPj4gRGVhciBDaGFp cnMsDQo+Pg0KPj4gIA0KPj4NCj4+IFdlIGhhdmUgcG9zdGVkIG5ldyBkcmFmdCBvZiBOQVQ2NCBl eHBlcmllbmNlcy4NCj4+DQo+PiBDdXJyZW50IGRyYWZ0IGlzIGEgam9pbmVkIGVmZm9ydCBmcm9t IGZvdXIgb3BlcmF0b3JzIChDaGluYSBNb2JpbGUsIA0KPj4gVC1tb2JpbGUgVVNBLCBDaGluYSBU ZWxlY29tIGFuZCBGcmFuY2UgVGVsZWNvbSkNCj4+DQo+PiB3aG8gaXMgYWN0aXZlbHkgcHJvZ3Jl c3NpbmcgSVB2NiBkZXBsb3ltZW50IGRlcGVuZGluZyBvbiB0aGUgcHJhY3RpY2VzLg0KPj4NCj4+ IFNldmVyYWwgZXhwZXJ0cyBlbmNvdXJhZ2UgdXMgdG8gY29udGludWUgdGhlIHdvcmsgYWZ0ZXIg dGhlaXIga2luZCANCj4+IHJldmlldw0KPj4NCj4+ICANCj4+DQo+PiBGb3Igbm93LCB3ZSBoYXZl IGFkZHJlc3NlZCBhbGwgY29tbWVudHMuDQo+Pg0KPj4gVGhlIGRyYWZ0IGlzIHJlYWR5IGZvciB0 aGUgYWRvcHRpb24uDQo+Pg0KPj4gVGhlIGF1dGhvcnMgd291bGQgbGlrZSB0byBjb25zdWx0IHlv dXIgb3BpbmlvbnMgYW5kIGxvb2sgZm9yd2FyZCB5b3VyIA0KPj4gZ3VpZGFuY2UuDQo+Pg0KPj4g IA0KPj4NCj4+ICANCj4+DQo+PiBNYW55IHRoYW5rcw0KPj4NCj4+ICANCj4+DQo+PiBBdXRob3Jz DQo+Pg0KPj4gIA0KPj4NCj4+ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09DQo+Pg0KPj4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWNoZW4t djZvcHMtbmF0NjQtZXhwZXJpZW5jZS0wMi50eHQNCj4+DQo+PiBoYXMgYmVlbiBzdWNjZXNzZnVs bHkgc3VibWl0dGVkIGJ5IEdhbmcgQ2hlbiBhbmQgcG9zdGVkIHRvIHRoZQ0KPj4NCj4+IElFVEYg cmVwb3NpdG9yeS4NCj4+DQo+PiAgDQo+Pg0KPj4gRmlsZW5hbWU6ICAgICAgICBkcmFmdC1jaGVu LXY2b3BzLW5hdDY0LWV4cGVyaWVuY2UNCj4+DQo+PiBSZXZpc2lvbjogICAgICAgIDAyDQo+Pg0K Pj4gVGl0bGU6ICAgICAgICAgICBOQVQ2NCBPcGVyYXRpb25hbCBFeHBlcmllbmNlcw0KPj4NCj4+ IENyZWF0aW9uIGRhdGU6ICAgMjAxMi0wNy0wNA0KPj4NCj4+IFdHIElEOiAgICAgICAgICAgSW5k aXZpZHVhbCBTdWJtaXNzaW9uDQo+Pg0KPj4gTnVtYmVyIG9mIHBhZ2VzOiAxNQ0KPj4NCj4+IFVS TDogICAgICAgICAgICANCj4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LWNoZW4tdjZvcHMtbmF0NjQtZXhwZXJpZW5jZQ0KPj4gLTAyLnR4dA0KPj4NCj4+IFN0YXR1 czogICAgICAgICANCj4+IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtY2hl bi12Nm9wcy1uYXQ2NC1leHBlcmllbmNlDQo+Pg0KPj4gSHRtbGl6ZWQ6ICAgICAgIA0KPj4gaHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2hlbi12Nm9wcy1uYXQ2NC1leHBlcmllbmNl LTAyDQo+Pg0KPj4gRGlmZjogICAgICAgICAgIA0KPj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL3Jm Y2RpZmY/dXJsMj1kcmFmdC1jaGVuLXY2b3BzLW5hdDY0LWV4cGVyaWVuY2UtDQo+PiAwMg0KPj4N Cj4+ICANCj4+DQo+PiBBYnN0cmFjdDoNCj4+DQo+PiAgICBUaGlzIGRvY3VtZW50IHN1bW1hcml6 ZXMgc29tZSBzdGF0ZWZ1bCBOQVQ2NCBkZXBsb3ltZW50IHNjZW5hcmlvcyANCj4+IGFuZA0KPj4N Cj4+ICAgIG9wZXJhdGlvbmFsIGV4cGVyaWVuY2VzIGZvciBOQVQ2NC1DR04gYW5kIE5BVDY0LUNF Lg0KPj4NCj4+ICANCj4+DQo+PiAgDQo+Pg0KPiANCg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KdjZvcHMgbWFpbGluZyBsaXN0DQp2Nm9wc0BpZXRm Lm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVz IGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZl bnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9y aXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxl eiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVz IHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0 aWJsZXMgZCdhbHRlcmF0aW9uLApGcmFuY2UgVGVsZWNvbSAtIE9yYW5nZSBkZWNsaW5lIHRvdXRl IHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZh bHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250 YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHBy b3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBj b3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVt YWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1l c3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBGcmFu Y2UgVGVsZWNvbSAtIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUg YmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg== From joelja@bogus.com Fri Jul 6 09:08: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 E81F121F871E for ; Fri, 6 Jul 2012 09:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uL0aMzxX2Hpq for ; Fri, 6 Jul 2012 09:08:38 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 1496C21F8655 for ; Fri, 6 Jul 2012 09:08:37 -0700 (PDT) Received: from Joels-MacBook-Pro.local (c-71-193-176-225.hsd1.wa.comcast.net [71.193.176.225]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q66G8qXb019376 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 6 Jul 2012 16:08:52 GMT (envelope-from joelja@bogus.com) Message-ID: <4FF70D8F.5010706@bogus.com> Date: Fri, 06 Jul 2012 09:08:47 -0700 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "Fred Baker (fred)" References: <28DC472D-01D4-4534-97A9-6AE52BE9CC58@tid.es> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 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]); Fri, 06 Jul 2012 16:08:53 +0000 (UTC) Cc: IPv6 Ops WG Subject: Re: [v6ops] Draft on DC migration to IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Jul 2012 16:08:39 -0000 On 6/25/12 05:56 , Fred Baker (fred) wrote: > In addition to getting working group commentary (which has to happen to make it onto the agenda), may I suggest you discuss the draft with my co-chair, who is an IPv6 data center operator? over in 2.1 The translation of IPv6 requests into the internal infrastructure format occurs at the outmost level of the DC Internet connection. This can be typically achieved at the DC gateway routers, that support the appropriate address translation mechanisms for those services required to be accessed through native IPv6 requests. The policies for applying adaptation can range from performing it only to a limited set of specified services to providing a general translation service for all public services. Finer mechanisms, based on address ranges or more sophisticated dynamic policies are also possible, as they are applied by a limited set of control elements. This provides an additional level of control to the usage of IPv6 routable addresses in the DC environment, which can be especially significant at the early deployment stages. This model is also suitable to be applied in an "off-shore" mode by the service provider connecting the DC infrastructure to the Internet, as described in [I-D.sunq-v6ops-contents-transition] Basically no content provider that I know of want to lose the source address associated with the incoming request. so the recommendation here, to the extent that it's a recommendation is really unappealing. o Flow labels can be applied to enhance load-balancing, as described in [I-D.carpenter-v6ops-label-balance]. Incoming IPv6 requests can take advantage of them, and the gateway systems use them as a hint for applying load-balancing mechanisms at the IPv4 internal accesses. The majority of the flow labels today are zero. datacenter operators are not os developers and we don't engage in wishful thinking. > On Jun 25, 2012, at 4:58 PM, Diego R. Lopez wrote: From Tina.Tsou.Zouting@huawei.com Fri Jul 6 09:33: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 34C2421F85D9 for ; Fri, 6 Jul 2012 09:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.506 X-Spam-Level: X-Spam-Status: No, score=-5.506 tagged_above=-999 required=5 tests=[AWL=0.493, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7w4ySJgpXWr for ; Fri, 6 Jul 2012 09:33:00 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0C56721F85D8 for ; Fri, 6 Jul 2012 09:33:00 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHM61503; Fri, 06 Jul 2012 12:33:16 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 6 Jul 2012 09:31:52 -0700 Received: from dfweml513-mbx.china.huawei.com ([169.254.3.208]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.003; Fri, 6 Jul 2012 09:31:54 -0700 From: Tina TSOU To: Philip Matthews Thread-Topic: [v6ops] RE new draft: draft-matthews-v6ops-design-guidelines Thread-Index: AQHNWecJACikpvqhIUyikIXbIivbupccr6kA///GPQY= Date: Fri, 6 Jul 2012 16:31:53 +0000 Message-ID: References: , <3F7BC6E6-10C6-464D-9F9D-3769F432728B@magma.ca> In-Reply-To: <3F7BC6E6-10C6-464D-9F9D-3769F432728B@magma.ca> Accept-Language: en-US, zh-CN 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 X-CFilter-Loop: Reflected Cc: "v6ops@ietf.org" Subject: Re: [v6ops] RE new draft: draft-matthews-v6ops-design-guidelines X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Jul 2012 16:33:01 -0000 Hi Phil, Here is the proposed text for section 8. 8. OSPF 8.1 Enabling OSPFv3 per interface or OSPFv2 per subnet/network:=20 Enabling OSPFv3 on a per-interface basis provides us with the advantage of = enabling/ disabling a particular interface for the OSPF process. When OSPFv= 3 is enabled in the router configuration mode, selecting a particular inter= face by enabling it simplifies the configuration of OSPF, as compared to sp= ecifying the network in OSPFv2. The main advantage of this approach is that the interfaces of the two OSPF = neighbor routers do not have to be in the same subnet for successfully form= ing OSPF neighbors. The interfaces of the two routers participating in the = OSPF process have to be enabled with OSPF on the interface configuration mo= de. Since an interface can have multiple IPv6 addresses, this feature provi= des one with the ability of efficiently using the addresses for routing. Initiating IPv6 on the interface also prevents human errors caused by confi= guring wrong network address or wild card masks. There is no requirement of= calculating the network address of the interface for initiating the OSPF p= rocess on the routers.=20 One of the disadvantages of the per-interface approach is in terms of secur= ity concerns. If one of the interfaces of the router is enabled with OSPFv3= in the interface configuration mode, and a second OSPF speaking router is = connected to the interface, both the routers will be able to form neighbors= , even though the second router may be a rogue router in a different networ= k.OSPFv3 has no authentication field in its header, and thus depends on the= IPv6 authentication header (AH) and Encapsulating Security Payload (ESP). = Thus, from the security point of view, one should be have a clear idea of t= he network design, before enabling the OSPF process on the interface. 8.2 Multiple instances per link in OSPFv3 or multiple OSPF processes in OSP= Fv2=20 OSPFv3 supports multiple OSPF instances per interface. This feature makes i= t possible to add a single interface to be part of more than one area, by h= aving different instance ID. The interface would represent the scenario of = multiple logical interfaces on a single physical interface. Adding multiple= OSPF processes or instances in OSPFv2 adds more overhead and overloads the= router. However, having a single OSPFv3 process and adding instances per i= nterface helps us in maximizing the efficiency of the router, without overl= oading it. The only disadvantage would be some amount of added complexity in managing = the instances, by maintaining a database of the instance IDs for each insta= nce in the header. 8.3 OSPFv3 next-hop addresses: Local or Global addresses? After enabling OSPFv3 for internal routing purposes, the next hop address o= f an OSPFv3 route can be either a: a. Link local address. b. Global address. There are a number of advantages of using link local addresses as next hop = for OSPFv3 routes. First, the link local addresses are automatically config= ured when IPv6 is enabled on the router and do not need any additional conf= iguration. Even if link Local addresses change, (due to the change of a net= work interface card, the MAC address changes), the router would recalculate= its link local address on its own and would advertise it to the other rout= ers in the link.=20 Link local addresses are a representation of layer 2 to layer 3 mapping (EU= I-64). Link local addresses do not propagate outside the scope of a link an= d are more secure. Routers learn link local addresses with the help of Neig= hbor Discover protocol (NDP), thus an additional lookup in the routing tabl= e is not required. It saves processing and memory of the routers. 8.4 Router ID (RID) inconsistency removed in OSPFv3 In the case of OSPFv2, there is inconsistency in the RID of the routers. If= the RID is configured manually in the router configuration mode, it is sel= ected as the RID. Else, the loopback interface with the highest IP address = is selected as the RID. If there are no loopback addresses configured, the = highest IP address of an interface is selected as the RID. This leads to in= consistency in the RID in the OSPF database. This inconsistency is no longe= r present in OSPFv3 and it mandates the use of a 32-bit dotted decimal to b= e configured as RID for each router. Thus, all the routers are recognized b= y a unique RID, which helps in convenient and easier recognition.=20 8.5 Are separate sessions required for IPv4 and IPv6? OSPFv3 is solely used for routing IPv6 traffic and not IPv4 traffic. There = is a separate routing table for OSPFv3 and OSPFv2. If the router is a dual = stack router, both OSPFv2 and OSPFv3 have to be configured separately for e= nabling IPv4 and IPv6 routing respectively. The disadvantage of a single session for both IPv4 and IPv6 is the unnecess= ary delay in the lookup of the much larger routing table, containing both I= Pv4 and IPv6 routes. There is also an added advantage of the separate sessi= on approach in maintaining separate traffic measurements for both kind of t= raffic and thus implementing traffic engineering accordingly.=20 The disadvantage of this process is the need of router memory and resources= in maintaining two routing tables and two processes for both protocols in = the routers. =20 Tina On Jul 6, 2012, at 6:59 AM, "Philip Matthews" wr= ote: > Thanks very much for your helpful comments and your interest in the draft= . >=20 > Some comments inline. >=20 > - Philip >=20 > On 2012-07-04, at 9:14 , Jean-Francois.TremblayING@videotron.com wrote: >=20 >>> A new draft has been posted, at http://tools.ietf.org/html/draft- >>> matthews-v6ops-design-guidelines. Please take a look at it and comment. >>=20 >> Useful, although coming a bit late for most ISPs. Some guidelines also=20 >> apply to enterprises.=20 >>=20 >> A few additionnal comments/ideas:=20 >>=20 >> 3.2 Adressing >> Global vs ULA arguments could also be considered. A disadvantage of ULA= =20 >> is the lack of reverse DNS, unless the reverse zone is added locally.=20 >> Advantage of ULA is simplicity to filter. Possibly less administrativa.= =20 >=20 > My thought is that the draft should focus on design choices about IPv6 (o= r the combination of IPv4 and IPv6) that do not come up with pure IPv4. Oth= erwise, the possible topics to cover in the draft become much bigger, and t= he draft no longer seems to fall within the charter of V6OPS. >=20 > So what I am wondering is: do ULAs provide a design choice that 1918 addr= esses do not provide in IPv4? Right now, I don't see any, but maybe I am m= issing something. I will think about this some more. >=20 >>=20 >> 4.1 Next-hop >> Some early implementations of next hop redundancy protocols supported=20 >> a or b exclusively.=20 >=20 > Perhaps it wasn't clear that section 4.1 is supposed to talk about next-h= op addresses for _static routes_, and not next hops in general. I will tr= y to make this clearer in the next version. >=20 > However, your comment points out that the draft does not currently cover = VRRP. Thanks! I will add that in future revision, as VRRP does seem to h= ave a few interesting design topics. >=20 >>=20 >> 6. iBGP >> Some protocols require a specific combination of AF and transport. For=20 >> example, 6PE/6vPE requires IPv6 and VPNv6 address families over IPv4=20 >> transport. Native IPv6 routes should be over IPv6 transport.=20 >=20 > Yes. > I am trying to figure out how to handle iBGP, as saying something interes= ting about it really depends on what you are trying to do with it. I am st= arting to think that I should not cover it in isolation, but rather in some= larger context (e.g., in the context of talking about 6PE or 6VPE)=20 >=20 >>=20 >> 7. ISIS >> Multi-topology vs single topology >> Some implementations of ISIS have issues running IPv6 with a single=20 >> topology. Multi-topology is recommended, even if IPv4 is not carried in= =20 >> LSPs.=20 >=20 > I agree. I will cover this in a future revision. >=20 >>=20 >> /JF >>=20 >>=20 >> _______________________________________________ >> 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 brian.e.carpenter@gmail.com Fri Jul 6 09:59: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 AE56321F8712 for ; Fri, 6 Jul 2012 09:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.788 X-Spam-Level: X-Spam-Status: No, score=-100.788 tagged_above=-999 required=5 tests=[AWL=0.303, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iV9dECw9Rc0i for ; Fri, 6 Jul 2012 09:59:52 -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 EDDB821F8707 for ; Fri, 6 Jul 2012 09:59:51 -0700 (PDT) Received: by eaaq13 with SMTP id q13so3985500eaa.31 for ; Fri, 06 Jul 2012 10:00:08 -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=IqnJfzGASTWy4dwSMPWOeEtvcd5Yplvih1Dz2AyTMtg=; b=WPyoC7r1rAu+Xura0rK0scxdv09B8ByjD4nT171ZzHJS0YEXUVJNQNm9a1N8Z0SnYq 3OKSI1+7qM4HNMccOGGCTj+vvKOmpW9g1j9aSH2cQvyecbLHlSyMyeEFhxBejPtSyJmC SKWuYLta3Wq1vXN4nxrN8G1ufroKIW+vDayPMLaDrNHE7DJqnFh/miwg9uMQefuOzJqU KTEdi7Eyt77WjJdmRqGIuUYaYZtmcCUdgQtIhbcGLb4QQjUjniLHydeg2zDriwgYVwbe gnJ7Poa35QmrM428NJPJxXoFD8MyagIiY5vlKDnvkHgOpmEyNgC8fHqDf/DLf2jSpykN f6iA== Received: by 10.14.119.202 with SMTP id n50mr7326717eeh.33.1341594008123; Fri, 06 Jul 2012 10:00:08 -0700 (PDT) Received: from [192.168.1.67] (host-2-102-219-21.as13285.net. [2.102.219.21]) by mx.google.com with ESMTPS id p41sm72996810eef.5.2012.07.06.10.00.06 (version=SSLv3 cipher=OTHER); Fri, 06 Jul 2012 10:00:06 -0700 (PDT) Message-ID: <4FF71993.7090301@gmail.com> Date: Fri, 06 Jul 2012 18:00:03 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Jean-Francois.TremblayING@videotron.com References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org, philip_matthews@magma.ca Subject: Re: [v6ops] RE new draft: draft-matthews-v6ops-design-guidelines X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 06 Jul 2012 16:59:52 -0000 On 2012-07-06 16:53, Jean-Francois.TremblayING@videotron.com wrote: > Philip Matthews a =C3=A9crit sur 06/07/2012 = 08:58:38=20 > AM : >=20 >>> 3.2 Adressing >>> Global vs ULA arguments could also be considered. A disadvantage of=20 > ULA=20 >>> is the lack of reverse DNS, unless the reverse zone is added locally.= =20 >>> Advantage of ULA is simplicity to filter. Possibly less=20 > administrativa.=20 >> My thought is that the draft should focus on design choices about=20 >> IPv6 (or the combination of IPv4 and IPv6) that do not come up with=20 >> pure IPv4. Otherwise, the possible topics to cover in the draft=20 >> become much bigger, and the draft no longer seems to fall within the >> charter of V6OPS. >> >> So what I am wondering is: do ULAs provide a design choice that 1918 >> addresses do not provide in IPv4? Right now, I don't see any, but=20 >> maybe I am missing something. I will think about this some more. > =20 > Not sure I'm following your reasoning here. Choosing to number part=20 > of your network with global vs ULA adressing is an IPv6 design choice. The design *advantage* of ULAs is that if you merge two networks using them, the addressing scheme still works. If you merge two Net 10s, stuff breaks. Merge =3D physically merge, or connect temporarily or permanently with VPNs. Brian From touch@isi.edu Fri Jul 6 15:46: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 52A4421F85C4; Fri, 6 Jul 2012 15:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.234 X-Spam-Level: X-Spam-Status: No, score=-103.234 tagged_above=-999 required=5 tests=[AWL=-1.235, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vhLsdpb40MqM; Fri, 6 Jul 2012 15:46:55 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id D894621F85C0; Fri, 6 Jul 2012 15:46:55 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id q66MkF3u005185 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 6 Jul 2012 15:46:15 -0700 (PDT) Message-ID: <4FF76AB7.6040008@isi.edu> Date: Fri, 06 Jul 2012 15:46:15 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: internet-drafts@ietf.org References: <20120703034522.1902.94338.idtracker@ietfa.amsl.com> In-Reply-To: <20120703034522.1902.94338.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: v6ops@ietf.org, i-d-announce@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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: Fri, 06 Jul 2012 22:46:56 -0000 This doc relies on RFC 6145, which has a few key problems: 1. it sets IPv4 ID=0 when IPv6 lacks a frag header that will hopefully be possible after ipv4-id-update is final (if it does proceed as intended) but isn't true now 2. copying the low 16 bits of the IPv6 ID field to the IPv4 ID field is invalid that field might not follow the ID uniqueness criteria of IPv4 3. the system assumes IPv4 can reassemble 1280 byte packets but only 576 can be assumed I've pointed these out elsewhere, but they need to be resolved before any doc that relies on it can proceed, IMO. Joe On 7/2/2012 8:45 PM, 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 : 464XLAT: Combination of Stateful and Stateless Translation > Author(s) : Masataka Mawatari > Masanobu Kawashima > Cameron Byrne > Filename : draft-ietf-v6ops-464xlat-05.txt > Pages : 19 > Date : 2012-07-02 > > 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-05 > > A diff from previous version is available at: > http://tools.ietf.org/rfcdiff?url2=draft-ietf-v6ops-464xlat-05 > > > 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 xing@cernet.edu.cn Fri Jul 6 18:41: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 3D50E11E80B7 for ; Fri, 6 Jul 2012 18:41:27 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTsjvA2v4WaR for ; Fri, 6 Jul 2012 18:41:26 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with ESMTP id 23C6011E808C for ; Fri, 6 Jul 2012 18:41:25 -0700 (PDT) Received: from [127.0.0.1] (unknown [125.34.43.57]) by centos (Coremail) with SMTP id AQAAf3DLNgOukvdPpgwEAA--.13751S5; Sat, 07 Jul 2012 09:36:47 +0800 (CST) Message-ID: <4FF793D6.9070904@cernet.edu.cn> Date: Sat, 07 Jul 2012 09:41:42 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: v6ops@ietf.org References: <20120703094549.14140.23639.idtracker@ietfa.amsl.com> In-Reply-To: <20120703094549.14140.23639.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CM-TRANSID: AQAAf3DLNgOukvdPpgwEAA--.13751S5 X-Coremail-Antispam: 1UD129KBjvJXoW7Zryxtr1fXryfJrWruFW8Crg_yoW8AFWfpa yDG3y5Kw18Jw18G3ykXr1UZw1rZr98W3yDAFsxtrnIka98J3Z2yr1Fkry5trWDJFyfJws7 tr4Uuw1UuFs3trJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUqE14x267AKxVW8JVW5JwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2ocxC64kIII0Yj41l84ACjcxK6xIIjxv20xvE14 v26r1j6r1xM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26r1j6r4UM28EF7xvwVC2z280aVAF wI0_Gr0_Cr1l84ACjcxK6I8E87Iv6xkF7I0E14v26r4j6r4UJwAS0I0E0xvYzxvE52x082 IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWUJVWUGwAv 7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcVAKI48JM4x0x7 Aq67IIx4CEVc8vx2IErcIFxwCY02Avz4vE14v_KwCF04k20xvY0x0EwIxGrwC20s026c02 F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jrv_JF 1lIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7Cj xVAFwI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6rWUJVWrZr1UMIIF0xvEx4A2jsIE14 v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Gr0_Gr1UYxBIdaVFxhVjvjDU0xZFpf9x 0JUHpB-UUUUU= X-CM-SenderInfo: p0lqwqxfhu0vvwohv3gofq/ Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ivi-icmp-address-02.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, 07 Jul 2012 01:41:27 -0000 Hi, All, We have submitted an updated version of draft-ietf-v6ops-ivi-icmp-address. This version removed the well-known IPv4 prefix and focused on the use of public IPv4 address (interface, loopback, or even a pool shared by several stateless translators) + RFC5837 and looking for the WG review. Thank you very much! xing internet-drafts@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 : 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-02.txt > Pages : 6 > Date : 2012-07-03 > > Abstract: > A stateless IPv4/IPv6 translator may receive ICMPv6 packets > containing non IPv4-translatable addresses as the source that should > be passed across the translator as an ICMP packet directed to the > IPv4-translatable destination. This document presents > recommendations for source address translation in ICMPv6 headers for > 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-02 > > A diff from previous version is available at: > http://tools.ietf.org/rfcdiff?url2=draft-ietf-v6ops-ivi-icmp-address-02 > > > 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 philip_matthews@magma.ca Sat Jul 7 13:08: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 DB54621F8575 for ; Sat, 7 Jul 2012 13:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.53 X-Spam-Level: X-Spam-Status: No, score=-1.53 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-Wy+2OUIAt1 for ; Sat, 7 Jul 2012 13:08:23 -0700 (PDT) Received: from mail-02.primus.ca (mail16.primus.ca [216.254.141.183]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB3521F8565 for ; Sat, 7 Jul 2012 13:08:22 -0700 (PDT) Received: from [74.198.165.15] (helo=[172.20.10.2]) by mail-02.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1SnbJ1-0002nZ-1p; Sat, 07 Jul 2012 16:08:42 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Philip Matthews In-Reply-To: <4FF71993.7090301@gmail.com> Date: Sat, 7 Jul 2012 16:08:29 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9405C4CB-3DEE-40CA-8FEC-E32B3CA61F76@magma.ca> References: <4FF71993.7090301@gmail.com> To: Brian E Carpenter , Jean-Francois.TremblayING@videotron.com X-Mailer: Apple Mail (2.1084) X-Authenticated: philip_matthews - ([172.20.10.2]) [74.198.165.15] Cc: IETF v6ops list Subject: Re: [v6ops] RE new draft: draft-matthews-v6ops-design-guidelines X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 Jul 2012 20:08:24 -0000 Brian and JF: Good point. Forgot about this. Not quite sure yet how I am going to add this. The section was dealing = with just p2p links, and this observation applies to larger networks. = Still it should be mentioned somehow. - Philip On 2012-07-06, at 13:00 , Brian E Carpenter wrote: > On 2012-07-06 16:53, Jean-Francois.TremblayING@videotron.com wrote: >> Philip Matthews a =E9crit sur 06/07/2012 = 08:58:38=20 >> AM : >>=20 >>>> 3.2 Adressing >>>> Global vs ULA arguments could also be considered. A disadvantage of=20= >> ULA=20 >>>> is the lack of reverse DNS, unless the reverse zone is added = locally.=20 >>>> Advantage of ULA is simplicity to filter. Possibly less=20 >> administrativa.=20 >>> My thought is that the draft should focus on design choices about=20 >>> IPv6 (or the combination of IPv4 and IPv6) that do not come up with=20= >>> pure IPv4. Otherwise, the possible topics to cover in the draft=20 >>> become much bigger, and the draft no longer seems to fall within the >>> charter of V6OPS. >>>=20 >>> So what I am wondering is: do ULAs provide a design choice that 1918 >>> addresses do not provide in IPv4? Right now, I don't see any, but=20= >>> maybe I am missing something. I will think about this some more. >>=20 >> Not sure I'm following your reasoning here. Choosing to number part=20= >> of your network with global vs ULA adressing is an IPv6 design = choice. >=20 > The design *advantage* of ULAs is that if you merge two networks > using them, the addressing scheme still works. If you merge two > Net 10s, stuff breaks. >=20 > Merge =3D physically merge, or connect temporarily or permanently > with VPNs. >=20 > Brian >=20 >=20 From sunjp@sttri.com.cn Mon Jul 2 21:57: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 E51EF21F870F for ; Mon, 2 Jul 2012 21:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.01 X-Spam-Level: *** X-Spam-Status: No, score=3.01 tagged_above=-999 required=5 tests=[AWL=0.742, BAYES_50=0.001, J_CHICKENPOX_13=0.6, SARE_RECV_IP_218078=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eCQ4CCLO1goW for ; Mon, 2 Jul 2012 21:56:59 -0700 (PDT) Received: from corp.21cn.com (corp.forptr.21cn.com [121.14.129.36]) by ietfa.amsl.com (Postfix) with ESMTP id E68C321F8713 for ; Mon, 2 Jul 2012 21:56:58 -0700 (PDT) HMM_SOURCE_IP: 10.27.101.10:40199.111449767 HMM_ATTACHE_NUM: 0000 HMM_SOURCE_TYPE: SMTP Received: from sunTHINK (unknown [10.27.101.10]) by corp.21cn.com (HERMES) with ESMTP id A195045C02D; Tue, 3 Jul 2012 12:56:57 +0800 (CST) Received: from sunTHINK ([218.80.215.132]) by 21CN-entas10(MEDUSA 10.27.101.10) with ESMTP id 1341291417.25378 for fred@cisco.com ; Tue Jul 3 12:57:04 2012 0/X-Total-Score: 0: 2/X-Total-Score: 0: X-FILTER-SCORE: to=<8793868561848a9484904f84908e758a8f824f759490964f7b9096958a8f886189968298868a4f84908e9757909194618a8695874f9093889b89828f88808b9961949595938a4f84908e4f848f>, score=<1341291424BxBBiB7xiT2LRbtBBBBB7BjMjjpjHMpcWQAZGjjjjjHj> From: To: Date: Tue, 3 Jul 2012 12:56:59 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AQHNWCteNCRYj+zU4EuHibb6lobgm5cW0CcggAALGuCAACM+gA== X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7601.17609 Message-Id: <20120703045657.A195045C02D@corp.21cn.com> X-Mailman-Approved-At: Sat, 07 Jul 2012 16:48:10 -0700 Cc: v6ops@ietf.org, =?gb2312?B?J9XFvezQwic=?= Subject: Re: [v6ops] Some questions on draft-zhang-v6ops-ipv6oa-iwf X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 Jul 2012 05:23:13 -0000 intent for draft-zhang-v6ops-ipv6oa-iwf : > > > 1) Please provide a succinct problem statement for your draft. What > problem/issue is this draft discussing? What operational problems does > the proposal address in real life networks? > A: Currently, IPoA encapsulation is migrated to an Ethernet > aggregation network in [TR101]. This draft proposes a solution to > provide a smooth communication between legacy ATM/SDH and IPv6 over > Ethernet when network migrates to IPv6. > > 2) Where does this draft or presentation fits into v6ops' current > charter (http://datatracker.ietf.org/wg/v6ops/charter/)? Citing > specific a > section(s) of the charter is preferable. > A: In v6ops charter, the first goal is " Solicit input from network > operators and users to identify operational issues with the IPv4/IPv6 > Internet, and determine solutions or workarounds to those issues. " > This draft fits into this one. > > 3) Who is this draft's audience? > A: Those operators whose networks contain both ATM/SDH and IPv6 over > Ethernet, such as China Telecom, Vodafone, etc. > > 4) Have any operators expressed interest in this draft or its problem > space, either via review or other discussion? > A: China Telecom expressed great interests. As far as we know, > Vodafone might also interest. > > 5) Is this draft pursuing discussion in any other WGs? If so, please > list them here, along with rationale for the interaction with multiple > WGs in parallel. > A: We firstly pursue discussion in v6ops. If there is any other WG you > think related to this work, we can also try. > > 6) Is any protocol work being recommended in the draft? > A: No. This draft only focus on interworking function. > > > > > -----Original Message----- > From: fred@cisco.com [mailto:fred@cisco.com] > Sent: Saturday, June 30, 2012 8:45 PM > To: draft-zhang-v6ops-ipv6oa-iwf@tools.ietf.org > Cc: v6ops-chairs@tools.ietf.org > Subject: Some questions on draft-zhang-v6ops-ipv6oa-iwf > > Let me ask some questions. This is not intended to put you off or > offend, but to help the chairs in understanding where the draft fits > in the big scheme of things. > > 1) Please provide a succinct problem statement for your draft. What > problem/issue is this draft discussing? What operational problems does > the proposal address in real life networks? > > 2) Where does this draft or presentation fits into v6ops' current > charter (http://datatracker.ietf.org/wg/v6ops/charter/)? Citing > specific a > section(s) of the charter is preferable. > > 3) Who is this draft's audience? > > 4) Have any operators expressed interest in this draft or its problem > space, either via review or other discussion? > > 5) Is this draft pursuing discussion in any other WGs? If so, please > list them here, along with rationale for the interaction with multiple > WGs in parallel. > > 6) Is any protocol work being recommended in the draft? > > the criteria the WG asked me to apply for new work or presentation > slots > are: > - recent or recently updated draft > - within charter > - results in constructive discussion on the mailing list > > I need for you to provoke discussion on the list. You may respond to > my opening email to do so if it's helpful. From carlw@mcsr-labs.org Sun Jul 8 17:57: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 722B121F875D for ; Sun, 8 Jul 2012 17:57: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o0qZnfJpL1Nb for ; Sun, 8 Jul 2012 17:57:07 -0700 (PDT) Received: from mail149c38.carrierzone.com (mail149c38.carrierzone.com [66.175.56.179]) by ietfa.amsl.com (Postfix) with ESMTP id 6060E21F85F1 for ; Sun, 8 Jul 2012 17:57:04 -0700 (PDT) X-Authenticated-User: carlw.mcsr-labs.org Received: from [10.0.1.3] (c-71-230-119-210.hsd1.pa.comcast.net [71.230.119.210]) (authenticated bits=0) by mail149c38.carrierzone.com (8.13.6/8.13.1) with ESMTP id q690vNip014042 for ; Mon, 9 Jul 2012 00:57:25 +0000 User-Agent: Microsoft-MacOutlook/14.13.0.110805 Date: Sun, 08 Jul 2012 20:57:21 -0400 From: Carl Williams To: Message-ID: Thread-Topic: Call for Adoption, was Re: New draft waiting for adoption: draft-chen-v6ops-nat64-experience-02 Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-CSC: 0 X-CHA: v=1.1 cv=mwlFAaDA+ikO7kMzgKjtEAO1h4y7OmPpnUzlklLDj+M= c=1 sm=1 a=W-hxRJO8TvsA:10 a=LzeqQKIxupAA:10 a=Gzqcop6RMF0A:10 a=kj9zAlcOel0A:10 a=82lcX82o5UxRLc1vpnM4fA==:17 a=xcTfSnc4AAAA:8 a=48vgC7mUAAAA:8 a=AUd_NHdVAAAA:8 a=qeW2lMnuL6OgHc_9p0oA:9 a=CjuIK1q_8ugA:10 a=d5F51druI-gA:10 a=kkUMZHjH4KkA:10 a=rpjHd656CRUA:10 a=yiKzFwc1bccgUr6U:21 a=qW0I7QMPoMfR9FhT:21 a=82lcX82o5UxRLc1vpnM4fA==:117 X-CTCH-Spam: Unknown X-CTCH-RefID: str=0001.0A010206.4FFA2C76.0007, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 Subject: Re: [v6ops] Call for Adoption, was Re: New draft waiting for adoption: draft-chen-v6ops-nat64-experience-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 09 Jul 2012 00:57:08 -0000 I support this document as a working group document as it represents the insights of experiences on NAT64 for publication as an information RFC. Thanks. Carl ________________________________________ * From: Joel jaeggli > * To: IPv6 Ops WG > * Date: Fri, 06 Jul 2012 08:42:51 -0700 * In-reply-to: <1DFE8BF4-885E-4F2F-AA1B-4FC1658BA688 at cisco.com > * References: <0B2FA58F71A34C199446380DA654FB07 at LENOVO1E4798BB > <1DFE8BF4-885E-4F2F-AA1B-4FC1658BA688 at cisco.com > ________________________________________ The following message commences a 1 week call for opinions on the adoption of draft-chen-v6ops-nat64-experience-02 http://tools.ietf.org/html/draft-chen-v6ops-nat64-experience-02 Friday 7/13/2012 is the deadline for this particular call. Thank you. joel >> >> Dear Chairs, >> >> >> >> We have posted new draft of NAT64 experiences. >> >> Current draft is a joined effort from four operators (China Mobile, >> T-mobile USA, China Telecom and France Telecom) >> >> who is actively progressing IPv6 deployment depending on the practices. >> >> Several experts encourage us to continue the work after their kind >>review >> >> >> >> For now, we have addressed all comments. >> >> The draft is ready for the adoption. >> >> The authors would like to consult your opinions and look forward your >> guidance. >> >> >> >> >> >> Many thanks >> >> >> >> Authors >> >> >> >> ===================================================== >> >> A new version of I-D, draft-chen-v6ops-nat64-experience-02.txt >> >> has been successfully submitted by Gang Chen and posted to the >> >> IETF repository. >> >> >> >> Filename: draft-chen-v6ops-nat64-experience >> >> Revision: 02 >> >> Title: NAT64 Operational Experiences >> >> Creation date: 2012-07-04 >> >> WG ID: Individual Submission >> >> Number of pages: 15 >> >> URL: >> >>http://www.ietf.org/internet-drafts/draft-chen-v6ops-nat64-experience-02. >>txt >> >> Status: >> http://datatracker.ietf.org/doc/draft-chen-v6ops-nat64-experience >> >> Htmlized: >> http://tools.ietf.org/html/draft-chen-v6ops-nat64-experience-02 >> >> Diff: >> http://tools.ietf.org/rfcdiff?url2=draft-chen-v6ops-nat64-experience-02 >> >> >> >> Abstract: >> >> This document summarizes some stateful NAT64 deployment scenarios and >> >> operational experiences for NAT64-CGN and NAT64-CE. >> >> >> >> >> > From mawatari@jpix.ad.jp Sun Jul 8 18:39: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 7FA6121F87DF for ; Sun, 8 Jul 2012 18:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YXkx-mYUg-VU for ; Sun, 8 Jul 2012 18:39:21 -0700 (PDT) Received: from mx20.jpix.ad.jp (mx20.jpix.ad.jp [210.171.225.78]) by ietfa.amsl.com (Postfix) with ESMTP id CC73321F87DD for ; Sun, 8 Jul 2012 18:39:20 -0700 (PDT) Received: from [192.168.0.230] (64es-v4pool4.jpix.ad.jp [202.90.12.4]) by mx20.jpix.ad.jp (Postfix) with ESMTP id 82FF6FC021 for ; Mon, 9 Jul 2012 10:39:39 +0900 (JST) Date: Mon, 09 Jul 2012 10:39:38 +0900 From: MAWATARI Masataka To: v6ops@ietf.org In-Reply-To: <4FF76AB7.6040008@isi.edu> References: <20120703034522.1902.94338.idtracker@ietfa.amsl.com> <4FF76AB7.6040008@isi.edu> Message-Id: <20120709103937.312D.8FE1F57E@jpix.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.57.03 [ja] Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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: Mon, 09 Jul 2012 01:39:21 -0000 Dear Joe-san, Thank you very much for your comments and information about ipv4-id-update. Translation does not have full-transparency and then 464XLAT includes issues based on that as you said. 464XLAT is a method that provide limited IPv4 connectivity using translation. We authors write that in the section of abstract. Kind Regards, Masataka MAWATARI * On Fri, 06 Jul 2012 15:46:15 -0700 * Joe Touch wrote: > This doc relies on RFC 6145, which has a few key problems: > > 1. it sets IPv4 ID=0 when IPv6 lacks a frag header > > that will hopefully be possible after ipv4-id-update is final > (if it does proceed as intended) but isn't true now > > 2. copying the low 16 bits of the IPv6 ID field to the IPv4 ID field is > invalid > that field might not follow the ID uniqueness criteria of IPv4 > > 3. the system assumes IPv4 can reassemble 1280 byte packets > but only 576 can be assumed > > I've pointed these out elsewhere, but they need to be resolved before > any doc that relies on it can proceed, IMO. > > Joe > > On 7/2/2012 8:45 PM, 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 : 464XLAT: Combination of Stateful and Stateless Translation > > Author(s) : Masataka Mawatari > > Masanobu Kawashima > > Cameron Byrne > > Filename : draft-ietf-v6ops-464xlat-05.txt > > Pages : 19 > > Date : 2012-07-02 > > > > 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-05 > > > > A diff from previous version is available at: > > http://tools.ietf.org/rfcdiff?url2=draft-ietf-v6ops-464xlat-05 > > > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ From victor.kuarsingh@gmail.com Sun Jul 8 21: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 620B221F87F9 for ; Sun, 8 Jul 2012 21:40:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.603 X-Spam-Level: X-Spam-Status: No, score=-1.603 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HzSZt7VjpPp0 for ; Sun, 8 Jul 2012 21:40:46 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id AC11E21F8805 for ; Sun, 8 Jul 2012 21:40:45 -0700 (PDT) Received: by yhq56 with SMTP id 56so12213694yhq.31 for ; Sun, 08 Jul 2012 21:41:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=i4j8C35UiwfLzVkYAystIJINcbxXgdd4727KH5xV5mU=; b=WcI27UB2Jubq6Oyaj2nL3myqnQvWIp7XotLpFfrK5DwPN9zHN58EJ47AKgphEp8Sx5 J1T4D6D04ySGb6BT8fZiANmLzMk12zby+R7XYEe0SBZ9arCiiwfaWUWGuJXuhkTQZIaM CyvRRbuOUn91NdwVKlvx7JPQx6JKHqglkdoWhwkj0REZUQCt7b8DxquRrF35e9ryvOiu +Ot2nSJOaCzOZK437MiGOoM2gCasvAY2sfJiJ9AeNCdlHr7nX5IvhHwakJoKX5MnZsVM XWHF5ckBdFk5FcoDF12sXEXxXyLIO7F+6q5aMNEKVmtJNDGjIHtWCYKPqHY36Degk2ys 56mA== Received: by 10.42.38.83 with SMTP id b19mr19450801ice.10.1341808869044; Sun, 08 Jul 2012 21:41:09 -0700 (PDT) Received: from [192.168.100.200] ([67.224.83.162]) by mx.google.com with ESMTPS id s4sm8304354igb.1.2012.07.08.21.41.06 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 08 Jul 2012 21:41:08 -0700 (PDT) References: In-Reply-To: Mime-Version: 1.0 (iPad Mail 8J2) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPad Mail (8J2) From: Victor Kuarsingh Date: Mon, 9 Jul 2012 00:41:29 -0400 To: Carl Williams Cc: "" Subject: Re: [v6ops] Call for Adoption, was Re: New draft waiting for adoption: draft-chen-v6ops-nat64-experience-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 09 Jul 2012 04:40:47 -0000 I also would support this as a WG document. Real world experience is import= ant to document for technologies like NAT64. Regards, Victor K Sent from my iPad On 2012-07-08, at 8:57 PM, Carl Williams wrote: >=20 >=20 > I support this document as a working group document as it represents the > insights of experiences on NAT64 for publication as an information RFC. >=20 > Thanks. >=20 > Carl >=20 > ________________________________________ >=20 > * From: Joel jaeggli > > * To: IPv6 Ops WG > > * Date: Fri, 06 Jul 2012 08:42:51 -0700 > * In-reply-to: <1DFE8BF4-885E-4F2F-AA1B-4FC1658BA688 at cisco.com > > > * References: <0B2FA58F71A34C199446380DA654FB07 at LENOVO1E4798BB > > > <1DFE8BF4-885E-4F2F-AA1B-4FC1658BA688 at cisco.com > > >=20 > ________________________________________ > The following message commences a 1 week call for opinions on the > adoption of draft-chen-v6ops-nat64-experience-02 >=20 > http://tools.ietf.org/html/draft-chen-v6ops-nat64-experience-02 >=20 > Friday 7/13/2012 is the deadline for this particular call. >=20 > Thank you. > joel >=20 >=20 >>>=20 >>> Dear Chairs, >>>=20 >>>=20 >>>=20 >>> We have posted new draft of NAT64 experiences. >>>=20 >>> Current draft is a joined effort from four operators (China Mobile, >>> T-mobile USA, China Telecom and France Telecom) >>>=20 >>> who is actively progressing IPv6 deployment depending on the practices. >>>=20 >>> Several experts encourage us to continue the work after their kind >>> review >>>=20 >>>=20 >>>=20 >>> For now, we have addressed all comments. >>>=20 >>> The draft is ready for the adoption. >>>=20 >>> The authors would like to consult your opinions and look forward your >>> guidance. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Many thanks >>>=20 >>>=20 >>>=20 >>> Authors >>>=20 >>>=20 >>>=20 >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>=20 >>> A new version of I-D, draft-chen-v6ops-nat64-experience-02.txt >>>=20 >>> has been successfully submitted by Gang Chen and posted to the >>>=20 >>> IETF repository. >>>=20 >>>=20 >>>=20 >>> Filename: draft-chen-v6ops-nat64-experience >>>=20 >>> Revision: 02 >>>=20 >>> Title: NAT64 Operational Experiences >>>=20 >>> Creation date: 2012-07-04 >>>=20 >>> WG ID: Individual Submission >>>=20 >>> Number of pages: 15 >>>=20 >>> URL: =20 >>>=20 >>> http://www.ietf.org/internet-drafts/draft-chen-v6ops-nat64-experience-02= . >>> txt >>>=20 >>> Status: =20 >>> http://datatracker.ietf.org/doc/draft-chen-v6ops-nat64-experience >>>=20 >>> Htmlized: =20 >>> http://tools.ietf.org/html/draft-chen-v6ops-nat64-experience-02 >>>=20 >>> Diff: =20 >>> http://tools.ietf.org/rfcdiff?url2=3Ddraft-chen-v6ops-nat64-experience-0= 2 >>>=20 >>>=20 >>>=20 >>> Abstract: >>>=20 >>> This document summarizes some stateful NAT64 deployment scenarios and >>>=20 >>> operational experiences for NAT64-CGN and NAT64-CE. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From Tina.Tsou.Zouting@huawei.com Sun Jul 8 22:06: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 7DED721F8809 for ; Sun, 8 Jul 2012 22:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.52 X-Spam-Level: X-Spam-Status: No, score=-5.52 tagged_above=-999 required=5 tests=[AWL=0.479, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m+3miB+yMGab for ; Sun, 8 Jul 2012 22:06:25 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 701CE21F8804 for ; Sun, 8 Jul 2012 22:06:24 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHO90732; Mon, 09 Jul 2012 01:06:48 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 8 Jul 2012 22:05:44 -0700 Received: from dfweml513-mbx.china.huawei.com ([169.254.3.208]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.003; Sun, 8 Jul 2012 22:05:45 -0700 From: Tina TSOU To: Victor Kuarsingh Thread-Topic: [v6ops] Call for Adoption, was Re: New draft waiting for adoption: draft-chen-v6ops-nat64-experience-02 Thread-Index: AQHNXY0fq2nCfPpT9UOX67DoT9338pcgZeNE Date: Mon, 9 Jul 2012 05:05:44 +0000 Message-ID: <48EBEB84-261C-49A1-973F-086EC346FD76@huawei.com> References: , In-Reply-To: Accept-Language: en-US, zh-CN 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 X-CFilter-Loop: Reflected Cc: "" Subject: Re: [v6ops] Call for Adoption, was Re: New draft waiting for adoption: draft-chen-v6ops-nat64-experience-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 09 Jul 2012 05:06:26 -0000 I support the adoption of this document. Tina On Jul 8, 2012, at 9:41 PM, "Victor Kuarsingh" = wrote: > I also would support this as a WG document. Real world experience is imp= ortant to document for technologies like NAT64. >=20 > Regards, >=20 > Victor K >=20 >=20 >=20 > Sent from my iPad >=20 > On 2012-07-08, at 8:57 PM, Carl Williams wrote: >=20 >>=20 >>=20 >> I support this document as a working group document as it represents the >> insights of experiences on NAT64 for publication as an information RFC. >>=20 >> Thanks. >>=20 >> Carl >>=20 >> ________________________________________ >>=20 >> * From: Joel jaeggli > >> * To: IPv6 Ops WG > >> * Date: Fri, 06 Jul 2012 08:42:51 -0700 >> * In-reply-to: <1DFE8BF4-885E-4F2F-AA1B-4FC1658BA688 at cisco.com >> > >> * References: <0B2FA58F71A34C199446380DA654FB07 at LENOVO1E4798BB >> > >> <1DFE8BF4-885E-4F2F-AA1B-4FC1658BA688 at cisco.com >> > >>=20 >> ________________________________________ >> The following message commences a 1 week call for opinions on the >> adoption of draft-chen-v6ops-nat64-experience-02 >>=20 >> http://tools.ietf.org/html/draft-chen-v6ops-nat64-experience-02 >>=20 >> Friday 7/13/2012 is the deadline for this particular call. >>=20 >> Thank you. >> joel >>=20 >>=20 >>>>=20 >>>> Dear Chairs, >>>>=20 >>>>=20 >>>>=20 >>>> We have posted new draft of NAT64 experiences. >>>>=20 >>>> Current draft is a joined effort from four operators (China Mobile, >>>> T-mobile USA, China Telecom and France Telecom) >>>>=20 >>>> who is actively progressing IPv6 deployment depending on the practices= . >>>>=20 >>>> Several experts encourage us to continue the work after their kind >>>> review >>>>=20 >>>>=20 >>>>=20 >>>> For now, we have addressed all comments. >>>>=20 >>>> The draft is ready for the adoption. >>>>=20 >>>> The authors would like to consult your opinions and look forward your >>>> guidance. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> Many thanks >>>>=20 >>>>=20 >>>>=20 >>>> Authors >>>>=20 >>>>=20 >>>>=20 >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >>>>=20 >>>> A new version of I-D, draft-chen-v6ops-nat64-experience-02.txt >>>>=20 >>>> has been successfully submitted by Gang Chen and posted to the >>>>=20 >>>> IETF repository. >>>>=20 >>>>=20 >>>>=20 >>>> Filename: draft-chen-v6ops-nat64-experience >>>>=20 >>>> Revision: 02 >>>>=20 >>>> Title: NAT64 Operational Experiences >>>>=20 >>>> Creation date: 2012-07-04 >>>>=20 >>>> WG ID: Individual Submission >>>>=20 >>>> Number of pages: 15 >>>>=20 >>>> URL: =20 >>>>=20 >>>> http://www.ietf.org/internet-drafts/draft-chen-v6ops-nat64-experience-= 02. >>>> txt >>>>=20 >>>> Status: =20 >>>> http://datatracker.ietf.org/doc/draft-chen-v6ops-nat64-experience >>>>=20 >>>> Htmlized: =20 >>>> http://tools.ietf.org/html/draft-chen-v6ops-nat64-experience-02 >>>>=20 >>>> Diff: =20 >>>> http://tools.ietf.org/rfcdiff?url2=3Ddraft-chen-v6ops-nat64-experience= -02 >>>>=20 >>>>=20 >>>>=20 >>>> Abstract: >>>>=20 >>>> This document summarizes some stateful NAT64 deployment scenarios and >>>>=20 >>>> operational experiences for NAT64-CGN and NAT64-CE. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>=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 randy@psg.com Sun Jul 8 23:18: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 93D0721F8687 for ; Sun, 8 Jul 2012 23:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id exhRkySOa32T for ; Sun, 8 Jul 2012 23:18:04 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 3E39221F8668 for ; Sun, 8 Jul 2012 23:18:04 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1So7Id-000HGV-SC; Mon, 09 Jul 2012 06:18:24 +0000 Date: Mon, 09 Jul 2012 15:18:22 +0900 Message-ID: From: Randy Bush To: Brian E Carpenter In-Reply-To: <4FF71993.7090301@gmail.com> References: <4FF71993.7090301@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: v6ops@ietf.org, philip_matthews@magma.ca Subject: Re: [v6ops] RE new draft: draft-matthews-v6ops-design-guidelines X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 09 Jul 2012 06:18:04 -0000 > The design *advantage* of ULAs is that if you merge two networks > using them, the addressing scheme still works. If you merge two > Net 10s, stuff breaks. ^ might the design advantage of using global space is that it will always work. randy From kawashimam@vx.jp.nec.com Sun Jul 8 23:46: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 E297011E8079 for ; Sun, 8 Jul 2012 23:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[AWL=1.650, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rOcCDYbjFlcx for ; Sun, 8 Jul 2012 23:46:00 -0700 (PDT) Received: from tyo202.gate.nec.co.jp (TYO202.gate.nec.co.jp [202.32.8.206]) by ietfa.amsl.com (Postfix) with ESMTP id C6F3921F862A for ; Sun, 8 Jul 2012 23:45:59 -0700 (PDT) Received: from mailgate4.nec.co.jp ([10.7.69.184]) by tyo202.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id q696kKJT005713; Mon, 9 Jul 2012 15:46:20 +0900 (JST) Received: (from root@localhost) by mailgate4.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id q696kKJ18279; Mon, 9 Jul 2012 15:46:20 +0900 (JST) Received: from mail02.kamome.nec.co.jp (mail02.kamome.nec.co.jp [10.25.43.5]) by mailsv.nec.co.jp (8.13.8/8.13.4) with ESMTP id q696k4TP001249; Mon, 9 Jul 2012 15:46:20 +0900 (JST) Received: from shikibu.jp.nec.com ([10.26.220.2] [10.26.220.2]) by mail03.kamome.nec.co.jp with ESMTP id BT-MMP-299832; Mon, 9 Jul 2012 15:45:16 +0900 Received: from siznecatg159185 ([10.3.159.185] [10.3.159.185]) by mail.jp.nec.com with ESMTP; Mon, 9 Jul 2012 15:45:15 +0900 To: Joel jaeggli In-reply-to: <4FF7077B.5050703@bogus.com> Message-Id: <20120709154515kawashimam@mail.jp.nec.com> References: <4FF7077B.5050703@bogus.com> Mime-Version: 1.0 X-Mailer: StarOffice21/MailClient[4.65 Step9] From: Masanobu Kawashima Date: Mon, 9 Jul 2012 15:45:14 +0900 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] Call for Adoption, was Re: New draft waiting for adoption:draft-chen-v6ops-nat64-experience-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 09 Jul 2012 06:46:01 -0000 I support this document as a WG document. Regards, Masanobu >The following message commences a 1 week call for opinions on the >adoption of draft-chen-v6ops-nat64-experience-02 > > http://tools.ietf.org/html/draft-chen-v6ops-nat64-experience-02 > >Friday 7/13/2012 is the deadline for this particular call. > >Thank you. >joel > >>> $Bh>"f%/Th!!-m-fmz(B>>> >>> Dear Chairs, >>> >>> >>> >>> We have posted new draft of NAT64 experiences. >>> >>> Current draft is a joined effort from four operators (China Mobile, >>> T-mobile USA, China Telecom and France Telecom) >>> >>> who is actively progressing IPv6 deployment depending on the practices. >>> >>> Several experts encourage us to continue the work after their kind review >>> >>> >>> >>> For now, we have addressed all comments. >>> >>> The draft is ready for the adoption. >>> >>> The authors would like to consult your opinions and look forward your >>> guidance. >>> >>> >>> >>> >>> >>> Many thanks >>> >>> >>> >>> Authors >>> >>> >>> >>> ===================================================== >>> >>> A new version of I-D, draft-chen-v6ops-nat64-experience-02.txt >>> >>> has been successfully submitted by Gang Chen and posted to the >>> >>> IETF repository. >>> >>> >>> >>> Filename: draft-chen-v6ops-nat64-experience >>> >>> Revision: 02 >>> >>> Title: NAT64 Operational Experiences >>> >>> Creation date: 2012-07-04 >>> >>> WG ID: Individual Submission >>> >>> Number of pages: 15 >>> >>> URL: >>> http://www.ietf.org/internet-drafts/draft-chen-v6ops-nat64-experience-02.txt >>> >>> Status: >>> http://datatracker.ietf.org/doc/draft-chen-v6ops-nat64-experience >>> >>> Htmlized: >>> http://tools.ietf.org/html/draft-chen-v6ops-nat64-experience-02 >>> >>> Diff: >>> http://tools.ietf.org/rfcdiff?url2=draft-chen-v6ops-nat64-experience-02 >>> >>> >>> >>> Abstract: >>> >>> This document summarizes some stateful NAT64 deployment scenarios and >>> >>> operational experiences for NAT64-CGN and NAT64-CE. >>> >>> >>> >>> >>> >> > > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops ======================================== NEC AccessTechnica, Ltd. Product Development Department Masanobu Kawashima kawashimam@vx.jp.nec.com http://www.necat.co.jp/ ======================================== From brian.e.carpenter@gmail.com Mon Jul 9 02:12: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 1CDBE21F87FD for ; Mon, 9 Jul 2012 02:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.099 X-Spam-Level: X-Spam-Status: No, score=-101.099 tagged_above=-999 required=5 tests=[AWL=0.592, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vb0kEwtjQJ4G for ; Mon, 9 Jul 2012 02:12:54 -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 5C7F521F87E9 for ; Mon, 9 Jul 2012 02:12:54 -0700 (PDT) Received: by eekd4 with SMTP id d4so4415361eek.31 for ; Mon, 09 Jul 2012 02:13:18 -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=TLoRZ7JsXdYp8rpRL4SvFA+H6zq+qO61cMDs5pVKgkY=; b=G9kuY7FGAZYAWgDYX2z1I0+DaqSQWVVJDeB1NiVtFH8PO4hwpvOS9AcOxBVFMvhfQJ 7vEilrQuOPLBwTMK/hr4ZYIgnNYmtuNa7C883aYM3GXdiVPHZGw6d4WJJscPfHfQfCFC LIGFu8KU1llc3YL4kcth1OWoUUNuBd63jW59B9zFQ+ZDcOQau3MmZq2e6HGFtYrCzAS0 Z1B1/AbTylAygETS6TDG7M+9oGj8fJsV03G8BkQ3o1lQbZ8B3p3IIMig6llwZ3fSXDCf y0u2tsCzdve8pU7wuwiJIpDwy1DvUvKHj4TmMPK/fLJ6chUoTTei8qMylVU3cSWBLkOJ xqtw== Received: by 10.14.185.134 with SMTP id u6mr9054451eem.188.1341825198018; Mon, 09 Jul 2012 02:13:18 -0700 (PDT) Received: from [192.168.1.66] (host-2-102-218-129.as13285.net. [2.102.218.129]) by mx.google.com with ESMTPS id z5sm92025960eem.3.2012.07.09.02.13.15 (version=SSLv3 cipher=OTHER); Mon, 09 Jul 2012 02:13:16 -0700 (PDT) Message-ID: <4FFAA0A8.1040903@gmail.com> Date: Mon, 09 Jul 2012 10:13:12 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Randy Bush References: <4FF71993.7090301@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, philip_matthews@magma.ca Subject: Re: [v6ops] RE new draft: draft-matthews-v6ops-design-guidelines X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 09 Jul 2012 09:12:55 -0000 On 09/07/2012 07:18, Randy Bush wrote: >> The design *advantage* of ULAs is that if you merge two networks >> using them, the addressing scheme still works. If you merge two >> Net 10s, stuff breaks. ^ might It's true that there is a very small probability of two sites picking the same ULA prefix, but operationally this seems irrelevantly unlikely, so I find that unqualified "might" misleading. > the design advantage of using global space is that it will always > work. Yes, all other things being equal, I agree. Brian From randy@psg.com Mon Jul 9 02:17: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 EEC8821F8819 for ; Mon, 9 Jul 2012 02:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EsVCUVqeZg7O for ; Mon, 9 Jul 2012 02:17:37 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 714B121F8814 for ; Mon, 9 Jul 2012 02:17:37 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SoA6Q-000HaW-Ct; Mon, 09 Jul 2012 09:17:58 +0000 Date: Mon, 09 Jul 2012 18:17:57 +0900 Message-ID: From: Randy Bush To: Brian E Carpenter In-Reply-To: <4FFAA0A8.1040903@gmail.com> References: <4FF71993.7090301@gmail.com> <4FFAA0A8.1040903@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: v6ops@ietf.org, philip_matthews@magma.ca Subject: Re: [v6ops] RE new draft: draft-matthews-v6ops-design-guidelines X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 09 Jul 2012 09:17:38 -0000 >>> The design *advantage* of ULAs is that if you merge two networks >>> using them, the addressing scheme still works. If you merge two >>> Net 10s, stuff breaks. ^ might > It's true that there is a very small probability of two sites picking > the same ULA prefix, but operationally this seems irrelevantly > unlikely, so I find that unqualified "might" misleading. i'm from ops. i do not want to have to explain to people who wear funny clothes why i took the risk that a 9.0 earthquake would not happen. especially when it was trivially avoidable. randy From philip_matthews@magma.ca Mon Jul 9 05:12: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 6DF0E21F864F for ; Mon, 9 Jul 2012 05:12:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ve0LO32QIXEb for ; Mon, 9 Jul 2012 05:12:21 -0700 (PDT) Received: from mail-09.primus.ca (mail16.primus.ca [216.254.141.183]) by ietfa.amsl.com (Postfix) with ESMTP id 8738A21F8619 for ; Mon, 9 Jul 2012 05:12:21 -0700 (PDT) Received: from [74.198.165.119] (helo=[172.20.10.2]) by mail-09.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1SoCpW-0004Kr-0J; Mon, 09 Jul 2012 08:12:45 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Philip Matthews In-Reply-To: Date: Mon, 9 Jul 2012 08:11:50 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8D67ADFF-3F9C-4E2D-900A-A08C799503B6@magma.ca> References: , <3F7BC6E6-10C6-464D-9F9D-3769F432728B@magma.ca> To: Tina TSOU X-Mailer: Apple Mail (2.1084) X-Authenticated: philip_matthews - ([172.20.10.2]) [74.198.165.119] Cc: "v6ops@ietf.org" Subject: Re: [v6ops] RE new draft: draft-matthews-v6ops-design-guidelines X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 09 Jul 2012 12:12:22 -0000 Hi Tina: Thanks for your suggestions! =20 Your proposed text seems to be taking the draft in a slightly different = direction. My idea was to discuss the choices that someone configuring = a router for IPv6 (or for a mixed v4/v6 network) could make. For = example, whether to run v4 and v6 on the same interface or on separate = interfaces. One might call these "operational choices". It seems that = your text is documenting protocol and implementation design decisions = between v4 and v6 instead. These are also interesting, but I am = wondering if these are not best covered in a separate draft? - Philip On 2012-07-06, at 12:31 , Tina TSOU wrote: > Hi Phil, > Here is the proposed text for section 8. >=20 > 8. OSPF >=20 > 8.1 Enabling OSPFv3 per interface or OSPFv2 per subnet/network:=20 > Enabling OSPFv3 on a per-interface basis provides us with the = advantage of enabling/ disabling a particular interface for the OSPF = process. When OSPFv3 is enabled in the router configuration mode, = selecting a particular interface by enabling it simplifies the = configuration of OSPF, as compared to specifying the network in OSPFv2. > The main advantage of this approach is that the interfaces of the two = OSPF neighbor routers do not have to be in the same subnet for = successfully forming OSPF neighbors. The interfaces of the two routers = participating in the OSPF process have to be enabled with OSPF on the = interface configuration mode. Since an interface can have multiple IPv6 = addresses, this feature provides one with the ability of efficiently = using the addresses for routing. > Initiating IPv6 on the interface also prevents human errors caused by = configuring wrong network address or wild card masks. There is no = requirement of calculating the network address of the interface for = initiating the OSPF process on the routers.=20 > One of the disadvantages of the per-interface approach is in terms of = security concerns. If one of the interfaces of the router is enabled = with OSPFv3 in the interface configuration mode, and a second OSPF = speaking router is connected to the interface, both the routers will be = able to form neighbors, even though the second router may be a rogue = router in a different network.OSPFv3 has no authentication field in its = header, and thus depends on the IPv6 authentication header (AH) and = Encapsulating Security Payload (ESP). Thus, from the security point of = view, one should be have a clear idea of the network design, before = enabling the OSPF process on the interface. >=20 > 8.2 Multiple instances per link in OSPFv3 or multiple OSPF processes = in OSPFv2=20 > OSPFv3 supports multiple OSPF instances per interface. This feature = makes it possible to add a single interface to be part of more than one = area, by having different instance ID. The interface would represent the = scenario of multiple logical interfaces on a single physical interface. = Adding multiple OSPF processes or instances in OSPFv2 adds more overhead = and overloads the router. However, having a single OSPFv3 process and = adding instances per interface helps us in maximizing the efficiency of = the router, without overloading it. > The only disadvantage would be some amount of added complexity in = managing the instances, by maintaining a database of the instance IDs = for each instance in the header. >=20 >=20 >=20 > 8.3 OSPFv3 next-hop addresses: Local or Global addresses? > After enabling OSPFv3 for internal routing purposes, the next hop = address of an OSPFv3 route can be either a: > a. Link local address. > b. Global address. > There are a number of advantages of using link local addresses as next = hop for OSPFv3 routes. First, the link local addresses are automatically = configured when IPv6 is enabled on the router and do not need any = additional configuration. Even if link Local addresses change, (due to = the change of a network interface card, the MAC address changes), the = router would recalculate its link local address on its own and would = advertise it to the other routers in the link.=20 > Link local addresses are a representation of layer 2 to layer 3 = mapping (EUI-64). Link local addresses do not propagate outside the = scope of a link and are more secure. Routers learn link local addresses = with the help of Neighbor Discover protocol (NDP), thus an additional = lookup in the routing table is not required. It saves processing and = memory of the routers. >=20 >=20 >=20 > 8.4 Router ID (RID) inconsistency removed in OSPFv3 > In the case of OSPFv2, there is inconsistency in the RID of the = routers. If the RID is configured manually in the router configuration = mode, it is selected as the RID. Else, the loopback interface with the = highest IP address is selected as the RID. If there are no loopback = addresses configured, the highest IP address of an interface is selected = as the RID. This leads to inconsistency in the RID in the OSPF database. = This inconsistency is no longer present in OSPFv3 and it mandates the = use of a 32-bit dotted decimal to be configured as RID for each router. = Thus, all the routers are recognized by a unique RID, which helps in = convenient and easier recognition.=20 >=20 >=20 >=20 > 8.5 Are separate sessions required for IPv4 and IPv6? > OSPFv3 is solely used for routing IPv6 traffic and not IPv4 traffic. = There is a separate routing table for OSPFv3 and OSPFv2. If the router = is a dual stack router, both OSPFv2 and OSPFv3 have to be configured = separately for enabling IPv4 and IPv6 routing respectively. > The disadvantage of a single session for both IPv4 and IPv6 is the = unnecessary delay in the lookup of the much larger routing table, = containing both IPv4 and IPv6 routes. There is also an added advantage = of the separate session approach in maintaining separate traffic = measurements for both kind of traffic and thus implementing traffic = engineering accordingly.=20 > The disadvantage of this process is the need of router memory and = resources in maintaining two routing tables and two processes for both = protocols in the routers. =20 >=20 > Tina >=20 > On Jul 6, 2012, at 6:59 AM, "Philip Matthews" = wrote: >=20 From Tina.Tsou.Zouting@huawei.com Mon Jul 9 16:31: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 507E711E8121 for ; Mon, 9 Jul 2012 16:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.845 X-Spam-Level: X-Spam-Status: No, score=-5.845 tagged_above=-999 required=5 tests=[AWL=0.754, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id isrqLZkfNO8P for ; Mon, 9 Jul 2012 16:31:27 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6803F21F86FC for ; Mon, 9 Jul 2012 16:31:27 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHW52115; Mon, 09 Jul 2012 19:31:53 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 9 Jul 2012 16:29:17 -0700 Received: from dfweml513-mbx.china.huawei.com ([169.254.3.208]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0323.003; Mon, 9 Jul 2012 16:29:14 -0700 From: Tina TSOU To: Philip Matthews Thread-Topic: [v6ops] RE new draft: draft-matthews-v6ops-design-guidelines Thread-Index: AQHNWecJACikpvqhIUyikIXbIivbupccr6kA///GPQaABOOuAIAAR+pG Date: Mon, 9 Jul 2012 23:29:13 +0000 Message-ID: <02D187E2-27A7-42D7-851D-93B04EF28781@huawei.com> References: , <3F7BC6E6-10C6-464D-9F9D-3769F432728B@magma.ca> , <8D67ADFF-3F9C-4E2D-900A-A08C799503B6@magma.ca> In-Reply-To: <8D67ADFF-3F9C-4E2D-900A-A08C799503B6@magma.ca> Accept-Language: en-US, zh-CN 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 X-CFilter-Loop: Reflected Cc: "v6ops@ietf.org" Subject: Re: [v6ops] RE new draft: draft-matthews-v6ops-design-guidelines X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 09 Jul 2012 23:31:28 -0000 I was thinking in line with: If we are using OSPF v2 for IPv4, why should = we use OSPFV3 for IPv6. Tina On Jul 9, 2012, at 5:12 AM, "Philip Matthews" wr= ote: > Hi Tina: >=20 > Thanks for your suggestions! =20 >=20 > Your proposed text seems to be taking the draft in a slightly different d= irection. My idea was to discuss the choices that someone configuring a ro= uter for IPv6 (or for a mixed v4/v6 network) could make. For example, wheth= er to run v4 and v6 on the same interface or on separate interfaces. One mi= ght call these "operational choices". It seems that your text is document= ing protocol and implementation design decisions between v4 and v6 instead.= These are also interesting, but I am wondering if these are not best cove= red in a separate draft? >=20 > - Philip >=20 > On 2012-07-06, at 12:31 , Tina TSOU wrote: >=20 >> Hi Phil, >> Here is the proposed text for section 8. >>=20 >> 8. OSPF >>=20 >> 8.1 Enabling OSPFv3 per interface or OSPFv2 per subnet/network:=20 >> Enabling OSPFv3 on a per-interface basis provides us with the advantage = of enabling/ disabling a particular interface for the OSPF process. When OS= PFv3 is enabled in the router configuration mode, selecting a particular in= terface by enabling it simplifies the configuration of OSPF, as compared to= specifying the network in OSPFv2. >> The main advantage of this approach is that the interfaces of the two OS= PF neighbor routers do not have to be in the same subnet for successfully f= orming OSPF neighbors. The interfaces of the two routers participating in t= he OSPF process have to be enabled with OSPF on the interface configuration= mode. Since an interface can have multiple IPv6 addresses, this feature pr= ovides one with the ability of efficiently using the addresses for routing. >> Initiating IPv6 on the interface also prevents human errors caused by co= nfiguring wrong network address or wild card masks. There is no requirement= of calculating the network address of the interface for initiating the OSP= F process on the routers.=20 >> One of the disadvantages of the per-interface approach is in terms of se= curity concerns. If one of the interfaces of the router is enabled with OSP= Fv3 in the interface configuration mode, and a second OSPF speaking router = is connected to the interface, both the routers will be able to form neighb= ors, even though the second router may be a rogue router in a different net= work.OSPFv3 has no authentication field in its header, and thus depends on = the IPv6 authentication header (AH) and Encapsulating Security Payload (ESP= ). Thus, from the security point of view, one should be have a clear idea o= f the network design, before enabling the OSPF process on the interface. >>=20 >> 8.2 Multiple instances per link in OSPFv3 or multiple OSPF processes in = OSPFv2=20 >> OSPFv3 supports multiple OSPF instances per interface. This feature make= s it possible to add a single interface to be part of more than one area, b= y having different instance ID. The interface would represent the scenario = of multiple logical interfaces on a single physical interface. Adding multi= ple OSPF processes or instances in OSPFv2 adds more overhead and overloads = the router. However, having a single OSPFv3 process and adding instances pe= r interface helps us in maximizing the efficiency of the router, without ov= erloading it. >> The only disadvantage would be some amount of added complexity in managi= ng the instances, by maintaining a database of the instance IDs for each in= stance in the header. >>=20 >>=20 >>=20 >> 8.3 OSPFv3 next-hop addresses: Local or Global addresses? >> After enabling OSPFv3 for internal routing purposes, the next hop addres= s of an OSPFv3 route can be either a: >> a. Link local address. >> b. Global address. >> There are a number of advantages of using link local addresses as next h= op for OSPFv3 routes. First, the link local addresses are automatically con= figured when IPv6 is enabled on the router and do not need any additional c= onfiguration. Even if link Local addresses change, (due to the change of a = network interface card, the MAC address changes), the router would recalcul= ate its link local address on its own and would advertise it to the other r= outers in the link.=20 >> Link local addresses are a representation of layer 2 to layer 3 mapping = (EUI-64). Link local addresses do not propagate outside the scope of a link= and are more secure. Routers learn link local addresses with the help of N= eighbor Discover protocol (NDP), thus an additional lookup in the routing t= able is not required. It saves processing and memory of the routers. >>=20 >>=20 >>=20 >> 8.4 Router ID (RID) inconsistency removed in OSPFv3 >> In the case of OSPFv2, there is inconsistency in the RID of the routers.= If the RID is configured manually in the router configuration mode, it is = selected as the RID. Else, the loopback interface with the highest IP addre= ss is selected as the RID. If there are no loopback addresses configured, t= he highest IP address of an interface is selected as the RID. This leads to= inconsistency in the RID in the OSPF database. This inconsistency is no lo= nger present in OSPFv3 and it mandates the use of a 32-bit dotted decimal t= o be configured as RID for each router. Thus, all the routers are recognize= d by a unique RID, which helps in convenient and easier recognition.=20 >>=20 >>=20 >>=20 >> 8.5 Are separate sessions required for IPv4 and IPv6? >> OSPFv3 is solely used for routing IPv6 traffic and not IPv4 traffic. The= re is a separate routing table for OSPFv3 and OSPFv2. If the router is a du= al stack router, both OSPFv2 and OSPFv3 have to be configured separately fo= r enabling IPv4 and IPv6 routing respectively. >> The disadvantage of a single session for both IPv4 and IPv6 is the unnec= essary delay in the lookup of the much larger routing table, containing bot= h IPv4 and IPv6 routes. There is also an added advantage of the separate se= ssion approach in maintaining separate traffic measurements for both kind o= f traffic and thus implementing traffic engineering accordingly.=20 >> The disadvantage of this process is the need of router memory and resour= ces in maintaining two routing tables and two processes for both protocols = in the routers. =20 >>=20 >> Tina >>=20 >> On Jul 6, 2012, at 6:59 AM, "Philip Matthews" = wrote: >>=20 >=20 From Fred.L.Templin@boeing.com Mon Jul 9 17:05: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 735FE11E80D1 for ; Mon, 9 Jul 2012 17:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.114 X-Spam-Level: X-Spam-Status: No, score=-2.114 tagged_above=-999 required=5 tests=[AWL=-0.115, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qb-InZewg51L for ; Mon, 9 Jul 2012 17:05:21 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) by ietfa.amsl.com (Postfix) with ESMTP id AD0D221F86A5 for ; Mon, 9 Jul 2012 17:05:20 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q6A05jw1001370 for ; Mon, 9 Jul 2012 17:05:46 -0700 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [130.247.228.54]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q6A05ilE001361 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 9 Jul 2012 17:05:45 -0700 Received: from stl-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q6A05iX1026037; Mon, 9 Jul 2012 19:05:44 -0500 Received: from XCH-NWHT-02.nw.nos.boeing.com (xch-nwht-02.nw.nos.boeing.com [130.247.70.248]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q6A05hS5026018 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 9 Jul 2012 19:05:44 -0500 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-02.nw.nos.boeing.com ([130.247.70.248]) with mapi; Mon, 9 Jul 2012 17:05:43 -0700 From: "Templin, Fred L" To: Joe Touch Date: Mon, 9 Jul 2012 17:05:42 -0700 Thread-Topic: [v6ops] Prep for v6ops IETF 84 agenda Thread-Index: Ac1WL5ycrhwC71jqR/+m8XEHfMnATgH/y8og Message-ID: References: <8D73E1D6-A968-4397-A843-FE073197B7F1@cisco.com> <4FEE0533.1060203@isi.edu> In-Reply-To: <4FEE0533.1060203@isi.edu> 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: "v6ops@ietf.org WG" , Ron Bonica Subject: Re: [v6ops] Prep for v6ops IETF 84 agenda X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 10 Jul 2012 00:05:21 -0000 Hi Joe, I have taken your suggestion and now have two separate documents: > I was expecting a differrent approach: >=20 > a) revise this doc to focus on ops issues that > don't require any standards changes Here is the original one that has now been revised to focus on ops issues that don't require any standards changes: https://datatracker.ietf.org/doc/draft-generic-v6ops-tunmtu/ >=20 > b) propose the problem of IPv6 downstream refragmentation > in a separate doc in a different WG and, here is a new one that addresses fragmentation in a separate doc in the 6man WG: http://www.ietf.org/id/draft-generic-6man-tunfrag-02.txt Thanks - Fred fred.l.templin@boeing.com From Fred.L.Templin@boeing.com Mon Jul 9 17:07: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 4EDD611E8136 for ; Mon, 9 Jul 2012 17:07:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[AWL=-0.110, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jo8uFak2PMtJ for ; Mon, 9 Jul 2012 17:07:35 -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 8571711E812A for ; Mon, 9 Jul 2012 17:07:35 -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 q6A080Qs028277 for ; Mon, 9 Jul 2012 19:08:01 -0500 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [130.247.228.54]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q6A080O6028272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 9 Jul 2012 19:08:00 -0500 Received: from stl-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q6A080mw030005; Mon, 9 Jul 2012 19:08:00 -0500 Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q6A07xdk029985 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 9 Jul 2012 19:08:00 -0500 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-11.nw.nos.boeing.com ([130.247.25.114]) with mapi; Mon, 9 Jul 2012 17:07:59 -0700 From: "Templin, Fred L" To: "Fred Baker (fred)" Date: Mon, 9 Jul 2012 17:07:57 -0700 Thread-Topic: Prep for v6ops IETF 84 agenda Thread-Index: AQHNUnbpWFu7FKUfJEyvobkjy/vWXZchuqSQ Message-ID: References: <8D73E1D6-A968-4397-A843-FE073197B7F1@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "v6ops@ietf.org WG" , Ron Bonica Subject: Re: [v6ops] Prep for v6ops IETF 84 agenda X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 10 Jul 2012 00:07:36 -0000 Hi Fred, > -----Original Message----- > From: Fred Baker (fred) [mailto:fred@cisco.com] > Sent: Thursday, June 28, 2012 4:21 PM > To: Templin, Fred L > Cc: v6ops@ietf.org WG; Ron Bonica > Subject: Re: Prep for v6ops IETF 84 agenda >=20 >=20 > On Jun 29, 2012, at 12:34 AM, Templin, Fred L wrote: >=20 > >> -----Original Message----- > >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of > >> Fred Baker (fred) > >> Sent: Sunday, June 24, 2012 7:05 PM > >> To: v6ops@ietf.org WG > >> Cc: Ron Bonica > >> Subject: [v6ops] Prep for v6ops IETF 84 agenda > >> > >> I sat down this morning to assess our agenda. Interested in working > group > >> comment. > > > > OK Fred; I'll bite. Why are you listing 'draft-generic-v6ops-tunmtu' > > as "#out of charter"? >=20 > Because changes to section 4.5 of RFC 2460 ("a source node may divide the > packet...") is a change to RFC 2460, and should be discussed by the folks > maintaining RFC 2460. This document has now been revised to speak only to operational issues (and not any changes to RFC2460 nor any other documents): https://datatracker.ietf.org/doc/draft-generic-v6ops-tunmtu/ Please re-review and re-evaluate in terms of charter applicability. Thanks - Fred fred.l.templin@boeing.com =20 > Begin forwarded message: >=20 > > From: "Fred Baker (fred)" > > Date: June 23, 2012 5:43:22 AM GMT+08:00 > > To: Fred Templin , "v6ops@ietf.org WG" > > > Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu > > > > Coming back to this as a meta-issue. > > > > v6ops is about operational considerations and procedures, but not > protocols; disputing RFC 2460, aka redesigning IPv6, seems like a protoco= l > issue. > > > > The reason to not do inner fragmentation, if memory serves, has to do > with the behavior of fragmentation in the network and its effect on > communications. For example, suppose you and I are in 9K clean networks > (so the TCP MSS starts out as 9K), my link to the public network has an > MTU of 1500, and somewhere en route to you there is another link with an > MTU of 1400. When I send a 9K packet, it will become six 1500 byte packet= s > with a small caboose that picks up the size of five IP headers (IPv4 or > IPv6), and what you will receive is six 1400 byte packets interspersed > with six 100+IP byte packets, followed by the original caboose. What if > the fragmenting router's queue, at the time of fragmentation, was one > packet short of the needed capacity? Maybe the retransmission follows a > different path and is fragmented differently, resulting in funny overlaps > whose handling isn't very well specified. There's nothing *incorrect* > about a stream of 13 packets of various sizes being reassem > > bled, but integrating retransmissions gets messy. IIRC, they just wante= d > to clean that up. > > > > Which brings me to the following consideration. > > > > If we're talking about having one tunnel endpoint put a message into a > tunnel datagram and then fragment it, and have the other tunnel endpoint > reassemble the original and forward it, we are talking about an > operational procedure that requires support in a router, but which I can > correlate with section 5 of RFC 2460. > > > > One thing I would invite is discussion of operational experience with > RFC 4821. Wouldn't it be nice if the endpoint actually chose an MSS based > on what actually worked (shades of Happy Eyeballs), rather than depending > on error messages that network operators routinely filter out? > > > > If we're talking about changing the recommendation of RFC 2460 regardin= g > who does fragmentation, that sounds like an IPv6 protocol change, and I'd > like to refer that to 6MAN. > > > > Does that make sense? > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops From fred@cisco.com Mon Jul 9 19: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 044BE21F85D2 for ; Mon, 9 Jul 2012 19:01:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.249 X-Spam-Level: X-Spam-Status: No, score=-110.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RXVbqwmSzbeg for ; Mon, 9 Jul 2012 19:01:10 -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 A8BC321F85CE for ; Mon, 9 Jul 2012 19:01:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=4345; q=dns/txt; s=iport; t=1341885697; x=1343095297; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=rO7u12rqZqNhU3WadRWAOGZtXDmpLeFbcrTluZKymhs=; b=Di6/JVlYDViRhexv6dMB3zVpHafiTUbROo0nNZPjNV486KZDPPGHpIYt TN9igteilpFKXu3JLneDePvFYVPBKUIhEZ7v4KtgEsI6xb2SrrhgQNIcX rztvHPEZmt1GZJBzJ0sA/c2T5Jm/Kgvc93SDmoTT78eUDPs3x49NLS+dd I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJSM+0+tJV2d/2dsb2JhbABFt3yBB4IgAQEBAwEBAQEPASc0CwUHBAIBCBEDAQEBAR4JBycLFAkIAgQOBSKHZQYLnB6gPgSLQIVCYAOVNo4fgWaCXw X-IronPort-AV: E=Sophos;i="4.77,556,1336348800"; d="scan'208";a="100198054" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP; 10 Jul 2012 02:01:36 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q6A21ajN007064 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Jul 2012 02:01:36 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.118]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0298.004; Mon, 9 Jul 2012 21:01:36 -0500 From: "Fred Baker (fred)" To: "Templin, Fred L" Thread-Topic: Prep for v6ops IETF 84 agenda Thread-Index: AQHNUnbpWFu7FKUfJEyvobkjy/vWXQ== Date: Tue, 10 Jul 2012 02:01:13 +0000 Message-ID: <57B96402-FB12-4579-9731-BDD7FC89C9D3@cisco.com> References: <8D73E1D6-A968-4397-A843-FE073197B7F1@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.85.176] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19030.000 x-tm-as-result: No--75.609400-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 Cc: "v6ops@ietf.org WG" , Ron Bonica Subject: Re: [v6ops] Prep for v6ops IETF 84 agenda X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 10 Jul 2012 02:01:12 -0000 No problem. Same rules apply as to all drafts; Joel and I will be looking f= or operational interest from the working group. On Jul 9, 2012, at 5:07 PM, Templin, Fred L wrote: > Hi Fred, >=20 >> -----Original Message----- >> From: Fred Baker (fred) [mailto:fred@cisco.com] >> Sent: Thursday, June 28, 2012 4:21 PM >> To: Templin, Fred L >> Cc: v6ops@ietf.org WG; Ron Bonica >> Subject: Re: Prep for v6ops IETF 84 agenda >>=20 >>=20 >> On Jun 29, 2012, at 12:34 AM, Templin, Fred L wrote: >>=20 >>>> -----Original Message----- >>>> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf >> Of >>>> Fred Baker (fred) >>>> Sent: Sunday, June 24, 2012 7:05 PM >>>> To: v6ops@ietf.org WG >>>> Cc: Ron Bonica >>>> Subject: [v6ops] Prep for v6ops IETF 84 agenda >>>>=20 >>>> I sat down this morning to assess our agenda. Interested in working >> group >>>> comment. >>>=20 >>> OK Fred; I'll bite. Why are you listing 'draft-generic-v6ops-tunmtu' >>> as "#out of charter"? >>=20 >> Because changes to section 4.5 of RFC 2460 ("a source node may divide th= e >> packet...") is a change to RFC 2460, and should be discussed by the folk= s >> maintaining RFC 2460. >=20 > This document has now been revised to speak only to > operational issues (and not any changes to RFC2460 > nor any other documents): >=20 > https://datatracker.ietf.org/doc/draft-generic-v6ops-tunmtu/ >=20 > Please re-review and re-evaluate in terms of charter > applicability. >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 >> Begin forwarded message: >>=20 >>> From: "Fred Baker (fred)" >>> Date: June 23, 2012 5:43:22 AM GMT+08:00 >>> To: Fred Templin , "v6ops@ietf.org WG" >> >>> Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu >>>=20 >>> Coming back to this as a meta-issue. >>>=20 >>> v6ops is about operational considerations and procedures, but not >> protocols; disputing RFC 2460, aka redesigning IPv6, seems like a protoc= ol >> issue. >>>=20 >>> The reason to not do inner fragmentation, if memory serves, has to do >> with the behavior of fragmentation in the network and its effect on >> communications. For example, suppose you and I are in 9K clean networks >> (so the TCP MSS starts out as 9K), my link to the public network has an >> MTU of 1500, and somewhere en route to you there is another link with an >> MTU of 1400. When I send a 9K packet, it will become six 1500 byte packe= ts >> with a small caboose that picks up the size of five IP headers (IPv4 or >> IPv6), and what you will receive is six 1400 byte packets interspersed >> with six 100+IP byte packets, followed by the original caboose. What if >> the fragmenting router's queue, at the time of fragmentation, was one >> packet short of the needed capacity? Maybe the retransmission follows a >> different path and is fragmented differently, resulting in funny overlap= s >> whose handling isn't very well specified. There's nothing *incorrect* >> about a stream of 13 packets of various sizes being reassem >>> bled, but integrating retransmissions gets messy. IIRC, they just wante= d >> to clean that up. >>>=20 >>> Which brings me to the following consideration. >>>=20 >>> If we're talking about having one tunnel endpoint put a message into a >> tunnel datagram and then fragment it, and have the other tunnel endpoint >> reassemble the original and forward it, we are talking about an >> operational procedure that requires support in a router, but which I can >> correlate with section 5 of RFC 2460. >>>=20 >>> One thing I would invite is discussion of operational experience with >> RFC 4821. Wouldn't it be nice if the endpoint actually chose an MSS base= d >> on what actually worked (shades of Happy Eyeballs), rather than dependin= g >> on error messages that network operators routinely filter out? >>>=20 >>> If we're talking about changing the recommendation of RFC 2460 regardin= g >> who does fragmentation, that sounds like an IPv6 protocol change, and I'= d >> like to refer that to 6MAN. >>>=20 >>> Does that make sense? >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >=20 From jiangsheng@huawei.com Mon Jul 9 20:30: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 C8CB211E811F for ; Mon, 9 Jul 2012 20:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IBmWTEYh0vuw for ; Mon, 9 Jul 2012 20:30:49 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3756011E8110 for ; Mon, 9 Jul 2012 20:30:49 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHP68284; Mon, 09 Jul 2012 23:31:15 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 9 Jul 2012 20:27:38 -0700 Received: from SZXEML413-HUB.china.huawei.com (10.82.67.152) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 9 Jul 2012 20:27:40 -0700 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.140]) by szxeml413-hub.china.huawei.com ([10.82.67.152]) with mapi id 14.01.0323.003; Tue, 10 Jul 2012 11:27:37 +0800 From: Sheng Jiang To: "v6ops@ietf.org" Thread-Topic: New Version Notification for draft-jiang-semantic-prefix-00.txt Thread-Index: AQHNXaP3eifIRoHPo02wGSDOlR2P6pch260g Date: Tue, 10 Jul 2012 03:27:36 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B9239EF7160@szxeml545-mbx.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.31] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [v6ops] FW: New Version Notification for draft-jiang-semantic-prefix-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: Tue, 10 Jul 2012 03:30:49 -0000 SGksIGFsbCwNCg0KV2UgaGF2ZSBzdWJtaXR0ZWQgYSBuZXcgZHJhZnQgZHJhZnQtamlhbmctc2Vt YW50aWMtcHJlZml4LCAiU2VtYW50aWMgSVB2NiBQcmVmaXgiLiBJdCBwcm9wb3NlcyBhIGZyYW1l d29yayB0byBhbGxvdyBzZW1hbnRpY3MgdG8gYmUgZW1iZWRkZWQgaW50byBwcmVmaXggc28gdGhh dCBJU1AgY2FuIGVhc2lseSBhcHBseSByZWxldmFudCBvcGVyYXRpb25zIGFjY29yZGluZ2x5Lg0K DQpBbGwgY29tbWVudHMgYXJlIHdlbGNvbWUuDQoNCkJlc3QgcmVnYXJkcywNCg0KU2hlbmcNCg0K PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQo+IFNlbnQ6IE1vbmRheSwg SnVseSAwOSwgMjAxMiAzOjI1IFBNDQo+IFRvOiBTaGVuZyBKaWFuZw0KPiBTdWJqZWN0OiBOZXcg VmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWppYW5nLXNlbWFudGljLXByZWZpeC0wMC50 eHQNCj4gDQo+IA0KPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtamlhbmctc2VtYW50aWMt cHJlZml4LTAwLnR4dA0KPiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFNoZW5n IEppYW5nIGFuZCBwb3N0ZWQgdG8gdGhlDQo+IElFVEYgcmVwb3NpdG9yeS4NCj4gDQo+IEZpbGVu YW1lOgkgZHJhZnQtamlhbmctc2VtYW50aWMtcHJlZml4DQo+IFJldmlzaW9uOgkgMDANCj4gVGl0 bGU6CQkgU2VtYW50aWMgSVB2NiBQcmVmaXgNCj4gQ3JlYXRpb24gZGF0ZToJIDIwMTItMDctMDkN Cj4gV0cgSUQ6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+IE51bWJlciBvZiBwYWdlczogOQ0K PiBVUkw6DQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWppYW5n LXNlbWFudGljLXByZWZpeC0wMC50eHQNCj4gU3RhdHVzOg0KPiBodHRwOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWppYW5nLXNlbWFudGljLXByZWZpeA0KPiBIdG1saXplZDogICAg ICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWppYW5nLXNlbWFudGljLXByZWZp eC0wMA0KPiANCj4gDQo+IEFic3RyYWN0Og0KPiAgICBTb21lIEludGVybmV0IFNlcnZpY2UgUHJv dmlkZXJzIGRlc2lyZSB0byBiZSBhd2FyZSBvZiBtb3JlDQo+ICAgIGluZm9ybWF0aW9uIGFib3V0 IGVhY2ggcGFja2V0LCBzbyB0aGF0IHBhY2tldHMgY2FuIGJlIHRyZWF0ZWQNCj4gICAgZGlmZmVy ZW50bHkgYW5kIGVmZmljaWVudGx5LiBJUHY2LCB3aXRoIGEgbGFyZ2UgYWRkcmVzcyBzcGFjZSwg YWxsb3dzDQo+ICAgIHNlbWFudGljcyB0byBiZSBlbWJlZGRlZCBpbnRvIGFkZHJlc3Nlcy4gUm91 dGVycyBjYW4gZWFzaWx5IGFwcGx5DQo+ICAgIHJlbGV2YW50IG9wZXJhdGlvbnMgYWNjb3JkaW5n bHkuIFRoaXMgZG9jdW1lbnQgcHJvdmlkZXMgYW5hbHlzaXMgb24NCj4gICAgaG93IHRvIGZvcm0g c2VtYW50aWMgcHJlZml4IGFuZCBjb3JyZXNwb25kaW5nIHVzZSBjYXNlcywgYW5kDQo+ICAgIGlk ZW50aWZpZXMgdGhlIHRlY2huaWNhbCByZXF1aXJlbWVudHMgdG8gbWF4aW1pemUgdGhlIGJlbmVm aXRzIG9mIHRoZQ0KPiAgICBzZW1hbnRpYyBwcmVmaXggYXBwcm9hY2guIEl0IGlzIHJlY29tbWVu ZGVkIHRvIHVzZSA0fjEyIGJpdHMgaW4NCj4gICAgcHJlZml4IGZvciBlbWJlZGRlZCBzZW1hbnRp Y3MuDQo+IA0KPiANCj4gDQo+IA0KPiBUaGUgSUVURiBTZWNyZXRhcmlhdA0K From jiangsheng@huawei.com Mon Jul 9 23:48: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 0BE0921F8535 for ; Mon, 9 Jul 2012 23:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q3T2vhmDIK+7 for ; Mon, 9 Jul 2012 23:48:18 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id D541921F8526 for ; Mon, 9 Jul 2012 23:48:17 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHW76816; Tue, 10 Jul 2012 02:48:44 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 9 Jul 2012 23:45:04 -0700 Received: from SZXEML430-HUB.china.huawei.com (10.72.61.38) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 9 Jul 2012 23:44:51 -0700 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.140]) by szxeml430-hub.china.huawei.com ([10.72.61.38]) with mapi id 14.01.0323.003; Tue, 10 Jul 2012 14:44:45 +0800 From: Sheng Jiang To: Joel jaeggli , IPv6 Ops WG Thread-Topic: [v6ops] Call for Adoption, was Re: New draft waiting for adoption: draft-chen-v6ops-nat64-experience-02 Thread-Index: AQHNW44SfsVSY/uUTESXq1zF1OB4QJciFybA Date: Tue, 10 Jul 2012 06:44:44 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B9239EF7244@szxeml545-mbx.china.huawei.com> References: <0B2FA58F71A34C199446380DA654FB07@LENOVO1E4798BB> <1DFE8BF4-885E-4F2F-AA1B-4FC1658BA688@cisco.com> <4FF7077B.5050703@bogus.com> In-Reply-To: <4FF7077B.5050703@bogus.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.31] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [v6ops] Call for Adoption, was Re: New draft waiting for adoption: draft-chen-v6ops-nat64-experience-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 10 Jul 2012 06:48:19 -0000 U3VwcG9ydCBmb3IgV0cgYWRvcHRpb24uIFF1aXRlIHVzZWZ1bCBleHBlcmllbmNlIGZvciBvdGhl ciBJU1BzLg0KDQpTaGVuZw0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206 IHY2b3BzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYNCj4gT2YgSm9lbCBqYWVnZ2xpDQo+IFNlbnQ6IEZyaWRheSwgSnVseSAwNiwgMjAx MiAxMTo0MyBQTQ0KPiBUbzogSVB2NiBPcHMgV0cNCj4gU3ViamVjdDogW3Y2b3BzXSBDYWxsIGZv ciBBZG9wdGlvbiwgd2FzIFJlOiBOZXcgZHJhZnQgd2FpdGluZyBmb3IgYWRvcHRpb246DQo+IGRy YWZ0LWNoZW4tdjZvcHMtbmF0NjQtZXhwZXJpZW5jZS0wMg0KPiANCj4gVGhlIGZvbGxvd2luZyBt ZXNzYWdlIGNvbW1lbmNlcyBhIDEgd2VlayBjYWxsIGZvciBvcGluaW9ucyBvbiB0aGUNCj4gYWRv cHRpb24gb2YgZHJhZnQtY2hlbi12Nm9wcy1uYXQ2NC1leHBlcmllbmNlLTAyDQo+IA0KPiAgaHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2hlbi12Nm9wcy1uYXQ2NC1leHBlcmllbmNl LTAyDQo+IA0KPiBGcmlkYXkgNy8xMy8yMDEyIGlzIHRoZSBkZWFkbGluZSBmb3IgdGhpcyBwYXJ0 aWN1bGFyIGNhbGwuDQo+IA0KPiBUaGFuayB5b3UuDQo+IGpvZWwNCj4gDQo+ID4+IOS8geS4muag h+WHhueahOaWh+acrOagvOW8j++8iOaooeeJiO+8iQ0KPiA+Pg0KPiA+PiBEZWFyIENoYWlycywN Cj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4gV2UgaGF2ZSBwb3N0ZWQgbmV3IGRyYWZ0IG9mIE5BVDY0 IGV4cGVyaWVuY2VzLg0KPiA+Pg0KPiA+PiBDdXJyZW50IGRyYWZ0IGlzIGEgam9pbmVkIGVmZm9y dCBmcm9tIGZvdXIgb3BlcmF0b3JzIChDaGluYSBNb2JpbGUsDQo+ID4+IFQtbW9iaWxlIFVTQSwg Q2hpbmEgVGVsZWNvbSBhbmQgRnJhbmNlIFRlbGVjb20pDQo+ID4+DQo+ID4+IHdobyBpcyBhY3Rp dmVseSBwcm9ncmVzc2luZyBJUHY2IGRlcGxveW1lbnQgZGVwZW5kaW5nIG9uIHRoZSBwcmFjdGlj ZXMuDQo+ID4+DQo+ID4+IFNldmVyYWwgZXhwZXJ0cyBlbmNvdXJhZ2UgdXMgdG8gY29udGludWUg dGhlIHdvcmsgYWZ0ZXIgdGhlaXIga2luZCByZXZpZXcNCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4g Rm9yIG5vdywgd2UgaGF2ZSBhZGRyZXNzZWQgYWxsIGNvbW1lbnRzLg0KPiA+Pg0KPiA+PiBUaGUg ZHJhZnQgaXMgcmVhZHkgZm9yIHRoZSBhZG9wdGlvbi4NCj4gPj4NCj4gPj4gVGhlIGF1dGhvcnMg d291bGQgbGlrZSB0byBjb25zdWx0IHlvdXIgb3BpbmlvbnMgYW5kIGxvb2sgZm9yd2FyZCB5b3Vy DQo+ID4+IGd1aWRhbmNlLg0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+PiBNYW55 IHRoYW5rcw0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+PiBBdXRob3JzDQo+ID4+DQo+ID4+DQo+ID4+ DQo+ID4+ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09DQo+ID4+DQo+ID4+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1jaGVuLXY2b3BzLW5h dDY0LWV4cGVyaWVuY2UtMDIudHh0DQo+ID4+DQo+ID4+IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBz dWJtaXR0ZWQgYnkgR2FuZyBDaGVuIGFuZCBwb3N0ZWQgdG8gdGhlDQo+ID4+DQo+ID4+IElFVEYg cmVwb3NpdG9yeS4NCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4gRmlsZW5hbWU6ICAgICAgICBkcmFm dC1jaGVuLXY2b3BzLW5hdDY0LWV4cGVyaWVuY2UNCj4gPj4NCj4gPj4gUmV2aXNpb246ICAgICAg ICAwMg0KPiA+Pg0KPiA+PiBUaXRsZTogICAgICAgICAgIE5BVDY0IE9wZXJhdGlvbmFsIEV4cGVy aWVuY2VzDQo+ID4+DQo+ID4+IENyZWF0aW9uIGRhdGU6ICAgMjAxMi0wNy0wNA0KPiA+Pg0KPiA+ PiBXRyBJRDogICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KPiA+Pg0KPiA+PiBOdW1i ZXIgb2YgcGFnZXM6IDE1DQo+ID4+DQo+ID4+IFVSTDoNCj4gPj4NCj4gaHR0cDovL3d3dy5pZXRm Lm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtY2hlbi12Nm9wcy1uYXQ2NC1leHBlcmllbmNlLTAy Lg0KPiB0eHQNCj4gPj4NCj4gPj4gU3RhdHVzOg0KPiA+PiBodHRwOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWNoZW4tdjZvcHMtbmF0NjQtZXhwZXJpZW5jZQ0KPiA+Pg0KPiA+PiBI dG1saXplZDoNCj4gPj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2hlbi12Nm9w cy1uYXQ2NC1leHBlcmllbmNlLTAyDQo+ID4+DQo+ID4+IERpZmY6DQo+ID4+IGh0dHA6Ly90b29s cy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtY2hlbi12Nm9wcy1uYXQ2NC1leHBlcmllbmNl LTAyDQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+IEFic3RyYWN0Og0KPiA+Pg0KPiA+PiAgICBUaGlz IGRvY3VtZW50IHN1bW1hcml6ZXMgc29tZSBzdGF0ZWZ1bCBOQVQ2NCBkZXBsb3ltZW50DQo+IHNj ZW5hcmlvcyBhbmQNCj4gPj4NCj4gPj4gICAgb3BlcmF0aW9uYWwgZXhwZXJpZW5jZXMgZm9yIE5B VDY0LUNHTiBhbmQgTkFUNjQtQ0UuDQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4N Cj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4gdjZvcHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0K From nick@inex.ie Tue Jul 10 03:05: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 95AAA21F870F for ; Tue, 10 Jul 2012 03:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WP-TMg7T4vMA for ; Tue, 10 Jul 2012 03:05:44 -0700 (PDT) Received: from mail.acquirer.com (mail.acquirer.com [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id D4CAB21F8709 for ; Tue, 10 Jul 2012 03:05:42 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from crumpet.local (inet-gw.acquirer.com [87.198.142.10]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id q6AA4P9U071107 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 10 Jul 2012 11:04:26 +0100 (IST) (envelope-from nick@inex.ie) Message-ID: <4FFBFE58.8040408@inex.ie> Date: Tue, 10 Jul 2012 11:05:12 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Sheng Jiang References: <5D36713D8A4E7348A7E10DF7437A4B9239EF7160@szxeml545-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B9239EF7160@szxeml545-mbx.china.huawei.com> X-Enigmail-Version: 1.4.2 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] FW: New Version Notification for draft-jiang-semantic-prefix-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: Tue, 10 Jul 2012 10:05:44 -0000 Hi Sheng, On 10/07/2012 04:27, Sheng Jiang wrote: > We have submitted a new draft draft-jiang-semantic-prefix, "Semantic > IPv6 Prefix". It proposes a framework to allow semantics to be embedded > into prefix so that ISP can easily apply relevant operations > accordingly. 1. scale: > Typically, network operators would have /13 ~ /20 address space The number of operators with /13-/20 of address space is proportionally tiny. 2. hardcoding: > In practice, a host may belong to several semantics. It means several > IPv6 addresses are available on a single physical interface. A > certain packet would only serve a certain semantic. The stack or > applications on that host must know and understand these semantics > and its correspondent bits in order to choose right source address > when forming a packet. I'm not sure that hardcoding semantics like this into an end-user application is a good idea. In fact, I'm pretty sure it isn't. Hard-coding semantics into addressing structures is an idea that crops up from time to time in different guises, and it always turns out to be a Bad Idea (e.g. rfc 2073, rfc 2374, etc). Whereas I like the idea of being able to deterministically tag traffic on ingress, applying semantics to addressing has too many problems associated with it to make it practical to deploy (e.g. class inflexibility, renumbering if a class changes, the dangers of hard-coding applications to expect specific address ranges to behave in a particular way, etc) Nick From Niall.oReilly@ucd.ie Tue Jul 10 03:13: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 1F25821F8683 for ; Tue, 10 Jul 2012 03:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mxIH4WBfwzEZ for ; Tue, 10 Jul 2012 03:13:45 -0700 (PDT) Received: from smtp.ucd.ie (mgmtirp1.ucd.ie [137.43.231.111]) by ietfa.amsl.com (Postfix) with ESMTP id 6DAE821F8681 for ; Tue, 10 Jul 2012 03:13:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,559,1336345200"; d="scan'208";a="23782036" Received: from dhcp-c101a8a5.ucd.ie ([193.1.168.165]) by smtp.ucd.ie with ESMTP/TLS/AES128-SHA; 10 Jul 2012 11:14:11 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Niall O'Reilly In-Reply-To: <4FFBFE58.8040408@inex.ie> Date: Tue, 10 Jul 2012 11:14:10 +0100 Content-Transfer-Encoding: 7bit Message-Id: <06AF4254-FAB4-496C-A894-7092451C42C0@ucd.ie> References: <5D36713D8A4E7348A7E10DF7437A4B9239EF7160@szxeml545-mbx.china.huawei.com> <4FFBFE58.8040408@inex.ie> To: Nick Hilliard X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] FW: New Version Notification for draft-jiang-semantic-prefix-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: Tue, 10 Jul 2012 10:13:46 -0000 On 10 Jul 2012, at 11:05, Nick Hilliard wrote: > applying semantics to > addressing has too many problems associated with it to make it practical to > deploy (e.g. class inflexibility, renumbering if a class changes, the > dangers of hard-coding applications to expect specific address ranges to > behave in a particular way, etc) Not to mention diversity of semantic binding and untrustworthiness of the semantic intent of other operators, just as for QoS. Niall O'Reilly From nick@inex.ie Tue Jul 10 03:27: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 246B521F8775 for ; Tue, 10 Jul 2012 03:27: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vBbWLz9Nb+b1 for ; Tue, 10 Jul 2012 03:27:07 -0700 (PDT) Received: from mail.acquirer.com (mail.acquirer.com [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 0316621F8772 for ; Tue, 10 Jul 2012 03:27:06 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from crumpet.local (inet-gw.acquirer.com [87.198.142.10]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id q6AAQeFa071375 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 10 Jul 2012 11:26:40 +0100 (IST) (envelope-from nick@inex.ie) Message-ID: <4FFC038F.40507@inex.ie> Date: Tue, 10 Jul 2012 11:27:27 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Sheng Jiang References: <5D36713D8A4E7348A7E10DF7437A4B9239EF7160@szxeml545-mbx.china.huawei.com> <4FFBFE58.8040408@inex.ie> In-Reply-To: <4FFBFE58.8040408@inex.ie> X-Enigmail-Version: 1.4.2 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] FW: New Version Notification for draft-jiang-semantic-prefix-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: Tue, 10 Jul 2012 10:27:08 -0000 On 10/07/2012 11:05, Nick Hilliard wrote: > On 10/07/2012 04:27, Sheng Jiang wrote: >> Typically, network operators would have /13 ~ /20 address space > > The number of operators with /13-/20 of address space is proportionally tiny. To qualify this statement, I pulled a copy of all ipv6 delegations from all 5 RIRs (ftp.arin.net:/pub/stats/). Out of 8702 ipv6 allocations worldwide, there are 11 delegations between /13 and /20: 1 x /16 2 x /19 8 x /20 Nick From j.schoenwaelder@jacobs-university.de Tue Jul 10 02:12: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 DDE4511E8122 for ; Tue, 10 Jul 2012 02:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.198 X-Spam-Level: X-Spam-Status: No, score=-103.198 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AVre+EAvcS8u for ; Tue, 10 Jul 2012 02:12:52 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 14AB511E80B7 for ; Tue, 10 Jul 2012 02:12:52 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5CEB720C38; Tue, 10 Jul 2012 11:13:18 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id vpYhoRsILeD5; Tue, 10 Jul 2012 11:13:18 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EB05620C33; Tue, 10 Jul 2012 11:13:17 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2B443204F360; Tue, 10 Jul 2012 11:13:17 +0200 (CEST) Date: Tue, 10 Jul 2012 11:13:17 +0200 From: Juergen Schoenwaelder To: "Will Liu (Shucheng)" Message-ID: <20120710091316.GA14517@elstar.local> Mail-Followup-To: "Will Liu (Shucheng)" , v6ops@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Tue, 10 Jul 2012 06:57:31 -0700 Cc: v6ops@ietf.org Subject: [v6ops] goals of draft-zhang-v6ops-ipv6oa-iwf-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 09:12:53 -0000 Hi, I had a look at and I am not sure what exactly this I-D proposes. Apparently, I am not clear what the "Interworking Function" discussed in the document boils down to. - If it is simply an IPv6 router, than I believe there is no problem with connecting an ATM network to an Ethernet network. - If the "Interworking Function" is not an IP layer function, then (a) where is it defined how such an "Interworking Function" works and (b) why should the working group focusing primarily on IPv6 operational and deployment issues worry about this? There might be simple answers to these question, I just did not find them easily in the document. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From Fred.L.Templin@boeing.com Tue Jul 10 08:26: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 2A57E11E80BD for ; Tue, 10 Jul 2012 08:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.105 X-Spam-Level: X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[AWL=-0.106, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TbC+F4BPGhkw for ; Tue, 10 Jul 2012 08:26:08 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) by ietfa.amsl.com (Postfix) with ESMTP id 3B26711E8099 for ; Tue, 10 Jul 2012 08:26:08 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q6AFQZvY027551 for ; Tue, 10 Jul 2012 08:26:35 -0700 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.128.218]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q6AFQY7C027538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 10 Jul 2012 08:26:35 -0700 Received: from slb-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q6AFQY61024147; Tue, 10 Jul 2012 08:26:34 -0700 Received: from XCH-NWHT-04.nw.nos.boeing.com (xch-nwht-04.nw.nos.boeing.com [130.247.64.250]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q6AFQXvO024114 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 10 Jul 2012 08:26:34 -0700 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-04.nw.nos.boeing.com ([130.247.64.250]) with mapi; Tue, 10 Jul 2012 08:26:33 -0700 From: "Templin, Fred L" To: "Fred Baker (fred)" Date: Tue, 10 Jul 2012 08:26:32 -0700 Thread-Topic: Prep for v6ops IETF 84 agenda Thread-Index: AQHNUnbpWFu7FKUfJEyvobkjy/vWXZciu1Uw Message-ID: References: <8D73E1D6-A968-4397-A843-FE073197B7F1@cisco.com> <57B96402-FB12-4579-9731-BDD7FC89C9D3@cisco.com> In-Reply-To: <57B96402-FB12-4579-9731-BDD7FC89C9D3@cisco.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: "v6ops@ietf.org WG" , Ron Bonica Subject: Re: [v6ops] Prep for v6ops IETF 84 agenda X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 10 Jul 2012 15:26:09 -0000 Fred, > -----Original Message----- > From: Fred Baker (fred) [mailto:fred@cisco.com] > Sent: Monday, July 09, 2012 7:01 PM > To: Templin, Fred L > Cc: v6ops@ietf.org WG; Ron Bonica > Subject: Re: Prep for v6ops IETF 84 agenda >=20 > No problem. Same rules apply as to all drafts; Joel and I will be looking > for operational interest from the working group. There was a lot of list discussion on this beginning in mid-May and extending through the end of June, with a considerable number of people involved. Fred fred.l.templin@boeing.com > On Jul 9, 2012, at 5:07 PM, Templin, Fred L wrote: >=20 > > Hi Fred, > > > >> -----Original Message----- > >> From: Fred Baker (fred) [mailto:fred@cisco.com] > >> Sent: Thursday, June 28, 2012 4:21 PM > >> To: Templin, Fred L > >> Cc: v6ops@ietf.org WG; Ron Bonica > >> Subject: Re: Prep for v6ops IETF 84 agenda > >> > >> > >> On Jun 29, 2012, at 12:34 AM, Templin, Fred L wrote: > >> > >>>> -----Original Message----- > >>>> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On > Behalf > >> Of > >>>> Fred Baker (fred) > >>>> Sent: Sunday, June 24, 2012 7:05 PM > >>>> To: v6ops@ietf.org WG > >>>> Cc: Ron Bonica > >>>> Subject: [v6ops] Prep for v6ops IETF 84 agenda > >>>> > >>>> I sat down this morning to assess our agenda. Interested in working > >> group > >>>> comment. > >>> > >>> OK Fred; I'll bite. Why are you listing 'draft-generic-v6ops-tunmtu' > >>> as "#out of charter"? > >> > >> Because changes to section 4.5 of RFC 2460 ("a source node may divide > the > >> packet...") is a change to RFC 2460, and should be discussed by the > folks > >> maintaining RFC 2460. > > > > This document has now been revised to speak only to > > operational issues (and not any changes to RFC2460 > > nor any other documents): > > > > https://datatracker.ietf.org/doc/draft-generic-v6ops-tunmtu/ > > > > Please re-review and re-evaluate in terms of charter > > applicability. > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > >> Begin forwarded message: > >> > >>> From: "Fred Baker (fred)" > >>> Date: June 23, 2012 5:43:22 AM GMT+08:00 > >>> To: Fred Templin , "v6ops@ietf.org WG" > >> > >>> Subject: Re: [v6ops] new draft: draft-generic-v6ops-tunmtu > >>> > >>> Coming back to this as a meta-issue. > >>> > >>> v6ops is about operational considerations and procedures, but not > >> protocols; disputing RFC 2460, aka redesigning IPv6, seems like a > protocol > >> issue. > >>> > >>> The reason to not do inner fragmentation, if memory serves, has to do > >> with the behavior of fragmentation in the network and its effect on > >> communications. For example, suppose you and I are in 9K clean network= s > >> (so the TCP MSS starts out as 9K), my link to the public network has a= n > >> MTU of 1500, and somewhere en route to you there is another link with > an > >> MTU of 1400. When I send a 9K packet, it will become six 1500 byte > packets > >> with a small caboose that picks up the size of five IP headers (IPv4 o= r > >> IPv6), and what you will receive is six 1400 byte packets interspersed > >> with six 100+IP byte packets, followed by the original caboose. What i= f > >> the fragmenting router's queue, at the time of fragmentation, was one > >> packet short of the needed capacity? Maybe the retransmission follows = a > >> different path and is fragmented differently, resulting in funny > overlaps > >> whose handling isn't very well specified. There's nothing *incorrect* > >> about a stream of 13 packets of various sizes being reassem > >>> bled, but integrating retransmissions gets messy. IIRC, they just > wanted > >> to clean that up. > >>> > >>> Which brings me to the following consideration. > >>> > >>> If we're talking about having one tunnel endpoint put a message into = a > >> tunnel datagram and then fragment it, and have the other tunnel > endpoint > >> reassemble the original and forward it, we are talking about an > >> operational procedure that requires support in a router, but which I > can > >> correlate with section 5 of RFC 2460. > >>> > >>> One thing I would invite is discussion of operational experience with > >> RFC 4821. Wouldn't it be nice if the endpoint actually chose an MSS > based > >> on what actually worked (shades of Happy Eyeballs), rather than > depending > >> on error messages that network operators routinely filter out? > >>> > >>> If we're talking about changing the recommendation of RFC 2460 > regarding > >> who does fragmentation, that sounds like an IPv6 protocol change, and > I'd > >> like to refer that to 6MAN. > >>> > >>> Does that make sense? > >>> _______________________________________________ > >>> v6ops mailing list > >>> v6ops@ietf.org > >>> https://www.ietf.org/mailman/listinfo/v6ops > > From fred@cisco.com Tue Jul 10 08:51: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 AB61A11E8177 for ; Tue, 10 Jul 2012 08:51:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.226 X-Spam-Level: X-Spam-Status: No, score=-110.226 tagged_above=-999 required=5 tests=[AWL=-0.227, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c4tcoF8Li9FN for ; Tue, 10 Jul 2012 08:51:22 -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 3549611E816C for ; Tue, 10 Jul 2012 08:51:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=4209; q=dns/txt; s=iport; t=1341935497; x=1343145097; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=q9zEWwohrsJgvKzW3gZFavHC2bBtdXRkxi8r6FRGylQ=; b=j4b5HExGB4F1bWGXhdjthLK0TYJClsQflJmogp3oaWS4B579iss1D68I hM5DWaNAMyRhfgYkLCblpaK77nEycl/ROAlV0Jnj97yiJoZNg3PTWIfJe bTJhLgzo4QYW4CqrXy5lPKDysGerRcQQ6Pm/1bBGxvV0BW2Cv07Zr0Ytc Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAEBP/E+tJXG+/2dsb2JhbABFt3mBB4IgAQEBAwEBAQELBAEnKwkLBQsCAQg2ECcLJQIEDgUUBgiHZQYLnFWgNASLQIVCYAOVNo4fgWaCXw X-IronPort-AV: E=Sophos;i="4.77,559,1336348800"; d="scan'208";a="100450915" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-5.cisco.com with ESMTP; 10 Jul 2012 15:51:37 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q6AFpahB023864 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Jul 2012 15:51:36 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.118]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0298.004; Tue, 10 Jul 2012 10:51:36 -0500 From: "Fred Baker (fred)" To: "v6ops@ietf.org WG" Thread-Topic: [v6ops] Prep for v6ops IETF 84 agenda Thread-Index: AQHNUnbpWFu7FKUfJEyvobkjy/vWXZcjFqiA Date: Tue, 10 Jul 2012 15:51:11 +0000 Message-ID: <45F1DB32-74F6-4E4A-88E2-118B76A5F474@cisco.com> References: <8D73E1D6-A968-4397-A843-FE073197B7F1@cisco.com> In-Reply-To: <8D73E1D6-A968-4397-A843-FE073197B7F1@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.114.240] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19030.006 x-tm-as-result: No--49.013300-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: <829FCE7B18B7AB4EBCADD88C934AC8AB@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ron Bonica Subject: Re: [v6ops] Prep for v6ops IETF 84 agenda X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 10 Jul 2012 15:51:25 -0000 I have an updated list, as of the -00 cutoff yesterday. I have culled out d= rafts that have not been updated since the last meeting. The three "not clear" drafts seem to me on the hairy edge. In Fred's case, = yes, there has been list discussion. It has mostly been to tell him he's wr= ong in his approach. What little discussion has happened on draft-lopez-v6o= ps-dc-ipv6 seems to mostly point to other documents as already saying thing= s. draft-zhang-v6ops-ipv6oa-iwf is just new, and hasn't been discussed. Your thoughts on this? #no expressed interest Apr 26 20:07 draft-jiang-v6ops-v4v6mc-proxy-01.txt Mar 29 11:27 draft-donley-v6ops-ce-router-design-00.txt #out of charter May 9 19:44 draft-templin-v6ops-isops-17.txt Mar 30 19:33 draft-yang-v6ops-fast6-00.txt #in IESG or RFC Editor queues May 15 10:12 draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-06.txt May 22 05:30 draft-ietf-v6ops-ra-guard-implementation-04.txt Jul 3 02:45 draft-ietf-v6ops-ivi-icmp-address-02.txt May 29 19:10 draft-ietf-v6ops-wireline-incremental-ipv6-04.txt Jun 9 13:41 draft-ietf-v6ops-ipv6-discard-prefix-05.txt May 16 19:02 draft-ietf-v6ops-6204bis-09.txt #WGLC requested in v6ops, no news from AD on sunset4 Jul 2 20:42 draft-ietf-v6ops-464xlat-05.txt (WGLC requested by authors) #Not clear Jun 19 19:33 draft-lopez-v6ops-dc-ipv6-02.txt Jul 4 07:42 draft-generic-v6ops-tunmtu-09.txt Jun 30 03:02 draft-zhang-v6ops-ipv6oa-iwf-00.txt #For agenda Jun 29 06:37 draft-matthews-v6ops-design-guidelines-00.txt Jun 12 03:26 draft-ietf-v6ops-icp-guidance-01.txt (WGLC requested by author= s) Apr 29 21:58 draft-gundavelli-v6ops-community-wifi-svcs-04.txt Jul 4 02:18 draft-chen-v6ops-nat64-experience-02.txt On Jun 24, 2012, at 7:04 PM, Fred Baker (fred) wrote: > I sat down this morning to assess our agenda. Interested in working group= comment. >=20 > # no update > Jan 11 16:48 draft-yang-v6ops-fast6-pppoe-02.txt > Feb 21 18:10 draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-04.txt > Feb 23 07:29 draft-carpenter-v6ops-icp-guidance-03.txt > Feb 25 11:37 draft-ietf-v6ops-ivi-icmp-address-01.txt > Feb 28 08:49 draft-chkpvc-enterprise-incremental-ipv6-00.txt > Mar 5 17:46 draft-ma-v6ops-terminal-test-00.txt > Mar 7 07:33 draft-carpenter-v6ops-label-balance-02.txt > Mar 12 06:21 draft-vanrein-v6ops-6bed4-01.txt > Mar 12 17:52 draft-chen-v6ops-nat64-experience-01.txt > Mar 12 21:34 draft-liu-v6ops-ula-usage-analysis-02.txt > Mar 13 04:59 draft-sunq-v6ops-contents-transition-03.txt > Mar 30 03:27 draft-donley-v6ops-ce-router-design-00.txt > Mar 31 11:33 draft-yang-v6ops-fast6-00.txt >=20 > #no expressed interest > Jun 20 11:33 draft-lopez-v6ops-dc-ipv6-02.txt > Apr 27 12:07 draft-jiang-v6ops-v4v6mc-proxy-01.txt >=20 > #out of charter > Jun 24 07:59 draft-generic-v6ops-tunmtu-07.txt > May 10 11:44 draft-templin-v6ops-isops-17.txt >=20 > #in IESG queue > May 30 11:10 draft-ietf-v6ops-wireline-incremental-ipv6-04.txt > May 17 11:02 draft-ietf-v6ops-6204bis-09.txt >=20 >=20 > #WGLC in v6ops or move to sunset4; awaiting AD direction > May 8 10:14 draft-ietf-v6ops-464xlat-03.txt >=20 > #potential for agenda > Apr 30 13:58 draft-gundavelli-v6ops-community-wifi-svcs-04.txt > May 16 02:12 draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-06.txt > May 22 21:30 draft-ietf-v6ops-ra-guard-implementation-04.txt >=20 > #for agenda, perhaps ready for last call > Jun 12 19:26 draft-ietf-v6ops-icp-guidance-01.txt >=20 >=20 >=20 > For draft-ietf-v6ops-ivi-icmp-address, the last discussion was in April, = and we were to expect an update. If that happens, I expect to bring that to= the agenda.=20 >=20 > Lee asked about draft-chkpvc-enterprise-incremental-ipv6 on the list, but= I see no update and I wasn't clear on the list commentary, whether the ope= rators want to discuss.=20 >=20 > There is still, of course, time for folks to post -00 drafts (until 9 Jul= y); if there is list discussion of those drafts, we will include them in th= e agenda. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From Fred.L.Templin@boeing.com Tue Jul 10 08:58: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 4E66011E807F for ; Tue, 10 Jul 2012 08:58:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[AWL=-0.102, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3rS0XQDdC4ZU for ; Tue, 10 Jul 2012 08:58:40 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) by ietfa.amsl.com (Postfix) with ESMTP id 2E67221F85D7 for ; Tue, 10 Jul 2012 08:58:40 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q6AFx57n019246 for ; Tue, 10 Jul 2012 08:59:06 -0700 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [130.247.228.54]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q6AFx5fY019242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 10 Jul 2012 08:59:05 -0700 Received: from stl-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q6AFx41f031843; Tue, 10 Jul 2012 10:59:04 -0500 Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com [130.247.25.109]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q6AFx39W031749 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 10 Jul 2012 10:59:04 -0500 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-05.nw.nos.boeing.com ([130.247.25.109]) with mapi; Tue, 10 Jul 2012 08:59:03 -0700 From: "Templin, Fred L" To: "Fred Baker (fred)" , "v6ops@ietf.org WG" Date: Tue, 10 Jul 2012 08:59:02 -0700 Thread-Topic: [v6ops] Prep for v6ops IETF 84 agenda Thread-Index: AQHNUnbpWFu7FKUfJEyvobkjy/vWXZcjFqiA//+s4lA= Message-ID: References: <8D73E1D6-A968-4397-A843-FE073197B7F1@cisco.com> <45F1DB32-74F6-4E4A-88E2-118B76A5F474@cisco.com> In-Reply-To: <45F1DB32-74F6-4E4A-88E2-118B76A5F474@cisco.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: Ron Bonica Subject: Re: [v6ops] Prep for v6ops IETF 84 agenda X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 10 Jul 2012 15:58:41 -0000 Fred, > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Fred Baker (fred) > Sent: Tuesday, July 10, 2012 8:51 AM > To: v6ops@ietf.org WG > Cc: Ron Bonica > Subject: Re: [v6ops] Prep for v6ops IETF 84 agenda >=20 > I have an updated list, as of the -00 cutoff yesterday. I have culled out > drafts that have not been updated since the last meeting. >=20 > The three "not clear" drafts seem to me on the hairy edge. In Fred's case= , > yes, there has been list discussion. It has mostly been to tell him he's > wrong in his approach. That's why we have list discussion - to set things right. 'draft-generic-v6ops-tunmtu' now has things right, and should have a more solid status than "not clear". > What little discussion has happened on draft-lopez- > v6ops-dc-ipv6 seems to mostly point to other documents as already saying > things. draft-zhang-v6ops-ipv6oa-iwf is just new, and hasn't been > discussed. >=20 > Your thoughts on this? This is somewhat better, but now I need to ask why do you have 'draft-templin-v6ops-isops' as out of charter? Thanks - Fred fred.l.templin@boeing.com > #no expressed interest > Apr 26 20:07 draft-jiang-v6ops-v4v6mc-proxy-01.txt > Mar 29 11:27 draft-donley-v6ops-ce-router-design-00.txt >=20 > #out of charter > May 9 19:44 draft-templin-v6ops-isops-17.txt > Mar 30 19:33 draft-yang-v6ops-fast6-00.txt >=20 > #in IESG or RFC Editor queues > May 15 10:12 draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-06.txt > May 22 05:30 draft-ietf-v6ops-ra-guard-implementation-04.txt > Jul 3 02:45 draft-ietf-v6ops-ivi-icmp-address-02.txt > May 29 19:10 draft-ietf-v6ops-wireline-incremental-ipv6-04.txt > Jun 9 13:41 draft-ietf-v6ops-ipv6-discard-prefix-05.txt > May 16 19:02 draft-ietf-v6ops-6204bis-09.txt >=20 > #WGLC requested in v6ops, no news from AD on sunset4 > Jul 2 20:42 draft-ietf-v6ops-464xlat-05.txt (WGLC requested by authors) >=20 > #Not clear > Jun 19 19:33 draft-lopez-v6ops-dc-ipv6-02.txt > Jul 4 07:42 draft-generic-v6ops-tunmtu-09.txt > Jun 30 03:02 draft-zhang-v6ops-ipv6oa-iwf-00.txt >=20 > #For agenda > Jun 29 06:37 draft-matthews-v6ops-design-guidelines-00.txt > Jun 12 03:26 draft-ietf-v6ops-icp-guidance-01.txt (WGLC requested by > authors) > Apr 29 21:58 draft-gundavelli-v6ops-community-wifi-svcs-04.txt > Jul 4 02:18 draft-chen-v6ops-nat64-experience-02.txt >=20 > On Jun 24, 2012, at 7:04 PM, Fred Baker (fred) wrote: >=20 > > I sat down this morning to assess our agenda. Interested in working > group comment. > > > > # no update > > Jan 11 16:48 draft-yang-v6ops-fast6-pppoe-02.txt > > Feb 21 18:10 draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-04.txt > > Feb 23 07:29 draft-carpenter-v6ops-icp-guidance-03.txt > > Feb 25 11:37 draft-ietf-v6ops-ivi-icmp-address-01.txt > > Feb 28 08:49 draft-chkpvc-enterprise-incremental-ipv6-00.txt > > Mar 5 17:46 draft-ma-v6ops-terminal-test-00.txt > > Mar 7 07:33 draft-carpenter-v6ops-label-balance-02.txt > > Mar 12 06:21 draft-vanrein-v6ops-6bed4-01.txt > > Mar 12 17:52 draft-chen-v6ops-nat64-experience-01.txt > > Mar 12 21:34 draft-liu-v6ops-ula-usage-analysis-02.txt > > Mar 13 04:59 draft-sunq-v6ops-contents-transition-03.txt > > Mar 30 03:27 draft-donley-v6ops-ce-router-design-00.txt > > Mar 31 11:33 draft-yang-v6ops-fast6-00.txt > > > > #no expressed interest > > Jun 20 11:33 draft-lopez-v6ops-dc-ipv6-02.txt > > Apr 27 12:07 draft-jiang-v6ops-v4v6mc-proxy-01.txt > > > > #out of charter > > Jun 24 07:59 draft-generic-v6ops-tunmtu-07.txt > > May 10 11:44 draft-templin-v6ops-isops-17.txt > > > > #in IESG queue > > May 30 11:10 draft-ietf-v6ops-wireline-incremental-ipv6-04.txt > > May 17 11:02 draft-ietf-v6ops-6204bis-09.txt > > > > > > #WGLC in v6ops or move to sunset4; awaiting AD direction > > May 8 10:14 draft-ietf-v6ops-464xlat-03.txt > > > > #potential for agenda > > Apr 30 13:58 draft-gundavelli-v6ops-community-wifi-svcs-04.txt > > May 16 02:12 draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-06.txt > > May 22 21:30 draft-ietf-v6ops-ra-guard-implementation-04.txt > > > > #for agenda, perhaps ready for last call > > Jun 12 19:26 draft-ietf-v6ops-icp-guidance-01.txt > > > > > > > > For draft-ietf-v6ops-ivi-icmp-address, the last discussion was in April= , > and we were to expect an update. If that happens, I expect to bring that > to the agenda. > > > > Lee asked about draft-chkpvc-enterprise-incremental-ipv6 on the list, > but I see no update and I wasn't clear on the list commentary, whether th= e > operators want to discuss. > > > > There is still, of course, time for folks to post -00 drafts (until 9 > July); if there is list discussion of those drafts, we will include them > in the agenda. > > _______________________________________________ > > 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 farmer@umn.edu Tue Jul 10 09:10: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 375A411E8187 for ; Tue, 10 Jul 2012 09:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S5HIIrvR7Kyj for ; Tue, 10 Jul 2012 09:10:52 -0700 (PDT) Received: from vs-m.tc.umn.edu (vs-m.tc.umn.edu [134.84.135.97]) by ietfa.amsl.com (Postfix) with ESMTP id 5E6A011E8134 for ; Tue, 10 Jul 2012 09:10:52 -0700 (PDT) Received: from mail-yw0-f43.google.com (mail-yw0-f43.google.com [209.85.213.43]) by vs-m.tc.umn.edu (UMN smtpd) with ESMTP for ; Tue, 10 Jul 2012 11:11:14 -0500 (CDT) X-Umn-Remote-Mta: [N] mail-yw0-f43.google.com [209.85.213.43] #+LO+TR X-Umn-Classification: local Received: by mail-yw0-f43.google.com with SMTP id 10so266224yhl.16 for ; Tue, 10 Jul 2012 09:11:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=Qdjs7WTB/SMDy/cTIcWianoj7mIvD6E+X6cy6ajSsdc=; b=mDS34pQOuu+l+gf8mjYLtr/wSNvdeyHogLnKulhIN2f8NEDa+9ukJogCgnoerJYk0J c9JqhPxs1LWfor4Z670SbFfyP31tPGecQNc6ZERV69GAeHFyo2AbR45zCuv2jM+g4LuU VabMuHbNK3+GqSstOKzc4jRwGt5ESJCs4alqALDWn6nAmNmgI5VIvqTdki+lLz9GVvxK iW6jgX07Gt0eFm9/QbN4jwnqkECwLnBetbEhMHkLbeg51L7dnzw6aoEiX3QslV/MU9R1 Q6B1kRKnemTrpL2RhZTqY/glEuzpqVGpf4tDMHNIJeqxNsbMg6bznvTKlhVeOtYcBAF/ qlXA== Received: by 10.50.41.226 with SMTP id i2mr12214842igl.4.1341936674409; Tue, 10 Jul 2012 09:11:14 -0700 (PDT) Received: from oit200959392-2.local (c-24-118-200-23.hsd1.mn.comcast.net. [24.118.200.23]) by mx.google.com with ESMTPS id bj4sm11953155igc.16.2012.07.10.09.11.13 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 10 Jul 2012 09:11:13 -0700 (PDT) Message-ID: <4FFC541F.90701@umn.edu> Date: Tue, 10 Jul 2012 11:11:11 -0500 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Niall O'Reilly References: <5D36713D8A4E7348A7E10DF7437A4B9239EF7160@szxeml545-mbx.china.huawei.com> <4FFBFE58.8040408@inex.ie> <06AF4254-FAB4-496C-A894-7092451C42C0@ucd.ie> In-Reply-To: <06AF4254-FAB4-496C-A894-7092451C42C0@ucd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnstLFmeaeToKnJ+/0bbXAEszG4EmlnRDrkFZ1DKdZ9Nn0xuPnLSvCl/+kjKL1UBPc8VvzO Cc: "v6ops@ietf.org" Subject: Re: [v6ops] FW: New Version Notification for draft-jiang-semantic-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Farmer List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 16:10:53 -0000 On 7/10/12 05:14 CDT, Niall O'Reilly wrote: > > On 10 Jul 2012, at 11:05, Nick Hilliard wrote: > >> applying semantics to >> addressing has too many problems associated with it to make it practical to >> deploy (e.g. class inflexibility, renumbering if a class changes, the >> dangers of hard-coding applications to expect specific address ranges to >> behave in a particular way, etc) > > Not to mention diversity of semantic binding and untrustworthiness > of the semantic intent of other operators, just as for QoS. I suspect that semantics like this are or will be common in an enterprise environment. But the whole purpose would be local significance of the binding only. A standard binding that would meet everyone's needs would require way to many bits. So for semantics in the addressing scheme to be useful they need to be local. A draft discussing such local use of semantics might be useful, but any attempt to standardize the semantics is doomed to failure. The idea that you could use semantics like this at the ISP scale is equally doomed. Maybe a industry specific provider might be able to implement a semantic useful to a specific industry, but that is really just a group of enterprises agreeing on a semantics that make sense within the group of enterprises. There is to much variation in needs to standardize a general semantic of any real usefulness. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From v6ops@globis.net Tue Jul 10 12:48: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 1F74711E8124 for ; Tue, 10 Jul 2012 12:48:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1ah5G4M1ScF for ; Tue, 10 Jul 2012 12:48:53 -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 2C41B11E80E3 for ; Tue, 10 Jul 2012 12:48:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 285B3870082; Tue, 10 Jul 2012 21:49:19 +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 BaOf9gmlf7sW; Tue, 10 Jul 2012 21:49:14 +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 E9B84870065; Tue, 10 Jul 2012 21:49:13 +0200 (CEST) Message-ID: <4FFC8738.40502@globis.net> Date: Tue, 10 Jul 2012 21:49:12 +0200 From: Ray Hunter User-Agent: Postbox 3.0.4 (Macintosh/20120616) MIME-Version: 1.0 To: David Farmer References: <5D36713D8A4E7348A7E10DF7437A4B9239EF7160@szxeml545-mbx.china.huawei.com> <4FFBFE58.8040408@inex.ie> <06AF4254-FAB4-496C-A894-7092451C42C0@ucd.ie> <4FFC541F.90701@umn.edu> In-Reply-To: <4FFC541F.90701@umn.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] FW: New Version Notification for draft-jiang-semantic-prefix-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: Tue, 10 Jul 2012 19:48:54 -0000 +1 for David Farmer's comments. The IPv6 addressing schemes I am rolling out in enterprises include some very very limited semantics in a couple of octets of the prefix e.g. - one 4 bit nibble immediately after the fixed leftmost octets. This will be used for associating a prefix with a geographical / latency region, and thus being able to advertise the longest possible summary prefix out of a varying/growing number of Internet breakouts. - some site & LAN ID locators of varying lengths - finally, on the /64 boundary, one reserved octet for being able to associate a LAN prefix to a single DSCP / QoS/ traffic/ security class. These traffic classes will be very very limited and will only have a specific meaning within an individual enterprise e.g. mapping traffic from a LAN to one of 5 pre-defined DSCP based classes respected by all of the contracted network service providers, so they can easily perform DSCP remarking on ingress and egress. I too suspect standardisation across multiple AS's is doomed to failure. regards, David Farmer wrote: > > On 7/10/12 05:14 CDT, Niall O'Reilly wrote: >> >> On 10 Jul 2012, at 11:05, Nick Hilliard wrote: >> >>> applying semantics to >>> addressing has too many problems associated with it to make it >>> practical to >>> deploy (e.g. class inflexibility, renumbering if a class changes, the >>> dangers of hard-coding applications to expect specific address >>> ranges to >>> behave in a particular way, etc) >> >> Not to mention diversity of semantic binding and untrustworthiness >> of the semantic intent of other operators, just as for QoS. > > I suspect that semantics like this are or will be common in an > enterprise environment. But the whole purpose would be local > significance of the binding only. A standard binding that would meet > everyone's needs would require way to many bits. So for semantics in > the addressing scheme to be useful they need to be local. > > A draft discussing such local use of semantics might be useful, but > any attempt to standardize the semantics is doomed to failure. > > The idea that you could use semantics like this at the ISP scale is > equally doomed. Maybe a industry specific provider might be able to > implement a semantic useful to a specific industry, but that is really > just a group of enterprises agreeing on a semantics that make sense > within the group of enterprises. There is to much variation in needs > to standardize a general semantic of any real usefulness. > > From nick@inex.ie Tue Jul 10 14:26: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 E601911E810F for ; Tue, 10 Jul 2012 14:26:41 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JVxRFoa-a5w8 for ; Tue, 10 Jul 2012 14:26:41 -0700 (PDT) Received: from mail.acquirer.com (mail.acquirer.com [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 1903F11E810B for ; Tue, 10 Jul 2012 14:26:40 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100:6caf:7bbf:673a:c670]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id q6ALQCSD079994 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 10 Jul 2012 22:26:18 +0100 (IST) (envelope-from nick@inex.ie) Message-ID: <4FFC9E24.9070903@inex.ie> Date: Tue, 10 Jul 2012 22:27:00 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: David Farmer References: <5D36713D8A4E7348A7E10DF7437A4B9239EF7160@szxeml545-mbx.china.huawei.com> <4FFBFE58.8040408@inex.ie> <06AF4254-FAB4-496C-A894-7092451C42C0@ucd.ie> <4FFC541F.90701@umn.edu> In-Reply-To: <4FFC541F.90701@umn.edu> X-Enigmail-Version: 1.4.2 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] FW: New Version Notification for draft-jiang-semantic-prefix-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: Tue, 10 Jul 2012 21:26:42 -0000 On 10/07/2012 17:11, David Farmer wrote: > I suspect that semantics like this are or will be common in an enterprise > environment This is a part of any standard IPv6 addressing plan - everyone organisation has one, whether enterprise or service provider. But as you point out, it is completely futile to work out a generic plan of this form that attempts to please everyone. I agree that a discussion draft would be interesting. Nick From internet-drafts@ietf.org Tue Jul 10 17:02: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 07A0D11E814A; Tue, 10 Jul 2012 17:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id urpt+EF6vvZQ; Tue, 10 Jul 2012 17:02:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8142411E8087; Tue, 10 Jul 2012 17:02:11 -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.30p3 Message-ID: <20120711000211.23834.30508.idtracker@ietfa.amsl.com> Date: Tue, 10 Jul 2012 17:02:11 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-ivi-icmp-address-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: Wed, 11 Jul 2012 00:02:12 -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-03.txt Pages : 6 Date : 2012-07-10 Abstract: A stateless IPv4/IPv6 translator may receive ICMPv6 packets containing non IPv4-translatable addresses as the source that should be passed across the translator as an ICMP packet directed to the IPv4-translatable destination. This document presents recommendations for source address translation in ICMPv6 headers for 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-03 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-ivi-icmp-address-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From dwing@cisco.com Tue Jul 10 17:33: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 BF1A021F8507 for ; Tue, 10 Jul 2012 17:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.465 X-Spam-Level: X-Spam-Status: No, score=-110.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NSoXZzre8daz for ; Tue, 10 Jul 2012 17:33:05 -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 C714C21F84D9 for ; Tue, 10 Jul 2012 17:33:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1179; q=dns/txt; s=iport; t=1341966815; x=1343176415; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=kOV6sA1ogLTZkbREeiotEa3sWTlHpqn8uYz1P1PMPWU=; b=K98eed9ATJ9uY9Lmgd+ispNEHsNV1BbyjrU2OVU5eWsr8yNkmTsCdE80 /cj/KHvVVZBIyffqvOgCVKwoPoJQBhtlHvcD6i0R0PoI2jlZfdDtc61NF F7Nogx7pP68RwfAn12GeByq0VoqGIiec49GFL1mf2E4NTc9W58AyZSbSy 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAGnI/E+rRDoH/2dsb2JhbABFDqhUjx2BB4IgAQEBBAgKARcQPQINAwIJDgE3GSMSCQEBBAEdF4dqnRSgBotUhVoDiEmFBZYHgWaCJlmBNg X-IronPort-AV: E=Sophos;i="4.77,564,1336348800"; d="scan'208";a="51587031" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 11 Jul 2012 00:33:34 +0000 Received: from dwingWS ([10.21.118.211]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q6B0XYY4004065; Wed, 11 Jul 2012 00:33:34 GMT From: "Dan Wing" To: "'Ray Hunter'" , "'David Farmer'" References: <5D36713D8A4E7348A7E10DF7437A4B9239EF7160@szxeml545-mbx.china.huawei.com> <4FFBFE58.8040408@inex.ie> <06AF4254-FAB4-496C-A894-7092451C42C0@ucd.ie> <4FFC541F.90701@umn.edu> <4FFC8738.40502@globis.net> In-Reply-To: <4FFC8738.40502@globis.net> Date: Tue, 10 Jul 2012 17:33:34 -0700 Message-ID: <085f01cd5efc$cdff1bb0$69fd5310$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac1e1SCB6xCOAbfGSpejUr6tQ8pfQwAJy7qg Content-Language: en-us Cc: v6ops@ietf.org Subject: Re: [v6ops] FW: New Version Notification for draft-jiang-semantic-prefix-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: Wed, 11 Jul 2012 00:33:06 -0000 ... > - finally, on the /64 boundary, one reserved octet for being able to > associate a LAN prefix to a single DSCP / QoS/ traffic/ security class. > These traffic classes will be very very limited and will only have a > specific meaning within an individual enterprise e.g. mapping traffic > from a LAN to one of 5 pre-defined DSCP based classes respected by all > of the contracted network service providers, so they can easily perform > DSCP remarking on ingress and egress. I sure would like to understand better the details. I have seen a similar proposal, but it suffered from a problem that only dedicated-use devices could participate in that scheme. Multi-use devices (e.g., a PC, a tablet, a smartphone) will not have the smarts to acquire multiple IPv6 prefixes and have certain applications use a certain prefix (e.g., VoIP application is supposed to use a certain prefix to get certain DSCP treatment). This gets even harder if all applications are Javascript running within a web browser which is sometimes doing bittorrent, other times interactive realtime media, other times streaming video, other times filling out a web form. -d From internet-drafts@ietf.org Tue Jul 10 17:40: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 1772711E8133; Tue, 10 Jul 2012 17:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p511LUKjGzL0; Tue, 10 Jul 2012 17:40:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6507411E8107; Tue, 10 Jul 2012 17:40:26 -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.30p3 Message-ID: <20120711004026.4989.56313.idtracker@ietfa.amsl.com> Date: Tue, 10 Jul 2012 17:40:26 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-wireline-incremental-ipv6-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: Wed, 11 Jul 2012 00:40:27 -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-05.txt Pages : 28 Date : 2012-07-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-05 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-wireline-incremental-= ipv6-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jiangsheng@huawei.com Tue Jul 10 19:25: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 8F90521F852B for ; Tue, 10 Jul 2012 19:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kds-uvOTSLdI for ; Tue, 10 Jul 2012 19:25:08 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9477A21F8528 for ; Tue, 10 Jul 2012 19:25:08 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHQ52559; Tue, 10 Jul 2012 22:25:37 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 10 Jul 2012 19:22:16 -0700 Received: from SZXEML430-HUB.china.huawei.com (10.72.61.38) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 10 Jul 2012 19:22:20 -0700 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.140]) by szxeml430-hub.china.huawei.com ([10.72.61.38]) with mapi id 14.01.0323.003; Wed, 11 Jul 2012 10:22:12 +0800 From: Sheng Jiang To: Nick Hilliard Thread-Topic: [v6ops] FW: New Version Notification for draft-jiang-semantic-prefix-00.txt Thread-Index: AQHNXaP3eifIRoHPo02wGSDOlR2P6pch260ggAB2SNCAAQLcsA== Date: Wed, 11 Jul 2012 02:22:11 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B9239EF791F@szxeml545-mbx.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B9239EF7160@szxeml545-mbx.china.huawei.com> <4FFBFE58.8040408@inex.ie> <4FFC038F.40507@inex.ie> In-Reply-To: <4FFC038F.40507@inex.ie> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.31] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "v6ops@ietf.org" Subject: Re: [v6ops] FW: New Version Notification for draft-jiang-semantic-prefix-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: Wed, 11 Jul 2012 02:25:09 -0000 SGksIE5pY2ssDQoNClRoYW5rcyBmb3IgeW91ciBjb21tZW50cy4gWW91IGFyZSByaWdodCBJIHdv dWxkIGZpeCB0aGlzIGluIGxhdGVyIHZlcnNpb24uIFRoYW5rcyBmb3IgeW91ciBwb2ludCwgdG9v Lg0KDQpGcm9tIHRoZSBkYXRhLCBteSBlc3RpbWF0ZSBpcyAxNn4yMiBhcmUgZm9yIGxhcmdlIElT UHMsIHdobyBoYXZlIG1pbGxpb24gc3Vic2NyaWJlcnMuIFRoZXkgbWF5IGhhdmUgbXVsdGlwbGUg ZGlzY29udGlndW91cyBhZGRyZXNzIHNwYWNlLCBidXQgZWFjaCBvZiB0aGVtIG1heSBvbmx5IGNv dmVyIGxlc3MgdGhhbiBhIG1pbGxpb24gc3Vic2NyaWJlcnMuDQoNClNoZW5nDQoNCj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTmljayBIaWxsaWFyZCBbbWFpbHRvOm5pY2tA aW5leC5pZV0NCj4gU2VudDogVHVlc2RheSwgSnVseSAxMCwgMjAxMiA2OjI3IFBNDQo+IFRvOiBT aGVuZyBKaWFuZw0KPiBDYzogdjZvcHNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFt2Nm9wc10g Rlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCj4gZHJhZnQtamlhbmctc2VtYW50aWMt cHJlZml4LTAwLnR4dA0KPiANCj4gT24gMTAvMDcvMjAxMiAxMTowNSwgTmljayBIaWxsaWFyZCB3 cm90ZToNCj4gPiBPbiAxMC8wNy8yMDEyIDA0OjI3LCBTaGVuZyBKaWFuZyB3cm90ZToNCj4gPj4g VHlwaWNhbGx5LCBuZXR3b3JrIG9wZXJhdG9ycyB3b3VsZCBoYXZlIC8xMyB+IC8yMCBhZGRyZXNz IHNwYWNlDQo+ID4NCj4gPiBUaGUgbnVtYmVyIG9mIG9wZXJhdG9ycyB3aXRoIC8xMy0vMjAgb2Yg YWRkcmVzcyBzcGFjZSBpcyBwcm9wb3J0aW9uYWxseQ0KPiB0aW55Lg0KPiANCj4gVG8gcXVhbGlm eSB0aGlzIHN0YXRlbWVudCwgSSBwdWxsZWQgYSBjb3B5IG9mIGFsbCBpcHY2IGRlbGVnYXRpb25z IGZyb20gYWxsDQo+IDUgUklScyAoZnRwLmFyaW4ubmV0Oi9wdWIvc3RhdHMvKS4gIE91dCBvZiA4 NzAyIGlwdjYgYWxsb2NhdGlvbnMgd29ybGR3aWRlLA0KPiB0aGVyZSBhcmUgMTEgZGVsZWdhdGlv bnMgYmV0d2VlbiAvMTMgYW5kIC8yMDoNCj4gDQo+ICAgIDEgeCAvMTYNCj4gICAgMiB4IC8xOQ0K PiAgICA4IHggLzIwDQo+IA0KPiBOaWNrDQo= From jiangsheng@huawei.com Tue Jul 10 19: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 6E0AD11E80CE for ; Tue, 10 Jul 2012 19:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iUkqq5qkbKXg for ; Tue, 10 Jul 2012 19:34:22 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id C8FB111E80A1 for ; Tue, 10 Jul 2012 19:34:21 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHX49492; Tue, 10 Jul 2012 22:34:51 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 10 Jul 2012 19:32:09 -0700 Received: from SZXEML415-HUB.china.huawei.com (10.82.67.154) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 10 Jul 2012 19:32:13 -0700 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.140]) by szxeml415-hub.china.huawei.com ([10.82.67.154]) with mapi id 14.01.0323.003; Wed, 11 Jul 2012 10:32:09 +0800 From: Sheng Jiang To: Nick Hilliard Thread-Topic: [v6ops] FW: New Version Notification for draft-jiang-semantic-prefix-00.txt Thread-Index: AQHNXaP3eifIRoHPo02wGSDOlR2P6pch260g///p6wCAAY8TgA== Date: Wed, 11 Jul 2012 02:32:08 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B9239EF792F@szxeml545-mbx.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B9239EF7160@szxeml545-mbx.china.huawei.com> <4FFBFE58.8040408@inex.ie> In-Reply-To: <4FFBFE58.8040408@inex.ie> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.31] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "v6ops@ietf.org" Subject: Re: [v6ops] FW: New Version Notification for draft-jiang-semantic-prefix-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: Wed, 11 Jul 2012 02:34:22 -0000 PiAyLiBoYXJkY29kaW5nOg0KPiANCj4gPiAgICBJbiBwcmFjdGljZSwgYSBob3N0IG1heSBiZWxv bmcgdG8gc2V2ZXJhbCBzZW1hbnRpY3MuIEl0IG1lYW5zIHNldmVyYWwNCj4gPiAgICBJUHY2IGFk ZHJlc3NlcyBhcmUgYXZhaWxhYmxlIG9uIGEgc2luZ2xlIHBoeXNpY2FsIGludGVyZmFjZS4gQQ0K PiA+ICAgIGNlcnRhaW4gcGFja2V0IHdvdWxkIG9ubHkgc2VydmUgYSBjZXJ0YWluIHNlbWFudGlj LiBUaGUgc3RhY2sgb3INCj4gPiAgICBhcHBsaWNhdGlvbnMgb24gdGhhdCBob3N0IG11c3Qga25v dyBhbmQgdW5kZXJzdGFuZCB0aGVzZSBzZW1hbnRpY3MNCj4gPiAgICBhbmQgaXRzIGNvcnJlc3Bv bmRlbnQgYml0cyBpbiBvcmRlciB0byBjaG9vc2UgcmlnaHQgc291cmNlIGFkZHJlc3MNCj4gPiAg ICB3aGVuIGZvcm1pbmcgYSBwYWNrZXQuDQo+IA0KPiBJJ20gbm90IHN1cmUgdGhhdCBoYXJkY29k aW5nIHNlbWFudGljcyBsaWtlIHRoaXMgaW50byBhbiBlbmQtdXNlcg0KPiBhcHBsaWNhdGlvbiBp cyBhIGdvb2QgaWRlYS4gIEluIGZhY3QsIEknbSBwcmV0dHkgc3VyZSBpdCBpc24ndC4NCj4gDQo+ IEhhcmQtY29kaW5nIHNlbWFudGljcyBpbnRvIGFkZHJlc3Npbmcgc3RydWN0dXJlcyBpcyBhbiBp ZGVhIHRoYXQgY3JvcHMgdXANCj4gZnJvbSB0aW1lIHRvIHRpbWUgaW4gZGlmZmVyZW50IGd1aXNl cywgYW5kIGl0IGFsd2F5cyB0dXJucyBvdXQgdG8gYmUgYSBCYWQNCj4gSWRlYSAoZS5nLiByZmMg MjA3MywgcmZjIDIzNzQsIGV0YykuICBXaGVyZWFzIEkgbGlrZSB0aGUgaWRlYSBvZiBiZWluZyBh YmxlDQo+IHRvIGRldGVybWluaXN0aWNhbGx5IHRhZyB0cmFmZmljIG9uIGluZ3Jlc3MsIGFwcGx5 aW5nIHNlbWFudGljcyB0bw0KPiBhZGRyZXNzaW5nIGhhcyB0b28gbWFueSBwcm9ibGVtcyBhc3Nv Y2lhdGVkIHdpdGggaXQgdG8gbWFrZSBpdCBwcmFjdGljYWwgdG8NCj4gZGVwbG95IChlLmcuIGNs YXNzIGluZmxleGliaWxpdHksIHJlbnVtYmVyaW5nIGlmIGEgY2xhc3MgY2hhbmdlcywgdGhlDQo+ IGRhbmdlcnMgb2YgaGFyZC1jb2RpbmcgYXBwbGljYXRpb25zIHRvIGV4cGVjdCBzcGVjaWZpYyBh ZGRyZXNzIHJhbmdlcyB0bw0KPiBiZWhhdmUgaW4gYSBwYXJ0aWN1bGFyIHdheSwgZXRjKSBhcHBs aWNhdGlvbg0KDQpIaSwgTmljaywNCg0KSSBndWVzcyB5b3VyIG1pc3VuZGVyc3RhbmRpbmcgd2hh dCBJIG1lYW4gaGVyZS4gSSBkaWQgTk9UIG1lYW4gaGFyZGNvZGluZyBhZGRyZXNzIGluIGFwcGxp Y2F0aW9uIGF0IGFsbC4gSSBhbSBmdWxseSBhZ3JlZSBoYXJkY29kaW5nIHNlbWFudGljcyBpbnRv IGFuIGVuZC11c2VyIGFwcGxpY2F0aW9uIGlzIGEgYmFkIGlkZWEuIFdoYXQgSSBtZWFuIHdhcyBh cHBsaWNhdGlvbnMgaW50ZXJ2ZW5lIGNob29zaW5nIG9mIHNvdXJjZSBhZGRyZXNzLCBsaWtlIFJG QzUwMTQsICJJUHY2IFNvY2tldCBBUEkgZm9yIFNvdXJjZSBBZGRyZXNzIFNlbGVjdGlvbiIuIFRo ZSBob3N0IElwdjYgc3RhY2sgcmVwb3J0IHRvIEFQUCB0aHJvdWdoIHNvY2tldCBBUEksIHRoZXJl IGFyZSBtdWx0aXBsZSBhdmFpbGFibGUgc291cmNlIGFkZHIuIFRoZW4gQVBQIHJlc3BvbnNlcyB0 byBzYXkgdXNlIGFkZHIgQSBiZWNhdXNlIGl0IGhhcyBteSBzZW1hbnRpYy4NCg0KU2hlbmcNCg0K PiBOaWNrDQo= From jmh@joelhalpern.com Tue Jul 10 19:38: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 3137421F85A5 for ; Tue, 10 Jul 2012 19:38:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.083 X-Spam-Level: X-Spam-Status: No, score=-102.083 tagged_above=-999 required=5 tests=[AWL=-0.418, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cuqxZMD-z9JJ for ; Tue, 10 Jul 2012 19:38:27 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id AFDB821F85A4 for ; Tue, 10 Jul 2012 19:38:27 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 2ACAF557FF6 for ; Tue, 10 Jul 2012 19:38:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 1D0F7102C57 for ; Tue, 10 Jul 2012 19:38:55 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.10.10.105] (pool-71-161-51-33.clppva.btas.verizon.net [71.161.51.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 92C0D102C56 for ; Tue, 10 Jul 2012 19:38:54 -0700 (PDT) Message-ID: <4FFCE725.1040003@joelhalpern.com> Date: Tue, 10 Jul 2012 22:38:29 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: v6ops@ietf.org References: <5D36713D8A4E7348A7E10DF7437A4B9239EF7160@szxeml545-mbx.china.huawei.com> <4FFBFE58.8040408@inex.ie> <06AF4254-FAB4-496C-A894-7092451C42C0@ucd.ie> <4FFC541F.90701@umn.edu> <4FFC8738.40502@globis.net> <085f01cd5efc$cdff1bb0$69fd5310$@com> In-Reply-To: <085f01cd5efc$cdff1bb0$69fd5310$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] FW: New Version Notification for draft-jiang-semantic-prefix-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: Wed, 11 Jul 2012 02:38:28 -0000 I would not several additional complications: 1) We have bits in the header for this sort of information. Why would you duplicate it into the address? 2) Many folks have concluded that one of the significant complications in IP is that our addresses overload both identity and location. This proposal further overloads the "who" and "where" with a "how". Adding more distinct semantics to the same field does not seem like a good idea at all. And, as Dan points out, this assumes that the hosts can select the correct address for the correct use. That seems extremely unlikely. Overall, putting traffic handling semantics (how) into the IP address seems to me to be a very bad idea. (Yes, I have seen proposals from operators to do so. The proposal assumed that the operational support systems would magically make the right things happen in all the right places. The proposal also seriously under-estimated the address assignment and filtering complexity.) Yours, Joel M. Halpern On 7/10/2012 8:33 PM, Dan Wing wrote: > ... >> - finally, on the /64 boundary, one reserved octet for being able to >> associate a LAN prefix to a single DSCP / QoS/ traffic/ security class. >> These traffic classes will be very very limited and will only have a >> specific meaning within an individual enterprise e.g. mapping traffic >> from a LAN to one of 5 pre-defined DSCP based classes respected by all >> of the contracted network service providers, so they can easily perform >> DSCP remarking on ingress and egress. > > I sure would like to understand better the details. > > I have seen a similar proposal, but it suffered from a problem that only > dedicated-use devices could participate in that scheme. Multi-use > devices (e.g., a PC, a tablet, a smartphone) will not have the > smarts to acquire multiple IPv6 prefixes and have certain applications > use a certain prefix (e.g., VoIP application is supposed to use > a certain prefix to get certain DSCP treatment). This gets even > harder if all applications are Javascript running within a web > browser which is sometimes doing bittorrent, other times interactive > realtime media, other times streaming video, other times filling > out a web form. > > -d > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From jiangsheng@huawei.com Tue Jul 10 19:52: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 BF18211E8079 for ; Tue, 10 Jul 2012 19:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.256 X-Spam-Level: X-Spam-Status: No, score=-6.256 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SYifJ-nuBEcn for ; Tue, 10 Jul 2012 19:52:51 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 11CC111E80E0 for ; Tue, 10 Jul 2012 19:52:51 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHX50365; Tue, 10 Jul 2012 22:53:20 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 10 Jul 2012 19:51:41 -0700 Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 10 Jul 2012 19:51:40 -0700 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.140]) by szxeml409-hub.china.huawei.com ([10.82.67.136]) with mapi id 14.01.0323.003; Wed, 11 Jul 2012 10:51:32 +0800 From: Sheng Jiang To: David Farmer , Niall O'Reilly Thread-Topic: [v6ops] FW: New Version Notification for draft-jiang-semantic-prefix-00.txt Thread-Index: AQHNXrauLAbyfZ7QXE2Mxdngs8+d7pcjXf4A Date: Wed, 11 Jul 2012 02:51:32 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B9239EF7959@szxeml545-mbx.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B9239EF7160@szxeml545-mbx.china.huawei.com> <4FFBFE58.8040408@inex.ie> <06AF4254-FAB4-496C-A894-7092451C42C0@ucd.ie> <4FFC541F.90701@umn.edu> In-Reply-To: <4FFC541F.90701@umn.edu> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.31] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "v6ops@ietf.org" Subject: Re: [v6ops] FW: New Version Notification for draft-jiang-semantic-prefix-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: Wed, 11 Jul 2012 02:52:51 -0000 PiA+PiBhcHBseWluZyBzZW1hbnRpY3MgdG8NCj4gPj4gYWRkcmVzc2luZyBoYXMgdG9vIG1hbnkg cHJvYmxlbXMgYXNzb2NpYXRlZCB3aXRoIGl0IHRvIG1ha2UgaXQgcHJhY3RpY2FsDQo+IHRvDQo+ ID4+IGRlcGxveSAoZS5nLiBjbGFzcyBpbmZsZXhpYmlsaXR5LCByZW51bWJlcmluZyBpZiBhIGNs YXNzIGNoYW5nZXMsIHRoZQ0KPiA+PiBkYW5nZXJzIG9mIGhhcmQtY29kaW5nIGFwcGxpY2F0aW9u cyB0byBleHBlY3Qgc3BlY2lmaWMgYWRkcmVzcyByYW5nZXMgdG8NCj4gPj4gYmVoYXZlIGluIGEg cGFydGljdWxhciB3YXksIGV0YykNCj4gPg0KPiA+IAlOb3QgdG8gbWVudGlvbiBkaXZlcnNpdHkg b2Ygc2VtYW50aWMgYmluZGluZyBhbmQgdW50cnVzdHdvcnRoaW5lc3MNCj4gPiAJb2YgdGhlIHNl bWFudGljIGludGVudCBvZiBvdGhlciBvcGVyYXRvcnMsIGp1c3QgYXMgZm9yIFFvUy4NCj4gDQo+ IEkgc3VzcGVjdCB0aGF0IHNlbWFudGljcyBsaWtlIHRoaXMgYXJlIG9yIHdpbGwgYmUgY29tbW9u IGluIGFuDQo+IGVudGVycHJpc2UgZW52aXJvbm1lbnQuICBCdXQgdGhlIHdob2xlIHB1cnBvc2Ug d291bGQgYmUgbG9jYWwNCj4gc2lnbmlmaWNhbmNlIG9mIHRoZSBiaW5kaW5nIG9ubHkuICBBIHN0 YW5kYXJkIGJpbmRpbmcgdGhhdCB3b3VsZCBtZWV0DQo+IGV2ZXJ5b25lJ3MgbmVlZHMgd291bGQg cmVxdWlyZSB3YXkgdG8gbWFueSBiaXRzLiAgU28gZm9yIHNlbWFudGljcyBpbg0KPiB0aGUgYWRk cmVzc2luZyBzY2hlbWUgdG8gYmUgdXNlZnVsIHRoZXkgbmVlZCB0byBiZSBsb2NhbC4NCj4gDQo+ IEEgZHJhZnQgZGlzY3Vzc2luZyBzdWNoIGxvY2FsIHVzZSBvZiBzZW1hbnRpY3MgbWlnaHQgYmUg dXNlZnVsLCBidXQgYW55DQo+IGF0dGVtcHQgdG8gc3RhbmRhcmRpemUgdGhlIHNlbWFudGljcyBp cyBkb29tZWQgdG8gZmFpbHVyZS4NCg0KSGksIERhdmlkLA0KDQpZb3VyIGNvbW1lbnRzIGFyZSBl eGFjdGx5IG15IHB1cnBvc2UuIE5vdGUgbXkgZHJhZnQgaGFzIEluZm9ybWF0aW9uYWwgaW50ZW5k ZWQgc3RhdHVzLg0KDQpBcyBJIGhhdmUgZGVmaW5lZCBhIHRlcm0gIlRoZSBTZW1hbnRpYyBQcmVm aXggRG9tYWluIi4gQW55IHNlbWFudGljIHdvdWxkIG9ubHkgbWVhbmluZ2Z1bCBpbiB0aGF0IGRv bWFpbiBMT0NBTExZLCB1bmxlc3MgdGhlcmUgYXJlIHNlbWFudGljcyBhZ3JlZW1lbnRzIGJldHdl ZW4gdHdvIGRvbWFpbnMuDQoNCkkgaGF2ZSBOTyBpbnRlbnRpb24gYW5kIHRoaW5rIHdlIHNob3Vs ZCBOT1QgdG8gc3RhbmRhcmRpemUgYW55IGNvbW1vbiBzZW1hbnRpY3MuDQoNCj4gVGhlIGlkZWEg dGhhdCB5b3UgY291bGQgdXNlIHNlbWFudGljcyBsaWtlIHRoaXMgYXQgdGhlIElTUCBzY2FsZSBp cw0KPiBlcXVhbGx5IGRvb21lZC4gIE1heWJlIGEgaW5kdXN0cnkgc3BlY2lmaWMgcHJvdmlkZXIg bWlnaHQgYmUgYWJsZSB0bw0KPiBpbXBsZW1lbnQgYSBzZW1hbnRpYyB1c2VmdWwgdG8gYSBzcGVj aWZpYyBpbmR1c3RyeSwgYnV0IHRoYXQgaXMgcmVhbGx5DQo+IGp1c3QgYSBncm91cCBvZiBlbnRl cnByaXNlcyBhZ3JlZWluZyBvbiBhIHNlbWFudGljcyB0aGF0IG1ha2Ugc2Vuc2UNCj4gd2l0aGlu IHRoZSBncm91cCBvZiBlbnRlcnByaXNlcy4gIFRoZXJlIGlzIHRvIG11Y2ggdmFyaWF0aW9uIGlu IG5lZWRzIHRvDQo+IHN0YW5kYXJkaXplIGEgZ2VuZXJhbCBzZW1hbnRpYyBvZiBhbnkgcmVhbCB1 c2VmdWxuZXNzLg0KDQpJIGRvIGFncmVlIGVudGVycHJpc2UgbmV0d29yayB3b3VsZCBiZSBiZW5l Zml0IGJ5IGFwcGx5aW5nIHNlbWFudGljIHByZWZpeC4gSSBhbGwgdGhpbmsgSVNQIGNhbiBnZXQg YmVuZWZpdCBhcyB3ZWxsLiBUaGUgcHJlY29uZGl0aW9uIGlzIHRoYXQgSVNQcyBzZWxmLXJlc3Ry aWN0ZSBOT1QgdG8gcHV0IHRvbyBtYW55IHNlbWFudGljIGludG8gcHJlZml4LiBJZiB0aGV5IG9u bHkgZW1iZWRkZWQgdGhlIG1vc3QgaW1wb3J0YW50IHNlbWFudGljcywgdGhleSBtYXkgYXZvaWQg dHJhcCB0aGVtc2VsdmVzIGludG8gdmVyeSBjb21wbGljYXRlZCBtYW5hZ2VtZW50IGlzc3Vlcy4N Cg0KRGlmZmVyZW50IElTUHMgbWF5IGhhdmUgdmVyeSBkaWZmZXJlbnQgY2hvb3NlIGZvciB0aGUg bW9zdCBpbXBvcnRhbnQgc2VtYW50aWNzLiBUaGVyZWZvcmUsIHN0YW5kYXJkaXppbmcgYSBnZW5l cmFsIHNlbWFudGljIGlzIGFsbW9zdCBhbiBpbXBvc3NpYmxlIGpvYi4NCg0KU2hlbmcNCg0KPiAt LQ0KPiA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KPiBE YXZpZCBGYXJtZXIgICAgICAgICAgICAgICBFbWFpbDpmYXJtZXJAdW1uLmVkdQ0KPiBOZXR3b3Jr aW5nICYgVGVsZWNvbW11bmljYXRpb24gU2VydmljZXMNCj4gT2ZmaWNlIG9mIEluZm9ybWF0aW9u IFRlY2hub2xvZ3kNCj4gVW5pdmVyc2l0eSBvZiBNaW5uZXNvdGENCj4gMjIxOCBVbml2ZXJzaXR5 IEF2ZSBTRQkgICAgUGhvbmU6IDYxMi02MjYtMDgxNQ0KPiBNaW5uZWFwb2xpcywgTU4gNTU0MTQt MzAyOSAgIENlbGw6IDYxMi04MTItOTk1Mg0KPiA9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PQ0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+IHY2b3BzIG1haWxpbmcgbGlzdA0KPiB2Nm9wc0BpZXRm Lm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo= From jiangsheng@huawei.com Tue Jul 10 20:31: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 C001E11E8079 for ; Tue, 10 Jul 2012 20:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.224 X-Spam-Level: X-Spam-Status: No, score=-6.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1cnmyyImHg4D for ; Tue, 10 Jul 2012 20:31:28 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id B5E5021F85B6 for ; Tue, 10 Jul 2012 20:31:28 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHQ56132; Tue, 10 Jul 2012 23:31:58 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 10 Jul 2012 20:28:40 -0700 Received: from SZXEML436-HUB.china.huawei.com (10.72.61.64) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 10 Jul 2012 20:28:43 -0700 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.140]) by szxeml436-hub.china.huawei.com ([10.72.61.64]) with mapi id 14.01.0323.003; Wed, 11 Jul 2012 11:28:37 +0800 From: Sheng Jiang To: "Joel M. Halpern" , "v6ops@ietf.org" Thread-Topic: [v6ops] FW: New Version Notification for draft-jiang-semantic-prefix-00.txt Thread-Index: AQHNXvzcKDTl3PRA4Eum8U3O2TzDVZci2GyAgACPnVA= Date: Wed, 11 Jul 2012 03:28:34 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B9239EF79F5@szxeml545-mbx.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B9239EF7160@szxeml545-mbx.china.huawei.com> <4FFBFE58.8040408@inex.ie> <06AF4254-FAB4-496C-A894-7092451C42C0@ucd.ie> <4FFC541F.90701@umn.edu> <4FFC8738.40502@globis.net> <085f01cd5efc$cdff1bb0$69fd5310$@com> <4FFCE725.1040003@joelhalpern.com> In-Reply-To: <4FFCE725.1040003@joelhalpern.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.31] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [v6ops] FW: New Version Notification for draft-jiang-semantic-prefix-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: Wed, 11 Jul 2012 03:31:29 -0000 PiBJIHdvdWxkIG5vdCBzZXZlcmFsIGFkZGl0aW9uYWwgY29tcGxpY2F0aW9uczoNCj4gMSkgV2Ug aGF2ZSBiaXRzIGluIHRoZSBoZWFkZXIgZm9yIHRoaXMgc29ydCBvZiBpbmZvcm1hdGlvbi4gIFdo eSB3b3VsZA0KPiB5b3UgZHVwbGljYXRlIGl0IGludG8gdGhlIGFkZHJlc3M/DQoNClRoZSBEaWZm U2VydiBmaWVsZHMgc2V0IGJ5IHRoZSBwYWNrZXQgc2VuZGVycyBhcmUgbm90IHRydXN0YWJsZSBi eSB0aGUgbmV0d29yayBvcGVyYXRvcnMuIEluIHRoZSByZWFsIHVzZXIgY2FzZSwgSVNQcyBkZXBs b3kgInJlbWFya2luZyIgcG9pbnRzIGF0IHRoZSBlZGdlIG5ldHdvcmssIHdoaWNoIGNsYXNzaWZ5 IGVhY2ggcmVjZWl2ZWQgcGFja2V0IGFuZCByZXdyaXRlIGl0cyBEaWZmU2VydiBmaWVsZCBhY2Nv cmRpbmcgdG8gdXNlciBpbmZvcm1hdGlvbiBsZWFybmVkIGZyb20gQUFBIG9yIFZMQU4uDQoNCj4g MikgTWFueSBmb2xrcyBoYXZlIGNvbmNsdWRlZCB0aGF0IG9uZSBvZiB0aGUgc2lnbmlmaWNhbnQg Y29tcGxpY2F0aW9ucw0KPiBpbiBJUCBpcyB0aGF0IG91ciBhZGRyZXNzZXMgb3ZlcmxvYWQgYm90 aCBpZGVudGl0eSBhbmQgbG9jYXRpb24uICBUaGlzDQo+IHByb3Bvc2FsIGZ1cnRoZXIgb3Zlcmxv YWRzIHRoZSAid2hvIiBhbmQgIndoZXJlIiB3aXRoIGEgImhvdyIuICBBZGRpbmcNCj4gbW9yZSBk aXN0aW5jdCBzZW1hbnRpY3MgdG8gdGhlIHNhbWUgZmllbGQgZG9lcyBub3Qgc2VlbSBsaWtlIGEg Z29vZCBpZGVhDQo+IGF0IGFsbC4NCg0KSSBrbm93IHRoZSByb3V0aW5nIHNjYWxhYmlsaXR5IGRp c2N1c3Npb24gYW5kIGludm9sdmVkIGluIHNldmVyYWwgSUQvTG9jYXRvciBzZXBhcmF0aW9uIHJl c2VhcmNoLiBCdXQsIG1vc3Qgb2YgaXNzdWVzIGFyZSBpbiBJUHY0IGVyYS4NCg0KSSBkb24ndCB0 aGluayB0aGUgc2VtYW50aWMgaXMgImhvdyIuIEl0IGlzIG1vcmUgY2xvc2UgdG8gYSBkZXRhaWxl ZCAid2hvIi4NCg0KPiBBbmQsIGFzIERhbiBwb2ludHMgb3V0LCB0aGlzIGFzc3VtZXMgdGhhdCB0 aGUgaG9zdHMgY2FuIHNlbGVjdCB0aGUNCj4gY29ycmVjdCBhZGRyZXNzIGZvciB0aGUgY29ycmVj dCB1c2UuICBUaGF0IHNlZW1zIGV4dHJlbWVseSB1bmxpa2VseS4NCg0KVGhpcyBpcyBvbmUgb2Yg Z2FwcyBJIGlkZW50aWZpZWQgaW4gdGhlIHNlY3Rpb24gNy4gU28sIEkgYWdyZWUgZm9yIG5vdy4g QnV0IHRlY2hub2xvZ2llcyBhcmUgZGV2ZWxvcGluZyBmb3J3YXJkcy4NCg0KVGhlIHNpbXBsZXN0 IG1vZGVsIG9mIHNlbWFudGljIHByZWZpeCBpcyBvbmx5IGVtYmVkZGVkIGFic3RyYWN0ZWQgdXNl ciB0eXBlIHNlbWFudGljIGludG8gdGhlIHByZWZpeC4gSXQgY2FuIGJlIHN1cHBvcnRlZCB3aXRo IHRoZSBjdXJyZW50IG5ldHdvcmsgYXJjaGl0ZWN0dXJlIGJlY2F1c2UgZWFjaCBzdWJzY3JpYmUg c3RpbGwgYXNzaWduZWQgb25lIHByZWZpeCwgd2hpbGUgdGhleSBhcmUgbm90IG5vdGlmaWVkIHRo ZSBzZW1hbnRpYyB3aXRoaW4gaXQNCg0KPiBPdmVyYWxsLCBwdXR0aW5nIHRyYWZmaWMgaGFuZGxp bmcgc2VtYW50aWNzIChob3cpIGludG8gdGhlIElQIGFkZHJlc3MNCj4gc2VlbXMgdG8gbWUgdG8g YmUgYSB2ZXJ5IGJhZCBpZGVhLiAgKFllcywgSSBoYXZlIHNlZW4gcHJvcG9zYWxzIGZyb20NCj4g b3BlcmF0b3JzIHRvIGRvIHNvLiAgVGhlIHByb3Bvc2FsIGFzc3VtZWQgdGhhdCB0aGUgb3BlcmF0 aW9uYWwgc3VwcG9ydA0KPiBzeXN0ZW1zIHdvdWxkIG1hZ2ljYWxseSBtYWtlIHRoZSByaWdodCB0 aGluZ3MgaGFwcGVuIGluIGFsbCB0aGUgcmlnaHQNCj4gcGxhY2VzLiAgVGhlIHByb3Bvc2FsIGFs c28gc2VyaW91c2x5IHVuZGVyLWVzdGltYXRlZCB0aGUgYWRkcmVzcw0KPiBhc3NpZ25tZW50IGFu ZCBmaWx0ZXJpbmcgY29tcGxleGl0eS4pDQoNCkkgYWdyZWUgd2l0aCB5b3Ugb3BlcmF0b3JzIGFy ZSB1bmRlci1lc3RpbWF0ZWQgdGhlIHRlY2huaWNhbCBnYXBzLiBBcyBJIHN0YXRlIGluIHNlY3Rp b24gNzogIlRoZSBtb3JlIHNlbWFudGljcyBlbWJlZGRlZCBpbnRvIHByZWZpeCwgdGhlIG1vcmUg Y29tcGxpY2F0ZWQgZnVuY3Rpb25zIGFyZSBuZWVkZWQgZm9yIHByZWZpeCBkZWxlZ2F0aW9uLCBo b3N0IG5vdGlmaWNhdGlvbiBhbmQgYWRkcmVzcyBzZWxlY3Rpb25zLiIgV2hhdCdzIG9uZSBvZiB0 aGUgcmVhc29uIEkgd3JvdGUgdGhpcyBkcmFmdCAtIHRvIGlkZW50aWZ5IHRoZSB0ZWNobmljYWwg Z2Fwcy4gVGhlbiwgb3BlcmF0b3JzIG5lZWQgdG8gbWFrZSBjaG9vc2UsIGVpdGhlciByZXRyZWF0 IHRvIHNpbXBsZSBzZW1hbnRpYyAob3Igbm8gc2VtYW50aWMpLCBvciBwdXQgZWZmb3J0cyB0byBm aWxsIHRoZXNlIHRlY2huaWNhbCBnYXBzLg0KDQpTaGVuZw0KDQo+IFlvdXJzLA0KPiBKb2VsIE0u IEhhbHBlcm4NCj4gDQo+IE9uIDcvMTAvMjAxMiA4OjMzIFBNLCBEYW4gV2luZyB3cm90ZToNCj4g PiAuLi4NCj4gPj4gLSBmaW5hbGx5LCBvbiB0aGUgLzY0IGJvdW5kYXJ5LCBvbmUgcmVzZXJ2ZWQg b2N0ZXQgZm9yIGJlaW5nIGFibGUgdG8NCj4gPj4gYXNzb2NpYXRlIGEgTEFOIHByZWZpeCB0byBh IHNpbmdsZSBEU0NQIC8gUW9TLyB0cmFmZmljLyBzZWN1cml0eSBjbGFzcy4NCj4gPj4gVGhlc2Ug dHJhZmZpYyBjbGFzc2VzIHdpbGwgYmUgdmVyeSB2ZXJ5IGxpbWl0ZWQgYW5kIHdpbGwgb25seSBo YXZlIGENCj4gPj4gc3BlY2lmaWMgbWVhbmluZyB3aXRoaW4gYW4gaW5kaXZpZHVhbCBlbnRlcnBy aXNlIGUuZy4gbWFwcGluZyB0cmFmZmljDQo+ID4+IGZyb20gYSBMQU4gdG8gb25lIG9mIDUgcHJl LWRlZmluZWQgRFNDUCBiYXNlZCBjbGFzc2VzIHJlc3BlY3RlZCBieSBhbGwNCj4gPj4gb2YgdGhl IGNvbnRyYWN0ZWQgbmV0d29yayBzZXJ2aWNlIHByb3ZpZGVycywgc28gdGhleSBjYW4gZWFzaWx5 IHBlcmZvcm0NCj4gPj4gRFNDUCByZW1hcmtpbmcgb24gaW5ncmVzcyBhbmQgZWdyZXNzLg0KPiA+ DQo+ID4gSSBzdXJlIHdvdWxkIGxpa2UgdG8gdW5kZXJzdGFuZCBiZXR0ZXIgdGhlIGRldGFpbHMu DQo+ID4NCj4gPiBJIGhhdmUgc2VlbiBhIHNpbWlsYXIgcHJvcG9zYWwsIGJ1dCBpdCBzdWZmZXJl ZCBmcm9tIGEgcHJvYmxlbSB0aGF0IG9ubHkNCj4gPiBkZWRpY2F0ZWQtdXNlIGRldmljZXMgY291 bGQgcGFydGljaXBhdGUgaW4gdGhhdCBzY2hlbWUuICBNdWx0aS11c2UNCj4gPiBkZXZpY2VzIChl LmcuLCBhIFBDLCBhIHRhYmxldCwgYSBzbWFydHBob25lKSB3aWxsIG5vdCBoYXZlIHRoZQ0KPiA+ IHNtYXJ0cyB0byBhY3F1aXJlIG11bHRpcGxlIElQdjYgcHJlZml4ZXMgYW5kIGhhdmUgY2VydGFp biBhcHBsaWNhdGlvbnMNCj4gPiB1c2UgYSBjZXJ0YWluIHByZWZpeCAoZS5nLiwgVm9JUCBhcHBs aWNhdGlvbiBpcyBzdXBwb3NlZCB0byB1c2UNCj4gPiBhIGNlcnRhaW4gcHJlZml4IHRvIGdldCBj ZXJ0YWluIERTQ1AgdHJlYXRtZW50KS4gIFRoaXMgZ2V0cyBldmVuDQo+ID4gaGFyZGVyIGlmIGFs bCBhcHBsaWNhdGlvbnMgYXJlIEphdmFzY3JpcHQgcnVubmluZyB3aXRoaW4gYSB3ZWINCj4gPiBi cm93c2VyIHdoaWNoIGlzIHNvbWV0aW1lcyBkb2luZyBiaXR0b3JyZW50LCBvdGhlciB0aW1lcyBp bnRlcmFjdGl2ZQ0KPiA+IHJlYWx0aW1lIG1lZGlhLCBvdGhlciB0aW1lcyBzdHJlYW1pbmcgdmlk ZW8sIG90aGVyIHRpbWVzIGZpbGxpbmcNCj4gPiBvdXQgYSB3ZWIgZm9ybS4NCj4gPg0KPiA+IC1k DQo+ID4NCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+ID4gdjZvcHMgbWFpbGluZyBsaXN0DQo+ID4gdjZvcHNAaWV0Zi5vcmcNCj4gPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo+ID4NCj4gDQo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHY2b3BzIG1h aWxpbmcgbGlzdA0KPiB2Nm9wc0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3Y2b3BzDQo= From v6ops@globis.net Tue Jul 10 23:07: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 C65A721F8555 for ; Tue, 10 Jul 2012 23:07: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_74=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ZI+bLvxUZwR for ; Tue, 10 Jul 2012 23:07:44 -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 D8C4A21F8518 for ; Tue, 10 Jul 2012 23:07:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 0F56B8700CA; Wed, 11 Jul 2012 08:08:12 +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 cWXIcgktpx3e; Wed, 11 Jul 2012 08:08:04 +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 F37E0870046; Wed, 11 Jul 2012 08:08:03 +0200 (CEST) Message-ID: <4FFD1842.2090509@globis.net> Date: Wed, 11 Jul 2012 08:08:02 +0200 From: Ray Hunter User-Agent: Postbox 3.0.4 (Macintosh/20120616) MIME-Version: 1.0 To: Dan Wing References: <5D36713D8A4E7348A7E10DF7437A4B9239EF7160@szxeml545-mbx.china.huawei.com> <4FFBFE58.8040408@inex.ie> <06AF4254-FAB4-496C-A894-7092451C42C0@ucd.ie> <4FFC541F.90701@umn.edu> <4FFC8738.40502@globis.net> <085f01cd5efc$cdff1bb0$69fd5310$@com> In-Reply-To: <085f01cd5efc$cdff1bb0$69fd5310$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] FW: New Version Notification for draft-jiang-semantic-prefix-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: Wed, 11 Jul 2012 06:07:44 -0000 You are correct Dan: this is not my finest and most portable idea, but here's the gory details since you asked. Apps will eventually have to set their own QoS at the host level. But there's no universal mechanism to do this. DSCP only has local significance. So if you contract 4 or 5 MPLS providers (not unusual in a multi-sourcing strategy for a large geographically dispersed enterprise) you are almost certain to have 4 or 5 different DSCP mappings with 4 or 5 different semantics. Highly mobile nodes & BYOD quite simply cannot cope with this, as there's no network to end device signalling for QoS AFAIK. About the best you can hope for out of the shrink wrap is that EF = voice. Sometimes. Today we map apps to DSCP based on IPv4 extended access lists + class-maps + DSCP rewriting. That then feeds into CBWFQ + DSCP aware WRED. Standard fare really. It's horrible to maintain but it pretty much works. There's a small amount of NBAR marking too, although not all MPLS providers support this due to the overhead. And in any case, since each MPLS provider uses different DSCP settings you have to rewrite at the borders. Firewall rules are generally specified on a per host basis. Add IPv6 SLAAC + temporary addresses into the mix and it's fairly likely that you are not going to be able to identify equipment or flows based on IPv6 address. Since many important apps for QoS (e.g. bulk back up) don't always run on well known port numbers, or applications re-use well-known port numbers (everything on port 80), you've lost even that (vague) mapping. If we can get DHCPv6 to assign IPv6 addresses based on DUID it might happen. But up until now, support for DHCPv6 has been pretty abysmal, so I'm not counting on that. It's the same story for basic access-lists and firewall security: you can't reliably identify devices or flows any more based on IP address+port, so you can't specify static firewall rules per end device. OK people might say that you can always authenticate to the firewall and add rules dynamically. But not all flows have human users sat behind them. And there might easily be 2 or 3 firewalls on the path. All of the other mechanisms are being killed, so we're going to have to invent new bad habits. So we figured as a last resort to try to identify applications and basic security classes based on LAN prefix. If you have a bulk back up server, connect it to a LAN for bulk traffic. If you have voice equipment, connect it to a voice LAN. If you have stuff that needs inbound connectivity, connect it to an inbound DMZ LAN. If you have stuff that does not need inbound connectivity except from certain management LANs, place it on a security class 1 LAN. The VLANs and class-map access-lists and firewall access-lists can then be standardised throughout the whole network for all providers for all sites [providers simply add in their own local DSCP tags]. Configs can be auto-generated. We may even eventually able to assign highly mobile devices to appropriate LANs based on 802.1X VLAN assignment: so the CIO's iDevice gets connected to the VIP LAN. It's not like we're short of IPv6 addresses or VLAN ID's. regards, > Dan Wing > 11 July 2012 02:33 > ... > > I sure would like to understand better the details. > > I have seen a similar proposal, but it suffered from a problem that only > dedicated-use devices could participate in that scheme. Multi-use > devices (e.g., a PC, a tablet, a smartphone) will not have the > smarts to acquire multiple IPv6 prefixes and have certain applications > use a certain prefix (e.g., VoIP application is supposed to use > a certain prefix to get certain DSCP treatment). This gets even > harder if all applications are Javascript running within a web > browser which is sometimes doing bittorrent, other times interactive > realtime media, other times streaming video, other times filling > out a web form. > > -d > > > ------------------------------------------------------------------------ From internet-drafts@ietf.org Tue Jul 10 23:57: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 BBB6E21F856F; Tue, 10 Jul 2012 23:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yMGTUu+gR9hB; Tue, 10 Jul 2012 23:57:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3EF921F8565; Tue, 10 Jul 2012 23:57:19 -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.30p3 Message-ID: <20120711065719.16518.37506.idtracker@ietfa.amsl.com> Date: Tue, 10 Jul 2012 23:57:19 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-icp-guidance-02.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, 11 Jul 2012 06:57:20 -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-02.txt Pages : 20 Date : 2012-07-10 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-02 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-icp-guidance-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From brian.e.carpenter@gmail.com Wed Jul 11 00:03: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 8178C11E80BC for ; Wed, 11 Jul 2012 00:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.181 X-Spam-Level: X-Spam-Status: No, score=-101.181 tagged_above=-999 required=5 tests=[AWL=0.509, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGAMRJENjeaf for ; Wed, 11 Jul 2012 00:03: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 C9FCB11E8086 for ; Wed, 11 Jul 2012 00:03:52 -0700 (PDT) Received: by eaaq13 with SMTP id q13so248832eaa.31 for ; Wed, 11 Jul 2012 00:04:22 -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:content-type:content-transfer-encoding; bh=7CsH/gH6sNIOvqH4S7mDQb7Em/qjVPtZaJ4n9nec1w4=; b=vrZrkeFqEswQz3wW0Ax8poq9Sp+0wuqzOpmjWGrI/ntzpyGQ3NLKJh+6kZ5kWgNevh SOacCuUXqqmSHsqJGGecUvlh6kPTu8KBSGbXyofLA7sZd6/2AA4JIGsILo4hIcgitrT+ LwKo+DhWqhJU1zjUIsO1HsiyzqQFzchJUS6B02VuhsKC1+AC2ZedojC+v3y+c6rsyk/H 4DaJ4geyuClE5OtwfYo6TIlkI5lDqD7NPhPbiWeorFnybRnuTIecHdwrzF/0zNEmhxDx hW1Dg0i+8bQy2jlKaXame9jj5N1OA5of7AAIwz7ibbgFaI8TZxKYBhjPhDI0Xthfio1w KwXw== Received: by 10.14.22.5 with SMTP id s5mr10720947ees.226.1341990261720; Wed, 11 Jul 2012 00:04:21 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-219-124.as13285.net. [2.102.219.124]) by mx.google.com with ESMTPS id e48sm2694232eea.12.2012.07.11.00.04.20 (version=SSLv3 cipher=OTHER); Wed, 11 Jul 2012 00:04:20 -0700 (PDT) Message-ID: <4FFD2576.3050507@gmail.com> Date: Wed, 11 Jul 2012 08:04:22 +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 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [v6ops] [Fwd: I-D Action: draft-ietf-v6ops-icp-guidance-02.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, 11 Jul 2012 07:03:53 -0000 This update is mainly in response to a careful review by Mark Smith. Brian + Sheng -------- Original Message -------- Subject: I-D Action: draft-ietf-v6ops-icp-guidance-02.txt Date: Tue, 10 Jul 2012 23:57:19 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org 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 : IPv6 Guidance for Internet Content and Application Service Providers Author(s) : Brian Carpenter Sheng Jiang Filename : draft-ietf-v6ops-icp-guidance-02.txt Pages : 20 Date : 2012-07-10 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-02 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=draft-ietf-v6ops-icp-guidance-02 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 lorenzo@google.com Wed Jul 11 02:36: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 302D921F8666 for ; Wed, 11 Jul 2012 02:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.519 X-Spam-Level: X-Spam-Status: No, score=-102.519 tagged_above=-999 required=5 tests=[AWL=0.158, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVFPX4h630J5 for ; Wed, 11 Jul 2012 02:36:18 -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 1D9FB21F864F for ; Wed, 11 Jul 2012 02:36:18 -0700 (PDT) Received: by ggnc4 with SMTP id c4so1041047ggn.31 for ; Wed, 11 Jul 2012 02:36: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=tRNOAb+8Qm9rD2nXUHp5JHhsVz1NHKAfGbzeUiG1kbQ=; b=FZuow4srnLfE5WJAi8gVLFTmyhuGJPe8CbQ8yY0QRUcmP6mJSGQCM7IGjSllBVJc4O +suLRNXT+3qwUjRMiONA6QWLsV2kXyXTIJKZBOiVa2VjR0VF/jz/mTLX7sRYsv7SqhAh t6Ix5dBGSSYdvrfsE5n8pTzQaGUPmopdwlPoA6c8EyWghtduhU0n5+tZs8XbMRnUQGfO NhFGieTmKMJJIkGYBGxJBp5Jif8EagwPGr+5/jEh2i6gr/9yuS7TvO9H8/60Zb5HLBAP NuZg4W490Z1CfElQi7VwCBHT9Q/42h9Uw1nqksTZH2QtkyyFtlLjaa91OyR88RnhvGss VkkQ== 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=tRNOAb+8Qm9rD2nXUHp5JHhsVz1NHKAfGbzeUiG1kbQ=; b=Q6Z1r5m9Pr7aWE0xZK9lo0ZOPJeumMGFDOuqWtKnNFI9XBiyX2CKa4ECGfifpxRif7 GN6Ack7BGs/NETT+nTSiLQlPs6EF4fim2dIKMs87mrh6VAEKsaOZFX9S+WEIRPcq0ZgO BYIT25E5Ujf+IJtVX4VvJtViDfZbFVnnF/ukGlnzcru3lmLJ/vZVplz3RJvdvv42sO1N +rhApFwlJrG5x8MvYnXHZvScJvgvZzzH0MXFv/JFUAWCVofUJk5U7y01chX6/j1BP0ia 1hQogL45d2fyVNvvAp6Vt/cmk/3eBaiIRAmXNnEUbWz/fuKKBoMCh/7i5zoqUQuSMSat 48ug== Received: by 10.42.80.6 with SMTP id t6mr24707276ick.15.1341999407373; Wed, 11 Jul 2012 02:36:47 -0700 (PDT) Received: by 10.42.80.6 with SMTP id t6mr24707267ick.15.1341999407221; Wed, 11 Jul 2012 02:36:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.196.206 with HTTP; Wed, 11 Jul 2012 02:36:26 -0700 (PDT) In-Reply-To: <79510968-0EE0-473F-A0B1-DD4B35092523@laposte.net> References: <20120625002907.24191.87700.idtracker@ietfa.amsl.com> <20120625093320kawashimam@mail.jp.nec.com> <79510968-0EE0-473F-A0B1-DD4B35092523@laposte.net> From: Lorenzo Colitti Date: Wed, 11 Jul 2012 18:36:26 +0900 Message-ID: To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=20cf300e5067f4ccc304c48a952c X-System-Of-Record: true X-Gm-Message-State: ALoCoQmnNTaCUrffNN91BVSmYqNHCedNcVEY9uR9+VZrKzKOMFeCWUeqx3Hv4Yck3X6AxRPKxPah4N82ZU1K2tIwlVhV0KygxvU+22uaK2GFDGWKNKAa5P78hSxMam2YKaHK+H7PcR03X3gfGN18hXG6comcDQy6FaXy6iyR2KhpXTdrap2kDHE= Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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, 11 Jul 2012 09:36:19 -0000 --20cf300e5067f4ccc304c48a952c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Jun 25, 2012 at 4:34 PM, R=E9mi Despr=E9s wrote: > Hi, Masanobu-san, > > I have to confirm, no surprise, that I object to its BCP status because: > - it proposes more than just a combination of existing RFCs > What does it propose that's not just a combination of existing RFCs? It seems to me that the document essentially just says "you can build a service called 464xlat by combining the behaviour specified by these two RFCs, and choosing these particular values as parameters". It's not specifying any new behaviour. > - it has close relationship with subjects discussed in Softwires such as > MAP and 4rd, without serious examination of this relationship. > I don't understand why this would apply differently to a BCP or to an informational document. Also, I don't understand why this is relevant at all. The softwires work is attempting to solve a similar problem by defining new technology, and the approaches don't overlap. Cheers, Lorenzo --20cf300e5067f4ccc304c48a952c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Jun 25, 2012 at 4:34 PM, R=E9mi Despr=E9= s <despres.remi@laposte.net> wrote:
Hi, Masanobu-san,

I have to confirm, no surprise, that I object to its BCP status because: - it proposes more than just a combination of existing RFCs

What does it propose that's = not just a combination of existing RFCs? It seems to me that the document e= ssentially just says "you can build a service called 464xlat by combin= ing the behaviour specified by these two RFCs, and choosing these particula= r values as parameters". It's not specifying any new behaviour.
=A0
- it has close relationship with subjects discussed in Softwires such as MA= P and 4rd, without serious examination of this relationship.

I don't understand why this= would apply differently to a BCP or to an informational document. Also, I = don't understand why this is relevant at all. The softwires work is att= empting to solve a similar problem by defining new technology, and the appr= oaches don't overlap.

Cheers,
Lorenzo
--20cf300e5067f4ccc304c48a952c-- From lorenzo@google.com Wed Jul 11 02:38: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 22F2721F84F7 for ; Wed, 11 Jul 2012 02:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[AWL=0.079, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZEXRsmCQqN6V for ; Wed, 11 Jul 2012 02:38:28 -0700 (PDT) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by ietfa.amsl.com (Postfix) with ESMTP id 3518521F84F3 for ; Wed, 11 Jul 2012 02:38:28 -0700 (PDT) Received: by yhfs35 with SMTP id s35so1447184yhf.27 for ; Wed, 11 Jul 2012 02:38:58 -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=qWUm1E0byUMCTLDT5gFMoMlDI4iBtT7Du9/Gq6Tprb8=; b=Sw4Z1eXTATUUZ2SwklIyeXTqRt2YWV6VEVdxAsB90XmYh9LIzhZS86POrHNautpZ1s 1w/HgtMa6ahfVPo0CcPUmHFEfXq8/4iW26skjYTAvVJchI7MfIGh8xb+uUxkK0in5Xgt 9xyN14DAbZGN8dfagh64eHKSUNd4eB78vd4rx60RT5527zV8yu+l/9WNqYF5z7xgINFK i/K92Of4hRpTgHPsGA8LPdp7SxEweoyT+Vse5E6eC/X6PJeFwg3KF48qTEIJmb23JnKP +vEF0yiL/YEmYVl4gKODHXupvTdZhPq1xy0Z0cMdlNFS9fne5VxgXebc6zLSL9fsTKUb txaQ== 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=qWUm1E0byUMCTLDT5gFMoMlDI4iBtT7Du9/Gq6Tprb8=; b=P9zLmY07vFXT6hnNd71yhvgf9ZEGljxXrO8egFd/vIl26OF8u2vlx6nQSVpTghP7n2 2rxj6mhXdKyPPAv5aRTa1jBLNtWoJaAmCbquZEB67ZAMdj1FTdTy0sBhmT0Op1mv5XPb HIpR05JnfpIVV7iUv8TPeR1F4HH2RjzcYrOB+ayXw4rM415yaY92hsEPIlgQcotQnDYm kFlpDhjwqAKWjszs1QJtzHfIL8Simpx8h/5AmeIvja4bKpvAN54lzCi2BsyUUB0Clru2 2WivcOO43T6IbI5QgW4MTwDQCZSUghtOcYs1remnllaTNPyQUsCeGdrnJrVs0dedpNRq 8HWA== Received: by 10.50.161.198 with SMTP id xu6mr13878181igb.69.1341999537855; Wed, 11 Jul 2012 02:38:57 -0700 (PDT) Received: by 10.50.161.198 with SMTP id xu6mr13878168igb.69.1341999537744; Wed, 11 Jul 2012 02:38:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.196.206 with HTTP; Wed, 11 Jul 2012 02:38:37 -0700 (PDT) In-Reply-To: References: <20120703034522.1902.94338.idtracker@ietfa.amsl.com> <20120703124949kawashimam@mail.jp.nec.com> From: Lorenzo Colitti Date: Wed, 11 Jul 2012 18:38:37 +0900 Message-ID: To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=14dae9341141bc6bad04c48a9d90 X-System-Of-Record: true X-Gm-Message-State: ALoCoQm0Y8xvHa+2ZmqpTB0osQqvXH9nmNJCM/ryojuPE8zpFjakDFsyOmQhsFA9g97tcjPt+np3eAE7P/WE63grWMMBC60qvn2PISyKcmG5up/NQ4IEnkNn/7lqpB0SBOEbJJ348Pw9r5NxcJ397MTpsuKqy/lUG+B5NJwqDaVg4b66Sn4gRgc= Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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: Wed, 11 Jul 2012 09:38:29 -0000 --14dae9341141bc6bad04c48a9d90 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Jul 3, 2012 at 5:39 PM, R=E9mi Despr=E9s = wrote: > A good reason to refuse Informational or Experimental hasn't been seen on > this list. > An informational document is not a standards document. Thus, it cannot prevent the development of multiple incompatible implementations. Given that this document describes how to compose existing standards to run a service that requires both customer-side and provider-side components, I'd say interoperability is pretty important if this is to work at all. Cheers, Lorenzo --14dae9341141bc6bad04c48a9d90 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Jul 3, 2012 at 5:39 PM, R=E9mi Despr=E9s= <despres.remi@laposte.net> wrote:
A good reason to refuse Informational or Experimental hasn't been seen = on this list.

An informational document= is not a standards document. Thus, it cannot prevent the development of mu= ltiple incompatible implementations.

Given that this document describes how to compose exist= ing standards to run a service that requires both customer-side and provide= r-side components, I'd say interoperability is pretty important if this= is to work at all.

Cheers,
Lorenzo
--14dae9341141bc6bad04c48a9d90-- From cathy.zhou@huawei.com Wed Jul 11 02:40: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 0D60421F84FD for ; Wed, 11 Jul 2012 02:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p27UfM386HtE for ; Wed, 11 Jul 2012 02:40:30 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id E911721F864F for ; Wed, 11 Jul 2012 02:40:29 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHX73574; Wed, 11 Jul 2012 05:41:00 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 11 Jul 2012 02:39:15 -0700 Received: from SZXEML425-HUB.china.huawei.com (10.72.61.33) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 11 Jul 2012 02:39:19 -0700 Received: from SZXEML527-MBS.china.huawei.com ([169.254.6.143]) by szxeml425-hub.china.huawei.com ([10.72.61.33]) with mapi id 14.01.0323.003; Wed, 11 Jul 2012 17:39:13 +0800 From: "Zhouqian (Cathy)" To: Joel jaeggli , "Fred Baker (fred)" Thread-Topic: [v6ops] Draft on DC migration to IPv6 Thread-Index: AQHNW5Grz6Airmi1OkGxTcsV2RJJE5cj2oyg Date: Wed, 11 Jul 2012 09:39:12 +0000 Message-ID: References: <28DC472D-01D4-4534-97A9-6AE52BE9CC58@tid.es> <4FF70D8F.5010706@bogus.com> In-Reply-To: <4FF70D8F.5010706@bogus.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.77.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: IPv6 Ops WG Subject: Re: [v6ops] Draft on DC migration to IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 11 Jul 2012 09:40:31 -0000 Hi Joel, -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of J= oel jaeggli Sent: Saturday, July 07, 2012 12:09 AM To: Fred Baker (fred) Cc: IPv6 Ops WG Subject: Re: [v6ops] Draft on DC migration to IPv6 On 6/25/12 05:56 , Fred Baker (fred) wrote: > In addition to getting working group commentary (which has to happen to m= ake it onto the agenda), may I suggest you discuss the draft with my co-cha= ir, who is an IPv6 data center operator? over in 2.1 The translation of IPv6 requests into the internal infrastructure format occurs at the outmost level of the DC Internet connection. This can be typically achieved at the DC gateway routers, that support the appropriate address translation mechanisms for those services required to be accessed through native IPv6 requests. The policies for applying adaptation can range from performing it only to a limited set of specified services to providing a general translation service for all public services. Finer mechanisms, based on address ranges or more sophisticated dynamic policies are also possible, as they are applied by a limited set of control elements. This provides an additional level of control to the usage of IPv6 routable addresses in the DC environment, which can be especially significant at the early deployment stages. This model is also suitable to be applied in an "off-shore" mode by the service provider connecting the DC infrastructure to the Internet, as described in [I-D.sunq-v6ops-contents-transition] Basically no content provider that I know of want to lose the source address associated with the incoming request. so the recommendation here, to the extent that it's a recommendation is really unappealing. [Cathy] The content provider will not lose the source address associated wi= th the incoming request. The source IPv6 address is translated to IPv4 addr= ess, and the translator need retain the correspondence between IPv6 source = address and IPv4 source address. This is similar to NAT64, but there is a b= it different: typical NAT64 is session based while IPv4/v6 translator in da= tacenter can be user based which can reduce the binding entries. If we don'= t use v4/v6 translator and just update the datacenter to dual-stack, there = will be a very huge cost. So it is not recommended at the begin of IPv6 mig= ration. o Flow labels can be applied to enhance load-balancing, as described in [I-D.carpenter-v6ops-label-balance]. Incoming IPv6 requests can take advantage of them, and the gateway systems use them as a hint for applying load-balancing mechanisms at the IPv4 internal accesses. The majority of the flow labels today are zero. datacenter operators are not os developers and we don't engage in wishful thinking. [Cathy] Yes, I agree with you that "The majority of the flow labels today a= re zero". The datacenter will still use the tradition of the load-balance m= ethod. Using flow labels for load balance is a complementary method. Cathy > On Jun 25, 2012, at 4:58 PM, Diego R. Lopez wrote: _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From diego@tid.es Wed Jul 11 03:11: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 E9E4921F863D for ; Wed, 11 Jul 2012 03:11:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.676 X-Spam-Level: X-Spam-Status: No, score=-5.676 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BIqw+ygTz5d8 for ; Wed, 11 Jul 2012 03:11:48 -0700 (PDT) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id A922521F8636 for ; Wed, 11 Jul 2012 03:11:47 -0700 (PDT) Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M6Z00M7RR0H7X@tid.hi.inet> for v6ops@ietf.org; Wed, 11 Jul 2012 12:12:17 +0200 (MEST) Received: from tid (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id 78.6D.26499.1815DFF4; Wed, 11 Jul 2012 12:12:17 +0200 (CEST) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0M6Z00M7MR0G7X@tid.hi.inet> for v6ops@ietf.org; Wed, 11 Jul 2012 12:12:17 +0200 (MEST) Received: from EX10-MB1-MAD.hi.inet ([fe80::a473:4f3e:f8db:1855]) by ex10-htcas4-mad.hi.inet ([::1]) with mapi id 14.02.0298.004; Wed, 11 Jul 2012 12:12:17 +0200 Date: Wed, 11 Jul 2012 10:12:16 +0000 From: "Diego R. Lopez" In-reply-to: <45F1DB32-74F6-4E4A-88E2-118B76A5F474@cisco.com> X-Originating-IP: [10.95.64.115] To: "Fred Baker (fred)" Message-id: <99754D29-3BF5-4E7D-9908-D8F2B1D42F25@tid.es> Content-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US Thread-topic: [v6ops] Prep for v6ops IETF 84 agenda Thread-index: AQHNUnbpWFu7FKUfJEyvobkjy/vWXQ== X-AuditID: 0a5f4068-b7f206d000006783-d7-4ffd518144c3 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNKsWRmVeSWpSXmKPExsXCFe/ApdsY+NffYPUhbovTx/YyOzB6LFny kymAMYrLJiU1J7MstUjfLoEr49/UXcwF23gqLl64wtzA2MPTxcjJISFgIvHnxGYmCFtM4sK9 9WxdjFwcQgIbGSXeL+pggXB+Mkr8/baPFcJZyiixdP85ZpAWFgFVic1Xm1hBbDYg+1Hzb3YQ W1jASGLzuWZGEJtTwFZi27HTrBArFCT+nHvMAmKLCGhIbPhyFCzOLOAqMevxJaDVHBy8ApYS s94FQITNJN5P/wU2hldAUOLH5HssICXMAuoSU6bkQpSISzS33mSBsBUlpi1qACtnBHrm+6k1 TBCbjCUWXDsPtVVPYuqMRqiHBSSW7DnPDGGLSrx8/A/sGiGBfIkve9+yTWCUmIXkillIrpiF cMUsJFfMQnLFAkbWVYxixUlFmekZJbmJmTnpBoZ6GZl6mXmpJZsYITGXsYNx+U6VQ4wCHIxK PLyK0z75C7EmlhVX5h5ilORgUhLlne3/11+ILyk/pTIjsTgjvqg0J7X4EKMEB7OSCG+ND1CO NyWxsiq1KB8mJcPBoSTB2xcAlBIsSk1PrUjLzAEmFpg0EwcnSDsPUPthkBre4oLE3OLMdIj8 KUZJKXHeZSAJAZBERmkeXO8rRnGgI4V5j4NkeYApEK7rFdBAJqCBC5b+ARlYkoiQkmpg9BQJ kuHZEPaQcdYJuUd+LBxazZ/W5c28/P3SWy27fIH8R9Wnu5pDWpuv6P6tFnhZeUE27fDvfW+T ZXhvTzCUfK7wU/tqnaBUSbfWtN7HAcejV391udO8tiHuv/te8xMhx7kMZh79WrbJU0J9j+pU udyyn64b96jxvgsVem+lvDOyfqb6Y7uzSizFGYmGWsxFxYkA4DxSaz4DAAA= References: <8D73E1D6-A968-4397-A843-FE073197B7F1@cisco.com> <45F1DB32-74F6-4E4A-88E2-118B76A5F474@cisco.com> Cc: "v6ops@ietf.org WG" , Ron Bonica Subject: Re: [v6ops] Prep for v6ops IETF 84 agenda X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 11 Jul 2012 10:11:49 -0000 SGksDQoNCk9uIDEwIEp1bCAyMDEyLCBhdCAxNzo1MSAsIEZyZWQgQmFrZXIgKGZyZWQpIHdyb3Rl Og0KPiBXaGF0IGxpdHRsZSBkaXNjdXNzaW9uIGhhcyBoYXBwZW5lZCBvbiBkcmFmdC1sb3Blei12 Nm9wcy1kYy1pcHY2IHNlZW1zIHRvIG1vc3RseSBwb2ludCB0byBvdGhlciBkb2N1bWVudHMgYXMg YWxyZWFkeSBzYXlpbmcgdGhpbmdzLg0KDQpJIGhhdmUgYSBkaWZmZXJlbnQgaW1wcmVzc2lvbi4g VGhlIChub3QgdGhhdCBtdWNoLCBncmFudGVkKSBkaXNjdXNzaW9uIGhhcyBmb2N1c2VkDQpvbiBj bGFyaWZ5aW5nIGFzcGVjdHMgcmVnYXJkaW5nIHRoZSBwcm9wb3NlZCBsZXZlbHMgYW5kIHdoZXJl IGNlcnRhaW4gc29sdXRpb25zIGNvdWxkDQpmaXQgaW4gdGhvc2UgbGV2ZWxzLiBJdCBpcyB0cnVl IHRoYXQgc29tZSBwcmVjaXNpb25zIG9uIHRoZSByaWdodCByZWZlcmVuY2VzIHdlcmUNCm1hZGUs IGJ1dCBpZiBhcyBmYXIgYXMgSSBjYW4gcmVjYWxsIHRoZXkgd2VyZSBtYWRlIGFzIGFkZGl0aW9u YWwgY29tbWVudHMuDQoNCkJlIGdvb2RlLA0KDQotLQ0KIkVzdGEgdmV6IG5vIGZhbGxhcmVtb3Ms IERvY3RvciBJbmZpZXJubyINCg0KRHIgRGllZ28gUi4gTG9wZXoNClRlbGVmb25pY2EgSStEDQpo dHRwOi8vcGVvcGxlLnRpZC5lcy9kaWVnby5sb3Blei8NCg0KZS1tYWlsOiBkaWVnb0B0aWQuZXMN ClRlbDogICAgKzM0IDkxMyAxMjkgMDQxDQpNb2JpbGU6ICszNCA2ODIgMDUxIDA5MQ0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KDQpFc3RlIG1lbnNhamUgc2UgZGlyaWdlIGV4Y2x1c2l2YW1lbnRl IGEgc3UgZGVzdGluYXRhcmlvLiBQdWVkZSBjb25zdWx0YXIgbnVlc3RyYSBwb2zDrXRpY2EgZGUg ZW52w61vIHkgcmVjZXBjacOzbiBkZSBjb3JyZW8gZWxlY3Ryw7NuaWNvIGVuIGVsIGVubGFjZSBz aXR1YWRvIG3DoXMgYWJham8uDQpUaGlzIG1lc3NhZ2UgaXMgaW50ZW5kZWQgZXhjbHVzaXZlbHkg Zm9yIGl0cyBhZGRyZXNzZWUuIFdlIG9ubHkgc2VuZCBhbmQgcmVjZWl2ZSBlbWFpbCBvbiB0aGUg YmFzaXMgb2YgdGhlIHRlcm1zIHNldCBvdXQgYXQuDQpodHRwOi8vd3d3LnRpZC5lcy9FUy9QQUdJ TkFTL2Rpc2NsYWltZXIuYXNweA0K From despres.remi@laposte.net Wed Jul 11 05:32: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 D96AF21F861F for ; Wed, 11 Jul 2012 05:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.221 X-Spam-Level: X-Spam-Status: No, score=-1.221 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, GB_ABOUTYOU=0.5, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6JPP1q6xhzy for ; Wed, 11 Jul 2012 05:32:56 -0700 (PDT) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.2]) by ietfa.amsl.com (Postfix) with ESMTP id A71F621F8620 for ; Wed, 11 Jul 2012 05:32:55 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2109.sfr.fr (SMTP Server) with ESMTP id 38E8170000F2; Wed, 11 Jul 2012 14:33:25 +0200 (CEST) Received: from [192.168.1.73] (58.204.170.89.rev.sfr.net [89.170.204.58]) by msfrf2109.sfr.fr (SMTP Server) with ESMTP id 3D1C27000148; Wed, 11 Jul 2012 14:33:24 +0200 (CEST) X-SFR-UUID: 20120711123324250.3D1C27000148@msfrf2109.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-8-778067071 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 11 Jul 2012 14:33:23 +0200 Message-Id: References: <20120625002907.24191.87700.idtracker@ietfa.amsl.com> <20120625093320kawashimam@mail.jp.nec.com> <79510968-0EE0-473F-A0B1-DD4B35092523@laposte.net> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) Cc: v6ops v6ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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, 11 Jul 2012 12:32:57 -0000 --Apple-Mail-8-778067071 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi, Lorenzo, Comments about your two mails inline. 2012-07-11 =E0 11:36, Lorenzo Colitti: > On Mon, Jun 25, 2012 at 4:34 PM, R=E9mi Despr=E9s = wrote: > Hi, Masanobu-san, >=20 > I have to confirm, no surprise, that I object to its BCP status = because: > - it proposes more than just a combination of existing RFCs >=20 > What does it propose that's not just a combination of existing RFCs? = It seems to me that the document essentially just says "you can build a = service called 464xlat by combining the behaviour specified by these two = RFCs, and choosing these particular values as parameters". It's not = specifying any new behaviour. (*) At least two points (both valuable IMHO) specify new behaviors: - In section 3: << The CLAT does not comply with the sentence "Both = IPv4-translatable IPv6 addresses and IPv4-converted IPv6 addresses = SHOULD use the same prefix." that is described on Section 3.3 in = [RFC6052] due to using different IPv6 prefixes for CLAT-side and = PLAT-side IPv4 addresses. >> - There is a request to IANA in section 10. BCP is therefore inappropriate AFAIK. Whether Experimental would be better than Informational remains however = open AFAIAC. > =20 > - it has close relationship with subjects discussed in Softwires such = as MAP and 4rd, without serious examination of this relationship. >=20 > I don't understand why this would apply differently to a BCP or to an = informational document. Also, I don't understand why this is relevant at = all. The softwires work is attempting to solve a similar problem by = defining new technology, and the approaches don't overlap. Hastily freezing a recommended behavior while a better one is being = currently worked on, is in my understanding inappropriate. In particular, improved transparency to IPv4 null checksums and to DF=3D1 = fragmented packets of RFC 4821 is worth considering (as proposed with = the NAT64+ of tools.ietf.org/html/draft-ietf-softwire-4rd-02).=20 OTOH, as I said, publishing 4X4XLAT now is IMHO valuable (be it as = informational or experimental): it deals with a subject not covered in = other IETF documents. >=20 > Cheers, > Lorenzo 2012-07-11 11:38, Lorenzo Colitti : > On Tue, Jul 3, 2012 at 5:39 PM, R=E9mi Despr=E9s = wrote: > A good reason to refuse Informational or Experimental hasn't been seen = on this list. >=20 > An informational document is not a standards document. Neither a BCP AFAIK. > Thus, it cannot prevent the development of multiple incompatible = implementations. (**) 464XLAT defines a CLAT behavior designed to work with any NAT64, so that = AFAIK incompatibility isn't an issue. > Given that this document describes how to compose existing standards = to run a service that requires both customer-side and provider-side = components, I'd say interoperability is pretty important if this is to = work at all. (*)and (**) above are relevant here. The remaining question is while the chairs wouldn't accept an = Informational or Experimental status while authors themselves are open = to it. Cheers, RD =20 >=20 > Cheers, > Lorenzo --Apple-Mail-8-778067071 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On Mon, Jun 25, 2012 at 4:34 = PM, R=E9mi Despr=E9s <despres.remi@laposte.net> wrote:
Hi, = Masanobu-san,

I have to confirm, no surprise, that I object to = its BCP status because:
- it proposes more than just a combination of = existing RFCs

What does it propose that's not just a combination = of existing RFCs? It seems to me that the document essentially just says = "you can build a service called 464xlat by combining the behaviour = specified by these two RFCs, and choosing these particular values as = parameters". It's not specifying any new = behaviour.

(*)
At least = two points (both valuable IMHO) specify new behaviors:
- In = section 3: << The CLAT does not = comply with the sentence "Both IPv4-translatable = IPv6 addresses and IPv4-converted IPv6 addresses SHOULD use the same prefix." that is described = on Section 3.3 = in [RFC6052] due to using different IPv6 prefixes for CLAT-side and PLAT-side IPv4 addresses. = >>
- There is a = request to IANA in section 10.

BCP is therefore = inappropriate AFAIK.
Whether = Experimental would be better than Informational remains however open = AFAIAC.

 
- it has close = relationship with subjects discussed in Softwires such as MAP and 4rd, = without serious examination of this = relationship.

I = don't understand why this would apply differently to a BCP or to an = informational document. Also, I don't understand why this is relevant at = all. The softwires work is attempting to solve a similar problem by = defining new technology, and the approaches don't = overlap.

Hastily freezing a = recommended behavior while a better one is being currently worked on, is = in my understanding inappropriate.

In = particular, improved transparency to IPv4 null checksums and to DF=3D1 = fragmented packets of RFC 4821 is worth considering (as proposed = with the NAT64+ of tools.ietf.= org/html/draft-ietf-softwire-4rd-02). 

O= TOH, as I said, publishing 4X4XLAT now is IMHO valuable (be it = as informational or experimental): it deals with a subject not covered = in other IETF documents.


Cheers,
Lorenzo

=

2012-07-11  11:38, Lorenzo Colitti = :

On Tue, Jul 3, 2012 at 5:39 PM, = R=E9mi Despr=E9s <despres.remi@laposte.net> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin-top: 0px; margin-right: = 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; = border-left-color: rgb(204, 204, 204); border-left-style: solid; = padding-left: 1ex; ">A good reason to refuse Informational or = Experimental hasn't been seen on this = list.

An informational document is = not a standards document. =

Neither a BCP = AFAIK.

Thus, it cannot prevent the development of = multiple incompatible = implementations.

(**)
464= XLAT defines a CLAT behavior designed to work with any NAT64, so that = AFAIK incompatibility isn't an = issue.


Given that this document describes how to = compose existing standards to run a service that requires both = customer-side and provider-side components, I'd say interoperability is = pretty important if this is to work at = all.

(*)and (**) above are = relevant here.

The remaining question is while = the chairs wouldn't accept an Informational or Experimental status while = authors themselves are open to = it.

Cheers,
RD


 


Cheers,
Lorenzo
<= /div>


= --Apple-Mail-8-778067071-- From fred@cisco.com Wed Jul 11 07:42: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 B8AFA21F86F3 for ; Wed, 11 Jul 2012 07:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.479 X-Spam-Level: X-Spam-Status: No, score=-110.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pVRVvtSUDLkn for ; Wed, 11 Jul 2012 07:42:19 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id AE6A021F86D0 for ; Wed, 11 Jul 2012 07:42:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=720; q=dns/txt; s=iport; t=1342017770; x=1343227370; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=xMRyJnycOH94Po97hsPFGuz/Zekh7m9MpB7RWm+tlKc=; b=N74EEZ6uMxnRUo3fsSFVRJg4fJgYDDe1nTPXKXN1dn/x3fKHeu+op1zk RGHJNxGuvuOsvzpVxaPRN8co/9eRLnbvuOv32JtGdmSd93spnawJPOt1y K4/bwm1sq+PI5+92sKWHciOklZASkB8Exj2b2eW+pxivzooCu0plgcrGF g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EALWP/U+tJXHA/2dsb2JhbABFt2SBB4IhAQEEEgEnPxACAQg2EDIlAgQOJ4drnT+gG4tAhQ5gA5U6jiCBZoJf X-IronPort-AV: E=Sophos;i="4.77,567,1336348800"; d="scan'208";a="100625596" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-1.cisco.com with ESMTP; 11 Jul 2012 14:42:50 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q6BEgo98025818 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Jul 2012 14:42:50 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.118]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0298.004; Wed, 11 Jul 2012 09:42:49 -0500 From: "Fred Baker (fred)" To: "Zhouqian (Cathy)" Thread-Topic: [v6ops] Draft on DC migration to IPv6 Thread-Index: AQHNUtH08AdBnuzG2kudzG/wrZXEvg== Date: Wed, 11 Jul 2012 14:42:20 +0000 Message-ID: References: <28DC472D-01D4-4534-97A9-6AE52BE9CC58@tid.es> <4FF70D8F.5010706@bogus.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.70.9] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19032.004 x-tm-as-result: No--23.978400-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: <9A6E59507CA0994A93E7E8770774451D@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPv6 Ops WG Subject: Re: [v6ops] Draft on DC migration to IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 11 Jul 2012 14:42:20 -0000 On Jul 11, 2012, at 2:39 AM, Zhouqian (Cathy) wrote: > [Cathy] The content provider will not lose the source address associated = with the incoming request. The source IPv6 address is translated to IPv4 ad= dress, and the translator need retain the correspondence between IPv6 sourc= e address and IPv4 source address.=20 Yes, but for many data center applications, the application itself wants to= know the original source address in order to provide location-aware servic= es. So it is not sufficient for the NAT to know; the information needs to s= omehow be presented to the application. This has been brought up by Lorenzo= among others as a requirement in their data centers and public services. From joelja@bogus.com Wed Jul 11 07: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 5479621F871C for ; Wed, 11 Jul 2012 07:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.239 X-Spam-Level: X-Spam-Status: No, score=-102.239 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rhlg7YcgjBVl for ; Wed, 11 Jul 2012 07:50:53 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 6B1CD21F850B for ; Wed, 11 Jul 2012 07:50:53 -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 q6BEpJxc058408 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 11 Jul 2012 14:51:19 GMT (envelope-from joelja@bogus.com) Message-ID: <4FFD92E9.7020609@bogus.com> Date: Wed, 11 Jul 2012 07:51:21 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120704 Thunderbird/14.0 MIME-Version: 1.0 To: "Zhouqian (Cathy)" References: <28DC472D-01D4-4534-97A9-6AE52BE9CC58@tid.es> <4FF70D8F.5010706@bogus.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, 11 Jul 2012 14:51:20 +0000 (UTC) Cc: IPv6 Ops WG Subject: Re: [v6ops] Draft on DC migration to IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 11 Jul 2012 14:50:54 -0000 On 7/11/12 2:39 AM, Zhouqian (Cathy) wrote: > Hi Joel, > > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Joel jaeggli > Sent: Saturday, July 07, 2012 12:09 AM > To: Fred Baker (fred) > Cc: IPv6 Ops WG > Subject: Re: [v6ops] Draft on DC migration to IPv6 > > On 6/25/12 05:56 , Fred Baker (fred) wrote: >> In addition to getting working group commentary (which has to happen to make it onto the agenda), may I suggest you discuss the draft with my co-chair, who is an IPv6 data center operator? > over in 2.1 > > The translation of IPv6 requests into the internal infrastructure > format occurs at the outmost level of the DC Internet connection. > This can be typically achieved at the DC gateway routers, that > support the appropriate address translation mechanisms for those > services required to be accessed through native IPv6 requests. The > policies for applying adaptation can range from performing it only to > a limited set of specified services to providing a general > translation service for all public services. Finer mechanisms, based > on address ranges or more sophisticated dynamic policies are also > possible, as they are applied by a limited set of control elements. > This provides an additional level of control to the usage of IPv6 > routable addresses in the DC environment, which can be especially > significant at the early deployment stages. > > This model is also suitable to be applied in an "off-shore" mode by > the service provider connecting the DC infrastructure to the > Internet, as described in [I-D.sunq-v6ops-contents-transition] > > Basically no content provider that I know of want to lose the source > address associated with the incoming request. so the recommendation > here, to the extent that it's a recommendation is really unappealing. > > [Cathy] The content provider will not lose the source address associated with the incoming request. The source IPv6 address is translated to IPv4 address, and the translator need retain the correspondence between IPv6 source address and IPv4 source address. This is similar to NAT64, but there is a bit different: typical NAT64 is session based while IPv4/v6 translator in datacenter can be user based which can reduce the binding entries. If we don't use v4/v6 translator and just update the datacenter to dual-stack, there will be a very huge cost. So it is not recommended at the begin of IPv6 migration. The content provider will lose access to the source ip for the purposes of the application. retaining a correspondence in a log someplace is not the equivalent of passing that information along. Presuming the existance of a hypthetical message bus by which I can signal the application what the source address was is all fine and dandy but I don't have one. Some application layer proxies e.g. http(s) can pass this information in-band so you end up with x-forwarded-for for example (and no nat64) presuming that you can enable load balancer application tier to handle such activities. > o Flow labels can be applied to enhance load-balancing, as described > in [I-D.carpenter-v6ops-label-balance]. Incoming IPv6 requests > can take advantage of them, and the gateway systems use them as a > hint for applying load-balancing mechanisms at the IPv4 internal > accesses. > > The majority of the flow labels today are zero. datacenter operators are > not os developers and we don't engage in wishful thinking. > > [Cathy] Yes, I agree with you that "The majority of the flow labels today are zero". The datacenter will still use the tradition of the load-balance method. Using flow labels for load balance is a complementary method. It's not complementary because today it doesn't work. So... What useful advice does that amount to for someone considering enabling ipv6 on their load balancer tier? > Cathy > >> On Jun 25, 2012, at 4:58 PM, Diego R. Lopez wrote: > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From diego@tid.es Wed Jul 11 08:07: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 D7AC421F8594 for ; Wed, 11 Jul 2012 08:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6 X-Spam-Level: X-Spam-Status: No, score=-6 tagged_above=-999 required=5 tests=[AWL=0.599, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a85IgfqR72JB for ; Wed, 11 Jul 2012 08:07:55 -0700 (PDT) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id 890A921F858D for ; Wed, 11 Jul 2012 08:07:54 -0700 (PDT) Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M7000CMU4Q0CL@tid.hi.inet> for v6ops@ietf.org; Wed, 11 Jul 2012 17:08:24 +0200 (MEST) Received: from tid (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id A1.D3.26499.8E69DFF4; Wed, 11 Jul 2012 17:08:24 +0200 (CEST) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0M7000CMP4PZCL@tid.hi.inet> for v6ops@ietf.org; Wed, 11 Jul 2012 17:08:24 +0200 (MEST) Received: from EX10-MB1-MAD.hi.inet ([fe80::a473:4f3e:f8db:1855]) by ex10-htcas3-mad.hi.inet ([::1]) with mapi id 14.02.0298.004; Wed, 11 Jul 2012 17:08:23 +0200 Date: Wed, 11 Jul 2012 15:08:23 +0000 From: "Diego R. Lopez" In-reply-to: X-Originating-IP: [10.95.64.115] To: "Fred Baker (fred)" Message-id: <9E1CA4A1-8AE8-4EA0-80DD-55719A29AB17@tid.es> Content-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US Thread-topic: [v6ops] Draft on DC migration to IPv6 Thread-index: AQHNUqhbgWRF7Aew1UKq7qhHvsQ1MZcK3RGAgBF/VoCAB27PAIAAVLIAgAAHSYA= X-AuditID: 0a5f4068-b7f206d000006783-60-4ffd96e84409 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNKsWRmVeSWpSXmKPExsXCFe/Apfti2l9/g4PLuS1OH9vL7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujJV7n7IWHBGt6Lg7h6mB8Y9IFyMnh4SAiUTfoyfsELaYxIV7 69m6GLk4hAQ2MkqcuLGYHcL5ySjRvPI5I4SzlFGiZ+4JJpAWFgFViWk71oDZbED2o+bfQB0c HMICRhLfJ3mBhDkFbCW2LDzPDLFBQeLPuccsILaIgIbEhi9HWUFsZgEfiS13f4NdwStgKbFg xlpGiLiZRM/ezYwQcUGJH5PvsYCMZxZQl5gyJReiRFyiufUmC4StKDFtUQNYOSPQM99PgVzG AbTKWOLIPkGIrX4S8589ZIS4RkBiyR6Yy0QlXj7+xwrxYQeTxNXl89gnMErMQnLFLCRXzEK4 YhaSK2YhuWIBI+sqRrHipKLM9IyS3MTMnHQDQ72MTL3MvNSSTYyQmMvYwbh8p8ohRgEORiUe XsVpn/yFWBPLiitzDzFKcjApifJ+L/nrL8SXlJ9SmZFYnBFfVJqTWnyIUYKDWUmEt3wCUI43 JbGyKrUoHyYlw8GhJMErB0wPQoJFqempFWmZOcDEApNm4uAEaecBamcCqeEtLkjMLc5Mh8if YpSUEuc9MxUoIQCSyCjNg+t9xSgOdKQwrxtIGw8wBcJ1vQIayAQ0cMHSPyADSxIRUlINjAsf 8K474bP/rmpiIl+K7nK/T+23UzwurT6ZyR2zqErXOjLkLKth11U+6fsMs2PWRV5lPcczcdpF +eZ1fZtCQmUmyi678/JCd866qC0SyS5Tty3Tl/2kr3Hm4r3ySVNVDPbENh7SnbrJ+76Bs+T+ +U9KjbzqzhrceOAiOmX9fbZadUeV+xOifiqxFGckGmoxFxUnAgDTfvAqPgMAAA== References: <28DC472D-01D4-4534-97A9-6AE52BE9CC58@tid.es> <4FF70D8F.5010706@bogus.com> Cc: IPv6 Ops WG Subject: Re: [v6ops] Draft on DC migration to IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 11 Jul 2012 15:07:57 -0000 SGksDQoNCk9uIDExIEp1bCAyMDEyLCBhdCAxNjo0MiAsIEZyZWQgQmFrZXIgKGZyZWQpIHdyb3Rl Og0KPiBPbiBKdWwgMTEsIDIwMTIsIGF0IDI6MzkgQU0sIFpob3VxaWFuIChDYXRoeSkgd3JvdGU6 DQo+DQo+PiBbQ2F0aHldIFRoZSBjb250ZW50IHByb3ZpZGVyIHdpbGwgbm90IGxvc2UgdGhlIHNv dXJjZSBhZGRyZXNzIGFzc29jaWF0ZWQgd2l0aCB0aGUgaW5jb21pbmcgcmVxdWVzdC4gVGhlIHNv dXJjZSBJUHY2IGFkZHJlc3MgaXMgdHJhbnNsYXRlZCB0byBJUHY0IGFkZHJlc3MsIGFuZCB0aGUg dHJhbnNsYXRvciBuZWVkIHJldGFpbiB0aGUgY29ycmVzcG9uZGVuY2UgYmV0d2VlbiBJUHY2IHNv dXJjZSBhZGRyZXNzIGFuZCBJUHY0IHNvdXJjZSBhZGRyZXNzLg0KPg0KPiBZZXMsIGJ1dCBmb3Ig bWFueSBkYXRhIGNlbnRlciBhcHBsaWNhdGlvbnMsIHRoZSBhcHBsaWNhdGlvbiBpdHNlbGYgd2Fu dHMgdG8ga25vdyB0aGUgb3JpZ2luYWwgc291cmNlIGFkZHJlc3MgaW4gb3JkZXIgdG8gcHJvdmlk ZSBsb2NhdGlvbi1hd2FyZSBzZXJ2aWNlcy4gU28gaXQgaXMgbm90IHN1ZmZpY2llbnQgZm9yIHRo ZSBOQVQgdG8ga25vdzsgdGhlIGluZm9ybWF0aW9uIG5lZWRzIHRvIHNvbWVob3cgYmUgcHJlc2Vu dGVkIHRvIHRoZSBhcHBsaWNhdGlvbi4gVGhpcyBoYXMgYmVlbiBicm91Z2h0IHVwIGJ5IExvcmVu em8gYW1vbmcgb3RoZXJzIGFzIGEgcmVxdWlyZW1lbnQgaW4gdGhlaXIgZGF0YSBjZW50ZXJzIGFu ZCBwdWJsaWMgc2VydmljZXMuDQoNClRoZSBkcmFmdCBkb2VzIG5vdCBpbXBseSB0aGF0IHRoaXMg aXMgYSByZWNvbW1lbmRlZCBvciBkZXNpcmFibGUgc29sdXRpb24sIGJ1dCBqdXN0DQp1c2VzIGl0 IHRvIGlsbHVzdHJhdGUgYSBwb3NzaWJsZSB3YXkgb2YgYWNoaWV2aW5nIGxldmVsIDEsIHRoYXQg aGF2ZSBiZWVuIHJlcG9ydGVkDQphcyBhIHNlcnZpY2UgYnkgYSBuZXR3b3JrIG9wZXJhdG9yLiBB bmQgSSBjYW4gaW1hZ2luZSB0aGF0IHNvbWUgREMgb3BlcmF0b3JzDQptYXkgd2VsbCByZW5vdW5j ZSB0byBrbm93IHRoZSBhY3R1YWwgdjYgc291cmNlIGlmIHRoZXkgY2FuIGhhdmUgYW4gZWFzeSBw YXRoIHRvDQphY2hpZXZlIHY2IGFjY2VzaWJpbGl0eSB2aWEgYSBtYW5hZ2VkIHNlcnZpY2UgbGlr ZSB0aGlzLg0KDQpBbmQsIGp1c3QgaW4gY2FzZSwgSSBwZXJzb25hbGx5IGZpbmQgbWFueSBvZiB0 aG9zZSBsb2NhdGlvbi1hd2FyZSBzZXJ2aWNlcyBtb3JlIGFuDQphbm5veWFuY2UgdGhhbiAgYW55 dGhpbmcgZWxzZTogSSBkb24ndCBzZWUgYW55IGFkdmFudGFnZSBpbiBnZXR0aW5nIGFuIEVzdG9u aWFuIFVJIG9yDQphIHNlYXJjaCBlbmdpbmUgcHJpb3JpdGl6aW5nIHJlc3VsdHMgaW4gTm9yd2Vn aWFuIGZvciBtZS4NCg0KQmUgZ29vZGUuDQoNCiJFc3RhIHZleiBubyBmYWxsYXJlbW9zLCBEb2N0 b3IgSW5maWVybm8iDQoNCkRyIERpZWdvIFIuIExvcGV6DQpUZWxlZm9uaWNhIEkrRA0KaHR0cDov L3Blb3BsZS50aWQuZXMvZGllZ28ubG9wZXovDQoNCmUtbWFpbDogZGllZ29AdGlkLmVzDQpUZWw6 ICAgICszNCA5MTMgMTI5IDA0MQ0KTW9iaWxlOiArMzQgNjgyIDA1MSAwOTENCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCg0KRXN0ZSBtZW5zYWplIHNlIGRpcmlnZSBleGNsdXNpdmFtZW50ZSBhIHN1 IGRlc3RpbmF0YXJpby4gUHVlZGUgY29uc3VsdGFyIG51ZXN0cmEgcG9sw610aWNhIGRlIGVudsOt byB5IHJlY2VwY2nDs24gZGUgY29ycmVvIGVsZWN0csOzbmljbyBlbiBlbCBlbmxhY2Ugc2l0dWFk byBtw6FzIGFiYWpvLg0KVGhpcyBtZXNzYWdlIGlzIGludGVuZGVkIGV4Y2x1c2l2ZWx5IGZvciBp dHMgYWRkcmVzc2VlLiBXZSBvbmx5IHNlbmQgYW5kIHJlY2VpdmUgZW1haWwgb24gdGhlIGJhc2lz IG9mIHRoZSB0ZXJtcyBzZXQgb3V0IGF0Lg0KaHR0cDovL3d3dy50aWQuZXMvRVMvUEFHSU5BUy9k aXNjbGFpbWVyLmFzcHgNCg== From diego@tid.es Wed Jul 11 08:14: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 7CDE021F8679 for ; Wed, 11 Jul 2012 08:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.043 X-Spam-Level: X-Spam-Status: No, score=-6.043 tagged_above=-999 required=5 tests=[AWL=0.556, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CuOCfSw7Iij7 for ; Wed, 11 Jul 2012 08:14:27 -0700 (PDT) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id D7C5021F857F for ; Wed, 11 Jul 2012 08:14:26 -0700 (PDT) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M70001U550VDI@tid.hi.inet> for v6ops@ietf.org; Wed, 11 Jul 2012 17:14:55 +0200 (MEST) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id FA.C4.02752.F689DFF4; Wed, 11 Jul 2012 17:14:55 +0200 (CEST) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0M70001TX50VDI@tid.hi.inet> for v6ops@ietf.org; Wed, 11 Jul 2012 17:14:55 +0200 (MEST) Received: from EX10-MB1-MAD.hi.inet ([fe80::a473:4f3e:f8db:1855]) by ex10-htcas4-mad.hi.inet ([::1]) with mapi id 14.02.0298.004; Wed, 11 Jul 2012 17:14:55 +0200 Date: Wed, 11 Jul 2012 15:14:54 +0000 From: "Diego R. Lopez" In-reply-to: <4FFD92E9.7020609@bogus.com> X-Originating-IP: [10.95.64.115] To: joel jaeggli Message-id: Content-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US Thread-topic: [v6ops] Draft on DC migration to IPv6 Thread-index: AQHNUqhbgWRF7Aew1UKq7qhHvsQ1MZcK3RGAgBF/VoCAB27PAIAAVzeAgAAGmIA= X-AuditID: 0a5f4e69-b7f6d6d000000ac0-13-4ffd986ffab8 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJKsWRmVeSWpSXmKPExsXCFe9nqJs/46+/wenP2hanj+1ldmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxoLF+xgL5glUfH2m3sD4gr+LkZNDQsBEYs+Gv6wQtpjEhXvr 2boYuTiEBLYzSiy9d4UZwvnJKNH35xYjhLOUUWLe9etgLSwCqhLdh3eygdhsQPaj5t/sXYwc HMICRhLfJ3mBhDkFNCXmtb5lgdigIPHn3GMwW0RAWeLPxgvMIDazgI/ElrsgrZwcvAKWEgc/ XGKHiJtJnOvcxAQRF5T4MfkeC8h4ZgF1iSlTciFKxCWaW2+yQNiKEtMWNTCC2IxAz3w/tYYJ pFxEwFjiyD5BCNNP4u3zeohjBCSW7DnPDGGLSrx8/I8V4sEvjBJX7x9gncAoMQvJEbOQHDEL 4YhZSI6YheSIBYysqxjFipOKMtMzSnITM3PSDYz0MjL1MvNSSzYxQuItcwfj8p0qhxgFOBiV eHglpn3yF2JNLCuuzD3EKMnBpCTK+73kr78QX1J+SmVGYnFGfFFpTmrxIUYJDmYlEd7yCUA5 3pTEyqrUonyYlAwHh5IEb9t0oJRgUWp6akVaZg4wqcCkmTg4Qdp5gNqzQGp4iwsSc4sz0yHy pxglpcR5K0ESAiCJjNI8uN5XjOJARwrzFoBkeYDpD67rFdBAJqCBC5b+ARlYkoiQkmpgLGtS v9a66Mgkr6Jr4u6byy3KZtRtuvs0RXeRfA5HxHyFgw3MTff+s+s/u1wy9+0e1yQGBYGuQJkz xYlmsho/WjjemU/cNS+YdXpw4b+E5HOsf2c5Cd4u/1IwN/7l6U6261Y36/Sytm/ujZ0ieetN qaRAjeJ0BbMNgb9vhT/578g5UWUhVzO/EktxRqKhFnNRcSIAx4OYEjwDAAA= References: <28DC472D-01D4-4534-97A9-6AE52BE9CC58@tid.es> <4FF70D8F.5010706@bogus.com> <4FFD92E9.7020609@bogus.com> Cc: IPv6 Ops WG Subject: Re: [v6ops] Draft on DC migration to IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 11 Jul 2012 15:14:28 -0000 DQpPbiAxMSBKdWwgMjAxMiwgYXQgMTY6NTEgLCBqb2VsIGphZWdnbGkgd3JvdGU6DQo+PiBUaGUg bWFqb3JpdHkgb2YgdGhlIGZsb3cgbGFiZWxzIHRvZGF5IGFyZSB6ZXJvLiBkYXRhY2VudGVyIG9w ZXJhdG9ycyBhcmUNCj4+IG5vdCBvcyBkZXZlbG9wZXJzIGFuZCB3ZSBkb24ndCBlbmdhZ2UgaW4g d2lzaGZ1bCB0aGlua2luZy4NCj4+DQo+PiBbQ2F0aHldIFllcywgSSBhZ3JlZSB3aXRoIHlvdSB0 aGF0ICJUaGUgbWFqb3JpdHkgb2YgdGhlIGZsb3cgbGFiZWxzIHRvZGF5IGFyZSB6ZXJvIi4gVGhl IGRhdGFjZW50ZXIgd2lsbCBzdGlsbCB1c2UgdGhlIHRyYWRpdGlvbiBvZiB0aGUgbG9hZC1iYWxh bmNlIG1ldGhvZC4gVXNpbmcgZmxvdyBsYWJlbHMgZm9yIGxvYWQgYmFsYW5jZSBpcyBhIGNvbXBs ZW1lbnRhcnkgbWV0aG9kLg0KPiBJdCdzIG5vdCBjb21wbGVtZW50YXJ5IGJlY2F1c2UgdG9kYXkg aXQgZG9lc24ndCB3b3JrLiBTby4uLiAgV2hhdCB1c2VmdWwgYWR2aWNlIGRvZXMgdGhhdCBhbW91 bnQgdG8gZm9yIHNvbWVvbmUgY29uc2lkZXJpbmcgZW5hYmxpbmcgaXB2NiBvbiB0aGVpciBsb2Fk IGJhbGFuY2VyIHRpZXI/DQoNCkl0IGlzIGEgbWVudGlvbiB0byB0aGUgYWR2YW50YWdlcyB0aGF0 IGEgZ2VuZXJhbGl6YXRpb24gb2YgdGhlIHByb3Bvc2VkIHVzYWdlIG9mIGZsb3cNCmxhYmVscyBm b3IgbG9hZCBiYWxhbmNpbmcgY2FuIGJyaW5nLiBJdCB0aGlzIGFwcGxpY2F0aW9uIG9mIGZsb3cg bGFiZWxzIGRvZXMgbm90IGdldA0KdHJhY3Rpb24gd2Ugc2hhbGwgZGVsZXRlIGl0LCBidXQgaW4g aXRzIGN1cnJlbnQgc3RhdHVzIGlzIGEgc291bmQgdGVjaG5pY2FsIHByb3Bvc2FsDQphbmQgSSBk b24ndCBzZWUgaXQgbWFrZXMgYW55IGhhcm0uDQoNCkJlIGdvb2RlLA0KDQotLQ0KIkVzdGEgdmV6 IG5vIGZhbGxhcmVtb3MsIERvY3RvciBJbmZpZXJubyINCg0KRHIgRGllZ28gUi4gTG9wZXoNClRl bGVmb25pY2EgSStEDQpodHRwOi8vcGVvcGxlLnRpZC5lcy9kaWVnby5sb3Blei8NCg0KZS1tYWls OiBkaWVnb0B0aWQuZXMNClRlbDogICAgKzM0IDkxMyAxMjkgMDQxDQpNb2JpbGU6ICszNCA2ODIg MDUxIDA5MQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpFc3RlIG1lbnNhamUgc2UgZGlyaWdl IGV4Y2x1c2l2YW1lbnRlIGEgc3UgZGVzdGluYXRhcmlvLiBQdWVkZSBjb25zdWx0YXIgbnVlc3Ry YSBwb2zDrXRpY2EgZGUgZW52w61vIHkgcmVjZXBjacOzbiBkZSBjb3JyZW8gZWxlY3Ryw7NuaWNv IGVuIGVsIGVubGFjZSBzaXR1YWRvIG3DoXMgYWJham8uDQpUaGlzIG1lc3NhZ2UgaXMgaW50ZW5k ZWQgZXhjbHVzaXZlbHkgZm9yIGl0cyBhZGRyZXNzZWUuIFdlIG9ubHkgc2VuZCBhbmQgcmVjZWl2 ZSBlbWFpbCBvbiB0aGUgYmFzaXMgb2YgdGhlIHRlcm1zIHNldCBvdXQgYXQuDQpodHRwOi8vd3d3 LnRpZC5lcy9FUy9QQUdJTkFTL2Rpc2NsYWltZXIuYXNweA0K From bingxuere@gmail.com Wed Jul 11 08:39: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 5C3EE21F85AA for ; Wed, 11 Jul 2012 08:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.18 X-Spam-Level: X-Spam-Status: No, score=-3.18 tagged_above=-999 required=5 tests=[AWL=-0.182, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yIwe5wqPuq8t for ; Wed, 11 Jul 2012 08:39:20 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id C68B921F86B5 for ; Wed, 11 Jul 2012 08:39:15 -0700 (PDT) Received: by yenq13 with SMTP id q13so1448398yen.31 for ; Wed, 11 Jul 2012 08:39: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:from:date:message-id:subject:to :cc:content-type; bh=egeg+rujRvzwb/r7OUgiwlaJmbhrSdyF6CtVUC6ihH4=; b=sjEKXqH0d7A4oV4KlG3tfA2567puPGzZz/+L+9dSRoKiBsqzWozHDTRcGbkPh4X9V0 GhXBywRXClBCzJXtNU29BWGTYqxpjYlYIT1plsrtFb0vFtDuQ534LCi3hrijfA3ozUqe 4c7pf9oGRp8mRPu9mld2oKxC/e0bgdqcYIuy8lJQlUmTHIg75wHnLK2/pwIrTZgBP3pL 47IOnKtLhGlz5DwRre4TEE8gvHWYqi1yvphLrU+LEOc/WLQAtT5rdpHFZmbdNaJVNlvR rXUwyVs7d6SodV0XOIYnfvF+bmMok2B7f3sxM0H9Ej4ghN7MfOrsRHbjxbuAphEtjshq 5rrw== Received: by 10.50.156.196 with SMTP id wg4mr15084246igb.54.1342021186073; Wed, 11 Jul 2012 08:39:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.46.6 with HTTP; Wed, 11 Jul 2012 08:39:05 -0700 (PDT) In-Reply-To: References: <28DC472D-01D4-4534-97A9-6AE52BE9CC58@tid.es> <4FF70D8F.5010706@bogus.com> From: Qiong Date: Wed, 11 Jul 2012 23:39:05 +0800 Message-ID: To: "Fred Baker (fred)" Content-Type: multipart/alternative; boundary=e89a8f3baf0113b2f904c48fa85e Cc: IPv6 Ops WG Subject: Re: [v6ops] Draft on DC migration to IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 11 Jul 2012 15:39:21 -0000 --e89a8f3baf0113b2f904c48fa85e Content-Type: text/plain; charset=UTF-8 Dear Fred, On Wed, Jul 11, 2012 at 10:42 PM, Fred Baker (fred) wrote: > > On Jul 11, 2012, at 2:39 AM, Zhouqian (Cathy) wrote: > > > [Cathy] The content provider will not lose the source address associated > with the incoming request. The source IPv6 address is translated to IPv4 > address, and the translator need retain the correspondence between IPv6 > source address and IPv4 source address. > > Yes, but for many data center applications, the application itself wants > to know the original source address in order to provide location-aware > services. So it is not sufficient for the NAT to know; the information > needs to somehow be presented to the application. This has been brought up > by Lorenzo among others as a requirement in their data centers and public > services. > With regard to this point, I think it will be a common problem in address sharing environment, especially when NAT becomes more and more prevalent (NAT444, DS-Lite, NAT64, etc.) in the future. Content providers have to face this problem that they will lose the original source address anyhow, and we should think of a way to solve this problem, right? In our trial, we have tried inserting X-forward header in NAT device to make application get to know the original address. Besides, I think HOST_ID (draft-ietf-intarea-nat-reveal-analysis) is also a possible solution. How do you think ? Thanks! Best wishes Qiong > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > -- ============================================== Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/* PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * =============================================== --e89a8f3baf0113b2f904c48fa85e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Fred,

On Wed, Jul 11, 2012 at 10:42 = PM, Fred Baker (fred) <fred@cisco.com> wrote:

On Jul 11, 2012, at 2:39 AM, Zhouqian (Cathy) wrote:

> [Cathy] The content provider will not lose the source address associat= ed with the incoming request. The source IPv6 address is translated to IPv4= address, and the translator need retain the correspondence between IPv6 so= urce address and IPv4 source address.

Yes, but for many data center applications, the application itself wa= nts to know the original source address in order to provide location-aware = services. So it is not sufficient for the NAT to know; the information need= s to somehow be presented to the application. This has been brought up by L= orenzo among others as a requirement in their data centers and public servi= ces.

With regard to this point, I think it will be a commo= n problem in address sharing environment, especially when NAT becomes more = and more prevalent (NAT444, DS-Lite, NAT64, etc.) = in the future. Content providers have to face this problem that they= will lose the original source address anyhow, and we should think of a way= to solve this problem, right?

In our trial, we have tried inserting X-forward header in NAT device to= make application get to know the original address. Besides, I think HOST_I= D (draft-ietf-intarea-nat-reveal-analysis) is also a possible solution. How= do you think ?

Thanks!

Best wishes
Qiong
=C2=A0

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



--
=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Qiong Sun
Chin= a Telecom Beijing Research Institude


Open source code:
lightw= eight 4over6: http://sourceforge.net/projects/laft6/
PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

--e89a8f3baf0113b2f904c48fa85e-- From fred@cisco.com Wed Jul 11 09:14: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 2B34111E8088; Wed, 11 Jul 2012 09:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.513 X-Spam-Level: X-Spam-Status: No, score=-110.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hyOtBjJh49zB; Wed, 11 Jul 2012 09:14:40 -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 C0F7021F8503; Wed, 11 Jul 2012 09:14:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=8595; q=dns/txt; s=iport; t=1342023311; x=1343232911; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=cHSO9YLda4ATsFVJlnRcFaIb9ujKnVfaqDEBO1rImhA=; b=e5tZTJUgJCwNNrePZAU3gS0tiu+gRfzorOhjRIvC25JVxtL6gsCgxARr 1wxH8Mwqmx2hpJVpB/ATMSziBE5TV+BJHA3nv25d5yLj2NHdhiDCwHIdo OaDTVviaTgbOctkBG63SefpDUlyoSSRsLU0ESdgOllZ3hMzZ/sWqMN0uw g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAB+m/U+tJV2d/2dsb2JhbAA7CrdqgQeCJxIBJzEHBxIBPkInBAENDhIHh2sLnUOgH4tQhH5gA5U6jiCBZoJfgVgHHA X-IronPort-AV: E=Sophos;i="4.77,567,1336348800"; d="scan'208";a="100852478" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP; 11 Jul 2012 16:15:10 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q6BGFAUj006670 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Jul 2012 16:15:10 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.118]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0298.004; Wed, 11 Jul 2012 11:15:09 -0500 From: "Fred Baker (fred)" To: Ron Bonica , The IESG Thread-Topic: draft-ietf-v6ops-ivi-icmp-address to BCP Thread-Index: AQHNX4BXdtmrpq70dEG5q/vNfpTMkw== Date: Wed, 11 Jul 2012 16:14:40 +0000 Message-ID: <6E84D620-AD6C-4D47-BDBA-ED02C00FA5F0@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.119.136] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19032.005 x-tm-as-result: No--61.186800-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: <2A1EF6DF8561DC429732A1D28D612E10@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPv6 Ops WG , "draft-ietf-v6ops-ivi-icmp-address@tools.ietf.org" Subject: [v6ops] draft-ietf-v6ops-ivi-icmp-address to BCP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 11 Jul 2012 16:14:41 -0000 Ron: I have filed this set of remarks on the datatracker, and placed the documen= t into the WG state "submitted to IESG". The following is the WG summary. Fred (1) What type of RFC is being requested (BCP, Proposed Standard, Internet S= tandard, Informational, Experimental, or Historic)? Why is this the proper = type of RFC? Is this type of RFC indicated in the title page header? This document is proposed as a Best Current Practice. The argument for that= status is as follows. The original authors, from CERNET, observed an opera= tional problem in their network, which uses a stateful IPv4/IPv6 Translator= between an IPv4-only domain (CERNET) and an IPv6-only domain (CERNET2). Th= ey considered several options, discussed two options in the working group, = and ultimately came to a two-fold recommendation. This recommendation is fo= und in sections 4 and 5 of the document, and has working group consensus as= stated. The solution meets an operational need and mitigates user confusio= n issues in such an environment, has been tested, and provably works. (2) The IESG approval announcement includes a Document Announcement Write-U= p. Please provide such a Document Announcement Write-Up. Recent examples ca= n be found in the "Action" announcements for approved documents. The approv= al announcement contains the following sections: Technical Summary A stateless IPv4/IPv6 translator may receive ICMPv6 packets containing non IPv4-translatable addresses as the source that should be passed across the translator as an ICMP packet directed to the IPv4-translatable destination. This document presents recommendations for source address translation and original source=20 address transport in ICMPv6 headers for such cases. Working Group Summary The working group process was pretty straightforward. The authors brought a= n initial proposal, which was not accepted, and working group discussion re= sulted in the document's recommendation. To the shepherd's knowledge, there= is no dissent regarding the final recommendation. Document Quality There are existing implementations of the procedure and protocol in questio= n. It has been tested in CERNET/CERNET2. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? The Document Shepherd is Fred Baker. The Responsible AD is Ron Bonica. (3) Briefly describe the review of this document that was performed by the = Document Shepherd. If this version of the document is not ready for publica= tion, please explain why the document is being forwarded to the IESG. The shepherd read the initial document, followed the working group discussi= on and spoke with the authors privately, and read the ultimate outcome. Whi= le the RFC Editor will likely make minor adjustments regarding english pros= e (the original authors are not native speakers of English), the document i= s clear and understandable. (4) Does the document Shepherd have any concerns about the depth or breadth= of the reviews that have been performed? No. The acknowledgements section notes a number of people who have commente= d or contributed text. (5) Do portions of the document need review from a particular or from broad= er perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML= , or internationalization? If so, describe the review that took place. This is not, in my view, required. The document contains no formal language= , and beyond using the ICMP extension documented in RFC 5837 imposes no pro= tocol specifics. (6) Describe any specific concerns or issues that the Document Shepherd has= with this document that the Responsible Area Director and/or the IESG shou= ld be aware of? For example, perhaps he or she is uncomfortable with certai= n parts of the document, or has concerns whether there really is a need for= it. In any event, if the WG has discussed those issues and has indicated t= hat it still wishes to advance the document, detail those concerns here. The shepherd is comfortable with the document, and working group discussion= has not surfaced remaining issues. (7) Has each author confirmed that any and all appropriate IPR disclosures = required for full conformance with the provisions of BCP 78 and BCP 79 have= already been filed. If not, explain why. Yes. (8) Has an IPR disclosure been filed that references this document? If so, = summarize any WG discussion and conclusion regarding the IPR disclosures. Not to my knowledge. (9) How solid is the WG consensus behind this document? Does it represent t= he strong concurrence of a few individuals, with others being silent, or do= es the WG as a whole understand and agree with it? As noted in the acknowledgements, working group discussion was robust and b= road. I would describe this as having broad consensus. (10) Has anyone threatened an appeal or otherwise indicated extreme discont= ent? If so, please summarise the areas of conflict in separate email messag= es to the Responsible Area Director. (It should be in a separate email beca= use this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document.= (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist).= Boilerplate checks are not enough; this check needs to be thorough. The idnits tool reports: =3D=3D The document seems to lack the recommended RFC 2119 boilerplate, e= ven if it appears to use RFC 2119 keywords -- however, there's a paragraph wi= th a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). =20 The document contains: 2. Notational Conventions The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119]. (12) Describe how the document meets any required formal review criteria, s= uch as the MIB Doctor, media type, and URI type reviews. N/A (13) Have all references within this document been identified as either nor= mative or informative? The references are all normative, and are listed as such. (14) Are there normative references to documents that are not ready for adv= ancement or are otherwise in an unclear state? If such normative references= exist, what is the plan for their completion? There are no such references. (15) Are there downward normative references references (see RFC 3967)? If = so, list these downward references to support the Area Director in the Last= Call procedure. The references are all BCPs or Proposed or Draft Standards. There are no do= wnward references as a BCP. (16) Will publication of this document change the status of any existing RF= Cs? Are those RFCs listed on the title page header, listed in the abstract,= and discussed in the introduction? If the RFCs are not listed in the Abstr= act and Introduction, explain why, and point to the part of the document wh= ere the relationship of this document to the other RFCs is discussed. If th= is information is not in the document, explain why the WG considers it unne= cessary. This document uses other RFCs, but does not updated them. (17) Describe the Document Shepherd's review of the IANA considerations sec= tion, especially with regard to its consistency with the body of the docume= nt. Confirm that all protocol extensions that the document makes are associ= ated with the appropriate reservations in IANA registries. Confirm that any= referenced IANA registries have been clearly identified. Confirm that newl= y created IANA registries include a detailed specification of the initial c= ontents for the registry, that allocations procedures for future registrati= ons are defined, and a reasonable name for the new registry has been sugges= ted (see RFC 5226). The document doesn't depend on IANA registries or create new ones. (18) List any new IANA registries that require Expert Review for future all= ocations. Provide any public guidance that the IESG would find useful in se= lecting the IANA Experts for these new registries. N/A (19) Describe reviews and automated checks performed by the Document Shephe= rd to validate sections of the document written in a formal language, such = as XML code, BNF rules, MIB definitions, etc. N/A= From fred@cisco.com Wed Jul 11 09:22: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 85A5C11E80CF for ; Wed, 11 Jul 2012 09:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.223 X-Spam-Level: X-Spam-Status: No, score=-110.223 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RDPIalVdygvE for ; Wed, 11 Jul 2012 09:22:43 -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 5E02221F867B for ; Wed, 11 Jul 2012 09:22:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=7754; q=dns/txt; s=iport; t=1342023794; x=1343233394; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=eJZHVFQisI6hvXQ8SB+ILu4hG2Mmr6iy3ByLQ5KzTyk=; b=OM1aADwwf/aGjJU9wswxwDKWEl89eFMPJNa7I19vrySHl+VuK8Z143AD jZ7kf26+i/B4TsGOSbPzM7ig0wXBnRpejJ/ZGIYLEebupbgXXG4Vq8EL2 au1FVKgMeDVoG+SUc5mzo/YA9dXe2q3vFOvSMZIuIxmqjv2LFb2o7hQbd U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AowGAJSn/U+tJV2Z/2dsb2JhbAA7CqcNkF6BB4IhAQEEAQEBDwFbCxACAQg/BycLFBECBA4FGweHawudNqAfi0AQhH5gA5U6gRKNDoFmgl8 X-IronPort-AV: E=Sophos;i="4.77,569,1336348800"; d="scan'208,217";a="100883427" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 11 Jul 2012 16:23:14 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q6BGND1X008477 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Jul 2012 16:23:13 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.118]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0298.004; Wed, 11 Jul 2012 11:23:13 -0500 From: "Fred Baker (fred)" To: Qiong Thread-Topic: [v6ops] Draft on DC migration to IPv6 Thread-Index: AQHNUtH08AdBnuzG2kudzG/wrZXEvg== Date: Wed, 11 Jul 2012 16:22:44 +0000 Message-ID: <56D50253-703D-400D-AED9-2C692EE656D4@cisco.com> References: <28DC472D-01D4-4534-97A9-6AE52BE9CC58@tid.es> <4FF70D8F.5010706@bogus.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.119.136] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19032.005 x-tm-as-result: No--41.406500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_56D50253703D400DAED92C692EE656D4ciscocom_" MIME-Version: 1.0 Cc: IPv6 Ops WG Subject: Re: [v6ops] Draft on DC migration to IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 11 Jul 2012 16:22:44 -0000 --_000_56D50253703D400DAED92C692EE656D4ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Jul 11, 2012, at 8:39 AM, Qiong wrote: Dear Fred, On Wed, Jul 11, 2012 at 10:42 PM, Fred Baker (fred) > wrote: On Jul 11, 2012, at 2:39 AM, Zhouqian (Cathy) wrote: > [Cathy] The content provider will not lose the source address associated = with the incoming request. The source IPv6 address is translated to IPv4 ad= dress, and the translator need retain the correspondence between IPv6 sourc= e address and IPv4 source address. Yes, but for many data center applications, the application itself wants to= know the original source address in order to provide location-aware servic= es. So it is not sufficient for the NAT to know; the information needs to s= omehow be presented to the application. This has been brought up by Lorenzo= among others as a requirement in their data centers and public services. With regard to this point, I think it will be a common problem in address s= haring environment, especially when NAT becomes more and more prevalent (NA= T444, DS-Lite, NAT64, etc.) in the future. Content providers have to face t= his problem that they will lose the original source address anyhow, and we = should think of a way to solve this problem, right? A solution needs to be arrived at; I'm not sure we need to think of the sol= ution, but we should at least identify the issue. In our trial, we have tried inserting X-forward header in NAT device to mak= e application get to know the original address. Besides, I think HOST_ID (d= raft-ietf-intarea-nat-reveal-analysis) is also a possible solution. How do = you think ? Those are possible solutions. They represent adding some form of Applicatio= n Layer Gateway, which is necessarily application-specific and to my knowle= dge are not defined for a variety of applications. My point to Cathy was th= at it is inadequate to dismiss the issue with "the NAT knows the translatio= n"; while true at the network layer, it misses an important set of issues e= ntirely. I suspect that this document is not complete without addressing the applica= tion geolocation issues. Thanks! Best wishes Qiong _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: http://sourceforge.net/projects/laft6/ PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --_000_56D50253703D400DAED92C692EE656D4ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
On Jul 11, 2012, at 8:39 AM, Qiong wrote:

Dear Fred,

On Wed, Jul 11, 2012 at 10:42 PM, Fred Baker (fr= ed) <fred@cisco.com&= gt; wrote:

On Jul 11, 2012, at 2:39 AM, Zhouqian (Cathy) wrote:

> [Cathy] The content provider will not lose the source address associat= ed with the incoming request. The source IPv6 address is translated to IPv4= address, and the translator need retain the correspondence between IPv6 so= urce address and IPv4 source address.

Yes, but for many data center applications, the application itself wants to= know the original source address in order to provide location-aware servic= es. So it is not sufficient for the NAT to know; the information needs to s= omehow be presented to the application. This has been brought up by Lorenzo among others as a requirement in their= data centers and public services.

With regard to this point, I think it will be a common problem in address s= haring environment, especially when NAT becomes more and more prevalent (NAT444, DS-Lite, NAT64, etc.) in= the future. Content providers have to face this problem that they will los= e the original source address anyhow, and we should think of a way to solve= this problem, right?

A solution needs to be arrived at; I'm not sure we need to think of th= e solution, but we should at least identify the issue.

In our trial, we have tried inserting X-forward header in NAT device t= o make application get to know the original address. Besides, I think HOST_= ID (draft-ietf-intarea-nat-reveal-analysis) is also a possible solution. Ho= w do you think ?

Those are possible solutions. They represent adding some form of Appli= cation Layer Gateway, which is necessarily application-specific and to my k= nowledge are not defined for a variety of applications. My point to Cathy w= as that it is inadequate to dismiss the issue with "the NAT knows the translation"; while true at th= e network layer, it misses an important set of issues entirely. 

I suspect that this document is not complete without addressing the ap= plication geolocation issues.

Thanks!

Best wishes
Qiong
 

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



--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Qiong Sun
China Telecom Beijing Research Institude


Open source code:
lightweight 4over6: http://sourceforge.net/projects/laft6/
PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D



--_000_56D50253703D400DAED92C692EE656D4ciscocom_-- From fred@cisco.com Wed Jul 11 09:48: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 46E1121F84F2 for ; Wed, 11 Jul 2012 09:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.259 X-Spam-Level: X-Spam-Status: No, score=-110.259 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r1zRW4BL0BCC for ; Wed, 11 Jul 2012 09:48:28 -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 5545021F84EF for ; Wed, 11 Jul 2012 09:48:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=4097; q=dns/txt; s=iport; t=1342025339; x=1343234939; h=from:to:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=sRCZ429o4L8ccNWsn4mdiPMD5LG7M38qiBMd4XtmpA0=; b=TfuNm83NKhz2hTTEVhYvjCY5vlQWm/Y+tRswTOLW77/5r3jmdMY/vJsS p90bihsKPXkftC0Gteyj1wAilVWtyzZPfyw1YmBCXoYAbwKwjUhGlAWNo 51hBzkpT6mRZYKVu7daPuWPTsSudirC3XoC+16ofeV6fEiMd48jejCK4e w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFADSt/U+tJXG8/2dsb2JhbABFtUQBgieBB4IgAQEBAwEBAg8BJ0QJAgIBGQMBAh8QGw0KGwIIAgQBEiKHZQYLnTWgHwSLPIUOYAOTEYIpjiCBZoJf X-IronPort-AV: E=Sophos;i="4.77,569,1336348800"; d="scan'208";a="100864705" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 11 Jul 2012 16:48:59 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q6BGmwbI013447 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Jul 2012 16:48:59 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.118]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0298.004; Wed, 11 Jul 2012 11:48:58 -0500 From: "Fred Baker (fred)" To: IPv6 Ops WG , opsec chairs Thread-Topic: RIPE-555 fundamentaly changes the way how we can filter IPv6 & IPv4 martians? Thread-Index: AQHNX4Qkp8zLrJW+6UucE44WZaulUQ== Date: Wed, 11 Jul 2012 16:48:29 +0000 Message-ID: References: <4FFDACB2.9080106@switch.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.119.136] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19032.005 x-tm-as-result: No--56.785200-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: <54F7C83A4F9B914696E4BF4ABD19795C@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [v6ops] Fwd: RIPE-555 fundamentaly changes the way how we can filter IPv6 & IPv4 martians? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 11 Jul 2012 16:48:29 -0000 FYI, in case you had not seen it. > From: Chris Welti > Date: July 11, 2012 9:41:22 AM PDT > To: > Subject: RIPE-555 fundamentaly changes the way how we can filter IPv6 & I= Pv4 martians? >=20 > Dear IPv6 (and IPv4) network operators >=20 > RIPE has recently published RIPE-555 (Address space managed by the RIPE N= CC), which > replaces RIPE-510. >=20 > With RIPE-510 (http://www.ripe.net/ripe/docs/ripe-510), it was quite clea= r that > all IPv6 address allocations smaller than a /32 (longer prefixes) were co= ming out of > just a few special ranges: > a) Internet Exchange Points: up to /64 out of 2001:7f8::/32 > b) Root Name Servers: up to /64 out of 2001:7f8::/29 > c) Anycasting TLD nameservers: /48 out of 2001:678::/29 > d) IPv6 PI address space: up to /64 out of 2001:678::/29 >=20 > Now, the new document RIPE-555 (http://www.ripe.net/ripe/docs/ripe-555), = drops all > these special ranges except for IPv6 PI space. >=20 > The section Longest Prefix Tables, which always included a list of IPv4 &= IPv6 prefix > ranges and their longest allocated or assigned prefix in that range has b= een > drastically reduced to just read as follows: >=20 > "The smallest prefix assigned by the RIPE NCC from any IPv4 range is a /2= 9. > The smallest prefix assigned by the RIPE NCC from any IPv6 range is a /48= ." >=20 > Additionally the section "Routing decisions" has been adjusted to just sa= y: > "Routing decisions are the responsibility of network operators". > The sentence "Network operators taking routing decisions based on prefix = length > are requested and encouraged to route at least blocks of sizes correspond= ing to > the longest prefix and larger" >=20 > In the past we have used RIPE-510 and its predecessors as a basis for our= martian > filters, where we deny prefixes that are longer than the minimum allocati= on sizes > for a particular address range allocated/assigned by RIPE. >=20 > To me as an operator this raises the question on how I should now filter = martians for > the RIPE region? > Since I can not rely on the fact that longer prefix lengths just happen i= n > certain well defined ranges (minimum allocation per address range) anymor= e, > I see only three possibilites: >=20 > 1) Generate a prefix-list out of > ftp://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-extended-latest > which includes all valid allocated/assigned IPv4 and IPv6 prefixes. Then = only accept > those prefixes. That list would contain hundreds of thousands of entries = and would have > to be built at least daily, so newly allocated prefixes can be properly a= ccepted. >=20 > 2) Just filter out prefixes that are longer than /48 for v6 and longer th= an /29 > for v4 and keep all the rest. >=20 > 3) Still filter the way we did before and risk that new "valid" longer pr= efix allocations > are not accepted. >=20 > Option 1 is not really feasible due to the huge size of the prefix-list >=20 > Option 2 means that basically I'm opening up the possibility for accident= ial (leaks) > or purposeful (traffic engineering) leaks of potentially 65535 /48 v6 pre= fixes per /32, > and there are a lot of possible /32s :) > Even though it's less for v4 it's still a couple of millions of /29 v4 pr= efixes > That could result in a lot of addresses in the routing table! >=20 > Option 3 also does not sound like a good idea, as that would lead to hole= s in the routing > table. >=20 > Similar concerns have also been raised by my colleague Alex on the [ncc-s= ervices-wg] list > but so far nobody else has chimed in. >=20 > So how and on what basis do you create your martian filters? > Or is this a non-issue for you? >=20 > Best regards, > Chris / AS559 >=20 > SWITCH > Serving Swiss Universities > -------------------------- > Chris Welti, Network Engineer > Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland > phone +41 44 268 15 30, fax +41 44 268 15 68 > chris.welti@switch.ch > http://www.switch.ch=20 From joelja@bogus.com Wed Jul 11 10:10: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 06D3911E80E8 for ; Wed, 11 Jul 2012 10:10:17 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2bjoUJy4LfOL for ; Wed, 11 Jul 2012 10:10:16 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 4174E11E80EF for ; Wed, 11 Jul 2012 10:10:16 -0700 (PDT) Received: from Joels-MacBook-Pro.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 q6BHAioP059450 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 11 Jul 2012 17:10:45 GMT (envelope-from joelja@bogus.com) Message-ID: <4FFDB38F.3080206@bogus.com> Date: Wed, 11 Jul 2012 10:10:39 -0700 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Qiong References: <28DC472D-01D4-4534-97A9-6AE52BE9CC58@tid.es> <4FF70D8F.5010706@bogus.com> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 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, 11 Jul 2012 17:10:45 +0000 (UTC) Cc: IPv6 Ops WG Subject: Re: [v6ops] Draft on DC migration to IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 11 Jul 2012 17:10:17 -0000 On 7/11/12 08:39 , Qiong wrote: > Dear Fred, > > On Wed, Jul 11, 2012 at 10:42 PM, Fred Baker (fred) > wrote: > > > On Jul 11, 2012, at 2:39 AM, Zhouqian (Cathy) wrote: > > > [Cathy] The content provider will not lose the source address > associated with the incoming request. The source IPv6 address is > translated to IPv4 address, and the translator need retain the > correspondence between IPv6 source address and IPv4 source address. > > Yes, but for many data center applications, the application itself > wants to know the original source address in order to provide > location-aware services. So it is not sufficient for the NAT to > know; the information needs to somehow be presented to the > application. This has been brought up by Lorenzo among others as a > requirement in their data centers and public services. > > > With regard to this point, I think it will be a common problem in > address sharing environment, especially when NAT becomes more and more > prevalent (NAT444, DS-Lite, NAT64, etc.) in the future. Content > providers have to face this problem that they will lose the original > source address anyhow, and we should think of a way to solve this > problem, right? The fact that the carrier the customer is behind might also nat their source address or that they have a residential gateway is a rather more distant problem then an nat64 located rather closer to me. I still want to know that the source is verizon's cgnat rather than my local nat64 gateway. > In our trial, we have tried inserting X-forward header in NAT device to > make application get to know the original address. Besides, I think > HOST_ID (draft-ietf-intarea-nat-reveal-analysis) is also a possible > solution. Not within a draft that operates within the confines of existing reality it isn't. > How do you think ? so you're rewriting the protocol stream on the fly, or this really an alg and not a nat box, and I imagine you don't do http(s) in the case of the former. > Thanks! > > Best wishes > Qiong > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > > > -- > ============================================== > Qiong Sun > China Telecom Beijing Research Institude > > > Open source code: > lightweight 4over6: /http://sourceforge.net/projects/laft6// > PCP-natcoord:/http://sourceforge.net/projects/pcpportsetdemo/ / > =============================================== > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From fred@cisco.com Wed Jul 11 10: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 9378E11E811B for ; Wed, 11 Jul 2012 10:20:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.43 X-Spam-Level: X-Spam-Status: No, score=-110.43 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQjIVGR5R0y4 for ; Wed, 11 Jul 2012 10:20:53 -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 566BB11E813C for ; Wed, 11 Jul 2012 10:20:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=7491; q=dns/txt; s=iport; t=1342027284; x=1343236884; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=3s4b/wUYpameeEWQM3TCjUhchPOJLxvPQfaTxZ09ZU4=; b=hMfjaHwj5HjdKug7dWGx0PBuejnZs0Wu12L6UEN2quhMLQVrKfsRDevO z/H0+hJW6szkk9EMlMtFpmzYjX459jJ6rXTaQ9Tqx1OWdA2Mhedr0OnHk NmU61Qg22vycpy6pkP38DXM0zxD0S/Nvj2jYEzxr37zyEcj8Kz5dkJL5C Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAKW1/U+tJV2Y/2dsb2JhbAA7CrdsgQeCJxIBJzEHAgUSAT5CJwQODhmHawudNqAai1CEfmADlTqOIIFmgl+BWAcc X-IronPort-AV: E=Sophos;i="4.77,569,1336348800"; d="scan'208";a="100897660" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 11 Jul 2012 17:21:24 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q6BHLOsb017115 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Jul 2012 17:21:24 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.118]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0298.004; Wed, 11 Jul 2012 12:21:23 -0500 From: "Fred Baker (fred)" To: Ron Bonica Thread-Topic: draft-ietf-v6ops-wireline-incremental-ipv6 to Informational Thread-Index: AQHNX4mYQTpJm8o3QUq6U4hP+CMi4w== Date: Wed, 11 Jul 2012 17:20:54 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.119.136] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19032.005 x-tm-as-result: No--62.218100-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: <861439A9AF33134A9E324E98B171F192@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-v6ops-wireline-incremental-ipv6@tools.ietf.org" , IPv6 Ops WG Subject: [v6ops] draft-ietf-v6ops-wireline-incremental-ipv6 to Informational X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 11 Jul 2012 17:20:54 -0000 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet S= tandard, Informational, Experimental, or Historic)? Why is this the proper = type of RFC? Is this type of RFC indicated in the title page header? This document is recommended as "informational"; it is essentially a white = paper describing a phased approach to operational deployment of IPv6. (2) The IESG approval announcement includes a Document Announcement Write-U= p. Please provide such a Document Announcement Write-Up. Recent examples ca= n be found in the "Action" announcements for approved documents. The approv= al announcement contains the following sections: 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 kno= wledge, while every operator has not taken (or considered) taking every ste= p 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 th= ey should be thought through. Document Quality The framework is well written and has stood up under review. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? The Document Shepherd is Fred Baker. The Responsible AD is Ron Bonica. (3) Briefly describe the review of this document that was performed by the = Document Shepherd. If this version of the document is not ready for publica= tion, please explain why the document is being forwarded to the IESG. The shepherd read the initial document, followed the working group discussi= on and spoke with the authors privately, and read the ultimate outcome. The= document is clear and understandable. (4) Does the document Shepherd have any concerns about the depth or breadth= of the reviews that have been performed? No. The acknowledgements section notes a number of people who have commente= d or contributed text. (5) Do portions of the document need review from a particular or from broad= er perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML= , or internationalization? If so, describe the review that took place. This is not, in my view, required. The document contains no formal language= , and imposes no protocol specifics. (6) Describe any specific concerns or issues that the Document Shepherd has= with this document that the Responsible Area Director and/or the IESG shou= ld be aware of? For example, perhaps he or she is uncomfortable with certai= n parts of the document, or has concerns whether there really is a need for= it. In any event, if the WG has discussed those issues and has indicated t= hat it still wishes to advance the document, detail those concerns here. The shepherd is comfortable with the document, and working group discussion= has not surfaced remaining issues. (7) Has each author confirmed that any and all appropriate IPR disclosures = required for full conformance with the provisions of BCP 78 and BCP 79 have= already been filed. If not, explain why. Yes. (8) Has an IPR disclosure been filed that references this document? If so, = summarize any WG discussion and conclusion regarding the IPR disclosures. Not to my knowledge. (9) How solid is the WG consensus behind this document? Does it represent t= he strong concurrence of a few individuals, with others being silent, or do= es the WG as a whole understand and agree with it? As noted in the acknowledgements, working group discussion was robust and b= road. I would describe this as having broad consensus. (10) Has anyone threatened an appeal or otherwise indicated extreme discont= ent? If so, please summarise the areas of conflict in separate email messag= es to the Responsible Area Director. (It should be in a separate email beca= use this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document.= (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist).= Boilerplate checks are not enough; this check needs to be thorough. I found no nits. (12) Describe how the document meets any required formal review criteria, s= uch as the MIB Doctor, media type, and URI type reviews. N/A (13) Have all references within this document been identified as either nor= mative or informative? The references are list as normative and informative. (14) Are there normative references to documents that are not ready for adv= ancement or are otherwise in an unclear state? If such normative references= exist, what is the plan for their completion? There are no such references. (15) Are there downward normative references references (see RFC 3967)? If = so, list these downward references to support the Area Director in the Last= Call procedure. An informational document cannot have downward references. (16) Will publication of this document change the status of any existing RF= Cs? Are those RFCs listed on the title page header, listed in the abstract,= and discussed in the introduction? If the RFCs are not listed in the Abstr= act and Introduction, explain why, and point to the part of the document wh= ere the relationship of this document to the other RFCs is discussed. If th= is information is not in the document, explain why the WG considers it unne= cessary. This document uses other RFCs, but does not update them. (17) Describe the Document Shepherd's review of the IANA considerations sec= tion, especially with regard to its consistency with the body of the docume= nt. Confirm that all protocol extensions that the document makes are associ= ated with the appropriate reservations in IANA registries. Confirm that any= referenced IANA registries have been clearly identified. Confirm that newl= y created IANA registries include a detailed specification of the initial c= ontents for the registry, that allocations procedures for future registrati= ons are defined, and a reasonable name for the new registry has been sugges= ted (see RFC 5226). The document doesn't depend on IANA registries or create new ones. (18) List any new IANA registries that require Expert Review for future all= ocations. Provide any public guidance that the IESG would find useful in se= lecting the IANA Experts for these new registries. N/A (19) Describe reviews and automated checks performed by the Document Shephe= rd to validate sections of the document written in a formal language, such = as XML code, BNF rules, MIB definitions, etc. N/A= From swmike@swm.pp.se Wed Jul 11 10:29: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 F1E7B11E8122 for ; Wed, 11 Jul 2012 10:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rXggtjOan+xd for ; Wed, 11 Jul 2012 10:29:56 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 98BC611E8117 for ; Wed, 11 Jul 2012 10:29:55 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id E46C29E; Wed, 11 Jul 2012 19:30:24 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id D63619C; Wed, 11 Jul 2012 19:30:24 +0200 (CEST) Date: Wed, 11 Jul 2012 19:30:24 +0200 (CEST) From: Mikael Abrahamsson To: "Fred Baker (fred)" In-Reply-To: Message-ID: References: <4FFDACB2.9080106@switch.ch> 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] Fwd: RIPE-555 fundamentaly changes the way how we can filter IPv6 & IPv4 martians? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 11 Jul 2012 17:29:59 -0000 On Wed, 11 Jul 2012, Fred Baker (fred) wrote: >> With RIPE-510 (http://www.ripe.net/ripe/docs/ripe-510), it was quite clear that >> all IPv6 address allocations smaller than a /32 (longer prefixes) were coming out of >> just a few special ranges: >> a) Internet Exchange Points: up to /64 out of 2001:7f8::/32 >> b) Root Name Servers: up to /64 out of 2001:7f8::/29 >> c) Anycasting TLD nameservers: /48 out of 2001:678::/29 >> d) IPv6 PI address space: up to /64 out of 2001:678::/29 Just as FYI, I have been in contact with RIPC NCC staff. Some clarifications might be in order: Root name servers are /32s now. IXP networks might still be affected by a simplified filtering policy of allowing /48 out of 2001:678::/29 and /32 out of rest of RIPE space, but personally I don't think IXP networks should be world reachable, but that's a different discussion I guess. Not touching the IPv4 part of the message... -- Mikael Abrahamsson email: swmike@swm.pp.se From turchanyi.geza@gmail.com Wed Jul 11 10:57: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 0FD9111E8116 for ; Wed, 11 Jul 2012 10:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QFvXBXAjoxS7 for ; Wed, 11 Jul 2012 10:57:18 -0700 (PDT) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by ietfa.amsl.com (Postfix) with ESMTP id 70E9611E80DB for ; Wed, 11 Jul 2012 10:57:18 -0700 (PDT) Received: by yhfs35 with SMTP id s35so2287539yhf.27 for ; Wed, 11 Jul 2012 10:57: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; bh=OYKHJMmgQHxzDeHCajbICDSjn46goIiOmBI1tK6eCrg=; b=sciTUx5jU7pHJW2qcFMNauX+/zNEDFyAu4CAETQj9oODh0lvK2jCfWv2tLFywqXOx4 hwtJ6iY1zt8cYzy5m5vPtkXPH6sQccUWpCzW/dZAhOf6N1CJA4vOvvAfSmEcfxNoXyKB x9VVLTF3NKyDKaPTk32dZyDnobnunrdBOWv1MVQA67Zqz8csEu+2z+8PgtPul6IwFJDa T7nZP22wUFaVA5Mk2u2U8iDbYYXVWblMf1YhctAwqGvqzaz/FvntlSgfBGtjB3EzjmRi LLpo4+NYkwnArrkZRC24EGjN8I3z90lELdQQerb1Wtawh7eFT0/DrjC3Ck7+aiAMk4qC QX7A== MIME-Version: 1.0 Received: by 10.66.82.228 with SMTP id l4mr47142670pay.41.1342029468833; Wed, 11 Jul 2012 10:57:48 -0700 (PDT) Received: by 10.66.228.131 with HTTP; Wed, 11 Jul 2012 10:57:48 -0700 (PDT) In-Reply-To: References: <4FFDACB2.9080106@switch.ch> Date: Wed, 11 Jul 2012 19:57:48 +0200 Message-ID: From: Turchanyi Geza To: "Fred Baker (fred)" Content-Type: multipart/alternative; boundary=f46d042ef589c4968804c4919519 Cc: IPv6 Ops WG , opsec chairs Subject: Re: [v6ops] Fwd: RIPE-555 fundamentaly changes the way how we can filter IPv6 & IPv4 martians? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 11 Jul 2012 17:57:19 -0000 --f46d042ef589c4968804c4919519 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Jul 11, 2012 at 6:48 PM, Fred Baker (fred) wrote: > FYI, in case you had not seen it. > > > > From: Chris Welti > > Date: July 11, 2012 9:41:22 AM PDT > > To: > > Subject: RIPE-555 fundamentaly changes the way how we can filter IPv6 & > IPv4 martians? > > > > Dear IPv6 (and IPv4) network operators > > > > RIPE has recently published RIPE-555 (Address space managed by the RIPE > NCC), which > > replaces RIPE-510. > ---- > Additionally the section "Routing decisions" has been adjusted to just say: > > "Routing decisions are the responsibility of network operators". > > The sentence "Network operators taking routing decisions based on prefi= x > length > > are requested and encouraged to route at least blocks of sizes > corresponding to > > the longest prefix and larger" > --- There were several people, including me, that openly argued against some new RIPE policies that neglect the consecquences at the routing level, however, there is a noisy minority acting at the RIPE policy working group, overlooking reasonable arguments. Perhaps we should return to these questions against. Many thanks Chris, for your comments! G=E9za --f46d042ef589c4968804c4919519 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Jul 11, 2012 at 6:48 PM, Fred Ba= ker (fred) <fred@cisco.com> wrote:
FYI, in case you had not seen it.


> From: Chris Welti <chris.w= elti@switch.ch>
> Date: July 11, 2012 9:41:22 AM PDT
> To: <ipv6-ops@lists.cl= uenet.de>
> Subject: RIPE-555 fundamentaly changes the way how we can filter IPv6 = & IPv4 martians?
>
> Dear IPv6 (and IPv4) network operators
>
> RIPE has recently published RIPE-555 (Address space managed by the RIP= E NCC), which
> replaces RIPE-510.
----

> Additionally = the section "Routing decisions" has been adjusted to just say:
> "Routing decisions are the responsibility of network operators&qu= ot;.
> The sentence "Network operators taking routing decisions based on= prefix length
> are requested and encouraged to route at least blocks of sizes corresp= onding to
> the longest prefix and larger"

---

There were several people, including me, that openly argued ag= ainst some new RIPE policies that neglect the consecquences at the routing = level, however, there is a noisy minority acting at the RIPE policy working= group, overlooking reasonable arguments.

Perhaps we should return to these questions against.

Many thanks= Chris, for your comments!
=A0

G=E9za
--f46d042ef589c4968804c4919519-- From gert@space.net Wed Jul 11 11:24: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 359B511E8110 for ; Wed, 11 Jul 2012 11:24: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XnwyCmAcob+1 for ; Wed, 11 Jul 2012 11:24:41 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 595E511E8101 for ; Wed, 11 Jul 2012 11:24:40 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 1F92EF8C5F for ; Wed, 11 Jul 2012 20:25:10 +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 67DCCF8C5A for ; Wed, 11 Jul 2012 20:25:07 +0200 (CEST) Received: (qmail 69664 invoked by uid 1007); 11 Jul 2012 20:25:07 +0200 Date: Wed, 11 Jul 2012 20:25:07 +0200 From: Gert Doering To: Turchanyi Geza Message-ID: <20120711182507.GK38127@Space.Net> References: <4FFDACB2.9080106@switch.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.21 (2010-09-15) Cc: IPv6 Ops WG , opsec chairs Subject: Re: [v6ops] Fwd: RIPE-555 fundamentaly changes the way how we can filter IPv6 & IPv4 martians? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 11 Jul 2012 18:24:42 -0000 Hi, On Wed, Jul 11, 2012 at 07:57:48PM +0200, Turchanyi Geza wrote: > There were several people, including me, that openly argued against some > new RIPE policies that neglect the consecquences at the routing level, > however, there is a noisy minority acting at the RIPE policy working group, > overlooking reasonable arguments. *sigh*. This really shouldn't be here, but I can't let it stand as it is. We had broad support in the RIPE address policy working group to change some requirements on IPv6 PI assignments (namely removing the "multihoming requirements", which were ill-defined to begin with), with a "noisy minority", mostly consisting of Geza, objecting against this. Now going around and claiming that this was a "noisy minority acting at the RIPE policy working group" is twisting reality somewhat - it was "significantly more voices supporting the proposal than objecting", and that's "rough consensus" - and the arguments were FUD-based, not "reasonable". All of this happened openly on the RIPE address policy working group mailing list, which has a public archive, so everyone can make up their own mind of the situation. OTOH, the address policy WG had nothing to do with the change of RIPE-510 to RIPE-555, and I'm still considering whether I see this as a matter-of-fact declaration (as soon as IPv4 runs out, every sort of minimum allocation size for individual /8s is moot, as people will want all the scraps and bits left over), or as a problem. For IPv6, I'm not not exactly happy with the way it is written now, implying that /48s could be assigned from anywhere in the address space. But then, upstreams really should filter their customers by IRR or RPKI, and not "by prefix ranges", as someone malevolent could do enough harm by announcing a million /32s which would pass anyone's "/32s permitted from RIR /12 ranges" filters just fine... Gert Doering -- address policy WG chair *and* network operator -- 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 cb.list6@gmail.com Wed Jul 11 11:26: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 AAB8D11E8122 for ; Wed, 11 Jul 2012 11:26:55 -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.650, BAYES_00=-2.599, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sZk0YoDvnt16 for ; Wed, 11 Jul 2012 11:26:54 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id BD87311E8121 for ; Wed, 11 Jul 2012 11:26:54 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so2537535pbc.31 for ; Wed, 11 Jul 2012 11:27: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=m0D+PFIDMPB8ZqqzeiemnRJfXxTOszEoWvV+4uAR1U4=; b=pQ/SMqdI42OUm6qKcbN8U07boYhhOfJIDT70fpV0rKtU7Ih+WGg6oV2wcwVeFfp0L3 8hFuDZFXhyd+la6DmLG0XeEURMEqD5iXfTPU6ZKukWzFdA7j2d1kjJW7jLJBo1hZnGHV PTsSEuNF9Ak02sHZYcrZ5fQPuETSe65XQkKJHrTY3c/ETDTOg3y+/aKqxTAEHT+w0StW v/OIp9FpPI0Dir4ga85LVtD2l2MBN97Qn34MUWC0wJqrhOeDNgQq3O2Vv+LO9KgFIa+j TPsBz5C/kgF8sax813F4/ypHhZtkTGSFpdu2JJVV/lyJ/kjkGqJyoStKF5TUtdrr7EFW YUTw== MIME-Version: 1.0 Received: by 10.68.221.10 with SMTP id qa10mr80352609pbc.154.1342031245781; Wed, 11 Jul 2012 11:27:25 -0700 (PDT) Received: by 10.142.100.9 with HTTP; Wed, 11 Jul 2012 11:27:25 -0700 (PDT) Received: by 10.142.100.9 with HTTP; Wed, 11 Jul 2012 11:27:25 -0700 (PDT) In-Reply-To: References: <20120625002907.24191.87700.idtracker@ietfa.amsl.com> <20120625093320kawashimam@mail.jp.nec.com> <79510968-0EE0-473F-A0B1-DD4B35092523@laposte.net> Date: Wed, 11 Jul 2012 11:27:25 -0700 Message-ID: From: Cameron Byrne To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=e89a8ff24801aeab7004c491ff4e Cc: v6ops v6ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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, 11 Jul 2012 18:26:55 -0000 --e89a8ff24801aeab7004c491ff4e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Jul 11, 2012 8:33 AM, "R=E9mi Despr=E9s" wrot= e: > > Hi, Lorenzo, > > Comments about your two mails inline. > > > 2012-07-11 =E0 11:36, Lorenzo Colitti: > >> On Mon, Jun 25, 2012 at 4:34 PM, R=E9mi Despr=E9s wrote: >>> >>> Hi, Masanobu-san, >>> >>> I have to confirm, no surprise, that I object to its BCP status because= : >>> - it proposes more than just a combination of existing RFCs >> >> >> What does it propose that's not just a combination of existing RFCs? It seems to me that the document essentially just says "you can build a service called 464xlat by combining the behaviour specified by these two RFCs, and choosing these particular values as parameters". It's not specifying any new behaviour. > > > (*) > At least two points (both valuable IMHO) specify new behaviors: > - In section 3: << The CLAT does not comply with the sentence "Both IPv4-translatable IPv6 addresses and IPv4-converted IPv6 addresses SHOULD use the same prefix." that is described on Section 3.3 in [RFC6052] due to using different IPv6 prefixes for CLAT-side and PLAT-side IPv4 addresses. >= > > - There is a request to IANA in section 10. > > BCP is therefore inappropriate AFAIK. > Whether Experimental would be better than Informational remains however open AFAIAC. > >> >>> >>> - it has close relationship with subjects discussed in Softwires such as MAP and 4rd, without serious examination of this relationship. >> >> >> I don't understand why this would apply differently to a BCP or to an informational document. Also, I don't understand why this is relevant at all. The softwires work is attempting to solve a similar problem by defining new technology, and the approaches don't overlap. > > > Hastily freezing a recommended behavior while a better one is being currently worked on, is in my understanding inappropriate. > > In particular, improved transparency to IPv4 null checksums and to DF=3D1 fragmented packets of RFC 4821 is worth considering (as proposed with the NAT64+ of tools.ietf.org/html/draft-ietf-softwire-4rd-02). > Better? I thought we resolved long ago to not fall into these types of unqualified statements. CB > OTOH, as I said, publishing 4X4XLAT now is IMHO valuable (be it as informational or experimental): it deals with a subject not covered in other IETF documents. > >> >> Cheers, >> Lorenzo > > > > > 2012-07-11 11:38, Lorenzo Colitti : > >> On Tue, Jul 3, 2012 at 5:39 PM, R=E9mi Despr=E9s wrote: >>> >>> A good reason to refuse Informational or Experimental hasn't been seen on this list. >> >> >> An informational document is not a standards document. > > > Neither a BCP AFAIK. > >> Thus, it cannot prevent the development of multiple incompatible implementations. > > > (**) > 464XLAT defines a CLAT behavior designed to work with any NAT64, so that AFAIK incompatibility isn't an issue. > > >> Given that this document describes how to compose existing standards to run a service that requires both customer-side and provider-side components, I'd say interoperability is pretty important if this is to work at all. > > > (*)and (**) above are relevant here. > > The remaining question is while the chairs wouldn't accept an Informational or Experimental status while authors themselves are open to it. > > Cheers, > RD > > > > >> >> Cheers, >> Lorenzo > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --e89a8ff24801aeab7004c491ff4e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Jul 11, 2012 8:33 AM, "R=E9mi Despr=E9s" <despres.remi@laposte.net> wrote:
>
> Hi, Lorenzo,
>
> Comments about your two mails inline.
>
>
> 2012-07-11 =E0 11:36, Lorenzo Colitti:
>
>> On Mon, Jun 25, 2012 at 4:34 PM, R=E9mi Despr=E9s=A0<despres.remi@laposte.net>=A0wrote:=
>>>
>>> Hi, Masanobu-san,
>>>
>>> I have to confirm, no surprise, that I object to its BCP statu= s because:
>>> - it proposes more than just a combination of existing RFCs >>
>>
>> What does it propose that's not just a combination of existing= RFCs? It seems to me that the document essentially just says "you can= build a service called 464xlat by combining the behaviour specified by the= se two RFCs, and choosing these particular values as parameters". It&#= 39;s not specifying any new behaviour.
>
>
> (*)
> At least two points (both valuable IMHO) specify new behaviors:
> - In section 3: <<=A0The CLAT does not comply with the sentence = "Both IPv4-translatable IPv6 addresses and IPv4-converted IPv6 address= es SHOULD use the same prefix." that is described on Section=A03.3 in = [RFC6052] due to using different IPv6 prefixes for CLAT-side and PLAT-side = IPv4 addresses. >>
> - There is a request to IANA in section 10.
>
> BCP is therefore inappropriate AFAIK.
> Whether Experimental would be better than Informational remains howeve= r open AFAIAC.
>
>> =A0
>>>
>>> - it has close relationship with subjects discussed in Softwir= es such as MAP and 4rd, without serious examination of this relationship. >>
>>
>> I don't understand why this would apply differently to a BCP o= r to an informational document. Also, I don't understand why this is re= levant at all. The softwires work is attempting to solve a similar problem = by defining new technology, and the approaches don't overlap.
>
>
> Hastily freezing a recommended behavior while a better one is being cu= rrently worked on, is in my understanding inappropriate.
>
> In particular, improved transparency to IPv4 null checksums and to DF= =3D1 fragmented packets of RFC 4821=A0is worth considering (as proposed wit= h the NAT64+ of=A0tools.ietf.org/html/draft-ietf-softwire-4rd-02).=A0
>

Better?=A0 I thought we resolved long ago to not fall into these types o= f unqualified statements.

CB

> OTOH, as I said, publishing 4X4XLAT now=A0is IMHO valuable=A0(be it= as informational or experimental): it deals with a subject not covered in = other IETF documents.
>
>>
>> Cheers,
>> Lorenzo
>
>
>
>
> 2012-07-11 =A011:38, Lorenzo Colitti :
>
>> On Tue, Jul 3, 2012 at 5:39 PM, R=E9mi Despr=E9s=A0<despres.remi@laposte.net>=A0wrote:<= br> >>>
>>> A good reason to refuse Informational or Experimental hasn'= ;t been seen on this list.
>>
>>
>> An informational document is not a standards document.
>
>
> Neither a BCP AFAIK.
>
>> Thus, it cannot prevent the development of multiple incompatible i= mplementations.
>
>
> (**)
> 464XLAT defines a CLAT behavior designed to work with any NAT64, so th= at AFAIK incompatibility isn't an issue.
>
>
>> Given that this document describes how to compose existing standar= ds to run a service that requires both customer-side and provider-side comp= onents, I'd say interoperability is pretty important if this is to work= at all.
>
>
> (*)and (**) above are relevant here.
>
> The remaining question is while the chairs wouldn't accept an Info= rmational or Experimental status while authors themselves are open to it. >
> Cheers,
> RD
>
>
> =A0
>
>>
>> Cheers,
>> Lorenzo
>
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops
>

--e89a8ff24801aeab7004c491ff4e-- From brian.e.carpenter@gmail.com Wed Jul 11 11:35: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 6864C11E8100 for ; Wed, 11 Jul 2012 11:35:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.21 X-Spam-Level: X-Spam-Status: No, score=-101.21 tagged_above=-999 required=5 tests=[AWL=0.481, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4gTAAXz1dGrU for ; Wed, 11 Jul 2012 11:35:39 -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 A569511E80EF for ; Wed, 11 Jul 2012 11:35:38 -0700 (PDT) Received: by eaaq13 with SMTP id q13so537258eaa.31 for ; Wed, 11 Jul 2012 11:36:09 -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=745ZwiV5Q+j4wD0lVE6r7U7N6DvMjl+pX/ln1yma7SI=; b=XEOerj5jpobvpC1w73khZYB/kR9euXMHtiJP304H3+PZI3gAh10YnHJYGIPm3OtodY mOthWBa4c2XE6TfEdhFEjmVRzNQknO7gUL4UmsoPVcLYfc+rdrz9olkzWBQhXHqm9Prk dY17/G3FrqRZFsdGj702xuKYntbI4GJgpsEkvMa9he6i80y7flQLlwnq7FWCLig5uDyH ZN8BXGIiigwN2FbIg5Q+VgLXeFLHmmHBrr2YYPvO8t+t/4u06VUiQqnNg//83x86Aem9 0VhzBfkYOlJml0UaZMRYq3T8B/EAc4kLBRQ8dvOtcrFkKbl+akYNPYAF6V8ebasx58aW aDLw== Received: by 10.14.127.133 with SMTP id d5mr12223595eei.173.1342031769103; Wed, 11 Jul 2012 11:36:09 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-219-124.as13285.net. [2.102.219.124]) by mx.google.com with ESMTPS id z16sm8219964eef.16.2012.07.11.11.36.05 (version=SSLv3 cipher=OTHER); Wed, 11 Jul 2012 11:36:06 -0700 (PDT) Message-ID: <4FFDC79D.7050307@gmail.com> Date: Wed, 11 Jul 2012 19:36:13 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Gert Doering References: <4FFDACB2.9080106@switch.ch> <20120711182507.GK38127@Space.Net> In-Reply-To: <20120711182507.GK38127@Space.Net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG , opsec chairs Subject: Re: [v6ops] Fwd: RIPE-555 fundamentaly changes the way how we can filter IPv6 & IPv4 martians? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 11 Jul 2012 18:35:39 -0000 But Gert, wearing your "network operator" hat, aren't you worried about the long-term impact on your routing costs of what is effectively a free-for-all policy on long prefixes? I mean, that is why people invented CIDR and aggregation in the first place. Brian On 11/07/2012 19:25, Gert Doering wrote: > Hi, > > On Wed, Jul 11, 2012 at 07:57:48PM +0200, Turchanyi Geza wrote: >> There were several people, including me, that openly argued against some >> new RIPE policies that neglect the consecquences at the routing level, >> however, there is a noisy minority acting at the RIPE policy working group, >> overlooking reasonable arguments. > > *sigh*. This really shouldn't be here, but I can't let it stand as it is. > > > We had broad support in the RIPE address policy working group to change > some requirements on IPv6 PI assignments (namely removing the "multihoming > requirements", which were ill-defined to begin with), with a "noisy > minority", mostly consisting of Geza, objecting against this. > > Now going around and claiming that this was a "noisy minority acting at > the RIPE policy working group" is twisting reality somewhat - it was > "significantly more voices supporting the proposal than objecting", > and that's "rough consensus" - and the arguments were FUD-based, not > "reasonable". > > All of this happened openly on the RIPE address policy working group > mailing list, which has a public archive, so everyone can make up their > own mind of the situation. > > > > OTOH, the address policy WG had nothing to do with the change of RIPE-510 > to RIPE-555, and I'm still considering whether I see this as a matter-of-fact > declaration (as soon as IPv4 runs out, every sort of minimum allocation > size for individual /8s is moot, as people will want all the scraps and > bits left over), or as a problem. > > For IPv6, I'm not not exactly happy with the way it is written now, > implying that /48s could be assigned from anywhere in the address space. > But then, upstreams really should filter their customers by IRR or RPKI, > and not "by prefix ranges", as someone malevolent could do enough harm > by announcing a million /32s which would pass anyone's "/32s permitted > from RIR /12 ranges" filters just fine... > > Gert Doering > -- address policy WG chair *and* network operator From fred@cisco.com Wed Jul 11 11:55: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 5D33521F8672 for ; Wed, 11 Jul 2012 11:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.14 X-Spam-Level: X-Spam-Status: No, score=-110.14 tagged_above=-999 required=5 tests=[AWL=-0.141, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eCcE7MGioy8s for ; Wed, 11 Jul 2012 11:55:52 -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 22D0A21F8666 for ; Wed, 11 Jul 2012 11:55:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=8699; q=dns/txt; s=iport; t=1342032983; x=1343242583; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=zXddxmtkrigrMe3GXbzZj9TL3+sgv/RDQ2BvwpxD6YE=; b=hA1tEfpPzSm1cQP/1b29gCyZY0yINWqBqssR0FmfHYsBSAviMVTqd6ov 8A/6aZfQTqCjL858cbqWgBVM0RcHMXR3M7d6A1OWCWHct4/whzbD+HwsR h4O5A7eyNln2e89R5sbF1+HQCRxEUl+r/NIxOPIzdWozAQYw2CGuc5hBq E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFANrL/U+tJV2c/2dsb2JhbABFtUaCKIEHgiABAQEDARIBJzcNCwIBCDYQMiUCBDWHZQYLnSugJItAhQ5gA5U6gRKNDoFmgl+BWCM X-IronPort-AV: E=Sophos;i="4.77,569,1336348800"; d="scan'208";a="100923479" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP; 11 Jul 2012 18:56:23 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q6BIuMqT026819 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 11 Jul 2012 18:56:23 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.118]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0298.004; Wed, 11 Jul 2012 13:56:22 -0500 From: "Fred Baker (fred)" To: IPv6 Ops WG Thread-Topic: [v6ops] Fwd: RIPE-555 fundamentaly changes the way how we can filter IPv6 & IPv4 martians? Thread-Index: AQHNX5bd4uPwF1EKkEetTmMMXftV8A== Date: Wed, 11 Jul 2012 18:55:53 +0000 Message-ID: <2CFB6DD5-7BD4-4044-AB71-16DF0C28734F@cisco.com> References: <4FFDACB2.9080106@switch.ch> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.75.177] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19034.001 x-tm-as-result: No--40.602100-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: <7C17D27F35CE1F49AD4488D3402E4E2A@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] Fwd: RIPE-555 fundamentaly changes the way how we can filter IPv6 & IPv4 martians? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 11 Jul 2012 18:55:53 -0000 On Jul 11, 2012, at 10:57 AM, Turchanyi Geza wrote: > There were several people, including me, that openly argued against some = new RIPE policies that neglect the consecquences at the routing level, howe= ver, there is a noisy minority acting at the RIPE policy working group, ove= rlooking reasonable arguments. There have been calls in the past for the IETF to make recommendations to t= he RIRs on such policy. One of the proposals, if memory serves, was to reco= mmend that service providers filter prefixes longer than /48, and another w= as that they filter prefixes longer than were allocated by the RIR in quest= ion or the IANA. The general comment was to shout the suggestion down: "tha= t's for the RIR communities to comment on, not the IETF". If I understand the dialog here (and no, I'm not involved in RIPE Policy), = it sounds like there might be value in comments on the architectural implic= ations of policy decisions on routing. If I were to make a filtering proposal, I might look at the RPKI work. I co= uld imagine an RPKI database maintained by an RIR having a key for each all= ocated prefix and each aggregated prefix (e.g., I could imagine Europe and = the Americas routing to "APNIC prefixes" as an aggregated class, and only t= o more specifics within or close to the Asia Pacific region), and a recomme= ndation from v6ops to the effect that an ISP should filter to prefixes that= are in the RPKI database (and attested to by it) barring specific business= requirements; deaggregation by a business partner acceptable to a given ne= twork might be an example of a business requirement, as would acceptance of= the announcement of a specific ULA. I could also imagine the RIR offering = a service to a network that wants to deaggregate, that would allow it to fi= le signed keys for the more specific prefixes it wants to announce. I could also imagine the operators in the room saying "that's why we don't = want advice from the IETF" :-) Question for the accumulated folks "in the room": Is the architectural impl= ications of routing and filtering policy an appropriate topic to invite a d= raft concerning? If so, who might constitute an appropriate design team? Documents relevant to RPKI: https://tools.ietf.org/html/rfc6382 6382 Unique Origin Autonomous System Numbers (ASNs) per Node for Globally Anycasted Services. D. McPherson, R. Donnelly, F. Scalzo. October 2011. (Format: TXT=3D25224 bytes) (Also BCP0169) (Status: BEST CURRENT PRACTICE) https://tools.ietf.org/html/rfc6472 6472 Recommendation for Not Using AS_SET and AS_CONFED_SET in BGP. W. Kumari, K. Sriram. December 2011. (Format: TXT=3D10673 bytes) (Also BCP0172) (Status: BEST CURRENT PRACTICE) https://tools.ietf.org/html/rfc6480 6480 An Infrastructure to Support Secure Internet Routing. M. Lepinski, S. Kent. February 2012. (Format: TXT=3D62127 bytes) (Status: INFORMATIONAL) https://tools.ietf.org/html/rfc6481 6481 A Profile for Resource Certificate Repository Structure. G. Huston, R. Loomans, G. Michaelson. February 2012. (Format: TXT=3D36117 bytes) (Status: PROPOSED STANDARD) https://tools.ietf.org/html/rfc6482 6482 A Profile for Route Origin Authorizations (ROAs). M. Lepinski, S. Kent, D. Kong. February 2012. (Format: TXT=3D15745 bytes) (Status: PROPOSED STANDARD) https://tools.ietf.org/html/rfc6483 6483 Validation of Route Origination Using the Resource Certificate Public Key Infrastructure (PKI) and Route Origin Authorizations (ROAs). G. Huston, G. Michaelson. February 2012. (Format: TXT=3D19811 bytes) (Status: INFORMATIONAL) https://tools.ietf.org/html/rfc6484 6484 Certificate Policy (CP) for the Resource Public Key Infrastructure (RPKI). S. Kent, D. Kong, K. Seo, R. Watro. February 2012. (Format: TXT=3D77855 bytes) (Also BCP0173) (Status: BEST CURRENT PRACTICE) https://tools.ietf.org/html/rfc6485 6485 The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure (RPKI). G. Huston. February 2012. (Format: TXT=3D11377 bytes) (Status: PROPOSED STANDARD) https://tools.ietf.org/html/rfc6486 6486 Manifests for the Resource Public Key Infrastructure (RPKI). R. Austein, G. Huston, S. Kent, M. Lepinski. February 2012. (Format: TXT=3D42913 bytes) (Status: PROPOSED STANDARD) https://tools.ietf.org/html/rfc6487 6487 A Profile for X.509 PKIX Resource Certificates. G. Huston, G. Michaelson, R. Loomans. February 2012. (Format: TXT=3D69150 bytes) (Status: PROPOSED STANDARD) https://tools.ietf.org/html/rfc6488 6488 Signed Object Template for the Resource Public Key Infrastructure (RPKI). M. Lepinski, A. Chi, S. Kent. February 2012. (Format: TXT=3D25130 bytes) (Status: PROPOSED STANDARD) https://tools.ietf.org/html/rfc6489 6489 Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI). G. Huston, G. Michaelson, S. Kent. February 2012. (Format: TXT=3D23060 bytes) (Also BCP0174) (Status: BES= T CURRENT PRACTICE) https://tools.ietf.org/html/rfc6490 6490 Resource Public Key Infrastructure (RPKI) Trust Anchor Locator. G. Huston, S. Weiler, G. Michaelson, S. Kent. February 2012. (Format: TXT=3D15004 bytes) (Status: PROPOSED STANDARD) https://tools.ietf.org/html/rfc6491 6491 Resource Public Key Infrastructure (RPKI) Objects Issued by IANA. T. Manderson, L. Vegoda, S. Kent. February 2012. (Format: TXT=3D23662 bytes) (Status: PROPOSED STANDARD) https://tools.ietf.org/html/rfc6492 6492 A Protocol for Provisioning Resource Certificates. G. Huston, R. Loomans, B. Ellacott, R. Austein. February 2012. (Format: TXT=3D65896 bytes) (Status: PROPOSED STANDARD) https://tools.ietf.org/html/rfc6493 6493 The Resource Public Key Infrastructure (RPKI) Ghostbusters Record. R. Bush. February 2012. (Format: TXT=3D15491 bytes) (Status: PROPOSED STANDARD) https://tools.ietf.org/html/rfc6494 6494 Certificate Profile and Certificate Management for SEcure Neighbor Discovery (SEND). R. Gagliano, S. Krishnan, A. Kukec. February 2012. (Format: TXT=3D26425 bytes) (Updates RFC3971) (Status: PROPOSED STANDARD) http://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-ltamgmt http://tools.ietf.org/html/draft-ietf-sidr-rpki-ltamgmt "Local Trust Anchor Management for the Resource Public Key Infrastructure", Stephen Kent, Mark Reynolds, 9-Jul-12 http://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-rtr http://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr "The RPKI/Router Protocol", Randy Bush, Rob Austein, 2-Feb-12 "Definitions of Managed Objects for the RPKI-Router Protocol", Randy Bush, Bert Wijnen, Keyur Patel, Michael Baer, 26-Mar-12 "RPKI Router Implementation Report", Randy Bush, Rob Austein, Keyur Patel, Hannes Gredler, Matthias Waehlisch, 27-Mar-12 http://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-rtr http://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr "The RPKI/Router Protocol", Randy Bush, Rob Austein, 2-Feb-12 "Definitions of Managed Objects for the RPKI-Router Protocol", Randy Bush, Bert Wijnen, Keyur Patel, Michael Baer, 26-Mar-12 "RPKI Router Implementation Report", Randy Bush, Rob Austein, Keyur Patel, Hannes Gredler, Matthias Waehlisch, 27-Mar-12 http://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-rtr-impl http://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr-impl "RPKI Router Implementation Report", Randy Bush, Rob Austein, Keyur Patel, Hannes Gredler, Matthias Waehlisch, 27-Mar-12 http://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-rtr-impl http://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr-impl "RPKI Router Implementation Report", Randy Bush, Rob Austein, Keyur Patel, Hannes Gredler, Matthias Waehlisch, 27-Mar-12 http://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-rtr-protocol-mib http://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr-protocol-mib "Definitions of Managed Objects for the RPKI-Router Protocol", Randy Bush, Bert Wijnen, Keyur Patel, Michael Baer, 26-Mar-12 http://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-rtr-protocol-mib http://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr-protocol-mib "Definitions of Managed Objects for the RPKI-Router Protocol", Randy Bush, Bert Wijnen, Keyur Patel, Michael Baer, 26-Mar-12 http://datatracker.ietf.org/doc/draft-ymbk-rpki-grandparenting http://tools.ietf.org/html/draft-ymbk-rpki-grandparenting "Responsible Grandparenting in the RPKI", Randy Bush, 29-Jun-12 From farmer@umn.edu Wed Jul 11 12:24: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 D8C1E11E810C for ; Wed, 11 Jul 2012 12:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YbMVN1EWKtD2 for ; Wed, 11 Jul 2012 12:24:24 -0700 (PDT) Received: from vs-m.tc.umn.edu (vs-m.tc.umn.edu [134.84.135.97]) by ietfa.amsl.com (Postfix) with ESMTP id DA1EC11E80DB for ; Wed, 11 Jul 2012 12:24:23 -0700 (PDT) Received: from mail-yx0-f171.google.com (mail-yx0-f171.google.com [209.85.213.171]) by vs-m.tc.umn.edu (UMN smtpd) with ESMTP for ; Wed, 11 Jul 2012 14:24:44 -0500 (CDT) X-Umn-Remote-Mta: [N] mail-yx0-f171.google.com [209.85.213.171] #+LO+TR X-Umn-Classification: local Received: by mail-yx0-f171.google.com with SMTP id q11so2926646yen.16 for ; Wed, 11 Jul 2012 12:24:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=/uibnhxRqPWQZsnghro+lnE+hsZLOf1isVSyihaXPs0=; b=No8Hq3fQlg83BKbEBl0sVNTB5jR4gCX8E/2woactGLWBE2nSqk/3cmRqR1NLcgbc+h pad3IBmMlJBUDsV1Yj/jXqBp8acxq0kKh/Y1Uujbtthcl13dZY8yHD9X8LckQeliGTWC r58eAOJNmZB5p9zmXEycC5ozLMq9xj3mIBKX30N2RQfNKvbYJDwwkOHXHSTGepvR4obj hWfPHNXhiXft3eopzC2haDX6g6ZQyPyiDzIUMEkrk6/SjakZdorCyBjB1yL5ThIsoFeu awQHWo86j1+GdKbbCeg/BkMc8h+K60cIymHy4Q9DIFr7swfPWzIGYQvsZr9IPADr9zsU vz1w== Received: by 10.50.222.200 with SMTP id qo8mr15407295igc.20.1342034684352; Wed, 11 Jul 2012 12:24:44 -0700 (PDT) Received: from x-128-101-234-110.uofm-secure.wireless.umn.edu ([2607:ea00:104:2000:223:6cff:fe94:288c]) by mx.google.com with ESMTPS id if4sm15003278igc.10.2012.07.11.12.24.43 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 11 Jul 2012 12:24:43 -0700 (PDT) Message-ID: <4FFDD2FA.4040705@umn.edu> Date: Wed, 11 Jul 2012 14:24:42 -0500 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "Fred Baker (fred)" References: <4FFDACB2.9080106@switch.ch> <2CFB6DD5-7BD4-4044-AB71-16DF0C28734F@cisco.com> In-Reply-To: <2CFB6DD5-7BD4-4044-AB71-16DF0C28734F@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkGjwMZvGcx0Qq+yxpGfZtcFrapGyj6U5+pe3WUa+Po7lmqY14o37pvmjFSShI/OW1hr9Cv Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd: RIPE-555 fundamentaly changes the way how we can filter IPv6 & IPv4 martians? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Farmer List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 19:24:25 -0000 On 7/11/12 13:55 CDT, Fred Baker (fred) wrote: > > On Jul 11, 2012, at 10:57 AM, Turchanyi Geza wrote: > >> There were several people, including me, that openly argued against some new RIPE policies that neglect the consecquences at the routing level, however, there is a noisy minority acting at the RIPE policy working group, overlooking reasonable arguments. > > There have been calls in the past for the IETF to make recommendations to the RIRs on such policy. One of the proposals, if memory serves, was to recommend that service providers filter prefixes longer than /48, and another was that they filter prefixes longer than were allocated by the RIR in question or the IANA. The general comment was to shout the suggestion down: "that's for the RIR communities to comment on, not the IETF". I think the real problem is that the IETF is leaving it up to the RIRs. The RIRs claim no charter or ability to control routing policy only allocation policy. Many of the same people who shout down the IETF involving itself in the issue, also shout down the RIRs involving themselves in the issue. So as it stands no one seems to claim responsibility for routing policy other than the operators themselves. > If I understand the dialog here (and no, I'm not involved in RIPE Policy), it sounds like there might be value in comments on the architectural implications of policy decisions on routing. Probably more important than that are the architectural implications of only having the individual network operators responsible for routing policy. > If I were to make a filtering proposal, I might look at the RPKI work. I could imagine an RPKI database maintained by an RIR having a key for each allocated prefix and each aggregated prefix (e.g., I could imagine Europe and the Americas routing to "APNIC prefixes" as an aggregated class, and only to more specifics within or close to the Asia Pacific region), and a recommendation from v6ops to the effect that an ISP should filter to prefixes that are in the RPKI database (and attested to by it) barring specific business requirements; deaggregation by a business partner acceptable to a given network might be an example of a business requirement, as would acceptance of the announcement of a specific ULA. I could also imagine the RIR offering a service to a network that wants to deaggregate, that would allow it to file signed keys for the more specific prefixes it wants to announce. > > I could also imagine the operators in the room saying "that's why we don't want advice from the IETF" :-) Or from the RIRs either. :-) > Question for the accumulated folks "in the room": Is the architectural implications of routing and filtering policy an appropriate topic to invite a draft concerning? If so, who might constitute an appropriate design team? Please add to that where ongoing coordination, recommendation, or standardization (if we go that far) of routing and filtering policy belongs? IETF, RIRs, NOGs, someplace else? As full disclosure: I am involved in RIR policy processes as a member of the ARIN Advisory Council. Randy Bush would refer to me a Policy Wonk I believe. I figure I should just own it, rather than fight it. :-) Trying to fight Randy is frequently a loosing battle. :-) -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From gert@space.net Wed Jul 11 13: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 CEB7F21F8528 for ; Wed, 11 Jul 2012 13:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id po8vF0L8keNi for ; Wed, 11 Jul 2012 13:09:17 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0114621F8513 for ; Wed, 11 Jul 2012 13:09:15 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id A459DF8C45 for ; Wed, 11 Jul 2012 22:09:46 +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 6A071F8C55 for ; Wed, 11 Jul 2012 22:09:46 +0200 (CEST) Received: (qmail 15346 invoked by uid 1007); 11 Jul 2012 22:09:46 +0200 Date: Wed, 11 Jul 2012 22:09:46 +0200 From: Gert Doering To: Brian E Carpenter Message-ID: <20120711200946.GM38127@Space.Net> References: <4FFDACB2.9080106@switch.ch> <20120711182507.GK38127@Space.Net> <4FFDC79D.7050307@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="j/TTpdoN/8xAVVIu" Content-Disposition: inline In-Reply-To: <4FFDC79D.7050307@gmail.com> X-NCC-RegID: de.space X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.21 (2010-09-15) Cc: IPv6 Ops WG , opsec chairs Subject: Re: [v6ops] Fwd: RIPE-555 fundamentaly changes the way how we can filter IPv6 & IPv4 martians? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 11 Jul 2012 20:09:17 -0000 --j/TTpdoN/8xAVVIu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Wed, Jul 11, 2012 at 07:36:13PM +0100, Brian E Carpenter wrote: > But Gert, wearing your "network operator" hat, aren't you worried > about the long-term impact on your routing costs of what is effectively > a free-for-all policy on long prefixes? >=20 > I mean, that is why people invented CIDR and aggregation in the first > place. Which statement are you basing this "free-for-all policy" on, exactly? RIPE-510 never was a "the community has agreed on aggregation" document, but a summary about which prefix sizes the RIPE NCC has handed out from which /8s - and, effectively, RIPE-555 is the same: documenting the minimum assignment and allocation sizes the RIPE NCC has given out. The RIPE NCC's job is not to tell operators what they can or can not route - that's job of the *operator community* to agree upon, and=20 =66rom what I hear, they seem to be willing to accept /48 PI from their customers, /32 or larger (less bits) from other ISPs, and to a certain extent, permit deaggregation of /32s. RIPE-532 is the document from the *community* that covers what the RIPE routing working group was able to form consensus on regarding aggregation - it strongly recommends aggregating where possible, but takes reality into account and does not disallow deaggregation where needed. Now, it can be constructed that a liberal address assignment policy constructs a "free for all" regarding DFZ pollution with end-site prefixes - and to a certain extent, I shared this fear in the past. =20 Experience from IPv4, where we always had a very liberal PI policy, teaches us that it's still not "free" (a DSL or cable operator will not route your PI prefix for 20 EUR/month, to start with), and that PI space is not actually the largest identifiable source of routes=20 in the IPv4 DFZ (deaggregated PA is). Given all that, the IPv6 address policy can not answer the question "who is permitted to have a slot in the global routing system, and what should the obligations be?" - all we do is "deal out numbers", and the operators will have to agree on the price for a routing table slot, either for "a block of numbers labeled PI" or "a block of numbers labeled part-of-someones PA". Especially rules like "the receipient of a PI prefix must be multihomed!", do not make sense if you can get a nice and shiny /32 PA instead, by just paying higher yearly fees (and becoming a LIR). Address policy should=20 not be "if you pay more, you can get more addresses with less strings attached". 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 --j/TTpdoN/8xAVVIu Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iQCVAwUBT/3diqkuBuNlUUl1AQLqnAP/V3gxkuO0TzPQat9gs5ct359BTiV6//fV RFLbLJdixtrF18XstgTiMIB0CINmy/wx1OD2pnOR1VKE8LegkQ8K5//SZIOK4tFU mfYpPtDhXBWKlL5FgjqCgmpWCz6DeIR0tv4y4HQZR1r9QfamU5lL8hO/XDgTKopf B3OlRIUAoXY= =jtZE -----END PGP SIGNATURE----- --j/TTpdoN/8xAVVIu-- From gert@space.net Wed Jul 11 13:14: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 7EDAA21F858E for ; Wed, 11 Jul 2012 13:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bauRBJMe2c4V for ; Wed, 11 Jul 2012 13:14:01 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1E91B21F858D for ; Wed, 11 Jul 2012 13:13:57 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 0DA71F8C48 for ; Wed, 11 Jul 2012 22:14:28 +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 97E5AF8C50 for ; Wed, 11 Jul 2012 22:14:22 +0200 (CEST) Received: (qmail 16843 invoked by uid 1007); 11 Jul 2012 22:14:22 +0200 Date: Wed, 11 Jul 2012 22:14:22 +0200 From: Gert Doering To: David Farmer Message-ID: <20120711201422.GN38127@Space.Net> References: <4FFDACB2.9080106@switch.ch> <2CFB6DD5-7BD4-4044-AB71-16DF0C28734F@cisco.com> <4FFDD2FA.4040705@umn.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FFDD2FA.4040705@umn.edu> X-NCC-RegID: de.space X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.21 (2010-09-15) Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd: RIPE-555 fundamentaly changes the way how we can filter IPv6 & IPv4 martians? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 11 Jul 2012 20:14:01 -0000 Hi, On Wed, Jul 11, 2012 at 02:24:42PM -0500, David Farmer wrote: > So as it stands no one seems to claim responsibility for routing policy > other than the operators themselves. Since they also have to foot the bill, that sounds somewhat reasonable to me. No? Gert Doering -- RIPE policy wonk, Operator, Vendor "XL" price victim -- 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 nick@inex.ie Wed Jul 11 14:07: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 6B83F21F85DD for ; Wed, 11 Jul 2012 14:07:30 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xX5SMuOfDnIM for ; Wed, 11 Jul 2012 14:07:25 -0700 (PDT) Received: from mail.acquirer.com (mail.acquirer.com [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 8A2D121F85DF for ; Wed, 11 Jul 2012 14:07:24 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100:89ec:7ca3:4c26:ecdf]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id q6BL6ufO002067 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 11 Jul 2012 22:07:01 +0100 (IST) (envelope-from nick@inex.ie) Message-ID: <4FFDEB20.60601@inex.ie> Date: Wed, 11 Jul 2012 22:07:44 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: David Farmer References: <4FFDACB2.9080106@switch.ch> <2CFB6DD5-7BD4-4044-AB71-16DF0C28734F@cisco.com> <4FFDD2FA.4040705@umn.edu> In-Reply-To: <4FFDD2FA.4040705@umn.edu> X-Enigmail-Version: 1.4.2 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd: RIPE-555 fundamentaly changes the way how we can filter IPv6 & IPv4 martians? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 11 Jul 2012 21:07:30 -0000 On 11/07/2012 20:24, David Farmer wrote: > So as it stands no one seems to claim responsibility for routing policy > other than the operators themselves. Geoff Huston gave a talk about this at the last RIPE meeting: https://ripe64.ripe.net/programme/meeting-plan/routing-wg/ Would recommend watching the webcast: as with all Geoff's talks, it was as entertaining as it was informative. Nick From nick@inex.ie Wed Jul 11 14:19: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 CEE2111E80E1 for ; Wed, 11 Jul 2012 14:19:26 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LTUCVTgyjN6o for ; Wed, 11 Jul 2012 14:19:26 -0700 (PDT) Received: from mail.acquirer.com (mail.acquirer.com [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id ECF6F11E80BB for ; Wed, 11 Jul 2012 14:19:25 -0700 (PDT) X-Envelope-To: Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100:89ec:7ca3:4c26:ecdf]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id q6BLJ3pU002136 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 11 Jul 2012 22:19:08 +0100 (IST) (envelope-from nick@inex.ie) Message-ID: <4FFDEDF7.8060207@inex.ie> Date: Wed, 11 Jul 2012 22:19:51 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: v6ops@ietf.org References: <4FFDACB2.9080106@switch.ch> <20120711182507.GK38127@Space.Net> In-Reply-To: <20120711182507.GK38127@Space.Net> X-Enigmail-Version: 1.4.2 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] Fwd: RIPE-555 fundamentaly changes the way how we can filter IPv6 & IPv4 martians? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 11 Jul 2012 21:19:27 -0000 On 11/07/2012 19:25, Gert Doering wrote: > We had broad support in the RIPE address policy working group to change > some requirements on IPv6 PI assignments (namely removing the "multihoming > requirements", which were ill-defined to begin with), with a "noisy > minority", mostly consisting of Geza, objecting against this. Gert wrote a good summary of this: > https://www.ripe.net/ripe/mail/archives/address-policy-wg/2011-December/006600.html The discussion about the proposal was lengthy and wide-ranging, and included extensive discussion on routing table issues. Nick From fred@cisco.com Wed Jul 11 14:28: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 E23E911E80D0 for ; Wed, 11 Jul 2012 14:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.149 X-Spam-Level: X-Spam-Status: No, score=-110.149 tagged_above=-999 required=5 tests=[AWL=-0.149, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47UvptpO6Hj3 for ; Wed, 11 Jul 2012 14:28:09 -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 5EB8A11E80CB for ; Wed, 11 Jul 2012 14:28:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=360; q=dns/txt; s=iport; t=1342042121; x=1343251721; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=td+xFNvVolx6VWYTAMpP8B6IoTD0kL+GanNbpW8BMQM=; b=YrSDYso23imRsCzBnvT7LmThRJpuRP2wGVnGD8fdq2PnUDerLiap0Fyq RfnyNPq3183goRG1tm+hQ+8eiNurWLoG2BrjQqaZTNL/M/Oj9AduEc5/B kijGXjvJcFwqpQFPgZwn4WddFStjucjXacjA8YzzvxnIqV/fH2Go2rXAW Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EABDv/U+tJXG8/2dsb2JhbABFt3GBB4IhAQEEEgEnPxACAQg2EDIlAgQODhmHawudPqAfkE5gA5U6jiCBZoJf X-IronPort-AV: E=Sophos;i="4.77,569,1336348800"; d="scan'208";a="100973056" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-5.cisco.com with ESMTP; 11 Jul 2012 21:28:33 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q6BLSX6g017313 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Jul 2012 21:28:33 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.118]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0298.004; Wed, 11 Jul 2012 16:28:33 -0500 From: "Fred Baker (fred)" To: "v6ops@ietf.org WG" Thread-Topic: [v6ops] Prep for v6ops IETF 84 agenda Thread-Index: AQHNUnbpWFu7FKUfJEyvobkjy/vWXZcjFqiAgAHweIA= Date: Wed, 11 Jul 2012 21:28:03 +0000 Message-ID: <49128AF1-1EF0-478B-B5E1-2B5A73AFE1A3@cisco.com> References: <8D73E1D6-A968-4397-A843-FE073197B7F1@cisco.com> <45F1DB32-74F6-4E4A-88E2-118B76A5F474@cisco.com> In-Reply-To: <45F1DB32-74F6-4E4A-88E2-118B76A5F474@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.126.156] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19034.001 x-tm-as-result: No--28.065100-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: <64D298C73D050845BF527BFF2A41A126@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ron Bonica Subject: Re: [v6ops] Prep for v6ops IETF 84 agenda X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 11 Jul 2012 21:28:10 -0000 I have uploaded a preliminary agenda, at http://www.ietf.org/proceedings/84/agenda/agenda-84-v6ops I have put the drafts that I identified as clearly appropriate on Thursday,= and the "unclear" on Friday. Those who object to the latter set are free t= o leave Thursday evening :-) We should have at least half an hour per draft= for discussion.= From diego@tid.es Wed Jul 11 15:02: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 E87E911E80B6 for ; Wed, 11 Jul 2012 15:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.08 X-Spam-Level: X-Spam-Status: No, score=-6.08 tagged_above=-999 required=5 tests=[AWL=0.519, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MVeN1e-GxbJS for ; Wed, 11 Jul 2012 15:02:49 -0700 (PDT) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id EC5D911E810F for ; Wed, 11 Jul 2012 15:02:48 -0700 (PDT) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M7000CBHNXJWO@tid.hi.inet> for v6ops@ietf.org; Thu, 12 Jul 2012 00:03:19 +0200 (MEST) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id F3.B8.02752.628FDFF4; Thu, 12 Jul 2012 00:03:19 +0200 (CEST) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0M7000CB8NXIWO@tid.hi.inet> for v6ops@ietf.org; Thu, 12 Jul 2012 00:03:18 +0200 (MEST) Received: from EX10-MB1-MAD.hi.inet ([fe80::a473:4f3e:f8db:1855]) by ex10-htcas4-mad.hi.inet ([::1]) with mapi id 14.02.0298.004; Thu, 12 Jul 2012 00:03:15 +0200 Date: Wed, 11 Jul 2012 22:03:14 +0000 From: "Diego R. Lopez" In-reply-to: <56D50253-703D-400D-AED9-2C692EE656D4@cisco.com> X-Originating-IP: [10.95.64.115] To: "Fred Baker (fred)" Message-id: Content-id: <8DC34B2BDA880B4385AA1404CF2D58D4@hi.inet> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US Thread-topic: [v6ops] Draft on DC migration to IPv6 Thread-index: AQHNUqhbgWRF7Aew1UKq7qhHvsQ1MZcK3RGAgBF/VoCAB27PAIAAVLIAgAAP24CAAAwyAIAAXyaA X-AuditID: 0a5f4e69-b7f6d6d000000ac0-e9-4ffdf8260fbb X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJKsWRmVeSWpSXmKPExsXCFe9nqKv+46+/wdrpQhanj+1ldmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxunDu5kL5ilUnLmzmamBcYt8FyMHh4SAicS92axdjJxAppjE hXvr2boYuTiEBLYzShx/9ooFJCEk8JNRYu1ZUYjEUkaJzQu+MYIkWARUJf7cO8kEYrMB2Y+a f7ODDBUWMJL4PskLJMwpYCtxa+JhNogFChJ/zj0GmykioCGx4ctRsMXMQDWr728Gs3kFLCVa /hxmhIibScxa8pcNIi4o8WPyPRaQ8cwC6hJTpuRClIhLNLfeZIGwFSWmLWoAa2UE+uX7qTVM IOUiAsYSR/YJQmyNkejd3MwOcY2AxJI955khbFGJl4//sUJ82MQscet9K8sERolZSK6YheSK WQhXzEJyxSwkVyxgZF3FKFacVJSZnlGSm5iZk25gpJeRqZeZl1qyiRESb5k7GJfvVDnEKMDB qMTDKzHtk78Qa2JZcWXuIUZJDiYlUV7mr3/9hfiS8lMqMxKLM+KLSnNSiw8xSnAwK4nwHnwJ lONNSaysSi3Kh0nJcHAoSfBGfgdKCRalpqdWpGXmAJMKTJqJgxOknQeo/c03kPbigsTc4sx0 iPwpRkkpcV5fkGYBkERGaR5c7ytGcaAjhXlNQbI8wPQH1/UKaCAT0MAFS/+ADCxJREhJNTBu /6NRb3OBOUT+zWbJ5RnfrDcHrTysI3FLQfmN73GRDfxcm79KW9Q03vzAfPRBfr/kVCubK9Gt jNe27y5UiHil9PzRUgXHZ1kKQrseF10pmJ12dUG0Ttyp5atO+i/f8TR1zZZdiyQj9yT2uree kTs3oTdaa136z6ammHMsbgfn5f9pcTgwh1NPiaU4I9FQi7moOBEA6Uo7MzwDAAA= References: <28DC472D-01D4-4534-97A9-6AE52BE9CC58@tid.es> <4FF70D8F.5010706@bogus.com> <56D50253-703D-400D-AED9-2C692EE656D4@cisco.com> Cc: IPv6 Ops WG Subject: Re: [v6ops] Draft on DC migration to IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 11 Jul 2012 22:02:51 -0000 DQpPbiAxMSBKdWwgMjAxMiwgYXQgMTg6MjIgLCBGcmVkIEJha2VyIChmcmVkKSB3cm90ZToNCg0K Pg0KPiBPbiBKdWwgMTEsIDIwMTIsIGF0IDg6MzkgQU0sIFFpb25nIHdyb3RlOg0KPg0KPj4gRGVh ciBGcmVkLA0KPj4NCj4+IE9uIFdlZCwgSnVsIDExLCAyMDEyIGF0IDEwOjQyIFBNLCBGcmVkIEJh a2VyIChmcmVkKSA8ZnJlZEBjaXNjby5jb20+IHdyb3RlOg0KPj4NCj4+IE9uIEp1bCAxMSwgMjAx MiwgYXQgMjozOSBBTSwgWmhvdXFpYW4gKENhdGh5KSB3cm90ZToNCj4+DQo+PiA+IFtDYXRoeV0g VGhlIGNvbnRlbnQgcHJvdmlkZXIgd2lsbCBub3QgbG9zZSB0aGUgc291cmNlIGFkZHJlc3MgYXNz b2NpYXRlZCB3aXRoIHRoZSBpbmNvbWluZyByZXF1ZXN0LiBUaGUgc291cmNlIElQdjYgYWRkcmVz cyBpcyB0cmFuc2xhdGVkIHRvIElQdjQgYWRkcmVzcywgYW5kIHRoZSB0cmFuc2xhdG9yIG5lZWQg cmV0YWluIHRoZSBjb3JyZXNwb25kZW5jZSBiZXR3ZWVuIElQdjYgc291cmNlIGFkZHJlc3MgYW5k IElQdjQgc291cmNlIGFkZHJlc3MuDQo+Pg0KPj4gWWVzLCBidXQgZm9yIG1hbnkgZGF0YSBjZW50 ZXIgYXBwbGljYXRpb25zLCB0aGUgYXBwbGljYXRpb24gaXRzZWxmIHdhbnRzIHRvIGtub3cgdGhl IG9yaWdpbmFsIHNvdXJjZSBhZGRyZXNzIGluIG9yZGVyIHRvIHByb3ZpZGUgbG9jYXRpb24tYXdh cmUgc2VydmljZXMuIFNvIGl0IGlzIG5vdCBzdWZmaWNpZW50IGZvciB0aGUgTkFUIHRvIGtub3c7 IHRoZSBpbmZvcm1hdGlvbiBuZWVkcyB0byBzb21laG93IGJlIHByZXNlbnRlZCB0byB0aGUgYXBw bGljYXRpb24uIFRoaXMgaGFzIGJlZW4gYnJvdWdodCB1cCBieSBMb3JlbnpvIGFtb25nIG90aGVy cyBhcyBhIHJlcXVpcmVtZW50IGluIHRoZWlyIGRhdGEgY2VudGVycyBhbmQgcHVibGljIHNlcnZp Y2VzLg0KPj4NCj4+IFdpdGggcmVnYXJkIHRvIHRoaXMgcG9pbnQsIEkgdGhpbmsgaXQgd2lsbCBi ZSBhIGNvbW1vbiBwcm9ibGVtIGluIGFkZHJlc3Mgc2hhcmluZyBlbnZpcm9ubWVudCwgZXNwZWNp YWxseSB3aGVuIE5BVCBiZWNvbWVzIG1vcmUgYW5kIG1vcmUgcHJldmFsZW50IChOQVQ0NDQsIERT LUxpdGUsIE5BVDY0LCBldGMuKSBpbiB0aGUgZnV0dXJlLiBDb250ZW50IHByb3ZpZGVycyBoYXZl IHRvIGZhY2UgdGhpcyBwcm9ibGVtIHRoYXQgdGhleSB3aWxsIGxvc2UgdGhlIG9yaWdpbmFsIHNv dXJjZSBhZGRyZXNzIGFueWhvdywgYW5kIHdlIHNob3VsZCB0aGluayBvZiBhIHdheSB0byBzb2x2 ZSB0aGlzIHByb2JsZW0sIHJpZ2h0Pw0KPg0KPiBBIHNvbHV0aW9uIG5lZWRzIHRvIGJlIGFycml2 ZWQgYXQ7IEknbSBub3Qgc3VyZSB3ZSBuZWVkIHRvIHRoaW5rIG9mIHRoZSBzb2x1dGlvbiwgYnV0 IHdlIHNob3VsZCBhdCBsZWFzdCBpZGVudGlmeSB0aGUgaXNzdWUuDQo+DQo+PiBJbiBvdXIgdHJp YWwsIHdlIGhhdmUgdHJpZWQgaW5zZXJ0aW5nIFgtZm9yd2FyZCBoZWFkZXIgaW4gTkFUIGRldmlj ZSB0byBtYWtlIGFwcGxpY2F0aW9uIGdldCB0byBrbm93IHRoZSBvcmlnaW5hbCBhZGRyZXNzLiBC ZXNpZGVzLCBJIHRoaW5rIEhPU1RfSUQgKGRyYWZ0LWlldGYtaW50YXJlYS1uYXQtcmV2ZWFsLWFu YWx5c2lzKSBpcyBhbHNvIGEgcG9zc2libGUgc29sdXRpb24uIEhvdyBkbyB5b3UgdGhpbmsgPw0K Pg0KPiBUaG9zZSBhcmUgcG9zc2libGUgc29sdXRpb25zLiBUaGV5IHJlcHJlc2VudCBhZGRpbmcg c29tZSBmb3JtIG9mIEFwcGxpY2F0aW9uIExheWVyIEdhdGV3YXksIHdoaWNoIGlzIG5lY2Vzc2Fy aWx5IGFwcGxpY2F0aW9uLXNwZWNpZmljIGFuZCB0byBteSBrbm93bGVkZ2UgYXJlIG5vdCBkZWZp bmVkIGZvciBhIHZhcmlldHkgb2YgYXBwbGljYXRpb25zLiBNeSBwb2ludCB0byBDYXRoeSB3YXMg dGhhdCBpdCBpcyBpbmFkZXF1YXRlIHRvIGRpc21pc3MgdGhlIGlzc3VlIHdpdGggInRoZSBOQVQg a25vd3MgdGhlIHRyYW5zbGF0aW9uIjsgd2hpbGUgdHJ1ZSBhdCB0aGUgbmV0d29yayBsYXllciwg aXQgbWlzc2VzIGFuIGltcG9ydGFudCBzZXQgb2YgaXNzdWVzIGVudGlyZWx5Lg0KPg0KPiBJIHN1 c3BlY3QgdGhhdCB0aGlzIGRvY3VtZW50IGlzIG5vdCBjb21wbGV0ZSB3aXRob3V0IGFkZHJlc3Np bmcgdGhlIGFwcGxpY2F0aW9uIGdlb2xvY2F0aW9uIGlzc3Vlcy4NCg0KSSB0aGluayB5b3UgaGF2 ZSBhIHBvaW50IGhlcmUuIFdoYXQgaWYgd2UgdXBkYXRlIHRoZSBkb2N1bWVudCBleHBsaWNpdGx5 IG1lbnRpb25pbmcNCnRoYXQgbWFuYWdlZCB2NiBhY2Nlc3MgdG8gdGhlIERDIGluIGxldmVsIDEg aGFzIGlzc3VlcyB3aXRoIGdlb2xvY2F0aW9uIGFuZCBvdGhlcg0KYXBwbGljYXRpb25zIGV4cGVj dGluZyB0byBhcHBseSB0aGUgYWN0dWFsIHNvdXJjZSBhZGRyZXNzPw0KDQpCZSBnb29kZSwNCg0K DQotLQ0KIkVzdGEgdmV6IG5vIGZhbGxhcmVtb3MsIERvY3RvciBJbmZpZXJubyINCg0KRHIgRGll Z28gUi4gTG9wZXoNClRlbGVmb25pY2EgSStEDQpodHRwOi8vcGVvcGxlLnRpZC5lcy9kaWVnby5s b3Blei8NCg0KZS1tYWlsOiBkaWVnb0B0aWQuZXMNClRlbDogICAgKzM0IDkxMyAxMjkgMDQxDQpN b2JpbGU6ICszNCA2ODIgMDUxIDA5MQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpFc3RlIG1l bnNhamUgc2UgZGlyaWdlIGV4Y2x1c2l2YW1lbnRlIGEgc3UgZGVzdGluYXRhcmlvLiBQdWVkZSBj b25zdWx0YXIgbnVlc3RyYSBwb2zDrXRpY2EgZGUgZW52w61vIHkgcmVjZXBjacOzbiBkZSBjb3Jy ZW8gZWxlY3Ryw7NuaWNvIGVuIGVsIGVubGFjZSBzaXR1YWRvIG3DoXMgYWJham8uDQpUaGlzIG1l c3NhZ2UgaXMgaW50ZW5kZWQgZXhjbHVzaXZlbHkgZm9yIGl0cyBhZGRyZXNzZWUuIFdlIG9ubHkg c2VuZCBhbmQgcmVjZWl2ZSBlbWFpbCBvbiB0aGUgYmFzaXMgb2YgdGhlIHRlcm1zIHNldCBvdXQg YXQuDQpodHRwOi8vd3d3LnRpZC5lcy9FUy9QQUdJTkFTL2Rpc2NsYWltZXIuYXNweA0K From farmer@umn.edu Wed Jul 11 17:45: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 73C1D11E817C for ; Wed, 11 Jul 2012 17:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s3o6Tn6ZvZ+T for ; Wed, 11 Jul 2012 17:45:37 -0700 (PDT) Received: from vs-w.tc.umn.edu (vs-w.tc.umn.edu [134.84.135.88]) by ietfa.amsl.com (Postfix) with ESMTP id 4D36C11E817A for ; Wed, 11 Jul 2012 17:45:37 -0700 (PDT) Received: from mail-yx0-f171.google.com (mail-yx0-f171.google.com [209.85.213.171]) by vs-w.tc.umn.edu (UMN smtpd) with ESMTP for ; Wed, 11 Jul 2012 19:46:00 -0500 (CDT) X-Umn-Remote-Mta: [N] mail-yx0-f171.google.com [209.85.213.171] #+LO+TR X-Umn-Classification: local Received: by mail-yx0-f171.google.com with SMTP id q11so3442530yen.16 for ; Wed, 11 Jul 2012 17:46:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=SFwU8Wxx/zje5tFJ2G6ZfpiJ8lvTTiYr5z4CIdCrtg4=; b=hehq39qZ3hMCRapqUAkN2oG4auEgm8d8DNH9WfkiL1A9dlz5zJ1ukONAlrm+5ftxye 6uc24A2BBAL2Wnyu6kELEdYXgsJFFBlVMQob1+83am+/tSXUapgUYw4nxDoYX/DVvx1p W3g7VZoWnEkEqUYZoWj9Q3j5o+5sIlF9yTudlKS0dwHtOPnc6fRAo2o/Zm7wSSiRGO5C g7igwvwHNGycoeF7kenSXNXogy5AF8r78jY3z5b/uNTsrbZyPXxNrByOVg17/EMo27BE kYvX9pO/VGp+x3T8YmThnV7PXKnhlHhm4kmQeOxBl7gBweSMOJWBWRDZNsq9k6mzKjp3 ddlw== Received: by 10.50.159.196 with SMTP id xe4mr15991321igb.43.1342053959967; Wed, 11 Jul 2012 17:45:59 -0700 (PDT) Received: from x-128-101-234-110.uofm-secure.wireless.umn.edu ([2607:ea00:104:2000:223:6cff:fe94:288c]) by mx.google.com with ESMTPS id q1sm5776889igj.15.2012.07.11.17.45.58 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 11 Jul 2012 17:45:59 -0700 (PDT) Message-ID: <4FFE1E46.3060707@umn.edu> Date: Wed, 11 Jul 2012 19:45:58 -0500 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Nick Hilliard References: <4FFDACB2.9080106@switch.ch> <2CFB6DD5-7BD4-4044-AB71-16DF0C28734F@cisco.com> <4FFDD2FA.4040705@umn.edu> <4FFDEB20.60601@inex.ie> In-Reply-To: <4FFDEB20.60601@inex.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlXlRsfwOg0Rr8sla5+PFCu5YQUNpDqzmZ26RoqHYqZWSwjeNuMu3zlmL4VrTrh2Zt3+zWO Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd: RIPE-555 fundamentaly changes the way how we can filter IPv6 & IPv4 martians? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Farmer List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 00:45:38 -0000 On 7/11/12 16:07 CDT, Nick Hilliard wrote: > On 11/07/2012 20:24, David Farmer wrote: >> So as it stands no one seems to claim responsibility for routing policy >> other than the operators themselves. > > Geoff Huston gave a talk about this at the last RIPE meeting: > > https://ripe64.ripe.net/programme/meeting-plan/routing-wg/ > > Would recommend watching the webcast: as with all Geoff's talks, it was as > entertaining as it was informative. Thanks for the reference. Geoff's talks are always interesting. To summarize; There are no routing police. However, we all seem to be more or less well behaved. So, being a router policeman would be a very boring job. :) Therefore, at least right now, we don't need any routing police. I, agree. On 7/11/12 15:14 CDT, Gert Doering wrote: > Hi, > ... > Since they also have to foot the bill, that sounds somewhat reasonable > to me. No? I think it is perfectly reasonable. However, frequently people seem to decry the lack of routing police around here. And, when asked about it many people seem to pass the buck to someone else. My comments were mostly in reaction to "that's for the RIR communities to comment on, not the IETF", rather than trying to suggest that we need routing police. I don't think we need create the routing police. However, since everyone seems to pass the buck on the issue, its not even clear who could form and swear in a posse if we ever actually needed one. Without someone who has that clear authority, then we are only left with vigilantes. And vigilantes are usually as dangerous to the community as the bad guys, and usually far more dangerous than the police are. So, I guess I would suggest we settle the issue of who has the authority to form and swear in a posse, both as a protection against vigilantes and in the, I hope small, chance we ever actually need a posse some day. Because, if that day ever comes, that's not the day to figure out who has the authority to form the posse. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From joelja@bogus.com Wed Jul 11 20:09: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 52B3011E80B8 for ; Wed, 11 Jul 2012 20:09:44 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pn2PNWRQjkt8 for ; Wed, 11 Jul 2012 20:09:43 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id D324311E80A1 for ; Wed, 11 Jul 2012 20:09:42 -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 q6C3ABX3062526 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 12 Jul 2012 03:10:12 GMT (envelope-from joelja@bogus.com) Message-ID: <4FFE4013.4080508@bogus.com> Date: Wed, 11 Jul 2012 20:10:11 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120704 Thunderbird/14.0 MIME-Version: 1.0 To: "Diego R. Lopez" References: <28DC472D-01D4-4534-97A9-6AE52BE9CC58@tid.es> <4FF70D8F.5010706@bogus.com> <56D50253-703D-400D-AED9-2C692EE656D4@cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; 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, 12 Jul 2012 03:10:13 +0000 (UTC) Cc: IPv6 Ops WG Subject: Re: [v6ops] Draft on DC migration to IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Jul 2012 03:09:44 -0000 On 7/11/12 3:03 PM, Diego R. Lopez wrote: > On 11 Jul 2012, at 18:22 , Fred Baker (fred) wrote: > >> On Jul 11, 2012, at 8:39 AM, Qiong wrote: >> >>> Dear Fred, >>> >>> On Wed, Jul 11, 2012 at 10:42 PM, Fred Baker (fred) wrote: >>> >>> On Jul 11, 2012, at 2:39 AM, Zhouqian (Cathy) wrote: >>> >>>> [Cathy] The content provider will not lose the source address associated with the incoming request. The source IPv6 address is translated to IPv4 address, and the translator need retain the correspondence between IPv6 source address and IPv4 source address. >>> Yes, but for many data center applications, the application itself wants to know the original source address in order to provide location-aware services. So it is not sufficient for the NAT to know; the information needs to somehow be presented to the application. This has been brought up by Lorenzo among others as a requirement in their data centers and public services. >>> >>> With regard to this point, I think it will be a common problem in address sharing environment, especially when NAT becomes more and more prevalent (NAT444, DS-Lite, NAT64, etc.) in the future. Content providers have to face this problem that they will lose the original source address anyhow, and we should think of a way to solve this problem, right? >> A solution needs to be arrived at; I'm not sure we need to think of the solution, but we should at least identify the issue. >> >>> In our trial, we have tried inserting X-forward header in NAT device to make application get to know the original address. Besides, I think HOST_ID (draft-ietf-intarea-nat-reveal-analysis) is also a possible solution. How do you think ? >> Those are possible solutions. They represent adding some form of Application Layer Gateway, which is necessarily application-specific and to my knowledge are not defined for a variety of applications. My point to Cathy was that it is inadequate to dismiss the issue with "the NAT knows the translation"; while true at the network layer, it misses an important set of issues entirely. >> >> I suspect that this document is not complete without addressing the application geolocation issues. > I think you have a point here. What if we update the document explicitly mentioning > that managed v6 access to the DC in level 1 has issues with geolocation and other > applications expecting to apply the actual source address? Such that it shouldn't be done that way, sure. > Be goode, > > > -- > "Esta vez no fallaremos, Doctor Infierno" > > Dr Diego R. Lopez > Telefonica I+D > http://people.tid.es/diego.lopez/ > > e-mail: diego@tid.es > Tel: +34 913 129 041 > Mobile: +34 682 051 091 > ----------------------------------------- > > > ________________________________ > > Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. > This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at. > http://www.tid.es/ES/PAGINAS/disclaimer.aspx > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From joelja@bogus.com Wed Jul 11 20:17: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 CC07711E8125 for ; Wed, 11 Jul 2012 20:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.47 X-Spam-Level: X-Spam-Status: No, score=-102.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9iv1u4ob9MMj for ; Wed, 11 Jul 2012 20:17:54 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id E665A11E8100 for ; Wed, 11 Jul 2012 20:17:53 -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 q6C3IN9C062582 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 12 Jul 2012 03:18:23 GMT (envelope-from joelja@bogus.com) Message-ID: <4FFE41FF.2030900@bogus.com> Date: Wed, 11 Jul 2012 20:18:23 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120704 Thunderbird/14.0 MIME-Version: 1.0 To: "Diego R. Lopez" References: <28DC472D-01D4-4534-97A9-6AE52BE9CC58@tid.es> <4FF70D8F.5010706@bogus.com> <4FFD92E9.7020609@bogus.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; 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, 12 Jul 2012 03:18:23 +0000 (UTC) Cc: IPv6 Ops WG Subject: Re: [v6ops] Draft on DC migration to IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Jul 2012 03:17:54 -0000 On 7/11/12 8:14 AM, Diego R. Lopez wrote: > On 11 Jul 2012, at 16:51 , joel jaeggli wrote: >>> The majority of the flow labels today are zero. datacenter operators are >>> not os developers and we don't engage in wishful thinking. >>> >>> [Cathy] Yes, I agree with you that "The majority of the flow labels today are zero". The datacenter will still use the tradition of the load-balance method. Using flow labels for load balance is a complementary method. >> It's not complementary because today it doesn't work. So... What useful advice does that amount to for someone considering enabling ipv6 on their load balancer tier? > It is a mention to the advantages that a generalization of the proposed usage of flow > labels for load balancing can bring. It this application of flow labels does not get > traction we shall delete it, but in its current status is a sound technical proposal > and I don't see it makes any harm. I would hope that a document aiming to be, A Reference Framework for DC Migration to IPv6 would stick to things that you can in fact deploy. Datacenter v6 deployment is not a theoretical future activity. > Be goode, > > -- > "Esta vez no fallaremos, Doctor Infierno" > > Dr Diego R. Lopez > Telefonica I+D > http://people.tid.es/diego.lopez/ > > e-mail: diego@tid.es > Tel: +34 913 129 041 > Mobile: +34 682 051 091 > ----------------------------------------- > > > ________________________________ > > Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. > This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at. > http://www.tid.es/ES/PAGINAS/disclaimer.aspx > From joelja@bogus.com Wed Jul 11 20:23: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 7587D11E8100 for ; Wed, 11 Jul 2012 20:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.487 X-Spam-Level: X-Spam-Status: No, score=-102.487 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rdsrYWcVvFgV for ; Wed, 11 Jul 2012 20:23:08 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 064D611E80D0 for ; Wed, 11 Jul 2012 20:23:07 -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 q6C3NcWs062627 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 12 Jul 2012 03:23:38 GMT (envelope-from joelja@bogus.com) Message-ID: <4FFE433A.3090707@bogus.com> Date: Wed, 11 Jul 2012 20:23:38 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120704 Thunderbird/14.0 MIME-Version: 1.0 To: "Diego R. Lopez" References: <28DC472D-01D4-4534-97A9-6AE52BE9CC58@tid.es> <4FF70D8F.5010706@bogus.com> <9E1CA4A1-8AE8-4EA0-80DD-55719A29AB17@tid.es> In-Reply-To: <9E1CA4A1-8AE8-4EA0-80DD-55719A29AB17@tid.es> Content-Type: text/plain; charset=UTF-8; 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, 12 Jul 2012 03:23:39 +0000 (UTC) Cc: IPv6 Ops WG Subject: Re: [v6ops] Draft on DC migration to IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Jul 2012 03:23:08 -0000 On 7/11/12 8:08 AM, Diego R. Lopez wrote: > And, just in case, I personally find many of those location-aware > services more an annoyance than anything else: I don't see any > advantage in getting an Estonian UI or a search engine prioritizing > results in Norwegian for me. fraud and abuse detection is a large application for source addresses, user visible content changes are one of the least important considerations. From bingxuere@gmail.com Wed Jul 11 20:54: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 3924611E80A4 for ; Wed, 11 Jul 2012 20:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.173 X-Spam-Level: X-Spam-Status: No, score=-3.173 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4eW1VZ1wkuA for ; Wed, 11 Jul 2012 20:54:20 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3686611E809F for ; Wed, 11 Jul 2012 20:54:20 -0700 (PDT) Received: by yhq56 with SMTP id 56so2294024yhq.31 for ; Wed, 11 Jul 2012 20: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:from:date:message-id:subject:to :cc:content-type; bh=BpJmSeaRhnzuWYZ+ZBw5FEDc6+rc0UncequLnW0zfYE=; b=tXwnp3iS6V7h4ZFWbNtLmNvyyGxVzGUn3UhPZaRfscXdaG4UZYd6R/NfcyZtL4k88F XplGimcKKArgtNfK14QGd7DEJIb45D8lGTzeLUnnWWAyjrY0PRiOcvub8QJLYE/Zj4mK fxSUbV9JtJuhhW/AT9XVoZs3fgjDQOuaIUI+3PrLT+iNm6XU/bEChiMpC9zW4RwNs06i ZvuXgm7ZkVHLNPFG5qVMg+LBnrzgy7HggNqSIF6mN1qZ8LtHmN2FHubn2zM1g9k8mi6O lbTb0hOr5nXmOErX7s/wqrkdAdoNhT9EdqOEfOXZv1YLQi8Y8cW7boGJTyadori+o2II 9dpQ== Received: by 10.42.146.6 with SMTP id h6mr26771484icv.53.1342065291935; Wed, 11 Jul 2012 20:54:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.46.6 with HTTP; Wed, 11 Jul 2012 20:54:11 -0700 (PDT) In-Reply-To: <56D50253-703D-400D-AED9-2C692EE656D4@cisco.com> References: <28DC472D-01D4-4534-97A9-6AE52BE9CC58@tid.es> <4FF70D8F.5010706@bogus.com> <56D50253-703D-400D-AED9-2C692EE656D4@cisco.com> From: Qiong Date: Thu, 12 Jul 2012 11:54:11 +0800 Message-ID: To: "Fred Baker (fred)" Content-Type: multipart/alternative; boundary=90e6ba6e8716fdc00b04c499ec93 Cc: IPv6 Ops WG Subject: Re: [v6ops] Draft on DC migration to IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Jul 2012 03:54:21 -0000 --90e6ba6e8716fdc00b04c499ec93 Content-Type: text/plain; charset=UTF-8 Dear Fred, On Thu, Jul 12, 2012 at 12:22 AM, Fred Baker (fred) wrote: > > On Jul 11, 2012, at 8:39 AM, Qiong wrote: > > Dear Fred, > > On Wed, Jul 11, 2012 at 10:42 PM, Fred Baker (fred) wrote: > >> >> On Jul 11, 2012, at 2:39 AM, Zhouqian (Cathy) wrote: >> >> > [Cathy] The content provider will not lose the source address >> associated with the incoming request. The source IPv6 address is translated >> to IPv4 address, and the translator need retain the correspondence between >> IPv6 source address and IPv4 source address. >> >> Yes, but for many data center applications, the application itself wants >> to know the original source address in order to provide location-aware >> services. So it is not sufficient for the NAT to know; the information >> needs to somehow be presented to the application. This has been brought up >> by Lorenzo among others as a requirement in their data centers and public >> services. >> > > With regard to this point, I think it will be a common problem in address > sharing environment, especially when NAT becomes more and more prevalent > (NAT444, DS-Lite, NAT64, etc.) in the future. Content providers have to > face this problem that they will lose the original source address anyhow, > and we should think of a way to solve this problem, right? > > > A solution needs to be arrived at; I'm not sure we need to think of the > solution, but we should at least identify the issue. > > In our trial, we have tried inserting X-forward header in NAT device to > make application get to know the original address. Besides, I think HOST_ID > (draft-ietf-intarea-nat-reveal-analysis) is also a possible solution. How > do you think ? > > > Those are possible solutions. They represent adding some form of > Application Layer Gateway, which is necessarily application-specific and to > my knowledge are not defined for a variety of applications. My point to > Cathy was that it is inadequate to dismiss the issue with "the NAT knows > the translation"; while true at the network layer, it misses an important > set of issues entirely. > > I suspect that this document is not complete without addressing the > application geolocation issues. > Qiong: Agree with you. We should identify the issue and the possible solutions. Best wishes Qiong > > Thanks! > > Best wishes > Qiong > > >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > > > > -- > ============================================== > Qiong Sun > China Telecom Beijing Research Institude > > > Open source code: > lightweight 4over6: *http://sourceforge.net/projects/laft6/* > PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * > =============================================== > > > > -- ============================================== Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/* PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * =============================================== --90e6ba6e8716fdc00b04c499ec93 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Fred,

On Thu, Jul 12, 2012 at 12:22 = AM, Fred Baker (fred) <fred@cisco.com> wrote:

On Jul 11, 2012, at 8:39 AM, Qiong wrote:

Dear Fred,

On Wed, Jul 11, 2012 at 10:42 PM, Fred Baker (fr= ed) <fred@cisco.com&= gt; wrote:

On Jul 11, 2012, at 2:39 AM, Zhouqian (Cathy) wrote:

> [Cathy] The content provider will not lose the source address associat= ed with the incoming request. The source IPv6 address is translated to IPv4= address, and the translator need retain the correspondence between IPv6 so= urce address and IPv4 source address.

Yes, but for many data center applications, the application itself wants to= know the original source address in order to provide location-aware servic= es. So it is not sufficient for the NAT to know; the information needs to s= omehow be presented to the application. This has been brought up by Lorenzo among others as a requirement in their= data centers and public services.

With regard to this point, I think it will be a common problem in address s= haring environment, especially when NAT becomes more and more prevalent (NAT444, DS-Lite, NAT64, etc.) in the future. Conten= t providers have to face this problem that they will lose the original sour= ce address anyhow, and we should think of a way to solve this problem, righ= t?

A solution needs to be arrived at; I'm not sure we need to think o= f the solution, but we should at least identify the issue.

In our trial, we have tried inserting X-forward header in NAT device t= o make application get to know the original address. Besides, I think HOST_= ID (draft-ietf-intarea-nat-reveal-analysis) is also a possible solution. Ho= w do you think ?

Those are possible solutions. They represent adding some form of Appli= cation Layer Gateway, which is necessarily application-specific and to my k= nowledge are not defined for a variety of applications. My point to Cathy w= as that it is inadequate to dismiss the issue with "the NAT knows the translation"; while true at th= e network layer, it misses an important set of issues entirely.=C2=A0

I suspect that this document is not complete without addressing the ap= plication geolocation issues.

= Qiong: Agree with you. We should identify the issue and the possible soluti= ons.

Best wishes
Qiong

Thanks!

Best wishes
Qiong
=C2=A0

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



--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Qiong Sun
China Telecom Beijing Research Institude


Open source code:
lightweight 4over6: http://sourceforge.net/projects/laft6/
PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D






--
=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Qiong Sun
China Telecom Be= ijing Research Institude


Open source code:
lightweight 4over6= : h= ttp://sourceforge.net/projects/laft6/
PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

--90e6ba6e8716fdc00b04c499ec93-- From bingxuere@gmail.com Wed Jul 11 21:10: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 5896D11E80A4 for ; Wed, 11 Jul 2012 21:10:56 -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.469, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DGivHQT08N1Q for ; Wed, 11 Jul 2012 21:10:55 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 707B221F84F6 for ; Wed, 11 Jul 2012 21:10:55 -0700 (PDT) Received: by ghbg16 with SMTP id g16so2131955ghb.31 for ; Wed, 11 Jul 2012 21:11: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:from:date:message-id:subject:to :cc:content-type; bh=jk2+FjvnxuJJRFlyDI6FtY+PbQke31XHuTtjgaoZbCA=; b=flS0XPXZNEhKjtndtKe5hSoVgN2F9AlTwnR5BO4V2SCuVb4CkFk7w49X60A8y/BQqw iJdWm1KrVvPGUaEyITYI6QaYLp8Os7sqTtn5rjQ01rc9Me4DQPe0bAGkD/hNiy1MEI/I VYxD/sd5W+5dEHAUikVr2k15S/W1Y1mTYoopc9zWnYXQ1/OiRFFjSp7K9+gVCtwSisNa lr8Ax8FmKi5IsU4y2mJzhsDA9tXoRvw7PahEgEhpjidcNwSrw2QG8MHbCx5VWzBWxh5i 6hvqowfFdPMHlJMLPL9CxDqqZ2uusSQsZ/vMDK4Pt1TGQcpaRQ2tbARPZJRtUnw9WNNM BB9Q== Received: by 10.50.57.130 with SMTP id i2mr16241319igq.2.1342066286860; Wed, 11 Jul 2012 21:11:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.46.6 with HTTP; Wed, 11 Jul 2012 21:10:46 -0700 (PDT) In-Reply-To: <4FFDB38F.3080206@bogus.com> References: <28DC472D-01D4-4534-97A9-6AE52BE9CC58@tid.es> <4FF70D8F.5010706@bogus.com> <4FFDB38F.3080206@bogus.com> From: Qiong Date: Thu, 12 Jul 2012 12:10:46 +0800 Message-ID: To: Joel jaeggli Content-Type: multipart/alternative; boundary=14dae93403b74b194504c49a2884 Cc: IPv6 Ops WG Subject: Re: [v6ops] Draft on DC migration to IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Jul 2012 04:10:56 -0000 --14dae93403b74b194504c49a2884 Content-Type: text/plain; charset=UTF-8 Hi Joel, On Thu, Jul 12, 2012 at 1:10 AM, Joel jaeggli wrote: > On 7/11/12 08:39 , Qiong wrote: > > Dear Fred, > > > > On Wed, Jul 11, 2012 at 10:42 PM, Fred Baker (fred) > > wrote: > > > > > > On Jul 11, 2012, at 2:39 AM, Zhouqian (Cathy) wrote: > > > > > [Cathy] The content provider will not lose the source address > > associated with the incoming request. The source IPv6 address is > > translated to IPv4 address, and the translator need retain the > > correspondence between IPv6 source address and IPv4 source address. > > > > Yes, but for many data center applications, the application itself > > wants to know the original source address in order to provide > > location-aware services. So it is not sufficient for the NAT to > > know; the information needs to somehow be presented to the > > application. This has been brought up by Lorenzo among others as a > > requirement in their data centers and public services. > > > > > > With regard to this point, I think it will be a common problem in > > address sharing environment, especially when NAT becomes more and more > > prevalent (NAT444, DS-Lite, NAT64, etc.) in the future. Content > > providers have to face this problem that they will lose the original > > source address anyhow, and we should think of a way to solve this > > problem, right? > > The fact that the carrier the customer is behind might also nat their > source address or that they have a residential gateway is a rather more > distant problem then an nat64 located rather closer to me. I still want > to know that the source is verizon's cgnat rather than my local nat64 > gateway. > But the fact is that you can not "assume" how close this NAT64 gateway is the network. This depends on the operational deployment model, traffic model, etc. It might be deployed distributed, centralized or in other ways. But anyway, you will lose the orignial address and you can not trust it anymore. Even if it is still a verizon's address, you can not know to what extend the granularity you have lost. It is a reality now, and it will be more and more prevalent in the future. The content provider should also have to face it. > > > In our trial, we have tried inserting X-forward header in NAT device to > > make application get to know the original address. Besides, I think > > HOST_ID (draft-ietf-intarea-nat-reveal-analysis) is also a possible > > solution. > > Not within a draft that operates within the confines of existing reality > it isn't. > Why NAT+some sort of Application Gateway can not be a possible solution ? Best wishes Qiong > > > How do you think ? > > so you're rewriting the protocol stream on the fly, or this really an > alg and not a nat box, and I imagine you don't do http(s) in the case of > the former. > > > Thanks! > > > > Best wishes > > Qiong > > > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > > > > > > > > -- > > ============================================== > > Qiong Sun > > China Telecom Beijing Research Institude > > > > > > Open source code: > > lightweight 4over6: /http://sourceforge.net/projects/laft6// > > PCP-natcoord:/http://sourceforge.net/projects/pcpportsetdemo/ / > > =============================================== > > > > > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > > > -- ============================================== Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/* PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * =============================================== --14dae93403b74b194504c49a2884 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Joel,

On Thu, Jul 12, 2012 at 1:10 AM,= Joel jaeggli <joelja@bogus.com> wrote:
On 7/11/12 08:39 , Qiong wrote:
> Dear Fred,
>
> On Wed, Jul 11, 2012 at 10:42 PM, Fred Baker (fred) <fred@cisco.com
> <mailto:f= red@cisco.com>> wrote:
>
>
> =C2=A0 =C2=A0 On Jul 11, 2012, at 2:39 AM, Zhouqian (Cathy) wrote:
>
> =C2=A0 =C2=A0 > [Cathy] The content provider will not lose the sour= ce address
> =C2=A0 =C2=A0 associated with the incoming request. The source IPv6 ad= dress is
> =C2=A0 =C2=A0 translated to IPv4 address, and the translator need reta= in the
> =C2=A0 =C2=A0 correspondence between IPv6 source address and IPv4 sour= ce address.
>
> =C2=A0 =C2=A0 Yes, but for many data center applications, the applicat= ion itself
> =C2=A0 =C2=A0 wants to know the original source address in order to pr= ovide
> =C2=A0 =C2=A0 location-aware services. So it is not sufficient for the= NAT to
> =C2=A0 =C2=A0 know; the information needs to somehow be presented to t= he
> =C2=A0 =C2=A0 application. This has been brought up by Lorenzo among o= thers as a
> =C2=A0 =C2=A0 requirement in their data centers and public services. >
>
> With regard to this point, I think it will be a common problem in
> address sharing environment, especially when NAT becomes more and more=
> prevalent (NAT444, DS-Lite, NAT64, etc.) in the future. Content
> providers have to face this problem that they will lose the original > source address anyhow, and we should think of a way to solve this
> problem, right?

The fact that the carrier the customer is behind might also nat their=
source address or that they have a residential gateway is a rather more
distant problem then an nat64 located rather closer to me. I still want
to know that the source is verizon's cgnat rather than my local nat64 gateway.
But the fact is that you can not "assume= " how close this NAT64 gateway is the network. This depends on the ope= rational deployment model, traffic model, etc. It might be deployed distrib= uted, centralized or in other ways.
But anyway, you will lose the orignial address and you can not trust it any= more. Even if it is still a verizon's address, you can not know to what= extend the granularity you have lost. It is a reality now, and it will be = more and more prevalent in the future. The content provider should also hav= e to face it.=C2=A0 =C2=A0

> In our trial, we have tried inserting X-forward header in NAT device t= o
> make application get to know the original address. Besides, I think > HOST_ID (draft-ietf-intarea-nat-reveal-analysis) is also a possible > solution.

Not within a draft that operates within the confines of existing real= ity
it isn't.
Why NAT+some sort of Application Gateway= can not be a possible solution ?

Best wishes
Qiong

> How do you think ?

so you're rewriting the protocol stream on the fly, or this reall= y an
alg and not a nat box, and I imagine you don't do http(s) in the case o= f
the former.

> Thanks!
>
> Best wishes
> Qiong
>
>
>
> =C2=A0 =C2=A0 _______________________________________________
> =C2=A0 =C2=A0 v6ops mailing list
> =C2=A0 =C2=A0 v6ops@ietf.org <mailto:v6ops@ietf.org>
> =C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/v= 6ops
>
>
>
>
> --
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> Qiong Sun
> China Telecom Beijing Research Institude
>
>
> Open source code:
> lightweight 4over6: /http://sourceforge.net/projects/laft6//
> PCP-natcoord:/http://sourceforge.net/projects/pcpportsetdemo/ /=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>





--
=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Qiong Sun
Chin= a Telecom Beijing Research Institude


Open source code:
lightw= eight 4over6: http://sourceforge.net/projects/laft6/
PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

--14dae93403b74b194504c49a2884-- From randy@psg.com Wed Jul 11 21:52: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 8126321F85D8 for ; Wed, 11 Jul 2012 21:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UcYcElr4tASQ for ; Wed, 11 Jul 2012 21:52:23 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id C0BF821F85D7 for ; Wed, 11 Jul 2012 21:52:23 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SpBOY-0001MZ-Ks; Thu, 12 Jul 2012 04:52:55 +0000 Date: Thu, 12 Jul 2012 13:52:53 +0900 Message-ID: From: Randy Bush To: "Fred Baker (fred)" In-Reply-To: <2CFB6DD5-7BD4-4044-AB71-16DF0C28734F@cisco.com> References: <4FFDACB2.9080106@switch.ch> <2CFB6DD5-7BD4-4044-AB71-16DF0C28734F@cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd: RIPE-555 fundamentaly changes the way how we can filter IPv6 & IPv4 martians? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Jul 2012 04:52:24 -0000 > Is the architectural implications of routing and filtering policy an > appropriate topic to invite a draft concerning? other than incorrect filters breaking connectivity, there are no architectural implications, only scaling issues. randy From despres.remi@laposte.net Wed Jul 11 22:49: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 3612721F8713 for ; Wed, 11 Jul 2012 22:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.488 X-Spam-Level: X-Spam-Status: No, score=-1.488 tagged_above=-999 required=5 tests=[AWL=0.460, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6nfIvRAGjCH9 for ; Wed, 11 Jul 2012 22:49:48 -0700 (PDT) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.2]) by ietfa.amsl.com (Postfix) with ESMTP id 151D221F8573 for ; Wed, 11 Jul 2012 22:49:47 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2107.sfr.fr (SMTP Server) with ESMTP id 1DF6170000CB; Thu, 12 Jul 2012 07:50:19 +0200 (CEST) Received: from [192.168.1.73] (58.204.170.89.rev.sfr.net [89.170.204.58]) by msfrf2107.sfr.fr (SMTP Server) with ESMTP id 35CE670000AD; Thu, 12 Jul 2012 07:50:18 +0200 (CEST) X-SFR-UUID: 20120712055018220.35CE670000AD@msfrf2107.sfr.fr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-11-840281495 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Thu, 12 Jul 2012 07:50:17 +0200 Message-Id: <28998A3C-1BCC-46F4-A205-498B8EC96D0A@laposte.net> References: <20120625002907.24191.87700.idtracker@ietfa.amsl.com> <20120625093320kawashimam@mail.jp.nec.com> <79510968-0EE0-473F-A0B1-DD4B35092523@laposte.net> To: Cameron Byrne X-Mailer: Apple Mail (2.1084) Cc: v6ops v6ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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: Thu, 12 Jul 2012 05:49:49 -0000 --Apple-Mail-11-840281495 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi, Cameron, Please see inline. 2012-07-11 =E0 20:27, Cameron Byrne: > On Jul 11, 2012 8:33 AM, "R=E9mi Despr=E9s" = wrote: >=20 ... > > Hastily freezing a recommended behavior while a better one is being = currently worked on, is in my understanding inappropriate. > > > > In particular, improved transparency to IPv4 null checksums and to = DF=3D1 fragmented packets of RFC 4821 is worth considering (as proposed = with the NAT64+ of tools.ietf.org/html/draft-ietf-softwire-4rd-02).=20 > > >=20 > Better? I thought we resolved long ago to not fall into these types of = unqualified statements. >=20 Here is, with more details, why my statement to Lorenzo was IMHO worth = making: =20 1. - IPv4 may have fragmented packets (like IPv6) - RFC 4821 (standard track) recommends that they be sent with DF=3D1 - RFC 6145 translates IPv6 fragmented packets into IPv4 fragmented = packets that have DF=3D0 =3D> This conflicts with the objective of RFC 4821. 2. - In IPv4 UDP datagrams may be without checksum (unlike IPv6) - RFC 6145 translates IPv4 null-checksum datagrams into a valid-checksum = IPv6 datagrams, even if corrupted before translation =3D> This introduces a security risk 3. - A mechanism to avoid these two problems, including in stateful NAT64s = if upgraded to this effect, have been identified in Softwire, in a draft = having authors from widely different origins.=20 - This mechanism has no identified side effect that would introduce = service regression. =3D> the word "better behavior" is justified.=20 If you still object to some of the points above, please explain, = preferably after a look at the above-mentioned Softwire draft. Regards, RD=20 --Apple-Mail-11-840281495 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1


2012-0= 7-11 =E0 20:27, Cameron Byrne:

On Jul = 11, 2012 8:33 AM, "R=E9mi Despr=E9s" <despres.remi@laposte.net> = wrote:

...

> Hastily freezing a recommended behavior while a better one is being = currently worked on, is in my understanding inappropriate.
>
> In particular, improved transparency to IPv4 null checksums and to = DF=3D1 fragmented packets of RFC 4821 is worth considering (as = proposed with the NAT64+ of tools.ietf.= org/html/draft-ietf-softwire-4rd-02). 
>

Better? I thought we resolved long ago to not fall into = these types of unqualified statements.

Here = is, with more details, why my statement to Lorenzo was IMHO worth = making:
 
1.
- IPv4 may have = fragmented packets (like IPv6)
- RFC 4821 (standard track) = recommends that they be sent with DF=3D1
- RFC 6145 translates = IPv6 fragmented packets into IPv4 fragmented packets that have = DF=3D0
=3D> This conflicts with the objective of RFC = 4821.
2.
- In IPv4 UDP datagrams may be without = checksum (unlike IPv6)
- RFC 6145 translates IPv4 = null-checksum datagrams into a valid-checksum IPv6 datagrams, even if = corrupted before translation
=3D> This introduces a = security risk
3.
- A mechanism to avoid these two = problems, including in stateful NAT64s if upgraded to this effect, have = been identified in Softwire, in a draft having authors from widely = different origins. 
- This mechanism has no identified = side effect that would introduce service regression.
=3D> = the word "better behavior" is = justified. 

If you still object to some of = the points above, please explain, preferably after a look at the = above-mentioned Softwire = draft.

Regards,
RD 

=

= --Apple-Mail-11-840281495-- From turchanyi.geza@gmail.com Wed Jul 11 23: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 E707F11E80A5 for ; Wed, 11 Jul 2012 23:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6dVxBEhdxf6F for ; Wed, 11 Jul 2012 23:26:43 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 54CB111E8099 for ; Wed, 11 Jul 2012 23:26:43 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so3431470pbc.31 for ; Wed, 11 Jul 2012 23:27: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=vHvL0A48fUKWQmEljjrPQQb3gWHx9BmjVc+txdH6dJg=; b=rlDuRennufveI28GK/nmYnLrT4sRhyXVLwgxF8DdZIqVsEHngwgRTl5xuAg7Y+Pkhd jDy3Ad3bNlfkFleDbCKHPu3lDZm7/S2WJh0Z6I4IWAbSmof/LsazVFC1yhuv5emUSxiD sNiKiuNEMtvool/RsC9JJkL1LlrTJx1Krtb5+hpS3zkZIxhNBo5AmrdqOEQPmV9ndCGJ 6UXGu7tzcUJe0Y9diw8fX4V7kvSmr08CPt8CoA02rhXzaVGmkjUCBjHGw04ne8/oshoE GNZ1kJePk6ptMf1oDKbQv56s6eSV/T+ae+u90F30c+erpeDzhQ2kE2HprPK8WtvLL5Qm bWFg== MIME-Version: 1.0 Received: by 10.68.203.66 with SMTP id ko2mr2715962pbc.84.1342074435772; Wed, 11 Jul 2012 23:27:15 -0700 (PDT) Received: by 10.66.228.131 with HTTP; Wed, 11 Jul 2012 23:27:15 -0700 (PDT) In-Reply-To: References: <4FFDACB2.9080106@switch.ch> <2CFB6DD5-7BD4-4044-AB71-16DF0C28734F@cisco.com> Date: Thu, 12 Jul 2012 08:27:15 +0200 Message-ID: From: Turchanyi Geza To: Randy Bush Content-Type: multipart/alternative; boundary=047d7b10cfb701a1d304c49c0ecb Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd: RIPE-555 fundamentaly changes the way how we can filter IPv6 & IPv4 martians? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Jul 2012 06:26:44 -0000 --047d7b10cfb701a1d304c49c0ecb Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Randy, On Thu, Jul 12, 2012 at 6:52 AM, Randy Bush wrote: > > Is the architectural implications of routing and filtering policy an > > appropriate topic to invite a draft concerning? > > other than incorrect filters breaking connectivity, there are no > architectural implications, only scaling issues. > > and we could add: these scaling issues could create a need of drastical upgrade of our router's linecards very soon. Many service providers won't be able to finance this. On the name of this "minority", G=E9za --047d7b10cfb701a1d304c49c0ecb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Randy,


On Thu, Jul 12, 2012 at 6:52 A= M, Randy Bush <randy@psg.com> wrote:
> Is the architectural implications of routing and fil= tering policy an
> appropriate topic to invite a draft concerning?

other than incorrect filters breaking connectivity, there are no
architectural implications, only scaling issues.


and we could add: these scaling issues could create a need of d= rastical upgrade of our router's linecards very soon. Many service prov= iders won't be able to finance this.

On the name of this "minority",

G=E9za
=
--047d7b10cfb701a1d304c49c0ecb-- From brian.e.carpenter@gmail.com Thu Jul 12 00:16: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 2036311E80ED for ; Thu, 12 Jul 2012 00:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.615 X-Spam-Level: X-Spam-Status: No, score=-100.615 tagged_above=-999 required=5 tests=[AWL=-0.164, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E4ySQldPaFWP for ; Thu, 12 Jul 2012 00:16:03 -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 55F6E11E80D6 for ; Thu, 12 Jul 2012 00:16:03 -0700 (PDT) Received: by wibhr14 with SMTP id hr14so1541643wib.13 for ; Thu, 12 Jul 2012 00:16:35 -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=GAKbYRFEL+u97MKdeSWq0XO09qYMvXyjWRb4jnHtkP8=; b=j9x6JuQrhEJHqTlpVz44YSY8pUXqOVDkf5cdnxmU1iAMQ+3N2UC/AvhM+nlbkpFkRI gIKdi1FEV6egSPVkc1mHsiCks8PQG2JyViQ9ne5xLlAuM4/RyT3Q7aTbIfT/bFxKeGs0 lUQikHpZ6XJe8oYNus7QoMRgJt2Yn0ZcuCgklLLGT3ePCKWbcev28jeK4ykQYaDm3KgD 3qv8RQ7EYz1Qya0gyl/64l6POIvaYJdlCL8BNTPIFL55gcyyI83jmb9iBET/L/fc3ZZB rlBHs8k9Rd0TYyhNsqAwXjB/pqSNYrQRHZhxgfYV5j/yTDs2+YsYhGCQ5+sxfi4FXG5g qahg== Received: by 10.217.7.6 with SMTP id z6mr2252459wes.5.1342077395301; Thu, 12 Jul 2012 00:16:35 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-217-107.as13285.net. [2.102.217.107]) by mx.google.com with ESMTPS id w7sm32065674wiz.0.2012.07.12.00.16.32 (version=SSLv3 cipher=OTHER); Thu, 12 Jul 2012 00:16:33 -0700 (PDT) Message-ID: <4FFE79DA.3010408@gmail.com> Date: Thu, 12 Jul 2012 08:16:42 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Qiong References: <28DC472D-01D4-4534-97A9-6AE52BE9CC58@tid.es> <4FF70D8F.5010706@bogus.com> <4FFDB38F.3080206@bogus.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] Draft on DC migration to IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Jul 2012 07:16:04 -0000 On 12/07/2012 05:10, Qiong wrote: ... >> The fact that the carrier the customer is behind might also nat their >> source address or that they have a residential gateway is a rather more >> distant problem then an nat64 located rather closer to me. I still want >> to know that the source is verizon's cgnat rather than my local nat64 >> gateway. >> > But the fact is that you can not "assume" how close this NAT64 gateway is > the network. This depends on the operational deployment model, traffic > model, etc. It might be deployed distributed, centralized or in other ways. > But anyway, you will lose the orignial address and you can not trust it > anymore. Even if it is still a verizon's address, you can not know to what > extend the granularity you have lost. It is a reality now, and it will be > more and more prevalent in the future. The content provider should also > have to face it. Consider that this is also a massive problem created by the deployment of NAT444 brought about by CGNs. IPv6 can only win here, as it offers a long-term solution. But it seems clear to me that in the short term, IPv6 wins if we advocate full dual stack for DCs, because that maximizes the number of cases in which we have end to end addressing and therefore have useable geolocation. Brian From gert@space.net Thu Jul 12 00:18: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 EEC3021F8631 for ; Thu, 12 Jul 2012 00:18:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x4L0obp+Pyyh for ; Thu, 12 Jul 2012 00:18:12 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id EA68A21F8613 for ; Thu, 12 Jul 2012 00:18:11 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 940C4F8C45 for ; Thu, 12 Jul 2012 09:18:43 +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 7FCF3F8C4B for ; Thu, 12 Jul 2012 09:18:43 +0200 (CEST) Received: (qmail 96821 invoked by uid 1007); 12 Jul 2012 09:18:43 +0200 Date: Thu, 12 Jul 2012 09:18:43 +0200 From: Gert Doering To: Turchanyi Geza Message-ID: <20120712071843.GV38127@Space.Net> References: <4FFDACB2.9080106@switch.ch> <2CFB6DD5-7BD4-4044-AB71-16DF0C28734F@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.21 (2010-09-15) Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd: RIPE-555 fundamentaly changes the way how we can filter IPv6 & IPv4 martians? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Jul 2012 07:18:13 -0000 Hi, On Thu, Jul 12, 2012 at 08:27:15AM +0200, Turchanyi Geza wrote: > On Thu, Jul 12, 2012 at 6:52 AM, Randy Bush wrote: > > > > Is the architectural implications of routing and filtering policy an > > > appropriate topic to invite a draft concerning? > > > > other than incorrect filters breaking connectivity, there are no > > architectural implications, only scaling issues. > > and we could add: these scaling issues could create a need of drastical > upgrade of our router's linecards very soon. Many service providers won't > be able to finance this. > > On the name of this "minority", I call this FUD again, given that people who actually *study* routing table and assignment behaviour have not seen this imminent end of the IPv6 Internet anywhere near. In particular, the policy change that you claim to be instrumented by a "minority" is very clearly *not* visible in the data - see here: http://www.space.net/~gert/RIPE/weekly/2012/28/ in the "Allocations by Class and RIR Region" diagram, the dotted red line. (For the casual reader: Geza is still ranting about our "careless" change to the IPv6 PI assignment policy - if there's anything that's going to kill us, it's "not going to IPv6 quick enough to avoid the IPv4 explosion", not "being too liberal in giving out IPv6 number blocks") 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 brian.e.carpenter@gmail.com Thu Jul 12 00:23: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 EA3CF21F85D0 for ; Thu, 12 Jul 2012 00:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.231 X-Spam-Level: X-Spam-Status: No, score=-101.231 tagged_above=-999 required=5 tests=[AWL=0.460, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0jcFkD6-+9D for ; Thu, 12 Jul 2012 00:23: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 C509021F85C4 for ; Thu, 12 Jul 2012 00:23:21 -0700 (PDT) Received: by eaaq13 with SMTP id q13so653358eaa.31 for ; Thu, 12 Jul 2012 00:23:53 -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=rNZRPAZ6Z3HcZDbPe1q/fjqnVRHz06NTqiWN6p8dPyA=; b=efMhbIBwZCMdG4OvU9AlI0qAcfPa2F5odykDX7CqPdJWWF5QbIkTi0Mraj7vfJvEmB zltmqAXstFmd5pCve2hfH5qHmYzkqHjlTcAHNhq6Xu4+F9awKiWHo0+cakvnBJC29DxN OQ59yty+j+iH1AWGhCNu9tvJPRiNHipBIR3+kt1UJAecE4tuQ4KEylY4bUMi/nRHCqcg i+gTxvQroTceAhv4V1auNpuxakDxNHCtfLqgr2pd//rZ1nKs9oGUfJf4/xrgAY7LoUGq MuG5RFoWTOqsYZr6cjO36fJfinVFpHFk1BYPVwnyTKVsSIsq/4XwKr82cVWpTG2+QPsd S/gQ== Received: by 10.14.28.80 with SMTP id f56mr435090eea.133.1342077833399; Thu, 12 Jul 2012 00:23:53 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-217-107.as13285.net. [2.102.217.107]) by mx.google.com with ESMTPS id a16sm12746511eeg.0.2012.07.12.00.23.51 (version=SSLv3 cipher=OTHER); Thu, 12 Jul 2012 00:23:52 -0700 (PDT) Message-ID: <4FFE7B91.1030904@gmail.com> Date: Thu, 12 Jul 2012 08:24:01 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Gert Doering References: <4FFDACB2.9080106@switch.ch> <2CFB6DD5-7BD4-4044-AB71-16DF0C28734F@cisco.com> <4FFDD2FA.4040705@umn.edu> <20120711201422.GN38127@Space.Net> In-Reply-To: <20120711201422.GN38127@Space.Net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd: RIPE-555 fundamentaly changes the way how we can filter IPv6 & IPv4 martians? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Jul 2012 07:23:29 -0000 Gert, On 11/07/2012 21:14, Gert Doering wrote: > Hi, > > On Wed, Jul 11, 2012 at 02:24:42PM -0500, David Farmer wrote: >> So as it stands no one seems to claim responsibility for routing policy >> other than the operators themselves. > > Since they also have to foot the bill, that sounds somewhat reasonable > to me. No? No. It's known as the tragedy of the commons. That's where we seem to be headed, until something equivalent to the BGP crisis of 1993/1994 occurs for IPv6. As Randy said, it's a scaling issue. Brian From randy@psg.com Thu Jul 12 00:24: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 EBBCF21F86F0 for ; Thu, 12 Jul 2012 00:24:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w31pmUTlHSw9 for ; Thu, 12 Jul 2012 00:24:14 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 4107A21F86EF for ; Thu, 12 Jul 2012 00:24:14 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SpDlT-0001cY-Mq; Thu, 12 Jul 2012 07:24:44 +0000 Date: Thu, 12 Jul 2012 16:24:42 +0900 Message-ID: From: Randy Bush To: Gert Doering In-Reply-To: <20120712071843.GV38127@Space.Net> References: <4FFDACB2.9080106@switch.ch> <2CFB6DD5-7BD4-4044-AB71-16DF0C28734F@cisco.com> <20120712071843.GV38127@Space.Net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd: RIPE-555 fundamentaly changes the way how we can filter IPv6 & IPv4 martians? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Jul 2012 07:24:15 -0000 >>>> Is the architectural implications of routing and filtering policy an >>>> appropriate topic to invite a draft concerning? >>> >>> other than incorrect filters breaking connectivity, there are no >>> architectural implications, only scaling issues. >> >> and we could add: these scaling issues could create a need of drastical >> upgrade of our router's linecards very soon. Many service providers won't >> be able to finance this. >> >> On the name of this "minority", > > I call this FUD again, given that people who actually *study* routing > table and assignment behaviour have not seen this imminent end of the > IPv6 Internet anywhere near. first, fred asked about *architectural* issues. i repeat, there are none. then geza played sore loser, recycling a discussion he lost. i happened to agree with him at the time, but we lost, end. but geza was not saying the sky was falling. he was just saying that he was gonna be forced to pay fred for bigger line cards. this is not an ietf issue. nothing to see. move along. randy From gert@space.net Thu Jul 12 00: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 1EFD721F8742 for ; Thu, 12 Jul 2012 00:54:54 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5mL7nFvANM5m for ; Thu, 12 Jul 2012 00:54:53 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 443C121F8764 for ; Thu, 12 Jul 2012 00:54:53 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 3CE37F8C41 for ; Thu, 12 Jul 2012 09:55:25 +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 D86EBF8C4A for ; Thu, 12 Jul 2012 09:55:24 +0200 (CEST) Received: (qmail 7884 invoked by uid 1007); 12 Jul 2012 09:55:24 +0200 Date: Thu, 12 Jul 2012 09:55:24 +0200 From: Gert Doering To: Brian E Carpenter Message-ID: <20120712075524.GW38127@Space.Net> References: <4FFDACB2.9080106@switch.ch> <2CFB6DD5-7BD4-4044-AB71-16DF0C28734F@cisco.com> <4FFDD2FA.4040705@umn.edu> <20120711201422.GN38127@Space.Net> <4FFE7B91.1030904@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vZA0c23d8KJOGLy8" Content-Disposition: inline In-Reply-To: <4FFE7B91.1030904@gmail.com> X-NCC-RegID: de.space X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.21 (2010-09-15) Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd: RIPE-555 fundamentaly changes the way how we can filter IPv6 & IPv4 martians? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Jul 2012 07:54:54 -0000 --vZA0c23d8KJOGLy8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Jul 12, 2012 at 08:24:01AM +0100, Brian E Carpenter wrote: > On 11/07/2012 21:14, Gert Doering wrote: > > On Wed, Jul 11, 2012 at 02:24:42PM -0500, David Farmer wrote: > >> So as it stands no one seems to claim responsibility for routing polic= y=20 > >> other than the operators themselves. > >=20 > > Since they also have to foot the bill, that sounds somewhat reasonable= =20 > > to me. No? >=20 > No. It's known as the tragedy of the commons. That's where we seem to be = headed, > until something equivalent to the BGP crisis of 1993/1994 occurs for IPv6. > As Randy said, it's a scaling issue. OK, I bite. So who should be able to decide what prefixes an operator=20 should be carrying in their routers? The IETF has demonstrated a very clear non-understanding of operational realities out there with the "TLA" model - you can't just arbitrary decide "*you* are big/rich/nice/... enough to be permitted to the 8192 TLA club, and *you* are not, so go and change your business model" (which, incidently, the IETF didn't even try, it just put out the TLA model and didn't care for the implementation). The RIRs exist because their communities think they do a reasonable job,=20 so they should better do what their communities and paying members=20 want - which doesn't particularily qualify them to *set up* rules for the DFZ either. The RIRs could be tasked to monitor the DFZ, run more education, and chase violators - but they don't really have a reasonably big stick to *sanction* someone who is announcing arbitrary garbage. The operators are the ones who have the big stick, called "not accepting=20 routes that they deem unsuitable" - and they are the ones who have to give money to Fred if the scaling issue hits, so they (should) have an interest in caring. 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 --vZA0c23d8KJOGLy8 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iQCVAwUBT/6C7KkuBuNlUUl1AQISJQP/U9m4H95Ax+hOEhblPQcTDczR0FhR1+Uz UR76IP0RFSf3jcb/cGRLHPeA4gtQvkXmTXSGL0NM+ysVpP8RW/na+AM/5uKdCwzg fW4jjrzBjPjiEZm/XC9WsjkB932qMHn1dezSer7FYr2EEyLmEeQTLAaHYV56qsba QROHTjlgW9I= =XytI -----END PGP SIGNATURE----- --vZA0c23d8KJOGLy8-- From cathy.zhou@huawei.com Thu Jul 12 01:07: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 C296821F8795 for ; Thu, 12 Jul 2012 01:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.604 X-Spam-Level: X-Spam-Status: No, score=-5.604 tagged_above=-999 required=5 tests=[AWL=-0.845, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AaGty+yFZ311 for ; Thu, 12 Jul 2012 01:07:51 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 11B8821F8793 for ; Thu, 12 Jul 2012 01:07:51 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHR53540; Thu, 12 Jul 2012 04:08:23 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 12 Jul 2012 01:05:24 -0700 Received: from SZXEML430-HUB.china.huawei.com (10.72.61.38) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 12 Jul 2012 01:05:29 -0700 Received: from SZXEML527-MBS.china.huawei.com ([169.254.6.143]) by szxeml430-hub.china.huawei.com ([10.72.61.38]) with mapi id 14.01.0323.003; Thu, 12 Jul 2012 16:05:24 +0800 From: "Zhouqian (Cathy)" To: Brian E Carpenter , Qiong Thread-Topic: [v6ops] Draft on DC migration to IPv6 Thread-Index: AQHNW5Grz6Airmi1OkGxTcsV2RJJE5cj2oyg///O9ACAAA/bgIAAGZWAgAC4cACAADPzAIAAkxxQ Date: Thu, 12 Jul 2012 08:05:23 +0000 Message-ID: References: <28DC472D-01D4-4534-97A9-6AE52BE9CC58@tid.es> <4FF70D8F.5010706@bogus.com> <4FFDB38F.3080206@bogus.com> <4FFE79DA.3010408@gmail.com> In-Reply-To: <4FFE79DA.3010408@gmail.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.77.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: IPv6 Ops WG Subject: Re: [v6ops] Draft on DC migration to IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Jul 2012 08:07:51 -0000 Hi Brian, -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of B= rian E Carpenter Sent: Thursday, July 12, 2012 3:17 PM To: Qiong Cc: IPv6 Ops WG Subject: Re: [v6ops] Draft on DC migration to IPv6 On 12/07/2012 05:10, Qiong wrote: ... >> The fact that the carrier the customer is behind might also nat their >> source address or that they have a residential gateway is a rather more >> distant problem then an nat64 located rather closer to me. I still want >> to know that the source is verizon's cgnat rather than my local nat64 >> gateway. >> > But the fact is that you can not "assume" how close this NAT64 gateway is > the network. This depends on the operational deployment model, traffic > model, etc. It might be deployed distributed, centralized or in other way= s. > But anyway, you will lose the orignial address and you can not trust it > anymore. Even if it is still a verizon's address, you can not know to wha= t > extend the granularity you have lost. It is a reality now, and it will be > more and more prevalent in the future. The content provider should also > have to face it. Consider that this is also a massive problem created by the deployment of NAT444 brought about by CGNs. IPv6 can only win here, as it offers a long-term solution. But it seems clear to me that in the short term, IPv6 wins if we advocate full dual stack for DCs, because that maximizes the num= ber of cases in which we have end to end addressing and therefore have useable geolocation. Full IPv6 in datacenter is the ultimate goal. However, the datacenter suppo= rting IPv6 is not only network supporting, but also application layer suppo= rting. Supporting IPv6 is a huge cost for the existing IPv4 only datacenter= and some small ICPs. Currently, the IPv6 traffic and users are only a smal= l part. Forcing the datacenter to fully support IPv6 is not a good choice a= t the beginning of IPv6 migration, and it may even impact the evolution of = IPv6. It may be a good way to let current IPv4 only datacenter support IPv6= with small change. Through this way, it can promote the growth of IPv6 tra= ffic. Cathy Brian _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From randy@psg.com Thu Jul 12 01:37: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 18D0D21F87A4 for ; Thu, 12 Jul 2012 01:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.969 X-Spam-Level: X-Spam-Status: No, score=-1.969 tagged_above=-999 required=5 tests=[AWL=-0.610, BAYES_00=-2.599, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id khQ-VsA6u-zC for ; Thu, 12 Jul 2012 01:37:52 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id A5EE721F8780 for ; Thu, 12 Jul 2012 01:37:52 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SpEul-0001jK-1D; Thu, 12 Jul 2012 08:38:23 +0000 Date: Thu, 12 Jul 2012 17:38:21 +0900 Message-ID: From: Randy Bush To: "Zhouqian (Cathy)" In-Reply-To: References: <28DC472D-01D4-4534-97A9-6AE52BE9CC58@tid.es> <4FF70D8F.5010706@bogus.com> <4FFDB38F.3080206@bogus.com> <4FFE79DA.3010408@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: IPv6 Ops WG Subject: Re: [v6ops] Draft on DC migration to IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Jul 2012 08:37:53 -0000 > Consider that this is also a massive problem created by the deployment > of NAT444 brought about by CGNs. IPv6 can only win here, as it offers a > long-term solution. But it seems clear to me that in the short term, IPv6 > wins if we advocate full dual stack for DCs, because that maximizes the number > of cases in which we have end to end addressing and therefore have useable > geolocation. > > Full IPv6 in datacenter is the ultimate goal. However, the datacenter > supporting IPv6 is not only network supporting, but also application > layer supporting. Supporting IPv6 is a huge cost for the existing IPv4 > only datacenter and some small ICPs. Currently, the IPv6 traffic and > users are only a small part. Forcing the datacenter to fully support > IPv6 is not a good choice at the beginning of IPv6 migration, and it > may even impact the evolution of IPv6. It may be a good way to let > current IPv4 only datacenter support IPv6 with small change. Through > this way, it can promote the growth of IPv6 traffic. > > Cathy i am having problems reconciling these two paragraphs. randy From nick@inex.ie Thu Jul 12 02:56: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 3C83021F8779 for ; Thu, 12 Jul 2012 02:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rq8y+3Y3+FF0 for ; Thu, 12 Jul 2012 02:56:04 -0700 (PDT) Received: from mail.acquirer.com (mail.acquirer.com [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id DD9FB21F877B for ; Thu, 12 Jul 2012 02:56:02 -0700 (PDT) X-Envelope-To: Received: from crumpet.local ([IPv6:2001:1bb8:2004:100:84b7:e68b:c9d0:87f]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id q6C9tfQS046628 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 12 Jul 2012 10:55:42 +0100 (IST) (envelope-from nick@inex.ie) Message-ID: <4FFE9F4E.7080100@inex.ie> Date: Thu, 12 Jul 2012 10:56:30 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: v6ops@ietf.org References: <4FFDACB2.9080106@switch.ch> <2CFB6DD5-7BD4-4044-AB71-16DF0C28734F@cisco.com> <4FFDD2FA.4040705@umn.edu> <20120711201422.GN38127@Space.Net> <4FFE7B91.1030904@gmail.com> In-Reply-To: <4FFE7B91.1030904@gmail.com> X-Enigmail-Version: 1.4.2 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] Fwd: RIPE-555 fundamentaly changes the way how we can filter IPv6 & IPv4 martians? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Jul 2012 09:56:05 -0000 On 12/07/2012 08:24, Brian E Carpenter wrote: > No. It's known as the tragedy of the commons. That's where we seem to be headed, > until something equivalent to the BGP crisis of 1993/1994 occurs for IPv6. > As Randy said, it's a scaling issue. the bgp crisis of 1993/1994 related to address exhaustion due to a bad allocation strategy. It was worked around initially by CIDR and later NAT. But it wasn't related to forwarding table size: you could still hold a full table in a Cisco 2500 at the time. Nick From turchanyi.geza@gmail.com Thu Jul 12 03:54: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 1AB5021F864A for ; Thu, 12 Jul 2012 03:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2asSC6adP8nP for ; Thu, 12 Jul 2012 03:54:11 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id A3A9921F87D1 for ; Thu, 12 Jul 2012 03:54:11 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so3799634pbc.31 for ; Thu, 12 Jul 2012 03:54: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=zsWyTYOqD7ATSCDht+jsMAwumS4AvcRzRB2Moij/zlI=; b=Usryc4S6ykjgyd0tUXCAfgn9MHlrX56Rjs1uq2CSwTylJVMNQnPhyFG0mwD/3cTGER XRnQ8d/QkoUZhYzh/9bxu3IRk1nIW/Dsw63taSBGHYdzd+zQQwvjohiLAyCNS3B659ju LAj0oUbmTZ03ifXbjYanGYfCSW96veVKHVYaeJMt++GNdS7+cyO+lU/C9hN9X+0WMwzW mxUgxeskNE1Hjk6WcvFNHd25k/uOfKsaRtlGu/jZZ4ctEqF+PXWbmeCjUvbkhCvWirO5 NoM0Dje95DbjfVy+wHes+azxYKn2pY84F1NNyfMacBbv7y0JckotcMP3yZFiXLJDyz+B TRdg== MIME-Version: 1.0 Received: by 10.68.194.4 with SMTP id hs4mr4395188pbc.128.1342090484578; Thu, 12 Jul 2012 03:54:44 -0700 (PDT) Received: by 10.66.228.131 with HTTP; Thu, 12 Jul 2012 03:54:44 -0700 (PDT) In-Reply-To: <20120712075524.GW38127@Space.Net> References: <4FFDACB2.9080106@switch.ch> <2CFB6DD5-7BD4-4044-AB71-16DF0C28734F@cisco.com> <4FFDD2FA.4040705@umn.edu> <20120711201422.GN38127@Space.Net> <4FFE7B91.1030904@gmail.com> <20120712075524.GW38127@Space.Net> Date: Thu, 12 Jul 2012 12:54:44 +0200 Message-ID: From: Turchanyi Geza To: Gert Doering Content-Type: multipart/alternative; boundary=047d7b15a8a596f7d604c49fcaf7 Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd: RIPE-555 fundamentaly changes the way how we can filter IPv6 & IPv4 martians? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Jul 2012 10:54:16 -0000 --047d7b15a8a596f7d604c49fcaf7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Gert, you were right when you proposed -- that time, temporaly, just in the initial phase of IPv6 addresss allocation -- suspending the TLA concept, in order to facilitate the IPv6 address allocation to start. May be it was in 2002, I do not remember exactly, however, I remember for the debat and for your arguments. However, the TLA concept was not bad and my guess is that we must come back to it or something very similar in the (not too far) future. The other question who has the stick in hands is wrong: It is the regulator= . If self regulation of the Internet happen to not working, it will be done by politically controlled boards.. Good luck, G=E9za On Thu, Jul 12, 2012 at 9:55 AM, Gert Doering wrote: > Hi, > > On Thu, Jul 12, 2012 at 08:24:01AM +0100, Brian E Carpenter wrote: > > On 11/07/2012 21:14, Gert Doering wrote: > > > On Wed, Jul 11, 2012 at 02:24:42PM -0500, David Farmer wrote: > > >> So as it stands no one seems to claim responsibility for routing > policy > > >> other than the operators themselves. > > > > > > Since they also have to foot the bill, that sounds somewhat reasonabl= e > > > to me. No? > > > > No. It's known as the tragedy of the commons. That's where we seem to b= e > headed, > > until something equivalent to the BGP crisis of 1993/1994 occurs for > IPv6. > > As Randy said, it's a scaling issue. > > OK, I bite. So who should be able to decide what prefixes an operator > should be carrying in their routers? > > The IETF has demonstrated a very clear non-understanding of operational > realities out there with the "TLA" model - you can't just arbitrary decid= e > "*you* are big/rich/nice/... enough to be permitted to the 8192 TLA club, > and *you* are not, so go and change your business model" (which, > incidently, > the IETF didn't even try, it just put out the TLA model and didn't care > for the implementation). > > The RIRs exist because their communities think they do a reasonable job, > so they should better do what their communities and paying members > want - which doesn't particularily qualify them to *set up* rules for > the DFZ either. The RIRs could be tasked to monitor the DFZ, run more > education, and chase violators - but they don't really have a reasonably > big stick to *sanction* someone who is announcing arbitrary garbage. > > The operators are the ones who have the big stick, called "not accepting > routes that they deem unsuitable" - and they are the ones who have to > give money to Fred if the scaling issue hits, so they (should) have an > interest in caring. > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culema= nn > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --047d7b15a8a596f7d604c49fcaf7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Gert,

you were right when you proposed -- that time, temporaly, just= in the initial phase of IPv6 addresss allocation -- suspending the TLA con= cept, in order to facilitate the IPv6 address allocation to start. May be i= t was in 2002, I do not remember exactly, however, I remember for the debat= and for your arguments.

However, the TLA concept was not bad and my guess is that we must come = back to it or something very similar in the (not too far) future.

Th= e other question who has the stick in hands is wrong: It is the regulator.<= br>
If self regulation of the Internet happen to not working, it will be do= ne by politically controlled boards..

Good luck,

G=E9za

On Thu, Jul 12, 2012 at 9:55 AM, Gert Doerin= g <gert@space.net> wrote:
Hi,

On Thu, Jul 12, 2012 at 08:24:01AM +0100, Brian E Carpenter wrote:
> On 11/07/2012 21:14, Gert Doering wrote:
> > On Wed, Jul 11, 2012 at 02:24:42PM -0500, David Farmer= wrote:
> >> So as it stands no one seems to claim responsibility for rout= ing policy
> >> other than the operators themselves.
> >
> > Since they also have to foot the bill, that sounds somewhat reaso= nable
> > to me. =A0No?
>
> No. It's known as the tragedy of the commons. That's where we = seem to be headed,
> until something equivalent to the BGP crisis of 1993/1994 occurs for I= Pv6.
> As Randy said, it's a scaling issue.

OK, I bite. =A0So who should be able to decide what prefixes an opera= tor
should be carrying in their routers?

The IETF has demonstrated a very clear non-understanding of operational
realities out there with the "TLA" model - you can't just arb= itrary decide
"*you* are big/rich/nice/... enough to be permitted to the 8192 TLA cl= ub,
and *you* are not, so go and change your business model" (which, incid= ently,
the IETF didn't even try, it just put out the TLA model and didn't = care
for the implementation).

The RIRs exist because their communities think they do a reasonable job, so they should better do what their communities and paying members
want - which doesn't particularily qualify them to *set up* rules for the DFZ either. =A0The RIRs could be tasked to monitor the DFZ, run more education, and chase violators - but they don't really have a reasonabl= y
big stick to *sanction* someone who is announcing arbitrary garbage.

The operators are the ones who have the big stick, called "not accepti= ng
routes that they deem unsuitable" - and they are the ones who have to<= br> give money to Fred if the scaling issue hits, so they (should) have an
interest in caring.

Gert Doering
=A0 =A0 =A0 =A0 -- NetMaster
--
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.: D= E813185279

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


--047d7b15a8a596f7d604c49fcaf7-- From gert@space.net Thu Jul 12 04:17: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 62B8821F8804 for ; Thu, 12 Jul 2012 04:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJ7aRGDKsbtF for ; Thu, 12 Jul 2012 04:17:32 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8D70021F8803 for ; Thu, 12 Jul 2012 04:17:31 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id B090EF8C4B for ; Thu, 12 Jul 2012 13:18:03 +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 8FB43F8C50 for ; Thu, 12 Jul 2012 13:18:03 +0200 (CEST) Received: (qmail 72724 invoked by uid 1007); 12 Jul 2012 13:18:03 +0200 Date: Thu, 12 Jul 2012 13:18:03 +0200 From: Gert Doering To: Turchanyi Geza Message-ID: <20120712111803.GB38127@Space.Net> References: <4FFDACB2.9080106@switch.ch> <2CFB6DD5-7BD4-4044-AB71-16DF0C28734F@cisco.com> <4FFDD2FA.4040705@umn.edu> <20120711201422.GN38127@Space.Net> <4FFE7B91.1030904@gmail.com> <20120712075524.GW38127@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LGhQbn2N+4fvG9BK" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.21 (2010-09-15) Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd: RIPE-555 fundamentaly changes the way how we can filter IPv6 & IPv4 martians? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Jul 2012 11:17:33 -0000 --LGhQbn2N+4fvG9BK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Jul 12, 2012 at 12:54:44PM +0200, Turchanyi Geza wrote: > you were right when you proposed -- that time, temporaly, just in the > initial phase of IPv6 addresss allocation -- suspending the TLA concept, = in > order to facilitate the IPv6 address allocation to start. May be it was in > 2002, I do not remember exactly, however, I remember for the debat and for > your arguments. >=20 > However, the TLA concept was not bad and my guess is that we must come ba= ck > to it or something very similar in the (not too far) future. The TLA concept was nice in theory, but not applicable to reality. Unless you are able to draw a clear line "this network gets a TLA, and that network does not get a TLA" that is clear enough so it can actually be implemented, and that will not destroy the existing tight peering mesh of the Internet, it is not useful. Now, geographical aggregation is a concept that might actually have worked, but it was too foreign for operators to understand, so lacked uptake. > The other question who has the stick in hands is wrong: It is the regulat= or. >=20 > If self regulation of the Internet happen to not working, it will be done > by politically controlled boards.. >=20 > Good luck, "Self destruction by fear of the future" is also a sign of failing self regulation. 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 --LGhQbn2N+4fvG9BK Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iQCVAwUBT/6ya6kuBuNlUUl1AQKnHQP8DLbTaOw1LmxCsm/l052zMSdf9zZCThf2 605HZkxtRXluHplwWEjOZpqGAuGPuq66OwT5wRILXEfoxFs7cVoN8INsgYQDM6XD lWeEPSaLXyabSd8jJ8Oq+SdKeq/R0rzn67UxBysLvdr2ZM+CornHosoqvUXpNxDE WMFIFeFX1aM= =s3xS -----END PGP SIGNATURE----- --LGhQbn2N+4fvG9BK-- From evyncke@cisco.com Thu Jul 12 04:19: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 1368921F880E for ; Thu, 12 Jul 2012 04:19:30 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EbV27Ywf9w1t for ; Thu, 12 Jul 2012 04:19:29 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id E5D8521F87AA for ; Thu, 12 Jul 2012 04:19:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=evyncke@cisco.com; l=1252; q=dns/txt; s=iport; t=1342092002; x=1343301602; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=i4CukMFXGasOH1LOf7PouBr+TKPk6KsMKEo1rO/ZW30=; b=LW1P1XfIBlLy5JW4nVa83C5s5LPeNL3A0Z2IoeI6Ps2nn3uDe1rPyFdR N3dGWhBr2XZXsi7yEfRkOUpbccEoDekPpZh+tk7Fmz7wfXzmpmYrcZcni GFc5N2FvFG/x2GyMlJJg8QoHqXIPaA0upb2LzNi5/QOdCvByvTXKCszWq w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANux/k+tJXHB/2dsb2JhbABFt3iBB4IgAQEBBAEBAQ8BWwsMBAIBCBEEAQELHQcnCxQJCAIEAQ0FCAEZh2sLnUugH4tAFIUIYAOIFptEgWaCX4FW X-IronPort-AV: E=Sophos;i="4.77,573,1336348800"; d="scan'208";a="100963030" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-1.cisco.com with ESMTP; 12 Jul 2012 11:20:01 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q6CBK1F0017445 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Jul 2012 11:20:01 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.178]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0298.004; Thu, 12 Jul 2012 06:20:01 -0500 From: "Eric Vyncke (evyncke)" To: "Fred Baker (fred)" , "v6ops@ietf.org WG" Thread-Topic: [v6ops] Prep for v6ops IETF 84 agenda Thread-Index: AQHNUnbpWFu7FKUfJEyvobkjy/vWXZcjFqiAgAHweICAAJM6cA== Date: Thu, 12 Jul 2012 11:20:00 +0000 Message-ID: <97EB7536A2B2C549846804BBF3FD47E10475CC@xmb-aln-x02.cisco.com> References: <8D73E1D6-A968-4397-A843-FE073197B7F1@cisco.com> <45F1DB32-74F6-4E4A-88E2-118B76A5F474@cisco.com> <49128AF1-1EF0-478B-B5E1-2B5A73AFE1A3@cisco.com> In-Reply-To: <49128AF1-1EF0-478B-B5E1-2B5A73AFE1A3@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.185.70] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19034.006 x-tm-as-result: No--30.572600-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: "lee.howard@twcable.com" , Ron Bonica , "victor.kuarsingh@rci.rogers.com" Subject: Re: [v6ops] Prep for v6ops IETF 84 agenda X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Jul 2012 11:19:30 -0000 Fred and Joel, As several authors of draft-chkpvc-enterprise-incremental-ipv6-00 will be i= n Vancouver, can we have a slot at one V6OPS WG meeting to present our I-D?= It has got some discussions on the list in June so there is indeed interes= t (and I agree with Brian this may be too ambitious and could be limited to= a RFC roadmap for beginners). Thanks a lot in advance Regards -=E9ric PS: and I understand that, once again, we are late. > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Fred Baker (fred) > Sent: mercredi 11 juillet 2012 23:28 > To: v6ops@ietf.org WG > Cc: Ron Bonica > Subject: Re: [v6ops] Prep for v6ops IETF 84 agenda >=20 > I have uploaded a preliminary agenda, at > http://www.ietf.org/proceedings/84/agenda/agenda-84-v6ops >=20 > I have put the drafts that I identified as clearly appropriate on Thursda= y, > and the "unclear" on Friday. Those who object to the latter set are free = to > leave Thursday evening :-) We should have at least half an hour per draft > for discussion. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nick@inex.ie Thu Jul 12 04:27: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 5A34321F8811 for ; Thu, 12 Jul 2012 04:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jzxtoc7wF2Ay for ; Thu, 12 Jul 2012 04:27:09 -0700 (PDT) Received: from mail.acquirer.com (mail.acquirer.com [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 95B4221F876F for ; Thu, 12 Jul 2012 04:27:09 -0700 (PDT) X-Envelope-To: Received: from crumpet.local (inet-gw.acquirer.com [87.198.142.10]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id q6CBQo1G060189 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 12 Jul 2012 12:26:52 +0100 (IST) (envelope-from nick@inex.ie) Message-ID: <4FFEB4AB.40400@inex.ie> Date: Thu, 12 Jul 2012 12:27:39 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: v6ops@ietf.org References: <4FFDACB2.9080106@switch.ch> <2CFB6DD5-7BD4-4044-AB71-16DF0C28734F@cisco.com> <4FFDD2FA.4040705@umn.edu> <20120711201422.GN38127@Space.Net> <4FFE7B91.1030904@gmail.com> <20120712075524.GW38127@Space.Net> In-Reply-To: X-Enigmail-Version: 1.4.2 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] Fwd: RIPE-555 fundamentaly changes the way how we can filter IPv6 & IPv4 martians? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Jul 2012 11:27:10 -0000 On 12/07/2012 11:54, Turchanyi Geza wrote: > However, the TLA concept was not bad TLAs are an utterly broken concept unless you like the idea of top-down incumbent-style networking frameworks. The strength of the Internet is its distributed nature which allows anyone to provide services at any level without regard to existing anti-competitive interests. Any attempt to warp this into a top-down model should be killed in a fire. Nick From cathy.zhou@huawei.com Thu Jul 12 04:37: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 AE1A021F8821 for ; Thu, 12 Jul 2012 04:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.355 X-Spam-Level: X-Spam-Status: No, score=-6.355 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bEL+K1hqbPqz for ; Thu, 12 Jul 2012 04:37:25 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 78A6221F8815 for ; Thu, 12 Jul 2012 04:37:25 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHY63139; Thu, 12 Jul 2012 07:37:58 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 12 Jul 2012 04:35:16 -0700 Received: from SZXEML436-HUB.china.huawei.com (10.72.61.64) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 12 Jul 2012 04:35:21 -0700 Received: from SZXEML527-MBS.china.huawei.com ([169.254.6.143]) by szxeml436-hub.china.huawei.com ([10.72.61.64]) with mapi id 14.01.0323.003; Thu, 12 Jul 2012 19:35:18 +0800 From: "Zhouqian (Cathy)" To: "Diego R. Lopez" , "Fred Baker (fred)" Thread-Topic: [v6ops] Draft on DC migration to IPv6 Thread-Index: AQHNW5Grz6Airmi1OkGxTcsV2RJJE5cj2oyg///O9ACAAAdHgIAB2Gag Date: Thu, 12 Jul 2012 11:35:17 +0000 Message-ID: References: <28DC472D-01D4-4534-97A9-6AE52BE9CC58@tid.es> <4FF70D8F.5010706@bogus.com> <9E1CA4A1-8AE8-4EA0-80DD-55719A29AB17@tid.es> In-Reply-To: <9E1CA4A1-8AE8-4EA0-80DD-55719A29AB17@tid.es> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.77.118] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: IPv6 Ops WG Subject: Re: [v6ops] Draft on DC migration to IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Jul 2012 11:37:26 -0000 QWdyZWUgd2l0aCBEaWVnbyB0aGF0IHRoZSBzb2x1dGlvbiBpbiB0aGlzIGRvY3VtZW50IGlzIG9u bHkgYSBwb3NzaWJsZSB3YXkuIA0KRm9yIHRoZSBvcGVyYXRvcnMgd2hvIGhhdmUgZWFzeSBJUHY2 IGFjY2VzcywgTkFUIGlzIG5vdCBuZWVkZWQuIFRoZSBzb3VyY2UgYWRkcmVzcyBjb3VsZCBiZSBw cmVzZW50ZWQgdG8gdGhlIGFwcGxpY2F0aW9uLg0KQnV0IGZvciB0aGUgb3BlcmF0b3JzIHdobyBk b24ndCBoYXZlIGVhc3kgSVB2NiBhY2Nlc3MsIHNvbWUgZW5jYXBzdWxhdGlvbiBtZXRob2Qgc2hv dWxkIA0KYmUgdXNlZCwgZS5nLiwgSVB2Ni1pbi1JUHY0LCB0byBjYXJyeSBJUHY2IHRyYWZmaWMg b3ZlciBJUHY0Lg0KDQpCZXN0IFJlZ2FyZHMsDQpDYXRoeQ0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogRGllZ28gUi4gTG9wZXogW21haWx0bzpkaWVnb0B0aWQuZXNdIA0KU2Vu dDogV2VkbmVzZGF5LCBKdWx5IDExLCAyMDEyIDExOjA4IFBNDQpUbzogRnJlZCBCYWtlciAoZnJl ZCkNCkNjOiBaaG91cWlhbiAoQ2F0aHkpOyBJUHY2IE9wcyBXRw0KU3ViamVjdDogUmU6IFt2Nm9w c10gRHJhZnQgb24gREMgbWlncmF0aW9uIHRvIElQdjYNCg0KSGksDQoNCk9uIDExIEp1bCAyMDEy LCBhdCAxNjo0MiAsIEZyZWQgQmFrZXIgKGZyZWQpIHdyb3RlOg0KPiBPbiBKdWwgMTEsIDIwMTIs IGF0IDI6MzkgQU0sIFpob3VxaWFuIChDYXRoeSkgd3JvdGU6DQo+DQo+PiBbQ2F0aHldIFRoZSBj b250ZW50IHByb3ZpZGVyIHdpbGwgbm90IGxvc2UgdGhlIHNvdXJjZSBhZGRyZXNzIGFzc29jaWF0 ZWQgd2l0aCB0aGUgaW5jb21pbmcgcmVxdWVzdC4gVGhlIHNvdXJjZSBJUHY2IGFkZHJlc3MgaXMg dHJhbnNsYXRlZCB0byBJUHY0IGFkZHJlc3MsIGFuZCB0aGUgdHJhbnNsYXRvciBuZWVkIHJldGFp biB0aGUgY29ycmVzcG9uZGVuY2UgYmV0d2VlbiBJUHY2IHNvdXJjZSBhZGRyZXNzIGFuZCBJUHY0 IHNvdXJjZSBhZGRyZXNzLg0KPg0KPiBZZXMsIGJ1dCBmb3IgbWFueSBkYXRhIGNlbnRlciBhcHBs aWNhdGlvbnMsIHRoZSBhcHBsaWNhdGlvbiBpdHNlbGYgd2FudHMgdG8ga25vdyB0aGUgb3JpZ2lu YWwgc291cmNlIGFkZHJlc3MgaW4gb3JkZXIgdG8gcHJvdmlkZSBsb2NhdGlvbi1hd2FyZSBzZXJ2 aWNlcy4gU28gaXQgaXMgbm90IHN1ZmZpY2llbnQgZm9yIHRoZSBOQVQgdG8ga25vdzsgdGhlIGlu Zm9ybWF0aW9uIG5lZWRzIHRvIHNvbWVob3cgYmUgcHJlc2VudGVkIHRvIHRoZSBhcHBsaWNhdGlv bi4gVGhpcyBoYXMgYmVlbiBicm91Z2h0IHVwIGJ5IExvcmVuem8gYW1vbmcgb3RoZXJzIGFzIGEg cmVxdWlyZW1lbnQgaW4gdGhlaXIgZGF0YSBjZW50ZXJzIGFuZCBwdWJsaWMgc2VydmljZXMuDQoN ClRoZSBkcmFmdCBkb2VzIG5vdCBpbXBseSB0aGF0IHRoaXMgaXMgYSByZWNvbW1lbmRlZCBvciBk ZXNpcmFibGUgc29sdXRpb24sIGJ1dCBqdXN0DQp1c2VzIGl0IHRvIGlsbHVzdHJhdGUgYSBwb3Nz aWJsZSB3YXkgb2YgYWNoaWV2aW5nIGxldmVsIDEsIHRoYXQgaGF2ZSBiZWVuIHJlcG9ydGVkDQph cyBhIHNlcnZpY2UgYnkgYSBuZXR3b3JrIG9wZXJhdG9yLiBBbmQgSSBjYW4gaW1hZ2luZSB0aGF0 IHNvbWUgREMgb3BlcmF0b3JzDQptYXkgd2VsbCByZW5vdW5jZSB0byBrbm93IHRoZSBhY3R1YWwg djYgc291cmNlIGlmIHRoZXkgY2FuIGhhdmUgYW4gZWFzeSBwYXRoIHRvDQphY2hpZXZlIHY2IGFj Y2VzaWJpbGl0eSB2aWEgYSBtYW5hZ2VkIHNlcnZpY2UgbGlrZSB0aGlzLg0KDQpBbmQsIGp1c3Qg aW4gY2FzZSwgSSBwZXJzb25hbGx5IGZpbmQgbWFueSBvZiB0aG9zZSBsb2NhdGlvbi1hd2FyZSBz ZXJ2aWNlcyBtb3JlIGFuDQphbm5veWFuY2UgdGhhbiAgYW55dGhpbmcgZWxzZTogSSBkb24ndCBz ZWUgYW55IGFkdmFudGFnZSBpbiBnZXR0aW5nIGFuIEVzdG9uaWFuIFVJIG9yDQphIHNlYXJjaCBl bmdpbmUgcHJpb3JpdGl6aW5nIHJlc3VsdHMgaW4gTm9yd2VnaWFuIGZvciBtZS4NCg0KQmUgZ29v ZGUuDQoNCiJFc3RhIHZleiBubyBmYWxsYXJlbW9zLCBEb2N0b3IgSW5maWVybm8iDQoNCkRyIERp ZWdvIFIuIExvcGV6DQpUZWxlZm9uaWNhIEkrRA0KaHR0cDovL3Blb3BsZS50aWQuZXMvZGllZ28u bG9wZXovDQoNCmUtbWFpbDogZGllZ29AdGlkLmVzDQpUZWw6ICAgICszNCA5MTMgMTI5IDA0MQ0K TW9iaWxlOiArMzQgNjgyIDA1MSAwOTENCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KRXN0ZSBt ZW5zYWplIHNlIGRpcmlnZSBleGNsdXNpdmFtZW50ZSBhIHN1IGRlc3RpbmF0YXJpby4gUHVlZGUg Y29uc3VsdGFyIG51ZXN0cmEgcG9sw610aWNhIGRlIGVudsOtbyB5IHJlY2VwY2nDs24gZGUgY29y cmVvIGVsZWN0csOzbmljbyBlbiBlbCBlbmxhY2Ugc2l0dWFkbyBtw6FzIGFiYWpvLg0KVGhpcyBt ZXNzYWdlIGlzIGludGVuZGVkIGV4Y2x1c2l2ZWx5IGZvciBpdHMgYWRkcmVzc2VlLiBXZSBvbmx5 IHNlbmQgYW5kIHJlY2VpdmUgZW1haWwgb24gdGhlIGJhc2lzIG9mIHRoZSB0ZXJtcyBzZXQgb3V0 IGF0Lg0KaHR0cDovL3d3dy50aWQuZXMvRVMvUEFHSU5BUy9kaXNjbGFpbWVyLmFzcHgNCg== From brian.e.carpenter@gmail.com Thu Jul 12 05: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 C878821F844C for ; Thu, 12 Jul 2012 05:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.242 X-Spam-Level: X-Spam-Status: No, score=-101.242 tagged_above=-999 required=5 tests=[AWL=0.449, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v0-Qxpc5JXSk for ; Thu, 12 Jul 2012 05:18:03 -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 F3C4421F87C7 for ; Thu, 12 Jul 2012 05:18:02 -0700 (PDT) Received: by eekd4 with SMTP id d4so781098eek.31 for ; Thu, 12 Jul 2012 05:18:35 -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=hUbbt7yCg6vmHopQhyeAyz2qdZ9bu1zNvYJo33+G8B4=; b=k0Fv8Q/EjUuFIBKbOJHq4+ez4xPHF3bUk5UpqjJIR6QIvrs4rFSHtYydcQ7t8pfCH3 /Sw3MbuRfbXb1mD1v0dUDfjwmO0GQcAl4lr44tpxyHq2vxk5K7D2+DGWaMCPQs+1Qf2W vZtDrJX9TK+tcgJSrXh1GIrv6wYsPoSaQuULu4cyCzR6gfLRu8zoTzgmvtTnD4WJF7bI 17KVqxTlH3As2rNkIdCxEVB6DBdS47o0pbw8Ha4OTKkRcacWCNxzNRlHVfaR44nI9LH8 aqkM/Y/CgtjZkQjJPq98Y5KBSqTvQA11swYwbqnotQsJo4yBKcq1p5LTOY8x3KEDzApT IT1Q== Received: by 10.14.99.1 with SMTP id w1mr12746771eef.74.1342095515526; Thu, 12 Jul 2012 05:18:35 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-217-107.as13285.net. [2.102.217.107]) by mx.google.com with ESMTPS id a16sm15181324eeg.0.2012.07.12.05.18.33 (version=SSLv3 cipher=OTHER); Thu, 12 Jul 2012 05:18:33 -0700 (PDT) Message-ID: <4FFEC0A4.2070509@gmail.com> Date: Thu, 12 Jul 2012 13:18:44 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Nick Hilliard References: <4FFDACB2.9080106@switch.ch> <2CFB6DD5-7BD4-4044-AB71-16DF0C28734F@cisco.com> <4FFDD2FA.4040705@umn.edu> <20120711201422.GN38127@Space.Net> <4FFE7B91.1030904@gmail.com> <4FFE9F4E.7080100@inex.ie> In-Reply-To: <4FFE9F4E.7080100@inex.ie> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: RIPE-555 fundamentaly changes the way how we can filter IPv6 & IPv4 martians? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Jul 2012 12:18:03 -0000 On 12/07/2012 10:56, Nick Hilliard wrote: > On 12/07/2012 08:24, Brian E Carpenter wrote: >> No. It's known as the tragedy of the commons. That's where we seem to be headed, >> until something equivalent to the BGP crisis of 1993/1994 occurs for IPv6. >> As Randy said, it's a scaling issue. > > the bgp crisis of 1993/1994 related to address exhaustion due to a bad > allocation strategy. It was worked around initially by CIDR and later NAT. > But it wasn't related to forwarding table size: you could still hold a > full table in a Cisco 2500 at the time. But only just. If the growth had continued as it was going at the start of 1994, that would soon have been untrue. Bothe BGP4 and CIDR were needed to allow router memory size to keep up with reality. Brian From brian.e.carpenter@gmail.com Thu Jul 12 05:19: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 3E55A21F8816 for ; Thu, 12 Jul 2012 05:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.253 X-Spam-Level: X-Spam-Status: No, score=-101.253 tagged_above=-999 required=5 tests=[AWL=0.438, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pO79Irl8F6-q for ; Thu, 12 Jul 2012 05:19:34 -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 8794521F87F3 for ; Thu, 12 Jul 2012 05:19:34 -0700 (PDT) Received: by eekd4 with SMTP id d4so781698eek.31 for ; Thu, 12 Jul 2012 05:20:07 -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=bJ+gwBln4LsZhWdapbFtZEkmDccMpTs6Gqo+A61C9u4=; b=EO8eSo/f0gZHS1FKVZq8+oNeJJaPutbg1R1p2QZwWMvgPYO6N22qz6L7XqJ1yiapBH hENnsrNS/9hlIh6D+qi4lfP/Emuot0gKJhZr3YcurIDC2hW48vWWR1ii3LR0eTaVJ5p6 X7DMPnmqoC5jikJpLmgVXFwGUpXtuPbZ5A2aS2rUfLzMZgNBHRpzU4J4Ela7zTQdtOx8 8Qn3nIx9cxBwCcukj+pkP9JQ8rPgEuEtjfEUwfps23MxwlFd5ikT9eA3+65HkuJ4gU7O Qrn0wH9rHiQtgJcwwcbJxzEDsA+7qjtilYIywjlpO/ZnfDXUqaabRYAkIEy+Z9nmL/ik fDIg== Received: by 10.14.101.138 with SMTP id b10mr12810420eeg.56.1342095607158; Thu, 12 Jul 2012 05:20:07 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-217-107.as13285.net. [2.102.217.107]) by mx.google.com with ESMTPS id a16sm15194523eeg.0.2012.07.12.05.20.05 (version=SSLv3 cipher=OTHER); Thu, 12 Jul 2012 05:20:06 -0700 (PDT) Message-ID: <4FFEC100.505@gmail.com> Date: Thu, 12 Jul 2012 13:20:16 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Gert Doering References: <4FFDACB2.9080106@switch.ch> <2CFB6DD5-7BD4-4044-AB71-16DF0C28734F@cisco.com> <4FFDD2FA.4040705@umn.edu> <20120711201422.GN38127@Space.Net> <4FFE7B91.1030904@gmail.com> <20120712075524.GW38127@Space.Net> In-Reply-To: <20120712075524.GW38127@Space.Net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd: RIPE-555 fundamentaly changes the way how we can filter IPv6 & IPv4 martians? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Jul 2012 12:19:35 -0000 On 12/07/2012 08:55, Gert Doering wrote: > Hi, > > On Thu, Jul 12, 2012 at 08:24:01AM +0100, Brian E Carpenter wrote: >> On 11/07/2012 21:14, Gert Doering wrote: >>> On Wed, Jul 11, 2012 at 02:24:42PM -0500, David Farmer wrote: >>>> So as it stands no one seems to claim responsibility for routing policy >>>> other than the operators themselves. >>> Since they also have to foot the bill, that sounds somewhat reasonable >>> to me. No? >> No. It's known as the tragedy of the commons. That's where we seem to be headed, >> until something equivalent to the BGP crisis of 1993/1994 occurs for IPv6. >> As Randy said, it's a scaling issue. > > OK, I bite. So who should be able to decide what prefixes an operator > should be carrying in their routers? That's the $64B question, indeed. I agree with you about TLAs, by the way. Brian > > The IETF has demonstrated a very clear non-understanding of operational > realities out there with the "TLA" model - you can't just arbitrary decide > "*you* are big/rich/nice/... enough to be permitted to the 8192 TLA club, > and *you* are not, so go and change your business model" (which, incidently, > the IETF didn't even try, it just put out the TLA model and didn't care > for the implementation). > > The RIRs exist because their communities think they do a reasonable job, > so they should better do what their communities and paying members > want - which doesn't particularily qualify them to *set up* rules for > the DFZ either. The RIRs could be tasked to monitor the DFZ, run more > education, and chase violators - but they don't really have a reasonably > big stick to *sanction* someone who is announcing arbitrary garbage. > > The operators are the ones who have the big stick, called "not accepting > routes that they deem unsuitable" - and they are the ones who have to > give money to Fred if the scaling issue hits, so they (should) have an > interest in caring. > > Gert Doering > -- NetMaster From randy@psg.com Thu Jul 12 05:48: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 242CA21F852D for ; Thu, 12 Jul 2012 05:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TbaJfjoSPhxu for ; Thu, 12 Jul 2012 05:48:20 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id BB45721F854D for ; Thu, 12 Jul 2012 05:48:20 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SpIpB-0002B7-2d; Thu, 12 Jul 2012 12:48:53 +0000 Date: Thu, 12 Jul 2012 21:48:52 +0900 Message-ID: From: Randy Bush To: Brian E Carpenter In-Reply-To: <4FFEC0A4.2070509@gmail.com> References: <4FFDACB2.9080106@switch.ch> <2CFB6DD5-7BD4-4044-AB71-16DF0C28734F@cisco.com> <4FFDD2FA.4040705@umn.edu> <20120711201422.GN38127@Space.Net> <4FFE7B91.1030904@gmail.com> <4FFE9F4E.7080100@inex.ie> <4FFEC0A4.2070509@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: IETF v6ops list Subject: Re: [v6ops] Fwd: RIPE-555 fundamentaly changes the way how we can filter IPv6 & IPv4 martians? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Jul 2012 12:48:21 -0000 dunno about you folk, but in '92 it took us a 4000 to hold a table but this is not nanog. what are we trying to learn here? randy From nick@inex.ie Thu Jul 12 05:51: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 2C6F921F86F5 for ; Thu, 12 Jul 2012 05:51:43 -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=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AGyDIkh31qpm for ; Thu, 12 Jul 2012 05:51:42 -0700 (PDT) Received: from mail.acquirer.com (mail.acquirer.com [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 39F1121F86E5 for ; Thu, 12 Jul 2012 05:51:42 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from crumpet.local (inet-gw.acquirer.com [87.198.142.10]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id q6CCpNgJ061260 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 12 Jul 2012 13:51:23 +0100 (IST) (envelope-from nick@inex.ie) Message-ID: <4FFEC87C.7010404@inex.ie> Date: Thu, 12 Jul 2012 13:52:12 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Brian E Carpenter References: <4FFDACB2.9080106@switch.ch> <2CFB6DD5-7BD4-4044-AB71-16DF0C28734F@cisco.com> <4FFDD2FA.4040705@umn.edu> <20120711201422.GN38127@Space.Net> <4FFE7B91.1030904@gmail.com> <4FFE9F4E.7080100@inex.ie> <4FFEC0A4.2070509@gmail.com> In-Reply-To: <4FFEC0A4.2070509@gmail.com> X-Enigmail-Version: 1.4.2 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: RIPE-555 fundamentaly changes the way how we can filter IPv6 & IPv4 martians? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Jul 2012 12:51:43 -0000 On 12/07/2012 13:18, Brian E Carpenter wrote: > But only just. If the growth had continued as it was going at the start of > 1994, that would soon have been untrue. Bothe BGP4 and CIDR were needed to > allow router memory size to keep up with reality. There were several problems at the time, most of which were caused by non CIDR allocation and poor bgp3->bgp4 migration policies. I.e. people were announcing 256 x /24 instead of 1 x /16 because either their routers didn't handle CIDR properly or else because they weren't being clued in enough to manually sort out the aggregation issues. The CIDR report helped a lot in this regard. Later on, we observed a general trend towards a pretty constant level of deaggregation. The primary problem of 1993/1994 was that if the addressing allocation strategies weren't changed, it was realised that complete v4 exhaustion would have occurred within 3-4 years. The aggregation and fib size issue were secondary concerns, even though there was a brief acute problem with fib size. FIB size (+ churn) wasn't an issue then any more than it is now. By which I mean it's a constant issue in the back-ground which can generally be dealt with every several years with normal equipment upgrades. I'm not upset that my PFC3A sups aren't capable of handling 1M prefixes any more than I'm upset that my c2500 border router couldn't hold a full table after 1994. It needed to upgraded to a c4500 anyway because it was handling too much traffic for a 2500. Similarly the pfc3as needed to be upgraded to larger models because I needed mpls and netflow + more scale. No doubt, there will be a crisis in a couple of years when we reach the limits of a 1M ipv4 prefix tcam engine (an engine size which has been current since 2005 - 7 years ago), and then people will need to upgrade line cards and chassis control engines to the latest and greatest. Or we can engineer our way out of this by using clever RIB and FIB optimisation techniques. But by the time this kit becomes obsolete, we will have had 10-12 years where it was current, which a) is well beyond any reasonable depreciation write-down period and b) will have provided 10-12 years for vendors to develop engines past 1M x v4 prefix engines to lookup engines with much larger capability. Nick From slz@baycix.de Thu Jul 12 05: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 3C42D21F882B for ; Thu, 12 Jul 2012 05:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p0Y7FxniKxMM for ; Thu, 12 Jul 2012 05:59:21 -0700 (PDT) Received: from mail.g-bag.baycix.de (mail.g-bag.baycix.de [212.72.65.2]) by ietfa.amsl.com (Postfix) with ESMTP id 6ACD221F8829 for ; Thu, 12 Jul 2012 05:59:21 -0700 (PDT) Received: from andromeda.fritz.box (p5798613B.dip.t-dialin.net [87.152.97.59]) (authenticated bits=0) by mail.g-bag.baycix.de (8.13.8/8.13.3/FF-Nr13) with ESMTP id q6CCxpVx007625 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Thu, 12 Jul 2012 14:59:52 +0200 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1278) From: Sascha Lenz In-Reply-To: <4FFEC87C.7010404@inex.ie> Date: Thu, 12 Jul 2012 14:59:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <86E6E422-323F-4C94-957C-EFCC3237BE6A@baycix.de> References: <4FFDACB2.9080106@switch.ch> <2CFB6DD5-7BD4-4044-AB71-16DF0C28734F@cisco.com> <4FFDD2FA.4040705@umn.edu> <20120711201422.GN38127@Space.Net> <4FFE7B91.1030904@gmail.com> <4FFE9F4E.7080100@inex.ie> <4FFEC0A4.2070509@gmail.com> <4FFEC87C.7010404@inex.ie> To: IPv6 WG Ops X-Mailer: Apple Mail (2.1278) Subject: Re: [v6ops] Fwd: RIPE-555 fundamentaly changes the way how we can filter IPv6 & IPv4 martians? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Jul 2012 12:59:22 -0000 Hi all, [...] >=20 > No doubt, there will be a crisis in a couple of years when we reach = the > limits of a 1M ipv4 prefix tcam engine (an engine size which has been > current since 2005 - 7 years ago), and then people will need to = upgrade > line cards and chassis control engines to the latest and greatest. Or = we > can engineer our way out of this by using clever RIB and FIB = optimisation > techniques. But by the time this kit becomes obsolete, we will have = had > 10-12 years where it was current, which a) is well beyond any = reasonable > depreciation write-down period and b) will have provided 10-12 years = for > vendors to develop engines past 1M x v4 prefix engines to lookup = engines > with much larger capability. if i would be less old(-fashioned), i would say : "+1" or "Like!" about = that, i think.... --=20 Mit freundlichen Gr=FC=DFen / Kind Regards Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect From gert@space.net Thu Jul 12 06:09: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 30EB121F881E for ; Thu, 12 Jul 2012 06:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MfhJ1l0oXH9R for ; Thu, 12 Jul 2012 06:09:29 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5A7E421F8814 for ; Thu, 12 Jul 2012 06:09:28 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 04588F8C6D for ; Thu, 12 Jul 2012 15:10:01 +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 E3D31F8C68 for ; Thu, 12 Jul 2012 15:10:00 +0200 (CEST) Received: (qmail 5582 invoked by uid 1007); 12 Jul 2012 15:10:00 +0200 Date: Thu, 12 Jul 2012 15:10:00 +0200 From: Gert Doering To: Randy Bush Message-ID: <20120712131000.GC38127@Space.Net> References: <4FFDACB2.9080106@switch.ch> <2CFB6DD5-7BD4-4044-AB71-16DF0C28734F@cisco.com> <4FFDD2FA.4040705@umn.edu> <20120711201422.GN38127@Space.Net> <4FFE7B91.1030904@gmail.com> <4FFE9F4E.7080100@inex.ie> <4FFEC0A4.2070509@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.21 (2010-09-15) Cc: IETF v6ops list Subject: Re: [v6ops] Fwd: RIPE-555 fundamentaly changes the way how we can filter IPv6 & IPv4 martians? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Jul 2012 13:09:30 -0000 Hi, On Thu, Jul 12, 2012 at 09:48:52PM +0900, Randy Bush wrote: > dunno about you folk, but in '92 it took us a 4000 to hold a table We managed with a 2500 in '94, but we had far less internal routes :-) > but this is not nanog. what are we trying to learn here? What I can hear between the lines is that we're still searching for an answer to 1. who should be permitted to announce a prefix globally? 1a. and who decides these rules? 2. who controls that nothing else is announced? 3. who can sanction non-conforming behaviour? I think 2+3 can be solved by technical means *iff* enough people think there is value in controlling announcements (one option is RPKI, another option is tightly filtering downstream announcements based on IRR data, coupled with proper IRR DB security - I'm not qualified to say which is "better"). 1 + 1a are hard, and I have no answer. (And of course, this discussion has not very much to do with RIPE-555, except that some folks assumed that RIPE-510 gave useful guidance on "1", which had never been its primary purpose) 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 slz@baycix.de Thu Jul 12 06:19: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 02E3A21F8855 for ; Thu, 12 Jul 2012 06:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7YI2M7ud467N for ; Thu, 12 Jul 2012 06:19:14 -0700 (PDT) Received: from mail.g-bag.baycix.de (mail.g-bag.baycix.de [212.72.65.2]) by ietfa.amsl.com (Postfix) with ESMTP id B159C21F87D8 for ; Thu, 12 Jul 2012 06:19:13 -0700 (PDT) Received: from andromeda.fritz.box (p5798613B.dip.t-dialin.net [87.152.97.59]) (authenticated bits=0) by mail.g-bag.baycix.de (8.13.8/8.13.3/FF-Nr13) with ESMTP id q6CDJjah010790 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Thu, 12 Jul 2012 15:19:46 +0200 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1278) From: Sascha Lenz In-Reply-To: <20120712131000.GC38127@Space.Net> Date: Thu, 12 Jul 2012 15:19:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5FA1B73A-9631-4FF2-9CFF-3D0122E1CCFC@baycix.de> References: <4FFDACB2.9080106@switch.ch> <2CFB6DD5-7BD4-4044-AB71-16DF0C28734F@cisco.com> <4FFDD2FA.4040705@umn.edu> <20120711201422.GN38127@Space.Net> <4FFE7B91.1030904@gmail.com> <4FFE9F4E.7080100@inex.ie> <4FFEC0A4.2070509@gmail.com> <20120712131000.GC38127@Space.Net> To: IETF v6ops list X-Mailer: Apple Mail (2.1278) Subject: Re: [v6ops] Fwd: RIPE-555 fundamentaly changes the way how we can filter IPv6 & IPv4 martians? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Jul 2012 13:19:16 -0000 Hi all, > Hi, >=20 > On Thu, Jul 12, 2012 at 09:48:52PM +0900, Randy Bush wrote: >> dunno about you folk, but in '92 it took us a 4000 to hold a table >=20 > We managed with a 2500 in '94, but we had far less internal routes :-) >=20 >> but this is not nanog. what are we trying to learn here? >=20 > What I can hear between the lines is that we're still searching for > an answer to >=20 > 1. who should be permitted to announce a prefix globally? > 1a. and who decides these rules? > 2. who controls that nothing else is announced? > 3. who can sanction non-conforming behaviour? >=20 > I think 2+3 can be solved by technical means *iff* enough people think=20= > there is value in controlling announcements (one option is RPKI, = another=20 > option is tightly filtering downstream announcements based on IRR = data,=20 > coupled with proper IRR DB security - I'm not qualified to say which = is=20 > "better"). >=20 > 1 + 1a are hard, and I have no answer. >=20 >=20 > (And of course, this discussion has not very much to do with RIPE-555, > except that some folks assumed that RIPE-510 gave useful guidance on > "1", which had never been its primary purpose) >=20 I don't have an answer for 1+1a either, but i guess there never will be, by design of the global internet. But your last comment is the important one here: Those kind of RIR = documents, including ripe-510/555 seem to be .. "misused" (for the lack of better = wording) for a long time now. But it was inevitable that such approaches are = misguided. Time told us many times (-> reachability issues with "new" (v4-)/8s = being used nowadays etc.). RPKI-assisted filtering may be an approach for the future, for example. = But not sure about that personally (so far). =20 --=20 Mit freundlichen Gr=FC=DFen / Kind Regards Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect From diego@tid.es Thu Jul 12 06:30: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 668C021F8851 for ; Thu, 12 Jul 2012 06:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.113 X-Spam-Level: X-Spam-Status: No, score=-6.113 tagged_above=-999 required=5 tests=[AWL=0.486, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LzxMZ9OSlezk for ; Thu, 12 Jul 2012 06:30:52 -0700 (PDT) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 64B3221F883A for ; Thu, 12 Jul 2012 06:30:52 -0700 (PDT) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M7100FL0UWCLE@tid.hi.inet> for v6ops@ietf.org; Thu, 12 Jul 2012 15:31:24 +0200 (MEST) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id 40.E7.02752.CA1DEFF4; Thu, 12 Jul 2012 15:31:24 +0200 (CEST) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0M7100FKUUWCLE@tid.hi.inet> for v6ops@ietf.org; Thu, 12 Jul 2012 15:31:24 +0200 (MEST) Received: from EX10-MB1-MAD.hi.inet ([fe80::a473:4f3e:f8db:1855]) by EX10-HTCAS5-MAD.hi.inet ([::1]) with mapi id 14.02.0298.004; Thu, 12 Jul 2012 15:31:23 +0200 Date: Thu, 12 Jul 2012 13:31:23 +0000 From: "Diego R. Lopez" In-reply-to: <4FFE433A.3090707@bogus.com> X-Originating-IP: [10.95.64.115] To: joel jaeggli Message-id: Content-id: <4623BEDA6C3B4041BE0C77452BC9679A@hi.inet> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US, es-ES Thread-topic: [v6ops] Draft on DC migration to IPv6 Thread-index: AQHNUqhbgWRF7Aew1UKq7qhHvsQ1MZcK3RGAgBF/VoCAB27PAIAAVLIAgAAHSYCAAM1rAIAAqc0A X-AuditID: 0a5f4e69-b7f6d6d000000ac0-29-4ffed1ac0d8d X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNKsWRmVeSWpSXmKPExsXCFe9nqLvm4j9/g8X7FSxOH9vL7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujMmvWxkL5vBWvGlaz9LA+IGni5GTQ0LARKJ1zwFmCFtM4sK9 9WxdjFwcQgLbGSWmPXzMDOH8ZJTYOekwVGYpo8SSg03sIC0sAqoS29//YgOx2YDsR82/geIc HMICRhLfJ3mBhDkFNCXm7D3OBrFBQeLPuccsILaIgLLEn40XwDYzC7hJ/Oh4BzaSV8BSYua3 bVBxM4nXd76zQsQFJX5MvscCMp5ZQF1iypRciBJxiebWmywQtqLEtEUNjCA2o4CsxLv581lB ykUEjCWO7BOE2Boj8eXYUSaIawQkluw5D/W7qMTLx/9YIT68yiQxfVYf+wRGiVlIrpiF5IpZ CFfMQnLFLCRXLGBkXcUoVpxUlJmeUZKbmJmTbmCkl5Gpl5mXWrKJERJzmTsYl+9UOcQowMGo xMMrMe2TvxBrYllxZe4hRkkOJiVR3toL//yF+JLyUyozEosz4otKc1KLDzFKcDArifD25wLl eFMSK6tSi/JhUjIcHEoSvF9A2gSLUtNTK9Iyc4CJBSbNxMEJ0s4D1L4GpIa3uCAxtzgzHSJ/ ilFSSpyXC5iYhARAEhmleXC9rxjFgY4U5v0I0sYDTIFwXa+ABjIBDVyw9A/IwJJEhJRUA2N5 2dKdleJJd/yDFwU0znVfvfzIepeMlnitougpFRetLSLSlwabbvv459HqJU8s/v3Kjun4eGpu 1PxF66YpGM7czS3r1anw45f81xUl4r03Mh8XFr4obvMwu2Kzb5/72ZgEmWUuRncKb9xN6/l5 zHzy5hePOlnrN8bPPnjxobfb3cPfEz827PipxFKckWioxVxUnAgAG74FYD4DAAA= References: <28DC472D-01D4-4534-97A9-6AE52BE9CC58@tid.es> <4FF70D8F.5010706@bogus.com> <9E1CA4A1-8AE8-4EA0-80DD-55719A29AB17@tid.es> <4FFE433A.3090707@bogus.com> Cc: IPv6 Ops WG Subject: Re: [v6ops] Draft on DC migration to IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Jul 2012 13:30:53 -0000 DQoNCk9uIDEyIEp1bCAyMDEyLCBhdCAwNToyMyAsIGpvZWwgamFlZ2dsaSB3cm90ZToNCj4gT24g Ny8xMS8xMiA4OjA4IEFNLCBEaWVnbyBSLiBMb3BleiB3cm90ZToNCj4+IEFuZCwganVzdCBpbiBj YXNlLCBJIHBlcnNvbmFsbHkgZmluZCBtYW55IG9mIHRob3NlIGxvY2F0aW9uLWF3YXJlIHNlcnZp Y2VzIG1vcmUgYW4gYW5ub3lhbmNlIHRoYW4gYW55dGhpbmcgZWxzZTogSSBkb24ndCBzZWUgYW55 IGFkdmFudGFnZSBpbiBnZXR0aW5nIGFuIEVzdG9uaWFuIFVJIG9yIGEgc2VhcmNoIGVuZ2luZSBw cmlvcml0aXppbmcgcmVzdWx0cyBpbiBOb3J3ZWdpYW4gZm9yIG1lLg0KPiBmcmF1ZCBhbmQgYWJ1 c2UgZGV0ZWN0aW9uIGlzIGEgbGFyZ2UgYXBwbGljYXRpb24gZm9yIHNvdXJjZSBhZGRyZXNzZXMs IHVzZXIgdmlzaWJsZSBjb250ZW50IGNoYW5nZXMgYXJlIG9uZSBvZiB0aGUgbGVhc3QgaW1wb3J0 YW50IGNvbnNpZGVyYXRpb25zLg0KDQoNClJlcHV0YXRpb24gc2VydmljZXMsIGFwcGxpZWQgZm9y IGZyYXVkIGFuZCBhYnVzZSBkZXRlY3Rpb24sIGFyZSBhbm90aGVyIGtpbmQgb2YNCm1hbmFnZWQg c2VydmljZXMgdGhhdCBzb21lIG5ldHdvcmsgb3BlcmF0b3JzIG9mZmVyLg0KDQotLQ0KIkVzdGEg dmV6IG5vIGZhbGxhcmVtb3MsIERvY3RvciBJbmZpZXJubyINCg0KRHIgRGllZ28gUi4gTG9wZXoN ClRlbGVmb25pY2EgSStEDQpodHRwOi8vcGVvcGxlLnRpZC5lcy9kaWVnby5sb3Blei8NCg0KZS1t YWlsOiBkaWVnb0B0aWQuZXMNClRlbDogICAgKzM0IDkxMyAxMjkgMDQxDQpNb2JpbGU6ICszNCA2 ODIgMDUxIDA5MQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpFc3RlIG1lbnNhamUgc2UgZGly aWdlIGV4Y2x1c2l2YW1lbnRlIGEgc3UgZGVzdGluYXRhcmlvLiBQdWVkZSBjb25zdWx0YXIgbnVl c3RyYSBwb2zDrXRpY2EgZGUgZW52w61vIHkgcmVjZXBjacOzbiBkZSBjb3JyZW8gZWxlY3Ryw7Nu aWNvIGVuIGVsIGVubGFjZSBzaXR1YWRvIG3DoXMgYWJham8uDQpUaGlzIG1lc3NhZ2UgaXMgaW50 ZW5kZWQgZXhjbHVzaXZlbHkgZm9yIGl0cyBhZGRyZXNzZWUuIFdlIG9ubHkgc2VuZCBhbmQgcmVj ZWl2ZSBlbWFpbCBvbiB0aGUgYmFzaXMgb2YgdGhlIHRlcm1zIHNldCBvdXQgYXQuDQpodHRwOi8v d3d3LnRpZC5lcy9FUy9QQUdJTkFTL2Rpc2NsYWltZXIuYXNweA0K From he@uninett.no Thu Jul 12 06:42: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 C7EAC21F884F for ; Thu, 12 Jul 2012 06:42: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mLxbdF5z+f4n for ; Thu, 12 Jul 2012 06:42:08 -0700 (PDT) Received: from smistad.uninett.no (smistad.uninett.no [IPv6:2001:700:1:0:21e:4fff:feed:ced]) by ietfa.amsl.com (Postfix) with ESMTP id DE23921F8859 for ; Thu, 12 Jul 2012 06:42:07 -0700 (PDT) Received: from smistad.uninett.no (smistad.uninett.no [158.38.62.77]) by smistad.uninett.no (Postfix) with ESMTP id 62D673D0B4; Thu, 12 Jul 2012 15:42:39 +0200 (CEST) Date: Thu, 12 Jul 2012 15:42:39 +0200 (CEST) Message-Id: <20120712.154239.133898240.he@uninett.no> To: gert@space.net From: Havard Eidnes In-Reply-To: <20120712131000.GC38127@Space.Net> References: <4FFEC0A4.2070509@gmail.com> <20120712131000.GC38127@Space.Net> X-Mailer: Mew version 6.3 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: RIPE-555 fundamentaly changes the way how we can filter IPv6 & IPv4 martians? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Jul 2012 13:42:08 -0000 > What I can hear between the lines is that we're still searching for > an answer to > > 1. who should be permitted to announce a prefix globally? > 1a. and who decides these rules? > 2. who controls that nothing else is announced? > 3. who can sanction non-conforming behaviour? > > I think 2+3 can be solved by technical means *iff* enough people thin= k = > there is value in controlling announcements (one option is RPKI, anot= her = > option is tightly filtering downstream announcements based on IRR dat= a, = > coupled with proper IRR DB security - I'm not qualified to say which = is = > "better"). > > 1 + 1a are hard, and I have no answer. I'm only talking about IPv6 here... On 1, I thought at least that the practice of punching a hole in a PA allocation (announcing a longer prefix from the PA allocation from another ASN) and simultaneously that noone is announcing the covering PA prefix would at least be frowned upon, and that loss of connectivity to certain networks would be suitable treatment for such policy violations. On 1a, each operator is in the end in control of what prefixes he will allow into the routing table on his routers. It is my opinion that the removal of the publication of information by the RIRs which might make it feasible to implement a sanction against the hole-punchers-with-no-covering-prefix is ... not constructive, and not consistent with the role of the RIRs in our ecosystem. > (And of course, this discussion has not very much to do with RIPE-555= , > except that some folks assumed that RIPE-510 gave useful guidance on > "1", which had never been its primary purpose) ?!? I thought the whole point of this discussion was exactly that, and that documenting the minimum assignment sizes did indeed give some useful guidance which might be of use by a network operator. Regards, - H=E5vard From andrea@ripe.net Thu Jul 12 06:34: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 5F40021F876D for ; Thu, 12 Jul 2012 06:34:43 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YNiedUe+0v+M for ; Thu, 12 Jul 2012 06:34:42 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id 6109C21F8720 for ; Thu, 12 Jul 2012 06:34:41 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1SpJXz-0006yW-W0; Thu, 12 Jul 2012 15:35:13 +0200 Received: from s258-sslvpn-1.ripe.net ([193.0.20.231] helo=guest117.guestnet.ripe.net) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1SpJXz-0002eZ-Q7; Thu, 12 Jul 2012 15:35:11 +0200 Message-ID: <4FFED28F.3010407@ripe.net> Date: Thu, 12 Jul 2012 15:35:11 +0200 From: Andrea Cima User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Alexander Gall , Sascha Lenz References: <4FFADB8F.7040709@ripe.net> <20475.60361.476285.923710@switch.ch> <4FFC1407.2070204@ripe.net> <20476.19063.651745.927381@switch.ch> In-Reply-To: <20476.19063.651745.927381@switch.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816066, check: 20120712 clean X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 426d8c7b8120432a204ea5ce806f17310feb0e2d300ebb04ea393cadb7df1b83 Cc: ncc-services-wg@ripe.net, v6ops@ietf.org, routing-wg@ripe.net, ipv6-ops@lists.cluenet.de Subject: Re: [v6ops] [routing-wg] RIPE Document Published - ripe-555, Address Space Managed by the RIPE NCC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Jul 2012 13:50:21 -0000 [Copied ipv6-ops and v6ops mailing lists due to ongoing discussions about the same subject] Hi Alexander, On 7/10/12 5:29 PM, Alexander Gall wrote: > That's much appreciated. However, this list is missing a piece of > information that some people have been using for many years to > generate "martian/bogon"-type route filters. From the old "longest > prefix per block" list (and there is, or at least used to be such a > list for every RIR), these people (like us) generate filters for BGP > that deny all longer prefixes in such a range. I don't see how we can > infer this information from the file. For example, how do we know > exactly which IPv6 block has been set aside for IXP assignments in > order to allow more specific prefixes in it? Even if this information > is available from somwhere (though I wouldn't know where), it would be > useful to have a single place where this is recorded (and this place > used to be RIPE-510 and its predecessors). Both of IPv4 and IPv6 policies allow de-aggregation of allocations now. The requirement to announce an IPv6 allocation as one prefix only was removed from the policy in year 2009, please see: https://www.ripe.net/ripe/policies/proposals/2009-06 IPv6 Address Policy requires that IPv6 PI assignments are made from a separate address block. This is described in RIPE 555. There is no such requirement in the policies for IPv6 IXP or TLD anycast. Root server assignments are all /32 and thus presumably not the subject of any filtering (Sascha, I hope this answers your question as well). This document has been updated frequently in the past due to changes in policies and address assignment and allocation strategies, while at the same time not offering a very detailed view of the address space managed by the RIPE NCC. This version of the document is expected to change much less frequently while any loss of detailed information would be compensated by the published extended delegated statistics. We understand however that you may want to filter based on prefix lengths. The single data source for this is extended FTP stats we started publishing at ftp://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-extended-latest There you can see exactly which blocks were issued. As explained above, the changes made to RIPE 510 have the aim to increase the quality of the data provided to operators. If however there is a strong feeling in the community to include additional information in RIPE 555, we will do so. In this case however it would be better if we could collect the feedback through a single mailing list. Therefore I would suggest the NCC Services Mailing List. Best regards, Andrea Cima RIPE NCC > Section 4 also has tremendous potential for misunderstandings, given > the meaning of "longest prefix" in RIPE-510, which differs > substantially from that of the /29 and /48 mentioned in RIPE-555. > > Regards, From gert@space.net Thu Jul 12 07:23: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 06D6621F84EA for ; Thu, 12 Jul 2012 07:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cAetsK49f-4c for ; Thu, 12 Jul 2012 07:23:24 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 01E3121F84E6 for ; Thu, 12 Jul 2012 07:23:22 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 2DE78F8C6D for ; Thu, 12 Jul 2012 16:23:55 +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 16285F8C4B for ; Thu, 12 Jul 2012 16:23:55 +0200 (CEST) Received: (qmail 27711 invoked by uid 1007); 12 Jul 2012 16:23:54 +0200 Date: Thu, 12 Jul 2012 16:23:54 +0200 From: Gert Doering To: Havard Eidnes Message-ID: <20120712142354.GH38127@Space.Net> References: <4FFEC0A4.2070509@gmail.com> <20120712131000.GC38127@Space.Net> <20120712.154239.133898240.he@uninett.no> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HrV55DujqS0rXGB5" Content-Disposition: inline In-Reply-To: <20120712.154239.133898240.he@uninett.no> X-NCC-RegID: de.space X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.21 (2010-09-15) Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: RIPE-555 fundamentaly changes the way how we can filter IPv6 & IPv4 martians? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Jul 2012 14:23:25 -0000 --HrV55DujqS0rXGB5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Jul 12, 2012 at 03:42:39PM +0200, Havard Eidnes wrote: > > 1. who should be permitted to announce a prefix globally? > > 1a. and who decides these rules? > > 2. who controls that nothing else is announced? > > 3. who can sanction non-conforming behaviour? [..] > I'm only talking about IPv6 here... >=20 > On 1, I thought at least that the practice of punching a hole in > a PA allocation (announcing a longer prefix from the PA > allocation from another ASN) and simultaneously that noone is > announcing the covering PA prefix would at least be frowned upon, > and that loss of connectivity to certain networks would be > suitable treatment for such policy violations. > > On 1a, each operator is in the end in control of what prefixes he > will allow into the routing table on his routers. Which has been called the "tragedy of the commons" here... (but that's not my major point, I want to answer the next paragraph). > It is my opinion that the removal of the publication of > information by the RIRs which might make it feasible to implement > a sanction against the hole-punchers-with-no-covering-prefix is > ... not constructive, and not consistent with the role of the > RIRs in our ecosystem. Well, the RIPE NCC publishes very detailed information (in the stats file which is referenced) on what they actually gave out - so you still have the information there, in much more detailed form than before. =20 OTOH, I can understand the wish to document the ranges where "special=20 case" prefixes (not /32, and not PI either) are coming from. These have=20 not actually changed from RIPE-510 (for IPv6), and I think from the=20 discussions it seems to be clear that there is value in bringing back=20 the list. > > (And of course, this discussion has not very much to do with RIPE-555, > > except that some folks assumed that RIPE-510 gave useful guidance on > > "1", which had never been its primary purpose) >=20 > ?!? >=20 > I thought the whole point of this discussion was exactly that, > and that documenting the minimum assignment sizes did indeed give > some useful guidance which might be of use by a network operator. OK, you have a point here - my choice of words was a bit unlucky. I still think that people are reading too much into the change from 510 to 555, as the document never had the authority to tell people "this is=20 a good prefix and this is a bad prefix" (which I intended to say with the reference to "1" above). It *did* give guidance on whether something small you see in your BGP tables was likely given out as part of a larger aggregate, or "as is", so you could use it to filter "bad deaggregates". OTOH, the assumption that a deaggregate must have a covering prefix "or it's your own fault" just doesn't hold true for IPv6, given that people used to have multiple IPv4 allocations to be used for=20 "different networks", and in IPv6, they just have one (because it's big enough) but still have to number "different networks" from it - and depending on their network structure, there might not be any sort of interconnection, so announcing the aggregate is not necessarily useful. (It has been said that "one routing table slot is one routing table slot", and entities that operate multiple non-connected networks should just get multiple blocks from their corresponding RIR - indeed that makes filtering according to size easier, but we've not yet been able to form a policy in the RIPE region that permits handing out an extra allocation while the first one is not full yet...) 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 --HrV55DujqS0rXGB5 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iQCVAwUBT/7d+qkuBuNlUUl1AQLHnAQAxVLNsiIdcrcsIqKWM4BCTo9kY1+Vx3js 4YUL8GXrNigNYpVkpXMRUXskFk1Jk5fyq2mHNRx9Su7Hq83T8gAIyRLFzhARLB2u SiGlNMRk/yqOF47GAYgBI/ZJl4xz3XkawN00+SpHG/N0zTv8IbevyRv3wYOi/7Ol lFryptUImFI= =FS9T -----END PGP SIGNATURE----- --HrV55DujqS0rXGB5-- From bs7652@att.com Thu Jul 12 07:29: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 3205521F8773 for ; Thu, 12 Jul 2012 07:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kg7KXdy0v3mN for ; Thu, 12 Jul 2012 07:29:50 -0700 (PDT) Received: from nbfkord-smmo03.seg.att.com (nbfkord-smmo03.seg.att.com [209.65.160.84]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4E721F8726 for ; Thu, 12 Jul 2012 07:29:49 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo03.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id d7fdeff4.0.1160798.00-467.3194405.nbfkord-smmo03.seg.att.com (envelope-from ); Thu, 12 Jul 2012 14:30:23 +0000 (UTC) X-MXL-Hash: 4ffedf7f37d42315-5a044e11e46e73adbd58f651a66502d91f123a1a Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q6CEUJl1031094; Thu, 12 Jul 2012 10:30:21 -0400 Received: from sflint03.pst.cso.att.com (sflint03.pst.cso.att.com [144.154.234.230]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q6CETWUS029788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Jul 2012 10:30:15 -0400 Received: from GAALPA1MSGHUB9D.ITServices.sbc.com (gaalpa1msghub9d.itservices.sbc.com [130.8.36.90]) by sflint03.pst.cso.att.com (RSA Interceptor); Thu, 12 Jul 2012 10:28:01 -0400 Received: from GAALPA1MSGUSR9N.ITServices.sbc.com ([130.8.36.71]) by GAALPA1MSGHUB9D.ITServices.sbc.com ([130.8.36.90]) with mapi id 14.02.0298.004; Thu, 12 Jul 2012 10:28:00 -0400 From: "STARK, BARBARA H" To: Gert Doering , Randy Bush Thread-Topic: [v6ops] Fwd: RIPE-555 fundamentaly changes the way how we can filter IPv6 & IPv4 martians? Thread-Index: Ac1gOohyKdqzLG7lQL6a1wljwyyf7Q== Date: Thu, 12 Jul 2012 14:28:00 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61113E14E@GAALPA1MSGUSR9N.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.215.243] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=1.0 c=1 a=T24SFrVRIvAA:10 a=Zk7wwxXgrOcA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=Qs8R1XBwmid1qB] X-AnalysisOut: [FB/a8mmA==:17 a=1ibwJlUuAAAA:8 a=WVMW6XO4hvgEDojmSo4A:9 a=] X-AnalysisOut: [CjuIK1q_8ugA:10 a=Tp8CupYolQEHzSPu:21 a=XAduiYxHCkrARILK:2] X-AnalysisOut: [1] Cc: IETF v6ops list Subject: Re: [v6ops] Fwd: RIPE-555 fundamentaly changes the way how we can filter IPv6 & IPv4 martians? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Jul 2012 14:29:51 -0000 > What I can hear between the lines is that we're still searching for an an= swer > to >=20 > 1. who should be permitted to announce a prefix globally? > 1a. and who decides these rules? > 2. who controls that nothing else is announced? > 3. who can sanction non-conforming behaviour? Just to provide food for thought, in case there still exist people who aren= 't aware of this ... There are proposals for ITU (not ITU-T, specifically, but perhaps some othe= r, possibly new, ITU group) to take control of various Internet resources a= nd standards, including top level and some not-so-top-level domain name con= trol, IP address block allocation, and policy of all sorts (including addre= ss allocation policy, peering policy, and what operators must and must not = do). Policy would have teeth, because it would be dictated under terms of a= n international treaty. Policy can also include requiring adherence to BCPs= or standards. Some Internet standards creation could also be done there.=20 If you aren't aware of this activity, I recommend starting from the Interne= t Society's page on the topic: http://www.internetsociety.org/wcit=20 December 2012 in Dubai is when the ITU's WCIT meeting happens. Barbara From dburk@burkov.aha.ru Thu Jul 12 09:13: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 EFDEB21F8631 for ; Thu, 12 Jul 2012 09:13:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.362 X-Spam-Level: ** X-Spam-Status: No, score=2.362 tagged_above=-999 required=5 tests=[AWL=0.939, BAYES_00=-2.599, HELO_EQ_RU=0.595, HELO_IS_SMALL6=0.556, HOST_EQ_RU=0.875, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zDLgHmQNbCHO for ; Thu, 12 Jul 2012 09:13:44 -0700 (PDT) Received: from aha.ru (backend13.aha.ru [62.113.86.202]) by ietfa.amsl.com (Postfix) with ESMTP id 0278C21F85E3 for ; Thu, 12 Jul 2012 09:13:43 -0700 (PDT) Received: from [83.149.8.245] (account dburk@burkov.aha.ru HELO [172.18.137.173]) by backend13.aha.ru (CommuniGate Pro SMTP 4.3.11) with ESMTPSA id 306741818; Thu, 12 Jul 2012 20:14:12 +0400 References: <2D09D61DDFA73D4C884805CC7865E61113E14E@GAALPA1MSGUSR9N.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61113E14E@GAALPA1MSGUSR9N.ITServices.sbc.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <94703DC7-3E43-492E-B87E-0C4E4B476BC1@burkov.aha.ru> X-Mailer: iPhone Mail (9B206) From: Dmitry Burkov Date: Thu, 12 Jul 2012 20:12:20 +0400 To: "STARK, BARBARA H" Cc: IETF v6ops list Subject: Re: [v6ops] Fwd: RIPE-555 fundamentaly changes the way how we can filter IPv6 & IPv4 martians? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Jul 2012 16:13:45 -0000 Barbara, could I ask you to be concrete. If you know concrete proposals - please, pro= vide links. Regards, Dmitry Sent from my iPhone On 12.07.2012, at 18:28, "STARK, BARBARA H" wrote: >> What I can hear between the lines is that we're still searching for an an= swer >> to >>=20 >> 1. who should be permitted to announce a prefix globally? >> 1a. and who decides these rules? >> 2. who controls that nothing else is announced? >> 3. who can sanction non-conforming behaviour? >=20 > Just to provide food for thought, in case there still exist people who are= n't aware of this ... >=20 > There are proposals for ITU (not ITU-T, specifically, but perhaps some oth= er, possibly new, ITU group) to take control of various Internet resources a= nd standards, including top level and some not-so-top-level domain name cont= rol, IP address block allocation, and policy of all sorts (including address= allocation policy, peering policy, and what operators must and must not do)= . Policy would have teeth, because it would be dictated under terms of an in= ternational treaty. Policy can also include requiring adherence to BCPs or s= tandards. Some Internet standards creation could also be done there.=20 >=20 > If you aren't aware of this activity, I recommend starting from the Intern= et Society's page on the topic: http://www.internetsociety.org/wcit=20 >=20 > December 2012 in Dubai is when the ITU's WCIT meeting happens. >=20 > > Barbara > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From brian.e.carpenter@gmail.com Thu Jul 12 09:44: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 10F6611E8091 for ; Thu, 12 Jul 2012 09:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.654 X-Spam-Level: X-Spam-Status: No, score=-100.654 tagged_above=-999 required=5 tests=[AWL=-0.203, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cS3Q3wH7JrNv for ; Thu, 12 Jul 2012 09:44:49 -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 AFBAD11E8085 for ; Thu, 12 Jul 2012 09:44:48 -0700 (PDT) Received: by eaaq13 with SMTP id q13so905804eaa.31 for ; Thu, 12 Jul 2012 09:45: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:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=EZMiWgYSOm0Ei1CxVNUFPXUx7w2NxqBGmuKiv2Ve54Q=; b=scnwqmWR/NbD28qutGweSa/b3lqnNg1sEeFlCTrBX0G2hpXgFasmfApxPprXU96/7N KFrEVeKZfegDiVyS+nVjWAfD7zM+yN2LFaawX+dfHtcMpmTWpoXp074fulWezURo61H2 GE6liMSHUN/ZSMwy60pVdlOpX7Np7JFsQknlxSPsSWi5M4vW4h5ijhFTc2/zAeikuaLZ v5ZjWZLeu6FU3dnpF1Hbq79u3SldY2Uy8uK65XGuGD2fDWIlqV5MA5d8eeCixvcp/eXv E26wFVFsQsomjf4K2rqoihWUrejAAbsdmZBJ7tuSNhvmKMNxIKvbiPZPTnW7Fb02RcTw 2BuQ== Received: by 10.14.98.77 with SMTP id u53mr13251964eef.185.1342111521665; Thu, 12 Jul 2012 09:45:21 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-217-107.as13285.net. [2.102.217.107]) by mx.google.com with ESMTPS id u14sm17285426eem.4.2012.07.12.09.45.18 (version=SSLv3 cipher=OTHER); Thu, 12 Jul 2012 09:45:19 -0700 (PDT) Message-ID: <4FFEFF2A.6080600@gmail.com> Date: Thu, 12 Jul 2012 17:45:30 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Randy Bush References: <28DC472D-01D4-4534-97A9-6AE52BE9CC58@tid.es> <4FF70D8F.5010706@bogus.com> <4FFDB38F.3080206@bogus.com> <4FFE79DA.3010408@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] Draft on DC migration to IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Jul 2012 16:44:50 -0000 On 12/07/2012 09:38, Randy Bush wrote: >> Consider that this is also a massive problem created by the deployment >> of NAT444 brought about by CGNs. IPv6 can only win here, as it offers a >> long-term solution. But it seems clear to me that in the short term, IPv6 >> wins if we advocate full dual stack for DCs, because that maximizes the number >> of cases in which we have end to end addressing and therefore have useable >> geolocation. >> >> Full IPv6 in datacenter is the ultimate goal. However, the datacenter >> supporting IPv6 is not only network supporting, but also application >> layer supporting. Supporting IPv6 is a huge cost for the existing IPv4 >> only datacenter and some small ICPs. Currently, the IPv6 traffic and >> users are only a small part. Forcing the datacenter to fully support >> IPv6 is not a good choice at the beginning of IPv6 migration, and it >> may even impact the evolution of IPv6. It may be a good way to let >> current IPv4 only datacenter support IPv6 with small change. Through >> this way, it can promote the growth of IPv6 traffic. >> >> Cathy > > i am having problems reconciling these two paragraphs. That is because I wrote the first one, and Cathy wrote the second, but her mail software did not mark up the text accordingly. I think the problem is that the "level 1" phase advocated by the draft is pretty broken, and geolocation is one of the damaged pieces. Brian From bs7652@att.com Thu Jul 12 09:51: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 EC86E21F877B for ; Thu, 12 Jul 2012 09:51:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qr5aTjbk1yIG for ; Thu, 12 Jul 2012 09:51:06 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 96B7E21F8678 for ; Thu, 12 Jul 2012 09:51:06 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.11.0-10) with ESMTP id c900fff4.51003940.2156473.00-507.5871516.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 12 Jul 2012 16:51:40 +0000 (UTC) X-MXL-Hash: 4fff009c18ab40ad-7c60ad76d10bd5407a9a18b005020ca915ac57c0 Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id 6900fff4.0.2156435.00-381.5871417.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 12 Jul 2012 16:51:37 +0000 (UTC) X-MXL-Hash: 4fff00992752e4a2-b7b23047128b1cad0635a55d93d203c7532c3c9b Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q6CGpXOt029105; Thu, 12 Jul 2012 12:51:34 -0400 Received: from sflint04.pst.cso.att.com (sflint04.pst.cso.att.com [144.154.234.231]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q6CGpFUQ028575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Jul 2012 12:51:28 -0400 Received: from GAALPA1MSGHUB9C.ITServices.sbc.com (gaalpa1msghub9c.itservices.sbc.com [130.8.36.89]) by sflint04.pst.cso.att.com (RSA Interceptor); Thu, 12 Jul 2012 12:50:18 -0400 Received: from GAALPA1MSGUSR9N.ITServices.sbc.com ([130.8.36.71]) by GAALPA1MSGHUB9C.ITServices.sbc.com ([130.8.36.89]) with mapi id 14.02.0298.004; Thu, 12 Jul 2012 12:50:17 -0400 From: "STARK, BARBARA H" To: Dmitry Burkov Thread-Topic: [v6ops] Fwd: RIPE-555 fundamentaly changes the way how we can filter IPv6 & IPv4 martians? Thread-Index: Ac1gOohyKdqzLG7lQL6a1wljwyyf7QAMBusAAAfAAYA= Date: Thu, 12 Jul 2012 16:50:16 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61113F2C7@GAALPA1MSGUSR9N.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E61113E14E@GAALPA1MSGUSR9N.ITServices.sbc.com> <94703DC7-3E43-492E-B87E-0C4E4B476BC1@burkov.aha.ru> In-Reply-To: <94703DC7-3E43-492E-B87E-0C4E4B476BC1@burkov.aha.ru> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.215.243] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=1.0 c=1 a=T24SFrVRIvAA:10 a=Zk7wwxXgrOcA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=Qs8R1XBwmid1qB] X-AnalysisOut: [FB/a8mmA==:17 a=hZG83p_yAAAA:8 a=1ibwJlUuAAAA:8 a=N8Gt_XnZ] X-AnalysisOut: [AAAA:8 a=zQP7CpKOAAAA:8 a=48vgC7mUAAAA:8 a=bPcw9bK5U56_i6H] X-AnalysisOut: [v0OIA:9 a=CjuIK1q_8ugA:10 a=Hz7IrDYlS0cA:10 a=lZB815dzVvQA] X-AnalysisOut: [:10 a=dWcdUDVHYh5i02li:21 a=1b7zmmDSM90kz8CR:21] Cc: IETF v6ops list Subject: Re: [v6ops] Fwd: RIPE-555 fundamentaly changes the way how we can filter IPv6 & IPv4 martians? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Jul 2012 16:51:08 -0000 It is very difficult to get concrete information. This is all being managed= by the ITU (from the top, the Council, and not ITU-T), and to truly get de= tails, you must be granted access to ITU content. See http://www.itu.int/council/groups/cwg-wcit12/ for info related to ITU p= reparations for their WCIT 2012 conference. ITU had a meeting just a few weeks ago, and there are links on the above pa= ge to the contributions and documents of that meeting. But to access any of= that, you need a login. I provided the Internet Society (ISOC) link: http://www.internetsociety.org= /wcit. ISOC has been trying to educate non-ITU members as best they can, an= d to get people to be engaged via their country and country representatives= . You may want to contact ISOC to see what you can get from them. ISOC does= have membership in ITU that allows them to participate in the ITU activiti= es. You can also do a search on "WCIT 2012" to see what is available on the Int= ernet about these activities. Add words to that search string if there are = specific elements you want to research. Barbara > -----Original Message----- > From: Dmitry Burkov [mailto:dburk@burkov.aha.ru] > Sent: Thursday, July 12, 2012 12:12 PM > To: STARK, BARBARA H > Cc: Gert Doering; Randy Bush; IETF v6ops list > Subject: Re: [v6ops] Fwd: RIPE-555 fundamentaly changes the way how we > can filter IPv6 & IPv4 martians? >=20 > Barbara, > could I ask you to be concrete. If you know concrete proposals - please, > provide links. >=20 > Regards, > Dmitry >=20 > Sent from my iPhone >=20 > On 12.07.2012, at 18:28, "STARK, BARBARA H" wrote: >=20 > >> What I can hear between the lines is that we're still searching for > >> an answer to > >> > >> 1. who should be permitted to announce a prefix globally? > >> 1a. and who decides these rules? > >> 2. who controls that nothing else is announced? > >> 3. who can sanction non-conforming behaviour? > > > > Just to provide food for thought, in case there still exist people who = aren't > aware of this ... > > > > There are proposals for ITU (not ITU-T, specifically, but perhaps some > other, possibly new, ITU group) to take control of various Internet resou= rces > and standards, including top level and some not-so-top-level domain name > control, IP address block allocation, and policy of all sorts (including = address > allocation policy, peering policy, and what operators must and must not d= o). > Policy would have teeth, because it would be dictated under terms of an > international treaty. Policy can also include requiring adherence to BCPs= or > standards. Some Internet standards creation could also be done there. > > > > If you aren't aware of this activity, I recommend starting from the > > Internet Society's page on the topic: > > http://www.internetsociety.org/wcit > > > > December 2012 in Dubai is when the ITU's WCIT meeting happens. > > > > > just trying to disseminate info, in case people haven't heard> Barbara > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops From brian.e.carpenter@gmail.com Thu Jul 12 09: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 E5E7C21F8707 for ; Thu, 12 Jul 2012 09:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.969 X-Spam-Level: X-Spam-Status: No, score=-100.969 tagged_above=-999 required=5 tests=[AWL=0.122, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DRx6EobeD4Uu for ; Thu, 12 Jul 2012 09:55: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 EDD7C21F86FF for ; Thu, 12 Jul 2012 09:55:32 -0700 (PDT) Received: by eaaq13 with SMTP id q13so909316eaa.31 for ; Thu, 12 Jul 2012 09:56: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:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=AwbR3MM4FjWyt86aGy9yc9e073eXeRuA7sqLSIJ6hE8=; b=Shv+0vTm/zNjhLR7afP22ubOGKO0v1DuFVv+zUkXUJ5yfllXV0XI975fDlZgBcAgNP vMXOzt4j65eHlTo4bX/1qQgDW+YOf40Y4P8hpTBkMIjEqTG9fgsdC0zQlmwwi4JArmGK TIsSyBGvTEP4PCtGXENQBwr1MBykJcXXrFCzgS+pKWbsQeoRWnXJkFQzz8Zmwq6ig5Jb uWBzKrkJyGmWlt21RHoNDIofEohr8COqad0BOPQZHVBtrzDGeSb8tOMpGotD7QiNbSKe uZjGFTLKpPa6VVjYuKQyeT17IGf2OfGejwPT5OBJO5xA9+0bmm7rUpYpjpIcmAIaiY6R NXzg== Received: by 10.14.47.200 with SMTP id t48mr12689277eeb.8.1342112166086; Thu, 12 Jul 2012 09:56:06 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-217-107.as13285.net. [2.102.217.107]) by mx.google.com with ESMTPS id y54sm17295499eef.10.2012.07.12.09.56.04 (version=SSLv3 cipher=OTHER); Thu, 12 Jul 2012 09:56:05 -0700 (PDT) Message-ID: <4FFF01AF.3000502@gmail.com> Date: Thu, 12 Jul 2012 17:56:15 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Gert Doering References: <4FFEC0A4.2070509@gmail.com> <20120712131000.GC38127@Space.Net> <20120712.154239.133898240.he@uninett.no> <20120712142354.GH38127@Space.Net> In-Reply-To: <20120712142354.GH38127@Space.Net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: [v6ops] What can v6ops do? [was: RIPE-555 fundamentaly changes the way how we can filter IPv6 & IPv4 martians?] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Jul 2012 16:55:34 -0000 So, I'm wondering what v6ops (or some other IETF WG) can do to increase the technical incentives to aggregate IPv6 prefixes, and decrease the incentives to disaggregate them. If the answer is "nothing" we might as well keep quiet. Regards Brian On 12/07/2012 15:23, Gert Doering wrote: > Hi, > > On Thu, Jul 12, 2012 at 03:42:39PM +0200, Havard Eidnes wrote: >>> 1. who should be permitted to announce a prefix globally? >>> 1a. and who decides these rules? >>> 2. who controls that nothing else is announced? >>> 3. who can sanction non-conforming behaviour? > [..] >> I'm only talking about IPv6 here... >> >> On 1, I thought at least that the practice of punching a hole in >> a PA allocation (announcing a longer prefix from the PA >> allocation from another ASN) and simultaneously that noone is >> announcing the covering PA prefix would at least be frowned upon, >> and that loss of connectivity to certain networks would be >> suitable treatment for such policy violations. >> >> On 1a, each operator is in the end in control of what prefixes he >> will allow into the routing table on his routers. > > Which has been called the "tragedy of the commons" here... (but that's > not my major point, I want to answer the next paragraph). > >> It is my opinion that the removal of the publication of >> information by the RIRs which might make it feasible to implement >> a sanction against the hole-punchers-with-no-covering-prefix is >> ... not constructive, and not consistent with the role of the >> RIRs in our ecosystem. > > Well, the RIPE NCC publishes very detailed information (in the stats > file which is referenced) on what they actually gave out - so you > still have the information there, in much more detailed form than > before. > > OTOH, I can understand the wish to document the ranges where "special > case" prefixes (not /32, and not PI either) are coming from. These have > not actually changed from RIPE-510 (for IPv6), and I think from the > discussions it seems to be clear that there is value in bringing back > the list. > > >>> (And of course, this discussion has not very much to do with RIPE-555, >>> except that some folks assumed that RIPE-510 gave useful guidance on >>> "1", which had never been its primary purpose) >> ?!? >> >> I thought the whole point of this discussion was exactly that, >> and that documenting the minimum assignment sizes did indeed give >> some useful guidance which might be of use by a network operator. > > OK, you have a point here - my choice of words was a bit unlucky. > > I still think that people are reading too much into the change from 510 > to 555, as the document never had the authority to tell people "this is > a good prefix and this is a bad prefix" (which I intended to say with > the reference to "1" above). > > It *did* give guidance on whether something small you see in your BGP tables > was likely given out as part of a larger aggregate, or "as is", so you > could use it to filter "bad deaggregates". > > OTOH, the assumption that a deaggregate must have a covering prefix > "or it's your own fault" just doesn't hold true for IPv6, given that > people used to have multiple IPv4 allocations to be used for > "different networks", and in IPv6, they just have one (because it's > big enough) but still have to number "different networks" from it - and > depending on their network structure, there might not be any sort of > interconnection, so announcing the aggregate is not necessarily useful. > > (It has been said that "one routing table slot is one routing table slot", > and entities that operate multiple non-connected networks should just get > multiple blocks from their corresponding RIR - indeed that makes filtering > according to size easier, but we've not yet been able to form a policy > in the RIPE region that permits handing out an extra allocation while > the first one is not full yet...) > > Gert Doering > -- NetMaster > From dburk@burkov.aha.ru Thu Jul 12 10:19: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 0E31821F86A1 for ; Thu, 12 Jul 2012 10:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.027 X-Spam-Level: X-Spam-Status: No, score=0.027 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_RU=0.595, HELO_IS_SMALL6=0.556, HOST_EQ_RU=0.875, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3oRM-GN8HIdx for ; Thu, 12 Jul 2012 10:19:42 -0700 (PDT) Received: from aha.ru (backend13.aha.ru [62.113.86.202]) by ietfa.amsl.com (Postfix) with ESMTP id B4A5521F870B for ; Thu, 12 Jul 2012 10:19:41 -0700 (PDT) Received: from [91.76.224.125] (account dburk@burkov.aha.ru HELO [192.168.1.5]) by backend13.aha.ru (CommuniGate Pro SMTP 4.3.11) with ESMTPSA id 306750670; Thu, 12 Jul 2012 21:20:14 +0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Dmitry Burkov In-Reply-To: <2D09D61DDFA73D4C884805CC7865E61113F2C7@GAALPA1MSGUSR9N.ITServices.sbc.com> Date: Thu, 12 Jul 2012 21:20:13 +0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2D09D61DDFA73D4C884805CC7865E61113E14E@GAALPA1MSGUSR9N.ITServices.sbc.com> <94703DC7-3E43-492E-B87E-0C4E4B476BC1@burkov.aha.ru> <2D09D61DDFA73D4C884805CC7865E61113F2C7@GAALPA1MSGUSR9N.ITServices.sbc.com> To: "STARK, BARBARA H" X-Mailer: Apple Mail (2.1278) Cc: IETF v6ops list Subject: Re: [v6ops] Fwd: RIPE-555 fundamentaly changes the way how we can filter IPv6 & IPv4 martians? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Jul 2012 17:19:43 -0000 I highly recommend you to use original sources - not interpretations, Dmitry On Jul 12, 2012, at 8:50 PM, STARK, BARBARA H wrote: > It is very difficult to get concrete information. This is all being = managed by the ITU (from the top, the Council, and not ITU-T), and to = truly get details, you must be granted access to ITU content. > See http://www.itu.int/council/groups/cwg-wcit12/ for info related to = ITU preparations for their WCIT 2012 conference. > ITU had a meeting just a few weeks ago, and there are links on the = above page to the contributions and documents of that meeting. But to = access any of that, you need a login. >=20 > I provided the Internet Society (ISOC) link: = http://www.internetsociety.org/wcit. ISOC has been trying to educate = non-ITU members as best they can, and to get people to be engaged via = their country and country representatives. You may want to contact ISOC = to see what you can get from them. ISOC does have membership in ITU that = allows them to participate in the ITU activities. >=20 > You can also do a search on "WCIT 2012" to see what is available on = the Internet about these activities. Add words to that search string if = there are specific elements you want to research. > Barbara >=20 >> -----Original Message----- >> From: Dmitry Burkov [mailto:dburk@burkov.aha.ru] >> Sent: Thursday, July 12, 2012 12:12 PM >> To: STARK, BARBARA H >> Cc: Gert Doering; Randy Bush; IETF v6ops list >> Subject: Re: [v6ops] Fwd: RIPE-555 fundamentaly changes the way how = we >> can filter IPv6 & IPv4 martians? >>=20 >> Barbara, >> could I ask you to be concrete. If you know concrete proposals - = please, >> provide links. >>=20 >> Regards, >> Dmitry >>=20 >> Sent from my iPhone >>=20 >> On 12.07.2012, at 18:28, "STARK, BARBARA H" wrote: >>=20 >>>> What I can hear between the lines is that we're still searching for >>>> an answer to >>>>=20 >>>> 1. who should be permitted to announce a prefix globally? >>>> 1a. and who decides these rules? >>>> 2. who controls that nothing else is announced? >>>> 3. who can sanction non-conforming behaviour? >>>=20 >>> Just to provide food for thought, in case there still exist people = who aren't >> aware of this ... >>>=20 >>> There are proposals for ITU (not ITU-T, specifically, but perhaps = some >> other, possibly new, ITU group) to take control of various Internet = resources >> and standards, including top level and some not-so-top-level domain = name >> control, IP address block allocation, and policy of all sorts = (including address >> allocation policy, peering policy, and what operators must and must = not do). >> Policy would have teeth, because it would be dictated under terms of = an >> international treaty. Policy can also include requiring adherence to = BCPs or >> standards. Some Internet standards creation could also be done there. >>>=20 >>> If you aren't aware of this activity, I recommend starting from the >>> Internet Society's page on the topic: >>> http://www.internetsociety.org/wcit >>>=20 >>> December 2012 in Dubai is when the ITU's WCIT meeting happens. >>>=20 >>> >> just trying to disseminate info, in case people haven't heard> = Barbara >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops From gert@space.net Thu Jul 12 10:57: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 07AD621F861C for ; Thu, 12 Jul 2012 10:57:10 -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=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kmTHqq-bH--6 for ; Thu, 12 Jul 2012 10:57:09 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id CAC8421F85AD for ; Thu, 12 Jul 2012 10:57:02 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 2C433F8C5B for ; Thu, 12 Jul 2012 19:57:35 +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 0EC10F8C5E for ; Thu, 12 Jul 2012 19:57:35 +0200 (CEST) Received: (qmail 87988 invoked by uid 1007); 12 Jul 2012 19:57:34 +0200 Date: Thu, 12 Jul 2012 19:57:34 +0200 From: Gert Doering To: Brian E Carpenter Message-ID: <20120712175734.GM38127@Space.Net> References: <4FFEC0A4.2070509@gmail.com> <20120712131000.GC38127@Space.Net> <20120712.154239.133898240.he@uninett.no> <20120712142354.GH38127@Space.Net> <4FFF01AF.3000502@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="T0Q6x799hJWgQ1sc" Content-Disposition: inline In-Reply-To: <4FFF01AF.3000502@gmail.com> X-NCC-RegID: de.space X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.21 (2010-09-15) Cc: v6ops@ietf.org Subject: Re: [v6ops] What can v6ops do? [was: RIPE-555 fundamentaly changes the way how we can filter IPv6 & IPv4 martians?] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Jul 2012 17:57:10 -0000 --T0Q6x799hJWgQ1sc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Jul 12, 2012 at 05:56:15PM +0100, Brian E Carpenter wrote: > So, I'm wondering what v6ops (or some other IETF WG) can do > to increase the technical incentives to aggregate IPv6 prefixes, > and decrease the incentives to disaggregate them. >=20 > If the answer is "nothing" we might as well keep quiet. I see a few reasons for deaggregation (as in "there are more-specific routes out of a single block given out by a RIR"), and have a few ideas=20 what could be done: - operator mistake -> easy cure: upstream filtering tricky bit: get all upstreams to agree that this is useful to have -> marketing / name&shame effort...? -> different fix: RPKI, so networks "further away" can see this is unintended, without having to maintain potentially=20 - "protects me against hijack" - we've not seen this in IPv6, and I don't seriously expect that argument when we're talking about 65536 /48s in a /32. - multiple distinct networks that are not connected -> naive cure: relax allocation policy to permit multiple allocations for distinct networks - ARIN has this, RIPE does not, no idea about the others. Doesn't change the number of routes out there, but permits "filtering according to RIR allocations" - traffic engineering reasons -> in many cases this can be done by announcing the more-specifics with limited reach - but as far as I understand, the IETF work on BGP extentions to limit prefix propagation died? Additionally, there should always be an aggregate, so filtering these further away is "harmless" - customer-multihoming out of upstream PA space ("hole punching") -> this is a tricky one. =20 naive cure: make them use PI, so it's not a deaggregate - nothing achieved in regards to scaling or routing table slots,= =20 but "filtering according to RIR allocations works!" real cure: provide multihoming solution with multiple upstream=20 networks that works *better* than end-site-with-PI, at=20 lower cost. So - what can IETF do? - make "multihoming with dual-/48" *work*, so one of the incentives for end-site multihoming with a globally visible route goes away - educate, to avoid "needless" deaggregation (mistakes, local TE) (I'm sure I have missed a few things, so please add to the lists) 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 --T0Q6x799hJWgQ1sc Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iQCVAwUBT/8QDqkuBuNlUUl1AQJWSQQAhDDuJ/S7BB6Q9r5YhPje/DF9Q1sc9v82 v4IU5EVbx62FigaApORWqgfHEwoIfxCMB6qIeLA0n1h75twFXe1VX9wlcsOOwOBm I1iwrgHRWva6cO3bLkUZ7cX9sZDYDhHgRx4nON/yHRoWnt1KA9ZscwfMn1vDCUM1 PwHYCDm/3qk= =gJJ7 -----END PGP SIGNATURE----- --T0Q6x799hJWgQ1sc-- From randy@psg.com Thu Jul 12 14:26: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 C540411E80CF for ; Thu, 12 Jul 2012 14:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 384o3sIC9h+D for ; Thu, 12 Jul 2012 14:26:54 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 6313C11E80A6 for ; Thu, 12 Jul 2012 14:26:54 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SpQv0-0003Bw-He; Thu, 12 Jul 2012 21:27:26 +0000 Date: Fri, 13 Jul 2012 06:27:25 +0900 Message-ID: From: Randy Bush To: Brian E Carpenter In-Reply-To: <4FFEFF2A.6080600@gmail.com> References: <28DC472D-01D4-4534-97A9-6AE52BE9CC58@tid.es> <4FF70D8F.5010706@bogus.com> <4FFDB38F.3080206@bogus.com> <4FFE79DA.3010408@gmail.com> <4FFEFF2A.6080600@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: IPv6 Ops WG Subject: Re: [v6ops] Draft on DC migration to IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Jul 2012 21:26:54 -0000 >> i am having problems reconciling these two paragraphs. > > That is because I wrote the first one, and Cathy wrote the second, > but her mail software did not mark up the text accordingly. oh . could people *please* learn how to configure their mail user agents? randy From tjc@ecs.soton.ac.uk Thu Jul 12 14:38: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 D030F11E80D2 for ; Thu, 12 Jul 2012 14:38: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.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0CcrTqo1MXrp for ; Thu, 12 Jul 2012 14:38:29 -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 F2B1611E80A6 for ; Thu, 12 Jul 2012 14:38:28 -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 q6CLd0ML000851 for ; Thu, 12 Jul 2012 22:39:00 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk q6CLd0ML000851 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1342129140; bh=B/3MmtPrbvPqT8Kl9Yi8MZ+hBEU=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=WIe3Ji9Gl4+OfCLRhCu4MtlJ+gdcjg/MupwUTpeUf4eFPnvaA+VLfs6GxB3wvTwQ7 eA+Q9iIOVLvEINu6OV2ZTDCA3SBrMOHlLfjdipSqi9ztExFB3kF7k+nYHDa6nzJ6tH D0EGrqxQN6a437ORXA26KfWNxGx1P8PKw/F4G9lk= 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 id o6BMd01397511775zK ret-id none; Thu, 12 Jul 2012 22:39:00 +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 q6CLcYwE005847 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 12 Jul 2012 22:38:34 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1278) From: Tim Chown In-Reply-To: <20120712175734.GM38127@Space.Net> Date: Thu, 12 Jul 2012 22:38:33 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <4FFEC0A4.2070509@gmail.com> <20120712131000.GC38127@Space.Net> <20120712.154239.133898240.he@uninett.no> <20120712142354.GH38127@Space.Net> <4FFF01AF.3000502@gmail.com> <20120712175734.GM38127@Space.Net> <2AA82FB4-F8D5-4B6E-BB07-D2AB19CE2A43@ecs.soton.ac.uk> To: IPv6 Operations X-Mailer: Apple Mail (2.1278) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=o6BMd0139751177500; tid=o6BMd01397511775zK; 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: q6CLd0ML000851 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [v6ops] What can v6ops do? [was: RIPE-555 fundamentaly changes the way how we can filter IPv6 & IPv4 martians?] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Jul 2012 21:38:30 -0000 On 12 Jul 2012, at 18:57, Gert Doering wrote: > So - what can IETF do? >=20 > - make "multihoming with dual-/48" *work*, so one of the incentives = for > end-site multihoming with a globally visible route goes away Gert, A perfect advertisement for the 6renum WG drafts, which are in need of = review: https://datatracker.ietf.org/doc/draft-ietf-6renum-enterprise https://datatracker.ietf.org/doc/draft-liu-6renum-gap-analysis https://datatracker.ietf.org/doc/draft-carpenter-6renum-static-problem You can join the renum list here: = https://www.ietf.org/mailman/listinfo/renum Tim= From diego@tid.es Thu Jul 12 14:55: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 A4FDA21F85F1 for ; Thu, 12 Jul 2012 14:55:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.141 X-Spam-Level: X-Spam-Status: No, score=-6.141 tagged_above=-999 required=5 tests=[AWL=0.458, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZYjZHrTu69vp for ; Thu, 12 Jul 2012 14:55:04 -0700 (PDT) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3FB9F21F85F0 for ; Thu, 12 Jul 2012 14:55:04 -0700 (PDT) Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M7200EKHI8PB8@tid.hi.inet> for v6ops@ietf.org; Thu, 12 Jul 2012 23:55:37 +0200 (MEST) Received: from tid (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id FD.AD.26499.9D74FFF4; Thu, 12 Jul 2012 23:55:37 +0200 (CEST) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0M7200EKCI8PB8@tid.hi.inet> for v6ops@ietf.org; Thu, 12 Jul 2012 23:55:37 +0200 (MEST) Received: from EX10-MB1-MAD.hi.inet ([fe80::a473:4f3e:f8db:1855]) by ex10-htcas3-mad.hi.inet ([::1]) with mapi id 14.02.0298.004; Thu, 12 Jul 2012 23:55:36 +0200 Date: Thu, 12 Jul 2012 21:55:36 +0000 From: "Diego R. Lopez" In-reply-to: <4FFEFF2A.6080600@gmail.com> X-Originating-IP: [10.95.64.115] To: Brian E Carpenter Message-id: Content-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US Thread-topic: [v6ops] Draft on DC migration to IPv6 Thread-index: AQHNUqhbgWRF7Aew1UKq7qhHvsQ1MZcK3RGAgBF/VoCAB27PAIAAVLIAgAAP24CAABmVgIAAuG8AgAAz8wCAAA2agIAACTaAgACIHACAAFakAA== X-AuditID: 0a5f4068-b7f206d000006783-9f-4fff47d9a1c5 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFKsWRmVeSWpSXmKPExsXCFe/ApXvT/b+/wbHvwhanj+1ldmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxvvvS9kKevgqWn5PZGtgvMPbxcjJISFgIjHvQgMLhC0mceHe erYuRi4OIYGNjBLbH71khHB+Mkpcev6AGaRKSGApo8TJGeEgNouAqsTOFcvAutmA7EfNv9m7 GDk4hAWMJL5P8gIJcwpoSly7sooVYoGCxJ9zj8HKRQSMJRq7ToPFmQVsJN60tDODtPIKWEpc PMoPETaT+Pd8KlgJr4CgxI/J91hASpgF1CWmTMmFKBGXaG69yQJhK0pMW9TACGIzAr3y/dQa JpBykE1H9gmCPCIi0MAo8eHSP0aIawQkluw5zwxhi0q8fPyPFeLbuywSR09tZJvAKDELyRmz kJwxC+GMWUjOmIXkjAWMrKsYxYqTijLTM0pyEzNz0g0M9TIy9TLzUks2MUIiLmMH4/KdKocY BTgYlXh4Fad98hdiTSwrrsw9xCjJwaQkymvt+t9fiC8pP6UyI7E4I76oNCe1+BCjBAezkgjv OnugHG9KYmVValE+TEqGg0NJglcemByEBItS01Mr0jJzgGkFJs3EwQnSzgPUfsYNpL24IDG3 ODMdIn+KUVJKnJcBpFkAJJFRmgfX+4pRHOhIYV5ukCwPMAHCdb0CGsgENHDWz38gA0sSEVJS wNh4yTdDZbJpXZrNo36v7HVKB4M5CwSOPDz9eO73VsaAIw12UjcWbTeXvL/5Mi/Lsd+1JW9c /t/9MvPgjP0C0cq6grm9wqenLnUoDOmL66tmMdKeu4Sbb1d7+LSHi++0btLr42n7VczkZLT+ NvdmpYzt/ada1l+70512ODooTnTm+qfvunPupCmxFGckGmoxFxUnAgB+1NlOPQMAAA== References: <28DC472D-01D4-4534-97A9-6AE52BE9CC58@tid.es> <4FF70D8F.5010706@bogus.com> <4FFDB38F.3080206@bogus.com> <4FFE79DA.3010408@gmail.com> <4FFEFF2A.6080600@gmail.com> Cc: IPv6 Ops WG Subject: Re: [v6ops] Draft on DC migration to IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Jul 2012 21:55:05 -0000 DQpPbiAxMiBKdWwgMjAxMiwgYXQgMTg6NDUgLCBCcmlhbiBFIENhcnBlbnRlciB3cm90ZToNCj4g VGhhdCBpcyBiZWNhdXNlIEkgd3JvdGUgdGhlIGZpcnN0IG9uZSwgYW5kIENhdGh5IHdyb3RlIHRo ZSBzZWNvbmQsDQo+IGJ1dCBoZXIgbWFpbCBzb2Z0d2FyZSBkaWQgbm90IG1hcmsgdXAgdGhlIHRl eHQgYWNjb3JkaW5nbHkuDQo+DQo+IEkgdGhpbmsgdGhlIHByb2JsZW0gaXMgdGhhdCB0aGUgImxl dmVsIDEiIHBoYXNlIGFkdm9jYXRlZCBieSB0aGUNCj4gZHJhZnQgaXMgcHJldHR5IGJyb2tlbiwg YW5kIGdlb2xvY2F0aW9uIGlzIG9uZSBvZiB0aGUgZGFtYWdlZA0KPiBwaWVjZXMuDQoNCg0KTGV0 IG1lIG5vdGUgdGhhdCBzb3VyY2UgYWRkcmVzcyBpcyBvbmx5IGxvc3QgZm9yIHRoZSBEQyBvcGVy YXRvciAoYW5kDQpnZW9sb2NhdGlvbiBqZW9wYXJkaXplZCkgb25seSBpZiBsZXZlbCAxIGlzIGFw cGxpZWQgd2l0aCBhbiBhZGRyZXNzIHRyYW5zbGF0b3INCm9mZmVyZWQgYXMgYSBtYW5hZ2VkIHNl cnZpY2UgYnkgdGhlIG5ldHdvcmsgb3BlcmF0b3IuIEFzIHRoZSB0ZXh0IHNheXMsIHlvdQ0KY2Fu IGhhdmUgdGhlIGFkZHJlc3MgdHJhbnNsYXRvciBpbiB0aGUgREMgaW5mcmFzdHJ1Y3R1cmUsIGFu ZCBpbiB0aGF0IGNhc2UNCnRoZSBEQyBvcGVyYXRvciBoYXMgdGhlIGluZm9ybWF0aW9uLg0KDQpC ZSBnb29kZSwNCg0KLS0NCiJFc3RhIHZleiBubyBmYWxsYXJlbW9zLCBEb2N0b3IgSW5maWVybm8i DQoNCkRyIERpZWdvIFIuIExvcGV6DQpUZWxlZm9uaWNhIEkrRA0KaHR0cDovL3Blb3BsZS50aWQu ZXMvZGllZ28ubG9wZXovDQoNCmUtbWFpbDogZGllZ29AdGlkLmVzDQpUZWw6ICAgICszNCA5MTMg MTI5IDA0MQ0KTW9iaWxlOiArMzQgNjgyIDA1MSAwOTENCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cg0KRXN0ZSBtZW5zYWplIHNlIGRpcmlnZSBleGNsdXNpdmFtZW50ZSBhIHN1IGRlc3RpbmF0YXJp by4gUHVlZGUgY29uc3VsdGFyIG51ZXN0cmEgcG9sw610aWNhIGRlIGVudsOtbyB5IHJlY2VwY2nD s24gZGUgY29ycmVvIGVsZWN0csOzbmljbyBlbiBlbCBlbmxhY2Ugc2l0dWFkbyBtw6FzIGFiYWpv Lg0KVGhpcyBtZXNzYWdlIGlzIGludGVuZGVkIGV4Y2x1c2l2ZWx5IGZvciBpdHMgYWRkcmVzc2Vl LiBXZSBvbmx5IHNlbmQgYW5kIHJlY2VpdmUgZW1haWwgb24gdGhlIGJhc2lzIG9mIHRoZSB0ZXJt cyBzZXQgb3V0IGF0Lg0KaHR0cDovL3d3dy50aWQuZXMvRVMvUEFHSU5BUy9kaXNjbGFpbWVyLmFz cHgNCg== From satoru.matsushima@gmail.com Thu Jul 12 19:07: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 C13EF11E8085 for ; Thu, 12 Jul 2012 19:07:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.431 X-Spam-Level: X-Spam-Status: No, score=-2.431 tagged_above=-999 required=5 tests=[AWL=-0.828, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ncGk1RKpz-RH for ; Thu, 12 Jul 2012 19:07:03 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id D11BA11E80E6 for ; Thu, 12 Jul 2012 19:07:02 -0700 (PDT) Received: by yhq56 with SMTP id 56so3546487yhq.31 for ; Thu, 12 Jul 2012 19:07:37 -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=xsn4UOlBVC17Y2RipmQBvVf5uGteSDfveWQt1hRcdn0=; b=BlwcGjpbjip3+eNAsjw4wKiYb/tmaUnqsehduKfdzrtOcZ5iZaqbgnD5/AMB7OVMrf LuQOGufqLAA1yezx8B5tqBfEWATw5LnYzgJIfTJNALCzcmV5v0g+Z5jiC+M/tcOAkYPZ xLyKPqohRd8ot5+3Vfx8+uS41/xmtdpzTyajg1KGIuT4ht2kEwL+ecGdMI6rGkrpYV5j fyaoRkBj8im7q3Qfwnycm3XfA3LzbUz/JaqnMm9/IkLBDELVBrEstq/gJXmoBz2mbbw4 D8ox4jejHvzSkxNT/aybw43G8HnQhw+FzHSKBMdTB5LE0uZYVSo4OycY/w3b3TZI6W+B dwqg== Received: by 10.66.75.162 with SMTP id d2mr1049215paw.59.1342145256811; Thu, 12 Jul 2012 19:07:36 -0700 (PDT) Received: from [10.201.80.50] ([202.45.12.141]) by mx.google.com with ESMTPS id op10sm4949811pbc.75.2012.07.12.19.07.34 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 12 Jul 2012 19:07:35 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=utf-8 From: Satoru Matsushima In-Reply-To: <4FF7077B.5050703@bogus.com> Date: Fri, 13 Jul 2012 11:07:32 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0B2FA58F71A34C199446380DA654FB07@LENOVO1E4798BB> <1DFE8BF4-885E-4F2F-AA1B-4FC1658BA688@cisco.com> <4FF7077B.5050703@bogus.com> To: Joel jaeggli X-Mailer: Apple Mail (2.1278) Cc: IPv6 Ops WG Subject: Re: [v6ops] Call for Adoption, was Re: New draft waiting for adoption: draft-chen-v6ops-nat64-experience-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Jul 2012 02:07:03 -0000 I support this adoption. This draft would be a good start point to be = gathered operator's experiences of NAT64.=20 FWIW, I think that it would be nice if the draft describes further = experiences into the draft, DNS64 operation for example. Best regards, --satoru On 2012/07/07, at 0:42, Joel jaeggli wrote: > The following message commences a 1 week call for opinions on the > adoption of draft-chen-v6ops-nat64-experience-02 >=20 > http://tools.ietf.org/html/draft-chen-v6ops-nat64-experience-02 >=20 > Friday 7/13/2012 is the deadline for this particular call. >=20 > Thank you. > joel >=20 >>> =E4=BC=81=E4=B8=9A=E6=A0=87=E5=87=86=E7=9A=84=E6=96=87=E6=9C=AC=E6=A0=BC= =E5=BC=8F=EF=BC=88=E6=A8=A1=E7=89=88=EF=BC=89 >>>=20 >>> Dear Chairs, >>>=20 >>>=20 >>>=20 >>> We have posted new draft of NAT64 experiences. >>>=20 >>> Current draft is a joined effort from four operators (China Mobile, >>> T-mobile USA, China Telecom and France Telecom) >>>=20 >>> who is actively progressing IPv6 deployment depending on the = practices. >>>=20 >>> Several experts encourage us to continue the work after their kind = review >>>=20 >>>=20 >>>=20 >>> For now, we have addressed all comments. >>>=20 >>> The draft is ready for the adoption. >>>=20 >>> The authors would like to consult your opinions and look forward = your >>> guidance. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Many thanks >>>=20 >>>=20 >>>=20 >>> Authors >>>=20 >>>=20 >>>=20 >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >>>=20 >>> A new version of I-D, draft-chen-v6ops-nat64-experience-02.txt >>>=20 >>> has been successfully submitted by Gang Chen and posted to the >>>=20 >>> IETF repository. >>>=20 >>>=20 >>>=20 >>> Filename: draft-chen-v6ops-nat64-experience >>>=20 >>> Revision: 02 >>>=20 >>> Title: NAT64 Operational Experiences >>>=20 >>> Creation date: 2012-07-04 >>>=20 >>> WG ID: Individual Submission >>>=20 >>> Number of pages: 15 >>>=20 >>> URL: =20 >>> = http://www.ietf.org/internet-drafts/draft-chen-v6ops-nat64-experience-02.t= xt >>>=20 >>> Status: =20 >>> http://datatracker.ietf.org/doc/draft-chen-v6ops-nat64-experience >>>=20 >>> Htmlized: =20 >>> http://tools.ietf.org/html/draft-chen-v6ops-nat64-experience-02 >>>=20 >>> Diff: =20 >>> = http://tools.ietf.org/rfcdiff?url2=3Ddraft-chen-v6ops-nat64-experience-02 >>>=20 >>>=20 >>>=20 >>> Abstract: >>>=20 >>> This document summarizes some stateful NAT64 deployment scenarios = and >>>=20 >>> operational experiences for NAT64-CGN and NAT64-CE. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From randy@psg.com Thu Jul 12 20:35: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 1F95D11E80E5 for ; Thu, 12 Jul 2012 20:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.28 X-Spam-Level: X-Spam-Status: No, score=-2.28 tagged_above=-999 required=5 tests=[AWL=-0.281, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJp9gm2WkCf0 for ; Thu, 12 Jul 2012 20:35:09 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id B8DF611E80B6 for ; Thu, 12 Jul 2012 20:35:09 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SpWfP-0004K8-Hi; Fri, 13 Jul 2012 03:35:43 +0000 Date: Fri, 13 Jul 2012 12:35:42 +0900 Message-ID: From: Randy Bush To: Brian E Carpenter In-Reply-To: <4FFF01AF.3000502@gmail.com> References: <4FFEC0A4.2070509@gmail.com> <20120712131000.GC38127@Space.Net> <20120712.154239.133898240.he@uninett.no> <20120712142354.GH38127@Space.Net> <4FFF01AF.3000502@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF v6ops list Subject: Re: [v6ops] What can v6ops do? [was: RIPE-555 fundamentaly changes the way how we can filter IPv6 & IPv4 martians?] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Jul 2012 03:35:10 -0000 > So, I'm wondering what v6ops (or some other IETF WG) can do to > increase the technical incentives to aggregate IPv6 prefixes, and > decrease the incentives to disaggregate them. how well has this gone with ipv4? and why do you expect ipv6 to be much different? at least the mess seems somewhat constant, see pierre francois's paper, =20 Luca Cittadini, Wolfgang M=FChlbauer, Steve Uhlig, Randy Bush, Pierre Francois, Olaf Maennel, "Evolution of Internet Address Space Deaggregation: Myths and Reality", in IEEE Journal on Selected Areas in Communications, Vol. 28, No. 8, October 2010. randy From joelja@bogus.com Thu Jul 12 21:44: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 D045611E80CF for ; Thu, 12 Jul 2012 21:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.761 X-Spam-Level: X-Spam-Status: No, score=-99.761 tagged_above=-999 required=5 tests=[AWL=-2.762, BAYES_00=-2.599, GB_SUMOF=5, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id huuNrMZkyZH4 for ; Thu, 12 Jul 2012 21:44:42 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 6063011E8095 for ; Thu, 12 Jul 2012 21:44:42 -0700 (PDT) Received: from Joels-MacBook-Pro.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 q6D4jFxa073136 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 13 Jul 2012 04:45:15 GMT (envelope-from joelja@bogus.com) Message-ID: <4FFFA7DB.9070403@bogus.com> Date: Thu, 12 Jul 2012 21:45:15 -0700 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Brian E Carpenter References: <4FFEC0A4.2070509@gmail.com> <20120712131000.GC38127@Space.Net> <20120712.154239.133898240.he@uninett.no> <20120712142354.GH38127@Space.Net> <4FFF01AF.3000502@gmail.com> In-Reply-To: <4FFF01AF.3000502@gmail.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 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]); Fri, 13 Jul 2012 04:45:16 +0000 (UTC) Cc: v6ops@ietf.org Subject: Re: [v6ops] What can v6ops do? [was: RIPE-555 fundamentaly changes the way how we can filter IPv6 & IPv4 martians?] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Jul 2012 04:44:44 -0000 On 7/12/12 09:56 , Brian E Carpenter wrote: > So, I'm wondering what v6ops (or some other IETF WG) can do > to increase the technical incentives to aggregate IPv6 prefixes, > and decrease the incentives to disaggregate them. > > If the answer is "nothing" we might as well keep quiet. Consider the previous technical incentive to aggregate, e.g. cidr. the swamp did not destroy the internet. It worked and the routing table grows more slowly than the replacement cycle for hardware necessary to carry it. Over on the social science side, The sum of individual decisions to only transitively express routes of a certain length and not longer actually works, much like flu shots the whole population doesn't have to immunized for the cure to work, just enough so that the bad actors are at the margins. jjaeggli@XX-XX-XX# show policy-options policy-statement no-small-prefixes from { route-filter 0.0.0.0/0 prefix-length-range /25-/32 reject; } The potential for bad actors in v6 might potentially result in more complex expressions of what normative behavior is. > Regards > Brian > > On 12/07/2012 15:23, Gert Doering wrote: >> Hi, >> >> On Thu, Jul 12, 2012 at 03:42:39PM +0200, Havard Eidnes wrote: >>>> 1. who should be permitted to announce a prefix globally? >>>> 1a. and who decides these rules? >>>> 2. who controls that nothing else is announced? >>>> 3. who can sanction non-conforming behaviour? >> [..] >>> I'm only talking about IPv6 here... >>> >>> On 1, I thought at least that the practice of punching a hole in >>> a PA allocation (announcing a longer prefix from the PA >>> allocation from another ASN) and simultaneously that noone is >>> announcing the covering PA prefix would at least be frowned upon, >>> and that loss of connectivity to certain networks would be >>> suitable treatment for such policy violations. >>> >>> On 1a, each operator is in the end in control of what prefixes he >>> will allow into the routing table on his routers. >> >> Which has been called the "tragedy of the commons" here... (but that's >> not my major point, I want to answer the next paragraph). >> >>> It is my opinion that the removal of the publication of >>> information by the RIRs which might make it feasible to implement >>> a sanction against the hole-punchers-with-no-covering-prefix is >>> ... not constructive, and not consistent with the role of the >>> RIRs in our ecosystem. >> >> Well, the RIPE NCC publishes very detailed information (in the stats >> file which is referenced) on what they actually gave out - so you >> still have the information there, in much more detailed form than >> before. >> >> OTOH, I can understand the wish to document the ranges where "special >> case" prefixes (not /32, and not PI either) are coming from. These have >> not actually changed from RIPE-510 (for IPv6), and I think from the >> discussions it seems to be clear that there is value in bringing back >> the list. >> >> >>>> (And of course, this discussion has not very much to do with RIPE-555, >>>> except that some folks assumed that RIPE-510 gave useful guidance on >>>> "1", which had never been its primary purpose) >>> ?!? >>> >>> I thought the whole point of this discussion was exactly that, >>> and that documenting the minimum assignment sizes did indeed give >>> some useful guidance which might be of use by a network operator. >> >> OK, you have a point here - my choice of words was a bit unlucky. >> >> I still think that people are reading too much into the change from 510 >> to 555, as the document never had the authority to tell people "this is >> a good prefix and this is a bad prefix" (which I intended to say with >> the reference to "1" above). >> >> It *did* give guidance on whether something small you see in your BGP tables >> was likely given out as part of a larger aggregate, or "as is", so you >> could use it to filter "bad deaggregates". >> >> OTOH, the assumption that a deaggregate must have a covering prefix >> "or it's your own fault" just doesn't hold true for IPv6, given that >> people used to have multiple IPv4 allocations to be used for >> "different networks", and in IPv6, they just have one (because it's >> big enough) but still have to number "different networks" from it - and >> depending on their network structure, there might not be any sort of >> interconnection, so announcing the aggregate is not necessarily useful. >> >> (It has been said that "one routing table slot is one routing table slot", >> and entities that operate multiple non-connected networks should just get >> multiple blocks from their corresponding RIR - indeed that makes filtering >> according to size easier, but we've not yet been able to form a policy >> in the RIPE region that permits handing out an extra allocation while >> the first one is not full yet...) >> >> Gert Doering >> -- NetMaster >> > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From swmike@swm.pp.se Thu Jul 12 22:51: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 D3BF421F8734 for ; Thu, 12 Jul 2012 22:51:41 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYQrJPCqqwbA for ; Thu, 12 Jul 2012 22:51:41 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 3F8DA21F8540 for ; Thu, 12 Jul 2012 22:51:40 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 8C94D9E; Fri, 13 Jul 2012 07:52:13 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 891D39C; Fri, 13 Jul 2012 07:52:13 +0200 (CEST) Date: Fri, 13 Jul 2012 07:52:13 +0200 (CEST) From: Mikael Abrahamsson To: Gert Doering In-Reply-To: <20120712175734.GM38127@Space.Net> Message-ID: References: <4FFEC0A4.2070509@gmail.com> <20120712131000.GC38127@Space.Net> <20120712.154239.133898240.he@uninett.no> <20120712142354.GH38127@Space.Net> <4FFF01AF.3000502@gmail.com> <20120712175734.GM38127@Space.Net> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: v6ops@ietf.org Subject: Re: [v6ops] What can v6ops do? [was: RIPE-555 fundamentaly changes the way how we can filter IPv6 & IPv4 martians?] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Jul 2012 05:51:42 -0000 On Thu, 12 Jul 2012, Gert Doering wrote: > - make "multihoming with dual-/48" *work*, so one of the incentives for > end-site multihoming with a globally visible route goes away Yes, please. Let's put it this way, an IPv6 Internet with 100-200k routes (in 10 years or so) would converge much quicker than a 10x higher prefix sized one. Currently state of the art routers seem to be able to program their FIB at a rate of approximately 10k entries per second, and this hasn't changed drastically the past 10-15 years. I would much rather use Moores law to converge the Internet quicker and heat less air (=lower power consumption) and spend less money (usually more table sizes = increased cost) when it comes to the core, than to continue this mess with customer PI. Also, the more end networks that speak BGP, the more chances for misconfiguration and the more global route churn we'll see. I am not really interested in my core router caring what ISP an enterprise customer on the other side of the world chose to use today as opposed to yesterday. I would also like to be able to multihome my residential household (I already have two connections into it) without using one of them to tunnel to the ISP that is my primary (which I can only do because I have a router there to tunnel to). -- Mikael Abrahamsson email: swmike@swm.pp.se From brian.e.carpenter@gmail.com Fri Jul 13 00: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 406E021F8718 for ; Fri, 13 Jul 2012 00:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.672 X-Spam-Level: X-Spam-Status: No, score=-99.672 tagged_above=-999 required=5 tests=[AWL=-1.181, BAYES_50=0.001, J_CHICKENPOX_13=0.6, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RIwTkIHYt7ph for ; Fri, 13 Jul 2012 00:29:26 -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 DE99B21F86F4 for ; Fri, 13 Jul 2012 00:29:25 -0700 (PDT) Received: by eekd4 with SMTP id d4so1017837eek.31 for ; Fri, 13 Jul 2012 00:30:00 -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=54i+xN5pk2iz8+1kbxmI93Vvd3ifO3MIL3G1A9jJyYc=; b=hvbBAL/azVogQl+4Y7CAAFAwZ1o4IWxd1TMD9ygEf/bFdhy6QtjzNkq++9fyj2+X9C qJ4NKT4YbdYQfl85puulC5scEJDGYiUh1v7U17pipvvEMsQo6VbWeTzyQmJQDjeHhy51 wElbQwC8n0lok8xyAC59EU43m3RyQlzT8ddyvxuqChH2+/StSM9L4ZCtuzTyHpsCg/RD c96xgbIt6l7M9y0lNuGksJepmPB8VOsA1yrTQPSAqc67R/LO1NzuFZe8PAJPunpzo7JA lTkCvDkZmKkpOeBE/CK5UgfQlpAmKnQpopyIZ3b7ht6ytBVzOFlVQO2rHfyiyqrx1EIk J40Q== Received: by 10.14.119.199 with SMTP id n47mr7007eeh.159.1342164600574; Fri, 13 Jul 2012 00:30:00 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-217-88.as13285.net. [2.102.217.88]) by mx.google.com with ESMTPS id z16sm22317255eef.16.2012.07.13.00.29.58 (version=SSLv3 cipher=OTHER); Fri, 13 Jul 2012 00:29:59 -0700 (PDT) Message-ID: <4FFFCE80.9010809@gmail.com> Date: Fri, 13 Jul 2012 08:30:08 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Randy Bush References: <4FFEC0A4.2070509@gmail.com> <20120712131000.GC38127@Space.Net> <20120712.154239.133898240.he@uninett.no> <20120712142354.GH38127@Space.Net> <4FFF01AF.3000502@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: IETF v6ops list Subject: Re: [v6ops] What can v6ops do? [was: RIPE-555 fundamentaly changes the way how we can filter IPv6 & IPv4 martians?] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Jul 2012 07:29:27 -0000 On 13/07/2012 04:35, Randy Bush wrote: >> So, I'm wondering what v6ops (or some other IETF WG) can do to >> increase the technical incentives to aggregate IPv6 prefixes, and >> decrease the incentives to disaggregate them. >=20 > how well has this gone with ipv4? and why do you expect ipv6 to be > much different? The only way it could be different is if we succeed in persuading sites to use multiple PA prefixes simultaneously (see Tim Chown's message and numerous attempts to find a good multihoming solution). Answering my own question, which wasn't intended to be rhetorical, I doubt if there is anything that v6ops iteself can do. > at least the mess seems somewhat constant, see pierre francois's > paper, =20 >=20 > Luca Cittadini, Wolfgang M=C3=BChlbauer, Steve Uhlig, Randy Bush, > Pierre Francois, Olaf Maennel, "Evolution of Internet Address > Space Deaggregation: Myths and Reality", in IEEE Journal on > Selected Areas in Communications, Vol. 28, No. 8, October 2010. An excellent paper (that happens to be consistent with my own CCR paper too). In fact that whole issue of JSAC is excellent. Brian From joelja@bogus.com Fri Jul 13 00:46: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 07FE721F86FC for ; Fri, 13 Jul 2012 00:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.31 X-Spam-Level: X-Spam-Status: No, score=-102.31 tagged_above=-999 required=5 tests=[AWL=0.289, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K1bjOEl8O2u3 for ; Fri, 13 Jul 2012 00:46:02 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 4F41221F8619 for ; Fri, 13 Jul 2012 00:46:02 -0700 (PDT) Received: from Joels-MacBook-Pro.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 q6D7kV0S073947 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 13 Jul 2012 07:46:32 GMT (envelope-from joelja@bogus.com) Message-ID: <4FFFD257.4060609@bogus.com> Date: Fri, 13 Jul 2012 00:46:31 -0700 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "Zhouqian (Cathy)" References: <28DC472D-01D4-4534-97A9-6AE52BE9CC58@tid.es> <4FF70D8F.5010706@bogus.com> <4FFDB38F.3080206@bogus.com> <4FFE79DA.3010408@gmail.com> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 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]); Fri, 13 Jul 2012 07:46:32 +0000 (UTC) Cc: IPv6 Ops WG Subject: Re: [v6ops] Draft on DC migration to IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Jul 2012 07:46:03 -0000 On 7/12/12 01:05 , Zhouqian (Cathy) wrote: > Full IPv6 in datacenter is the ultimate goal. However, the datacenter > supporting IPv6 is not only network supporting, but also application > layer supporting. Supporting IPv6 is a huge cost for the existing > IPv4 only datacenter and some small ICPs. You're making an assertion you'd have to support with data. > Currently, the IPv6 traffic > and users are only a small part. Forcing the datacenter to fully > support IPv6 is not a good choice at the beginning of IPv6 migration, > and it may even impact the evolution of IPv6. I've never asserted that. What I have asserted is that nat64 translation loses me the approximation of source addresses and my customers don't consider that acceptable today regardless if the source addresses are ipv4 or ipv6. > It may be a good way to > let current IPv4 only datacenter support IPv6 with small change. > Through this way, it can promote the growth of IPv6 traffic. So consider, as an operator, if your requirement were to provide the source address as you recived it, how would you do that? some (but certainly not a complete list of) possible answers are: proxy where possible, that works fine for http/s/websockets/spdy tunnel, all the way to the host if like. that can be done statelessly and it leverages the fact that your servers have ipv6 stacks and support ip-in-ip tunneling and have for more than a decade. Be selective rather than plunging towards dualstack DC, customer facing assets are only a portion of the stack that looks more like some of the further discussion in this document. > Cathy > From meng.wei2@zte.com.cn Fri Jul 13 04:35: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 5B85921F8724 for ; Fri, 13 Jul 2012 04:35:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.838 X-Spam-Level: X-Spam-Status: No, score=-101.838 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FCCkhJuD14hT for ; Fri, 13 Jul 2012 04:35:53 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 659A021F8723 for ; Fri, 13 Jul 2012 04:35:53 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 28620102519342; Fri, 13 Jul 2012 19:28:56 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 47531.102519342; Fri, 13 Jul 2012 19:36:09 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q6DBaMK3050409 for ; Fri, 13 Jul 2012 19:36:22 +0800 (GMT-8) (envelope-from meng.wei2@zte.com.cn) In-Reply-To: To: v6ops@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: meng.wei2@zte.com.cn Date: Fri, 13 Jul 2012 19:36:11 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-07-13 19:36:23, Serialize complete at 2012-07-13 19:36:23 Content-Type: multipart/alternative; boundary="=_alternative 003FC09A48257A3A_=" X-MAIL: mse01.zte.com.cn q6DBaMK3050409 Subject: [v6ops] Comment on draft-chen-v6ops-nat64-experience-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Jul 2012 11:35:54 -0000 This is a multipart message in MIME format. --=_alternative 003FC09A48257A3A_= Content-Type: text/plain; charset="US-ASCII" Hi Chen I read your draft and think that is useful. I support the adoption as WG draft. Best regards Meng -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s). If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited. If you have received this mail in error, please delete it and notify us immediately. --=_alternative 003FC09A48257A3A_= Content-Type: text/html; charset="US-ASCII"
Hi Chen

I read your draft and think that is useful.
I support the adoption as WG draft.

Best regards
Meng 


--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.
--=_alternative 003FC09A48257A3A_=-- From sarikaya2012@gmail.com Fri Jul 13 11:53: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 00B1711E80B7 for ; Fri, 13 Jul 2012 11:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.534 X-Spam-Level: X-Spam-Status: No, score=-3.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SpGGJV+F5n0G for ; Fri, 13 Jul 2012 11:53:01 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id EE46311E80B5 for ; Fri, 13 Jul 2012 11:53:00 -0700 (PDT) Received: by yhq56 with SMTP id 56so4443392yhq.31 for ; Fri, 13 Jul 2012 11:53:37 -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=YCy0jYPpfcbwbHiA0VeRCliQ3Vrly2D3FCbIfbHP67c=; b=KDHuqD3+/aSzxG1OQ2arsuj0chxvoev1bvWRJLV8u4jxPJltLPPzNGLd23yi5sn6OQ fYzhoEMnjR7qtuAI2fdFUm4EdntAEfveik0JcaVo2yWPrQCQJZFjhzgJggjZacmiiE/C C0NuCsbOUoX+6pN/E6nTMycNhwlL0zI9sHYM+YYApW5lwr0GwgvpDBS78OWOKOWa7cjP Wn2COmiGmnk9mEoCY4VmjtuIVcpasD+Uksch81lLfiviEeOOElUX0/ptHs2uMhnsyu19 eVZ17OYS08bxH0EwMXyvw+/HNmRVeH/ewaEz/U/52BgGCAyQ7I1TUcAJRF9i7J/wnbUr mFSQ== MIME-Version: 1.0 Received: by 10.50.159.135 with SMTP id xc7mr2017905igb.9.1342205617374; Fri, 13 Jul 2012 11:53:37 -0700 (PDT) Received: by 10.231.207.167 with HTTP; Fri, 13 Jul 2012 11:53:37 -0700 (PDT) In-Reply-To: References: <0B2FA58F71A34C199446380DA654FB07@LENOVO1E4798BB> <1DFE8BF4-885E-4F2F-AA1B-4FC1658BA688@cisco.com> <4FF7077B.5050703@bogus.com> Date: Fri, 13 Jul 2012 13:53:37 -0500 Message-ID: From: Behcet Sarikaya To: Satoru Matsushima Content-Type: text/plain; charset=ISO-8859-1 Cc: IPv6 Ops WG Subject: Re: [v6ops] Call for Adoption, was Re: New draft waiting for adoption: draft-chen-v6ops-nat64-experience-02 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, 13 Jul 2012 18:53:02 -0000 On Thu, Jul 12, 2012 at 9:07 PM, Satoru Matsushima wrote: > I support this adoption. This draft would be a good start point to be gathered operator's experiences of NAT64. + 1 > FWIW, I think that it would be nice if the draft describes further experiences into the draft, DNS64 operation for example. > I would like to see a discussion on multicast support. With unicast NAT64 so much deployed, don't we need multicast NAT64? Regards, Behcet From joelja@bogus.com Fri Jul 13 12:16: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 4A27321F878A for ; Fri, 13 Jul 2012 12:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.704 X-Spam-Level: X-Spam-Status: No, score=-101.704 tagged_above=-999 required=5 tests=[AWL=-0.594, BAYES_05=-1.11, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-aiLWxJblRl for ; Fri, 13 Jul 2012 12:16:06 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 430EC21F8777 for ; Fri, 13 Jul 2012 12:16:05 -0700 (PDT) Received: from Joels-MacBook-Pro.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 q6DJGejj077810 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Fri, 13 Jul 2012 19:16:41 GMT (envelope-from joelja@bogus.com) Message-ID: <50007413.2080202@bogus.com> Date: Fri, 13 Jul 2012 12:16:35 -0700 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: IPv6 Ops WG References: <0B2FA58F71A34C199446380DA654FB07@LENOVO1E4798BB> <1DFE8BF4-885E-4F2F-AA1B-4FC1658BA688@cisco.com> <4FF7077B.5050703@bogus.com> In-Reply-To: <4FF7077B.5050703@bogus.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 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]); Fri, 13 Jul 2012 19:16:41 +0000 (UTC) Subject: Re: [v6ops] Call for Adoption, was Re: New draft waiting for adoption: draft-chen-v6ops-nat64-experience-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Jul 2012 19:16:07 -0000 This document call has sort of gotten lost in the shuffle of other activity on the list... I would say that from my vantage point as an contributor and not as a wg chair that the document has some potential imho, but, It's in no way ready for last call, so acceptance or not as a wg document is basically about encouraging work on this draft. For a document titled NAT64 Operational Experiences it needs more experience the recommendations for deployment need to be simple and unambiguous. scenarios which are perilous are not recomendations section 4.1 smacks of "if we put nat64 everywhere, then nat64 will be everywhere" I would be willing given a copy of the source file to provide the authors with a set of corrections that they can use at the discretion in order to improve the readability. thanks joel On 7/6/12 08:42 , Joel jaeggli wrote: > The following message commences a 1 week call for opinions on the > adoption of draft-chen-v6ops-nat64-experience-02 > > http://tools.ietf.org/html/draft-chen-v6ops-nat64-experience-02 > > Friday 7/13/2012 is the deadline for this particular call. > > Thank you. > joel > >>> ä¼ä¸šæ ‡å‡†çš„文本格å¼ï¼ˆæ¨¡ç‰ˆï¼‰ >>> >>> Dear Chairs, >>> >>> >>> >>> We have posted new draft of NAT64 experiences. >>> >>> Current draft is a joined effort from four operators (China Mobile, >>> T-mobile USA, China Telecom and France Telecom) >>> >>> who is actively progressing IPv6 deployment depending on the practices. >>> >>> Several experts encourage us to continue the work after their kind review >>> >>> >>> >>> For now, we have addressed all comments. >>> >>> The draft is ready for the adoption. >>> >>> The authors would like to consult your opinions and look forward your >>> guidance. >>> >>> >>> >>> >>> >>> Many thanks >>> >>> >>> >>> Authors >>> >>> >>> >>> ===================================================== >>> >>> A new version of I-D, draft-chen-v6ops-nat64-experience-02.txt >>> >>> has been successfully submitted by Gang Chen and posted to the >>> >>> IETF repository. >>> >>> >>> >>> Filename: draft-chen-v6ops-nat64-experience >>> >>> Revision: 02 >>> >>> Title: NAT64 Operational Experiences >>> >>> Creation date: 2012-07-04 >>> >>> WG ID: Individual Submission >>> >>> Number of pages: 15 >>> >>> URL: >>> http://www.ietf.org/internet-drafts/draft-chen-v6ops-nat64-experience-02.txt >>> >>> Status: >>> http://datatracker.ietf.org/doc/draft-chen-v6ops-nat64-experience >>> >>> Htmlized: >>> http://tools.ietf.org/html/draft-chen-v6ops-nat64-experience-02 >>> >>> Diff: >>> http://tools.ietf.org/rfcdiff?url2=draft-chen-v6ops-nat64-experience-02 >>> >>> >>> >>> Abstract: >>> >>> This document summarizes some stateful NAT64 deployment scenarios and >>> >>> operational experiences for NAT64-CGN and NAT64-CE. >>> >>> >>> >>> >>> >> > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From Tetsuya.Murakami@ipinfusion.com Fri Jul 13 12:33: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 5378C11E80D3 for ; Fri, 13 Jul 2012 12:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.921 X-Spam-Level: X-Spam-Status: No, score=-3.921 tagged_above=-999 required=5 tests=[AWL=-0.323, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vjRvIu6QpVpL for ; Fri, 13 Jul 2012 12:33:05 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe003.messaging.microsoft.com [216.32.180.13]) by ietfa.amsl.com (Postfix) with ESMTP id AD9DD11E80C7 for ; Fri, 13 Jul 2012 12:33:05 -0700 (PDT) Received: from mail149-va3-R.bigfish.com (10.7.14.250) by VA3EHSOBE010.bigfish.com (10.7.40.12) with Microsoft SMTP Server id 14.1.225.23; Fri, 13 Jul 2012 19:33:42 +0000 Received: from mail149-va3 (localhost [127.0.0.1]) by mail149-va3-R.bigfish.com (Postfix) with ESMTP id 081C32C0459; Fri, 13 Jul 2012 19:33:42 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.244.213; KIP:(null); UIP:(null); IPV:NLI; H:CH1PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 0 X-BigFish: PS0(zzbb2dI98dIc85fh4015Izz1202hzz8275bhz2fh2a8h668h839hd25he5bhf0ah107ahbe3k) Received-SPF: pass (mail149-va3: domain of ipinfusion.com designates 157.56.244.213 as permitted sender) client-ip=157.56.244.213; envelope-from=Tetsuya.Murakami@ipinfusion.com; helo=CH1PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; Received: from mail149-va3 (localhost.localdomain [127.0.0.1]) by mail149-va3 (MessageSwitch) id 134220802190592_32583; Fri, 13 Jul 2012 19:33:41 +0000 (UTC) Received: from VA3EHSMHS013.bigfish.com (unknown [10.7.14.236]) by mail149-va3.bigfish.com (Postfix) with ESMTP id 092092A0052; Fri, 13 Jul 2012 19:33:41 +0000 (UTC) Received: from CH1PRD0510HT003.namprd05.prod.outlook.com (157.56.244.213) by VA3EHSMHS013.bigfish.com (10.7.99.23) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 13 Jul 2012 19:33:38 +0000 Received: from CH1PRD0510MB393.namprd05.prod.outlook.com ([169.254.7.238]) by CH1PRD0510HT003.namprd05.prod.outlook.com ([10.255.150.38]) with mapi id 14.16.0175.005; Fri, 13 Jul 2012 19:33:37 +0000 From: Tetsuya Murakami To: Satoru Matsushima Thread-Topic: [v6ops] Call for Adoption, was Re: New draft waiting for adoption: draft-chen-v6ops-nat64-experience-02 Thread-Index: AQHNYS5mXBIsBKfiY0CXWZ/ZCbuoxg== Date: Fri, 13 Jul 2012 19:33:37 +0000 Message-ID: <8C970C70-74EC-4771-8184-542782350742@ipinfusion.com> References: <0B2FA58F71A34C199446380DA654FB07@LENOVO1E4798BB> <1DFE8BF4-885E-4F2F-AA1B-4FC1658BA688@cisco.com> <4FF7077B.5050703@bogus.com> In-Reply-To: Accept-Language: ja-JP, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.150.4] Content-Type: multipart/alternative; boundary="_000_8C970C7074EC47718184542782350742ipinfusioncom_" MIME-Version: 1.0 X-OriginatorOrg: ipinfusion.com Cc: IPv6 Ops WG Subject: Re: [v6ops] Call for Adoption, was Re: New draft waiting for adoption: draft-chen-v6ops-nat64-experience-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Jul 2012 19:33:06 -0000 --_000_8C970C7074EC47718184542782350742ipinfusioncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On 2012/07/12, at 19:07, Satoru Matsushima wrote: I support this adoption. This draft would be a good start point to be gathe= red operator's experiences of NAT64. +1 I support for WG adoption. This draft is very useful experience for not onl= y operators but also implementation. Thanks, Tetsuya --_000_8C970C7074EC47718184542782350742ipinfusioncom_ Content-Type: text/html; charset="us-ascii" Content-ID: <27915D2C0B8BC649BF78E5913C4B4324@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
On 2012/07/12, at 19:07, Satoru Matsushima wrote:

I support this adoption. This draft would be a good start point to be = gathered operator's experiences of NAT64.

+1<= /span><= br> =
= I support for WG adoption. This draft is very useful experience for not onl= y operators but also implementation.
=
= Thanks,
= Tetsuya

--_000_8C970C7074EC47718184542782350742ipinfusioncom_-- From estrellazhang2012@gmail.com Tue Jul 10 20:10: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 0F71311E8099 for ; Tue, 10 Jul 2012 20:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.549 X-Spam-Level: X-Spam-Status: No, score=-0.549 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_32=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hh-qX5eCEPaV for ; Tue, 10 Jul 2012 20:09:59 -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 E1A7311E8079 for ; Tue, 10 Jul 2012 20:09:58 -0700 (PDT) Received: by weyu54 with SMTP id u54so223670wey.31 for ; Tue, 10 Jul 2012 20:10:27 -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:cc:content-type :content-transfer-encoding; bh=8DfZX1B+O+VbasIFeuzg6kf4mx/KNr7nODuqjtvrdyY=; b=rrPRU0Cio8jWOlaxyILayABu8wcU28dvpDWtkepmqL+AaRS3eojistO+iKbJ5lAffN Qf9ZreYTWAyzBdUis73muGEEAxNqih6KkNYZmBo9B8+n64QsxaRS9Emi5pLRz9PSuL2f Z42jQq0S2ptqa5GzaHacfEmbcgtXzrKN4kkVYHXD52kC56ua3VeMEMBGwfVthCfBk1c6 SYyiMaUZTd7PwAt5BXVuUxnjV/zcUupqz8kvKyGjc1aNMHhSN5dEgoYMVtUAhcQpHiLz V6zk9BGDaFZOLRCYnVpJOYDUTQz3d3oRTvUhmbymUs9iZUr8O0vrMcvr2f8MJX/c4m8l pKUA== MIME-Version: 1.0 Received: by 10.216.136.72 with SMTP id v50mr783997wei.203.1341976227630; Tue, 10 Jul 2012 20:10:27 -0700 (PDT) Received: by 10.216.199.167 with HTTP; Tue, 10 Jul 2012 20:10:27 -0700 (PDT) Date: Wed, 11 Jul 2012 11:10:27 +0800 Message-ID: From: Jiexin Zhang To: v6ops@ietf.org Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sat, 14 Jul 2012 08:09:13 -0700 Subject: [v6ops] "RE: goals of draft-zhang-v6ops-ipv6oa-iwf-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: Thu, 12 Jul 2012 08:03:16 -0000 Thanks for the question from J.s. There are some answers to J.s about goals of draft-zhang-v6ops-ipv6oa-iwf-00.txt " as following: - If it is simply an IPv6 router, than I believe there is no problem with connecting an ATM network to an Ethernet network. A: What we defined in the draft isn=A1=AFt an IPv6 router ,but some kind of layer 2 node, such as an ATM node with IPoA IWF function, which is still widely used in Chinatelecom ATM network. - If the "Interworking Function" is not an IP layer function, then (a) where is it defined how such an "Interworking Function" works and (b) why should the working group focusing primarily on IPv6 operational and deployment issues worry about this? A: =A3=A8a=A3=A9The IPv6oA IWF function will lie in an ATM node, just like IPo= A IWF in ATM node as in IPv4 age=A3=ACwhich will make it come true the interworking between ATM and IPv6 in an ATM node=A1=A3 =A3=A8b=A3=A9Because there are still a large scale layer 2 network in chinatelcom in the progress of IP-nalization, such as ATM network ,and SDH also. There are also many interworking demands between the layer 2 network and IP network. With the IP network fast migration to IPv6, those interworking demands are remain for the sake of investment save. Best RGDS. J.X. From cathy.zhou@huawei.com Sun Jul 15 20:40: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 1E97E21F846D for ; Sun, 15 Jul 2012 20:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.425 X-Spam-Level: X-Spam-Status: No, score=-6.425 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ngxg0vOjeQQs for ; Sun, 15 Jul 2012 20:40:02 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 630BD21F846C for ; Sun, 15 Jul 2012 20:40:02 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHU06094; Sun, 15 Jul 2012 23:40:45 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 15 Jul 2012 20:37:36 -0700 Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 15 Jul 2012 20:37:35 -0700 Received: from SZXEML527-MBX.china.huawei.com ([169.254.3.194]) by szxeml401-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Mon, 16 Jul 2012 11:37:27 +0800 From: "Zhouqian (Cathy)" To: Joel jaeggli Thread-Topic: [v6ops] Draft on DC migration to IPv6 Thread-Index: AQHNW5Grz6Airmi1OkGxTcsV2RJJE5cj2oyg///O9ACAAA/bgIAAGZWAgAC4cACAADPzAIAAkxxQgAEHjYCABPDEEA== Date: Mon, 16 Jul 2012 03:37:26 +0000 Message-ID: References: <28DC472D-01D4-4534-97A9-6AE52BE9CC58@tid.es> <4FF70D8F.5010706@bogus.com> <4FFDB38F.3080206@bogus.com> <4FFE79DA.3010408@gmail.com> <4FFFD257.4060609@bogus.com> In-Reply-To: <4FFFD257.4060609@bogus.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.77.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: IPv6 Ops WG Subject: Re: [v6ops] Draft on DC migration to IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 Jul 2012 03:40:03 -0000 Hi Joel, > -----Original Message----- > From: Joel jaeggli [mailto:joelja@bogus.com] > Sent: Friday, July 13, 2012 3:47 PM > To: Zhouqian (Cathy) > Cc: Brian E Carpenter; Qiong; IPv6 Ops WG > Subject: Re: [v6ops] Draft on DC migration to IPv6 >=20 > On 7/12/12 01:05 , Zhouqian (Cathy) wrote: >=20 > > Full IPv6 in datacenter is the ultimate goal. However, the datacenter > > supporting IPv6 is not only network supporting, but also application > > layer supporting. Supporting IPv6 is a huge cost for the existing > > IPv4 only datacenter and some small ICPs. >=20 > You're making an assertion you'd have to support with data. There are only a few ICPs supporting IPv6 in China. But China is one of the= countries=20 which most lacks IPv4 addresses. The main reason is the cost and the small = IPv6 traffic. =20 > > Currently, the IPv6 traffic > > and users are only a small part. Forcing the datacenter to fully > > support IPv6 is not a good choice at the beginning of IPv6 migration, > > and it may even impact the evolution of IPv6. >=20 > I've never asserted that. What I have asserted is that nat64 translation > loses me the approximation of source addresses and my customers don't > consider that acceptable today regardless if the source addresses are > ipv4 or ipv6. You are correct and the problem does exist in nat64 translation. But at the= first=20 stage of IPv6 datacenter transition when the client is v6 but the datacente= r is still v4,=20 this scenario is inevitable. We should think a better way to solve this. Bu= t currently=20 nat64 translation or IPv6 in IPv4 tunnel may be possible solutions. > > It may be a good way to > > let current IPv4 only datacenter support IPv6 with small change. > > Through this way, it can promote the growth of IPv6 traffic. >=20 > So consider, as an operator, if your requirement were to provide the > source address as you recived it, how would you do that? >=20 > some (but certainly not a complete list of) possible answers are: >=20 > proxy where possible, that works fine for http/s/websockets/spdy >=20 > tunnel, all the way to the host if like. that can be done statelessly > and it leverages the fact that your servers have ipv6 stacks and support > ip-in-ip tunneling and have for more than a decade. >=20 > Be selective rather than plunging towards dualstack DC, customer facing > assets are only a portion of the stack that looks more like some of the > further discussion in this document. For some IPv6 applications in IPv4 only datacenter, we could use an IPv4 he= ader=20 in the original IPv6 packet(v6 in v4 tunnel). But for some content which do= es not=20 support IPv6, translation is still needed. > > Cathy > > >=20 From jiangsheng@huawei.com Mon Jul 16 03: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 8EDF821F8671 for ; Mon, 16 Jul 2012 03:08:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.91 X-Spam-Level: X-Spam-Status: No, score=-5.91 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vKy03-guAqTO for ; Mon, 16 Jul 2012 03:08:13 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0348521F863C for ; Mon, 16 Jul 2012 03:08:08 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHU30151; Mon, 16 Jul 2012 06:08:53 -0400 (EDT) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 16 Jul 2012 03:07:08 -0700 Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 16 Jul 2012 03:07:07 -0700 Received: from szxeml545-mbx.china.huawei.com ([169.254.1.140]) by szxeml411-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Mon, 16 Jul 2012 18:07:04 +0800 From: Sheng Jiang To: "v6ops@ietf.org" Thread-Topic: New Version Notification for draft-jiang-semantic-prefix-01.txt Thread-Index: AQHNYzpDsyR2Ifepx0mAKRmDW5gqkJcrrk1g Date: Mon, 16 Jul 2012 10:07:04 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B9239EF98AE@szxeml545-mbx.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.31] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [v6ops] FW: New Version Notification for draft-jiang-semantic-prefix-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, 16 Jul 2012 10:08:14 -0000 SGksIGFsbCwNCg0KQSBuZXcgdmVyc2lvbiBkcmFmdCBkcmFmdC1qaWFuZy1zZW1hbnRpYy1wcmVm aXgsICJTZW1hbnRpYyBJUHY2IFByZWZpeCIsIGhhcyBiZWVuIHN1Ym1pdHRlZC4NCg0KVGhlIGRp c2N1c3Npb24gYW5kIGNvbW1lbnRzIGluIHY2b3BzIG1haWwgbGlzdCBoYXZlIGJlZW4gYWRkcmVz c2VkLiBBbHNvLCBlbnRlcnByaXNlIGNvbnNpZGVyYXRpb25zIGFuZCBzY2VuYXJpb3MgaXMgYWRk ZWQuIEl0IGlzIGVtcGhhc2l6ZWQgdGhhdCBzZW1hbnRpY3MgYXJlIG9ubHkgZm9yIGxvY2FsIG1l YW5pbmcsIGFuZCB0aGlzIGRvY3VtZW50IGhhcyBubyBpbnRlbmQgdG8gc3RhbmRhcmRpemUgYW55 IGNvbW1vbiBnbG9iYWwgc2VtYW50aWNzLg0KDQpBbGwgY29tbWVudHMgYXJlIHdlbGNvbWUuDQoN CkJlc3QgcmVnYXJkcywNCg0KU2hlbmcNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiBGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmddDQo+IFNlbnQ6IE1vbmRheSwgSnVseSAxNiwgMjAxMiA2OjAzIFBNDQo+IFRvOiBT aGVuZyBKaWFuZw0KPiBTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0 LWppYW5nLXNlbWFudGljLXByZWZpeC0wMS50eHQNCj4gDQo+IA0KPiBBIG5ldyB2ZXJzaW9uIG9m IEktRCwgZHJhZnQtamlhbmctc2VtYW50aWMtcHJlZml4LTAxLnR4dA0KPiBoYXMgYmVlbiBzdWNj ZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFNoZW5nIEppYW5nIGFuZCBwb3N0ZWQgdG8gdGhlDQo+IElF VEYgcmVwb3NpdG9yeS4NCj4gDQo+IEZpbGVuYW1lOgkgZHJhZnQtamlhbmctc2VtYW50aWMtcHJl Zml4DQo+IFJldmlzaW9uOgkgMDENCj4gVGl0bGU6CQkgU2VtYW50aWMgSVB2NiBQcmVmaXgNCj4g Q3JlYXRpb24gZGF0ZToJIDIwMTItMDctMTYNCj4gV0cgSUQ6CQkgSW5kaXZpZHVhbCBTdWJtaXNz aW9uDQo+IE51bWJlciBvZiBwYWdlczogMTENCj4gVVJMOg0KPiBodHRwOi8vd3d3LmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy9kcmFmdC1qaWFuZy1zZW1hbnRpYy1wcmVmaXgtMDEudHh0DQo+IFN0 YXR1czoNCj4gaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1qaWFuZy1zZW1h bnRpYy1wcmVmaXgNCj4gSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1qaWFuZy1zZW1hbnRpYy1wcmVmaXgtMDENCj4gRGlmZjoNCj4gaHR0cDovL3Rvb2xz LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1qaWFuZy1zZW1hbnRpYy1wcmVmaXgtMDENCj4g DQo+IEFic3RyYWN0Og0KPiAgICBTb21lIEludGVybmV0IFNlcnZpY2UgUHJvdmlkZXJzIGFuZCBl bnRlcnByaXNlcyBkZXNpcmUgdG8gYmUgYXdhcmUgb2YNCj4gICAgbW9yZSBpbmZvcm1hdGlvbiBh Ym91dCBlYWNoIHBhY2tldCwgc28gdGhhdCBwYWNrZXRzIGNhbiBiZSB0cmVhdGVkDQo+ICAgIGRp ZmZlcmVudGx5IGFuZCBlZmZpY2llbnRseS4gUGFja2V0LWxldmVsIGRpZmZlcmVudGlhdGluZyBj YW4gYWxzbw0KPiAgICBlbmFibGUgZmxvdy1sZXZlbCBhbmQgdXNlci1sZXZlbCBkaWZmZXJlbnRp YXRpbmcuDQo+IA0KPiAgICBJUHY2LCB3aXRoIGEgbGFyZ2UgYWRkcmVzcyBzcGFjZSwgYWxsb3dz IHNlbWFudGljcyB0byBiZSBlbWJlZGRlZA0KPiAgICBpbnRvIGFkZHJlc3Nlcy4gUm91dGVycyBj YW4gZWFzaWx5IGFwcGx5IHJlbGV2YW50IG9wZXJhdGlvbnMNCj4gICAgYWNjb3JkaW5nbHkuIFRo aXMgZG9jdW1lbnQgcHJvdmlkZXMgYW5hbHlzaXMgb24gaG93IHRvIGZvcm0gc2VtYW50aWMNCj4g ICAgcHJlZml4IGFuZCBjb3JyZXNwb25kaW5nIHVzZSBjYXNlcywgYW5kIGlkZW50aWZpZXMgdGhl IHRlY2huaWNhbA0KPiAgICByZXF1aXJlbWVudHMgdG8gbWF4aW1pemUgdGhlIGJlbmVmaXRzIG9m IHRoZSBzZW1hbnRpYyBwcmVmaXgNCj4gICAgYXBwcm9hY2guIEl0IGlzIHJlY29tbWVuZGVkIHRv IHVzZSA0fjEyIGJpdHMgaW4gcHJlZml4IGZvciBlbWJlZGRlZA0KPiAgICBzZW1hbnRpY3MuDQo+ IA0KPiAgICBUaGlzIGluZm9ybWF0aW9uYWwgZG9jdW1lbnQgb25seSBkaXNjdXNzZXMgdXNhZ2Ug b2Ygc2VtYW50aWNzIGluIGENCj4gICAgc2VtYW50aWMgcHJlZml4IGRvbWFpbi4gSXQgZG9lcyBO T1QgaW50ZW50IG9yIHN1Z2dlc3QgdG8gc3RhbmRhcmRpemUNCj4gICAgYW55IGNvbW1vbiBnbG9i YWwgc2VtYW50aWNzLg0KPiANCj4gDQo+IA0KPiANCj4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCg== From dwing@cisco.com Mon Jul 16 17:40: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 CC17911E809B for ; Mon, 16 Jul 2012 17:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.196 X-Spam-Level: X-Spam-Status: No, score=-110.196 tagged_above=-999 required=5 tests=[AWL=-0.197, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5WMliBAnh32G for ; Mon, 16 Jul 2012 17:40:55 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 96FCD11E80A5 for ; Mon, 16 Jul 2012 17:40:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=6838; q=dns/txt; s=iport; t=1342485702; x=1343695302; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=Odo+ZX8dbTv6drq2x5H7QEzvFX7bk+pzntx05gjCEzQ=; b=FDF4gvnACs22g6WcclsyQ6oeqG/DOxUQFMVy+sgD0XqlABqqwnDgoPNT C9LAOFE34xDdQ/7st7pvas8TOzT+Mq5apzwIQvhBqrADa4XaPUlLyEAiX RSwneNIqBCccfxxS3mzCV8wOLikLrTtlMU5SEpA0QNYIQw3MQfjStNlsJ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUFAGC0BFCrRDoI/2dsb2JhbAA7BAaqG487gQeCIAEBAQMBCAoBFxA9AgUHAQMCCQ4BAgQBASgHGSMKCAEIAQEEEQILF4dlBQycQqAhi0AQFoYhA4hLhQWWC4Fmgn8egRgJGg X-IronPort-AV: E=Sophos;i="4.77,598,1336348800"; d="scan'208";a="52031804" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 17 Jul 2012 00:41:41 +0000 Received: from dwingWS (sjc-vpn6-1639.cisco.com [10.21.126.103]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q6H0feeN025583; Tue, 17 Jul 2012 00:41:40 GMT From: "Dan Wing" To: "'Ray Hunter'" References: <5D36713D8A4E7348A7E10DF7437A4B9239EF7160@szxeml545-mbx.china.huawei.com> <4FFBFE58.8040408@inex.ie> <06AF4254-FAB4-496C-A894-7092451C42C0@ucd.ie> <4FFC541F.90701@umn.edu> <4FFC8738.40502@globis.net> <085f01cd5efc$cdff1bb0$69fd5310$@com> <4FFD1842.2090509@globis.net> In-Reply-To: <4FFD1842.2090509@globis.net> Date: Mon, 16 Jul 2012 17:41:39 -0700 Message-ID: <018901cd63b4$ee3dc0e0$cab942a0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac1fK45Y2ANdut0ARLGRSzGX9hi2HAEh+F0Q Content-Language: en-us Cc: v6ops@ietf.org Subject: Re: [v6ops] FW: New Version Notification for draft-jiang-semantic-prefix-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: Tue, 17 Jul 2012 00:40:57 -0000 > -----Original Message----- > From: Ray Hunter [mailto:v6ops@globis.net] > Sent: Tuesday, July 10, 2012 11:08 PM > To: Dan Wing > Cc: 'David Farmer'; v6ops@ietf.org > Subject: Re: [v6ops] FW: New Version Notification for draft-jiang- > semantic-prefix-00.txt > > You are correct Dan: this is not my finest and most portable idea, but > here's the gory details since you asked. > > Apps will eventually have to set their own QoS at the host level. But > there's no universal mechanism to do this. > > DSCP only has local significance. So if you contract 4 or 5 MPLS > providers (not unusual in a multi-sourcing strategy for a large > geographically dispersed enterprise) you are almost certain to have 4 > or > 5 different DSCP mappings with 4 or 5 different semantics. Highly > mobile > nodes & BYOD quite simply cannot cope with this, as there's no network > to end device signalling for QoS AFAIK. About the best you can hope for > out of the shrink wrap is that EF = voice. Sometimes. > > Today we map apps to DSCP based on IPv4 extended access lists + > class-maps + DSCP rewriting. That then feeds into CBWFQ + DSCP aware > WRED. Standard fare really. It's horrible to maintain but it pretty > much > works. There's a small amount of NBAR marking too, although not all > MPLS > providers support this due to the overhead. And in any case, since each > MPLS provider uses different DSCP settings you have to rewrite at the > borders. > > Firewall rules are generally specified on a per host basis. > > Add IPv6 SLAAC + temporary addresses into the mix and it's fairly > likely > that you are not going to be able to identify equipment or flows based > on IPv6 address. Since many important apps for QoS (e.g. bulk back up) > don't always run on well known port numbers, or applications re-use > well-known port numbers (everything on port 80), you've lost even that > (vague) mapping. If we can get DHCPv6 to assign IPv6 addresses based on > DUID it might happen. But up until now, support for DHCPv6 has been > pretty abysmal, so I'm not counting on that. > > It's the same story for basic access-lists and firewall security: you > can't reliably identify devices or flows any more based on IP > address+port, so you can't specify static firewall rules per end > device. > OK people might say that you can always authenticate to the firewall > and > add rules dynamically. But not all flows have human users sat behind > them. And there might easily be 2 or 3 firewalls on the path. Thanks for that detailed response. Would you be willing to write the above as an I-D for a problem statement? > All of the other mechanisms are being killed, so we're going to have to > invent new bad habits. So we figured as a last resort to try to > identify > applications and basic security classes based on LAN prefix. > > If you have a bulk back up server, connect it to a LAN for bulk > traffic. > If you have voice equipment, connect it to a voice LAN. If you have > stuff that needs inbound connectivity, connect it to an inbound DMZ > LAN. > If you have stuff that does not need inbound connectivity except from > certain management LANs, place it on a security class 1 LAN. > > The VLANs and class-map access-lists and firewall access-lists can then > be standardised throughout the whole network for all providers for all > sites [providers simply add in their own local DSCP tags]. Configs can > be auto-generated. We may even eventually able to assign highly mobile > devices to appropriate LANs based on 802.1X VLAN assignment: so the > CIO's iDevice gets connected to the VIP LAN. > > It's not like we're short of IPv6 addresses or VLAN ID's. Cisco (and our IP PBX competitors) have long suggested that enterprises put all voice devices on a separate VLAN ("voice VLAN"). This works sortof alright until you're doing WiFi (no VLANs, only separate SSIDs which you could map to separate VLANs) and completely fails with multi-use devices such as smartphones, PCs, and tablets. Even if the multi-use device is VLAN-aware (many aren't, due to deficient Ethernet drivers or other reasons) the VoIP application is often not VLAN aware or, if it is, doesn't have a reliable way to determine the "voice VLAN". Cisco Discovery Protocol, a layer 2 protocol, helps with that a bit, http://en.wikipedia.org/wiki/Cisco_Discovery_Protocol. The biggest issue, though, is multi-use devices. On those devices, a single VLAN and a single IPv6 is seldom the right choice. The device, by definition, does different things: it might do a VoIP call, video call, IMAP to check email, HTTP to look up employee phone numbers on the internal directory, HTTP video streaming, and so on. And a mis-configured application or mis-guided application (trying to do the right thing, but failing) can be installed which mis-use the VLAN or mis-use the IPv6 address, creating an authorization problem. For example, should an interactive game with voice chat use the "voice VLAN" for its voice chat functionality -- probably not, but how can we prevent the application from doing that. The VLAN problem persists into IPv6 addressing if part of the IPv6 address conveys that same meaning as VLANs did with IPv4. I would like to solve the problem of DSCP awareness to applications, so that when joining an application and its OS can know what DSCP values to use, and use them. And a way to signal the network that this endpoint is trying to follow and honor the rules of that network (versus choosing its own DSCP values based on some static configuration that might have been appropriate for a different network). We also need a way for the incoming flow (towards the host) to have proper DSCP markings, as far away from the host as possible -- as DSCP gets over-written. -d > regards, > > Dan Wing > > 11 July 2012 02:33 > > ... > > > > I sure would like to understand better the details. > > > > I have seen a similar proposal, but it suffered from a problem that > only > > dedicated-use devices could participate in that scheme. Multi-use > > devices (e.g., a PC, a tablet, a smartphone) will not have the > > smarts to acquire multiple IPv6 prefixes and have certain > applications > > use a certain prefix (e.g., VoIP application is supposed to use > > a certain prefix to get certain DSCP treatment). This gets even > > harder if all applications are Javascript running within a web > > browser which is sometimes doing bittorrent, other times interactive > > realtime media, other times streaming video, other times filling > > out a web form. > > > > -d > > > > > > --------------------------------------------------------------------- > --- From fred@cisco.com Mon Jul 16 17:42: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 D3E0811E80B5 for ; Mon, 16 Jul 2012 17:42:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.449 X-Spam-Level: X-Spam-Status: No, score=-110.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Ej0+FSbkRKw for ; Mon, 16 Jul 2012 17:42:24 -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 0B9A111E80E5 for ; Mon, 16 Jul 2012 17:42:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2306; q=dns/txt; s=iport; t=1342485790; x=1343695390; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=uJ3GWOeq+kEdylWytdSk4n8Bt3FUenLZXuCJ7+Hrsfw=; b=D0kpbvMc+/c3Q8HxkmU8Q85WPan/6duXkh5ufJ4SwyNIi7XvLlcJdpw8 efk4nWBOSZy8GjMseV1aaarQAMJNGMydkoF+HvyrD5Rwfh87hSdWQ5OEd CrT4j9KryQz5wnU3fl9RXCbxGJ7k4mK9CbeJ8D8sBeIiTi5RzIHDITZaC M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAOmzBFCtJXHA/2dsb2JhbABFuVaBB4IgAQEBAwESASc/BQsCAQg2EDIlAgQOJ4dlBpxNoCKLQIVnYAOVO44ggWaCX4Ff X-IronPort-AV: E=Sophos;i="4.77,598,1336348800"; d="scan'208";a="102430125" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-7.cisco.com with ESMTP; 17 Jul 2012 00:43:10 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q6H0h9x9028183 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Jul 2012 00:43:09 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.118]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0298.004; Mon, 16 Jul 2012 19:43:09 -0500 From: "Fred Baker (fred)" To: "Zhouqian (Cathy)" Thread-Topic: [v6ops] Draft on DC migration to IPv6 Thread-Index: AQHNUtH08AdBnuzG2kudzG/wrZXEvg== Date: Tue, 17 Jul 2012 00:43:19 +0000 Message-ID: <76DF5413-31FD-48AC-B6C5-A0A5BB8E1ECC@cisco.com> References: <28DC472D-01D4-4534-97A9-6AE52BE9CC58@tid.es> <4FF70D8F.5010706@bogus.com> <4FFDB38F.3080206@bogus.com> <4FFE79DA.3010408@gmail.com> <4FFFD257.4060609@bogus.com> In-Reply-To: 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-19042.007 x-tm-as-result: No--39.245400-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 Cc: IPv6 Ops WG Subject: Re: [v6ops] Draft on DC migration to IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 Jul 2012 00:42:26 -0000 On Jul 15, 2012, at 8:37 PM, Zhouqian (Cathy) wrote: > There are only a few ICPs supporting IPv6 in China. But China is one of t= he countries which most lacks IPv4 addresses.=20 I think there is some old data there. China took its time getting started, = but the rapid collapse of the IPv4 pool in APNIC was in large part due to C= hinese addressing demand.=20 But taking your argument as it stands, it's that much better of an argument= for Chinese ICPs to deploy IPv6. If I were a Chinese ISP, which I'm not, rather than thinking long and hard = about NAT64 translation as a way to deliver traffic to an IPv4-only ICP acr= oss an IPv6-dominant ISP network, I would think about how to open a cloud b= usiness model. "Just think, ICPs, instead of or in addition to running your= data centers, you could also run a service in our cloud". I would then mak= e a characteristic of VMs in the cloud datacenter and a requirement of appl= ications using it be dual stack operation. That could be as simple as build= ing an OS-specific replacement for gethostbyname and getaddrinfo that one h= anded a character string - an IPv4 literal, an IPv6 literal, or a domain na= me - and it handed back a connected socket or an error message, having exec= uted a "happy eyeballs" algorithm underneath, and on incoming connections d= idn't care about the distinction. Wouldn't it be interesting if we had a pu= blic specification for that... Business model =3D> revenue for one's favorite ISP. I would then take my IPv4-only client-side customers and use stateless NAT6= 4 to support them in an (increasingly) IPv6-only network, with the effect o= f moving traffic from the IPv4-only data centers to the dual stack cloud da= ta centers. And as residential customers become IPv6-capable, give them IPv= 6 service. Net effect: *native* IPv6 service. If ICP customers complain that this is a business game, say "fine, deploy I= Pv6 in your data center, and then the game is over - we can even prefer you= r data center if you like". When the lack of IPv6 support becomes an issue = for the ICP, the ICP will deploy it. Note that half of the folks on this list just forwarded this email to their= lawyers: it contained the phrase "business model" and the word "revenue".= From mbehring@cisco.com Tue Jul 17 05:48: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 71EF821F85A2; Tue, 17 Jul 2012 05:48:12 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ccKm3qvhCwIk; Tue, 17 Jul 2012 05:48:11 -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 E5D9921F857A; Tue, 17 Jul 2012 05:48:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8624; q=dns/txt; s=iport; t=1342529338; x=1343738938; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=8asSaACKdXk2ZXsQQUewRLWDGfj6T1WsZZ27cMJZTEA=; b=Ag5VWgW/wYza7pyjVH3Uy6nRA4WKhUkxzhPKu22W6N/HlWidA2TScZHB 3nneSoc7NXCvcR2T9eES4CytW5YCJSF28yUPAx07nNbQwPLlQAJQ7puUU QBEHN3zfi7NhldEX0Pea6FSlTqpnAoXxNM/DFP0bWAO8UYCulz+FPn7ZU I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAPBeBVCtJXHB/2dsb2JhbABFuU+BB4IgAQEBBAEBAQ8BJzQEBwwEAgEIEQQBAQsUCQcnCxQJCAEBBAENBQgBCwcHh2sLnFqgMotAFAaFTWADlk+NEIFmgl+BVgk X-IronPort-AV: E=Sophos;i="4.77,603,1336348800"; d="scan'208";a="99613793" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-9.cisco.com with ESMTP; 17 Jul 2012 12:48:37 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q6HCmbwH025133 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Jul 2012 12:48:37 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.60]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0298.004; Tue, 17 Jul 2012 07:48:37 -0500 From: "Michael Behringer (mbehring)" To: "George, Wes" , "grow@ietf.org" , "v6ops@ietf.org" Thread-Topic: draft-behringer-lla-only and draft-ietf-grow-private-ip-sp-cores Thread-Index: Ac0M1PTc8z4ZGA26S5W5umLx5IqzdwB6fdhwFVYuJJA= Date: Tue, 17 Jul 2012 12:48:36 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF02C124@xmb-rcd-x14.cisco.com> References: <20120328112128.19122.59432.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.194.18] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19046.000 x-tm-as-result: No--45.061600-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: "draft-behringer-lla-only@tools.ietf.org" , Anthony Kirkham Subject: Re: [v6ops] draft-behringer-lla-only and draft-ietf-grow-private-ip-sp-cores X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 Jul 2012 12:48:12 -0000 Wes,=20 Thanks for your great input and sorry for the delay. In the meantime we hav= e updated our draft to include many of your (and others') comments. (http:/= /tools.ietf.org/html/draft-behringer-lla-only-01). Most importantly, we mad= e it now an informational draft.=20 We believe it is best to keep the drafts separate. There are important diff= erences between private addresses and link local: One is routed, one is not= ; one needs to be configured, one not. We added however a xref to draft-iet= f-grow-private-ip-sp-cores, because as you rightly comment, they are relate= d. We still think there is value in draft-behringer-lla-only. Bottom line, we = want to provide a document presenting the issues and advantages that allows= operators to make an educated decision whether link local is the right app= roach for them.=20 We'll ask for slots in Vancouver at v6ops and opsec to discuss the new vers= ion.=20 Eric and Michael > -----Original Message----- > From: George, Wes [mailto:wesley.george@twcable.com] > Sent: 31 March 2012 01:15 > To: grow@ietf.org; v6ops@ietf.org > Cc: draft-behringer-lla-only@tools.ietf.org; Anthony Kirkham > Subject: draft-behringer-lla-only and draft-ietf-grow-private-ip-sp-cores > =09 > Cross-posting to both lists again because I was unable to attend the v6op= s > session where draft-behringer was discussed, draft-ietf-grow-private-ip-s= p- > cores is likely nearing WGLC, and I believe that the issue I raised needs= to be > addressed before either proceeds. I defer to the chairs of both groups to > determine how to manage this across the two groups. >=20 > After reviewing both draft-grow-private-ip-sp-cores (Kirkham) and draft- > behringer-lla-only again, I am even more convinced that they either need = to > be merged, or that draft-behringer needs to be abandoned altogether as a > bad idea. Draft-grow-private-ip-sp-cores is quite a lot more complete in = its > discussion of the considerations around private IP usage, but focuses on > IPv4, meaning that it *is* incomplete for lack of discussion of IPv6, whi= ch is > a reality in most SP cores today. Nearly all of the same considerations a= pply > for IPv4 and IPv6 in this case, so there are probably a limited number of > changes that would be necessary to cover IPv6 in the Kirkham document. > I think that we need to come to some consensus on the recommended > behavior on both cases. If the recommendation is different for one versus > the other, we need to have a unified and clear articulation as to why thi= s is > the case. It may be that the consensus is to not recommend a behavior at = all, > and simply expand the format of Kirkham's document to cover any IPv6- > specific items, since it discusses pros and cons evenly (as an informatio= nal > doc) rather than recommending anything as a BCP. My vote is to do this, a= s I > am unconvinced that use of LLA represents BCP today, nor should it. I > outline some reasons below, but that's probably not as critical if others > agree that this is the proper method to proceed with these documents. >=20 >=20 >=20 > If draft-behringer is left as a separate document, here are some specific > comments: > The advantages proposed in draft-behringer are IMO not enough to justify > recommending use of LLA. > - Smaller routing tables can be achieved through other methods such as > setting the interfaces into passive mode in the IGP (so that they are not > redistributed into the IGP) and/or not redistributing connected routes. > Further, as SPs make great use of interface bundling (LAG), the number of > interfaces with IP addresses is dramatically reduced, making the need to > pull the point to point interfaces out of the routing table significantly= lower. > - Reduced attack surface - draft-ietf-grow-private-ip-sp-cores sections 1= 0 > and 11 discuss this in great detail, and come to the conclusion that it i= s of > limited benefit, and that alternatives exist to protect the infrastructur= e. > - lower configuration complexity - while this is true, it is replaced by > additional complexity in troubleshooting. In the case of traces and pings > locally on the box, it adds the additional step of requiring the operator= to > use extended ping and trace commands to specify the exit interface in ord= er > to make the ping work (vs simply issuing "ping [ip address]"), and makes = it > nearly impossible to derive the address of the remote interface without > determining the remote side router through some other means and logging > into the router to look. (vs practice today of using an IP in the same su= bnet, > usually 1 digit up or down that can be guessed to save time). > - less address space: The other draft mentions this as well, in the conte= xt of > IPv4 where it might make a difference, but this simply is not much of a > concern with IPv6. An entire network could be numbered many times over > out of one /64. > -simpler DNS : Most ISPs operating at the scale where this makes any > difference at all have tools to build the DNS forward and reverse entries= for > their infrastructure automatically based on the router name and interface > name extracted from their inventory tools. It's a few bits of scripting, = so it's > not like having less interfaces in DNS results in any net reduction in wo= rk or > increase in the possibility of mistakes. >=20 > - Draft-ietf-grow-private-ip-sp-cores rightly notes that the proposed > solution to broken pings/traces/PMTUD from draft-behringer (RFC 5837) has > little or no implementation. This makes it a hard sell as any sort of > recommended solution unless the benefits are much more significant than > what is currently discussed in draft-behringer. This has to be a large en= ough > benefit to justify pushing hard on router vendors to implement the featur= e > and SPs to certify and deploy the code, and frankly there are many more > important features to consider. >=20 > Thanks, >=20 > Wes George >=20 >=20 > > -----Original Message----- > > From: grow-bounces@ietf.org [mailto:grow-bounces@ietf.org] On Behalf > > Of internet-drafts@ietf.org > > Sent: Wednesday, March 28, 2012 7:21 AM > > To: i-d-announce@ietf.org > > Cc: grow@ietf.org > > Subject: [GROW] I-D Action: draft-ietf-grow-private-ip-sp-cores-00.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. This draft is a work item of the Global Routing > > Operations Working Group of the IETF. > > > > Title : Issues with Private IP Addressing in the Intern= et > > Author(s) : Anthony Kirkham > > Filename : draft-ietf-grow-private-ip-sp-cores-00.txt > > Pages : 15 > > Date : 2012-03-28 > > > > The purpose of this document is to provide a discussion of the > > potential problems of using private, RFC1918, or non-globally- > > routable addressing within the core of an SP network. The discussio= n > > focuses on link addresses and to a small extent loopback addresses. > > While many of the issues are well recognised within the ISP > > community, there appears to be no document that collectively > > describes the issues. > > > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-grow-private-ip-sp-core > > s-00.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > This Internet-Draft can be retrieved at: > > ftp://ftp.ietf.org/internet-drafts/draft-ietf-grow-private-ip-sp-cores > > -00.txt > > > > _______________________________________________ > > GROW mailing list > > GROW@ietf.org > > https://www.ietf.org/mailman/listinfo/grow >=20 > This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or subject to > copyright belonging to Time Warner Cable. This E-mail is intended solely = for > the use of the individual or entity to which it is addressed. If you are = not the > intended recipient of this E-mail, you are hereby notified that any > dissemination, distribution, copying, or action taken in relation to the > contents of and attachments to this E-mail is strictly prohibited and may= be > unlawful. If you have received this E-mail in error, please notify the se= nder > immediately and permanently delete the original and any copy of this E- > mail and any printout. From diego@tid.es Tue Jul 17 09: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 9A9C421F861F for ; Tue, 17 Jul 2012 09:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.189 X-Spam-Level: X-Spam-Status: No, score=-6.189 tagged_above=-999 required=5 tests=[AWL=0.410, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qjnlFDa3agaK for ; Tue, 17 Jul 2012 09:54:18 -0700 (PDT) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 379D521F861E for ; Tue, 17 Jul 2012 09:54:17 -0700 (PDT) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M7B006OKDNL7G@tid.hi.inet> for v6ops@ietf.org; Tue, 17 Jul 2012 18:55:04 +0200 (MEST) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id 75.A0.02752.7E895005; Tue, 17 Jul 2012 18:55:03 +0200 (CEST) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0M7B006P4DNR7G@tid.hi.inet> for v6ops@ietf.org; Tue, 17 Jul 2012 18:55:03 +0200 (MEST) Received: from EX10-MB1-MAD.hi.inet ([fe80::a473:4f3e:f8db:1855]) by ex10-htcas3-mad.hi.inet ([::1]) with mapi id 14.02.0298.004; Tue, 17 Jul 2012 18:55:03 +0200 Date: Tue, 17 Jul 2012 16:55:02 +0000 From: "Diego R. Lopez" In-reply-to: <76DF5413-31FD-48AC-B6C5-A0A5BB8E1ECC@cisco.com> X-Originating-IP: [10.95.64.115] To: "Fred Baker (fred)" Message-id: <3A2CE74C-86BB-4CFE-BCBF-3C4F5D1EEBB8@tid.es> Content-id: MIME-version: 1.0 Content-type: text/plain; charset=Windows-1252 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-US Thread-topic: [v6ops] Draft on DC migration to IPv6 Thread-index: AQHNUqhbgWRF7Aew1UKq7qhHvsQ1MZcK3RGAgBF/VoCAB27PAIAAVLIAgAAP24CAABmVgIAAuG8AgAAz8wCAAA2agIABjRCAgARxZgCAAWGwgIABD32A X-AuditID: 0a5f4e69-b7f6d6d000000ac0-d9-500598e798b2 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLKsWRmVeSWpSXmKPExsXCFe9nqPt8BmuAwbUPuhanj+1ldmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxo0j01gLFvBVPPl+kqWB8Qx3FyMnh4SAiUTDhS3sELaYxIV7 69m6GLk4hAS2M0o8mTKHEcL5ySixd8kEVghnKaPE7EubGUFaWARUJb72HGQFsdmA7EfNv4FG cXAICxhJfJ/kBWJyCthKfJlQALFAQeLPuccsILaIgIbEhi9HwTqZBXwkttz9DXYEr4ClxLTL 26HiZhJ/l/2EigtK/Jh8jwUirifx8c9tRghbXKK59SZUXFviybsLYL2MQM98P7WGCeQEEQFj iSP7BEGuFxFoYZR4uWc/1MMCEkv2nGeGsEUlXj7+B/XiPlaJM09vME5glJiF5I5ZSO6YheSO WUjumIXkjgWMrKsYxYqTijLTM0pyEzNz0g2M9DIy9TLzUks2MULiLnMH4/KdKocYBTgYlXh4 JaZ98hdiTSwrrsw9xCjJwaQkyjt1AmuAEF9SfkplRmJxRnxRaU5q8SFGCQ5mJRHeCV1AOd6U xMqq1KJ8mJQMB4eSBO+D6UApwaLU9NSKtMwcYHKBSTNxcIK08wC1LwWp4S0uSMwtzkyHyJ9i lJQS510FkhAASWSU5sH1vmIUBzpSGGI0DzANwnW9AhrIBDTQsoQJZGBJIkJKqoFRffGFPWc0 pAwO/Rf8uvNU/+/bKxeoVx/It+PVypZo2nPdZmLTvV2eX3a6PZRoT+qR89uQfnxf1Ze0GXbM UZfXuLy0ZFLZxlfK9Ohwo88Ug2duRZU/xKc/8Nq+KM761fzcKFEJPsO8yXq8+4WW7fuqpiQU tErSzUNMvGBr7dfmx7mTbvt/2cGuxFKckWioxVxUnAgAJKhL8kADAAA= References: <28DC472D-01D4-4534-97A9-6AE52BE9CC58@tid.es> <4FF70D8F.5010706@bogus.com> <4FFDB38F.3080206@bogus.com> <4FFE79DA.3010408@gmail.com> <4FFFD257.4060609@bogus.com> <76DF5413-31FD-48AC-B6C5-A0A5BB8E1ECC@cisco.com> Cc: IPv6 Ops WG Subject: Re: [v6ops] Draft on DC migration to IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 Jul 2012 16:54:19 -0000 On 17 Jul 2012, at 02:43 , Fred Baker (fred) wrote: > I would then make a characteristic of VMs in the cloud datacenter and a r= equirement of applications using it be dual stack operation. That could be = as simple as building an OS-specific replacement for gethostbyname and geta= ddrinfo that one handed a character string - an IPv4 literal, an IPv6 liter= al, or a domain name - and it handed back a connected socket or an error me= ssage, having executed a "happy eyeballs" algorithm underneath, and on inco= ming connections didn't care about the distinction. Wouldn't it be interest= ing if we had a public specification for that=85 Hmmm, that looks like an interesting additional approach to level 2 dual-st= ack DCs. If the hypothetical OS functions replacement were smart enough, it would al= low the transparent interoperation of DCs with different levels of v6 penetration, = either horizontal (internal data paths are not migrated, for example) or vertical = (per tenant or service group). I'll add a mention to this possibility in the new version I'm working in, a= nd I think we could ellaborate a little more on the idea of the spec... Be goode, -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego@tid.es Tel: +34 913 129 041 Mobile: +34 682 051 091 ----------------------------------------- ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx From sarikaya2012@gmail.com Tue Jul 17 12:53: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 20EF921F8624 for ; Tue, 17 Jul 2012 12:53:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.543 X-Spam-Level: X-Spam-Status: No, score=-3.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQhLjf06vqdx for ; Tue, 17 Jul 2012 12:53:52 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED0B21F8621 for ; Tue, 17 Jul 2012 12:53:52 -0700 (PDT) Received: by ghbg16 with SMTP id g16so919435ghb.31 for ; Tue, 17 Jul 2012 12:54:40 -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=JbNtJNqiEdJCuntpIp7pGySUA0yWsL40kOX7//E9bp4=; b=ePNyTnl32xl56djgPfRvCI44E7YbcsXWcMK4qoKFYELic5i2ZEAAeMHKxUGKQloQ2y 1an915cnqJ7R3nI30zdeRKmCBM/G3hUr4s6R5nGk8GHKazWkobTHd3d81PD+gAGa0h34 9yTdP93gC0fas4vlz+6vJP43O0s8Etdz5JhHclXnTUlSmCpSZoNBv5T+iy4ZCjI9y/2y exv4f5qiO2QBQAnIFxTOh5OHkG989oKRIxqM30tS3ZDcshwGn3DuOjPmEP6uZVO9JxA2 mgcxAnUgyYsZSSUIjmkNgBhsYMKNo8QXRAHD290LB4+GcSYNLTIuAsbjVHU9vQq8olgl swMA== MIME-Version: 1.0 Received: by 10.50.194.132 with SMTP id hw4mr62757igc.63.1342554880511; Tue, 17 Jul 2012 12:54:40 -0700 (PDT) Received: by 10.231.207.167 with HTTP; Tue, 17 Jul 2012 12:54:40 -0700 (PDT) In-Reply-To: <018901cd63b4$ee3dc0e0$cab942a0$@com> References: <5D36713D8A4E7348A7E10DF7437A4B9239EF7160@szxeml545-mbx.china.huawei.com> <4FFBFE58.8040408@inex.ie> <06AF4254-FAB4-496C-A894-7092451C42C0@ucd.ie> <4FFC541F.90701@umn.edu> <4FFC8738.40502@globis.net> <085f01cd5efc$cdff1bb0$69fd5310$@com> <4FFD1842.2090509@globis.net> <018901cd63b4$ee3dc0e0$cab942a0$@com> Date: Tue, 17 Jul 2012 14:54:40 -0500 Message-ID: From: Behcet Sarikaya To: Dan Wing Content-Type: text/plain; charset=ISO-8859-1 Cc: Ray Hunter , v6ops@ietf.org Subject: Re: [v6ops] FW: New Version Notification for draft-jiang-semantic-prefix-00.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, 17 Jul 2012 19:53:53 -0000 Hi Dan, This is too long mail. On Mon, Jul 16, 2012 at 7:41 PM, Dan Wing wrote: > > Cisco (and our IP PBX competitors) have long suggested that enterprises > put all voice devices on a separate VLAN ("voice VLAN"). This works > sortof alright until you're doing WiFi (no VLANs, only separate SSIDs > which you could map to separate VLANs) and completely fails with > multi-use devices such as smartphones, PCs, and tablets. Even if the > multi-use device is VLAN-aware (many aren't, due to deficient Ethernet > drivers or other reasons) the VoIP application is often not VLAN aware > or, if it is, doesn't have a reliable way to determine the "voice > VLAN". What do mean by no VLANs? Is it because of deficient device drivers? > > The biggest issue, though, is multi-use devices. On those devices, > a single VLAN and a single IPv6 is seldom the right choice. The device, What do you mean by a single IPv6? Single IPv6 address/prefix? Regards, Behcet From cathy.zhou@huawei.com Tue Jul 17 23:34: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 6205D11E8143 for ; Tue, 17 Jul 2012 23:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.463 X-Spam-Level: X-Spam-Status: No, score=-6.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2NzgcimXFdT for ; Tue, 17 Jul 2012 23:34:38 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 5625911E8148 for ; Tue, 17 Jul 2012 23:34:38 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHV85546; Wed, 18 Jul 2012 02:35:27 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 17 Jul 2012 23:32:48 -0700 Received: from SZXEML413-HUB.china.huawei.com (10.82.67.152) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 17 Jul 2012 23:32:46 -0700 Received: from SZXEML527-MBX.china.huawei.com ([169.254.3.194]) by szxeml413-hub.china.huawei.com ([10.82.67.152]) with mapi id 14.01.0323.003; Wed, 18 Jul 2012 14:32:41 +0800 From: "Zhouqian (Cathy)" To: "Fred Baker (fred)" Thread-Topic: [v6ops] Draft on DC migration to IPv6 Thread-Index: AQHNW5Grz6Airmi1OkGxTcsV2RJJE5cj2oyg///O9ACAAA/bgIAAGZWAgAC4cACAADPzAIAAkxxQgAEHjYCABPDEEIAA4lKAgAEeAHA= Date: Wed, 18 Jul 2012 06:32:41 +0000 Message-ID: References: <28DC472D-01D4-4534-97A9-6AE52BE9CC58@tid.es> <4FF70D8F.5010706@bogus.com> <4FFDB38F.3080206@bogus.com> <4FFE79DA.3010408@gmail.com> <4FFFD257.4060609@bogus.com> <76DF5413-31FD-48AC-B6C5-A0A5BB8E1ECC@cisco.com> In-Reply-To: <76DF5413-31FD-48AC-B6C5-A0A5BB8E1ECC@cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.77.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: IPv6 Ops WG Subject: Re: [v6ops] Draft on DC migration to IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 Jul 2012 06:34:39 -0000 Hi Fred, >From the IPv6 world day website below, we can see that there are only 16 or= ganizations in China=20 which participate in the 2012 IPv6 World Day and part of them support IPv6 = page. http://www.worldipv6launch.org/participants/?q=3D1 Cathy > -----Original Message----- > From: Fred Baker (fred) [mailto:fred@cisco.com] > Sent: Tuesday, July 17, 2012 8:43 AM > To: Zhouqian (Cathy) > Cc: Joel jaeggli; IPv6 Ops WG > Subject: Re: [v6ops] Draft on DC migration to IPv6 >=20 >=20 > On Jul 15, 2012, at 8:37 PM, Zhouqian (Cathy) wrote: >=20 > > There are only a few ICPs supporting IPv6 in China. But China is one of= the > countries which most lacks IPv4 addresses. >=20 > I think there is some old data there. China took its time getting started= , but > the rapid collapse of the IPv4 pool in APNIC was in large part due to Chi= nese > addressing demand. >=20 > But taking your argument as it stands, it's that much better of an argume= nt > for Chinese ICPs to deploy IPv6. >=20 > If I were a Chinese ISP, which I'm not, rather than thinking long and har= d > about NAT64 translation as a way to deliver traffic to an IPv4-only ICP a= cross > an IPv6-dominant ISP network, I would think about how to open a cloud > business model. "Just think, ICPs, instead of or in addition to running y= our > data centers, you could also run a service in our cloud". I would then ma= ke a > characteristic of VMs in the cloud datacenter and a requirement of > applications using it be dual stack operation. That could be as simple as > building an OS-specific replacement for gethostbyname and getaddrinfo tha= t > one handed a character string - an IPv4 literal, an IPv6 literal, or a do= main > name - and it handed back a connected socket or an error message, having > executed a "happy eyeballs" algorithm underneath, and on incoming > connections didn't care about the distinction. Wouldn't it be interesting= if we > had a public specification for that... >=20 > Business model =3D> revenue for one's favorite ISP. >=20 > I would then take my IPv4-only client-side customers and use stateless > NAT64 to support them in an (increasingly) IPv6-only network, with the > effect of moving traffic from the IPv4-only data centers to the dual stac= k > cloud data centers. And as residential customers become IPv6-capable, giv= e > them IPv6 service. Net effect: *native* IPv6 service. >=20 > If ICP customers complain that this is a business game, say "fine, deploy= IPv6 > in your data center, and then the game is over - we can even prefer your > data center if you like". When the lack of IPv6 support becomes an issue = for > the ICP, the ICP will deploy it. >=20 > Note that half of the folks on this list just forwarded this email to the= ir > lawyers: it contained the phrase "business model" and the word "revenue". From phdgang@gmail.com Wed Jul 18 02: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 9418E21F86EA; Wed, 18 Jul 2012 02:04:26 -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, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 54QaJlbd0UFG; Wed, 18 Jul 2012 02:04:25 -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 A0F7721F86D5; Wed, 18 Jul 2012 02:04:25 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so1018946vcb.31 for ; Wed, 18 Jul 2012 02:05: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=U2HpjSggEpu73XsQ8365wAPDIRb3bc2BKhJMjz5IcPA=; b=Zzpfq2egKW4Q2i/Mq20ykgorH0kZG/8N1GFF4XJLJ2X2tprEIvWWlD/eCp6sue9YFG fDi9gEmZ3lDVBKLOMCTlGMgw2bNJMJGDmSCwMpunuAnrz76IOml/O9qPcGBlRquX+Dog RgOCkcsbgngf9XYJra5wiO/uogwavV592LyoAZxAqywq97PT2djVbdhVVLK0H53fOZxu leAuPbREBOcplVNyCHsEszXYzSxzYX0UIYYvj+hsLA8eTiXV0pUhAFErbjCLD8t2Qlyh /4eXJsXV/41Bacsnzthn4Lidyi96vRXVMAATQyc37ie6T4+VmiQ28NWEr0wr+O05DvhC 1EmQ== MIME-Version: 1.0 Received: by 10.52.100.4 with SMTP id eu4mr43127vdb.66.1342602315106; Wed, 18 Jul 2012 02:05:15 -0700 (PDT) Received: by 10.58.58.36 with HTTP; Wed, 18 Jul 2012 02:05:15 -0700 (PDT) In-Reply-To: <4FF696AA.3050508@tut.fi> References: <4FF696AA.3050508@tut.fi> Date: Wed, 18 Jul 2012 17:05:15 +0800 Message-ID: From: GangChen To: Aleksi Suhonen Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops , ipv6@ietf.org Subject: Re: [v6ops] draft-chen-v6ops-nat64-experience-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 Jul 2012 09:04:26 -0000 cc v6ops where there is discussion on draft-chen-v6ops-nat64-experience 2012/7/6, Aleksi Suhonen : > Hi, > > We've been running a NAT64/DNS64 setup at TREX Tampere Region Exchange > for over a year now and I'd like to submit the following experience for > your draft: Your inputs are welcome. > IPv6 Privacy Extensions are a big problem with stateless NAT64. A single > device with priv exts enabled will use up several IPv4 addresses from > the NAT64 pool. And since the IPv4 Internet is full of malware probing > for vulnerabilities, the whole IPv4 address pool for the stateless NAT64 > will periodically get random traffic from the Internet. > > Even if the priv ext addresses have expired, the network will generate > an ICMPv6 unreachable message which will travel through the NAT64 device > and thus refresh timers for the IPv4 mapping. Some firewalls will also > generate TCP RST messages for such probes to non-existent IPv6 addresses. > > In fact, our worst experience has been with an Apple iPad which was left > alone in an IPv6 only WLAN which was using our DNS64 service. The iPad > thought that the WLAN was broken because it only got an IPv6 address and > no DHCPv4 response. It had time to send some packets using IPv6 through > the NAT64 which created the mapping. Then it reset its WLAN and tried to > associate with the same SSID again. Every time it created a new privacy > extension based IPv6 address and a new mapping in the stateless NAT64 > device. > > Within an hour, all the IPv4 addresses in the pool for our NAT64 were > registered to this one device. =>I may hardly understand that is a problem with stateless NAT64. RFC6145 doesn't require creating a mapping state because it's *stateless*. The package forwarding is based on mapping rules, which is nothing to do with *lifetime*. Therefore, above statement of IPv4 pool exhaustion may not apply to stateless NAT64. I suspect this problem may occur in a stateful NAT64 context. The frequent reclaiming behavior would consume unnecessary resource by creating overwhelming states on NAT64 box. Your further check is expected. > It would be my recommendation that there was either a Router > Advertisement Flags Option for "do not use privacy extensions here" and > that this was used in all setups that use DNS64 name servers, or that > all such setups should use Managed Address Configuration aka DHCPv6 > address configuration. Those potential solutions are worth to be discussed further. Especially, new added RA flags option would require additional specification efforts. Many thanks Gang > -- > Aleksi Suhonen, Researcher > Department of Communications Engineering > Tampere University of Technology > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From evyncke@cisco.com Wed Jul 18 07:11: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 AD20C21F878A for ; Wed, 18 Jul 2012 07:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.12 X-Spam-Level: X-Spam-Status: No, score=-10.12 tagged_above=-999 required=5 tests=[AWL=-0.479, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, SARE_SUB_6CONS_WORD=0.356] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xM9ajOx0Oedl for ; Wed, 18 Jul 2012 07:11:38 -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 776C921F8789 for ; Wed, 18 Jul 2012 07:11:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=evyncke@cisco.com; l=8199; q=dns/txt; s=iport; t=1342620749; x=1343830349; h=from:to:cc:subject:date:message-id:mime-version; bh=dLKGm4qMLJfUkNxg/Ozgc41UTRAQq49DRn/SJ0Ec5Xo=; b=BZOzLBF8E6AXrnLJgmNPPLDYEKPH70AwblRUDvL3oTs+eNUCtDRQ5C07 zulPCCie3Pn7RR3d5zG/MK+yGYvH0lB/lHbQirEHok98AD7ZGbdzrmi/K kZ8/CjEX6+rR3xYEu9ngZo1Qu8FN5LQ/vpu7Fm/BD0wkXIfZDjKzenx6O Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak4FAH7DBlCtJXHA/2dsb2JhbABFgkqtbwGJAYEHgiIBBBIBGkcFEgEqViYBBA4NGodrC51uoBeRL2ADiBiOP40QgWaCXw X-IronPort-AV: E=Sophos;i="4.77,610,1336348800"; d="scan'208,217";a="103014657" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-2.cisco.com with ESMTP; 18 Jul 2012 14:12:28 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q6IECSGs005466 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 18 Jul 2012 14:12:28 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.178]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0298.004; Wed, 18 Jul 2012 09:12:28 -0500 From: "Eric Vyncke (evyncke)" To: "v6ops@ietf.org WG" Thread-Topic: New version of draft-chkpvc-enterprise-incremental-ipv6-01 Thread-Index: Ac1k71m1KkcMdiAsRzSbD5XMS6Agrw== Date: Wed, 18 Jul 2012 14:12:27 +0000 Message-ID: <97EB7536A2B2C549846804BBF3FD47E1050E25@xmb-aln-x02.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.185.70] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19048.005 x-tm-as-result: No--35.838500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_97EB7536A2B2C549846804BBF3FD47E1050E25xmbalnx02ciscocom_" MIME-Version: 1.0 Cc: "lee.howard@twcable.com" , "victor.kuarsingh@rci.rogers.com" Subject: [v6ops] New version of draft-chkpvc-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: Wed, 18 Jul 2012 14:11:39 -0000 --_000_97EB7536A2B2C549846804BBF3FD47E1050E25xmbalnx02ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We have updated our I-D about IPv6 enterprise deployment based on the few c= omments that we have received: http://tools.ietf.org/html/draft-chkpvc-enterprise-incremental-ipv6-01 (abs= tract below) The chairmen were kind enough to put us on the agenda on Friday even with a= filename which does not include v6ops. Thanks in advance for any comment, -=E9ric, Yanick, KK, Tim, Lee & Victor 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. --_000_97EB7536A2B2C549846804BBF3FD47E1050E25xmbalnx02ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

We have updated our I-D abo= ut IPv6 enterprise deployment based on the few comments that we have receiv= ed:

http://tools.ietf.o= rg/html/draft-chkpvc-enterprise-incremental-ipv6-01 (abstract below)

 

The chairmen were kind enou= gh to put us on the agenda on Friday even with a filename which does not in= clude v6ops.

 

Thanks in advance for any c= omment,

 

-=E9ric, Yanick, KK, Tim, L= ee & Victor

 

Enterprise network administ= rators worldwide are in various stages of

   preparing for = or deploying IPv6 into their networks.  The

   administrators= face different challenges than operators of Internet

   access provide= rs, and have reasons for different priorities.  The<= /p>

   overall proble= m for many administrators will be to offer Internet-

   facing service= s over IPv6, while continuing to support IPv4, and

   while introduc= ing IPv6 access within the enterprise IT network.  The

   overall transi= tion will take most networks from an IPv4-only

   environment to= a dual stack network environment and potentially an

   IPv6-only oper= ating mode.  This document helps provide a framework=

   for enterprise= network architects or administrators who may be faced

   with many of t= hese challenges as they consider their IPv6 support

   strategies.

--_000_97EB7536A2B2C549846804BBF3FD47E1050E25xmbalnx02ciscocom_-- From evyncke@cisco.com Wed Jul 18 07:34: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 89E0421F8797; Wed, 18 Jul 2012 07:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.448 X-Spam-Level: X-Spam-Status: No, score=-10.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oa7UyG9lVgUF; Wed, 18 Jul 2012 07:34:04 -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 9A24D21F8798; Wed, 18 Jul 2012 07:34:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=evyncke@cisco.com; l=4015; q=dns/txt; s=iport; t=1342622095; x=1343831695; h=from:to:cc:subject:date:message-id:mime-version; bh=VXzsKwxg/ElBA5bbs+wzPgNOb50K7OxlisgVtKGxVqU=; b=WGUUu/+PFhGbu71CINJe8qfjVBfiNUG+hsYeUBonqhle2i3TFoYkoFGc Im+td9RzoAtvMeNY7SjwwjVnr7aH9OV57hcowr2u4qXrau+Ja5LLQu62k ZqFkdDEtt0VLf3oJJuaJ38kkmVL94GFbN9h+JtUrWz8hqTshrtjNlJb/w I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak4FAAnJBlCtJXG+/2dsb2JhbABFgkqtZwGJAYEHgiIBBBIBGkwSAQweGT0mAQQBDQ0ah2sLnXCgF5EvYAOIGI4/jRCBZoJf X-IronPort-AV: E=Sophos;i="4.77,610,1336348800"; d="scan'208,217";a="103050281" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 18 Jul 2012 14:34:54 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q6IEYsQK008666 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 18 Jul 2012 14:34:54 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.178]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0298.004; Wed, 18 Jul 2012 09:34:54 -0500 From: "Eric Vyncke (evyncke)" To: "v6ops@ietf.org WG" , "opsec@ietf.org" Thread-Topic: New updated version of draft-vyncke-opsec-v6-01 (Operational Security Considerations for IPv6 Networks) Thread-Index: Ac1k8n6y0ZuVpdOPQS+AAZ9+CBbUHw== Date: Wed, 18 Jul 2012 14:34:53 +0000 Message-ID: <97EB7536A2B2C549846804BBF3FD47E1050EC5@xmb-aln-x02.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.185.70] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19048.005 x-tm-as-result: No--25.474200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_97EB7536A2B2C549846804BBF3FD47E1050EC5xmbalnx02ciscocom_" MIME-Version: 1.0 Cc: Merike Kaeo Subject: [v6ops] New updated version of draft-vyncke-opsec-v6-01 (Operational Security Considerations for IPv6 Networks) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 Jul 2012 14:34:05 -0000 --_000_97EB7536A2B2C549846804BBF3FD47E1050EC5xmbalnx02ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We have posted a new version of our draft draft-vyncke-opsec-v6 at: http://tools.ietf.org/html/draft-vyncke-opsec-v6-01 As usual comments are welcome, at Paris, comments were 'yes this is require= d'. BTW, the intent is not to write 100's of pages but rather document exis= ting I-D and good practices. Best regards -merike, kk and =E9ric --_000_97EB7536A2B2C549846804BBF3FD47E1050EC5xmbalnx02ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

We have posted a new versio= n of our draft draft-vyncke-opsec-v6 at:

http://tools.ietf.org/html/draft-vynck= e-opsec-v6-01

 

As usual comments are welco= me, at Paris, comments were ‘yes this is required’. BTW, the in= tent is not to write 100’s of pages but rather document existing I-D and good practices.

 

Best regards

 

-merike, kk and =E9ric=

 

--_000_97EB7536A2B2C549846804BBF3FD47E1050EC5xmbalnx02ciscocom_-- From achatz@forthnetgroup.gr Wed Jul 18 09:29: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 02CF211E80ED for ; Wed, 18 Jul 2012 09:29:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.87 X-Spam-Level: X-Spam-Status: No, score=-1.87 tagged_above=-999 required=5 tests=[AWL=0.729, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nbJr+BQ3UdgA for ; Wed, 18 Jul 2012 09:29:16 -0700 (PDT) Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.107]) by ietfa.amsl.com (Postfix) with ESMTP id BE10E11E80DB for ; Wed, 18 Jul 2012 09:29:14 -0700 (PDT) Received: from mx-av-06.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 q6IGU3nw001006 for ; Wed, 18 Jul 2012 19:30:03 +0300 Received: from MX-IN-01.forthnet.gr (mx-in-01.forthnet.gr [193.92.150.23]) by mx-av-06.forthnet.gr (8.14.4/8.14.4) with ESMTP id q6IGU3aV013684 for ; Wed, 18 Jul 2012 19:30:03 +0300 Received: from [62.1.48.75] (achatz.forthnet.gr [62.1.48.75]) (authenticated bits=0) by MX-IN-01.forthnet.gr (8.14.4/8.14.4) with ESMTP id q6IGTrRg016137; Wed, 18 Jul 2012 19:29:54 +0300 Authentication-Results: MX-IN-01.forthnet.gr smtp.mail=achatz@forthnetgroup.gr; auth=pass (PLAIN) Message-ID: <5006E47F.8010605@forthnetgroup.gr> Date: Wed, 18 Jul 2012 19:29:51 +0300 From: Tassos Chatzithomaoglou Organization: Forthnet User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120615 Firefox/13.0.1 SeaMonkey/2.10.1 MIME-Version: 1.0 To: "v6ops@ietf.org WG" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [v6ops] current solutions for incoming connections in CGN environments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 Jul 2012 16:29:17 -0000 Hi, I'm looking for opinions and recommendations regarding the known limitations with incoming connections & port forwarding in CGN-like environments (preferably DS-Lite), in environments with multiple layers of NAT or when NAT is not taking place on the CPE. If i'm not mistaken, currently you cannot have such a functionality based on standards. There seem to be some solutions on the way, but i'm looking for something that is available now, something that you would implement now if you had to go live in a few months. i.e. PCP seems to take too long, and besides some CPE vendors that offer beta firmware based on the drafts, i haven't seen any major router vendors implementing the PCP server function officially (besides vendor's beta demo at IETF 81). All operators using CGN, how do you currently solve this problem? Any plans to write an informational RFC based on this? Or is PCP the only solution and everyone is waiting for it? -- Tassos From cb.list6@gmail.com Wed Jul 18 09:33: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 98D3911E80D9 for ; Wed, 18 Jul 2012 09:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.156 X-Spam-Level: X-Spam-Status: No, score=-3.156 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sfuOf5PpTWZV for ; Wed, 18 Jul 2012 09:33:41 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id DA5DB11E80A6 for ; Wed, 18 Jul 2012 09:33:40 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so2944492pbc.31 for ; Wed, 18 Jul 2012 09:34: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=2yBZ2BCTxCQVZwVxFGRbHPeHi6pyUTfc8GV+KN9ZH3E=; b=y7FBhiGuYLb9B7e0OyrxIsm8zJll94XgUyp/iVNyJtppSIplxHTGf1OZax1DbIEz3M SubDNFlLQiLAg9GJoG4Rerp3SzzHKJKBxn7CVGjt3aJ8riiOy27LiNMelEpay4Aen3FN MMBRyuQ7fmaJnPoXQFErJUcoSs7cLqzhMZybXaxXPHss3UuvDcQHUBouCxWBmHctlTi0 cFt0PhgtvHy/O+g7mIPQKOB33XWQModc12HRsL4rdM8GQITtUeiYt8dT831zBwCuymgp rgS20w5sNHgwx4GyAL8QvT+1WG9dmTxCAMf3sWgfvoCMDATOQHE+yiEtqMB4AIdf89s3 9wPw== MIME-Version: 1.0 Received: by 10.68.224.39 with SMTP id qz7mr8608209pbc.127.1342629271521; Wed, 18 Jul 2012 09:34:31 -0700 (PDT) Received: by 10.142.100.9 with HTTP; Wed, 18 Jul 2012 09:34:31 -0700 (PDT) In-Reply-To: <5006E47F.8010605@forthnetgroup.gr> References: <5006E47F.8010605@forthnetgroup.gr> Date: Wed, 18 Jul 2012 09:34:31 -0700 Message-ID: From: Cameron Byrne To: Tassos Chatzithomaoglou Content-Type: text/plain; charset=ISO-8859-1 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] current solutions for incoming connections in CGN environments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 Jul 2012 16:33:41 -0000 On Wed, Jul 18, 2012 at 9:29 AM, Tassos Chatzithomaoglou wrote: > Hi, > > I'm looking for opinions and recommendations regarding the known limitations > with incoming connections & port forwarding in CGN-like environments > (preferably DS-Lite), in environments with multiple layers of NAT or when > NAT is not taking place on the CPE. > If i'm not mistaken, currently you cannot have such a functionality based on > standards. > There seem to be some solutions on the way, but i'm looking for something > that is available now, something that you would implement now if you had to > go live in a few months. > i.e. PCP seems to take too long, and besides some CPE vendors that offer > beta firmware based on the drafts, i haven't seen any major router vendors > implementing the PCP server function officially (besides vendor's beta demo > at IETF 81). > > All operators using CGN, how do you currently solve this problem? > Any plans to write an informational RFC based on this? > Or is PCP the only solution and everyone is waiting for it? > Since this is the v6ops lists, the solution is don't invest in more life support for IPv4. IPv6 does not have these problems. If your service is DS-lite, customers should have a very capable IPv6 connection and they can receive incoming connection over IPv6. CB From sarikaya2012@gmail.com Wed Jul 18 09:35: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 DC8B011E80ED for ; Wed, 18 Jul 2012 09:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.544 X-Spam-Level: X-Spam-Status: No, score=-3.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F5Q+IO4QT7f2 for ; Wed, 18 Jul 2012 09:35:38 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 00A7511E80D9 for ; Wed, 18 Jul 2012 09:35:37 -0700 (PDT) Received: by yenq13 with SMTP id q13so1973281yen.31 for ; Wed, 18 Jul 2012 09:36:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:cc :content-type; bh=yYDZ1pekwzFHhmC1+lIaH7wO3qBD3hi1pUxh/GJHKno=; b=HNt74xXsznYR98J5h0fL/wPwFyL3WkeRIvxCXU/Zwn8B6cwhgSdL6hsibUmQsRdaxF xRcN7objACD6syUiQIDzIwMCcFxl3p7WJBwGA1k/OiHzpbbKsw0IL6PmYMGMB8qK6b2P oImvGQuob5eQNZeV9L0C4mWdrwZx+THsX1zGmaeo8Eua1Fxy4DbCgtYmEu9reBFmXtJS WLpf66zDvDV/2PHeEmZ66BIEQzzSEg6XVDv4yUM4DnBhQQV8/raDUUDSmlQA+0c3Lzmi e5PDZAU46O+XE6+SKx7pHEVTpHqQ6a8Ck2YLLp25omz7fr92yPmznvwNnIrQ+PSDKXKR S4fw== MIME-Version: 1.0 Received: by 10.50.195.234 with SMTP id ih10mr2786767igc.0.1342629387950; Wed, 18 Jul 2012 09:36:27 -0700 (PDT) Received: by 10.231.207.167 with HTTP; Wed, 18 Jul 2012 09:36:27 -0700 (PDT) Date: Wed, 18 Jul 2012 11:36:27 -0500 Message-ID: From: Behcet Sarikaya To: Aleksi Suhonen Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-chen-v6ops-nat64-experience-02 Stateless NAT64 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: Wed, 18 Jul 2012 16:35:39 -0000 Hi Alexsi, On Tue, Jul 17, 2012 at 8:17 PM, Aleksi Suhonen wrote: > Hi, > > Sorry for late response. It's the summer holiday season here. O:-) > > > On 07/06/2012 05:59 PM, Michael Richardson wrote: >> >> >>>>>>> "Aleksi" == Aleksi Suhonen writes: >> >> Aleksi> Within an hour, all the IPv4 addresses in the pool for our >> Aleksi> NAT64 were registered to this one device. >> >> Do I understand that you attempt to provide a single IPv4 address 1:1 >> with a an internal IPv6 address? (NAT vs NAPT) > > > Yes. Stateless NAT64. http://tools.ietf.org/html/rfc6144#section-3.2.1 > Thanks for pointing this out. But RFC 6144 is informational and what Section 3.2.1 describes is very generic, it seems to describe kind of 4rd. So you need to write a draft describing Stateless NAT64 :-), please. Regards, Behcet From jhw@apple.com Wed Jul 18 10:23: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 D6CD721F879E for ; Wed, 18 Jul 2012 10:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_BAYES_5x7=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q9uRNgznC6Xh for ; Wed, 18 Jul 2012 10:23:24 -0700 (PDT) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id B08D421F8799 for ; Wed, 18 Jul 2012 10:23:15 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay16.apple.com ([17.128.113.55]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0M7D003R672UIWM3@mail-out.apple.com> for v6ops@ietf.org; Wed, 18 Jul 2012 10:23:58 -0700 (PDT) X-AuditID: 11807137-b7f626d0000059a0-bb-5006f12e493b Received: from kallisti.apple.com (kallisti.apple.com [17.193.13.64]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay16.apple.com (Apple SCV relay) with SMTP id 6D.DF.22944.E21F6005; Wed, 18 Jul 2012 10:23:58 -0700 (PDT) From: james woodyatt In-reply-to: Date: Wed, 18 Jul 2012 10:23:58 -0700 Message-id: <7B65A922-9936-42EE-B1AA-172941525FEA@apple.com> References: <5006E47F.8010605@forthnetgroup.gr> To: "v6ops@ietf.org WG" X-Mailer: Apple Mail (2.1485) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplluLIzCtJLcpLzFFi42IRPMjroKv3kS3AYPN9AYvTx/YyOzB6LFny kymAMYrLJiU1J7MstUjfLoEr4/GJ+WwFFzgrJn69z9LAeJq9i5GTQ0LARGJ26zxGCFtM4sK9 9WxdjFwcQgKzmSR+/LvBCpJgFtCSuPHvJROIzSugJzG7fQ4LiC0sECyxtO0HWJxNQEXi2+W7 YDanQKDEuk0TwGwWAVWJs83rGSHmaEssW/iaGWKOjcTLz9eAlnEALSuRePgiCyQsIqAh0bXl DxvEPbIS3w+fZ5vAyDcLyRWzkFwxC8nUBYzMqxgFi1JzEisNzfQSCwpyUvWS83M3MYICqaHQ fAfj9r9yhxgFOBiVeHgf7GINEGJNLCuuzD3EKMHBrCTCe+UFW4AQb0piZVVqUX58UWlOavEh RmkOFiVx3ih+oGqB9MSS1OzU1ILUIpgsEwenVAMjx51ABn8Xl+lHvt59IMoSosl11Xv5vtaa gy8evrO7+7LVuPfQG5Z7t53lStZk5jC0L5LMm7/wxZajUz7qCqb2Ba6T2+hkumw/Hw+nR4/0 j5qEI5Nni52c0+GoNrN0GtdGVam4t69XiqzT3PdE1dnmRtbZNTnzOC325El09bIqh6u80NGb 8nKyEktxRqKhFnNRcSIAoXMOKSACAAA= Subject: Re: [v6ops] current solutions for incoming connections in CGN environments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 Jul 2012 17:23:26 -0000 On Jul 18, 2012, at 09:34 , Cameron Byrne wrote: > > If your service is DS-lite, customers should have a very capable IPv6 connection and they can receive incoming connection over IPv6. Unless the CPE gateway has RFC 6092 Simple Security enabled--which MAY be the default configuration in many cases--in which case inbound flows other than IKE and IPsec ESP are rejected unless there is an integrated PCP service available to hosts for mapping other ports and protocols according to REC-48. REC-48 Internet gateways with IPv6 simple security capabilities SHOULD implement a protocol to permit applications to solicit inbound traffic without advance knowledge of the addresses of exterior nodes with which they expect to communicate. If there are IPv6 CPE gateways, commercially available now with RFC 6092 Simple Security filtering and an integrated PCP server for meeting REC-48, then I'd like to know about them. In particular, I'd like to know about any such gateways that have Simple Security enabled in the default configuration. -- james woodyatt member of technical staff, core os networking From victor.kuarsingh@gmail.com Wed Jul 18 10:23: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 64FFC21F85F2 for ; Wed, 18 Jul 2012 10:23:29 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sit3RSzg5FUr for ; Wed, 18 Jul 2012 10:23:28 -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 CCFDF21F879E for ; Wed, 18 Jul 2012 10:23:27 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so2663008lbb.31 for ; Wed, 18 Jul 2012 10:24: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=vq39EB9esWDaAD527bdVk+GEjcxyi8uWUlSAQt7ZQBI=; b=wpRgo10t3mjQ4tMXR6ReZ4MjMRvFY1mFY0P0YHrkhLrPZNl+f9UgXd0PbCZWlNDxOV +08yMCQrcUxLaC/9imSAjjCCmX4rXS1Ei0juNPg6H8lOE/Qs78te1jeRhQTwRi5TLa9c vuLWP01ClWowPSS05AFmMJ+tRb7OkWWI9Iwj3rY/EmgxMlMb4yJTLeZIjSflCc/bZNOu xyyEG3Ty+yWCQswERNxGwn0Mo46B+A8oAhLNBXK3zuBsxxzptmSwAttq/rQ17uwXYT8D 4Jk873OzPtv8OyAZ/g60JplJbxrVYjhOqg3oIJL3eFXAAtMI8/wripD1osS1hxNHQSvF D/8g== MIME-Version: 1.0 Received: by 10.112.85.225 with SMTP id k1mr2226432lbz.38.1342632257459; Wed, 18 Jul 2012 10:24:17 -0700 (PDT) Received: by 10.112.127.170 with HTTP; Wed, 18 Jul 2012 10:24:17 -0700 (PDT) In-Reply-To: References: <5006E47F.8010605@forthnetgroup.gr> Date: Wed, 18 Jul 2012 13:24:17 -0400 Message-ID: From: Victor Kuarsingh To: Cameron Byrne Content-Type: multipart/alternative; boundary=f46d04016861c516d204c51dee1f Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] current solutions for incoming connections in CGN environments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 Jul 2012 17:23:29 -0000 --f46d04016861c516d204c51dee1f Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jul 18, 2012 at 12:34 PM, Cameron Byrne wrote: > On Wed, Jul 18, 2012 at 9:29 AM, Tassos Chatzithomaoglou > wrote: > > Hi, > > > > I'm looking for opinions and recommendations regarding the known > limitations > > with incoming connections & port forwarding in CGN-like environments > > (preferably DS-Lite), in environments with multiple layers of NAT or when > > NAT is not taking place on the CPE. > > > All operators using CGN, how do you currently solve this problem? > > Any plans to write an informational RFC based on this? > > Or is PCP the only solution and everyone is waiting for it? > > > > Since this is the v6ops lists, the solution is don't invest in more > life support for IPv4. > > IPv6 does not have these problems. > > If your service is DS-lite, customers should have a very capable IPv6 > connection and they can receive incoming connection over IPv6. > I would tend to agree with Cameron here. Not sure how much support you will get on this list to solve this IPv4 issue. This is one of the many issues with CGN. I would try an reach out to the vendors and see if they have any specific capabilities on their platforms to incoming connections to work, but the larger issue we saw when analyzing this was getting it to be automated (customer portal, or other capability to set the port forwarding rules etc). We are waiting for PCP and have accepted the gap for now. Perhaps if you have some number of customers who need incoming port forwarding, then if possible, keep them off CGN (you may not have that option). If the port forwarding is required to support functions inside your network, you can try and by-pass the CGN (but I had assumed you need this for general incoming connections which would originate outside your network to your customers). regards, Victor K > > CB > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --f46d04016861c516d204c51dee1f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jul 18, 2012 at 12:34 PM, Cameron By= rne <cb.list6@gmail.com> wrote:
On Wed, Jul 18, 2012 at 9:29 AM, Tassos Chatzithomaoglou
<achatz@forthnetgroup.gr&= gt; wrote:
> Hi,
>
> I'm looking for opinions and recommendations regarding the known l= imitations
> with incoming connections & port forwarding in CGN-like environmen= ts
> (preferably DS-Lite), in environments with multiple layers of NAT or w= hen
> NAT is not taking place on the CPE.
=A0
> All operators using CGN, how do you currently solve this problem?
> Any plans to write an informational RFC based on this?
> Or is PCP the only solution and everyone is waiting for it?
>

Since this is the v6ops lists, the solution is don't invest in mo= re
life support for IPv4.

IPv6 does not have these problems.

If your service is DS-lite, customers should have a very capable IPv6
connection and they can receive incoming connection over IPv6.

I would tend to agree with Cameron here.=A0 Not sure how much = support you will get on this list to solve this IPv4 issue.

This is = one of the many issues with CGN.=A0 I would try an reach out to the vendors= and see if they have any specific capabilities on their platforms to incom= ing connections to work, but the larger issue we saw when analyzing this wa= s getting it to be automated (customer portal, or other capability to set t= he port forwarding rules etc).

We are waiting for PCP and have accepted the gap for now.

Perhap= s if you have some number of customers who need incoming port forwarding, t= hen if possible, keep them off CGN (you may not have that option).=A0 If th= e port forwarding is required to support functions inside your network, you= can try and by-pass the CGN (but I had assumed you need this for general i= ncoming connections which would originate outside your network to your cust= omers).

regards,

Victor K

=A0

CB
_____________________= __________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

--f46d04016861c516d204c51dee1f-- From gert@space.net Wed Jul 18 10:45: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 C66DF11E8132 for ; Wed, 18 Jul 2012 10:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OHtjtPo7xghx for ; Wed, 18 Jul 2012 10:45:37 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 316EC11E80D9 for ; Wed, 18 Jul 2012 10:45:36 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id E487FF8D34 for ; Wed, 18 Jul 2012 19:46:25 +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 CF280F8D35 for ; Wed, 18 Jul 2012 19:46:25 +0200 (CEST) Received: (qmail 24895 invoked by uid 1007); 18 Jul 2012 19:46:25 +0200 Date: Wed, 18 Jul 2012 19:46:25 +0200 From: Gert Doering To: Tassos Chatzithomaoglou Message-ID: <20120718174625.GV38127@Space.Net> References: <5006E47F.8010605@forthnetgroup.gr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5006E47F.8010605@forthnetgroup.gr> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] current solutions for incoming connections in CGN environments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 Jul 2012 17:45:37 -0000 Hi, On Wed, Jul 18, 2012 at 07:29:51PM +0300, Tassos Chatzithomaoglou wrote: > I'm looking for opinions and recommendations regarding the known > limitations with incoming connections & port forwarding > in CGN-like environments (preferably DS-Lite), in environments > with multiple layers of NAT or when NAT is not taking > place on the CPE. I've been told the solution is called "IPv6". (And I'm actually quite serious about that: do you really want to invest more and more money on a dead protocol, or do you want to show your customers some incentives why IPv6 is really what they want to have?) 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 achatz@forthnetgroup.gr Wed Jul 18 11:18: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 2D18A11E813B for ; Wed, 18 Jul 2012 11:18:54 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ifwa2DgOkVjQ for ; Wed, 18 Jul 2012 11:18:53 -0700 (PDT) Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.107]) by ietfa.amsl.com (Postfix) with ESMTP id 2920511E8132 for ; Wed, 18 Jul 2012 11:18:52 -0700 (PDT) Received: from mx-av-06.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 q6IIJfPl004348; Wed, 18 Jul 2012 21:19:41 +0300 Received: from MX-IN-11.forthnet.gr (mx-in-11.forthnet.gr [193.92.150.31]) by mx-av-06.forthnet.gr (8.14.4/8.14.4) with ESMTP id q6IIJfHL027088; Wed, 18 Jul 2012 21:19:41 +0300 Received: from [192.168.1.2] (77.49.140.157.dsl.dyn.forthnet.gr [77.49.140.157]) (authenticated bits=0) by MX-IN-11.forthnet.gr (8.14.4/8.14.4) with ESMTP id q6IIJeMP008124; Wed, 18 Jul 2012 21:19:41 +0300 Authentication-Results: MX-IN-11.forthnet.gr smtp.mail=achatz@forthnetgroup.gr; auth=pass (PLAIN) Message-ID: <5006FE33.7090903@forthnetgroup.gr> Date: Wed, 18 Jul 2012 21:19:31 +0300 From: Tassos Chatzithomaoglou User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120615 Firefox/13.0.1 SeaMonkey/2.10.1 MIME-Version: 1.0 To: Victor Kuarsingh References: <5006E47F.8010605@forthnetgroup.gr> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] current solutions for incoming connections in CGN environments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 Jul 2012 18:18:54 -0000 The problem is that although we have enabled IPv6 in our network, we don't expect traffic patterns to change in the near future... which means IPv4's usage will remain at high levels for some years. IPv6 traffic is still limited inside our network (and everywhere) in comparison to IPv4. And since we need to support our customer growth, we need to invest in IPv4 connectivity too for the time being. We already have started implementing an semi-automated way keeping DS-Lite "unfriendly" customers outside the CGN using our TR-069 platform, but it's getting more and more complicated as we dig into it. If PCP is the only way to solve this issue in the near future, then pushing our vendors to this direction (after it becomes a standard) is in the right direction. I was just hoping that other operators have already met and solved this issue. IPv6 is definitely the final and best solution and we are ready for it in most areas. We just need another (intermediate) solution for now, to keep customers happy and growing at the same time. -- Tassos Victor Kuarsingh wrote on 18/7/2012 20:24: > > On Wed, Jul 18, 2012 at 12:34 PM, Cameron Byrne > wrote: > > On Wed, Jul 18, 2012 at 9:29 AM, Tassos Chatzithomaoglou > > wrote: > > Hi, > > > > I'm looking for opinions and recommendations regarding the known limitations > > with incoming connections & port forwarding in CGN-like environments > > (preferably DS-Lite), in environments with multiple layers of NAT or when > > NAT is not taking place on the CPE. > > > All operators using CGN, how do you currently solve this problem? > > Any plans to write an informational RFC based on this? > > Or is PCP the only solution and everyone is waiting for it? > > > > Since this is the v6ops lists, the solution is don't invest in more > life support for IPv4. > > IPv6 does not have these problems. > > If your service is DS-lite, customers should have a very capable IPv6 > connection and they can receive incoming connection over IPv6. > > > I would tend to agree with Cameron here. Not sure how much support you will get on this > list to solve this IPv4 issue. > > This is one of the many issues with CGN. I would try an reach out to the vendors and > see if they have any specific capabilities on their platforms to incoming connections to > work, but the larger issue we saw when analyzing this was getting it to be automated > (customer portal, or other capability to set the port forwarding rules etc). > > We are waiting for PCP and have accepted the gap for now. > > Perhaps if you have some number of customers who need incoming port forwarding, then if > possible, keep them off CGN (you may not have that option). If the port forwarding is > required to support functions inside your network, you can try and by-pass the CGN (but > I had assumed you need this for general incoming connections which would originate > outside your network to your customers). > > regards, > > Victor K > > > CB > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > From Fred.L.Templin@boeing.com Wed Jul 18 11:19: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 3852011E8161 for ; Wed, 18 Jul 2012 11:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.96 X-Spam-Level: X-Spam-Status: No, score=-1.96 tagged_above=-999 required=5 tests=[AWL=-0.318, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, SARE_SUB_6CONS_WORD=0.356] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ufi1fT+jAxBS for ; Wed, 18 Jul 2012 11:18:59 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) by ietfa.amsl.com (Postfix) with ESMTP id 2780611E815C for ; Wed, 18 Jul 2012 11:18:59 -0700 (PDT) Received: from blv-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q6IIJnao004477 for ; Wed, 18 Jul 2012 11:19:49 -0700 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [130.247.228.54]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q6IIJmjH004462 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 18 Jul 2012 11:19:49 -0700 Received: from stl-av-01.boeing.com (localhost.localdomain [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q6IIJmFf020386; Wed, 18 Jul 2012 13:19:48 -0500 Received: from XCH-NWHT-04.nw.nos.boeing.com (xch-nwht-04.nw.nos.boeing.com [130.247.64.250]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q6IIJl2P020332 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 18 Jul 2012 13:19:48 -0500 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-04.nw.nos.boeing.com ([130.247.64.250]) with mapi; Wed, 18 Jul 2012 11:19:47 -0700 From: "Templin, Fred L" To: "Eric Vyncke (evyncke)" , "v6ops@ietf.org WG" Date: Wed, 18 Jul 2012 11:19:45 -0700 Thread-Topic: New version of draft-chkpvc-enterprise-incremental-ipv6-01 Thread-Index: Ac1k71m1KkcMdiAsRzSbD5XMS6AgrwAHrzyA Message-ID: References: <97EB7536A2B2C549846804BBF3FD47E1050E25@xmb-aln-x02.cisco.com> In-Reply-To: <97EB7536A2B2C549846804BBF3FD47E1050E25@xmb-aln-x02.cisco.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_E1829B60731D1740BB7A0626B4FAF0A65D8F55FC31XCHNW01Vnwnos_" MIME-Version: 1.0 X-TM-AS-MML: No Cc: "lee.howard@twcable.com" , "victor.kuarsingh@rci.rogers.com" Subject: Re: [v6ops] New version of draft-chkpvc-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: Wed, 18 Jul 2012 18:19:00 -0000 --_000_E1829B60731D1740BB7A0626B4FAF0A65D8F55FC31XCHNW01Vnwnos_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Eric, Thank you for posting this document update. Boeing had some very early input into the IPng discussions which resulted in the publication of RFC168= 7 back in August 1994. That document cast doubts on the deployment of IPng in Enterprise networks for many good reasons that still apply today (except for OSI harmonization, of course). I think your document could spend a moment to examine the RFC1687 viewpoints and then explain what has changed in the past 18 years and how those changes may now be motivating Enterprise network operators to move forward with IPv6 deployment. From looking at your document, I think there may now be some new claims to be made (e.g., network virtualization consuming address space) but it would be useful to spend a moment to cast RFC1687 in a historic light if possible. I have several other comments which I would send to you in e-mail. Thanks - Fred fred.l.templin@boeing.com From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of E= ric Vyncke (evyncke) Sent: Wednesday, July 18, 2012 7:12 AM To: v6ops@ietf.org WG Cc: lee.howard@twcable.com; victor.kuarsingh@rci.rogers.com Subject: [v6ops] New version of draft-chkpvc-enterprise-incremental-ipv6-01 We have updated our I-D about IPv6 enterprise deployment based on the few c= omments that we have received: http://tools.ietf.org/html/draft-chkpvc-enterprise-incremental-ipv6-01 (abs= tract below) The chairmen were kind enough to put us on the agenda on Friday even with a= filename which does not include v6ops. Thanks in advance for any comment, -=E9ric, Yanick, KK, Tim, Lee & Victor 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. --_000_E1829B60731D1740BB7A0626B4FAF0A65D8F55FC31XCHNW01Vnwnos_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Eric,

 

Thank you for posting this document update. Boeing h= ad some very early

input into the IPng discussions which resulted in the publi= cation of RFC1687

back in August 1994. That document cast doubts on the deploy= ment of IPng

in Enterprise networks for many good reasons that still apply tod= ay (except

for OSI harmonization, of course).

 

I think your document could spe= nd a moment to examine the RFC1687

viewpoints and then explain what has change= d in the past 18 years and

how those changes may now be motivating Enterprise = network operators

to move forward with IPv6 deployment. From looking at your d= ocument,

I think there may now be some new claims to be made (e.g., network

virtu= alization consuming address space) but it would be useful to spend

a moment to= cast RFC1687 in a historic light if possible.

 

I have several other commen= ts which I would send to you in e-mail.

 

Thanks - Fred<= /p>

fred.l.templin@boeing= .com

 

= From:= v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Eric Vyncke (evyncke)
Sent: Wednesday, July 18, 2012 7:12 AM
= To: v6ops@ietf.org WG
Cc: lee.howard@twcable.com; victor.k= uarsingh@rci.rogers.com
Subject: [v6ops] New version of draft-chk= pvc-enterprise-incremental-ipv6-01

 

We have updated our= I-D about IPv6 enterprise deployment based on the few comments that we hav= e received:

http://tools.= ietf.org/html/draft-chkpvc-enterprise-incremental-ipv6-01 (abstract bel= ow)

 

<= p class=3DMsoNormal>The chairmen were kind enough to put us on the agenda o= n Friday even with a filename which does not include v6ops.

 

Thanks in advance for any comment,

 

-=E9ric, Yanick, KK, Ti= m, Lee & Victor

 =

Enterprise network administrators wor= ldwide are in various stages of

<= span style=3D'font-size:10.0pt;font-family:"Comic Sans MS";color:#365F91'>&= nbsp;  preparing for or deploying IPv6 into their networks.  The<= o:p>

   administrators face = different challenges than operators of Internet

   access providers, and have reasons for differen= t priorities.  The

 &nb= sp; overall problem for many administrators will be to offer Internet-=

   facing services over IPv= 6, 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 netw= ork environment and potentially an

   for ente= rprise network architects or administrators who may be faced

   with many of these challenges as t= hey consider their IPv6 support

<= span style=3D'font-size:10.0pt;font-family:"Comic Sans MS";color:#365F91'>&= nbsp;  strategies.

= --_000_E1829B60731D1740BB7A0626B4FAF0A65D8F55FC31XCHNW01Vnwnos_-- From evyncke@cisco.com Wed Jul 18 11:39: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 7EC4711E8132 for ; Wed, 18 Jul 2012 11:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.02 X-Spam-Level: X-Spam-Status: No, score=-10.02 tagged_above=-999 required=5 tests=[AWL=-0.378, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, SARE_SUB_6CONS_WORD=0.356] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GYFF98ZVVAJu for ; Wed, 18 Jul 2012 11:38:59 -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 32E1B11E807F for ; Wed, 18 Jul 2012 11:38:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=evyncke@cisco.com; l=17603; q=dns/txt; s=iport; t=1342636790; x=1343846390; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=oAy5MwYfd0gGyJYaX9kahLGM8GmpgR8Qvy2IaYs0Imw=; b=ZRJZygXTO+enQww/rxZtMBGZqGpK5IGuJpnC+h3N99IE4qMOVVtsFUGU gfCP91Zu9if3P20vDal6uT9PbsAy3YbZ/6OeJJC5BfFKxlGNb++i8PBPO 3bDjsNPW/uDWa45zfkfPGQVz7nx3I2zi6/9YS7fCxqFk82XO5YXk0A9ZV 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak8FAP4BB1CtJV2b/2dsb2JhbABFgkqtaAGJAYEHgiABAQEEEgEaRwUQAgEIEQQBAQsdBzIUCQgBAQQBDQUIGodrC513oDGLQBqFVWADiBiOP40QgWaCX4Ff X-IronPort-AV: E=Sophos;i="4.77,611,1336348800"; d="scan'208,217";a="103166671" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 18 Jul 2012 18:39:49 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q6IIdn1m031537 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 18 Jul 2012 18:39:49 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.178]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0283.003; Wed, 18 Jul 2012 13:39:49 -0500 From: "Eric Vyncke (evyncke)" To: "Templin, Fred L" , "v6ops@ietf.org WG" Thread-Topic: New version of draft-chkpvc-enterprise-incremental-ipv6-01 Thread-Index: Ac1k71m1KkcMdiAsRzSbD5XMS6AgrwAHrzyAAAGYfLA= Date: Wed, 18 Jul 2012 18:39:48 +0000 Message-ID: <97EB7536A2B2C549846804BBF3FD47E105144D@xmb-aln-x02.cisco.com> References: <97EB7536A2B2C549846804BBF3FD47E1050E25@xmb-aln-x02.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.185.70] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19050.000 x-tm-as-result: No--59.252200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_97EB7536A2B2C549846804BBF3FD47E105144Dxmbalnx02ciscocom_" MIME-Version: 1.0 Cc: "lee.howard@twcable.com" , "victor.kuarsingh@rci.rogers.com" Subject: Re: [v6ops] New version of draft-chkpvc-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: Wed, 18 Jul 2012 18:39:00 -0000 --_000_97EB7536A2B2C549846804BBF3FD47E105144Dxmbalnx02ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Fred As you, I do hope that things have changed since 1994 ;-) But, our I-D focus is more on the HOW than on the WHY or WHEN but anyway, w= e will add this reference for sure Thanks for your comment Regards -=E9ric From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] Sent: mercredi 18 juillet 2012 20:20 To: Eric Vyncke (evyncke); v6ops@ietf.org WG Cc: lee.howard@twcable.com; victor.kuarsingh@rci.rogers.com Subject: RE: New version of draft-chkpvc-enterprise-incremental-ipv6-01 Eric, Thank you for posting this document update. Boeing had some very early input into the IPng discussions which resulted in the publication of RFC168= 7 back in August 1994. That document cast doubts on the deployment of IPng in Enterprise networks for many good reasons that still apply today (except for OSI harmonization, of course). I think your document could spend a moment to examine the RFC1687 viewpoints and then explain what has changed in the past 18 years and how those changes may now be motivating Enterprise network operators to move forward with IPv6 deployment. From looking at your document, I think there may now be some new claims to be made (e.g., network virtualization consuming address space) but it would be useful to spend a moment to cast RFC1687 in a historic light if possible. I have several other comments which I would send to you in e-mail. Thanks - Fred fred.l.templin@boeing.com From: v6ops-bounces@ietf.org [mailto:v6ops-b= ounces@ietf.org] On Behalf Of Eric Vyncke (evyncke) Sent: Wednesday, July 18, 2012 7:12 AM To: v6ops@ietf.org WG Cc: lee.howard@twcable.com; victor.kuarsingh= @rci.rogers.com Subject: [v6ops] New version of draft-chkpvc-enterprise-incremental-ipv6-01 We have updated our I-D about IPv6 enterprise deployment based on the few c= omments that we have received: http://tools.ietf.org/html/draft-chkpvc-enterprise-incremental-ipv6-01 (abs= tract below) The chairmen were kind enough to put us on the agenda on Friday even with a= filename which does not include v6ops. Thanks in advance for any comment, -=E9ric, Yanick, KK, Tim, Lee & Victor 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. --_000_97EB7536A2B2C549846804BBF3FD47E105144Dxmbalnx02ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Fred

 

As you, I do hope that thin= gs have changed since 1994 ;-)

 

But, our I-D focus is more = on the HOW than on the WHY or WHEN but anyway, we will add this reference f= or sure

 

Thanks for your comment

 

Regards

 

-=E9ric

 

From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]
Sent: mercredi 18 juillet 2012 20:20
To: Eric Vyncke (evyncke); v6ops@ietf.org WG
Cc: lee.howard@twcable.com; victor.kuarsingh@rci.rogers.com
Subject: RE: New version of draft-chkpvc-enterprise-incremental-ipv6= -01

 

Eric,

&n= bsp;

Thank y= ou for posting this document update. Boeing had some very early<= /span>

input i= nto the IPng discussions which resulted in the publication of RFC1687<= /o:p>

back in= August 1994. That document cast doubts on the deployment of IPng

in Ente= rprise networks for many good reasons that still apply today (except

for OSI= harmonization, of course).

&n= bsp;

I think= your document could spend a moment to examine the RFC1687

viewpoi= nts and then explain what has changed in the past 18 years and

how tho= se changes may now be motivating Enterprise network operators

to move= forward with IPv6 deployment. From looking at your document,

I think= there may now be some new claims to be made (e.g., network

virtual= ization consuming address space) but it would be useful to spend=

a momen= t to cast RFC1687 in a historic light if possible.

&n= bsp;

I have = several other comments which I would send to you in e-mail.

&n= bsp;

Thanks = - Fred

fred.l.templin@boeing.com

&n= bsp;

From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Eric Vyncke (evyncke)
Sent: Wednesday, July 18, 2012 7:12 AM
To: v6ops@ietf.org WG
Cc: lee.howard@twcable.com= ; victor.kuarsingh@rci.rogers.com
Subject: [v6ops] New version of draft-chkpvc-enterprise-incremental-= ipv6-01

 

We have updated our I-D abo= ut IPv6 enterprise deployment based on the few comments that we have receiv= ed:

http://tools.ietf.o= rg/html/draft-chkpvc-enterprise-incremental-ipv6-01 (abstract below)

 

The chairmen were kind enou= gh to put us on the agenda on Friday even with a filename which does not in= clude v6ops.

 

Thanks in advance for any c= omment,

 

-=E9ric, Yanick, KK, Tim, L= ee & Victor

 

Enterprise network administ= rators worldwide are in various stages of

   preparing for = or deploying IPv6 into their networks.  The

   administrators= face different challenges than operators of Internet

   access provide= rs, and have reasons for different priorities.  The<= /p>

   overall proble= m for many administrators will be to offer Internet-

   facing service= s over IPv6, while continuing to support IPv4, and

   while introduc= ing IPv6 access within the enterprise IT network.  The

   overall transi= tion will take most networks from an IPv4-only

   environment to= a dual stack network environment and potentially an

   IPv6-only oper= ating mode.  This document helps provide a framework=

   for enterprise= network architects or administrators who may be faced

   with many of t= hese challenges as they consider their IPv6 support

   strategies.

--_000_97EB7536A2B2C549846804BBF3FD47E105144Dxmbalnx02ciscocom_-- From gert@space.net Wed Jul 18 12:09: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 926ED11E817F for ; Wed, 18 Jul 2012 12:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L4FeN6TlATBu for ; Wed, 18 Jul 2012 12:09:13 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id DFAF111E8150 for ; Wed, 18 Jul 2012 12:09:10 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 98684F8D38 for ; Wed, 18 Jul 2012 21:10:00 +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 7E1F5F8D36 for ; Wed, 18 Jul 2012 21:10:00 +0200 (CEST) Received: (qmail 46415 invoked by uid 1007); 18 Jul 2012 21:10:00 +0200 Date: Wed, 18 Jul 2012 21:10:00 +0200 From: Gert Doering To: Tassos Chatzithomaoglou Message-ID: <20120718191000.GW38127@Space.Net> References: <5006E47F.8010605@forthnetgroup.gr> <5006FE33.7090903@forthnetgroup.gr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5006FE33.7090903@forthnetgroup.gr> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] current solutions for incoming connections in CGN environments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 Jul 2012 19:09:13 -0000 Hi, On Wed, Jul 18, 2012 at 09:19:31PM +0300, Tassos Chatzithomaoglou wrote: > IPv6 is definitely the final and best solution and we are ready for it in most areas. We > just need another (intermediate) solution for now, to keep customers happy and growing at > the same time. There is no way to make the customers happy with IPv4+CGN. 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 achatz@forthnetgroup.gr Wed Jul 18 13:32: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 1E97A21F85CC for ; Wed, 18 Jul 2012 13:32:39 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0BjroaRDbchh for ; Wed, 18 Jul 2012 13:32:38 -0700 (PDT) Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.107]) by ietfa.amsl.com (Postfix) with ESMTP id DF89321F85C5 for ; Wed, 18 Jul 2012 13:32:37 -0700 (PDT) Received: from mx-av-05.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-04.forthnet.gr (8.14.4/8.14.4) with ESMTP id q6IKXRUk012113; Wed, 18 Jul 2012 23:33:27 +0300 Received: from MX-IN-04.forthnet.gr (mx-in-04.forthnet.gr [193.92.150.163]) by mx-av-05.forthnet.gr (8.14.4/8.14.4) with ESMTP id q6IKXRCE020985; Wed, 18 Jul 2012 23:33:27 +0300 Received: from [192.168.1.2] (77.49.140.157.dsl.dyn.forthnet.gr [77.49.140.157]) (authenticated bits=0) by MX-IN-04.forthnet.gr (8.14.4/8.14.4) with ESMTP id q6IKXHaJ032422; Wed, 18 Jul 2012 23:33:18 +0300 Authentication-Results: MX-IN-04.forthnet.gr smtp.mail=achatz@forthnetgroup.gr; auth=pass (PLAIN) Message-ID: <50071D89.9070601@forthnetgroup.gr> Date: Wed, 18 Jul 2012 23:33:13 +0300 From: Tassos Chatzithomaoglou User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120615 Firefox/13.0.1 SeaMonkey/2.10.1 MIME-Version: 1.0 To: Gert Doering References: <5006E47F.8010605@forthnetgroup.gr> <5006FE33.7090903@forthnetgroup.gr> <20120718191000.GW38127@Space.Net> In-Reply-To: <20120718191000.GW38127@Space.Net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] current solutions for incoming connections in CGN environments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 Jul 2012 20:32:39 -0000 Gert, i'm more than open to proposals. Our IPv6 is completed, our DS-Lite will be completed soon, our customers are growing, our IPv4 addresses will be over soon...and IPv4 content (and traffic?) is still ~99%. Am i missing something obvious? I'm a fanatic supporter of IPv6, but as long as IPv6-only solutions do not cover us (and our customers), we'll have to keep investing on IPv6 + IPv4. We could very easily have chosen the IPv4-only way of doing CGN things, but we chose DS-Lite in order to prepare for the future. If there is a better solution (currently available), i'm more than happy to discuss it (broadcast or unicast). Unless, if buying IPv4 addresses is considered a better solution. But then you avoid CGN and IPv6. -- Tassos Gert Doering wrote on 18/7/2012 22:10: > Hi, > > On Wed, Jul 18, 2012 at 09:19:31PM +0300, Tassos Chatzithomaoglou wrote: >> IPv6 is definitely the final and best solution and we are ready for it in most areas. We >> just need another (intermediate) solution for now, to keep customers happy and growing at >> the same time. > There is no way to make the customers happy with IPv4+CGN. > > Gert Doering > -- NetMaster From gert@space.net Wed Jul 18 13:38: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 5DE8411E80AA for ; Wed, 18 Jul 2012 13:38:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AoQx-RhpEbJd for ; Wed, 18 Jul 2012 13:38:13 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2F6AE11E814A for ; Wed, 18 Jul 2012 13:38:12 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id F0920F8D34 for ; Wed, 18 Jul 2012 22:39:02 +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 D5F85F8D35 for ; Wed, 18 Jul 2012 22:39:02 +0200 (CEST) Received: (qmail 88026 invoked by uid 1007); 18 Jul 2012 22:39:02 +0200 Date: Wed, 18 Jul 2012 22:39:02 +0200 From: Gert Doering To: Tassos Chatzithomaoglou Message-ID: <20120718203902.GY38127@Space.Net> References: <5006E47F.8010605@forthnetgroup.gr> <5006FE33.7090903@forthnetgroup.gr> <20120718191000.GW38127@Space.Net> <50071D89.9070601@forthnetgroup.gr> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tE5k6OWzvhsAuKlL" Content-Disposition: inline In-Reply-To: <50071D89.9070601@forthnetgroup.gr> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] current solutions for incoming connections in CGN environments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 18 Jul 2012 20:38:14 -0000 --tE5k6OWzvhsAuKlL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Wed, Jul 18, 2012 at 11:33:13PM +0300, Tassos Chatzithomaoglou wrote: > Gert, i'm more than open to proposals. > Our IPv6 is completed, our DS-Lite will be completed soon, our customers = are growing, our=20 > IPv4 addresses will be over soon...and IPv4 content (and traffic?) is sti= ll ~99%. > Am i missing something obvious? You'll be surprised how much traffic google and facebook create, as soon as your access customers have ipv6-on-by-default. Much more than 1%. But when talking about NAT and "mapping ports back to your customers", it's fully and totally irrelevant how much content is there on IPv6 - if it's "I want to connect home!", having the customer on IPv6 is sufficient, it doesn't matter whether www.somebigsite.com needs to go through an IPv4 NAT444 or other abominations. 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 --tE5k6OWzvhsAuKlL Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iQCVAwUBUAce5qkuBuNlUUl1AQJkyAP/eohhRfMc+wx1b/SPltofJC4YyjKMUcxj 3Gw+XhHPDCg2sjI7m6w73evo5ZuDPkRhRCZqOtm1YrncexgZSab8rZ0HVBYuuRsk +P8mJkTmK0upebshu3H37SDH7DN+DY5F7KDn0jnXuvsfUSSLhzkQcPwvT0jyv27c +3Xxp1VjmvY= =Xv1h -----END PGP SIGNATURE----- --tE5k6OWzvhsAuKlL-- From tore.anderson@redpill-linpro.com Wed Jul 18 22:58: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 503B221F854B for ; Wed, 18 Jul 2012 22:58:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SbZWgXGHABfT for ; Wed, 18 Jul 2012 22:58:10 -0700 (PDT) Received: from zimbra.redpill-linpro.com (zimbra.redpill-linpro.com [87.238.49.234]) by ietfa.amsl.com (Postfix) with ESMTP id 1317E21F8535 for ; Wed, 18 Jul 2012 22:58:09 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.redpill-linpro.com (Postfix) with ESMTP id 8AFCD182000E; Thu, 19 Jul 2012 07:59:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at claudius.linpro.no Received: from zimbra.redpill-linpro.com ([127.0.0.1]) by localhost (zimbra.redpill-linpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rVG+aQ83x7Ju; Thu, 19 Jul 2012 07:59:00 +0200 (CEST) Received: from echo.linpro.no (echo.linpro.no [87.238.42.42]) by zimbra.redpill-linpro.com (Postfix) with ESMTPSA id 09A221820005; Thu, 19 Jul 2012 07:59:00 +0200 (CEST) Message-ID: <5007A223.1090003@redpill-linpro.com> Date: Thu, 19 Jul 2012 07:58:59 +0200 From: Tore Anderson Organization: Redpill Linpro AS User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Tassos Chatzithomaoglou References: <5006E47F.8010605@forthnetgroup.gr> <5006FE33.7090903@forthnetgroup.gr> <20120718191000.GW38127@Space.Net> <50071D89.9070601@forthnetgroup.gr> In-Reply-To: <50071D89.9070601@forthnetgroup.gr> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] current solutions for incoming connections in CGN environments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 19 Jul 2012 05:58:11 -0000 Hi Tassos, * Tassos Chatzithomaoglou > Gert, i'm more than open to proposals. > Our IPv6 is completed, our DS-Lite will be completed soon, our customers > are growing, our IPv4 addresses will be over soon...and IPv4 content > (and traffic?) is still ~99%. > Am i missing something obvious? No. If it's any consolation, it's not only you - we're all in the same shitty situation. By deploying IPv6 you are way ahead of most people in dealing with it though, congratulations! That said, according to Google's statistics at http://www.google.com/ipv6/statistics.html#tab=per-country-ipv6-adoption there are essentially no IPv6 traffic seen from Greece, which is odd as Forthnet is a large source of Greek eyeball traffic (second only to OTE in my netflow stats). Is your IPv6 implementation inside a walled garden or is there any other reason why it isn't show up in public stats like Google's? > I'm a fanatic supporter of IPv6, but as long as IPv6-only solutions do > not cover us (and our customers), we'll have to keep investing on IPv6 + > IPv4. > We could very easily have chosen the IPv4-only way of doing CGN things, > but we chose DS-Lite in order to prepare for the future. > If there is a better solution (currently available), i'm more than happy > to discuss it (broadcast or unicast). I suggest you look into the MAP/4RD stuff. Like DS-Lite and NAT444, it facilitates IPv4 address sharing between subscribers, but it does it without a CGN component - each subscriber gets an official IPv4 address routed all the way to his CPE like today, but a limited set of TCP/UDP ports. From this port range, the user can set up port forwardings using UPnP or manual CPE config just like he can today. You can also, if I understand correctly, provision an "entire" IPv4 address over MAP/4RD too, for example as a "premium" paid-for service for customers who insist on having specific well-known ports available to them. MAP rides on top of IPv6 in much the same way as DS-Lite, so since you've already implemented IPv6, you've already done with the hard part. Another very nice thing about it compared to DS-Lite is that it is entirely stateless in the core (just simple NAT44 in the CPEs like today). I think it fails your «currently available» criteria, though. But... > Unless, if buying IPv4 addresses is considered a better solution. But > then you avoid CGN and IPv6. ...the RIPE NCC still has more than 10 million IPv4 addresses in its free pool, and you can still allocate normally from it. So by making an allocation now, you will have bought yourself three months of time before you have to light up your DS-Lite CGN, in which you can wait for (or even better - help finalise!) PCP and/or MAP. I wouldn't abandon DS-Lite though, having a contingency plan ready to go the moment you need it is certainly smart. I don't understand why a strategy of buying IPv4 addresses instead of deploying any IPv4 address sharing solution would make you «avoid IPv6», though. IPv4 life-support and IPv6 deployments seem orthogonal to me, except that the former may benefit from the latter in the case of DS-Lite, MAP, and similar. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com From Tina.Tsou.Zouting@huawei.com Wed Jul 18 23:23: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 A62D921F865A for ; Wed, 18 Jul 2012 23:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.662 X-Spam-Level: X-Spam-Status: No, score=-5.662 tagged_above=-999 required=5 tests=[AWL=0.337, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jyPumGxTLnxZ for ; Wed, 18 Jul 2012 23:23:58 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD3321F852D for ; Wed, 18 Jul 2012 23:23:58 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHW70451; Thu, 19 Jul 2012 02:24:50 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 18 Jul 2012 23:22:15 -0700 Received: from DFWEML513-MBS.china.huawei.com ([169.254.4.5]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.003; Wed, 18 Jul 2012 23:22:18 -0700 From: Tina TSOU To: "Fred Baker (fred)" , Ron Bonica Thread-Topic: draft-ietf-v6ops-wireline-incremental-ipv6 to Informational Thread-Index: AQHNX4mYQTpJm8o3QUq6U4hP+CMi45cwLjoQ Date: Thu, 19 Jul 2012 06:22:17 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.243] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-ietf-v6ops-wireline-incremental-ipv6@tools.ietf.org" , IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-wireline-incremental-ipv6 to Informational X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 19 Jul 2012 06:23:59 -0000 The document is a good guide for anyone preparing to deploy IPv6 in their n= etworks. It describes the transition methods, highlighting its pros and con= s. However, in the discussion of NAT64 analysis, it is mentioned ipv6 only = clients and hosts to IPv4 servers. In my opinion, the reverse case, IPv4 on= ly host and IPv6 server can be included. Though this possibility is less, I= guess when all details of the other transition technologies are discussed,= it would be good to add this. In the discussion of Phase 0: Foundation: To= ols and Management, the requirement of the monitoring tools to be updated w= ith IPv6 capable and both IPv4/IPv6 simultaneously can be included in the d= iscussion. In the phase 1: tunneled IPv6, 6rd is discussed very well. In my= opinion, there can be a brief discussion of various ways of tunneling: ( I= SATAP, manual, 6to4, GRE,) or just a reference to which draft should be ref= erred to for further information about these tunneling options. Moreover, i= t is mentioned not all applications will be efficiently delivered in the tu= nneling approach, as the MTU reduces. Few examples of the applications that= are less affected by tunneling and applications that should not be tunnele= d would be helpful. The rest of the document is very well illustrated and = documented. Tina > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Fred Baker (fred) > Sent: Wednesday, July 11, 2012 10:21 AM > To: Ron Bonica > Cc: draft-ietf-v6ops-wireline-incremental-ipv6@tools.ietf.org; IPv6 Ops > WG > Subject: [v6ops] draft-ietf-v6ops-wireline-incremental-ipv6 to > Informational >=20 >=20 > (1) What type of RFC is being requested (BCP, Proposed Standard, > Internet Standard, Informational, Experimental, or Historic)? Why is > this the proper type of RFC? Is this type of RFC indicated in the title > page header? >=20 > This document is recommended as "informational"; it is essentially a > white paper describing a phased approach to operational deployment of > IPv6. >=20 > (2) The IESG approval announcement includes a Document Announcement > Write-Up. Please provide such a Document Announcement Write-Up. Recent > examples can be found in the "Action" announcements for approved > documents. The approval announcement contains the following sections: >=20 > Technical Summary >=20 > 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. >=20 > Working Group Summary >=20 > 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. >=20 > Document Quality >=20 > The framework is well written and has stood up under review. >=20 > Personnel >=20 > Who is the Document Shepherd? Who is the Responsible Area Director? >=20 > The Document Shepherd is Fred Baker. The Responsible AD is Ron Bonica. >=20 > (3) Briefly describe the review of this document that was performed by > the Document Shepherd. If this version of the document is not ready for > publication, please explain why the document is being forwarded to the > IESG. >=20 > The shepherd read the initial document, followed the working group > discussion and spoke with the authors privately, and read the ultimate > outcome. The document is clear and understandable. >=20 > (4) Does the document Shepherd have any concerns about the depth or > breadth of the reviews that have been performed? >=20 > No. The acknowledgements section notes a number of people who have > commented or contributed text. >=20 > (5) Do portions of the document need review from a particular or from > broader perspective, e.g., security, operational complexity, AAA, DNS, > DHCP, XML, or internationalization? If so, describe the review that > took place. >=20 > This is not, in my view, required. The document contains no formal > language, and imposes no protocol specifics. >=20 > (6) Describe any specific concerns or issues that the Document Shepherd > has with this document that the Responsible Area Director and/or the > IESG should be aware of? For example, perhaps he or she is > uncomfortable with certain parts of the document, or has concerns > whether there really is a need for it. In any event, if the WG has > discussed those issues and has indicated that it still wishes to > advance the document, detail those concerns here. >=20 > The shepherd is comfortable with the document, and working group > discussion has not surfaced remaining issues. >=20 > (7) Has each author confirmed that any and all appropriate IPR > disclosures required for full conformance with the provisions of BCP 78 > and BCP 79 have already been filed. If not, explain why. >=20 > Yes. >=20 > (8) Has an IPR disclosure been filed that references this document? If > so, summarize any WG discussion and conclusion regarding the IPR > disclosures. >=20 > Not to my knowledge. >=20 > (9) How solid is the WG consensus behind this document? Does it > represent the strong concurrence of a few individuals, with others > being silent, or does the WG as a whole understand and agree with it? >=20 > As noted in the acknowledgements, working group discussion was robust > and broad. I would describe this as having broad consensus. >=20 > (10) Has anyone threatened an appeal or otherwise indicated extreme > discontent? If so, please summarise the areas of conflict in separate > email messages to the Responsible Area Director. (It should be in a > separate email because this questionnaire is publicly available.) >=20 > No. >=20 > (11) Identify any ID nits the Document Shepherd has found in this > document. (See http://www.ietf.org/tools/idnits/ and the Internet- > Drafts Checklist). Boilerplate checks are not enough; this check needs > to be thorough. >=20 > I found no nits. >=20 > (12) Describe how the document meets any required formal review > criteria, such as the MIB Doctor, media type, and URI type reviews. >=20 > N/A >=20 > (13) Have all references within this document been identified as either > normative or informative? >=20 > The references are list as normative and informative. >=20 > (14) Are there normative references to documents that are not ready for > advancement or are otherwise in an unclear state? If such normative > references exist, what is the plan for their completion? >=20 > There are no such references. >=20 > (15) Are there downward normative references references (see RFC 3967)? > If so, list these downward references to support the Area Director in > the Last Call procedure. >=20 > An informational document cannot have downward references. >=20 > (16) Will publication of this document change the status of any > existing RFCs? Are those RFCs listed on the title page header, listed > in the abstract, and discussed in the introduction? If the RFCs are not > listed in the Abstract and Introduction, explain why, and point to the > part of the document where the relationship of this document to the > other RFCs is discussed. If this information is not in the document, > explain why the WG considers it unnecessary. >=20 > This document uses other RFCs, but does not update them. >=20 > (17) Describe the Document Shepherd's review of the IANA considerations > section, especially with regard to its consistency with the body of the > document. Confirm that all protocol extensions that the document makes > are associated with the appropriate reservations in IANA registries. > Confirm that any referenced IANA registries have been clearly > identified. Confirm that newly created IANA registries include a > detailed specification of the initial contents for the registry, that > allocations procedures for future registrations are defined, and a > reasonable name for the new registry has been suggested (see RFC 5226). >=20 > The document doesn't depend on IANA registries or create new ones. >=20 > (18) List any new IANA registries that require Expert Review for future > allocations. Provide any public guidance that the IESG would find > useful in selecting the IANA Experts for these new registries. >=20 > N/A >=20 > (19) Describe reviews and automated checks performed by the Document > Shepherd to validate sections of the document written in a formal > language, such as XML code, BNF rules, MIB definitions, etc. >=20 > N/A > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From lorenzo@google.com Thu Jul 19 01:15: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 A287821F867E for ; Thu, 19 Jul 2012 01:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.773 X-Spam-Level: X-Spam-Status: No, score=-102.773 tagged_above=-999 required=5 tests=[AWL=0.202, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3iSWSuWhu5pZ for ; Thu, 19 Jul 2012 01:15:01 -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 9EF5521F866A for ; Thu, 19 Jul 2012 01:15:00 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so3937231obb.31 for ; Thu, 19 Jul 2012 01:15: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=7YrbbS4m51gXG8GWd+t3VrKGhP6s88WkjVFOD6ihh94=; b=hDuhipHD0kATb9HGwWxNydI2bTizexv5VdN5FTEWu2u6udhp0uyFrVS/ZoCGON6ix6 tst8uk5CWagUrG/OyfKTYxIWkBgUFr6V3NM0sl+fTT93uuv8Efrz+ajeeI+0AcNos8mp cgifGjptPb2MEibizXXtx5BXfMqopFCvZcIh6SqjGP7QbhboN+jdTRSGDoZjT+u32kUV TsssV8bzlbMVaAiMZ/ksm0lu37uc/Blrg/eWDcDtv4NyZZWoWDKfQ5tRzZJBedoHYIuK Dzoh1+YvdOyDaqWm5rxAfCmalQm1QRPYjcyxjQSoNFZURUwoUFN15YfZxt+0hEtLm/4f 6j8w== 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=7YrbbS4m51gXG8GWd+t3VrKGhP6s88WkjVFOD6ihh94=; b=eCU4ens4JmkkIQ2vpfSjJw8f3LiQZjS2jgG8dniPajKLcIaRdnH4f/Yx8Cj9s7SxjZ KN7mIyDhFaHSBtDUC6bZOu+vCtlD+7h2Nz52sk9ZvzDYL7fdX6eMOsadIRsqr03hS+Cb QqGDMf8ZsNi09xpWyAGHq40EXWmN46rbwxxRamjW6+L09+sq2b1NqspcebN5Oof/ZcqM caitOpM/vL59m+GRreCtkOTDu2P5MiZAjgGLZC8xnyYQBGN8YPIzYuZ5FnnXF4L+NXlL oieysNxHvrWH9KueyAPtdKHNABfmxWxHD32H4R84v4m7Uqe3Gq3bK0nLVuRIEivFyq8b Xrng== Received: by 10.182.119.72 with SMTP id ks8mr1276146obb.10.1342685752993; Thu, 19 Jul 2012 01:15:52 -0700 (PDT) Received: by 10.182.119.72 with SMTP id ks8mr1276111obb.10.1342685752644; Thu, 19 Jul 2012 01:15:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.157.111 with HTTP; Thu, 19 Jul 2012 01:15:31 -0700 (PDT) In-Reply-To: <50071D89.9070601@forthnetgroup.gr> References: <5006E47F.8010605@forthnetgroup.gr> <5006FE33.7090903@forthnetgroup.gr> <20120718191000.GW38127@Space.Net> <50071D89.9070601@forthnetgroup.gr> From: Lorenzo Colitti Date: Thu, 19 Jul 2012 17:15:31 +0900 Message-ID: To: Tassos Chatzithomaoglou Content-Type: multipart/alternative; boundary=f46d04451a0154d3a704c52a630d X-System-Of-Record: true X-Gm-Message-State: ALoCoQmPe+pPs3eHZNDGrqZ1ZM/DImzeDJoxkPUjb//VFS11zysQTv3/PdcrsawuKeV8PHHujRMUBu7Shi5LaWhYz34CQCs8KTv8rH1x8FpakiHJ8WYDrJvnz8/Ki5RWseTRYUogg7ZPLVTMn0tCLorLtbXOLF0znUwPtFJmKXJO17mAqyZnxkQ= Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] current solutions for incoming connections in CGN environments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 19 Jul 2012 08:15:02 -0000 --f46d04451a0154d3a704c52a630d Content-Type: text/plain; charset=ISO-8859-7 Content-Transfer-Encoding: quoted-printable On Thu, Jul 19, 2012 at 5:33 AM, Tassos Chatzithomaoglou < achatz@forthnetgroup.gr> wrote: > Our IPv6 is completed, our DS-Lite will be completed soon, our customers > are growing, our IPv4 addresses will be over soon...and IPv4 content (and > traffic?) is still ~99%. > Am i missing something obvious? > Yes, you are. If your IPv4 traffic is 99%, then your IPv6 project is not "completed". There is much more than 1% of content and traffic on IPv6. As AT&T says: "For our IPv6 enabled customers, we=A2re seeing more than 20 percent of traffic transition to IPv6": http://www.attinnovationspace.com/innovation/story/a7782696 . If you don't have enough IPv6 traffic, you probably haven't deployed IPv6 to enough users. One solution to your problem is as follows: 1. Deploy IPv6 to a large percentage of your users 2. Take away the public IPv4 addresses for those users and put them behind a NAT. If a user wants inbound connectivity (and many probably don't know they do, or don't care), then give them a public IPv4 address (either for free or for an extra fee). This appears to be what AT&T is doing: public numbers suggest that they have more than 4% of IPv6 users, and there are hints on the forums that they are asking their customers to renumber their internal networks out of 10/8 (which suggests carrier-operated NAT). So before you tell us why this is impossible and will never work, bear in mind that one of the largest ISPs in the world is doing it :-) Regards, Lorenzo --f46d04451a0154d3a704c52a630d Content-Type: text/html; charset=ISO-8859-7 Content-Transfer-Encoding: quoted-printable
On Thu, Jul 19, 2012 at 5:33 AM, Tassos Chatzith= omaoglou <achatz@forthnetgroup.gr> wrote:
Our IPv6 is completed, our DS-Lite will be completed soon, our customers ar= e growing, our IPv4 addresses will be over soon...and IPv4 content (and tra= ffic?) is still ~99%.
Am i missing something obvious?

Yes, yo= u are. If=A0your IPv4 traffic is 99%, then your IPv6 project is not "c= ompleted".=A0There is much more than 1% of content and traffic on IPv6= . As AT&T says: "For our IPv6 enabled customers, we=A2re seeing mo= re than 20 percent of traffic transition to IPv6":=A0http://www.attinnova= tionspace.com/innovation/story/a7782696 . If you don't have enough = IPv6 traffic, you probably haven't deployed IPv6 to enough users.

One solution to your problem is as follows:
<= br>
1. Deploy IPv6 to a large percentage of your users
= 2. Take away the public IPv4 addresses for those users and put them behind = a NAT.

If a user wants inbound connectivity (and many probably= don't know they do, or don't care), then give them a public IPv4 a= ddress (either for free or for an extra fee).

This appears to be what AT&T is doing: public numbers suggest that they= have more than 4% of IPv6 users, and there are hints on the forums that th= ey are asking their customers to renumber their internal networks out of 10= /8 (which suggests carrier-operated NAT).

So before you tell us why this is impossible and will n= ever work, bear in mind that one of the largest ISPs in the world is doing = it :-)

Regards,
Lorenzo
--f46d04451a0154d3a704c52a630d-- From fgont@si6networks.com Thu Jul 19 05: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 5A5F521F8738; Thu, 19 Jul 2012 05:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.458 X-Spam-Level: X-Spam-Status: No, score=-1.458 tagged_above=-999 required=5 tests=[AWL=-0.528, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4h5xiWJVG-M; Thu, 19 Jul 2012 05:54:49 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 728E521F8736; Thu, 19 Jul 2012 05:54:49 -0700 (PDT) Received: from bl10-131-211.dsl.telepac.pt ([85.243.131.211] helo=[192.168.1.84]) by web01.jbserver.net with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1SrqGX-0001LD-A3; Thu, 19 Jul 2012 14:55:37 +0200 Message-ID: <5007643C.9050003@si6networks.com> Date: Thu, 19 Jul 2012 02:34:52 +0100 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: "Eric Vyncke (evyncke)" References: <97EB7536A2B2C549846804BBF3FD47E1050EC5@xmb-aln-x02.cisco.com> In-Reply-To: <97EB7536A2B2C549846804BBF3FD47E1050EC5@xmb-aln-x02.cisco.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org WG" , "opsec@ietf.org" , Merike Kaeo Subject: Re: [v6ops] New updated version of draft-vyncke-opsec-v6-01 (Operational Security Considerations for IPv6 Networks) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 19 Jul 2012 12:54:50 -0000 Hi, Eric (et al), I think this document is filling an existing gap. Thanks for writing it! I've begun to read your I-D. I'll be sending some feedback in batches, since it will likely result in more timely feedback. Abstract: I wouldn't go as far as saying that "RFC 4942 describes the security issues in the protocol". Introduction: The I-D says "Network Address and Port Translation [RFC3022] has lead to the common feeling that NATPT equals security and with IPv6 NATPT is no more needed." A side effect of NATPT is that the *device* ends up operating as a stateful firewall that only allows return traffic. I'd personally find it challenging (?) to find a term for which one could claim "X equals security" (since there are many aspects of security, which can hardly be addressed by a single "device"). However, I'd note that there are security properties in firewalls (which a NATPT ends up acting as, as a side effect). Regarding "IPv6 NATPT", I seem to recall that it already ships with Linux? Nits: Section 2.1.1: "Once an address allocation has been assigned" This doesn't seem to parse well. Section 2.1.1: You should probably clarify that, when talking about "manually configured addresses", you're talking about devices (e.g. routers) that typically have their addresses manually-configured, and *not* encouraging manually-configured addresses in general devices. Section 2.1.2: I don't recall the details of the discussion regarding ULAs, but would guess that some have probably argued that they may make troubleshooting painful? Section 2.1.3: This section should probably reference draft-ietf-v6ops-v6nd-problems, since using /112 also works as a workaround for buggy implementations that fail to properly manage the Neighbor Cache. Some slideware I've used recently (e.g. , ) might be of help, too. Section 2.1.4: This section should reference RFC4941 rather than RFC3041. You may want to reference draft-gont-opsec-ipv6-host-scanning. Nit: s/know/known/ This section says "Privacy addressing attempts to mitigate this threat". However, privacy addresses are typically (*) configured *in addition* to IEEE-derived IIDS -- hence they do not mitigate the host scanning problem. draft-ietf-6man-stable-privacy-addresses does, since they are meant to replace the IEEE-derived IIDs. (*) with the notable exception of OpenBSD, which removes IEEE-derived IIDs when privacy addresses are enabled. This section says "While privacy addresses are truly generated randomly to protect against user tracking, but assuming that nodes use the EUI-64 format for global addressing, a list of expected pre-authorized host addresses can be generated." I don't follow... for outgoing connections, hosts would employ privacy addresses, so... Section 2.2: Nits: s/relied/relies/ s/not he/on the/ Section 2.2.1: You should probably note the many reasons for which SEND is challenging to deploy (PKI, not widely implemented, etc.) Additionally, as noted in draft-ietf-6man-nd-extension-headers, if you end up relying on fragmentation (which you shouldn't!), it could be possible for an attacker to circumvent SEND. Section 2.2.2: You may want to look at/reference: draft-gont-opsec-dhcpv6-shield. Section 2.2.3: Nit: s/DOS/DoS/ Section 2.2.4: The I-D says "However, several evasion techniques that circumvent the protection provided by RA Guard have surfaced. A key challenge to this mitigation technique is introduced by IPv6 fragmentation." Note that for existing implementations, you do not even need to use fragmentation: these RA-Guard implementations simply expect the ICMPv6 to follow the fixed IPv6 header -- hence simply including any IPv6 extension header is enough to circumvent them. [I-D.gont-6man-nd-extension-headers] should now be [I-D.ietf-6man-nd-extension-headers] ;-) Ok, 2:33 AM... more on this later.... ;-) Cheers, Fernando On 07/18/2012 03:34 PM, Eric Vyncke (evyncke) wrote: > We have posted a new version of our draft draft-vyncke-opsec-v6 at: > > http://tools.ietf.org/html/draft-vyncke-opsec-v6-01 > > > > As usual comments are welcome, at Paris, comments were ‘yes this is > required’. BTW, the intent is not to write 100’s of pages but rather > document existing I-D and good practices. > > > > Best regards > > > > -merike, kk and éric > > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From achatz@forthnetgroup.gr Thu Jul 19 13:31: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 C9E2721F86AD for ; Thu, 19 Jul 2012 13:31:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.113 X-Spam-Level: X-Spam-Status: No, score=-2.113 tagged_above=-999 required=5 tests=[AWL=0.486, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cZDvp74FAmCK for ; Thu, 19 Jul 2012 13:31:09 -0700 (PDT) Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.107]) by ietfa.amsl.com (Postfix) with ESMTP id 9365121F8634 for ; Thu, 19 Jul 2012 13:31:08 -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 q6JKW0VV000636; Thu, 19 Jul 2012 23:32:00 +0300 Received: from MX-IN-11.forthnet.gr (mx-in-11.forthnet.gr [193.92.150.31]) by mx-av-03.forthnet.gr (8.14.3/8.14.3) with ESMTP id q6JKW00X025407; Thu, 19 Jul 2012 23:32:00 +0300 Received: from [62.1.48.75] (achatz.forthnet.gr [62.1.48.75]) (authenticated bits=0) by MX-IN-11.forthnet.gr (8.14.4/8.14.4) with ESMTP id q6JKVxCG020745; Thu, 19 Jul 2012 23:31:59 +0300 Authentication-Results: MX-IN-11.forthnet.gr smtp.mail=achatz@forthnetgroup.gr; auth=pass (PLAIN) Message-ID: <50086EBB.7090300@forthnetgroup.gr> Date: Thu, 19 Jul 2012 23:31:55 +0300 From: Tassos Chatzithomaoglou Organization: Forthnet User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120615 Firefox/13.0.1 SeaMonkey/2.10.1 MIME-Version: 1.0 To: Tore Anderson References: <5006E47F.8010605@forthnetgroup.gr> <5006FE33.7090903@forthnetgroup.gr> <20120718191000.GW38127@Space.Net> <50071D89.9070601@forthnetgroup.gr> <5007A223.1090003@redpill-linpro.com> In-Reply-To: <5007A223.1090003@redpill-linpro.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] current solutions for incoming connections in CGN environments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 19 Jul 2012 20:31:09 -0000 Tore Anderson wrote on 19/07/2012 08:58: > Hi Tassos, > > * Tassos Chatzithomaoglou > >> Gert, i'm more than open to proposals. >> Our IPv6 is completed, our DS-Lite will be completed soon, our customers >> are growing, our IPv4 addresses will be over soon...and IPv4 content >> (and traffic?) is still ~99%. >> Am i missing something obvious? > No. If it's any consolation, it's not only you - we're all in the same > shitty situation. By deploying IPv6 you are way ahead of most people in > dealing with it though, congratulations! > > That said, according to Google's statistics at > http://www.google.com/ipv6/statistics.html#tab=per-country-ipv6-adoption > there are essentially no IPv6 traffic seen from Greece, which is odd as > Forthnet is a large source of Greek eyeball traffic (second only to OTE > in my netflow stats). Is your IPv6 implementation inside a walled garden > or is there any other reason why it isn't show up in public stats like > Google's? We enable IPv6 on CPEs in batches (we've met many strange issues in our pilot and we want to be careful), so it will take a while until we have a considerable amount of traffic shown there. At the same time we are testing (and enhancing) our IPv6 address allocation system, so we cannot move very fast, unless everything is working fine. > >> I'm a fanatic supporter of IPv6, but as long as IPv6-only solutions do >> not cover us (and our customers), we'll have to keep investing on IPv6 + >> IPv4. >> We could very easily have chosen the IPv4-only way of doing CGN things, >> but we chose DS-Lite in order to prepare for the future. >> If there is a better solution (currently available), i'm more than happy >> to discuss it (broadcast or unicast). > I suggest you look into the MAP/4RD stuff. Like DS-Lite and NAT444, it > facilitates IPv4 address sharing between subscribers, but it does it > without a CGN component - each subscriber gets an official IPv4 address > routed all the way to his CPE like today, but a limited set of TCP/UDP > ports. From this port range, the user can set up port forwardings using > UPnP or manual CPE config just like he can today. You can also, if I > understand correctly, provision an "entire" IPv4 address over MAP/4RD > too, for example as a "premium" paid-for service for customers who > insist on having specific well-known ports available to them. > > MAP rides on top of IPv6 in much the same way as DS-Lite, so since > you've already implemented IPv6, you've already done with the hard part. > Another very nice thing about it compared to DS-Lite is that it is > entirely stateless in the core (just simple NAT44 in the CPEs like today). > > I think it fails your «currently available» criteria, though. But... MAP/4RD will probably take a while until it gets into CPEs. DS-Lite, which is older, got in very recently. >> Unless, if buying IPv4 addresses is considered a better solution. But >> then you avoid CGN and IPv6. > ...the RIPE NCC still has more than 10 million IPv4 addresses in its > free pool, and you can still allocate normally from it. So by making an > allocation now, you will have bought yourself three months of time > before you have to light up your DS-Lite CGN, in which you can wait for > (or even better - help finalise!) PCP and/or MAP. I wouldn't abandon > DS-Lite though, having a contingency plan ready to go the moment you > need it is certainly smart. > > I don't understand why a strategy of buying IPv4 addresses instead of > deploying any IPv4 address sharing solution would make you «avoid IPv6», > though. IPv4 life-support and IPv6 deployments seem orthogonal to me, > except that the former may benefit from the latter in the case of > DS-Lite, MAP, and similar. > > Best regards, Marketing-wise, the acceptance for IPv6 was driven solely by the exhaustion of IPv4 addresses. "If we buy more, we don't (currently) need IPv6. It's like buying more time to get more customers." Please don't ask my opinion about this... -- Tassos From achatz@forthnetgroup.gr Thu Jul 19 13: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 15F2D11E80A4 for ; Thu, 19 Jul 2012 13:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.235 X-Spam-Level: X-Spam-Status: No, score=-2.235 tagged_above=-999 required=5 tests=[AWL=0.365, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5L8Nn0r-1wHY for ; Thu, 19 Jul 2012 13:54:48 -0700 (PDT) Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.107]) by ietfa.amsl.com (Postfix) with ESMTP id 75F5A11E80B8 for ; Thu, 19 Jul 2012 13:54:48 -0700 (PDT) Received: from mx-av-04.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-04.forthnet.gr (8.14.4/8.14.4) with ESMTP id q6JKtf6b028359; Thu, 19 Jul 2012 23:55:41 +0300 Received: from MX-IN-01.forthnet.gr (mx-in-01.forthnet.gr [193.92.150.23]) by mx-av-04.forthnet.gr (8.14.4/8.14.4) with ESMTP id q6JKtfJB030193; Thu, 19 Jul 2012 23:55:41 +0300 Received: from [62.1.48.75] (achatz.forthnet.gr [62.1.48.75]) (authenticated bits=0) by MX-IN-01.forthnet.gr (8.14.4/8.14.4) with ESMTP id q6JKteEN021930; Thu, 19 Jul 2012 23:55:40 +0300 Authentication-Results: MX-IN-01.forthnet.gr smtp.mail=achatz@forthnetgroup.gr; auth=pass (PLAIN) Message-ID: <50087449.6060704@forthnetgroup.gr> Date: Thu, 19 Jul 2012 23:55:37 +0300 From: Tassos Chatzithomaoglou Organization: Forthnet User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120615 Firefox/13.0.1 SeaMonkey/2.10.1 MIME-Version: 1.0 To: Lorenzo Colitti References: <5006E47F.8010605@forthnetgroup.gr> <5006FE33.7090903@forthnetgroup.gr> <20120718191000.GW38127@Space.Net> <50071D89.9070601@forthnetgroup.gr> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] current solutions for incoming connections in CGN environments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 19 Jul 2012 20:54:50 -0000 Lorenzo Colitti wrote on 19/07/2012 11:15: > On Thu, Jul 19, 2012 at 5:33 AM, Tassos Chatzithomaoglou > wrote: > > Our IPv6 is completed, our DS-Lite will be completed soon, our customers are growing, our IPv4 addresses will be > over soon...and IPv4 content (and traffic?) is still ~99%. > Am i missing something obvious? > > > Yes, you are. If your IPv4 traffic is 99%, then your IPv6 project is not "completed". There is much more than 1% of > content and traffic on IPv6. As AT&T says: "For our IPv6 enabled customers, we’re seeing more than 20 percent of > traffic transition to IPv6": http://www.attinnovationspace.com/innovation/story/a7782696 . If you don't have enough > IPv6 traffic, you probably haven't deployed IPv6 to enough users. > As i already told to Tore, we still haven't enabled IPv6 to enough users' CPEs. I expect this number to grow in the next few weeks. > One solution to your problem is as follows: > > 1. Deploy IPv6 to a large percentage of your users > 2. Take away the public IPv4 addresses for those users and put them behind a NAT. > > If a user wants inbound connectivity (and many probably don't know they do, or don't care), then give them a public > IPv4 address (either for free or for an extra fee). > This is what we are planning to do (in a semi-automated way), but it goes against our marketing-moto: "Every customer should have connectivity to/from everywhere every-time, over everything.". > This appears to be what AT&T is doing: public numbers suggest that they have more than 4% of IPv6 users, and there are > hints on the forums that they are asking their customers to renumber their internal networks out of 10/8 (which > suggests carrier-operated NAT). > > So before you tell us why this is impossible and will never work, bear in mind that one of the largest ISPs in the > world is doing it :-) > It would be good to know if they are running out of IPv4 addresses like us, which i believe they don't, since they were lucky enough to get many in the beginning. -- Tassos From arturo.servin@gmail.com Thu Jul 19 14:11: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 4B37611E8086 for ; Thu, 19 Jul 2012 14:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rk3yAwo6hrU9 for ; Thu, 19 Jul 2012 14:11:14 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id D402421F8702 for ; Thu, 19 Jul 2012 14:10:55 -0700 (PDT) Received: by ghbg16 with SMTP id g16so3616895ghb.31 for ; Thu, 19 Jul 2012 14:11: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 :message-id:references:to:x-mailer; bh=u8NviGS0rfdEBuwJsSS7oGfn8T8I9yy8uZglWc6fbXc=; b=dLdp9wf7JOqW30HoCQ2XY3AGarJff7I3Wq4KNYqIXSKgr2MnvKVLJrBH6PzE27iSOB 8dO/7FNeLothluBL5qi8IAUJ+P8ojwc0ms+GbngAmAxdj7oLLWVHiOuhnYx3KaClHWWX vJVmPKlWRF+p6zZiKCAWRQNz+r15TKT6W9fwDuDzuA+w745Cg87NiWtCXhiPbd3G5xvT FLZ0P6jzUZxmQg7esn1Eu/ct32YYKG2f3qK5FiwVC7cf9TvIkZXStZW6X5CaKZC98bm9 hn7TjFJ3MrwSlczJzm9G6WoGGFRd5zCDLS25cylvjuPMfSkv0+k1Y/CcUxZl7yCYc2kN OxgQ== Received: by 10.236.145.40 with SMTP id o28mr3425505yhj.70.1342732309726; Thu, 19 Jul 2012 14:11:49 -0700 (PDT) Received: from [190.115.129.13] ([190.115.129.13]) by mx.google.com with ESMTPS id l49sm5801160yhj.8.2012.07.19.14.11.47 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 19 Jul 2012 14:11:48 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_6B3DA14F-BE0B-44E1-90CD-F75E8EB96A4C" From: Arturo Servin In-Reply-To: <50087449.6060704@forthnetgroup.gr> Date: Thu, 19 Jul 2012 17:11:46 -0400 Message-Id: <0D977B78-B721-4E68-A1BA-E092D050A452@gmail.com> References: <5006E47F.8010605@forthnetgroup.gr> <5006FE33.7090903@forthnetgroup.gr> <20120718191000.GW38127@Space.Net> <50071D89.9070601@forthnetgroup.gr> <50087449.6060704@forthnetgroup.gr> To: Tassos Chatzithomaoglou X-Mailer: Apple Mail (2.1278) Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] current solutions for incoming connections in CGN environments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 19 Jul 2012 21:11:15 -0000 --Apple-Mail=_6B3DA14F-BE0B-44E1-90CD-F75E8EB96A4C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Probably they are. If you are talking about 12/8 this one is = only 16M address, far away less of the amount of customers that ATT = probably has and need an IP. regards, as On 19 Jul 2012, at 16:55, Tassos Chatzithomaoglou wrote: >> This appears to be what AT&T is doing: public numbers suggest that = they have more than 4% of IPv6 users, and there are hints on the forums = that they are asking their customers to renumber their internal networks = out of 10/8 (which suggests carrier-operated NAT). >>=20 >> So before you tell us why this is impossible and will never work, = bear in mind that one of the largest ISPs in the world is doing it :-) >>=20 > It would be good to know if they are running out of IPv4 addresses = like us, which i believe they don't, since they were lucky enough to get = many in the beginning. --Apple-Mail=_6B3DA14F-BE0B-44E1-90CD-F75E8EB96A4C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Probably they are. If you = are talking about 12/8 this one is only 16M address, far away less of = the amount of customers that ATT probably has and need an = IP.

regards,
as

On = 19 Jul 2012, at 16:55, Tassos Chatzithomaoglou wrote:

This appears to be what AT&T is = doing: public numbers suggest that they have more than 4% of IPv6 users, = and there are hints on the forums that they are asking their customers = to renumber their internal networks out of 10/8 (which suggests = carrier-operated NAT).

So before you = tell us why this is impossible and will never work, bear in mind that = one of the largest ISPs in the world is doing it = :-)

It would = be good to know if they are running out of IPv4 addresses like us, which = i believe they don't, since they were lucky enough to get many in the = beginning.

= --Apple-Mail=_6B3DA14F-BE0B-44E1-90CD-F75E8EB96A4C-- From BECHA@ripe.net Fri Jul 20 08:27: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 4B42821F8526 for ; Fri, 20 Jul 2012 08:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bvSb1XdJ38eA for ; Fri, 20 Jul 2012 08:27:29 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id F340121F849C for ; Fri, 20 Jul 2012 08:27:28 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1SsF7u-0007I0-R3 for v6ops@ietf.org; Fri, 20 Jul 2012 17:28:23 +0200 Received: from vesna.vpn.ripe.net ([193.0.21.44] helo=guest173.guestnet.ripe.net) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1SsF7u-0003Gc-GY for v6ops@ietf.org; Fri, 20 Jul 2012 17:28:22 +0200 Message-ID: <50097916.6050006@ripe.net> Date: Fri, 20 Jul 2012 17:28:22 +0200 From: Vesna Manojlovic User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: v6ops@ietf.org References: <4FFEC0A4.2070509@gmail.com> <20120712131000.GC38127@Space.Net> <20120712.154239.133898240.he@uninett.no> In-Reply-To: <20120712.154239.133898240.he@uninett.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20120720 clean X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 63c376d8fe7b052a5a65f88a9765b61a983e56340551a6f001b9852fe0098cf6 Subject: Re: [v6ops] Fwd: RIPE-555 fundamentaly changes the way how we can filter IPv6 & IPv4 martians? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 20 Jul 2012 15:27:30 -0000 Dear colleagues, On 7/12/12 3:42 PM, Havard Eidnes wrote: >> (And of course, this discussion has not very much to do with RIPE-555, >> except that some folks assumed that RIPE-510 gave useful guidance on >> "1", which had never been its primary purpose) > > ?!? > > I thought the whole point of this discussion was exactly that, > and that documenting the minimum assignment sizes did indeed give > some useful guidance which might be of use by a network operator. After considering your feedback about RIPE-510 & RIPE555, RIPEstat developers have created another visual interpretation of RIR "delegations" data: an interactive widget in which you can query for any address space prefix (0/0, 2000::/3 or 5/8, for example) and receive a prefix size distribution as an output: https://stat.ripe.net/widget/rir-prefix-size-distribution You can use the resulting output to determine a cutting-off point for the filtering based on the minimum allocation size: for example, if the 213/8 block has only XX % prefixes smaller then /24, you might decide that it is safe to not accept those prefixes. Or you can go for the /25 or /23 instead. A data call API is also available for the scripting and creating your own favorite filters. We are interested in your feedback: - do you find this useful? - how can we improve it, so that it suits your needs even better? We already have multiple ideas for the additional features in the next release of the widget, but we are very much looking forward to hear from you and make a new widget or improve this one based on your needs! More information is available in the RIPE Labs article: https://labs.ripe.net/Members/becha/rir-prefix-size-distribution-in-ripestat Regards, Vesna -- Vesna Manojlovic BECHA@ripe.net Senior Community Builder +31205354444 for Measurements Tools RIPE NCC http://ripe.net From turchanyi.geza@gmail.com Fri Jul 20 09:22: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 6DE4C21F8643 for ; Fri, 20 Jul 2012 09:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.365 X-Spam-Level: X-Spam-Status: No, score=-2.365 tagged_above=-999 required=5 tests=[AWL=-1.033, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k1do3iMNb2J1 for ; Fri, 20 Jul 2012 09:22:15 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2E78021F8621 for ; Fri, 20 Jul 2012 09:22:07 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so6631716pbc.31 for ; Fri, 20 Jul 2012 09:23:03 -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=gXfApKIPaxL+teYbwDlVhV/H8+kn2kISNoAl7mppM/s=; b=tZ7fZ8bz3roOE3YOBzCmx+xF9ppXN3nABHlcg4+B/W6YlL4SHihwGyrNVV8N9Eyk1P IgxMmOSyhieRnDkj6DtCNqWycmTrDf/3aCWh7727ZXkdg6vx91TBFtf6Uhiw4pYlxVDv Dc4aT3EdFZvljPxQBiT+QWZ0ns6vAT5NZ9dfxtEBZ6JcGMmFOxrkEj7JuhJon0lvtsIq uZHqUIz+eWAIkZcjZfvjzuBRlJRfBMoz41XV3ayvk42dOUYiuJVHdKAKR5V7UxigmIkV yffP7yafV3bKc+0jdc2CDcQQ3QRHjyPQy166oqKiIi6yxl+bMd3CD2VozBpNOLghWuka WvtQ== MIME-Version: 1.0 Received: by 10.68.203.66 with SMTP id ko2mr15179987pbc.84.1342801383459; Fri, 20 Jul 2012 09:23:03 -0700 (PDT) Received: by 10.66.228.131 with HTTP; Fri, 20 Jul 2012 09:23:03 -0700 (PDT) In-Reply-To: <50097916.6050006@ripe.net> References: <4FFEC0A4.2070509@gmail.com> <20120712131000.GC38127@Space.Net> <20120712.154239.133898240.he@uninett.no> <50097916.6050006@ripe.net> Date: Fri, 20 Jul 2012 18:23:03 +0200 Message-ID: From: Turchanyi Geza To: Vesna Manojlovic Content-Type: multipart/alternative; boundary=047d7b10cfb7770ac304c5454f81 Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: RIPE-555 fundamentaly changes the way how we can filter IPv6 & IPv4 martians? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 20 Jul 2012 16:22:16 -0000 --047d7b10cfb7770ac304c5454f81 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello Vesna, Many thanks for your tool and comments! I would be intesrested in stats of (merely) not routed but allocated addresses... Thanks, G=E9za On Fri, Jul 20, 2012 at 5:28 PM, Vesna Manojlovic wrote: > Dear colleagues, > > > On 7/12/12 3:42 PM, Havard Eidnes wrote: > >> (And of course, this discussion has not very much to do with RIPE-555, >>> except that some folks assumed that RIPE-510 gave useful guidance on >>> "1", which had never been its primary purpose) >>> >> >> ?!? >> >> I thought the whole point of this discussion was exactly that, >> and that documenting the minimum assignment sizes did indeed give >> some useful guidance which might be of use by a network operator. >> > > After considering your feedback about RIPE-510 & RIPE555, > RIPEstat developers have created another visual interpretation of > RIR "delegations" data: an interactive widget in which you can query for > any address space prefix (0/0, 2000::/3 or 5/8, for example) and receive = a > prefix size distribution as an output: > https://stat.ripe.net/widget/**rir-prefix-size-distribution > > You can use the resulting output to determine a cutting-off point for the > filtering based on the minimum allocation size: for example, if the 213/8 > block has only XX % prefixes smaller then /24, you might decide that it i= s > safe to not accept those prefixes. Or you can go for the /25 or /23 inste= ad. > > A data call API is also available for the scripting and creating your own > favorite filters. > > We are interested in your feedback: > - do you find this useful? > - how can we improve it, so that it suits your needs even better? > > We already have multiple ideas for the additional features in the next > release of the widget, but we are very much looking forward to hear from > you and make a new widget or improve this one based on your needs! > > More information is available in the RIPE Labs article: > https://labs.ripe.net/Members/**becha/rir-prefix-size-** > distribution-in-ripestat > > Regards, > Vesna > > -- > Vesna Manojlovic BECHA@ripe.net > Senior Community Builder +31205354444 > for Measurements Tools RIPE NCC http://ripe.net > > > ______________________________**_________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/**listinfo/v6ops > --047d7b10cfb7770ac304c5454f81 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello Vesna,

Many thanks for your tool and comments!

I would = be intesrested in stats of (merely) not routed but allocated addresses...
Thanks,

G=E9za

On Fri, Jul 2= 0, 2012 at 5:28 PM, Vesna Manojlovic <BECHA@ripe.net> wrote:
Dear colleagues,


On 7/12/12 3:42 PM, Havard Eidnes wrote:
(And of course, this discussion has not very much to do with RIPE-555,
except that some folks assumed that RIPE-510 gave useful guidance on
"1", which had never been its primary purpose)

?!?

I thought the whole point of this discussion was exactly that,
and that documenting the minimum assignment sizes did indeed give
some useful guidance which might be of use by a network operator.

After considering your feedback about RIPE-510 & RIPE555,
RIPEstat developers have created another visual interpretation of
RIR "delegations" data: an interactive widget in which you can qu= ery for any address space prefix (0/0, 2000::/3 or 5/8, for example) and re= ceive a prefix size distribution as an output:
https://stat.ripe.net/widget/rir-prefix-size-distributi= on

You can use the resulting output to determine a cutting-off point for the f= iltering based on the minimum allocation size: for example, if the 213/8 bl= ock has only XX % prefixes smaller then /24, you might decide that it is sa= fe to not accept those prefixes. Or you can go for the /25 or /23 instead.<= br>
A data call API is also available for the scripting and creating your own f= avorite filters.

We are interested in your feedback:
- do you find this useful?
- how can we improve it, so that it suits your needs even better?

We already have multiple ideas for the additional features in the next rele= ase of the widget, but we are very much looking forward to hear from you an= d make a new widget or improve this one based on your needs!

More information is available in the RIPE Labs article:
https://labs.ripe.net/Members/becha/= rir-prefix-size-distribution-in-ripestat

Regards,
Vesna

--
Vesna Manojlovic =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 BECHA@ripe.net<= /a>
Senior Community Builder =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 +31205354444
for Measurements Tools =A0 =A0 =A0 =A0 =A0RIPE NCC =A0 =A0 =A0 =A0http://ripe.net


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

--047d7b10cfb7770ac304c5454f81-- From jeroen@unfix.org Fri Jul 20 09: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 2910E21F85C6 for ; Fri, 20 Jul 2012 09:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5sfgENZCCQlb for ; Fri, 20 Jul 2012 09:50:41 -0700 (PDT) Received: from icaras.de.unfix.org (icaras.de.unfix.org [IPv6:2a01:4f8:130:74c1:5054:ff:fec4:f7d4]) by ietfa.amsl.com (Postfix) with ESMTP id 0380B21F855E for ; Fri, 20 Jul 2012 09:50:40 -0700 (PDT) Received: from kami.ch.unfix.org (117-1.5-85.cust.bluewin.ch [85.5.1.117]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by icaras.de.unfix.org (Postfix) with ESMTPSA id F0E30801C2A9; Fri, 20 Jul 2012 18:51:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=unfix.org; s=DKIM2009; t=1342803095; bh=ZV3nHCQnQ3mb1V0zCaECIKr/rVfFekvEgKji+jHRFoI=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=v/8Yj719Dk96IYsOXpsQw/bAL4RFFQtflCd9OD2uvRroGI8d6doT0ETfwFvQ4lWY7 zTLuiDVAcPYLk3oMoLmAlQ95MUQmgLcauupRt45mBKdHksckMHqNEnBEA1FKoOclfG tP44/+NnNhtnkc8ea9GKu/9aKmSZ/Q3iSEODDs2cQeLLOGOZkH3SchCBsojKoCSXJE f7bbWOBxnwQMs+gXqhpR0pJfEqm0Gh+LbZcPIntq7Z4084yqq60e2+JqFN/uIVbDTc /6yQMKBq6COeuQ4qPjXkU/WYqr82sC/xtWe6SmlzDzikNENGVNrJiVMJl4q6plz52p 7zdK3GsnkClGA== Message-ID: <50098C95.9050100@unfix.org> Date: Fri, 20 Jul 2012 18:51:33 +0200 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Turchanyi Geza References: <4FFEC0A4.2070509@gmail.com> <20120712131000.GC38127@Space.Net> <20120712.154239.133898240.he@uninett.no> <50097916.6050006@ripe.net> In-Reply-To: X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: RIPE-555 fundamentaly changes the way how we can filter IPv6 & IPv4 martians? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 20 Jul 2012 16:50:42 -0000 On 2012-07-20 18:23, Turchanyi Geza wrote: > Hello Vesna, > > Many thanks for your tool and comments! > > I would be intesrested in stats of (merely) not routed but allocated > addresses... Check http://www.sixxs.net/tools/grh/ and the reports it generates. There are a lot of more specifics out there and also a lot of prefixes which do not route the allocated size... (and then those network admins wonder why it does not work) Greets, Jeroen From Tina.Tsou.Zouting@huawei.com Fri Jul 20 21: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 8DE5311E8086 for ; Fri, 20 Jul 2012 21:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.281 X-Spam-Level: X-Spam-Status: No, score=-2.281 tagged_above=-999 required=5 tests=[AWL=-3.086, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wo7RwecjmUwg for ; Fri, 20 Jul 2012 21:25:58 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 325C411E8079 for ; Fri, 20 Jul 2012 21:25:58 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHY21394; Sat, 21 Jul 2012 00:26:55 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 20 Jul 2012 21:25:56 -0700 Received: from DFWEML513-MBS.china.huawei.com ([169.254.4.5]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0323.003; Fri, 20 Jul 2012 21:25:58 -0700 From: Tina TSOU To: Sheng Jiang Thread-Topic: [v6ops] Call for Adoption, was Re: New draft waiting for adoption: draft-chen-v6ops-nat64-experience-02 Thread-Index: AQHNW44Rwz7O6YK62kW7F7h5B7rp+pcijTcAgBCthfo= Date: Sat, 21 Jul 2012 04:25:57 +0000 Message-ID: <8C9DC6AF-764D-49D5-9C6A-98776E532407@huawei.com> References: <0B2FA58F71A34C199446380DA654FB07@LENOVO1E4798BB> <1DFE8BF4-885E-4F2F-AA1B-4FC1658BA688@cisco.com> <4FF7077B.5050703@bogus.com>, <5D36713D8A4E7348A7E10DF7437A4B9239EF7244@szxeml545-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B9239EF7244@szxeml545-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_8C9DC6AF764D49D59C6A98776E532407huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: IPv6 Ops WG Subject: Re: [v6ops] Call for Adoption, was Re: New draft waiting for adoption: draft-chen-v6ops-nat64-experience-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 21 Jul 2012 04:25:59 -0000 --_000_8C9DC6AF764D49D59C6A98776E532407huaweicom_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 U3VwcG9ydCB3aXRoIGNvbW1lbnRzIGJlbG93Lg0KDQpJbiB0aGUgZHJhZnQsIE5BVDY0IHdhcyBj b21wYXJlZCB3aXRoIGR1YWwgc3RhY2sgbmV0d29yayB3aGVyZSBtb3JlIGNvc3QgaXMgaW52b2x2 ZWQgd2hpbGUgbWFuYWdpbmcgdHdvIHN0YWNrcyBvZiBwcm90b2NvbC4gSWYgTkFUNjQgaXMgYSB3 YXkgb2YgY29leGlzdGVuY2Ugb2YgSVB2NiBhbmQgSVB2NCwgYSBicmllZiBkaXNjdXNzaW9uIG9m IHR1bm5lbGluZyBvcHRpb25zIGNvbXBhcmVkIHRvIE5BVDY0IGNhbiBiZSBhZGRlZC4gTW9yZW92 ZXIsIGluIHRoZSBkZXBsb3ltZW50IGNvbnNpZGVyYXRpb25zLCBpbiBjYXNlIE5BVDY0IGlzIGlu dGVncmF0ZWQgd2l0aCBhbiBleGlzdGluZyBnYXRld2F5LCB3aGF0IHdvdWxkIGJlIHRoZSBwb3Nz aWJsZSBpbXBhY3RzIGFuZCBtZW1vcnkgcmVxdWlyZW1lbnRzIG9mIHRoZSBnYXRld2F5LiBUaGVy ZSB3b3VsZCBhIGRhdGEgYmFzZSBtYWludGFpbmVkIG9mIHRoZSBtYXBwaW5nLCB0aGF0IG1pZ2h0 IGRlbWFuZCBtb3JlIHJlc291cmNlcy4gRGVwbG95aW5nIGl0IKGwY2xvc2UgdG8gQk5HIG9yIENS IGhhcyBmZXcgaW1wYWN0cyChsCCoQ2lmIHRoZXJlIGNhbiBiZSBmZXcgZXhhbXBsZXMgb2YgdGhl IGltcGFjdHMuDQoNCkJhc2VkIG9uIG15IE5BVDY0IGV4cGVyaWVuY2UsIHRoZSBOQVQ2NCBnYXRl d2F5IHNob3VsZCBhbHNvIGRlZmluZSByb3V0ZXMgdG8gdGhlIGJsb2NrIG9mIGFkZHJlc3NlcyAo Zm9yIGV4YW1wbGUgOjovOTYgaXB2NiBhZGRyZXNzIGJsb2NrKSB1c2VkIHRvIHJlcHJlc2VudCBJ UHY0IGFkZHJlc3MuIElmIGEuYi5jLmQgaXMgdXNlZCB0byByZXByZXNlbnQgczpmOmc6aDo6MSB0 aGVuIHRoZXJlIHNob3VsZCBiZSByb3V0ZXMgdG8gYS5iLmMuZCAgYXMgd2VsbCB0byBzdWNjZXNz ZnVsbHkgTkFULiBJbiBteSBvcGluaW9uLCB0aGlzIGlzIGFuIGltcG9ydGFudCBpbXBsZW1lbnRh dGlvbiByZXF1aXJlbWVudC4NCg0KSW4gTkFUNjQtQ0UgTmV0d29ya2luZyBwYXJhZ3JhcGgsIEkg ZGlkIG5vdCBnZXQgdGhpcyBsaW5lOiChsE9uZSBiaWcgY2hhbGxlbmdlIGlzIE5BVDY0LUNFIGZh Y2luZyBJUHY2IEludGVybmV0LCBvbiB3aGljaCBhIHNpZ25pZmljYW50IElQdjYgdXNlcnMgbWF5 IGNvbm5lY3QgdG8uobENCg0KVGluYQ0KDQpPbiBKdWwgMjAsIDIwMTIsIGF0IDQ6NDcgUE0sICJT aGVuZyBKaWFuZyIgPGppYW5nc2hlbmdAaHVhd2VpLmNvbTxtYWlsdG86amlhbmdzaGVuZ0BodWF3 ZWkuY29tPj4gd3JvdGU6DQoNClN1cHBvcnQgZm9yIFdHIGFkb3B0aW9uLiBRdWl0ZSB1c2VmdWwg ZXhwZXJpZW5jZSBmb3Igb3RoZXIgSVNQcy4NCg0KU2hlbmcNCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IHY2b3BzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnY2b3BzLWJvdW5j ZXNAaWV0Zi5vcmc+IFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmDQpP ZiBKb2VsIGphZWdnbGkNClNlbnQ6IEZyaWRheSwgSnVseSAwNiwgMjAxMiAxMTo0MyBQTQ0KVG86 IElQdjYgT3BzIFdHDQpTdWJqZWN0OiBbdjZvcHNdIENhbGwgZm9yIEFkb3B0aW9uLCB3YXMgUmU6 IE5ldyBkcmFmdCB3YWl0aW5nIGZvciBhZG9wdGlvbjoNCmRyYWZ0LWNoZW4tdjZvcHMtbmF0NjQt ZXhwZXJpZW5jZS0wMg0KDQpUaGUgZm9sbG93aW5nIG1lc3NhZ2UgY29tbWVuY2VzIGEgMSB3ZWVr IGNhbGwgZm9yIG9waW5pb25zIG9uIHRoZQ0KYWRvcHRpb24gb2YgZHJhZnQtY2hlbi12Nm9wcy1u YXQ2NC1leHBlcmllbmNlLTAyDQoNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNo ZW4tdjZvcHMtbmF0NjQtZXhwZXJpZW5jZS0wMg0KDQpGcmlkYXkgNy8xMy8yMDEyIGlzIHRoZSBk ZWFkbGluZSBmb3IgdGhpcyBwYXJ0aWN1bGFyIGNhbGwuDQoNClRoYW5rIHlvdS4NCmpvZWwNCg0K xvPStbHq17y1xM7Esb648cq9o6jEo7Dmo6kNCg0KRGVhciBDaGFpcnMsDQoNCg0KDQpXZSBoYXZl IHBvc3RlZCBuZXcgZHJhZnQgb2YgTkFUNjQgZXhwZXJpZW5jZXMuDQoNCkN1cnJlbnQgZHJhZnQg aXMgYSBqb2luZWQgZWZmb3J0IGZyb20gZm91ciBvcGVyYXRvcnMgKENoaW5hIE1vYmlsZSwNClQt bW9iaWxlIFVTQSwgQ2hpbmEgVGVsZWNvbSBhbmQgRnJhbmNlIFRlbGVjb20pDQoNCndobyBpcyBh Y3RpdmVseSBwcm9ncmVzc2luZyBJUHY2IGRlcGxveW1lbnQgZGVwZW5kaW5nIG9uIHRoZSBwcmFj dGljZXMuDQoNClNldmVyYWwgZXhwZXJ0cyBlbmNvdXJhZ2UgdXMgdG8gY29udGludWUgdGhlIHdv cmsgYWZ0ZXIgdGhlaXIga2luZCByZXZpZXcNCg0KDQoNCkZvciBub3csIHdlIGhhdmUgYWRkcmVz c2VkIGFsbCBjb21tZW50cy4NCg0KVGhlIGRyYWZ0IGlzIHJlYWR5IGZvciB0aGUgYWRvcHRpb24u DQoNClRoZSBhdXRob3JzIHdvdWxkIGxpa2UgdG8gY29uc3VsdCB5b3VyIG9waW5pb25zIGFuZCBs b29rIGZvcndhcmQgeW91cg0KZ3VpZGFuY2UuDQoNCg0KDQoNCg0KTWFueSB0aGFua3MNCg0KDQoN CkF1dGhvcnMNCg0KDQoNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09DQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1jaGVuLXY2b3BzLW5h dDY0LWV4cGVyaWVuY2UtMDIudHh0DQoNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQg YnkgR2FuZyBDaGVuIGFuZCBwb3N0ZWQgdG8gdGhlDQoNCklFVEYgcmVwb3NpdG9yeS4NCg0KDQoN CkZpbGVuYW1lOiAgICAgICAgZHJhZnQtY2hlbi12Nm9wcy1uYXQ2NC1leHBlcmllbmNlDQoNClJl dmlzaW9uOiAgICAgICAgMDINCg0KVGl0bGU6ICAgICAgICAgICBOQVQ2NCBPcGVyYXRpb25hbCBF eHBlcmllbmNlcw0KDQpDcmVhdGlvbiBkYXRlOiAgIDIwMTItMDctMDQNCg0KV0cgSUQ6ICAgICAg ICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCg0KTnVtYmVyIG9mIHBhZ2VzOiAxNQ0KDQpVUkw6 DQoNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWNoZW4tdjZvcHMt bmF0NjQtZXhwZXJpZW5jZS0wMi4NCnR4dA0KDQpTdGF0dXM6DQpodHRwOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWNoZW4tdjZvcHMtbmF0NjQtZXhwZXJpZW5jZQ0KDQpIdG1saXpl ZDoNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNoZW4tdjZvcHMtbmF0NjQtZXhw ZXJpZW5jZS0wMg0KDQpEaWZmOg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL3JmY2RpZmY/dXJsMj1k cmFmdC1jaGVuLXY2b3BzLW5hdDY0LWV4cGVyaWVuY2UtMDINCg0KDQoNCkFic3RyYWN0Og0KDQog IFRoaXMgZG9jdW1lbnQgc3VtbWFyaXplcyBzb21lIHN0YXRlZnVsIE5BVDY0IGRlcGxveW1lbnQN CnNjZW5hcmlvcyBhbmQNCg0KICBvcGVyYXRpb25hbCBleHBlcmllbmNlcyBmb3IgTkFUNjQtQ0dO IGFuZCBOQVQ2NC1DRS4NCg0KDQoNCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KdjZvcHMgbWFpbGluZyBsaXN0DQp2Nm9wc0BpZXRmLm9y ZzxtYWlsdG86djZvcHNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3Y2b3BzDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KdjZvcHMgbWFpbGluZyBsaXN0DQp2Nm9wc0BpZXRmLm9yZzxtYWlsdG86djZvcHNAaWV0 Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo= --_000_8C9DC6AF764D49D59C6A98776E532407huaweicom_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Support with comments below.

In the draft, NAT64 was compared with dual stack network where m= ore cost is involved while managing two stacks of protocol. If NAT64 is a w= ay of coexistence of IPv6 and IPv4, a brief discussion of tunneling options= compared to NAT64 can be added. Moreover, in the deployment considerations, in case NAT64 is integrated wi= th an existing gateway, what would be the possible impacts and memory requi= rements of the gateway. There would a data base maintained of the mapping, = that might demand more resources. Deploying it =A1=B0close to BNG or CR has few impacts =A1=B0 =A8Cif there = can be few examples of the impacts.
 
Based on my NAT64 experience, the NAT64 gateway should also define rou= tes to the block of addresses (for example ::/96 ipv6 address block) used t= o represent IPv4 address. If a.b.c.d is used to represent s:f:g:h::1 then t= here should be routes to a.b.c.d  as well to successfully NAT. In my opinion, this is an important implement= ation requirement.
 
In NAT64-CE Networking paragraph, I did not get this line: =A1=B0One b= ig challenge is NAT64-CE facing IPv6 Internet, on which a significa= nt IPv6 users may connect to.=A1=B1

Tina

On Jul 20, 2012, at 4:47 PM, "Sheng Jiang" <jiangsheng@huawei.com> wrote:

Support for WG adoption. Quite useful experience for other ISPs.=

Sheng

-----Original Message-----
From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
Of Joel jaeggli
Sent: Friday, July 06, 2012 11:43 PM=
To: IPv6 Ops WG
Subject: [v6ops] Call for Adoption, was Re:= New draft waiting for adoption:
draft-chen-v6ops-nat64-experience-02=

The following message commences a 1 week ca= ll for opinions on the
adoption of draft-chen-v6ops-nat64-experien= ce-02

http://tools.ietf.org/html/draft-chen-v6op= s-nat64-experience-02

Friday 7/13/2012 is the deadline for this p= articular call.

Thank you.
joel

=C6=F3=D2=B5=B1=EA=D7=BC=B5=C4=CE=C4=B1=BE= =B8=F1=CA=BD=A3=A8=C4=A3=B0=E6=A3=A9

Dear Chairs,



We have posted new draft of NAT64 experienc= es.

Current draft is a joined effort from four = operators (China Mobile,
T-mobile USA, China Telecom and France Tele= com)

who is actively progressing IPv6 deployment= depending on the practices.

Several experts encourage us to continue th= e work after their kind review



For now, we have addressed all comments.

The draft is ready for the adoption.=

The authors would like to consult your opin= ions and look forward your
guidance.





Many thanks



Authors



=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

A new version of I-D, draft-chen-v6ops-nat6= 4-experience-02.txt

has been successfully submitted by Gang Che= n and posted to the

IETF repository.



Filename:      &nb= sp; draft-chen-v6ops-nat64-experience

Revision:      &nb= sp; 02

Title:       =     NAT64 Operational Experiences

Creation date:   2012-07-04

WG ID:       =     Individual Submission

Number of pages: 15

URL:

http://www.ietf.org/internet-draf= ts/draft-chen-v6ops-nat64-experience-02.
txt

Status:
http://datatracker.ietf.org/doc/draft-ch= en-v6ops-nat64-experience

Htmlized:
http://tools.ietf.org/html/draft-chen-v6op= s-nat64-experience-02

Diff:
http://tools.ietf.org/rfcdiff?ur= l2=3Ddraft-chen-v6ops-nat64-experience-02



Abstract:

  This document summarizes some s= tateful NAT64 deployment
scenarios and

  operational experiences for NAT= 64-CGN and NAT64-CE.








___________________________________________= ____
v6ops mailing list
v6ops@iet= f.org
https://www.ietf.org/mailman/listinfo/v6ops
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.i= etf.org/mailman/listinfo/v6ops
--_000_8C9DC6AF764D49D59C6A98776E532407huaweicom_-- From phdgang@gmail.com Sat Jul 21 20:41: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 C9DCF21F84B6 for ; Sat, 21 Jul 2012 20:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.014 X-Spam-Level: X-Spam-Status: No, score=-2.014 tagged_above=-999 required=5 tests=[AWL=-1.465, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQzCuCEjWThm for ; Sat, 21 Jul 2012 20:41: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 BF99321F84A6 for ; Sat, 21 Jul 2012 20:41:13 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so4225404vcb.31 for ; Sat, 21 Jul 2012 20:42:14 -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=JgMH1tfQnTWxObtInCKjs53C2WjbI2sF/c02M7GiUzA=; b=a7H0NkjlY7ca92IqTFiU1irgCs8e3LBytwbXkjNDB7tnMPubxW4EWgiRwTXgbhvJrc tE0TBJZhaKtsui6nhUKIvfqAD6bZVk7V1XcOJWwwuCFkPDCM3Ago+ZZ3NtwgNh6PjvW8 pI//pdOhhJ0AWLKKVE7pqSek+6hgzxlKp3vSns2iAD/3nYIakRgXk3PifsZdOQpEmKLJ hh1M2tRXal9n2p+uzXEmPmVY/yRUNY0EJURp3SBnbH8VmY8baN9sXlNEmZpere/wgk64 TvWQAJ0oUY1WiKgrShp9TU+QlZ/g+d/WyhzccQoKg4TU7DG7DSyc3Xomde1+9QEg7vQm NgFg== MIME-Version: 1.0 Received: by 10.220.153.7 with SMTP id i7mr8213515vcw.34.1342928533739; Sat, 21 Jul 2012 20:42:13 -0700 (PDT) Received: by 10.58.4.40 with HTTP; Sat, 21 Jul 2012 20:42:13 -0700 (PDT) In-Reply-To: <8C9DC6AF-764D-49D5-9C6A-98776E532407@huawei.com> References: <0B2FA58F71A34C199446380DA654FB07@LENOVO1E4798BB> <1DFE8BF4-885E-4F2F-AA1B-4FC1658BA688@cisco.com> <4FF7077B.5050703@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239EF7244@szxeml545-mbx.china.huawei.com> <8C9DC6AF-764D-49D5-9C6A-98776E532407@huawei.com> Date: Sun, 22 Jul 2012 11:42:13 +0800 Message-ID: From: GangChen To: Tina TSOU Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Ops WG Subject: Re: [v6ops] Call for Adoption, was Re: New draft waiting for adoption: draft-chen-v6ops-nat64-experience-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 22 Jul 2012 03:41:14 -0000 2012/7/21, Tina TSOU : > Support with comments below. Thanks > In the draft, NAT64 was compared with dual stack network where more cost = is > involved while managing two stacks of protocol. If NAT64 is a way of > coexistence of IPv6 and IPv4, a brief discussion of tunneling options > compared to NAT64 can be added. If we are focusing on the case of IPv6 communicating with IPv4, they are likely incomparable imho. >Moreover, in the deployment considerations, > in case NAT64 is integrated with an existing gateway, what would be the > possible impacts and memory requirements of the gateway. There would a da= ta > base maintained of the mapping, that might demand more resources. Deployi= ng > it =A1=B0close to BNG or CR has few impacts =A1=B0 =A8Cif there can be fe= w examples of > the impacts. Right. We documented that at Section 3.1. Please take a further check. > Based on my NAT64 experience, the NAT64 gateway should also define routes= to > the block of addresses (for example ::/96 ipv6 address block) used to > represent IPv4 address. If a.b.c.d is used to represent s:f:g:h::1 then > there should be routes to a.b.c.d as well to successfully NAT. In my > opinion, this is an important implementation requirement. Those were discussed at section 3.4 rfc6052. > In NAT64-CE Networking paragraph, I did not get this line: =A1=B0One big > challenge is NAT64-CE facing IPv6 Internet, on which a significant IPv6 > users may connect to.=A1=B1 When NAT64-CE is doing, care should be taken to be aware of the problems it may caused. The draft intended to raise such caution. NAT64-CE implicitly means it has to encounter significant IPv6 customers connectivity in the scenario of IPv6 Internet->IPv4 network. When numerous IPv6 connections are launched, scalability concerns are applied. The draft recommended NAT64-CE is *only* deployed and used in a relative small scale where appropriate number of IPv6 customer from early adopter to access services. BRs Gang > Tina > > On Jul 20, 2012, at 4:47 PM, "Sheng Jiang" > > wrote: > > Support for WG adoption. Quite useful experience for other ISPs. > > Sheng > > -----Original Message----- > From: v6ops-bounces@ietf.org > [mailto:v6ops-bounces@ietf.org] On Behalf > Of Joel jaeggli > Sent: Friday, July 06, 2012 11:43 PM > To: IPv6 Ops WG > Subject: [v6ops] Call for Adoption, was Re: New draft waiting for adoptio= n: > draft-chen-v6ops-nat64-experience-02 > > The following message commences a 1 week call for opinions on the > adoption of draft-chen-v6ops-nat64-experience-02 > > http://tools.ietf.org/html/draft-chen-v6ops-nat64-experience-02 > > Friday 7/13/2012 is the deadline for this particular call. > > Thank you. > joel > > =C6=F3=D2=B5=B1=EA=D7=BC=B5=C4=CE=C4=B1=BE=B8=F1=CA=BD=A3=A8=C4=A3=B0=E6= =A3=A9 > > Dear Chairs, > > > > We have posted new draft of NAT64 experiences. > > Current draft is a joined effort from four operators (China Mobile, > T-mobile USA, China Telecom and France Telecom) > > who is actively progressing IPv6 deployment depending on the practices. > > Several experts encourage us to continue the work after their kind review > > > > For now, we have addressed all comments. > > The draft is ready for the adoption. > > The authors would like to consult your opinions and look forward your > guidance. > > > > > > Many thanks > > > > Authors > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > A new version of I-D, draft-chen-v6ops-nat64-experience-02.txt > > has been successfully submitted by Gang Chen and posted to the > > IETF repository. > > > > Filename: draft-chen-v6ops-nat64-experience > > Revision: 02 > > Title: NAT64 Operational Experiences > > Creation date: 2012-07-04 > > WG ID: Individual Submission > > Number of pages: 15 > > URL: > > http://www.ietf.org/internet-drafts/draft-chen-v6ops-nat64-experience-02. > txt > > Status: > http://datatracker.ietf.org/doc/draft-chen-v6ops-nat64-experience > > Htmlized: > http://tools.ietf.org/html/draft-chen-v6ops-nat64-experience-02 > > Diff: > http://tools.ietf.org/rfcdiff?url2=3Ddraft-chen-v6ops-nat64-experience-02 > > > > Abstract: > > This document summarizes some stateful NAT64 deployment > scenarios and > > operational experiences for NAT64-CGN and NAT64-CE. > > > > > > > > > _______________________________________________ > 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 phdgang@gmail.com Sat Jul 21 21:27: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 9F5D921F847E; Sat, 21 Jul 2012 21:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.995 X-Spam-Level: X-Spam-Status: No, score=-2.995 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qqpBaQM1ura; Sat, 21 Jul 2012 21:27:25 -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 C94E821F847C; Sat, 21 Jul 2012 21:27:24 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so8538824obb.31 for ; Sat, 21 Jul 2012 21:28:25 -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=g3mhZ2oC+4iWkm8IdMBZ4L6N3Oa/GZLPgnK4GH0yXN8=; b=xse5fmhsUhASusxjLFwNZ2Ps5O5bgjDLqtyeosVB6kNK/XRilGOWYTrB2dfDeGPflw 7foHeLSVWdJRxZD3AylXqsZynWlB2RcQQ29HPZS0yR/pdHvp53KvPJCAP0FGHdxQIizE fpm0QOjEpZHzvsk4n/yV4ixt1Db4YbmKZfm3n9T/3yx1aRJr80dqDroQu1M92Tns54ps CdJEZ1RcMhx/GV3pnFOVzrxXhRA9wB0xeMb6sS3bV5RRg/olhtX7NxsRMIBGk598TdFc xymB5GARE99Y3/O7HF1wuhmnxrWWrn4iUpiCqEbTDwwe4VrzA0pkF+pmIWwtMoK45yE0 n29g== MIME-Version: 1.0 Received: by 10.50.173.5 with SMTP id bg5mr7633384igc.35.1342931304837; Sat, 21 Jul 2012 21:28:24 -0700 (PDT) Received: by 10.42.151.194 with HTTP; Sat, 21 Jul 2012 21:28:24 -0700 (PDT) In-Reply-To: <500B5A2D.6000408@tut.fi> References: <4FF696AA.3050508@tut.fi> <500B5A2D.6000408@tut.fi> Date: Sun, 22 Jul 2012 12:28:24 +0800 Message-ID: From: GangChen To: Aleksi Suhonen Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops , "ipv6@ietf.org" Subject: Re: [v6ops] draft-chen-v6ops-nat64-experience-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 22 Jul 2012 04:27:25 -0000 Hello Aleksi, Please see my reply inline. 2012/7/22, Aleksi Suhonen : > Hi, > > On 07/18/2012 12:05 PM, GangChen wrote: >> cc v6ops where there is discussion on draft-chen-v6ops-nat64-experience > > Oh sorry. I thought I started the discussion on the right mailing-list > in the first place, but turns out it was wrong. > >> =>I may hardly understand that is a problem with stateless NAT64. >> RFC6145 doesn't require creating a mapping state because it's >> *stateless*. The package forwarding is based on mapping rules, which >> is nothing to do with *lifetime*. Therefore, above statement of IPv4 >> pool exhaustion may not apply to stateless NAT64. I suspect this >> problem may occur in a stateful NAT64 context. The frequent reclaiming >> behavior would consume unnecessary resource by creating overwhelming >> states on NAT64 box. Your further check is expected. > > I think you're confused by the name "Stateless NAT64" because it's not > stateless despite its name. Stateless NAT64 maintains state about the > src.IPv6->src.IPv4 address mappings, while Stateful NAPT64 maintains > state about both addresses and ports. I have same understanding on the term of "Stateless NAT64" with http://www.ietf.org/mail-archive/web/ipv6/current/msg16070.html > Take a minute to think about it: Stateless NAT64 creates a 1:1 mapping > between its IPv6 clients and the IPv4 pool it's been given. If it did > not maintain a mapping, how would returning IPv4 packets be mapped back > to IPv6? Where would it find which IPv6 address should be the final > destination? Please take a look at Page13~22 at http://fud.no/talks/20120417-RIPE64-The_Case_for_IPv6_Only_Data_Centres.pdf If a stateless translator maintains the binding information of *src.IPv6->src.IPv4 address*, the essential feature of "Does not require flows to flow bidirectionally across a single translator" would lose. Therefore, I prefer to understand your above description is a variant of RFC6146, i.e. in the case of BIB/STE excluding port information. BRs Gang > -- > Aleksi Suhonen, Researcher > Department of Communications Engineering > Tampere University of Technology > From Aleksi.Suhonen@tut.fi Sat Jul 21 18:26: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 9E39B21F8552 for ; Sat, 21 Jul 2012 18:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1uy2PFOteZhV for ; Sat, 21 Jul 2012 18:26:53 -0700 (PDT) Received: from mail-gw-out2.cc.tut.fi (mail-gw-out2.cc.tut.fi [130.230.160.33]) by ietfa.amsl.com (Postfix) with ESMTP id 5B1F921F8548 for ; Sat, 21 Jul 2012 18:26:51 -0700 (PDT) X-AuditID: 82e6a021-b7f236d000000a82-46-500b57163ff2 Received: from mail1.tut.fi (mail1.tut.fi [130.230.162.19]) by mail-gw-out2.cc.tut.fi (Symantec Messaging Gateway) with SMTP id 4B.A6.02690.6175B005; Sun, 22 Jul 2012 04:27:50 +0300 (EEST) Received: from [IPv6:2001:708:310:52:21a:6bff:fe61:167] (pool46.nat64.trex.fi [195.140.194.46]) by mail1.tut.fi (Postfix) with ESMTPSA id 3581840663; Sun, 22 Jul 2012 04:27:50 +0300 (EEST) Message-ID: <500B5715.8050002@tut.fi> Date: Sun, 22 Jul 2012 04:27:49 +0300 From: Aleksi Suhonen Organization: Tampere University of Technology / Department of Communications Engineering User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.5) Gecko/20120624 Icedove/10.0.5 MIME-Version: 1.0 To: sarikaya@ieee.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCIsWRmVeSWpSXmKPExsXS9GyRsK5YOHeAQecVCYvnN2azWyzvW85q Mbv3NIvF6WN7mR1YPHbOusvu8XTCQSaPJUt+Mnm8mjCFOYAlissmJTUnsyy1SN8ugSvj27GF rAWH2Sp2/dJqYFzG2sXIySEhYCJx7M8pRghbTOLCvfVsXYxcHEIC+xglWmZtYYJwDjBK/L9x iQ2kildAVeL/9/vMIDYLkL3r7FImEJtNQEfiStctsBp+gWiJ1+f+soPYogIhEtObDzJB9ApK nJz5hAXEFhEQlbj95gzYFcxANa131oL1Cgs4SrzpvgR2kZBAgMTDaU/AdnEKBErcmdcFVMMB VG8t8W13EUSrvMT2t3OYJzAKzkKyYRZC1SwkVQsYmVcxiuUmZuboppfr5peWGOklJ+uVlJbo pWVuYgQH9QLFHYynZugfYhTgYFTi4TVy5w4QYk0sK67MPcQoycGkJMrrFwgU4kvKT6nMSCzO iC8qzUktPsQowcGsJMJ7TRMox5uSWFmVWpQPk5Lh4FCS4HUNA0oJFqWmp1akZeYAYxcmzcTB CdLOA9RuDlLDW1yQmFucmQ6RP8WoKCXOKwiSEABJZJTmwfWCEkf9////XzGKAx0rDNHOA0w6 cN2vgAYzAQ2WzuICGVySiJCSamDMD19yjyG87dNUBcbTt42buD/HN2TEBhhv27j2vbTY0ewl h8P0o0Q2T3D8X6bw/p5CbpHTWZWJZ298Fkz413J2ScHxe/nzKsKjjm2Yr7x6hhH3sZpstp2S Cu8un8orr7HqPXJWOPo5+9wuN6M20+1crlyXuV3aVTOuHLFsyUn59/XD9MyP23yUWIozEg21 mIuKEwEYtQqn9wIAAA== X-Mailman-Approved-At: Sat, 21 Jul 2012 22:27:09 -0700 Cc: v6ops@ietf.org, lutchann@litech.org, Behcet Sarikaya Subject: Re: [v6ops] draft-chen-v6ops-nat64-experience-02 Stateless NAT64 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 22 Jul 2012 01:26:54 -0000 Hi, On 07/18/2012 07:36 PM, Behcet Sarikaya wrote: > On Tue, Jul 17, 2012 at 8:17 PM, Aleksi Suhonen wrote: >> Yes. Stateless NAT64. http://tools.ietf.org/html/rfc6144#section-3.2.1 > Thanks for pointing this out. > But RFC 6144 is informational and what Section 3.2.1 describes is very > generic, it seems to describe kind of 4rd. > So you need to write a draft describing Stateless NAT64 :-), please. These people have been able to implement Stateless NAT64 with the existing drafts and RFCs: http://www.litech.org/tayga/ And that is the implementation we are using. I think you should contact them about any issues regarding standards conformity. Yours sincerely, -- Aleksi Suhonen, Researcher Department of Communications Engineering Tampere University of Technology From fred@cisco.com Sat Jul 21 22:31: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 4353E11E808F for ; Sat, 21 Jul 2012 22:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.496 X-Spam-Level: X-Spam-Status: No, score=-110.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6T51ODaITb7G for ; Sat, 21 Jul 2012 22:31: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 7D1FA11E808C for ; Sat, 21 Jul 2012 22:31:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=442; q=dns/txt; s=iport; t=1342935170; x=1344144770; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=1WVKCdhFRX3P88PkcBhdeS+nrwdyvfO+kU2w/7Oh6DU=; b=QS5KfZsZRN8pAsGK2UrYnoCpxPV7BGoKJj1WRyPyjLF3TTCGH1EyvKYL zXZvg+VolgKO9ymuvDFGGJZHBMZZUyy+ukmUQ/n+V2vIU6wBoCpcMeLpz 0kyO5Fhsd4+FxltS1g8sgbYaWUqfYR6JrgZxXrKHCwPbJmVhCqUTvUY15 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EANCPC1CtJV2Z/2dsb2JhbABFuV2BB4IgAQEBAwESASc/BQsCAQg2EDIlAgQOJ4dlBp8knwSLTYVzYAOVSY4ngWaCXw X-IronPort-AV: E=Sophos;i="4.77,631,1336348800"; d="scan'208";a="104133282" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 22 Jul 2012 05:32:50 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q6M5WnSP005050 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 22 Jul 2012 05:32:49 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.118]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0298.004; Sun, 22 Jul 2012 00:32:49 -0500 From: "Fred Baker (fred)" To: "" Thread-Topic: [v6ops] draft-chen-v6ops-nat64-experience-02 Stateless NAT64 Thread-Index: AQHNZ8ttnYI5ufwA3U6h5r7c96sc9g== Date: Sun, 22 Jul 2012 05:32:37 +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: [10.32.244.221] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19056.004 x-tm-as-result: No--28.468800-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 Cc: Aleksi Suhonen , "" Subject: Re: [v6ops] draft-chen-v6ops-nat64-experience-02 Stateless NAT64 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 22 Jul 2012 05:31:52 -0000 On Jul 18, 2012, at 9:36 AM, Behcet Sarikaya wrote: > So you need to write a draft describing Stateless NAT64 :-), please. Stateless IPv4/IPv6 translation is RFC 6145. Are you poking at the fact that only RFC 6146 claims the name "NAT64"? If so, I'll point out that nobody claims the name "NAT46", although draft-i= etf-pcp-base-26.txt and draft-mdt-softwire-map-dhcp-option-03.txt attempt t= o refer to it. Do the grep.= From joelja@bogus.com Sun Jul 22 18:25: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 7C96721F8608 for ; Sun, 22 Jul 2012 18:25:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.799 X-Spam-Level: X-Spam-Status: No, score=-101.799 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zHlsWyvH3uiz for ; Sun, 22 Jul 2012 18:25:27 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0B28421F853E for ; Sun, 22 Jul 2012 18:25:24 -0700 (PDT) Received: from joels-MacBook-Air.local (201.sub-166-250-34.myvzw.com [166.250.34.201]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q6N1PMow062603 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Mon, 23 Jul 2012 01:25:23 GMT (envelope-from joelja@bogus.com) Message-ID: <500CA7FC.2040209@bogus.com> Date: Sun, 22 Jul 2012 18:25:16 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120711 Thunderbird/14.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]); Mon, 23 Jul 2012 01:25:23 +0000 (UTC) Subject: [v6ops] Problem in citing http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 23 Jul 2012 01:25:27 -0000 I have seen in at least two discussions recently as well as a document that I'm reviewing citations of: http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis-02 Analysis of Solution Candidates to Reveal a Host Identifier (HOST_ID) in Shared Address Deployments From my vantage point this document analyzes the solution space, it does not solve the problem of host identification in particular it does not today mitigate problems with source identification through translation. Pointing to this document as solution, is IMHO tantamount to saying there isn't an operationally relevant solution, and should be acknowledged accordingly. The analysis in my opinion is a terribly important document and we should read it closely, and use it to inform work on the problem. thanks joel From warren@kumari.net Sun Jul 22 18: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 82C8D21F8608; Sun, 22 Jul 2012 18:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.038 X-Spam-Level: X-Spam-Status: No, score=-106.038 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ffHS8NIGo7Ut; Sun, 22 Jul 2012 18:28:33 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 6840521F85E7; Sun, 22 Jul 2012 18:28:33 -0700 (PDT) Received: from [5.5.8.21] (vpn.snozzages.com [204.194.22.7]) by vimes.kumari.net (Postfix) with ESMTPSA id 3AED41B405FA; Sun, 22 Jul 2012 21:28:32 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF02C124@xmb-rcd-x14.cisco.com> Date: Sun, 22 Jul 2012 21:28:37 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <20346E31-B14E-42FC-8AE9-F5CA97CEC38C@kumari.net> References: <20120328112128.19122.59432.idtracker@ietfa.amsl.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF02C124@xmb-rcd-x14.cisco.com> To: Michael Behringer (mbehring) X-Mailer: Apple Mail (2.1278) Cc: "grow@ietf.org" , "v6ops@ietf.org" , "draft-behringer-lla-only@tools.ietf.org" Subject: Re: [v6ops] [GROW] draft-behringer-lla-only and draft-ietf-grow-private-ip-sp-cores X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 23 Jul 2012 01:28:34 -0000 On Jul 17, 2012, at 8:48 AM, Michael Behringer (mbehring) wrote: > Wes,=20 >=20 > Thanks for your great input and sorry for the delay. In the meantime = we have updated our draft to include many of your (and others') = comments. (http://tools.ietf.org/html/draft-behringer-lla-only-01). Most = importantly, we made it now an informational draft.=20 >=20 > We believe it is best to keep the drafts separate. Excellent (actually, I believe that draft-ietf-grow-private-ip-sp-cores = lies with the IESG at the moment, and so it kinda has to stay = separate)... > There are important differences between private addresses and link = local: One is routed, one is not; one needs to be configured, one not. = We added however a xref to draft-ietf-grow-private-ip-sp-cores, because = as you rightly comment, they are related. >=20 Cool. > We still think there is value in draft-behringer-lla-only. Bottom = line, we want to provide a document presenting the issues and advantages = that allows operators to make an educated decision whether link local is = the right approach for them.=20 >=20 > We'll ask for slots in Vancouver at v6ops and opsec to discuss the new = version.=20 >=20 Excellent, and just to close the loop (so v6ops / grow folk know), you = did ask, and we've created a slot on the OpSec agenda (15min, = Wednesday, Aug 1, 13:00 - 15:00, Georgia B) for this... W =20 > Eric and Michael >=20 >> -----Original Message----- >> From: George, Wes [mailto:wesley.george@twcable.com] >> Sent: 31 March 2012 01:15 >> To: grow@ietf.org; v6ops@ietf.org >> Cc: draft-behringer-lla-only@tools.ietf.org; Anthony Kirkham >> Subject: draft-behringer-lla-only and = draft-ietf-grow-private-ip-sp-cores >> =09 >> Cross-posting to both lists again because I was unable to attend the = v6ops >> session where draft-behringer was discussed, = draft-ietf-grow-private-ip-sp- >> cores is likely nearing WGLC, and I believe that the issue I raised = needs to be >> addressed before either proceeds. I defer to the chairs of both = groups to >> determine how to manage this across the two groups. >>=20 >> After reviewing both draft-grow-private-ip-sp-cores (Kirkham) and = draft- >> behringer-lla-only again, I am even more convinced that they either = need to >> be merged, or that draft-behringer needs to be abandoned altogether = as a >> bad idea. Draft-grow-private-ip-sp-cores is quite a lot more complete = in its >> discussion of the considerations around private IP usage, but focuses = on >> IPv4, meaning that it *is* incomplete for lack of discussion of IPv6, = which is >> a reality in most SP cores today. Nearly all of the same = considerations apply >> for IPv4 and IPv6 in this case, so there are probably a limited = number of >> changes that would be necessary to cover IPv6 in the Kirkham = document. >> I think that we need to come to some consensus on the recommended >> behavior on both cases. If the recommendation is different for one = versus >> the other, we need to have a unified and clear articulation as to why = this is >> the case. It may be that the consensus is to not recommend a behavior = at all, >> and simply expand the format of Kirkham's document to cover any IPv6- >> specific items, since it discusses pros and cons evenly (as an = informational >> doc) rather than recommending anything as a BCP. My vote is to do = this, as I >> am unconvinced that use of LLA represents BCP today, nor should it. I >> outline some reasons below, but that's probably not as critical if = others >> agree that this is the proper method to proceed with these documents. >>=20 >>=20 >>=20 >> If draft-behringer is left as a separate document, here are some = specific >> comments: >> The advantages proposed in draft-behringer are IMO not enough to = justify >> recommending use of LLA. >> - Smaller routing tables can be achieved through other methods such = as >> setting the interfaces into passive mode in the IGP (so that they are = not >> redistributed into the IGP) and/or not redistributing connected = routes. >> Further, as SPs make great use of interface bundling (LAG), the = number of >> interfaces with IP addresses is dramatically reduced, making the need = to >> pull the point to point interfaces out of the routing table = significantly lower. >> - Reduced attack surface - draft-ietf-grow-private-ip-sp-cores = sections 10 >> and 11 discuss this in great detail, and come to the conclusion that = it is of >> limited benefit, and that alternatives exist to protect the = infrastructure. >> - lower configuration complexity - while this is true, it is replaced = by >> additional complexity in troubleshooting. In the case of traces and = pings >> locally on the box, it adds the additional step of requiring the = operator to >> use extended ping and trace commands to specify the exit interface in = order >> to make the ping work (vs simply issuing "ping [ip address]"), and = makes it >> nearly impossible to derive the address of the remote interface = without >> determining the remote side router through some other means and = logging >> into the router to look. (vs practice today of using an IP in the = same subnet, >> usually 1 digit up or down that can be guessed to save time). >> - less address space: The other draft mentions this as well, in the = context of >> IPv4 where it might make a difference, but this simply is not much of = a >> concern with IPv6. An entire network could be numbered many times = over >> out of one /64. >> -simpler DNS : Most ISPs operating at the scale where this makes any >> difference at all have tools to build the DNS forward and reverse = entries for >> their infrastructure automatically based on the router name and = interface >> name extracted from their inventory tools. It's a few bits of = scripting, so it's >> not like having less interfaces in DNS results in any net reduction = in work or >> increase in the possibility of mistakes. >>=20 >> - Draft-ietf-grow-private-ip-sp-cores rightly notes that the proposed >> solution to broken pings/traces/PMTUD from draft-behringer (RFC 5837) = has >> little or no implementation. This makes it a hard sell as any sort of >> recommended solution unless the benefits are much more significant = than >> what is currently discussed in draft-behringer. This has to be a = large enough >> benefit to justify pushing hard on router vendors to implement the = feature >> and SPs to certify and deploy the code, and frankly there are many = more >> important features to consider. >>=20 >> Thanks, >>=20 >> Wes George >>=20 >>=20 >>> -----Original Message----- >>> From: grow-bounces@ietf.org [mailto:grow-bounces@ietf.org] On Behalf >>> Of internet-drafts@ietf.org >>> Sent: Wednesday, March 28, 2012 7:21 AM >>> To: i-d-announce@ietf.org >>> Cc: grow@ietf.org >>> Subject: [GROW] I-D Action: = draft-ietf-grow-private-ip-sp-cores-00.txt >>>=20 >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. This draft is a work item of the Global Routing >>> Operations Working Group of the IETF. >>>=20 >>> Title : Issues with Private IP Addressing in the = Internet >>> Author(s) : Anthony Kirkham >>> Filename : draft-ietf-grow-private-ip-sp-cores-00.txt >>> Pages : 15 >>> Date : 2012-03-28 >>>=20 >>> The purpose of this document is to provide a discussion of the >>> potential problems of using private, RFC1918, or non-globally- >>> routable addressing within the core of an SP network. The = discussion >>> focuses on link addresses and to a small extent loopback = addresses. >>> While many of the issues are well recognised within the ISP >>> community, there appears to be no document that collectively >>> describes the issues. >>>=20 >>>=20 >>> A URL for this Internet-Draft is: >>> = http://www.ietf.org/internet-drafts/draft-ietf-grow-private-ip-sp-core >>> s-00.txt >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> This Internet-Draft can be retrieved at: >>> = ftp://ftp.ietf.org/internet-drafts/draft-ietf-grow-private-ip-sp-cores >>> -00.txt >>>=20 >>> _______________________________________________ >>> GROW mailing list >>> GROW@ietf.org >>> https://www.ietf.org/mailman/listinfo/grow >>=20 >> This E-mail and any of its attachments may contain Time Warner Cable >> proprietary information, which is privileged, confidential, or = subject to >> copyright belonging to Time Warner Cable. This E-mail is intended = solely for >> the use of the individual or entity to which it is addressed. If you = are not the >> intended recipient of this E-mail, you are hereby notified that any >> dissemination, distribution, copying, or action taken in relation to = the >> contents of and attachments to this E-mail is strictly prohibited and = may be >> unlawful. If you have received this E-mail in error, please notify = the sender >> immediately and permanently delete the original and any copy of this = E- >> mail and any printout. > _______________________________________________ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow >=20 -- "Build a man a fire, and he'll be warm for a day. Set a man on fire, and = he'll be warm for the rest of his life." -- Terry Pratchett From dr@cluenet.de Sun Jul 22 23:06: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 08D7B11E8072 for ; Sun, 22 Jul 2012 23:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_53=0.6, J_CHICKENPOX_55=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R2wGrt6SV4rm for ; Sun, 22 Jul 2012 23:06:49 -0700 (PDT) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by ietfa.amsl.com (Postfix) with ESMTP id 90EF511E8079 for ; Sun, 22 Jul 2012 23:06:47 -0700 (PDT) Received: by mail1.cluenet.de (Postfix, from userid 500) id 98D731086EC; Mon, 23 Jul 2012 08:06:45 +0200 (CEST) Date: Mon, 23 Jul 2012 08:06:45 +0200 From: Daniel Roesen To: v6ops@ietf.org Message-ID: <20120723060645.GA3207@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org References: <5006E47F.8010605@forthnetgroup.gr> <7B65A922-9936-42EE-B1AA-172941525FEA@apple.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7B65A922-9936-42EE-B1AA-172941525FEA@apple.com> X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [v6ops] current solutions for incoming connections in CGN environments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 23 Jul 2012 06:06:50 -0000 On Wed, Jul 18, 2012 at 10:23:58AM -0700, james woodyatt wrote: > In particular, I'd like to know about any such gateways that have > Simple Security enabled in the default configuration. AVM Fritz!Box. But you can configure holes to specific hosts+ports in the LAN. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From Carl.Wuyts@technicolor.com Sun Jul 22 23:21: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 01E6621F8624 for ; Sun, 22 Jul 2012 23:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.549 X-Spam-Level: X-Spam-Status: No, score=-5.549 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O5KwBhkhWNXQ for ; Sun, 22 Jul 2012 23:21:11 -0700 (PDT) Received: from na3sys009aog124.obsmtp.com (na3sys009aog124.obsmtp.com [74.125.149.151]) by ietfa.amsl.com (Postfix) with ESMTP id 78B7421F8620 for ; Sun, 22 Jul 2012 23:21:08 -0700 (PDT) Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob124.postini.com ([74.125.148.12]) with SMTP ID DSNKUAztU168ZzE+OeEBJnKIMjvB1BCRe1a4@postini.com; Sun, 22 Jul 2012 23:21:11 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; Mon, 23 Jul 2012 08:21:04 +0200 Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.192]) by MOPESMAILHC02.eu.thmulti.com ([141.11.100.29]) with mapi; Mon, 23 Jul 2012 08:21:05 +0200 From: Wuyts Carl To: Daniel Roesen , "v6ops@ietf.org" Date: Mon, 23 Jul 2012 08:21:05 +0200 Thread-Topic: [v6ops] current solutions for incoming connections in CGN environments Thread-Index: Ac1omWOd+P0W5CDVSWuXSkIJFASyoAAAbGxw Message-ID: <867F4B6A1672E541A94676D556793ACD149FBE6E44@MOPESMBX01.eu.thmulti.com> References: <5006E47F.8010605@forthnetgroup.gr> <7B65A922-9936-42EE-B1AA-172941525FEA@apple.com> <20120723060645.GA3207@srv03.cluenet.de> In-Reply-To: <20120723060645.GA3207@srv03.cluenet.de> 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] current solutions for incoming connections in CGN environments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 23 Jul 2012 06:21:12 -0000 Same for the Technicolor CPE. By default: drop unsollicited inbound traffi= c and (optionally) punch holes for specific traffic if needed. Regs Carl -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of D= aniel Roesen Sent: maandag 23 juli 2012 8:07 To: v6ops@ietf.org Subject: Re: [v6ops] current solutions for incoming connections in CGN envi= ronments On Wed, Jul 18, 2012 at 10:23:58AM -0700, james woodyatt wrote: > In particular, I'd like to know about any such gateways that have=20 > Simple Security enabled in the default configuration. AVM Fritz!Box. But you can configure holes to specific hosts+ports in the L= AN. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 ________= _______________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From tjc@ecs.soton.ac.uk Mon Jul 23 07:00: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 1986F11E8072 for ; Mon, 23 Jul 2012 07:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.319 X-Spam-Level: X-Spam-Status: No, score=-2.319 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7v+EOTlwATU for ; Mon, 23 Jul 2012 07:00: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 A163911E8089 for ; Mon, 23 Jul 2012 07:00:54 -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 q6NE0lpU013726 for ; Mon, 23 Jul 2012 15:00:47 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk q6NE0lpU013726 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1343052048; bh=KgXG06hxnVrfZZyTeu2vrvwjKqU=; h=From:Mime-Version:Subject:Date:In-Reply-To:To:References; b=KbRVH0B21GVRWGMi1vHoV2Nu+QYLT8N0nbFjiGpcicN4th93fh+HddIqmuA6nEFrJ IT9zbhsQFR4rlxE+76MlIftm72ziblVV0DsP9xXIXohsF+/cEsBJytfcPOYOO5dPQG +eh6wwn9ponT0HhIOA4YE/XdunJDaxxPqCjXwiQo= 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 o6MF0l0430661306sn ret-id none; Mon, 23 Jul 2012 15:00:47 +0100 Received: from ip-204-173.eduroam.soton.ac.uk (ip-204-173.eduroam.soton.ac.uk [152.78.204.173]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q6NE0jC1023208 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 23 Jul 2012 15:00:45 +0100 From: Tim Chown Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_5FFFB3E3-ADF5-412E-9DF0-D82A6DA74F29" Date: Mon, 23 Jul 2012 15:00:44 +0100 In-Reply-To: To: "v6ops@ietf.org WG" References: <5006E47F.8010605@forthnetgroup.gr> <5006FE33.7090903@forthnetgroup.gr> <20120718191000.GW38127@Space.Net> <50071D89.9070601@forthnetgroup.gr> <938CD4C2-6A04-4BBD-AB1E-F9570FF16C12@ecs.soton.ac.uk> Message-ID: X-Mailer: Apple Mail (2.1278) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=o6MF0l043066130600; tid=o6MF0l0430661306sn; 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: q6NE0lpU013726 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [v6ops] current solutions for incoming connections in CGN environments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 23 Jul 2012 14:00:56 -0000 --Apple-Mail=_5FFFB3E3-ADF5-412E-9DF0-D82A6DA74F29 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 19 Jul 2012, at 09:15, Lorenzo Colitti wrote: > On Thu, Jul 19, 2012 at 5:33 AM, Tassos Chatzithomaoglou = wrote: > Our IPv6 is completed, our DS-Lite will be completed soon, our = customers are growing, our IPv4 addresses will be over soon...and IPv4 = content (and traffic?) is still ~99%. > Am i missing something obvious? >=20 > Yes, you are. If your IPv4 traffic is 99%, then your IPv6 project is = not "completed". There is much more than 1% of content and traffic on = IPv6. As AT&T says: "For our IPv6 enabled customers, we=92re seeing more = than 20 percent of traffic transition to IPv6": = http://www.attinnovationspace.com/innovation/story/a7782696 . If you = don't have enough IPv6 traffic, you probably haven't deployed IPv6 to = enough users. I have seen other reports/measurements of over 40%, and in some cases = 50%, of web content (by traffic volume, not by sites enabled) available = over IPv6. W6L has blown away that 1% stat.=20 Tim= --Apple-Mail=_5FFFB3E3-ADF5-412E-9DF0-D82A6DA74F29 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Thu, Jul 19, 2012 at 5:33 = AM, Tassos Chatzithomaoglou <achatz@forthnetgroup.gr> = wrote:
Our IPv6 is completed, our DS-Lite will be completed soon, our customers = are growing, our IPv4 addresses will be over soon...and IPv4 content = (and traffic?) is still ~99%.
Am i missing something obvious?

Yes, = you are. If your IPv4 traffic is 99%, then your IPv6 project is not = "completed". There is much more than 1% of content and traffic on = IPv6. As AT&T says: "For our IPv6 enabled customers, we=92re seeing = more than 20 percent of traffic transition to IPv6": http:= //www.attinnovationspace.com/innovation/story/a7782696 . If you = don't have enough IPv6 traffic, you probably haven't deployed IPv6 to = enough users.

I have seen other = reports/measurements of over 40%, and in some cases 50%, of web content = (by traffic volume, not by sites enabled) available over IPv6.  W6L = has blown away that 1% = stat. 

Tim
= --Apple-Mail=_5FFFB3E3-ADF5-412E-9DF0-D82A6DA74F29-- From sarikaya2012@gmail.com Mon Jul 23 11:28: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 31F7121F85D6 for ; Mon, 23 Jul 2012 11:28:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.55 X-Spam-Level: X-Spam-Status: No, score=-3.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id enlNfWMMNGlj for ; Mon, 23 Jul 2012 11:28:24 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 652DD21F85AA for ; Mon, 23 Jul 2012 11:28:24 -0700 (PDT) Received: by ghbg16 with SMTP id g16so6344219ghb.31 for ; Mon, 23 Jul 2012 11:28:24 -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=oW8+KgV+1AJVyu1j5TzzP0rPQqGEs6WALGyPho1qryo=; b=WwqCuCPkLRrFbkWyEgFowXFyRpV/ORU/VNsR4/4hgJiFJeYZeC9pC2XKCwDe84MBsY 7rAYTqppuLgjOSAD5czE+gha6o5e0LOkFLHuC6PkjBs8xKSfNeXULazLM1x9+7qeZBT4 UULR7vJxhgyeanidtYQSwPSbbCBG0oUtS+5WYBTWg2UzDFm8thp4v8+azDoIwhC7bnIs wv0UAQEV7H8MVuaFGjWKADKsjOwnoY8wTsavYU3aQRivv+2m3KOmgFWr64Ax5TinaNOH Qw2bcJcLwV06Lrj6KNpd7wtulr497Che5+Axvgq0ajblf5GvlKS5enOkP6RxZHSE5aQl 3sDA== MIME-Version: 1.0 Received: by 10.50.194.132 with SMTP id hw4mr11471199igc.63.1343068103166; Mon, 23 Jul 2012 11:28:23 -0700 (PDT) Received: by 10.231.207.167 with HTTP; Mon, 23 Jul 2012 11:28:23 -0700 (PDT) In-Reply-To: <500B5715.8050002@tut.fi> References: <500B5715.8050002@tut.fi> Date: Mon, 23 Jul 2012 13:28:23 -0500 Message-ID: From: Behcet Sarikaya To: Aleksi Suhonen Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops@ietf.org, lutchann@litech.org Subject: Re: [v6ops] draft-chen-v6ops-nat64-experience-02 Stateless NAT64 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: Mon, 23 Jul 2012 18:28:25 -0000 On Sat, Jul 21, 2012 at 8:27 PM, Aleksi Suhonen wrote: > Hi, > > > On 07/18/2012 07:36 PM, Behcet Sarikaya wrote: >> >> On Tue, Jul 17, 2012 at 8:17 PM, Aleksi Suhonen >> wrote: >>> >>> Yes. Stateless NAT64. http://tools.ietf.org/html/rfc6144#section-3.2.1 > > >> Thanks for pointing this out. >> But RFC 6144 is informational and what Section 3.2.1 describes is very >> generic, it seems to describe kind of 4rd. > > >> So you need to write a draft describing Stateless NAT64 :-), please. > > > These people have been able to implement Stateless NAT64 with the existing > drafts and RFCs: > > http://www.litech.org/tayga/ > > And that is the implementation we are using. I think you should contact them > about any issues regarding standards conformity. > Thanks for pointing this out. I am still puzzled, tayga is using DNS64 and they talk about NAT44. Maybe you can explain their solution approach to me then I would be happy to help document it :-)? Regards, Behcet From pkern@spike.0x539.de Mon Jul 23 11:34: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 848D611E80E2 for ; Mon, 23 Jul 2012 11:34:20 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tETVcYM4FBQH for ; Mon, 23 Jul 2012 11:34:20 -0700 (PDT) Received: from hub.kern.lc (hub.kern.lc [IPv6:2a00:1158:3::c7]) by ietfa.amsl.com (Postfix) with ESMTP id CA80511E80BF for ; Mon, 23 Jul 2012 11:34:19 -0700 (PDT) Received: from [2001:470:720c:0:4c13:bfca:540c:fb80] (helo=spike.0x539.de) by hub.kern.lc with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1StNSL-0007Wi-2o; Mon, 23 Jul 2012 20:34:09 +0200 Received: from pkern by spike.0x539.de with local (Exim 4.80) (envelope-from ) id 1StNSP-000411-SR; Mon, 23 Jul 2012 20:34:13 +0200 Date: Mon, 23 Jul 2012 20:34:13 +0200 From: Philipp Kern To: sarikaya@ieee.org Message-ID: <20120723183413.GB14528@spike.0x539.de> References: <500B5715.8050002@tut.fi> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="3uo+9/B/ebqu+fSQ" Content-Disposition: inline In-Reply-To: Organization: Fachschaft Mathematik / Informatik am Karlsruher Institut fuer Technologie (KIT) User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Aleksi Suhonen , v6ops@ietf.org, lutchann@litech.org Subject: Re: [v6ops] draft-chen-v6ops-nat64-experience-02 Stateless NAT64 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 23 Jul 2012 18:40:56 -0000 --3uo+9/B/ebqu+fSQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Behcet, am Mon, Jul 23, 2012 at 01:28:23PM -0500 hast du folgendes geschrieben: > Thanks for pointing this out. I am still puzzled, tayga is using DNS64 > and they talk about NAT44. tayga implements NAT64, not DNS64 (for instance bind9 could be used for the latter). NAT44 is needed because the IPv6 source addresses are mapped into a private IPv4 pool by default, which then needs masquerading (aka NAT44) into the public internet. The site even says this: | The dynamic pool can be chosen from private IPv4 address space | (10.x.x.x, 192.168.x.x, etc) and can be of any size, although it needs | to be large enough to contain one IPv4 address for every IPv6 host | that needs to use the NAT64. Of course you could also use public space without NAT44, but then you're back to one public IPv4 address per client. Kind regards Philipp Kern --3uo+9/B/ebqu+fSQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEAREIAAYFAlANmSUACgkQ7Ro5M7LPzdjZ6gCg8xe4ah2IoCZH8A2Zkhor/D0a TlgAoIeg2cCXPD+53LV8seOVtPgpR30p =eQpl -----END PGP SIGNATURE----- --3uo+9/B/ebqu+fSQ-- From sarikaya2012@gmail.com Mon Jul 23 12:29: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 42C0121F842B; Mon, 23 Jul 2012 12:29:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.551 X-Spam-Level: X-Spam-Status: No, score=-3.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dqj8ag3ZxlYq; Mon, 23 Jul 2012 12:29:54 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 431B621F841E; Mon, 23 Jul 2012 12:29:54 -0700 (PDT) Received: by ghbg16 with SMTP id g16so6418055ghb.31 for ; Mon, 23 Jul 2012 12:29:53 -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=i5ECtGMAeDi6OUydL+NpbkT76uXtMK60DUqNDvYEWDA=; b=QTgTNdlxqQbq8LqHs+U1Jg9n5v0+jR9qZ4RhED5kb569p+mvV1n+lgEWcMTQx1ZnvB uo23t8sg/FD77RmOJ+5KKJevQ1i0XiLfmQNSbDnTul9J6hYgnfLsmHPCb6+nnEWya462 tx2TF8HyPOwxxO3uDFhGmsAfX2G+YmrBzHAJHBj5Yd3Iahw56WIyxWR1Knf7gMgYj8qI 9TvkULlC7Kjefw/MoDwFEbMdq4ji5ovCgqczPaeJH7jaYB2iHJhOuDFn4fkJ+MFCZSqn sWkQMNczbJeHkeC8V43/KIM/k3ULm7qIbu4HWjcvQaXItuznSsqa2oXH+1PvMjqoULix vfXA== MIME-Version: 1.0 Received: by 10.236.201.161 with SMTP id b21mr8316764yho.41.1343071793787; Mon, 23 Jul 2012 12:29:53 -0700 (PDT) Received: by 10.231.207.167 with HTTP; Mon, 23 Jul 2012 12:29:53 -0700 (PDT) In-Reply-To: References: <4FF696AA.3050508@tut.fi> <500B5A2D.6000408@tut.fi> Date: Mon, 23 Jul 2012 14:29:53 -0500 Message-ID: From: Behcet Sarikaya To: GangChen Content-Type: text/plain; charset=ISO-8859-1 Cc: Aleksi Suhonen , v6ops , "ipv6@ietf.org" Subject: Re: [v6ops] draft-chen-v6ops-nat64-experience-02 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: Mon, 23 Jul 2012 19:29:55 -0000 > > Please take a look at Page13~22 at > http://fud.no/talks/20120417-RIPE64-The_Case_for_IPv6_Only_Data_Centres.pdf > > If a stateless translator maintains the binding information of > *src.IPv6->src.IPv4 address*, the essential feature of "Does not > require flows to flow bidirectionally across a single translator" > would lose. > Exactly. I now understood what is meant by Stateless NAT64 reading the above presentation. It solves the reverse problem of IPv4-only client talking to IPv6-only server. Regards, Behcet From joelja@bogus.com Tue Jul 24 00:41: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 01D9821F84F1 for ; Tue, 24 Jul 2012 00:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.809 X-Spam-Level: X-Spam-Status: No, score=-100.809 tagged_above=-999 required=5 tests=[AWL=-1.260, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uA-mtB6Y-vb7 for ; Tue, 24 Jul 2012 00:41:50 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 59A3821F84E4 for ; Tue, 24 Jul 2012 00:41:50 -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 q6O7fjgH072287 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 24 Jul 2012 07:41:46 GMT (envelope-from joelja@bogus.com) Message-ID: <500E51B9.2020905@bogus.com> Date: Tue, 24 Jul 2012 00:41:45 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120711 Thunderbird/14.0 MIME-Version: 1.0 To: Tina TSOU References: <0B2FA58F71A34C199446380DA654FB07@LENOVO1E4798BB> <1DFE8BF4-885E-4F2F-AA1B-4FC1658BA688@cisco.com> <4FF7077B.5050703@bogus.com>, <5D36713D8A4E7348A7E10DF7437A4B9239EF7244@szxeml545-mbx.china.huawei.com> <8C9DC6AF-764D-49D5-9C6A-98776E532407@huawei.com> In-Reply-To: <8C9DC6AF-764D-49D5-9C6A-98776E532407@huawei.com> Content-Type: text/plain; charset=GB2312 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]); Tue, 24 Jul 2012 07:41:46 +0000 (UTC) Cc: IPv6 Ops WG Subject: Re: [v6ops] Call for Adoption, was Re: New draft waiting for adoption: draft-chen-v6ops-nat64-experience-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 24 Jul 2012 07:41:51 -0000 On 7/20/12 9:25 PM, Tina TSOU wrote: > Support with comments below. > > In the draft, NAT64 was compared with dual stack network where more > cost is involved while managing two stacks of protocol. If NAT64 is a > way of coexistence of IPv6 and IPv4, a brief discussion of tunneling > options compared to NAT64 can be added. Moreover, in the deployment > considerations, in case NAT64 is integrated with an existing gateway, > what would be the possible impacts and memory requirements of the > gateway. There would a data base maintained of the mapping, that might > demand more resources. Deploying it ¡°close to BNG or CR has few > impacts ¡° ¨Cif there can be few examples of the impacts. The assertions about cost bound up in the document I don't buy at all. Particularly in the context of CGN deployment. You're not likely to build in consensus in the in v6ops that dual stack deployment is dramatically more expensive that the alternative (outside cases where externalities such as licensing apply), so if you're headed that direction you should be prepared to marshall a rather convincing argument. > Based on my NAT64 experience, the NAT64 gateway should also define > routes to the block of addresses (for example ::/96 ipv6 address > block) used to represent IPv4 address. If a.b.c.d is used to represent > s:f:g:h::1 then there should be routes to a.b.c.d as well to > successfully NAT. In my opinion, this is an important implementation > requirement. > In NAT64-CE Networking paragraph, I did not get this line: ¡°One big > challenge is NAT64-CE facing IPv6 Internet, on which a significant > IPv6 users may connect to.¡± Given that I'm unconvinced in the context of DC migration that placing a nat64 translator in front of a load balancer is a good idea, I certainly wouldn't support it here either. stacking stateful devices is expensive state-wise (as that section asserts), results in additional latency, loses the source address if you're doing a transform and so on, the previous section attempts to assert that the existence of the mapping to source address is valuable, and indeed it is so much so that correlation after the fact isn't a substitution for having that data when the connection is made. an earlier section cites draft-ietf-intarea-nat-reveal-analysis-02 in the case of addressing the loss of source address, that sort of demonstrates the scope of the problem since that document doesn't solve it. > Tina > > On Jul 20, 2012, at 4:47 PM, "Sheng Jiang" > wrote: > >> Support for WG adoption. Quite useful experience for other ISPs. >> >> Sheng >> >>> -----Original Message----- >>> From: v6ops-bounces@ietf.org >>> [mailto:v6ops-bounces@ietf.org] On Behalf >>> Of Joel jaeggli >>> Sent: Friday, July 06, 2012 11:43 PM >>> To: IPv6 Ops WG >>> Subject: [v6ops] Call for Adoption, was Re: New draft waiting for >>> adoption: >>> draft-chen-v6ops-nat64-experience-02 >>> >>> The following message commences a 1 week call for opinions on the >>> adoption of draft-chen-v6ops-nat64-experience-02 >>> >>> http://tools.ietf.org/html/draft-chen-v6ops-nat64-experience-02 >>> >>> Friday 7/13/2012 is the deadline for this particular call. >>> >>> Thank you. >>> joel >>> >>>>> ÆóÒµ±ê×¼µÄÎı¾¸ñʽ£¨Ä£°æ£© >>>>> >>>>> Dear Chairs, >>>>> >>>>> >>>>> >>>>> We have posted new draft of NAT64 experiences. >>>>> >>>>> Current draft is a joined effort from four operators (China Mobile, >>>>> T-mobile USA, China Telecom and France Telecom) >>>>> >>>>> who is actively progressing IPv6 deployment depending on the >>>>> practices. >>>>> >>>>> Several experts encourage us to continue the work after their kind >>>>> review >>>>> >>>>> >>>>> >>>>> For now, we have addressed all comments. >>>>> >>>>> The draft is ready for the adoption. >>>>> >>>>> The authors would like to consult your opinions and look forward your >>>>> guidance. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Many thanks >>>>> >>>>> >>>>> >>>>> Authors >>>>> >>>>> >>>>> >>>>> ===================================================== >>>>> >>>>> A new version of I-D, draft-chen-v6ops-nat64-experience-02.txt >>>>> >>>>> has been successfully submitted by Gang Chen and posted to the >>>>> >>>>> IETF repository. >>>>> >>>>> >>>>> >>>>> Filename: draft-chen-v6ops-nat64-experience >>>>> >>>>> Revision: 02 >>>>> >>>>> Title: NAT64 Operational Experiences >>>>> >>>>> Creation date: 2012-07-04 >>>>> >>>>> WG ID: Individual Submission >>>>> >>>>> Number of pages: 15 >>>>> >>>>> URL: >>>>> >>> http://www.ietf.org/internet-drafts/draft-chen-v6ops-nat64-experience-02. >>> txt >>>>> >>>>> Status: >>>>> http://datatracker.ietf.org/doc/draft-chen-v6ops-nat64-experience >>>>> >>>>> Htmlized: >>>>> http://tools.ietf.org/html/draft-chen-v6ops-nat64-experience-02 >>>>> >>>>> Diff: >>>>> http://tools.ietf.org/rfcdiff?url2=draft-chen-v6ops-nat64-experience-02 >>>>> >>>>> >>>>> >>>>> Abstract: >>>>> >>>>> This document summarizes some stateful NAT64 deployment >>> scenarios and >>>>> >>>>> operational experiences for NAT64-CGN and NAT64-CE. >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >>> _______________________________________________ >>> 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 wang.cui1@zte.com.cn Tue Jul 24 00:46: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 2FC6A21F8601 for ; Tue, 24 Jul 2012 00:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.601 X-Spam-Level: X-Spam-Status: No, score=-98.601 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, MIME_BASE64_TEXT=1.753, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yfdxNyXqZNnL for ; Tue, 24 Jul 2012 00:46:26 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 4400F21F85E6 for ; Tue, 24 Jul 2012 00:46:26 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 10723102519342; Tue, 24 Jul 2012 15:36:43 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 60404.1353729570; Tue, 24 Jul 2012 15:46:22 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q6O7kHws080607; Tue, 24 Jul 2012 15:46:17 +0800 (GMT-8) (envelope-from wang.cui1@zte.com.cn) To: estrellazhang2012@gmail.com MIME-Version: 1.0 X-KeepSent: D22200D9:689DC01C-48257A45:00299C89; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: wang.cui1@zte.com.cn Date: Tue, 24 Jul 2012 15:46:16 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-07-24 15:46:16, Serialize complete at 2012-07-24 15:46:16 Content-Type: multipart/alternative; boundary="=_alternative 002A930E48257A45_=" X-MAIL: mse02.zte.com.cn q6O7kHws080607 Cc: v6ops@ietf.org Subject: [v6ops] "RE: goals of draft-zhang-v6ops-ipv6oa-iwf-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: Tue, 24 Jul 2012 07:46:27 -0000 This is a multipart message in MIME format. --=_alternative 002A930E48257A45_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksDQoNCkkgaGF2ZSB0aHJvdWdobHkgcmVhZCB0aGlzIGRyYWZ0IGFuZCB0aGUgZGlzY3Vzc2lv bnMgb24gdGhlIG1haWxpbmcgbGlzdCwNCnRoZSBwcmV2aW91cyBxdWVzdGlvbnMgZnJvbSBmcmVk IGFuZCBKLlMgaGVscCBteSB1bmRlcnN0YW5kaW5nIGFib3V0IHRoaXMgDQpkcmFmdCwgDQphbmQg dGhpcyBzb2x1dGlvbiBzZWVtcyBtb3JlIGVjb25vbWljYWwgd2hpY2gganVzdCBuZWVkIHVwZGF0 ZXMgdGhlIA0KdmVyc2lvbiBvZiANCnRoZSBBVE0gbm9kZXMgdGhhbiBidXlpbmcgZXh0cmEgZXF1 aXBtZW50cyB0byByZXBsYWNlIHRoZSBsb2NhdGVkIEFUTSANCm5vZGVzIG9yIEFUTSBuZXR3b3Jr o7sgDQoNCkJ1dCBoZXJlIEkgaGF2ZSBhIGNvbW1lbnQ6IA0KDQogICAgMSkgWW91IHNhaWQgdGhl ICJJbnRlcndvcmtpbmcgRnVuY3Rpb24iIGlzIGEgbGF5ZXIgMiBub2RlLCBidXQgaW4gDQpzZWN0 aW9uIDQuMix3aGF0IHRoZSBJUHY2b0EgSVdGIGRvIHNlZW1zIGxpa2UgYSANCiAgICAgICAgbGF5 ZXIgMyBub2RlIGJlY2F1c2UgdGhpcyBub2RlIGhhcyB0byBkZWFsIHdpdGggSVAgYWRkcmVzcy4g V2hhdCANCmRvIHlvdSB0aGluayA/IA0KDQpUaGFua3N+DQpDdWkgV2FuZw0KDQoNCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5m b3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRo aXMgbWFpbCAoYW5kIGFueSBhdHRhY2htZW50IHRyYW5zbWl0dGVkIGhlcmV3aXRoKSBpcyBwcml2 aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIGZvciB0aGUgZXhjbHVzaXZl IHVzZSBvZiB0aGUgYWRkcmVzc2VlKHMpLiAgSWYgeW91IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVj aXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRpb24gb3Igb3Ro ZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBz dHJpY3RseSBwcm9oaWJpdGVkLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtYWlsIGluIGVy cm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMgaW1tZWRpYXRlbHkuDQoNCg== --=_alternative 002A930E48257A45_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLDwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SSBoYXZlIHRocm91Z2hseSByZWFkIHRo aXMgZHJhZnQgYW5kDQp0aGUgZGlzY3Vzc2lvbnMgb24gdGhlIG1haWxpbmcgbGlzdCw8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPnRoZSBwcmV2aW91cyBxdWVzdGlv bnMgZnJvbSBmcmVkIGFuZA0KSi5TIGhlbHAgbXkgdW5kZXJzdGFuZGluZyBhYm91dCB0aGlzIGRy YWZ0LCA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmFuZCB0aGlz IHNvbHV0aW9uIHNlZW1zIG1vcmUgZWNvbm9taWNhbA0Kd2hpY2gganVzdCBuZWVkIHVwZGF0ZXMg dGhlIHZlcnNpb24gb2Y8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IsvOzOUiPg0KPC9mb250Pjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQp0aGUgQVRNIG5vZGVzIHRoYW4gYnV5 aW5nIGV4dHJhIGVxdWlwbWVudHMgdG8gcmVwbGFjZSB0aGUgbG9jYXRlZCBBVE0gbm9kZXMNCm9y IEFUTSBuZXR3b3JrPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSLLzszlIj6juzwvZm9udD48Zm9u dCBzaXplPTMgZmFjZT0iy87M5SI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPjxicj4NCkJ1dCBoZXJlIEkgaGF2ZSBhIGNvbW1lbnQ6PC9mb250Pjxmb250IHNp emU9MyBmYWNlPSLLzszlIj4gPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj48YnI+DQogJm5ic3A7ICZuYnNwOzEpIFlvdSBzYWlkIDwvZm9udD48Zm9udCBzaXplPTMg ZmFjZT0iy87M5SI+dGhlICZxdW90O0ludGVyd29ya2luZw0KRnVuY3Rpb24mcXVvdDs8L2ZvbnQ+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiBpcyBhIGxheWVyIDIgbm9kZSwNCmJ1dCBp biBzZWN0aW9uIDQuMix3aGF0IHRoZSBJUHY2b0EgSVdGIGRvIHNlZW1zIGxpa2UgYSA8L2ZvbnQ+ PGZvbnQgc2l6ZT0zIGZhY2U9IsvOzOUiPjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2xheWVyDQozIG5vZGUgYmVj YXVzZSB0aGlzIG5vZGUgaGFzIHRvIGRlYWwgd2l0aCBJUCBhZGRyZXNzLiBXaGF0IGRvIHlvdSB0 aGluaw0KPyA8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi PlRoYW5rc348L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkN1aSBX YW5nPC9mb250Pg0KPGJyPjxwcmU+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFJm5ic3A7SW5mb3JtYXRpb24mbmJzcDtTZWN1cml0 eSZuYnNwO05vdGljZTombmJzcDtUaGUmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO2NvbnRhaW5lZCZu YnNwO2luJm5ic3A7dGhpcyZuYnNwO21haWwmbmJzcDsoYW5kJm5ic3A7YW55Jm5ic3A7YXR0YWNo bWVudCZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7aGVyZXdpdGgpJm5ic3A7aXMmbmJzcDtwcml2aWxl Z2VkJm5ic3A7YW5kJm5ic3A7Y29uZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7aXMmbmJzcDtpbnRl bmRlZCZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO2V4Y2x1c2l2ZSZuYnNwO3VzZSZuYnNwO29mJm5i c3A7dGhlJm5ic3A7YWRkcmVzc2VlKHMpLiZuYnNwOyZuYnNwO0lmJm5ic3A7eW91Jm5ic3A7YXJl Jm5ic3A7bm90Jm5ic3A7YW4mbmJzcDtpbnRlbmRlZCZuYnNwO3JlY2lwaWVudCwmbmJzcDthbnkm bmJzcDtkaXNjbG9zdXJlLCZuYnNwO3JlcHJvZHVjdGlvbiwmbmJzcDtkaXN0cmlidXRpb24mbmJz cDtvciZuYnNwO290aGVyJm5ic3A7ZGlzc2VtaW5hdGlvbiZuYnNwO29yJm5ic3A7dXNlJm5ic3A7 b2YmbmJzcDt0aGUmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO2NvbnRhaW5lZCZuYnNwO2lzJm5ic3A7 c3RyaWN0bHkmbmJzcDtwcm9oaWJpdGVkLiZuYnNwOyZuYnNwO0lmJm5ic3A7eW91Jm5ic3A7aGF2 ZSZuYnNwO3JlY2VpdmVkJm5ic3A7dGhpcyZuYnNwO21haWwmbmJzcDtpbiZuYnNwO2Vycm9yLCZu YnNwO3BsZWFzZSZuYnNwO2RlbGV0ZSZuYnNwO2l0Jm5ic3A7YW5kJm5ic3A7bm90aWZ5Jm5ic3A7 dXMmbmJzcDtpbW1lZGlhdGVseS4NCg0KPC9wcmU+ --=_alternative 002A930E48257A45_=-- From Francis.Dupont@fdupont.fr Tue Jul 24 03:45: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 B23E221F8609 for ; Tue, 24 Jul 2012 03:45:51 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BhscmgiYDqbA for ; Tue, 24 Jul 2012 03:45:51 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 7141321F8608 for ; Tue, 24 Jul 2012 03:45:50 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q6OAjj3Y048198; Tue, 24 Jul 2012 12:45:46 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201207241045.q6OAjj3Y048198@givry.fdupont.fr> From: Francis Dupont To: Tassos Chatzithomaoglou In-reply-to: Your message of Wed, 18 Jul 2012 19:29:51 +0300. <5006E47F.8010605@forthnetgroup.gr> Date: Tue, 24 Jul 2012 12:45:45 +0200 Sender: Francis.Dupont@fdupont.fr Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] current solutions for incoming connections in CGN environments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 24 Jul 2012 10:45:51 -0000 In your previous mail you wrote: > I'm looking for opinions and recommendations regarding the known > limitations with incoming connections & port forwarding in CGN-like > environments (preferably DS-Lite), in environments with multiple > layers of NAT or when NAT is not taking place on the CPE. => UPnP IGD v2 (with the whole new framework, BTW not the v1) does the job but I don't know if it is popular for CGN vendors. BTW it was published ~20 months ago... > If i'm not mistaken, currently you cannot have such a functionality > based on standards. => define "standards" (:-)... Regards Francis.Dupont@fdupont.fr PS: I know the IPv6 part (IPv6 firewall control, more CPE oriented) was implemented. BTW this has no equivalent in PCP yet. From gert@space.net Tue Jul 24 07:28: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 D55AD21F8535 for ; Tue, 24 Jul 2012 07:28:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.253 X-Spam-Level: X-Spam-Status: No, score=-2.253 tagged_above=-999 required=5 tests=[AWL=-0.254, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dj3es24uHmT1 for ; Tue, 24 Jul 2012 07:28:39 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2278C21F85DB for ; Tue, 24 Jul 2012 07:28:37 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 67555F8C3D for ; Tue, 24 Jul 2012 16:28:36 +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 2A165F8C3E for ; Tue, 24 Jul 2012 16:28:36 +0200 (CEST) Received: (qmail 37348 invoked by uid 1007); 24 Jul 2012 16:28:36 +0200 Date: Tue, 24 Jul 2012 16:28:36 +0200 From: Gert Doering To: Mikael Abrahamsson Message-ID: <20120724142836.GL38127@Space.Net> References: <4FFEC0A4.2070509@gmail.com> <20120712131000.GC38127@Space.Net> <20120712.154239.133898240.he@uninett.no> <20120712142354.GH38127@Space.Net> <4FFF01AF.3000502@gmail.com> <20120712175734.GM38127@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1FASoxBNj+w9tqcF" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: v6ops@ietf.org Subject: Re: [v6ops] What can v6ops do? [was: RIPE-555 fundamentaly changes the way how we can filter IPv6 & IPv4 martians?] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 24 Jul 2012 14:28:40 -0000 --1FASoxBNj+w9tqcF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, coming back to this: On Fri, Jul 13, 2012 at 07:52:13AM +0200, Mikael Abrahamsson wrote: > On Thu, 12 Jul 2012, Gert Doering wrote: >=20 > > - make "multihoming with dual-/48" *work*, so one of the incentives for > > end-site multihoming with a globally visible route goes away >=20 > Yes, please. It actually works quite well today - except for proper source address selection *failover* in the face of failing connections. Sort of=20 "happy eyeballs .bis"... most simple example: home network has two ISPs, A and B, both assigning a /48, both offering "access to the Internet", so both are valid as "default route" host on LAN has two IPv6 addresses, "A" and "B" router(s) do source-based routing, packets with source address "A"=20 goes to ISP "A", packets with source address "B" goes to ISP "B" (this is a strong MUST as ISPs are encouraged to do BCP38 filtering) user types "www.google.com" into browser source address selection selects "use source address A" ISP A has "issues", and the connection to Google never succeeds browser falls over to IPv4... what is missing here: ISP A has "issues", and the connection to Google never succeeds connection is re-tried with source address *B*, packets leave via ISP B, and reach Google as far as I could determine, no operating systems today will ever re-try a failed connection with a different source address, and they are all fully RFC conforming, as there is no RFC telling them they should do that. Now, the interesting question is "how to go forward with this"? There's Ole's draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat, which addresses most of the issues, and points to lots of other drafts about source address selection, DHCPv6 policy distribution, etc. - but after reading through all that, I came to the conclusion that "this is mostly intended for managed environments" - which is not what "your generic barbershop customer" wants. 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 --1FASoxBNj+w9tqcF Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iQCVAwUBUA6xFKkuBuNlUUl1AQLjtwP/frl8ys62umwk4j3BLoalhwHAtNxYNGDg XzuQGhwxGpsEByv+MG++yEGUcoJcGfPVj/i6/pvbv6KqCj6YpulNAuLRZBZ2ZOo9 Rm0ksTa/SzJvMWxoZUnwSrOoxhvX1EQ674MpE8koas5nHC2tG4Pf0uDOg3I8lc4Z KvN5TaEr+0U= =AKgY -----END PGP SIGNATURE----- --1FASoxBNj+w9tqcF-- From jeroen@unfix.org Tue Jul 24 07:48: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 F363821F8625 for ; Tue, 24 Jul 2012 07:48:49 -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=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_23=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQa2XX7ORAFA for ; Tue, 24 Jul 2012 07:48:49 -0700 (PDT) Received: from icaras.de.unfix.org (icaras.de.unfix.org [78.47.209.234]) by ietfa.amsl.com (Postfix) with ESMTP id 5373D21F8624 for ; Tue, 24 Jul 2012 07:48:49 -0700 (PDT) Received: from kami.ch.unfix.org (117-1.5-85.cust.bluewin.ch [85.5.1.117]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by icaras.de.unfix.org (Postfix) with ESMTPSA id AE125801C2AA; Tue, 24 Jul 2012 16:48:46 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=unfix.org; s=DKIM2009; t=1343141327; bh=xBjRlorXT9oVKhGnQ/vgbK64Wk0pwN4n0N+nOWuqEvs=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=FUG+ssI1mZ/6RWvrr796NqRu7TdR47w7Nvk1GSDXCcdWzeVmxYLsHOpYZElllLNtx IAKIvd9ViBcqpznkar/IqdJTcgbXbUicrj4evGPmjaCJmnld09FPUSlVzmuW39eIyE 4kqLldqVZSj4VB+Z6qvgYanAjo6N4hMHcf/XPCKev9xhPXozSauwug5EnywgZ8TSH8 c9bIeMU2eo0DTnqDeO3M7YQti0xQcaBbV07RhcowldiOAMB02poQYGaYxQeGzVY7Ng NFHbKwTzkJrQ/mYVZnGxipJ1yE8cI0oYnhTHyr9MSA5VFneNNVMzFOkhqUX+sI4wUU k4FLB/2tN1fKw== Message-ID: <500EB5CE.6070709@unfix.org> Date: Tue, 24 Jul 2012 16:48:46 +0200 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Gert Doering References: <4FFEC0A4.2070509@gmail.com> <20120712131000.GC38127@Space.Net> <20120712.154239.133898240.he@uninett.no> <20120712142354.GH38127@Space.Net> <4FFF01AF.3000502@gmail.com> <20120712175734.GM38127@Space.Net> <20120724142836.GL38127@Space.Net> In-Reply-To: <20120724142836.GL38127@Space.Net> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] What can v6ops do? [was: RIPE-555 fundamentaly changes the way how we can filter IPv6 & IPv4 martians?] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 24 Jul 2012 14:48:50 -0000 On 2012-07-24 16:28, Gert Doering wrote: > Hi, > > coming back to this: > > On Fri, Jul 13, 2012 at 07:52:13AM +0200, Mikael Abrahamsson wrote: >> On Thu, 12 Jul 2012, Gert Doering wrote: >> >>> - make "multihoming with dual-/48" *work*, so one of the incentives for >>> end-site multihoming with a globally visible route goes away >> >> Yes, please. > > It actually works quite well today - except for proper source address > selection *failover* in the face of failing connections. Sort of > "happy eyeballs .bis"... I am still wondering if ISPs and content providers like it that a host will be then connecting, likely in parallel, from + to multiple addresses. Thus lets say that a webserver has 4 addresses (2 IPv4, 2 IPv6) and the user has 2 ISPs and thus gets 2 addresses locally, that would mean that a HE implementation might build 4 connections in paralell, closing 3 of them that are 'too slow', while the HE.bis implementation might cause 8 of them dropping 7. Multiply that by a million users and instead of 1 mpps you suddenly have 8 mpps.... Oh and another is that A6/DNAME was maybe not that a bad idea, though a bit of scripting can definitely solve that too (and it is still to be seen that ISPs will be delegating reverse DNS to end-sites). Even if code did that, which would be great, the problem is then still long-lived connections[*] and inbound connections. Though, these should be addressed with Mobile IPv6, LISP or HE which retries both inbound addresses, which might be suboptimal according to some, then again, you get what you pay for. Greets, Jeroen (* = who is still looking for the ultimate screen/tmux/byobu: have a bunch of shell windows with unlimited scrollback that always stay connected/reconnect even if local IP address changes or one gets disconnected; the 'too many shells open and too much moving issue') From phdgang@gmail.com Tue Jul 24 08:34: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 43C9D21F8540 for ; Tue, 24 Jul 2012 08:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.026 X-Spam-Level: X-Spam-Status: No, score=-1.026 tagged_above=-999 required=5 tests=[AWL=-1.966, BAYES_05=-1.11, J_CHICKENPOX_13=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SjdF88MsoO7Z for ; Tue, 24 Jul 2012 08:34:56 -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 3D27A21F853F for ; Tue, 24 Jul 2012 08:34:56 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so6329209vcb.31 for ; Tue, 24 Jul 2012 08:34: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:content-transfer-encoding; bh=1SlLIbaeYGQP5FPfV6nsNSJm5oSbwREAcyzhF5Lo8is=; b=vuaF9KCaj2AQr5pTjniCRoUxGTFoGBvrup76FRF8rXlu2/lHeHx3O6/prEHhvnPqi6 2HZyHlTrJHCcSgtavenyC56NTe2lUONSw6qBWexqdk6ioTWEhLSJK0MbZnkXX23JxUCK 0iCni2WUMSgS8i+8IlxqPqa+OgdGTgJeDZReR9q92pxS4g1cWGVvs3O0hF5V8wVEweNC pR8MlmLU/IRy6IhkpFhVyTNeaWkQlqDaxbAbT7wMXEJHvbjcXvc2tbBEcwTyQCue+pTt soA0rPtngF3wz8Tazus3Fz97aIuNZy75HynABO9GLZGOwkNkXuOw5vHeO+zwRrN4wy4i oJ2g== MIME-Version: 1.0 Received: by 10.52.97.230 with SMTP id ed6mr13771022vdb.65.1343144095517; Tue, 24 Jul 2012 08:34:55 -0700 (PDT) Received: by 10.58.91.179 with HTTP; Tue, 24 Jul 2012 08:34:55 -0700 (PDT) In-Reply-To: <500E51B9.2020905@bogus.com> References: <0B2FA58F71A34C199446380DA654FB07@LENOVO1E4798BB> <1DFE8BF4-885E-4F2F-AA1B-4FC1658BA688@cisco.com> <4FF7077B.5050703@bogus.com> <5D36713D8A4E7348A7E10DF7437A4B9239EF7244@szxeml545-mbx.china.huawei.com> <8C9DC6AF-764D-49D5-9C6A-98776E532407@huawei.com> <500E51B9.2020905@bogus.com> Date: Tue, 24 Jul 2012 23:34:55 +0800 Message-ID: From: GangChen To: joel jaeggli Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Ops WG Subject: Re: [v6ops] Call for Adoption, was Re: New draft waiting for adoption: draft-chen-v6ops-nat64-experience-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 24 Jul 2012 15:34:57 -0000 2012/7/24, joel jaeggli : > On 7/20/12 9:25 PM, Tina TSOU wrote: >> Support with comments below. >> >> In the draft, NAT64 was compared with dual stack network where more >> cost is involved while managing two stacks of protocol. If NAT64 is a >> way of coexistence of IPv6 and IPv4, a brief discussion of tunneling >> options compared to NAT64 can be added. Moreover, in the deployment >> considerations, in case NAT64 is integrated with an existing gateway, >> what would be the possible impacts and memory requirements of the >> gateway. There would a data base maintained of the mapping, that might >> demand more resources. Deploying it =A1=B0close to BNG or CR has few >> impacts =A1=B0 =A8Cif there can be few examples of the impacts. > The assertions about cost bound up in the document I don't buy at all. > Particularly in the context of CGN deployment. The draft didn't intend to assert about cost, because that is subject to concrete business models which is going beyond the scope of documenting. What the draft documented is to objectively describe the cons and pros in a given implementation. Accepting your revision, I think the position of draft is getting clear, i.e. the draft just objectively report what we have done and what we find. > You're not likely to build in consensus in the in v6ops that dual stack > deployment is dramatically more expensive that the alternative (outside > cases where externalities such as licensing apply), Exactly. We don't want to enter a topic that would be worthy of another 30-page document, with all the different considerations. The draft focus on the potential benefits when IPv6-only is adopted. >so if you're headed > that direction you should be prepared to marshall a rather convincing > argument. >> Based on my NAT64 experience, the NAT64 gateway should also define >> routes to the block of addresses (for example ::/96 ipv6 address >> block) used to represent IPv4 address. If a.b.c.d is used to represent >> s:f:g:h::1 then there should be routes to a.b.c.d as well to >> successfully NAT. In my opinion, this is an important implementation >> requirement. >> In NAT64-CE Networking paragraph, I did not get this line: =A1=B0One big >> challenge is NAT64-CE facing IPv6 Internet, on which a significant >> IPv6 users may connect to.=A1=B1 > Given that I'm unconvinced in the context of DC migration that placing a > nat64 translator in front of a load balancer is a good idea, I certainly > wouldn't support it here either. Given there were sufficient discussions on the list, I guess group would surely understand that well. The draft didn't want to venture to recommend something in this case. However, it should at least identify the issues and let people aware of those issues, since those case are sure to exist for the time being. The draft would like to raise such caution. > stacking stateful devices is expensive state-wise (as that section > asserts), results in additional latency, loses the source address if > you're doing a transform and so on, the previous section attempts to > assert that the existence of the mapping to source address is valuable, > and indeed it is so much so that correlation after the fact isn't a > substitution for having that data when the connection is made. > an earlier section cites draft-ietf-intarea-nat-reveal-analysis-02 in > the case of addressing the loss of source address, that sort of > demonstrates the scope of the problem since that document doesn't solve i= t. Good comments. As you could see, the draft already asserted the expense FWIW, we can state that further in the draft, e.g. for operators who already deployed such mode, it should be cautious and aware the problems it may cause. Such usages should be restrained to a relative small-scale, since native IPv6 is always desirable. For operators who seek a clear precedent for operating reliable ipv6-only services, it should be prudent to adopt such mode (in some sense it's not recommended), because the usages is problematic at several aspects. Many thanks Gang >> Tina >> >> On Jul 20, 2012, at 4:47 PM, "Sheng Jiang" > > wrote: >> >>> Support for WG adoption. Quite useful experience for other ISPs. >>> >>> Sheng >>> >>>> -----Original Message----- >>>> From: v6ops-bounces@ietf.org >>>> [mailto:v6ops-bounces@ietf.org] On Behalf >>>> Of Joel jaeggli >>>> Sent: Friday, July 06, 2012 11:43 PM >>>> To: IPv6 Ops WG >>>> Subject: [v6ops] Call for Adoption, was Re: New draft waiting for >>>> adoption: >>>> draft-chen-v6ops-nat64-experience-02 >>>> >>>> The following message commences a 1 week call for opinions on the >>>> adoption of draft-chen-v6ops-nat64-experience-02 >>>> >>>> http://tools.ietf.org/html/draft-chen-v6ops-nat64-experience-02 >>>> >>>> Friday 7/13/2012 is the deadline for this particular call. >>>> >>>> Thank you. >>>> joel >>>> >>>>>> =C6=F3=D2=B5=B1=EA=D7=BC=B5=C4=CE=C4=B1=BE=B8=F1=CA=BD=A3=A8=C4=A3= =B0=E6=A3=A9 >>>>>> >>>>>> Dear Chairs, >>>>>> >>>>>> >>>>>> >>>>>> We have posted new draft of NAT64 experiences. >>>>>> >>>>>> Current draft is a joined effort from four operators (China Mobile, >>>>>> T-mobile USA, China Telecom and France Telecom) >>>>>> >>>>>> who is actively progressing IPv6 deployment depending on the >>>>>> practices. >>>>>> >>>>>> Several experts encourage us to continue the work after their kind >>>>>> review >>>>>> >>>>>> >>>>>> >>>>>> For now, we have addressed all comments. >>>>>> >>>>>> The draft is ready for the adoption. >>>>>> >>>>>> The authors would like to consult your opinions and look forward you= r >>>>>> guidance. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Many thanks >>>>>> >>>>>> >>>>>> >>>>>> Authors >>>>>> >>>>>> >>>>>> >>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >>>>>> >>>>>> A new version of I-D, draft-chen-v6ops-nat64-experience-02.txt >>>>>> >>>>>> has been successfully submitted by Gang Chen and posted to the >>>>>> >>>>>> IETF repository. >>>>>> >>>>>> >>>>>> >>>>>> Filename: draft-chen-v6ops-nat64-experience >>>>>> >>>>>> Revision: 02 >>>>>> >>>>>> Title: NAT64 Operational Experiences >>>>>> >>>>>> Creation date: 2012-07-04 >>>>>> >>>>>> WG ID: Individual Submission >>>>>> >>>>>> Number of pages: 15 >>>>>> >>>>>> URL: >>>>>> >>>> http://www.ietf.org/internet-drafts/draft-chen-v6ops-nat64-experience-= 02. >>>> txt >>>>>> >>>>>> Status: >>>>>> http://datatracker.ietf.org/doc/draft-chen-v6ops-nat64-experience >>>>>> >>>>>> Htmlized: >>>>>> http://tools.ietf.org/html/draft-chen-v6ops-nat64-experience-02 >>>>>> >>>>>> Diff: >>>>>> http://tools.ietf.org/rfcdiff?url2=3Ddraft-chen-v6ops-nat64-experien= ce-02 >>>>>> >>>>>> >>>>>> >>>>>> Abstract: >>>>>> >>>>>> This document summarizes some stateful NAT64 deployment >>>> scenarios and >>>>>> >>>>>> operational experiences for NAT64-CGN and NAT64-CE. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 gert@space.net Tue Jul 24 08:38: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 624EF21F8678 for ; Tue, 24 Jul 2012 08:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[AWL=-0.536, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GuuDwos3aRFX for ; Tue, 24 Jul 2012 08:38:20 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8544021F8668 for ; Tue, 24 Jul 2012 08:38:20 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id D97CEF8C6A for ; Tue, 24 Jul 2012 17:38:19 +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 C9F45F8C55 for ; Tue, 24 Jul 2012 17:38:19 +0200 (CEST) Received: (qmail 57788 invoked by uid 1007); 24 Jul 2012 17:38:19 +0200 Date: Tue, 24 Jul 2012 17:38:19 +0200 From: Gert Doering To: Jeroen Massar Message-ID: <20120724153819.GO38127@Space.Net> References: <4FFEC0A4.2070509@gmail.com> <20120712131000.GC38127@Space.Net> <20120712.154239.133898240.he@uninett.no> <20120712142354.GH38127@Space.Net> <4FFF01AF.3000502@gmail.com> <20120712175734.GM38127@Space.Net> <20120724142836.GL38127@Space.Net> <500EB5CE.6070709@unfix.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RI+P/CiYqhD6quxl" Content-Disposition: inline In-Reply-To: <500EB5CE.6070709@unfix.org> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: v6ops@ietf.org Subject: Re: [v6ops] What can v6ops do? [was: RIPE-555 fundamentaly changes the way how we can filter IPv6 & IPv4 martians?] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 24 Jul 2012 15:38:21 -0000 --RI+P/CiYqhD6quxl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Tue, Jul 24, 2012 at 04:48:46PM +0200, Jeroen Massar wrote: > > It actually works quite well today - except for proper source address > > selection *failover* in the face of failing connections. Sort of=20 > > "happy eyeballs .bis"... >=20 > I am still wondering if ISPs and content providers like it that a host > will be then connecting, likely in parallel, from + to multiple addresses. I don't know what the "best" result would be. Maybe "try one combination and fall over after 500ms" or "5s" or whatever, plus "cache the result" (obviously). "Do all combinations in parallel in the same fraction of a second" is obviously not a very nice approach - and HE implementations don't do that for multiple IPv6 destination addresses today either (Apple will do 1 v4 + 1 v6 at the same time, the rest does "with slight delay"). > Thus lets say that a webserver has 4 addresses (2 IPv4, 2 IPv6) and the > user has 2 ISPs and thus gets 2 addresses locally, that would mean that > a HE implementation might build 4 connections in paralell, closing 3 of > them that are 'too slow', while the HE.bis implementation might cause 8 > of them dropping 7. Multiply that by a million users and instead of 1 > mpps you suddenly have 8 mpps.... Yes. This certainly needs to be taken into account. Nevertheless, source address failover needs to be done, otherwise=20 we'll be back to "ULA inside, two NPT66 boxes to the respective ISPs" (and I've already heard from vendors that their customers are asking for that, because "the other thing is too complicated" *sigh*). > Oh and another is that A6/DNAME was maybe not that a bad idea, though a > bit of scripting can definitely solve that too (and it is still to be > seen that ISPs will be delegating reverse DNS to end-sites). Slightly different can of worms, but DNS also needs to be fixed if you want to be able to connect from the outside to internal hosts in "SoHo networks", without resorting to some sort of registrar service ("back to my mac"). > Even if code did that, which would be great, the problem is then still > long-lived connections[*] and inbound connections. Though, these should > be addressed with Mobile IPv6, LISP or HE which retries both inbound > addresses, which might be suboptimal according to some, then again, you > get what you pay for. Fixing things for outbound connections would already go quite some=20 distance for the *largest number* of leafs - "home users" and "smallest shops" that are really 99% just consuming, and not running servers (except for maybe some remote-maintenance-service connection to my Mom's PC, but those can be fixed by inside-out VPN setup, DynDNS, external registrar services, etc.) > (* =3D who is still looking for the ultimate screen/tmux/byobu: have a > bunch of shell windows with unlimited scrollback that always stay > connected/reconnect even if local IP address changes or one gets > disconnected; the 'too many shells open and too much moving issue') You and I are not what causes the scaling problem at the edge :-) 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 --RI+P/CiYqhD6quxl Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iQCVAwUBUA7Ba6kuBuNlUUl1AQLVIAP/VXnclHGI6cYxUuvq8dum3kBbo5+W94Fy 8GbwnqdkyC2DHqT3Nt55YyBIth02EUqbSygheapRZJfYevB7jAfsNKE+haatIDr5 mO6Mq4n3aEB9Ws+BNIlNsaJ5JF3odfPwv1xdQtYs9nFPOgT5YmYPMOMzH6d0T00W EMIaNUULD2Y= =DMnk -----END PGP SIGNATURE----- --RI+P/CiYqhD6quxl-- From brian.e.carpenter@gmail.com Tue Jul 24 09: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 B82BD21F8669 for ; Tue, 24 Jul 2012 09:19:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.776 X-Spam-Level: X-Spam-Status: No, score=-100.776 tagged_above=-999 required=5 tests=[AWL=-0.285, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_23=0.6, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gr6wW8aJtr4p for ; Tue, 24 Jul 2012 09:19:33 -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 EC6A121F862A for ; Tue, 24 Jul 2012 09:19:32 -0700 (PDT) Received: by weyu54 with SMTP id u54so5869571wey.31 for ; Tue, 24 Jul 2012 09:19:32 -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=Px2OBitlEGDf/kwnGY4e1uw0wpGdgOS6K/HML0LyCPg=; b=S+p2SQOXmSIoERb4eu99sXR/rygxv4sZJoV9Q6xyzbs4Snm0bFKTIhwzP88d8LddTA cBKDPsdcW0QUajPWZx0UsBI/F9+Gwldzlyf893av53CggToi8ARJcaH97UX5mdVZEOO9 FVtNj7FAMu6+hoSZ+A3itLHsUQlcJGux11sIXYCCwHwhYMjMT26SOFm97PtE1AAw4ppJ fhJtiz/Ym44JtkqwVJFfUXF+j1/JCZmD6D/4qeBVmdGWoPchubNLm96vHaZZDm+dS/Zn EC/Z3zw48ZJ5/jwAt2QyRfN1HHCB+PsKqWYVIDGdwEFGLrq2AW0v+DXt2ABYCm7SJLxO koFg== Received: by 10.180.107.103 with SMTP id hb7mr8361234wib.3.1343146772109; Tue, 24 Jul 2012 09:19:32 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-218-212.as13285.net. [2.102.218.212]) by mx.google.com with ESMTPS id j4sm308109eeo.11.2012.07.24.09.19.29 (version=SSLv3 cipher=OTHER); Tue, 24 Jul 2012 09:19:30 -0700 (PDT) Message-ID: <500ECB13.3080902@gmail.com> Date: Tue, 24 Jul 2012 17:19:31 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Jeroen Massar References: <4FFEC0A4.2070509@gmail.com> <20120712131000.GC38127@Space.Net> <20120712.154239.133898240.he@uninett.no> <20120712142354.GH38127@Space.Net> <4FFF01AF.3000502@gmail.com> <20120712175734.GM38127@Space.Net> <20120724142836.GL38127@Space.Net> <500EB5CE.6070709@unfix.org> In-Reply-To: <500EB5CE.6070709@unfix.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] What can v6ops do? [was: RIPE-555 fundamentaly changes the way how we can filter IPv6 & IPv4 martians?] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 24 Jul 2012 16:19:33 -0000 On 24/07/2012 15:48, Jeroen Massar wrote: > On 2012-07-24 16:28, Gert Doering wrote: >> Hi, >> >> coming back to this: >> >> On Fri, Jul 13, 2012 at 07:52:13AM +0200, Mikael Abrahamsson wrote: >>> On Thu, 12 Jul 2012, Gert Doering wrote: >>> >>>> - make "multihoming with dual-/48" *work*, so one of the incentives for >>>> end-site multihoming with a globally visible route goes away >>> Yes, please. >> It actually works quite well today - except for proper source address >> selection *failover* in the face of failing connections. Sort of >> "happy eyeballs .bis"... > > I am still wondering if ISPs and content providers like it that a host > will be then connecting, likely in parallel, from + to multiple addresses. I don't really care what they *like* if I am the user. In any case, it was precisely to allow session continuity in such a case that we invented shim6, which is still waiting for its future to arrive. It's also why MPTCP is interesting, and it's why we have draft-ietf-mif-happy-eyeballs-extension. Eventually, one or more of these solutions will become widespread. I'm not sure we need to do anything except wait. (Incidentally, I see that draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat is stuck in the RFC queue waiting for normative references.) Brian > > Thus lets say that a webserver has 4 addresses (2 IPv4, 2 IPv6) and the > user has 2 ISPs and thus gets 2 addresses locally, that would mean that > a HE implementation might build 4 connections in paralell, closing 3 of > them that are 'too slow', while the HE.bis implementation might cause 8 > of them dropping 7. Multiply that by a million users and instead of 1 > mpps you suddenly have 8 mpps.... > > Oh and another is that A6/DNAME was maybe not that a bad idea, though a > bit of scripting can definitely solve that too (and it is still to be > seen that ISPs will be delegating reverse DNS to end-sites). > > Even if code did that, which would be great, the problem is then still > long-lived connections[*] and inbound connections. Though, these should > be addressed with Mobile IPv6, LISP or HE which retries both inbound > addresses, which might be suboptimal according to some, then again, you > get what you pay for. > > Greets, > Jeroen > > (* = who is still looking for the ultimate screen/tmux/byobu: have a > bunch of shell windows with unlimited scrollback that always stay > connected/reconnect even if local IP address changes or one gets > disconnected; the 'too many shells open and too much moving issue') > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > . > From jeroen@unfix.org Tue Jul 24 09: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 98EF421F855A for ; Tue, 24 Jul 2012 09:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.099 X-Spam-Level: X-Spam-Status: No, score=-102.099 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1cRskARe32jJ for ; Tue, 24 Jul 2012 09:54:49 -0700 (PDT) Received: from icaras.de.unfix.org (icaras.de.unfix.org [IPv6:2a01:4f8:130:74c1:5054:ff:fec4:f7d4]) by ietfa.amsl.com (Postfix) with ESMTP id 976C721F8530 for ; Tue, 24 Jul 2012 09:54:49 -0700 (PDT) Received: from kami.ch.unfix.org (117-1.5-85.cust.bluewin.ch [85.5.1.117]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by icaras.de.unfix.org (Postfix) with ESMTPSA id 65050801C2AA; Tue, 24 Jul 2012 18:54:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=unfix.org; s=DKIM2009; t=1343148887; bh=XwLBDaNZz+HiEFZWOASGH4+6pmMapcUV6brcCgqyIOQ=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=FXJHT/Bc6wjD6nrowxbZXabGKGCWzo1vDw+UtpzHmKjhhLHR3ClYWQKWHstc4Rg4g n+QJd1IC24x3HmMIUee/3BKL6ANvmExixX2qyobWrwfP0aTiT5reQMKILDzHJRUyCY RcyT32DHI3yA10ZvAUWRnCwX6BqiChEA5+KpErN8myfY5D/AHldJbgBHAKgFsWa4Of +hb5/k54zuvtzCigeqhDRcy+egi5D0rDWsYNQVz9kRo6ZIapdB/uzmcPL6Qfn9GP59 QS/agVHcmTrJe7/IQkaKaJ955gTAsDDU65DuxWS2Fsa114yBDQCc0hAlcgxz103tVs vJp6UXZdeA0mQ== Message-ID: <500ED356.2090902@unfix.org> Date: Tue, 24 Jul 2012 18:54:46 +0200 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Brian E Carpenter References: <4FFEC0A4.2070509@gmail.com> <20120712131000.GC38127@Space.Net> <20120712.154239.133898240.he@uninett.no> <20120712142354.GH38127@Space.Net> <4FFF01AF.3000502@gmail.com> <20120712175734.GM38127@Space.Net> <20120724142836.GL38127@Space.Net> <500EB5CE.6070709@unfix.org> <500ECB13.3080902@gmail.com> In-Reply-To: <500ECB13.3080902@gmail.com> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] What can v6ops do? [was: RIPE-555 fundamentaly changes the way how we can filter IPv6 & IPv4 martians?] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 24 Jul 2012 16:54:50 -0000 On 2012-07-24 18:19, Brian E Carpenter wrote: > On 24/07/2012 15:48, Jeroen Massar wrote: >> On 2012-07-24 16:28, Gert Doering wrote: >>> Hi, >>> >>> coming back to this: >>> >>> On Fri, Jul 13, 2012 at 07:52:13AM +0200, Mikael Abrahamsson wrote: >>>> On Thu, 12 Jul 2012, Gert Doering wrote: >>>> >>>>> - make "multihoming with dual-/48" *work*, so one of the incentives for >>>>> end-site multihoming with a globally visible route goes away >>>> Yes, please. >>> It actually works quite well today - except for proper source address >>> selection *failover* in the face of failing connections. Sort of >>> "happy eyeballs .bis"... >> >> I am still wondering if ISPs and content providers like it that a host >> will be then connecting, likely in parallel, from + to multiple addresses. > > I don't really care what they *like* if I am the user. In any case, it was > precisely to allow session continuity in such a case that we invented > shim6, which is still waiting for its future to arrive. It's also why MPTCP > is interesting, and it's why we have draft-ietf-mif-happy-eyeballs-extension. And the protocol I always forget that does most of the things (only disconnect and resume later it does not support) I want but which is not universally available: SCTP > Eventually, one or more of these solutions will become widespread. I'm not > sure we need to do anything except wait. A proper overview in eg Wikipedia, or heck a "IETF FAQ" page would maybe be an idea: "How do I solve the problem where I have two prefixes at home and want to failover between them". Greets, Jeroen From jeroen@unfix.org Tue Jul 24 10:25: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 6A6FE11E8079 for ; Tue, 24 Jul 2012 10:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.774 X-Spam-Level: X-Spam-Status: No, score=-101.774 tagged_above=-999 required=5 tests=[AWL=-0.375, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_23=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xvQIesQHcWlX for ; Tue, 24 Jul 2012 10:25:50 -0700 (PDT) Received: from icaras.de.unfix.org (icaras.de.unfix.org [IPv6:2a01:4f8:130:74c1:5054:ff:fec4:f7d4]) by ietfa.amsl.com (Postfix) with ESMTP id 5BE2611E8086 for ; Tue, 24 Jul 2012 10:25:50 -0700 (PDT) Received: from kami.ch.unfix.org (117-1.5-85.cust.bluewin.ch [85.5.1.117]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by icaras.de.unfix.org (Postfix) with ESMTPSA id 9189F801C2AA; Tue, 24 Jul 2012 19:25:48 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=unfix.org; s=DKIM2009; t=1343150749; bh=rq89iRtxJhY27nBbBKb9sVcZgBLKhSZj2deOIcEUEXs=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=JkzBa6vvKOmWBTKAJUvCPFqtv/HCQsF5gFhGi3gsro9reaZX9yT6ewpNxzCDmVVMw 79HJ4MI0EMpNaZ7WC0pjkMHEcJOqg0hLvg7sYNzRPYz7wrOqfRdvwtWf6e88kWFCDa CZmtbQPtDyaW6VXA+SwTIfjBiW3ST4wE8eHANodPbsotmbQ0Ay6t8ZMKAC3+82gnlc 3hZypFxcVI9VJMfZQncoADaf2a5jab/elTM7znNOU4ixPUsD7QUG35hmU4pspPiW22 IOYgtqUMyQYQiGzxriZ/p4ABMsoXyOTSzXBFkZM71OHF9zRr+jfmB9jQ70W0VPDrLQ VaBVlw7F5EWfQ== Message-ID: <500EDA9C.4040204@unfix.org> Date: Tue, 24 Jul 2012 19:25:48 +0200 From: Jeroen Massar Organization: Unfix User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Gert Doering References: <4FFEC0A4.2070509@gmail.com> <20120712131000.GC38127@Space.Net> <20120712.154239.133898240.he@uninett.no> <20120712142354.GH38127@Space.Net> <4FFF01AF.3000502@gmail.com> <20120712175734.GM38127@Space.Net> <20120724142836.GL38127@Space.Net> <500EB5CE.6070709@unfix.org> <20120724153819.GO38127@Space.Net> In-Reply-To: <20120724153819.GO38127@Space.Net> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] What can v6ops do? [was: RIPE-555 fundamentaly changes the way how we can filter IPv6 & IPv4 martians?] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 24 Jul 2012 17:25:51 -0000 [Mark Andrews: could I entice you to update your HE-code mentioned below or do you accept patches to it? :) ] On 2012-07-24 17:38, Gert Doering wrote: > Hi, > > On Tue, Jul 24, 2012 at 04:48:46PM +0200, Jeroen Massar wrote: >>> It actually works quite well today - except for proper source address >>> selection *failover* in the face of failing connections. Sort of >>> "happy eyeballs .bis"... >> >> I am still wondering if ISPs and content providers like it that a host >> will be then connecting, likely in parallel, from + to multiple addresses. > > I don't know what the "best" result would be. Maybe "try one combination > and fall over after 500ms" or "5s" or whatever, plus "cache the result" > (obviously). Apple does it mostly okay in Lion, the only problem I have with it is that there is no 'off' button for disabling the failover from IPv6 to IPv4 or at least making it not quibble over 20ms latency difference (currently solved in my home net by slowing down IPv4 packets in the router when the source address is a Mac OS X box ;). > "Do all combinations in parallel in the same fraction of a second" is > obviously not a very nice approach - and HE implementations don't do > that for multiple IPv6 destination addresses today either (Apple will > do 1 v4 + 1 v6 at the same time, the rest does "with slight delay"). That sounds about nice indeed. >> Thus lets say that a webserver has 4 addresses (2 IPv4, 2 IPv6) and the >> user has 2 ISPs and thus gets 2 addresses locally, that would mean that >> a HE implementation might build 4 connections in paralell, closing 3 of >> them that are 'too slow', while the HE.bis implementation might cause 8 >> of them dropping 7. Multiply that by a million users and instead of 1 >> mpps you suddenly have 8 mpps.... > > Yes. This certainly needs to be taken into account. > > Nevertheless, source address failover needs to be done, otherwise > we'll be back to "ULA inside, two NPT66 boxes to the respective ISPs" > (and I've already heard from vendors that their customers are asking > for that, because "the other thing is too complicated" *sigh*). I unfortunately am not a mass-customer ISP who can demand features from vendors, /me looks at the Comcasts around the world though. I do think having a Happy Eyeballs Bis with this in there will be a good thing to have for Operating Systems. One argument for router/NAT-box vendors is that it will be retrofitted in the OS and that they do not have to do much for it. As mentioned at the top Mark has the code worked out for destination address selection: https://www.isc.org/community/blog/201101/how-to-connect-to-a-multi-homed-server-over-tcp >> Oh and another is that A6/DNAME was maybe not that a bad idea, though a >> bit of scripting can definitely solve that too (and it is still to be >> seen that ISPs will be delegating reverse DNS to end-sites). > > Slightly different can of worms, but DNS also needs to be fixed if > you want to be able to connect from the outside to internal hosts > in "SoHo networks", without resorting to some sort of registrar > service ("back to my mac"). There are enough DynDNS services which can resolve this and I am sure that if there is a 'site multihoming with multiple prefixes' RFC that these services will enable their users to register multiple addresses or easily swap out a /48 for another or add/remove one etc prefixing all the hosts in a session ala A6. >> Even if code did that, which would be great, the problem is then still >> long-lived connections[*] and inbound connections. Though, these should >> be addressed with Mobile IPv6, LISP or HE which retries both inbound >> addresses, which might be suboptimal according to some, then again, you >> get what you pay for. > > Fixing things for outbound connections would already go quite some > distance for the *largest number* of leafs - "home users" and "smallest > shops" that are really 99% just consuming, and not running servers > (except for maybe some remote-maintenance-service connection to > my Mom's PC, but those can be fixed by inside-out VPN setup, DynDNS, > external registrar services, etc.) Indeed. >> (* = who is still looking for the ultimate screen/tmux/byobu: have a >> bunch of shell windows with unlimited scrollback that always stay >> connected/reconnect even if local IP address changes or one gets >> disconnected; the 'too many shells open and too much moving issue') > > You and I are not what causes the scaling problem at the edge :-) Well... I did not register my private AS + PIv6 prefix yet ;) (and won't happen either as I don't see the value of it) Greets, Jeroen From sarikaya2012@gmail.com Tue Jul 24 15:00: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 7D08111E8088 for ; Tue, 24 Jul 2012 15:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.538 X-Spam-Level: X-Spam-Status: No, score=-3.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-i76prhHqzV for ; Tue, 24 Jul 2012 15:00:32 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id B673011E8072 for ; Tue, 24 Jul 2012 15:00:32 -0700 (PDT) Received: by yhq56 with SMTP id 56so66980yhq.31 for ; Tue, 24 Jul 2012 15:00:32 -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=W95VqnGqyEIXESkdMfNFE+vt5YdtoMkvgYaGTTHKYf0=; b=w96QNvwsxjVV6N5DKqBmHsvaaGLocDpUlPkZR2dmEISBOKDorujZAOsoIGY97FhqnK 8KH3TRcv93Rgs3FUeozlmSMKp21ssozeuZSl21r45reGQJseMlP0KoqloVjgjQUosxS6 MqrnTVc/oLV0qNUUErXa/42WD2krlqHc4bn6h7HkICw55wPhEmJ5O/LuIUsI9VEjSrVT qFvPltczKNnlNFY0Daj9cakqMWoPDZ3AXElSEzZfingHkhdgbCyDBK9vIYUdeCyb5VIv ES0gE6qxh1bVVrl7ZVSb82cKrMq3s2xhDqOYgIxeERscxwbCrjvxQ+AtqozWv2JJPest 3TZg== MIME-Version: 1.0 Received: by 10.42.66.13 with SMTP id n13mr18462940ici.39.1343167229409; Tue, 24 Jul 2012 15:00:29 -0700 (PDT) Received: by 10.231.207.167 with HTTP; Tue, 24 Jul 2012 15:00:29 -0700 (PDT) In-Reply-To: References: <500B5715.8050002@tut.fi> Date: Tue, 24 Jul 2012 17:00:29 -0500 Message-ID: From: Behcet Sarikaya To: Nathan Lutchansky Content-Type: text/plain; charset=ISO-8859-1 Cc: Aleksi Suhonen , v6ops@ietf.org Subject: Re: [v6ops] draft-chen-v6ops-nat64-experience-02 Stateless NAT64 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, 24 Jul 2012 22:00:33 -0000 On Tue, Jul 24, 2012 at 4:44 PM, Nathan Lutchansky wrote: > On Sun, 22 Jul 2012, Aleksi Suhonen wrote: >> >> On 07/18/2012 07:36 PM, Behcet Sarikaya wrote: >>> >>> So you need to write a draft describing Stateless NAT64 :-), please. >> >> >> These people have been able to implement Stateless NAT64 with the existing >> drafts and RFCs: >> >> http://www.litech.org/tayga/ > > > TAYGA is an implementation of RFC 6145 with a small extension: if an > incoming IPv6 packet has a source address that cannot be translated per RFC > 6052, TAYGA can be configured to automatically bind that address for a time > to a free IPv4 address from an administratively-configured pool. In this > configuration TAYGA is not truly stateless, but it still maintains no state > regarding transport layer flows. > > Regarding Aleksi's experiences with privacy extensions depleting the entire > dynamic pool, there is not much that can be done about this--it's just one > more thing that RFC 4941 breaks. I would love to have an RA option that > forced privacy extensions to be disabled; I would use it on every network I > maintain. -Nathan Hi Nathan, I don't know the relationship of tayga and this presentation: http://fud.no/talks/20120417-RIPE64-The_Case_for_IPv6_Only_Data_Centres.pdf which is a stateless translator maintains the binding information of *src.IPv6->src.IPv4 address* It seems that this is what is called Stateless NAT64. Reading the above presentation, Stateless NAT64 solves the reverse problem of NAT64, i.e. IPv4-only client talking to IPv6-only server. So as far as I am concerned the puzzle of Stateless NAT64 is solved. Behcet From estrellazhang2012@gmail.com Tue Jul 24 18:40: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 B7B6221F84D0 for ; Tue, 24 Jul 2012 18:40:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.774 X-Spam-Level: X-Spam-Status: No, score=-1.774 tagged_above=-999 required=5 tests=[AWL=1.225, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S-K8hUVngZK1 for ; Tue, 24 Jul 2012 18:40:41 -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 05E6C21F84CF for ; Tue, 24 Jul 2012 18:40:40 -0700 (PDT) Received: by weyu54 with SMTP id u54so142854wey.31 for ; Tue, 24 Jul 2012 18:40: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:content-transfer-encoding; bh=ALBkVD914jafBygwJ4vjmgriVCTTbQRSBu1QdzSd1Y0=; b=SO+A6UidHe2c09SfCsNW518YkNDUPs3mVGQmLHqkLVeh1kcsYaEULdCw1NqHENda/7 Dp9Iq52GjK+9QEDTY9hkpkmBi8ud7tzDOVZoml91W7GMuyEj86Ceb6CtC8/4FI8tdON5 U5qC5UuT9ZZWY1IP4ZOfc46UX8rZFmA5KbRozbu5TiwxF78xAJ1ZKVRxss3jddpORDz1 7KwSzdE4Jly92aEXl5G2ouhgiBrdwyG34yoNs0yPGk7YPgAK58hrxVC12kgoj87M1GIV 22iYzmjN2UCYtjHWu6uOwz+H5ihIqgSGfe2bYrLMx3pV9rZ0V0hPwkrz3683S26toD5M 7cnw== MIME-Version: 1.0 Received: by 10.180.75.168 with SMTP id d8mr11362902wiw.8.1343180440106; Tue, 24 Jul 2012 18:40:40 -0700 (PDT) Received: by 10.217.2.5 with HTTP; Tue, 24 Jul 2012 18:40:40 -0700 (PDT) In-Reply-To: References: Date: Wed, 25 Jul 2012 09:40:40 +0800 Message-ID: From: Jiexin Zhang To: wang.cui1@zte.com.cn Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org Subject: Re: [v6ops] "RE: goals of draft-zhang-v6ops-ipv6oa-iwf-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: Wed, 25 Jul 2012 01:40:41 -0000 2012/7/25, Jiexin Zhang : > Thanks for the comments from Miss Wang. Actually=A3=ACI think IWF means = it can perform both layer2 and IP function. Therefore, IWF can be performed in a layer 2 node, such as an ATM switch, which works like the IPv4oA IWF in ATM switch usually. And it can also be performed in a layer 3 node, BRAS as an example. In this draft, we just defined IWF is in a layer 2 node. > ~~JX > > 2012/7/24, wang.cui1@zte.com.cn : >> Hi, >> >> I have throughly read this draft and the discussions on the mailing list= , >> the previous questions from fred and J.S help my understanding about thi= s >> draft, >> and this solution seems more economical which just need updates the >> version of >> the ATM nodes than buying extra equipments to replace the located ATM >> nodes or ATM network=A3=BB >> >> But here I have a comment: >> >> 1) You said the "Interworking Function" is a layer 2 node, but in >> section 4.2,what the IPv6oA IWF do seems like a >> layer 3 node because this node has to deal with IP address. What >> do you think ? >> >> Thanks~ >> Cui Wang >> >> >> -------------------------------------------------------- >> ZTE Information Security Notice: The information contained in this mail >> (and >> any attachment transmitted herewith) is privileged and confidential and >> is >> intended for the exclusive use of the addressee(s). If you are not an >> intended recipient, any disclosure, reproduction, distribution or other >> dissemination or use of the information contained is strictly prohibited= . >> If you have received this mail in error, please delete it and notify us >> immediately. >> >> > From Aleksi.Suhonen@tut.fi Tue Jul 24 20:40: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 8867411E8085 for ; Tue, 24 Jul 2012 20:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HOwJWEb2WW3X for ; Tue, 24 Jul 2012 20:40:49 -0700 (PDT) Received: from mail-gw-out2.cc.tut.fi (mail-gw-out2.cc.tut.fi [130.230.160.33]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2DD11E8080 for ; Tue, 24 Jul 2012 20:40:46 -0700 (PDT) X-AuditID: 82e6a021-b7f236d000000a82-2d-500f6abd9547 Received: from mail1.tut.fi (mail1.tut.fi [130.230.162.19]) by mail-gw-out2.cc.tut.fi (Symantec Messaging Gateway) with SMTP id 6C.1F.02690.DBA6F005; Wed, 25 Jul 2012 06:40:45 +0300 (EEST) Received: from [IPv6:2001:708:310:52:21a:6bff:fe61:167] (pool46.nat64.trex.fi [195.140.194.46]) by mail1.tut.fi (Postfix) with ESMTPSA id E91F740167; Wed, 25 Jul 2012 06:40:44 +0300 (EEST) Message-ID: <500F6AB7.3020709@tut.fi> Date: Wed, 25 Jul 2012 06:40:39 +0300 From: Aleksi Suhonen Organization: Tampere University of Technology / Department of Communications Engineering User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.5) Gecko/20120624 Icedove/10.0.5 MIME-Version: 1.0 To: v6ops@ietf.org References: <500B5715.8050002@tut.fi> <20120723183413.GB14528@spike.0x539.de> In-Reply-To: <20120723183413.GB14528@spike.0x539.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKIsWRmVeSWpSXmKPExsXS9GyRsO7eLP4Ag6fNbBbPb8xmt5i74Amb xeze0ywWp4/tZXZg8Xg64SCTx5IlP5k8Xk2YwuzRNnciUwBLFJdNSmpOZllqkb5dAlfGlBXL GQvmsVXse/uXtYHxN0sXIyeHhICJxLm9LVC2mMSFe+vZuhi5OIQE9jFK/FrXywrhHGCUWDFv MytIFa+AqsRjoPEgNguQ/etlC5jNJqAjcaXrFhuIzS8QLfH63F92EFtUIERievNBJoheQYmT M5+AbRMREJLY8awJKM7BwSzgJ/FngxVIWFjAU2Jzz3kWiL3XGSV6Hr0Em8MJdOnX3YvYIOqt Jb7tLgIJMwvIS2x/O4d5AqPgLCQbZiFUzUJStYCReRWjWG5iZo5uerlufmmJkV5ysl5JaYle WuYmRnBYL1DcwXhqhv4hRgEORiUe3hUv+QKEWBPLiitzDzFKcjApifI6p/EHCPEl5adUZiQW Z8QXleakFh9ilOBgVhLhLQoDyvGmJFZWpRblw6RkODiUJHgnZgKlBItS01Mr0jJzgNELk2bi 4ARp5wFqPwJSw1tckJhbnJkOkT/FqCglzrsPJCEAksgozYPrBaWO+v///79iFAc6Vpi3DaSK B5h24LpfAQ1mAhr8PIwPZHBJIkJKqoGx97X8YVfuB3OyFJdnFisvYIm1vz/9d0bHr7cXY04Z hYdek1Kev3GLiMUha8d7rB2qITeWTpdtmlv3rYebxa02vivDe/YM+98vpPZpG7854Ht8l4q/ VvAzvaVWZuvWJxqfurpi/T+7r2qTXy6Qab87W+vT/p8W//T56+5UtBe2BE36JyuWsLFEiaU4 I9FQi7moOBEAEmsja/gCAAA= Cc: lutchann@litech.org Subject: Re: [v6ops] draft-chen-v6ops-nat64-experience-02 Stateless NAT64 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 25 Jul 2012 03:40:49 -0000 Hi, On 07/23/2012 09:34 PM, Philipp Kern wrote: > am Mon, Jul 23, 2012 at 01:28:23PM -0500 hast du folgendes geschrieben: >> Thanks for pointing this out. I am still puzzled, tayga is using DNS64 >> and they talk about NAT44. > tayga implements NAT64, not DNS64 (for instance bind9 could be used for the > latter). NAT44 is needed because the IPv6 source addresses are mapped into a > private IPv4 pool by default, which then needs masquerading (aka NAT44) into > the public internet. The site even says this: I would simplify the above like this: Tayga implements Stateless NAT64, but it can be used to build a Stateful NAT64 setup by adding a NAT44 next to it. -- Aleksi Suhonen, Researcher Department of Communications Engineering Tampere University of Technology From liushucheng@huawei.com Tue Jul 24 20:55: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 DB7F911E8080 for ; Tue, 24 Jul 2012 20:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.032 X-Spam-Level: X-Spam-Status: No, score=-5.032 tagged_above=-999 required=5 tests=[AWL=-1.386, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_32=0.6, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s5C2V2QgC0qW for ; Tue, 24 Jul 2012 20:55:11 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 101F111E807F for ; Tue, 24 Jul 2012 20:55:11 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIH93370; Tue, 24 Jul 2012 23:55:10 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 24 Jul 2012 20:52:37 -0700 Received: from SZXEML423-HUB.china.huawei.com (10.82.67.162) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 24 Jul 2012 20:52:40 -0700 Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.75]) by szxeml423-hub.china.huawei.com ([10.82.67.162]) with mapi id 14.01.0323.003; Wed, 25 Jul 2012 11:52:35 +0800 From: "Will Liu (Shucheng)" To: "wang.cui1@zte.com.cn" Thread-Topic: [v6ops] "RE: goals of draft-zhang-v6ops-ipv6oa-iwf-00.txt " Thread-Index: AQHNagaLJtbkYYoO8kagl+XtfL/+sZc5Wfdw Date: Wed, 25 Jul 2012 03:52:34 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.79.130] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "v6ops@ietf.org" Subject: Re: [v6ops] "RE: goals of draft-zhang-v6ops-ipv6oa-iwf-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: Wed, 25 Jul 2012 03:55:12 -0000 TGV0IG1lIGFkZCBvbmUgcG9pbnQuIEluIGZhY3QgdGhlIElQdjZvQSBpbnRlcndvcmtpbmcgaXMg c29ydCBvZiBhbiBORCBhbmQgSU5EIHByb3h5LiBJdCBtYWtlcyBjaGFuZ2VzIHRvIE5EIGFuZCBJ TkQgbWVzc2FnZXMuIEhvd2V2ZXIsIGl0IGRvZXMgbm90IGluaXRpYXRlIHRoZSBORCBtZXNzYWdl LiBNb3JlIGRldGFpbHMgd2VyZSB3cml0dGVuIGluIHRoZSBsYXN0IGJ1dCB0d28gcGFyYWdyYXBo cyBpbiBjaGFwdGVyIDQuMi4NCg0KobBXaGVuIElQdjZvQSBJV0Ygc2VuZHMgSW52ZXJzZSBOZWln aGJvciBEaXNjb3ZlcnkgTWVzc2FnZSwgaXQgY2FuDQogICAgICAgIGNoYW5nZSB0aGUgTmVpZ2hi b3IgU29saWNpdGF0aW9uIE1lc3NhZ2UgZnJvbSBCTkcgdG8gSW52ZXJzZSBOZWlnaGJvcg0KICAg ICAgICBEaXNjb3ZlcnkgU29saWNpdGF0aW9uIG1lc3NhZ2Ugb3IgY2hhbmdlIHRoZSBJbnZlcnNl IE5laWdoYm9yDQogICAgICAgIERpc2NvdmVyeSBBZHZlcnRpc2VtZW50cyBtZXNzYWdlIGZyb20g Q1BFIHRvIE5laWdoYm9yIEFkdmVydGlzZW1lbnRzDQogICAgICAgIG1lc3NhZ2Ugc2luY2UgSU5E IHByb3RvY29sIGlzIGp1c3QgdGhlIGV4dGVuc2lvbiB0byB0aGUgSVB2NiBOZWlnaGJvcg0KICAg ICAgICBEaXNjb3ZlcnkuobENCg0KRGlkIHRoaXMgYW5zd2VyIHRoZSBxdWVzdGlvbiwgb3IgZG8g eW91IGhhdmUgb3RoZXIgcXVlc3Rpb25zIHJlZ2FyZGluZyB0aGUgcmVzcG9uc2liaWxpdGllcyBv ZiBJV0Y/DQoNClJlZ2FyZHMsDQpXaWxsDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiBGcm9tOiB2Nm9wcy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86djZvcHMtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+IEppZXhpbiBaaGFuZw0KPiBTZW50OiBXZWRuZXNkYXks IEp1bHkgMjUsIDIwMTIgOTo0MSBBTQ0KPiBUbzogd2FuZy5jdWkxQHp0ZS5jb20uY24NCj4gQ2M6 IHY2b3BzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbdjZvcHNdICJSRTogZ29hbHMgb2YgZHJh ZnQtemhhbmctdjZvcHMtaXB2Nm9hLWl3Zi0wMC50eHQgIg0KPiANCj4gMjAxMi83LzI1LCBKaWV4 aW4gWmhhbmcgPGVzdHJlbGxhemhhbmcyMDEyQGdtYWlsLmNvbT46DQo+ID4gVGhhbmtzIGZvciB0 aGUgY29tbWVudHMgZnJvbSBNaXNzIFdhbmcuICBBY3R1YWxseaOsSSB0aGluayBJV0YgbWVhbnMg aXQNCj4gY2FuIHBlcmZvcm0gYm90aCBsYXllcjIgYW5kIElQIGZ1bmN0aW9uLiBUaGVyZWZvcmUs IElXRiBjYW4gYmUNCj4gcGVyZm9ybWVkIGluIGEgbGF5ZXIgMiBub2RlLCBzdWNoIGFzIGFuIEFU TSBzd2l0Y2gsIHdoaWNoIHdvcmtzIGxpa2UNCj4gdGhlIElQdjRvQSBJV0YgaW4gQVRNIHN3aXRj aCB1c3VhbGx5LiAgQW5kIGl0IGNhbiBhbHNvIGJlIHBlcmZvcm1lZA0KPiBpbiBhIGxheWVyIDMg bm9kZSwgQlJBUyBhcyBhbiBleGFtcGxlLiBJbiB0aGlzIGRyYWZ0LCB3ZSBqdXN0IGRlZmluZWQN Cj4gSVdGIGlzIGluIGEgbGF5ZXIgMiBub2RlLg0KPiA+DQo+IH5+SlgNCj4gPg0KPiA+IDIwMTIv Ny8yNCwgd2FuZy5jdWkxQHp0ZS5jb20uY24gPHdhbmcuY3VpMUB6dGUuY29tLmNuPjoNCj4gPj4g SGksDQo+ID4+DQo+ID4+IEkgaGF2ZSB0aHJvdWdobHkgcmVhZCB0aGlzIGRyYWZ0IGFuZCB0aGUg ZGlzY3Vzc2lvbnMgb24gdGhlIG1haWxpbmcgbGlzdCwNCj4gPj4gdGhlIHByZXZpb3VzIHF1ZXN0 aW9ucyBmcm9tIGZyZWQgYW5kIEouUyBoZWxwIG15IHVuZGVyc3RhbmRpbmcgYWJvdXQgdGhpcw0K PiA+PiBkcmFmdCwNCj4gPj4gYW5kIHRoaXMgc29sdXRpb24gc2VlbXMgbW9yZSBlY29ub21pY2Fs IHdoaWNoIGp1c3QgbmVlZCB1cGRhdGVzIHRoZQ0KPiA+PiB2ZXJzaW9uIG9mDQo+ID4+IHRoZSBB VE0gbm9kZXMgdGhhbiBidXlpbmcgZXh0cmEgZXF1aXBtZW50cyB0byByZXBsYWNlIHRoZSBsb2Nh dGVkIEFUTQ0KPiA+PiBub2RlcyBvciBBVE0gbmV0d29ya6O7DQo+ID4+DQo+ID4+IEJ1dCBoZXJl IEkgaGF2ZSBhIGNvbW1lbnQ6DQo+ID4+DQo+ID4+ICAgICAxKSBZb3Ugc2FpZCB0aGUgIkludGVy d29ya2luZyBGdW5jdGlvbiIgaXMgYSBsYXllciAyIG5vZGUsIGJ1dCBpbg0KPiA+PiBzZWN0aW9u IDQuMix3aGF0IHRoZSBJUHY2b0EgSVdGIGRvIHNlZW1zIGxpa2UgYQ0KPiA+PiAgICAgICAgIGxh eWVyIDMgbm9kZSBiZWNhdXNlIHRoaXMgbm9kZSBoYXMgdG8gZGVhbCB3aXRoIElQIGFkZHJlc3Mu IFdoYXQNCj4gPj4gZG8geW91IHRoaW5rID8NCj4gPj4NCj4gPj4gVGhhbmtzfg0KPiA+PiBDdWkg V2FuZw0KPiA+Pg0KPiA+Pg0KPiA+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+PiBaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90 aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbA0KPiA+PiAoYW5kDQo+ ID4+IGFueSBhdHRhY2htZW50IHRyYW5zbWl0dGVkIGhlcmV3aXRoKSBpcyBwcml2aWxlZ2VkIGFu ZCBjb25maWRlbnRpYWwgYW5kDQo+ID4+IGlzDQo+ID4+IGludGVuZGVkIGZvciB0aGUgZXhjbHVz aXZlIHVzZSBvZiB0aGUgYWRkcmVzc2VlKHMpLiAgSWYgeW91IGFyZSBub3QgYW4NCj4gPj4gaW50 ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRp b24gb3Igb3RoZXINCj4gPj4gZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlIGluZm9ybWF0aW9u IGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLg0KPiA+PiBJZiB5b3UgaGF2ZSByZWNl aXZlZCB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cw0K PiA+PiBpbW1lZGlhdGVseS4NCj4gPj4NCj4gPj4NCj4gPg0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4gdjZv cHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9w cw0K From pkern@spike.0x539.de Wed Jul 25 02:24: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 0918321F84B6 for ; Wed, 25 Jul 2012 02:24:53 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kaIqeK6xhcb6 for ; Wed, 25 Jul 2012 02:24:52 -0700 (PDT) Received: from hub.kern.lc (hub.kern.lc [IPv6:2a00:1158:3::c7]) by ietfa.amsl.com (Postfix) with ESMTP id 679C121F8454 for ; Wed, 25 Jul 2012 02:24:52 -0700 (PDT) Received: from [2001:470:720c:0:7c26:800f:8492:6266] (helo=spike.0x539.de) by hub.kern.lc with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Stxpj-0002Z0-2O; Wed, 25 Jul 2012 11:24:43 +0200 Received: from pkern by spike.0x539.de with local (Exim 4.80) (envelope-from ) id 1Stxpp-0004I4-ET; Wed, 25 Jul 2012 11:24:49 +0200 Date: Wed, 25 Jul 2012 11:24:49 +0200 From: Philipp Kern To: Aleksi Suhonen Message-ID: <20120725092449.GA16178@spike.0x539.de> References: <500B5715.8050002@tut.fi> <20120723183413.GB14528@spike.0x539.de> <500F6AB7.3020709@tut.fi> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="zYM0uCDKw75PZbzx" Content-Disposition: inline In-Reply-To: <500F6AB7.3020709@tut.fi> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: v6ops@ietf.org, lutchann@litech.org Subject: Re: [v6ops] draft-chen-v6ops-nat64-experience-02 Stateless NAT64 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 25 Jul 2012 09:24:53 -0000 --zYM0uCDKw75PZbzx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 25, 2012 at 06:40:39AM +0300, Aleksi Suhonen wrote: > On 07/23/2012 09:34 PM, Philipp Kern wrote: > >am Mon, Jul 23, 2012 at 01:28:23PM -0500 hast du folgendes geschrieben: > >>Thanks for pointing this out. I am still puzzled, tayga is using DNS64 > >>and they talk about NAT44. > >tayga implements NAT64, not DNS64 (for instance bind9 could be used for = the > >latter). NAT44 is needed because the IPv6 source addresses are mapped in= to a > >private IPv4 pool by default, which then needs masquerading (aka NAT44) = into > >the public internet. The site even says this: > I would simplify the above like this: >=20 > Tayga implements Stateless NAT64, but it can be used to build a > Stateful NAT64 setup by adding a NAT44 next to it. Except that it it stateful already with the default dynamic pool, but it ca= n be used statelessly. Kind regards Philipp Kern --zYM0uCDKw75PZbzx Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEAREIAAYFAlAPu2EACgkQ7Ro5M7LPzdj76wCg8UXRa/FISvkOaTmUfe2lTlW9 FacAoMFbOE2NkJkruSoIgQ6IKPEjjpa3iQEcBAEBCAAGBQJQD7thAAoJEERuJUU1 0FbsJFcH/2LN9u1TOFFOLzBb6L7QkTo46rUwz+xLanLgKdq/QImxAY17G15Ov1Dr hHjaoE8Uq9qzxBRK4UFZ9XpTHdDZ87K5fGnUyTizGQbrNtP41bX4yD0ZQw5asZ0C CBEaYGgvnuak68P6n+Y9uh0skMeCMEA7zlM3ovtItjALbI6/TMwtidy48yLPEIK4 O1e6FtnDC5v59mPbt+iWu4bim7kZAMyXiWrM7RZ39t1SF+zqrhjTYLi4OM/v7RqP GMbpdUwQl2hSpNdJbChUN/WiRkrMhPtgq6Vi6gHs4zvy5IeX/BhJ765+oS2TvZQz zIQf2t3Lf+gAPNOKtJoNgzhXMkf7WAM= =Fkhf -----END PGP SIGNATURE----- --zYM0uCDKw75PZbzx-- From joelja@bogus.com Wed Jul 25 08:48: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 4948521F8679 for ; Wed, 25 Jul 2012 08:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.237 X-Spam-Level: X-Spam-Status: No, score=-102.237 tagged_above=-999 required=5 tests=[AWL=0.362, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ipiII3vSPEfX for ; Wed, 25 Jul 2012 08:48:45 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id AEB0621F8666 for ; Wed, 25 Jul 2012 08:48:45 -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 q6PFmLZ2081957 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 25 Jul 2012 15:48:22 GMT (envelope-from joelja@bogus.com) Message-ID: <50101545.40808@bogus.com> Date: Wed, 25 Jul 2012 08:48:21 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120717 Thunderbird/15.0 MIME-Version: 1.0 To: "Zhouqian (Cathy)" References: <28DC472D-01D4-4534-97A9-6AE52BE9CC58@tid.es> <4FF70D8F.5010706@bogus.com> <4FFDB38F.3080206@bogus.com> <4FFE79DA.3010408@gmail.com> <4FFFD257.4060609@bogus.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, 25 Jul 2012 15:48:22 +0000 (UTC) Cc: IPv6 Ops WG Subject: Re: [v6ops] Draft on DC migration to IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 25 Jul 2012 15:48:46 -0000 On 7/15/12 8:37 PM, Zhouqian (Cathy) wrote: > Hi Joel, > >> -----Original Message----- >> From: Joel jaeggli [mailto:joelja@bogus.com] >> Sent: Friday, July 13, 2012 3:47 PM >> To: Zhouqian (Cathy) >> Cc: Brian E Carpenter; Qiong; IPv6 Ops WG >> Subject: Re: [v6ops] Draft on DC migration to IPv6 >> >> On 7/12/12 01:05 , Zhouqian (Cathy) wrote: >> >>> Full IPv6 in datacenter is the ultimate goal. However, the datacenter >>> supporting IPv6 is not only network supporting, but also application >>> layer supporting. Supporting IPv6 is a huge cost for the existing >>> IPv4 only datacenter and some small ICPs. >> You're making an assertion you'd have to support with data. > There are only a few ICPs supporting IPv6 in China. But China is one of the countries > which most lacks IPv4 addresses. The main reason is the cost and the small IPv6 traffic. Internet content providers are rather efficient users of ipv4 addresses on a host count vs address consumption basis, much moreso than retail ISPs. Rather than perpetuate a myth of indigenous internet exceptional-ism which you have little evidence to support I would focus on advice to internet content providers that does not leave them worse of then they are remaining ipv4-only. >>> Currently, the IPv6 traffic >>> and users are only a small part. Forcing the datacenter to fully >>> support IPv6 is not a good choice at the beginning of IPv6 migration, >>> and it may even impact the evolution of IPv6. >> I've never asserted that. What I have asserted is that nat64 translation >> loses me the approximation of source addresses and my customers don't >> consider that acceptable today regardless if the source addresses are >> ipv4 or ipv6. > You are correct and the problem does exist in nat64 translation. But at the first > stage of IPv6 datacenter transition when the client is v6 but the datacenter is still v4, > this scenario is inevitable. No it is not. It is not inevitable in my environment nor in that of many other operators. > We should think a better way to solve this. This is an ops working group. we don't need more transition technology to provide advice to operators. in many respects we need less. > But currently > nat64 translation or IPv6 in IPv4 tunnel may be possible solutions. > >>> It may be a good way to >>> let current IPv4 only datacenter support IPv6 with small change. >>> Through this way, it can promote the growth of IPv6 traffic. >> So consider, as an operator, if your requirement were to provide the >> source address as you recived it, how would you do that? >> >> some (but certainly not a complete list of) possible answers are: >> >> proxy where possible, that works fine for http/s/websockets/spdy >> >> tunnel, all the way to the host if like. that can be done statelessly >> and it leverages the fact that your servers have ipv6 stacks and support >> ip-in-ip tunneling and have for more than a decade. >> >> Be selective rather than plunging towards dualstack DC, customer facing >> assets are only a portion of the stack that looks more like some of the >> further discussion in this document. > For some IPv6 applications in IPv4 only datacenter, we could use an IPv4 header > in the original IPv6 packet(v6 in v4 tunnel). But for some content which does not > support IPv6, translation is still needed. > >>> Cathy >>> > From sarikaya2012@gmail.com Wed Jul 25 08:58: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 0505821F86B0 for ; Wed, 25 Jul 2012 08:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.539 X-Spam-Level: X-Spam-Status: No, score=-3.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kXfj4EIR4bZr for ; Wed, 25 Jul 2012 08:58:07 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2D90421F86AF for ; Wed, 25 Jul 2012 08:58:07 -0700 (PDT) Received: by ghbg16 with SMTP id g16so981911ghb.31 for ; Wed, 25 Jul 2012 08:58:06 -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=l9UaXN+uMPkbc/EFDTn23RmUFZq5UpHyo5JZ1nfyBmQ=; b=oWBsekiVl+fMTHuKzN3hHIxbpkBYe3s4RxrYBFt1E91zr+LMWLK1luWYmHiHw6Wf1P /+GtoASqFWKBhBtZ6RV0IbNQfuMynlIJRDSvE9E3EQOGtgDhv5xDoeh5seFteijwWmty j7eNJMo2fInwiT2QqIIkxt+8iK1xxEn4Bki51qi8mctDlM1hXNpbWQNd3K91VmUA/27c eWi1r3xiwhicDjwop1wVszzrCgYMWM83c4Cti3FMJdq2DtfJtwTGAEQuC+yN1tB3G28W kBKxs9wF4Bpzsum+dd7yLGDjgmu4ihWXWfzMVUwk8eYbq2PnN/HHRS4IvMXtvZkIIRop UVog== MIME-Version: 1.0 Received: by 10.43.46.194 with SMTP id up2mr25789128icb.22.1343231886423; Wed, 25 Jul 2012 08:58:06 -0700 (PDT) Received: by 10.231.207.167 with HTTP; Wed, 25 Jul 2012 08:58:06 -0700 (PDT) In-Reply-To: References: <500B5715.8050002@tut.fi> Date: Wed, 25 Jul 2012 10:58:06 -0500 Message-ID: From: Behcet Sarikaya To: Nathan Lutchansky Content-Type: text/plain; charset=ISO-8859-1 Cc: Aleksi Suhonen , v6ops@ietf.org Subject: Re: [v6ops] draft-chen-v6ops-nat64-experience-02 Stateless NAT64 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: Wed, 25 Jul 2012 15:58:08 -0000 On Tue, Jul 24, 2012 at 5:19 PM, Nathan Lutchansky wrote: > On Tue, 24 Jul 2012, Behcet Sarikaya wrote: >> >> On Tue, Jul 24, 2012 at 4:44 PM, Nathan Lutchansky >> wrote: >>> >>> >>> TAYGA is an implementation of RFC 6145 with a small extension: if an >>> incoming IPv6 packet has a source address that cannot be translated per >>> RFC >>> 6052, TAYGA can be configured to automatically bind that address for a >>> time >>> to a free IPv4 address from an administratively-configured pool. In this >>> configuration TAYGA is not truly stateless, but it still maintains no >>> state >>> regarding transport layer flows. >> >> >> Hi Nathan, >> >> I don't know the relationship of tayga and this presentation: >> >> >> http://fud.no/talks/20120417-RIPE64-The_Case_for_IPv6_Only_Data_Centres.pdf >> >> >> which is a stateless translator maintains the binding information of >> *src.IPv6->src.IPv4 address* >> >> It seems that this is what is called Stateless NAT64. >> >> Reading the above >> presentation, Stateless NAT64 solves the reverse problem of NAT64, >> i.e. IPv4-only client >> talking to IPv6-only server. >> >> So as far as I am concerned the puzzle of Stateless NAT64 is solved. > > > Hi Behcet, > > Tore's presentation which you linked describes a stateless NAT64 scenario in > which the IPv6 addresses of all of the IPv6 nodes which need to utilize the > NAT64 translator are already known and can be statically bound to an IPv4 > address in the NAT64 configuration. > > The presentation does not address the scenario where the NAT64 translator is > not pre-configured with a list of all the IPv6 addresses it will need to > translate. This would occur if a NAT64 translator could be utilized by any > IPv6 node in a large network. In this case, the translator must dynamically > bind an available IPv4 address to each IPv6 node that attempts to use the > translation service. This is not behavior that is specified in RFC 6145, > but it is implemented in TAYGA. > > Does that answer your question? -Nathan So tayga is a not so "stateless" form of so-called stateless NAT64. I am amazed by the confusing terminology that is created around the good old NAT64. It would have been better to use a different name, like IVI. Behcet From tore@redpill-linpro.com Wed Jul 25 09:58: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 40DD921F86B6 for ; Wed, 25 Jul 2012 09:58: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kc8zxmJrtTwM for ; Wed, 25 Jul 2012 09:58:41 -0700 (PDT) Received: from zimbra.redpill-linpro.com (zimbra.redpill-linpro.com [87.238.49.234]) by ietfa.amsl.com (Postfix) with ESMTP id E55A321F86A0 for ; Wed, 25 Jul 2012 09:58:39 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.redpill-linpro.com (Postfix) with ESMTP id 0C6281820047; Wed, 25 Jul 2012 18:58:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at claudius.linpro.no Received: from zimbra.redpill-linpro.com ([127.0.0.1]) by localhost (zimbra.redpill-linpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C7616qyn0vG6; Wed, 25 Jul 2012 18:58:37 +0200 (CEST) Received: from zimbra.redpill-linpro.com (claudius.linpro.no [87.238.49.234]) by zimbra.redpill-linpro.com (Postfix) with ESMTP id 70C37182002B; Wed, 25 Jul 2012 18:58:37 +0200 (CEST) Date: Wed, 25 Jul 2012 18:58:37 +0200 (CEST) From: Tore Anderson To: sarikaya@ieee.org Message-ID: <1859800325.18044802.1343235517392.JavaMail.root@claudius.linpro.no> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailer: Zimbra 7.1.4_GA_2555 (ZimbraWebClient - FF3.0 (Linux)/7.1.4_GA_2555) Cc: Aleksi Suhonen , v6ops@ietf.org, Nathan Lutchansky Subject: Re: [v6ops] draft-chen-v6ops-nat64-experience-02 Stateless NAT64 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 25 Jul 2012 16:58:42 -0000 Hello, * Nathan Lutchansky >> Tore's presentation which you linked describes a stateless NAT64 >> scenario in which the IPv6 addresses of all of the IPv6 nodes >> which need to utilize the NAT64 translator are already known and >> can be statically bound to an IPv4 address in the NAT64 >> configuration. >>=20 >> The presentation does not address the scenario where the NAT64 >> translator is not pre-configured with a list of all the IPv6 >> addresses it will need to translate. Actually, only a single slide (22) in the deck discusses a situation where a list of explicit translations are configured on the translator(s). This behaviour is not specified in RFC 6052, but I believe it would be very useful feature for my use case. The rest of the presentation is all about pure RFC 6052+6145 operation. The address mapping algorithm in RFC 6052 does not require the individual IPv6 addresses to be configured, the only thing you need to configure is the prefixes you'll be using for translation. An example of a complete configuration is found in appendix B in the slide deck. I ran it in production for several months, worked great. >> In this case, the translator must dynamically bind an available >> IPv4 address to each IPv6 node that attempts to use the >> translation service. This is not behavior that is specified in >> RFC 6145, but it is implemented in TAYGA. That sounds very much like a stateful approach to me, the word "dynamically" is a dead giveaway... * Behcet Sarikaya > So tayga is a not so "stateless" form of so-called stateless NAT64. > I am amazed by the confusing terminology that is created around the > good old NAT64. >=20 > It would have been better to use a different name, like IVI. Heh. =C2=ABIVI=C2=BB is no better. I've looked, and I can find no official definition of the term. RFC 6219 refers to it, but what =C2=ABIVI=C2=BB act= ually is the name of, as far as I can tell, is a long-defunct Linux implementation of RFC 6052+6145 found at www.ivi2.org. Similarly, =C2=ABStateless NAT64=C2=BB isn't a official standard either, as the only mention of =C2=ABNAT64=C2=BB is in RFC 6146 - that only defines =C2=ABState= ful NAT64=C2=BB. The most correct name that I've found for the technology (as opposed to individual implementations) is =C2=ABSIIT=C2=BB, which is defined in RFC= 6145. Tore From rajiva@cisco.com Wed Jul 25 13: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 6030021F870A for ; Wed, 25 Jul 2012 13:56:31 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nAmAvAsN25Wx for ; Wed, 25 Jul 2012 13:56:30 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 71F6721F86F8 for ; Wed, 25 Jul 2012 13:56:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=4532; q=dns/txt; s=iport; t=1343249790; x=1344459390; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=SePrfehN7C1cj0AnN9dDa3PyymGMZpxYDeh2U1ynBYo=; b=ClblQLm3PDATDQ19wRXhlt0fzWOmsrmM19gZIZwtg4/4T9wSycMssqNK AYH3MrtzISyUqFZv+iIvCn9q2DIV0CkD2grvJVE9PxMqDddGtbgPP7XcB VHIKs+lvTnQch/+Q6z1qKqSv0zKEO6V7NSaA0Kk720gEil/jVC7GjuAZe w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFABBdEFCtJV2a/2dsb2JhbABFuU2BB4IgAQEBAwEBAQEPASc0CwUHBAIBCBEEAQELFAkHJwsUCQgCBAENBQgRAgeHZQYLmzSPFpE9i00UhgBgA6NwgWaCX4FWCQ X-IronPort-AV: E=Sophos;i="4.77,654,1336348800"; d="scan'208";a="105117807" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 25 Jul 2012 20:56:30 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q6PKuTDn000875 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 25 Jul 2012 20:56:29 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.67]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0298.004; Wed, 25 Jul 2012 15:56:29 -0500 From: "Rajiv Asati (rajiva)" To: Tore Anderson , Tassos Chatzithomaoglou Thread-Topic: [v6ops] current solutions for incoming connections in CGN environments Thread-Index: AQHNZSSg016jmcx22UOeFn6kOjj21ZcwcLaAgAoUnOA= Date: Wed, 25 Jul 2012 20:57:13 +0000 Message-ID: References: <5006E47F.8010605@forthnetgroup.gr> <5006FE33.7090903@forthnetgroup.gr> <20120718191000.GW38127@Space.Net> <50071D89.9070601@forthnetgroup.gr> <5007A223.1090003@redpill-linpro.com> In-Reply-To: <5007A223.1090003@redpill-linpro.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.243.58] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19064.001 x-tm-as-result: No--47.485900-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 WG" Subject: Re: [v6ops] current solutions for incoming connections in CGN environments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 25 Jul 2012 20:56:31 -0000 > MAP rides on top of IPv6 in much the same way as DS-Lite, so since you've > already implemented IPv6, you've already done with the hard part. > Another very nice thing about it compared to DS-Lite is that it is entire= ly > stateless in the core (just simple NAT44 in the CPEs like today). >=20 > I think it fails your criteria, though. But... Turns out that there are available implementations (on routers and CPE/home= gateways) that will be demoed at the IETF next week. There was an email ab= out it on softwire WG. Cheers, Rajiv > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Tore Anderson > Sent: Thursday, July 19, 2012 1:59 AM > To: Tassos Chatzithomaoglou > Cc: v6ops@ietf.org WG > Subject: Re: [v6ops] current solutions for incoming connections in CGN > environments >=20 > Hi Tassos, >=20 > * Tassos Chatzithomaoglou >=20 > > Gert, i'm more than open to proposals. > > Our IPv6 is completed, our DS-Lite will be completed soon, our > > customers are growing, our IPv4 addresses will be over soon...and IPv4 > > content (and traffic?) is still ~99%. > > Am i missing something obvious? >=20 > No. If it's any consolation, it's not only you - we're all in the same sh= itty > situation. By deploying IPv6 you are way ahead of most people in dealing > with it though, congratulations! >=20 > That said, according to Google's statistics at > http://www.google.com/ipv6/statistics.html#tab=3Dper-country-ipv6- > adoption > there are essentially no IPv6 traffic seen from Greece, which is odd as > Forthnet is a large source of Greek eyeball traffic (second only to OTE i= n my > netflow stats). Is your IPv6 implementation inside a walled garden or is > there any other reason why it isn't show up in public stats like Google's= ? >=20 > > I'm a fanatic supporter of IPv6, but as long as IPv6-only solutions do > > not cover us (and our customers), we'll have to keep investing on IPv6 > > + IPv4. > > We could very easily have chosen the IPv4-only way of doing CGN > > things, but we chose DS-Lite in order to prepare for the future. > > If there is a better solution (currently available), i'm more than > > happy to discuss it (broadcast or unicast). >=20 > I suggest you look into the MAP/4RD stuff. Like DS-Lite and NAT444, it > facilitates IPv4 address sharing between subscribers, but it does it with= out a > CGN component - each subscriber gets an official IPv4 address routed all = the > way to his CPE like today, but a limited set of TCP/UDP ports. From this = port > range, the user can set up port forwardings using UPnP or manual CPE conf= ig > just like he can today. You can also, if I understand correctly, provisio= n an > "entire" IPv4 address over MAP/4RD too, for example as a "premium" paid- > for service for customers who insist on having specific well-known ports > available to them. >=20 > MAP rides on top of IPv6 in much the same way as DS-Lite, so since you've > already implemented IPv6, you've already done with the hard part. > Another very nice thing about it compared to DS-Lite is that it is entire= ly > stateless in the core (just simple NAT44 in the CPEs like today). >=20 > I think it fails your criteria, though. But... >=20 > > Unless, if buying IPv4 addresses is considered a better solution. But > > then you avoid CGN and IPv6. >=20 > ...the RIPE NCC still has more than 10 million IPv4 addresses in its free= pool, > and you can still allocate normally from it. So by making an allocation n= ow, > you will have bought yourself three months of time before you have to lig= ht > up your DS-Lite CGN, in which you can wait for (or even better - help > finalise!) PCP and/or MAP. I wouldn't abandon DS-Lite though, having a > contingency plan ready to go the moment you need it is certainly smart. >=20 > I don't understand why a strategy of buying IPv4 addresses instead of > deploying any IPv4 address sharing solution would make you , > though. IPv4 life-support and IPv6 deployments seem orthogonal to me, > except that the former may benefit from the latter in the case of DS-Lite= , > MAP, and similar. >=20 > Best regards, > -- > Tore Anderson > Redpill Linpro AS - http://www.redpill-linpro.com >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From achatz@forthnetgroup.gr Thu Jul 26 00:40: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 2CDBD21F8726 for ; Thu, 26 Jul 2012 00:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QwLMnr9LJbd7 for ; Thu, 26 Jul 2012 00:40:37 -0700 (PDT) Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.107]) by ietfa.amsl.com (Postfix) with ESMTP id 618D121F870B for ; Thu, 26 Jul 2012 00:40:33 -0700 (PDT) Received: from mx-av-05.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-04.forthnet.gr (8.14.4/8.14.4) with ESMTP id q6Q7eOim018507; Thu, 26 Jul 2012 10:40:24 +0300 Received: from MX-IN-04.forthnet.gr (mx-in-04.forthnet.gr [193.92.150.163]) by mx-av-05.forthnet.gr (8.14.4/8.14.4) with ESMTP id q6Q7eOni010598; Thu, 26 Jul 2012 10:40:24 +0300 Received: from [192.168.1.2] (46.246.222.140.dsl.dyn.forthnet.gr [46.246.222.140]) (authenticated bits=0) by MX-IN-04.forthnet.gr (8.14.4/8.14.4) with ESMTP id q6Q7eE2X031568; Thu, 26 Jul 2012 10:40:15 +0300 Authentication-Results: MX-IN-04.forthnet.gr smtp.mail=achatz@forthnetgroup.gr; auth=pass (PLAIN) Message-ID: <5010F458.9040706@forthnetgroup.gr> Date: Thu, 26 Jul 2012 10:40:08 +0300 From: Tassos Chatzithomaoglou User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120615 Firefox/13.0.1 SeaMonkey/2.10.1 MIME-Version: 1.0 To: Francis Dupont References: <201207241045.q6OAjj3Y048198@givry.fdupont.fr> In-Reply-To: <201207241045.q6OAjj3Y048198@givry.fdupont.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] current solutions for incoming connections in CGN environments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 26 Jul 2012 07:40:38 -0000 Francis Dupont wrote on 24/7/2012 13:45: > In your previous mail you wrote: > >> I'm looking for opinions and recommendations regarding the known >> limitations with incoming connections & port forwarding in CGN-like >> environments (preferably DS-Lite), in environments with multiple >> layers of NAT or when NAT is not taking place on the CPE. > => UPnP IGD v2 (with the whole new framework, BTW not the v1) does the > job but I don't know if it is popular for CGN vendors. BTW it was published > ~20 months ago... I must admit that i haven't looked too much at UPnP stuff, but isn't that supposed to work between the host and the CPE on the LAN side? Are there any UPnP IGD implementations having to do with the connection between the CPE and the CGN on the WAN side? >> If i'm not mistaken, currently you cannot have such a functionality >> based on standards. > => define "standards" (:-)... I'm actually referring to protocols than have become proposed standard RFCs. Regards, Tassos From Francis.Dupont@fdupont.fr Thu Jul 26 06: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 C9C0321F8760 for ; Thu, 26 Jul 2012 06:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fKodymAnCjoH for ; Thu, 26 Jul 2012 06:18:45 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id ED57C21F872E for ; Thu, 26 Jul 2012 06:18:44 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q6QDIZU8035455; Thu, 26 Jul 2012 15:18:35 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201207261318.q6QDIZU8035455@givry.fdupont.fr> From: Francis Dupont To: Tassos Chatzithomaoglou In-reply-to: Your message of Thu, 26 Jul 2012 10:40:08 +0300. <5010F458.9040706@forthnetgroup.gr> Date: Thu, 26 Jul 2012 15:18:35 +0200 Sender: Francis.Dupont@fdupont.fr Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] current solutions for incoming connections in CGN environments X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 26 Jul 2012 13:18:46 -0000 In your previous mail you wrote: > I must admit that i haven't looked too much at UPnP stuff, but > isn't that supposed to work between the host and the CPE on the LAN > side? => yes but there is nothing which makes it to not work between the host(s) and the CGN when you have replaced the multicast discovery by something more explicit. > Are there any UPnP IGD implementations having to do with the > connection between the CPE and the CGN on the WAN side? => why bother with the CPE? the NAT is the CGN so it is the device you want to control (note you can go to A+P solutions like light weight DS-Lite too, or simply IPv6...) and UPnP IGD v2 provides this. BTW for real world solutions you have the portal (i.e., a web interface where customers can configure port forwarding entries) which is very common. Note it is not a bad idea to just have one (or a few) static entrie(s) for a ssh or TLS tunnel port where the incoming connections are multiplexed in a secure way: not secure dynamic forwarding entries can be stolen as CGNs don't use stable storage to keep them (*)... Regards Francis.Dupont@fdupont.fr (*): in fact for "legal" logs CGNs have stable storage but ISPs which deploy CGNs usually don't care about customer security or similar service quality... From estrellazhang2012@gmail.com Tue Jul 24 17:54: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 80F9811E80B8 for ; Tue, 24 Jul 2012 17:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.034 X-Spam-Level: X-Spam-Status: No, score=-3.034 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GfXV3VzmA6Wl for ; Tue, 24 Jul 2012 17:54:39 -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 C3B9B11E80A4 for ; Tue, 24 Jul 2012 17:54:38 -0700 (PDT) Received: by wibhr14 with SMTP id hr14so123304wib.13 for ; Tue, 24 Jul 2012 17:54: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:content-transfer-encoding; bh=NqdFB55HF+YL6ga/ZnzWSlYzOBLbvd6JqL/276Eumwg=; b=k6mdz1upjGVBBErqWvAbdG9al1+jAM3vtsL4dnBI5JHcCAQsWcvqhly7uXu7t4Ak2J 9eUorNjEyxuaD/YXHL69r/DcywiKnVSQ32kD37s369VjysaYfM4fY/EZCr+qId7Wsddh OFOQ4txAEBS4SUHsQRFYRHm+v2dX0g2S9ZdkltFoWtt8QlRsKthTcS5llo/A/VIPHV3d pzU9Gz56uXs/XEZB+QwS0RzAyEbNZcwUzrNLTk3p25v62Opy3ctNWq7lihYbDePkuZoW z8iXjFnrZKxv39mcMM3WIaxBcwYDK4axiJhQ29IY3hxY314Zh4aoJmr5fvOkpgGWXjxT pQnA== MIME-Version: 1.0 Received: by 10.180.82.164 with SMTP id j4mr11762801wiy.18.1343177677932; Tue, 24 Jul 2012 17:54:37 -0700 (PDT) Received: by 10.217.2.5 with HTTP; Tue, 24 Jul 2012 17:54:37 -0700 (PDT) In-Reply-To: References: Date: Wed, 25 Jul 2012 08:54:37 +0800 Message-ID: From: Jiexin Zhang To: wang.cui1@zte.com.cn Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 26 Jul 2012 08:12:44 -0700 Cc: v6ops@ietf.org Subject: Re: [v6ops] "RE: goals of draft-zhang-v6ops-ipv6oa-iwf-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: Wed, 25 Jul 2012 00:54:39 -0000 Thanks for the comments from Miss Wang. Actually=A3=ACI think IWF means it can perform both layer2 and IP function. Therefore, IWF can be performed in a layer 2 node, such as an ATM switch, which works like the IPv4oA IWF in ATM switch usually. And it can also be performed in a layer 3 node, BRAS as an example. In this draft, we just defined IWF is in a layer 2 node. 2012/7/24, wang.cui1@zte.com.cn : > Hi, > > I have throughly read this draft and the discussions on the mailing list, > the previous questions from fred and J.S help my understanding about this > draft, > and this solution seems more economical which just need updates the > version of > the ATM nodes than buying extra equipments to replace the located ATM > nodes or ATM network=A3=BB > > But here I have a comment: > > 1) You said the "Interworking Function" is a layer 2 node, but in > section 4.2,what the IPv6oA IWF do seems like a > layer 3 node because this node has to deal with IP address. What > do you think ? > > Thanks~ > Cui Wang > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail (= and > any attachment transmitted herewith) is privileged and confidential and i= s > intended for the exclusive use of the addressee(s). If you are not an > intended recipient, any disclosure, reproduction, distribution or other > dissemination or use of the information contained is strictly prohibited. > If you have received this mail in error, please delete it and notify us > immediately. > > From v6ops@globis.net Thu Jul 26 23:47: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 62EF411E80D2 for ; Thu, 26 Jul 2012 23:47:30 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WK0npo1WoOOm for ; Thu, 26 Jul 2012 23:47:27 -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 87B4C11E80CD for ; Thu, 26 Jul 2012 23:47:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 572958700BB; Fri, 27 Jul 2012 08:47:11 +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 fHXgOm8apuen; Fri, 27 Jul 2012 08:46:49 +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 9C0B887005B; Fri, 27 Jul 2012 08:46:49 +0200 (CEST) Message-ID: <50123953.8080502@globis.net> Date: Fri, 27 Jul 2012 08:46:43 +0200 From: Ray Hunter User-Agent: Postbox 3.0.4 (Macintosh/20120616) MIME-Version: 1.0 To: sarikaya@ieee.org References: <500B5715.8050002@tut.fi> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Aleksi Suhonen , v6ops@ietf.org, Nathan Lutchansky Subject: Re: [v6ops] draft-chen-v6ops-nat64-experience-02 Stateless NAT64 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 27 Jul 2012 06:47:30 -0000 IMHO This may have niche application in managed environments, but anyone who is thinking about deploying *anything* stateful on an IPv6 Internet facing data centre (Section 4 of the draft) needs first to read a health warning in bold about potential resource depletion. For translation: 128 bits of address information does not fit in 32 bits. End of story. And I still don't know of any machine yet built that can fully track state for 128 bits of addressing e.g. to prevent the DoS attack before it reaches the translation pool. We may have solved address depletion, but we've now shifted the bottleneck to memory depletion. I therefore don't think the v6ops wg should be encouraging such risky behaviour as suggested in the draft. Instead, we should be recommending use of end to end native IPv6 when connecting to the IPv6 Internet, and putting strategies in place to ensure individual machines' resources aren't overwhelmed e.g. http://tools.ietf.org/html/draft-carpenter-v6ops-label-balance-02. regards, RayH Behcet Sarikaya wrote: > On Tue, Jul 24, 2012 at 4:44 PM, Nathan Lutchansky wrote: >> On Sun, 22 Jul 2012, Aleksi Suhonen wrote: >>> On 07/18/2012 07:36 PM, Behcet Sarikaya wrote: >>>> So you need to write a draft describing Stateless NAT64 :-), please. >>> These people have been able to implement Stateless NAT64 with the existing >>> drafts and RFCs: >>> >>> http://www.litech.org/tayga/ >> TAYGA is an implementation of RFC 6145 with a small extension: if an >> incoming IPv6 packet has a source address that cannot be translated per RFC >> 6052, TAYGA can be configured to automatically bind that address for a time >> to a free IPv4 address from an administratively-configured pool. In this >> configuration TAYGA is not truly stateless, but it still maintains no state >> regarding transport layer flows. >> >> Regarding Aleksi's experiences with privacy extensions depleting the entire >> dynamic pool, there is not much that can be done about this--it's just one >> more thing that RFC 4941 breaks. I would love to have an RA option that >> forced privacy extensions to be disabled; I would use it on every network I >> maintain. -Nathan > > Hi Nathan, > > I don't know the relationship of tayga and this presentation: > > http://fud.no/talks/20120417-RIPE64-The_Case_for_IPv6_Only_Data_Centres.pdf > > > which is a stateless translator maintains the binding information of > *src.IPv6->src.IPv4 address* > > It seems that this is what is called Stateless NAT64. > > Reading the above > presentation, Stateless NAT64 solves the reverse problem of NAT64, > i.e. IPv4-only client > talking to IPv6-only server. > > So as far as I am concerned the puzzle of Stateless NAT64 is solved. > > Behcet > From phdgang@gmail.com Fri Jul 27 04:04: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 575AF21F863D for ; Fri, 27 Jul 2012 04:04:29 -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.249, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OpqZ6-AI0wuW for ; Fri, 27 Jul 2012 04:04: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 000EC21F8629 for ; Fri, 27 Jul 2012 04:04:12 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so2690789vcb.31 for ; Fri, 27 Jul 2012 04:04: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 :cc:content-type; bh=yk6MsC2GpfGV3wGPLr26MXvYtnUSBtZUaQDGH4BrVwY=; b=gFBrmJb0Mt4uzItndcPuce3+wAM6p5yMPa5bnLl6CD9WZrV6DGogOETevkM0Eb3cjh 12HzkiNCpNze0/WfKEstuiXFU1LyrtMcdzaRancdzOPtcNafuxIdNvY5p/rnnCHzObyb Y/0SHpMiH8NnalbHkSic662wJTVsmjlG0Kz1Op9Xbf6E2gLy9BuGjJ0x8gm+mNqXYmfc /2ydN+y7lA/+oMq07L5hHo+oFtsFRDXug7zyvdT5ZEr6rLweTtVMPbpPJktLmj9h+aMv 6xFQOo9mjzed+NPYoT9Bg3umoCnNH/cpzYlGp/djp7M2AQf1paD7ufLkUKV/XE6qMSSC r9Sw== MIME-Version: 1.0 Received: by 10.52.97.230 with SMTP id ed6mr1756995vdb.65.1343387052389; Fri, 27 Jul 2012 04:04:12 -0700 (PDT) Received: by 10.58.91.179 with HTTP; Fri, 27 Jul 2012 04:04:12 -0700 (PDT) In-Reply-To: <50123953.8080502@globis.net> References: <500B5715.8050002@tut.fi> <50123953.8080502@globis.net> Date: Fri, 27 Jul 2012 19:04:12 +0800 Message-ID: From: GangChen To: Ray Hunter Content-Type: text/plain; charset=ISO-8859-1 Cc: Aleksi Suhonen , Nathan Lutchansky , v6ops@ietf.org Subject: Re: [v6ops] draft-chen-v6ops-nat64-experience-02 Stateless NAT64 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 27 Jul 2012 11:04:29 -0000 2012/7/27, Ray Hunter : > IMHO This may have niche application in managed environments, but anyone > who is thinking about deploying *anything* stateful on an IPv6 Internet > facing data centre (Section 4 of the draft) needs first to read a health > warning in bold about potential resource depletion. For translation: 128 > bits of address information does not fit in 32 bits. End of story. Exactly. The draft asserted the same concern regarding the address depletion >And I > still don't know of any machine yet built that can fully track state for > 128 bits of addressing e.g. to prevent the DoS attack before it reaches > the translation pool. We may have solved address depletion, but we've > now shifted the bottleneck to memory depletion. I therefore don't think > the v6ops wg should be encouraging such risky behaviour as suggested in > the draft. Instead, we should be recommending use of end to end native > IPv6 when connecting to the IPv6 Internet, and putting strategies in > place to ensure individual machines' resources aren't overwhelmed e.g. > http://tools.ietf.org/html/draft-carpenter-v6ops-label-balance-02. I have to apologize if the draft gives you impression that is suggested. We documented that because we are experiencing several cases in which the usage is adopted nowadays. The draft intended to identify the issues and raise a caution, i.e. those off-the-shelf solutions should be constrained to small-scale. FWIW, the draft (which we would post soon) would describe the expense further after chair's kind reviews. Clear statement should be "For operators who already deployed such mode, it should be cautious and aware the problems it may cause. Such usages should be restrained to a relative small-scale, since native IPv6 is always desirable. For operators who seek a clear precedent for operating reliable ipv6-only services, it's not recommended, because the usages is problematic at several aspects." Best Regards Gang > regards, > RayH > > Behcet Sarikaya wrote: >> On Tue, Jul 24, 2012 at 4:44 PM, Nathan Lutchansky >> wrote: >>> On Sun, 22 Jul 2012, Aleksi Suhonen wrote: >>>> On 07/18/2012 07:36 PM, Behcet Sarikaya wrote: >>>>> So you need to write a draft describing Stateless NAT64 :-), please. >>>> These people have been able to implement Stateless NAT64 with the >>>> existing >>>> drafts and RFCs: >>>> >>>> http://www.litech.org/tayga/ >>> TAYGA is an implementation of RFC 6145 with a small extension: if an >>> incoming IPv6 packet has a source address that cannot be translated per >>> RFC >>> 6052, TAYGA can be configured to automatically bind that address for a >>> time >>> to a free IPv4 address from an administratively-configured pool. In >>> this >>> configuration TAYGA is not truly stateless, but it still maintains no >>> state >>> regarding transport layer flows. >>> >>> Regarding Aleksi's experiences with privacy extensions depleting the >>> entire >>> dynamic pool, there is not much that can be done about this--it's just >>> one >>> more thing that RFC 4941 breaks. I would love to have an RA option that >>> forced privacy extensions to be disabled; I would use it on every network >>> I >>> maintain. -Nathan >> >> Hi Nathan, >> >> I don't know the relationship of tayga and this presentation: >> >> http://fud.no/talks/20120417-RIPE64-The_Case_for_IPv6_Only_Data_Centres.pdf >> >> >> which is a stateless translator maintains the binding information of >> *src.IPv6->src.IPv4 address* >> >> It seems that this is what is called Stateless NAT64. >> >> Reading the above >> presentation, Stateless NAT64 solves the reverse problem of NAT64, >> i.e. IPv4-only client >> talking to IPv6-only server. >> >> So as far as I am concerned the puzzle of Stateless NAT64 is solved. >> >> Behcet >> > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From kkumar@google.com Fri Jul 27 14:22: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 A791911E80BA for ; Fri, 27 Jul 2012 14:22:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.361 X-Spam-Level: X-Spam-Status: No, score=-102.361 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Rh+5qc4Cdvq for ; Fri, 27 Jul 2012 14:22:18 -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 D4E1C11E808A for ; Fri, 27 Jul 2012 14:22:17 -0700 (PDT) Received: by qcac10 with SMTP id c10so2228232qca.31 for ; Fri, 27 Jul 2012 14:22:17 -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=3fB37dcglrstRKdQDp7BoUBX/aXdDB6OeuDSSPKHY6s=; b=KrU7RvR0fhyvn4f/6AF2eD8aQz6ZkQPnjP7AWe4aVPqy9zIcbdbbPj8nQRDlBosiJX uzwUBQGZQRBGhw4YW2fcfXmZofplJFhxbrCr6SovJBXD7CTJRUQF1rBb6Hg1qXRMCasJ D3cPqYiJujjVqC3FSHqaDfiTMMahtgEJzmEVvrfj847LxHeaeG2ajek7jOiQ6x1ZKj4M xm9WAjvhkpz7mbWbdyBcsA3JVuQm/hAmsF4qHyF3mCs7O0ZwEqBNoOFsc5ofn6X0ANZF hocKhF0Y9fGItTV4ePaTFVC/6FnLP4xHm6tDMk/TjBxgbKHm54Lk289KNyLxUphP/Fah AZIw== 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=3fB37dcglrstRKdQDp7BoUBX/aXdDB6OeuDSSPKHY6s=; b=kc2B6W5NuY6x9sfhl23JJhnuHmxam9aENpQNkASJO4nD6F3n34VALsq5gI49Wk+wM3 Y9lCtJRlpWyONCggh4n9LMXqSz4uLpm6grXHRo0qKHLfIMGxmea2DZybQoSNlLGy5KdE AMOa6zjrGR8HNdAL3pOnFCxjuNhyuqRUGfWxLv3JqHRoAa1eDS+tGcXyM3ZnJJ+Wf1xx iqNlRwe/tfFKi8PBHlb07FzvMgvGJKiVdixBBCoUKd7zTEZ22qD8tpmGoWmCI/GUPSYn 1+AaWgZy6uxSgvpn8it+syqyWb1AQAcL2VzXfFlVITZmkUqTfx9hUjeu1bHNj8qB/UNA dwXQ== Received: by 10.229.135.19 with SMTP id l19mr1790305qct.129.1343424137349; Fri, 27 Jul 2012 14:22:17 -0700 (PDT) Received: by 10.229.135.19 with SMTP id l19mr1790296qct.129.1343424137199; Fri, 27 Jul 2012 14:22:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.135.76 with HTTP; Fri, 27 Jul 2012 14:21:56 -0700 (PDT) In-Reply-To: <6BCCA339-F0B1-4CAC-A1FA-B2B3DF887D66@magma.ca> References: <20120629134643.1308.69156.idtracker@ietfa.amsl.com> <6BCCA339-F0B1-4CAC-A1FA-B2B3DF887D66@magma.ca> From: KK Date: Fri, 27 Jul 2012 14:21:56 -0700 Message-ID: To: Philip Matthews Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQl8xcdXzA6vjI6nc3BsaJR41BhqjmXnVseG8vf4b7iAhLy+AnD50C8VMCR6Ds1RXOzDHMazpAmdrN3iWatkodqCN4HuUW8BGfhgQEpUlT/PDxDjdfPLp9cc2x/CZpHGCuteyM8BZN42j/Z5/K3kG3kE8eS3/uNqbS90DASQ9nj/wiPJQpc= Cc: v6ops Subject: Re: [v6ops] New draft: draft-matthews-v6ops-design-guidelines-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: Fri, 27 Jul 2012 21:22:18 -0000 Hi Philip, Overall, I think this is useful guidance. A few comments/questions: Section 1. draft-chkpvc-enterprise-incremental-ipv6 (work in progress) aims to provide guidance for enterprises on their IPv6 deployments. You may want to consider adding this as a reference as well. Section 3.1. I am not sure if I am reading this correctly... >An advantage of option (b) is there is only half as many layer 3 interfaces, which can help with scaling. If physical links are used, then there is also a capex advantage. Doesn't using option (b) actually use twice as many layer 3 interfaces? In which case, I am not sure I understand how this would be a capex advantage? It almost seems that your description of advantages for the two options have been swapped around, i.e. the advantage of option (b) is that you get separate measurements for IPv4 and IPv6, while option (a) gets you scaling and capex advantages. Section 3.2. draft-behringer-lla-only (work in progress) talks about using link-local addresses where possible. You may want to consider adding that as a reference. Regards, KK On Fri, Jun 29, 2012 at 11:14 AM, Philip Matthews wrote: > (Looks like my first attempt didn't make it for some reason, so I am > resending. My apologies if you receive two copies.) > > I have submitted a draft entitled "Design Guidelines for IPv6 Networks". The > intent is to present some of the common design choices that come up when > designing IPv6 networks, and document the pros and cons of the various > possible solutions. These are questions like "Should I do eBGP peering with > globals or link-locals?" that come up from time-to-time on mailing lists or > *NOG presentations. The goal is to document them in one place, give fairly > thorough discussion, and present a best-practice (if we can come to some > agreement). > > The document is looking at both IPv6-only networks and mixed IPv4/IPv6 > networks. That is, a number of questions have to do with how IPv4 and IPv6 > should or should not be mixed in a network. > > The current version is very much a work-in-progress, with content in some > areas, but TBDs in other areas. Currently, I have put in content around > point-to-point links, static routing, and eBGP routing. > > I have gotten some interesting feedback on a preliminary version from a > couple of people, but want to see what others say before doing more work on > the document. > > I would be interested in hearing comment on both the general idea of the > document, as well as comments on the current discussion areas and new > discussion areas. > > - Philip > > Begin forwarded message: > > From: internet-drafts@ietf.org > Date: June 29, 2012 9:46:43 EDT > To: philip_matthews@magma.ca > Subject: New Version Notification for > draft-matthews-v6ops-design-guidelines-00.txt > > > A new version of I-D, draft-matthews-v6ops-design-guidelines-00.txt > has been successfully submitted by Philip Matthews and posted to the > IETF repository. > > Filename: draft-matthews-v6ops-design-guidelines > Revision: 00 > Title: Design Guidelines for IPv6 Networks > Creation date: 2012-06-29 > WG ID: Individual Submission > Number of pages: 10 > URL: > http://www.ietf.org/internet-drafts/draft-matthews-v6ops-design-guidelines-00.txt > Status: > http://datatracker.ietf.org/doc/draft-matthews-v6ops-design-guidelines > Htmlized: > http://tools.ietf.org/html/draft-matthews-v6ops-design-guidelines-00 > > > Abstract: > This document presents advice on the design choices that arise when > designing IPv6 networks (both dual-stack and IPv6-only). The > intended audience is someone designing an IPv6 network who is > knowledgeable about best current practices around IPv4 network > design, and wishes to learn the corresponding practices for IPv6. > > > > > The IETF Secretariat > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From kkumar@google.com Fri Jul 27 17:34: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 243BD11E810C for ; Fri, 27 Jul 2012 17:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.362 X-Spam-Level: X-Spam-Status: No, score=-102.362 tagged_above=-999 required=5 tests=[AWL=0.014, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EDwj5dseFFUu for ; Fri, 27 Jul 2012 17:34:54 -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 676C411E8107 for ; Fri, 27 Jul 2012 17:34:54 -0700 (PDT) Received: by lagv3 with SMTP id v3so2531964lag.31 for ; Fri, 27 Jul 2012 17:34:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type :x-system-of-record; bh=2kHtdbVGB9N+e+if//H5rjP4TZcMZBgg0iQrM8P9ng8=; b=lL4yPzzj3MnIgDWzB6e1QfQhjxNAYu/SYhcTekmMeqVMp/Mau0Npf+kRAOBKyf7W83 BICgpz97wwnzOliPjKNQk7Ae7C68bYw/oAETSbOLIVbUvLkkwvNzcU2vTpAp6wkOm+5K H/RE5rKh77T2QXjNSiXbqHPvOcdLg5jzaKew5DDI4ZmGsGJA4T5hB8Bl7bFFBZUBbwXk UXzDRl09UEHTGK/N+t2SCKjgqvJ5h8yvPzJNJHqxzTje5CnAfvf50x+MVs9ObgZuU7wm RyQncB84HHnIgJm6BclAaeDvwg45oNykHSh8HXmrJCu3/YF0S/MiBqN7rkyq7oRHHlFx VYYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type :x-system-of-record:x-gm-message-state; bh=2kHtdbVGB9N+e+if//H5rjP4TZcMZBgg0iQrM8P9ng8=; b=Fk+UVc2szvStkhEfs84L+7Um/8BjjTEZE6MeH4HBdbURCYxekya8daYYvo2KSZ50f1 mPPAfvLjxQW7V+Dol7Zqa2OvuKtLpPa0+XQEgsp3I3oL++sl0PdzM6N+cw/vnzYEGkrl W+6m9bY5c+WvCA4DxfvYjUsn3pcAr0ifwSvsI8DV97Z6jTn2uzBo0yJCrsEDJjlI/Guw fV6DmAew8HhR5XDUv+2TA8Ful7C1E5gxleneOKQVtz4ejzYMKbBVNvbMCcOL2hVJrY8G t0maTImlIIEdci0/ZKdNQ166+XN8EAeao2G6uXcILxT2l3mCzJ8aZZxiaWCTr5Mo+EhJ sPEg== Received: by 10.112.85.42 with SMTP id e10mr2112889lbz.17.1343435693285; Fri, 27 Jul 2012 17:34:53 -0700 (PDT) Received: by 10.112.85.42 with SMTP id e10mr2112885lbz.17.1343435693154; Fri, 27 Jul 2012 17:34:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.116.2 with HTTP; Fri, 27 Jul 2012 17:34:32 -0700 (PDT) From: KK Date: Fri, 27 Jul 2012 17:34:32 -0700 Message-ID: To: v6ops@ietf.org Content-Type: multipart/alternative; boundary=f46d04016dcf44e18304c5d8ff31 X-System-Of-Record: true X-Gm-Message-State: ALoCoQl7SDKanhLLrs5onZfoE5rDlty+R0io05v69J4zZOErC1KXJc7PhCYzRE5z4Z3e+AtX8zdWn4mhASMcU2HPXOcT34BxcBIcTKow5YoF00isoXSI5+8q/iTjzK9dCouqTZlLpVCo1w+3X8QT0ynaGrmRNa3S5yXbiKild250D4Ax6zVFBaw= Cc: opsec chairs Subject: [v6ops] Some IPv6 related drafts in OPSEC WG X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 28 Jul 2012 00:34:55 -0000 --f46d04016dcf44e18304c5d8ff31 Content-Type: text/plain; charset=ISO-8859-1 Hi All, There are some new and/or updated IPv6 related drafts in the opsec WG that could use some additional review from folks in v6ops. http://datatracker.ietf.org/doc/draft-gont-opsec-ipv6-host-scanning/ http://datatracker.ietf.org/doc/draft-gont-opsec-ipv6-implications-on-ipv4-nets/ http://datatracker.ietf.org/doc/draft-gont-opsec-dhcpv6-shield/ http://datatracker.ietf.org/doc/draft-gont-opsec-ipv6-nd-shield/ https://datatracker.ietf.org/doc/draft-vyncke-opsec-v6/ The agenda for opsec's Wednesday session can be found at http://tools.ietf.org/wg/opsec/agenda. Thanks, KK --f46d04016dcf44e18304c5d8ff31 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi All,

There are some new and/or updated IPv6 related d= rafts in the opsec WG that could use some additional review from folks in v= 6ops.


The agenda for opsec's Wednesday session can = be found at=A0http://tools.ietf.org/wg/opsec/agenda.=A0

Thanks,
KK
--f46d04016dcf44e18304c5d8ff31-- From philip_matthews@magma.ca Sun Jul 29 09:18: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 52EF921F8628 for ; Sun, 29 Jul 2012 09:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.007 X-Spam-Level: X-Spam-Status: No, score=-1.007 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0W89+e9PihF for ; Sun, 29 Jul 2012 09:18:39 -0700 (PDT) Received: from mail-02.primus.ca (mail16.primus.ca [216.254.141.183]) by ietfa.amsl.com (Postfix) with ESMTP id 34D2521F85E3 for ; Sun, 29 Jul 2012 09:18:39 -0700 (PDT) Received: from [130.129.20.131] by mail-02.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1SvWCS-00083x-17; Sun, 29 Jul 2012 12:18:36 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Philip Matthews In-Reply-To: Date: Sat, 28 Jul 2012 21:38:14 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <456840DB-E398-4804-848F-716A4D3A2A58@magma.ca> References: <20120629134643.1308.69156.idtracker@ietfa.amsl.com> <6BCCA339-F0B1-4CAC-A1FA-B2B3DF887D66@magma.ca> To: KK X-Mailer: Apple Mail (2.1084) X-Authenticated: philip_matthews - ([130.129.20.131]) [130.129.20.131] Cc: v6ops Subject: Re: [v6ops] New draft: draft-matthews-v6ops-design-guidelines-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: Sun, 29 Jul 2012 16:18:40 -0000 On 2012-07-27, at 17:21 , KK wrote: > Hi Philip, >=20 > Overall, I think this is useful guidance. Thanks very much for your comments. >=20 > A few comments/questions: >=20 > Section 1. > draft-chkpvc-enterprise-incremental-ipv6 (work in progress) aims to > provide guidance for enterprises on their IPv6 deployments. You may > want to consider adding this as a reference as well. I have not seen this draft. I'll take a look at it. The list of references in the draft are still very much a = work-in-progress. > Section 3.1. > I am not sure if I am reading this correctly... >=20 >> An advantage of option (b) is there is only half as many layer 3 = interfaces, which can help with scaling. If physical links are used, = then there is also a capex advantage. >=20 > Doesn't using option (b) actually use twice as many layer 3 > interfaces? In which case, I am not sure I understand how this would > be a capex advantage? >=20 > It almost seems that your description of advantages for the two > options have been swapped around, i.e. the advantage of option (b) is > that you get separate measurements for IPv4 and IPv6, while option (a) > gets you scaling and capex advantages. Yup. Indeed, they got swapped. I guess I need to proofread more carefully next time! :-) >=20 > Section 3.2. > draft-behringer-lla-only (work in progress) talks about using > link-local addresses where possible. You may want to consider adding > that as a reference. That draft is the draft that I meant when I wrote "For more discussion on these points see [recent I-D]". I haven't seen an updated version of this draft yet, so I am not sure = what is happening with it. >=20 > Regards, > KK >=20 > On Fri, Jun 29, 2012 at 11:14 AM, Philip Matthews > wrote: >> (Looks like my first attempt didn't make it for some reason, so I am >> resending. My apologies if you receive two copies.) >>=20 >> I have submitted a draft entitled "Design Guidelines for IPv6 = Networks". The >> intent is to present some of the common design choices that come up = when >> designing IPv6 networks, and document the pros and cons of the = various >> possible solutions. These are questions like "Should I do eBGP = peering with >> globals or link-locals?" that come up from time-to-time on mailing = lists or >> *NOG presentations. The goal is to document them in one place, give = fairly >> thorough discussion, and present a best-practice (if we can come to = some >> agreement). >>=20 >> The document is looking at both IPv6-only networks and mixed = IPv4/IPv6 >> networks. That is, a number of questions have to do with how IPv4 = and IPv6 >> should or should not be mixed in a network. >>=20 >> The current version is very much a work-in-progress, with content in = some >> areas, but TBDs in other areas. Currently, I have put in content = around >> point-to-point links, static routing, and eBGP routing. >>=20 >> I have gotten some interesting feedback on a preliminary version from = a >> couple of people, but want to see what others say before doing more = work on >> the document. >>=20 >> I would be interested in hearing comment on both the general idea of = the >> document, as well as comments on the current discussion areas and new >> discussion areas. >>=20 >> - Philip >>=20 >> Begin forwarded message: >>=20 >> From: internet-drafts@ietf.org >> Date: June 29, 2012 9:46:43 EDT >> To: philip_matthews@magma.ca >> Subject: New Version Notification for >> draft-matthews-v6ops-design-guidelines-00.txt >>=20 >>=20 >> A new version of I-D, draft-matthews-v6ops-design-guidelines-00.txt >> has been successfully submitted by Philip Matthews and posted to the >> IETF repository. >>=20 >> Filename: draft-matthews-v6ops-design-guidelines >> Revision: 00 >> Title: Design Guidelines for IPv6 Networks >> Creation date: 2012-06-29 >> WG ID: Individual Submission >> Number of pages: 10 >> URL: >> = http://www.ietf.org/internet-drafts/draft-matthews-v6ops-design-guidelines= -00.txt >> Status: >> = http://datatracker.ietf.org/doc/draft-matthews-v6ops-design-guidelines >> Htmlized: >> http://tools.ietf.org/html/draft-matthews-v6ops-design-guidelines-00 >>=20 >>=20 >> Abstract: >> This document presents advice on the design choices that arise when >> designing IPv6 networks (both dual-stack and IPv6-only). The >> intended audience is someone designing an IPv6 network who is >> knowledgeable about best current practices around IPv4 network >> design, and wishes to learn the corresponding practices for IPv6. >>=20 >>=20 >>=20 >>=20 >> The IETF Secretariat >>=20 >>=20 >>=20 >>=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 >=20 From joelja@bogus.com Sun Jul 29 10:45: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 6B1F321F857E for ; Sun, 29 Jul 2012 10:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zcTmIP-srazw for ; Sun, 29 Jul 2012 10:45:22 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0FBB021F857D for ; Sun, 29 Jul 2012 10:45:22 -0700 (PDT) Received: from dhcp-6624.meeting.ietf.org (dhcp-6624.meeting.ietf.org [130.129.102.36]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q6THjKX3012428 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sun, 29 Jul 2012 17:45:20 GMT (envelope-from joelja@bogus.com) Message-ID: <501576B0.30603@bogus.com> Date: Sun, 29 Jul 2012 10:45:20 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120717 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]); Sun, 29 Jul 2012 17:45:20 +0000 (UTC) Subject: [v6ops] Reminder, get your slides 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: Sun, 29 Jul 2012 17:45:22 -0000 Our first meeting is on thursday at 0900. if you are speaking in either this session or on friday at 0900. please submitt your slides if you have not done so already. if you have done so, thanks! joel From gilbert_kim@vanguard.com Sun Jul 29 14:49: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 ABD3511E80D5 for ; Sun, 29 Jul 2012 14:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.11 X-Spam-Level: X-Spam-Status: No, score=-5.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QahG+KEufzH5 for ; Sun, 29 Jul 2012 14:49:56 -0700 (PDT) Received: from pslva865.vanguard.com (pslva865.vanguard.com [192.175.204.35]) by ietfa.amsl.com (Postfix) with ESMTP id C5EB611E80C5 for ; Sun, 29 Jul 2012 14:49:49 -0700 (PDT) Received: from pslna812.vanguard.com (pslna812.vanguard.com [10.221.33.198]) by pslva865.vanguard.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.1.1) with ESMTP id q6TLnfbL004349 for ; Sun, 29 Jul 2012 17:49:44 -0400 X-DKIM: OpenDKIM Filter v2.1.3 pslva865.vanguard.com q6TLnfbL004349 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=vanguard.com; s=vanguard; t=1343598584; bh=V32Es4jsdWTZRJn4nMsOKi8y/2Q=; l=823; h=Subject:From:To:Message-ID:Date:MIME-Version:Content-type; b=TASRcRSQfut+gCQilyuRzrD90XH47Z2Des3ix8PCdr+8CkkaMwbOX2mIQr5K5Wy0r b4gR7zPui2tm4Vhkh9RLQ== 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 q6TLnfuQ020656 for ; Sun, 29 Jul 2012 17:49:41 -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 q6TLne2h024010 for ; Sun, 29 Jul 2012 17:49:41 -0400 Auto-Submitted: auto-generated From: gilbert_kim@vanguard.com To: v6ops@ietf.org Message-ID: Date: Sun, 29 Jul 2012 17:49:39 -0400 X-MIMETrack: Serialize by Router on VGI4Mail/VGI(Release 8.5.2FP2|March 22, 2011) at 07/29/2012 05:49:19 PM 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: Sun, 29 Jul 2012 21:49:56 -0000 I will be out of the office starting 07/30/2012 and will not return until 08/13/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 fgont@si6networks.com Sun Jul 29 15:45: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 1C06F21F8592 for ; Sun, 29 Jul 2012 15:45:21 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZD+PSllxYSg for ; Sun, 29 Jul 2012 15:45:20 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 2C69521F857E for ; Sun, 29 Jul 2012 15:45:20 -0700 (PDT) Received: from [2001:df8:0:64:5e26:aff:fe33:7063] by web01.jbserver.net with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1SvcEe-0001ZB-Pk; Mon, 30 Jul 2012 00:45:17 +0200 Message-ID: <5015BCD7.9030007@si6networks.com> Date: Sun, 29 Jul 2012 19:44:39 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: IPv6 Operations X-Enigmail-Version: 1.5a1pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [v6ops] IPv6 Toolkit v1.2.2 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 29 Jul 2012 22:45:21 -0000 Folks, Thought you might be interested: We've released IPv6 toolkit v1.2.2: a set of IPv6 security assessment/troubleshooting tools. The toolkit compiles/runs on Linux, *BSD, and Mac OS. The tarball for version 1.2.2 of the toolkit is available at: http://www.si6networks.com/research/ipv6-toolkit-v1.2.2.tar.gz> Additionally, we have a git repository for the toolkit: This toolkit can be employed to perform local IPv6 scans, assess a number of security aspects of IPv6 implementations (such as predictability of Fragment ID values, etc). It can also be employed to play with IPv6 address resolution, SLAAC, RA-Guard evasion, etc. Any feedback, bug reports, or requests for new features should be sent to: Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From swmike@swm.pp.se Mon Jul 30 03: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 C69D321F8714 for ; Mon, 30 Jul 2012 03:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Adj2Ciqu7YcS for ; Mon, 30 Jul 2012 03:20:32 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 35CD321F8712 for ; Mon, 30 Jul 2012 03:20:31 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 487159C; Mon, 30 Jul 2012 12:20:28 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 41D599A for ; Mon, 30 Jul 2012 12:20:28 +0200 (CEST) Date: Mon, 30 Jul 2012 12:20:28 +0200 (CEST) From: Mikael Abrahamsson To: v6ops@ietf.org Message-ID: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: [v6ops] Different DNS servers depending on dual stack or single stack usage X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 30 Jul 2012 10:20:32 -0000 Hello. I would like to describe a problem that I do not have a solution to, thus trying to solicit possible remedies to it so please fire if you have any thoughts. Let's say we have a network where clients can connect, some will be dual stack, some will be IPv6 only (3GPP for instance, also wifi). In case the client is IPv6 only (single stack), I would like them to have access to DNS64/NAT64 infrastructure. At the same time, I would like to avoid handing out the DNS64 resolver address if the client is dual stacked (I believe that is considered harmful?). How could this be achieved? One way would be to extend the DHCP standard to hand out multiple DNS servers and have them tagged for different use, so the client would need to decide if it's single or dual stack, and choose DNS resolver accordingly. Thoughts? -- Mikael Abrahamsson email: swmike@swm.pp.se From fred@cisco.com Mon Jul 30 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 B5A2C21F8476 for ; Mon, 30 Jul 2012 05:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.932 X-Spam-Level: X-Spam-Status: No, score=-110.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oOxR6J5o5lbi for ; Mon, 30 Jul 2012 05:45:03 -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 3F47621F8444 for ; Mon, 30 Jul 2012 05:45:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=147; q=dns/txt; s=iport; t=1343652303; x=1344861903; h=date:from:message-id:to:subject:cc; bh=xiRPWqgU+rYss5gclF4vxgJCC4Pv7Jhd7Fxibm10geA=; b=DGiuDSKhirP2lNWcwEfkQ6J1nO2m1ZrR7lnne0kcqQAhn7UZW5PP2djq hrQ7VKIItoEhqF145bXpzybh8xq5DBNiWKEZx1rFP1HsxhZaZmZDzMVg1 7vYhGrzS468EPdtbAB2/Ec3BynSwltnND8U39eLqK4o54xhDoDv3kwthJ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnQGAEiAFlCrRDoJ/2dsb2JhbABFhS+jRgGQYIEHgjkBZjwtgQqHagyaQJ9cjxaCPGADiE2OEI0TgWaCfw X-IronPort-AV: E=Sophos;i="4.77,679,1336348800"; d="scan'208";a="50417135" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 30 Jul 2012 12:45:01 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q6UCj1JU018396; Mon, 30 Jul 2012 12:45:01 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id q6UCj1F06725; Mon, 30 Jul 2012 05:45:01 -0700 (PDT) Date: Mon, 30 Jul 2012 05:45:01 -0700 (PDT) From: Message-Id: <201207301245.q6UCj1F06725@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-smith-v6ops-larger-ipv6-loopback-prefix@tools.ietf.org Subject: [v6ops] new draft: draft-smith-v6ops-larger-ipv6-loopback-prefix X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 30 Jul 2012 12:45:03 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-smith-v6ops-larger-ipv6-loopback-prefix. Please take a look at it and comment. From cb.list6@gmail.com Mon Jul 30 06:50: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 1D08421F84B5 for ; Mon, 30 Jul 2012 06:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.154 X-Spam-Level: X-Spam-Status: No, score=-3.154 tagged_above=-999 required=5 tests=[AWL=-0.155, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jh87laIg2IbM for ; Mon, 30 Jul 2012 06:50:17 -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 4E9E621F8464 for ; Mon, 30 Jul 2012 06:50:17 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so3672151lbb.31 for ; Mon, 30 Jul 2012 06:50: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=Khp4QVHpPeE33liTm786e3w2cAAP8TVkjIcpVmqEApg=; b=lTkdlXoLRn0CeWsTRfjPnaQcOYDwTUQgteYPel0qQ4KRWXY9Z6ckm4csql4c9GPPgK HV1A69wzavDHMNPCKF6kMhRD843ghyf6i66eeKyJGbuVm30Cl7jsE88sfivOFR1Y9TPc 48tn6ZsXhhQN3uP4Wj0cZbrOHIcdgYsD0UgQwpDhi9zYrwG1dNvpwW1ArKaY71eutLjf f8UiHOFfOb9XBfr94T0wfH+jtpYaWkVq2h2EcS0R0GhGhGpounf0mia/SZk4OLocOj9Z WPSSAZM2xsOrvrjQjrsID53wY4D/93sDh09IFiVAd351EkSIJxCNVKPzKCyZtit7uQ0g vgUw== MIME-Version: 1.0 Received: by 10.152.136.18 with SMTP id pw18mr11504955lab.17.1343656216132; Mon, 30 Jul 2012 06:50:16 -0700 (PDT) Received: by 10.112.3.196 with HTTP; Mon, 30 Jul 2012 06:50:15 -0700 (PDT) In-Reply-To: References: Date: Mon, 30 Jul 2012 06:50:15 -0700 Message-ID: From: Cameron Byrne To: Mikael Abrahamsson Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops@ietf.org Subject: Re: [v6ops] Different DNS servers depending on dual stack or single stack usage X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 30 Jul 2012 13:50:18 -0000 On Mon, Jul 30, 2012 at 3:20 AM, Mikael Abrahamsson wrote: > > Hello. > > I would like to describe a problem that I do not have a solution to, thus > trying to solicit possible remedies to it so please fire if you have any > thoughts. > > Let's say we have a network where clients can connect, some will be dual > stack, some will be IPv6 only (3GPP for instance, also wifi). In case the > client is IPv6 only (single stack), I would like them to have access to > DNS64/NAT64 infrastructure. At the same time, I would like to avoid handing > out the DNS64 resolver address if the client is dual stacked (I believe that > is considered harmful?). > Why is DNS64 to DS NAT44 hosts harmful? IMHO, NAT44 and NAT64 equivalent levels of service (NOTE: In my experience, NAT44 ALGs are more complete than NAT64 ALGs .... that is implementation level issues). > How could this be achieved? One way would be to extend the DHCP standard to > hand out multiple DNS servers and have them tagged for different use, so the > client would need to decide if it's single or dual stack, and choose DNS > resolver accordingly. > You want one DHCP solution for multiple access types? Seems like the solutions should be address assignments for the specific access types, but i am likely missing something. CB > Thoughts? > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nick@inex.ie Mon Jul 30 07:35: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 0F4D321F87FC for ; Mon, 30 Jul 2012 07:35:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.654 X-Spam-Level: X-Spam-Status: No, score=-1.654 tagged_above=-999 required=5 tests=[AWL=-0.946, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, MISSING_HEADERS=1.292, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGeawPEOdDCb for ; Mon, 30 Jul 2012 07:35:57 -0700 (PDT) Received: from mail.acquirer.com (mail.acquirer.com [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 54EE321F87FA for ; Mon, 30 Jul 2012 07:35:56 -0700 (PDT) X-Envelope-To: Received: from crumpet.internal.acquirer.com ([IPv6:2001:1bb8:2004:100:a83e:401e:51da:d4a0]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id q6UEYjDk007462 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 30 Jul 2012 15:34:45 +0100 (IST) (envelope-from nick@inex.ie) Message-ID: <50169BC8.4040500@inex.ie> Date: Mon, 30 Jul 2012 15:35:52 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 CC: IPv6 Operations References: <201207301245.q6UCj1F06725@ftpeng-update.cisco.com> In-Reply-To: <201207301245.q6UCj1F06725@ftpeng-update.cisco.com> X-Enigmail-Version: 1.4.3 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] new draft: draft-smith-v6ops-larger-ipv6-loopback-prefix X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 30 Jul 2012 14:35:58 -0000 On 30/07/2012 13:45, fred@cisco.com wrote: > A new draft has been posted, at > http://tools.ietf.org/html/draft-smith-v6ops-larger-ipv6-loopback-prefix. > Please take a look at it and comment. Overall I like this idea, but I don't think that sufficient justification has been provided in the draft. - Regarding the justification in section 2, #2.1 could in theory be provided by private address space, but I see value here in terms of keeping host-local traffic local. I think the text could be tightened to say something like "we need a range of loopback addresses for host-local requirements" where it can be guaranteed by design that packets destined for a particular range of addresses will not leave the machine (whether real or virtual). - Section 2.2 should be removed - there is nothing ipv4 related about the use of 127.127/16 in ntpd. - you should consider whether RFC4379 should be mentioned in the justification section and maybe talk to the MPLS people about this draft to see if they're interested - I'm not sure section 2.3 provides a reasonably justification for a range of loopbacks either. In fact, I don't really understand what you're trying to explain here. - Is there some reason that 0::/64 wouldn't suffice for this instead of 1::/48? The reason for this is that it would automatically encompass the existing loopback address which means that v6 hosts would only have to increase the subnet mask from /128 to /64 in order to be compliant with this draft. Stylistically, the draft would be improved by cutting out about 70% of the text. There is implicit virtue in brevity and conciseness. Could I suggest the following changes? - amalgamate sections 3 and 4 into a single section section no more than a couple of sentences long. - remove the ubiquitous references to 1::/48 and refer to the actual value only in 2-3 instances at most. - amalgamate section 5 into two short paragraphs - security considerations: tl;dr. Could this be made shorter? Nick From pkern@spike.0x539.de Mon Jul 30 08: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 A375821F8820 for ; Mon, 30 Jul 2012 08:04:44 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sn+lGXhXc+0S for ; Mon, 30 Jul 2012 08:04:44 -0700 (PDT) Received: from hub.kern.lc (hub.kern.lc [IPv6:2a00:1158:3::c7]) by ietfa.amsl.com (Postfix) with ESMTP id 0946021F8824 for ; Mon, 30 Jul 2012 08:04:43 -0700 (PDT) Received: from [2001:470:720c:0:1568:8e4d:8401:833d] (helo=spike.0x539.de) by hub.kern.lc with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1SvrWG-0008UI-Ul; Mon, 30 Jul 2012 17:04:29 +0200 Received: from pkern by spike.0x539.de with local (Exim 4.80) (envelope-from ) id 1SvrWR-0000K8-Sl; Mon, 30 Jul 2012 17:04:39 +0200 Date: Mon, 30 Jul 2012 17:04:39 +0200 From: Philipp Kern To: Nick Hilliard Message-ID: <20120730150439.GA1085@spike.0x539.de> References: <201207301245.q6UCj1F06725@ftpeng-update.cisco.com> <50169BC8.4040500@inex.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50169BC8.4040500@inex.ie> Organization: 0x539 dev group User-Agent: Mutt/1.5.21 (2010-09-15) Cc: IPv6 Operations Subject: Re: [v6ops] new draft: draft-smith-v6ops-larger-ipv6-loopback-prefix X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 30 Jul 2012 15:04:44 -0000 On Mon, Jul 30, 2012 at 03:35:52PM +0100, Nick Hilliard wrote: > - Is there some reason that 0::/64 wouldn't suffice for this instead of > 1::/48? The reason for this is that it would automatically encompass the > existing loopback address which means that v6 hosts would only have to > increase the subnet mask from /128 to /64 in order to be compliant with > this draft. Overlap with IPv6-compatible addressing[1] I presume. Kind regards Philipp Kern [1] http://technet.microsoft.com/en-us/library/cc727992%28v=ws.10%29.aspx From phdgang@gmail.com Mon Jul 30 10:03: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 984BC21F8615 for ; Mon, 30 Jul 2012 10:03:13 -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.522, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rzMa1pjPN9s4 for ; Mon, 30 Jul 2012 10:03:13 -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 F3A1621F8577 for ; Mon, 30 Jul 2012 10:03:12 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so5152078vcb.31 for ; Mon, 30 Jul 2012 10:03: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=8F7EbOtQY7V7UP43A+arjtr6BP/urwiB2/0ePHGkr9Y=; b=lqdRvSvuFGqZ1BUgBt17B6j8KWWpVjcaPm1PQVEsoY8QRh2tRxiCYpQW6TtjFtpD9b rjYfxLYJ1heLfsw+GndS8vuSazs4GxomPuGRHkkJG0kefKAzgCOD1v01an+oZBegyDNa tYvQXpY3wkOxg8jQRmYuhPrwpX3e9lclCYODNiIeObZADrSr40dMwQNc7OpDXIqDXvLQ wqfCp3jS6wEe4fPyJoHwmjtmV0nZtV860a0zk9Cdax2X+Wqy9K/Wew/eNzTfh8j4Ja8U KTlc/O2CJydyj42GLeISJGJDleR6eOjGVS+XSnWLrzTGGvtIvH1JZqSqBxCQwIFNlc7B hoow== MIME-Version: 1.0 Received: by 10.220.141.202 with SMTP id n10mr11660837vcu.49.1343667792380; Mon, 30 Jul 2012 10:03:12 -0700 (PDT) Received: by 10.58.91.179 with HTTP; Mon, 30 Jul 2012 10:03:12 -0700 (PDT) In-Reply-To: <20120730165520.16697.19648.idtracker@ietfa.amsl.com> References: <20120730165520.16697.19648.idtracker@ietfa.amsl.com> Date: Tue, 31 Jul 2012 01:03:12 +0800 Message-ID: From: GangChen To: v6ops Content-Type: text/plain; charset=ISO-8859-1 Subject: [v6ops] Fwd: I-D Action: draft-chen-v6ops-nat64-experience-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: Mon, 30 Jul 2012 17:03:13 -0000 Hello all, Considering the discussion on the previous version, we have updated the draft of NAT64-experiences. Thankful for Joel's editing proposal which significantly improved the legibility of the document. Compared to provious, main changes are: 1) Made editing improvements through the draft 2) Consolidated the statement on the standpoint of NAT64-CE 3) Identified issues in NAT64-CE context accordingly Your comments are appreciated Many thanks Authors ---------- Forwarded message ---------- From: internet-drafts@ietf.org Date: Mon, 30 Jul 2012 09:55:20 -0700 Subject: I-D Action: draft-chen-v6ops-nat64-experience-03.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : NAT64 Operational Experiences Author(s) : Gang Chen Zhen Cao Cameron Byrne Chongfeng Xie David Binet Filename : draft-chen-v6ops-nat64-experience-03.txt Pages : 16 Date : 2012-07-30 Abstract: This document summarizes stateful NAT64 deployment scenarios and operational experience with NAT64-CGN(NAT64 Carrier Grade NATs) and NAT64-CE (NAT64 Customer Edge). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-chen-v6ops-nat64-experience There's also a htmlized version available at: http://tools.ietf.org/html/draft-chen-v6ops-nat64-experience-03 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=draft-chen-v6ops-nat64-experience-03 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 dr@cluenet.de Mon Jul 30 14:18: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 2C7D121F85D2 for ; Mon, 30 Jul 2012 14:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VtET1+b9Vofq for ; Mon, 30 Jul 2012 14:18:21 -0700 (PDT) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by ietfa.amsl.com (Postfix) with ESMTP id 7389011E809C for ; Mon, 30 Jul 2012 14:18:20 -0700 (PDT) Received: by mail1.cluenet.de (Postfix, from userid 500) id 952AB10876D; Mon, 30 Jul 2012 23:18:19 +0200 (CEST) Date: Mon, 30 Jul 2012 23:18:19 +0200 From: Daniel Roesen To: v6ops@ietf.org Message-ID: <20120730211819.GA1177@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org References: 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] Different DNS servers depending on dual stack or single stack usage X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 30 Jul 2012 21:18:22 -0000 Hi, On Mon, Jul 30, 2012 at 12:20:28PM +0200, Mikael Abrahamsson wrote: > Let's say we have a network where clients can connect, some will be dual > stack, some will be IPv6 only (3GPP for instance, also wifi). In case the > client is IPv6 only (single stack), I would like them to have access to > DNS64/NAT64 infrastructure. At the same time, I would like to avoid handing > out the DNS64 resolver address if the client is dual stacked (I believe > that is considered harmful?). Yep, that's a problem I was thinking about multiple times, too. > How could this be achieved? One way would be to extend the DHCP standard to > hand out multiple DNS servers and have them tagged for different use, so > the client would need to decide if it's single or dual stack, and choose > DNS resolver accordingly. I was considering using an EDNS0 option to request DNS64 service, kinda "DNS64 desired" similar to "recursion desired". Single-stack IPv6 clients would set this flag. See #networker logs from 2012-01-17 for some discussion. :) Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From dr@cluenet.de Mon Jul 30 14:27: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 469AF21F8602 for ; Mon, 30 Jul 2012 14:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mCwFoZ9v2vqT for ; Mon, 30 Jul 2012 14:27:00 -0700 (PDT) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by ietfa.amsl.com (Postfix) with ESMTP id A92F321F85F9 for ; Mon, 30 Jul 2012 14:27:00 -0700 (PDT) Received: by mail1.cluenet.de (Postfix, from userid 500) id E93FF108745; Mon, 30 Jul 2012 23:26:59 +0200 (CEST) Date: Mon, 30 Jul 2012 23:26:59 +0200 From: Daniel Roesen To: v6ops@ietf.org Message-ID: <20120730212659.GB1177@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org References: 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] Different DNS servers depending on dual stack or single stack usage X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 30 Jul 2012 21:27:01 -0000 On Mon, Jul 30, 2012 at 06:50:15AM -0700, Cameron Byrne wrote: > Why is DNS64 to DS NAT44 hosts harmful? IMHO, NAT44 and NAT64 > equivalent levels of service (NOTE: In my experience, NAT44 ALGs are > more complete than NAT64 ALGs .... that is implementation level > issues). When providing centralized NAT64 service, I really don't want to see traffic from dualstacked services to go through NAT64 towards dualstacked endpoints which happen to support DNS resolving via IPv6 transport, really. It should use its very own IPv4 connectivity to reach such a service, no matter wether it gets implemented via CPE-based NAT44, NAT444 or DS-Lite. Don't inject more AFI trickery than absolutely required as long as IPv4 is still delivered to the endpoint. IMHO, YMMV. :) > You want one DHCP solution for multiple access types? > > Seems like the solutions should be address assignments for the > specific access types, but i am likely missing something. How do you detect an IPv6-only endpoint from the DHCP server and/or DNS recursor perspective? Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From jared@puck.nether.net Mon Jul 30 14:39: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 089E511E817F for ; Mon, 30 Jul 2012 14:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GlFGjvufjYzd for ; Mon, 30 Jul 2012 14:39:28 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 6533A11E816F for ; Mon, 30 Jul 2012 14:39:28 -0700 (PDT) Received: from [10.0.0.137] (173-167-0-106-michigan.hfc.comcastbusiness.net [173.167.0.106]) (authenticated bits=0) by puck.nether.net (8.14.4/8.14.4) with ESMTP id q6ULdL4h001458 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 30 Jul 2012 17:39:21 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Jared Mauch In-Reply-To: Date: Mon, 30 Jul 2012 17:39:21 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Cameron Byrne X-Mailer: Apple Mail (2.1278) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Mon, 30 Jul 2012 17:39:22 -0400 (EDT) Cc: v6ops@ietf.org Subject: Re: [v6ops] Different DNS servers depending on dual stack or single stack usage X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 30 Jul 2012 21:39:29 -0000 On Jul 30, 2012, at 9:50 AM, Cameron Byrne wrote: >> How could this be achieved? One way would be to extend the DHCP = standard to >> hand out multiple DNS servers and have them tagged for different use, = so the >> client would need to decide if it's single or dual stack, and choose = DNS >> resolver accordingly. >>=20 >=20 > You want one DHCP solution for multiple access types? >=20 > Seems like the solutions should be address assignments for the > specific access types, but i am likely missing something. Sounds like you want to modify the host stack (or application layer) to = have per-af resolvers and capabilities. since you are stuck with = gethostbyname2() and similar, you need to push this elsewhere. I'm not = sure the best way to address this as it requires a more comprehensive = rewrite of so many parts of the system. What is the overall ROI you see for this work? Is this just a system to = provide polarization for or against v4("Classic IP")? - Jared= From swmike@swm.pp.se Mon Jul 30 21:05: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 155B811E810B for ; Mon, 30 Jul 2012 21:05:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rlaqOcZpdyMG for ; Mon, 30 Jul 2012 21:05:33 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 3097B11E809A for ; Mon, 30 Jul 2012 21:05:33 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 17D319C; Tue, 31 Jul 2012 06:05:31 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 0EFBF9A; Tue, 31 Jul 2012 06:05:31 +0200 (CEST) Date: Tue, 31 Jul 2012 06:05:31 +0200 (CEST) From: Mikael Abrahamsson To: Cameron Byrne 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: v6ops@ietf.org Subject: Re: [v6ops] Different DNS servers depending on dual stack or single stack usage X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 31 Jul 2012 04:05:34 -0000 On Mon, 30 Jul 2012, Cameron Byrne wrote: > Why is DNS64 to DS NAT44 hosts harmful? IMHO, NAT44 and NAT64 equivalent > levels of service (NOTE: In my experience, NAT44 ALGs are more complete > than NAT64 ALGs .... that is implementation level issues). I seem to remember seeing text that this was harmful, but I might be mistaken. > You want one DHCP solution for multiple access types? Well, that is not my primary goal. > Seems like the solutions should be address assignments for the > specific access types, but i am likely missing something. Well, for instance for the 3GPP scenario I have no idea if the client is going to request a v6 only PDP context, a v4v6 PDP context, or two different (v4/v6) PDP contexts, at the time I need to hand out DNS servers. I also do not know if the client is going v6 only by means of taking down it's v4 PDP context along the way. -- Mikael Abrahamsson email: swmike@swm.pp.se From swmike@swm.pp.se Mon Jul 30 21:09: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 838AA11E80EA for ; Mon, 30 Jul 2012 21:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j3io4gdisNTt for ; Mon, 30 Jul 2012 21:09:06 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id DCE9311E80C5 for ; Mon, 30 Jul 2012 21:09:05 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 326DA9C; Tue, 31 Jul 2012 06:09:05 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 2B6359A; Tue, 31 Jul 2012 06:09:05 +0200 (CEST) Date: Tue, 31 Jul 2012 06:09:05 +0200 (CEST) From: Mikael Abrahamsson To: Jared Mauch 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: v6ops@ietf.org Subject: Re: [v6ops] Different DNS servers depending on dual stack or single stack usage X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 31 Jul 2012 04:09:06 -0000 On Mon, 30 Jul 2012, Jared Mauch wrote: > Sounds like you want to modify the host stack (or application layer) to > have per-af resolvers and capabilities. since you are stuck with > gethostbyname2() and similar, you need to push this elsewhere. I'm not > sure the best way to address this as it requires a more comprehensive > rewrite of so many parts of the system. Nope, I do not think that is what is being proposed. > What is the overall ROI you see for this work? Is this just a system to > provide polarization for or against v4("Classic IP")? For me it would mean I could provide v6 only clients with NAT64 connectivity on all access technologies for the forseeable future. Another way might be that v6 only clients who desire NAT64 connectivity actually asked different questions than a dual stack client so that the resolver knew if it should give DNS64 answers or not. Perhaps that is a saner way to go? I also do not understand your last sentence, could you please rephrase/elaborate? -- Mikael Abrahamsson email: swmike@swm.pp.se From jared@puck.nether.net Tue Jul 31 02: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 CBF1921F8534 for ; Tue, 31 Jul 2012 02:25:08 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9K6LU0txyfgm for ; Tue, 31 Jul 2012 02:25:08 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 5F6B021F8533 for ; Tue, 31 Jul 2012 02:25:08 -0700 (PDT) Received: from [10.0.0.163] (173-167-0-106-michigan.hfc.comcastbusiness.net [173.167.0.106]) (authenticated bits=0) by puck.nether.net (8.14.4/8.14.4) with ESMTP id q6V9P17g020472 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 31 Jul 2012 05:25:02 -0400 References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=us-ascii Message-Id: <481D3F0B-E926-4AA7-BDF0-30CE4919AF69@puck.nether.net> Content-Transfer-Encoding: quoted-printable X-Mailer: iPhone Mail (9B206) From: Jared Mauch Date: Tue, 31 Jul 2012 05:25:01 -0400 To: Mikael Abrahamsson X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Tue, 31 Jul 2012 05:25:02 -0400 (EDT) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Different DNS servers depending on dual stack or single stack usage X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 31 Jul 2012 09:25:08 -0000 On Jul 31, 2012, at 12:09 AM, Mikael Abrahamsson wrote: >=20 > I also do not understand your last sentence, could you please rephrase/ela= borate? I think I am concerned about feature creep with the idea of providing a pref= erence. I do think this will be challenging without significant changes in t= he host applications or stack.=20 Jared= From swmike@swm.pp.se Tue Jul 31 03:35: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 5297921F869E for ; Tue, 31 Jul 2012 03:35:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ul7eqgssgqmG for ; Tue, 31 Jul 2012 03:35:34 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 8049B21F86A4 for ; Tue, 31 Jul 2012 03:35:34 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 9AA249E; Tue, 31 Jul 2012 12:35:32 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 93C689C; Tue, 31 Jul 2012 12:35:32 +0200 (CEST) Date: Tue, 31 Jul 2012 12:35:32 +0200 (CEST) From: Mikael Abrahamsson To: Jared Mauch In-Reply-To: <481D3F0B-E926-4AA7-BDF0-30CE4919AF69@puck.nether.net> Message-ID: References: <481D3F0B-E926-4AA7-BDF0-30CE4919AF69@puck.nether.net> 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" Subject: Re: [v6ops] Different DNS servers depending on dual stack or single stack usage X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 31 Jul 2012 10:35:35 -0000 On Tue, 31 Jul 2012, Jared Mauch wrote: > I think I am concerned about feature creep with the idea of providing a > preference. I do think this will be challenging without significant > changes in the host applications or stack. Ok. So how do we adress the problem? Going a completely different route and go for the "discover NAT64 prefix"-heuritics and ask clients to implement that instead, if they're single stacked on v6? -- Mikael Abrahamsson email: swmike@swm.pp.se From swmike@swm.pp.se Tue Jul 31 03:36: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 A6CF521F86AD for ; Tue, 31 Jul 2012 03:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PjdHwCSQLDAp for ; Tue, 31 Jul 2012 03:36:48 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 1AF6421F86A4 for ; Tue, 31 Jul 2012 03:36:48 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 6AF959C; Tue, 31 Jul 2012 12:36:47 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 640589A; Tue, 31 Jul 2012 12:36:47 +0200 (CEST) Date: Tue, 31 Jul 2012 12:36:47 +0200 (CEST) From: Mikael Abrahamsson To: Cameron Byrne 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: v6ops@ietf.org Subject: Re: [v6ops] Different DNS servers depending on dual stack or single stack usage X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 31 Jul 2012 10:36:48 -0000 On Mon, 30 Jul 2012, Cameron Byrne wrote: > Why is DNS64 to DS NAT44 hosts harmful? IMHO, NAT44 and NAT64 equivalent > levels of service (NOTE: In my experience, NAT44 ALGs are more complete > than NAT64 ALGs .... that is implementation level issues). Well, in my example the client has un-NATed v4 and v6 service, but might sometimes not have v4 connectivity at all. So this is not a DNS64 vs DS NAT44 problem, it's a DNS64 vs DS non-NAT44 problem. I agree that if the client is behind NAT44, then this is less an issue. -- Mikael Abrahamsson email: swmike@swm.pp.se From cb.list6@gmail.com Tue Jul 31 07:18: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 78AB921F86EA for ; Tue, 31 Jul 2012 07:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.439 X-Spam-Level: X-Spam-Status: No, score=-3.439 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CsTJrviAE7dM for ; Tue, 31 Jul 2012 07:18:30 -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 4707721F86E8 for ; Tue, 31 Jul 2012 07:18:30 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so4358142lbb.31 for ; Tue, 31 Jul 2012 07:18: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=CZLWMVCpIwKXM6v/iOdp1Nzv2hnxK/LZFXFJ8FBKSGQ=; b=mGvpj8HBgMPKTiW8ladFj044ZXmQMJKHENFNpNoTl96bTv83Kuhi0IhXarKQIeP5n5 oqEjC4SN7nEJo9zTXBH2daa79/KR+JfAAh/gLoeHn7rIp4ap3a05A0uWTAbP620tBC9w RnpMvuUlGZ4coKcj3AKUUxAMm8JxSOMQB5txJQOzjQ7EfzF3ArM9zh3ysg6wIHozq2dt Ovy019aBd6W789hYfZrBAjzcJkU1uFPhVZWfpp/sCl/ag0lAgXVfaX9wDMNc6EygH2DJ 2Mwc9d6opRmSswyJsuoP7gqJr7gYbK5OQS5qsQOksI0gF85VM2oMxmS+ZrBGaQngKm7B WyZQ== MIME-Version: 1.0 Received: by 10.112.82.42 with SMTP id f10mr6791153lby.95.1343744309141; Tue, 31 Jul 2012 07:18:29 -0700 (PDT) Received: by 10.112.3.196 with HTTP; Tue, 31 Jul 2012 07:18:28 -0700 (PDT) Received: by 10.112.3.196 with HTTP; Tue, 31 Jul 2012 07:18:28 -0700 (PDT) In-Reply-To: References: Date: Tue, 31 Jul 2012 07:18:28 -0700 Message-ID: From: Cameron Byrne To: Mikael Abrahamsson Content-Type: multipart/alternative; boundary=f46d04016a97371f9604c620da2e Cc: v6ops@ietf.org Subject: Re: [v6ops] Different DNS servers depending on dual stack or single stack usage X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 31 Jul 2012 14:18:31 -0000 --f46d04016a97371f9604c620da2e Content-Type: text/plain; charset=ISO-8859-1 On Jul 31, 2012 3:36 AM, "Mikael Abrahamsson" wrote: > > On Mon, 30 Jul 2012, Cameron Byrne wrote: > >> Why is DNS64 to DS NAT44 hosts harmful? IMHO, NAT44 and NAT64 equivalent levels of service (NOTE: In my experience, NAT44 ALGs are more complete than NAT64 ALGs .... that is implementation level issues). > > > Well, in my example the client has un-NATed v4 and v6 service, but might sometimes not have v4 connectivity at all. So this is not a DNS64 vs DS NAT44 problem, it's a DNS64 vs DS non-NAT44 problem. I agree that if the client is behind NAT44, then this is less an issue. > > To clarify scope, there is a workable solution: seperate dhcp servers / config / VMs per access type. The open question is for having one monolithic dhcp config for multiple access types with different host configuration requirements. So the ons monolithic server must make an intelligent decision ( select dns server) bases on access type / relay agent (if from this relay access network do x, else do y) CB > -- > Mikael Abrahamsson email: swmike@swm.pp.se --f46d04016a97371f9604c620da2e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Jul 31, 2012 3:36 AM, "Mikael Abrahamsson" <swmike@swm.pp.se> wrote:
>
> On Mon, 30 Jul 2012, Cameron Byrne wrote:
>
>> Why is DNS64 to DS NAT44 hosts harmful? IMHO, NAT44 and NAT64 equi= valent levels of service (NOTE: =A0In my experience, NAT44 ALGs are more co= mplete than NAT64 ALGs .... that is implementation level issues).
>
>
> Well, in my example the client has un-NATed v4 and v6 service, but mig= ht sometimes not have v4 connectivity at all. So this is not a DNS64 vs DS = NAT44 problem, it's a DNS64 vs DS non-NAT44 problem. I agree that if th= e client is behind NAT44, then this is less an issue.
>
>

To clarify scope, there is a workable solution: seperate dhcp servers / = config / VMs=A0 per access type.

The open question is for having one monolithic dhcp config for multiple = access types with different host configuration requirements.

So the ons monolithic server must make an intelligent decision ( select = dns server) bases on access type / relay agent (if from this relay access n= etwork do x, else do y)

CB

> --
> Mikael Abrahamsson =A0 =A0email: s= wmike@swm.pp.se

--f46d04016a97371f9604c620da2e-- From naveen.ipv6@gmail.com Tue Jul 31 09:47: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 C827C21F86D6 for ; Tue, 31 Jul 2012 09:47:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.74 X-Spam-Level: X-Spam-Status: No, score=-1.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5gRVE9q2RRuO for ; Tue, 31 Jul 2012 09:47:43 -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 60E6421F867E for ; Tue, 31 Jul 2012 09:47:43 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so12389879obb.31 for ; Tue, 31 Jul 2012 09:47:43 -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=9MmVtJy9XScPxyr5RFFVc4gwlre7SfeNSMs9B/n+7Tw=; b=Vb6LGFCf1iYb1oYSSECIvlhRVPmzvcrtgnJ1mRdpVDWyHr5mWnx9sbMQm/1CIQbSrr gA33dIEsIvCb3izmOHdg4UvpxjKiKXAd+SnXO+95wpyJf3VO++KP7ZFnf0JQftEcMPn9 W1eCk3ebASeGONljDM6GNuBDJOISQ+sj4sAoovPi3HpOqTW/LdjBocUV6u6IP3loZE2u hsrD/gZdJbLIEUPfdPMseJAKhRKFctnp8+QMtv3WJb005v/T8YtDuFJu6m6DTQ6lfRXl LW4APtn/DYcRN9BQHespgKMmFTKBo0agobyyhvFrtd7xtR+c3bviNCaRfjqqEtKMiM13 dzOA== MIME-Version: 1.0 Received: by 10.182.14.101 with SMTP id o5mr24719988obc.1.1343753262986; Tue, 31 Jul 2012 09:47:42 -0700 (PDT) Received: by 10.76.116.67 with HTTP; Tue, 31 Jul 2012 09:47:42 -0700 (PDT) Date: Tue, 31 Jul 2012 22:17:42 +0530 Message-ID: From: Naveen Lakshman To: v6ops v6ops WG Content-Type: text/plain; charset=ISO-8859-1 Subject: [v6ops] Webex Link for Remote Participation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 31 Jul 2012 16:47:43 -0000 Hi, Is there any Webex link for remote participation. -- n@v::n/128 (Naveen) From fred@cisco.com Tue Jul 31 09:52: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 97E6F21F870A for ; Tue, 31 Jul 2012 09:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.51 X-Spam-Level: X-Spam-Status: No, score=-110.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d-cDlXWqjJ7y for ; Tue, 31 Jul 2012 09:52:27 -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 C145221F8707 for ; Tue, 31 Jul 2012 09:52:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=218; q=dns/txt; s=iport; t=1343753541; x=1344963141; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=X3O9UMLBSlcpyBRK2sujuY2zxgPFkd8ggV5VttGfpyo=; b=mjWAtjBKhq5jXla16eFYkXfnAi0fTvZAGwkroAuV5d0wyGxiED1BihZl oaP9fzCl7/pucxt3Cj3wdwwjfZMFXQ335ByBHFeYoygB/3XlzmUwKzEq6 pzqL0HB8yOgj48WSBz8aPfaKUJ3t8a5xqShgeEvxNDfRUjhmJNd1DLEL+ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFAOQMGFCtJV2Z/2dsb2JhbABFhTG0SIEHgiABAQEDARIBJz8FCwIBCDYQMiUCBA4nh2UGC5wQoHEEi0mGKWADlUeOJ4Fmgl8 X-IronPort-AV: E=Sophos;i="4.77,688,1336348800"; d="scan'208";a="107079857" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 31 Jul 2012 16:52:08 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q6VGq84X009981 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 31 Jul 2012 16:52:08 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.7]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0298.004; Tue, 31 Jul 2012 11:52:07 -0500 From: "Fred Baker (fred)" To: Naveen Lakshman Thread-Topic: [v6ops] Webex Link for Remote Participation Thread-Index: AQHNbzzRTzqhcS2FjkqRS7cuWCevrg== Date: Tue, 31 Jul 2012 16:52:06 +0000 Message-ID: <5CA57939-04F1-43F8-B267-63527F9BDE18@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.124.109] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19074.004 x-tm-as-result: No--28.795200-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 Cc: v6ops v6ops WG Subject: Re: [v6ops] Webex Link for Remote Participation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 31 Jul 2012 16:52:27 -0000 On Jul 31, 2012, at 9:47 AM, Naveen Lakshman wrote: > Hi, >=20 > Is there any Webex link for remote participation. https://www.ietf.org/meeting/84/remote-participation.html > --=20 > n@v::n/128 (Naveen) From joelja@bogus.com Tue Jul 31 09:53: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 06DEB21F871C for ; Tue, 31 Jul 2012 09:53:57 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4YzBq8F1KqVj for ; Tue, 31 Jul 2012 09:53:56 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 584C221F8717 for ; Tue, 31 Jul 2012 09:53:56 -0700 (PDT) Received: from dhcp-6624.meeting.ietf.org (dhcp-6624.meeting.ietf.org [130.129.102.36]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q6VGrnfd029403 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 31 Jul 2012 16:53:49 GMT (envelope-from joelja@bogus.com) Message-ID: <50180D9F.8000007@bogus.com> Date: Tue, 31 Jul 2012 09:53:51 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120717 Thunderbird/15.0 MIME-Version: 1.0 To: Naveen Lakshman 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]); Tue, 31 Jul 2012 16:53:49 +0000 (UTC) Cc: v6ops v6ops WG Subject: Re: [v6ops] Webex Link for Remote Participation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 31 Jul 2012 16:53:57 -0000 On 7/31/12 9:47 AM, Naveen Lakshman wrote: > Hi, > > Is there any Webex link for remote participation. The IESG discontinued the bi-directional audio experiment for IETF meetings. Webex audio conferencing is used for virtual-interims. Streaming audio is available for both v6ops sessions and xmpp/jabber is used as a side/back-channel. Links to both are provided from the ietf tools agenda. http://tools.ietf.org From fred@cisco.com Tue Jul 31 10:45: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 E99E321F8665 for ; Tue, 31 Jul 2012 10:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.218 X-Spam-Level: X-Spam-Status: No, score=-110.218 tagged_above=-999 required=5 tests=[AWL=0.381, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lUGWqVlipEZ2 for ; Tue, 31 Jul 2012 10:45:04 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 384DC21F861B for ; Tue, 31 Jul 2012 10:45:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1342; q=dns/txt; s=iport; t=1343756704; x=1344966304; h=from:to:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=cfSxflN/icUJkN3j3rxbeDGN8zWtqjauEY1oNgh7/Gk=; b=fywsKgKsRnyP9IPQaj6JtCoc7XnkfkPlTXFwb3rghH28eCWXXNCli6vm hFy/saVh1NIyN1AojfjjlY9kPfdrp6KoTdVO8hSGnUqfCI6TS+hnXYBWX ZPZd4f2u/h2Cj6SceDlRbzok6akoXQM2izilxZfHiK3HwNG3VturibnWR o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJkYGFCtJXHB/2dsb2JhbABFuXmBB4IgAQEBAwESAQodRAsCARkDAQIfECERGwIIAgQTFA6HXAMGBgucCJcXDYlKBIpiZxuGDmADk3SBU4sKgx2BZoJf X-IronPort-AV: E=Sophos;i="4.77,688,1336348800"; d="scan'208";a="106888934" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-1.cisco.com with ESMTP; 31 Jul 2012 17:45:03 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q6VHj3A1013434 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 31 Jul 2012 17:45:03 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.7]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0298.004; Tue, 31 Jul 2012 12:45:03 -0500 From: "Fred Baker (fred)" To: v6ops v6ops WG Thread-Topic: Need volunteers for the NomCom Thread-Index: AQHNbnHMWqNTD2JprkyX7ESXEz8XKQ== Date: Tue, 31 Jul 2012 17:45:02 +0000 Message-ID: <37856F52-58BF-4896-B6FB-CEAB07BE137D@cisco.com> References: <20120730032233.17770.35790.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.65.101] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19074.005 x-tm-as-result: No--29.968600-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] Fwd: Need volunteers for the NomCom X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 31 Jul 2012 17:45:05 -0000 This is a request from the powers that be... please be a power that be... > From: NomCom Chair > Date: July 29, 2012 8:22:33 PM PDT > To: Working Group Chairs > Subject: Need volunteers for the NomCom >=20 > We are currently looking for volunteers to serve on the 2012-2013 NomCom. > As you know, the success of the NomCom process depends crucially on=20 > having a large pool of volunteers from throughout the IETF community.=20 > In particular, it is valuable for the pool of volunteers to have strong=20 > representation from all of the technical areas within the IETF.=20 >=20 > I understand that not all IETF participants read the IETF announce list=20 > frequently. Therefore, if you would be willing to inform active participa= nts=20 > in your working groups about this year's call for NomCom volunteers, I=20 > would greatly appreciate it.=20 >=20 > The NomCom 2012-2013 Call for Volunteers is open until this Sunday,=20 > August 5. Details can be found at: https://datatracker.ietf.org/ann/nomco= m/49851/ >=20 > Thank you for your help, > - Matt Lepinski > mlepinski.ietf@gmail.com > nomcom-chair@ietf.org ---------------------------------------------------- The ignorance of how to use new knowledge stockpiles exponentially.=20 - Marshall McLuhan From jouni.nospam@gmail.com Tue Jul 31 16:46: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 1BF4021F8982 for ; Tue, 31 Jul 2012 16:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.396 X-Spam-Level: X-Spam-Status: No, score=-3.396 tagged_above=-999 required=5 tests=[AWL=-0.397, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cOzP75YwO3M2 for ; Tue, 31 Jul 2012 16:46:02 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8AE7321F8981 for ; Tue, 31 Jul 2012 16:46:02 -0700 (PDT) Received: by yenq13 with SMTP id q13so7244796yen.31 for ; Tue, 31 Jul 2012 16:46:02 -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=2e7mcjxxUvxoe9Sk6NCDDewHSybRAOq7DhsSgqOf16I=; b=lJK6KzPms1E9EHNcSFXSft09Ddcs9HjsrX6su4SRj6UapEXEFw/FrN965eSOgEat4P Ca9UWw0p2jBzwNQDtzsCiPyZXiOtk9eBW/QEJAd0ACMBOop3WYdOc1cNbK4oHLjF1lDd uhy1etyUvmhCwtcw1D2V5MjuGfz5X1cSLay2BDUrc2FRw4qBXQVBjlg9zTAwIN0ZSLg+ 1/KvbAEnxRt5cUbrLXIAvGRHoNc+nJTBbVMG4dPtt9PsnS7zShY77aemlecQLqzPqVYq Y878r9ygfh25XBu55wYe+aYUOfV5/Npvx9g1qCJ52iBxXQ6PqDhBT5RX7sFN/HbC4jt4 rJug== Received: by 10.66.88.202 with SMTP id bi10mr2338137pab.10.1343778361734; Tue, 31 Jul 2012 16:46:01 -0700 (PDT) Received: from ?IPv6:2001:df8::16:226:bbff:fe18:6e9c? ([2001:df8:0:16:226:bbff:fe18:6e9c]) by mx.google.com with ESMTPS id wi6sm1224684pbc.35.2012.07.31.16.45.57 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 31 Jul 2012 16:45:58 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Wed, 1 Aug 2012 02:45:55 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org Subject: Re: [v6ops] Different DNS servers depending on dual stack or single stack usage X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 31 Jul 2012 23:46:03 -0000 Hi, On Jul 30, 2012, at 1:20 PM, Mikael Abrahamsson wrote: >=20 > Hello. >=20 > I would like to describe a problem that I do not have a solution to, = thus trying to solicit possible remedies to it so please fire if you = have any thoughts. >=20 > Let's say we have a network where clients can connect, some will be = dual stack, some will be IPv6 only (3GPP for instance, also wifi). In = case the client is IPv6 only (single stack), I would like them to have = access to DNS64/NAT64 infrastructure. For 3GPP networks this can be achieved using AAA to provision DNS = servers for your APN.. obviously you need some additional logic then in your AAA server to hand out different DNS servers depending on the PDP-Type that = got established. - Jouni > At the same time, I would like to avoid handing out the DNS64 = resolver address if the client is dual stacked (I believe that is = considered harmful?). >=20 > How could this be achieved? One way would be to extend the DHCP = standard to hand out multiple DNS servers and have them tagged for = different use, so the client would need to decide if it's single or dual = stack, and choose DNS resolver accordingly. >=20 > Thoughts? >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From gvandeve@cisco.com Tue Jul 31 17:45: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 2376C11E8072 for ; Tue, 31 Jul 2012 17:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.548 X-Spam-Level: X-Spam-Status: No, score=-10.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rudA0mJeLZOZ for ; Tue, 31 Jul 2012 17:45:28 -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 646BB21F8806 for ; Tue, 31 Jul 2012 17:45:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gvandeve@cisco.com; l=5499; q=dns/txt; s=iport; t=1343781928; x=1344991528; h=from:to:subject:date:message-id:mime-version; bh=hLL0+Ik22H8FwX71s5agROJakmQ7vc2HFyqDVKPQ1cg=; b=SyDzY1IOiJNEt6CE94g0xfX0s8YvuB4iP6rtDSoeHL6KzTJ+h0CtY0tm PLx3NsTWel0Jab/hHokoCRd7tfn4c6YEo4ESafByyEAGgkQkYK6RaaV7y xaFgFsp8b8nOdHdODllUioQk4oCCRqnMao36Dh7VROisKtnWx1ry+cVLF 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAMV7GFCtJXG//2dsb2JhbABFgkq3MYEHgiIBBBIBGj4gASpWJgEEGxqHa5pEgSigW5FyYAOjboFmgl8 X-IronPort-AV: E=Sophos;i="4.77,690,1336348800"; d="scan'208,217";a="107247208" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-3.cisco.com with ESMTP; 01 Aug 2012 00:45:28 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q710jR9I013002 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 1 Aug 2012 00:45:27 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.132]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0298.004; Tue, 31 Jul 2012 19:45:27 -0500 From: "Gunter Van de Velde (gvandeve)" To: "v6ops v6ops WG (v6ops@ietf.org)" Thread-Topic: Reminder: OPSEC IPv6 Slots Thread-Index: Ac1vffdCgM6s3G7kRnyfe+oX0RCR7g== Date: Wed, 1 Aug 2012 00:45:27 +0000 Message-ID: <67832B1175062E48926BF3CB27C49B24047A85@xmb-aln-x12.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.72.181] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19074.004 x-tm-as-result: No--33.175200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_67832B1175062E48926BF3CB27C49B24047A85xmbalnx12ciscocom_" MIME-Version: 1.0 Subject: [v6ops] Reminder: OPSEC IPv6 Slots X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 01 Aug 2012 00:45:29 -0000 --_000_67832B1175062E48926BF3CB27C49B24047A85xmbalnx12ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, Please kindly find this reminder. At OPSEC tomorrow there will be 7 IPv6 drafts discussed about. (all drafts are actually IPv6 only or are dual-stack oriented) Feel free to attend the OPSEC meeting to share your expertise in this area,= because your quality feedback is desired. Drafts: Host Scanning in IPv6 Networks draft-gont-opsec-ipv6-host-scanning-01 Security Implications of IPv6 on IPv4 Networks draft-gont-opsec-ipv6-implications-on-ipv4-nets-01 DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers draft-gont-opsec-dhcpv6-shield-00 Neighbor Discovery Shield (ND-Shield): Protecting against Neighbor Discover= y Attacks draft-gont-opsec-ipv6-nd-shield-00 Operational Security Considerations for IPv6 Networks draft-vyncke-opsec-v6-01 Using Only Link-Local Addressing Inside an IPv6 Network draft-behringer-lla-only-01 BGP Operations and Security draft-jdurand-bgp-security-01 G/ KK, Warren OPSEC Chairs --_000_67832B1175062E48926BF3CB27C49B24047A85xmbalnx12ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

Please kindly find this reminder.

 

At OPSEC tomorrow there will be 7 IPv6 drafts discus= sed about.

(all drafts are actually IPv6 only or are dual-stack= oriented)

 

Feel free to attend the OPSEC meeting to share your = expertise in this area, because

your quality feedback is desired.

 

Drafts:

 

Host Scanning in IPv6 Networks

draft-gont-opsec-ipv6-host-scanning-01

 

Security Implications of IPv6 on IPv4 Networks
draft-gont-opsec-ipv6-implications-on-ipv4-nets-01

 

DHCPv6-Shield: Protecting Against Rogue DHCPv6 Serve= rs

draft-gont-opsec-dhcpv6-shield-00

 

Neighbor Discovery Shield (ND-Shield): Protecting ag= ainst Neighbor Discovery Attacks

draft-gont-opsec-ipv6-nd-shield-00

 

Operational Security Considerations for IPv6 Network= s

draft-vyncke-opsec-v6-01

 

Using Only Link-Local Addressing Inside an IPv6 Netw= ork

draft-behringer-lla-only-01

 

BGP Operations and Security

draft-jdurand-bgp-security-01

 

G/

KK,

Warren

 

OPSEC Chairs

--_000_67832B1175062E48926BF3CB27C49B24047A85xmbalnx12ciscocom_-- From swmike@swm.pp.se Tue Jul 31 22:30: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 D787821F85CC for ; Tue, 31 Jul 2012 22:30:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sjch4uJsUQjQ for ; Tue, 31 Jul 2012 22:30:10 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id DE93D21F85CD for ; Tue, 31 Jul 2012 22:30:09 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 905299C; Wed, 1 Aug 2012 07:30:06 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 8A1E39A for ; Wed, 1 Aug 2012 07:30:06 +0200 (CEST) Date: Wed, 1 Aug 2012 07:30:06 +0200 (CEST) From: Mikael Abrahamsson To: v6ops@ietf.org 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 Subject: Re: [v6ops] Different DNS servers depending on dual stack or single stack usage X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 01 Aug 2012 05:30:11 -0000 On Wed, 1 Aug 2012, jouni korhonen wrote: >> Let's say we have a network where clients can connect, some will be >> dual stack, some will be IPv6 only (3GPP for instance, also wifi). In >> case the client is IPv6 only (single stack), I would like them to have >> access to DNS64/NAT64 infrastructure. > > For 3GPP networks this can be achieved using AAA to provision DNS servers > for your APN.. obviously you need some additional logic then in your AAA > server to hand out different DNS servers depending on the PDP-Type that got > established. I don't believe this solves my problem. If I hand out DNS64 for everybody who connects using IPv6, I might cause problems to clients who establish a second PDP context, this time IPv4 only (dual bearer). I read the 464xlat discussion from february, and I can only chime in with Cameron that getting v4v6 dual stack PDP context actually working in a 2G/3G/4G environement, is non-trivial. There are a lot of components that need to support it and it seems whenever I get one of them fixed, there is something else we didn't think of. Also handsets seem to be very slow to adopt this (the only time I've been able to successfully able to enable a dual stack single bearer is on LTE, which then fails miserably when handing over to (or trying to establish in) 2G/3G), but handsets also do not seem to go the way of supporting 2 single stack bearers either (at least not Android). My Galaxy Nexus with 4.1.1 at least has the v4v6 PDP type I can choose, but it doesn't work (and I don't really know if it's the phone or the network (or both) that fails). I would at least like to thank Google for IPv6-enabling their phones so we have something to test with (we have USB dongles for computer connectivity as well, but that doesn't test the App ecosystem). I have been trying to reach someone at Apple to try to understand where they're headed, but so far no luck on that (which doesn't greatly surprise me considering their usual secrecy), but if someone from Apple reads this, it would greatly help if you would at least say for instance "it looks like we're going to support single v4v6 PDP context, single v4, or single v6 in the not too distant future", so we have something to plan for. Right now I have a really hard time internally trying to get something done because I can't say what we should be headed for, what will the handsets support in 1-2 years time. Installed base is also of great importance, if tens of percent doesn't support something (or will support it in the not too distant future) it's really hard to get anyone to spend time on implementing anything network side. So the only thing I can say for sure right now is that v6 only seems to work on a few android phones, and getting networking code into android would be easier (at least I imagine so) than to get baseband changes done to support new PDP context types. But this is just speculation on my part... -- Mikael Abrahamsson email: swmike@swm.pp.se