From eleven.fuyu@huawei.com Tue Nov 1 01:58:00 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B26321F904D for ; Tue, 1 Nov 2011 01:58:00 -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=[AWL=-0.001, 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 fmhKRDq-XjDy for ; Tue, 1 Nov 2011 01:57:59 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id BDE7D21F9042 for ; Tue, 1 Nov 2011 01:57:51 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTZ00JF84RKBQ@szxga03-in.huawei.com> for v6ops@ietf.org; Tue, 01 Nov 2011 16:54:56 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTZ00EYZ4QZGK@szxga03-in.huawei.com> for v6ops@ietf.org; Tue, 01 Nov 2011 16:54:56 +0800 (CST) Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AER16408; Tue, 01 Nov 2011 16:54:55 +0800 Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 01 Nov 2011 16:54:53 +0800 Received: from SZXEML512-MBX.china.huawei.com ([169.254.5.238]) by szxeml401-hub.china.huawei.com ([10.82.67.31]) with mapi id 14.01.0270.001; Tue, 01 Nov 2011 16:54:44 +0800 Date: Tue, 01 Nov 2011 08:54:42 +0000 From: "Eleven Fu(Yu)" In-reply-to: X-Originating-IP: [10.108.4.119] To: Qiong Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_/JrWyjyfvF+fYlfoAWyTYA)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: [v6ops] Fwd: New Version Notification for draft-sunq-v6ops-contents-transition-02.txt Thread-index: AQHMlhYkleC0HKPdbE6i0MbQtMSTkJWXjpgA X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Fwd: New Version Notification for draft-sunq-v6ops-contents-transition-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, 01 Nov 2011 08:58:00 -0000 --Boundary_(ID_/JrWyjyfvF+fYlfoAWyTYA) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: base64 SGkgUWlvbmc6DQoNCiAgIFBsZWFzZSBzZWUgc29tZSBjb21tZW50cyBmb3IgZHJhZnQtc3VucS12 Nm9wcy1jb250ZW50cy10cmFuc2l0aW9uLTAyIGJlbG93LA0KDQpGaWd1cmUgMSBpcyBhIGxpdHRs ZSBtaXNsZWFkaW5nLiBCZWNhdXNlIE5BVDY0IGNhbiBvbmx5IHNlcnZlIHRoZSBjb21tdW5pY2F0 aW9ucyBpbml0aWF0ZWQgYnkgSVB2NiBzaWRlIHRvIElQdjQgc2V2ZXIuIEl0IGNhbuKAmXQgcHJv dmlkZSBjb25uZWN0aW9uIHNlcnZpY2UgaW5pdGlhdGVkIGJ5IElQdjQgc2lkZS4gSG93ZXZlciwg dGhlIGZpZ3VyZSAxIG1heSBnaXZlIHJlYWRlcnMgc29tZSBpbmZvcm1hdGlvbiB0aGF0IGl0IGFs c28gdXNlIE5BVDY0IHRvIHNlcnZlIHRoZSBjb25uZWN0aW9ucyBpbml0aWF0ZWQgYnkgSVB2NCBz aWRlIHRvIElQdjYgc2V2ZXIuIFNvIEkgdGhpbmsgc29tZSBtb3JlIGluZm9ybWF0aW9uIG1heSBu ZWVkIHRvIGJlICBkZXNjcmliZWQgaW4gdGhlIGZpZ3VyZSB0byBjbGFyaWZ5IHRoZSBJUHY0IHRv IElQdjYgY29tbXVuaXRhcmlhbiBzY2VuYXJpby4NCg0KT3ZlcmFsbCwgIEkgdGhpbmsgdGhpcyBz b2x1dGlvbiBpcyBtZWFuaW5nZnVsIGZvciBtaWQtc2l6ZSBhbmQgc21hbGwgSUNQcyB0byAgcHJv dmlkZSBJUHY2ICBhY2Nlc3Mgc2VydmljZSBhbmQgaXMgdXNlZnVsIHRvIGVuY291cmFnZSBJUHY2 IHRyYWZmaWMuDQoNCkNoZWVycw0KDQpZdQ0KDQoNCkZyb206IHY2b3BzLWJvdW5jZXNAaWV0Zi5v cmc8bWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86djZvcHMtYm91bmNlc0Bp ZXRmLm9yZ108bWFpbHRvOlttYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZ10+IE9uIEJlaGFs ZiBPZiBRaW9uZw0KU2VudDogU2F0dXJkYXksIE9jdG9iZXIgMjksIDIwMTEgNDozOCBQTQ0KVG86 IHY2b3BzQGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9yZz4NClN1YmplY3Q6IFt2Nm9wc10g RndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXN1bnEtdjZvcHMtY29udGVu dHMtdHJhbnNpdGlvbi0wMi50eHQNCg0KRGVhciwgYWxsLA0KDQpUaGFua3MgZm9yIHlvdXIgZmVl ZGJhY2sgZnJvbSBJRVRGIDgxdGguIFdlIGhhdmUgdXBkYXRlZCBhIG5ldyB2ZXJzaW9uIG9mICJS YXBpZCBUcmFuc2l0aW9uIG9mIElQdjQgY29udGVudHMgdG8gYmUgSVB2Ni1hY2Nlc3NpYmxlIi4g V2UgaGF2ZSBkZXBsb3llZCBzZXZlcmFsIG1vZGVscyBmb3IgdGhlIHRyYW5zaXRpb24gb2YgSVB2 NCBzZXJ2aWNlcyB0byBJUHY2IGluIG91ciBjb21tZXJjaWFsIG5ldHdvcmssIGFpbWluZyBhdCBy YXBpZGx5IGluY3JlYXNpbmcgdGhlIGFtb3VudCBvZiBJUHY2IGFjY2Vzc2libGUgY29udGVudHMg Zm9yIHVzZXJzIGZyb20gSVB2NiBJbnRlcm5ldCB3aGlsZSBwcmVzZXJ2aW5nIHRoZSBjb250aW51 aXR5IG9mIElQdjQgc2VydmljZSBkZWxpdmVyeS4gV2Ugd291bGQgbGlrZSB0byBzaGFyZSBvdXIg ZXhwZXJpbWVudHMgYW5kIGNvbnNpZGVyYXRpb25zLiBBbnl3YXksIGNvbnRlbnQgdHJhbnNpdGlv biBpcyB2ZXJ5IGltcG9ydGFudCBpbiB0aGUgd2hvbGUgSVB2NiB0cmFuc2l0aW9uIHByb2Nlc3Mu DQoNCllvdSBjYW4gZmluZCBpdCB0aHJvdWdoOiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJh ZnQtc3VucS12Nm9wcy1jb250ZW50cy10cmFuc2l0aW9uLTAyLnR4dA0KDQpZb3VyIGNvbW1lbnRz IHdpbGwgYmUgdmVyeSBtdWNoIGFwcHJlY2lhdGVkLiAgVGhhbmtzIGluIGFkdmFuY2UhDQoNCkJl c3Qgd2lzaGVzDQoNClFpb25nDQoNCi0tLS0tLS0tLS0gRm9yd2FyZGVkIG1lc3NhZ2UgLS0tLS0t LS0tLQ0KRnJvbTogc3VucWlvbmcgPHN1bnFpb25nQGN0YnJpLmNvbS5jbjxtYWlsdG86c3VucWlv bmdAY3RicmkuY29tLmNuPj4NCkRhdGU6IFNhdCwgT2N0IDI5LCAyMDExIGF0IDQ6MjAgUE0NClN1 YmplY3Q6IEZ3OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yZHJhZnQtc3VucS12Nm9wcy1j b250ZW50cy10cmFuc2l0aW9uLTAyLnR4dA0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXN1 bnEtdjZvcHMtY29udGVudHMtdHJhbnNpdGlvbi0wMi50eHQgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5 IHN1Ym1pdHRlZCBieSBRaW9uZyBTdW4gYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5 Lg0KDQpGaWxlbmFtZTogIGRyYWZ0LXN1bnEtdjZvcHMtY29udGVudHMtdHJhbnNpdGlvbg0KUmV2 aXNpb246ICAwMg0KVGl0bGU6ICBSYXBpZCBUcmFuc2l0aW9uIG9mIElQdjQgY29udGVudHMgdG8g YmUgSVB2Ni1hY2Nlc3NpYmxlDQpDcmVhdGlvbiBkYXRlOiAgMjAxMS0xMC0yOQ0KV0cgSUQ6ICBJ bmRpdmlkdWFsIFN1Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczogMTQNCkFic3RyYWN0Og0KICAg VGhpcyBkb2N1bWVudCBkZXNjcmliZXMgc2V2ZXJhbCBkZXBsb3ltZW50IG1vZGVscyBmb3IgdGhl IHRyYW5zaXRpb24NCiAgIG9mIElQdjQgc2VydmljZXMgdG8gSVB2NiwgYWltaW5nIGF0IHJhcGlk bHkgaW5jcmVhc2luZyB0aGUgYW1vdW50IG9mDQogICBJUHY2IGFjY2Vzc2libGUgY29udGVudHMg Zm9yIHVzZXJzIGZyb20gSVB2NiBJbnRlcm5ldCB3aGlsZQ0KICAgcHJlc2VydmluZyB0aGUgY29u dGludWl0eSBvZiBJUHY0IHNlcnZpY2UgZGVsaXZlcnkuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0 DQoNCg== --Boundary_(ID_/JrWyjyfvF+fYlfoAWyTYA) Content-type: text/html; charset=utf-8 Content-transfer-encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlZl cmRhbmE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiXEDlrovkvZMiOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0K LyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5N c29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVy bGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0 ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IuaJueazqOahhuaW h+acrCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6OS4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCnNwYW4uQ2hhcg0KCXttc28tc3R5 bGUtbmFtZToi5om55rOo5qGG5paH5pysIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazrmibnms6jmoYbmlofmnKw7DQoJZm9udC1mYW1pbHk65a6L5L2TO30N CnNwYW4uYXBwbGUtc3R5bGUtc3Bhbg0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1zdHlsZS1zcGFu O30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6 MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCglt YXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0 PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iWkgtQ04iIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+SGkgUWlvbmc6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOyZuYnNwOyBQbGVhc2Ugc2VlIHNvbWUgY29tbWVudHMgZm9yIGRyYWZ0LXN1bnEt djZvcHMtY29udGVudHMtdHJhbnNpdGlvbi0wMiBiZWxvdyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDo1LjI1cHQiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RmlndXJlIDEgaXMgYSBs aXR0bGUgbWlzbGVhZGluZy4gQmVjYXVzZSBOQVQ2NCBjYW4gb25seSBzZXJ2ZSB0aGUgY29tbXVu aWNhdGlvbnMgaW5pdGlhdGVkIGJ5IElQdjYgc2lkZSB0byBJUHY0IHNldmVyLg0KIEl0IGNhbuKA mXQgcHJvdmlkZSBjb25uZWN0aW9uIHNlcnZpY2UgaW5pdGlhdGVkIGJ5IElQdjQgc2lkZS4gSG93 ZXZlciwgdGhlIGZpZ3VyZSAxIG1heSBnaXZlIHJlYWRlcnMgc29tZSBpbmZvcm1hdGlvbiB0aGF0 IGl0IGFsc28gdXNlIE5BVDY0IHRvIHNlcnZlIHRoZSBjb25uZWN0aW9ucyBpbml0aWF0ZWQgYnkg SVB2NCBzaWRlIHRvIElQdjYgc2V2ZXIuIFNvIEkgdGhpbmsgc29tZSBtb3JlIGluZm9ybWF0aW9u IG1heSBuZWVkIHRvIGJlJm5ic3A7IGRlc2NyaWJlZA0KIGluIHRoZSBmaWd1cmUgdG8gY2xhcmlm eSB0aGUgSVB2NCB0byBJUHY2IGNvbW11bml0YXJpYW4gc2NlbmFyaW8uPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6NS4yNXB0Ij48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk92ZXJhbGws Jm5ic3A7IEkgdGhpbmsgdGhpcyBzb2x1dGlvbiBpcyBtZWFuaW5nZnVsIGZvciBtaWQtc2l6ZSBh bmQgc21hbGwgSUNQcyB0byZuYnNwOyBwcm92aWRlIElQdjYmbmJzcDsgYWNjZXNzIHNlcnZpY2Ug YW5kIGlzIHVzZWZ1bA0KIHRvIGVuY291cmFnZSBJUHY2IHRyYWZmaWMuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNoZWVycw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPll1PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ DQo8YSBocmVmPSJtYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZyI+djZvcHMtYm91bmNlc0Bp ZXRmLm9yZzwvYT4gPGEgaHJlZj0ibWFpbHRvOlttYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9y Z10iPg0KW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXTwvYT4gPGI+T24gQmVoYWxmIE9m IDwvYj5RaW9uZzxicj4NCjxiPlNlbnQ6PC9iPiBTYXR1cmRheSwgT2N0b2JlciAyOSwgMjAxMSA0 OjM4IFBNPGJyPg0KPGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86djZvcHNAaWV0Zi5vcmciPnY2 b3BzQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBbdjZvcHNdIEZ3ZDogTmV3IFZl cnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1zdW5xLXY2b3BzLWNvbnRlbnRzLXRyYW5zaXRp b24tMDIudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkRlYXIsIGFsbCw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGFua3MgZm9yIHlvdXIgZmVlZGJhY2sg ZnJvbSBJRVRGIDgxdGguIFdlIGhhdmUgdXBkYXRlZCBhIG5ldyB2ZXJzaW9uIG9mICZxdW90O1Jh cGlkIFRyYW5zaXRpb24gb2YgSVB2NCBjb250ZW50cyB0byBiZSBJUHY2LWFjY2Vzc2libGUmcXVv dDsuIFdlIGhhdmUgZGVwbG95ZWQmbmJzcDtzZXZlcmFsIG1vZGVscyBmb3IgdGhlIHRyYW5zaXRp b24mbmJzcDtvZiBJUHY0IHNlcnZpY2VzIHRvIElQdjYgaW4gb3VyJm5ic3A7Y29tbWVyY2lhbCZu YnNwO25ldHdvcmssDQogYWltaW5nIGF0IHJhcGlkbHkgaW5jcmVhc2luZyB0aGUgYW1vdW50IG9m Jm5ic3A7SVB2NiBhY2Nlc3NpYmxlIGNvbnRlbnRzIGZvciB1c2VycyBmcm9tIElQdjYgSW50ZXJu ZXQgd2hpbGUmbmJzcDtwcmVzZXJ2aW5nIHRoZSBjb250aW51aXR5IG9mIElQdjQgc2VydmljZSBk ZWxpdmVyeS4gV2Ugd291bGQgbGlrZSB0byBzaGFyZSBvdXIgZXhwZXJpbWVudHMgYW5kIGNvbnNp ZGVyYXRpb25zLiBBbnl3YXksIGNvbnRlbnQgdHJhbnNpdGlvbiBpcyB2ZXJ5IGltcG9ydGFudA0K IGluIHRoZSB3aG9sZSBJUHY2IHRyYW5zaXRpb24gcHJvY2Vzcy48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPllvdSBjYW4gZmluZCBpdCB0aHJvdWdoOiZu YnNwOzxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1zdW5xLXY2b3BzLWNv bnRlbnRzLXRyYW5zaXRpb24tMDIudHh0Ij5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQt c3VucS12Nm9wcy1jb250ZW50cy10cmFuc2l0aW9uLTAyLnR4dDwvYT48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPllvdXIgY29tbWVudHMgd2lsbCBiZSB2 ZXJ5IG11Y2ggYXBwcmVjaWF0ZWQuICZuYnNwO1RoYW5rcyBpbiBhZHZhbmNlITxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+QmVzdCB3aXNoZXM8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlFpb25nPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj4tLS0tLS0tLS0tIEZvcndhcmRlZCBtZXNzYWdlIC0tLS0tLS0tLS08YnI+DQpGcm9tOiA8 Yj5zdW5xaW9uZzwvYj4gJmx0OzxhIGhyZWY9Im1haWx0bzpzdW5xaW9uZ0BjdGJyaS5jb20uY24i PnN1bnFpb25nQGN0YnJpLmNvbS5jbjwvYT4mZ3Q7PGJyPg0KRGF0ZTogU2F0LCBPY3QgMjksIDIw MTEgYXQgNDoyMCBQTTxicj4NClN1YmplY3Q6IEZ3OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g Zm9yZHJhZnQtc3VucS12Nm9wcy1jb250ZW50cy10cmFuc2l0aW9uLTAyLnR4dDxicj4NCjwvc3Bh bj48c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PkEmbmJzcDtuZXcmbmJzcDt2ZXJzaW9uJm5ic3A7b2YmbmJzcDtJLUQsJm5ic3A7ZHJhZnQtc3Vu cS12Nm9wcy1jb250ZW50cy10cmFuc2l0aW9uLTAyLnR4dCZuYnNwO2hhcyZuYnNwO2JlZW4mbmJz cDtzdWNjZXNzZnVsbHkmbmJzcDtzdWJtaXR0ZWQmbmJzcDtieSZuYnNwO1Fpb25nJm5ic3A7U3Vu Jm5ic3A7YW5kJm5ic3A7cG9zdGVkJm5ic3A7dG8mbmJzcDt0aGUmbmJzcDtJRVRGJm5ic3A7cmVw b3NpdG9yeS48L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxl ZnQ6Ny41cHQ7bWFyZ2luLXRvcDo3LjVwdDttYXJnaW4tcmlnaHQ6Ny41cHQ7bWFyZ2luLWJvdHRv bTo3LjVwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkZpbGVuYW1lOiAmbmJz cDtkcmFmdC1zdW5xLXY2b3BzLWNvbnRlbnRzLXRyYW5zaXRpb248bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5SZXZpc2lvbjogJm5ic3A7MDI8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5U aXRsZTogJm5ic3A7UmFwaWQmbmJzcDtUcmFuc2l0aW9uJm5ic3A7b2YmbmJzcDtJUHY0Jm5ic3A7 Y29udGVudHMmbmJzcDt0byZuYnNwO2JlJm5ic3A7SVB2Ni1hY2Nlc3NpYmxlPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRh bmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Q3JlYXRpb24mbmJz cDtkYXRlOiAmbmJzcDsyMDExLTEwLTI5PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+V0cmbmJzcDtJRDogJm5ic3A7SW5kaXZpZHVhbCZuYnNw O1N1Ym1pc3Npb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj5OdW1iZXImbmJzcDtvZiZuYnNwO3BhZ2VzOiZuYnNwOzE0PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRh bmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+QWJzdHJhY3Q6PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5i c3A7Jm5ic3A7Jm5ic3A7VGhpcyZuYnNwO2RvY3VtZW50Jm5ic3A7ZGVzY3JpYmVzJm5ic3A7c2V2 ZXJhbCZuYnNwO2RlcGxveW1lbnQmbmJzcDttb2RlbHMmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDt0 cmFuc2l0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7b2YmbmJzcDtJUHY0Jm5ic3A7c2VydmljZXMmbmJz cDt0byZuYnNwO0lQdjYsJm5ic3A7YWltaW5nJm5ic3A7YXQmbmJzcDtyYXBpZGx5Jm5ic3A7aW5j cmVhc2luZyZuYnNwO3RoZSZuYnNwO2Ftb3VudCZuYnNwO29mPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7SVB2 NiZuYnNwO2FjY2Vzc2libGUmbmJzcDtjb250ZW50cyZuYnNwO2ZvciZuYnNwO3VzZXJzJm5ic3A7 ZnJvbSZuYnNwO0lQdjYmbmJzcDtJbnRlcm5ldCZuYnNwO3doaWxlPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 cHJlc2VydmluZyZuYnNwO3RoZSZuYnNwO2NvbnRpbnVpdHkmbmJzcDtvZiZuYnNwO0lQdjQmbmJz cDtzZXJ2aWNlJm5ic3A7ZGVsaXZlcnkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+VGhlJm5ic3A7SUVURiZuYnNwO1NlY3JldGFyaWF0PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --Boundary_(ID_/JrWyjyfvF+fYlfoAWyTYA)-- From tore.anderson@redpill-linpro.com Tue Nov 1 02:10:39 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EC7E21F8610 for ; Tue, 1 Nov 2011 02:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qmDY-7L9cx3f for ; Tue, 1 Nov 2011 02:10:15 -0700 (PDT) Received: from zimbra.redpill-linpro.com (zimbra.redpill-linpro.com [IPv6:2a02:c0:200:c000::1]) by ietfa.amsl.com (Postfix) with ESMTP id 35D7721F8E06 for ; Tue, 1 Nov 2011 02:10:11 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.redpill-linpro.com (Postfix) with ESMTP id E25FC103801F; Tue, 1 Nov 2011 10:10:06 +0100 (CET) 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 Fkrr0t2WlD5K; Tue, 1 Nov 2011 10:10:06 +0100 (CET) Received: from echo.linpro.no (unknown [IPv6:2a02:c0:1002:102:21d:60ff:fe48:f59e]) by zimbra.redpill-linpro.com (Postfix) with ESMTPSA id 6249E103801E; Tue, 1 Nov 2011 10:10:06 +0100 (CET) Message-ID: <4EAFB76D.7070208@redpill-linpro.com> Date: Tue, 01 Nov 2011 10:10:05 +0100 From: Tore Anderson Organization: Redpill Linpro AS User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: Brian E Carpenter References: <201110221355.p9MDt0M17687@ftpeng-update.cisco.com> <4EA7DC26.6020802@forthnetgroup.gr> <4EA87342.90305@gmail.com> <4EAB2233.8040908@gmail.com> <4EAB4856.2070002@dougbarton.us> <50CF70B9-3EAA-4897-9AF3-62A8D96C3EFB@cisco.com> <4EADB1C2.8000601@gmail.com> In-Reply-To: <4EADB1C2.8000601@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , "draft-carpenter-v6ops-icp-guidance@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-carpenter-v6ops-icp-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 01 Nov 2011 09:10:39 -0000 * Brian E Carpenter > That is a very different deployment model than > draft-carpenter-v6ops-icp-guidance advocates. I can understand that > there might be unusual circumstances in which it would be chosen, but > it is so much simpler to dual-stack all servers. In a purely technical sense, you might be right. However, I've come to realize that dual-stack is not really a viable transition approach for us, due to organizational and human considerations. I think the draft is intended exactly for organizations such as ours btw, as we're a small/medium-sized ICP. We have a team of people that works on the network infrastructure (of which I'm part), and several teams with sysadmins that operate the customers' servers, operating systems, and the applications running on them. While my colleagues and I are happy to promote IPv6 by always assigning an IPv6 prefix to all LANs that are requested by the server guys, their priorities are very different - they don't want to get involved more networking than absolutely necessary. So if I give them two IP stacks to work with, they'll choose one and leave the other one unused, and not surprisingly, the one they choose to work with is going to be the most familiar one - IPv4. I can understand it, too - dual stack is in a sense dual work and dual complexity. They'd need to configure ACLs twice, monitor everything twice, accept lots of new failure scenarios and so on. It's real operational overhead, and nobody really wants that. If there is an explicit demand from the customer to have IPv6 availability, that changes things somewhat - but usually not more than causing a dual-stacking of the public internet-facing frontends. Most servers remain IPv4-only, while only the load balancers/web servers/whatever gets an additional IPv6 address that can be published in DNS. In any case, customer requests for IPv6 are few and far between, and to this date no customer has ever asked us for a dual-stacking of all of his servers. After all, dual-stack as a transition mechanism has gained approx. zero momentum in the decade it's been the recommended IPv6 transition mechanism. I don't see any reason why that would change any time soon. I'm instead pursuing a path where I'll give the sysadmins single-stack IPv6 to work with, and handle IPv4 connectivity as a translation function in the core network (e.g. using SIIT). We'll see how that works out in the end, but it has some advantages over dual-stack, in my opinion: First, it forces the sysadmins to actually make use of IPv6. Second, it doesn't require them to deal with more than 1 IP protocol. Third, and perhaps most importantly, it helps a lot with IPv4 depletion. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com From brian.e.carpenter@gmail.com Tue Nov 1 13:17:02 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 457B211E81CD for ; Tue, 1 Nov 2011 13:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.205 X-Spam-Level: X-Spam-Status: No, score=-103.205 tagged_above=-999 required=5 tests=[AWL=-0.206, BAYES_00=-2.599, 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 TCJDos5JkkaH for ; Tue, 1 Nov 2011 13:17:01 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 246A211E81C7 for ; Tue, 1 Nov 2011 13:17:00 -0700 (PDT) Received: by wyg30 with SMTP id 30so2918143wyg.31 for ; Tue, 01 Nov 2011 13:16:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=/GR5VnJ1D04lVDfRm+qAlHxuT64vXqrhyy+okdFr2FQ=; b=YFkQlzW1dHvPkQ0Oxr5Y2o6s5yTaXfT17BVWSTu0x7XX4ebJBvbSxNo99Y2Uir4WwX lo6Ps0BPTHtX1pWioBaERs4ej6rtQ44WJoqx49logedpypO6H9gXVVVnZzBBTaA3TxuY bPAv03C5Pzrg9ry40YHG3e7Watn1hQdBfBFu0= Received: by 10.227.208.81 with SMTP id gb17mr1296098wbb.24.1320178570346; Tue, 01 Nov 2011 13:16:10 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id fy21sm195770wbb.5.2011.11.01.13.16.07 (version=SSLv3 cipher=OTHER); Tue, 01 Nov 2011 13:16:09 -0700 (PDT) Message-ID: <4EB05384.5000007@gmail.com> Date: Wed, 02 Nov 2011 09:16:04 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Eleven Fu(Yu)" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" , Qiong Subject: Re: [v6ops] Fwd: New Version Notification for draft-sunq-v6ops-contents-transition-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, 01 Nov 2011 20:17:02 -0000 I'm not seeing why this is a better solution for a small/medium ICP than just moving to a dual stack. That is much easier for a small network than for a big one. Regards Brian On 2011-11-01 21:54, Eleven Fu(Yu) wrote: > Hi Qiong: >=20 > Please see some comments for draft-sunq-v6ops-contents-transition-02= below, >=20 > Figure 1 is a little misleading. Because NAT64 can only serve the commu= nications initiated by IPv6 side to IPv4 sever. It can=E2=80=99t provide = connection service initiated by IPv4 side. However, the figure 1 may give= readers some information that it also use NAT64 to serve the connections= initiated by IPv4 side to IPv6 sever. So I think some more information m= ay need to be described in the figure to clarify the IPv4 to IPv6 commun= itarian scenario. >=20 > Overall, I think this solution is meaningful for mid-size and small IC= Ps to provide IPv6 access service and is useful to encourage IPv6 traff= ic. >=20 > Cheers >=20 > Yu >=20 >=20 > From: v6ops-bounces@ietf.org [mailto:v6o= ps-bounces@ietf.org] On Behalf Of= Qiong > Sent: Saturday, October 29, 2011 4:38 PM > To: v6ops@ietf.org > Subject: [v6ops] Fwd: New Version Notification for draft-sunq-v6ops-con= tents-transition-02.txt >=20 > Dear, all, >=20 > Thanks for your feedback from IETF 81th. We have updated a new version = of "Rapid Transition of IPv4 contents to be IPv6-accessible". We have dep= loyed several models for the transition of IPv4 services to IPv6 in our c= ommercial network, aiming at rapidly increasing the amount of IPv6 access= ible contents for users from IPv6 Internet while preserving the continuit= y of IPv4 service delivery. We would like to share our experiments and co= nsiderations. Anyway, content transition is very important in the whole I= Pv6 transition process. >=20 > You can find it through: http://tools.ietf.org/id/draft-sunq-v6ops-cont= ents-transition-02.txt >=20 > Your comments will be very much appreciated. Thanks in advance! >=20 > Best wishes >=20 > Qiong >=20 > ---------- Forwarded message ---------- > From: sunqiong > > Date: Sat, Oct 29, 2011 at 4:20 PM > Subject: Fw: New Version Notification fordraft-sunq-v6ops-contents-tran= sition-02.txt > A new version of I-D, draft-sunq-v6ops-contents-transition-02.txt has b= een successfully submitted by Qiong Sun and posted to the IETF repository= =2E >=20 > Filename: draft-sunq-v6ops-contents-transition > Revision: 02 > Title: Rapid Transition of IPv4 contents to be IPv6-accessible > Creation date: 2011-10-29 > WG ID: Individual Submission > Number of pages: 14 > Abstract: > This document describes several deployment models for the transition= > of IPv4 services to IPv6, aiming at rapidly increasing the amount of= > IPv6 accessible contents for users from IPv6 Internet while > preserving the continuity of IPv4 service delivery. >=20 > The IETF Secretariat >=20 >=20 >=20 > -----------------------------------------------------------------------= - >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From brian.e.carpenter@gmail.com Tue Nov 1 13:28:58 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C90E821F9CA8 for ; Tue, 1 Nov 2011 13:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.5 X-Spam-Level: X-Spam-Status: No, score=-103.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a1V44y+R6Z83 for ; Tue, 1 Nov 2011 13:28:58 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id F3FF521F9CA2 for ; Tue, 1 Nov 2011 13:28:57 -0700 (PDT) Received: by wwi36 with SMTP id 36so2380954wwi.13 for ; Tue, 01 Nov 2011 13:27:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=UGuP0adj2CA2YFamTjHIbckWlRRpRedNU3wpQg3NN+U=; b=NkNr3ArZpVYpZyCCNf+XCcslrQl61IQdXYiT7UDcNiTUlEtm69rSoThMM4KJEp7Oz9 /Pu+XXZTMQl9TwMte5wUi8fBC7YOEKkIk7rR5Lg2HH+YcXmdvZQEW9FQLmr2fpzpIJ1a TENxZR2X8qtr6q0jTBFIL7kjCx3J0camIWnxg= Received: by 10.216.80.87 with SMTP id j65mr327299wee.57.1320179235205; Tue, 01 Nov 2011 13:27:15 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id eu16sm235675wbb.7.2011.11.01.13.27.10 (version=SSLv3 cipher=OTHER); Tue, 01 Nov 2011 13:27:13 -0700 (PDT) Message-ID: <4EB0561C.7070507@gmail.com> Date: Wed, 02 Nov 2011 09:27:08 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Tore Anderson References: <201110221355.p9MDt0M17687@ftpeng-update.cisco.com> <4EA7DC26.6020802@forthnetgroup.gr> <4EA87342.90305@gmail.com> <4EAB2233.8040908@gmail.com> <4EAB4856.2070002@dougbarton.us> <50CF70B9-3EAA-4897-9AF3-62A8D96C3EFB@cisco.com> <4EADB1C2.8000601@gmail.com> <4EAFB76D.7070208@redpill-linpro.com> In-Reply-To: <4EAFB76D.7070208@redpill-linpro.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , "draft-carpenter-v6ops-icp-guidance@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-carpenter-v6ops-icp-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 01 Nov 2011 20:28:58 -0000 Grumble. I don't like that conclusion, because it's clear that the desired end point is native v6 and I don't see how your approach gets us there. OK, if the draft becomes a WG draft, I can see that we would need to add the draft-sunq-v6ops-contents-transition model to the outside-in scenario, as an alternative to the dual stack proxy. However, although the proxy may be a bit slower, it strikes me as a much cleaner solution than NAT64. And of course it's off-the-shelf running code. Regards Brian On 2011-11-01 22:10, Tore Anderson wrote: > * Brian E Carpenter > >> That is a very different deployment model than >> draft-carpenter-v6ops-icp-guidance advocates. I can understand that >> there might be unusual circumstances in which it would be chosen, but >> it is so much simpler to dual-stack all servers. > > In a purely technical sense, you might be right. However, I've come to > realize that dual-stack is not really a viable transition approach for > us, due to organizational and human considerations. I think the draft is > intended exactly for organizations such as ours btw, as we're a > small/medium-sized ICP. > > We have a team of people that works on the network infrastructure (of > which I'm part), and several teams with sysadmins that operate the > customers' servers, operating systems, and the applications running on > them. While my colleagues and I are happy to promote IPv6 by always > assigning an IPv6 prefix to all LANs that are requested by the server > guys, their priorities are very different - they don't want to get > involved more networking than absolutely necessary. So if I give them > two IP stacks to work with, they'll choose one and leave the other one > unused, and not surprisingly, the one they choose to work with is going > to be the most familiar one - IPv4. > > I can understand it, too - dual stack is in a sense dual work and dual > complexity. They'd need to configure ACLs twice, monitor everything > twice, accept lots of new failure scenarios and so on. It's real > operational overhead, and nobody really wants that. > > If there is an explicit demand from the customer to have IPv6 > availability, that changes things somewhat - but usually not more than > causing a dual-stacking of the public internet-facing frontends. Most > servers remain IPv4-only, while only the load balancers/web > servers/whatever gets an additional IPv6 address that can be published > in DNS. In any case, customer requests for IPv6 are few and far between, > and to this date no customer has ever asked us for a dual-stacking of > all of his servers. > > After all, dual-stack as a transition mechanism has gained approx. zero > momentum in the decade it's been the recommended IPv6 transition > mechanism. I don't see any reason why that would change any time soon. > > I'm instead pursuing a path where I'll give the sysadmins single-stack > IPv6 to work with, and handle IPv4 connectivity as a translation > function in the core network (e.g. using SIIT). We'll see how that works > out in the end, but it has some advantages over dual-stack, in my > opinion: First, it forces the sysadmins to actually make use of IPv6. > Second, it doesn't require them to deal with more than 1 IP protocol. > Third, and perhaps most importantly, it helps a lot with IPv4 depletion. > > Best regards, From bingxuere@gmail.com Tue Nov 1 22:04:56 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3187C11E8086 for ; Tue, 1 Nov 2011 22:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.212 X-Spam-Level: X-Spam-Status: No, score=-3.212 tagged_above=-999 required=5 tests=[AWL=0.386, 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 G+p53FGekuwd for ; Tue, 1 Nov 2011 22:04:55 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1BBE911E807F for ; Tue, 1 Nov 2011 22:04:55 -0700 (PDT) Received: by iaeo4 with SMTP id o4so1713963iae.31 for ; Tue, 01 Nov 2011 22:04:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=J8/amHbHgBBLa1cz2EYgqeo1MX3OPbRWINDmkDFHDMI=; b=cicsnugDIWUv3jFx3Pqa0Xrgv+MLyjVWUCfyS44ev5dMi+a2Otbw451AlwmVELaRTs TmUC77Vubng9Cc/1a4YL+gZDID3qr4qrE75jnzzooV2/R6MNWvE/6CNJYodqfab3xxRN /F3mvz7yAL+HF6BK0WW84Oc4EAcOzgB2phk2w= Received: by 10.43.44.199 with SMTP id uh7mr1967586icb.25.1320210293114; Tue, 01 Nov 2011 22:04:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.218.10 with HTTP; Tue, 1 Nov 2011 22:04:12 -0700 (PDT) In-Reply-To: References: From: Qiong Date: Wed, 2 Nov 2011 13:04:12 +0800 Message-ID: To: "Eleven Fu(Yu)" Content-Type: multipart/alternative; boundary=bcaec52999eb8cc6bd04b0b96908 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Fwd: New Version Notification for draft-sunq-v6ops-contents-transition-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, 02 Nov 2011 05:04:56 -0000 --bcaec52999eb8cc6bd04b0b96908 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Yu, Thanks for your comments. Please see inline :) On Tue, Nov 1, 2011 at 4:54 PM, Eleven Fu(Yu) wrote= : > Hi Qiong:**** > > ** ** > > Please see some comments for draft-sunq-v6ops-contents-transition-02 > below,**** > > ** ** > > Figure 1 is a little misleading. Because NAT64 can only serve the > communications initiated by IPv6 side to IPv4 sever. It can=E2=80=99t pro= vide > connection service initiated by IPv4 side. However, the figure 1 may give > readers some information that it also use NAT64 to serve the connections > initiated by IPv4 side to IPv6 sever. So I think some more information ma= y > need to be described in the figure to clarify the IPv4 to IPv6 > communitarian scenario.**** > > ** > Sorry for misleading, and we would clarify it in the next version. Our deployment model includes both stateful NAT64 and stateless NAT64(IVI), in which stateful NAT64 is for scenario initiated by IPv6 side to IPv4 server, while stateless NAT64(IVI) is for IPv4 initiated client to IPv6 server. ** > > Overall, I think this solution is meaningful for mid-size and small ICPs > to provide IPv6 access service and is useful to encourage IPv6 traffic.= * > *** > > ** > Thanks. Our basic idea is to encourage IPv6 traffic and enrich IPv6 contents ASAP. Actually, we have discussed with many ICPs and their situations are quite complicated. Some of them even do not realize what is IPv6, but just keep asking us whether we have IPv6 customers or not. We believe that the amount IPv6 traffic and IPv6-reachable contents is a key point to the development of IPv6. After so many years of IPv6 research, our whole community really need the confidence to move forward, and maybe IPv6 traffic is most convincing. Although it is a only initial step kind of not so clean, but it does help enriching IPv6 content for a great many ICPs. What's why we would like to offer transition service to ICPs at low cost. Best wishes Qiong > ** > > Cheers **** > > ** ** > > Yu**** > > ** ** > > ** ** > > *From:* v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] *On Behalf > Of *Qiong > *Sent:* Saturday, October 29, 2011 4:38 PM > *To:* v6ops@ietf.org > *Subject:* [v6ops] Fwd: New Version Notification for > draft-sunq-v6ops-contents-transition-02.txt**** > > ** ** > > Dear, all,**** > > ** ** > > Thanks for your feedback from IETF 81th. We have updated a new version of > "Rapid Transition of IPv4 contents to be IPv6-accessible". We have > deployed several models for the transition of IPv4 services to IPv6 in > our commercial network, aiming at rapidly increasing the amount of IPv6 > accessible contents for users from IPv6 Internet while preserving the > continuity of IPv4 service delivery. We would like to share our experimen= ts > and considerations. Anyway, content transition is very important in the > whole IPv6 transition process.**** > > ** ** > > You can find it through: > http://tools.ietf.org/id/draft-sunq-v6ops-contents-transition-02.txt**** > > ** ** > > Your comments will be very much appreciated. Thanks in advance!**** > > ** ** > > Best wishes**** > > ** ** > > Qiong**** > > ** ** > > ---------- Forwarded message ---------- > From: *sunqiong* > Date: Sat, Oct 29, 2011 at 4:20 PM > Subject: Fw: New Version Notification > fordraft-sunq-v6ops-contents-transition-02.txt > > A new version of I-D, draft-sunq-v6ops-contents-transition-02.txt has bee= n successfully submitted by Qiong Sun and posted to the IETF repository. > **** > > ** ** > > Filename: draft-sunq-v6ops-contents-transition**** > > Revision: 02**** > > Title: Rapid Transition of IPv4 contents to be IPv6-accessible**** > > Creation date: 2011-10-29**** > > WG ID: Individual Submission**** > > Number of pages: 14**** > > Abstract:**** > > This document describes several deployment models for the transition**= * > * > > of IPv4 services to IPv6, aiming at rapidly increasing the amount of**= * > * > > IPv6 accessible contents for users from IPv6 Internet while**** > > preserving the continuity of IPv4 service delivery.**** > > > > **** > > The IETF Secretariat**** > > ** ** > --bcaec52999eb8cc6bd04b0b96908 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Yu,

Thanks for your comments. Please see inline :)

On Tue, Nov 1, 2011 at 4:54 PM, Eleven= Fu(Yu) <ele= ven.fuyu@huawei.com> wrote:

Hi Qiong:

=C2=A0

=C2=A0=C2=A0 Please see some comments for draft-sunq-v6ops-conten= ts-transition-02 below,

=C2=A0

Figure 1 is a little misleading. Bec= ause NAT64 can only serve the communications initiated by IPv6 side to IPv4= sever. It can=E2=80=99t provide connection service initiated by IPv4 side. Howeve= r, the figure 1 may give readers some information that it also use NAT64 to= serve the connections initiated by IPv4 side to IPv6 sever. So I think som= e more information may need to be=C2=A0 described in the figure to clarify the IPv4 to IPv6 communitarian scenario.


So= rry for misleading, and we would clarify it in the next version. Our deploy= ment model includes both stateful NAT64 and stateless NAT64(IVI), in which = stateful NAT64 is for scenario initiated by IPv6 side to IPv4 server, while= stateless NAT64(IVI) is for IPv4 initiated client to IPv6 server.=C2=A0

=C2=A0

Overall,=C2=A0 I think this solution= is meaningful for mid-size and small ICPs to=C2=A0 provide IPv6=C2=A0 acce= ss service and is useful to encourage IPv6 traffic.

=C2=A0

Thanks.=C2= =A0Our basic idea is to encourage IPv6 traffic and enrich IPv6 contents ASA= P. Actually, we have discussed with many ICPs and their situations are quit= e complicated. Some of them even do not realize what is IPv6, but just keep= asking us whether we have IPv6 customers or not.
We believe that the amount IPv6 traffic and IPv6-reachable contents is= a key point to the development of IPv6. After so many years of IPv6 resear= ch, our whole community really need the confidence to move forward, and may= be IPv6 traffic is most convincing. Although it is a only initial step kind= of not so clean, but it does help enriching IPv6 content for a great many = ICPs. What's why we would like to offer transition service to ICPs at l= ow cost.

Best wishes

Qiong =C2=A0=C2=A0=
=C2=A0

Cheers

=C2=A0

Yu

=C2=A0

=C2=A0

F= rom: v6ops-bounces@i= etf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Qiong
Sent: Saturday, October 29, 2011 4:38 PM
To: v6ops@ietf.o= rg
Subject: [v6ops] Fwd: New Version Notification for draft-sunq-v6ops-= contents-transition-02.txt

=C2=A0

Dear, all,=

=C2=A0

Thanks for your feedback from I= ETF 81th. We have updated a new version of "Rapid Transition of IPv4 c= ontents to be IPv6-accessible". We have deployed=C2=A0several models f= or the transition=C2=A0of IPv4 services to IPv6 in our=C2=A0commercial=C2= =A0network, aiming at rapidly increasing the amount of=C2=A0IPv6 accessible contents f= or users from IPv6 Internet while=C2=A0preserving the continuity of IPv4 se= rvice delivery. We would like to share our experiments and considerations. = Anyway, content transition is very important in the whole IPv6 transition process.

=C2=A0

You can find it through:=C2=A0<= a href=3D"http://tools.ietf.org/id/draft-sunq-v6ops-contents-transition-02.= txt" target=3D"_blank">http://tools.ietf.org/id/draft-sunq-v6ops-contents-t= ransition-02.txt

=C2=A0

Your comments will be very much= appreciated. =C2=A0Thanks in advance!

=C2=A0

Best wishes

=C2=A0

Qiong

= =C2=A0

---------- Forwarded message --= --------
From: sunqiong <sunqiong@ctbri.com.cn>
Date: Sat, Oct 29, 2011 at 4:20 PM
Subject: Fw: New Version Notification fordraft-sunq-v6ops-contents-transiti= on-02.txt
A=C2=A0new=C2=A0version=C2=A0of=C2=A0I-D,= =C2=A0draft-sunq-v6ops-contents-transition-02.txt=C2=A0has=C2=A0been=C2=A0s= uccessfully=C2=A0submitted=C2=A0by=C2=A0Qiong=C2=A0Sun=C2=A0and=C2=A0posted= =C2=A0to=C2=A0the=C2=A0IETF=C2=A0repository.

=C2=A0

Filename: =C2=A0draft-sunq-v6ops-contents-transition<= /span>

Revision: =C2=A002

Title: =C2=A0Rapid=C2=A0Transition=C2=A0of=C2=A0IPv4=C2=A0contents= =C2=A0to=C2=A0be=C2=A0IPv6-accessible

Creation=C2=A0date: =C2=A02011-10-29

WG=C2=A0ID: =C2=A0Individual=C2=A0Submission

Number=C2=A0of=C2=A0pages:=C2=A014

Abstract:

=C2=A0=C2=A0=C2=A0This=C2=A0document=C2=A0describes=C2=A0several=C2= =A0deployment=C2=A0models=C2=A0for=C2=A0the=C2=A0transition

=C2=A0=C2=A0=C2=A0of=C2=A0IPv4=C2=A0services=C2=A0to=C2=A0IPv6,=C2= =A0aiming=C2=A0at=C2=A0rapidly=C2=A0increasing=C2=A0the=C2=A0amount=C2=A0of=

=C2=A0=C2=A0=C2=A0IPv6=C2=A0accessible=C2=A0contents=C2=A0for=C2=A0= users=C2=A0from=C2=A0IPv6=C2=A0Internet=C2=A0while

=C2=A0=C2=A0=C2=A0preserving=C2=A0the=C2=A0continuity=C2=A0of=C2=A0= IPv4=C2=A0service=C2=A0delivery.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

The=C2=A0IETF=C2=A0Secretariat

=C2=A0


--bcaec52999eb8cc6bd04b0b96908-- From marka@isc.org Wed Nov 2 00:13:39 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E2AF11E80D1 for ; Wed, 2 Nov 2011 00:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, 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 rXD1zbQxtKXs for ; Wed, 2 Nov 2011 00:13:38 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id A6DDE11E80A6 for ; Wed, 2 Nov 2011 00:13:38 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id E6068C9428; Wed, 2 Nov 2011 07:13:25 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 64253216C6A; Wed, 2 Nov 2011 07:13:25 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 7821D16765EC; Wed, 2 Nov 2011 18:13:23 +1100 (EST) To: Tore Anderson From: Mark Andrews References: <201110221355.p9MDt0M17687@ftpeng-update.cisco.com> <4EA7DC26.6020802@forthnetgroup.gr> <4EA87342.90305@gmail.com> <4EAB2233.8040908@gmail.com> <4EAB4856.2070002@dougbarton.us> <50CF70B9-3EAA-4897-9AF3-62A8D96C3EFB@cisco.com> <4EADB1C2.8000601@gmail.com> <4EAFB76D.7070208@redpill-linpro.com> In-reply-to: Your message of "Tue, 01 Nov 2011 10:10:05 BST." <4EAFB76D.7070208@redpill-linpro.com> Date: Wed, 02 Nov 2011 18:13:23 +1100 Message-Id: <20111102071323.7821D16765EC@drugs.dv.isc.org> Cc: "v6ops@ietf.org" , "draft-carpenter-v6ops-icp-guidance@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-carpenter-v6ops-icp-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 Nov 2011 07:13:39 -0000 In message <4EAFB76D.7070208@redpill-linpro.com>, Tore Anderson writes: > * Brian E Carpenter > > > That is a very different deployment model than > > draft-carpenter-v6ops-icp-guidance advocates. I can understand that > > there might be unusual circumstances in which it would be chosen, but > > it is so much simpler to dual-stack all servers. > > In a purely technical sense, you might be right. However, I've come to > realize that dual-stack is not really a viable transition approach for > us, due to organizational and human considerations. I think the draft is > intended exactly for organizations such as ours btw, as we're a > small/medium-sized ICP. > > We have a team of people that works on the network infrastructure (of > which I'm part), and several teams with sysadmins that operate the > customers' servers, operating systems, and the applications running on > them. While my colleagues and I are happy to promote IPv6 by always > assigning an IPv6 prefix to all LANs that are requested by the server > guys, their priorities are very different - they don't want to get > involved more networking than absolutely necessary. So if I give them > two IP stacks to work with, they'll choose one and leave the other one > unused, and not surprisingly, the one they choose to work with is going > to be the most familiar one - IPv4. > > I can understand it, too - dual stack is in a sense dual work and dual > complexity. They'd need to configure ACLs twice, monitor everything > twice, accept lots of new failure scenarios and so on. It's real > operational overhead, and nobody really wants that. Our ops people would say you are exagerating the costs. They have 7+ years of dual stack experience. It's not zero but is close to that. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From bingxuere@gmail.com Wed Nov 2 01:25:12 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C60B11E80CD for ; Wed, 2 Nov 2011 01:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.244 X-Spam-Level: X-Spam-Status: No, score=-3.244 tagged_above=-999 required=5 tests=[AWL=0.354, 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 jMopwpF7ZcXm for ; Wed, 2 Nov 2011 01:25:11 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 204C111E80AC for ; Wed, 2 Nov 2011 01:25:11 -0700 (PDT) Received: by iaeo4 with SMTP id o4so1926749iae.31 for ; Wed, 02 Nov 2011 01:24:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=GSK1wfg2nlwCl4WDRodQ8saik0wB6Uev4D0QPwfQ1ko=; b=QzwkocyXgh08WQYbVqGTLar6N/NOuz9nOzWWYnR+MviPHLNfhtEqDrclxGmh2vx5Nk vtSoiw0cjoBFR9MAQ+mhe/oJOkSfGrlDJbj7CHF1Kze4JNh0ZCpzR8OXgaXYABBQ40Ek y0nU3JLVL493sk68GHJoQc02LpeWITwLTXgfE= Received: by 10.42.41.143 with SMTP id p15mr2556902ice.9.1320222276087; Wed, 02 Nov 2011 01:24:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.218.10 with HTTP; Wed, 2 Nov 2011 01:23:54 -0700 (PDT) In-Reply-To: <4EB05384.5000007@gmail.com> References: <4EB05384.5000007@gmail.com> From: Qiong Date: Wed, 2 Nov 2011 16:23:54 +0800 Message-ID: To: Brian E Carpenter Content-Type: multipart/alternative; boundary=20cf301d424cca705204b0bc33c8 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Fwd: New Version Notification for draft-sunq-v6ops-contents-transition-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, 02 Nov 2011 08:25:12 -0000 --20cf301d424cca705204b0bc33c8 Content-Type: text/plain; charset=UTF-8 Hi Brian, Thanks for your comments. I agree that dual-stack is a very straightforward way to IPv6 and should be recommended in general. But frankly, I think the situation we are facing with seems much more complicated, sometimes beyond technical issues. Most ICPs are still lacking of motivation to upgrade, just waiting for v6 users. And in the same way, operators are also hesitating to deploy v6 when there are very few existing v6 contents. This chicken and egg thing is still ongoing, even we are running out IPv4 address. After all, dual stack is what we have discussing for 10 years. But up to now, how many ICPs have upgraded to IPv6 in dual-stack directly? I really think we need to re-think it again, from both technical aspect and the industry/or market aspect. And the first step is rather important to give us confidence to move forward. That's why we recommend single-stack (either v4 or v6) transition in the current phase. Then, for the conservative ones, the IPv4 services can be still offered natively, and the IPv6 services can be offered by the stateful NAT64; while for progressive ones and newly comers, the stateless IVI can be employed to offer native IPv6 services reachable via IPv4. And we hope it would help enrich IPv6 content asap. Then how do you think ? Thanks Qiong On Wed, Nov 2, 2011 at 4:16 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > I'm not seeing why this is a better solution for a small/medium ICP > than just moving to a dual stack. That is much easier for a small > network than for a big one. > > Regards > Brian > > --20cf301d424cca705204b0bc33c8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Brian,

Thanks for your comments.

=
I agree that dual-stack is a very=C2=A0straightforward=C2=A0way to IPv= 6 and should be recommended in general. But frankly, I think the situation = we are facing with seems much more complicated, sometimes beyond technical = issues. Most ICPs are still lacking of motivation to upgrade, just waiting = for v6 users. And in the same way, operators are also hesitating to deploy = v6 when there are very few existing v6 contents. This chicken and egg thing= is still ongoing, even we are running out IPv4 address.

After all, dual stack is what we have discussing for 10= years. But up to now, how many ICPs have upgraded to IPv6 in dual-stack di= rectly? I really think we need to re-think it again, from both technical as= pect and the industry/or market aspect. And the first step is rather import= ant to give us confidence to move forward. That's why we recommend sing= le-stack (either v4 or v6)=C2=A0transition=C2=A0in the current phase. Then,= for the conservative ones,=C2=A0the IPv4 services can be still offered nat= ively, and the IPv6 services can be offered by the stateful NAT64; while fo= r progressive ones and newly comers, the stateless IVI can be employed to o= ffer native IPv6 services reachable via IPv4. And we hope it would help enr= ich IPv6 content asap. Then how do you think ?

Thanks

Qiong


On Wed, Nov 2, 2011 at 4:16 AM, Bria= n E Carpenter <brian.e.carpenter@gmail.com> wrote:
I'm not seeing why this is a better sol= ution for a small/medium ICP
than just moving to a dual stack. That is much easier for a small
network than for a big one.

Regards
=C2=A0 Brian

--20cf301d424cca705204b0bc33c8-- From tore.anderson@redpill-linpro.com Wed Nov 2 02:05:36 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C109511E8129 for ; Wed, 2 Nov 2011 02:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RqdaZkrerAgi for ; Wed, 2 Nov 2011 02:05:36 -0700 (PDT) Received: from zimbra.redpill-linpro.com (zimbra.redpill-linpro.com [IPv6:2a02:c0:200:c000::1]) by ietfa.amsl.com (Postfix) with ESMTP id 145DB11E811E for ; Wed, 2 Nov 2011 02:05:35 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.redpill-linpro.com (Postfix) with ESMTP id 4B482103000F; Wed, 2 Nov 2011 10:05:34 +0100 (CET) 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 nGeEiRP4JVHG; Wed, 2 Nov 2011 10:05:33 +0100 (CET) Received: from echo.linpro.no (unknown [IPv6:2a02:c0:1002:102:21d:60ff:fe48:f59e]) by zimbra.redpill-linpro.com (Postfix) with ESMTPSA id DC1701030009; Wed, 2 Nov 2011 10:05:33 +0100 (CET) Message-ID: <4EB107DD.5070707@redpill-linpro.com> Date: Wed, 02 Nov 2011 10:05:33 +0100 From: Tore Anderson Organization: Redpill Linpro AS User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110927 Thunderbird/7.0 MIME-Version: 1.0 To: Brian E Carpenter References: <201110221355.p9MDt0M17687@ftpeng-update.cisco.com> <4EA7DC26.6020802@forthnetgroup.gr> <4EA87342.90305@gmail.com> <4EAB2233.8040908@gmail.com> <4EAB4856.2070002@dougbarton.us> <50CF70B9-3EAA-4897-9AF3-62A8D96C3EFB@cisco.com> <4EADB1C2.8000601@gmail.com> <4EAFB76D.7070208@redpill-linpro.com> <4EB0561C.7070507@gmail.com> In-Reply-To: <4EB0561C.7070507@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , "draft-carpenter-v6ops-icp-guidance@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-carpenter-v6ops-icp-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 Nov 2011 09:05:36 -0000 * Brian E Carpenter > Grumble. I don't like that conclusion, because it's clear that > the desired end point is native v6 and I don't see how your > approach gets us there. Native IPv6 on all servers and used by all applications running on those servers doesn't get us to native IPv6? Huh? :-) -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com From tore.anderson@redpill-linpro.com Wed Nov 2 02:22:36 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA1591F0C5F for ; Wed, 2 Nov 2011 02:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IzjU3Vm4ylNa for ; Wed, 2 Nov 2011 02:22:36 -0700 (PDT) Received: from zimbra.redpill-linpro.com (zimbra.redpill-linpro.com [IPv6:2a02:c0:200:c000::1]) by ietfa.amsl.com (Postfix) with ESMTP id D3C9111E80D9 for ; Wed, 2 Nov 2011 02:22:35 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.redpill-linpro.com (Postfix) with ESMTP id 31F32103000F; Wed, 2 Nov 2011 10:22:35 +0100 (CET) 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 MH4nMiycX2bM; Wed, 2 Nov 2011 10:22:34 +0100 (CET) Received: from echo.linpro.no (unknown [IPv6:2a02:c0:1002:102:21d:60ff:fe48:f59e]) by zimbra.redpill-linpro.com (Postfix) with ESMTPSA id AC4F31030009; Wed, 2 Nov 2011 10:22:34 +0100 (CET) Message-ID: <4EB10BDA.3060202@redpill-linpro.com> Date: Wed, 02 Nov 2011 10:22:34 +0100 From: Tore Anderson Organization: Redpill Linpro AS User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110927 Thunderbird/7.0 MIME-Version: 1.0 To: Mark Andrews References: <201110221355.p9MDt0M17687@ftpeng-update.cisco.com> <4EA7DC26.6020802@forthnetgroup.gr> <4EA87342.90305@gmail.com> <4EAB2233.8040908@gmail.com> <4EAB4856.2070002@dougbarton.us> <50CF70B9-3EAA-4897-9AF3-62A8D96C3EFB@cisco.com> <4EADB1C2.8000601@gmail.com> <4EAFB76D.7070208@redpill-linpro.com> <20111102071323.7821D16765EC@drugs.dv.isc.org> In-Reply-To: <20111102071323.7821D16765EC@drugs.dv.isc.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , "draft-carpenter-v6ops-icp-guidance@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-carpenter-v6ops-icp-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 Nov 2011 09:22:37 -0000 * Mark Andrews > In message <4EAFB76D.7070208@redpill-linpro.com>, Tore Anderson writes: >> >> In a purely technical sense, you might be right. However, I've come to >> realize that dual-stack is not really a viable transition approach for >> us, due to organizational and human considerations. I think the draft is >> intended exactly for organizations such as ours btw, as we're a >> small/medium-sized ICP. >> >> We have a team of people that works on the network infrastructure (of >> which I'm part), and several teams with sysadmins that operate the >> customers' servers, operating systems, and the applications running on >> them. While my colleagues and I are happy to promote IPv6 by always >> assigning an IPv6 prefix to all LANs that are requested by the server >> guys, their priorities are very different - they don't want to get >> involved more networking than absolutely necessary. So if I give them >> two IP stacks to work with, they'll choose one and leave the other one >> unused, and not surprisingly, the one they choose to work with is going >> to be the most familiar one - IPv4. >> >> I can understand it, too - dual stack is in a sense dual work and dual >> complexity. They'd need to configure ACLs twice, monitor everything >> twice, accept lots of new failure scenarios and so on. It's real >> operational overhead, and nobody really wants that. > > Our ops people would say you are exagerating the costs. Considering I didn't mention costs at all, I'm not sure how you came to that conclusion. I don't believe that dual stack mean you have to double your operations budget. The added technical complexity is the main problem for us, not costs. Not even an hour after I sent my previous e-mail yesterday, a colleague came over to me asking if I could look into why some accounting cron jobs had stopped working since last month. Turns out the problem was that a server had been recently dual-stacked, which caused a download job from another server (which had been dual-stacked for a long time) to fail, because the ACLs that allowed the download to happen over IPv4 wasn't properly duplicated in IPv6. Easy enough to fix, and fortunately not critical at all, but it's an example of a failure scenario you are open to only when running dual-stack. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com From marka@isc.org Wed Nov 2 04:12:28 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55CAB1F0C98 for ; Wed, 2 Nov 2011 04:12:28 -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.044, 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 X8zqr5cYZ1Zt for ; Wed, 2 Nov 2011 04:12:27 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 6A6591F0C8E for ; Wed, 2 Nov 2011 04:12:27 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 97E585F98BC; Wed, 2 Nov 2011 11:12:00 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id A72A9216C6A; Wed, 2 Nov 2011 11:11:58 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 8587F1678E96; Wed, 2 Nov 2011 22:11:44 +1100 (EST) To: Tore Anderson From: Mark Andrews References: <201110221355.p9MDt0M17687@ftpeng-update.cisco.com> <4EA7DC26.6020802@forthnetgroup.gr> <4EA87342.90305@gmail.com> <4EAB2233.8040908@gmail.com> <4EAB4856.2070002@dougbarton.us> <50CF70B9-3EAA-4897-9AF3-62A8D96C3EFB@cisco.com> <4EADB1C2.8000601@gmail.com> <4EAFB76D.7070208@redpill-linpro.com> <20111102071323.7821D16765EC@drugs.dv.isc.org> <4EB10BDA.3060202@redpill-linpro.com> In-reply-to: Your message of "Wed, 02 Nov 2011 10:22:34 BST." <4EB10BDA.3060202@redpill-linpro.com> Date: Wed, 02 Nov 2011 22:11:44 +1100 Message-Id: <20111102111144.8587F1678E96@drugs.dv.isc.org> Cc: "v6ops@ietf.org" , "draft-carpenter-v6ops-icp-guidance@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-carpenter-v6ops-icp-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 Nov 2011 11:12:28 -0000 In message <4EB10BDA.3060202@redpill-linpro.com>, Tore Anderson writes: > * Mark Andrews > > > In message <4EAFB76D.7070208@redpill-linpro.com>, Tore Anderson writes: > >> > >> In a purely technical sense, you might be right. However, I've come to > >> realize that dual-stack is not really a viable transition approach for > >> us, due to organizational and human considerations. I think the draft is > >> intended exactly for organizations such as ours btw, as we're a > >> small/medium-sized ICP. > >> > >> We have a team of people that works on the network infrastructure (of > >> which I'm part), and several teams with sysadmins that operate the > >> customers' servers, operating systems, and the applications running on > >> them. While my colleagues and I are happy to promote IPv6 by always > >> assigning an IPv6 prefix to all LANs that are requested by the server > >> guys, their priorities are very different - they don't want to get > >> involved more networking than absolutely necessary. So if I give them > >> two IP stacks to work with, they'll choose one and leave the other one > >> unused, and not surprisingly, the one they choose to work with is going > >> to be the most familiar one - IPv4. > >> > >> I can understand it, too - dual stack is in a sense dual work and dual > >> complexity. They'd need to configure ACLs twice, monitor everything > >> twice, accept lots of new failure scenarios and so on. It's real > >> operational overhead, and nobody really wants that. > > > > Our ops people would say you are exagerating the costs. > > Considering I didn't mention costs at all, I'm not sure how you came to > that conclusion. I don't believe that dual stack mean you have to double > your operations budget. The added technical complexity is the main > problem for us, not costs. > > Not even an hour after I sent my previous e-mail yesterday, a colleague > came over to me asking if I could look into why some accounting cron > jobs had stopped working since last month. Turns out the problem was > that a server had been recently dual-stacked, which caused a download > job from another server (which had been dual-stacked for a long time) to > fail, because the ACLs that allowed the download to happen over IPv4 > wasn't properly duplicated in IPv6. Easy enough to fix, and fortunately > not critical at all, but it's an example of a failure scenario you are > open to only when running dual-stack. I would suggest that your tools are not RFC 1123 compliant as they didn't cope with a multi-homed servers. This failure could have happened with IPv4 only. It's only been been 22 years since support for multi-homed servers was recommended. > Best regards, > -- > Tore Anderson > Redpill Linpro AS - http://www.redpill-linpro.com -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From john.mann@monash.edu Wed Nov 2 04:27:17 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9317911E80D9 for ; Wed, 2 Nov 2011 04:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.677 X-Spam-Level: X-Spam-Status: No, score=-5.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 gQVia+SgYsTd for ; Wed, 2 Nov 2011 04:27:16 -0700 (PDT) Received: from na3sys009aog126.obsmtp.com (na3sys009aog126.obsmtp.com [74.125.149.155]) by ietfa.amsl.com (Postfix) with ESMTP id 9E29811E808A for ; Wed, 2 Nov 2011 04:27:16 -0700 (PDT) Received: from mail-vx0-f170.google.com ([209.85.220.170]) (using TLSv1) by na3sys009aob126.postini.com ([74.125.148.12]) with SMTP; Wed, 02 Nov 2011 04:27:16 PDT Received: by vcbfl15 with SMTP id fl15so15712vcb.29 for ; Wed, 02 Nov 2011 04:27:02 -0700 (PDT) Received: by 10.182.119.2 with SMTP id kq2mr804783obb.41.1320233222070; Wed, 02 Nov 2011 04:27:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.193.102 with HTTP; Wed, 2 Nov 2011 04:26:41 -0700 (PDT) In-Reply-To: References: <4EB05384.5000007@gmail.com> From: John Mann Date: Wed, 2 Nov 2011 22:26:41 +1100 Message-ID: To: Qiong Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Fwd: New Version Notification for draft-sunq-v6ops-contents-transition-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, 02 Nov 2011 11:27:17 -0000 Hi, On 2 November 2011 19:23, Qiong wrote: > Hi Brian, > Thanks for your comments. > I agree that dual-stack is a very=A0straightforward=A0way to IPv6 and sho= uld be > recommended in general. But frankly, I think the situation we are facing > with seems much more complicated, sometimes beyond technical issues. Most > ICPs are still lacking of motivation to upgrade, just waiting for v6 user= s. > And in the same way, operators are also hesitating to deploy v6 when ther= e > are very few existing v6 contents. This chicken and egg thing is still > ongoing, even we are running out IPv4 address. > After all, dual stack is what we have discussing for 10 years. But up to > now, how many ICPs have upgraded to IPv6 in dual-stack directly? At Monash University, we dual-stacked the main web farm and most user subne= ts. Not much IPv6 traffic due to slow roll-out of (IPv6-enabled) Windows7 clien= ts. The big step increases in IPv6 traffic were due to a) Google over IPv6 whitelisting b) YouTube available over IPv6 Through our Internet border, we are now doing 600 GB/day (10%) IPv6 traffic inbound and 60 GB/day (1.5%) IPv6 traffic outbound. Google have broken the chicken v. egg impasse. Enable IPv6 on Facebook, other CDNs etc and we could have a lot of IPv6 tra= ffic! Thanks, John > I really > think we need to re-think it again, from both technical aspect and the > industry/or market aspect. And the first step is rather important to give= us > confidence to move forward. That's why we recommend single-stack (either = v4 > or v6)=A0transition=A0in the current phase. Then, for the conservative on= es,=A0the > IPv4 services can be still offered natively, and the IPv6 services can be > offered by the stateful NAT64; while for progressive ones and newly comer= s, > the stateless IVI can be employed to offer native IPv6 services reachable > via IPv4. And we hope it would help enrich IPv6 content asap. Then how do > you think ? > Thanks > Qiong > > On Wed, Nov 2, 2011 at 4:16 AM, Brian E Carpenter > wrote: >> >> I'm not seeing why this is a better solution for a small/medium ICP >> than just moving to a dual stack. That is much easier for a small >> network than for a big one. >> >> Regards >> =A0 Brian >> > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > From gert@space.net Wed Nov 2 07:08:59 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DECC21F8B85 for ; Wed, 2 Nov 2011 07:08:59 -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 oUKeJoPJpI0w for ; Wed, 2 Nov 2011 07:08:59 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id F1E2F21F8B77 for ; Wed, 2 Nov 2011 07:08:57 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id B1EA2F88B6 for ; Wed, 2 Nov 2011 15:08:56 +0100 (CET) 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 9E4DBF88AA for ; Wed, 2 Nov 2011 15:08:56 +0100 (CET) Received: (qmail 54872 invoked by uid 1007); 2 Nov 2011 15:08:56 +0100 Date: Wed, 2 Nov 2011 15:08:56 +0100 From: Gert Doering To: Mark Andrews Message-ID: <20111102140856.GS71280@Space.Net> References: <201110221355.p9MDt0M17687@ftpeng-update.cisco.com> <4EA7DC26.6020802@forthnetgroup.gr> <4EA87342.90305@gmail.com> <4EAB2233.8040908@gmail.com> <4EAB4856.2070002@dougbarton.us> <50CF70B9-3EAA-4897-9AF3-62A8D96C3EFB@cisco.com> <4EADB1C2.8000601@gmail.com> <4EAFB76D.7070208@redpill-linpro.com> <20111102071323.7821D16765EC@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111102071323.7821D16765EC@drugs.dv.isc.org> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "v6ops@ietf.org" , "draft-carpenter-v6ops-icp-guidance@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-carpenter-v6ops-icp-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 Nov 2011 14:08:59 -0000 Hi, On Wed, Nov 02, 2011 at 06:13:23PM +1100, Mark Andrews wrote: > Our ops people would say you are exagerating the costs. They have > 7+ years of dual stack experience. It's not zero but is close to > that. Speaking as an Ops person, I really, *really* want to get rid of dual-stack. Double address management, double monitoring, double testing for internal connections between machines (will it use v4 or v6 today?), double ACLing things, twice as many opportunities for people to make mistakes. Worse, if one of the protocols isn't set up right, you might not even notice it right away if the applications are using the other one today. I very much like Tore's approach. (I don't see us actually doing this any time soon - the network is not currently set up properly for that - but the idea of running everything IPv6-only with an IPv4 front-end proxy has lots of merits) 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 gert@space.net Wed Nov 2 07:10:05 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC9811E808A for ; Wed, 2 Nov 2011 07:10:04 -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 e2Be4udYi92z for ; Wed, 2 Nov 2011 07:10:03 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 33FEE11E80C2 for ; Wed, 2 Nov 2011 07:10:03 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 51262F88B6 for ; Wed, 2 Nov 2011 15:10:02 +0100 (CET) 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 2C08EF88A7 for ; Wed, 2 Nov 2011 15:10:02 +0100 (CET) Received: (qmail 55559 invoked by uid 1007); 2 Nov 2011 15:10:02 +0100 Date: Wed, 2 Nov 2011 15:10:02 +0100 From: Gert Doering To: Mark Andrews Message-ID: <20111102141002.GT71280@Space.Net> References: <4EA87342.90305@gmail.com> <4EAB2233.8040908@gmail.com> <4EAB4856.2070002@dougbarton.us> <50CF70B9-3EAA-4897-9AF3-62A8D96C3EFB@cisco.com> <4EADB1C2.8000601@gmail.com> <4EAFB76D.7070208@redpill-linpro.com> <20111102071323.7821D16765EC@drugs.dv.isc.org> <4EB10BDA.3060202@redpill-linpro.com> <20111102111144.8587F1678E96@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111102111144.8587F1678E96@drugs.dv.isc.org> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "v6ops@ietf.org" , "draft-carpenter-v6ops-icp-guidance@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-carpenter-v6ops-icp-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 Nov 2011 14:10:05 -0000 Hi, On Wed, Nov 02, 2011 at 10:11:44PM +1100, Mark Andrews wrote: > I would suggest that your tools are not RFC 1123 compliant as they > didn't cope with a multi-homed servers. This failure could have > happened with IPv4 only. It's only been been 22 years since support > for multi-homed servers was recommended. Cheap shot. "If you don't like the extra work something causes, it must be because you / your tools are not up for the job" 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 bingxuere@gmail.com Wed Nov 2 07:37:46 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F2C021F8CBD for ; Wed, 2 Nov 2011 07:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.971 X-Spam-Level: X-Spam-Status: No, score=-2.971 tagged_above=-999 required=5 tests=[AWL=0.027, 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 zJ-4JEKYMahg for ; Wed, 2 Nov 2011 07:37:45 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 75E4E21F8CA7 for ; Wed, 2 Nov 2011 07:37:45 -0700 (PDT) Received: by iaeo4 with SMTP id o4so248267iae.31 for ; Wed, 02 Nov 2011 07:37:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=6UTdSB63A58XhWpKlroCeFnG2CWHr06ago3a6lRt9Yc=; b=kfmy1TWhf9SieVYJCMsA1xverAeZnDt8iyX7pHP/I3k+eyiCEC35aAuygV7nvBQEB4 rX0abHiXjUXt9c/yLA9DaZY+8oznuZx4KGsTW4nQvknpfMp/AUxmXewvxM2VAbtpwRyE mCYj2b+kW00gK5SjapWHGK15BCtNlenY/mHpE= Received: by 10.42.163.200 with SMTP id d8mr1730780icy.41.1320244665093; Wed, 02 Nov 2011 07:37:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.218.10 with HTTP; Wed, 2 Nov 2011 07:37:04 -0700 (PDT) In-Reply-To: <20111102140856.GS71280@Space.Net> References: <201110221355.p9MDt0M17687@ftpeng-update.cisco.com> <4EA7DC26.6020802@forthnetgroup.gr> <4EA87342.90305@gmail.com> <4EAB2233.8040908@gmail.com> <4EAB4856.2070002@dougbarton.us> <50CF70B9-3EAA-4897-9AF3-62A8D96C3EFB@cisco.com> <4EADB1C2.8000601@gmail.com> <4EAFB76D.7070208@redpill-linpro.com> <20111102071323.7821D16765EC@drugs.dv.isc.org> <20111102140856.GS71280@Space.Net> From: Qiong Date: Wed, 2 Nov 2011 22:37:04 +0800 Message-ID: To: Gert Doering Content-Type: multipart/alternative; boundary=90e6ba6e89dc478d5704b0c16ac7 Cc: "v6ops@ietf.org" , "draft-carpenter-v6ops-icp-guidance@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-carpenter-v6ops-icp-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 Nov 2011 14:37:46 -0000 --90e6ba6e89dc478d5704b0c16ac7 Content-Type: text/plain; charset=UTF-8 Hi, Gert, On Wed, Nov 2, 2011 at 10:08 PM, Gert Doering wrote: > Hi, > > On Wed, Nov 02, 2011 at 06:13:23PM +1100, Mark Andrews wrote: > > Our ops people would say you are exagerating the costs. They have > > 7+ years of dual stack experience. It's not zero but is close to > > that. > > Speaking as an Ops person, I really, *really* want to get rid of > dual-stack. Double address management, double monitoring, double > testing for internal connections between machines (will it use v4 or > v6 today?), double ACLing things, twice as many opportunities for > people to make mistakes. Worse, if one of the protocols isn't set > up right, you might not even notice it right away if the applications > are using the other one today. > > I very much like Tore's approach. > > Fully agree. This is also what we are discussing in draft-sunq-v6ops-contents-transition-02, in which native IPv4/IPv6 server models are introduced. Looking forward to your comments as well. > (I don't see us actually doing this any time soon - the network is > not currently set up properly for that - but the idea of running > everything IPv6-only with an IPv4 front-end proxy has lots of merits) > > For IPv6-only server, stateless IVI can be deployed with good scalablity and application-independent feature. Best wishes Qiong 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 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --90e6ba6e89dc478d5704b0c16ac7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi,=C2=A0Gert,

On Wed, Nov 2, 2011 at 10:= 08 PM, Gert Doering <gert@space.net> wrote:
Hi,

On Wed, Nov 02, 2011 at 06:13:23PM +1100, Mark Andrews wrote:
> Our ops people would say you are exagerating the costs. =C2=A0They hav= e
> 7+ years of dual stack experience. =C2=A0It's not zero but is clos= e to
> that.

Speaking as an Ops person, I really, *really* want to get rid of
dual-stack. =C2=A0Double address management, double monitoring, double
testing for internal connections between machines (will it use v4 or
v6 today?), double ACLing things, twice as many opportunities for
people to make mistakes. =C2=A0Worse, if one of the protocols isn't set=
up right, you might not even notice it right away if the applications
are using the other one today.

I very much like Tore's approach.

Fully agree. This is also what we are discussing in d= raft-sunq-v6ops-contents-transition-02, in which native IPv4/IPv6 server mo= dels are introduced. Looking forward to your comments as well. =C2=A0
=C2=A0
(I don't see us actually doing this any time soon - the network is
not currently set up properly for that - but the idea of running
everything IPv6-only with an IPv4 front-end proxy has lots of merits)

For IPv6-only server, stateless IVI can be deployed w= ith good scalablity and application-independent feature.

Best wishes=C2=A0

Qiong


Gert Doering
=C2=A0 =C2=A0 =C2=A0 =C2=A0-- NetMaster
--
have you enabled IPv6 on something today...?

SpaceNet AG =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Aufsichtsratsvo= rs.: A. Grundner-Culemann
D-80807 Muenchen =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0USt-IdNr.:= DE813185279
__________________________________= _____________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

--90e6ba6e89dc478d5704b0c16ac7-- From cb.list6@gmail.com Wed Nov 2 08:03:10 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69CF21F0C72 for ; Wed, 2 Nov 2011 08:03:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.644 X-Spam-Level: X-Spam-Status: No, score=-2.644 tagged_above=-999 required=5 tests=[AWL=0.354, 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 37raToGWiK+A for ; Wed, 2 Nov 2011 08:03:09 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 878D51F0C6B for ; Wed, 2 Nov 2011 08:03:09 -0700 (PDT) Received: by qadc10 with SMTP id c10so323743qad.31 for ; Wed, 02 Nov 2011 08:03:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GZQZz8C/6095/bvAcn9xOHzc/+jy9u3iNEkzOWbHDxY=; b=K4hFUM56ooCA/q+Vv2CqWcyQL7B+85K6Uezly8mgAM03TbyPEFywHC00+joWDH4ugE daTCSkPqXRZu4lgMXCWnvGux9LRymXrjOiOnHwxuBMQ3Eki8glg5LGX0YzUx+ohy24tn Jb+RByBdJqxoT/jm0RJ3nNl0yV/o8YWGqSjJQ= MIME-Version: 1.0 Received: by 10.68.38.100 with SMTP id f4mr5375484pbk.62.1320246188624; Wed, 02 Nov 2011 08:03:08 -0700 (PDT) Received: by 10.142.230.8 with HTTP; Wed, 2 Nov 2011 08:03:08 -0700 (PDT) Received: by 10.142.230.8 with HTTP; Wed, 2 Nov 2011 08:03:08 -0700 (PDT) In-Reply-To: References: <4EB05384.5000007@gmail.com> Date: Wed, 2 Nov 2011 08:03:08 -0700 Message-ID: From: Cameron Byrne To: Qiong Content-Type: multipart/alternative; boundary=bcaec520f05316c9fc04b0c1c589 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Fwd: New Version Notification for draft-sunq-v6ops-contents-transition-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, 02 Nov 2011 15:03:10 -0000 --bcaec520f05316c9fc04b0c1c589 Content-Type: text/plain; charset=ISO-8859-1 On Nov 2, 2011 1:25 AM, "Qiong" wrote: > > Hi Brian, > > Thanks for your comments. > > I agree that dual-stack is a very straightforward way to IPv6 and should be recommended in general. But frankly, I think the situation we are facing with seems much more complicated, sometimes beyond technical issues. Most ICPs are still lacking of motivation to upgrade, just waiting for v6 users. And in the same way, operators are also hesitating to deploy v6 when there are very few existing v6 contents. This chicken and egg thing is still ongoing, even we are running out IPv4 address. > > After all, dual stack is what we have discussing for 10 years. But up to now, how many ICPs have upgraded to IPv6 in dual-stack directly? I really think we need to re-think it again, from both technical aspect and the industry/or market aspect. And the first step is rather important to give us confidence to move forward. That's why we recommend single-stack (either v4 or v6) transition in the current phase. Then, for the conservative ones, the IPv4 services can be still offered natively, and the IPv6 services can be offered by the stateful NAT64; while for progressive ones and newly comers, the stateless IVI can be employed to offer native IPv6 services reachable via IPv4. And we hope it would help enrich IPv6 content asap. Then how do you think ? > I agree with concerns here. My understanding is that: Content = cloud (many many horizontally scaled servers) Users = many devices (phone, tablet, pc, ...) Free ipv4 is less than near term cloud + many devices That said, there is going to be a lot of MARKET pressure for content to be reachable end to end given that there will be many single stacks on each side of the internet I don't have any conclusion beyond agreeing with Qiong that simple dual-stack cannot work since cloud and devices exceed the ipv4 addresses to service them. Cb Ps. I remain very concerned about the digital divide impacts of ipv4 markets. IETF needs to take a more bold stance on ipv6-single stacking, otherwise we are just creating a stronger market for ipv4 addresses, widening the digital divide , and increasing cost of all involved. > Thanks > > Qiong > > > On Wed, Nov 2, 2011 at 4:16 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: >> >> I'm not seeing why this is a better solution for a small/medium ICP >> than just moving to a dual stack. That is much easier for a small >> network than for a big one. >> >> Regards >> Brian >> > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --bcaec520f05316c9fc04b0c1c589 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Nov 2, 2011 1:25 AM, "Qiong" <bingxuere@gmail.com> wrote:
>
> Hi Brian,
>
> Thanks for your comments.
>
> I agree that dual-stack is a very=A0straightforward=A0way to IPv6 and = should be recommended in general. But frankly, I think the situation we are= facing with seems much more complicated, sometimes beyond technical issues= . Most ICPs are still lacking of motivation to upgrade, just waiting for v6= users. And in the same way, operators are also hesitating to deploy v6 whe= n there are very few existing v6 contents. This chicken and egg thing is st= ill ongoing, even we are running out IPv4 address.
>
> After all, dual stack is what we have discussing for 10 years. But up = to now, how many ICPs have upgraded to IPv6 in dual-stack directly? I reall= y think we need to re-think it again, from both technical aspect and the in= dustry/or market aspect. And the first step is rather important to give us = confidence to move forward. That's why we recommend single-stack (eithe= r v4 or v6)=A0transition=A0in the current phase. Then, for the conservative= ones,=A0the IPv4 services can be still offered natively, and the IPv6 serv= ices can be offered by the stateful NAT64; while for progressive ones and n= ewly comers, the stateless IVI can be employed to offer native IPv6 service= s reachable via IPv4. And we hope it would help enrich IPv6 content asap. T= hen how do you think ?
>

I agree with concerns here. My understanding is that:

Content =3D cloud (many many horizontally scaled servers)

Users =3D many devices (phone, tablet, pc, ...)

Free ipv4 is less than near term cloud + many devices

That said, there is going to be a lot of MARKET pressure for content to = be reachable end to end given that there will be many single stacks on each= side of the internet

I don't have any conclusion beyond agreeing with Qiong that simple d= ual-stack cannot work since cloud and devices exceed the ipv4 addresses to = service them.

Cb

Ps. I remain very concerned about the digital divide impacts of ipv4 mar= kets. IETF needs to take a more bold stance on ipv6-single stacking, otherw= ise we are just creating a stronger market for ipv4 addresses,=A0 widening = the digital divide , and increasing cost of all involved.

> Thanks
>
> Qiong
>
>
> On Wed, Nov 2, 2011 at 4:16 AM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote: >>
>> I'm not seeing why this is a better solution for a small/mediu= m ICP
>> than just moving to a dual stack. That is much easier for a small<= br> >> network than for a big one.
>>
>> Regards
>> =A0 Brian
>>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops
>

--bcaec520f05316c9fc04b0c1c589-- From cb.list6@gmail.com Wed Nov 2 08:13:35 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00B1B11E80B6 for ; Wed, 2 Nov 2011 08:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.664 X-Spam-Level: X-Spam-Status: No, score=-2.664 tagged_above=-999 required=5 tests=[AWL=0.334, 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 EomKv04szFde for ; Wed, 2 Nov 2011 08:13:34 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id D33B811E8090 for ; Wed, 2 Nov 2011 08:13:33 -0700 (PDT) Received: by qadc10 with SMTP id c10so337925qad.31 for ; Wed, 02 Nov 2011 08:13:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UlxAIrmJs9DUImBOXpo0DGRDbaddByghieY3LAHPRwo=; b=ACuwRTKEniLsdIpWXuuVfhszxnydePE6Z1cfYerv2+aoP+GQmj0+m9i9W6f8pYS3Ip xErzdjDKeZ/NWInCOCMCfrOcaQqJqVjJbmWJfrD6eaLZ53Y0ugjO6gCPG4kyrMgKypWm T0wCo+2q++FnAcdr0cP4WHYjVfW4msaP1Or1I= MIME-Version: 1.0 Received: by 10.68.38.100 with SMTP id f4mr5428999pbk.62.1320246812881; Wed, 02 Nov 2011 08:13:32 -0700 (PDT) Received: by 10.142.230.8 with HTTP; Wed, 2 Nov 2011 08:13:32 -0700 (PDT) Received: by 10.142.230.8 with HTTP; Wed, 2 Nov 2011 08:13:32 -0700 (PDT) In-Reply-To: <4EB10BDA.3060202@redpill-linpro.com> References: <201110221355.p9MDt0M17687@ftpeng-update.cisco.com> <4EA7DC26.6020802@forthnetgroup.gr> <4EA87342.90305@gmail.com> <4EAB2233.8040908@gmail.com> <4EAB4856.2070002@dougbarton.us> <50CF70B9-3EAA-4897-9AF3-62A8D96C3EFB@cisco.com> <4EADB1C2.8000601@gmail.com> <4EAFB76D.7070208@redpill-linpro.com> <20111102071323.7821D16765EC@drugs.dv.isc.org> <4EB10BDA.3060202@redpill-linpro.com> Date: Wed, 2 Nov 2011 08:13:32 -0700 Message-ID: From: Cameron Byrne To: Tore Anderson Content-Type: multipart/alternative; boundary=bcaec520f0534c332804b0c1ea70 Cc: "v6ops@ietf.org" , "draft-carpenter-v6ops-icp-guidance@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-carpenter-v6ops-icp-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 Nov 2011 15:13:35 -0000 --bcaec520f0534c332804b0c1ea70 Content-Type: text/plain; charset=ISO-8859-1 On Nov 2, 2011 2:22 AM, "Tore Anderson" wrote: > > * Mark Andrews > > > In message <4EAFB76D.7070208@redpill-linpro.com>, Tore Anderson writes: > >> > >> In a purely technical sense, you might be right. However, I've come to > >> realize that dual-stack is not really a viable transition approach for > >> us, due to organizational and human considerations. I think the draft is > >> intended exactly for organizations such as ours btw, as we're a > >> small/medium-sized ICP. > >> > >> We have a team of people that works on the network infrastructure (of > >> which I'm part), and several teams with sysadmins that operate the > >> customers' servers, operating systems, and the applications running on > >> them. While my colleagues and I are happy to promote IPv6 by always > >> assigning an IPv6 prefix to all LANs that are requested by the server > >> guys, their priorities are very different - they don't want to get > >> involved more networking than absolutely necessary. So if I give them > >> two IP stacks to work with, they'll choose one and leave the other one > >> unused, and not surprisingly, the one they choose to work with is going > >> to be the most familiar one - IPv4. > >> > >> I can understand it, too - dual stack is in a sense dual work and dual > >> complexity. They'd need to configure ACLs twice, monitor everything > >> twice, accept lots of new failure scenarios and so on. It's real > >> operational overhead, and nobody really wants that. > > > > Our ops people would say you are exagerating the costs. > > Considering I didn't mention costs at all, I'm not sure how you came to > that conclusion. I don't believe that dual stack mean you have to double > your operations budget. The added technical complexity is the main > problem for us, not costs. > > Not even an hour after I sent my previous e-mail yesterday, a colleague > came over to me asking if I could look into why some accounting cron > jobs had stopped working since last month. Turns out the problem was > that a server had been recently dual-stacked, which caused a download > job from another server (which had been dual-stacked for a long time) to > fail, because the ACLs that allowed the download to happen over IPv4 > wasn't properly duplicated in IPv6. Easy enough to fix, and fortunately > not critical at all, but it's an example of a failure scenario you are > open to only when running dual-stack. > In case folks want to know the hard cold cash cost of using ipv4, ask Microsoft http://www.bbc.co.uk/news/technology-12859585 Consider that the floor price, now that it went through, the model is proven and prices will rise. Ipv6 is essentially free, especially on a per address basis :-) Not only that, the ROI timescale for ipv6 payback on initial investments is as long as you think ipv6 will be around. Ipv4 payback ...not quite as long. Cb > Best regards, > -- > Tore Anderson > Redpill Linpro AS - http://www.redpill-linpro.com > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --bcaec520f0534c332804b0c1ea70 Content-Type: text/html; charset=ISO-8859-1


On Nov 2, 2011 2:22 AM, "Tore Anderson" <tore.anderson@redpill-linpro.com> wrote:
>
> * Mark Andrews
>
> > In message <4EAFB76D.7070208@redpill-linpro.com>, Tore Anderson writes:
> >>
> >> In a purely technical sense, you might be right. However, I've come to
> >> realize that dual-stack is not really a viable transition approach for
> >> us, due to organizational and human considerations. I think the draft is
> >> intended exactly for organizations such as ours btw, as we're a
> >> small/medium-sized ICP.
> >>
> >> We have a team of people that works on the network infrastructure (of
> >> which I'm part), and several teams with sysadmins that operate the
> >> customers' servers, operating systems, and the applications running on
> >> them. While my colleagues and I are happy to promote IPv6 by always
> >> assigning an IPv6 prefix to all LANs that are requested by the server
> >> guys, their priorities are very different - they don't want to get
> >> involved more networking than absolutely necessary. So if I give them
> >> two IP stacks to work with, they'll choose one and leave the other one
> >> unused, and not surprisingly, the one they choose to work with is going
> >> to be the most familiar one - IPv4.
> >>
> >> I can understand it, too - dual stack is in a sense dual work and dual
> >> complexity. They'd need to configure ACLs twice, monitor everything
> >> twice, accept lots of new failure scenarios and so on. It's real
> >> operational overhead, and nobody really wants that.
> >
> > Our ops people would say you are exagerating the costs.
>
> Considering I didn't mention costs at all, I'm not sure how you came to
> that conclusion. I don't believe that dual stack mean you have to double
> your operations budget. The added technical complexity is the main
> problem for us, not costs.
>
> Not even an hour after I sent my previous e-mail yesterday, a colleague
> came over to me asking if I could look into why some accounting cron
> jobs had stopped working since last month. Turns out the problem was
> that a server had been recently dual-stacked, which caused a download
> job from another server (which had been dual-stacked for a long time) to
> fail, because the ACLs that allowed the download to happen over IPv4
> wasn't properly duplicated in IPv6. Easy enough to fix, and fortunately
> not critical at all, but it's an example of a failure scenario you are
> open to only when running dual-stack.
>

In case folks want to know the hard cold cash cost of using ipv4, ask Microsoft

http://www.bbc.co.uk/news/technology-12859585

Consider that the floor price, now that it went through, the model is proven and prices will rise.

Ipv6 is essentially free, especially on a per address basis :-)

Not only that, the ROI timescale for ipv6 payback on initial investments is as long as you think ipv6 will be around. Ipv4 payback ...not quite as long.

Cb

> Best regards,
> --
> Tore Anderson
> Redpill Linpro AS - http://www.redpill-linpro.com
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

--bcaec520f0534c332804b0c1ea70-- From bingxuere@gmail.com Wed Nov 2 09:19:59 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79C6811E80C4 for ; Wed, 2 Nov 2011 09:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.973 X-Spam-Level: X-Spam-Status: No, score=-2.973 tagged_above=-999 required=5 tests=[AWL=0.025, 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 53h27n2QH6MH for ; Wed, 2 Nov 2011 09:19:58 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1D3FF1F0C9E for ; Wed, 2 Nov 2011 09:19:58 -0700 (PDT) Received: by iaeo4 with SMTP id o4so380447iae.31 for ; Wed, 02 Nov 2011 09:19:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=poy7hsnaHt0QaXUmS6p94LETadfzFMyzztbHYQA3vO0=; b=c1ulQOm2gT7MnXmbfdnNBWfnQWtto1iyBR1ZOJ8zDUM59mmDzIMXczoF5OcqUFRIRv zLHS0nSiBLtbEmaODDM21CNyogJzc4ijqg9MhQ/T/a3r1f3qlBTW8cH1WI2Cp19u689o SxAGNfxslK+mN9lVg3qL4BqRj6w4qv76q0h/E= Received: by 10.42.155.1 with SMTP id s1mr300966icw.33.1320250797209; Wed, 02 Nov 2011 09:19:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.218.10 with HTTP; Wed, 2 Nov 2011 09:19:16 -0700 (PDT) In-Reply-To: References: <4EB05384.5000007@gmail.com> From: Qiong Date: Thu, 3 Nov 2011 00:19:16 +0800 Message-ID: To: John Mann Content-Type: multipart/alternative; boundary=90e6ba6e8440c838bd04b0c2d79c Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Fwd: New Version Notification for draft-sunq-v6ops-contents-transition-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, 02 Nov 2011 16:19:59 -0000 --90e6ba6e8440c838bd04b0c2d79c Content-Type: text/plain; charset=UTF-8 Hi, John, Thanks. Please see inline. On Wed, Nov 2, 2011 at 7:26 PM, John Mann wrote: > Hi, > > At Monash University, we dual-stacked the main web farm and most user > subnets. > Not much IPv6 traffic due to slow roll-out of (IPv6-enabled) Windows7 > clients. > > The big step increases in IPv6 traffic were due to > a) Google over IPv6 whitelisting > b) YouTube available over IPv6 > Does Google upgrade all their services directly on IPv6, or use some kind of translation or proxy mechanism within its servers? I heard that Youtube has adopted LISP+NAT64 for its own transition, and Yahoo has also deployed several translation POPs around the world. I'm not sure whether it is correct or not. Please correct me if I'm wrong :) Of course, google is a very good example and we all hope many other ICPs will follow it in a short time. > > Through our Internet border, we are now doing 600 GB/day (10%) IPv6 > traffic inbound > and 60 GB/day (1.5%) IPv6 traffic outbound. > > Google have broken the chicken v. egg impasse. > Enable IPv6 on Facebook, other CDNs etc and we could have a lot of IPv6 > traffic! > Very good news! I believe the traffic volume is the most exciting info for us. In China, we also have a great volume of IPv6 traffic in CERNET2 (China Education Network for next generation Internet), which is a IPv6-only core-network. We have a lot of IPv6 contents including videos, BT, forums, etc, and the preference policy over IPv6 is applied here. As indicated in our draft (Appendix 1.1), more than 91 percent of our IPv6 users come from CERNET2. However, from operator perspective, I still think the situation here is a little bit different in commercial network. Since operator itself is for earning money rather than doing research, it would be more harder to persuade market people when there is no explicit value for them. After all, IPv6 deployment will cost quite a lot in the short run. So a simple question would just come out, why should we invest so much when there is still little reachable IPv6 content. In the same way, ICPs are also waiting for IPv6 users. In our situation, although we already have quite a lot of CERNET2 IPv6 users, it is still far from enough to convince a majority of ICPs upgrading to IPv6 directly. We all expect that ICPs would have the same belief with us, that IPv6 is definitely the future direction, but here we should make things happen at the first step. Anyway, we believe that ICP transition is the key point to IPv6 success. Best wishes Qiong Thanks, > John > > > I really > > think we need to re-think it again, from both technical aspect and the > > industry/or market aspect. And the first step is rather important to > give us > > confidence to move forward. That's why we recommend single-stack (either > v4 > > or v6) transition in the current phase. Then, for the conservative > ones, the > > IPv4 services can be still offered natively, and the IPv6 services can be > > offered by the stateful NAT64; while for progressive ones and newly > comers, > > the stateless IVI can be employed to offer native IPv6 services reachable > > via IPv4. And we hope it would help enrich IPv6 content asap. Then how do > > you think ? > > Thanks > > Qiong > > > > On Wed, Nov 2, 2011 at 4:16 AM, Brian E Carpenter > > wrote: > >> > >> I'm not seeing why this is a better solution for a small/medium ICP > >> than just moving to a dual stack. That is much easier for a small > >> network than for a big one. > >> > >> Regards > >> Brian > >> > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > > > --90e6ba6e8440c838bd04b0c2d79c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, John,


Thanks. Please see inline.=


On Wed,= Nov 2, 2011 at 7:26 PM, John Mann <john.mann@monash.edu>= wrote:
Hi,

At Monash University, we dual-stacked the main web farm and most u= ser subnets.
Not much IPv6 traffic due to slow roll-out of (IPv6-enabled) Windows7 clien= ts.

The big step increases in IPv6 traffic were due to
a) Google over IPv6 whitelisting
b) YouTube available over IPv6

Does Goo= gle upgrade all their services directly on IPv6, or use some kind of transl= ation or proxy mechanism within its servers? I heard that Youtube has adopt= ed LISP+NAT64 for its own transition, and Yahoo has also deployed several t= ranslation POPs around the world. I'm not sure whether it is correct or= not. Please correct me if I'm wrong :)
Of course, google is a very good example and we all hope many other IC= Ps will follow it in a short time.
=C2=A0

Through our Internet border, we are now doing 600 GB/day (10%) IPv6
traffic inbound
and 60 GB/day (1.5%) IPv6 traffic outbound.

Google have broken the chicken v. egg impasse.
Enable IPv6 on Facebook, other CDNs etc and we could have a lot of IPv6 tra= ffic!
=C2=A0
Very good news! I believe = the traffic volume is the most exciting info for us. In China, we also have= a great volume of IPv6 traffic in CERNET2 (China Education Network for nex= t generation Internet), which is a IPv6-only core-network. We have a lot of= IPv6 contents including videos, BT, forums, etc, and the preference policy= over IPv6 is applied here. As indicated in our draft (Appendix 1.1), more = than 91 percent of our IPv6 users come from CERNET2.

However, from operator perspective, I still think the s= ituation here is a little bit different in commercial network. Since operat= or itself is for earning money rather than doing research, it would be more= harder to persuade market people when there is no explicit value for them.= After all, IPv6 deployment will cost quite a lot in the short run. So a si= mple question would just come out, why should we invest so much when there = is still little reachable IPv6 content.
In the same way, ICPs are also waiting for IPv6 users. In our situatio= n, although we already have quite a lot of CERNET2 IPv6 users, it is still = far from enough to convince a majority of ICPs upgrading to IPv6 directly. = We all expect that ICPs would have the same belief with us, that IPv6 is de= finitely the future direction, but here we should make things happen at the= first step. Anyway, we believe that ICP transition is the key point to IPv= 6 success.

Best wishes

Qiong=C2=A0
<= /div>
=C2=A0=C2=A0=C2=A0

Thanks,
=C2=A0 =C2=A0John

> =C2=A0I really
> think we need to re-think it again, from both technical aspect and the=
> industry/or market aspect. And the first step is rather important to g= ive us
> confidence to move forward. That's why we recommend single-stack (= either v4
> or v6)=C2=A0transition=C2=A0in the current phase. Then, for the conser= vative ones,=C2=A0the
> IPv4 services can be still offered natively, and the IPv6 services can= be
> offered by the stateful NAT64; while for progressive ones and newly co= mers,
> the stateless IVI can be employed to offer native IPv6 services reacha= ble
> via IPv4. And we hope it would help enrich IPv6 content asap. Then how= do
> you think ?
> Thanks
> Qiong
>
> On Wed, Nov 2, 2011 at 4:16 AM, Brian E Carpenter
> <b= rian.e.carpenter@gmail.com> wrote:
>>
>> I'm not seeing why this is a better solution for a small/mediu= m ICP
>> than just moving to a dual stack. That is much easier for a small<= br> >> network than for a big one.
>>
>> Regards
>> =C2=A0 Brian
>>
>
> ___________________________________________= ____
> v6ops mailing list
> v6ops@ietf.org=
> https://www.ietf.org/mailman/listinfo/v6ops
>
>

--90e6ba6e8440c838bd04b0c2d79c-- From sarikaya2012@gmail.com Wed Nov 2 12:38:47 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC4F61F0C44 for ; Wed, 2 Nov 2011 12:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.137 X-Spam-Level: X-Spam-Status: No, score=-3.137 tagged_above=-999 required=5 tests=[AWL=-0.139, 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 Vsq5s+6hL2O0 for ; Wed, 2 Nov 2011 12:38:46 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 973861F0CAC for ; Wed, 2 Nov 2011 12:38:46 -0700 (PDT) Received: by gye5 with SMTP id 5so541232gye.31 for ; Wed, 02 Nov 2011 12:38:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=vLv5z8JshKnVfgg5cfDY6iHpLnYmC8M7wEFebGhtTn0=; b=ec3pnQEzerH9qD5lWqWZKGNIEIO9RrhjRiJcqdyOO3OQqfLDTKw7BAtn1lh8cd9MnT 8RPFz6TS+Wq6T9PEwUBO9RABESjZKwAU5WxDcmFXyOywEB+WrcV+L/r8kU7lmHnPqnTg aiT4nZ+v18RKOiNUhrWA3OD5lqjSMvXSG/OH0= MIME-Version: 1.0 Received: by 10.236.192.233 with SMTP id i69mr9305638yhn.60.1320262724114; Wed, 02 Nov 2011 12:38:44 -0700 (PDT) Received: by 10.236.108.135 with HTTP; Wed, 2 Nov 2011 12:38:44 -0700 (PDT) In-Reply-To: References: <201110221355.p9MDt0M17687@ftpeng-update.cisco.com> <4EA7DC26.6020802@forthnetgroup.gr> <4EA87342.90305@gmail.com> <4EAB2233.8040908@gmail.com> <4EAB4856.2070002@dougbarton.us> <50CF70B9-3EAA-4897-9AF3-62A8D96C3EFB@cisco.com> <4EADB1C2.8000601@gmail.com> <4EAFB76D.7070208@redpill-linpro.com> <20111102071323.7821D16765EC@drugs.dv.isc.org> <4EB10BDA.3060202@redpill-linpro.com> Date: Wed, 2 Nov 2011 14:38:44 -0500 Message-ID: From: Behcet Sarikaya To: Cameron Byrne Content-Type: multipart/alternative; boundary=20cf3056431fae5abe04b0c59ef2 Cc: "v6ops@ietf.org" , "draft-carpenter-v6ops-icp-guidance@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-carpenter-v6ops-icp-guidance 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, 02 Nov 2011 19:38:47 -0000 --20cf3056431fae5abe04b0c59ef2 Content-Type: text/plain; charset=ISO-8859-1 This part of the news is scary: Registries that oversee the allocation of net addresses are also working on plans for a re-circulation system that takes IPv4 addresses from firms that are using IPv6 and releases them for use by others. On Wed, Nov 2, 2011 at 10:13 AM, Cameron Byrne wrote: > > On Nov 2, 2011 2:22 AM, "Tore Anderson" > wrote: > > > > * Mark Andrews > > > > > In message <4EAFB76D.7070208@redpill-linpro.com>, Tore Anderson > writes: > > >> > > >> In a purely technical sense, you might be right. However, I've come to > > >> realize that dual-stack is not really a viable transition approach for > > >> us, due to organizational and human considerations. I think the draft > is > > >> intended exactly for organizations such as ours btw, as we're a > > >> small/medium-sized ICP. > > >> > > >> We have a team of people that works on the network infrastructure (of > > >> which I'm part), and several teams with sysadmins that operate the > > >> customers' servers, operating systems, and the applications running on > > >> them. While my colleagues and I are happy to promote IPv6 by always > > >> assigning an IPv6 prefix to all LANs that are requested by the server > > >> guys, their priorities are very different - they don't want to get > > >> involved more networking than absolutely necessary. So if I give them > > >> two IP stacks to work with, they'll choose one and leave the other one > > >> unused, and not surprisingly, the one they choose to work with is > going > > >> to be the most familiar one - IPv4. > > >> > > >> I can understand it, too - dual stack is in a sense dual work and dual > > >> complexity. They'd need to configure ACLs twice, monitor everything > > >> twice, accept lots of new failure scenarios and so on. It's real > > >> operational overhead, and nobody really wants that. > > > > > > Our ops people would say you are exagerating the costs. > > > > Considering I didn't mention costs at all, I'm not sure how you came to > > that conclusion. I don't believe that dual stack mean you have to double > > your operations budget. The added technical complexity is the main > > problem for us, not costs. > > > > Not even an hour after I sent my previous e-mail yesterday, a colleague > > came over to me asking if I could look into why some accounting cron > > jobs had stopped working since last month. Turns out the problem was > > that a server had been recently dual-stacked, which caused a download > > job from another server (which had been dual-stacked for a long time) to > > fail, because the ACLs that allowed the download to happen over IPv4 > > wasn't properly duplicated in IPv6. Easy enough to fix, and fortunately > > not critical at all, but it's an example of a failure scenario you are > > open to only when running dual-stack. > > > > In case folks want to know the hard cold cash cost of using ipv4, ask > Microsoft > > http://www.bbc.co.uk/news/technology-12859585 > > Consider that the floor price, now that it went through, the model is > proven and prices will rise. > > Ipv6 is essentially free, especially on a per address basis :-) > > Not only that, the ROI timescale for ipv6 payback on initial investments > is as long as you think ipv6 will be around. Ipv4 payback ...not quite as > long. > > Cb > > > Best regards, > > -- > > Tore Anderson > > Redpill Linpro AS - http://www.redpill-linpro.com > > _______________________________________________ > > 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 > > --20cf3056431fae5abe04b0c59ef2 Content-Type: text/html; charset=ISO-8859-1 This part of the news is scary:

Registries that oversee the allocation of net addresses are also working on plans for a re-circulation system that takes IPv4 addresses from firms that are using IPv6 and releases them for use by others.

On Wed, Nov 2, 2011 at 10:13 AM, Cameron Byrne <cb.list6@gmail.com> wrote:


On Nov 2, 2011 2:22 AM, "Tore Anderson" <tore.anderson@redpill-linpro.com> wrote:
>
> * Mark Andrews
>
> > In message <4EAFB76D.7070208@redpill-linpro.com>, Tore Anderson writes:
> >>
> >> In a purely technical sense, you might be right. However, I've come to
> >> realize that dual-stack is not really a viable transition approach for
> >> us, due to organizational and human considerations. I think the draft is
> >> intended exactly for organizations such as ours btw, as we're a
> >> small/medium-sized ICP.
> >>
> >> We have a team of people that works on the network infrastructure (of
> >> which I'm part), and several teams with sysadmins that operate the
> >> customers' servers, operating systems, and the applications running on
> >> them. While my colleagues and I are happy to promote IPv6 by always
> >> assigning an IPv6 prefix to all LANs that are requested by the server
> >> guys, their priorities are very different - they don't want to get
> >> involved more networking than absolutely necessary. So if I give them
> >> two IP stacks to work with, they'll choose one and leave the other one
> >> unused, and not surprisingly, the one they choose to work with is going
> >> to be the most familiar one - IPv4.
> >>
> >> I can understand it, too - dual stack is in a sense dual work and dual
> >> complexity. They'd need to configure ACLs twice, monitor everything
> >> twice, accept lots of new failure scenarios and so on. It's real
> >> operational overhead, and nobody really wants that.
> >
> > Our ops people would say you are exagerating the costs.
>
> Considering I didn't mention costs at all, I'm not sure how you came to
> that conclusion. I don't believe that dual stack mean you have to double
> your operations budget. The added technical complexity is the main
> problem for us, not costs.
>
> Not even an hour after I sent my previous e-mail yesterday, a colleague
> came over to me asking if I could look into why some accounting cron
> jobs had stopped working since last month. Turns out the problem was
> that a server had been recently dual-stacked, which caused a download
> job from another server (which had been dual-stacked for a long time) to
> fail, because the ACLs that allowed the download to happen over IPv4
> wasn't properly duplicated in IPv6. Easy enough to fix, and fortunately
> not critical at all, but it's an example of a failure scenario you are
> open to only when running dual-stack.
>

In case folks want to know the hard cold cash cost of using ipv4, ask Microsoft

http://www.bbc.co.uk/news/technology-12859585

Consider that the floor price, now that it went through, the model is proven and prices will rise.

Ipv6 is essentially free, especially on a per address basis :-)

Not only that, the ROI timescale for ipv6 payback on initial investments is as long as you think ipv6 will be around. Ipv4 payback ...not quite as long.

Cb

> Best regards,
> --
> Tore Anderson
> Redpill Linpro AS - http://www.redpill-linpro.com
> _______________________________________________
> 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


--20cf3056431fae5abe04b0c59ef2-- From lorenzo@google.com Wed Nov 2 12:42:17 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E43FC11E8152 for ; Wed, 2 Nov 2011 12:42:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[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 1tFLd-igML3S for ; Wed, 2 Nov 2011 12:42:17 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id CFFD111E8187 for ; Wed, 2 Nov 2011 12:42:16 -0700 (PDT) Received: by gye5 with SMTP id 5so544630gye.31 for ; Wed, 02 Nov 2011 12:42:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=/E9/sRzf50KTmDCfyLu4mrH2CbAgw0ORHyh6sSuAAR4=; b=b9o2XqtiLOMDFoRtRYnObLQPylRxAnXGnAuJnqC/MIFKg7ASw32mOJDHr4A4lCPc/f 6jXFD1bnB13DeElkmhZA== Received: by 10.150.113.18 with SMTP id l18mr6769784ybc.45.1320262936330; Wed, 02 Nov 2011 12:42:16 -0700 (PDT) Received: by 10.150.113.18 with SMTP id l18mr6769766ybc.45.1320262936133; Wed, 02 Nov 2011 12:42:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.202.14 with HTTP; Wed, 2 Nov 2011 12:41:55 -0700 (PDT) In-Reply-To: <20111102111144.8587F1678E96@drugs.dv.isc.org> References: <201110221355.p9MDt0M17687@ftpeng-update.cisco.com> <4EA7DC26.6020802@forthnetgroup.gr> <4EA87342.90305@gmail.com> <4EAB2233.8040908@gmail.com> <4EAB4856.2070002@dougbarton.us> <50CF70B9-3EAA-4897-9AF3-62A8D96C3EFB@cisco.com> <4EADB1C2.8000601@gmail.com> <4EAFB76D.7070208@redpill-linpro.com> <20111102071323.7821D16765EC@drugs.dv.isc.org> <4EB10BDA.3060202@redpill-linpro.com> <20111102111144.8587F1678E96@drugs.dv.isc.org> From: Lorenzo Colitti Date: Wed, 2 Nov 2011 12:41:55 -0700 Message-ID: To: Mark Andrews Content-Type: multipart/alternative; boundary=000e0cd5c6de5180d004b0c5ab5f X-System-Of-Record: true Cc: "v6ops@ietf.org" , "draft-carpenter-v6ops-icp-guidance@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-carpenter-v6ops-icp-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 Nov 2011 19:42:18 -0000 --000e0cd5c6de5180d004b0c5ab5f Content-Type: text/plain; charset=ISO-8859-1 On Wed, Nov 2, 2011 at 04:11, Mark Andrews wrote: > I would suggest that your tools are not RFC 1123 compliant as they > didn't cope with a multi-homed servers. This failure could have > happened with IPv4 only. It's only been been 22 years since support > for multi-homed servers was recommended. And yet, arguing with reality is not going to help you change reality. It will only make you out of touch. --000e0cd5c6de5180d004b0c5ab5f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Nov 2, 2011 at 04:11, Mark Andrews <marka@isc.org> wrote:
I would suggest that your tools are not R= FC 1123 compliant as they
didn't cope with a multi-homed servers. =A0This failure could have
happened with IPv4 only. =A0It's only been been 22 years since support<= br> for multi-homed servers was recommended.

An= d yet, arguing with reality is not going to help you change reality. It wil= l only make you out of touch.
--000e0cd5c6de5180d004b0c5ab5f-- From gert@space.net Wed Nov 2 12:44:49 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6170211E816C for ; Wed, 2 Nov 2011 12:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 l8TbWeO02Yjy for ; Wed, 2 Nov 2011 12:44:49 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id C5DE411E8160 for ; Wed, 2 Nov 2011 12:44:47 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id C4307F887C for ; Wed, 2 Nov 2011 20:44:46 +0100 (CET) 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 9C7D7F8886 for ; Wed, 2 Nov 2011 20:44:46 +0100 (CET) Received: (qmail 50447 invoked by uid 1007); 2 Nov 2011 20:44:46 +0100 Date: Wed, 2 Nov 2011 20:44:46 +0100 From: Gert Doering To: sarikaya@ieee.org Message-ID: <20111102194446.GB71280@Space.Net> References: <4EAB2233.8040908@gmail.com> <4EAB4856.2070002@dougbarton.us> <50CF70B9-3EAA-4897-9AF3-62A8D96C3EFB@cisco.com> <4EADB1C2.8000601@gmail.com> <4EAFB76D.7070208@redpill-linpro.com> <20111102071323.7821D16765EC@drugs.dv.isc.org> <4EB10BDA.3060202@redpill-linpro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "draft-carpenter-v6ops-icp-guidance@tools.ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-carpenter-v6ops-icp-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 Nov 2011 19:44:49 -0000 Hi, On Wed, Nov 02, 2011 at 02:38:44PM -0500, Behcet Sarikaya wrote: > This part of the news is scary: > > Registries that oversee the allocation of net addresses are also working on > plans for a re-circulation system that takes IPv4 addresses from firms that > are using IPv6 and releases them for use by others. Uh, what exactly is scary about that? If company A doesn't need their addresses anymore, and company B does, and the RIRs keep track of "who is using what", this sounds like a reasonable thing to me. The nitty details of individual transfer policies can indeed be scary, but that's certainly not what you were referring to. 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 joelja@bogus.com Wed Nov 2 12:45:56 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB83011E8177 for ; Wed, 2 Nov 2011 12:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.166 X-Spam-Level: X-Spam-Status: No, score=-102.166 tagged_above=-999 required=5 tests=[AWL=-0.167, 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 lS67eGqXhFhd for ; Wed, 2 Nov 2011 12:45:56 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 190E911E8152 for ; Wed, 2 Nov 2011 12:45:56 -0700 (PDT) Received: from Zorch.local (host-64-47-136-190.masergy.com [64.47.136.190]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id pA2Jjm6E058145 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 2 Nov 2011 19:45:49 GMT (envelope-from joelja@bogus.com) Message-ID: <4EB19DE7.5050303@bogus.com> Date: Wed, 02 Nov 2011 12:45:43 -0700 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: sarikaya@ieee.org References: <201110221355.p9MDt0M17687@ftpeng-update.cisco.com> <4EA7DC26.6020802@forthnetgroup.gr> <4EA87342.90305@gmail.com> <4EAB2233.8040908@gmail.com> <4EAB4856.2070002@dougbarton.us> <50CF70B9-3EAA-4897-9AF3-62A8D96C3EFB@cisco.com> <4EADB1C2.8000601@gmail.com> <4EAFB76D.7070208@redpill-linpro.com> <20111102071323.7821D16765EC@drugs.dv.isc.org> <4EB10BDA.3060202@redpill-linpro.com> In-Reply-To: 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, 02 Nov 2011 19:45:49 +0000 (UTC) Cc: "draft-carpenter-v6ops-icp-guidance@tools.ietf.org" , "v6ops@ietf.org" , Behcet Sarikaya Subject: Re: [v6ops] new draft: draft-carpenter-v6ops-icp-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 Nov 2011 19:45:57 -0000 On 11/2/11 12:38 , Behcet Sarikaya wrote: > This part of the news is scary: > > Registries that oversee the allocation of net addresses are also working > on plans for a re-circulation system that takes IPv4 addresses from > firms that are using IPv6 and releases them for use by others. If you return addresses to an RIR or transfer them to a third party, you can expect them to be reused... I don't expect that you'd want to use the BBC as your authoritative source of ip addresses policy news however. > On Wed, Nov 2, 2011 at 10:13 AM, Cameron Byrne > wrote: > > > On Nov 2, 2011 2:22 AM, "Tore Anderson" > > wrote: > > > > * Mark Andrews > > > > > In message <4EAFB76D.7070208@redpill-linpro.com > >, Tore Anderson writes: > > >> > > >> In a purely technical sense, you might be right. However, I've > come to > > >> realize that dual-stack is not really a viable transition > approach for > > >> us, due to organizational and human considerations. I think the > draft is > > >> intended exactly for organizations such as ours btw, as we're a > > >> small/medium-sized ICP. > > >> > > >> We have a team of people that works on the network > infrastructure (of > > >> which I'm part), and several teams with sysadmins that operate the > > >> customers' servers, operating systems, and the applications > running on > > >> them. While my colleagues and I are happy to promote IPv6 by always > > >> assigning an IPv6 prefix to all LANs that are requested by the > server > > >> guys, their priorities are very different - they don't want to get > > >> involved more networking than absolutely necessary. So if I > give them > > >> two IP stacks to work with, they'll choose one and leave the > other one > > >> unused, and not surprisingly, the one they choose to work with > is going > > >> to be the most familiar one - IPv4. > > >> > > >> I can understand it, too - dual stack is in a sense dual work > and dual > > >> complexity. They'd need to configure ACLs twice, monitor everything > > >> twice, accept lots of new failure scenarios and so on. It's real > > >> operational overhead, and nobody really wants that. > > > > > > Our ops people would say you are exagerating the costs. > > > > Considering I didn't mention costs at all, I'm not sure how you > came to > > that conclusion. I don't believe that dual stack mean you have to > double > > your operations budget. The added technical complexity is the main > > problem for us, not costs. > > > > Not even an hour after I sent my previous e-mail yesterday, a > colleague > > came over to me asking if I could look into why some accounting cron > > jobs had stopped working since last month. Turns out the problem was > > that a server had been recently dual-stacked, which caused a download > > job from another server (which had been dual-stacked for a long > time) to > > fail, because the ACLs that allowed the download to happen over IPv4 > > wasn't properly duplicated in IPv6. Easy enough to fix, and > fortunately > > not critical at all, but it's an example of a failure scenario you are > > open to only when running dual-stack. > > > > In case folks want to know the hard cold cash cost of using ipv4, > ask Microsoft > > http://www.bbc.co.uk/news/technology-12859585 > > Consider that the floor price, now that it went through, the model > is proven and prices will rise. > > Ipv6 is essentially free, especially on a per address basis :-) > > Not only that, the ROI timescale for ipv6 payback on initial > investments is as long as you think ipv6 will be around. Ipv4 > payback ...not quite as long. > > Cb > > > Best regards, > > -- > > Tore Anderson > > Redpill Linpro AS - http://www.redpill-linpro.com > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From brian.e.carpenter@gmail.com Wed Nov 2 13:12:57 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BED751F0CC9 for ; Wed, 2 Nov 2011 13:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.372 X-Spam-Level: X-Spam-Status: No, score=-102.372 tagged_above=-999 required=5 tests=[AWL=-1.039, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_FWDLOOK=1.666, 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 n5L9C4xciKpP for ; Wed, 2 Nov 2011 13:12:57 -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 D50FE1F0CC8 for ; Wed, 2 Nov 2011 13:12:56 -0700 (PDT) Received: by ywt2 with SMTP id 2so579280ywt.31 for ; Wed, 02 Nov 2011 13:12:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=dPU2JOiwYsZ3bWG/dIGV+xfIXDgZqNe+cTHwoVi2TIk=; b=DDCc+wQv0CnxSVEJ2YVrmN6QXq8jdjNxveTiLSgO8Kvwml0k39YVNtVOST4YY54zxU S5s6oNkPUEQcF3kWb7sHmsTST1iFxnG9ZbD6ZrTenxsXLxJv9e7/1dBxd/O8v+E6Gsbd CSrWGLvqP9roYGgdvB7rDNfBPlVywHWh8/xt4= Received: by 10.236.155.2 with SMTP id i2mr8856335yhk.115.1320264774453; Wed, 02 Nov 2011 13:12:54 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id r9sm10218374anh.8.2011.11.02.13.12.51 (version=SSLv3 cipher=OTHER); Wed, 02 Nov 2011 13:12:53 -0700 (PDT) Message-ID: <4EB1A443.1000301@gmail.com> Date: Thu, 03 Nov 2011 09:12:51 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Qiong References: <4EB05384.5000007@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Fwd: New Version Notification for draft-sunq-v6ops-contents-transition-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, 02 Nov 2011 20:12:57 -0000 Qiong, On 2011-11-03 05:19, Qiong wrote: > Hi, John, > > > Thanks. Please see inline. > > > On Wed, Nov 2, 2011 at 7:26 PM, John Mann wrote: > >> Hi, >> >> At Monash University, we dual-stacked the main web farm and most user >> subnets. >> Not much IPv6 traffic due to slow roll-out of (IPv6-enabled) Windows7 >> clients. >> >> The big step increases in IPv6 traffic were due to >> a) Google over IPv6 whitelisting >> b) YouTube available over IPv6 >> > > Does Google upgrade all their services directly on IPv6, or use some kind > of translation or proxy mechanism within its servers? I heard that Youtube > has adopted LISP+NAT64 for its own transition, LISP??? > and Yahoo has also deployed > several translation POPs around the world. I'm not sure whether it is > correct or not. Please correct me if I'm wrong :) > Of course, google is a very good example and we all hope many other ICPs > will follow it in a short time. And credit where it is due: the discussion about outside-in vs inside-out approaches in draft-carpenter-v6ops-icp-guidance came from an off-list message from Erik Kline at Google. The point is, using a dual stack proxy or a NAT64 as a front-end interface to the IPv6 Internet is the first step in an outside-in approach. It's a starting point, not a permanent solution. Personally I think a proxy is a more forward-looking solution, but NAT64 is a little more efficient, as a student of mine has proved. (See http://www.cs.auckland.ac.nz/~brian/NAT64-perf-Beijing.pdf) I think my main issue with your draft is the way the proposal is described in section 3.1. If it was described as the first step towards a complete solution according to RFC6180, I would be much happier. Brian > > >> Through our Internet border, we are now doing 600 GB/day (10%) IPv6 >> traffic inbound >> and 60 GB/day (1.5%) IPv6 traffic outbound. >> >> Google have broken the chicken v. egg impasse. >> Enable IPv6 on Facebook, other CDNs etc and we could have a lot of IPv6 >> traffic! >> > > Very good news! I believe the traffic volume is the most exciting info for > us. In China, we also have a great volume of IPv6 traffic in CERNET2 (China > Education Network for next generation Internet), which is a IPv6-only > core-network. We have a lot of IPv6 contents including videos, BT, forums, > etc, and the preference policy over IPv6 is applied here. As indicated in > our draft (Appendix 1.1), more than 91 percent of our IPv6 users come from > CERNET2. > > However, from operator perspective, I still think the situation here is a > little bit different in commercial network. Since operator itself is for > earning money rather than doing research, it would be more harder to > persuade market people when there is no explicit value for them. After all, > IPv6 deployment will cost quite a lot in the short run. So a simple > question would just come out, why should we invest so much when there is > still little reachable IPv6 content. > In the same way, ICPs are also waiting for IPv6 users. In our situation, > although we already have quite a lot of CERNET2 IPv6 users, it is still far > from enough to convince a majority of ICPs upgrading to IPv6 directly. We > all expect that ICPs would have the same belief with us, that IPv6 is > definitely the future direction, but here we should make things happen at > the first step. Anyway, we believe that ICP transition is the key point to > IPv6 success. > > Best wishes > > Qiong > > > Thanks, >> John >> >>> I really >>> think we need to re-think it again, from both technical aspect and the >>> industry/or market aspect. And the first step is rather important to >> give us >>> confidence to move forward. That's why we recommend single-stack (either >> v4 >>> or v6) transition in the current phase. Then, for the conservative >> ones, the >>> IPv4 services can be still offered natively, and the IPv6 services can be >>> offered by the stateful NAT64; while for progressive ones and newly >> comers, >>> the stateless IVI can be employed to offer native IPv6 services reachable >>> via IPv4. And we hope it would help enrich IPv6 content asap. Then how do >>> you think ? >>> Thanks >>> Qiong >>> >>> On Wed, Nov 2, 2011 at 4:16 AM, Brian E Carpenter >>> wrote: >>>> I'm not seeing why this is a better solution for a small/medium ICP >>>> than just moving to a dual stack. That is much easier for a small >>>> network than for a big one. >>>> >>>> Regards >>>> Brian >>>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> >>> > From brian.e.carpenter@gmail.com Wed Nov 2 13:17:57 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE7C311E8122 for ; Wed, 2 Nov 2011 13:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.481 X-Spam-Level: X-Spam-Status: No, score=-103.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MYaPvjkF-tcU for ; Wed, 2 Nov 2011 13:17:57 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD5D11E8175 for ; Wed, 2 Nov 2011 13:17:57 -0700 (PDT) Received: by gye5 with SMTP id 5so578904gye.31 for ; Wed, 02 Nov 2011 13:17:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=T2XVHUMwuWjLOC5EdyMuV6IJHwDOSwfnePcVUAk/HJE=; b=G0uIgbBsulC5p3bFNNpVIcdlB4uUPTqzmUyf7Xva/ENZzYYZbBgZp8Y4dYExAccATz u2jPDSzy6f+EUpeV6WaPCMkRZvYlPZE6H7VVAx6WfgkLJu1Njr6sj5HXrC6hB/Nsqxh7 RmaLqcgaaM2J5nsBc7rWZIXsE6GwQAIa4G8+c= Received: by 10.236.161.133 with SMTP id w5mr9333920yhk.63.1320265077086; Wed, 02 Nov 2011 13:17:57 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id j25sm5718297yhm.12.2011.11.02.13.17.49 (version=SSLv3 cipher=OTHER); Wed, 02 Nov 2011 13:17:53 -0700 (PDT) Message-ID: <4EB1A56B.1010707@gmail.com> Date: Thu, 03 Nov 2011 09:17:47 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Tore Anderson References: <201110221355.p9MDt0M17687@ftpeng-update.cisco.com> <4EA7DC26.6020802@forthnetgroup.gr> <4EA87342.90305@gmail.com> <4EAB2233.8040908@gmail.com> <4EAB4856.2070002@dougbarton.us> <50CF70B9-3EAA-4897-9AF3-62A8D96C3EFB@cisco.com> <4EADB1C2.8000601@gmail.com> <4EAFB76D.7070208@redpill-linpro.com> <4EB0561C.7070507@gmail.com> <4EB107DD.5070707@redpill-linpro.com> In-Reply-To: <4EB107DD.5070707@redpill-linpro.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , "draft-carpenter-v6ops-icp-guidance@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-carpenter-v6ops-icp-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 Nov 2011 20:17:58 -0000 On 2011-11-02 22:05, Tore Anderson wrote: > * Brian E Carpenter > >> Grumble. I don't like that conclusion, because it's clear that >> the desired end point is native v6 and I don't see how your >> approach gets us there. > > Native IPv6 on all servers and used by all applications running on those > servers doesn't get us to native IPv6? Huh? :-) It was this that triggered my comment: >> and not surprisingly, the one they choose to work with is going >> to be the most familiar one - IPv4. I agree that what you describe is a good approach. Sorry that wasn't clear (I misphrased it; yesterday was a busy day). Brian From brian.e.carpenter@gmail.com Wed Nov 2 13:26:53 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E105811E811F for ; Wed, 2 Nov 2011 13:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.484 X-Spam-Level: X-Spam-Status: No, score=-103.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tanfO7l7L3hI for ; Wed, 2 Nov 2011 13:26:53 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 64B3E11E80BC for ; Wed, 2 Nov 2011 13:26:53 -0700 (PDT) Received: by gye5 with SMTP id 5so587204gye.31 for ; Wed, 02 Nov 2011 13:26:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=FMqwvN6fiketH/1f+O+PVkYFojbfudDnkbJ+6I7gsSI=; b=cRsIel3VLhSgdHpnOcJkIqUdDpjjSJHBkDy/Ku5i5MMyctDmhTnhBg4QK+pdiRzCTZ 384zyNXfosHD/RRgDcKn5MBdHKc19qt7DWzZKdtJUOacAyj7ROobiOw4gIt39STfj0PE v293J3NDPp5p13fU68stJPYy0ummHdv1umcwc= Received: by 10.101.8.2 with SMTP id l2mr1509906ani.79.1320265613057; Wed, 02 Nov 2011 13:26:53 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id 4sm10322793ano.9.2011.11.02.13.26.49 (version=SSLv3 cipher=OTHER); Wed, 02 Nov 2011 13:26:52 -0700 (PDT) Message-ID: <4EB1A789.7030900@gmail.com> Date: Thu, 03 Nov 2011 09:26:49 +1300 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: <201110221355.p9MDt0M17687@ftpeng-update.cisco.com> <4EA7DC26.6020802@forthnetgroup.gr> <4EA87342.90305@gmail.com> <4EAB2233.8040908@gmail.com> <4EAB4856.2070002@dougbarton.us> <50CF70B9-3EAA-4897-9AF3-62A8D96C3EFB@cisco.com> <4EADB1C2.8000601@gmail.com> <4EAFB76D.7070208@redpill-linpro.com> <20111102071323.7821D16765EC@drugs.dv.isc.org> <20111102140856.GS71280@Space.Net> In-Reply-To: <20111102140856.GS71280@Space.Net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , "draft-carpenter-v6ops-icp-guidance@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-carpenter-v6ops-icp-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 02 Nov 2011 20:26:54 -0000 Hi Gert, On 2011-11-03 03:08, Gert Doering wrote: > Hi, > > On Wed, Nov 02, 2011 at 06:13:23PM +1100, Mark Andrews wrote: >> Our ops people would say you are exagerating the costs. They have >> 7+ years of dual stack experience. It's not zero but is close to >> that. > > Speaking as an Ops person, I really, *really* want to get rid of > dual-stack. Double address management, double monitoring, double > testing for internal connections between machines (will it use v4 or > v6 today?), double ACLing things, twice as many opportunities for > people to make mistakes. Worse, if one of the protocols isn't set > up right, you might not even notice it right away if the applications > are using the other one today. > > I very much like Tore's approach. > > (I don't see us actually doing this any time soon - the network is > not currently set up properly for that - but the idea of running > everything IPv6-only with an IPv4 front-end proxy has lots of merits) However, that would be a hard sell to a conservative ICP in 2011. I certainly agree that this is a desirable end state, but my guess is that it's at least ten years away as a mainstream approach. Maybe we should add a new phrase to go with 'early adopter', such as 'early rejecter". Brian From marka@isc.org Wed Nov 2 17:01:37 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6D0011E80BD for ; Wed, 2 Nov 2011 17:01:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.042, 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 QrvU9rqjZF+n for ; Wed, 2 Nov 2011 17:01:37 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id B799B11E8073 for ; Wed, 2 Nov 2011 17:01:35 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 05E32C942B; Thu, 3 Nov 2011 00:01:21 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 72B5C216C6A; Thu, 3 Nov 2011 00:01:20 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id B979E1681EC5; Thu, 3 Nov 2011 11:01:13 +1100 (EST) To: Gert Doering From: Mark Andrews References: <4EA87342.90305@gmail.com> <4EAB2233.8040908@gmail.com> <4EAB4856.2070002@dougbarton.us> <50CF70B9-3EAA-4897-9AF3-62A8D96C3EFB@cisco.com> <4EADB1C2.8000601@gmail.com> <4EAFB76D.7070208@redpill-linpro.com> <20111102071323.7821D16765EC@drugs.dv.isc.org> <4EB10BDA.3060202@redpill-linpro.com> <20111102111144.8587F1678E96@drugs.dv.isc.org> <20111102141002.GT71280@Space.Net> In-reply-to: Your message of "Wed, 02 Nov 2011 15:10:02 BST." <20111102141002.GT71280@Space.Net> Date: Thu, 03 Nov 2011 11:01:13 +1100 Message-Id: <20111103000113.B979E1681EC5@drugs.dv.isc.org> Cc: "v6ops@ietf.org" , "draft-carpenter-v6ops-icp-guidance@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-carpenter-v6ops-icp-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 Nov 2011 00:01:37 -0000 In message <20111102141002.GT71280@Space.Net>, Gert Doering writes: > Hi, > > On Wed, Nov 02, 2011 at 10:11:44PM +1100, Mark Andrews wrote: > > I would suggest that your tools are not RFC 1123 compliant as they > > didn't cope with a multi-homed servers. This failure could have > > happened with IPv4 only. It's only been been 22 years since support > > for multi-homed servers was recommended. > > Cheap shot. > > "If you don't like the extra work something causes, it must be because > you / your tools are not up for the job" The entire 6to4 fiasco with web clients is because they did not handle multi-homed servers. If they handled multi-homed servers (a bug that was reported long before there was much if any dual stacked servers) they would have handled 6to4 issues. They would have connected / fallen back to IPv4 when the IPv6 path was blocked due to stupid firewall blocking the encapulated packets. Dual stack just means you clients need to work well with multi-homed servers. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From tore@redpill-linpro.com Wed Nov 2 17:06:54 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E7BD11E80BE for ; Wed, 2 Nov 2011 17:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.323 X-Spam-Level: X-Spam-Status: No, score=-2.323 tagged_above=-999 required=5 tests=[AWL=-0.276, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tqvbEa02n2PS for ; Wed, 2 Nov 2011 17:06:50 -0700 (PDT) Received: from zimbra.redpill-linpro.com (zimbra.redpill-linpro.com [IPv6:2a02:c0:200:c000::1]) by ietfa.amsl.com (Postfix) with ESMTP id A412D11E8073 for ; Wed, 2 Nov 2011 17:06:49 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.redpill-linpro.com (Postfix) with ESMTP id 36B8A1030009; Thu, 3 Nov 2011 01:06:48 +0100 (CET) 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 TVY4cMif69q8; Thu, 3 Nov 2011 01:06:45 +0100 (CET) Received: from zimbra.redpill-linpro.com (claudius.linpro.no [87.238.49.234]) by zimbra.redpill-linpro.com (Postfix) with ESMTP id 90AA41030001; Thu, 3 Nov 2011 01:06:45 +0100 (CET) Date: Thu, 03 Nov 2011 01:06:45 +0100 (CET) From: Tore Anderson To: Qiong Message-ID: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Mailer: Zimbra 7.1.3_GA_3346 (ZimbraWebClient - FF3.0 (Linux)/7.1.3_GA_3346) Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: New Version Notification for draft-sunq-v6ops-contents-transition-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, 03 Nov 2011 00:06:54 -0000 * Qiong > http://tools.ietf.org/id/draft-sunq-v6ops-contents-transition-02.txt > > Your comments will be very much appreciated. Thanks in advance! Hello, My comments follow: 1) Figure 1 displays a single NAT64 gateway that both handles stateless IPv4-client-to-IPv6-server translations as well as stateful IPv6-client- to-IPv4-server translations. These two techniques are completely independent of each other, so I suggest you display this as two separate translator boxes, and rather mention that the two functions may be co- located on the same physical hardware. A stateful function is limited by the total amount of flows as well as the flow initiation rate, it is much more prone to being overloaded than a stateless function. I therefore generally recommend against co- locating critical stateful and stateless functions on the same hardware, unless it can be ensured that an overloading of the stateful function does not impact the stateless function. To prevent confusion, I would also avoid referring to the two distinct functions with the same name ("NAT64 gateway"). Perhaps "IVI gateway" would be better for the stateless function? (Or "SIIT gateway", see below.) 2) The header of section 5 ("IPv6-to-IPv4 communication scenario") is somewhat ambigous. I suggest rewriting it to e.g. "IPv6 client to IPv4 server communication scenario". Likewise for the title of section 6. 3) In section 5, I think it should be mentioned that an alternative to using stateful NAT64 is using a Layer-4 or Layer-7 proxy (e.g. HAProxy). This has the advantage of sometimes being able to communicate the original IPv6 source address of the end user to the IPv4 server,e.g., for geo-location. This can be done by inserting a Layer-7 header such as HTTP's X-Forwarded-For. 4) In section 6, it should be pointed out that due to its stateless nature, the IVI translation function can trivially be made redundant and load balanced, by using standard routing techniques such as anycasting and equal-cost multipath routes. This is in my opinion an enormous advantage over stateful NAT64, which requres symmetric traffic flow across a single translator box. 5) I believe there should be some discussion of potential issues arising from the fact that the IPv6 header usually is 20 bytes larger than an IPv4 header: Assuming a standard Ethernet MTU of 1500 bytes, if a translator receives a maximum-sized IPv4 packet with the Don't Fragment flag unset, the translator needs to fragment the packet when translating to IPv6. This has some potential side-effects, as the addition of the IPv6 Extension Header may prevent firewalls and similar middleware boxes from correctly evaluating the fragmented packets according to ACLs or similar. Use of a 1520 bytes large MTU in the IPv6 network between the translator and the server may be one way to deal with this problem, in the IVI scenario. Also, when using TCP, an IPv6 server using MTU 1500 will generally ensure sufficiently small enough MSS is negotiated so that the IPv4 client is prevented from ever sending larger IPv4 packets than 1480 bytes, which will not require fragmentation. In the stateful scenario, this issue can be avoided by using a Layer-4/7 proxy rather than NAT64. 6) I feel that the references to RFC 6219 is wrong. In all three cases (sections 1, 3.1, and 6), it is used as a normative reference, i.e., as the IVI protocol specification. However, RFC 6219 is not a protocol specification as far as I can tell, it is rather just a case study. It should therefore be an informative reference. As far as I've been able to understand from reading RFC 6219, the protocol called "stateless IVI" is in reality specified in RFC 6145 where it is called "Stateless IP/ICMP Translation" (SIIT). If this is correct, and there really is no difference between "stateless IVI" and SIIT, I feel that the use of the name IVI is questionable as it does not appear once in RFC 6145 (nor in RFC 6052 for that matter). The only reference I find to the name "IVI" in current IETF docs are in this draft as well as in RFC 6219 (where it just seems to describe SIIT). I therefore suggest you replace all mentions of (stateless) IVI with SIIT, and the related normative references from RFC 6219 to RFC 6145. Best regards, -- Tore Anderson From phdgang@gmail.com Wed Nov 2 19:00:18 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0C2411E80E0 for ; Wed, 2 Nov 2011 19:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.166 X-Spam-Level: X-Spam-Status: No, score=-3.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 vluf44XGg9ZP for ; Wed, 2 Nov 2011 19:00:18 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id EB17711E80CB for ; Wed, 2 Nov 2011 19:00:17 -0700 (PDT) Received: by wyg30 with SMTP id 30so864509wyg.31 for ; Wed, 02 Nov 2011 19:00:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=tP0fUS/t4OyB+oSI4hWTFj7Ux8wYXiBZ3Uqv0BHZkqw=; b=VQKBCg+UuL1vE4YGwdpOrUnmQoQLXVJ+6BlPcp2UtqFo2iida28hRbYw3WjUF48C0D ey9mw1dlSBzwAXJlUiHl6giwq3633vcBjMqYVosPXmMUBRHUvRxq3h8HQxs/rSDPsC/Y l40BY89LopErP4ukHYQojmVsM4BzgYrhzBHlc= MIME-Version: 1.0 Received: by 10.227.203.132 with SMTP id fi4mr9253558wbb.6.1320285615545; Wed, 02 Nov 2011 19:00:15 -0700 (PDT) Received: by 10.180.102.8 with HTTP; Wed, 2 Nov 2011 19:00:15 -0700 (PDT) Date: Thu, 3 Nov 2011 10:00:15 +0800 Message-ID: From: GangChen To: v6ops Content-Type: text/plain; charset=ISO-8859-1 Subject: [v6ops] NAT64 Operational Considerations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 Nov 2011 02:00:18 -0000 Dear all, I have just submitted the draft for NAT64 operational consideration. The intention is to provide comprehensive considerations for NAT64 deployment. The detailed information is listed at below A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : NAT64 Operational Considerations Author(s) : Gang Chen Filename : draft-chen-v6ops-nat64-cpe-03.txt Pages : 8 Date : 2011-10-31 The document has summarized NAT64 usages on different modes, in which NAT64 may serve for a large-scale network or would give enterprise or residential service opportunities to be accessed by IPv6 remote subscribers. The document has described different operations for each usage and proposed operational considerations for each particular NAT64-mode. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-chen-v6ops-nat64-cpe-03.txt Many thanks Gang From bingxuere@gmail.com Wed Nov 2 19:30:31 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0926111E809B for ; Wed, 2 Nov 2011 19:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.975 X-Spam-Level: X-Spam-Status: No, score=-2.975 tagged_above=-999 required=5 tests=[AWL=0.023, 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 1TWKQP+ZFInE for ; Wed, 2 Nov 2011 19:30:30 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6DDA611E8098 for ; Wed, 2 Nov 2011 19:30:30 -0700 (PDT) Received: by iaeo4 with SMTP id o4so990475iae.31 for ; Wed, 02 Nov 2011 19:30:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=QOEGYxEMciH/mhsrfBCdoofay4Jscy21Wxi3zLUvqoY=; b=eXDkYQtjvJQso+4my39d17QaKqGGkh+WdU+2YsSF5JvciudBw1bEk8WOFO7O07l/HV i2ZNj5jcfRdxUBpqpLvF7X9WhOS/LG3jDGpXkRmYYV3soF0KZUpBo4o6KUHeU1CsS/z1 YW9m6aizMI/psErZytDMU24hZmcsop6LwiE3o= Received: by 10.43.44.199 with SMTP id uh7mr5637907icb.25.1320287430104; Wed, 02 Nov 2011 19:30:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.218.10 with HTTP; Wed, 2 Nov 2011 19:29:49 -0700 (PDT) In-Reply-To: References: From: Qiong Date: Thu, 3 Nov 2011 10:29:49 +0800 Message-ID: To: GangChen Content-Type: multipart/alternative; boundary=bcaec52999eb45d7d604b0cb5fcc Cc: v6ops Subject: Re: [v6ops] NAT64 Operational Considerations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 Nov 2011 02:30:31 -0000 --bcaec52999eb45d7d604b0cb5fcc Content-Type: text/plain; charset=UTF-8 Hi, Gang, I'm not against that NAT64 can be deployed in IDC scenario. But actually, this deployment model is originally proposed by us in draft-sunq-v6ops-contents-transition-00, don't you think it is inappropriate to include it without notification to us? Best regards Qiong On Thu, Nov 3, 2011 at 10:00 AM, GangChen wrote: > Dear all, > > I have just submitted the draft for NAT64 operational consideration. > The intention is to provide comprehensive considerations for NAT64 > deployment. > The detailed information is listed at below > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : NAT64 Operational Considerations > Author(s) : Gang Chen > Filename : draft-chen-v6ops-nat64-cpe-03.txt > Pages : 8 > Date : 2011-10-31 > > The document has summarized NAT64 usages on different modes, in which > NAT64 may serve for a large-scale network or would give enterprise or > residential service opportunities to be accessed by IPv6 remote > subscribers. The document has described different operations for > each usage and proposed operational considerations for each > particular NAT64-mode. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-chen-v6ops-nat64-cpe-03.txt > > Many thanks > > Gang > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --bcaec52999eb45d7d604b0cb5fcc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Gang,

I'm not against that NAT64 can be deployed= in IDC scenario. But actually, this deployment model is originally propose= d by us in draft-sunq-v6ops-contents-transition-00, don't you think it = is=C2=A0inappropriate=C2=A0to =C2=A0include it without notification to us?<= /div>

Best regards

Qiong =C2=A0
<= br>
On Thu, Nov 3, 2011 at 10:00 AM, GangChen <phdgang@gmail.com> wrote:
Dear all,

I have just submitted the draft for NAT64 operational consideration.
The intention is to provide comprehensive considerations for NAT64 deployme= nt.
The detailed information is listed at below

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.

=C2=A0 =C2=A0 =C2=A0 Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : NAT64 Oper= ational Considerations
=C2=A0 =C2=A0 =C2=A0 Author(s) =C2=A0 =C2=A0 =C2=A0 : Gang Chen
=C2=A0 =C2=A0 =C2=A0 Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-chen-v6op= s-nat64-cpe-03.txt
=C2=A0 =C2=A0 =C2=A0 Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 8
=C2=A0 =C2=A0 =C2=A0 Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: 2011-= 10-31

=C2=A0The document has summarized NAT64 usages on different modes, in whic= h
=C2=A0NAT64 may serve for a large-scale network or would give enterprise o= r
=C2=A0residential service opportunities to be accessed by IPv6 remote
=C2=A0subscribers. =C2=A0The document has described different operations f= or
=C2=A0each usage and proposed operational considerations for each
=C2=A0particular NAT64-mode.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-chen-v6o= ps-nat64-cpe-03.txt

Many thanks

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

--bcaec52999eb45d7d604b0cb5fcc-- From pch-b29AA871B@u-1.phicoh.com Thu Nov 3 02:02:15 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C19B11E80E8 for ; Thu, 3 Nov 2011 02:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.413 X-Spam-Level: X-Spam-Status: No, score=-8.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, GB_I_LETTER=-2, 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 xN9cqjm9Eydj for ; Thu, 3 Nov 2011 02:02:14 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 8B00F11E80EB for ; Thu, 3 Nov 2011 02:02:12 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #76) id m1RLtBX-0001j6C; Thu, 3 Nov 2011 10:02:07 +0100 Message-Id: To: Mark Andrews From: Philip Homburg Sender: pch-b29AA871B@u-1.phicoh.com References: <4EA87342.90305@gmail.com> <4EAB2233.8040908@gmail.com> <4EAB4856.2070002@dougbarton.us> <50CF70B9-3EAA-4897-9AF3-62A8D96C3EFB@cisco.com> <4EADB1C2.8000601@gmail.com> <4EAFB76D.7070208@redpill-linpro.com> <20111102071323.7821D16765EC@drugs.dv.isc.org> <4EB10BDA.3060202@redpill-linpro.com> <20111102111144.8587F1678E96@drugs.dv.isc.org> <20111102141002.GT71280@Space.Net> <20111103000113.B979E1681EC5@drugs.dv.isc.org> In-reply-to: Your message of "Thu, 03 Nov 2011 11:01:13 +1100 ." <20111103000113.B979E1681EC5@drugs.dv.isc.org> Date: Thu, 03 Nov 2011 10:02:01 +0100 Cc: "v6ops@ietf.org" , "draft-carpenter-v6ops-icp-guidance@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-carpenter-v6ops-icp-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 Nov 2011 09:02:15 -0000 In your letter dated Thu, 03 Nov 2011 11:01:13 +1100 you wrote: > >In message <20111102141002.GT71280@Space.Net>, Gert Doering writes: >> Hi, >> >> On Wed, Nov 02, 2011 at 10:11:44PM +1100, Mark Andrews wrote: >> > I would suggest that your tools are not RFC 1123 compliant as they >> > didn't cope with a multi-homed servers. This failure could have >> > happened with IPv4 only. It's only been been 22 years since support >> > for multi-homed servers was recommended. >> >> Cheap shot. >> >> "If you don't like the extra work something causes, it must be because >> you / your tools are not up for the job" > >The entire 6to4 fiasco with web clients is because they did not >handle multi-homed servers. If they handled multi-homed servers >(a bug that was reported long before there was much if any dual >stacked servers) they would have handled 6to4 issues. They would >have connected / fallen back to IPv4 when the IPv6 path was blocked >due to stupid firewall blocking the encapulated packets. > >Dual stack just means you clients need to work well with multi-homed >servers. I think this is a bit silly. The best thing we have today to let a host deal with 6to4 brokenness is HE and even that is not a fully general solution. In all the time there where multi-homed services (I think multi-homed servers is the wrong term given how redundancy is typically implemented) there was almost no progress in destination selection. The only games in town were DNS, which is also rather limited in this context (where IPv6 does not work at all) and anycast routing (same story). If we ignore specialized solutions and consider what is shipped with major operating systems as the state of the art, then the conclusion is that we simply do not know how to do multi-homing. So until major operating systems ship with libraries or other services that make multi-homing just work, I'd suggest the we consider any kind of multi-homing as a potential reliability problem. And in that model, if you can drop IPv4 internally and replace it with just an external IPv4-to-IPv6 traslator then things probably get better. From marka@isc.org Thu Nov 3 02:55:44 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 581CE1F0C62 for ; Thu, 3 Nov 2011 02:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.558 X-Spam-Level: X-Spam-Status: No, score=-3.558 tagged_above=-999 required=5 tests=[AWL=1.041, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n5i4420NLw7M for ; Thu, 3 Nov 2011 02:55:43 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id A42221F0C3E for ; Thu, 3 Nov 2011 02:55:43 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id C5B2EC9473; Thu, 3 Nov 2011 09:55:28 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 2B049216C6A; Thu, 3 Nov 2011 09:55:28 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 8FF5A168C535; Thu, 3 Nov 2011 20:55:24 +1100 (EST) To: Philip Homburg From: Mark Andrews References: <4EA87342.90305@gmail.com> <4EAB2233.8040908@gmail.com> <4EAB4856.2070002@dougbarton.us> <50CF70B9-3EAA-4897-9AF3-62A8D96C3EFB@cisco.com> <4EADB1C2.8000601@gmail.com> <4EAFB76D.7070208@redpill-linpro.com> <20111102071323.7821D16765EC@drugs.dv.isc.org> <4EB10BDA.3060202@redpill-linpro.com> <20111102111144.8587F1678E96@drugs.dv.isc.org> <20111102141002.GT71280@Space.Net> <20111103000113.B979E1681EC5@drugs.dv.isc.org> In-reply-to: Your message of "Thu, 03 Nov 2011 10:02:01 BST." Date: Thu, 03 Nov 2011 20:55:24 +1100 Message-Id: <20111103095524.8FF5A168C535@drugs.dv.isc.org> Cc: "v6ops@ietf.org" , "draft-carpenter-v6ops-icp-guidance@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-carpenter-v6ops-icp-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 Nov 2011 09:55:44 -0000 In message , Philip Homburg writes: > In your letter dated Thu, 03 Nov 2011 11:01:13 +1100 you wrote: > > > >In message <20111102141002.GT71280@Space.Net>, Gert Doering writes: > >> Hi, > >> > >> On Wed, Nov 02, 2011 at 10:11:44PM +1100, Mark Andrews wrote: > >> > I would suggest that your tools are not RFC 1123 compliant as they > >> > didn't cope with a multi-homed servers. This failure could have > >> > happened with IPv4 only. It's only been been 22 years since support > >> > for multi-homed servers was recommended. > >> > >> Cheap shot. > >> > >> "If you don't like the extra work something causes, it must be because > >> you / your tools are not up for the job" > > > >The entire 6to4 fiasco with web clients is because they did not > >handle multi-homed servers. If they handled multi-homed servers > >(a bug that was reported long before there was much if any dual > >stacked servers) they would have handled 6to4 issues. They would > >have connected / fallen back to IPv4 when the IPv6 path was blocked > >due to stupid firewall blocking the encapulated packets. > > > >Dual stack just means you clients need to work well with multi-homed > >servers. > > I think this is a bit silly. > > The best thing we have today to let a host deal with 6to4 brokenness is HE > and even that is not a fully general solution. > > In all the time there where multi-homed services (I think multi-homed servers > is the wrong term given how redundancy is typically implemented) there was > almost no progress in destination selection. You are looking for optimal. It would be nice if applications just tried alterative addresses. Just because one is unreachable it says nothing about the other. > The only games in town were DNS, which is also rather limited in this context > (where IPv6 does not work at all) and anycast routing (same story). DNS works fine for IPv6 both at the transport and data level. > If we ignore specialized solutions and consider what is shipped with major > operating systems as the state of the art, then the conclusion is that we > simply do not know how to do multi-homing. > > So until major operating systems ship with libraries or other services that > make multi-homing just work, I'd suggest the we consider any kind of > multi-homing as a potential reliability problem. > > And in that model, if you can drop IPv4 internally and replace it with just an > external IPv4-to-IPv6 traslator then things probably get better. OS's have shipped with libraries that have returned multiple addresses for 2+ decades. When the application only tries the first you can blame the application not the the OS. The complaint here was the data didn't transfer when there were two addresses and the acl path blocked one of the transports. The other transport was wide open. The application should have tried it. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From pch-b29AA871B@u-1.phicoh.com Thu Nov 3 03:40:49 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61F9A1F0C61 for ; Thu, 3 Nov 2011 03:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.436 X-Spam-Level: X-Spam-Status: No, score=-8.436 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, GB_I_LETTER=-2, 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 XG9e0eIXpUuz for ; Thu, 3 Nov 2011 03:40:49 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 6D3EC1F0C3C for ; Thu, 3 Nov 2011 03:40:48 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #76) id m1RLuj0-0001isC; Thu, 3 Nov 2011 11:40:46 +0100 Message-Id: To: Mark Andrews From: Philip Homburg Sender: pch-b29AA871B@u-1.phicoh.com References: <4EA87342.90305@gmail.com> <4EAB2233.8040908@gmail.com> <4EAB4856.2070002@dougbarton.us> <50CF70B9-3EAA-4897-9AF3-62A8D96C3EFB@cisco.com> <4EADB1C2.8000601@gmail.com> <4EAFB76D.7070208@redpill-linpro.com> <20111102071323.7821D16765EC@drugs.dv.isc.org> <4EB10BDA.3060202@redpill-linpro.com> <20111102111144.8587F1678E96@drugs.dv.isc.org> <20111102141002.GT71280@Space.Net> <20111103000113.B979E1681EC5@drugs.dv.isc.org> <20111103095524.8FF5A168C535@drugs.dv.isc.org> In-reply-to: Your message of "Thu, 03 Nov 2011 20:55:24 +1100 ." <20111103095524.8FF5A168C535@drugs.dv.isc.org> Date: Thu, 03 Nov 2011 11:40:24 +0100 Cc: "v6ops@ietf.org" , "draft-carpenter-v6ops-icp-guidance@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-carpenter-v6ops-icp-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 Nov 2011 10:40:49 -0000 In your letter dated Thu, 03 Nov 2011 20:55:24 +1100 you wrote: >You are looking for optimal. It would be nice if applications just >tried alterative addresses. Just because one is unreachable it >says nothing about the other. > >DNS works fine for IPv6 both at the transport and data level. Just trying alternative addresses is nowhere near enough. For anything interactive, users expect real time response. Just add an unreachable DNS resolver to the head of the list of resolvers in /etc/resolv.conf and see how quickly you want to remove it again. >OS's have shipped with libraries that have returned multiple addresses >for 2+ decades. When the application only tries the first you can >blame the application not the the OS. I agree that application should do that at some basic level. >The complaint here was the data didn't transfer when there were two >addresses and the acl path blocked one of the transports. The other >transport was wide open. The application should have tried it. There are ACLs at many levels. Retrying for errors at the network level is common. But if you get an access denied at the application level do you retry? Suppose a web browser get a 404, do you expect it to try all other addresses to see if one would work? From gert@space.net Thu Nov 3 03:58:44 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB7E311E80DC for ; Thu, 3 Nov 2011 03:58: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=[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 N60+B8n4yIKz for ; Thu, 3 Nov 2011 03:58:44 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0B10F11E80D3 for ; Thu, 3 Nov 2011 03:58:43 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 2D3AAF88AA for ; Thu, 3 Nov 2011 11:58:42 +0100 (CET) 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 151CDF889A for ; Thu, 3 Nov 2011 11:58:42 +0100 (CET) Received: (qmail 11067 invoked by uid 1007); 3 Nov 2011 11:58:41 +0100 Date: Thu, 3 Nov 2011 11:58:41 +0100 From: Gert Doering To: Mark Andrews Message-ID: <20111103105841.GF71280@Space.Net> References: <4EAB2233.8040908@gmail.com> <4EAB4856.2070002@dougbarton.us> <50CF70B9-3EAA-4897-9AF3-62A8D96C3EFB@cisco.com> <4EADB1C2.8000601@gmail.com> <4EAFB76D.7070208@redpill-linpro.com> <20111102071323.7821D16765EC@drugs.dv.isc.org> <4EB10BDA.3060202@redpill-linpro.com> <20111102111144.8587F1678E96@drugs.dv.isc.org> <20111102141002.GT71280@Space.Net> <20111103000113.B979E1681EC5@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IfZ+tgy+ooJOsAAy" Content-Disposition: inline In-Reply-To: <20111103000113.B979E1681EC5@drugs.dv.isc.org> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "v6ops@ietf.org" , "draft-carpenter-v6ops-icp-guidance@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-carpenter-v6ops-icp-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 Nov 2011 10:58:44 -0000 --IfZ+tgy+ooJOsAAy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi On Thu, Nov 03, 2011 at 11:01:13AM +1100, Mark Andrews wrote: > The entire 6to4 fiasco with web clients is because they did not > handle multi-homed servers. If they handled multi-homed servers > (a bug that was reported long before there was much if any dual > stacked servers) they would have handled 6to4 issues. They would > have connected / fallen back to IPv4 when the IPv6 path was blocked > due to stupid firewall blocking the encapulated packets. One of us seems to be a bit decoupled from reality. All the clients (that have been adapted to IPv6 in the first place) *do*=20 fall over if IPv6 connection fails, and they used to do so by following=20 the sample implementation in the RFC that explained that you should use=20 getaddrinfo() and then loop on the results, trying to connect to each=20 address in sequence. And as a result, they fall over *after timeouting* on connect(), again following the RFCs on how long a TCP connect should try. Which works fine if you either have connectivity, or have an ICMP error or TCP reset coming back, but "firewalls blocking the encapsulated packets" exactly do not do so - so it's blackholing, and 30 seconds to 1.5 minutes wait time before trying the next address in the list (which is completely unacceptable for a content provider trying to serve web stuff). So where exactly did "the web clients" fail to implement the authoritative RFCs on this? 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 --IfZ+tgy+ooJOsAAy Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQCVAwUBTrJz4akuBuNlUUl1AQLnWwP/akivmkkzuE+8V0Qe3qQUHS1KZNmROh/o fXK2JKcX57QVy1DDk3cDbCQrWpHh2WsEVIk0QgUgqlJgi8MpsFIf4PLO/TKt/v5o DOah40fcB5945QwztImd4cQ1Ew64WlK++BH+gLP7ekBOTAQPD/E4qnONQKsn3r7k SOom4o4Kfwc= =4IF8 -----END PGP SIGNATURE----- --IfZ+tgy+ooJOsAAy-- From marka@isc.org Thu Nov 3 05:18:40 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91B591F0C61 for ; Thu, 3 Nov 2011 05:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, 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 UGg3zvBU0z7X for ; Thu, 3 Nov 2011 05:18:39 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 998301F0C5F for ; Thu, 3 Nov 2011 05:18:39 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 456375F984C; Thu, 3 Nov 2011 12:18:17 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id AEEA9216C6A; Thu, 3 Nov 2011 12:18:15 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 07016168C986; Thu, 3 Nov 2011 23:18:11 +1100 (EST) To: Gert Doering From: Mark Andrews References: <4EAB2233.8040908@gmail.com> <4EAB4856.2070002@dougbarton.us> <50CF70B9-3EAA-4897-9AF3-62A8D96C3EFB@cisco.com> <4EADB1C2.8000601@gmail.com> <4EAFB76D.7070208@redpill-linpro.com> <20111102071323.7821D16765EC@drugs.dv.isc.org> <4EB10BDA.3060202@redpill-linpro.com> <20111102111144.8587F1678E96@drugs.dv.isc.org> <20111102141002.GT71280@Space.Net> <20111103000113.B979E1681EC5@drugs.dv.isc.org> <20111103105841.GF71280@Space.Net> In-reply-to: Your message of "Thu, 03 Nov 2011 11:58:41 BST." <20111103105841.GF71280@Space.Net> Date: Thu, 03 Nov 2011 23:18:10 +1100 Message-Id: <20111103121811.07016168C986@drugs.dv.isc.org> Cc: "v6ops@ietf.org" , "draft-carpenter-v6ops-icp-guidance@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-carpenter-v6ops-icp-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 Nov 2011 12:18:40 -0000 In message <20111103105841.GF71280@Space.Net>, Gert Doering writes: > > Hi > > On Thu, Nov 03, 2011 at 11:01:13AM +1100, Mark Andrews wrote: > > The entire 6to4 fiasco with web clients is because they did not > > handle multi-homed servers. If they handled multi-homed servers > > (a bug that was reported long before there was much if any dual > > stacked servers) they would have handled 6to4 issues. They would > > have connected / fallen back to IPv4 when the IPv6 path was blocked > > due to stupid firewall blocking the encapulated packets. > > One of us seems to be a bit decoupled from reality. > > All the clients (that have been adapted to IPv6 in the first place) *do*=20 > fall over if IPv6 connection fails, and they used to do so by following=20 > the sample implementation in the RFC that explained that you should use=20 > getaddrinfo() and then loop on the results, trying to connect to each=20 > address in sequence. It's sample code. Not the "Holy Writ". If you needed to fall over faster you were free to do so. There have been application that have done so. > And as a result, they fall over *after timeouting* on connect(), again > following the RFCs on how long a TCP connect should try. Yet these browser vendors have years old bug reports saying that their performance sucked, especially when a IPv6 address was unreachable, and didn't do anything about it. > Which works fine if you either have connectivity, or have an ICMP error > or TCP reset coming back, but "firewalls blocking the encapsulated packets" > exactly do not do so - so it's blackholing, and 30 seconds to 1.5 minutes > wait time before trying the next address in the list (which is completely > unacceptable for a content provider trying to serve web stuff). > > So where exactly did "the web clients" fail to implement the authoritative > RFCs on this? So did the RFC's also say they couldn't remember which address worked and using for the next element of the page? The browser developers just didn't think about this. > 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 > > --IfZ+tgy+ooJOsAAy > Content-Type: application/pgp-signature > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (FreeBSD) > > iQCVAwUBTrJz4akuBuNlUUl1AQLnWwP/akivmkkzuE+8V0Qe3qQUHS1KZNmROh/o > fXK2JKcX57QVy1DDk3cDbCQrWpHh2WsEVIk0QgUgqlJgi8MpsFIf4PLO/TKt/v5o > DOah40fcB5945QwztImd4cQ1Ew64WlK++BH+gLP7ekBOTAQPD/E4qnONQKsn3r7k > SOom4o4Kfwc= > =4IF8 > -----END PGP SIGNATURE----- > > --IfZ+tgy+ooJOsAAy-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From pch-b29AA871B@u-1.phicoh.com Thu Nov 3 05:53:20 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88A1311E80A3 for ; Thu, 3 Nov 2011 05:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.455 X-Spam-Level: X-Spam-Status: No, score=-8.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, GB_I_LETTER=-2, 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 VBegKSuQNCbG for ; Thu, 3 Nov 2011 05:53:20 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 753AC11E808E for ; Thu, 3 Nov 2011 05:53:19 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #76) id m1RLwnF-0001ZoC; Thu, 3 Nov 2011 13:53:17 +0100 Message-Id: To: Mark Andrews From: Philip Homburg Sender: pch-b29AA871B@u-1.phicoh.com References: <4EAB2233.8040908@gmail.com> <4EAB4856.2070002@dougbarton.us> <50CF70B9-3EAA-4897-9AF3-62A8D96C3EFB@cisco.com> <4EADB1C2.8000601@gmail.com> <4EAFB76D.7070208@redpill-linpro.com> <20111102071323.7821D16765EC@drugs.dv.isc.org> <4EB10BDA.3060202@redpill-linpro.com> <20111102111144.8587F1678E96@drugs.dv.isc.org> <20111102141002.GT71280@Space.Net> <20111103000113.B979E1681EC5@drugs.dv.isc.org> <20111103105841.GF71280@Space.Net> <20111103121811.07016168C986@drugs.dv.isc.org> In-reply-to: Your message of "Thu, 03 Nov 2011 23:18:10 +1100 ." <20111103121811.07016168C986@drugs.dv.isc.org> Date: Thu, 03 Nov 2011 13:52:56 +0100 Cc: "v6ops@ietf.org" , "draft-carpenter-v6ops-icp-guidance@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-carpenter-v6ops-icp-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 Nov 2011 12:53:20 -0000 In your letter dated Thu, 03 Nov 2011 23:18:10 +1100 you wrote: >It's sample code. Not the "Holy Writ". If you needed to fall over >faster you were free to do so. There have been application that >have done so. Yes, I can see how that works. First we encourage application writers to just come up with their own solutions, and when they have rolled out something that happens to be broken we can complain about it and write BCPs about how it should be done. We would never, like, write a HE specification before it actually became an issue. >Yet these browser vendors have years old bug reports saying that >their performance sucked, especially when a IPv6 address was >unreachable, and didn't do anything about it. And in all that time, nobody bothered to write a BCP about how it should be done. In my experience, implementing HE was hard work. So far we have a set of requirements, which is good, but nothing telling implementors how it should be done. And if it was trivial, Apple would not have gotten it wrong. >So did the RFC's also say they couldn't remember which address >worked and using for the next element of the page? The browser >developers just didn't think about this. The days that the contents of a website came form just a single server are long gone. The 'nice' thing about applications caching name to address mappings is that they don't know the DNS TTLs. Creating all kinds of other problems. I think that for the same origin policy, browsers already have to use the same IP address as they used earlier, but I don't know if they do that in practice. From phdgang@gmail.com Thu Nov 3 05:59:41 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFC0E11E80FC for ; Thu, 3 Nov 2011 05:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.974 X-Spam-Level: X-Spam-Status: No, score=-2.974 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C2MQXX8kSx4r for ; Thu, 3 Nov 2011 05:59:40 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3632911E80AC for ; Thu, 3 Nov 2011 05:59:40 -0700 (PDT) Received: by wyg30 with SMTP id 30so1385674wyg.31 for ; Thu, 03 Nov 2011 05:59:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XD1g9Z4MH8qTd97DYjVKQybcoWfA0PFBeofxSlISbxY=; b=uk9uz5qYdpHBD9pqd0Hf9Lkz2YYmDvobhrpv2910TZhfzAXsfAAHBIFw2rgReuG9NC AbRyIGf+HbbZVb+7a6+3FbcRt9w9kOQxQkSDtvR5jDymcntDk423Lqny/Irbm/RHPDRi +7NwpiGI9o3Fal5crqdvlrAHlUSCxBRBGlWKw= MIME-Version: 1.0 Received: by 10.227.199.5 with SMTP id eq5mr12215404wbb.2.1320325179299; Thu, 03 Nov 2011 05:59:39 -0700 (PDT) Received: by 10.180.102.8 with HTTP; Thu, 3 Nov 2011 05:59:39 -0700 (PDT) In-Reply-To: References: Date: Thu, 3 Nov 2011 20:59:39 +0800 Message-ID: From: GangChen To: Qiong Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops Subject: Re: [v6ops] NAT64 Operational Considerations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 Nov 2011 12:59:41 -0000 hi Qiong, I can hardly understand your points. I mean that is a pretty common use case, not your proprietary. It has already been included in draft-chen-v6ops-nat64-cpe-02 and presented in last IETF meeting. I believe we all here is to find good solutions and contribute the community. I'm very sorry to hear your suspicion, which is against the IETF spirit. That is a place for technical discussion. Don't you think that is inappropriate to make such statement? Gang 2011/11/3, Qiong : > Hi, Gang, > > I'm not against that NAT64 can be deployed in IDC scenario. But actually, > this deployment model is originally proposed by us in > draft-sunq-v6ops-contents-transition-00, don't you think it > is inappropriate to include it without notification to us? > > Best regards > > Qiong > > On Thu, Nov 3, 2011 at 10:00 AM, GangChen wrote: > >> Dear all, >> >> I have just submitted the draft for NAT64 operational consideration. >> The intention is to provide comprehensive considerations for NAT64 >> deployment. >> The detailed information is listed at below >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> Title : NAT64 Operational Considerations >> Author(s) : Gang Chen >> Filename : draft-chen-v6ops-nat64-cpe-03.txt >> Pages : 8 >> Date : 2011-10-31 >> >> The document has summarized NAT64 usages on different modes, in which >> NAT64 may serve for a large-scale network or would give enterprise or >> residential service opportunities to be accessed by IPv6 remote >> subscribers. The document has described different operations for >> each usage and proposed operational considerations for each >> particular NAT64-mode. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-chen-v6ops-nat64-cpe-03.txt >> >> Many thanks >> >> Gang >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > From brian.e.carpenter@gmail.com Thu Nov 3 14:29:47 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01F8A1F0CA4 for ; Thu, 3 Nov 2011 14:29:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.176 X-Spam-Level: X-Spam-Status: No, score=-104.176 tagged_above=-999 required=5 tests=[AWL=0.823, BAYES_00=-2.599, GB_I_LETTER=-2, 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 MvPQC5Jvt2tf for ; Thu, 3 Nov 2011 14:29:46 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 370AC1F0C7F for ; Thu, 3 Nov 2011 14:29:43 -0700 (PDT) Received: by faas12 with SMTP id s12so2402012faa.31 for ; Thu, 03 Nov 2011 14:29:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Wp4jJa4nrKnGQBLS29hevoTYFPd3qKj8uK0ThTuc1QI=; b=KON2EQQ3rDkcxE5msmAMR/UZFayzALiCni3Lq0qKJSuj6V1+WETZhKSPrBecqWZYGv lvaVzyJ44ZgVqCC6YmmuWC59dH5dPZV3Iu140sPluXT21xNGL8s1RMm/sSfQdiGzU02v Ol6KRUQswqnInztRhm3aLjnGEURliyoeqKx+Y= Received: by 10.223.91.68 with SMTP id l4mr19110520fam.16.1320355782245; Thu, 03 Nov 2011 14:29:42 -0700 (PDT) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id k13sm4660398fah.0.2011.11.03.14.29.38 (version=SSLv3 cipher=OTHER); Thu, 03 Nov 2011 14:29:41 -0700 (PDT) Message-ID: <4EB307BC.7030403@gmail.com> Date: Fri, 04 Nov 2011 10:29:32 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Philip Homburg References: <4EAB2233.8040908@gmail.com> <4EAB4856.2070002@dougbarton.us> <50CF70B9-3EAA-4897-9AF3-62A8D96C3EFB@cisco.com> <4EADB1C2.8000601@gmail.com> <4EAFB76D.7070208@redpill-linpro.com> <20111102071323.7821D16765EC@drugs.dv.isc.org> <4EB10BDA.3060202@redpill-linpro.com> <20111102111144.8587F1678E96@drugs.dv.isc.org> <20111102141002.GT71280@Space.Net> <20111103000113.B979E1681EC5@drugs.dv.isc.org> <20111103105841.GF71280@Space.Net> <20111103121811.07016168C986@drugs.dv.isc.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-carpenter-v6ops-icp-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 Nov 2011 21:29:47 -0000 I'm failing to see anything specifically relevant to advice for ICPs in this sub-thread. In the document under discussion, we refer to AAAA whitelisting as a possible tactic and state that: There is little an ICP can do to deal with client-side or remote ISP deficiencies in IPv6 support, but it is hoped that the "happy eyeballs" [I-D.ietf-v6ops-happy-eyeballs] approach will improve the ability for clients to deal with such problems. We probably need to add NAT64 (draft-sunq-v6ops-contents-transition) as an additional scenario. Is there anything else in this sub-thread that constitutes useful advice for ICPs? If not, please change the Subject header ;-) Regards Brian On 2011-11-04 01:52, Philip Homburg wrote: > In your letter dated Thu, 03 Nov 2011 23:18:10 +1100 you wrote: >> It's sample code. Not the "Holy Writ". If you needed to fall over >> faster you were free to do so. There have been application that >> have done so. > > Yes, I can see how that works. First we encourage application writers to just > come up with their own solutions, and when they have rolled out something > that happens to be broken we can complain about it and write BCPs about how > it should be done. > > We would never, like, write a HE specification before it actually became an > issue. > >> Yet these browser vendors have years old bug reports saying that >> their performance sucked, especially when a IPv6 address was >> unreachable, and didn't do anything about it. > > And in all that time, nobody bothered to write a BCP about how it should be > done. > > In my experience, implementing HE was hard work. > > So far we have a set of requirements, which is good, but nothing telling > implementors how it should be done. > > And if it was trivial, Apple would not have gotten it wrong. > >> So did the RFC's also say they couldn't remember which address >> worked and using for the next element of the page? The browser >> developers just didn't think about this. > > The days that the contents of a website came form just a single server are > long gone. > > The 'nice' thing about applications caching name to address mappings is that > they don't know the DNS TTLs. Creating all kinds of other problems. > I think that for the same origin policy, browsers already have to use the same > IP address as they used earlier, but I don't know if they do that in practice. > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From marka@isc.org Thu Nov 3 15:08:36 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 533B41F0CD1 for ; Thu, 3 Nov 2011 15:08:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.59 X-Spam-Level: X-Spam-Status: No, score=-3.59 tagged_above=-999 required=5 tests=[AWL=1.009, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3cusXx2ma613 for ; Thu, 3 Nov 2011 15:08:35 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 5963C1F0C79 for ; Thu, 3 Nov 2011 15:08:35 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 3340BC9427; Thu, 3 Nov 2011 22:08:21 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id A517B216C6A; Thu, 3 Nov 2011 22:08:20 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 5FB8C168D8E6; Fri, 4 Nov 2011 09:08:04 +1100 (EST) To: Philip Homburg From: Mark Andrews References: <4EAB2233.8040908@gmail.com> <4EAB4856.2070002@dougbarton.us> <50CF70B9-3EAA-4897-9AF3-62A8D96C3EFB@cisco.com> <4EADB1C2.8000601@gmail.com> <4EAFB76D.7070208@redpill-linpro.com> <20111102071323.7821D16765EC@drugs.dv.isc.org> <4EB10BDA.3060202@redpill-linpro.com> <20111102111144.8587F1678E96@drugs.dv.isc.org> <20111102141002.GT71280@Space.Net> <20111103000113.B979E1681EC5@drugs.dv.isc.org> <20111103105841.GF71280@Space.Net> <20111103121811.07016168C986@drugs.dv.isc.org> In-reply-to: Your message of "Thu, 03 Nov 2011 13:52:56 BST." Date: Fri, 04 Nov 2011 09:08:04 +1100 Message-Id: <20111103220804.5FB8C168D8E6@drugs.dv.isc.org> Cc: "v6ops@ietf.org" , "draft-carpenter-v6ops-icp-guidance@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-carpenter-v6ops-icp-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 03 Nov 2011 22:08:36 -0000 In message , Philip Homburg writes: > In your letter dated Thu, 03 Nov 2011 23:18:10 +1100 you wrote: > >It's sample code. Not the "Holy Writ". If you needed to fall over > >faster you were free to do so. There have been application that > >have done so. > > Yes, I can see how that works. First we encourage application writers to just > come up with their own solutions, and when they have rolled out something > that happens to be broken we can complain about it and write BCPs about how > it should be done. Web browers were making parallel connections to web servers to speed up performance yet they waited 30+ seconds for a initial connect to succeed when they know that 99.9999% of connections won't succeed if they don't succeed in the first 2 seconds and users are hitting stop after 5 seconds. They just weren't meeting their users needs. > We would never, like, write a HE specification before it actually became an > issue. Its been a issue for years. People have been saying we can't deploy IPv6 for years because browsers don't failover properly. Browsers have had toggles to turn off IPv6 for years. Those toggles were added because it was a issue. It's becoming a critical issue because most of the net will be dual stacked rsn and people are beging to see they can't delay going dual stack any longer and are there for kicking up a bigger stink to get the browsers fixed. The browser vendors choose not to fix the issue, instead they hid the issue for as long as they could. HE pushes the wait done to the 100's of milliseconds. I order of magnitude faster than application like ssh have been doing for years now. > >Yet these browser vendors have years old bug reports saying that > >their performance sucked, especially when a IPv6 address was > >unreachable, and didn't do anything about it. > > And in all that time, nobody bothered to write a BCP about how it should be > done. Because it shouldn't have needed a BCP. Non blocking connect was introduces in BSD 4.3 if my memory is correct. I know I've been using non blocking connects for about as long as they have existed as I've had applications that just can't afford to block. > In my experience, implementing HE was hard work. > > So far we have a set of requirements, which is good, but nothing telling > implementors how it should be done. > > And if it was trivial, Apple would not have gotten it wrong. Apple tried to be over smart and didn't listen to the advice given to them. Apple have IPv6 aware applications that don't work in a IPv6 only environment. Apple have TCP based applications, that they have written, that don't fallback to IPv4 if they can't reach the server over IPv6. They just don't try the other address. > >So did the RFC's also say they couldn't remember which address > >worked and using for the next element of the page? The browser > >developers just didn't think about this. > > The days that the contents of a website came form just a single server are > long gone. > > The 'nice' thing about applications caching name to address mappings is that > they don't know the DNS TTLs. Creating all kinds of other problems. > I think that for the same origin policy, browsers already have to use the sam > e > IP address as they used earlier, but I don't know if they do that in practice > . And applications are free to retrieve the DNS TTL if they want. The tools for doing this are decades old. Most applications don't need to know the DNS TTL. They make a single connection. For many applications waiting 30 seconds for connect to fail is not a issue especially if they are doing other things at the same time. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From bingxuere@gmail.com Thu Nov 3 19:05:28 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEE461F0C48 for ; Thu, 3 Nov 2011 19:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.143 X-Spam-Level: X-Spam-Status: No, score=-2.143 tagged_above=-999 required=5 tests=[AWL=-0.811, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_FWDLOOK=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 fYonjTWcINAf for ; Thu, 3 Nov 2011 19:05:26 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8EAAC1F0C3D for ; Thu, 3 Nov 2011 19:05:26 -0700 (PDT) Received: by iaeo4 with SMTP id o4so2570265iae.31 for ; Thu, 03 Nov 2011 19:05:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=WfShNdoZqWo8RB83/ulpC8OeHBjQdYl3y0TTM9ofAAU=; b=Pqk4CZ3NcbXCKhcO9o++y/XP+utJOGankxSoQjJB9D7ui437X5ZPHUg6zcL927T0ih gLlTH+1DuPZyuNRHqXap0MqcjiJkFFnUG2ghyeMdTHoVvXXprym4rTfU2+F9a+PVexWC b72cToJ3aGTYt44j9s+2wBCWEuaivUoBxaXs8= Received: by 10.42.133.201 with SMTP id i9mr12150215ict.1.1320372326063; Thu, 03 Nov 2011 19:05:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.218.10 with HTTP; Thu, 3 Nov 2011 19:04:45 -0700 (PDT) In-Reply-To: <4EB1A443.1000301@gmail.com> References: <4EB05384.5000007@gmail.com> <4EB1A443.1000301@gmail.com> From: Qiong Date: Fri, 4 Nov 2011 10:04:45 +0800 Message-ID: To: Brian E Carpenter Content-Type: multipart/alternative; boundary=90e6ba3fcc23775dc704b0df237f Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Fwd: New Version Notification for draft-sunq-v6ops-contents-transition-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: Fri, 04 Nov 2011 02:05:28 -0000 --90e6ba3fcc23775dc704b0df237f Content-Type: text/plain; charset=UTF-8 Hi Brian, Please see inline :) On Thu, Nov 3, 2011 at 4:12 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > > > > > Does Google upgrade all their services directly on IPv6, or use some kind > > of translation or proxy mechanism within its servers? I heard that > Youtube > > has adopted LISP+NAT64 for its own transition, > > LISP??? > Sorry, I remember wrong. It is facebook who has adopted LISP to offer IPv6 service, not google. Sorry for that mistake. > > > and Yahoo has also deployed > > several translation POPs around the world. I'm not sure whether it is > > correct or not. Please correct me if I'm wrong :) > > Of course, google is a very good example and we all hope many other ICPs > > will follow it in a short time. > > And credit where it is due: the discussion about outside-in vs inside-out > approaches in draft-carpenter-v6ops-icp-guidance came from an off-list > message > from Erik Kline at Google. The point is, using a dual stack proxy or a > NAT64 > as a front-end interface to the IPv6 Internet is the first step in an > outside-in > approach. It's a starting point, not a permanent solution. > I agree that it is only a transition approach for ICP. We believe IPv6-only support should be our final objective. However, the starting point is quite important for us all, especially when IPv6 is under discussing for so many years. Thanks for your understanding, and I do think your draft is a good reference for ICPs who would like to adopt dual-stack upgrading. Personally I think a proxy is a more forward-looking solution, but NAT64 is > a little more efficient, as a student of mine has proved. > (See http://www.cs.auckland.ac.nz/~brian/NAT64-perf-Beijing.pdf) > Sorry, I'm kind of confused by the comparison result. It seems the performance of NAT64 would decrease significantly for Big request. But in our performance test, both on prototype and commercial device, we do not find such problem. I can share you with our test results later. > I think my main issue with your draft is the way the proposal is > described in section 3.1. If it was described as the first step > towards a complete solution according to RFC6180, I would > be much happier. > > Best wishes Qiong > Brian > > > > > > >> Through our Internet border, we are now doing 600 GB/day (10%) IPv6 > >> traffic inbound > >> and 60 GB/day (1.5%) IPv6 traffic outbound. > >> > >> Google have broken the chicken v. egg impasse. > >> Enable IPv6 on Facebook, other CDNs etc and we could have a lot of IPv6 > >> traffic! > >> > > > > Very good news! I believe the traffic volume is the most exciting info > for > > us. In China, we also have a great volume of IPv6 traffic in CERNET2 > (China > > Education Network for next generation Internet), which is a IPv6-only > > core-network. We have a lot of IPv6 contents including videos, BT, > forums, > > etc, and the preference policy over IPv6 is applied here. As indicated in > > our draft (Appendix 1.1), more than 91 percent of our IPv6 users come > from > > CERNET2. > > > > However, from operator perspective, I still think the situation here is a > > little bit different in commercial network. Since operator itself is for > > earning money rather than doing research, it would be more harder to > > persuade market people when there is no explicit value for them. After > all, > > IPv6 deployment will cost quite a lot in the short run. So a simple > > question would just come out, why should we invest so much when there is > > still little reachable IPv6 content. > > In the same way, ICPs are also waiting for IPv6 users. In our situation, > > although we already have quite a lot of CERNET2 IPv6 users, it is still > far > > from enough to convince a majority of ICPs upgrading to IPv6 directly. We > > all expect that ICPs would have the same belief with us, that IPv6 is > > definitely the future direction, but here we should make things happen at > > the first step. Anyway, we believe that ICP transition is the key point > to > > IPv6 success. > > > > Best wishes > > > > Qiong > > > > > > Thanks, > >> John > >> > >>> I really > >>> think we need to re-think it again, from both technical aspect and the > >>> industry/or market aspect. And the first step is rather important to > >> give us > >>> confidence to move forward. That's why we recommend single-stack > (either > >> v4 > >>> or v6) transition in the current phase. Then, for the conservative > >> ones, the > >>> IPv4 services can be still offered natively, and the IPv6 services can > be > >>> offered by the stateful NAT64; while for progressive ones and newly > >> comers, > >>> the stateless IVI can be employed to offer native IPv6 services > reachable > >>> via IPv4. And we hope it would help enrich IPv6 content asap. Then how > do > >>> you think ? > >>> Thanks > >>> Qiong > >>> > >>> On Wed, Nov 2, 2011 at 4:16 AM, Brian E Carpenter > >>> wrote: > >>>> I'm not seeing why this is a better solution for a small/medium ICP > >>>> than just moving to a dual stack. That is much easier for a small > >>>> network than for a big one. > >>>> > >>>> Regards > >>>> Brian > >>>> > >>> _______________________________________________ > >>> v6ops mailing list > >>> v6ops@ietf.org > >>> https://www.ietf.org/mailman/listinfo/v6ops > >>> > >>> > > > --90e6ba3fcc23775dc704b0df237f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Brian,

Please see inline :)

On Thu, Nov 3, 2011 at 4:12 AM, Brian E Carpenter <brian.e.carpenter@gmai= l.com> wrote:

>
> Does Google upgrade all their services directly on IPv6, or use some k= ind
> of translation or proxy mechanism within its servers? I heard that You= tube
> has adopted LISP+NAT64 for its own transition,

LISP???
Sorry, I remember wrong. It is facebook = who has adopted LISP to offer IPv6 service, not google. Sorry for that mist= ake. =C2=A0

> and Yahoo has also deployed
> several translation POPs around the world. I'm not sure whether it= is
> correct or not. Please correct me if I'm wrong :)
> Of course, google is a very good example and we all hope many other IC= Ps
> will follow it in a short time.

And credit where it is due: the discussion about outside-in vs inside= -out
approaches in draft-carpenter-v6ops-icp-guidance came from an off-list mess= age
from Erik Kline at Google. The point is, using a dual stack proxy or a NAT6= 4
as a front-end interface to the IPv6 Internet is the first step in an outsi= de-in
approach. It's a starting point, not a permanent solution.

I agree that it is only a transition approach for I= CP. We believe IPv6-only support should be our final objective. However, th= e starting point is quite important for us all, especially when IPv6 is und= er discussing for so many years.=C2=A0
Thanks for your understanding, and I do think your draft is a good ref= erence for ICPs who would like to adopt dual-stack upgrading.
Personally I think a proxy is a more forward-looking solution, but NAT64 is=
a little more efficient, as a student of mine has proved.
(See http://www.cs.auckland.ac.nz/~brian/NAT64-perf-Beijing.p= df)
Sorry, I'm kind of confused by the compari= son result. It seems the performance of NAT64 would decrease significantly = for Big request. But in our performance test, both on prototype and=C2=A0co= mmercial=C2=A0device, we do not find such problem. I can share you with our= test results later.
=C2=A0
I think my main issue with your draft is the way the proposal is
described in section 3.1. If it was described as the first step
towards a complete solution according to RFC6180, I would
be much happier.


Best wi= shes

Qiong
=C2=A0
=C2=A0 Brian

>
>
>> Through our Internet border, we are now doing 600 GB/day (10%) IPv= 6
>> traffic inbound
>> and 60 GB/day (1.5%) IPv6 traffic outbound.
>>
>> Google have broken the chicken v. egg impasse.
>> Enable IPv6 on Facebook, other CDNs etc and we could have a lot of= IPv6
>> traffic!
>>
>
> Very good news! I believe the traffic volume is the most exciting info= for
> us. In China, we also have a great volume of IPv6 traffic in CERNET2 (= China
> Education Network for next generation Internet), which is a IPv6-only<= br> > core-network. We have a lot of IPv6 contents including videos, BT, for= ums,
> etc, and the preference policy over IPv6 is applied here. As indicated= in
> our draft (Appendix 1.1), more than 91 percent of our IPv6 users come = from
> CERNET2.
>
> However, from operator perspective, I still think the situation here i= s a
> little bit different in commercial network. Since operator itself is f= or
> earning money rather than doing research, it would be more harder to > persuade market people when there is no explicit value for them. After= all,
> IPv6 deployment will cost quite a lot in the short run. So a simple > question would just come out, why should we invest so much when there = is
> still little reachable IPv6 content.
> In the same way, ICPs are also waiting for IPv6 users. In our situatio= n,
> although we already have quite a lot of CERNET2 IPv6 users, it is stil= l far
> from enough to convince a majority of ICPs upgrading to IPv6 directly.= We
> all expect that ICPs would have the same belief with us, that IPv6 is<= br> > definitely the future direction, but here we should make things happen= at
> the first step. Anyway, we believe that ICP transition is the key poin= t to
> IPv6 success.
>
> Best wishes
>
> Qiong
>
>
> Thanks,
>> =C2=A0 =C2=A0 John
>>
>>> =C2=A0I really
>>> think we need to re-think it again, from both technical aspect= and the
>>> industry/or market aspect. And the first step is rather import= ant to
>> give us
>>> confidence to move forward. That's why we recommend single= -stack (either
>> v4
>>> or v6) transition in the current phase. Then, for the conserva= tive
>> ones, the
>>> IPv4 services can be still offered natively, and the IPv6 serv= ices can be
>>> offered by the stateful NAT64; while for progressive ones and = newly
>> comers,
>>> the stateless IVI can be employed to offer native IPv6 service= s reachable
>>> via IPv4. And we hope it would help enrich IPv6 content asap. = Then how do
>>> you think ?
>>> Thanks
>>> Qiong
>>>
>>> On Wed, Nov 2, 2011 at 4:16 AM, Brian E Carpenter
>>> <brian.e.car= penter@gmail.com> wrote:
>>>> I'm not seeing why this is a better solution for a sma= ll/medium ICP
>>>> than just moving to a dual stack. That is much easier for = a small
>>>> network than for a big one.
>>>>
>>>> Regards
>>>> =C2=A0 Brian
>>>>
>>> _______________________________________________
>>> v6ops mailing list
>>> v6ops@ietf.org
>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>
>>>
>

--90e6ba3fcc23775dc704b0df237f-- From cb.list6@gmail.com Thu Nov 3 19:21:12 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D20F11E80F0 for ; Thu, 3 Nov 2011 19:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.829 X-Spam-Level: X-Spam-Status: No, score=-1.829 tagged_above=-999 required=5 tests=[AWL=-0.497, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_FWDLOOK=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 m5Notyi-alwg for ; Thu, 3 Nov 2011 19:21:11 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1549911E8089 for ; Thu, 3 Nov 2011 19:21:11 -0700 (PDT) Received: by iaeo4 with SMTP id o4so2585461iae.31 for ; Thu, 03 Nov 2011 19:21:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/KPyjP6ZDVMK0OzwsHPSdyh4Z/Emh74RKsc6jxfIPeo=; b=Xunl2OBngC32L8ogVq++G3c5Q7a2WI6E7UrFsFpG6If3oGnpvPmGAkQZXE9Q3CcvCV kpKjR1j4ed30nTbsIJpe+vLu/qPp7W1f2eXmQHkZbX/TbOXfdHJDy6KVTqN+T06oPBxG 1LrY+SrMTqVE5EGPrrESIILb2H7XxG9oVdphg= MIME-Version: 1.0 Received: by 10.42.149.71 with SMTP id u7mr12322454icv.37.1320373269085; Thu, 03 Nov 2011 19:21:09 -0700 (PDT) Received: by 10.142.230.8 with HTTP; Thu, 3 Nov 2011 19:21:08 -0700 (PDT) Received: by 10.142.230.8 with HTTP; Thu, 3 Nov 2011 19:21:08 -0700 (PDT) In-Reply-To: References: <4EB05384.5000007@gmail.com> <4EB1A443.1000301@gmail.com> Date: Thu, 3 Nov 2011 19:21:08 -0700 Message-ID: From: Cameron Byrne To: Qiong Content-Type: multipart/alternative; boundary=90e6ba2121b7acbd9304b0df5bd3 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Fwd: New Version Notification for draft-sunq-v6ops-contents-transition-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: Fri, 04 Nov 2011 02:21:12 -0000 --90e6ba2121b7acbd9304b0df5bd3 Content-Type: text/plain; charset=ISO-8859-1 On Nov 3, 2011 7:05 PM, "Qiong" wrote: > > Hi Brian, > > Please see inline :) > > On Thu, Nov 3, 2011 at 4:12 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: >> >> >> > >> > Does Google upgrade all their services directly on IPv6, or use some kind >> > of translation or proxy mechanism within its servers? I heard that Youtube >> > has adopted LISP+NAT64 for its own transition, >> >> LISP??? > > Sorry, I remember wrong. It is facebook who has adopted LISP to offer IPv6 service, not google. Sorry for that mistake. They also offer non-LISP ipv6 at www.v6.facebook.com >> >> >> > and Yahoo has also deployed >> > several translation POPs around the world. I'm not sure whether it is >> > correct or not. Please correct me if I'm wrong :) >> > Of course, google is a very good example and we all hope many other ICPs >> > will follow it in a short time. >> >> And credit where it is due: the discussion about outside-in vs inside-out >> approaches in draft-carpenter-v6ops-icp-guidance came from an off-list message >> from Erik Kline at Google. The point is, using a dual stack proxy or a NAT64 >> as a front-end interface to the IPv6 Internet is the first step in an outside-in >> approach. It's a starting point, not a permanent solution. > > > I agree that it is only a transition approach for ICP. We believe IPv6-only support should be our final objective. However, the starting point is quite important for us all, especially when IPv6 is under discussing for so many years. > Thanks for your understanding, and I do think your draft is a good reference for ICPs who would like to adopt dual-stack upgrading. > >> Personally I think a proxy is a more forward-looking solution, but NAT64 is >> a little more efficient, as a student of mine has proved. >> (See http://www.cs.auckland.ac.nz/~brian/NAT64-perf-Beijing.pdf) > > Sorry, I'm kind of confused by the comparison result. It seems the performance of NAT64 would decrease significantly for Big request. But in our performance test, both on prototype and commercial device, we do not find such problem. I can share you with our test results later. > >> >> I think my main issue with your draft is the way the proposal is >> described in section 3.1. If it was described as the first step >> towards a complete solution according to RFC6180, I would >> be much happier. >> > > Best wishes > > Qiong > >> >> Brian >> >> > >> > >> >> Through our Internet border, we are now doing 600 GB/day (10%) IPv6 >> >> traffic inbound >> >> and 60 GB/day (1.5%) IPv6 traffic outbound. >> >> >> >> Google have broken the chicken v. egg impasse. >> >> Enable IPv6 on Facebook, other CDNs etc and we could have a lot of IPv6 >> >> traffic! >> >> >> > >> > Very good news! I believe the traffic volume is the most exciting info for >> > us. In China, we also have a great volume of IPv6 traffic in CERNET2 (China >> > Education Network for next generation Internet), which is a IPv6-only >> > core-network. We have a lot of IPv6 contents including videos, BT, forums, >> > etc, and the preference policy over IPv6 is applied here. As indicated in >> > our draft (Appendix 1.1), more than 91 percent of our IPv6 users come from >> > CERNET2. >> > >> > However, from operator perspective, I still think the situation here is a >> > little bit different in commercial network. Since operator itself is for >> > earning money rather than doing research, it would be more harder to >> > persuade market people when there is no explicit value for them. After all, >> > IPv6 deployment will cost quite a lot in the short run. So a simple >> > question would just come out, why should we invest so much when there is >> > still little reachable IPv6 content. >> > In the same way, ICPs are also waiting for IPv6 users. In our situation, >> > although we already have quite a lot of CERNET2 IPv6 users, it is still far >> > from enough to convince a majority of ICPs upgrading to IPv6 directly. We >> > all expect that ICPs would have the same belief with us, that IPv6 is >> > definitely the future direction, but here we should make things happen at >> > the first step. Anyway, we believe that ICP transition is the key point to >> > IPv6 success. >> > >> > Best wishes >> > >> > Qiong >> > >> > >> > Thanks, >> >> John >> >> >> >>> I really >> >>> think we need to re-think it again, from both technical aspect and the >> >>> industry/or market aspect. And the first step is rather important to >> >> give us >> >>> confidence to move forward. That's why we recommend single-stack (either >> >> v4 >> >>> or v6) transition in the current phase. Then, for the conservative >> >> ones, the >> >>> IPv4 services can be still offered natively, and the IPv6 services can be >> >>> offered by the stateful NAT64; while for progressive ones and newly >> >> comers, >> >>> the stateless IVI can be employed to offer native IPv6 services reachable >> >>> via IPv4. And we hope it would help enrich IPv6 content asap. Then how do >> >>> you think ? >> >>> Thanks >> >>> Qiong >> >>> >> >>> On Wed, Nov 2, 2011 at 4:16 AM, Brian E Carpenter >> >>> wrote: >> >>>> I'm not seeing why this is a better solution for a small/medium ICP >> >>>> than just moving to a dual stack. That is much easier for a small >> >>>> network than for a big one. >> >>>> >> >>>> Regards >> >>>> Brian >> >>>> >> >>> _______________________________________________ >> >>> 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 > --90e6ba2121b7acbd9304b0df5bd3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Nov 3, 2011 7:05 PM, "Qiong" <bingxuere@gmail.com> wrote:
>
> Hi Brian,
>
> Please see inline :)
>
> On Thu, Nov 3, 2011 at 4:12 AM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote: >>
>>
>> >
>> > Does Google upgrade all their services directly on IPv6, or u= se some kind
>> > of translation or proxy mechanism within its servers? I heard= that Youtube
>> > has adopted LISP+NAT64 for its own transition,
>>
>> LISP???
>
> Sorry, I remember wrong. It is facebook who has adopted LISP to offer = IPv6 service, not google. Sorry for that mistake. =A0

They also offer non-LISP ipv6 at = www.v6.facebook.com

>>
>>
>> > and Yahoo has also deployed
>> > several translation POPs around the world. I'm not sure w= hether it is
>> > correct or not. Please correct me if I'm wrong :)
>> > Of course, google is a very good example and we all hope many= other ICPs
>> > will follow it in a short time.
>>
>> And credit where it is due: the discussion about outside-in vs ins= ide-out
>> approaches in draft-carpenter-v6ops-icp-guidance came from an off-= list message
>> from Erik Kline at Google. The point is, using a dual stack proxy = or a NAT64
>> as a front-end interface to the IPv6 Internet is the first step in= an outside-in
>> approach. It's a starting point, not a permanent solution.
>
>
> I agree that it is only a transition approach for ICP. We believe IPv6= -only support should be our final objective. However, the starting point is= quite important for us all, especially when IPv6 is under discussing for s= o many years.=A0
> Thanks for your understanding, and I do think your draft is a good ref= erence for ICPs who would like to adopt dual-stack upgrading.
>
>> Personally I think a proxy is a more forward-looking solution, but= NAT64 is
>> a little more efficient, as a student of mine has proved.
>> (See http://www.cs.auckland.ac.nz/~brian/NAT64-perf-Beijing.pdf) >
> Sorry, I'm kind of confused by the comparison result. It seems the= performance of NAT64 would decrease significantly for Big request. But in = our performance test, both on prototype and=A0commercial=A0device, we do no= t find such problem. I can share you with our test results later.
> =A0
>>
>> I think my main issue with your draft is the way the proposal is >> described in section 3.1. If it was described as the first step >> towards a complete solution according to RFC6180, I would
>> be much happier.
>>
>
> Best wishes
>
> Qiong
> =A0
>>
>> =A0 Brian
>>
>> >
>> >
>> >> Through our Internet border, we are now doing 600 GB/day = (10%) IPv6
>> >> traffic inbound
>> >> and 60 GB/day (1.5%) IPv6 traffic outbound.
>> >>
>> >> Google have broken the chicken v. egg impasse.
>> >> Enable IPv6 on Facebook, other CDNs etc and we could have= a lot of IPv6
>> >> traffic!
>> >>
>> >
>> > Very good news! I believe the traffic volume is the most exci= ting info for
>> > us. In China, we also have a great volume of IPv6 traffic in = CERNET2 (China
>> > Education Network for next generation Internet), which is a I= Pv6-only
>> > core-network. We have a lot of IPv6 contents including videos= , BT, forums,
>> > etc, and the preference policy over IPv6 is applied here. As = indicated in
>> > our draft (Appendix 1.1), more than 91 percent of our IPv6 us= ers come from
>> > CERNET2.
>> >
>> > However, from operator perspective, I still think the situati= on here is a
>> > little bit different in commercial network. Since operator it= self is for
>> > earning money rather than doing research, it would be more ha= rder to
>> > persuade market people when there is no explicit value for th= em. After all,
>> > IPv6 deployment will cost quite a lot in the short run. So a = simple
>> > question would just come out, why should we invest so much wh= en there is
>> > still little reachable IPv6 content.
>> > In the same way, ICPs are also waiting for IPv6 users. In our= situation,
>> > although we already have quite a lot of CERNET2 IPv6 users, i= t is still far
>> > from enough to convince a majority of ICPs upgrading to IPv6 = directly. We
>> > all expect that ICPs would have the same belief with us, that= IPv6 is
>> > definitely the future direction, but here we should make thin= gs happen at
>> > the first step. Anyway, we believe that ICP transition is the= key point to
>> > IPv6 success.
>> >
>> > Best wishes
>> >
>> > Qiong
>> >
>> >
>> > Thanks,
>> >> =A0 =A0 John
>> >>
>> >>> =A0I really
>> >>> think we need to re-think it again, from both technic= al aspect and the
>> >>> industry/or market aspect. And the first step is rath= er important to
>> >> give us
>> >>> confidence to move forward. That's why we recomme= nd single-stack (either
>> >> v4
>> >>> or v6) transition in the current phase. Then, for the= conservative
>> >> ones, the
>> >>> IPv4 services can be still offered natively, and the = IPv6 services can be
>> >>> offered by the stateful NAT64; while for progressive = ones and newly
>> >> comers,
>> >>> the stateless IVI can be employed to offer native IPv= 6 services reachable
>> >>> via IPv4. And we hope it would help enrich IPv6 conte= nt asap. Then how do
>> >>> you think ?
>> >>> Thanks
>> >>> Qiong
>> >>>
>> >>> On Wed, Nov 2, 2011 at 4:16 AM, Brian E Carpenter
>> >>> <br= ian.e.carpenter@gmail.com> wrote:
>> >>>> I'm not seeing why this is a better solution = for a small/medium ICP
>> >>>> than just moving to a dual stack. That is much ea= sier for a small
>> >>>> network than for a big one.
>> >>>>
>> >>>> Regards
>> >>>> =A0 Brian
>> >>>>
>> >>> _______________________________________________
>> >>> v6ops mailing list
>> >>> v6ops@ietf.org<= br> >> >>> https://www.ietf.org/mailman/listinfo/v6ops
>> >>>
>> >>>
>> >
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops
>

--90e6ba2121b7acbd9304b0df5bd3-- From jacniq@gmail.com Thu Nov 3 20:28:16 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CFC511E809C for ; Thu, 3 Nov 2011 20:28:16 -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 8WBXcdcPTqBC for ; Thu, 3 Nov 2011 20:28:15 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8C28411E8089 for ; Thu, 3 Nov 2011 20:28:15 -0700 (PDT) Received: by vws5 with SMTP id 5so2047156vws.31 for ; Thu, 03 Nov 2011 20:28:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Vrt0RXmmzozYLueVqZpFGo8vXT8gnXQ+tdE9tP0FNbw=; b=uZ1DmqIqYTGlSaTKXe4lq/5L6wwdpPAzw/4esDaMmsgSC+hIm/oFm8UeoiJ4C5aWFK bhWSeA45dJmclSaxSc1z5diLatc6QgZ65+mwlRWvZZw2M3LbG3Yxjwd3M3pI0IWWKNfm GzzaEhUVUN9KLGToWPOjsUBhkkwQHBUAf6B1I= MIME-Version: 1.0 Received: by 10.52.36.109 with SMTP id p13mr12783416vdj.59.1320377293809; Thu, 03 Nov 2011 20:28:13 -0700 (PDT) Received: by 10.52.187.161 with HTTP; Thu, 3 Nov 2011 20:28:13 -0700 (PDT) In-Reply-To: References: Date: Fri, 4 Nov 2011 11:28:13 +0800 Message-ID: From: Jacni Qin To: Tore Anderson Content-Type: multipart/alternative; boundary=20cf3079bfee9127af04b0e04bdd Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: New Version Notification for draft-sunq-v6ops-contents-transition-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: Fri, 04 Nov 2011 03:28:16 -0000 --20cf3079bfee9127af04b0e04bdd Content-Type: text/plain; charset=ISO-8859-1 Hi Tore, Thanks for your careful review and comments, inline please, On Thu, Nov 3, 2011 at 8:06 AM, Tore Anderson < tore.anderson@redpill-linpro.com> wrote: > ... > > 5) I believe there should be some discussion of potential issues arising > from the fact that the IPv6 header usually is 20 bytes larger than an > IPv4 header: > > We are following the specifications in RFC6145/6146 about the fragment issue. > Assuming a standard Ethernet MTU of 1500 bytes, if a translator receives > a maximum-sized IPv4 packet with the Don't Fragment flag unset, the > translator needs to fragment the packet when translating to IPv6. This > has some potential side-effects, as the addition of the IPv6 Extension > Header may prevent firewalls and similar middleware boxes from correctly > evaluating the fragmented packets according to ACLs or similar. > > True, this has been mentioned in, http://tools.ietf.org/html/rfc6145#page-6 the recommended approach as well. > Use of a 1520 bytes large MTU in the IPv6 network between the translator > and the server may be one way to deal with this problem, in the IVI > scenario. Also, when using TCP, an IPv6 server using MTU 1500 will > generally ensure sufficiently small enough MSS is negotiated so that the > IPv4 client is prevented from ever sending larger IPv4 packets than 1480 > bytes, which will not require fragmentation. In the stateful scenario, > this issue can be avoided by using a Layer-4/7 proxy rather than NAT64. > > Please see above the reference, thanks Cheers, Jacni --20cf3079bfee9127af04b0e04bdd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Tore,

Thanks for your careful r= eview and comments, inline please,

On Thu, Nov 3, 2011 at 8:06 AM, Tore Anderson <tore.anderson@redpill-linpro.= com> wrote:
...

5) I believe there should be some discussion of potential issues arising from the fact that the IPv6 header usually is 20 bytes larger than an
IPv4 header:

We are following the specifications in RFC6145/6146 a= bout the fragment issue.

=A0
Assuming a standard Ethernet MTU of 1500 bytes, if a translator receives a maximum-sized IPv4 packet with the Don't Fragment flag unset, the
translator needs to fragment the packet when translating to IPv6. This
has some potential side-effects, as the addition of the IPv6 Extension
Header may prevent firewalls and similar middleware boxes from correctly evaluating the fragmented packets according to ACLs or similar.

True, this has been mentioned in, http://tools.ietf.org/html/rfc6145#page-= 6
the recommended approach as well.

=A0
Use of a 1520 bytes large MTU in the IPv6 network between the translator and the server may be one way to deal with this problem, in the IVI
scenario. Also, when using TCP, an IPv6 server using MTU 1500 will
generally ensure sufficiently small enough MSS is negotiated so that the IPv4 client is prevented from ever sending larger IPv4 packets than 1480 bytes, which will not require fragmentation. In the stateful scenario,
this issue can be avoided by using a Layer-4/7 proxy rather than NAT64.

Please see above the reference, thanks


Che= ers,
Jacni
=A0

--20cf3079bfee9127af04b0e04bdd-- From fred@cisco.com Thu Nov 3 23:00:49 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE5311F0C48 for ; Thu, 3 Nov 2011 23:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.596 X-Spam-Level: X-Spam-Status: No, score=-105.596 tagged_above=-999 required=5 tests=[AWL=0.959, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, 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 y8u4fKC3V2W4 for ; Thu, 3 Nov 2011 23:00:48 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id AC4B31F0C45 for ; Thu, 3 Nov 2011 23:00:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=5435; q=dns/txt; s=iport; t=1320386448; x=1321596048; h=from:subject:date:message-id:to:mime-version: content-transfer-encoding; bh=qzi/91t6i71n0nWH+wHKlvY+FF7wL+ovJ0wowZ+PyS8=; b=OYXvjthwY7B6mgH5RahDCHgNF8Btq4LwiXdu30Y8H/Pzpstp0esJG8ZU ooMFjOS0Qo690R56qMGUNlqPH2OQmbBvHANnypThVahwOURmBYG2N6yRe rEEhiZeKO4goDegdYrPtKOtTXcr7BeH2AJ93Bwnqj1d4rL+E3kdZilUKl s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmQIAE1+s06rRDoI/2dsb2JhbABAAyaoPYEhgQUPAQGBYQEBAQIBAgEBDwFUBwMNJwMBAgEjBC4fCQ4TFAsDh2AIlHuBJgGeSoYJgjRiBIgGjBKFMYxB X-IronPort-AV: E=Sophos;i="4.69,454,1315180800"; d="scan'208";a="12285704" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 04 Nov 2011 06:00:48 +0000 Received: from sjo-vlan631-gw.cisco.com (tky-vpn-client-231-136.cisco.com [10.70.231.136]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pA460eh5014770 for ; Fri, 4 Nov 2011 06:00:46 GMT Received: from [127.0.0.1] by sjo-vlan631-gw.cisco.com (PGP Universal service); Fri, 04 Nov 2011 14:00:47 +0900 X-PGP-Universal: processed; by sjo-vlan631-gw.cisco.com on Fri, 04 Nov 2011 14:00:47 +0900 From: Fred Baker Date: Fri, 4 Nov 2011 09:02:30 +0800 Message-Id: To: "v6ops@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: [v6ops] The US Federal Communications Commission just sent the IETF RAI/SIP community an early Christmas present... X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 04 Nov 2011 06:00:49 -0000 For those who are not on the ietf@ietf.org list. Something to pass along = to your legal and regulatory folks, as if they haven't heard about it = yet... I expect that over time this will also become international practice or = expectation, and in some places may already be. But US FCC is telling = traditional voice carriers in the US to add IP interconnection for voice = to their interconnection options if they don't have it already. My guess = is that it's less draconian than it sounds; there has been discussion in = FCC-related circles of turning off the traditional PSTN by 2018, and it = sounds like the FCC is asking carriers to take a step in that direction. = But this will change the VoIP market in a variety of ways. FYI/FYA. > From: "Richard Shockey" > Date: November 3, 2011 7:06:59 AM GMT+08:00 > To: "'IETF-Discussion list'" > Subject: The US Federal Communications Commission just sent the IETF = RAI/SIP community an early Christmas present... >=20 > Folks it was suggested that I resend this message from the RAI list to = the Full Dispatch list but what the heck ... the IETF community needs = to see this. > =20 > What you see here is a very significant policy direction from the US = Federal Communications Commission to the IETF/SIP/RAI community. > =20 > Mandatory IP interconnection between carriers for E.164 named Voice. = In addition there are clauses that mandate non modification of the = calling parties E.164 number in the headers. > =20 > This should come as no surprise to anyone. Our international carrier = partners at i3Forum.org have been preaching this for some time. > =20 > =46rom the FCC executive summary of the Report and Order. =20 > =20 > 26. IP-to-IP Interconnection. We recognize the importance of = interconnection to > competition and the associated consumer benefits. We anticipate that = the reforms we adopt will > further promote the deployment and use of IP networks, and seek = comment in the accompanying > FNPRM regarding the policy framework for IP-to-IP interconnection. We = also make clear that > even while our FNPRM is pending, we expect all carriers to negotiate = in good faith in response to > requests for IP-to-IP interconnection for the exchange of voice = traffic. > =20 > =20 > = http://transition.fcc.gov/Daily_Releases/Daily_Business/2011/db1027/DOC-31= 0692A1.pdf > =20 > =20 > = http://www.snrdenton.com/news__insights/alerts/2011-10-28_overhaul.aspx > =20 > =20 > http://www.dwt.com/LearningCenter/Advisories?find=3D441777 > =20 > =20 > I wish to make it clear that I=92m personally willing to privately = discuss with the technical community how we can transition our industry = to the all SIP network. > =20 > If you want to speculate on how you translate a E.164 number to a = point of interconnection ..you can, but RFC 6116 is not a bad starting = point though Global SPID identifiers would work. ( I gladly gave up my = blue dot recently) > =20 > We won! > Richard Shockey > Shockey Consulting > Chairman of the Board of Directors SIP Forum > PSTN Mobile: +1 703.593.2683 > > skype-linkedin-facebook: rshockey101 > http//www.sipforum.org >=20 > =20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf Begin forwarded message: > From: John Leslie > Date: November 4, 2011 8:29:25 AM GMT+08:00 > To: "'IETF-Discussion list'" > Subject: Re: The US Federal Communications Commission just sent the = IETF RAI/SIPcommunity an early Christmas present... >=20 > Richard Shockey wrote: >> From: George Willingmyre [mailto:gtw@gtwassociates.com]=20 >>>=20 >>> I do not know what is the meaning of the sentence,=20 >>>=20 >>> "we expect all carriers to negotiate in good faith in response to = requests >>> for IP-to-IP interconnection for the exchange of voice traffic." >>>=20 >>> Does anyone have insight? >>=20 >> I read it "If you don't play nice .. we're going to make you." You = are >> going to eat your Broccoli and like it and no whining .. >=20 > Hopefully someone better informed than I will respond, but I have > dealt in FCC-speak... :^( >=20 > IMHO, they're talking "obligation to interconnect" between = "carriers" > as required by actual law. >=20 > "interconnect" in FCC-speak means exchange voice traffic at a > "feasible" point. "Carriers" means a regulated voice provider. >=20 > Thus, they mean to "expect" these regulated entities to negotiate > a point of interconnection where they speak IP instead of e.g. SONET. >=20 > And, yes, they will (eventually) force them to interconnect (using > IP) whether or not the "negotiations" succeed. >=20 > Speaking only for myself, I don't read it to impose anything except > on regulated "carriers", and they're opening up themselves to forcing > a particular mechanism and point of connection when negotiation fails. > This, of course, creates an opportunity to educate FCC folks on the > actual technical issues of voice interchange at IP level... >=20 > -- > John Leslie >>=20 >>=20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From fred@cisco.com Thu Nov 3 23:22:59 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A22D01F0C41 for ; Thu, 3 Nov 2011 23:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.51 X-Spam-Level: X-Spam-Status: No, score=-109.51 tagged_above=-999 required=5 tests=[AWL=1.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 rshN1Mz6UJio for ; Thu, 3 Nov 2011 23:22:58 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 479921F0C3D for ; Thu, 3 Nov 2011 23:22:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1302; q=dns/txt; s=iport; t=1320387778; x=1321597378; h=from:subject:date:message-id:cc:to:mime-version: content-transfer-encoding; bh=Wpg1SwbIfBw9gjxC3adKcBS/iSM29hkhdJs8TywEd7A=; b=PV78CrB4Y8RxWS3YRmNtzIwd+FetdsWd2D48jykZgbitCn+/CfMmwiQM NG36v3seP+/3gHn4xOegSevON2BHEvHTyPXbIwWCrrDKrHx6ZQMB5g/EL bEPSBQ6g+wfsy1QmNcsmtvWw6MvnJhRYwpEcWHW2jw6fMcAes3zVPMLn9 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEAKKEs05Io8UR/2dsb2JhbABDqgWBBYILASc/gT41nggBnkOIPWIEiAaMEoUxjEE X-IronPort-AV: E=Sophos;i="4.69,454,1315180800"; d="scan'208";a="59171717" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-2.cisco.com with ESMTP; 04 Nov 2011 06:22:42 +0000 Received: from sjo-vlan631-gw.cisco.com (tky-vpn-client-231-136.cisco.com [10.70.231.136]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pA46McIC010008; Fri, 4 Nov 2011 06:22:39 GMT Received: from [127.0.0.1] by sjo-vlan631-gw.cisco.com (PGP Universal service); Fri, 04 Nov 2011 14:22:41 +0900 X-PGP-Universal: processed; by sjo-vlan631-gw.cisco.com on Fri, 04 Nov 2011 14:22:41 +0900 From: Fred Baker Date: Fri, 4 Nov 2011 14:22:24 +0800 Message-Id: To: "v6ops@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: Ron Bonica Subject: [v6ops] IPv6 Operations - IETF 82 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 04 Nov 2011 06:22:59 -0000 For some reason I'm having issues posting the agenda. The agenda as it = stands right now is as follows, and gives half an hour to each = discussion. I need a speaker from each topic, and whatever slides you = plan to use by 13 November at the latest. Please plan on ten minutes of = presentation at the most, reserving 20 minutes for discussion. IPv6 Operations - IETF 82 Wednesday 9:00-11:30 Agenda bashing=20 Basic Requirements for IPv6 Customer Edge Routers 31-Oct-11 , Operational Neighbor Discovery Problems 24-Oct-11 , Stateless Source Address Mapping for ICMPv6 Packets 25-Jul-11 , Experiences from an IPv6-Only Network in the WIDE Camp Autumn 2011 23-Oct-11 , Thursday 13:00-15:00 Wireline Incremental IPv6 9-Oct-11 , Analysis and recommendation for the ULA usage 21-Oct-11 , IPv6 Guidance for Internet Content and Application Service Providers 21-Oct-11 , Rapid Transition of IPv4 contents to be IPv6-accessible 29-Oct-11 , From fred@cisco.com Thu Nov 3 23:24:33 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65A6F11E80B6 for ; Thu, 3 Nov 2011 23:24:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[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 aucxuVksWg-9 for ; Thu, 3 Nov 2011 23:24:32 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 63E1A11E80B0 for ; Thu, 3 Nov 2011 23:24:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1669; q=dns/txt; s=iport; t=1320387872; x=1321597472; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=L0xJT4zKotUczC1EATOO3yvMmzTBATT0WoRuU3KB3Ig=; b=N6t4QgbTUlZ+69nXQp+nmz6GkDe7TPD0uEGQqYQfHd9eLuaXiAWunAIi SJkXqp0tTX3KuP3mw3QlMTQiHwgz75zU9NE/TpuI6nZbMDFdZLvls7O6k jRPP0H0C1x9S6xsjBZotSijRvXaqk6VXqUDaIPnMYgLXx8naP3CovwtCd 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwFALuEs06Q/khN/2dsb2JhbABDqGSBIYEFgXIBAQEDAQEBAQ8BJzQLBQsLRicwBhMJGYdgCJYgAZ5DiD1iBIgGjBKFMYxB X-IronPort-AV: E=Sophos;i="4.69,454,1315180800"; d="scan'208";a="2393420" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-4.cisco.com with ESMTP; 04 Nov 2011 06:24:30 +0000 Received: from sjo-vlan631-gw.cisco.com (tky-vpn-client-231-136.cisco.com [10.70.231.136]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pA46ORxJ003059; Fri, 4 Nov 2011 06:24:28 GMT Received: from [127.0.0.1] by sjo-vlan631-gw.cisco.com (PGP Universal service); Fri, 04 Nov 2011 14:24:29 +0900 X-PGP-Universal: processed; by sjo-vlan631-gw.cisco.com on Fri, 04 Nov 2011 14:24:29 +0900 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Fri, 4 Nov 2011 14:24:09 +0800 Message-Id: <6511F174-31CA-41CF-8EDB-1F1F6CF75A06@cisco.com> References: To: "v6ops@ietf.org WG" X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: Ron Bonica Subject: Re: [v6ops] IPv6 Operations - IETF 82 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 04 Nov 2011 06:24:33 -0000 Having just said this, I managed to upload the agenda... http://www.ietf.org/proceedings/82/agenda/v6ops.html On Nov 4, 2011, at 2:22 PM, Fred Baker wrote: > For some reason I'm having issues posting the agenda. The agenda as it = stands right now is as follows, and gives half an hour to each = discussion. I need a speaker from each topic, and whatever slides you = plan to use by 13 November at the latest. Please plan on ten minutes of = presentation at the most, reserving 20 minutes for discussion. >=20 >=20 > IPv6 Operations - IETF 82 >=20 > Wednesday 9:00-11:30 >=20 > Agenda bashing=20 > Basic Requirements for IPv6 Customer Edge Routers > 31-Oct-11 , > Operational Neighbor Discovery Problems > 24-Oct-11 , > Stateless Source Address Mapping for ICMPv6 Packets > 25-Jul-11 , > Experiences from an IPv6-Only Network in the WIDE Camp Autumn 2011 > 23-Oct-11 , >=20 > Thursday 13:00-15:00 >=20 > Wireline Incremental IPv6 > 9-Oct-11 , > Analysis and recommendation for the ULA usage > 21-Oct-11 , > IPv6 Guidance for Internet Content and Application Service Providers > 21-Oct-11 , > Rapid Transition of IPv4 contents to be IPv6-accessible > 29-Oct-11 , >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From tore.anderson@redpill-linpro.com Fri Nov 4 01:40:34 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 227FD21F8A7B for ; Fri, 4 Nov 2011 01:40:34 -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 loNg5N4FaRi2 for ; Fri, 4 Nov 2011 01:40:33 -0700 (PDT) Received: from zimbra.redpill-linpro.com (zimbra.redpill-linpro.com [IPv6:2a02:c0:200:c000::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F1FD21F8C1D for ; Fri, 4 Nov 2011 01:40:32 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.redpill-linpro.com (Postfix) with ESMTP id 0C16B103002B; Fri, 4 Nov 2011 09:40:31 +0100 (CET) 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 zffC91AXzSHR; Fri, 4 Nov 2011 09:40:28 +0100 (CET) Received: from echo.linpro.no (unknown [IPv6:2a02:c0:1002:102:21d:60ff:fe48:f59e]) by zimbra.redpill-linpro.com (Postfix) with ESMTPSA id 5FDB91030005; Fri, 4 Nov 2011 09:40:28 +0100 (CET) Message-ID: <4EB3A4FB.1020404@redpill-linpro.com> Date: Fri, 04 Nov 2011 09:40:27 +0100 From: Tore Anderson Organization: Redpill Linpro AS User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110927 Thunderbird/7.0 MIME-Version: 1.0 To: Jacni Qin References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: New Version Notification for draft-sunq-v6ops-contents-transition-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: Fri, 04 Nov 2011 08:40:34 -0000 * Jacni Qin > True, this has been mentioned in, > http://tools.ietf.org/html/rfc6145#page-6 > the recommended approach as well. Thanks for the pointer - I agree, the referenced text here is good enough. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com From pch-b29AA871B@u-1.phicoh.com Fri Nov 4 02:42:55 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22B5A21F8B8F for ; Fri, 4 Nov 2011 02:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.469 X-Spam-Level: X-Spam-Status: No, score=-8.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, GB_I_LETTER=-2, 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 TtRFQ0ipOlwT for ; Fri, 4 Nov 2011 02:42:54 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id EA33E21F8AB8 for ; Fri, 4 Nov 2011 02:42:53 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #76) id m1RMGIW-0001iyC; Fri, 4 Nov 2011 10:42:52 +0100 Message-Id: To: Mark Andrews From: Philip Homburg Sender: pch-b29AA871B@u-1.phicoh.com References: <4EAB2233.8040908@gmail.com> <4EAB4856.2070002@dougbarton.us> <50CF70B9-3EAA-4897-9AF3-62A8D96C3EFB@cisco.com> <4EADB1C2.8000601@gmail.com> <4EAFB76D.7070208@redpill-linpro.com> <20111102071323.7821D16765EC@drugs.dv.isc.org> <4EB10BDA.3060202@redpill-linpro.com> <20111102111144.8587F1678E96@drugs.dv.isc.org> <20111102141002.GT71280@Space.Net> <20111103000113.B979E1681EC5@drugs.dv.isc.org> <20111103105841.GF71280@Space.Net> <20111103121811.07016168C986@drugs.dv.isc.org> <20111103220804.5FB8C168D8E6@drugs.dv.isc.org> In-reply-to: Your message of "Fri, 04 Nov 2011 09:08:04 +1100 ." <20111103220804.5FB8C168D8E6@drugs.dv.isc.org> Date: Fri, 04 Nov 2011 10:42:46 +0100 Cc: "v6ops@ietf.org" Subject: [v6ops] Destination selection (Was: Re: new draft: draft-carpenter-v6ops-icp-guidance ) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 04 Nov 2011 09:42:55 -0000 In your letter dated Fri, 04 Nov 2011 09:08:04 +1100 you wrote: >Its been a issue for years. People have been saying we can't deploy >IPv6 for years because browsers don't failover properly. Browsers >have had toggles to turn off IPv6 for years. Those toggles were >added because it was a issue. It's becoming a critical issue because >most of the net will be dual stacked rsn and people are beging to >see they can't delay going dual stack any longer and are there for >kicking up a bigger stink to get the browsers fixed. I don't like this line of reasoning. If this is something we care about, we should write a RFC detailing how it should be done. If we can't bothered to write an RFC, why would anyone else care? For browser vendors it worked for years, and it still works. Switching off IPv6 solves the problem. No need to invent complicated trickery. As for you suggesting to reduce timeouts to 2 seconds instead of 30. That may help during a short outage, but if my browser would always wait 2 second due to IPv6 failing then I would quickly disable IPv6 (or fix IPv6). So, changing that timeout doesn't fix anything. And it may actually hurt, because there maybe situations where users rely on the 30 second timeout. >HE pushes the wait done to the 100's of milliseconds. I order of >magnitude faster than application like ssh have been doing for years >now. And this is the point where it actuaslly becomes useful. Certainly with stateful HE, it will just work around broken connections. >Because it shouldn't have needed a BCP. Non blocking connect was >introduces in BSD 4.3 if my memory is correct. I know I've been >using non blocking connects for about as long as they have existed >as I've had applications that just can't afford to block. Browsers have been using non blocking connects as long as the first versions of Netscape. That's not the issue. HE is a new game in town. It would have been nice if HE style connecting was suggested in the IPv6 socket RFCs. But it wasn't. >Apple tried to be over smart and didn't listen to the advice given >to them. Apple have IPv6 aware applications that don't work in a >IPv6 only environment. Apple have TCP based applications, that >they have written, that don't fallback to IPv4 if they can't reach >the server over IPv6. They just don't try the other address. That's obviously a bug. But I was referring to case where OSX will connect over IPv4 when a perfectly good IPv6 link is availabe as well. >And applications are free to retrieve the DNS TTL if they want. The tools >for doing this are decades old. Most applications don't need to know the >DNS TTL. They make a single connection. And yet, getaddrinfo doesn't return the TTL. Another example where what's in the RFC is just incomplete. From pch-b29AA871B@u-1.phicoh.com Fri Nov 4 02:49:05 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 352C921F8AB8 for ; Fri, 4 Nov 2011 02:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.481 X-Spam-Level: X-Spam-Status: No, score=-8.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, GB_I_LETTER=-2, 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 3SGHDirukkv8 for ; Fri, 4 Nov 2011 02:49:04 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 6158721F8AB0 for ; Fri, 4 Nov 2011 02:49:04 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #76) id m1RMGOS-0001izC; Fri, 4 Nov 2011 10:49:00 +0100 Message-Id: To: Brian E Carpenter From: Philip Homburg Sender: pch-b29AA871B@u-1.phicoh.com References: <4EAB2233.8040908@gmail.com> <4EAB4856.2070002@dougbarton.us> <50CF70B9-3EAA-4897-9AF3-62A8D96C3EFB@cisco.com> <4EADB1C2.8000601@gmail.com> <4EAFB76D.7070208@redpill-linpro.com> <20111102071323.7821D16765EC@drugs.dv.isc.org> <4EB10BDA.3060202@redpill-linpro.com> <20111102111144.8587F1678E96@drugs.dv.isc.org> <20111102141002.GT71280@Space.Net> <20111103000113.B979E1681EC5@drugs.dv.isc.org> <20111103105841.GF71280@Space.Net> <20111103121811.07016168C986@drugs.dv.isc.org> <4EB307BC.7030403@gmail.com> In-reply-to: Your message of "Fri, 04 Nov 2011 10:29:32 +1300 ." <4EB307BC.7030403@gmail.com> Date: Fri, 04 Nov 2011 10:48:59 +0100 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] new draft: draft-carpenter-v6ops-icp-guidance X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 04 Nov 2011 09:49:05 -0000 In your letter dated Fri, 04 Nov 2011 10:29:32 +1300 you wrote: >I'm failing to see anything specifically relevant to advice for ICPs >in this sub-thread. Yes, quite right. I'm not an ICP, but what seems to be missing from this draft is explict operator experience. Though IPv6 day was mostly smooth and boring there were some interesting gotchas. It may be worth collecting those. This draft seems to have the obvious stuff. But the stuff you would not think of yourself and that you normally only find out the hard way seems to be missing. From gilbert_kim@vanguard.com Fri Nov 4 04:07:59 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C582621F8B7B for ; Fri, 4 Nov 2011 04:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.74 X-Spam-Level: X-Spam-Status: No, score=-4.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ySWr2n0OiGBK for ; Fri, 4 Nov 2011 04:07:59 -0700 (PDT) Received: from pslva865.vanguard.com (pslva865.vanguard.com [192.175.204.35]) by ietfa.amsl.com (Postfix) with ESMTP id 0E41721F8B71 for ; Fri, 4 Nov 2011 04:07:58 -0700 (PDT) Received: from pslva832.vanguard.com (pslva832.vanguard.com [10.17.37.10]) by pslva865.vanguard.com (Sentrion-MTA-4.1.1/Sentrion-MTA-4.1.1) with ESMTP id pA4B7oLn029458 for ; Fri, 4 Nov 2011 07:07:52 -0400 X-DKIM: OpenDKIM Filter v2.1.3 pslva865.vanguard.com pA4B7oLn029458 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=vanguard.com; s=vanguard; t=1320404872; bh=reaTQNMMjeTmhO6t2tIIZz//WkE=; l=823; h=Subject:From:To:Message-ID:Date:MIME-Version:Content-type; b=P+a68swsKVpJ0LhfpMc+qJCliocfwfsodVput+2/HsESII85uZAKOHsNtP06UJi4/ L2+0N2l+Q64O0sD7lPEjw== Received: from pslva867.vanguard.com (pslva867.vanguard.com [10.17.9.44]) by pslva832.vanguard.com (8.14.4/8.14.4) with ESMTP id pA4B7oR0014588 for ; Fri, 4 Nov 2011 07:07:50 -0400 Received: from vgi4mail.vanguard.com (pvnva784.vanguard.com [10.17.128.144]) by pslva867.vanguard.com (Sentrion-MTA-4.1.1/Sentrion-MTA-4.1.1) with ESMTP id pA4B7nIJ010444 for ; Fri, 4 Nov 2011 07:07:49 -0400 Auto-Submitted: auto-generated From: gilbert_kim@vanguard.com To: v6ops@ietf.org Message-ID: Date: Fri, 4 Nov 2011 07:07:48 -0400 X-MIMETrack: Serialize by Router on VGI4Mail/VGI(Release 8.5.2FP2|March 22, 2011) at 11/04/2011 07:07:49 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: [v6ops] Gilbert Kim is out of office. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 11:07:59 -0000 I will be out of the office starting 11/04/2011 and will not return until 11/08/2011. 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 bingxuere@gmail.com Fri Nov 4 06:40:51 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 220D921F8BEC for ; Fri, 4 Nov 2011 06:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.216 X-Spam-Level: X-Spam-Status: No, score=-3.216 tagged_above=-999 required=5 tests=[AWL=0.382, 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 vxKd2mYoWGbn for ; Fri, 4 Nov 2011 06:40:49 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8AA6921F8C17 for ; Fri, 4 Nov 2011 06:40:49 -0700 (PDT) Received: by iaeo4 with SMTP id o4so3326289iae.31 for ; Fri, 04 Nov 2011 06:40:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=S2sL9y6y7cwTcrn+HoPqGocx8SdCOXXFzByPd5NhHpI=; b=GWEOeluUAn6b0QEbBFaoCM086f/FDArt2ocSKJ8zoPcY3p9Xf4yTowTVOuND/feqV+ k4tyiixiIPbJOkahLZZBK2vOZRgyycCJWqVv/H1FqdU8V/5rAQmU3/DP2cEh83n941KV sKvHKdWPRNJh1tgroDAFSzaV2XnA1vpSOqGzk= Received: by 10.42.163.200 with SMTP id d8mr14029814icy.41.1320414049134; Fri, 04 Nov 2011 06:40:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.218.10 with HTTP; Fri, 4 Nov 2011 06:40:08 -0700 (PDT) In-Reply-To: <201111041609169589985@ctbri.com.cn> References: <201111041609169589985@ctbri.com.cn> From: Qiong Date: Fri, 4 Nov 2011 21:40:08 +0800 Message-ID: To: v6ops@ietf.org, tore.anderson@redpill-linpro.com Content-Type: multipart/alternative; boundary=90e6ba6e89dc5ae66b04b0e8da05 Subject: Re: [v6ops] Fwd: New Version Notificationfor draft-sunq-v6ops-contents-transition-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: Fri, 04 Nov 2011 13:40:51 -0000 --90e6ba6e89dc5ae66b04b0e8da05 Content-Type: text/plain; charset=UTF-8 Hi Tore, Thanks a lot for your comments:) Sorry for late reply. Please see inline. > * Qiong > > http://tools.ietf.org/id/draft-sunq-v6ops-contents-transition-02.txt > > > > Your comments will be very much appreciated. Thanks in advance! > Hello, > My comments follow: > 1) Figure 1 displays a single NAT64 gateway that both handles stateless > IPv4-client-to-IPv6-server translations as well as stateful IPv6-client- > to-IPv4-server translations. These two techniques are completely > independent of each other, so I suggest you display this as two separate > translator boxes, and rather mention that the two functions may be co- > located on the same physical hardware. > I'm sorry this figure really causes misunderstanding. It will be clearer to separate these two translator boxes accordingly. > A stateful function is limited by the total amount of flows as well as > the flow initiation rate, it is much more prone to being overloaded > than a stateless function. I therefore generally recommend against co- > locating critical stateful and stateless functions on the same hardware, > unless it can be ensured that an overloading of the stateful function > does not impact the stateless function. > I agree that stateless solution have better scalability compared to stateful ones. But for the question whether they should co-locate in the same hardware or not, I personally think it may depend on the implementation for different vendors. As far as I know, some vendors intend to implement quite a lot transition mechanisms on the same device. In this case, it would be reasonable to deploy them in the same device if the overall performance is ensured. > To prevent confusion, I would also avoid referring to the two distinct > functions with the same name ("NAT64 gateway"). Perhaps "IVI gateway" > would be better for the stateless function? (Or "SIIT gateway", see > below.) > Well, I think SIIT is an old word obsoleted by RFC6145. I have confirmed with Prof. Li (the author of RFC6145) that "stateless translation" is a more accurate word. How do you think of this one? > 2) The header of section 5 ("IPv6-to-IPv4 communication scenario") is > somewhat ambigous. I suggest rewriting it to e.g. "IPv6 client to IPv4 > server communication scenario". Likewise for the title of section 6. > Very good suggestion :) Thanks. > 3) In section 5, I think it should be mentioned that an alternative to > using stateful NAT64 is using a Layer-4 or Layer-7 proxy (e.g. HAProxy). > This has the advantage of sometimes being able to communicate the > original IPv6 source address of the end user to the IPv4 server,e.g., > for geo-location. This can be done by inserting a Layer-7 header such > as HTTP's X-Forwarded-For. > Yes, proxy is another alternative to this scenario. From my perspective, I think NAT64 would have better efficiency and take lower cost compared to Layer-7 method. And it is also application-independent, except for a few ALGs. Besides, we have offered an open API for CPs to retrieve its original IPv6 address when necessary. Actually, for address sharing situation in the future, e.g. NAT444, DS-Lite, etc, one public IPv4 address will be shared among multiple subscribers. This will also have impact on CPs and this kind of binding information is useful for them as well. So, we would like to provide them with a unified API to get binding information. Therefore, I personally prefer network-layer translation as a transition service offered by operators. Layer-7 proxy is also a good solution when CPs would like to deploy it by themselves. > 4) In section 6, it should be pointed out that due to its stateless > nature, the IVI translation function can trivially be made redundant > and load balanced, by using standard routing techniques such as > anycasting and equal-cost multipath routes. This is in my opinion an > enormous advantage over stateful NAT64, which requres symmetric traffic > flow across a single translator box. > Exactly:) That's why we would like to adopt stateless translation here. > 5) I believe there should be some discussion of potential issues arising > from the fact that the IPv6 header usually is 20 bytes larger than an > IPv4 header: > Assuming a standard Ethernet MTU of 1500 bytes, if a translator receives > a maximum-sized IPv4 packet with the Don't Fragment flag unset, the > translator needs to fragment the packet when translating to IPv6. This > has some potential side-effects, as the addition of the IPv6 Extension > Header may prevent firewalls and similar middleware boxes from correctly > evaluating the fragmented packets according to ACLs or similar. > Use of a 1520 bytes large MTU in the IPv6 network between the translator > and the server may be one way to deal with this problem, in the IVI > scenario. Also, when using TCP, an IPv6 server using MTU 1500 will > generally ensure sufficiently small enough MSS is negotiated so that the > IPv4 client is prevented from ever sending larger IPv4 packets than 1480 > bytes, which will not require fragmentation. In the stateful scenario, > this issue can be avoided by using a Layer-4/7 proxy rather than NAT64. > Jacni has explained this part. > 6) I feel that the references to RFC 6219 is wrong. In all three cases > (sections 1, 3.1, and 6), it is used as a normative reference, i.e., as > the IVI protocol specification. However, RFC 6219 is not a protocol > specification as far as I can tell, it is rather just a case study. It > should therefore be an informative reference. > As far as I've been able to understand from reading RFC 6219, the > protocol called "stateless IVI" is in reality specified in RFC 6145 > where it is called "Stateless IP/ICMP Translation" (SIIT). If this is > correct, and there really is no difference between "stateless IVI" and > SIIT, I feel that the use of the name IVI is questionable as it does not > appear once in RFC 6145 (nor in RFC 6052 for that matter). The only > reference I find to the name "IVI" in current IETF docs are in this > draft as well as in RFC 6219 (where it just seems to describe SIIT). > I therefore suggest you replace all mentions of (stateless) IVI with > SIIT, and the related normative references from RFC 6219 to RFC 6145. > Thanks for pointing out this mistake. We will quote RFC6145 and RFC6052 as normative reference and replace RFC6219 as informative reference. Regarding the name issue, how about using "stateless translation" and "stateful translation" ? Thanks again for your detailed review. I very much appreciated it:) Best wishes Qiong > Best regards, > -- > Tore Anderson > --90e6ba6e89dc5ae66b04b0e8da05 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Tore,

Thanks a lot for your comments:) Sorry for late reply.

Please see inline.
=C2=A0
*=C2=A0Qiong
>=C2=A0
>=C2=A0Your=C2=A0comments=C2=A0will=C2=A0be=C2=A0very=C2=A0much=C2= =A0appreciated.=C2=A0Thanks=C2=A0in=C2=A0advance!
Hello,
My=C2=A0comments=C2=A0follow:
1)=C2=A0Figure=C2=A01=C2=A0displays=C2=A0a=C2=A0single=C2=A0NAT64=C2= =A0gateway=C2=A0that=C2=A0both=C2=A0handles=C2=A0stateless
IPv4-client-to-IPv6-server=C2=A0translations=C2=A0as=C2=A0well=C2=A0as= =C2=A0stateful=C2=A0IPv6-client-
to-IPv4-server=C2=A0translations.=C2=A0These=C2=A0two=C2=A0techniques= =C2=A0are=C2=A0completely
independent=C2=A0of=C2=A0each=C2=A0other,=C2=A0so=C2=A0I=C2=A0suggest= =C2=A0you=C2=A0display=C2=A0this=C2=A0as=C2=A0two=C2=A0separate
translator=C2=A0boxes,=C2=A0and=C2=A0rather=C2=A0mention=C2=A0that=C2= =A0the=C2=A0two=C2=A0functions=C2=A0may=C2=A0be=C2=A0co-
located=C2=A0on=C2=A0the=C2=A0same=C2=A0physical=C2=A0hardware.
<= /font>
I'm sorry this figure really causes misunde= rstanding. It will be clearer to separate these two translator boxes accord= ingly.
A=C2=A0stateful=C2=A0function=C2=A0is=C2=A0limited=C2=A0by=C2=A0the=C2= =A0total=C2=A0amount=C2=A0of=C2=A0flows=C2=A0as=C2=A0well=C2=A0as
the=C2=A0flow=C2=A0initiation=C2=A0rate,=C2=A0it=C2=A0is=C2=A0much=C2= =A0more=C2=A0prone=C2=A0to=C2=A0being=C2=A0overloaded
than=C2=A0a=C2=A0stateless=C2=A0function.=C2=A0I=C2=A0therefore=C2=A0g= enerally=C2=A0recommend=C2=A0against=C2=A0co-
locating=C2=A0critical=C2=A0stateful=C2=A0and=C2=A0stateless=C2=A0func= tions=C2=A0on=C2=A0the=C2=A0same=C2=A0hardware,
unless=C2=A0it=C2=A0can=C2=A0be=C2=A0ensured=C2=A0that=C2=A0an=C2=A0ov= erloading=C2=A0of=C2=A0the=C2=A0stateful=C2=A0function
does=C2=A0not=C2=A0impact=C2=A0the=C2=A0stateless=C2=A0function.
=
I agree that stateless solution have better scalability compared to st= ateful ones. But for the question whether they should co-locate in the same= hardware or not, I personally think it may depend on the implementation fo= r different vendors. As far as I know, some vendors intend to implement qui= te a lot transition mechanisms on the same device. In this case, it would b= e reasonable to deploy them in the same device if the overall performance i= s ensured.
To=C2=A0prevent=C2=A0confusion,=C2=A0I=C2=A0would=C2=A0also=C2=A0avoid= =C2=A0referring=C2=A0to=C2=A0the=C2=A0two=C2=A0distinct
functions=C2=A0with=C2=A0the=C2=A0same=C2=A0name=C2=A0("NAT64=C2= =A0gateway").=C2=A0Perhaps=C2=A0"IVI=C2=A0gateway"
would=C2=A0be=C2=A0better=C2=A0for=C2=A0the=C2=A0stateless=C2=A0functi= on?=C2=A0(Or=C2=A0"SIIT=C2=A0gateway",=C2=A0see
below.)
Well, I think SIIT is an old word obsoleted by RFC6145. I have confirm= ed with Prof. Li (the author of RFC6145) that "stateless translation&q= uot; is a more accurate word. How do you think of this one?
=C2=A0
2)=C2=A0The=C2=A0header=C2=A0of=C2=A0section=C2=A05=C2=A0("IPv6-t= o-IPv4=C2=A0communication=C2=A0scenario")=C2=A0is
somewhat=C2=A0ambigous.=C2=A0I=C2=A0suggest=C2=A0rewriting=C2=A0it=C2= =A0to=C2=A0e.g.=C2=A0"IPv6=C2=A0client=C2=A0to=C2=A0IPv4
server=C2=A0communication=C2=A0scenario".=C2=A0Likewise=C2=A0for= =C2=A0the=C2=A0title=C2=A0of=C2=A0section=C2=A06.
=
Very good suggestion :) Thanks.
3)=C2=A0In=C2=A0section=C2=A05,=C2=A0I=C2=A0think=C2=A0it=C2=A0should= =C2=A0be=C2=A0mentioned=C2=A0that=C2=A0an=C2=A0alternative=C2=A0to
using=C2=A0stateful=C2=A0NAT64=C2=A0is=C2=A0using=C2=A0a=C2=A0Layer-4= =C2=A0or=C2=A0Layer-7=C2=A0proxy=C2=A0(e.g.=C2=A0HAProxy).
This=C2=A0has=C2=A0the=C2=A0advantage=C2=A0of=C2=A0sometimes=C2=A0bein= g=C2=A0able=C2=A0to=C2=A0communicate=C2=A0the
original=C2=A0IPv6=C2=A0source=C2=A0address=C2=A0of=C2=A0the=C2=A0end= =C2=A0user=C2=A0to=C2=A0the=C2=A0IPv4=C2=A0server,e.g.,
for=C2=A0geo-location.=C2=A0This=C2=A0can=C2=A0be=C2=A0done=C2=A0by=C2= =A0inserting=C2=A0a=C2=A0Layer-7=C2=A0header=C2=A0such
as=C2=A0HTTP's=C2=A0X-Forwarded-For.
Yes, proxy is another alternative to this scenario. From my perspectiv= e, I think NAT64 would have better efficiency and take lower cost compared = to Layer-7 method. And it is also application-independent, except for a few= ALGs. Besides, we have offered an open API for CPs to retrieve its origina= l IPv6 address when necessary.
Actually, for address sharing situation in the future, e.g. NAT444, DS= -Lite, etc, one public IPv4 address will be shared among multiple subscribe= rs. This will also have impact on CPs and this kind of binding information = is useful for them as well. So, we would like to provide them with a unifie= d API to get binding information.
Therefore, I personally prefer network-layer translation as a transition se= rvice offered by operators. Layer-7 proxy is also a good solution when CPs = would like to deploy it by themselves.
=C2=A0
4)=C2=A0In=C2=A0section=C2=A06,=C2=A0it=C2=A0should=C2=A0be=C2=A0point= ed=C2=A0out=C2=A0that=C2=A0due=C2=A0to=C2=A0its=C2=A0stateless
nature,=C2=A0the=C2=A0IVI=C2=A0translation=C2=A0function=C2=A0can=C2= =A0trivially=C2=A0be=C2=A0made=C2=A0redundant
and=C2=A0load=C2=A0balanced,=C2=A0by=C2=A0using=C2=A0standard=C2=A0rou= ting=C2=A0techniques=C2=A0such=C2=A0as
anycasting=C2=A0and=C2=A0equal-cost=C2=A0multipath=C2=A0routes.=C2=A0T= his=C2=A0is=C2=A0in=C2=A0my=C2=A0opinion=C2=A0an
enormous=C2=A0advantage=C2=A0over=C2=A0stateful=C2=A0NAT64,=C2=A0which= =C2=A0requres=C2=A0symmetric=C2=A0traffic
flow=C2=A0across=C2=A0a=C2=A0single=C2=A0translator=C2=A0box.
Exactly:) That's why we would like to adopt stateless translation = here.
5)=C2=A0I=C2=A0believe=C2=A0there=C2=A0should=C2=A0be=C2=A0some=C2=A0d= iscussion=C2=A0of=C2=A0potential=C2=A0issues=C2=A0arising
from=C2=A0the=C2=A0fact=C2=A0that=C2=A0the=C2=A0IPv6=C2=A0header=C2=A0= usually=C2=A0is=C2=A020=C2=A0bytes=C2=A0larger=C2=A0than=C2=A0an
IPv4=C2=A0header:
Assuming=C2=A0a=C2=A0standard=C2=A0Ethernet=C2=A0MTU=C2=A0of=C2=A01500= =C2=A0bytes,=C2=A0if=C2=A0a=C2=A0translator=C2=A0receives
a=C2=A0maximum-sized=C2=A0IPv4=C2=A0packet=C2=A0with=C2=A0the=C2=A0Don= 't=C2=A0Fragment=C2=A0flag=C2=A0unset,=C2=A0the
translator=C2=A0needs=C2=A0to=C2=A0fragment=C2=A0the=C2=A0packet=C2=A0= when=C2=A0translating=C2=A0to=C2=A0IPv6.=C2=A0This
has=C2=A0some=C2=A0potential=C2=A0side-effects,=C2=A0as=C2=A0the=C2=A0= addition=C2=A0of=C2=A0the=C2=A0IPv6=C2=A0Extension
Header=C2=A0may=C2=A0prevent=C2=A0firewalls=C2=A0and=C2=A0similar=C2= =A0middleware=C2=A0boxes=C2=A0from=C2=A0correctly
evaluating=C2=A0the=C2=A0fragmented=C2=A0packets=C2=A0according=C2=A0t= o=C2=A0ACLs=C2=A0or=C2=A0similar.
Use=C2=A0of=C2=A0a=C2=A01520=C2=A0bytes=C2=A0large=C2=A0MTU=C2=A0in=C2= =A0the=C2=A0IPv6=C2=A0network=C2=A0between=C2=A0the=C2=A0translator
and=C2=A0the=C2=A0server=C2=A0may=C2=A0be=C2=A0one=C2=A0way=C2=A0to=C2= =A0deal=C2=A0with=C2=A0this=C2=A0problem,=C2=A0in=C2=A0the=C2=A0IVI
scenario.=C2=A0Also,=C2=A0when=C2=A0using=C2=A0TCP,=C2=A0an=C2=A0IPv6= =C2=A0server=C2=A0using=C2=A0MTU=C2=A01500=C2=A0will
generally=C2=A0ensure=C2=A0sufficiently=C2=A0small=C2=A0enough=C2=A0MS= S=C2=A0is=C2=A0negotiated=C2=A0so=C2=A0that=C2=A0the
IPv4=C2=A0client=C2=A0is=C2=A0prevented=C2=A0from=C2=A0ever=C2=A0sendi= ng=C2=A0larger=C2=A0IPv4=C2=A0packets=C2=A0than=C2=A01480
bytes,=C2=A0which=C2=A0will=C2=A0not=C2=A0require=C2=A0fragmentation.= =C2=A0In=C2=A0the=C2=A0stateful=C2=A0scenario,
this=C2=A0issue=C2=A0can=C2=A0be=C2=A0avoided=C2=A0by=C2=A0using=C2=A0= a=C2=A0Layer-4/7=C2=A0proxy=C2=A0rather=C2=A0than=C2=A0NAT64.
<= /div>
Jacni has explained this part.
6)=C2=A0I=C2=A0feel=C2=A0that=C2=A0the=C2=A0references=C2=A0to=C2=A0RF= C=C2=A06219=C2=A0is=C2=A0wrong.=C2=A0In=C2=A0all=C2=A0three=C2=A0cases
(sections=C2=A01,=C2=A03.1,=C2=A0and=C2=A06),=C2=A0it=C2=A0is=C2=A0use= d=C2=A0as=C2=A0a=C2=A0normative=C2=A0reference,=C2=A0i.e.,=C2=A0as
the=C2=A0IVI=C2=A0protocol=C2=A0specification.=C2=A0However,=C2=A0RFC= =C2=A06219=C2=A0is=C2=A0not=C2=A0a=C2=A0protocol
specification=C2=A0as=C2=A0far=C2=A0as=C2=A0I=C2=A0can=C2=A0tell,=C2= =A0it=C2=A0is=C2=A0rather=C2=A0just=C2=A0a=C2=A0case=C2=A0study.=C2=A0It
should=C2=A0therefore=C2=A0be=C2=A0an=C2=A0informative=C2=A0reference.=
As=C2=A0far=C2=A0as=C2=A0I've=C2=A0been=C2=A0able=C2=A0to=C2=A0und= erstand=C2=A0from=C2=A0reading=C2=A0RFC=C2=A06219,=C2=A0the
protocol=C2=A0called=C2=A0"stateless=C2=A0IVI"=C2=A0is=C2=A0= in=C2=A0reality=C2=A0specified=C2=A0in=C2=A0RFC=C2=A06145
where=C2=A0it=C2=A0is=C2=A0called=C2=A0"Stateless=C2=A0IP/ICMP=C2= =A0Translation"=C2=A0(SIIT).=C2=A0If=C2=A0this=C2=A0is
correct,=C2=A0and=C2=A0there=C2=A0really=C2=A0is=C2=A0no=C2=A0differen= ce=C2=A0between=C2=A0"stateless=C2=A0IVI"=C2=A0and
SIIT,=C2=A0I=C2=A0feel=C2=A0that=C2=A0the=C2=A0use=C2=A0of=C2=A0the=C2= =A0name=C2=A0IVI=C2=A0is=C2=A0questionable=C2=A0as=C2=A0it=C2=A0does=C2=A0n= ot
appear=C2=A0once=C2=A0in=C2=A0RFC=C2=A06145=C2=A0(nor=C2=A0in=C2=A0RFC= =C2=A06052=C2=A0for=C2=A0that=C2=A0matter).=C2=A0The=C2=A0only
reference=C2=A0I=C2=A0find=C2=A0to=C2=A0the=C2=A0name=C2=A0"IVI&q= uot;=C2=A0in=C2=A0current=C2=A0IETF=C2=A0docs=C2=A0are=C2=A0in=C2=A0this
draft=C2=A0as=C2=A0well=C2=A0as=C2=A0in=C2=A0RFC=C2=A06219=C2=A0(where= =C2=A0it=C2=A0just=C2=A0seems=C2=A0to=C2=A0describe=C2=A0SIIT).
I=C2=A0therefore=C2=A0suggest=C2=A0you=C2=A0replace=C2=A0all=C2=A0ment= ions=C2=A0of=C2=A0(stateless)=C2=A0IVI=C2=A0with
SIIT,=C2=A0and=C2=A0the=C2=A0related=C2=A0normative=C2=A0references=C2= =A0from=C2=A0RFC=C2=A06219=C2=A0to=C2=A0RFC=C2=A06145.
=C2=A0
Thanks for pointing out this mistake. We will quote RFC6145 and RFC605= 2 as normative reference and replace RFC6219 as informative reference.
= Regarding the name issue, how about using "stateless translation"= and "stateful translation" ?
Thanks again for your detailed review. I very much appreciated it:)=C2=A0
Best wishes
=C2=A0
Qiong
=C2=A0
Best=C2=A0regards,
--=C2=A0
Tore=C2=A0Anderson

--90e6ba6e89dc5ae66b04b0e8da05-- From tore.anderson@redpill-linpro.com Fri Nov 4 07:35:13 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D60B721F8C53 for ; Fri, 4 Nov 2011 07:35:13 -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 gz2UJSX5gSH3 for ; Fri, 4 Nov 2011 07:35:12 -0700 (PDT) Received: from zimbra.redpill-linpro.com (zimbra.redpill-linpro.com [IPv6:2a02:c0:200:c000::1]) by ietfa.amsl.com (Postfix) with ESMTP id 651F821F8C44 for ; Fri, 4 Nov 2011 07:35:12 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.redpill-linpro.com (Postfix) with ESMTP id 3510D103002B; Fri, 4 Nov 2011 15:35:11 +0100 (CET) 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 gvWgv1danotI; Fri, 4 Nov 2011 15:35:10 +0100 (CET) Received: from echo.linpro.no (unknown [IPv6:2a02:c0:1002:102:21d:60ff:fe48:f59e]) by zimbra.redpill-linpro.com (Postfix) with ESMTPSA id 36E511030005; Fri, 4 Nov 2011 15:35:10 +0100 (CET) Message-ID: <4EB3F81D.1050106@redpill-linpro.com> Date: Fri, 04 Nov 2011 15:35:09 +0100 From: Tore Anderson Organization: Redpill Linpro AS User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110927 Thunderbird/7.0 MIME-Version: 1.0 To: Qiong References: <201111041609169589985@ctbri.com.cn> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: New Version Notificationfor draft-sunq-v6ops-contents-transition-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: Fri, 04 Nov 2011 14:35:14 -0000 Hi again, * Qiong >> 1) Figure 1 displays a single NAT64 gateway that both handles >> stateless IPv4-client-to-IPv6-server translations as well as >> stateful IPv6-client- to-IPv4-server translations. These two >> techniques are completely independent of each other, so I suggest >> you display this as two separate translator boxes, and rather >> mention that the two functions may be co- located on the same >> physical hardware. >> > I'm sorry this figure really causes misunderstanding. It will be > clearer to separate these two translator boxes accordingly. > >> A stateful function is limited by the total amount of flows as well >> as the flow initiation rate, it is much more prone to being >> overloaded than a stateless function. I therefore generally >> recommend against co- locating critical stateful and stateless >> functions on the same hardware, unless it can be ensured that an >> overloading of the stateful function does not impact the stateless >> function. >> > I agree that stateless solution have better scalability compared to > stateful ones. But for the question whether they should co-locate in > the same hardware or not, I personally think it may depend on the > implementation for different vendors. As far as I know, some vendors > intend to implement quite a lot transition mechanisms on the same > device. In this case, it would be reasonable to deploy them in the > same device if the overall performance is ensured. Yes, my point was not really that you should make any strong recommendation either way, just that it should be made clear that the two deployment scenarios described are completely independent of each other, and that there are nothing about them that *requires* them to be co-located on the same box. Which means breaking up the "NAT64" box in Figure 1 in two, and perhaps adding another figures in sections 5 and 6. > Well, I think SIIT is an old word obsoleted by RFC6145. The text in RFC6145 starts like this: «This document describes the Stateless IP/ICMP Translation Algorithm (SIIT)» So to me it seems that RFC6145 doesn't in any way obsolete the term «SIIT», quite the opposite: it _defines_ it. > I have confirmed with Prof. Li (the author of RFC6145) that > "stateless translation" is a more accurate word. How do you think of > this one? Well, as SIIT is an abbreviation for «Stateless IP/ICMP Translation» I believe that is as accurate as you can get... >> 3) In section 5, I think it should be mentioned that an alternative >> to using stateful NAT64 is using a Layer-4 or Layer-7 proxy (e.g. >> HAProxy). This has the advantage of sometimes being able to >> communicate the original IPv6 source address of the end user to the >> IPv4 server,e.g., for geo-location. This can be done by inserting a >> Layer-7 header such as HTTP's X-Forwarded-For. >> > Yes, proxy is another alternative to this scenario. From my > perspective, I think NAT64 would have better efficiency and take > lower cost compared to Layer-7 method. And it is also > application-independent, except for a few ALGs. Besides, we have > offered an open API for CPs to retrieve its original IPv6 address > when necessary. Actually, for address sharing situation in the > future, e.g. NAT444, DS-Lite, etc, one public IPv4 address will be > shared among multiple subscribers. This will also have impact on CPs > and this kind of binding information is useful for them as well. So, > we would like to provide them with a unified API to get binding > information. Therefore, I personally prefer network-layer translation > as a transition service offered by operators. Layer-7 proxy is also a > good solution when CPs would like to deploy it by themselves. I am making no statement whether network, transport, or application layer translation/proxying is the best, but it seems to me that the alternatives should be mentioned, at least, so that the reader can decide for himself which solution suits him the best. Unless, of course, the scope of the document is meant to focus on network layer translation exclusively. But its title and abstract doesn't indicate that. Actually, come to think of it, the title of the document, «Rapid Transition of IPv4 contents to be IPv6-accessible» only really describes the stateful model described in section 5. Maybe it should be made more generic? Something like «Transition of single-stack content to dual-stack end-user availability», maybe? >> 6) I feel that the references to RFC 6219 is wrong. In all three >> cases (sections 1, 3.1, and 6), it is used as a normative >> reference, i.e., as the IVI protocol specification. However, RFC >> 6219 is not a protocol specification as far as I can tell, it is >> rather just a case study. It should therefore be an informative >> reference. As far as I've been able to understand from reading RFC >> 6219, the protocol called "stateless IVI" is in reality specified >> in RFC 6145 where it is called "Stateless IP/ICMP Translation" >> (SIIT). If this is correct, and there really is no difference >> between "stateless IVI" and SIIT, I feel that the use of the name >> IVI is questionable as it does not appear once in RFC 6145 (nor in >> RFC 6052 for that matter). The only reference I find to the name >> "IVI" in current IETF docs are in this draft as well as in RFC 6219 >> (where it just seems to describe SIIT). I therefore suggest you >> replace all mentions of (stateless) IVI with SIIT, and the related >> normative references from RFC 6219 to RFC 6145. > > Thanks for pointing out this mistake. We will quote RFC6145 and > RFC6052 as normative reference and replace RFC6219 as informative > reference. Regarding the name issue, how about using "stateless > translation" and "stateful translation" ? For the stateless model described in section 6, RFC 6145 (which in turn refers to RFC 6052) is the protocol specification, and it defines the name to be «Stateless IP/ICMP Translation», or «SIIT» for short. For the stateful model described in section 5, RFC 6146 is the protocol specification, and it defines the name to be «Stateful NAT64», or just «NAT64» for short. I really think you should stick to these names exactly as they are defined. It's hard enough to keep track of all the various IPv6/IPv4 transition technologies with only one name per tech, we really don't need even more names to learn. :-) Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com From brian.e.carpenter@gmail.com Fri Nov 4 12:47:15 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B150321F8BA8 for ; Fri, 4 Nov 2011 12:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.681 X-Spam-Level: X-Spam-Status: No, score=-102.681 tagged_above=-999 required=5 tests=[AWL=-0.748, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_FWDLOOK=1.666, 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 Gk6rrpoHxr3w for ; Fri, 4 Nov 2011 12:47:15 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id DC0C321F8B9A for ; Fri, 4 Nov 2011 12:47:14 -0700 (PDT) Received: by faas12 with SMTP id s12so3579734faa.31 for ; Fri, 04 Nov 2011 12:47:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=x16aZDf67BdT0EfsR6Cvvo5wRlzxwYkmz8l48cWv2zk=; b=yDALx5pCw8gXcTnHZzvgIMq/O7SKYsP1Z1SsrqAvKPxDecAUXPJVhgL9hCVZLiDXvD jH0THCfj6R8f8W5+AgLioC6xZ/FwX1fFWGvStK+f2DftnG+jlRmsB0vMgelmWT3sRXQW r9gopbo43T6/16ulcMB4L3AaI7b0uuI1W6+YM= Received: by 10.223.30.149 with SMTP id u21mr26465057fac.18.1320436034030; Fri, 04 Nov 2011 12:47:14 -0700 (PDT) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id a8sm18168714faa.11.2011.11.04.12.47.10 (version=SSLv3 cipher=OTHER); Fri, 04 Nov 2011 12:47:13 -0700 (PDT) Message-ID: <4EB44137.6040009@gmail.com> Date: Sat, 05 Nov 2011 08:47:03 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Qiong References: <4EB05384.5000007@gmail.com> <4EB1A443.1000301@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: [v6ops] OT: NA64 performance [ New Version Notification for draft-sunq-v6ops-contents-transition-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: Fri, 04 Nov 2011 19:47:15 -0000 On 2011-11-04 15:04, Qiong wrote: ... >> Personally I think a proxy is a more forward-looking solution, but NAT64 is >> a little more efficient, as a student of mine has proved. >> (See http://www.cs.auckland.ac.nz/~brian/NAT64-perf-Beijing.pdf) >> > Sorry, I'm kind of confused by the comparison result. It seems the > performance of NAT64 would decrease significantly for Big request. But in > our performance test, both on prototype and commercial device, we do not > find such problem. I can share you with our test results later. We could never explain that performance anomaly, even after inspecting the code and discussing with the software author. It is probably only an implementation issue. Brian From bzeeb-lists@lists.zabbadoz.net Fri Nov 4 20:04:11 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFB4F11E80E7; Fri, 4 Nov 2011 20:04:11 -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=[BAYES_00=-2.599, J_CHICKENPOX_13=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 APidyBa3mIAU; Fri, 4 Nov 2011 20:04:11 -0700 (PDT) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by ietfa.amsl.com (Postfix) with ESMTP id 0A15011E80E5; Fri, 4 Nov 2011 20:04:10 -0700 (PDT) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 28B4F25D37D1; Sat, 5 Nov 2011 03:04:08 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 2E33CBD4372; Sat, 5 Nov 2011 03:04:08 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id AoYVn5K8bK8E; Sat, 5 Nov 2011 03:03:58 +0000 (UTC) Received: from nv.sbone.de (nv.sbone.de [IPv6:fde9:577b:c1a9:31::2013:138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id BE92BBD4376; Sat, 5 Nov 2011 03:03:12 +0000 (UTC) Date: Sat, 5 Nov 2011 03:03:11 +0000 (UTC) From: "Bjoern A. Zeeb" To: ietf@ietf.org In-Reply-To: <20111027231114.5471.38579.idtracker@ietfa.amsl.com> Message-ID: References: <20111027231114.5471.38579.idtracker@ietfa.amsl.com> X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: v6ops@ietf.org Subject: Re: [v6ops] Last Call: (Happy Eyeballs: Success with Dual-Stack Hosts) to Proposed Standard X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 05 Nov 2011 03:04:11 -0000 On Thu, 27 Oct 2011, The IESG wrote: Hi, > The IESG has received a request from the IPv6 Operations WG (v6ops) to > consider the following document: > - 'Happy Eyeballs: Success with Dual-Stack Hosts' > as a Proposed Standard Having been on a lot of different (company and few end user) networks the last weeks that had IPv6 and having seen the discussion on v6ops only just today I want to second a couple of voices from v6ops (sorry for the lateness and having to do it this way) and raise mine as well on :: 5.3. Debugging and Troubleshooting :: .. :: To assist in that regard, the :: implementations MAY also provide a mechanism to disable their Happy :: Eyeballs behavior via a user setting. here. ++ on MAY is NOT strong enough, especially given the ignorance of vendors for adding such an option voluntarily anyway. I understand that there are situations in which a MUST is too hard and not feasible but here's a few observations: - Given I try to be v6-only whenever possible I see v6 problems (HE) users on v4/v6 networks do not see usually fairly quickly. - As soon as having machines on dual-stack, observations are: a) a significant drop in use of v6-favoured transition technology (e.g. NAT64 traffic) when comparing HE vs. non-HE systems by "more 'happy eyeballs' enforced" use of legacy IP. b) I find that about about 1 in 3 of IPv6 enabled networks have problems that are simply hidden to most people by HE these days, and may otherwise not be enough to bother and ignored, and it is extremly hard to i) show people the problem exists (send them to a v6-only server is the fastest solution usally unless (v) applies) ii) then explain it to them (as things are mostly so fine lately) iii) for them then to figure out when the problem started iv) for them to figure out where the problem is and what is affected, and v) sometimes it is strange problems only affecting some but not all systems making debugging really hard. c) that debugging often takes long (often due to missing options, etc), d) that monitoring is usualy far from existent to catch the problems early or at all, and e) by the time it is understood and fixed some other "minor oddities here and there" strangely often disappear as well and things are indeed "so fine" and use some more v6 in addition as well. I have about too many emails on these topics in my inbox from the last weeks (and not just with "you") and I am tired of not being able to turn HE off on a good fraction mainstream systems/browsers, especially for the people who SHOULD, want, or rather MUST care (contrary to the people who have no idea what this would be about and never bother the hard to find advanced option anyway). I vote for substituing "MAY" to a "SHOULD whenever possible" in 5.3. /bz -- Bjoern A. Zeeb Damn eat your dogfood! Really! Stop bit received. Insert coin for new address family. From joelja@bogus.com Sat Nov 5 07:47:38 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1E7921F8A35 for ; Sat, 5 Nov 2011 07:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.022 X-Spam-Level: X-Spam-Status: No, score=-102.022 tagged_above=-999 required=5 tests=[AWL=-0.023, 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 vHv1dmIHUUkD for ; Sat, 5 Nov 2011 07:47:38 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 6639D21F8997 for ; Sat, 5 Nov 2011 07:47:38 -0700 (PDT) Received: from Zorch.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 pA5ElX8J030075 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sat, 5 Nov 2011 14:47:34 GMT (envelope-from joelja@bogus.com) Message-ID: <4EB54C85.4050909@bogus.com> Date: Sat, 05 Nov 2011 07:47:33 -0700 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Qiong References: <4EB05384.5000007@gmail.com> In-Reply-To: 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]); Sat, 05 Nov 2011 14:47:34 +0000 (UTC) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Fwd: New Version Notification for draft-sunq-v6ops-contents-transition-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, 05 Nov 2011 14:47:38 -0000 On 11/2/11 01:23 , Qiong wrote: > Hi Brian, > > Thanks for your comments. > > I agree that dual-stack is a very straightforward way to IPv6 and should > be recommended in general. But frankly, I think the situation we are > facing with seems much more complicated, sometimes beyond technical > issues. Most ICPs are still lacking of motivation to upgrade, just > waiting for v6 users. And in the same way, operators are also hesitating > to deploy v6 when there are very few existing v6 contents. This chicken > and egg thing is still ongoing, even we are running out IPv4 address. > > After all, dual stack is what we have discussing for 10 years. But up to > now, how many ICPs have upgraded to IPv6 in dual-stack directly? I > really think we need to re-think it again, from both technical aspect > and the industry/or market aspect. And the first step is rather > important to give us confidence to move forward. That's why we recommend > single-stack (either v4 or v6) transition in the current phase. Then, > for the conservative ones, the IPv4 services can be still offered > natively, and the IPv6 services can be offered by the stateful NAT64; > while for progressive ones and newly comers, the stateless IVI can be > employed to offer native IPv6 services reachable via IPv4. And we hope > it would help enrich IPv6 content asap. Then how do you think ? Any solution that causes me to lose access to the source address is not usable from my vantage point as a content provider. When I terminate connections on an l7 load balancer as I generally do for http/https on ipv4 and where we do it in ipv6 I can drop x-forwarded for in there. That requires that I recieve the traffic unmolested by a nat transform associated with my own service. > Thanks > > Qiong > > > On Wed, Nov 2, 2011 at 4:16 AM, Brian E Carpenter > > wrote: > > I'm not seeing why this is a better solution for a small/medium ICP > than just moving to a dual stack. That is much easier for a small > network than for a big one. > > Regards > Brian > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From brian.e.carpenter@gmail.com Sat Nov 5 12:45:53 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B138721F851A for ; Sat, 5 Nov 2011 12:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.181 X-Spam-Level: X-Spam-Status: No, score=-103.181 tagged_above=-999 required=5 tests=[AWL=-0.182, BAYES_00=-2.599, 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 ipUV09IAr11w for ; Sat, 5 Nov 2011 12:45:53 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id E1A6321F847F for ; Sat, 5 Nov 2011 12:45:52 -0700 (PDT) Received: by faas12 with SMTP id s12so4478323faa.31 for ; Sat, 05 Nov 2011 12:45:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=cNMmuBvHy0Qqo07cYMXJYBB5Peob3C/5Baapw3+MJH4=; b=B/CoKDGRNxDhcy78LpByX0hEjP4miwaoEc6Ps+rlZCKv+dwPvTCaolncjR9gQ/y1GL ATytK/awfMsrhmgQMOLWSLB+jJJMHV+JT0AC6tzBMmCuL35lXellL8Ad0MCIWbeTWitX Vo6KT2ETH1zLJvprxLvNMi1r0dUAX52mDL7yI= Received: by 10.223.91.82 with SMTP id l18mr31700965fam.30.1320522351968; Sat, 05 Nov 2011 12:45:51 -0700 (PDT) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id l26sm23045069fad.17.2011.11.05.12.45.48 (version=SSLv3 cipher=OTHER); Sat, 05 Nov 2011 12:45:50 -0700 (PDT) Message-ID: <4EB5925F.6090602@gmail.com> Date: Sun, 06 Nov 2011 08:45:35 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Joel jaeggli References: <4EB05384.5000007@gmail.com> <4EB54C85.4050909@bogus.com> In-Reply-To: <4EB54C85.4050909@bogus.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Fwd: New Version Notification for draft-sunq-v6ops-contents-transition-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, 05 Nov 2011 19:45:53 -0000 in line .. On 2011-11-06 03:47, Joel jaeggli wrote: > On 11/2/11 01:23 , Qiong wrote: >> Hi Brian, >> >> Thanks for your comments. >> >> I agree that dual-stack is a very straightforward way to IPv6 and should >> be recommended in general. But frankly, I think the situation we are >> facing with seems much more complicated, sometimes beyond technical >> issues. Most ICPs are still lacking of motivation to upgrade, just >> waiting for v6 users. And in the same way, operators are also hesitating >> to deploy v6 when there are very few existing v6 contents. This chicken >> and egg thing is still ongoing, even we are running out IPv4 address. >> >> After all, dual stack is what we have discussing for 10 years. But up to >> now, how many ICPs have upgraded to IPv6 in dual-stack directly? I >> really think we need to re-think it again, from both technical aspect >> and the industry/or market aspect. And the first step is rather >> important to give us confidence to move forward. That's why we recommend >> single-stack (either v4 or v6) transition in the current phase. Then, >> for the conservative ones, the IPv4 services can be still offered >> natively, and the IPv6 services can be offered by the stateful NAT64; >> while for progressive ones and newly comers, the stateless IVI can be >> employed to offer native IPv6 services reachable via IPv4. And we hope >> it would help enrich IPv6 content asap. Then how do you think ? > > Any solution that causes me to lose access to the source address is not > usable from my vantage point as a content provider. When I terminate > connections on an l7 load balancer as I generally do for http/https on > ipv4 and where we do it in ipv6 I can drop x-forwarded for in there. > That requires that I recieve the traffic unmolested by a nat transform > associated with my own service. It certainly seems that geolocation would fail miserably behind a NAT64 local to the ICP. All the IPv6 clients would be reported as living in the computer room, wouldn't they? Brian >> Thanks >> >> Qiong >> >> >> On Wed, Nov 2, 2011 at 4:16 AM, Brian E Carpenter >> > wrote: >> >> I'm not seeing why this is a better solution for a small/medium ICP >> than just moving to a dual stack. That is much easier for a small >> network than for a big one. >> >> Regards >> Brian >> >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > > From eleven.fuyu@huawei.com Mon Nov 7 02:04:09 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D34B021F8AD1 for ; Mon, 7 Nov 2011 02:04:09 -0800 (PST) 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 WEczeXDrouoC for ; Mon, 7 Nov 2011 02:04:09 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 30D2B21F8ABD for ; Mon, 7 Nov 2011 02:04:09 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUA0081XBVZF8@szxga05-in.huawei.com> for v6ops@ietf.org; Mon, 07 Nov 2011 18:02:23 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUA007QUBVYOY@szxga05-in.huawei.com> for v6ops@ietf.org; Mon, 07 Nov 2011 18:02:23 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEU56293; Mon, 07 Nov 2011 18:02:22 +0800 Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 07 Nov 2011 18:02:19 +0800 Received: from SZXEML512-MBS.china.huawei.com ([169.254.6.57]) by szxeml404-hub.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Mon, 07 Nov 2011 18:02:12 +0800 Date: Mon, 07 Nov 2011 10:02:11 +0000 From: "Eleven Fu(Yu)" In-reply-to: X-Originating-IP: [10.108.4.119] To: GangChen , v6ops Message-id: MIME-version: 1.0 Content-type: text/plain; charset=Windows-1252 Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: [v6ops] NAT64 Operational Considerations Thread-index: AQHMmcxglIuIpdbo1UGhL5Y1kpvDp5WgySOA X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: Subject: Re: [v6ops] NAT64 Operational Considerations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 Nov 2011 10:04:09 -0000 Hi Gang, I have read draft-chen-v6ops-nat64-cpe, please see come comments below, The draft is structured by different deploy positions of NAT64 as different modes. It describes operational process for each mode. But I think as a informational guide for readers, some more considerations need to be described for each mode in more detail, such as logging problem, ALG issues, DNS, load balancing etc. For section 4, some security considerations also need to be involved, such as user tracking, Dos attack etc. Cheers Yu -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of GangChen Sent: Thursday, November 03, 2011 10:00 AM To: v6ops Subject: [v6ops] NAT64 Operational Considerations Dear all, I have just submitted the draft for NAT64 operational consideration. The intention is to provide comprehensive considerations for NAT64 deployment. The detailed information is listed at below A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : NAT64 Operational Considerations Author(s) : Gang Chen Filename : draft-chen-v6ops-nat64-cpe-03.txt Pages : 8 Date : 2011-10-31 The document has summarized NAT64 usages on different modes, in which NAT64 may serve for a large-scale network or would give enterprise or residential service opportunities to be accessed by IPv6 remote subscribers. The document has described different operations for each usage and proposed operational considerations for each particular NAT64-mode. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-chen-v6ops-nat64-cpe-03.txt Many thanks Gang _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From leonidas@netmode.ntua.gr Mon Nov 7 05:30:56 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6067F21F8B67 for ; Mon, 7 Nov 2011 05:30:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.305 X-Spam-Level: X-Spam-Status: No, score=-2.305 tagged_above=-999 required=5 tests=[AWL=0.294, 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 y1E+gMHOrdI7 for ; Mon, 7 Nov 2011 05:30:51 -0800 (PST) Received: from achilles.noc.ntua.gr (achilles.noc.ntua.gr [IPv6:2001:648:2000:de::210]) by ietfa.amsl.com (Postfix) with ESMTP id E131D21F8B55 for ; Mon, 7 Nov 2011 05:30:50 -0800 (PST) Received: from netmode.ece.ntua.gr ([IPv6:2001:648:2000:d:21d:9ff:fe05:33c7]) by achilles.noc.ntua.gr (8.14.4/8.14.4) with ESMTP id pA7DUnEo044445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 7 Nov 2011 15:30:49 +0200 (EET) (envelope-from leonidas@netmode.ntua.gr) Received: from dhcp-71.netmode.ece.ntua.gr (dhcp-71.netmode.ece.ntua.gr [147.102.13.71]) by netmode.ece.ntua.gr (8.14.4/8.14.3) with ESMTP id pA7DUnH3023429; Mon, 7 Nov 2011 15:30:49 +0200 (EET) (envelope-from leonidas@netmode.ntua.gr) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: v6ops@ietf.org Date: Mon, 07 Nov 2011 15:29:50 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Leonidas Lymberopoulos" Message-ID: User-Agent: Opera Mail/11.50 (Linux) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (achilles.noc.ntua.gr [IPv6:2001:648:2000:de::210]); Mon, 07 Nov 2011 15:30:49 +0200 (EET) X-Virus-Scanned: clamav-milter 0.97 at achilles.noc.ntua.gr X-Virus-Status: Clean Subject: [v6ops] (CFP) IEEE/IFIP International Workshop on Management of the Future Internet (ManFI 2012) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 13:30:56 -0000 ----------------------------------------------------------------------------------------------------- Please accept our apologies if you receive multiple copies of this CfP ----------------------------------------------------------------------------------------------------- IEEE/IFIP International Workshop on Management of the Future Internet (ManFI 2012) ================================================================================== 16 April 2012 Maui, Hawaii, USA http://www.manfi.org CALL FOR PAPERS --------------- The Fourth IEEE/IFIP International Workshop on Management of the Future Internet (ManFI 2012) will be held in conjunction with IEEE/IFIP NOMS 2012 in Maui, Hawaii, USA, from April 16-20, 2012. The workshop is sponsored by the IEEE Communications Society (ComSoc) and supported by POSTECH ITCE, Ghent University-IBBT, NEC, and Ericsson LM. The workshop is endorsed by the Technical Committee on Network Operations and Management (CNOM). It is widely agreed that, despite its many successes, the current Internet also has a set of systemic problems, ranging from an upcoming shortage of IP addresses to insufficient security. However, the lack of scalable and agile manageability is arguably more important, as without management, it is impossible to build systems that adapt the services and resources offered in a context-dependent manner. In either case (clean slate vs. evolution vs. revolution) we must consider the manageability of the Future Internet from the beginning. Following the success of the three previous editions of this workshop, held in conjunction with IM 2009, NOMS 2010 and IM 2011, ManFI 2012 aims at providing an international forum for researchers in these and similar areas. ManFI 2012 will combine original full paper presentations with a motivating keynote, quick hot topic presentations and a panel discussion to thoroughly explore this challenging topic. Topics of interest ------------------ Authors are invited to submit papers that fall into or are related to the topic areas listed below: - Architectural Issues * Advantages and disadvantages of revolutionary, evolutionary, and other approaches to managing the Future Internet * Separation of data, control, and management planes * Design of architectural building blocks for managing the Future Internet * Advances in measurement, management, security, accounting, mobility, and other functions * Virtualization of resources and services * Dynamic composition of management and operational functionality * Mechanisms for managing interconnected computational infrastructures (e.g. elastic clouds, federated clouds) in the Future Internet * Implications of social network success on the Future Internet architecture - Design and Implementation Issues * Abstractions for programmable network elements * Accommodating context-awareness in management * Applying situation awareness to network management * Federation between administrative domains and support of all constituencies * The role of models, ontologies, and other knowledge abstractions in the Future Internet * Uncertainty and probabilistic approaches to management of the Future Internet * Approaches for the organization of management data, data analytics and visualization * Experience reports from Future Internet experimental facilities set-up and results - Economic Issues * Economic aspects driving the deployment of Future Internet management technology * Economic opportunities and challenges for management technology * Experience reports from management in test beds Paper submission ---------------- Paper submissions must present original, research or experiences. Late-breaking advances and work-in-progress reports from ongoing research are also encouraged. Only original papers that have not been published or submitted for publication elsewhere can be submitted. Each submission must be written in English, accompanied by a 75 to 200 word abstract that clearly outlines the scope and contributions of the paper, and a list of up to 5 key words. There is a length limitation of 6 pages (including title, abstract, all figures, tables, and references) for regular conference papers, and 4 pages for short papers. Submissions must be in IEEE 2-column style. Papers exceeding these limits, multiple submissions, and self-plagiarized papers will be rejected without further review. Authors should submit their papers in PDF, postscript, or Word formats via JEMS: (https://submissoes.sbc.org.br/). Proceedings ----------- Papers accepted for ManFI 2012 will be included in the conference proceedings, IEEE Xplore, and EI Index. The IEEE reserves the right to remove any paper from IEEE Xplore if the paper is not presented at the workshop. Awards will be presented to the best paper and to the best student paper at the workshop. Furthermore, we plan to work with a leading journal, such as JNSM, TNSM and IJNM, to solicit extended versions of the best papers of ManFI 2012 to be submitted for review. Workshop Co-Chairs ------------------ - Prof. James Won-Ki Hong, POSTECH, Korea - Prof. Filip De Turck, Ghent University - IBBT, Belgium - Dr. Yoshiaki Kiriha, NEC, Japan - Dr. Sven van der Meer, Ericsson LM, Ireland Publicity Co-Chairs ------------------- - Leonidas Lymberopoulos, National Technical University of Athens, Greece - Cathryn Peoples, University of Ulster, UK Important dates --------------- - Abstract registration deadline: December 14, 2011 - Paper submission: December 20, 2011 - Notification of acceptance: January 31, 2012 - Final version of papers due: February 15, 2012 - Workshop date: April 16, 2012 For more information, please contact one of the Workshop Co-Chairs at tpcchairs@manfi2012.org From arturo.servin@gmail.com Mon Nov 7 09:04:35 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB59121F8C63 for ; Mon, 7 Nov 2011 09:04:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFTvsxsjAyA7 for ; Mon, 7 Nov 2011 09:04:35 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6405E21F8C5E for ; Mon, 7 Nov 2011 09:04:21 -0800 (PST) Received: by bkbzv15 with SMTP id zv15so4337227bkb.31 for ; Mon, 07 Nov 2011 09:04:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=XdQJwA1ulalvEkZE89YIMzVPX6hBXaydc9RCR0jeJK8=; b=olHRsqLQgpA1M1Gx2cWWXaKJ3W9Oyws5V/0/M7NnGeebAx/VeMf75O3r2GJqKBrfGX pBeQyZ95mdRB0THSUY6RjWqTaWjocS/piAuXd1yWh7hWZAfWcsJZQELdGqGVBHtaJk+L lEoGuzpR6Ag+CYDr/9xtFpsjRnkMtCSTGUzkw= Received: by 10.205.127.68 with SMTP id gz4mr4114510bkc.17.1320685458693; Mon, 07 Nov 2011 09:04:18 -0800 (PST) Received: from [164.73.1.200] ([164.73.1.200]) by mx.google.com with ESMTPS id o8sm13530750bkd.3.2011.11.07.09.04.16 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 07 Nov 2011 09:04:18 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Arturo Servin In-Reply-To: Date: Mon, 7 Nov 2011 15:04:12 -0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8B0CE30D-5A56-4105-A10C-A6047A27A180@gmail.com> References: To: GangChen X-Mailer: Apple Mail (2.1251.1) Cc: v6ops Subject: Re: [v6ops] NAT64 Operational Considerations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 Nov 2011 17:04:36 -0000 Gang, I found a bit hard to see the target audience of this draft, it = has a bit for developers and a bit for operators. As an operator I was expecting to see some practical = recommendations on what to do (and what not to) for deploying NAT64. I = haven't read RFC 6146 in a while but I think that you are repeating some = of the recommendations that are said there. To make this document more = valuable I would recommend you to go deeper in the practical = considerations when deploying NAT64. Hope it helps, /as On 3 Nov 2011, at 00:00, GangChen wrote: > Dear all, >=20 > I have just submitted the draft for NAT64 operational consideration. > The intention is to provide comprehensive considerations for NAT64 = deployment. > The detailed information is listed at below >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 > Title : NAT64 Operational Considerations > Author(s) : Gang Chen > Filename : draft-chen-v6ops-nat64-cpe-03.txt > Pages : 8 > Date : 2011-10-31 >=20 > The document has summarized NAT64 usages on different modes, in which > NAT64 may serve for a large-scale network or would give enterprise or > residential service opportunities to be accessed by IPv6 remote > subscribers. The document has described different operations for > each usage and proposed operational considerations for each > particular NAT64-mode. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-chen-v6ops-nat64-cpe-03.txt >=20 > Many thanks >=20 > Gang > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From sarikaya2012@gmail.com Mon Nov 7 10:05:01 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2315E21F8B14 for ; Mon, 7 Nov 2011 10:05:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.138 X-Spam-Level: X-Spam-Status: No, score=-3.138 tagged_above=-999 required=5 tests=[AWL=-0.140, 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 s7jtBwjT5Vkf for ; Mon, 7 Nov 2011 10:05:00 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5A67C21F8B10 for ; Mon, 7 Nov 2011 10:05:00 -0800 (PST) Received: by gye5 with SMTP id 5so6496617gye.31 for ; Mon, 07 Nov 2011 10:04:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=uNyVd79gvL6YMJcGQ6z4HcQkQUNduNmsZ0YXMVFZhzk=; b=jD+VDM6WCPw3RSoKicnAhx1Cxtid+m3wXfUuIJfIUXZXgUQEIDWiYZaMuxeBNxPLuS 8oDf7i3T2kSXRiF+0m1p18+9wXN3lC8uyuUitsvww1PRfyEXFfJMCMSocX1JLcYNR+X0 Oe9yIedlWCxXYrqNCUFtViEqpZF4mUW1KmHcI= MIME-Version: 1.0 Received: by 10.236.170.231 with SMTP id p67mr37024724yhl.111.1320689094626; Mon, 07 Nov 2011 10:04:54 -0800 (PST) Received: by 10.236.108.135 with HTTP; Mon, 7 Nov 2011 10:04:54 -0800 (PST) In-Reply-To: <8B0CE30D-5A56-4105-A10C-A6047A27A180@gmail.com> References: <8B0CE30D-5A56-4105-A10C-A6047A27A180@gmail.com> Date: Mon, 7 Nov 2011 12:04:54 -0600 Message-ID: From: Behcet Sarikaya To: Arturo Servin Content-Type: multipart/alternative; boundary=20cf30549a09580e3d04b128e4b0 Cc: v6ops Subject: Re: [v6ops] NAT64 Operational Considerations 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, 07 Nov 2011 18:05:01 -0000 --20cf30549a09580e3d04b128e4b0 Content-Type: text/plain; charset=ISO-8859-1 Hi Arturo, I think this draft is not intended to repeat RFC 6146. The way I understood is the draft discusses how NAT64 can be deployed in broadband networks. Section 2.3 states a lot of requirements that Broadband Forum may be interested in. My question is what IDC? Regards, Behcet On Mon, Nov 7, 2011 at 11:04 AM, Arturo Servin wrote: > Gang, > > I found a bit hard to see the target audience of this draft, it has > a bit for developers and a bit for operators. > > As an operator I was expecting to see some practical > recommendations on what to do (and what not to) for deploying NAT64. I > haven't read RFC 6146 in a while but I think that you are repeating some of > the recommendations that are said there. To make this document more > valuable I would recommend you to go deeper in the practical > considerations when deploying NAT64. > > Hope it helps, > /as > > On 3 Nov 2011, at 00:00, GangChen wrote: > > > Dear all, > > > > I have just submitted the draft for NAT64 operational consideration. > > The intention is to provide comprehensive considerations for NAT64 > deployment. > > The detailed information is listed at below > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > Title : NAT64 Operational Considerations > > Author(s) : Gang Chen > > Filename : draft-chen-v6ops-nat64-cpe-03.txt > > Pages : 8 > > Date : 2011-10-31 > > > > The document has summarized NAT64 usages on different modes, in which > > NAT64 may serve for a large-scale network or would give enterprise or > > residential service opportunities to be accessed by IPv6 remote > > subscribers. The document has described different operations for > > each usage and proposed operational considerations for each > > particular NAT64-mode. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-chen-v6ops-nat64-cpe-03.txt > > > > Many thanks > > > > Gang > > _______________________________________________ > > 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 > --20cf30549a09580e3d04b128e4b0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Arturo,

I think this draft is not intended to repeat RFC 6146.
The way I understood is the draft discusses how NAT64 can be deployed= in broadband networks. Section 2.3 states a lot of requirements that Broad= band Forum may be interested in.

My question is what IDC?

Regards,

Behcet

On Mon, Nov 7, 2011 at 11:04 AM, Arturo Servin <arturo.servin@gmail= .com> wrote:
Gang,

=A0 =A0 =A0 =A0I found a bit hard to see the target audience of this draft= , it has a bit for developers and a bit for operators.

=A0 =A0 =A0 =A0As an operator I was expecting to see some practical recomm= endations on what to do (and what not to) for deploying NAT64. I haven'= t read RFC 6146 in a while but I think that you are repeating some of the r= ecommendations that are said there. To make this document more valuable I w= ould recommend you to go deeper =A0in the practical considerations when dep= loying NAT64.

Hope it helps,
/as

On 3 Nov 2011, at 00:00, GangChen wrote:

> Dear all,
>
> I have just submitted the draft for NAT64 operational consideration. > The intention is to provide comprehensive considerations for NAT64 dep= loyment.
> The detailed information is listed at below
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
>
> =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : NAT64 Operational Consideratio= ns
> =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Gang Chen
> =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-chen-v6ops-nat64-cpe-03.tx= t
> =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 8
> =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-10-31
>
> =A0The document has summarized NAT64 usages on different modes, in whi= ch
> =A0NAT64 may serve for a large-scale network or would give enterprise = or
> =A0residential service opportunities to be accessed by IPv6 remote
> =A0subscribers. =A0The document has described different operations for=
> =A0each usage and proposed operational considerations for each
> =A0particular NAT64-mode.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-che= n-v6ops-nat64-cpe-03.txt
>
> Many thanks
>
> Gang
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

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

--20cf30549a09580e3d04b128e4b0-- From arturo.servin@gmail.com Mon Nov 7 10:47:06 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D39911E8081 for ; Mon, 7 Nov 2011 10:47:06 -0800 (PST) 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=[AWL=-0.000, 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 KG2SyGIYVFNF for ; Mon, 7 Nov 2011 10:47:05 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id EB85021F84D1 for ; Mon, 7 Nov 2011 10:47:04 -0800 (PST) Received: by wwi36 with SMTP id 36so5112763wwi.13 for ; Mon, 07 Nov 2011 10:47:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=otZM56E7mGmgQnD8GAEzZy15q0LYW5saAejp/pQVP6M=; b=bG+bgaCShybPO+0TL1iGNAl4sgYFaSnXUZ8aonJfsm/n99EaSaM6Rqq1Y67tOd4Zq9 orPkEyIex4v6jikgtRoC4R4Z/kWS7Xc8dGtMzV26iBUte3KUmC/klzW3cxvCPZxCpi7n +14TIXsF3hCibAjbPkzOdpzs2CSGuXEkFExjA= Received: by 10.180.92.163 with SMTP id cn3mr8835889wib.26.1320691622771; Mon, 07 Nov 2011 10:47:02 -0800 (PST) Received: from [164.73.1.200] ([164.73.1.200]) by mx.google.com with ESMTPS id fs1sm5690753wib.3.2011.11.07.10.46.55 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 07 Nov 2011 10:47:02 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_BFEDD2D3-B1A6-4FA8-8714-55463E6AE7F3" From: Arturo Servin In-Reply-To: Date: Mon, 7 Nov 2011 16:46:50 -0200 Message-Id: <24BE250F-DE3A-43A0-84F6-F1E69C1DAC34@gmail.com> References: <8B0CE30D-5A56-4105-A10C-A6047A27A180@gmail.com> To: sarikaya@ieee.org X-Mailer: Apple Mail (2.1251.1) Cc: v6ops Subject: Re: [v6ops] NAT64 Operational Considerations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 07 Nov 2011 18:47:06 -0000 --Apple-Mail=_BFEDD2D3-B1A6-4FA8-8714-55463E6AE7F3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Behcet, On 7 Nov 2011, at 16:04, Behcet Sarikaya wrote: > Hi Arturo, >=20 > I think this draft is not intended to repeat RFC 6146.=20 I know. >=20 > The way I understood is the draft discusses how NAT64 can be deployed = in broadband networks. Section 2.3 states a lot of requirements that = Broadband Forum may be interested in. There are some recommendations that are already in RFC 6146. = Section 3.5 and Section 5. But I see no harm to repeat some of the content, my comments are = that the draft could be improved by adding some other recommendations, = not only the ones stated. >=20 > My question is what IDC? >=20 > Regards, >=20 > Behcet Regards, .as >=20 > On Mon, Nov 7, 2011 at 11:04 AM, Arturo Servin = wrote: > Gang, >=20 > I found a bit hard to see the target audience of this draft, it = has a bit for developers and a bit for operators. >=20 > As an operator I was expecting to see some practical = recommendations on what to do (and what not to) for deploying NAT64. I = haven't read RFC 6146 in a while but I think that you are repeating some = of the recommendations that are said there. To make this document more = valuable I would recommend you to go deeper in the practical = considerations when deploying NAT64. >=20 > Hope it helps, > /as >=20 > On 3 Nov 2011, at 00:00, GangChen wrote: >=20 > > Dear all, > > > > I have just submitted the draft for NAT64 operational consideration. > > The intention is to provide comprehensive considerations for NAT64 = deployment. > > The detailed information is listed at below > > > > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > > > > Title : NAT64 Operational Considerations > > Author(s) : Gang Chen > > Filename : draft-chen-v6ops-nat64-cpe-03.txt > > Pages : 8 > > Date : 2011-10-31 > > > > The document has summarized NAT64 usages on different modes, in = which > > NAT64 may serve for a large-scale network or would give enterprise = or > > residential service opportunities to be accessed by IPv6 remote > > subscribers. The document has described different operations for > > each usage and proposed operational considerations for each > > particular NAT64-mode. > > > > A URL for this Internet-Draft is: > > = http://www.ietf.org/internet-drafts/draft-chen-v6ops-nat64-cpe-03.txt > > > > Many thanks > > > > Gang > > _______________________________________________ > > 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 --Apple-Mail=_BFEDD2D3-B1A6-4FA8-8714-55463E6AE7F3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
Hi Arturo,

I think this draft is not intended to = repeat RFC 6146.

I = know.


The way I understood is the = draft discusses how NAT64 can be deployed in broadband networks. Section = 2.3 states a lot of requirements that Broadband Forum may be interested = in.

There are some recommendations = that are already in RFC 6146. Section 3.5 and Section = 5.

But I see no harm to repeat = some of the content, my comments are that the draft could be improved by = adding some other recommendations, not only the ones = stated.




My question is what = IDC?

Regards,

Behcet

Reg= ards,
.as


On Mon, Nov 7, 2011 at 11:04 AM, Arturo Servin = <arturo.servin@gmail.com> wrote:
Gang,

       I found a bit hard to see the target = audience of this draft, it has a bit for developers and a bit for = operators.

       As an operator I was expecting to see some = practical recommendations on what to do (and what not to) for deploying = NAT64. I haven't read RFC 6146 in a while but I think that you are = repeating some of the recommendations that are said there. To make this = document more valuable I would recommend you to go deeper  in the = practical considerations when deploying NAT64.

Hope it helps,
/as

On 3 Nov 2011, at 00:00, GangChen wrote:

> Dear all,
>
> I have just submitted the draft for NAT64 operational = consideration.
> The intention is to provide comprehensive considerations for NAT64 = deployment.
> The detailed information is listed at below
>
> A New Internet-Draft is available from the on-line Internet-Drafts = directories.
>
>       Title           : = NAT64 Operational Considerations
>       Author(s)       : Gang Chen
>       Filename        : = draft-chen-v6ops-nat64-cpe-03.txt
>       Pages           : = 8
>       Date           =  : 2011-10-31
>
>  The document has summarized NAT64 usages on different modes, = in which
>  NAT64 may serve for a large-scale network or would give = enterprise or
>  residential service opportunities to be accessed by IPv6 = remote
>  subscribers.  The document has described different = operations for
>  each usage and proposed operational considerations for = each
>  particular NAT64-mode.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-chen-v6ops-nat= 64-cpe-03.txt
>
> Many thanks
>
> Gang
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

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


= --Apple-Mail=_BFEDD2D3-B1A6-4FA8-8714-55463E6AE7F3-- From dwing@cisco.com Mon Nov 7 16:59:06 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09ABF1F0C54 for ; Mon, 7 Nov 2011 16:59:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.716 X-Spam-Level: X-Spam-Status: No, score=-104.716 tagged_above=-999 required=5 tests=[AWL=-0.383, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, SARE_FWDLOOK=1.666, 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 PDWGwfUM4QkH for ; Mon, 7 Nov 2011 16:59:05 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 48BFF1F0C52 for ; Mon, 7 Nov 2011 16:59:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1328; q=dns/txt; s=iport; t=1320713945; x=1321923545; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=2HvDZHseuEXXEu/rJIinUuwPq/3FhVIBQou7h0dXslY=; b=EGNnltQiPvS0qAnVVOqpgYDxdlFAG7MxNomorj/V9TpRb41VOAtdKNnj VH6pfRCEjJlQlerZv4dvcB/s9+EVOl0sN/IbEYYpVhwaSfOo67xjRdy+a 8eeZXDs8Yg9tm0BJjrDIt24re5iBHuzdqgGKIV1tf10oGwrF37Szd9R9z s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvcAACR+uE6rRDoJ/2dsb2JhbABDFpl1gWuLJ4E1gSSBBYFyAQEBAgEBAQEBBQoBFxA0CQIMAQMCCQ8CBAEBASMEBxkOFQoJCAEBBAESCxAHh2AImS8Bnn2JKwSIC54j X-IronPort-AV: E=Sophos;i="4.69,473,1315180800"; d="scan'208";a="11377807" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 08 Nov 2011 00:59:05 +0000 Received: from dwingWS ([128.107.106.204]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pA80x4Oe009952; Tue, 8 Nov 2011 00:59:05 GMT From: "Dan Wing" To: "'Brian E Carpenter'" , "'Qiong'" References: <4EB05384.5000007@gmail.com> <4EB1A443.1000301@gmail.com> <4EB44137.6040009@gmail.com> In-Reply-To: <4EB44137.6040009@gmail.com> Date: Mon, 7 Nov 2011 16:59:04 -0800 Message-ID: <045601cc9db1$9cb6a710$d623f530$@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: AcybKpUk1P8w2zeIRY+d36B+Wj7w0wChu8IQ Content-Language: en-us Cc: v6ops@ietf.org Subject: Re: [v6ops] OT: NA64 performance [ New Version Notification for draft-sunq-v6ops-contents-transition-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, 08 Nov 2011 00:59:06 -0000 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Brian E Carpenter > Sent: Friday, November 04, 2011 12:47 PM > To: Qiong > Cc: v6ops@ietf.org > Subject: [v6ops] OT: NA64 performance [ New Version Notification for > draft-sunq-v6ops-contents-transition-02.txt] > > On 2011-11-04 15:04, Qiong wrote: > > ... > >> Personally I think a proxy is a more forward-looking solution, but > NAT64 is > >> a little more efficient, as a student of mine has proved. > >> (See http://www.cs.auckland.ac.nz/~brian/NAT64-perf-Beijing.pdf) > >> > > Sorry, I'm kind of confused by the comparison result. It seems the > > performance of NAT64 would decrease significantly for Big request. > But in > > our performance test, both on prototype and commercial device, we do > not > > find such problem. I can share you with our test results later. > > We could never explain that performance anomaly, even after inspecting > the code and discussing with the software author. It is probably only > an implementation issue. Were the packets big enough you might be hitting MTU problems or PMTUD? -d > > Brian > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From phdgang@gmail.com Mon Nov 7 18:34:03 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 370321F0C5A for ; Mon, 7 Nov 2011 18:34:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.979 X-Spam-Level: X-Spam-Status: No, score=-2.979 tagged_above=-999 required=5 tests=[AWL=0.020, 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 vqAeaVQnNBLT for ; Mon, 7 Nov 2011 18:34:02 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5DDCE1F0C59 for ; Mon, 7 Nov 2011 18:34:02 -0800 (PST) Received: by wyg30 with SMTP id 30so31177wyg.31 for ; Mon, 07 Nov 2011 18:34:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=As22TBCNP9FnVFsAW6YgWAwt9VxdVZRCsiTP3ootAeg=; b=wgGhJUwwgbT/DpXwROc6n7d6KafRuItA7vQt9X2mooXedYTkNAKK8WQBkNfUXPf2Jt oeIvJDkO36+EkoQXwL5YZFPH0AF7ATIbLv1tMBQ4aEskfSRaotRwZvG9atU7UeBL3D8I XvOOr7Fquxzn16YGdV/ON0LTJmuS4SXl+RzEU= MIME-Version: 1.0 Received: by 10.180.102.4 with SMTP id fk4mr10586406wib.15.1320719640158; Mon, 07 Nov 2011 18:34:00 -0800 (PST) Received: by 10.180.102.8 with HTTP; Mon, 7 Nov 2011 18:33:59 -0800 (PST) In-Reply-To: References: Date: Tue, 8 Nov 2011 10:33:59 +0800 Message-ID: From: GangChen To: "Eleven Fu(Yu)" Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops Subject: Re: [v6ops] NAT64 Operational Considerations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Nov 2011 02:34:03 -0000 Hello Eleven Fu, Please see my reply inline. 2011/11/7, Eleven Fu(Yu) : > Hi Gang, > > I have read draft-chen-v6ops-nat64-cpe, please see come comments below, > > The draft is structured by different deploy positions of NAT64 as different > modes. It describes operational process for each mode. But I think as a > informational guide for readers, some more considerations need to be > described for each mode in more detail, such as logging problem, ALG issues, > DNS, load balancing etc. That is a good suggestion. There are different considerations regarding to different NAT64 position actually. I would like to elaborate that in next version. > For section 4, some security considerations also need to be involved, such > as user tracking, Dos attack etc. Yes. It should be added. Many thanks Gang > Cheers > > Yu > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > GangChen > Sent: Thursday, November 03, 2011 10:00 AM > To: v6ops > Subject: [v6ops] NAT64 Operational Considerations > > Dear all, > > I have just submitted the draft for NAT64 operational consideration. > The intention is to provide comprehensive considerations for NAT64 > deployment. > The detailed information is listed at below > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : NAT64 Operational Considerations > Author(s) : Gang Chen > Filename : draft-chen-v6ops-nat64-cpe-03.txt > Pages : 8 > Date : 2011-10-31 > > The document has summarized NAT64 usages on different modes, in which > NAT64 may serve for a large-scale network or would give enterprise or > residential service opportunities to be accessed by IPv6 remote > subscribers. The document has described different operations for > each usage and proposed operational considerations for each > particular NAT64-mode. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-chen-v6ops-nat64-cpe-03.txt > > Many thanks > > Gang > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From phdgang@gmail.com Mon Nov 7 18:51:17 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36D4D11E80D3 for ; Mon, 7 Nov 2011 18:51:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.982 X-Spam-Level: X-Spam-Status: No, score=-2.982 tagged_above=-999 required=5 tests=[AWL=0.017, 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 52Q0k+02bDhu for ; Mon, 7 Nov 2011 18:51:16 -0800 (PST) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 7260011E80B9 for ; Mon, 7 Nov 2011 18:51:16 -0800 (PST) Received: by wwf22 with SMTP id 22so5777483wwf.1 for ; Mon, 07 Nov 2011 18:51:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WD5/0YY0N7jkz8AfYWvYNxp+wi8sp+0SsU0a5GpPWI0=; b=j4umP78Gf/5hTlUSDuGk3QTO6oV1HERTxtk57j/YLvk10F+4LNrI7k4fsia+96aLz/ Q+mmM405fnnHi0ZGVp+wEcANR6/kWxbUemMG5WShtshYXXoB/wxzPCUjpa+VH0YXjn57 vRGvL7JcWpcYfRXuDO1c+hmr58TZEyxtlvpWk= MIME-Version: 1.0 Received: by 10.180.3.71 with SMTP id a7mr10654599wia.0.1320720675424; Mon, 07 Nov 2011 18:51:15 -0800 (PST) Received: by 10.180.102.8 with HTTP; Mon, 7 Nov 2011 18:51:15 -0800 (PST) In-Reply-To: <8B0CE30D-5A56-4105-A10C-A6047A27A180@gmail.com> References: <8B0CE30D-5A56-4105-A10C-A6047A27A180@gmail.com> Date: Tue, 8 Nov 2011 10:51:15 +0800 Message-ID: From: GangChen To: Arturo Servin Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops Subject: Re: [v6ops] NAT64 Operational Considerations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Nov 2011 02:51:17 -0000 Hello Arturo, Thanks for the comments. Please see my reply inline. 2011/11/8, Arturo Servin : > Gang, > >I found a bit hard to see the target audience of this draft, it has a bit > for developers and a bit for operators. Sorry for the confusion. My intention is to help NAT64 deployment from an operator point of view. > > As an operator I was expecting to see some practical recommendations on > what to do (and what not to) for deploying NAT64. I haven't read RFC 6146 in > a while but I think that you are repeating some of the recommendations that > are said there. I guess that impression is coming from the "Requirment Section". I agree it should be amended to be more practical, other than implementation specific. > To make this document more valuable I would recommend you to > go deeper in the practical considerations when deploying NAT64. Thanks for the suggestion. I guess that is what Eleven suggested. I will add more texts regarding to that. Many thanks Gang > Hope it helps, > /as > > On 3 Nov 2011, at 00:00, GangChen wrote: > >> Dear all, >> >> I have just submitted the draft for NAT64 operational consideration. >> The intention is to provide comprehensive considerations for NAT64 >> deployment. >> The detailed information is listed at below >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> Title : NAT64 Operational Considerations >> Author(s) : Gang Chen >> Filename : draft-chen-v6ops-nat64-cpe-03.txt >> Pages : 8 >> Date : 2011-10-31 >> >> The document has summarized NAT64 usages on different modes, in which >> NAT64 may serve for a large-scale network or would give enterprise or >> residential service opportunities to be accessed by IPv6 remote >> subscribers. The document has described different operations for >> each usage and proposed operational considerations for each >> particular NAT64-mode. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-chen-v6ops-nat64-cpe-03.txt >> >> Many thanks >> >> Gang >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > > From phdgang@gmail.com Mon Nov 7 19:04:28 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7375F11E80D5 for ; Mon, 7 Nov 2011 19:04:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.985 X-Spam-Level: X-Spam-Status: No, score=-2.985 tagged_above=-999 required=5 tests=[AWL=0.014, 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 ycIQsiFW7LHV for ; Mon, 7 Nov 2011 19:04:27 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7059D11E80B9 for ; Mon, 7 Nov 2011 19:04:27 -0800 (PST) Received: by wwi36 with SMTP id 36so44760wwi.13 for ; Mon, 07 Nov 2011 19:04:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hb5mQoKW2a84FaZOwzYIkL1k7JZ487EY9Fa9zaoR9DA=; b=KGi7fXbSlEfaiTUpEXxZ2A22f/bUq/Mzlp6Z9wMtUVOe0/NhIFUR1xJUtyP8HlCL2t POJVp4ZzyCB+42F+qAniGJTN171gAitkbtUmFHL4qdZFiKgZU3hMOqou1WOaoAykYG4A XkPI+JRu/29WkO2G7ba49qBxnHVXdE+Jkeljs= MIME-Version: 1.0 Received: by 10.180.106.104 with SMTP id gt8mr10722412wib.6.1320721465899; Mon, 07 Nov 2011 19:04:25 -0800 (PST) Received: by 10.180.102.8 with HTTP; Mon, 7 Nov 2011 19:04:25 -0800 (PST) In-Reply-To: References: <8B0CE30D-5A56-4105-A10C-A6047A27A180@gmail.com> Date: Tue, 8 Nov 2011 11:04:25 +0800 Message-ID: From: GangChen To: sarikaya@ieee.org Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops , Arturo Servin Subject: Re: [v6ops] NAT64 Operational Considerations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 08 Nov 2011 03:04:28 -0000 Hello Behcet, 2011/11/8, Behcet Sarikaya : > Hi Arturo, > > I think this draft is not intended to repeat RFC 6146. > > The way I understood is the draft discusses how NAT64 can be deployed in > broadband networks. Section 2.3 states a lot of requirements that Broadband > Forum may be interested in. > > My question is what IDC? IDC is a practical deployment case for NAT64. And it's getting more and more prevalent. I adopt this as a case for NAT64 at CGN position. A specific feature for this case is NAT64 would not only take the role of IPv4-IPv6 translator, but also load-balancer. Not sure if answer your question :) Many thanks Gang > Regards, > > Behcet > > On Mon, Nov 7, 2011 at 11:04 AM, Arturo Servin > wrote: > >> Gang, >> >> I found a bit hard to see the target audience of this draft, it has >> a bit for developers and a bit for operators. >> >> As an operator I was expecting to see some practical >> recommendations on what to do (and what not to) for deploying NAT64. I >> haven't read RFC 6146 in a while but I think that you are repeating some >> of >> the recommendations that are said there. To make this document more >> valuable I would recommend you to go deeper in the practical >> considerations when deploying NAT64. >> >> Hope it helps, >> /as >> >> On 3 Nov 2011, at 00:00, GangChen wrote: >> >> > Dear all, >> > >> > I have just submitted the draft for NAT64 operational consideration. >> > The intention is to provide comprehensive considerations for NAT64 >> deployment. >> > The detailed information is listed at below >> > >> > A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> > >> > Title : NAT64 Operational Considerations >> > Author(s) : Gang Chen >> > Filename : draft-chen-v6ops-nat64-cpe-03.txt >> > Pages : 8 >> > Date : 2011-10-31 >> > >> > The document has summarized NAT64 usages on different modes, in which >> > NAT64 may serve for a large-scale network or would give enterprise or >> > residential service opportunities to be accessed by IPv6 remote >> > subscribers. The document has described different operations for >> > each usage and proposed operational considerations for each >> > particular NAT64-mode. >> > >> > A URL for this Internet-Draft is: >> > http://www.ietf.org/internet-drafts/draft-chen-v6ops-nat64-cpe-03.txt >> > >> > Many thanks >> > >> > Gang >> > _______________________________________________ >> > 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 brian.e.carpenter@gmail.com Mon Nov 7 19:25:39 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C90C11E80E1 for ; Mon, 7 Nov 2011 19:25:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.66 X-Spam-Level: X-Spam-Status: No, score=-102.66 tagged_above=-999 required=5 tests=[AWL=-0.727, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_FWDLOOK=1.666, 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 iGVsjvx2ED3b for ; Mon, 7 Nov 2011 19:25:38 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 80E0D11E80E0 for ; Mon, 7 Nov 2011 19:25:38 -0800 (PST) Received: by vws5 with SMTP id 5so50652vws.31 for ; Mon, 07 Nov 2011 19:25:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=TdQqD7B/Us2u+PAxdCveCZFxQDpp5ad8o3Mu4EvjIHg=; b=XbKVWRWcTXQgrlQO6SEXv7m9imcEYzatYiaOEmbMnkkDYW0l3bvg2WSXjn+e0aTHbI 5JUDQbVYBnhqOeZsQ4kKGoMnK0YGVN7JhmTpoWamqJRKoc2cvtGfXNjwSKxbcvxtVjG/ hIVxuAg+Vv+SYVz/7C+TRJVNrzMFGMYFOf5Lw= Received: by 10.52.22.226 with SMTP id h2mr13079901vdf.46.1320722737979; Mon, 07 Nov 2011 19:25:37 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id id7sm199733vdb.21.2011.11.07.19.25.35 (version=SSLv3 cipher=OTHER); Mon, 07 Nov 2011 19:25:37 -0800 (PST) Message-ID: <4EB8A141.8090901@gmail.com> Date: Tue, 08 Nov 2011 16:25:53 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dan Wing References: <4EB05384.5000007@gmail.com> <4EB1A443.1000301@gmail.com> <4EB44137.6040009@gmail.com> <045601cc9db1$9cb6a710$d623f530$@com> In-Reply-To: <045601cc9db1$9cb6a710$d623f530$@com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] OT: NA64 performance [ New Version Notification for draft-sunq-v6ops-contents-transition-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, 08 Nov 2011 03:25:39 -0000 On 2011-11-08 13:59, Dan Wing wrote: >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf >> Of Brian E Carpenter >> Sent: Friday, November 04, 2011 12:47 PM >> To: Qiong >> Cc: v6ops@ietf.org >> Subject: [v6ops] OT: NA64 performance [ New Version Notification for >> draft-sunq-v6ops-contents-transition-02.txt] >> >> On 2011-11-04 15:04, Qiong wrote: >> >> ... >>>> Personally I think a proxy is a more forward-looking solution, but >> NAT64 is >>>> a little more efficient, as a student of mine has proved. >>>> (See http://www.cs.auckland.ac.nz/~brian/NAT64-perf-Beijing.pdf) >>>> >>> Sorry, I'm kind of confused by the comparison result. It seems the >>> performance of NAT64 would decrease significantly for Big request. >> But in >>> our performance test, both on prototype and commercial device, we do >> not >>> find such problem. I can share you with our test results later. >> We could never explain that performance anomaly, even after inspecting >> the code and discussing with the software author. It is probably only >> an implementation issue. > > Were the packets big enough you might be hitting MTU problems or PMTUD? I really don't think so. "Large" meant an HTTP POST with 1200 bytes in the payload, for a total packet size of 1382 bytes. Our lab runs at 1500 bytes, and there was no encapsulation involved. We have a paper about these tests undergoing peer review, otherwise I would just post it here and now. Brian From bingxuere@gmail.com Mon Nov 7 21:49:15 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B58FF21F85AA for ; Mon, 7 Nov 2011 21:49:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.236 X-Spam-Level: X-Spam-Status: No, score=-3.236 tagged_above=-999 required=5 tests=[AWL=0.362, 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 6WTTRFD3d7bA for ; Mon, 7 Nov 2011 21:49:14 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 893C721F85B1 for ; Mon, 7 Nov 2011 21:49:14 -0800 (PST) Received: by iaeo4 with SMTP id o4so216926iae.31 for ; Mon, 07 Nov 2011 21:49:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=u4LtDARKKKcIEw2I3r/boQ6zwy5X7VDF0wEo/AqyFuk=; b=Bcj+4lsYgMEEXPMpSza+zrLTI/Wx6+ePWVkK0CtXO+mHjYaiSXqf4fK/matsriGDC8 W9eRHGFY2EK/COx4fsZZSYCavrVJluK6luDn3v5UlFGarhS8QDUNRGm9uZL5BOXx6rNX uS4G0jCT01sf4n30CTa1sYp8ZsB/LfMicC67I= Received: by 10.42.148.136 with SMTP id r8mr29134792icv.1.1320731354109; Mon, 07 Nov 2011 21:49:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.218.10 with HTTP; Mon, 7 Nov 2011 21:48:33 -0800 (PST) In-Reply-To: <4EB3F81D.1050106@redpill-linpro.com> References: <201111041609169589985@ctbri.com.cn> <4EB3F81D.1050106@redpill-linpro.com> From: Qiong Date: Tue, 8 Nov 2011 13:48:33 +0800 Message-ID: To: Tore Anderson Content-Type: multipart/alternative; boundary=90e6ba61351834987404b132bb78 Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: New Version Notificationfor draft-sunq-v6ops-contents-transition-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, 08 Nov 2011 05:49:15 -0000 --90e6ba61351834987404b132bb78 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Tore, Thanks again for your comments. See inline~~ On Fri, Nov 4, 2011 at 10:35 PM, Tore Anderson < tore.anderson@redpill-linpro.com> wrote: > > > Yes, my point was not really that you should make any strong > recommendation either way, just that it should be made clear that the > two deployment scenarios described are completely independent of each > other, and that there are nothing about them that *requires* them to be > co-located on the same box. Which means breaking up the "NAT64" box in > Figure 1 in two, and perhaps adding another figures in sections 5 and 6. > > ok, I get it. That's true, there is no "requirement" to be co-located in the same box. > > Well, I think SIIT is an old word obsoleted by RFC6145. > > The text in RFC6145 starts like this: > > =C2=ABThis document describes the Stateless IP/ICMP Translation Algorithm > (SIIT)=C2=BB > > So to me it seems that RFC6145 doesn't in any way obsolete the term > =C2=ABSIIT=C2=BB, quite the opposite: it _defines_ it. > > Well, the SIIT in RFC2765 defines both header translation and address translation, while RFC6145 only defines header translation, leaving address translation in RFC6052. Anyway, we need to find a well-defined word rather than create a new one, maybe SIIT :) > I am making no statement whether network, transport, or application > layer translation/proxying is the best, but it seems to me that the > alternatives should be mentioned, at least, so that the reader can > decide for himself which solution suits him the best. Unless, of course, > the scope of the document is meant to focus on network layer translation > exclusively. But its title and abstract doesn't indicate that. > > Agree, and we will mention it as two alternatives. Actually, come to think of it, the title of the document, =C2=ABRapid > Transition of IPv4 contents to be IPv6-accessible=C2=BB only really descr= ibes > the stateful model described in section 5. Maybe it should be made more > generic? Something like =C2=ABTransition of single-stack content to > dual-stack end-user availability=C2=BB, maybe? > Hmm~~~We will consider it:) Thanks Best regards Qiong > >> 6) I feel that the references to RFC 6219 is wrong. In all three > >> cases (sections 1, 3.1, and 6), it is used as a normative > >> reference, i.e., as the IVI protocol specification. However, RFC > >> 6219 is not a protocol specification as far as I can tell, it is > >> rather just a case study. It should therefore be an informative > >> reference. As far as I've been able to understand from reading RFC > >> 6219, the protocol called "stateless IVI" is in reality specified > >> in RFC 6145 where it is called "Stateless IP/ICMP Translation" > >> (SIIT). If this is correct, and there really is no difference > >> between "stateless IVI" and SIIT, I feel that the use of the name > >> IVI is questionable as it does not appear once in RFC 6145 (nor in > >> RFC 6052 for that matter). The only reference I find to the name > >> "IVI" in current IETF docs are in this draft as well as in RFC 6219 > >> (where it just seems to describe SIIT). I therefore suggest you > >> replace all mentions of (stateless) IVI with SIIT, and the related > >> normative references from RFC 6219 to RFC 6145. > > > > Thanks for pointing out this mistake. We will quote RFC6145 and > > RFC6052 as normative reference and replace RFC6219 as informative > > reference. Regarding the name issue, how about using "stateless > > translation" and "stateful translation" ? > > For the stateless model described in section 6, RFC 6145 (which in turn > refers to RFC 6052) is the protocol specification, and it defines the > name to be =C2=ABStateless IP/ICMP Translation=C2=BB, or =C2=ABSIIT=C2=BB= for short. > > For the stateful model described in section 5, RFC 6146 is the protocol > specification, and it defines the name to be =C2=ABStateful NAT64=C2=BB, = or just > =C2=ABNAT64=C2=BB for short. > > I really think you should stick to these names exactly as they are > defined. It's hard enough to keep track of all the various IPv6/IPv4 > transition technologies with only one name per tech, we really don't > need even more names to learn. :-) > > Best regards, > -- > Tore Anderson > Redpill Linpro AS - http://www.redpill-linpro.com > --90e6ba61351834987404b132bb78 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Tore,

Thanks again for your comments.

<= div>See inline~~
=C2=A0
On Fri, Nov= 4, 2011 at 10:35 PM, Tore Anderson <tore.anderson@redpill-linpro.com>= wrote:


Yes, my point was not really that you should make any strong
recommendation either way, just that it should be made clear that the
two deployment scenarios described are completely independent of each
other, and that there are nothing about them that *requires* them to be
co-located on the same box. Which means breaking up the "NAT64" b= ox in
Figure 1 in two, and perhaps adding another figures in sections 5 and 6.

ok, I get it. That's true= , there is no "requirement" to be co-located in the same box.
=C2=A0=C2=A0
> Well, I think SIIT is an old word obsoleted by RFC6145.

The text in RFC6145 starts like this:

=C2=ABThis document describes the Stateless IP/ICMP Translation Algorithm (= SIIT)=C2=BB

So to me it seems that RFC6145 doesn't in any way obsolete the term
=C2=ABSIIT=C2=BB, quite the opposite: it _defines_ it.

Well, the SIIT in RFC2765 def= ines both header translation and address translation, while RFC6145 only de= fines header translation, leaving address translation in RFC6052. Anyway, w= e need to find a well-defined word rather than create a new one, maybe SIIT= :)=C2=A0
=C2=A0
I am mak= ing no statement whether network, transport, or application
layer translation/proxying is the best, but it seems to me that the
alternatives should be mentioned, at least, so that the reader can
decide for himself which solution suits him the best. Unless, of course, the scope of the document is meant to focus on network layer translation exclusively. But its title and abstract doesn't indicate that.

Agree, and we will mention it as two alternatives.

Actually, come to think of it, the title of the document, =C2=ABRapid
Transition of IPv4 contents to be IPv6-accessible=C2=BB only really describ= es
the stateful model described in section 5. Maybe it should be made more
generic? Something like =C2=ABTransition of single-stack content to
dual-stack end-user availability=C2=BB, maybe?

Hmm~~~We will consider it:)

Thanks

Best regards

Qiong

=C2= =A0
>> 6) I feel that the references to RFC 6219 is wrong. In all three >> cases (sections 1, 3.1, and 6), it is used as a normative
>> reference, i.e., as the IVI protocol specification. However, RFC >> 6219 is not a protocol specification as far as I can tell, it is >> rather just a case study. It should therefore be an informative >> reference. As far as I've been able to understand from reading= RFC
>> 6219, the protocol called "stateless IVI" is in reality = specified
>> in RFC 6145 where it is called "Stateless IP/ICMP Translation= "
>> (SIIT). If this is correct, and there really is no difference
>> between "stateless IVI" and SIIT, I feel that the use of= the name
>> IVI is questionable as it does not appear once in RFC 6145 (nor in=
>> RFC 6052 for that matter). The only reference I find to the name >> "IVI" in current IETF docs are in this draft as well as = in RFC 6219
>> (where it just seems to describe SIIT). I therefore suggest you >> replace all mentions of (stateless) IVI with SIIT, and the related=
>> normative references from RFC 6219 to RFC 6145.
>
> Thanks for pointing out this mistake. We will quote RFC6145 and
> RFC6052 as normative reference and replace RFC6219 as informative
> reference. Regarding the name issue, how about using "stateless > translation" and "stateful translation" ?

For the stateless model described in section 6, RFC 6145 (which in tu= rn
refers to RFC 6052) is the protocol specification, and it defines the
name to be =C2=ABStateless IP/ICMP Translation=C2=BB, or =C2=ABSIIT=C2=BB f= or short.

For the stateful model described in section 5, RFC 6146 is the protocol
specification, and it defines the name to be =C2=ABStateful NAT64=C2=BB, or= just
=C2=ABNAT64=C2=BB for short.

I really think you should stick to these names exactly as they are
defined. It's hard enough to keep track of all the various IPv6/IPv4 transition technologies with only one name per tech, we really don't need even more names to learn. :-)

Best regards,
--
Tore Anderson
Redpill Linpro AS - http://www.redpill-lin= pro.com

--90e6ba61351834987404b132bb78-- From bingxuere@gmail.com Mon Nov 7 22:13:53 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53A2321F8CA2 for ; Mon, 7 Nov 2011 22:13:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.954 X-Spam-Level: X-Spam-Status: No, score=-2.954 tagged_above=-999 required=5 tests=[AWL=0.044, 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 DVuL2TCMOqBa for ; Mon, 7 Nov 2011 22:13:52 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 83A4321F8C9F for ; Mon, 7 Nov 2011 22:13:52 -0800 (PST) Received: by iaeo4 with SMTP id o4so241192iae.31 for ; Mon, 07 Nov 2011 22:13:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=jctg00iGMqHvWbKvMH/52+Q8hmkMZ1kE7xz596bqwxA=; b=EfiTUf9cP4jTNq2zO96X6G3S71BkKLhOhFyH0dKMaI2cT7keFAPpbawtMcrSb2bOLq gnstsW96/J1phkYVWzQjkcOS0fLZ9GxXybHK/hptrLytu9o9iUzoEgqs8oQec9Xn8WQN YHou1/o4VS+GYMtvPBxY25DPrHnp0/FHkenjg= Received: by 10.42.155.74 with SMTP id t10mr50983046icw.49.1320732832112; Mon, 07 Nov 2011 22:13:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.218.10 with HTTP; Mon, 7 Nov 2011 22:13:11 -0800 (PST) In-Reply-To: <4EB54C85.4050909@bogus.com> References: <4EB05384.5000007@gmail.com> <4EB54C85.4050909@bogus.com> From: Qiong Date: Tue, 8 Nov 2011 14:13:11 +0800 Message-ID: To: Joel jaeggli Content-Type: multipart/alternative; boundary=90e6ba6e8dbc4d217904b13313ae Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Fwd: New Version Notification for draft-sunq-v6ops-contents-transition-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, 08 Nov 2011 06:13:53 -0000 --90e6ba6e8dbc4d217904b13313ae Content-Type: text/plain; charset=UTF-8 Hi, Joel On Sat, Nov 5, 2011 at 10:47 PM, Joel jaeggli wrote: > > After all, dual stack is what we have discussing for 10 years. But up to > > now, how many ICPs have upgraded to IPv6 in dual-stack directly? I > > really think we need to re-think it again, from both technical aspect > > and the industry/or market aspect. And the first step is rather > > important to give us confidence to move forward. That's why we recommend > > single-stack (either v4 or v6) transition in the current phase. Then, > > for the conservative ones, the IPv4 services can be still offered > > natively, and the IPv6 services can be offered by the stateful NAT64; > > while for progressive ones and newly comers, the stateless IVI can be > > employed to offer native IPv6 services reachable via IPv4. And we hope > > it would help enrich IPv6 content asap. Then how do you think ? > > Any solution that causes me to lose access to the source address is not > usable from my vantage point as a content provider. When I terminate > connections on an l7 load balancer as I generally do for http/https on > ipv4 and where we do it in ipv6 I can drop x-forwarded for in there. > That requires that I recieve the traffic unmolested by a nat transform > associated with my own service. > > I agree it is important. But there is another question here : although you can use l7 load balancer to insert x-forwarded here, how can you guarantee that there is no CGN along the path from the user's end-host to the data center. I mean, in case we cannot avoid deploying some kind of address sharing mechanisms in the future, ICPs have to face the fact that they will somehow lose the geo-location info when they receive IPv4 traffic. So maybe it is one choice to provide them with a database which stores the original binding information. Would it be some kind of helpful ? Thanks Best wishes Qiong > > Thanks > > > > Qiong > > > > > > On Wed, Nov 2, 2011 at 4:16 AM, Brian E Carpenter > > > > wrote: > > > > I'm not seeing why this is a better solution for a small/medium ICP > > than just moving to a dual stack. That is much easier for a small > > network than for a big one. > > > > Regards > > Brian > > > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > --90e6ba6e8dbc4d217904b13313ae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Joel

On Sat, Nov 5, 2011 at 10:47 PM,= Joel jaeggli <joe= lja@bogus.com> wrote:
> After all, dual stack is what we have discussing for 10 years. But up = to
> now, how many ICPs have upgraded to IPv6 in dual-stack directly? I
> really think we need to re-think it again, from both technical aspect<= br> > and the industry/or market aspect. And the first step is rather
> important to give us confidence to move forward. That's why we rec= ommend
> single-stack (either v4 or v6) transition in the current phase. Then,<= br> > for the conservative ones, the IPv4 services can be still offered
> natively, and the IPv6 services can be offered by the stateful NAT64;<= br> > while for progressive ones and newly comers, the stateless IVI can be<= br> > employed to offer native IPv6 services reachable via IPv4. And we hope=
> it would help enrich IPv6 content asap. Then how do you think ?

Any solution that causes me to lose access to the source address is not
usable from my vantage point as a content provider. When I terminate
connections on an l7 load balancer as I generally do for http/https on
ipv4 and where we do it in ipv6 I can drop x-forwarded for in there.
That requires that I recieve the traffic unmolested by a nat transform
associated with my own service.

I agree it is important. But there is another questio= n here : although you can use l7 load balancer to insert x-forwarded here, = =C2=A0how can you guarantee that there is no CGN along the path from the us= er's end-host to the data center. I mean, in case we cannot avoid deplo= ying some kind of address sharing mechanisms in the future, ICPs have to fa= ce the fact that they will=C2=A0somehow=C2=A0lose the=C2=A0geo-location inf= o when they receive IPv4 traffic. So maybe it is one choice to provide them= with a database which stores the=C2=A0original=C2=A0binding information. W= ould it be some kind of helpful ?=C2=A0

Thanks

Best wishes
<= br>
Qiong

=C2=A0
> Thanks
>
> Qiong
>
>
> On Wed, Nov 2, 2011 at 4:16 AM, Brian E Carpenter
> <brian.e.carpenter@g= mail.com <mailto:bria= n.e.carpenter@gmail.com>> wrote:
>
> =C2=A0 =C2=A0 I'm not seeing why this is a better solution for a s= mall/medium ICP
> =C2=A0 =C2=A0 than just moving to a dual stack. That is much easier fo= r a small
> =C2=A0 =C2=A0 network than for a big one.
>
> =C2=A0 =C2=A0 Regards
> =C2=A0 =C2=A0 =C2=A0 Brian
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


--90e6ba6e8dbc4d217904b13313ae-- From dwing@cisco.com Tue Nov 8 16:32:13 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 297E511E8095 for ; Tue, 8 Nov 2011 16:32:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.569 X-Spam-Level: X-Spam-Status: No, score=-105.569 tagged_above=-999 required=5 tests=[AWL=0.430, 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 8bg6uqP5bntb for ; Tue, 8 Nov 2011 16:32:12 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 4C7C011E8081 for ; Tue, 8 Nov 2011 16:32:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2787; q=dns/txt; s=iport; t=1320798732; x=1322008332; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=9Ih9wKuinMMyR9bh0NKY3Ttz0zRuvgVCkRyV+9R3Oiw=; b=gLtTplJw0Vungv2uNekvTd/vVw7bDWZ5VEg49sdtfbGEIfXbwkSoc04x M80LoOL8l2/6yUqtbHFQmG2SNtsTgqW5DQ3OsS5fDxybzrTRE7OuScW7F geMqLcxAmmLUMcdYvIyX6H/i6NThzchlZhI6e8ak5cMQ1tCYJbI04Jg6N U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArQAAHrJuU6rRDoG/2dsb2JhbABEmiCBa4xzgSaBBYFyAQEBAwEBAQEFCgEXEDQQBwEDAgkPAgQBASgHGQ4VCgkIAgQBEgkCF4dgCJlxAZ5tiS0EiAueJQ X-IronPort-AV: E=Sophos;i="4.69,480,1315180800"; d="scan'208";a="13095013" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 09 Nov 2011 00:32:12 +0000 Received: from dwingWS ([128.107.106.204]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pA90WC0t019341; Wed, 9 Nov 2011 00:32:12 GMT From: "Dan Wing" To: "'Eleven Fu\(Yu\)'" , "'GangChen'" , "'v6ops'" References: In-Reply-To: Date: Tue, 8 Nov 2011 16:32:11 -0800 Message-ID: <031801cc9e77$05aaacb0$11000610$@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: AQHMmcxglIuIpdbo1UGhL5Y1kpvDp5WgySOAgALwqtA= Content-Language: en-us Subject: Re: [v6ops] NAT64 Operational Considerations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 09 Nov 2011 00:32:13 -0000 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Eleven Fu(Yu) > Sent: Monday, November 07, 2011 2:02 AM > To: GangChen; v6ops > Subject: Re: [v6ops] NAT64 Operational Considerations > > Hi Gang, > > I have read draft-chen-v6ops-nat64-cpe, please see come comments below, > > The draft is structured by different deploy positions of NAT64 as > different modes. It describes operational process for each mode. But I > think as a informational guide for readers, some more considerations > need to be described for each mode in more detail, such as logging > problem, ALG issues, DNS, load balancing etc. > > For section 4, some security considerations also need to be involved, > such as user tracking, Dos attack etc. Logging, user tracking, and DoS attacks are a problem with all IPv4 address sharing mechanisms -- not just NAT64. Is http://tools.ietf.org/html/rfc6269 inadequate at describing the issues? Are there NAT64 *specific* issues of logging, user tracking, and DoS attacks that should be included in a document like draft-chen-v6ops-nat64-cpe? -d > Cheers > > Yu > > > > > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of GangChen > Sent: Thursday, November 03, 2011 10:00 AM > To: v6ops > Subject: [v6ops] NAT64 Operational Considerations > > Dear all, > > I have just submitted the draft for NAT64 operational consideration. > The intention is to provide comprehensive considerations for NAT64 > deployment. > The detailed information is listed at below > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : NAT64 Operational Considerations > Author(s) : Gang Chen > Filename : draft-chen-v6ops-nat64-cpe-03.txt > Pages : 8 > Date : 2011-10-31 > > The document has summarized NAT64 usages on different modes, in which > NAT64 may serve for a large-scale network or would give enterprise or > residential service opportunities to be accessed by IPv6 remote > subscribers. The document has described different operations for > each usage and proposed operational considerations for each > particular NAT64-mode. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-chen-v6ops-nat64-cpe-03.txt > > Many thanks > > Gang > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From Carl.Wuyts@technicolor.com Wed Nov 9 01:22:07 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCD2C21F84D5 for ; Wed, 9 Nov 2011 01:22:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.178 X-Spam-Level: X-Spam-Status: No, score=-4.178 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oh64Dc+T2AWH for ; Wed, 9 Nov 2011 01:22:03 -0800 (PST) Received: from na3sys009aog123.obsmtp.com (na3sys009aog123.obsmtp.com [74.125.149.149]) by ietfa.amsl.com (Postfix) with ESMTP id 9929821F84CD for ; Wed, 9 Nov 2011 01:22:02 -0800 (PST) Received: from mopesedge02.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob123.postini.com ([74.125.148.12]) with SMTP ID DSNKTrpGMpJflTXwQIHo8s+Iodki2DHqjAc6@postini.com; Wed, 09 Nov 2011 01:22:02 PST Received: from MOPESMAILHC01.eu.thmulti.com (141.11.100.25) by mopesedge02.eu.thmulti.com (141.11.253.23) with Microsoft SMTP Server (TLS) id 8.3.192.1; Wed, 9 Nov 2011 10:21:02 +0100 Received: from MOPESMBX01.eu.thmulti.com ([169.254.155.121]) by MOPESMAILHC01.eu.thmulti.com ([141.11.100.25]) with mapi; Wed, 9 Nov 2011 10:21:12 +0100 From: Wuyts Carl To: "v6ops@ietf.org" Date: Wed, 9 Nov 2011 10:21:11 +0100 Thread-Topic: RFC6204bis-02 Thread-Index: AcyewOvBbq1YdOdiSD66Sp1uaN6CQw== Message-ID: <867F4B6A1672E541A94676D556793ACD0C263BCDD7@MOPESMBX01.eu.thmulti.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/related; boundary="_006_867F4B6A1672E541A94676D556793ACD0C263BCDD7MOPESMBX01eut_"; type="multipart/alternative" MIME-Version: 1.0 Subject: [v6ops] RFC6204bis-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, 09 Nov 2011 09:22:07 -0000 --_006_867F4B6A1672E541A94676D556793ACD0C263BCDD7MOPESMBX01eut_ Content-Type: multipart/alternative; boundary="_000_867F4B6A1672E541A94676D556793ACD0C263BCDD7MOPESMBX01eut_" --_000_867F4B6A1672E541A94676D556793ACD0C263BCDD7MOPESMBX01eut_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, Ole has asked me, @ RIPE meeting in Vienna last week, to review the RFC6204= bis, basically to see if it would have a lot of impact towards the/our CPE = and whether or not it would be useful to publish it with its current conten= t. Overall, I don't think this version really adds a lot of extra requirements= . This could be a reason to wait however, it "just" adds 6rd/DSlite as bas= ic mechanisms, which is OK + it re-phrases a few of the other requirements.= I think it could also be used to add some extra info on some of the exist= ing RFC6204 requirements (see remarks below on WAA-8 and WPD-5). I've exchanged a few mails with Ole on this, and he suggested me to bring t= hese things up on v6ops; reason for this mail. Find my comments below. 1. DLW-4: If the IPv6 CE Router is configured with a public IPv4 add= ress on its WAN interface, where public IPv4 address is defined as any addr= ess which is not in the private IP address space specified in [RFC5735] and= also not in the reserved IP address space specified in [RFC6333], then the= IPv6 CE Router MUST disable the DS-Lite B4 element. This one is not fully ok I'd say. First of all, the DSlite is supposed to = run on a v6-only intf, hence you could consider it as a configuration issue= in case you have configured a public IPv4 on it ? Even if not, I don't s= ee what you should have to check for public IPv4 address presence to bring = up (or not) the DSLite intf. And then what happens if the DSLite tunnel is up, and a public IPv4 is bein= g configured on top ? Bring it down ? Imagine you boot the CPE, preconfigured with DHCPv6 option for dslite. Thi= s will bring up the DSLite intf, because of the option, why bothering check= ing the public IPv4 presence ? Maybe this is not really an issue, afterall, it's a configuration "mistake"= . So my recommendation here would be to remove this requirement. That's all wrt to RFC6204bis. I must say, that some of the RFC6204 require= ments currently present are not really clear on what they exactly cover, i.= e. some of them can be, imho, interpreted in multiple ways hence might lead= to some confusion. 2. WAA-8: If the IPv6 CE router does not acquire global IPv6 address= (es) from either SLAAC or DHCPv6, then it MUST create global IPv6 address(e= s) from its delegated prefix(es) and configure those on one of its internal= virtual network interfaces. I assume this is describing the situation where the WAN intf does not get a= n IPv6 addr (not via RA, not via dhcpv6 ia_na). In this situation, you wan= t to configure one from the delegated prefix on "a virtual network intf (be= ing exactly what, loop ?)". If the delegated prefix <>64, I don't see an i= ssue, however, if the ia_pd prefix length =3D 64, this would mean that only= the CPE would get an IPv6 address from the ia_pd, and nothing more left to= distribute on the LAN OR the only available /64 gets sent to the LAN hosts= , but nothing available on the CPE (for remote management). Ole's answer to this was: "" in 6204bis this requirement has been weakened with the additional "unless c= onfigured to require a global IPv6 address on the WAN interface". to avoid = cable CPEs having to comply with this. the motivation for the original requirement, is to give the CPE an IPv6 add= ress that is independent of LAN side interface state, that can be used for = e.g. management of the CPE. in the case of the single /64, I would use that on the LAN interface and co= nfigure an address out of it. if you get more, I would reserve a /64 for "l= oopback" on the box. "" And "" I do agree with your point though, WAA-8 is written under the assumption th= at a delegated prefix would be larger than a /64. I don't know if we should fix that, or use it as a signal to ISPs that the = practice of only /64 is not going to work well. "" So I think one cannot rule out the possibility of using /64s. Maybe it's n= ot (and it should not) be the preferred way but on the other hand, it is al= lowed. So my recommendation here would be to add a /64 behavior to avoid c= onfusion or other interpretation. 3. WPD-5: If the IPv6 CE router initiates DHCPv6 before receiving a = Router Advertisement, it MUST also request an IA_NA option in DHCPv6. So this is linking RA presence/receiving with the request for ia_na or not= . I don't think these 2 things should be linked, i.e. the ia_na option will b= e configured upfront in the DHCPv6 client configuration or not, it should n= ot be added on the fly. Ole's answer to this: "" the purpose of this was twofold: - keep DHCP and RA processing separate (allow for both being done in parall= el) - allow for a single DHCP session for both addresses and prefixes. "" And "" yes, unfortunately the M-bit is tied to IA_NA processing. the latest revision 03 is proposing that _no_ IPv6 DHCP should happen until= an RA is received with either M or O =3D 1. "" Our opinion on this one is that they should not be linked, so either allow = for configuration to listen to RA or not, and act upon it, or just deal wit= h the result, just request both, independent from RA received or not. Supp= ose you're on a ptp link, you might not even want to see RA, hence you shou= ld not tie yourself up to it, unless you want to make things more complex a= nd start defining exceptions. My 2 cents regs Carl Wuyts GCD System Architect Networking Connect Division carl.wuyts@technicolor.com tel.: +32 3 443 65 90 [cid:image001.gif@01CC9EC9.4D835710] [cid:image002.gif@01CC9EC9.4D835710] Prins Boudewijnlaan 47 - 2650 Edegem - Belgium Technicolor Delivery Technologies Belgium NV Registered office (maatschappelijke zetel): Prins Boudewijnlaan 47, 2650 Ed= egem, Belgium Company registration number (ondernemingsnummer): 0428837295 - RPR Antwerpe= n [cid:image003.gif@01CC9EC9.4D835710] Help preserve the color of our world - Think before you print. Carl Wuyts GCD System Architect Networking Connect Division carl.wuyts@technicolor.com tel.: +32 3 443 65 90 [cid:image001.gif@01CC9EC9.4D835710] [cid:image002.gif@01CC9EC9.4D835710] Prins Boudewijnlaan 47 - 2650 Edegem - Belgium Technicolor Delivery Technologies Belgium NV Registered office (maatschappelijke zetel): Prins Boudewijnlaan 47, 2650 Ed= egem, Belgium Company registration number (ondernemingsnummer): 0428837295 - RPR Antwerpe= n [cid:image003.gif@01CC9EC9.4D835710] Help preserve the color of our world - Think before you print. --_000_867F4B6A1672E541A94676D556793ACD0C263BCDD7MOPESMBX01eut_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,<= /p>

 

Ole has a= sked me, @ RIPE meeting in Vienna last week, to review the RFC6204bis, basi= cally to see if it would have a lot of impact towards the/our CPE and wheth= er or not it would be useful to publish it with its current content.

 

Over= all, I don’t think this version really adds a lot of extra requiremen= ts.  This could be a reason to wait however, it “just” add= s 6rd/DSlite as basic mechanisms, which is OK + it re-phrases a few of the = other requirements.  I think it could also be used to add some extra i= nfo on some of the existing RFC6204 requirements (see remarks below on WAA-= 8 and WPD-5).

 

I’ve exchanged a few mails with Ole on this, and he = suggested me to bring these things up on v6ops; reason for this mail. = Find my comments below.

 

1.     &nbs= p; DLW-4:  If the IPv6 CE Router is = configured with a public IPv4 address on its WAN interface, where public IP= v4 address is defined as any address which is not in the private IP address= space specified in [RFC5735] and also not in the reserved IP address space= specified in [RFC6333], then the IPv6 CE Router MUST disable the DS-Lite B= 4 element.

 

 

This one is not fully ok= I’d say.  First of all, the DSlite is supposed to run on a v6-o= nly intf, hence you could consider it as a configuration issue in case you = have configured a public  IPv4 on it ?  Even if not, I don’= t see what you should have to check for public IPv4 address presence to bri= ng up (or not) the DSLite intf.

And t= hen what happens if the DSLite tunnel is up, and a public IPv4 is being con= figured on top ?  Bring it down ?

Imagine you boot the CPE, preconfigured with DHCPv6 option for dslite.&nb= sp; This will bring up the DSLite intf, because of the option, why botherin= g checking the public IPv4 presence ?

Maybe this is not really an issue, afterall, it’s a configuration &#= 8220;mistake”.

 

So my recommendation here would be to remov= e this requirement.

 

 

T= hat’s all wrt to RFC6204bis.  I must say, that some of the RFC62= 04 requirements currently present are not really clear on what they exactly= cover, i.e. some of them can be, imho, interpreted in multiple ways hence = might lead to some confusion.

= <= o:p> =

= 2.    &nbs= p;  WAA-8:  If the IPv6 CE rout= er does not acquire global IPv6 address(es) from either SLAAC or DHCPv6, th= en it MUST create global IPv6 address(es) from its delegated prefix(es) and= configure those on one of its internal virtual network interfaces.

 

I assume this is describing the situation where the WAN intf does = not get an IPv6 addr (not via RA, not via dhcpv6 ia_na).  In this situ= ation, you want to configure one from the delegated prefix on “a virt= ual network intf (being exactly what, loop ?)”.  If the delegate= d prefix <>64, I don’t see an issue, however, if the ia_pd pref= ix length =3D 64, this would mean that only the CPE would get an IPv6 addre= ss from the ia_pd, and nothing more left to distribute on the LAN OR the on= ly available /64 gets sent to the LAN hosts, but nothing available on the C= PE (for remote management).

&nbs= p;

Ole’s answer to this was:

“”

in 6204bis this requirement has been weakened with the additional = "unless configured to require a global IPv6 address on the WAN interfa= ce". to avoid cable CPEs having to comply with this.=

the motivation for the original requirement, is to giv= e the CPE an IPv6 address that is independent of LAN side interface state, = that can be used for e.g. management of the CPE.

in the case of the single /64, I would use that on the LAN inte= rface and configure an address out of it. if you get more, I would reserve = a /64 for "loopback" on the box.

“”

And

“”

I do agree with your point though, WAA-8 is written under the assumptio= n that a delegated prefix would be larger than a /64.

=

I don't know if we should fix that, or use it as a signal = to ISPs that the practice of only /64 is not going to work well.=

“”

So I think one cannot rule out the possibility of using /64s. = ; Maybe it’s not (and it should not) be the preferred way but on the = other hand, it is allowed.  So my recommendation here would be to add = a /64 behavior to avoid confusion or other interpretation.

 

 

3. &= nbsp;     WPD-5: = ; If the IPv6 CE router initiates DHCPv6 before receiving a Router Advertis= ement, it MUST also request an IA_NA option in DHCPv6.

&= nbsp;

So this is linking RA= presence/receiving  with the request for ia_na or not.

I don’t think these 2 things should be linked= , i.e. the ia_na option will be configured upfront in the DHCPv6 client con= figuration or not, it should not be added on the fly.

=

 

Ole’s a= nswer to this:

“”

the purpose of this was twofold:<= /span>

- keep DHCP and RA processing separate (allow fo= r both being done in parallel)

- allo= w for a single DHCP session for both addresses and prefixes.

“”

And

“”

yes, unfortunately the M-bit is tied to IA_NA processing.

the latest revision 03 is proposing that= _no_ IPv6 DHCP should happen until an RA is received with either M or O = =3D 1.

“”<= /p>

Our opinion on this one is that they should not = be linked, so either allow for configuration to listen to RA or not, an= d act upon it, or just deal with the result, just request both, independent= from RA received or not.  Suppose you’re on a ptp link, you mig= ht not even want to see RA, hence you should not tie yourself up to it, unl= ess you want to make things more complex and start defining exceptions.

 

M= y 2 cents

regs

 

Carl Wuyts

GCD System Architect Networking

Connect Divi= sion

carl.wuyts@technicolor.com

tel.: +32 3 443 65 90

3Dtwitter

3D"Visit

Prins Boudewijnlaan 47  -  2650 Edegem &= nbsp;-  Belgium

Technicolor Delivery Tech= nologies Belgium NV

Registered office (maatschappelijke zetel): Prins Boudewijnlaan = 47, 2650 Edegem, Belgium

<= span style=3D'font-size:7.0pt;font-family:"Arial","sans-serif";color:#9D9FA= 2'>Company registration number (ondernemingsnummer): 0428837295 - RPR Antwe= rpen

3DEco=

Help preserve the color of our world - Think = before you print.

 

 

 

 = ;

= --_000_867F4B6A1672E541A94676D556793ACD0C263BCDD7MOPESMBX01eut_-- --_006_867F4B6A1672E541A94676D556793ACD0C263BCDD7MOPESMBX01eut_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=1351; creation-date="Wed, 09 Nov 2011 09:21:11 GMT"; modification-date="Wed, 09 Nov 2011 09:21:11 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhGAAYAPcAAAAAAP///1Sfum/L64bW8o7h/ofU74fT7pHb9pfa8u75/VbD5VzG6FvF5l3G 513F5l/G51/F5mHH52PH6GPI6GPI52TH6GXJ6GbI6GnK6mjJ6WjK6WzL6m/M63HN6nPN6nTN63fR 7XnR7XTI5FeVqnnN537T7n7R7H/T7X3O6Y3f+4jV73m903/E2oDE2pTf+ZPc9JTa8Zfa8aDd8LDj 9MXr9+z5/er3+/r9/imy1yyx1S202S2z1zK43TW63jW32zS22Ta53Te73za32zq84Dm53Du73j2/ 4j2+4T283z273kHB5D++4EHA4kG/4UPA40K/4UTB5EbD5UbB40rJ7EjD5ErG6EnE5knE5Ua720rE 5kvG507J607I6U3G50/K60u+3U2/4U7A4k2/3lLI6E/A31XN7lHC4VnP8FfL61PD4lXD5FXF41vR 8VfG5VO92lrJ51a+21i/21/O7F7L6VnB3VzE4mHN6l/H5V3D30+lvWDH41/E4GDF4WLH42rL6GvP 6l+2znLZ9W7Q62C1zGO50HXZ9HTY83ba9XXX8mW70nLO6nHN6We803rd+HXV73zf+mm91HXS62vA 12GpvWavw2ixxVmWp2qxxYDW7X3Q52yzxm+2yW60x4HS6HC2yXG3ynzD2I7a75Xb7pvh9F+HkqTg 8ajg76ff7qri8bPo97fm9Ljm9MXw/Mfw/NDz/dDx+tbx+dz0++H1++f5/uv5/Six1S+22jG01zK1 2EXD5E/M7U7H50yvyWPY91zJ5WjZ92za927b+HHY82G4z3Xd+FurwHXa9Xfc93ne+F+rv37h+2u/ 1YDi/H7c9YHh+YLh+YXi+mqyxWuzxork+ovj+o3l+3K4ypXn+12PnJrm+qXp+63j8cLx/M/0/ef4 /Jfp+57q+6Xt/Kjv/avv/a3v/a7w/bPw/bzz/uP6/+z7/vP9/7fz/r30/sD0/sX1/sn2/tT4/9L2 /d/6/+X7/+b7/+r8/+v7/sz3/tr5/ub8/+39//v///3///7//////yH5BAEAAP8ALAAAAAAYABgA AAj/AP8JHEiwoMGCAgggOGCg4YqHEB8aOPCCAEESKmR84MABg0cOHUKGHDCAA4gEBQaOiIHBwgQO pmrQEEEhg80NGnJewACDhcAUJyBMwBArgL8ACkxc2MBUg8cLEEy0+PkhQoMZAerNmxegBoMLFChc AFsBQggXAkswerBgVYB8+eLtu7GorgcKDipIcBBi6r8SHtiyCoAPH7x6AXAoxjELRYO9IUIJlGMn jBi37zLHo2fPXj19/hT8WRMGDzGBb7LosIUqADp07WC7c9eOHbwAmnjwGBNIYBwwuHK0NleOOLnj 5MaxC+BpR64zp//JGQNkx6kA4rKXO8ede7oAe378/1BTSGCdMkNunfIXLhw4eQH6yU88KoiSImzK /8tzpkiPVP1gg4013gRgYGKmEMEEE0a4oYhAeahhhA/c8FMNNdF0s4466tyzTgCrOAFFEnA0IhAf bCQhhCkBVPMMNDDC+GI3AUiCBBNwRCJQH24wgUQmAWwjTDJEFllMNAGIcoQTdDAjkB9uODGFFLHw o00wwGSZpS/bBJDJEk80+eQvTVQhxR2zBECLK6202c0rAchCxhVR3DGJb5I0gYUXVqRBCiy1BFqL Dd+oMocVW+jyCCEC6ZEIIFps0cUXVOyCRhuYomEGFVx0wcsghlwyUC/DOHPIMcg4AskyzbS6DCSO ICSDiDOCGFNQNspUYgkmm3TCCSjXgPJJJ9NIYwklpRyk7LIDBQQAOw== --_006_867F4B6A1672E541A94676D556793ACD0C263BCDD7MOPESMBX01eut_ Content-Type: image/gif; name="image002.gif" Content-Description: image002.gif Content-Disposition: inline; filename="image002.gif"; size=1834; creation-date="Wed, 09 Nov 2011 09:21:11 GMT"; modification-date="Wed, 09 Nov 2011 09:21:11 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhcgBFAOZ/AEGueqipqmgxkACLS4ORyPb294DFpZrMVqvi+sXr2Ie3laLXtnRHnLQlZO3J 2M+pxP7pJvqtgePqmqOIvYLKnACP1fewoXa65/vCov71sdqRnc6OpPvrlcU/benvs7qmzpzR8P/n rc7imtLntMkhU/V7Hf/yl+fZ6f3HipjL7b+MraKs1h+WXIrU9fNrPv/dkaTIrpQpd/JlIr8kXv/o ALa3uO0bLwCmUQC68pKSlf/CDgxNosvbKtvb3IzGP8nJyoiJjPaWgH+Ag3Z3euTk5Y3Y+MTfm+3t 7r/AwZubnvBSJQCZ3NLS0//eAwN+yE84la9fmdjkX//RSiPB855BhP/ILiCvY9HeRvLkCvmykSld q/aNl4Dd+cPT6O85Q2m+Q6zRONnM5OPx0PR3OR2Z2eOttkCr4Lfbm//uQPWMWbeLscPbysbs/OP1 /ZeLwPaLN9blff/iEvXlByCi3nzB69eqvN7r4uzysHfDWSCKzu+Uh8R4pR6j4IVfqm1ucf///yH5 BAEAAH8ALAAAAAByAEUAAAf/gH+Cg4SFhoeIiYqLjI2Oj5CRkpOUlZaXmJmam5ydnp+goaKjpKWm p6ipqqusra6vsLGys7S1tqF+Oat+freMubu9vorAkkhIlryqBQWXxZBEvD2VyqhEQtPJupJJScnC pzV+2dTbqdWnSX4BNTWDR+01RIUFSO0/zX/AP+1Mg/x/iLRDku9PO0JH7NXA906hv0Ho/vSId2TQ xB4Jf1gKwKujoB8deWn8OCTkkIp+gAAJGUBQjnUhgUAEB9Lkx5C58lUr8DLkSHE5Spqb1IMjkh7T evgZ4o9JyYrR/Mib2FKfHyH4kPBq1rPGkR4lH1ZjsvQH0gDIlA7RSGSlN6uC/zgCmfcjrEFeQuRd EkeO48g/IN2pQ2boasGV014+/MPRHdw/QsYZUve3wFO4R5YWBOlN3FtMfAetBJKj9EpdEQk9+/My sWRB4hxXS3koNcdpypRWnXnXMejXf4SWHt4yNcShrVkDjy1o9lDehELnXldIGfNMoV0CJxSZnGrk kpPDltpc2FZDK+eJlqwsmsx3V3trEvdXK5CKgvKJu59fLHjX5FxXjVz5fHUXEPmAJER5gkQ2UgHq uHMdJiANkcNIK+WSQ2TraaiZPv8pFyB5jxWwkoUvLWjiVUlkmE01RJQERACRISifJhxR90cBNUTG YkE1ZAgEYTnsxlgO8wSA5P8/F7pkDo8+AvFgj7wkoR5r5hChzlU1JNjkMGCGKeaYZJZp5pmqsIHA mmyCkMKbcK4g55wrfGDnnR88oOeedZTh558WBCqoBRgUaigGISSqaAgZNOroHR5EKqkHI1Rq6QKY ZroADJx2CoMdjxSAQBGkktoCHRekqioBrLZKgBsTxCqrGirUaqsGuOaqgR5B9OprBMAGG8ELxBb7 ggnIJmuCBMw2K4EIRkQb7RkUVGstBQpkq60CazTSRqmlnqrqqq6yCqusstqqrq65+uqusMGiYCyx HCiLLAfONguttEZQe22122oLQ0GHsAGuqeOSW+656E6grq0bsIuru7/CG4H/vPMea++y+TK7r7T+ /huwtqAiMsXJKE/BBxkst5yHFjDHrAUDNNdMMxU450xFBzz3zLMXQAfthQtjFG30G1UkrXQVEDTt dNNXRC31FWAcYPXVeFih9dZWsOD11ywAkAgOZJeNwxIVpK22Ezu07fYOTwgg99wCxGD33TE0MMPe fJNgw9+A26CEDIQXXoIOiCeuQxM0NO44FjxELjkPYPhg+eVf3KD55jcM4PnnA4iNiNllo6122my/ 3XbcdMuN9916872334H/PXjhhB+uOOKMO9445JNHXvnllmfOueagfy76IaSTbfrpqavOeuuv2x27 7LTXfjvuuu/eu+/ABz88//HGH5+858sb0vzZp6Ou+uqtu1799X3Xbjvuue/Ou++/By888cU7HvLO l75CrO95a3sf3OJXt/nJbnb2Exz+ZNA9xX3vcf6jHAB9UD7OnS90Y2seAt33vunRrXp5e+AMshe4 7RlOf4vjHw3CN7nxYU6AnSNgCEk3wgpE720mnBsK6QdB+7kwf/q7YP/8BwcxOPGJC8DhBwtIiAO2 z4cKDKL8XkfEFUbwiBSEoRJpIIcomPGMUbiDIRIgRR2OToRXrEAX5kjHLvSBgUNUIQsBB8YSSOGP gJRCHGRIA0ewUYBTTAQXFslILswhjoe4Y/zy+EASbOGSmNyCCyYog0OggYeQhgSAKEcJABa40RFm gKQhThCGVrryAZR84CHSwElPgrISADhlI1J5RUc4IJaym2UtSZHL5FFREbxsny9RuAcHOPOZDjgE BrJAzWpmoRQLMIA2t7kASCTzdI44ARTGSU4oPABN6EynOtfJzna6853wjKc850nPetrznvjMpz73 yc9++tMUgQAAOw== --_006_867F4B6A1672E541A94676D556793ACD0C263BCDD7MOPESMBX01eut_ Content-Type: image/gif; name="image003.gif" Content-Description: image003.gif Content-Disposition: inline; filename="image003.gif"; size=493; creation-date="Wed, 09 Nov 2011 09:21:11 GMT"; modification-date="Wed, 09 Nov 2011 09:21:11 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhHAAhAMQAALHNVVqXGZu+IqbFNv79/ury0pK4H2SdaJzAJNjlq/3++vL34srdiSl5Mfj7 8OHrvDmDE5u+Kb3VbtDgm5jCnJC2IqDBJHqqHoazHsfYxcfco+/58f7///7+/v///f///yH5BAAA AAAALAAAAAAcACEAAAX/4CeOZGmeaKqubOumXSfKL0rT9RiTe65/nl0vxxE1KB3Ph6b8KGYjT/Pn ORwIHmy0FEQFCZRG5yldJnEqD6ezaWQIHMJDApAwCthgF8hbEqwEBQARAoWFEgskQWgiChwFDRoD hpQCA3hLQGhxSWABFpQIlAMPT2NoeTIJEBigooavlzJDS0UdHAkBEAivAoSjDklTQAROuBYQn7+/ lBJJS01SUgoJoskWvaECCWUiHEEKtw+8BtegvoWxiYtqSmsLhBblEALn2hLDH3HTAIXYuhfqVeLF TZ8SR3oSULKAQVeAChYi8kJwCUg4BcVkOOiXDgHDACAvXMBQoWQEOw6iahwsMCmdAI8CKoiciUEA gAJ8aBC4xfKlz3QRsVGcoICMJidKOjhgMKCXqKcAJqSMIkwEuw8OHjCQwNVOggJPvqm4ZUJGuw47 lajlA0Sat28xyJZV9APasGEcvknBkU9TjJ1WrTZZE9hHihAAOw== --_006_867F4B6A1672E541A94676D556793ACD0C263BCDD7MOPESMBX01eut_-- From wbeebee@cisco.com Wed Nov 9 07:42:26 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C260221F8C81 for ; Wed, 9 Nov 2011 07:42:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.159 X-Spam-Level: X-Spam-Status: No, score=-3.159 tagged_above=-999 required=5 tests=[AWL=-0.024, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SU3f7NPMLnx7 for ; Wed, 9 Nov 2011 07:42:23 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id E42A021F8B03 for ; Wed, 9 Nov 2011 07:42:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wbeebee@cisco.com; l=3516; q=dns/txt; s=iport; t=1320853343; x=1322062943; h=date:subject:from:to:message-id:in-reply-to:mime-version; bh=QEDFT3DaiQnc4Q1K9vxjubHYVBYu3b1MxInDQcL0cd0=; b=eK7T+9IcDFKQgtQ2cjQE017gzURhAMXTHNlh5MIURvoy/n/Y72qND1MW 2BcxvT7g/VJ3L6IbKe4QNVHRVihm5PZeny2+8i0qOE+SZbygQqb/W3AA9 NXLL5MweyXuGr0k0FAyLVYS9pylTDGqMxNuQ5ld6SqyZdqssbswPFWxzg A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar8FAKOeuk6tJXG//2dsb2JhbABCgk2GeJ9gdwKBBYFyAQEBAwESASpBDQEIBIEZAQEEATSHYJkLAZ8aiX8Eh1sxjBmFPoglhC0 X-IronPort-AV: E=Sophos;i="4.69,484,1315180800"; d="scan'208,217";a="34512540" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-7.cisco.com with ESMTP; 09 Nov 2011 15:42:22 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id pA9FgMsM025982; Wed, 9 Nov 2011 15:42:22 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Nov 2011 09:42:22 -0600 Received: from 161.44.182.196 ([161.44.182.196]) by XMB-RCD-201.cisco.com ([72.163.62.208]) with Microsoft Exchange Server HTTP-DAV ; Wed, 9 Nov 2011 15:42:22 +0000 User-Agent: Microsoft-Entourage/12.31.0.110725 Date: Wed, 09 Nov 2011 10:42:19 -0500 From: Wes Beebee To: Wuyts Carl , "v6ops@ietf.org" Message-ID: Thread-Topic: [v6ops] RFC6204bis-02 Thread-Index: AcyewOvBbq1YdOdiSD66Sp1uaN6CQwANT42D In-Reply-To: <867F4B6A1672E541A94676D556793ACD0C263BCDD7@MOPESMBX01.eu.thmulti.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3403680140_438187" X-OriginalArrivalTime: 09 Nov 2011 15:42:22.0344 (UTC) FILETIME=[2BF3C080:01CC9EF6] Subject: Re: [v6ops] RFC6204bis-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, 09 Nov 2011 15:42:26 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3403680140_438187 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable > 2. WAA-8: If the IPv6 CE router does not acquire global IPv6 > address(es) from either SLAAC or DHCPv6, then it MUST create global IPv6 > address(es) from its delegated prefix(es) and configure those on one of i= ts > internal virtual network interfaces. > =20 > I assume this is describing the situation where the WAN intf does not get= an > IPv6 addr (not via RA, not via dhcpv6 ia_na). In this situation, you wan= t to > configure one from the delegated prefix on =B3a virtual network intf (being > exactly what, loop ?)=B2. If the delegated prefix <>64, I don=B9t see an iss= ue, > however, if the ia_pd prefix length =3D 64, this would mean that only the C= PE > would get an IPv6 address from the ia_pd, and nothing more left to distri= bute > on the LAN OR the only available /64 gets sent to the LAN hosts, but noth= ing > available on the CPE (for remote management). The intent with IA_PD prefix length =3D 64 is that one /128 from the /64 woul= d be configured on the internal interface, and the /64 would be advertised on the LAN for others to get addresses from. If an NS(DAD) for the loopback address is received on the LAN interface, the router would respond with an NA to indicate that the address was already configured on the (internal) interface (a very unlikely event). - Wes --B_3403680140_438187 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [v6ops] RFC6204bis-02 > 2.       WAA-8: &= nbsp;If the IPv6 CE router does not acquire global IPv6
> address(es) from either SLAAC or DHCPv6, then it MUST create global IP= v6
> address(es) from its delegated prefix(es) and configure those on one o= f its
> internal virtual network interfaces.
>  
> I assume this is describing the situation where the WAN intf does not = get an
> IPv6 addr (not via RA, not via dhcpv6 ia_na).  In this situation,= you want to
> configure one from the delegated prefix on “a virtual network in= tf (being
> exactly what, loop ?)”.  If the delegated prefix <>64= , I don’t see an issue,
> however, if the ia_pd prefix length =3D 64, this would mean that only th= e CPE
> would get an IPv6 address from the ia_pd, and nothing more left to dis= tribute
> on the LAN OR the only available /64 gets sent to the LAN hosts, but n= othing
> available on the CPE (for remote management).

The intent with IA_PD prefix length =3D 64 is that one /128 from the /64 woul= d be configured on the internal interface, and the /64 would be advertised o= n the LAN for others to get addresses from.  If an NS(DAD) for the loop= back address is received on the LAN interface, the router would respond with= an NA to indicate that the address was already configured on the (internal)= interface (a very unlikely event).

- Wes --B_3403680140_438187-- From joelja@bogus.com Wed Nov 9 09:40:27 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E66B321F8C46 for ; Wed, 9 Nov 2011 09:40:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.463 X-Spam-Level: X-Spam-Status: No, score=-102.463 tagged_above=-999 required=5 tests=[AWL=0.136, 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 X+ywZ+CugBzK for ; Wed, 9 Nov 2011 09:40:27 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 76F9621F8C34 for ; Wed, 9 Nov 2011 09:40:27 -0800 (PST) Received: from Zorch.local (host-64-47-136-190.masergy.com [64.47.136.190]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id pA9HeQIH045777 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 9 Nov 2011 17:40:26 GMT (envelope-from joelja@bogus.com) Message-ID: <4EBABB05.8070601@bogus.com> Date: Wed, 09 Nov 2011 09:40:21 -0800 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: IPv6 Ops WG , draft-ietf-v6ops-ipv6-discard-prefix@tools.ietf.org 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, 09 Nov 2011 17:40:27 +0000 (UTC) Subject: [v6ops] draft-ietf-v6ops-ipv6-discard-prefix-00 - IANA feeback X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 09 Nov 2011 17:40:28 -0000 FYI we recieved the following feedback from IANA on draft-ietf-v6ops-ipv6-discard-prefix-00, this was requested by the wg chairs during the WGLC. as noted the specical use prefix falls within 2000::/3 the global unicast range. teredo for the record is 2001:0::/32. joel --- 1. This assignment should come from the IANA IPv6 Special Purpose Address Registry and not the IPv6 Address Space registry, as per RFC 4773. 2. Because of the change in registry, the IC section should indicate how to complete the relevant cells in the table: - Assignment (name) - Termination Date (or never) - Purpose - Contact details - Routing scope 3. The IC section currently states that "The prefix should be allocated from ::/3" and as we would be taking it from 2001:0000::/23 that sentence is probably superfluous. If the author takes a shine to a specific /64 from there he could let us know. Otherwise, I propose we just take the numerically lowest /64, which would be immediately after the TEREDO assignment. We could discuss this with the author in case he has operational concerns with that. From shemant@cisco.com Wed Nov 9 11:43:41 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D770011E8090 for ; Wed, 9 Nov 2011 11:43:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.115 X-Spam-Level: X-Spam-Status: No, score=-6.115 tagged_above=-999 required=5 tests=[AWL=0.483, 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 kdT0eGeyLWiK for ; Wed, 9 Nov 2011 11:43:40 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id DF96711E808B for ; Wed, 9 Nov 2011 11:43:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=14063; q=dns/txt; s=iport; t=1320867820; x=1322077420; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=3GUKsEzNCXbth2z/PcKCLtTovy9HX4b3XcY+rXWxR70=; b=TXoITWn0QnpndSD1lNtKeHCfI0Uo9kN/sxoq4JZ3cYE6D/BWYwtwSqfN zTIGMf7UHLqSwfVsVSv7LMOPKKMIdt6EwkNd50PUlVEKIINE1oqnokKbj 3ZVEdNKCXxv2JckENRt+FSGKZTe3ELOk/q9cB54P8UccAMvZ/hqXsmOGF E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArsAAHbXuk6tJV2d/2dsb2JhbABDgk2XW498gQWBcgEBAQQSAQkRA1kCAQgRBAEBCwYXAQYBRQkIAQEEARIIGqBVAZ8giRxjBIgMkVeMUw X-IronPort-AV: E=Sophos;i="4.69,484,1315180800"; d="scan'208,217";a="34576624" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP; 09 Nov 2011 19:43:39 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id pA9JhdFS025070; Wed, 9 Nov 2011 19:43:39 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Nov 2011 13:43:38 -0600 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC9F17.E09A6E3E" Date: Wed, 9 Nov 2011 13:43:38 -0600 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C303494128@XMB-RCD-109.cisco.com> In-Reply-To: <867F4B6A1672E541A94676D556793ACD0C263BCDD7@MOPESMBX01.eu.thmulti.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] RFC6204bis-02 Thread-Index: AcyewOvBbq1YdOdiSD66Sp1uaN6CQwAVZjrQ References: <867F4B6A1672E541A94676D556793ACD0C263BCDD7@MOPESMBX01.eu.thmulti.com> From: "Hemant Singh (shemant)" To: "Wuyts Carl" , X-OriginalArrivalTime: 09 Nov 2011 19:43:38.0990 (UTC) FILETIME=[E0B4A0E0:01CC9F17] Subject: Re: [v6ops] RFC6204bis-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, 09 Nov 2011 19:43:42 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC9F17.E09A6E3E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Wuyts Carl Sent: Wednesday, November 09, 2011 4:21 AM To: v6ops@ietf.org Subject: [v6ops] RFC6204bis-02 =20 =20 >1. WPD-5: If the IPv6 CE router initiates DHCPv6 before receiving a Router Advertisement, it MUST also request an IA_NA option in DHCPv6. =20 >Our opinion on this one is that they should not be linked, so either allow for configuration to listen to RA or not, and act upon it, or just deal with the result, just request both, independent from RA received or >not. Suppose you're on a ptp link, you might not even want to see RA, hence you should not tie yourself up to it, unless you want to make things more complex and start defining exceptions. =20 The attempt is to not link at all. Note IA_PD acquisition is a router to router protocol as per RFC 3633 and thus an RA has got nothing to do with the CE router WAN interface kicking off DHCPv6 for the IA_PD. Since the IA_PD is being asked of, it was a optimization to also ask for the IA_NA. We have a similar optimization in=20 =20 [W-5: DHCPv6 address assignment (IA_NA) and DHCPv6 prefix delegation (IA_PD) SHOULD be done as a single DHCPv6 session.] =20 That said, cable broadband standards body contacted us to change WPD-4 to "by Default, the IPv6 CE router MUST initiate DHCPv6 prefix delegation when either the M and or the O flags are set to 1 in a received Router Advertisement message." With the new text the cable standards body can write in their profile specific document that their eRouter cable modem MUST only initiate DHCPv6 PD on seeing the RA. If the WPD-4 original text was not changed, the cable profile document would be in contradiction with RFC 6204. However, once the cable profile is all settled, none of the old behavior for the CE router changes. With the new WPD-4 text, the CE router is still legal to initiate DHCPv6 without seeing an RA or if an RA is seen, the CE doesn't care what the M and the O bits are. =20 =20 Thanks, =20 Hemant =20 ------_=_NextPart_001_01CC9F17.E09A6E3E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

From:= = v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of = Wuyts Carl
Sent: Wednesday, November 09, 2011 4:21 = AM
To: v6ops@ietf.org
Subject: [v6ops] = RFC6204bis-02

 

 =

>1. WPD-5: = ; If the IPv6 CE router initiates DHCPv6 before receiving a Router = Advertisement, it MUST also request an IA_NA option in = DHCPv6.

 

>Our = opinion on this one is that they should not be linked, so either = allow for configuration to listen to RA or not, and act upon it, or just = deal with the result, just request both, independent from RA received or = >not.  Suppose you’re = on a ptp link, you might not even want to see RA, hence you should not = tie yourself up to it, unless you want to make things more complex and = start defining exceptions.

 

The attempt is to not link at all.   Note = IA_PD acquisition is a router to router protocol as per RFC 3633 and = thus an RA has got nothing to do with the CE router WAN interface = kicking off DHCPv6 for the IA_PD.   Since the IA_PD is being = asked of, it was a optimization to also ask for the IA_NA.  =  We have a similar optimization in

 

[W-5:  DHCPv6 = address assignment (IA_NA) and DHCPv6 prefix = delegation

         (IA_PD) SHOULD be = done as a single DHCPv6 session.]

 

That said, = cable broadband standards body contacted us to change WPD-4 to “by = Default, the IPv6 CE router MUST initiate DHCPv6 prefix delegation when = either the M and or the O flags are set to 1 in a received Router = Advertisement message.”  With the new text the cable = standards body can write in their profile specific document that their = eRouter cable modem MUST only initiate DHCPv6 PD on seeing the RA.  = If the WPD-4 original text was not changed, the cable profile document = would be in contradiction with RFC 6204.   However, once the = cable profile is all settled, none of the old behavior for the CE router = changes.   With the new WPD-4 text, the CE router is still = legal to initiate DHCPv6 without seeing an RA or if an RA is seen, the = CE doesn’t care what the M and the O bits are.   =

 

Thanks,

 

Hemant

 

------_=_NextPart_001_01CC9F17.E09A6E3E-- From lorenzo@google.com Wed Nov 9 12:37:44 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F5D311E80B0 for ; Wed, 9 Nov 2011 12:37:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[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 2h3IYbZ4Mw3U for ; Wed, 9 Nov 2011 12:37:43 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7A2AC11E80AF for ; Wed, 9 Nov 2011 12:37:43 -0800 (PST) Received: by ggnr4 with SMTP id r4so646317ggn.31 for ; Wed, 09 Nov 2011 12:37:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=psWWpLOqchKaVXLAjP7JfsoIOMyZj5OzVfgDzZ/q4BU=; b=Tka3SxnFUBmb429p0vGE83QbFDWnF/CR63U89u4RaVhAK3cX5ynzxd9XR7ksooFCUW OTI3zs/svAk6yZv5eGgA== Received: by 10.101.139.15 with SMTP id r15mr1876767ann.161.1320871059344; Wed, 09 Nov 2011 12:37:39 -0800 (PST) Received: by 10.101.139.15 with SMTP id r15mr1876755ann.161.1320871059148; Wed, 09 Nov 2011 12:37:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.202.14 with HTTP; Wed, 9 Nov 2011 12:37:18 -0800 (PST) In-Reply-To: <867F4B6A1672E541A94676D556793ACD0C263BCDD7@MOPESMBX01.eu.thmulti.com> References: <867F4B6A1672E541A94676D556793ACD0C263BCDD7@MOPESMBX01.eu.thmulti.com> From: Lorenzo Colitti Date: Wed, 9 Nov 2011 12:37:18 -0800 Message-ID: To: Wuyts Carl Content-Type: multipart/alternative; boundary=0016e68e7f8b4650b504b15342ef X-System-Of-Record: true Cc: "v6ops@ietf.org" Subject: Re: [v6ops] RFC6204bis-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, 09 Nov 2011 20:37:44 -0000 --0016e68e7f8b4650b504b15342ef Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Wed, Nov 9, 2011 at 01:21, Wuyts Carl wrote= : > * > 2. ****WAA-8: If the IPv6 CE router does not acquire global IPv6 > address(es) from either SLAAC or DHCPv6, then it MUST create global IPv6 > address(es) from its delegated prefix(es) and configure those on one of i= ts > internal virtual network interfaces.* > > ** ** > > I assume this is describing the situation where the WAN intf does not get > an IPv6 addr (not via RA, not via dhcpv6 ia_na). In this situation, you > want to configure one from the delegated prefix on =93a virtual network i= ntf > (being exactly what, loop ?)=94. If the delegated prefix <>64, I don=92t= see > an issue, however, if the ia_pd prefix length =3D 64, this would mean tha= t > only the CPE would get an IPv6 address from the ia_pd, and nothing more > left to distribute on the LAN OR the only available /64 gets sent to the > LAN hosts, but nothing available on the CPE (for remote management). > No, wait. The CE router gets at least one /64 from PD, possibly more. If it doesn't have an IPv6 address (from RA, or from DHCPv6 NA) on the WAN interface, it picks ONE global address from the PD as its global IPv6 address. Since the CE router is a router that's connected to at least one /64 in the PD, it can just pick an autoconf address from one of those /64s, assign it to a loopback, and do proxy ND for it on the interface that "owns" that /64. DAD will take care of it. No? --0016e68e7f8b4650b504b15342ef Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Wed, Nov 9, 2011 at 01:21, Wuyts Carl <Carl.Wuyts@tec= hnicolor.com> wrote:


2.=A0=A0=A0=A0=A0=A0 <= /span>WAA-8:=A0 If the IP= v6 CE router does not acquire global IPv6 address(es) from either SLAAC or = DHCPv6, then it MUST create global IPv6 address(es) from its delegated pref= ix(es) and configure those on one of its internal virtual network interface= s.

=A0

I assume this is describing the situation where th= e WAN intf does not get an IPv6 addr (not via RA, not via dhcpv6 ia_na).=A0= In this situation, you want to configure one from the delegated prefix on = =93a virtual network intf (being exactly what, loop ?)=94.=A0 If the delega= ted prefix <>64, I don=92t see an issue, however, if the ia_pd prefix= length =3D 64, this would mean that only the CPE would get an IPv6 address= from the ia_pd, and nothing more left to distribute on the LAN OR the only= available /64 gets sent to the LAN hosts, but nothing available on the CPE= (for remote management).

No, wait. The CE router gets at least one /64= from PD, possibly more. If it doesn't have an IPv6 address (from RA, o= r from DHCPv6 NA) on the WAN interface, it picks ONE global address from th= e PD as its global IPv6 address. Since the CE router is a router that's= connected to at least one /64 in the PD, it can just pick an autoconf addr= ess from one of those /64s, assign it to a loopback, and do proxy ND for it= on the interface that "owns" that /64. DAD will take care of it.= No?
--0016e68e7f8b4650b504b15342ef-- From lorenzo@google.com Wed Nov 9 12:56:47 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCCAA21F84D3 for ; Wed, 9 Nov 2011 12:56:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[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 XJ-5tSfjLT0M for ; Wed, 9 Nov 2011 12:56:47 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id B9A9121F84CE for ; Wed, 9 Nov 2011 12:56:40 -0800 (PST) Received: by yenl7 with SMTP id l7so1362257yen.31 for ; Wed, 09 Nov 2011 12:56:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=60ZLT+efeSJffeuCuCVYnTHwdnWw5iRm3fdf0WWAK9k=; b=bxDuUrkeC4KQ9suFSsfJeyyMG3cv5Qg8f9ceQIDh2OYVRf9V+z6qdl/E4uc8hPRIWf CSuE7KrAijSwzmzY9wmw== Received: by 10.101.194.4 with SMTP id w4mr1993554anp.51.1320872200373; Wed, 09 Nov 2011 12:56:40 -0800 (PST) Received: by 10.101.194.4 with SMTP id w4mr1993543anp.51.1320872200129; Wed, 09 Nov 2011 12:56:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.202.14 with HTTP; Wed, 9 Nov 2011 12:56:19 -0800 (PST) In-Reply-To: <867F4B6A1672E541A94676D556793ACD0C263BCDD7@MOPESMBX01.eu.thmulti.com> References: <867F4B6A1672E541A94676D556793ACD0C263BCDD7@MOPESMBX01.eu.thmulti.com> From: Lorenzo Colitti Date: Wed, 9 Nov 2011 12:56:19 -0800 Message-ID: To: Wuyts Carl Content-Type: multipart/alternative; boundary=00504501553d484e4404b1538640 X-System-Of-Record: true Cc: "v6ops@ietf.org" Subject: Re: [v6ops] RFC6204bis-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, 09 Nov 2011 20:56:47 -0000 --00504501553d484e4404b1538640 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Wed, Nov 9, 2011 at 01:21, Wuyts Carl wrote= : > *Our opinion on this one is that they should not be linked*, so either > allow for configuration to listen to RA or not, and act upon it, or just > deal with the result, just request both, independent from RA received or > not. Suppose you=92re on a ptp link, you might not even want to see RA, > hence you should not tie yourself up to it, unless you want to make thing= s > more complex and start defining exceptions. > Having the CE router ask for DHCPv6 regardless of any RA it receives or does not receive does not allow operators to control their IPv6 rollouts. The problem is that in steady state, DHCPv6 will send one request every 2 minutes. If those requests are not answered, in a 10M user network with 5% of CPEs IPv6-capable, that means upwards of 4000 requests per second. That 110x the load of steady-state IPv4, where, say, 100% of CPEs will get a DHCPv4 lease and not ask again for, say, 3 days. You can't expect an operator to increase DHCPv6 capacity by over 100x just to roll out IPv6. In order to roll out IPv6 gradually, the operator needs to signal to the CE router that "IPv6 is available". The RA is the canonical way to do that (that's what DHCPv6 was designed to listen to). Unfortunately, making RA independent from DHCPv6 makes the CE router ignore the signal. This can cause real scaling issues. We (where "we" =3D=3D the organizers of the next World IPv6 event) are work= ing with retail CE manufacturers who appear to be willing to enable IPv6 by default in a substantial portion of their products if the event happens. We're also working with a number of large ISPs, who appear to be willing to bring IPv6 to single-digit percentages of their users during 1H2012, which basically, given CPE churn rate, means enabling the majority of the access network. The resulting potential effect on those networks' DHCPv6 servers (i.e., "burn them down to the ground with a > 100x increase in load") could cause those networks to slow down those rollouts considerably or not start them at all until DHCPv6 servers can be forklifted. You might think that the obvious solution to this is to have the CE router ask "less frequently", but that also means that the CE router will find out "less frequently" when connectivity has come back after an outage or prolonged disconnection (since disconnections may not always correspond to link flaps). This makes IPv6 less reliable than IPv4, which is not what anyone wants. --00504501553d484e4404b1538640 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Wed, Nov 9, 2011 at 01:21, Wuyts Carl <Carl.Wuyts@tec= hnicolor.com> wrote:

Our opinion on this one is that they should not be linked, so ei= ther allow for configuration to listen to RA or not, and act upon it, or ju= st deal with the result, just request both, independent from RA received or= not.=A0 Suppose you=92re on a ptp link, you might not even want to see RA,= hence you should not tie yourself up to it, unless you want to make things= more complex and start defining exceptions.


Having the CE router ask for D= HCPv6 regardless of any RA it receives or does not receive does not allow o= perators to control their IPv6 rollouts.

The probl= em is that in steady state, DHCPv6 will send one request every 2 minutes. I= f those requests are not answered, in a 10M user network with 5% of CPEs IP= v6-capable, that means upwards of 4000 requests per second. That 110x the l= oad of steady-state IPv4, where, say, 100% of CPEs will get a DHCPv4 lease = and not ask again for, say, 3 days. You can't expect an operator to inc= rease DHCPv6 capacity by over 100x just to roll out IPv6.

In order to roll out IPv6 gradually, the operator needs= to signal to the CE router that "IPv6 is available". The RA is t= he canonical way to do that (that's what DHCPv6 was designed to listen = to). Unfortunately, making RA independent from DHCPv6 makes the CE router i= gnore the signal.

This can cause real scaling issues.

=
We (where "we" =3D=3D the organizers of the next World= IPv6 event) are working with retail CE manufacturers who appear to be will= ing to enable IPv6 by default in a substantial portion of their products if= the event happens. We're also working with a number of large ISPs, who= appear to be willing to bring IPv6 to single-digit percentages of their us= ers during 1H2012, which basically, given CPE churn rate, means enabling th= e majority of the access network.

The resulting potential effect on those networks' D= HCPv6 servers (i.e., "burn them down to the ground with a > 100x in= crease in load") could cause those networks to slow down those rollout= s considerably or not start them at all until DHCPv6 servers can be forklif= ted.

You might think that the obvious solution to this= is to have the CE router ask "less frequently", but that also me= ans that the CE router will find out "less frequently" when conne= ctivity has come back=A0after an outage or prolonged disconnection=A0(since= disconnections may not always correspond to link flaps). This makes IPv6 l= ess reliable than IPv4, which is not what anyone wants.
--00504501553d484e4404b1538640-- From wbeebee@cisco.com Wed Nov 9 13:03:33 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0200911E8093 for ; Wed, 9 Nov 2011 13:03:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.853 X-Spam-Level: X-Spam-Status: No, score=-3.853 tagged_above=-999 required=5 tests=[AWL=0.679, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wGPVzD27Gbcg for ; Wed, 9 Nov 2011 13:03:32 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1D7C321F84F8 for ; Wed, 9 Nov 2011 13:03:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wbeebee@cisco.com; l=802; q=dns/txt; s=iport; t=1320872612; x=1322082212; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=/JGAOK7uARJxZcpuQ5JGDfE0kxh8E/F6kL7vB1XiLDE=; b=KY8bSjH988MQOnC4qmUDKhVLzuVlc0hCuQsQyi3sGwgBWf02FjqiY3mF /BkvP09465Fq0/JL/C6aqtlIjPZ7qSS06oxxNvxtmJyUQ7yRTrjuAjn0p AHaTqc80r+hsmwxvsur6mTDZ0kt3bFM6XBvDYRXN2VkDP4dIlBSWhVsSv k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As4FAHbpuk6tJV2Z/2dsb2JhbABDiUWgXQKBBYFyAQEBAwESAScCATwFDQEIgR0BAQQBDSeHYJhoAZ8aiX8EiAyMGYU+iCWELQ X-IronPort-AV: E=Sophos;i="4.69,485,1315180800"; d="scan'208";a="34601535" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 09 Nov 2011 21:03:30 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pA9L3U5u027172; Wed, 9 Nov 2011 21:03:30 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Nov 2011 15:03:30 -0600 Received: from 161.44.175.128 ([161.44.175.128]) by XMB-RCD-201.cisco.com ([72.163.62.208]) with Microsoft Exchange Server HTTP-DAV ; Wed, 9 Nov 2011 21:03:30 +0000 User-Agent: Microsoft-Entourage/12.31.0.110725 Date: Wed, 09 Nov 2011 16:03:28 -0500 From: Wes Beebee To: Lorenzo Colitti , Wuyts Carl Message-ID: Thread-Topic: [v6ops] RFC6204bis-02 Thread-Index: AcyfIwctWLVEdMG1Wk2EJh6dOMoGGA== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 09 Nov 2011 21:03:30.0733 (UTC) FILETIME=[08CE95D0:01CC9F23] Cc: "v6ops@ietf.org" Subject: Re: [v6ops] RFC6204bis-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, 09 Nov 2011 21:03:33 -0000 Lorenzo - > The resulting potential effect on those networks' DHCPv6 servers (i.e., "burn > them down to the ground with a > 100x increase in load") could cause those > networks to slow down those rollouts considerably or not start them at all > until DHCPv6 servers can be forklifted. No one is suggesting that we not solve the problem. We are taking issue with HOW you are suggesting to solve the problem. I, for one, believe that the issue is really an access concentrator issue, which routinely manages congestion-control and rate-limits DHCPv6 packets ANYWAY. It has to - to protect the DHCPv6 servers from DoS attacks from untrusted CPE routers. Why not use the mechanisms that are already in place, that require no specific standards effort, to solve this problem? - Wes From shemant@cisco.com Wed Nov 9 13:13:24 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 653CD21F8557 for ; Wed, 9 Nov 2011 13:13:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.123 X-Spam-Level: X-Spam-Status: No, score=-6.123 tagged_above=-999 required=5 tests=[AWL=0.476, 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 vzhujBDxgllp for ; Wed, 9 Nov 2011 13:13:23 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id E808A21F8548 for ; Wed, 9 Nov 2011 13:13:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=1589; q=dns/txt; s=iport; t=1320873200; x=1322082800; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=Zf0AtUYlnwyYSU88TnJJwSiVOUQZemn4Ed/RTzkH93I=; b=GZt3bqMCS4CyyUc1wb7nz0++eVmughYKlPJFUC+SJGJokHTxRKVGGDab Ps/TQxY2WLUe5dFiDBX7o8FQSWvo0pH5R0zKoVapPI7eDuZjtoyZ5cQFS aMO+kMOiI8K+q2c39J800ErCYmh5tP9UHehISgt//mng67X/5PdJias/a 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArsAAEfsuk6tJV2b/2dsb2JhbABDmiiPfIEFgXIBAQEEEgEdCj8MBAIBCBEEAQELBhcBBgFFCQgBAQQBEggaoFEBnxqJHGMEiAyRV4xT X-IronPort-AV: E=Sophos;i="4.69,485,1315180800"; d="scan'208";a="34605585" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 09 Nov 2011 21:13:19 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pA9LDUB1022819; Wed, 9 Nov 2011 21:13:30 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Nov 2011 15:13:19 -0600 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Nov 2011 15:13:18 -0600 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3034941C5@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] RFC6204bis-02 Thread-Index: AcyfIwctWLVEdMG1Wk2EJh6dOMoGGAAAK7yQ References: From: "Hemant Singh (shemant)" To: "Wes Beebee (wbeebee)" , "Lorenzo Colitti" , "Wuyts Carl" X-OriginalArrivalTime: 09 Nov 2011 21:13:19.0620 (UTC) FILETIME=[67CF9C40:01CC9F24] Cc: v6ops@ietf.org Subject: Re: [v6ops] RFC6204bis-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, 09 Nov 2011 21:13:24 -0000 -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Wes Beebee (wbeebee) Sent: Wednesday, November 09, 2011 4:03 PM To: Lorenzo Colitti; Wuyts Carl Cc: v6ops@ietf.org Subject: Re: [v6ops] RFC6204bis-02 >No one is suggesting that we not solve the problem. We are taking issue >with HOW you are suggesting to solve the problem. I, for one, believe that >the issue is really an access concentrator issue, which routinely manages >congestion-control and rate-limits DHCPv6 packets ANYWAY. It has to - to >protect the DHCPv6 servers from DoS attacks from untrusted CPE routers. >Why not use the mechanisms that are already in place, that require no >specific standards effort, to solve this problem? +1. =20 I do acknowledge that problem of a storm at the DHCPv6 server in an SP network where the SP is not ready to server DHCPv6. However, changing rfc6204bis or any other IETF document to solve the storm does not make sense. Folks are suggesting to use the M and the O bits in the RA to signal DHCPv6 start/stop when such suggestions have thrashed for multiple years in the IETF 6man and the DHC WG's with no change to the document in this regard. I have personally emailed to the SP mitigation configuration at the access concentrator and so has Ole and others. If the SP is not serving DHCPv6, why does the SP even have a access concentrator configuration to relay DHCPv6 client traffic to a server? The access concentrator DHCPv6 relay agent operation can be shut down as well. =20 Hemant From lorenzo@google.com Wed Nov 9 14:22:54 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 652C411E8080 for ; Wed, 9 Nov 2011 14:22:54 -0800 (PST) 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.458, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, 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 JyBNSBMJqg78 for ; Wed, 9 Nov 2011 14:22:53 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id A855B21F84A0 for ; Wed, 9 Nov 2011 14:22:53 -0800 (PST) Received: by ggnr4 with SMTP id r4so749041ggn.31 for ; Wed, 09 Nov 2011 14:22:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=+cNWcSULcDYqCzuiFjM+KF3OQ7MthrjiotvQYfg/SFY=; b=FaP2qA+vjsTEdCegV17gIIpD15/u24m61GzNJjVtY0zGJ3k+sj0pdqS3cCah/xrDT+ 0xOoydjOYCPxzPVacYYw== Received: by 10.101.194.4 with SMTP id w4mr2127926anp.51.1320877373262; Wed, 09 Nov 2011 14:22:53 -0800 (PST) Received: by 10.101.194.4 with SMTP id w4mr2127919anp.51.1320877373115; Wed, 09 Nov 2011 14:22:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.202.14 with HTTP; Wed, 9 Nov 2011 14:22:32 -0800 (PST) In-Reply-To: References: From: Lorenzo Colitti Date: Wed, 9 Nov 2011 14:22:32 -0800 Message-ID: To: Wes Beebee Content-Type: multipart/alternative; boundary=00504501553d9dce3304b154ba45 X-System-Of-Record: true Cc: "v6ops@ietf.org" Subject: Re: [v6ops] RFC6204bis-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, 09 Nov 2011 22:22:54 -0000 --00504501553d9dce3304b154ba45 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Nov 9, 2011 at 13:03, Wes Beebee wrote: > > The resulting potential effect on those networks' DHCPv6 servers (i.e., > "burn > > them down to the ground with a > 100x increase in load") could cause > those > > networks to slow down those rollouts considerably or not start them at > all > > until DHCPv6 servers can be forklifted. > > No one is suggesting that we not solve the problem. We are taking issue > with HOW you are suggesting to solve the problem. I didn't make any suggestions in this thread. That discussion is being carried out elsewhere with a more limited group of people, because we don't necessarily want to spam the whole of v6ops with it :-) All I did was give one important reason why it's not automatically a good idea to make RS and DHCPv6 PD independent. Another good reason, which I just realize I forgot to mention, is that from the perspective of a CE router, having a DHCPv6 PD and no default route is pointless, because it can't go anywhere anyway. It's also harmful to the hosts behind it, because even if the CE router is implemented correctly and does not give the hosts a default route, it will still be giving them global IPv6 addresses, which will double their DNS lookup latency (because once they have a global IPv6 address, they will start asking for AAAA records). I, for one, believe that the issue is really an access concentrator issue, > which routinely manages congestion-control and rate-limits DHCPv6 packets > ANYWAY. It has to - to > protect the DHCPv6 servers from DoS attacks from untrusted CPE routers. > > Why not use the mechanisms that are already in place, that require no > specific standards effort, to solve this problem? Because every time you rate-limit a DHCP request, that could be a user that can't get online. If you're hitting rate-limits all the time, you're denying service to real users all the time. The problem here is not that one particular CE router asks for DHCP PD too often - it may be fine for one CE router to make 5 DHCPv6 requests in one minute, as long as it doesn't happen all the time. It's that when when you add up millions of CE routers asking every 2 minutes, *all the time* the aggregate load becomes very large. --00504501553d9dce3304b154ba45 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Nov 9, 2011 at 13:03, Wes Beebee <wbeeb= ee@cisco.com> wrote:
> The resulting potential effect on those networks' DHCPv6 serv= ers (i.e., "burn
> them down to the ground with a > 100x increase in load") could= cause those
> networks to slow down those rollouts considerably or not start them at= all
> until DHCPv6 servers can be forklifted.

No one is suggesting that we not solve the problem. =A0We are taking = issue
with HOW you are suggesting to solve the problem.

I didn't make any suggestions in this thread. That discussion is= being carried out elsewhere with a more limited group of people, because w= e don't necessarily want to spam the whole of v6ops with it :-)

All I did was give one important reason why it's no= t automatically a good idea to make RS and DHCPv6 PD independent.

Another good reason, which I just realize I forgot to mention, is that= from the perspective of a CE router, having a DHCPv6 PD and no default rou= te is pointless, because it can't go anywhere anyway. It's also har= mful to the hosts behind it, because even if the CE router is implemented c= orrectly and does not give the hosts a default route, it will still be givi= ng them global IPv6 addresses, which will double their DNS lookup latency (= because once they have a global IPv6 address, they will start asking for AA= AA records).

I, for one, believe that=A0th= e issue is really an access concentrator issue, which routinely manages=A0c= ongestion-control and rate-limits DHCPv6 packets ANYWAY. =A0It has to - to<= br> protect the DHCPv6 servers from DoS attacks from untrusted CPE routers.

Why not use the mechanisms that are already in place, that require no
specific standards effort, to solve this problem?

Because every time y= ou rate-limit a DHCP request, that could be a user that can't get onlin= e. If you're hitting rate-limits all the time, you're denying servi= ce to real users all the time.

= The problem here is not tha= t one particular CE router asks for DHCP PD too often - it may be fine for = one CE router to make 5 DHCPv6 requests in one minute, as long as it doesn&= #39;t happen all the time. It's that when when you add up millions of C= E routers asking every 2 minutes, *all the time* the aggregate load becomes= very large.
--00504501553d9dce3304b154ba45-- From fred@cisco.com Wed Nov 9 15:10:14 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68B5F11E8087 for ; Wed, 9 Nov 2011 15:10:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.482 X-Spam-Level: X-Spam-Status: No, score=-107.482 tagged_above=-999 required=5 tests=[AWL=-1.483, 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 r82hNARP-bvL for ; Wed, 9 Nov 2011 15:10:13 -0800 (PST) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 9965D21F845A for ; Wed, 9 Nov 2011 15:10:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2235; q=dns/txt; s=iport; t=1320880212; x=1322089812; h=from:subject:date:references:to:message-id:mime-version: content-transfer-encoding; bh=pqeQEGE6vfqCCLTo97AKaSg7GNPZBFu0lVieHLYh8AQ=; b=YdWMkCKngzOqJkWdIdvfxsLJUOCxFJJSwKfc8UjKmOf6eApws3k3G4jt a1cwK4Kga1DOOUnxBrXsmjbM7lj/qQQfx7BEnQNEL0jQEtp7WwLh/yjt/ Q0C1ALr7LB0wZB9u+8uo2lSTUKnhSeVPfpLVr1OfX9FtZAexkYcLtz42V c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAEQHu05Io8UQ/2dsb2JhbAAqFwOqJIEFgXIBAQEDARIBJ0QLHAMBAgEnB0YHAggGExQOh2AII5hLAZ8PhmiCNGMEiAqIS4NQhTWMSl8 X-IronPort-AV: E=Sophos;i="4.69,486,1315180800"; d="scan'208";a="2754481" Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-3.cisco.com with ESMTP; 09 Nov 2011 23:09:53 +0000 Received: from Freds-Computer.local (hkidc-vpn-client-235-216.cisco.com [10.75.235.216]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pA9N9qkR007363 for ; Wed, 9 Nov 2011 23:09:52 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Thu, 10 Nov 2011 07:09:52 +0800 X-PGP-Universal: processed; by Freds-Computer.local on Thu, 10 Nov 2011 07:09:52 +0800 From: Fred Baker Date: Thu, 10 Nov 2011 07:09:40 +0800 References: To: "v6ops@ietf.org WG" Message-Id: Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: [v6ops] Fwd: Comcast IPv6 Update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 09 Nov 2011 23:10:14 -0000 FYI. As other companies deploy residential IPv6 services, it would be = similarly appropriate for them to state the fact and point to their = public statements about them. Begin forwarded message: > From: "Brzozowski, John" > Date: November 10, 2011 12:34:05 AM GMT+08:00 > To: Fred Baker , Joel Jaeggli > Subject: FW: Comcast IPv6 Update >=20 > FYI - in case you wish to forward to the v6ops community. >=20 > John > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > John Jason Brzozowski > Comcast Cable > e) mailto:john_brzozowski@cable.comcast.com > o) 609-377-6594 > m) 484-962-0060 > w) http://www.comcast6.net > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 >=20 >=20 >=20 > On 11/9/11 11:32 AM, "John Jason Brzozowski" > wrote: >=20 >> Update from http://www.comcast6.net >> IPv6 Pilot Market Deployment Begins >> Wednesday, November 9, 2011 >> =09 >> Comcast has started our first pilot market deployment of IPv6 in >> limited areas of California and Colorado. This first phase supports >> directly connected CPE, where a single computer is directly connected = to >> a cable device. A subsequent phase will support home gateway devices. >> To learn more, check out FAQs on the pilot market deployment >> and the announcement >> and technical >> details = >> on our blog.=20 >>=20 >> John >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> John Jason Brzozowski >> Comcast Cable >> e) mailto:john_brzozowski@cable.comcast.com >> o) 609-377-6594 >> m) 484-962-0060 >> w) http://www.comcast6.net >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 >>=20 >>=20 >=20 From phdgang@gmail.com Wed Nov 9 18:42:31 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A605A21F85B1 for ; Wed, 9 Nov 2011 18:42:31 -0800 (PST) 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_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 qJdY5IGO+c3f for ; Wed, 9 Nov 2011 18:42:31 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id C0B5621F8591 for ; Wed, 9 Nov 2011 18:42:30 -0800 (PST) Received: by wyf28 with SMTP id 28so409619wyf.31 for ; Wed, 09 Nov 2011 18:42:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5e+juvyBw7fC8sIlJ/VwWHpbEbYcHDUxj//tETU2/xY=; b=gVgViL91VZM8WlF4XFPMQZ5vlR+NRUj6FmW+1O/nFytnsibQTQMX/GO37LOvENBYvt AjwyhQmWmv5ly3/FmRE0RM55/0WFwoSLLin5Q5mThC9RhwoqbxRJqvdkCdiMtc6qwH3J DOTtInC3AGcryRUieCTDGMy9yJJ3n8YZJ8iC0= MIME-Version: 1.0 Received: by 10.180.4.167 with SMTP id l7mr2250126wil.51.1320892950009; Wed, 09 Nov 2011 18:42:30 -0800 (PST) Received: by 10.180.102.8 with HTTP; Wed, 9 Nov 2011 18:42:29 -0800 (PST) In-Reply-To: <031801cc9e77$05aaacb0$11000610$@com> References: <031801cc9e77$05aaacb0$11000610$@com> Date: Thu, 10 Nov 2011 10:42:29 +0800 Message-ID: From: GangChen To: Dan Wing Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops Subject: Re: [v6ops] NAT64 Operational Considerations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 10 Nov 2011 02:42:31 -0000 Hello Dan Thanks for the comments. > Are there NAT64 *specific* issues of logging, user tracking, and DoS > attacks that should be included in a document like > draft-chen-v6ops-nat64-cpe? The draft has proposal a category regarding to NAT64 deployment position. If we are talking about specific consideration for NAT64, it may depend on the specific use cases. For example, logging has different requirements whether NAT64 located on CGN side or CE side. For example, NAT64 box may go beyond the operator control in CE case. Operator may need to take extra consideration for logging. I think that is only a tentative thought. Sorry about that. But I would like to concrete the cases in next version. Many thanks Gang 2011/11/9, Dan Wing : >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf >> Of Eleven Fu(Yu) >> Sent: Monday, November 07, 2011 2:02 AM >> To: GangChen; v6ops >> Subject: Re: [v6ops] NAT64 Operational Considerations >> >> Hi Gang, >> >> I have read draft-chen-v6ops-nat64-cpe, please see come comments below, >> >> The draft is structured by different deploy positions of NAT64 as >> different modes. It describes operational process for each mode. But I >> think as a informational guide for readers, some more considerations >> need to be described for each mode in more detail, such as logging >> problem, ALG issues, DNS, load balancing etc. >> >> For section 4, some security considerations also need to be involved, >> such as user tracking, Dos attack etc. > > Logging, user tracking, and DoS attacks are a problem with all IPv4 > address sharing mechanisms -- not just NAT64. Is > http://tools.ietf.org/html/rfc6269 inadequate at describing > the issues? > > Are there NAT64 *specific* issues of logging, user tracking, and DoS > attacks that should be included in a document like > draft-chen-v6ops-nat64-cpe? > > -d > > > >> Cheers >> >> Yu >> >> >> >> >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf >> Of GangChen >> Sent: Thursday, November 03, 2011 10:00 AM >> To: v6ops >> Subject: [v6ops] NAT64 Operational Considerations >> >> Dear all, >> >> I have just submitted the draft for NAT64 operational consideration. >> The intention is to provide comprehensive considerations for NAT64 >> deployment. >> The detailed information is listed at below >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> Title : NAT64 Operational Considerations >> Author(s) : Gang Chen >> Filename : draft-chen-v6ops-nat64-cpe-03.txt >> Pages : 8 >> Date : 2011-10-31 >> >> The document has summarized NAT64 usages on different modes, in which >> NAT64 may serve for a large-scale network or would give enterprise or >> residential service opportunities to be accessed by IPv6 remote >> subscribers. The document has described different operations for >> each usage and proposed operational considerations for each >> particular NAT64-mode. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-chen-v6ops-nat64-cpe-03.txt >> >> Many thanks >> >> Gang >> _______________________________________________ >> 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 dwing@cisco.com Wed Nov 9 19:20:11 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A135F21F84DD for ; Wed, 9 Nov 2011 19:20:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.364 X-Spam-Level: X-Spam-Status: No, score=-105.364 tagged_above=-999 required=5 tests=[AWL=0.635, 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 CRSvKyykkqtH for ; Wed, 9 Nov 2011 19:20:10 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id DBDB521F84D1 for ; Wed, 9 Nov 2011 19:20:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=4406; q=dns/txt; s=iport; t=1320895210; x=1322104810; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=oHQtZJB/4pv8wIuGwqBSpjhQvumo/6phiQaIKnRJk5E=; b=ZY5qfwojrolR+g3sSZNrlO5PnJGHxAEuEkBFuH8foZu38NKmtpgCyn+Y xKQmlL+qFBMzGM+f2VjexWPORxKkisF4F7NXH0FZY2QYRROznyd6EXdSm D3WpSKcqtJ7w0toqw6KqsRkJG87tFzXjxmVBfqUjh9YF7/3Trxj06WGBP A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au4BAORBu06rRDoH/2dsb2JhbABEggOYJ4FrjhGBBYFyAQEBAwEBAQEFCgEXEDQLBQcBAwIJDwIEAQEoBxkIBhUKCQgBAQQTCQIXh2AImQoBnwWJfwSIDJZdh08 X-IronPort-AV: E=Sophos;i="4.69,486,1315180800"; d="scan'208";a="11789507" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 10 Nov 2011 03:20:10 +0000 Received: from dwingWS ([10.32.240.194]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pAA3KAb4029256; Thu, 10 Nov 2011 03:20:10 GMT From: "Dan Wing" To: "'GangChen'" References: <031801cc9e77$05aaacb0$11000610$@com> In-Reply-To: Date: Wed, 9 Nov 2011 19:20:09 -0800 Message-ID: <07f001cc9f57$a72c2100$f5846300$@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: AcyfUmUlwPiVUp7IQCGX/WO9bfyF6wABLKCw Content-Language: en-us Cc: 'v6ops' Subject: Re: [v6ops] NAT64 Operational Considerations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 10 Nov 2011 03:20:11 -0000 > -----Original Message----- > From: GangChen [mailto:phdgang@gmail.com] > Sent: Wednesday, November 09, 2011 6:42 PM > To: Dan Wing > Cc: Eleven Fu(Yu); v6ops > Subject: Re: [v6ops] NAT64 Operational Considerations > > Hello Dan > > Thanks for the comments. > > > Are there NAT64 *specific* issues of logging, user tracking, and DoS > > attacks that should be included in a document like > > draft-chen-v6ops-nat64-cpe? > > The draft has proposal a category regarding to NAT64 deployment > position. If we are talking about specific consideration for NAT64, it > may depend on the specific use cases. For example, logging has > different requirements whether NAT64 located on CGN side or CE side. Yes, that difference is described in RFC6144, which uses the terminology "Scenario 1: An IPv6 Network to the IPv4 Internet" and "Scenario 3: The IPv6 Internet to an IPv4 Network" for these two cases. > For example, NAT64 box may go beyond the operator control in CE case. Someone operates the NAT64; just not the Internet Service Provider. > Operator may need to take extra consideration for logging. I think > that is only a tentative thought. Sorry about that. But I would like > to concrete the cases in next version. -d > Many thanks > > Gang > > > 2011/11/9, Dan Wing : > >> -----Original Message----- > >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On > Behalf > >> Of Eleven Fu(Yu) > >> Sent: Monday, November 07, 2011 2:02 AM > >> To: GangChen; v6ops > >> Subject: Re: [v6ops] NAT64 Operational Considerations > >> > >> Hi Gang, > >> > >> I have read draft-chen-v6ops-nat64-cpe, please see come comments > below, > >> > >> The draft is structured by different deploy positions of NAT64 as > >> different modes. It describes operational process for each mode. But > I > >> think as a informational guide for readers, some more considerations > >> need to be described for each mode in more detail, such as logging > >> problem, ALG issues, DNS, load balancing etc. > >> > >> For section 4, some security considerations also need to be > involved, > >> such as user tracking, Dos attack etc. > > > > Logging, user tracking, and DoS attacks are a problem with all IPv4 > > address sharing mechanisms -- not just NAT64. Is > > http://tools.ietf.org/html/rfc6269 inadequate at describing > > the issues? > > > > Are there NAT64 *specific* issues of logging, user tracking, and DoS > > attacks that should be included in a document like > > draft-chen-v6ops-nat64-cpe? > > > > -d > > > > > > > >> Cheers > >> > >> Yu > >> > >> > >> > >> > >> -----Original Message----- > >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On > Behalf > >> Of GangChen > >> Sent: Thursday, November 03, 2011 10:00 AM > >> To: v6ops > >> Subject: [v6ops] NAT64 Operational Considerations > >> > >> Dear all, > >> > >> I have just submitted the draft for NAT64 operational consideration. > >> The intention is to provide comprehensive considerations for NAT64 > >> deployment. > >> The detailed information is listed at below > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts > >> directories. > >> > >> Title : NAT64 Operational Considerations > >> Author(s) : Gang Chen > >> Filename : draft-chen-v6ops-nat64-cpe-03.txt > >> Pages : 8 > >> Date : 2011-10-31 > >> > >> The document has summarized NAT64 usages on different modes, in > which > >> NAT64 may serve for a large-scale network or would give enterprise > or > >> residential service opportunities to be accessed by IPv6 remote > >> subscribers. The document has described different operations for > >> each usage and proposed operational considerations for each > >> particular NAT64-mode. > >> > >> A URL for this Internet-Draft is: > >> http://www.ietf.org/internet-drafts/draft-chen-v6ops-nat64-cpe- > 03.txt > >> > >> Many thanks > >> > >> Gang > >> _______________________________________________ > >> 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 hansliu@gmail.com Wed Nov 9 20:09:18 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4DBD1F0C46 for ; Wed, 9 Nov 2011 20:09:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aI1o28gLKwLA for ; Wed, 9 Nov 2011 20:09:18 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id E9EEC21F847D for ; Wed, 9 Nov 2011 20:09:17 -0800 (PST) Received: by iaeo4 with SMTP id o4so3167535iae.31 for ; Wed, 09 Nov 2011 20:09:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BF+Li+M89o44ewPY9jNDWCNvhPkjG6DgRbd/xcMupf8=; b=EN/S0a6U75uy8H5xLZazdIbjbGOnvPIZ4gRYcC0PKhmcFxt9uvJFLzP2Xe+BC4c8hH PwC8EPEU7hOepEAn2I5HwmX2PpC9xg8vQsy6DCIa1JggSpd9W5qgJ1udhJu7UbRR5n3E otauZdk/sID6YhhwKnlf4IRPa6bn39vuTsaDQ= MIME-Version: 1.0 Received: by 10.231.69.146 with SMTP id z18mr1352491ibi.79.1320898156319; Wed, 09 Nov 2011 20:09:16 -0800 (PST) Received: by 10.231.172.71 with HTTP; Wed, 9 Nov 2011 20:09:16 -0800 (PST) In-Reply-To: <867F4B6A1672E541A94676D556793ACD0C263BCDD7@MOPESMBX01.eu.thmulti.com> References: <867F4B6A1672E541A94676D556793ACD0C263BCDD7@MOPESMBX01.eu.thmulti.com> Date: Thu, 10 Nov 2011 12:09:16 +0800 Message-ID: From: Hans Liu To: Wuyts Carl Content-Type: multipart/alternative; boundary=0015176f10da6453b504b159913e Cc: Claire Cheng , "v6ops@ietf.org" Subject: Re: [v6ops] RFC6204bis-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: Thu, 10 Nov 2011 04:09:18 -0000 --0015176f10da6453b504b159913e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Nov 9, 2011 at 5:21 PM, Wuyts Carl wrot= e: > All,**** > > ** ** > > Ole has asked me, @ RIPE meeting in Vienna last week, to review the > RFC6204bis, basically to see if it would have a lot of impact towards > the/our CPE and whether or not it would be useful to publish it with its > current content.**** > > ** ** > > Overall, I don=E2=80=99t think this version really adds a lot of extra > requirements. This could be a reason to wait however, it =E2=80=9Cjust= =E2=80=9D adds > 6rd/DSlite as basic mechanisms, which is OK + it re-phrases a few of the > other requirements. I think it could also be used to add some extra info > on some of the existing RFC6204 requirements (see remarks below on WAA-8 > and WPD-5). **** > > ** ** > > I=E2=80=99ve exchanged a few mails with Ole on this, and he suggested me = to bring > these things up on v6ops; reason for this mail. Find my comments below.*= * > ** > > ** ** > > ***1. ****DLW-4: If the IPv6 CE Router is configured with a public > IPv4 address on its WAN interface, where public IPv4 address is defined a= s > any address which is not in the private IP address space specified in > [RFC5735] and also not in the reserved IP address space specified in > [RFC6333], then the IPv6 CE Router MUST disable the DS-Lite B4 element.* > > * * > > ** ** > > This one is not fully ok I=E2=80=99d say. First of all, the DSlite is su= pposed to > run on a v6-only intf, hence you could consider it as a configuration iss= ue > in case you have configured a public IPv4 on it ? Even if not, I don=E2= =80=99t > see what you should have to check for public IPv4 address presence to bri= ng > up (or not) the DSLite intf.**** > > And then what happens if the DSLite tunnel is up, and a public IPv4 is > being configured on top ? Bring it down ?**** > > Imagine you boot the CPE, preconfigured with DHCPv6 option for dslite. > This will bring up the DSLite intf, because of the option, why bothering > checking the public IPv4 presence ?**** > > Maybe this is not really an issue, afterall, it=E2=80=99s a configuration > =E2=80=9Cmistake=E2=80=9D.**** > > ** ** > > *So my recommendation here would be to remove this requirement.* > > ** > [Hans]: The recommendation looks ok to me. In D-Link implementation, I put DS-Lite under IPv4 Internet Settings, as one of the WAN type. A user can only select Static IP, DHCP, PPPoE, L2TP, PPTP or DS-Lite. Best regards, Hans --0015176f10da6453b504b159913e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wed, Nov 9, 2011 at 5:21 PM, Wuyts Ca= rl <Carl= .Wuyts@technicolor.com> wrote:

All,

=C2=A0

Ole has asked me, @ RIPE meeting in Vienna last week, = to review the RFC6204bis, basically to see if it would have a lot of impact= towards the/our CPE and whether or not it would be useful to publish it wi= th its current content.

=C2=A0

Overa= ll, I don=E2=80=99t think this version really adds a lot of extra requireme= nts.=C2=A0 This could be a reason to wait however, it =E2=80=9Cjust=E2=80= =9D adds 6rd/DSlite as basic mechanisms, which is OK + it re-phrases a few = of the other requirements.=C2=A0 I think it could also be used to add some = extra info on some of the existing RFC6204 requirements (see remarks below = on WAA-8 and WPD-5).

=C2=A0

I=E2= =80=99ve exchanged a few mails with Ole on this, and he suggested me to bri= ng these things up on v6ops; reason for this mail.=C2=A0 Find my comments b= elow.

=C2=A0

1.=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 DLW-4:=C2=A0 If the IPv6 CE Router= is configured with a public IPv4 address on its WAN interface, where publi= c IPv4 address is defined as any address which is not in the private IP add= ress space specified in [RFC5735] and also not in the reserved IP address s= pace specified in [RFC6333], then the IPv6 CE Router MUST disable the DS-Li= te B4 element.

=C2=A0

=C2=A0

This one is not fully ok I=E2=80=99d say.=C2=A0 First of all, the DSlite= is supposed to run on a v6-only intf, hence you could consider it as a con= figuration issue in case you have configured a public=C2=A0 IPv4 on it ?=C2= =A0 Even if not, I don=E2=80=99t see what you should have to check for publ= ic IPv4 address presence to bring up (or not) the DSLite intf.

And then what happens if the DSLite tun= nel is up, and a public IPv4 is being configured on top ?=C2=A0 Bring it do= wn ?

Imagine yo= u boot the CPE, preconfigured with DHCPv6 option for dslite.=C2=A0 This wil= l bring up the DSLite intf, because of the option, why bothering checking t= he public IPv4 presence ?

Maybe this is not really an issue, afte= rall, it=E2=80=99s a configuration =E2=80=9Cmistake=E2=80=9D.=

=C2=A0<= /p>

So my recommendation here would b= e to remove this requirement.

[Hans]: The recommendation looks ok to me. In D-Link implementatio= n, I put DS-Lite under IPv4 Internet Settings, as one of the WAN type. A us= er can only select Static IP, DHCP, PPPoE, L2TP, PPTP or DS-Lite.=C2=A0

=C2=A0

Best regards,
Hans
--0015176f10da6453b504b159913e-- From hansliu@gmail.com Wed Nov 9 20:28:05 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 077EE21F85AE for ; Wed, 9 Nov 2011 20:28:05 -0800 (PST) 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.299, 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 Yz36L9UwDGb8 for ; Wed, 9 Nov 2011 20:28:04 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7363421F85AA for ; Wed, 9 Nov 2011 20:28:04 -0800 (PST) Received: by iaeo4 with SMTP id o4so3184871iae.31 for ; Wed, 09 Nov 2011 20:28:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=oug6agUH4P7ZxoyhHlsN2YTXYSzpp71gAdn5v4OTdug=; b=P4H1pRPB5amzSoeMdaV8E5o0sD6I1H0sMd9yJ/Kfy6H+eQf1mbHGuIlZP+8zWf7GsT IK0qpuIAi8/6HLFaYm3pFbEl4uoPIpYopF+GXqyQM2MjJ6tl0zujir73W1zpFmdra2IA QQzvNaPmaA9sOlgCFq6cTpzC4YM6ZwT9C52xc= MIME-Version: 1.0 Received: by 10.231.69.146 with SMTP id z18mr1362028ibi.79.1320899283958; Wed, 09 Nov 2011 20:28:03 -0800 (PST) Received: by 10.231.172.71 with HTTP; Wed, 9 Nov 2011 20:28:03 -0800 (PST) In-Reply-To: References: <867F4B6A1672E541A94676D556793ACD0C263BCDD7@MOPESMBX01.eu.thmulti.com> Date: Thu, 10 Nov 2011 12:28:03 +0800 Message-ID: From: Hans Liu To: Wes Beebee Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Claire Cheng , "v6ops@ietf.org" Subject: Re: [v6ops] RFC6204bis-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: Thu, 10 Nov 2011 04:28:05 -0000 On Wed, Nov 9, 2011 at 11:42 PM, Wes Beebee wrote: >> 2. =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0WAA-8: =C2=A0If the IPv6 CE route= r does not acquire global IPv6 >> address(es) from either SLAAC or DHCPv6, then it MUST create global IPv6 >> address(es) from its delegated prefix(es) and configure those on one of >> its >> internal virtual network interfaces. >> >> I assume this is describing the situation where the WAN intf does not ge= t >> an >> IPv6 addr (not via RA, not via dhcpv6 ia_na). =C2=A0In this situation, y= ou want >> to >> configure one from the delegated prefix on =E2=80=9Ca virtual network in= tf (being >> exactly what, loop ?)=E2=80=9D. =C2=A0If the delegated prefix <>64, I do= n=E2=80=99t see an >> issue, >> however, if the ia_pd prefix length =3D 64, this would mean that only th= e >> CPE >> would get an IPv6 address from the ia_pd, and nothing more left to >> distribute >> on the LAN OR the only available /64 gets sent to the LAN hosts, but >> nothing >> available on the CPE (for remote management). > > The intent with IA_PD prefix length =3D 64 is that one /128 from the /64 = would > be configured on the internal interface, and the /64 would be advertised = on > the LAN for others to get addresses from. =C2=A0If an NS(DAD) for the loo= pback > address is received on the LAN interface, the router would respond with a= n > NA to indicate that the address was already configured on the (internal) > interface (a very unlikely event). [Hans]: It is confusing. WAN.IPv6.12 of TR-124i2 is confusing too. CPE device vendors may suffer from this kind of unclear requirements and there may be differences and (maybe) IOT issues among implementations. It says: "If the device does not have a globally-scoped address on its WAN interface after being delegated a prefix, it MUST create addresses for itself from the delegated prefix. It MUST have at least one address and MAY have more. There is currently no algorithm defined for address creation and it should be assumed that different service providers will want different rules for how to create the address, how many addresses to create, and, in the case of multiple addresses, how the different addresses are used." > > - Wes > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --=20 Instead of following the fashion, we lead it through. From Carl.Wuyts@technicolor.com Thu Nov 10 00:08:42 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC34411E80BB for ; Thu, 10 Nov 2011 00:08:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.178 X-Spam-Level: X-Spam-Status: No, score=-4.178 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7FDO5wV9wQ0 for ; Thu, 10 Nov 2011 00:08:39 -0800 (PST) Received: from na3sys009aog112.obsmtp.com (na3sys009aog112.obsmtp.com [74.125.149.207]) by ietfa.amsl.com (Postfix) with ESMTP id E0BD911E80B9 for ; Thu, 10 Nov 2011 00:08:36 -0800 (PST) Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob112.postini.com ([74.125.148.12]) with SMTP ID DSNKTruGgmfgZ4iFwWLUA7E9jtmhc4DghYF+@postini.com; Thu, 10 Nov 2011 00:08:37 PST Received: from MOPESMAILHC03.eu.thmulti.com (141.11.100.132) by mail3.technicolor.com (141.11.253.22) with Microsoft SMTP Server (TLS) id 8.3.192.1; Thu, 10 Nov 2011 09:07:47 +0100 Received: from MOPESMBX01.eu.thmulti.com ([169.254.155.121]) by MOPESMAILHC03.eu.thmulti.com ([141.11.100.132]) with mapi; Thu, 10 Nov 2011 09:07:54 +0100 From: Wuyts Carl To: Wes Beebee Date: Thu, 10 Nov 2011 09:07:49 +0100 Thread-Topic: [v6ops] RFC6204bis-02 Thread-Index: AcyfH26NRjpM8FC5QEiNtBfWkpOFnwAX4KRA Message-ID: <867F4B6A1672E541A94676D556793ACD0C263BD0EC@MOPESMBX01.eu.thmulti.com> References: <867F4B6A1672E541A94676D556793ACD0C263BCDD7@MOPESMBX01.eu.thmulti.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/related; boundary="_006_867F4B6A1672E541A94676D556793ACD0C263BD0ECMOPESMBX01eut_"; type="multipart/alternative" MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] RFC6204bis-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: Thu, 10 Nov 2011 08:08:42 -0000 --_006_867F4B6A1672E541A94676D556793ACD0C263BD0ECMOPESMBX01eut_ Content-Type: multipart/alternative; boundary="_000_867F4B6A1672E541A94676D556793ACD0C263BD0ECMOPESMBX01eut_" --_000_867F4B6A1672E541A94676D556793ACD0C263BD0ECMOPESMBX01eut_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Wes, Some remarks on your below comment. You read the WAA-8 as: sent the /64 Pd to the LAN host and fetch one /128 f= rom it for the loop intf First of all, I think the WAA-8 is not clear on this. In fact, as Ole poin= ted out, is was first written from the point-of-view that the ia_pd would b= e different from 64. This will lead to different people translating this d= ifferently, hence different implementations by CPE vendors. Secondly, I think you're violating the rules a little here. You fetch a /1= 28 host IP form the single available ia_pd and assign this one to the loopb= ack interface and you assume that the DAD process works ok, i.e., that the = CPE will say it is in use. But, the loopback interface is no part of your = LAN subnet, hence this will not work without an ND proxy (as Lorenzo mentio= ns in his reply), unless the loop intf is 'bridged' into your LAN, which is= not the case normally I'd say. I think indeed it can work in Lorenzo's story, with the ND proxy, however. = This will impose the need for some daemon to add this Proxy ND message auto= matically, as this is targeting residential gateways as well, meaning that = manual intervention on this might not be possible/wanted. Looking at these, I'm still convinced this topic needs a more detailed des= cription in the case of prefix-length =3D 64. 3 possibilities: 1. The ia_pd gets sent to the Lan hosts, no address on loop available =E8 Will work fine for the hosts, but not remotely manageable 2. The ia_pd gets sent fully to the loop, so loop gets an address fr= om it, either /64 or /128 host-IP. In this case, the Lan hosts will have = no global IP, hence cannot get passed their local link or ULA territory, wh= atever available. 3. Define Lorenzo's approach, using a ND proxy. regs Carl Wuyts GCD System Architect Networking Connect Division carl.wuyts@technicolor.com tel.: +32 3 443 65 90 [cid:image001.gif@01CC9F87.EDBC1730] [cid:image002.gif@01CC9F87.EDBC1730] Prins Boudewijnlaan 47 - 2650 Edegem - Belgium Technicolor Delivery Technologies Belgium NV Registered office (maatschappelijke zetel): Prins Boudewijnlaan 47, 2650 Ed= egem, Belgium Company registration number (ondernemingsnummer): 0428837295 - RPR Antwerpe= n [cid:image003.gif@01CC9F87.EDBC1730] Help preserve the color of our world - Think before you print. From: Lorenzo Colitti [mailto:lorenzo@google.com] Sent: woensdag 9 november 2011 21:37 To: Wuyts Carl Cc: v6ops@ietf.org Subject: Re: [v6ops] RFC6204bis-02 On Wed, Nov 9, 2011 at 01:21, Wuyts Carl > wrote: 2. WAA-8: If the IPv6 CE router does not acquire global IPv6 address= (es) from either SLAAC or DHCPv6, then it MUST create global IPv6 address(e= s) from its delegated prefix(es) and configure those on one of its internal= virtual network interfaces. I assume this is describing the situation where the WAN intf does not get a= n IPv6 addr (not via RA, not via dhcpv6 ia_na). In this situation, you wan= t to configure one from the delegated prefix on "a virtual network intf (be= ing exactly what, loop ?)". If the delegated prefix <>64, I don't see an i= ssue, however, if the ia_pd prefix length =3D 64, this would mean that only= the CPE would get an IPv6 address from the ia_pd, and nothing more left to= distribute on the LAN OR the only available /64 gets sent to the LAN hosts= , but nothing available on the CPE (for remote management). No, wait. The CE router gets at least one /64 from PD, possibly more. If it= doesn't have an IPv6 address (from RA, or from DHCPv6 NA) on the WAN inter= face, it picks ONE global address from the PD as its global IPv6 address. S= ince the CE router is a router that's connected to at least one /64 in the = PD, it can just pick an autoconf address from one of those /64s, assign it = to a loopback, and do proxy ND for it on the interface that "owns" that /64= . DAD will take care of it. No? --_000_867F4B6A1672E541A94676D556793ACD0C263BD0ECMOPESMBX01eut_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Wes,

 

Some remarks on your below comment.=

You rea= d the WAA-8 as: sent the /64 Pd to the LAN host and fetch one /128 from it = for the loop intf

&nb= sp;

First of all, I think the W= AA-8 is not clear on this.=A0 In fact, as Ole pointed out, is was first wri= tten from the point-of-view that the ia_pd would be different from 64. =A0T= his will lead to different people translating this differently, hence diffe= rent implementations by CPE vendors.

 

Secondly= , I think you’re violating the rules a little here.=A0 You fetch a /1= 28 host IP form the single available ia_pd and assign this one to the loopb= ack interface and you assume that the DAD process works ok, i.e., that the = CPE will say it is in use.=A0 But, the loopback interface is no part of you= r LAN subnet, hence this will not work without an ND proxy (as Lorenzo ment= ions in his reply), unless the loop intf is ‘bridged’ into your= LAN, which is not the case normally I’d say.

 

= I think indeed it can work in Lorenzo’s story, with the ND pro= xy, however. This will impose the need for some daemon to add this Proxy ND= message automatically, as this is targeting residential gateways as well, = meaning that manual intervention on this might not be possible/wanted.=

 

Looking at these, I’m still convinced this = topic =A0needs a more detailed description in the case of prefix-length =3D= 64.=A0 3 possibilities:

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'>1.       The ia_pd gets sent to the Lan hosts, no address on loop availabl= e

=E8 Will work fine for the hosts, but not remo= tely manageable

2.3. 

regs

 

Carl Wuyts

GCD System Architect Networking

Connect Divi= sion

carl.wuyts@technicolor.com

tel.: +32 3 443 65 90

3D=

= 3D"Visit=

Prins Boudewijnlaan 47  - = ; 2650 Edegem  -  Belgium

= Technicolor Delivery Technologies Belgium NV=

Registe= red office (maatschappelijke zetel): Prins Boudewijnlaan 47, 2650 Edegem, B= elgium

Company registr= ation number (ondernemingsnummer): 0428837295 - RPR Antwerpen

3DEco

=

Help preserve the color of our world - Think before you print.

<= td valign=3Dtop style=3D'border:none;border-top:solid #9D9FA2 1.0pt;padding= :1.5pt 0cm 1.5pt 0cm'>

Carl Wuyts

GCD System Architect Net= working

Connect Division

<= /tr>

carl.wuyts@technicolor.com

tel.: +32 3 443 65 90

3Dtwitt=

3D"Visit

Pri= ns Boudewijnlaan 47  -  2650 Edegem  - &= nbsp;Belgium

Technicolor Delivery Technologies Belg= ium NV

Registered office (maatschappelijke zetel): Pr= ins Boudewijnlaan 47, 2650 Edegem, Belgium

Company registration number (ondernemingsnummer): 0428= 837295 - RPR Antwerpen

3DEco

Help preserve = the color of our world - Think before you print.

<= /td>

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'> 

 

From: Lorenzo Colitti [mailto:lo= renzo@google.com]
Sent: woensdag 9 november 2011 21:37
To:= Wuyts Carl
Cc: v6ops@ietf.org
Subject: Re: [v6ops]= RFC6204bis-02

 <= /o:p>

On Wed, Nov 9, 2011 at 01:21, Wuyts Carl= <Carl.Wuyts@technicolor.c= om> wrote:

<= b>
2.       WAA-8:  If the IPv6 CE router does not acquire= global IPv6 address(es) from either SLAAC or DHCPv6, then it MUST create g= lobal IPv6 address(es) from its delegated prefix(es) and configure those on= one of its internal virtual network interfaces.<= /p>

 

I assume this is describing the situation where= the WAN intf does not get an IPv6 addr (not via RA, not via dhcpv6 ia_na).=   In this situation, you want to configure one from the delegated pref= ix on “a virtual network intf (being exactly what, loop ?)”.&nb= sp; If the delegated prefix <>64, I don’t see an issue, however= , if the ia_pd prefix length =3D 64, this would mean that only the CPE woul= d get an IPv6 address from the ia_pd, and nothing more left to distribute o= n the LAN OR the only available /64 gets sent to the LAN hosts, but nothing= available on the CPE (for remote management).

<= /div>

No, wait. The CE router gets at least one /6= 4 from PD, possibly more. If it doesn't have an IPv6 address (from RA, or f= rom DHCPv6 NA) on the WAN interface, it picks ONE global address from the P= D as its global IPv6 address. Since the CE router is a router that's connec= ted to at least one /64 in the PD, it can just pick an autoconf address fro= m one of those /64s, assign it to a loopback, and do proxy ND for it on the= interface that "owns" that /64. DAD will take care of it. No?

= --_000_867F4B6A1672E541A94676D556793ACD0C263BD0ECMOPESMBX01eut_-- --_006_867F4B6A1672E541A94676D556793ACD0C263BD0ECMOPESMBX01eut_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=1351; creation-date="Thu, 10 Nov 2011 08:07:50 GMT"; modification-date="Thu, 10 Nov 2011 08:07:50 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhGAAYAPcAAAAAAP///1Sfum/L64bW8o7h/ofU74fT7pHb9pfa8u75/VbD5VzG6FvF5l3G 513F5l/G51/F5mHH52PH6GPI6GPI52TH6GXJ6GbI6GnK6mjJ6WjK6WzL6m/M63HN6nPN6nTN63fR 7XnR7XTI5FeVqnnN537T7n7R7H/T7X3O6Y3f+4jV73m903/E2oDE2pTf+ZPc9JTa8Zfa8aDd8LDj 9MXr9+z5/er3+/r9/imy1yyx1S202S2z1zK43TW63jW32zS22Ta53Te73za32zq84Dm53Du73j2/ 4j2+4T283z273kHB5D++4EHA4kG/4UPA40K/4UTB5EbD5UbB40rJ7EjD5ErG6EnE5knE5Ua720rE 5kvG507J607I6U3G50/K60u+3U2/4U7A4k2/3lLI6E/A31XN7lHC4VnP8FfL61PD4lXD5FXF41vR 8VfG5VO92lrJ51a+21i/21/O7F7L6VnB3VzE4mHN6l/H5V3D30+lvWDH41/E4GDF4WLH42rL6GvP 6l+2znLZ9W7Q62C1zGO50HXZ9HTY83ba9XXX8mW70nLO6nHN6We803rd+HXV73zf+mm91HXS62vA 12GpvWavw2ixxVmWp2qxxYDW7X3Q52yzxm+2yW60x4HS6HC2yXG3ynzD2I7a75Xb7pvh9F+HkqTg 8ajg76ff7qri8bPo97fm9Ljm9MXw/Mfw/NDz/dDx+tbx+dz0++H1++f5/uv5/Six1S+22jG01zK1 2EXD5E/M7U7H50yvyWPY91zJ5WjZ92za927b+HHY82G4z3Xd+FurwHXa9Xfc93ne+F+rv37h+2u/ 1YDi/H7c9YHh+YLh+YXi+mqyxWuzxork+ovj+o3l+3K4ypXn+12PnJrm+qXp+63j8cLx/M/0/ef4 /Jfp+57q+6Xt/Kjv/avv/a3v/a7w/bPw/bzz/uP6/+z7/vP9/7fz/r30/sD0/sX1/sn2/tT4/9L2 /d/6/+X7/+b7/+r8/+v7/sz3/tr5/ub8/+39//v///3///7//////yH5BAEAAP8ALAAAAAAYABgA AAj/AP8JHEiwoMGCAgggOGCg4YqHEB8aOPCCAEESKmR84MABg0cOHUKGHDCAA4gEBQaOiIHBwgQO pmrQEEEhg80NGnJewACDhcAUJyBMwBArgL8ACkxc2MBUg8cLEEy0+PkhQoMZAerNmxegBoMLFChc AFsBQggXAkswerBgVYB8+eLtu7GorgcKDipIcBBi6r8SHtiyCoAPH7x6AXAoxjELRYO9IUIJlGMn jBi37zLHo2fPXj19/hT8WRMGDzGBb7LosIUqADp07WC7c9eOHbwAmnjwGBNIYBwwuHK0NleOOLnj 5MaxC+BpR64zp//JGQNkx6kA4rKXO8ede7oAe378/1BTSGCdMkNunfIXLhw4eQH6yU88KoiSImzK /8tzpkiPVP1gg4013gRgYGKmEMEEE0a4oYhAeahhhA/c8FMNNdF0s4466tyzTgCrOAFFEnA0IhAf bCQhhCkBVPMMNDDC+GI3AUiCBBNwRCJQH24wgUQmAWwjTDJEFllMNAGIcoQTdDAjkB9uODGFFLHw o00wwGSZpS/bBJDJEk80+eQvTVQhxR2zBECLK6202c0rAchCxhVR3DGJb5I0gYUXVqRBCiy1BFqL Dd+oMocVW+jyCCEC6ZEIIFps0cUXVOyCRhuYomEGFVx0wcsghlwyUC/DOHPIMcg4AskyzbS6DCSO ICSDiDOCGFNQNspUYgkmm3TCCSjXgPJJJ9NIYwklpRyk7LIDBQQAOw== --_006_867F4B6A1672E541A94676D556793ACD0C263BD0ECMOPESMBX01eut_ Content-Type: image/gif; name="image002.gif" Content-Description: image002.gif Content-Disposition: inline; filename="image002.gif"; size=1834; creation-date="Thu, 10 Nov 2011 08:07:50 GMT"; modification-date="Thu, 10 Nov 2011 08:07:50 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhcgBFAOZ/AEGueqipqmgxkACLS4ORyPb294DFpZrMVqvi+sXr2Ie3laLXtnRHnLQlZO3J 2M+pxP7pJvqtgePqmqOIvYLKnACP1fewoXa65/vCov71sdqRnc6OpPvrlcU/benvs7qmzpzR8P/n rc7imtLntMkhU/V7Hf/yl+fZ6f3HipjL7b+MraKs1h+WXIrU9fNrPv/dkaTIrpQpd/JlIr8kXv/o ALa3uO0bLwCmUQC68pKSlf/CDgxNosvbKtvb3IzGP8nJyoiJjPaWgH+Ag3Z3euTk5Y3Y+MTfm+3t 7r/AwZubnvBSJQCZ3NLS0//eAwN+yE84la9fmdjkX//RSiPB855BhP/ILiCvY9HeRvLkCvmykSld q/aNl4Dd+cPT6O85Q2m+Q6zRONnM5OPx0PR3OR2Z2eOttkCr4Lfbm//uQPWMWbeLscPbysbs/OP1 /ZeLwPaLN9blff/iEvXlByCi3nzB69eqvN7r4uzysHfDWSCKzu+Uh8R4pR6j4IVfqm1ucf///yH5 BAEAAH8ALAAAAAByAEUAAAf/gH+Cg4SFhoeIiYqLjI2Oj5CRkpOUlZaXmJmam5ydnp+goaKjpKWm p6ipqqusra6vsLGys7S1tqF+Oat+freMubu9vorAkkhIlryqBQWXxZBEvD2VyqhEQtPJupJJScnC pzV+2dTbqdWnSX4BNTWDR+01RIUFSO0/zX/AP+1Mg/x/iLRDku9PO0JH7NXA906hv0Ho/vSId2TQ xB4Jf1gKwKujoB8deWn8OCTkkIp+gAAJGUBQjnUhgUAEB9Lkx5C58lUr8DLkSHE5Spqb1IMjkh7T evgZ4o9JyYrR/Mib2FKfHyH4kPBq1rPGkR4lH1ZjsvQH0gDIlA7RSGSlN6uC/zgCmfcjrEFeQuRd EkeO48g/IN2pQ2boasGV014+/MPRHdw/QsYZUve3wFO4R5YWBOlN3FtMfAetBJKj9EpdEQk9+/My sWRB4hxXS3koNcdpypRWnXnXMejXf4SWHt4yNcShrVkDjy1o9lDehELnXldIGfNMoV0CJxSZnGrk kpPDltpc2FZDK+eJlqwsmsx3V3trEvdXK5CKgvKJu59fLHjX5FxXjVz5fHUXEPmAJER5gkQ2UgHq uHMdJiANkcNIK+WSQ2TraaiZPv8pFyB5jxWwkoUvLWjiVUlkmE01RJQERACRISifJhxR90cBNUTG YkE1ZAgEYTnsxlgO8wSA5P8/F7pkDo8+AvFgj7wkoR5r5hChzlU1JNjkMGCGKeaYZJZp5pmqsIHA mmyCkMKbcK4g55wrfGDnnR88oOeedZTh558WBCqoBRgUaigGISSqaAgZNOroHR5EKqkHI1Rq6QKY ZroADJx2CoMdjxSAQBGkktoCHRekqioBrLZKgBsTxCqrGirUaqsGuOaqgR5B9OprBMAGG8ELxBb7 ggnIJmuCBMw2K4EIRkQb7RkUVGstBQpkq60CazTSRqmlnqrqqq6yCqusstqqrq65+uqusMGiYCyx HCiLLAfONguttEZQe22122oLQ0GHsAGuqeOSW+656E6grq0bsIuru7/CG4H/vPMea++y+TK7r7T+ /huwtqAiMsXJKE/BBxkst5yHFjDHrAUDNNdMMxU450xFBzz3zLMXQAfthQtjFG30G1UkrXQVEDTt dNNXRC31FWAcYPXVeFih9dZWsOD11ywAkAgOZJeNwxIVpK22Ezu07fYOTwgg99wCxGD33TE0MMPe fJNgw9+A26CEDIQXXoIOiCeuQxM0NO44FjxELjkPYPhg+eVf3KD55jcM4PnnA4iNiNllo6122my/ 3XbcdMuN9916872334H/PXjhhB+uOOKMO9445JNHXvnllmfOueagfy76IaSTbfrpqavOeuuv2x27 7LTXfjvuuu/eu+/ABz88//HGH5+858sb0vzZp6Ou+uqtu1799X3Xbjvuue/Ou++/By888cU7HvLO l75CrO95a3sf3OJXt/nJbnb2Exz+ZNA9xX3vcf6jHAB9UD7OnS90Y2seAt33vunRrXp5e+AMshe4 7RlOf4vjHw3CN7nxYU6AnSNgCEk3wgpE720mnBsK6QdB+7kwf/q7YP/8BwcxOPGJC8DhBwtIiAO2 z4cKDKL8XkfEFUbwiBSEoRJpIIcomPGMUbiDIRIgRR2OToRXrEAX5kjHLvSBgUNUIQsBB8YSSOGP gJRCHGRIA0ewUYBTTAQXFslILswhjoe4Y/zy+EASbOGSmNyCCyYog0OggYeQhgSAKEcJABa40RFm gKQhThCGVrryAZR84CHSwElPgrISADhlI1J5RUc4IJaym2UtSZHL5FFREbxsny9RuAcHOPOZDjgE BrJAzWpmoRQLMIA2t7kASCTzdI44ARTGSU4oPABN6EynOtfJzna6853wjKc850nPetrznvjMpz73 yc9++tMUgQAAOw== --_006_867F4B6A1672E541A94676D556793ACD0C263BD0ECMOPESMBX01eut_ Content-Type: image/gif; name="image003.gif" Content-Description: image003.gif Content-Disposition: inline; filename="image003.gif"; size=493; creation-date="Thu, 10 Nov 2011 08:07:51 GMT"; modification-date="Thu, 10 Nov 2011 08:07:51 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhHAAhAMQAALHNVVqXGZu+IqbFNv79/ury0pK4H2SdaJzAJNjlq/3++vL34srdiSl5Mfj7 8OHrvDmDE5u+Kb3VbtDgm5jCnJC2IqDBJHqqHoazHsfYxcfco+/58f7///7+/v///f///yH5BAAA AAAALAAAAAAcACEAAAX/4CeOZGmeaKqubOumXSfKL0rT9RiTe65/nl0vxxE1KB3Ph6b8KGYjT/Pn ORwIHmy0FEQFCZRG5yldJnEqD6ezaWQIHMJDApAwCthgF8hbEqwEBQARAoWFEgskQWgiChwFDRoD hpQCA3hLQGhxSWABFpQIlAMPT2NoeTIJEBigooavlzJDS0UdHAkBEAivAoSjDklTQAROuBYQn7+/ lBJJS01SUgoJoskWvaECCWUiHEEKtw+8BtegvoWxiYtqSmsLhBblEALn2hLDH3HTAIXYuhfqVeLF TZ8SR3oSULKAQVeAChYi8kJwCUg4BcVkOOiXDgHDACAvXMBQoWQEOw6iahwsMCmdAI8CKoiciUEA gAJ8aBC4xfKlz3QRsVGcoICMJidKOjhgMKCXqKcAJqSMIkwEuw8OHjCQwNVOggJPvqm4ZUJGuw47 lajlA0Sat28xyJZV9APasGEcvknBkU9TjJ1WrTZZE9hHihAAOw== --_006_867F4B6A1672E541A94676D556793ACD0C263BD0ECMOPESMBX01eut_-- From Carl.Wuyts@technicolor.com Thu Nov 10 00:17:39 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28B171F0C41 for ; Thu, 10 Nov 2011 00:17:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.72 X-Spam-Level: X-Spam-Status: No, score=-3.72 tagged_above=-999 required=5 tests=[AWL=-0.458, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxtvk8K+lynM for ; Thu, 10 Nov 2011 00:17:36 -0800 (PST) Received: from na3sys009aog103.obsmtp.com (na3sys009aog103.obsmtp.com [74.125.149.71]) by ietfa.amsl.com (Postfix) with ESMTP id F09091F0C3F for ; Thu, 10 Nov 2011 00:17:18 -0800 (PST) Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob103.postini.com ([74.125.148.12]) with SMTP ID DSNKTruIjXYuhLGOUf/Dj0ID2ipU6iBwhVgJ@postini.com; Thu, 10 Nov 2011 00:17:20 PST 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.192.1; Thu, 10 Nov 2011 09:15:08 +0100 Received: from MOPESMBX01.eu.thmulti.com ([169.254.155.121]) by MOPESMAILHC02.eu.thmulti.com ([141.11.100.29]) with mapi; Thu, 10 Nov 2011 09:15:15 +0100 From: Wuyts Carl To: Lorenzo Colitti , Wes Beebee Date: Thu, 10 Nov 2011 09:15:13 +0100 Thread-Topic: [v6ops] RFC6204bis-02 Thread-Index: AcyfLiHAplV9Y6ucSaSDwW88SElkNQAUbgNw Message-ID: <867F4B6A1672E541A94676D556793ACD0C263BD0F3@MOPESMBX01.eu.thmulti.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/related; boundary="_006_867F4B6A1672E541A94676D556793ACD0C263BD0F3MOPESMBX01eut_"; type="multipart/alternative" MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] RFC6204bis-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: Thu, 10 Nov 2011 08:17:39 -0000 --_006_867F4B6A1672E541A94676D556793ACD0C263BD0F3MOPESMBX01eut_ Content-Type: multipart/alternative; boundary="_000_867F4B6A1672E541A94676D556793ACD0C263BD0F3MOPESMBX01eut_" --_000_867F4B6A1672E541A94676D556793ACD0C263BD0F3MOPESMBX01eut_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Lorenzo, About the link/no-link of RA and DHCPv6. Interesting comments and some valid points, but it does not cover for the 1= 00% of use cases I think. First of all, our CPE is able to handle both scenario's, link the DHCPv6 cl= ient to RA or not, and act upon it. So from that point-of-view, I'm not co= ncerned to not be able to do this or anything, we support both. However, a few things are being overlooked I think: 1. In case of ptp WAN link, the customer might not want to sent any R= A's at all, afterall, it is point-to-point, hence you cannot link DHCPv6 to= the RA, as ... nothing will happen then. 2. The DHCP WG is working on the options to get specific routes from = the server, similar as for IPv4, hence there is no default route issue in t= hat scenario, the route info will come from DHCPv6 in this case, not from R= A. Wrt the issue on CPE asking too often for PD, I agree this can be an issue.= In fact, on this the DHCP WG is also exchanging quite a few mails this we= ek, so we might see some changes here, but are bound to the existing RFC to= day of course. regs Carl Wuyts GCD System Architect Networking Connect Division carl.wuyts@technicolor.com tel.: +32 3 443 65 90 [cid:image001.gif@01CC9F89.411123C0] [cid:image002.gif@01CC9F89.411123C0] Prins Boudewijnlaan 47 - 2650 Edegem - Belgium Technicolor Delivery Technologies Belgium NV Registered office (maatschappelijke zetel): Prins Boudewijnlaan 47, 2650 Ed= egem, Belgium Company registration number (ondernemingsnummer): 0428837295 - RPR Antwerpe= n [cid:image003.gif@01CC9F89.411123C0] Help preserve the color of our world - Think before you print. From: Lorenzo Colitti [mailto:lorenzo@google.com] Sent: woensdag 9 november 2011 23:23 To: Wes Beebee Cc: Wuyts Carl; v6ops@ietf.org Subject: Re: [v6ops] RFC6204bis-02 On Wed, Nov 9, 2011 at 13:03, Wes Beebee > wrote: > The resulting potential effect on those networks' DHCPv6 servers (i.e., "= burn > them down to the ground with a > 100x increase in load") could cause thos= e > networks to slow down those rollouts considerably or not start them at al= l > until DHCPv6 servers can be forklifted. No one is suggesting that we not solve the problem. We are taking issue with HOW you are suggesting to solve the problem. I didn't make any suggestions in this thread. That discussion is being carr= ied out elsewhere with a more limited group of people, because we don't nec= essarily want to spam the whole of v6ops with it :-) All I did was give one important reason why it's not automatically a good i= dea to make RS and DHCPv6 PD independent. Another good reason, which I just realize I forgot to mention, is that from= the perspective of a CE router, having a DHCPv6 PD and no default route is= pointless, because it can't go anywhere anyway. It's also harmful to the h= osts behind it, because even if the CE router is implemented correctly and = does not give the hosts a default route, it will still be giving them globa= l IPv6 addresses, which will double their DNS lookup latency (because once = they have a global IPv6 address, they will start asking for AAAA records). I, for one, believe that the issue is really an access concentrator issue, = which routinely manages congestion-control and rate-limits DHCPv6 packets A= NYWAY. It has to - to protect the DHCPv6 servers from DoS attacks from untrusted CPE routers. Why not use the mechanisms that are already in place, that require no specific standards effort, to solve this problem? Because every time you rate-limit a DHCP request, that could be a user that= can't get online. If you're hitting rate-limits all the time, you're denyi= ng service to real users all the time. The problem here is not that one particular CE router asks for DHCP PD too = often - it may be fine for one CE router to make 5 DHCPv6 requests in one m= inute, as long as it doesn't happen all the time. It's that when when you a= dd up millions of CE routers asking every 2 minutes, *all the time* the agg= regate load becomes very large. --_000_867F4B6A1672E541A94676D556793ACD0C263BD0F3MOPESMBX01eut_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Lorenzo,<= o:p>

 

About the link/no-link of RA and DHCPv6.=

Interesting comments and some = valid points, but it does not cover for the 100% of use cases I think.=

 

First of all, our CPE is able to handle both scen= ario’s, link the DHCPv6 client to RA or not, and act upon it.  S= o from that point-of-view, I’m not concerned to not be able to do thi= s or anything, we support both.

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'>However, a few things are being overlooked I think:=

1.     &n= bsp; In case of ptp WAN link, the cus= tomer might not want to sent any RA’s at all, afterall, it is point-t= o-point, hence you cannot link DHCPv6 to the RA, as … nothing will ha= ppen then.

2.&nbs= p;      The = DHCP WG is working on the options to get specific routes from the server, s= imilar as for IPv4, hence there is no default route issue in that scenario,= the route info will come from DHCPv6 in this case, not from RA.=

 

Wrt the issue on CPE asking too often for PD, I agree t= his can be an issue.  In fact, on this the DHCP WG is also exchanging = quite a few mails this week, so we might see some changes here, but are bou= nd to the existing RFC today of course.

 

regs=

 <= /p>

Carl Wuyts<= /b>

GCD System Architect Networking=

= Connect Division

carl.wuyts@technicolor.com

tel.: +32 3 443 65 90

3Dtwitter

Prins Boudewijnl= aan 47  -  2650 Edegem  -  Belgium<= o:p>

Technicolor Delivery Technologies Belgium NV=

<= span lang=3DNL-BE style=3D'font-size:7.0pt;font-family:"Arial","sans-serif"= ;color:#9D9FA2'>Registered office (maatschappelijke zetel): Prins Boudewijn= laan 47, 2650 Edegem, Belgium

Company registration number (ondernemingsnummer): 0428837295 - RPR = Antwerpen

3DEco

Help preserve the color of o= ur world - Think before you print.

&nb= sp;

 

From: Lorenzo Colitti [mailto:lorenzo@google.c= om]
Sent: woensdag 9 november 2011 23:23
To: Wes Beebe= e
Cc: Wuyts Carl; v6ops@ietf.org
Subject: Re: [v6ops] R= FC6204bis-02

 

On Wed, Nov 9, 2011 at 13:03, Wes Beebee &= lt;wbeebee@cisco.com= > wrote:

> The resulting potential effect on those networks' DHCPv6 s= ervers (i.e., "burn
> them down to the ground with a > 100x i= ncrease in load") could cause those
> networks to slow down thos= e rollouts considerably or not start them at all
> until DHCPv6 serve= rs can be forklifted.

No one is su= ggesting that we not solve the problem.  We are taking issue
with H= OW you are suggesting to solve the problem.

 

I didn't make= any suggestions in this thread. That discussion is being carried out elsew= here with a more limited group of people, because we don't necessarily want= to spam the whole of v6ops with it :-)

 

All I did= was give one important reason why it's not automatically a good idea to ma= ke RS and DHCPv6 PD independent.


Another good reason, which I just realize I forgot to mention, is t= hat from the perspective of a CE router, having a DHCPv6 PD and no default = route is pointless, because it can't go anywhere anyway. It's also harmful = to the hosts behind it, because even if the CE router is implemented correc= tly and does not give the hosts a default route, it will still be giving th= em global IPv6 addresses, which will double their DNS lookup latency (becau= se once they have a global IPv6 address, they will start asking for AAAA re= cords).

 

=

I, for one, believe that the issue is really an access concentrato= r issue, which routinely manages congestion-control and rate-limits DH= CPv6 packets ANYWAY.  It has to - to
protect the DHCPv6 servers fro= m DoS attacks from untrusted CPE routers.

Why not use the mechanisms= that are already in place, that require no
specific standards effort, t= o solve this problem?

=  

Because every time you= rate-limit a DHCP request, that could be a user that can't get online. If = you're hitting rate-limits all the time, you're denying service to real use= rs all the time.

 <= /o:p>

The problem here is not that one p= articular CE router asks for DHCP PD too often - it may be fine for one CE = router to make 5 DHCPv6 requests in one minute, as long as it doesn't happe= n all the time. It's that when when you add up millions of CE routers askin= g every 2 minutes, *all the time* the aggregate load becomes very large.

= --_000_867F4B6A1672E541A94676D556793ACD0C263BD0F3MOPESMBX01eut_-- --_006_867F4B6A1672E541A94676D556793ACD0C263BD0F3MOPESMBX01eut_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=1351; creation-date="Thu, 10 Nov 2011 08:15:14 GMT"; modification-date="Thu, 10 Nov 2011 08:15:14 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhGAAYAPcAAAAAAP///1Sfum/L64bW8o7h/ofU74fT7pHb9pfa8u75/VbD5VzG6FvF5l3G 513F5l/G51/F5mHH52PH6GPI6GPI52TH6GXJ6GbI6GnK6mjJ6WjK6WzL6m/M63HN6nPN6nTN63fR 7XnR7XTI5FeVqnnN537T7n7R7H/T7X3O6Y3f+4jV73m903/E2oDE2pTf+ZPc9JTa8Zfa8aDd8LDj 9MXr9+z5/er3+/r9/imy1yyx1S202S2z1zK43TW63jW32zS22Ta53Te73za32zq84Dm53Du73j2/ 4j2+4T283z273kHB5D++4EHA4kG/4UPA40K/4UTB5EbD5UbB40rJ7EjD5ErG6EnE5knE5Ua720rE 5kvG507J607I6U3G50/K60u+3U2/4U7A4k2/3lLI6E/A31XN7lHC4VnP8FfL61PD4lXD5FXF41vR 8VfG5VO92lrJ51a+21i/21/O7F7L6VnB3VzE4mHN6l/H5V3D30+lvWDH41/E4GDF4WLH42rL6GvP 6l+2znLZ9W7Q62C1zGO50HXZ9HTY83ba9XXX8mW70nLO6nHN6We803rd+HXV73zf+mm91HXS62vA 12GpvWavw2ixxVmWp2qxxYDW7X3Q52yzxm+2yW60x4HS6HC2yXG3ynzD2I7a75Xb7pvh9F+HkqTg 8ajg76ff7qri8bPo97fm9Ljm9MXw/Mfw/NDz/dDx+tbx+dz0++H1++f5/uv5/Six1S+22jG01zK1 2EXD5E/M7U7H50yvyWPY91zJ5WjZ92za927b+HHY82G4z3Xd+FurwHXa9Xfc93ne+F+rv37h+2u/ 1YDi/H7c9YHh+YLh+YXi+mqyxWuzxork+ovj+o3l+3K4ypXn+12PnJrm+qXp+63j8cLx/M/0/ef4 /Jfp+57q+6Xt/Kjv/avv/a3v/a7w/bPw/bzz/uP6/+z7/vP9/7fz/r30/sD0/sX1/sn2/tT4/9L2 /d/6/+X7/+b7/+r8/+v7/sz3/tr5/ub8/+39//v///3///7//////yH5BAEAAP8ALAAAAAAYABgA AAj/AP8JHEiwoMGCAgggOGCg4YqHEB8aOPCCAEESKmR84MABg0cOHUKGHDCAA4gEBQaOiIHBwgQO pmrQEEEhg80NGnJewACDhcAUJyBMwBArgL8ACkxc2MBUg8cLEEy0+PkhQoMZAerNmxegBoMLFChc AFsBQggXAkswerBgVYB8+eLtu7GorgcKDipIcBBi6r8SHtiyCoAPH7x6AXAoxjELRYO9IUIJlGMn jBi37zLHo2fPXj19/hT8WRMGDzGBb7LosIUqADp07WC7c9eOHbwAmnjwGBNIYBwwuHK0NleOOLnj 5MaxC+BpR64zp//JGQNkx6kA4rKXO8ede7oAe378/1BTSGCdMkNunfIXLhw4eQH6yU88KoiSImzK /8tzpkiPVP1gg4013gRgYGKmEMEEE0a4oYhAeahhhA/c8FMNNdF0s4466tyzTgCrOAFFEnA0IhAf bCQhhCkBVPMMNDDC+GI3AUiCBBNwRCJQH24wgUQmAWwjTDJEFllMNAGIcoQTdDAjkB9uODGFFLHw o00wwGSZpS/bBJDJEk80+eQvTVQhxR2zBECLK6202c0rAchCxhVR3DGJb5I0gYUXVqRBCiy1BFqL Dd+oMocVW+jyCCEC6ZEIIFps0cUXVOyCRhuYomEGFVx0wcsghlwyUC/DOHPIMcg4AskyzbS6DCSO ICSDiDOCGFNQNspUYgkmm3TCCSjXgPJJJ9NIYwklpRyk7LIDBQQAOw== --_006_867F4B6A1672E541A94676D556793ACD0C263BD0F3MOPESMBX01eut_ Content-Type: image/gif; name="image002.gif" Content-Description: image002.gif Content-Disposition: inline; filename="image002.gif"; size=1834; creation-date="Thu, 10 Nov 2011 08:15:14 GMT"; modification-date="Thu, 10 Nov 2011 08:15:14 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhcgBFAOZ/AEGueqipqmgxkACLS4ORyPb294DFpZrMVqvi+sXr2Ie3laLXtnRHnLQlZO3J 2M+pxP7pJvqtgePqmqOIvYLKnACP1fewoXa65/vCov71sdqRnc6OpPvrlcU/benvs7qmzpzR8P/n rc7imtLntMkhU/V7Hf/yl+fZ6f3HipjL7b+MraKs1h+WXIrU9fNrPv/dkaTIrpQpd/JlIr8kXv/o ALa3uO0bLwCmUQC68pKSlf/CDgxNosvbKtvb3IzGP8nJyoiJjPaWgH+Ag3Z3euTk5Y3Y+MTfm+3t 7r/AwZubnvBSJQCZ3NLS0//eAwN+yE84la9fmdjkX//RSiPB855BhP/ILiCvY9HeRvLkCvmykSld q/aNl4Dd+cPT6O85Q2m+Q6zRONnM5OPx0PR3OR2Z2eOttkCr4Lfbm//uQPWMWbeLscPbysbs/OP1 /ZeLwPaLN9blff/iEvXlByCi3nzB69eqvN7r4uzysHfDWSCKzu+Uh8R4pR6j4IVfqm1ucf///yH5 BAEAAH8ALAAAAAByAEUAAAf/gH+Cg4SFhoeIiYqLjI2Oj5CRkpOUlZaXmJmam5ydnp+goaKjpKWm p6ipqqusra6vsLGys7S1tqF+Oat+freMubu9vorAkkhIlryqBQWXxZBEvD2VyqhEQtPJupJJScnC pzV+2dTbqdWnSX4BNTWDR+01RIUFSO0/zX/AP+1Mg/x/iLRDku9PO0JH7NXA906hv0Ho/vSId2TQ xB4Jf1gKwKujoB8deWn8OCTkkIp+gAAJGUBQjnUhgUAEB9Lkx5C58lUr8DLkSHE5Spqb1IMjkh7T evgZ4o9JyYrR/Mib2FKfHyH4kPBq1rPGkR4lH1ZjsvQH0gDIlA7RSGSlN6uC/zgCmfcjrEFeQuRd EkeO48g/IN2pQ2boasGV014+/MPRHdw/QsYZUve3wFO4R5YWBOlN3FtMfAetBJKj9EpdEQk9+/My sWRB4hxXS3koNcdpypRWnXnXMejXf4SWHt4yNcShrVkDjy1o9lDehELnXldIGfNMoV0CJxSZnGrk kpPDltpc2FZDK+eJlqwsmsx3V3trEvdXK5CKgvKJu59fLHjX5FxXjVz5fHUXEPmAJER5gkQ2UgHq uHMdJiANkcNIK+WSQ2TraaiZPv8pFyB5jxWwkoUvLWjiVUlkmE01RJQERACRISifJhxR90cBNUTG YkE1ZAgEYTnsxlgO8wSA5P8/F7pkDo8+AvFgj7wkoR5r5hChzlU1JNjkMGCGKeaYZJZp5pmqsIHA mmyCkMKbcK4g55wrfGDnnR88oOeedZTh558WBCqoBRgUaigGISSqaAgZNOroHR5EKqkHI1Rq6QKY ZroADJx2CoMdjxSAQBGkktoCHRekqioBrLZKgBsTxCqrGirUaqsGuOaqgR5B9OprBMAGG8ELxBb7 ggnIJmuCBMw2K4EIRkQb7RkUVGstBQpkq60CazTSRqmlnqrqqq6yCqusstqqrq65+uqusMGiYCyx HCiLLAfONguttEZQe22122oLQ0GHsAGuqeOSW+656E6grq0bsIuru7/CG4H/vPMea++y+TK7r7T+ /huwtqAiMsXJKE/BBxkst5yHFjDHrAUDNNdMMxU450xFBzz3zLMXQAfthQtjFG30G1UkrXQVEDTt dNNXRC31FWAcYPXVeFih9dZWsOD11ywAkAgOZJeNwxIVpK22Ezu07fYOTwgg99wCxGD33TE0MMPe fJNgw9+A26CEDIQXXoIOiCeuQxM0NO44FjxELjkPYPhg+eVf3KD55jcM4PnnA4iNiNllo6122my/ 3XbcdMuN9916872334H/PXjhhB+uOOKMO9445JNHXvnllmfOueagfy76IaSTbfrpqavOeuuv2x27 7LTXfjvuuu/eu+/ABz88//HGH5+858sb0vzZp6Ou+uqtu1799X3Xbjvuue/Ou++/By888cU7HvLO l75CrO95a3sf3OJXt/nJbnb2Exz+ZNA9xX3vcf6jHAB9UD7OnS90Y2seAt33vunRrXp5e+AMshe4 7RlOf4vjHw3CN7nxYU6AnSNgCEk3wgpE720mnBsK6QdB+7kwf/q7YP/8BwcxOPGJC8DhBwtIiAO2 z4cKDKL8XkfEFUbwiBSEoRJpIIcomPGMUbiDIRIgRR2OToRXrEAX5kjHLvSBgUNUIQsBB8YSSOGP gJRCHGRIA0ewUYBTTAQXFslILswhjoe4Y/zy+EASbOGSmNyCCyYog0OggYeQhgSAKEcJABa40RFm gKQhThCGVrryAZR84CHSwElPgrISADhlI1J5RUc4IJaym2UtSZHL5FFREbxsny9RuAcHOPOZDjgE BrJAzWpmoRQLMIA2t7kASCTzdI44ARTGSU4oPABN6EynOtfJzna6853wjKc850nPetrznvjMpz73 yc9++tMUgQAAOw== --_006_867F4B6A1672E541A94676D556793ACD0C263BD0F3MOPESMBX01eut_ Content-Type: image/gif; name="image003.gif" Content-Description: image003.gif Content-Disposition: inline; filename="image003.gif"; size=493; creation-date="Thu, 10 Nov 2011 08:15:14 GMT"; modification-date="Thu, 10 Nov 2011 08:15:14 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhHAAhAMQAALHNVVqXGZu+IqbFNv79/ury0pK4H2SdaJzAJNjlq/3++vL34srdiSl5Mfj7 8OHrvDmDE5u+Kb3VbtDgm5jCnJC2IqDBJHqqHoazHsfYxcfco+/58f7///7+/v///f///yH5BAAA AAAALAAAAAAcACEAAAX/4CeOZGmeaKqubOumXSfKL0rT9RiTe65/nl0vxxE1KB3Ph6b8KGYjT/Pn ORwIHmy0FEQFCZRG5yldJnEqD6ezaWQIHMJDApAwCthgF8hbEqwEBQARAoWFEgskQWgiChwFDRoD hpQCA3hLQGhxSWABFpQIlAMPT2NoeTIJEBigooavlzJDS0UdHAkBEAivAoSjDklTQAROuBYQn7+/ lBJJS01SUgoJoskWvaECCWUiHEEKtw+8BtegvoWxiYtqSmsLhBblEALn2hLDH3HTAIXYuhfqVeLF TZ8SR3oSULKAQVeAChYi8kJwCUg4BcVkOOiXDgHDACAvXMBQoWQEOw6iahwsMCmdAI8CKoiciUEA gAJ8aBC4xfKlz3QRsVGcoICMJidKOjhgMKCXqKcAJqSMIkwEuw8OHjCQwNVOggJPvqm4ZUJGuw47 lajlA0Sat28xyJZV9APasGEcvknBkU9TjJ1WrTZZE9hHihAAOw== --_006_867F4B6A1672E541A94676D556793ACD0C263BD0F3MOPESMBX01eut_-- From swmike@swm.pp.se Thu Nov 10 00:37:49 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A20221F88AB for ; Thu, 10 Nov 2011 00:37:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.145, 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 OG4IejRuaf3X for ; Thu, 10 Nov 2011 00:37:48 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 8864E21F88A0 for ; Thu, 10 Nov 2011 00:37:48 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id A97F09E; Thu, 10 Nov 2011 09:37:46 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id A660C9C; Thu, 10 Nov 2011 09:37:46 +0100 (CET) Date: Thu, 10 Nov 2011 09:37:46 +0100 (CET) From: Mikael Abrahamsson To: Wuyts Carl In-Reply-To: <867F4B6A1672E541A94676D556793ACD0C263BD0EC@MOPESMBX01.eu.thmulti.com> Message-ID: References: <867F4B6A1672E541A94676D556793ACD0C263BCDD7@MOPESMBX01.eu.thmulti.com> <867F4B6A1672E541A94676D556793ACD0C263BD0EC@MOPESMBX01.eu.thmulti.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-137064504-314882826-1320914266=:19721" Cc: "v6ops@ietf.org" Subject: Re: [v6ops] RFC6204bis-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: Thu, 10 Nov 2011 08:37:49 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---137064504-314882826-1320914266=:19721 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT On Thu, 10 Nov 2011, Wuyts Carl wrote: > (as Lorenzo mentions in his reply), unless the loop intf is 'bridged' > into your LAN, which is not the case normally I'd say. I think some of us are "damaged" from the old cisco style of doing this, which would be: int lan0 ipv6 address dhcpv6pd-space ::1/64 int loopback0 ipv6 unnumbered lan0 So basically this would work by lan0 always being "up" (regardless if there is a cable in there or not), the CPE will assign itself ::1 on that /64 which it got by DHCPv6-PD, and then it'll use that same address on loopback0, and one can do: ip telnet source-interface Loopback0 ip tacacs source-interface Loopback0 logging source-interface Loopback0 etc. Everything the router sources itself will be sourced from the IP on Looopback0 which will be the address it has on lan0. This has worked fine for 15-20 years on Cisco routers, I guess the confusion is from this model not being defined in an RFC? > I think indeed it can work in Lorenzo's story, with the ND proxy, > however. This will impose the need for some daemon to add this Proxy ND > message automatically, as this is targeting residential gateways as > well, meaning that manual intervention on this might not be > possible/wanted. I don't really see a need for ND proxy. Why is it needed? > è Will work fine for the hosts, but not remotely manageable It's still reachable, both from WAN and LAN. It's just the weak host model in standard operation. -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-314882826-1320914266=:19721-- From swmike@swm.pp.se Thu Nov 10 00:40:48 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA19D21F8A35 for ; Thu, 10 Nov 2011 00:40:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133, 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 LtvdRyqFGm7X for ; Thu, 10 Nov 2011 00:40:48 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 3267821F88AB for ; Thu, 10 Nov 2011 00:40:48 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 5B8959E; Thu, 10 Nov 2011 09:40:46 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 583679C for ; Thu, 10 Nov 2011 09:40:46 +0100 (CET) Date: Thu, 10 Nov 2011 09:40:46 +0100 (CET) From: Mikael Abrahamsson To: "v6ops@ietf.org" In-Reply-To: Message-ID: References: <867F4B6A1672E541A94676D556793ACD0C263BCDD7@MOPESMBX01.eu.thmulti.com> <867F4B6A1672E541A94676D556793ACD0C263BD0EC@MOPESMBX01.eu.thmulti.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [v6ops] RFC6204bis-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: Thu, 10 Nov 2011 08:40:48 -0000 On Thu, 10 Nov 2011, Mikael Abrahamsson wrote: > int lan0 > ipv6 address dhcpv6pd-space ::1/64 > > int loopback0 > ipv6 unnumbered lan0 This should be "ipv6 address unnumbered lan0". -- Mikael Abrahamsson email: swmike@swm.pp.se From Carl.Wuyts@technicolor.com Thu Nov 10 01:03:50 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4F6821F8512 for ; Thu, 10 Nov 2011 01:03:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.974 X-Spam-Level: X-Spam-Status: No, score=-4.974 tagged_above=-999 required=5 tests=[AWL=1.025, 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 gXnzGyWzbpoe for ; Thu, 10 Nov 2011 01:03:49 -0800 (PST) Received: from na3sys009aog116.obsmtp.com (na3sys009aog116.obsmtp.com [74.125.149.240]) by ietfa.amsl.com (Postfix) with ESMTP id C7DBC21F8531 for ; Thu, 10 Nov 2011 01:03:45 -0800 (PST) Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob116.postini.com ([74.125.148.12]) with SMTP ID DSNKTruTaq8quhPsr1iEE65zmKmqCuhKTiFF@postini.com; Thu, 10 Nov 2011 01:03:49 PST 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.192.1; Thu, 10 Nov 2011 10:00:17 +0100 Received: from MOPESMBX01.eu.thmulti.com ([169.254.155.121]) by MOPESMAILHC01.eu.thmulti.com ([141.11.100.25]) with mapi; Thu, 10 Nov 2011 10:00:24 +0100 From: Wuyts Carl To: Mikael Abrahamsson , "v6ops@ietf.org" Date: Thu, 10 Nov 2011 10:00:22 +0100 Thread-Topic: [v6ops] RFC6204bis-02 Thread-Index: AcyfhHqVvUnEJHKbSeCwDRuH+d5nswAAgULw Message-ID: <867F4B6A1672E541A94676D556793ACD0C263BD133@MOPESMBX01.eu.thmulti.com> References: <867F4B6A1672E541A94676D556793ACD0C263BCDD7@MOPESMBX01.eu.thmulti.com> <867F4B6A1672E541A94676D556793ACD0C263BD0EC@MOPESMBX01.eu.thmulti.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] RFC6204bis-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: Thu, 10 Nov 2011 09:03:50 -0000 Although I've worked @ Cisco for a couple of years, I don't think I'm damag= ed by their "style", or any other style :-) The CLI on our devices is very different from the one @ Cisco. We don't do unnumbered loopback for the Lan interface, so the lan intf gets= just an IPv6 address from the PD. You could unnumber both sides, and inde= ed make the address reachable from both LAN/WAN, however I'm not sure this = is the model you'd like to use on a residential CPE, i.e. use the same pref= ix on both BNG-CPE link as on CPE-LAN. regs Carl Wuyts GCD System Architect Networking CONNECT DIVISION carl.wuyts@technicolor.com tel.: +32 3 443 65 90 Prins Boudewijnlaan 47=A0=A0-=A0=A02650 Edegem=A0=A0-=A0=A0Belgium Technicolor Delivery Technologies Belgium NV Registered office (maatschappelijke zetel): Prins Boudewijnlaan 47, 2650 Ed= egem, Belgium Company registration number (ondernemingsnummer): 0428837295 - RPR Antwerpe= n Help preserve the color of our world - Think before you print. -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of M= ikael Abrahamsson Sent: donderdag 10 november 2011 9:41 To: v6ops@ietf.org Subject: Re: [v6ops] RFC6204bis-02 On Thu, 10 Nov 2011, Mikael Abrahamsson wrote: > int lan0 > ipv6 address dhcpv6pd-space ::1/64 > > int loopback0 > ipv6 unnumbered lan0 This should be "ipv6 address unnumbered lan0". --=20 Mikael Abrahamsson email: swmike@swm.pp.se _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From swmike@swm.pp.se Thu Nov 10 01:07:34 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68DBA21F8AFB for ; Thu, 10 Nov 2011 01:07:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.476 X-Spam-Level: X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=0.123, 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 Qo7APEnhzYUD for ; Thu, 10 Nov 2011 01:07:34 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id A0D9C21F8ACE for ; Thu, 10 Nov 2011 01:07:33 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 022019E; Thu, 10 Nov 2011 10:07:32 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id F19019C; Thu, 10 Nov 2011 10:07:32 +0100 (CET) Date: Thu, 10 Nov 2011 10:07:32 +0100 (CET) From: Mikael Abrahamsson To: Wuyts Carl In-Reply-To: <867F4B6A1672E541A94676D556793ACD0C263BD133@MOPESMBX01.eu.thmulti.com> Message-ID: References: <867F4B6A1672E541A94676D556793ACD0C263BCDD7@MOPESMBX01.eu.thmulti.com> <867F4B6A1672E541A94676D556793ACD0C263BD0EC@MOPESMBX01.eu.thmulti.com> <867F4B6A1672E541A94676D556793ACD0C263BD133@MOPESMBX01.eu.thmulti.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "v6ops@ietf.org" Subject: Re: [v6ops] RFC6204bis-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: Thu, 10 Nov 2011 09:07:34 -0000 On Thu, 10 Nov 2011, Wuyts Carl wrote: > We don't do unnumbered loopback for the Lan interface, so the lan intf > gets just an IPv6 address from the PD. You could unnumber both sides, > and indeed make the address reachable from both LAN/WAN, however I'm not > sure this is the model you'd like to use on a residential CPE, i.e. use > the same prefix on both BNG-CPE link as on CPE-LAN. Why would the address be reachable from WAN using ND? The BNG already has a static route pointing to the CPE LL address that encompasses the whole DHCPv6-PD prefix, I don't understand why it would need to reach the address using ND on the WAN link. I advocate to not have any GUA address at all on the WAN link, and that the CPE uses its address on the CPE lan interface for any locally sourced traffic (and I'm ok if this interface is always up from CPE point of view, regardless if there are any LAN ports that are up). -- Mikael Abrahamsson email: swmike@swm.pp.se From Carl.Wuyts@technicolor.com Thu Nov 10 01:22:25 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A91621F8B09 for ; Thu, 10 Nov 2011 01:22:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.479 X-Spam-Level: X-Spam-Status: No, score=-5.479 tagged_above=-999 required=5 tests=[AWL=1.120, 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 Ld5Toiua5Y3Q for ; Thu, 10 Nov 2011 01:22:25 -0800 (PST) Received: from na3sys009aog125.obsmtp.com (na3sys009aog125.obsmtp.com [74.125.149.153]) by ietfa.amsl.com (Postfix) with ESMTP id 265C121F8B03 for ; Thu, 10 Nov 2011 01:22:22 -0800 (PST) Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob125.postini.com ([74.125.148.12]) with SMTP ID DSNKTruXzYcxKKSuYtA4lYT0Z2DH+zDZT1Ex@postini.com; Thu, 10 Nov 2011 01:22:24 PST 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.192.1; Thu, 10 Nov 2011 10:18:51 +0100 Received: from MOPESMBX01.eu.thmulti.com ([169.254.155.121]) by MOPESMAILHC02.eu.thmulti.com ([141.11.100.29]) with mapi; Thu, 10 Nov 2011 10:18:57 +0100 From: Wuyts Carl To: Mikael Abrahamsson Date: Thu, 10 Nov 2011 10:18:55 +0100 Thread-Topic: [v6ops] RFC6204bis-02 Thread-Index: AcyfiDGpFvBUNvZXTwaRDJiiy1z8XAAANiPw Message-ID: <867F4B6A1672E541A94676D556793ACD0C263BD13E@MOPESMBX01.eu.thmulti.com> References: <867F4B6A1672E541A94676D556793ACD0C263BCDD7@MOPESMBX01.eu.thmulti.com> <867F4B6A1672E541A94676D556793ACD0C263BD0EC@MOPESMBX01.eu.thmulti.com> <867F4B6A1672E541A94676D556793ACD0C263BD133@MOPESMBX01.eu.thmulti.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] RFC6204bis-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: Thu, 10 Nov 2011 09:22:25 -0000 I've no problem not assigning a GUA to the WAN intf itself, it's configurab= le, depends on the ISP's choice, so that's ok, we're very flexible in that = area. Sourcing host-originated traffic from our CPE indeed can use the GUA= from the LAN, loop or WAN, no problem either, but I'm not sure our custome= rs (i.e. ISPs/Telcos) would want to use an IP from a delegated prefix to be= used as target IPv6 address for their remote management, in the CPE case, = this is often CWMP. Still, the idea of my message is not to say what should/must be done wrt GU= A usage on LAN/WAN/loop, but rather to have a clear description of it in th= e RFC6204(bis), especially for the prefixlength=3D64 use case. Carl Wuyts GCD System Architect Networking CONNECT DIVISION carl.wuyts@technicolor.com tel.: +32 3 443 65 90 Prins Boudewijnlaan 47=A0=A0-=A0=A02650 Edegem=A0=A0-=A0=A0Belgium Technicolor Delivery Technologies Belgium NV Registered office (maatschappelijke zetel): Prins Boudewijnlaan 47, 2650 Ed= egem, Belgium Company registration number (ondernemingsnummer): 0428837295 - RPR Antwerpe= n Help preserve the color of our world - Think before you print. -----Original Message----- From: Mikael Abrahamsson [mailto:swmike@swm.pp.se]=20 Sent: donderdag 10 november 2011 10:08 To: Wuyts Carl Cc: v6ops@ietf.org Subject: RE: [v6ops] RFC6204bis-02 On Thu, 10 Nov 2011, Wuyts Carl wrote: > We don't do unnumbered loopback for the Lan interface, so the lan intf=20 > gets just an IPv6 address from the PD. You could unnumber both sides,=20 > and indeed make the address reachable from both LAN/WAN, however I'm=20 > not sure this is the model you'd like to use on a residential CPE,=20 > i.e. use the same prefix on both BNG-CPE link as on CPE-LAN. Why would the address be reachable from WAN using ND? The BNG already has a= static route pointing to the CPE LL address that encompasses the whole DHC= Pv6-PD prefix, I don't understand why it would need to reach the address us= ing ND on the WAN link. I advocate to not have any GUA address at all on the WAN link, and that the= CPE uses its address on the CPE lan interface for any locally sourced traf= fic (and I'm ok if this interface is always up from CPE point of view, rega= rdless if there are any LAN ports that are up). --=20 Mikael Abrahamsson email: swmike@swm.pp.se From fred@cisco.com Thu Nov 10 01:29:15 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF42421F8ADC for ; Thu, 10 Nov 2011 01:29:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.668 X-Spam-Level: X-Spam-Status: No, score=-109.668 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 2EaA87m7g6m2 for ; Thu, 10 Nov 2011 01:29:15 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE6921F899F for ; Thu, 10 Nov 2011 01:29:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=5854; q=dns/txt; s=iport; t=1320917350; x=1322126950; h=from:subject:date:message-id:to:mime-version; bh=xGCGk15MFNqtVGgF9ons2Fiv1Y5ycpJ1uCVjH7Jo49A=; b=L1mzhPDbEYaKRW8umcL/fF7094S2AUFAVejSY2YaYL+syYoppVQ8+ubp iOeZo82bEFoeHQ407gFfFEURK7yGh1b1Q1srj2LDjvuyAXPtDnm9xxr9Z bUM6t5SM4MgcTN2cSxxI6IYvUk5HCUSg1ueq6CsjHBUL3uqp7E/Vw8hXU 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEFADiZu05Io8US/2dsb2JhbABCgk2fcAGHbYEFggcEARo4gVI1h2iYIoEmAZ5siRtjBIgNjBuFNYxK X-IronPort-AV: E=Sophos;i="4.69,488,1315180800"; d="scan'208,217";a="59568191" Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-2.cisco.com with ESMTP; 10 Nov 2011 09:29:08 +0000 Received: from Freds-Computer.local (hkidc-vpn-client-233-71.cisco.com [10.75.233.71]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pAA9T6PI031891 for ; Thu, 10 Nov 2011 09:29:07 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Thu, 10 Nov 2011 17:29:07 +0800 X-PGP-Universal: processed; by Freds-Computer.local on Thu, 10 Nov 2011 17:29:07 +0800 From: Fred Baker Date: Thu, 10 Nov 2011 17:28:55 +0800 Message-Id: <097BB1D2-D8AF-4B64-BCA2-8C1D3B37798A@cisco.com> To: "v6ops@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Content-Type: multipart/alternative; boundary=Apple-Mail-164--987248069 Subject: [v6ops] IPv6 Operations - IETF 82 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 10 Nov 2011 09:29:16 -0000 --Apple-Mail-164--987248069 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Seeing some discussion, I have added Gang Chen's draft to the agenda. = The implications are that speakers Wednesday get a half hour each, while = speakers Thursday get 24 minutes. There is an issue posting the agenda = just now, so I'll do it when the server will take it. Folks with issues = - that's what agenda bashing is for. Speakers, I need slides by Sunday evening at the latest, and I suggest = that you plan for a little presentation and a lot of discussion. IPv6 Operations - IETF 82 Wednesday 9:00-11:30 Agenda bashing =20 Basic Requirements for IPv6 Customer Edge Routers 31-Oct-11 , Operational Neighbor Discovery Problems 24-Oct-11 , Stateless Source Address Mapping for ICMPv6 Packets 25-Jul-11 , Experiences from an IPv6-Only Network in the WIDE Camp Autumn 2011 23-Oct-11 , Wireline Incremental IPv6 9-Oct-11 , Thursday 13:00-15:00 Analysis and recommendation for the ULA usage 21-Oct-11 , Using the IPv6 Flow Label for Server Load Balancing 12-Oct-11 , IPv6 Guidance for Internet Content and Application Service Providers 21-Oct-11 , Rapid Transition of IPv4 contents to be IPv6-accessible 29-Oct-11 , NAT64 Operational Considerations 31-Oct-11 , --Apple-Mail-164--987248069 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii IPv6 Operations - IETF 82
Seeing some discussion, I have added Gang Chen's draft to the agenda. The implications are that speakers Wednesday get a half hour each, while speakers Thursday get 24 minutes. There is an issue posting the agenda just now, so I'll do it when the server will take it. Folks with issues - that's what agenda bashing is for.

Speakers, I need slides by Sunday evening at the latest, and I suggest that you plan for a little presentation and a lot of discussion.

IPv6 Operations - IETF 82

Wednesday 9:00-11:30

Agenda bashing
 
Basic Requirements for IPv6 Customer Edge Routers
31-Oct-11 , <draft-ietf-v6ops-6204bis>
Operational Neighbor Discovery Problems
24-Oct-11 , <draft-ietf-v6ops-v6nd-problems>
Stateless Source Address Mapping for ICMPv6 Packets
25-Jul-11 , <draft-xli-v6ops-ivi-icmp-address>
Experiences from an IPv6-Only Network in the WIDE Camp Autumn 2011
23-Oct-11 , <draft-hazeyama-widecamp-ipv6-only-experience>
Wireline Incremental IPv6
9-Oct-11 , <draft-kuarsingh-wireline-incremental-ipv6>

Thursday 13:00-15:00

Analysis and recommendation for the ULA usage
21-Oct-11 , <draft-liu-v6ops-ula-usage-analysis>
Using the IPv6 Flow Label for Server Load Balancing
12-Oct-11 , <draft-carpenter-v6ops-label-balance>
IPv6 Guidance for Internet Content and Application Service Providers
21-Oct-11 , <draft-carpenter-v6ops-icp-guidance>
Rapid Transition of IPv4 contents to be IPv6-accessible
29-Oct-11 , <draft-sunq-v6ops-contents-transition>
NAT64 Operational Considerations
31-Oct-11 , <draft-chen-v6ops-nat64-cpe>

--Apple-Mail-164--987248069-- From ichiroumakino@gmail.com Thu Nov 10 03:58:47 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 922ED21F8AFE for ; Thu, 10 Nov 2011 03:58:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 S6wb8ufVkBTx for ; Thu, 10 Nov 2011 03:58:47 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id CAD2D21F8AFD for ; Thu, 10 Nov 2011 03:58:46 -0800 (PST) Received: by wyf28 with SMTP id 28so819307wyf.31 for ; Thu, 10 Nov 2011 03:58:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=rul8CBz74ECzv7NtgPvSWElFF0SeMSvhhZIiP+/ffQE=; b=KpU0CQwGConvNPdW/82TIo1VMOm5uqeNOFdd3baJoZ+baJXeSglEqtG01bmt1F43kw Kl9LpiIfM7ccIBAJpcD8r5dY415syv9dte7av/9sbglES+9ZAC0ulfnikd7hmFGTH9Fs Zi6fg1+RGyloiMbA8auobJZE6phYlwZ0Qpb7M= Received: by 10.216.133.13 with SMTP id p13mr1943211wei.93.1320926325988; Thu, 10 Nov 2011 03:58:45 -0800 (PST) Received: from dhcp-osl-vl300-64-103-53-121.cisco.com (dhcp-osl-vl300-64-103-53-121.cisco.com. [64.103.53.121]) by mx.google.com with ESMTPS id b5sm9312234wbh.4.2011.11.10.03.58.44 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 10 Nov 2011 03:58:44 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Ole Troan In-Reply-To: <867F4B6A1672E541A94676D556793ACD0C263BD0EC@MOPESMBX01.eu.thmulti.com> Date: Thu, 10 Nov 2011 12:58:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <867F4B6A1672E541A94676D556793ACD0C263BCDD7@MOPESMBX01.eu.thmulti.com> <867F4B6A1672E541A94676D556793ACD0C263BD0EC@MOPESMBX01.eu.thmulti.com> To: Wuyts Carl X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] RFC6204bis-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: Thu, 10 Nov 2011 11:58:47 -0000 Carl et al, > Looking at these, I=92m still convinced this topic needs a more = detailed description in the case of prefix-length =3D 64. 3 = possibilities: > 1. The ia_pd gets sent to the Lan hosts, no address on loop = available > =E8 Will work fine for the hosts, but not remotely manageable > 2. The ia_pd gets sent fully to the loop, so loop gets an = address from it, either /64 or /128 host-IP. In this case, the Lan = hosts will have no global IP, hence cannot get passed their local link = or ULA territory, whatever available. > 3. Define Lorenzo=92s approach, using a ND proxy. 4. The delegated prefix is used to assign a prefix to the LAN side = interface. The CE assigns one address out of the /64 to the LAN interface. no ND proxy needed. the only change is that the reference to an internal = virtual interface in the requirement should be removed or made optional. = possibly with text suggesting that if possible (PD size > 64) an = internal always up interface should be used to allow for remote = management even when the LAN side interface(s) are down. cheers, Ole From ichiroumakino@gmail.com Thu Nov 10 04:00:49 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB7C21F8B29 for ; Thu, 10 Nov 2011 04:00:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.529 X-Spam-Level: X-Spam-Status: No, score=-3.529 tagged_above=-999 required=5 tests=[AWL=0.070, 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 O3sb8kO9tSnX for ; Thu, 10 Nov 2011 04:00:48 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7947A21F8B28 for ; Thu, 10 Nov 2011 04:00:48 -0800 (PST) Received: by wwh12 with SMTP id 12so1573752wwh.13 for ; Thu, 10 Nov 2011 04:00:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=a/DGh+tHyzDNtX5PLQ3PtGmxI7bSbNlZS6Gz1e8BJ/E=; b=tu2LwlCcr3VhVCmIyOBEJQwDD0LBZaspqiYB/0ZJVBSIeVOfHDVAZbkfN7zyHolJ2q y8j1cdhg0AAAk+ljb2kRCSgTBxkMDdiZBzgdslJS2F8q3oN17qmY3An0TfI4BWew2fSd th0L5ANZnu4EOJnJDUZ8Pv6l33+3gCuYU3c3I= Received: by 10.216.135.40 with SMTP id t40mr1341789wei.41.1320926447678; Thu, 10 Nov 2011 04:00:47 -0800 (PST) Received: from dhcp-osl-vl300-64-103-53-121.cisco.com (dhcp-osl-vl300-64-103-53-121.cisco.com. [64.103.53.121]) by mx.google.com with ESMTPS id et20sm9297500wbb.15.2011.11.10.04.00.46 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 10 Nov 2011 04:00:47 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: Date: Thu, 10 Nov 2011 13:00:45 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <867F4B6A1672E541A94676D556793ACD0C263BCDD7@MOPESMBX01.eu.thmulti.com> <867F4B6A1672E541A94676D556793ACD0C263BD0EC@MOPESMBX01.eu.thmulti.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] RFC6204bis-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: Thu, 10 Nov 2011 12:00:49 -0000 Mikael, >> (as Lorenzo mentions in his reply), unless the loop intf is 'bridged' = into your LAN, which is not the case normally I'd say. >=20 > I think some of us are "damaged" from the old cisco style of doing = this, which would be: >=20 > int lan0 > ipv6 address dhcpv6pd-space ::1/64 >=20 > int loopback0 > ipv6 unnumbered lan0 >=20 > So basically this would work by lan0 always being "up" (regardless if = there is a cable in there or not), the CPE will assign itself ::1 on = that /64 which it got by DHCPv6-PD, and then it'll use that same address = on loopback0, and one can do: >=20 > ip telnet source-interface Loopback0 > ip tacacs source-interface Loopback0 > logging source-interface Loopback0 >=20 > etc. Everything the router sources itself will be sourced from the IP = on Looopback0 which will be the address it has on lan0. >=20 > This has worked fine for 15-20 years on Cisco routers, I guess the = confusion is from this model not being defined in an RFC? you may think you are damaged by the old cisco style of doing it, while = you are in fact wrong. ;-) the "ipv6 unnumbered" command does not do what its "ip unnumbered" = equivalent does. it is only a reference used by the source address selection algorithm. = in the above configuration the address is bound to the lan0 interface. = and therefore no form of ND proxy is needed. cheers, Ole= From swmike@swm.pp.se Thu Nov 10 04:05:19 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C073A21F8B21 for ; Thu, 10 Nov 2011 04:05:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.114, 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 TR-oq5+sE8Fg for ; Thu, 10 Nov 2011 04:05:19 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 3707021F86EE for ; Thu, 10 Nov 2011 04:05:19 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 5F7219E; Thu, 10 Nov 2011 13:05:18 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 5C1DC9C; Thu, 10 Nov 2011 13:05:18 +0100 (CET) Date: Thu, 10 Nov 2011 13:05:18 +0100 (CET) From: Mikael Abrahamsson To: Ole Troan In-Reply-To: Message-ID: References: <867F4B6A1672E541A94676D556793ACD0C263BCDD7@MOPESMBX01.eu.thmulti.com> <867F4B6A1672E541A94676D556793ACD0C263BD0EC@MOPESMBX01.eu.thmulti.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "v6ops@ietf.org" Subject: Re: [v6ops] RFC6204bis-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: Thu, 10 Nov 2011 12:05:19 -0000 On Thu, 10 Nov 2011, Ole Troan wrote: > it is only a reference used by the source address selection algorithm. > in the above configuration the address is bound to the lan0 interface. > and therefore no form of ND proxy is needed. I never said ND proxy was needed, I was advocating that it wasn't needed. Also, I don't understand why you say it's different from the IPv4 equivalent, in what way? -- Mikael Abrahamsson email: swmike@swm.pp.se From Carl.Wuyts@technicolor.com Thu Nov 10 04:08:26 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08ED921F8B1C for ; Thu, 10 Nov 2011 04:08:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.666 X-Spam-Level: X-Spam-Status: No, score=-5.666 tagged_above=-999 required=5 tests=[AWL=0.933, 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 NJ1KOieg5osq for ; Thu, 10 Nov 2011 04:08:25 -0800 (PST) Received: from na3sys009aog119.obsmtp.com (na3sys009aog119.obsmtp.com [74.125.149.246]) by ietfa.amsl.com (Postfix) with ESMTP id 8983821F8B15 for ; Thu, 10 Nov 2011 04:08:23 -0800 (PST) Received: from mopesedge02.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob119.postini.com ([74.125.148.12]) with SMTP ID DSNKTru+sJlAhYKiVypZzMAkaow/GYYXgQwU@postini.com; Thu, 10 Nov 2011 04:08:25 PST Received: from MOPESMAILHC02.eu.thmulti.com (141.11.100.29) by mopesedge02.eu.thmulti.com (141.11.253.23) with Microsoft SMTP Server (TLS) id 8.3.192.1; Thu, 10 Nov 2011 13:06:31 +0100 Received: from MOPESMBX01.eu.thmulti.com ([169.254.155.121]) by MOPESMAILHC02.eu.thmulti.com ([141.11.100.29]) with mapi; Thu, 10 Nov 2011 13:06:46 +0100 From: Wuyts Carl To: Ole Troan Date: Thu, 10 Nov 2011 13:06:45 +0100 Thread-Topic: [v6ops] RFC6204bis-02 Thread-Index: AcyfoB3gZjE7W7FiQ/Orjly0P5GkYwAARbyg Message-ID: <867F4B6A1672E541A94676D556793ACD0C263BD210@MOPESMBX01.eu.thmulti.com> References: <867F4B6A1672E541A94676D556793ACD0C263BCDD7@MOPESMBX01.eu.thmulti.com> <867F4B6A1672E541A94676D556793ACD0C263BD0EC@MOPESMBX01.eu.thmulti.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] RFC6204bis-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: Thu, 10 Nov 2011 12:08:26 -0000 Agree Carl Wuyts GCD System Architect Networking CONNECT DIVISION carl.wuyts@technicolor.com tel.: +32 3 443 65 90 Prins Boudewijnlaan 47=A0=A0-=A0=A02650 Edegem=A0=A0-=A0=A0Belgium Technicolor Delivery Technologies Belgium NV Registered office (maatschappelijke zetel): Prins Boudewijnlaan 47, 2650 Ed= egem, Belgium Company registration number (ondernemingsnummer): 0428837295 - RPR Antwerpe= n Help preserve the color of our world - Think before you print. -----Original Message----- From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of Ole Troan Sent: donderdag 10 november 2011 12:59 To: Wuyts Carl Cc: Wes Beebee; v6ops@ietf.org Subject: Re: [v6ops] RFC6204bis-02 Carl et al, > Looking at these, I'm still convinced this topic needs a more detailed d= escription in the case of prefix-length =3D 64. 3 possibilities: > 1. The ia_pd gets sent to the Lan hosts, no address on loop availab= le > =E8 Will work fine for the hosts, but not remotely manageable > 2. The ia_pd gets sent fully to the loop, so loop gets an address = from it, either /64 or /128 host-IP. In this case, the Lan hosts will hav= e no global IP, hence cannot get passed their local link or ULA territory, = whatever available. > 3. Define Lorenzo's approach, using a ND proxy. 4. The delegated prefix is used to assign a prefix to the LAN side interfac= e. The CE assigns one address out of the /64 to the LAN interface. no ND proxy needed. the only change is that the reference to an internal vi= rtual interface in the requirement should be removed or made optional. poss= ibly with text suggesting that if possible (PD size > 64) an internal alway= s up interface should be used to allow for remote management even when the = LAN side interface(s) are down. cheers, Ole From ichiroumakino@gmail.com Thu Nov 10 04:09:35 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19B2221F8B3A for ; Thu, 10 Nov 2011 04:09:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.533 X-Spam-Level: X-Spam-Status: No, score=-3.533 tagged_above=-999 required=5 tests=[AWL=0.066, 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 Um8fiNGjfQzT for ; Thu, 10 Nov 2011 04:09:34 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 54C5F21F8B38 for ; Thu, 10 Nov 2011 04:09:34 -0800 (PST) Received: by wyf28 with SMTP id 28so831371wyf.31 for ; Thu, 10 Nov 2011 04:09:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=jSsQaF5EfJgf0MmhxeLnCFkgcGmT4XVyYy1g/3lj74k=; b=bdHVAO/xhYd4z3f1jm64KQmTEfMqBPXjx3umd5K3WSEsbF0pFMbnMDZ/5vmh0wdcGf ZS/zugb8KChXLXgcviyZMf5OqZq6b1RSv7ixP+A0S6EanV/0YSJwOi2TEJpAIcqypYNq EFUDJuIXDCUQYnpSAhe5kUsApQmWBQjatZZWg= Received: by 10.180.85.161 with SMTP id i1mr8281695wiz.17.1320926973514; Thu, 10 Nov 2011 04:09:33 -0800 (PST) Received: from dhcp-osl-vl300-64-103-53-121.cisco.com (dhcp-osl-vl300-64-103-53-121.cisco.com. [64.103.53.121]) by mx.google.com with ESMTPS id k5sm4726800wiz.9.2011.11.10.04.09.32 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 10 Nov 2011 04:09:32 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: Date: Thu, 10 Nov 2011 13:09:31 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2F20AC05-3E0D-46F8-9C01-421C96961255@employees.org> References: <867F4B6A1672E541A94676D556793ACD0C263BCDD7@MOPESMBX01.eu.thmulti.com> <867F4B6A1672E541A94676D556793ACD0C263BD0EC@MOPESMBX01.eu.thmulti.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] RFC6204bis-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: Thu, 10 Nov 2011 12:09:35 -0000 Mikael, >> it is only a reference used by the source address selection = algorithm. in the above configuration the address is bound to the lan0 = interface. and therefore no form of ND proxy is needed. >=20 > I never said ND proxy was needed, I was advocating that it wasn't = needed. indeed. I tried to say the same thing. > Also, I don't understand why you say it's different from the IPv4 = equivalent, in what way? we're getting very cisco-ish here. ip unnumbered borrows an address from = another interface. basically sharing an address between two interfaces. = the IPv6 equivalent does no such thing. trust me, I wrote that code. cheers, Ole From bingxuere@gmail.com Thu Nov 10 05:48:41 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78EE721F8B27 for ; Thu, 10 Nov 2011 05:48:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.944 X-Spam-Level: X-Spam-Status: No, score=-2.944 tagged_above=-999 required=5 tests=[AWL=0.054, 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 MhcCA0yOO0IS for ; Thu, 10 Nov 2011 05:48:40 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7707421F8B21 for ; Thu, 10 Nov 2011 05:48:40 -0800 (PST) Received: by iaeo4 with SMTP id o4so3791164iae.31 for ; Thu, 10 Nov 2011 05:48:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=UuDqGfUX/OodwzmtO74sxniQ+pdNAYJOEM6tYkp0T1g=; b=oEZIb3kAScSCXTmm3bx37zCPdEHWNf9Pchii50RDKIFzsyUT7q+R4nSZIZrn+ziKz8 5HmFxUm0bRsqxQJIPkYBfPSk9lvCsI8weyZrKdvvG7MzQEczb6Y9pbuU5lNJgnvPLQnP 6c3yeyWamzZ27LGHNa7sxGSUdaNj3euAddSS4= Received: by 10.42.155.133 with SMTP id u5mr7680282icw.8.1320932920094; Thu, 10 Nov 2011 05:48:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.223.197 with HTTP; Thu, 10 Nov 2011 05:47:57 -0800 (PST) In-Reply-To: <031801cc9e77$05aaacb0$11000610$@com> References: <031801cc9e77$05aaacb0$11000610$@com> From: Qiong Date: Thu, 10 Nov 2011 21:47:57 +0800 Message-ID: To: Dan Wing Content-Type: multipart/alternative; boundary=90e6ba21241b796ede04b161a933 Cc: v6ops Subject: Re: [v6ops] NAT64 Operational Considerations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 10 Nov 2011 13:48:41 -0000 --90e6ba21241b796ede04b161a933 Content-Type: text/plain; charset=UTF-8 Hi Dan, On Wed, Nov 9, 2011 at 8:32 AM, Dan Wing wrote: > > -----Original Message----- > > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > > Of Eleven Fu(Yu) > > Sent: Monday, November 07, 2011 2:02 AM > > To: GangChen; v6ops > > Subject: Re: [v6ops] NAT64 Operational Considerations > > > > Hi Gang, > > > > I have read draft-chen-v6ops-nat64-cpe, please see come comments below, > > > > The draft is structured by different deploy positions of NAT64 as > > different modes. It describes operational process for each mode. But I > > think as a informational guide for readers, some more considerations > > need to be described for each mode in more detail, such as logging > > problem, ALG issues, DNS, load balancing etc. > > > > For section 4, some security considerations also need to be involved, > > such as user tracking, Dos attack etc. > > Logging, user tracking, and DoS attacks are a problem with all IPv4 > address sharing mechanisms -- not just NAT64. Is > http://tools.ietf.org/html/rfc6269 inadequate at describing > the issues? > > I agree there are similar issues in address sharing. But from our deployment experience, I think it will still have different impact with regard to IDC deployment model. Some specific considerations for NAT64 server-side deployment have been described in draft-sunq-v6ops-contents-transition, including: 1) addressing: private address space can be provided in a controlled IPv4 network (IDC), which may further improve the scalability using 1:1 address mapping 2) DNS: static AAAA records can be added directly in authoritative DNS server, and this would be easier to implement in practice 3) Security: since there will be worldwide IPv6 users, some security mechanisms e.g. acl, etc, will not be as efficient as customer-side deployment. Additional considerations need to been taken here. 4) ALG: since the applications for a given IDC can be known in advance, limited ALGs will been needed in this case compared to user-side deployment. 5) Geographically aware services: For geo-location service, an open API can be provided to ICPs to get original IPv6 address for subscribers when needed. 6) Logging: user-level logging can be introduced to meet the practical logging requirement for large-scale operators I would like to have your comments as well :) Best wishes Qiong > Are there NAT64 *specific* issues of logging, user tracking, and DoS > attacks that should be included in a document like > draft-chen-v6ops-nat64-cpe? > > -d > > > > > Cheers > > > > Yu > > > > > > > > > > -----Original Message----- > > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > > Of GangChen > > Sent: Thursday, November 03, 2011 10:00 AM > > To: v6ops > > Subject: [v6ops] NAT64 Operational Considerations > > > > Dear all, > > > > I have just submitted the draft for NAT64 operational consideration. > > The intention is to provide comprehensive considerations for NAT64 > > deployment. > > The detailed information is listed at below > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > Title : NAT64 Operational Considerations > > Author(s) : Gang Chen > > Filename : draft-chen-v6ops-nat64-cpe-03.txt > > Pages : 8 > > Date : 2011-10-31 > > > > The document has summarized NAT64 usages on different modes, in which > > NAT64 may serve for a large-scale network or would give enterprise or > > residential service opportunities to be accessed by IPv6 remote > > subscribers. The document has described different operations for > > each usage and proposed operational considerations for each > > particular NAT64-mode. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-chen-v6ops-nat64-cpe-03.txt > > > > Many thanks > > > > Gang > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --90e6ba21241b796ede04b161a933 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Dan,

On Wed, Nov 9, 2011 at 8:32 AM, D= an Wing <dwing@cisco.com> wrote:
> -----Original Message-----
> From: v6op= s-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
> Of Eleven Fu(Yu)
> Sent: Monday, November 07, 2011 2:02 AM
> To: GangChen; v6ops
> Subject: Re: [v6ops] NAT64 Operational Considerations
>
> Hi Gang,
>
> I have read draft-chen-v6ops-nat64-cpe, please see come comments below= ,
>
> The draft is structured by different deploy positions of NAT64 as
> different modes. It describes operational process for each mode. But I=
> think as a informational guide for readers, some more considerations > need to be described for each mode in more detail, such as logging
> problem, ALG issues, DNS, load balancing etc.
>
> For section 4, some security considerations also need to be involved,<= br> > such as user tracking, Dos attack etc.

Logging, user tracking, and DoS attacks are a problem with all IPv4 address sharing mechanisms -- not just NAT64. =C2=A0Is
http://too= ls.ietf.org/html/rfc6269 inadequate at describing
the issues?

I agree there are=C2=A0similar=C2=A0issues in address= sharing. But from our deployment experience, I think it will still have di= fferent impact with regard to IDC deployment model. Some specific considera= tions for NAT64 server-side deployment have been described in draft-sunq-v6= ops-contents-transition, including:
1) addressing: private address space can be provided in a controlled I= Pv4 network (IDC), which may further improve the scalability using 1:1 addr= ess mapping
2) DNS: static AAAA records can be added directly in = authoritative DNS server, and this would be easier to implement in practice=
3) Security: since there will be worldwide=C2=A0IPv6=C2=A0users, some = security mechanisms e.g. acl, etc, will not be as efficient as customer-sid= e deployment. Additional considerations need to been taken here. =C2=A0
4) ALG: since the applications for a given IDC can be known in advan= ce, limited ALGs will been needed in this case compared to user-side deploy= ment.=C2=A0
5)=C2=A0Geographically aware services: For geo-location service, an op= en API can be provided to ICPs to get original IPv6 address for=C2=A0subscr= ibers=C2=A0when needed.
6) Logging: user-level logging can be int= roduced to meet the practical logging requirement for large-scale operators=

I would like to have your comments as well :)

Best wishes

Qiong
=C2=A0=
Are there NAT64 *specific* issues of logging, user tracking, and DoS
attacks that should be included in a document like
draft-chen-v6ops-nat64-cpe?

-d



> Cheers
>
> Yu
>
>
>
>
> -----Original Message-----
> From: v6op= s-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
> Of GangChen
> Sent: Thursday, November 03, 2011 10:00 AM
> To: v6ops
> Subject: [v6ops] NAT64 Operational Considerations
>
> Dear all,
>
> I have just submitted the draft for NAT64 operational consideration. > The intention is to provide comprehensive considerations for NAT64
> deployment.
> The detailed information is listed at below
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : = NAT64 Operational Considerations
> =C2=A0 =C2=A0 =C2=A0 =C2=A0Author(s) =C2=A0 =C2=A0 =C2=A0 : Gang Chen<= br> > =C2=A0 =C2=A0 =C2=A0 =C2=A0Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft= -chen-v6ops-nat64-cpe-03.txt
> =C2=A0 =C2=A0 =C2=A0 =C2=A0Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : = 8
> =C2=A0 =C2=A0 =C2=A0 =C2=A0Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 2011-10-31
>
> =C2=A0 The document has summarized NAT64 usages on different modes, in= which
> =C2=A0 NAT64 may serve for a large-scale network or would give enterpr= ise or
> =C2=A0 residential service opportunities to be accessed by IPv6 remote=
> =C2=A0 subscribers. =C2=A0The document has described different operati= ons for
> =C2=A0 each usage and proposed operational considerations for each
> =C2=A0 particular NAT64-mode.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-che= n-v6ops-nat64-cpe-03.txt
>
> Many thanks
>
> Gang
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org=
> https://www.ietf.org/mailman/listinfo/v6ops
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org=
> https://www.ietf.org/mailman/listinfo/v6ops

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

--90e6ba21241b796ede04b161a933-- From dwing@cisco.com Thu Nov 10 07:13:26 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0914221F8B1F for ; Thu, 10 Nov 2011 07:13:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.375 X-Spam-Level: X-Spam-Status: No, score=-105.375 tagged_above=-999 required=5 tests=[AWL=0.624, 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 QlhiP1vZjyZ3 for ; Thu, 10 Nov 2011 07:13:25 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 32E9D21F8B1D for ; Thu, 10 Nov 2011 07:13:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=5443; q=dns/txt; s=iport; t=1320938005; x=1322147605; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=e9g19nS9DJegqk4bYQ3sk/2Nm8KZpTKOKc48L0LRiOQ=; b=Ft5SFiL74gAVvoNqVZGuiBnTIvm0uz3r4gTAfN78s9LLVrgGmRiutRZC giceZhVO/r7Tb2sQnwRIWPBUz0J68K6h0iDB5ua0uWmRI/IH0smJSTN/p l3DvxgfQFWlMFWde6v382+GwUaygnjgUZbBu/GwLLocU69iDDXuxhJ2Rw A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsIAAIvpu06rRDoI/2dsb2JhbABEhH2VMYFrjg6BBYFyAQEBAwEBAQEFCgEQB0QLBQcBAwIJDwIEAQEBAgIjAwICGQgGFQoJCAEBBBMJAheHYAiZRQGMWZISgTCHOIEWBIgPlmCHTw X-IronPort-AV: E=Sophos;i="4.69,489,1315180800"; d="scan'208";a="13430795" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 10 Nov 2011 15:13:25 +0000 Received: from dwingWS ([10.32.240.194]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pAAFDONL024331; Thu, 10 Nov 2011 15:13:24 GMT From: "Dan Wing" To: "'Qiong'" References: <031801cc9e77$05aaacb0$11000610$@com> In-Reply-To: Date: Thu, 10 Nov 2011 07:13:25 -0800 Message-ID: <08d801cc9fbb$4b0aee10$e120ca30$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acyfr3lLYcjw4sn8QlCf8UWhOZPSigAC16ZA Content-Language: en-us Cc: 'v6ops' Subject: Re: [v6ops] NAT64 Operational Considerations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 10 Nov 2011 15:13:26 -0000 > -----Original Message----- > From: Qiong [mailto:bingxuere@gmail.com] > Sent: Thursday, November 10, 2011 5:48 AM > To: Dan Wing > Cc: Eleven Fu(Yu); GangChen; v6ops > Subject: Re: [v6ops] NAT64 Operational Considerations > > Hi Dan, > > > On Wed, Nov 9, 2011 at 8:32 AM, Dan Wing wrote: > > > > -----Original Message----- > > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On > Behalf > > > Of Eleven Fu(Yu) > > Sent: Monday, November 07, 2011 2:02 AM > > To: GangChen; v6ops > > Subject: Re: [v6ops] NAT64 Operational Considerations > > > > > Hi Gang, > > > > I have read draft-chen-v6ops-nat64-cpe, please see come > comments below, > > > > The draft is structured by different deploy positions of NAT64 > as > > different modes. It describes operational process for each > mode. But I > > think as a informational guide for readers, some more > considerations > > need to be described for each mode in more detail, such as > logging > > problem, ALG issues, DNS, load balancing etc. > > > > For section 4, some security considerations also need to be > involved, > > such as user tracking, Dos attack etc. > > > Logging, user tracking, and DoS attacks are a problem with all > IPv4 > address sharing mechanisms -- not just NAT64. Is > http://tools.ietf.org/html/rfc6269 inadequate at describing > the issues? > > > > I agree there are similar issues in address sharing. But from our > deployment experience, I think it will still have different impact with > regard to IDC deployment model. Some specific considerations for NAT64 > server-side deployment Which is the "The IPv6 Internet to an IPv4 Network" scenario described in RFC6144. > have been described in draft-sunq-v6ops- > contents-transition, including: > 1) addressing: private address space can be provided in a controlled > IPv4 network (IDC), which may further improve the scalability using 1:1 > address mapping Yes, that is worth describing. > 2) DNS: static AAAA records can be added directly in authoritative DNS > server, and this would be easier to implement in practice That is because "The IPv6 Internet to an IPv4 Network" does not require synthesized AAAA, which was described in http://tools.ietf.org/html/rfc6144#section-2.3 > 3) Security: since there will be worldwide IPv6 users, some security > mechanisms e.g. acl, etc, will not be as efficient as customer-side > deployment. Additional considerations need to been taken here. > 4) ALG: since the applications for a given IDC can be known in advance, > limited ALGs will been needed in this case compared to user-side > deployment. > 5) Geographically aware services: For geo-location service, an open API > can be provided to ICPs to get original IPv6 address for subscribers > when needed. > 6) Logging: user-level logging can be introduced to meet the practical > logging requirement for large-scale operators I like 3-6, too. Thanks for explaining -- I now understand you are concentrating on the "The IPv6 Internet to an IPv4 Network" scenario, which I had previously mis-understood or I had missed. -d > I would like to have your comments as well :) > > Best wishes > > Qiong > > > Are there NAT64 *specific* issues of logging, user tracking, and > DoS > attacks that should be included in a document like > draft-chen-v6ops-nat64-cpe? > > -d > > > > > > Cheers > > > > Yu > > > > > > > > > > -----Original Message----- > > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On > Behalf > > Of GangChen > > Sent: Thursday, November 03, 2011 10:00 AM > > To: v6ops > > Subject: [v6ops] NAT64 Operational Considerations > > > > Dear all, > > > > I have just submitted the draft for NAT64 operational > consideration. > > The intention is to provide comprehensive considerations for > NAT64 > > deployment. > > The detailed information is listed at below > > > > A New Internet-Draft is available from the on-line Internet- > Drafts > > directories. > > > > Title : NAT64 Operational Considerations > > Author(s) : Gang Chen > > Filename : draft-chen-v6ops-nat64-cpe-03.txt > > Pages : 8 > > Date : 2011-10-31 > > > > The document has summarized NAT64 usages on different modes, > in which > > NAT64 may serve for a large-scale network or would give > enterprise or > > residential service opportunities to be accessed by IPv6 > remote > > subscribers. The document has described different operations > for > > each usage and proposed operational considerations for each > > particular NAT64-mode. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-chen-v6ops-nat64-cpe- > 03.txt > > > > Many thanks > > > > Gang > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > From fx.lebail@yahoo.com Thu Nov 10 07:44:57 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8609321F8B21 for ; Thu, 10 Nov 2011 07:44:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.042 X-Spam-Level: X-Spam-Status: No, score=0.042 tagged_above=-999 required=5 tests=[AWL=-0.259, BAYES_50=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 zXZ8wFdN0pL3 for ; Thu, 10 Nov 2011 07:44:57 -0800 (PST) Received: from nm30.bullet.mail.ne1.yahoo.com (nm30.bullet.mail.ne1.yahoo.com [98.138.90.93]) by ietfa.amsl.com (Postfix) with SMTP id D122521F8B1F for ; Thu, 10 Nov 2011 07:44:56 -0800 (PST) Received: from [98.138.90.55] by nm30.bullet.mail.ne1.yahoo.com with NNFMP; 10 Nov 2011 15:44:49 -0000 Received: from [98.138.89.166] by tm8.bullet.mail.ne1.yahoo.com with NNFMP; 10 Nov 2011 15:44:49 -0000 Received: from [127.0.0.1] by omp1022.mail.ne1.yahoo.com with NNFMP; 10 Nov 2011 15:44:49 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 753098.57107.bm@omp1022.mail.ne1.yahoo.com Received: (qmail 6741 invoked by uid 60001); 10 Nov 2011 15:44:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1320939889; bh=6WNgFnY/yowNsHYz0zCCislaPKhtPoNpeHvaL3dUjDg=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Kf2V8YIUELQJS5oljlKXaNmcntoEnbDsJfkHIg7eLA61eWtUr6pSimKjIfsO+/pgI8iLLVsBtOQ2z5aOkFy6LblPXFiIhnqnONUKTu37+4HHkmtXxcr5JpolQueslfEauOs2sfdMx7kDb+NPgyysGnJArtirUY3dBgKDWk248BI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=FWhgj+TBSDDnb7xN1jLb3yoc5XR3ELrYiPOPcIdYPgaYx62VCWCTPJd91NEyjlveZX3x/aZheF0cOJeoU48oR1XjYqALEW8BFDXxmz8zrUKV5N/AHw+/Wl/AT15pqccKPL4mEije9Aqv4YdcZb4mgAt8tp1cNPEQlb2+oHLPd3k=; X-YMail-OSG: cRr8zboVM1mXqvwkJduUttPY5.0J7iy5aGdh8_Sxvda30Uq 5g3OPK99ufzhV9HN55ELBDMbvZqVVCr.lX5NS6v9dgmh7T3E2jdKPc6i8u4d JLmotZKFFQjWNOYRadnvLrFiWTKOX682fF_.8odhTu9pPGp7e8GtzT_EBIYH JGp_ZrjVPHNQiXaluF8FHVbIBiZ0aUuibML_Kx5P05WaNlYIbY2CyvyjOxBw 0pjMr2__DejUZWd0Anz8kIof_9NLyRGu4LoHWG.UQ9R4idqLEnFU.jn8D5d7 aCxzAKqP4UWzcD0mnLMRVgPjg7rCp6hBax0ATdFpTmULWyR0D0lG2Vafv8E6 fDomqtWQLB5883.tP46ITP3xhY6s5VpuFM7sAShnr0yjFMQVDvWZ3UfyXw34 mfRQjYgLc4qtXI_heAvrxl8ReUOQF2dT6h83kM2DfP9900SojMsHPkWtBwHI 0H8oa0oYT Received: from [193.49.124.107] by web126013.mail.ne1.yahoo.com via HTTP; Thu, 10 Nov 2011 07:44:48 PST X-Mailer: YahooMailWebService/0.8.115.325013 References: <867F4B6A1672E541A94676D556793ACD0C263BCDD7@MOPESMBX01.eu.thmulti.com> <867F4B6A1672E541A94676D556793ACD0C263BD0EC@MOPESMBX01.eu.thmulti.com> Message-ID: <1320939888.6720.YahooMailNeo@web126013.mail.ne1.yahoo.com> Date: Thu, 10 Nov 2011 07:44:48 -0800 (PST) From: =?utf-8?B?RnJhbsOnb2lzLVhhdmllciBMZSBCYWls?= To: Wuyts Carl , Wes Beebee In-Reply-To: <867F4B6A1672E541A94676D556793ACD0C263BD0EC@MOPESMBX01.eu.thmulti.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] RFC6204bis-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: =?utf-8?B?RnJhbsOnb2lzLVhhdmllciBMZSBCYWls?= List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 15:44:57 -0000 =0A=0A________________________________=0A>From: Wuyts Carl =0A>To: Wes Beebee =0A>Cc: "v6ops@ietf.org" = =0A>Sent: Thursday, November 10, 2011 9:07 AM=0A>Subject: R= e: [v6ops] RFC6204bis-02=0A>=0A>=0A>Hi Wes,=0A>=C2=A0=0A>Some remarks on yo= ur below comment.=0A>You read the WAA-8 as: sent the /64 Pd to the LAN host= and fetch one /128 from it for the loop intf=0A>=C2=A0=0A>First of all, I = think the WAA-8 is not clear on this.=C2=A0 In fact, as Ole pointed out, is= was first written from the point-of-view that the ia_pd would be different= from 64. =C2=A0This will lead to different people translating this differe= ntly, hence different implementations by CPE vendors.=0A>=C2=A0=0A>Secondly= , I think you=E2=80=99re violating the rules a little here.=C2=A0 You fetch= a /128 host IP form the single available ia_pd and assign this one to the = loopback interface and you assume that the DAD process works ok, i.e., that= the CPE will say it is in use.=C2=A0 But, the loopback interface is no par= t of your LAN subnet, hence this will not work without an ND proxy (as Lore= nzo mentions in his reply), unless the loop intf is =E2=80=98bridged=E2=80= =99 into your LAN, which is not the case normally I=E2=80=99d say.=0A>=C2= =A0=0A>I think indeed it can work in Lorenzo=E2=80=99s story, with the ND p= roxy, however. This will impose the need for some daemon to add this Proxy = ND message automatically, as this is targeting residential gateways as well= , meaning that manual intervention on this might not be possible/wanted.=0A= >=C2=A0=0A>Looking at these, I=E2=80=99m still convinced this topic =C2=A0n= eeds a more detailed description in the case of prefix-length =3D 64.=C2=A0= 3 possibilities:=0A>1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The ia_pd gets = sent to the Lan hosts, no address on loop available=0A>=C3=A8Will work fine= for the hosts, but not remotely manageable =0A>2.=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 =C2=A0The ia_pd gets sent fully to the loop, so loop gets an a= ddress from it, either /64 or /128 host-IP.=C2=A0=C2=A0 In this case, the L= an hosts will have no global IP, hence cannot get passed their local link o= r ULA territory, whatever available.=0A>3.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Define Lorenzo=E2=80=99s approach, using a ND proxy.=0A>=C2=A0 =0A=0A= =0AHi,=0A=0AMany CPE have a bridge on the LAN side, bridging Ethernet inter= faces, Wifi interface, etc.=0A=0AThis bridge should be always up, not depen= dent of the underlying interfaces.=0A=0AIf you set on the bridge an EUI-64 = (on other) based on the IA_PD, you dont need loopback, so no problem.=0A=0A= As said in RFC6204,=C2=A0 =0A=0AWAA-9: As a router, the IPv6 CE router MUS= T follow the weak host (Weak ES) model [RFC1122]. When originating packets= from an interface, it will use a source address from another one of its in= terfaces if the outgoing interface does not have an address of suitable sco= pe. =0ACheers,=0A=0AFran=C3=A7ois-Xavier=0A From joelja@bogus.com Thu Nov 10 09:26:42 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B632421F893C for ; Thu, 10 Nov 2011 09:26:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.01 X-Spam-Level: X-Spam-Status: No, score=-102.01 tagged_above=-999 required=5 tests=[AWL=-0.011, 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 zIlNi7QtRzL6 for ; Thu, 10 Nov 2011 09:26:42 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD9C21F891D for ; Thu, 10 Nov 2011 09:26:42 -0800 (PST) Received: from Zorch.local (89.sub-166-250-33.myvzw.com [166.250.33.89]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id pAAHQfO6072954 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Thu, 10 Nov 2011 17:26:41 GMT (envelope-from joelja@bogus.com) Message-ID: <4EBC094A.6050608@bogus.com> Date: Thu, 10 Nov 2011 09:26:34 -0800 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: IPv6 Ops WG 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]); Thu, 10 Nov 2011 17:26:41 +0000 (UTC) Subject: [v6ops] V6ops sessions could use a scribe. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 10 Nov 2011 17:26:42 -0000 Our meetings are: WEDNESDAY, November 16, 2011 0900 THURSDAY, November 17, 2011 1300 While we have a good track record with lining up volunteers, and I generally take speaking notes to the jabber room as well you might consider whether you'd assist the relevance and accuracy of the minutes by taking notes. You can if you are so inclined use the v6ops etherpad in the interests validating that experiment. http://tools.ietf.org/wg/v6ops/minutes thanks joel From shemant@cisco.com Thu Nov 10 12:55:02 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE13A21F8B61 for ; Thu, 10 Nov 2011 12:55:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.83 X-Spam-Level: X-Spam-Status: No, score=-5.83 tagged_above=-999 required=5 tests=[AWL=0.169, 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 8QRMEUqeWdeq for ; Thu, 10 Nov 2011 12:55:02 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 1E9C521F8B57 for ; Thu, 10 Nov 2011 12:55:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=992; q=dns/txt; s=iport; t=1320958502; x=1322168102; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=7tZsZkJIHHAJqlzutVZFRFmf2pbd7YC3CtCcMPm6Sgc=; b=UmreWrMshfFUHuevNFsLViH9Fdbz8grBJQcqTXFhfeLeZdVBLgQuq+fo oNzC9cPNcgarUiWHAQ83erEARtiDhdJRYUnIo4zkiLMhgXcb6UcuqUL+v OVei+eOX8b1ms84hNyVUJ3QO0BG6xJzEqKEdO4r5CDfsPGRhQmVR5peGd Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsEAAJw5vE6tJV2Y/2dsb2JhbABEmjKPeoEFgXIBAQEEAQEBDwEdCjQXBAIBCBEEAQELBhcBBgEmHwkIAQEEARIIGodomSUBnlmJG2MEiA+RWoxT X-IronPort-AV: E=Sophos;i="4.69,490,1315180800"; d="scan'208";a="34897513" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 10 Nov 2011 20:55:01 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pAAKt1IH013280; Thu, 10 Nov 2011 20:55:01 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Nov 2011 14:55:01 -0600 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 10 Nov 2011 14:55:00 -0600 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3034945F0@XMB-RCD-109.cisco.com> In-Reply-To: <4EBC094A.6050608@bogus.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] V6ops sessions could use a scribe. Thread-Index: Acyfze/elhOexMhyRbOYH9ItCwv8JwAHPSLg References: <4EBC094A.6050608@bogus.com> From: "Hemant Singh (shemant)" To: "Joel jaeggli" , "IPv6 Ops WG" X-OriginalArrivalTime: 10 Nov 2011 20:55:01.0626 (UTC) FILETIME=[03C4C5A0:01CC9FEB] Subject: Re: [v6ops] V6ops sessions could use a scribe. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 10 Nov 2011 20:55:03 -0000 I can volunteer to be a scribe except during presentation of the rfc6204bis document when I may need to comment at the mic. Thanks, Hemant -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Joel jaeggli Sent: Thursday, November 10, 2011 12:27 PM To: IPv6 Ops WG Subject: [v6ops] V6ops sessions could use a scribe. Our meetings are: WEDNESDAY, November 16, 2011 0900 THURSDAY, November 17, 2011 1300 While we have a good track record with lining up volunteers, and I generally take speaking notes to the jabber room as well you might consider whether you'd assist the relevance and accuracy of the minutes by taking notes. You can if you are so inclined use the v6ops etherpad in the interests validating that experiment. http://tools.ietf.org/wg/v6ops/minutes thanks joel _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From brian.e.carpenter@gmail.com Thu Nov 10 13:29:14 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93CAE21F8A56 for ; Thu, 10 Nov 2011 13:29:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.257 X-Spam-Level: X-Spam-Status: No, score=-103.257 tagged_above=-999 required=5 tests=[AWL=-0.110, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152, 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 nXkoNnw7XTcT for ; Thu, 10 Nov 2011 13:29:13 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 29D3521F8A55 for ; Thu, 10 Nov 2011 13:29:13 -0800 (PST) Received: by faas12 with SMTP id s12so3927172faa.31 for ; Thu, 10 Nov 2011 13:29:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=7J9rFhBkknDW5N+vLuglJngR8d7lICpmhWaKMKbjsVE=; b=mltX+jjQQMUey9xJ7jPGk0DvTgBAWULWnbnZBXt2m003hNkoiaLmJPve270AKZ+zPC mUXwjojVsH7GxXi3CKD7eW6IDgz1ymnn+3Yv6+Q57efyRokPrsAkaPqXfeB7BzM6yM/g 9gQc6zR5P1H1vu/osvaCjoI/e8SL8ka8WifxM= Received: by 10.223.6.15 with SMTP id 15mr14535576fax.4.1320960550811; Thu, 10 Nov 2011 13:29:10 -0800 (PST) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id n25sm12769683fah.15.2011.11.10.13.29.08 (version=SSLv3 cipher=OTHER); Thu, 10 Nov 2011 13:29:10 -0800 (PST) Message-ID: <4EBC4219.7000205@gmail.com> Date: Fri, 11 Nov 2011 10:28:57 +1300 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=UTF-8 Content-Transfer-Encoding: 7bit Subject: [v6ops] =?utf-8?q?Adventures_in_Tech=3A_Dive_on_in=2C_the_IPv6_is?= =?utf-8?q?_lovely_=E2=80=A2_The_Register_Forums?= X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 10 Nov 2011 21:29:14 -0000 IF somebody has the patience, it might be interesting to go through these two articles and the resulting forum comments to identify operational issues, gaps and misconceptions. http://www.theregister.co.uk/2011/10/31/ipv6_transport/ http://www.theregister.co.uk/2011/11/07/ipv6_transport_of_delight_part_2/ -- Regards Brian Carpenter From lorenzo@google.com Thu Nov 10 13:51:34 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36C1121F849E for ; Thu, 10 Nov 2011 13:51:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.862 X-Spam-Level: X-Spam-Status: No, score=-102.862 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1YN9vCfZ0TW for ; Thu, 10 Nov 2011 13:51:33 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB3821F84A0 for ; Thu, 10 Nov 2011 13:51:32 -0800 (PST) Received: by iaeo4 with SMTP id o4so4448429iae.31 for ; Thu, 10 Nov 2011 13:51:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=m7TVmBltBWfEHrRATYNvTRCEG86KAIYeXky0GmGZzSo=; b=Yuy/7aUA0x6hWeObZMFRws6/4kl6+qImLDHHV0G8Z5JwHkKGRzPqFchzlxx7U2flhC tLHR27KXhRk8MBvhrV0Q== Received: by 10.231.63.9 with SMTP id z9mr2237490ibh.17.1320961892620; Thu, 10 Nov 2011 13:51:32 -0800 (PST) Received: by 10.231.63.9 with SMTP id z9mr2237483ibh.17.1320961892460; Thu, 10 Nov 2011 13:51:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.202.14 with HTTP; Thu, 10 Nov 2011 13:51:11 -0800 (PST) In-Reply-To: <867F4B6A1672E541A94676D556793ACD0C263BD0EC@MOPESMBX01.eu.thmulti.com> References: <867F4B6A1672E541A94676D556793ACD0C263BCDD7@MOPESMBX01.eu.thmulti.com> <867F4B6A1672E541A94676D556793ACD0C263BD0EC@MOPESMBX01.eu.thmulti.com> From: Lorenzo Colitti Date: Thu, 10 Nov 2011 13:51:11 -0800 Message-ID: To: Wuyts Carl Content-Type: multipart/alternative; boundary=000e0cd4b38e5ca78e04b168681b X-System-Of-Record: true Cc: "v6ops@ietf.org" Subject: Re: [v6ops] RFC6204bis-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: Thu, 10 Nov 2011 21:51:34 -0000 --000e0cd4b38e5ca78e04b168681b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Thu, Nov 10, 2011 at 00:07, Wuyts Carl wrote= : > Some remarks on your below comment. > > You read the WAA-8 as: sent the /64 Pd to the LAN host and fetch one /128 > from it for the loop intf**** > > ** ** > > First of all, I think the WAA-8 is not clear on this. In fact, as Ole > pointed out, is was first written from the point-of-view that the ia_pd > would be different from 64. This will lead to different people translati= ng > this differently, hence different implementations by CPE vendors.**** > > ** ** > > Secondly, I think you=92re violating the rules a little here. You fetch = a > /128 host IP form the single available ia_pd and assign this one to the > loopback interface and you assume that the DAD process works ok, i.e., th= at > the CPE will say it is in use. But, the loopback interface is no part of > your LAN subnet, hence this will not work without an ND proxy (as Lorenzo > mentions in his reply), unless the loop intf is =91bridged=92 into your L= AN, > which is not the case normally I=92d say. > Actually, I think that in practice this is not a problem, because the LAN interface is actually a bridge, so it's a virtual interface. So you can simply assign the address to it and you're done. As an example: say that you have a /64 for the LAN interface: 2001:db8:0:1::/64 . That's a virtual interface, so you can just pick any address on the LAN interface (say 2001:db8:0:1:/64, or even 2001:db8:0:1::1) , and assign it to the LAN interface, and that's it. DAD will work. I agree that the text needs to be clarified. What was the original reason for saying "configuring it on one of its internal virtual interfaces"? Was it just to say that the CE router should be able to use a LAN-side address when talking to the rest of the world? I think the weak host model (mandated in WAA-9) does that for you. So perhaps we can just change the text to "MUST create global IPv6 address(es) from its delegated prefix(es) to use for global communications", and leave it at that? --000e0cd4b38e5ca78e04b168681b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Thu, Nov 10, 2011 at 00:07, Wuyts Carl <Carl.Wuyts@te= chnicolor.com> wrote:

Some remarks= on your below comment.

You read the WAA-8 as: sent = the /64 Pd to the LAN host and fetch one /128 from it for the loop intf<= /u>

=A0

First= of all, I think the WAA-8 is not clear on this.=A0 In fact, as Ole pointed= out, is was first written from the point-of-view that the ia_pd would be d= ifferent from 64. =A0This will lead to different people translating this di= fferently, hence different implementations by CPE vendors.

=A0

Secondly, I think you=92re violating the rules a little h= ere.=A0 You fetch a /128 host IP form the single available ia_pd and assign= this one to the loopback interface and you assume that the DAD process wor= ks ok, i.e., that the CPE will say it is in use.=A0 But, the loopback inter= face is no part of your LAN subnet, hence this will not work without an ND = proxy (as Lorenzo mentions in his reply), unless the loop intf is =91bridge= d=92 into your LAN, which is not the case normally I=92d say.


Actually, I think that=A0in pr= actice this is not a problem, because the LAN interface is actually a bridg= e, so it's a virtual interface. So you can simply assign the address to= it and you're done.

As an example: say that you have a /64 for the LAN inte= rface: 2001:db8:0:1::/64 . That's a virtual interface, so you can just = pick any address on the LAN interface (say 2001:db8:0:1:<IID>/64, or = even 2001:db8:0:1::1) , and assign it to the LAN interface, and that's = it. DAD will work.

I agree that the text needs to be clarified.
=
What was the original reason for saying "configuring it= on one of its internal virtual interfaces"? Was it just to say that t= he CE router should be able to use a LAN-side address when talking to the r= est of the world? I think the weak host model (mandated in WAA-9) does that= for you. So perhaps we can just change the text to "MUST create=A0glo= bal IPv6 address(es) from its delegated prefix(es) to use for global commun= ications", and leave it at that?
--000e0cd4b38e5ca78e04b168681b-- From lorenzo@google.com Thu Nov 10 14:42:33 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FFF621F8770 for ; Thu, 10 Nov 2011 14:42:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=-0.209, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_32=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 BmBs5wYEgZ-i for ; Thu, 10 Nov 2011 14:42:32 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9F62021F86FF for ; Thu, 10 Nov 2011 14:42:32 -0800 (PST) Received: by iaeo4 with SMTP id o4so4501080iae.31 for ; Thu, 10 Nov 2011 14:42:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=2MHiSa5mluysEZyjUO9YpAYYy5bQZA/Cc6IRpyIOW8M=; b=kHWGu7LqBQWBlnhgKwQ9lsuNuxuSkeNr895YYL3/iERq8XBc4OLdLKWJu5mDflyznN U+NSv7UY5wyg3YAkGzZg== Received: by 10.231.4.131 with SMTP id 3mr2284158ibr.30.1320964952295; Thu, 10 Nov 2011 14:42:32 -0800 (PST) Received: by 10.231.4.131 with SMTP id 3mr2284145ibr.30.1320964952149; Thu, 10 Nov 2011 14:42:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.35.201 with HTTP; Thu, 10 Nov 2011 14:42:11 -0800 (PST) In-Reply-To: <867F4B6A1672E541A94676D556793ACD0C263BD0F3@MOPESMBX01.eu.thmulti.com> References: <867F4B6A1672E541A94676D556793ACD0C263BD0F3@MOPESMBX01.eu.thmulti.com> From: Lorenzo Colitti Date: Thu, 10 Nov 2011 14:42:11 -0800 Message-ID: To: Wuyts Carl Content-Type: multipart/alternative; boundary=000e0cd139babbcf9904b1691e58 X-System-Of-Record: true Cc: "v6ops@ietf.org" Subject: Re: [v6ops] RFC6204bis-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: Thu, 10 Nov 2011 22:42:33 -0000 --000e0cd139babbcf9904b1691e58 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Thu, Nov 10, 2011 at 00:15, Wuyts Carl wrote= : > 1. **In case of ptp WAN link, the customer might not want to sent > any RA=92s at all, afterall, it is point-to-point, hence you cannot link > DHCPv6 to the RA, as =85 nothing will happen then. > What kind of point-to-point link? In PPP you have IPv6CP and you can use that as a signal to trigger DHCPv6 PD. Are there other kinds? > **** > > **2. **The DHCP WG is working on the options to get specific routes > from the server, similar as for IPv4, hence there is no default route iss= ue > in that scenario, the route info will come from DHCPv6 in this case, not > from RA. > People have been talking about getting routes via DHCPv6 for a long time, and it hasn't actually happened yet. If this time the IETF does reach consensus on it and it becomes an RFC, then that RFC can always update this one. --000e0cd139babbcf9904b1691e58 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Thu, Nov 10, 2011 at 00:15, Wuyts Carl <Carl.Wuyts@te= chnicolor.com> wrote:

1.=A0=A0=A0=A0=A0=A0 In cas= e of ptp WAN link, the customer might not want to sent any RA=92s at all, a= fterall, it is point-to-point, hence you cannot link DHCPv6 to the RA, as = =85 nothing will happen then.

=A0
What kind of point-to-point lin= k? In PPP you have IPv6CP and you can use that as a signal to trigger DHCPv= 6 PD. Are there other kinds?
=A0

2.=A0=A0=A0=A0=A0=A0 The DHCP WG is working on the = options to get specific routes from the server, similar as for IPv4, hence = there is no default route issue in that scenario, the route info will come = from DHCPv6 in this case, not from RA.

People have been talking about getting routes= via DHCPv6 for a long time, and it hasn't actually happened yet. If th= is time the IETF does reach consensus on it and it becomes an RFC, then tha= t RFC can always update this one.
--000e0cd139babbcf9904b1691e58-- From niu.qibo@zte.com.cn Thu Nov 10 16:46:46 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9E731F0C5A; Thu, 10 Nov 2011 16:46:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -91.334 X-Spam-Level: X-Spam-Status: No, score=-91.334 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_46=0.256, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_45=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, 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 b9yT4wiKUkQ7; Thu, 10 Nov 2011 16:46:46 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 6A6131F0C3C; Thu, 10 Nov 2011 16:46:45 -0800 (PST) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 566901738626466; Fri, 11 Nov 2011 08:36:04 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 6255.1738626466; Fri, 11 Nov 2011 08:46:14 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id pAB0kOct087371; Fri, 11 Nov 2011 08:46:24 +0800 (GMT-8) (envelope-from niu.qibo@zte.com.cn) In-Reply-To: To: v6ops-bounces@ietf.org Cc: v6ops , v6ops-bounces@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: niu.qibo@zte.com.cn Date: Fri, 11 Nov 2011 08:46:18 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-11-11 08:46:25, Serialize complete at 2011-11-11 08:46:25 Content-Type: multipart/related; boundary="=_related 0004408448257945_=" X-MAIL: mse02.zte.com.cn pAB0kOct087371 Subject: [v6ops] =?gb2312?b?tPC4tDogICBOQVQ2NCBPcGVyYXRpb25hbCBDb25zaWRl?= =?gb2312?b?cmF0aW9ucw==?= X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 11 Nov 2011 00:46:47 -0000 This is a multipart message in MIME format. --=_related 0004408448257945_= Content-Type: multipart/alternative; boundary="=_alternative 0004408548257945_=" --=_alternative 0004408548257945_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksIE1yIENoZW4NCkkgaGF2ZSByZWFkIHlvdXIgZHJhZnQsIGl0IGNvdmVycyBtb3N0IHNjZW5h cmlvczsNCkNHTiBob3Qtc3RhbmRieSBtZWNoYW5pc20sIExhd2Z1bCBpbnRlcmNlcHRpb24gKEND LUlJRiksIHVzZXIgdHJhY2VhYmlsaXR5IA0KYW5kIHNjZXVyaXR5IChUQ1AgVHJhY2sgYW5kIEFu dGktRERPUykgbWF5IGJlIGNvbnNpZGVyZWQgaW4gIk5BVDY0LUNHTiANCk1vZGUgUmVxdWlyZW1l bnRzIg0KVGhhbmtzIQ0KDQoNCg0KTml1IFFpYm8gxaPG9LKoDQpCZWFyZXIgTmV0d29ya3MgUHJv ZHVjdCBQbGFubmluZyBTeXN0ZW0gRGVwdA0KDQpQcm9kdWN0IE1hcmtldGluZyBTeXN0ZW0gDQqy +sa3ytCzoczlz7UNCjUvQixOMC42OCBaaUppbmdIdWEgUm9hZCxZdUh1YSBEaXN0cmljdCxOYW5q aW5nLEppYW5nc3UgUC5SLkNoaW5hLCAyMTAwMTINClRlbDorODYtMjUtNTI4NzA0ODMNCkZheDor ODYtMjUtNTI4NzA2NTMNCkVtYWlsOm5pdS5xaWJvQHp0ZS5jb20uY24gDQoNCg0KDQoNCg0KDQpH YW5nQ2hlbiA8cGhkZ2FuZ0BnbWFpbC5jb20+DQq3orz+yMujuiB2Nm9wcy1ib3VuY2VzQGlldGYu b3JnDQoyMDExLTExLTAzIDEwOjAwDQogDQogICAgICAgIMrVvP7Iy6O6ICAgICAgICB2Nm9wcyA8 djZvcHNAaWV0Zi5vcmc+DQogICAgICAgILOty82juiANCiAgICAgICAg1vfM4qO6ICBbdjZvcHNd ICBOQVQ2NCBPcGVyYXRpb25hbCBDb25zaWRlcmF0aW9ucw0KDQoNCkRlYXIgYWxsLA0KDQpJIGhh dmUganVzdCBzdWJtaXR0ZWQgdGhlIGRyYWZ0IGZvciBOQVQ2NCBvcGVyYXRpb25hbCBjb25zaWRl cmF0aW9uLg0KVGhlIGludGVudGlvbiBpcyB0byBwcm92aWRlIGNvbXByZWhlbnNpdmUgY29uc2lk ZXJhdGlvbnMgZm9yIE5BVDY0IA0KZGVwbG95bWVudC4NClRoZSBkZXRhaWxlZCBpbmZvcm1hdGlv biBpcyBsaXN0ZWQgYXQgYmVsb3cNCg0KQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxl IGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIA0KZGlyZWN0b3JpZXMuDQoNCiAgICAg ICBUaXRsZSAgICAgICAgICAgOiBOQVQ2NCBPcGVyYXRpb25hbCBDb25zaWRlcmF0aW9ucw0KICAg ICAgIEF1dGhvcihzKSAgICAgICA6IEdhbmcgQ2hlbg0KICAgICAgIEZpbGVuYW1lICAgICAgICA6 IGRyYWZ0LWNoZW4tdjZvcHMtbmF0NjQtY3BlLTAzLnR4dA0KICAgICAgIFBhZ2VzICAgICAgICAg ICA6IDgNCiAgICAgICBEYXRlICAgICAgICAgICAgOiAyMDExLTEwLTMxDQoNCiAgVGhlIGRvY3Vt ZW50IGhhcyBzdW1tYXJpemVkIE5BVDY0IHVzYWdlcyBvbiBkaWZmZXJlbnQgbW9kZXMsIGluIHdo aWNoDQogIE5BVDY0IG1heSBzZXJ2ZSBmb3IgYSBsYXJnZS1zY2FsZSBuZXR3b3JrIG9yIHdvdWxk IGdpdmUgZW50ZXJwcmlzZSBvcg0KICByZXNpZGVudGlhbCBzZXJ2aWNlIG9wcG9ydHVuaXRpZXMg dG8gYmUgYWNjZXNzZWQgYnkgSVB2NiByZW1vdGUNCiAgc3Vic2NyaWJlcnMuICBUaGUgZG9jdW1l bnQgaGFzIGRlc2NyaWJlZCBkaWZmZXJlbnQgb3BlcmF0aW9ucyBmb3INCiAgZWFjaCB1c2FnZSBh bmQgcHJvcG9zZWQgb3BlcmF0aW9uYWwgY29uc2lkZXJhdGlvbnMgZm9yIGVhY2gNCiAgcGFydGlj dWxhciBOQVQ2NC1tb2RlLg0KDQpBIFVSTCBmb3IgdGhpcyBJbnRlcm5ldC1EcmFmdCBpczoNCmh0 dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWNoZW4tdjZvcHMtbmF0NjQt Y3BlLTAzLnR4dA0KDQpNYW55IHRoYW5rcw0KDQpHYW5nDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KdjZvcHMgbWFpbGluZyBsaXN0DQp2Nm9wc0BpZXRm Lm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KDQoNCg0K DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29u dGFpbmVkIGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9y Z2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNp cGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQg YXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVu aWNhdGlvbiB0byBvdGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQg d2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ug b2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJ ZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhl IG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBt ZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2Ug aGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5 c3RlbS4NCg== --=_alternative 0004408548257945_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLCBNciBDaGVuPC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5JIGhhdmUgcmVhZCB5b3VyIGRyYWZ0 LCBpdCBjb3ZlcnMgbW9zdA0Kc2NlbmFyaW9zOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+Q0dOIGhvdC1zdGFuZGJ5IG1lY2hhbmlzbSwgTGF3ZnVsIGludGVyY2Vw dGlvbg0KKENDLUlJRiksIHVzZXIgdHJhY2VhYmlsaXR5IGFuZCBzY2V1cml0eSAoVENQIFRyYWNr IGFuZCBBbnRpLURET1MpIG1heQ0KYmUgY29uc2lkZXJlZCBpbiAmcXVvdDtOQVQ2NC1DR04gTW9k ZSBSZXF1aXJlbWVudHMmcXVvdDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPlRoYW5rcyE8L2ZvbnQ+DQo8dGFibGU+DQo8dHI+DQo8dGQ+DQo8ZGl2IGFsaWduPWNl bnRlcj48aW1nIHNyYz1jaWQ6XzJfMDZCNjQxQzgwNkI2M0UwQzAwMDQ0MDdDNDgyNTc5NDU+PC9k aXY+DQo8dGQ+PGZvbnQgc2l6ZT0yPjxicj4NCjwvZm9udD4NCjx0YWJsZSB3aWR0aD0xMDAlPg0K PHRyPg0KPHRkIGNvbHNwYW49Mj48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxiPk5pdSBRaWJv IMWjxvSyqDwvYj48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9IkFyaWFsIj5CZWFyZXIg TmV0d29ya3MgUHJvZHVjdCBQbGFubmluZyBTeXN0ZW0gRGVwdDwvZm9udD4NCjx0cj4NCjx0ZCBy b3dzcGFuPTI+PGltZyBzcmM9Y2lkOl8yXzA3OUI2QzQ4MDc5QjY4OEMwMDA0NDA3RDQ4MjU3OTQ1 Pg0KPHRkPjxmb250IHNpemU9MiBjb2xvcj0jOTA5MDkwIGZhY2U9IkFyaWFsIj48Yj5Qcm9kdWN0 IE1hcmtldGluZyBTeXN0ZW0NCjwvYj48L2ZvbnQ+DQo8dHI+DQo8dGQ+PGZvbnQgc2l6ZT0yIGNv bG9yPSM5MDkwOTAgZmFjZT0iQXJpYWwiPjxiPrL6xrfK0LOhzOXPtTwvYj48L2ZvbnQ+DQo8dHI+ DQo8dGQgY29sc3Bhbj0yPjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+NS9CLE4wLjY4IFppSmlu Z0h1YSBSb2FkLFl1SHVhDQpEaXN0cmljdCxOYW5qaW5nLEppYW5nc3UgUC5SLkNoaW5hLCAyMTAw MTI8YnI+DQpUZWw6Kzg2LTI1LTUyODcwNDgzPGJyPg0KRmF4Ois4Ni0yNS01Mjg3MDY1Mzxicj4N CkVtYWlsOm5pdS5xaWJvQHp0ZS5jb20uY24gPC9mb250PjwvdGFibGU+DQo8YnI+PC90YWJsZT4N Cjxicj4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10 b3A+DQo8dGQ+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPkdhbmdDaGVu ICZsdDtwaGRnYW5nQGdtYWlsLmNvbSZndDs8L2I+PC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj63orz+yMujuiB2Nm9wcy1ib3VuY2VzQGlldGYub3JnPC9mb250Pg0K PHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTEtMTEtMDMgMTA6MDA8L2ZvbnQ+ DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9IkFyaWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgytW8/sjLo7oNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3Y2 b3BzICZsdDt2Nm9wc0BpZXRmLm9yZyZndDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyCzrcvNo7oNCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7INb3zOKjug0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7W3Y2b3BzXSAmbmJzcDtOQVQ2NCBPcGVyYXRpb25hbCBDb25zaWRlcmF0aW9u czwvZm9udD48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+RGVhciBh bGwsPGJyPg0KPGJyPg0KSSBoYXZlIGp1c3Qgc3VibWl0dGVkIHRoZSBkcmFmdCBmb3IgTkFUNjQg b3BlcmF0aW9uYWwgY29uc2lkZXJhdGlvbi48YnI+DQpUaGUgaW50ZW50aW9uIGlzIHRvIHByb3Zp ZGUgY29tcHJlaGVuc2l2ZSBjb25zaWRlcmF0aW9ucyBmb3IgTkFUNjQgZGVwbG95bWVudC48YnI+ DQpUaGUgZGV0YWlsZWQgaW5mb3JtYXRpb24gaXMgbGlzdGVkIGF0IGJlbG93PGJyPg0KPGJyPg0K QSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJu ZXQtRHJhZnRzIGRpcmVjdG9yaWVzLjxicj4NCjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyBU aXRsZSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDogTkFUNjQNCk9wZXJhdGlv bmFsIENvbnNpZGVyYXRpb25zPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7IEF1dGhvcihzKSAm bmJzcDsgJm5ic3A7ICZuYnNwOyA6IEdhbmcgQ2hlbjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNw OyBGaWxlbmFtZSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs6IGRyYWZ0LWNoZW4tdjZvcHMt bmF0NjQtY3BlLTAzLnR4dDxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyBQYWdlcyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDogODxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNw OyBEYXRlICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiAyMDExLTEw LTMxPGJyPg0KPGJyPg0KICZuYnNwO1RoZSBkb2N1bWVudCBoYXMgc3VtbWFyaXplZCBOQVQ2NCB1 c2FnZXMgb24gZGlmZmVyZW50IG1vZGVzLCBpbg0Kd2hpY2g8YnI+DQogJm5ic3A7TkFUNjQgbWF5 IHNlcnZlIGZvciBhIGxhcmdlLXNjYWxlIG5ldHdvcmsgb3Igd291bGQgZ2l2ZSBlbnRlcnByaXNl DQpvcjxicj4NCiAmbmJzcDtyZXNpZGVudGlhbCBzZXJ2aWNlIG9wcG9ydHVuaXRpZXMgdG8gYmUg YWNjZXNzZWQgYnkgSVB2NiByZW1vdGU8YnI+DQogJm5ic3A7c3Vic2NyaWJlcnMuICZuYnNwO1Ro ZSBkb2N1bWVudCBoYXMgZGVzY3JpYmVkIGRpZmZlcmVudCBvcGVyYXRpb25zDQpmb3I8YnI+DQog Jm5ic3A7ZWFjaCB1c2FnZSBhbmQgcHJvcG9zZWQgb3BlcmF0aW9uYWwgY29uc2lkZXJhdGlvbnMg Zm9yIGVhY2g8YnI+DQogJm5ic3A7cGFydGljdWxhciBOQVQ2NC1tb2RlLjxicj4NCjxicj4NCkEg VVJMIGZvciB0aGlzIEludGVybmV0LURyYWZ0IGlzOjxicj4NCmh0dHA6Ly93d3cuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWNoZW4tdjZvcHMtbmF0NjQtY3BlLTAzLnR4dDxicj4NCjxi cj4NCk1hbnkgdGhhbmtzPGJyPg0KPGJyPg0KR2FuZzxicj4NCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KdjZvcHMgbWFpbGluZyBsaXN0PGJyPg0K djZvcHNAaWV0Zi5vcmc8YnI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3Y2b3BzPGJyPg0KPGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHByZT4NCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUmbmJz cDtJbmZvcm1hdGlvbiZuYnNwO1NlY3VyaXR5Jm5ic3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2lu Zm9ybWF0aW9uJm5ic3A7Y29udGFpbmVkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNw O2lzJm5ic3A7c29sZWx5Jm5ic3A7cHJvcGVydHkmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRl cidzJm5ic3A7b3JnYW5pemF0aW9uLiZuYnNwO1RoaXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNh dGlvbiZuYnNwO2lzJm5ic3A7Y29uZmlkZW50aWFsLiZuYnNwO1JlY2lwaWVudHMmbmJzcDtuYW1l ZCZuYnNwO2Fib3ZlJm5ic3A7YXJlJm5ic3A7b2JsaWdhdGVkJm5ic3A7dG8mbmJzcDttYWludGFp biZuYnNwO3NlY3JlY3kmbmJzcDthbmQmbmJzcDthcmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQm bmJzcDt0byZuYnNwO2Rpc2Nsb3NlJm5ic3A7dGhlJm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNw O3RoaXMmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7dG8mbmJzcDtvdGhlcnMuDQpUaGlzJm5ic3A7 ZW1haWwmbmJzcDthbmQmbmJzcDthbnkmbmJzcDtmaWxlcyZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7 d2l0aCZuYnNwO2l0Jm5ic3A7YXJlJm5ic3A7Y29uZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7aW50 ZW5kZWQmbmJzcDtzb2xlbHkmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNw O3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtvciZuYnNwO2VudGl0eSZuYnNwO3RvJm5ic3A7d2hv bSZuYnNwO3RoZXkmbmJzcDthcmUmbmJzcDthZGRyZXNzZWQuJm5ic3A7SWYmbmJzcDt5b3UmbmJz cDtoYXZlJm5ic3A7cmVjZWl2ZWQmbmJzcDt0aGlzJm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vy cm9yJm5ic3A7cGxlYXNlJm5ic3A7bm90aWZ5Jm5ic3A7dGhlJm5ic3A7b3JpZ2luYXRvciZuYnNw O29mJm5ic3A7dGhlJm5ic3A7bWVzc2FnZS4mbmJzcDtBbnkmbmJzcDt2aWV3cyZuYnNwO2V4cHJl c3NlZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21lc3NhZ2UmbmJzcDthcmUmbmJzcDt0aG9zZSZu YnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO3NlbmRlci4NClRoaXMmbmJzcDtt ZXNzYWdlJm5ic3A7aGFzJm5ic3A7YmVlbiZuYnNwO3NjYW5uZWQmbmJzcDtmb3ImbmJzcDt2aXJ1 c2VzJm5ic3A7YW5kJm5ic3A7U3BhbSZuYnNwO2J5Jm5ic3A7WlRFJm5ic3A7QW50aS1TcGFtJm5i c3A7c3lzdGVtLg0KPC9wcmU+ --=_alternative 0004408548257945_=-- --=_related 0004408448257945_= Content-Type: image/jpeg Content-ID: <_2_06B641C806B63E0C0004407C48257945> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAMgAA/+4ADkFkb2JlAGTAAAAAAf/b AIQACAYGBgYGCAYGCAwIBwgMDgoICAoOEA0NDg0NEBEMDg0NDgwRDxITFBMSDxgYGhoYGCMiIiIj JycnJycnJycnJwEJCAgJCgkLCQkLDgsNCw4RDg4ODhETDQ0ODQ0TGBEPDw8PERgWFxQUFBcWGhoY GBoaISEgISEnJycnJycnJycn/8AAEQgAfwCGAwEiAAIRAQMRAf/EAKAAAAEFAQEBAAAAAAAAAAAA AAADBAUGBwIBCAEAAgMBAQAAAAAAAAAAAAAAAwQAAgUBBhAAAgEDAQYDBAkEAgIDAAAAAQIDAAQF ESExQVESBmEiE3GBMkKRobHBUnIjFAfRYjNDgiSSooMVFhEAAQQABAIIAwcFAAAAAAAAAQARAgMh MRIEQVFhcYGRIjITBaHBFLHRQlKCojPwYpIjNP/aAAwDAQACEQMRAD8A3+iiiooiuXkSNGkdgqKN WYnQAeJNMctl7DC2T31/KI4k3D5mbgqDiaxXuru/Kdyu0JZrXGg/p2iHQuOczDf7KY2+1nccPDEZ yPyQrbo1jmeACmM7/JeZxmburfFXNrkcerAxOUYFSd8fUp29POlsb/LmVu7m3snw8c01w6xIIZSC Sx03OtZ1HZyTypbW8bSytsjijGrH2KKvv8V9umfKT5u6TSOx1ht1Yf7jsc/8RsrTuo2tVJlKAJjH qkTwySNdt87ABIgSPYBxWwoWKgsOltBqN+h5V0TpRqBtJ0FIyXlpF/kmRfawrEYnJaa7Z6RZ68GR xz7BcxE/mFKhYJRqhDDmp1+yuSjLqXHfJIeqy/C2ntrpbwDZINPEUS2rb0bX+00wl64z0uND40GU pRxXCSFMK6uOpTqOddVApcSQt1Rtt4jgalLS9juRp8Mg3ofuq0LRLDIqCQKdUUUUVWRRRRUURTTI ZC2xlnLe3bhIYhqeZ5KPE07rLe9My2VvTZQN/wBO0JGzc8o3sfy8KLRV6sxHIDEnoVJz0xfjwVa7 hzN73DetdXJ6YkOltb6+WNfvY8aSwvbl/wBwXf7WyXpRdPXuG+CMHnzbkKeYvDXGXvo7K22M215C NiIN7GtbtLTG9t4sRRARW8I1ZvmdzxPNmrRu3ApiK6gNTYDl0paNWsmczhxTXB9tYfti2LQKPW01 nvJdOtvfwHgKayZm2tA9vhbZVVnZ3l00Uux1ZgvHWo+8yFxl5dZNUtwf04B9rczS9taagbKT0HGV pMpHEgldlblGoMBxTeaXIXe24ndgflB0X6BTR7AHaw19u2rMmOfo6iui868axXd061YWxGAYdSoa 5nN1UJsen4fqpmVu7Ruu1nkhP9jEVcriw6RqyaciaibmyG3ZRoWg4HFAnGcMk0su+MrYOI8jGLyA b3A6ZB9xq64zMYruC2L2kglA/wAkTbHQ8mXfWb3tnprsqE9S7xl0t7j5WguIzsdeIHBhxFSe0rtD waJ+HcpXvpxOmzxDpzWt31m9uDIvnh+tajhM0bK6HR1+FqW7S7ttu5LdreYCLIwD/sW/Bhu9SPmp +qvctZftG9SPbbvs0/CeVYW7286icG05jl0p5xKIsgXBUzjsgl7HodkqbHX7xT6qPBdyWs63EZ8y 7xzHI1cradLmFJ4jqjjUf0q+3v8AUDHzD4jmr1z1BuIS1FFFMIih+5Mgcdi5ZIzpNL+lF7W4+6su MOm0+88Sauvd8xmvIbYfDCvUw/ubdURiMcL7J28DjWMN6kn5U2/Waf27V1ajxxPVwQbPFJuxWntL DLi8eJpV0uroCSVjvC/KnuFQWayzZa+MMZ/6du3Sg/Ew2F/6VYe68mcdiXEZ6Zrg+jFpw1+I+4VT cXGCVGmwVSmJmZXzxJJZB3Nmlqo9qmbKDdrVgtbcIodhpr8I40zxdsJOqWT/ABptbxPKpJX626tw 3AchQrZuSFamGAJ45JwA7gdR2eFcOrKdhpVG0FcSEUBM8ElJMJF9OVdfGmM1hHOD6DeYfId9OZNK SaOSVDJFr1x8Rv0q4LZFCkNWBDqt31myFlddGG8GqvkrTQEgVpPq298v7a90WXcko51Vc1jpLWRo pR4ow3MOdN7e/EA5rN3NDDVHEfZ1rPP3N3iL6LJWLmO5t26kPAjijc1YVt+Gyln3ThIr6IeS4Xpl j4pINjKfYaxnLQdPUam/4rzRss3cYOVv0L5TLCp3CZB5tPzLTG9pjbT6gGMRj0x4hc9vvMZmqRwl 9qs13E9rPJbyfFGdCeY4Gpfti/0lksXOxv1Itf8A2Fc92W3SYb1fm/Sf7VNVy0uza3sFyDp0ONfy k6GvImX0+4zwB/aU6ZenZ2/ArTdaK4616PU18unVr4b6K13HPpTjhUrLKZsjcudvm6R/x2U/7Wtg txcTkbVVUX3nWkbmIm4mJ4ux+upbAJ0RT8yw+oU3ZL/U3QAqAeJVLv28MmYtbIHywReoR/c5/oK4 w8bO6qo1JFRPdsxfu28VvkEaj2dOv31aezHhMrqwHX06qTwAo8ho28G/KD3rOf1N0QS3ibuU+6i1 t4rRfi06pD417G3AVzesr3WibToBXaMsOnzSfUKzyU8M+gYJ0iMRqx6R416zwJu85pqZXf4jr4cK 5LVTUr6uSWe5Pyoo91cR3rrIA/wnYQBpSDGkJDU1BUMjmvL8hZnV41IO1eFcxpDl4Wx9wSHUdUMh 3jw1pbJDqign/EOk1DSO8R642KuNoYcKvGWKDYdMi4cHMcwqf3Jj3sbiS2l+JePMc6p9hePjM7j7 5D0m3uIySN+hbpb6jV/7ll/fRx3cn+Rv0pTyZd301mmQ8rsw3qdR7jW3tiZ1NLiGKyi0NwDDJ8Op fRncUS3GFuGG3pUSqfYdfsrOZH1U+I+ur7kcna22DijuiVa6tgsZ6SQWMY8uo3VnLPoNPdzrxPus oi6LFzpY9nNaO8kNQY8MVpX70/8A5f8Aea+b9tv8dOmiq4mYs37Plx6SFruKEeogU6KDIANW06du vOijfVRZ9Y/5nz/Hk3WievHPUP4nz/FkrDcwaTyfm1+mneJXo9Veehpa4h1k151zbL6c3gw0PurZ MniybbFZR3uDbd43Ou6aOKRfHZ0/dU52tcBBczcUi2e+mv8ALFi0N1jsyg0Rg1tKfH40++kezFuL 2K99FdVSIFz7NtPE6trCXIaT1jBZcgYbuQxxJkO5Xi0dpbQMNDcKvm59Jr1ZBULi8i0cglX4tdq8 xyqenhSaL95Z+ZDtkjG9TxrMsiQSE1XPVFxmMx814JPGgyUy9WvDMKHpXfUCdmQc6TaQGmplrky+ NQxXDYpS5IbFRNxV9PtqCuTopJqSuJgMTCvFpD9VQN9cdKdI2sdgHjVogmQZDvkP2hc47FQZWDIv dSFIYV6ht3OASGNZPdp610kCeYySLGvj1OFFXfKXktjFLaJIVaVC1yFOw6jyqfZUF2bjTme7rCDp 6ooH/czeCRbR/wC2lbO2euudkjgA4HUkgIzsqhGLEEueb/ct1usXBfYtcfcL5RGqqeKsoADD2Vlt 3jL63yRxbRl7kt0RgbnB3OPDnWw7aSa0t2uEu2jU3CKUSUjzBTvArze82UdwYyfTIHEtnHiFqX7Y W6S7EHPoVei7Ujh7enxkbAXdyqtLPpvkVhIo/KCulFWfQ0UT6Ohm04en6f6Xfvfir+hVlpHl0fpQ yht9JmLlStFMoqhO6cIvcODu8adkrr127n5ZU2ofprGu2cxf4i5nsyxgeTW3uojvDDVTv5GvoCsu /kftCT1j3PioixGhyUCfEwX/AHKBxA+KndnbHGizyzyfISSW9qkQLYeaGbclH2F/0noY7QdCfEVZ sdl5Ldw8Z1B2Oh3MKqOVyuByEVjc4RfSuCvTdx6dI6gB9dJwZB00DgqfGi2bczGpjE8jms8XGqbC QLcRktIdbTJKZrJhHcb3hbZqfCoqZpIHKSqUbxqvRZMghgxBG5gdDUkncjugiu0W4Tdq2xh76W+m mODop3Vc8zpPMZdycmeuWnpqLvH3TBbb1Ukb/Wq9e33VOY3tyafSa9YpDvVCNGI8apKsR82C7DXY WraXSDgEzv7khLW0jHXIqa9A2nqaoy/lTERetcEPfOP0YN/Rr8zU/wA5nMdhZ5bfHJ6t43+S4baF 4dIrPcjkZJ3eWRizudWYnUk0xt9sZESIYHmqbi2MZEahKWWGUfvTTJXjN6rs3Uz/ABNx8a0f+JcC 1njJs7coVnyJ0h12EQIfL/5HbVI7R7Wn7tyQMqlcTbMDdzbg5H+lD9tbuiJBGkMShEQBURdwUDQC i760Qj9PDMsZdA4BH9vpON0uPlf7UtRXg3V7WYtNFFFFRRFFFFRRedQrhpItCGZdDsIJG6ofuqyk vcNOIGZZoR6sZUkE9O9dnhWUxTSu3mkc+1j/AFp/abD6mEpizTpLEM/asf3L3c7K6FRo1icXEtTD kQzFWHur+PVkmlyfa/QzN57nHBhoxPzRcj4VSIr+5tZGtrlCHjOjwTroy6cNDtrRO2s9b4pGguIN UkOrTptf2MDv0qx32K7Z7siBuEjncDyyoeiZfeNGpg3Wbc+nuImysYRsbFkKMKt5AW0SjXaQ8q3w WUw5KxO2Wz2/2ORT+LMYWLb/APWGUjhJKdKmr7+K5UYvishqvCK5XU+zrWoeb+P+6YCemCKYDcY5 Rt9zCjRs2dg/kAfgSYoEttvKz/E/SIifyTtO9buFfSxlnbWY/Gq9TAeJNR133TlZSdb2RifjfXQH XgANwpSPsbu2UdAs0iB/HKo+nTWpK0/i7LTEG/vYrdOKwgyN9LaCuE7GvxaodniPzXRX7hY0dM2/ wj8lSbm+LFndtSx2niTU9232FlO4XS6yCvY4w6Esw0mlHJBwB/Ea0PFdk9t4Iicx/ubof77k9ba/ 2ruFTb3vUOmEaKNnUfuFAt3zjTtokf3nDuCb2/twgdW4kJH8gx7yvbKzssPaRWFhEsMEI0SNPtPM njS6kkknfTVNu3fzNO4kJ8x3VnSDOSXJzK1Il8AGAyCWXdXtFFDREUUUVFEUUUVFFyVBBDDUEaEV nx7EuZJ72SOVYgspNmjDUOp83m5cq0OudPEeFHo3NtGr0y2pnwfJKbvY0brR68TL03IYt5h/RWT3 GOvsc/p3kLRnXY29T7G3UpCzIQyMVI3Mp0+ytPnFv6TC6Kel83qadPv6qgLjFdr3BLRXUMD84pk0 1/KSRT0PcoyDWwIPExxHcs2Xs06y9ExIcBLA96iLXM5OEAC4ZlHBwG+2pKPuHIaeYI3joR9lN3wl op/Qyluw5O6g/SGrwYxl3Xdqw5+qKrKW0lj4XPQyLCvewwOvv1fen4zt624IvsH9aDkLyUeaUgHe F2U3jx543NuP/kWnsOPh/wBl5F/xYH76ETt45aewOmIx3MvNq7SySUknUnU8SdtO4I3kPkXX7Kcw 22Pj01lRzzZx9lP06On9PTp4abqDO4ZRCYhQc5FIQ2oTQvtPKnIoooBJOJRwAAwRRRRXF1FFFFRR f//Z --=_related 0004408448257945_= Content-Type: image/jpeg Content-ID: <_2_079B6C48079B688C0004407D48257945> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAPAAA/+4ADkFkb2JlAGTAAAAAAf/b AIQABgQEBAUEBgUFBgkGBQYJCwgGBggLDAoKCwoKDBAMDAwMDAwQDA4PEA8ODBMTFBQTExwbGxsc Hx8fHx8fHx8fHwEHBwcNDA0YEBAYGhURFRofHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8f Hx8fHx8fHx8fHx8fHx8fHx8f/8AAEQgAIgBjAwERAAIRAQMRAf/EAJQAAAIDAQEBAAAAAAAAAAAA AAYHAAUIAQQDAQEAAwEBAAAAAAAAAAAAAAAAAwQFAgEQAAEDAgQDBAYDEQEAAAAAAAIBAwQFBgAR EgchExQxQSIIUXGBMrIVUiMXkaFCcjNTczR0tDV1hcUWRjdjEQABAwQBAwMFAAAAAAAAAAAAAQID ETESBCFBgQVxwROxIoJDNP/aAAwDAQACEQMRAD8AOL4uneOJdlRjURqYVKbcRIhNwhdBR0Cq5Hyy 1eLPvxq68UCsRXUy9SrI5+XFis283Qvyr3rTKZUKjzoj7jgvsoy0KrpaMu0QRUyIcSbWpG2NVROT mKVyuopV1PczeKlqK1F+RCB1SRlZENttC09unU2meWeJWa0Drc9zlZXpcILRvbdSW1UplVKQlObp MuXElHFBtpXgb1MkLiAiF6UTPjivsQQpRG3yTqdse+62oDdN3L3hqiH8tlSZqtZc3p4jTunVnlq0 trlnliw/VgbfjuRpK9bDbsK7KjFs4qnf00aZIWYbIv1Llwk0qiK2PjRsePiy9OMrbaxH0ZahaiVy pyL/AMxO+J0W26XI2/uiC5UHZihMSG5FmFyeUS+IF5ulNSJxyxWJRl0HdSwXqNTnJl1UnrnYzJSR KbGEuaTYqaKOtMl1d2WAKir70Q4e6S7ddEcefJhK7TalJXTHemGCmy0iJxVskRU15+8mnLvwAPbI by1e5LPuubdhNjWLZefemCAo2IR+WTgCgp9AmjHjmvBM1zwBeeXvcu49wLIdq1djMsyo0o4gyGMx F9AADU+WuelU15LkuXqwAyKo641TZbrZaXG2XCAvQQgqouAM/faXfXyXqPmznN+UdVq5bX5b5r0/ M/J/m+GWAG9uhcf+P2VUJjZ6ZTwdLD9PNe8KKn4o5l7MT6kWciJ0I5XYtFh5dra51Rn3E8OYRB6S Iq/nHEQnST8UMk9uNHykvCMT1INZt1LHzK/qtv8A6ST8LeOPFXd2PdmyBbD/AOIj/IS/dlxVX+j8 vcl/X2FDtJuJSbNWprUY8h/rkZ5XToC5crXnq1kP0+GNTd1XS0x6VKsMqNue3zL3TBunYiPV4TTj MdyrsgIPIKHm2Lwr7qkn38Yk0SxuxUusfklRJ7kbOUm1NsLUvCLUH5Mq4hYJ+K6II23zo3PXQo+J cl4ccRnR9t39nKTYFJtCowqhImncAK682+ICLagDJ5Dp/TL24AZ/mbrVmTrpttyl1+PTrxt2e3Hm k6D6dOyuT4OmQtkhIyYouQKq+LAAHeNy2jQ2twajbNzR6m9e7vTs0qIxIDkx3nuofedN0GxT8NsQ HPgeeeAND+W2q2V9nkC3bfqbVQn0pgHq0jQOjokSyNwkVXADVkWoUVPo4AZ9Z/hE79nd+BcAZb/1 7+gf3rABf5h7kWVW4Nvx1Uggh1EgE733uAD60D4sbXjIqNV6lPZdzQbe3lt/45aNPphDpkC3zZa+ l93xuZ+pV0+zGXsy/I9XFmNuLUQXPmV/VbfX/wBZPwt4v+Ku7sQbVkC2H/w8f5CX7suKrv6Py9yT 9fYWextnW5chVlK3CSYkVI/I1EY6eZzNXuEPbpTGh5Cd7McVpcrwMR1al55htuZL+z6UKzqW490s 9qZ0EfU65o+sRwgElIyXU4i5JjGdI561dcutaiJRDNG4txbtv2XQrdvCjPUyhUhW2aW4/CcjERMs q0Iq4eSGvL7fu45PS0u09979gUCNV7WnOQKQKJTnI1OfBFbcFsdSlkSEii2PHADF801pbXUFXa6+ 3IlXtX3m3W4iSFFsWm9Iuum2iZiKiGgePvLw7FwBXbv7M7d2htlCuumUOorLnHE5zEmTwiC+iOGj yCPbw5XDsJfZgB2bD2TtrSLfW47FN8odfaZJ9JD3OUCZ1fVqmSaTAnCEsAMas/wid+zu/AuAMt/6 9/QP71gAvvLZy/qlddTqcXkSWZcgnmHieRs0FfcFRVOCgiInsxsQb0bWIi9Cm+ByrU9FpbZboU+6 aXOqL6lBjSAckp1pOZgnb4FXxerHOxtQuYqInPoesieioqhZvRY1w3WxSW6M224UM3if5riN5I4I IOWfb7q4raOw2JVy6kk8auRKBHTrbnJtw1bshRZnLTVhOEi6wFxWlDPNO1EXELpU+XNLZVJEb9tB Jx9ld04ikkXls6uBKzM5aFl2Z6dOftxrrvwrf6FT4HpYcW1Vv3DQrZODXzU5yyXHEJXVf+rJBQfG vqXhjJ25GPfVlqFqJqonIHeZrba7L9tik06247ciTEmrIfF10GUQOSQZopqmfEsVyQalvxH4dBps OQiC/GisMvCi5ohttiJIip28UwAo5Pl4bq29k6+q9M62jCTMinU1wicJXwBE0uauCMtGOoQTt7Ox OIDbuK36XcFFm0aqMo/T57RMyWl7xLvRe4hXiK9y8cALjYjZuobbFcTD9SKbBnSQWmNoRIKMgK/W G37ovEpaSy7hTADPqjZuUyW22Kk4bLggKdqqoKiJgDO/2f3r8k5HyWRzfk3T6PDnzvm3P0e928vx YA0lgCYA5gDuAJgCYAmAJgCYAmAJgCYAmAP/2Q== --=_related 0004408448257945_=-- From phdgang@gmail.com Thu Nov 10 22:17:40 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A67F71F0C48; Thu, 10 Nov 2011 22:17:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.022 X-Spam-Level: * X-Spam-Status: No, score=1.022 tagged_above=-999 required=5 tests=[AWL=-4.130, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_46=0.256, J_CHICKENPOX_13=0.6, J_CHICKENPOX_45=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id woOvtRlyO--k; Thu, 10 Nov 2011 22:17:39 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7ACC01F0C35; Thu, 10 Nov 2011 22:17:39 -0800 (PST) Received: by wyf28 with SMTP id 28so1865317wyf.31 for ; Thu, 10 Nov 2011 22:17:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=wDWHnUfjHxfjb1sKZi/eFPLrtkT5tbZEdUhDWdOW5zI=; b=tQr9a3tFs2bVXXHEVWmoKmKbKT3CDmDMqpFnBchasG6OuSXVHJMMeFj47NseSXvEKZ ljVs95M/mth/J14DCv+foxU57QUwA5ceMWLajvIvVDJzhKyC9tUTwHq0fg6EVIRjz6na pdjbiHu7tufObszT3f6oSZf4BRZma1lmMHekg= MIME-Version: 1.0 Received: by 10.180.90.148 with SMTP id bw20mr12596642wib.33.1320992258623; Thu, 10 Nov 2011 22:17:38 -0800 (PST) Received: by 10.180.102.8 with HTTP; Thu, 10 Nov 2011 22:17:38 -0800 (PST) In-Reply-To: References: Date: Fri, 11 Nov 2011 14:17:38 +0800 Message-ID: From: GangChen To: niu.qibo@zte.com.cn Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Cc: v6ops , v6ops-bounces@ietf.org Subject: Re: [v6ops] =?gb2312?b?tPC4tDogTkFUNjQgT3BlcmF0aW9uYWwgQ29uc2lkZXJh?= =?gb2312?b?dGlvbnM=?= X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 11 Nov 2011 06:17:40 -0000 Hello Qibo, Thanks for the comments. That is a good suggestion. I will update in next version. BRs Gang 2011/11/11, niu.qibo@zte.com.cn : > Hi, Mr Chen > I have read your draft, it covers most scenarios; > CGN hot-standby mechanism, Lawful interception (CC-IIF), user traceabilit= y > and sceurity (TCP Track and Anti-DDOS) may be considered in "NAT64-CGN > Mode Requirements" > Thanks! > > > > Niu Qibo =C5=A3=C6=F4=B2=A8 > Bearer Networks Product Planning System Dept > > Product Marketing System > =B2=FA=C6=B7=CA=D0=B3=A1=CC=E5=CF=B5 > 5/B,N0.68 ZiJingHua Road,YuHua District,Nanjing,Jiangsu P.R.China, 210012 > Tel:+86-25-52870483 > Fax:+86-25-52870653 > Email:niu.qibo@zte.com.cn > > > > > > > GangChen > =B7=A2=BC=FE=C8=CB=A3=BA v6ops-bounces@ietf.org > 2011-11-03 10:00 > > =CA=D5=BC=FE=C8=CB=A3=BA v6ops > =B3=AD=CB=CD=A3=BA > =D6=F7=CC=E2=A3=BA [v6ops] NAT64 Operational Considerations > > > Dear all, > > I have just submitted the draft for NAT64 operational consideration. > The intention is to provide comprehensive considerations for NAT64 > deployment. > The detailed information is listed at below > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : NAT64 Operational Considerations > Author(s) : Gang Chen > Filename : draft-chen-v6ops-nat64-cpe-03.txt > Pages : 8 > Date : 2011-10-31 > > The document has summarized NAT64 usages on different modes, in which > NAT64 may serve for a large-scale network or would give enterprise or > residential service opportunities to be accessed by IPv6 remote > subscribers. The document has described different operations for > each usage and proposed operational considerations for each > particular NAT64-mode. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-chen-v6ops-nat64-cpe-03.txt > > Many thanks > > Gang > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail i= s > solely property of the sender's organization. This mail communication is > confidential. Recipients named above are obligated to maintain secrecy an= d > are not permitted to disclose the contents of this communication to other= s. > This email and any files transmitted with it are confidential and intende= d > solely for the use of the individual or entity to whom they are addressed= . > If you have received this email in error please notify the originator of = the > message. Any views expressed in this message are those of the individual > sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam syste= m. > From joelja@bogus.com Thu Nov 10 22:51:24 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA2A1F0C61 for ; Thu, 10 Nov 2011 22:51:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.23 X-Spam-Level: X-Spam-Status: No, score=-101.23 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, 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 soz2paRTl8KU for ; Thu, 10 Nov 2011 22:51:23 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 9166C1F0C5F for ; Thu, 10 Nov 2011 22:51:20 -0800 (PST) Received: from Zorch.local ([210.229.158.64]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id pAB6nruZ087793 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 11 Nov 2011 06:50:01 GMT (envelope-from joelja@bogus.com) Message-ID: <4EBC6599.6030002@bogus.com> Date: Thu, 10 Nov 2011 16:00:25 -0800 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Qiong References: <4EB05384.5000007@gmail.com> <4EB54C85.4050909@bogus.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 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, 11 Nov 2011 06:51:18 +0000 (UTC) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Fwd: New Version Notification for draft-sunq-v6ops-contents-transition-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: Fri, 11 Nov 2011 06:51:24 -0000 On 11/7/11 22:13 , Qiong wrote: > Hi, Joel > > On Sat, Nov 5, 2011 at 10:47 PM, Joel jaeggli > wrote: > > > After all, dual stack is what we have discussing for 10 years. But > up to > > now, how many ICPs have upgraded to IPv6 in dual-stack directly? I > > really think we need to re-think it again, from both technical aspect > > and the industry/or market aspect. And the first step is rather > > important to give us confidence to move forward. That's why we > recommend > > single-stack (either v4 or v6) transition in the current phase. Then, > > for the conservative ones, the IPv4 services can be still offered > > natively, and the IPv6 services can be offered by the stateful NAT64; > > while for progressive ones and newly comers, the stateless IVI can be > > employed to offer native IPv6 services reachable via IPv4. And we hope > > it would help enrich IPv6 content asap. Then how do you think ? > > Any solution that causes me to lose access to the source address is not > usable from my vantage point as a content provider. When I terminate > connections on an l7 load balancer as I generally do for http/https on > ipv4 and where we do it in ipv6 I can drop x-forwarded for in there. > That requires that I recieve the traffic unmolested by a nat transform > associated with my own service. > > I agree it is important. But there is another question here : although > you can use l7 load balancer to insert x-forwarded here, how can you > guarantee that there is no CGN along the path from the user's end-host > to the data center. I don't have to, what I need is a granular enough view of where the address sharing is occuring that I can serve my content accordingly. it's not a problem for example if ~200,000 mobile users of an app at Indonesia's 3rd largest mobile operator emerge from behind a /22 > I mean, in case we cannot avoid deploying some kind > of address sharing mechanisms in the future, ICPs have to face the fact you'll note that I'm assuming the existence of address sharing mechanisms on both sides of the conversation. I'd very much prefer that the one working on my behalf not necessarily throw out information as a product of it's design. > that they will somehow lose the geo-location info when they receive IPv4 > traffic. So maybe it is one choice to provide them with a database which > stores the original binding information. Would it be some kind of helpful ? where are you going to put that and signal it? > Thanks > > Best wishes > > Qiong > > > > > Thanks > > > > Qiong > > > > > > On Wed, Nov 2, 2011 at 4:16 AM, Brian E Carpenter > > > >> wrote: > > > > I'm not seeing why this is a better solution for a > small/medium ICP > > than just moving to a dual stack. That is much easier for a small > > network than for a big one. > > > > Regards > > Brian > > > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > From joelja@bogus.com Fri Nov 11 00:18:09 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB471F0C63 for ; Fri, 11 Nov 2011 00:18:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.615 X-Spam-Level: X-Spam-Status: No, score=-101.615 tagged_above=-999 required=5 tests=[AWL=0.385, 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 G-DUpRfqFrjY for ; Fri, 11 Nov 2011 00:18:09 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 2B8711F0C61 for ; Fri, 11 Nov 2011 00:18:08 -0800 (PST) Received: from Zorch.local ([210.229.158.64]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id pAB8I5iR089427 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 11 Nov 2011 08:18:07 GMT (envelope-from joelja@bogus.com) Message-ID: <4EBCDA38.4050808@bogus.com> Date: Fri, 11 Nov 2011 00:18:00 -0800 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "Hemant Singh (shemant)" References: <4EBC094A.6050608@bogus.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3034945F0@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3034945F0@XMB-RCD-109.cisco.com> 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, 11 Nov 2011 08:18:07 +0000 (UTC) Cc: IPv6 Ops WG Subject: Re: [v6ops] V6ops sessions could use a scribe. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 11 Nov 2011 08:18:09 -0000 Thank you. joel On 11/10/11 12:55 , Hemant Singh (shemant) wrote: > I can volunteer to be a scribe except during presentation of the > rfc6204bis document when I may need to comment at the mic. > > Thanks, > > Hemant > > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Joel jaeggli > Sent: Thursday, November 10, 2011 12:27 PM > To: IPv6 Ops WG > Subject: [v6ops] V6ops sessions could use a scribe. > > Our meetings are: > > WEDNESDAY, November 16, 2011 0900 > THURSDAY, November 17, 2011 1300 > > While we have a good track record with lining up volunteers, and I > generally take speaking notes to the jabber room as well you might > consider whether you'd assist the relevance and accuracy of the minutes > by taking notes. > > You can if you are so inclined use the v6ops etherpad in the interests > validating that experiment. > > http://tools.ietf.org/wg/v6ops/minutes > > thanks > joel > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From Carl.Wuyts@technicolor.com Fri Nov 11 04:20:32 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3B7221F86D0 for ; Fri, 11 Nov 2011 04:20:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.289 X-Spam-Level: X-Spam-Status: No, score=-4.289 tagged_above=-999 required=5 tests=[AWL=-0.711, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uOKwUZ3QvsCb for ; Fri, 11 Nov 2011 04:20:30 -0800 (PST) Received: from na3sys009aog122.obsmtp.com (na3sys009aog122.obsmtp.com [74.125.149.147]) by ietfa.amsl.com (Postfix) with ESMTP id 2B4F221F86EC for ; Fri, 11 Nov 2011 04:20:26 -0800 (PST) Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob122.postini.com ([74.125.148.12]) with SMTP ID DSNKTr0TBit9YnowXEAq1UmF5RdzZyuH8mTH@postini.com; Fri, 11 Nov 2011 04:20:28 PST 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.192.1; Fri, 11 Nov 2011 13:18:55 +0100 Received: from MOPESMBX01.eu.thmulti.com ([169.254.155.121]) by MOPESMAILHC02.eu.thmulti.com ([141.11.100.29]) with mapi; Fri, 11 Nov 2011 13:19:04 +0100 From: Wuyts Carl To: Lorenzo Colitti Date: Fri, 11 Nov 2011 13:19:01 +0100 Thread-Topic: [v6ops] RFC6204bis-02 Thread-Index: Acyf+grlhXNcIYJARcakpc/bIQWN0wAcPLPg Message-ID: <867F4B6A1672E541A94676D556793ACD0C27516166@MOPESMBX01.eu.thmulti.com> References: <867F4B6A1672E541A94676D556793ACD0C263BD0F3@MOPESMBX01.eu.thmulti.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/related; boundary="_006_867F4B6A1672E541A94676D556793ACD0C27516166MOPESMBX01eut_"; type="multipart/alternative" MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] RFC6204bis-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, 11 Nov 2011 12:20:32 -0000 --_006_867F4B6A1672E541A94676D556793ACD0C27516166MOPESMBX01eut_ Content-Type: multipart/alternative; boundary="_000_867F4B6A1672E541A94676D556793ACD0C27516166MOPESMBX01eut_" --_000_867F4B6A1672E541A94676D556793ACD0C27516166MOPESMBX01eut_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Lorenzo, PPP indeed is a good example, and yes, IPVPv6 could potentially trigger DHC= Pv6 PD, but no, this is not a good idea. It's remarkable to see/hear alway= s: "CPE not ready", "CPE the issue in IPV6", but it keeps coming back to th= e CPE having to adapt. You suggest to listen to IPCPv6, possible of course= , but yet again another mechanism ?? Listen to RA for auto-injection of th= e default route is ok and commonly agreed upon, in fact, we support it, but= we also support to ignore them, CPE must be flexible, but your suggestion = now is to listen to IPCPv6 and then linking it to DHCP-PD ? So no, no hard= req needed to link DHCP-PD to RAS listening, not ok for e.g. PPP. And no, please do not start linking up other protocols please, it is not ne= cessary and only creates extra possibilities. On one hand, everyone expect= s the CPE do be nearly free-of-charge, but on the other hand it must be cap= able of supporting all kind of scenario's ?! What's next ?? I agree on the more-specific routes. Indeed it's ongoing for some time, bu= t not yet really materialized, on the other hand, it'll come sooner or late= r so better take it into account today in describing standard CPE behavior. regs Carl Wuyts GCD System Architect Networking Connect Division carl.wuyts@technicolor.com tel.: +32 3 443 65 90 [cid:image001.gif@01CCA073.DEED5240] [cid:image002.gif@01CCA073.DEED5240] Prins Boudewijnlaan 47 - 2650 Edegem - Belgium Technicolor Delivery Technologies Belgium NV Registered office (maatschappelijke zetel): Prins Boudewijnlaan 47, 2650 Ed= egem, Belgium Company registration number (ondernemingsnummer): 0428837295 - RPR Antwerpe= n [cid:image003.gif@01CCA073.DEED5240] Help preserve the color of our world - Think before you print. From: Lorenzo Colitti [mailto:lorenzo@google.com] Sent: donderdag 10 november 2011 23:42 To: Wuyts Carl Cc: Wes Beebee; v6ops@ietf.org Subject: Re: [v6ops] RFC6204bis-02 On Thu, Nov 10, 2011 at 00:15, Wuyts Carl > wrote: 1. In case of ptp WAN link, the customer might not want to sent any R= A's at all, afterall, it is point-to-point, hence you cannot link DHCPv6 to= the RA, as ... nothing will happen then. What kind of point-to-point link? In PPP you have IPv6CP and you can use th= at as a signal to trigger DHCPv6 PD. Are there other kinds? 2. The DHCP WG is working on the options to get specific routes from = the server, similar as for IPv4, hence there is no default route issue in t= hat scenario, the route info will come from DHCPv6 in this case, not from R= A. People have been talking about getting routes via DHCPv6 for a long time, a= nd it hasn't actually happened yet. If this time the IETF does reach consen= sus on it and it becomes an RFC, then that RFC can always update this one. --_000_867F4B6A1672E541A94676D556793ACD0C27516166MOPESMBX01eut_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Lorenzo,<= o:p>

 

PPP indeed is a good example, and yes, IPVPv6= could potentially trigger DHCPv6 PD, but no, this is not a good idea. = ; It’s remarkable to see/hear always: “CPE not ready”, &#= 8220;CPE the issue in IPV6”, but it keeps coming back to the CPE havi= ng to adapt.  You suggest to listen to IPCPv6, possible of course, but= yet again another mechanism ??  Listen to RA for auto-injection of th= e default route is ok and commonly agreed upon, in fact, we support it, but= we also support to ignore them, CPE must be flexible, but your suggestion = now is to listen to IPCPv6 and then linking it to DHCP-PD ?  So no, no= hard req needed to link DHCP-PD to RAS listening, not ok for e.g. PPP.

 

<= p class=3DMsoNormal>And no, please do not start linking up other pro= tocols please, it is not necessary and only creates extra possibilities.&nb= sp; On one hand, everyone expects the CPE do be nearly free-of-charge, but = on the other hand it must be capable of supporting all kind of scenarioR= 17;s ?!

 <= /span>

What’s next ??

 

I agree on the more-specific routes.  Indeed it’s = ongoing for some time, but not yet really materialized, on the other hand, = it’ll come sooner or later so better take it into account today in de= scribing standard CPE behavior.

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'> 

regs

 

Carl Wuyts

GCD System Architect Networking

Connect D= ivision

= carl.wuyts@technicolor.com

<= p class=3DMsoNormal>tel.: +32 3 443 65 90

<= p class=3DMsoNormal>3Dtwitter

3D"Visit

Prins Boudewijnlaan 47&= nbsp; -  2650 Edegem  -  Belgium

= Technicolor Delivery Technologies Belgium NV=

Registered office (maatschappelijke zetel): Prins Boudewijnlaan 47= , 2650 Edegem, Belgium

Company registration number (ondernemingsnummer): 0428837295 - RPR Antwerp= en

Help preserve the color of our worl= d - Think before you print.

 

 

From: Lorenzo Colitti [mailto:lorenzo@google.com] Sent: donderdag 10 november 2011 23:42
To: Wuyts Carl
= Cc: Wes Beebee; v6ops@ietf.org
Subject: Re: [v6ops] RFC620= 4bis-02

 

On Thu, Nov 10, 2011 at 00:15, Wuyts Carl <<= a href=3D"mailto:Carl.Wuyts@technicolor.com">Carl.Wuyts@technicolor.com= > wrote:

1. = ;      In case of ptp WAN link, the customer might not want to sent any= RA’s at all, afterall, it is point-to-point, hence you cannot link D= HCPv6 to the RA, as … nothing will happen then.

=

 

What kind of point-to-point link? In PPP you have IPv6CP an= d you can use that as a signal to trigger DHCPv6 PD. Are there other kinds?=

 

<= blockquote style=3D'border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm= 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm'>

2.       The DHCP WG is working on the options to ge= t specific routes from the server, similar as for IPv4, hence there is no d= efault route issue in that scenario, the route info will come from DHCPv6 i= n this case, not from RA.

People have been talking about getting routes via DH= CPv6 for a long time, and it hasn't actually happened yet. If this time the= IETF does reach consensus on it and it becomes an RFC, then that RFC can a= lways update this one.

= --_000_867F4B6A1672E541A94676D556793ACD0C27516166MOPESMBX01eut_-- --_006_867F4B6A1672E541A94676D556793ACD0C27516166MOPESMBX01eut_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=1351; creation-date="Fri, 11 Nov 2011 12:19:01 GMT"; modification-date="Fri, 11 Nov 2011 12:19:01 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhGAAYAPcAAAAAAP///1Sfum/L64bW8o7h/ofU74fT7pHb9pfa8u75/VbD5VzG6FvF5l3G 513F5l/G51/F5mHH52PH6GPI6GPI52TH6GXJ6GbI6GnK6mjJ6WjK6WzL6m/M63HN6nPN6nTN63fR 7XnR7XTI5FeVqnnN537T7n7R7H/T7X3O6Y3f+4jV73m903/E2oDE2pTf+ZPc9JTa8Zfa8aDd8LDj 9MXr9+z5/er3+/r9/imy1yyx1S202S2z1zK43TW63jW32zS22Ta53Te73za32zq84Dm53Du73j2/ 4j2+4T283z273kHB5D++4EHA4kG/4UPA40K/4UTB5EbD5UbB40rJ7EjD5ErG6EnE5knE5Ua720rE 5kvG507J607I6U3G50/K60u+3U2/4U7A4k2/3lLI6E/A31XN7lHC4VnP8FfL61PD4lXD5FXF41vR 8VfG5VO92lrJ51a+21i/21/O7F7L6VnB3VzE4mHN6l/H5V3D30+lvWDH41/E4GDF4WLH42rL6GvP 6l+2znLZ9W7Q62C1zGO50HXZ9HTY83ba9XXX8mW70nLO6nHN6We803rd+HXV73zf+mm91HXS62vA 12GpvWavw2ixxVmWp2qxxYDW7X3Q52yzxm+2yW60x4HS6HC2yXG3ynzD2I7a75Xb7pvh9F+HkqTg 8ajg76ff7qri8bPo97fm9Ljm9MXw/Mfw/NDz/dDx+tbx+dz0++H1++f5/uv5/Six1S+22jG01zK1 2EXD5E/M7U7H50yvyWPY91zJ5WjZ92za927b+HHY82G4z3Xd+FurwHXa9Xfc93ne+F+rv37h+2u/ 1YDi/H7c9YHh+YLh+YXi+mqyxWuzxork+ovj+o3l+3K4ypXn+12PnJrm+qXp+63j8cLx/M/0/ef4 /Jfp+57q+6Xt/Kjv/avv/a3v/a7w/bPw/bzz/uP6/+z7/vP9/7fz/r30/sD0/sX1/sn2/tT4/9L2 /d/6/+X7/+b7/+r8/+v7/sz3/tr5/ub8/+39//v///3///7//////yH5BAEAAP8ALAAAAAAYABgA AAj/AP8JHEiwoMGCAgggOGCg4YqHEB8aOPCCAEESKmR84MABg0cOHUKGHDCAA4gEBQaOiIHBwgQO pmrQEEEhg80NGnJewACDhcAUJyBMwBArgL8ACkxc2MBUg8cLEEy0+PkhQoMZAerNmxegBoMLFChc AFsBQggXAkswerBgVYB8+eLtu7GorgcKDipIcBBi6r8SHtiyCoAPH7x6AXAoxjELRYO9IUIJlGMn jBi37zLHo2fPXj19/hT8WRMGDzGBb7LosIUqADp07WC7c9eOHbwAmnjwGBNIYBwwuHK0NleOOLnj 5MaxC+BpR64zp//JGQNkx6kA4rKXO8ede7oAe378/1BTSGCdMkNunfIXLhw4eQH6yU88KoiSImzK /8tzpkiPVP1gg4013gRgYGKmEMEEE0a4oYhAeahhhA/c8FMNNdF0s4466tyzTgCrOAFFEnA0IhAf bCQhhCkBVPMMNDDC+GI3AUiCBBNwRCJQH24wgUQmAWwjTDJEFllMNAGIcoQTdDAjkB9uODGFFLHw o00wwGSZpS/bBJDJEk80+eQvTVQhxR2zBECLK6202c0rAchCxhVR3DGJb5I0gYUXVqRBCiy1BFqL Dd+oMocVW+jyCCEC6ZEIIFps0cUXVOyCRhuYomEGFVx0wcsghlwyUC/DOHPIMcg4AskyzbS6DCSO ICSDiDOCGFNQNspUYgkmm3TCCSjXgPJJJ9NIYwklpRyk7LIDBQQAOw== --_006_867F4B6A1672E541A94676D556793ACD0C27516166MOPESMBX01eut_ Content-Type: image/gif; name="image002.gif" Content-Description: image002.gif Content-Disposition: inline; filename="image002.gif"; size=1834; creation-date="Fri, 11 Nov 2011 12:19:01 GMT"; modification-date="Fri, 11 Nov 2011 12:19:01 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhcgBFAOZ/AEGueqipqmgxkACLS4ORyPb294DFpZrMVqvi+sXr2Ie3laLXtnRHnLQlZO3J 2M+pxP7pJvqtgePqmqOIvYLKnACP1fewoXa65/vCov71sdqRnc6OpPvrlcU/benvs7qmzpzR8P/n rc7imtLntMkhU/V7Hf/yl+fZ6f3HipjL7b+MraKs1h+WXIrU9fNrPv/dkaTIrpQpd/JlIr8kXv/o ALa3uO0bLwCmUQC68pKSlf/CDgxNosvbKtvb3IzGP8nJyoiJjPaWgH+Ag3Z3euTk5Y3Y+MTfm+3t 7r/AwZubnvBSJQCZ3NLS0//eAwN+yE84la9fmdjkX//RSiPB855BhP/ILiCvY9HeRvLkCvmykSld q/aNl4Dd+cPT6O85Q2m+Q6zRONnM5OPx0PR3OR2Z2eOttkCr4Lfbm//uQPWMWbeLscPbysbs/OP1 /ZeLwPaLN9blff/iEvXlByCi3nzB69eqvN7r4uzysHfDWSCKzu+Uh8R4pR6j4IVfqm1ucf///yH5 BAEAAH8ALAAAAAByAEUAAAf/gH+Cg4SFhoeIiYqLjI2Oj5CRkpOUlZaXmJmam5ydnp+goaKjpKWm p6ipqqusra6vsLGys7S1tqF+Oat+freMubu9vorAkkhIlryqBQWXxZBEvD2VyqhEQtPJupJJScnC pzV+2dTbqdWnSX4BNTWDR+01RIUFSO0/zX/AP+1Mg/x/iLRDku9PO0JH7NXA906hv0Ho/vSId2TQ xB4Jf1gKwKujoB8deWn8OCTkkIp+gAAJGUBQjnUhgUAEB9Lkx5C58lUr8DLkSHE5Spqb1IMjkh7T evgZ4o9JyYrR/Mib2FKfHyH4kPBq1rPGkR4lH1ZjsvQH0gDIlA7RSGSlN6uC/zgCmfcjrEFeQuRd EkeO48g/IN2pQ2boasGV014+/MPRHdw/QsYZUve3wFO4R5YWBOlN3FtMfAetBJKj9EpdEQk9+/My sWRB4hxXS3koNcdpypRWnXnXMejXf4SWHt4yNcShrVkDjy1o9lDehELnXldIGfNMoV0CJxSZnGrk kpPDltpc2FZDK+eJlqwsmsx3V3trEvdXK5CKgvKJu59fLHjX5FxXjVz5fHUXEPmAJER5gkQ2UgHq uHMdJiANkcNIK+WSQ2TraaiZPv8pFyB5jxWwkoUvLWjiVUlkmE01RJQERACRISifJhxR90cBNUTG YkE1ZAgEYTnsxlgO8wSA5P8/F7pkDo8+AvFgj7wkoR5r5hChzlU1JNjkMGCGKeaYZJZp5pmqsIHA mmyCkMKbcK4g55wrfGDnnR88oOeedZTh558WBCqoBRgUaigGISSqaAgZNOroHR5EKqkHI1Rq6QKY ZroADJx2CoMdjxSAQBGkktoCHRekqioBrLZKgBsTxCqrGirUaqsGuOaqgR5B9OprBMAGG8ELxBb7 ggnIJmuCBMw2K4EIRkQb7RkUVGstBQpkq60CazTSRqmlnqrqqq6yCqusstqqrq65+uqusMGiYCyx HCiLLAfONguttEZQe22122oLQ0GHsAGuqeOSW+656E6grq0bsIuru7/CG4H/vPMea++y+TK7r7T+ /huwtqAiMsXJKE/BBxkst5yHFjDHrAUDNNdMMxU450xFBzz3zLMXQAfthQtjFG30G1UkrXQVEDTt dNNXRC31FWAcYPXVeFih9dZWsOD11ywAkAgOZJeNwxIVpK22Ezu07fYOTwgg99wCxGD33TE0MMPe fJNgw9+A26CEDIQXXoIOiCeuQxM0NO44FjxELjkPYPhg+eVf3KD55jcM4PnnA4iNiNllo6122my/ 3XbcdMuN9916872334H/PXjhhB+uOOKMO9445JNHXvnllmfOueagfy76IaSTbfrpqavOeuuv2x27 7LTXfjvuuu/eu+/ABz88//HGH5+858sb0vzZp6Ou+uqtu1799X3Xbjvuue/Ou++/By888cU7HvLO l75CrO95a3sf3OJXt/nJbnb2Exz+ZNA9xX3vcf6jHAB9UD7OnS90Y2seAt33vunRrXp5e+AMshe4 7RlOf4vjHw3CN7nxYU6AnSNgCEk3wgpE720mnBsK6QdB+7kwf/q7YP/8BwcxOPGJC8DhBwtIiAO2 z4cKDKL8XkfEFUbwiBSEoRJpIIcomPGMUbiDIRIgRR2OToRXrEAX5kjHLvSBgUNUIQsBB8YSSOGP gJRCHGRIA0ewUYBTTAQXFslILswhjoe4Y/zy+EASbOGSmNyCCyYog0OggYeQhgSAKEcJABa40RFm gKQhThCGVrryAZR84CHSwElPgrISADhlI1J5RUc4IJaym2UtSZHL5FFREbxsny9RuAcHOPOZDjgE BrJAzWpmoRQLMIA2t7kASCTzdI44ARTGSU4oPABN6EynOtfJzna6853wjKc850nPetrznvjMpz73 yc9++tMUgQAAOw== --_006_867F4B6A1672E541A94676D556793ACD0C27516166MOPESMBX01eut_ Content-Type: image/gif; name="image003.gif" Content-Description: image003.gif Content-Disposition: inline; filename="image003.gif"; size=493; creation-date="Fri, 11 Nov 2011 12:19:01 GMT"; modification-date="Fri, 11 Nov 2011 12:19:01 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhHAAhAMQAALHNVVqXGZu+IqbFNv79/ury0pK4H2SdaJzAJNjlq/3++vL34srdiSl5Mfj7 8OHrvDmDE5u+Kb3VbtDgm5jCnJC2IqDBJHqqHoazHsfYxcfco+/58f7///7+/v///f///yH5BAAA AAAALAAAAAAcACEAAAX/4CeOZGmeaKqubOumXSfKL0rT9RiTe65/nl0vxxE1KB3Ph6b8KGYjT/Pn ORwIHmy0FEQFCZRG5yldJnEqD6ezaWQIHMJDApAwCthgF8hbEqwEBQARAoWFEgskQWgiChwFDRoD hpQCA3hLQGhxSWABFpQIlAMPT2NoeTIJEBigooavlzJDS0UdHAkBEAivAoSjDklTQAROuBYQn7+/ lBJJS01SUgoJoskWvaECCWUiHEEKtw+8BtegvoWxiYtqSmsLhBblEALn2hLDH3HTAIXYuhfqVeLF TZ8SR3oSULKAQVeAChYi8kJwCUg4BcVkOOiXDgHDACAvXMBQoWQEOw6iahwsMCmdAI8CKoiciUEA gAJ8aBC4xfKlz3QRsVGcoICMJidKOjhgMKCXqKcAJqSMIkwEuw8OHjCQwNVOggJPvqm4ZUJGuw47 lajlA0Sat28xyJZV9APasGEcvknBkU9TjJ1WrTZZE9hHihAAOw== --_006_867F4B6A1672E541A94676D556793ACD0C27516166MOPESMBX01eut_-- From Carl.Wuyts@technicolor.com Fri Nov 11 04:22:13 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3472B21F8515 for ; Fri, 11 Nov 2011 04:22:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.5 X-Spam-Level: X-Spam-Status: No, score=-4.5 tagged_above=-999 required=5 tests=[AWL=-0.322, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wvUovDrgrcW6 for ; Fri, 11 Nov 2011 04:22:11 -0800 (PST) Received: from na3sys009aog118.obsmtp.com (na3sys009aog118.obsmtp.com [74.125.149.244]) by ietfa.amsl.com (Postfix) with ESMTP id E8EB221F84B8 for ; Fri, 11 Nov 2011 04:22:07 -0800 (PST) Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob118.postini.com ([74.125.148.12]) with SMTP ID DSNKTr0Tb0S0CHq//iwJ1O121hlqTTz0p0Rv@postini.com; Fri, 11 Nov 2011 04:22:09 PST Received: from MOPESMAILHC03.eu.thmulti.com (141.11.100.132) by mail3.technicolor.com (141.11.253.22) with Microsoft SMTP Server (TLS) id 8.3.192.1; Fri, 11 Nov 2011 13:21:11 +0100 Received: from MOPESMBX01.eu.thmulti.com ([169.254.155.121]) by MOPESMAILHC03.eu.thmulti.com ([141.11.100.132]) with mapi; Fri, 11 Nov 2011 13:21:19 +0100 From: Wuyts Carl To: Lorenzo Colitti Date: Fri, 11 Nov 2011 13:21:17 +0100 Thread-Topic: [v6ops] RFC6204bis-02 Thread-Index: Acyf8uuP4LpTnIlqQ1Cpvkk4ee8jlwAeTu0A Message-ID: <867F4B6A1672E541A94676D556793ACD0C27516167@MOPESMBX01.eu.thmulti.com> References: <867F4B6A1672E541A94676D556793ACD0C263BCDD7@MOPESMBX01.eu.thmulti.com> <867F4B6A1672E541A94676D556793ACD0C263BD0EC@MOPESMBX01.eu.thmulti.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/related; boundary="_006_867F4B6A1672E541A94676D556793ACD0C27516167MOPESMBX01eut_"; type="multipart/alternative" MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] RFC6204bis-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, 11 Nov 2011 12:22:13 -0000 --_006_867F4B6A1672E541A94676D556793ACD0C27516167MOPESMBX01eut_ Content-Type: multipart/alternative; boundary="_000_867F4B6A1672E541A94676D556793ACD0C27516167MOPESMBX01eut_" --_000_867F4B6A1672E541A94676D556793ACD0C27516167MOPESMBX01eut_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Agreed, but it's all about what people understand as "virtual intf". I'd l= ink it to the loop, in this case, "another subnet" compared to the LAN, so = not a good idea to use /128 from same prefix. I agree with your changed description below on, avoids misinterpretation fo= r sure. regs Carl Wuyts GCD System Architect Networking Connect Division carl.wuyts@technicolor.com tel.: +32 3 443 65 90 [cid:image001.gif@01CCA074.CB5704F0] [cid:image002.gif@01CCA074.CB5704F0] Prins Boudewijnlaan 47 - 2650 Edegem - Belgium Technicolor Delivery Technologies Belgium NV Registered office (maatschappelijke zetel): Prins Boudewijnlaan 47, 2650 Ed= egem, Belgium Company registration number (ondernemingsnummer): 0428837295 - RPR Antwerpe= n [cid:image003.gif@01CCA074.CB5704F0] Help preserve the color of our world - Think before you print. From: Lorenzo Colitti [mailto:lorenzo@google.com] Sent: donderdag 10 november 2011 22:51 To: Wuyts Carl Cc: Wes Beebee; v6ops@ietf.org Subject: Re: [v6ops] RFC6204bis-02 On Thu, Nov 10, 2011 at 00:07, Wuyts Carl > wrote: Some remarks on your below comment. You read the WAA-8 as: sent the /64 Pd to the LAN host and fetch one /128 f= rom it for the loop intf First of all, I think the WAA-8 is not clear on this. In fact, as Ole poin= ted out, is was first written from the point-of-view that the ia_pd would b= e different from 64. This will lead to different people translating this d= ifferently, hence different implementations by CPE vendors. Secondly, I think you're violating the rules a little here. You fetch a /1= 28 host IP form the single available ia_pd and assign this one to the loopb= ack interface and you assume that the DAD process works ok, i.e., that the = CPE will say it is in use. But, the loopback interface is no part of your = LAN subnet, hence this will not work without an ND proxy (as Lorenzo mentio= ns in his reply), unless the loop intf is 'bridged' into your LAN, which is= not the case normally I'd say. Actually, I think that in practice this is not a problem, because the LAN i= nterface is actually a bridge, so it's a virtual interface. So you can simp= ly assign the address to it and you're done. As an example: say that you have a /64 for the LAN interface: 2001:db8:0:1:= :/64 . That's a virtual interface, so you can just pick any address on the = LAN interface (say 2001:db8:0:1:/64, or even 2001:db8:0:1::1) , and as= sign it to the LAN interface, and that's it. DAD will work. I agree that the text needs to be clarified. What was the original reason for saying "configuring it on one of its inter= nal virtual interfaces"? Was it just to say that the CE router should be ab= le to use a LAN-side address when talking to the rest of the world? I think= the weak host model (mandated in WAA-9) does that for you. So perhaps we c= an just change the text to "MUST create global IPv6 address(es) from its de= legated prefix(es) to use for global communications", and leave it at that? --_000_867F4B6A1672E541A94676D556793ACD0C27516167MOPESMBX01eut_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Agreed, b= ut it’s all about what people understand as “virtual intf”= ;.  I’d link it to the loop, in this case, “another subnet= ” compared to the LAN, so not a good idea to use /128 from same prefi= x.

 

I agree with your changed description belo= w on, avoids misinterpretation for sure.

 

regs=

 <= /p>

Carl Wuyts<= /b>

GCD System Architect Networking=

= Connect Division

carl.wuyts@technicolor.com

tel.: +32 3 443 65 90

3Dtwitter

Prins Boudewijnl= aan 47  -  2650 Edegem  -  Belgium<= o:p>

Technicolor Delivery Technologies Belgium NV=

<= span lang=3DNL-BE style=3D'font-size:7.0pt;font-family:"Arial","sans-serif"= ;color:#9D9FA2'>Registered office (maatschappelijke zetel): Prins Boudewijn= laan 47, 2650 Edegem, Belgium

Company registration number (ondernemingsnummer): 0428837295 - RPR = Antwerpen

3DEco

Help preserve the color of o= ur world - Think before you print.

&nb= sp;

 

From: Lorenzo Colitti [mailto:lorenzo@google.c= om]
Sent: donderdag 10 november 2011 22:51
To: Wuyts C= arl
Cc: Wes Beebee; v6ops@ietf.org
Subject: Re: [v6ops]= RFC6204bis-02

 <= /o:p>

On Thu, Nov 10, 2011 at 00:07, Wuyts Car= l <Carl.Wuyts@technicolor.= com> wrote:

Some remarks on your below comment.=

You read the WAA-8 as: sent the /64 Pd to the LAN host and fetch one /128= from it for the loop intf

 

First of all, I think the WAA-8 is not = clear on this.  In fact, as Ole pointed out, is was first written from= the point-of-view that the ia_pd would be different from 64.  This wi= ll lead to different people translating this differently, hence different i= mplementations by CPE vendors.

 

Secondly, I think you’re violat= ing the rules a little here.  You fetch a /128 host IP form the single= available ia_pd and assign this one to the loopback interface and you assu= me that the DAD process works ok, i.e., that the CPE will say it is in use.=   But, the loopback interface is no part of your LAN subnet, hence thi= s will not work without an ND proxy (as Lorenzo mentions in his reply), unl= ess the loop intf is ‘bridged’ into your LAN, which is not the = case normally I’d say.

 

Actually,= I think that in practice this is not a problem, because the LAN inter= face is actually a bridge, so it's a virtual interface. So you can simply a= ssign the address to it and you're done.

 

As an exa= mple: say that you have a /64 for the LAN interface: 2001:db8:0:1::/64 . Th= at's a virtual interface, so you can just pick any address on the LAN inter= face (say 2001:db8:0:1:<IID>/64, or even 2001:db8:0:1::1) , and assig= n it to the LAN interface, and that's it. DAD will work.

 

I agree that the text needs to be clarified.

 

= What was the original reason for saying "configuring it on one of its = internal virtual interfaces"? Was it just to say that the CE router sh= ould be able to use a LAN-side address when talking to the rest of the worl= d? I think the weak host model (mandated in WAA-9) does that for you. So pe= rhaps we can just change the text to "MUST create global IPv6 add= ress(es) from its delegated prefix(es) to use for global communications&quo= t;, and leave it at that?

= --_000_867F4B6A1672E541A94676D556793ACD0C27516167MOPESMBX01eut_-- --_006_867F4B6A1672E541A94676D556793ACD0C27516167MOPESMBX01eut_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=1351; creation-date="Fri, 11 Nov 2011 12:21:17 GMT"; modification-date="Fri, 11 Nov 2011 12:21:17 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhGAAYAPcAAAAAAP///1Sfum/L64bW8o7h/ofU74fT7pHb9pfa8u75/VbD5VzG6FvF5l3G 513F5l/G51/F5mHH52PH6GPI6GPI52TH6GXJ6GbI6GnK6mjJ6WjK6WzL6m/M63HN6nPN6nTN63fR 7XnR7XTI5FeVqnnN537T7n7R7H/T7X3O6Y3f+4jV73m903/E2oDE2pTf+ZPc9JTa8Zfa8aDd8LDj 9MXr9+z5/er3+/r9/imy1yyx1S202S2z1zK43TW63jW32zS22Ta53Te73za32zq84Dm53Du73j2/ 4j2+4T283z273kHB5D++4EHA4kG/4UPA40K/4UTB5EbD5UbB40rJ7EjD5ErG6EnE5knE5Ua720rE 5kvG507J607I6U3G50/K60u+3U2/4U7A4k2/3lLI6E/A31XN7lHC4VnP8FfL61PD4lXD5FXF41vR 8VfG5VO92lrJ51a+21i/21/O7F7L6VnB3VzE4mHN6l/H5V3D30+lvWDH41/E4GDF4WLH42rL6GvP 6l+2znLZ9W7Q62C1zGO50HXZ9HTY83ba9XXX8mW70nLO6nHN6We803rd+HXV73zf+mm91HXS62vA 12GpvWavw2ixxVmWp2qxxYDW7X3Q52yzxm+2yW60x4HS6HC2yXG3ynzD2I7a75Xb7pvh9F+HkqTg 8ajg76ff7qri8bPo97fm9Ljm9MXw/Mfw/NDz/dDx+tbx+dz0++H1++f5/uv5/Six1S+22jG01zK1 2EXD5E/M7U7H50yvyWPY91zJ5WjZ92za927b+HHY82G4z3Xd+FurwHXa9Xfc93ne+F+rv37h+2u/ 1YDi/H7c9YHh+YLh+YXi+mqyxWuzxork+ovj+o3l+3K4ypXn+12PnJrm+qXp+63j8cLx/M/0/ef4 /Jfp+57q+6Xt/Kjv/avv/a3v/a7w/bPw/bzz/uP6/+z7/vP9/7fz/r30/sD0/sX1/sn2/tT4/9L2 /d/6/+X7/+b7/+r8/+v7/sz3/tr5/ub8/+39//v///3///7//////yH5BAEAAP8ALAAAAAAYABgA AAj/AP8JHEiwoMGCAgggOGCg4YqHEB8aOPCCAEESKmR84MABg0cOHUKGHDCAA4gEBQaOiIHBwgQO pmrQEEEhg80NGnJewACDhcAUJyBMwBArgL8ACkxc2MBUg8cLEEy0+PkhQoMZAerNmxegBoMLFChc AFsBQggXAkswerBgVYB8+eLtu7GorgcKDipIcBBi6r8SHtiyCoAPH7x6AXAoxjELRYO9IUIJlGMn jBi37zLHo2fPXj19/hT8WRMGDzGBb7LosIUqADp07WC7c9eOHbwAmnjwGBNIYBwwuHK0NleOOLnj 5MaxC+BpR64zp//JGQNkx6kA4rKXO8ede7oAe378/1BTSGCdMkNunfIXLhw4eQH6yU88KoiSImzK /8tzpkiPVP1gg4013gRgYGKmEMEEE0a4oYhAeahhhA/c8FMNNdF0s4466tyzTgCrOAFFEnA0IhAf bCQhhCkBVPMMNDDC+GI3AUiCBBNwRCJQH24wgUQmAWwjTDJEFllMNAGIcoQTdDAjkB9uODGFFLHw o00wwGSZpS/bBJDJEk80+eQvTVQhxR2zBECLK6202c0rAchCxhVR3DGJb5I0gYUXVqRBCiy1BFqL Dd+oMocVW+jyCCEC6ZEIIFps0cUXVOyCRhuYomEGFVx0wcsghlwyUC/DOHPIMcg4AskyzbS6DCSO ICSDiDOCGFNQNspUYgkmm3TCCSjXgPJJJ9NIYwklpRyk7LIDBQQAOw== --_006_867F4B6A1672E541A94676D556793ACD0C27516167MOPESMBX01eut_ Content-Type: image/gif; name="image002.gif" Content-Description: image002.gif Content-Disposition: inline; filename="image002.gif"; size=1834; creation-date="Fri, 11 Nov 2011 12:21:18 GMT"; modification-date="Fri, 11 Nov 2011 12:21:18 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhcgBFAOZ/AEGueqipqmgxkACLS4ORyPb294DFpZrMVqvi+sXr2Ie3laLXtnRHnLQlZO3J 2M+pxP7pJvqtgePqmqOIvYLKnACP1fewoXa65/vCov71sdqRnc6OpPvrlcU/benvs7qmzpzR8P/n rc7imtLntMkhU/V7Hf/yl+fZ6f3HipjL7b+MraKs1h+WXIrU9fNrPv/dkaTIrpQpd/JlIr8kXv/o ALa3uO0bLwCmUQC68pKSlf/CDgxNosvbKtvb3IzGP8nJyoiJjPaWgH+Ag3Z3euTk5Y3Y+MTfm+3t 7r/AwZubnvBSJQCZ3NLS0//eAwN+yE84la9fmdjkX//RSiPB855BhP/ILiCvY9HeRvLkCvmykSld q/aNl4Dd+cPT6O85Q2m+Q6zRONnM5OPx0PR3OR2Z2eOttkCr4Lfbm//uQPWMWbeLscPbysbs/OP1 /ZeLwPaLN9blff/iEvXlByCi3nzB69eqvN7r4uzysHfDWSCKzu+Uh8R4pR6j4IVfqm1ucf///yH5 BAEAAH8ALAAAAAByAEUAAAf/gH+Cg4SFhoeIiYqLjI2Oj5CRkpOUlZaXmJmam5ydnp+goaKjpKWm p6ipqqusra6vsLGys7S1tqF+Oat+freMubu9vorAkkhIlryqBQWXxZBEvD2VyqhEQtPJupJJScnC pzV+2dTbqdWnSX4BNTWDR+01RIUFSO0/zX/AP+1Mg/x/iLRDku9PO0JH7NXA906hv0Ho/vSId2TQ xB4Jf1gKwKujoB8deWn8OCTkkIp+gAAJGUBQjnUhgUAEB9Lkx5C58lUr8DLkSHE5Spqb1IMjkh7T evgZ4o9JyYrR/Mib2FKfHyH4kPBq1rPGkR4lH1ZjsvQH0gDIlA7RSGSlN6uC/zgCmfcjrEFeQuRd EkeO48g/IN2pQ2boasGV014+/MPRHdw/QsYZUve3wFO4R5YWBOlN3FtMfAetBJKj9EpdEQk9+/My sWRB4hxXS3koNcdpypRWnXnXMejXf4SWHt4yNcShrVkDjy1o9lDehELnXldIGfNMoV0CJxSZnGrk kpPDltpc2FZDK+eJlqwsmsx3V3trEvdXK5CKgvKJu59fLHjX5FxXjVz5fHUXEPmAJER5gkQ2UgHq uHMdJiANkcNIK+WSQ2TraaiZPv8pFyB5jxWwkoUvLWjiVUlkmE01RJQERACRISifJhxR90cBNUTG YkE1ZAgEYTnsxlgO8wSA5P8/F7pkDo8+AvFgj7wkoR5r5hChzlU1JNjkMGCGKeaYZJZp5pmqsIHA mmyCkMKbcK4g55wrfGDnnR88oOeedZTh558WBCqoBRgUaigGISSqaAgZNOroHR5EKqkHI1Rq6QKY ZroADJx2CoMdjxSAQBGkktoCHRekqioBrLZKgBsTxCqrGirUaqsGuOaqgR5B9OprBMAGG8ELxBb7 ggnIJmuCBMw2K4EIRkQb7RkUVGstBQpkq60CazTSRqmlnqrqqq6yCqusstqqrq65+uqusMGiYCyx HCiLLAfONguttEZQe22122oLQ0GHsAGuqeOSW+656E6grq0bsIuru7/CG4H/vPMea++y+TK7r7T+ /huwtqAiMsXJKE/BBxkst5yHFjDHrAUDNNdMMxU450xFBzz3zLMXQAfthQtjFG30G1UkrXQVEDTt dNNXRC31FWAcYPXVeFih9dZWsOD11ywAkAgOZJeNwxIVpK22Ezu07fYOTwgg99wCxGD33TE0MMPe fJNgw9+A26CEDIQXXoIOiCeuQxM0NO44FjxELjkPYPhg+eVf3KD55jcM4PnnA4iNiNllo6122my/ 3XbcdMuN9916872334H/PXjhhB+uOOKMO9445JNHXvnllmfOueagfy76IaSTbfrpqavOeuuv2x27 7LTXfjvuuu/eu+/ABz88//HGH5+858sb0vzZp6Ou+uqtu1799X3Xbjvuue/Ou++/By888cU7HvLO l75CrO95a3sf3OJXt/nJbnb2Exz+ZNA9xX3vcf6jHAB9UD7OnS90Y2seAt33vunRrXp5e+AMshe4 7RlOf4vjHw3CN7nxYU6AnSNgCEk3wgpE720mnBsK6QdB+7kwf/q7YP/8BwcxOPGJC8DhBwtIiAO2 z4cKDKL8XkfEFUbwiBSEoRJpIIcomPGMUbiDIRIgRR2OToRXrEAX5kjHLvSBgUNUIQsBB8YSSOGP gJRCHGRIA0ewUYBTTAQXFslILswhjoe4Y/zy+EASbOGSmNyCCyYog0OggYeQhgSAKEcJABa40RFm gKQhThCGVrryAZR84CHSwElPgrISADhlI1J5RUc4IJaym2UtSZHL5FFREbxsny9RuAcHOPOZDjgE BrJAzWpmoRQLMIA2t7kASCTzdI44ARTGSU4oPABN6EynOtfJzna6853wjKc850nPetrznvjMpz73 yc9++tMUgQAAOw== --_006_867F4B6A1672E541A94676D556793ACD0C27516167MOPESMBX01eut_ Content-Type: image/gif; name="image003.gif" Content-Description: image003.gif Content-Disposition: inline; filename="image003.gif"; size=493; creation-date="Fri, 11 Nov 2011 12:21:18 GMT"; modification-date="Fri, 11 Nov 2011 12:21:18 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhHAAhAMQAALHNVVqXGZu+IqbFNv79/ury0pK4H2SdaJzAJNjlq/3++vL34srdiSl5Mfj7 8OHrvDmDE5u+Kb3VbtDgm5jCnJC2IqDBJHqqHoazHsfYxcfco+/58f7///7+/v///f///yH5BAAA AAAALAAAAAAcACEAAAX/4CeOZGmeaKqubOumXSfKL0rT9RiTe65/nl0vxxE1KB3Ph6b8KGYjT/Pn ORwIHmy0FEQFCZRG5yldJnEqD6ezaWQIHMJDApAwCthgF8hbEqwEBQARAoWFEgskQWgiChwFDRoD hpQCA3hLQGhxSWABFpQIlAMPT2NoeTIJEBigooavlzJDS0UdHAkBEAivAoSjDklTQAROuBYQn7+/ lBJJS01SUgoJoskWvaECCWUiHEEKtw+8BtegvoWxiYtqSmsLhBblEALn2hLDH3HTAIXYuhfqVeLF TZ8SR3oSULKAQVeAChYi8kJwCUg4BcVkOOiXDgHDACAvXMBQoWQEOw6iahwsMCmdAI8CKoiciUEA gAJ8aBC4xfKlz3QRsVGcoICMJidKOjhgMKCXqKcAJqSMIkwEuw8OHjCQwNVOggJPvqm4ZUJGuw47 lajlA0Sat28xyJZV9APasGEcvknBkU9TjJ1WrTZZE9hHihAAOw== --_006_867F4B6A1672E541A94676D556793ACD0C27516167MOPESMBX01eut_-- From wbeebee@cisco.com Fri Nov 11 06:30:41 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E531421F8663 for ; Fri, 11 Nov 2011 06:30:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.966 X-Spam-Level: X-Spam-Status: No, score=-3.966 tagged_above=-999 required=5 tests=[AWL=0.566, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ol6gq8jhEomd for ; Fri, 11 Nov 2011 06:30:41 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 3850021F84B8 for ; Fri, 11 Nov 2011 06:30:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wbeebee@cisco.com; l=1046; q=dns/txt; s=iport; t=1321021841; x=1322231441; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=QuOIlRM3xIQ7iQstJR08jo73H2uUHXttmaThPoOrWLQ=; b=iz9irarkKFwSyBAasTWqtlQ8Tw5GE7iwA/DJM6rVJBv37zfuz1U4EA8A BCmsU07JANdWcW4BraK6n51hZ555/HAk2+4I4Ivy8Yb0v8BnzqS854fqZ pBKxDg5H4h096zW1F/2qca9rNlr1QYT7u4Tri2PGYvlG4mHuYZga95ETR c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoYFAFQxvU6tJV2d/2dsb2JhbABDiUOgWAKBBYFyAQEBAwESASkBPBIBCIEdAQEEAQ0gB4dgmw0BnkeJfgSHXzGMHYVDiCaELQ X-IronPort-AV: E=Sophos;i="4.69,495,1315180800"; d="scan'208";a="35112888" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP; 11 Nov 2011 14:30:41 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id pABEUeS7007390; Fri, 11 Nov 2011 14:30:40 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 11 Nov 2011 08:30:40 -0600 Received: from 161.44.175.128 ([161.44.175.128]) by XMB-RCD-201.cisco.com ([72.163.62.208]) with Microsoft Exchange Server HTTP-DAV ; Fri, 11 Nov 2011 14:30:40 +0000 User-Agent: Microsoft-Entourage/12.31.0.110725 Date: Fri, 11 Nov 2011 09:30:38 -0500 From: Wes Beebee To: Wuyts Carl , Lorenzo Colitti Message-ID: Thread-Topic: [v6ops] RFC6204bis-02 Thread-Index: Acyf+grlhXNcIYJARcakpc/bIQWN0wAcPLPgAATfXzc= In-Reply-To: <867F4B6A1672E541A94676D556793ACD0C27516166@MOPESMBX01.eu.thmulti.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 11 Nov 2011 14:30:40.0650 (UTC) FILETIME=[7CC4D6A0:01CCA07E] Cc: "v6ops@ietf.org" Subject: Re: [v6ops] RFC6204bis-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, 11 Nov 2011 14:30:42 -0000 >> but we also support to ignore them, CPE must be flexible, but your sugge= stion >> now is to listen to IPCPv6 and then linking it to DHCP-PD ? So no, no h= ard >> req needed to link DHCP-PD to RAS listening, not ok for e.g. PPP. > =20 >> And no, please do not start linking up other protocols please, it is not >> necessary and only creates extra possibilities. On one hand, everyone >> expects the CPE do be nearly free-of-charge, but on the other hand it mu= st be >> capable of supporting all kind of scenario=B9s ?! > =20 >> What=B9s next ?? +1=20 Lorenzo - All this thrashing is accomplishing only one thing - confusion. We need to send clear signals in RFC6204bis to CPE vendors. Where we were not clear in RFC 6204, we need to be more clear in RFC 6204bis. However, this is not an opportunity to revisit solutions that are already Pareto optimal. Pareto optimal does not mean that everyone is happy - it simply means that you can't make someone happy without making someone else unhappy. - Wes From nick@inex.ie Fri Nov 11 07:03:26 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B79E321F8A62 for ; Fri, 11 Nov 2011 07:03:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.225 X-Spam-Level: X-Spam-Status: No, score=-2.225 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_13=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 5br1iLmVLLzz for ; Fri, 11 Nov 2011 07:03:26 -0800 (PST) Received: from mail.acquirer.com (mail.acquirer.com [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 16BA421F8A35 for ; Fri, 11 Nov 2011 07:03:25 -0800 (PST) X-Envelope-To: v6ops@ietf.org Received: from crumpet.internal.acquirer.com ([IPv6:2001:1bb8:2004:100:d18b:bb89:a846:532b]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id pABF5X8N024745 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 11 Nov 2011 15:05:34 GMT (envelope-from nick@inex.ie) Message-ID: <4EBD3931.7040300@inex.ie> Date: Fri, 11 Nov 2011 15:03:13 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Joel jaeggli References: <4EBABB05.8070601@bogus.com> In-Reply-To: <4EBABB05.8070601@bogus.com> 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; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-v6ops-ipv6-discard-prefix@tools.ietf.org, IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-ipv6-discard-prefix-00 - IANA feeback X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 11 Nov 2011 15:03:26 -0000 On 09/11/2011 17:40, Joel jaeggli wrote: > 3. The IC section currently states that "The prefix should be allocated > from ::/3" and as we would be taking it from 2001:0000::/23 that > sentence is probably superfluous. If the author takes a shine to a > specific /64 from there he could let us know. Otherwise, I propose we > just take the numerically lowest /64, which would be immediately after > the TEREDO assignment. We could discuss this with the author in case he > has operational concerns with that. As an author comment, the WG consensus at the last v6ops meeting was that the prefix should specifically not come from global unicast space. However, IANA would prefer if it were to come from the special purpose registry: 2001::/23. Regardless of IANA's preferences, I'm still of the opinion that it would be better to keep to the WG preference. Nick From cb.list6@gmail.com Fri Nov 11 09:05:10 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5F8A21F86EE for ; Fri, 11 Nov 2011 09:05:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.018 X-Spam-Level: X-Spam-Status: No, score=-3.018 tagged_above=-999 required=5 tests=[AWL=0.581, 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 c7FzIzl216bi for ; Fri, 11 Nov 2011 09:05:10 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 413C521F861E for ; Fri, 11 Nov 2011 09:05:10 -0800 (PST) Received: by gye5 with SMTP id 5so3731744gye.31 for ; Fri, 11 Nov 2011 09:05:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=m4FdcE4Rv2SV/mtNq+FuM7PzrPmBD2yWJgg5YS+z4Dc=; b=r1gx1mnQz6fUIE3gq9k6DnoC4xWmG4n1IDwVnJREF7ixOTE/2QiJsDeuZaf6Zgj4d5 YAwmkamGrmXENf4hvUe7Sp2MnMZueiI3gUaFrW7lWHQwWp0WWYOBJBFgynZMfo2jUJjq zqZkOM4Mv/36MER8bZ+Cw1qf/rgobQykkdg9w= MIME-Version: 1.0 Received: by 10.68.5.162 with SMTP id t2mr26315758pbt.73.1321031108343; Fri, 11 Nov 2011 09:05:08 -0800 (PST) Received: by 10.142.230.8 with HTTP; Fri, 11 Nov 2011 09:05:08 -0800 (PST) Date: Fri, 11 Nov 2011 09:05:08 -0800 Message-ID: From: Cameron Byrne To: "v6ops@ietf.org WG" Content-Type: text/plain; charset=ISO-8859-1 Subject: [v6ops] T-Mobile USA IPv6 Android launch X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 11 Nov 2011 17:05:11 -0000 On Wed, Nov 9, 2011 at 3:09 PM, Fred Baker wrote: > FYI. As other companies deploy residential IPv6 services, it would be similarly appropriate for them to state the fact and point to their public statements about them. > FYI. T-Mobile USA now has opt-in beta support for an Android phone on IPv6, more info here https://sites.google.com/site/tmoipv6/lg-mytouch As far as i know, this is the first Android phone that supports IPv6 on the GSM/UMTS mobile interface. Previous version of Android phones supported IPv6 on WiFi and LTE. Our main epc.tmobile.com APN now works with both IPv4 and IPv6 without any whitelisting in the San Francisco area, the rest of the USA should be complete early next year. Cameron From jhw@apple.com Fri Nov 11 10:42:25 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 594EA21F8AA8 for ; Fri, 11 Nov 2011 10:42:25 -0800 (PST) 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=[AWL=0.000, 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 0YcTB7Fwd8gp for ; Fri, 11 Nov 2011 10:42:24 -0800 (PST) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id EE95A21F8A97 for ; Fri, 11 Nov 2011 10:42:24 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay14.apple.com ([17.128.113.52]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LUI00CDEEJRZBK1@mail-out.apple.com> for v6ops@ietf.org; Fri, 11 Nov 2011 10:41:58 -0800 (PST) X-AuditID: 11807134-b7ce4ae0000052e8-73-4ebd6c751514 Received: from [17.153.26.166] (Unknown_Domain [17.153.26.166]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay14.apple.com (Apple SCV relay) with SMTP id 42.90.21224.57C6DBE4; Fri, 11 Nov 2011 10:41:57 -0800 (PST) From: james woodyatt In-reply-to: Date: Fri, 11 Nov 2011 10:41:57 -0800 Message-id: <2523A802-0827-4595-9D16-498484BC8F4D@apple.com> References: To: Wes Beebee X-Mailer: Apple Mail (2.1251.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMLMWRmVeSWpSXmKPExsUiOFNqmW5pzl4/g7fXrSxOH9vLbNG+7gqb A5PHlN8bWT2WLPnJFMAUxWWTkpqTWZZapG+XwJXx7mo3e8FDloqVS9YyNjA+Yu5i5OSQEDCR OLvlMRuELSZx4d56IJuLQ0hgKpPE0znXwBLCAkoSO7ffAWvgFTCWWHPrHQuIzSygI7Fz6x2w GjYBFYlvl+8ygdicAgYSUzZ9AKtnEVCVWPl/NVA9B1C9isT/Bn6IVm2JZQtfQ420kXj4/xKY LSSgL3Hv9maw8SJAa99//8QEcZu8RMvXO2wTGPlnIbliFpIrZiEZu4CReRWjYFFqTmKloYle YkFBTqpecn7uJkZQ0DUUmuxgPPiT/xCjAAejEg/voqS9fkKsiWXFlbmHGCU4mJVEeKeYA4V4 UxIrq1KL8uOLSnNSiw8xSnOwKInzRngApQTSE0tSs1NTC1KLYLJMHJxSDYyzXu25pext6t+3 YJeq2zPfZe1zXh5b3NP8P760JbPYTpN7xi+X3su2C1y0zjZazTh9dH1uQJO5fpjA1blLvnJM 4Vi9OVrstOuF4obdqeYbF6w+/OzQBM+8ezvFWC7MyePLErZR5pwy5elx782JhpsWpXRnJqQt iuoKzefo6pI59FXOl3/B9PlKLMUZiYZazEXFiQC2uYjGNgIAAA== Cc: IPv6 Operations Subject: Re: [v6ops] RFC6204bis-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, 11 Nov 2011 18:42:25 -0000 On Nov 11, 2011, at 06:30 , Wes Beebee wrote: > > However, this is not an opportunity to revisit solutions that are > already Pareto optimal. > > Pareto optimal does not mean that everyone is happy - it simply means that > you can't make someone happy without making someone else unhappy. Then I propose to suspend all further IETF activity on IPv6 until the opportunity arises again to revisit solutions to the exhaustion of IPv4 free pool space via operating strategies other than NAT444. -- james woodyatt member of technical staff, core os networking From wbeebee@cisco.com Fri Nov 11 11:43:09 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA9E221F8A7E for ; Fri, 11 Nov 2011 11:43:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.047 X-Spam-Level: X-Spam-Status: No, score=-4.047 tagged_above=-999 required=5 tests=[AWL=0.485, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bP7hZKpHMJ5r for ; Fri, 11 Nov 2011 11:43:09 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 5403921F8A7D for ; Fri, 11 Nov 2011 11:43:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wbeebee@cisco.com; l=657; q=dns/txt; s=iport; t=1321040589; x=1322250189; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=m1vVrJEbfUGlzIs/PFcSnI/PbOuTF9a4ilHRMhFzsGU=; b=bmrmGkquIo49WPN6O+ris6mmmkTY5ZzHbThR5uXF7rESI9gIT57Z5RTU xdWjiT7zjG74ECCbiRB7dfzcfwfDuzrJWHTfNwIPtJJbJtJfsC5gaPk0G yGLIjcx1X+w6DanupzhCIF1HRK7jyMLQyCS6jExo9dGiB4GiqgV2LBiuQ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoYFAOZ5vU6tJV2b/2dsb2JhbABCiUOgWgKBBYFyAQEBAwESAScCATwSAQiBHQEBBA4gB4dgmhsBniiJfgSIEIwdhUOIJoQt X-IronPort-AV: E=Sophos;i="4.69,496,1315180800"; d="scan'208";a="35202202" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 11 Nov 2011 19:43:09 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pABJhKdx016813; Fri, 11 Nov 2011 19:43:20 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 11 Nov 2011 13:43:08 -0600 Received: from 161.44.175.128 ([161.44.175.128]) by XMB-RCD-201.cisco.com ([72.163.62.208]) with Microsoft Exchange Server HTTP-DAV ; Fri, 11 Nov 2011 19:43:07 +0000 User-Agent: Microsoft-Entourage/12.31.0.110725 Date: Fri, 11 Nov 2011 14:43:07 -0500 From: Wes Beebee To: james woodyatt Message-ID: Thread-Topic: [v6ops] RFC6204bis-02 Thread-Index: AcygqiJ2yfsNtl/H4kGmrGu3tImVIA== In-Reply-To: <2523A802-0827-4595-9D16-498484BC8F4D@apple.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 11 Nov 2011 19:43:08.0840 (UTC) FILETIME=[238F9A80:01CCA0AA] Cc: IPv6 Operations Subject: Re: [v6ops] RFC6204bis-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, 11 Nov 2011 19:43:09 -0000 >> However, this is not an opportunity to revisit solutions that are >> already Pareto optimal. >> >> Pareto optimal does not mean that everyone is happy - it simply means that >> you can't make someone happy without making someone else unhappy. > > Then I propose to suspend all further IETF activity on IPv6 until the > opportunity arises again to revisit solutions to the exhaustion of IPv4 free > pool space via operating strategies other than NAT444. Then I propose that we spend the next 10 years arguing over the meaning of the M and O bits so that we can achieve no more consensus than the previous 10 years have gotten us. - Wes From dougb@dougbarton.us Fri Nov 11 13:57:09 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1D2421F8713 for ; Fri, 11 Nov 2011 13:57:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[AWL=-0.149, 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 tLskKpz1275S for ; Fri, 11 Nov 2011 13:57:08 -0800 (PST) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id 1C4C121F86AA for ; Fri, 11 Nov 2011 13:57:07 -0800 (PST) Received: (qmail 15136 invoked by uid 399); 11 Nov 2011 21:57:04 -0000 Received: from unknown (HELO 172-17-198-245.globalsuite.net) (dougb@dougbarton.us@12.207.105.210) by mail2.fluidhosting.com with ESMTPAM; 11 Nov 2011 21:57:04 -0000 X-Originating-IP: 12.207.105.210 X-Sender: dougb@dougbarton.us Message-ID: <4EBD9A2D.4070309@dougbarton.us> Date: Fri, 11 Nov 2011 13:57:01 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111110 Thunderbird/8.0 MIME-Version: 1.0 To: Nick Hilliard References: <4EBABB05.8070601@bogus.com> <4EBD3931.7040300@inex.ie> In-Reply-To: <4EBD3931.7040300@inex.ie> X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: draft-ietf-v6ops-ipv6-discard-prefix@tools.ietf.org, IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-ipv6-discard-prefix-00 - IANA feeback X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 11 Nov 2011 21:57:09 -0000 On 11/11/2011 07:03, Nick Hilliard wrote: > On 09/11/2011 17:40, Joel jaeggli wrote: >> 3. The IC section currently states that "The prefix should be allocated >> from ::/3" and as we would be taking it from 2001:0000::/23 that >> sentence is probably superfluous. If the author takes a shine to a >> specific /64 from there he could let us know. Otherwise, I propose we >> just take the numerically lowest /64, which would be immediately after >> the TEREDO assignment. We could discuss this with the author in case he >> has operational concerns with that. > > As an author comment, the WG consensus at the last v6ops meeting was > that the prefix should specifically not come from global unicast space. Not only do I disagree that what you're describing was the consensus, but you're still mischaracterizing "global unicast space." Please see: https://www.ietf.org/mail-archive/web/v6ops/current/msg09679.html > However, IANA would prefer if it were to come from the special purpose > registry: 2001::/23. I retain a slight preference for Roger's idea of using the last /32 in 2000::/3 (3fff:ffff::/32). OTOH the only reason I can see not to pull it from the SPR would be to avoid wasting space in that registry that could eventually be put to a better purpose; so if the final decision is to go that way I wouldn't object. hth, Doug -- "We could put the whole Internet into a book." "Too practical." Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From shemant@cisco.com Fri Nov 11 23:22:04 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD88421F8495 for ; Fri, 11 Nov 2011 23:22:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.132 X-Spam-Level: X-Spam-Status: No, score=-6.132 tagged_above=-999 required=5 tests=[AWL=0.466, 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 4aTGMEIQIO4c for ; Fri, 11 Nov 2011 23:22:03 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 1375D21F849B for ; Fri, 11 Nov 2011 23:22:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=11119; q=dns/txt; s=iport; t=1321082523; x=1322292123; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=XnVPdSXNi76ZPnACvtIsKO9iHiF40eQXWT58WMiwdGY=; b=FkYd8DKpsP9Ys9d2DW9d2XcLs+aLN+mgOmch80ckKUIgEhyfCLEsFug2 QbSj6aKQvFyrTE4eiQhQ7NCsrep/LsVkBnzvoIBdwT98Jr3z4I6O8SKA5 bcGjIeEYTvRPMKGmz/LXqZ/rP5PyzV0vM/i2ToJ+sX81w/xkV0Q8ciLP0 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArIAABoevk6tJV2a/2dsb2JhbABBgk2XW4gVAYdwgQWBcgEBAQQSAQkRA1kCAQgRBAEBCwYXAQYBRQkIAQEEARIIGodomFABnW+JHGMEiBCRYoxU X-IronPort-AV: E=Sophos;i="4.69,498,1315180800"; d="scan'208,217";a="35300197" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 12 Nov 2011 07:21:59 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pAC7LxFR016005; Sat, 12 Nov 2011 07:21:59 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 12 Nov 2011 01:21:59 -0600 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCA10B.C40327FE" Date: Sat, 12 Nov 2011 01:21:56 -0600 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C303494A91@XMB-RCD-109.cisco.com> In-Reply-To: <867F4B6A1672E541A94676D556793ACD0C263BCDD7@MOPESMBX01.eu.thmulti.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] RFC6204bis-02 Thread-Index: AcyewOvBbq1YdOdiSD66Sp1uaN6CQwCSeq2g References: <867F4B6A1672E541A94676D556793ACD0C263BCDD7@MOPESMBX01.eu.thmulti.com> From: "Hemant Singh (shemant)" To: "Wuyts Carl" , X-OriginalArrivalTime: 12 Nov 2011 07:21:59.0507 (UTC) FILETIME=[C42FA230:01CCA10B] Subject: Re: [v6ops] RFC6204bis-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, 12 Nov 2011 07:22:05 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCA10B.C40327FE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Wuyts, =20 Sorry for the delayed reply. The bullet is correct. If a CPE router WAN has a public IPv4 address, then the router can send data over the native IPv4 network so why invoke DS-Lite? As for your error related comments/questions, please see the Coexistence section of the document version -02. See bullets 1 and 3 where a specific order is specified and if the CE follows the order there is les chance of mistake. =20 =20 http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-02#page-15 =20 Thanks for the review. =20 Hemant =20 From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Wuyts Carl Sent: Wednesday, November 09, 2011 4:21 AM To: v6ops@ietf.org Subject: [v6ops] RFC6204bis-02 =20 =20 1. DLW-4: If the IPv6 CE Router is configured with a public IPv4 address on its WAN interface, where public IPv4 address is defined as any address which is not in the private IP address space specified in [RFC5735] and also not in the reserved IP address space specified in [RFC6333], then the IPv6 CE Router MUST disable the DS-Lite B4 element. =20 =20 This one is not fully ok I'd say. First of all, the DSlite is supposed to run on a v6-only intf, hence you could consider it as a configuration issue in case you have configured a public IPv4 on it ? Even if not, I don't see what you should have to check for public IPv4 address presence to bring up (or not) the DSLite intf. And then what happens if the DSLite tunnel is up, and a public IPv4 is being configured on top ? Bring it down ? Imagine you boot the CPE, preconfigured with DHCPv6 option for dslite. This will bring up the DSLite intf, because of the option, why bothering checking the public IPv4 presence ? Maybe this is not really an issue, afterall, it's a configuration "mistake". =20 So my recommendation here would be to remove this requirement. =20 =20 ------_=_NextPart_001_01CCA10B.C40327FE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Wuyts,

 

Sorry for the delayed = reply.   The bullet is correct.  If a CPE router WAN has = a public IPv4 address, then the router can send data over the native = IPv4 network so why invoke DS-Lite?  As for your error related = comments/questions, please see the Coexistence section of the document = version -02.  See bullets 1 and 3 where a specific order is = specified and if the CE follows the order there is les chance of = mistake.   

 

h= ttp://tools.ietf.org/html/draft-ietf-v6ops-6204bis-02#page-15

 

Thanks for the = review.

 

Hemant

 

From:= = v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of = Wuyts Carl
Sent: Wednesday, November 09, 2011 4:21 = AM
To: v6ops@ietf.org
Subject: [v6ops] = RFC6204bis-02

 

 

1.      = DLW-4:  If the IPv6 CE Router is = configured with a public IPv4 address on its WAN interface, where public = IPv4 address is defined as any address which is not in the private IP = address space specified in [RFC5735] and also not in the reserved IP = address space specified in [RFC6333], then the IPv6 CE Router MUST = disable the DS-Lite B4 element.

 

 =

This one = is not fully ok I’d say.  First of all, the DSlite is = supposed to run on a v6-only intf, hence you could consider it as a = configuration issue in case you have configured a public  IPv4 on = it ?  Even if not, I don’t see what you should have to check = for public IPv4 address presence to bring up (or not) the DSLite = intf.

And then = what happens if the DSLite tunnel is up, and a public IPv4 is being = configured on top ?  Bring it down ?

Imagine = you boot the CPE, preconfigured with DHCPv6 option for dslite.  = This will bring up the DSLite intf, because of the option, why bothering = checking the public IPv4 presence ?

Maybe this = is not really an issue, afterall, it’s a configuration = “mistake”.

 =

So my = recommendation here would be to remove this = requirement.

 =

 

------_=_NextPart_001_01CCA10B.C40327FE-- From joelja@bogus.com Sat Nov 12 01:36:33 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C62FE21F854E for ; Sat, 12 Nov 2011 01:36:33 -0800 (PST) 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 iLHuPLm3y7kf for ; Sat, 12 Nov 2011 01:36:33 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 3596C21F8514 for ; Sat, 12 Nov 2011 01:36:33 -0800 (PST) Received: from dhcp-1437.meeting.ietf.org (dhcp-1437.meeting.ietf.org [130.129.20.55]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id pAC9aTIl016667 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sat, 12 Nov 2011 09:36:31 GMT (envelope-from joelja@bogus.com) Message-ID: <4EBE3E1C.1000905@bogus.com> Date: Sat, 12 Nov 2011 17:36:28 +0800 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Nick Hilliard References: <4EBABB05.8070601@bogus.com> <4EBD3931.7040300@inex.ie> In-Reply-To: <4EBD3931.7040300@inex.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sat, 12 Nov 2011 09:36:33 +0000 (UTC) Cc: draft-ietf-v6ops-ipv6-discard-prefix@tools.ietf.org, IPv6 Ops WG Subject: Re: [v6ops] draft-ietf-v6ops-ipv6-discard-prefix-00 - IANA feeback X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 12 Nov 2011 09:36:33 -0000 On 11/11/11 07:03 , Nick Hilliard wrote: > On 09/11/2011 17:40, Joel jaeggli wrote: >> 3. The IC section currently states that "The prefix should be allocated >> from ::/3" and as we would be taking it from 2001:0000::/23 that >> sentence is probably superfluous. If the author takes a shine to a >> specific /64 from there he could let us know. Otherwise, I propose we >> just take the numerically lowest /64, which would be immediately after >> the TEREDO assignment. We could discuss this with the author in case he >> has operational concerns with that. > > As an author comment, the WG consensus at the last v6ops meeting was > that the prefix should specifically not come from global unicast space. well, we solicted advice, and we recieved it... If we belive that it should not come from the special purpose registry we should be prepared to justify that rfc4773 doesn't apply to the IESG. To review the mailing list history the on our own, discussion looks something like the following: We have one participant using the documentation region: wmaton@ryouko.imsb.nrc.ca In my implementation I have been using the IPv6 documentation prefix, 2001:0DB8::/32, which I admit may be bad practice and make me out to be a bad boy, e pur si muove. (Or, it works for me.) Mark smith says: Where your thoughts to have it come from within 2000::/3, which is perhaps why you chose /32? I think it probably should come from outside of it similar to ULAs, ::1 etc., because I don't think a discard function is dependent on the Internet's global unicast addressing. Once it's outside of 2000::/3, I'd think the chosen size can chosen based on expected use, rather than trying to reasonably fit in with an existing allocation scheme. daniel rosen says: /64s are far less likely to leak into the DFZ. As such, I'd favor to settle on /64 if size doesn't matter for other reasons. rogerj@gmail.com It should be a ::/32 and should be taken from the very end of the same 2000::/3 we are currently using. To pick it from outside the current used address may sound like a good idea, and may be tempting to make it stand out from current addresses. But I'm more afraid that will polute our next go on IPv6. doug barton says: I agree that 3fff:ffff::/32 is a good idea for this purpose. 3ff* is more or less useless for general purposes anyway given the historical Teredo usage. I don't like the idea of using a prefix from a block outside 2000::/3, since we have been operating under the assumption that if we screw something up in this /3 that we can start over in one of the others. I'd hate to cripple that premise. erik kline says: What about something from up near the ULA space? keith moore says: There's always {prefix}::dead:beef fred baker says: In BGP peering, one generally announces the set of prefixes associated with some set of communities, and accepts 2000::/3 or some set of more specific routes after a short list of exclusions. I thought I heard that it should be easy to fail to announce (eg to miss those communities) and that the same filter (2001::/3 plus future IANA allocations to the RIRs) should prevent acceptance if announced. That brings me to suggest that the /64 should be in either ::/3 or e000::/3, as we have various sets of addresses there that have those characteristics. > However, IANA would prefer if it were to come from the special purpose > registry: 2001::/23. > > Regardless of IANA's preferences, I'm still of the opinion that it would > be better to keep to the WG preference. which is fine > Nick > From ichiroumakino@gmail.com Sat Nov 12 02:33:31 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5764321F85C7 for ; Sat, 12 Nov 2011 02:33:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cyZju0Ey4c39 for ; Sat, 12 Nov 2011 02:33:30 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 320A721F84CC for ; Sat, 12 Nov 2011 02:33:30 -0800 (PST) Received: by bkbzv15 with SMTP id zv15so5009708bkb.31 for ; Sat, 12 Nov 2011 02:33:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=BGy6Q4dQORL4QrRpfk4YMn3kjZeeTFpJwgKy2jnUC/A=; b=J2+cOFTPuWoL7jPAMwZEE0ItqFQ+/9tt33dI5wQtW5ijFCjp2R3I5rdxMgtpXH0u2c /clQyxkO/nEwBkalTeFNENN/b3F6FP7Ha4sG+BZyxbibOx6HKh6OWyGSKWLb/3A+c83n I0Qt5dnbuRVZmUcVCCaDhIvNkaVFYCPD1pE7Q= Received: by 10.204.133.216 with SMTP id g24mr4113374bkt.82.1321094007488; Sat, 12 Nov 2011 02:33:27 -0800 (PST) Received: from [192.168.255.4] (46.66.160.22.tmi.telenormobil.no. [46.66.160.22]) by mx.google.com with ESMTPS id cc2sm15002458bkb.8.2011.11.12.02.33.24 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 12 Nov 2011 02:33:25 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Ole Troan In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C303494A91@XMB-RCD-109.cisco.com> Date: Sat, 12 Nov 2011 11:32:18 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <199B5744-200B-4BC3-9056-004D2AE5FEE1@employees.org> References: <867F4B6A1672E541A94676D556793ACD0C263BCDD7@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303494A91@XMB-RCD-109.cisco.com> To: Hemant Singh (shemant) X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org Subject: Re: [v6ops] RFC6204bis-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, 12 Nov 2011 10:33:31 -0000 Hemant, > Sorry for the delayed reply. The bullet is correct. If a CPE router = WAN has a public IPv4 address, then the router can send data over the = native IPv4 network so why invoke DS-Lite? As for your error related = comments/questions, please see the Coexistence section of the document = version -02. See bullets 1 and 3 where a specific order is specified = and if the CE follows the order there is les chance of mistake. =20 > =20 > http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-02#page-15 I think there are some fundamental differences in how CPEs are supposed = to operate and be provisioned. 1) provision the CPE with _all_ information available in the network. = including DS-lite DHCP options, 6rd DHCP options, native IPv6, native IPv4, whatever... and make the CPE intelligently = choose what makes sense. 2) expect the CPE to follow what it is being told to do. meaning that it = gets only provisioned with information that makes sense for it. everything else is a configuration error. if it = gets provisioned with e.g both native IPv6 and 6rd, then it should use both connections as if it is multi-homed. the scenario in 2 is important for the transitioning case between 6rd = and native, likewise I think the same thing applies to ds-lite and the = other shared IPv4 scenarios. I'm in camp 2, and I think the co-existence = text in the draft is wrong. (I think Mark is working on a more complete = text in a 6rd sunsetting draft, and we should probably ask the ds-lite = authors to work through the DS-lite scenario as well). cheers, Ole > =20 > Thanks for the review. > =20 > Hemant > =20 > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Wuyts Carl > Sent: Wednesday, November 09, 2011 4:21 AM > To: v6ops@ietf.org > Subject: [v6ops] RFC6204bis-02 > =20 > =20 > 1. DLW-4: If the IPv6 CE Router is configured with a public IPv4 = address on its WAN interface, where public IPv4 address is defined as = any address which is not in the private IP address space specified in = [RFC5735] and also not in the reserved IP address space specified in = [RFC6333], then the IPv6 CE Router MUST disable the DS-Lite B4 element. > =20 > =20 > This one is not fully ok I=92d say. First of all, the DSlite is = supposed to run on a v6-only intf, hence you could consider it as a = configuration issue in case you have configured a public IPv4 on it ? = Even if not, I don=92t see what you should have to check for public IPv4 = address presence to bring up (or not) the DSLite intf. > And then what happens if the DSLite tunnel is up, and a public IPv4 is = being configured on top ? Bring it down ? > Imagine you boot the CPE, preconfigured with DHCPv6 option for dslite. = This will bring up the DSLite intf, because of the option, why = bothering checking the public IPv4 presence ? > Maybe this is not really an issue, afterall, it=92s a configuration = =93mistake=94. > =20 > So my recommendation here would be to remove this requirement. > =20 > =20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From hansliu@gmail.com Sat Nov 12 05:15:05 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A203E21F85F2 for ; Sat, 12 Nov 2011 05:15:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rw8KlA3xp9rx for ; Sat, 12 Nov 2011 05:15:05 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 211BD21F85EF for ; Sat, 12 Nov 2011 05:15:05 -0800 (PST) Received: by iaeo4 with SMTP id o4so6705996iae.31 for ; Sat, 12 Nov 2011 05:15:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=8qWnH1E4cbym6aEeWKpOJA3+gHcqxABBimPGlJyfcFI=; b=TE9WzMcYX3CGSsPFxk3VPWmsbYp+OTl4jSjSyUsgJmUo58nbBkvJHsBNz0aBsqPLWm CZKhdqosfoB9py7ZLcihb4DY0wh6vbVaIAWuFoF6Bk8btK5ntJzAsVmY546M3VzW1EoX htZzIvjkzooU/aXjeeXCvnZNVPNzZmvn282us= MIME-Version: 1.0 Received: by 10.50.41.196 with SMTP id h4mr16910085igl.42.1321103704819; Sat, 12 Nov 2011 05:15:04 -0800 (PST) Received: by 10.231.172.71 with HTTP; Sat, 12 Nov 2011 05:15:04 -0800 (PST) In-Reply-To: <199B5744-200B-4BC3-9056-004D2AE5FEE1@employees.org> References: <867F4B6A1672E541A94676D556793ACD0C263BCDD7@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303494A91@XMB-RCD-109.cisco.com> <199B5744-200B-4BC3-9056-004D2AE5FEE1@employees.org> Date: Sat, 12 Nov 2011 21:15:04 +0800 Message-ID: From: Hans Liu To: Ole Troan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org Subject: Re: [v6ops] RFC6204bis-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, 12 Nov 2011 13:15:05 -0000 > the scenario in 2 is important for the transitioning case between 6rd and= native, likewise I think the same thing applies to ds-lite and the other s= hared IPv4 scenarios. I'm in camp 2, and I think the co-existence text in t= he draft is wrong. (I think Mark is working on a more complete text in a 6r= d sunsetting draft, and we should probably ask the ds-lite authors to work = through the DS-lite scenario as well). > > cheers, > Ole > > > Agree with Ole on this. Regards, Hans From mark@townsley.net Sat Nov 12 05:19:00 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ABFB21F8505 for ; Sat, 12 Nov 2011 05:19:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.209 X-Spam-Level: X-Spam-Status: No, score=-3.209 tagged_above=-999 required=5 tests=[AWL=-0.210, 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 vfWyiWDH18Cq for ; Sat, 12 Nov 2011 05:18:59 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 842AC21F8591 for ; Sat, 12 Nov 2011 05:18:59 -0800 (PST) Received: by wyf28 with SMTP id 28so3150973wyf.31 for ; Sat, 12 Nov 2011 05:18:58 -0800 (PST) Received: by 10.227.204.132 with SMTP id fm4mr10346035wbb.26.1321103938665; Sat, 12 Nov 2011 05:18:58 -0800 (PST) Received: from ams-townsley-8711.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id w27sm2524775wbm.5.2011.11.12.05.18.55 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 12 Nov 2011 05:18:56 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Mark Townsley In-Reply-To: <199B5744-200B-4BC3-9056-004D2AE5FEE1@employees.org> Date: Sat, 12 Nov 2011 14:18:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <712EE896-7B46-4F63-A354-678AC4DEA302@townsley.net> References: <867F4B6A1672E541A94676D556793ACD0C263BCDD7@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303494A91@XMB-RCD-109.cisco.com> <199B5744-200B-4BC3-9056-004D2AE5FEE1@employees.org> To: Ole Troan X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org Subject: Re: [v6ops] RFC6204bis-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, 12 Nov 2011 13:19:00 -0000 On Nov 12, 2011, at 11:32 AM, Ole Troan wrote: > Hemant, >=20 >> Sorry for the delayed reply. The bullet is correct. If a CPE = router WAN has a public IPv4 address, then the router can send data over = the native IPv4 network so why invoke DS-Lite? As for your error = related comments/questions, please see the Coexistence section of the = document version -02. See bullets 1 and 3 where a specific order is = specified and if the CE follows the order there is les chance of = mistake. =20 >>=20 >> http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-02#page-15 >=20 > I think there are some fundamental differences in how CPEs are = supposed to operate and be provisioned. >=20 > 1) provision the CPE with _all_ information available in the network. = including DS-lite DHCP options, 6rd DHCP options, > native IPv6, native IPv4, whatever... and make the CPE intelligently = choose what makes sense. >=20 > 2) expect the CPE to follow what it is being told to do. meaning that = it gets only provisioned with information that > makes sense for it. everything else is a configuration error. if it = gets provisioned with e.g both native IPv6 and 6rd, > then it should use both connections as if it is multi-homed. >=20 > the scenario in 2 is important for the transitioning case between 6rd = and native, likewise I think the same thing applies to ds-lite and the = other shared IPv4 scenarios. I'm in camp 2, and I think the co-existence = text in the draft is wrong. (I think Mark is working on a more complete = text in a 6rd sunsetting draft, and we should probably ask the ds-lite = authors to work through the DS-lite scenario as well). Yes, I am, in conjunction with the 6rd experts at Free. You should see = something very soon. - Mark >=20 > cheers, > Ole >=20 >=20 >=20 >>=20 >> Thanks for the review. >>=20 >> Hemant >>=20 >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On = Behalf Of Wuyts Carl >> Sent: Wednesday, November 09, 2011 4:21 AM >> To: v6ops@ietf.org >> Subject: [v6ops] RFC6204bis-02 >>=20 >>=20 >> 1. DLW-4: If the IPv6 CE Router is configured with a public = IPv4 address on its WAN interface, where public IPv4 address is defined = as any address which is not in the private IP address space specified in = [RFC5735] and also not in the reserved IP address space specified in = [RFC6333], then the IPv6 CE Router MUST disable the DS-Lite B4 element. >>=20 >>=20 >> This one is not fully ok I=92d say. First of all, the DSlite is = supposed to run on a v6-only intf, hence you could consider it as a = configuration issue in case you have configured a public IPv4 on it ? = Even if not, I don=92t see what you should have to check for public IPv4 = address presence to bring up (or not) the DSLite intf. >> And then what happens if the DSLite tunnel is up, and a public IPv4 = is being configured on top ? Bring it down ? >> Imagine you boot the CPE, preconfigured with DHCPv6 option for = dslite. This will bring up the DSLite intf, because of the option, why = bothering checking the public IPv4 presence ? >> Maybe this is not really an issue, afterall, it=92s a configuration = =93mistake=94. >>=20 >> So my recommendation here would be to remove this requirement. >>=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 From sander@steffann.nl Sat Nov 12 12:15:16 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC2C021F8A7A for ; Sat, 12 Nov 2011 12:15:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.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 CKPZSlzEbsb0 for ; Sat, 12 Nov 2011 12:15:16 -0800 (PST) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id 34A1921F8A66 for ; Sat, 12 Nov 2011 12:15:16 -0800 (PST) Received: from [10.87.2.166] (unknown [80.187.212.54]) by mail.sintact.nl (Postfix) with ESMTP id D55F22021; Sat, 12 Nov 2011 21:15:08 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Sander Steffann In-Reply-To: <199B5744-200B-4BC3-9056-004D2AE5FEE1@employees.org> Date: Sat, 12 Nov 2011 21:15:06 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6E7FD1ED-42E2-412E-9766-56B7612B21AF@steffann.nl> References: <867F4B6A1672E541A94676D556793ACD0C263BCDD7@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303494A91@XMB-RCD-109.cisco.com> <199B5744-200B-4BC3-9056-004D2AE5FEE1@employees.org> To: Ole Troan X-Mailer: Apple Mail (2.1251.1) Cc: v6ops@ietf.org Subject: Re: [v6ops] RFC6204bis-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, 12 Nov 2011 20:15:17 -0000 Hi Ole, > 2) expect the CPE to follow what it is being told to do. meaning that = it gets only provisioned with information that > makes sense for it. everything else is a configuration error. if it = gets provisioned with e.g both native IPv6 and 6rd, > then it should use both connections as if it is multi-homed. >=20 > the scenario in 2 is important for the transitioning case between 6rd = and native, likewise I think the same thing applies to ds-lite and the = other shared IPv4 scenarios. I'm in camp 2, and I think the co-existence = text in the draft is wrong. (I think Mark is working on a more complete = text in a 6rd sunsetting draft, and we should probably ask the ds-lite = authors to work through the DS-lite scenario as well). I agree fully. If we take migrations from one technology to another into = account now we will make our (well, ISP / network operator) lives a = *lot* easier in the future. Met vriendelijke groet, Sander Steffann From shemant@cisco.com Sat Nov 12 17:48:36 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D52711E808D for ; Sat, 12 Nov 2011 17:48:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.139 X-Spam-Level: X-Spam-Status: No, score=-6.139 tagged_above=-999 required=5 tests=[AWL=0.460, 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 zFOoP3NpHscj for ; Sat, 12 Nov 2011 17:48:35 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 8CDC811E8083 for ; Sat, 12 Nov 2011 17:48:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=1218; q=dns/txt; s=iport; t=1321148915; x=1322358515; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=OpxP7ibP+iJWsDicxdisdaj/Hv7aACRqVUvY3kDpEaU=; b=jG9xOKKJXukjSfRa7JbNcrAg/jVSWJEEvGWpyjq0Eh7oP84lYZa4ZSdV 33ONxr9OVyrYVeKqoOXawoef9j9joSKOVA/VFb6LGqs+z8TVEiirs+DhK +YiA3b/CfAYH1iPlij9INTLa1U65rvozAMu976CkFCSDPhbf7r16ZgbQf g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArEAANIhv06tJV2b/2dsb2JhbABCmimQBoEFgXIBAQEEEgEdCj8MBAIBCA4DBAEBCwYXAQYBICUJCAEBBBMIGqAsAZ0qiRxjBIgQkWKFB4dN X-IronPort-AV: E=Sophos;i="4.69,501,1315180800"; d="scan'208";a="35390195" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 13 Nov 2011 01:48:34 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pAD1mk2P006257; Sun, 13 Nov 2011 01:48:46 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 12 Nov 2011 19:48:34 -0600 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 12 Nov 2011 19:48:31 -0600 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C303494AF6@XMB-RCD-109.cisco.com> In-Reply-To: <199B5744-200B-4BC3-9056-004D2AE5FEE1@employees.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] RFC6204bis-02 Thread-Index: AcyhJoXSSJeoOWbsTOm5S/W31p/9FwAft6Jw References: <867F4B6A1672E541A94676D556793ACD0C263BCDD7@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303494A91@XMB-RCD-109.cisco.com> <199B5744-200B-4BC3-9056-004D2AE5FEE1@employees.org> From: "Hemant Singh (shemant)" To: "Ole Troan" X-OriginalArrivalTime: 13 Nov 2011 01:48:34.0024 (UTC) FILETIME=[5A66EE80:01CCA1A6] Cc: v6ops@ietf.org Subject: Re: [v6ops] RFC6204bis-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, 13 Nov 2011 01:48:36 -0000 -----Original Message----- From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of Ole Troan Sent: Saturday, November 12, 2011 5:32 AM To: Hemant Singh (shemant) Cc: Wuyts Carl; v6ops@ietf.org Subject: Re: [v6ops] RFC6204bis-02 >2) expect the CPE to follow what it is being told to do. meaning that it gets only provisioned with information that > makes sense for it. everything else is a configuration error. if it gets provisioned with e.g both native IPv6 and 6rd, > then it should use both connections as if it is multi-homed. Already specified in the Coexistence section for how does 6rd work with native IPv6 - see bullet 5 of the -02 version posted. Then the sunsetting of 6rd to move to native IPv6 is discussed in a paragraph below the bullets of the Coexistence section. >the other shared IPv4 scenarios. I'm in camp 2, and I think the co-existence text in the draft is wrong.=20 What specifically is wrong? During emails in Softwires in the past year one Int area AD has already said the IPv6 CE router includes a Coexistence section because someone asked how does the CE router know how to start DS-Lite, vs. 6rd, vs. IPv4 or IPv6 native tech. =20 Hemant =20 From marka@isc.org Sat Nov 12 23:00:33 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4753411E80BB for ; Sat, 12 Nov 2011 23:00:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.444 X-Spam-Level: X-Spam-Status: No, score=-0.444 tagged_above=-999 required=5 tests=[AWL=-2.145, BAYES_00=-2.599, J_CHICKENPOX_110=0.6, J_CHICKENPOX_13=0.6, MANGLED_MEDS=2.3, SARE_BAYES_5x8=0.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 fAK-rkyLyGD4 for ; Sat, 12 Nov 2011 23:00:32 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id B6FA311E80AC for ; Sat, 12 Nov 2011 23:00:31 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id A27465F98B1; Sun, 13 Nov 2011 07:00:10 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id F1EF1216C83; Sun, 13 Nov 2011 07:00:07 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 583DD17137B8; Sun, 13 Nov 2011 18:00:05 +1100 (EST) To: "Hemant Singh (shemant)" From: Mark Andrews References: <867F4B6A1672E541A94676D556793ACD0C263BCDD7@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303494A91@XMB-RCD-109.cisco.com> In-reply-to: Your message of "Sat, 12 Nov 2011 01:21:56 MDT." <5B6B2B64C9FE2A489045EEEADDAFF2C303494A91@XMB-RCD-109.cisco.com> Date: Sun, 13 Nov 2011 18:00:05 +1100 Message-Id: <20111113070005.583DD17137B8@drugs.dv.isc.org> Cc: v6ops@ietf.org Subject: Re: [v6ops] RFC6204bis-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, 13 Nov 2011 07:00:33 -0000 In message <5B6B2B64C9FE2A489045EEEADDAFF2C303494A91@XMB-RCD-109.cisco.com>, "He mant Singh (shemant)" writes: > > Wuyts, > > Sorry for the delayed reply. The bullet is correct. If a CPE router > WAN has a public IPv4 address, then the router can send data over the > native IPv4 network so why invoke DS-Lite? As for your error related > comments/questions, please see the Coexistence section of the document > version -02. See bullets 1 and 3 where a specific order is specified > and if the CE follows the order there is les chance of mistake. =20 > > http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-02#page-15 > > Thanks for the review. > > Hemant Personally this is being over prescriptive. Today we have CPE being presented what appear to be public address but in practice are NAT'd addresses. If it is reasonable to run DS-lite with RFC 1918 addresses on the WAN interface it is reasonable to run DS-lite with what appear to be public addresses on the WAN interface. It is also reasonable to run DS-Lite on top of 6rd especially when the addresses being used for 6rd are ambigious. It really isn't that hard to get the routing correct. Yes, there is double encapsulation but the payoff is a single NAT layer. DS-Lite options learnt on the WAN interface SHOULD be made available on the LAN interfaces even if there is no B4 functionality in the CPE. This allows individual ipv6-only nodes to use DS-Lite. > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Wuyts Carl > Sent: Wednesday, November 09, 2011 4:21 AM > To: v6ops@ietf.org > Subject: [v6ops] RFC6204bis-02 > > =20 > > =20 > > 1. DLW-4: If the IPv6 CE Router is configured with a public IPv4 > address on its WAN interface, where public IPv4 address is defined as > any address which is not in the private IP address space specified in > [RFC5735] and also not in the reserved IP address space specified in > [RFC6333], then the IPv6 CE Router MUST disable the DS-Lite B4 element. > > =20 > > =20 > > This one is not fully ok I'd say. First of all, the DSlite is supposed > to run on a v6-only intf, hence you could consider it as a configuration > issue in case you have configured a public IPv4 on it ? Even if not, I > don't see what you should have to check for public IPv4 address presence > to bring up (or not) the DSLite intf. > > And then what happens if the DSLite tunnel is up, and a public IPv4 is > being configured on top ? Bring it down ? > > Imagine you boot the CPE, preconfigured with DHCPv6 option for dslite. > This will bring up the DSLite intf, because of the option, why bothering > checking the public IPv4 presence ? > > Maybe this is not really an issue, afterall, it's a configuration > "mistake". > > =20 > > So my recommendation here would be to remove this requirement. > > =20 > > =20 > > > ------_=_NextPart_001_01CCA10B.C40327FE > Content-Type: text/html; > charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > xmlns:o=3D"urn:schemas-microsoft-com:office:office" = > xmlns:w=3D"urn:schemas-microsoft-com:office:word" = > xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" = > xmlns=3D"http://www.w3.org/TR/REC-html40"> http-equiv=3DContent-Type content=3D"text/html; = > charset=3Dus-ascii"> (filtered medium)"> vlink=3Dpurple>

style=3D'color:#1F497D'>Wuyts,

class=3DMsoNormal> style=3D'color:#1F497D'> 

class=3DMsoNormal>Sorry for the delayed = > reply.   The bullet is correct.  If a CPE router WAN has = > a public IPv4 address, then the router can send data over the native = > IPv4 network so why invoke DS-Lite?  As for your error related = > comments/questions, please see the Coexistence section of the document = > version -02.  See bullets 1 and 3 where a specific order is = > specified and if the CE follows the order there is les chance of = > mistake.   

style=3D'color:#1F497D'> 

class=3DMsoNormal> href=3D"http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-02#page-15">h= > ttp://tools.ietf.org/html/draft-ietf-v6ops-6204bis-02#page-15 :p>

style=3D'color:#1F497D'> 

class=3DMsoNormal>Thanks for the = > review.

style=3D'color:#1F497D'> 

class=3DMsoNormal> style=3D'color:#1F497D'>Hemant

class=3DMsoNormal> style=3D'color:#1F497D'> 

style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in = > 0in 0in'>

style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:= > = > v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of = > Wuyts Carl
Sent: Wednesday, November 09, 2011 4:21 = > AM
To: v6ops@ietf.org
Subject: [v6ops] = > RFC6204bis-02

class=3DMsoNormal> 

class=3DMsoNormal> 

style=3D'text-indent:-.25in;mso-list:l0 level1 lfo2'> !supportLists]>1. style=3D'font:7.0pt "Times New Roman"'>      = > DLW-4:  If the IPv6 CE Router is = > configured with a public IPv4 address on its WAN interface, where public = > IPv4 address is defined as any address which is not in the private IP = > address space specified in [RFC5735] and also not in the reserved IP = > address space specified in [RFC6333], then the IPv6 CE Router MUST = > disable the DS-Lite B4 element.

class=3DMsoPlainText> style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'> style=3D'text-decoration:none'> 

class=3DMsoPlainText> style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'> = >

style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>This one = > is not fully ok I’d say.  First of all, the DSlite is = > supposed to run on a v6-only intf, hence you could consider it as a = > configuration issue in case you have configured a public  IPv4 on = > it ?  Even if not, I don’t see what you should have to check = > for public IPv4 address presence to bring up (or not) the DSLite = > intf.

style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>And then = > what happens if the DSLite tunnel is up, and a public IPv4 is being = > configured on top ?  Bring it down ?

class=3DMsoPlainText> style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>Imagine = > you boot the CPE, preconfigured with DHCPv6 option for dslite.  = > This will bring up the DSLite intf, because of the option, why bothering = > checking the public IPv4 presence ?

class=3DMsoPlainText> style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>Maybe this = > is not really an issue, afterall, it’s a configuration = > “mistake”.

class=3DMsoPlainText> style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'> = >

style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>So my = > recommendation here would be to remove this = > requirement.

style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'> = >

class=3DMsoNormal> 

> ------_=_NextPart_001_01CCA10B.C40327FE-- > > --===============8555349567329490546== > Content-Type: text/plain; charset="us-ascii" > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --===============8555349567329490546==-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From bertietf@bwijnen.net Sun Nov 13 00:33:59 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20E9621F8512 for ; Sun, 13 Nov 2011 00:33:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 11YmdtLlH7ZR for ; Sun, 13 Nov 2011 00:33:58 -0800 (PST) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id 51E3921F893C for ; Sun, 13 Nov 2011 00:33:58 -0800 (PST) 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 1RPVVk-0002Zn-0F; Sun, 13 Nov 2011 09:33:57 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1RPVVh-000577-OB; Sun, 13 Nov 2011 09:33:54 +0100 Message-ID: <4EBF80EC.8060907@bwijnen.net> Date: Sun, 13 Nov 2011 16:33:48 +0800 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <4EBF7777.8040206@ripe.net> In-Reply-To: <4EBF7777.8040206@ripe.net> X-Forwarded-Message-Id: <4EBF7777.8040206@ripe.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4f2e47c7b75fa4bca2b04fed88f0f84da Cc: Mirjam Kuehne Subject: [v6ops] New on RIPE Labs: Hampered Eyeballs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 13 Nov 2011 08:33:59 -0000 FYI, I think this info is relevant to this working group, because it discusses implementation of the WG's happy eyeballs document. Enjoy. Bert -------- Original Message -------- Subject: New on RIPE Labs: Hampered Eyeballs Date: Sun, 13 Nov 2011 08:53:27 +0100 From: Mirjam Kuehne Reply-To: iepg@iepg.org To: iepg@iepg.org Hi, There is a new post on RIPE Labs (written by Emile Aben) that might be interesting to you (and Bert Wijnen might have referred to it during the IEPG meeting): Hampered Eyeballs - Observations on Two "Happy Eyeballs" Implementations https://labs.ripe.net/Members/emileaben/hampered-eyeballs Kind Regards, Mirjam Kuehne RIPE NCC From bingxuere@gmail.com Sun Nov 13 18:30:24 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35AA41F0C72 for ; Sun, 13 Nov 2011 18:30:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.947 X-Spam-Level: X-Spam-Status: No, score=-2.947 tagged_above=-999 required=5 tests=[AWL=0.052, 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 ykYpt46rAs+k for ; Sun, 13 Nov 2011 18:30:23 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7B8121F0C76 for ; Sun, 13 Nov 2011 18:30:23 -0800 (PST) Received: by iaeo4 with SMTP id o4so8652195iae.31 for ; Sun, 13 Nov 2011 18:30:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=DCIR8/MI+uvzzwRonSeLIwboFYATEmo82KvKH9bm/lk=; b=B5OxjM8Nhx1WlS/1v0YaDCFGF5BqDa+cnfsxErmnpbNJivKch7tKkjHClxVrQaCHqZ bpNQDbVhYYu4h80+J3EsU7yK2z8TJ2KQvildf9p27+o6UT8SuYnwpFU/nfpe7sEAA4mF e0AaBaPPZBJ4hHy2YMJWWV9Qwm+cNE4etbDk4= Received: by 10.42.154.7 with SMTP id o7mr20783580icw.48.1321237823089; Sun, 13 Nov 2011 18:30:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.223.197 with HTTP; Sun, 13 Nov 2011 18:29:42 -0800 (PST) In-Reply-To: <4EBC6599.6030002@bogus.com> References: <4EB05384.5000007@gmail.com> <4EB54C85.4050909@bogus.com> <4EBC6599.6030002@bogus.com> From: Qiong Date: Mon, 14 Nov 2011 10:29:42 +0800 Message-ID: To: Joel jaeggli Content-Type: text/plain; charset=UTF-8 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Fwd: New Version Notification for draft-sunq-v6ops-contents-transition-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: Mon, 14 Nov 2011 02:30:24 -0000 Hi Joel, Thanks for your explaination. I now understand your points clearly. Please see inline :) > On 11/7/11 22:13 , Qiong wrote: >> Hi, Joel >> >> On Sat, Nov 5, 2011 at 10:47 PM, Joel jaeggli > > wrote: >> >>> After all, dual stack is what we have discussing for 10 years. But >> up to >>> now, how many ICPs have upgraded to IPv6 in dual-stack directly? I >>> really think we need to re-think it again, from both technical aspect >>> and the industry/or market aspect. And the first step is rather >>> important to give us confidence to move forward. That's why we >> recommend >>> single-stack (either v4 or v6) transition in the current phase. Then, >>> for the conservative ones, the IPv4 services can be still offered >>> natively, and the IPv6 services can be offered by the stateful NAT64; >>> while for progressive ones and newly comers, the stateless IVI can be >>> employed to offer native IPv6 services reachable via IPv4. And we hope >>> it would help enrich IPv6 content asap. Then how do you think ? >> >> Any solution that causes me to lose access to the source address is not >> usable from my vantage point as a content provider. When I terminate >> connections on an l7 load balancer as I generally do for http/https on >> ipv4 and where we do it in ipv6 I can drop x-forwarded for in there. >> That requires that I recieve the traffic unmolested by a nat transform >> associated with my own service. >> >> I agree it is important. But there is another question here : although >> you can use l7 load balancer to insert x-forwarded here, how can you >> guarantee that there is no CGN along the path from the user's end-host >> to the data center. > > I don't have to, what I need is a granular enough view of where the > address sharing is occuring that I can serve my content accordingly. > it's not a problem for example if ~200,000 mobile users of an app at > Indonesia's 3rd largest mobile operator emerge from behind a /22 Well, in that case, it would be much simpler. But the situation in our network, is that we do have address exhaustion problem. I think this will become common problem for most operators sooner or later, and we somehow have to adopt some kind of address sharing approach in our network. >> I mean, in case we cannot avoid deploying some kind >> of address sharing mechanisms in the future, ICPs have to face the fact > > you'll note that I'm assuming the existence of address sharing > mechanisms on both sides of the conversation. I'd very much prefer that > the one working on my behalf not necessarily throw out information as a > product of it's design. I think this is a tradeoff, and we would discuss it more clearly in the next version. > >> that they will somehow lose the geo-location info when they receive IPv4 >> traffic. So maybe it is one choice to provide them with a database which >> stores the original binding information. Would it be some kind of helpful ? > > where are you going to put that and signal it? We have offered an web-service based API and the content provider can use it to retrieve its original IPv6 address when receiving an IPv4 packet. Best wishes Qiong >> Thanks >> >> Best wishes >> >> Qiong >> >> >> >>> Thanks >>> >>> Qiong >>> >>> >>> On Wed, Nov 2, 2011 at 4:16 AM, Brian E Carpenter >>> >> > >> wrote: >>> >>> I'm not seeing why this is a better solution for a >> small/medium ICP >>> than just moving to a dual stack. That is much easier for a small >>> network than for a big one. >>> >>> Regards >>> Brian >>> >>> >>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >> >> > From teco@inf-net.nl Sun Nov 13 23:30:02 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9BF011E80FE for ; Sun, 13 Nov 2011 23:30:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.52 X-Spam-Level: X-Spam-Status: No, score=-3.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 MwgFZJHXmeFt for ; Sun, 13 Nov 2011 23:30:02 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2E52211E80CE for ; Sun, 13 Nov 2011 23:30:02 -0800 (PST) Received: by yenq4 with SMTP id q4so3005599yen.31 for ; Sun, 13 Nov 2011 23:30:01 -0800 (PST) Received: by 10.236.124.17 with SMTP id w17mr12422479yhh.126.1321255801811; Sun, 13 Nov 2011 23:30:01 -0800 (PST) Received: from dhcp-13af.meeting.ietf.org (dhcp-13af.meeting.ietf.org. [130.129.19.175]) by mx.google.com with ESMTPS id r4sm58927905anl.5.2011.11.13.23.29.59 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 13 Nov 2011 23:30:01 -0800 (PST) From: Teco Boot Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Nov 2011 08:29:57 +0100 Message-Id: <41172287-6CA2-4B06-8355-2E3463057DA0@inf-net.nl> To: v6ops@ietf.org Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Subject: [v6ops] Enterprises and draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 Nov 2011 07:30:03 -0000 In 6renum wg (enterprise renumbering), we have a need for egress router = selection based on source address. This topic would be in scope of = draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat. But IMHO current = version sticks to very small sites. Enterprises have often a multi-hop = path between hosts and egress routers. Add such scenario in the = document? Current text and diagram in section 3.2 nicely explains the IPv4-NAPT = approach. We already know how this works. Replace with something = focussed on an IPv6 network? Teco.= From fred@cisco.com Sun Nov 13 23:41:19 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 673E311E8175 for ; Sun, 13 Nov 2011 23:41:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.874 X-Spam-Level: X-Spam-Status: No, score=-107.874 tagged_above=-999 required=5 tests=[AWL=-1.275, 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 Uxyv8OJ8X+R1 for ; Sun, 13 Nov 2011 23:41:18 -0800 (PST) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id B900411E80FE for ; Sun, 13 Nov 2011 23:41:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=801; q=dns/txt; s=iport; t=1321256477; x=1322466077; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=okoiewQMIoT/u37ht4Y3BnLgmEtcnGO2vxR6et4/4Jg=; b=g/yHNqxOdAEwsNv1bPOJHS1X79JBOFQxpCwwslihUdO43FiXLBMTFXqd WZNh+mx+GvSvF3PPKbhcKe8aT7V7hxODtCEqNx2gWxMAOu/gEgbEEG4X2 WIDdTlE2xQNMXDoFTndkMFQTsoxx/VxqaaQb2/MulNAwNOgEZklYi0a9a w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAOTEwE5Io8UQ/2dsb2JhbABCqX2BBYFyAQEBAwESASc/BQsLGC5XBjWHYJk0AZ1UiRxjBIgOjCCFO4xL X-IronPort-AV: E=Sophos;i="4.69,507,1315180800"; d="scan'208";a="2994987" Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-3.cisco.com with ESMTP; 14 Nov 2011 07:41:16 +0000 Received: from dhcp-57cd.meeting.ietf.org (hkidc-vpn-client-233-43.cisco.com [10.75.233.43]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pAE7fECK007763; Mon, 14 Nov 2011 07:41:14 GMT Received: from [127.0.0.1] by dhcp-57cd.meeting.ietf.org (PGP Universal service); Mon, 14 Nov 2011 15:41:14 +0800 X-PGP-Universal: processed; by dhcp-57cd.meeting.ietf.org on Mon, 14 Nov 2011 15:41:14 +0800 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <41172287-6CA2-4B06-8355-2E3463057DA0@inf-net.nl> Date: Mon, 14 Nov 2011 15:41:01 +0800 Message-Id: <60827AA3-F326-4CB0-96C7-F74687ED614E@cisco.com> References: <41172287-6CA2-4B06-8355-2E3463057DA0@inf-net.nl> To: Teco Boot X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org Subject: Re: [v6ops] Enterprises and draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 Nov 2011 07:41:19 -0000 On Nov 14, 2011, at 3:29 PM, Teco Boot wrote: > In 6renum wg (enterprise renumbering), we have a need for egress = router selection based on source address. This topic would be in scope = of draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat. But IMHO current = version sticks to very small sites. Enterprises have often a multi-hop = path between hosts and egress routers. Add such scenario in the = document? Why is exit routing not a routing problem? I would think it is an = appropriate topic for a model such as draft-baker-fun-routing-class > Current text and diagram in section 3.2 nicely explains the IPv4-NAPT = approach. We already know how this works. Replace with something = focussed on an IPv6 network? That would be the province of tools like RFC 6296...= From joelja@bogus.com Sun Nov 13 23:47:59 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7810911E821C for ; Sun, 13 Nov 2011 23:47:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.224 X-Spam-Level: X-Spam-Status: No, score=-102.224 tagged_above=-999 required=5 tests=[AWL=-0.225, 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 YVo7OTxc7aqh for ; Sun, 13 Nov 2011 23:47:59 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id F1E4111E8201 for ; Sun, 13 Nov 2011 23:47:58 -0800 (PST) Received: from dhcp-2510.meeting.ietf.org (dhcp-2510.meeting.ietf.org [130.129.37.16]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id pAE7lsnv065247 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Mon, 14 Nov 2011 07:47:56 GMT (envelope-from joelja@bogus.com) Message-ID: <4EC0C7A9.900@bogus.com> Date: Mon, 14 Nov 2011 15:47:53 +0800 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Fred Baker References: <41172287-6CA2-4B06-8355-2E3463057DA0@inf-net.nl> <60827AA3-F326-4CB0-96C7-F74687ED614E@cisco.com> In-Reply-To: <60827AA3-F326-4CB0-96C7-F74687ED614E@cisco.com> 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]); Mon, 14 Nov 2011 07:47:57 +0000 (UTC) Cc: v6ops@ietf.org Subject: Re: [v6ops] Enterprises and draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 Nov 2011 07:47:59 -0000 On 11/14/11 15:41 , Fred Baker wrote: > > > On Nov 14, 2011, at 3:29 PM, Teco Boot wrote: >> In 6renum wg (enterprise renumbering), we have a need for egress >> router selection based on source address. This topic would be in >> scope of draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat. But >> IMHO current version sticks to very small sites. Enterprises have >> often a multi-hop path between hosts and egress routers. Add such >> scenario in the document? > > Why is exit routing not a routing problem? I would think it is an > appropriate topic for a model such as draft-baker-fun-routing-class there's always rh0... >> Current text and diagram in section 3.2 nicely explains the >> IPv4-NAPT approach. We already know how this works. Replace with >> something focussed on an IPv6 network? > > That would be the province of tools like RFC 6296... > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From fred@cisco.com Sun Nov 13 23:56:20 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B88B11E824E for ; Sun, 13 Nov 2011 23:56:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.549 X-Spam-Level: X-Spam-Status: No, score=-109.549 tagged_above=-999 required=5 tests=[AWL=0.450, 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 WBluaAG-tHy8 for ; Sun, 13 Nov 2011 23:56:19 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 05E2311E824C for ; Sun, 13 Nov 2011 23:56:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1239; q=dns/txt; s=iport; t=1321257379; x=1322466979; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=9LdAGvYa8yR9tVzuhowQ4VoR1XdlGfyZPeBLRz2HvYs=; b=KMRxmoQquhvs/2+HWtvZCCVYwO14HMh3bHgrKK6D/bPaIUgZn7BomOB3 10m6RGrwrnIBmCyxNW2QRybHrcd6gUtWZkCEIppGpM2D/pwTT9i0DQPDQ MNLjLNDWHgsx6Uvh5ePv81TfWpgWrUimbuZayBAtjIfMl0WaH73BlaJ1G o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAGHIwE5Io8US/2dsb2JhbABCqX2BBYFyAQEBAwEBAQEPASc0CwULCxguJzAGEyKHYAiZJQGdUASJHGMEiA6MIIU7jEs X-IronPort-AV: E=Sophos;i="4.69,507,1315180800"; d="scan'208";a="121512070" Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-1.cisco.com with ESMTP; 14 Nov 2011 07:56:17 +0000 Received: from dhcp-57cd.meeting.ietf.org (hkidc-vpn-client-233-43.cisco.com [10.75.233.43]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pAE7tIQC018575; Mon, 14 Nov 2011 07:56:15 GMT Received: from [127.0.0.1] by dhcp-57cd.meeting.ietf.org (PGP Universal service); Mon, 14 Nov 2011 15:56:16 +0800 X-PGP-Universal: processed; by dhcp-57cd.meeting.ietf.org on Mon, 14 Nov 2011 15:56:16 +0800 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <4EC0C7A9.900@bogus.com> Date: Mon, 14 Nov 2011 15:56:15 +0800 Message-Id: <5AF30972-563D-4E93-87F0-68E78535DD0F@cisco.com> References: <41172287-6CA2-4B06-8355-2E3463057DA0@inf-net.nl> <60827AA3-F326-4CB0-96C7-F74687ED614E@cisco.com> <4EC0C7A9.900@bogus.com> To: Joel jaeggli X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org Subject: Re: [v6ops] Enterprises and draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 Nov 2011 07:56:20 -0000 On Nov 14, 2011, at 3:47 PM, Joel jaeggli wrote: > On 11/14/11 15:41 , Fred Baker wrote: >> >>=20 >> On Nov 14, 2011, at 3:29 PM, Teco Boot wrote: >>> In 6renum wg (enterprise renumbering), we have a need for egress >>> router selection based on source address. This topic would be in >>> scope of draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat. But >>> IMHO current version sticks to very small sites. Enterprises have >>> often a multi-hop path between hosts and egress routers. Add such >>> scenario in the document? >>=20 >> Why is exit routing not a routing problem? I would think it is an >> appropriate topic for a model such as draft-baker-fun-routing-class >=20 > >=20 > there's always rh0... There is, if one knows what address to rh0 to; I don't know of any hosts = that know that... >>> Current text and diagram in section 3.2 nicely explains the >>> IPv4-NAPT approach. We already know how this works. Replace with >>> something focussed on an IPv6 network? >>=20 >> That would be the province of tools like RFC 6296...=20 >> _______________________________________________ v6ops mailing list=20 >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >>=20 >=20 From teco@inf-net.nl Mon Nov 14 00:04:17 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D2CA11E8266 for ; Mon, 14 Nov 2011 00:04:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.376 X-Spam-Level: X-Spam-Status: No, score=-2.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 O7B5A+bX-w7p for ; Mon, 14 Nov 2011 00:04:16 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 394B511E80B5 for ; Mon, 14 Nov 2011 00:04:14 -0800 (PST) Received: by wwe5 with SMTP id 5so2825212wwe.13 for ; Mon, 14 Nov 2011 00:04:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.227.205.135 with SMTP id fq7mr765447wbb.19.1321257853192; Mon, 14 Nov 2011 00:04:13 -0800 (PST) Received: by 10.227.69.143 with HTTP; Mon, 14 Nov 2011 00:04:13 -0800 (PST) In-Reply-To: <60827AA3-F326-4CB0-96C7-F74687ED614E@cisco.com> References: <41172287-6CA2-4B06-8355-2E3463057DA0@inf-net.nl> <60827AA3-F326-4CB0-96C7-F74687ED614E@cisco.com> Date: Mon, 14 Nov 2011 09:04:13 +0100 Message-ID: From: Teco Boot To: Fred Baker Content-Type: multipart/alternative; boundary=0015176f0824ff0acf04b1ad5020 Cc: v6ops@ietf.org Subject: Re: [v6ops] Enterprises and draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 Nov 2011 08:04:17 -0000 --0015176f0824ff0acf04b1ad5020 Content-Type: text/plain; charset=ISO-8859-1 2011/11/14 Fred Baker > > > On Nov 14, 2011, at 3:29 PM, Teco Boot wrote: > > In 6renum wg (enterprise renumbering), we have a need for egress router > selection based on source address. This topic would be in scope of > draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat. But IMHO current version > sticks to very small sites. Enterprises have often a multi-hop path between > hosts and egress routers. Add such scenario in the document? > > Why is exit routing not a routing problem? I would think it is an > appropriate topic for a model such as draft-baker-fun-routing-class Sure. The BRDP-based routing model is fun also, although less fundamental. I don't care v6ops or 6renum produces a gap analysis doc to kick some wg in routing area. > > Current text and diagram in section 3.2 nicely explains the IPv4-NAPT > approach. We already know how this works. Replace with something focussed > on an IPv6 network? > > That would be the province of tools like RFC 6296... I thought the goal of this draft is try to avoid? Teco. --0015176f0824ff0acf04b1ad5020 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2011/11/14 Fred Baker = <fred@cisco.com>
</chair>

On Nov 14, 2011, at 3:29 PM, Teco Boot wrote:
> In 6renum wg (enterprise renumbering), we have a need for egress route= r selection based on source address. This topic would be in scope of draft-= ietf-v6ops-ipv6-multihoming-without-ipv6nat. But IMHO current version stick= s to very small sites. Enterprises have often a multi-hop path between host= s and egress routers. Add such scenario in the document?

Why is exit routing not a routing problem? I would think it is an app= ropriate topic for a model such as draft-baker-fun-routing-class
Sure. The BRDP-based routing model is fun also, although less fundam= ental.

I don't care v6ops or=A06renum produces a gap analy= sis doc to kick some wg in routing area.

=A0
=
> Current text and diagram in section 3.2 nicely explains the IPv4-NAPT = approach. We already know how this works. Replace with something focussed o= n an IPv6 network?

That would be the province of tools like RFC 6296...

I thought the goal of this draft is try to avoid?

Teco.
=A0

--0015176f0824ff0acf04b1ad5020-- From teco@inf-net.nl Mon Nov 14 00:08:49 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5E3E11E826B for ; Mon, 14 Nov 2011 00:08:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.376 X-Spam-Level: X-Spam-Status: No, score=-2.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 Nt2dDu6Pu-ni for ; Mon, 14 Nov 2011 00:08:49 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id B118211E824C for ; Mon, 14 Nov 2011 00:08:48 -0800 (PST) Received: by wyf28 with SMTP id 28so4256406wyf.31 for ; Mon, 14 Nov 2011 00:08:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.227.206.81 with SMTP id ft17mr12404105wbb.23.1321258125161; Mon, 14 Nov 2011 00:08:45 -0800 (PST) Received: by 10.227.69.143 with HTTP; Mon, 14 Nov 2011 00:08:45 -0800 (PST) In-Reply-To: <4EC0C7A9.900@bogus.com> References: <41172287-6CA2-4B06-8355-2E3463057DA0@inf-net.nl> <60827AA3-F326-4CB0-96C7-F74687ED614E@cisco.com> <4EC0C7A9.900@bogus.com> Date: Mon, 14 Nov 2011 09:08:45 +0100 Message-ID: From: Teco Boot To: Joel jaeggli Content-Type: multipart/alternative; boundary=00151747906e34f39104b1ad61ce Cc: v6ops@ietf.org Subject: Re: [v6ops] Enterprises and draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 Nov 2011 08:08:49 -0000 --00151747906e34f39104b1ad61ce Content-Type: text/plain; charset=ISO-8859-1 2011/11/14 Joel jaeggli > On 11/14/11 15:41 , Fred Baker wrote: > > > > > > On Nov 14, 2011, at 3:29 PM, Teco Boot wrote: > >> In 6renum wg (enterprise renumbering), we have a need for egress > >> router selection based on source address. This topic would be in > >> scope of draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat. But > >> IMHO current version sticks to very small sites. Enterprises have > >> often a multi-hop path between hosts and egress routers. Add such > >> scenario in the document? > > > > Why is exit routing not a routing problem? I would think it is an > > appropriate topic for a model such as draft-baker-fun-routing-class > > > > there's always rh0... > O yes. Or take another approach: L3-switches could be nice tunnel endpoints. Often, CPU is idle on these boxes, so I don't expect objections. > > >> Current text and diagram in section 3.2 nicely explains the > >> IPv4-NAPT approach. We already know how this works. Replace with > >> something focussed on an IPv6 network? > > > > That would be the province of tools like RFC 6296... > > _______________________________________________ v6ops mailing list > > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > > > --00151747906e34f39104b1ad61ce Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2011/11/14 Joel jaeggli <joelja@bogus.com>
On 11/14/11 15:41 , Fred Baker wrote:
> </chair>
>
> On Nov 14, 2011, at 3:29 PM, Teco Boot wrote:
>> In 6renum wg (enterprise renumbering), we have a need for egress >> router selection based on source address. This topic would be in >> scope of draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat. But >> IMHO current version sticks to very small sites. Enterprises have<= br> >> often a multi-hop path between hosts and egress routers. Add such<= br> >> scenario in the document?
>
> Why is exit routing not a routing problem? I would think it is an
> appropriate topic for a model such as draft-baker-fun-routing-class
<troll>

there's always rh0...

O yes. Or tak= e another approach: L3-switches could be nice tunnel endpoints. Often, CPU = is idle on these boxes, so I don't expect objections.=A0
=A0<= /div>

>> Current text and diagram in section 3.2 nicely explains the
>> IPv4-NAPT approach. We already know how this works. Replace with >> something focussed on an IPv6 network?
>
> That would be the province of tools like RFC 6296...
> _______________________________________________ v6ops mailing li= st
> v6ops@ietf.org https://www.ietf.o= rg/mailman/listinfo/v6ops
>


--00151747906e34f39104b1ad61ce-- From fred@cisco.com Mon Nov 14 00:44:30 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF03121F8E41 for ; Mon, 14 Nov 2011 00:44:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.515 X-Spam-Level: X-Spam-Status: No, score=-109.515 tagged_above=-999 required=5 tests=[AWL=0.483, 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 AS4jQ1RgxE+y for ; Mon, 14 Nov 2011 00:44:30 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id A13EC21F8E19 for ; Mon, 14 Nov 2011 00:44:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=4013; q=dns/txt; s=iport; t=1321260269; x=1322469869; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=Z2KQgFWlGyu6LHjQxoYloBtO3wQvJ22mfkJdwZa/VLQ=; b=d7/8wzdMWpQhr5e5sb9gU9gI1M/xNPnKJfOxZ5uTm1c7Np/Ju2rKcotM 1KI/AgQ+1LYLZaO0cp1d6ff1qtWGtH06mLC8oaDRENv31bK4wIHY4lt2w pNsrrqTt8jrDXg559s/8A+Cmvihs7wsbJDPWwmgVCxQtHXLUjtXY3zL98 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EADLUwE5Io8UT/2dsb2JhbABCqX6BBYFyAQEBAwEBAQEPAVsLBQsLBBQuJzAGEyKHYAiZIAGdVwSJHGMEiA6MIIU7jEs X-IronPort-AV: E=Sophos;i="4.69,507,1315180800"; d="scan'208,217";a="121516654" Received: from bgl-core-4.cisco.com ([72.163.197.19]) by ams-iport-1.cisco.com with ESMTP; 14 Nov 2011 08:44:27 +0000 Received: from dhcp-57cd.meeting.ietf.org (hkidc-vpn-client-235-87.cisco.com [10.75.235.87]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pAE8iP7l020294; Mon, 14 Nov 2011 08:44:26 GMT Received: from [127.0.0.1] by dhcp-57cd.meeting.ietf.org (PGP Universal service); Mon, 14 Nov 2011 16:44:26 +0800 X-PGP-Universal: processed; by dhcp-57cd.meeting.ietf.org on Mon, 14 Nov 2011 16:44:26 +0800 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Mon, 14 Nov 2011 16:44:14 +0800 Message-Id: <209E4139-FF6D-4187-95FD-C3CA0E5ACC8A@cisco.com> References: <41172287-6CA2-4B06-8355-2E3463057DA0@inf-net.nl> <60827AA3-F326-4CB0-96C7-F74687ED614E@cisco.com> <4EC0C7A9.900@bogus.com> To: Teco Boot X-Mailer: Apple Mail (2.1084) Content-Type: multipart/alternative; boundary=Apple-Mail-6--644328799 Cc: v6ops@ietf.org Subject: Re: [v6ops] Enterprises and draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 14 Nov 2011 08:44:30 -0000 --Apple-Mail-6--644328799 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 14, 2011, at 4:08 PM, Teco Boot wrote: >=20 >=20 > 2011/11/14 Joel jaeggli > On 11/14/11 15:41 , Fred Baker wrote: > > > > > > On Nov 14, 2011, at 3:29 PM, Teco Boot wrote: > >> In 6renum wg (enterprise renumbering), we have a need for egress > >> router selection based on source address. This topic would be in > >> scope of draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat. But > >> IMHO current version sticks to very small sites. Enterprises have > >> often a multi-hop path between hosts and egress routers. Add such > >> scenario in the document? > > > > Why is exit routing not a routing problem? I would think it is an > > appropriate topic for a model such as draft-baker-fun-routing-class >=20 > >=20 > there's always rh0... >=20 > O yes. Or take another approach: L3-switches could be nice tunnel = endpoints. Often, CPU is idle on these boxes, so I don't expect = objections.=20 :-) > =20 >=20 > >> Current text and diagram in section 3.2 nicely explains the > >> IPv4-NAPT approach. We already know how this works. Replace with > >> something focussed on an IPv6 network? > > > > That would be the province of tools like RFC 6296... > > _______________________________________________ v6ops mailing list > > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > >=20 >=20 --Apple-Mail-6--644328799 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On Nov 14, 2011, at 4:08 PM, Teco Boot wrote:



2011/11/14 Joel jaeggli <joelja@bogus.com>
On 11/14/11 15:41 , Fred Baker wrote:
> </chair>
>
> On Nov 14, 2011, at 3:29 PM, Teco Boot wrote:
>> In 6renum wg (enterprise renumbering), we have a need for egress
>> router selection based on source address. This topic would be in
>> scope of draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat. But
>> IMHO current version sticks to very small sites. Enterprises have
>> often a multi-hop path between hosts and egress routers. Add such
>> scenario in the document?
>
> Why is exit routing not a routing problem? I would think it is an
> appropriate topic for a model such as draft-baker-fun-routing-class

<troll>

there's always rh0...

O yes. Or take another approach: L3-switches could be nice tunnel endpoints. Often, CPU is idle on these boxes, so I don't expect objections. 

:-)

 

>> Current text and diagram in section 3.2 nicely explains the
>> IPv4-NAPT approach. We already know how this works. Replace with
>> something focussed on an IPv6 network?
>
> That would be the province of tools like RFC 6296...
> _______________________________________________ v6ops mailing list
> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops
>



--Apple-Mail-6--644328799-- From Carl.Wuyts@technicolor.com Mon Nov 14 02:20:27 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7836C21F8E7D for ; Mon, 14 Nov 2011 02:20:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.525 X-Spam-Level: X-Spam-Status: No, score=-3.525 tagged_above=-999 required=5 tests=[AWL=-1.226, BAYES_00=-2.599, J_CHICKENPOX_110=0.6, J_CHICKENPOX_13=0.6, MANGLED_MEDS=2.3, RCVD_IN_DNSWL_MED=-4, SARE_BAYES_5x8=0.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 MXBn7rwQa5QR for ; Mon, 14 Nov 2011 02:20:26 -0800 (PST) Received: from na3sys009aog104.obsmtp.com (na3sys009aog104.obsmtp.com [74.125.149.73]) by ietfa.amsl.com (Postfix) with ESMTP id 4B56321F8EAE for ; Mon, 14 Nov 2011 02:20:19 -0800 (PST) Received: from mopesedge02.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob104.postini.com ([74.125.148.12]) with SMTP ID DSNKTsDrYUyQ8Cw8VwKB5FojXbJ114qKRTPy@postini.com; Mon, 14 Nov 2011 02:20:22 PST Received: from MOPESMAILHC01.eu.thmulti.com (141.11.100.25) by mopesedge02.eu.thmulti.com (141.11.253.23) with Microsoft SMTP Server (TLS) id 8.3.192.1; Mon, 14 Nov 2011 11:18:51 +0100 Received: from MOPESMBX01.eu.thmulti.com ([169.254.155.121]) by MOPESMAILHC01.eu.thmulti.com ([141.11.100.25]) with mapi; Mon, 14 Nov 2011 11:18:56 +0100 From: Wuyts Carl To: Mark Andrews , "Hemant Singh (shemant)" Date: Mon, 14 Nov 2011 11:18:53 +0100 Thread-Topic: [v6ops] RFC6204bis-02 Thread-Index: Acyh0fCPbwP4VlIQRTuwC6imaaKqqAA5K2Nw Message-ID: <867F4B6A1672E541A94676D556793ACD0C27516333@MOPESMBX01.eu.thmulti.com> References: <867F4B6A1672E541A94676D556793ACD0C263BCDD7@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303494A91@XMB-RCD-109.cisco.com> <20111113070005.583DD17137B8@drugs.dv.isc.org> In-Reply-To: <20111113070005.583DD17137B8@drugs.dv.isc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] RFC6204bis-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, 14 Nov 2011 10:20:27 -0000 Just a small Q. What are you referring to exactly when stating: "" DS-Lite options learnt on the WAN interface ... "" DS-Lite options being ???=20 Carl Wuyts GCD System Architect Networking CONNECT DIVISION carl.wuyts@technicolor.com tel.: +32 3 443 65 90 Prins Boudewijnlaan 47=A0=A0-=A0=A02650 Edegem=A0=A0-=A0=A0Belgium Technicolor Delivery Technologies Belgium NV Registered office (maatschappelijke zetel): Prins Boudewijnlaan 47, 2650 Ed= egem, Belgium Company registration number (ondernemingsnummer): 0428837295 - RPR Antwerpe= n Help preserve the color of our world - Think before you print. -----Original Message----- From: Mark Andrews [mailto:marka@isc.org]=20 Sent: zondag 13 november 2011 8:00 To: Hemant Singh (shemant) Cc: Wuyts Carl; v6ops@ietf.org Subject: Re: [v6ops] RFC6204bis-02 In message <5B6B2B64C9FE2A489045EEEADDAFF2C303494A91@XMB-RCD-109.cisco.com>= , "He mant Singh (shemant)" writes: > > Wuyts, >=20 > Sorry for the delayed reply. The bullet is correct. If a CPE router > WAN has a public IPv4 address, then the router can send data over the=20 > native IPv4 network so why invoke DS-Lite? As for your error related=20 > comments/questions, please see the Coexistence section of the document=20 > version -02. See bullets 1 and 3 where a specific order is specified=20 > and if the CE follows the order there is les chance of mistake. =3D20 >=20 > http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-02#page-15 >=20 > Thanks for the review. >=20 > Hemant Personally this is being over prescriptive. Today we have CPE being presen= ted what appear to be public address but in practice are NAT'd addresses. = If it is reasonable to run DS-lite with RFC 1918 addresses on the WAN inter= face it is reasonable to run DS-lite with what appear to be public addresse= s on the WAN interface. It is also reasonable to run DS-Lite on top of 6rd= especially when the addresses being used for 6rd are ambigious. It really= isn't that hard to get the routing correct. Yes, there is double encapsul= ation but the payoff is a single NAT layer. DS-Lite options learnt on the WAN interface SHOULD be made available on the= LAN interfaces even if there is no B4 functionality in the CPE. This allows individual ipv6-only nodes to use DS-Lite. > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf=20 > Of Wuyts Carl > Sent: Wednesday, November 09, 2011 4:21 AM > To: v6ops@ietf.org > Subject: [v6ops] RFC6204bis-02 >=20 > =3D20 >=20 > =3D20 >=20 > 1. DLW-4: If the IPv6 CE Router is configured with a public IPv4 > address on its WAN interface, where public IPv4 address is defined as=20 > any address which is not in the private IP address space specified in=20 > [RFC5735] and also not in the reserved IP address space specified in=20 > [RFC6333], then the IPv6 CE Router MUST disable the DS-Lite B4 element. >=20 > =3D20 >=20 > =3D20 >=20 > This one is not fully ok I'd say. First of all, the DSlite is=20 > supposed to run on a v6-only intf, hence you could consider it as a=20 > configuration issue in case you have configured a public IPv4 on it ? =20 > Even if not, I don't see what you should have to check for public IPv4=20 > address presence to bring up (or not) the DSLite intf. >=20 > And then what happens if the DSLite tunnel is up, and a public IPv4 is=20 > being configured on top ? Bring it down ? >=20 > Imagine you boot the CPE, preconfigured with DHCPv6 option for dslite. > This will bring up the DSLite intf, because of the option, why=20 > bothering checking the public IPv4 presence ? >=20 > Maybe this is not really an issue, afterall, it's a configuration=20 > "mistake". >=20 > =3D20 >=20 > So my recommendation here would be to remove this requirement. >=20 > =3D20 >=20 > =3D20 >=20 >=20 > ------_=3D_NextPart_001_01CCA10B.C40327FE > Content-Type: text/html; > charset=3D"us-ascii" > Content-Transfer-Encoding: quoted-printable >=20 > xmlns:o=3D3D"urn:schemas-microsoft-com:office:office" =3D=20 > xmlns:w=3D3D"urn:schemas-microsoft-com:office:word" =3D=20 > xmlns:m=3D3D"http://schemas.microsoft.com/office/2004/12/omml" =3D=20 > xmlns=3D3D"http://www.w3.org/TR/REC-html40"> http-equiv=3D3DContent-Type content=3D3D"text/html; =3D=20 > charset=3D3Dus-ascii"> 12 =3D (filtered medium)"> link=3D3Dblue =3D vlink=3D3Dpurple>
class=3D3DMsoNormal> style=3D3D'color:#1F497D'>Wuyts,

class=3D3DMsoNormal> style=3D3D'color:#1F497D'> 

class=3D3DMsoNormal>Sorry for the delayed= =20 > =3D reply.   The bullet is correct.  If a CPE router WAN=20 > has =3D a public IPv4 address, then the router can send data over the=20 > native =3D > IPv4 network so why invoke DS-Lite?  As for your error related =3D=20 > comments/questions, please see the Coexistence section of the document=20 > =3D version -02.  See bullets 1 and 3 where a specific order is =3D= =20 > specified and if the CE follows the order there is les chance of =3D=20 > mistake.   

=3D style=3D3D'color:#1F497D'> 

class=3D3DMsoNormal> href=3D3D"http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-02#page-15 > ">h=3D=20 > ttp://tools.ietf.org/html/draft-ietf-v6ops-6204bis-02#page-15 >

style=3D3D'color:#1F497D'> 

class=3D3DMsoNormal>Thanks for the =3D=20 > review.

style=3D3D'color:#1F497D'> 

class=3D3DMsoNormal> style=3D3D'color:#1F497D'>Hemant

class=3D3DMsoNormal> style=3D3D'color:#1F497D'> 

style=3D3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in=20 > =3D 0in 0in'>

style=3D3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From: an>=3D style=3D3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> =3D=20 > v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of=20 > =3D Wuyts Carl
Sent: Wednesday, November 09, 2011 4:21 =3D= =20 > AM
To: v6ops@ietf.org
Subject: [v6ops] =3D=20 > RFC6204bis-02

class=3D3DMsoNormal> 

class=3D3DMsoNormal> 

style=3D3D'text-indent:-.25in;mso-list:l0 level1 lfo2'> !supportLists]>1. style=3D3D'font:7.0pt "Times New Roman"'>     =20 > =3D DLW-4:  If the IPv6 CE Router= =20 > is =3D configured with a public IPv4 address on its WAN interface, where= =20 > public =3D > IPv4 address is defined as any address which is not in the private IP=20 > =3D address space specified in [RFC5735] and also not in the reserved IP= =20 > =3D address space specified in [RFC6333], then the IPv6 CE Router MUST = =3D=20 > disable the DS-Lite B4 element.

class=3D3DMsoPlainText> style=3D3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'> an =3D=20 > style=3D3D'text-decoration:none'> 

< > p =3D class=3D3DMsoPlainText> style=3D3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>&nb > sp;=3D

style=3D3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>This one= =20 > =3D is not fully ok I’d say.  First of all, the DSlite is =3D= =20 > supposed to run on a v6-only intf, hence you could consider it as a =3D=20 > configuration issue in case you have configured a public  IPv4 on=20 > =3D it ?  Even if not, I don’t see what you should have to=20 > check =3D for public IPv4 address presence to bring up (or not) the=20 > DSLite =3D intf.

style=3D3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>And then= =20 > =3D what happens if the DSLite tunnel is up, and a public IPv4 is being=20 > =3D configured on top ?  Bring it down ?

class=3D3DMsoPlainText> style=3D3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>Imagine=20 > =3D you boot the CPE, preconfigured with DHCPv6 option for dslite. = =20 > =3D This will bring up the DSLite intf, because of the option, why=20 > bothering =3D checking the public IPv4 presence=20 > ?

style=3D3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>Maybe=20 > this =3D is not really an issue, afterall, it’s a configuration =3D= =20 > “mistake”.

class=3D3DMsoPlainText> style=3D3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>&nb > sp;=3D

style=3D3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>So my =3D= =20 > recommendation here would be to remove this =3D=20 > requirement.

style=3D3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>&nb > sp;=3D >

class=3D3DMsoNormal> 

> ------_=3D_NextPart_001_01CCA10B.C40327FE-- >=20 > --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D8555349567329490546=3D=3D > Content-Type: text/plain; charset=3D"us-ascii" > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > Content-Disposition: inline >=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=3D8555349567329490546=3D=3D-= - -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From Carl.Wuyts@technicolor.com Mon Nov 14 02:53:56 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8241211E81DA for ; Mon, 14 Nov 2011 02:53:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.041 X-Spam-Level: X-Spam-Status: No, score=-3.041 tagged_above=-999 required=5 tests=[AWL=-1.463, BAYES_50=0.001, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R3ym2L3-+z94 for ; Mon, 14 Nov 2011 02:53:51 -0800 (PST) Received: from na3sys009aog117.obsmtp.com (na3sys009aog117.obsmtp.com [74.125.149.242]) by ietfa.amsl.com (Postfix) with ESMTP id E99C311E81C5 for ; Mon, 14 Nov 2011 02:53:41 -0800 (PST) Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob117.postini.com ([74.125.148.12]) with SMTP ID DSNKTsDzNRCn58A/UyCuNyLGvcfJgi8A6Eo5@postini.com; Mon, 14 Nov 2011 02:53:42 PST 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.192.1; Mon, 14 Nov 2011 11:51:49 +0100 Received: from MOPESMBX01.eu.thmulti.com ([169.254.155.121]) by MOPESMAILHC01.eu.thmulti.com ([141.11.100.25]) with mapi; Mon, 14 Nov 2011 11:51:50 +0100 From: Wuyts Carl To: "Hemant Singh (shemant)" , "v6ops@ietf.org" Date: Mon, 14 Nov 2011 11:51:50 +0100 Thread-Topic: [v6ops] RFC6204bis-02 Thread-Index: AcyewOvBbq1YdOdiSD66Sp1uaN6CQwCSeq2gAGv1BCA= Message-ID: <867F4B6A1672E541A94676D556793ACD0C27516363@MOPESMBX01.eu.thmulti.com> References: <867F4B6A1672E541A94676D556793ACD0C263BCDD7@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303494A91@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C303494A91@XMB-RCD-109.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/related; boundary="_006_867F4B6A1672E541A94676D556793ACD0C27516363MOPESMBX01eut_"; type="multipart/alternative" MIME-Version: 1.0 Subject: Re: [v6ops] RFC6204bis-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, 14 Nov 2011 10:53:58 -0000 --_006_867F4B6A1672E541A94676D556793ACD0C27516363MOPESMBX01eut_ Content-Type: multipart/alternative; boundary="_000_867F4B6A1672E541A94676D556793ACD0C27516363MOPESMBX01eut_" --_000_867F4B6A1672E541A94676D556793ACD0C27516363MOPESMBX01eut_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Well, Indeed, if a public v4 address is present, one could wonder why still= bringing up the DSLite. On the other hand, why not ? Reason for mentioning this is that there are too many links created between= things/protocols (e.g. the RA/DHCP which I was pointing at too in these em= ails). We, as CPE vendor, are trying to be as much flexible to our audienc= e as possible, so we can automatically create dslite tunnels etc. Suppose = you now first have to check the IPv4 public presence on the Wan intf )on wh= ich the tunnel is supposed to be mapped onto), then you've to introduce ext= ra checks, while things, theoretically at least, can co-exist. What will y= ou do if someone adds an IPv4 public address on this same WAN intf AFTER th= e DSLite tunnel was created ? Tear it down automatically (meaning you've t= o poll for the presence or make sure extra eventing is in place??) So you = introduce extra complexity when doing this, which in fact are not needed. Carl Wuyts GCD System Architect Networking Connect Division carl.wuyts@technicolor.com tel.: +32 3 443 65 90 [cid:image001.gif@01CCA2C3.CB517F20] [cid:image002.gif@01CCA2C3.CB517F20] Prins Boudewijnlaan 47 - 2650 Edegem - Belgium Technicolor Delivery Technologies Belgium NV Registered office (maatschappelijke zetel): Prins Boudewijnlaan 47, 2650 Ed= egem, Belgium Company registration number (ondernemingsnummer): 0428837295 - RPR Antwerpe= n [cid:image003.gif@01CCA2C3.CB517F20] Help preserve the color of our world - Think before you print. From: Hemant Singh (shemant) [mailto:shemant@cisco.com] Sent: zaterdag 12 november 2011 8:22 To: Wuyts Carl; v6ops@ietf.org Subject: RE: [v6ops] RFC6204bis-02 Wuyts, Sorry for the delayed reply. The bullet is correct. If a CPE router WAN = has a public IPv4 address, then the router can send data over the native IP= v4 network so why invoke DS-Lite? As for your error related comments/quest= ions, please see the Coexistence section of the document version -02. See = bullets 1 and 3 where a specific order is specified and if the CE follows t= he order there is les chance of mistake. http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-02#page-15 Thanks for the review. Hemant From: v6ops-bounces@ietf.org [mailto:v6ops-b= ounces@ietf.org] On Behalf Of Wuyts Carl Sent: Wednesday, November 09, 2011 4:21 AM To: v6ops@ietf.org Subject: [v6ops] RFC6204bis-02 1. DLW-4: If the IPv6 CE Router is configured with a public IPv4 add= ress on its WAN interface, where public IPv4 address is defined as any addr= ess which is not in the private IP address space specified in [RFC5735] and= also not in the reserved IP address space specified in [RFC6333], then the= IPv6 CE Router MUST disable the DS-Lite B4 element. This one is not fully ok I'd say. First of all, the DSlite is supposed to = run on a v6-only intf, hence you could consider it as a configuration issue= in case you have configured a public IPv4 on it ? Even if not, I don't s= ee what you should have to check for public IPv4 address presence to bring = up (or not) the DSLite intf. And then what happens if the DSLite tunnel is up, and a public IPv4 is bein= g configured on top ? Bring it down ? Imagine you boot the CPE, preconfigured with DHCPv6 option for dslite. Thi= s will bring up the DSLite intf, because of the option, why bothering check= ing the public IPv4 presence ? Maybe this is not really an issue, afterall, it's a configuration "mistake"= . So my recommendation here would be to remove this requirement. --_000_867F4B6A1672E541A94676D556793ACD0C27516363MOPESMBX01eut_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Well, Indeed, if a public v4 address is present, one could wo= nder why still bringing up the DSLite.  On the other hand, why not ?&n= bsp;

Reason for mentioning this is that there are too many links created betw= een things/protocols (e.g. the RA/DHCP which I was pointing at too in these= emails).  We, as CPE vendor, are trying to be as much flexible to our= audience as possible, so we can automatically create dslite tunnels etc.&n= bsp; Suppose you now first have to check the IPv4 public presence on the Wa= n intf )on which the tunnel is supposed to be mapped onto), then you’= ve to introduce extra checks, while things, theoretically at least, can co-= exist.  What will you do if someone adds an IPv4 public address on thi= s same WAN intf AFTER the DSLite tunnel was created ?  Tear it down au= tomatically (meaning you’ve to poll for the presence or make sure ext= ra eventing is in place??)  So you introduce extra complexity when doi= ng this, which in fact are not needed.

 

Carl Wuyts

GCD System Architect Networking

Connect D= ivision

= carl.wuyts@technicolor.com=

tel.: +32 3 443 65 90=

3Dtwi=

3D"Visit

= Prins Boudewijnlaan 47  -  2650 Edegem  -&nbs= p; Belgium

Technicolor Delivery Technologies= Belgium NV

Registered office (maatschappelijke zetel= ): Prins Boudewijnlaan 47, 2650 Edegem, Belgium

Company registration number (ondernemingsnummer):= 0428837295 - RPR Antwerpen

3DEco

Help prese= rve the color of our world - Think before you print.<= /p>

 

 

From: Hemant Singh (shemant) [mailto:shemant@c= isco.com]
Sent: zaterdag 12 november 2011 8:22
To: Wuy= ts Carl; v6ops@ietf.org
Subject: RE: [v6ops] RFC6204bis-02

 

Wuyts,

 

Sorry for the delayed = reply.   The bullet is correct.  If a CPE router WAN has a p= ublic IPv4 address, then the router can send data over the native IPv4 netw= ork so why invoke DS-Lite?  As for your error related comments/questio= ns, please see the Coexistence section of the document version -02.  S= ee bullets 1 and 3 where a specific order is specified and if the CE follow= s the order there is les chance of mistake.   <= /p>

 

http://tools.ietf= .org/html/draft-ietf-v6ops-6204bis-02#page-15

 

=

Thanks for the review.

 

= Hemant

 

From:<= /b> v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On= Behalf Of Wuyts Carl
Sent: Wednesday, November 09, 2011 4:21= AM
To: v6ops@ietf.org
<= b>Subject: [v6ops] RFC6204bis-02

 

 =

1.      = DLW-4:  If the IPv6 CE Router is co= nfigured with a public IPv4 address on its WAN interface, where public IPv4= address is defined as any address which is not in the private IP address s= pace specified in [RFC5735] and also not in the reserved IP address space s= pecified in [RFC6333], then the IPv6 CE Router MUST disable the DS-Lite B4 = element.

 

 

This one is not fully ok I= 217;d say.  First of all, the DSlite is supposed to run on a v6-only i= ntf, hence you could consider it as a configuration issue in case you have = configured a public  IPv4 on it ?  Even if not, I don’t see= what you should have to check for public IPv4 address presence to bring up= (or not) the DSLite intf.

And then w= hat happens if the DSLite tunnel is up, and a public IPv4 is being configur= ed on top ?  Bring it down ?

Ima= gine you boot the CPE, preconfigured with DHCPv6 option for dslite.  T= his will bring up the DSLite intf, because of the option, why bothering che= cking the public IPv4 presence ?

Mayb= e this is not really an issue, afterall, it’s a configuration “= mistake”.

 

So my recommendation here would be to remove thi= s requirement.

 <= /span>

 

= --_000_867F4B6A1672E541A94676D556793ACD0C27516363MOPESMBX01eut_-- --_006_867F4B6A1672E541A94676D556793ACD0C27516363MOPESMBX01eut_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=1351; creation-date="Mon, 14 Nov 2011 10:51:49 GMT"; modification-date="Mon, 14 Nov 2011 10:51:49 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhGAAYAPcAAAAAAP///1Sfum/L64bW8o7h/ofU74fT7pHb9pfa8u75/VbD5VzG6FvF5l3G 513F5l/G51/F5mHH52PH6GPI6GPI52TH6GXJ6GbI6GnK6mjJ6WjK6WzL6m/M63HN6nPN6nTN63fR 7XnR7XTI5FeVqnnN537T7n7R7H/T7X3O6Y3f+4jV73m903/E2oDE2pTf+ZPc9JTa8Zfa8aDd8LDj 9MXr9+z5/er3+/r9/imy1yyx1S202S2z1zK43TW63jW32zS22Ta53Te73za32zq84Dm53Du73j2/ 4j2+4T283z273kHB5D++4EHA4kG/4UPA40K/4UTB5EbD5UbB40rJ7EjD5ErG6EnE5knE5Ua720rE 5kvG507J607I6U3G50/K60u+3U2/4U7A4k2/3lLI6E/A31XN7lHC4VnP8FfL61PD4lXD5FXF41vR 8VfG5VO92lrJ51a+21i/21/O7F7L6VnB3VzE4mHN6l/H5V3D30+lvWDH41/E4GDF4WLH42rL6GvP 6l+2znLZ9W7Q62C1zGO50HXZ9HTY83ba9XXX8mW70nLO6nHN6We803rd+HXV73zf+mm91HXS62vA 12GpvWavw2ixxVmWp2qxxYDW7X3Q52yzxm+2yW60x4HS6HC2yXG3ynzD2I7a75Xb7pvh9F+HkqTg 8ajg76ff7qri8bPo97fm9Ljm9MXw/Mfw/NDz/dDx+tbx+dz0++H1++f5/uv5/Six1S+22jG01zK1 2EXD5E/M7U7H50yvyWPY91zJ5WjZ92za927b+HHY82G4z3Xd+FurwHXa9Xfc93ne+F+rv37h+2u/ 1YDi/H7c9YHh+YLh+YXi+mqyxWuzxork+ovj+o3l+3K4ypXn+12PnJrm+qXp+63j8cLx/M/0/ef4 /Jfp+57q+6Xt/Kjv/avv/a3v/a7w/bPw/bzz/uP6/+z7/vP9/7fz/r30/sD0/sX1/sn2/tT4/9L2 /d/6/+X7/+b7/+r8/+v7/sz3/tr5/ub8/+39//v///3///7//////yH5BAEAAP8ALAAAAAAYABgA AAj/AP8JHEiwoMGCAgggOGCg4YqHEB8aOPCCAEESKmR84MABg0cOHUKGHDCAA4gEBQaOiIHBwgQO pmrQEEEhg80NGnJewACDhcAUJyBMwBArgL8ACkxc2MBUg8cLEEy0+PkhQoMZAerNmxegBoMLFChc AFsBQggXAkswerBgVYB8+eLtu7GorgcKDipIcBBi6r8SHtiyCoAPH7x6AXAoxjELRYO9IUIJlGMn jBi37zLHo2fPXj19/hT8WRMGDzGBb7LosIUqADp07WC7c9eOHbwAmnjwGBNIYBwwuHK0NleOOLnj 5MaxC+BpR64zp//JGQNkx6kA4rKXO8ede7oAe378/1BTSGCdMkNunfIXLhw4eQH6yU88KoiSImzK /8tzpkiPVP1gg4013gRgYGKmEMEEE0a4oYhAeahhhA/c8FMNNdF0s4466tyzTgCrOAFFEnA0IhAf bCQhhCkBVPMMNDDC+GI3AUiCBBNwRCJQH24wgUQmAWwjTDJEFllMNAGIcoQTdDAjkB9uODGFFLHw o00wwGSZpS/bBJDJEk80+eQvTVQhxR2zBECLK6202c0rAchCxhVR3DGJb5I0gYUXVqRBCiy1BFqL Dd+oMocVW+jyCCEC6ZEIIFps0cUXVOyCRhuYomEGFVx0wcsghlwyUC/DOHPIMcg4AskyzbS6DCSO ICSDiDOCGFNQNspUYgkmm3TCCSjXgPJJJ9NIYwklpRyk7LIDBQQAOw== --_006_867F4B6A1672E541A94676D556793ACD0C27516363MOPESMBX01eut_ Content-Type: image/gif; name="image002.gif" Content-Description: image002.gif Content-Disposition: inline; filename="image002.gif"; size=1834; creation-date="Mon, 14 Nov 2011 10:51:49 GMT"; modification-date="Mon, 14 Nov 2011 10:51:49 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhcgBFAOZ/AEGueqipqmgxkACLS4ORyPb294DFpZrMVqvi+sXr2Ie3laLXtnRHnLQlZO3J 2M+pxP7pJvqtgePqmqOIvYLKnACP1fewoXa65/vCov71sdqRnc6OpPvrlcU/benvs7qmzpzR8P/n rc7imtLntMkhU/V7Hf/yl+fZ6f3HipjL7b+MraKs1h+WXIrU9fNrPv/dkaTIrpQpd/JlIr8kXv/o ALa3uO0bLwCmUQC68pKSlf/CDgxNosvbKtvb3IzGP8nJyoiJjPaWgH+Ag3Z3euTk5Y3Y+MTfm+3t 7r/AwZubnvBSJQCZ3NLS0//eAwN+yE84la9fmdjkX//RSiPB855BhP/ILiCvY9HeRvLkCvmykSld q/aNl4Dd+cPT6O85Q2m+Q6zRONnM5OPx0PR3OR2Z2eOttkCr4Lfbm//uQPWMWbeLscPbysbs/OP1 /ZeLwPaLN9blff/iEvXlByCi3nzB69eqvN7r4uzysHfDWSCKzu+Uh8R4pR6j4IVfqm1ucf///yH5 BAEAAH8ALAAAAAByAEUAAAf/gH+Cg4SFhoeIiYqLjI2Oj5CRkpOUlZaXmJmam5ydnp+goaKjpKWm p6ipqqusra6vsLGys7S1tqF+Oat+freMubu9vorAkkhIlryqBQWXxZBEvD2VyqhEQtPJupJJScnC pzV+2dTbqdWnSX4BNTWDR+01RIUFSO0/zX/AP+1Mg/x/iLRDku9PO0JH7NXA906hv0Ho/vSId2TQ xB4Jf1gKwKujoB8deWn8OCTkkIp+gAAJGUBQjnUhgUAEB9Lkx5C58lUr8DLkSHE5Spqb1IMjkh7T evgZ4o9JyYrR/Mib2FKfHyH4kPBq1rPGkR4lH1ZjsvQH0gDIlA7RSGSlN6uC/zgCmfcjrEFeQuRd EkeO48g/IN2pQ2boasGV014+/MPRHdw/QsYZUve3wFO4R5YWBOlN3FtMfAetBJKj9EpdEQk9+/My sWRB4hxXS3koNcdpypRWnXnXMejXf4SWHt4yNcShrVkDjy1o9lDehELnXldIGfNMoV0CJxSZnGrk kpPDltpc2FZDK+eJlqwsmsx3V3trEvdXK5CKgvKJu59fLHjX5FxXjVz5fHUXEPmAJER5gkQ2UgHq uHMdJiANkcNIK+WSQ2TraaiZPv8pFyB5jxWwkoUvLWjiVUlkmE01RJQERACRISifJhxR90cBNUTG YkE1ZAgEYTnsxlgO8wSA5P8/F7pkDo8+AvFgj7wkoR5r5hChzlU1JNjkMGCGKeaYZJZp5pmqsIHA mmyCkMKbcK4g55wrfGDnnR88oOeedZTh558WBCqoBRgUaigGISSqaAgZNOroHR5EKqkHI1Rq6QKY ZroADJx2CoMdjxSAQBGkktoCHRekqioBrLZKgBsTxCqrGirUaqsGuOaqgR5B9OprBMAGG8ELxBb7 ggnIJmuCBMw2K4EIRkQb7RkUVGstBQpkq60CazTSRqmlnqrqqq6yCqusstqqrq65+uqusMGiYCyx HCiLLAfONguttEZQe22122oLQ0GHsAGuqeOSW+656E6grq0bsIuru7/CG4H/vPMea++y+TK7r7T+ /huwtqAiMsXJKE/BBxkst5yHFjDHrAUDNNdMMxU450xFBzz3zLMXQAfthQtjFG30G1UkrXQVEDTt dNNXRC31FWAcYPXVeFih9dZWsOD11ywAkAgOZJeNwxIVpK22Ezu07fYOTwgg99wCxGD33TE0MMPe fJNgw9+A26CEDIQXXoIOiCeuQxM0NO44FjxELjkPYPhg+eVf3KD55jcM4PnnA4iNiNllo6122my/ 3XbcdMuN9916872334H/PXjhhB+uOOKMO9445JNHXvnllmfOueagfy76IaSTbfrpqavOeuuv2x27 7LTXfjvuuu/eu+/ABz88//HGH5+858sb0vzZp6Ou+uqtu1799X3Xbjvuue/Ou++/By888cU7HvLO l75CrO95a3sf3OJXt/nJbnb2Exz+ZNA9xX3vcf6jHAB9UD7OnS90Y2seAt33vunRrXp5e+AMshe4 7RlOf4vjHw3CN7nxYU6AnSNgCEk3wgpE720mnBsK6QdB+7kwf/q7YP/8BwcxOPGJC8DhBwtIiAO2 z4cKDKL8XkfEFUbwiBSEoRJpIIcomPGMUbiDIRIgRR2OToRXrEAX5kjHLvSBgUNUIQsBB8YSSOGP gJRCHGRIA0ewUYBTTAQXFslILswhjoe4Y/zy+EASbOGSmNyCCyYog0OggYeQhgSAKEcJABa40RFm gKQhThCGVrryAZR84CHSwElPgrISADhlI1J5RUc4IJaym2UtSZHL5FFREbxsny9RuAcHOPOZDjgE BrJAzWpmoRQLMIA2t7kASCTzdI44ARTGSU4oPABN6EynOtfJzna6853wjKc850nPetrznvjMpz73 yc9++tMUgQAAOw== --_006_867F4B6A1672E541A94676D556793ACD0C27516363MOPESMBX01eut_ Content-Type: image/gif; name="image003.gif" Content-Description: image003.gif Content-Disposition: inline; filename="image003.gif"; size=493; creation-date="Mon, 14 Nov 2011 10:51:49 GMT"; modification-date="Mon, 14 Nov 2011 10:51:49 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhHAAhAMQAALHNVVqXGZu+IqbFNv79/ury0pK4H2SdaJzAJNjlq/3++vL34srdiSl5Mfj7 8OHrvDmDE5u+Kb3VbtDgm5jCnJC2IqDBJHqqHoazHsfYxcfco+/58f7///7+/v///f///yH5BAAA AAAALAAAAAAcACEAAAX/4CeOZGmeaKqubOumXSfKL0rT9RiTe65/nl0vxxE1KB3Ph6b8KGYjT/Pn ORwIHmy0FEQFCZRG5yldJnEqD6ezaWQIHMJDApAwCthgF8hbEqwEBQARAoWFEgskQWgiChwFDRoD hpQCA3hLQGhxSWABFpQIlAMPT2NoeTIJEBigooavlzJDS0UdHAkBEAivAoSjDklTQAROuBYQn7+/ lBJJS01SUgoJoskWvaECCWUiHEEKtw+8BtegvoWxiYtqSmsLhBblEALn2hLDH3HTAIXYuhfqVeLF TZ8SR3oSULKAQVeAChYi8kJwCUg4BcVkOOiXDgHDACAvXMBQoWQEOw6iahwsMCmdAI8CKoiciUEA gAJ8aBC4xfKlz3QRsVGcoICMJidKOjhgMKCXqKcAJqSMIkwEuw8OHjCQwNVOggJPvqm4ZUJGuw47 lajlA0Sat28xyJZV9APasGEcvknBkU9TjJ1WrTZZE9hHihAAOw== --_006_867F4B6A1672E541A94676D556793ACD0C27516363MOPESMBX01eut_-- From marka@isc.org Mon Nov 14 13:08:42 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1CAB11E813D for ; Mon, 14 Nov 2011 13:08:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.245 X-Spam-Level: X-Spam-Status: No, score=-0.245 tagged_above=-999 required=5 tests=[AWL=-2.246, BAYES_50=0.001, J_CHICKENPOX_110=0.6, J_CHICKENPOX_13=0.6, SARE_BAYES_5x8=0.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 tA2Dtavtcvkr for ; Mon, 14 Nov 2011 13:08:38 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 31C7711E80DF for ; Mon, 14 Nov 2011 13:08:37 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id A955A5F98B7; Mon, 14 Nov 2011 21:08:13 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 62BD9216C6F; Mon, 14 Nov 2011 21:07:41 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 64529171A31E; Tue, 15 Nov 2011 08:07:38 +1100 (EST) To: Wuyts Carl From: Mark Andrews References: <867F4B6A1672E541A94676D556793ACD0C263BCDD7@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303494A91@XMB-RCD-109.cisco.com> <20111113070005.583DD17137B8@drugs.dv.isc.org> <867F4B6A1672E541A94676D556793ACD0C27516333@MOPESMBX01.eu.thmulti.com> In-reply-to: Your message of "Mon, 14 Nov 2011 11:18:53 BST." <867F4B6A1672E541A94676D556793ACD0C27516333@MOPESMBX01.eu.thmulti.com> Date: Tue, 15 Nov 2011 08:07:38 +1100 Message-Id: <20111114210738.64529171A31E@drugs.dv.isc.org> Cc: "v6ops@ietf.org" Subject: Re: [v6ops] RFC6204bis-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, 14 Nov 2011 21:08:42 -0000 In message <867F4B6A1672E541A94676D556793ACD0C27516333@MOPESMBX01.eu.thmulti.com>, Wuyts Carl w rites: > Just a small Q. What are you referring to exactly when stating: > "" > DS-Lite options learnt on the WAN interface ... > "" > DS-Lite options being ???=20 I suppose it is more formally labeled the "The AFTR-Name DHCPv6 Option". This should be able to be learnt from upstream, much the same way as DNS servers can be learnt from upstream. > Carl Wuyts > GCD System Architect Networking > CONNECT DIVISION > carl.wuyts@technicolor.com > tel.: +32 3 443 65 90 > > > Prins Boudewijnlaan 47=A0=A0-=A0=A02650 Edegem=A0=A0-=A0=A0Belgium > Technicolor Delivery Technologies Belgium NV > Registered office (maatschappelijke zetel): Prins Boudewijnlaan 47, 2650 Ed= > egem, Belgium > Company registration number (ondernemingsnummer): 0428837295 - RPR Antwerpe= > n > > Help preserve the color of our world - Think before you print. > > > > > -----Original Message----- > From: Mark Andrews [mailto:marka@isc.org]=20 > Sent: zondag 13 november 2011 8:00 > To: Hemant Singh (shemant) > Cc: Wuyts Carl; v6ops@ietf.org > Subject: Re: [v6ops] RFC6204bis-02 > > > In message <5B6B2B64C9FE2A489045EEEADDAFF2C303494A91@XMB-RCD-109.cisco.com>= > , "He mant Singh (shemant)" writes: > > > > Wuyts, > >=20 > > Sorry for the delayed reply. The bullet is correct. If a CPE router > > WAN has a public IPv4 address, then the router can send data over the=20 > > native IPv4 network so why invoke DS-Lite? As for your error related=20 > > comments/questions, please see the Coexistence section of the document=20 > > version -02. See bullets 1 and 3 where a specific order is specified=20 > > and if the CE follows the order there is les chance of mistake. =3D20 > >=20 > > http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-02#page-15 > >=20 > > Thanks for the review. > >=20 > > Hemant > > Personally this is being over prescriptive. Today we have CPE being presen= > ted what appear to be public address but in practice are NAT'd addresses. = > If it is reasonable to run DS-lite with RFC 1918 addresses on the WAN inter= > face it is reasonable to run DS-lite with what appear to be public addresse= > s on the WAN interface. It is also reasonable to run DS-Lite on top of 6rd= > especially when the addresses being used for 6rd are ambigious. It really= > isn't that hard to get the routing correct. Yes, there is double encapsul= > ation but the payoff is a single NAT layer. > > DS-Lite options learnt on the WAN interface SHOULD be made available on the= > LAN interfaces even if there is no B4 functionality in the CPE. > This allows individual ipv6-only nodes to use DS-Lite. > > > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf=20 > > Of Wuyts Carl > > Sent: Wednesday, November 09, 2011 4:21 AM > > To: v6ops@ietf.org > > Subject: [v6ops] RFC6204bis-02 > >=20 > > =3D20 > >=20 > > =3D20 > >=20 > > 1. DLW-4: If the IPv6 CE Router is configured with a public IPv4 > > address on its WAN interface, where public IPv4 address is defined as=20 > > any address which is not in the private IP address space specified in=20 > > [RFC5735] and also not in the reserved IP address space specified in=20 > > [RFC6333], then the IPv6 CE Router MUST disable the DS-Lite B4 element. > >=20 > > =3D20 > >=20 > > =3D20 > >=20 > > This one is not fully ok I'd say. First of all, the DSlite is=20 > > supposed to run on a v6-only intf, hence you could consider it as a=20 > > configuration issue in case you have configured a public IPv4 on it ? =20 > > Even if not, I don't see what you should have to check for public IPv4=20 > > address presence to bring up (or not) the DSLite intf. > >=20 > > And then what happens if the DSLite tunnel is up, and a public IPv4 is=20 > > being configured on top ? Bring it down ? > >=20 > > Imagine you boot the CPE, preconfigured with DHCPv6 option for dslite. > > This will bring up the DSLite intf, because of the option, why=20 > > bothering checking the public IPv4 presence ? > >=20 > > Maybe this is not really an issue, afterall, it's a configuration=20 > > "mistake". > >=20 > > =3D20 > >=20 > > So my recommendation here would be to remove this requirement. > >=20 > > =3D20 > >=20 > > =3D20 > >=20 > >=20 > > ------_=3D_NextPart_001_01CCA10B.C40327FE > > Content-Type: text/html; > > charset=3D"us-ascii" > > Content-Transfer-Encoding: quoted-printable > >=20 > > > xmlns:o=3D3D"urn:schemas-microsoft-com:office:office" =3D=20 > > xmlns:w=3D3D"urn:schemas-microsoft-com:office:word" =3D=20 > > xmlns:m=3D3D"http://schemas.microsoft.com/office/2004/12/omml" =3D=20 > > xmlns=3D3D"http://www.w3.org/TR/REC-html40"> > http-equiv=3D3DContent-Type content=3D3D"text/html; =3D=20 > > charset=3D3Dus-ascii"> d=20 > > 12 =3D (filtered medium)"> > link=3D3Dblue =3D vlink=3D3Dpurple>
> class=3D3DMsoNormal> > style=3D3D'color:#1F497D'>Wuyts,

> class=3D3DMsoNormal> > style=3D3D'color:#1F497D'> 

> class=3D3DMsoNormal>Sorry for the delayed= > =20 > > =3D reply.   The bullet is correct.  If a CPE router WAN=20 > > has =3D a public IPv4 address, then the router can send data over the=20 > > native =3D > > IPv4 network so why invoke DS-Lite?  As for your error related =3D=20 > > comments/questions, please see the Coexistence section of the document=20 > > =3D version -02.  See bullets 1 and 3 where a specific order is =3D= > =20 > > specified and if the CE follows the order there is les chance of =3D=20 > > mistake.   

> =3D style=3D3D'color:#1F497D'> 

> class=3D3DMsoNormal> > href=3D3D"http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-02#page-15 > > ">h=3D=20 > > ttp://tools.ietf.org/html/draft-ietf-v6ops-6204bis-02#page-15 > >

> style=3D3D'color:#1F497D'> 

> class=3D3DMsoNormal>Thanks for the =3D=20 > > review.

> style=3D3D'color:#1F497D'> 

> class=3D3DMsoNormal> > style=3D3D'color:#1F497D'>Hemant

> class=3D3DMsoNormal> > style=3D3D'color:#1F497D'> 

> style=3D3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in=20 > > =3D 0in 0in'>

> style=3D3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From: > an>=3D > style=3D3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> =3D=20 > > v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of=20 > > =3D Wuyts Carl
Sent: Wednesday, November 09, 2011 4:21 =3D= > =20 > > AM
To: v6ops@ietf.org
Subject: [v6ops] =3D=20 > > RFC6204bis-02

> class=3D3DMsoNormal> 

> class=3D3DMsoNormal> 

=3D > > style=3D3D'text-indent:-.25in;mso-list:l0 level1 lfo2'> > !supportLists]>1. > style=3D3D'font:7.0pt "Times New Roman"'>     =20 > > =3D DLW-4:  If the IPv6 CE Router= > =20 > > is =3D configured with a public IPv4 address on its WAN interface, where= > =20 > > public =3D > > IPv4 address is defined as any address which is not in the private IP=20 > > =3D address space specified in [RFC5735] and also not in the reserved IP= > =20 > > =3D address space specified in [RFC6333], then the IPv6 CE Router MUST = > =3D=20 > > disable the DS-Lite B4 element.

> class=3D3DMsoPlainText> > style=3D3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'> > an =3D=20 > > style=3D3D'text-decoration:none'> 

< > > p =3D class=3D3DMsoPlainText> > style=3D3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>&nb > > sp;=3D

> style=3D3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>This one= > =20 > > =3D is not fully ok I’d say.  First of all, the DSlite is =3D= > =20 > > supposed to run on a v6-only intf, hence you could consider it as a =3D=20 > > configuration issue in case you have configured a public  IPv4 on=20 > > =3D it ?  Even if not, I don’t see what you should have to=20 > > check =3D for public IPv4 address presence to bring up (or not) the=20 > > DSLite =3D intf.

=20 > > style=3D3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>And then= > =20 > > =3D what happens if the DSLite tunnel is up, and a public IPv4 is being=20 > > =3D configured on top ?  Bring it down ?

=20 > > class=3D3DMsoPlainText> > style=3D3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>Imagine=20 > > =3D you boot the CPE, preconfigured with DHCPv6 option for dslite. = > =20 > > =3D This will bring up the DSLite intf, because of the option, why=20 > > bothering =3D checking the public IPv4 presence=20 > > ?

> style=3D3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>Maybe=20 > > this =3D is not really an issue, afterall, it’s a configuration =3D= > =20 > > “mistake”.

> class=3D3DMsoPlainText> > style=3D3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>&nb > > sp;=3D

> style=3D3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>So my =3D= > =20 > > recommendation here would be to remove this =3D=20 > > requirement.

=20 > > style=3D3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>&nb > > sp;=3D > >

> class=3D3DMsoNormal> 

> > ------_=3D_NextPart_001_01CCA10B.C40327FE-- > >=20 > > --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D8555349567329490546=3D=3D > > Content-Type: text/plain; charset=3D"us-ascii" > > MIME-Version: 1.0 > > Content-Transfer-Encoding: 7bit > > Content-Disposition: inline > >=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=3D8555349567329490546=3D=3D-= > - > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From shemant@cisco.com Mon Nov 14 16:30:54 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0F5B11E80F7 for ; Mon, 14 Nov 2011 16:30:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.164 X-Spam-Level: X-Spam-Status: No, score=-6.164 tagged_above=-999 required=5 tests=[AWL=0.435, 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 R9xL9qb99T4I for ; Mon, 14 Nov 2011 16:30:53 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 5AEC311E80D0 for ; Mon, 14 Nov 2011 16:30:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=431; q=dns/txt; s=iport; t=1321317053; x=1322526653; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=FWaBfPW/0U6pKFFL7I7+S4ykED3ETul3NEfmSK/YCcY=; b=T+r0c2IjdbT+gp/3sJM85OpwXdHaLMFnVN1T6s22zwKuk+IvTfoBd9ZJ fioyGQ+0HPKGPIedSAU8rBA2aaz29kiGDPGzX0Cg4A1WFAUetmYIPsAj4 FHqr6/V95VTFzg58LmrJMD0c0FRp1FaBt8qbR15alIG6OTHCmaWr6ldqD 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At4AAACywU6tJXG+/2dsb2JhbABEmWSQBYEFgXIBAQEEEgEdCj8MBAIBCBEEAQELBhcBBgFFCQgBAQQBEggaomIBnn2JHGMEiBCRYoxU X-IronPort-AV: E=Sophos;i="4.69,511,1315180800"; d="scan'208";a="35964220" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-5.cisco.com with ESMTP; 15 Nov 2011 00:30:53 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id pAF0UqEL022747; Tue, 15 Nov 2011 00:30:52 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Nov 2011 18:30:52 -0600 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Nov 2011 18:30:51 -0600 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C303494F73@XMB-RCD-109.cisco.com> In-Reply-To: <867F4B6A1672E541A94676D556793ACD0C27516333@MOPESMBX01.eu.thmulti.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] RFC6204bis-02 Thread-Index: Acyh0fCPbwP4VlIQRTuwC6imaaKqqAA5K2NwAB1QICA= References: <867F4B6A1672E541A94676D556793ACD0C263BCDD7@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303494A91@XMB-RCD-109.cisco.com> <20111113070005.583DD17137B8@drugs.dv.isc.org> <867F4B6A1672E541A94676D556793ACD0C27516333@MOPESMBX01.eu.thmulti.com> From: "Hemant Singh (shemant)" To: "Wuyts Carl" , "Mark Andrews" X-OriginalArrivalTime: 15 Nov 2011 00:30:52.0544 (UTC) FILETIME=[D4C50800:01CCA32D] Cc: v6ops@ietf.org Subject: Re: [v6ops] RFC6204bis-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, 15 Nov 2011 00:30:54 -0000 -----Original Message----- From: Wuyts Carl [mailto:Carl.Wuyts@technicolor.com]=20 Sent: Monday, November 14, 2011 6:19 PM To: Mark Andrews; Hemant Singh (shemant) Cc: v6ops@ietf.org Subject: RE: [v6ops] RFC6204bis-02 >Just a small Q. What are you referring to exactly when stating: >"" >DS-Lite options learnt on the WAN interface ... >"" >DS-Lite options being ???=20 IPv6 address of the AFTR element. Hemant From shemant@cisco.com Mon Nov 14 16:30:56 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B4EA11E8111 for ; Mon, 14 Nov 2011 16:30:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.169 X-Spam-Level: X-Spam-Status: No, score=-6.169 tagged_above=-999 required=5 tests=[AWL=0.429, 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 VI5hZQelRPPQ for ; Mon, 14 Nov 2011 16:30:55 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id F331011E80D0 for ; Mon, 14 Nov 2011 16:30:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=6802; q=dns/txt; s=iport; t=1321317055; x=1322526655; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=1z1Eoi2Ujo0+lHIJQevrGgu9+QGaKFAYYnxC8wZfDtk=; b=TjkkQTgF5/RGOCFzk0BKGJJFOyVoAr5/edXePv1MUVQI/+HvR/6eu4ll o/8uVwuX+5wscTuMSzXhti9TmokSgk5405X6r9wZ7518tV/6G+uNbOlE4 9v6RkIiEEUXblCYH55IpMChfOf+E5dcsxa5OMF4f18IOYkU7fUCEJtItj g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At4AAOaxwU6tJXG8/2dsb2JhbABEgk2XF5AFgQWBcgEBAQQSAQkRA1kCAQgRBAEBCwYXAQYBRQkIAQEEARIIGqJiAZ59iRxjBIgQkWKMVA X-IronPort-AV: E=Sophos;i="4.69,511,1315180800"; d="scan'208,217";a="35961818" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 15 Nov 2011 00:30:54 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id pAF0UskG022034; Tue, 15 Nov 2011 00:30:54 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Nov 2011 18:30:54 -0600 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCA32D.D59BB1DD" Date: Mon, 14 Nov 2011 18:30:50 -0600 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C303494F74@XMB-RCD-109.cisco.com> In-Reply-To: <867F4B6A1672E541A94676D556793ACD0C27516363@MOPESMBX01.eu.thmulti.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] RFC6204bis-02 Thread-Index: AcyewOvBbq1YdOdiSD66Sp1uaN6CQwCSeq2gAGv1BCAAHHv0MA== References: <867F4B6A1672E541A94676D556793ACD0C263BCDD7@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303494A91@XMB-RCD-109.cisco.com> <867F4B6A1672E541A94676D556793ACD0C27516363@MOPESMBX01.eu.thmulti.com> From: "Hemant Singh (shemant)" To: "Wuyts Carl" , X-OriginalArrivalTime: 15 Nov 2011 00:30:54.0281 (UTC) FILETIME=[D5CE1390:01CCA32D] Subject: Re: [v6ops] RFC6204bis-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, 15 Nov 2011 00:30:56 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCA32D.D59BB1DD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 =20 From: Wuyts Carl [mailto:Carl.Wuyts@technicolor.com]=20 Sent: Monday, November 14, 2011 6:52 PM To: Hemant Singh (shemant); v6ops@ietf.org Subject: RE: [v6ops] RFC6204bis-02 =20 >Well, Indeed, if a public v4 address is present, one could wonder why still bringing up the DSLite. On the other hand, why not ? =20 =20 What use case do you have to run native IPv4 and DS-Lite concurrently? =20 >What will you do if someone adds an IPv4 public address on this same WAN intf AFTER the DSLite tunnel was created ? Tear it down automatically (meaning you've to poll for the presence >or make sure extra eventing is in place??) So you introduce extra complexity when doing this, which in fact are not needed. =20 This is sunsetting of DS-Lite which the document which is relatively obvious. If native IPv4 is provisioned when DS-Lite is running, the DS-Lite tunnel has to be closed, and NAT44 services enabled on the CE router with native IPv4. Note NAT44 is not running when DS-Lite is operational. =20 =20 Hemant ------_=_NextPart_001_01CCA32D.D59BB1DD Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

From:= = Wuyts Carl [mailto:Carl.Wuyts@technicolor.com]
Sent: Monday, = November 14, 2011 6:52 PM
To: Hemant Singh (shemant); = v6ops@ietf.org
Subject: RE: [v6ops] = RFC6204bis-02

 

>Well, Indeed, if a public v4 address is = present, one could wonder why still bringing up the DSLite.  On the = other hand, why not ? 

 

What use case do you = have to run native IPv4 and DS-Lite = concurrently?

 

>What will you do if = someone adds an IPv4 public address on this same WAN intf AFTER the = DSLite tunnel was created ?  Tear it down automatically (meaning = you’ve to poll for the presence >or make sure extra eventing is = in place??)  So you introduce extra complexity when doing this, = which in fact are not needed.

 

This is sunsetting of = DS-Lite which the document which is relatively obvious.  If native = IPv4 is provisioned when DS-Lite is running, the DS-Lite tunnel has to = be closed, and NAT44 services enabled on the CE router with native = IPv4.  Note NAT44 is not running when DS-Lite is operational.  =

 

Hemant

------_=_NextPart_001_01CCA32D.D59BB1DD-- From internet-drafts@ietf.org Mon Nov 14 19:02:31 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8BDC1F0D3D; Mon, 14 Nov 2011 19:02:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 8Im1zcJJn7KT; Mon, 14 Nov 2011 19:02:28 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB5351F0D48; Mon, 14 Nov 2011 19:02:03 -0800 (PST) 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: 3.63 Message-ID: <20111115030203.13561.64928.idtracker@ietfa.amsl.com> Date: Mon, 14 Nov 2011 19:02:03 -0800 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-ivi-icmp-address-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, 15 Nov 2011 03:02:32 -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-00.txt Pages : 7 Date : 2011-11-14 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 the IPv4-translatable destination. This document discusses the considerations and the stateless address mapping algorithms for source address translation in ICMPv6 headers for such cases. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ivi-icmp-address-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-v6ops-ivi-icmp-address-00.txt From marka@isc.org Mon Nov 14 20:07:33 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48FE51F0CEB for ; Mon, 14 Nov 2011 20:07:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.553 X-Spam-Level: X-Spam-Status: No, score=0.553 tagged_above=-999 required=5 tests=[AWL=-2.948, BAYES_50=0.001, J_CHICKENPOX_110=0.6, J_CHICKENPOX_13=0.6, MANGLED_MEDS=2.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 JkVWNXmUXRQR for ; Mon, 14 Nov 2011 20:07:32 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 18A851F0C54 for ; Mon, 14 Nov 2011 20:07:32 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 2E1F05F9887; Tue, 15 Nov 2011 04:07:17 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id DF693216C6D; Tue, 15 Nov 2011 04:06:44 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 2A9D81732B1D; Tue, 15 Nov 2011 15:06:38 +1100 (EST) To: "Hemant Singh (shemant)" From: Mark Andrews References: <867F4B6A1672E541A94676D556793ACD0C263BCDD7@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303494A91@XMB-RCD-109.cisco.com> <867F4B6A1672E541A94676D556793ACD0C27516363@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303494F74@XMB-RCD-109.cisco.com> In-reply-to: Your message of "Mon, 14 Nov 2011 18:30:50 MDT." <5B6B2B64C9FE2A489045EEEADDAFF2C303494F74@XMB-RCD-109.cisco.com> Date: Tue, 15 Nov 2011 15:06:37 +1100 Message-Id: <20111115040638.2A9D81732B1D@drugs.dv.isc.org> Cc: v6ops@ietf.org Subject: Re: [v6ops] RFC6204bis-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, 15 Nov 2011 04:07:33 -0000 In message <5B6B2B64C9FE2A489045EEEADDAFF2C303494F74@XMB-RCD-109.cisco.com>, "Hemant Singh (she mant)" writes: > > From: Wuyts Carl [mailto:Carl.Wuyts@technicolor.com]=20 > Sent: Monday, November 14, 2011 6:52 PM > To: Hemant Singh (shemant); v6ops@ietf.org > Subject: RE: [v6ops] RFC6204bis-02 > > =20 > > >Well, Indeed, if a public v4 address is present, one could wonder why > still bringing up the DSLite. On the other hand, why not ? =20 > > =20 > > What use case do you have to run native IPv4 and DS-Lite concurrently? You want to migrate from CGNv4/Public IPv4 to DS-Lite as you are intending to stop supplying IPv4 addresses. If you don't have DS-Lite traffic you have no idea of whether you can do this or not. This is especially true when you don't control the CPE devices. "public v4 address" is a myth as far as the CPE is concerned. It has no way to know if it has a public IPv4 address or not. I've suggested DHCP options in the past to provide the information but have been shot down as not needed. 6to4 needs, DS-Lite vs CGN-64 needs it, I'm sure other things will need it. > What will you do if someone adds an IPv4 public address on this same > WAN intf AFTER the DSLite tunnel was created ? Tear it down > automatically (meaning you've to poll for the presence >or make sure > extra eventing is in place??) So you introduce extra complexity when > doing this, which in fact are not needed. > > =20 > > This is sunsetting of DS-Lite which the document which is relatively > obvious. If native IPv4 is provisioned when DS-Lite is running, the > DS-Lite tunnel has to be closed, and NAT44 services enabled on the CE > router with native IPv4. Note NAT44 is not running when DS-Lite is > operational. =20 > > =20 > > Hemant > > > ------_=_NextPart_001_01CCA32D.D59BB1DD > Content-Type: text/html; > charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > xmlns:o=3D"urn:schemas-microsoft-com:office:office" = > xmlns:w=3D"urn:schemas-microsoft-com:office:word" = > xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" = > xmlns=3D"http://www.w3.org/TR/REC-html40"> http-equiv=3DContent-Type content=3D"text/html; = > charset=3Dus-ascii"> (filtered medium)"> vlink=3Dpurple>

style=3D'color:#1F497D'> 

class=3DMsoNormal> style=3D'color:#1F497D'> 

style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in = > 0in 0in'>

style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:= > = > Wuyts Carl [mailto:Carl.Wuyts@technicolor.com]
Sent: Monday, = > November 14, 2011 6:52 PM
To: Hemant Singh (shemant); = > v6ops@ietf.org
Subject: RE: [v6ops] = > RFC6204bis-02

class=3DMsoNormal> 

style=3D'color:#1F497D'>>Well, Indeed, if a public v4 address is = > present, one could wonder why still bringing up the DSLite.  On the = > other hand, why not ? 

class=3DMsoNormal> style=3D'color:#1F497D'> 

class=3DMsoNormal>What use case do you = > have to run native IPv4 and DS-Lite = > concurrently?

style=3D'color:#1F497D'> 

class=3DMsoNormal>>What will you do if = > someone adds an IPv4 public address on this same WAN intf AFTER the = > DSLite tunnel was created ?  Tear it down automatically (meaning = > you’ve to poll for the presence >or make sure extra eventing is = > in place??)  So you introduce extra complexity when doing this, = > which in fact are not needed.

class=3DMsoNormal> style=3D'color:#1F497D'> 

class=3DMsoNormal>This is sunsetting of = > DS-Lite which the document which is relatively obvious.  If native = > IPv4 is provisioned when DS-Lite is running, the DS-Lite tunnel has to = > be closed, and NAT44 services enabled on the CE router with native = > IPv4.  Note NAT44 is not running when DS-Lite is operational.  = >

style=3D'color:#1F497D'> 

class=3DMsoNormal> style=3D'color:#1F497D'>Hemant

> ------_=_NextPart_001_01CCA32D.D59BB1DD-- > > --===============7144896635156409313== > Content-Type: text/plain; charset="us-ascii" > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --===============7144896635156409313==-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From lorenzo@google.com Mon Nov 14 21:40:34 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A172A1F0DBF for ; Mon, 14 Nov 2011 21:40:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=-0.205, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_32=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 2e3a9qVQFYb0 for ; Mon, 14 Nov 2011 21:40:32 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7C9DD11E8267 for ; Mon, 14 Nov 2011 21:40:22 -0800 (PST) Received: by ggnr5 with SMTP id r5so2013708ggn.31 for ; Mon, 14 Nov 2011 21:40:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=z8hI0iQnFqqp0UGzIT3Su1W3PMuREwCivBhtPmDEoBM=; b=WjIgfAwtCeMZV4Jl6Pr+0K0N8zfw85TzHvr1lXJh72NzicXmEw8QyoFH6SX9t6Ni0D RnjrGF3MycqafqmbsXiA== Received: by 10.101.42.17 with SMTP id u17mr7745058anj.7.1321335620286; Mon, 14 Nov 2011 21:40:20 -0800 (PST) Received: by 10.101.42.17 with SMTP id u17mr7745050anj.7.1321335620148; Mon, 14 Nov 2011 21:40:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.202.14 with HTTP; Mon, 14 Nov 2011 21:39:59 -0800 (PST) In-Reply-To: <867F4B6A1672E541A94676D556793ACD0C27516166@MOPESMBX01.eu.thmulti.com> References: <867F4B6A1672E541A94676D556793ACD0C263BD0F3@MOPESMBX01.eu.thmulti.com> <867F4B6A1672E541A94676D556793ACD0C27516166@MOPESMBX01.eu.thmulti.com> From: Lorenzo Colitti Date: Tue, 15 Nov 2011 13:39:59 +0800 Message-ID: To: Wuyts Carl Content-Type: multipart/alternative; boundary=001636ed71a4449f3504b1bf6ce2 X-System-Of-Record: true Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] RFC6204bis-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, 15 Nov 2011 05:40:34 -0000 --001636ed71a4449f3504b1bf6ce2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Nov 11, 2011 4:20 AM, "Wuyts Carl" wrote: > PPP indeed is a good example, and yes, IPVPv6 could potentially trigger DHCPv6 PD, but no, this is not a good idea. It=92s remarkable to see/hear always: =93CPE not ready=94, =93CPE the issue in IPV6=94, but it keeps comi= ng back to the CPE having to adapt. You suggest to listen to IPCPv6, possible of course, but yet again another mechanism ?? Listen to RA for auto-injection of the default route is ok and commonly agreed upon, in fact, we support it, but we also support to ignore them, CPE must be flexible, but your suggestion now is to listen to IPCPv6 and then linking it to DHCP-PD ? So no, no hard req needed to link DHCP-PD to RAS listening, not ok for e.g. PPP. Wait... so you're saying that your CPE starts DHCPv6 PD *before* IPv6CP is up? How can you do that? You don't even have a link-local address. What do you do on Ethernet links, start DHCPv6 PD before DAD completes, so you can avoid tying the two protocols together? --001636ed71a4449f3504b1bf6ce2 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On Nov 11, 2011 4:20 AM, "Wuyts Carl" <Carl.Wuyts@technicolor.com&= gt; wrote:
> PPP indeed is a good example, and yes, IPVPv6 could potentially trigge= r DHCPv6 PD, but no, this is not a good idea.=A0 It=92s remarkable to see/h= ear always: =93CPE not ready=94, =93CPE the issue in IPV6=94, but it keeps = coming back to the CPE having to adapt.=A0 You suggest to listen to IPCPv6,= possible of course, but yet again another mechanism ??=A0 Listen to RA for= auto-injection of the default route is ok and commonly agreed upon, in fac= t, we support it, but we also support to ignore them, CPE must be flexible,= but your suggestion now is to listen to IPCPv6 and then linking it to DHCP= -PD ?=A0 So no, no hard req needed to link DHCP-PD to RAS listening, not ok= for e.g. PPP.

Wait... so you're saying that your CPE starts DHCPv6 PD *before* IPv= 6CP is up? How can you do that? You don't even have a link-local addres= s.

What do you do on Ethernet links, start DHCPv6 PD before DAD completes, = so you can avoid tying the two protocols together?

--001636ed71a4449f3504b1bf6ce2-- From internet-drafts@ietf.org Mon Nov 14 22:28:59 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7244E1F0DBF; Mon, 14 Nov 2011 22:28:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 2j2WkHuhnR+P; Mon, 14 Nov 2011 22:28:59 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0478F1F0CBB; Mon, 14 Nov 2011 22:28:59 -0800 (PST) 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: 3.63 Message-ID: <20111115062859.14026.42405.idtracker@ietfa.amsl.com> Date: Mon, 14 Nov 2011 22:28:59 -0800 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-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: Tue, 15 Nov 2011 06:28: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 : IPv6 Multihoming without Network Address Translation Author(s) : Ole Troan David Miles Satoru Matsushima Tadahisa Okimoto Dan Wing Filename : draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-03.txt Pages : 24 Date : 2011-11-14 Network Address and Port Translation (NAPT) works well for conserving global addresses and addressing multihoming requirements, because an IPv4 NAPT router implements three functions: source address selection, next-hop resolution and optionally DNS resolution. For IPv6 hosts one approach could be the use of NPTv6. However, NAT should be avoided, if at all possible, to permit transparent end-to- end connectivity. In this document, we analyze the use cases of multihoming. We also describe functional requirements and possible solutions for multihoming without the use of NAT in IPv6 for hosts and small IPv6 networks that would otherwise be unable to meet minimum IPv6 allocation criteria. We conclude that DHCPv6 based solutions are suitable to solve the multihoming issues, which described in this document. Nevertheless, we mention that the possible needs for NPTv6 in the transition phase to the fully deployment of the proposed solutions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv6-multihoming-witho= ut-ipv6nat-03.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-v6ops-ipv6-multihoming-withou= t-ipv6nat-03.txt From Carl.Wuyts@technicolor.com Mon Nov 14 22:55:23 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 165DD11E8094 for ; Mon, 14 Nov 2011 22:55:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.119 X-Spam-Level: X-Spam-Status: No, score=-3.119 tagged_above=-999 required=5 tests=[AWL=-1.120, BAYES_50=0.001, J_CHICKENPOX_110=0.6, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, SARE_BAYES_5x8=0.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 55OiVcJdHnbf for ; Mon, 14 Nov 2011 22:55:21 -0800 (PST) Received: from na3sys009aog108.obsmtp.com (na3sys009aog108.obsmtp.com [74.125.149.199]) by ietfa.amsl.com (Postfix) with ESMTP id BFAB51F0C44 for ; Mon, 14 Nov 2011 22:55:17 -0800 (PST) Received: from mopesedge02.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob108.postini.com ([74.125.148.12]) with SMTP ID DSNKTsIM1BG2VM7+Svb7Fw54hRzVOwDbPQbT@postini.com; Mon, 14 Nov 2011 22:55:20 PST Received: from MOPESMAILHC01.eu.thmulti.com (141.11.100.25) by mopesedge02.eu.thmulti.com (141.11.253.23) with Microsoft SMTP Server (TLS) id 8.3.192.1; Tue, 15 Nov 2011 07:55:07 +0100 Received: from MOPESMBX01.eu.thmulti.com ([169.254.155.121]) by MOPESMAILHC01.eu.thmulti.com ([141.11.100.25]) with mapi; Tue, 15 Nov 2011 07:55:14 +0100 From: Wuyts Carl To: Mark Andrews Date: Tue, 15 Nov 2011 07:55:12 +0100 Thread-Topic: [v6ops] RFC6204bis-02 Thread-Index: AcyjEZN1tq7dj4QLTzSAESSQ0ccAvAAUYp1A Message-ID: <867F4B6A1672E541A94676D556793ACD0C27516652@MOPESMBX01.eu.thmulti.com> References: <867F4B6A1672E541A94676D556793ACD0C263BCDD7@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303494A91@XMB-RCD-109.cisco.com> <20111113070005.583DD17137B8@drugs.dv.isc.org> <867F4B6A1672E541A94676D556793ACD0C27516333@MOPESMBX01.eu.thmulti.com> <20111114210738.64529171A31E@drugs.dv.isc.org> In-Reply-To: <20111114210738.64529171A31E@drugs.dv.isc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] RFC6204bis-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, 15 Nov 2011 06:55:23 -0000 Ok, that's indeed the option I know off, but was not clear to me whether an= ything else was in scope. Maybe this info must be provided to the LAN hosts, however, not sure how yo= u see this ? DHCPv6 in bridge mode from host, but then what with hosts not supporting DH= CPv6 client (e.g. Win XP) ? Use RA's to do this ? Not defined. Other mechanisms ? e.g. some "spoofing" scenario ? In this case, it seems= like yet again some extra functionality should be present in the CPE, shou= ldn't we first focus on the basics ?? Carl Wuyts GCD System Architect Networking CONNECT DIVISION carl.wuyts@technicolor.com tel.: +32 3 443 65 90 Prins Boudewijnlaan 47 - 2650 Edegem - Belgium Technicolor Delivery Technologies Belgium NV Registered office (maatschappelijke zetel): Prins Boudewijnlaan 47, 2650 Ed= egem, Belgium Company registration number (ondernemingsnummer): 0428837295 - RPR Antwerpe= n Help preserve the color of our world - Think before you print. -----Original Message----- From: Mark Andrews [mailto:marka@isc.org] Sent: maandag 14 november 2011 22:08 To: Wuyts Carl Cc: Hemant Singh (shemant); v6ops@ietf.org Subject: Re: [v6ops] RFC6204bis-02 In message <867F4B6A1672E541A94676D556793ACD0C27516333@MOPESMBX01.eu.thmult= i.com>, Wuyts Carl w rites: > Just a small Q. What are you referring to exactly when stating: > "" > DS-Lite options learnt on the WAN interface ... > "" > DS-Lite options being ???=3D20 I suppose it is more formally labeled the "The AFTR-Name DHCPv6 Option". This should be able to be learnt from upstream, much the same way as DNS se= rvers can be learnt from upstream. > Carl Wuyts > GCD System Architect Networking > CONNECT DIVISION > carl.wuyts@technicolor.com > tel.: +32 3 443 65 90 > > > Prins Boudewijnlaan 47=3DA0=3DA0-=3DA0=3DA02650 Edegem=3DA0=3DA0-=3DA0=3D= A0Belgium > Technicolor Delivery Technologies Belgium NV Registered office > (maatschappelijke zetel): Prins Boudewijnlaan 47, 2650 Ed=3D egem, > Belgium Company registration number (ondernemingsnummer): 0428837295 - > RPR Antwerpe=3D n > > Help preserve the color of our world - Think before you print. > > > > > -----Original Message----- > From: Mark Andrews [mailto:marka@isc.org]=3D20 > Sent: zondag 13 november 2011 8:00 > To: Hemant Singh (shemant) > Cc: Wuyts Carl; v6ops@ietf.org > Subject: Re: [v6ops] RFC6204bis-02 > > > In message > <5B6B2B64C9FE2A489045EEEADDAFF2C303494A91@XMB-RCD-109.cisco.com>=3D > , "He mant Singh (shemant)" writes: > > > > Wuyts, > >=3D20 > > Sorry for the delayed reply. The bullet is correct. If a CPE router > > WAN has a public IPv4 address, then the router can send data over > >the=3D20 native IPv4 network so why invoke DS-Lite? As for your error > >related=3D20 comments/questions, please see the Coexistence section of > >the document=3D20 version -02. See bullets 1 and 3 where a specific > >order is specified=3D20 and if the CE follows the order there is les > >chance of mistake. =3D3D20 > >=3D20 > > http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-02#page-15 > >=3D20 > > Thanks for the review. > >=3D20 > > Hemant > > Personally this is being over prescriptive. Today we have CPE being > presen=3D ted what appear to be public address but in practice are NAT'd > addresses. =3D If it is reasonable to run DS-lite with RFC 1918 > addresses on the WAN inter=3D face it is reasonable to run DS-lite with > what appear to be public addresse=3D s on the WAN interface. It is also > reasonable to run DS-Lite on top of 6rd=3D especially when the > addresses being used for 6rd are ambigious. It really=3D isn't that > hard to get the routing correct. Yes, there is double encapsul=3D ation = but the payoff is a single NAT layer. > > DS-Lite options learnt on the WAN interface SHOULD be made available > on the=3D LAN interfaces even if there is no B4 functionality in the CPE= . > This allows individual ipv6-only nodes to use DS-Lite. > > > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On > >Behalf=3D20 Of Wuyts Carl > > Sent: Wednesday, November 09, 2011 4:21 AM > > To: v6ops@ietf.org > > Subject: [v6ops] RFC6204bis-02 > >=3D20 > > =3D3D20 > >=3D20 > > =3D3D20 > >=3D20 > > 1. DLW-4: If the IPv6 CE Router is configured with a public IPv4 > > address on its WAN interface, where public IPv4 address is defined > >as=3D20 any address which is not in the private IP address space > >specified in=3D20 [RFC5735] and also not in the reserved IP address > >space specified in=3D20 [RFC6333], then the IPv6 CE Router MUST disable= the DS-Lite B4 element. > >=3D20 > > =3D3D20 > >=3D20 > > =3D3D20 > >=3D20 > > This one is not fully ok I'd say. First of all, the DSlite is=3D20 > >supposed to run on a v6-only intf, hence you could consider it as > >a=3D20 configuration issue in case you have configured a public IPv4 > >on it ? =3D20 Even if not, I don't see what you should have to check > >for public IPv4=3D20 address presence to bring up (or not) the DSLite i= ntf. > >=3D20 > > And then what happens if the DSLite tunnel is up, and a public IPv4 > >is=3D20 being configured on top ? Bring it down ? > >=3D20 > > Imagine you boot the CPE, preconfigured with DHCPv6 option for dslite. > > This will bring up the DSLite intf, because of the option, why=3D20 > >bothering checking the public IPv4 presence ? > >=3D20 > > Maybe this is not really an issue, afterall, it's a configuration=3D20 > >"mistake". > >=3D20 > > =3D3D20 > >=3D20 > > So my recommendation here would be to remove this requirement. > >=3D20 > > =3D3D20 > >=3D20 > > =3D3D20 > >=3D20 > >=3D20 > > ------_=3D3D_NextPart_001_01CCA10B.C40327FE > > Content-Type: text/html; > > charset=3D3D"us-ascii" > > Content-Transfer-Encoding: quoted-printable > >=3D20 > > >xmlns:o=3D3D3D"urn:schemas-microsoft-com:office:office" =3D3D=3D20 > >xmlns:w=3D3D3D"urn:schemas-microsoft-com:office:word" =3D3D=3D20 > >xmlns:m=3D3D3D"http://schemas.microsoft.com/office/2004/12/omml" =3D3D= =3D20 > >xmlns=3D3D3D"http://www.w3.org/TR/REC-html40"> >http-equiv=3D3D3DContent-Type content=3D3D3D"text/html; =3D3D=3D20 > >charset=3D3D3Dus-ascii"> >Wor=3D > d=3D20 > > 12 =3D3D (filtered medium)"> > link=3D3D3Dblue =3D3D vlink=3D3D3Dpurple>
= > class=3D3D3DMsoNormal> > style=3D3D3D'color:#1F497D'>Wuyts,

> class=3D3D3DMsoNormal> > style=3D3D3D'color:#1F497D'> 

> class=3D3D3DMsoNormal>Sorry for the > > delayed=3D > =3D20 > > =3D3D reply.   The bullet is correct.  If a CPE router > > WAN=3D20 has =3D3D a public IPv4 address, then the router can send data > > over the=3D20 native =3D3D > > IPv4 network so why invoke DS-Lite?  As for your error related > > =3D3D=3D20 comments/questions, please see the Coexistence section of th= e > > document=3D20 =3D3D version -02.  See bullets 1 and 3 where a > > specific order is =3D3D=3D > =3D20 > > specified and if the CE follows the order there is les chance of > > =3D3D=3D20 mistake.   

> class=3D3D3DMsoNormal> > style=3D3D3D'color:#1F497D'> 

> class=3D3D3DMsoNormal> > href=3D3D3D"http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-02#pag > > e-15 > > ">h=3D3D=3D20 > > ttp://tools.ietf.org/html/draft-ietf-v6ops-6204bis-02#page-15 > p>

> style=3D3D3D'color:#1F497D'> 

> class=3D3D3DMsoNormal>Thanks for the > > =3D3D=3D20 review.

> =3D3D=3D20 style=3D3D3D'color:#1F497D'> 

> =3D3D=3D20 class=3D3D3DMsoNormal> > style=3D3D3D'color:#1F497D'>Hemant

> class=3D3D3DMsoNormal> > style=3D3D3D'color:#1F497D'> 

> =3D3D=3D20 style=3D3D3D'border:none;border-top:solid #B5C4DF > > 1.0pt;padding:3.0pt 0in=3D20 =3D3D 0in 0in'>

> class=3D3D3DMsoNormal> > style=3D3D3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From: > > > an>=3D3D > style=3D3D3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> > > =3D3D=3D20 v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On > > Behalf Of=3D20 =3D3D Wuyts Carl
Sent: Wednesday, November > > 09, 2011 4:21 =3D3D=3D > =3D20 > > AM
To: v6ops@ietf.org
Subject: [v6ops] =3D3D=3D20 > > RFC6204bis-02

> class=3D3D3DMsoNormal> 

> class=3D3D3DMsoNormal> 

> class=3D3D3DMsoListParagraph =3D > =3D3D > > style=3D3D3D'text-indent:-.25in;mso-list:l0 level1 lfo2'> > !supportLists]>1. > style=3D3D3D'font:7.0pt "Times New > > Roman"'>     =3D20 > > =3D3D DLW-4:  If the IPv6 CE > > Router=3D > =3D20 > > is =3D3D configured with a public IPv4 address on its WAN interface, > > where=3D > =3D20 > > public =3D3D > > IPv4 address is defined as any address which is not in the private > > IP=3D20 =3D3D address space specified in [RFC5735] and also not in the > > reserved IP=3D > =3D20 > > =3D3D address space specified in [RFC6333], then the IPv6 CE Router > > MUST =3D > =3D3D=3D20 > > disable the DS-Lite B4 element.

> class=3D3D3DMsoPlainText> > style=3D3D3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'> > > > an =3D3D=3D20 > > style=3D3D3D'text-decoration:none'> < > > /p>< p =3D3D class=3D3D3DMsoPlainText> > style=3D3D3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'> > >&nb sp;=3D3D

> style=3D3D3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>This > > one=3D > =3D20 > > =3D3D is not fully ok I’d say.  First of all, the DSlite is > > =3D3D=3D > =3D20 > > supposed to run on a v6-only intf, hence you could consider it as a > > =3D3D=3D20 configuration issue in case you have configured a > > public  IPv4 on=3D20 =3D3D it ?  Even if not, I don’t > > see what you should have to=3D20 check =3D3D for public IPv4 address > > presence to bring up (or not) the=3D20 DSLite =3D3D > > intf.

=3D20 > > style=3D3D3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>And > > then=3D > =3D20 > > =3D3D what happens if the DSLite tunnel is up, and a public IPv4 is > > being=3D20 =3D3D configured on top ?  Bring it down > > ?

=3D20 > > class=3D3D3DMsoPlainText> > style=3D3D3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>Imag > > ine=3D20 =3D3D you boot the CPE, preconfigured with DHCPv6 option for > > dslite. =3D > =3D20 > > =3D3D This will bring up the DSLite intf, because of the option, > > why=3D20 bothering =3D3D checking the public IPv4 presence=3D20 > > ?

> style=3D3D3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>Mayb > > e=3D20 this =3D3D is not really an issue, afterall, it’s a > > configuration =3D3D=3D > =3D20 > > “mistake”.

> class=3D3D3DMsoPlainText> > style=3D3D3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'> > >&nb sp;=3D3D

> =3D3D=3D20 > > style=3D3D3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>So > > my =3D3D=3D > =3D20 > > recommendation here would be to remove this =3D3D=3D20 > > requirement.

> class=3D3D3DMsoPlainText> =3D20 > > > >style=3D3D3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'> > >&nb > > sp;=3D3D > >

> class=3D3D3DMsoNormal> 

> > ------_=3D3D_NextPart_001_01CCA10B.C40327FE-- > >=3D20 > > > >--=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D= =3D3D8555349567329490546=3D3D > >=3D3D > > Content-Type: text/plain; charset=3D3D"us-ascii" > > MIME-Version: 1.0 > > Content-Transfer-Encoding: 7bit > > Content-Disposition: inline > >=3D20 > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > >=3D20 > > > >--=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D= =3D3D8555349567329490546=3D3D > >=3D3D-=3D > - > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From Carl.Wuyts@technicolor.com Mon Nov 14 23:07:23 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D87E411E8121 for ; Mon, 14 Nov 2011 23:07:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.326 X-Spam-Level: X-Spam-Status: No, score=-5.326 tagged_above=-999 required=5 tests=[AWL=1.273, 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 Dm388rYcvYB5 for ; Mon, 14 Nov 2011 23:07:23 -0800 (PST) Received: from na3sys009aog116.obsmtp.com (na3sys009aog116.obsmtp.com [74.125.149.240]) by ietfa.amsl.com (Postfix) with ESMTP id 1799911E8114 for ; Mon, 14 Nov 2011 23:07:19 -0800 (PST) Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob116.postini.com ([74.125.148.12]) with SMTP ID DSNKTsIPpyG3u384664ZFyVyzSPCQwNyEW4a@postini.com; Mon, 14 Nov 2011 23:07:23 PST Received: from MOPESMAILHC03.eu.thmulti.com (141.11.100.132) by mail3.technicolor.com (141.11.253.22) with Microsoft SMTP Server (TLS) id 8.3.192.1; Tue, 15 Nov 2011 07:55:45 +0100 Received: from MOPESMBX01.eu.thmulti.com ([169.254.155.121]) by MOPESMAILHC03.eu.thmulti.com ([141.11.100.132]) with mapi; Tue, 15 Nov 2011 07:55:47 +0100 From: Wuyts Carl To: "Hemant Singh (shemant)" , Mark Andrews Date: Tue, 15 Nov 2011 07:55:46 +0100 Thread-Topic: [v6ops] RFC6204bis-02 Thread-Index: Acyh0fCPbwP4VlIQRTuwC6imaaKqqAA5K2NwAB1QICAADerrIA== Message-ID: <867F4B6A1672E541A94676D556793ACD0C27516653@MOPESMBX01.eu.thmulti.com> References: <867F4B6A1672E541A94676D556793ACD0C263BCDD7@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303494A91@XMB-RCD-109.cisco.com> <20111113070005.583DD17137B8@drugs.dv.isc.org> <867F4B6A1672E541A94676D556793ACD0C27516333@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303494F73@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C303494F73@XMB-RCD-109.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] RFC6204bis-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, 15 Nov 2011 07:07:24 -0000 Sorry, but this option only foresees in AFTR name, so FQDN, no IPv6 address Carl Wuyts GCD System Architect Networking CONNECT DIVISION carl.wuyts@technicolor.com tel.: +32 3 443 65 90 Prins Boudewijnlaan 47=A0=A0-=A0=A02650 Edegem=A0=A0-=A0=A0Belgium Technicolor Delivery Technologies Belgium NV Registered office (maatschappelijke zetel): Prins Boudewijnlaan 47, 2650 Ed= egem, Belgium Company registration number (ondernemingsnummer): 0428837295 - RPR Antwerpe= n Help preserve the color of our world - Think before you print. -----Original Message----- From: Hemant Singh (shemant) [mailto:shemant@cisco.com]=20 Sent: dinsdag 15 november 2011 1:31 To: Wuyts Carl; Mark Andrews Cc: v6ops@ietf.org Subject: RE: [v6ops] RFC6204bis-02 -----Original Message----- From: Wuyts Carl [mailto:Carl.Wuyts@technicolor.com]=20 Sent: Monday, November 14, 2011 6:19 PM To: Mark Andrews; Hemant Singh (shemant) Cc: v6ops@ietf.org Subject: RE: [v6ops] RFC6204bis-02 >Just a small Q. What are you referring to exactly when stating: >"" >DS-Lite options learnt on the WAN interface ... >"" >DS-Lite options being ???=20 IPv6 address of the AFTR element. Hemant From Carl.Wuyts@technicolor.com Mon Nov 14 23:10:25 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4398B11E8094 for ; Mon, 14 Nov 2011 23:10:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.213 X-Spam-Level: X-Spam-Status: No, score=-4.213 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWYPotDJzdsc for ; Mon, 14 Nov 2011 23:10:22 -0800 (PST) Received: from na3sys009aog124.obsmtp.com (na3sys009aog124.obsmtp.com [74.125.149.151]) by ietfa.amsl.com (Postfix) with ESMTP id E3E4311E8100 for ; Mon, 14 Nov 2011 23:10:17 -0800 (PST) Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob124.postini.com ([74.125.148.12]) with SMTP ID DSNKTsIQWQtoOTnl4qvKALsotoRvuzGVZTpy@postini.com; Mon, 14 Nov 2011 23:10:18 PST 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.192.1; Tue, 15 Nov 2011 08:03:22 +0100 Received: from MOPESMBX01.eu.thmulti.com ([169.254.155.121]) by MOPESMAILHC01.eu.thmulti.com ([141.11.100.25]) with mapi; Tue, 15 Nov 2011 08:03:25 +0100 From: Wuyts Carl To: "Hemant Singh (shemant)" , "v6ops@ietf.org" Date: Tue, 15 Nov 2011 08:03:23 +0100 Thread-Topic: [v6ops] RFC6204bis-02 Thread-Index: AcyewOvBbq1YdOdiSD66Sp1uaN6CQwCSeq2gAGv1BCAAHHv0MAANyK5Q Message-ID: <867F4B6A1672E541A94676D556793ACD0C27516655@MOPESMBX01.eu.thmulti.com> References: <867F4B6A1672E541A94676D556793ACD0C263BCDD7@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303494A91@XMB-RCD-109.cisco.com> <867F4B6A1672E541A94676D556793ACD0C27516363@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303494F74@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C303494F74@XMB-RCD-109.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/related; boundary="_006_867F4B6A1672E541A94676D556793ACD0C27516655MOPESMBX01eut_"; type="multipart/alternative" MIME-Version: 1.0 Subject: Re: [v6ops] RFC6204bis-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, 15 Nov 2011 07:10:25 -0000 --_006_867F4B6A1672E541A94676D556793ACD0C27516655MOPESMBX01eut_ Content-Type: multipart/alternative; boundary="_000_867F4B6A1672E541A94676D556793ACD0C27516655MOPESMBX01eut_" --_000_867F4B6A1672E541A94676D556793ACD0C27516655MOPESMBX01eut_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable inline Carl Wuyts GCD System Architect Networking Connect Division carl.wuyts@technicolor.com tel.: +32 3 443 65 90 [cid:image001.gif@01CCA36C.B998DC20] [cid:image002.gif@01CCA36C.B998DC20] Prins Boudewijnlaan 47 - 2650 Edegem - Belgium Technicolor Delivery Technologies Belgium NV Registered office (maatschappelijke zetel): Prins Boudewijnlaan 47, 2650 Ed= egem, Belgium Company registration number (ondernemingsnummer): 0428837295 - RPR Antwerpe= n [cid:image003.gif@01CCA36C.B998DC20] Help preserve the color of our world - Think before you print. From: Hemant Singh (shemant) [mailto:shemant@cisco.com] Sent: dinsdag 15 november 2011 1:31 To: Wuyts Carl; v6ops@ietf.org Subject: RE: [v6ops] RFC6204bis-02 From: Wuyts Carl [mailto:Carl.Wuyts@technicolor.com] Sent: Monday, November 14, 2011 6:52 PM To: Hemant Singh (shemant); v6ops@ietf.org Subject: RE: [v6ops] RFC6204bis-02 >Well, Indeed, if a public v4 address is present, one could wonder why stil= l bringing up the DSLite. On the other hand, why not ? What use case do you have to run native IPv4 and DS-Lite concurrently? [Carl] multi-homed CPE, although they might use different WAN links. Anywa= y, we cannot prevent that a customer is asking for this, some specific traf= fic routed and the other tunneled in DSLite >What will you do if someone adds an IPv4 public address on this same WAN i= ntf AFTER the DSLite tunnel was created ? Tear it down automatically (mean= ing you've to poll for the presence >or make sure extra eventing is in plac= e??) So you introduce extra complexity when doing this, which in fact are = not needed. This is sunsetting of DS-Lite which the document which is relatively obviou= s. If native IPv4 is provisioned when DS-Lite is running, the DS-Lite tunn= el has to be closed, and NAT44 services enabled on the CE router with nativ= e IPv4. Note NAT44 is not running when DS-Lite is operational. [Carl] Still do not agree. First of all, it should not be the task of the = CPE to do all these things "auto-magically", secondly you can perfectly NAT= some traffic while tunnel the other. Again, some extra functionality is p= ushed onto the CPE, which should not be done. Just an extra question: "Who is provisioning the public IPv4 on that WAN in= tf ?" It's the ISP ? or the end-user ? or ... ? If the ISP decides on doi= ng this, he should be aware to remove either the tunnel or the DHCPv6 optio= n to establish it at the same time, no ? If not, you tell the CPe to reque= st the DSLite AFTR, but it should then check public v4 on the intf to bring= it up or not ? Why asking the option then ? Hemant --_000_867F4B6A1672E541A94676D556793ACD0C27516655MOPESMBX01eut_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

inline

 

=

Carl Wuyts

GCD System Architect Networking

Connect Division

carl.wuyts@techn= icolor.com

tel.: +32 3 443 65 90

3Dtwitter<= span style=3D'font-size:9.0pt;font-family:"Trebuchet MS","sans-serif";color= :#1F497D'>

3D"Visit

Prins Boudewijnlaa= n 47  -  2650 Edegem  -  Belgium

Technicolor Delivery Technologies Belgium NV

Registered office (maatschappelijke zetel): Prins Boudewijnla= an 47, 2650 Edegem, Belgium

<= b>Company registration number (ondernemingsnummer): 0428837295 - RPR An= twerpen

3DEco

Help preserve the color of our= world - Think before you print.

 

 

From: Hemant Singh (shemant) [mailto:shemant@cisco.com]
S= ent: dinsdag 15 november 2011 1:31
To: Wuyts Carl; v6ops@ietf= .org
Subject: RE: [v6ops] RFC6204bis-02

 

 

=  

<= p class=3DMsoNormal>From: Wuyts Carl [mailto:Carl.Wuyts@technicolor.com]
Sent: Monday, Nove= mber 14, 2011 6:52 PM
To: Hemant Singh (shemant); v6ops@ietf.org
Subject: RE: [v6ops] RFC620= 4bis-02

 

>Well, Indeed= , if a public v4 address is present, one could wonder why still bringing up= the DSLite.  On the other hand, why not ? 

 

What use case do yo= u have to run native IPv4 and DS-Lite concurrently?

[Carl] multi-homed CPE, al= though they might use different WAN links.  Anyway, we cannot prevent = that a customer is asking for this, some specific traffic routed and the ot= her tunneled in DSLite

 

>What will you do if someone adds an IPv4 public= address on this same WAN intf AFTER the DSLite tunnel was created ?  = Tear it down automatically (meaning you’ve to poll for the presence &= gt;or make sure extra eventing is in place??)  So you introduce extra = complexity when doing this, which in fact are not needed.=

 

This is sunsetti= ng of DS-Lite which the document which is relatively obvious.  If nati= ve IPv4 is provisioned when DS-Lite is running, the DS-Lite tunnel has to b= e closed, and NAT44 services enabled on the CE router with native IPv4.&nbs= p; Note NAT44 is not running when DS-Lite is operational. 

[Carl] Still do not agree.  First of all, it sh= ould not be the task of the CPE to do all these things “auto-magicall= y”, secondly you can perfectly NAT some traffic while tunnel the othe= r.  Again, some extra functionality is pushed onto the CPE, which shou= ld not be done.

Just an extra question: “Who is provisioning the public= IPv4 on that WAN intf ?”  It’s the ISP ? or the end-user = ? or … ?  If the ISP decides on doing this, he should be aware t= o remove either the tunnel or the DHCPv6 option to establish it at the same= time, no ?  If not, you tell the CPe to request the DSLite AFTR, but = it should then check public v4 on the intf to bring it up or not ?  Wh= y asking the option then ?

 

<= span style=3D'color:#1F497D'> 

Hemant

<= /html>= --_000_867F4B6A1672E541A94676D556793ACD0C27516655MOPESMBX01eut_-- --_006_867F4B6A1672E541A94676D556793ACD0C27516655MOPESMBX01eut_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=1351; creation-date="Tue, 15 Nov 2011 07:03:23 GMT"; modification-date="Tue, 15 Nov 2011 07:03:23 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhGAAYAPcAAAAAAP///1Sfum/L64bW8o7h/ofU74fT7pHb9pfa8u75/VbD5VzG6FvF5l3G 513F5l/G51/F5mHH52PH6GPI6GPI52TH6GXJ6GbI6GnK6mjJ6WjK6WzL6m/M63HN6nPN6nTN63fR 7XnR7XTI5FeVqnnN537T7n7R7H/T7X3O6Y3f+4jV73m903/E2oDE2pTf+ZPc9JTa8Zfa8aDd8LDj 9MXr9+z5/er3+/r9/imy1yyx1S202S2z1zK43TW63jW32zS22Ta53Te73za32zq84Dm53Du73j2/ 4j2+4T283z273kHB5D++4EHA4kG/4UPA40K/4UTB5EbD5UbB40rJ7EjD5ErG6EnE5knE5Ua720rE 5kvG507J607I6U3G50/K60u+3U2/4U7A4k2/3lLI6E/A31XN7lHC4VnP8FfL61PD4lXD5FXF41vR 8VfG5VO92lrJ51a+21i/21/O7F7L6VnB3VzE4mHN6l/H5V3D30+lvWDH41/E4GDF4WLH42rL6GvP 6l+2znLZ9W7Q62C1zGO50HXZ9HTY83ba9XXX8mW70nLO6nHN6We803rd+HXV73zf+mm91HXS62vA 12GpvWavw2ixxVmWp2qxxYDW7X3Q52yzxm+2yW60x4HS6HC2yXG3ynzD2I7a75Xb7pvh9F+HkqTg 8ajg76ff7qri8bPo97fm9Ljm9MXw/Mfw/NDz/dDx+tbx+dz0++H1++f5/uv5/Six1S+22jG01zK1 2EXD5E/M7U7H50yvyWPY91zJ5WjZ92za927b+HHY82G4z3Xd+FurwHXa9Xfc93ne+F+rv37h+2u/ 1YDi/H7c9YHh+YLh+YXi+mqyxWuzxork+ovj+o3l+3K4ypXn+12PnJrm+qXp+63j8cLx/M/0/ef4 /Jfp+57q+6Xt/Kjv/avv/a3v/a7w/bPw/bzz/uP6/+z7/vP9/7fz/r30/sD0/sX1/sn2/tT4/9L2 /d/6/+X7/+b7/+r8/+v7/sz3/tr5/ub8/+39//v///3///7//////yH5BAEAAP8ALAAAAAAYABgA AAj/AP8JHEiwoMGCAgggOGCg4YqHEB8aOPCCAEESKmR84MABg0cOHUKGHDCAA4gEBQaOiIHBwgQO pmrQEEEhg80NGnJewACDhcAUJyBMwBArgL8ACkxc2MBUg8cLEEy0+PkhQoMZAerNmxegBoMLFChc AFsBQggXAkswerBgVYB8+eLtu7GorgcKDipIcBBi6r8SHtiyCoAPH7x6AXAoxjELRYO9IUIJlGMn jBi37zLHo2fPXj19/hT8WRMGDzGBb7LosIUqADp07WC7c9eOHbwAmnjwGBNIYBwwuHK0NleOOLnj 5MaxC+BpR64zp//JGQNkx6kA4rKXO8ede7oAe378/1BTSGCdMkNunfIXLhw4eQH6yU88KoiSImzK /8tzpkiPVP1gg4013gRgYGKmEMEEE0a4oYhAeahhhA/c8FMNNdF0s4466tyzTgCrOAFFEnA0IhAf bCQhhCkBVPMMNDDC+GI3AUiCBBNwRCJQH24wgUQmAWwjTDJEFllMNAGIcoQTdDAjkB9uODGFFLHw o00wwGSZpS/bBJDJEk80+eQvTVQhxR2zBECLK6202c0rAchCxhVR3DGJb5I0gYUXVqRBCiy1BFqL Dd+oMocVW+jyCCEC6ZEIIFps0cUXVOyCRhuYomEGFVx0wcsghlwyUC/DOHPIMcg4AskyzbS6DCSO ICSDiDOCGFNQNspUYgkmm3TCCSjXgPJJJ9NIYwklpRyk7LIDBQQAOw== --_006_867F4B6A1672E541A94676D556793ACD0C27516655MOPESMBX01eut_ Content-Type: image/gif; name="image002.gif" Content-Description: image002.gif Content-Disposition: inline; filename="image002.gif"; size=1834; creation-date="Tue, 15 Nov 2011 07:03:23 GMT"; modification-date="Tue, 15 Nov 2011 07:03:23 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhcgBFAOZ/AEGueqipqmgxkACLS4ORyPb294DFpZrMVqvi+sXr2Ie3laLXtnRHnLQlZO3J 2M+pxP7pJvqtgePqmqOIvYLKnACP1fewoXa65/vCov71sdqRnc6OpPvrlcU/benvs7qmzpzR8P/n rc7imtLntMkhU/V7Hf/yl+fZ6f3HipjL7b+MraKs1h+WXIrU9fNrPv/dkaTIrpQpd/JlIr8kXv/o ALa3uO0bLwCmUQC68pKSlf/CDgxNosvbKtvb3IzGP8nJyoiJjPaWgH+Ag3Z3euTk5Y3Y+MTfm+3t 7r/AwZubnvBSJQCZ3NLS0//eAwN+yE84la9fmdjkX//RSiPB855BhP/ILiCvY9HeRvLkCvmykSld q/aNl4Dd+cPT6O85Q2m+Q6zRONnM5OPx0PR3OR2Z2eOttkCr4Lfbm//uQPWMWbeLscPbysbs/OP1 /ZeLwPaLN9blff/iEvXlByCi3nzB69eqvN7r4uzysHfDWSCKzu+Uh8R4pR6j4IVfqm1ucf///yH5 BAEAAH8ALAAAAAByAEUAAAf/gH+Cg4SFhoeIiYqLjI2Oj5CRkpOUlZaXmJmam5ydnp+goaKjpKWm p6ipqqusra6vsLGys7S1tqF+Oat+freMubu9vorAkkhIlryqBQWXxZBEvD2VyqhEQtPJupJJScnC pzV+2dTbqdWnSX4BNTWDR+01RIUFSO0/zX/AP+1Mg/x/iLRDku9PO0JH7NXA906hv0Ho/vSId2TQ xB4Jf1gKwKujoB8deWn8OCTkkIp+gAAJGUBQjnUhgUAEB9Lkx5C58lUr8DLkSHE5Spqb1IMjkh7T evgZ4o9JyYrR/Mib2FKfHyH4kPBq1rPGkR4lH1ZjsvQH0gDIlA7RSGSlN6uC/zgCmfcjrEFeQuRd EkeO48g/IN2pQ2boasGV014+/MPRHdw/QsYZUve3wFO4R5YWBOlN3FtMfAetBJKj9EpdEQk9+/My sWRB4hxXS3koNcdpypRWnXnXMejXf4SWHt4yNcShrVkDjy1o9lDehELnXldIGfNMoV0CJxSZnGrk kpPDltpc2FZDK+eJlqwsmsx3V3trEvdXK5CKgvKJu59fLHjX5FxXjVz5fHUXEPmAJER5gkQ2UgHq uHMdJiANkcNIK+WSQ2TraaiZPv8pFyB5jxWwkoUvLWjiVUlkmE01RJQERACRISifJhxR90cBNUTG YkE1ZAgEYTnsxlgO8wSA5P8/F7pkDo8+AvFgj7wkoR5r5hChzlU1JNjkMGCGKeaYZJZp5pmqsIHA mmyCkMKbcK4g55wrfGDnnR88oOeedZTh558WBCqoBRgUaigGISSqaAgZNOroHR5EKqkHI1Rq6QKY ZroADJx2CoMdjxSAQBGkktoCHRekqioBrLZKgBsTxCqrGirUaqsGuOaqgR5B9OprBMAGG8ELxBb7 ggnIJmuCBMw2K4EIRkQb7RkUVGstBQpkq60CazTSRqmlnqrqqq6yCqusstqqrq65+uqusMGiYCyx HCiLLAfONguttEZQe22122oLQ0GHsAGuqeOSW+656E6grq0bsIuru7/CG4H/vPMea++y+TK7r7T+ /huwtqAiMsXJKE/BBxkst5yHFjDHrAUDNNdMMxU450xFBzz3zLMXQAfthQtjFG30G1UkrXQVEDTt dNNXRC31FWAcYPXVeFih9dZWsOD11ywAkAgOZJeNwxIVpK22Ezu07fYOTwgg99wCxGD33TE0MMPe fJNgw9+A26CEDIQXXoIOiCeuQxM0NO44FjxELjkPYPhg+eVf3KD55jcM4PnnA4iNiNllo6122my/ 3XbcdMuN9916872334H/PXjhhB+uOOKMO9445JNHXvnllmfOueagfy76IaSTbfrpqavOeuuv2x27 7LTXfjvuuu/eu+/ABz88//HGH5+858sb0vzZp6Ou+uqtu1799X3Xbjvuue/Ou++/By888cU7HvLO l75CrO95a3sf3OJXt/nJbnb2Exz+ZNA9xX3vcf6jHAB9UD7OnS90Y2seAt33vunRrXp5e+AMshe4 7RlOf4vjHw3CN7nxYU6AnSNgCEk3wgpE720mnBsK6QdB+7kwf/q7YP/8BwcxOPGJC8DhBwtIiAO2 z4cKDKL8XkfEFUbwiBSEoRJpIIcomPGMUbiDIRIgRR2OToRXrEAX5kjHLvSBgUNUIQsBB8YSSOGP gJRCHGRIA0ewUYBTTAQXFslILswhjoe4Y/zy+EASbOGSmNyCCyYog0OggYeQhgSAKEcJABa40RFm gKQhThCGVrryAZR84CHSwElPgrISADhlI1J5RUc4IJaym2UtSZHL5FFREbxsny9RuAcHOPOZDjgE BrJAzWpmoRQLMIA2t7kASCTzdI44ARTGSU4oPABN6EynOtfJzna6853wjKc850nPetrznvjMpz73 yc9++tMUgQAAOw== --_006_867F4B6A1672E541A94676D556793ACD0C27516655MOPESMBX01eut_ Content-Type: image/gif; name="image003.gif" Content-Description: image003.gif Content-Disposition: inline; filename="image003.gif"; size=493; creation-date="Tue, 15 Nov 2011 07:03:24 GMT"; modification-date="Tue, 15 Nov 2011 07:03:24 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhHAAhAMQAALHNVVqXGZu+IqbFNv79/ury0pK4H2SdaJzAJNjlq/3++vL34srdiSl5Mfj7 8OHrvDmDE5u+Kb3VbtDgm5jCnJC2IqDBJHqqHoazHsfYxcfco+/58f7///7+/v///f///yH5BAAA AAAALAAAAAAcACEAAAX/4CeOZGmeaKqubOumXSfKL0rT9RiTe65/nl0vxxE1KB3Ph6b8KGYjT/Pn ORwIHmy0FEQFCZRG5yldJnEqD6ezaWQIHMJDApAwCthgF8hbEqwEBQARAoWFEgskQWgiChwFDRoD hpQCA3hLQGhxSWABFpQIlAMPT2NoeTIJEBigooavlzJDS0UdHAkBEAivAoSjDklTQAROuBYQn7+/ lBJJS01SUgoJoskWvaECCWUiHEEKtw+8BtegvoWxiYtqSmsLhBblEALn2hLDH3HTAIXYuhfqVeLF TZ8SR3oSULKAQVeAChYi8kJwCUg4BcVkOOiXDgHDACAvXMBQoWQEOw6iahwsMCmdAI8CKoiciUEA gAJ8aBC4xfKlz3QRsVGcoICMJidKOjhgMKCXqKcAJqSMIkwEuw8OHjCQwNVOggJPvqm4ZUJGuw47 lajlA0Sat28xyJZV9APasGEcvknBkU9TjJ1WrTZZE9hHihAAOw== --_006_867F4B6A1672E541A94676D556793ACD0C27516655MOPESMBX01eut_-- From Carl.Wuyts@technicolor.com Mon Nov 14 23:11:53 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF49E1F0C5A for ; Mon, 14 Nov 2011 23:11:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.911 X-Spam-Level: X-Spam-Status: No, score=-3.911 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hsil5vna-3EI for ; Mon, 14 Nov 2011 23:11:52 -0800 (PST) Received: from na3sys009aog124.obsmtp.com (na3sys009aog124.obsmtp.com [74.125.149.151]) by ietfa.amsl.com (Postfix) with ESMTP id CD9FB1F0C47 for ; Mon, 14 Nov 2011 23:11:49 -0800 (PST) Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob124.postini.com ([74.125.148.12]) with SMTP ID DSNKTsIQtCVCipDBzHRK1WcJNNRroxzm3Qqq@postini.com; Mon, 14 Nov 2011 23:11:50 PST 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.192.1; Tue, 15 Nov 2011 08:11:00 +0100 Received: from MOPESMBX01.eu.thmulti.com ([169.254.155.121]) by MOPESMAILHC02.eu.thmulti.com ([141.11.100.29]) with mapi; Tue, 15 Nov 2011 08:10:57 +0100 From: Wuyts Carl To: Lorenzo Colitti Date: Tue, 15 Nov 2011 08:10:55 +0100 Thread-Topic: [v6ops] RFC6204bis-02 Thread-Index: AcyjWRI7jqqw/SrKQxa1XTq9b3ac/AAC8HOQ Message-ID: <867F4B6A1672E541A94676D556793ACD0C27516658@MOPESMBX01.eu.thmulti.com> References: <867F4B6A1672E541A94676D556793ACD0C263BD0F3@MOPESMBX01.eu.thmulti.com> <867F4B6A1672E541A94676D556793ACD0C27516166@MOPESMBX01.eu.thmulti.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/related; boundary="_006_867F4B6A1672E541A94676D556793ACD0C27516658MOPESMBX01eut_"; type="multipart/alternative" MIME-Version: 1.0 Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] RFC6204bis-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, 15 Nov 2011 07:11:54 -0000 --_006_867F4B6A1672E541A94676D556793ACD0C27516658MOPESMBX01eut_ Content-Type: multipart/alternative; boundary="_000_867F4B6A1672E541A94676D556793ACD0C27516658MOPESMBX01eut_" --_000_867F4B6A1672E541A94676D556793ACD0C27516658MOPESMBX01eut_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Carl Wuyts GCD System Architect Networking Connect Division carl.wuyts@technicolor.com tel.: +32 3 443 65 90 [cid:image001.gif@01CCA36D.B65888C0] [cid:image002.gif@01CCA36D.B65888C0] Prins Boudewijnlaan 47 - 2650 Edegem - Belgium Technicolor Delivery Technologies Belgium NV Registered office (maatschappelijke zetel): Prins Boudewijnlaan 47, 2650 Ed= egem, Belgium Company registration number (ondernemingsnummer): 0428837295 - RPR Antwerpe= n [cid:image003.gif@01CCA36D.B65888C0] Help preserve the color of our world - Think before you print. From: Lorenzo Colitti [mailto:lorenzo@google.com] Sent: dinsdag 15 november 2011 6:40 To: Wuyts Carl Cc: v6ops@ietf.org WG; Wes Beebee Subject: RE: [v6ops] RFC6204bis-02 On Nov 11, 2011 4:20 AM, "Wuyts Carl" > wrote: > PPP indeed is a good example, and yes, IPVPv6 could potentially trigger D= HCPv6 PD, but no, this is not a good idea. It's remarkable to see/hear alw= ays: "CPE not ready", "CPE the issue in IPV6", but it keeps coming back to = the CPE having to adapt. You suggest to listen to IPCPv6, possible of cour= se, but yet again another mechanism ?? Listen to RA for auto-injection of = the default route is ok and commonly agreed upon, in fact, we support it, b= ut we also support to ignore them, CPE must be flexible, but your suggestio= n now is to listen to IPCPv6 and then linking it to DHCP-PD ? So no, no ha= rd req needed to link DHCP-PD to RAS listening, not ok for e.g. PPP. Wait... so you're saying that your CPE starts DHCPv6 PD *before* IPv6CP is = up? How can you do that? You don't even have a link-local address. No, DHCPv6 runs on top of PPP in this case, hence it cannot start before it= is up, but there's no link to RAs, which was the first statement: "link RA= to DHCPv6", so no RA needed to start DHCPv6 on this link, hence preferably= protocols should not be linked. What do you do on Ethernet links, start DHCPv6 PD before DAD completes, so = you can avoid tying the two protocols together? We have different configuration possibilities here, one being not to listen= to RA and configure the DHCPv6 client independent from the flags in it, so= not wait for the RA indeed. We're IPv6 ready logo certified, core protoco= ls phase II, so don't worry, we respect the rules towards DAD and everythin= g, we just don't want to tie up protocols, i.e. no fixed link between the R= A and DHCPv6, no matter Ethernet, PPP or whatever --_000_867F4B6A1672E541A94676D556793ACD0C27516658MOPESMBX01eut_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

&nbs= p;

 

=

Carl Wuyts=

GCD System Architect Networking

Con= nect Division

carl.wuyts@technicolor.com=

tel.: +32 3 443 65 90=

= 3Dtwitter

3D"VisitPrins Boudewijnlaan= 47  -  2650 Edegem  -  Belgium

Technicolor Delivery Technologies Belgium NV

Registered office (maatschappelijke zetel): Prins Boudewijnlaa= n 47, 2650 Edegem, Belgium

Company registration number (ondernemingsnummer): 0428837295 - RPR Ant= werpen

3DEco

Help preserve the color of our = world - Think before you print.

=

 =

 

From: Lorenzo Colitti [mailto:lorenzo@google.com]=
Sent: dinsdag 15 november 2011 6:40
To: Wuyts CarlCc: v6ops@ietf.org WG; Wes Beebee
Subject: RE: [v6ops] RF= C6204bis-02

 

On Nov 11, 2011 4:20 AM, "Wuyts Carl" <Carl.Wuyts@technicolor.co= m> wrote:
> PPP indeed is a good example, and yes, IPVPv6 coul= d potentially trigger DHCPv6 PD, but no, this is not a good idea.  It&= #8217;s remarkable to see/hear always: “CPE not ready”, “= CPE the issue in IPV6”, but it keeps coming back to the CPE having to= adapt.  You suggest to listen to IPCPv6, possible of course, but yet = again another mechanism ??  Listen to RA for auto-injection of the def= ault route is ok and commonly agreed upon, in fact, we support it, but we a= lso support to ignore them, CPE must be flexible, but your suggestion now i= s to listen to IPCPv6 and then linking it to DHCP-PD ?  So no, no hard= req needed to link DHCP-PD to RAS listening, not ok for e.g. PPP.

Wait... so you're saying that your CPE starts DHCPv6 PD *before* I= Pv6CP is up? How can you do that? You don't even have a link-local address.=

No, DHCPv6 runs on top of PPP in this case, hence = it cannot start before it is up, but there’s no link to RAs, which wa= s the first statement: “link RA to DHCPv6”, so no RA needed to = start DHCPv6 on this link, hence preferably protocols should not be linked.=

What do you do on Ethernet links, start DHCPv6 PD = before DAD completes, so you can avoid tying the two protocols together?

We have different configuration possibilities here, o= ne being not to listen to RA and configure the DHCPv6 client independent fr= om the flags in it, so not wait for the RA indeed.  We’re IPv6 r= eady logo certified, core protocols phase II, so don’t worry, we resp= ect the rules towards DAD and everything, we just don’t want to tie u= p protocols, i.e. no fixed link between the RA and DHCPv6, no matter Ethern= et, PPP or whatever

= --_000_867F4B6A1672E541A94676D556793ACD0C27516658MOPESMBX01eut_-- --_006_867F4B6A1672E541A94676D556793ACD0C27516658MOPESMBX01eut_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=1351; creation-date="Tue, 15 Nov 2011 07:10:56 GMT"; modification-date="Tue, 15 Nov 2011 07:10:56 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhGAAYAPcAAAAAAP///1Sfum/L64bW8o7h/ofU74fT7pHb9pfa8u75/VbD5VzG6FvF5l3G 513F5l/G51/F5mHH52PH6GPI6GPI52TH6GXJ6GbI6GnK6mjJ6WjK6WzL6m/M63HN6nPN6nTN63fR 7XnR7XTI5FeVqnnN537T7n7R7H/T7X3O6Y3f+4jV73m903/E2oDE2pTf+ZPc9JTa8Zfa8aDd8LDj 9MXr9+z5/er3+/r9/imy1yyx1S202S2z1zK43TW63jW32zS22Ta53Te73za32zq84Dm53Du73j2/ 4j2+4T283z273kHB5D++4EHA4kG/4UPA40K/4UTB5EbD5UbB40rJ7EjD5ErG6EnE5knE5Ua720rE 5kvG507J607I6U3G50/K60u+3U2/4U7A4k2/3lLI6E/A31XN7lHC4VnP8FfL61PD4lXD5FXF41vR 8VfG5VO92lrJ51a+21i/21/O7F7L6VnB3VzE4mHN6l/H5V3D30+lvWDH41/E4GDF4WLH42rL6GvP 6l+2znLZ9W7Q62C1zGO50HXZ9HTY83ba9XXX8mW70nLO6nHN6We803rd+HXV73zf+mm91HXS62vA 12GpvWavw2ixxVmWp2qxxYDW7X3Q52yzxm+2yW60x4HS6HC2yXG3ynzD2I7a75Xb7pvh9F+HkqTg 8ajg76ff7qri8bPo97fm9Ljm9MXw/Mfw/NDz/dDx+tbx+dz0++H1++f5/uv5/Six1S+22jG01zK1 2EXD5E/M7U7H50yvyWPY91zJ5WjZ92za927b+HHY82G4z3Xd+FurwHXa9Xfc93ne+F+rv37h+2u/ 1YDi/H7c9YHh+YLh+YXi+mqyxWuzxork+ovj+o3l+3K4ypXn+12PnJrm+qXp+63j8cLx/M/0/ef4 /Jfp+57q+6Xt/Kjv/avv/a3v/a7w/bPw/bzz/uP6/+z7/vP9/7fz/r30/sD0/sX1/sn2/tT4/9L2 /d/6/+X7/+b7/+r8/+v7/sz3/tr5/ub8/+39//v///3///7//////yH5BAEAAP8ALAAAAAAYABgA AAj/AP8JHEiwoMGCAgggOGCg4YqHEB8aOPCCAEESKmR84MABg0cOHUKGHDCAA4gEBQaOiIHBwgQO pmrQEEEhg80NGnJewACDhcAUJyBMwBArgL8ACkxc2MBUg8cLEEy0+PkhQoMZAerNmxegBoMLFChc AFsBQggXAkswerBgVYB8+eLtu7GorgcKDipIcBBi6r8SHtiyCoAPH7x6AXAoxjELRYO9IUIJlGMn jBi37zLHo2fPXj19/hT8WRMGDzGBb7LosIUqADp07WC7c9eOHbwAmnjwGBNIYBwwuHK0NleOOLnj 5MaxC+BpR64zp//JGQNkx6kA4rKXO8ede7oAe378/1BTSGCdMkNunfIXLhw4eQH6yU88KoiSImzK /8tzpkiPVP1gg4013gRgYGKmEMEEE0a4oYhAeahhhA/c8FMNNdF0s4466tyzTgCrOAFFEnA0IhAf bCQhhCkBVPMMNDDC+GI3AUiCBBNwRCJQH24wgUQmAWwjTDJEFllMNAGIcoQTdDAjkB9uODGFFLHw o00wwGSZpS/bBJDJEk80+eQvTVQhxR2zBECLK6202c0rAchCxhVR3DGJb5I0gYUXVqRBCiy1BFqL Dd+oMocVW+jyCCEC6ZEIIFps0cUXVOyCRhuYomEGFVx0wcsghlwyUC/DOHPIMcg4AskyzbS6DCSO ICSDiDOCGFNQNspUYgkmm3TCCSjXgPJJJ9NIYwklpRyk7LIDBQQAOw== --_006_867F4B6A1672E541A94676D556793ACD0C27516658MOPESMBX01eut_ Content-Type: image/gif; name="image002.gif" Content-Description: image002.gif Content-Disposition: inline; filename="image002.gif"; size=1834; creation-date="Tue, 15 Nov 2011 07:10:56 GMT"; modification-date="Tue, 15 Nov 2011 07:10:56 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhcgBFAOZ/AEGueqipqmgxkACLS4ORyPb294DFpZrMVqvi+sXr2Ie3laLXtnRHnLQlZO3J 2M+pxP7pJvqtgePqmqOIvYLKnACP1fewoXa65/vCov71sdqRnc6OpPvrlcU/benvs7qmzpzR8P/n rc7imtLntMkhU/V7Hf/yl+fZ6f3HipjL7b+MraKs1h+WXIrU9fNrPv/dkaTIrpQpd/JlIr8kXv/o ALa3uO0bLwCmUQC68pKSlf/CDgxNosvbKtvb3IzGP8nJyoiJjPaWgH+Ag3Z3euTk5Y3Y+MTfm+3t 7r/AwZubnvBSJQCZ3NLS0//eAwN+yE84la9fmdjkX//RSiPB855BhP/ILiCvY9HeRvLkCvmykSld q/aNl4Dd+cPT6O85Q2m+Q6zRONnM5OPx0PR3OR2Z2eOttkCr4Lfbm//uQPWMWbeLscPbysbs/OP1 /ZeLwPaLN9blff/iEvXlByCi3nzB69eqvN7r4uzysHfDWSCKzu+Uh8R4pR6j4IVfqm1ucf///yH5 BAEAAH8ALAAAAAByAEUAAAf/gH+Cg4SFhoeIiYqLjI2Oj5CRkpOUlZaXmJmam5ydnp+goaKjpKWm p6ipqqusra6vsLGys7S1tqF+Oat+freMubu9vorAkkhIlryqBQWXxZBEvD2VyqhEQtPJupJJScnC pzV+2dTbqdWnSX4BNTWDR+01RIUFSO0/zX/AP+1Mg/x/iLRDku9PO0JH7NXA906hv0Ho/vSId2TQ xB4Jf1gKwKujoB8deWn8OCTkkIp+gAAJGUBQjnUhgUAEB9Lkx5C58lUr8DLkSHE5Spqb1IMjkh7T evgZ4o9JyYrR/Mib2FKfHyH4kPBq1rPGkR4lH1ZjsvQH0gDIlA7RSGSlN6uC/zgCmfcjrEFeQuRd EkeO48g/IN2pQ2boasGV014+/MPRHdw/QsYZUve3wFO4R5YWBOlN3FtMfAetBJKj9EpdEQk9+/My sWRB4hxXS3koNcdpypRWnXnXMejXf4SWHt4yNcShrVkDjy1o9lDehELnXldIGfNMoV0CJxSZnGrk kpPDltpc2FZDK+eJlqwsmsx3V3trEvdXK5CKgvKJu59fLHjX5FxXjVz5fHUXEPmAJER5gkQ2UgHq uHMdJiANkcNIK+WSQ2TraaiZPv8pFyB5jxWwkoUvLWjiVUlkmE01RJQERACRISifJhxR90cBNUTG YkE1ZAgEYTnsxlgO8wSA5P8/F7pkDo8+AvFgj7wkoR5r5hChzlU1JNjkMGCGKeaYZJZp5pmqsIHA mmyCkMKbcK4g55wrfGDnnR88oOeedZTh558WBCqoBRgUaigGISSqaAgZNOroHR5EKqkHI1Rq6QKY ZroADJx2CoMdjxSAQBGkktoCHRekqioBrLZKgBsTxCqrGirUaqsGuOaqgR5B9OprBMAGG8ELxBb7 ggnIJmuCBMw2K4EIRkQb7RkUVGstBQpkq60CazTSRqmlnqrqqq6yCqusstqqrq65+uqusMGiYCyx HCiLLAfONguttEZQe22122oLQ0GHsAGuqeOSW+656E6grq0bsIuru7/CG4H/vPMea++y+TK7r7T+ /huwtqAiMsXJKE/BBxkst5yHFjDHrAUDNNdMMxU450xFBzz3zLMXQAfthQtjFG30G1UkrXQVEDTt dNNXRC31FWAcYPXVeFih9dZWsOD11ywAkAgOZJeNwxIVpK22Ezu07fYOTwgg99wCxGD33TE0MMPe fJNgw9+A26CEDIQXXoIOiCeuQxM0NO44FjxELjkPYPhg+eVf3KD55jcM4PnnA4iNiNllo6122my/ 3XbcdMuN9916872334H/PXjhhB+uOOKMO9445JNHXvnllmfOueagfy76IaSTbfrpqavOeuuv2x27 7LTXfjvuuu/eu+/ABz88//HGH5+858sb0vzZp6Ou+uqtu1799X3Xbjvuue/Ou++/By888cU7HvLO l75CrO95a3sf3OJXt/nJbnb2Exz+ZNA9xX3vcf6jHAB9UD7OnS90Y2seAt33vunRrXp5e+AMshe4 7RlOf4vjHw3CN7nxYU6AnSNgCEk3wgpE720mnBsK6QdB+7kwf/q7YP/8BwcxOPGJC8DhBwtIiAO2 z4cKDKL8XkfEFUbwiBSEoRJpIIcomPGMUbiDIRIgRR2OToRXrEAX5kjHLvSBgUNUIQsBB8YSSOGP gJRCHGRIA0ewUYBTTAQXFslILswhjoe4Y/zy+EASbOGSmNyCCyYog0OggYeQhgSAKEcJABa40RFm gKQhThCGVrryAZR84CHSwElPgrISADhlI1J5RUc4IJaym2UtSZHL5FFREbxsny9RuAcHOPOZDjgE BrJAzWpmoRQLMIA2t7kASCTzdI44ARTGSU4oPABN6EynOtfJzna6853wjKc850nPetrznvjMpz73 yc9++tMUgQAAOw== --_006_867F4B6A1672E541A94676D556793ACD0C27516658MOPESMBX01eut_ Content-Type: image/gif; name="image003.gif" Content-Description: image003.gif Content-Disposition: inline; filename="image003.gif"; size=493; creation-date="Tue, 15 Nov 2011 07:10:56 GMT"; modification-date="Tue, 15 Nov 2011 07:10:56 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhHAAhAMQAALHNVVqXGZu+IqbFNv79/ury0pK4H2SdaJzAJNjlq/3++vL34srdiSl5Mfj7 8OHrvDmDE5u+Kb3VbtDgm5jCnJC2IqDBJHqqHoazHsfYxcfco+/58f7///7+/v///f///yH5BAAA AAAALAAAAAAcACEAAAX/4CeOZGmeaKqubOumXSfKL0rT9RiTe65/nl0vxxE1KB3Ph6b8KGYjT/Pn ORwIHmy0FEQFCZRG5yldJnEqD6ezaWQIHMJDApAwCthgF8hbEqwEBQARAoWFEgskQWgiChwFDRoD hpQCA3hLQGhxSWABFpQIlAMPT2NoeTIJEBigooavlzJDS0UdHAkBEAivAoSjDklTQAROuBYQn7+/ lBJJS01SUgoJoskWvaECCWUiHEEKtw+8BtegvoWxiYtqSmsLhBblEALn2hLDH3HTAIXYuhfqVeLF TZ8SR3oSULKAQVeAChYi8kJwCUg4BcVkOOiXDgHDACAvXMBQoWQEOw6iahwsMCmdAI8CKoiciUEA gAJ8aBC4xfKlz3QRsVGcoICMJidKOjhgMKCXqKcAJqSMIkwEuw8OHjCQwNVOggJPvqm4ZUJGuw47 lajlA0Sat28xyJZV9APasGEcvknBkU9TjJ1WrTZZE9hHihAAOw== --_006_867F4B6A1672E541A94676D556793ACD0C27516658MOPESMBX01eut_-- From Ted.Lemon@nominum.com Mon Nov 14 23:15:01 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 156BC1F0CAF for ; Mon, 14 Nov 2011 23:15:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.559 X-Spam-Level: X-Spam-Status: No, score=-106.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 vqC-sADTi8NO for ; Mon, 14 Nov 2011 23:15:00 -0800 (PST) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id 4519D1F0C47 for ; Mon, 14 Nov 2011 23:15:00 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKTsIRc5FX9ny/gwGnjUavyKGL2vZeI9/K@postini.com; Mon, 14 Nov 2011 23:15:00 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 5E0E21B82B3 for ; Mon, 14 Nov 2011 23:14:59 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 0066B190052; Mon, 14 Nov 2011 23:14:58 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.01.0339.001; Mon, 14 Nov 2011 23:14:58 -0800 From: Ted Lemon To: Wuyts Carl Thread-Topic: [v6ops] RFC6204bis-02 Thread-Index: AQHMoxFwbq1YdOdiSD66Sp1uaN6CQ5WuBwMA//9/aVM= Date: Tue, 15 Nov 2011 07:14:56 +0000 Message-ID: <80D702DA-F460-4017-939F-C387AFC2A060@nominum.com> References: <867F4B6A1672E541A94676D556793ACD0C263BCDD7@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303494A91@XMB-RCD-109.cisco.com> <20111113070005.583DD17137B8@drugs.dv.isc.org> <867F4B6A1672E541A94676D556793ACD0C27516333@MOPESMBX01.eu.thmulti.com> <20111114210738.64529171A31E@drugs.dv.isc.org>, <867F4B6A1672E541A94676D556793ACD0C27516652@MOPESMBX01.eu.thmulti.com> In-Reply-To: <867F4B6A1672E541A94676D556793ACD0C27516652@MOPESMBX01.eu.thmulti.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] RFC6204bis-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, 15 Nov 2011 07:15:01 -0000 On Nov 15, 2011, at 2:55 PM, "Wuyts Carl" wrot= e: > DHCPv6 in bridge mode from host, but then what with hosts not supporting = DHCPv6 client (e.g. Win XP) ? We also fail on Win95 machines. Not sure how to address this... :)= From Carl.Wuyts@technicolor.com Mon Nov 14 23:17:57 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85FDE11E815D for ; Mon, 14 Nov 2011 23:17:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[AWL=1.200, 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 8e7tTg4+jsgn for ; Mon, 14 Nov 2011 23:17:56 -0800 (PST) Received: from na3sys009aog126.obsmtp.com (na3sys009aog126.obsmtp.com [74.125.149.155]) by ietfa.amsl.com (Postfix) with ESMTP id A1C7A11E8114 for ; Mon, 14 Nov 2011 23:17:54 -0800 (PST) Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob126.postini.com ([74.125.148.12]) with SMTP ID DSNKTsISIpN1ER/2W6/ph1HGCoyPf74b+UL9@postini.com; Mon, 14 Nov 2011 23:17:56 PST 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.192.1; Tue, 15 Nov 2011 08:17:40 +0100 Received: from MOPESMBX01.eu.thmulti.com ([169.254.155.121]) by MOPESMAILHC02.eu.thmulti.com ([141.11.100.29]) with mapi; Tue, 15 Nov 2011 08:17:43 +0100 From: Wuyts Carl To: Ted Lemon Date: Tue, 15 Nov 2011 08:17:42 +0100 Thread-Topic: [v6ops] RFC6204bis-02 Thread-Index: AQHMoxFwbq1YdOdiSD66Sp1uaN6CQ5WuBwMA//9/aVOAAABs0A== Message-ID: <867F4B6A1672E541A94676D556793ACD0C2751665C@MOPESMBX01.eu.thmulti.com> References: <867F4B6A1672E541A94676D556793ACD0C263BCDD7@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303494A91@XMB-RCD-109.cisco.com> <20111113070005.583DD17137B8@drugs.dv.isc.org> <867F4B6A1672E541A94676D556793ACD0C27516333@MOPESMBX01.eu.thmulti.com> <20111114210738.64529171A31E@drugs.dv.isc.org>, <867F4B6A1672E541A94676D556793ACD0C27516652@MOPESMBX01.eu.thmulti.com> <80D702DA-F460-4017-939F-C387AFC2A060@nominum.com> In-Reply-To: <80D702DA-F460-4017-939F-C387AFC2A060@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] RFC6204bis-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, 15 Nov 2011 07:17:57 -0000 :-) Well, I don't know the situation in all countries but there's still a huge = number of Win XPs around. Doubt this will be the same for Win 95, or older= ones like windows 3.1(1) Carl Wuyts GCD System Architect Networking CONNECT DIVISION carl.wuyts@technicolor.com tel.: +32 3 443 65 90 Prins Boudewijnlaan 47=A0=A0-=A0=A02650 Edegem=A0=A0-=A0=A0Belgium Technicolor Delivery Technologies Belgium NV Registered office (maatschappelijke zetel): Prins Boudewijnlaan 47, 2650 Ed= egem, Belgium Company registration number (ondernemingsnummer): 0428837295 - RPR Antwerpe= n Help preserve the color of our world - Think before you print. -----Original Message----- From: Ted Lemon [mailto:Ted.Lemon@nominum.com]=20 Sent: dinsdag 15 november 2011 8:15 To: Wuyts Carl Cc: Mark Andrews; v6ops@ietf.org Subject: Re: [v6ops] RFC6204bis-02 On Nov 15, 2011, at 2:55 PM, "Wuyts Carl" wrot= e: > DHCPv6 in bridge mode from host, but then what with hosts not supporting = DHCPv6 client (e.g. Win XP) ? We also fail on Win95 machines. Not sure how to address this... :) From Ted.Lemon@nominum.com Mon Nov 14 23:25:17 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADA5C11E8152 for ; Mon, 14 Nov 2011 23:25:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.56 X-Spam-Level: X-Spam-Status: No, score=-106.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 U0rSpPGE8R+v for ; Mon, 14 Nov 2011 23:25:17 -0800 (PST) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id EF5CC11E8094 for ; Mon, 14 Nov 2011 23:25:16 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKTsIT3CqGbveCjBMBC6YrPMS6f3I4kwDq@postini.com; Mon, 14 Nov 2011 23:25:17 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id A97591B82B2 for ; Mon, 14 Nov 2011 23:25:15 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 994E919005C; Mon, 14 Nov 2011 23:25:15 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.01.0339.001; Mon, 14 Nov 2011 23:25:15 -0800 From: Ted Lemon To: Wuyts Carl Thread-Topic: [v6ops] RFC6204bis-02 Thread-Index: AQHMoxFwbq1YdOdiSD66Sp1uaN6CQ5WuBwMA//9/aVOAAABs0IAAAnWX Date: Tue, 15 Nov 2011 07:25:15 +0000 Message-ID: <2815D4D2-F0CC-4921-84C9-249EC65F42D0@nominum.com> References: <867F4B6A1672E541A94676D556793ACD0C263BCDD7@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303494A91@XMB-RCD-109.cisco.com> <20111113070005.583DD17137B8@drugs.dv.isc.org> <867F4B6A1672E541A94676D556793ACD0C27516333@MOPESMBX01.eu.thmulti.com> <20111114210738.64529171A31E@drugs.dv.isc.org>, <867F4B6A1672E541A94676D556793ACD0C27516652@MOPESMBX01.eu.thmulti.com> <80D702DA-F460-4017-939F-C387AFC2A060@nominum.com>, <867F4B6A1672E541A94676D556793ACD0C2751665C@MOPESMBX01.eu.thmulti.com> In-Reply-To: <867F4B6A1672E541A94676D556793ACD0C2751665C@MOPESMBX01.eu.thmulti.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] RFC6204bis-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, 15 Nov 2011 07:25:17 -0000 On Nov 15, 2011, at 3:17 PM, "Wuyts Carl" wrot= e: > Well, I don't know the situation in all countries but there's still a hug= e number of Win XPs around. Doubt this will be the same for Win 95, or old= er ones like windows 3.1(1) True enough, but we shouldn't be designing protocols around ten year old op= erating systems. The trend should be for the market share of XP to decline = over time. = From Carl.Wuyts@technicolor.com Mon Nov 14 23:33:17 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47CCD11E80AD for ; Mon, 14 Nov 2011 23:33:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.474 X-Spam-Level: X-Spam-Status: No, score=-5.474 tagged_above=-999 required=5 tests=[AWL=1.125, 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 tlde98Cf7eSQ for ; Mon, 14 Nov 2011 23:33:16 -0800 (PST) Received: from na3sys009aog121.obsmtp.com (na3sys009aog121.obsmtp.com [74.125.149.145]) by ietfa.amsl.com (Postfix) with ESMTP id 5030411E8094 for ; Mon, 14 Nov 2011 23:33:13 -0800 (PST) Received: from mopesedge02.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob121.postini.com ([74.125.148.12]) with SMTP ID DSNKTsIVuG/AzcHvHbT+wHnH9LR4C6Wpb+XK@postini.com; Mon, 14 Nov 2011 23:33:16 PST Received: from MOPESMAILHC02.eu.thmulti.com (141.11.100.29) by mopesedge02.eu.thmulti.com (141.11.253.23) with Microsoft SMTP Server (TLS) id 8.3.192.1; Tue, 15 Nov 2011 08:33:03 +0100 Received: from MOPESMBX01.eu.thmulti.com ([169.254.155.121]) by MOPESMAILHC02.eu.thmulti.com ([141.11.100.29]) with mapi; Tue, 15 Nov 2011 08:33:08 +0100 From: Wuyts Carl To: Ted Lemon Date: Tue, 15 Nov 2011 08:33:06 +0100 Thread-Topic: [v6ops] RFC6204bis-02 Thread-Index: AQHMoxFwbq1YdOdiSD66Sp1uaN6CQ5WuBwMA//9/aVOAAABs0IAAAnWXgAAB4zA= Message-ID: <867F4B6A1672E541A94676D556793ACD0C27516664@MOPESMBX01.eu.thmulti.com> References: <867F4B6A1672E541A94676D556793ACD0C263BCDD7@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303494A91@XMB-RCD-109.cisco.com> <20111113070005.583DD17137B8@drugs.dv.isc.org> <867F4B6A1672E541A94676D556793ACD0C27516333@MOPESMBX01.eu.thmulti.com> <20111114210738.64529171A31E@drugs.dv.isc.org>, <867F4B6A1672E541A94676D556793ACD0C27516652@MOPESMBX01.eu.thmulti.com> <80D702DA-F460-4017-939F-C387AFC2A060@nominum.com>, <867F4B6A1672E541A94676D556793ACD0C2751665C@MOPESMBX01.eu.thmulti.com> <2815D4D2-F0CC-4921-84C9-249EC65F42D0@nominum.com> In-Reply-To: <2815D4D2-F0CC-4921-84C9-249EC65F42D0@nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] RFC6204bis-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, 15 Nov 2011 07:33:17 -0000 I agree, however, it's not me who has to agree. Anyway, if you want to go more the up-to-date way: what about dhcpv6 client= availability on mobile devices (smartphones etc)? Carl Wuyts GCD System Architect Networking CONNECT DIVISION carl.wuyts@technicolor.com tel.: +32 3 443 65 90 Prins Boudewijnlaan 47=A0=A0-=A0=A02650 Edegem=A0=A0-=A0=A0Belgium Technicolor Delivery Technologies Belgium NV Registered office (maatschappelijke zetel): Prins Boudewijnlaan 47, 2650 Ed= egem, Belgium Company registration number (ondernemingsnummer): 0428837295 - RPR Antwerpe= n Help preserve the color of our world - Think before you print. -----Original Message----- From: Ted Lemon [mailto:Ted.Lemon@nominum.com]=20 Sent: dinsdag 15 november 2011 8:25 To: Wuyts Carl Cc: Mark Andrews; v6ops@ietf.org Subject: Re: [v6ops] RFC6204bis-02 On Nov 15, 2011, at 3:17 PM, "Wuyts Carl" wrot= e: > Well, I don't know the situation in all countries but there's still a hug= e number of Win XPs around. Doubt this will be the same for Win 95, or old= er ones like windows 3.1(1) True enough, but we shouldn't be designing protocols around ten year old op= erating systems. The trend should be for the market share of XP to decline = over time.=20 From shemant@cisco.com Mon Nov 14 23:55:14 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F1ED1F0D0C for ; Mon, 14 Nov 2011 23:55:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.18 X-Spam-Level: X-Spam-Status: No, score=-6.18 tagged_above=-999 required=5 tests=[AWL=0.418, 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 dDySVJwV3H6Y for ; Mon, 14 Nov 2011 23:55:13 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 125791F0C47 for ; Mon, 14 Nov 2011 23:55:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=6202; q=dns/txt; s=iport; t=1321343713; x=1322553313; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=1xu4JRBtuWjBbiCCF46imhSMCtQBG33GuJUM+iAYw1w=; b=nEe6Zgh8+b3NvNftWRIRdePIgZjU9yvHiA1p2CbIrXwU3EoyJ8uE6H7P sd4+eG+tlciAXyYGy8pElaMZlLJ7JOFow0FquS292rmGHSYp3uAZ+mTK3 NPwY3Rg2CM2/n79Q41ubRzUI7w1+AeNl5tj/sV3F6IQYN/s36YU1Rajiu 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApkAADIawk6tJXG//2dsb2JhbABDgk2XGJAFgQWBcgEBAQQSAQkRA1kCAQgRBAEBCwYXAQYBRQkIAQEEARIIGqQSAZ8HiSFjBIgRkWOMVQ X-IronPort-AV: E=Sophos;i="4.69,513,1315180800"; d="scan'208,217";a="36021954" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-2.cisco.com with ESMTP; 15 Nov 2011 07:55:12 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id pAF7tCwe025297; Tue, 15 Nov 2011 07:55:12 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Nov 2011 01:55:11 -0600 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCA36B.E707DF1A" Date: Tue, 15 Nov 2011 01:55:10 -0600 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C303494FE3@XMB-RCD-109.cisco.com> In-Reply-To: <867F4B6A1672E541A94676D556793ACD0C27516655@MOPESMBX01.eu.thmulti.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] RFC6204bis-02 Thread-Index: AcyewOvBbq1YdOdiSD66Sp1uaN6CQwCSeq2gAGv1BCAAHHv0MAANyK5QAAHgk2A= References: <867F4B6A1672E541A94676D556793ACD0C263BCDD7@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303494A91@XMB-RCD-109.cisco.com> <867F4B6A1672E541A94676D556793ACD0C27516363@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303494F74@XMB-RCD-109.cisco.com> <867F4B6A1672E541A94676D556793ACD0C27516655@MOPESMBX01.eu.thmulti.com> From: "Hemant Singh (shemant)" To: "Wuyts Carl" , X-OriginalArrivalTime: 15 Nov 2011 07:55:11.0980 (UTC) FILETIME=[E70822C0:01CCA36B] Subject: Re: [v6ops] RFC6204bis-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, 15 Nov 2011 07:55:14 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCA36B.E707DF1A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 From: Wuyts Carl [mailto:Carl.Wuyts@technicolor.com]=20 Sent: Monday, November 14, 2011 6:52 PM To: Hemant Singh (shemant); v6ops@ietf.org Subject: RE: [v6ops] RFC6204bis-02 =20 =20 > [Carl] multi-homed CPE, although they might use different WAN links. Anyway, we cannot prevent that a customer is asking for this, some specific traffic routed and the other tunneled in >DSLite =20 It's IPv4 multi-homed case and NAT44 that is out of the IPv6 CE router document. The rfc6204bis document also does not support multi-homing except for the case of sunsetting 6rd. See the Coexitence section's last paragraph. =20 Hemant =20 ------_=_NextPart_001_01CCA36B.E707DF1A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

From:= = Wuyts Carl [mailto:Carl.Wuyts@technicolor.= com]
Sent: Monday, November 14, 2011 6:52 = PM
To: Hemant Singh (shemant); v6ops@ietf.org
Subject: RE: = [v6ops] RFC6204bis-02

 

 

> [Carl] multi-homed = CPE, although they might use different WAN links.  Anyway, we = cannot prevent that a customer is asking for this, some specific traffic = routed and the other tunneled in >DSLite

 

It’s IPv4 = multi-homed case and NAT44 that is out of the IPv6 CE router = document.  The rfc6204bis document also does not support = multi-homing except for the case of sunsetting 6rd.  See the = Coexitence section’s last paragraph.

 

Hemant

 

------_=_NextPart_001_01CCA36B.E707DF1A-- From Carl.Wuyts@technicolor.com Mon Nov 14 23:57:11 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AFAF11E80B2 for ; Mon, 14 Nov 2011 23:57:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.33 X-Spam-Level: X-Spam-Status: No, score=-4.33 tagged_above=-999 required=5 tests=[AWL=-0.152, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7dlmCrpblrP for ; Mon, 14 Nov 2011 23:57:09 -0800 (PST) Received: from na3sys009aog108.obsmtp.com (na3sys009aog108.obsmtp.com [74.125.149.199]) by ietfa.amsl.com (Postfix) with ESMTP id 05BBC1F0CFF for ; Mon, 14 Nov 2011 23:57:07 -0800 (PST) Received: from mopesedge02.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob108.postini.com ([74.125.148.12]) with SMTP ID DSNKTsIbU0nZ5ebOGsMmmDM3ClLfE736X2ib@postini.com; Mon, 14 Nov 2011 23:57:08 PST Received: from MOPESMAILHC02.eu.thmulti.com (141.11.100.29) by mopesedge02.eu.thmulti.com (141.11.253.23) with Microsoft SMTP Server (TLS) id 8.3.192.1; Tue, 15 Nov 2011 08:56:58 +0100 Received: from MOPESMBX01.eu.thmulti.com ([169.254.155.121]) by MOPESMAILHC02.eu.thmulti.com ([141.11.100.29]) with mapi; Tue, 15 Nov 2011 08:57:02 +0100 From: Wuyts Carl To: "Hemant Singh (shemant)" , "v6ops@ietf.org" Date: Tue, 15 Nov 2011 08:56:59 +0100 Thread-Topic: [v6ops] RFC6204bis-02 Thread-Index: AcyewOvBbq1YdOdiSD66Sp1uaN6CQwCSeq2gAGv1BCAAHHv0MAANyK5QAAHgk2AAADFEcA== Message-ID: <867F4B6A1672E541A94676D556793ACD0C27516671@MOPESMBX01.eu.thmulti.com> References: <867F4B6A1672E541A94676D556793ACD0C263BCDD7@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303494A91@XMB-RCD-109.cisco.com> <867F4B6A1672E541A94676D556793ACD0C27516363@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303494F74@XMB-RCD-109.cisco.com> <867F4B6A1672E541A94676D556793ACD0C27516655@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303494FE3@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C303494FE3@XMB-RCD-109.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/related; boundary="_006_867F4B6A1672E541A94676D556793ACD0C27516671MOPESMBX01eut_"; type="multipart/alternative" MIME-Version: 1.0 Subject: Re: [v6ops] RFC6204bis-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, 15 Nov 2011 07:57:11 -0000 --_006_867F4B6A1672E541A94676D556793ACD0C27516671MOPESMBX01eut_ Content-Type: multipart/alternative; boundary="_000_867F4B6A1672E541A94676D556793ACD0C27516671MOPESMBX01eut_" --_000_867F4B6A1672E541A94676D556793ACD0C27516671MOPESMBX01eut_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ok, no problem to leave that out for me, approach remains the same however.= CPE should not have the task to automatically bring up/tear down the DSLi= te tunnel in case of "public" IPv4 presence. Carl Wuyts GCD System Architect Networking Connect Division carl.wuyts@technicolor.com tel.: +32 3 443 65 90 [cid:image001.gif@01CCA374.89040E60] [cid:image002.gif@01CCA374.89040E60] Prins Boudewijnlaan 47 - 2650 Edegem - Belgium Technicolor Delivery Technologies Belgium NV Registered office (maatschappelijke zetel): Prins Boudewijnlaan 47, 2650 Ed= egem, Belgium Company registration number (ondernemingsnummer): 0428837295 - RPR Antwerpe= n [cid:image003.gif@01CCA374.89040E60] Help preserve the color of our world - Think before you print. From: Hemant Singh (shemant) [mailto:shemant@cisco.com] Sent: dinsdag 15 november 2011 8:55 To: Wuyts Carl; v6ops@ietf.org Subject: RE: [v6ops] RFC6204bis-02 From: Wuyts Carl [mailto:Carl.Wuyts@technicolor.com] Sent: Monday, November 14, 2011 6:52 PM To: Hemant Singh (shemant); v6ops@ietf.org Subject: RE: [v6ops] RFC6204bis-02 > [Carl] multi-homed CPE, although they might use different WAN links. Any= way, we cannot prevent that a customer is asking for this, some specific tr= affic routed and the other tunneled in >DSLite It's IPv4 multi-homed case and NAT44 that is out of the IPv6 CE router docu= ment. The rfc6204bis document also does not support multi-homing except fo= r the case of sunsetting 6rd. See the Coexitence section's last paragraph. Hemant --_000_867F4B6A1672E541A94676D556793ACD0C27516671MOPESMBX01eut_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ok, no problem to leave that out for me, approach remains the= same however.  CPE should not have the task to automatically bring up= /tear down the DSLite tunnel in case of “public” IPv4 presence.=

 

Carl Wuyts

GCD Sy= stem Architect Networking

Connect Division

carl.wuyts@technicolor.com

<= img border=3D0 width=3D24 height=3D24 id=3D"Picture_x0020_1" src=3D"cid:ima= ge001.gif@01CCA374.89040E60" alt=3Dtwitter>

3D"Visit

Prins Boudewijnlaan 47  -&nb= sp; 2650 Edegem  -  Belgium

<= /td>

Technicolor Delivery Technologies Belgium NV

Regist= ered office (maatschappelijke zetel): Prins Boudewijnlaan 47, 2650 Edegem, = Belgium

Company regist= ration number (ondernemingsnummer): 0428837295 - RPR Antwerpen

3DEco

Help preserve the color of our world - Think befor= e you print.

<= /td>

&n= bsp;

 

From: Heman= t Singh (shemant) [mailto:shemant@cisco.com]
Sent: dinsdag 15 no= vember 2011 8:55
To: Wuyts Carl; v6ops@ietf.org
Subject: RE: [v6ops] RFC6204bis-02

 

 

From:<= /b> Wuyt= s Carl [mailto:Carl.Wuyts@tec= hnicolor.com]
Sent: Monday, November 14, 2011 6:52 PM
= To: Hemant Singh (shemant); v6ops@iet= f.org
Subject: RE: [v6ops] RFC6204bis-02

 =

&n= bsp;

>= ; [Carl] multi-homed CPE, although they might use different WAN links. = ; Anyway, we cannot prevent that a customer is asking for this, some specif= ic traffic routed and the other tunneled in >DSLite

 

It’s IPv4 mul= ti-homed case and NAT44 that is out of the IPv6 CE router document.  T= he rfc6204bis document also does not support multi-homing except for the ca= se of sunsetting 6rd.  See the Coexitence section’s last paragra= ph.

 

Hemant

 

= --_000_867F4B6A1672E541A94676D556793ACD0C27516671MOPESMBX01eut_-- --_006_867F4B6A1672E541A94676D556793ACD0C27516671MOPESMBX01eut_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=1351; creation-date="Tue, 15 Nov 2011 07:57:00 GMT"; modification-date="Tue, 15 Nov 2011 07:57:00 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhGAAYAPcAAAAAAP///1Sfum/L64bW8o7h/ofU74fT7pHb9pfa8u75/VbD5VzG6FvF5l3G 513F5l/G51/F5mHH52PH6GPI6GPI52TH6GXJ6GbI6GnK6mjJ6WjK6WzL6m/M63HN6nPN6nTN63fR 7XnR7XTI5FeVqnnN537T7n7R7H/T7X3O6Y3f+4jV73m903/E2oDE2pTf+ZPc9JTa8Zfa8aDd8LDj 9MXr9+z5/er3+/r9/imy1yyx1S202S2z1zK43TW63jW32zS22Ta53Te73za32zq84Dm53Du73j2/ 4j2+4T283z273kHB5D++4EHA4kG/4UPA40K/4UTB5EbD5UbB40rJ7EjD5ErG6EnE5knE5Ua720rE 5kvG507J607I6U3G50/K60u+3U2/4U7A4k2/3lLI6E/A31XN7lHC4VnP8FfL61PD4lXD5FXF41vR 8VfG5VO92lrJ51a+21i/21/O7F7L6VnB3VzE4mHN6l/H5V3D30+lvWDH41/E4GDF4WLH42rL6GvP 6l+2znLZ9W7Q62C1zGO50HXZ9HTY83ba9XXX8mW70nLO6nHN6We803rd+HXV73zf+mm91HXS62vA 12GpvWavw2ixxVmWp2qxxYDW7X3Q52yzxm+2yW60x4HS6HC2yXG3ynzD2I7a75Xb7pvh9F+HkqTg 8ajg76ff7qri8bPo97fm9Ljm9MXw/Mfw/NDz/dDx+tbx+dz0++H1++f5/uv5/Six1S+22jG01zK1 2EXD5E/M7U7H50yvyWPY91zJ5WjZ92za927b+HHY82G4z3Xd+FurwHXa9Xfc93ne+F+rv37h+2u/ 1YDi/H7c9YHh+YLh+YXi+mqyxWuzxork+ovj+o3l+3K4ypXn+12PnJrm+qXp+63j8cLx/M/0/ef4 /Jfp+57q+6Xt/Kjv/avv/a3v/a7w/bPw/bzz/uP6/+z7/vP9/7fz/r30/sD0/sX1/sn2/tT4/9L2 /d/6/+X7/+b7/+r8/+v7/sz3/tr5/ub8/+39//v///3///7//////yH5BAEAAP8ALAAAAAAYABgA AAj/AP8JHEiwoMGCAgggOGCg4YqHEB8aOPCCAEESKmR84MABg0cOHUKGHDCAA4gEBQaOiIHBwgQO pmrQEEEhg80NGnJewACDhcAUJyBMwBArgL8ACkxc2MBUg8cLEEy0+PkhQoMZAerNmxegBoMLFChc AFsBQggXAkswerBgVYB8+eLtu7GorgcKDipIcBBi6r8SHtiyCoAPH7x6AXAoxjELRYO9IUIJlGMn jBi37zLHo2fPXj19/hT8WRMGDzGBb7LosIUqADp07WC7c9eOHbwAmnjwGBNIYBwwuHK0NleOOLnj 5MaxC+BpR64zp//JGQNkx6kA4rKXO8ede7oAe378/1BTSGCdMkNunfIXLhw4eQH6yU88KoiSImzK /8tzpkiPVP1gg4013gRgYGKmEMEEE0a4oYhAeahhhA/c8FMNNdF0s4466tyzTgCrOAFFEnA0IhAf bCQhhCkBVPMMNDDC+GI3AUiCBBNwRCJQH24wgUQmAWwjTDJEFllMNAGIcoQTdDAjkB9uODGFFLHw o00wwGSZpS/bBJDJEk80+eQvTVQhxR2zBECLK6202c0rAchCxhVR3DGJb5I0gYUXVqRBCiy1BFqL Dd+oMocVW+jyCCEC6ZEIIFps0cUXVOyCRhuYomEGFVx0wcsghlwyUC/DOHPIMcg4AskyzbS6DCSO ICSDiDOCGFNQNspUYgkmm3TCCSjXgPJJJ9NIYwklpRyk7LIDBQQAOw== --_006_867F4B6A1672E541A94676D556793ACD0C27516671MOPESMBX01eut_ Content-Type: image/gif; name="image002.gif" Content-Description: image002.gif Content-Disposition: inline; filename="image002.gif"; size=1834; creation-date="Tue, 15 Nov 2011 07:57:00 GMT"; modification-date="Tue, 15 Nov 2011 07:57:00 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhcgBFAOZ/AEGueqipqmgxkACLS4ORyPb294DFpZrMVqvi+sXr2Ie3laLXtnRHnLQlZO3J 2M+pxP7pJvqtgePqmqOIvYLKnACP1fewoXa65/vCov71sdqRnc6OpPvrlcU/benvs7qmzpzR8P/n rc7imtLntMkhU/V7Hf/yl+fZ6f3HipjL7b+MraKs1h+WXIrU9fNrPv/dkaTIrpQpd/JlIr8kXv/o ALa3uO0bLwCmUQC68pKSlf/CDgxNosvbKtvb3IzGP8nJyoiJjPaWgH+Ag3Z3euTk5Y3Y+MTfm+3t 7r/AwZubnvBSJQCZ3NLS0//eAwN+yE84la9fmdjkX//RSiPB855BhP/ILiCvY9HeRvLkCvmykSld q/aNl4Dd+cPT6O85Q2m+Q6zRONnM5OPx0PR3OR2Z2eOttkCr4Lfbm//uQPWMWbeLscPbysbs/OP1 /ZeLwPaLN9blff/iEvXlByCi3nzB69eqvN7r4uzysHfDWSCKzu+Uh8R4pR6j4IVfqm1ucf///yH5 BAEAAH8ALAAAAAByAEUAAAf/gH+Cg4SFhoeIiYqLjI2Oj5CRkpOUlZaXmJmam5ydnp+goaKjpKWm p6ipqqusra6vsLGys7S1tqF+Oat+freMubu9vorAkkhIlryqBQWXxZBEvD2VyqhEQtPJupJJScnC pzV+2dTbqdWnSX4BNTWDR+01RIUFSO0/zX/AP+1Mg/x/iLRDku9PO0JH7NXA906hv0Ho/vSId2TQ xB4Jf1gKwKujoB8deWn8OCTkkIp+gAAJGUBQjnUhgUAEB9Lkx5C58lUr8DLkSHE5Spqb1IMjkh7T evgZ4o9JyYrR/Mib2FKfHyH4kPBq1rPGkR4lH1ZjsvQH0gDIlA7RSGSlN6uC/zgCmfcjrEFeQuRd EkeO48g/IN2pQ2boasGV014+/MPRHdw/QsYZUve3wFO4R5YWBOlN3FtMfAetBJKj9EpdEQk9+/My sWRB4hxXS3koNcdpypRWnXnXMejXf4SWHt4yNcShrVkDjy1o9lDehELnXldIGfNMoV0CJxSZnGrk kpPDltpc2FZDK+eJlqwsmsx3V3trEvdXK5CKgvKJu59fLHjX5FxXjVz5fHUXEPmAJER5gkQ2UgHq uHMdJiANkcNIK+WSQ2TraaiZPv8pFyB5jxWwkoUvLWjiVUlkmE01RJQERACRISifJhxR90cBNUTG YkE1ZAgEYTnsxlgO8wSA5P8/F7pkDo8+AvFgj7wkoR5r5hChzlU1JNjkMGCGKeaYZJZp5pmqsIHA mmyCkMKbcK4g55wrfGDnnR88oOeedZTh558WBCqoBRgUaigGISSqaAgZNOroHR5EKqkHI1Rq6QKY ZroADJx2CoMdjxSAQBGkktoCHRekqioBrLZKgBsTxCqrGirUaqsGuOaqgR5B9OprBMAGG8ELxBb7 ggnIJmuCBMw2K4EIRkQb7RkUVGstBQpkq60CazTSRqmlnqrqqq6yCqusstqqrq65+uqusMGiYCyx HCiLLAfONguttEZQe22122oLQ0GHsAGuqeOSW+656E6grq0bsIuru7/CG4H/vPMea++y+TK7r7T+ /huwtqAiMsXJKE/BBxkst5yHFjDHrAUDNNdMMxU450xFBzz3zLMXQAfthQtjFG30G1UkrXQVEDTt dNNXRC31FWAcYPXVeFih9dZWsOD11ywAkAgOZJeNwxIVpK22Ezu07fYOTwgg99wCxGD33TE0MMPe fJNgw9+A26CEDIQXXoIOiCeuQxM0NO44FjxELjkPYPhg+eVf3KD55jcM4PnnA4iNiNllo6122my/ 3XbcdMuN9916872334H/PXjhhB+uOOKMO9445JNHXvnllmfOueagfy76IaSTbfrpqavOeuuv2x27 7LTXfjvuuu/eu+/ABz88//HGH5+858sb0vzZp6Ou+uqtu1799X3Xbjvuue/Ou++/By888cU7HvLO l75CrO95a3sf3OJXt/nJbnb2Exz+ZNA9xX3vcf6jHAB9UD7OnS90Y2seAt33vunRrXp5e+AMshe4 7RlOf4vjHw3CN7nxYU6AnSNgCEk3wgpE720mnBsK6QdB+7kwf/q7YP/8BwcxOPGJC8DhBwtIiAO2 z4cKDKL8XkfEFUbwiBSEoRJpIIcomPGMUbiDIRIgRR2OToRXrEAX5kjHLvSBgUNUIQsBB8YSSOGP gJRCHGRIA0ewUYBTTAQXFslILswhjoe4Y/zy+EASbOGSmNyCCyYog0OggYeQhgSAKEcJABa40RFm gKQhThCGVrryAZR84CHSwElPgrISADhlI1J5RUc4IJaym2UtSZHL5FFREbxsny9RuAcHOPOZDjgE BrJAzWpmoRQLMIA2t7kASCTzdI44ARTGSU4oPABN6EynOtfJzna6853wjKc850nPetrznvjMpz73 yc9++tMUgQAAOw== --_006_867F4B6A1672E541A94676D556793ACD0C27516671MOPESMBX01eut_ Content-Type: image/gif; name="image003.gif" Content-Description: image003.gif Content-Disposition: inline; filename="image003.gif"; size=493; creation-date="Tue, 15 Nov 2011 07:57:01 GMT"; modification-date="Tue, 15 Nov 2011 07:57:01 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhHAAhAMQAALHNVVqXGZu+IqbFNv79/ury0pK4H2SdaJzAJNjlq/3++vL34srdiSl5Mfj7 8OHrvDmDE5u+Kb3VbtDgm5jCnJC2IqDBJHqqHoazHsfYxcfco+/58f7///7+/v///f///yH5BAAA AAAALAAAAAAcACEAAAX/4CeOZGmeaKqubOumXSfKL0rT9RiTe65/nl0vxxE1KB3Ph6b8KGYjT/Pn ORwIHmy0FEQFCZRG5yldJnEqD6ezaWQIHMJDApAwCthgF8hbEqwEBQARAoWFEgskQWgiChwFDRoD hpQCA3hLQGhxSWABFpQIlAMPT2NoeTIJEBigooavlzJDS0UdHAkBEAivAoSjDklTQAROuBYQn7+/ lBJJS01SUgoJoskWvaECCWUiHEEKtw+8BtegvoWxiYtqSmsLhBblEALn2hLDH3HTAIXYuhfqVeLF TZ8SR3oSULKAQVeAChYi8kJwCUg4BcVkOOiXDgHDACAvXMBQoWQEOw6iahwsMCmdAI8CKoiciUEA gAJ8aBC4xfKlz3QRsVGcoICMJidKOjhgMKCXqKcAJqSMIkwEuw8OHjCQwNVOggJPvqm4ZUJGuw47 lajlA0Sat28xyJZV9APasGEcvknBkU9TjJ1WrTZZE9hHihAAOw== --_006_867F4B6A1672E541A94676D556793ACD0C27516671MOPESMBX01eut_-- From mark@townsley.net Tue Nov 15 00:02:01 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E600C1F0CA7 for ; Tue, 15 Nov 2011 00:02:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGYnKXMH30mD for ; Tue, 15 Nov 2011 00:02:00 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 25C5C1F0C61 for ; Tue, 15 Nov 2011 00:02:00 -0800 (PST) Received: by ggnr5 with SMTP id r5so2153007ggn.31 for ; Tue, 15 Nov 2011 00:01:59 -0800 (PST) Received: by 10.68.33.134 with SMTP id r6mr40354423pbi.76.1321344119330; Tue, 15 Nov 2011 00:01:59 -0800 (PST) Received: from dhcp-13d7.meeting.ietf.org (64-104-46-217.cisco.com. [64.104.46.217]) by mx.google.com with ESMTPS id 4sm63040739pbj.18.2011.11.15.00.01.57 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 15 Nov 2011 00:01:58 -0800 (PST) From: Mark Townsley Content-Type: multipart/alternative; boundary=Apple-Mail-1--560468954 Date: Tue, 15 Nov 2011 16:01:54 +0800 Message-Id: To: "v6ops@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: Alexandre Cassen Subject: [v6ops] 6rd Sunsetting X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 Nov 2011 08:02:01 -0000 --Apple-Mail-1--560468954 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Alexandre and I just finished up a -00 that describes two methods for = moving a 6rd deployment to native IPv6. Apologies for not getting this = out before the meeting. http://www.ietf.org/id/draft-townsley-v6ops-6rd-sunsetting-00.txt Abstract This document provides guidelines for transitioning an IPv6 deployment using IPv6 Rapid Deployment (6rd) to an IPv6 deployment using Native IPv6. It is targeted at both 6rd operators and 6rd implementors." - Mark= --Apple-Mail-1--560468954 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

Alexandre and I just finished up a -00 that describes two methods for moving a 6rd deployment to native IPv6. Apologies for not getting this out before the meeting.


Abstract

   This document provides guidelines for transitioning an IPv6
   deployment using IPv6 Rapid Deployment (6rd) to an IPv6 deployment
   using Native IPv6.  It is targeted at both 6rd operators and 6rd
   implementors."

- Mark
--Apple-Mail-1--560468954-- From hansliu@gmail.com Tue Nov 15 00:17:52 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E905F11E808C for ; Tue, 15 Nov 2011 00:17:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.239 X-Spam-Level: X-Spam-Status: No, score=-3.239 tagged_above=-999 required=5 tests=[AWL=-0.240, 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 Zf74EWolQomk for ; Tue, 15 Nov 2011 00:17:51 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7D71F11E8086 for ; Tue, 15 Nov 2011 00:17:51 -0800 (PST) Received: by iaeo4 with SMTP id o4so10555592iae.31 for ; Tue, 15 Nov 2011 00:17:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=J5hX6Gn8M0/Pzs+DxKUUif6zXkvc3otr5sEQHVXrRmY=; b=SEeiyT6HjUX2gXPnh0WUpkfB8ZtTd66uyAu/8m05iBRf4nyBi4uDqdYf34KPP/XQr6 wGWGWPteFiwI6JGzUjDI3xgJn+xNKQWxw5zJBvqTKsoQLIxfvi3u97AuWylfy7M1ulKa pdReym81dK/KVO6t7yaJ/jIswUmAWP/KfZHNc= MIME-Version: 1.0 Received: by 10.231.68.130 with SMTP id v2mr5992080ibi.71.1321345069778; Tue, 15 Nov 2011 00:17:49 -0800 (PST) Received: by 10.231.172.71 with HTTP; Tue, 15 Nov 2011 00:17:49 -0800 (PST) In-Reply-To: References: Date: Tue, 15 Nov 2011 16:17:49 +0800 Message-ID: From: Hans Liu To: Mark Townsley Content-Type: text/plain; charset=UTF-8 Cc: Alexandre Cassen , "v6ops@ietf.org WG" , Claire Cheng Subject: Re: [v6ops] 6rd Sunsetting X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 Nov 2011 08:17:53 -0000 Excuse me Mark, I still don't have an idea in what kind of use case should we have 6rd and Native Dual Stack at the same time in the network? Regards, Hans On Tue, Nov 15, 2011 at 4:01 PM, Mark Townsley wrote: > > Alexandre and I just finished up a -00 that describes two methods for moving > a 6rd deployment to native IPv6. Apologies for not getting this out before > the meeting. > http://www.ietf.org/id/draft-townsley-v6ops-6rd-sunsetting-00.txt > > Abstract > > This document provides guidelines for transitioning an IPv6 > deployment using IPv6 Rapid Deployment (6rd) to an IPv6 deployment > using Native IPv6. It is targeted at both 6rd operators and 6rd > implementors." > > - Mark > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > -- Instead of following the fashion, we lead it through. From Carl.Wuyts@technicolor.com Tue Nov 15 00:32:45 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6215521F8B02 for ; Tue, 15 Nov 2011 00:32:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.232 X-Spam-Level: X-Spam-Status: No, score=-5.232 tagged_above=-999 required=5 tests=[AWL=0.767, 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 OoqW4g-HU+s1 for ; Tue, 15 Nov 2011 00:32:44 -0800 (PST) Received: from na3sys009aog124.obsmtp.com (na3sys009aog124.obsmtp.com [74.125.149.151]) by ietfa.amsl.com (Postfix) with ESMTP id 9D25621F84B5 for ; Tue, 15 Nov 2011 00:32:31 -0800 (PST) Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob124.postini.com ([74.125.148.12]) with SMTP ID DSNKTsIjmMLkDBol3MlBQd/dSZqtJKwjOsOo@postini.com; Tue, 15 Nov 2011 00:32:36 PST Received: from MOPESMAILHC03.eu.thmulti.com (141.11.100.132) by mail3.technicolor.com (141.11.253.22) with Microsoft SMTP Server (TLS) id 8.3.192.1; Tue, 15 Nov 2011 09:31:24 +0100 Received: from MOPESMBX01.eu.thmulti.com ([169.254.155.121]) by MOPESMAILHC03.eu.thmulti.com ([141.11.100.132]) with mapi; Tue, 15 Nov 2011 09:31:27 +0100 From: Wuyts Carl To: Hans Liu , Mark Townsley Date: Tue, 15 Nov 2011 09:31:26 +0100 Thread-Topic: [v6ops] 6rd Sunsetting Thread-Index: AcyjbxnNOQR0MG4fSJaDXSxBH1r2bAAAZqXw Message-ID: <867F4B6A1672E541A94676D556793ACD0C2751669B@MOPESMBX01.eu.thmulti.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Alexandre Cassen , "v6ops@ietf.org WG" , Claire Cheng Subject: Re: [v6ops] 6rd Sunsetting X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 Nov 2011 08:32:45 -0000 Why not. Apart from the described scenario in this draft (which in fact is= a temp 6rd/native setup), you could also have some CPE deployment using mu= ltiple Wan intfs, one of them being native, another one of them not (yet) n= ative, using 6rd. Carl Wuyts GCD System Architect Networking CONNECT DIVISION carl.wuyts@technicolor.com tel.: +32 3 443 65 90 Prins Boudewijnlaan 47=A0=A0-=A0=A02650 Edegem=A0=A0-=A0=A0Belgium Technicolor Delivery Technologies Belgium NV Registered office (maatschappelijke zetel): Prins Boudewijnlaan 47, 2650 Ed= egem, Belgium Company registration number (ondernemingsnummer): 0428837295 - RPR Antwerpe= n Help preserve the color of our world - Think before you print. -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of H= ans Liu Sent: dinsdag 15 november 2011 9:18 To: Mark Townsley Cc: Alexandre Cassen; v6ops@ietf.org WG; Claire Cheng Subject: Re: [v6ops] 6rd Sunsetting Excuse me Mark, I still don't have an idea in what kind of use case should = we have 6rd and Native Dual Stack at the same time in the network? Regards, Hans On Tue, Nov 15, 2011 at 4:01 PM, Mark Townsley wrote: > > Alexandre and I just finished up a -00 that describes two methods for=20 > moving a 6rd deployment to native IPv6. Apologies for not getting this=20 > out before the meeting. > http://www.ietf.org/id/draft-townsley-v6ops-6rd-sunsetting-00.txt > > Abstract > > This document provides guidelines for transitioning an IPv6 > deployment using IPv6 Rapid Deployment (6rd) to an IPv6 deployment > using Native IPv6. It is targeted at both 6rd operators and 6rd > implementors." > > - Mark > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > -- Instead of following the fashion, we lead it through. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From shemant@cisco.com Tue Nov 15 00:34:42 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCC8721F8DD5 for ; Tue, 15 Nov 2011 00:34:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.185 X-Spam-Level: X-Spam-Status: No, score=-6.185 tagged_above=-999 required=5 tests=[AWL=0.413, 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 8xpNsoM4YOVt for ; Tue, 15 Nov 2011 00:34:42 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id C51BD21F8DE1 for ; Tue, 15 Nov 2011 00:34:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=6212; q=dns/txt; s=iport; t=1321346082; x=1322555682; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=4s+dVE7+UfFwvp1s0veCtHcHBAp6jaqFWI1yg78BXNY=; b=jkBAGcdnt/G0umQcff1pGKH3Dj+lV3uESGYloE7iDHBL4d1EUh41aWhM lOKTs/9XgldEE6lhM5uF7S+mrIjWZKSXlAhUHL6FMFX6OgMLU5EkRXEb3 PwVp/4esLF1OQdjjXzdLRAt7A7pv9ujpDbiabkFgktnAIslLDXnmyk2VR Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApkAACEjwk6tJV2Z/2dsb2JhbABDgk2XGJAFgQWBcgEBAQMBEgEJEQNOCwIBCBEEAQELBhcBBgFFCQgCBAESCBqHYJxNAZ8IiSFjBIgRkWOMVQ X-IronPort-AV: E=Sophos;i="4.69,513,1315180800"; d="scan'208,217";a="36060511" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 15 Nov 2011 08:34:41 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pAF8YfKA016774; Tue, 15 Nov 2011 08:34:41 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Nov 2011 02:34:41 -0600 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCA371.6AE34B17" Date: Tue, 15 Nov 2011 02:34:39 -0600 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C303494FE5@XMB-RCD-109.cisco.com> In-Reply-To: <867F4B6A1672E541A94676D556793ACD0C27516671@MOPESMBX01.eu.thmulti.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] RFC6204bis-02 Thread-Index: AcyewOvBbq1YdOdiSD66Sp1uaN6CQwCSeq2gAGv1BCAAHHv0MAANyK5QAAHgk2AAADFEcAABKvkA References: <867F4B6A1672E541A94676D556793ACD0C263BCDD7@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303494A91@XMB-RCD-109.cisco.com> <867F4B6A1672E541A94676D556793ACD0C27516363@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303494F74@XMB-RCD-109.cisco.com> <867F4B6A1672E541A94676D556793ACD0C27516655@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303494FE3@XMB-RCD-109.cisco.com> <867F4B6A1672E541A94676D556793ACD0C27516671@MOPESMBX01.eu.thmulti.com> From: "Hemant Singh (shemant)" To: "Wuyts Carl" , X-OriginalArrivalTime: 15 Nov 2011 08:34:41.0032 (UTC) FILETIME=[6B18C880:01CCA371] Subject: Re: [v6ops] RFC6204bis-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, 15 Nov 2011 08:34:43 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCA371.6AE34B17 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 From: Wuyts Carl [mailto:Carl.Wuyts@technicolor.com]=20 Sent: Tuesday, November 15, 2011 3:57 PM To: Hemant Singh (shemant); v6ops@ietf.org Subject: RE: [v6ops] RFC6204bis-02 =20 > CPE should not have the task to automatically bring up/tear down the DSLite tunnel in case of "public" IPv4 presence. =20 RfC6204bis document does not mention any such behavior mentioned above. Please also note from the Coexistence section, the text says "Some guidelines follow:". A vendor is welcome to implement anything else they'd like. =20 =20 Thanks, =20 Hemant =20 ------_=_NextPart_001_01CCA371.6AE34B17 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

From:= = Wuyts Carl [mailto:Carl.Wuyts@technicolor.com]
Sent: Tuesday, = November 15, 2011 3:57 PM
To: Hemant Singh (shemant); = v6ops@ietf.org
Subject: RE: [v6ops] = RFC6204bis-02

 

> CPE should not have the task to automatically = bring up/tear down the DSLite tunnel in case of “public” = IPv4 presence.

 

RfC6204bis document does = not mention any such behavior mentioned above.   Please also = note from the Coexistence section, the text says “Some guidelines = follow:”.   A vendor is welcome to implement anything = else they’d like. 

 

Thanks,

 

Hemant

 

------_=_NextPart_001_01CCA371.6AE34B17-- From Francis.Dupont@fdupont.fr Tue Nov 15 00:35:01 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0390921F8DCE for ; Tue, 15 Nov 2011 00:35:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, 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 8xAESmwgVsRP for ; Tue, 15 Nov 2011 00:35:00 -0800 (PST) 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 1EA0521F8DC8 for ; Tue, 15 Nov 2011 00:34:59 -0800 (PST) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id pAF8Yjd8050074; Tue, 15 Nov 2011 09:34:45 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201111150834.pAF8Yjd8050074@givry.fdupont.fr> From: Francis Dupont To: Hans Liu In-reply-to: Your message of Tue, 15 Nov 2011 16:17:49 +0800. Date: Tue, 15 Nov 2011 09:34:45 +0100 Sender: Francis.Dupont@fdupont.fr Cc: Alexandre Cassen , "v6ops@ietf.org WG" , Claire Cheng Subject: Re: [v6ops] 6rd Sunsetting X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 Nov 2011 08:35:01 -0000 In your previous mail you wrote: Excuse me Mark, I still don't have an idea in what kind of use case should we have 6rd and Native Dual Stack at the same time in the network? => Mark used the word "moving" which IMHO strongly suggest we don't have both 6rd and native dual stack at the same time, doesn't it? Regards Francis.Dupont@fdupont.fr (happy user of 6rd and surely even more happy with native IPv6 :-) From Carl.Wuyts@technicolor.com Tue Nov 15 00:45:25 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44FD321F8FD3 for ; Tue, 15 Nov 2011 00:45:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.362 X-Spam-Level: X-Spam-Status: No, score=-4.362 tagged_above=-999 required=5 tests=[AWL=-0.184, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q1ukN8mQltYN for ; Tue, 15 Nov 2011 00:45:23 -0800 (PST) Received: from na3sys009aog124.obsmtp.com (na3sys009aog124.obsmtp.com [74.125.149.151]) by ietfa.amsl.com (Postfix) with ESMTP id E378921F8FC2 for ; Tue, 15 Nov 2011 00:45:20 -0800 (PST) Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob124.postini.com ([74.125.148.12]) with SMTP ID DSNKTsImoKaxy+POf8DUWuH6ShgukK7pzNQt@postini.com; Tue, 15 Nov 2011 00:45:21 PST 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.192.1; Tue, 15 Nov 2011 09:40:42 +0100 Received: from MOPESMBX01.eu.thmulti.com ([169.254.155.121]) by MOPESMAILHC01.eu.thmulti.com ([141.11.100.25]) with mapi; Tue, 15 Nov 2011 09:40:45 +0100 From: Wuyts Carl To: "Hemant Singh (shemant)" , "v6ops@ietf.org" Date: Tue, 15 Nov 2011 09:40:44 +0100 Thread-Topic: [v6ops] RFC6204bis-02 Thread-Index: AcyewOvBbq1YdOdiSD66Sp1uaN6CQwCSeq2gAGv1BCAAHHv0MAANyK5QAAHgk2AAADFEcAABKvkAAABIDxA= Message-ID: <867F4B6A1672E541A94676D556793ACD0C275166AC@MOPESMBX01.eu.thmulti.com> References: <867F4B6A1672E541A94676D556793ACD0C263BCDD7@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303494A91@XMB-RCD-109.cisco.com> <867F4B6A1672E541A94676D556793ACD0C27516363@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303494F74@XMB-RCD-109.cisco.com> <867F4B6A1672E541A94676D556793ACD0C27516655@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303494FE3@XMB-RCD-109.cisco.com> <867F4B6A1672E541A94676D556793ACD0C27516671@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303494FE5@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C303494FE5@XMB-RCD-109.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/related; boundary="_006_867F4B6A1672E541A94676D556793ACD0C275166ACMOPESMBX01eut_"; type="multipart/alternative" MIME-Version: 1.0 Subject: Re: [v6ops] RFC6204bis-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, 15 Nov 2011 08:45:25 -0000 --_006_867F4B6A1672E541A94676D556793ACD0C275166ACMOPESMBX01eut_ Content-Type: multipart/alternative; boundary="_000_867F4B6A1672E541A94676D556793ACD0C275166ACMOPESMBX01eut_" --_000_867F4B6A1672E541A94676D556793ACD0C275166ACMOPESMBX01eut_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ok, just want to make sure, as RFC6204 gets lots of interests lately in CPE= area (but also e.g. @ RIPE), to not miss out on anything here. The RFC6204bis says, quoted form it: "" If the IPv6 CE Router is configured with a public IPv4 address on its WAN interface, where public IPv4 address is defined as any address which is not in the private IP address space specified in [RFC5735]= and also not in the reserved IP address space specified in [RFC6333], then the IPv6 CE Router MUST disable the DS-Lite B4 element. "" MUST, so imho, the MUST should be replaced with MAY (or maybe SHOULD). Carl Wuyts GCD System Architect Networking Connect Division carl.wuyts@technicolor.com tel.: +32 3 443 65 90 [cid:image001.gif@01CCA37A.A532A8C0] [cid:image002.gif@01CCA37A.A532A8C0] Prins Boudewijnlaan 47 - 2650 Edegem - Belgium Technicolor Delivery Technologies Belgium NV Registered office (maatschappelijke zetel): Prins Boudewijnlaan 47, 2650 Ed= egem, Belgium Company registration number (ondernemingsnummer): 0428837295 - RPR Antwerpe= n [cid:image003.gif@01CCA37A.A532A8C0] Help preserve the color of our world - Think before you print. From: Hemant Singh (shemant) [mailto:shemant@cisco.com] Sent: dinsdag 15 november 2011 9:35 To: Wuyts Carl; v6ops@ietf.org Subject: RE: [v6ops] RFC6204bis-02 From: Wuyts Carl [mailto:Carl.Wuyts@technicolor.com] Sent: Tuesday, November 15, 2011 3:57 PM To: Hemant Singh (shemant); v6ops@ietf.org Subject: RE: [v6ops] RFC6204bis-02 > CPE should not have the task to automatically bring up/tear down the DSLi= te tunnel in case of "public" IPv4 presence. RfC6204bis document does not mention any such behavior mentioned above. P= lease also note from the Coexistence section, the text says "Some guideline= s follow:". A vendor is welcome to implement anything else they'd like. Thanks, Hemant --_000_867F4B6A1672E541A94676D556793ACD0C275166ACMOPESMBX01eut_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ok, just want to make sure, as RFC6204 gets lots of interests= lately in CPE area (but also e.g. @ RIPE), to not miss out on anything her= e.

= The RFC6204bis says, quoted form it:

“”

If the IPv6 CE Router is confi= gured with a public IPv4

         =   address on its WAN interface, where public IPv4 address is

  &= nbsp;        defined as any address whic= h is not in the private IP address

       &n= bsp;   space specified in [RFC5735] and = also not in the reserved IP

        &nb= sp;  address space specified in [RFC6333], then the IPv6 CE Router

   &= nbsp;       MUST disable the DS-Lite B4 eleme= nt.

“”

 

MUST, so imho, the MUST should be replaced with MAY (or = maybe SHOULD).

 

=

Carl Wuyts

GCD System Architect Networking

carl.wuyts@technicolor.c= om

tel.: +32 3 443 65 90

3Dtwitter3D"Visit=

Prins Boudewijnlaan 47&nbs= p; -  2650 Edegem  -  Belgium=

Technicolor Delivery Technologies Belgium NV

Registered office (maatschappelijke zetel): Prins Boudewijnlaan 47, = 2650 Edegem, Belgium

C= ompany registration number (ondernemingsnummer): 0428837295 - RPR Antwerpen=

=3DEco

Help preserve the color of our world= - Think before you print.

 

 

From: Hemant Singh (shemant) [mailto:shemant@cisco.com]
Sent: dinsdag 15 november 2011 9:35
To: Wuyts Carl; v6ops@ietf.orgSubject: RE: [v6ops] RFC6204bis-02

 

 

From: Wuyts Carl [mailt= o:Carl.Wuyts@technicolor.com]
Sent: Tuesday, November 15, 20= 11 3:57 PM
To: Hemant Singh (shemant); v6ops@ietf.org
Subject: RE: [v6ops] RFC6204bis-02

 

> CPE should not have the task to automatically bring up/tear = down the DSLite tunnel in case of “public” IPv4 presence.<= /o:p>

 

RfC6204bis document does not mention any such behavior mentioned above.&nb= sp;  Please also note from the Coexistence section, the text says R= 20;Some guidelines follow:”.   A vendor is welcome to imple= ment anything else they’d like. 

 

Thanks,

 

Hemant

&nbs= p;

= --_000_867F4B6A1672E541A94676D556793ACD0C275166ACMOPESMBX01eut_-- --_006_867F4B6A1672E541A94676D556793ACD0C275166ACMOPESMBX01eut_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=1351; creation-date="Tue, 15 Nov 2011 08:40:44 GMT"; modification-date="Tue, 15 Nov 2011 08:40:44 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhGAAYAPcAAAAAAP///1Sfum/L64bW8o7h/ofU74fT7pHb9pfa8u75/VbD5VzG6FvF5l3G 513F5l/G51/F5mHH52PH6GPI6GPI52TH6GXJ6GbI6GnK6mjJ6WjK6WzL6m/M63HN6nPN6nTN63fR 7XnR7XTI5FeVqnnN537T7n7R7H/T7X3O6Y3f+4jV73m903/E2oDE2pTf+ZPc9JTa8Zfa8aDd8LDj 9MXr9+z5/er3+/r9/imy1yyx1S202S2z1zK43TW63jW32zS22Ta53Te73za32zq84Dm53Du73j2/ 4j2+4T283z273kHB5D++4EHA4kG/4UPA40K/4UTB5EbD5UbB40rJ7EjD5ErG6EnE5knE5Ua720rE 5kvG507J607I6U3G50/K60u+3U2/4U7A4k2/3lLI6E/A31XN7lHC4VnP8FfL61PD4lXD5FXF41vR 8VfG5VO92lrJ51a+21i/21/O7F7L6VnB3VzE4mHN6l/H5V3D30+lvWDH41/E4GDF4WLH42rL6GvP 6l+2znLZ9W7Q62C1zGO50HXZ9HTY83ba9XXX8mW70nLO6nHN6We803rd+HXV73zf+mm91HXS62vA 12GpvWavw2ixxVmWp2qxxYDW7X3Q52yzxm+2yW60x4HS6HC2yXG3ynzD2I7a75Xb7pvh9F+HkqTg 8ajg76ff7qri8bPo97fm9Ljm9MXw/Mfw/NDz/dDx+tbx+dz0++H1++f5/uv5/Six1S+22jG01zK1 2EXD5E/M7U7H50yvyWPY91zJ5WjZ92za927b+HHY82G4z3Xd+FurwHXa9Xfc93ne+F+rv37h+2u/ 1YDi/H7c9YHh+YLh+YXi+mqyxWuzxork+ovj+o3l+3K4ypXn+12PnJrm+qXp+63j8cLx/M/0/ef4 /Jfp+57q+6Xt/Kjv/avv/a3v/a7w/bPw/bzz/uP6/+z7/vP9/7fz/r30/sD0/sX1/sn2/tT4/9L2 /d/6/+X7/+b7/+r8/+v7/sz3/tr5/ub8/+39//v///3///7//////yH5BAEAAP8ALAAAAAAYABgA AAj/AP8JHEiwoMGCAgggOGCg4YqHEB8aOPCCAEESKmR84MABg0cOHUKGHDCAA4gEBQaOiIHBwgQO pmrQEEEhg80NGnJewACDhcAUJyBMwBArgL8ACkxc2MBUg8cLEEy0+PkhQoMZAerNmxegBoMLFChc AFsBQggXAkswerBgVYB8+eLtu7GorgcKDipIcBBi6r8SHtiyCoAPH7x6AXAoxjELRYO9IUIJlGMn jBi37zLHo2fPXj19/hT8WRMGDzGBb7LosIUqADp07WC7c9eOHbwAmnjwGBNIYBwwuHK0NleOOLnj 5MaxC+BpR64zp//JGQNkx6kA4rKXO8ede7oAe378/1BTSGCdMkNunfIXLhw4eQH6yU88KoiSImzK /8tzpkiPVP1gg4013gRgYGKmEMEEE0a4oYhAeahhhA/c8FMNNdF0s4466tyzTgCrOAFFEnA0IhAf bCQhhCkBVPMMNDDC+GI3AUiCBBNwRCJQH24wgUQmAWwjTDJEFllMNAGIcoQTdDAjkB9uODGFFLHw o00wwGSZpS/bBJDJEk80+eQvTVQhxR2zBECLK6202c0rAchCxhVR3DGJb5I0gYUXVqRBCiy1BFqL Dd+oMocVW+jyCCEC6ZEIIFps0cUXVOyCRhuYomEGFVx0wcsghlwyUC/DOHPIMcg4AskyzbS6DCSO ICSDiDOCGFNQNspUYgkmm3TCCSjXgPJJJ9NIYwklpRyk7LIDBQQAOw== --_006_867F4B6A1672E541A94676D556793ACD0C275166ACMOPESMBX01eut_ Content-Type: image/gif; name="image002.gif" Content-Description: image002.gif Content-Disposition: inline; filename="image002.gif"; size=1834; creation-date="Tue, 15 Nov 2011 08:40:44 GMT"; modification-date="Tue, 15 Nov 2011 08:40:44 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhcgBFAOZ/AEGueqipqmgxkACLS4ORyPb294DFpZrMVqvi+sXr2Ie3laLXtnRHnLQlZO3J 2M+pxP7pJvqtgePqmqOIvYLKnACP1fewoXa65/vCov71sdqRnc6OpPvrlcU/benvs7qmzpzR8P/n rc7imtLntMkhU/V7Hf/yl+fZ6f3HipjL7b+MraKs1h+WXIrU9fNrPv/dkaTIrpQpd/JlIr8kXv/o ALa3uO0bLwCmUQC68pKSlf/CDgxNosvbKtvb3IzGP8nJyoiJjPaWgH+Ag3Z3euTk5Y3Y+MTfm+3t 7r/AwZubnvBSJQCZ3NLS0//eAwN+yE84la9fmdjkX//RSiPB855BhP/ILiCvY9HeRvLkCvmykSld q/aNl4Dd+cPT6O85Q2m+Q6zRONnM5OPx0PR3OR2Z2eOttkCr4Lfbm//uQPWMWbeLscPbysbs/OP1 /ZeLwPaLN9blff/iEvXlByCi3nzB69eqvN7r4uzysHfDWSCKzu+Uh8R4pR6j4IVfqm1ucf///yH5 BAEAAH8ALAAAAAByAEUAAAf/gH+Cg4SFhoeIiYqLjI2Oj5CRkpOUlZaXmJmam5ydnp+goaKjpKWm p6ipqqusra6vsLGys7S1tqF+Oat+freMubu9vorAkkhIlryqBQWXxZBEvD2VyqhEQtPJupJJScnC pzV+2dTbqdWnSX4BNTWDR+01RIUFSO0/zX/AP+1Mg/x/iLRDku9PO0JH7NXA906hv0Ho/vSId2TQ xB4Jf1gKwKujoB8deWn8OCTkkIp+gAAJGUBQjnUhgUAEB9Lkx5C58lUr8DLkSHE5Spqb1IMjkh7T evgZ4o9JyYrR/Mib2FKfHyH4kPBq1rPGkR4lH1ZjsvQH0gDIlA7RSGSlN6uC/zgCmfcjrEFeQuRd EkeO48g/IN2pQ2boasGV014+/MPRHdw/QsYZUve3wFO4R5YWBOlN3FtMfAetBJKj9EpdEQk9+/My sWRB4hxXS3koNcdpypRWnXnXMejXf4SWHt4yNcShrVkDjy1o9lDehELnXldIGfNMoV0CJxSZnGrk kpPDltpc2FZDK+eJlqwsmsx3V3trEvdXK5CKgvKJu59fLHjX5FxXjVz5fHUXEPmAJER5gkQ2UgHq uHMdJiANkcNIK+WSQ2TraaiZPv8pFyB5jxWwkoUvLWjiVUlkmE01RJQERACRISifJhxR90cBNUTG YkE1ZAgEYTnsxlgO8wSA5P8/F7pkDo8+AvFgj7wkoR5r5hChzlU1JNjkMGCGKeaYZJZp5pmqsIHA mmyCkMKbcK4g55wrfGDnnR88oOeedZTh558WBCqoBRgUaigGISSqaAgZNOroHR5EKqkHI1Rq6QKY ZroADJx2CoMdjxSAQBGkktoCHRekqioBrLZKgBsTxCqrGirUaqsGuOaqgR5B9OprBMAGG8ELxBb7 ggnIJmuCBMw2K4EIRkQb7RkUVGstBQpkq60CazTSRqmlnqrqqq6yCqusstqqrq65+uqusMGiYCyx HCiLLAfONguttEZQe22122oLQ0GHsAGuqeOSW+656E6grq0bsIuru7/CG4H/vPMea++y+TK7r7T+ /huwtqAiMsXJKE/BBxkst5yHFjDHrAUDNNdMMxU450xFBzz3zLMXQAfthQtjFG30G1UkrXQVEDTt dNNXRC31FWAcYPXVeFih9dZWsOD11ywAkAgOZJeNwxIVpK22Ezu07fYOTwgg99wCxGD33TE0MMPe fJNgw9+A26CEDIQXXoIOiCeuQxM0NO44FjxELjkPYPhg+eVf3KD55jcM4PnnA4iNiNllo6122my/ 3XbcdMuN9916872334H/PXjhhB+uOOKMO9445JNHXvnllmfOueagfy76IaSTbfrpqavOeuuv2x27 7LTXfjvuuu/eu+/ABz88//HGH5+858sb0vzZp6Ou+uqtu1799X3Xbjvuue/Ou++/By888cU7HvLO l75CrO95a3sf3OJXt/nJbnb2Exz+ZNA9xX3vcf6jHAB9UD7OnS90Y2seAt33vunRrXp5e+AMshe4 7RlOf4vjHw3CN7nxYU6AnSNgCEk3wgpE720mnBsK6QdB+7kwf/q7YP/8BwcxOPGJC8DhBwtIiAO2 z4cKDKL8XkfEFUbwiBSEoRJpIIcomPGMUbiDIRIgRR2OToRXrEAX5kjHLvSBgUNUIQsBB8YSSOGP gJRCHGRIA0ewUYBTTAQXFslILswhjoe4Y/zy+EASbOGSmNyCCyYog0OggYeQhgSAKEcJABa40RFm gKQhThCGVrryAZR84CHSwElPgrISADhlI1J5RUc4IJaym2UtSZHL5FFREbxsny9RuAcHOPOZDjgE BrJAzWpmoRQLMIA2t7kASCTzdI44ARTGSU4oPABN6EynOtfJzna6853wjKc850nPetrznvjMpz73 yc9++tMUgQAAOw== --_006_867F4B6A1672E541A94676D556793ACD0C275166ACMOPESMBX01eut_ Content-Type: image/gif; name="image003.gif" Content-Description: image003.gif Content-Disposition: inline; filename="image003.gif"; size=493; creation-date="Tue, 15 Nov 2011 08:40:44 GMT"; modification-date="Tue, 15 Nov 2011 08:40:44 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhHAAhAMQAALHNVVqXGZu+IqbFNv79/ury0pK4H2SdaJzAJNjlq/3++vL34srdiSl5Mfj7 8OHrvDmDE5u+Kb3VbtDgm5jCnJC2IqDBJHqqHoazHsfYxcfco+/58f7///7+/v///f///yH5BAAA AAAALAAAAAAcACEAAAX/4CeOZGmeaKqubOumXSfKL0rT9RiTe65/nl0vxxE1KB3Ph6b8KGYjT/Pn ORwIHmy0FEQFCZRG5yldJnEqD6ezaWQIHMJDApAwCthgF8hbEqwEBQARAoWFEgskQWgiChwFDRoD hpQCA3hLQGhxSWABFpQIlAMPT2NoeTIJEBigooavlzJDS0UdHAkBEAivAoSjDklTQAROuBYQn7+/ lBJJS01SUgoJoskWvaECCWUiHEEKtw+8BtegvoWxiYtqSmsLhBblEALn2hLDH3HTAIXYuhfqVeLF TZ8SR3oSULKAQVeAChYi8kJwCUg4BcVkOOiXDgHDACAvXMBQoWQEOw6iahwsMCmdAI8CKoiciUEA gAJ8aBC4xfKlz3QRsVGcoICMJidKOjhgMKCXqKcAJqSMIkwEuw8OHjCQwNVOggJPvqm4ZUJGuw47 lajlA0Sat28xyJZV9APasGEcvknBkU9TjJ1WrTZZE9hHihAAOw== --_006_867F4B6A1672E541A94676D556793ACD0C275166ACMOPESMBX01eut_-- From mark@townsley.net Tue Nov 15 00:46:02 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A39821F8FEA for ; Tue, 15 Nov 2011 00:46:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, 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 Sb+lS1RrohLX for ; Tue, 15 Nov 2011 00:46:02 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0897021F8FDF for ; Tue, 15 Nov 2011 00:46:01 -0800 (PST) Received: by ywt34 with SMTP id 34so5960077ywt.31 for ; Tue, 15 Nov 2011 00:46:01 -0800 (PST) Received: by 10.68.4.38 with SMTP id h6mr51114749pbh.5.1321346761291; Tue, 15 Nov 2011 00:46:01 -0800 (PST) Received: from dhcp-13d7.meeting.ietf.org (64-104-46-217.cisco.com. [64.104.46.217]) by mx.google.com with ESMTPS id s4sm63335460pbq.8.2011.11.15.00.45.58 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 15 Nov 2011 00:45:59 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: <201111150834.pAF8Yjd8050074@givry.fdupont.fr> Date: Tue, 15 Nov 2011 16:45:54 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201111150834.pAF8Yjd8050074@givry.fdupont.fr> To: Francis Dupont X-Mailer: Apple Mail (2.1084) Cc: Alexandre Cassen , "v6ops@ietf.org WG" , Claire Cheng Subject: Re: [v6ops] 6rd Sunsetting X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 Nov 2011 08:46:02 -0000 On Nov 15, 2011, at 4:34 PM, Francis Dupont wrote: > In your previous mail you wrote: >=20 > Excuse me Mark, I still don't have an idea in what kind of use case > should we have 6rd and Native Dual Stack at the same time in the > network? >=20 > =3D> Mark used the word "moving" which IMHO strongly suggest we don't > have both 6rd and native dual stack at the same time, doesn't it? Both methods described in the document are incremental, one requiring = renumbering and the associated (general) issues with that, the other = not. In either case, you will have 6rd and native at the same time in = the network as you move subscribers over time.=20 - Mark >=20 > Regards >=20 > Francis.Dupont@fdupont.fr (happy user of 6rd and surely even more = happy > with native IPv6 :-) From mark@townsley.net Tue Nov 15 00:46:45 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7FD521F8FDD for ; Tue, 15 Nov 2011 00:46:45 -0800 (PST) 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 vkj7Wj-jOAWo for ; Tue, 15 Nov 2011 00:46:45 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 35A6B21F8FBF for ; Tue, 15 Nov 2011 00:46:45 -0800 (PST) Received: by ggnr5 with SMTP id r5so2198500ggn.31 for ; Tue, 15 Nov 2011 00:46:44 -0800 (PST) Received: by 10.68.209.9 with SMTP id mi9mr16991190pbc.62.1321346804427; Tue, 15 Nov 2011 00:46:44 -0800 (PST) Received: from dhcp-13d7.meeting.ietf.org (64-104-46-217.cisco.com. [64.104.46.217]) by mx.google.com with ESMTPS id s4sm63335460pbq.8.2011.11.15.00.46.41 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 15 Nov 2011 00:46:43 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: Date: Tue, 15 Nov 2011 16:46:41 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <1F0FCAA1-EE6D-4B20-8F1F-7F985F97493A@townsley.net> References: To: Hans Liu X-Mailer: Apple Mail (2.1084) Cc: Alexandre Cassen , "v6ops@ietf.org WG" , Claire Cheng Subject: Re: [v6ops] 6rd Sunsetting X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 Nov 2011 08:46:45 -0000 On Nov 15, 2011, at 4:17 PM, Hans Liu wrote: > Excuse me Mark, I still don't have an idea in what kind of use case > should we have 6rd and Native Dual Stack at the same time in the > network? Incremental transition from 6rd to native.=20 - Mark >=20 > Regards, > Hans >=20 > On Tue, Nov 15, 2011 at 4:01 PM, Mark Townsley = wrote: >>=20 >> Alexandre and I just finished up a -00 that describes two methods for = moving >> a 6rd deployment to native IPv6. Apologies for not getting this out = before >> the meeting. >> http://www.ietf.org/id/draft-townsley-v6ops-6rd-sunsetting-00.txt >>=20 >> Abstract >>=20 >> This document provides guidelines for transitioning an IPv6 >> deployment using IPv6 Rapid Deployment (6rd) to an IPv6 deployment >> using Native IPv6. It is targeted at both 6rd operators and 6rd >> implementors." >>=20 >> - Mark >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >>=20 >=20 >=20 >=20 > --=20 > Instead of following the fashion, we lead it through. From shemant@cisco.com Tue Nov 15 00:49:11 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD74421F8FC2 for ; Tue, 15 Nov 2011 00:49:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.191 X-Spam-Level: X-Spam-Status: No, score=-6.191 tagged_above=-999 required=5 tests=[AWL=0.407, 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 5a7gkEpO+cIw for ; Tue, 15 Nov 2011 00:49:10 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 5126B21F8E65 for ; Tue, 15 Nov 2011 00:49:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=9463; q=dns/txt; s=iport; t=1321346950; x=1322556550; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=5DcmLZs7uKw8MBXMzWHLIAwapYvpY98c72XaHKVCNC4=; b=U0ZzmkmIOrO/JOH0xsjX0RjU+ODX/DChYeZ+Uyz10ShsaMYtrPwBEMan dfKZemUpaR4paAsjyfuLxbRZ0JLjSIhrKutkSDoFa5GZVUz5Oy7NSuCAA Lh4p0vVlEXYgSRPm6KnsNK+bAJM5j9dK1qCFhlfn5OJvN0GOr1HfXgALx E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApkAABYnwk6tJXHB/2dsb2JhbABDgk2XGIgVAYdvgQWBcgEBAQQSAQkRA0kQAgEIEQQBAQsGFwEGAUUJCAIEARIIGodonDEBnwiJIWMEiBGRY4xV X-IronPort-AV: E=Sophos;i="4.69,513,1315180800"; d="scan'208,217";a="36056633" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-4.cisco.com with ESMTP; 15 Nov 2011 08:49:06 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id pAF8n6qN032112; Tue, 15 Nov 2011 08:49:06 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Nov 2011 02:49:06 -0600 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCA373.6EB3930F" Date: Tue, 15 Nov 2011 02:49:04 -0600 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C303494FE8@XMB-RCD-109.cisco.com> In-Reply-To: <867F4B6A1672E541A94676D556793ACD0C275166AC@MOPESMBX01.eu.thmulti.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] RFC6204bis-02 Thread-Index: AcyewOvBbq1YdOdiSD66Sp1uaN6CQwCSeq2gAGv1BCAAHHv0MAANyK5QAAHgk2AAADFEcAABKvkAAABIDxAAAFiyMA== References: <867F4B6A1672E541A94676D556793ACD0C263BCDD7@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303494A91@XMB-RCD-109.cisco.com> <867F4B6A1672E541A94676D556793ACD0C27516363@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303494F74@XMB-RCD-109.cisco.com> <867F4B6A1672E541A94676D556793ACD0C27516655@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303494FE3@XMB-RCD-109.cisco.com> <867F4B6A1672E541A94676D556793ACD0C27516671@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303494FE5@XMB-RCD-109.cisco.com> <867F4B6A1672E541A94676D556793ACD0C275166AC@MOPESMBX01.eu.thmulti.com> From: "Hemant Singh (shemant)" To: "Wuyts Carl" , X-OriginalArrivalTime: 15 Nov 2011 08:49:06.0373 (UTC) FILETIME=[6EE15750:01CCA373] Cc: "Lee, Yiu" Subject: Re: [v6ops] RFC6204bis-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, 15 Nov 2011 08:49:11 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCA373.6EB3930F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable One author (cced in this email) of the DS-Lite RFC was agreeable to this bullet. I will ask him if he is OK with changing the MUST to a SHOULD and then we can consider the change. =20 Thanks, =20 Hemant =20 From: Wuyts Carl [mailto:Carl.Wuyts@technicolor.com]=20 Sent: Tuesday, November 15, 2011 4:41 PM To: Hemant Singh (shemant); v6ops@ietf.org Subject: RE: [v6ops] RFC6204bis-02 =20 Ok, just want to make sure, as RFC6204 gets lots of interests lately in CPE area (but also e.g. @ RIPE), to not miss out on anything here. The RFC6204bis says, quoted form it: "" If the IPv6 CE Router is configured with a public IPv4 address on its WAN interface, where public IPv4 address is defined as any address which is not in the private IP address space specified in [RFC5735 ] and also not in the reserved IP address space specified in [RFC6333 ], then the IPv6 CE Router MUST disable the DS-Lite B4 element. "" =20 MUST, so imho, the MUST should be replaced with MAY (or maybe SHOULD). =20 ------_=_NextPart_001_01CCA373.6EB3930F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

One author (cced in this email) of the DS-Lite = RFC was agreeable to this bullet.   I will ask him if he is OK = with changing the MUST to a SHOULD and then we can consider the = change.

 

Thanks,

 

Hemant

 

From:= = Wuyts Carl [mailto:Carl.Wuyts@technicolor.com]
Sent: Tuesday, = November 15, 2011 4:41 PM
To: Hemant Singh (shemant); = v6ops@ietf.org
Subject: RE: [v6ops] = RFC6204bis-02

 

Ok, just want to make sure, as RFC6204 gets lots = of interests lately in CPE area (but also e.g. @ RIPE), to not miss out = on anything here.

The RFC6204bis says, quoted form = it:

“”

If the IPv6 CE = Router is configured with a public IPv4

           = address on its WAN interface, where public IPv4 address = is

           = defined as any address which is not in the private IP = address

           space = specified in [RFC5735] and also = not in the reserved IP

           = address space specified in [RFC6333], then the IPv6 CE = Router

           MUST = disable the DS-Lite B4 element.

“”

 

MUST, so imho, the MUST = should be replaced with MAY (or maybe SHOULD).

 

------_=_NextPart_001_01CCA373.6EB3930F-- From Carl.Wuyts@technicolor.com Tue Nov 15 00:53:18 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30AAC21F9008 for ; Tue, 15 Nov 2011 00:53:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.352 X-Spam-Level: X-Spam-Status: No, score=-4.352 tagged_above=-999 required=5 tests=[AWL=-0.174, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xsvq1beXM4db for ; Tue, 15 Nov 2011 00:53:15 -0800 (PST) Received: from na3sys009aog118.obsmtp.com (na3sys009aog118.obsmtp.com [74.125.149.244]) by ietfa.amsl.com (Postfix) with ESMTP id 0F66421F8FF5 for ; Tue, 15 Nov 2011 00:53:09 -0800 (PST) Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob118.postini.com ([74.125.148.12]) with SMTP ID DSNKTsIodCEsJnGMLwIuD0DL5EgnCXExK168@postini.com; Tue, 15 Nov 2011 00:53:11 PST 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.192.1; Tue, 15 Nov 2011 09:48:10 +0100 Received: from MOPESMBX01.eu.thmulti.com ([141.11.100.105]) by MOPESMAILHC02.eu.thmulti.com ([141.11.100.29]) with mapi; Tue, 15 Nov 2011 09:48:13 +0100 From: Wuyts Carl To: Mark Townsley , "v6ops@ietf.org WG" Date: Tue, 15 Nov 2011 09:48:10 +0100 Thread-Topic: [v6ops] 6rd Sunsetting Thread-Index: AcyjbOONSuOnuxKZQSGwIx05LaLVfAABixAQ Message-ID: <867F4B6A1672E541A94676D556793ACD0C275166BE@MOPESMBX01.eu.thmulti.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/related; boundary="_006_867F4B6A1672E541A94676D556793ACD0C275166BEMOPESMBX01eut_"; type="multipart/alternative" MIME-Version: 1.0 Cc: Alexandre Cassen Subject: Re: [v6ops] 6rd Sunsetting X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 Nov 2011 08:53:18 -0000 --_006_867F4B6A1672E541A94676D556793ACD0C275166BEMOPESMBX01eut_ Content-Type: multipart/alternative; boundary="_000_867F4B6A1672E541A94676D556793ACD0C275166BEMOPESMBX01eut_" --_000_867F4B6A1672E541A94676D556793ACD0C275166BEMOPESMBX01eut_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Question: In case the CPE must be able to cope with an identical IPv6 PD, a= s in "" 6rd and native IPv6 MUST allow for an identical IPv6 delegated prefix. "" Then how does it exactly work with timer updates (as they might be differen= t and done on different times by both mechanisms) ? Carl Wuyts GCD System Architect Networking Connect Division carl.wuyts@technicolor.com tel.: +32 3 443 65 90 [cid:image001.gif@01CCA37B.AF931A60] [cid:image002.gif@01CCA37B.AF931A60] Prins Boudewijnlaan 47 - 2650 Edegem - Belgium Technicolor Delivery Technologies Belgium NV Registered office (maatschappelijke zetel): Prins Boudewijnlaan 47, 2650 Ed= egem, Belgium Company registration number (ondernemingsnummer): 0428837295 - RPR Antwerpe= n [cid:image003.gif@01CCA37B.AF931A60] Help preserve the color of our world - Think before you print. From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of M= ark Townsley Sent: dinsdag 15 november 2011 9:02 To: v6ops@ietf.org WG Cc: Alexandre Cassen Subject: [v6ops] 6rd Sunsetting Alexandre and I just finished up a -00 that describes two methods for movin= g a 6rd deployment to native IPv6. Apologies for not getting this out befor= e the meeting. http://www.ietf.org/id/draft-townsley-v6ops-6rd-sunsetting-00.txt Abstract This document provides guidelines for transitioning an IPv6 deployment using IPv6 Rapid Deployment (6rd) to an IPv6 deployment using Native IPv6. It is targeted at both 6rd operators and 6rd implementors." - Mark --_000_867F4B6A1672E541A94676D556793ACD0C275166BEMOPESMBX01eut_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Question:= In case the CPE must be able to cope with an identical IPv6 PD, as in=

“”

6rd and native IPv6 MUST allow for an identical IPv6 delegated

       prefix.<= /o:p>

“”

Then how does it exactly work with timer u= pdates (as they might be different and done on different times by both mech= anisms) ?

 

 

Carl Wuyts

GCD System Architect Networking

Conne= ct Division

carl.wuyts@technicolor.com

tel.: +32 3 443 65 90

3Dtwitter

3D"Visit

Prins Boudewijnlaan = 47  -  2650 Edegem  -  Belgium=

= Technicolor Delivery Technologies Belgium NV=

Registered office (maatschappelijke zetel): Prins Boudewijnlaan= 47, 2650 Edegem, Belgium

= Company registration number (ondernemingsnummer): 0428837295 - RPR Antw= erpen

3DEco

Help preserve the color of our w= orld - Think before you print.

<= /td>

 <= /o:p>

 <= /p>

From: v6ops-bounces@ietf.org [mailto:v6= ops-bounces@ietf.org] On Behalf Of Mark Townsley
Sent: din= sdag 15 november 2011 9:02
To: v6ops@ietf.org WG
Cc: Al= exandre Cassen
Subject: [v6ops] 6rd Sunsetting<= /p>

 

 

Alexandre and = I just finished up a -00 that describes two methods for moving a 6rd deploy= ment to native IPv6. Apologies for not getting this out before the meeting.=

 

<= div>

http://www.ietf.org/id/draft-townsley-v6ops-6rd= -sunsetting-00.txt

&= nbsp;

Abstract
 
  =
; This document provides guidelines for transitioning an IPv6
   deployment using IP=
v6 Rapid Deployment (6rd) to an IPv6 deployment
   using Native IPv6.  It is ta= rgeted at both 6rd operators and 6rd
   implementors."
<= /div>

 

- Mark

= --_000_867F4B6A1672E541A94676D556793ACD0C275166BEMOPESMBX01eut_-- --_006_867F4B6A1672E541A94676D556793ACD0C275166BEMOPESMBX01eut_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=1351; creation-date="Tue, 15 Nov 2011 08:48:11 GMT"; modification-date="Tue, 15 Nov 2011 08:48:11 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhGAAYAPcAAAAAAP///1Sfum/L64bW8o7h/ofU74fT7pHb9pfa8u75/VbD5VzG6FvF5l3G 513F5l/G51/F5mHH52PH6GPI6GPI52TH6GXJ6GbI6GnK6mjJ6WjK6WzL6m/M63HN6nPN6nTN63fR 7XnR7XTI5FeVqnnN537T7n7R7H/T7X3O6Y3f+4jV73m903/E2oDE2pTf+ZPc9JTa8Zfa8aDd8LDj 9MXr9+z5/er3+/r9/imy1yyx1S202S2z1zK43TW63jW32zS22Ta53Te73za32zq84Dm53Du73j2/ 4j2+4T283z273kHB5D++4EHA4kG/4UPA40K/4UTB5EbD5UbB40rJ7EjD5ErG6EnE5knE5Ua720rE 5kvG507J607I6U3G50/K60u+3U2/4U7A4k2/3lLI6E/A31XN7lHC4VnP8FfL61PD4lXD5FXF41vR 8VfG5VO92lrJ51a+21i/21/O7F7L6VnB3VzE4mHN6l/H5V3D30+lvWDH41/E4GDF4WLH42rL6GvP 6l+2znLZ9W7Q62C1zGO50HXZ9HTY83ba9XXX8mW70nLO6nHN6We803rd+HXV73zf+mm91HXS62vA 12GpvWavw2ixxVmWp2qxxYDW7X3Q52yzxm+2yW60x4HS6HC2yXG3ynzD2I7a75Xb7pvh9F+HkqTg 8ajg76ff7qri8bPo97fm9Ljm9MXw/Mfw/NDz/dDx+tbx+dz0++H1++f5/uv5/Six1S+22jG01zK1 2EXD5E/M7U7H50yvyWPY91zJ5WjZ92za927b+HHY82G4z3Xd+FurwHXa9Xfc93ne+F+rv37h+2u/ 1YDi/H7c9YHh+YLh+YXi+mqyxWuzxork+ovj+o3l+3K4ypXn+12PnJrm+qXp+63j8cLx/M/0/ef4 /Jfp+57q+6Xt/Kjv/avv/a3v/a7w/bPw/bzz/uP6/+z7/vP9/7fz/r30/sD0/sX1/sn2/tT4/9L2 /d/6/+X7/+b7/+r8/+v7/sz3/tr5/ub8/+39//v///3///7//////yH5BAEAAP8ALAAAAAAYABgA AAj/AP8JHEiwoMGCAgggOGCg4YqHEB8aOPCCAEESKmR84MABg0cOHUKGHDCAA4gEBQaOiIHBwgQO pmrQEEEhg80NGnJewACDhcAUJyBMwBArgL8ACkxc2MBUg8cLEEy0+PkhQoMZAerNmxegBoMLFChc AFsBQggXAkswerBgVYB8+eLtu7GorgcKDipIcBBi6r8SHtiyCoAPH7x6AXAoxjELRYO9IUIJlGMn jBi37zLHo2fPXj19/hT8WRMGDzGBb7LosIUqADp07WC7c9eOHbwAmnjwGBNIYBwwuHK0NleOOLnj 5MaxC+BpR64zp//JGQNkx6kA4rKXO8ede7oAe378/1BTSGCdMkNunfIXLhw4eQH6yU88KoiSImzK /8tzpkiPVP1gg4013gRgYGKmEMEEE0a4oYhAeahhhA/c8FMNNdF0s4466tyzTgCrOAFFEnA0IhAf bCQhhCkBVPMMNDDC+GI3AUiCBBNwRCJQH24wgUQmAWwjTDJEFllMNAGIcoQTdDAjkB9uODGFFLHw o00wwGSZpS/bBJDJEk80+eQvTVQhxR2zBECLK6202c0rAchCxhVR3DGJb5I0gYUXVqRBCiy1BFqL Dd+oMocVW+jyCCEC6ZEIIFps0cUXVOyCRhuYomEGFVx0wcsghlwyUC/DOHPIMcg4AskyzbS6DCSO ICSDiDOCGFNQNspUYgkmm3TCCSjXgPJJJ9NIYwklpRyk7LIDBQQAOw== --_006_867F4B6A1672E541A94676D556793ACD0C275166BEMOPESMBX01eut_ Content-Type: image/gif; name="image002.gif" Content-Description: image002.gif Content-Disposition: inline; filename="image002.gif"; size=1834; creation-date="Tue, 15 Nov 2011 08:48:11 GMT"; modification-date="Tue, 15 Nov 2011 08:48:11 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhcgBFAOZ/AEGueqipqmgxkACLS4ORyPb294DFpZrMVqvi+sXr2Ie3laLXtnRHnLQlZO3J 2M+pxP7pJvqtgePqmqOIvYLKnACP1fewoXa65/vCov71sdqRnc6OpPvrlcU/benvs7qmzpzR8P/n rc7imtLntMkhU/V7Hf/yl+fZ6f3HipjL7b+MraKs1h+WXIrU9fNrPv/dkaTIrpQpd/JlIr8kXv/o ALa3uO0bLwCmUQC68pKSlf/CDgxNosvbKtvb3IzGP8nJyoiJjPaWgH+Ag3Z3euTk5Y3Y+MTfm+3t 7r/AwZubnvBSJQCZ3NLS0//eAwN+yE84la9fmdjkX//RSiPB855BhP/ILiCvY9HeRvLkCvmykSld q/aNl4Dd+cPT6O85Q2m+Q6zRONnM5OPx0PR3OR2Z2eOttkCr4Lfbm//uQPWMWbeLscPbysbs/OP1 /ZeLwPaLN9blff/iEvXlByCi3nzB69eqvN7r4uzysHfDWSCKzu+Uh8R4pR6j4IVfqm1ucf///yH5 BAEAAH8ALAAAAAByAEUAAAf/gH+Cg4SFhoeIiYqLjI2Oj5CRkpOUlZaXmJmam5ydnp+goaKjpKWm p6ipqqusra6vsLGys7S1tqF+Oat+freMubu9vorAkkhIlryqBQWXxZBEvD2VyqhEQtPJupJJScnC pzV+2dTbqdWnSX4BNTWDR+01RIUFSO0/zX/AP+1Mg/x/iLRDku9PO0JH7NXA906hv0Ho/vSId2TQ xB4Jf1gKwKujoB8deWn8OCTkkIp+gAAJGUBQjnUhgUAEB9Lkx5C58lUr8DLkSHE5Spqb1IMjkh7T evgZ4o9JyYrR/Mib2FKfHyH4kPBq1rPGkR4lH1ZjsvQH0gDIlA7RSGSlN6uC/zgCmfcjrEFeQuRd EkeO48g/IN2pQ2boasGV014+/MPRHdw/QsYZUve3wFO4R5YWBOlN3FtMfAetBJKj9EpdEQk9+/My sWRB4hxXS3koNcdpypRWnXnXMejXf4SWHt4yNcShrVkDjy1o9lDehELnXldIGfNMoV0CJxSZnGrk kpPDltpc2FZDK+eJlqwsmsx3V3trEvdXK5CKgvKJu59fLHjX5FxXjVz5fHUXEPmAJER5gkQ2UgHq uHMdJiANkcNIK+WSQ2TraaiZPv8pFyB5jxWwkoUvLWjiVUlkmE01RJQERACRISifJhxR90cBNUTG YkE1ZAgEYTnsxlgO8wSA5P8/F7pkDo8+AvFgj7wkoR5r5hChzlU1JNjkMGCGKeaYZJZp5pmqsIHA mmyCkMKbcK4g55wrfGDnnR88oOeedZTh558WBCqoBRgUaigGISSqaAgZNOroHR5EKqkHI1Rq6QKY ZroADJx2CoMdjxSAQBGkktoCHRekqioBrLZKgBsTxCqrGirUaqsGuOaqgR5B9OprBMAGG8ELxBb7 ggnIJmuCBMw2K4EIRkQb7RkUVGstBQpkq60CazTSRqmlnqrqqq6yCqusstqqrq65+uqusMGiYCyx HCiLLAfONguttEZQe22122oLQ0GHsAGuqeOSW+656E6grq0bsIuru7/CG4H/vPMea++y+TK7r7T+ /huwtqAiMsXJKE/BBxkst5yHFjDHrAUDNNdMMxU450xFBzz3zLMXQAfthQtjFG30G1UkrXQVEDTt dNNXRC31FWAcYPXVeFih9dZWsOD11ywAkAgOZJeNwxIVpK22Ezu07fYOTwgg99wCxGD33TE0MMPe fJNgw9+A26CEDIQXXoIOiCeuQxM0NO44FjxELjkPYPhg+eVf3KD55jcM4PnnA4iNiNllo6122my/ 3XbcdMuN9916872334H/PXjhhB+uOOKMO9445JNHXvnllmfOueagfy76IaSTbfrpqavOeuuv2x27 7LTXfjvuuu/eu+/ABz88//HGH5+858sb0vzZp6Ou+uqtu1799X3Xbjvuue/Ou++/By888cU7HvLO l75CrO95a3sf3OJXt/nJbnb2Exz+ZNA9xX3vcf6jHAB9UD7OnS90Y2seAt33vunRrXp5e+AMshe4 7RlOf4vjHw3CN7nxYU6AnSNgCEk3wgpE720mnBsK6QdB+7kwf/q7YP/8BwcxOPGJC8DhBwtIiAO2 z4cKDKL8XkfEFUbwiBSEoRJpIIcomPGMUbiDIRIgRR2OToRXrEAX5kjHLvSBgUNUIQsBB8YSSOGP gJRCHGRIA0ewUYBTTAQXFslILswhjoe4Y/zy+EASbOGSmNyCCyYog0OggYeQhgSAKEcJABa40RFm gKQhThCGVrryAZR84CHSwElPgrISADhlI1J5RUc4IJaym2UtSZHL5FFREbxsny9RuAcHOPOZDjgE BrJAzWpmoRQLMIA2t7kASCTzdI44ARTGSU4oPABN6EynOtfJzna6853wjKc850nPetrznvjMpz73 yc9++tMUgQAAOw== --_006_867F4B6A1672E541A94676D556793ACD0C275166BEMOPESMBX01eut_ Content-Type: image/gif; name="image003.gif" Content-Description: image003.gif Content-Disposition: inline; filename="image003.gif"; size=493; creation-date="Tue, 15 Nov 2011 08:48:12 GMT"; modification-date="Tue, 15 Nov 2011 08:48:12 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhHAAhAMQAALHNVVqXGZu+IqbFNv79/ury0pK4H2SdaJzAJNjlq/3++vL34srdiSl5Mfj7 8OHrvDmDE5u+Kb3VbtDgm5jCnJC2IqDBJHqqHoazHsfYxcfco+/58f7///7+/v///f///yH5BAAA AAAALAAAAAAcACEAAAX/4CeOZGmeaKqubOumXSfKL0rT9RiTe65/nl0vxxE1KB3Ph6b8KGYjT/Pn ORwIHmy0FEQFCZRG5yldJnEqD6ezaWQIHMJDApAwCthgF8hbEqwEBQARAoWFEgskQWgiChwFDRoD hpQCA3hLQGhxSWABFpQIlAMPT2NoeTIJEBigooavlzJDS0UdHAkBEAivAoSjDklTQAROuBYQn7+/ lBJJS01SUgoJoskWvaECCWUiHEEKtw+8BtegvoWxiYtqSmsLhBblEALn2hLDH3HTAIXYuhfqVeLF TZ8SR3oSULKAQVeAChYi8kJwCUg4BcVkOOiXDgHDACAvXMBQoWQEOw6iahwsMCmdAI8CKoiciUEA gAJ8aBC4xfKlz3QRsVGcoICMJidKOjhgMKCXqKcAJqSMIkwEuw8OHjCQwNVOggJPvqm4ZUJGuw47 lajlA0Sat28xyJZV9APasGEcvknBkU9TjJ1WrTZZE9hHihAAOw== --_006_867F4B6A1672E541A94676D556793ACD0C275166BEMOPESMBX01eut_-- From Carl.Wuyts@technicolor.com Tue Nov 15 00:54:04 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EF4121F9008 for ; Tue, 15 Nov 2011 00:54:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.344 X-Spam-Level: X-Spam-Status: No, score=-4.344 tagged_above=-999 required=5 tests=[AWL=-0.166, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FUbeLc0+L6XT for ; Tue, 15 Nov 2011 00:54:03 -0800 (PST) Received: from na3sys009aog117.obsmtp.com (na3sys009aog117.obsmtp.com [74.125.149.242]) by ietfa.amsl.com (Postfix) with ESMTP id F2B1721F9013 for ; Tue, 15 Nov 2011 00:54:00 -0800 (PST) Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob117.postini.com ([74.125.148.12]) with SMTP ID DSNKTsIonRtftlk+mRetp5B1ggAelC2ThvOb@postini.com; Tue, 15 Nov 2011 00:54:01 PST 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.192.1; Tue, 15 Nov 2011 09:49:48 +0100 Received: from MOPESMBX01.eu.thmulti.com ([141.11.100.105]) by MOPESMAILHC02.eu.thmulti.com ([141.11.100.29]) with mapi; Tue, 15 Nov 2011 09:49:51 +0100 From: Wuyts Carl To: "Hemant Singh (shemant)" , "v6ops@ietf.org" Date: Tue, 15 Nov 2011 09:49:48 +0100 Thread-Topic: [v6ops] RFC6204bis-02 Thread-Index: AcyewOvBbq1YdOdiSD66Sp1uaN6CQwCSeq2gAGv1BCAAHHv0MAANyK5QAAHgk2AAADFEcAABKvkAAABIDxAAAFiyMAAAFAkw Message-ID: <867F4B6A1672E541A94676D556793ACD0C275166C3@MOPESMBX01.eu.thmulti.com> References: <867F4B6A1672E541A94676D556793ACD0C263BCDD7@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303494A91@XMB-RCD-109.cisco.com> <867F4B6A1672E541A94676D556793ACD0C27516363@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303494F74@XMB-RCD-109.cisco.com> <867F4B6A1672E541A94676D556793ACD0C27516655@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303494FE3@XMB-RCD-109.cisco.com> <867F4B6A1672E541A94676D556793ACD0C27516671@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303494FE5@XMB-RCD-109.cisco.com> <867F4B6A1672E541A94676D556793ACD0C275166AC@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303494FE8@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C303494FE8@XMB-RCD-109.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/related; boundary="_006_867F4B6A1672E541A94676D556793ACD0C275166C3MOPESMBX01eut_"; type="multipart/alternative" MIME-Version: 1.0 Cc: "Lee, Yiu" Subject: Re: [v6ops] RFC6204bis-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, 15 Nov 2011 08:54:04 -0000 --_006_867F4B6A1672E541A94676D556793ACD0C275166C3MOPESMBX01eut_ Content-Type: multipart/alternative; boundary="_000_867F4B6A1672E541A94676D556793ACD0C275166C3MOPESMBX01eut_" --_000_867F4B6A1672E541A94676D556793ACD0C275166C3MOPESMBX01eut_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thank you, much appreciated Carl Wuyts GCD System Architect Networking Connect Division carl.wuyts@technicolor.com tel.: +32 3 443 65 90 [cid:image001.gif@01CCA37B.E9B9BAF0] [cid:image002.gif@01CCA37B.E9B9BAF0] Prins Boudewijnlaan 47 - 2650 Edegem - Belgium Technicolor Delivery Technologies Belgium NV Registered office (maatschappelijke zetel): Prins Boudewijnlaan 47, 2650 Ed= egem, Belgium Company registration number (ondernemingsnummer): 0428837295 - RPR Antwerpe= n [cid:image003.gif@01CCA37B.E9B9BAF0] Help preserve the color of our world - Think before you print. From: Hemant Singh (shemant) [mailto:shemant@cisco.com] Sent: dinsdag 15 november 2011 9:49 To: Wuyts Carl; v6ops@ietf.org Cc: Lee, Yiu Subject: RE: [v6ops] RFC6204bis-02 One author (cced in this email) of the DS-Lite RFC was agreeable to this bu= llet. I will ask him if he is OK with changing the MUST to a SHOULD and t= hen we can consider the change. Thanks, Hemant From: Wuyts Carl [mailto:Carl.Wuyts@technicolor.com] Sent: Tuesday, November 15, 2011 4:41 PM To: Hemant Singh (shemant); v6ops@ietf.org Subject: RE: [v6ops] RFC6204bis-02 Ok, just want to make sure, as RFC6204 gets lots of interests lately in CPE= area (but also e.g. @ RIPE), to not miss out on anything here. The RFC6204bis says, quoted form it: "" If the IPv6 CE Router is configured with a public IPv4 address on its WAN interface, where public IPv4 address is defined as any address which is not in the private IP address space specified in [RFC5735]= and also not in the reserved IP address space specified in [RFC6333], then the IPv6 CE Router MUST disable the DS-Lite B4 element. "" MUST, so imho, the MUST should be replaced with MAY (or maybe SHOULD). --_000_867F4B6A1672E541A94676D556793ACD0C275166C3MOPESMBX01eut_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thank you, much appreciated

 

<= td valign=3Dtop style=3D'padding:1.5pt 0cm 1.5pt 0cm'>

Carl Wuyts

GCD System Architect Networking=

Connec= t Division

carl.wuyts@technicolor.com

tel.: +32 3 443 65 = 90

3Dt=

3D"Visit<= /span>

Prins Boudewijnlaan 47  -  2650 Edegem  -&nb= sp; Belgium

Technicolor Delivery Technologies= Belgium NV

Registered office (maatschappelijke zetel= ): Prins Boudewijnlaan 47, 2650 Edegem, Belgium

Company registration number (ondernemingsnummer):= 0428837295 - RPR Antwerpen

3DEco

Help prese= rve the color of our world - Think before you print.<= /p>

 

 

From: Hemant Singh (shemant) [mailto:shemant@c= isco.com]
Sent: dinsdag 15 november 2011 9:49
To: Wuyt= s Carl; v6ops@ietf.org
Cc: Lee, Yiu
Subject: RE: [v6ops= ] RFC6204bis-02

=  

One auth= or (cced in this email) of the DS-Lite RFC was agreeable to this bullet.&nb= sp;  I will ask him if he is OK with changing the MUST to a SHOULD and= then we can consider the change.

 

Thanks,

 

Hemant

 

From: Wuyts Carl [mailto:Carl.Wuyts@technicolor.com]
Sent:<= /b> Tuesday, November 15, 2011 4:41 PM
To: Hemant Singh (shemant)= ; v6ops@ietf.org
Subject: R= E: [v6ops] RFC6204bis-02

 

Ok, just want to make sure, as RFC6204 gets lots of interests lately in CP= E area (but also e.g. @ RIPE), to not miss out on anything here.=

The RFC6204bi= s says, quoted form it:

“”

If the IPv6 CE Router is configured with a = public IPv4

           addres= s on its WAN interface, where public IPv4 address is

<= p class=3DMsoNormal style=3D'page-break-before:always'>    &n= bsp;      defined as any address which is not in t= he private IP address

         &nb= sp; space specified in [RFC5735] and also not in t= he reserved IP

           add= ress space specified in [RFC6333], then the IPv6 CE Router

     &n= bsp;     MUST disable the DS-Lite B4 element.

“̶= 1;

=  

MUST, so imho, the MUST should be replaced with MAY (or maybe SHOULD).<= o:p>

 

= --_000_867F4B6A1672E541A94676D556793ACD0C275166C3MOPESMBX01eut_-- --_006_867F4B6A1672E541A94676D556793ACD0C275166C3MOPESMBX01eut_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=1351; creation-date="Tue, 15 Nov 2011 08:49:49 GMT"; modification-date="Tue, 15 Nov 2011 08:49:49 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhGAAYAPcAAAAAAP///1Sfum/L64bW8o7h/ofU74fT7pHb9pfa8u75/VbD5VzG6FvF5l3G 513F5l/G51/F5mHH52PH6GPI6GPI52TH6GXJ6GbI6GnK6mjJ6WjK6WzL6m/M63HN6nPN6nTN63fR 7XnR7XTI5FeVqnnN537T7n7R7H/T7X3O6Y3f+4jV73m903/E2oDE2pTf+ZPc9JTa8Zfa8aDd8LDj 9MXr9+z5/er3+/r9/imy1yyx1S202S2z1zK43TW63jW32zS22Ta53Te73za32zq84Dm53Du73j2/ 4j2+4T283z273kHB5D++4EHA4kG/4UPA40K/4UTB5EbD5UbB40rJ7EjD5ErG6EnE5knE5Ua720rE 5kvG507J607I6U3G50/K60u+3U2/4U7A4k2/3lLI6E/A31XN7lHC4VnP8FfL61PD4lXD5FXF41vR 8VfG5VO92lrJ51a+21i/21/O7F7L6VnB3VzE4mHN6l/H5V3D30+lvWDH41/E4GDF4WLH42rL6GvP 6l+2znLZ9W7Q62C1zGO50HXZ9HTY83ba9XXX8mW70nLO6nHN6We803rd+HXV73zf+mm91HXS62vA 12GpvWavw2ixxVmWp2qxxYDW7X3Q52yzxm+2yW60x4HS6HC2yXG3ynzD2I7a75Xb7pvh9F+HkqTg 8ajg76ff7qri8bPo97fm9Ljm9MXw/Mfw/NDz/dDx+tbx+dz0++H1++f5/uv5/Six1S+22jG01zK1 2EXD5E/M7U7H50yvyWPY91zJ5WjZ92za927b+HHY82G4z3Xd+FurwHXa9Xfc93ne+F+rv37h+2u/ 1YDi/H7c9YHh+YLh+YXi+mqyxWuzxork+ovj+o3l+3K4ypXn+12PnJrm+qXp+63j8cLx/M/0/ef4 /Jfp+57q+6Xt/Kjv/avv/a3v/a7w/bPw/bzz/uP6/+z7/vP9/7fz/r30/sD0/sX1/sn2/tT4/9L2 /d/6/+X7/+b7/+r8/+v7/sz3/tr5/ub8/+39//v///3///7//////yH5BAEAAP8ALAAAAAAYABgA AAj/AP8JHEiwoMGCAgggOGCg4YqHEB8aOPCCAEESKmR84MABg0cOHUKGHDCAA4gEBQaOiIHBwgQO pmrQEEEhg80NGnJewACDhcAUJyBMwBArgL8ACkxc2MBUg8cLEEy0+PkhQoMZAerNmxegBoMLFChc AFsBQggXAkswerBgVYB8+eLtu7GorgcKDipIcBBi6r8SHtiyCoAPH7x6AXAoxjELRYO9IUIJlGMn jBi37zLHo2fPXj19/hT8WRMGDzGBb7LosIUqADp07WC7c9eOHbwAmnjwGBNIYBwwuHK0NleOOLnj 5MaxC+BpR64zp//JGQNkx6kA4rKXO8ede7oAe378/1BTSGCdMkNunfIXLhw4eQH6yU88KoiSImzK /8tzpkiPVP1gg4013gRgYGKmEMEEE0a4oYhAeahhhA/c8FMNNdF0s4466tyzTgCrOAFFEnA0IhAf bCQhhCkBVPMMNDDC+GI3AUiCBBNwRCJQH24wgUQmAWwjTDJEFllMNAGIcoQTdDAjkB9uODGFFLHw o00wwGSZpS/bBJDJEk80+eQvTVQhxR2zBECLK6202c0rAchCxhVR3DGJb5I0gYUXVqRBCiy1BFqL Dd+oMocVW+jyCCEC6ZEIIFps0cUXVOyCRhuYomEGFVx0wcsghlwyUC/DOHPIMcg4AskyzbS6DCSO ICSDiDOCGFNQNspUYgkmm3TCCSjXgPJJJ9NIYwklpRyk7LIDBQQAOw== --_006_867F4B6A1672E541A94676D556793ACD0C275166C3MOPESMBX01eut_ Content-Type: image/gif; name="image002.gif" Content-Description: image002.gif Content-Disposition: inline; filename="image002.gif"; size=1834; creation-date="Tue, 15 Nov 2011 08:49:49 GMT"; modification-date="Tue, 15 Nov 2011 08:49:49 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhcgBFAOZ/AEGueqipqmgxkACLS4ORyPb294DFpZrMVqvi+sXr2Ie3laLXtnRHnLQlZO3J 2M+pxP7pJvqtgePqmqOIvYLKnACP1fewoXa65/vCov71sdqRnc6OpPvrlcU/benvs7qmzpzR8P/n rc7imtLntMkhU/V7Hf/yl+fZ6f3HipjL7b+MraKs1h+WXIrU9fNrPv/dkaTIrpQpd/JlIr8kXv/o ALa3uO0bLwCmUQC68pKSlf/CDgxNosvbKtvb3IzGP8nJyoiJjPaWgH+Ag3Z3euTk5Y3Y+MTfm+3t 7r/AwZubnvBSJQCZ3NLS0//eAwN+yE84la9fmdjkX//RSiPB855BhP/ILiCvY9HeRvLkCvmykSld q/aNl4Dd+cPT6O85Q2m+Q6zRONnM5OPx0PR3OR2Z2eOttkCr4Lfbm//uQPWMWbeLscPbysbs/OP1 /ZeLwPaLN9blff/iEvXlByCi3nzB69eqvN7r4uzysHfDWSCKzu+Uh8R4pR6j4IVfqm1ucf///yH5 BAEAAH8ALAAAAAByAEUAAAf/gH+Cg4SFhoeIiYqLjI2Oj5CRkpOUlZaXmJmam5ydnp+goaKjpKWm p6ipqqusra6vsLGys7S1tqF+Oat+freMubu9vorAkkhIlryqBQWXxZBEvD2VyqhEQtPJupJJScnC pzV+2dTbqdWnSX4BNTWDR+01RIUFSO0/zX/AP+1Mg/x/iLRDku9PO0JH7NXA906hv0Ho/vSId2TQ xB4Jf1gKwKujoB8deWn8OCTkkIp+gAAJGUBQjnUhgUAEB9Lkx5C58lUr8DLkSHE5Spqb1IMjkh7T evgZ4o9JyYrR/Mib2FKfHyH4kPBq1rPGkR4lH1ZjsvQH0gDIlA7RSGSlN6uC/zgCmfcjrEFeQuRd EkeO48g/IN2pQ2boasGV014+/MPRHdw/QsYZUve3wFO4R5YWBOlN3FtMfAetBJKj9EpdEQk9+/My sWRB4hxXS3koNcdpypRWnXnXMejXf4SWHt4yNcShrVkDjy1o9lDehELnXldIGfNMoV0CJxSZnGrk kpPDltpc2FZDK+eJlqwsmsx3V3trEvdXK5CKgvKJu59fLHjX5FxXjVz5fHUXEPmAJER5gkQ2UgHq uHMdJiANkcNIK+WSQ2TraaiZPv8pFyB5jxWwkoUvLWjiVUlkmE01RJQERACRISifJhxR90cBNUTG YkE1ZAgEYTnsxlgO8wSA5P8/F7pkDo8+AvFgj7wkoR5r5hChzlU1JNjkMGCGKeaYZJZp5pmqsIHA mmyCkMKbcK4g55wrfGDnnR88oOeedZTh558WBCqoBRgUaigGISSqaAgZNOroHR5EKqkHI1Rq6QKY ZroADJx2CoMdjxSAQBGkktoCHRekqioBrLZKgBsTxCqrGirUaqsGuOaqgR5B9OprBMAGG8ELxBb7 ggnIJmuCBMw2K4EIRkQb7RkUVGstBQpkq60CazTSRqmlnqrqqq6yCqusstqqrq65+uqusMGiYCyx HCiLLAfONguttEZQe22122oLQ0GHsAGuqeOSW+656E6grq0bsIuru7/CG4H/vPMea++y+TK7r7T+ /huwtqAiMsXJKE/BBxkst5yHFjDHrAUDNNdMMxU450xFBzz3zLMXQAfthQtjFG30G1UkrXQVEDTt dNNXRC31FWAcYPXVeFih9dZWsOD11ywAkAgOZJeNwxIVpK22Ezu07fYOTwgg99wCxGD33TE0MMPe fJNgw9+A26CEDIQXXoIOiCeuQxM0NO44FjxELjkPYPhg+eVf3KD55jcM4PnnA4iNiNllo6122my/ 3XbcdMuN9916872334H/PXjhhB+uOOKMO9445JNHXvnllmfOueagfy76IaSTbfrpqavOeuuv2x27 7LTXfjvuuu/eu+/ABz88//HGH5+858sb0vzZp6Ou+uqtu1799X3Xbjvuue/Ou++/By888cU7HvLO l75CrO95a3sf3OJXt/nJbnb2Exz+ZNA9xX3vcf6jHAB9UD7OnS90Y2seAt33vunRrXp5e+AMshe4 7RlOf4vjHw3CN7nxYU6AnSNgCEk3wgpE720mnBsK6QdB+7kwf/q7YP/8BwcxOPGJC8DhBwtIiAO2 z4cKDKL8XkfEFUbwiBSEoRJpIIcomPGMUbiDIRIgRR2OToRXrEAX5kjHLvSBgUNUIQsBB8YSSOGP gJRCHGRIA0ewUYBTTAQXFslILswhjoe4Y/zy+EASbOGSmNyCCyYog0OggYeQhgSAKEcJABa40RFm gKQhThCGVrryAZR84CHSwElPgrISADhlI1J5RUc4IJaym2UtSZHL5FFREbxsny9RuAcHOPOZDjgE BrJAzWpmoRQLMIA2t7kASCTzdI44ARTGSU4oPABN6EynOtfJzna6853wjKc850nPetrznvjMpz73 yc9++tMUgQAAOw== --_006_867F4B6A1672E541A94676D556793ACD0C275166C3MOPESMBX01eut_ Content-Type: image/gif; name="image003.gif" Content-Description: image003.gif Content-Disposition: inline; filename="image003.gif"; size=493; creation-date="Tue, 15 Nov 2011 08:49:49 GMT"; modification-date="Tue, 15 Nov 2011 08:49:49 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhHAAhAMQAALHNVVqXGZu+IqbFNv79/ury0pK4H2SdaJzAJNjlq/3++vL34srdiSl5Mfj7 8OHrvDmDE5u+Kb3VbtDgm5jCnJC2IqDBJHqqHoazHsfYxcfco+/58f7///7+/v///f///yH5BAAA AAAALAAAAAAcACEAAAX/4CeOZGmeaKqubOumXSfKL0rT9RiTe65/nl0vxxE1KB3Ph6b8KGYjT/Pn ORwIHmy0FEQFCZRG5yldJnEqD6ezaWQIHMJDApAwCthgF8hbEqwEBQARAoWFEgskQWgiChwFDRoD hpQCA3hLQGhxSWABFpQIlAMPT2NoeTIJEBigooavlzJDS0UdHAkBEAivAoSjDklTQAROuBYQn7+/ lBJJS01SUgoJoskWvaECCWUiHEEKtw+8BtegvoWxiYtqSmsLhBblEALn2hLDH3HTAIXYuhfqVeLF TZ8SR3oSULKAQVeAChYi8kJwCUg4BcVkOOiXDgHDACAvXMBQoWQEOw6iahwsMCmdAI8CKoiciUEA gAJ8aBC4xfKlz3QRsVGcoICMJidKOjhgMKCXqKcAJqSMIkwEuw8OHjCQwNVOggJPvqm4ZUJGuw47 lajlA0Sat28xyJZV9APasGEcvknBkU9TjJ1WrTZZE9hHihAAOw== --_006_867F4B6A1672E541A94676D556793ACD0C275166C3MOPESMBX01eut_-- From Francis.Dupont@fdupont.fr Tue Nov 15 00:55:58 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1229D21F9010 for ; Tue, 15 Nov 2011 00:55:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, 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 y7uBh4dQuXko for ; Tue, 15 Nov 2011 00:55:57 -0800 (PST) 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 5317321F9009 for ; Tue, 15 Nov 2011 00:55:57 -0800 (PST) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id pAF8teRU051375; Tue, 15 Nov 2011 09:55:40 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201111150855.pAF8teRU051375@givry.fdupont.fr> From: Francis Dupont To: Mark Townsley In-reply-to: Your message of Tue, 15 Nov 2011 16:45:54 +0800. Date: Tue, 15 Nov 2011 09:55:40 +0100 Sender: Francis.Dupont@fdupont.fr Cc: Alexandre Cassen , "v6ops@ietf.org WG" , Claire Cheng Subject: Re: [v6ops] 6rd Sunsetting X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 Nov 2011 08:55:58 -0000 In your previous mail you wrote: Both methods described in the document are incremental, one requiring renumbering and the associated (general) issues with that, the other not. In either case, you will have 6rd and native at the same time in the network as you move subscribers over time. => I am a bit subscriber oriented (perhaps because I am myself a 6rd user) so I read the question about use case as can a subscriber be provided with both 6rd and native IPv6 service at the same time by an ISP? and IMHO the answer is in general no. Regards Francis.Dupont@fdupont.fr PS: do you have contacts at Illiad/Free to apply one of your methods? (of course I'd prefer the not renumbering one) From mark@townsley.net Tue Nov 15 01:11:38 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1202D11E808B for ; Tue, 15 Nov 2011 01:11:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 Ip2sVFsdbSaQ for ; Tue, 15 Nov 2011 01:11:37 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 474DA11E808F for ; Tue, 15 Nov 2011 01:11:37 -0800 (PST) Received: by ggnr5 with SMTP id r5so2224814ggn.31 for ; Tue, 15 Nov 2011 01:11:37 -0800 (PST) Received: by 10.68.13.103 with SMTP id g7mr789199pbc.59.1321348296522; Tue, 15 Nov 2011 01:11:36 -0800 (PST) Received: from dhcp-13d7.meeting.ietf.org (64-104-46-217.cisco.com. [64.104.46.217]) by mx.google.com with ESMTPS id f1sm55239609pba.7.2011.11.15.01.11.32 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 15 Nov 2011 01:11:34 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: <201111150855.pAF8teRU051375@givry.fdupont.fr> Date: Tue, 15 Nov 2011 17:11:28 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <584DFDD4-D356-4ACB-8582-4A195B36D5A4@townsley.net> References: <201111150855.pAF8teRU051375@givry.fdupont.fr> To: Francis Dupont X-Mailer: Apple Mail (2.1084) Cc: Alexandre Cassen , "v6ops@ietf.org WG" , Claire Cheng Subject: Re: [v6ops] 6rd Sunsetting X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 Nov 2011 09:11:38 -0000 On Nov 15, 2011, at 4:55 PM, Francis Dupont wrote: > In your previous mail you wrote: >=20 > Both methods described in the document are incremental, one = requiring > renumbering and the associated (general) issues with that, the other > not. In either case, you will have 6rd and native at the same time = in > the network as you move subscribers over time. >=20 > =3D> I am a bit subscriber oriented (perhaps because I am myself > a 6rd user) so I read the question about use case as can a subscriber > be provided with both 6rd and native IPv6 service at the same time > by an ISP? and IMHO the answer is in general no. For the simple singlehomed user, the user should either notice nothing = at all when being transitioned from 6rd to native ("seamless" mode = described in the draft) or witness a renumbering. The service to the = end-user before and after should be essentially the same. For multihoming, I don't know why we would limit 6rd and native to two = separate ISPs any more than we would limit two native connections to two = ISPs. It's clearly not the common case, but inasmuch as multihomed CPEs = exist, one could be native and the other 6rd. - Mark >=20 > Regards >=20 > Francis.Dupont@fdupont.fr >=20 > PS: do you have contacts at Illiad/Free to apply one of your methods? > (of course I'd prefer the not renumbering one) From brian.e.carpenter@gmail.com Tue Nov 15 01:13:44 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 065F321F8F4E for ; Tue, 15 Nov 2011 01:13:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.972 X-Spam-Level: X-Spam-Status: No, score=-102.972 tagged_above=-999 required=5 tests=[AWL=-0.573, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=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 V9BcPXTUl0zi for ; Tue, 15 Nov 2011 01:13:42 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA851F0C3F for ; Tue, 15 Nov 2011 01:13:42 -0800 (PST) Received: by ywt34 with SMTP id 34so5989358ywt.31 for ; Tue, 15 Nov 2011 01:13:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=j8zgciU5oE5te2f+hoTXZpZ7XKZVfFxBIudRf0g21pw=; b=HyBRXhbmx6UwVfEUK4Uf7hKaGQJ6LW7eRrSqtZ0nkdRhI93PWCvfcK5dIwFRSYn4+w +810sFn7CteozOZG4ZEhjboEXUOvMcnIsKx6AWSMZGWGMN/seAbs0loMfF3ONlI3H6Hl qRTlMTs/adn7FDoUnxpw4poY2Ky897sGOz4Hc= Received: by 10.101.148.29 with SMTP id a29mr7588392ano.21.1321348421733; Tue, 15 Nov 2011 01:13:41 -0800 (PST) Received: from [130.129.19.92] (dhcp-135c.meeting.ietf.org. [130.129.19.92]) by mx.google.com with ESMTPS id 32sm71431785anu.10.2011.11.15.01.13.37 (version=SSLv3 cipher=OTHER); Tue, 15 Nov 2011 01:13:40 -0800 (PST) Message-ID: <4EC22D3D.9060801@gmail.com> Date: Tue, 15 Nov 2011 22:13:33 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mark Townsley References: <1F0FCAA1-EE6D-4B20-8F1F-7F985F97493A@townsley.net> In-Reply-To: <1F0FCAA1-EE6D-4B20-8F1F-7F985F97493A@townsley.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Alexandre Cassen , "v6ops@ietf.org WG" , Claire Cheng Subject: Re: [v6ops] 6rd Sunsetting X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 Nov 2011 09:13:44 -0000 Mark, I will read the draft when a calm moment arrives. But I have to ask, what is its relationship to RFC 6264? That already includes 6rd as one option in the path to v6ness. Regards Brian On 2011-11-15 21:46, Mark Townsley wrote: > On Nov 15, 2011, at 4:17 PM, Hans Liu wrote: > >> Excuse me Mark, I still don't have an idea in what kind of use case >> should we have 6rd and Native Dual Stack at the same time in the >> network? > > Incremental transition from 6rd to native. > > - Mark > >> Regards, >> Hans >> >> On Tue, Nov 15, 2011 at 4:01 PM, Mark Townsley wrote: >>> Alexandre and I just finished up a -00 that describes two methods for moving >>> a 6rd deployment to native IPv6. Apologies for not getting this out before >>> the meeting. >>> http://www.ietf.org/id/draft-townsley-v6ops-6rd-sunsetting-00.txt >>> >>> Abstract >>> >>> This document provides guidelines for transitioning an IPv6 >>> deployment using IPv6 Rapid Deployment (6rd) to an IPv6 deployment >>> using Native IPv6. It is targeted at both 6rd operators and 6rd >>> implementors." >>> >>> - Mark >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> >>> >> >> >> -- >> Instead of following the fashion, we lead it through. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From randy@psg.com Tue Nov 15 01:16:44 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A37F61F0C3F for ; Tue, 15 Nov 2011 01:16:44 -0800 (PST) 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 4hnwUOq2Fznk for ; Tue, 15 Nov 2011 01:16:44 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 4496C1F0C3C for ; Tue, 15 Nov 2011 01:16:44 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RQF8A-0004S0-Jh; Tue, 15 Nov 2011 09:16:38 +0000 Date: Tue, 15 Nov 2011 17:16:36 +0800 Message-ID: From: Randy Bush To: Mark Townsley In-Reply-To: <584DFDD4-D356-4ACB-8582-4A195B36D5A4@townsley.net> References: <201111150855.pAF8teRU051375@givry.fdupont.fr> <584DFDD4-D356-4ACB-8582-4A195B36D5A4@townsley.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: Alexandre Cassen , "v6ops@ietf.org WG" , Claire Cheng Subject: Re: [v6ops] 6rd Sunsetting X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 Nov 2011 09:16:44 -0000 i want cgn sunsetting. or how about ds-lite eclipse? From mark@townsley.net Tue Nov 15 01:37:27 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3CB911E819E for ; Tue, 15 Nov 2011 01:37:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.924 X-Spam-Level: X-Spam-Status: No, score=-2.924 tagged_above=-999 required=5 tests=[AWL=-0.525, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=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 xcu6AERV4auQ for ; Tue, 15 Nov 2011 01:37:26 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 72E7211E8113 for ; Tue, 15 Nov 2011 01:37:26 -0800 (PST) Received: by ywt34 with SMTP id 34so6014410ywt.31 for ; Tue, 15 Nov 2011 01:37:26 -0800 (PST) Received: by 10.101.179.35 with SMTP id g35mr1765426anp.82.1321349845961; Tue, 15 Nov 2011 01:37:25 -0800 (PST) Received: from ?IPv6:2001:df8::16:226:bbff:fe1a:79b4? ([2001:df8:0:16:226:bbff:fe1a:79b4]) by mx.google.com with ESMTPS id y1sm25247028anj.18.2011.11.15.01.37.23 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 15 Nov 2011 01:37:25 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: <4EC22D3D.9060801@gmail.com> Date: Tue, 15 Nov 2011 17:37:20 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7CABAB61-E3D3-4C68-91BA-621A5CA0DE51@townsley.net> References: <1F0FCAA1-EE6D-4B20-8F1F-7F985F97493A@townsley.net> <4EC22D3D.9060801@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1084) Cc: Alexandre Cassen , "v6ops@ietf.org WG" , Claire Cheng Subject: Re: [v6ops] 6rd Sunsetting X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 Nov 2011 09:37:27 -0000 On Nov 15, 2011, at 5:13 PM, Brian E Carpenter wrote: > Mark, >=20 > I will read the draft when a calm moment arrives. But I have to ask, > what is its relationship to RFC 6264? That already includes 6rd > as one option in the path to v6ness. This is very specific for 6rd to native (no CGN, ds-lite, etc), and, = importantly, includes specific requirements for CPE implementors. = Relevant as 6204-bis has brought 6rd into its scope.=20 I look forward to your review, and whether it is in conflict in anyway = with 6264 in your mind. - Mark >=20 > Regards > Brian >=20 > On 2011-11-15 21:46, Mark Townsley wrote: >> On Nov 15, 2011, at 4:17 PM, Hans Liu wrote: >>=20 >>> Excuse me Mark, I still don't have an idea in what kind of use case >>> should we have 6rd and Native Dual Stack at the same time in the >>> network? >>=20 >> Incremental transition from 6rd to native.=20 >>=20 >> - Mark >>=20 >>> Regards, >>> Hans >>>=20 >>> On Tue, Nov 15, 2011 at 4:01 PM, Mark Townsley = wrote: >>>> Alexandre and I just finished up a -00 that describes two methods = for moving >>>> a 6rd deployment to native IPv6. Apologies for not getting this out = before >>>> the meeting. >>>> http://www.ietf.org/id/draft-townsley-v6ops-6rd-sunsetting-00.txt >>>>=20 >>>> Abstract >>>>=20 >>>> This document provides guidelines for transitioning an IPv6 >>>> deployment using IPv6 Rapid Deployment (6rd) to an IPv6 deployment >>>> using Native IPv6. It is targeted at both 6rd operators and 6rd >>>> implementors." >>>>=20 >>>> - Mark >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>=20 >>>>=20 >>>=20 >>>=20 >>> --=20 >>> Instead of following the fashion, we lead it through. >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 From Carl.Wuyts@technicolor.com Tue Nov 15 03:00:01 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23D4F21F8EE9 for ; Tue, 15 Nov 2011 03:00:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.337 X-Spam-Level: X-Spam-Status: No, score=-4.337 tagged_above=-999 required=5 tests=[AWL=-0.159, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qGR8qXG77Gah for ; Tue, 15 Nov 2011 02:59:58 -0800 (PST) Received: from na3sys009aog116.obsmtp.com (na3sys009aog116.obsmtp.com [74.125.149.240]) by ietfa.amsl.com (Postfix) with ESMTP id 2B10621F8EE7 for ; Tue, 15 Nov 2011 02:59:56 -0800 (PST) Received: from mopesedge02.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob116.postini.com ([74.125.148.12]) with SMTP ID DSNKTsJGKRlYNFrgcxwHsPEFDoQ8uqZ0FzaJ@postini.com; Tue, 15 Nov 2011 02:59:58 PST Received: from MOPESMAILHC03.eu.thmulti.com (141.11.100.132) by mopesedge02.eu.thmulti.com (141.11.253.23) with Microsoft SMTP Server (TLS) id 8.3.192.1; Tue, 15 Nov 2011 11:58:41 +0100 Received: from MOPESMBX01.eu.thmulti.com ([169.254.155.121]) by MOPESMAILHC03.eu.thmulti.com ([141.11.100.132]) with mapi; Tue, 15 Nov 2011 11:58:49 +0100 From: Wuyts Carl To: "Lee, Yiu" , "Hemant Singh (shemant)" Date: Tue, 15 Nov 2011 11:58:47 +0100 Thread-Topic: [v6ops] RFC6204bis-02 Thread-Index: AcyewOvBbq1YdOdiSD66Sp1uaN6CQwCSeq2gAGv1BCAAHHv0MAANyK5QAAHgk2AAADFEcAABKvkAAABIDxAAAFiyMAAEM3K7AAAvTsA= Message-ID: <867F4B6A1672E541A94676D556793ACD0C275167F4@MOPESMBX01.eu.thmulti.com> References: <867F4B6A1672E541A94676D556793ACD0C263BCDD7@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303494A91@XMB-RCD-109.cisco.com> <867F4B6A1672E541A94676D556793ACD0C27516363@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303494F74@XMB-RCD-109.cisco.com> <867F4B6A1672E541A94676D556793ACD0C27516655@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303494FE3@XMB-RCD-109.cisco.com> <867F4B6A1672E541A94676D556793ACD0C27516671@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303494FE5@XMB-RCD-109.cisco.com> <867F4B6A1672E541A94676D556793ACD0C275166AC@MOPESMBX01.eu.thmulti.com>, <5B6B2B64C9FE2A489045EEEADDAFF2C303494FE8@XMB-RCD-109.cisco.com> <2F25DE74-DA72-4B7B-9358-9E1F17BF4DAD@Cable.Comcast.com> In-Reply-To: <2F25DE74-DA72-4B7B-9358-9E1F17BF4DAD@Cable.Comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/related; boundary="_006_867F4B6A1672E541A94676D556793ACD0C275167F4MOPESMBX01eut_"; type="multipart/alternative" MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] RFC6204bis-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, 15 Nov 2011 11:00:01 -0000 --_006_867F4B6A1672E541A94676D556793ACD0C275167F4MOPESMBX01eut_ Content-Type: multipart/alternative; boundary="_000_867F4B6A1672E541A94676D556793ACD0C275167F4MOPESMBX01eut_" --_000_867F4B6A1672E541A94676D556793ACD0C275167F4MOPESMBX01eut_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Well, as I've said before, it's probably unlikely that you're using a DSLit= e together with a public IPv4 address, however, it is possible. Moreover, = I'm speaking as CPE vendor, the CPE should not be in charge of checking for= "public IPv4 presence and based upon that tear up/bring down the DSLite tu= nnel. If the ISP (we're not present in retail) decides on configuring the = CPE with a public IPv4, then he should be aware of his actions and remove e= ither the tunnel or the DHCPv6 option for the tunnel from the configuration= . The only thing I want is to have a common approach for ALL CPEs, not being = enforced to start polling/eventing this, and increase complexity, so I just= want to have this requirement in the RFC6204bis being present as MAY/SHOUL= D i.s.o. MUST. Tx and regs Carl Wuyts GCD System Architect Networking Connect Division carl.wuyts@technicolor.com tel.: +32 3 443 65 90 [cid:image001.gif@01CCA38D.B7435060] [cid:image002.gif@01CCA38D.B7435060] Prins Boudewijnlaan 47 - 2650 Edegem - Belgium Technicolor Delivery Technologies Belgium NV Registered office (maatschappelijke zetel): Prins Boudewijnlaan 47, 2650 Ed= egem, Belgium Company registration number (ondernemingsnummer): 0428837295 - RPR Antwerpe= n [cid:image003.gif@01CCA38D.B7435060] Help preserve the color of our world - Think before you print. From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] Sent: dinsdag 15 november 2011 11:48 To: Hemant Singh (shemant) Cc: Wuyts Carl; v6ops@ietf.org Subject: Re: [v6ops] RFC6204bis-02 Hi, Could anybody please explain a scenario where an IPv4 address was given to = a CPE but still want dslite? I assume the CPE would use the provisioned IPv= 4 address to access IPv4 service. Thanks, Yiu On Nov 15, 2011, at 5:34 AM, "Hemant Singh (shemant)" > wrote: One author (cced in this email) of the DS-Lite RFC was agreeable to this bu= llet. I will ask him if he is OK with changing the MUST to a SHOULD and t= hen we can consider the change. Thanks, Hemant From: Wuyts Carl [mailto:Carl.Wuyts@technicolor.com] Sent: Tuesday, November 15, 2011 4:41 PM To: Hemant Singh (shemant); v6ops@ietf.org Subject: RE: [v6ops] RFC6204bis-02 Ok, just want to make sure, as RFC6204 gets lots of interests lately in CPE= area (but also e.g. @ RIPE), to not miss out on anything here. The RFC6204bis says, quoted form it: "" If the IPv6 CE Router is configured with a public IPv4 address on its WAN interface, where public IPv4 address is defined as any address which is not in the private IP address space specified in [RFC5735]= and also not in the reserved IP address space specified in [RFC6333], then the IPv6 CE Router MUST disable the DS-Lite B4 element. "" MUST, so imho, the MUST should be replaced with MAY (or maybe SHOULD). --_000_867F4B6A1672E541A94676D556793ACD0C275167F4MOPESMBX01eut_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Well, as I’ve said before, it’s p= robably unlikely that you’re using a DSLite together with a public IP= v4 address, however, it is possible.  Moreover, I’m speaking as = CPE vendor, the CPE should not be in charge of checking for “public I= Pv4 presence and based upon that tear up/bring down the DSLite tunnel. = ; If the ISP (we’re not present in retail) decides on configuring the= CPE with a public IPv4, then he should be aware of his actions and remove = either the tunnel or the DHCPv6 option for the tunnel from the configuratio= n.

=  

The only thing I want is to have a common approach for ALL CPEs, not be= ing enforced to start polling/eventing this, and increase complexity, so I = just want to have this requirement in the RFC6204bis being present as MAY/S= HOULD i.s.o. MUST.

 

Tx and regs

<= span style=3D'color:#1F497D'> 

Carl Wuyts

GCD System Architect Networking

Connect Divisio= n

carl.w= uyts@technicolor.com

tel.: +32 3 443 65 90

3Dtwitter

3D"Visit

Prins Bo= udewijnlaan 47  -  2650 Edegem  -  = Belgium

Technicolor Delivery Technologies Belgium = NV

Registered office (maatschappelijke zetel): Prins = Boudewijnlaan 47, 2650 Edegem, Belgium

Company registration number (ondernemingsnummer): 04288372= 95 - RPR Antwerpen

<= /tr>

3DEco

Help preserve the c= olor of our world - Think before you print.

 

 

From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com]
<= b>Sent: dinsdag 15 november 2011 11:48
To: Hemant Singh (shem= ant)
Cc: Wuyts Carl; v6ops@ietf.org
Subject: Re: [v6ops= ] RFC6204bis-02

=  

Hi,

 

Could anybody please explain a scenario where an = IPv4 address was given to a CPE but still want dslite? I assume the CPE wou= ld use the provisioned IPv4 address to access IPv4 service.

<= div>

Thanks,

Yiu


On Nov 15, 2011, at 5:34 AM, "Hemant Singh (sheman= t)" <shemant@cisco.com>= wrote:

One aut= hor (cced in this email) of the DS-Lite RFC was agreeable to this bullet.&n= bsp;  I will ask him if he is OK with changing the MUST to a SHOULD an= d then we can consider the change.

 

Thanks,

 

Hemant

=

 =

From: Wuyts Carl [mailto:Carl.Wuyts@technicolor.com]
Sen= t: Tuesday, November 15, 2011 4:41 PM
To: Hemant Singh (shema= nt); v6ops@ietf.org
Subject: RE: [v6ops] RFC6204bis-02

 

Ok, just want to make sure, as RFC6204 gets lots of interests lately in= CPE area (but also e.g. @ RIPE), to not miss out on anything here.<= o:p>

The RFC620= 4bis says, quoted form it:

“”

If the IPv6 CE Router is configured with= a public IPv4

           add= ress on its WAN interface, where public IPv4 address is

    = ;       defined as any address which is not i= n the private IP address

         =   space specified in [RFC5735] and also not i= n the reserved IP

           = address space specified in [RFC6333], then the IPv6 CE Router

    &nb= sp;      MUST disable the DS-Lite B4 element.

“= ”

 

MUST, so imho, the MUST should be replaced with MAY (or maybe SHOU= LD).

 

= --_000_867F4B6A1672E541A94676D556793ACD0C275167F4MOPESMBX01eut_-- --_006_867F4B6A1672E541A94676D556793ACD0C275167F4MOPESMBX01eut_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=1351; creation-date="Tue, 15 Nov 2011 10:58:48 GMT"; modification-date="Tue, 15 Nov 2011 10:58:48 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhGAAYAPcAAAAAAP///1Sfum/L64bW8o7h/ofU74fT7pHb9pfa8u75/VbD5VzG6FvF5l3G 513F5l/G51/F5mHH52PH6GPI6GPI52TH6GXJ6GbI6GnK6mjJ6WjK6WzL6m/M63HN6nPN6nTN63fR 7XnR7XTI5FeVqnnN537T7n7R7H/T7X3O6Y3f+4jV73m903/E2oDE2pTf+ZPc9JTa8Zfa8aDd8LDj 9MXr9+z5/er3+/r9/imy1yyx1S202S2z1zK43TW63jW32zS22Ta53Te73za32zq84Dm53Du73j2/ 4j2+4T283z273kHB5D++4EHA4kG/4UPA40K/4UTB5EbD5UbB40rJ7EjD5ErG6EnE5knE5Ua720rE 5kvG507J607I6U3G50/K60u+3U2/4U7A4k2/3lLI6E/A31XN7lHC4VnP8FfL61PD4lXD5FXF41vR 8VfG5VO92lrJ51a+21i/21/O7F7L6VnB3VzE4mHN6l/H5V3D30+lvWDH41/E4GDF4WLH42rL6GvP 6l+2znLZ9W7Q62C1zGO50HXZ9HTY83ba9XXX8mW70nLO6nHN6We803rd+HXV73zf+mm91HXS62vA 12GpvWavw2ixxVmWp2qxxYDW7X3Q52yzxm+2yW60x4HS6HC2yXG3ynzD2I7a75Xb7pvh9F+HkqTg 8ajg76ff7qri8bPo97fm9Ljm9MXw/Mfw/NDz/dDx+tbx+dz0++H1++f5/uv5/Six1S+22jG01zK1 2EXD5E/M7U7H50yvyWPY91zJ5WjZ92za927b+HHY82G4z3Xd+FurwHXa9Xfc93ne+F+rv37h+2u/ 1YDi/H7c9YHh+YLh+YXi+mqyxWuzxork+ovj+o3l+3K4ypXn+12PnJrm+qXp+63j8cLx/M/0/ef4 /Jfp+57q+6Xt/Kjv/avv/a3v/a7w/bPw/bzz/uP6/+z7/vP9/7fz/r30/sD0/sX1/sn2/tT4/9L2 /d/6/+X7/+b7/+r8/+v7/sz3/tr5/ub8/+39//v///3///7//////yH5BAEAAP8ALAAAAAAYABgA AAj/AP8JHEiwoMGCAgggOGCg4YqHEB8aOPCCAEESKmR84MABg0cOHUKGHDCAA4gEBQaOiIHBwgQO pmrQEEEhg80NGnJewACDhcAUJyBMwBArgL8ACkxc2MBUg8cLEEy0+PkhQoMZAerNmxegBoMLFChc AFsBQggXAkswerBgVYB8+eLtu7GorgcKDipIcBBi6r8SHtiyCoAPH7x6AXAoxjELRYO9IUIJlGMn jBi37zLHo2fPXj19/hT8WRMGDzGBb7LosIUqADp07WC7c9eOHbwAmnjwGBNIYBwwuHK0NleOOLnj 5MaxC+BpR64zp//JGQNkx6kA4rKXO8ede7oAe378/1BTSGCdMkNunfIXLhw4eQH6yU88KoiSImzK /8tzpkiPVP1gg4013gRgYGKmEMEEE0a4oYhAeahhhA/c8FMNNdF0s4466tyzTgCrOAFFEnA0IhAf bCQhhCkBVPMMNDDC+GI3AUiCBBNwRCJQH24wgUQmAWwjTDJEFllMNAGIcoQTdDAjkB9uODGFFLHw o00wwGSZpS/bBJDJEk80+eQvTVQhxR2zBECLK6202c0rAchCxhVR3DGJb5I0gYUXVqRBCiy1BFqL Dd+oMocVW+jyCCEC6ZEIIFps0cUXVOyCRhuYomEGFVx0wcsghlwyUC/DOHPIMcg4AskyzbS6DCSO ICSDiDOCGFNQNspUYgkmm3TCCSjXgPJJJ9NIYwklpRyk7LIDBQQAOw== --_006_867F4B6A1672E541A94676D556793ACD0C275167F4MOPESMBX01eut_ Content-Type: image/gif; name="image002.gif" Content-Description: image002.gif Content-Disposition: inline; filename="image002.gif"; size=1834; creation-date="Tue, 15 Nov 2011 10:58:48 GMT"; modification-date="Tue, 15 Nov 2011 10:58:48 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhcgBFAOZ/AEGueqipqmgxkACLS4ORyPb294DFpZrMVqvi+sXr2Ie3laLXtnRHnLQlZO3J 2M+pxP7pJvqtgePqmqOIvYLKnACP1fewoXa65/vCov71sdqRnc6OpPvrlcU/benvs7qmzpzR8P/n rc7imtLntMkhU/V7Hf/yl+fZ6f3HipjL7b+MraKs1h+WXIrU9fNrPv/dkaTIrpQpd/JlIr8kXv/o ALa3uO0bLwCmUQC68pKSlf/CDgxNosvbKtvb3IzGP8nJyoiJjPaWgH+Ag3Z3euTk5Y3Y+MTfm+3t 7r/AwZubnvBSJQCZ3NLS0//eAwN+yE84la9fmdjkX//RSiPB855BhP/ILiCvY9HeRvLkCvmykSld q/aNl4Dd+cPT6O85Q2m+Q6zRONnM5OPx0PR3OR2Z2eOttkCr4Lfbm//uQPWMWbeLscPbysbs/OP1 /ZeLwPaLN9blff/iEvXlByCi3nzB69eqvN7r4uzysHfDWSCKzu+Uh8R4pR6j4IVfqm1ucf///yH5 BAEAAH8ALAAAAAByAEUAAAf/gH+Cg4SFhoeIiYqLjI2Oj5CRkpOUlZaXmJmam5ydnp+goaKjpKWm p6ipqqusra6vsLGys7S1tqF+Oat+freMubu9vorAkkhIlryqBQWXxZBEvD2VyqhEQtPJupJJScnC pzV+2dTbqdWnSX4BNTWDR+01RIUFSO0/zX/AP+1Mg/x/iLRDku9PO0JH7NXA906hv0Ho/vSId2TQ xB4Jf1gKwKujoB8deWn8OCTkkIp+gAAJGUBQjnUhgUAEB9Lkx5C58lUr8DLkSHE5Spqb1IMjkh7T evgZ4o9JyYrR/Mib2FKfHyH4kPBq1rPGkR4lH1ZjsvQH0gDIlA7RSGSlN6uC/zgCmfcjrEFeQuRd EkeO48g/IN2pQ2boasGV014+/MPRHdw/QsYZUve3wFO4R5YWBOlN3FtMfAetBJKj9EpdEQk9+/My sWRB4hxXS3koNcdpypRWnXnXMejXf4SWHt4yNcShrVkDjy1o9lDehELnXldIGfNMoV0CJxSZnGrk kpPDltpc2FZDK+eJlqwsmsx3V3trEvdXK5CKgvKJu59fLHjX5FxXjVz5fHUXEPmAJER5gkQ2UgHq uHMdJiANkcNIK+WSQ2TraaiZPv8pFyB5jxWwkoUvLWjiVUlkmE01RJQERACRISifJhxR90cBNUTG YkE1ZAgEYTnsxlgO8wSA5P8/F7pkDo8+AvFgj7wkoR5r5hChzlU1JNjkMGCGKeaYZJZp5pmqsIHA mmyCkMKbcK4g55wrfGDnnR88oOeedZTh558WBCqoBRgUaigGISSqaAgZNOroHR5EKqkHI1Rq6QKY ZroADJx2CoMdjxSAQBGkktoCHRekqioBrLZKgBsTxCqrGirUaqsGuOaqgR5B9OprBMAGG8ELxBb7 ggnIJmuCBMw2K4EIRkQb7RkUVGstBQpkq60CazTSRqmlnqrqqq6yCqusstqqrq65+uqusMGiYCyx HCiLLAfONguttEZQe22122oLQ0GHsAGuqeOSW+656E6grq0bsIuru7/CG4H/vPMea++y+TK7r7T+ /huwtqAiMsXJKE/BBxkst5yHFjDHrAUDNNdMMxU450xFBzz3zLMXQAfthQtjFG30G1UkrXQVEDTt dNNXRC31FWAcYPXVeFih9dZWsOD11ywAkAgOZJeNwxIVpK22Ezu07fYOTwgg99wCxGD33TE0MMPe fJNgw9+A26CEDIQXXoIOiCeuQxM0NO44FjxELjkPYPhg+eVf3KD55jcM4PnnA4iNiNllo6122my/ 3XbcdMuN9916872334H/PXjhhB+uOOKMO9445JNHXvnllmfOueagfy76IaSTbfrpqavOeuuv2x27 7LTXfjvuuu/eu+/ABz88//HGH5+858sb0vzZp6Ou+uqtu1799X3Xbjvuue/Ou++/By888cU7HvLO l75CrO95a3sf3OJXt/nJbnb2Exz+ZNA9xX3vcf6jHAB9UD7OnS90Y2seAt33vunRrXp5e+AMshe4 7RlOf4vjHw3CN7nxYU6AnSNgCEk3wgpE720mnBsK6QdB+7kwf/q7YP/8BwcxOPGJC8DhBwtIiAO2 z4cKDKL8XkfEFUbwiBSEoRJpIIcomPGMUbiDIRIgRR2OToRXrEAX5kjHLvSBgUNUIQsBB8YSSOGP gJRCHGRIA0ewUYBTTAQXFslILswhjoe4Y/zy+EASbOGSmNyCCyYog0OggYeQhgSAKEcJABa40RFm gKQhThCGVrryAZR84CHSwElPgrISADhlI1J5RUc4IJaym2UtSZHL5FFREbxsny9RuAcHOPOZDjgE BrJAzWpmoRQLMIA2t7kASCTzdI44ARTGSU4oPABN6EynOtfJzna6853wjKc850nPetrznvjMpz73 yc9++tMUgQAAOw== --_006_867F4B6A1672E541A94676D556793ACD0C275167F4MOPESMBX01eut_ Content-Type: image/gif; name="image003.gif" Content-Description: image003.gif Content-Disposition: inline; filename="image003.gif"; size=493; creation-date="Tue, 15 Nov 2011 10:58:48 GMT"; modification-date="Tue, 15 Nov 2011 10:58:48 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhHAAhAMQAALHNVVqXGZu+IqbFNv79/ury0pK4H2SdaJzAJNjlq/3++vL34srdiSl5Mfj7 8OHrvDmDE5u+Kb3VbtDgm5jCnJC2IqDBJHqqHoazHsfYxcfco+/58f7///7+/v///f///yH5BAAA AAAALAAAAAAcACEAAAX/4CeOZGmeaKqubOumXSfKL0rT9RiTe65/nl0vxxE1KB3Ph6b8KGYjT/Pn ORwIHmy0FEQFCZRG5yldJnEqD6ezaWQIHMJDApAwCthgF8hbEqwEBQARAoWFEgskQWgiChwFDRoD hpQCA3hLQGhxSWABFpQIlAMPT2NoeTIJEBigooavlzJDS0UdHAkBEAivAoSjDklTQAROuBYQn7+/ lBJJS01SUgoJoskWvaECCWUiHEEKtw+8BtegvoWxiYtqSmsLhBblEALn2hLDH3HTAIXYuhfqVeLF TZ8SR3oSULKAQVeAChYi8kJwCUg4BcVkOOiXDgHDACAvXMBQoWQEOw6iahwsMCmdAI8CKoiciUEA gAJ8aBC4xfKlz3QRsVGcoICMJidKOjhgMKCXqKcAJqSMIkwEuw8OHjCQwNVOggJPvqm4ZUJGuw47 lajlA0Sat28xyJZV9APasGEcvknBkU9TjJ1WrTZZE9hHihAAOw== --_006_867F4B6A1672E541A94676D556793ACD0C275167F4MOPESMBX01eut_-- From yiu_lee@cable.comcast.com Tue Nov 15 02:47:49 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30F8E21F8D83 for ; Tue, 15 Nov 2011 02:47:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.392 X-Spam-Level: X-Spam-Status: No, score=-101.392 tagged_above=-999 required=5 tests=[AWL=0.342, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4-yMExMWDZx for ; Tue, 15 Nov 2011 02:47:48 -0800 (PST) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id 7B91921F8532 for ; Tue, 15 Nov 2011 02:47:48 -0800 (PST) Received: from ([24.40.55.40]) by copdcimo01.cable.comcast.com with ESMTP id 5503630.61456911; Tue, 15 Nov 2011 03:47:53 -0700 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%11]) with mapi id 14.01.0339.001; Tue, 15 Nov 2011 05:47:43 -0500 From: "Lee, Yiu" To: "Hemant Singh (shemant)" Thread-Topic: [v6ops] RFC6204bis-02 Thread-Index: AcyewOvBbq1YdOdiSD66Sp1uaN6CQwCSeq2gAGv1BCAAHHv0MAANyK5QAAHgk2AAADFEcAABKvkAAABIDxAAAFiyMAAEM3K7 Date: Tue, 15 Nov 2011 10:47:43 +0000 Message-ID: <2F25DE74-DA72-4B7B-9358-9E1F17BF4DAD@Cable.Comcast.com> References: <867F4B6A1672E541A94676D556793ACD0C263BCDD7@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303494A91@XMB-RCD-109.cisco.com> <867F4B6A1672E541A94676D556793ACD0C27516363@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303494F74@XMB-RCD-109.cisco.com> <867F4B6A1672E541A94676D556793ACD0C27516655@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303494FE3@XMB-RCD-109.cisco.com> <867F4B6A1672E541A94676D556793ACD0C27516671@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303494FE5@XMB-RCD-109.cisco.com> <867F4B6A1672E541A94676D556793ACD0C275166AC@MOPESMBX01.eu.thmulti.com>, <5B6B2B64C9FE2A489045EEEADDAFF2C303494FE8@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C303494FE8@XMB-RCD-109.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_2F25DE74DA724B7B93589E1F17BF4DADCableComcastcom_" MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 15 Nov 2011 03:21:44 -0800 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] RFC6204bis-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, 15 Nov 2011 10:47:49 -0000 --_000_2F25DE74DA724B7B93589E1F17BF4DADCableComcastcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, Could anybody please explain a scenario where an IPv4 address was given to = a CPE but still want dslite? I assume the CPE would use the provisioned IPv= 4 address to access IPv4 service. Thanks, Yiu On Nov 15, 2011, at 5:34 AM, "Hemant Singh (shemant)" > wrote: One author (cced in this email) of the DS-Lite RFC was agreeable to this bu= llet. I will ask him if he is OK with changing the MUST to a SHOULD and t= hen we can consider the change. Thanks, Hemant From: Wuyts Carl [mailto:Carl.Wuyts@technicolor.com] Sent: Tuesday, November 15, 2011 4:41 PM To: Hemant Singh (shemant); v6ops@ietf.org Subject: RE: [v6ops] RFC6204bis-02 Ok, just want to make sure, as RFC6204 gets lots of interests lately in CPE= area (but also e.g. @ RIPE), to not miss out on anything here. The RFC6204bis says, quoted form it: =93=94 If the IPv6 CE Router is configured with a public IPv4 address on its WAN interface, where public IPv4 address is defined as any address which is not in the private IP address space specified in [RFC5735]= and also not in the reserved IP address space specified in [RFC6333], then the IPv6 CE Router MUST disable the DS-Lite B4 element. =93=94 MUST, so imho, the MUST should be replaced with MAY (or maybe SHOULD). --_000_2F25DE74DA724B7B93589E1F17BF4DADCableComcastcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi,

Could anybody please explain a scenario where an IPv4 address was give= n to a CPE but still want dslite? I assume the CPE would use the provisione= d IPv4 address to access IPv4 service.

Thanks,
Yiu

On Nov 15, 2011, at 5:34 AM, "Hemant Singh (shemant)" <shemant@cisco.com> wrote:

One author (cced in th= is email) of the DS-Lite RFC was agreeable to this bullet.   I wi= ll ask him if he is OK with changing the MUST to a SHOULD and then we can c= onsider the change.

 

Thanks,

 

Hemant

 

From: Wuyts Ca= rl [mailto:Carl.Wuyts@technicolor.com]
Sent: Tuesday, November 15, 2011 4:41 PM
To: Hemant Singh (shemant); v6ops@= ietf.org
Subject: RE: [v6ops] RFC6204bis-02

 

Ok, just want to make = sure, as RFC6204 gets lots of interests lately in CPE area (but also e.g. @= RIPE), to not miss out on anything here.

The RFC6204bis says, q= uoted form it:

=93=94

If the IPv6= CE Router is configured with a public IPv4

  = ;         address on its WAN interf= ace, where public IPv4 address is

  = ;         defined as any address wh= ich is not in the private IP address

  = ;         space specified in [RFC5735] and also not in the reserved IP

  = ;         address space specified i= n [RFC6333], then the IPv6 CE Router

  = ;         MUST disable the DS-Lite = B4 element.

=93=94

 

MUST, so imho, the MUS= T should be replaced with MAY (or maybe SHOULD).

 

--_000_2F25DE74DA724B7B93589E1F17BF4DADCableComcastcom_-- From Olaf.Bonness@telekom.de Tue Nov 15 05:28:21 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA59D21F8BA6 for ; Tue, 15 Nov 2011 05:28:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 gykivwJ56P2g for ; Tue, 15 Nov 2011 05:28:20 -0800 (PST) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) by ietfa.amsl.com (Postfix) with ESMTP id 9B2F721F8AD2 for ; Tue, 15 Nov 2011 05:28:19 -0800 (PST) Received: from he111528.emea1.cds.t-internal.com ([10.125.90.87]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 15 Nov 2011 14:28:16 +0100 Received: from HE111541.emea1.cds.t-internal.com ([169.254.2.251]) by HE111528.EMEA1.CDS.T-INTERNAL.COM ([2002:7cd:5a57::7cd:5a57]) with mapi; Tue, 15 Nov 2011 14:28:16 +0100 From: To: , Date: Tue, 15 Nov 2011 14:28:14 +0100 Thread-Topic: [v6ops] RFC6204bis-02 Thread-Index: AcyewOvBbq1YdOdiSD66Sp1uaN6CQwCSeq2gAGv1BCAAHHv0MAANyK5QAAHgk2AAADFEcAABKvkAAABIDxAAAFiyMAAEM3K7AAWKn7A= Message-ID: References: <867F4B6A1672E541A94676D556793ACD0C263BCDD7@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303494A91@XMB-RCD-109.cisco.com> <867F4B6A1672E541A94676D556793ACD0C27516363@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303494F74@XMB-RCD-109.cisco.com> <867F4B6A1672E541A94676D556793ACD0C27516655@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303494FE3@XMB-RCD-109.cisco.com> <867F4B6A1672E541A94676D556793ACD0C27516671@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303494FE5@XMB-RCD-109.cisco.com> <867F4B6A1672E541A94676D556793ACD0C275166AC@MOPESMBX01.eu.thmulti.com>, <5B6B2B64C9FE2A489045EEEADDAFF2C303494FE8@XMB-RCD-109.cisco.com> <2F25DE74-DA72-4B7B-9358-9E1F17BF4DAD@Cable.Comcast.com> In-Reply-To: <2F25DE74-DA72-4B7B-9358-9E1F17BF4DAD@Cable.Comcast.com> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: multipart/alternative; boundary="_000_CE8995AB5D178F44A2154F5C9A97CAF4024F2E836979HE111541eme_" MIME-Version: 1.0 Cc: v6ops@ietf.org Subject: Re: [v6ops] RFC6204bis-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, 15 Nov 2011 13:28:21 -0000 --_000_CE8995AB5D178F44A2154F5C9A97CAF4024F2E836979HE111541eme_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Some providers might deploy IPv6-only access networks in order to be future= proof and additionally reduce network complexity of Dual-Stack. Regards Olaf Von: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] Im Auftrag von = Lee, Yiu Gesendet: Dienstag, 15. November 2011 11:48 An: Hemant Singh (shemant) Cc: v6ops@ietf.org Betreff: Re: [v6ops] RFC6204bis-02 Hi, Could anybody please explain a scenario where an IPv4 address was given to = a CPE but still want dslite? I assume the CPE would use the provisioned IPv= 4 address to access IPv4 service. Thanks, Yiu On Nov 15, 2011, at 5:34 AM, "Hemant Singh (shemant)" > wrote: One author (cced in this email) of the DS-Lite RFC was agreeable to this bu= llet. I will ask him if he is OK with changing the MUST to a SHOULD and t= hen we can consider the change. Thanks, Hemant From: Wuyts Carl [mailto:Carl.Wuyts@technicolor.com] Sent: Tuesday, November 15, 2011 4:41 PM To: Hemant Singh (shemant); v6ops@ietf.org Subject: RE: [v6ops] RFC6204bis-02 Ok, just want to make sure, as RFC6204 gets lots of interests lately in CPE= area (but also e.g. @ RIPE), to not miss out on anything here. The RFC6204bis says, quoted form it: "" If the IPv6 CE Router is configured with a public IPv4 address on its WAN interface, where public IPv4 address is defined as any address which is not in the private IP address space specified in [RFC5735]= and also not in the reserved IP address space specified in [RFC6333], then the IPv6 CE Router MUST disable the DS-Lite B4 element. "" MUST, so imho, the MUST should be replaced with MAY (or maybe SHOULD). --_000_CE8995AB5D178F44A2154F5C9A97CAF4024F2E836979HE111541eme_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

= Some providers might deploy IPv6-only access = networks in order to be future proof and additionally reduce network comple= xity of Dual-Stack.

Regards

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Olaf<= o:p>

 

 = ;

Von: v6ops-bounces= @ietf.org [mailto:v6ops-bounces@ietf.org] Im Auftrag von Lee, YiuGesendet: Dienstag, 15. November 2011 11:48
An: Hemant Si= ngh (shemant)
Cc: v6ops@ietf.org
Betreff: Re: [v6ops] R= FC6204bis-02

&nb= sp;

Hi,

 

Could anybody please explain a scenario where an IPv= 4 address was given to a CPE but still want dslite? I assume the CPE would = use the provisioned IPv4 address to access IPv4 service.

Thanks,

Yiu


On Nov 15, 2011, at 5:34 AM, "Hemant Singh (shemant)&= quot; <shemant@cisco.com> wr= ote:

One author= (cced in this email) of the DS-Lite RFC was agreeable to this bullet. = ;  I will ask him if he is OK with changing the MUST to a SHOULD and t= hen we can consider the change.

<= span style=3D'color:#1F497D'> 

Thanks,

 

Hemant

 

=

From: Wuyts Carl [mailto:Carl.Wuyts@techni= color.com]
Sent: Tuesday, November 15, 2011 4:41 PM
To: Hemant Singh (shemant); v6ops@ietf.org<= /a>
Subject: RE: [v6ops] RFC6204bis-02

 

Ok, just want to make sure, as RFC6204 gets lots o= f interests lately in CPE area (but also e.g. @ RIPE), to not miss out on a= nything here.

The RFC6204bis says, quoted form it:

“”

If the IPv6 CE Rout= er is configured with a public IPv4

       &= nbsp;   address on its WAN interface, where public IPv4 address i= s

&n= bsp;          defined as any a= ddress which is not in the private IP address

     &nb= sp;     space specified in [RFC573= 5] and also not in the reserved IP

      &nbs= p;    address space specified in [RFC6333], then the IPv6 CE Router

 &n= bsp;         MUST disable the DS-Li= te B4 element.

“”

 

MUST, so imho, the MUST should be replaced with= MAY (or maybe SHOULD).

 

<= /body>= --_000_CE8995AB5D178F44A2154F5C9A97CAF4024F2E836979HE111541eme_-- From ichiroumakino@gmail.com Tue Nov 15 05:30:43 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F6BD11E8106 for ; Tue, 15 Nov 2011 05:30:43 -0800 (PST) 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 YkdsO7TmJbHg for ; Tue, 15 Nov 2011 05:30:39 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD6421F8EDB for ; Tue, 15 Nov 2011 05:30:39 -0800 (PST) Received: by yenq4 with SMTP id q4so4864808yen.31 for ; Tue, 15 Nov 2011 05:30:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=KSatp+BTJ8PeJ/cY15FQN1WHaHdjiZubcSL+qzHc6Xc=; b=aROA8MbD8ZpiW0YSQeHb2MbLzEnkXqAif7Z7OU8zNsEhiKCuxiLf7EAwSU53pv4urE rckEqVc+jlZJITG5QNqo7cLCRQkcAKqayVSea+YlFqzDVS1Y+mVEvefAhTpypVDN3v+9 nsNUIuXzlhxyLWdyB5sXdpSrg6uDNRIorohGg= Received: by 10.68.7.9 with SMTP id f9mr47338129pba.47.1321363838619; Tue, 15 Nov 2011 05:30:38 -0800 (PST) Received: from sjc-vpn4-486.cisco.com (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPS id b4sm65004790pbc.19.2011.11.15.05.27.55 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 15 Nov 2011 05:30:36 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Ole Troan In-Reply-To: <2F25DE74-DA72-4B7B-9358-9E1F17BF4DAD@Cable.Comcast.com> Date: Tue, 15 Nov 2011 21:27:32 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <867F4B6A1672E541A94676D556793ACD0C263BCDD7@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303494A91@XMB-RCD-109.cisco.com> <867F4B6A1672E541A94676D556793ACD0C27516363@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303494F74@XMB-RCD-109.cisco.com> <867F4B6A1672E541A94676D556793ACD0C27516655@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303494FE3@XMB-RCD-109.cisco.com> <867F4B6A1672E541A94676D556793ACD0C27516671@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303494FE5@XMB-RCD-109.cisco.com> <867F4B6A1672E541A94676D556793ACD0C275166AC@MOPESMBX01.eu.thmulti.com>, <5B6B2B64C9FE2A489045EEEADDAFF2C303494FE8@XMB-RCD-109.cisco.com> <2F25DE74-DA72-4B7B-9358-9E1F17BF4DAD@Cable.Comcast.com> To: "Lee, Yiu" X-Mailer: Apple Mail (2.1084) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] RFC6204bis-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, 15 Nov 2011 13:30:43 -0000 > Could anybody please explain a scenario where an IPv4 address was = given to a CPE but still want dslite? I assume the CPE would use the = provisioned IPv4 address to access IPv4 service. walled garden native IPv4 address, Internet service over DS-lite.=20 transitioning from one to the other. e.g from native IPv4 or from = private native IPv4 (behind CGN) to DS-lite see an example in the new 6rd-sunsetting draft for how native and = tunneled service works. this is really policy. something that we shouldn't encode here in an = RFC. if the CPE gets IPv4 service on multiple interfaces, it is multi-homed. cheers, Ole >> One author (cced in this email) of the DS-Lite RFC was agreeable to = this bullet. I will ask him if he is OK with changing the MUST to a = SHOULD and then we can consider the change. >> =20 >> Thanks, >> =20 >> Hemant >> =20 >> From: Wuyts Carl [mailto:Carl.Wuyts@technicolor.com]=20 >> Sent: Tuesday, November 15, 2011 4:41 PM >> To: Hemant Singh (shemant); v6ops@ietf.org >> Subject: RE: [v6ops] RFC6204bis-02 >> =20 >> Ok, just want to make sure, as RFC6204 gets lots of interests lately = in CPE area (but also e.g. @ RIPE), to not miss out on anything here. >> The RFC6204bis says, quoted form it: >> =93=94 >> If the IPv6 CE Router is configured with a public IPv4 >> address on its WAN interface, where public IPv4 address is >> defined as any address which is not in the private IP = address >> space specified in [RFC5735] and also not in the reserved = IP >> address space specified in [RFC6333], then the IPv6 CE = Router >> MUST disable the DS-Lite B4 element. >> =93=94 >> =20 >> MUST, so imho, the MUST should be replaced with MAY (or maybe = SHOULD). >> =20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From wesley.george@twcable.com Tue Nov 15 06:02:02 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76FF421F8D50 for ; Tue, 15 Nov 2011 06:02:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.916 X-Spam-Level: X-Spam-Status: No, score=-0.916 tagged_above=-999 required=5 tests=[AWL=0.547, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, 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 qI7yCOK0LXfC for ; Tue, 15 Nov 2011 06:02:00 -0800 (PST) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB3221F8D4A for ; Tue, 15 Nov 2011 06:02:00 -0800 (PST) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.69,514,1315195200"; d="scan'208";a="297531569" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 15 Nov 2011 08:57:18 -0500 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.26]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Tue, 15 Nov 2011 09:01:47 -0500 From: "George, Wes" To: Wuyts Carl , "Lee, Yiu" , "Hemant Singh (shemant)" Date: Tue, 15 Nov 2011 09:02:12 -0500 Thread-Topic: [v6ops] RFC6204bis-02 Thread-Index: AcyewOvBbq1YdOdiSD66Sp1uaN6CQwCSeq2gAGv1BCAAHHv0MAANyK5QAAHgk2AAADFEcAABKvkAAABIDxAAAFiyMAAEM3K7AAAvTsAABnfm4A== Message-ID: References: <867F4B6A1672E541A94676D556793ACD0C263BCDD7@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303494A91@XMB-RCD-109.cisco.com> <867F4B6A1672E541A94676D556793ACD0C27516363@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303494F74@XMB-RCD-109.cisco.com> <867F4B6A1672E541A94676D556793ACD0C27516655@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303494FE3@XMB-RCD-109.cisco.com> <867F4B6A1672E541A94676D556793ACD0C27516671@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303494FE5@XMB-RCD-109.cisco.com> <867F4B6A1672E541A94676D556793ACD0C275166AC@MOPESMBX01.eu.thmulti.com>, <5B6B2B64C9FE2A489045EEEADDAFF2C303494FE8@XMB-RCD-109.cisco.com> <2F25DE74-DA72-4B7B-9358-9E1F17BF4DAD@Cable.Comcast.com> <867F4B6A1672E541A94676D556793ACD0C275167F4@MOPESMBX01.eu.thmulti.com> In-Reply-To: <867F4B6A1672E541A94676D556793ACD0C275167F4@MOPESMBX01.eu.thmulti.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] RFC6204bis-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, 15 Nov 2011 14:02:02 -0000 From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of W= uyts Carl >> the CPE should not be in charge of checking for "public" IPv4 presence a= nd based upon that tear up/bring down the DSLite tunnel. If the ISP (we're= not present in retail) decides on configuring the CPE with a public IPv4, = then he should be aware of his actions and remove either the tunnel or the = DHCPv6 option for the tunnel from the configuration. [WEG] More importantly, how would a CPE determine what addresses are public= and what are private? Assuming simply public !=3D RFC1918 isn't enough, wh= ether draft-weil passes or not. Either you now have to take that space into= account as additional private space, or you run the very real risk of folk= s using "public" addresses (squat) inside of private environments, or both. Wes George This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From fred@cisco.com Tue Nov 15 06:55:08 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2947F21F8B21 for ; Tue, 15 Nov 2011 06:55:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.742 X-Spam-Level: X-Spam-Status: No, score=-105.742 tagged_above=-999 required=5 tests=[AWL=0.857, 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 Vo0f6xvB-cnz for ; Tue, 15 Nov 2011 06:55:04 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 6AF2B21F8B23 for ; Tue, 15 Nov 2011 06:55:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=137; q=dns/txt; s=iport; t=1321368904; x=1322578504; h=date:from:message-id:to:subject:cc; bh=hEhiXt3aQDTGzGwWXWrIq7bo2YQLTfh1ygjB8zEzhLg=; b=mtXNvWqAWVY0ZBqSfObzctGfb/4m0tVpZQZvr1wObw5LexgpKZUC4XQ6 sx/I/rPPoWm1CCl21dBQABc83GZCNXYdIjocMGJ+V3wddj6u61oEdh7gV /07UjGCenc8gm4vm0xzoBK6wOzM7FvlhfXX/jc4i1aFt+BKpG7r2d7ntB I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqkGALh8wk6rRDoG/2dsb2JhbABEmicBhAcDizyBBYILAWY8LYEKh2iaAgGfAYZ8gxUEiBOeOg X-IronPort-AV: E=Sophos;i="4.69,515,1315180800"; d="scan'208";a="12634358" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 15 Nov 2011 14:55:01 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pAFEt1Pt030372; Tue, 15 Nov 2011 14:55:01 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id pAFEt1j04890; Tue, 15 Nov 2011 06:55:01 -0800 (PST) Date: Tue, 15 Nov 2011 06:55:01 -0800 (PST) From: Message-Id: <201111151455.pAFEt1j04890@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-townsley-v6ops-6rd-sunsetting@tools.ietf.org Subject: [v6ops] new draft: draft-townsley-v6ops-6rd-sunsetting X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 Nov 2011 14:55:08 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-townsley-v6ops-6rd-sunsetting. Please take a look at it and comment. From fred@cisco.com Tue Nov 15 06:55:08 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32B1621F8B23 for ; Tue, 15 Nov 2011 06:55:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.849 X-Spam-Level: X-Spam-Status: No, score=-105.849 tagged_above=-999 required=5 tests=[AWL=0.750, 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 t51FJJoo-F10 for ; Tue, 15 Nov 2011 06:55:04 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 6FFD321F8B24 for ; Tue, 15 Nov 2011 06:55:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=135; q=dns/txt; s=iport; t=1321368904; x=1322578504; h=date:from:message-id:to:subject:cc; bh=poIORcnYHbyOTF5Z2W0NbsPuYE+hJxulJOy0TfXIN20=; b=MUQprtQ+4XTnoGuz471NMIFGqy/68h86vL5dpOzlDOlPzJib0oYwBCui 0dMJR2umN0YqabwGkH1ppBvD3+wyk6thBmqLlYUWYuh1orP5QLxqHT3bp agvogcuwVbOeyiBdJpq+GIj2Bolg21+0NAxxxV8+qHkZSXkPMTbOBK3jx 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqkGALh8wk6rRDoG/2dsb2JhbABEmicBhAcDizyBBYILAWY8LYEKh2iaAgGfAYZ8gxUEiBOeOg X-IronPort-AV: E=Sophos;i="4.69,515,1315180800"; d="scan'208";a="12634359" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 15 Nov 2011 14:55:01 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pAFEt1Ow030375; Tue, 15 Nov 2011 14:55:01 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id pAFEt1K04887; Tue, 15 Nov 2011 06:55:01 -0800 (PST) Date: Tue, 15 Nov 2011 06:55:01 -0800 (PST) From: Message-Id: <201111151455.pAFEt1K04887@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-ietf-v6ops-ivi-icmp-address@tools.ietf.org Subject: [v6ops] new draft: draft-ietf-v6ops-ivi-icmp-address X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 Nov 2011 14:55:08 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-ietf-v6ops-ivi-icmp-address. Please take a look at it and comment. From yiu_lee@cable.comcast.com Tue Nov 15 07:01:24 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38EFE21F8B24 for ; Tue, 15 Nov 2011 07:01:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.077 X-Spam-Level: X-Spam-Status: No, score=-99.077 tagged_above=-999 required=5 tests=[AWL=-2.145, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_13=0.6, MIME_BASE64_TEXT=1.753, 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 VzJRvsEL+3AA for ; Tue, 15 Nov 2011 07:01:23 -0800 (PST) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id 9D31121F8B21 for ; Tue, 15 Nov 2011 07:01:20 -0800 (PST) Received: from ([24.40.55.42]) by copdcimo01.cable.comcast.com with ESMTP id 5503630.61483115; Tue, 15 Nov 2011 08:01:23 -0700 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%11]) with mapi id 14.01.0339.001; Tue, 15 Nov 2011 10:01:26 -0500 From: "Lee, Yiu" To: Ole Troan Thread-Topic: [v6ops] RFC6204bis-02 Thread-Index: AcyewOvBbq1YdOdiSD66Sp1uaN6CQwCSeq2gAGv1BCAAHHv0MAANyK5QAAHgk2AAADFEcAABKvkAAABIDxAAAFiyMAAEM3K7ABAO/AD//8ZaAA== Date: Tue, 15 Nov 2011 15:01:12 +0000 Message-ID: <603F3E51-2066-41BD-8E3C-A315011C6EA7@Cable.Comcast.com> References: <867F4B6A1672E541A94676D556793ACD0C263BCDD7@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303494A91@XMB-RCD-109.cisco.com> <867F4B6A1672E541A94676D556793ACD0C27516363@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303494F74@XMB-RCD-109.cisco.com> <867F4B6A1672E541A94676D556793ACD0C27516655@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303494FE3@XMB-RCD-109.cisco.com> <867F4B6A1672E541A94676D556793ACD0C27516671@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303494FE5@XMB-RCD-109.cisco.com> <867F4B6A1672E541A94676D556793ACD0C275166AC@MOPESMBX01.eu.thmulti.com>, <5B6B2B64C9FE2A489045EEEADDAFF2C303494FE8@XMB-RCD-109.cisco.com> <2F25DE74-DA72-4B7B-9358-9E1F17BF4DAD@Cable.Comcast.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 15 Nov 2011 07:19:35 -0800 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] RFC6204bis-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, 15 Nov 2011 15:01:24 -0000 T2suIFNvIHRoZSBzY2VuYXJpbyBpcyBhbiBJU1AgcHJvdmlzaW9ucyBhbiBJUHY0IGZvciBpbnRl cm5hbCB1c2UsIHN1YnNjcmliZXIncyBJbnRlcm5ldCB0cmFmZmljIHdpbGwgdXNlIGRzbGl0ZS4g VGhhdCBpbXBsaWVzIHRoZSBDUEUgd2lsbCBoYXZlIHRoZSBsb2dpYyB0byBmdW5uZWwgdGhlIHRy YWZmaWMgZm9yIHByb3BlciByb3V0aW5nIGRlY2lzaW9uLiBDaGFuZ2UgdG8gInNob3VsZCIgaW1w bGllcyBhIGxvdC4gSSB3b3VsZCByZWNvbW1lbmQgdG8gbWVudGlvbiBhbiBleGFtcGxlIGluIHRo ZSBkcmFmdCB3aHkgYSBDUEUgaGFzIGFuIElQdjQgYWRkcmVzcyBidXQgc3RpbGwgdXNlcyBkc2xp dGUuIA0KDQoNCk9uIE5vdiAxNSwgMjAxMSwgYXQgODozMCBBTSwgIk9sZSBUcm9hbiIgPG90cm9h bkBlbXBsb3llZXMub3JnPiB3cm90ZToNCg0KPj4gQ291bGQgYW55Ym9keSBwbGVhc2UgZXhwbGFp biBhIHNjZW5hcmlvIHdoZXJlIGFuIElQdjQgYWRkcmVzcyB3YXMgZ2l2ZW4gdG8gYSBDUEUgYnV0 IHN0aWxsIHdhbnQgZHNsaXRlPyBJIGFzc3VtZSB0aGUgQ1BFIHdvdWxkIHVzZSB0aGUgcHJvdmlz aW9uZWQgSVB2NCBhZGRyZXNzIHRvIGFjY2VzcyBJUHY0IHNlcnZpY2UuDQo+IA0KPiB3YWxsZWQg Z2FyZGVuIG5hdGl2ZSBJUHY0IGFkZHJlc3MsIEludGVybmV0IHNlcnZpY2Ugb3ZlciBEUy1saXRl LiANCj4gdHJhbnNpdGlvbmluZyBmcm9tIG9uZSB0byB0aGUgb3RoZXIuIGUuZyBmcm9tIG5hdGl2 ZSBJUHY0IG9yIGZyb20gcHJpdmF0ZSBuYXRpdmUgSVB2NCAoYmVoaW5kIENHTikgdG8gRFMtbGl0 ZQ0KPiBzZWUgYW4gZXhhbXBsZSBpbiB0aGUgbmV3IDZyZC1zdW5zZXR0aW5nIGRyYWZ0IGZvciBo b3cgbmF0aXZlIGFuZCB0dW5uZWxlZCBzZXJ2aWNlIHdvcmtzLg0KPiANCj4gdGhpcyBpcyByZWFs bHkgcG9saWN5LiBzb21ldGhpbmcgdGhhdCB3ZSBzaG91bGRuJ3QgZW5jb2RlIGhlcmUgaW4gYW4g UkZDLg0KPiBpZiB0aGUgQ1BFIGdldHMgSVB2NCBzZXJ2aWNlIG9uIG11bHRpcGxlIGludGVyZmFj ZXMsIGl0IGlzIG11bHRpLWhvbWVkLg0KPiANCj4gY2hlZXJzLA0KPiBPbGUNCj4gDQo+Pj4gT25l IGF1dGhvciAoY2NlZCBpbiB0aGlzIGVtYWlsKSBvZiB0aGUgRFMtTGl0ZSBSRkMgd2FzIGFncmVl YWJsZSB0byB0aGlzIGJ1bGxldC4gICBJIHdpbGwgYXNrIGhpbSBpZiBoZSBpcyBPSyB3aXRoIGNo YW5naW5nIHRoZSBNVVNUIHRvIGEgU0hPVUxEIGFuZCB0aGVuIHdlIGNhbiBjb25zaWRlciB0aGUg Y2hhbmdlLg0KPj4+IA0KPj4+IFRoYW5rcywNCj4+PiANCj4+PiBIZW1hbnQNCj4+PiANCj4+PiBG cm9tOiBXdXl0cyBDYXJsIFttYWlsdG86Q2FybC5XdXl0c0B0ZWNobmljb2xvci5jb21dIA0KPj4+ IFNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDE1LCAyMDExIDQ6NDEgUE0NCj4+PiBUbzogSGVtYW50 IFNpbmdoIChzaGVtYW50KTsgdjZvcHNAaWV0Zi5vcmcNCj4+PiBTdWJqZWN0OiBSRTogW3Y2b3Bz XSBSRkM2MjA0YmlzLTAyDQo+Pj4gDQo+Pj4gT2ssIGp1c3Qgd2FudCB0byBtYWtlIHN1cmUsIGFz IFJGQzYyMDQgZ2V0cyBsb3RzIG9mIGludGVyZXN0cyBsYXRlbHkgaW4gQ1BFIGFyZWEgKGJ1dCBh bHNvIGUuZy4gQCBSSVBFKSwgdG8gbm90IG1pc3Mgb3V0IG9uIGFueXRoaW5nIGhlcmUuDQo+Pj4g VGhlIFJGQzYyMDRiaXMgc2F5cywgcXVvdGVkIGZvcm0gaXQ6DQo+Pj4gobChsQ0KPj4+IElmIHRo ZSBJUHY2IENFIFJvdXRlciBpcyBjb25maWd1cmVkIHdpdGggYSBwdWJsaWMgSVB2NA0KPj4+ICAg ICAgICAgICBhZGRyZXNzIG9uIGl0cyBXQU4gaW50ZXJmYWNlLCB3aGVyZSBwdWJsaWMgSVB2NCBh ZGRyZXNzIGlzDQo+Pj4gICAgICAgICAgIGRlZmluZWQgYXMgYW55IGFkZHJlc3Mgd2hpY2ggaXMg bm90IGluIHRoZSBwcml2YXRlIElQIGFkZHJlc3MNCj4+PiAgICAgICAgICAgc3BhY2Ugc3BlY2lm aWVkIGluIFtSRkM1NzM1XSBhbmQgYWxzbyBub3QgaW4gdGhlIHJlc2VydmVkIElQDQo+Pj4gICAg ICAgICAgIGFkZHJlc3Mgc3BhY2Ugc3BlY2lmaWVkIGluIFtSRkM2MzMzXSwgdGhlbiB0aGUgSVB2 NiBDRSBSb3V0ZXINCj4+PiAgICAgICAgICAgTVVTVCBkaXNhYmxlIHRoZSBEUy1MaXRlIEI0IGVs ZW1lbnQuDQo+Pj4gobChsQ0KPj4+IA0KPj4+IE1VU1QsIHNvIGltaG8sIHRoZSBNVVNUIHNob3Vs ZCBiZSByZXBsYWNlZCB3aXRoIE1BWSAob3IgbWF5YmUgU0hPVUxEKS4NCj4+PiANCj4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiB2Nm9wcyBtYWls aW5nIGxpc3QNCj4+IHY2b3BzQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3Y2b3BzDQo+IA0K From bs7652@att.com Tue Nov 15 07:33:16 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F29F21F8B55 for ; Tue, 15 Nov 2011 07:33:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.426 X-Spam-Level: X-Spam-Status: No, score=-106.426 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 lokNdRRQuxye for ; Tue, 15 Nov 2011 07:33:14 -0800 (PST) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id E068921F8B37 for ; Tue, 15 Nov 2011 07:33:13 -0800 (PST) X-Env-Sender: bs7652@att.com X-Msg-Ref: server-15.tower-120.messagelabs.com!1321371191!49372326!1 X-Originating-IP: [144.160.20.146] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14667 invoked from network); 15 Nov 2011 15:33:11 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-15.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Nov 2011 15:33:11 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pAFFVjIk009350 for ; Tue, 15 Nov 2011 10:31:45 -0500 Received: from 01AL10015010626.AD.BLS.COM (sfldmibbcraeninet1-v2.enaf.ait.sbc.com [10.231.16.33]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pAFFVdxp009191 for ; Tue, 15 Nov 2011 10:31:40 -0500 Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01AL10015010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Nov 2011 09:32:17 -0600 Received: from 01NC27689010650.AD.BLS.COM ([90.144.44.120]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Nov 2011 10:32:17 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCA3AB.C1E816AC" Date: Tue, 15 Nov 2011 10:33:03 -0500 Message-ID: <750BF7861EBBE048B3E648B4BB6E8F4F20B124DE@crexc50p> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] 6rd Sunsetting Thread-Index: AcyjbMdrG8fQqDnpSiuXKDRY89QkRAAOym+w References: From: "STARK, BARBARA H" To: X-OriginalArrivalTime: 15 Nov 2011 15:32:17.0020 (UTC) FILETIME=[C1A123C0:01CCA3AB] Subject: Re: [v6ops] 6rd Sunsetting X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 Nov 2011 15:33:16 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCA3AB.C1E816AC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have a few comments on the proposed 6rd Sunsetting doc. =20 1. Since CE Routers can't predict whether an access network will choose to renumber or keep numbers the same, it must be prepared to handle either. Recommendations for CE routers need to be provided that account for both cases, and do not require the CE router to know, a priori, which will be used (that is, there should be no expectation of differing configuration in the CE router, depending on what the access network decides to do). [This draft is written from the access network perspective. For good CE router recommendations, it needs to look at it, holistically, from the CE router perspective.] =20 2. There is an assumption in some of the text in this draft that CE routers inside the 6rd domain will always route directly to each other, without going to the BR. Note that we've specifically asked for it to be configurable as to whether or not this is the case. Therefore, some CE routers may be configured to send all IPv6 traffic to the BR. I don't think this necessarily changes the recommendations, but it should change some of the language used to justify the recommendations. =20 3. The following phrase is used a couple of times, and is a bit fuzzy, IMO: "6rd routes remain [in the CE router] as long as 6rd is configured by the SP". When 6rd is configured by DHCPv4 or TR-069 or SNMP, it's clear to me what this means. But when the CE router was manually configured for 6rd, I have no clue what this means. How is the manually-configured CE router supposed to know whether or not 6rd is configured by the SP? Some guidance in this area would be appreciated. For example, should the CE router test to see if the BR is reachable, and if not assume that 6rd is not configured by the SP? =20 Barbara=20 =20 From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Mark Townsley Sent: Tuesday, November 15, 2011 3:02 AM To: v6ops@ietf.org WG Cc: Alexandre Cassen Subject: [v6ops] 6rd Sunsetting =20 =20 Alexandre and I just finished up a -00 that describes two methods for moving a 6rd deployment to native IPv6. Apologies for not getting this out before the meeting. =20 http://www.ietf.org/id/draft-townsley-v6ops-6rd-sunsetting-00.txt =20 Abstract =20 This document provides guidelines for transitioning an IPv6 deployment using IPv6 Rapid Deployment (6rd) to an IPv6 deployment using Native IPv6. It is targeted at both 6rd operators and 6rd implementors." =20 - Mark ------_=_NextPart_001_01CCA3AB.C1E816AC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have a few comments on the proposed 6rd Sunsetting = doc.

 

1. Since CE Routers can’t predict whether an access network = will choose to renumber or keep numbers the same, it must be prepared to = handle either. Recommendations for CE routers need to be provided that = account for both cases, and do not require the CE router to know, a = priori, which will be used (that is, there should be no expectation of = differing configuration in the CE router, depending on what the access = network decides to do). [This draft is written from the access network = perspective. For good CE router recommendations, it needs to look at it, = holistically, from the CE router perspective.]

 

2. There is an assumption in some of the text in this draft that CE = routers inside the 6rd domain will always route directly to each other, = without going to the BR. Note that we’ve specifically asked for it = to be configurable as to whether or not this is the case. Therefore, = some CE routers may be configured to send all IPv6 traffic to the BR. I = don’t think this necessarily changes the recommendations, but it = should change some of the language used to justify the = recommendations.

 

3. The following phrase is used a couple of times, and is a bit = fuzzy, IMO: “6rd routes remain [in the CE router] as long as 6rd = is configured by the SP”. When 6rd is configured by DHCPv4 or = TR-069 or SNMP, it’s clear to me what this means. But when the CE = router was manually configured for 6rd, I have no clue what this means. = How is the manually-configured CE router supposed to know whether or not = 6rd is configured by the SP? Some guidance in this area would be = appreciated. For example, should the CE router test to see if the BR is = reachable, and if not assume that 6rd is not configured by the = SP?

 

Barbara

 

From:= = v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of = Mark Townsley
Sent: Tuesday, November 15, 2011 3:02 = AM
To: v6ops@ietf.org WG
Cc: Alexandre = Cassen
Subject: [v6ops] 6rd = Sunsetting

 

 

Alexandre and I just finished up a -00 that describes = two methods for moving a 6rd deployment to native IPv6. Apologies for = not getting this out before the meeting.

 

 

Abstract
 
   This document provides guidelines for =
transitioning an IPv6
   deployment using IPv6 Rapid =
Deployment (6rd) to an IPv6 deployment
   using Native IPv6.  It is =
targeted at both 6rd operators and 6rd
   =
implementors."

 

- = Mark

------_=_NextPart_001_01CCA3AB.C1E816AC-- From bs7652@att.com Tue Nov 15 07:50:31 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A05BD21F8B68 for ; Tue, 15 Nov 2011 07:50:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.448 X-Spam-Level: X-Spam-Status: No, score=-106.448 tagged_above=-999 required=5 tests=[AWL=0.151, 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 l1JzPU1rCcZU for ; Tue, 15 Nov 2011 07:50:30 -0800 (PST) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id CB47621F8B65 for ; Tue, 15 Nov 2011 07:50:29 -0800 (PST) X-Env-Sender: bs7652@att.com X-Msg-Ref: server-15.tower-119.messagelabs.com!1321372227!1173107!1 X-Originating-IP: [144.160.20.146] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23158 invoked from network); 15 Nov 2011 15:50:28 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-15.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Nov 2011 15:50:28 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pAFFn2Kl006870 for ; Tue, 15 Nov 2011 10:49:02 -0500 Received: from 01AL10015010625.AD.BLS.COM (sfldmibbcraeninet1.pmtr.mwst.att.com [10.231.16.33]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pAFFmwRB006753 for ; Tue, 15 Nov 2011 10:48:58 -0500 Received: from 01NC27689010625.AD.BLS.COM ([90.144.44.200]) by 01AL10015010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Nov 2011 09:49:35 -0600 Received: from 01NC27689010650.AD.BLS.COM ([90.144.44.120]) by 01NC27689010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Nov 2011 10:49:36 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Nov 2011 10:50:22 -0500 Message-ID: <750BF7861EBBE048B3E648B4BB6E8F4F20B1252E@crexc50p> In-Reply-To: <603F3E51-2066-41BD-8E3C-A315011C6EA7@Cable.Comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] RFC6204bis-02: DS-Lite transition discussion Thread-Index: AcyewOvBbq1YdOdiSD66Sp1uaN6CQwCSeq2gAGv1BCAAHHv0MAANyK5QAAHgk2AAADFEcAABKvkAAABIDxAAAFiyMAAEM3K7ABAO/AD//8ZaAP//9fDg References: <867F4B6A1672E541A94676D556793ACD0C263BCDD7@MOPESMBX01.eu.thmulti.com><5B6B2B64C9FE2A489045EEEADDAFF2C303494A91@XMB-RCD-109.cisco.com><867F4B6A1672E541A94676D556793ACD0C27516363@MOPESMBX01.eu.thmulti.com><5B6B2B64C9FE2A489045EEEADDAFF2C303494F74@XMB-RCD-109.cisco.com><867F4B6A1672E541A94676D556793ACD0C27516655@MOPESMBX01.eu.thmulti.com><5B6B2B64C9FE2A489045EEEADDAFF2C303494FE3@XMB-RCD-109.cisco.com><867F4B6A1672E541A94676D556793ACD0C27516671@MOPESMBX01.eu.thmulti.com><5B6B2B64C9FE2A489045EEEADDAFF2C303494FE5@XMB-RCD-109.cisco.com><867F4B6A1672E541A94676D556793ACD0C275166AC@MOPESMBX01.eu.thmulti.com>, <5B6B2B64C9FE2A489045EEEADDAFF2C303494FE8@XMB-RCD-109.cisco.com><2F25DE74-DA72-4B7B-9358-9E1F17BF4DAD@Cable.Comcast.com>, <603F3E51-2066-41BD-8E3C-A315011C6EA7@Cable.Comcast.com> From: "STARK, BARBARA H" To: X-OriginalArrivalTime: 15 Nov 2011 15:49:36.0128 (UTC) FILETIME=[2CFC7000:01CCA3AE] Subject: Re: [v6ops] RFC6204bis-02: DS-Lite transition discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 Nov 2011 15:50:31 -0000 As I see it, there are 2 main transition scenarios around DS-Lite: 1. The customer has a NAT444 service and is being transitioned to DS-Lite, to remove one layer of NAT, and maybe as part of a process to remove IPv4 from the access network. In this case, the NAT444 address provided to the CE router may be RFC1918, from some new address space that may or may not be allocated for CGN deployments, or some other bogon address that the CGN operator decided to use. The direction of transition is towards DS-Lite, and away from native IPv4. 2. The customer has a public IPv4 address on the CE router WAN, but the access network is preparing to stop supporting IPv4 in the access network, and is moving all IPv4 connectivity to DS-Lite. The direction of transition is towards DS-Lite and away from native IPv4. 3. The customer has DS-Lite, doesn't like it, so the provider is transitioning him to an IPv4 service with a public IPv4 address to the CE router WAN. The direction of transition is towards native IPv4 and away from DS-Lite. I don't see much of a case for DS-Lite to be transitioned to NAT444 as a variant on scenario 3. But note that in the case of random bogon addresses in scenario 1, we really have no idea as to whether the WAN IPv4 address is public or private. And the CE router really has no clue as to why it sees both native IPv4 and DS-Lite. It just knows that both are there, and needs simple rules for dealing with the situation. Barbara From v6ops@globis.net Tue Nov 15 10:13:14 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A50F1F0C42 for ; Tue, 15 Nov 2011 10:13:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.121, 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 z9VLKf3qYlON for ; Tue, 15 Nov 2011 10:13:09 -0800 (PST) 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 38FCB1F0C3D for ; Tue, 15 Nov 2011 10:13:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id E2BEB8700B6 for ; Tue, 15 Nov 2011 19:13:07 +0100 (CET) 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 DuUNjSlB8rLW for ; Tue, 15 Nov 2011 19:12:57 +0100 (CET) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id EB6FE870056 for ; Tue, 15 Nov 2011 19:12:56 +0100 (CET) Message-ID: <4EC2ABA8.4020303@globis.net> Date: Tue, 15 Nov 2011 19:12:56 +0100 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: v6ops@ietf.org References: <20111115062859.14026.42405.idtracker@ietfa.amsl.com> In-Reply-To: <20111115062859.14026.42405.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-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: Tue, 15 Nov 2011 18:13:14 -0000 I support this work. 1. I am no fan of NAT. One valid use of NAT that I have seen is to guarantee a symmetrical return route for packets that have been routed at a remote site using policy based routing (PBR) e.g. Internet offload of "bulk" traffic. A mechanism for routers to be able communicate their PBR policy table rules to the local end node should be successful. But IMHO draft-ietf-6man-addr-select-opt-01 would not seem to be adequate, as it does not contain enough high-level application related information like something being "expensive" AFAIK. And that leaves a hard problem of how to communicate a soft policy that may not be based on hard classifiers like bandwidth, but rather dollar cost per megabyte. 2. "In short, while IPv6 facilitates hosts having more than one address in the same address scope, the application of this causes significant issues for a host from routing, source address selection and DNS resolution perspectives" I still like the "learn by trying" approach of Happy Eyeballs (mentioned this back in April) even though it may produce some (small) additional burden on the network. One problem again is that start-up metrics related to SYN packet performance may not provide appropriate/sufficient information to be able to formulate effective or meaningful policy for source address/destination address/path selection. As an extension to the "learn by trying" approach, is there a case for a hop-by-hop header option for end nodes to be able to learn path characteristics from routers (during session start up)? I doubt that core routers will ever want to process or add such a header option, but I could imagine that a CPE router or end node could be configured to tag packets containing a TCP SYN going out of interface A as being "cheap" and interface B as being "high latency" based on a locally configured administrative option. That tag could be reflected at the server end back to the client during session start up. I'm thinking of the good old EIGRP metrics as a simple starting point [bandwidth, delay, reliability, load, minimum MTU, hop count]. Vendor extensions of the tags should of course be possible. These tags would then be used by the end node to be able to select the correct path to use (per application) from the successfully negotiated paths. 3. "a function to control every node centrally. A site administrator or a service provider could determine or could have an effect on the behavior at their users' hosts." The draft seems to assume that routers or network managers are all knowing, and end nodes and end users are dumb. In a model based on mobile handsets connected to alternative (competing) networks, the user probably knows more than the service providers about what policy they want: think WiFi v 4G. I'd thus prefer a model that was more symmetrical, where policy selection and communication of path/topology information were orthogonal. regards, RayH internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. > > Title : IPv6 Multihoming without Network Address Translation > Author(s) : Ole Troan > David Miles > Satoru Matsushima > Tadahisa Okimoto > Dan Wing > Filename : draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-03.txt > Pages : 24 > Date : 2011-11-14 > > Network Address and Port Translation (NAPT) works well for conserving > global addresses and addressing multihoming requirements, because an > IPv4 NAPT router implements three functions: source address > selection, next-hop resolution and optionally DNS resolution. For > IPv6 hosts one approach could be the use of NPTv6. However, NAT > should be avoided, if at all possible, to permit transparent end-to- > end connectivity. In this document, we analyze the use cases of > multihoming. We also describe functional requirements and possible > solutions for multihoming without the use of NAT in IPv6 for hosts > and small IPv6 networks that would otherwise be unable to meet > minimum IPv6 allocation criteria. We conclude that DHCPv6 based > solutions are suitable to solve the multihoming issues, which > described in this document. Nevertheless, we mention that the > possible needs for NPTv6 in the transition phase to the fully > deployment of the proposed solutions. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-03.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-v6ops-ipv6-multihoming-without-ipv6nat-03.txt > > From marka@isc.org Tue Nov 15 15:00:44 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFA8E1F0C9C for ; Tue, 15 Nov 2011 15:00:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.144 X-Spam-Level: X-Spam-Status: No, score=-2.144 tagged_above=-999 required=5 tests=[AWL=-0.145, 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 zDdRR5NP1ASy for ; Tue, 15 Nov 2011 15:00:40 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 0481C1F0C34 for ; Tue, 15 Nov 2011 15:00:40 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id C26BA5F9899; Tue, 15 Nov 2011 23:00:24 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 61C34216C6A; Tue, 15 Nov 2011 23:00:22 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 49D741739A18; Wed, 16 Nov 2011 10:00:16 +1100 (EST) To: "STARK, BARBARA H" From: Mark Andrews References: <867F4B6A1672E541A94676D556793ACD0C263BCDD7@MOPESMBX01.eu.thmulti.com><5B6B2B64C9FE2A489045EEEADDAFF2C303494A91@XMB-RCD-109.cisco.com><867F4B6A1672E541A94676D556793ACD0C27516363@MOPESMBX01.eu.thmulti.com><5B6B2B64C9FE2A489045EEEADDAFF2C303494F74@XMB-RCD-109.cisco.com><867F4B6A1672E541A94676D556793ACD0C27516655@MOPESMBX01.eu.thmulti.com><5B6B2B64C9FE2A489045EEEADDAFF2C303494FE3@XMB-RCD-109.cisco.com><867F4B6A1672E541A94676D556793ACD0C27516671@MOPESMBX01.eu.thmulti.com><5B6B2B64C9FE2A489045EEEADDAFF2C303494FE5@XMB-RCD-109.cisco.com><867F4B6A1672E541A94676D556793ACD0C275166AC@MOPESMBX01.eu.thmulti.com>, <5B6B2B64C9FE2A489045EEEADDAFF2C303494FE8@XMB-RCD-109.cisco.com><2F25DE74-DA72-4B7B-9358-9E1F17BF4DAD@Cable.Comcast.com>, <603F3E51-2066-41BD-8E3C-A315011C6EA7@Cable.Comcast.com> <750BF7861EBBE048B3E648B4BB6E8F4F20B1252E@crexc50p> In-reply-to: Your message of "Tue, 15 Nov 2011 10:50:22 CDT." <750BF7861EBBE048B3E648B4BB6E8F4F20B1252E@crexc50p> Date: Wed, 16 Nov 2011 10:00:15 +1100 Message-Id: <20111115230016.49D741739A18@drugs.dv.isc.org> Cc: v6ops@ietf.org Subject: Re: [v6ops] RFC6204bis-02: DS-Lite transition discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 15 Nov 2011 23:00:44 -0000 As a user, I want to be able to specifiy who is providing my AFTR service. My ISP's AFTR boxes may suck or my ISP may be using NAT64 and in either case I want to be able to use a third party AFTR service. As a user, I want to be able to disable the use of DS-Lite. As a user, I want my CPE to use DS-Lite if my ISP enables it. (default) As for routing when there is both a WAN IPv4 address and DS-Lite available. Route local addresses natively (WAN and LAN) and non-local addresses via DS-Lite. If there is a entry in the NAT's state table use it in preference to DS-Lite. As a user, I want to be able to specify whether the AFTR option is advertised internally or not. (default off?) In message <750BF7861EBBE048B3E648B4BB6E8F4F20B1252E@crexc50p>, "STARK, BARBARA H" writes: > As I see it, there are 2 main transition scenarios around DS-Lite: > > 1. The customer has a NAT444 service and is being transitioned to > DS-Lite, to remove one layer of NAT, and maybe as part of a process to > remove IPv4 from the access network. In this case, the NAT444 address > provided to the CE router may be RFC1918, from some new address space > that may or may not be allocated for CGN deployments, or some other > bogon address that the CGN operator decided to use. The direction of > transition is towards DS-Lite, and away from native IPv4. > > 2. The customer has a public IPv4 address on the CE router WAN, but the > access network is preparing to stop supporting IPv4 in the access > network, and is moving all IPv4 connectivity to DS-Lite. The direction > of transition is towards DS-Lite and away from native IPv4. > > 3. The customer has DS-Lite, doesn't like it, so the provider is > transitioning him to an IPv4 service with a public IPv4 address to the > CE router WAN. The direction of transition is towards native IPv4 and > away from DS-Lite. > > I don't see much of a case for DS-Lite to be transitioned to NAT444 as a > variant on scenario 3. But note that in the case of random bogon > addresses in scenario 1, we really have no idea as to whether the WAN > IPv4 address is public or private. > > And the CE router really has no clue as to why it sees both native IPv4 > and DS-Lite. It just knows that both are there, and needs simple rules > for dealing with the situation. > > Barbara > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From brian.e.carpenter@gmail.com Tue Nov 15 16:00:46 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8903D11E813C for ; Tue, 15 Nov 2011 16:00:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.006 X-Spam-Level: X-Spam-Status: No, score=-101.006 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_RECV_IP_061228=0.895, SARE_RECV_SPAM_DOMN0b=1.666, 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 pw+3mVfrIs3V for ; Tue, 15 Nov 2011 16:00:46 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 148F611E8137 for ; Tue, 15 Nov 2011 16:00:45 -0800 (PST) Received: by ggnr5 with SMTP id r5so3290242ggn.31 for ; Tue, 15 Nov 2011 16:00:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ZRlmszAfHM832aHZ/kQfO77guxis1Sw9aeVPd40l4X4=; b=PrkExsCDd8Fyq4TSLNBSPm+J4shG28Fvuilfws4zE7QmJNM73Cbv9GXncsuuMPsGKM uERYRF1ymzO54AwWt7pJXdMbHw1Q0MkK5j04kz+W9EljuD0XPbTfFcALhCGcWakCO7jh TA3EgF905wR4Aoza9hlNXFsIv3S7H61VBeAE4= Received: by 10.229.80.10 with SMTP id r10mr4270613qck.200.1321401645449; Tue, 15 Nov 2011 16:00:45 -0800 (PST) Received: from [192.168.0.217] (61-230-53-171.dynamic.hinet.net. [61.230.53.171]) by mx.google.com with ESMTPS id t8sm8606999qaz.4.2011.11.15.16.00.42 (version=SSLv3 cipher=OTHER); Tue, 15 Nov 2011 16:00:44 -0800 (PST) Message-ID: <4EC2FD24.1090303@gmail.com> Date: Wed, 16 Nov 2011 13:00:36 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ray Hunter References: <20111115062859.14026.42405.idtracker@ietfa.amsl.com> <4EC2ABA8.4020303@globis.net> In-Reply-To: <4EC2ABA8.4020303@globis.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-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, 16 Nov 2011 00:00:46 -0000 > > 3. "a function to control every node centrally. A site administrator or a service provider could determine or could have an effect on the behavior at their users' hosts." > > The draft seems to assume that routers or network managers are all knowing, and end nodes and end users are dumb. In a model based on mobile handsets connected to alternative (competing) networks, the user probably knows more than the service providers about what policy they want: think WiFi v 4G. I'd thus prefer a model that was more symmetrical, where policy selection and communication of path/topology information were orthogonal. That conversation seems to belong in MIF. It's very close to the conversation in the MIF WG yesterday about draft-chen-mif-happy-eyeballs-extension (which has the property of apparently needing ESP to work properly). Regards Brian From shemant@cisco.com Tue Nov 15 16:32:13 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05BE71F0C7C for ; Tue, 15 Nov 2011 16:32:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.196 X-Spam-Level: X-Spam-Status: No, score=-6.196 tagged_above=-999 required=5 tests=[AWL=0.402, 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 14tRMpp9IlRo for ; Tue, 15 Nov 2011 16:32:09 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id E452C1F0C79 for ; Tue, 15 Nov 2011 16:32:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=6824; q=dns/txt; s=iport; t=1321403529; x=1322613129; h=mime-version:subject:date:message-id:from:to; bh=XIpQvRnkkTRKYqXa/xhpdp2RymhycX4NzbSdzYBqxEQ=; b=ApyMQq8ZOTQbRU5WdtIdIDRVA1sDBbk8zp4dmSsAXom9d6Xit6M95gb9 fWLQNUKkGQfsWNFNVPsoKeYf7vSePFfKadv+GeJEN6wcukHMDjNpHcwWj Oygzg0M2bZCumahviYfmb4bfEAiQ5ehwbNMmpDFA2glyAe4qsyUvPmtsZ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwAAKMDw06tJV2a/2dsb2JhbABDgk2XHZAIgQWBcgEBAQMBEgEJEQNbAQgRBAEBCwYYB0wBAQUEAQQTCBqHYJkdgSYBnlGJLmMEiBORY4xV X-IronPort-AV: E=Sophos;i="4.69,517,1315180800"; d="scan'208,217";a="36335492" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 16 Nov 2011 00:32:08 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pAG0W8uX003639 for ; Wed, 16 Nov 2011 00:32:08 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Nov 2011 18:32:07 -0600 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCA3F7.2C229751" Date: Tue, 15 Nov 2011 18:32:06 -0600 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3035442BC@XMB-RCD-109.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: latest copy of rfc6204bis included Thread-Index: AcyeS0S+2TMx+7qamEebs19h+J+iXAFq6NAA From: "Hemant Singh (shemant)" To: X-OriginalArrivalTime: 16 Nov 2011 00:32:07.0919 (UTC) FILETIME=[2C1C17F0:01CCA3F7] Subject: [v6ops] FW: latest copy of rfc6204bis included X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 Nov 2011 00:32:13 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCA3F7.2C229751 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable For anyone who thinks the IPv6 ND RA's M or the O bits can signal start/stop DHCPv6 to a client, please see this email from our IPv6 CE router design team discussion. It's is bad idea. =20 =20 Hemant =20 From: Wes Beebee (wbeebee)=20 Sent: Wednesday, November 09, 2011 3:19 AM To: Lorenzo Colitti; Hemant Singh (shemant) Cc: Wojciech Dec (wdec); cpe-router@external.cisco.com; Erik Kline; John Jason Brzozowski Subject: Re: latest copy of rfc6204bis included =20 Lorenzo - >> I don't see any text that requires the CE router not to do DHCPv6 PD if M=3D0=20 >> and O=3D0. Where is it? The reason you do not see such text is that we don't want to introduce anything deliberately in RFC 6204bis that will explicitly break in the multi-homing case. Even though it's "out of scope" - we don't want to invalidate the whole document when it becomes "in scope". For example, imagine a case where a home router is connected to a hub and to two modems which go to two different service providers. One provider sets M=3DO=3D0 and the other provider sets M=3DO=3D1. If = setting M=3DO=3D0 turns off DHCPv6 and M=3DO=3D1 triggers a reinitialization, then imagine = the case where each service provider sets the RA interval to 1 second and the RA's come in alternating every 0.5 second. In that case, the CE router will be re-doing DHCPv6 every second and will create a DHCPv6 storm for the service provider. That's why we explicitly don't re-trigger or turn off/on DHCPv6 based on some trigger. All that we say is that in the case of M=3DO=3D1, the CE router MUST do DHCPv6 by default. That's all that needs to be said, and that's all that can be said. - Wes=20 ------_=_NextPart_001_01CCA3F7.2C229751 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: latest copy of rfc6204bis = included

For anyone who thinks the IPv6 ND RA’s M or the O bits can = signal start/stop DHCPv6 to a client, please see this email from our = IPv6 CE router design team discussion.  It’s is bad = idea. 

 

Hemant

 

From:= = Wes Beebee (wbeebee)
Sent: Wednesday, November 09, 2011 3:19 = AM
To: Lorenzo Colitti; Hemant Singh (shemant)
Cc: = Wojciech Dec (wdec); cpe-router@external.cisco.com; Erik Kline; John = Jason Brzozowski
Subject: Re: latest copy of rfc6204bis = included

 

Lorenzo = -

>> I don't see any text that = requires the CE router not to do DHCPv6 PD if M=3D0
>> and = O=3D0. Where is it?

The reason = you do not see such text is that we don’t want to introduce = anything deliberately in RFC 6204bis that will explicitly break in the = multi-homing case.  Even though it’s “out of = scope” - we don’t want to invalidate the whole document when = it becomes “in scope”.

For example, imagine a case = where a home router is connected to a hub and to two modems which go to = two different service providers.  One provider sets M=3DO=3D0 and = the other provider sets M=3DO=3D1.  If setting M=3DO=3D0 turns off = DHCPv6 and M=3DO=3D1 triggers a reinitialization, then imagine the case = where each service provider sets the RA interval to 1 second and the = RA’s come in alternating every 0.5 second.  In that case, the = CE router will be re-doing DHCPv6 every second and will create a DHCPv6 = storm for the service provider.

That’s why we explicitly = don’t re-trigger or turn off/on DHCPv6 based on some trigger. =  All that we say is that in the case of M=3DO=3D1, the CE router = MUST do DHCPv6 by default.  That’s all that needs to be said, = and that’s all that can be said.

- Wes =

------_=_NextPart_001_01CCA3F7.2C229751-- From victor.kuarsingh@gmail.com Tue Nov 15 17:56:30 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0464B11E816B for ; Tue, 15 Nov 2011 17:56:30 -0800 (PST) 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.099, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=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 zcuuslEu1sfA for ; Tue, 15 Nov 2011 17:56:26 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id F0CBD11E8166 for ; Tue, 15 Nov 2011 17:56:25 -0800 (PST) Received: by vws5 with SMTP id 5so8342811vws.31 for ; Tue, 15 Nov 2011 17:56:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding; bh=meV54oJqJZ9cSXXvZqYIPyIc40JeLZC4vOyyUbX0jvY=; b=X/Hm6VDfw7JKOHS9y4/cvGyRSYRtWme1PTfh2xoguIGVjMiGwSlYm0XU/vXCbxN+u+ vfWFMJW+AmEkazH+FFDLLhj3b7mnlqLqHwWRkqzrQe2cZLQzuRkLkq85VdJnyBaIOXE5 izpewrgRjf6NSylFxpkzLOiQnmb2l9F2gPIEc= Received: by 10.52.33.69 with SMTP id p5mr46792500vdi.78.1321408585441; Tue, 15 Nov 2011 17:56:25 -0800 (PST) Received: from [130.129.22.223] (dhcp-16df.meeting.ietf.org. [130.129.22.223]) by mx.google.com with ESMTPS id w5sm5383368vdh.17.2011.11.15.17.56.20 (version=SSLv3 cipher=OTHER); Tue, 15 Nov 2011 17:56:24 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Wed, 16 Nov 2011 09:56:15 +0800 From: Victor Kuarsingh To: Mark Townsley , Brian E Carpenter Message-ID: Thread-Topic: [v6ops] 6rd Sunsetting In-Reply-To: <7CABAB61-E3D3-4C68-91BA-621A5CA0DE51@townsley.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Alexandre Cassen , "v6ops@ietf.org WG" , Claire Cheng Subject: Re: [v6ops] 6rd Sunsetting X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 Nov 2011 01:56:30 -0000 Mark, In section 5 (Sunsetting without renumbering), the impacts on the routing environment may be needed in the discussion. As an example, when we developed our routing architecture for IPv6, it did not follow how IPv4 prefixes/blocks were distributed in the network due to limitations of how IPv4 had to go out. So, if the CE needs to retain the PD (as calculated by 6rd), then this may have impacts (considerations) on the IPv6 routing architecture. I am not saying this is bad or good, but should be considered. An operator may need to make changes upfront to keep routing aggregation intact. Regards, Victor K On 11-11-15 5:37 PM, "Mark Townsley" wrote: > >On Nov 15, 2011, at 5:13 PM, Brian E Carpenter wrote: > >> Mark, >> >> I will read the draft when a calm moment arrives. But I have to ask, >> what is its relationship to RFC 6264? That already includes 6rd >> as one option in the path to v6ness. > >This is very specific for 6rd to native (no CGN, ds-lite, etc), and, >importantly, includes specific requirements for CPE implementors. >Relevant as 6204-bis has brought 6rd into its scope. > >I look forward to your review, and whether it is in conflict in anyway >with 6264 in your mind. > >- Mark > >> >> Regards >> Brian >> >> On 2011-11-15 21:46, Mark Townsley wrote: >>> On Nov 15, 2011, at 4:17 PM, Hans Liu wrote: >>> >>>> Excuse me Mark, I still don't have an idea in what kind of use case >>>> should we have 6rd and Native Dual Stack at the same time in the >>>> network? >>> >>> Incremental transition from 6rd to native. >>> >>> - Mark >>> >>>> Regards, >>>> Hans >>>> >>>> On Tue, Nov 15, 2011 at 4:01 PM, Mark Townsley >>>>wrote: >>>>> Alexandre and I just finished up a -00 that describes two methods >>>>>for moving >>>>> a 6rd deployment to native IPv6. Apologies for not getting this out >>>>>before >>>>> the meeting. >>>>> http://www.ietf.org/id/draft-townsley-v6ops-6rd-sunsetting-00.txt >>>>> >>>>> Abstract >>>>> >>>>> This document provides guidelines for transitioning an IPv6 >>>>> deployment using IPv6 Rapid Deployment (6rd) to an IPv6 deployment >>>>> using Native IPv6. It is targeted at both 6rd operators and 6rd >>>>> implementors." >>>>> >>>>> - Mark >>>>> _______________________________________________ >>>>> v6ops mailing list >>>>> v6ops@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>> >>>>> >>>> >>>> >>>> -- >>>> Instead of following the fashion, we lead it through. >>> >>> _______________________________________________ >>> 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 victor.kuarsingh@gmail.com Tue Nov 15 18:00:47 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A75E011E8156 for ; Tue, 15 Nov 2011 18:00:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=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 LY+LV0u6yocK for ; Tue, 15 Nov 2011 18:00:43 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id EEE8611E8158 for ; Tue, 15 Nov 2011 18:00:39 -0800 (PST) Received: by vcbfl15 with SMTP id fl15so1322189vcb.31 for ; Tue, 15 Nov 2011 18:00:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding; bh=vNJH2BAZB49d2SIox5oNr/LMui06VarG1+oZLuk3a74=; b=xQqv0OhpIcoaXxhvyXJ6oiIsGKaoP58GujmEsJ3XeTavFfsTBE7AMlhM5b+OjBTH5q I1lUOmSYtKCNtoqnvlhzGf24PnBzwNBw4BFlhU5jJWMWd280XPnKZSC113oYKA5SOl48 /T6Mt+tlSZ23uD2yOt+ruonHaT3d1kv/vVePY= Received: by 10.52.70.167 with SMTP id n7mr47086820vdu.67.1321408837806; Tue, 15 Nov 2011 18:00:37 -0800 (PST) Received: from [130.129.22.223] (dhcp-16df.meeting.ietf.org. [130.129.22.223]) by mx.google.com with ESMTPS id co10sm5002382vdc.0.2011.11.15.18.00.33 (version=SSLv3 cipher=OTHER); Tue, 15 Nov 2011 18:00:37 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Wed, 16 Nov 2011 10:00:28 +0800 From: Victor Kuarsingh To: Mark Townsley , Brian E Carpenter Message-ID: Thread-Topic: [v6ops] 6rd Sunsetting In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Alexandre Cassen , "v6ops@ietf.org WG" , Claire Cheng Subject: Re: [v6ops] 6rd Sunsetting X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 Nov 2011 02:00:47 -0000 Mark, At second pass, I noticed you actually addressed this in section 5, subsection 5/6. I missed this nuance at first pass - sorry. Regards, Victor K On 11-11-16 9:56 AM, "Victor Kuarsingh" wrote: >Mark, > >In section 5 (Sunsetting without renumbering), the impacts on the routing >environment may be needed in the discussion. > >As an example, when we developed our routing architecture for IPv6, it did >not follow how IPv4 prefixes/blocks were distributed in the network due to >limitations of how IPv4 had to go out. > >So, if the CE needs to retain the PD (as calculated by 6rd), then this may >have impacts (considerations) on the IPv6 routing architecture. I am not >saying this is bad or good, but should be considered. An operator may >need to make changes upfront to keep routing aggregation intact. > >Regards, > >Victor K > >On 11-11-15 5:37 PM, "Mark Townsley" wrote: > >> >>On Nov 15, 2011, at 5:13 PM, Brian E Carpenter wrote: >> >>> Mark, >>> >>> I will read the draft when a calm moment arrives. But I have to ask, >>> what is its relationship to RFC 6264? That already includes 6rd >>> as one option in the path to v6ness. >> >>This is very specific for 6rd to native (no CGN, ds-lite, etc), and, >>importantly, includes specific requirements for CPE implementors. >>Relevant as 6204-bis has brought 6rd into its scope. >> >>I look forward to your review, and whether it is in conflict in anyway >>with 6264 in your mind. >> >>- Mark >> >>> >>> Regards >>> Brian >>> >>> On 2011-11-15 21:46, Mark Townsley wrote: >>>> On Nov 15, 2011, at 4:17 PM, Hans Liu wrote: >>>> >>>>> Excuse me Mark, I still don't have an idea in what kind of use case >>>>> should we have 6rd and Native Dual Stack at the same time in the >>>>> network? >>>> >>>> Incremental transition from 6rd to native. >>>> >>>> - Mark >>>> >>>>> Regards, >>>>> Hans >>>>> >>>>> On Tue, Nov 15, 2011 at 4:01 PM, Mark Townsley >>>>>wrote: >>>>>> Alexandre and I just finished up a -00 that describes two methods >>>>>>for moving >>>>>> a 6rd deployment to native IPv6. Apologies for not getting this out >>>>>>before >>>>>> the meeting. >>>>>> http://www.ietf.org/id/draft-townsley-v6ops-6rd-sunsetting-00.txt >>>>>> >>>>>> Abstract >>>>>> >>>>>> This document provides guidelines for transitioning an IPv6 >>>>>> deployment using IPv6 Rapid Deployment (6rd) to an IPv6 deployment >>>>>> using Native IPv6. It is targeted at both 6rd operators and 6rd >>>>>> implementors." >>>>>> >>>>>> - Mark >>>>>> _______________________________________________ >>>>>> v6ops mailing list >>>>>> v6ops@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Instead of following the fashion, we lead it through. >>>> >>>> _______________________________________________ >>>> 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 brian.e.carpenter@gmail.com Tue Nov 15 18:02:03 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAB0811E8177 for ; Tue, 15 Nov 2011 18:02:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.546 X-Spam-Level: X-Spam-Status: No, score=-103.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VFrOV3WI7Idx for ; Tue, 15 Nov 2011 18:02:02 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 88D3C11E815F for ; Tue, 15 Nov 2011 18:02:02 -0800 (PST) Received: by ggnr5 with SMTP id r5so3400863ggn.31 for ; Tue, 15 Nov 2011 18:02:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=NE2IPa0c9tM2kTXydn2qMwZ4IHkhUAxJVXhRQ8SncEw=; b=aurGQ3diX1tFYbSez6yzo70HmayJhhbQBJqGi/LMPxeD0MuKLjHX/eKuXyvhq8Xnal n8/A2s0gQ+sT1EIoLd42wfTEK/nbuWUZbBrlykrgzOsIgGCH0RlLKocPFjm+3ccjt698 mD7SPIUWqvMAxNy+kgcO6H4QxN+bIoLIRd9sk= Received: by 10.229.67.213 with SMTP id s21mr4586118qci.89.1321408922009; Tue, 15 Nov 2011 18:02:02 -0800 (PST) Received: from [130.129.19.92] (dhcp-135c.meeting.ietf.org. [130.129.19.92]) by mx.google.com with ESMTPS id ho10sm5739787qab.11.2011.11.15.18.02.00 (version=SSLv3 cipher=OTHER); Tue, 15 Nov 2011 18:02:01 -0800 (PST) Message-ID: <4EC31993.6080708@gmail.com> Date: Wed, 16 Nov 2011 15:01:55 +1300 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=UTF-8 Content-Transfer-Encoding: 7bit Subject: [v6ops] Small comments on draft-ietf-v6ops-v6nd-problems X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 Nov 2011 02:02:04 -0000 > 6.2. Appropriate Subnet Sizing. > > By sizing subnets to reflect the number of addresses actually in use, > the problem can be avoided. For example, [RFC6164] recommends sizing > the subnets for inter-router links to only have 2 addresses (a /127). > It is worth noting that this practice is common in IPv4 networks, in > part to protect against the harmful effects of ARP request flooding. There seems to be a point missing here. The majority of subnets, i.e. all subnets operating SLAAC, are constrained to be /64, so this advice cannot be followed for them. It can only apply to specialised subnets where SLAAC is not used. As a more general comment, maybe an informative reference somewhere to RFC 5157 would be useful. It talks about the kind of scanning attack that might be mounted. Brian From rkitindi@gmail.com Tue Nov 15 18:06:18 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B41D111E8158 for ; Tue, 15 Nov 2011 18:06:18 -0800 (PST) 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 AaVCw9+stKNx for ; Tue, 15 Nov 2011 18:06:14 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id EA6C81F0C99 for ; Tue, 15 Nov 2011 18:06:09 -0800 (PST) Received: by vws5 with SMTP id 5so8351780vws.31 for ; Tue, 15 Nov 2011 18:06:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WLHedoWyrYwi0QsDvfdPnr/46hUEtB3iGKiZaTO2taI=; b=JLfJ6iEkNxG7f4MtGeejbPXkVbH18ekFVnac2IaRsBjc54ykhqTqVA1pkchYJpD326 /Tg8rhFRqJaylTkbtSqTymceOAkg/Lg/Y29QeOygTEJhHE/qmdn7crI5lrNE7+vCuWwy +QHAxm4tQmK0fDbHZKtEmxzFxe87GOlbm5u4o= MIME-Version: 1.0 Received: by 10.224.17.148 with SMTP id s20mr19582181qaa.55.1321409168801; Tue, 15 Nov 2011 18:06:08 -0800 (PST) Received: by 10.229.149.1 with HTTP; Tue, 15 Nov 2011 18:06:08 -0800 (PST) In-Reply-To: <4EC31993.6080708@gmail.com> References: <4EC31993.6080708@gmail.com> Date: Wed, 16 Nov 2011 05:06:08 +0300 Message-ID: From: rajabu kitindi To: Brian E Carpenter Content-Type: multipart/alternative; boundary=bcaec51b15e91bff8804b1d08c3a Cc: IPv6 Operations Subject: Re: [v6ops] Small comments on draft-ietf-v6ops-v6nd-problems X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 Nov 2011 02:06:19 -0000 --bcaec51b15e91bff8804b1d08c3a Content-Type: text/plain; charset=ISO-8859-1 Just a question, IPv6 was designed for 64-bits network and 64-bits host, which makes largest prefix length to be /64. Does using /127 prefix length requires IPv6 format modification in any way? /Rajabu On Wed, Nov 16, 2011 at 5:01 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > > 6.2. Appropriate Subnet Sizing. > > > > By sizing subnets to reflect the number of addresses actually in use, > > the problem can be avoided. For example, [RFC6164] recommends sizing > > the subnets for inter-router links to only have 2 addresses (a /127). > > It is worth noting that this practice is common in IPv4 networks, in > > part to protect against the harmful effects of ARP request flooding. > > There seems to be a point missing here. The majority of subnets, i.e. > all subnets operating SLAAC, are constrained to be /64, so this advice > cannot be followed for them. It can only apply to specialised subnets > where SLAAC is not used. > > As a more general comment, maybe an informative reference somewhere > to RFC 5157 would be useful. It talks about the kind of scanning attack > that might be mounted. > > Brian > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > -- MOTD: When we stop to think, we often miss our opportunity --bcaec51b15e91bff8804b1d08c3a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Just a question, IPv6 was designed for 64-bits network and 64-bits host, wh= ich makes largest prefix length to be /64. Does using /127 prefix length re= quires IPv6 format modification in any way?

/Rajabu

On Wed, Nov 16, 2011 at 5:01 AM, Brian E Car= penter <brian.e.carpenter@gmail.com> wrote:
> 6.2. =A0Appropriate Subnet Sizing.
>
> =A0 =A0By sizing subnets to reflect the number of addresses actually i= n use,
> =A0 =A0the problem can be avoided. =A0For example, [RFC6164] recommend= s sizing
> =A0 =A0the subnets for inter-router links to only have 2 addresses (a = /127).
> =A0 =A0It is worth noting that this practice is common in IPv4 network= s, in
> =A0 =A0part to protect against the harmful effects of ARP request floo= ding.

There seems to be a point missing here. The majority of subnets, i.e.
all subnets operating SLAAC, are constrained to be /64, so this advice
cannot be followed for them. It can only apply to specialised subnets
where SLAAC is not used.

As a more general comment, maybe an informative reference somewhere
to RFC 5157 would be useful. It talks about the kind of scanning attack
that might be mounted.

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



--
MOTD: When w= e stop to think, we often miss our opportunity
--bcaec51b15e91bff8804b1d08c3a-- From shemant@cisco.com Tue Nov 15 18:07:06 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A941011E8179 for ; Tue, 15 Nov 2011 18:07:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.901 X-Spam-Level: X-Spam-Status: No, score=-5.901 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 lafS79uEXFS3 for ; Tue, 15 Nov 2011 18:07:02 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6CA3611E818E for ; Tue, 15 Nov 2011 18:07:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=14456; q=dns/txt; s=iport; t=1321409222; x=1322618822; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=Uj6xijkY8vFn0SwWIoGExqPBgWwD0ahrT9GVFIFAm9U=; b=EhJ6u7S4s0sD20mkcsw40RJxOfvzySHHwtdr7RNN1+cVYjApdgjeeSz0 XAb4glqivrGRcrbfrmjX1/Iug5ntGZO7S+QcvgT9R1BGW5CwB1crGI+F4 IadIp9yODglYrGZgjRFN2NrOrmxBPq3ugWvcFXvmJuLUTDooelzmcY/6X Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwAACEaw06tJV2a/2dsb2JhbABDgk2XHZAIgQWBcgEBAQMBEgEJEQNJEAIBCBEEAQELBhcBBgFFCAEIAQEEARIIGodgmjgBnlKJLmMEiBORY4xV X-IronPort-AV: E=Sophos;i="4.69,518,1315180800"; d="scan'208,217";a="36354796" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 16 Nov 2011 02:07:02 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pAG271lT015144 for ; Wed, 16 Nov 2011 02:07:01 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Nov 2011 20:07:01 -0600 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCA404.6DADD0D5" Date: Tue, 15 Nov 2011 20:06:59 -0600 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C30354430D@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3035442BC@XMB-RCD-109.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] FW: latest copy of rfc6204bis included Thread-Index: AcyeS0S+2TMx+7qamEebs19h+J+iXAFq6NAAAAKwXVA= References: <5B6B2B64C9FE2A489045EEEADDAFF2C3035442BC@XMB-RCD-109.cisco.com> From: "Hemant Singh (shemant)" To: "Hemant Singh (shemant)" , X-OriginalArrivalTime: 16 Nov 2011 02:07:01.0317 (UTC) FILETIME=[6DA3AF50:01CCA404] Cc: "Mark Townsley \(townsley\)" Subject: Re: [v6ops] FW: latest copy of rfc6204bis included X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 Nov 2011 02:07:06 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCA404.6DADD0D5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Mark, =20 We should stop harking at rfc6204 that the document made quite a few mistake. Doesn't fly - the delta between rfc6204 and rfc6204bis that is not transition tech is minor tweaks. The DHCPv6 server storm problem raised recently by Comcast is a not any mistake in RFC 6204. What can an IPv6 CE router document do changing the DHC or the ND protocols? Further, I, Wes Beebee and Ole have already said several times the M and the O bits in the RA just can't be used to signal start/stop to a DHCv6 client. See use case below. =20 =20 Also, at the last IETF it was v6ops who told us to fasttrack transition tech in rfc6204bis and ship a new copy out ASAP. So why are we thrashing at this IETF for this goal? =20 Further, the rfc6204bis document is already good for 6rd sunsetting, so what specifically do we need from your new draft? You new draft is also in conflict with rfc6204bis. Your document includes the text below shown between squared braces. =20 [A 6rd CE MUST assign a forwarding metric such that native IPv6 egress is preferred for traffic outside the 6rd domain when 6rd and native IPv6 interfaces are active.] =20 Sunsetting 6rd involves concurrent operation of 6rd and native IPv6. In such an operation the switching in the IPv6 CE router is source-based routing while your text above speaks of destination based routing. Our document says =20 [5. Selection of 6rd tunnel or native IPv6 output interface on the CE router is determined by the source IPv6 address of the packet from a host.] =20 Hemant =20 From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Hemant Singh (shemant) Sent: Wednesday, November 16, 2011 8:32 AM To: v6ops@ietf.org Subject: [v6ops] FW: latest copy of rfc6204bis included =20 For anyone who thinks the IPv6 ND RA's M or the O bits can signal start/stop DHCPv6 to a client, please see this email from our IPv6 CE router design team discussion. It's is bad idea. =20 =20 Hemant =20 From: Wes Beebee (wbeebee)=20 Sent: Wednesday, November 09, 2011 3:19 AM To: Lorenzo Colitti; Hemant Singh (shemant) Cc: Wojciech Dec (wdec); cpe-router@external.cisco.com; Erik Kline; John Jason Brzozowski Subject: Re: latest copy of rfc6204bis included =20 Lorenzo - >> I don't see any text that requires the CE router not to do DHCPv6 PD if M=3D0=20 >> and O=3D0. Where is it? The reason you do not see such text is that we don't want to introduce anything deliberately in RFC 6204bis that will explicitly break in the multi-homing case. Even though it's "out of scope" - we don't want to invalidate the whole document when it becomes "in scope". For example, imagine a case where a home router is connected to a hub and to two modems which go to two different service providers. One provider sets M=3DO=3D0 and the other provider sets M=3DO=3D1. If = setting M=3DO=3D0 turns off DHCPv6 and M=3DO=3D1 triggers a reinitialization, then imagine = the case where each service provider sets the RA interval to 1 second and the RA's come in alternating every 0.5 second. In that case, the CE router will be re-doing DHCPv6 every second and will create a DHCPv6 storm for the service provider. That's why we explicitly don't re-trigger or turn off/on DHCPv6 based on some trigger. All that we say is that in the case of M=3DO=3D1, the CE router MUST do DHCPv6 by default. That's all that needs to be said, and that's all that can be said. - Wes=20 ------_=_NextPart_001_01CCA404.6DADD0D5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: latest copy of rfc6204bis = included

Mark,

 

We should stop harking at rfc6204 that the document made quite a few = mistake.  Doesn’t fly – the delta between rfc6204 and = rfc6204bis that is not transition tech is minor tweaks.  The DHCPv6 = server storm problem raised recently by Comcast is a not any mistake in = RFC 6204.  What can an IPv6 CE router document do changing the DHC = or the ND protocols?  Further, I, Wes Beebee and Ole have already = said several times the M and the O bits in the RA just can’t be = used to signal start/stop to a DHCv6 client.  See use case = below. 

 

Also, at the last IETF it was v6ops who told us to fasttrack = transition tech in rfc6204bis and ship a new copy out ASAP.  So why = are we thrashing at this IETF for this goal?

 

Further, the rfc6204bis  document is already good for 6rd = sunsetting, so what specifically do we need from your new draft?  = You new draft is also in conflict with rfc6204bis.   Your = document includes the text below shown between squared = braces.

 

[A 6rd CE MUST assign a forwarding metric such that native =
IPv6

egress is preferred = for traffic outside the 6rd domain when 6rd

and native IPv6 interfaces are active.]

 

Sunsetting 6rd involves concurrent operation of 6rd and native = IPv6.  In such an operation the switching in the IPv6 CE router is = source-based routing while your text above speaks of destination based = routing.   Our document says

 

[5.  Selection of 6rd tunnel or native =
IPv6 output interface on the CE

     router is determined by the source IPv6 = address of the packet

     from a host.]

 

Hemant

 

From:= = v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of = Hemant Singh (shemant)
Sent: Wednesday, November 16, 2011 = 8:32 AM
To: v6ops@ietf.org
Subject: [v6ops] FW: = latest copy of rfc6204bis included

 

For anyone who thinks the IPv6 ND RA’s M or the O bits can = signal start/stop DHCPv6 to a client, please see this email from our = IPv6 CE router design team discussion.  It’s is bad = idea. 

 

Hemant

 

From:= = Wes Beebee (wbeebee)
Sent: Wednesday, November 09, 2011 3:19 = AM
To: Lorenzo Colitti; Hemant Singh (shemant)
Cc: = Wojciech Dec (wdec); cpe-router@external.cisco.com; Erik Kline; John = Jason Brzozowski
Subject: Re: latest copy of rfc6204bis = included

 

Lorenzo = -

>> I don't see any text that = requires the CE router not to do DHCPv6 PD if M=3D0
>> and = O=3D0. Where is it?

The reason = you do not see such text is that we don’t want to introduce = anything deliberately in RFC 6204bis that will explicitly break in the = multi-homing case.  Even though it’s “out of = scope” - we don’t want to invalidate the whole document when = it becomes “in scope”.

For example, imagine a case = where a home router is connected to a hub and to two modems which go to = two different service providers.  One provider sets M=3DO=3D0 and = the other provider sets M=3DO=3D1.  If setting M=3DO=3D0 turns off = DHCPv6 and M=3DO=3D1 triggers a reinitialization, then imagine the case = where each service provider sets the RA interval to 1 second and the = RA’s come in alternating every 0.5 second.  In that case, the = CE router will be re-doing DHCPv6 every second and will create a DHCPv6 = storm for the service provider.

That’s why we explicitly = don’t re-trigger or turn off/on DHCPv6 based on some trigger. =  All that we say is that in the case of M=3DO=3D1, the CE router = MUST do DHCPv6 by default.  That’s all that needs to be said, = and that’s all that can be said.

- Wes =

------_=_NextPart_001_01CCA404.6DADD0D5-- From rkitindi@gmail.com Tue Nov 15 18:11:50 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30D9711E818E for ; Tue, 15 Nov 2011 18:11:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 kjj-BA0JXmOE for ; Tue, 15 Nov 2011 18:11:44 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id B4E1321F8DB8 for ; Tue, 15 Nov 2011 18:11:43 -0800 (PST) Received: by ywt34 with SMTP id 34so7173741ywt.31 for ; Tue, 15 Nov 2011 18:11:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=U6c8sOj0B1lmf1qZnSpk5Kz3yVM7V6JuexLMVckOs50=; b=KqyJJajNkJxz26NBAdTjsZE8rT6BqLNJYVyPqQt0riTn0ySwwCfS3z54NSrU1UFNP7 fgyczn5j6chcxVN91WHxv3plweM2jrylU0l6OQRsAwr+T8/xyJ7e3V1APEqiaT6GPv+R eeIJudxl+Iblh3HYJ9s9GWLYvETW4hfx8o6Ow= MIME-Version: 1.0 Received: by 10.229.61.142 with SMTP id t14mr4348170qch.37.1321409503223; Tue, 15 Nov 2011 18:11:43 -0800 (PST) Received: by 10.229.149.1 with HTTP; Tue, 15 Nov 2011 18:11:43 -0800 (PST) In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C30354430D@XMB-RCD-109.cisco.com> References: <5B6B2B64C9FE2A489045EEEADDAFF2C3035442BC@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30354430D@XMB-RCD-109.cisco.com> Date: Wed, 16 Nov 2011 05:11:43 +0300 Message-ID: From: rajabu kitindi To: "Hemant Singh (shemant)" Content-Type: multipart/alternative; boundary=001485ee82ee0ae14b04b1d0a0e9 Cc: "Mark Townsley \(townsley\)" , v6ops@ietf.org Subject: Re: [v6ops] FW: latest copy of rfc6204bis included X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 Nov 2011 02:11:50 -0000 --001485ee82ee0ae14b04b1d0a0e9 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I am going through CPE WAN requirement, reading W - 1, my opinion would be router should not act as a host, stateless IP address allocation on router my be problematic as it does not provide visibility to what IP address has been allocated to which device interface. This brings complications during network troubleshooting. /Rajabu On Wed, Nov 16, 2011 at 5:06 AM, Hemant Singh (shemant) wrote: > Mark,**** > > ** ** > > We should stop harking at rfc6204 that the document made quite a few > mistake. Doesn=92t fly =96 the delta between rfc6204 and rfc6204bis that= is > not transition tech is minor tweaks. The DHCPv6 server storm problem > raised recently by Comcast is a not any mistake in RFC 6204. What can an > IPv6 CE router document do changing the DHC or the ND protocols? Further= , > I, Wes Beebee and Ole have already said several times the M and the O bit= s > in the RA just can=92t be used to signal start/stop to a DHCv6 client. S= ee > use case below. **** > > ** ** > > *Also, at the last IETF it was v6ops who told us to fasttrack transition > tech in rfc6204bis and ship a new copy out ASAP. So why are we thrashing > at this IETF for this goal?* > > ** ** > > Further, the rfc6204bis document is already good for 6rd sunsetting, so > what specifically do we need from your new draft? You new draft is also = in > conflict with rfc6204bis. Your document includes the text below shown > between squared braces.**** > > ** ** > > [A 6rd CE MUST assign a forwarding metric such that native IPv6**** > > egress is preferred for traffic outside the 6rd domain when 6rd**** > > and native IPv6 interfaces are active.]**** > > ** ** > > Sunsetting 6rd involves concurrent operation of 6rd and native IPv6. In > such an operation the switching in the IPv6 CE router is source-based > routing while your text above speaks of destination based routing. Our > document says**** > > ** ** > > [5. Selection of 6rd tunnel or native IPv6 output interface on the CE***= * > > router is determined by the source IPv6 address of the packet**** > > from a host.]**** > > ** ** > > Hemant**** > > ** ** > > *From:* v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] *On Behalf > Of *Hemant Singh (shemant) > *Sent:* Wednesday, November 16, 2011 8:32 AM > *To:* v6ops@ietf.org > *Subject:* [v6ops] FW: latest copy of rfc6204bis included**** > > ** ** > > For anyone who thinks the IPv6 ND RA=92s M or the O bits can signal > start/stop DHCPv6 to a client, please see this email from our IPv6 CE > router design team discussion. It=92s is bad idea. **** > > ** ** > > Hemant**** > > ** ** > > *From:* Wes Beebee (wbeebee) > *Sent:* Wednesday, November 09, 2011 3:19 AM > *To:* Lorenzo Colitti; Hemant Singh (shemant) > *Cc:* Wojciech Dec (wdec); cpe-router@external.cisco.com; Erik Kline; > John Jason Brzozowski > *Subject:* Re: latest copy of rfc6204bis included**** > > ** ** > > Lorenzo - > > >> I don't see any text that requires the CE router not to do DHCPv6 PD i= f > M=3D0 > >> and O=3D0. Where is it? > > The reason you do not see such text is that we don=92t want to introduce > anything deliberately in RFC 6204bis that will explicitly break in the > multi-homing case. Even though it=92s =93out of scope=94 - we don=92t wa= nt to > invalidate the whole document when it becomes =93in scope=94. > > For example, imagine a case where a home router is connected to a hub and > to two modems which go to two different service providers. One provider > sets M=3DO=3D0 and the other provider sets M=3DO=3D1. If setting M=3DO= =3D0 turns off > DHCPv6 and M=3DO=3D1 triggers a reinitialization, then imagine the case w= here > each service provider sets the RA interval to 1 second and the RA=92s com= e in > alternating every 0.5 second. In that case, the CE router will be re-doi= ng > DHCPv6 every second and will create a DHCPv6 storm for the service provid= er. > > That=92s why we explicitly don=92t re-trigger or turn off/on DHCPv6 based= on > some trigger. All that we say is that in the case of M=3DO=3D1, the CE r= outer > MUST do DHCPv6 by default. That=92s all that needs to be said, and that= =92s > all that can be said. > > - Wes **** > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --=20 MOTD: When we stop to think, we often miss our opportunity --001485ee82ee0ae14b04b1d0a0e9 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
I am going through CPE WAN requ= irement, reading W - 1, my opinion would be=A0 router should not act as a h= ost, stateless IP address allocation on router my be problematic as it does= not provide visibility to what IP address has been allocated to which devi= ce interface. This brings complications during network troubleshooting.=A0<= /span>

/Rajabu

On Wed, Nov 16, 2011 at 5:06 AM= , Hemant Singh (shemant) <shemant@cisco.com> wrote:

Mark,

=A0

We sh= ould stop harking at rfc6204 that the document made quite a few mistake. = =A0Doesn=92t fly =96 the delta between rfc6204 and rfc6204bis that is not t= ransition tech is minor tweaks. =A0The DHCPv6 server storm problem raised r= ecently by Comcast is a not any mistake in RFC 6204.=A0 What can an IPv6 CE= router document do changing the DHC or the ND protocols?=A0 Further, I, We= s Beebee and Ole have already said several times the M and the O bits in th= e RA just can=92t be used to signal start/stop to a DHCv6 client.=A0 See us= e case below.=A0

=A0

Also, at the last IETF it was v6ops who told us to fas= ttrack transition tech in rfc6204bis and ship a new copy out ASAP.=A0 So wh= y are we thrashing at this IETF for this goal?

=A0

Further, the rfc6204bis =A0document is already good for 6= rd sunsetting, so what specifically do we need from your new draft?=A0 You = new draft is also in conflict with rfc6204bis. =A0=A0Your document includes= the text below shown between squared braces.

=A0

=
[A 6rd CE MUST assign a forwarding metric such that native IPv6

egress is preferred for traffic outside the 6rd domain whe= n 6rd

and native IPv6 interfaces a= re active.]=

=A0

Sunsetting 6rd involves concurrent operation of 6rd and n= ative IPv6.=A0 In such an operation the switching in the IPv6 CE router is = source-based routing while your text above speaks of destination based rout= ing.=A0=A0 Our document says

=A0

=
[5.=A0 Selection of 6rd=
 tunnel or native IPv6 output interface on the CE

=A0=A0=A0=A0 router is determined by the sourc=
e IPv6 address of the packet
=A0=A0=A0=A0 from a host.]=



=A0
Hemant


=A0
From: v6ops-bounces@ietf=
.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Hemant Singh (shemant)
Sent: Wednesday, November 16, 2011 8:32 AM
To: v6ops@ietf.org
Subject:<=
/b> [v6ops] FW: latest copy of rfc6204bis included


=A0=

F=
or anyone who thinks the IPv6 ND RA=92s M or the O bits can signal start/st=
op DHCPv6 to a client, please see this email from our IPv6 CE router design=
 team discussion.=A0 It=92s is bad idea.=A0 


=A0
Hemant
=A0


Fr=
om: Wes Beebee (wbeebee) 
Sent: Wednesday, November 09, 2011 3:19 AM

To: Lorenzo Colitti; Hemant Singh (shemant)
Cc: Wojciech D=
ec (wdec); cpe-router@external.cisco.com; Erik Kline; John Jason Brzozowski

Subject: Re: latest copy of rfc6204bis included=

=A0
Lorenzo -

>> I don't see any text that requires the CE router no=
t to do DHCPv6 PD if M=3D0 

>> and O=3D0. Where is it?

T=
he reason you do not see such text is that we don=92t want to introduce any=
thing deliberately in RFC 6204bis that will explicitly break in the multi-h=
oming case. =A0Even though it=92s =93out of scope=94 - we don=92t want to i=
nvalidate the whole document when it becomes =93in scope=94.


For example, imagine a case where a home router is connected to a hub a=
nd to two modems which go to two different service providers. =A0One provid=
er sets M=3DO=3D0 and the other provider sets M=3DO=3D1. =A0If setting M=3D=
O=3D0 turns off DHCPv6 and M=3DO=3D1 triggers a reinitialization, then imag=
ine the case where each service provider sets the RA interval to 1 second a=
nd the RA=92s come in alternating every 0.5 second. =A0In that case, the CE=
 router will be re-doing DHCPv6 every second and will create a DHCPv6 storm=
 for the service provider.


That=92s why we explicitly don=92t re-trigger or turn off/on DHCPv6 bas=
ed on some trigger. =A0All that we say is that in the case of M=3DO=3D1, th=
e CE router MUST do DHCPv6 by default. =A0That=92s all that needs to be sai=
d, and that=92s all that can be said.


- Wes

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




--
MOTD: Wh= en we stop to think, we often miss our opportunity
--001485ee82ee0ae14b04b1d0a0e9-- From john_brzozowski@cable.comcast.com Tue Nov 15 18:17:17 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C09EA21F8E12 for ; Tue, 15 Nov 2011 18:17:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.535 X-Spam-Level: X-Spam-Status: No, score=-100.535 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_13=0.6, J_CHICKENPOX_36=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 0zdjQp6j3j2P for ; Tue, 15 Nov 2011 18:17:13 -0800 (PST) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id 3E23221F8E06 for ; Tue, 15 Nov 2011 18:17:13 -0800 (PST) Received: from ([24.40.55.42]) by copdcimo01.cable.comcast.com with ESMTP id 5503630.61612119; Tue, 15 Nov 2011 19:17:17 -0700 Received: from PACDCEXMB01.cable.comcast.com ([fe80::3cf0:9cac:6c2a:7359]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%11]) with mapi id 14.01.0339.001; Tue, 15 Nov 2011 21:17:20 -0500 From: "Brzozowski, John" To: "Hemant Singh (shemant)" , "v6ops@ietf.org" Thread-Topic: [v6ops] FW: latest copy of rfc6204bis included Thread-Index: AcyeS0S+2TMx+7qamEebs19h+J+iXAFq6NAAAAKwXVAAHEi/gA== Date: Wed, 16 Nov 2011 02:17:06 +0000 Message-ID: In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C30354430D@XMB-RCD-109.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [130.129.18.94] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <92E39376201E3745826711A564555F45@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "W. Mark Townsley" Subject: Re: [v6ops] FW: latest copy of rfc6204bis included X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 Nov 2011 02:17:17 -0000 Mistakes with RFC6204 were made from the earliest versions, there is no harm admitting where mistakes were made. In fact, this is healthy to ensure we do not make them again. The DHCPv6 client problem is a mistake in RFC6204 and my concern is that we are/were actively discussing allow it to live on in BIS. Ignoring real world experience and feedback is not part of this process last time I checked. John =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D John Jason Brzozowski Comcast Cable e) mailto:john_brzozowski@cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On 11/16/11 10:06 AM, "Hemant Singh (shemant)" wrote: >Re: latest copy of rfc6204bis includedMark, >=20 >We should stop harking at rfc6204 that the document made quite a few >mistake. Doesn=B9t fly =AD the delta between rfc6204 and rfc6204bis that = is >not transition tech is minor tweaks. The DHCPv6 server storm problem >raised recently by Comcast is a not any mistake in RFC 6204. What can an >IPv6 CE router document do changing the DHC or the ND protocols? >Further, I, Wes Beebee and Ole have already said several times the M and >the O bits in the RA just can=B9t be used to signal start/stop to a DHCv6 >client. See use case below. >=20 >Also, at the last IETF it was v6ops who told us to fasttrack transition >tech in rfc6204bis and ship a new copy out ASAP. So why are we thrashing >at this IETF for this goal? >=20 >Further, the rfc6204bis document is already good for 6rd sunsetting, so >what specifically do we need from your new draft? You new draft is also >in conflict with rfc6204bis. Your document includes the text below >shown between squared braces. >=20 >[A 6rd CE MUST assign a forwarding metric such that native IPv6egress is >preferred for traffic outside the 6rd domain when 6rd >and native IPv6 interfaces are active.] >=20 >Sunsetting 6rd involves concurrent operation of 6rd and native IPv6. In >such an operation the switching in the IPv6 CE router is source-based >routing while your text above speaks of destination based routing. Our >document says >=20 >[5. Selection of 6rd tunnel or native IPv6 output interface on the CE > router is determined by the source IPv6 address of the packet > from a host.] >=20 >Hemant >=20 >From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of >Hemant Singh (shemant) >Sent: Wednesday, November 16, 2011 8:32 AM >To: v6ops@ietf.org >Subject: [v6ops] FW: latest copy of rfc6204bis included > > >=20 >For anyone who thinks the IPv6 ND RA=B9s M or the O bits can signal >start/stop DHCPv6 to a client, please see this email from our IPv6 CE >router design team discussion. It=B9s is bad idea. >=20 >Hemant >=20 >From: Wes Beebee (wbeebee) >Sent: Wednesday, November 09, 2011 3:19 AM >To: Lorenzo Colitti; Hemant Singh (shemant) >Cc: Wojciech Dec (wdec); cpe-router@external.cisco.com; Erik Kline; John >Jason Brzozowski >Subject: Re: latest copy of rfc6204bis included > > >=20 >Lorenzo - > >>> I don't see any text that requires the CE router not to do DHCPv6 PD >>>if M=3D0=20 >>> and O=3D0. Where is it? > >The reason you do not see such text is that we don=B9t want to introduce >anything deliberately in RFC 6204bis that will explicitly break in the >multi-homing case. Even though it=B9s =B3out of scope=B2 - we don=B9t wan= t to >invalidate the whole document when it becomes =B3in scope=B2. > >For example, imagine a case where a home router is connected to a hub and >to two modems which go to two different service providers. One provider >sets M=3DO=3D0 and the other provider sets M=3DO=3D1. If setting M=3DO=3D= 0 turns off >DHCPv6 and M=3DO=3D1 triggers a reinitialization, then imagine the case wh= ere >each service provider sets the RA interval to 1 second and the RA=B9s come >in alternating every 0.5 second. In that case, the CE router will be >re-doing DHCPv6 every second and will create a DHCPv6 storm for the >service provider. > >That=B9s why we explicitly don=B9t re-trigger or turn off/on DHCPv6 based = on >some trigger. All that we say is that in the case of M=3DO=3D1, the CE >router MUST do DHCPv6 by default. That=B9s all that needs to be said, and >that=B9s all that can be said. > >- Wes=20 > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From shemant@cisco.com Tue Nov 15 18:17:19 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E38821F8E13 for ; Tue, 15 Nov 2011 18:17:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.902 X-Spam-Level: X-Spam-Status: No, score=-5.902 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 l593GtL4Msoo for ; Tue, 15 Nov 2011 18:17:15 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 0D02B21F8E11 for ; Tue, 15 Nov 2011 18:17:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=6829; q=dns/txt; s=iport; t=1321409835; x=1322619435; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=Y3Ns3EATK73yd+n3Fy1W59JwO7HIeC68PEcJnpD/PRs=; b=X1kFJ/yd1xA7DYbxaiyOiyOYOgNIWIFOZkEyK6GY4eAPeLdQrDXASM5V IYa0W8kBAFumRviqU/xkbk4kn/ONYsh/9MDhzPx2nDlU4OT0uvBKzi8TU wgDG0t+LgkccfYlIZe8MrHLW1YSBF7NkEZ1N5DGRJ/dwLAS3G5v+HyrJn U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwAABccw06tJV2a/2dsb2JhbABDgk2XHZAIgQWBcgEBAQQSAQkRA0kQAgEIEQQBAQsGFwEGASAlCAEIAQEEEwgaoi4BnlOJLmMEiBORY4UHh04 X-IronPort-AV: E=Sophos;i="4.69,518,1315180800"; d="scan'208,217";a="36348175" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP; 16 Nov 2011 02:17:14 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pAG2HEIq023445; Wed, 16 Nov 2011 02:17:14 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Nov 2011 20:17:14 -0600 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCA405.DAFF7870" Date: Tue, 15 Nov 2011 20:17:12 -0600 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C303544314@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] FW: latest copy of rfc6204bis included Thread-Index: AcykBRZRMw25RhKBRdm6wRpRhUjYaAAABjGw References: <5B6B2B64C9FE2A489045EEEADDAFF2C3035442BC@XMB-RCD-109.cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C30354430D@XMB-RCD-109.cisco.com> From: "Hemant Singh (shemant)" To: "rajabu kitindi" X-OriginalArrivalTime: 16 Nov 2011 02:17:14.0395 (UTC) FILETIME=[DB0FF6B0:01CCA405] Cc: "Mark Townsley \(townsley\)" , v6ops@ietf.org Subject: Re: [v6ops] FW: latest copy of rfc6204bis included X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 Nov 2011 02:17:19 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCA405.DAFF7870 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 =20 From: rajabu kitindi [mailto:rkitindi@gmail.com]=20 Sent: Wednesday, November 16, 2011 10:12 AM To: Hemant Singh (shemant) Cc: v6ops@ietf.org; Mark Townsley (townsley) Subject: Re: [v6ops] FW: latest copy of rfc6204bis included =20 >I am going through CPE WAN requirement, reading W - 1, my opinion would be router should not act as a host, stateless IP >address allocation on router my be problematic as >it does not provide visibility to what IP address has been allocated to >which device interface. This brings complications during network troubleshooting.=20 =20 Go back to years ago in v6ops archive and see this issue has already been put to bed. The DSL BBF asked of this requirement on the CE WAN and it does make sense. Each BNG/DSLAM or a CMTS (both are access concentrators) will support a DAD proxy and thus the SP first-hop IPv6 router does know about any SLAAC address. The WAN interface will issue a DAD probe for the SLAAC address. Further when an interface on a router is acquiring an IPv6 address the interface is acting as a host. =20 Hemant =20 ------_=_NextPart_001_01CCA405.DAFF7870 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

From:= = rajabu kitindi [mailto:rkitindi@gmail.com]
Sent: Wednesday, = November 16, 2011 10:12 AM
To: Hemant Singh = (shemant)
Cc: v6ops@ietf.org; Mark Townsley = (townsley)
Subject: Re: [v6ops] FW: latest copy of rfc6204bis = included

 

>I am going through CPE WAN requirement, reading = W - 1, my opinion would be  router should not act as a host, = stateless IP >address allocation = on router my be problematic as >it does not provide visibility to = what IP address has been allocated to >which device interface. This brings = complications during network troubleshooting. 

 

Go back to years ago in v6ops archive and see this issue has already = been put to bed.  The DSL BBF asked of this requirement on the CE = WAN and it does make sense.  Each BNG/DSLAM or a CMTS  (both = are access concentrators) will support a DAD proxy and thus the SP = first-hop IPv6 router does know about any SLAAC address.  The WAN = interface will issue a DAD probe for the SLAAC address.  Further = when an interface on a router is acquiring an IPv6 address the interface = is acting as a host.

 

Hemant

 

------_=_NextPart_001_01CCA405.DAFF7870-- From shemant@cisco.com Tue Nov 15 18:21:36 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF4E811E815F for ; Tue, 15 Nov 2011 18:21:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.903 X-Spam-Level: X-Spam-Status: No, score=-5.903 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 3EpOA4MXGf+j for ; Tue, 15 Nov 2011 18:21:31 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 898A621F8E44 for ; Tue, 15 Nov 2011 18:21:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=5946; q=dns/txt; s=iport; t=1321410091; x=1322619691; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=D2DoPmMtjxXYBf8VE4XrnLBdYHa8BSON6CBtb7R5ZoQ=; b=UqJHL7TMziPDE4c5owzXQaUBJMfCR/K7sAz2lU210c6Dl6JhlcIQF/r0 QwVbgorG3DXrcDVgGaJ/1JfQDtZAq7mzfIYESUqwzj90iQZWMh4eNrVfI RReCAfLMe3cM7r/d4kkm3KlmTdKZK+CRBMowfyUDcdz6lSj5AIuLI2nfa Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnsAAG4dw06tJV2Y/2dsb2JhbABDgk2XHZAIgQWBcgEBAQQSAQkRA0kQAgEIEQQBAQsGGAYBTQEIAQEEARIIGqIyAZ5UiTRjBIgUkWSMVw X-IronPort-AV: E=Sophos;i="4.69,518,1315180800"; d="scan'208,217";a="36364403" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 16 Nov 2011 02:21:31 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pAG2LVhk014899 for ; Wed, 16 Nov 2011 02:21:31 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Nov 2011 20:21:30 -0600 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCA406.73E9A450" Date: Tue, 15 Nov 2011 20:21:29 -0600 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C303544317@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C30354430D@XMB-RCD-109.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] FW: latest copy of rfc6204bis included Thread-Index: AcyeS0S+2TMx+7qamEebs19h+J+iXAFq6NAAAAKwXVAAAQzw8A== References: <5B6B2B64C9FE2A489045EEEADDAFF2C3035442BC@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30354430D@XMB-RCD-109.cisco.com> From: "Hemant Singh (shemant)" To: "Hemant Singh (shemant)" , X-OriginalArrivalTime: 16 Nov 2011 02:21:30.0959 (UTC) FILETIME=[73FC85F0:01CCA406] Cc: "Mark Townsley \(townsley\)" Subject: Re: [v6ops] FW: latest copy of rfc6204bis included X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 Nov 2011 02:21:36 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCA406.73E9A450 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Mark, =20 From: Hemant Singh (shemant)=20 Sent: Wednesday, November 16, 2011 10:07 AM To: Hemant Singh (shemant); v6ops@ietf.org Cc: Mark Townsley (townsley) Subject: RE: [v6ops] FW: latest copy of rfc6204bis included =20 =20 >We should stop harking at rfc6204 that the document made quite a few mistake. =20 =20 Sorry, Ole told me you were talking about rfc6204bis when speaking of mistakes. Hmm, we authors of the document were only doing what the v6ops WG tells us. From Quebec City the WG told us to add IP transition tech and much before that one Int area AD pointed to Softwires that the rfc6204bis has a Coexistence section to deal with IP transition tech and native IP . We'd be happy to work with you to flush out sunsetting tech for 6rd and native IPv6. =20 =20 Hemant ------_=_NextPart_001_01CCA406.73E9A450 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: latest copy of rfc6204bis = included

Mark,

 

From:= = Hemant Singh (shemant)
Sent: Wednesday, November 16, 2011 = 10:07 AM
To: Hemant Singh (shemant); = v6ops@ietf.org
Cc: Mark Townsley (townsley)
Subject: = RE: [v6ops] FW: latest copy of rfc6204bis = included

 

 

>We should stop harking at rfc6204 that the document made quite a few = mistake.    

 

Sorry, Ole told me you were talking about rfc6204bis when speaking of = mistakes. Hmm, we authors of the document were only doing what the v6ops = WG tells us.  From Quebec City the WG told us to add IP transition = tech and much before that one Int area AD pointed to Softwires that the = rfc6204bis has a Coexistence section to deal with IP transition tech and = native IP .  We’d be happy to work with you to flush out = sunsetting tech for 6rd and native IPv6. 

 

Hemant

------_=_NextPart_001_01CCA406.73E9A450-- From victor.kuarsingh@gmail.com Tue Nov 15 18:22:38 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4381211E818F for ; Tue, 15 Nov 2011 18:22:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.668 X-Spam-Level: X-Spam-Status: No, score=-1.668 tagged_above=-999 required=5 tests=[AWL=-0.665, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_36=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 95v6sa-bZBlO for ; Tue, 15 Nov 2011 18:22:33 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id D53E311E8184 for ; Tue, 15 Nov 2011 18:22:31 -0800 (PST) Received: by vws5 with SMTP id 5so8365711vws.31 for ; Tue, 15 Nov 2011 18:22:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding; bh=I9EkMDXivwnPfeFPdBejfzljO0JVRZILiX1vSawJPmA=; b=n2RvaOss7wXPnW9XBCXwtB3eF0GFpCPL2364gaHDnaAHMMuoZyDvqyboQsa41U2agh FduXfpfm8miwXgLIUI1mp9U1OEHuwkQs6nJdSZwbG+rkZlzhFFJ2xrjAjshiJHYjvJ+W ml1y+9BOufRTXnpeb5xxQ2MMCkf0YtYej+U98= Received: by 10.52.37.129 with SMTP id y1mr47015008vdj.23.1321410149590; Tue, 15 Nov 2011 18:22:29 -0800 (PST) Received: from [130.129.22.223] (dhcp-16df.meeting.ietf.org. [130.129.22.223]) by mx.google.com with ESMTPS id ey9sm40637786vdc.19.2011.11.15.18.22.24 (version=SSLv3 cipher=OTHER); Tue, 15 Nov 2011 18:22:28 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Wed, 16 Nov 2011 10:22:19 +0800 From: Victor Kuarsingh To: "Brzozowski, John" , "Hemant Singh (shemant)" , "v6ops@ietf.org" Message-ID: Thread-Topic: [v6ops] FW: latest copy of rfc6204bis included In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="EUC-KR" Content-transfer-encoding: quoted-printable Cc: "W. Mark Townsley" Subject: Re: [v6ops] FW: latest copy of rfc6204bis included X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 Nov 2011 02:22:38 -0000 I will need to concur with John here. Ignoring real world problems is a mistake. It has taken considerable effort for key operators to move IPv6 programs forward. Having these programs hampered by avoidable issues risks both those deployments from moving forward (bad for all of us), and may dampen others from starting and moving forward. IPv6 needs to go in.. And it needs to work well. If we cannot attain this, and have operational issues related to this it just puts undue pressure operators in the forefront. Regards, Victor K On 11-11-16 10:17 AM, "Brzozowski, John" wrote: >Mistakes with RFC6204 were made from the earliest versions, there is no >harm admitting where mistakes were made. In fact, this is healthy to >ensure we do not make them again. > >The DHCPv6 client problem is a mistake in RFC6204 and my concern is that >we are/were actively discussing allow it to live on in BIS. > >Ignoring real world experience and feedback is not part of this process >last time I checked. > >John >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >John Jason Brzozowski >Comcast Cable >e) mailto:john_brzozowski@cable.comcast.com >o) 609-377-6594 >m) 484-962-0060 >w) http://www.comcast6.net >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > >On 11/16/11 10:06 AM, "Hemant Singh (shemant)" wrote: > >>Re: latest copy of rfc6204bis includedMark, >>=20 >>We should stop harking at rfc6204 that the document made quite a few >>mistake. Doesn=A9=F6t fly =A1=A9 the delta between rfc6204 and rfc6204bis that i= s >>not transition tech is minor tweaks. The DHCPv6 server storm problem >>raised recently by Comcast is a not any mistake in RFC 6204. What can an >>IPv6 CE router document do changing the DHC or the ND protocols? >>Further, I, Wes Beebee and Ole have already said several times the M and >>the O bits in the RA just can=A9=F6t be used to signal start/stop to a DHCv6 >>client. See use case below. >>=20 >>Also, at the last IETF it was v6ops who told us to fasttrack transition >>tech in rfc6204bis and ship a new copy out ASAP. So why are we thrashing >>at this IETF for this goal? >>=20 >>Further, the rfc6204bis document is already good for 6rd sunsetting, so >>what specifically do we need from your new draft? You new draft is also >>in conflict with rfc6204bis. Your document includes the text below >>shown between squared braces. >>=20 >>[A 6rd CE MUST assign a forwarding metric such that native IPv6egress is >>preferred for traffic outside the 6rd domain when 6rd >>and native IPv6 interfaces are active.] >>=20 >>Sunsetting 6rd involves concurrent operation of 6rd and native IPv6. In >>such an operation the switching in the IPv6 CE router is source-based >>routing while your text above speaks of destination based routing. Our >>document says >>=20 >>[5. Selection of 6rd tunnel or native IPv6 output interface on the CE >> router is determined by the source IPv6 address of the packet >> from a host.] >>=20 >>Hemant >>=20 >>From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of >>Hemant Singh (shemant) >>Sent: Wednesday, November 16, 2011 8:32 AM >>To: v6ops@ietf.org >>Subject: [v6ops] FW: latest copy of rfc6204bis included >> >> >>=20 >>For anyone who thinks the IPv6 ND RA=A9=F6s M or the O bits can signal >>start/stop DHCPv6 to a client, please see this email from our IPv6 CE >>router design team discussion. It=A9=F6s is bad idea. >>=20 >>Hemant >>=20 >>From: Wes Beebee (wbeebee) >>Sent: Wednesday, November 09, 2011 3:19 AM >>To: Lorenzo Colitti; Hemant Singh (shemant) >>Cc: Wojciech Dec (wdec); cpe-router@external.cisco.com; Erik Kline; John >>Jason Brzozowski >>Subject: Re: latest copy of rfc6204bis included >> >> >>=20 >>Lorenzo - >> >>>> I don't see any text that requires the CE router not to do DHCPv6 PD >>>>if M=3D0=20 >>>> and O=3D0. Where is it? >> >>The reason you do not see such text is that we don=A9=F6t want to introduce >>anything deliberately in RFC 6204bis that will explicitly break in the >>multi-homing case. Even though it=A9=F6s =A9=F8out of scope=A9=F7 - we don=A9=F6t want t= o >>invalidate the whole document when it becomes =A9=F8in scope=A9=F7. >> >>For example, imagine a case where a home router is connected to a hub and >>to two modems which go to two different service providers. One provider >>sets M=3DO=3D0 and the other provider sets M=3DO=3D1. If setting M=3DO=3D0 turns off >>DHCPv6 and M=3DO=3D1 triggers a reinitialization, then imagine the case where >>each service provider sets the RA interval to 1 second and the RA=A9=F6s come >>in alternating every 0.5 second. In that case, the CE router will be >>re-doing DHCPv6 every second and will create a DHCPv6 storm for the >>service provider. >> >>That=A9=F6s why we explicitly don=A9=F6t re-trigger or turn off/on DHCPv6 based o= n >>some trigger. All that we say is that in the case of M=3DO=3D1, the CE >>router MUST do DHCPv6 by default. That=A9=F6s all that needs to be said, and >>that=A9=F6s all that can be said. >> >>- Wes=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 shemant@cisco.com Tue Nov 15 18:28:11 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A63A721F8E98 for ; Tue, 15 Nov 2011 18:28:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.905 X-Spam-Level: X-Spam-Status: No, score=-5.905 tagged_above=-999 required=5 tests=[AWL=0.094, 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 PoOOjuzmUcnF for ; Tue, 15 Nov 2011 18:28:07 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id A32A221F8EA2 for ; Tue, 15 Nov 2011 18:28:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=1019; q=dns/txt; s=iport; t=1321410487; x=1322620087; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=in3RPNQ1ZLR6fdq+OurK55w1PgodmAwfwyTqu34FGpk=; b=guXy+pSKGpZomDAOk3UsMqLCdQJPDu71XCJeFZwfq68ELSunS7FQz/QC HhxRjJlT27QY4yxJ/6gvebMmrLEeGRQkVQo8mVqCdW2nPn5wD7pZaGntL naR46yG/1luSDZ2h2mowzNAbGTt66ttOsDN3ls2SsAYyiU7V0Fu21Vbvv A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnsAAIofw06tJXHB/2dsb2JhbABDmWqQCIEFgXIBAQEEEgEdCj8MBAIBCBEEAQELBhcBBgFFCAEIAQEEARIIGqJHAZ5ViTRjBIgUkWSMVw X-IronPort-AV: E=Sophos;i="4.69,518,1315180800"; d="scan'208";a="36373510" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-4.cisco.com with ESMTP; 16 Nov 2011 02:27:57 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id pAG2Rv2n032166; Wed, 16 Nov 2011 02:27:57 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Nov 2011 20:27:57 -0600 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Nov 2011 20:27:55 -0600 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C30354431B@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] FW: latest copy of rfc6204bis included Thread-Index: AcyeS0S+2TMx+7qamEebs19h+J+iXAFq6NAAAAKwXVAAHEi/gAAbEqkw References: <5B6B2B64C9FE2A489045EEEADDAFF2C30354430D@XMB-RCD-109.cisco.com> From: "Hemant Singh (shemant)" To: "Brzozowski, John" , X-OriginalArrivalTime: 16 Nov 2011 02:27:57.0494 (UTC) FILETIME=[5A611560:01CCA407] Cc: "Mark Townsley \(townsley\)" Subject: Re: [v6ops] FW: latest copy of rfc6204bis included X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 Nov 2011 02:28:11 -0000 -----Original Message----- From: Brzozowski, John [mailto:John_Brzozowski@Cable.Comcast.com]=20 Sent: Wednesday, November 16, 2011 10:17 AM To: Hemant Singh (shemant); v6ops@ietf.org Cc: Mark Townsley (townsley) Subject: Re: [v6ops] FW: latest copy of rfc6204bis included >Mistakes with RFC6204 were made from the earliest versions, there is no >harm admitting where mistakes were made. In fact, this is healthy to >ensure we do not make them again. >The DHCPv6 client problem is a mistake in RFC6204 and my concern is that >we are/were actively discussing allow it to live on in BIS. I totally don't have a problem admitting to a mistake but for this specific case, it's a problem with protocols that a v6ops document such as rfc6204 does not deal with. We have already acknowledged the Comcast dhcpv6 server storm problem but the problem can't be solved by adding new text related to the M and the O bits to rfc6204bis-02. I personally like Ralph's idea for the MAX_SOL_RT. =20 Hemant From shemant@cisco.com Tue Nov 15 18:32:29 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 673CD11E81C0 for ; Tue, 15 Nov 2011 18:32:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.206 X-Spam-Level: X-Spam-Status: No, score=-6.206 tagged_above=-999 required=5 tests=[AWL=0.393, 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 eHaeTuz5zBSl for ; Tue, 15 Nov 2011 18:32:25 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 3B94911E8107 for ; Tue, 15 Nov 2011 18:32:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=1841; q=dns/txt; s=iport; t=1321410745; x=1322620345; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=jhM2FzOK8TUNdAWcBeVktDrZINDuTvaGAmM+LIhSCfA=; b=maUrpV8bJmXIxasabGkkR0J749npsNkukzlEJ6W2PlMP8rRKbfINEn9A HhihDKtsxaOgjmxSiwMswtlYM30Kb53kQKB90oq8521scGNuYdy6YemAn 9pR4Dj+PfWbBYPjbBXbgu8YulSMooo9M0E2Pss8/X9NHIvc5xPf8tDoeP 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnsAAEkgw06tJXHA/2dsb2JhbABDmWqQCIEFgXIBAQEDARIBHQo/DAQCAQgRBAEBCwYXAQYBICUIAQgBAQQBEggTB4dgmlcBnlWJNGMEiBSRZIUHh1A X-IronPort-AV: E=Sophos;i="4.69,518,1315180800"; d="scan'208";a="36385670" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-7.cisco.com with ESMTP; 16 Nov 2011 02:31:58 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id pAG2Vwpw008870; Wed, 16 Nov 2011 02:31:58 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Nov 2011 20:31:57 -0600 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Nov 2011 20:31:55 -0600 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C30354431D@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] FW: latest copy of rfc6204bis included Thread-Index: AcykBpfOJTAknZMXRIi+MdwoBcCWIgAAOzfw References: From: "Hemant Singh (shemant)" To: "Victor Kuarsingh" , "Brzozowski, John" , X-OriginalArrivalTime: 16 Nov 2011 02:31:57.0878 (UTC) FILETIME=[E9A8C560:01CCA407] Cc: "Mark Townsley \(townsley\)" Subject: Re: [v6ops] FW: latest copy of rfc6204bis included X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 Nov 2011 02:32:29 -0000 Victor, -----Original Message----- From: Victor Kuarsingh [mailto:victor.kuarsingh@gmail.com]=20 Sent: Wednesday, November 16, 2011 10:22 AM To: Brzozowski, John; Hemant Singh (shemant); v6ops@ietf.org Cc: Mark Townsley (townsley) Subject: Re: [v6ops] FW: latest copy of rfc6204bis included >Ignoring real world problems is a mistake. =20 I, Ole, and Wes Beebee have already acknowledged the operational problem. It's the solution were are looking into and some solutions just do not make sense. See this email I sent today included between squared braces below. [Lorenzo - >> I don't see any text that requires the CE router not to do DHCPv6 PD if M=3D0=20 >> and O=3D0. Where is it? The reason you do not see such text is that we don't want to introduce anything deliberately in RFC 6204bis that will explicitly break in the multi-homing case. Even though it's "out of scope" - we don't want to invalidate the whole document when it becomes "in scope". For example, imagine a case where a home router is connected to a hub and to two modems which go to two different service providers. One provider sets M=3DO=3D0 and the other provider sets M=3DO=3D1. If = setting M=3DO=3D0 turns off DHCPv6 and M=3DO=3D1 triggers a reinitialization, then imagine = the case where each service provider sets the RA interval to 1 second and the RA's come in alternating every 0.5 second. In that case, the CE router will be re-doing DHCPv6 every second and will create a DHCPv6 storm for the service provider. That's why we explicitly don't re-trigger or turn off/on DHCPv6 based on some trigger. All that we say is that in the case of M=3DO=3D1, the CE router MUST do DHCPv6 by default. That's all that needs to be said, and that's all that can be said. - Wes] Regards back, Hemant From brian.e.carpenter@gmail.com Tue Nov 15 18:52:03 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23B9911E8164 for ; Tue, 15 Nov 2011 18:52:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.296 X-Spam-Level: X-Spam-Status: No, score=-103.296 tagged_above=-999 required=5 tests=[AWL=-0.297, BAYES_00=-2.599, 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 DrxsSJG6eKBl for ; Tue, 15 Nov 2011 18:51:59 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id D38DA11E8151 for ; Tue, 15 Nov 2011 18:51:58 -0800 (PST) Received: by vws5 with SMTP id 5so8391328vws.31 for ; Tue, 15 Nov 2011 18:51:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=o/H3QIzKU82sbxKpx0j6HRQlu7T0GdYdS/pv/2rw9pg=; b=At45oZmIYOXv7uZyhU/n6RPSJnH7UtWn2CxUA6NUjCgaQPYVxao7FJ053Dx44loBlv bXB6piVlzBBiLKkouWWe6iYN6GopezvaQCxuIsM48NHzsHREGU5k+dbvo6+czUdwtTim c7dxxWbihqM6NgO5Oo5hQ2bi4yueA2lia9zMs= Received: by 10.52.17.112 with SMTP id n16mr46980336vdd.70.1321411918232; Tue, 15 Nov 2011 18:51:58 -0800 (PST) Received: from [130.129.19.92] (dhcp-135c.meeting.ietf.org. [130.129.19.92]) by mx.google.com with ESMTPS id z6sm30639350vdg.18.2011.11.15.18.51.55 (version=SSLv3 cipher=OTHER); Tue, 15 Nov 2011 18:51:57 -0800 (PST) Message-ID: <4EC32547.3070304@gmail.com> Date: Wed, 16 Nov 2011 15:51:51 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: rajabu kitindi References: <4EC31993.6080708@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] Small comments on draft-ietf-v6ops-v6nd-problems X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 Nov 2011 02:52:03 -0000 Rajabu, See RFC 6164 "Using 127-Bit IPv6 Prefixes on Inter-Router Links". Regards Brian On 2011-11-16 15:06, rajabu kitindi wrote: > Just a question, IPv6 was designed for 64-bits network and 64-bits host, > which makes largest prefix length to be /64. Does using /127 prefix length > requires IPv6 format modification in any way? > > /Rajabu > > On Wed, Nov 16, 2011 at 5:01 AM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >>> 6.2. Appropriate Subnet Sizing. >>> >>> By sizing subnets to reflect the number of addresses actually in use, >>> the problem can be avoided. For example, [RFC6164] recommends sizing >>> the subnets for inter-router links to only have 2 addresses (a /127). >>> It is worth noting that this practice is common in IPv4 networks, in >>> part to protect against the harmful effects of ARP request flooding. >> There seems to be a point missing here. The majority of subnets, i.e. >> all subnets operating SLAAC, are constrained to be /64, so this advice >> cannot be followed for them. It can only apply to specialised subnets >> where SLAAC is not used. >> >> As a more general comment, maybe an informative reference somewhere >> to RFC 5157 would be useful. It talks about the kind of scanning attack >> that might be mounted. >> >> Brian >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > > > From rdroms.ietf@gmail.com Tue Nov 15 17:28:40 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDF6F1F0C8E for ; Tue, 15 Nov 2011 17:28:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.202 X-Spam-Level: X-Spam-Status: No, score=-102.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 EuTvRy6QmVXB for ; Tue, 15 Nov 2011 17:28:36 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id C9C3E1F0C92 for ; Tue, 15 Nov 2011 17:28:36 -0800 (PST) Received: by ywt34 with SMTP id 34so7134030ywt.31 for ; Tue, 15 Nov 2011 17:28:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:from:content-type:x-mailer:message-id:date:to :content-transfer-encoding:mime-version; bh=zu392YxCr0sghOCSx4jV9j4U66bW+CeI+LGcleEV9JQ=; b=RkpIYCtDnhqCmupSbVqrbDoh5GBIhjJi1e16eCnaJBM7r/IWzxm6Zgs41fs4PSSSoI nt97R3aebc0SoTg+oX+sW8sVrBptbX+xkiTOMtpT4nS+oag7oYxj9J59iuGvkoC7Ql+F w6ZNuH0p+IICDfsPo8MR5XE8Bqy6a4Pgc+uVw= Received: by 10.100.226.9 with SMTP id y9mr9017919ang.87.1321406916414; Tue, 15 Nov 2011 17:28:36 -0800 (PST) Received: from [10.91.172.169] ([166.137.10.45]) by mx.google.com with ESMTPS id 36sm79859823anz.2.2011.11.15.17.28.33 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 15 Nov 2011 17:28:35 -0800 (PST) From: Ralph Droms Content-Type: multipart/alternative; boundary=Apple-Mail-D183EFF6-B497-4D3D-90BD-D709C8B0A088 X-Mailer: iPhone Mail (9A334) Message-Id: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com> Date: Wed, 16 Nov 2011 09:28:21 +0800 To: "v6ops@ietf.org" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) X-Mailman-Approved-At: Tue, 15 Nov 2011 20:07:39 -0800 Subject: [v6ops] DHCPv6 option for MAX_SOL_RT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 Nov 2011 01:28:40 -0000 --Apple-Mail-D183EFF6-B497-4D3D-90BD-D709C8B0A088 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii ...is here: http://tools.ietf.org/html/draft-droms-dhc-dhcpv6-maxsolrt-updat= e-00 --Apple-Mail-D183EFF6-B497-4D3D-90BD-D709C8B0A088 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=utf-8
--Apple-Mail-D183EFF6-B497-4D3D-90BD-D709C8B0A088-- From shemant@cisco.com Tue Nov 15 20:40:57 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DADF11E812B for ; Tue, 15 Nov 2011 20:40:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.21 X-Spam-Level: X-Spam-Status: No, score=-6.21 tagged_above=-999 required=5 tests=[AWL=0.388, 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 zqY4nPWX-DMD for ; Tue, 15 Nov 2011 20:40:53 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 3F98711E8114 for ; Tue, 15 Nov 2011 20:40:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=8462; q=dns/txt; s=iport; t=1321418453; x=1322628053; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=/qPLKYKc3DqJ1fHUWkt1Y0N2B4goR6B4iRfeW6tonG8=; b=CN4lH9UGqcpueSz0H1+JtWjOG+mfNtzPK1GiNjE3lH1wV2xYHosOYG5u wakzzYJKuXH62LLnRoz+cDQyAC0fFcxkXA50N1OLBz5QNEMtpyDRWbQfW VlA0Txv3eTeuXUuRpc18Dy90qInNJ7sIQoS1Q4qNcJ5KJtgAjuF+sT8L5 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApEAADs+w06tJV2Y/2dsb2JhbABDgk2CNJRpiBUBhmyBBoEFgXIBAQEEEgEJBwoDWQIBCA4DBAEBCwYXAQICAgEBRAkIAQEEARIIGodoml8BjFmRe4kBM2MEiBSRZIM6iR0 X-IronPort-AV: E=Sophos;i="4.69,518,1315180800"; d="scan'208,217";a="36397711" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 16 Nov 2011 04:40:53 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pAG4eqVw010702; Wed, 16 Nov 2011 04:40:52 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Nov 2011 22:40:52 -0600 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCA419.EBD07E0B" Date: Tue, 15 Nov 2011 22:40:50 -0600 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C30354434B@XMB-RCD-109.cisco.com> In-Reply-To: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] DHCPv6 option for MAX_SOL_RT Thread-Index: AcykFVFQjQjxsFbTS8aNBqUvA2ycawABB6mw References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com> From: "Hemant Singh (shemant)" To: "Ralph Droms" , X-OriginalArrivalTime: 16 Nov 2011 04:40:52.0687 (UTC) FILETIME=[EBF6F5F0:01CCA419] Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 Nov 2011 04:40:57 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCA419.EBD07E0B Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 UmFscGgsDQoNCiANCg0KVGhhbmtzIG11Y2ggZm9yIHRoZSBVUkwgdG8gdGhlIGRvYy4gIE9uZSBx dWVzdGlvbiByZWxhdGVkIHRvIHRoaXMgdGV4dCBmcm9tIHRoZSBkb2N1bWVudCBzbmlwcGVkIGJl bG93IGJldHdlZW4gc3F1YXJlZCBicmFjZXMuDQoNCiANCg0KW0lmIHRoZSBESENQdjYgc2VydmVy IGRlY2xpbmVzIHRvIGFzc2lnbiBhbnkgYWRkcmVzc2VzIHRvIGEgY2xpZW50IGluDQoNCmFuIElB X05BIG9yIElBX1RBIG9wdGlvbixdDQoNCiANCg0KVGhlIFdBTiBpbnRlcmZhY2Ugb24gYW4gSVB2 NiBDRSByb3V0ZXIgaXMgdXNpbmcgYW4gdW5udW1iZXJlZCBXQU4gbW9kZWwgYW5kIHRodXMgdGhl IFdBTiBESENQdjYgY2xpZW50IHJlcXVlc3QgbWF5IG9ubHkgaW5jbHVkZSBhbiBJQV9QRCBvcHRp b24uICBUaHVzLCBkb27igJl0IHdlIGhhdmUgdG8gaW5jbHVkZSB0aGUgSUFfUEQgb3B0aW9uIHRv IHRoZSB0ZXh0IGFib3ZlPyAgSWYgeWVzLCB0aGVuIHNvbWUgb3RoZXIgdGV4dCBpbW1lZGlhdGVs eSBiZWxvdyBpbiB0aGUgZG9jdW1lbnQgYWxzbyBjaGFuZ2VzIHRvIGluY2x1ZGUgdGhlIElBX1BE Lg0KDQogDQoNClJlZ2FyZHMsDQoNCiANCg0KSGVtYW50DQoNCiANCg0KRnJvbTogdjZvcHMtYm91 bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBSYWxwaCBEcm9tcw0KU2VudDogV2VkbmVzZGF5LCBOb3ZlbWJlciAxNiwgMjAxMSA5OjI4IEFN DQpUbzogdjZvcHNAaWV0Zi5vcmcNClN1YmplY3Q6IFt2Nm9wc10gREhDUHY2IG9wdGlvbiBmb3Ig TUFYX1NPTF9SVA0KDQogDQoNCg0KLi4uaXMgaGVyZTogaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtZHJvbXMtZGhjLWRoY3B2Ni1tYXhzb2xydC11cGRhdGUtMDAgPGh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWRyb21zLWRoYy1kaGNwdjYtbWF4c29scnQtdXBkYXRlLTAw PiANCg0K ------_=_NextPart_001_01CCA419.EBD07E0B 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 IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0K CW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXtt c28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+ DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGJnY29sb3I9 d2hpdGUgbGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNl Y3Rpb24xPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlJhbHBoLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0 OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+VGhhbmtzIG11Y2ggZm9yIHRoZSBVUkwgdG8gdGhlIGRvYy7CoCBP bmUgcXVlc3Rpb24gcmVsYXRlZCB0byB0aGlzIHRleHQgZnJvbSB0aGUgZG9jdW1lbnQgc25pcHBl ZCBiZWxvdyBiZXR3ZWVuIHNxdWFyZWQgYnJhY2VzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+PHByZSBzdHlsZT0ncGFnZS1icmVhay1iZWZvcmU6YWx3YXlzJz48c3BhbiBzdHls ZT0nY29sb3I6IzFGNDk3RCc+Wzwvc3Bhbj48c3BhbiBsYW5nPUVOPklmIHRoZSBESENQdjYgc2Vy dmVyIGRlY2xpbmVzIHRvIGFzc2lnbiBhbnkgYWRkcmVzc2VzIHRvIGEgY2xpZW50IGluPG86cD48 L286cD48L3NwYW4+PC9wcmU+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4gc3R5bGU9 J2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiBhbiBJQV9OQSBvciBJQV9UQSBvcHRpb24sPC9z cGFuPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOiMxRjQ5N0Qn Pl08bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5UaGUg V0FOIGludGVyZmFjZSBvbiBhbiBJUHY2IENFIHJvdXRlciBpcyB1c2luZyBhbiB1bm51bWJlcmVk IFdBTiBtb2RlbCBhbmQgdGh1cyB0aGUgV0FOIERIQ1B2NiBjbGllbnQgcmVxdWVzdCBtYXkgb25s eSBpbmNsdWRlIGFuIElBX1BEIG9wdGlvbi7CoCBUaHVzLCBkb27igJl0IHdlIGhhdmUgdG8gaW5j bHVkZSB0aGUgSUFfUEQgb3B0aW9uIHRvIHRoZSB0ZXh0IGFib3ZlP8KgIElmIHllcywgdGhlbiBz b21lIG90aGVyIHRleHQgaW1tZWRpYXRlbHkgYmVsb3cgaW4gdGhlIGRvY3VtZW50IGFsc28gY2hh bmdlcyB0byBpbmNsdWRlIHRoZSBJQV9QRC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlJlZ2FyZHMsPG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5 N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMUY0OTdEJz5IZW1hbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w PjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJp ZiInPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPiB2Nm9wcy1ib3VuY2VzQGlldGYub3JnIFttYWls dG86djZvcHMtYm91bmNlc0BpZXRmLm9yZ10gPGI+T24gQmVoYWxmIE9mIDwvYj5SYWxwaCBEcm9t czxicj48Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBOb3ZlbWJlciAxNiwgMjAxMSA5OjI4IEFNPGJy PjxiPlRvOjwvYj4gdjZvcHNAaWV0Zi5vcmc8YnI+PGI+U3ViamVjdDo8L2I+IFt2Nm9wc10gREhD UHY2IG9wdGlvbiBmb3IgTUFYX1NPTF9SVDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz48YnI+Li4uaXMgaGVyZTombmJz cDs8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1kcm9tcy1kaGMtZGhj cHY2LW1heHNvbHJ0LXVwZGF0ZS0wMCI+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5odHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1kcm9tcy1kaGMtZGhjcHY2LW1heHNvbHJ0LXVwZGF0 ZS0wMDwvc3Bhbj48L2E+PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PC9ib2R5PjwvaHRtbD4= ------_=_NextPart_001_01CCA419.EBD07E0B-- From rdroms.ietf@gmail.com Tue Nov 15 20:48:25 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5912311E811C; Tue, 15 Nov 2011 20:48:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.099 X-Spam-Level: X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, 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 E-iG-fGMCtOs; Tue, 15 Nov 2011 20:48:21 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 28C9C11E80CC; Tue, 15 Nov 2011 20:48:21 -0800 (PST) Received: by ywt34 with SMTP id 34so7319960ywt.31 for ; Tue, 15 Nov 2011 20:48:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=8RA4qR8MwZzsctzU16FAC2qE+YJF0srkdm3D8ewHt8w=; b=WDvRkJcUaW1/EZbyoebHvy1PmQH0QvW+V+joSUecJIVPkwUdcgOLYfpVd4lw0HThNK CpyfPJZpqK/qAriFXS/OU+KaaQkAO3yZow3Cw1W/RZXDLDwZ4nN9qNYDW9OTmHnjkeL2 I1rUCk0z+/hQovLiO+R+jTlk8AMh3LHxlr92U= Received: by 10.50.216.134 with SMTP id oq6mr33078721igc.11.1321418897942; Tue, 15 Nov 2011 20:48:17 -0800 (PST) Received: from sjc-vpn5-293.cisco.com (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPS id j1sm21683501igq.2.2011.11.15.20.48.15 (version=SSLv3 cipher=OTHER); Tue, 15 Nov 2011 20:48:17 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Ralph Droms In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C30354434B@XMB-RCD-109.cisco.com> Date: Wed, 16 Nov 2011 12:48:12 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30354434B@XMB-RCD-109.cisco.com> To: "Hemant Singh (shemant)" X-Mailer: Apple Mail (2.1251.1) Cc: "dhcwg@ietf.org WG" , IPv6 Operations , Ralph Droms Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 Nov 2011 04:48:25 -0000 Yeah, the text should probably refer to IA_PD as well. Forwarding to = dhc WG as well for comment before I make a change. - Ralph On Nov 16, 2011, at 12:40 PM 11/16/11, Hemant Singh (shemant) wrote: > Ralph, > =20 > Thanks much for the URL to the doc. One question related to this text = from the document snipped below between squared braces. > =20 > [If the DHCPv6 server declines to assign any addresses to a client in > an IA_NA or IA_TA option,] > =20 > The WAN interface on an IPv6 CE router is using an unnumbered WAN = model and thus the WAN DHCPv6 client request may only include an IA_PD = option. Thus, don=92t we have to include the IA_PD option to the text = above? If yes, then some other text immediately below in the document = also changes to include the IA_PD. > =20 > Regards, > =20 > Hemant > =20 > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Ralph Droms > Sent: Wednesday, November 16, 2011 9:28 AM > To: v6ops@ietf.org > Subject: [v6ops] DHCPv6 option for MAX_SOL_RT > =20 >=20 > ...is here: = http://tools.ietf.org/html/draft-droms-dhc-dhcpv6-maxsolrt-update-00 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From rkitindi@gmail.com Tue Nov 15 20:57:29 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 347E31F0CC8 for ; Tue, 15 Nov 2011 20:57:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.098 X-Spam-Level: X-Spam-Status: No, score=-3.098 tagged_above=-999 required=5 tests=[AWL=-0.100, 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 QRugWRStE7VW for ; Tue, 15 Nov 2011 20:57:25 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id D70041F0CC5 for ; Tue, 15 Nov 2011 20:57:24 -0800 (PST) Received: by vcbfl15 with SMTP id fl15so79822vcb.31 for ; Tue, 15 Nov 2011 20:57:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/YR+fQFMm8BRb6QCwK63BmWgeiZ8/nwdGhFOOMjXCl8=; b=vFEEyXI3fnpxnUvNRzGlr4R12yoKJvD+cAMN4495w1APXPed6beyn3wbrBqeZHvlxV 69hMjYuveL3PXbrNThbv3O2IkFLTQbECclTWgra7LlIFCUU0xkZAyt4mFSyI+MQURHB6 +8JaoYFxUgHiqqg9gV/xjrLeGUherEFSEzXWo= MIME-Version: 1.0 Received: by 10.229.61.142 with SMTP id t14mr4374229qch.37.1321419442999; Tue, 15 Nov 2011 20:57:22 -0800 (PST) Received: by 10.229.149.1 with HTTP; Tue, 15 Nov 2011 20:57:22 -0800 (PST) Received: by 10.229.149.1 with HTTP; Tue, 15 Nov 2011 20:57:22 -0800 (PST) In-Reply-To: <4EC32547.3070304@gmail.com> References: <4EC31993.6080708@gmail.com> <4EC32547.3070304@gmail.com> Date: Wed, 16 Nov 2011 07:57:22 +0300 Message-ID: From: rajabu kitindi To: Brian E Carpenter Content-Type: multipart/alternative; boundary=001485ee82ee7fd32204b1d2f0f7 Cc: IPv6 Operations Subject: Re: [v6ops] Small comments on draft-ietf-v6ops-v6nd-problems X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 Nov 2011 04:57:29 -0000 --001485ee82ee7fd32204b1d2f0f7 Content-Type: text/plain; charset=ISO-8859-1 Thanks /Rajabu On 16 Nov 2011 10:51, "Brian E Carpenter" wrote: > Rajabu, > > See RFC 6164 "Using 127-Bit IPv6 Prefixes on Inter-Router Links". > > Regards > Brian > > On 2011-11-16 15:06, rajabu kitindi wrote: > > Just a question, IPv6 was designed for 64-bits network and 64-bits host, > > which makes largest prefix length to be /64. Does using /127 prefix > length > > requires IPv6 format modification in any way? > > > > /Rajabu > > > > On Wed, Nov 16, 2011 at 5:01 AM, Brian E Carpenter < > > brian.e.carpenter@gmail.com> wrote: > > > >>> 6.2. Appropriate Subnet Sizing. > >>> > >>> By sizing subnets to reflect the number of addresses actually in > use, > >>> the problem can be avoided. For example, [RFC6164] recommends > sizing > >>> the subnets for inter-router links to only have 2 addresses (a > /127). > >>> It is worth noting that this practice is common in IPv4 networks, in > >>> part to protect against the harmful effects of ARP request flooding. > >> There seems to be a point missing here. The majority of subnets, i.e. > >> all subnets operating SLAAC, are constrained to be /64, so this advice > >> cannot be followed for them. It can only apply to specialised subnets > >> where SLAAC is not used. > >> > >> As a more general comment, maybe an informative reference somewhere > >> to RFC 5157 would be useful. It talks about the kind of scanning attack > >> that might be mounted. > >> > >> Brian > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops > >> > > > > > > > --001485ee82ee7fd32204b1d2f0f7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Thanks

/Rajabu

On 16 Nov 2011 10:51, "Brian E Carpenter&qu= ot; <brian.e.carpenter@gm= ail.com> wrote:
Rajabu,

See RFC 6164 "Using 127-Bit IPv6 Prefixes on Inter-Router Links".=

Regards
=A0 Brian

On 2011-11-16 15:06, rajabu kitindi wrote:
> Just a question, IPv6 was designed for 64-bits network and 64-bits hos= t,
> which makes largest prefix length to be /64. Does using /127 prefix le= ngth
> requires IPv6 format modification in any way?
>
> /Rajabu
>
> On Wed, Nov 16, 2011 at 5:01 AM, Brian E Carpenter <
> brian.e.carpenter@gmail= .com> wrote:
>
>>> 6.2. =A0Appropriate Subnet Sizing.
>>>
>>> =A0 =A0By sizing subnets to reflect the number of addresses ac= tually in use,
>>> =A0 =A0the problem can be avoided. =A0For example, [RFC6164] r= ecommends sizing
>>> =A0 =A0the subnets for inter-router links to only have 2 addre= sses (a /127).
>>> =A0 =A0It is worth noting that this practice is common in IPv4= networks, in
>>> =A0 =A0part to protect against the harmful effects of ARP requ= est flooding.
>> There seems to be a point missing here. The majority of subnets, i= .e.
>> all subnets operating SLAAC, are constrained to be /64, so this ad= vice
>> cannot be followed for them. It can only apply to specialised subn= ets
>> where SLAAC is not used.
>>
>> As a more general comment, maybe an informative reference somewher= e
>> to RFC 5157 would be useful. It talks about the kind of scanning a= ttack
>> that might be mounted.
>>
>> =A0 Brian
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
>
>
>
--001485ee82ee7fd32204b1d2f0f7-- From shemant@cisco.com Tue Nov 15 21:02:46 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF6821F0CC7; Tue, 15 Nov 2011 21:02:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.915 X-Spam-Level: X-Spam-Status: No, score=-5.915 tagged_above=-999 required=5 tests=[AWL=0.084, 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 PykT8sWxGaoH; Tue, 15 Nov 2011 21:02:42 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id C78931F0C9B; Tue, 15 Nov 2011 21:02:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=1572; q=dns/txt; s=iport; t=1321419761; x=1322629361; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=yOMF7NGT99yQKkp/gU7JG9HC7O+ih3RndUha1oKlMjQ=; b=LMNZmdQU3fMp2cVmveLdkjPuANj6EeN0M1gyNeqWvfhdNwfCB4ui6LtB BqeYAB69OE7+7LVOby/+c/pBnlPvvKV1saKpJ5myogscw6bcAYixWvnV3 zHWZslOOXSIXNA44tt6rWBo31PoupROgP/0xDFIqQq+O9gUtuPDgzTYkD s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnsAAEVDw06rRDoJ/2dsb2JhbABDmWqQCIEFgXIBAQEDAQEBAQ8BHQo0CwUHBAIBCA4DBAEBCwYXAQYBIAYfCQgBAQQTCBqHYAiaXQGeVYk0YwSIFJFkgzqBTYdQ X-IronPort-AV: E=Sophos;i="4.69,519,1315180800"; d="scan'208";a="14541471" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 16 Nov 2011 05:02:41 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pAG52frt015677; Wed, 16 Nov 2011 05:02:41 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Nov 2011 23:02:41 -0600 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Nov 2011 23:02:37 -0600 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C30354434F@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] DHCPv6 option for MAX_SOL_RT Thread-Index: AcykGvXJ9btRCyV6QUyI2s3Df0IPbAAAfuVw References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30354434B@XMB-RCD-109.cisco.com> From: "Hemant Singh (shemant)" To: "Ralph Droms" X-OriginalArrivalTime: 16 Nov 2011 05:02:41.0151 (UTC) FILETIME=[F7DEB8F0:01CCA41C] Cc: dhcwg@ietf.org, IPv6 Operations Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 Nov 2011 05:02:47 -0000 Great, thanks, Hemant -----Original Message----- From: Ralph Droms [mailto:rdroms.ietf@gmail.com]=20 Sent: Wednesday, November 16, 2011 12:48 PM To: Hemant Singh (shemant) Cc: Ralph Droms; IPv6 Operations; dhcwg@ietf.org WG Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT Yeah, the text should probably refer to IA_PD as well. Forwarding to dhc WG as well for comment before I make a change. - Ralph On Nov 16, 2011, at 12:40 PM 11/16/11, Hemant Singh (shemant) wrote: > Ralph, > =20 > Thanks much for the URL to the doc. One question related to this text from the document snipped below between squared braces. > =20 > [If the DHCPv6 server declines to assign any addresses to a client in > an IA_NA or IA_TA option,] > =20 > The WAN interface on an IPv6 CE router is using an unnumbered WAN model and thus the WAN DHCPv6 client request may only include an IA_PD option. Thus, don't we have to include the IA_PD option to the text above? If yes, then some other text immediately below in the document also changes to include the IA_PD. > =20 > Regards, > =20 > Hemant > =20 > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Ralph Droms > Sent: Wednesday, November 16, 2011 9:28 AM > To: v6ops@ietf.org > Subject: [v6ops] DHCPv6 option for MAX_SOL_RT > =20 >=20 > ...is here: http://tools.ietf.org/html/draft-droms-dhc-dhcpv6-maxsolrt-update-00 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From joelja@bogus.com Tue Nov 15 21:06:40 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAF7B1F0CFF for ; Tue, 15 Nov 2011 21:06:40 -0800 (PST) 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 vVzBv04XH1UH for ; Tue, 15 Nov 2011 21:06:36 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 07CF31F0C9B for ; Tue, 15 Nov 2011 21:06:34 -0800 (PST) Received: from dhcp-2510.meeting.ietf.org (dhcp-2510.meeting.ietf.org [130.129.37.16]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id pAG56S4t018429 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 16 Nov 2011 05:06:31 GMT (envelope-from joelja@bogus.com) Message-ID: <4EC344D2.8080404@bogus.com> Date: Wed, 16 Nov 2011 13:06:26 +0800 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: rajabu kitindi References: <4EC31993.6080708@gmail.com> In-Reply-To: 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, 16 Nov 2011 05:06:32 +0000 (UTC) Cc: IPv6 Operations Subject: Re: [v6ops] Small comments on draft-ietf-v6ops-v6nd-problems X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 Nov 2011 05:06:41 -0000 On 11/16/11 10:06 , rajabu kitindi wrote: > Just a question, IPv6 was designed for 64-bits network and 64-bits host, > which makes largest prefix length to be /64. Does using /127 prefix > length requires IPv6 format modification in any way? No, it does however mean slaac doesn't work... in practical terms hosts and routers support vlsm just fine. see http://tools.ietf.org/html/rfc6164 for detail on /127s... > /Rajabu > > On Wed, Nov 16, 2011 at 5:01 AM, Brian E Carpenter > > wrote: > > > 6.2. Appropriate Subnet Sizing. > > > > By sizing subnets to reflect the number of addresses actually > in use, > > the problem can be avoided. For example, [RFC6164] recommends > sizing > > the subnets for inter-router links to only have 2 addresses (a > /127). > > It is worth noting that this practice is common in IPv4 > networks, in > > part to protect against the harmful effects of ARP request > flooding. > > There seems to be a point missing here. The majority of subnets, i.e. > all subnets operating SLAAC, are constrained to be /64, so this advice > cannot be followed for them. It can only apply to specialised subnets > where SLAAC is not used. > > As a more general comment, maybe an informative reference somewhere > to RFC 5157 would be useful. It talks about the kind of scanning attack > that might be mounted. > > Brian > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > > > -- > MOTD: When we stop to think, we often miss our opportunity > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From joelja@bogus.com Tue Nov 15 21:09:13 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF03021F90B5 for ; Tue, 15 Nov 2011 21:09:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.217 X-Spam-Level: X-Spam-Status: No, score=-102.217 tagged_above=-999 required=5 tests=[AWL=-0.218, 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 krU4hcK6cpOA for ; Tue, 15 Nov 2011 21:09:09 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD4621F90B4 for ; Tue, 15 Nov 2011 21:09:09 -0800 (PST) Received: from dhcp-2510.meeting.ietf.org (dhcp-2510.meeting.ietf.org [130.129.37.16]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id pAG595X4018507 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 16 Nov 2011 05:09:06 GMT (envelope-from joelja@bogus.com) Message-ID: <4EC34570.6040308@bogus.com> Date: Wed, 16 Nov 2011 13:09:04 +0800 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Brian E Carpenter References: <4EC31993.6080708@gmail.com> In-Reply-To: <4EC31993.6080708@gmail.com> 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, 16 Nov 2011 05:09:07 +0000 (UTC) Cc: IPv6 Operations Subject: Re: [v6ops] Small comments on draft-ietf-v6ops-v6nd-problems X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 Nov 2011 05:09:13 -0000 On 11/16/11 10:01 , Brian E Carpenter wrote: >> 6.2. Appropriate Subnet Sizing. >> >> By sizing subnets to reflect the number of addresses actually in use, >> the problem can be avoided. For example, [RFC6164] recommends sizing >> the subnets for inter-router links to only have 2 addresses (a /127). >> It is worth noting that this practice is common in IPv4 networks, in >> part to protect against the harmful effects of ARP request flooding. > > There seems to be a point missing here. The majority of subnets, i.e. > all subnets operating SLAAC, are constrained to be /64, so this advice > cannot be followed for them. It can only apply to specialised subnets > where SLAAC is not used. correct. I can smith the text accordingly to reflect that. > As a more general comment, maybe an informative reference somewhere > to RFC 5157 would be useful. It talks about the kind of scanning attack > that might be mounted. ok > Brian > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From frnkblk@iname.com Tue Nov 15 21:30:33 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4A091F0CAA for ; Tue, 15 Nov 2011 21:30:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, 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 8ZC1x++3Mzku for ; Tue, 15 Nov 2011 21:30:29 -0800 (PST) Received: from premieronline.net (smtp1-2.premieronline.net [96.31.0.22]) by ietfa.amsl.com (Postfix) with ESMTP id 902DA1F0C95 for ; Tue, 15 Nov 2011 21:30:29 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=199.120.69.4; Received: from BULKFAMLAPTOP (unverified [199.120.69.4]) by premieronline.net (SurgeMail 5.0n) with ESMTP (TLS) id 33709312-1729245 for multiple; Tue, 15 Nov 2011 23:08:12 -0600 From: "Frank Bulk" To: "'Hemant Singh \(shemant\)'" References: <5B6B2B64C9FE2A489045EEEADDAFF2C30354431D@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C30354431D@XMB-RCD-109.cisco.com> Date: Tue, 15 Nov 2011 23:08:11 -0600 Message-ID: <000f01cca41d$bcbad730$36308590$@iname.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AcykBpfOJTAknZMXRIi+MdwoBcCWIgAAOzfwAAU6ZOA= Content-Language: en-us X-Authenticated-User: fbulk@premieronline.net X-SpamDetect: : 0.000000 X-Info: aspam skipped due to (g_smite_skip_auth) X-Encryption: SSL encrypted X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=0 Stars=0 Good=15 Friend=4 Surbl=0 Catch=0 r=0 ip=199.120.69.4 X-IP-stats: Incoming Last 0, First 981, in=1570, out=0, spam=0 ip=199.120.69.4 Cc: "Mark Townsley \(townsley\)" , v6ops@ietf.org Subject: Re: [v6ops] FW: latest copy of rfc6204bis included X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 Nov 2011 05:30:33 -0000 Hemant: Bridging two ISPs? That doesn't sound wise, and if that's a real concern (users would do it!), we should spell out what the failure state looks like in the home router, perhaps failing over to a working WAN connection. This hysteresis issue can be addressed by requiring a unique WAN interface (physical or virtual) per ISP so that DHCPv6 Solicit decisions are made independently, on a per-interface basis. Frank -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Hemant Singh (shemant) Sent: Tuesday, November 15, 2011 8:32 PM To: Victor Kuarsingh; Brzozowski, John; v6ops@ietf.org Cc: Mark Townsley (townsley) Subject: Re: [v6ops] FW: latest copy of rfc6204bis included Victor, -----Original Message----- From: Victor Kuarsingh [mailto:victor.kuarsingh@gmail.com] Sent: Wednesday, November 16, 2011 10:22 AM To: Brzozowski, John; Hemant Singh (shemant); v6ops@ietf.org Cc: Mark Townsley (townsley) Subject: Re: [v6ops] FW: latest copy of rfc6204bis included >Ignoring real world problems is a mistake. I, Ole, and Wes Beebee have already acknowledged the operational problem. It's the solution were are looking into and some solutions just do not make sense. See this email I sent today included between squared braces below. [Lorenzo - >> I don't see any text that requires the CE router not to do DHCPv6 PD if M=0 >> and O=0. Where is it? The reason you do not see such text is that we don't want to introduce anything deliberately in RFC 6204bis that will explicitly break in the multi-homing case. Even though it's "out of scope" - we don't want to invalidate the whole document when it becomes "in scope". For example, imagine a case where a home router is connected to a hub and to two modems which go to two different service providers. One provider sets M=O=0 and the other provider sets M=O=1. If setting M=O=0 turns off DHCPv6 and M=O=1 triggers a reinitialization, then imagine the case where each service provider sets the RA interval to 1 second and the RA's come in alternating every 0.5 second. In that case, the CE router will be re-doing DHCPv6 every second and will create a DHCPv6 storm for the service provider. That's why we explicitly don't re-trigger or turn off/on DHCPv6 based on some trigger. All that we say is that in the case of M=O=1, the CE router MUST do DHCPv6 by default. That's all that needs to be said, and that's all that can be said. - Wes] Regards back, Hemant _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From shemant@cisco.com Tue Nov 15 21:34:37 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E9DE1F0C61 for ; Tue, 15 Nov 2011 21:34:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.216 X-Spam-Level: X-Spam-Status: No, score=-6.216 tagged_above=-999 required=5 tests=[AWL=0.383, 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 SLkSLsWU6Lyx for ; Tue, 15 Nov 2011 21:34:33 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 17ACB1F0C95 for ; Tue, 15 Nov 2011 21:34:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=545; q=dns/txt; s=iport; t=1321421673; x=1322631273; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=l7g59Xa/jbj9SDBf2mKVzr1dMmoxf6Zz8tDsn7UH2FU=; b=SNidJZpCqeJ2BJkF3kLV5qEhLk4C0tkaPU9+xcRvEJHeeIMgSCIQLSJW eDCyBQbkJSy75TQX2ys+KqXxf40idFPOrxZ4eYqj3W7mZjBLVzsw5dHUe 1vRemb5oB1J9HGWuR6Nc0S66xqzoPie5Ggm+rnF+2iDmm810TPiieQ7PC Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnsAAPlKw06tJV2d/2dsb2JhbABDmWqQCIEFgXIBAQEEEgEdCj8MBAIBCA4DBAEBCwYXAQYBRQgBCAEBBBMIGqIqAZ5TiTRjBIgUkWSMVw X-IronPort-AV: E=Sophos;i="4.69,519,1315180800"; d="scan'208";a="36406596" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 16 Nov 2011 05:34:32 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id pAG5YWHm014738; Wed, 16 Nov 2011 05:34:32 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Nov 2011 23:34:32 -0600 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Nov 2011 23:34:30 -0600 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C303544351@XMB-RCD-109.cisco.com> In-Reply-To: <000f01cca41d$bcbad730$36308590$@iname.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] FW: latest copy of rfc6204bis included Thread-Index: AcykBpfOJTAknZMXRIi+MdwoBcCWIgAAOzfwAAU6ZOAAASFIIA== References: <5B6B2B64C9FE2A489045EEEADDAFF2C30354431D@XMB-RCD-109.cisco.com> <000f01cca41d$bcbad730$36308590$@iname.com> From: "Hemant Singh (shemant)" To: "Frank Bulk" X-OriginalArrivalTime: 16 Nov 2011 05:34:32.0672 (UTC) FILETIME=[6B39AE00:01CCA421] Cc: "Mark Townsley \(townsley\)" , v6ops@ietf.org Subject: Re: [v6ops] FW: latest copy of rfc6204bis included X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 Nov 2011 05:34:37 -0000 Frank, -----Original Message----- From: Frank Bulk [mailto:frnkblk@iname.com]=20 Sent: Wednesday, November 16, 2011 1:08 PM To: Hemant Singh (shemant) Cc: Mark Townsley (townsley); Victor Kuarsingh; Brzozowski, John; v6ops@ietf.org Subject: RE: [v6ops] FW: latest copy of rfc6204bis included >Bridging two ISPs? =20 Stuff happens. One designs protocol that are immune to naive network setup. The DHCPv6 server storm problem will need to work on some protocol(s) and that is why the use case is certainly valid. =20 Hemant From frnkblk@iname.com Tue Nov 15 21:49:45 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B508121F9215 for ; Tue, 15 Nov 2011 21:49:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.642 X-Spam-Level: X-Spam-Status: No, score=-1.642 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r5s-yZR9prGq for ; Tue, 15 Nov 2011 21:49:45 -0800 (PST) Received: from premieronline.net (smtp2-4.premieronline.net [96.31.0.29]) by ietfa.amsl.com (Postfix) with ESMTP id 03FEE21F920E for ; Tue, 15 Nov 2011 21:49:44 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=199.120.69.4; Received: from BULKFAMLAPTOP (unverified [199.120.69.4]) by premieronline.net (SurgeMail 5.0n) with ESMTP (TLS) id 6809122-1729245 for multiple; Tue, 15 Nov 2011 23:49:42 -0600 From: "Frank Bulk" To: "'Hemant Singh \(shemant\)'" References: <5B6B2B64C9FE2A489045EEEADDAFF2C30354431D@XMB-RCD-109.cisco.com> <000f01cca41d$bcbad730$36308590$@iname.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303544351@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C303544351@XMB-RCD-109.cisco.com> Date: Tue, 15 Nov 2011 23:49:40 -0600 Message-ID: <001001cca423$889a3580$99cea080$@iname.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AcykBpfOJTAknZMXRIi+MdwoBcCWIgAAOzfwAAU6ZOAAASFIIAAAb2BA Content-Language: en-us X-Authenticated-User: fbulk@premieronline.net X-SpamDetect: : 0.000000 X-Info: aspam skipped due to (g_smite_skip_auth) X-Encryption: SSL encrypted X-MyRbl: Color=Unknown (rbl) Age=0 Spam=0 Notspam=0 Stars=0 Good=24 Friend=0 Surbl=0 Catch=0 r=0 ip=199.120.69.4 X-IP-stats: Incoming Last 0, First 980, in=1720, out=0, spam=0 ip=199.120.69.4 Cc: "Mark Townsley \(townsley\)" , v6ops@ietf.org Subject: Re: [v6ops] FW: latest copy of rfc6204bis included X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 Nov 2011 05:49:45 -0000 We shouldn't enable bad configurations. If bridging two ISPs is "bad" we shouldn't let that be a use case to hold back on what's a reality (i.e. DHCPv6 storming) for millions of good configurations. Yes, we need to able to have routers with one WAN that can handle RAs from more than one device (e.g. some kind of change on service provider router that causes the RA to come from a different address), but we can put in language in rfc6204 that minimizes the effects of the use case you shared. Frank -----Original Message----- From: Hemant Singh (shemant) [mailto:shemant@cisco.com] Sent: Tuesday, November 15, 2011 11:35 PM To: Frank Bulk Cc: Mark Townsley (townsley); Victor Kuarsingh; Brzozowski, John; v6ops@ietf.org Subject: RE: [v6ops] FW: latest copy of rfc6204bis included Frank, -----Original Message----- From: Frank Bulk [mailto:frnkblk@iname.com] Sent: Wednesday, November 16, 2011 1:08 PM To: Hemant Singh (shemant) Cc: Mark Townsley (townsley); Victor Kuarsingh; Brzozowski, John; v6ops@ietf.org Subject: RE: [v6ops] FW: latest copy of rfc6204bis included >Bridging two ISPs? Stuff happens. One designs protocol that are immune to naive network setup. The DHCPv6 server storm problem will need to work on some protocol(s) and that is why the use case is certainly valid. Hemant From shemant@cisco.com Tue Nov 15 21:54:49 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E96A1F0D13 for ; Tue, 15 Nov 2011 21:54:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.22 X-Spam-Level: X-Spam-Status: No, score=-6.22 tagged_above=-999 required=5 tests=[AWL=0.379, 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 qqimTIA6csUd for ; Tue, 15 Nov 2011 21:54:45 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id EE8781F0CF5 for ; Tue, 15 Nov 2011 21:54:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=846; q=dns/txt; s=iport; t=1321422885; x=1322632485; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=r7y1JAM0YgigJrki4iei8K8RKyM7hezl8/djrIf7XpI=; b=Jwrby1D6tZoZMDuj4gO3Cp1txql5R8h5MeinOJgRSM6vyp9ynsgxxmLS hNYoBPFmcEyCXcTvVxgqUgoaCYHXXtlQTXon9oC2h0P0sfMjdG7QxanAN Gon9qCvhuJoGupl+x820fd29ZQz5nYS9WTWHEPqX8OuHMdyFqAu976Wbw Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnsAAJlPw06tJXG9/2dsb2JhbABDmWqQCIEFgXIBAQEEEgEdCj8MBAIBCA4DBAEBCwYXAQYBRQgBCAEBBBMIGqIgAZ5PiTRjBIgUkWSMVw X-IronPort-AV: E=Sophos;i="4.69,519,1315180800"; d="scan'208";a="36419074" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-4.cisco.com with ESMTP; 16 Nov 2011 05:54:44 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id pAG5sium012311; Wed, 16 Nov 2011 05:54:44 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Nov 2011 23:54:44 -0600 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Nov 2011 23:54:42 -0600 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C303544354@XMB-RCD-109.cisco.com> In-Reply-To: <001001cca423$889a3580$99cea080$@iname.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] FW: latest copy of rfc6204bis included Thread-Index: AcykBpfOJTAknZMXRIi+MdwoBcCWIgAAOzfwAAU6ZOAAASFIIAAAb2BAAABANPA= References: <5B6B2B64C9FE2A489045EEEADDAFF2C30354431D@XMB-RCD-109.cisco.com> <000f01cca41d$bcbad730$36308590$@iname.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303544351@XMB-RCD-109.cisco.com> <001001cca423$889a3580$99cea080$@iname.com> From: "Hemant Singh (shemant)" To: "Frank Bulk" X-OriginalArrivalTime: 16 Nov 2011 05:54:44.0139 (UTC) FILETIME=[3D50DFB0:01CCA424] Cc: "Mark Townsley \(townsley\)" , v6ops@ietf.org Subject: Re: [v6ops] FW: latest copy of rfc6204bis included X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 Nov 2011 05:54:49 -0000 -----Original Message----- From: Frank Bulk [mailto:frnkblk@iname.com]=20 Sent: Wednesday, November 16, 2011 1:50 PM To: Hemant Singh (shemant) Cc: Mark Townsley (townsley); Victor Kuarsingh; Brzozowski, John; v6ops@ietf.org Subject: RE: [v6ops] FW: latest copy of rfc6204bis included >Yes, we need to able to have routers with one WAN that can handle RAs from >more than one device (e.g. some kind of change on service provider router >that causes the RA to come from a different address), but we can put in >language in rfc6204 that minimizes the effects of the use case you shared. The CE router has two WAN interfaces (future scope) and the same problem still occurs. A host behind the CE router receives every 1/2 sec an RA with M bit set and in the next 1/2 sec receives and RA with the M bit cleared.=20 Hemant From shemant@cisco.com Tue Nov 15 22:05:07 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 606F41F0D25 for ; Tue, 15 Nov 2011 22:05:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.924 X-Spam-Level: X-Spam-Status: No, score=-5.924 tagged_above=-999 required=5 tests=[AWL=0.075, 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 LMIV1wrpTRHZ for ; Tue, 15 Nov 2011 22:05:03 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 49C641F0D2E for ; Tue, 15 Nov 2011 22:05:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=1504; q=dns/txt; s=iport; t=1321423500; x=1322633100; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=ZwLxjx5f74sgrL63kmb7xq+2a1l/DTMAxoxl+YhWAwI=; b=SoPX7Fl4RmPKtbrJRmlWo6yXev6VWI1QxXWoW9LZxZSSLsc+COCDqMoD J4eMyRMfMigVYDOj71mh6wu07lBQCf323j8CI9py/ICTCfjDaKAka6Xt8 AI7WAS4k0XfI3uHWOW3qqAl+OgOYGn7TeN4Cs/ndJhE7Mlm7uG0riOKLq M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnsAAPlRw06tJXHB/2dsb2JhbABDmWqQCIEFgXIBAQEEAQEBDwEdCjQLDAQCAQgRBAEBCwYXAQYBJh8IAQgCBAESCBqHaJo6AZ5QiTRjBIgUkWSMVw X-IronPort-AV: E=Sophos;i="4.69,519,1315180800"; d="scan'208";a="36414162" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-3.cisco.com with ESMTP; 16 Nov 2011 06:04:59 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id pAG64xiJ009210; Wed, 16 Nov 2011 06:04:59 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Nov 2011 00:04:59 -0600 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Nov 2011 00:04:58 -0600 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C303544358@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C303544354@XMB-RCD-109.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] FW: latest copy of rfc6204bis included Thread-Index: AcykBpfOJTAknZMXRIi+MdwoBcCWIgAAOzfwAAU6ZOAAASFIIAAAb2BAAABANPAAAG3HgA== References: <5B6B2B64C9FE2A489045EEEADDAFF2C30354431D@XMB-RCD-109.cisco.com><000f01cca41d$bcbad730$36308590$@iname.com><5B6B2B64C9FE2A489045EEEADDAFF2C303544351@XMB-RCD-109.cisco.com><001001cca423$889a3580$99cea080$@iname.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303544354@XMB-RCD-109.cisco.com> From: "Hemant Singh (shemant)" To: "Hemant Singh (shemant)" , "Frank Bulk" X-OriginalArrivalTime: 16 Nov 2011 06:04:59.0613 (UTC) FILETIME=[AC2AC0D0:01CCA425] Cc: "Mark Townsley \(townsley\)" , v6ops@ietf.org Subject: Re: [v6ops] FW: latest copy of rfc6204bis included X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 Nov 2011 06:05:07 -0000 Frank, Also why would Ralph's new document in the DHC server not solve the DHCPv6 server storm due to a single DHCv6 client?=20 http://tools.ietf.org/html/draft-droms-dhc-dhcpv6-maxsolrt-update-00 Thanks, Hemant -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Hemant Singh (shemant) Sent: Wednesday, November 16, 2011 1:55 PM To: Frank Bulk Cc: Mark Townsley (townsley); v6ops@ietf.org Subject: Re: [v6ops] FW: latest copy of rfc6204bis included -----Original Message----- From: Frank Bulk [mailto:frnkblk@iname.com]=20 Sent: Wednesday, November 16, 2011 1:50 PM To: Hemant Singh (shemant) Cc: Mark Townsley (townsley); Victor Kuarsingh; Brzozowski, John; v6ops@ietf.org Subject: RE: [v6ops] FW: latest copy of rfc6204bis included >Yes, we need to able to have routers with one WAN that can handle RAs from >more than one device (e.g. some kind of change on service provider router >that causes the RA to come from a different address), but we can put in >language in rfc6204 that minimizes the effects of the use case you shared. The CE router has two WAN interfaces (future scope) and the same problem still occurs. A host behind the CE router receives every 1/2 sec an RA with M bit set and in the next 1/2 sec receives and RA with the M bit cleared.=20 Hemant _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From fred@cisco.com Tue Nov 15 23:03:56 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C76FF11E81CB for ; Tue, 15 Nov 2011 23:03:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.357 X-Spam-Level: X-Spam-Status: No, score=-105.357 tagged_above=-999 required=5 tests=[AWL=0.642, 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 fWn8uWHbJ5sQ for ; Tue, 15 Nov 2011 23:03:52 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 6D4F311E81B7 for ; Tue, 15 Nov 2011 23:03:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2061; q=dns/txt; s=iport; t=1321427032; x=1322636632; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=zRR3IG6rS3eFIHSLNkHDWajcfp1nHwQ2G9SI9KTTUL8=; b=dp1jzwfFvsxkQax2wQQHr3MTXJe8jzSWblEVXsa/OSfIb2WzHnc8QuE6 MADp31+bsEhejLApPOry0wNuQfI6DYCCIslypEdSwYn/mn96Cl1zWcUCJ 8pxGSDeQSUBsBFoEXhDk18gq6tbNNrzEF7oLGvVJ+sdibcwBYjg7AyqWs U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAMRfw06rRDoJ/2dsb2JhbABDqXKBBYFyAQEBAwEBAQEPASc0CwULCxguJzAGEwkZh2AImiYBnlGJNGMEiBKMIoU7jE4 X-IronPort-AV: E=Sophos;i="4.69,519,1315180800"; d="scan'208";a="14492598" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 16 Nov 2011 07:03:52 +0000 Received: from dhcp-57cd.meeting.ietf.org (sjc-vpn6-1383.cisco.com [10.21.125.103]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pAG73oh1008982; Wed, 16 Nov 2011 07:03:51 GMT Received: from [127.0.0.1] by dhcp-57cd.meeting.ietf.org (PGP Universal service); Wed, 16 Nov 2011 15:03:51 +0800 X-PGP-Universal: processed; by dhcp-57cd.meeting.ietf.org on Wed, 16 Nov 2011 15:03:51 +0800 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Wed, 16 Nov 2011 15:03:03 +0800 Message-Id: <68DAB112-6E32-45FE-9AB7-A34E64898F60@cisco.com> References: To: Hans Liu X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: Alexandre Cassen , "v6ops@ietf.org WG" , Claire Cheng Subject: Re: [v6ops] 6rd Sunsetting X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 Nov 2011 07:03:56 -0000 The use cases I can think of are: 1) I used to run 6rd and have now deployed native service, but have not = yet turned 6rd off. 2) I am using 6rd in one place and native service somewhere else. The second case is a pretty common coexistence case, I should think, but = the two configurations don't conflict because they are different parts = of the network. The first case is one that is presumably transitory but = will be common during a switchover. I think the argument for thinking about routing is to direct traffic to = the wider PMTU when possible and to have native deployment obsolete 6rd = deployment quickly. If the route metrics are the same, one would expect = some traffic to use native and some to use 6rd connectivity, which could = be confusing for someone expecting the 6rd traffic to go to null. On Nov 15, 2011, at 4:17 PM, Hans Liu wrote: > Excuse me Mark, I still don't have an idea in what kind of use case > should we have 6rd and Native Dual Stack at the same time in the > network? >=20 > Regards, > Hans >=20 > On Tue, Nov 15, 2011 at 4:01 PM, Mark Townsley = wrote: >>=20 >> Alexandre and I just finished up a -00 that describes two methods for = moving >> a 6rd deployment to native IPv6. Apologies for not getting this out = before >> the meeting. >> http://www.ietf.org/id/draft-townsley-v6ops-6rd-sunsetting-00.txt >>=20 >> Abstract >>=20 >> This document provides guidelines for transitioning an IPv6 >> deployment using IPv6 Rapid Deployment (6rd) to an IPv6 deployment >> using Native IPv6. It is targeted at both 6rd operators and 6rd >> implementors." >>=20 >> - Mark >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >>=20 >=20 >=20 >=20 > --=20 > Instead of following the fashion, we lead it through. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From v6ops@globis.net Wed Nov 16 00:32:49 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3F2421F914F for ; Wed, 16 Nov 2011 00:32:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.484 X-Spam-Level: X-Spam-Status: No, score=-2.484 tagged_above=-999 required=5 tests=[AWL=0.114, 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 8xsLHsxpHtXu for ; Wed, 16 Nov 2011 00:32:49 -0800 (PST) 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 8B86821F9454 for ; Wed, 16 Nov 2011 00:32:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id A81FF8700E2; Wed, 16 Nov 2011 09:32:47 +0100 (CET) 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 3jrCjVVjhGy1; Wed, 16 Nov 2011 09:32:41 +0100 (CET) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id C4D6A87007C; Wed, 16 Nov 2011 09:32:41 +0100 (CET) Message-ID: <4EC37529.4070505@globis.net> Date: Wed, 16 Nov 2011 09:32:41 +0100 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: Brian E Carpenter References: <20111115062859.14026.42405.idtracker@ietfa.amsl.com> <4EC2ABA8.4020303@globis.net> <4EC2FD24.1090303@gmail.com> In-Reply-To: <4EC2FD24.1090303@gmail.com> Content-Type: multipart/alternative; boundary="------------010709000401040301090703" Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-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, 16 Nov 2011 08:32:49 -0000 This is a multi-part message in MIME format. --------------010709000401040301090703 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Thanks for the pointer. The slight nuance here is that the end node could choose the path based on locally-known application requirements (via selecting default router, source, and destination address) all going out of the same physical interface (e.g. site Ethernet LAN), but a router several hops away (at the site entrance) might be the device that actually provides the multiple alternative path characteristics, (e.g. based on policy based routing, or having 2 independent ISP routers each seeding their own prefixes into the Homenet). regards, RayH Brian E Carpenter wrote: >> 3. "a function to control every node centrally. A site administrator or a service provider could determine or could have an effect on the behavior at their users' hosts." >> >> The draft seems to assume that routers or network managers are all knowing, and end nodes and end users are dumb. In a model based on mobile handsets connected to alternative (competing) networks, the user probably knows more than the service providers about what policy they want: think WiFi v 4G. I'd thus prefer a model that was more symmetrical, where policy selection and communication of path/topology information were orthogonal. >> > > That conversation seems to belong in MIF. It's very close to the conversation > in the MIF WG yesterday about draft-chen-mif-happy-eyeballs-extension (which > has the property of apparently needing ESP to work properly). > > Regards > Brian > > --------------010709000401040301090703 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Thanks for the pointer. The slight nuance here is that the end node could choose the path based on locally-known application requirements (via selecting default router, source, and destination address) all going out of the same physical interface (e.g. site Ethernet LAN), but a router several hops away (at the site entrance) might be the device that actually provides the multiple alternative path characteristics, (e.g. based on policy based routing, or having 2 independent ISP routers each seeding their own prefixes into the Homenet).

regards,
RayH

Brian E Carpenter wrote: 
3. "a function to control every node centrally.  A site administrator or a service provider could determine or could have an effect on the behavior at their users' hosts."

The draft seems to assume that routers or network managers are all knowing, and end nodes and end users are dumb. In a model based on mobile handsets connected to alternative (competing) networks, the user probably knows more than the service providers about what policy they want: think WiFi v 4G. I'd thus prefer a model that was more symmetrical, where policy selection and communication of path/topology information were orthogonal.
    

That conversation seems to belong in MIF. It's very close to the conversation
in the MIF WG yesterday about draft-chen-mif-happy-eyeballs-extension (which
has the property of apparently needing ESP to work properly).

Regards
   Brian

--------------010709000401040301090703-- From Carl.Wuyts@technicolor.com Wed Nov 16 00:49:23 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2248621F949E for ; Wed, 16 Nov 2011 00:49:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.24 X-Spam-Level: X-Spam-Status: No, score=-5.24 tagged_above=-999 required=5 tests=[AWL=0.759, 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 1zj9ikjRnmgx for ; Wed, 16 Nov 2011 00:49:22 -0800 (PST) Received: from na3sys009aog121.obsmtp.com (na3sys009aog121.obsmtp.com [74.125.149.145]) by ietfa.amsl.com (Postfix) with ESMTP id 13D4921F9495 for ; Wed, 16 Nov 2011 00:49:17 -0800 (PST) Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob121.postini.com ([74.125.148.12]) with SMTP ID DSNKTsN49ucvo7wMn0QS1Y+oCuO7HG3v3W6o@postini.com; Wed, 16 Nov 2011 00:49:21 PST Received: from MOPESMAILHC03.eu.thmulti.com (141.11.100.132) by mail3.technicolor.com (141.11.253.22) with Microsoft SMTP Server (TLS) id 8.3.192.1; Wed, 16 Nov 2011 09:42:37 +0100 Received: from MOPESMBX01.eu.thmulti.com ([169.254.155.121]) by MOPESMAILHC03.eu.thmulti.com ([141.11.100.132]) with mapi; Wed, 16 Nov 2011 09:42:41 +0100 From: Wuyts Carl To: Mark Andrews , "STARK, BARBARA H" Date: Wed, 16 Nov 2011 09:42:40 +0100 Thread-Topic: [v6ops] RFC6204bis-02: DS-Lite transition discussion Thread-Index: Acyj6m0hFnCihJT4Q6m6e8MQas64dgAUNopA Message-ID: <867F4B6A1672E541A94676D556793ACD0C27516B38@MOPESMBX01.eu.thmulti.com> References: <867F4B6A1672E541A94676D556793ACD0C263BCDD7@MOPESMBX01.eu.thmulti.com><5B6B2B64C9FE2A489045EEEADDAFF2C303494A91@XMB-RCD-109.cisco.com><867F4B6A1672E541A94676D556793ACD0C27516363@MOPESMBX01.eu.thmulti.com><5B6B2B64C9FE2A489045EEEADDAFF2C303494F74@XMB-RCD-109.cisco.com><867F4B6A1672E541A94676D556793ACD0C27516655@MOPESMBX01.eu.thmulti.com><5B6B2B64C9FE2A489045EEEADDAFF2C303494FE3@XMB-RCD-109.cisco.com><867F4B6A1672E541A94676D556793ACD0C27516671@MOPESMBX01.eu.thmulti.com><5B6B2B64C9FE2A489045EEEADDAFF2C303494FE5@XMB-RCD-109.cisco.com><867F4B6A1672E541A94676D556793ACD0C275166AC@MOPESMBX01.eu.thmulti.com>, <5B6B2B64C9FE2A489045EEEADDAFF2C303494FE8@XMB-RCD-109.cisco.com><2F25DE74-DA72-4B7B-9358-9E1F17BF4DAD@Cable.Comcast.com>, <603F3E51-2066-41BD-8E3C-A315011C6EA7@Cable.Comcast.com> <750BF7861EBBE048B3E648B4BB6E8F4F20B1252E@crexc50p> <20111115230016.49D741739A18@drugs.dv.isc.org> In-Reply-To: <20111115230016.49D741739A18@drugs.dv.isc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] RFC6204bis-02: DS-Lite transition discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 Nov 2011 08:49:23 -0000 Well, I assume the situation will/might depend on area and ISP, but as a re= sidential CPE, decisions like this are usually not left to the end-user. T= he ISPs chooses the scenario. The user can just either see some info on so= me GUI or maybe configure a very limited number of parameters. Please also note, and correct me if I'm wrong but I don't think this is bou= nd to area or ISP, the avg residential end-user doesn't know (or need to kn= ow ?) what an IP address is, what an IPv6 address is, what the diff is betw= een them, what dslite is ... In the end, the avg residential end-user just wants to have a solid, reliab= le service from his ISP. Carl Wuyts GCD System Architect Networking CONNECT DIVISION carl.wuyts@technicolor.com tel.: +32 3 443 65 90 Prins Boudewijnlaan 47=A0=A0-=A0=A02650 Edegem=A0=A0-=A0=A0Belgium Technicolor Delivery Technologies Belgium NV Registered office (maatschappelijke zetel): Prins Boudewijnlaan 47, 2650 Ed= egem, Belgium Company registration number (ondernemingsnummer): 0428837295 - RPR Antwerpe= n Help preserve the color of our world - Think before you print. -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of M= ark Andrews Sent: woensdag 16 november 2011 0:00 To: STARK, BARBARA H Cc: v6ops@ietf.org Subject: Re: [v6ops] RFC6204bis-02: DS-Lite transition discussion As a user, I want to be able to specifiy who is providing my AFTR service. = My ISP's AFTR boxes may suck or my ISP may be using NAT64 and in either ca= se I want to be able to use a third party AFTR service. As a user, I want to be able to disable the use of DS-Lite. As a user, I want my CPE to use DS-Lite if my ISP enables it. (default) As for routing when there is both a WAN IPv4 address and DS-Lite available.= Route local addresses natively (WAN and LAN) and non-local addresses via = DS-Lite. If there is a entry in the NAT's state table use it in preference= to DS-Lite. As a user, I want to be able to specify whether the AFTR option is advertised internally or not. (default off?) In message <750BF7861EBBE048B3E648B4BB6E8F4F20B1252E@crexc50p>, "STARK, BAR= BARA H" writes: > As I see it, there are 2 main transition scenarios around DS-Lite: >=20 > 1. The customer has a NAT444 service and is being transitioned to=20 > DS-Lite, to remove one layer of NAT, and maybe as part of a process to=20 > remove IPv4 from the access network. In this case, the NAT444 address=20 > provided to the CE router may be RFC1918, from some new address space=20 > that may or may not be allocated for CGN deployments, or some other=20 > bogon address that the CGN operator decided to use. The direction of=20 > transition is towards DS-Lite, and away from native IPv4. >=20 > 2. The customer has a public IPv4 address on the CE router WAN, but=20 > the access network is preparing to stop supporting IPv4 in the access=20 > network, and is moving all IPv4 connectivity to DS-Lite. The direction=20 > of transition is towards DS-Lite and away from native IPv4. >=20 > 3. The customer has DS-Lite, doesn't like it, so the provider is=20 > transitioning him to an IPv4 service with a public IPv4 address to the=20 > CE router WAN. The direction of transition is towards native IPv4 and=20 > away from DS-Lite. >=20 > I don't see much of a case for DS-Lite to be transitioned to NAT444 as=20 > a variant on scenario 3. But note that in the case of random bogon=20 > addresses in scenario 1, we really have no idea as to whether the WAN > IPv4 address is public or private. >=20 > And the CE router really has no clue as to why it sees both native=20 > IPv4 and DS-Lite. It just knows that both are there, and needs simple=20 > rules for dealing with the situation. >=20 > Barbara > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From shemant@cisco.com Wed Nov 16 01:01:44 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A310A21F9550 for ; Wed, 16 Nov 2011 01:01:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.925 X-Spam-Level: X-Spam-Status: No, score=-5.925 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 vMe2VHGDGK6q for ; Wed, 16 Nov 2011 01:01:43 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 9999C21F9549 for ; Wed, 16 Nov 2011 01:01:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=11993; q=dns/txt; s=iport; t=1321434103; x=1322643703; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=yNYwcSowJC3l19JNBozuIhEUzT5pCR8IXWjoLl3aooA=; b=m/rkd/wVMhmB9RwzqE+fST0Pn6LigFRPaNsQNW0Eq+4DSE2ExMapVSA6 h3xhNUJ38k659PntGJZsUsvJIbZow8mBHJy2UjP1GRL3ipog6pnpfbd2A YPt8mJNf3Xk6RJzgN/GzgO4DLZrjHQb4reHpnK+GLD06q2RGE43P1lyK0 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApAAACp7w06tJXG8/2dsb2JhbABDmW6IFQGHc4EFgXIBAQEDAQEBAQ8BCREDPgsFBwQCAQgRBAEBAQoGFwEGASYfCQgBAQQBEggBGYdgCJpCAZ5YiTRjBIgUkWSMVw X-IronPort-AV: E=Sophos;i="4.69,520,1315180800"; d="scan'208,217";a="36469184" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-5.cisco.com with ESMTP; 16 Nov 2011 09:01:43 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id pAG91hZQ007573; Wed, 16 Nov 2011 09:01:43 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Nov 2011 03:01:42 -0600 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCA43E.5BB84EEC" Date: Wed, 16 Nov 2011 03:01:39 -0600 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C30354436E@XMB-RCD-109.cisco.com> In-Reply-To: <68DAB112-6E32-45FE-9AB7-A34E64898F60@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] 6rd Sunsetting Thread-Index: AcykLe9E8+BD7WIjTbKJouEVl5VMJgAD8WKQ References: <68DAB112-6E32-45FE-9AB7-A34E64898F60@cisco.com> From: "Hemant Singh (shemant)" To: "Fred Baker (fred)" , "Hans Liu" X-OriginalArrivalTime: 16 Nov 2011 09:01:42.0468 (UTC) FILETIME=[5BF60840:01CCA43E] Cc: Alexandre Cassen , v6ops@ietf.org, Claire Cheng Subject: Re: [v6ops] 6rd Sunsetting X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 Nov 2011 09:01:44 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCA43E.5BB84EEC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, The use cases that Fred outlined are exactly what we authors of the document considered and the text in section 4.4.3 of the rfc6204bis document reflects the fact. The relevant text for the section is the first paragraph of the section, bullets 1, 2, 5, and 6, and the last paragraph covers sunsetting of 6rd.=20 =20 http://tools.ietf.org/id/draft-ietf-v6ops-6204bis-02.txt Thanks, Fred. Hemant -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Fred Baker (fred) Sent: Wednesday, November 16, 2011 3:03 PM To: Hans Liu Cc: Alexandre Cassen; v6ops@ietf.org WG; Claire Cheng Subject: Re: [v6ops] 6rd Sunsetting The use cases I can think of are: 1) I used to run 6rd and have now deployed native service, but have not yet turned 6rd off. 2) I am using 6rd in one place and native service somewhere else. The second case is a pretty common coexistence case, I should think, but the two configurations don't conflict because they are different parts of the network. The first case is one that is presumably transitory but will be common during a switchover. I think the argument for thinking about routing is to direct traffic to the wider PMTU when possible and to have native deployment obsolete 6rd deployment quickly. If the route metrics are the same, one would expect some traffic to use native and some to use 6rd connectivity, which could be confusing for someone expecting the 6rd traffic to go to null. On Nov 15, 2011, at 4:17 PM, Hans Liu wrote: > Excuse me Mark, I still don't have an idea in what kind of use case > should we have 6rd and Native Dual Stack at the same time in the > network? >=20 > Regards, > Hans >=20 > On Tue, Nov 15, 2011 at 4:01 PM, Mark Townsley wrote: >>=20 >> Alexandre and I just finished up a -00 that describes two methods for moving >> a 6rd deployment to native IPv6. Apologies for not getting this out before >> the meeting. >> http://www.ietf.org/id/draft-townsley-v6ops-6rd-sunsetting-00.txt >>=20 >> Abstract >>=20 >> This document provides guidelines for transitioning an IPv6 >> deployment using IPv6 Rapid Deployment (6rd) to an IPv6 deployment >> using Native IPv6. It is targeted at both 6rd operators and 6rd >> implementors." >>=20 >> - Mark >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >>=20 >=20 >=20 >=20 > --=20 > Instead of following the fashion, we lead it through. > _______________________________________________ > 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 ------_=_NextPart_001_01CCA43E.5BB84EEC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [v6ops] 6rd Sunsetting

Folks,

The use cases = that Fred outlined are exactly what we authors of the document = considered and the text in section 4.4.3 of the rfc6204bis document reflects the = fact.  The relevant text for the section is the first paragraph of = the section, bullets 1, 2, 5, and 6, and the last paragraph covers sunsetting of = 6rd.

 

http://tools.ietf.org/id/draft-ietf-v6ops-6204bis-02.tx= t

Thanks, = Fred.

Hemant

-----Original = Message-----
From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org]= On Behalf Of Fred Baker (fred)
Sent: Wednesday, November 16, 2011 3:03 PM
To: Hans Liu
Cc: Alexandre Cassen; v6ops@ietf.org WG; Claire Cheng
Subject: Re: [v6ops] 6rd Sunsetting

The use cases = I can think of are:

1) I used to = run 6rd and have now deployed native service, but have not yet turned = 6rd off.

2) I am using = 6rd in one place and native service somewhere else.

The second = case is a pretty common coexistence case, I should think, but the two = configurations don't conflict because they are different parts of the = network. The first case is one that is presumably transitory but will be = common during a switchover.

I think the = argument for thinking about routing is to direct traffic to the wider = PMTU when possible and to have native deployment obsolete 6rd deployment = quickly. If the route metrics are the same, one would expect some = traffic to use native and some to use 6rd connectivity, which could be = confusing for someone expecting the 6rd traffic to go to = null.

On Nov 15, = 2011, at 4:17 PM, Hans Liu wrote:

> Excuse me = Mark, I still don't have an idea in what kind of use = case

> should we = have 6rd and Native Dual Stack at the same time in the

> = network?

> =

> = Regards,

> = Hans

> =

> On Tue, = Nov 15, 2011 at 4:01 PM, Mark Townsley <mark@townsley.net> = wrote:

>> =

>> = Alexandre and I just finished up a -00 that describes two methods for = moving

>> a 6rd = deployment to native IPv6. Apologies for not getting this out = before

>> the = meeting.

>> http://www.ietf.org/id/draft-townsley-v6ops-6rd-sunsetting-00.txt

>> =

>> = Abstract

>> =

>>   This document provides guidelines = for transitioning an IPv6

>>   deployment using IPv6 Rapid = Deployment (6rd) to an IPv6 deployment

>>   using Native IPv6.  It is = targeted at both 6rd operators and 6rd

>>   = implementors."

>> =

>> - = Mark

>> = _______________________________________________

>> v6ops = mailing list

>> = v6ops@ietf.org

>> https://www.ietf.org= /mailman/listinfo/v6ops

>> =

>> =

> =

> =

> =

> -- =

> Instead = of following the fashion, we lead it through.

> = _______________________________________________

> v6ops = mailing list

> = v6ops@ietf.org

> https://www.ietf.org= /mailman/listinfo/v6ops

_______________________________________________<= /SPAN>

v6ops mailing = list

v6ops@ietf.org

https://www.ietf.org= /mailman/listinfo/v6ops

------_=_NextPart_001_01CCA43E.5BB84EEC-- From Carl.Wuyts@technicolor.com Wed Nov 16 01:04:33 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3623821F9566 for ; Wed, 16 Nov 2011 01:04:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.972 X-Spam-Level: X-Spam-Status: No, score=-4.972 tagged_above=-999 required=5 tests=[AWL=0.427, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_36=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 Z1mdPQsil7Xa for ; Wed, 16 Nov 2011 01:04:32 -0800 (PST) Received: from na3sys009aog116.obsmtp.com (na3sys009aog116.obsmtp.com [74.125.149.240]) by ietfa.amsl.com (Postfix) with ESMTP id 231E221F9564 for ; Wed, 16 Nov 2011 01:04:29 -0800 (PST) Received: from mopesedge02.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob116.postini.com ([74.125.148.12]) with SMTP ID DSNKTsN8nDh/fodAABUxK7tAoaVog5bj2Z0V@postini.com; Wed, 16 Nov 2011 01:04:31 PST Received: from MOPESMAILHC02.eu.thmulti.com (141.11.100.29) by mopesedge02.eu.thmulti.com (141.11.253.23) with Microsoft SMTP Server (TLS) id 8.3.192.1; Wed, 16 Nov 2011 10:00:56 +0100 Received: from MOPESMBX01.eu.thmulti.com ([169.254.155.121]) by MOPESMAILHC02.eu.thmulti.com ([141.11.100.29]) with mapi; Wed, 16 Nov 2011 10:01:06 +0100 From: Wuyts Carl To: Victor Kuarsingh , "Brzozowski, John" , "Hemant Singh (shemant)" , "v6ops@ietf.org" Date: Wed, 16 Nov 2011 10:01:04 +0100 Thread-Topic: [v6ops] FW: latest copy of rfc6204bis included Thread-Index: AcykBqX8uAd8xtMARomx48JAF6kQ9QAN2+hQ Message-ID: <867F4B6A1672E541A94676D556793ACD0C27516B60@MOPESMBX01.eu.thmulti.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "W. Mark Townsley" Subject: Re: [v6ops] FW: latest copy of rfc6204bis included X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 Nov 2011 09:04:33 -0000 +1, we've finally come to a stage to be able to roll-out a solid IPv6 resid= ential CPE, so indeed some extra corrections to this RFC seems unavoidable. Carl Wuyts GCD System Architect Networking CONNECT DIVISION carl.wuyts@technicolor.com tel.: +32 3 443 65 90 Prins Boudewijnlaan 47=A0=A0-=A0=A02650 Edegem=A0=A0-=A0=A0Belgium Technicolor Delivery Technologies Belgium NV Registered office (maatschappelijke zetel): Prins Boudewijnlaan 47, 2650 Ed= egem, Belgium Company registration number (ondernemingsnummer): 0428837295 - RPR Antwerpe= n Help preserve the color of our world - Think before you print. -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of V= ictor Kuarsingh Sent: woensdag 16 november 2011 3:22 To: Brzozowski, John; Hemant Singh (shemant); v6ops@ietf.org Cc: W. Mark Townsley Subject: Re: [v6ops] FW: latest copy of rfc6204bis included I will need to concur with John here. Ignoring real world problems is a mistake. It has taken considerable effor= t for key operators to move IPv6 programs forward. Having these programs h= ampered by avoidable issues risks both those deployments from moving forwar= d (bad for all of us), and may dampen others from starting and moving forwa= rd. IPv6 needs to go in.. And it needs to work well. If we cannot attain this,= and have operational issues related to this it just puts undue pressure op= erators in the forefront. Regards, Victor K On 11-11-16 10:17 AM, "Brzozowski, John" wrote: >Mistakes with RFC6204 were made from the earliest versions, there is no=20 >harm admitting where mistakes were made. In fact, this is healthy to=20 >ensure we do not make them again. > >The DHCPv6 client problem is a mistake in RFC6204 and my concern is=20 >that we are/were actively discussing allow it to live on in BIS. > >Ignoring real world experience and feedback is not part of this process=20 >last time I checked. > >John >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >John Jason Brzozowski >Comcast Cable >e) mailto:john_brzozowski@cable.comcast.com >o) 609-377-6594 >m) 484-962-0060 >w) http://www.comcast6.net >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > >On 11/16/11 10:06 AM, "Hemant Singh (shemant)" wrote: > >>Re: latest copy of rfc6204bis includedMark, >>=20 >>We should stop harking at rfc6204 that the document made quite a few=20 >>mistake. Doesn=B9t fly =AD the delta between rfc6204 and rfc6204bis that= =20 >>is not transition tech is minor tweaks. The DHCPv6 server storm=20 >>problem raised recently by Comcast is a not any mistake in RFC 6204. =20 >>What can an >>IPv6 CE router document do changing the DHC or the ND protocols? >>Further, I, Wes Beebee and Ole have already said several times the M=20 >>and the O bits in the RA just can=B9t be used to signal start/stop to a=20 >>DHCv6 client. See use case below. >>=20 >>Also, at the last IETF it was v6ops who told us to fasttrack=20 >>transition tech in rfc6204bis and ship a new copy out ASAP. So why=20 >>are we thrashing at this IETF for this goal? >>=20 >>Further, the rfc6204bis document is already good for 6rd sunsetting,=20 >>so what specifically do we need from your new draft? You new draft is al= so >>in conflict with rfc6204bis. Your document includes the text below >>shown between squared braces. >>=20 >>[A 6rd CE MUST assign a forwarding metric such that native IPv6egress=20 >>is preferred for traffic outside the 6rd domain when 6rd and native=20 >>IPv6 interfaces are active.] >>=20 >>Sunsetting 6rd involves concurrent operation of 6rd and native IPv6. =20 >>In such an operation the switching in the IPv6 CE router is source-based >>routing while your text above speaks of destination based routing. Our >>document says >>=20 >>[5. Selection of 6rd tunnel or native IPv6 output interface on the CE =20 >>router is determined by the source IPv6 address of the packet >> from a host.] >>=20 >>Hemant >>=20 >>From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf=20 >>Of Hemant Singh (shemant) >>Sent: Wednesday, November 16, 2011 8:32 AM >>To: v6ops@ietf.org >>Subject: [v6ops] FW: latest copy of rfc6204bis included >> >> >>=20 >>For anyone who thinks the IPv6 ND RA=B9s M or the O bits can signal=20 >>start/stop DHCPv6 to a client, please see this email from our IPv6 CE=20 >>router design team discussion. It=B9s is bad idea. >>=20 >>Hemant >>=20 >>From: Wes Beebee (wbeebee) >>Sent: Wednesday, November 09, 2011 3:19 AM >>To: Lorenzo Colitti; Hemant Singh (shemant) >>Cc: Wojciech Dec (wdec); cpe-router@external.cisco.com; Erik Kline;=20 >>John Jason Brzozowski >>Subject: Re: latest copy of rfc6204bis included >> >> >>=20 >>Lorenzo - >> >>>> I don't see any text that requires the CE router not to do DHCPv6=20 >>>>PD if M=3D0 and O=3D0. Where is it? >> >>The reason you do not see such text is that we don=B9t want to introduce= =20 >>anything deliberately in RFC 6204bis that will explicitly break in the=20 >>multi-homing case. Even though it=B9s =B3out of scope=B2 - we don=B9t wa= nt to=20 >>invalidate the whole document when it becomes =B3in scope=B2. >> >>For example, imagine a case where a home router is connected to a hub=20 >>and to two modems which go to two different service providers. One=20 >>provider sets M=3DO=3D0 and the other provider sets M=3DO=3D1. If settin= g=20 >>M=3DO=3D0 turns off >>DHCPv6 and M=3DO=3D1 triggers a reinitialization, then imagine the case=20 >>where each service provider sets the RA interval to 1 second and the=20 >>RA=B9s come in alternating every 0.5 second. In that case, the CE=20 >>router will be re-doing DHCPv6 every second and will create a DHCPv6=20 >>storm for the service provider. >> >>That=B9s why we explicitly don=B9t re-trigger or turn off/on DHCPv6 based= =20 >>on some trigger. All that we say is that in the case of M=3DO=3D1, the C= E=20 >>router MUST do DHCPv6 by default. That=B9s all that needs to be said,=20 >>and that=B9s all that can be said. >> >>- Wes >> >>_______________________________________________ >>v6ops mailing list >>v6ops@ietf.org >>https://www.ietf.org/mailman/listinfo/v6ops > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From ichiroumakino@gmail.com Wed Nov 16 02:27:43 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39BB221F9529 for ; Wed, 16 Nov 2011 02:27:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 NoA+bbMUFwdg for ; Wed, 16 Nov 2011 02:27:42 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9907C21F9521 for ; Wed, 16 Nov 2011 02:27:42 -0800 (PST) Received: by iaeo4 with SMTP id o4so469164iae.31 for ; Wed, 16 Nov 2011 02:27:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=fOxu6MxF0J7PQ/dO+CRP/yyK3WC0xQh0IoK8w7Dg/MQ=; b=eZL9DEwlymoPCHQwMwsCaFnM/RWmEvsVFxhb8JcJNujISgV7R/RqP68B1jLpk5T4tz RQgIG3F+r7E24Xdesd1unz6kMBscpa65d8a34f4LlV8TuvqLcTFwLs4FH6kWv2mcDURq XZVW52Ulf2GVL2QGpMBaBMRbOEgKaRQFfxD7w= Received: by 10.42.148.136 with SMTP id r8mr31148188icv.1.1321439262233; Wed, 16 Nov 2011 02:27:42 -0800 (PST) Received: from [10.21.86.64] (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPS id bu33sm42674048ibb.11.2011.11.16.02.27.38 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 16 Nov 2011 02:27:40 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: Date: Wed, 16 Nov 2011 18:27:34 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <4A1713D1-5DA4-4139-855A-9579C0F3A901@employees.org> References: To: "Brzozowski, John" X-Mailer: Apple Mail (2.1084) Cc: "W. Mark Townsley" , "v6ops@ietf.org" Subject: Re: [v6ops] FW: latest copy of rfc6204bis included X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 Nov 2011 10:27:43 -0000 John, > Mistakes with RFC6204 were made from the earliest versions, there is = no > harm admitting where mistakes were made. In fact, this is healthy to > ensure we do not make them again. >=20 > The DHCPv6 client problem is a mistake in RFC6204 and my concern is = that > we are/were actively discussing allow it to live on in BIS. >=20 > Ignoring real world experience and feedback is not part of this = process > last time I checked. I'll be the first to accept that we make mistakes (those who know me = know that to be a lie, but let's assume that I do for the purpose of = this discussion). ;-) from a standards perspective: I do NOT accept that there are any mistakes with regards to DHCP = address assignment and prefix delegation behaviour in RFC6204. RFC6204 is an informational document and a "device profile" document. RFC6204 does _not_ specify document behaviour. it certainly does _not_ = specify how DHCP should work. _iff_ the correct solution to this problem were that the protocol = called DHCPv6 PD defined in RFC3633 should be triggered by existing or new bits in Router Advertisements, then that has to be done as new = standard track documents in DHC / 6man. _iff_ the correct solution to this problem were that the meaning of = the M/O bits must change, then that has to be done in 6man. when that is done, a respin of 6204 can obviously reference that work. operationally, yes I accept and agree there are issues. short-term there = are many operational workarounds. mid-term they can be fixed by the = before-mentioned new DHCP option. assuming that every IPv6 = implementation will support it. can we stop this now? so that I can continue on the = draft-troan-global-ban-on-ever-talking-about-m&o-bits-ever-again-00 cheers, Ole From shemant@cisco.com Wed Nov 16 04:45:31 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C06021F9542 for ; Wed, 16 Nov 2011 04:45:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.926 X-Spam-Level: X-Spam-Status: No, score=-5.926 tagged_above=-999 required=5 tests=[AWL=0.073, 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 WmpChlIp3VDm for ; Wed, 16 Nov 2011 04:45:30 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 3896F21F953C for ; Wed, 16 Nov 2011 04:45:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=4910; q=dns/txt; s=iport; t=1321447530; x=1322657130; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=i6g/xOcWiz8iW8lvbhYGn6UEGt+LjLF3hJMonZRpk+M=; b=bqSS/mR2iRIoe+jgbt0vYPNU2/E+1qkb4HyMHmzh8Lzdu2tlaiNwMbFo YuR5bfaYE1q4Pqw4J/gVxRj69rj+4NNlKGPCLrDo4D403gDbW81liXbQw N7vAAGwKgw2n1PsmZx04ZYF8WrQh33Dza3KjUGsD2uqUB7B14DxcQZMaA 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoAAMevw06tJXG9/2dsb2JhbABDmXKQBYEFgXIBAQEEAQEBDwEdPgsMAgICAQgRBAEBCwYXAQYBGgwfCQgBAQQBEggBEgeHaJpJAZ5qAokyYwSHYzGRZIxX X-IronPort-AV: E=Sophos;i="4.69,521,1315180800"; d="scan'208";a="36512022" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-4.cisco.com with ESMTP; 16 Nov 2011 12:45:28 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id pAGCjRS4017112; Wed, 16 Nov 2011 12:45:27 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Nov 2011 06:45:28 -0600 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Nov 2011 06:45:24 -0600 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C30354437C@XMB-RCD-109.cisco.com> In-Reply-To: <867F4B6A1672E541A94676D556793ACD0C27516B38@MOPESMBX01.eu.thmulti.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] RFC6204bis-02: DS-Lite transition discussion Thread-Index: Acyj6m0hFnCihJT4Q6m6e8MQas64dgAUNopAAAh6hoA= References: <867F4B6A1672E541A94676D556793ACD0C263BCDD7@MOPESMBX01.eu.thmulti.com><5B6B2B64C9FE2A489045EEEADDAFF2C303494A91@XMB-RCD-109.cisco.com><867F4B6A1672E541A94676D556793ACD0C27516363@MOPESMBX01.eu.thmulti.com><5B6B2B64C9FE2A489045EEEADDAFF2C303494F74@XMB-RCD-109.cisco.com><867F4B6A1672E541A94676D556793ACD0C27516655@MOPESMBX01.eu.thmulti.com><5B6B2B64C9FE2A489045EEEADDAFF2C303494FE3@XMB-RCD-109.cisco.com><867F4B6A1672E541A94676D556793ACD0C27516671@MOPESMBX01.eu.thmulti.com><5B6B2B64C9FE2A489045EEEADDAFF2C303494FE5@XMB-RCD-109.cisco.com><867F4B6A1672E541A94676D556793ACD0C275166AC@MOPESMBX01.eu.thmulti.com>, <5B6B2B64C9FE2A489045EEEADDAFF2C303494FE8@XMB-RCD-109.cisco.com><2F25DE74-DA72-4B7B-9358-9E1F17BF4DAD@Cable.Comcast.com>, <603F3E51-2066-41BD-8E3C-A315011C6EA7@Cable.Comcast.com><750BF7861EBBE048B3E648B4BB6E8F4F20B1252E@crexc50p><20111115230016.49D741739A18@drugs.dv.isc.org> <867F4B6A1672E541A94676D556793ACD0C27516B38@ MOPESMBX 01.eu.thmulti.com> From: "Hemant Singh (shemant)" To: "Wuyts Carl" , "Mark Andrews" , "STARK, BARBARA H" X-OriginalArrivalTime: 16 Nov 2011 12:45:28.0072 (UTC) FILETIME=[9E3EA080:01CCA45D] Cc: v6ops@ietf.org Subject: Re: [v6ops] RFC6204bis-02: DS-Lite transition discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 Nov 2011 12:45:31 -0000 Carl, Did you see this email from me today? Ralph already has one solution = pushed forward in the DHC WG to deal with the DHCPv6 server storm. http://www.ietf.org/mail-archive/web/v6ops/current/msg11111.html Hemant -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Wuyts Carl Sent: Wednesday, November 16, 2011 4:43 PM To: Mark Andrews; STARK, BARBARA H Cc: v6ops@ietf.org Subject: Re: [v6ops] RFC6204bis-02: DS-Lite transition discussion Well, I assume the situation will/might depend on area and ISP, but as a = residential CPE, decisions like this are usually not left to the = end-user. The ISPs chooses the scenario. The user can just either see = some info on some GUI or maybe configure a very limited number of = parameters. Please also note, and correct me if I'm wrong but I don't think this is = bound to area or ISP, the avg residential end-user doesn't know (or need = to know ?) what an IP address is, what an IPv6 address is, what the diff = is between them, what dslite is ... In the end, the avg residential end-user just wants to have a solid, = reliable service from his ISP. Carl Wuyts GCD System Architect Networking CONNECT DIVISION carl.wuyts@technicolor.com tel.: +32 3 443 65 90 Prins Boudewijnlaan 47=A0=A0-=A0=A02650 Edegem=A0=A0-=A0=A0Belgium Technicolor Delivery Technologies Belgium NV Registered office (maatschappelijke zetel): Prins Boudewijnlaan 47, 2650 = Edegem, Belgium Company registration number (ondernemingsnummer): 0428837295 - RPR = Antwerpen Help preserve the color of our world - Think before you print. -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Mark Andrews Sent: woensdag 16 november 2011 0:00 To: STARK, BARBARA H Cc: v6ops@ietf.org Subject: Re: [v6ops] RFC6204bis-02: DS-Lite transition discussion As a user, I want to be able to specifiy who is providing my AFTR = service. My ISP's AFTR boxes may suck or my ISP may be using NAT64 and = in either case I want to be able to use a third party AFTR service. As a user, I want to be able to disable the use of DS-Lite. As a user, I want my CPE to use DS-Lite if my ISP enables it. (default) As for routing when there is both a WAN IPv4 address and DS-Lite = available. Route local addresses natively (WAN and LAN) and non-local = addresses via DS-Lite. If there is a entry in the NAT's state table use = it in preference to DS-Lite. As a user, I want to be able to specify whether the AFTR option is advertised internally or not. (default off?) In message <750BF7861EBBE048B3E648B4BB6E8F4F20B1252E@crexc50p>, "STARK, = BARBARA H" writes: > As I see it, there are 2 main transition scenarios around DS-Lite: >=20 > 1. The customer has a NAT444 service and is being transitioned to=20 > DS-Lite, to remove one layer of NAT, and maybe as part of a process to = > remove IPv4 from the access network. In this case, the NAT444 address=20 > provided to the CE router may be RFC1918, from some new address space=20 > that may or may not be allocated for CGN deployments, or some other=20 > bogon address that the CGN operator decided to use. The direction of=20 > transition is towards DS-Lite, and away from native IPv4. >=20 > 2. The customer has a public IPv4 address on the CE router WAN, but=20 > the access network is preparing to stop supporting IPv4 in the access=20 > network, and is moving all IPv4 connectivity to DS-Lite. The direction = > of transition is towards DS-Lite and away from native IPv4. >=20 > 3. The customer has DS-Lite, doesn't like it, so the provider is=20 > transitioning him to an IPv4 service with a public IPv4 address to the = > CE router WAN. The direction of transition is towards native IPv4 and=20 > away from DS-Lite. >=20 > I don't see much of a case for DS-Lite to be transitioned to NAT444 as = > a variant on scenario 3. But note that in the case of random bogon=20 > addresses in scenario 1, we really have no idea as to whether the WAN > IPv4 address is public or private. >=20 > And the CE router really has no clue as to why it sees both native=20 > IPv4 and DS-Lite. It just knows that both are there, and needs simple=20 > rules for dealing with the situation. >=20 > Barbara > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From Carl.Wuyts@technicolor.com Wed Nov 16 04:54:54 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23B7A21F951A for ; Wed, 16 Nov 2011 04:54:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.289 X-Spam-Level: X-Spam-Status: No, score=-5.289 tagged_above=-999 required=5 tests=[AWL=0.710, 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 Nbh+D2Cl6Dla for ; Wed, 16 Nov 2011 04:54:53 -0800 (PST) Received: from na3sys009aog106.obsmtp.com (na3sys009aob106.obsmtp.com [74.125.149.76]) by ietfa.amsl.com (Postfix) with ESMTP id 1FCDA21F9515 for ; Wed, 16 Nov 2011 04:54:49 -0800 (PST) Received: from mopesedge02.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob106.postini.com ([74.125.148.12]) with SMTP ID DSNKTsOyguOemh6q8gKA6RefGzezW/p0Z/9d@postini.com; Wed, 16 Nov 2011 04:54:53 PST Received: from MOPESMAILHC03.eu.thmulti.com (141.11.100.132) by mopesedge02.eu.thmulti.com (141.11.253.23) with Microsoft SMTP Server (TLS) id 8.3.192.1; Wed, 16 Nov 2011 13:51:16 +0100 Received: from MOPESMBX01.eu.thmulti.com ([169.254.155.121]) by MOPESMAILHC03.eu.thmulti.com ([141.11.100.132]) with mapi; Wed, 16 Nov 2011 13:51:27 +0100 From: Wuyts Carl To: "Hemant Singh (shemant)" , Mark Andrews , "STARK, BARBARA H" Date: Wed, 16 Nov 2011 13:51:23 +0100 Thread-Topic: [v6ops] RFC6204bis-02: DS-Lite transition discussion Thread-Index: Acyj6m0hFnCihJT4Q6m6e8MQas64dgAUNopAAAh6hoAAACrrcA== Message-ID: <867F4B6A1672E541A94676D556793ACD0C27516CDE@MOPESMBX01.eu.thmulti.com> References: <867F4B6A1672E541A94676D556793ACD0C263BCDD7@MOPESMBX01.eu.thmulti.com><5B6B2B64C9FE2A489045EEEADDAFF2C303494A91@XMB-RCD-109.cisco.com><867F4B6A1672E541A94676D556793ACD0C27516363@MOPESMBX01.eu.thmulti.com><5B6B2B64C9FE2A489045EEEADDAFF2C303494F74@XMB-RCD-109.cisco.com><867F4B6A1672E541A94676D556793ACD0C27516655@MOPESMBX01.eu.thmulti.com><5B6B2B64C9FE2A489045EEEADDAFF2C303494FE3@XMB-RCD-109.cisco.com><867F4B6A1672E541A94676D556793ACD0C27516671@MOPESMBX01.eu.thmulti.com><5B6B2B64C9FE2A489045EEEADDAFF2C303494FE5@XMB-RCD-109.cisco.com><867F4B6A1672E541A94676D556793ACD0C275166AC@MOPESMBX01.eu.thmulti.com>, <5B6B2B64C9FE2A489045EEEADDAFF2C303494FE8@XMB-RCD-109.cisco.com><2F25DE74-DA72-4B7B-9358-9E1F17BF4DAD@Cable.Comcast.com>, <603F3E51-2066-41BD-8E3C-A315011C6EA7@Cable.Comcast.com><750BF7861EBBE048B3E648B4BB6E8F4F20B1252E@crexc50p><20111115230016.49D741739A18@drugs.dv.isc.org> <867F4B6A1672E541A94676D556793ACD0C27516B38@MOPESMBX 01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30354437C@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C30354437C@XMB-RCD-109.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] RFC6204bis-02: DS-Lite transition discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 Nov 2011 12:54:54 -0000 Yes, I did. There have been quite a few mails exchanged on this over the la= st few weeks. If this materializes into rfc, we'll cope with it. My conce= rns on all of these are not related to this storm issue in fact, just don't= want too much linking in place (like dhcpv6 and RA, public v4 and dslite t= unnel, etc), it makes things too complex and some improvements on descripti= ons, to avoid confusion. Thx Carl Wuyts GCD System Architect Networking CONNECT DIVISION carl.wuyts@technicolor.com tel.: +32 3 443 65 90 Prins Boudewijnlaan 47=A0=A0-=A0=A02650 Edegem=A0=A0-=A0=A0Belgium Technicolor Delivery Technologies Belgium NV Registered office (maatschappelijke zetel): Prins Boudewijnlaan 47, 2650 Ed= egem, Belgium Company registration number (ondernemingsnummer): 0428837295 - RPR Antwerpe= n Help preserve the color of our world - Think before you print. -----Original Message----- From: Hemant Singh (shemant) [mailto:shemant@cisco.com]=20 Sent: woensdag 16 november 2011 13:45 To: Wuyts Carl; Mark Andrews; STARK, BARBARA H Cc: v6ops@ietf.org Subject: RE: [v6ops] RFC6204bis-02: DS-Lite transition discussion Carl, Did you see this email from me today? Ralph already has one solution pushe= d forward in the DHC WG to deal with the DHCPv6 server storm. http://www.ietf.org/mail-archive/web/v6ops/current/msg11111.html Hemant -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of W= uyts Carl Sent: Wednesday, November 16, 2011 4:43 PM To: Mark Andrews; STARK, BARBARA H Cc: v6ops@ietf.org Subject: Re: [v6ops] RFC6204bis-02: DS-Lite transition discussion Well, I assume the situation will/might depend on area and ISP, but as a re= sidential CPE, decisions like this are usually not left to the end-user. T= he ISPs chooses the scenario. The user can just either see some info on so= me GUI or maybe configure a very limited number of parameters. Please also note, and correct me if I'm wrong but I don't think this is bou= nd to area or ISP, the avg residential end-user doesn't know (or need to kn= ow ?) what an IP address is, what an IPv6 address is, what the diff is betw= een them, what dslite is ... In the end, the avg residential end-user just wants to have a solid, reliab= le service from his ISP. Carl Wuyts GCD System Architect Networking CONNECT DIVISION carl.wuyts@technicolor.com tel.: +32 3 443 65 90 Prins Boudewijnlaan 47=A0=A0-=A0=A02650 Edegem=A0=A0-=A0=A0Belgium Technico= lor Delivery Technologies Belgium NV Registered office (maatschappelijke ze= tel): Prins Boudewijnlaan 47, 2650 Edegem, Belgium Company registration num= ber (ondernemingsnummer): 0428837295 - RPR Antwerpen Help preserve the color of our world - Think before you print. -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of M= ark Andrews Sent: woensdag 16 november 2011 0:00 To: STARK, BARBARA H Cc: v6ops@ietf.org Subject: Re: [v6ops] RFC6204bis-02: DS-Lite transition discussion As a user, I want to be able to specifiy who is providing my AFTR service. = My ISP's AFTR boxes may suck or my ISP may be using NAT64 and in either ca= se I want to be able to use a third party AFTR service. As a user, I want to be able to disable the use of DS-Lite. As a user, I want my CPE to use DS-Lite if my ISP enables it. (default) As for routing when there is both a WAN IPv4 address and DS-Lite available.= Route local addresses natively (WAN and LAN) and non-local addresses via = DS-Lite. If there is a entry in the NAT's state table use it in preference= to DS-Lite. As a user, I want to be able to specify whether the AFTR option is advertised internally or not. (default off?) In message <750BF7861EBBE048B3E648B4BB6E8F4F20B1252E@crexc50p>, "STARK, BAR= BARA H" writes: > As I see it, there are 2 main transition scenarios around DS-Lite: >=20 > 1. The customer has a NAT444 service and is being transitioned to=20 > DS-Lite, to remove one layer of NAT, and maybe as part of a process to=20 > remove IPv4 from the access network. In this case, the NAT444 address=20 > provided to the CE router may be RFC1918, from some new address space=20 > that may or may not be allocated for CGN deployments, or some other=20 > bogon address that the CGN operator decided to use. The direction of=20 > transition is towards DS-Lite, and away from native IPv4. >=20 > 2. The customer has a public IPv4 address on the CE router WAN, but=20 > the access network is preparing to stop supporting IPv4 in the access=20 > network, and is moving all IPv4 connectivity to DS-Lite. The direction=20 > of transition is towards DS-Lite and away from native IPv4. >=20 > 3. The customer has DS-Lite, doesn't like it, so the provider is=20 > transitioning him to an IPv4 service with a public IPv4 address to the=20 > CE router WAN. The direction of transition is towards native IPv4 and=20 > away from DS-Lite. >=20 > I don't see much of a case for DS-Lite to be transitioned to NAT444 as=20 > a variant on scenario 3. But note that in the case of random bogon=20 > addresses in scenario 1, we really have no idea as to whether the WAN > IPv4 address is public or private. >=20 > And the CE router really has no clue as to why it sees both native > IPv4 and DS-Lite. It just knows that both are there, and needs simple=20 > rules for dealing with the situation. >=20 > Barbara > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org _______________________________________________ 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 frnkblk@iname.com Wed Nov 16 06:13:54 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C05A21F969D for ; Wed, 16 Nov 2011 06:13:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.57 X-Spam-Level: X-Spam-Status: No, score=-1.57 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, 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 Cy8ujRsHQ0Rq for ; Wed, 16 Nov 2011 06:13:53 -0800 (PST) Received: from premieronline.net (smtp2-2.premieronline.net [96.31.0.27]) by ietfa.amsl.com (Postfix) with ESMTP id 9FF2B21F9698 for ; Wed, 16 Nov 2011 06:13:53 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=199.120.69.4; Received: from FRANKBULK (unverified [199.120.69.4]) by premieronline.net (SurgeMail 5.0n) with ESMTP (TLS) id 6824945-1729245 for multiple; Wed, 16 Nov 2011 08:13:50 -0600 From: "Frank Bulk" To: "'Hemant Singh \(shemant\)'" References: <5B6B2B64C9FE2A489045EEEADDAFF2C30354431D@XMB-RCD-109.cisco.com><000f01cca41d$bcbad730$36308590$@iname.com><5B6B2B64C9FE2A489045EEEADDAFF2C303544351@XMB-RCD-109.cisco.com><001001cca423$889a3580$99cea080$@iname.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303544354@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303544358@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C303544358@XMB-RCD-109.cisco.com> Date: Wed, 16 Nov 2011 08:13:49 -0600 Message-ID: <007401cca469$f6731400$e3593c00$@iname.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AcykBpfOJTAknZMXRIi+MdwoBcCWIgAAOzfwAAU6ZOAAASFIIAAAb2BAAABANPAAAG3HgAARBpNA Content-Language: en-us X-Authenticated-User: fbulk@premieronline.net X-SpamDetect: : 0.000000 X-Info: aspam skipped due to (g_smite_skip_auth) X-Encryption: SSL encrypted X-MyRbl: Color=Unknown (rbl) Age=0 Spam=0 Notspam=0 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=199.120.69.4 X-IP-stats: Incoming Last 0, First 981, in=1723, out=0, spam=0 ip=199.120.69.4 Cc: "Mark Townsley \(townsley\)" , v6ops@ietf.org Subject: Re: [v6ops] FW: latest copy of rfc6204bis included X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: frnkblk@iname.com List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 14:13:54 -0000 It resolves the DHCP storm issue, just that it if an operator mis-configures a host or pool in the DHCP configuration it may not be easy for them to get the CPE to re-request an IP address again. The use of RA is more immediate (M&O=0 => stop SOLICITing) (M|O=1 => start SOLICITing). Frank -----Original Message----- From: Hemant Singh (shemant) [mailto:shemant@cisco.com] Sent: Wednesday, November 16, 2011 12:05 AM To: Hemant Singh (shemant); Frank Bulk Cc: Mark Townsley (townsley); v6ops@ietf.org Subject: RE: [v6ops] FW: latest copy of rfc6204bis included Frank, Also why would Ralph's new document in the DHC server not solve the DHCPv6 server storm due to a single DHCv6 client? http://tools.ietf.org/html/draft-droms-dhc-dhcpv6-maxsolrt-update-00 Thanks, Hemant -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Hemant Singh (shemant) Sent: Wednesday, November 16, 2011 1:55 PM To: Frank Bulk Cc: Mark Townsley (townsley); v6ops@ietf.org Subject: Re: [v6ops] FW: latest copy of rfc6204bis included -----Original Message----- From: Frank Bulk [mailto:frnkblk@iname.com] Sent: Wednesday, November 16, 2011 1:50 PM To: Hemant Singh (shemant) Cc: Mark Townsley (townsley); Victor Kuarsingh; Brzozowski, John; v6ops@ietf.org Subject: RE: [v6ops] FW: latest copy of rfc6204bis included >Yes, we need to able to have routers with one WAN that can handle RAs from >more than one device (e.g. some kind of change on service provider router >that causes the RA to come from a different address), but we can put in >language in rfc6204 that minimizes the effects of the use case you shared. The CE router has two WAN interfaces (future scope) and the same problem still occurs. A host behind the CE router receives every 1/2 sec an RA with M bit set and in the next 1/2 sec receives and RA with the M bit cleared. Hemant _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From Carl.Wuyts@technicolor.com Wed Nov 16 06:25:18 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76BBB21F94B9 for ; Wed, 16 Nov 2011 06:25:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.316 X-Spam-Level: X-Spam-Status: No, score=-5.316 tagged_above=-999 required=5 tests=[AWL=0.683, 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 trC2OVlsVaMm for ; Wed, 16 Nov 2011 06:25:17 -0800 (PST) Received: from na3sys009aog122.obsmtp.com (na3sys009aog122.obsmtp.com [74.125.149.147]) by ietfa.amsl.com (Postfix) with ESMTP id 5E98621F94D1 for ; Wed, 16 Nov 2011 06:25:16 -0800 (PST) Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob122.postini.com ([74.125.148.12]) with SMTP ID DSNKTsPHyvSsuMFDBe06tijXKPdJ8dzr8srh@postini.com; Wed, 16 Nov 2011 06:25:17 PST Received: from MOPESMAILHC03.eu.thmulti.com (141.11.100.132) by mail3.technicolor.com (141.11.253.22) with Microsoft SMTP Server (TLS) id 8.3.192.1; Wed, 16 Nov 2011 15:21:26 +0100 Received: from MOPESMBX01.eu.thmulti.com ([169.254.155.121]) by MOPESMAILHC03.eu.thmulti.com ([141.11.100.132]) with mapi; Wed, 16 Nov 2011 15:21:31 +0100 From: Wuyts Carl To: "frnkblk@iname.com" , "'Hemant Singh (shemant)'" Date: Wed, 16 Nov 2011 15:21:29 +0100 Thread-Topic: [v6ops] FW: latest copy of rfc6204bis included Thread-Index: AcykBpfOJTAknZMXRIi+MdwoBcCWIgAAOzfwAAU6ZOAAASFIIAAAb2BAAABANPAAAG3HgAARBpNAAABYcsA= Message-ID: <867F4B6A1672E541A94676D556793ACD0C27516D7E@MOPESMBX01.eu.thmulti.com> References: <5B6B2B64C9FE2A489045EEEADDAFF2C30354431D@XMB-RCD-109.cisco.com><000f01cca41d$bcbad730$36308590$@iname.com><5B6B2B64C9FE2A489045EEEADDAFF2C303544351@XMB-RCD-109.cisco.com><001001cca423$889a3580$99cea080$@iname.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303544354@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303544358@XMB-RCD-109.cisco.com> <007401cca469$f6731400$e3593c00$@iname.com> In-Reply-To: <007401cca469$f6731400$e3593c00$@iname.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Mark Townsley \(townsley\)" , "v6ops@ietf.org" Subject: Re: [v6ops] FW: latest copy of rfc6204bis included X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 Nov 2011 14:25:18 -0000 Hm, but doesn't this boil down again to my Q from before: why linking DHCP = to RA (you could maybe make this optional/configurable), and what if no RA = on the link (e.g. in PTP scenario) ? Carl Wuyts GCD System Architect Networking CONNECT DIVISION carl.wuyts@technicolor.com tel.: +32 3 443 65 90 Prins Boudewijnlaan 47=A0=A0-=A0=A02650 Edegem=A0=A0-=A0=A0Belgium Technicolor Delivery Technologies Belgium NV Registered office (maatschappelijke zetel): Prins Boudewijnlaan 47, 2650 Ed= egem, Belgium Company registration number (ondernemingsnummer): 0428837295 - RPR Antwerpe= n Help preserve the color of our world - Think before you print. -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of F= rank Bulk Sent: woensdag 16 november 2011 15:14 To: 'Hemant Singh (shemant)' Cc: Mark Townsley (townsley); v6ops@ietf.org Subject: Re: [v6ops] FW: latest copy of rfc6204bis included It resolves the DHCP storm issue, just that it if an operator mis-configure= s a host or pool in the DHCP configuration it may not be easy for them to g= et the CPE to re-request an IP address again. The use of RA is more immedi= ate (M&O=3D0 =3D> stop SOLICITing) (M|O=3D1 =3D> start SOLICITing). Frank -----Original Message----- From: Hemant Singh (shemant) [mailto:shemant@cisco.com] Sent: Wednesday, November 16, 2011 12:05 AM To: Hemant Singh (shemant); Frank Bulk Cc: Mark Townsley (townsley); v6ops@ietf.org Subject: RE: [v6ops] FW: latest copy of rfc6204bis included Frank, Also why would Ralph's new document in the DHC server not solve the DHCPv6 server storm due to a single DHCv6 client?=20 http://tools.ietf.org/html/draft-droms-dhc-dhcpv6-maxsolrt-update-00 Thanks, Hemant -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of H= emant Singh (shemant) Sent: Wednesday, November 16, 2011 1:55 PM To: Frank Bulk Cc: Mark Townsley (townsley); v6ops@ietf.org Subject: Re: [v6ops] FW: latest copy of rfc6204bis included -----Original Message----- From: Frank Bulk [mailto:frnkblk@iname.com] Sent: Wednesday, November 16, 2011 1:50 PM To: Hemant Singh (shemant) Cc: Mark Townsley (townsley); Victor Kuarsingh; Brzozowski, John; v6ops@iet= f.org Subject: RE: [v6ops] FW: latest copy of rfc6204bis included >Yes, we need to able to have routers with one WAN that can handle RAs from >more than one device (e.g. some kind of change on service provider router >that causes the RA to come from a different address), but we can put in=20 >language in rfc6204 that minimizes the effects of the use case you shared. The CE router has two WAN interfaces (future scope) and the same problem st= ill occurs. A host behind the CE router receives every 1/2 sec an RA with = M bit set and in the next 1/2 sec receives and RA with the M bit cleared.=20 Hemant _______________________________________________ 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 frnkblk@iname.com Wed Nov 16 06:29:26 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E848721F958E for ; Wed, 16 Nov 2011 06:29:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.546 X-Spam-Level: X-Spam-Status: No, score=-1.546 tagged_above=-999 required=5 tests=[AWL=-0.047, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, 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 aLue7O5w1qrA for ; Wed, 16 Nov 2011 06:29:26 -0800 (PST) Received: from premieronline.net (smtp2-3.premieronline.net [96.31.0.28]) by ietfa.amsl.com (Postfix) with ESMTP id 3B5C121F9595 for ; Wed, 16 Nov 2011 06:29:26 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=199.120.69.4; Received: from FRANKBULK (unverified [199.120.69.4]) by premieronline.net (SurgeMail 5.0n) with ESMTP (TLS) id 6825694-1729245 for multiple; Wed, 16 Nov 2011 08:29:25 -0600 From: "Frank Bulk" To: "'Wuyts Carl'" , "'Hemant Singh \(shemant\)'" References: <5B6B2B64C9FE2A489045EEEADDAFF2C30354431D@XMB-RCD-109.cisco.com><000f01cca41d$bcbad730$36308590$@iname.com><5B6B2B64C9FE2A489045EEEADDAFF2C303544351@XMB-RCD-109.cisco.com><001001cca423$889a3580$99cea080$@iname.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303544354@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303544358@XMB-RCD-109.cisco.com> <007401cca469$f6731400$e3593c00$@iname.com> <867F4B6A1672E541A94676D556793ACD0C27516D7E@MOPESMBX01.eu.thmulti.com> In-Reply-To: <867F4B6A1672E541A94676D556793ACD0C27516D7E@MOPESMBX01.eu.thmulti.com> Date: Wed, 16 Nov 2011 08:29:24 -0600 Message-ID: <007501cca46c$236dbf80$6a493e80$@iname.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AcykBpfOJTAknZMXRIi+MdwoBcCWIgAAOzfwAAU6ZOAAASFIIAAAb2BAAABANPAAAG3HgAARBpNAAABYcsAAAD+FUA== Content-Language: en-us X-Authenticated-User: fbulk@premieronline.net X-SpamDetect: : 0.000000 X-Info: aspam skipped due to (g_smite_skip_auth) X-Encryption: SSL encrypted X-MyRbl: Color=Unknown (rbl) Age=0 Spam=0 Notspam=0 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=199.120.69.4 X-IP-stats: Incoming Last 0, First 981, in=1724, out=0, spam=0 ip=199.120.69.4 Cc: "Mark Townsley \(townsley\)" , v6ops@ietf.org Subject: Re: [v6ops] FW: latest copy of rfc6204bis included X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: frnkblk@iname.com List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 14:29:27 -0000 We want to link DHCPv6 to RA because we want different behaviors to = happen. That's why the M and O bits are hints, and already used to suggest to = the client whether it's a managed link and whether there are optional bits = to pick up. Using M and O bits to cause action is nothing new here. If there's no RA in the link there's nothing in rfc6402bis that prevents = the CPE from initiating DHCPv6. Frank -----Original Message----- From: Wuyts Carl [mailto:Carl.Wuyts@technicolor.com]=20 Sent: Wednesday, November 16, 2011 8:21 AM To: frnkblk@iname.com; 'Hemant Singh (shemant)' Cc: Mark Townsley (townsley); v6ops@ietf.org Subject: RE: [v6ops] FW: latest copy of rfc6204bis included Hm, but doesn't this boil down again to my Q from before: why linking = DHCP to RA (you could maybe make this optional/configurable), and what if no = RA on the link (e.g. in PTP scenario) ? Carl Wuyts GCD System Architect Networking CONNECT DIVISION carl.wuyts@technicolor.com tel.: +32 3 443 65 90 Prins Boudewijnlaan 47=A0=A0-=A0=A02650 Edegem=A0=A0-=A0=A0Belgium Technicolor Delivery Technologies Belgium NV Registered office (maatschappelijke zetel): Prins Boudewijnlaan 47, 2650 Edegem, Belgium Company registration number (ondernemingsnummer): 0428837295 - RPR = Antwerpen Help preserve the color of our world - Think before you print. -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Frank Bulk Sent: woensdag 16 november 2011 15:14 To: 'Hemant Singh (shemant)' Cc: Mark Townsley (townsley); v6ops@ietf.org Subject: Re: [v6ops] FW: latest copy of rfc6204bis included It resolves the DHCP storm issue, just that it if an operator = mis-configures a host or pool in the DHCP configuration it may not be easy for them to = get the CPE to re-request an IP address again. The use of RA is more = immediate (M&O=3D0 =3D> stop SOLICITing) (M|O=3D1 =3D> start SOLICITing). Frank -----Original Message----- From: Hemant Singh (shemant) [mailto:shemant@cisco.com] Sent: Wednesday, November 16, 2011 12:05 AM To: Hemant Singh (shemant); Frank Bulk Cc: Mark Townsley (townsley); v6ops@ietf.org Subject: RE: [v6ops] FW: latest copy of rfc6204bis included Frank, Also why would Ralph's new document in the DHC server not solve the DHCPv6 server storm due to a single DHCv6 client?=20 http://tools.ietf.org/html/draft-droms-dhc-dhcpv6-maxsolrt-update-00 Thanks, Hemant -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Hemant Singh (shemant) Sent: Wednesday, November 16, 2011 1:55 PM To: Frank Bulk Cc: Mark Townsley (townsley); v6ops@ietf.org Subject: Re: [v6ops] FW: latest copy of rfc6204bis included -----Original Message----- From: Frank Bulk [mailto:frnkblk@iname.com] Sent: Wednesday, November 16, 2011 1:50 PM To: Hemant Singh (shemant) Cc: Mark Townsley (townsley); Victor Kuarsingh; Brzozowski, John; v6ops@ietf.org Subject: RE: [v6ops] FW: latest copy of rfc6204bis included >Yes, we need to able to have routers with one WAN that can handle RAs from >more than one device (e.g. some kind of change on service provider router >that causes the RA to come from a different address), but we can put in = >language in rfc6204 that minimizes the effects of the use case you shared. The CE router has two WAN interfaces (future scope) and the same problem still occurs. A host behind the CE router receives every 1/2 sec an RA = with M bit set and in the next 1/2 sec receives and RA with the M bit = cleared.=20 Hemant _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From Carl.Wuyts@technicolor.com Wed Nov 16 06:33:43 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 539A421F95D4 for ; Wed, 16 Nov 2011 06:33:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.341 X-Spam-Level: X-Spam-Status: No, score=-5.341 tagged_above=-999 required=5 tests=[AWL=0.658, 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 8eGg6h74-RkY for ; Wed, 16 Nov 2011 06:33:42 -0800 (PST) Received: from na3sys009aog107.obsmtp.com (na3sys009aog107.obsmtp.com [74.125.149.197]) by ietfa.amsl.com (Postfix) with ESMTP id ED81821F95CC for ; Wed, 16 Nov 2011 06:33:40 -0800 (PST) Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob107.postini.com ([74.125.148.12]) with SMTP ID DSNKTsPJwCbCCH6uMe4JhdS4w3T/ZFhpkTao@postini.com; Wed, 16 Nov 2011 06:33:41 PST 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.192.1; Wed, 16 Nov 2011 15:30:43 +0100 Received: from MOPESMBX01.eu.thmulti.com ([169.254.155.121]) by MOPESMAILHC01.eu.thmulti.com ([141.11.100.25]) with mapi; Wed, 16 Nov 2011 15:30:49 +0100 From: Wuyts Carl To: "frnkblk@iname.com" , "'Hemant Singh (shemant)'" Date: Wed, 16 Nov 2011 15:30:45 +0100 Thread-Topic: [v6ops] FW: latest copy of rfc6204bis included Thread-Index: AcykBpfOJTAknZMXRIi+MdwoBcCWIgAAOzfwAAU6ZOAAASFIIAAAb2BAAABANPAAAG3HgAARBpNAAABYcsAAAD+FUAAAFwZA Message-ID: <867F4B6A1672E541A94676D556793ACD0C27516D8B@MOPESMBX01.eu.thmulti.com> References: <5B6B2B64C9FE2A489045EEEADDAFF2C30354431D@XMB-RCD-109.cisco.com><000f01cca41d$bcbad730$36308590$@iname.com><5B6B2B64C9FE2A489045EEEADDAFF2C303544351@XMB-RCD-109.cisco.com><001001cca423$889a3580$99cea080$@iname.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303544354@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303544358@XMB-RCD-109.cisco.com> <007401cca469$f6731400$e3593c00$@iname.com> <867F4B6A1672E541A94676D556793ACD0C27516D7E@MOPESMBX01.eu.thmulti.com> <007501cca46c$236dbf80$6a493e80$@iname.com> In-Reply-To: <007501cca46c$236dbf80$6a493e80$@iname.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Mark Townsley \(townsley\)" , "v6ops@ietf.org" Subject: Re: [v6ops] FW: latest copy of rfc6204bis included X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 Nov 2011 14:33:43 -0000 Ok, as long as it it's an optional thing, it's perfectly fine. Carl Wuyts GCD System Architect Networking CONNECT DIVISION carl.wuyts@technicolor.com tel.: +32 3 443 65 90 Prins Boudewijnlaan 47=A0=A0-=A0=A02650 Edegem=A0=A0-=A0=A0Belgium Technicolor Delivery Technologies Belgium NV Registered office (maatschappelijke zetel): Prins Boudewijnlaan 47, 2650 Ed= egem, Belgium Company registration number (ondernemingsnummer): 0428837295 - RPR Antwerpe= n Help preserve the color of our world - Think before you print. -----Original Message----- From: Frank Bulk [mailto:frnkblk@iname.com]=20 Sent: woensdag 16 november 2011 15:29 To: Wuyts Carl; 'Hemant Singh (shemant)' Cc: Mark Townsley (townsley); v6ops@ietf.org Subject: RE: [v6ops] FW: latest copy of rfc6204bis included We want to link DHCPv6 to RA because we want different behaviors to happen. That's why the M and O bits are hints, and already used to suggest to the c= lient whether it's a managed link and whether there are optional bits to pi= ck up. Using M and O bits to cause action is nothing new here. If there's no RA in the link there's nothing in rfc6402bis that prevents th= e CPE from initiating DHCPv6. Frank -----Original Message----- From: Wuyts Carl [mailto:Carl.Wuyts@technicolor.com] Sent: Wednesday, November 16, 2011 8:21 AM To: frnkblk@iname.com; 'Hemant Singh (shemant)' Cc: Mark Townsley (townsley); v6ops@ietf.org Subject: RE: [v6ops] FW: latest copy of rfc6204bis included Hm, but doesn't this boil down again to my Q from before: why linking DHCP = to RA (you could maybe make this optional/configurable), and what if no RA = on the link (e.g. in PTP scenario) ? Carl Wuyts GCD System Architect Networking CONNECT DIVISION carl.wuyts@technicolor.com tel.: +32 3 443 65 90 Prins Boudewijnlaan 47=A0=A0-=A0=A02650 Edegem=A0=A0-=A0=A0Belgium Technico= lor Delivery Technologies Belgium NV Registered office (maatschappelijke ze= tel): Prins Boudewijnlaan 47, 2650 Edegem, Belgium Company registration num= ber (ondernemingsnummer): 0428837295 - RPR Antwerpen Help preserve the color of our world - Think before you print. -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of F= rank Bulk Sent: woensdag 16 november 2011 15:14 To: 'Hemant Singh (shemant)' Cc: Mark Townsley (townsley); v6ops@ietf.org Subject: Re: [v6ops] FW: latest copy of rfc6204bis included It resolves the DHCP storm issue, just that it if an operator mis-configure= s a host or pool in the DHCP configuration it may not be easy for them to g= et the CPE to re-request an IP address again. The use of RA is more immedi= ate (M&O=3D0 =3D> stop SOLICITing) (M|O=3D1 =3D> start SOLICITing). Frank -----Original Message----- From: Hemant Singh (shemant) [mailto:shemant@cisco.com] Sent: Wednesday, November 16, 2011 12:05 AM To: Hemant Singh (shemant); Frank Bulk Cc: Mark Townsley (townsley); v6ops@ietf.org Subject: RE: [v6ops] FW: latest copy of rfc6204bis included Frank, Also why would Ralph's new document in the DHC server not solve the DHCPv6 server storm due to a single DHCv6 client?=20 http://tools.ietf.org/html/draft-droms-dhc-dhcpv6-maxsolrt-update-00 Thanks, Hemant -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of H= emant Singh (shemant) Sent: Wednesday, November 16, 2011 1:55 PM To: Frank Bulk Cc: Mark Townsley (townsley); v6ops@ietf.org Subject: Re: [v6ops] FW: latest copy of rfc6204bis included -----Original Message----- From: Frank Bulk [mailto:frnkblk@iname.com] Sent: Wednesday, November 16, 2011 1:50 PM To: Hemant Singh (shemant) Cc: Mark Townsley (townsley); Victor Kuarsingh; Brzozowski, John; v6ops@iet= f.org Subject: RE: [v6ops] FW: latest copy of rfc6204bis included >Yes, we need to able to have routers with one WAN that can handle RAs from >more than one device (e.g. some kind of change on service provider router >that causes the RA to come from a different address), but we can put in=20 >language in rfc6204 that minimizes the effects of the use case you shared. The CE router has two WAN interfaces (future scope) and the same problem st= ill occurs. A host behind the CE router receives every 1/2 sec an RA with = M bit set and in the next 1/2 sec receives and RA with the M bit cleared.=20 Hemant _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From lorenzo@google.com Wed Nov 16 08:07:29 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 906301F0C7D for ; Wed, 16 Nov 2011 08:07:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.88 X-Spam-Level: X-Spam-Status: No, score=-102.88 tagged_above=-999 required=5 tests=[AWL=0.096, 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 tgtkcIyuwkxY for ; Wed, 16 Nov 2011 08:07:29 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 060061F0C4E for ; Wed, 16 Nov 2011 08:07:28 -0800 (PST) Received: by ggnr5 with SMTP id r5so4380237ggn.31 for ; Wed, 16 Nov 2011 08:07:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=k1SRRXWyDGEcBqtvVWNTfFVcXeG2lDPIL7gxMIwkB0w=; b=eDGWKtxPs6HVn5gdi20QpblMupFV8TQO9cL1oF63PFXokYV1W16cnT4g0bs/WBadOj 6+mAmMrbwgrDVS/LuGvw== Received: by 10.236.200.194 with SMTP id z42mr2613992yhn.70.1321459648423; Wed, 16 Nov 2011 08:07:28 -0800 (PST) Received: by 10.236.200.194 with SMTP id z42mr2613800yhn.70.1321459647122; Wed, 16 Nov 2011 08:07:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.202.14 with HTTP; Wed, 16 Nov 2011 08:07:06 -0800 (PST) In-Reply-To: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com> References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com> From: Lorenzo Colitti Date: Thu, 17 Nov 2011 00:07:06 +0800 Message-ID: To: Ralph Droms Content-Type: multipart/alternative; boundary=20cf305b1230da0d8e04b1dc4c92 X-System-Of-Record: true Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 16 Nov 2011 16:07:29 -0000 --20cf305b1230da0d8e04b1dc4c92 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Nov 16, 2011 at 09:28, Ralph Droms wrote: > ...is here: > http://tools.ietf.org/html/draft-droms-dhc-dhcpv6-maxsolrt-update-00 > I don't think we should mess with the default SOL_MAX_RT. In some cases (e.g., if a host or CE router is disconnected from the network without link going down), it will cause the host to get stuck asking for DHCPv6 only once every two hours. This will cause it have to wait, on average, a full hour before obtaining IPv6 parameters again. This is much slower than IPv4 and thus is a performance parity issue. Given that this draft defines the option to set SOL_MAX_RT from the DHCPv6 server, why do we need to change the default at all? --20cf305b1230da0d8e04b1dc4c92 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Nov 16, 2011 at 09:28, Ralph Droms <rdroms.ietf@gmail= .com> wrote:

I don't think we should mess wit= h the default SOL_MAX_RT. In some cases (e.g., if a host or CE router is di= sconnected from the network without link going down), it will cause the hos= t to get stuck asking for DHCPv6 only once every two hours. This will cause= it have to wait, on average, a full hour before obtaining=A0IPv6 parameters again.=A0This is much slower than IPv4 and th= us is a performance parity issue.

= Given that this draft defin= es the option to set SOL_MAX_RT from the DHCPv6 server, why do we need to c= hange the default at all?
--20cf305b1230da0d8e04b1dc4c92-- From frnkblk@iname.com Wed Nov 16 10:15:26 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C5D821F9510 for ; Wed, 16 Nov 2011 10:15:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.835 X-Spam-Level: X-Spam-Status: No, score=-1.835 tagged_above=-999 required=5 tests=[AWL=0.264, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w07CBm3wOU+V for ; Wed, 16 Nov 2011 10:15:20 -0800 (PST) Received: from premieronline.net (smtp2-1.premieronline.net [96.31.0.26]) by ietfa.amsl.com (Postfix) with ESMTP id 9A69021F9430 for ; Wed, 16 Nov 2011 10:15:20 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=199.120.69.4; Received: from FRANKBULK (unverified [199.120.69.4]) by premieronline.net (SurgeMail 5.0n) with ESMTP (TLS) id 6837943-1729245 for multiple; Wed, 16 Nov 2011 12:15:17 -0600 From: "Frank Bulk" To: "'Hemant Singh \(shemant\)'" References: <5B6B2B64C9FE2A489045EEEADDAFF2C30354431D@XMB-RCD-109.cisco.com> <000f01cca41d$bcbad730$36308590$@iname.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303544351@XMB-RCD-109.cisco.com> <001001cca423$889a3580$99cea080$@iname.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303544354@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C303544354@XMB-RCD-109.cisco.com> Date: Wed, 16 Nov 2011 12:15:15 -0600 Message-ID: <007c01cca48b$b09d4cd0$11d7e670$@iname.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AcykBpfOJTAknZMXRIi+MdwoBcCWIgAAOzfwAAU6ZOAAASFIIAAAb2BAAABANPAAGXNqsA== Content-Language: en-us X-Authenticated-User: fbulk@premieronline.net X-SpamDetect: : 0.000000 X-Info: aspam skipped due to (g_smite_skip_auth) X-Encryption: SSL encrypted X-MyRbl: Color=Unknown (rbl) Age=0 Spam=0 Notspam=0 Stars=0 Good=4 Friend=0 Surbl=0 Catch=0 r=0 ip=199.120.69.4 X-IP-stats: Incoming Last 0, First 981, in=1729, out=0, spam=0 ip=199.120.69.4 Cc: "Mark Townsley \(townsley\)" , v6ops@ietf.org Subject: Re: [v6ops] FW: latest copy of rfc6204bis included X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: frnkblk@iname.com List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 18:15:26 -0000 Hemant: I don't want to spend too much time talking about future scope items but I still think it's wise to give some passing thought to possible future use/break cases. A CE router with two WAN interfaces does not necessarily replicate on the LAN interface(s) the M/O bits that were received on the WAN interface(s). In fact, in all the SOHO routers I've looked at, the LAN behavior is independently configured. Because I'm not aware of any RFC requirements that say that M/O bits need to be replicated from the WAN to LAN, I don't think that any of the hosts behind the CE will DHCPv6 thrash. Diagram: ISP #1 ISP #2 M=O=0 M|0=1 | | \ / \ / | | WAN 1 WAN 2 ======= | CPE | ======= LAN | M=O=1 | Host with stateful CPE support As facilitated by the current version of rfc6204bis, WAN 1 is not required to issue DHCPv6 solicits. This is the out that the cable folk are needing. But WAN 1 could issue DHCPv6 solicats, and the BBF folk require that. rfc6204bis requires DHCPv6 to start on WAN2. What the LAN does with its RA is independent of WAN1 and WAN2, and which prefixes are or are not advertised -- well, we can discuss that on homenet at a future time. Frank -----Original Message----- From: Hemant Singh (shemant) [mailto:shemant@cisco.com] Sent: Tuesday, November 15, 2011 11:55 PM To: Frank Bulk Cc: Mark Townsley (townsley); Victor Kuarsingh; Brzozowski, John; v6ops@ietf.org Subject: RE: [v6ops] FW: latest copy of rfc6204bis included -----Original Message----- From: Frank Bulk [mailto:frnkblk@iname.com] Sent: Wednesday, November 16, 2011 1:50 PM To: Hemant Singh (shemant) Cc: Mark Townsley (townsley); Victor Kuarsingh; Brzozowski, John; v6ops@ietf.org Subject: RE: [v6ops] FW: latest copy of rfc6204bis included >Yes, we need to able to have routers with one WAN that can handle RAs from >more than one device (e.g. some kind of change on service provider router >that causes the RA to come from a different address), but we can put in >language in rfc6204 that minimizes the effects of the use case you shared. The CE router has two WAN interfaces (future scope) and the same problem still occurs. A host behind the CE router receives every 1/2 sec an RA with M bit set and in the next 1/2 sec receives and RA with the M bit cleared. Hemant From shemant@cisco.com Wed Nov 16 16:06:56 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEDB21F0C4A for ; Wed, 16 Nov 2011 16:06:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.927 X-Spam-Level: X-Spam-Status: No, score=-5.927 tagged_above=-999 required=5 tests=[AWL=0.072, 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 Sp5TAV3bS+db for ; Wed, 16 Nov 2011 16:06:52 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 431141F0C46 for ; Wed, 16 Nov 2011 16:06:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=3735; q=dns/txt; s=iport; t=1321488412; x=1322698012; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=sOyxwcdkM3F89ukgDjVEcA8XXRriv43vzT87+GxE3+I=; b=ANQEAbfPrgYwevOkJHx48bfM1/AAdhNkaVXv6VeVLN+z4ORYOvF2aces ddZbVRQHvQnqCtdyF9gZLPKsC0vERczeIy8fabotxHHtGhljlFr2KqoCF zQ49s8W4zJ2D8kwFRDILZhnY4pjLDyMOn3ThPyZnmBAnkMmAsb+xvA6K2 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AowAAGZPxE6tJXHB/2dsb2JhbABCmXiQDoEFgXIBAQEEAQEBDwEdPgsMBAIBCBEEAQELBhcBBgEmHwgBCAIEARIIGodolSUBnmmJNGMEh2MxkWSMVw X-IronPort-AV: E=Sophos;i="4.69,523,1315180800"; d="scan'208";a="36735306" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-8.cisco.com with ESMTP; 17 Nov 2011 00:06:51 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id pAH06pp0030375; Thu, 17 Nov 2011 00:06:51 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Nov 2011 18:06:51 -0600 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Nov 2011 18:06:47 -0600 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C30354472F@XMB-RCD-109.cisco.com> In-Reply-To: <867F4B6A1672E541A94676D556793ACD0C27516D7E@MOPESMBX01.eu.thmulti.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] FW: latest copy of rfc6204bis included Thread-Index: AcykBpfOJTAknZMXRIi+MdwoBcCWIgAAOzfwAAU6ZOAAASFIIAAAb2BAAABANPAAAG3HgAARBpNAAABYcsAAFGoc4A== References: <5B6B2B64C9FE2A489045EEEADDAFF2C30354431D@XMB-RCD-109.cisco.com><000f01cca41d$bcbad730$36308590$@iname.com><5B6B2B64C9FE2A489045EEEADDAFF2C303544351@XMB-RCD-109.cisco.com><001001cca423$889a3580$99cea080$@iname.com><5B6B2B64C9FE2A489045EEEADDAFF2C303544354@XMB-RCD-109.cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C303544358@XMB-RCD-109.cisco.com> <007401cca469$f6731400$e3593c00$@iname.com> <867F4B6A1672E541A94676D556793ACD0C27516D7E@MOPESMBX01.eu.thmulti.com> From: "Hemant Singh (shemant)" To: "Wuyts Carl" , X-OriginalArrivalTime: 17 Nov 2011 00:06:51.0499 (UTC) FILETIME=[CEAA83B0:01CCA4BC] Cc: v6ops@ietf.org Subject: Re: [v6ops] FW: latest copy of rfc6204bis included X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 Nov 2011 00:06:57 -0000 The DSL Broadband forum has already decoupled DHCPv6 from IPv6 ND RA in = their standards. I have nothing further to say on using the M and the O = bits to start/stop DHCPv6 beyond what I have said already - bad idea. Hemant -----Original Message----- From: Wuyts Carl [mailto:Carl.Wuyts@technicolor.com]=20 Sent: Wednesday, November 16, 2011 9:21 AM To: frnkblk@iname.com; Hemant Singh (shemant) Cc: Mark Townsley (townsley); v6ops@ietf.org Subject: RE: [v6ops] FW: latest copy of rfc6204bis included Hm, but doesn't this boil down again to my Q from before: why linking = DHCP to RA (you could maybe make this optional/configurable), and what = if no RA on the link (e.g. in PTP scenario) ? Carl Wuyts GCD System Architect Networking CONNECT DIVISION carl.wuyts@technicolor.com tel.: +32 3 443 65 90 Prins Boudewijnlaan 47=A0=A0-=A0=A02650 Edegem=A0=A0-=A0=A0Belgium Technicolor Delivery Technologies Belgium NV Registered office (maatschappelijke zetel): Prins Boudewijnlaan 47, 2650 = Edegem, Belgium Company registration number (ondernemingsnummer): 0428837295 - RPR = Antwerpen Help preserve the color of our world - Think before you print. -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Frank Bulk Sent: woensdag 16 november 2011 15:14 To: 'Hemant Singh (shemant)' Cc: Mark Townsley (townsley); v6ops@ietf.org Subject: Re: [v6ops] FW: latest copy of rfc6204bis included It resolves the DHCP storm issue, just that it if an operator = mis-configures a host or pool in the DHCP configuration it may not be = easy for them to get the CPE to re-request an IP address again. The use = of RA is more immediate (M&O=3D0 =3D> stop SOLICITing) (M|O=3D1 =3D> start SOLICITing). Frank -----Original Message----- From: Hemant Singh (shemant) [mailto:shemant@cisco.com] Sent: Wednesday, November 16, 2011 12:05 AM To: Hemant Singh (shemant); Frank Bulk Cc: Mark Townsley (townsley); v6ops@ietf.org Subject: RE: [v6ops] FW: latest copy of rfc6204bis included Frank, Also why would Ralph's new document in the DHC server not solve the DHCPv6 server storm due to a single DHCv6 client?=20 http://tools.ietf.org/html/draft-droms-dhc-dhcpv6-maxsolrt-update-00 Thanks, Hemant -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Hemant Singh (shemant) Sent: Wednesday, November 16, 2011 1:55 PM To: Frank Bulk Cc: Mark Townsley (townsley); v6ops@ietf.org Subject: Re: [v6ops] FW: latest copy of rfc6204bis included -----Original Message----- From: Frank Bulk [mailto:frnkblk@iname.com] Sent: Wednesday, November 16, 2011 1:50 PM To: Hemant Singh (shemant) Cc: Mark Townsley (townsley); Victor Kuarsingh; Brzozowski, John; = v6ops@ietf.org Subject: RE: [v6ops] FW: latest copy of rfc6204bis included >Yes, we need to able to have routers with one WAN that can handle RAs from >more than one device (e.g. some kind of change on service provider router >that causes the RA to come from a different address), but we can put in = >language in rfc6204 that minimizes the effects of the use case you shared. The CE router has two WAN interfaces (future scope) and the same problem = still occurs. A host behind the CE router receives every 1/2 sec an RA = with M bit set and in the next 1/2 sec receives and RA with the M bit = cleared.=20 Hemant _______________________________________________ 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 shemant@cisco.com Wed Nov 16 16:16:05 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DFBF11E809A for ; Wed, 16 Nov 2011 16:16:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.927 X-Spam-Level: X-Spam-Status: No, score=-5.927 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 nk6wqsD-RNEF for ; Wed, 16 Nov 2011 16:16:04 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id D8CEB11E8099 for ; Wed, 16 Nov 2011 16:16:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=14574; q=dns/txt; s=iport; t=1321488964; x=1322698564; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=wyZxI7cseqXRzbBihrK4qhFrksyaQ+qJr1YjpZVqsz4=; b=RU4Ml/DBeQqy3pLU/8/rZweOSz8anshLZYBqRJK4EGEpIyhVbReBnbp6 2bc11/SwQuWK3iTXaiBbxBQflSkqIaXpv55IB7L7ajahpDsG6g3G7cmtX xqe7jwNIWeCQCpyVY53l8suotscJSrmecKDV7g2Pl4j4qRhCLBjjcFzQ5 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AowAANlRxE6tJXG//2dsb2JhbABCgk2XK4gVAYd4gQWBcgEBAQMBAQEBDwEJEQM+CwUHBAIBCBEEAQELBhcBBgEmHwkIAQEEEwgBGYdgCJUnAZ5riTRjBIgUkWSMVw X-IronPort-AV: E=Sophos;i="4.69,523,1315180800"; d="scan'208,217";a="36724959" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-6.cisco.com with ESMTP; 17 Nov 2011 00:16:03 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id pAH0G3jD008220 for ; Thu, 17 Nov 2011 00:16:03 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Nov 2011 18:16:03 -0600 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCA4BE.176395D7" Date: Wed, 16 Nov 2011 18:16:00 -0600 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C303544735@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C30354436E@XMB-RCD-109.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] 6rd Sunsetting Thread-Index: AcykLe9E8+BD7WIjTbKJouEVl5VMJgAD8WKQACAISYA= References: <68DAB112-6E32-45FE-9AB7-A34E64898F60@cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30354436E@XMB-RCD-109.cisco.com> From: "Hemant Singh (shemant)" To: "Fred Baker (fred)" X-OriginalArrivalTime: 17 Nov 2011 00:16:03.0077 (UTC) FILETIME=[176EA350:01CCA4BE] Cc: v6ops@ietf.org Subject: Re: [v6ops] 6rd Sunsetting X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 Nov 2011 00:16:05 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCA4BE.176395D7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Chairs, =20 Please also note from the email below that the rfc6204bis has no dependency on any Softwires 6rd sunsetting document. The rfc6204bis document 6rd sunsetting text is already complete. =20 Hemant =20 From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Hemant Singh (shemant) Sent: Wednesday, November 16, 2011 5:02 PM To: Fred Baker (fred); Hans Liu Cc: Alexandre Cassen; v6ops@ietf.org; Claire Cheng Subject: Re: [v6ops] 6rd Sunsetting =20 Folks, The use cases that Fred outlined are exactly what we authors of the document considered and the text in section 4.4.3 of the rfc6204bis document reflects the fact. The relevant text for the section is the first paragraph of the section, bullets 1, 2, 5, and 6, and the last paragraph covers sunsetting of 6rd.=20 =20 http://tools.ietf.org/id/draft-ietf-v6ops-6204bis-02.txt =20 Thanks, Fred. Hemant -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Fred Baker (fred) Sent: Wednesday, November 16, 2011 3:03 PM To: Hans Liu Cc: Alexandre Cassen; v6ops@ietf.org WG; Claire Cheng Subject: Re: [v6ops] 6rd Sunsetting The use cases I can think of are: 1) I used to run 6rd and have now deployed native service, but have not yet turned 6rd off. 2) I am using 6rd in one place and native service somewhere else. The second case is a pretty common coexistence case, I should think, but the two configurations don't conflict because they are different parts of the network. The first case is one that is presumably transitory but will be common during a switchover. I think the argument for thinking about routing is to direct traffic to the wider PMTU when possible and to have native deployment obsolete 6rd deployment quickly. If the route metrics are the same, one would expect some traffic to use native and some to use 6rd connectivity, which could be confusing for someone expecting the 6rd traffic to go to null. On Nov 15, 2011, at 4:17 PM, Hans Liu wrote: > Excuse me Mark, I still don't have an idea in what kind of use case > should we have 6rd and Native Dual Stack at the same time in the > network? >=20 > Regards, > Hans >=20 > On Tue, Nov 15, 2011 at 4:01 PM, Mark Townsley wrote: >>=20 >> Alexandre and I just finished up a -00 that describes two methods for moving >> a 6rd deployment to native IPv6. Apologies for not getting this out before >> the meeting. >> http://www.ietf.org/id/draft-townsley-v6ops-6rd-sunsetting-00.txt >>=20 >> Abstract >>=20 >> This document provides guidelines for transitioning an IPv6 >> deployment using IPv6 Rapid Deployment (6rd) to an IPv6 deployment >> using Native IPv6. It is targeted at both 6rd operators and 6rd >> implementors." >>=20 >> - Mark >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >>=20 >=20 >=20 >=20 > --=20 > Instead of following the fashion, we lead it through. > _______________________________________________ > 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 ------_=_NextPart_001_01CCA4BE.176395D7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [v6ops] 6rd Sunsetting

Chairs,

 

Please also note from the email below that the rfc6204bis has no = dependency on any Softwires 6rd sunsetting document.   The = rfc6204bis document 6rd sunsetting text is already = complete.

 

Hemant

 

From:= = v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of = Hemant Singh (shemant)
Sent: Wednesday, November 16, 2011 = 5:02 PM
To: Fred Baker (fred); Hans Liu
Cc: = Alexandre Cassen; v6ops@ietf.org; Claire Cheng
Subject: Re: = [v6ops] 6rd Sunsetting

 

Folks,

The use cases that Fred outlined are = exactly what we authors of the document considered and the text in = section 4.4.3 of the rfc6204bis document reflects the fact.  The = relevant text for the section is the first paragraph of the section, = bullets 1, 2, 5, and 6, and = the last paragraph covers sunsetting of 6rd. =

 

http://tools.ietf.org/id/draft-ietf-v6ops-= 6204bis-02.txt

Thanks, = Fred.

Hemant

-----Original Message-----
From: = v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org]= On Behalf Of Fred Baker (fred)
Sent: Wednesday, November 16, 2011 = 3:03 PM
To: Hans Liu
Cc: Alexandre Cassen; v6ops@ietf.org WG; = Claire Cheng
Subject: Re: [v6ops] 6rd = Sunsetting

The use cases I can think of = are:

1) I = used to run 6rd and have now deployed native service, but have not yet = turned 6rd off.

2) I am using 6rd in one place and native = service somewhere else.

The second case is a pretty common = coexistence case, I should think, but the two configurations don't = conflict because they are different parts of the network. The first case = is one that is presumably transitory but will be common during a = switchover.

I think the argument for thinking about = routing is to direct traffic to the wider PMTU when possible and to have = native deployment obsolete 6rd deployment quickly. If the route metrics = are the same, one would expect some traffic to use native and some to = use 6rd connectivity, which could be confusing for someone expecting the = 6rd traffic to go to null.

On Nov 15, 2011, at 4:17 PM, Hans Liu = wrote:

> = Excuse me Mark, I still don't have an idea in what kind of use = case

> = should we have 6rd and Native Dual Stack at the same time in = the

> = network?

>

> = Regards,

> Hans

>

> On Tue, Nov 15, 2011 at 4:01 PM, = Mark Townsley <mark@townsley.net> = wrote:

>>

>> Alexandre and I just finished up = a -00 that describes two methods for = moving

>> a 6rd deployment to native IPv6. = Apologies for not getting this out before

>> the = meeting.

>> http://www.ietf.org/id/draft-townsley-v6ops-6rd-sunsetting-00.txt

>> =

>> = Abstract

>>

>>   This document = provides guidelines for transitioning an = IPv6

>>   deployment using = IPv6 Rapid Deployment (6rd) to an IPv6 = deployment

>>   using Native = IPv6.  It is targeted at both 6rd operators and = 6rd

>>   = implementors."

>>

>> - = Mark

>> = _______________________________________________

<= span style=3D'font-family:Consolas'>>> v6ops mailing = list

>> = v6ops@ietf.org

>> https://www.ietf.org= /mailman/listinfo/v6ops

>>

>>

>

>

>

> --

> Instead of following the fashion, we = lead it through.

> = _______________________________________________

<= span style=3D'font-family:Consolas'>> 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

------_=_NextPart_001_01CCA4BE.176395D7-- From shemant@cisco.com Wed Nov 16 16:19:11 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9241F11E8099 for ; Wed, 16 Nov 2011 16:19:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.228 X-Spam-Level: X-Spam-Status: No, score=-6.228 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jzLcXZ1C8wOt for ; Wed, 16 Nov 2011 16:19:05 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 40F0811E809A for ; Wed, 16 Nov 2011 16:19:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=4734; q=dns/txt; s=iport; t=1321489145; x=1322698745; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=LulkLZZ96Zh/HYCt1kFqa2dNj2mNq5HpydkA6OmaiJU=; b=WjaZ1rv9/kNRycSzBy0X09LYxM5QbGdNFqZMStys0v66/ALz2vMsnOnF gu7yJ+HSZ/y24IyThCU79+PL2rst+KOtXi5t5UL0dmj398cngc5dLhNY4 GGt9nlco/Ev+smWPNd5fwicpBBd92hJrwLo1P5aqc9fXbgTTfJPOOTyuv 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AowAAMpSxE6tJXHB/2dsb2JhbABCgk2XK5AOgQWBcgEBAQMBEgEJEQNJBQsCAQgRBAEBCwYXAQYBRQkIAQEEARIIGodglD0BnmuJNGMEiBSRZIM6iR0 X-IronPort-AV: E=Sophos;i="4.69,523,1315180800"; d="scan'208,217";a="36731179" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-3.cisco.com with ESMTP; 17 Nov 2011 00:19:04 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id pAH0J4gW003475; Thu, 17 Nov 2011 00:19:04 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Nov 2011 18:19:04 -0600 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCA4BE.837897B8" Date: Wed, 16 Nov 2011 18:19:02 -0600 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C30354473D@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] DHCPv6 option for MAX_SOL_RT Thread-Index: Acyked5j2WMz18C/Q5ywnOM8K8GwUgARGBGA References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com> From: "Hemant Singh (shemant)" To: "Lorenzo Colitti" , "Ralph Droms" X-OriginalArrivalTime: 17 Nov 2011 00:19:04.0473 (UTC) FILETIME=[838D7890:01CCA4BE] Cc: v6ops@ietf.org Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 Nov 2011 00:19:11 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCA4BE.837897B8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Lorenzo, =20 From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Lorenzo Colitti Sent: Thursday, November 17, 2011 12:07 AM To: Ralph Droms Cc: v6ops@ietf.org Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT =20 =20 > In some cases (e.g., if a host or CE router is disconnected from the network without link going down), it will >cause the host to get stuck asking for DHCPv6 only once every >two hours.=20 =20 How does a node get disconnected from the network without the node's link going down? Please give an example? =20 Hemant =20 ------_=_NextPart_001_01CCA4BE.837897B8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Lorenzo,

 

From:= = v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of = Lorenzo Colitti
Sent: Thursday, November 17, 2011 12:07 = AM
To: Ralph Droms
Cc: = v6ops@ietf.org
Subject: Re: [v6ops] DHCPv6 option for = MAX_SOL_RT

 

 

> In some = cases (e.g., if a host or CE router is disconnected from the network = without link going down), it will >cause the host to get stuck asking = for DHCPv6 only once every >two = hours.

 

How does a node get disconnected from the network without the = node’s link going down?  Please give an = example?

 

Hemant

 

------_=_NextPart_001_01CCA4BE.837897B8-- From joelja@bogus.com Wed Nov 16 16:31:28 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1413E11E809A for ; Wed, 16 Nov 2011 16:31:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.213 X-Spam-Level: X-Spam-Status: No, score=-102.213 tagged_above=-999 required=5 tests=[AWL=-0.214, 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 9SMsaTvMSw9P for ; Wed, 16 Nov 2011 16:31:27 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id A1C0311E8094 for ; Wed, 16 Nov 2011 16:31:27 -0800 (PST) Received: from dhcp-2510.meeting.ietf.org (dhcp-2510.meeting.ietf.org [130.129.37.16]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id pAH0VJJ8040796 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 17 Nov 2011 00:31:21 GMT (envelope-from joelja@bogus.com) Message-ID: <4EC455D6.8030601@bogus.com> Date: Thu, 17 Nov 2011 08:31:18 +0800 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Hemant Singh (shemant)" References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30354473D@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C30354473D@XMB-RCD-109.cisco.com> Content-Type: text/plain; charset=windows-1252 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, 17 Nov 2011 00:31:22 +0000 (UTC) Cc: v6ops@ietf.org, Ralph Droms Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 Nov 2011 00:31:28 -0000 On 11/17/11 08:19 , Hemant Singh (shemant) wrote: > Lorenzo, > > > > *From:*v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] *On Behalf > Of *Lorenzo Colitti > *Sent:* Thursday, November 17, 2011 12:07 AM > *To:* Ralph Droms > *Cc:* v6ops@ietf.org > *Subject:* Re: [v6ops] DHCPv6 option for MAX_SOL_RT > > > > > >> In some cases (e.g., if a host or CE router is disconnected from the > network without link going down), it will >cause the host to get stuck > asking for DHCPv6 only once every >two hours. > > > > How does a node get disconnected from the network without the node’s > link going down? Please give an example? l2 vs l1 segmentation... > > Hemant > > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From Ted.Lemon@nominum.com Wed Nov 16 16:38:48 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C501111E808F for ; Wed, 16 Nov 2011 16:38:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.561 X-Spam-Level: X-Spam-Status: No, score=-106.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 m6gtUqElNQ0i for ; Wed, 16 Nov 2011 16:38:48 -0800 (PST) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id C29AD11E8086 for ; Wed, 16 Nov 2011 16:38:47 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKTsRXlwTcIYZnYW4jenMFOsoU3yJkA/NI@postini.com; Wed, 16 Nov 2011 16:38:47 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 60E0F1B82A8 for ; Wed, 16 Nov 2011 16:38:46 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id C5D6C19005D; Wed, 16 Nov 2011 16:38:43 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.01.0339.001; Wed, 16 Nov 2011 16:38:43 -0800 From: Ted Lemon To: Joel jaeggli Thread-Topic: [v6ops] DHCPv6 option for MAX_SOL_RT Thread-Index: AQHMpBVS9v5OyU3dDEaf8biIUoZIIJWwMYMAgACJcgCAAANuAP//e/aA Date: Thu, 17 Nov 2011 00:38:43 +0000 Message-ID: References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30354473D@XMB-RCD-109.cisco.com>, <4EC455D6.8030601@bogus.com> In-Reply-To: <4EC455D6.8030601@bogus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" , Ralph Droms Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 Nov 2011 00:38:48 -0000 On Nov 17, 2011, at 8:31 AM, "Joel jaeggli" wrote: > l2 vs l1 segmentation... Wouldn't there be evidence of this because you'd see different RAs? From joelja@bogus.com Wed Nov 16 16:41:37 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D23B1F0C35 for ; Wed, 16 Nov 2011 16:41:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VkHI6ElxGJG7 for ; Wed, 16 Nov 2011 16:41:37 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 30B9421F8C06 for ; Wed, 16 Nov 2011 16:41:37 -0800 (PST) Received: from dhcp-2510.meeting.ietf.org (dhcp-2510.meeting.ietf.org [130.129.37.16]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id pAH0fUgR041000 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 17 Nov 2011 00:41:33 GMT (envelope-from joelja@bogus.com) Message-ID: <4EC4583A.1080509@bogus.com> Date: Thu, 17 Nov 2011 08:41:30 +0800 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Ted Lemon References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30354473D@XMB-RCD-109.cisco.com>, <4EC455D6.8030601@bogus.com> In-Reply-To: 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]); Thu, 17 Nov 2011 00:41:34 +0000 (UTC) Cc: "v6ops@ietf.org" , Ralph Droms Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 Nov 2011 00:41:37 -0000 On 11/17/11 08:38 , Ted Lemon wrote: > On Nov 17, 2011, at 8:31 AM, "Joel jaeggli" wrote: >> l2 vs l1 segmentation... > > Wouldn't there be evidence of this because you'd see different RAs? or none at all. From Ted.Lemon@nominum.com Wed Nov 16 16:59:56 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D8291F0C35 for ; Wed, 16 Nov 2011 16:59:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.562 X-Spam-Level: X-Spam-Status: No, score=-106.562 tagged_above=-999 required=5 tests=[AWL=0.037, 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 DrpGYqCm6tE3 for ; Wed, 16 Nov 2011 16:59:55 -0800 (PST) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id 7D17921F8726 for ; Wed, 16 Nov 2011 16:59:55 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKTsRciQ+D4Lbq+Y9PWhbLyYPiGNfz2AXd@postini.com; Wed, 16 Nov 2011 16:59:55 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 4E87A1B82E1 for ; Wed, 16 Nov 2011 16:59:53 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 41DCF19005D; Wed, 16 Nov 2011 16:59:53 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.01.0339.001; Wed, 16 Nov 2011 16:59:53 -0800 From: Ted Lemon To: Joel jaeggli Thread-Topic: [v6ops] DHCPv6 option for MAX_SOL_RT Thread-Index: AQHMpBVS9v5OyU3dDEaf8biIUoZIIJWwMYMAgACJcgCAAANuAP//e/aAgACG4wD//38HcA== Date: Thu, 17 Nov 2011 00:59:53 +0000 Message-ID: <03A04F9E-5BD9-4FC6-9301-D55CEC21BD18@nominum.com> References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30354473D@XMB-RCD-109.cisco.com>, <4EC455D6.8030601@bogus.com> , <4EC4583A.1080509@bogus.com> In-Reply-To: <4EC4583A.1080509@bogus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" , Ralph Droms Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 Nov 2011 00:59:56 -0000 On Nov 17, 2011, at 8:41 AM, "Joel jaeggli" wrote: > or none at all. Indeed. Point being that we can probably figure out a way to make sure th= at this doesn't happen. From shemant@cisco.com Wed Nov 16 17:27:50 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 309F21F0C4A for ; Wed, 16 Nov 2011 17:27:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.232 X-Spam-Level: X-Spam-Status: No, score=-6.232 tagged_above=-999 required=5 tests=[AWL=0.367, 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 79NhBJLQiieG for ; Wed, 16 Nov 2011 17:27:49 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id A1BCA21F847B for ; Wed, 16 Nov 2011 17:27:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=551; q=dns/txt; s=iport; t=1321493269; x=1322702869; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=p4B+0SN3yFhR5VDRWIHPya2p2nZ+MWzUUfihMEaU0Fs=; b=knYTMbVL8JZEVDFB31XQC1DkNubpUCmlC8C+g4akYVetaV4uBbY/g3kd ZQwj8MMOktHinU3K1H5HFxZ/WZetrruyxKHZKvgSHAKyvWCpGequRFry/ gIj6aFhaSf3qqjXXtvn77i7BClx2TrYojxrf/BTjCKSWpZElXBM2/7e41 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AowAAAxixE6tJXHA/2dsb2JhbABCmXiQDoEFgXIBAQEEEgEdCj8MBAIBCBEEAQELBhcBBgFFCQgBAQQTCBqcUwGeaIk0YwSIFJFkgzqJHQ X-IronPort-AV: E=Sophos;i="4.69,524,1315180800"; d="scan'208";a="36744151" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-3.cisco.com with ESMTP; 17 Nov 2011 01:27:49 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id pAH1RnXl012828; Thu, 17 Nov 2011 01:27:49 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Nov 2011 19:27:48 -0600 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Nov 2011 19:27:47 -0600 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C303544761@XMB-RCD-109.cisco.com> In-Reply-To: <4EC455D6.8030601@bogus.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] DHCPv6 option for MAX_SOL_RT Thread-Index: AcykwDwk3BAkUPG1SAubDrNBVEs32wAB0fLg References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30354473D@XMB-RCD-109.cisco.com> <4EC455D6.8030601@bogus.com> From: "Hemant Singh (shemant)" To: "Joel jaeggli" X-OriginalArrivalTime: 17 Nov 2011 01:27:48.0897 (UTC) FILETIME=[1DE6A110:01CCA4C8] Cc: v6ops@ietf.org, Ralph Droms Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 Nov 2011 01:27:50 -0000 -----Original Message----- From: Joel jaeggli [mailto:joelja@bogus.com]=20 Sent: Thursday, November 17, 2011 8:31 AM To: Hemant Singh (shemant) Cc: Lorenzo Colitti; Ralph Droms; v6ops@ietf.org Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT >l2 vs l1 segmentation... Now I remember also one case that I mentioned in the cpe router design team. There is a network hub between the broadband modem and the CPE router. Even if the modem's Ethernet port signal link down state, the hub does not transmit such messages. =20 Hemant From marka@isc.org Wed Nov 16 17:35:10 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B854211E80B7 for ; Wed, 16 Nov 2011 17:35:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.445 X-Spam-Level: X-Spam-Status: No, score=-2.445 tagged_above=-999 required=5 tests=[AWL=0.154, 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 6TFCHAaWXbRM for ; Wed, 16 Nov 2011 17:35:09 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id A456811E8081 for ; Wed, 16 Nov 2011 17:35:09 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 5693FC9424; Thu, 17 Nov 2011 01:34:59 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 1C304216C6B; Thu, 17 Nov 2011 01:34:59 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 19F35179A55F; Thu, 17 Nov 2011 12:34:52 +1100 (EST) To: Ray Hunter From: Mark Andrews References: <20111115062859.14026.42405.idtracker@ietfa.amsl.com> <4EC2ABA8.4020303@globis.net> <4EC2FD24.1090303@gmail.com> <4EC37529.4070505@globis.net> In-reply-to: Your message of "Wed, 16 Nov 2011 09:32:41 BST." <4EC37529.4070505@globis.net> Date: Thu, 17 Nov 2011 12:34:51 +1100 Message-Id: <20111117013452.19F35179A55F@drugs.dv.isc.org> Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 01:35:10 -0000 Why don't apply some of the techinques from SIDR and have CPE generate as public key pair use that to validate that it got a prefix from one ISP and is permitted to use those source address to the other ISP. This can be completely automated. ISP servicing a area just need to know each others public keys. This really isn't beyound the hardware capabilities of any CPE box on the market today. Lets do source address filtering correctly. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From brian.e.carpenter@gmail.com Wed Nov 16 17:57:04 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC221F0C64 for ; Wed, 16 Nov 2011 17:57:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.544 X-Spam-Level: X-Spam-Status: No, score=-103.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XX9tsU2hmwJM for ; Wed, 16 Nov 2011 17:57:03 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id C45311F0C70 for ; Wed, 16 Nov 2011 17:57:03 -0800 (PST) Received: by ywt34 with SMTP id 34so505985ywt.31 for ; Wed, 16 Nov 2011 17:57:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=+MNx1p/YCqIvBtLJFEHqMtGKdkw3NiJeMj0OT1euCqw=; b=gsQWIJnTIHz8IK0Fht74NxXgOjyX+GBX+1DTcuPx66GeN7VtNc7PdsdmePBtyBLHuZ UfYSzhRjOiCVLao6qnBcpiyhOF79X7hKw3mRAtQ2RXV94HHTLML4AX/G4m2M80tyYfYu NRbjEas4htbGzaST9Lt0/190u029Kdzh3/E4E= Received: by 10.236.181.164 with SMTP id l24mr5988767yhm.22.1321495023445; Wed, 16 Nov 2011 17:57:03 -0800 (PST) Received: from [130.129.19.92] (dhcp-135c.meeting.ietf.org. [130.129.19.92]) by mx.google.com with ESMTPS id h45sm2995096yhm.15.2011.11.16.17.57.01 (version=SSLv3 cipher=OTHER); Wed, 16 Nov 2011 17:57:02 -0800 (PST) Message-ID: <4EC469E7.9010602@gmail.com> Date: Thu, 17 Nov 2011 14:56:55 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mark Andrews References: <20111115062859.14026.42405.idtracker@ietfa.amsl.com> <4EC2ABA8.4020303@globis.net> <4EC2FD24.1090303@gmail.com> <4EC37529.4070505@globis.net> <20111117013452.19F35179A55F@drugs.dv.isc.org> In-Reply-To: <20111117013452.19F35179A55F@drugs.dv.isc.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Ray Hunter , v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 01:57:04 -0000 I agree that we need a secure automated solution of some kind. > ISP servicing a area just need > to know each others public keys. That doesn't solve the general case, because multinationals tend to be connected to the Internet at very widely separated locations. So I think the correct statment is ISP just need to know each others public keys. That's a more difficult trust model, but not insoluble (for example, a trusted public key repository at each RIR). Regards Brian On 2011-11-17 14:34, Mark Andrews wrote: > Why don't apply some of the techinques from SIDR and have CPE > generate as public key pair use that to validate that it got a > prefix from one ISP and is permitted to use those source address > to the other ISP. > > This can be completely automated. ISP servicing a area just need > to know each others public keys. > > This really isn't beyound the hardware capabilities of any CPE > box on the market today. > > Lets do source address filtering correctly. > From leo.liubing@huawei.com Wed Nov 16 18:43:03 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21C2221F8B10; Wed, 16 Nov 2011 18:43:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.156 X-Spam-Level: X-Spam-Status: No, score=-4.156 tagged_above=-999 required=5 tests=[AWL=-1.042, BAYES_00=-2.599, CN_BODY_80=0.532, J_CHICKENPOX_13=0.6, J_CHICKENPOX_36=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 6ptxDcg3kNmX; Wed, 16 Nov 2011 18:43:02 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 461AC11E80B0; Wed, 16 Nov 2011 18:43:02 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUS000VQA5EWV@szxga05-in.huawei.com>; Thu, 17 Nov 2011 10:41:38 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUS006GYA5E9N@szxga05-in.huawei.com>; Thu, 17 Nov 2011 10:41:38 +0800 (CST) Received: from szxeml206-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFA84953; Thu, 17 Nov 2011 10:41:37 +0800 Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 17 Nov 2011 10:41:32 +0800 Received: from SZXEML509-MBS.china.huawei.com ([169.254.2.220]) by szxeml403-hub.china.huawei.com ([10.82.67.35]) with mapi id 14.01.0323.003; Thu, 17 Nov 2011 10:36:47 +0800 Date: Thu, 17 Nov 2011 02:36:47 +0000 From: "Leo Liu(bing)" X-Originating-IP: [172.24.2.41] To: "renum@ietf.org" , "homenet@ietf.org" , "v6ops@ietf.org" Message-id: <8AE0F17B87264D4CAC7DE0AA6C406F4523668C32@szxeml509-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: [Homenet][6renum][v6ops] ULA discussion Thread-index: Acyk0cBJgV/lCELMRGui5tWz0sirpA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Subject: [v6ops] [Homenet][6renum] ULA discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 Nov 2011 02:43:03 -0000 SGksIGFsbA0KSW4gVHVlc2RheSdzIEhvbWVuZXQgV0cgbWVldGluZywgdGhlcmUgd2FzIGEgYnJp ZWYgZGlzY3Vzc2lvbiBhYm91dCB3aGV0aGVyIHRvIHVzZSBVTEEsIGJ1dCBubyBjb25zZW5zdXMg YWNoaWV2ZWQuDQoNCkl0IHdhcyBxdWl0ZSB0aGUgc2FtZSBzaXR1YXRpb24gYXMgaW4gNnJlbnVt IFdHLiBXZSB1c2VkIHRvIGRpc2N1c3MgVUxBIHVzYWdlIHRvIGF2b2lkIHNvbWUgcmVudW1iZXJp bmcsIGJ1dCB0aGVyZSdzIG5vIGNvbnNlbnN1cyB5ZXQuIEFzIHRoZSBjaGFpciBzdWdnZXN0ZWQs IHdlIHRob3VnaHQgdGhlIFVMQSB0b3BpYyBpbnZvbHZpbmcgY29tbW9uIElQdjYgZGVwbG95bWVu dCBjb25zaWRlcmF0aW9uLiBGb3IgZXhhbXBsZSwgd2hldGhlciBVTEEtb25seStOQVQgaXMgYWNj ZXB0YWJsZSBvciBub3Q7IFVMQStHbG9iYWwgbXVsdGlwbGUgYWRkcmVzc2luZyBjb25zaWRlciBy ZWNvbW1lbmRlZCBhcyBwcm92aWRpbmcgc3RhYmxlIGxvY2FsIGNvbW11bmljYXRpb24sIG9yIG5v dCByZWNvbW1lbmRlZCBhcyBhZGRpbmcgdG9vIG11Y2ggb3BlcmF0aW9uYWwgY29tcGxleGl0eS4N Cg0KU28gd2UgcHJvZHVjZWQgYSBkcmFmdCBpbiB2Nm9wcyBpbnRlbmQgdG8gZGlzY3VzcyB0aGUg dG9waWMgYW1vbmcgbW9yZSBwZW9wbGUuDQpJZiB5b3UgY2FyZSBhYm91dCBVTEEsIGhvcGUgeW91 IGNhbiBqb2luIHRoZSBkaXNjdXNzaW9uIGluIHY2b3BzIHRoaXMgYWZ0ZXJub29uKFRodXJzZGF5 KSBhdCAxMzowMC4gKFVMQSB3aWxsIGJlIHRoZSBmaXJzdCB0byBiZSBwcmVzZW50ZWQpDQoNClRo YW5rcywNCkJpbmcNCg0KVGhlIHNsaWRlc6O6aHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5n cy84Mi9zbGlkZXMvdjZvcHMtOC5wcHQgIA0Ko6hJdCBpcyBhIGxpdHRsZSBkaWZmZXJlbnQgZnJv bSB0aGUgb3JpZ2luYWwgZHJhZnQgc2luY2Ugd2UgaW5jbHVkZWQgc29tZSBmZWVkYmFjayBhZnRl ciBzdWJtaXR0aW5nIHRoZSAwMCB2ZXJzaW9uo6kNClRoZSBkcmFmdDogaHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtbGl1LXY2b3BzLXVsYS11c2FnZS1hbmFseXNpcy0wMC5odG1s From mark@townsley.net Wed Nov 16 21:12:49 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30D631F0C42; Wed, 16 Nov 2011 21:12:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=-0.616, BAYES_00=-2.599, CN_BODY_80=0.532, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_36=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 I5iEMZnG4X5U; Wed, 16 Nov 2011 21:12:48 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1F9C421F95BF; Wed, 16 Nov 2011 21:12:48 -0800 (PST) Received: by ywt34 with SMTP id 34so674259ywt.31 for ; Wed, 16 Nov 2011 21:12:47 -0800 (PST) Received: by 10.101.138.12 with SMTP id q12mr4708898ann.75.1321506767712; Wed, 16 Nov 2011 21:12:47 -0800 (PST) Received: from ?IPv6:2001:df8::16:226:bbff:fe1a:79b4? ([2001:df8:0:16:226:bbff:fe1a:79b4]) by mx.google.com with ESMTPS id i31sm70802756anm.19.2011.11.16.21.12.45 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 16 Nov 2011 21:12:46 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-23--401480816 From: Mark Townsley In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F4523668C32@szxeml509-mbs.china.huawei.com> Date: Thu, 17 Nov 2011 12:11:42 +0800 Message-Id: References: <8AE0F17B87264D4CAC7DE0AA6C406F4523668C32@szxeml509-mbs.china.huawei.com> To: "Leo Liu(bing)" X-Mailer: Apple Mail (2.1084) Cc: "homenet@ietf.org" , "renum@ietf.org" , "v6ops@ietf.org" Subject: Re: [v6ops] [renum] [Homenet][6renum] ULA discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 Nov 2011 05:12:49 -0000 --Apple-Mail-23--401480816 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=GB2312 "ULA isolated" in 3.1.1 as well as 3.1.2 "ULA Coexist with Global" is = important to homenet.=20 It is equally important for "ULA connected" described in section 3.1.1 = to *not* exist, or if it does for the devices in the homenet to be = readily aware that the ULA is "connected". See Chris Palmer's = presentation here for more info: = http://www.ietf.org/proceedings/81/slides/homenet-5.pdf (I have been = promised a draft as well - Chris?).=20 - Mark On Nov 17, 2011, at 10:36 AM, Leo Liu(bing) wrote: > Hi, all > In Tuesday's Homenet WG meeting, there was a brief discussion about = whether to use ULA, but no consensus achieved. >=20 > It was quite the same situation as in 6renum WG. We used to discuss = ULA usage to avoid some renumbering, but there's no consensus yet. As = the chair suggested, we thought the ULA topic involving common IPv6 = deployment consideration. For example, whether ULA-only+NAT is = acceptable or not; ULA+Global multiple addressing consider recommended = as providing stable local communication, or not recommended as adding = too much operational complexity. >=20 > So we produced a draft in v6ops intend to discuss the topic among more = people. > If you care about ULA, hope you can join the discussion in v6ops this = afternoon(Thursday) at 13:00. (ULA will be the first to be presented) >=20 > Thanks, > Bing >=20 > The slides=A3=BAhttp://www.ietf.org/proceedings/82/slides/v6ops-8.ppt =20= > =A3=A8It is a little different from the original draft since we = included some feedback after submitting the 00 version=A3=A9 > The draft: = http://tools.ietf.org/html/draft-liu-v6ops-ula-usage-analysis-00.html > _______________________________________________ > renum mailing list > renum@ietf.org > https://www.ietf.org/mailman/listinfo/renum --Apple-Mail-23--401480816 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=GB2312

It is equally important for "ULA = connected" described in section 3.1.1 to *not* exist, or if it does for = the devices in the homenet to be readily aware that the ULA is = "connected". See Chris Palmer's presentation here for more = info: http://ww= w.ietf.org/proceedings/81/slides/homenet-5.pdf (I have been = promised a draft as well - Chris?). 

- = Mark

On Nov 17, 2011, at 10:36 AM, Leo = Liu(bing) wrote:

Hi, all
In Tuesday's Homenet WG meeting, there was = a brief discussion about whether to use ULA, but no consensus = achieved.

It was quite the same situation as in 6renum WG. We = used to discuss ULA usage to avoid some renumbering, but there's no = consensus yet. As the chair suggested, we thought the ULA topic = involving common IPv6 deployment consideration. For example, whether = ULA-only+NAT is acceptable or not; ULA+Global multiple addressing = consider recommended as providing stable local communication, or not = recommended as adding too much operational complexity.

So we = produced a draft in v6ops intend to discuss the topic among more = people.
If you care about ULA, hope you can join the discussion in = v6ops this afternoon(Thursday) at 13:00. (ULA will be the first to be = presented)

Thanks,
Bing

The = slides=A3=BAhttp://www.ietf.org/proceedings/82/slides/v6ops-8.ppt =  
=A3=A8It is a little different from the original draft since = we included some feedback after submitting the 00 version=A3=A9
The = draft: http://tools.ietf.org/html/draft-liu-v6ops-ula-usage-analysis-00.html=
_______________________________________________
renum mailing = list
renum@ietf.org
https://www.ietf.org/= mailman/listinfo/renum

= --Apple-Mail-23--401480816-- From bs7652@att.com Wed Nov 16 21:29:15 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53E4721F9683 for ; Wed, 16 Nov 2011 21:29:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.164 X-Spam-Level: X-Spam-Status: No, score=-106.164 tagged_above=-999 required=5 tests=[AWL=-0.166, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 RJ76q9tRPM82 for ; Wed, 16 Nov 2011 21:29:12 -0800 (PST) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id 9863421F9685 for ; Wed, 16 Nov 2011 21:29:12 -0800 (PST) X-Env-Sender: bs7652@att.com X-Msg-Ref: server-4.tower-120.messagelabs.com!1321507750!49681924!1 X-Originating-IP: [144.160.20.146] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23662 invoked from network); 17 Nov 2011 05:29:10 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-4.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 17 Nov 2011 05:29:10 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pAH5RicT016264; Thu, 17 Nov 2011 00:27:44 -0500 Received: from 01AL10015010625.AD.BLS.COM (sfldmibbcraeninet1-v2.enaf.ait.sbc.com [10.231.16.33]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pAH5ReLa016232; Thu, 17 Nov 2011 00:27:40 -0500 Received: from 01NC27689010627.AD.BLS.COM ([90.144.44.202]) by 01AL10015010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Nov 2011 23:28:17 -0600 Received: from 01NC27689010650.AD.BLS.COM ([90.144.44.120]) by 01NC27689010627.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Nov 2011 00:28:17 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCA4E9.B5D9C20C" Date: Thu, 17 Nov 2011 00:29:03 -0500 Message-ID: <750BF7861EBBE048B3E648B4BB6E8F4F20DC41F6@crexc50p> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C30354436E@XMB-RCD-109.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] 6rd Sunsetting Thread-Index: AcykLe9E8+BD7WIjTbKJouEVl5VMJgAD8WKQAA2f5yA= References: <68DAB112-6E32-45FE-9AB7-A34E64898F60@cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30354436E@XMB-RCD-109.cisco.com> From: "STARK, BARBARA H" To: "Hemant Singh (shemant)" , "Fred Baker (fred)" , "Hans Liu" X-OriginalArrivalTime: 17 Nov 2011 05:28:17.0101 (UTC) FILETIME=[B5C7D7D0:01CCA4E9] Cc: Alexandre Cassen , v6ops@ietf.org, Claire Cheng Subject: Re: [v6ops] 6rd Sunsetting X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 Nov 2011 05:29:15 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCA4E9.B5D9C20C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In reading through the 6rd sunsetting draft vs. 6204bis, I think we may not have fully covered the case (in 6204bis) where the same prefix is used for 6rd and native. In this case, the philosophy of "route based on source address" won't work, and we should probably use the "metric" approach proposed by the 6rd sunsetting draft. We also can't unprefer and invalidate the prefix to the LAN. =20 So perhaps the items in 6204bis become: 5. Selection of 6rd tunnel or native IPv6 output interface on the CE router is determined by the source IPv6 address of the packet from a host, when different prefixes are available over 6rd vs. native IPv6 (IA_PD).=20 If the two interfaces provide the CE router with the same prefix, then the=20 CE router assigns a forwarding metric such that native IPv6 egress is preferred when 6rd and native IPv6 interfaces are active. =20 6. The CE router informs hosts that the native IPv6 prefix is preferred over the=20 6rd prefix, in the case where the two interfaces use different prefixes. Barbara =20 From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Hemant Singh (shemant) Sent: Wednesday, November 16, 2011 4:02 AM To: Fred Baker (fred); Hans Liu Cc: Alexandre Cassen; v6ops@ietf.org; Claire Cheng Subject: Re: [v6ops] 6rd Sunsetting =20 Folks, The use cases that Fred outlined are exactly what we authors of the document considered and the text in section 4.4.3 of the rfc6204bis document reflects the fact. The relevant text for the section is the first paragraph of the section, bullets 1, 2, 5, and 6, and the last paragraph covers sunsetting of 6rd.=20 =20 http://tools.ietf.org/id/draft-ietf-v6ops-6204bis-02.txt =20 Thanks, Fred. Hemant -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Fred Baker (fred) Sent: Wednesday, November 16, 2011 3:03 PM To: Hans Liu Cc: Alexandre Cassen; v6ops@ietf.org WG; Claire Cheng Subject: Re: [v6ops] 6rd Sunsetting The use cases I can think of are: 1) I used to run 6rd and have now deployed native service, but have not yet turned 6rd off. 2) I am using 6rd in one place and native service somewhere else. The second case is a pretty common coexistence case, I should think, but the two configurations don't conflict because they are different parts of the network. The first case is one that is presumably transitory but will be common during a switchover. I think the argument for thinking about routing is to direct traffic to the wider PMTU when possible and to have native deployment obsolete 6rd deployment quickly. If the route metrics are the same, one would expect some traffic to use native and some to use 6rd connectivity, which could be confusing for someone expecting the 6rd traffic to go to null. On Nov 15, 2011, at 4:17 PM, Hans Liu wrote: > Excuse me Mark, I still don't have an idea in what kind of use case > should we have 6rd and Native Dual Stack at the same time in the > network? >=20 > Regards, > Hans >=20 > On Tue, Nov 15, 2011 at 4:01 PM, Mark Townsley wrote: >>=20 >> Alexandre and I just finished up a -00 that describes two methods for moving >> a 6rd deployment to native IPv6. Apologies for not getting this out before >> the meeting. >> http://www.ietf.org/id/draft-townsley-v6ops-6rd-sunsetting-00.txt >>=20 >> Abstract >>=20 >> This document provides guidelines for transitioning an IPv6 >> deployment using IPv6 Rapid Deployment (6rd) to an IPv6 deployment >> using Native IPv6. It is targeted at both 6rd operators and 6rd >> implementors." >>=20 >> - Mark >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >>=20 >=20 >=20 >=20 > --=20 > Instead of following the fashion, we lead it through. > _______________________________________________ > 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 ------_=_NextPart_001_01CCA4E9.B5D9C20C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [v6ops] 6rd Sunsetting

In reading through the 6rd sunsetting draft vs. 6204bis, I think we = may not have fully covered the case (in 6204bis) where the same prefix = is used for 6rd and native. In this case, the philosophy of “route = based on source address” won’t work, and we should probably = use the “metric” approach proposed by the 6rd sunsetting = draft. We also can’t unprefer and invalidate the prefix to the = LAN.

 

So perhaps the items in 6204bis become:

   = 5.  Selection of 6rd tunnel or native IPv6 output interface on the = CE

       router is determined by the = source IPv6 address of the packet

       from a =
host, when different prefixes are =
available over 6rd vs. native IPv6 (IA_PD). =

     &n=
bsp; If the two interfaces provide the CE router with the same =
prefix, then the 
     &n=
bsp; CE router assigns a forwarding metric such that native =
IPv6
     &n=
bsp; egress is preferred when 6rd
     &n=
bsp; and native IPv6 interfaces are active.

 

   = 6.  The CE router informs hosts that = the native IPv6 prefix is preferred over the =

       6rd = prefix, in the case where the two interfaces use different = prefixes.

Barbara

 

From:= = v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of = Hemant Singh (shemant)
Sent: Wednesday, November 16, 2011 = 4:02 AM
To: Fred Baker (fred); Hans Liu
Cc: = Alexandre Cassen; v6ops@ietf.org; Claire Cheng
Subject: Re: = [v6ops] 6rd Sunsetting

 

Folks,

The use cases that Fred outlined are = exactly what we authors of the document considered and the text in = section 4.4.3 of the rfc6204bis document reflects the fact.  The = relevant text for the section is the first paragraph of the section, = bullets 1, 2, 5, and 6, and = the last paragraph covers sunsetting of 6rd. =

 

http://tools.ietf.org/id/draft-ietf-v6ops-= 6204bis-02.txt

Thanks, = Fred.

Hemant

-----Original Message-----
From: = v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org]= On Behalf Of Fred Baker (fred)
Sent: Wednesday, November 16, 2011 = 3:03 PM
To: Hans Liu
Cc: Alexandre Cassen; v6ops@ietf.org WG; = Claire Cheng
Subject: Re: [v6ops] 6rd = Sunsetting

The use cases I can think of = are:

1) I = used to run 6rd and have now deployed native service, but have not yet = turned 6rd off.

2) I am using 6rd in one place and native = service somewhere else.

The second case is a pretty common = coexistence case, I should think, but the two configurations don't = conflict because they are different parts of the network. The first case = is one that is presumably transitory but will be common during a = switchover.

I think the argument for thinking about = routing is to direct traffic to the wider PMTU when possible and to have = native deployment obsolete 6rd deployment quickly. If the route metrics = are the same, one would expect some traffic to use native and some to = use 6rd connectivity, which could be confusing for someone expecting the = 6rd traffic to go to null.

On Nov 15, 2011, at 4:17 PM, Hans Liu = wrote:

> = Excuse me Mark, I still don't have an idea in what kind of use = case

> = should we have 6rd and Native Dual Stack at the same time in = the

> = network?

>

> = Regards,

> Hans

>

> On Tue, Nov 15, 2011 at 4:01 PM, = Mark Townsley <mark@townsley.net> = wrote:

>>

>> Alexandre and I just finished up = a -00 that describes two methods for = moving

>> a 6rd deployment to native IPv6. = Apologies for not getting this out before

>> the = meeting.

>> http://www.ietf.org/id/draft-townsley-v6ops-6rd-sunsetting-00.txt

>> =

>> = Abstract

>>

>>   This document = provides guidelines for transitioning an = IPv6

>>   deployment using = IPv6 Rapid Deployment (6rd) to an IPv6 = deployment

>>   using Native = IPv6.  It is targeted at both 6rd operators and = 6rd

>>   = implementors."

>>

>> - = Mark

>> = _______________________________________________

<= span style=3D'font-family:Consolas'>>> v6ops mailing = list

>> = v6ops@ietf.org

>> https://www.ietf.org= /mailman/listinfo/v6ops

>>

>>

>

>

>

> --

> Instead of following the fashion, we = lead it through.

> = _______________________________________________

<= span style=3D'font-family:Consolas'>> 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

------_=_NextPart_001_01CCA4E9.B5D9C20C-- From hiromi@inetcore.com Wed Nov 16 21:38:34 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 673611F0C4F for ; Wed, 16 Nov 2011 21:38:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.2 X-Spam-Level: * X-Spam-Status: No, score=1.2 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_36=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 0719to9uJb-X for ; Wed, 16 Nov 2011 21:38:34 -0800 (PST) Received: from inc.inetcore.com (inc.inetcore.com [IPv6:2403:2000:1:1::11]) by ietfa.amsl.com (Postfix) with ESMTP id B13921F0C44 for ; Wed, 16 Nov 2011 21:38:33 -0800 (PST) Received: from [IPv6:2403:2000:1:3:40bc:1db3:92ce:4957] (unknown [IPv6:2403:2000:1:3:40bc:1db3:92ce:4957]) by inc.inetcore.com (Postfix) with ESMTPSA id 82762321DBD for ; Thu, 17 Nov 2011 14:38:24 +0900 (JST) Message-ID: <4EC49DCB.4050605@inetcore.com> Date: Thu, 17 Nov 2011 14:38:19 +0900 From: Ruri Hiromi Organization: INTEC Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: v6ops@ietf.org References: <8AE0F17B87264D4CAC7DE0AA6C406F4523668C32@szxeml509-mbs.china.huawei.com> In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F4523668C32@szxeml509-mbs.china.huawei.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] [Homenet][6renum] ULA discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 Nov 2011 05:38:34 -0000 Hi, This draft is very interesting to me. In my client case, one /48 of ULA is small for their World Wide Network with 4 bit boundary hierarchic management. With their management concept they have to use multiple ULAs. My question is, do multiple ULAs within a enterprise network work fine? In this case, ULA is not isolated within the enterprise. Excuse me if this will be a corner case. (Of course, I propose them to get a PI for greater space) (2011/11/17 11:36), Leo Liu(bing) wrote: > Hi, all > In Tuesday's Homenet WG meeting, there was a brief discussion about whether to use ULA, but no consensus achieved. > > It was quite the same situation as in 6renum WG. We used to discuss ULA usage to avoid some renumbering, but there's no consensus yet. As the chair suggested, we thought the ULA topic involving common IPv6 deployment consideration. For example, whether ULA-only+NAT is acceptable or not; ULA+Global multiple addressing consider recommended as providing stable local communication, or not recommended as adding too much operational complexity. > > So we produced a draft in v6ops intend to discuss the topic among more people. > If you care about ULA, hope you can join the discussion in v6ops this afternoon(Thursday) at 13:00. (ULA will be the first to be presented) > > Thanks, > Bing > > The slides$B!'(Bhttp://www.ietf.org/proceedings/82/slides/v6ops-8.ppt > $B!J(BIt is a little different from the original draft since we included some feedback after submitting the 00 version$B!K(B > The draft: http://tools.ietf.org/html/draft-liu-v6ops-ula-usage-analysis-00.html > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- --------------- Ruri Hiromi INTEC Inc. From marka@isc.org Wed Nov 16 21:51:04 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F00A11E80E4 for ; Wed, 16 Nov 2011 21:51:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.151, 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 b1Mj49OrolKL for ; Wed, 16 Nov 2011 21:51:03 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC2311E809B for ; Wed, 16 Nov 2011 21:51:03 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id C72945F98B6; Thu, 17 Nov 2011 05:50:50 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id AE655216C6B; Thu, 17 Nov 2011 05:50:48 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id E34FC179DAF9; Thu, 17 Nov 2011 16:50:40 +1100 (EST) To: Brian E Carpenter From: Mark Andrews References: <20111115062859.14026.42405.idtracker@ietfa.amsl.com> <4EC2ABA8.4020303@globis.net> <4EC2FD24.1090303@gmail.com> <4EC37529.4070505@globis.net> <20111117013452.19F35179A55F@drugs.dv.isc.org> <4EC469E7.9010602@gmail.com> In-reply-to: Your message of "Thu, 17 Nov 2011 14:56:55 +1300." <4EC469E7.9010602@gmail.com> Date: Thu, 17 Nov 2011 16:50:40 +1100 Message-Id: <20111117055040.E34FC179DAF9@drugs.dv.isc.org> Cc: Ray Hunter , v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 05:51:04 -0000 In message <4EC469E7.9010602@gmail.com>, Brian E Carpenter writes: > I agree that we need a secure automated solution of some kind. > > > ISP servicing a area just need > > to know each others public keys. > > That doesn't solve the general case, because multinationals tend > to be connected to the Internet at very widely separated locations. > So I think the correct statment is > > ISP just need to know each others public keys. > > That's a more difficult trust model, but not insoluble (for example, > a trusted public key repository at each RIR). > > Regards > Brian I would expect multi-nationals to be able to work around these sort of restrictions already. My primary focus is to make it work for the home / small office. Bigger customers can usually make this work today without automation. Homes and small offices can't because them man power cost is too high to deal with the volume. That said I would welcome a solution that scales up to handle any business that isn't a ISP. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From shemant@cisco.com Wed Nov 16 21:57:31 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56C8B11E8106 for ; Wed, 16 Nov 2011 21:57:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.935 X-Spam-Level: X-Spam-Status: No, score=-5.935 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 2yfElSTDM9Z6 for ; Wed, 16 Nov 2011 21:57:28 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0B88111E811D for ; Wed, 16 Nov 2011 21:57:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=21987; q=dns/txt; s=iport; t=1321509448; x=1322719048; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=WgX5N0cwRGZgly9w4L8nMhQwhjM7GEiKLcW28sRKOpo=; b=VFZ5QxHt30KMQPJhpPs4lmpqkFRmRRyc8Kdy/jARstFXL7NfkMEBanlp TKaUvSW0RiXpkX4djaJQ/m7BMQXIpAmxYOsmiTWOYI4gFRXRuK9HhJRJW fsAlp10h66EeGk8DxraZDaOOhhaakNnmGv03VxuNdMEoA+FbQhn7PjOgj o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUAAKuhxE6tJXHA/2dsb2JhbABCgk2XK4gVAYd4gQWBcgEBAQMBAQEBDwEJEQM+CwUHBAIBCBEEAQELBhAHAQYBJh8JCAEBBAESCAEWA4dgCJQ+AZ5QiTRjBIgUkWSMVw X-IronPort-AV: E=Sophos;i="4.69,525,1315180800"; d="scan'208,217";a="36803939" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-1.cisco.com with ESMTP; 17 Nov 2011 05:57:27 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id pAH5vR0h022933; Thu, 17 Nov 2011 05:57:27 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Nov 2011 23:57:27 -0600 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCA4ED.C8C647C3" Date: Wed, 16 Nov 2011 23:57:24 -0600 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3035447D6@XMB-RCD-109.cisco.com> In-Reply-To: <750BF7861EBBE048B3E648B4BB6E8F4F20DC41F6@crexc50p> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] 6rd Sunsetting Thread-Index: AcykLe9E8+BD7WIjTbKJouEVl5VMJgAD8WKQAA2f5yAAHbNYYA== References: <68DAB112-6E32-45FE-9AB7-A34E64898F60@cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30354436E@XMB-RCD-109.cisco.com> <750BF7861EBBE048B3E648B4BB6E8F4F20DC41F6@crexc50p> From: "Hemant Singh (shemant)" To: "STARK, BARBARA H" , "Fred Baker (fred)" , "Hans Liu" X-OriginalArrivalTime: 17 Nov 2011 05:57:27.0286 (UTC) FILETIME=[C8F8E160:01CCA4ED] Cc: Alexandre Cassen , v6ops@ietf.org, Claire Cheng Subject: Re: [v6ops] 6rd Sunsetting X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 Nov 2011 05:57:31 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCA4ED.C8C647C3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Barbara, =20 Agreed. We had the metric as part of an earlier revision of text emailed to the cpe router mailer but during editing we missed putting the same prefix back to the text. Good catch. =20 Thanks, =20 Hemant =20 From: STARK, BARBARA H [mailto:bs7652@att.com]=20 Sent: Thursday, November 17, 2011 1:29 PM To: Hemant Singh (shemant); Fred Baker (fred); Hans Liu Cc: Alexandre Cassen; v6ops@ietf.org; Claire Cheng Subject: RE: [v6ops] 6rd Sunsetting =20 In reading through the 6rd sunsetting draft vs. 6204bis, I think we may not have fully covered the case (in 6204bis) where the same prefix is used for 6rd and native. In this case, the philosophy of "route based on source address" won't work, and we should probably use the "metric" approach proposed by the 6rd sunsetting draft. We also can't unprefer and invalidate the prefix to the LAN. =20 So perhaps the items in 6204bis become: 5. Selection of 6rd tunnel or native IPv6 output interface on the CE router is determined by the source IPv6 address of the packet from a host, when different prefixes are available over 6rd vs. native IPv6 (IA_PD).=20 If the two interfaces provide the CE router with the same prefix, then the=20 CE router assigns a forwarding metric such that native IPv6 egress is preferred when 6rd and native IPv6 interfaces are active. =20 6. The CE router informs hosts that the native IPv6 prefix is preferred over the=20 6rd prefix, in the case where the two interfaces use different prefixes. Barbara =20 From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Hemant Singh (shemant) Sent: Wednesday, November 16, 2011 4:02 AM To: Fred Baker (fred); Hans Liu Cc: Alexandre Cassen; v6ops@ietf.org; Claire Cheng Subject: Re: [v6ops] 6rd Sunsetting =20 Folks, The use cases that Fred outlined are exactly what we authors of the document considered and the text in section 4.4.3 of the rfc6204bis document reflects the fact. The relevant text for the section is the first paragraph of the section, bullets 1, 2, 5, and 6, and the last paragraph covers sunsetting of 6rd.=20 =20 http://tools.ietf.org/id/draft-ietf-v6ops-6204bis-02.txt =20 Thanks, Fred. Hemant -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Fred Baker (fred) Sent: Wednesday, November 16, 2011 3:03 PM To: Hans Liu Cc: Alexandre Cassen; v6ops@ietf.org WG; Claire Cheng Subject: Re: [v6ops] 6rd Sunsetting The use cases I can think of are: 1) I used to run 6rd and have now deployed native service, but have not yet turned 6rd off. 2) I am using 6rd in one place and native service somewhere else. The second case is a pretty common coexistence case, I should think, but the two configurations don't conflict because they are different parts of the network. The first case is one that is presumably transitory but will be common during a switchover. I think the argument for thinking about routing is to direct traffic to the wider PMTU when possible and to have native deployment obsolete 6rd deployment quickly. If the route metrics are the same, one would expect some traffic to use native and some to use 6rd connectivity, which could be confusing for someone expecting the 6rd traffic to go to null. On Nov 15, 2011, at 4:17 PM, Hans Liu wrote: > Excuse me Mark, I still don't have an idea in what kind of use case > should we have 6rd and Native Dual Stack at the same time in the > network? >=20 > Regards, > Hans >=20 > On Tue, Nov 15, 2011 at 4:01 PM, Mark Townsley wrote: >>=20 >> Alexandre and I just finished up a -00 that describes two methods for moving >> a 6rd deployment to native IPv6. Apologies for not getting this out before >> the meeting. >> http://www.ietf.org/id/draft-townsley-v6ops-6rd-sunsetting-00.txt >>=20 >> Abstract >>=20 >> This document provides guidelines for transitioning an IPv6 >> deployment using IPv6 Rapid Deployment (6rd) to an IPv6 deployment >> using Native IPv6. It is targeted at both 6rd operators and 6rd >> implementors." >>=20 >> - Mark >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >>=20 >=20 >=20 >=20 > --=20 > Instead of following the fashion, we lead it through. > _______________________________________________ > 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 ------_=_NextPart_001_01CCA4ED.C8C647C3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [v6ops] 6rd Sunsetting

Barbara,

 

Agreed.    We had the metric as part of an earlier = revision of text emailed to the cpe router mailer but during editing we = missed putting the same prefix back to the text.  Good = catch.

 

Thanks,

 

Hemant

 

From:= = STARK, BARBARA H [mailto:bs7652@att.com] =
Sent: Thursday, November 17, 2011 1:29 PM
To: = Hemant Singh (shemant); Fred Baker (fred); Hans Liu
Cc: = Alexandre Cassen; v6ops@ietf.org; = Claire Cheng
Subject: RE: [v6ops] 6rd = Sunsetting

 

In reading through the 6rd sunsetting draft vs. 6204bis, I think we = may not have fully covered the case (in 6204bis) where the same prefix = is used for 6rd and native. In this case, the philosophy of “route = based on source address” won’t work, and we should probably = use the “metric” approach proposed by the 6rd sunsetting = draft. We also can’t unprefer and invalidate the prefix to the = LAN.

 

So perhaps the items in 6204bis become:

   = 5.  Selection of 6rd tunnel or native IPv6 output interface on the = CE

       router is determined by the = source IPv6 address of the packet

       from a =
host, when different prefixes are =
available over 6rd vs. native IPv6 (IA_PD). =

     &n=
bsp; If the two interfaces provide the CE router with the same =
prefix, then the 
     &n=
bsp; CE router assigns a forwarding metric such that native =
IPv6
     &n=
bsp; egress is preferred when 6rd
     &n=
bsp; and native IPv6 interfaces are active.

 

   = 6.  The CE router informs hosts that = the native IPv6 prefix is preferred over the =

       6rd = prefix, in the case where the two interfaces use different = prefixes.

Barbara

 

From:= = v6ops-bounces@ietf.org [mailto:v6ops-bounces@iet= f.org] On Behalf Of Hemant Singh (shemant)
Sent: = Wednesday, November 16, 2011 4:02 AM
To: Fred Baker (fred); = Hans Liu
Cc: Alexandre Cassen; v6ops@ietf.org; Claire = Cheng
Subject: Re: [v6ops] 6rd = Sunsetting

 

Folks,

The use cases that Fred outlined are = exactly what we authors of the document considered and the text in = section 4.4.3 of the rfc6204bis document reflects the fact.  The = relevant text for the section is the first paragraph of the section, = bullets 1, 2, 5, and 6, and = the last paragraph covers sunsetting of 6rd. =

 

http://tools.ietf.org/id/draft-ietf-v6ops-= 6204bis-02.txt

Thanks, = Fred.

Hemant

-----Original Message-----
From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org]= On Behalf Of Fred Baker (fred)
Sent: Wednesday, November 16, 2011 = 3:03 PM
To: Hans Liu
Cc: Alexandre Cassen; v6ops@ietf.org WG; Claire = Cheng
Subject: Re: [v6ops] 6rd = Sunsetting

The use cases I can think of = are:

1) I = used to run 6rd and have now deployed native service, but have not yet = turned 6rd off.

2) I am using 6rd in one place and native = service somewhere else.

The second case is a pretty common = coexistence case, I should think, but the two configurations don't = conflict because they are different parts of the network. The first case = is one that is presumably transitory but will be common during a = switchover.

I think the argument for thinking about = routing is to direct traffic to the wider PMTU when possible and to have = native deployment obsolete 6rd deployment quickly. If the route metrics = are the same, one would expect some traffic to use native and some to = use 6rd connectivity, which could be confusing for someone expecting the = 6rd traffic to go to null.

On Nov 15, 2011, at 4:17 PM, Hans Liu = wrote:

> = Excuse me Mark, I still don't have an idea in what kind of use = case

> = should we have 6rd and Native Dual Stack at the same time in = the

> = network?

>

> = Regards,

> Hans

>

> On Tue, Nov 15, 2011 at 4:01 PM, = Mark Townsley <mark@townsley.net> = wrote:

>>

>> Alexandre and I just finished up = a -00 that describes two methods for = moving

>> a 6rd deployment to native IPv6. = Apologies for not getting this out before

>> the = meeting.

>> http://www.ietf.org/id/draft-townsley-v6ops-6rd-sunsetting-00.txt

>> =

>> = Abstract

>>

>>   This document = provides guidelines for transitioning an = IPv6

>>   deployment using = IPv6 Rapid Deployment (6rd) to an IPv6 = deployment

>>   using Native = IPv6.  It is targeted at both 6rd operators and = 6rd

>>   = implementors."

>>

>> - = Mark

>> = _______________________________________________

<= span style=3D'font-family:Consolas'>>> v6ops mailing = list

>> v6ops@ietf.org

>> https://www.ietf.org= /mailman/listinfo/v6ops

>>

>>

>

>

>

> --

> Instead of following the fashion, we = lead it through.

> = _______________________________________________

<= span style=3D'font-family:Consolas'>> 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

------_=_NextPart_001_01CCA4ED.C8C647C3-- From shemant@cisco.com Wed Nov 16 21:59:58 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16A1921F972E for ; Wed, 16 Nov 2011 21:59:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.236 X-Spam-Level: X-Spam-Status: No, score=-6.236 tagged_above=-999 required=5 tests=[AWL=0.363, 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 2ZH4V+D7mTY0 for ; Wed, 16 Nov 2011 21:59:57 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 73A7221F966D for ; Wed, 16 Nov 2011 21:59:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=1239; q=dns/txt; s=iport; t=1321509597; x=1322719197; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=buLjHojq7IMbfhI1cbtDE4oRfsM8VLuK0031jy2yYpM=; b=Ry8P6Bw7qhwa1n5zV52U2F09yuHRoGUZ4NcZVZ3IDvy3rnIPxPPiVoqN Gvxl/KvKx+hUUSL8XIICI3eUmEmKxt1aQYMzt+GKRHE/gGLR5eQ3Fwma+ xAriNZ3f8e30wn+I3T/bMs/wnQnzTUI0gKXqZ+dH3aPZvyH0EZ/uCQt9z w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArQAAJ2ixE6tJXHA/2dsb2JhbABCmXiQDoEFgXIBAQEEEgEdCj8MBAIBCBEEAQELBgUSAQYBRQkIAgQBEgganCkBnk6GdoI+YwSIFJFkjFc X-IronPort-AV: E=Sophos;i="4.69,525,1315180800"; d="scan'208";a="36804428" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-5.cisco.com with ESMTP; 17 Nov 2011 05:59:55 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id pAH5xtBq023900; Thu, 17 Nov 2011 05:59:55 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Nov 2011 23:59:55 -0600 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Nov 2011 23:59:54 -0600 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3035447D7@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] RFC6204bis-02 Thread-Index: AcyewOvBbq1YdOdiSD66Sp1uaN6CQwCSeq2gAGv1BCAAHHv0MAANyK5QAAHgk2AAADFEcAABKvkAAABIDxAAAFiyMAAEM3K7AAAvTsAABnfm4AAbNh6w References: <867F4B6A1672E541A94676D556793ACD0C263BCDD7@MOPESMBX01.eu.thmulti.com><5B6B2B64C9FE2A489045EEEADDAFF2C303494A91@XMB-RCD-109.cisco.com><867F4B6A1672E541A94676D556793ACD0C27516363@MOPESMBX01.eu.thmulti.com><5B6B2B64C9FE2A489045EEEADDAFF2C303494F74@XMB-RCD-109.cisco.com><867F4B6A1672E541A94676D556793ACD0C27516655@MOPESMBX01.eu.thmulti.com><5B6B2B64C9FE2A489045EEEADDAFF2C303494FE3@XMB-RCD-109.cisco.com><867F4B6A1672E541A94676D556793ACD0C27516671@MOPESMBX01.eu.thmulti.com><5B6B2B64C9FE2A489045EEEADDAFF2C303494FE5@XMB-RCD-109.cisco.com><867F4B6A1672E541A94676D556793ACD0C275166AC@MOPESMBX01.eu.thmulti.com>, <5B6B2B64C9FE2A489045EEEADDAFF2C303494FE8@XMB-RCD-109.cisco.com><2F25DE74-DA72-4B7B-9358-9E1F17BF4DAD@Cable.Comcast.com> <867F4B6A1672E541A94676D556793ACD0C275167F4@MOPESMBX01.eu.thmulti.com> From: "Hemant Singh (shemant)" To: "George, Wes" , "Wuyts Carl" , "Lee, Yiu" X-OriginalArrivalTime: 17 Nov 2011 05:59:55.0702 (UTC) FILETIME=[216F5D60:01CCA4EE] Cc: v6ops@ietf.org Subject: Re: [v6ops] RFC6204bis-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: Thu, 17 Nov 2011 05:59:58 -0000 -----Original Message----- From: George, Wes [mailto:wesley.george@twcable.com]=20 Sent: Tuesday, November 15, 2011 10:02 PM To: Wuyts Carl; Lee, Yiu; Hemant Singh (shemant) Cc: v6ops@ietf.org Subject: RE: [v6ops] RFC6204bis-02 >[WEG] More importantly, how would a CPE determine what addresses are public and what are private? Assuming simply public !=3D RFC1918 isn't >enough, whether draft-weil passes or not. Either you now have to take that space into account as additional private space, or you run the >very real risk of folks using "public" addresses (squat) inside of private environments, or both. We have discussed such a question in the cpe router design team. The private address space included RFC5735 and the reserved range in RFC 6333. Current range suffices for a DS-Lite right now because even if a range is very small DS-Lite also uses port + IP enlarges the range. Of course, stuff happens and some day the range may deplete and then draft-weil or a squat range will need to be considered. Thus a CE router vendor is expected to provide a knob or a firmware upgrade when the range changes. We are leaning towards changing the MUST in the bullet to a SHOULD as well. Thanks, Hemant From john_brzozowski@cable.comcast.com Wed Nov 16 22:27:21 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B20E811E8142 for ; Wed, 16 Nov 2011 22:27:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.499 X-Spam-Level: X-Spam-Status: No, score=-104.499 tagged_above=-999 required=5 tests=[AWL=3.964, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQH3RjGAFkNQ for ; Wed, 16 Nov 2011 22:27:20 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id 88B6B11E8137 for ; Wed, 16 Nov 2011 22:27:20 -0800 (PST) Received: from ([24.40.55.41]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.146478491; Thu, 17 Nov 2011 01:27:15 -0500 Received: from PACDCEXMB01.cable.comcast.com ([fe80::3cf0:9cac:6c2a:7359]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%11]) with mapi id 14.01.0339.001; Thu, 17 Nov 2011 01:27:15 -0500 From: "Brzozowski, John" To: Lorenzo Colitti , Ralph Droms Thread-Topic: [v6ops] DHCPv6 option for MAX_SOL_RT Thread-Index: AQHMpPHyB5vqkfAeIE2CH2QcxPX8aw== Date: Thu, 17 Nov 2011 06:27:14 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [130.129.18.94] Content-Type: text/plain; charset="us-ascii" Content-ID: <489E2735C2AF7C4CB4D89F403956D7A2@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 Nov 2011 06:27:21 -0000 I think I could live with not changing the default value. We will also need to ensure IA_PD is added to the draft. In separate threads the notion of a per IA option is also being discussed. John =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D John Jason Brzozowski Comcast Cable e) mailto:john_brzozowski@cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On 11/17/11 12:07 AM, "Lorenzo Colitti" wrote: >On Wed, Nov 16, 2011 at 09:28, Ralph Droms wrote: > >...is here:=20 >http://tools.ietf.org/html/draft-droms-dhc-dhcpv6-maxsolrt-update-00 > > > > >I don't think we should mess with the default SOL_MAX_RT. In some cases >(e.g., if a host or CE router is disconnected from the network without >link going down), it will cause the host to get stuck asking for DHCPv6 >only once every two hours. This will cause it have to wait, on average, a >full hour before obtaining IPv6 parameters again. This is much slower >than IPv4 and thus is a performance parity issue. > >Given that this draft defines the option to set SOL_MAX_RT from the >DHCPv6 server, why do we need to change the default at all? > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From jari.arkko@piuha.net Wed Nov 16 23:07:10 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DCB01F0C8F for ; Wed, 16 Nov 2011 23:07:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.058, 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 vjW88nbdhy9E for ; Wed, 16 Nov 2011 23:07:09 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 728891F0C87 for ; Wed, 16 Nov 2011 23:07:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 06CFA2CC5C; Thu, 17 Nov 2011 09:07:08 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cs5l+ZxGH28b; Thu, 17 Nov 2011 09:07:07 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 8B1B52CC4D; Thu, 17 Nov 2011 09:07:06 +0200 (EET) Message-ID: <4EC4B299.8070605@piuha.net> Date: Thu, 17 Nov 2011 15:07:05 +0800 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: 'IPv6 Operations' , "W. Mark Townsley" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [v6ops] 6rd sunsetting draft X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 Nov 2011 07:07:10 -0000 Good stuff, needed. But very, very early. Understandably so, just days old. A couple of comments: "1. A 6rd CE MUST continue to allow 6rd packets to be sent and received as long as 6rd configuration is provided by the ISP, even while links on the router are configured with native IPv6." But you would _always_ have the internal interface configured with native IPv6 when 6rd is used. The statement needs further work. "3. 6rd and native IPv6 MUST allow for identical IPv6 delegated prefix". Hmm... a requirement on what must be possible, by operator configs and protocol mechanisms and implementations... we need to state what the device must do, in a concrete sense. Again, further work needed. Jari From jari.arkko@piuha.net Wed Nov 16 23:07:56 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB4821F979D for ; Wed, 16 Nov 2011 23:07:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.243 X-Spam-Level: X-Spam-Status: No, score=-102.243 tagged_above=-999 required=5 tests=[AWL=-0.244, 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 2lNacRL0hw-0 for ; Wed, 16 Nov 2011 23:07:55 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 57D7B21F9716 for ; Wed, 16 Nov 2011 23:07:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id AA3CE2CC5C; Thu, 17 Nov 2011 09:07:54 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rR0Hcw8cRNQt; Thu, 17 Nov 2011 09:07:53 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 2554E2CC4D; Thu, 17 Nov 2011 09:07:51 +0200 (EET) Message-ID: <4EC4B2C6.3060704@piuha.net> Date: Thu, 17 Nov 2011 15:07:50 +0800 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: 'IPv6 Operations' , "'Cao,Zhen'" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [v6ops] the nat64 operational document (draft-chen-v6ops-nat64-cpe) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 Nov 2011 07:07:56 -0000 I didn't get time on the mike to make my second comment. I liked the presentation. Thank for you doing it. Clearly, the ipv6.xxx.com stuff needs to be removed. But people had a question about the role of the document. I think it is the job of the IETF and V6OPS to produce documents that provide operational views about IETF technology (such as 6RD, NAT64, etc). There can be multiple classes of such documents, ranging from documenting someone's operational experience to recommending a particular practice to letting the IETF know that it needs some further enhancements in the protocol suite. I think this document falls in the first class, it may be too early to make recommendations about specific modes of deployment for NAT64 yet. I generally like these types of documents and would like to see V6OPS publish them, or, as was done with some other NAT64 documents, take them to AD sponsored/RFC Editor publications. I also agree with Lee that the presentation was great, the draft should be updated with all the information from the presentation. Jari From lorenzo@google.com Wed Nov 16 23:25:35 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F07611E812B for ; Wed, 16 Nov 2011 23:25:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.888 X-Spam-Level: X-Spam-Status: No, score=-102.888 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id skzG+s-Ycsya for ; Wed, 16 Nov 2011 23:25:34 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 95EF611E8114 for ; Wed, 16 Nov 2011 23:25:34 -0800 (PST) Received: by ggnr5 with SMTP id r5so787950ggn.31 for ; Wed, 16 Nov 2011 23:25:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=zwENc5j8pDXh5dOfG6Og6pU5V4CBc414qI0bAIrRNy4=; b=cLaZgBvQcSPk9AJ9qBN1Ydp3++tG8Zw0joGdk/TV2ZkWsd0jCH2jXWcP7RGTbtfl+S f9a6myq1Ff4q+2/mA91g== Received: by 10.236.124.105 with SMTP id w69mr7179084yhh.2.1321514734229; Wed, 16 Nov 2011 23:25:34 -0800 (PST) Received: by 10.236.124.105 with SMTP id w69mr7179068yhh.2.1321514734096; Wed, 16 Nov 2011 23:25:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.202.14 with HTTP; Wed, 16 Nov 2011 23:25:13 -0800 (PST) In-Reply-To: References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30354473D@XMB-RCD-109.cisco.com> <4EC455D6.8030601@bogus.com> From: Lorenzo Colitti Date: Thu, 17 Nov 2011 15:25:13 +0800 Message-ID: To: Ted Lemon Content-Type: multipart/alternative; boundary=20cf3010eb694a92be04b1e92061 X-System-Of-Record: true Cc: "v6ops@ietf.org" , Ralph Droms Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 Nov 2011 07:25:35 -0000 --20cf3010eb694a92be04b1e92061 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Nov 17, 2011 at 08:38, Ted Lemon wrote: > On Nov 17, 2011, at 8:31 AM, "Joel jaeggli" wrote: > > l2 vs l1 segmentation... > > Wouldn't there be evidence of this because you'd see different RAs? If you're a CE router, it doesn't matter what RAs you see. CE routers explicitly ignore IPv6 RAs when determining whether to start DHCPv6 PD or not, --20cf3010eb694a92be04b1e92061 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Nov 17, 2011 at 08:38, Ted Lemon <Ted.Lemon@nominum.c= om> wrote:
On Nov 17, 2011, at 8:31 AM, "Joel jaeggli" <joelja@bogus.com> wrote:
> l2 vs l1 segmentation...

Wouldn't there be evidence of this because you'd see different RAs?=

If you're a CE router, it doesn't = matter what RAs you see. CE routers explicitly ignore IPv6 RAs when determi= ning whether to start DHCPv6 PD or not,
--20cf3010eb694a92be04b1e92061-- From Ted.Lemon@nominum.com Wed Nov 16 23:50:55 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6EC51F0CA7 for ; Wed, 16 Nov 2011 23:50:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.565 X-Spam-Level: X-Spam-Status: No, score=-106.565 tagged_above=-999 required=5 tests=[AWL=0.034, 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 urEBxk0OJyeW for ; Wed, 16 Nov 2011 23:50:55 -0800 (PST) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id B378E1F0C82 for ; Wed, 16 Nov 2011 23:50:54 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKTsS83Y7BHFz5Wr6wAKTfftBLoFxGxRYF@postini.com; Wed, 16 Nov 2011 23:50:54 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 868D11B82E1 for ; Wed, 16 Nov 2011 23:50:52 -0800 (PST) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 6E9B619005D; Wed, 16 Nov 2011 23:50:51 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.01.0339.001; Wed, 16 Nov 2011 23:50:51 -0800 From: Ted Lemon To: Lorenzo Colitti Thread-Topic: [v6ops] DHCPv6 option for MAX_SOL_RT Thread-Index: AQHMpBVS9v5OyU3dDEaf8biIUoZIIJWwMYMAgACJcgCAAANuAP//e/aAgAD3r4D//4ENOg== Date: Thu, 17 Nov 2011 07:50:50 +0000 Message-ID: <3E09E3FD-51F7-4FA9-A173-ADDAB07871E9@nominum.com> References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30354473D@XMB-RCD-109.cisco.com> <4EC455D6.8030601@bogus.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" , Ralph Droms Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 Nov 2011 07:50:55 -0000 On Nov 17, 2011, at 3:25 PM, "Lorenzo Colitti" wrote: > If you're a CE router, it doesn't matter what RAs you see. CE routers exp= licitly ignore IPv6 RAs when determining whether to start DHCPv6 PD or not, So if you're a CE router that's plugged into an ethernet that's got your up= stream on it, and your upstream goes away, but your switch doesn't tell you= because it doesn't know you need to know, then we have a problem. Is tha= t a possible scenario for CE routers? It seems to me that typically a CE = router is going to see a carrier transition of some kind when moving to a d= ifferent provider network. BTW, I actually am not entirely convinced that Ralph's proposal is a good i= dea=97it's a quick hack to work around a one-time operational problem that = we will be stuck with forever. However, I'd like us to focus on real reas= ons for liking it or disliking it. I think the "carrier transition won't = be noticed" issue is easily addressed and not a very likely scenario anyway= . I would prefer to focus on real problems. From zehn.cao@gmail.com Wed Nov 16 23:56:05 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FAF81F0CDA for ; Wed, 16 Nov 2011 23:56:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s1e84fU48Vke for ; Wed, 16 Nov 2011 23:56:04 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB071F0CD2 for ; Wed, 16 Nov 2011 23:56:04 -0800 (PST) Received: by wyf28 with SMTP id 28so1831347wyf.31 for ; Wed, 16 Nov 2011 23:56:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PHltowQpjuhymiwDni54y5iQ/l3UL+oMS0a/HSV4KKQ=; b=JmmJTSDzp/NEkesSM00wyVkxugC0ca2CPhy3Zspvrc3wxPCsy/jIPsLTK+ZqrbI4p9 IxEccusOKs/PMMi3ojW312k4WL5EsmOozU2hczmd4tTzZOZJLWl16zt/qWXzPHWheb+7 zMY5exyvd+3dOzibXG5IjWjsMT+eTTQ8oS8s8= MIME-Version: 1.0 Received: by 10.182.216.105 with SMTP id op9mr10548418obc.57.1321516562875; Wed, 16 Nov 2011 23:56:02 -0800 (PST) Received: by 10.182.57.200 with HTTP; Wed, 16 Nov 2011 23:56:02 -0800 (PST) In-Reply-To: <4EC4B2C6.3060704@piuha.net> References: <4EC4B2C6.3060704@piuha.net> Date: Thu, 17 Nov 2011 15:56:02 +0800 Message-ID: From: Zhen Cao To: Jari Arkko Content-Type: text/plain; charset=ISO-8859-1 Cc: "Cao,Zhen" , IPv6 Operations Subject: Re: [v6ops] the nat64 operational document (draft-chen-v6ops-nat64-cpe) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 Nov 2011 07:56:05 -0000 Our pleasure. Thank you. For the naming part, how about rephrase to something like this: Although some websites are only providing IPv6 via the sub-domain names (ipv6.xxx.com), that's NOT RECOMMENDED. *reasons below*... -Zhen On Thu, Nov 17, 2011 at 3:07 PM, Jari Arkko wrote: > I didn't get time on the mike to make my second comment. > > I liked the presentation. Thank for you doing it. > > Clearly, the ipv6.xxx.com stuff needs to be removed. > > But people had a question about the role of the document. I think it is the > job of the IETF and V6OPS to produce documents that provide operational > views about IETF technology (such as 6RD, NAT64, etc). There can be multiple > classes of such documents, ranging from documenting someone's operational > experience to recommending a particular practice to letting the IETF know > that it needs some further enhancements in the protocol suite. I think this > document falls in the first class, it may be too early to make > recommendations about specific modes of deployment for NAT64 yet. I > generally like these types of documents and would like to see V6OPS publish > them, or, as was done with some other NAT64 documents, take them to AD > sponsored/RFC Editor publications. > > I also agree with Lee that the presentation was great, the draft should be > updated with all the information from the presentation. > > Jari > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From jari.arkko@piuha.net Thu Nov 17 00:19:03 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8024011E8176 for ; Thu, 17 Nov 2011 00:19:03 -0800 (PST) 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 Drr98D3gQZzH for ; Thu, 17 Nov 2011 00:19:02 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 4CA8911E8175 for ; Thu, 17 Nov 2011 00:19:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 96C9E2CC5F; Thu, 17 Nov 2011 10:19:01 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L6AsgmqnR3g4; Thu, 17 Nov 2011 10:18:59 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 0490D2CC5D; Thu, 17 Nov 2011 10:18:57 +0200 (EET) Message-ID: <4EC4C370.1020009@piuha.net> Date: Thu, 17 Nov 2011 16:18:56 +0800 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Zhen Cao References: <4EC4B2C6.3060704@piuha.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Cao,Zhen" , IPv6 Operations Subject: Re: [v6ops] the nat64 operational document (draft-chen-v6ops-nat64-cpe) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 Nov 2011 08:19:03 -0000 I'd remove the whole text. You are entering a topic that would be worthy of another 30-page document, with all the different considerations. Don't summarize it with one sentence, because it will leave the wrong impression. And we have some experience that is very difficult for the IETF to produce an agreeable answer in this space. Jari On 17.11.2011 15:56, Zhen Cao wrote: > Our pleasure. Thank you. > > For the naming part, how about rephrase to something like this: > Although some websites are only providing IPv6 via the sub-domain > names (ipv6.xxx.com), that's NOT RECOMMENDED. *reasons below*... > > -Zhen > On Thu, Nov 17, 2011 at 3:07 PM, Jari Arkko wrote: >> I didn't get time on the mike to make my second comment. >> >> I liked the presentation. Thank for you doing it. >> >> Clearly, the ipv6.xxx.com stuff needs to be removed. >> >> But people had a question about the role of the document. I think it is the >> job of the IETF and V6OPS to produce documents that provide operational >> views about IETF technology (such as 6RD, NAT64, etc). There can be multiple >> classes of such documents, ranging from documenting someone's operational >> experience to recommending a particular practice to letting the IETF know >> that it needs some further enhancements in the protocol suite. I think this >> document falls in the first class, it may be too early to make >> recommendations about specific modes of deployment for NAT64 yet. I >> generally like these types of documents and would like to see V6OPS publish >> them, or, as was done with some other NAT64 documents, take them to AD >> sponsored/RFC Editor publications. >> >> I also agree with Lee that the presentation was great, the draft should be >> updated with all the information from the presentation. >> >> Jari >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> From fred@cisco.com Thu Nov 17 01:04:39 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8952621F9B23 for ; Thu, 17 Nov 2011 01:04:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.28 X-Spam-Level: X-Spam-Status: No, score=-107.28 tagged_above=-999 required=5 tests=[AWL=-1.282, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 GwK3LDPwFX7f for ; Thu, 17 Nov 2011 01:04:35 -0800 (PST) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 1C12C21F9B2B for ; Thu, 17 Nov 2011 01:04:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=29910; q=dns/txt; s=iport; t=1321520674; x=1322730274; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=NtwY4cYNxM5q2ec0HaZ1VwyKCKlht0JgZOrXZNZfjuo=; b=QVyOzI66DdcmYfpwHWoA2Cm6SC7uhN5Q9v761hI4DwnkdjBRDCTAeijA ORMTtzxxksOpzrzAwhsFfWVnh86eUT0daGWx+67f4WkCz+wy117bDs9aD SM0aZtusCTssoShwvRO23Z2YZN1BsjxpIJ3YuGmjkPevWfJTFdIW2IlhS 4=; X-IronPort-AV: E=Sophos;i="4.69,525,1315180800"; d="scan'208,217";a="3308044" Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-4.cisco.com with ESMTP; 17 Nov 2011 09:04:31 +0000 Received: from dhcp-5155.meeting.ietf.org (hkidc-vpn-client-234-97.cisco.com [10.75.234.97]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pAH94RdE012881; Thu, 17 Nov 2011 09:04:28 GMT Received: from [127.0.0.1] by dhcp-5155.meeting.ietf.org (PGP Universal service); Thu, 17 Nov 2011 17:04:29 +0800 X-PGP-Universal: processed; by dhcp-5155.meeting.ietf.org on Thu, 17 Nov 2011 17:04:29 +0800 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <750BF7861EBBE048B3E648B4BB6E8F4F20DC41F6@crexc50p> Date: Thu, 17 Nov 2011 17:04:16 +0800 Message-Id: References: <68DAB112-6E32-45FE-9AB7-A34E64898F60@cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30354436E@XMB-RCD-109.cisco.com> <750BF7861EBBE048B3E648B4BB6E8F4F20DC41F6@crexc50p> To: "STARK, BARBARA H" X-Mailer: Apple Mail (2.1084) Content-Type: multipart/alternative; boundary=Apple-Mail-4--383927443 Cc: Alexandre Cassen , v6ops@ietf.org, Claire Cheng Subject: Re: [v6ops] 6rd Sunsetting X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 Nov 2011 09:04:40 -0000 --Apple-Mail-4--383927443 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Personally, I'd be a bit perplexed at putting native and 6rd deployment = into the same prefix. I could imagine adjacent prefixes - one is = 2001:dba:2:2::/64 and the other is 2001:dba:2:3::/64. But to my way of = thinking, the prefix in effect chooses the path to the place the prefix = is located. The reason for source select routing is the issue raised in = BCP 84: BCP 38 will drop traffic if it takes the wrong path, so please = route outbound traffic on the correct path. If two paths have the same = prefix, then either we're looking at ECMP, or we have a situation in = which the router's tables are ambiguous... On Nov 17, 2011, at 1:29 PM, STARK, BARBARA H wrote: > In reading through the 6rd sunsetting draft vs. 6204bis, I think we = may not have fully covered the case (in 6204bis) where the same prefix = is used for 6rd and native. In this case, the philosophy of =93route = based on source address=94 won=92t work, and we should probably use the = =93metric=94 approach proposed by the 6rd sunsetting draft. We also = can=92t unprefer and invalidate the prefix to the LAN. > =20 > So perhaps the items in 6204bis become: > 5. Selection of 6rd tunnel or native IPv6 output interface on the = CE > router is determined by the source IPv6 address of the packet > from a host, when different prefixes are available over 6rd vs. = native IPv6 (IA_PD).=20 > If the two interfaces provide the CE router with the same = prefix, then the=20 > CE router assigns a forwarding metric such that native IPv6 > egress is preferred when 6rd > and native IPv6 interfaces are active. > =20 > 6. The CE router informs hosts that the native IPv6 prefix is = preferred over the > 6rd prefix, in the case where the two interfaces use different = prefixes. > Barbara > =20 > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Hemant Singh (shemant) > Sent: Wednesday, November 16, 2011 4:02 AM > To: Fred Baker (fred); Hans Liu > Cc: Alexandre Cassen; v6ops@ietf.org; Claire Cheng > Subject: Re: [v6ops] 6rd Sunsetting > =20 > Folks, >=20 > The use cases that Fred outlined are exactly what we authors of the = document considered and the text in section 4.4.3 of the rfc6204bis = document reflects the fact. The relevant text for the section is the = first paragraph of the section, bullets 1, 2, 5, and 6, and the last = paragraph covers sunsetting of 6rd. >=20 > =20 >=20 > http://tools.ietf.org/id/draft-ietf-v6ops-6204bis-02.txt >=20 > Thanks, Fred. >=20 > Hemant >=20 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Fred Baker (fred) > Sent: Wednesday, November 16, 2011 3:03 PM > To: Hans Liu > Cc: Alexandre Cassen; v6ops@ietf.org WG; Claire Cheng > Subject: Re: [v6ops] 6rd Sunsetting >=20 > The use cases I can think of are: >=20 > 1) I used to run 6rd and have now deployed native service, but have = not yet turned 6rd off. >=20 > 2) I am using 6rd in one place and native service somewhere else. >=20 > The second case is a pretty common coexistence case, I should think, = but the two configurations don't conflict because they are different = parts of the network. The first case is one that is presumably = transitory but will be common during a switchover. >=20 > I think the argument for thinking about routing is to direct traffic = to the wider PMTU when possible and to have native deployment obsolete = 6rd deployment quickly. If the route metrics are the same, one would = expect some traffic to use native and some to use 6rd connectivity, = which could be confusing for someone expecting the 6rd traffic to go to = null. >=20 > On Nov 15, 2011, at 4:17 PM, Hans Liu wrote: >=20 > > Excuse me Mark, I still don't have an idea in what kind of use case >=20 > > should we have 6rd and Native Dual Stack at the same time in the >=20 > > network? >=20 > > >=20 > > Regards, >=20 > > Hans >=20 > > >=20 > > On Tue, Nov 15, 2011 at 4:01 PM, Mark Townsley = wrote: >=20 > >> >=20 > >> Alexandre and I just finished up a -00 that describes two methods = for moving >=20 > >> a 6rd deployment to native IPv6. Apologies for not getting this out = before >=20 > >> the meeting. >=20 > >> http://www.ietf.org/id/draft-townsley-v6ops-6rd-sunsetting-00.txt >=20 > >> >=20 > >> Abstract >=20 > >> >=20 > >> This document provides guidelines for transitioning an IPv6 >=20 > >> deployment using IPv6 Rapid Deployment (6rd) to an IPv6 = deployment >=20 > >> using Native IPv6. It is targeted at both 6rd operators and 6rd >=20 > >> implementors." >=20 > >> >=20 > >> - Mark >=20 > >> _______________________________________________ >=20 > >> v6ops mailing list >=20 > >> v6ops@ietf.org >=20 > >> https://www.ietf.org/mailman/listinfo/v6ops >=20 > >> >=20 > >> >=20 > > >=20 > > >=20 > > >=20 > > -- >=20 > > Instead of following the fashion, we lead it through. >=20 > > _______________________________________________ >=20 > > v6ops mailing list >=20 > > v6ops@ietf.org >=20 > > https://www.ietf.org/mailman/listinfo/v6ops >=20 > _______________________________________________ >=20 > v6ops mailing list >=20 > v6ops@ietf.org >=20 > https://www.ietf.org/mailman/listinfo/v6ops >=20 --Apple-Mail-4--383927443 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Personally, I'd be a bit perplexed at putting = native and 6rd deployment into the same prefix. I could imagine adjacent = prefixes - one is 2001:dba:2:2::/64 and the other = is 2001:dba:2:3::/64. But to my way of thinking, the prefix in = effect chooses the path to the place the prefix is located. The reason = for source select routing is the issue raised in BCP 84: BCP 38 will = drop traffic if it takes the wrong path, so please route outbound = traffic on the correct path. If two paths have the same prefix, then = either we're looking at ECMP, or we have a situation in which the = router's tables are ambiguous...

On Nov 17, 2011, at = 1:29 PM, STARK, BARBARA H wrote:

In reading through the 6rd sunsetting draft vs. = 6204bis, I think we may not have fully covered the case (in 6204bis) = where the same prefix is used for 6rd and native. In this case, the = philosophy of =93route based on source address=94 won=92t work, and we = should probably use the =93metric=94 approach proposed by the 6rd = sunsetting draft. We also can=92t unprefer and invalidate the prefix to = the LAN.
 
So perhaps the items in 6204bis = become:
   5.  Selection of 6rd tunnel or native = IPv6 output interface on the CE
, when different prefixes are available over 6rd = vs. native IPv6 (IA_PD). 
       If =
the two interfaces provide the CE router with the same prefix, then the =

       egress =
is preferred when 6rd
   6.  The CE router informs hosts that the native IPv6 =
prefix is preferred over the
       6rd prefix, in = the case where the two interfaces use different prefixes 
From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.or= g] On Behalf = Of Hemant Singh = (shemant)
Sent: Wednesday, November 16, = 2011 4:02 AM
To: Fred Baker (fred); Hans = Liu
Cc: Alexandre Cassen; v6ops@ietf.org; Claire Cheng
Subject: Re: [v6ops] 6rd = Sunsetting
Folks,

The use cases that Fred outlined are exactly what we authors = of the document considered and the text in section 4.4.3 of the = rfc6204bis document reflects the fact.  The relevant text for the = section is the first paragraph of the section, bullets 1, 2, 5, and 6, and the last paragraph covers sunsetting of = 6rd.

Thanks, Fred.

-----Original = Message-----
From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On = Behalf Of Fred Baker (fred)
Sent: Wednesday, November 16, 2011 3:03 = PM
To: Hans Liu
Cc: Alexandre Cassen; v6ops@ietf.org WG; Claire = Cheng
Subject: Re: [v6ops] 6rd Sunsetting

The use cases I can think of are:

1) I used to run 6rd and have now deployed native service, = but have not yet turned 6rd off.

2) I am using 6rd in one place and native service somewhere = else.

The second case is a pretty common = coexistence case, I should think, but the two configurations don't = conflict because they are different parts of the network. The first case = is one that is presumably transitory but will be common during a = switchover.

I think the argument = for thinking about routing is to direct traffic to the wider PMTU when = possible and to have native deployment obsolete 6rd deployment quickly. = If the route metrics are the same, one would expect some traffic to use = native and some to use 6rd connectivity, which could be confusing for = someone expecting the 6rd traffic to go to null.

On Nov 15, 2011, at 4:17 PM, Hans Liu = wrote:

> Excuse me Mark, I still don't = have an idea in what kind of use case

> should we have 6rd and Native Dual Stack at the same = time in the

> = network?

> Regards,

> Hans

> On Tue, Nov 15, 2011 at 4:01 PM, = Mark Townsley <mark@townsley.net> = wrote:

>>

>> Alexandre and I just finished up a -00 that = describes two methods for moving

>> a 6rd deployment to native IPv6. Apologies for not = getting this out before

>> the = meeting.

>> >>

>> Abstract

>>

>>   = This document provides guidelines for transitioning an = IPv6

>>   deployment using = IPv6 Rapid Deployment (6rd) to an IPv6 = deployment

>>   = using Native IPv6.  It is targeted at both 6rd operators and = 6rd

>>   = implementors."

>> - = Mark

>> = _______________________________________________

>> v6ops mailing list

>> v6ops@ietf.org

>> >>

>

>

> = --

> Instead of following the fashion, = we lead it through.

> = _______________________________________________

> v6ops mailing list

> v6ops@ietf.org

> v6ops mailing list

v6ops@ietf.org

To: "'Jari Arkko'" , "'IPv6 Operations'" , "'Cao,Zhen'" References: <4EC4B2C6.3060704@piuha.net> In-Reply-To: <4EC4B2C6.3060704@piuha.net> Date: Thu, 17 Nov 2011 17:21:11 +0800 Message-ID: <000601cca50a$41cc3620$c564a260$@org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acyk96NFP7P1mstCTAe2i79noBLcvwAEZy+A Content-Language: en-us Subject: Re: [v6ops] the nat64 operational document (draft-chen-v6ops-nat64-cpe) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 Nov 2011 09:21:16 -0000 > But people had a question about the role of the document. I think it is the job of the IETF > and V6OPS to produce documents that provide operational views about IETF technology > (such as 6RD, NAT64, etc). There can be multiple classes of such documents, ranging from > documenting someone's operational experience to recommending a particular practice to > letting the IETF know that it needs some further enhancements in the protocol suite. I think > this document falls in the first class, it may be too early to make recommendations about > specific modes of deployment for NAT64 yet I agree, I like documents of this class, and I think you're right about which kind of document this is. I'd like the document to be clearer in that regard, maybe starting with a title like "NAT64 Operational Experiences." >. I generally like these types of documents and > would like to see V6OPS publish them, or, as was done with some other NAT64 > documents, take them to AD sponsored/RFC Editor publications. I agree in general. Not yet sure I agree in specific. Lee From v6ops@globis.net Thu Nov 17 01:46:03 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2FE821F9B25 for ; Thu, 17 Nov 2011 01:46:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.103, 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 Q2pm35LLCMzw for ; Thu, 17 Nov 2011 01:46:03 -0800 (PST) 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 70AF021F9B20 for ; Thu, 17 Nov 2011 01:46:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 560918700E7; Thu, 17 Nov 2011 10:45:59 +0100 (CET) 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 eDRkI2LVKdKJ; Thu, 17 Nov 2011 10:45:53 +0100 (CET) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 72E648700E6; Thu, 17 Nov 2011 10:45:53 +0100 (CET) Message-ID: <4EC4D7D1.8050601@globis.net> Date: Thu, 17 Nov 2011 10:45:53 +0100 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: Mark Andrews References: <20111115062859.14026.42405.idtracker@ietfa.amsl.com> <4EC2ABA8.4020303@globis.net> <4EC2FD24.1090303@gmail.com> <4EC37529.4070505@globis.net> <20111117013452.19F35179A55F@drugs.dv.isc.org> <4EC469E7.9010602@gmail.com> <20111117055040.E34FC179DAF9@drugs.dv.isc.org> In-Reply-To: <20111117055040.E34FC179DAF9@drugs.dv.isc.org> Content-Type: multipart/alternative; boundary="------------000301000901050506030004" Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 09:46:03 -0000 This is a multi-part message in MIME format. --------------000301000901050506030004 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Agreed. Most multinationals I know are already LIRs. They can run BGP to the major sites with multiple ISPs and their own PI /32. That's the easy bit. But it isn't just about a few large sites and 2 ISP's. There's also the rest of the private corporate network covering 50+ countries + multiple (smaller) ISPs to consider. IMHO I have seen three use cases so far in production today in IPv4 that are not really covered in IPv6. To be frank, these current solutions seem mainly to be driven by commercial considerations rather than technical ones. So if a commercial solution could be found, there wouldn't be much resistance to change. Most problems are due to the return route, not the outbound one. 1. Home workers, remote branch offices, and SME's that need higher availability than a single consumer ISP link, but don't have the capability/desire/cash/ISP to run a multihomed BGP AS. Today they can use a simple outbound-only load-balancing box, or a specialist VPN box that provides 2 GRE/IPSec tunnels via 2 ISPs. The GRE/IPSec solution will obviously work in the future, but the load balancer won't. 2. Local Internet break out. Remote corporate site is still connected to the corporate network for business/production critical apps, but Internet traffic is gatewayed directly into the Public Internet at the local site for Internet centric apps like foobarnow.com. Today the local site Internet firewall/router can use NAT44 outbound: guaranteeing a return route direct to the local site. Most, but not all, Internet centric apps are web based, but that would mean installing a proxy on every site for IPv6. I see no solution so far for apps that are "NAT44-able" but "non-proxy-able" with IPv6. Negotiating ISP routing of a single /48 in country X from the PI /32 is unlikely to work in all cases. I guess these sites could just use PA space addresses, but then you have limited service availability, and potential renumbering issues. 3. Internet offload. Remote corporate site has a main link and an Internet connection. Local site router is connected to both and uses Policy Based Routing (PBR) to route down the appropriate link. A GRE tunnel carries the bulk traffic over the Internet to the regional corporate data centre, where it emerges from the tunnel and passes through the usual security controls onto the Public Internet. Return route to the GRE tunnel is guaranteed via NAT. Otherwise you'd need to run PBR on the DC firewall as the Internet tunnel and private corporate network are connected to different security zones on the firewall. PBR on firewalls doesn't exist so far AFAIK. In most cases there's multiple hops (and possibly security devices) between the end nodes and the point where the alternative paths split. Mark Andrews wrote: > > > I would expect multi-nationals to be able to work around these sort > of restrictions already. My primary focus is to make it work for > the home / small office. Bigger customers can usually make this > work today without automation. Homes and small offices can't because > them man power cost is too high to deal with the volume. > > That said I would welcome a solution that scales up to handle any > business that isn't a ISP. > > Mark > --------------000301000901050506030004 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Agreed. Most multinationals I know are already LIRs. They can run BGP to the major sites with multiple ISPs and their own PI /32. That's the easy bit.

But it isn't just about a few large sites and 2 ISP's. There's also the rest of the private corporate network covering 50+ countries + multiple (smaller) ISPs to consider.

IMHO I have seen three use cases so far in production today in IPv4 that are not really covered in IPv6. To be frank, these current solutions seem mainly to be driven by commercial considerations rather than technical ones. So if a commercial solution could be found, there wouldn't be much resistance to change. Most problems are due to the return route, not the outbound one.

1. Home workers, remote branch offices, and SME's that need higher availability than a single consumer ISP link, but don't have the capability/desire/cash/ISP to run a multihomed BGP AS. Today they can use a simple outbound-only load-balancing box, or a specialist VPN box that provides 2 GRE/IPSec tunnels via 2 ISPs. The GRE/IPSec solution will obviously work in the future, but the load balancer won't.

2. Local Internet break out. Remote corporate site is still connected to the corporate network for business/production critical apps, but Internet traffic is gatewayed directly into the Public Internet at the local site for Internet centric apps like foobarnow.com. Today the local site Internet firewall/router can use NAT44 outbound: guaranteeing a return route direct to the local site. Most, but not all, Internet centric apps are web based, but that would mean installing a proxy on every site for IPv6. I see no solution so far for apps that are "NAT44-able" but "non-proxy-able" with IPv6. Negotiating ISP routing of a single /48 in country X from the PI /32 is unlikely to work in all cases. I guess these sites could just use PA space addresses, but then you have limited service availability, and potential renumbering issues.

3. Internet offload. Remote corporate site has a main link and an Internet connection. Local site router is connected to both and uses Policy Based Routing (PBR) to route down the appropriate link. A GRE tunnel carries the bulk traffic over the Internet to the regional corporate data centre, where it emerges from the tunnel and passes through the usual security controls onto the Public Internet. Return route to the GRE tunnel is guaranteed via NAT. Otherwise you'd need to run PBR on the DC firewall as the Internet tunnel and private corporate network are connected to different security zones on the firewall. PBR on firewalls doesn't exist so far AFAIK.

In most cases there's multiple hops (and possibly security devices) between the end nodes and the point where the alternative paths split.


Mark Andrews wrote:

<snip> 

I would expect multi-nationals to be able to work around these sort
of restrictions already.  My primary focus is to make it work for
the home / small office.  Bigger customers can usually make this
work today without automation.  Homes and small offices can't because
them man power cost is too high to deal with the volume.

That said I would welcome a solution that scales up to handle any
business that isn't a ISP.

Mark

--------------000301000901050506030004-- From mark@townsley.net Thu Nov 17 02:12:39 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FA2421F9B65 for ; Thu, 17 Nov 2011 02:12:39 -0800 (PST) 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 Nehh-vK9L+La for ; Thu, 17 Nov 2011 02:12:38 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id C90E921F8C14 for ; Thu, 17 Nov 2011 02:12:37 -0800 (PST) Received: by ggnr5 with SMTP id r5so965981ggn.31 for ; Thu, 17 Nov 2011 02:12:37 -0800 (PST) Received: by 10.236.154.166 with SMTP id h26mr7724470yhk.88.1321524757115; Thu, 17 Nov 2011 02:12:37 -0800 (PST) Received: from [172.16.7.11] ([122.147.35.3]) by mx.google.com with ESMTPS id f14sm402872ani.8.2011.11.17.02.12.32 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 17 Nov 2011 02:12:35 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-37--379832956 From: Mark Townsley In-Reply-To: Date: Thu, 17 Nov 2011 18:12:30 +0800 Message-Id: References: <68DAB112-6E32-45FE-9AB7-A34E64898F60@cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30354436E@XMB-RCD-109.cisco.com> <750BF7861EBBE048B3E648B4BB6E8F4F20DC41F6@crexc50p> To: Fred Baker X-Mailer: Apple Mail (2.1084) Cc: Alexandre Cassen , v6ops@ietf.org, Claire Cheng Subject: Re: [v6ops] 6rd Sunsetting X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 Nov 2011 10:12:39 -0000 --Apple-Mail-37--379832956 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Nov 17, 2011, at 5:04 PM, Fred Baker wrote: > Personally, I'd be a bit perplexed at putting native and 6rd = deployment into the same prefix. I agree, it is not the most obvious solution, and the draft says that. = But, once you run through it until the end, it has some compelling = aspects.=20 > I could imagine adjacent prefixes - one is 2001:dba:2:2::/64 and the = other is 2001:dba:2:3::/64. Unfortunately. that's not possible with the way that 6rd operates. > But to my way of thinking, the prefix in effect chooses the path to = the place the prefix is located. If it follows normal routing, it of course chooses the path based on the = destination, not the delegated prefix.=20 > The reason for source select routing is the issue raised in BCP 84: = BCP 38 will drop traffic if it takes the wrong path, so please route = outbound traffic on the correct path. Using the same delegated prefix avoids this (our #2 scenario), using = different prefixes (scenario #1) causes us to have to deal with this = problem. Source select routing is something that needs to be solved, and = is on the list of things we are worrying about in homenet, but AFAIK it = is beyond the current state of the art.=20 > If two paths have the same prefix, then either we're looking at ECMP, = or we have a situation in which the router's tables are ambiguous... The draft specifically says that the native path should have a preferred = metric. Alternatively, an implementation could remove the default route = to the 6rd virtual interface, but that would require some coupling = between interfaces, something that I was trying to avoid.=20 So, I don't see the ambiguity. With 6rd and native up, there are at most = 3 routes. One more-specific that points to the CE-CE 6rd tunnel, the = other one or two that point to native or 6rd BR upstream, but with a = preference for native over 6rd. - Mark >=20 > On Nov 17, 2011, at 1:29 PM, STARK, BARBARA H wrote: >=20 >> In reading through the 6rd sunsetting draft vs. 6204bis, I think we = may not have fully covered the case (in 6204bis) where the same prefix = is used for 6rd and native. In this case, the philosophy of =93route = based on source address=94 won=92t work, and we should probably use the = =93metric=94 approach proposed by the 6rd sunsetting draft. We also = can=92t unprefer and invalidate the prefix to the LAN. >> =20 >> So perhaps the items in 6204bis become: >> 5. Selection of 6rd tunnel or native IPv6 output interface on the = CE >> router is determined by the source IPv6 address of the packet >> from a host, when different prefixes are available over 6rd = vs. native IPv6 (IA_PD).=20 >> If the two interfaces provide the CE router with the same = prefix, then the=20 >> CE router assigns a forwarding metric such that native IPv6 >> egress is preferred when 6rd >> and native IPv6 interfaces are active. >> =20 >> 6. The CE router informs hosts that the native IPv6 prefix is = preferred over the >> 6rd prefix, in the case where the two interfaces use different = prefixes. >> Barbara >> =20 >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On = Behalf Of Hemant Singh (shemant) >> Sent: Wednesday, November 16, 2011 4:02 AM >> To: Fred Baker (fred); Hans Liu >> Cc: Alexandre Cassen; v6ops@ietf.org; Claire Cheng >> Subject: Re: [v6ops] 6rd Sunsetting >> =20 >> Folks, >>=20 >> The use cases that Fred outlined are exactly what we authors of the = document considered and the text in section 4.4.3 of the rfc6204bis = document reflects the fact. The relevant text for the section is the = first paragraph of the section, bullets 1, 2, 5, and 6, and the last = paragraph covers sunsetting of 6rd. >>=20 >> =20 >>=20 >> http://tools.ietf.org/id/draft-ietf-v6ops-6204bis-02.txt >>=20 >> Thanks, Fred. >>=20 >> Hemant >>=20 >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On = Behalf Of Fred Baker (fred) >> Sent: Wednesday, November 16, 2011 3:03 PM >> To: Hans Liu >> Cc: Alexandre Cassen; v6ops@ietf.org WG; Claire Cheng >> Subject: Re: [v6ops] 6rd Sunsetting >>=20 >> The use cases I can think of are: >>=20 >> 1) I used to run 6rd and have now deployed native service, but have = not yet turned 6rd off. >>=20 >> 2) I am using 6rd in one place and native service somewhere else. >>=20 >> The second case is a pretty common coexistence case, I should think, = but the two configurations don't conflict because they are different = parts of the network. The first case is one that is presumably = transitory but will be common during a switchover. >>=20 >> I think the argument for thinking about routing is to direct traffic = to the wider PMTU when possible and to have native deployment obsolete = 6rd deployment quickly. If the route metrics are the same, one would = expect some traffic to use native and some to use 6rd connectivity, = which could be confusing for someone expecting the 6rd traffic to go to = null. >>=20 >> On Nov 15, 2011, at 4:17 PM, Hans Liu wrote: >>=20 >> > Excuse me Mark, I still don't have an idea in what kind of use case >>=20 >> > should we have 6rd and Native Dual Stack at the same time in the >>=20 >> > network? >>=20 >> > >>=20 >> > Regards, >>=20 >> > Hans >>=20 >> > >>=20 >> > On Tue, Nov 15, 2011 at 4:01 PM, Mark Townsley = wrote: >>=20 >> >> >>=20 >> >> Alexandre and I just finished up a -00 that describes two methods = for moving >>=20 >> >> a 6rd deployment to native IPv6. Apologies for not getting this = out before >>=20 >> >> the meeting. >>=20 >> >> http://www.ietf.org/id/draft-townsley-v6ops-6rd-sunsetting-00.txt >>=20 >> >> >>=20 >> >> Abstract >>=20 >> >> >>=20 >> >> This document provides guidelines for transitioning an IPv6 >>=20 >> >> deployment using IPv6 Rapid Deployment (6rd) to an IPv6 = deployment >>=20 >> >> using Native IPv6. It is targeted at both 6rd operators and 6rd >>=20 >> >> implementors." >>=20 >> >> >>=20 >> >> - Mark >>=20 >> >> _______________________________________________ >>=20 >> >> v6ops mailing list >>=20 >> >> v6ops@ietf.org >>=20 >> >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >> >> >>=20 >> >> >>=20 >> > >>=20 >> > >>=20 >> > >>=20 >> > -- >>=20 >> > Instead of following the fashion, we lead it through. >>=20 >> > _______________________________________________ >>=20 >> > v6ops mailing list >>=20 >> > v6ops@ietf.org >>=20 >> > https://www.ietf.org/mailman/listinfo/v6ops >>=20 >> _______________________________________________ >>=20 >> v6ops mailing list >>=20 >> v6ops@ietf.org >>=20 >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail-37--379832956 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
I could imagine adjacent prefixes - one is = 2001:dba:2:2::/64 and the other is 2001:dba:2:3::/64. =

Unfortunately. that's not = possible with the way that 6rd operates.

But to my way of = thinking, the prefix in effect chooses the path to the place the prefix = is located.

If it follows normal = routing, it of course chooses the path based on the destination, not the = delegated prefix. 

The reason for source select = routing is the issue raised in BCP 84: BCP 38 will drop traffic if it = takes the wrong path, so please route outbound traffic on the correct = path.

Using the same delegated = prefix avoids this (our #2 scenario), using different prefixes (scenario = #1) causes us to have to deal with this problem. Source select routing = is something that needs to be solved, and is on the list of things we = are worrying about in homenet, but AFAIK it is beyond the current state = of the art. 

If two paths have the same = prefix, then either we're looking at ECMP, or we have a situation in = which the router's tables are = ambiguous...

The draft = specifically says that the native path should have a preferred metric. = Alternatively, an implementation could remove the default route to the = 6rd virtual interface, but that would require some coupling between = interfaces, something that I was trying to = avoid. 

So, I don't see the ambiguity. = With 6rd and native up, there are at most 3 routes. One more-specific = that points to the CE-CE 6rd tunnel, the other one or two that point to = native or 6rd BR upstream, but with a preference for native over = 6rd.

- = Mark




On Nov 17, = 2011, at 1:29 PM, STARK, BARBARA H wrote:

In reading through the 6rd sunsetting draft vs. = 6204bis, I think we may not have fully covered the case (in 6204bis) = where the same prefix is used for 6rd and native. In this case, the = philosophy of =93route based on source address=94 won=92t work, and we = should probably use the =93metric=94 approach proposed by the 6rd = sunsetting draft. We also can=92t unprefer and invalidate the prefix to = the LAN.
 
So perhaps the items in 6204bis = become:
   5.  Selection of 6rd tunnel or native = IPv6 output interface on the CE
, when different prefixes are available over 6rd = vs. native IPv6 (IA_PD). 
       If =
the two interfaces provide the CE router with the same prefix, then the =

       egress =
is preferred when 6rd
   6.  The CE router informs hosts that the native IPv6 =
prefix is preferred over the
       6rd prefix, in = the case where the two interfaces use different prefixes 
Folks,

The use cases that Fred outlined are exactly what we authors = of the document considered and the text in section 4.4.3 of the = rfc6204bis document reflects the fact.  The relevant text for the = section is the first paragraph of the section, bullets 1, 2, 5, and 6, and the last paragraph covers sunsetting of = 6rd.

Thanks, Fred.

-----Original = Message-----
From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On = Behalf Of Fred Baker (fred)
Sent: Wednesday, November 16, 2011 3:03 = PM
To: Hans Liu
Cc: Alexandre Cassen; v6ops@ietf.org WG; Claire = Cheng
Subject: Re: [v6ops] 6rd Sunsetting

The use cases I can think of are:

1) I used to run 6rd and have now deployed native service, = but have not yet turned 6rd off.

2) I am using 6rd in one place and native service somewhere = else.

The second case is a pretty common = coexistence case, I should think, but the two configurations don't = conflict because they are different parts of the network. The first case = is one that is presumably transitory but will be common during a = switchover.

I think the argument = for thinking about routing is to direct traffic to the wider PMTU when = possible and to have native deployment obsolete 6rd deployment quickly. = If the route metrics are the same, one would expect some traffic to use = native and some to use 6rd connectivity, which could be confusing for = someone expecting the 6rd traffic to go to null.

On Nov 15, 2011, at 4:17 PM, Hans Liu = wrote:

> Excuse me Mark, I still don't = have an idea in what kind of use case

> should we have 6rd and Native Dual Stack at the same = time in the

> = network?

> Regards,

> Hans

> On Tue, Nov 15, 2011 at 4:01 PM, = Mark Townsley <mark@townsley.net> = wrote:

>>

>> Alexandre and I just finished up a -00 that = describes two methods for moving

>> a 6rd deployment to native IPv6. Apologies for not = getting this out before

>> the = meeting.

>> >>

>> Abstract

>>

>>   = This document provides guidelines for transitioning an = IPv6

>>   deployment using = IPv6 Rapid Deployment (6rd) to an IPv6 = deployment

>>   = using Native IPv6.  It is targeted at both 6rd operators and = 6rd

>>   = implementors."

>> - = Mark

>> = _______________________________________________

>> v6ops mailing list

>> v6ops@ietf.org

>> >>

>

>

> = --

> Instead of following the fashion, = we lead it through.

> = _______________________________________________

> v6ops mailing list

> v6ops@ietf.org

> v6ops mailing list

v6ops@ietf.org

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


= --Apple-Mail-37--379832956-- From brian.e.carpenter@gmail.com Thu Nov 17 02:24:19 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A54521F9BB9 for ; Thu, 17 Nov 2011 02:24:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.245 X-Spam-Level: X-Spam-Status: No, score=-103.245 tagged_above=-999 required=5 tests=[AWL=-0.246, BAYES_00=-2.599, 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 aQc7wjWgdtej for ; Thu, 17 Nov 2011 02:24:18 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 396B621F9B8C for ; Thu, 17 Nov 2011 02:24:18 -0800 (PST) Received: by yenq4 with SMTP id q4so977425yen.31 for ; Thu, 17 Nov 2011 02:24:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=JOGpy5ko/X3jQIJW98DBU6kOTqUcrXnVYcyFsfGElho=; b=euqWR0XFGT7S7vzRimKN2hlTGk+xFDJXvl1izyr7NgiXR8tWp0aeg9UbUascO2rzsN bg9OFpTxE6mzWeK+S2UzH3EfkPVyFTk/8mHJO8CfjaASBxwcKbN2JFiIuCRVYdWXjvMy 7rhJ9Kn3gRdPs9SBchuKyjDyj45GP6zSFwuB8= Received: by 10.236.154.42 with SMTP id g30mr8120966yhk.3.1321525457684; Thu, 17 Nov 2011 02:24:17 -0800 (PST) Received: from [130.129.19.92] (dhcp-135c.meeting.ietf.org. [130.129.19.92]) by mx.google.com with ESMTPS id k3sm94912278ann.0.2011.11.17.02.24.14 (version=SSLv3 cipher=OTHER); Thu, 17 Nov 2011 02:24:16 -0800 (PST) Message-ID: <4EC4E0C7.6070801@gmail.com> Date: Thu, 17 Nov 2011 23:24:07 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Fred Baker References: <68DAB112-6E32-45FE-9AB7-A34E64898F60@cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30354436E@XMB-RCD-109.cisco.com> <750BF7861EBBE048B3E648B4BB6E8F4F20DC41F6@crexc50p> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Alexandre Cassen , v6ops@ietf.org, Claire Cheng Subject: Re: [v6ops] 6rd Sunsetting X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 Nov 2011 10:24:19 -0000 Fred, Who is applying BCP38? I assume the 6rd operator can figure out that howe= ver the traffic arrives, it is from the appropriate CE, because in the 6rd world,= the operator provides and configure the CE anyway. There would just be the sa= me BCP38 filter on both paths. Regards Brian On 2011-11-17 22:04, Fred Baker wrote: > Personally, I'd be a bit perplexed at putting native and 6rd deployment= into the same prefix. I could imagine adjacent prefixes - one is 2001:db= a:2:2::/64 and the other is 2001:dba:2:3::/64. But to my way of thinking,= the prefix in effect chooses the path to the place the prefix is located= =2E The reason for source select routing is the issue raised in BCP 84: B= CP 38 will drop traffic if it takes the wrong path, so please route outbo= und traffic on the correct path. If two paths have the same prefix, then = either we're looking at ECMP, or we have a situation in which the router'= s tables are ambiguous... >=20 > On Nov 17, 2011, at 1:29 PM, STARK, BARBARA H wrote: >=20 >> In reading through the 6rd sunsetting draft vs. 6204bis, I think we ma= y not have fully covered the case (in 6204bis) where the same prefix is u= sed for 6rd and native. In this case, the philosophy of =E2=80=9Croute ba= sed on source address=E2=80=9D won=E2=80=99t work, and we should probably= use the =E2=80=9Cmetric=E2=80=9D approach proposed by the 6rd sunsetting= draft. We also can=E2=80=99t unprefer and invalidate the prefix to the L= AN. >> =20 >> So perhaps the items in 6204bis become: >> 5. Selection of 6rd tunnel or native IPv6 output interface on the = CE >> router is determined by the source IPv6 address of the packet >> from a host, when different prefixes are available over 6rd vs.= native IPv6 (IA_PD).=20 >> If the two interfaces provide the CE router with the same prefi= x, then the=20 >> CE router assigns a forwarding metric such that native IPv6 >> egress is preferred when 6rd >> and native IPv6 interfaces are active. >> =20 >> 6. The CE router informs hosts that the native IPv6 prefix is pref= erred over the >> 6rd prefix, in the case where the two interfaces use different = prefixes. >> Barbara >> =20 >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf= Of Hemant Singh (shemant) >> Sent: Wednesday, November 16, 2011 4:02 AM >> To: Fred Baker (fred); Hans Liu >> Cc: Alexandre Cassen; v6ops@ietf.org; Claire Cheng >> Subject: Re: [v6ops] 6rd Sunsetting >> =20 >> Folks, >> >> The use cases that Fred outlined are exactly what we authors of the do= cument considered and the text in section 4.4.3 of the rfc6204bis documen= t reflects the fact. The relevant text for the section is the first para= graph of the section, bullets 1, 2, 5, and 6, and the last paragraph cove= rs sunsetting of 6rd. >> >> =20 >> >> http://tools.ietf.org/id/draft-ietf-v6ops-6204bis-02.txt >> >> Thanks, Fred. >> >> Hemant >> >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf= Of Fred Baker (fred) >> Sent: Wednesday, November 16, 2011 3:03 PM >> To: Hans Liu >> Cc: Alexandre Cassen; v6ops@ietf.org WG; Claire Cheng >> Subject: Re: [v6ops] 6rd Sunsetting >> >> The use cases I can think of are: >> >> 1) I used to run 6rd and have now deployed native service, but have no= t yet turned 6rd off. >> >> 2) I am using 6rd in one place and native service somewhere else. >> >> The second case is a pretty common coexistence case, I should think, b= ut the two configurations don't conflict because they are different parts= of the network. The first case is one that is presumably transitory but = will be common during a switchover. >> >> I think the argument for thinking about routing is to direct traffic t= o the wider PMTU when possible and to have native deployment obsolete 6rd= deployment quickly. If the route metrics are the same, one would expect = some traffic to use native and some to use 6rd connectivity, which could = be confusing for someone expecting the 6rd traffic to go to null. >> >> On Nov 15, 2011, at 4:17 PM, Hans Liu wrote: >> >>> Excuse me Mark, I still don't have an idea in what kind of use case >>> should we have 6rd and Native Dual Stack at the same time in the >>> network? >>> Regards, >>> Hans >>> On Tue, Nov 15, 2011 at 4:01 PM, Mark Townsley wr= ote: >>>> Alexandre and I just finished up a -00 that describes two methods fo= r moving >>>> a 6rd deployment to native IPv6. Apologies for not getting this out = before >>>> the meeting. >>>> http://www.ietf.org/id/draft-townsley-v6ops-6rd-sunsetting-00.txt >>>> Abstract >>>> This document provides guidelines for transitioning an IPv6 >>>> deployment using IPv6 Rapid Deployment (6rd) to an IPv6 deployment= >>>> using Native IPv6. It is targeted at both 6rd operators and 6rd >>>> implementors." >>>> - Mark >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>> -- >>> Instead of following the fashion, we lead it through. >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >> _______________________________________________ >> >> v6ops mailing list >> >> v6ops@ietf.org >> >> https://www.ietf.org/mailman/listinfo/v6ops >> >=20 >=20 >=20 > -----------------------------------------------------------------------= - >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From fred@cisco.com Thu Nov 17 02:38:11 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC7321F993E for ; Thu, 17 Nov 2011 02:38:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.546 X-Spam-Level: X-Spam-Status: No, score=-107.546 tagged_above=-999 required=5 tests=[AWL=-0.947, 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 jzzgpybtK8Yi for ; Thu, 17 Nov 2011 02:38:10 -0800 (PST) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id E2B6221F9A15 for ; Thu, 17 Nov 2011 02:38:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=5754; q=dns/txt; s=iport; t=1321526290; x=1322735890; h=from:subject:date:message-id:cc:to:mime-version: content-transfer-encoding; bh=Cg1UYqS/iaL0WDnvEZgQA4L0WTWWcElrdq9Xuev66VU=; b=QFxvVbSEwJSPssfKndyz/Q5ZDvXoASKkJfjv03TW/HaUARLhO3ZLf5Cs jDyGZ8inSa47kvnxUQ+Do2QWn2fWLJtZ7/bgsNfeDfWmfc516IJSjE3zy DmiKq8n9o8DzEAxEE6iRG8YnLM0xjd03eQLjdneTBOS3PkzGdFZgRruXc Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAIvjxE5Io8US/2dsb2JhbABBAal+gQWCCwEnLRJMAoEeB51KAZ4+hxMBgiBjBIgTjCKFO4xO X-IronPort-AV: E=Sophos;i="4.69,526,1315180800"; d="scan'208";a="3316887" Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-3.cisco.com with ESMTP; 17 Nov 2011 10:38:08 +0000 Received: from dhcp-4466.meeting.ietf.org (hkidc-vpn-client-233-100.cisco.com [10.75.233.100]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pAHAc6K9029802; Thu, 17 Nov 2011 10:38:07 GMT Received: from [127.0.0.1] by dhcp-4466.meeting.ietf.org (PGP Universal service); Thu, 17 Nov 2011 18:38:07 +0800 X-PGP-Universal: processed; by dhcp-4466.meeting.ietf.org on Thu, 17 Nov 2011 18:38:07 +0800 From: Fred Baker Date: Thu, 17 Nov 2011 18:37:54 +0800 Message-Id: <754008F3-6B2B-4DD1-B72B-EDE17A4FBF80@cisco.com> To: draft-liu-v6ops-ula-usage-analysis@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org WG" Subject: [v6ops] Major use cases for ULA X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 Nov 2011 10:38:11 -0000 Trying to summarize at least my thoughts from the discussion this = afternoon. Working group, tell me what I'm missing in this. First, as Jari noted from the mike, there is no case in which a ULA is = required. If one is willing to only have connectivity in the link-local = environment, one can communicate between two directly connected systems = using a link-local address. If one has in the past had the use of a = prefix allocated by someone else, but are right now not connected to the = Internet, there is no harm in using that prefix even if it is expired. = Reason: there will be no confusion. As soon as one reconnects, the = expiration of the prefix needs to take effect, however. To my mind, there are three valid uses of a ULA. The choice of use cases = center on the word "local". 1) if one is in a network that does not have service from someone that = will allocate it a prefix and wants to either use addresses that are not = link-local or addresses that will allow for routing, a ULA provides a = way to generate a prefix for the purpose. One example of such an = environment is a Smart Grid HAN in a home that doesn't have an ISP. To = me, this is a textbook case for the use of a ULA. 2) if one is in a network that DOES have service from someone that will = allocate it a prefix but wants to use addresses that are not in that = prefix and are not routed anywhere else, a ULA can provide such a = prefix. There are a number of possible examples.=20 At Cisco, to pick one, we have a number of systems with names like = http://wwwin.cisco.com - systems that offer no services outside Cisco = but provide some interior service. There are at least two ways to = implement that policy. One obvious one would be to put some ACL in the = routers/firewalls at the edge of the network that drop traffic to or = from those addresses. Another, which I would only want to implement in = the presence of that firewall ACL, would be to not advertise the names = outside the company in DNS (probably by implementing a split DNS). A = third would be to give them ULA addresses, which are not advertised = outside the company and are therefore something folks outside can't = route to. Another example is the one I mentioned in RFC 6296; if you choose to use = such a translator, you're going to need an interior prefix. That could = be ULA or global. If it is global and you decide to change away from = that carrier, you will have to renumber the network. If you find that = scary, you might choose a ULA as your internal prefix. The key point is not "6296", nor is it "internal-only policy". It's "In = my addressing plan, I want to use a *different* prefix that is not = routed outside". If you have that policy, one of the options (and not = the only option) would be to use a ULA. 3) If you have a special routing scenario, of which = draft-baker-v6ops-b2b-private-routing is an example, for various reasons = you might want to have routing that you control and is separate from = other routing. In the b2b case, even though two companies each have at = least one ISP, they might choose to ALSO use direct connectivity that = only connects stated machines, such as a silicon foundry with client = engineers that use it. A ULA provides a simple way to obtain such a = prefix that would be used in accordance with an agreement between the = parties. To my mind, the renumbering scenario is a red herring. Thomas Narten = wanted desperately for me to put it into RFC 4192 as "A ULA could help = when renumbering a network". However, it doesn't actually do so. Case 1) suppose I am now using prefix 2001:dba:1::/48 and want to change = to 2001:dba:2:8000::/49. Suppose that I am offering a service (web, = email, whatever) outside of my network. What RFC 4192 suggests is = bringing up the two prefixes in parallel (eg, I am now using both = 2001:dba:1::/48 and 2001:dba:2:8000::/49 throughout my network), and = then take the old one down. The effect: during some part of the = procedure, my external services have first one address, then two = addresses, and finally one, but the one is the new one. I completely = changed my address space, but my service never went down. Case 2) suppose I am now using prefix 2001:dba:1::/48 and want to change = to 2001:dba:2:8000::/49. Suppose that I am offering a service (web, = email, whatever) outside of my network. What the ULA advocates suggest = that I have a ULA up in parallel, either all the time or brought up for = the purpose. I am in effect now using 2001:dba:1::/48 and the ULA. I now = take down 2001:dba:1::/48, and either simultaneously or subsequently = bring up 2001:dba:2:8000::/49. If I do the two sequentially, I have an = interval in which my services are only reachable via the ULA; if I = change them at the same time, the ULA allows me to maintain control of = my network (my network management system and other internal uses can use = it to access equipment and applications within my network), but the = disrupted routing makes my services unavailable in either global prefix = for some period of time. The effect: during some part of the procedure, = the various systems in my network might have one, two, or three = addresses, but during any period in which only the ULA has stable = routing, my services are down as far as any external user is concerned. Hence, a ULA is helpful for folks within my own network, but does not = help keep my externally-facing services running. To my small mind, that = makes a ULA a nice fallback in case something gets screwed up, but it is = not a renumbering solution. It fails to prevent a service outage during = renumbering.= From brian.e.carpenter@gmail.com Thu Nov 17 02:40:00 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A70B21F9BC3 for ; Thu, 17 Nov 2011 02:40:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.937 X-Spam-Level: X-Spam-Status: No, score=-102.937 tagged_above=-999 required=5 tests=[AWL=-0.538, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=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 cPplEEqWfimY for ; Thu, 17 Nov 2011 02:39:59 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id C4F5C21F9BBD for ; Thu, 17 Nov 2011 02:39:52 -0800 (PST) Received: by ywt34 with SMTP id 34so1007866ywt.31 for ; Thu, 17 Nov 2011 02:39:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=pY7sfKhPDnDTPRWix5tzGOQnIwJ7b2QF50SvG9MUdKU=; b=P1tEbg2CMMoNuUdVdfGKu3yxFkhYNArTqEEaFtctkFdj0fKQKJe7l6uUwbry3BTW0P krZPpGfA7fnxynzcCC+Dy+wpAImftycoyKgwAI3/WFqu6QKEW5EzyJgv8eemJDgNCyQm qRXS4N6NsvJWmCaDMkcm0eyiK+XmokjJIAKF8= Received: by 10.236.190.40 with SMTP id d28mr8158803yhn.92.1321526392323; Thu, 17 Nov 2011 02:39:52 -0800 (PST) Received: from [130.129.19.92] (dhcp-135c.meeting.ietf.org. [130.129.19.92]) by mx.google.com with ESMTPS id 4sm94978011ano.9.2011.11.17.02.39.48 (version=SSLv3 cipher=OTHER); Thu, 17 Nov 2011 02:39:51 -0800 (PST) Message-ID: <4EC4E46D.4090701@gmail.com> Date: Thu, 17 Nov 2011 23:39:41 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mark Townsley References: <1F0FCAA1-EE6D-4B20-8F1F-7F985F97493A@townsley.net> <4EC22D3D.9060801@gmail.com> <7CABAB61-E3D3-4C68-91BA-621A5CA0DE51@townsley.net> In-Reply-To: <7CABAB61-E3D3-4C68-91BA-621A5CA0DE51@townsley.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Alexandre Cassen , "v6ops@ietf.org WG" , Claire Cheng Subject: [v6ops] draft-townsley-v6ops-6rd-sunsetting-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 Nov 2011 10:40:00 -0000 Major comments first: I like. I have just re-read section 3 "Smooth Transition towards IPv6 Infrastructure" of RFC 6264 and I think it fits with your model almost seamlessly. (If you re-read it, remember that 6264 makes two assumptions: ISPs will run CGNs whether we like it or not, and the CGN as described in 6264 coexists with a 6rd decapsulator.) If you agree with this you could easily add an informative reference to 6264. > 4. When native IPv6 becomes active on a given CE, an upstream > default route is installed for IPv6 as it normally would, while > assigning a metric that causes the native link to be preferred > over 6rd. I assume you mean that a *second* /128 route is installed, with the first one being provisioned as part of the pure 6rd phase. > 6rd routes remain as long as 6rd is configured by the > SP, allowing the more-specific route for inter-domain 6rd traffic > to be selected over the native route (again, following normal IP > forwarding rules). Which "6rd routes"? This is the first time you mention them. Do you mean that as well as the default (/128) route, there is also a specific route for the local 6rd prefix (e.g. a /32)? Minor: > Unlike 6to4 [RFC3056], 6rd is designed to be configured and operated > by an SP. Actually RFC3056 *was* intended to be a managed solution configured and operated by enterprise and SP operators. The one you mean to insult is Anycast 6to4 [RFC3068]. > Using this mode, end-user sites are renumbered when moving from 6rd > to native IPv6. Recommendations for "Renumbering Without a Flag Day" > described in [RFC4192] should be followed. I wish it was that simple; it isn't really, which is why we have just started 6RENUM. It would be useful if you could look at the various draft-*-6renum drafts to see if we have missed any issues that will come up during your sunset. In any case, why would anybody want to use the renumbering model if you can make the non-renumbering model work properly? Regards Brian On 2011-11-15 22:37, Mark Townsley wrote: > On Nov 15, 2011, at 5:13 PM, Brian E Carpenter wrote: > >> Mark, >> >> I will read the draft when a calm moment arrives. But I have to ask, >> what is its relationship to RFC 6264? That already includes 6rd >> as one option in the path to v6ness. > > This is very specific for 6rd to native (no CGN, ds-lite, etc), and, importantly, includes specific requirements for CPE implementors. Relevant as 6204-bis has brought 6rd into its scope. > > I look forward to your review, and whether it is in conflict in anyway with 6264 in your mind. > > - Mark > >> Regards >> Brian >> >> On 2011-11-15 21:46, Mark Townsley wrote: >>> On Nov 15, 2011, at 4:17 PM, Hans Liu wrote: >>> >>>> Excuse me Mark, I still don't have an idea in what kind of use case >>>> should we have 6rd and Native Dual Stack at the same time in the >>>> network? >>> Incremental transition from 6rd to native. >>> >>> - Mark >>> >>>> Regards, >>>> Hans >>>> >>>> On Tue, Nov 15, 2011 at 4:01 PM, Mark Townsley wrote: >>>>> Alexandre and I just finished up a -00 that describes two methods for moving >>>>> a 6rd deployment to native IPv6. Apologies for not getting this out before >>>>> the meeting. >>>>> http://www.ietf.org/id/draft-townsley-v6ops-6rd-sunsetting-00.txt >>>>> >>>>> Abstract >>>>> >>>>> This document provides guidelines for transitioning an IPv6 >>>>> deployment using IPv6 Rapid Deployment (6rd) to an IPv6 deployment >>>>> using Native IPv6. It is targeted at both 6rd operators and 6rd >>>>> implementors." >>>>> >>>>> - Mark >>>>> _______________________________________________ >>>>> v6ops mailing list >>>>> v6ops@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>> >>>>> >>>> >>>> -- >>>> Instead of following the fashion, we lead it through. >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> > > From v6ops@daork.net Thu Nov 17 02:59:08 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D54D221F9A94 for ; Thu, 17 Nov 2011 02:59:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xpL-xJ9EBnl8 for ; Thu, 17 Nov 2011 02:59:08 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4726121F9A8C for ; Thu, 17 Nov 2011 02:59:08 -0800 (PST) Received: by yenq4 with SMTP id q4so1018746yen.31 for ; Thu, 17 Nov 2011 02:59:07 -0800 (PST) Received: by 10.236.143.3 with SMTP id k3mr8151611yhj.91.1321527547854; Thu, 17 Nov 2011 02:59:07 -0800 (PST) Received: from [192.168.0.34] ([121.98.251.230]) by mx.google.com with ESMTPS id l18sm1952193anb.22.2011.11.17.02.59.05 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 17 Nov 2011 02:59:07 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Nathan Ward In-Reply-To: <754008F3-6B2B-4DD1-B72B-EDE17A4FBF80@cisco.com> Date: Thu, 17 Nov 2011 23:59:01 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <754008F3-6B2B-4DD1-B72B-EDE17A4FBF80@cisco.com> To: Fred Baker X-Mailer: Apple Mail (2.1251.1) Cc: "v6ops@ietf.org WG" , draft-liu-v6ops-ula-usage-analysis@tools.ietf.org Subject: Re: [v6ops] Major use cases for ULA X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 Nov 2011 10:59:08 -0000 On 17/11/2011, at 11:37 PM, Fred Baker wrote: > 1) if one is in a network that does not have service from someone that = will allocate it a prefix and wants to either use addresses that are not = link-local or addresses that will allow for routing, a ULA provides a = way to generate a prefix for the purpose. One example of such an = environment is a Smart Grid HAN in a home that doesn't have an ISP. To = me, this is a textbook case for the use of a ULA. >=20 > 2) if one is in a network that DOES have service from someone that = will allocate it a prefix but wants to use addresses that are not in = that prefix and are not routed anywhere else, a ULA can provide such a = prefix. There are a number of possible examples.=20 Something similar to both of the above, internal DNS services where you = have a dynamic prefix (say an ADSL line) but a routed internal network. = An very very common example of an internal DNS service is Active = Directory, or anything that does DNS updates after dynamic address = assignment to end hosts. I'm not familiar with the background to this discussion, but it sounds = like someone is talking about taking it away, and that would be bad. = I've taught a heap of IPv6 courses so have a wide view of weird and = wonderful IPv6 deployments, and ULA is very much an important tool. -- Nathan Ward= From Anders_Brandt@sigmadesigns.com Thu Nov 17 02:57:08 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0475921F99A7; Thu, 17 Nov 2011 02:57:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.105 X-Spam-Level: X-Spam-Status: No, score=0.105 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RDNS_NONE=0.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 228Ol0-IGmqb; Thu, 17 Nov 2011 02:57:07 -0800 (PST) Received: from CPH-EX1.sdesigns.com (unknown [195.215.56.171]) by ietfa.amsl.com (Postfix) with ESMTP id 5D63521F999C; Thu, 17 Nov 2011 02:57:06 -0800 (PST) Received: from CPH-EX1.sdesigns.com ([192.168.10.36]) by cph-ex1 ([192.168.10.36]) with mapi id 14.01.0270.001; Thu, 17 Nov 2011 11:57:05 +0100 From: Anders Brandt To: Fred Baker , "draft-liu-v6ops-ula-usage-analysis@tools.ietf.org" Thread-Topic: [v6ops] Major use cases for ULA Thread-Index: AQHMpRV7q3uJbPTXJESRbtUav6pFZpWw4Ym3 Date: Thu, 17 Nov 2011 10:57:04 +0000 Message-ID: <03F31C213F2C6941BFDDBB4336E9E6CD0AB40668@cph-ex1> References: <754008F3-6B2B-4DD1-B72B-EDE17A4FBF80@cisco.com> In-Reply-To: <754008F3-6B2B-4DD1-B72B-EDE17A4FBF80@cisco.com> Accept-Language: en-US, da-DK Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.10.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 17 Nov 2011 03:00:30 -0800 Cc: "v6ops@ietf.org WG" , "homenet@ietf.org" Subject: Re: [v6ops] Major use cases for ULA X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 Nov 2011 10:58:36 -0000 May I suggest variant 1b) : A home control installation with some powerline devices and some wireless d= evices each part of a lighting control system that MUST ALWAYS work. Both subnets are installed in autonomous fashion by two different technicia= ns. Later, their border routers are interconnected via the homenet backbone= . We may argue if a ULA prefix is needed in the homenet backbone but both of = the home control networks need ULA addresses A: because the devices need stable addresses so that they know where to sen= d On/Off commands to the other subnet without depending on DNS servers, etc= . B: because there is no infrastructure to coordinate the assignment of prefi= xes in the two home control subnets C: because LLNs often do use coordinated assignment of short link-layer add= resses to get shorter frames and to improve header compression. These short link-layer would often lead to duplicate IPv6 addresses if = in the same subnet.=20 Thanks, Anders Brandt ________________________________________ From: v6ops-bounces@ietf.org [v6ops-bounces@ietf.org] on behalf of Fred Bak= er [fred@cisco.com] Sent: Thursday, November 17, 2011 11:37 To: draft-liu-v6ops-ula-usage-analysis@tools.ietf.org Cc: v6ops@ietf.org WG Subject: [v6ops] Major use cases for ULA Trying to summarize at least my thoughts from the discussion this afternoon= . Working group, tell me what I'm missing in this. First, as Jari noted from the mike, there is no case in which a ULA is requ= ired. If one is willing to only have connectivity in the link-local environ= ment, one can communicate between two directly connected systems using a li= nk-local address. If one has in the past had the use of a prefix allocated = by someone else, but are right now not connected to the Internet, there is = no harm in using that prefix even if it is expired. Reason: there will be n= o confusion. As soon as one reconnects, the expiration of the prefix needs = to take effect, however. To my mind, there are three valid uses of a ULA. The choice of use cases ce= nter on the word "local". 1) if one is in a network that does not have service from someone that will= allocate it a prefix and wants to either use addresses that are not link-l= ocal or addresses that will allow for routing, a ULA provides a way to gene= rate a prefix for the purpose. One example of such an environment is a Smar= t Grid HAN in a home that doesn't have an ISP. To me, this is a textbook ca= se for the use of a ULA. 2) if one is in a network that DOES have service from someone that will all= ocate it a prefix but wants to use addresses that are not in that prefix an= d are not routed anywhere else, a ULA can provide such a prefix. There are = a number of possible examples. At Cisco, to pick one, we have a number of systems with names like http://w= wwin.cisco.com - systems that offer no services outside Cisco but provide s= ome interior service. There are at least two ways to implement that policy.= One obvious one would be to put some ACL in the routers/firewalls at the e= dge of the network that drop traffic to or from those addresses. Another, w= hich I would only want to implement in the presence of that firewall ACL, w= ould be to not advertise the names outside the company in DNS (probably by = implementing a split DNS). A third would be to give them ULA addresses, whi= ch are not advertised outside the company and are therefore something folks= outside can't route to. Another example is the one I mentioned in RFC 6296; if you choose to use su= ch a translator, you're going to need an interior prefix. That could be ULA= or global. If it is global and you decide to change away from that carrier= , you will have to renumber the network. If you find that scary, you might = choose a ULA as your internal prefix. The key point is not "6296", nor is it "internal-only policy". It's "In my = addressing plan, I want to use a *different* prefix that is not routed outs= ide". If you have that policy, one of the options (and not the only option)= would be to use a ULA. 3) If you have a special routing scenario, of which draft-baker-v6ops-b2b-p= rivate-routing is an example, for various reasons you might want to have ro= uting that you control and is separate from other routing. In the b2b case,= even though two companies each have at least one ISP, they might choose to= ALSO use direct connectivity that only connects stated machines, such as a= silicon foundry with client engineers that use it. A ULA provides a simple= way to obtain such a prefix that would be used in accordance with an agree= ment between the parties. To my mind, the renumbering scenario is a red herring. Thomas Narten wanted= desperately for me to put it into RFC 4192 as "A ULA could help when renum= bering a network". However, it doesn't actually do so. Case 1) suppose I am now using prefix 2001:dba:1::/48 and want to change to= 2001:dba:2:8000::/49. Suppose that I am offering a service (web, email, wh= atever) outside of my network. What RFC 4192 suggests is bringing up the tw= o prefixes in parallel (eg, I am now using both 2001:dba:1::/48 and 2001:db= a:2:8000::/49 throughout my network), and then take the old one down. The e= ffect: during some part of the procedure, my external services have first o= ne address, then two addresses, and finally one, but the one is the new one= . I completely changed my address space, but my service never went down. Case 2) suppose I am now using prefix 2001:dba:1::/48 and want to change to= 2001:dba:2:8000::/49. Suppose that I am offering a service (web, email, wh= atever) outside of my network. What the ULA advocates suggest that I have a= ULA up in parallel, either all the time or brought up for the purpose. I a= m in effect now using 2001:dba:1::/48 and the ULA. I now take down 2001:dba= :1::/48, and either simultaneously or subsequently bring up 2001:dba:2:8000= ::/49. If I do the two sequentially, I have an interval in which my service= s are only reachable via the ULA; if I change them at the same time, the UL= A allows me to maintain control of my network (my network management system= and other internal uses can use it to access equipment and applications wi= thin my network), but the disrupted routing makes my services unavailable i= n either global prefix for some period of time. The effect: during some par= t of the procedure, the various systems in my network might have one, two, = or three addres ses, but during any period in which only the ULA has stable routing, my se= rvices are down as far as any external user is concerned. Hence, a ULA is helpful for folks within my own network, but does not help = keep my externally-facing services running. To my small mind, that makes a = ULA a nice fallback in case something gets screwed up, but it is not a renu= mbering solution. It fails to prevent a service outage during renumbering. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops= From brian.e.carpenter@gmail.com Thu Nov 17 03:10:12 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABEC521F9B47 for ; Thu, 17 Nov 2011 03:10:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.515 X-Spam-Level: X-Spam-Status: No, score=-103.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dun0MoUFUdNd for ; Thu, 17 Nov 2011 03:10:10 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id D207B21F9B43 for ; Thu, 17 Nov 2011 03:10:08 -0800 (PST) Received: by ggnr5 with SMTP id r5so1035494ggn.31 for ; Thu, 17 Nov 2011 03:10:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=/BSJzTXWhi7xphQBQFYaCD/ETDafdfNG2u/wzFW/Yzw=; b=JheorGAlsHR1C0tYju2CzHVUljBnvPaMbutH31JtZjk42smeBn7fYbofqixQ1VetVG PCQUShPZ/X3YHRpie6+ZA/pM1OQtpMx0jNEK2f2rn67tw3pFRqfl8P1U75+i+6u+g5uf aXLLkla/5x6qzYrBvLu8+5Y6S5QSUoKOpojRs= Received: by 10.101.85.4 with SMTP id n4mr11107868anl.155.1321528208299; Thu, 17 Nov 2011 03:10:08 -0800 (PST) Received: from [130.129.19.92] (dhcp-135c.meeting.ietf.org. [130.129.19.92]) by mx.google.com with ESMTPS id 32sm13923199anu.10.2011.11.17.03.10.05 (version=SSLv3 cipher=OTHER); Thu, 17 Nov 2011 03:10:07 -0800 (PST) Message-ID: <4EC4EB86.80308@gmail.com> Date: Fri, 18 Nov 2011 00:09:58 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ray Hunter References: <20111115062859.14026.42405.idtracker@ietfa.amsl.com> <4EC2ABA8.4020303@globis.net> <4EC2FD24.1090303@gmail.com> <4EC37529.4070505@globis.net> <20111117013452.19F35179A55F@drugs.dv.isc.org> <4EC469E7.9010602@gmail.com> <20111117055040.E34FC179DAF9@drugs.dv.isc.org> <4EC4D7D1.8050601@globis.net> In-Reply-To: <4EC4D7D1.8050601@globis.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 11:10:12 -0000 Ray, On 2011-11-17 22:45, Ray Hunter wrote: > Agreed. Most multinationals I know are already LIRs. They can run BGP to > the major sites with multiple ISPs and their own PI /32. That's the easy > bit. > > But it isn't just about a few large sites and 2 ISP's. There's also the > rest of the private corporate network covering 50+ countries + multiple > (smaller) ISPs to consider. Exactly. The small number of biiig multinationals is not an issue. > > IMHO I have seen three use cases so far in production today in IPv4 that > are not really covered in IPv6. To be frank, these current solutions > seem mainly to be driven by commercial considerations rather than > technical ones. So if a commercial solution could be found, there > wouldn't be much resistance to change. Most problems are due to the > return route, not the outbound one. > > 1. Home workers, remote branch offices, and SME's that need higher > availability than a single consumer ISP link, but don't have the > capability/desire/cash/ISP to run a multihomed BGP AS. Today they can > use a simple outbound-only load-balancing box, or a specialist VPN box > that provides 2 GRE/IPSec tunnels via 2 ISPs. The GRE/IPSec solution > will obviously work in the future, but the load balancer won't. Multipath TCP would handle the load balancing issue (but not of course for non-TCP traffic). Shim6 would handle failover for all types of flow. But both of these need both ends to play, which makes deployment sticky. > > 2. Local Internet break out. Remote corporate site is still connected to > the corporate network for business/production critical apps, but > Internet traffic is gatewayed directly into the Public Internet at the > local site for Internet centric apps like foobarnow.com. Today the local > site Internet firewall/router can use NAT44 outbound: guaranteeing a > return route direct to the local site. Most, but not all, Internet > centric apps are web based, but that would mean installing a proxy on > every site for IPv6. I see no solution so far for apps that are > "NAT44-able" but "non-proxy-able" with IPv6. Negotiating ISP routing of > a single /48 in country X from the PI /32 is unlikely to work in all > cases. I guess these sites could just use PA space addresses, but then > you have limited service availability, and potential renumbering issues. Why? If the local PA link goes down, you'd revert to a slower path using an address under the PI prefix. In my experience when I was such a corporate user, I got renumbered whenever I reconnected my ThinkPad. It was never an issue. > > 3. Internet offload. Remote corporate site has a main link and an > Internet connection. Local site router is connected to both and uses > Policy Based Routing (PBR) to route down the appropriate link. A GRE > tunnel carries the bulk traffic over the Internet to the regional > corporate data centre, where it emerges from the tunnel and passes > through the usual security controls onto the Public Internet. Return > route to the GRE tunnel is guaranteed via NAT. Otherwise you'd need to > run PBR on the DC firewall as the Internet tunnel and private corporate > network are connected to different security zones on the firewall. PBR > on firewalls doesn't exist so far AFAIK. Firewalls aren't routers, but they can have routers glued onto them. Brian > > In most cases there's multiple hops (and possibly security devices) > between the end nodes and the point where the alternative paths split. > > > Mark Andrews wrote: >> >> >> I would expect multi-nationals to be able to work around these sort >> of restrictions already. My primary focus is to make it work for >> the home / small office. Bigger customers can usually make this >> work today without automation. Homes and small offices can't because >> them man power cost is too high to deal with the volume. >> >> That said I would welcome a solution that scales up to handle any >> business that isn't a ISP. >> >> Mark >> > > From brian.e.carpenter@gmail.com Thu Nov 17 03:19:49 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57B8E21F9BB2 for ; Thu, 17 Nov 2011 03:19:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.517 X-Spam-Level: X-Spam-Status: No, score=-103.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mNJfr6yVfeKA for ; Thu, 17 Nov 2011 03:19:48 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id CDBEB21F9BB1 for ; Thu, 17 Nov 2011 03:19:48 -0800 (PST) Received: by yenq4 with SMTP id q4so1045098yen.31 for ; Thu, 17 Nov 2011 03:19:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=S0yNOuSDe4m2v/L0ZbMNbaOxaNGLxMMwxVIMpWojZYQ=; b=qdsZfV4WcbiKzMz5XP7FnhtDKPXBu0Kqkys1mRML6NHZlkCIgAtKUdSAwepWiURRvv HJhVFHe7ltRiCtz4TPWKtLD/okKu2lcxnrJtQehRahGKceGHDYJRNOhgfwyKotHPPual czVPuQuejpp/mXiAvZCiUqbUhaI6EFxWEyG4E= Received: by 10.236.200.131 with SMTP id z3mr8409719yhn.129.1321528788476; Thu, 17 Nov 2011 03:19:48 -0800 (PST) Received: from [130.129.19.92] (dhcp-135c.meeting.ietf.org. [130.129.19.92]) by mx.google.com with ESMTPS id q5sm5504766yhm.7.2011.11.17.03.19.45 (version=SSLv3 cipher=OTHER); Thu, 17 Nov 2011 03:19:47 -0800 (PST) Message-ID: <4EC4EDC9.1080003@gmail.com> Date: Fri, 18 Nov 2011 00:19:37 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Fred Baker References: <754008F3-6B2B-4DD1-B72B-EDE17A4FBF80@cisco.com> In-Reply-To: <754008F3-6B2B-4DD1-B72B-EDE17A4FBF80@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org WG" , draft-liu-v6ops-ula-usage-analysis@tools.ietf.org Subject: Re: [v6ops] Major use cases for ULA X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 Nov 2011 11:19:49 -0000 Fred, > First, as Jari noted from the mike, there is no case in which a ULA is required. Then how do we assign a prefix for a totally isolated network that includes at least two subnets? I realise that no such network will exist for ever without getting connected to the Internet, but during the time that it does exist in isolation, ULA seems a better solution than having people make up their own unicast prefix or applying to ARIN for a PI prefix. Beyond that I'm getting too sleepy to work through your analysis, but I think Bing's model of documenting the full range of use cases in a neutral manner is a good first step. The second step might well be guidelines about which ones are viable and which ones are harmful. As Nathan's comment shows, opinions may vary. Regards Brian From shtsuchi@cisco.com Thu Nov 17 03:20:16 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D001921F9BCB for ; Thu, 17 Nov 2011 03:20:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.132 X-Spam-Level: X-Spam-Status: No, score=-7.132 tagged_above=-999 required=5 tests=[AWL=-1.133, BAYES_00=-2.599, J_CHICKENPOX_72=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 AFwuTNpKMGUo for ; Thu, 17 Nov 2011 03:20:14 -0800 (PST) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id E0E8921F9BC7 for ; Thu, 17 Nov 2011 03:20:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shtsuchi@cisco.com; l=1377; q=dns/txt; s=iport; t=1321528813; x=1322738413; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=wyAmsnGXDeHXFXJ3eUgZGtwq9FLqHWjcNw9r/x/AsxA=; b=UFT8JZRpi2HJoqSwH09lkmsyqF0jlDAHcrF5PGzBXPRn/5TBgTyCcpEx h+BWYVafOzAw6K2S/feZ26KO1c8XoJPjofqWBHsf9cQTtPfx0I8oTzKCp qOTkCiPeNHENDUzEHkAIyi20scTFlLBhAOWecvMDDZvMBN368dQT9IoEj E=; X-IronPort-AV: E=Sophos;i="4.69,526,1315180800"; d="scan'208";a="3321844" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-3.cisco.com with ESMTP; 17 Nov 2011 11:20:10 +0000 Received: from [10.70.231.124] (tky-vpn-client-231-124.cisco.com [10.70.231.124]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pAHBK6eh019641; Thu, 17 Nov 2011 11:20:07 GMT Message-ID: <4EC4EDE5.2000306@cisco.com> Date: Thu, 17 Nov 2011 19:20:05 +0800 From: Shishio Tsuchiya User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: mark@townsley.net References: In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: acassen@freebox.fr, v6ops@ietf.org Subject: Re: [v6ops] 6rd Sunsetting X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 Nov 2011 11:20:16 -0000 Mark and Alexandre Thank you for publishing this document. When I discuss about 6rd deployment with operators,"sunsetting" is also often considered. I had 2 idea, 1.change transport to IPv6 "sunsetting" 2.use private IPv4 compression address with multiple 6rd domains "survival" But "survival" is not healthy,so I think this "sunsetting" draft would be useful for operators. And I have comments about section 5. http://tools.ietf.org/html/draft-townsley-v6ops-6rd-sunsetting-00#section-5 2. CEs reachable by Native IPv6 are configured via DHCPv6-PD [RFC3633] with the same delegated prefix calculated and in use by 6rd. If 6rd delegated prefix could copy to DHCPv6-PD OPTION_IAPREFIX (26) in solicit,it is easy. http://tools.ietf.org/html/rfc3633#section-10 Regards, -Shishio (2011/11/15 16:01), Mark Townsley wrote: > > Alexandre and I just finished up a -00 that describes two methods for moving a 6rd deployment to native IPv6. Apologies for not getting this out before the meeting. > > http://www.ietf.org/id/draft-townsley-v6ops-6rd-sunsetting-00.txt > > Abstract > > This document provides guidelines for transitioning an IPv6 > deployment using IPv6 Rapid Deployment (6rd) to an IPv6 deployment > using Native IPv6. It is targeted at both 6rd operators and 6rd > implementors." > > > - Mark From Ted.Lemon@nominum.com Thu Nov 17 04:34:36 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCEAF11E810F for ; Thu, 17 Nov 2011 04:34:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.566 X-Spam-Level: X-Spam-Status: No, score=-106.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 H6Ro51ct83LW for ; Thu, 17 Nov 2011 04:34:35 -0800 (PST) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE7F11E8112 for ; Thu, 17 Nov 2011 04:34:33 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKTsT/WDQkaJR6kRwSFSzWZRtuYsRkxF05@postini.com; Thu, 17 Nov 2011 04:34:34 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 4387F1B82E2 for ; Thu, 17 Nov 2011 04:34:32 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 3250119005D; Thu, 17 Nov 2011 04:34:32 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.01.0339.001; Thu, 17 Nov 2011 04:34:32 -0800 From: Ted Lemon To: Fred Baker Thread-Topic: [v6ops] Major use cases for ULA Thread-Index: AQHMpRUIso3G0hT1x0+tTu8QOVetT5WxAFiu Date: Thu, 17 Nov 2011 12:34:31 +0000 Message-ID: <59AE9692-C8E9-4B64-98C9-A28DF5C8C622@nominum.com> References: <754008F3-6B2B-4DD1-B72B-EDE17A4FBF80@cisco.com> In-Reply-To: <754008F3-6B2B-4DD1-B72B-EDE17A4FBF80@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org WG" , "draft-liu-v6ops-ula-usage-analysis@tools.ietf.org" Subject: Re: [v6ops] Major use cases for ULA X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 Nov 2011 12:34:36 -0000 On Nov 17, 2011, at 6:38 PM, "Fred Baker" wrote: > If one has in the past had the use of a prefix allocated by someone else,= but are right now not connected to the Internet, there is no harm in using= that prefix even if it is expired. Reason: there will be no confusion. As = soon as one reconnects, the expiration of the prefix needs to take effect, = however. This is all very well and good as long as we believe we can count on detect= ing when this transition happens. I would argue that we really can't. O= f course, I suppose in practice the way this would look would be that we wo= uld think we were still connected when we weren't, and would therefore expi= re the prefix, but the point is that the very simple solution you've sugges= ted here really is not something that I would expect to be robust in wide d= eployment. From shemant@cisco.com Thu Nov 17 04:37:59 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBF8C21F9860 for ; Thu, 17 Nov 2011 04:37:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.94 X-Spam-Level: X-Spam-Status: No, score=-5.94 tagged_above=-999 required=5 tests=[AWL=0.059, 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 2mF4OFwbtXYz for ; Thu, 17 Nov 2011 04:37:59 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id B110721F984B for ; Thu, 17 Nov 2011 04:37:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=2354; q=dns/txt; s=iport; t=1321533479; x=1322743079; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=hJp2QhNR0Sbs/viki+4F34DcPWp9S/7cbqZeqNIb2zw=; b=Ww3Qlkj5/OsiefOLRifvA9GsDfnSbIkKFDZdvmmDZpdnbnYQb9+Kzu/S jLUcIwX45TIPSB1niI3Hhe/VzT+pduzOZ6tgQB+BVGYbtmTTomeaRdmko 83L3H+rnFZWEJt7bezFo4vDOnHnjYMvlYYiUbTWEKOi45Nm7NBMZDB0gF 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AooAAI7/xE6tJXHA/2dsb2JhbABCmXiQBoEFgXIBAQEDAQEBAQ8BHQotBwsFBwQCAQgRBAEBCwYXAQYBJh8JCAEBBAESCBMHh2AIli0BnkQEiTRjBIgVkWSMVw X-IronPort-AV: E=Sophos;i="4.69,526,1315180800"; d="scan'208";a="36891752" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-1.cisco.com with ESMTP; 17 Nov 2011 12:37:57 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id pAHCbv3U008305; Thu, 17 Nov 2011 12:37:57 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Nov 2011 06:37:56 -0600 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Nov 2011 06:37:54 -0600 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3035447F3@XMB-RCD-109.cisco.com> In-Reply-To: <4EC4EDC9.1080003@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] Major use cases for ULA Thread-Index: AcylGtaRnlI+V2kyTu+82RQql8uZ3wACNLAA References: <754008F3-6B2B-4DD1-B72B-EDE17A4FBF80@cisco.com> <4EC4EDC9.1080003@gmail.com> From: "Hemant Singh (shemant)" To: "Brian E Carpenter" , "Fred Baker (fred)" X-OriginalArrivalTime: 17 Nov 2011 12:37:56.0789 (UTC) FILETIME=[BBAC0E50:01CCA525] Cc: v6ops@ietf.org, draft-liu-v6ops-ula-usage-analysis@tools.ietf.org Subject: Re: [v6ops] Major use cases for ULA X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 Nov 2011 12:38:00 -0000 Note as of circa 2007-2008, in v6ops discussion on the IPv6 CPE router draft we clearly said the ULA in the home LAN serves as a stable prefix for the computer at home to print to the printer at home with the SP global link has gone down. The ULA has already been specified in RFC 6204. Thus at least no new document is needed to outline such a use which has been already carried over to homenet. The other use case of the ULA was also discussed around the same time as above to configure the CPE router using a URL. It was distinctly noted that some web browsers will not serve a URL with a link-local address. Then an IPv6 global is needed and the ULA has global scope. Soon as the CPE router is powered up the ULA can be used to access the device over the web when the user has not even connected the CPE WAN to the Internet SP. =20 The ULA document in RFC 4193 already specifies properties of the ULA that make it relatively clear to a reader where the ULA can be used. Thus why do we need a new document to document what the ULA can be used for? =20 Hemant -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Brian E Carpenter Sent: Thursday, November 17, 2011 7:20 PM To: Fred Baker (fred) Cc: v6ops@ietf.org WG; draft-liu-v6ops-ula-usage-analysis@tools.ietf.org Subject: Re: [v6ops] Major use cases for ULA Fred, > First, as Jari noted from the mike, there is no case in which a ULA is required. Then how do we assign a prefix for a totally isolated network that includes at least two subnets? I realise that no such network will exist for ever without getting connected to the Internet, but during the time that it does exist in isolation, ULA seems a better solution than having people make up their own unicast prefix or applying to ARIN for a PI prefix. Beyond that I'm getting too sleepy to work through your analysis, but I think Bing's model of documenting the full range of use cases in a neutral manner is a good first step. The second step might well be guidelines about which ones are viable and which ones are harmful. As Nathan's comment shows, opinions may vary. Regards Brian _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From cxc@xmu.edu.cn Thu Nov 17 05:05:59 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D67771F0CA1 for ; Thu, 17 Nov 2011 05:05:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.004 X-Spam-Level: * X-Spam-Status: No, score=1.004 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, FH_RELAY_NODNS=1.451, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xt0+afJoeFBw for ; Thu, 17 Nov 2011 05:05:55 -0800 (PST) Received: from xmu.edu.cn (unknown [IPv6:2001:da8:e800:0:e61f:13ff:fe38:8310]) by ietfa.amsl.com (Postfix) with ESMTP id 0FE311F0C9A for ; Thu, 17 Nov 2011 05:05:53 -0800 (PST) Received: from JustinChenPC (unknown [210.34.8.198]) by app (Coremail) with SMTP id 0iL_+5DbMzLTA8VOAFpiAg--.58310S2; Thu, 17 Nov 2011 20:53:39 +0800 (CST) From: "Justin Chen" To: "'Fred Baker'" References: <20111013211312.B6C7421F8AFF@ietfa.amsl.com> <619C3B81-1CDC-4341-8180-EC8472864CC0@cisco.com> <4EA53FB7.6090603@cernet.edu.cn> <91B5BAD7-9C72-4619-8822-A52D3EFC4EBE@cisco.com> In-Reply-To: <91B5BAD7-9C72-4619-8822-A52D3EFC4EBE@cisco.com> Date: Thu, 17 Nov 2011 21:05:42 +0800 Message-ID: <000001cca529$9c9c6880$d5d53980$@xmu.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHt0io9Yk+bWyYyqrC3oWqJ+cZnVwLqtxVLATtwLnYBB1qhzJVFQU8w Content-Language: zh-cn X-CM-TRANSID: 0iL_+5DbMzLTA8VOAFpiAg--.58310S2 X-Coremail-Antispam: 1UD129KBjvJXoWxWw1DtFWDuFW3tr43WrWUXFb_yoWrJF1rpa yUWa1rCrWkXwnagwn2qw1vyryYv3y7Aay8GF13tr9Fy398tFZ2yr4jkw1fZrWDuF4fGF1v qr4UCr18ur4fJ3DanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUU42b7IF0VCFI7km07C26c804VAKzcIF0wAYjxAI6xZILanIXVAF wwAYjsxI4VWxJwAYFVCjjxCrM7CY07I20VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM2k07c x0zVAaqwAawVCIc40E5I027xCE548m6r1DJr4UtwAqjxCEc2xF0cIa020Ex4CE44I27wAq jxCE34x0Y48IcwAqx4xG64xvF2IEw4CE5I8CrVC2j2WlYx0E2Ix0cI8IcVAFwI0_Jr0_Jr 4lYx0Ex4A2jsIE14v26r1j6r4UM4x0Y48IcxkI7VAKI48JMxAIw28IcxkI7VAKI48JMxCI bVA2zIxYr2IEbsI20wCFI7vE0wC2zVAF1VAY17CE14v26r1Y6r17MIIYrxkI7VAKI48JMs 8CjcxG0xvEz27vcSsGvfC2KfnxnUUI43ZEXa7IUbBOJ7UUUUU== X-CM-SenderInfo: hf0fq5lpxovvfxof0/ Cc: v6ops@ietf.org Subject: [v6ops] =?utf-8?b?562U5aSNOiAgRndkOiA4Mm5kIElFVEYgRFJBRlQgQWdl?= =?utf-8?q?nda?= X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 Nov 2011 13:06:00 -0000 Hi all, I support draft-xli-v6ops-ivi-icmp-address-00.txt to be adopted as a WG = document in V6ops. Based on our experience, I think a special block of IPv4 address = representing non-IPv4 translatable address will be very useful for = trouble shooting in campus network.=20 Regards, Chen Xiaochou -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: Fred Baker [mailto:fred@cisco.com]=20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2011=E5=B9=B410=E6=9C=8824=E6=97=A5 20:24 =E6=94=B6=E4=BB=B6=E4=BA=BA: v6ops@ietf.org WG =E6=8A=84=E9=80=81: V6ops Chairs =E4=B8=BB=E9=A2=98: Re: [v6ops] Fwd: 82nd IETF DRAFT Agenda Looking for comments/support from the working group. On Oct 24, 2011, at 3:36 AM, Xing Li wrote: > Hi, Fred and All, >=20 > =E4=BA=8E 2011/10/14 5:52, Fred Baker =E5=86=99=E9=81=93: >> The initial version of the agenda has been posted. It places v6ops on = Wednesday and Friday mornings, a total of 4.5 hours. I personally am = satisfied with it, but if folks have issues I can pass them along. >>=20 >> I'll note that the deadline for -00 drafts is 24 October, and the = deadline for updated drafts is a week later. For discussion in the = working group meetings, I'm looking for a draft posted after 25 July, = with supporting email discussion on the list. >>=20 >> I'm looking for (and in some cases have seen) commentary on each of: >>=20 >> -rw-rw-r-- 1 fred fred 13796 Jul 25 23:59=20 >> draft-xli-v6ops-ivi-icmp-address-00.txt >=20 > I would like to request that the V6ops WG adopt = draft-xli-v6ops-ivi-icmp-address-00.txt as a WG adoption. >=20 > The draft describes the operational considerations of mapping ICMPv6 = packets through an RFC6145 gateway where the IPv6 address is not = directly translatable into an IPv4 address, and requests an IANA Special = Purpose IPv4 address allocation (192.70.192.0/24) to allow this address = mapping to take place using a protocol-specific designated address block = in IPv4. >=20 > The authors are hopeful that this will not require any valuable = face-to-face WG time at IETF 82 and the WG's consideration of this = document can be undertaken entirely on the mailing list. >=20 > Regards, >=20 > xing >=20 >> -rw-rw-r-- 1 fred fred 34974 Sep 14 10:45=20 >> draft-ietf-v6ops-happy-eyeballs-04.txt >> -rw-rw-r-- 1 fred fred 26625 Sep 27 13:22=20 >> draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-04.txt >> -rw-rw-r-- 1 fred fred 25341 Oct 2 11:39=20 >> draft-jjmb-v6ops-comcast-ipv6-experiences-02.txt >> -rw-rw-r-- 1 fred fred 28127 Oct 6 14:13=20 >> draft-gashinsky-v6ops-v6nd-problems-00.txt >> -rw-rw-r-- 1 fred fred 45016 Oct 7 12:39 = draft-ietf-v6ops-6204bis-00.txt >> -rw-rw-r-- 1 fred fred 8877 Oct 10 09:00 = draft-ietf-v6ops-ipv6-discard-prefix-00.txt >> -rw-rw-r-- 1 fred fred 15656 Oct 12 20:38=20 >> draft-carpenter-v6ops-label-balance-00.txt >>=20 >> plus any new drafts that are posted. >>=20 >> Begin forwarded message: >>=20 >>> From: IETF Agenda >>> Date: October 13, 2011 2:13:10 PM PDT >>> To: Working Group Chairs Cc:irsg@irtf.org >>> Subject: 82nd IETF DRAFT Agenda >>>=20 >>> The DRAFT agenda is ready for viewing. Please note the cutoff date=20 >>> for requests to reschedule Working Group and BOF meetings is October = >>> 17, 2011 >>> 17:00 PT. The final agenda will be published on October 21, 2011. >>>=20 >>> https://datatracker.ietf.org/meeting/82/agenda.html >>> https://datatracker.ietf.org/meeting/82/agenda.txt >>>=20 >>> http://www.ietf.org/meeting/82/index.html >>>=20 >>>=20 >>> Thanks, >>> Wanda >>>=20 >>> Only 30 days until Taipei, 82nd IETF! >>> Online registration for the IETF meeting is at: >>> http://www.ietf.org/meeting/register.html >>>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >>=20 >=20 From cxc@xmu.edu.cn Thu Nov 17 05:06:15 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 210241F0CA9 for ; Thu, 17 Nov 2011 05:06:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.004 X-Spam-Level: * X-Spam-Status: No, score=1.004 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, FH_RELAY_NODNS=1.451, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9QRc+Lmgwowr for ; Thu, 17 Nov 2011 05:06:15 -0800 (PST) Received: from xmu.edu.cn (unknown [IPv6:2001:da8:e800:0:e61f:13ff:fe38:8310]) by ietfa.amsl.com (Postfix) with ESMTP id EFE3F1F0CA6 for ; Thu, 17 Nov 2011 05:06:04 -0800 (PST) Received: from JustinChenPC (unknown [210.34.8.198]) by app (Coremail) with SMTP id 0iL_+5DrsR7BA8VOAFpiAg--.58258S2; Thu, 17 Nov 2011 20:53:22 +0800 (CST) From: "Justin Chen" To: "'Fred Baker'" References: <20111013211312.B6C7421F8AFF@ietfa.amsl.com> <619C3B81-1CDC-4341-8180-EC8472864CC0@cisco.com> <4EA53FB7.6090603@cernet.edu.cn> <91B5BAD7-9C72-4619-8822-A52D3EFC4EBE@cisco.com> In-Reply-To: <91B5BAD7-9C72-4619-8822-A52D3EFC4EBE@cisco.com> Date: Thu, 17 Nov 2011 21:05:24 +0800 Message-ID: <000001cca529$92677e40$b7367ac0$@xmu.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHt0io9Yk+bWyYyqrC3oWqJ+cZnVwLqtxVLATtwLnYBB1qhzJVFQU8w Content-Language: zh-cn X-CM-TRANSID: 0iL_+5DrsR7BA8VOAFpiAg--.58258S2 X-Coremail-Antispam: 1UD129KBjvJXoWxWw1DtFWDuFW3tr43WrWUXFb_yoWrJF1rpa yUWa1rCrWkXwnagwn2qw1vyryYv3y7Aay8GF13tr9Fy398tFZ2yr4jkw1fZrWDuF4fGF1v qr4UCr18ur4fJ3DanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUU2Eb7IF0VCFI7km07C26c804VAKzcIF0wAYjxAI6xZILanIXVAF wwAYjsxI4VWxJwAYFVCjjxCrM7CY07I20VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM2k07c x0zVAaqwAawVCIc40E5I027xCE548m6r1DJr4UtwAqjxCEc2xF0cIa020Ex4CE44I27wAq jxCE34x0Y48IcwAqx4xG64xvF2IEw4CE5I8CrVC2j2WlYx0Ex4A2jsIE14v26r1j6r4UM4 x0Y48IcxkI7VAKI48JMxAIw28IcxkI7VAKI48JMxCIbVA2zIxYr2IEbsI20wCFI7vE0wC2 zVAF1VAY17CE14v26r1Y6r17MIIYrxkI7VAKI48JMs8CjcxG0xvEz27vcSsGvfC2KfnxnU UI43ZEXa7IUjLiSJUUUUU== X-CM-SenderInfo: hf0fq5lpxovvfxof0/ Cc: v6ops@ietf.org Subject: [v6ops] =?utf-8?b?562U5aSNOiAgRndkOiA4Mm5kIElFVEYgRFJBRlQgQWdl?= =?utf-8?q?nda?= X-BeenThere: v6ops@ietf.org X-Mailman-Version: 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, 17 Nov 2011 13:06:15 -0000 Hi all, I support draft-xli-v6ops-ivi-icmp-address-00.txt to be adopted as a WG = document in V6ops. Based on our experience, I think a special block of IPv4 address = representing non-IPv4 translatable address will be very useful for = trouble shooting in campus network.=20 Regards, Chen Xiaochou -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: Fred Baker [mailto:fred@cisco.com]=20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2011=E5=B9=B410=E6=9C=8824=E6=97=A5 20:24 =E6=94=B6=E4=BB=B6=E4=BA=BA: v6ops@ietf.org WG =E6=8A=84=E9=80=81: V6ops Chairs =E4=B8=BB=E9=A2=98: Re: [v6ops] Fwd: 82nd IETF DRAFT Agenda Looking for comments/support from the working group. On Oct 24, 2011, at 3:36 AM, Xing Li wrote: > Hi, Fred and All, >=20 > =E4=BA=8E 2011/10/14 5:52, Fred Baker =E5=86=99=E9=81=93: >> The initial version of the agenda has been posted. It places v6ops on = Wednesday and Friday mornings, a total of 4.5 hours. I personally am = satisfied with it, but if folks have issues I can pass them along. >>=20 >> I'll note that the deadline for -00 drafts is 24 October, and the = deadline for updated drafts is a week later. For discussion in the = working group meetings, I'm looking for a draft posted after 25 July, = with supporting email discussion on the list. >>=20 >> I'm looking for (and in some cases have seen) commentary on each of: >>=20 >> -rw-rw-r-- 1 fred fred 13796 Jul 25 23:59=20 >> draft-xli-v6ops-ivi-icmp-address-00.txt >=20 > I would like to request that the V6ops WG adopt = draft-xli-v6ops-ivi-icmp-address-00.txt as a WG adoption. >=20 > The draft describes the operational considerations of mapping ICMPv6 = packets through an RFC6145 gateway where the IPv6 address is not = directly translatable into an IPv4 address, and requests an IANA Special = Purpose IPv4 address allocation (192.70.192.0/24) to allow this address = mapping to take place using a protocol-specific designated address block = in IPv4. >=20 > The authors are hopeful that this will not require any valuable = face-to-face WG time at IETF 82 and the WG's consideration of this = document can be undertaken entirely on the mailing list. >=20 > Regards, >=20 > xing >=20 >> -rw-rw-r-- 1 fred fred 34974 Sep 14 10:45=20 >> draft-ietf-v6ops-happy-eyeballs-04.txt >> -rw-rw-r-- 1 fred fred 26625 Sep 27 13:22=20 >> draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-04.txt >> -rw-rw-r-- 1 fred fred 25341 Oct 2 11:39=20 >> draft-jjmb-v6ops-comcast-ipv6-experiences-02.txt >> -rw-rw-r-- 1 fred fred 28127 Oct 6 14:13=20 >> draft-gashinsky-v6ops-v6nd-problems-00.txt >> -rw-rw-r-- 1 fred fred 45016 Oct 7 12:39 = draft-ietf-v6ops-6204bis-00.txt >> -rw-rw-r-- 1 fred fred 8877 Oct 10 09:00 = draft-ietf-v6ops-ipv6-discard-prefix-00.txt >> -rw-rw-r-- 1 fred fred 15656 Oct 12 20:38=20 >> draft-carpenter-v6ops-label-balance-00.txt >>=20 >> plus any new drafts that are posted. >>=20 >> Begin forwarded message: >>=20 >>> From: IETF Agenda >>> Date: October 13, 2011 2:13:10 PM PDT >>> To: Working Group Chairs Cc:irsg@irtf.org >>> Subject: 82nd IETF DRAFT Agenda >>>=20 >>> The DRAFT agenda is ready for viewing. Please note the cutoff date=20 >>> for requests to reschedule Working Group and BOF meetings is October = >>> 17, 2011 >>> 17:00 PT. The final agenda will be published on October 21, 2011. >>>=20 >>> https://datatracker.ietf.org/meeting/82/agenda.html >>> https://datatracker.ietf.org/meeting/82/agenda.txt >>>=20 >>> http://www.ietf.org/meeting/82/index.html >>>=20 >>>=20 >>> Thanks, >>> Wanda >>>=20 >>> Only 30 days until Taipei, 82nd IETF! >>> Online registration for the IETF meeting is at: >>> http://www.ietf.org/meeting/register.html >>>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >>=20 >=20 From v6ops@globis.net Thu Nov 17 05:06:26 2011 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C973911E80A3 for ; Thu, 17 Nov 2011 05:06:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.098, 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 R6T3nG62f0A5 for ; Thu, 17 Nov 2011 05:06:25 -0800 (PST) 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 E654111E80ED for ; Thu, 17 Nov 2011 05:06:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id ED3408700E4; Thu, 17 Nov 2011 14:06:23 +0100 (CET) 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 x5EMSfOrfe4r; Thu, 17 Nov 2011 14:06:18 +0100 (CET) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 43A428700B9; Thu, 17 Nov 2011 14:06:18 +0100 (CET) Message-ID: <4EC506CA.3020006@globis.net> Date: Thu, 17 Nov 2011 14:06:18 +0100 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: Brian E Carpenter References: <20111115062859.14026.42405.idtracker@ietfa.amsl.com> <4EC2ABA8.4020303@globis.net> <4EC2FD24.1090303@gmail.com> <4EC37529.4070505@globis.net> <20111117013452.19F35179A55F@drugs.dv.isc.org> <4EC469E7.9010602@gmail.com> <20111117055040.E34FC179DAF9@drugs.dv.isc.org> <4EC4D7D1.8050601@globis.net> <4EC4EB86.80308@gmail.com> In-Reply-To: <4EC4EB86.80308@gmail.com> Content-Type: multipart/alternative; boundary="------------010106060200060400050709" Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 13:06:26 -0000 This is a multi-part message in MIME format. --------------010106060200060400050709 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Inline. Brian E Carpenter wrote: > Ray, > > On 2011-11-17 22:45, Ray Hunter wrote: > >> Agreed. Most multinationals I know are already LIRs. They can run BGP to >> the major sites with multiple ISPs and their own PI /32. That's the easy >> bit. >> >> But it isn't just about a few large sites and 2 ISP's. There's also the >> rest of the private corporate network covering 50+ countries + multiple >> (smaller) ISPs to consider. >> > > Exactly. The small number of biiig multinationals is not an issue. > > >> IMHO I have seen three use cases so far in production today in IPv4 that >> are not really covered in IPv6. To be frank, these current solutions >> seem mainly to be driven by commercial considerations rather than >> technical ones. So if a commercial solution could be found, there >> wouldn't be much resistance to change. Most problems are due to the >> return route, not the outbound one. >> >> 1. Home workers, remote branch offices, and SME's that need higher >> availability than a single consumer ISP link, but don't have the >> capability/desire/cash/ISP to run a multihomed BGP AS. Today they can >> use a simple outbound-only load-balancing box, or a specialist VPN box >> that provides 2 GRE/IPSec tunnels via 2 ISPs. The GRE/IPSec solution >> will obviously work in the future, but the load balancer won't. >> > > Multipath TCP would handle the load balancing issue (but not of course > for non-TCP traffic). Shim6 would handle failover for all types of flow. > But both of these need both ends to play, which makes deployment sticky. > > Sure. >> 2. Local Internet break out. Remote corporate site is still connected to >> the corporate network for business/production critical apps, but >> Internet traffic is gatewayed directly into the Public Internet at the >> local site for Internet centric apps like foobarnow.com. Today the local >> site Internet firewall/router can use NAT44 outbound: guaranteeing a >> return route direct to the local site. Most, but not all, Internet >> centric apps are web based, but that would mean installing a proxy on >> every site for IPv6. I see no solution so far for apps that are >> "NAT44-able" but "non-proxy-able" with IPv6. Negotiating ISP routing of >> a single /48 in country X from the PI /32 is unlikely to work in all >> cases. I guess these sites could just use PA space addresses, but then >> you have limited service availability, and potential renumbering issues. >> > > Why? If the local PA link goes down, you'd revert to a slower path > using an address under the PI prefix. > > In my experience when I was such a corporate user, I got renumbered whenever > I reconnected my ThinkPad. It was never an issue. > > The point is that the end node doesn't know which IPv6 source address to use for which application and when, because there's no signaling today. The idea in the draft to distribute an RFC3484 type policy from routers to end nodes should theoretically work in this case. However, the PA prefix could still be up (in RA) and still be valid in IA_PD, and the local ISP interface UP, but packet forwarding via the ISP link is down, meaning a very slow or incomplete takeover as the end node has no indication of upstream failure. One option would be to ensure that on ISP link failure, the site egress router could ensure that all leases and addresses from the PA prefix are flushed from the whole site. But there's no flushing mechanism today, only timer expiry. Or that a policy update can be pushed to all end nodes: not easy. It's also tricky to deploy in practice right now as end nodes are mobile between sites (your Thinkpad moves) and not all end nodes are managed by IT (it's your Thinkpad, not mine). So I suspect it'll be tough to write a universal RFC3484 policy to cover all end nodes and all cases. Or it might become hundreds of lines long. And it probably won't work for guests, contractors, or BYOD because of trust issues. Today you can force these failovers pretty quickly using object tracking to simply avoid using the NATted interface at the site router, without involving the end nodes at all. That's why I'm attracted to the "learn by trying" approach: to avoid direct policy interactions of routers and end nodes several hops away. So intermediate routers could inform end nodes about the characteristics of the available end-to-end paths. But end nodes provide the ultimate policy of which path to select per application. They also test the end to end path before using it, to avoid unhappy eyeballs. >> 3. Internet offload. Remote corporate site has a main link and an >> Internet connection. Local site router is connected to both and uses >> Policy Based Routing (PBR) to route down the appropriate link. A GRE >> tunnel carries the bulk traffic over the Internet to the regional >> corporate data centre, where it emerges from the tunnel and passes >> through the usual security controls onto the Public Internet. Return >> route to the GRE tunnel is guaranteed via NAT. Otherwise you'd need to >> run PBR on the DC firewall as the Internet tunnel and private corporate >> network are connected to different security zones on the firewall. PBR >> on firewalls doesn't exist so far AFAIK. >> > > Firewalls aren't routers, but they can have routers glued onto them. > > This is admittedly a corner case and little to do with the IETF standards. This is multi-interface firewall where the policies are linked to physical interface. Theoretically speaking "gluing" on a PBR function would work. But practically speaking, the PBR function has to be integrated within the same box as the firewall function, not bolted on the outside as an additional router. It's going to be large amounts of money to replace / change. > Brian > > >> In most cases there's multiple hops (and possibly security devices) >> between the end nodes and the point where the alternative paths split. >> >> >> Mark Andrews wrote: >> >>> >>> >>> I would expect multi-nationals to be able to work around these sort >>> of restrictions already. My primary focus is to make it work for >>> the home / small office. Bigger customers can usually make this >>> work today without automation. Homes and small offices can't because >>> them man power cost is too high to deal with the volume. >>> >>> That said I would welcome a solution that scales up to handle any >>> business that isn't a ISP. >>> >>> Mark >>> >>> >> --------------010106060200060400050709 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Inline.

Brian E Carpenter wrote: 
Ray,

On 2011-11-17 22:45, Ray Hunter wrote:
  
Agreed. Most multinationals I know are already LIRs. They can run BGP to
the major sites with multiple ISPs and their own PI /32. That's the easy
bit.

But it isn't just about a few large sites and 2 ISP's. There's also the
rest of the private corporate network covering 50+ countries + multiple
(smaller) ISPs to consider.
    

Exactly. The small number of biiig multinationals is not an issue.

  
IMHO I have seen three use cases so far in production today in IPv4 that
are not really covered in IPv6. To be frank, these current solutions
seem mainly to be driven by commercial considerations rather than
technical ones. So if a commercial solution could be found, there
wouldn't be much resistance to change. Most problems are due to the
return route, not the outbound one.

1. Home workers, remote branch offices, and SME's that need higher
availability than a single consumer ISP link, but don't have the
capability/desire/cash/ISP to run a multihomed BGP AS. Today they can
use a simple outbound-only load-balancing box, or a specialist VPN box
that provides 2 GRE/IPSec tunnels via 2 ISPs. The GRE/IPSec solution
will obviously work in the future, but the load balancer won't.
    

Multipath TCP would handle the load balancing issue (but not of course
for non-TCP traffic). Shim6 would handle failover for all types of flow.
But both of these need both ends to play, which makes deployment sticky.
Sure.

  

    
2. Local Internet break out. Remote corporate site is still connected to
the corporate network for business/production critical apps, but
Internet traffic is gatewayed directly into the Public Internet at the
local site for Internet centric apps like foobarnow.com. Today the local
site Internet firewall/router can use NAT44 outbound: guaranteeing a
return route direct to the local site. Most, but not all, Internet
centric apps are web based, but that would mean installing a proxy on
every site for IPv6. I see no solution so far for apps that are
"NAT44-able" but "non-proxy-able" with IPv6. Negotiating ISP routing of
a single /48 in country X from the PI /32 is unlikely to work in all
cases. I guess these sites could just use PA space addresses, but then
you have limited service availability, and potential renumbering issues.
    

  

  

Why? If the local PA link goes down, you'd revert to a slower path
using an address under the PI prefix.

In my experience when I was such a corporate user, I got renumbered whenever
I reconnected my ThinkPad. It was never an issue.

  



The point is that the end node doesn't know which IPv6 source address
to use for which application and when, because there's no signaling
today.



The idea in the draft to distribute an RFC3484 type policy from routers
to end nodes should theoretically work in this case. 



However, the PA prefix could
still be up (in RA) and still be valid in IA_PD,
and the local ISP interface UP, but packet forwarding via the ISP link
is down, meaning a very slow or incomplete takeover as the end node has
no indication of upstream failure. 



One option would be to ensure that on ISP link failure, the site egress
router could ensure that all leases and
addresses from the PA prefix are flushed from the whole site. But
there's no flushing mechanism today, only timer expiry. Or that a
policy update can be pushed to all end nodes: not easy.



It's also tricky to deploy in practice right now as end nodes are
mobile between sites (your Thinkpad moves) and not all end nodes are
managed by IT (it's your Thinkpad, not mine). So I suspect it'll be
tough to write a universal RFC3484 policy to cover all end nodes and
all cases. Or it might become hundreds of lines long. And it probably
won't work for guests, contractors, or BYOD because of trust issues.



Today you can force these failovers pretty quickly using object
tracking to simply avoid using the NATted interface at the site router,
without involving the end nodes at all.



That's why I'm attracted to the "learn by trying" approach: to avoid
direct policy interactions of routers and end nodes several hops away.
So intermediate routers could inform end nodes about the
characteristics of the available end-to-end paths. But end nodes
provide the ultimate policy of which path to select per application.
They also test the end to end path before using it, to avoid unhappy
eyeballs.



  

  

    
3. Internet offload. Remote corporate site has a main link and an
Internet connection. Local site router is connected to both and uses
Policy Based Routing (PBR) to route down the appropriate link. A GRE
tunnel carries the bulk traffic over the Internet to the regional
corporate data centre, where it emerges from the tunnel and passes
through the usual security controls onto the Public Internet. Return
route to the GRE tunnel is guaranteed via NAT. Otherwise you'd need to
run PBR on the DC firewall as the Internet tunnel and private corporate
network are connected to different security zones on the firewall. PBR
on firewalls doesn't exist so far AFAIK.
    

  

  

Firewalls aren't routers, but they can have routers glued onto them.

  



This is admittedly a corner case and little to do with the IETF
standards. This is multi-interface firewall where the policies are
linked to physical interface. Theoretically speaking "gluing" on a PBR
function would work. But practically speaking, the PBR function has to
be integrated within the same box as the firewall function, not bolted
on the outside as an additional router. It's going to be large amounts
of money to replace / change.





  
   Brian

  

  

    
In most cases there's multiple hops (and possibly security devices)
between the end nodes and the point where the alternative paths split.


Mark Andrews wrote:
    

    

      
<snip>

I would expect multi-nationals to be able to work around these sort
of restrictions already.  My primary focus is to make it work for
the home / small office.  Bigger customers can usually make this
work today without automation.  Homes and small offices can't because
them man power cost is too high to deal with the volume.

That said I would welcome a solution that scales up to handle any
business that isn't a ISP.

Mark
   
      

    

    
    

  








--------------010106060200060400050709--

From fred@cisco.com  Thu Nov 17 05:53:23 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40ECD21F9A4E for ; Thu, 17 Nov 2011 05:53:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -107.511
X-Spam-Level: 
X-Spam-Status: No, score=-107.511 tagged_above=-999 required=5 tests=[AWL=-0.912, 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 Mkuy8nNgMwq9 for ; Thu, 17 Nov 2011 05:53:22 -0800 (PST)
Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 2F89A21F9A4D for ; Thu, 17 Nov 2011 05:53:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2545; q=dns/txt; s=iport; t=1321538002; x=1322747602; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=1jYinR2Tozrm+Zpk8Oie2SkR2L2M3v2I1uqQlX+8uAs=; b=BPPnq42OkRdPXcSeWUpaumxb6rM5jtvlhqVMBsDzx5swko4UDCOvGHfO 4cDTEmUmyEyzi/NveJvntBHCrqv/bBs06lVuSvK4E1TtQhgVG+87N7+Qd JyJKH0yMYw8hHO0MzoMvhQk+IAjTFmfPqaXK/EZO/G1df3TjaG3MK30MK w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EADsRxU5Io8US/2dsb2JhbABCqX6BBYFyAQEBAwESASc/BQsLRlcGLgeHYJZvAZ5PiTRjBIgTjCKFO4xO
X-IronPort-AV: E=Sophos;i="4.69,527,1315180800";  d="scan'208";a="3337542"
Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-3.cisco.com with ESMTP; 17 Nov 2011 13:53:20 +0000
Received: from dhcp-4466.meeting.ietf.org (hkidc-vpn-client-233-100.cisco.com [10.75.233.100]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pAHDrIZg029480; Thu, 17 Nov 2011 13:53:19 GMT
Received: from [127.0.0.1] by dhcp-4466.meeting.ietf.org (PGP Universal service); Thu, 17 Nov 2011 21:53:19 +0800
X-PGP-Universal: processed; by dhcp-4466.meeting.ietf.org on Thu, 17 Nov 2011 21:53:19 +0800
Mime-Version: 1.0 (Apple Message framework v1084)
From: Fred Baker 
In-Reply-To: <4EC4EDC9.1080003@gmail.com>
Date: Thu, 17 Nov 2011 21:53:06 +0800
Message-Id: <6A642CDE-B5B7-4717-B8C8-B3F4EDC8043F@cisco.com>
References: <754008F3-6B2B-4DD1-B72B-EDE17A4FBF80@cisco.com> <4EC4EDC9.1080003@gmail.com>
To: Brian E Carpenter 
X-Mailer: Apple Mail (2.1084)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Cc: "v6ops@ietf.org WG" , draft-liu-v6ops-ula-usage-analysis@tools.ietf.org
Subject: Re: [v6ops] Major use cases for ULA
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 17 Nov 2011 13:53:23 -0000

On Nov 17, 2011, at 7:19 PM, Brian E Carpenter wrote:

> Fred,
>=20
>> First, as Jari noted from the mike, there is no case in which a ULA =
is required.
>=20
> Then how do we assign a prefix for a totally isolated network that =
includes
> at least two subnets?

You could probably completely make something up. Given Jari's assertion =
that one could use an expired prefix, I suspect he might support that. =
As long as it remains totally isolated, you're in your own little world.

That said, you'll note that you just described the first case for the =
use of a ULA. I think even Jari might prefer a ULA to bits pulled out of =
a dark place.

> I realise that no such network will exist for ever without getting =
connected
> to the Internet, but during the time that it does exist in isolation, =
ULA seems
> a better solution than having people make up their own unicast prefix =
or
> applying to ARIN for a PI prefix.
>=20
> Beyond that I'm getting too sleepy to work through your analysis, but =
I think
> Bing's model of documenting the full range of use cases in a neutral =
manner
> is a good first step. The second step might well be guidelines about =
which
> ones are viable and which ones are harmful.

The concern I heard in today's discussion fell broadly into two =
categories.=20

Part was the usual technology religion - "We MUST preclude NAT", "We =
MUST preclude ULA in any case", and "We MUST assume that because OUR =
network does/needs/experiences , All Networks Are the Same, and we =
will filibuster at the mike to prevent any other view from being =
expressed, because 'That's Just Stupid'." Once upon a time, differences =
in viewpoint were accepted in the IETF as normal, and there was a =
certain professionalism that grudgingly accepted that the other guy =
might have a point in a case the speaker had not considered. I'm not =
sure we're that way any more.

The other concern, one I thought was valid, was that many of the use =
cases described in the slides (if not the draft) were in fact incorrect. =
A car and an airplane were listed, for example, as networks that don't =
connect to the Internet. In both cases, we have commercial instances of =
them connecting to the Internet.

My suggestion to Bing is to step away from the dubious examples, and =
simply describe networks that don't connect to the Internet, networks =
that do but..., and so on.=20




> As Nathan's comment shows, opinions may vary.
>=20
> Regards
>   Brian
>=20


From brian.e.carpenter@gmail.com  Thu Nov 17 06:01:01 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1C5721F993B for ; Thu, 17 Nov 2011 06:01:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.333
X-Spam-Level: 
X-Spam-Status: No, score=-101.333 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_RECV_SPAM_DOMN0b=1.666, 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 HaDfB5b4qc1O for ; Thu, 17 Nov 2011 06:00:57 -0800 (PST)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id E07A921F9937 for ; Thu, 17 Nov 2011 06:00:56 -0800 (PST)
Received: by ggnr5 with SMTP id r5so1265858ggn.31 for ; Thu, 17 Nov 2011 06:00:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=AXO5XNSFWiJnY1wkYcce+D0wgU2fgTkgZZq+/0fo+dw=; b=fXjppX51ZT0l6JYeOwy1RsdAjZv55m1Wzc8OL2ie9KV5X3nADNF0uU5vKiLuLZL+oi DzAEZKIDx7kbWS1XOSGHZ0+gGgUZlaGNg4jgBm4bR0tKdnp0OJEC5HWja5VU3+yYsPtS bMrnDJSmjEDCkIe3odC7Nro28DM6fcGT7xqA8=
Received: by 10.236.161.65 with SMTP id v41mr9699245yhk.42.1321538450756; Thu, 17 Nov 2011 06:00:50 -0800 (PST)
Received: from [192.168.0.45] (61-217-193-77.dynamic.hinet.net. [61.217.193.77]) by mx.google.com with ESMTPS id y58sm6073602yhi.17.2011.11.17.06.00.47 (version=SSLv3 cipher=OTHER); Thu, 17 Nov 2011 06:00:49 -0800 (PST)
Message-ID: <4EC5137F.7000706@gmail.com>
Date: Fri, 18 Nov 2011 03:00:31 +1300
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: "Hemant Singh (shemant)" 
References: <754008F3-6B2B-4DD1-B72B-EDE17A4FBF80@cisco.com> <4EC4EDC9.1080003@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3035447F3@XMB-RCD-109.cisco.com>
In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3035447F3@XMB-RCD-109.cisco.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: v6ops@ietf.org, draft-liu-v6ops-ula-usage-analysis@tools.ietf.org
Subject: Re: [v6ops] Major use cases for ULA
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 17 Nov 2011 14:01:01 -0000

Hemant,

> The ULA document in RFC 4193 already specifies properties of the ULA
> that make it relatively clear to a reader where the ULA can be used.
> Thus why do we need a new document to document what the ULA can be used
> for?

IMHO, because 4193 only makes it *relatively* clear, and there is news
coming back from customer land that people designing their IPv6
addressing plans do not find it sufficiently clear.

Regards
   Brian

On 2011-11-18 01:37, Hemant Singh (shemant) wrote:
> Note as of circa 2007-2008, in v6ops discussion on the IPv6 CPE router
> draft we clearly said the ULA in the home LAN serves as a stable prefix
> for the computer at home to print to the printer at home with the SP
> global link has gone down.  The ULA has already been specified in RFC
> 6204.  Thus at least no new document is needed to outline such a use
> which has been already carried over to homenet.
> 
> The other use case of the ULA was also discussed around the same time as
> above to configure the CPE router using a URL.  It was distinctly noted
> that some web browsers will not serve a URL with a link-local address.
> Then an IPv6 global is needed and the ULA has global scope. Soon as the
> CPE router is powered up the ULA can be used to access the device over
> the web when the user has not even connected the CPE WAN to the Internet
> SP.  
> 
> The ULA document in RFC 4193 already specifies properties of the ULA
> that make it relatively clear to a reader where the ULA can be used.
> Thus why do we need a new document to document what the ULA can be used
> for?  
> 
> Hemant
> 
> -----Original Message-----
> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
> Of Brian E Carpenter
> Sent: Thursday, November 17, 2011 7:20 PM
> To: Fred Baker (fred)
> Cc: v6ops@ietf.org WG; draft-liu-v6ops-ula-usage-analysis@tools.ietf.org
> Subject: Re: [v6ops] Major use cases for ULA
> 
> Fred,
> 
>> First, as Jari noted from the mike, there is no case in which a ULA is
> required.
> 
> Then how do we assign a prefix for a totally isolated network that
> includes
> at least two subnets?
> 
> I realise that no such network will exist for ever without getting
> connected
> to the Internet, but during the time that it does exist in isolation,
> ULA seems
> a better solution than having people make up their own unicast prefix or
> applying to ARIN for a PI prefix.
> 
> Beyond that I'm getting too sleepy to work through your analysis, but I
> think
> Bing's model of documenting the full range of use cases in a neutral
> manner
> is a good first step. The second step might well be guidelines about
> which
> ones are viable and which ones are harmful.
> 
> As Nathan's comment shows, opinions may vary.
> 
> Regards
>    Brian
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
> 

From fred@cisco.com  Thu Nov 17 06:07:17 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF9211E80E3 for ; Thu, 17 Nov 2011 06:07:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -107.489
X-Spam-Level: 
X-Spam-Status: No, score=-107.489 tagged_above=-999 required=5 tests=[AWL=-0.890, 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 T6JcphBvcnkv for ; Thu, 17 Nov 2011 06:07:13 -0800 (PST)
Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id D8ADD11E80D2 for ; Thu, 17 Nov 2011 06:07:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=731; q=dns/txt; s=iport; t=1321538833; x=1322748433; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=49UtWr4jKZgE2Ma6RS923k/fDcyNFMXENDlk8vleUxs=; b=fguvvWZvraUJLtYhnVsF/L0sbZ63MCjFok5nCxJOlJ1NWPFWfdLclUcD N1U8XZlFFhk1cJe2Ar3w/9H+TXhMpQV0IfHH5khSyyLr26g+cSwxijf7t lNTO/RRuCH+HuQZxVxHDT8J/fUIXH4GK2ueOCMLMY5rfnyXMgHaQwpNqV A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAKwUxU5Io8UR/2dsb2JhbABCqX6BBYFyAQEBAwESASc9AgULC0ZXBhMJGYdgCJZ+AZ5PiTRjBIgTjCKFO4URhz0
X-IronPort-AV: E=Sophos;i="4.69,527,1315180800";  d="scan'208";a="3339809"
Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-3.cisco.com with ESMTP; 17 Nov 2011 14:07:05 +0000
Received: from dhcp-4466.meeting.ietf.org (hkidc-vpn-client-233-100.cisco.com [10.75.233.100]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pAHE73m7014280; Thu, 17 Nov 2011 14:07:03 GMT
Received: from [127.0.0.1] by dhcp-4466.meeting.ietf.org (PGP Universal service); Thu, 17 Nov 2011 22:07:04 +0800
X-PGP-Universal: processed; by dhcp-4466.meeting.ietf.org on Thu, 17 Nov 2011 22:07:04 +0800
Mime-Version: 1.0 (Apple Message framework v1084)
From: Fred Baker 
In-Reply-To: <20111115062859.14026.74743.idtracker@ietfa.amsl.com>
Date: Thu, 17 Nov 2011 22:06:52 +0800
Message-Id: 
References: <20111115062859.14026.74743.idtracker@ietfa.amsl.com>
To: "v6ops@ietf.org WG" 
X-Mailer: Apple Mail (2.1084)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Cc: Pete Resnick , draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat@tools.ietf.org, "ietfdbh@comcast.net Harrington" , Wesley Eddy 
Subject: Re: [v6ops] New Version Notification - draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-03.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Nov 2011 14:07:17 -0000

Folks:

Please review http://tinyurl.com/7gw45ma and comment. In view of a US =
holiday next week, I'll give you through 2 December. The changes have =
been made in response to IESG "Discuss" comments. The question is =
whether the working group still agrees with the draft.

Fred

On Nov 15, 2011, at 2:28 PM, Internet-Drafts@ietf.org wrote:

> New version (-03) has been submitted for =
draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-03.txt.
> =
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv6-multihoming-with=
out-ipv6nat-03.txt
>=20
>=20
> Diff from previous version:
> =
http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-ipv6-multihoming-wit=
hout-ipv6nat-03
>=20
> IETF Secretariat.


From d.sturek@att.net  Thu Nov 17 06:25:15 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D245111E813F for ; Thu, 17 Nov 2011 06:25:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.524
X-Spam-Level: 
X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Od9eHPF6ocGN for ; Thu, 17 Nov 2011 06:25:14 -0800 (PST)
Received: from nm24.access.bullet.mail.mud.yahoo.com (nm24.access.bullet.mail.mud.yahoo.com [66.94.237.89]) by ietfa.amsl.com (Postfix) with SMTP id 5045A11E8125 for ; Thu, 17 Nov 2011 06:24:51 -0800 (PST)
Received: from [66.94.237.192] by nm24.access.bullet.mail.mud.yahoo.com with NNFMP; 17 Nov 2011 14:24:48 -0000
Received: from [66.94.237.121] by tm3.access.bullet.mail.mud.yahoo.com with NNFMP; 17 Nov 2011 14:24:48 -0000
Received: from [127.0.0.1] by omp1026.access.mail.mud.yahoo.com with NNFMP; 17 Nov 2011 14:24:48 -0000
X-Yahoo-Newman-Id: 398917.23090.bm@omp1026.access.mail.mud.yahoo.com
Received: (qmail 35990 invoked from network); 17 Nov 2011 14:24:48 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1321539888; bh=phrK57y82uv6kkvE1gAggk+WVjx1OtRNMJrJP29TO7w=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=E/fxvRIWKoaoU1GgOQ4dMpHzhWm8NSv38HTPKQXKC2xkmMFCmTPvRKNq2nBtMhdx+DZuDOdtgFmAu1LZtdnJTgkEUjpsrk3A+zUhuSsnQXNYGsGjUTdADREHYJ+BPk0fV6Jv2TO7KT3vZaenIYEU6EB+lNK5p7iOg30Ht5HZN6A=
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: 9I4Ihm4VM1m.geh8YgzujF8Lo4GS3mmyc9nogFT1jx8MXJl Ys3DnoxNyLmnk7.yVi8LoyXwRNWNnzgtv9lFcfRj2Rm7aL4avfCw_AL5954c sY5Y4hhw7KQvlPaBfPAYInrx37K1PTMxw7hckdENUNTU7ugc6e4Ggmhzljbw ghqScDb.bcPJaBIRv0YfMd0ARJ2OrSQFrh9fKL4rCJ6jY_zmTV2uKrA94K7H JcSb2dUx.jeSzC315JeabYjJnCAUff7q889HwBwz1hFnjONq.TjQkZduL1zP ds9f7OMC.s_S6rWBz2xocTrL9FHdsLbWqXwJwCV.3w79pMeRualHuqDYXsYg 3rHFsqwQEdr0S48_5NMjKmuVT2yA0NLYAyPLlRsF1o5Fj8XTmFL7eG_FHG0K V8uKOD2jeyy92Hulaz2e0lfnhlLnqp5dvB3dJBA--
X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo-
Received: from [192.168.0.196] (d.sturek@69.105.138.6 with login) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 17 Nov 2011 06:24:47 -0800 PST
User-Agent: Microsoft-MacOutlook/14.13.0.110805
Date: Thu, 17 Nov 2011 06:24:37 -0800
From: Don Sturek 
To: Anders Brandt , Fred Baker , "draft-liu-v6ops-ula-usage-analysis@tools.ietf.org" 
Message-ID: 
Thread-Topic: [homenet] [v6ops] Major use cases for ULA
In-Reply-To: <03F31C213F2C6941BFDDBB4336E9E6CD0AB40668@cph-ex1>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: "v6ops@ietf.org WG" , "homenet@ietf.org" 
Subject: Re: [v6ops] [homenet]  Major use cases for ULA
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 17 Nov 2011 14:25:15 -0000

Hi Anders,

+1 on what you wrote.  Here is another reason that ULAs are needed:
1)  If globals were used on the sub nets in your example, there would be a
dependence on the ISP serving the prefix that is unwanted for
communication within the home (eg, on/off for lighting within the home).
2)  For technologies like IEEE 802.15.4, link locals will not work in the
multi subnet scenario below.

It would also be nice within Homenet if we could provide an informational
draft providing guidance to the application development community around
using the proper scoped address type (ie, only use globals where you
really need global addressing, use ULAs for applications which are
designed to communicate within the home and use link locals where you are
sure the device you are trying to communicate with is on the same link as
the sender)

Don




On 11/17/11 2:57 AM, "Anders Brandt" 
wrote:

>May I suggest variant 1b) :
>
>A home control installation with some powerline devices and some wireless
>devices each part of a lighting control system that MUST ALWAYS work.
>Both subnets are installed in autonomous fashion by two different
>technicians. Later, their border routers are interconnected via the
>homenet backbone.
>We may argue if a ULA prefix is needed in the homenet backbone but both
>of the home control networks need ULA addresses
>
>A: because the devices need stable addresses so that they know where to
>send On/Off commands to the other subnet without depending on DNS
>servers, etc.
>
>B: because there is no infrastructure to coordinate the assignment of
>prefixes in the two home control subnets
>
>C: because LLNs often do use coordinated assignment of short link-layer
>addresses to get shorter frames and to improve header compression.
>    These short link-layer would often lead to duplicate IPv6 addresses
>if in the same subnet.
>
>Thanks,
>  Anders Brandt
>
>________________________________________
>From: v6ops-bounces@ietf.org [v6ops-bounces@ietf.org] on behalf of Fred
>Baker [fred@cisco.com]
>Sent: Thursday, November 17, 2011 11:37
>To: draft-liu-v6ops-ula-usage-analysis@tools.ietf.org
>Cc: v6ops@ietf.org WG
>Subject: [v6ops] Major use cases for ULA
>
>Trying to summarize at least my thoughts from the discussion this
>afternoon. Working group, tell me what I'm missing in this.
>
>First, as Jari noted from the mike, there is no case in which a ULA is
>required. If one is willing to only have connectivity in the link-local
>environment, one can communicate between two directly connected systems
>using a link-local address. If one has in the past had the use of a
>prefix allocated by someone else, but are right now not connected to the
>Internet, there is no harm in using that prefix even if it is expired.
>Reason: there will be no confusion. As soon as one reconnects, the
>expiration of the prefix needs to take effect, however.
>
>To my mind, there are three valid uses of a ULA. The choice of use cases
>center on the word "local".
>
>1) if one is in a network that does not have service from someone that
>will allocate it a prefix and wants to either use addresses that are not
>link-local or addresses that will allow for routing, a ULA provides a way
>to generate a prefix for the purpose. One example of such an environment
>is a Smart Grid HAN in a home that doesn't have an ISP. To me, this is a
>textbook case for the use of a ULA.
>
>2) if one is in a network that DOES have service from someone that will
>allocate it a prefix but wants to use addresses that are not in that
>prefix and are not routed anywhere else, a ULA can provide such a prefix.
>There are a number of possible examples.
>
>At Cisco, to pick one, we have a number of systems with names like
>http://wwwin.cisco.com - systems that offer no services outside Cisco but
>provide some interior service. There are at least two ways to implement
>that policy. One obvious one would be to put some ACL in the
>routers/firewalls at the edge of the network that drop traffic to or from
>those addresses. Another, which I would only want to implement in the
>presence of that firewall ACL, would be to not advertise the names
>outside the company in DNS (probably by implementing a split DNS). A
>third would be to give them ULA addresses, which are not advertised
>outside the company and are therefore something folks outside can't route
>to.
>
>Another example is the one I mentioned in RFC 6296; if you choose to use
>such a translator, you're going to need an interior prefix. That could be
>ULA or global. If it is global and you decide to change away from that
>carrier, you will have to renumber the network. If you find that scary,
>you might choose a ULA as your internal prefix.
>
>The key point is not "6296", nor is it "internal-only policy". It's "In
>my addressing plan, I want to use a *different* prefix that is not routed
>outside". If you have that policy, one of the options (and not the only
>option) would be to use a ULA.
>
>3) If you have a special routing scenario, of which
>draft-baker-v6ops-b2b-private-routing is an example, for various reasons
>you might want to have routing that you control and is separate from
>other routing. In the b2b case, even though two companies each have at
>least one ISP, they might choose to ALSO use direct connectivity that
>only connects stated machines, such as a silicon foundry with client
>engineers that use it. A ULA provides a simple way to obtain such a
>prefix that would be used in accordance with an agreement between the
>parties.
>
>
>
>To my mind, the renumbering scenario is a red herring. Thomas Narten
>wanted desperately for me to put it into RFC 4192 as "A ULA could help
>when renumbering a network". However, it doesn't actually do so.
>
>Case 1) suppose I am now using prefix 2001:dba:1::/48 and want to change
>to 2001:dba:2:8000::/49. Suppose that I am offering a service (web,
>email, whatever) outside of my network. What RFC 4192 suggests is
>bringing up the two prefixes in parallel (eg, I am now using both
>2001:dba:1::/48 and 2001:dba:2:8000::/49 throughout my network), and then
>take the old one down. The effect: during some part of the procedure, my
>external services have first one address, then two addresses, and finally
>one, but the one is the new one. I completely changed my address space,
>but my service never went down.
>
>Case 2) suppose I am now using prefix 2001:dba:1::/48 and want to change
>to 2001:dba:2:8000::/49. Suppose that I am offering a service (web,
>email, whatever) outside of my network. What the ULA advocates suggest
>that I have a ULA up in parallel, either all the time or brought up for
>the purpose. I am in effect now using 2001:dba:1::/48 and the ULA. I now
>take down 2001:dba:1::/48, and either simultaneously or subsequently
>bring up 2001:dba:2:8000::/49. If I do the two sequentially, I have an
>interval in which my services are only reachable via the ULA; if I change
>them at the same time, the ULA allows me to maintain control of my
>network (my network management system and other internal uses can use it
>to access equipment and applications within my network), but the
>disrupted routing makes my services unavailable in either global prefix
>for some period of time. The effect: during some part of the procedure,
>the various systems in my network might have one, two, or three addres
> ses, but during any period in which only the ULA has stable routing, my
>services are down as far as any external user is concerned.
>
>Hence, a ULA is helpful for folks within my own network, but does not
>help keep my externally-facing services running. To my small mind, that
>makes a ULA a nice fallback in case something gets screwed up, but it is
>not a renumbering solution. It fails to prevent a service outage during
>renumbering.
>_______________________________________________
>v6ops mailing list
>v6ops@ietf.org
>https://www.ietf.org/mailman/listinfo/v6ops
>_______________________________________________
>homenet mailing list
>homenet@ietf.org
>https://www.ietf.org/mailman/listinfo/homenet



From teco@inf-net.nl  Thu Nov 17 06:28:58 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BF7011E8151 for ; Thu, 17 Nov 2011 06:28:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.377
X-Spam-Level: 
X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 N4lLb1VRFwx4 for ; Thu, 17 Nov 2011 06:28:57 -0800 (PST)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5B20E11E8125 for ; Thu, 17 Nov 2011 06:28:57 -0800 (PST)
Received: by wyf28 with SMTP id 28so2356085wyf.31 for ; Thu, 17 Nov 2011 06:28:56 -0800 (PST)
MIME-Version: 1.0
Received: by 10.227.205.135 with SMTP id fq7mr11593738wbb.19.1321540136492; Thu, 17 Nov 2011 06:28:56 -0800 (PST)
Received: by 10.227.42.73 with HTTP; Thu, 17 Nov 2011 06:28:56 -0800 (PST)
In-Reply-To: <754008F3-6B2B-4DD1-B72B-EDE17A4FBF80@cisco.com>
References: <754008F3-6B2B-4DD1-B72B-EDE17A4FBF80@cisco.com>
Date: Thu, 17 Nov 2011 15:28:56 +0100
Message-ID: 
From: Teco Boot 
To: Fred Baker 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "v6ops@ietf.org WG" , draft-liu-v6ops-ula-usage-analysis@tools.ietf.org
Subject: Re: [v6ops] Major use cases for ULA
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 17 Nov 2011 14:28:58 -0000

Another practical ULA usage: a MIF case. An organization uses ULA for
inner communication and PI/PA for connections with external hosts on
the Internet. Own hosts on the Internet set up VPN tunnels for
connection with own internal hosts. On the VPN clients, the VPN tunnel
has an ULA address. A FC00::/7 route points to the VPN server. Easy to
understand, configure and troubleshoot.

With PI, advantage is less than PA, or near to zero.

Teco

2011/11/17 Fred Baker :
> Trying to summarize at least my thoughts from the discussion this afterno=
on. Working group, tell me what I'm missing in this.
>
> First, as Jari noted from the mike, there is no case in which a ULA is re=
quired. If one is willing to only have connectivity in the link-local envir=
onment, one can communicate between two directly connected systems using a =
link-local address. If one has in the past had the use of a prefix allocate=
d by someone else, but are right now not connected to the Internet, there i=
s no harm in using that prefix even if it is expired. Reason: there will be=
 no confusion. As soon as one reconnects, the expiration of the prefix need=
s to take effect, however.
>
> To my mind, there are three valid uses of a ULA. The choice of use cases =
center on the word "local".
>
> 1) if one is in a network that does not have service from someone that wi=
ll allocate it a prefix and wants to either use addresses that are not link=
-local or addresses that will allow for routing, a ULA provides a way to ge=
nerate a prefix for the purpose. One example of such an environment is a Sm=
art Grid HAN in a home that doesn't have an ISP. To me, this is a textbook =
case for the use of a ULA.
>
> 2) if one is in a network that DOES have service from someone that will a=
llocate it a prefix but wants to use addresses that are not in that prefix =
and are not routed anywhere else, a ULA can provide such a prefix. There ar=
e a number of possible examples.
>
> At Cisco, to pick one, we have a number of systems with names like http:/=
/wwwin.cisco.com - systems that offer no services outside Cisco but provide=
 some interior service. There are at least two ways to implement that polic=
y. One obvious one would be to put some ACL in the routers/firewalls at the=
 edge of the network that drop traffic to or from those addresses. Another,=
 which I would only want to implement in the presence of that firewall ACL,=
 would be to not advertise the names outside the company in DNS (probably b=
y implementing a split DNS). A third would be to give them ULA addresses, w=
hich are not advertised outside the company and are therefore something fol=
ks outside can't route to.
>
> Another example is the one I mentioned in RFC 6296; if you choose to use =
such a translator, you're going to need an interior prefix. That could be U=
LA or global. If it is global and you decide to change away from that carri=
er, you will have to renumber the network. If you find that scary, you migh=
t choose a ULA as your internal prefix.
>
> The key point is not "6296", nor is it "internal-only policy". It's "In m=
y addressing plan, I want to use a *different* prefix that is not routed ou=
tside". If you have that policy, one of the options (and not the only optio=
n) would be to use a ULA.
>
> 3) If you have a special routing scenario, of which draft-baker-v6ops-b2b=
-private-routing is an example, for various reasons you might want to have =
routing that you control and is separate from other routing. In the b2b cas=
e, even though two companies each have at least one ISP, they might choose =
to ALSO use direct connectivity that only connects stated machines, such as=
 a silicon foundry with client engineers that use it. A ULA provides a simp=
le way to obtain such a prefix that would be used in accordance with an agr=
eement between the parties.
>
>
>
> To my mind, the renumbering scenario is a red herring. Thomas Narten want=
ed desperately for me to put it into RFC 4192 as "A ULA could help when ren=
umbering a network". However, it doesn't actually do so.
>
> Case 1) suppose I am now using prefix 2001:dba:1::/48 and want to change =
to 2001:dba:2:8000::/49. Suppose that I am offering a service (web, email, =
whatever) outside of my network. What RFC 4192 suggests is bringing up the =
two prefixes in parallel (eg, I am now using both 2001:dba:1::/48 and 2001:=
dba:2:8000::/49 throughout my network), and then take the old one down. The=
 effect: during some part of the procedure, my external services have first=
 one address, then two addresses, and finally one, but the one is the new o=
ne. I completely changed my address space, but my service never went down.
>
> Case 2) suppose I am now using prefix 2001:dba:1::/48 and want to change =
to 2001:dba:2:8000::/49. Suppose that I am offering a service (web, email, =
whatever) outside of my network. What the ULA advocates suggest that I have=
 a ULA up in parallel, either all the time or brought up for the purpose. I=
 am in effect now using 2001:dba:1::/48 and the ULA. I now take down 2001:d=
ba:1::/48, and either simultaneously or subsequently bring up 2001:dba:2:80=
00::/49. If I do the two sequentially, I have an interval in which my servi=
ces are only reachable via the ULA; if I change them at the same time, the =
ULA allows me to maintain control of my network (my network management syst=
em and other internal uses can use it to access equipment and applications =
within my network), but the disrupted routing makes my services unavailable=
 in either global prefix for some period of time. The effect: during some p=
art of the procedure, the various systems in my network might have one, two=
, or three addres
> =A0ses, but during any period in which only the ULA has stable routing, m=
y services are down as far as any external user is concerned.
>
> Hence, a ULA is helpful for folks within my own network, but does not hel=
p keep my externally-facing services running. To my small mind, that makes =
a ULA a nice fallback in case something gets screwed up, but it is not a re=
numbering solution. It fails to prevent a service outage during renumbering=
.
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>

From tomasz.mrugalski@gmail.com  Thu Nov 17 06:36:32 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 738BB11E8168 for ; Thu, 17 Nov 2011 06:36:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.199
X-Spam-Level: 
X-Spam-Status: No, score=-3.199 tagged_above=-999 required=5 tests=[AWL=-0.200, 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 tTN7LSAdrJFC for ; Thu, 17 Nov 2011 06:36:32 -0800 (PST)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7285C11E8138 for ; Thu, 17 Nov 2011 06:36:23 -0800 (PST)
Received: by ggnr5 with SMTP id r5so1321284ggn.31 for ; Thu, 17 Nov 2011 06:36:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type:content-transfer-encoding; bh=a/NfReNCJ4jH7VC+mYwNfgvvQAy/5gJR0MUT5yO7VW8=; b=JRSeGoMQsxdy5+S9RbjT0BfRpVaI9/3wHTwt1v4zgrvwffCUV0yE7DRKxk6HoXRGlA fd9bV911X2gMlXecwB/8vKo78th9moKxtjBaZAcSgrYXVqzBDjHTiy6k4tVxibvEmExK A7sNjx9w3JZUfuxIQhEcUfT/WXz1zMRalFpWw=
Received: by 10.236.181.164 with SMTP id l24mr10028182yhm.22.1321540583077; Thu, 17 Nov 2011 06:36:23 -0800 (PST)
Received: from dhcp-41d0.meeting.ietf.org ([2001:df8:0:64:de2b:61ff:fee5:409c]) by mx.google.com with ESMTPS id v5sm96595000anf.3.2011.11.17.06.36.21 (version=SSLv3 cipher=OTHER); Thu, 17 Nov 2011 06:36:22 -0800 (PST)
Message-ID: <4EC51BE3.3050106@gmail.com>
Date: Thu, 17 Nov 2011 22:36:19 +0800
From: Tomek Mrugalski 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: v6ops@ietf.org
X-Enigmail-Version: 1.3.3
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: [v6ops] Discussion on feasibility of route configuration over DHCPv6
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 17 Nov 2011 14:36:32 -0000

Hi,
Everyone's favourite topic is back. There is pretty good chance that
current discussion will lead to either publication of
draft-ietf-mif-dhcpv6-route-option or its abandonment.

If you care about this topic, you are encouraged to read and post in:

Why we need route option thread:
http://www.ietf.org/mail-archive/web/mif/current/msg01431.html

Why we should drop route option thread:
http://www.ietf.org/mail-archive/web/mif/current/msg01432.html

There are questions raised if MIF is the best place for this option, but
since it is adopted there, MIF list seems like a reasonable place to
discuss its faith. There are at least 5 (DHC, MIF, HOMENET, V6OPS, 6MAN)
WGs that may be interested in this. There may be others. I consider
cross-posting to 5 mailing lists as highly inappropriate.

Similar posts as this will be sent to DHC, HOMENET, V6OPS and 6MAN shortly.

Cheers,
Tomek Mrugalski
ISC


From cb.list6@gmail.com  Thu Nov 17 07:58:49 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F8F71F0C4F for ; Thu, 17 Nov 2011 07:58:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.811
X-Spam-Level: 
X-Spam-Status: No, score=-2.811 tagged_above=-999 required=5 tests=[AWL=0.187,  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 r9+UY2zSYayS for ; Thu, 17 Nov 2011 07:58:49 -0800 (PST)
Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) by ietfa.amsl.com (Postfix) with ESMTP id 039251F0C47 for ; Thu, 17 Nov 2011 07:58:48 -0800 (PST)
Received: by pzk5 with SMTP id 5so2528212pzk.9 for ; Thu, 17 Nov 2011 07:58:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qgY3BNnnBcO3RM2MtuG+RK593zJNfR0h0sxcHYHt/QU=; b=YHC7XyPioVTOlakbktt99JWJ42xA5MQaYF2no6oQW5OH5JcydfTczVEqQZfiLcaek1 VVINXTfEiLj94PV+3ZXsw2dbVnCYPPfyDmZe+jq7OdOemLZlGC+EYzJ3OW/9yxX4TzKH UG//zP5TDp3uBomspr9fPoVlAgsKtDvt0U84g=
MIME-Version: 1.0
Received: by 10.68.73.40 with SMTP id i8mr164302pbv.45.1321545527490; Thu, 17 Nov 2011 07:58:47 -0800 (PST)
Received: by 10.143.7.1 with HTTP; Thu, 17 Nov 2011 07:58:47 -0800 (PST)
Received: by 10.143.7.1 with HTTP; Thu, 17 Nov 2011 07:58:47 -0800 (PST)
In-Reply-To: <4EC4EDC9.1080003@gmail.com>
References: <754008F3-6B2B-4DD1-B72B-EDE17A4FBF80@cisco.com> <4EC4EDC9.1080003@gmail.com>
Date: Thu, 17 Nov 2011 07:58:47 -0800
Message-ID: 
From: Cameron Byrne 
To: Brian E Carpenter 
Content-Type: multipart/alternative; boundary=f46d04170701b8785604b1f04b1f
Cc: "v6ops@ietf.org WG" , draft-liu-v6ops-ula-usage-analysis@tools.ietf.org
Subject: Re: [v6ops] Major use cases for ULA
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 17 Nov 2011 15:58:49 -0000

--f46d04170701b8785604b1f04b1f
Content-Type: text/plain; charset=ISO-8859-1

On Nov 17, 2011 3:19 AM, "Brian E Carpenter" 
wrote:
>
> Fred,
>
> > First, as Jari noted from the mike, there is no case in which a ULA is
required.
>
> Then how do we assign a prefix for a totally isolated network that
includes
> at least two subnets?
>
> I realise that no such network will exist for ever without getting
connected
> to the Internet, but during the time that it does exist in isolation, ULA
seems
> a better solution than having people make up their own unicast prefix or
> applying to ARIN for a PI prefix.
>
> Beyond that I'm getting too sleepy to work through your analysis, but I
think
> Bing's model of documenting the full range of use cases in a neutral
manner
> is a good first step. The second step might well be guidelines about which
> ones are viable and which ones are harmful.
>

+1 that Bing has a good approach and this work is valuable , with the ideal
outcome that the known-good use cases are documented. Yes, ula is useful in
some cases.

> As Nathan's comment shows, opinions may vary.
>
> Regards
>   Brian
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

--f46d04170701b8785604b1f04b1f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable




On Nov 17, 2011 3:19 AM, "Brian E Carpenter" <brian.e.carpenter@gmail.com> wrote:
>

> Fred,

>

> > First, as Jari noted from the mike, there is no case in which a U=
LA is required.

>

> Then how do we assign a prefix for a totally isolated network that inc=
ludes

> at least two subnets?

>

> I realise that no such network will exist for ever without getting con=
nected

> to the Internet, but during the time that it does exist in isolation, =
ULA seems

> a better solution than having people make up their own unicast prefix =
or

> applying to ARIN for a PI prefix.

>

> Beyond that I'm getting too sleepy to work through your analysis, =
but I think

> Bing's model of documenting the full range of use cases in a neutr=
al manner

> is a good first step. The second step might well be guidelines about w=
hich

> ones are viable and which ones are harmful.

>


+1 that Bing has a good approach and this work is valuable , with the id=
eal outcome that the known-good use cases are documented. Yes, ula is usefu=
l in some cases. 


> As Nathan's comment shows, opinions may vary.

>

> Regards

> =A0 Brian

>

> _______________________________________________

> v6ops mailing list

> v6ops@ietf.org

> https://www.ie=
tf.org/mailman/listinfo/v6ops




--f46d04170701b8785604b1f04b1f--

From fx.lebail@yahoo.com  Thu Nov 17 08:12:39 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6327011E810F for ; Thu, 17 Nov 2011 08:12:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.921
X-Spam-Level: 
X-Spam-Status: No, score=-0.921 tagged_above=-999 required=5 tests=[AWL=0.778,  BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 SN0fCFm-vBmi for ; Thu, 17 Nov 2011 08:12:38 -0800 (PST)
Received: from nm24-vm2.bullet.mail.ne1.yahoo.com (nm24-vm2.bullet.mail.ne1.yahoo.com [98.138.91.212]) by ietfa.amsl.com (Postfix) with SMTP id A934121F91F0 for ; Thu, 17 Nov 2011 08:12:38 -0800 (PST)
Received: from [98.138.90.56] by nm24.bullet.mail.ne1.yahoo.com with NNFMP; 17 Nov 2011 16:12:32 -0000
Received: from [98.138.88.237] by tm9.bullet.mail.ne1.yahoo.com with NNFMP; 17 Nov 2011 16:12:32 -0000
Received: from [127.0.0.1] by omp1037.mail.ne1.yahoo.com with NNFMP; 17 Nov 2011 16:12:32 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 652241.59599.bm@omp1037.mail.ne1.yahoo.com
Received: (qmail 73890 invoked by uid 60001); 17 Nov 2011 16:12:32 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1321546352; bh=QaPFXfwpNHg9CUFz07lbiSPbL9GwHQxUfP1Yd0c3Z3c=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=veubeWhR/rT2sxXho983lY/OdAAy/L6EQfPwD1YYqAE+l4u22rfx0DkmNxFanR/5CxrqyZXAYtsIlR+eH8e3dNeK7DqZrE/3O/WtUqGhKp8dNnqMu0h6uxOPurvfHH7dFz8xd9UML9XLCufTngpNK/2tBXN9NVrabgdgJqpUZaQ=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=rBzsNDQb8XrvClGZNiYrx3TI97sxySZnvSgMOm9KjBMe5JEMCYIL8E4NfF/EJbRbCM7OAquvwRXtVIfn9e8KguC6+RZs2FL50AfBGMJ23kYEaGqKW6Zxn1/duwvh6fakeXWt3aQnFWfIrNpZbAamHfLm7taex0ZRMIzKn/+9Gx4=;
X-YMail-OSG: ppQWKcEVM1mE_NhrsCrZH9JnFVKoUeY3YhPsRtSVGBKTXQj E7a1GAuDZW3kjrg5Yu6xCuK.UDjKBFJcH1U7IjAVs9FFt2fj27PFtp0VWdbG fsYdDjRinwW.ITrjue4UOwrql.fYc9JDtsrQ_WDC4c7xSHy.ahvwm.MSjguc NgtLCUYZ.R9DMMN0zwtKMsfWVem_qf.fv.RsvCI3_yUrCOUIaZTnIzZPl89W kpyZph3f9jqpk0AudaCvxAHaxHLlwTC1YLm.aihSlXR7MWtG5uCmoD2Y.z9T N1HxmgJjOsumGstLb.RLIWu8PDX.TkKu4NHYavSYMgQ9u4SRGpw6j61prQmm qRuBt4ntRryK8X_4hzah9wCy22cf29jQAAbDMZYUMCYe01ki8oXPuZMJF9KS UJvM.a12f.1aNlzpDhlXWtAndIJiLs0qm26hYgpPPOrRTx4tP1S0wV9y9C5k p2iEnYuUMd8FBhZgLMqA3ValeT5lOLZVcoPWSYuViVusnrzMoc0cP9jV6
Received: from [193.49.124.107] by web126009.mail.ne1.yahoo.com via HTTP; Thu, 17 Nov 2011 08:12:31 PST
X-Mailer: YahooMailWebService/0.8.115.325013
References: <867F4B6A1672E541A94676D556793ACD0C263BCDD7@MOPESMBX01.eu.thmulti.com><5B6B2B64C9FE2A489045EEEADDAFF2C303494A91@XMB-RCD-109.cisco.com><867F4B6A1672E541A94676D556793ACD0C27516363@MOPESMBX01.eu.thmulti.com><5B6B2B64C9FE2A489045EEEADDAFF2C303494F74@XMB-RCD-109.cisco.com><867F4B6A1672E541A94676D556793ACD0C27516655@MOPESMBX01.eu.thmulti.com><5B6B2B64C9FE2A489045EEEADDAFF2C303494FE3@XMB-RCD-109.cisco.com><867F4B6A1672E541A94676D556793ACD0C27516671@MOPESMBX01.eu.thmulti.com><5B6B2B64C9FE2A489045EEEADDAFF2C303494FE5@XMB-RCD-109.cisco.com><867F4B6A1672E541A94676D556793ACD0C275166AC@MOPESMBX01.eu.thmulti.com>, <5B6B2B64C9FE2A489045EEEADDAFF2C303494FE8@XMB-RCD-109.cisco.com><2F25DE74-DA72-4B7B-9358-9E1F17BF4DAD@Cable.Comcast.com> <867F4B6A1672E541A94676D556793ACD0C275167F4@MOPESMBX01.eu.thmulti.com>  <5B6B2B64C9FE2A489045EEEADDAFF2C3035447D7@XMB-RCD-109.cisco.com>
Message-ID: <1321546351.73809.YahooMailNeo@web126009.mail.ne1.yahoo.com>
Date: Thu, 17 Nov 2011 08:12:31 -0800 (PST)
From: =?iso-8859-1?Q?Fran=E7ois-Xavier_Le_Bail?= 
To: "Hemant Singh \(shemant\)" , "George, Wes" , Wuyts Carl , "Lee, Yiu" 
In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3035447D7@XMB-RCD-109.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] RFC6204bis-02
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: =?iso-8859-1?Q?Fran=E7ois-Xavier_Le_Bail?= 
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Nov 2011 16:12:39 -0000

----- Original Message -----=0A=0A> From: Hemant Singh (shemant) =0A> To: "George, Wes" ; Wuyts Carl ; "Lee, Yiu" =0A> -----=
Original Message-----=0A> From: George, Wes [mailto:wesley.george@twcable.c=
om] =0A> To: Wuyts Carl; Lee, Yiu; Hemant Singh (shemant)=0A> =0A>> [WEG] M=
ore importantly, how would a CPE determine what addresses are=0A> public an=
d what are private? Assuming simply public !=3D RFC1918 isn't=0A>> enough, =
whether draft-weil passes or not. Either you now have to take=0A> that spac=
e into account as additional private space, or you run the=0A>> very real r=
isk of folks using "public" addresses (squat) inside of=0A> private environ=
ments, or both.=0A> =0A> We have discussed such a question in the cpe route=
r design team.=A0 The=0A> private address space included RFC5735 and the re=
served range in RFC=0A> 6333.=A0 Current range suffices for a DS-Lite right=
 now because even if a=0A> range is very small DS-Lite also uses port + IP =
enlarges the range.=A0 Of=0A> course, stuff happens and some day the range =
may deplete and then=0A> draft-weil or a squat range will need to be consid=
ered.=A0 Thus a CE=0A> router vendor is expected to provide a knob or a fir=
mware upgrade when=0A> the range changes.=A0  We are leaning towards changi=
ng the MUST in the=0A> bullet to a SHOULD as well.=0A=0AHemant,=0A=0ARFC 63=
33 reserve 192.0.0.0/29 which is included in=0A=0A"192.0.0.0/24 - This bloc=
k is reserved for IETF protocol assignments." =0Adocumented in RFC 5735.=0A=
=0ASo I think only reference to RFC 5735 is needed. =0AThanks,=0AFrancois-X=
avier=0A=0A> _______________________________________________=0A> v6ops mail=
ing list=0A> v6ops@ietf.org=0A> https://www.ietf.org/mailman/listinfo/v6ops=
=0A>

From shemant@cisco.com  Thu Nov 17 13:53:21 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99FC91F0C6F for ; Thu, 17 Nov 2011 13:53:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.24
X-Spam-Level: 
X-Spam-Status: No, score=-6.24 tagged_above=-999 required=5 tests=[AWL=0.358,  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 IT-krt0qmjWZ for ; Thu, 17 Nov 2011 13:53:21 -0800 (PST)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id EFCC31F0C6B for ; Thu, 17 Nov 2011 13:53:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=5476; q=dns/txt; s=iport; t=1321566801; x=1322776401; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=mJvXq4cLvbIOg6IDEEJVfgdunlEyMKKdkY/ITmfW7g4=; b=O6TCbeZsoNMy5NVBdkVc16vpc92yn3wMQigppDd8ldFaL/iyT0bnMAnV 86HBfRuURh/96iVq09KeD4GhDz5TwlCOstmmUkuz5oRekYeVvO6iiYTtQ 9+/mPJOr2QWmSRoouGZp0uP1f0UgzB19A0Fv7aVVH3TLiD4SeLXsxzX4v U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AnkAACiCxU6tJXHA/2dsb2JhbABCgk2XQZAygQWBcgEBAQEDEgEJEQNJEAIBCBEEAQELBhgGAU4IAQEEEwgan1UBnj2JNGMEiBWRZIxX
X-IronPort-AV: E=Sophos;i="4.69,529,1315180800"; d="scan'208,217";a="37079794"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-4.cisco.com with ESMTP; 17 Nov 2011 21:53:19 +0000
Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id pAHLrJLQ015964;  Thu, 17 Nov 2011 21:53:19 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 17 Nov 2011 15:53:18 -0600
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCA573.5118F157"
Date: Thu, 17 Nov 2011 15:53:17 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C303544B01@XMB-RCD-109.cisco.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] 6rd Sunsetting
Thread-Index: AcylB+2XBG7bnps9SgyKSbwWeQqt3wAYjhIA
References: <68DAB112-6E32-45FE-9AB7-A34E64898F60@cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30354436E@XMB-RCD-109.cisco.com> <750BF7861EBBE048B3E648B4BB6E8F4F20DC41F6@crexc50p> 
From: "Hemant Singh (shemant)" 
To: "Fred Baker (fred)" , "STARK, BARBARA H" 
X-OriginalArrivalTime: 17 Nov 2011 21:53:18.0924 (UTC) FILETIME=[513658C0:01CCA573]
Cc: Alexandre Cassen , v6ops@ietf.org, Claire Cheng 
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 17 Nov 2011 21:53:21 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CCA573.5118F157
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

=20

From: Fred Baker (fred)=20
Sent: Thursday, November 17, 2011 5:04 PM
To: STARK, BARBARA H
Cc: Hemant Singh (shemant); Hans Liu; Alexandre Cassen; v6ops@ietf.org;
Claire Cheng
Subject: Re: [v6ops] 6rd Sunsetting

=20

>Personally, I'd be a bit perplexed at putting native and 6rd deployment
into the same prefix. I could imagine adjacent prefixes - one is
2001:dba:2:2::/64 and the other >is 2001:dba:2:3::/64.=20

=20

The text sent out earlier said a route metric that prefers native IPv6
over 6rd will forward packets for your example above.

=20

Hemant

=20


------_=_NextPart_001_01CCA573.5118F157
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


 
From:=
 =
Fred Baker (fred) 
Sent: Thursday, November 17, 2011 5:04 =
PM
To: STARK, BARBARA H
Cc: Hemant Singh (shemant); =
Hans Liu; Alexandre Cassen; v6ops@ietf.org; Claire =
Cheng
Subject: Re: [v6ops] 6rd =
Sunsetting
 
>Personally, I'd be a bit perplexed at =
putting native and 6rd deployment into the same prefix. I could imagine =
adjacent prefixes - one is 2001:dba:2:2::/64 and the other >is 2001:dba:2:3::/64. =

 
The text sent out =
earlier said a route metric that prefers native IPv6 over 6rd will =
forward packets for your example above.
 
Hemant
 

------_=_NextPart_001_01CCA573.5118F157--

From shemant@cisco.com  Thu Nov 17 14:01:27 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CECDA1F0C83 for ; Thu, 17 Nov 2011 14:01:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.094
X-Spam-Level: 
X-Spam-Status: No, score=-6.094 tagged_above=-999 required=5 tests=[AWL=0.205,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 vul1js4eCyC0 for ; Thu, 17 Nov 2011 14:01:23 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id ACFFA1F0C6B for ; Thu, 17 Nov 2011 14:01:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=560; q=dns/txt; s=iport; t=1321567282; x=1322776882; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=DE4j2VOogXisGUjK3FKxz9f2SXQugsOJBaLxQMAdSKs=; b=VIBMIsEOblrzyu7dHAxe2hcdlBozF/9pHh7s4zit1oMzjuDZKtiGYi9h nSGbWFWBrcLIqfduTNxLm+AFf6mFtKAVo3eVmTm9zWCszTnJfUDcqbShY NfpVxKQjApT8xKoNnKs9JjdX+di3q8unFi0OKkBRATivA4gwWJkWSAUfa w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqMAAKuDxU6tJV2Y/2dsb2JhbABCmg4PkCOBBYFyAQEBAQMSAR1JDAQCAQgRBAEBCwYXAQYBRAEJCAEBBAESCBqfWwGeOok0YwSHZDGRZIUHh1A
X-IronPort-AV: E=Sophos;i="4.69,529,1315180800"; d="scan'208";a="37098335"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 17 Nov 2011 22:01:22 +0000
Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pAHM1Nsw032003;  Thu, 17 Nov 2011 22:01:23 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 17 Nov 2011 16:01:22 -0600
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 17 Nov 2011 16:01:21 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C303544B12@XMB-RCD-109.cisco.com>
In-Reply-To: <1321546351.73809.YahooMailNeo@web126009.mail.ne1.yahoo.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] RFC6204bis-02
Thread-Index: AcylQ7bt2mMYenGQTWiue4uIiSVFyAAMJXrQ
References: <867F4B6A1672E541A94676D556793ACD0C263BCDD7@MOPESMBX01.eu.thmulti.com><5B6B2B64C9FE2A489045EEEADDAFF2C303494A91@XMB-RCD-109.cisco.com><867F4B6A1672E541A94676D556793ACD0C27516363@MOPESMBX01.eu.thmulti.com><5B6B2B64C9FE2A489045EEEADDAFF2C303494F74@XMB-RCD-109.cisco.com><867F4B6A1672E541A94676D556793ACD0C27516655@MOPESMBX01.eu.thmulti.com><5B6B2B64C9FE2A489045EEEADDAFF2C303494FE3@XMB-RCD-109.cisco.com><867F4B6A1672E541A94676D556793ACD0C27516671@MOPESMBX01.eu.thmulti.com><5B6B2B64C9FE2A489045EEEADDAFF2C303494FE5@XMB-RCD-109.cisco.com><867F4B6A1672E541A94676D556793ACD0C275166AC@MOPESMBX01.eu.thmulti.com>, <5B6B2B64C9FE2A489045EEEADDAFF2C303494FE8@XMB-RCD-109.cisco.com><2F25DE74-DA72-4B7B-9358-9E1F17BF4DAD@Cable.Comcast.com> <867F4B6A1672E541A94676D556793ACD0C275167F4@MOPESMBX01.eu.thmulti.com>  <5B6B2B64C9FE2A489045EEEADDAFF2C3035447D7@XMB-RCD-109.cisco.com> <1321546351.73809.YahooMailNeo@web126009 .mail.ne 1.yahoo.com>
From: "Hemant Singh (shemant)" 
To: =?iso-8859-1?Q?Fran=E7ois-Xavier_Le_Bail?= , "George, Wes" , "Wuyts Carl" , "Lee, Yiu" 
X-OriginalArrivalTime: 17 Nov 2011 22:01:22.0914 (UTC) FILETIME=[71B15C20:01CCA574]
Cc: v6ops@ietf.org
Subject: Re: [v6ops] RFC6204bis-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: Thu, 17 Nov 2011 22:01:27 -0000

-----Original Message-----
From: Fran=E7ois-Xavier Le Bail [mailto:fx.lebail@yahoo.com]=20
Sent: Friday, November 18, 2011 12:13 AM
To: Hemant Singh (shemant); George, Wes; Wuyts Carl; Lee, Yiu
Cc: v6ops@ietf.org
Subject: Re: [v6ops] RFC6204bis-02

>RFC 6333 reserve 192.0.0.0/29 which is included in

>"192.0.0.0/24 - This block is reserved for IETF protocol assignments."=20
>documented in RFC 5735.

>So I think only reference to RFC 5735 is needed.=20

Good catch.  Will remove the reference to the range from RFC 6333.

Thanks,

Hemant

From jhw@apple.com  Thu Nov 17 14:55:24 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54D3D21F94E4 for ; Thu, 17 Nov 2011 14:55:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.298
X-Spam-Level: 
X-Spam-Status: No, score=-106.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=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 gvS9Yswll6Pp for ; Thu, 17 Nov 2011 14:55:23 -0800 (PST)
Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id D689621F94E0 for ; Thu, 17 Nov 2011 14:55:23 -0800 (PST)
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_dBvHDbsWb8CMMq9rpVLiXg)"
Received: from relay15.apple.com ([17.128.113.54]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTP id <0LUT00BFKU1RXW13@mail-out.apple.com> for v6ops@ietf.org; Thu, 17 Nov 2011 14:55:08 -0800 (PST)
X-AuditID: 11807136-b7c19ae0000072b0-74-4ec590ccba09
Received: from [17.153.31.123] (Unknown_Domain [17.153.31.123]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate)	by relay15.apple.com (Apple SCV relay) with SMTP id 84.D0.29360.CC095CE4; Thu, 17 Nov 2011 14:55:08 -0800 (PST)
From: james woodyatt 
In-reply-to: 
Date: Thu, 17 Nov 2011 14:55:08 -0800
Message-id: <7EB596BF-B175-40BF-ABC8-326599670B04@apple.com>
References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com>  <5B6B2B64C9FE2A489045EEEADDAFF2C30354473D@XMB-RCD-109.cisco.com> <4EC455D6.8030601@bogus.com>  
To: Lorenzo Colitti 
X-Mailer: Apple Mail (2.1251.1)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrNLMWRmVeSWpSXmKPExsUiOFO+WvfMhKN+BhOOqFmsP/2O0eL0sb3M DkweCzaVeixZ8pMpgCmKyyYlNSezLLVI3y6BK+PKhrVMBYtVKjYvf8/WwHhNvouRk0NCwERi z/E17BC2mMSFe+vZuhi5OIQEpjJJXJ4wnw0kISxgKHFj+yWwIl4BY4k1t96xgNjMAgkS0zau ZgSx2QRUJL5dvssEYnMKBEp8/3sCLM4ioCrxufErkM0BVK8i8b+BH2KMjcTyNZcZIXZdZ5L4 P2UPM0hCREBD4sG640wQB8lLtHy9wzaBkW8WktWzkKyGsLUlli18zQxh60m8bHrHjimuK3Fx 3STGBYxsqxgFi1JzEisNTfUSCwpyUvWS83M3MYKCtKHQbAfjjr9yhxgFOBiVeHgn2h71E2JN LCuuzD3EKMHBrCTC+8oDKMSbklhZlVqUH19UmpNafIhRmoNFSZy3dNdBPyGB9MSS1OzU1ILU IpgsEwenVAPjQuMVqsv2JJi5+wieD3RpFXrT+rjTds5Gru/Z1h+ZzcsN/h5gDHumMuepSIam zsWk16bHwr92GPdw1FkWzSm7kHLy/Pb1WRNczH59mO0b1mMU2LltSvqMTrt11+Pm5n1YfqQ7 hK+hNd10/fTEqu1N7gc+bJ3Lw1v+8WTGE3G2/f8PH1959oylEktxRqKhFnNRcSIAnvjfQk4C	AAA=
Cc: IPv6 Operations 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 17 Nov 2011 22:55:24 -0000

--Boundary_(ID_dBvHDbsWb8CMMq9rpVLiXg)
Content-type: text/plain; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT

On Nov 16, 2011, at 11:25 PM, Lorenzo Colitti wrote:

> If you're a CE router, it doesn't matter what RAs you see. CE routers explicitly ignore IPv6 RAs when determining whether to start DHCPv6 PD or not,

This is news to me.  The way I read RFC 6204 and I-D.ietf-v6ops-6204bis, CPE routers are not required to ignore the M and O bits in IPv6 router advertisements.  As far as I can see, CPE router implementations that wait to receive a router advertisement on the WAN with O=1 before starting the DHCPv6 client still conforms to the recommendations and complies with the forthcoming IPv6Ready CPE Router Interoperability test specification.


--
james woodyatt 
member of technical staff, core os networking




--Boundary_(ID_dBvHDbsWb8CMMq9rpVLiXg)
Content-type: text/html; CHARSET=US-ASCII
Content-transfer-encoding: quoted-printable


If you're a =
CE router, it doesn't matter what RAs you see. CE routers explicitly =
ignore IPv6 RAs when determining whether to start DHCPv6 PD or =
not,

This is news to me.  The way =
I read RFC 6204 and I-D.ietf-v6ops-6204bis, CPE routers are not required =
to ignore the M and O bits in IPv6 router advertisements.  As far =
as I can see, CPE router implementations that wait to receive a router =
advertisement on the WAN with O=3D1 before starting the DHCPv6 client =
still conforms to the recommendations and complies with the forthcoming =
IPv6Ready CPE Router Interoperability test specification.




--
james woodyatt <jhw@apple.com>
member of technical staff, core os =
networking






=

--Boundary_(ID_dBvHDbsWb8CMMq9rpVLiXg)--

From shemant@cisco.com  Thu Nov 17 16:29:17 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA21E1F0C3E for ; Thu, 17 Nov 2011 16:29:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.946
X-Spam-Level: 
X-Spam-Status: No, score=-5.946 tagged_above=-999 required=5 tests=[AWL=0.052,  BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=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 ecS3FOqM4r7W for ; Thu, 17 Nov 2011 16:29:15 -0800 (PST)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 8D33C11E80D1 for ; Thu, 17 Nov 2011 16:29:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=7887; q=dns/txt; s=iport; t=1321576155; x=1322785755; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=y80cswTOas1pVhfPW0Z0qlYVtCKhSWrFkn/JvUl2fxI=; b=lS51QsXOpyR84KMu2ujXmAbQZYlVbw8A+yFVVzPhy2vLmMd90mAipAVN v1qA84pJ6Dz+anFucEvzW9/cSdFlkIxR4hZP3h7HFvUmA1ChIRkieWmHR TvD2Gyw4xAKen+DThNKz2OlWlXedJD3JpYvljp8SKmRS4UAqw+ISW3ucJ s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AnoAAKqmxU6tJXG9/2dsb2JhbABCgk2XRJAygQWBcgEBAQEDEgEJEQNJEAIBCBEEAQELBhcBBgFFCQgBAQQBEggSCJ9TAZ41iTRjBIgVkWSDOokd
X-IronPort-AV: E=Sophos;i="4.69,530,1315180800"; d="scan'208,217";a="37108287"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-3.cisco.com with ESMTP; 18 Nov 2011 00:29:15 +0000
Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id pAI0TFrE018707;  Fri, 18 Nov 2011 00:29:15 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 17 Nov 2011 18:29:15 -0600
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCA589.19C25241"
Date: Thu, 17 Nov 2011 18:29:13 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C303544B88@XMB-RCD-109.cisco.com>
In-Reply-To: <7EB596BF-B175-40BF-ABC8-326599670B04@apple.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] DHCPv6 option for MAX_SOL_RT
Thread-Index: AcylfCE5hEHJ6IwETkW8AJhuNzeFWQADKIsA
References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com><5B6B2B64C9FE2A489045EEEADDAFF2C30354473D@XMB-RCD-109.cisco.com><4EC455D6.8030601@bogus.com> <7EB596BF-B175-40BF-ABC8-326599670B04@apple.com>
From: "Hemant Singh (shemant)" 
To: "james woodyatt" , "Lorenzo Colitti" 
X-OriginalArrivalTime: 18 Nov 2011 00:29:15.0036 (UTC) FILETIME=[19E3BDC0:01CCA589]
Cc: IPv6 Operations 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 18 Nov 2011 00:29:17 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CCA589.19C25241
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

James,

=20

RFC 3633 specifies acquiring an IA_PD between a requesting and a
delegating router.  Thus such a protocol between two routers could care
less if the delegating router issued an RA to the requesting router or
if an RA issued, why care about the M and the O bits.  The CE router WAN
interface does support an unnumbered model in which the WAN interface
has only an IPv6 link-local.  Then the WAN has to initiate DHCPv6 to
acquire an IA_PD.

=20

Hemant

=20

From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
Of james woodyatt
Sent: Thursday, November 17, 2011 5:55 PM
To: Lorenzo Colitti
Cc: IPv6 Operations
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT

=20

On Nov 16, 2011, at 11:25 PM, Lorenzo Colitti wrote:





If you're a CE router, it doesn't matter what RAs you see. CE routers
explicitly ignore IPv6 RAs when determining whether to start DHCPv6 PD
or not,

=20

This is news to me.  The way I read RFC 6204 and I-D.ietf-v6ops-6204bis,
CPE routers are not required to ignore the M and O bits in IPv6 router
advertisements.  As far as I can see, CPE router implementations that
wait to receive a router advertisement on the WAN with O=3D1 before
starting the DHCPv6 client still conforms to the recommendations and
complies with the forthcoming IPv6Ready CPE Router Interoperability test
specification.

=20


--

james woodyatt 

member of technical staff, core os networking





=20


------_=_NextPart_001_01CCA589.19C25241
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


James,
 
RFC 3633 specifies acquiring an IA_PD between a requesting and a =
delegating router.  Thus such a protocol between two routers could =
care less if the delegating router issued an RA to the requesting router =
or if an RA issued, why care about the M and the O bits.  The CE =
router WAN interface does support an unnumbered model in which the WAN =
interface has only an IPv6 link-local.  Then the WAN has to =
initiate DHCPv6 to acquire an IA_PD.
 
Hemant
 
From:=
 =
v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of =
james woodyatt
Sent: Thursday, November 17, 2011 5:55 =
PM
To: Lorenzo Colitti
Cc: IPv6 =
Operations
Subject: Re: [v6ops] DHCPv6 option for =
MAX_SOL_RT
 
On =
Nov 16, 2011, at 11:25 PM, Lorenzo Colitti wrote:


If =
you're a CE router, it doesn't matter what RAs you see. CE routers =
explicitly ignore IPv6 RAs when determining whether to start DHCPv6 PD =
or not,
 
This is =
news to me.  The way I read RFC 6204 and I-D.ietf-v6ops-6204bis, =
CPE routers are not required to ignore the M and O bits in IPv6 router =
advertisements.  As far as I can see, CPE router implementations =
that wait to receive a router advertisement on the WAN with O=3D1 before =
starting the DHCPv6 client still conforms to the recommendations and =
complies with the forthcoming IPv6Ready CPE Router Interoperability test =
specification.
 

--
james =
woodyatt <jhw@apple.com><=
/o:p>
member=
 of technical staff, core os networking<=
/o:p>

 

------_=_NextPart_001_01CCA589.19C25241--

From Tina.Tsou.Zouting@huawei.com  Thu Nov 17 17:08:21 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D9611F0C5D for ; Thu, 17 Nov 2011 17:08:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.038
X-Spam-Level: 
X-Spam-Status: No, score=-6.038 tagged_above=-999 required=5 tests=[AWL=0.560,  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 uIwXu-e1UJzg for ; Thu, 17 Nov 2011 17:08:20 -0800 (PST)
Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 120FD1F0C55 for ; Thu, 17 Nov 2011 17:08:20 -0800 (PST)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUU00I230HO7C@szxga03-in.huawei.com> for v6ops@ietf.org; Fri, 18 Nov 2011 09:08:12 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUU00DTI0HOW8@szxga03-in.huawei.com> for v6ops@ietf.org; Fri, 18 Nov 2011 09:08:12 +0800 (CST)
Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AFD57701; Fri, 18 Nov 2011 09:08:12 +0800
Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 18 Nov 2011 09:08:02 +0800
Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.40]) by szxeml406-hub.china.huawei.com ([10.82.67.93]) with mapi id 14.01.0323.003; Fri, 18 Nov 2011 09:08:01 +0800
Date: Fri, 18 Nov 2011 01:08:01 +0000
From: Tina TSOU 
In-reply-to: <5B6B2B64C9FE2A489045EEEADDAFF2C303544B01@XMB-RCD-109.cisco.com>
To: "Hemant Singh (shemant)" 
Message-id: <8C037EF8-4CC9-41E7-BD57-B347581A8AA9@huawei.com>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_BoJW7VFAvlPqvKvucz2gsA)"
Content-language: en-US
Accept-Language: en-US, zh-CN
Thread-topic: [v6ops] 6rd Sunsetting
Thread-index: AQHMo2zkiVaVmflTEk2DrH6PcFso4ZWtESmAgAF9cYCAACEjgIABVu+AgAA8IQCAANbdgIAAvIXZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
References:   <68DAB112-6E32-45FE-9AB7-A34E64898F60@cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30354436E@XMB-RCD-109.cisco.com> <750BF7861EBBE048B3E648B4BB6E8F4F20DC41F6@crexc50p>  <5B6B2B64C9FE2A489045EEEADDAFF2C303544B01@XMB-RCD-109.cisco.com>
Cc: Alexandre Cassen , "v6ops@ietf.org" , Claire Cheng 
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 18 Nov 2011 01:08:21 -0000

--Boundary_(ID_BoJW7VFAvlPqvKvucz2gsA)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

In Section 5, I have doubts in the steps an operator would employ:

1.   In 6rd CE is configured with Ipv6 Prefix for eg: 2001:D000::/20 and not delegated prefix, delegated prefix is calculated with the WAN address of the CE.

2.   What are native and 6rd interfaces? A CE has a LAN interface, a WAN interface and a tunnel interface. For native Ipv6, is the CE connected to the WAN with another interface?

3.   Currently the IP forwarding rule is something like this:

Ipv6 route 2001:D000::/20  tunnel0 ( all 6rd traffic will be forwarded from tunnel interface)

Ipv6 route ::/0 tunnel0  BR-interface(default route for  native v6 traffic from tunnel but via BR)

How will the forwarding rule be with native IPv6? Can you give an example?

4.   If we use the same 6rd prefix for native nodes, BR still has the rule that it forwards only those incoming packets which have this prefix, otherwise discard. But how does BR distinguish whether the packet with this prefix will follow native ipv6 routing or be tunneled? ( As per my understanding with native Ipv6 deployment we also mean that we have some native v6 routing in the n/w for v6 only nodes, though initially there will be very routes and gradually as the n/w changes towards native v6, we want 6rd traffic to become less)

Tina
Sent from my iPad

On Nov 18, 2011, at 5:53 AM, "Hemant Singh (shemant)" > wrote:


From: Fred Baker (fred)
Sent: Thursday, November 17, 2011 5:04 PM
To: STARK, BARBARA H
Cc: Hemant Singh (shemant); Hans Liu; Alexandre Cassen;  v6ops@ietf.org; Claire Cheng
Subject: Re: [v6ops] 6rd Sunsetting

>Personally, I'd be a bit perplexed at putting native and 6rd deployment into the same prefix. I could imagine adjacent prefixes - one is 2001:dba:2:2::/64 and the other >is 2001:dba:2:3::/64.

The text sent out earlier said a route metric that prefers native IPv6 over 6rd will forward packets for your example above.

Hemant


--Boundary_(ID_BoJW7VFAvlPqvKvucz2gsA)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT










In Section 5, I have doubts in the steps an operator would employ:



1.   In
 6rd CE is configured with Ipv6 Prefix for eg: 2001:D000::/20 and not delegated prefix, delegated prefix is calculated with the WAN address of the CE.



2.   What
 are native and 6rd interfaces? A CE has a LAN interface, a WAN interface and a tunnel interface. For native Ipv6, is the CE connected to the WAN with another interface?



3.   Currently
 the IP forwarding rule is something like this:



Ipv6 route 2001:D000::/20  tunnel0 ( all 6rd traffic will be forwarded from tunnel interface)



Ipv6 route ::/0 tunnel0  BR-interface(default route for  native v6 traffic from tunnel but via BR)



How will the forwarding rule be with native IPv6? Can you give an example?



4.   If
 we use the same 6rd prefix for native nodes, BR still has the rule that it forwards only those incoming packets which have this prefix, otherwise discard. But how does BR distinguish whether the packet with this prefix will follow native ipv6 routing or be
 tunneled? ( As per my understanding with native Ipv6 deployment we also mean that we have some native v6 routing in the n/w for v6 only nodes, though initially there will be very routes and gradually as the n/w changes towards native v6, we want 6rd traffic
 to become less)



 

Tina

Sent from my iPad




On Nov 18, 2011, at 5:53 AM, "Hemant Singh (shemant)" <shemant@cisco.com> wrote:














 






From: Fred Baker (fred)


Sent: Thursday, November 17, 2011 5:04 PM

To: STARK, BARBARA H

Cc: Hemant Singh (shemant); Hans Liu; Alexandre Cassen; 
v6ops@ietf.org; Claire Cheng

Subject: Re: [v6ops] 6rd Sunsetting






 


>Personally, I'd be a bit perplexed at putting native and 6rd deployment into the same prefix. I could imagine adjacent prefixes - one is 2001:dba:2:2::/64 and the other
>is 2001:dba:2:3::/64. 




 


The text sent out earlier said a route metric that prefers native IPv6 over 6rd will forward packets for your example above.


 


Hemant


 


















--Boundary_(ID_BoJW7VFAvlPqvKvucz2gsA)--

From fred@cisco.com  Thu Nov 17 17:29:18 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8165A1F0C55 for ; Thu, 17 Nov 2011 17:29:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -107.499
X-Spam-Level: 
X-Spam-Status: No, score=-107.499 tagged_above=-999 required=5 tests=[AWL=-0.900, 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 SdDkdxWYX7P3 for ; Thu, 17 Nov 2011 17:29:17 -0800 (PST)
Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 6E2691F0C52 for ; Thu, 17 Nov 2011 17:29:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1692; q=dns/txt; s=iport; t=1321579757; x=1322789357; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=Kt3wUe0RVqj5fkE7MHmq/MpNlUiLbZf+jid+oqoxi9w=; b=cx8VCCVjiQkC8ED/3w9vgN4I+mNVrWCyo6eF22FiZ89WNjPl9THXqQna UMLLE4bNv0c8tDlELXn8fIegyfv80BufMLkIZmBi3vNBuKFR3ExpSUdAB bEv/U35YmSJqYHrqNCKmkiTFS9CjxPcHbk5Dm44SsFVYW2GYfaSSJPmFb I=;
X-IronPort-AV: E=Sophos;i="4.69,530,1315180800";  d="scan'208";a="3387450"
Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-4.cisco.com with ESMTP; 18 Nov 2011 01:29:13 +0000
Received: from dhcp-4466.meeting.ietf.org (hkidc-vpn-client-233-100.cisco.com [10.75.233.100]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pAI1TCCh001999; Fri, 18 Nov 2011 01:29:12 GMT
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Fred Baker 
In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C303544B01@XMB-RCD-109.cisco.com>
Date: Fri, 18 Nov 2011 09:29:11 +0800
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <68DAB112-6E32-45FE-9AB7-A34E64898F60@cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30354436E@XMB-RCD-109.cisco.com> <750BF7861EBBE048B3E648B4BB6E8F4F20DC41F6@crexc50p>  <5B6B2B64C9FE2A489045EEEADDAFF2C303544B01@XMB-RCD-109.cisco.com>
To: Hemant Singh (shemant) 
X-Mailer: Apple Mail (2.1084)
Cc: Alexandre Cassen , v6ops@ietf.org, Claire Cheng 
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 18 Nov 2011 01:29:18 -0000

On Nov 18, 2011, at 5:53 AM, Hemant Singh (shemant) wrote:
> From: Fred Baker (fred)=20
> Sent: Thursday, November 17, 2011 5:04 PM
> To: STARK, BARBARA H
> Cc: Hemant Singh (shemant); Hans Liu; Alexandre Cassen; =
v6ops@ietf.org; Claire Cheng
> Subject: Re: [v6ops] 6rd Sunsetting
> =20
> >Personally, I'd be a bit perplexed at putting native and 6rd =
deployment into the same prefix. I could imagine adjacent prefixes - one =
is 2001:dba:2:2::/64 and the other >is 2001:dba:2:3::/64.
> =20
> The text sent out earlier said a route metric that prefers native IPv6 =
over 6rd will forward packets for your example above.
> =20
> Hemant

Well, yes, but only if the routing protocol in question is set up in a =
way that routing protocols recognize. I realize that MIF thinks it would =
be nice to have systems on multiple interfaces using the same prefix. =
Routing protocols (RIPng, OSPFv3, IS-IS, ...) will want to treat =
separate prefixes as separate interfaces and single prefixes as single =
interfaces, or will want to talk about neighbor relationships - the way =
to get to a set of 6rd prefixes is via a 6rd neighbor, and the way to =
get to a more general prefix is a different routing neighbor.

Instead of mandating weird route selection rules, it would be really =
nice to be able to discuss it in terms the routing protocol, and =
therefore the metric you refer to, which is carried in a routing =
protocol, understand.=20

BTW, this is probably the first time I have heard discussion of a =
routing protocol exchanged between a broadband ISP and a residential =
customer that wasn't immediately shouted down by the broadband =
operator...=

From shemant@cisco.com  Thu Nov 17 17:48:22 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB6411E80A4 for ; Thu, 17 Nov 2011 17:48:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.247
X-Spam-Level: 
X-Spam-Status: No, score=-6.247 tagged_above=-999 required=5 tests=[AWL=0.352,  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 Kh0iEPxMBAaw for ; Thu, 17 Nov 2011 17:48:21 -0800 (PST)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB9211E8094 for ; Thu, 17 Nov 2011 17:48:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=1269; q=dns/txt; s=iport; t=1321580901; x=1322790501; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=dOYIseOBpgTjkU1oxdG/JKra0ZXk5jLMHzeIHQF0HPc=; b=Q++2i3kHStBAhKxWS0N/73j2l1GDoou1KAcUxqEvnSj23wxhLy1ApX0l aLuRp2K6GHToI7QKbkWshFsiLlf6VzK74jnTmdtHXjxruPDHjvVFKUbg6 /mKwwiznNWkGi1a0QZjicUmZYSQZPM+/AwjiogDg91gOSDZUJqnnbXje6 U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AnkAAAO4xU6tJV2Z/2dsb2JhbABCmhCQMoEFgXIBAQEBAxIBHQo4BwwEAgEIEQQBAQsGGAYBTggBAQQTCBqgBQGeLYk0YwSIFZFkjFc
X-IronPort-AV: E=Sophos;i="4.69,530,1315180800"; d="scan'208";a="37121001"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP; 18 Nov 2011 01:48:20 +0000
Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pAI1mK2X029261;  Fri, 18 Nov 2011 01:48:20 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 17 Nov 2011 19:48:20 -0600
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 17 Nov 2011 19:48:18 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C303544BAB@XMB-RCD-109.cisco.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] 6rd Sunsetting
Thread-Index: AcylkXwIclPFHaH0SNm9o/dnqxRfGgAAZjAg
References: <68DAB112-6E32-45FE-9AB7-A34E64898F60@cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30354436E@XMB-RCD-109.cisco.com> <750BF7861EBBE048B3E648B4BB6E8F4F20DC41F6@crexc50p>  <5B6B2B64C9FE2A489045EEEADDAFF2C303544B01@XMB-RCD-109.cisco.com> 
From: "Hemant Singh (shemant)" 
To: "Fred Baker (fred)" 
X-OriginalArrivalTime: 18 Nov 2011 01:48:20.0418 (UTC) FILETIME=[265B9220:01CCA594]
Cc: Alexandre Cassen , v6ops@ietf.org, Claire Cheng 
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 18 Nov 2011 01:48:22 -0000

-----Original Message-----
From: Fred Baker (fred)=20
Sent: Friday, November 18, 2011 9:29 AM
To: Hemant Singh (shemant)
Cc: STARK, BARBARA H; Hans Liu; Alexandre Cassen; v6ops@ietf.org; Claire
Cheng
Subject: Re: [v6ops] 6rd Sunsetting


>Well, yes, but only if the routing protocol in question is set up in a
way that routing protocols recognize. I realize that MIF thinks it
>would be nice to have systems on multiple interfaces using the same
prefix. Routing protocols (RIPng, OSPFv3, IS-IS, ...) will want to
>treat separate prefixes as separate interfaces and single prefixes as
single interfaces, or will want to talk about neighbor >relationships -
the way to get to a set of 6rd prefixes is via a 6rd neighbor, and the
way to get to a more general prefix is a different >routing neighbor.

RFC 6204 nor rfc6204bis recommend to not run a routing protocol between
the CPE WAN and the SP.  Neither does rfc6204 support a multihoming
feature (MIF) on the WAN that is needed when the WAN includes at least
two interfaces.  When rfc6204bis mentions a routing metric, it is simply
an auto-created static IPv6 route internal to the CPE router.  Also the
LAN routing protocols in rfc6204bis has been taken out and move to
homenet. =20

Hemant

From shemant@cisco.com  Thu Nov 17 18:07:21 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87D4F1F0C46 for ; Thu, 17 Nov 2011 18:07:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.25
X-Spam-Level: 
X-Spam-Status: No, score=-6.25 tagged_above=-999 required=5 tests=[AWL=0.349,  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 MZC7mFGw339l for ; Thu, 17 Nov 2011 18:07:20 -0800 (PST)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id C37F71F0C34 for ; Thu, 17 Nov 2011 18:07:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=1058; q=dns/txt; s=iport; t=1321582040; x=1322791640; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=TBR6icaCEB9UJDYhDLAjaitjCrVfsaCcFuTc/uDjcQo=; b=atfjQbp0wcxr8CyI1MU4880p3SH6u/hEq64fAXHSthVzQajwNsQ69BoR n+4auS9slxK23gaVW8DLifD6TgsYTwrBlTC/OzMRFgYC+XnFAO2bvi86c 9gLrrgSUsbZCtp6g3Nag83pXq8E8tc1DjTa6VzImaPd0/2Dc0fGpg59kp c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AnkAADq9xU6tJXG8/2dsb2JhbABCmhGQMoEFgXIBAQEBAxIBHQo/DAQCAQgRBAEBCwYXAQYBRQkIAQEEARIIGp95AZ4uiTRjBIgVkWSMVw
X-IronPort-AV: E=Sophos;i="4.69,530,1315180800"; d="scan'208";a="37117155"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-6.cisco.com with ESMTP; 18 Nov 2011 02:07:20 +0000
Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id pAI27KRV015772;  Fri, 18 Nov 2011 02:07:20 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 17 Nov 2011 20:07:20 -0600
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 17 Nov 2011 20:07:18 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C303544BB0@XMB-RCD-109.cisco.com>
In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C303544BAB@XMB-RCD-109.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] 6rd Sunsetting
Thread-Index: AcylkXwIclPFHaH0SNm9o/dnqxRfGgAAZjAgAADOaUA=
References: <68DAB112-6E32-45FE-9AB7-A34E64898F60@cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C30354436E@XMB-RCD-109.cisco.com><750BF7861EBBE048B3E648B4BB6E8F4F20DC41F6@crexc50p><5B6B2B64C9FE2A489045EEEADDAFF2C303544B01@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303544BAB@XMB-RCD-109.cisco.com>
From: "Hemant Singh (shemant)" 
To: "Hemant Singh (shemant)" , "Fred Baker (fred)" 
X-OriginalArrivalTime: 18 Nov 2011 02:07:20.0219 (UTC) FILETIME=[CDBB66B0:01CCA596]
Cc: Alexandre Cassen , v6ops@ietf.org, Claire Cheng 
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 18 Nov 2011 02:07:21 -0000

Fred,

Sorry, there is MIF involved with 6rd and native IPv6 running
concurrently.  However, the auto-generated static route text emailed
below still works.  Soon as native IPv6 is active on the CPE when 6rd
was running previously, the 6rd tunnel will be given lower priority than
native IPv6 for data forwarding.

Hemant

-----Original Message-----
From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
Of Hemant Singh (shemant)
Sent: Friday, November 18, 2011 9:48 AM
To: Fred Baker (fred)
Cc: Alexandre Cassen; v6ops@ietf.org; Claire Cheng
Subject: Re: [v6ops] 6rd Sunsetting

RFC 6204 nor rfc6204bis recommend to not run a routing protocol between
the CPE WAN and the SP.  Neither does rfc6204 support a multihoming
feature (MIF) on the WAN that is needed when the WAN includes at least
two interfaces.  When rfc6204bis mentions a routing metric, it is simply
an auto-created static IPv6 route internal to the CPE router.  Also the
LAN routing protocols in rfc6204bis has been taken out and move to
homenet. =20


From jhw@apple.com  Thu Nov 17 18:39:13 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17BD011E80A5 for ; Thu, 17 Nov 2011 18:39:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.568
X-Spam-Level: 
X-Spam-Status: No, score=-106.568 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 RLnjUzsPd4F2 for ; Thu, 17 Nov 2011 18:39:12 -0800 (PST)
Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 85A8411E8098 for ; Thu, 17 Nov 2011 18:39:12 -0800 (PST)
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_W2KDUNN5x4ZJOr+kVt4xAw)"
Received: from relay16.apple.com ([17.128.113.55]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTP id <0LUU00BTO4EVXWY3@mail-out.apple.com> for v6ops@ietf.org; Thu, 17 Nov 2011 18:39:11 -0800 (PST)
X-AuditID: 11807137-b7c56ae0000051ed-94-4ec5c54e43c7
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 A5.5A.20973.F45C5CE4; Thu, 17 Nov 2011 18:39:11 -0800 (PST)
From: james woodyatt 
In-reply-to: <5B6B2B64C9FE2A489045EEEADDAFF2C303544B88@XMB-RCD-109.cisco.com>
Date: Thu, 17 Nov 2011 18:39:10 -0800
Message-id: 
References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com>  <5B6B2B64C9FE2A489045EEEADDAFF2C30354473D@XMB-RCD-109.cisco.com> <4EC455D6.8030601@bogus.com>   <7EB596BF-B175-40BF-ABC8-326599670B04@apple.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303544B88@XMB-RCD-109.cisco.com>
To: Hemant Singh  (shemant)
X-Mailer: Apple Mail (2.1251.1)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFLMWRmVeSWpSXmKPExsUieJDXQdf/6FE/g0d3WS1u/brGZnH62F5m ByaPKb83snosWfKTKYApissmJTUnsyy1SN8ugSujbeca9oIpGhWLvn1ibGBcqdTFyMkhIWAi MWHFbHYIW0ziwr31bF2MXBxCArOZJNqmtTOCJIQFDCVubL8EVsQrYCyx5tY7FhCbWSBB4tf+ y2BxNgEViW+X7zKB2JwCvhLHJ+0Gq2ERUJVYsWEuaxcjB1C9isT/Bn4Qk1fARuLHzkKIVSeZ JW4v38AGUi4ioCfxeOcDVoh75CVavt5hm8DINwvJ5llINkPY2hLLFr5mngW2QUdi8kJGVGEI ++P5I0wLGNlWMQoWpeYkVhqa6SUWFOSk6iXn525iBIVoQ6H5Dsbtf+UOMQpwMCrx8FpaH/UT Yk0sK67MPcQowcGsJMLbtBIoxJuSWFmVWpQfX1Sak1p8iFGag0VJnDdsK1BKID2xJDU7NbUg tQgmy8TBKdXAuHX5v/07b3nc1+UQfbBJ+HZtds5XzhtvHsyOOmS25qHGCv6uudqHojd+vnp8 a2+kf2vzeVHfgyWe+ZZ7rH4IbXhg/0P76LS6TU1Tn1ocvHihRsbZ0PHKpO0fJV1Mdpgve60h 9vxlWOHs3QGnztl0hzv93hNhONWg57RZ5czvUxYcWp57ICk3NFyJpTgj0VCLuag4EQDQm/r2 TQIAAA==
Cc: IPv6 Operations 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 18 Nov 2011 02:39:13 -0000

--Boundary_(ID_W2KDUNN5x4ZJOr+kVt4xAw)
Content-type: text/plain; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT

On Nov 17, 2011, at 16:29 , Hemant Singh (shemant) wrote:

> RFC 3633 specifies acquiring an IA_PD between a requesting and a delegating router.  Thus such a protocol between two routers could care less if the delegating router issued an RA to the requesting router or if an RA issued, why care about the M and the O bits.  The CE router WAN interface does support an unnumbered model in which the WAN interface has only an IPv6 link-local.  Then the WAN has to initiate DHCPv6 to acquire an IA_PD.

None of that implies that CPE routers are required or even expected, by IETF, to ignore the M and O bits in router advertisements received at their WAN interfaces.  I still don't see any language anywhere in an IETF document that says CPE routers are not permitted to wait until they receive a router advertisement with O=1 before initiating the DHCPv6 client on their WAN interface to request any options, including the IA_PD option.

(For the record, I am still opposed to the adoption of any such language.)


--
j h woodyatt 



--Boundary_(ID_W2KDUNN5x4ZJOr+kVt4xAw)
Content-type: text/html; CHARSET=US-ASCII
Content-transfer-encoding: quoted-printable


RFC 3633 specifies =
acquiring an IA_PD between a requesting and a delegating router.  =
Thus such a protocol between two routers could care less if the =
delegating router issued an RA to the requesting router or if an RA =
issued, why care about the M and the O bits.  The CE router WAN =
interface does support an unnumbered model in which the WAN interface =
has only an IPv6 link-local.  Then the WAN has to initiate DHCPv6 =
to acquire an IA_PD.

None of =
that implies that CPE routers are required or even expected, by IETF, to =
ignore the M and O bits in router advertisements received at their WAN =
interfaces.  I still don't see any language anywhere in an IETF =
document that says CPE routers are not permitted to wait until they =
receive a router advertisement with O=3D1 before initiating the DHCPv6 =
client on their WAN interface to request any options, including the =
IA_PD option.

(For the record, I am still =
opposed to the adoption of any such language.)


--
j h woodyatt <jhw@apple.com>





=

--Boundary_(ID_W2KDUNN5x4ZJOr+kVt4xAw)--

From leo.liubing@huawei.com  Thu Nov 17 18:49:16 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B9AF1F0C6A for ; Thu, 17 Nov 2011 18:49:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.236
X-Spam-Level: 
X-Spam-Status: No, score=-3.236 tagged_above=-999 required=5 tests=[AWL=-1.440, BAYES_00=-2.599, 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 v6Lc22hzF6iz for ; Thu, 17 Nov 2011 18:49:15 -0800 (PST)
Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6A91F0C68 for ; Thu, 17 Nov 2011 18:49:15 -0800 (PST)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUU00IZM54P7C@szxga03-in.huawei.com> for v6ops@ietf.org; Fri, 18 Nov 2011 10:48:25 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUU00GYE54PKA@szxga03-in.huawei.com> for v6ops@ietf.org; Fri, 18 Nov 2011 10:48:25 +0800 (CST)
Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AFB53981; Fri, 18 Nov 2011 10:48:24 +0800
Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 18 Nov 2011 10:48:16 +0800
Received: from SZXEML509-MBS.china.huawei.com ([169.254.2.220]) by szxeml407-hub.china.huawei.com ([10.82.67.94]) with mapi id 14.01.0323.003; Fri, 18 Nov 2011 10:48:15 +0800
Date: Fri, 18 Nov 2011 02:48:14 +0000
From: "Leo Liu(bing)" 
In-reply-to: <5B6B2B64C9FE2A489045EEEADDAFF2C3035447F3@XMB-RCD-109.cisco.com>
X-Originating-IP: [172.24.2.41]
To: "Hemant Singh (shemant)" , Brian E Carpenter , "Fred Baker (fred)" 
Message-id: <8AE0F17B87264D4CAC7DE0AA6C406F45236690F9@szxeml509-mbs.china.huawei.com>
MIME-version: 1.0
Content-type: text/plain; charset=gb2312
Content-language: zh-CN
Content-transfer-encoding: base64
Accept-Language: zh-CN, en-US
Thread-topic: [v6ops] Major use cases for ULA
Thread-index: AQHMpRUJvI18wacPokOHL33emnLRKZWwZU6AgAAV3wCAAWqcOQ==
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
References: <754008F3-6B2B-4DD1-B72B-EDE17A4FBF80@cisco.com> <4EC4EDC9.1080003@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3035447F3@XMB-RCD-109.cisco.com>
Cc: "v6ops@ietf.org" , "draft-liu-v6ops-ula-usage-analysis@tools.ietf.org" 
Subject: Re: [v6ops] Major use cases for ULA
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 18 Nov 2011 02:49:16 -0000

SGksIEhlbWFudA0KDQpUaGUgUkZDNjIwNCBpcyBmb3IgdGhlIENQRSByZXF1aXJlbWVudCwgYnV0
IHRoZSBVTEEgdG9waWMgZGlzY3Vzc2VkIGluIEhvbWVuZXQgaXMgd2hldGhlciBpdCBpcyBhIGdv
b2QgaWRlYSBmb3IgdGhlIGhvc3RzIHdpdGhpbiBhIGhvbWUgbmV0d29yayB0byBiZSBjb25maWd1
cmVkIHdpdGggVUxBIGFsb25nIHdpdGggdGhlIGdsb2JhbCBQQSBhZGRyZXNzZXMuIFBybyBpcyBV
TEEgY2FuIHByb3ZpZGUgc3RhYmxlIGxvY2FsIGNvbW11bmljYXRpb24gcmVnYXJkbGVzcyBvZiB0
aGUgUEEgcmVudW1iZXJpbmcgZnJvbSB0aGUgSVNQOyBjb24gaXMgYWRkaW5nIG9wZXJhdGlvbiBj
b21wbGV4aXR5IG9mIHJ1bm5pbmcgbXVsdGlwbGUgcHJlZml4ZXMuIEl0IGlzIHN0aWxsIGNvbnRy
b3ZlcmNpYWwgYW5kIEkgZG9uJ3QgdGhpbmsgdGhlIFJGQzYyMDQgY2FuIGRyaXZlIGEgY29uY2x1
c2lvbiBmb3IgaXQuDQoNCkkgYWdyZWUgdGhhdCBSRkM0MTkzIGhhcyBwcm92aWRlZCBzb21lIGNs
ZWFyIGd1aWRsaW5lcyBvZiB1c2luZyBVTEEuIEJ1dCB0aGV5IGFyZSAqcHJpbmNpcGxlKiBhbmQg
KmdlbmVyYWwqLCBhbmQgdGhlIGZhY3QgaXMgdGhhdCB0aGVyZSdzIGZldyBkZXBsb3ltZW50IG9m
IFVMQSBhbmQgaW4gc29tZSBjYXNlcyBpdCBpcyBjb250cm92ZXJjaWFsLiBUaGUgZG9jdW1lbnQg
aW50ZW5kcyB0byBtb3ZlIGZvcndhcmQgb24gdGhpcyB0b3BpYy4gV2UgdHJpZWQgdG8gbWFrZSBh
IGNvbXByZWhlbnNpdmUgYW5hbHlzaXMgb2YgVUxBIHVzZWNhc2VzIGFzIGEgc3RhcnQgYW5kIGhv
cGUgdG8gcHJvdm9rZSBkaXNjdXNzaW9uIHNvIHRoYXQgd2UgbWF5IGFjaGlldmUgY29uc2Vuc3Vz
IHRvIG1ha2Ugc29tZSByZWNvbW1lbmRhdGlvbnMuIEJlc2lkZXMsIHRoZXJlIGFyZSBzb21lIGdv
b2QgcHJhY3Rpc2Ugb2YgdXNpbmcgVUxBIGFzIGEgdXNlZnVsIHRvb2wsIHdoaWNoIEkgYmVsaXZl
IGlzIHdvcnRoIHRvIGJlIGRvY3VtZW50ZWQgYW5kIHZhbHVhYmxlIGZvciB0aGUgcmVhZGVycywg
YW5kIHdlJ3ZlIHJlY2VpdmVkIHNldmVyYWwgZmVlZGJhY2tzIG9mIHN1Y2ggc3R1ZmYgYWZ0ZXIg
c3VibWl0dGluZyB0aGUgZHJhZnQuIA0KDQpTbywgdGhlcmUgYXJlIHBlb3BsZSBkbyBjYXJlIGFi
b3V0IHVzaW5nIFVMQS4gQW5kIEkgYmVsaWV2ZSB0aGUgZGlzY3Vzc2lvbiBpcyBuZWVkZWQgYW5k
IHZhbHVhYmxlLg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQq3
orz+yMs6IHY2b3BzLWJvdW5jZXNAaWV0Zi5vcmcgW3Y2b3BzLWJvdW5jZXNAaWV0Zi5vcmddILT6
se0gSGVtYW50IFNpbmdoIChzaGVtYW50KSBbc2hlbWFudEBjaXNjby5jb21dDQq3osvNyrG85Dog
MjAxMcTqMTHUwjE3yNUgMjA6MzcNCrW9OiBCcmlhbiBFIENhcnBlbnRlcjsgRnJlZCBCYWtlciAo
ZnJlZCkNCkNjOiB2Nm9wc0BpZXRmLm9yZzsgZHJhZnQtbGl1LXY2b3BzLXVsYS11c2FnZS1hbmFs
eXNpc0B0b29scy5pZXRmLm9yZw0K1vfM4jogUmU6IFt2Nm9wc10gTWFqb3IgdXNlIGNhc2VzIGZv
ciBVTEENCg0KTm90ZSBhcyBvZiBjaXJjYSAyMDA3LTIwMDgsIGluIHY2b3BzIGRpc2N1c3Npb24g
b24gdGhlIElQdjYgQ1BFIHJvdXRlcg0KZHJhZnQgd2UgY2xlYXJseSBzYWlkIHRoZSBVTEEgaW4g
dGhlIGhvbWUgTEFOIHNlcnZlcyBhcyBhIHN0YWJsZSBwcmVmaXgNCmZvciB0aGUgY29tcHV0ZXIg
YXQgaG9tZSB0byBwcmludCB0byB0aGUgcHJpbnRlciBhdCBob21lIHdpdGggdGhlIFNQDQpnbG9i
YWwgbGluayBoYXMgZ29uZSBkb3duLiAgVGhlIFVMQSBoYXMgYWxyZWFkeSBiZWVuIHNwZWNpZmll
ZCBpbiBSRkMNCjYyMDQuICBUaHVzIGF0IGxlYXN0IG5vIG5ldyBkb2N1bWVudCBpcyBuZWVkZWQg
dG8gb3V0bGluZSBzdWNoIGEgdXNlDQp3aGljaCBoYXMgYmVlbiBhbHJlYWR5IGNhcnJpZWQgb3Zl
ciB0byBob21lbmV0Lg0KDQpUaGUgb3RoZXIgdXNlIGNhc2Ugb2YgdGhlIFVMQSB3YXMgYWxzbyBk
aXNjdXNzZWQgYXJvdW5kIHRoZSBzYW1lIHRpbWUgYXMNCmFib3ZlIHRvIGNvbmZpZ3VyZSB0aGUg
Q1BFIHJvdXRlciB1c2luZyBhIFVSTC4gIEl0IHdhcyBkaXN0aW5jdGx5IG5vdGVkDQp0aGF0IHNv
bWUgd2ViIGJyb3dzZXJzIHdpbGwgbm90IHNlcnZlIGEgVVJMIHdpdGggYSBsaW5rLWxvY2FsIGFk
ZHJlc3MuDQpUaGVuIGFuIElQdjYgZ2xvYmFsIGlzIG5lZWRlZCBhbmQgdGhlIFVMQSBoYXMgZ2xv
YmFsIHNjb3BlLiBTb29uIGFzIHRoZQ0KQ1BFIHJvdXRlciBpcyBwb3dlcmVkIHVwIHRoZSBVTEEg
Y2FuIGJlIHVzZWQgdG8gYWNjZXNzIHRoZSBkZXZpY2Ugb3Zlcg0KdGhlIHdlYiB3aGVuIHRoZSB1
c2VyIGhhcyBub3QgZXZlbiBjb25uZWN0ZWQgdGhlIENQRSBXQU4gdG8gdGhlIEludGVybmV0DQpT
UC4NCg0KVGhlIFVMQSBkb2N1bWVudCBpbiBSRkMgNDE5MyBhbHJlYWR5IHNwZWNpZmllcyBwcm9w
ZXJ0aWVzIG9mIHRoZSBVTEENCnRoYXQgbWFrZSBpdCByZWxhdGl2ZWx5IGNsZWFyIHRvIGEgcmVh
ZGVyIHdoZXJlIHRoZSBVTEEgY2FuIGJlIHVzZWQuDQpUaHVzIHdoeSBkbyB3ZSBuZWVkIGEgbmV3
IGRvY3VtZW50IHRvIGRvY3VtZW50IHdoYXQgdGhlIFVMQSBjYW4gYmUgdXNlZA0KZm9yPw0KDQpI
ZW1hbnQNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHY2b3BzLWJvdW5jZXNA
aWV0Zi5vcmcgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCk9mIEJy
aWFuIEUgQ2FycGVudGVyDQpTZW50OiBUaHVyc2RheSwgTm92ZW1iZXIgMTcsIDIwMTEgNzoyMCBQ
TQ0KVG86IEZyZWQgQmFrZXIgKGZyZWQpDQpDYzogdjZvcHNAaWV0Zi5vcmcgV0c7IGRyYWZ0LWxp
dS12Nm9wcy11bGEtdXNhZ2UtYW5hbHlzaXNAdG9vbHMuaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBb
djZvcHNdIE1ham9yIHVzZSBjYXNlcyBmb3IgVUxBDQoNCkZyZWQsDQoNCj4gRmlyc3QsIGFzIEph
cmkgbm90ZWQgZnJvbSB0aGUgbWlrZSwgdGhlcmUgaXMgbm8gY2FzZSBpbiB3aGljaCBhIFVMQSBp
cw0KcmVxdWlyZWQuDQoNClRoZW4gaG93IGRvIHdlIGFzc2lnbiBhIHByZWZpeCBmb3IgYSB0b3Rh
bGx5IGlzb2xhdGVkIG5ldHdvcmsgdGhhdA0KaW5jbHVkZXMNCmF0IGxlYXN0IHR3byBzdWJuZXRz
Pw0KDQpJIHJlYWxpc2UgdGhhdCBubyBzdWNoIG5ldHdvcmsgd2lsbCBleGlzdCBmb3IgZXZlciB3
aXRob3V0IGdldHRpbmcNCmNvbm5lY3RlZA0KdG8gdGhlIEludGVybmV0LCBidXQgZHVyaW5nIHRo
ZSB0aW1lIHRoYXQgaXQgZG9lcyBleGlzdCBpbiBpc29sYXRpb24sDQpVTEEgc2VlbXMNCmEgYmV0
dGVyIHNvbHV0aW9uIHRoYW4gaGF2aW5nIHBlb3BsZSBtYWtlIHVwIHRoZWlyIG93biB1bmljYXN0
IHByZWZpeCBvcg0KYXBwbHlpbmcgdG8gQVJJTiBmb3IgYSBQSSBwcmVmaXguDQoNCkJleW9uZCB0
aGF0IEknbSBnZXR0aW5nIHRvbyBzbGVlcHkgdG8gd29yayB0aHJvdWdoIHlvdXIgYW5hbHlzaXMs
IGJ1dCBJDQp0aGluaw0KQmluZydzIG1vZGVsIG9mIGRvY3VtZW50aW5nIHRoZSBmdWxsIHJhbmdl
IG9mIHVzZSBjYXNlcyBpbiBhIG5ldXRyYWwNCm1hbm5lcg0KaXMgYSBnb29kIGZpcnN0IHN0ZXAu
IFRoZSBzZWNvbmQgc3RlcCBtaWdodCB3ZWxsIGJlIGd1aWRlbGluZXMgYWJvdXQNCndoaWNoDQpv
bmVzIGFyZSB2aWFibGUgYW5kIHdoaWNoIG9uZXMgYXJlIGhhcm1mdWwuDQoNCkFzIE5hdGhhbidz
IGNvbW1lbnQgc2hvd3MsIG9waW5pb25zIG1heSB2YXJ5Lg0KDQpSZWdhcmRzDQogICBCcmlhbg0K
DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KdjZvcHMg
bWFpbGluZyBsaXN0DQp2Nm9wc0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby92Nm9wcw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18NCnY2b3BzIG1haWxpbmcgbGlzdA0KdjZvcHNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCg==

From shemant@cisco.com  Thu Nov 17 19:46:16 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE04B11E8097 for ; Thu, 17 Nov 2011 19:46:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.253
X-Spam-Level: 
X-Spam-Status: No, score=-6.253 tagged_above=-999 required=5 tests=[AWL=0.346,  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 9M2y+9Eyw0vX for ; Thu, 17 Nov 2011 19:46:16 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 1F16A11E8073 for ; Thu, 17 Nov 2011 19:46:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=1055; q=dns/txt; s=iport; t=1321587976; x=1322797576; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=PK7bxLXFsqd/Q9cPs5WBe8wl6BcwE9lPdYIuNxZ6TAk=; b=Qp5VOkbCpgJUI7Hmcbyjs31WHQsyHo01LmWqb799azCf+t5gHC2RcBnr mD9woD04ieFmTr70Bg6zggNmfPcbLg59z28rsJ99J/LJgNQ7UT4eoqXuS em8kl5SGB7DCtnsL+WH/vjifHgBIF/IFqQf8nj29B5x2vrODnbJN/FUGF 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AokAANjUxU6tJV2Y/2dsb2JhbABCmhGQMoEFgXIBAQEEEgEdCj8MBAIBCBEEAQELBhcBBgFFCQgCBAESCBqgFQGeMYk0YwSIFpFmjFk
X-IronPort-AV: E=Sophos;i="4.69,530,1315180800"; d="scan'208";a="37170404"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 18 Nov 2011 03:46:13 +0000
Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pAI3kCNY009619;  Fri, 18 Nov 2011 03:46:12 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 17 Nov 2011 21:46:12 -0600
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 17 Nov 2011 21:46:11 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C303544BDC@XMB-RCD-109.cisco.com>
In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F45236690F9@szxeml509-mbs.china.huawei.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] Major use cases for ULA
Thread-Index: AQHMpRUJvI18wacPokOHL33emnLRKZWwZU6AgAAV3wCAAWqcOYAAGNfA
References: <754008F3-6B2B-4DD1-B72B-EDE17A4FBF80@cisco.com> <4EC4EDC9.1080003@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3035447F3@XMB-RCD-109.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F45236690F9@szxeml509-mbs.china.huawei.com>
From: "Hemant Singh (shemant)" 
To: "Leo Liu(bing)" , "Brian E Carpenter" , "Fred Baker (fred)" 
X-OriginalArrivalTime: 18 Nov 2011 03:46:12.0922 (UTC) FILETIME=[9DE609A0:01CCA5A4]
Cc: v6ops@ietf.org, draft-liu-v6ops-ula-usage-analysis@tools.ietf.org
Subject: Re: [v6ops] Major use cases for ULA
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 18 Nov 2011 03:46:16 -0000

-----Original Message-----
From: Leo Liu(bing) [mailto:leo.liubing@huawei.com]=20
Sent: Friday, November 18, 2011 10:48 AM
To: Hemant Singh (shemant); Brian E Carpenter; Fred Baker (fred)
Cc: v6ops@ietf.org; draft-liu-v6ops-ula-usage-analysis@tools.ietf.org
Subject: re: [v6ops] Major use cases for ULA


>The RFC6204 is for the CPE requirement, but the ULA topic discussed in
Homenet is whether it is a good idea for the hosts within a home
>network to be configured with ULA along with the global PA addresses.
Pro is ULA can provide stable local communication regardless of the >PA
renumbering from the ISP; con is adding operation complexity of running
multiple prefixes. It is still controvercial and I don't think >the
RFC6204 can drive a conclusion for it.

RFC 6204 already specifies use of the ULA and a GUA (Globally Unique
Address) prefix from the SP to run concurrently in the home.  Thus the
hosts in the home served by the CPE router will already support
concurrent use of at least two IPv6 address. =20

Hemant=20

From Ted.Lemon@nominum.com  Thu Nov 17 21:07:13 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6746D11E80C3 for ; Thu, 17 Nov 2011 21:07:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.569
X-Spam-Level: 
X-Spam-Status: No, score=-106.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 Ah5VWjE6pYgo for ; Thu, 17 Nov 2011 21:07:12 -0800 (PST)
Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id 6614311E80B3 for ; Thu, 17 Nov 2011 21:07:11 -0800 (PST)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKTsXn/gGSWl8e3Ga0qAYahQoDEz7IoTHw@postini.com; Thu, 17 Nov 2011 21:07:11 PST
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 685C41B82E4 for ; Thu, 17 Nov 2011 21:07:10 -0800 (PST)
Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 5388F19005D; Thu, 17 Nov 2011 21:07:10 -0800 (PST) (envelope-from Ted.Lemon@nominum.com)
Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.01.0339.001; Thu, 17 Nov 2011 21:07:10 -0800
From: Ted Lemon 
To: james woodyatt 
Thread-Topic: [v6ops] DHCPv6 option for MAX_SOL_RT
Thread-Index: AQHMpBVS9v5OyU3dDEaf8biIUoZIIJWwMYMAgACJcgCAAANuAP//e/aAgAD3r4CAAQPRAIAAGkmAgAAkTwD//6M9OA==
Date: Fri, 18 Nov 2011 05:07:09 +0000
Message-ID: <5DF4B5B0-8A53-4829-81B5-2131AECF1430@nominum.com>
References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com>  <5B6B2B64C9FE2A489045EEEADDAFF2C30354473D@XMB-RCD-109.cisco.com> <4EC455D6.8030601@bogus.com>   <7EB596BF-B175-40BF-ABC8-326599670B04@apple.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303544B88@XMB-RCD-109.cisco.com>, 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: IPv6 Operations 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 18 Nov 2011 05:07:13 -0000

On Nov 18, 2011, at 10:39 AM, "james woodyatt"  wrote:
> None of that implies that CPE routers are required or even expected, by I=
ETF, to ignore the M and O bits in router advertisements received at their =
WAN interfaces.  I still don't see any language anywhere in an IETF documen=
t that says CPE routers are not permitted to wait until they receive a rout=
er advertisement with O=3D1 before initiating the DHCPv6 client on their WA=
N interface to request any options, including the IA_PD option.

Since we don't know what the M and O bits do, I think it's a bit questionab=
le to use them in this way.   I mean, I can hack my router so that your CPE=
 device will not fail to configure itself, but that probably won't be possi=
ble anymore once my IPv6 upstream is coming from my actual ISP.=

From ichiroumakino@gmail.com  Thu Nov 17 22:42:37 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B3EC21F9539 for ; Thu, 17 Nov 2011 22:42:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.541
X-Spam-Level: 
X-Spam-Status: No, score=-3.541 tagged_above=-999 required=5 tests=[AWL=0.058,  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 ilZ8-rB7eQd2 for ; Thu, 17 Nov 2011 22:42:36 -0800 (PST)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id A1BBB21F9536 for ; Thu, 17 Nov 2011 22:42:36 -0800 (PST)
Received: by wwe5 with SMTP id 5so3845096wwe.13 for ; Thu, 17 Nov 2011 22:42:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=cL56pQh+KoQMZHxFsOY1yFgHpV7b5C9Xod3nw+XmP6w=; b=C2UcRJNsxJyUQMqePGhEZwrPWaf1zIEe14Uymr6aZndl+kRKoqHOCySomHt4vF1dz3 l8P1hW04nWxL4glkRmbPk9Oqo6jpDZAz0SV7+JZ/5CHiJHlibMHEnCuunzdD8/CvQNGc GHuBrqeDDln+aB8hI4VtusRYwBUpLMU7Tqrfw=
Received: by 10.180.81.73 with SMTP id y9mr1681103wix.37.1321598549615; Thu, 17 Nov 2011 22:42:29 -0800 (PST)
Received: from ams3-vpn-dhcp4965.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id eu16sm39669691wbb.7.2011.11.17.22.42.26 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 17 Nov 2011 22:42:28 -0800 (PST)
Sender: Ole Troan 
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Ole Troan 
In-Reply-To: 
Date: Fri, 18 Nov 2011 07:42:22 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com>  <5B6B2B64C9FE2A489045EEEADDAFF2C30354473D@XMB-RCD-109.cisco.com> <4EC455D6.8030601@bogus.com>   <7EB596BF-B175-40BF-ABC8-326599670B04@apple.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303544B88@XMB-RCD-109.cisco.com> 
To: james woodyatt 
X-Mailer: Apple Mail (2.1084)
Cc: IPv6 Operations 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 18 Nov 2011 06:42:37 -0000

>=20
>> RFC 3633 specifies acquiring an IA_PD between a requesting and a =
delegating router.  Thus such a protocol between two routers could care =
less if the delegating router issued an RA to the requesting router or =
if an RA issued, why care about the M and the O bits.  The CE router WAN =
interface does support an unnumbered model in which the WAN interface =
has only an IPv6 link-local.  Then the WAN has to initiate DHCPv6 to =
acquire an IA_PD.
>=20
> None of that implies that CPE routers are required or even expected, =
by IETF, to ignore the M and O bits in router advertisements received at =
their WAN interfaces.  I still don't see any language anywhere in an =
IETF document that says CPE routers are not permitted to wait until they =
receive a router advertisement with O=3D1 before initiating the DHCPv6 =
client on their WAN interface to request any options, including the =
IA_PD option.
>=20
> (For the record, I am still opposed to the adoption of any such =
language.)

6204 says that you are free to wait for the RA. and look at the M and =
the O bits. from the M/O bits the CPE can determine if it should ask for =
only IA_PD or both IA_PD and IA_NA. a 6204 router MUST always do DHCP.

cheers,
Ole=

From ichiroumakino@gmail.com  Thu Nov 17 22:43:57 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9B4C21F953B for ; Thu, 17 Nov 2011 22:43:57 -0800 (PST)
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 QkhaPIAKw3ZH for ; Thu, 17 Nov 2011 22:43:56 -0800 (PST)
Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id A733821F94E5 for ; Thu, 17 Nov 2011 22:43:52 -0800 (PST)
Received: by eyg24 with SMTP id 24so3451602eyg.31 for ; Thu, 17 Nov 2011 22:43:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=tXfCQznPxkLdUz2FFOnvQ6NoiH9PDf698znljREX0sE=; b=KIKIa3sKq0I5HJqZ/X82rUBl/rkfyMpP5DXqNnwb5TPYQXR7RFLJfbrwWl7gIP2C4J xUx8+nEl4uAI97IerYpmm9KdfN5047QVOSk1IIptJ4HGukiU5oC2YZ4/p4wPcKUXzlrw OCE2hgBmuC5f/kJxd9H4DO9j6mVbr2hnM4lCM=
Received: by 10.181.13.210 with SMTP id fa18mr1727642wid.19.1321598624130; Thu, 17 Nov 2011 22:43:44 -0800 (PST)
Received: from ams3-vpn-dhcp4965.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id ff6sm39673458wbb.10.2011.11.17.22.43.40 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 17 Nov 2011 22:43:43 -0800 (PST)
Sender: Ole Troan 
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=windows-1252
From: Ole Troan 
In-Reply-To: <3E09E3FD-51F7-4FA9-A173-ADDAB07871E9@nominum.com>
Date: Fri, 18 Nov 2011 07:43:36 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <223C79CD-05B2-4488-BE8D-59861997B484@employees.org>
References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com>  <5B6B2B64C9FE2A489045EEEADDAFF2C30354473D@XMB-RCD-109.cisco.com> <4EC455D6.8030601@bogus.com> ,  <3E09E3FD-51F7-4FA9-A173-ADDAB07871E9@nominum.com>
To: Ted Lemon 
X-Mailer: Apple Mail (2.1084)
Cc: "v6ops@ietf.org" , Ralph Droms 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 18 Nov 2011 06:43:57 -0000

Ted,

>> If you're a CE router, it doesn't matter what RAs you see. CE routers =
explicitly ignore IPv6 RAs when determining whether to start DHCPv6 PD =
or not,
>=20
> So if you're a CE router that's plugged into an ethernet that's got =
your upstream on it, and your upstream goes away, but your switch =
doesn't tell you because it doesn't know you need to know, then we have =
a problem.   Is that a possible scenario for CE routers?   It seems to =
me that typically a CE router is going to see a carrier transition of =
some kind when moving to a different provider network.

not getting a L2 event is common. there are multiple proposals to deal =
with that from Ethernet OAM, short DHCP lease timers to BFD echo. not =
sure any of that applies much to this discussion.

> BTW, I actually am not entirely convinced that Ralph's proposal is a =
good idea=97it's a quick hack to work around a one-time operational =
problem that we will be stuck with forever.   However, I'd like us to =
focus on real reasons for liking it or disliking it.   I think the =
"carrier transition won't be noticed" issue is easily addressed and not =
a very likely scenario anyway.   I would prefer to focus on real =
problems.

cheers,
Ole



From xiechf01@gmail.com  Thu Nov 17 23:32:05 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2878E11E808B for ; Thu, 17 Nov 2011 23:32:05 -0800 (PST)
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 dL3webtJArj0 for ; Thu, 17 Nov 2011 23:32:04 -0800 (PST)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id B33D821F9504 for ; Thu, 17 Nov 2011 23:32:03 -0800 (PST)
Received: by faap16 with SMTP id p16so5974379faa.31 for ; Thu, 17 Nov 2011 23:32:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=C0uxjXxQQ5yJBt3zYLpn2/r3N5YqFdUmcERi5kDxnA4=; b=UjBfGz9J2R1EU6fqVJ0YLmo2dt1pFZlbkwCBAs3dt1kXcbJShGGdFJ5Y/qdlCMa9Lm p5Agbq+uHt5jEEmtQ6Q92Usjd1rzkhmDE5GW5MMxTIx5XJiIhsK64zlmyIG+mMwrb2eb HjRAOoQlwoOywIE1mL/6BR1RMnUyCf4B4dFOg=
MIME-Version: 1.0
Received: by 10.204.13.70 with SMTP id b6mr2061014bka.78.1321601522708; Thu, 17 Nov 2011 23:32:02 -0800 (PST)
Received: by 10.204.115.78 with HTTP; Thu, 17 Nov 2011 23:32:02 -0800 (PST)
In-Reply-To: <4EBC6599.6030002@bogus.com>
References:   <4EB05384.5000007@gmail.com>  <4EB54C85.4050909@bogus.com>  <4EBC6599.6030002@bogus.com>
Date: Fri, 18 Nov 2011 15:32:02 +0800
Message-ID: 
From: Chongfeng Xie 
To: Joel jaeggli 
Content-Type: multipart/alternative; boundary=00151750da4a4bb37404b1fd5581
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] Fwd: New Version Notification for draft-sunq-v6ops-contents-transition-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: Fri, 18 Nov 2011 07:32:05 -0000

--00151750da4a4bb37404b1fd5581
Content-Type: text/plain; charset=ISO-8859-1

Hi, Joel,

       The stateful NAT64 can serve multiple ICPs within the same IDC
simultaneously.  All of them are IPv4-only and can not read IPv6 address,
they have different expectations to get the source IPv6 address, some want
to get IPv6 address, some may not. Some may want to get this information
online, some may offline. What I mean is that ICPs have different
requirements to geo-location. The current NAT64 design keeps the mapping
between users' IPv6 source address and IPv4 address, so the geo-location
information was not threw out in the NAT64 design. We will provide
Interfaces to ICPs to meet their different demands, this is our on-going
work.

      From the standpoint viewpoint of carriers, NAT64 can server as a
shared platform for ICPs in the early phase of transition, especially when
the volume of IPv6 users in not big enough.  Carriers would NOT like to
deploy a system which is involved with too much application-layer
processing, we prefer a solution of network-layer, this is more consistent
with the role of IETF  "above the wire and below the application".

Thank you!

Chongfeng

2011/11/11 Joel jaeggli 

> On 11/7/11 22:13 , Qiong wrote:
> > Hi, Joel
> >
> > On Sat, Nov 5, 2011 at 10:47 PM, Joel jaeggli  > > wrote:
> >
> >     > After all, dual stack is what we have discussing for 10 years. But
> >     up to
> >     > now, how many ICPs have upgraded to IPv6 in dual-stack directly? I
> >     > really think we need to re-think it again, from both technical
> aspect
> >     > and the industry/or market aspect. And the first step is rather
> >     > important to give us confidence to move forward. That's why we
> >     recommend
> >     > single-stack (either v4 or v6) transition in the current phase.
> Then,
> >     > for the conservative ones, the IPv4 services can be still offered
> >     > natively, and the IPv6 services can be offered by the stateful
> NAT64;
> >     > while for progressive ones and newly comers, the stateless IVI can
> be
> >     > employed to offer native IPv6 services reachable via IPv4. And we
> hope
> >     > it would help enrich IPv6 content asap. Then how do you think ?
> >
> >     Any solution that causes me to lose access to the source address is
> not
> >     usable from my vantage point as a content provider. When I terminate
> >     connections on an l7 load balancer as I generally do for http/https
> on
> >     ipv4 and where we do it in ipv6 I can drop x-forwarded for in there.
> >     That requires that I recieve the traffic unmolested by a nat
> transform
> >     associated with my own service.
> >
> > I agree it is important. But there is another question here : although
> > you can use l7 load balancer to insert x-forwarded here,  how can you
> > guarantee that there is no CGN along the path from the user's end-host
> > to the data center.
>
> I don't have to, what I need is a granular enough view of where the
> address sharing is occuring that I can serve my content accordingly.
> it's not a problem for example if ~200,000 mobile users of an app at
> Indonesia's 3rd largest mobile operator emerge from behind a /22
>
> > I mean, in case we cannot avoid deploying some kind
> > of address sharing mechanisms in the future, ICPs have to face the fact
>
> you'll note that I'm assuming the existence of address sharing
> mechanisms on both sides of the conversation. I'd very much prefer that
> the one working on my behalf not necessarily throw out information as a
> product of it's design.
>
> > that they will somehow lose the geo-location info when they receive IPv4
> > traffic. So maybe it is one choice to provide them with a database which
> > stores the original binding information. Would it be some kind of
> helpful ?
>
> where are you going to put that and signal it?
> > Thanks
> >
> > Best wishes
> >
> > Qiong
> >
> >
> >
> >     > Thanks
> >     >
> >     > Qiong
> >     >
> >     >
> >     > On Wed, Nov 2, 2011 at 4:16 AM, Brian E Carpenter
> >     > 
> >      >     >> wrote:
> >     >
> >     >     I'm not seeing why this is a better solution for a
> >     small/medium ICP
> >     >     than just moving to a dual stack. That is much easier for a
> small
> >     >     network than for a big one.
> >     >
> >     >     Regards
> >     >       Brian
> >     >
> >     >
> >     >
> >     > _______________________________________________
> >     > 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
>

--00151750da4a4bb37404b1fd5581
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Hi, Joel,

=A0=A0=A0 =A0=A0 The stateful NAT64 can serve multiple=
 ICPs=20
within the same IDC simultaneously.=A0 All of them are IPv4-only and can=20
not read IPv6 address, they have different expectations to get the=20
source IPv6 address, some want to get IPv6 address, some may not. Some=20
may want to get this information online, some may offline. What I mean=20
is that ICPs have different requirements to geo-location. The current=20
NAT64 design keeps the mapping between users' IPv6 source address and=
=20
IPv4 address, so the  geo-location information was not threw out in the=20
NAT64 design. We will provide Interfaces to ICPs to meet their=20
different demands, this is our on-going work.


=A0=A0=A0=A0=A0 From the standpoint viewpoint of carriers, NAT64 can se=
rver as
 a shared platform for ICPs in the early phase of transition, especially
 when the volume of IPv6 users in not big enough.=A0 Carriers would NOT=20
like to deploy a system which is involved with too much=20
application-layer processing, we prefer a solution of network-layer,=20
this is more consistent with the role of IETF=A0 "above the wire and b=
elow
 the application". 


Thank you!

Chongfeng

2011/11/11 Joel jaeggli <joelja@bogus.com>

On 11/7/11 22:13 , Qiong wrote:

> Hi, Joel

>

> On Sat, Nov 5, 2011 at 10:47 PM, Joel jaeggli <joelja@bogus.com

> <mailto:joelja@bogus.com>=
;> wrote:

>

> =A0 =A0 > After all, dual stack is what we have discussing for 10 y=
ears. But

> =A0 =A0 up to

> =A0 =A0 > now, how many ICPs have upgraded to IPv6 in dual-stack di=
rectly? I

> =A0 =A0 > really think we need to re-think it again, from both tech=
nical aspect

> =A0 =A0 > and the industry/or market aspect. And the first step is =
rather

> =A0 =A0 > important to give us confidence to move forward. That'=
;s why we

> =A0 =A0 recommend

> =A0 =A0 > single-stack (either v4 or v6) transition in the current =
phase. Then,

> =A0 =A0 > for the conservative ones, the IPv4 services can be still=
 offered

> =A0 =A0 > natively, and the IPv6 services can be offered by the sta=
teful NAT64;

> =A0 =A0 > while for progressive ones and newly comers, the stateles=
s IVI can be

> =A0 =A0 > employed to offer native IPv6 services reachable via IPv4=
. And we hope

> =A0 =A0 > it would help enrich IPv6 content asap. Then how do you t=
hink ?

>

> =A0 =A0 Any solution that causes me to lose access to the source addre=
ss is not

> =A0 =A0 usable from my vantage point as a content provider. When I ter=
minate

> =A0 =A0 connections on an l7 load balancer as I generally do for http/=
https on

> =A0 =A0 ipv4 and where we do it in ipv6 I can drop x-forwarded for in =
there.

> =A0 =A0 That requires that I recieve the traffic unmolested by a nat t=
ransform

> =A0 =A0 associated with my own service.

>

> I agree it is important. But there is another question here : although=


> you can use l7 load balancer to insert x-forwarded here, =A0how can yo=
u

> guarantee that there is no CGN along the path from the user's end-=
host

> to the data center.



I don't have to, what I need is a granular enough view of where the

address sharing is occuring that I can serve my content accordingly.

it's not a problem for example if ~200,000 mobile users of an app at
Indonesia's 3rd largest mobile operator emerge from behind a /22



> I mean, in case we cannot avoid deploying some kind

> of address sharing mechanisms in the future, ICPs have to face the fac=
t



you'll note that I'm assuming the existence of address sharing

mechanisms on both sides of the conversation. I'd very much prefer that=


the one working on my behalf not necessarily throw out information as a

product of it's design.



> that they will somehow lose the geo-location info when they receive IP=
v4

> traffic. So maybe it is one choice to provide them with a database whi=
ch

> stores the original binding information. Would it be some kind of help=
ful ?



where are you going to put that and signal it?

> Thanks

>

> Best wishes

>

> Qiong

>

>

>

> =A0 =A0 > Thanks

> =A0 =A0 >

> =A0 =A0 > Qiong

> =A0 =A0 >

> =A0 =A0 >

> =A0 =A0 > On Wed, Nov 2, 2011 at 4:16 AM, Brian E Carpenter

> =A0 =A0 > <brian.=
e.carpenter@gmail.com <mailto:brian.e.carpenter@gmail.com>

> =A0 =A0 <mailto:bria=
n.e.carpenter@gmail.com

> =A0 =A0 <mailto:bria=
n.e.carpenter@gmail.com>>> wrote:

> =A0 =A0 >

> =A0 =A0 > =A0 =A0 I'm not seeing why this is a better solution =
for a

> =A0 =A0 small/medium ICP

> =A0 =A0 > =A0 =A0 than just moving to a dual stack. That is much ea=
sier for a small

> =A0 =A0 > =A0 =A0 network than for a big one.

> =A0 =A0 >

> =A0 =A0 > =A0 =A0 Regards

> =A0 =A0 > =A0 =A0 =A0 Brian

> =A0 =A0 >

> =A0 =A0 >

> =A0 =A0 >

> =A0 =A0 > _______________________________________________

> =A0 =A0 > v6ops mailing list

> =A0 =A0 > v6ops@ietf.org <=
mailto:v6ops@ietf.org>

> =A0 =A0 > https://www.ietf.org/mailman/listinfo/v6ops

>

>



_______________________________________________

v6ops mailing list

v6ops@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/v6ops





--00151750da4a4bb37404b1fd5581--

From lorenzo@google.com  Fri Nov 18 00:06:29 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A249511E808F for ; Fri, 18 Nov 2011 00:06:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.895
X-Spam-Level: 
X-Spam-Status: No, score=-102.895 tagged_above=-999 required=5 tests=[AWL=0.081, 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 nSzwt5UnVSdD for ; Fri, 18 Nov 2011 00:06:28 -0800 (PST)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9CCB411E8083 for ; Fri, 18 Nov 2011 00:06:28 -0800 (PST)
Received: by ghrr14 with SMTP id r14so318851ghr.31 for ; Fri, 18 Nov 2011 00:06:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=XCAjrkMYRKC8JibW9mffmdrsSbjqX24MRoJlwH4ZbQU=; b=HkMjLd7b99uVWuqutPGg5EUxTvst1US56YoGJTsP82ZKXHdgsx0HSbM8ljD6j0e1h1 W2qc7Alx3OsqW/Ru6CKA==
Received: by 10.236.75.167 with SMTP id z27mr2897383yhd.53.1321603587884; Fri, 18 Nov 2011 00:06:27 -0800 (PST)
Received: by 10.236.75.167 with SMTP id z27mr2897371yhd.53.1321603587784; Fri, 18 Nov 2011 00:06:27 -0800 (PST)
MIME-Version: 1.0
Received: by 10.150.202.14 with HTTP; Fri, 18 Nov 2011 00:06:06 -0800 (PST)
In-Reply-To: 
References:   <4EB05384.5000007@gmail.com>  <4EB54C85.4050909@bogus.com>  <4EBC6599.6030002@bogus.com> 
From: Lorenzo Colitti 
Date: Fri, 18 Nov 2011 16:06:06 +0800
Message-ID: 
To: Chongfeng Xie 
Content-Type: multipart/alternative; boundary=20cf3005dde6623ee004b1fdd0fc
X-System-Of-Record: true
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] Fwd: New Version Notification for draft-sunq-v6ops-contents-transition-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: Fri, 18 Nov 2011 08:06:29 -0000

--20cf3005dde6623ee004b1fdd0fc
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Nov 18, 2011 at 15:32, Chongfeng Xie  wrote:

>       From the standpoint viewpoint of carriers, NAT64 can server as a
> shared platform for ICPs in the early phase of transition, especially when
> the volume of IPv6 users in not big enough.  Carriers would NOT like to
> deploy a system which is involved with too much application-layer
> processing, we prefer a solution of network-layer, this is more consistent
> with the role of IETF  "above the wire and below the application".
>

But we should also not recommend a solution for general use if it has
shortcomings.

This solution does not provide the servers with access to the original IPv6
address, and thus does not allow them to do abuse detection, abuse
mitigation, legal intercept, geolocation, and a host of other things. These
issues, coupled with scaling issues, make it unsuitable for real deployment
except in very small websites. It also has the operational disadvantage
that the complete logging information for a request (including the user's
IPv6 address) are not in one place any more, but either in two places (if
the NAT does logging) or not available at all (if it doesn't).

You could run an experiment using this solution. You could run
ipv6.company.com using this solution. But you couldn't run
www.company.comusing this solution unless it was very very small. So I
don't think that
this working group should sanction such a solution; instead, we should
provide implementors with tools and guidance for actually deploying IPv6 in
a way that will scale to their main websites.

--20cf3005dde6623ee004b1fdd0fc
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Fri, Nov 18, 2011 at 15:32, Chongfeng Xie <xiechf01@gmail.com=
> wrote:


=A0 =A0 =A0 From the standpoint viewpoint of carriers, NAT64 can server as
 a shared platform for ICPs in the early phase of transition, especially
 when the volume of IPv6 users in not big enough.=A0 Carriers would NOT=20
like to deploy a system which is involved with too much=20
application-layer processing, we prefer a solution of network-layer,=20
this is more consistent with the role of IETF=A0 "above the wire and b=
elow
 the application". 

But we should also not re=
commend a solution for general use if it has shortcomings.

This solution does not provide the servers with access to the orig=
inal IPv6 address, and thus does not allow them to do abuse detection, abus=
e mitigation, legal intercept, geolocation, and a host of other things.=A0T=
hese issues, coupled with scaling issues, make it unsuitable for real deplo=
yment except in very small websites. It also has the operational disadvanta=
ge that the complete logging information for a request (including the user&=
#39;s IPv6 address) are not in one place any more, but either in two places=
 (if the NAT does logging) or not available at all (if it doesn't).



You could run an experiment using this solution. You co=
uld run ipv6.company.com using this=
 solution. But you couldn't run www.=
company.com using this solution unless it was very very small.=A0So I d=
on't think that this working group should sanction such a solution; ins=
tead, we should provide implementors with tools and guidance for actually d=
eploying IPv6 in a way that will scale to their main websites.





--20cf3005dde6623ee004b1fdd0fc--

From Tina.Tsou.Zouting@huawei.com  Fri Nov 18 00:17:47 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C05011E80AA for ; Fri, 18 Nov 2011 00:17:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.052
X-Spam-Level: 
X-Spam-Status: No, score=-6.052 tagged_above=-999 required=5 tests=[AWL=0.546,  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 9mOgvFMPrRjz for ; Fri, 18 Nov 2011 00:17:45 -0800 (PST)
Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 8847D11E808B for ; Fri, 18 Nov 2011 00:17:44 -0800 (PST)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUU00DC2KDCYF@szxga04-in.huawei.com> for v6ops@ietf.org; Fri, 18 Nov 2011 16:17:36 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUU008BBKDCA3@szxga04-in.huawei.com> for v6ops@ietf.org; Fri, 18 Nov 2011 16:17:36 +0800 (CST)
Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AFB78176; Fri, 18 Nov 2011 16:17:35 +0800
Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 18 Nov 2011 16:17:27 +0800
Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.40]) by szxeml403-hub.china.huawei.com ([10.82.67.35]) with mapi id 14.01.0323.003; Fri, 18 Nov 2011 16:17:27 +0800
Date: Fri, 18 Nov 2011 08:17:27 +0000
From: Tina TSOU 
In-reply-to: 
X-Originating-IP: [10.212.245.210]
To: Lorenzo Colitti , Chongfeng Xie 
Message-id: 
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_upNKq/POgj9CqKMiIMFbCA)"
Content-language: en-US
Accept-Language: en-US, zh-CN
Thread-topic: [v6ops] Fwd: New Version Notification for draft-sunq-v6ops-contents-transition-02.txt
Thread-index: AQHMpcRN/jZITjrTv0i3Sw6wnO5EJZWxwDMAgACIqjA=
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
References:   <4EB05384.5000007@gmail.com>  <4EB54C85.4050909@bogus.com>  <4EBC6599.6030002@bogus.com>  
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] Fwd: New Version Notification for	draft-sunq-v6ops-contents-transition-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: Fri, 18 Nov 2011 08:17:47 -0000

--Boundary_(ID_upNKq/POgj9CqKMiIMFbCA)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

www.huawei.com for World IPv6 Day and ipv6.huawei.com for long term, both use dual stack DNS server and Web server, and China Telecom's dual stack network.


Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html


From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Lorenzo Colitti
Sent: Friday, November 18, 2011 4:06 PM
To: Chongfeng Xie
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Fwd: New Version Notification for draft-sunq-v6ops-contents-transition-02.txt

On Fri, Nov 18, 2011 at 15:32, Chongfeng Xie > wrote:
      From the standpoint viewpoint of carriers, NAT64 can server as a shared platform for ICPs in the early phase of transition, especially when the volume of IPv6 users in not big enough.  Carriers would NOT like to deploy a system which is involved with too much application-layer processing, we prefer a solution of network-layer, this is more consistent with the role of IETF  "above the wire and below the application".

But we should also not recommend a solution for general use if it has shortcomings.

This solution does not provide the servers with access to the original IPv6 address, and thus does not allow them to do abuse detection, abuse mitigation, legal intercept, geolocation, and a host of other things. These issues, coupled with scaling issues, make it unsuitable for real deployment except in very small websites. It also has the operational disadvantage that the complete logging information for a request (including the user's IPv6 address) are not in one place any more, but either in two places (if the NAT does logging) or not available at all (if it doesn't).

You could run an experiment using this solution. You could run ipv6.company.com using this solution. But you couldn't run www.company.com using this solution unless it was very very small. So I don't think that this working group should sanction such a solution; instead, we should provide implementors with tools and guidance for actually deploying IPv6 in a way that will scale to their main websites.

--Boundary_(ID_upNKq/POgj9CqKMiIMFbCA)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT













www.huawei.com for World IPv6 Day and ipv6.huawei.com for long term, both use dual
 stack DNS server and Web server, and China Telecom’s dual stack network.


 


 


Best Regards,


Tina TSOU


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


 


 




From: v6ops-bounces@ietf.org
 [mailto:v6ops-bounces@ietf.org] On Behalf Of Lorenzo Colitti

Sent: Friday, November 18, 2011 4:06 PM

To: Chongfeng Xie

Cc: v6ops@ietf.org

Subject: Re: [v6ops] Fwd: New Version Notification for draft-sunq-v6ops-contents-transition-02.txt




 




On Fri, Nov 18, 2011 at 15:32, Chongfeng Xie <xiechf01@gmail.com> wrote:


      From the standpoint viewpoint of carriers, NAT64 can server as a shared platform for ICPs in the early phase of transition, especially when the volume of IPv6 users in not big enough.  Carriers would NOT like to deploy a system which
 is involved with too much application-layer processing, we prefer a solution of network-layer, this is more consistent with the role of IETF  "above the wire and below the application".







But we should also not recommend a solution for general use if it has shortcomings.






 






This solution does not provide the servers with access to the original IPv6 address, and thus does not allow them to do abuse detection, abuse mitigation, legal intercept, geolocation, and a host of other things. These issues, coupled with
 scaling issues, make it unsuitable for real deployment except in very small websites. It also has the operational disadvantage that the complete logging information for a request (including the user's IPv6 address) are not in one place any more, but either
 in two places (if the NAT does logging) or not available at all (if it doesn't).






 






You could run an experiment using this solution. You could run
ipv6.company.com using this solution. But you couldn't run
www.company.com using this solution unless it was very very small. So I don't think that this working group should sanction such a solution; instead, we should provide implementors with tools and guidance for actually deploying
 IPv6 in a way that will scale to their main websites.










--Boundary_(ID_upNKq/POgj9CqKMiIMFbCA)--

From pch-b29AA871B@u-1.phicoh.com  Fri Nov 18 01:35:33 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6777521F84AD for ; Fri, 18 Nov 2011 01:35:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.491
X-Spam-Level: 
X-Spam-Status: No, score=-8.491 tagged_above=-999 required=5 tests=[AWL=0.108,  BAYES_00=-2.599, GB_I_LETTER=-2, 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 1QO1ibzNacFB for ; Fri, 18 Nov 2011 01:35:32 -0800 (PST)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 0A49E21F84AA for ; Fri, 18 Nov 2011 01:35:32 -0800 (PST)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #76) id m1RRKqv-0001iYC; Fri, 18 Nov 2011 10:35:21 +0100
Message-Id: 
To: Ray Hunter 
From: Philip Homburg 
Sender: pch-b29AA871B@u-1.phicoh.com
References: <20111115062859.14026.42405.idtracker@ietfa.amsl.com> <4EC2ABA8.4020303@globis.net> <4EC2FD24.1090303@gmail.com> <4EC37529.4070505@globis.net> <20111117013452.19F35179A55F@drugs.dv.isc.org> <4EC469E7.9010602@gmail.com> <20111117055040.E34FC179DAF9@drugs.dv.isc.org> <4EC4D7D1.8050601@globis.net> <4EC4EB86.80308@gmail.com> <4EC506CA.3020006@globis.net> 
In-reply-to: Your message of "Thu, 17 Nov 2011 14:06:18 +0100 ." <4EC506CA.3020006@globis.net> 
Date: Fri, 18 Nov 2011 10:35:11 +0100
Cc: v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-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: Fri, 18 Nov 2011 09:35:33 -0000

In your letter dated Thu, 17 Nov 2011 14:06:18 +0100 you wrote:
>The point is that the end node doesn't know which IPv6 source address to 
>use for which application and when, because there's no signaling today.
>
>The idea in the draft to distribute an RFC3484 type policy from routers 
>to end nodes should theoretically work in this case.
>
>However, the PA prefix could still be up (in RA) and still be valid in 
>IA_PD, and the local ISP interface UP, but packet forwarding via the ISP 
>link is down, meaning a very slow or incomplete takeover as the end node 
>has no indication of upstream failure.
>
>One option would be to ensure that on ISP link failure, the site egress 
>router could ensure that all leases and addresses from the PA prefix are 
>flushed from the whole site. But there's no flushing mechanism today, 
>only timer expiry. Or that a policy update can be pushed to all end 
>nodes: not easy.

A couple of things. In theory, DHCPv6 allows you push an update to the DHCPv6
client. So, invalidating prefixes and addresses is in theory possible.
The same goes for SLAAC: multicast a RA set the preferred time set to zero
and hosts will avoid that prefix.

Going one step further, routing protocols can be extended to include
information about different default routes (I did it just for RIPng, but it
should not be very hard for other routing protocols as well). If you do that
then the lack of a route default could prompt a router make a prefix not
preferred in RAs. (You want the kinds of 'policy routes' in your routing
protocol anyhow to allow routers to find the right exit for a packet in
more complex situations)



From Carl.Wuyts@technicolor.com  Fri Nov 18 01:52:09 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38BFE21F86B3 for ; Fri, 18 Nov 2011 01:52:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.365
X-Spam-Level: 
X-Spam-Status: No, score=-5.365 tagged_above=-999 required=5 tests=[AWL=0.634,  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 ulAu6Ldb0o3r for ; Fri, 18 Nov 2011 01:52:08 -0800 (PST)
Received: from na3sys009aog124.obsmtp.com (na3sys009aog124.obsmtp.com [74.125.149.151]) by ietfa.amsl.com (Postfix) with ESMTP id 4820521F8ABB for ; Fri, 18 Nov 2011 01:52:04 -0800 (PST)
Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob124.postini.com ([74.125.148.12]) with SMTP ID DSNKTsYqubu+2kXM6+lWVJq2OTVoBrjvUCPZ@postini.com; Fri, 18 Nov 2011 01:52:08 PST
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.192.1; Fri, 18 Nov 2011 10:50:13 +0100
Received: from MOPESMBX01.eu.thmulti.com ([169.254.155.121]) by MOPESMAILHC01.eu.thmulti.com ([141.11.100.25]) with mapi; Fri, 18 Nov 2011 10:50:21 +0100
From: Wuyts Carl 
To: "Hemant Singh (shemant)" , "Fred Baker (fred)" 
Date: Fri, 18 Nov 2011 10:50:19 +0100
Thread-Topic: [v6ops] 6rd Sunsetting
Thread-Index: AcylkXwIclPFHaH0SNm9o/dnqxRfGgAAZjAgAADOaUAAEBggAA==
Message-ID: <867F4B6A1672E541A94676D556793ACD0C2766D3CD@MOPESMBX01.eu.thmulti.com>
References: <68DAB112-6E32-45FE-9AB7-A34E64898F60@cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C30354436E@XMB-RCD-109.cisco.com><750BF7861EBBE048B3E648B4BB6E8F4F20DC41F6@crexc50p><5B6B2B64C9FE2A489045EEEADDAFF2C303544B01@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303544BAB@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303544BB0@XMB-RCD-109.cisco.com>
In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C303544BB0@XMB-RCD-109.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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Alexandre Cassen , "v6ops@ietf.org" , Claire Cheng 
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 18 Nov 2011 09:52:09 -0000

Submitted some Q on this earlier, but no response so far (or I must have mi=
ssed it, in this case I already apologize).

This draft sets some extra reqs for the CPE.
One of them is that the CPE must be able to cope with receiving the same pr=
efix through 6rd config and native.  So, the CPE RA Daemon will get the sam=
e prefix through 2 channels.  The RA daemon sees the prefix twice, but as i=
t is the same, what should the CPE do with the lifetime.
There's only 1 prefix to send to the hosts, so what lifetimes to use/how to=
 update the RA sending ? The most recent ones received ?  native preference=
 over 6rd ?  ... ?

tx

Carl Wuyts
GCD System Architect Networking
CONNECT DIVISION
carl.wuyts@technicolor.com
tel.: +32 3 443 65 90


Prins Boudewijnlaan 47=A0=A0-=A0=A02650 Edegem=A0=A0-=A0=A0Belgium
Technicolor Delivery Technologies Belgium NV
Registered office (maatschappelijke zetel): Prins Boudewijnlaan 47, 2650 Ed=
egem, Belgium
Company registration number (ondernemingsnummer): 0428837295 - RPR Antwerpe=
n

Help preserve the color of our world - Think before you print.





-----Original Message-----
From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of H=
emant Singh (shemant)
Sent: vrijdag 18 november 2011 3:07
To: Hemant Singh (shemant); Fred Baker (fred)
Cc: Alexandre Cassen; v6ops@ietf.org; Claire Cheng
Subject: Re: [v6ops] 6rd Sunsetting

Fred,

Sorry, there is MIF involved with 6rd and native IPv6 running concurrently.=
  However, the auto-generated static route text emailed below still works. =
 Soon as native IPv6 is active on the CPE when 6rd was running previously, =
the 6rd tunnel will be given lower priority than native IPv6 for data forwa=
rding.

Hemant

-----Original Message-----
From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of H=
emant Singh (shemant)
Sent: Friday, November 18, 2011 9:48 AM
To: Fred Baker (fred)
Cc: Alexandre Cassen; v6ops@ietf.org; Claire Cheng
Subject: Re: [v6ops] 6rd Sunsetting

RFC 6204 nor rfc6204bis recommend to not run a routing protocol between the=
 CPE WAN and the SP.  Neither does rfc6204 support a multihoming feature (M=
IF) on the WAN that is needed when the WAN includes at least two interfaces=
.  When rfc6204bis mentions a routing metric, it is simply an auto-created =
static IPv6 route internal to the CPE router.  Also the LAN routing protoco=
ls in rfc6204bis has been taken out and move to homenet. =20

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

From v6ops@globis.net  Fri Nov 18 04:11:13 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7441A21F8B35 for ; Fri, 18 Nov 2011 04:11:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.505
X-Spam-Level: 
X-Spam-Status: No, score=-3.505 tagged_above=-999 required=5 tests=[AWL=1.093,  BAYES_00=-2.599, GB_I_LETTER=-2, 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 cEP6XbAvDICP for ; Fri, 18 Nov 2011 04:11:12 -0800 (PST)
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 4A94C21F8ACA for ; Fri, 18 Nov 2011 04:11:12 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 7BFD28700CA; Fri, 18 Nov 2011 13:11:09 +0100 (CET)
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 MHhp82xHVZgG; Fri, 18 Nov 2011 13:11:03 +0100 (CET)
Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id C85B0870042; Fri, 18 Nov 2011 13:11:03 +0100 (CET)
Message-ID: <4EC64B52.5030907@globis.net>
Date: Fri, 18 Nov 2011 13:10:58 +0100
From: Ray Hunter 
User-Agent: Postbox Express 1.0.1 (Macintosh/20100705)
MIME-Version: 1.0
To: Philip Homburg 
References: <20111115062859.14026.42405.idtracker@ietfa.amsl.com> <4EC2ABA8.4020303@globis.net> <4EC2FD24.1090303@gmail.com> <4EC37529.4070505@globis.net> <20111117013452.19F35179A55F@drugs.dv.isc.org> <4EC469E7.9010602@gmail.com> <20111117055040.E34FC179DAF9@drugs.dv.isc.org> <4EC4D7D1.8050601@globis.net> <4EC4EB86.80308@gmail.com> <4EC506CA.3020006@globis.net> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------010403020403010208060509"
Cc: v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-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: Fri, 18 Nov 2011 12:11:13 -0000

This is a multi-part message in MIME format.
--------------010403020403010208060509
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Thanks. Got it now. RFC4861 6.3.4 p54 "If the new Lifetime value is 
zero, time-out the prefix immediately."

FYI People in corporate network are already used to dealing with 
multiple candidate default routes via separate protocols + local admin 
distance preference &/or route tagging.

A local RA flush via pio lifetime = 0 triggered by the absence of a 
specific default route tagged per egress router does look feasible.

Pushing an updated policy table to many nodes on a site via DHCPv6 on 
link failure doesn't sound very scalable (or fast). It would also seem 
to require that the DHCPv6 server track who is still active, so it can 
push the info.

Philip Homburg wrote:
> In your letter dated Thu, 17 Nov 2011 14:06:18 +0100 you wrote:
>    
>> The point is that the end node doesn't know which IPv6 source address to
>> use for which application and when, because there's no signaling today.
>>
>> The idea in the draft to distribute an RFC3484 type policy from routers
>> to end nodes should theoretically work in this case.
>>
>> However, the PA prefix could still be up (in RA) and still be valid in
>> IA_PD, and the local ISP interface UP, but packet forwarding via the ISP
>> link is down, meaning a very slow or incomplete takeover as the end node
>> has no indication of upstream failure.
>>
>> One option would be to ensure that on ISP link failure, the site egress
>> router could ensure that all leases and addresses from the PA prefix are
>> flushed from the whole site. But there's no flushing mechanism today,
>> only timer expiry. Or that a policy update can be pushed to all end
>> nodes: not easy.
>>      
>
> A couple of things. In theory, DHCPv6 allows you push an update to the DHCPv6
> client. So, invalidating prefixes and addresses is in theory possible.
> The same goes for SLAAC: multicast a RA set the preferred time set to zero
> and hosts will avoid that prefix.
>
> Going one step further, routing protocols can be extended to include
> information about different default routes (I did it just for RIPng, but it
> should not be very hard for other routing protocols as well). If you do that
> then the lack of a route default could prompt a router make a prefix not
> preferred in RAs. (You want the kinds of 'policy routes' in your routing
> protocol anyhow to allow routers to find the right exit for a packet in
> more complex situations)
>
>
>    


--------------010403020403010208060509
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit




  


Thanks. Got it now. RFC4861 6.3.4 p54 "If the new Lifetime value is
zero, time-out the prefix immediately."



FYI People in corporate network are already used to dealing with
multiple candidate default routes via separate protocols + local admin
distance preference &/or route tagging.



A local RA flush via pio lifetime = 0 triggered by the absence of a
specific default route tagged per egress router does look feasible.



Pushing an updated policy table to many nodes on a site via DHCPv6 on
link failure doesn't sound very scalable (or fast). It would also seem
to require that the DHCPv6 server track who is still active, so it can
push the info.



Philip Homburg wrote:


  
In your letter dated Thu, 17 Nov 2011 14:06:18 +0100 you wrote:
  

  

    
The point is that the end node doesn't know which IPv6 source address to 
use for which application and when, because there's no signaling today.

The idea in the draft to distribute an RFC3484 type policy from routers 
to end nodes should theoretically work in this case.

However, the PA prefix could still be up (in RA) and still be valid in 
IA_PD, and the local ISP interface UP, but packet forwarding via the ISP 
link is down, meaning a very slow or incomplete takeover as the end node 
has no indication of upstream failure.

One option would be to ensure that on ISP link failure, the site egress 
router could ensure that all leases and addresses from the PA prefix are 
flushed from the whole site. But there's no flushing mechanism today, 
only timer expiry. Or that a policy update can be pushed to all end 
nodes: not easy.
    

  

  

A couple of things. In theory, DHCPv6 allows you push an update to the DHCPv6
client. So, invalidating prefixes and addresses is in theory possible.
The same goes for SLAAC: multicast a RA set the preferred time set to zero
and hosts will avoid that prefix.

Going one step further, routing protocols can be extended to include
information about different default routes (I did it just for RIPng, but it
should not be very hard for other routing protocols as well). If you do that
then the lack of a route default could prompt a router make a prefix not
preferred in RAs. (You want the kinds of 'policy routes' in your routing
protocol anyhow to allow routers to find the right exit for a packet in
more complex situations)


  








--------------010403020403010208060509--

From ichiroumakino@gmail.com  Fri Nov 18 05:34:30 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A30821F8AF8 for ; Fri, 18 Nov 2011 05:34:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.546
X-Spam-Level: 
X-Spam-Status: No, score=-3.546 tagged_above=-999 required=5 tests=[AWL=0.053,  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 BtgMQokmw1H5 for ; Fri, 18 Nov 2011 05:34:29 -0800 (PST)
Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 88DF221F8AF7 for ; Fri, 18 Nov 2011 05:34:29 -0800 (PST)
Received: by wwe3 with SMTP id 3so1064753wwe.1 for ; Fri, 18 Nov 2011 05:34:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=HPy5vJ84x5VtYofiQeoUQ1AAIx6Fqhqh9R5dDtkhCEE=; b=TsZ5xQuujRJKZgtcdxYninZGDRkieQb6lT0SnsglGXrZek/toU+2hlu+m3Jcf9BQda javyQpLeCTEbaccM39sDhRXyWbFOAMcLVPIhAI4lTb6rzdWbruP/87/hkxCQUdjx9U/y eoi42MIzRwm4V45hiCcp7q5TECy46u4hiPrZ4=
Received: by 10.216.24.31 with SMTP id w31mr557421wew.16.1321623268562; Fri, 18 Nov 2011 05:34:28 -0800 (PST)
Received: from ams3-vpn-dhcp5098.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id ep16sm878400wbb.21.2011.11.18.05.34.23 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 18 Nov 2011 05:34:24 -0800 (PST)
Sender: Ole Troan 
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Ole Troan 
In-Reply-To: <867F4B6A1672E541A94676D556793ACD0C2766D3CD@MOPESMBX01.eu.thmulti.com>
Date: Fri, 18 Nov 2011 14:34:22 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <6A845C1B-1DC7-4826-8B0C-E354903ADDD5@employees.org>
References: <68DAB112-6E32-45FE-9AB7-A34E64898F60@cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C30354436E@XMB-RCD-109.cisco.com><750BF7861EBBE048B3E648B4BB6E8F4F20DC41F6@crexc50p><5B6B2B64C9FE2A489045EEEADDAFF2C303544B01@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303544BAB@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303544BB0@XMB-RCD-109.cisco.com> <867F4B6A1672E541A94676D556793ACD0C2766D3CD@MOPESMBX01.eu.thmulti.com>
To: Wuyts Carl 
X-Mailer: Apple Mail (2.1084)
Cc: Alexandre Cassen , "v6ops@ietf.org" , Claire Cheng 
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 18 Nov 2011 13:34:30 -0000

Carl,

> Submitted some Q on this earlier, but no response so far (or I must =
have missed it, in this case I already apologize).
>=20
> This draft sets some extra reqs for the CPE.
> One of them is that the CPE must be able to cope with receiving the =
same prefix through 6rd config and native.  So, the CPE RA Daemon will =
get the same prefix through 2 channels.  The RA daemon sees the prefix =
twice, but as it is the same, what should the CPE do with the lifetime.
> There's only 1 prefix to send to the hosts, so what lifetimes to =
use/how to update the RA sending ? The most recent ones received ?  =
native preference over 6rd ?  ... ?

you'll get one prefix from 6rd (inherits the IPv4 lease time) and one =
prefix from DHCP PD.
the correct answer must be the longest of the two.

cheers,
Ole=

From Carl.Wuyts@technicolor.com  Fri Nov 18 05:41:27 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 274F521F8B3E for ; Fri, 18 Nov 2011 05:41:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.687
X-Spam-Level: 
X-Spam-Status: No, score=-5.687 tagged_above=-999 required=5 tests=[AWL=0.912,  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 fJA-MJ6XI3Sy for ; Fri, 18 Nov 2011 05:41:26 -0800 (PST)
Received: from na3sys009aog119.obsmtp.com (na3sys009aog119.obsmtp.com [74.125.149.246]) by ietfa.amsl.com (Postfix) with ESMTP id E869921F8B35 for ; Fri, 18 Nov 2011 05:41:22 -0800 (PST)
Received: from mopesedge02.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob119.postini.com ([74.125.148.12]) with SMTP ID DSNKTsZgfysvNiNVAt1vNFxEodys5JD+u18/@postini.com; Fri, 18 Nov 2011 05:41:25 PST
Received: from MOPESMAILHC03.eu.thmulti.com (141.11.100.132) by mopesedge02.eu.thmulti.com (141.11.253.23) with Microsoft SMTP Server (TLS) id 8.3.192.1; Fri, 18 Nov 2011 14:39:37 +0100
Received: from MOPESMBX01.eu.thmulti.com ([169.254.155.121]) by MOPESMAILHC03.eu.thmulti.com ([141.11.100.132]) with mapi; Fri, 18 Nov 2011 14:39:54 +0100
From: Wuyts Carl 
To: Ole Troan 
Date: Fri, 18 Nov 2011 14:39:53 +0100
Thread-Topic: [v6ops] 6rd Sunsetting
Thread-Index: Acyl9s7p0TCi3/giTuOq1fG6Q+TcvAAAKs0A
Message-ID: <867F4B6A1672E541A94676D556793ACD0C2766D524@MOPESMBX01.eu.thmulti.com>
References: <68DAB112-6E32-45FE-9AB7-A34E64898F60@cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C30354436E@XMB-RCD-109.cisco.com><750BF7861EBBE048B3E648B4BB6E8F4F20DC41F6@crexc50p><5B6B2B64C9FE2A489045EEEADDAFF2C303544B01@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303544BAB@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303544BB0@XMB-RCD-109.cisco.com> <867F4B6A1672E541A94676D556793ACD0C2766D3CD@MOPESMBX01.eu.thmulti.com> <6A845C1B-1DC7-4826-8B0C-E354903ADDD5@employees.org>
In-Reply-To: <6A845C1B-1DC7-4826-8B0C-E354903ADDD5@employees.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Alexandre Cassen , "v6ops@ietf.org" , Claire Cheng 
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 18 Nov 2011 13:41:27 -0000

OK, so probably something to add to the draft then, if not, you might see d=
ifferent approaches I guess.

tx

Carl Wuyts
GCD System Architect Networking
CONNECT DIVISION
carl.wuyts@technicolor.com
tel.: +32 3 443 65 90


Prins Boudewijnlaan 47=A0=A0-=A0=A02650 Edegem=A0=A0-=A0=A0Belgium
Technicolor Delivery Technologies Belgium NV
Registered office (maatschappelijke zetel): Prins Boudewijnlaan 47, 2650 Ed=
egem, Belgium
Company registration number (ondernemingsnummer): 0428837295 - RPR Antwerpe=
n

Help preserve the color of our world - Think before you print.





-----Original Message-----
From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of Ole Troan
Sent: vrijdag 18 november 2011 14:34
To: Wuyts Carl
Cc: Hemant Singh (shemant); Fred Baker (fred); Alexandre Cassen; v6ops@ietf=
.org; Claire Cheng
Subject: Re: [v6ops] 6rd Sunsetting

Carl,

> Submitted some Q on this earlier, but no response so far (or I must have =
missed it, in this case I already apologize).
>=20
> This draft sets some extra reqs for the CPE.
> One of them is that the CPE must be able to cope with receiving the same =
prefix through 6rd config and native.  So, the CPE RA Daemon will get the s=
ame prefix through 2 channels.  The RA daemon sees the prefix twice, but as=
 it is the same, what should the CPE do with the lifetime.
> There's only 1 prefix to send to the hosts, so what lifetimes to use/how =
to update the RA sending ? The most recent ones received ?  native preferen=
ce over 6rd ?  ... ?

you'll get one prefix from 6rd (inherits the IPv4 lease time) and one prefi=
x from DHCP PD.
the correct answer must be the longest of the two.

cheers,
Ole

From jhw@apple.com  Fri Nov 18 10:05:03 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B39021F8AA8 for ; Fri, 18 Nov 2011 10:05:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.569
X-Spam-Level: 
X-Spam-Status: No, score=-106.569 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 uwM1D4IO2Gfo for ; Fri, 18 Nov 2011 10:05:02 -0800 (PST)
Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id 64B8621F8A97 for ; Fri, 18 Nov 2011 10:05:02 -0800 (PST)
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_x3g7hMuxt7N1WkD9hnMjbg)"
Received: from relay15.apple.com ([17.128.113.54]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTP id <0LUV001JIBC11MJ0@mail-out.apple.com> for v6ops@ietf.org; Fri, 18 Nov 2011 10:04:54 -0800 (PST)
X-AuditID: 11807136-b7c19ae0000072b0-00-4ec69e45c5d4
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 relay15.apple.com (Apple SCV relay) with SMTP id 23.97.29360.64E96CE4; Fri, 18 Nov 2011 10:04:54 -0800 (PST)
From: james woodyatt 
In-reply-to: 
Date: Fri, 18 Nov 2011 10:04:53 -0800
Message-id: 
References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com>  <5B6B2B64C9FE2A489045EEEADDAFF2C30354473D@XMB-RCD-109.cisco.com> <4EC455D6.8030601@bogus.com>   <7EB596BF-B175-40BF-ABC8-326599670B04@apple.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303544B88@XMB-RCD-109.cisco.com>  
To: Ole Troan 
X-Mailer: Apple Mail (2.1251.1)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFLMWRmVeSWpSXmKPExsUieJDXQddt3jE/g1lNmhaT21awWZw+tpfZ gcnj4LGPjB5LlvxkCmCK4rJJSc3JLEst0rdL4MrYfmonc8ExuYrXG/6xNTC+kupi5OSQEDCR +PnuMwuELSZx4d56ti5GLg4hgdlMEtdOPGUDSQgLGErc2H6JHcTmFTCWWHPrHVgDs0CCxIG/ m8FsNgEViW+X7zJ1MXJwcAo4Spx9XwkSZhFQlTj3eDU7SJgZqOR/Az/EFBuJs10/mCBWrWeR ePHkAzNIQgSo5vy0d4wQ98hLtHy9wzaBkW8Wks2zkGyGsLUlli18zTwLbIWOxOSFjKjCEPbH 80eYFjCyrWIULErNSaw0NNVLLCjISdVLzs/dxAgK0YZCsx2MO/7KHWIU4GBU4uGVnHbMT4g1 say4MvcQowQHs5IIr3Y3UIg3JbGyKrUoP76oNCe1+BCjNAeLkjhv6NajfkIC6YklqdmpqQWp RTBZJg5OqQbGtCY9foV9cgavvF1eNe3WbDyQp6g1vWnxev6LPlNVBDJF+Z1vadVXeH89VN/+ v+j25c4rPzYLbM2y3C302nVHRubdZ7eUn+2ONzCaf3iXkoDG3WlB7Pc3XXvd/OvowQgRe2tn o5oYm2uRYZyi3aprmlWKG7ODlSPCgjn4nBf0Ts/Pknwm1qTEUpyRaKjFXFScCAAPdzhMTQIA	AA==
Cc: IPv6 Operations 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 18 Nov 2011 18:05:03 -0000

--Boundary_(ID_x3g7hMuxt7N1WkD9hnMjbg)
Content-type: text/plain; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT

On Nov 17, 2011, at 22:42 , Ole Troan wrote:
> 
> a 6204 router MUST always do DHCP.

Not strictly true.  Any RFC 6204 conforming CPE router that never receives router advertisements with O=1 on its WAN interface is under no obligation to start its DHCPv6 client. 


--
j h woodyatt 



--Boundary_(ID_x3g7hMuxt7N1WkD9hnMjbg)
Content-type: text/html; CHARSET=US-ASCII
Content-transfer-encoding: quoted-printable


a 6204 router =
MUST always do DHCP.


Not strictly true. =
 Any RFC 6204 conforming CPE router that never receives router =
advertisements with O=3D1 on its WAN interface is under no obligation to =
start its DHCPv6 client. 


--
j h woodyatt <jhw@apple.com>





=

--Boundary_(ID_x3g7hMuxt7N1WkD9hnMjbg)--

From ichiroumakino@gmail.com  Fri Nov 18 10:08:44 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D813221F8AF3 for ; Fri, 18 Nov 2011 10:08:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.549
X-Spam-Level: 
X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050,  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 fcWm70jDtVFX for ; Fri, 18 Nov 2011 10:08:44 -0800 (PST)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2AB9921F8AB8 for ; Fri, 18 Nov 2011 10:08:44 -0800 (PST)
Received: by wwe5 with SMTP id 5so4683046wwe.13 for ; Fri, 18 Nov 2011 10:08:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=GhUu1vusUsg/u8zDpph9xt6PibVPqMWbmr6ZsDoK3bs=; b=pl077uas/MYcroVEHuHaY7I+5MHKBzUxfxQJ4Zhl+/TsXX2A1hrHj3HnZ+k2mk1Evt veheRUxoMh8Cz7ecEW+b7myrd8F3hHTJ2S8iGDg79uMVb6ZIrWV5alN+irqqmM9PF6Lw 7th4pXzQi/MpCpnP5wuvuaeXVz+62jGOflMKo=
Received: by 10.227.197.71 with SMTP id ej7mr2748827wbb.15.1321639723380; Fri, 18 Nov 2011 10:08:43 -0800 (PST)
Received: from dhcp-10-55-83-205.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id x8sm711118wix.17.2011.11.18.10.08.39 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 18 Nov 2011 10:08:39 -0800 (PST)
Sender: Ole Troan 
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Ole Troan 
In-Reply-To: 
Date: Fri, 18 Nov 2011 19:08:37 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <8D342733-88E6-45D3-B388-E001AE32CD77@employees.org>
References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com>  <5B6B2B64C9FE2A489045EEEADDAFF2C30354473D@XMB-RCD-109.cisco.com> <4EC455D6.8030601@bogus.com>   <7EB596BF-B175-40BF-ABC8-326599670B04@apple.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303544B88@XMB-RCD-109.cisco.com>   
To: james woodyatt 
X-Mailer: Apple Mail (2.1084)
Cc: IPv6 Operations 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 18 Nov 2011 18:08:44 -0000

James,

>> a 6204 router MUST always do DHCP.
>=20
> Not strictly true.  Any RFC 6204 conforming CPE router that never =
receives router advertisements with O=3D1 on its WAN interface is under =
no obligation to start its DHCPv6 client.=20

strictly true.
   WPD-4:  The IPv6 CE router MUST always initiate DHCPv6 prefix
           delegation, regardless of the M and O flags in a received
           Router Advertisement message.

cheers,
Ole


From john_brzozowski@cable.comcast.com  Fri Nov 18 10:25:04 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B983921F84ED for ; Fri, 18 Nov 2011 10:25:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.463
X-Spam-Level: 
X-Spam-Status: No, score=-108.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I9ToFuctGbpY for ; Fri, 18 Nov 2011 10:25:04 -0800 (PST)
Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id F309D21F84DD for ; Fri, 18 Nov 2011 10:25:03 -0800 (PST)
Received: from ([24.40.55.41]) by pacdcimo01.cable.comcast.com with ESMTP  id 5503620.146656120; Fri, 18 Nov 2011 13:24:59 -0500
Received: from PACDCEXMB01.cable.comcast.com ([fe80::3cf0:9cac:6c2a:7359]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%11]) with mapi id 14.01.0339.001; Fri, 18 Nov 2011 13:24:59 -0500
From: "Brzozowski, John" 
To: Ted Lemon , Lorenzo Colitti 
Thread-Topic: [v6ops] DHCPv6 option for MAX_SOL_RT
Thread-Index: AQHMpPoLB5vqkfAeIE2CH2QcxPX8a5WxBRwAgALJlwA=
Date: Fri, 18 Nov 2011 18:24:58 +0000
Message-ID: 
In-Reply-To: <3E09E3FD-51F7-4FA9-A173-ADDAB07871E9@nominum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.13.0.110805
x-originating-ip: [203.69.99.16]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <5960EBF9A4CF7F429523AB0B7170788E@cable.comcast.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "v6ops@ietf.org" , Ralph Droms 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 18 Nov 2011 18:25:04 -0000

On 11/17/11 3:50 PM, "Ted Lemon"  wrote:


>On Nov 17, 2011, at 3:25 PM, "Lorenzo Colitti"  wrote:
>> If you're a CE router, it doesn't matter what RAs you see. CE routers
>>explicitly ignore IPv6 RAs when determining whether to start DHCPv6 PD
>>or not,
>
>So if you're a CE router that's plugged into an ethernet that's got your
>upstream on it, and your upstream goes away, but your switch doesn't tell
>you because it doesn't know you need to know, then we have a problem.
>Is that a possible scenario for CE routers?   It seems to me that
>typically a CE router is going to see a carrier transition of some kind
>when moving to a different provider network.
[jjmb] this is something that could and does happen in real deployments.

>
>BTW, I actually am not entirely convinced that Ralph's proposal is a good
>idea=8Bit's a quick hack to work around a one-time operational problem tha=
t
>we will be stuck with forever.   However, I'd like us to focus on real
>reasons for liking it or disliking it.   I think the "carrier transition
>won't be noticed" issue is easily addressed and not a very likely
>scenario anyway.   I would prefer to focus on real problems.
[jjmb] I do not agree, many of the assumptions being made assume steady
state, full deployment.  Incremental enablement must be considered, no one
is going to flash enable IPv6.

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


From john_brzozowski@cable.comcast.com  Fri Nov 18 10:28:20 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5520511E809D for ; Fri, 18 Nov 2011 10:28:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.135
X-Spam-Level: 
X-Spam-Status: No, score=-101.135 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_35=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 kdgeNwylvJ4t for ; Fri, 18 Nov 2011 10:28:19 -0800 (PST)
Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id 8B1EF11E8099 for ; Fri, 18 Nov 2011 10:28:19 -0800 (PST)
Received: from ([24.40.55.42]) by copdcimo01.cable.comcast.com with ESMTP  id 5503630.62039134; Fri, 18 Nov 2011 11:28:27 -0700
Received: from PACDCEXMB01.cable.comcast.com ([fe80::3cf0:9cac:6c2a:7359]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%11]) with mapi id 14.01.0339.001; Fri, 18 Nov 2011 13:28:29 -0500
From: "Brzozowski, John" 
To: "Hemant Singh (shemant)" , James Woodyatt , Lorenzo Colitti 
Thread-Topic: [v6ops] DHCPv6 option for MAX_SOL_RT
Thread-Index: AQHMpPoLB5vqkfAeIE2CH2QcxPX8a5WyAcUAgAAaSYCAAbOPAA==
Date: Fri, 18 Nov 2011 18:28:10 +0000
Message-ID: 
In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C303544B88@XMB-RCD-109.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.13.0.110805
x-originating-ip: [24.40.55.71]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <29E28A58E010324C8BF912DE1A508E26@cable.comcast.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: IPv6 Operations 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 18 Nov 2011 18:28:20 -0000

>From an operators point of view who is deploying IPv6 I expect the M=3DO=3D=
1
to have meaning.

Default routes seem important, as such router advertisements are relevant.
=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
John Jason Brzozowski
Comcast Cable
e) mailto:john_brzozowski@cable.comcast.com
o) 609-377-6594
m) 484-962-0060
w) http://www.comcast6.net
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D




On 11/18/11 8:29 AM, "Hemant Singh (shemant)"  wrote:

>James,
>=20
>RFC 3633 specifies acquiring an IA_PD between a requesting and a
>delegating router.  Thus such a protocol between two routers could care
>less if the delegating router issued an RA to the requesting router or if
>an RA issued, why care about the M and the O bits.  The CE router WAN
>interface does support an unnumbered model in which the WAN interface has
>only an IPv6 link-local.  Then the WAN has to initiate DHCPv6 to acquire
>an IA_PD.
>=20
>Hemant
>=20
>From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of
>james woodyatt
>Sent: Thursday, November 17, 2011 5:55 PM
>To: Lorenzo Colitti
>Cc: IPv6 Operations
>Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
>
>
>=20
>On Nov 16, 2011, at 11:25 PM, Lorenzo Colitti wrote:
>
>
>
>
>If you're a CE router, it doesn't matter what RAs you see. CE routers
>explicitly ignore IPv6 RAs when determining whether to start DHCPv6 PD or
>not,
>
>=20
>This is news to me.  The way I read RFC 6204 and I-D.ietf-v6ops-6204bis,
>CPE routers are not required to ignore the M and O bits in IPv6 router
>advertisements.  As far as I can see, CPE router implementations that
>wait to receive a router advertisement on the WAN with O=3D1 before
>starting the DHCPv6 client still conforms to the recommendations and
>complies with the forthcoming IPv6Ready CPE Router Interoperability test
>specification.
>
>=20
>
>
>--
>
>james woodyatt 
>
>member of technical staff, core os networking
>
>
>
>
>
>=20
>
>_______________________________________________
>v6ops mailing list
>v6ops@ietf.org
>https://www.ietf.org/mailman/listinfo/v6ops


From john_brzozowski@cable.comcast.com  Fri Nov 18 10:32:47 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A93A011E80AD for ; Fri, 18 Nov 2011 10:32:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.463
X-Spam-Level: 
X-Spam-Status: No, score=-108.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oNaceyIvpiD6 for ; Fri, 18 Nov 2011 10:32:41 -0800 (PST)
Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id 7296511E8099 for ; Fri, 18 Nov 2011 10:32:41 -0800 (PST)
Received: from ([24.40.55.42]) by pacdcimo01.cable.comcast.com with ESMTP  id 5503620.146657782; Fri, 18 Nov 2011 13:32:38 -0500
Received: from PACDCEXMB01.cable.comcast.com ([fe80::3cf0:9cac:6c2a:7359]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%11]) with mapi id 14.01.0339.001; Fri, 18 Nov 2011 13:32:57 -0500
From: "Brzozowski, John" 
To: Ted Lemon , James Woodyatt 
Thread-Topic: [v6ops] DHCPv6 option for MAX_SOL_RT
Thread-Index: AQHMpPoLB5vqkfAeIE2CH2QcxPX8a5WyAcUAgAAaSYCAACRPAIAAKVmAgAFnJgA=
Date: Fri, 18 Nov 2011 18:32:37 +0000
Message-ID: 
In-Reply-To: <5DF4B5B0-8A53-4829-81B5-2131AECF1430@nominum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.13.0.110805
x-originating-ip: [203.69.99.16]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: IPv6 Operations 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 18 Nov 2011 18:32:47 -0000

Some implementations and deployments were planned before the semantics
behind the M/O bits were altered, so I would argue that they have value
and meaning.

The point here is we should not be prohibiting behavior.

John
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
John Jason Brzozowski
Comcast Cable
e) mailto:john_brzozowski@cable.comcast.com
o) 609-377-6594
m) 484-962-0060
w) http://www.comcast6.net
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D




On 11/18/11 1:07 PM, "Ted Lemon"  wrote:

>On Nov 18, 2011, at 10:39 AM, "james woodyatt"  wrote:
>> None of that implies that CPE routers are required or even expected, by
>>IETF, to ignore the M and O bits in router advertisements received at
>>their WAN interfaces.  I still don't see any language anywhere in an
>>IETF document that says CPE routers are not permitted to wait until they
>>receive a router advertisement with O=3D1 before initiating the DHCPv6
>>client on their WAN interface to request any options, including the
>>IA_PD option.
>
>Since we don't know what the M and O bits do, I think it's a bit
>questionable to use them in this way.   I mean, I can hack my router so
>that your CPE device will not fail to configure itself, but that probably
>won't be possible anymore once my IPv6 upstream is coming from my actual
>ISP.
>_______________________________________________
>v6ops mailing list
>v6ops@ietf.org
>https://www.ietf.org/mailman/listinfo/v6ops


From john_brzozowski@cable.comcast.com  Fri Nov 18 10:34:39 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F123311E80C7 for ; Fri, 18 Nov 2011 10:34:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.435
X-Spam-Level: 
X-Spam-Status: No, score=-101.435 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 NzDhEMn8HsPJ for ; Fri, 18 Nov 2011 10:34:37 -0800 (PST)
Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id A4F1111E80C5 for ; Fri, 18 Nov 2011 10:34:36 -0800 (PST)
Received: from ([24.40.55.42]) by copdcimo01.cable.comcast.com with ESMTP  id 5503630.62040440; Fri, 18 Nov 2011 11:34:42 -0700
Received: from PACDCEXMB01.cable.comcast.com ([fe80::3cf0:9cac:6c2a:7359]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%11]) with mapi id 14.01.0339.001; Fri, 18 Nov 2011 13:34:44 -0500
From: "Brzozowski, John" 
To: Ole Troan , Ted Lemon 
Thread-Topic: [v6ops] DHCPv6 option for MAX_SOL_RT
Thread-Index: AQHMpPoLB5vqkfAeIE2CH2QcxPX8a5WxBRwAgAF/jACAAUy0gA==
Date: Fri, 18 Nov 2011 18:34:25 +0000
Message-ID: 
In-Reply-To: <223C79CD-05B2-4488-BE8D-59861997B484@employees.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.13.0.110805
x-originating-ip: [24.40.55.71]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <7117C392CCA1814BAF710EBE6DF8C557@cable.comcast.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "v6ops@ietf.org" , Ralph Droms 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 18 Nov 2011 18:34:39 -0000

FWIW - short lease timer is a common practice in broadband networks,
however, this is operationally challenging at times if not automated.  It
would be ideal if this were properly addressed and discussed.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
John Jason Brzozowski
Comcast Cable
e) mailto:john_brzozowski@cable.comcast.com
o) 609-377-6594
m) 484-962-0060
w) http://www.comcast6.net
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D




On 11/18/11 2:43 PM, "Ole Troan"  wrote:

>Ted,
>
>>> If you're a CE router, it doesn't matter what RAs you see. CE routers
>>>explicitly ignore IPv6 RAs when determining whether to start DHCPv6 PD
>>>or not,
>>=20
>> So if you're a CE router that's plugged into an ethernet that's got
>>your upstream on it, and your upstream goes away, but your switch
>>doesn't tell you because it doesn't know you need to know, then we have
>>a problem.   Is that a possible scenario for CE routers?   It seems to
>>me that typically a CE router is going to see a carrier transition of
>>some kind when moving to a different provider network.
>
>not getting a L2 event is common. there are multiple proposals to deal
>with that from Ethernet OAM, short DHCP lease timers to BFD echo. not
>sure any of that applies much to this discussion.
>
>> BTW, I actually am not entirely convinced that Ralph's proposal is a
>>good idea=8Bit's a quick hack to work around a one-time operational
>>problem that we will be stuck with forever.   However, I'd like us to
>>focus on real reasons for liking it or disliking it.   I think the
>>"carrier transition won't be noticed" issue is easily addressed and not
>>a very likely scenario anyway.   I would prefer to focus on real
>>problems.
>
>cheers,
>Ole
>
>
>_______________________________________________
>v6ops mailing list
>v6ops@ietf.org
>https://www.ietf.org/mailman/listinfo/v6ops


From john_brzozowski@cable.comcast.com  Fri Nov 18 10:37:00 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD18111E80C5 for ; Fri, 18 Nov 2011 10:37:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.463
X-Spam-Level: 
X-Spam-Status: No, score=-108.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xSp8aKISw-HU for ; Fri, 18 Nov 2011 10:37:00 -0800 (PST)
Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id C947011E80C3 for ; Fri, 18 Nov 2011 10:36:59 -0800 (PST)
Received: from ([24.40.55.40]) by pacdcimo01.cable.comcast.com with ESMTP  id 5503620.146657198; Fri, 18 Nov 2011 13:29:33 -0500
Received: from PACDCEXMB01.cable.comcast.com ([fe80::3cf0:9cac:6c2a:7359]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%11]) with mapi id 14.01.0339.001; Fri, 18 Nov 2011 13:29:26 -0500
From: "Brzozowski, John" 
To: james woodyatt , Hemant Singh 
Thread-Topic: [v6ops] DHCPv6 option for MAX_SOL_RT
Thread-Index: AQHMpPoLB5vqkfAeIE2CH2QcxPX8a5WyAcUAgAAaSYCAACRPAIABj5SA
Date: Fri, 18 Nov 2011 18:29:25 +0000
Message-ID: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.13.0.110805
x-originating-ip: [203.69.99.16]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <7669C5A5F36F84469DD69AD374FED2C0@cable.comcast.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: IPv6 Operations 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 18 Nov 2011 18:37:00 -0000

I agree with James and we should not prohibit the behavior.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
John Jason Brzozowski
Comcast Cable
e) mailto:john_brzozowski@cable.comcast.com
o) 609-377-6594
m) 484-962-0060
w) http://www.comcast6.net
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D




On 11/18/11 10:39 AM, "james woodyatt"  wrote:

>On Nov 17, 2011, at 16:29 , Hemant Singh (shemant) wrote:
>
>
>RFC 3633 specifies acquiring an IA_PD between a requesting and a
>delegating router.  Thus such a protocol between two routers could care
>less if the delegating router issued an RA to the requesting router or if
>an RA issued, why care about the M and the O bits.  The CE router WAN
>interface does support an unnumbered model in which the WAN interface has
>only an IPv6 link-local.  Then the WAN has to initiate DHCPv6 to acquire
>an IA_PD.
>
>
>
>None of that implies that CPE routers are required or even expected, by
>IETF, to ignore the M and O bits in router advertisements received at
>their WAN interfaces.  I still don't see any language anywhere in an IETF
>document that says CPE routers are not permitted to wait until they
>receive a router advertisement with O=3D1 before initiating the DHCPv6
>client on their WAN interface to request any options, including the IA_PD
>option.
>
>(For the record, I am still opposed to the adoption of any such language.)
>
>
>--
>j h woodyatt 
>
>
>
>_______________________________________________
>v6ops mailing list
>v6ops@ietf.org
>https://www.ietf.org/mailman/listinfo/v6ops


From jhw@apple.com  Fri Nov 18 10:41:40 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A9BD1F0C40 for ; Fri, 18 Nov 2011 10:41:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.57
X-Spam-Level: 
X-Spam-Status: No, score=-106.57 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 8GC6oMpPyegT for ; Fri, 18 Nov 2011 10:41:39 -0800 (PST)
Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id C60EF1F0C34 for ; Fri, 18 Nov 2011 10:41:39 -0800 (PST)
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_trSCz+po6Vwnz2WNPAeXTQ)"
Received: from relay14.apple.com ([17.128.113.52]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LUV0012CD9E1MO0@mail-out.apple.com> for v6ops@ietf.org; Fri, 18 Nov 2011 10:41:38 -0800 (PST)
X-AuditID: 11807134-b7ce4ae0000052e8-db-4ec6a6e2c89f
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 relay14.apple.com (Apple SCV relay) with SMTP id 8C.8F.21224.2E6A6CE4; Fri, 18 Nov 2011 10:41:38 -0800 (PST)
From: james woodyatt 
In-reply-to: <8D342733-88E6-45D3-B388-E001AE32CD77@employees.org>
Date: Fri, 18 Nov 2011 10:41:38 -0800
Message-id: <6DA3F2E0-1E37-4D61-B035-49A77EFF17E4@apple.com>
References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com>  <5B6B2B64C9FE2A489045EEEADDAFF2C30354473D@XMB-RCD-109.cisco.com> <4EC455D6.8030601@bogus.com>   <7EB596BF-B175-40BF-ABC8-326599670B04@apple.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303544B88@XMB-RCD-109.cisco.com>    <8D342733-88E6-45D3-B388-E001AE32CD77@employees.org>
To: Ole Troan 
X-Mailer: Apple Mail (2.1251.1)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJLMWRmVeSWpSXmKPExsUieJDXQffRsmN+Bu9nallMblvBZnH62F5m ByaPg8c+MnosWfKTKYApissmJTUnsyy1SN8ugStj2pzNbAXPVSseN69gamDcotDFyMkhIWAi MfPeLmYIW0ziwr31bF2MXBxCArOZJHqOb2ECSQgLGErc2H6JHcTmFTCWWHPrHUsXIwcHs0CC xO0eQ5Awm4CKxLfLd8HKOQUcJRavOMgCYrMIqEr837iDCaJcReJ/Az/EFBuJdztesUCsmsoq cWL7X1aQhAhQzflp7xgh7pGXaPl6h20CI98sJJtnIWwGCTMLaEssW/iaGSKsIzF5ISOqMIT9 8fwRpgWMbKsYBYtScxIrDU30EgsKclL1kvNzNzGCArSh0GQH48Gf/IcYBTgYlXh4Jacd8xNi TSwrrsw9xCjBwawkwqvdDRTiTUmsrEotyo8vKs1JLT7EKM3BoiTOG7L1qJ+QQHpiSWp2ampB ahFMlomDU6qBMfHl45M1U7Qevrodx1LqtZfzf2zHjqlawW6SbcuTzj1fl3Lh13zNJecr/i16 9y/ZiLXde4V7YsWxY3kyHg3JVV4b/jovFRUV2b+w6y/3h46WKftryzq+MB5UT1VZFvTcudDJ b5bfzF3nGDs2P7bJzytNWO16qk2v7npKcvzLTRK3ZR+8FOtQVmIpzkg01GIuKk4EAIJBgS5M	AgAA
Cc: IPv6 Operations 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 18 Nov 2011 18:41:40 -0000

--Boundary_(ID_trSCz+po6Vwnz2WNPAeXTQ)
Content-type: text/plain; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT

On Nov 18, 2011, at 10:08 , Ole Troan wrote:
> 
>>> a 6204 router MUST always do DHCP.
>> 
>> Not strictly true.  Any RFC 6204 conforming CPE router that never receives router advertisements with O=1 on its WAN interface is under no obligation to start its DHCPv6 client. 
> 
> strictly true.
>   WPD-4:  The IPv6 CE router MUST always initiate DHCPv6 prefix
>           delegation, regardless of the M and O flags in a received
>           Router Advertisement message.

You're right.  I got ahead of myself.  However, any RFC 6204 conforming CPE router that never receives router advertisements on its WAN interface is under no obligation to start its DHCPv6 client.

It makes no sense to me that RFC 6204 expressly tells CPE router vendors they MUST start the DHCPv6 client even when O=0 in all router advertisements previously received on the WAN interface.  What's the purpose of that? Why on Earth would an operator need for CPE routers to start their DHCPv6 clients when the router advertisements they're sending have O=0?


--
j h woodyatt 



--Boundary_(ID_trSCz+po6Vwnz2WNPAeXTQ)
Content-type: text/html; CHARSET=US-ASCII
Content-transfer-encoding: quoted-printable



a 6204 router MUST always do =
DHCP.

Not strictly =
true.  Any RFC 6204 conforming CPE router that never receives =
router advertisements with O=3D1 on its WAN interface is under no =
obligation to start its DHCPv6 client. 

strictly =
true.
   WPD-4:  The IPv6 CE router MUST always =
initiate DHCPv6 prefix
 =
          delegation, =
regardless of the M and O flags in a received
 =
          Router =
Advertisement message.

You're right. =
 I got ahead of myself.  However, any RFC 6204 conforming =
CPE router that never receives router advertisements on its WAN =
interface is under no obligation to start its DHCPv6 =
client.

It makes no sense to me that RFC 6204 =
expressly tells CPE router vendors they MUST start the DHCPv6 client =
even when O=3D0 in all router advertisements previously =
received on the WAN interface.  What's the purpose of that? =
Why on Earth would an operator need for CPE routers to start their =
DHCPv6 clients when the router advertisements they're sending have =
O=3D0?


--
j h woodyatt <jhw@apple.com>





=

--Boundary_(ID_trSCz+po6Vwnz2WNPAeXTQ)--

From bs7652@att.com  Fri Nov 18 10:45:51 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B85B21F85EF for ; Fri, 18 Nov 2011 10:45:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.148
X-Spam-Level: 
X-Spam-Status: No, score=-106.148 tagged_above=-999 required=5 tests=[AWL=-0.149, 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 ntNRvIPSMVcE for ; Fri, 18 Nov 2011 10:45:50 -0800 (PST)
Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id 225E021F8562 for ; Fri, 18 Nov 2011 10:45:50 -0800 (PST)
X-Env-Sender: bs7652@att.com
X-Msg-Ref: server-2.tower-120.messagelabs.com!1321641937!49949613!1
X-Originating-IP: [144.160.20.146]
X-StarScan-Version: 6.3.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6637 invoked from network); 18 Nov 2011 18:45:38 -0000
Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-2.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 18 Nov 2011 18:45:38 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pAIIiAUd019135; Fri, 18 Nov 2011 13:44:11 -0500
Received: from 01AL10015010625.AD.BLS.COM (sfldmibbcraeninet1.pmtr.mwst.att.com [10.231.16.33]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pAIIdL1x012223; Fri, 18 Nov 2011 13:44:03 -0500
Received: from 01NC27689010625.AD.BLS.COM ([90.144.44.200]) by 01AL10015010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 18 Nov 2011 12:43:00 -0600
Received: from 01NC27689010650.AD.BLS.COM ([90.144.44.120]) by 01NC27689010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 18 Nov 2011 13:43:00 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 18 Nov 2011 13:43:46 -0500
Message-ID: <750BF7861EBBE048B3E648B4BB6E8F4F20DC4FEA@crexc50p>
In-Reply-To: <8D342733-88E6-45D3-B388-E001AE32CD77@employees.org>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] DHCPv6 option for MAX_SOL_RT
Thread-Index: AcymHQmvvP7v40ucTui3LlCwe76YmwAAz4nQ
References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com><5B6B2B64C9FE2A489045EEEADDAFF2C30354473D@XMB-RCD-109.cisco.com><4EC455D6.8030601@bogus.com><7EB596BF-B175-40BF-ABC8-326599670B04@apple.com><5B6B2B64C9FE2A489045EEEADDAFF2C303544B88@XMB-RCD-109.cisco.com> <8D342733-88E6-45D3-B388-E001AE32CD77@employees.org>
From: "STARK, BARBARA H" 
To: "Ole Troan" , "james woodyatt" 
X-OriginalArrivalTime: 18 Nov 2011 18:43:00.0780 (UTC) FILETIME=[E5E196C0:01CCA621]
Cc: IPv6 Operations 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 18 Nov 2011 18:45:51 -0000

The rest of us (well, me and the MSO guys and I think Hemant and Wes)
agreed to change the language of WPD-4. That's why the current 6204bis
draft has:
   WPD-4:  The IPv6 CE router MUST always initiate DHCPv6 prefix
           delegation, regardless of the M and O flags in a received
           Router Advertisement message.

I still think this is a reasonable change.
It doesn't preclude the previous behavior of doing DHCPv6 IA_PD,
regardless of M/O. It just doesn't mandate it. Now it only mandates it
if M or O=3D1. The current language leaves it up to the vendor (or other
specs) as to what to do when M=3DO=3D0, or no received RA. Devices =
compliant
under the old requirement are still compliant under the new requirement.

I'm comfortable with the current 6204bis language. I think it allows the
MSOs the ability to decrease the number of CE routers that are doing
all-the-time DHCPv6, while allowing me the freedom to have my CE routers
behave per the previous requirements. It doesn't make previously
compliant devices suddenly non-compliant. It also doesn't bring to zero
the quantity of CE routers that are causing the storm. But hopefully it
decreases the number sufficiently to allow for the desired controlled
introduction architecture to function without being brought to its knees
by CE routers who want their IA_PD and want it now.

Please, can't we agree on this compromise? Pretty please?
Barbara

> -----Original Message-----
> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
> Of Ole Troan
> Sent: Friday, November 18, 2011 1:09 PM
> To: james woodyatt
> Cc: IPv6 Operations
> Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
>=20
> James,
>=20
> >> a 6204 router MUST always do DHCP.
> >
> > Not strictly true.  Any RFC 6204 conforming CPE router that never
> receives router advertisements with O=3D1 on its WAN interface is =
under
> no obligation to start its DHCPv6 client.
>=20
> strictly true.
>    WPD-4:  The IPv6 CE router MUST always initiate DHCPv6 prefix
>            delegation, regardless of the M and O flags in a received
>            Router Advertisement message.
>=20
> cheers,
> Ole
>=20
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

From jhw@apple.com  Fri Nov 18 10:52:19 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 690D521F8A95 for ; Fri, 18 Nov 2011 10:52:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.572
X-Spam-Level: 
X-Spam-Status: No, score=-106.572 tagged_above=-999 required=5 tests=[AWL=0.028, 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 pcj19-sC-RhA for ; Fri, 18 Nov 2011 10:52:19 -0800 (PST)
Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id F073E21F858D for ; Fri, 18 Nov 2011 10:52:18 -0800 (PST)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII
Received: from relay14.apple.com ([17.128.113.52]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LUV00JTCDP1NZ34@mail-out.apple.com> for v6ops@ietf.org; Fri, 18 Nov 2011 10:51:48 -0800 (PST)
X-AuditID: 11807134-b7ce4ae0000052e8-9d-4ec6a944a143
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 relay14.apple.com (Apple SCV relay) with SMTP id AA.A3.21224.449A6CE4; Fri, 18 Nov 2011 10:51:48 -0800 (PST)
From: james woodyatt 
In-reply-to: <750BF7861EBBE048B3E648B4BB6E8F4F20DC4FEA@crexc50p>
Date: Fri, 18 Nov 2011 10:51:48 -0800
Message-id: <6EE83074-6822-4CA3-A7AC-3EB1BB96AF01@apple.com>
References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com>  <5B6B2B64C9FE2A489045EEEADDAFF2C30354473D@XMB-RCD-109.cisco.com> <4EC455D6.8030601@bogus.com>   <7EB596BF-B175-40BF-ABC8-326599670B04@apple.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303544B88@XMB-RCD-109.cisco.com>    <8D342733-88E6-45D3-B388-E001AE32CD77@employees.org> <750BF7861EBBE048B3E648B4BB6E8F4F20DC4FEA@crexc50p>
To: "STARK, BARBARA H" 
X-Mailer: Apple Mail (2.1251.1)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCLMWRmVeSWpSXmKPExsUieJDXQddl5TE/g+Y/YhaT/v5ktDh9bC+z A5PHy/45jB5LlvxkCmCK4rJJSc3JLEst0rdL4Mp40jWPseA3e8WSXxsYGxifs3YxcnJICJhI zO26zwxhi0lcuLeerYuRi0NIYDaTxKft09hAEsIChhI3tl9iB7F5BYwl1tx6xwJiMwtoSdz4 95IJxGYTUJH4dvkumM0p4CDx+MwHsKEsAqoSE3bOYOxi5ACqV5H438AP0aotsWzha2aIkTYS z1bcYofYe5JV4vPtW2C7RATUJVZNmw51qLxEy9c7bBMY+WchOWMWkjNmIZm7gJF5FaNgUWpO YqWhiV5iQUFOql5yfu4mRlDYNRSa7GA8+JP/EKMAB6MSD6/ktGN+QqyJZcWVuYcYJTiYlUR4 W5YDhXhTEiurUovy44tKc1KLDzFKc7AoifOGbD3qJySQnliSmp2aWpBaBJNl4uCUamBs1I12 v6rVF77J+w7D0krL1OeJJxuqFuQlyL52yfoRJj5RkE1a8Mz0Jb4Bax6x2MstthP2ubZ5RhqL +aucZ3O23OG779vAmdu1+f7+n1c4P754zXVqSnCnwJWuzkhHG9/+lPRjb+b+39C86l3SH4Mv GXZ5BjMF+oTmOlcnObyNXqgokBpdrarEUpyRaKjFXFScCAAtRZ7nNwIAAA==
Cc: IPv6 Operations 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 18 Nov 2011 18:52:19 -0000

On Nov 18, 2011, at 10:43 , STARK, BARBARA H wrote:

> The rest of us (well, me and the MSO guys and I think Hemant and Wes)
> agreed to change the language of WPD-4. That's why the current 6204bis
> draft has:
>   WPD-4:  The IPv6 CE router MUST always initiate DHCPv6 prefix
>           delegation, regardless of the M and O flags in a received
>           Router Advertisement message.

That's the text from RFC 6204.  Currently, I-D.draft-ietf-v6ops-6204bis-02 says this:

   WPD-4:  By default, the IPv6 CE router MUST initiate DHCPv6 prefix
           delegation when either the M or O flags are set to 1 in a
           received Router Advertisement message.

That's better, but it's still confusing.  It's invalid to send M=1 and O=0, so it suffices to say this:

   WPD-4:  By default, the IPv6 CE router MUST initiate DHCPv6 prefix
           delegation when the O flag is set to 1 in a received Router
           Advertisement message.


--
j h woodyatt 



From wbeebee@cisco.com  Fri Nov 18 10:53:26 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14F4D21F8AE1 for ; Fri, 18 Nov 2011 10:53:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.807
X-Spam-Level: 
X-Spam-Status: No, score=-3.807 tagged_above=-999 required=5 tests=[AWL=0.125,  BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wYdPd74aUAqI for ; Fri, 18 Nov 2011 10:53:25 -0800 (PST)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4C08521F8AD9 for ; Fri, 18 Nov 2011 10:53:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2871; q=dns/txt; s=iport; t=1321642405; x=1322852005; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=AxlqwGCCqOWm2ElEdlvzg1g4WBmqm+hQCXg21+JK6RI=; b=NIILRZqimMpHCDexZWjLL2I5752YKnKCmJNtZTPZ7LKEl4frHDuelzB0 46Fxu18HyZSDDisXm2OtEX9DHg2rl5lVKPaDIzgznaEVtNa/tT0lG9Kx6 5V66bodmsu2Im/jEf2DCBGK9U3cy8hs7pibVv8Za5VEXCudQAs1xWIdsJ Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ap8CABEppk6tJXG9/2dsb2JhbACQRY4CEgJ4iHCLZZI0hhkEhlCJQYQ4gnODeINw
X-IronPort-AV: E=Sophos;i="4.69,534,1315180800"; d="scan'208";a="34915460"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-9.cisco.com with ESMTP; 18 Nov 2011 18:53:25 +0000
Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id pAIIrO87019396;  Fri, 18 Nov 2011 18:53:24 GMT
Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 18 Nov 2011 12:53:24 -0600
Received: from 161.44.175.128 ([161.44.175.128]) by XMB-RCD-201.cisco.com ([72.163.62.208]) with Microsoft Exchange Server HTTP-DAV ;  Fri, 18 Nov 2011 18:53:24 +0000
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Fri, 18 Nov 2011 13:53:22 -0500
From: Wes Beebee 
To: "STARK, BARBARA H" , Ole Troan , james woodyatt 
Message-ID: 
Thread-Topic: [v6ops] DHCPv6 option for MAX_SOL_RT
Thread-Index: AcymHQmvvP7v40ucTui3LlCwe76YmwAAz4nQAADEFa4=
In-Reply-To: <750BF7861EBBE048B3E648B4BB6E8F4F20DC4FEA@crexc50p>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 18 Nov 2011 18:53:24.0507 (UTC) FILETIME=[59A6C6B0:01CCA623]
Cc: IPv6 Operations 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 18 Nov 2011 18:53:26 -0000

Barbara -

The text in draft-ietf-v6ops-6204bis-02 is:
   WPD-4:  By default, the IPv6 CE router MUST initiate DHCPv6 prefix
           delegation when either the M or O flags are set to 1 in a
           received Router Advertisement message.

- Wes


On 11/18/11 1:43 PM, "STARK, BARBARA H"  wrote:

> The rest of us (well, me and the MSO guys and I think Hemant and Wes)
> agreed to change the language of WPD-4. That's why the current 6204bis
> draft has:
>    WPD-4:  The IPv6 CE router MUST always initiate DHCPv6 prefix
>            delegation, regardless of the M and O flags in a received
>            Router Advertisement message.
> 
> I still think this is a reasonable change.
> It doesn't preclude the previous behavior of doing DHCPv6 IA_PD,
> regardless of M/O. It just doesn't mandate it. Now it only mandates it
> if M or O=1. The current language leaves it up to the vendor (or other
> specs) as to what to do when M=O=0, or no received RA. Devices compliant
> under the old requirement are still compliant under the new requirement.
> 
> I'm comfortable with the current 6204bis language. I think it allows the
> MSOs the ability to decrease the number of CE routers that are doing
> all-the-time DHCPv6, while allowing me the freedom to have my CE routers
> behave per the previous requirements. It doesn't make previously
> compliant devices suddenly non-compliant. It also doesn't bring to zero
> the quantity of CE routers that are causing the storm. But hopefully it
> decreases the number sufficiently to allow for the desired controlled
> introduction architecture to function without being brought to its knees
> by CE routers who want their IA_PD and want it now.
> 
> Please, can't we agree on this compromise? Pretty please?
> Barbara
> 
>> -----Original Message-----
>> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
>> Of Ole Troan
>> Sent: Friday, November 18, 2011 1:09 PM
>> To: james woodyatt
>> Cc: IPv6 Operations
>> Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
>> 
>> James,
>> 
>>>> a 6204 router MUST always do DHCP.
>>> 
>>> Not strictly true.  Any RFC 6204 conforming CPE router that never
>> receives router advertisements with O=1 on its WAN interface is under
>> no obligation to start its DHCPv6 client.
>> 
>> strictly true.
>>    WPD-4:  The IPv6 CE router MUST always initiate DHCPv6 prefix
>>            delegation, regardless of the M and O flags in a received
>>            Router Advertisement message.
>> 
>> cheers,
>> Ole
>> 
>> _______________________________________________
>> 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 wbeebee@cisco.com  Fri Nov 18 10:59:10 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90D3C21F8B07 for ; Fri, 18 Nov 2011 10:59:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.821
X-Spam-Level: 
X-Spam-Status: No, score=-3.821 tagged_above=-999 required=5 tests=[AWL=0.111,  BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UrbhrQyiDkAe for ; Fri, 18 Nov 2011 10:59:09 -0800 (PST)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id D8ADF21F8B05 for ; Fri, 18 Nov 2011 10:59:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wbeebee@cisco.com; l=1826; q=dns/txt; s=iport; t=1321642750; x=1322852350; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=UfspSOV1Xp7dQcVO5GQHcvQmm2fK6tFHz3YjdssIE84=; b=Y7U89r4EEgRe7MpM8IQ5yxl2S1Nvhx/O4+C3QMlRLMFj6QGTPCF0pJB4 Z1Jky8j50ygH7EKoq8/DtHjpulkiahqPs6clr6KUA6BT+hKF1HatP4wy6 oMnB0+iMx9/f3noWjc7m2+Eto1flRWkE3Fhl3DMXZfVE6gIPMSJechKdn 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Am4FANOqxk6tJV2d/2dsb2JhbABDqjMCgQWBcgEBAQMBAQEBDwEnAgExCwUNAQgYVTABAQQOBSKHYQiYDwGeWQSKFwSIF4wihUaDO4RvhC8
X-IronPort-AV: E=Sophos;i="4.69,534,1315180800"; d="scan'208";a="37352427"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 18 Nov 2011 18:58:51 +0000
Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id pAIIwoVi021603;  Fri, 18 Nov 2011 18:58:50 GMT
Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 18 Nov 2011 12:58:50 -0600
Received: from 161.44.175.128 ([161.44.175.128]) by XMB-RCD-201.cisco.com ([72.163.62.208]) with Microsoft Exchange Server HTTP-DAV ;  Fri, 18 Nov 2011 18:58:50 +0000
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Fri, 18 Nov 2011 13:58:48 -0500
From: Wes Beebee 
To: james woodyatt , "STARK, BARBARA H" 
Message-ID: 
Thread-Topic: [v6ops] DHCPv6 option for MAX_SOL_RT
Thread-Index: AcymJBp3+HnHgVdMrEqqoszWkDGt6A==
In-Reply-To: <6EE83074-6822-4CA3-A7AC-3EB1BB96AF01@apple.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 18 Nov 2011 18:58:50.0628 (UTC) FILETIME=[1C08E440:01CCA624]
Cc: IPv6 Operations 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 18 Nov 2011 18:59:10 -0000

James,

>From RFC 4861:

      M              1-bit "Managed address configuration" flag.  When
                     set, it indicates that addresses are available via
                     Dynamic Host Configuration Protocol [DHCPv6].

                     If the M flag is set, the O flag is redundant and
                     can be ignored because DHCPv6 will return all
                     available configuration information.

So, M=1 and O=0 is valid, the interpretation is that both addresses and
other information is available.

- Wes


On 11/18/11 1:51 PM, "james woodyatt"  wrote:

> On Nov 18, 2011, at 10:43 , STARK, BARBARA H wrote:
> 
>> The rest of us (well, me and the MSO guys and I think Hemant and Wes)
>> agreed to change the language of WPD-4. That's why the current 6204bis
>> draft has:
>>   WPD-4:  The IPv6 CE router MUST always initiate DHCPv6 prefix
>>           delegation, regardless of the M and O flags in a received
>>           Router Advertisement message.
> 
> That's the text from RFC 6204.  Currently, I-D.draft-ietf-v6ops-6204bis-02
> says this:
> 
>    WPD-4:  By default, the IPv6 CE router MUST initiate DHCPv6 prefix
>            delegation when either the M or O flags are set to 1 in a
>            received Router Advertisement message.
> 
> That's better, but it's still confusing.  It's invalid to send M=1 and O=0, so
> it suffices to say this:
> 
>    WPD-4:  By default, the IPv6 CE router MUST initiate DHCPv6 prefix
>            delegation when the O flag is set to 1 in a received Router
>            Advertisement message.
> 
> 
> --
> j h woodyatt 
> 
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


From ichiroumakino@gmail.com  Fri Nov 18 11:00:32 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A84D11E8083 for ; Fri, 18 Nov 2011 11:00:32 -0800 (PST)
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 jl8qCPki9-jV for ; Fri, 18 Nov 2011 11:00:31 -0800 (PST)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 67FE921F8B15 for ; Fri, 18 Nov 2011 11:00:31 -0800 (PST)
Received: by wwe5 with SMTP id 5so4745898wwe.13 for ; Fri, 18 Nov 2011 11:00:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=Yt31srWHUcDf1glMJ1nkJtmuxjLK+KRgm5z5UoVZYnY=; b=QN2M99lEJIZ8ab90kgHocxFCteR9DroJbF/0MRTqUtdDjrAZibmYUVC2QaCrTt62Oo xzlpmWkMD3MMLWkpPCjcSIXtXeM4gPu3uuP+xn4K2K7NR0bLze5wlUBRYf4oWu93I1XN EMvyRj1l9q3/afo+0uV0oxfCq89wI1KQMtStA=
Received: by 10.216.165.212 with SMTP id e62mr729058wel.42.1321642830476; Fri, 18 Nov 2011 11:00:30 -0800 (PST)
Received: from dhcp-10-55-83-205.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id d17sm1819208wbh.19.2011.11.18.11.00.28 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 18 Nov 2011 11:00:29 -0800 (PST)
Sender: Ole Troan 
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Ole Troan 
In-Reply-To: <6DA3F2E0-1E37-4D61-B035-49A77EFF17E4@apple.com>
Date: Fri, 18 Nov 2011 20:00:27 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <0C8C16BF-7075-4FC1-A6E0-7EC9017C9A34@employees.org>
References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com>  <5B6B2B64C9FE2A489045EEEADDAFF2C30354473D@XMB-RCD-109.cisco.com> <4EC455D6.8030601@bogus.com>   <7EB596BF-B175-40BF-ABC8-326599670B04@apple.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303544B88@XMB-RCD-109.cisco.com>    <8D342733-88E6-45D3-B388-E001AE32CD77@employees.org> <6DA3F2E0-1E37-4D61-B035-49A77EFF17E4@apple.com>
To: james woodyatt 
X-Mailer: Apple Mail (2.1084)
Cc: IPv6 Operations 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 18 Nov 2011 19:00:32 -0000

James,

>>>> a 6204 router MUST always do DHCP.
>>>=20
>>> Not strictly true.  Any RFC 6204 conforming CPE router that never =
receives router advertisements with O=3D1 on its WAN interface is under =
no obligation to start its DHCPv6 client.=20
>>=20
>> strictly true.
>>   WPD-4:  The IPv6 CE router MUST always initiate DHCPv6 prefix
>>           delegation, regardless of the M and O flags in a received
>>           Router Advertisement message.
>=20
> You're right.  I got ahead of myself.  However, any RFC 6204 =
conforming CPE router that never receives router advertisements on its =
WAN interface is under no obligation to start its DHCPv6 client.
>=20
> It makes no sense to me that RFC 6204 expressly tells CPE router =
vendors they MUST start the DHCPv6 client even when O=3D0 in all router =
advertisements previously received on the WAN interface.  What's the =
purpose of that? Why on Earth would an operator need for CPE routers to =
start their DHCPv6 clients when the router advertisements they're =
sending have O=3D0?

let me see if I can recount the reasoning behind:
 - DHCP PD is a router to router protocol. 3633 was never written to =
have a dependency on M/O bits.
   routers do not listen to RAs.
 - the issue of addressing / prefix delegation is different from =
routing.
   default router discovery was not specified in 3633. there are =
multiple other ways of doing it.
   there are deployments that do not use RAs.
 - as the dual host/router mode on an interface is not described in any =
RFC, the text in 6204 is in unchartered
   territory, we didn't want to violate text in 4861/4862 too much
 - on a point to point WAN link there is no need for router discovery.

cheers,
Ole=

From ichiroumakino@gmail.com  Fri Nov 18 11:04:42 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94F3A1F0C5A for ; Fri, 18 Nov 2011 11:04:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.553
X-Spam-Level: 
X-Spam-Status: No, score=-3.553 tagged_above=-999 required=5 tests=[AWL=0.046,  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 va7wTMWoGs3B for ; Fri, 18 Nov 2011 11:04:42 -0800 (PST)
Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id BE20B1F0C5C for ; Fri, 18 Nov 2011 11:04:41 -0800 (PST)
Received: by eyg24 with SMTP id 24so4424196eyg.31 for ; Fri, 18 Nov 2011 11:04:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=YmNPBrept997Fa+0xgMiRRW+h4km1//+t8oZwYljDf0=; b=Lf71Z+Z7/8nEI+LL2Gej4KbSA26QQHh/SEYCqNm68z/PuVH7OpeYvQWuf6r6eu5yT9 B8GFbGWmHYhB7LQlFLDylqc2OW/MSHS4hrOydAtZLvtcQQOzFsc3obCdln1SAEYfFKzf V73Ncm1uBTjDEnHbL8BZoYcGKxMRYcca7WU2s=
Received: by 10.180.95.132 with SMTP id dk4mr4513051wib.30.1321643079447; Fri, 18 Nov 2011 11:04:39 -0800 (PST)
Received: from dhcp-10-55-83-205.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id v6sm801564wix.1.2011.11.18.11.04.38 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 18 Nov 2011 11:04:38 -0800 (PST)
Sender: Ole Troan 
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Ole Troan 
In-Reply-To: <750BF7861EBBE048B3E648B4BB6E8F4F20DC4FEA@crexc50p>
Date: Fri, 18 Nov 2011 20:04:37 +0100
Content-Transfer-Encoding: 7bit
Message-Id: 
References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com><5B6B2B64C9FE2A489045EEEADDAFF2C30354473D@XMB-RCD-109.cisco.com><4EC455D6.8030601@bogus.com><7EB596BF-B175-40BF-ABC8-326599670B04@apple.com><5B6B2B64C9FE2A489045EEEADDAFF2C303544B88@XMB-RCD-109.cisco.com> <8D342733-88E6-45D3-B388-E001AE32CD77@employees.org> <750BF7861EBBE048B3E648B4BB6E8F4F20DC4FEA@crexc50p>
To: "STARK, BARBARA H" 
X-Mailer: Apple Mail (2.1084)
Cc: IPv6 Operations 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 18 Nov 2011 19:04:42 -0000

Barbara,

> The rest of us (well, me and the MSO guys and I think Hemant and Wes)
> agreed to change the language of WPD-4. That's why the current 6204bis
> draft has:
>   WPD-4:  The IPv6 CE router MUST always initiate DHCPv6 prefix
>           delegation, regardless of the M and O flags in a received
>           Router Advertisement message.
> 
> I still think this is a reasonable change.
> It doesn't preclude the previous behavior of doing DHCPv6 IA_PD,
> regardless of M/O. It just doesn't mandate it. Now it only mandates it
> if M or O=1. The current language leaves it up to the vendor (or other
> specs) as to what to do when M=O=0, or no received RA. Devices compliant
> under the old requirement are still compliant under the new requirement.
> 
> I'm comfortable with the current 6204bis language. I think it allows the
> MSOs the ability to decrease the number of CE routers that are doing
> all-the-time DHCPv6, while allowing me the freedom to have my CE routers
> behave per the previous requirements. It doesn't make previously
> compliant devices suddenly non-compliant. It also doesn't bring to zero
> the quantity of CE routers that are causing the storm. But hopefully it
> decreases the number sufficiently to allow for the desired controlled
> introduction architecture to function without being brought to its knees
> by CE routers who want their IA_PD and want it now.
> 
> Please, can't we agree on this compromise? Pretty please?

I'm afraid not. the text is just fuzzing the issue.
what are the use case for a CPE not trying to acquire a prefix?

I do expect things to change as a "homenet router" gets defined.

let's hold off on 6204bis until we have real new requirements.

cheers,
Ole

From Ted.Lemon@nominum.com  Fri Nov 18 13:41:22 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF33B1F0C8A for ; Fri, 18 Nov 2011 13:41:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.571
X-Spam-Level: 
X-Spam-Status: No, score=-106.571 tagged_above=-999 required=5 tests=[AWL=0.028, 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 bhddc2uvyGSJ for ; Fri, 18 Nov 2011 13:41:22 -0800 (PST)
Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 017C31F0C86 for ; Fri, 18 Nov 2011 13:41:21 -0800 (PST)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKTsbRAZigRPw8Jwp3lYC/8aHZNPx9qiI1@postini.com; Fri, 18 Nov 2011 13:41:22 PST
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id CF4E21B827A for ; Fri, 18 Nov 2011 13:41:19 -0800 (PST)
Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id C0E1519005D; Fri, 18 Nov 2011 13:41:19 -0800 (PST) (envelope-from Ted.Lemon@nominum.com)
Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.01.0339.001; Fri, 18 Nov 2011 13:41:19 -0800
From: Ted Lemon 
To: "Brzozowski, John" 
Thread-Topic: [v6ops] DHCPv6 option for MAX_SOL_RT
Thread-Index: AQHMpBVS9v5OyU3dDEaf8biIUoZIIJWwMYMAgACJcgCAAANuAP//e/aAgAD3r4D//4ENOoACyZ0A//+wwBc=
Date: Fri, 18 Nov 2011 21:41:19 +0000
Message-ID: <87A53A02-346E-425F-9BE2-ED4709B0FE85@nominum.com>
References: <3E09E3FD-51F7-4FA9-A173-ADDAB07871E9@nominum.com>, 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "v6ops@ietf.org" , Ralph Droms 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 18 Nov 2011 21:41:22 -0000

On Nov 19, 2011, at 2:25 AM, "Brzozowski, John"  wrote:
>> I think the "carrier transition
>> won't be noticed" issue is easily addressed and not a very likely
>> scenario anyway.   I would prefer to focus on real problems.
> [jjmb] I do not agree, many of the assumptions being made assume steady
> state, full deployment.  Incremental enablement must be considered, no on=
e
> is going to flash enable IPv6.

By "carrier" here I meant "layer one carrier" (e.g., ethernet carrier), not=
 "ISP."   Transition means "the network went away and came back," not "the =
ISP slowly or quickly deployed IPv6."   :)


From john_brzozowski@cable.comcast.com  Fri Nov 18 21:19:33 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7573D21F8B4F for ; Fri, 18 Nov 2011 21:19:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.499
X-Spam-Level: 
X-Spam-Status: No, score=-104.499 tagged_above=-999 required=5 tests=[AWL=3.064, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, 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 1pYMQ+xyhluA for ; Fri, 18 Nov 2011 21:19:32 -0800 (PST)
Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id 70E6821F8B56 for ; Fri, 18 Nov 2011 21:19:32 -0800 (PST)
Received: from ([24.40.55.41]) by pacdcimo01.cable.comcast.com with ESMTP  id 5503620.146711009; Sat, 19 Nov 2011 00:19:24 -0500
Received: from PACDCEXMB01.cable.comcast.com ([fe80::3cf0:9cac:6c2a:7359]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%11]) with mapi id 14.01.0339.001; Sat, 19 Nov 2011 00:19:24 -0500
From: "Brzozowski, John" 
To: "STARK, BARBARA H" , =?iso-8859-1?Q?Ole_Tr=F8an?= , James Woodyatt 
Thread-Topic: [v6ops] DHCPv6 option for MAX_SOL_RT
Thread-Index: AcymHQmvB5vqkfAeIE2CH2QcxPX8awAAz4nQACpXiYA=
Date: Sat, 19 Nov 2011 05:19:22 +0000
Message-ID: 
In-Reply-To: <750BF7861EBBE048B3E648B4BB6E8F4F20DC4FEA@crexc50p>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.13.0.110805
x-originating-ip: [24.40.55.70]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <97B51E7C267EAE4C84399B8F84B9B0D7@cable.comcast.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: IPv6 Operations 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 19 Nov 2011 05:19:33 -0000

Barbara,

I think we are close if not already there.  IMO if we are both aligned I
think we can move this work forward and focus on getting 6204bis out the
door.  I have been working closely with Chris Donley and appreciate your
willingness to collaborate.

John
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
John Jason Brzozowski
Comcast Cable
e) mailto:john_brzozowski@cable.comcast.com
o) 609-377-6594
m) 484-962-0060
w) http://www.comcast6.net
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D




On 11/19/11 2:43 AM, "STARK, BARBARA H"  wrote:

>The rest of us (well, me and the MSO guys and I think Hemant and Wes)
>agreed to change the language of WPD-4. That's why the current 6204bis
>draft has:
>   WPD-4:  The IPv6 CE router MUST always initiate DHCPv6 prefix
>           delegation, regardless of the M and O flags in a received
>           Router Advertisement message.
>
>I still think this is a reasonable change.
>It doesn't preclude the previous behavior of doing DHCPv6 IA_PD,
>regardless of M/O. It just doesn't mandate it. Now it only mandates it
>if M or O=3D1. The current language leaves it up to the vendor (or other
>specs) as to what to do when M=3DO=3D0, or no received RA. Devices complia=
nt
>under the old requirement are still compliant under the new requirement.
>
>I'm comfortable with the current 6204bis language. I think it allows the
>MSOs the ability to decrease the number of CE routers that are doing
>all-the-time DHCPv6, while allowing me the freedom to have my CE routers
>behave per the previous requirements. It doesn't make previously
>compliant devices suddenly non-compliant. It also doesn't bring to zero
>the quantity of CE routers that are causing the storm. But hopefully it
>decreases the number sufficiently to allow for the desired controlled
>introduction architecture to function without being brought to its knees
>by CE routers who want their IA_PD and want it now.
>
>Please, can't we agree on this compromise? Pretty please?
>Barbara
>
>> -----Original Message-----
>> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
>> Of Ole Troan
>> Sent: Friday, November 18, 2011 1:09 PM
>> To: james woodyatt
>> Cc: IPv6 Operations
>> Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
>>=20
>> James,
>>=20
>> >> a 6204 router MUST always do DHCP.
>> >
>> > Not strictly true.  Any RFC 6204 conforming CPE router that never
>> receives router advertisements with O=3D1 on its WAN interface is under
>> no obligation to start its DHCPv6 client.
>>=20
>> strictly true.
>>    WPD-4:  The IPv6 CE router MUST always initiate DHCPv6 prefix
>>            delegation, regardless of the M and O flags in a received
>>            Router Advertisement message.
>>=20
>> cheers,
>> Ole
>>=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 john_brzozowski@cable.comcast.com  Fri Nov 18 21:19:40 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B36151F0C63 for ; Fri, 18 Nov 2011 21:19:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.97
X-Spam-Level: 
X-Spam-Status: No, score=-105.97 tagged_above=-999 required=5 tests=[AWL=2.493, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mqeEw8+G3m3e for ; Fri, 18 Nov 2011 21:19:39 -0800 (PST)
Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id ACDA121F8B56 for ; Fri, 18 Nov 2011 21:19:39 -0800 (PST)
Received: from ([24.40.55.40]) by pacdcimo01.cable.comcast.com with ESMTP  id 5503620.146711014; Sat, 19 Nov 2011 00:19:36 -0500
Received: from PACDCEXMB01.cable.comcast.com ([fe80::3cf0:9cac:6c2a:7359]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%11]) with mapi id 14.01.0339.001; Sat, 19 Nov 2011 00:19:36 -0500
From: "Brzozowski, John" 
To: Ole Troan , Barbara Stark 
Thread-Topic: [v6ops] DHCPv6 option for MAX_SOL_RT
Thread-Index: AcymHQmvB5vqkfAeIE2CH2QcxPX8awAAz4nQAAui4IAAHuoBgA==
Date: Sat, 19 Nov 2011 05:19:35 +0000
Message-ID: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.13.0.110805
x-originating-ip: [24.40.55.70]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <82EB92DDCA271D46A113AAB466C95A19@cable.comcast.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: IPv6 Operations 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 19 Nov 2011 05:19:40 -0000

I agree with Barbara that we should move RFC6204bis forward.  I see no
reason why we should hold RFC6204bis any longer especially if two of the
primary customers for the work are in agreement.

John
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
John Jason Brzozowski
Comcast Cable
e) mailto:john_brzozowski@cable.comcast.com
o) 609-377-6594
m) 484-962-0060
w) http://www.comcast6.net
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D




On 11/19/11 3:04 AM, "Ole Troan"  wrote:

>Barbara,
>
>> The rest of us (well, me and the MSO guys and I think Hemant and Wes)
>> agreed to change the language of WPD-4. That's why the current 6204bis
>> draft has:
>>   WPD-4:  The IPv6 CE router MUST always initiate DHCPv6 prefix
>>           delegation, regardless of the M and O flags in a received
>>           Router Advertisement message.
>>=20
>> I still think this is a reasonable change.
>> It doesn't preclude the previous behavior of doing DHCPv6 IA_PD,
>> regardless of M/O. It just doesn't mandate it. Now it only mandates it
>> if M or O=3D1. The current language leaves it up to the vendor (or other
>> specs) as to what to do when M=3DO=3D0, or no received RA. Devices compl=
iant
>> under the old requirement are still compliant under the new requirement.
>>=20
>> I'm comfortable with the current 6204bis language. I think it allows the
>> MSOs the ability to decrease the number of CE routers that are doing
>> all-the-time DHCPv6, while allowing me the freedom to have my CE routers
>> behave per the previous requirements. It doesn't make previously
>> compliant devices suddenly non-compliant. It also doesn't bring to zero
>> the quantity of CE routers that are causing the storm. But hopefully it
>> decreases the number sufficiently to allow for the desired controlled
>> introduction architecture to function without being brought to its knees
>> by CE routers who want their IA_PD and want it now.
>>=20
>> Please, can't we agree on this compromise? Pretty please?
>
>I'm afraid not. the text is just fuzzing the issue.
>what are the use case for a CPE not trying to acquire a prefix?
>
>I do expect things to change as a "homenet router" gets defined.
>
>let's hold off on 6204bis until we have real new requirements.
>
>cheers,
>Ole
>_______________________________________________
>v6ops mailing list
>v6ops@ietf.org
>https://www.ietf.org/mailman/listinfo/v6ops


From john_brzozowski@cable.comcast.com  Fri Nov 18 21:19:48 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B56C81F0C6F for ; Fri, 18 Nov 2011 21:19:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.23
X-Spam-Level: 
X-Spam-Status: No, score=-103.23 tagged_above=-999 required=5 tests=[AWL=-1.495, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 3UrxbBhwt6oi for ; Fri, 18 Nov 2011 21:19:48 -0800 (PST)
Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id C073B1F0C67 for ; Fri, 18 Nov 2011 21:19:44 -0800 (PST)
Received: from ([24.40.55.41]) by copdcimo01.cable.comcast.com with ESMTP  id 5503630.62110716; Fri, 18 Nov 2011 22:19:55 -0700
Received: from PACDCEXMB01.cable.comcast.com ([fe80::3cf0:9cac:6c2a:7359]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%11]) with mapi id 14.01.0339.001; Sat, 19 Nov 2011 00:19:38 -0500
From: "Brzozowski, John" 
To: Ted Lemon 
Thread-Topic: [v6ops] DHCPv6 option for MAX_SOL_RT
Thread-Index: AQHMpPoLB5vqkfAeIE2CH2QcxPX8a5WxBRwAgALJlwD//7DHgIAAzBWA
Date: Sat, 19 Nov 2011 05:19:37 +0000
Message-ID: 
In-Reply-To: <87A53A02-346E-425F-9BE2-ED4709B0FE85@nominum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.13.0.110805
x-originating-ip: [24.40.55.70]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <9A673833A752694FBC100A5DEDB82608@cable.comcast.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "v6ops@ietf.org" , Ralph Droms 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 19 Nov 2011 05:19:48 -0000

Ack, I clearly misinterpreted.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
John Jason Brzozowski
Comcast Cable
e) mailto:john_brzozowski@cable.comcast.com
o) 609-377-6594
m) 484-962-0060
w) http://www.comcast6.net
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D




On 11/19/11 5:41 AM, "Ted Lemon"  wrote:

>On Nov 19, 2011, at 2:25 AM, "Brzozowski, John"
> wrote:
>>> I think the "carrier transition
>>> won't be noticed" issue is easily addressed and not a very likely
>>> scenario anyway.   I would prefer to focus on real problems.
>> [jjmb] I do not agree, many of the assumptions being made assume steady
>> state, full deployment.  Incremental enablement must be considered, no
>>one
>> is going to flash enable IPv6.
>
>By "carrier" here I meant "layer one carrier" (e.g., ethernet carrier),
>not "ISP."   Transition means "the network went away and came back," not
>"the ISP slowly or quickly deployed IPv6."   :)
>


From fred@cisco.com  Sat Nov 19 05:28:41 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A63E21F8753 for ; Sat, 19 Nov 2011 05:28:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.462
X-Spam-Level: 
X-Spam-Status: No, score=-109.462 tagged_above=-999 required=5 tests=[AWL=1.137, 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 03D2jdHsG7jR for ; Sat, 19 Nov 2011 05:28:40 -0800 (PST)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 6325B21F8461 for ; Sat, 19 Nov 2011 05:28:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=613; q=dns/txt; s=iport; t=1321709320; x=1322918920; h=from:content-transfer-encoding:subject:date:references: to:message-id:mime-version; bh=HVN2KcyvRJJwFZ+lfu0aElPpBHwGJT68RtP5YDGu+sI=; b=M2GkUnl5H2GNCrxF1IzI1C61kNXIUktWxNfmZWweq+lsG0PsMnYLGl8f nPSF2xN6M/bm7nJZ9pyKZ5f/YKW6mPPXKBjAIgP9+Y1DHeHQIUfrGLB/H 33Z5+rVALr9a1kLiVS5XEnjeU4KBwJrWmFjobtHUqnuWb6icIzgxJtZ9i o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EAMuux05Io8UR/2dsb2JhbABEqj+BBYFyAQEBAwEBAg8BJ0QLHAMBAi8oJQIIBhMih2EIl1EBnX8EiTRjBIgYigWCH4U9jFU
X-IronPort-AV: E=Sophos;i="4.69,538,1315180800"; d="scan'208";a="60032594"
Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-2.cisco.com with ESMTP; 19 Nov 2011 13:28:35 +0000
Received: from [10.88.5.185] (sin-vpn-client-20-219.cisco.com [10.68.20.219]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pAJDSYKe032657 for ; Sat, 19 Nov 2011 13:28:34 GMT
From: Fred Baker 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Sat, 19 Nov 2011 21:28:34 +0800
References: <4EC6612A.3060603@ripe.net>
To: "v6ops@ietf.org WG" 
Message-Id: 
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Subject: [v6ops] Fwd: Hampering Eyeballs - Observations on Two "Happy Eyeballs" Implementations (New on RIPE Labs)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 19 Nov 2011 13:28:41 -0000

Begin forwarded message:

> From: Mirjam Kuehne 
> Date: November 18, 2011 9:44:10 PM GMT+08:00
> To: ipv6-ops@lists.cluenet.de
> Subject: Hampering Eyeballs - Observations on Two "Happy Eyeballs" =
Implementations (New on RIPE Labs)
>=20
> Hi,
>=20
> In case you have not seen this yet: Emile Aben published an =
interesting article on RIPE Labs earlier this week:
>=20
> Hampering Eyeballs - Observations on Two "Happy Eyeballs" =
Implementations
>=20
> https://labs.ripe.net/Members/emileaben/hampered-eyeballs
>=20
> Kind Regards,
> Mirjam Kuehne
> RIPE NCC
>=20
>=20


From joelja@bogus.com  Sat Nov 19 13:11:23 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3593821F86A0 for ; Sat, 19 Nov 2011 13:11:23 -0800 (PST)
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 PVMJkPnodfvs for ; Sat, 19 Nov 2011 13:11:22 -0800 (PST)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 786FA21F869E for ; Sat, 19 Nov 2011 13:11:22 -0800 (PST)
Received: from Zorch.local (adsl-75-36-137-171.dsl.pltn13.sbcglobal.net [75.36.137.171]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id pAJLBEpN019841 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sat, 19 Nov 2011 21:11:17 GMT (envelope-from joelja@bogus.com)
Message-ID: <4EC81B6D.3000401@bogus.com>
Date: Sun, 20 Nov 2011 05:11:09 +0800
From: Joel jaeggli 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Chongfeng Xie 
References:   <4EB05384.5000007@gmail.com>  <4EB54C85.4050909@bogus.com>  <4EBC6599.6030002@bogus.com> 
In-Reply-To: 
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]); Sat, 19 Nov 2011 21:11:19 +0000 (UTC)
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] Fwd: New Version Notification for draft-sunq-v6ops-contents-transition-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, 19 Nov 2011 21:11:23 -0000

On 11/18/11 15:32 , Chongfeng Xie wrote:
> 
> Hi, Joel,
> 
>        The stateful NAT64 can serve multiple ICPs within the same IDC
> simultaneously.  All of them are IPv4-only and can not read IPv6
> address, they have different expectations to get the source IPv6
> address, some want to get IPv6 address, some may not. Some may want to
> get this information online, some may offline. What I mean is that ICPs
> have different requirements to geo-location. The current NAT64 design
> keeps the mapping between users' IPv6 source address and IPv4 address,
> so the geo-location information was not threw out in the NAT64 design.
> We will provide Interfaces to ICPs to meet their different demands, this
> is our on-going work.
> 
>       From the standpoint viewpoint of carriers, NAT64 can server as a
> shared platform for ICPs in the early phase of transition, especially
> when the volume of IPv6 users in not big enough.  Carriers would NOT
> like to deploy a system which is involved with too much
> application-layer processing, we prefer a solution of network-layer,
> this is more consistent with the role of IETF  "above the wire and below
> the application".

This is IPv6 "operations"...

As an operator of an internet content provider I need more visibility
than this proposed approach provides and I'm not alone.

A document covering what you did, I think, is just peachy. Putting the
v6ops stamp of approval on such a document given that I view the
approach as a bad idea would be something that I oppose.


> Thank you!
> 
> Chongfeng
> 
> 2011/11/11 Joel jaeggli >
> 
>     On 11/7/11 22:13 , Qiong wrote:
>     > Hi, Joel
>     >
>     > On Sat, Nov 5, 2011 at 10:47 PM, Joel jaeggli      
>     > >> wrote:
>     >
>     >     > After all, dual stack is what we have discussing for 10
>     years. But
>     >     up to
>     >     > now, how many ICPs have upgraded to IPv6 in dual-stack
>     directly? I
>     >     > really think we need to re-think it again, from both
>     technical aspect
>     >     > and the industry/or market aspect. And the first step is rather
>     >     > important to give us confidence to move forward. That's why we
>     >     recommend
>     >     > single-stack (either v4 or v6) transition in the current
>     phase. Then,
>     >     > for the conservative ones, the IPv4 services can be still
>     offered
>     >     > natively, and the IPv6 services can be offered by the
>     stateful NAT64;
>     >     > while for progressive ones and newly comers, the stateless
>     IVI can be
>     >     > employed to offer native IPv6 services reachable via IPv4.
>     And we hope
>     >     > it would help enrich IPv6 content asap. Then how do you think ?
>     >
>     >     Any solution that causes me to lose access to the source
>     address is not
>     >     usable from my vantage point as a content provider. When I
>     terminate
>     >     connections on an l7 load balancer as I generally do for
>     http/https on
>     >     ipv4 and where we do it in ipv6 I can drop x-forwarded for in
>     there.
>     >     That requires that I recieve the traffic unmolested by a nat
>     transform
>     >     associated with my own service.
>     >
>     > I agree it is important. But there is another question here : although
>     > you can use l7 load balancer to insert x-forwarded here,  how can you
>     > guarantee that there is no CGN along the path from the user's end-host
>     > to the data center.
> 
>     I don't have to, what I need is a granular enough view of where the
>     address sharing is occuring that I can serve my content accordingly.
>     it's not a problem for example if ~200,000 mobile users of an app at
>     Indonesia's 3rd largest mobile operator emerge from behind a /22
> 
>     > I mean, in case we cannot avoid deploying some kind
>     > of address sharing mechanisms in the future, ICPs have to face the
>     fact
> 
>     you'll note that I'm assuming the existence of address sharing
>     mechanisms on both sides of the conversation. I'd very much prefer that
>     the one working on my behalf not necessarily throw out information as a
>     product of it's design.
> 
>     > that they will somehow lose the geo-location info when they
>     receive IPv4
>     > traffic. So maybe it is one choice to provide them with a database
>     which
>     > stores the original binding information. Would it be some kind of
>     helpful ?
> 
>     where are you going to put that and signal it?
>     > Thanks
>     >
>     > Best wishes
>     >
>     > Qiong
>     >
>     >
>     >
>     >     > Thanks
>     >     >
>     >     > Qiong
>     >     >
>     >     >
>     >     > On Wed, Nov 2, 2011 at 4:16 AM, Brian E Carpenter
>     >     >      
>          >
>     >          
>     >          >>> wrote:
>     >     >
>     >     >     I'm not seeing why this is a better solution for a
>     >     small/medium ICP
>     >     >     than just moving to a dual stack. That is much easier
>     for a small
>     >     >     network than for a big one.
>     >     >
>     >     >     Regards
>     >     >       Brian
>     >     >
>     >     >
>     >     >
>     >     > _______________________________________________
>     >     > v6ops mailing list
>     >     > v6ops@ietf.org 
>     >
>     >     > https://www.ietf.org/mailman/listinfo/v6ops
>     >
>     >
> 
>     _______________________________________________
>     v6ops mailing list
>     v6ops@ietf.org 
>     https://www.ietf.org/mailman/listinfo/v6ops
> 
> 


From lorenzo@google.com  Sun Nov 20 05:13:06 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D142021F85AE for ; Sun, 20 Nov 2011 05:13:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level: 
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=-0.224, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_35=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 SdIEdgv7gxNc for ; Sun, 20 Nov 2011 05:13:06 -0800 (PST)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id C06F021F84FC for ; Sun, 20 Nov 2011 05:13:01 -0800 (PST)
Received: by ggeq3 with SMTP id q3so2794246gge.31 for ; Sun, 20 Nov 2011 05:13:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=4bef6WWXt3wH/UMloHoYLvkjnvrnm19bj4/BhrubT2k=; b=LDQzpVDCc47purLPESOQU2f0+6CLfCGKzB4dq/J8wrb7kYS3a8RjFYBGSK+pdLbJLj L6VUL6Md2vcJYPfJLwrQ==
Received: by 10.236.181.138 with SMTP id l10mr14350370yhm.36.1321794781255; Sun, 20 Nov 2011 05:13:01 -0800 (PST)
Received: by 10.236.181.138 with SMTP id l10mr14350361yhm.36.1321794781118; Sun, 20 Nov 2011 05:13:01 -0800 (PST)
MIME-Version: 1.0
Received: by 10.150.202.14 with HTTP; Sun, 20 Nov 2011 05:12:40 -0800 (PST)
In-Reply-To: <7EB596BF-B175-40BF-ABC8-326599670B04@apple.com>
References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com>  <5B6B2B64C9FE2A489045EEEADDAFF2C30354473D@XMB-RCD-109.cisco.com> <4EC455D6.8030601@bogus.com>   <7EB596BF-B175-40BF-ABC8-326599670B04@apple.com>
From: Lorenzo Colitti 
Date: Sun, 20 Nov 2011 22:12:40 +0900
Message-ID: 
To: james woodyatt 
Content-Type: multipart/alternative; boundary=20cf30434af064ffce04b22a543c
X-System-Of-Record: true
Cc: IPv6 Operations 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 20 Nov 2011 13:13:06 -0000

--20cf30434af064ffce04b22a543c
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Nov 18, 2011 at 07:55, james woodyatt  wrote:

> If you're a CE router, it doesn't matter what RAs you see. CE routers
> explicitly ignore IPv6 RAs when determining whether to start DHCPv6 PD or
> not,
>
>
> This is news to me.  The way I read RFC 6204 and I-D.ietf-v6ops-6204bis,
> CPE routers are not required to ignore the M and O bits in IPv6 router
> advertisements.  As far as I can see, CPE router implementations that wait
> to receive a router advertisement on the WAN with O=1 before starting the
> DHCPv6 client still conforms to the recommendations and complies with the
> forthcoming IPv6Ready CPE Router Interoperability test specification.
>

You're right, I misspoke. CE routers don't have to ignore RAs, they're just
not required to wait for them before initiating DHCPv6.

--20cf30434af064ffce04b22a543c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Fri, Nov 18, 2011 at 07:55, james woodyatt <jhw@apple.com><=
/span> wrote:



If you're a =
CE router, it doesn't matter what RAs you see. CE routers explicitly ig=
nore IPv6 RAs when determining whether to start DHCPv6 PD or not,



This is news to me. =A0The way I read RFC 6204 and I-D=
.ietf-v6ops-6204bis, CPE routers are not required to ignore the M and O bit=
s in IPv6 router advertisements. =A0As far as I can see, CPE router impleme=
ntations that wait to receive a router advertisement on the WAN with O=3D1 =
before starting the DHCPv6 client still conforms to the recommendations and=
 complies with the forthcoming IPv6Ready CPE Router Interoperability test s=
pecification.




You're right, I misspoke. CE rou=
ters don't have to ignore RAs, they're just not required to wait fo=
r them before initiating DHCPv6.


--20cf30434af064ffce04b22a543c--

From dougb@dougbarton.us  Sun Nov 20 20:03:59 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 752AA11E8093 for ; Sun, 20 Nov 2011 20:03:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.448
X-Spam-Level: 
X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=0.151,  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 592AqqzbkoFw for ; Sun, 20 Nov 2011 20:03:58 -0800 (PST)
Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id 9B3A511E8090 for ; Sun, 20 Nov 2011 20:03:58 -0800 (PST)
Received: (qmail 25998 invoked by uid 399); 21 Nov 2011 04:03:55 -0000
Received: from unknown (HELO 172-17-198-245.globalsuite.net) (dougb@dougbarton.us@12.207.105.210) by mail2.fluidhosting.com with ESMTPAM; 21 Nov 2011 04:03:55 -0000
X-Originating-IP: 12.207.105.210
X-Sender: dougb@dougbarton.us
Message-ID: <4EC9CDA8.6050808@dougbarton.us>
Date: Sun, 20 Nov 2011 20:03:52 -0800
From: Doug Barton 
Organization: http://SupersetSolutions.com/
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111110 Thunderbird/8.0
MIME-Version: 1.0
To: Fred Baker 
References: <754008F3-6B2B-4DD1-B72B-EDE17A4FBF80@cisco.com>
In-Reply-To: <754008F3-6B2B-4DD1-B72B-EDE17A4FBF80@cisco.com>
X-Enigmail-Version: undefined
OpenPGP: id=1A1ABC84
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "v6ops@ietf.org WG" , draft-liu-v6ops-ula-usage-analysis@tools.ietf.org
Subject: Re: [v6ops] Major use cases for ULA
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 21 Nov 2011 04:03:59 -0000

On 11/17/2011 02:37, Fred Baker wrote:
> Another example is the one I mentioned in RFC 6296; if you choose to use such a translator, you're going to need an interior prefix. That could be ULA or global. If it is global and you decide to change away from that carrier, you will have to renumber the network. If you find that scary, you might choose a ULA as your internal prefix.

Personally I think this is the "killer app" for ULA. My opinion is that
a lot of SMBs that can't/won't get their own PI will opt for this
combination.


Doug

-- 

		"We could put the whole Internet into a book."
		"Too practical."

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/


From joelja@bogus.com  Sun Nov 20 22:57:12 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3580421F84A4 for ; Sun, 20 Nov 2011 22:57:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.051
X-Spam-Level: 
X-Spam-Status: No, score=-102.051 tagged_above=-999 required=5 tests=[AWL=-0.051, 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 mZu4WWRhDkwV for ; Sun, 20 Nov 2011 22:57:11 -0800 (PST)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id B20F811E8098 for ; Sun, 20 Nov 2011 22:57:11 -0800 (PST)
Received: from Zorch.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 pAL6v4vl057043 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Mon, 21 Nov 2011 06:57:06 GMT (envelope-from joelja@bogus.com)
Message-ID: <4EC9F640.9050206@bogus.com>
Date: Sun, 20 Nov 2011 22:57:04 -0800
From: Joel jaeggli 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Brian E Carpenter 
References: <754008F3-6B2B-4DD1-B72B-EDE17A4FBF80@cisco.com> <4EC4EDC9.1080003@gmail.com>
In-Reply-To: <4EC4EDC9.1080003@gmail.com>
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]); Mon, 21 Nov 2011 06:57:08 +0000 (UTC)
Cc: "v6ops@ietf.org WG" , draft-liu-v6ops-ula-usage-analysis@tools.ietf.org
Subject: Re: [v6ops] Major use cases for ULA
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 21 Nov 2011 06:57:12 -0000

as an individual rather than as a chair.

On 11/17/11 03:19 , Brian E Carpenter wrote:
> Fred,
> 
>> First, as Jari noted from the mike, there is no case in which a ULA is required.
> 
> Then how do we assign a prefix for a totally isolated network that includes
> at least two subnets?
> 
> I realise that no such network will exist for ever without getting connected
> to the Internet, but during the time that it does exist in isolation, ULA seems
> a better solution than having people make up their own unicast prefix or
> applying to ARIN for a PI prefix.

The condition may also be ephemeral, e.g. a ula might be retained only
for the duration of the condition where an alternative does not exist.
networks that can facilely renumber in the course of normal operation
might have little trouble using and discarding a ula prefix.

> Beyond that I'm getting too sleepy to work through your analysis, but I think
> Bing's model of documenting the full range of use cases in a neutral manner
> is a good first step. The second step might well be guidelines about which
> ones are viable and which ones are harmful.

as an individual rather than as a chair.

It would be if it were neutral, it justifies the usage of a ula behind a
translator in the interest of topology hiding or enhanced security, it
also refers to ula central.

the later doesn't exist and former doesn't seem like the basis for
consensus onthe document.

> As Nathan's comment shows, opinions may vary.
> 
> Regards
>    Brian
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
> 


From leo.liubing@huawei.com  Mon Nov 21 02:01:38 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6459F21F8B76 for ; Mon, 21 Nov 2011 02:01:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.35
X-Spam-Level: 
X-Spam-Status: No, score=-5.35 tagged_above=-999 required=5 tests=[AWL=1.249,  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 anXAsyqu++FL for ; Mon, 21 Nov 2011 02:01:37 -0800 (PST)
Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id B1D9321F8B75 for ; Mon, 21 Nov 2011 02:01:37 -0800 (PST)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LV00095F95R9M@szxga03-in.huawei.com> for v6ops@ietf.org; Mon, 21 Nov 2011 18:01:03 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LV000FJM95Q39@szxga03-in.huawei.com> for v6ops@ietf.org; Mon, 21 Nov 2011 18:01:03 +0800 (CST)
Received: from szxeml206-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AFF57992; Mon, 21 Nov 2011 18:00:21 +0800
Received: from SZXEML421-HUB.china.huawei.com (10.82.67.160) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 21 Nov 2011 18:00:20 +0800
Received: from SZXEML509-MBS.china.huawei.com ([169.254.2.220]) by szxeml421-hub.china.huawei.com ([10.82.67.160]) with mapi id 14.01.0323.003; Mon, 21 Nov 2011 18:00:12 +0800
Date: Mon, 21 Nov 2011 10:00:10 +0000
From: "Leo Liu(bing)" 
In-reply-to: <4EC9F640.9050206@bogus.com>
X-Originating-IP: [10.108.4.74]
To: Joel jaeggli , Brian E Carpenter 
Message-id: <8AE0F17B87264D4CAC7DE0AA6C406F4523669A39@szxeml509-mbs.china.huawei.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-language: zh-CN
Content-transfer-encoding: 7BIT
Accept-Language: zh-CN, en-US
Thread-topic: [v6ops] Major use cases for ULA
Thread-index: AQHMpRUJvI18wacPokOHL33emnLRKZWwZU6AgAX/+ACAAKnJYA==
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
References: <754008F3-6B2B-4DD1-B72B-EDE17A4FBF80@cisco.com> <4EC4EDC9.1080003@gmail.com> <4EC9F640.9050206@bogus.com>
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] Major use cases for ULA
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 21 Nov 2011 10:01:38 -0000

Hi, Joel

> On 11/17/11 03:19 , Brian E Carpenter wrote:
> > Beyond that I'm getting too sleepy to work through your analysis, but I think
> > Bing's model of documenting the full range of use cases in a neutral manner
> > is a good first step. The second step might well be guidelines about which
> > ones are viable and which ones are harmful.
> 
> as an individual rather than as a chair.
> 
> It would be if it were neutral, it justifies the usage of a ula behind a
> translator in the interest of topology hiding or enhanced security, it
> also refers to ula central.
> 
> the later doesn't exist and former doesn't seem like the basis for
> consensus onthe document.
> 

My thought of including ULA-C is that, it can be considered as a use case rather than normative reference. Since this draft is all about ULA, we just include the recently discussed ULA-C topic to provoke more discussion. However, if nobody cares about ULA-C, that's OK, we would probably drop it out of the document.

For the former issue, I did not intend to preach people adopting ULA in the interest of security. But for my little understanding, I just doubt that is ULA for security really totally meaningless? I'd like to discuss it in the WG, if there has been strong consensus about this topic, excuse me for my not knowing it.

From lorenzo@google.com  Mon Nov 21 04:42:48 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60FD021F8C11 for ; Mon, 21 Nov 2011 04:42:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.586
X-Spam-Level: 
X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_32=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 ZEvCVt-7Em-E for ; Mon, 21 Nov 2011 04:42:47 -0800 (PST)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id B7EE621F8C10 for ; Mon, 21 Nov 2011 04:42:47 -0800 (PST)
Received: by ghrr14 with SMTP id r14so3313222ghr.31 for ; Mon, 21 Nov 2011 04:42:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=b8sxcw/mnYVEdPClasI1rn9PxRNrS27rvwVL9Zs0Wqk=; b=geqSvmbi3+bKFNitXaKnXP3/E32PBbm0NjRQgWDCmfS6TB3V2StCIVMXE27tk2CqLa mrYt7D5hs3Zj0gm29QOA==
Received: by 10.236.75.167 with SMTP id z27mr19012012yhd.53.1321879367238; Mon, 21 Nov 2011 04:42:47 -0800 (PST)
Received: by 10.236.75.167 with SMTP id z27mr19012002yhd.53.1321879367132; Mon, 21 Nov 2011 04:42:47 -0800 (PST)
MIME-Version: 1.0
Received: by 10.150.202.14 with HTTP; Mon, 21 Nov 2011 04:42:26 -0800 (PST)
In-Reply-To: <867F4B6A1672E541A94676D556793ACD0C27516658@MOPESMBX01.eu.thmulti.com>
References:    <867F4B6A1672E541A94676D556793ACD0C263BD0F3@MOPESMBX01.eu.thmulti.com>  <867F4B6A1672E541A94676D556793ACD0C27516166@MOPESMBX01.eu.thmulti.com>  <867F4B6A1672E541A94676D556793ACD0C27516658@MOPESMBX01.eu.thmulti.com>
From: Lorenzo Colitti 
Date: Mon, 21 Nov 2011 21:42:26 +0900
Message-ID: 
To: Wuyts Carl 
Content-Type: multipart/alternative; boundary=20cf3005dde61d25e204b23e06f6
X-System-Of-Record: true
Cc: "v6ops@ietf.org WG" 
Subject: Re: [v6ops] RFC6204bis-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, 21 Nov 2011 12:42:48 -0000

--20cf3005dde61d25e204b23e06f6
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Tue, Nov 15, 2011 at 16:10, Wuyts Carl wrote=
:

> Wait... so you're saying that your CPE starts DHCPv6 PD *before* IPv6CP i=
s
> up? How can you do that? You don't even have a link-local address.
>
> **
>
> No, DHCPv6 runs on top of PPP in this case, hence it cannot start before
> it is up, but there=92s no link to RAs, which was the first statement: =
=93link
> RA to DHCPv6=94, so no RA needed to start DHCPv6 on this link, hence
> preferably protocols should not be linked.
>
But they are linked: DHCPv6 has to start after PPP starts. So you do
trigger DHCPv6 when another protocol comes up, at least for PPP. So in
theory you could do so for RAs as well.

> ****
>
> What do you do on Ethernet links, start DHCPv6 PD before DAD completes, s=
o
> you can avoid tying the two protocols together?****
>
> We have different configuration possibilities here, one being not to
> listen to RA and configure the DHCPv6 client independent from the flags i=
n
> it, so not wait for the RA indeed.  We=92re IPv6 ready logo certified, co=
re
> protocols phase II, so don=92t worry, we respect the rules towards DAD an=
d
> everything, we just don=92t want to tie up protocols, i.e. no fixed link
> between the RA and DHCPv6, no matter Ethernet, PPP or whatever****
>
My point was that even on Ethernet, you can't immediately start DHCPv6 PD
as soon as link comes up. First you have to wait for the link-local address
to complete DAD. So there is a trigger on plain Ethernet too.

--20cf3005dde61d25e204b23e06f6
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


On Tue, Nov 15, 2011 at 16:10, Wuyts Carl <Carl.Wuyts@te=
chnicolor.com> wrote:



<=
p class=3D"MsoNormal">Wait... so you're saying that your CPE starts DHC=
Pv6 PD *before* IPv6CP is up? How can you do that? You don't even have =
a link-local address.



N=
o, DHCPv6 runs on top of PPP in this case, hence it cannot start before it =
is up, but there=92s no link to RAs, which was the first statement: =93link=
 RA to DHCPv6=94, so no RA needed to start DHCPv6 on this link, hence prefe=
rably protocols should not be linked.



But they are linked: DHCPv6 has to start afte=
r PPP starts. So you do trigger DHCPv6 when another protocol comes up, at l=
east for PPP. So in theory you could do so for RAs as well.



What do you do on =
Ethernet links, start DHCPv6 PD before DAD completes, so you can avoid tyin=
g the two protocols together?



We have different configuration possibi=
lities here, one being not to listen to RA and configure the DHCPv6 client =
independent from the flags in it, so not wait for the RA indeed.=A0 We=92re=
 IPv6 ready logo certified, core protocols phase II, so don=92t worry, we r=
espect the rules towards DAD and everything, we just don=92t want to tie up=
 protocols, i.e. no fixed link between the RA and DHCPv6, no matter Etherne=
t, PPP or whatever



My point was that even on Ethernet, you can&=
#39;t immediately start DHCPv6 PD as soon as link comes up. First you have =
to wait for the link-local address to complete DAD. So there is a trigger o=
n plain Ethernet too.

--20cf3005dde61d25e204b23e06f6--

From lorenzo@google.com  Mon Nov 21 04:48:03 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4903C21F8551 for ; Mon, 21 Nov 2011 04:48:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.872
X-Spam-Level: 
X-Spam-Status: No, score=-102.872 tagged_above=-999 required=5 tests=[AWL=0.104, 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 1HudBmTDIm1I for ; Mon, 21 Nov 2011 04:48:02 -0800 (PST)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id C5EA421F8B95 for ; Mon, 21 Nov 2011 04:48:02 -0800 (PST)
Received: by ghrr14 with SMTP id r14so3319259ghr.31 for ; Mon, 21 Nov 2011 04:48:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=l6vhDrRb7TtBIJ8co66qSD4Pq4T1JWN+7XYSelnjUHY=; b=LZfyudcdBeB8MekwJIn3SKJPAm4QDZidCI5WrcCylhaWn5S1Rlqm37yXoUnl2N5XrJ vDl4XcuiP3xEiKWNZNOw==
Received: by 10.147.50.12 with SMTP id c12mr2606790yak.8.1321879682324; Mon, 21 Nov 2011 04:48:02 -0800 (PST)
Received: by 10.147.50.12 with SMTP id c12mr2606782yak.8.1321879682122; Mon, 21 Nov 2011 04:48:02 -0800 (PST)
MIME-Version: 1.0
Received: by 10.150.202.14 with HTTP; Mon, 21 Nov 2011 04:47:41 -0800 (PST)
In-Reply-To: <867F4B6A1672E541A94676D556793ACD0C27516664@MOPESMBX01.eu.thmulti.com>
References: <867F4B6A1672E541A94676D556793ACD0C263BCDD7@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303494A91@XMB-RCD-109.cisco.com> <20111113070005.583DD17137B8@drugs.dv.isc.org> <867F4B6A1672E541A94676D556793ACD0C27516333@MOPESMBX01.eu.thmulti.com> <20111114210738.64529171A31E@drugs.dv.isc.org> <867F4B6A1672E541A94676D556793ACD0C27516652@MOPESMBX01.eu.thmulti.com> <80D702DA-F460-4017-939F-C387AFC2A060@nominum.com> <867F4B6A1672E541A94676D556793ACD0C2751665C@MOPESMBX01.eu.thmulti.com> <2815D4D2-F0CC-4921-84C9-249EC65F42D0@nominum.com> <867F4B6A1672E541A94676D556793ACD0C27516664@MOPESMBX01.eu.thmulti.com>
From: Lorenzo Colitti 
Date: Mon, 21 Nov 2011 21:47:41 +0900
Message-ID: 
To: Wuyts Carl 
Content-Type: multipart/alternative; boundary=000e0cd40714e3836e04b23e186b
X-System-Of-Record: true
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] RFC6204bis-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, 21 Nov 2011 12:48:03 -0000

--000e0cd40714e3836e04b23e186b
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Nov 15, 2011 at 16:33, Wuyts Carl wrote:

> I agree, however, it's not me who has to agree.
> Anyway, if you want to go more the up-to-date way: what about dhcpv6
> client availability on mobile devices (smartphones etc)?


Android doesn't support DHCPv6. What were you suggesting to use it for? I
tried to look back in the thread but I wasn't able to interpret the quoted
text.

--000e0cd40714e3836e04b23e186b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Tue, Nov 15, 2011 at 16:33, Wuyts Carl <Carl.Wuyts@technicolor.com> wrote:



I agree, however, it's not me who has to agree.

Anyway, if you want to go more the up-to-date way: what about dhcpv6 client=
 availability on mobile devices (smartphones etc)?

Android doesn't support DHCPv6. What were you suggesting to use=
 it for? I tried to look back in the thread but I wasn't able to interp=
ret the quoted text.






--000e0cd40714e3836e04b23e186b--

From wesley.george@twcable.com  Mon Nov 21 05:29:32 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6276A21F8B8D; Mon, 21 Nov 2011 05:29:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.439
X-Spam-Level: 
X-Spam-Status: No, score=-0.439 tagged_above=-999 required=5 tests=[AWL=0.024,  BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dKKgC4ZropCO; Mon, 21 Nov 2011 05:29:32 -0800 (PST)
Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id B775E21F8B6F; Mon, 21 Nov 2011 05:29:31 -0800 (PST)
X-SENDER-IP: 10.136.163.13
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="4.69,546,1315195200"; d="scan'208";a="284671270"
Received: from unknown (HELO PRVPEXHUB04.corp.twcable.com) ([10.136.163.13]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 21 Nov 2011 08:24:12 -0500
Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.26]) by PRVPEXHUB04.corp.twcable.com ([10.136.163.13]) with mapi; Mon, 21 Nov 2011 08:29:29 -0500
From: "George, Wes" 
To: Fred Baker , "draft-liu-v6ops-ula-usage-analysis@tools.ietf.org" 
Date: Mon, 21 Nov 2011 08:29:29 -0500
Thread-Topic: [v6ops] Major use cases for ULA
Thread-Index: AcylFQX1NuXAlRXZTbCjoh/QYOSewgBp1neQ
Message-ID: 
References: <754008F3-6B2B-4DD1-B72B-EDE17A4FBF80@cisco.com>
In-Reply-To: <754008F3-6B2B-4DD1-B72B-EDE17A4FBF80@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
Cc: "v6ops@ietf.org WG" , "renum@ietf.org" 
Subject: Re: [v6ops] Major use cases for ULA
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 21 Nov 2011 13:29:32 -0000

> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
> Of Fred Baker

> To my mind, the renumbering scenario is a red herring. Thomas Narten
> wanted desperately for me to put it into RFC 4192 as "A ULA could help
> when renumbering a network". However, it doesn't actually do so.
>
[WEG] snip
>
> Hence, a ULA is helpful for folks within my own network, but does not
> help keep my externally-facing services running. To my small mind, that
> makes a ULA a nice fallback in case something gets screwed up, but it
> is not a renumbering solution. It fails to prevent a service outage
> during renumbering.

[WEG] I think that your objection is based on more of a syntax problem (hai=
r-splitting, really) than anything. ULA came up in the context of 6renum as=
 a potential tool in the toolbox.
The thought is that in some cases it could:
1) reduce the number of hosts impacted by an external renumber by numbering=
 internal-only things from ULA
2) keep internal services online during a renumber (as you have discussed)

It's not a solution to renumbering by itself by any means - no magic here. =
But reducing the number of hosts one has to renumber or reducing the servic=
es impacted by a renumber does make renumbering easier/more palatable. Ther=
efore a discussion of how to make renumbering easier is incomplete without =
it, just as a discussion of reasons why ULA might make sense is incomplete =
without discussing ways that it might make renumbering easier.

Wes George, at least partially wearing my 6renum hat

This E-mail and any of its attachments may contain Time Warner Cable propri=
etary information, which is privileged, confidential, or subject to copyrig=
ht belonging to Time Warner Cable. This E-mail is intended solely for the u=
se of the individual or entity to which it is addressed. If you are not the=
 intended recipient of this E-mail, you are hereby notified that any dissem=
ination, distribution, copying, or action taken in relation to the contents=
 of and attachments to this E-mail is strictly prohibited and may be unlawf=
ul. If you have received this E-mail in error, please notify the sender imm=
ediately and permanently delete the original and any copy of this E-mail an=
d any printout.

From wesley.george@twcable.com  Mon Nov 21 05:29:33 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1960C21F8B8D for ; Mon, 21 Nov 2011 05:29:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.939
X-Spam-Level: 
X-Spam-Status: No, score=-0.939 tagged_above=-999 required=5 tests=[AWL=0.524,  BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, 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 Vaof1NKzo9YX for ; Mon, 21 Nov 2011 05:29:32 -0800 (PST)
Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 9916921F8B6F for ; Mon, 21 Nov 2011 05:29:32 -0800 (PST)
X-SENDER-IP: 10.136.163.12
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="4.69,546,1315195200"; d="scan'208";a="300040165"
Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 21 Nov 2011 08:24:49 -0500
Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.26]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Mon, 21 Nov 2011 08:29:29 -0500
From: "George, Wes" 
To: Fred Baker , Brian E Carpenter 
Date: Mon, 21 Nov 2011 08:29:29 -0500
Thread-Topic: [v6ops] Major use cases for ULA
Thread-Index: AcylMEvqH0PgoL3hREyksU0F3VNm6gBjDTkw
Message-ID: 
References: <754008F3-6B2B-4DD1-B72B-EDE17A4FBF80@cisco.com> <4EC4EDC9.1080003@gmail.com> <6A642CDE-B5B7-4717-B8C8-B3F4EDC8043F@cisco.com>
In-Reply-To: <6A642CDE-B5B7-4717-B8C8-B3F4EDC8043F@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
Cc: "v6ops@ietf.org WG" , "draft-liu-v6ops-ula-usage-analysis@tools.ietf.org" 
Subject: Re: [v6ops] Major use cases for ULA
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 21 Nov 2011 13:29:33 -0000

> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
> Of Fred Baker

> My suggestion to Bing is to step away from the dubious examples, and
> simply describe networks that don't connect to the Internet, networks
> that do but..., and so on.
>
[WEG] Agree - I already provided similar feedback to the authors directly w=
hen I read the review. I would add to that some discussion of when ULA real=
ly *isn't* a good idea - to give us an opportunity to reiterate that we don=
't think it's a good idea to make ULA + a NAT66 GW into the second coming o=
f NAT44 + RFC1918, for example.

Wes George


This E-mail and any of its attachments may contain Time Warner Cable propri=
etary information, which is privileged, confidential, or subject to copyrig=
ht belonging to Time Warner Cable. This E-mail is intended solely for the u=
se of the individual or entity to which it is addressed. If you are not the=
 intended recipient of this E-mail, you are hereby notified that any dissem=
ination, distribution, copying, or action taken in relation to the contents=
 of and attachments to this E-mail is strictly prohibited and may be unlawf=
ul. If you have received this E-mail in error, please notify the sender imm=
ediately and permanently delete the original and any copy of this E-mail an=
d any printout.

From fred@cisco.com  Mon Nov 21 06:21:08 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF2311E8096 for ; Mon, 21 Nov 2011 06:21:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.455
X-Spam-Level: 
X-Spam-Status: No, score=-109.455 tagged_above=-999 required=5 tests=[AWL=1.144, 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 BamfIT3VO4g9 for ; Mon, 21 Nov 2011 06:21:04 -0800 (PST)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 344A411E80A0 for ; Mon, 21 Nov 2011 06:21:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=261; q=dns/txt; s=iport; t=1321885262; x=1323094862; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=rQz5lC9m4chDC7bidSp9+h4DSvPqF3qhh9aS/FAYHmA=; b=AOE7FsY36IB7yDf0wp3w3JxRwCh06ps62VD9cyAGHnktMWeK5k11Lz6i E7A5RsW3tpTWd7QcCD/t+DjP/tJzR+bq1CsNsDLndlZ6pqaSbg12f6hl+ hIqC7E911crZKTrYfmkK28GokNSnuYnPHpbskQSup7jfzF+dqpYvzK/so Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvwEAFRdyk5Io8US/2dsb2JhbABDqjqBBYILASeBfTWcL4EmAZ4niTRjBIgYjCSFPYxV
X-IronPort-AV: E=Sophos;i="4.69,547,1315180800"; d="scan'208";a="122240149"
Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-1.cisco.com with ESMTP; 21 Nov 2011 14:21:00 +0000
Received: from [10.88.5.185] (sin-vpn-client-21-15.cisco.com [10.68.21.15]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pALEL0kZ025426 for ; Mon, 21 Nov 2011 14:21:00 GMT
From: Fred Baker 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Mon, 21 Nov 2011 22:20:59 +0800
Message-Id: <58DFE4A5-5291-4473-9C14-5A547171FC23@cisco.com>
To: "v6ops@ietf.org WG" 
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Subject: [v6ops] Requesting comments on draft-ietf-wireline-incremental-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, 21 Nov 2011 14:21:08 -0000

I think it would be of value to Victor if folks could comment on the =
document, indicating what should remain in, what should be taken out, =
and what should be added that isn't there. He is planning a rev as he =
develops the working group draft at -00.=

From satoru.matsushima@gmail.com  Mon Nov 21 07:11:37 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6357721F8797 for ; Mon, 21 Nov 2011 07:11:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.261
X-Spam-Level: 
X-Spam-Status: No, score=-3.261 tagged_above=-999 required=5 tests=[AWL=-0.262, 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 wFxdkRcXKEIg for ; Mon, 21 Nov 2011 07:11:33 -0800 (PST)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 551791F0C4B for ; Mon, 21 Nov 2011 07:11:33 -0800 (PST)
Received: by iaeo4 with SMTP id o4so8948632iae.31 for ; Mon, 21 Nov 2011 07:11:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=vwR76sN0q6YTAd5bESB2iApV7zdxVdSs/kgauzSdnPc=; b=oQUQ3GgSMVz+3ZzmlAUZmRffPZJitJo7x/2McoFPhU2Wlj3mxySgdLKYro+QiTczw9 64yAwhlMC2hIAWL/xx44zyL1NXMD8hCAfxnqb2y6IYCCJKy+t6Eeji1CFWubSUWVVLJO 7YLE/DEyhD7TYV8+mokNH7ZBB0n/OJ2zHaofI=
Received: by 10.231.48.142 with SMTP id r14mr3440984ibf.5.1321888291934; Mon, 21 Nov 2011 07:11:31 -0800 (PST)
Received: from [192.168.3.4] (softbank221038134212.bbtec.net. [221.38.134.212]) by mx.google.com with ESMTPS id ft1sm27015264igc.3.2011.11.21.07.11.28 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 21 Nov 2011 07:11:30 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=us-ascii
From: Satoru Matsushima 
In-Reply-To: 
Date: Tue, 22 Nov 2011 00:11:26 +0900
Content-Transfer-Encoding: quoted-printable
Message-Id: <4970044A-CC98-4D3E-90F8-F7732ED18637@gmail.com>
References: <20111115062859.14026.74743.idtracker@ietfa.amsl.com> 
To: Fred Baker , "v6ops@ietf.org WG" 
X-Mailer: Apple Mail (2.1251.1)
Cc: Pete Resnick , "ietfdbh@comcast.net Harrington" , draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat@tools.ietf.org, Wesley Eddy 
Subject: Re: [v6ops] New Version Notification - draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-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, 21 Nov 2011 15:11:37 -0000

Thanks Fred,

As an author of this draft, I'm very happy to see the progress of the =
draft. Thank you for all of your comments, contributes, and supports.

This draft describes issues of IPv6 multihoming when an operator try it =
without any kind of IPv6 NAT. Our conclusion is that DHCPv6 is expected =
as most realistic solution to solve the issues. We also understand that =
it might not be a perfect solution for that. We're not dreamer, so we =
have to adopt solution by which the issues can be solved, is available =
_right now_. It could be helpful current DHCPv6 discussion in the mif =
and dhc wg to provide an IPv6 multihoming use case.

We, authors of this draft, appreciate if v6ops working group =
continuously supports the work of this draft.

Best regards,
--satoru

On 2011/11/17, at 23:06, Fred Baker wrote:

> Folks:
>=20
> Please review http://tinyurl.com/7gw45ma and comment. In view of a US =
holiday next week, I'll give you through 2 December. The changes have =
been made in response to IESG "Discuss" comments. The question is =
whether the working group still agrees with the draft.
>=20
> Fred
>=20
> On Nov 15, 2011, at 2:28 PM, Internet-Drafts@ietf.org wrote:
>=20
>> New version (-03) has been submitted for =
draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-03.txt.
>> =
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv6-multihoming-with=
out-ipv6nat-03.txt
>>=20
>>=20
>> Diff from previous version:
>> =
http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-ipv6-multihoming-wit=
hout-ipv6nat-03
>>=20
>> IETF Secretariat.
>=20
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


From narten@us.ibm.com  Mon Nov 21 08:24:27 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BBFD21F8BBE for ; Mon, 21 Nov 2011 08:24:27 -0800 (PST)
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 AsHZt-L-xQnR for ; Mon, 21 Nov 2011 08:24:26 -0800 (PST)
Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by ietfa.amsl.com (Postfix) with ESMTP id F227921F8BBF for ; Mon, 21 Nov 2011 08:24:25 -0800 (PST)
Received: from /spool/local by e5.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for  from ; Mon, 21 Nov 2011 11:24:22 -0500
Received: from d01relay06.pok.ibm.com ([9.56.227.116]) by e5.ny.us.ibm.com ([192.168.1.105]) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted;  Mon, 21 Nov 2011 11:23:27 -0500
Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id pALG5pR03035262 for ; Mon, 21 Nov 2011 11:22:10 -0500
Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id pALFtpEa030014 for ; Mon, 21 Nov 2011 10:55:52 -0500
Received: from cichlid.raleigh.ibm.com (sig-9-49-158-47.mts.ibm.com [9.49.158.47]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id pALFtocK029928 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Nov 2011 10:55:50 -0500
Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id pALFtmoj017956; Mon, 21 Nov 2011 10:55:49 -0500
Message-Id: <201111211555.pALFtmoj017956@cichlid.raleigh.ibm.com>
To: "Hemant Singh (shemant)" 
In-reply-to: <5B6B2B64C9FE2A489045EEEADDAFF2C30354431D@XMB-RCD-109.cisco.com>
References:   <5B6B2B64C9FE2A489045EEEADDAFF2C30354431D@XMB-RCD-109.cisco.com>
Comments: In-reply-to "Hemant Singh (shemant)"  message dated "Tue, 15 Nov 2011 20:31:55 -0600."
Date: Mon, 21 Nov 2011 10:55:48 -0500
From: Thomas Narten 
x-cbid: 11112116-5930-0000-0000-0000020E0771
Cc: "Mark Townsley \(townsley\)" , v6ops@ietf.org
Subject: Re: [v6ops] FW: latest copy of rfc6204bis included
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 21 Nov 2011 16:24:27 -0000

"Hemant Singh (shemant)"  writes:

> For example, imagine a case where a home router is connected to a hub
> and to two modems which go to two different service providers.  One
> provider sets M=O=0 and the other provider sets M=O=1.  If setting M=O=0
> turns off DHCPv6 and M=O=1 triggers a reinitialization, then imagine the
> case where each service provider sets the RA interval to 1 second and
> the RA's come in alternating every 0.5 second.  In that case, the CE
> router will be re-doing DHCPv6 every second and will create a DHCPv6
> storm for the service provider.

If broadband operators are stupid enough to configure the sending of
RAs every second as described above, they get what they deserve.

Let's please not come up with bogus scenarios to justify putting
things in documents.

(If there are other reasonable rationales, please use them.)

Thomas


From shemant@cisco.com  Mon Nov 21 10:27:26 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DEAA11E80DB for ; Mon, 21 Nov 2011 10:27:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.257
X-Spam-Level: 
X-Spam-Status: No, score=-6.257 tagged_above=-999 required=5 tests=[AWL=0.342,  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 Rc3r7jzIfcGv for ; Mon, 21 Nov 2011 10:27:22 -0800 (PST)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id B908421F8564 for ; Mon, 21 Nov 2011 10:27:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=1545; q=dns/txt; s=iport; t=1321900036; x=1323109636; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=Dgkd536MIBY21HqUcfJpvvw7fW5Tx7uWbBizux21zF4=; b=Z8PVCDh+R7p9h+m+1JvguUx23mLZfmpSQYwAYYG+4ZT0WGKe7CW3n15w agF3fICBa/poS5fcMIkm3VZe7nS5j0XZkGEyed4MFLFVdYp7QM161Tpcn Xx+ejoCelIkinQe2FyeZ+kxpH3Trftuq1F3y6GK2bGW8lyPDCl6WF3xCh A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AogAADCXyk6tJV2c/2dsb2JhbABDmiaQF4EFgXIBAQEEEgEdSQwEAgEIEQQBAQsGFwEGAUUIAQgBAQQTCAEZh2mWHgGeS4k0YwSHaTGRaIxe
X-IronPort-AV: E=Sophos;i="4.69,548,1315180800"; d="scan'208";a="37923992"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP; 21 Nov 2011 18:27:16 +0000
Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id pALIRGUj028147;  Mon, 21 Nov 2011 18:27:16 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 21 Nov 2011 12:27:16 -0600
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 21 Nov 2011 12:27:15 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3035EE834@XMB-RCD-109.cisco.com>
In-Reply-To: <201111211555.pALFtmoj017956@cichlid.raleigh.ibm.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] FW: latest copy of rfc6204bis included
Thread-Index: AcyoZpq5FXv3azRfRjC8lMVj4b4QKgAExjbA
References:   <5B6B2B64C9FE2A489045EEEADDAFF2C30354431D@XMB-RCD-109.cisco.com> <201111211555.pALFtmoj017956@cichlid.raleigh.ibm.com>
From: "Hemant Singh (shemant)" 
To: "Thomas Narten" 
X-OriginalArrivalTime: 21 Nov 2011 18:27:16.0311 (UTC) FILETIME=[322C4E70:01CCA87B]
Cc: "Mark Townsley \(townsley\)" , v6ops@ietf.org
Subject: Re: [v6ops] FW: latest copy of rfc6204bis included
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 21 Nov 2011 18:27:26 -0000

-----Original Message-----
From: Thomas Narten [mailto:narten@us.ibm.com]=20
Sent: Monday, November 21, 2011 10:56 AM
To: Hemant Singh (shemant)
Cc: Victor Kuarsingh; Brzozowski, John; v6ops@ietf.org; Mark Townsley =
(townsley)
Subject: Re: [v6ops] FW: latest copy of rfc6204bis included

>Let's please not come up with bogus scenarios to justify putting
>things in documents.

Totally agreed. We did not add any such scenario in the Enhanced DAD =
draft or any other IETF document.   However, whether the scenario was =
bogus is a separate discussion - see

http://www.ietf.org/mail-archive/web/v6ops/current/msg11110.html


>(If there are other reasonable rationales, please use them.)

Agreed as well.  Not related to the M/O bits, but the reflected DAD =
probe problem.  One cable broadband problem outlined in the Intro =
section of the Enhanced DAD draft was a na=EFve user in the home who =
connected two broadband modems in his/her home to a network hub and =
caused the SP concentrator network interface's DAD probe to be reflected =
back.  This is a real problem.  Also one has to design protocols around =
dumb network configuration.  The use of the hub in any network causes, =
for one, a DHCPv6 client not detecting link up/down state but RFC 3315 =
outlines DHCPv6 procedures for link up/down state.  Likewise there was a =
na=EFve proposal to use link up/down state to converge OSPFv3 for prefix =
delegation in a home router LAN but the hub blocks reporting any link =
up/down state.=20

Hemant


From wbeebee@cisco.com  Mon Nov 21 11:40:52 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 027501F0C84 for ; Mon, 21 Nov 2011 11:40:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.132
X-Spam-Level: 
X-Spam-Status: No, score=-4.132 tagged_above=-999 required=5 tests=[AWL=0.400,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iq3u57eHPIHI for ; Mon, 21 Nov 2011 11:40:47 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id B8DAA1F0C62 for ; Mon, 21 Nov 2011 11:40:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wbeebee@cisco.com; l=781; q=dns/txt; s=iport; t=1321904448; x=1323114048; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=/lNgpEHfr7AzNjOMG649GDVPrsTSXDntWhm9XbLqU+8=; b=gZCUJTL3syEyrd+5BbqednAAKAxWOCn86tNolaJDK6oQcA+WgKy+ogdn mo3I3Td9wasxYD09EJUt9zUmVbEOR5CiBpWgIsDaor9BmITlFSU4f5aM2 5cXVdwwYfYuqot/OLTbNRMmm4ANnMmZm5gSeCAFFNfj+l8CVHTVoZzoqL M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqUFAKmoyk6tJXG8/2dsb2JhbABDqjsCgQWBcgEBAQMBEgEnAgE8EgEIgRQJAQEEAQ0OGYdhCJYFAZ5NihcEiBqMIoVGiC2EMA
X-IronPort-AV: E=Sophos;i="4.69,548,1315180800"; d="scan'208";a="37940251"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 21 Nov 2011 19:40:47 +0000
Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id pALJelv2031057;  Mon, 21 Nov 2011 19:40:47 GMT
Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 21 Nov 2011 13:40:47 -0600
Received: from 161.44.175.128 ([161.44.175.128]) by XMB-RCD-201.cisco.com ([72.163.62.208]) with Microsoft Exchange Server HTTP-DAV ;  Mon, 21 Nov 2011 19:40:46 +0000
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Mon, 21 Nov 2011 14:40:43 -0500
From: Wes Beebee 
To: "Hemant Singh (shemant)" , Thomas Narten 
Message-ID: 
Thread-Topic: [v6ops] FW: latest copy of rfc6204bis included
Thread-Index: AcyoZpq5FXv3azRfRjC8lMVj4b4QKgAExjbAAALwTGE=
In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3035EE834@XMB-RCD-109.cisco.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 21 Nov 2011 19:40:47.0176 (UTC) FILETIME=[7740E480:01CCA885]
Cc: "Mark Townsley \(townsley\)" , v6ops@ietf.org
Subject: Re: [v6ops] FW: latest copy of rfc6204bis included
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 21 Nov 2011 19:40:52 -0000

>> Let's please not come up with bogus scenarios to justify putting
>> things in documents.
> 
> Totally agreed. We did not add any such scenario in the Enhanced DAD draft or
> any other IETF document.   However, whether the scenario was bogus is a
> separate discussion - see
> 
> http://www.ietf.org/mail-archive/web/v6ops/current/msg11110.html

Multiple interfaces (MIF working group) and multi-homing, especially as it
applies to home networks, are areas of increasing focus within IETF.  They
are not "bogus scenarios".  Let's not continue the mistake of previous core
IPv6 specifications in not considering the impact of these scenarios on our
work.  Even if they're not explicitly "in-scope", we shouldn't do anything
which deliberately breaks them.

- Wes


From narten@us.ibm.com  Mon Nov 21 11:45:08 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 923691F0C84 for ; Mon, 21 Nov 2011 11:45:08 -0800 (PST)
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 MK2YSTiELGGP for ; Mon, 21 Nov 2011 11:45:04 -0800 (PST)
Received: from e8.ny.us.ibm.com (e8.ny.us.ibm.com [32.97.182.138]) by ietfa.amsl.com (Postfix) with ESMTP id 899AF1F0C62 for ; Mon, 21 Nov 2011 11:45:04 -0800 (PST)
Received: from /spool/local by e8.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for  from ; Mon, 21 Nov 2011 14:45:03 -0500
Received: from d01relay05.pok.ibm.com ([9.56.227.237]) by e8.ny.us.ibm.com ([192.168.1.108]) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted;  Mon, 21 Nov 2011 14:44:48 -0500
Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id pALJilqS203484 for ; Mon, 21 Nov 2011 14:44:47 -0500
Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id pALJilhM023276 for ; Mon, 21 Nov 2011 17:44:47 -0200
Received: from cichlid.raleigh.ibm.com (sig-9-49-158-47.mts.ibm.com [9.49.158.47]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id pALJik3w023220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Nov 2011 17:44:47 -0200
Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id pALJijSf019154; Mon, 21 Nov 2011 14:44:45 -0500
Message-Id: <201111211944.pALJijSf019154@cichlid.raleigh.ibm.com>
To: Wes Beebee 
In-reply-to: 
References: 
Comments: In-reply-to Wes Beebee  message dated "Mon, 21 Nov 2011 14:40:43 -0500."
Date: Mon, 21 Nov 2011 14:44:45 -0500
From: Thomas Narten 
x-cbid: 11112119-9360-0000-0000-000000D1DB0B
Cc: "Mark Townsley \(townsley\)" , v6ops@ietf.org
Subject: Re: [v6ops] FW: latest copy of rfc6204bis included
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 21 Nov 2011 19:45:08 -0000

Wes Beebee  writes:

> >> Let's please not come up with bogus scenarios to justify putting
> >> things in documents.
> > 
> > Totally agreed. We did not add any such scenario in the Enhanced DAD draft or
> > any other IETF document.   However, whether the scenario was bogus is a
> > separate discussion - see
> > 
> > http://www.ietf.org/mail-archive/web/v6ops/current/msg11110.html

> Multiple interfaces (MIF working group) and multi-homing, especially as it
> applies to home networks, are areas of increasing focus within IETF.  They
> are not "bogus scenarios".

Please go back and read what I quoted and said. The term "bogus
scenarios" does not refer to the scenario of multi-homing in
general. It refers specifically to the case of competing/conflicting
RAs being sent every second. That, IMO, is a bogus scenario.

Thomas


From internet-drafts@ietf.org  Mon Nov 21 13:32:30 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9B2711E8107; Mon, 21 Nov 2011 13:32:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.531
X-Spam-Level: 
X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5VX6MwLvCXEn; Mon, 21 Nov 2011 13:32:26 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7880211E80F8; Mon, 21 Nov 2011 13:32:26 -0800 (PST)
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: 3.64
Message-ID: <20111121213226.8833.16868.idtracker@ietfa.amsl.com>
Date: Mon, 21 Nov 2011 13:32:26 -0800
Cc: v6ops@ietf.org
Subject: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-discard-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, 21 Nov 2011 21:32:31 -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           : A Discard Prefix for IPv6
	Author(s)       : Nick Hilliard
	Filename        : draft-ietf-v6ops-ipv6-discard-prefix-01.txt
	Pages           : 5
	Date            : 2011-10-26

   Remote triggered black hole filtering describes a method of
   militating against denial-of-service attacks by selectively
   discarding traffic based on source or destination address.  Remote
   triggered black hole routing describes a method of selectively re-
   routing traffic into a sinkhole router (for further analysis) based
   on destination address.  This document explains why a unique IPv6
   prefix should be formally assigned by IANA for the purpose of
   facilitating IPv6 remote triggered black hole filtering and routing.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv6-discard-prefix-01=
.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-v6ops-ipv6-discard-prefix-01.=
txt


From jason_livingood@cable.comcast.com  Mon Nov 21 14:04:47 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D4F211E80F2 for ; Mon, 21 Nov 2011 14:04:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.463
X-Spam-Level: 
X-Spam-Status: No, score=-108.463 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W6E1AolKCKuX for ; Mon, 21 Nov 2011 14:04:46 -0800 (PST)
Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id 930FA21F86EC for ; Mon, 21 Nov 2011 14:04:46 -0800 (PST)
Received: from ([24.40.55.42]) by pacdcimo01.cable.comcast.com with ESMTP  id 5503620.146862057; Mon, 21 Nov 2011 17:04:41 -0500
Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%11]) with mapi id 14.01.0339.001; Mon, 21 Nov 2011 17:05:04 -0500
From: "Livingood, Jason" 
To: Brian E Carpenter , Fred Baker 
Thread-Topic: Title of draft-ietf-v6ops-v6-aaaa-whitelisting-implications-07
Thread-Index: AQHMqJmRYTsIZKVSlU+BpJEq8n3Shg==
Date: Mon, 21 Nov 2011 22:04:40 +0000
Message-ID: 
In-Reply-To: <4EA6179A.1080701@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.13.0.110805
x-originating-ip: [147.191.227.196]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3A9FF8C16B1A4542B7F8449D398CC42A@cable.comcast.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "v6ops@ietf.org" 
Subject: [v6ops] Title of draft-ietf-v6ops-v6-aaaa-whitelisting-implications-07
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 21 Nov 2011 22:04:47 -0000

I'll be posting the -08 update tomorrow (list responses formally noting
the feedback accepted to follow tomorrow). The only open question I see is
on the title of the I-D - a question raised by Brian Carpenter below.

The current title is: Considerations for Transitioning Content to IPv6

Brian has proposed: Considerations for Content Provision during IPv4/IPv6
Coexistence

I have not seen other objections to the title or any other feedback since
Brian's email.

IMHO the current title is a bit simpler and I am inclined to keep it
as-is, unless I hear feedback to the contrary here. But I'm open to
whatever direction the WG wishes to go in.

- Jason



On 10/24/11 9:57 PM, "Brian E Carpenter" 
wrote:

>I have a slight quibble with the revised title. I understand why the
>title has been broadened, but it now claims a very wide scope:
>  Considerations for Transitioning Content to IPv6
>
>How about:
>  Considerations for Content Provision during IPv4/IPv6 Coexistence


From jason_livingood@cable.comcast.com  Mon Nov 21 14:05:43 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4502121F8876 for ; Mon, 21 Nov 2011 14:05:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.162
X-Spam-Level: 
X-Spam-Status: No, score=-108.162 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, 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 e7+pEB82rCKa for ; Mon, 21 Nov 2011 14:05:39 -0800 (PST)
Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id CEDEE11E80F9 for ; Mon, 21 Nov 2011 14:05:38 -0800 (PST)
Received: from ([24.40.55.41]) by pacdcimo01.cable.comcast.com with ESMTP  id 5503620.146862143; Mon, 21 Nov 2011 17:05:17 -0500
Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%11]) with mapi id 14.01.0339.001; Mon, 21 Nov 2011 17:05:06 -0500
From: "Livingood, Jason" 
To: "George, Wes" , "v6ops@ietf.org" , Hannes Tschofenig , Alissa Cooper 
Thread-Topic: [v6ops] Privacy Considerations of draft-ietf-v6ops-v6-aaaa-whitelisting-implications-07
Thread-Index: AQHMinlLVd5oLAhHAkmF5cjsRUKZfZV7+jDwgDwkIgA=
Date: Mon, 21 Nov 2011 22:05:06 +0000
Message-ID: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.13.0.110805
x-originating-ip: [147.191.227.196]
Content-Type: multipart/alternative; boundary="_000_CAF031984398Cjasonlivingoodcablecomcastcom_"
MIME-Version: 1.0
Subject: Re: [v6ops] Privacy Considerations of draft-ietf-v6ops-v6-aaaa-whitelisting-implications-07
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 21 Nov 2011 22:05:43 -0000

--_000_CAF031984398Cjasonlivingoodcablecomcastcom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

I will shortly be making the =9608 update (tomorrow).

Wes =96 I have made your proposed changes.

Thanks!
Jason

On 10/14/11 11:44 AM, "George, Wes" > wrote:

I think that the first two paragraphs are useful, and that you should keep =
6.2 pretty much as-is, but remove =93probably=94 in both of the places that=
 it is used.

Thanks,

Wes George

From: v6ops-bounces@ietf.org [mailto:v6ops-b=
ounces@ietf.org] On Behalf Of Livingood, Jason
Sent: Friday, October 14, 2011 9:58 AM
To: v6ops@ietf.org; Hannes Tschofenig; Alissa Cooper
Subject: [v6ops] Privacy Considerations of draft-ietf-v6ops-v6-aaaa-whiteli=
sting-implications-07

One open question on the latest draft is in Section 6.2, pertaining to Priv=
acy Considerations. One reviewer has suggestion removing the first two para=
graphs in this section (http://tools.ietf.org/html/draft-ietf-v6ops-v6-aaaa=
-whitelisting-implications-07#section-6.2) and leaving only the third parag=
raph.

I am asking for feedback from the v6ops WG and from 2 IAB members here, Ali=
ssa and Hannes, who have been vocal on the topic of privacy consideration s=
ections. My inclination is to leave the section largely as it is now in a l=
onger form, rather than reducing it down (more detail being better).

Any opinions in the WG or from Alissa or Hannes?

Thanks!
Jason

________________________________
This E-mail and any of its attachments may contain Time Warner Cable propri=
etary information, which is privileged, confidential, or subject to copyrig=
ht belonging to Time Warner Cable. This E-mail is intended solely for the u=
se of the individual or entity to which it is addressed. If you are not the=
 intended recipient of this E-mail, you are hereby notified that any dissem=
ination, distribution, copying, or action taken in relation to the contents=
 of and attachments to this E-mail is strictly prohibited and may be unlawf=
ul. If you have received this E-mail in error, please notify the sender imm=
ediately and permanently delete the original and any copy of this E-mail an=
d any printout.

--_000_CAF031984398Cjasonlivingoodcablecomcastcom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: 
Content-Transfer-Encoding: quoted-printable











I will shortly be making the =9608 update (tomorrow). 











Wes =96 I have made your proposed changes. 







Thanks!


Jason










On 10/14/11 11:44 AM, "George, Wes" <wesley.george@twcable.com> wrote:



















I think that the first two paragra=
phs are useful, and that you should keep 6.2 pretty much as-is, but remove =
=93probably=94 in both of the places that
 it is used.


 




Thanks,


 


Wes George=





 








From:
v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org]
On Behalf Of Livingood, Jason

Sent: Friday, October 14, 2011 9:58 AM

To: v6ops@ietf.org; Hannes Tsc=
hofenig; Alissa Cooper

Subject: [v6ops] Privacy Considerations of draft-ietf-v6ops-v6-aaaa-=
whitelisting-implications-07






 




One open question on the latest draft is in Section 6.2, perta=
ining to Privacy Considerations. One reviewer has suggestion removing the f=
irst two paragraphs in this section
 (http://tools.ietf.org/html/draft-ietf-v6ops=
-v6-aaaa-whitelisting-implications-07#section-6.2) and leaving only the=
 third paragraph. 






 






I am asking for feedback from the v6ops WG and from 2 IAB memb=
ers here, Alissa and Hannes, who have been vocal on the topic of privacy co=
nsideration sections. My inclination
 is to leave the section largely as it is now in a longer form, rather than=
 reducing it down (more detail being better). 






 






Any opinions in the WG or from Alissa or Hannes?






 






Thanks!






Jason











This E-mail and any of its a=
ttachments 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 a=
re not the intended recipient of this E-mail, you are hereby notified that =
any dissemination, distribution, copying, or action taken in relation to th=
e contents of and attachments to
 this E-mail is strictly prohibited and may be unlawful. If you have receiv=
ed this E-mail in error, please notify the sender immediately and permanent=
ly delete the original and any copy of this E-mail and any printout.











--_000_CAF031984398Cjasonlivingoodcablecomcastcom_--

From jason_livingood@cable.comcast.com  Mon Nov 21 14:05:48 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7977711E812B for ; Mon, 21 Nov 2011 14:05:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.698
X-Spam-Level: 
X-Spam-Status: No, score=-104.698 tagged_above=-999 required=5 tests=[AWL=-3.564, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, 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 e6hsHjTCA+M7 for ; Mon, 21 Nov 2011 14:05:44 -0800 (PST)
Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id 56F7F11E8129 for ; Mon, 21 Nov 2011 14:05:44 -0800 (PST)
Received: from ([24.40.55.42]) by copdcimo01.cable.comcast.com with ESMTP  id 5503630.62295583; Mon, 21 Nov 2011 15:05:44 -0700
Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%11]) with mapi id 14.01.0339.001; Mon, 21 Nov 2011 17:05:44 -0500
From: "Livingood, Jason" 
To: Alissa Cooper , "George, Wes" 
Thread-Topic: [v6ops] Privacy Considerations of draft-ietf-v6ops-v6-aaaa-whitelisting-implications-07
Thread-Index: AQHMinlLVd5oLAhHAkmF5cjsRUKZfZV7+jDwgA4HewCALhy5gA==
Date: Mon, 21 Nov 2011 22:05:20 +0000
Message-ID: 
In-Reply-To: <3633E819-B568-4CB6-B1F5-8DA0090E72AC@cdt.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.13.0.110805
x-originating-ip: [147.191.227.196]
Content-Type: multipart/alternative; boundary="_000_CAF031BF4398Ejasonlivingoodcablecomcastcom_"
MIME-Version: 1.0
Cc: "v6ops@ietf.org" , Hannes Tschofenig 
Subject: Re: [v6ops] Privacy Considerations of draft-ietf-v6ops-v6-aaaa-whitelisting-implications-07
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 21 Nov 2011 22:05:48 -0000

--_000_CAF031BF4398Ejasonlivingoodcablecomcastcom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Thanks for your feedback as well, Alissa. These changes to the 1st and 2nd
paragraphs in the Privacy Considerations section will be made. This will
be in a -08 update tomorrow.

As for the device fingerprinting item - thanks for the heads up, that will
be useful in other I-Ds I am working on. In terms of this document, with
the changes you proposed and I have made for the -08 version, we should
not need to mention this since the information will be aggregate-level and
not more detailed.

- Jason



On 10/23/11 5:54 AM, "Alissa Cooper" > wrote:

I agree. I would suggest some tweaks to the first paragraph to make the
intent and applicability more clear:

As noted in Section 4.1, there is a benefit in sharing IPv6-related
   impairment statistics within the Internet community over time.  Any
   statistics that are shared or disclosed publicly should be aggregate
statistics, such as
   "the domain example.com has observed an average daily impairment rate
   of 0.05% in September 2011, down from 0.15% in January 2011".  They
should not include information that can directly or indirectly identify
individuals, such as names or email addresses.  Sharing only aggregate
data can help
   protect end user privacy and any information which may be proprietary
   to a domain.

In the second paragraph you might replace "or otherwise" with "and" since
advising an end user is not necessarily a means of obtaining consent.

Incidentally, the IAB has published draft guidance about privacy
considerations,
http://tools.ietf.org/html/draft-iab-privacy-considerations-01. One of
the areas that the guidance highlights is device fingerprinting. I assume
that IPv6 impairment status is a piece of information that can make a
device more susceptible to being uniquely fingerprinted; it might be
worth mentioning that in this section to illustrate why impairment status
should be disclosed/shared with care.

Alissa

On Oct 14, 2011, at 4:44 PM, George, Wes wrote:

I think that the first two paragraphs are useful, and that you should
keep 6.2 pretty much as-is, but remove =93probably=94 in both of the places
that it is used.

Thanks,

Wes George

From: v6ops-bounces@ietf.org [mailto:v6ops-b=
ounces@ietf.org] On Behalf
Of Livingood, Jason
Sent: Friday, October 14, 2011 9:58 AM
To: v6ops@ietf.org; Hannes Tschofenig; Alissa Cooper
Subject: [v6ops] Privacy Considerations of
draft-ietf-v6ops-v6-aaaa-whitelisting-implications-07

One open question on the latest draft is in Section 6.2, pertaining to
Privacy Considerations. One reviewer has suggestion removing the first
two paragraphs in this section
(http://tools.ietf.org/html/draft-ietf-v6ops-v6-aaaa-whitelisting-implica
tions-07#section-6.2) and leaving only the third paragraph.

I am asking for feedback from the v6ops WG and from 2 IAB members here,
Alissa and Hannes, who have been vocal on the topic of privacy
consideration sections. My inclination is to leave the section largely
as it is now in a longer form, rather than reducing it down (more detail
being better).

Any opinions in the WG or from Alissa or Hannes?

Thanks!
Jason
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.



--_000_CAF031BF4398Ejasonlivingoodcablecomcastcom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <718AA8AD16EB914CA5D3AD5A19230264@cable.comcast.com>
Content-Transfer-Encoding: quoted-printable







Thanks for your feedback as well, Alissa. These changes to the 1st and=
 2nd 


paragraphs in the Privacy Considerations section will be made. This wi=
ll 


be in a -08 update tomorrow.  







As for the device fingerprinting item - thanks for the heads up, that =
will 


be useful in other I-Ds I am working on. In terms of this document, wi=
th 


the changes you proposed and I have made for the -08 version, we shoul=
d 


not need to mention this since the information will be aggregate-level=
 and 


not more detailed.







- Jason

















On 10/23/11 5:54 AM, "Alissa Cooper" <acooper@cdt.org> wrote:









I agree. I would suggest some tweaks to the first paragraph to make th=
e 


intent and applicability more clear:







As noted in Section 4.1, there is a benefit in sharing IPv6-related

   impairment statistics within the Internet community over =
time.  Any


   statistics that are shared or disclosed publicly should b=
e aggregate 


statistics, such as


   "the domain example.com has observed an average dail=
y impairment rate


   of 0.05% in September 2011, down from 0.15% in January 20=
11".  They 


should not include information that can directly or indirectly identif=
y 


individuals, such as names or email addresses.  Sharing only=
 aggregate 


data can help


   protect end user privacy and any information which may be=
 proprietary


   to a domain.







In the second paragraph you might replace "or otherwise" wit=
h "and" since 


advising an end user is not necessarily a means of obtaining consent.<=
/div>






Incidentally, the IAB has published draft guidance about privacy 

considerations, 



the areas that the guidance highlights is device fingerprinting. I ass=
ume 


that IPv6 impairment status is a piece of information that can make a =



device more susceptible to being uniquely fingerprinted; it might be <=
/div>

worth mentioning that in this section to illustrate why impairment sta=
tus 


should be disclosed/shared with care.







Alissa







On Oct 14, 2011, at 4:44 PM, George, Wes wrote:









I think that the first two paragraphs are useful, and that you should =



keep 6.2 pretty much as-is, but remove =93probably=94 in both of the p=
laces 


that it is used.


  


Thanks,


  


Wes George


  



Of Livingood, Jason


Sent: Friday, October 14, 2011 9:58 AM


To: v6ops@ietf.org; Hannes Tscho=
fenig; Alissa Cooper


Subject: [v6ops] Privacy Considerations of 


draft-ietf-v6ops-v6-aaaa-whitelisting-implications-07


  


One open question on the latest draft is in Section 6.2, pertaining to=
 


Privacy Considerations. One reviewer has suggestion removing the first=
 


two paragraphs in this section 



tions-07#section-6.2) and leaving only the third paragraph. 


  


I am asking for feedback from the v6ops WG and from 2 IAB members here=
, 


Alissa and Hannes, who have been vocal on the topic of privacy 


consideration sections. My inclination is to leave the section largely=
 


as it is now in a longer form, rather than reducing it down (more deta=
il 


being better). 


  


Any opinions in the WG or from Alissa or Hannes?


  


Thanks!


Jason




This E-mail and any of its attachments may contain Time Warner Cable <=
/div>

proprietary information, which is privileged, confidential, or subject=
 


to copyright belonging to Time Warner Cable. This E-mail is intended <=
/div>

solely for the use of the individual or entity to which it is addresse=
d. 


If you are not the intended recipient of this E-mail, you are hereby <=
/div>

notified that any dissemination, distribution, copying, or action take=
n 


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.

















--_000_CAF031BF4398Ejasonlivingoodcablecomcastcom_--

From jason_livingood@cable.comcast.com  Mon Nov 21 14:06:09 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D02711E8125 for ; Mon, 21 Nov 2011 14:06:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -107.472
X-Spam-Level: 
X-Spam-Status: No, score=-107.472 tagged_above=-999 required=5 tests=[AWL=0.991, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GoA3SgRtms5J for ; Mon, 21 Nov 2011 14:06:06 -0800 (PST)
Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id 70C9011E8132 for ; Mon, 21 Nov 2011 14:05:58 -0800 (PST)
Received: from ([24.40.55.41]) by pacdcimo01.cable.comcast.com with ESMTP  id 5503620.146862254; Mon, 21 Nov 2011 17:05:55 -0500
Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%11]) with mapi id 14.01.0339.001; Mon, 21 Nov 2011 17:05:55 -0500
From: "Livingood, Jason" 
To: Fred Baker , Lorenzo Colitti 
Thread-Topic: [v6ops] Update of draft-ietf-v6ops-v6-aaaa-whitelisting-implications-07
Thread-Index: AQHMqJm9HhUKqsKx+EWs7egnINCdPQ==
Date: Mon, 21 Nov 2011 22:05:54 +0000
Message-ID: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.13.0.110805
x-originating-ip: [147.191.227.196]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] Update of draft-ietf-v6ops-v6-aaaa-whitelisting-implications-07
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 21 Nov 2011 22:06:09 -0000

I agree Fred - not sure this is actionable for this I-D.


Thanks
Jason

PS - There are 2 or 3 other bits of feedback that I'll close out on this
I-D tomorrow.

On 10/14/11 2:29 PM, "Fred Baker"  wrote:

>
>On Oct 14, 2011, at 11:19 AM, Lorenzo Colitti wrote:
>
>> One thing that happy eyeballs doesn't help you with is MTU holes.
>
>There are two obvious solutions to the PMTU problem: don't filter
>ICMP/ICMPv6, and
>
>https://tools.ietf.org/html/rfc4821
>4821 Packetization Layer Path MTU Discovery. M. Mathis, J. Heffner.
>     March 2007. (Format: TXT=3D75665 bytes) (Status: PROPOSED STANDARD)
>
>I'm in favor of both...
>
>Not sure what that has to do with AAAA Whitelisting.
>_______________________________________________
>v6ops mailing list
>v6ops@ietf.org
>https://www.ietf.org/mailman/listinfo/v6ops


From brian.e.carpenter@gmail.com  Mon Nov 21 14:26:08 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C464011E80EF for ; Mon, 21 Nov 2011 14:26:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.203
X-Spam-Level: 
X-Spam-Status: No, score=-103.203 tagged_above=-999 required=5 tests=[AWL=-0.204, BAYES_00=-2.599, 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 YOVjRDOcOCS4 for ; Mon, 21 Nov 2011 14:26:04 -0800 (PST)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id A951E11E809B for ; Mon, 21 Nov 2011 14:26:04 -0800 (PST)
Received: by vcbfy13 with SMTP id fy13so3658645vcb.31 for ; Mon, 21 Nov 2011 14:26:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=6yuYvuqjDPGvUSlI05SXr94tgOMJjMhA7LQZ8f3wEbU=; b=GK+Obt8lpnySlTdSN+yw97zaDFWG6J3zRaacYR+Z1uDOzwFfCTy48szDysRCSYSip7 5RP/eX/gJpyvNws7gwocVYXbYG4OfaPDjvCOSEUtTpYsIXL2F+Ly8y00/WYONqqegr3u eznxFWGV30SafSi0LGy0Nh0KTFpzoy2ei5cuI=
Received: by 10.52.174.65 with SMTP id bq1mr17460063vdc.30.1321914364042; Mon, 21 Nov 2011 14:26:04 -0800 (PST)
Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id ib2sm16074666vdb.1.2011.11.21.14.26.00 (version=SSLv3 cipher=OTHER); Mon, 21 Nov 2011 14:26:03 -0800 (PST)
Message-ID: <4ECACFF5.6020804@gmail.com>
Date: Tue, 22 Nov 2011 11:25:57 +1300
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Fred Baker 
References: <20111115062859.14026.74743.idtracker@ietfa.amsl.com> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: Pete Resnick , Wesley Eddy , "v6ops@ietf.org WG" , "ietfdbh@comcast.net Harrington" , draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat@tools.ietf.org
Subject: Re: [v6ops] New Version Notification -	draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-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, 21 Nov 2011 22:26:08 -0000

I still support this draft as modified.

There is a new concern however, namely the strenuous objections that
have been raised recently against draft-ietf-mif-dhcpv6-route-option.
If that document is blocked, this document becomes pointless, or
at least needs major rewriting to explain how RA/RIO (RFC 4191) can
be used despite its problems.

Also, I know this is far too late, but I really didn't like the Abstract
when I read it again. It seems to say the least important thing first and
comes across as negative. I propose a complete rewrite:

This document describes a practical approach to multihoming a small IPv6
user site using readily available solutions that permit address transparency
without sacrificing security. Specifically, such a site requires source
address selection, next-hop resolution and DNS resolution. We analyze the
use cases of multihoming and describe functional requirements and possible
solutions for multihoming for hosts and small IPv6 networks that are unable
to meet minimum IPv6 address allocation criteria. Such sites can only use
address space derived from their multiple providers. We conclude that DHCPv6
based solutions are suitable to meet the multihoming issues described in
this document. In particular, we show that the IPv4 approach to this problem
based on Network Address and Port Translation (NAPT) is unnecessary for IPv6,
although Network Prefix Translation (NPTv6) might be appropriate in some
transitional situations.

   Brian

On 2011-11-18 03:06, Fred Baker wrote:
> Folks:
> 
> Please review http://tinyurl.com/7gw45ma and comment. In view of a US holiday next week, I'll give you through 2 December. The changes have been made in response to IESG "Discuss" comments. The question is whether the working group still agrees with the draft.
> 
> Fred
> 
> On Nov 15, 2011, at 2:28 PM, Internet-Drafts@ietf.org wrote:
> 
>> New version (-03) has been submitted for draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-03.txt.
>> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-03.txt
>>
>>
>> Diff from previous version:
>> http://tools.ietf.org/rfcdiff?url2=draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-03
>>
>> IETF Secretariat.
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
> 

From Ted.Lemon@nominum.com  Mon Nov 21 16:34:20 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDF011F0C7E for ; Mon, 21 Nov 2011 16:34:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.573
X-Spam-Level: 
X-Spam-Status: No, score=-106.573 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 HvR1klZGg5DT for ; Mon, 21 Nov 2011 16:34:20 -0800 (PST)
Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA9B1F0C79 for ; Mon, 21 Nov 2011 16:34:19 -0800 (PST)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKTsruBOA8qJMzNQrJXZ2pzinxj4ZH8z00@postini.com; Mon, 21 Nov 2011 16:34:20 PST
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id B91CD1B82A9 for ; Mon, 21 Nov 2011 16:34:11 -0800 (PST)
Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 9C892190052; Mon, 21 Nov 2011 16:34:11 -0800 (PST) (envelope-from Ted.Lemon@nominum.com)
Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.01.0339.001; Mon, 21 Nov 2011 16:34:11 -0800
From: Ted Lemon 
To: Brian E Carpenter 
Thread-Topic: [v6ops] New Version Notification	- draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-03.txt
Thread-Index: AQHMqJyVBg59WZHjy0KH6Epa3rEMLpW4kbqA
Date: Tue, 22 Nov 2011 00:34:11 +0000
Message-ID: 
References: <20111115062859.14026.74743.idtracker@ietfa.amsl.com>  <4ECACFF5.6020804@gmail.com>
In-Reply-To: <4ECACFF5.6020804@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.1.10]
Content-Type: multipart/alternative; boundary="_000_C0D3C625895542E3B7B1109552525966nominumcom_"
MIME-Version: 1.0
Cc: "v6ops@ietf.org WG" , Wesley Eddy , Pete Resnick , "" , "ietfdbh@comcast.net Harrington" 
Subject: Re: [v6ops] New Version Notification	-	draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-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: Tue, 22 Nov 2011 00:34:21 -0000

--_000_C0D3C625895542E3B7B1109552525966nominumcom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

On Nov 21, 2011, at 5:25 PM, Brian E Carpenter wrote:
There is a new concern however, namely the strenuous objections that
have been raised recently against draft-ietf-mif-dhcpv6-route-option.
If that document is blocked, this document becomes pointless, or
at least needs major rewriting to explain how RA/RIO (RFC 4191) can
be used despite its problems.

Using the DHCPv6 route option, even if it is approved, to solve this proble=
m is unnecessary and, I would claim, harmful.   What you should actually do=
 is clear the A bit on one of the two advertised prefixes, and also set the=
 M bit in the RA message.   Now you can trivially control which hosts use t=
he second prefix, using DHCP, which prevents broken hosts from autoconfigur=
ing addresses on it.

Fundamentally, what this draft seems to be saying is "a plurality of IPv6 i=
mplementations are broken.   Some IPv6 implementations are not broken.   He=
re's how you do multihoming for non-broken hosts without causing broken hos=
ts to *completely* fail."   I do not love this solution.   The right thing =
to do is to fix the broken hosts.   I'm against changing the IPv6 architect=
ure to deal with this problem.

Since it's possible to write this document without changing the IPv6 archit=
ecture, I think that's the right thing to do.


--_000_C0D3C625895542E3B7B1109552525966nominumcom_
Content-Type: text/html; charset="us-ascii"
Content-ID: <4746290DD29974459DAD2B0347E8D39E@nominum.com>
Content-Transfer-Encoding: quoted-printable









On Nov 21, 2011, at 5:25 PM, Brian E Carpenter wrote:


There
 is a new concern however, namely the strenuous objections that

have been raised recently against draft-ietf-mif-dhcpv6-route-option.

If that document is blocked, this document becomes pointless, or

at least needs major rewriting to explain how RA/RIO (RFC 4191) can

be used despite its problems.






Using the DHCPv6 route option, even if it is approved, to solve this p=
roblem is unnecessary and, I would claim, harmful.   What you should a=
ctually do is clear the A bit on one of the two advertised prefixes, and al=
so set the M bit in the RA message.  
 Now you can trivially control which hosts use the second prefix, using DHC=
P, which prevents broken hosts from autoconfiguring addresses on it.







Fundamentally, what this draft seems to be saying is "a plurality=
 of IPv6 implementations are broken.   Some IPv6 implementations are n=
ot broken.   Here's how you do multihoming for non-broken hosts withou=
t causing broken hosts to *completely* fail."  
 I do not love this solution.   The right thing to do is to fix the br=
oken hosts.   I'm against changing the IPv6 architecture to deal with =
this problem.







Since it's possible to write this document without changing the IPv6 a=
rchitecture, I think that's the right thing to do.









--_000_C0D3C625895542E3B7B1109552525966nominumcom_--

From shemant@cisco.com  Mon Nov 21 17:41:07 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58D0E21F8B08 for ; Mon, 21 Nov 2011 17:41:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.26
X-Spam-Level: 
X-Spam-Status: No, score=-6.26 tagged_above=-999 required=5 tests=[AWL=0.339,  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 2Yk5chd8GmOV for ; Mon, 21 Nov 2011 17:41:03 -0800 (PST)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1562621F8B06 for ; Mon, 21 Nov 2011 17:41:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=1006; q=dns/txt; s=iport; t=1321926063; x=1323135663; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=Eq1UugeOdMWnJOMyvG8SU7/U2cYFcU5fJQbel6TMWls=; b=l1Y7Ph0TjyRIuR2zWITUVPMTWjh4M/qDFbHjZbt7OehpjbQwdd8yncaE tUX8yfLb+P2tjDVigCo81kx4QskQEsdkoMee4J6VcSNnIsjXqNaD0GTvq mfya1Rmt7lADSM5PI1UFb98CeYY2qtXSXrm+IHD/8rENq6GlKcv3rdgm7 o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqMAAH/9yk6tJV2b/2dsb2JhbABDmieQGoEFgXIBAQEEEgEdCj8MBAIBCBABBAEBCwYXAQYBRQkIAQEEARIIARmHaZYJAZ5iiTRjBIgakWeMXg
X-IronPort-AV: E=Sophos;i="4.69,551,1315180800"; d="scan'208";a="38017606"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 22 Nov 2011 01:41:02 +0000
Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pAM1f2uf004507;  Tue, 22 Nov 2011 01:41:02 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 21 Nov 2011 19:41:02 -0600
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 21 Nov 2011 19:41:00 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3035EEA99@XMB-RCD-109.cisco.com>
In-Reply-To: <201111150855.pAF8teRU051375@givry.fdupont.fr>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] 6rd Sunsetting
Thread-Index: AcyjdGjsnVIO06agRtGEnxHldAuK0AFQjYFw
References: Your message of Tue, 15 Nov 2011 16:45:54 +0800. <201111150855.pAF8teRU051375@givry.fdupont.fr>
From: "Hemant Singh (shemant)" 
To: "Francis Dupont" , "Mark Townsley" 
X-OriginalArrivalTime: 22 Nov 2011 01:41:02.0366 (UTC) FILETIME=[CAE923E0:01CCA8B7]
Cc: Alexandre Cassen , v6ops@ietf.org, Claire Cheng 
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Nov 2011 01:41:07 -0000

-----Original Message-----
From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
Of Francis Dupont
Sent: Tuesday, November 15, 2011 3:56 AM
To: Mark Townsley
Cc: Alexandre Cassen; v6ops@ietf.org WG; Claire Cheng
Subject: Re: [v6ops] 6rd Sunsetting

  =20
>=3D> I am a bit subscriber oriented (perhaps because I am myself
>a 6rd user) so I read the question about use case as can a subscriber
>be provided with both 6rd and native IPv6 service at the same time
>by an ISP? and IMHO the answer is in general no.

Use case already described in rfc6204bis.  See last paragraph of section
4.4.3 in

http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-02

Also see the same use case I replied to in

http://www.ietf.org/mail-archive/web/v6ops/current/msg10718.html

The summary is that even when the Preferred Lifetime is sent as zero to
a node, the prefix lingers for two hours or less and thus 6rd and native
IPv6 coexist concurrently on the CE router.

Hemant


From satoru.matsushima@gmail.com  Mon Nov 21 17:43:18 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B65AB1F0C85 for ; Mon, 21 Nov 2011 17:43:18 -0800 (PST)
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 Sbe5Mz0hlFpd for ; Mon, 21 Nov 2011 17:43:18 -0800 (PST)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 041601F0C83 for ; Mon, 21 Nov 2011 17:43:17 -0800 (PST)
Received: by iaeo4 with SMTP id o4so9685978iae.31 for ; Mon, 21 Nov 2011 17:43:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=U8BllnPOLfhFucT3dmD6mrOOJ3elwXXIYAT+nNagh7Y=; b=dgIH3YpSe4gV8l1uA+0KmE2LoOnrB21dKEObDie9PS/jQqfjHm2vapqMGMTiYJR90T Rj67fnAV+SYYN+JLi26NvoZpm6dwW1mC8/sEbK3OwpYrIgum+5yP4FMUJHWBHbXtrRgm 1VdfUeoV6YUFDQmxnvR2Uhkz9srEbDqCKLm6w=
Received: by 10.231.21.149 with SMTP id j21mr3924526ibb.29.1321926197646; Mon, 21 Nov 2011 17:43:17 -0800 (PST)
Received: from [10.201.82.125] ([202.45.12.141]) by mx.google.com with ESMTPS id j1sm30167837igq.2.2011.11.21.17.43.14 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 21 Nov 2011 17:43:16 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=us-ascii
From: Satoru Matsushima 
In-Reply-To: 
Date: Tue, 22 Nov 2011 10:43:12 +0900
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20111115062859.14026.74743.idtracker@ietfa.amsl.com>  <4ECACFF5.6020804@gmail.com> 
To: Ted Lemon 
X-Mailer: Apple Mail (2.1251.1)
Cc: "v6ops@ietf.org WG" , Wesley Eddy , Pete Resnick , "" , "ietfdbh@comcast.net Harrington" 
Subject: Re: [v6ops] New Version Notification	- draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-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: Tue, 22 Nov 2011 01:43:18 -0000

On 2011/11/22, at 9:34, Ted Lemon wrote:

> On Nov 21, 2011, at 5:25 PM, Brian E Carpenter wrote:
>> There is a new concern however, namely the strenuous objections that
>> have been raised recently against draft-ietf-mif-dhcpv6-route-option.
>> If that document is blocked, this document becomes pointless, or
>> at least needs major rewriting to explain how RA/RIO (RFC 4191) can
>> be used despite its problems.
>=20
> Using the DHCPv6 route option, even if it is approved, to solve this =
problem is unnecessary and, I would claim, harmful.   What you should =
actually do is clear the A bit on one of the two advertised prefixes, =
and also set the M bit in the RA message.   Now you can trivially =
control which hosts use the second prefix, using DHCP, which prevents =
broken hosts from autoconfiguring addresses on it.

This draft mentions not only which prefix hosts use.
Please read the scenarios in the draft.

>=20
> Fundamentally, what this draft seems to be saying is "a plurality of =
IPv6 implementations are broken.   Some IPv6 implementations are not =
broken.   Here's how you do multihoming for non-broken hosts without =
causing broken hosts to *completely* fail."   I do not love this =
solution.   The right thing to do is to fix the broken hosts.   I'm =
against changing the IPv6 architecture to deal with this problem.
>=20

This draft doesn't mention implementation specific brokenness.
Again, please read the scenarios in the draft.


> Since it's possible to write this document without changing the IPv6 =
architecture, I think that's the right thing to do.

I'm not sure what the IPv6 architecture you assume. We don't say that RA =
is not necessary, but we say DHCPv6 is most realistic to solve =
multihoming issue without any kind of IPv6 NAT. Do you say that without =
changing the IPv6 architecture means IPv6 NAT is the right thing to do?

cheers,
--satoru=

From frnkblk@iname.com  Mon Nov 21 19:39:30 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11E5F21F89BA for ; Mon, 21 Nov 2011 19:39:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.658
X-Spam-Level: 
X-Spam-Status: No, score=-0.658 tagged_above=-999 required=5 tests=[AWL=-1.018, BAYES_20=-0.74, FROM_LOCAL_NOVOWEL=0.5, 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 COpJ8si3fQHr for ; Mon, 21 Nov 2011 19:39:29 -0800 (PST)
Received: from premieronline.net (mail.premieronline.net [96.31.0.20]) by ietfa.amsl.com (Postfix) with ESMTP id 7631B21F893C for ; Mon, 21 Nov 2011 19:39:29 -0800 (PST)
X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=199.120.69.4; 
Received: from BULKFAMLAPTOP (unverified [199.120.69.4])  by premieronline.net (SurgeMail 5.0n) with ESMTP (TLS) id 33929700-1729245 for multiple; Mon, 21 Nov 2011 21:39:28 -0600
From: "Frank Bulk" 
To: "'Ole Troan'" 
References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com><5B6B2B64C9FE2A489045EEEADDAFF2C30354473D@XMB-RCD-109.cisco.com><4EC455D6.8030601@bogus.com><7EB596BF-B175-40BF-ABC8-326599670B04@apple.com><5B6B2B64C9FE2A489045EEEADDAFF2C303544B88@XMB-RCD-109.cisco.com>	<8D342733-88E6-45D3-B388-E001AE32CD77@employees.org>	<750BF7861EBBE048B3E648B4BB6E8F4F20DC4FEA@crexc50p> 
In-Reply-To: 
Date: Mon, 21 Nov 2011 21:39:27 -0600
Message-ID: <007801cca8c8$5610aa00$0231fe00$@iname.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AcymJPZAobN0WxheSNm3pw5n6pa51QCo1U2g
Content-Language: en-us
X-Authenticated-User: fbulk@premieronline.net 
X-SpamDetect: : 0.000000 
X-Info: aspam skipped due to (g_smite_skip_auth)
X-Encryption: SSL encrypted
X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=0 Stars=0 Good=21 Friend=4 Surbl=0 Catch=0 r=0 ip=199.120.69.4
X-IP-stats: Incoming Last 0, First 987, in=1692, out=0, spam=0 ip=199.120.69.4
Cc: IPv6 Operations 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Nov 2011 03:39:30 -0000

What's fuzzy?

-----Original Message-----
From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of
Ole Troan
Sent: Friday, November 18, 2011 1:05 PM
To: STARK, BARBARA H
Cc: IPv6 Operations
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT



I'm afraid not. the text is just fuzzing the issue.
what are the use case for a CPE not trying to acquire a prefix?

I do expect things to change as a "homenet router" gets defined.

let's hold off on 6204bis until we have real new requirements.

cheers,
Ole
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops



From Ted.Lemon@nominum.com  Mon Nov 21 19:42:09 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88A4C11E80D5 for ; Mon, 21 Nov 2011 19:42:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.573
X-Spam-Level: 
X-Spam-Status: No, score=-106.573 tagged_above=-999 required=5 tests=[AWL=0.026, 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 Mc81Hw+Fnucz for ; Mon, 21 Nov 2011 19:42:09 -0800 (PST)
Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id 98BD321F8A55 for ; Mon, 21 Nov 2011 19:42:08 -0800 (PST)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKTssaD2WUWxewegc5mbZyu2HJI4LpLCH+@postini.com; Mon, 21 Nov 2011 19:42:08 PST
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 27C5E1B8291 for ; Mon, 21 Nov 2011 19:42:07 -0800 (PST)
Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 1096C190052; Mon, 21 Nov 2011 19:42:07 -0800 (PST) (envelope-from Ted.Lemon@nominum.com)
Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.01.0339.001; Mon, 21 Nov 2011 19:42:06 -0800
From: Ted Lemon 
To: Satoru Matsushima 
Thread-Topic: [v6ops] New Version Notification	- draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-03.txt
Thread-Index: AQHMqLgd2RCDZISgFEK7gPUbq6X9qZW4xhOA
Date: Tue, 22 Nov 2011 03:42:06 +0000
Message-ID: <3D4D775D-E926-4F89-B279-75F0FE02B98F@nominum.com>
References: <20111115062859.14026.74743.idtracker@ietfa.amsl.com>  <4ECACFF5.6020804@gmail.com>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.1.10]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "v6ops@ietf.org WG" , Wesley Eddy , Pete Resnick , "" , "ietfdbh@comcast.net Harrington" 
Subject: Re: [v6ops] New Version Notification	- draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-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: Tue, 22 Nov 2011 03:42:09 -0000

On Nov 21, 2011, at 8:43 PM, Satoru Matsushima wrote:
> This draft mentions not only which prefix hosts use.
> Please read the scenarios in the draft.

I did, but the third scenario is just a MIF scenario, not a multihoming sce=
nario.   It's part of the MIF problem statement.

>> Fundamentally, what this draft seems to be saying is "a plurality of IPv=
6 implementations are broken.   Some IPv6 implementations are not broken.  =
 Here's how you do multihoming for non-broken hosts without causing broken =
hosts to *completely* fail."   I do not love this solution.   The right thi=
ng to do is to fix the broken hosts.   I'm against changing the IPv6 archit=
ecture to deal with this problem.
>>=20
>=20
> This draft doesn't mention implementation specific brokenness.
> Again, please read the scenarios in the draft.

It's true that the draft doesn't call it brokenness, but what it talks abou=
t _is_ brokenness, whether it's called that or not.

> I'm not sure what the IPv6 architecture you assume. We don't say that RA =
is not necessary, but we say DHCPv6 is most realistic to solve multihoming =
issue without any kind of IPv6 NAT. Do you say that without changing the IP=
v6 architecture means IPv6 NAT is the right thing to do?

No, that is not my position at all.   My position is that none of the scena=
rios you've described require a DHCPv6 route option to fix.   Indeed, the D=
HCPv6 route option is the wrong solution in all three scenarios: it perpetu=
ates brokenness instead of fixing the very real problems you've described.

These are exactly the same problem scenarios that I talked about in my pres=
entation in the DHC working group meeting.   There is wide agreement that t=
hese scenarios are a problem.   The MIF working group was chartered to fix =
at least scenario 3, and scenario 1 is in the problem statement as well.   =
Scenario 2 is the "really ugly problem" I described in my presentation in t=
he DHC working group.

These problems are solvable, and I think the MIF working group is capable o=
f solving them (although Scenario 2 will require some help from 6man).   I =
don't think we should be throwing out wholesale pieces of the internet arch=
itecture (specifically, RA) to solve this problem.   Or perhaps I should sa=
y that if we are considering doing that, we should admit that that's what w=
e're considering.

I'm agnostic=97it's pretty obvious to me that we can solve this with some b=
ackwards-compatible changes to RA.  So even though I personally would have =
preferred to use DHCP to solve this entire set of problems, since we didn't=
 do that, I think we should just fix RA.


From lorenzo@google.com  Mon Nov 21 21:51:09 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82C481F0C96 for ; Mon, 21 Nov 2011 21:51:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.884
X-Spam-Level: 
X-Spam-Status: No, score=-102.884 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UMtq8ttJQQZB for ; Mon, 21 Nov 2011 21:51:08 -0800 (PST)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id CBB961F0C8C for ; Mon, 21 Nov 2011 21:51:08 -0800 (PST)
Received: by ggnp4 with SMTP id p4so914398ggn.31 for ; Mon, 21 Nov 2011 21:51:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=RoGFM2EBz7dB2hWZGEqYqY5aH2tvVHSFF116KaIqBhU=; b=FmfIoO2q/udwugQBHWvrRhMLmozVl5y7XcxlVDwQumYSEumZF2IRK93fZJ7W0LrrPF XyZwaP58+r2ugq3g7LBA==
Received: by 10.236.183.52 with SMTP id p40mr24257766yhm.19.1321941068204; Mon, 21 Nov 2011 21:51:08 -0800 (PST)
Received: by 10.236.183.52 with SMTP id p40mr24257754yhm.19.1321941068105; Mon, 21 Nov 2011 21:51:08 -0800 (PST)
MIME-Version: 1.0
Received: by 10.150.202.14 with HTTP; Mon, 21 Nov 2011 21:50:47 -0800 (PST)
In-Reply-To: <750BF7861EBBE048B3E648B4BB6E8F4F20DC41F6@crexc50p>
References:   <68DAB112-6E32-45FE-9AB7-A34E64898F60@cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30354436E@XMB-RCD-109.cisco.com> <750BF7861EBBE048B3E648B4BB6E8F4F20DC41F6@crexc50p>
From: Lorenzo Colitti 
Date: Tue, 22 Nov 2011 14:50:47 +0900
Message-ID: 
To: "STARK, BARBARA H" 
Content-Type: multipart/alternative; boundary=bcaec52c5ea9c748b404b24c6300
X-System-Of-Record: true
Cc: v6ops@ietf.org, Claire Cheng , Alexandre Cassen 
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Nov 2011 05:51:09 -0000

--bcaec52c5ea9c748b404b24c6300
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Thu, Nov 17, 2011 at 14:29, STARK, BARBARA H  wrote:

> In reading through the 6rd sunsetting draft vs. 6204bis, I think we may
> not have fully covered the case (in 6204bis) where the same prefix is use=
d
> for 6rd and native. In this case, the philosophy of =93route based on sou=
rce
> address=94 won=92t work, and we should probably use the =93metric=94 appr=
oach
> proposed by the 6rd sunsetting draft. We also can=92t unprefer and invali=
date
> the prefix to the LAN.
>

Why do you need to route based on source address? If it's the same ISP
moving its users from 6rd to native, I would assume that it doesn't matter
whether the CPE sends packets out the native interface or the 6rd
interface, since they'll both be accepted by the ISP.

--bcaec52c5ea9c748b404b24c6300
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


On Thu, Nov 17, 2011 at 14:29, STARK, BARBARA H =
<bs7652@att.com&=
gt; wrote:



In reading through the 6rd sunsetting draft =
vs. 6204bis, I think we may not have fully covered the case (in 6204bis) wh=
ere the same prefix is used for 6rd and native. In this case, the philosoph=
y of =93route based on source address=94 won=92t work, and we should probab=
ly use the =93metric=94 approach proposed by the 6rd sunsetting draft. We a=
lso can=92t unprefer and invalidate the prefix to the LAN.




Why do you need to route based=
 on source address? If it's the same ISP moving its users from 6rd to n=
ative, I would assume that it doesn't matter whether the CPE sends pack=
ets out the native interface or the 6rd interface, since they'll both b=
e accepted by the ISP.





--bcaec52c5ea9c748b404b24c6300--

From victor.kuarsingh@gmail.com  Mon Nov 21 22:49:40 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D64C1F0C9B for ; Mon, 21 Nov 2011 22:49:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.219
X-Spam-Level: 
X-Spam-Status: No, score=-3.219 tagged_above=-999 required=5 tests=[AWL=-0.221, 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 bFii59tPykwP for ; Mon, 21 Nov 2011 22:49:39 -0800 (PST)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF601F0C97 for ; Mon, 21 Nov 2011 22:49:39 -0800 (PST)
Received: by yenm7 with SMTP id m7so3530146yen.31 for ; Mon, 21 Nov 2011 22:49:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UV9CkMY61/bDqHbJDJ285WpjGCAkznv8Vw2A+s7fqFg=; b=nrf7IU+QWXpNsRRfSSXBEiPVmHo6Ukb+vBzF7e5/Dj56+cpbWXPO1Jmg0Tytfkp2ns NhPJ0SO8hTRF7StcmFYM2t+TYpEyDa6VphcP2bsH81JE+MD5m1WSCeUqwaTnY57gXglt aO3PpGTBSLDDDRSyRCiT9Ur63+eMAkJ+jNQoI=
MIME-Version: 1.0
Received: by 10.68.59.1 with SMTP id v1mr38454055pbq.102.1321944578332; Mon, 21 Nov 2011 22:49:38 -0800 (PST)
Received: by 10.68.48.132 with HTTP; Mon, 21 Nov 2011 22:49:38 -0800 (PST)
In-Reply-To: 
References:   <68DAB112-6E32-45FE-9AB7-A34E64898F60@cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30354436E@XMB-RCD-109.cisco.com> <750BF7861EBBE048B3E648B4BB6E8F4F20DC41F6@crexc50p> 
Date: Tue, 22 Nov 2011 01:49:38 -0500
Message-ID: 
From: Victor Kuarsingh 
To: Lorenzo Colitti 
Content-Type: multipart/alternative; boundary=bcaec52e621d01184804b24d3505
Cc: Claire Cheng , v6ops@ietf.org, Alexandre Cassen 
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Nov 2011 06:49:40 -0000

--bcaec52e621d01184804b24d3505
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Tue, Nov 22, 2011 at 12:50 AM, Lorenzo Colitti wrote=
:

> On Thu, Nov 17, 2011 at 14:29, STARK, BARBARA H  wrote:
>
>> In reading through the 6rd sunsetting draft vs. 6204bis, I think we may
>> not have fully covered the case (in 6204bis) where the same prefix is us=
ed
>> for 6rd and native. In this case, the philosophy of =93route based on so=
urce
>> address=94 won=92t work, and we should probably use the =93metric=94 app=
roach
>> proposed by the 6rd sunsetting draft. We also can=92t unprefer and inval=
idate
>> the prefix to the LAN.
>>
>
> Why do you need to route based on source address? If it's the same ISP
> moving its users from 6rd to native, I would assume that it doesn't matte=
r
> whether the CPE sends packets out the native interface or the 6rd
> interface, since they'll both be accepted by the ISP.
>

Depending if RPF is running on the network, the operator may need/want to
have the outgoing traffic leave a given interface (i.e. if strict mode RFP
running on either the upstream router at the BR or the gateway north of the
native CE path).

Although even in this case, not sure way SBR is needed - metric should be
ok there.

Now my 2 cents....

All that said, I not sure why I would leave both on in the first place.
The complexity of having two paths for the same prefix seems a bit much.
Once I have a native path, I would break the 6RD path (in my operational
environment). Sure the transitioned customer may need to go via a BR to
talk to other 6RD endpoints, but not sure if this traffic volume is that
big of a deal.

Most traffic is to/from the Internet, Caches, CDNs.

regards,

Victor



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

--bcaec52e621d01184804b24d3505
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable



On Tue, Nov 22, 2011 at 12:50 AM, Lorenz=
o Colitti <loren=
zo@google.com> wrote:


On Thu, Nov 17, 2011 at 14:29,=
 STARK, BARBARA H <bs7652@att.com> wrote:




In reading through the 6rd sunsetting draft =
vs. 6204bis, I think we may not have fully covered the case (in 6204bis) wh=
ere the same prefix is used for 6rd and native. In this case, the philosoph=
y of =93route based on source address=94 won=92t work, and we should probab=
ly use the =93metric=94 approach proposed by the 6rd sunsetting draft. We a=
lso can=92t unprefer and invalidate the prefix to the LAN.





Why do you need to route=
 based on source address? If it's the same ISP moving its users from 6r=
d to native, I would assume that it doesn't matter whether the CPE send=
s packets out the native interface or the 6rd interface, since they'll =
both be accepted by the ISP.



Depending if RPF is running on the network, the=
 operator may need/want to have the outgoing traffic leave a given interfac=
e (i.e. if strict mode RFP running on either the upstream router at the BR =
or the gateway north of the native CE path).


Although even in this case, not sure way SBR is needed - metric should =
be ok there.

Now my 2 cents....

All that said, I not sure why=
 I would leave both on in the first place.=A0 The complexity of having two =
paths for the same prefix seems a bit much.=A0 Once I have a native path, I=
 would break the 6RD path (in my operational environment). Sure the transit=
ioned customer may need to go via a BR to talk to other 6RD endpoints, but =
not sure if this traffic volume is that big of a deal.


Most traffic is to/from the Internet, Caches, CDNs.

regards,
=

Victor

=A0







_______________________________________________

v6ops mailing list

v6ops@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/v6ops





--bcaec52e621d01184804b24d3505--

From jouni.nospam@gmail.com  Tue Nov 22 00:33:46 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62A1721F8C94 for ; Tue, 22 Nov 2011 00:33:46 -0800 (PST)
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.980, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 0Pn-f-wRE8yU for ; Tue, 22 Nov 2011 00:33:46 -0800 (PST)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id ADFCC21F8C93 for ; Tue, 22 Nov 2011 00:33:45 -0800 (PST)
Received: by fabs1 with SMTP id s1so147214fab.31 for ; Tue, 22 Nov 2011 00:33:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=FkIsvOUhMDxqVF8fGJ6BIoBSjeemaMMIFd5sQUFWzvE=; b=O1o9IjqWnvs6LABVZdQW1qhbE18sGLKuDHD3VflQszT7ggYrOQvZa9G3eGMIHdLLIE HXs/9U5laURRn4Vlv/i8ZV9HfOAr4tCFmZjytjqVZ41/5ogszd2rvxPudu39G9SRFsDm M3UQITIOJvaKuMJLzVaNyA0OG5VyV0SEXymE0=
Received: by 10.205.122.139 with SMTP id gg11mr17644266bkc.67.1321950823322; Tue, 22 Nov 2011 00:33:43 -0800 (PST)
Received: from [10.255.130.2] ([192.100.123.77]) by mx.google.com with ESMTPS id fa8sm1180407bkc.14.2011.11.22.00.33.39 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 22 Nov 2011 00:33:40 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: jouni korhonen 
In-Reply-To: <867F4B6A1672E541A94676D556793ACD0C27516664@MOPESMBX01.eu.thmulti.com>
Date: Tue, 22 Nov 2011 10:33:37 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <867F4B6A1672E541A94676D556793ACD0C263BCDD7@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303494A91@XMB-RCD-109.cisco.com> <20111113070005.583DD17137B8@drugs.dv.isc.org> <867F4B6A1672E541A94676D556793ACD0C27516333@MOPESMBX01.eu.thmulti.com> <20111114210738.64529171A31E@drugs.dv.isc.org>, <867F4B6A1672E541A94676D556793ACD0C27516652@MOPESMBX01.eu.thmulti.com> <80D702DA-F460-4017-939F-C387AFC2A060@nominum.com>, <867F4B6A1672E541A94676D556793ACD0C2751665C@MOPESMBX01.eu.thmulti.com> <2815D4D2-F0CC-4921-84C9-249EC65F42D0@nominum.com> <867F4B6A1672E541A94676D556793ACD0C27516664@MOPESMBX01.eu.thmulti.com>
To: Wuyts Carl 
X-Mailer: Apple Mail (2.1084)
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] RFC6204bis-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, 22 Nov 2011 08:33:46 -0000

On Nov 15, 2011, at 9:33 AM, Wuyts Carl wrote:

> I agree, however, it's not me who has to agree.
> Anyway, if you want to go more the up-to-date way: what about dhcpv6 =
client availability on mobile devices (smartphones etc)?

On cellular access side rather poor i.e. I know no phone/smartphone that =
is in production or are going to be in production soonish. Few reasons =
for that: if the cellular side is according to 3GPP specs then SLAAC is =
the only way to configure the address. Later on prefix delegation will =
be added but still SLAAC for the "WAN" address. Also the deployed =
gateway side has currently very little support for DHCPv6 and if any =
then it is for RFC3736.

- Jouni

>=20
> Carl Wuyts
> GCD System Architect Networking
> CONNECT DIVISION
> carl.wuyts@technicolor.com
> tel.: +32 3 443 65 90


From ichiroumakino@gmail.com  Tue Nov 22 01:00:38 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EAEF21F8B25 for ; Tue, 22 Nov 2011 01:00:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.555
X-Spam-Level: 
X-Spam-Status: No, score=-3.555 tagged_above=-999 required=5 tests=[AWL=0.044,  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 vmltQErFvHb3 for ; Tue, 22 Nov 2011 01:00:37 -0800 (PST)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id C3CE521F8B1D for ; Tue, 22 Nov 2011 01:00:36 -0800 (PST)
Received: by wwe5 with SMTP id 5so9268417wwe.13 for ; Tue, 22 Nov 2011 01:00:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=uqBp3Z5ijYPNrWQW4Sm/A9zr00oTLWIWA0Zuwoedm7k=; b=IYQ3kHGa+b3IheC1sUBX+XhGfVaxtjpF3We1t+KxRlsez3kjKiEZJS8YRZ51aLlJF1 RKbhgxiq+gVNd4/A/QawGhnhQbRCZZrzwPR/sYzelAcmE2i1jLN6k+D65/JKo6FGyZ5A 2GnEJ1yS0Zs+QvmAY9jkOFVNXI97D+nck/BPQ=
Received: by 10.216.136.168 with SMTP id w40mr2683705wei.27.1321952435995; Tue, 22 Nov 2011 01:00:35 -0800 (PST)
Received: from ams3-vpn-dhcp5208.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id ep13sm15895754wbb.8.2011.11.22.01.00.32 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 22 Nov 2011 01:00:33 -0800 (PST)
Sender: Ole Troan 
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Ole Troan 
In-Reply-To: <007801cca8c8$5610aa00$0231fe00$@iname.com>
Date: Tue, 22 Nov 2011 10:00:31 +0100
Content-Transfer-Encoding: 7bit
Message-Id: 
References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com><5B6B2B64C9FE2A489045EEEADDAFF2C30354473D@XMB-RCD-109.cisco.com><4EC455D6.8030601@bogus.com><7EB596BF-B175-40BF-ABC8-326599670B04@apple.com><5B6B2B64C9FE2A489045EEEADDAFF2C303544B88@XMB-RCD-109.cisco.com>	<8D342733-88E6-45D3-B388-E001AE32CD77@employees.org>	<750BF7861EBBE048B3E648B4BB6E8F4F20DC4FEA@crexc50p>  <007801cca8c8$5610aa00$0231fe00$@iname.com>
To: "Frank Bulk" 
X-Mailer: Apple Mail (2.1084)
Cc: IPv6 Operations 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Nov 2011 09:00:38 -0000

Frank,

> What's fuzzy?

from Barbara:

>  WPD-4:  The IPv6 CE router MUST always initiate DHCPv6 prefix
>          delegation, regardless of the M and O flags in a received
>          Router Advertisement message.
> 
> I still think this is a reasonable change.
> It doesn't preclude the previous behavior of doing DHCPv6 IA_PD,
> regardless of M/O. It just doesn't mandate it. Now it only mandates it
> if M or O=1. The current language leaves it up to the vendor (or other
> specs) as to what to do when M=O=0, or no received RA. Devices compliant
> under the old requirement are still compliant under the new requirement.

CPE receives and RA with M=O=0, what is it supposed to do with regards to PD?
left up to the vendor to decide?

cheers,
Ole

From Carl.Wuyts@technicolor.com  Tue Nov 22 01:14:27 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26F8521F8CEA for ; Tue, 22 Nov 2011 01:14:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.507
X-Spam-Level: 
X-Spam-Status: No, score=-4.507 tagged_above=-999 required=5 tests=[AWL=-0.329, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eWsiwWLeULqM for ; Tue, 22 Nov 2011 01:14:25 -0800 (PST)
Received: from na3sys009aog105.obsmtp.com (na3sys009aog105.obsmtp.com [74.125.149.75]) by ietfa.amsl.com (Postfix) with ESMTP id 8A4BC21F8B57 for ; Tue, 22 Nov 2011 01:14:22 -0800 (PST)
Received: from mopesedge02.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob105.postini.com ([74.125.148.12]) with SMTP ID DSNKTstn7YSCMU+5oJsEDUycX/bnYcTl2l11@postini.com; Tue, 22 Nov 2011 01:14:24 PST
Received: from MOPESMAILHC02.eu.thmulti.com (141.11.100.29) by mopesedge02.eu.thmulti.com (141.11.253.23) with Microsoft SMTP Server (TLS) id 8.3.192.1; Tue, 22 Nov 2011 10:11:40 +0100
Received: from MOPESMBX01.eu.thmulti.com ([169.254.155.121]) by MOPESMAILHC02.eu.thmulti.com ([141.11.100.29]) with mapi; Tue, 22 Nov 2011 10:11:44 +0100
From: Wuyts Carl 
To: Lorenzo Colitti 
Date: Tue, 22 Nov 2011 10:11:42 +0100
Thread-Topic: [v6ops] RFC6204bis-02
Thread-Index: AcyoS9De6Wm9fYqoRNKApnjyylUUkAAqj7QA
Message-ID: <867F4B6A1672E541A94676D556793ACD0C2766DA5A@MOPESMBX01.eu.thmulti.com>
References: <867F4B6A1672E541A94676D556793ACD0C263BCDD7@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303494A91@XMB-RCD-109.cisco.com> <20111113070005.583DD17137B8@drugs.dv.isc.org> <867F4B6A1672E541A94676D556793ACD0C27516333@MOPESMBX01.eu.thmulti.com> <20111114210738.64529171A31E@drugs.dv.isc.org> <867F4B6A1672E541A94676D556793ACD0C27516652@MOPESMBX01.eu.thmulti.com> <80D702DA-F460-4017-939F-C387AFC2A060@nominum.com> <867F4B6A1672E541A94676D556793ACD0C2751665C@MOPESMBX01.eu.thmulti.com> <2815D4D2-F0CC-4921-84C9-249EC65F42D0@nominum.com> <867F4B6A1672E541A94676D556793ACD0C27516664@MOPESMBX01.eu.thmulti.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/related; boundary="_006_867F4B6A1672E541A94676D556793ACD0C2766DA5AMOPESMBX01eut_"; type="multipart/alternative"
MIME-Version: 1.0
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] RFC6204bis-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, 22 Nov 2011 09:14:27 -0000

--_006_867F4B6A1672E541A94676D556793ACD0C2766DA5AMOPESMBX01eut_
Content-Type: multipart/alternative;
	boundary="_000_867F4B6A1672E541A94676D556793ACD0C2766DA5AMOPESMBX01eut_"

--_000_867F4B6A1672E541A94676D556793ACD0C2766DA5AMOPESMBX01eut_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Ted was referring to some scenario to bridge in the LAN hosts, and let them=
 execute the DHCPv6 client.
So I was pointing to Windows XP, not having DHCPv6 client functionality onb=
oard.  Ted answered on this "so what about win95", meaning that I should lo=
ok forward, not backward.  Although I think my statement , "still" looking =
to XP, is really a good one, as it still is massively around, I just gave h=
im another set of devices, smartphones, typically not having dhcpv6 client =
functionality.
And as you confirm, indeed, Android doesn't support it.  Tx for confirmatio=
n :-)

Carl Wuyts
GCD System Architect Networking
Connect Division

carl.wuyts@technicolor.com
tel.: +32 3 443 65 90
[cid:image001.gif@01CCA8FF.22174920]
[cid:image002.gif@01CCA8FF.22174920]
Prins Boudewijnlaan 47  -  2650 Edegem  -  Belgium

Technicolor Delivery Technologies Belgium NV
Registered office (maatschappelijke zetel): Prins Boudewijnlaan 47, 2650 Ed=
egem, Belgium
Company registration number (ondernemingsnummer): 0428837295 - RPR Antwerpe=
n
[cid:image003.gif@01CCA8FF.22174920]

Help preserve the color of our world - Think before you print.





From: Lorenzo Colitti [mailto:lorenzo@google.com]
Sent: maandag 21 november 2011 13:48
To: Wuyts Carl
Cc: Ted Lemon; v6ops@ietf.org
Subject: Re: [v6ops] RFC6204bis-02

On Tue, Nov 15, 2011 at 16:33, Wuyts Carl > wrote:
I agree, however, it's not me who has to agree.
Anyway, if you want to go more the up-to-date way: what about dhcpv6 client=
 availability on mobile devices (smartphones etc)?

Android doesn't support DHCPv6. What were you suggesting to use it for? I t=
ried to look back in the thread but I wasn't able to interpret the quoted t=
ext.

--_000_867F4B6A1672E541A94676D556793ACD0C2766DA5AMOPESMBX01eut_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Ted was r=
eferring to some scenario to bridge in the LAN hosts, and let them execute =
the DHCPv6 client.
So I wa=
s pointing to Windows XP, not having DHCPv6 client functionality onboard.&n=
bsp; Ted answered on this “so what about win95”, meaning that I=
 should look forward, not backward.  Although I think my statement , &=
#8220;still” looking to XP, is really a good one, as it still is mass=
ively around, I just gave him another set of devices, smartphones, typicall=
y not having dhcpv6 client functionality.
And as you confirm, indeed, Android doesn’t support i=
t.  Tx for confirmation :-)
=
 
Carl Wuyts
GCD =
System Architect Networking
Connect Division
carl.wuyts@technicolor.com<=
/a>
tel.=
: +32 3 443 65 90
3Dtwitter
3D"Visit
Technicolor Delive=
ry Technologies Belgium NV=

Registered office (maatsch=
appelijke zetel): Prins Boudewijnlaan 47, 2650 Edegem, Belgium
Company registration number (onder=
nemingsnummer): 0428837295 - RPR Antwerpen
3DEco
Help preserve the color of our world - Think before you print.<=
/o:p>
<=
p class=3DMsoNormal> 
 
From: Loren=
zo Colitti [mailto:lorenzo@google.com] 
Sent: maandag 21 november=
 2011 13:48
To: Wuyts Carl
Cc: Ted Lemon; v6ops@ietf.or=
g
Subject: Re: [v6ops] RFC6204bis-02
<=
p class=3DMsoNormal> 
On Tue, =
Nov 15, 2011 at 16:33, Wuyts Carl <Carl.Wuyts@technicolor.com> wrote:
I agree, however, it's not me who has to agree=
.
Anyway, if you want to go more the up-to-date way: what about dhcpv6 c=
lient availability on mobile devices (smartphones etc)?
=

 
A=
ndroid doesn't support DHCPv6. What were you suggesting to use it for? I tr=
ied to look back in the thread but I wasn't able to interpret the quoted te=
xt.
=

--_000_867F4B6A1672E541A94676D556793ACD0C2766DA5AMOPESMBX01eut_--

--_006_867F4B6A1672E541A94676D556793ACD0C2766DA5AMOPESMBX01eut_
Content-Type: image/gif; name="image001.gif"
Content-Description: image001.gif
Content-Disposition: inline; filename="image001.gif"; size=1351;
	creation-date="Tue, 22 Nov 2011 09:11:42 GMT";
	modification-date="Tue, 22 Nov 2011 09:11:42 GMT"
Content-ID: 
Content-Transfer-Encoding: base64

R0lGODlhGAAYAPcAAAAAAP///1Sfum/L64bW8o7h/ofU74fT7pHb9pfa8u75/VbD5VzG6FvF5l3G
513F5l/G51/F5mHH52PH6GPI6GPI52TH6GXJ6GbI6GnK6mjJ6WjK6WzL6m/M63HN6nPN6nTN63fR
7XnR7XTI5FeVqnnN537T7n7R7H/T7X3O6Y3f+4jV73m903/E2oDE2pTf+ZPc9JTa8Zfa8aDd8LDj
9MXr9+z5/er3+/r9/imy1yyx1S202S2z1zK43TW63jW32zS22Ta53Te73za32zq84Dm53Du73j2/
4j2+4T283z273kHB5D++4EHA4kG/4UPA40K/4UTB5EbD5UbB40rJ7EjD5ErG6EnE5knE5Ua720rE
5kvG507J607I6U3G50/K60u+3U2/4U7A4k2/3lLI6E/A31XN7lHC4VnP8FfL61PD4lXD5FXF41vR
8VfG5VO92lrJ51a+21i/21/O7F7L6VnB3VzE4mHN6l/H5V3D30+lvWDH41/E4GDF4WLH42rL6GvP
6l+2znLZ9W7Q62C1zGO50HXZ9HTY83ba9XXX8mW70nLO6nHN6We803rd+HXV73zf+mm91HXS62vA
12GpvWavw2ixxVmWp2qxxYDW7X3Q52yzxm+2yW60x4HS6HC2yXG3ynzD2I7a75Xb7pvh9F+HkqTg
8ajg76ff7qri8bPo97fm9Ljm9MXw/Mfw/NDz/dDx+tbx+dz0++H1++f5/uv5/Six1S+22jG01zK1
2EXD5E/M7U7H50yvyWPY91zJ5WjZ92za927b+HHY82G4z3Xd+FurwHXa9Xfc93ne+F+rv37h+2u/
1YDi/H7c9YHh+YLh+YXi+mqyxWuzxork+ovj+o3l+3K4ypXn+12PnJrm+qXp+63j8cLx/M/0/ef4
/Jfp+57q+6Xt/Kjv/avv/a3v/a7w/bPw/bzz/uP6/+z7/vP9/7fz/r30/sD0/sX1/sn2/tT4/9L2
/d/6/+X7/+b7/+r8/+v7/sz3/tr5/ub8/+39//v///3///7//////yH5BAEAAP8ALAAAAAAYABgA
AAj/AP8JHEiwoMGCAgggOGCg4YqHEB8aOPCCAEESKmR84MABg0cOHUKGHDCAA4gEBQaOiIHBwgQO
pmrQEEEhg80NGnJewACDhcAUJyBMwBArgL8ACkxc2MBUg8cLEEy0+PkhQoMZAerNmxegBoMLFChc
AFsBQggXAkswerBgVYB8+eLtu7GorgcKDipIcBBi6r8SHtiyCoAPH7x6AXAoxjELRYO9IUIJlGMn
jBi37zLHo2fPXj19/hT8WRMGDzGBb7LosIUqADp07WC7c9eOHbwAmnjwGBNIYBwwuHK0NleOOLnj
5MaxC+BpR64zp//JGQNkx6kA4rKXO8ede7oAe378/1BTSGCdMkNunfIXLhw4eQH6yU88KoiSImzK
/8tzpkiPVP1gg4013gRgYGKmEMEEE0a4oYhAeahhhA/c8FMNNdF0s4466tyzTgCrOAFFEnA0IhAf
bCQhhCkBVPMMNDDC+GI3AUiCBBNwRCJQH24wgUQmAWwjTDJEFllMNAGIcoQTdDAjkB9uODGFFLHw
o00wwGSZpS/bBJDJEk80+eQvTVQhxR2zBECLK6202c0rAchCxhVR3DGJb5I0gYUXVqRBCiy1BFqL
Dd+oMocVW+jyCCEC6ZEIIFps0cUXVOyCRhuYomEGFVx0wcsghlwyUC/DOHPIMcg4AskyzbS6DCSO
ICSDiDOCGFNQNspUYgkmm3TCCSjXgPJJJ9NIYwklpRyk7LIDBQQAOw==

--_006_867F4B6A1672E541A94676D556793ACD0C2766DA5AMOPESMBX01eut_
Content-Type: image/gif; name="image002.gif"
Content-Description: image002.gif
Content-Disposition: inline; filename="image002.gif"; size=1834;
	creation-date="Tue, 22 Nov 2011 09:11:43 GMT";
	modification-date="Tue, 22 Nov 2011 09:11:43 GMT"
Content-ID: 
Content-Transfer-Encoding: base64

R0lGODlhcgBFAOZ/AEGueqipqmgxkACLS4ORyPb294DFpZrMVqvi+sXr2Ie3laLXtnRHnLQlZO3J
2M+pxP7pJvqtgePqmqOIvYLKnACP1fewoXa65/vCov71sdqRnc6OpPvrlcU/benvs7qmzpzR8P/n
rc7imtLntMkhU/V7Hf/yl+fZ6f3HipjL7b+MraKs1h+WXIrU9fNrPv/dkaTIrpQpd/JlIr8kXv/o
ALa3uO0bLwCmUQC68pKSlf/CDgxNosvbKtvb3IzGP8nJyoiJjPaWgH+Ag3Z3euTk5Y3Y+MTfm+3t
7r/AwZubnvBSJQCZ3NLS0//eAwN+yE84la9fmdjkX//RSiPB855BhP/ILiCvY9HeRvLkCvmykSld
q/aNl4Dd+cPT6O85Q2m+Q6zRONnM5OPx0PR3OR2Z2eOttkCr4Lfbm//uQPWMWbeLscPbysbs/OP1
/ZeLwPaLN9blff/iEvXlByCi3nzB69eqvN7r4uzysHfDWSCKzu+Uh8R4pR6j4IVfqm1ucf///yH5
BAEAAH8ALAAAAAByAEUAAAf/gH+Cg4SFhoeIiYqLjI2Oj5CRkpOUlZaXmJmam5ydnp+goaKjpKWm
p6ipqqusra6vsLGys7S1tqF+Oat+freMubu9vorAkkhIlryqBQWXxZBEvD2VyqhEQtPJupJJScnC
pzV+2dTbqdWnSX4BNTWDR+01RIUFSO0/zX/AP+1Mg/x/iLRDku9PO0JH7NXA906hv0Ho/vSId2TQ
xB4Jf1gKwKujoB8deWn8OCTkkIp+gAAJGUBQjnUhgUAEB9Lkx5C58lUr8DLkSHE5Spqb1IMjkh7T
evgZ4o9JyYrR/Mib2FKfHyH4kPBq1rPGkR4lH1ZjsvQH0gDIlA7RSGSlN6uC/zgCmfcjrEFeQuRd
EkeO48g/IN2pQ2boasGV014+/MPRHdw/QsYZUve3wFO4R5YWBOlN3FtMfAetBJKj9EpdEQk9+/My
sWRB4hxXS3koNcdpypRWnXnXMejXf4SWHt4yNcShrVkDjy1o9lDehELnXldIGfNMoV0CJxSZnGrk
kpPDltpc2FZDK+eJlqwsmsx3V3trEvdXK5CKgvKJu59fLHjX5FxXjVz5fHUXEPmAJER5gkQ2UgHq
uHMdJiANkcNIK+WSQ2TraaiZPv8pFyB5jxWwkoUvLWjiVUlkmE01RJQERACRISifJhxR90cBNUTG
YkE1ZAgEYTnsxlgO8wSA5P8/F7pkDo8+AvFgj7wkoR5r5hChzlU1JNjkMGCGKeaYZJZp5pmqsIHA
mmyCkMKbcK4g55wrfGDnnR88oOeedZTh558WBCqoBRgUaigGISSqaAgZNOroHR5EKqkHI1Rq6QKY
ZroADJx2CoMdjxSAQBGkktoCHRekqioBrLZKgBsTxCqrGirUaqsGuOaqgR5B9OprBMAGG8ELxBb7
ggnIJmuCBMw2K4EIRkQb7RkUVGstBQpkq60CazTSRqmlnqrqqq6yCqusstqqrq65+uqusMGiYCyx
HCiLLAfONguttEZQe22122oLQ0GHsAGuqeOSW+656E6grq0bsIuru7/CG4H/vPMea++y+TK7r7T+
/huwtqAiMsXJKE/BBxkst5yHFjDHrAUDNNdMMxU450xFBzz3zLMXQAfthQtjFG30G1UkrXQVEDTt
dNNXRC31FWAcYPXVeFih9dZWsOD11ywAkAgOZJeNwxIVpK22Ezu07fYOTwgg99wCxGD33TE0MMPe
fJNgw9+A26CEDIQXXoIOiCeuQxM0NO44FjxELjkPYPhg+eVf3KD55jcM4PnnA4iNiNllo6122my/
3XbcdMuN9916872334H/PXjhhB+uOOKMO9445JNHXvnllmfOueagfy76IaSTbfrpqavOeuuv2x27
7LTXfjvuuu/eu+/ABz88//HGH5+858sb0vzZp6Ou+uqtu1799X3Xbjvuue/Ou++/By888cU7HvLO
l75CrO95a3sf3OJXt/nJbnb2Exz+ZNA9xX3vcf6jHAB9UD7OnS90Y2seAt33vunRrXp5e+AMshe4
7RlOf4vjHw3CN7nxYU6AnSNgCEk3wgpE720mnBsK6QdB+7kwf/q7YP/8BwcxOPGJC8DhBwtIiAO2
z4cKDKL8XkfEFUbwiBSEoRJpIIcomPGMUbiDIRIgRR2OToRXrEAX5kjHLvSBgUNUIQsBB8YSSOGP
gJRCHGRIA0ewUYBTTAQXFslILswhjoe4Y/zy+EASbOGSmNyCCyYog0OggYeQhgSAKEcJABa40RFm
gKQhThCGVrryAZR84CHSwElPgrISADhlI1J5RUc4IJaym2UtSZHL5FFREbxsny9RuAcHOPOZDjgE
BrJAzWpmoRQLMIA2t7kASCTzdI44ARTGSU4oPABN6EynOtfJzna6853wjKc850nPetrznvjMpz73
yc9++tMUgQAAOw==

--_006_867F4B6A1672E541A94676D556793ACD0C2766DA5AMOPESMBX01eut_
Content-Type: image/gif; name="image003.gif"
Content-Description: image003.gif
Content-Disposition: inline; filename="image003.gif"; size=493;
	creation-date="Tue, 22 Nov 2011 09:11:43 GMT";
	modification-date="Tue, 22 Nov 2011 09:11:43 GMT"
Content-ID: 
Content-Transfer-Encoding: base64

R0lGODlhHAAhAMQAALHNVVqXGZu+IqbFNv79/ury0pK4H2SdaJzAJNjlq/3++vL34srdiSl5Mfj7
8OHrvDmDE5u+Kb3VbtDgm5jCnJC2IqDBJHqqHoazHsfYxcfco+/58f7///7+/v///f///yH5BAAA
AAAALAAAAAAcACEAAAX/4CeOZGmeaKqubOumXSfKL0rT9RiTe65/nl0vxxE1KB3Ph6b8KGYjT/Pn
ORwIHmy0FEQFCZRG5yldJnEqD6ezaWQIHMJDApAwCthgF8hbEqwEBQARAoWFEgskQWgiChwFDRoD
hpQCA3hLQGhxSWABFpQIlAMPT2NoeTIJEBigooavlzJDS0UdHAkBEAivAoSjDklTQAROuBYQn7+/
lBJJS01SUgoJoskWvaECCWUiHEEKtw+8BtegvoWxiYtqSmsLhBblEALn2hLDH3HTAIXYuhfqVeLF
TZ8SR3oSULKAQVeAChYi8kJwCUg4BcVkOOiXDgHDACAvXMBQoWQEOw6iahwsMCmdAI8CKoiciUEA
gAJ8aBC4xfKlz3QRsVGcoICMJidKOjhgMKCXqKcAJqSMIkwEuw8OHjCQwNVOggJPvqm4ZUJGuw47
lajlA0Sat28xyJZV9APasGEcvknBkU9TjJ1WrTZZE9hHihAAOw==

--_006_867F4B6A1672E541A94676D556793ACD0C2766DA5AMOPESMBX01eut_--

From lorenzo@google.com  Tue Nov 22 01:20:32 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5BCE21F8D32 for ; Tue, 22 Nov 2011 01:20:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.889
X-Spam-Level: 
X-Spam-Status: No, score=-102.889 tagged_above=-999 required=5 tests=[AWL=0.087, 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 tusQh0z044Im for ; Tue, 22 Nov 2011 01:20:32 -0800 (PST)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0D09F21F8D31 for ; Tue, 22 Nov 2011 01:20:31 -0800 (PST)
Received: by ggnp4 with SMTP id p4so1091651ggn.31 for ; Tue, 22 Nov 2011 01:20:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=tMKzu2hAlOp+dynzqO95Of66AX1oX0eLnw2d9XVEIdM=; b=cqDmQ6EUPFy2xgH1TVneXSGTJG984fQ3e9o1ERtAEb7TBryjFr2f7i84R8QZmfe9Lj tf3rwSZvV8RQ2Fhs0bcA==
Received: by 10.236.183.52 with SMTP id p40mr25115856yhm.19.1321953631366; Tue, 22 Nov 2011 01:20:31 -0800 (PST)
Received: by 10.236.183.52 with SMTP id p40mr25115841yhm.19.1321953631265; Tue, 22 Nov 2011 01:20:31 -0800 (PST)
MIME-Version: 1.0
Received: by 10.150.202.14 with HTTP; Tue, 22 Nov 2011 01:20:10 -0800 (PST)
In-Reply-To: 
References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com>  <5B6B2B64C9FE2A489045EEEADDAFF2C30354473D@XMB-RCD-109.cisco.com> <4EC455D6.8030601@bogus.com>   <7EB596BF-B175-40BF-ABC8-326599670B04@apple.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303544B88@XMB-RCD-109.cisco.com>    <8D342733-88E6-45D3-B388-E001AE32CD77@employees.org> <750BF7861EBBE048B3E648B4BB6E8F4F20DC4FEA@crexc50p>  <007801cca8c8$5610aa00$0231fe00$@iname.com> 
From: Lorenzo Colitti 
Date: Tue, 22 Nov 2011 18:20:10 +0900
Message-ID: 
To: Ole Troan 
Content-Type: multipart/alternative; boundary=bcaec52c5ea999e56f04b24f5038
X-System-Of-Record: true
Cc: IPv6 Operations 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Nov 2011 09:20:32 -0000

--bcaec52c5ea999e56f04b24f5038
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Nov 22, 2011 at 18:00, Ole Troan  wrote:

> >  WPD-4:  The IPv6 CE router MUST always initiate DHCPv6 prefix
> >          delegation, regardless of the M and O flags in a received
> >          Router Advertisement message.
> >
> > I still think this is a reasonable change.
> > It doesn't preclude the previous behavior of doing DHCPv6 IA_PD,
> > regardless of M/O. It just doesn't mandate it. Now it only mandates it
> > if M or O=1. The current language leaves it up to the vendor (or other
> > specs) as to what to do when M=O=0, or no received RA. Devices compliant
> > under the old requirement are still compliant under the new requirement.
>
> CPE receives and RA with M=O=0, what is it supposed to do with regards to
> PD?
> left up to the vendor to decide?


Not do PD. Also not do PD if it doesn't have an RA at all, since a prefix
without a route is useless.

Hmm, I think I can hear the cries already... "DHCPv6 PD is just a fax
replacement! Routing has nothing to do with addressing! Routers don't
listen to RAs!". IMO none of those are true. :-)

--bcaec52c5ea999e56f04b24f5038
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Tue, Nov 22, 2011 at 18:00, Ole Troan <ot=
roan@employees.org> wrote:




> =A0WPD-4: =A0The IPv6 CE router MUST always initiate DHCPv6 prefi=
x

> =A0 =A0 =A0 =A0 =A0delegation, regardless of the M and O flags in a re=
ceived

> =A0 =A0 =A0 =A0 =A0Router Advertisement message.

>

> I still think this is a reasonable change.

> It doesn't preclude the previous behavior of doing DHCPv6 IA_PD,
> regardless of M/O. It just doesn't mandate it. Now it only mandate=
s it

> if M or O=3D1. The current language leaves it up to the vendor (or oth=
er

> specs) as to what to do when M=3DO=3D0, or no received RA. Devices com=
pliant

> under the old requirement are still compliant under the new requiremen=
t.




CPE receives and RA with M=3DO=3D0, what is it supposed to do with re=
gards to PD?

left up to the vendor to decide?

Not do PD.=
 Also not do PD if it doesn't have an RA at all, since a prefix without=
 a route is useless.

Hmm, I think I can hear the c=
ries already... "DHCPv6 PD is just a fax replacement! Routing has noth=
ing to do with addressing! Routers don't listen to RAs!".=A0IMO no=
ne of those are true.=A0:-)





--bcaec52c5ea999e56f04b24f5038--

From lorenzo@google.com  Tue Nov 22 01:21:15 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1210921F8D3C for ; Tue, 22 Nov 2011 01:21:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.893
X-Spam-Level: 
X-Spam-Status: No, score=-102.893 tagged_above=-999 required=5 tests=[AWL=0.083, 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 UC8hkAuD7G7g for ; Tue, 22 Nov 2011 01:21:14 -0800 (PST)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9541121F8D3B for ; Tue, 22 Nov 2011 01:21:14 -0800 (PST)
Received: by ggnp4 with SMTP id p4so1092345ggn.31 for ; Tue, 22 Nov 2011 01:21:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=wLeaJ9bTuWha8U1+5gR5IMJqvTe7rxdHmlY6Nc5jTb8=; b=Jl1nyKn8DYjWoGvt3pXIBKj083Gz5Ycth1OunlgGLIWkq9dU5f/QPAUp0tfQSsNZdI hNV+fBzXx4m2vM0c7EBQ==
Received: by 10.236.75.167 with SMTP id z27mr25421408yhd.53.1321953674250; Tue, 22 Nov 2011 01:21:14 -0800 (PST)
Received: by 10.236.75.167 with SMTP id z27mr25421385yhd.53.1321953674126; Tue, 22 Nov 2011 01:21:14 -0800 (PST)
MIME-Version: 1.0
Received: by 10.150.202.14 with HTTP; Tue, 22 Nov 2011 01:20:52 -0800 (PST)
In-Reply-To: <867F4B6A1672E541A94676D556793ACD0C2766DA5A@MOPESMBX01.eu.thmulti.com>
References: <867F4B6A1672E541A94676D556793ACD0C263BCDD7@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303494A91@XMB-RCD-109.cisco.com> <20111113070005.583DD17137B8@drugs.dv.isc.org> <867F4B6A1672E541A94676D556793ACD0C27516333@MOPESMBX01.eu.thmulti.com> <20111114210738.64529171A31E@drugs.dv.isc.org> <867F4B6A1672E541A94676D556793ACD0C27516652@MOPESMBX01.eu.thmulti.com> <80D702DA-F460-4017-939F-C387AFC2A060@nominum.com> <867F4B6A1672E541A94676D556793ACD0C2751665C@MOPESMBX01.eu.thmulti.com> <2815D4D2-F0CC-4921-84C9-249EC65F42D0@nominum.com> <867F4B6A1672E541A94676D556793ACD0C27516664@MOPESMBX01.eu.thmulti.com>  <867F4B6A1672E541A94676D556793ACD0C2766DA5A@MOPESMBX01.eu.thmulti.com>
From: Lorenzo Colitti 
Date: Tue, 22 Nov 2011 18:20:52 +0900
Message-ID: 
To: Wuyts Carl 
Content-Type: multipart/alternative; boundary=20cf3005dde627e69304b24f5325
X-System-Of-Record: true
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] RFC6204bis-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, 22 Nov 2011 09:21:15 -0000

--20cf3005dde627e69304b24f5325
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Nov 22, 2011 at 18:11, Wuyts Carl wrote:

> So I was pointing to Windows XP, not having DHCPv6 client functionality
> onboard.
>

Windows XP doesn't have IPv6 enabled by default, so it doesn't matter.

--20cf3005dde627e69304b24f5325
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Tue, Nov 22, 2011 at 18:11, Wuyts Carl <Carl.Wuyts@te=
chnicolor.com> wrote:



So I was pointing to Windows XP, not having DHCPv6 cl=
ient functionality onboard.




Windows XP doesn't have IP=
v6 enabled by default, so it doesn't matter.


--20cf3005dde627e69304b24f5325--

From mark@townsley.net  Tue Nov 22 01:25:55 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C112021F8D62 for ; Tue, 22 Nov 2011 01:25:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.189
X-Spam-Level: 
X-Spam-Status: No, score=-3.189 tagged_above=-999 required=5 tests=[AWL=-0.191, 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 wkMCRrKqR+Gi for ; Tue, 22 Nov 2011 01:25:55 -0800 (PST)
Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id B5DEC21F8D56 for ; Tue, 22 Nov 2011 01:25:54 -0800 (PST)
Received: by eyg24 with SMTP id 24so7214330eyg.31 for ; Tue, 22 Nov 2011 01:25:54 -0800 (PST)
Received: by 10.180.94.71 with SMTP id da7mr17818805wib.29.1321953953839; Tue, 22 Nov 2011 01:25:53 -0800 (PST)
Received: from ams-townsley-8712.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id c2sm15977988wbo.3.2011.11.22.01.25.51 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 22 Nov 2011 01:25:52 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-42-49366572
From: Mark Townsley 
In-Reply-To: 
Date: Tue, 22 Nov 2011 10:25:50 +0100
Message-Id: <252D3DEA-FF09-42C8-959E-8A7205D9DE67@townsley.net>
References:   <68DAB112-6E32-45FE-9AB7-A34E64898F60@cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30354436E@XMB-RCD-109.cisco.com> <750BF7861EBBE048B3E648B4BB6E8F4F20DC41F6@crexc50p> 
To: Lorenzo Colitti 
X-Mailer: Apple Mail (2.1084)
Cc: Claire Cheng , v6ops@ietf.org, Alexandre Cassen 
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Nov 2011 09:25:55 -0000

--Apple-Mail-42-49366572
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


On Nov 22, 2011, at 6:50 AM, Lorenzo Colitti wrote:

> On Thu, Nov 17, 2011 at 14:29, STARK, BARBARA H  =
wrote:
> In reading through the 6rd sunsetting draft vs. 6204bis, I think we =
may not have fully covered the case (in 6204bis) where the same prefix =
is used for 6rd and native. In this case, the philosophy of =93route =
based on source address=94 won=92t work, and we should probably use the =
=93metric=94 approach proposed by the 6rd sunsetting draft. We also =
can=92t unprefer and invalidate the prefix to the LAN.
>=20
>=20
> Why do you need to route based on source address? If it's the same ISP =
moving its users from 6rd to native, I would assume that it doesn't =
matter whether the CPE sends packets out the native interface or the 6rd =
interface, since they'll both be accepted by the ISP.

That's certainly the idea in the "same delegated prefix" case. In the =
"separate prefix" case, they *could* be separate ISPs (particularly when =
manually configuring 6rd, but that may be out of scope here).=20

Just trying to keep things simple here. The CPE brings up 6rd, or not, =
when told and passes on its prefix, whatever it is. Native does the =
same.  Forwarding rules prefer native over virtual when the installed =
routes are identical. That's really the crux of it. With this, the ISP =
can choose to "flash-cut" or steadily move users to a separate prefix, =
or keep them on the same prefix for the time being. It's really in the =
hands of the ISP to decide as long as the CPE can remain simple and =
deterministic in its response.=20

- Mark

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


--Apple-Mail-42-49366572
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252


On Thu, Nov 17, 2011 at 14:29, =
STARK, BARBARA H <bs7652@att.com> =
wrote:



In reading through the 6rd sunsetting draft vs. =
6204bis, I think we may not have fully covered the case (in 6204bis) =
where the same prefix is used for 6rd and native. In this case, the =
philosophy of =93route based on source address=94 won=92t work, and we =
should probably use the =93metric=94 approach proposed by the 6rd =
sunsetting draft. We also can=92t unprefer and invalidate the prefix to =
the LAN.




Why do you need to route =
based on source address? If it's the same ISP moving its users from 6rd =
to native, I would assume that it doesn't matter whether the CPE sends =
packets out the native interface or the 6rd interface, since they'll =
both be accepted by the =
ISP.

That's certainly the =
idea in the "same delegated prefix" case. In the "separate prefix" case, =
they *could* be separate ISPs (particularly when manually configuring =
6rd, but that may be out of scope =
here). 

Just trying to keep things simple =
here. The CPE brings up 6rd, or not, when told and passes on its prefix, =
whatever it is. Native does the same.  Forwarding rules prefer =
native over virtual when the installed routes are identical. That's =
really the crux of it. With this, the ISP can choose to "flash-cut" or =
steadily move users to a separate prefix, or keep them on the same =
prefix for the time being. It's really in the hands of the ISP to decide =
as long as the CPE can remain simple and deterministic in its =
response. 

- Mark





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

=

--Apple-Mail-42-49366572--

From lorenzo@google.com  Tue Nov 22 01:34:40 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9769E21F8D32 for ; Tue, 22 Nov 2011 01:34:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.897
X-Spam-Level: 
X-Spam-Status: No, score=-102.897 tagged_above=-999 required=5 tests=[AWL=0.079, 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 ov8qvEMMbjIz for ; Tue, 22 Nov 2011 01:34:39 -0800 (PST)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id C912321F8D31 for ; Tue, 22 Nov 2011 01:34:37 -0800 (PST)
Received: by ywt34 with SMTP id 34so6825963ywt.31 for ; Tue, 22 Nov 2011 01:34:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=sG6uZxm/ajURLW7L2Ng9Ib32Yzc7e1/SRR4qeVxHaLk=; b=ZIhnSIxh1SzYAdigKx7/cXOwYzAz60Z6LMSycKFnNx6lKBVdEZ3Y8k1qiRywcLk2G7 Z5Z6NXNqezVSOE1v9LVw==
Received: by 10.236.181.138 with SMTP id l10mr25039747yhm.36.1321954477228; Tue, 22 Nov 2011 01:34:37 -0800 (PST)
Received: by 10.236.181.138 with SMTP id l10mr25039723yhm.36.1321954477113; Tue, 22 Nov 2011 01:34:37 -0800 (PST)
MIME-Version: 1.0
Received: by 10.150.202.14 with HTTP; Tue, 22 Nov 2011 01:34:15 -0800 (PST)
In-Reply-To: <252D3DEA-FF09-42C8-959E-8A7205D9DE67@townsley.net>
References:   <68DAB112-6E32-45FE-9AB7-A34E64898F60@cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30354436E@XMB-RCD-109.cisco.com> <750BF7861EBBE048B3E648B4BB6E8F4F20DC41F6@crexc50p>  <252D3DEA-FF09-42C8-959E-8A7205D9DE67@townsley.net>
From: Lorenzo Colitti 
Date: Tue, 22 Nov 2011 18:34:15 +0900
Message-ID: 
To: Mark Townsley 
Content-Type: multipart/alternative; boundary=20cf30434af004827304b24f8359
X-System-Of-Record: true
Cc: Claire Cheng , v6ops@ietf.org, Alexandre Cassen 
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Nov 2011 09:34:40 -0000

--20cf30434af004827304b24f8359
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Nov 22, 2011 at 18:25, Mark Townsley  wrote:

> Why do you need to route based on source address? If it's the same ISP
> moving its users from 6rd to native, I would assume that it doesn't matter
> whether the CPE sends packets out the native interface or the 6rd
> interface, since they'll both be accepted by the ISP.
>
>
> That's certainly the idea in the "same delegated prefix" case. In the
> "separate prefix" case, they *could* be separate ISPs (particularly when
> manually configuring 6rd, but that may be out of scope here).
>

If you want to support 6rd service being provided by a different ISP than
native IPv6 service you may have to deal with ingress filtering issues. If
you choose to do so on the CE router, that will complicate the
implementation because it requires the CE router to do source-based routing.

I think doing this in the CE router is a bad idea because it complicates
the implementation all the time for a scenario (different 6rd ISP vs.
native ISP) that is essentially an edge case. Since edge cases tend to be
hard to test for, the CE router implementations might not get it right all
the time, and if even if just a few of them don't get it right, you're now
dropping customer traffic so you're basically forced to relax the ingress
filtering anyway.

I think we should make the CE router assume that if it is simultaneously
provisioned with 6rd and native it should not do policy routing and place
the burden of getting ingress filtering right on ISP/ISPs that is/are
providing the connectivity. After all, if I'm an ISP and use the 6rd
connectivity from another ISP, that ISP will know I'm a customer of theirs.

--20cf30434af004827304b24f8359
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Tue, Nov 22, 2011 at 18:25, Mark Townsley <m=
ark@townsley.net> wrote:




Why do you need to route based on source =
address? If it's the same ISP moving its users from 6rd to native, I wo=
uld assume that it doesn't matter whether the CPE sends packets out the=
 native interface or the 6rd interface, since they'll both be accepted =
by the ISP.





That's certainly the=
 idea in the "same delegated prefix" case. In the "separate =
prefix" case, they *could* be separate ISPs (particularly when manuall=
y configuring 6rd, but that may be out of scope here).=A0





If you want to support 6rd ser=
vice being provided by a different ISP than native IPv6 service you may hav=
e to deal with ingress filtering issues. If you choose to do so on the CE r=
outer, that will complicate the implementation because it requires the CE r=
outer to do source-based routing.





I think doing this in the CE router is a bad idea becau=
se it complicates the implementation all the time for a scenario (different=
 6rd ISP vs. native ISP) that is essentially an edge case. Since edge cases=
 tend to be hard to test for, the CE router implementations might not get i=
t right all the time, and if even if just a few of them don't get it ri=
ght, you're now dropping customer traffic so you're basically force=
d to relax the ingress filtering anyway.





I think we should make the CE router assume that if it =
is simultaneously provisioned with 6rd and native it should not do policy r=
outing and place the burden of getting ingress filtering right on ISP/ISPs =
that is/are providing the connectivity. After all, if I'm an ISP and us=
e the 6rd connectivity from another ISP, that ISP will know I'm a custo=
mer of theirs.






--20cf30434af004827304b24f8359--

From mark@townsley.net  Tue Nov 22 01:35:09 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA8C21F8D70 for ; Tue, 22 Nov 2011 01:35:09 -0800 (PST)
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 3A6HxTQ-tTw0 for ; Tue, 22 Nov 2011 01:35:08 -0800 (PST)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 13E8821F8D0B for ; Tue, 22 Nov 2011 01:35:07 -0800 (PST)
Received: by fabs1 with SMTP id s1so213524fab.31 for ; Tue, 22 Nov 2011 01:35:06 -0800 (PST)
Received: by 10.181.11.170 with SMTP id ej10mr17901857wid.28.1321954504814; Tue, 22 Nov 2011 01:35:04 -0800 (PST)
Received: from ams-townsley-8712.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id gd6sm16011091wbb.1.2011.11.22.01.35.03 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 22 Nov 2011 01:35:04 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-43-49918423
From: Mark Townsley 
In-Reply-To: 
Date: Tue, 22 Nov 2011 10:35:01 +0100
Message-Id: <289626EA-869E-46F4-8565-1B77DFC39834@townsley.net>
References:   <68DAB112-6E32-45FE-9AB7-A34E64898F60@cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30354436E@XMB-RCD-109.cisco.com> <750BF7861EBBE048B3E648B4BB6E8F4F20DC41F6@crexc50p>  
To: Victor Kuarsingh 
X-Mailer: Apple Mail (2.1084)
Cc: Alexandre Cassen , Claire Cheng , v6ops@ietf.org
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Nov 2011 09:35:09 -0000

--Apple-Mail-43-49918423
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


On Nov 22, 2011, at 7:49 AM, Victor Kuarsingh wrote:

>=20
>=20
> On Tue, Nov 22, 2011 at 12:50 AM, Lorenzo Colitti  =
wrote:
> On Thu, Nov 17, 2011 at 14:29, STARK, BARBARA H  =
wrote:
> In reading through the 6rd sunsetting draft vs. 6204bis, I think we =
may not have fully covered the case (in 6204bis) where the same prefix =
is used for 6rd and native. In this case, the philosophy of =93route =
based on source address=94 won=92t work, and we should probably use the =
=93metric=94 approach proposed by the 6rd sunsetting draft. We also =
can=92t unprefer and invalidate the prefix to the LAN.
>=20
>=20
> Why do you need to route based on source address? If it's the same ISP =
moving its users from 6rd to native, I would assume that it doesn't =
matter whether the CPE sends packets out the native interface or the 6rd =
interface, since they'll both be accepted by the ISP.
>=20
> Depending if RPF is running on the network, the operator may need/want =
to have the outgoing traffic leave a given interface (i.e. if strict =
mode RFP running on either the upstream router at the BR or the gateway =
north of the native CE path).

Yes, that's something you might have to worry about if two separate =
prefixes are being used during a staged cutover from 6rd to native. Just =
like bringing up any second interface and then tearing down the first.=20=


>=20
> Although even in this case, not sure way SBR is needed - metric should =
be ok there.
>=20
> Now my 2 cents....
>=20
> All that said, I not sure why I would leave both on in the first =
place.  The complexity of having two paths for the same prefix seems a =
bit much.  Once I have a native path, I would break the 6RD path (in my =
operational environment). Sure the transitioned customer may need to go =
via a BR to talk to other 6RD endpoints, but not sure if this traffic =
volume is that big of a deal.

That's certainly an option. You MUST renumber the user to a new prefix =
outside the 6rd domain in this case of course. So, this is either =
immediate or staged, and if staged you have to deal with the =
"multihomed" 6rd+native case for at least a period of time. The most =
apparent to the user of course is a "flash-cut", but if that's not a =
problem, then it might be the easiest way to go for you.=20

I'm just trying to keep the CPE simple, and the choice of migration in =
the hands of the operator here.=20

> Most traffic is to/from the Internet, Caches, CDNs.

(and CGNs...? :-)

You might find once the end-to-end Internet is returned with v6 you =
might have less centralization in the network ;-)=20

I agree though, depending on the network the added CE-CE traffic through =
the BRs may not be significant. Again, just trying to give you the =
options...

- Mark

>=20
> regards,
>=20
> Victor
>=20
> =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


--Apple-Mail-43-49918423
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252




On Tue, Nov 22, 2011 at =
12:50 AM, Lorenzo Colitti <lorenzo@google.com> =
wrote:


On Thu, Nov 17, 2011 at =
14:29, STARK, BARBARA H <bs7652@att.com> wrote:




In reading through the 6rd sunsetting draft vs. =
6204bis, I think we may not have fully covered the case (in 6204bis) =
where the same prefix is used for 6rd and native. In this case, the =
philosophy of =93route based on source address=94 won=92t work, and we =
should probably use the =93metric=94 approach proposed by the 6rd =
sunsetting draft. We also can=92t unprefer and invalidate the prefix to =
the LAN.





Why do you need to =
route based on source address? If it's the same ISP moving its users =
from 6rd to native, I would assume that it doesn't matter whether the =
CPE sends packets out the native interface or the 6rd interface, since =
they'll both be accepted by the ISP.



Depending if RPF is running on the network, =
the operator may need/want to have the outgoing traffic leave a given =
interface (i.e. if strict mode RFP running on either the upstream router =
at the BR or the gateway north of the native CE =
path).

Yes, that's =
something you might have to worry about if two separate prefixes are =
being used during a staged cutover from 6rd to native. Just like =
bringing up any second interface and then tearing down the =
first. 



Although even in this case, not sure way SBR is needed - metric =
should be ok there.

Now my 2 cents....

All that said, I =
not sure why I would leave both on in the first place.  The =
complexity of having two paths for the same prefix seems a bit =
much.  Once I have a native path, I would break the 6RD path (in my =
operational environment). Sure the transitioned customer may need to go =
via a BR to talk to other 6RD endpoints, but not sure if this traffic =
volume is that big of a =
deal.

That's certainly =
an option. You MUST renumber the user to a new prefix outside the 6rd =
domain in this case of course. So, this is either immediate or staged, =
and if staged you have to deal with the "multihomed" 6rd+native case for =
at least a period of time. The most apparent to the user of course is a =
"flash-cut", but if that's not a problem, then it might be the easiest =
way to go for you. 

I'm just trying to =
keep the CPE simple, and the choice of migration in the hands of the =
operator here. 


Most traffic is to/from the Internet, Caches, =
CDNs.

(and CGNs...? =
:-)

You might find once the end-to-end Internet is =
returned with v6 you might have less centralization in the network =
;-) 

I agree though, depending on the =
network the added CE-CE traffic through the BRs may not be significant. =
Again, just trying to give you the options...

- =
Mark


regards,

Victor

 







_______________________________________________

v6ops mailing list

v6ops@ietf.org

https://www.ietf.org/mailman/listinfo/v6ops




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

=

--Apple-Mail-43-49918423--

From mark@townsley.net  Tue Nov 22 01:54:12 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2258121F8D2D for ; Tue, 22 Nov 2011 01:54:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.46
X-Spam-Level: 
X-Spam-Status: No, score=-3.46 tagged_above=-999 required=5 tests=[AWL=0.138,  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 SqdPK7GKGIxe for ; Tue, 22 Nov 2011 01:54:11 -0800 (PST)
Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1472121F8D03 for ; Tue, 22 Nov 2011 01:54:10 -0800 (PST)
Received: by eyg24 with SMTP id 24so7243003eyg.31 for ; Tue, 22 Nov 2011 01:54:10 -0800 (PST)
Received: by 10.180.24.65 with SMTP id s1mr17868018wif.59.1321955649959; Tue, 22 Nov 2011 01:54:09 -0800 (PST)
Received: from ams-townsley-8712.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id j5sm6444277wix.20.2011.11.22.01.54.07 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 22 Nov 2011 01:54:08 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-44-51063002
From: Mark Townsley 
In-Reply-To: 
Date: Tue, 22 Nov 2011 10:54:06 +0100
Message-Id: <40F8EF95-C00D-45AF-A578-5C3628C896EB@townsley.net>
References:   <68DAB112-6E32-45FE-9AB7-A34E64898F60@cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30354436E@XMB-RCD-109.cisco.com> <750BF7861EBBE048B3E648B4BB6E8F4F20DC41F6@crexc50p>  <252D3DEA-FF09-42C8-959E-8A7205D9DE67@townsley.net> 
To: Lorenzo Colitti 
X-Mailer: Apple Mail (2.1084)
Cc: Claire Cheng , v6ops@ietf.org, Alexandre Cassen 
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Nov 2011 09:54:12 -0000

--Apple-Mail-44-51063002
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On Nov 22, 2011, at 10:34 AM, Lorenzo Colitti wrote:

> On Tue, Nov 22, 2011 at 18:25, Mark Townsley  =
wrote:
>> Why do you need to route based on source address? If it's the same =
ISP moving its users from 6rd to native, I would assume that it doesn't =
matter whether the CPE sends packets out the native interface or the 6rd =
interface, since they'll both be accepted by the ISP.
>=20
> That's certainly the idea in the "same delegated prefix" case. In the =
"separate prefix" case, they *could* be separate ISPs (particularly when =
manually configuring 6rd, but that may be out of scope here).=20
>=20
> If you want to support 6rd service being provided by a different ISP =
than native IPv6 service you may have to deal with ingress filtering =
issues. If you choose to do so on the CE router, that will complicate =
the implementation because it requires the CE router to do source-based =
routing.
>=20
> I think doing this in the CE router is a bad idea because it =
complicates the implementation all the time for a scenario (different =
6rd ISP vs. native ISP) that is essentially an edge case. Since edge =
cases tend to be hard to test for, the CE router implementations might =
not get it right all the time, and if even if just a few of them don't =
get it right, you're now dropping customer traffic so you're basically =
forced to relax the ingress filtering anyway.

Perhaps there is room for a "conservative in what you send" and "liberal =
in what you accept" bit of advice here.=20

>=20
> I think we should make the CE router assume that if it is =
simultaneously provisioned with 6rd and native it should not do policy =
routing and place the burden of getting ingress filtering right on =
ISP/ISPs that is/are providing the connectivity. After all, if I'm an =
ISP and use the 6rd connectivity from another ISP, that ISP will know =
I'm a customer of theirs.

For a CE that is only capable of supporting one ISP on its native =
interfaces anyway, I agree. And, the case I mentioned above where 6rd =
terminates outside the ISP for which v4 is served, you are likely in =
"manual config" territory anyway, and all bets are off. I don't think we =
need to specify how much control the CE does or does not give here once =
the config is exposed to the user. =20

I think it might get more complicated as you introduce CE that can =
multihome to different ISPs in general. But, here you have introduced =
and will be reliant upon source routing anyway.

- Mark=

--Apple-Mail-44-51063002
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii


On Nov 22, 2011, at 10:34 AM, Lorenzo Colitti wrote:

On Tue, Nov 22, 2011 at 18:25, Mark Townsley <mark@townsley.net> wrote:




Why do you need to route based on source address? If it's the same ISP moving its users from 6rd to native, I would assume that it doesn't matter whether the CPE sends packets out the native interface or the 6rd interface, since they'll both be accepted by the ISP.





That's certainly the idea in the "same delegated prefix" case. In the "separate prefix" case, they *could* be separate ISPs (particularly when manually configuring 6rd, but that may be out of scope here). 





If you want to support 6rd service being provided by a different ISP than native IPv6 service you may have to deal with ingress filtering issues. If you choose to do so on the CE router, that will complicate the implementation because it requires the CE router to do source-based routing.





I think doing this in the CE router is a bad idea because it complicates the implementation all the time for a scenario (different 6rd ISP vs. native ISP) that is essentially an edge case. Since edge cases tend to be hard to test for, the CE router implementations might not get it right all the time, and if even if just a few of them don't get it right, you're now dropping customer traffic so you're basically forced to relax the ingress filtering anyway.

Perhaps there is room for a "conservative in what you send" and "liberal in what you accept" bit of advice here. 






I think we should make the CE router assume that if it is simultaneously provisioned with 6rd and native it should not do policy routing and place the burden of getting ingress filtering right on ISP/ISPs that is/are providing the connectivity. After all, if I'm an ISP and use the 6rd connectivity from another ISP, that ISP will know I'm a customer of theirs.







For a CE that is only capable of supporting one ISP on its native interfaces anyway, I agree. And, the case I mentioned above where 6rd terminates outside the ISP for which v4 is served, you are likely in "manual config" territory anyway, and all bets are off. I don't think we need to specify how much control the CE does or does not give here once the config is exposed to the user.  

I think it might get more complicated as you introduce CE that can multihome to different ISPs in general. But, here you have introduced and will be reliant upon source routing anyway.

- Mark

--Apple-Mail-44-51063002--

From frnkblk@iname.com  Tue Nov 22 01:59:50 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD51821F8D28 for ; Tue, 22 Nov 2011 01:59:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.718
X-Spam-Level: 
X-Spam-Status: No, score=-1.718 tagged_above=-999 required=5 tests=[AWL=0.381,  BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Nckcez3ZMZI for ; Tue, 22 Nov 2011 01:59:50 -0800 (PST)
Received: from premieronline.net (smtp2-2.premieronline.net [96.31.0.27]) by ietfa.amsl.com (Postfix) with ESMTP id 3C73621F8D26 for ; Tue, 22 Nov 2011 01:59:50 -0800 (PST)
X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=199.120.69.4; 
Received: from FRANKBULK (unverified [199.120.69.4])  by premieronline.net (SurgeMail 5.0n) with ESMTP (TLS) id 7041289-1729245 for multiple; Tue, 22 Nov 2011 03:59:48 -0600
From: "Frank Bulk" 
To: "'Ole Troan'" 
References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com><5B6B2B64C9FE2A489045EEEADDAFF2C30354473D@XMB-RCD-109.cisco.com><4EC455D6.8030601@bogus.com><7EB596BF-B175-40BF-ABC8-326599670B04@apple.com><5B6B2B64C9FE2A489045EEEADDAFF2C303544B88@XMB-RCD-109.cisco.com>	<8D342733-88E6-45D3-B388-E001AE32CD77@employees.org>	<750BF7861EBBE048B3E648B4BB6E8F4F20DC4FEA@crexc50p>  <007801cca8c8$5610aa00$0231fe00$@iname.com> 
In-Reply-To: 
Date: Tue, 22 Nov 2011 03:59:48 -0600
Message-ID: <00f801cca8fd$784fcdf0$68ef69d0$@iname.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Acyo9Ta6zDxQCmtbRe+A/T1FEio/0gAB4tCg
Content-Language: en-us
X-Authenticated-User: fbulk@premieronline.net 
X-SpamDetect: : 0.000000 
X-Info: aspam skipped due to (g_smite_skip_auth)
X-Encryption: SSL encrypted
X-MyRbl: Color=Unknown (rbl) Age=0 Spam=0 Notspam=0 Stars=0 Good=1 Friend=0 Surbl=0 Catch=0 r=0 ip=199.120.69.4
X-IP-stats: Incoming Last 0, First 986, in=1835, out=0, spam=0 ip=199.120.69.4
Cc: IPv6 Operations 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: frnkblk@iname.com
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Nov 2011 09:59:50 -0000

Thanks for clarifying.

It's my understanding that if the CPE is using the unnumbered model it will
request a PD and if it's a device that must meet the CableLabs specs then it
will not request a PD.

Why do we have to specify behavior for M=O=0?

Frank

-----Original Message-----
From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of Ole Troan
Sent: Tuesday, November 22, 2011 3:01 AM
To: Frank Bulk
Cc: IPv6 Operations
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT

Frank,

> What's fuzzy?

from Barbara:

>  WPD-4:  The IPv6 CE router MUST always initiate DHCPv6 prefix
>          delegation, regardless of the M and O flags in a received
>          Router Advertisement message.
> 
> I still think this is a reasonable change.
> It doesn't preclude the previous behavior of doing DHCPv6 IA_PD,
> regardless of M/O. It just doesn't mandate it. Now it only mandates it
> if M or O=1. The current language leaves it up to the vendor (or other
> specs) as to what to do when M=O=0, or no received RA. Devices compliant
> under the old requirement are still compliant under the new requirement.

CPE receives and RA with M=O=0, what is it supposed to do with regards to
PD?
left up to the vendor to decide?

cheers,
Ole



From ichiroumakino@gmail.com  Tue Nov 22 02:03:41 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCF8D21F8B31 for ; Tue, 22 Nov 2011 02:03:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.557
X-Spam-Level: 
X-Spam-Status: No, score=-3.557 tagged_above=-999 required=5 tests=[AWL=0.042,  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 6oKiF5ImlWXe for ; Tue, 22 Nov 2011 02:03:41 -0800 (PST)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id DC5D921F8B7C for ; Tue, 22 Nov 2011 02:03:40 -0800 (PST)
Received: by wwe5 with SMTP id 5so12727wwe.13 for ; Tue, 22 Nov 2011 02:03:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=xVl6DxCp/6YhYkfcQVyUN5Qihux9teHhMk2i2S7gnXk=; b=PBDni868x0p8+iFh4e+nNa1j1WvGzbL0R6sjJfggbl1PF+02sekiyr/TnT6G6cwJiu RBXBiWZAfDyyj+czT5/nTmMRANDVEUCj9Eqw3ZbbR+agrp8uWcy+1x5xcoi7DYTvPnDJ IF3zNNi/MiCWikuUIlEbk0nzSIrlepSq84OvQ=
Received: by 10.227.206.66 with SMTP id ft2mr11781045wbb.24.1321956220056; Tue, 22 Nov 2011 02:03:40 -0800 (PST)
Received: from ams3-vpn-dhcp5208.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id j5sm6454632wix.20.2011.11.22.02.03.38 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 22 Nov 2011 02:03:39 -0800 (PST)
Sender: Ole Troan 
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Ole Troan 
In-Reply-To: <00f801cca8fd$784fcdf0$68ef69d0$@iname.com>
Date: Tue, 22 Nov 2011 11:03:36 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <418C43A6-5E8A-4CBD-83F4-3C5F502213A1@employees.org>
References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com><5B6B2B64C9FE2A489045EEEADDAFF2C30354473D@XMB-RCD-109.cisco.com><4EC455D6.8030601@bogus.com><7EB596BF-B175-40BF-ABC8-326599670B04@apple.com><5B6B2B64C9FE2A489045EEEADDAFF2C303544B88@XMB-RCD-109.cisco.com>	<8D342733-88E6-45D3-B388-E001AE32CD77@employees.org>	<750BF7861EBBE048B3E648B4BB6E8F4F20DC4FEA@crexc50p>  <007801cca8c8$5610aa00$0231fe00$@iname.com>  <00f801cca8fd$784fcdf0$68ef69d0$@iname.com>
To: 
X-Mailer: Apple Mail (2.1084)
Cc: IPv6 Operations 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Nov 2011 10:03:41 -0000

Frank,

> It's my understanding that if the CPE is using the unnumbered model it =
will
> request a PD and if it's a device that must meet the CableLabs specs =
then it
> will not request a PD.

I'm aware of no such requirement. I haven't seen anything in DOCSIS 3.0 =
that require a CE router _not_ to request a PD.
the issue discussed has been about the "DHCP storm" created when IPv6 is =
enabled but the policy on the DHCP server is to not hand out addresses =
or prefixes. we've got a fix for that in DHCP.

> Why do we have to specify behavior for M=3DO=3D0?

there isn't a use case for an ISP wanting to _only_ do IA_PD?
as in not DHCP for other configuration information nor for address =
assignment.

cheers,
Ole

> From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of Ole =
Troan
> Sent: Tuesday, November 22, 2011 3:01 AM
> To: Frank Bulk
> Cc: IPv6 Operations
> Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
>=20
> Frank,
>=20
>> What's fuzzy?
>=20
> from Barbara:
>=20
>> WPD-4:  The IPv6 CE router MUST always initiate DHCPv6 prefix
>>         delegation, regardless of the M and O flags in a received
>>         Router Advertisement message.
>>=20
>> I still think this is a reasonable change.
>> It doesn't preclude the previous behavior of doing DHCPv6 IA_PD,
>> regardless of M/O. It just doesn't mandate it. Now it only mandates =
it
>> if M or O=3D1. The current language leaves it up to the vendor (or =
other
>> specs) as to what to do when M=3DO=3D0, or no received RA. Devices =
compliant
>> under the old requirement are still compliant under the new =
requirement.
>=20
> CPE receives and RA with M=3DO=3D0, what is it supposed to do with =
regards to
> PD?
> left up to the vendor to decide?
>=20
> cheers,
> Ole
>=20
>=20


From mark@townsley.net  Tue Nov 22 02:12:59 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D569E21F8BBE for ; Tue, 22 Nov 2011 02:12:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.17
X-Spam-Level: 
X-Spam-Status: No, score=-3.17 tagged_above=-999 required=5 tests=[AWL=-0.172,  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 OKHLd8MiDvQu for ; Tue, 22 Nov 2011 02:12:59 -0800 (PST)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 91B9721F8BBC for ; Tue, 22 Nov 2011 02:12:58 -0800 (PST)
Received: by wwe5 with SMTP id 5so21552wwe.13 for ; Tue, 22 Nov 2011 02:12:57 -0800 (PST)
Received: by 10.216.137.86 with SMTP id x64mr2915463wei.2.1321956314208; Tue, 22 Nov 2011 02:05:14 -0800 (PST)
Received: from ams-townsley-8712.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id et20sm16057742wbb.15.2011.11.22.02.05.12 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 22 Nov 2011 02:05:13 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-45-51727507
From: Mark Townsley 
In-Reply-To: 
Date: Tue, 22 Nov 2011 11:05:11 +0100
Message-Id: 
References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com>  <5B6B2B64C9FE2A489045EEEADDAFF2C30354473D@XMB-RCD-109.cisco.com> <4EC455D6.8030601@bogus.com>   <7EB596BF-B175-40BF-ABC8-326599670B04@apple.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303544B88@XMB-RCD-109.cisco.com>    <8D342733-88E6-45D3-B388-E001AE32CD77@employees.org> <750BF7861EBBE048B3E648B4BB6E8F4F20DC4FEA@crexc50p>  <007801cca8c8$5610aa00$0231fe00$@iname.com>  
To: Lorenzo Colitti 
X-Mailer: Apple Mail (2.1084)
Cc: IPv6 Operations 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Nov 2011 10:12:59 -0000

--Apple-Mail-45-51727507
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On Nov 22, 2011, at 10:20 AM, Lorenzo Colitti wrote:

> On Tue, Nov 22, 2011 at 18:00, Ole Troan  wrote:
> >  WPD-4:  The IPv6 CE router MUST always initiate DHCPv6 prefix
> >          delegation, regardless of the M and O flags in a received
> >          Router Advertisement message.
> >
> > I still think this is a reasonable change.
> > It doesn't preclude the previous behavior of doing DHCPv6 IA_PD,
> > regardless of M/O. It just doesn't mandate it. Now it only mandates =
it
> > if M or O=3D1. The current language leaves it up to the vendor (or =
other
> > specs) as to what to do when M=3DO=3D0, or no received RA. Devices =
compliant
> > under the old requirement are still compliant under the new =
requirement.
>=20
> CPE receives and RA with M=3DO=3D0, what is it supposed to do with =
regards to PD?
> left up to the vendor to decide?
>=20
> Not do PD. Also not do PD if it doesn't have an RA at all, since a =
prefix without a route is useless.
>=20
> Hmm, I think I can hear the cries already... "DHCPv6 PD is just a fax =
replacement! Routing has nothing to do with addressing! Routers don't =
listen to RAs!". IMO none of those are true. :-)

Architectural arguments aside and more to running code, did we not hear =
that there is equipment in the field already that *expects* home routers =
to give up and send DHCPv6 even with no RA received? I think I have now =
heard two cases, from two different vendors, where we have this =
expectation today. Couple that with CE that send 3-4 RS and, if no RA =
received, start sending DHCPv6 from two different large retail CPE =
vendors, and I worry that cat is out of the bag on this one. =
"Conservative in what you send" already lost the battle, and "liberal in =
what you accept" is having to make up for it this time.=20

- Mark=20

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


--Apple-Mail-45-51727507
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii


On Tue, Nov 22, 2011 at 18:00, =
Ole Troan <otroan@employees.org> =
wrote:




>  WPD-4:  The IPv6 CE router MUST always initiate =
DHCPv6 prefix

>          delegation, regardless of the M =
and O flags in a received

>          Router Advertisement message.

>

> I still think this is a reasonable change.

> It doesn't preclude the previous behavior of doing DHCPv6 =
IA_PD,

> regardless of M/O. It just doesn't mandate it. Now it only mandates =
it

> if M or O=3D1. The current language leaves it up to the vendor (or =
other

> specs) as to what to do when M=3DO=3D0, or no received RA. Devices =
compliant

> under the old requirement are still compliant under the new =
requirement.




CPE receives and RA with M=3DO=3D0, what is it supposed to do with =
regards to PD?

left up to the vendor to decide?

Not do =
PD. Also not do PD if it doesn't have an RA at all, since a prefix =
without a route is useless.

Hmm, I think I can =
hear the cries already... "DHCPv6 PD is just a fax replacement! Routing =
has nothing to do with addressing! Routers don't listen to =
RAs!". IMO none of those are =
true. :-)

Architectural =
arguments aside and more to running code, did we not hear that there is =
equipment in the field already that *expects* home routers to give up =
and send DHCPv6 even with no RA received? I think I have now heard two =
cases, from two different vendors, where we have this expectation today. =
Couple that with CE that send 3-4 RS and, if no RA received, start =
sending DHCPv6 from two different large retail CPE vendors, and I worry =
that cat is out of the bag on this one. "Conservative in what you send" =
already lost the battle, and "liberal in what you accept" is having to =
make up for it this time. 

- =
Mark 





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

=

--Apple-Mail-45-51727507--

From frnkblk@iname.com  Tue Nov 22 02:25:41 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9236521F8D7B for ; Tue, 22 Nov 2011 02:25:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.772
X-Spam-Level: 
X-Spam-Status: No, score=-1.772 tagged_above=-999 required=5 tests=[AWL=0.327,  BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZ+r2ZfZi6et for ; Tue, 22 Nov 2011 02:25:41 -0800 (PST)
Received: from premieronline.net (smtp2-5.premieronline.net [96.31.0.30]) by ietfa.amsl.com (Postfix) with ESMTP id F0DF021F8D73 for ; Tue, 22 Nov 2011 02:25:40 -0800 (PST)
X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=199.120.69.4; 
Received: from FRANKBULK (unverified [199.120.69.4])  by premieronline.net (SurgeMail 5.0n) with ESMTP (TLS) id 7041808-1729245 for multiple; Tue, 22 Nov 2011 04:25:37 -0600
From: "Frank Bulk" 
To: "'Ole Troan'" 
References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com><5B6B2B64C9FE2A489045EEEADDAFF2C30354473D@XMB-RCD-109.cisco.com><4EC455D6.8030601@bogus.com><7EB596BF-B175-40BF-ABC8-326599670B04@apple.com><5B6B2B64C9FE2A489045EEEADDAFF2C303544B88@XMB-RCD-109.cisco.com>	<8D342733-88E6-45D3-B388-E001AE32CD77@employees.org>	<750BF7861EBBE048B3E648B4BB6E8F4F20DC4FEA@crexc50p>  <007801cca8c8$5610aa00$0231fe00$@iname.com>  <00f801cca8fd$784fcdf0$68ef69d0$@iname.com> <418C43A6-5E8A-4CBD-83F4-3C5F502213A1@employees.org>
In-Reply-To: <418C43A6-5E8A-4CBD-83F4-3C5F502213A1@employees.org>
Date: Tue, 22 Nov 2011 04:25:35 -0600
Message-ID: <00f901cca901$129a5f30$37cf1d90$@iname.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Acyo/gZba+JZJWZPTCaHZeuxwATJggAAmTPw
Content-Language: en-us
X-Authenticated-User: fbulk@premieronline.net 
X-SpamDetect: : 0.000000 
X-Info: aspam skipped due to (g_smite_skip_auth)
X-Encryption: SSL encrypted
X-MyRbl: Color=Unknown (rbl) Age=0 Spam=0 Notspam=0 Stars=0 Good=1 Friend=0 Surbl=0 Catch=0 r=0 ip=199.120.69.4
X-IP-stats: Incoming Last 0, First 986, in=1836, out=0, spam=0 ip=199.120.69.4
Cc: IPv6 Operations 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: frnkblk@iname.com
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Nov 2011 10:25:41 -0000

You're right, there's nothing currently in the CableLabs specs that require
a CE router not to request a PD, but my understanding is that what the MSO
folks want to avoid the DHCPv6 storm.  Looping in Chris here to correct me
if I'm wrong.

I don't know of a use case for an ISP wanting to only do IA_PD.  As the
others have said, why get a prefix that's not routable out the WAN?
Hopefully someone else who knows of such a use case can pipe in.

The way the rfc6402bis (and others) are written today, is there anything
that would prevent the CPE from doing an IA_PD upon receiving an RA for
M=O=0?  If not, I think we've left in a good amount of flexibility for the
future.

Frank

-----Original Message-----
From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of Ole Troan
Sent: Tuesday, November 22, 2011 4:04 AM
To: frnkblk@iname.com
Cc: IPv6 Operations
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT

Frank,

> It's my understanding that if the CPE is using the unnumbered model it
will
> request a PD and if it's a device that must meet the CableLabs specs then
it
> will not request a PD.

I'm aware of no such requirement. I haven't seen anything in DOCSIS 3.0 that
require a CE router _not_ to request a PD.
the issue discussed has been about the "DHCP storm" created when IPv6 is
enabled but the policy on the DHCP server is to not hand out addresses or
prefixes. we've got a fix for that in DHCP.

> Why do we have to specify behavior for M=O=0?

there isn't a use case for an ISP wanting to _only_ do IA_PD?
as in not DHCP for other configuration information nor for address
assignment.

cheers,
Ole

> From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of Ole Troan
> Sent: Tuesday, November 22, 2011 3:01 AM
> To: Frank Bulk
> Cc: IPv6 Operations
> Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
> 
> Frank,
> 
>> What's fuzzy?
> 
> from Barbara:
> 
>> WPD-4:  The IPv6 CE router MUST always initiate DHCPv6 prefix
>>         delegation, regardless of the M and O flags in a received
>>         Router Advertisement message.
>> 
>> I still think this is a reasonable change.
>> It doesn't preclude the previous behavior of doing DHCPv6 IA_PD,
>> regardless of M/O. It just doesn't mandate it. Now it only mandates it
>> if M or O=1. The current language leaves it up to the vendor (or other
>> specs) as to what to do when M=O=0, or no received RA. Devices compliant
>> under the old requirement are still compliant under the new requirement.
> 
> CPE receives and RA with M=O=0, what is it supposed to do with regards to
> PD?
> left up to the vendor to decide?
> 
> cheers,
> Ole
> 
> 




From sthaug@nethelp.no  Tue Nov 22 02:25:44 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ACE021F8DA2 for ; Tue, 22 Nov 2011 02:25:44 -0800 (PST)
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, 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 XJCX-VEuwUUo for ; Tue, 22 Nov 2011 02:25:43 -0800 (PST)
Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 3957821F8D8E for ; Tue, 22 Nov 2011 02:25:43 -0800 (PST)
Received: (qmail 76920 invoked from network); 22 Nov 2011 10:25:40 -0000
Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 22 Nov 2011 10:25:40 -0000
Date: Tue, 22 Nov 2011 11:25:40 +0100 (CET)
Message-Id: <20111122.112540.74674127.sthaug@nethelp.no>
To: otroan@employees.org
From: sthaug@nethelp.no
In-Reply-To: <418C43A6-5E8A-4CBD-83F4-3C5F502213A1@employees.org>
References:  <00f801cca8fd$784fcdf0$68ef69d0$@iname.com> <418C43A6-5E8A-4CBD-83F4-3C5F502213A1@employees.org>
X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: v6ops@ietf.org
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Nov 2011 10:25:44 -0000

> > Why do we have to specify behavior for M=O=0?
> 
> there isn't a use case for an ISP wanting to _only_ do IA_PD?

I'd love to do only IA_PD (and not IA_NA) - but I would most likely
want to hand out DNS servers etc. also.

Steinar Haug, Nethelp consulting, sthaug@nethelp.no

From frnkblk@iname.com  Tue Nov 22 02:26:35 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FBA521F8D8E for ; Tue, 22 Nov 2011 02:26:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.813
X-Spam-Level: 
X-Spam-Status: No, score=-1.813 tagged_above=-999 required=5 tests=[AWL=0.286,  BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZKRepOdYRIS9 for ; Tue, 22 Nov 2011 02:26:35 -0800 (PST)
Received: from premieronline.net (smtp1-5.premieronline.net [96.31.0.25]) by ietfa.amsl.com (Postfix) with ESMTP id 50D3321F8DAD for ; Tue, 22 Nov 2011 02:26:34 -0800 (PST)
X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=199.120.69.4; 
Received: from FRANKBULK (unverified [199.120.69.4])  by premieronline.net (SurgeMail 5.0n) with ESMTP (TLS) id 33935366-1729245 for multiple; Tue, 22 Nov 2011 04:26:32 -0600
From: "Frank Bulk" 
To: 
References: 	<00f801cca8fd$784fcdf0$68ef69d0$@iname.com>	<418C43A6-5E8A-4CBD-83F4-3C5F502213A1@employees.org> <20111122.112540.74674127.sthaug@nethelp.no>
In-Reply-To: <20111122.112540.74674127.sthaug@nethelp.no>
Date: Tue, 22 Nov 2011 04:26:33 -0600
Message-ID: <00fa01cca901$34b6d300$9e247900$@iname.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AcypARsjfkHAVasPQsu9VqWVlkDVrAAAAwmw
Content-Language: en-us
X-Authenticated-User: fbulk@premieronline.net 
X-SpamDetect: : 0.000000 
X-Info: aspam skipped due to (g_smite_skip_auth)
X-Encryption: SSL encrypted
X-MyRbl: Color=Unknown (rbl) Age=0 Spam=0 Notspam=0 Stars=0 Good=1 Friend=0 Surbl=0 Catch=0 r=0 ip=199.120.69.4
X-IP-stats: Incoming Last 0, First 987, in=1697, out=0, spam=0 ip=199.120.69.4
Cc: v6ops@ietf.org
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: frnkblk@iname.com
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Nov 2011 10:26:35 -0000

And you can do that if O=1, right?

Frank

-----Original Message-----
From: sthaug@nethelp.no [mailto:sthaug@nethelp.no] 
Sent: Tuesday, November 22, 2011 4:26 AM
To: otroan@employees.org
Cc: frnkblk@iname.com; v6ops@ietf.org
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT

> > Why do we have to specify behavior for M=O=0?
> 
> there isn't a use case for an ISP wanting to _only_ do IA_PD?

I'd love to do only IA_PD (and not IA_NA) - but I would most likely
want to hand out DNS servers etc. also.

Steinar Haug, Nethelp consulting, sthaug@nethelp.no



From lorenzo@google.com  Tue Nov 22 02:27:35 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 387D321F8DB4 for ; Tue, 22 Nov 2011 02:27:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.901
X-Spam-Level: 
X-Spam-Status: No, score=-102.901 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id chCdZYnPQhFX for ; Tue, 22 Nov 2011 02:27:34 -0800 (PST)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id A84F221F8DA9 for ; Tue, 22 Nov 2011 02:27:34 -0800 (PST)
Received: by ggnp4 with SMTP id p4so36751ggn.31 for ; Tue, 22 Nov 2011 02:27:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=wfM144oFqKg513gUOui0S+q8QoB2o7QskW7G0KC52IM=; b=lBmPCpjJmmG8CA7OpUjG/QnwTuywuGwJLqwe11zPU9j5+4FOlCbw4lN4gK3jNkDd0R WkJVvGRov4VyVqmb6VNQ==
Received: by 10.236.75.167 with SMTP id z27mr25847085yhd.53.1321957654254; Tue, 22 Nov 2011 02:27:34 -0800 (PST)
Received: by 10.236.75.167 with SMTP id z27mr25847070yhd.53.1321957654149; Tue, 22 Nov 2011 02:27:34 -0800 (PST)
MIME-Version: 1.0
Received: by 10.150.202.14 with HTTP; Tue, 22 Nov 2011 02:27:13 -0800 (PST)
In-Reply-To: <418C43A6-5E8A-4CBD-83F4-3C5F502213A1@employees.org>
References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com>  <5B6B2B64C9FE2A489045EEEADDAFF2C30354473D@XMB-RCD-109.cisco.com> <4EC455D6.8030601@bogus.com>   <7EB596BF-B175-40BF-ABC8-326599670B04@apple.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303544B88@XMB-RCD-109.cisco.com>    <8D342733-88E6-45D3-B388-E001AE32CD77@employees.org> <750BF7861EBBE048B3E648B4BB6E8F4F20DC4FEA@crexc50p>  <007801cca8c8$5610aa00$0231fe00$@iname.com>  <00f801cca8fd$784fcdf0$68ef69d0$@iname.com> <418C43A6-5E8A-4CBD-83F4-3C5F502213A1@employees.org>
From: Lorenzo Colitti 
Date: Tue, 22 Nov 2011 19:27:13 +0900
Message-ID: 
To: Ole Troan 
Content-Type: multipart/alternative; boundary=20cf3005dde6623bbf04b2504042
X-System-Of-Record: true
Cc: IPv6 Operations 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Nov 2011 10:27:35 -0000

--20cf3005dde6623bbf04b2504042
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Nov 22, 2011 at 19:03, Ole Troan  wrote:

> > Why do we have to specify behavior for M=O=0?
>
> there isn't a use case for an ISP wanting to _only_ do IA_PD?
> as in not DHCP for other configuration information nor for address
> assignment.
>

Yes, there is a use case for an ISP wanting to do only IA_PD and either
unnumbered or SLAAC on the WAN interface.

I think this should be indicated by M=0, O=1, as this is what's most
consistent with the current definition of the M/O bits in (RFC 4861; a
prefix is not "address information", and therefore it's "other
configuration information").

I believe that this is, for example, what the Apple implementation does -
in order to get it to do DHCPv6 PD, you need to send it an RA with O=1.

--20cf3005dde6623bbf04b2504042
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Tue, Nov 22, 2011 at 19:03, Ole Troan <otroan@employees.org=
> wrote:



> Why do we have to specify behavior for M=3DO=3D0?



there isn't a use case for an ISP wanting to _only_ do IA_PD?

as in not DHCP for other configuration information nor for address assignme=
nt.

Yes, there is a use case for an ISP=
 wanting to do only IA_PD and either unnumbered or SLAAC on the WAN interfa=
ce.




I think this should be indicated by M=3D0, O=3D1, as th=
is is what's most consistent with the current definition of the M/O bit=
s in (RFC 4861; a prefix is not "address information", and theref=
ore it's "other configuration information").




I believe that this is, for example, what the Apple imp=
lementation does - in order to get it to do DHCPv6 PD, you need to send it =
an RA with O=3D1.


--20cf3005dde6623bbf04b2504042--

From Carl.Wuyts@technicolor.com  Tue Nov 22 02:27:35 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3A1321F8DA9 for ; Tue, 22 Nov 2011 02:27:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.496
X-Spam-Level: 
X-Spam-Status: No, score=-4.496 tagged_above=-999 required=5 tests=[AWL=-0.318, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9FnxQ+VrdfbI for ; Tue, 22 Nov 2011 02:27:32 -0800 (PST)
Received: from na3sys009aog112.obsmtp.com (na3sys009aog112.obsmtp.com [74.125.149.207]) by ietfa.amsl.com (Postfix) with ESMTP id 9EF6A21F8DA4 for ; Tue, 22 Nov 2011 02:27:25 -0800 (PST)
Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob112.postini.com ([74.125.148.12]) with SMTP ID DSNKTst5DCMITQo+YmhxuI+xAtYJGP7oaNfr@postini.com; Tue, 22 Nov 2011 02:27:30 PST
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.192.1; Tue, 22 Nov 2011 11:22:49 +0100
Received: from MOPESMBX01.eu.thmulti.com ([169.254.155.121]) by MOPESMAILHC02.eu.thmulti.com ([141.11.100.29]) with mapi; Tue, 22 Nov 2011 11:22:51 +0100
From: Wuyts Carl 
To: Lorenzo Colitti , Mark Townsley 
Date: Tue, 22 Nov 2011 11:22:50 +0100
Thread-Topic: [v6ops] 6rd Sunsetting
Thread-Index: Acyo+f7qAEjIvi1wTc2piASgo9e7NwAAZt+w
Message-ID: <867F4B6A1672E541A94676D556793ACD0C2766DAD4@MOPESMBX01.eu.thmulti.com>
References:   <68DAB112-6E32-45FE-9AB7-A34E64898F60@cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30354436E@XMB-RCD-109.cisco.com> <750BF7861EBBE048B3E648B4BB6E8F4F20DC41F6@crexc50p>  <252D3DEA-FF09-42C8-959E-8A7205D9DE67@townsley.net> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/related; boundary="_006_867F4B6A1672E541A94676D556793ACD0C2766DAD4MOPESMBX01eut_"; type="multipart/alternative"
MIME-Version: 1.0
Cc: Claire Cheng , "v6ops@ietf.org" , Alexandre Cassen 
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Nov 2011 10:27:35 -0000

--_006_867F4B6A1672E541A94676D556793ACD0C2766DAD4MOPESMBX01eut_
Content-Type: multipart/alternative;
	boundary="_000_867F4B6A1672E541A94676D556793ACD0C2766DAD4MOPESMBX01eut_"

--_000_867F4B6A1672E541A94676D556793ACD0C2766DAD4MOPESMBX01eut_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

+1, indeed nothing to be pushed to the CPE side.

Carl Wuyts
GCD System Architect Networking
Connect Division

carl.wuyts@technicolor.com
tel.: +32 3 443 65 90
[cid:image001.gif@01CCA904.69D65800]
[cid:image002.gif@01CCA904.69D65800]
Prins Boudewijnlaan 47  -  2650 Edegem  -  Belgium

Technicolor Delivery Technologies Belgium NV
Registered office (maatschappelijke zetel): Prins Boudewijnlaan 47, 2650 Ed=
egem, Belgium
Company registration number (ondernemingsnummer): 0428837295 - RPR Antwerpe=
n
[cid:image003.gif@01CCA904.69D65800]

Help preserve the color of our world - Think before you print.





From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of L=
orenzo Colitti
Sent: dinsdag 22 november 2011 10:34
To: Mark Townsley
Cc: Claire Cheng; v6ops@ietf.org; Alexandre Cassen
Subject: Re: [v6ops] 6rd Sunsetting

On Tue, Nov 22, 2011 at 18:25, Mark Townsley > wrote:
Why do you need to route based on source address? If it's the same ISP movi=
ng its users from 6rd to native, I would assume that it doesn't matter whet=
her the CPE sends packets out the native interface or the 6rd interface, si=
nce they'll both be accepted by the ISP.

That's certainly the idea in the "same delegated prefix" case. In the "sepa=
rate prefix" case, they *could* be separate ISPs (particularly when manuall=
y configuring 6rd, but that may be out of scope here).

If you want to support 6rd service being provided by a different ISP than n=
ative IPv6 service you may have to deal with ingress filtering issues. If y=
ou choose to do so on the CE router, that will complicate the implementatio=
n because it requires the CE router to do source-based routing.

I think doing this in the CE router is a bad idea because it complicates th=
e implementation all the time for a scenario (different 6rd ISP vs. native =
ISP) that is essentially an edge case. Since edge cases tend to be hard to =
test for, the CE router implementations might not get it right all the time=
, and if even if just a few of them don't get it right, you're now dropping=
 customer traffic so you're basically forced to relax the ingress filtering=
 anyway.

I think we should make the CE router assume that if it is simultaneously pr=
ovisioned with 6rd and native it should not do policy routing and place the=
 burden of getting ingress filtering right on ISP/ISPs that is/are providin=
g the connectivity. After all, if I'm an ISP and use the 6rd connectivity f=
rom another ISP, that ISP will know I'm a customer of theirs.

--_000_867F4B6A1672E541A94676D556793ACD0C2766DAD4MOPESMBX01eut_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


+1, indee=
d nothing to be pushed to the CPE side.  
 
Carl Wuyts
GCD System Architect Networking
Connect Division
carl.wuyts@techn=
icolor.com
tel.: +32 3 443 65 90
3D"Visit
Prins Boudewijnlaan 47  - =
 2650 Edegem  -  Belgium
T=
echnicolor Delivery Technologies Belgium NV<=
o:p>
Registe=
red office (maatschappelijke zetel): Prins Boudewijnlaan 47, 2650 Edegem, B=
elgium
Company registr=
ation number (ondernemingsnummer): 0428837295 - RPR Antwerpen
3DEco
Help preserve the color of our world - Think before=
 you print.
 
 
From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Be=
half Of Lorenzo Colitti
Sent: dinsdag 22 november 2011 10:34<=
br>To: Mark Townsley
Cc: Claire Cheng; v6ops@ietf.org; Ale=
xandre Cassen
Subject: Re: [v6ops] 6rd Sunsetting
 
On Tue, Nov 22, 2011 at 18:25, Mark Townsley <mark@townsley.net> wrote:
Why do you need to route based on =
source address? If it's the same ISP moving its users from 6rd to native, I=
 would assume that it doesn't matter whether the CPE sends packets out the =
native interface or the 6rd interface, since they'll both be accepted by th=
e ISP.
 
That's certai=
nly the idea in the "same delegated prefix" case. In the "se=
parate prefix" case, they *could* be separate ISPs (particularly when =
manually configuring 6rd, but that may be out of scope here). 
 
If you want to support 6rd service being provi=
ded by a different ISP than native IPv6 service you may have to deal with i=
ngress filtering issues. If you choose to do so on the CE router, that will=
 complicate the implementation because it requires the CE router to do sour=
ce-based routing.
 =

I think doing this in the CE rout=
er is a bad idea because it complicates the implementation all the time for=
 a scenario (different 6rd ISP vs. native ISP) that is essentially an edge =
case. Since edge cases tend to be hard to test for, the CE router implement=
ations might not get it right all the time, and if even if just a few of th=
em don't get it right, you're now dropping customer traffic so you're basic=
ally forced to relax the ingress filtering anyway.
 
=
I think we should make the CE router assume that if it is simultaneously pr=
ovisioned with 6rd and native it should not do policy routing and place the=
 burden of getting ingress filtering right on ISP/ISPs that is/are providin=
g the connectivity. After all, if I'm an ISP and use the 6rd connectivity f=
rom another ISP, that ISP will know I'm a customer of theirs.
=

--_000_867F4B6A1672E541A94676D556793ACD0C2766DAD4MOPESMBX01eut_--

--_006_867F4B6A1672E541A94676D556793ACD0C2766DAD4MOPESMBX01eut_
Content-Type: image/gif; name="image001.gif"
Content-Description: image001.gif
Content-Disposition: inline; filename="image001.gif"; size=1351;
	creation-date="Tue, 22 Nov 2011 10:22:49 GMT";
	modification-date="Tue, 22 Nov 2011 10:22:49 GMT"
Content-ID: 
Content-Transfer-Encoding: base64

R0lGODlhGAAYAPcAAAAAAP///1Sfum/L64bW8o7h/ofU74fT7pHb9pfa8u75/VbD5VzG6FvF5l3G
513F5l/G51/F5mHH52PH6GPI6GPI52TH6GXJ6GbI6GnK6mjJ6WjK6WzL6m/M63HN6nPN6nTN63fR
7XnR7XTI5FeVqnnN537T7n7R7H/T7X3O6Y3f+4jV73m903/E2oDE2pTf+ZPc9JTa8Zfa8aDd8LDj
9MXr9+z5/er3+/r9/imy1yyx1S202S2z1zK43TW63jW32zS22Ta53Te73za32zq84Dm53Du73j2/
4j2+4T283z273kHB5D++4EHA4kG/4UPA40K/4UTB5EbD5UbB40rJ7EjD5ErG6EnE5knE5Ua720rE
5kvG507J607I6U3G50/K60u+3U2/4U7A4k2/3lLI6E/A31XN7lHC4VnP8FfL61PD4lXD5FXF41vR
8VfG5VO92lrJ51a+21i/21/O7F7L6VnB3VzE4mHN6l/H5V3D30+lvWDH41/E4GDF4WLH42rL6GvP
6l+2znLZ9W7Q62C1zGO50HXZ9HTY83ba9XXX8mW70nLO6nHN6We803rd+HXV73zf+mm91HXS62vA
12GpvWavw2ixxVmWp2qxxYDW7X3Q52yzxm+2yW60x4HS6HC2yXG3ynzD2I7a75Xb7pvh9F+HkqTg
8ajg76ff7qri8bPo97fm9Ljm9MXw/Mfw/NDz/dDx+tbx+dz0++H1++f5/uv5/Six1S+22jG01zK1
2EXD5E/M7U7H50yvyWPY91zJ5WjZ92za927b+HHY82G4z3Xd+FurwHXa9Xfc93ne+F+rv37h+2u/
1YDi/H7c9YHh+YLh+YXi+mqyxWuzxork+ovj+o3l+3K4ypXn+12PnJrm+qXp+63j8cLx/M/0/ef4
/Jfp+57q+6Xt/Kjv/avv/a3v/a7w/bPw/bzz/uP6/+z7/vP9/7fz/r30/sD0/sX1/sn2/tT4/9L2
/d/6/+X7/+b7/+r8/+v7/sz3/tr5/ub8/+39//v///3///7//////yH5BAEAAP8ALAAAAAAYABgA
AAj/AP8JHEiwoMGCAgggOGCg4YqHEB8aOPCCAEESKmR84MABg0cOHUKGHDCAA4gEBQaOiIHBwgQO
pmrQEEEhg80NGnJewACDhcAUJyBMwBArgL8ACkxc2MBUg8cLEEy0+PkhQoMZAerNmxegBoMLFChc
AFsBQggXAkswerBgVYB8+eLtu7GorgcKDipIcBBi6r8SHtiyCoAPH7x6AXAoxjELRYO9IUIJlGMn
jBi37zLHo2fPXj19/hT8WRMGDzGBb7LosIUqADp07WC7c9eOHbwAmnjwGBNIYBwwuHK0NleOOLnj
5MaxC+BpR64zp//JGQNkx6kA4rKXO8ede7oAe378/1BTSGCdMkNunfIXLhw4eQH6yU88KoiSImzK
/8tzpkiPVP1gg4013gRgYGKmEMEEE0a4oYhAeahhhA/c8FMNNdF0s4466tyzTgCrOAFFEnA0IhAf
bCQhhCkBVPMMNDDC+GI3AUiCBBNwRCJQH24wgUQmAWwjTDJEFllMNAGIcoQTdDAjkB9uODGFFLHw
o00wwGSZpS/bBJDJEk80+eQvTVQhxR2zBECLK6202c0rAchCxhVR3DGJb5I0gYUXVqRBCiy1BFqL
Dd+oMocVW+jyCCEC6ZEIIFps0cUXVOyCRhuYomEGFVx0wcsghlwyUC/DOHPIMcg4AskyzbS6DCSO
ICSDiDOCGFNQNspUYgkmm3TCCSjXgPJJJ9NIYwklpRyk7LIDBQQAOw==

--_006_867F4B6A1672E541A94676D556793ACD0C2766DAD4MOPESMBX01eut_
Content-Type: image/gif; name="image002.gif"
Content-Description: image002.gif
Content-Disposition: inline; filename="image002.gif"; size=1834;
	creation-date="Tue, 22 Nov 2011 10:22:50 GMT";
	modification-date="Tue, 22 Nov 2011 10:22:50 GMT"
Content-ID: 
Content-Transfer-Encoding: base64

R0lGODlhcgBFAOZ/AEGueqipqmgxkACLS4ORyPb294DFpZrMVqvi+sXr2Ie3laLXtnRHnLQlZO3J
2M+pxP7pJvqtgePqmqOIvYLKnACP1fewoXa65/vCov71sdqRnc6OpPvrlcU/benvs7qmzpzR8P/n
rc7imtLntMkhU/V7Hf/yl+fZ6f3HipjL7b+MraKs1h+WXIrU9fNrPv/dkaTIrpQpd/JlIr8kXv/o
ALa3uO0bLwCmUQC68pKSlf/CDgxNosvbKtvb3IzGP8nJyoiJjPaWgH+Ag3Z3euTk5Y3Y+MTfm+3t
7r/AwZubnvBSJQCZ3NLS0//eAwN+yE84la9fmdjkX//RSiPB855BhP/ILiCvY9HeRvLkCvmykSld
q/aNl4Dd+cPT6O85Q2m+Q6zRONnM5OPx0PR3OR2Z2eOttkCr4Lfbm//uQPWMWbeLscPbysbs/OP1
/ZeLwPaLN9blff/iEvXlByCi3nzB69eqvN7r4uzysHfDWSCKzu+Uh8R4pR6j4IVfqm1ucf///yH5
BAEAAH8ALAAAAAByAEUAAAf/gH+Cg4SFhoeIiYqLjI2Oj5CRkpOUlZaXmJmam5ydnp+goaKjpKWm
p6ipqqusra6vsLGys7S1tqF+Oat+freMubu9vorAkkhIlryqBQWXxZBEvD2VyqhEQtPJupJJScnC
pzV+2dTbqdWnSX4BNTWDR+01RIUFSO0/zX/AP+1Mg/x/iLRDku9PO0JH7NXA906hv0Ho/vSId2TQ
xB4Jf1gKwKujoB8deWn8OCTkkIp+gAAJGUBQjnUhgUAEB9Lkx5C58lUr8DLkSHE5Spqb1IMjkh7T
evgZ4o9JyYrR/Mib2FKfHyH4kPBq1rPGkR4lH1ZjsvQH0gDIlA7RSGSlN6uC/zgCmfcjrEFeQuRd
EkeO48g/IN2pQ2boasGV014+/MPRHdw/QsYZUve3wFO4R5YWBOlN3FtMfAetBJKj9EpdEQk9+/My
sWRB4hxXS3koNcdpypRWnXnXMejXf4SWHt4yNcShrVkDjy1o9lDehELnXldIGfNMoV0CJxSZnGrk
kpPDltpc2FZDK+eJlqwsmsx3V3trEvdXK5CKgvKJu59fLHjX5FxXjVz5fHUXEPmAJER5gkQ2UgHq
uHMdJiANkcNIK+WSQ2TraaiZPv8pFyB5jxWwkoUvLWjiVUlkmE01RJQERACRISifJhxR90cBNUTG
YkE1ZAgEYTnsxlgO8wSA5P8/F7pkDo8+AvFgj7wkoR5r5hChzlU1JNjkMGCGKeaYZJZp5pmqsIHA
mmyCkMKbcK4g55wrfGDnnR88oOeedZTh558WBCqoBRgUaigGISSqaAgZNOroHR5EKqkHI1Rq6QKY
ZroADJx2CoMdjxSAQBGkktoCHRekqioBrLZKgBsTxCqrGirUaqsGuOaqgR5B9OprBMAGG8ELxBb7
ggnIJmuCBMw2K4EIRkQb7RkUVGstBQpkq60CazTSRqmlnqrqqq6yCqusstqqrq65+uqusMGiYCyx
HCiLLAfONguttEZQe22122oLQ0GHsAGuqeOSW+656E6grq0bsIuru7/CG4H/vPMea++y+TK7r7T+
/huwtqAiMsXJKE/BBxkst5yHFjDHrAUDNNdMMxU450xFBzz3zLMXQAfthQtjFG30G1UkrXQVEDTt
dNNXRC31FWAcYPXVeFih9dZWsOD11ywAkAgOZJeNwxIVpK22Ezu07fYOTwgg99wCxGD33TE0MMPe
fJNgw9+A26CEDIQXXoIOiCeuQxM0NO44FjxELjkPYPhg+eVf3KD55jcM4PnnA4iNiNllo6122my/
3XbcdMuN9916872334H/PXjhhB+uOOKMO9445JNHXvnllmfOueagfy76IaSTbfrpqavOeuuv2x27
7LTXfjvuuu/eu+/ABz88//HGH5+858sb0vzZp6Ou+uqtu1799X3Xbjvuue/Ou++/By888cU7HvLO
l75CrO95a3sf3OJXt/nJbnb2Exz+ZNA9xX3vcf6jHAB9UD7OnS90Y2seAt33vunRrXp5e+AMshe4
7RlOf4vjHw3CN7nxYU6AnSNgCEk3wgpE720mnBsK6QdB+7kwf/q7YP/8BwcxOPGJC8DhBwtIiAO2
z4cKDKL8XkfEFUbwiBSEoRJpIIcomPGMUbiDIRIgRR2OToRXrEAX5kjHLvSBgUNUIQsBB8YSSOGP
gJRCHGRIA0ewUYBTTAQXFslILswhjoe4Y/zy+EASbOGSmNyCCyYog0OggYeQhgSAKEcJABa40RFm
gKQhThCGVrryAZR84CHSwElPgrISADhlI1J5RUc4IJaym2UtSZHL5FFREbxsny9RuAcHOPOZDjgE
BrJAzWpmoRQLMIA2t7kASCTzdI44ARTGSU4oPABN6EynOtfJzna6853wjKc850nPetrznvjMpz73
yc9++tMUgQAAOw==

--_006_867F4B6A1672E541A94676D556793ACD0C2766DAD4MOPESMBX01eut_
Content-Type: image/gif; name="image003.gif"
Content-Description: image003.gif
Content-Disposition: inline; filename="image003.gif"; size=493;
	creation-date="Tue, 22 Nov 2011 10:22:50 GMT";
	modification-date="Tue, 22 Nov 2011 10:22:50 GMT"
Content-ID: 
Content-Transfer-Encoding: base64

R0lGODlhHAAhAMQAALHNVVqXGZu+IqbFNv79/ury0pK4H2SdaJzAJNjlq/3++vL34srdiSl5Mfj7
8OHrvDmDE5u+Kb3VbtDgm5jCnJC2IqDBJHqqHoazHsfYxcfco+/58f7///7+/v///f///yH5BAAA
AAAALAAAAAAcACEAAAX/4CeOZGmeaKqubOumXSfKL0rT9RiTe65/nl0vxxE1KB3Ph6b8KGYjT/Pn
ORwIHmy0FEQFCZRG5yldJnEqD6ezaWQIHMJDApAwCthgF8hbEqwEBQARAoWFEgskQWgiChwFDRoD
hpQCA3hLQGhxSWABFpQIlAMPT2NoeTIJEBigooavlzJDS0UdHAkBEAivAoSjDklTQAROuBYQn7+/
lBJJS01SUgoJoskWvaECCWUiHEEKtw+8BtegvoWxiYtqSmsLhBblEALn2hLDH3HTAIXYuhfqVeLF
TZ8SR3oSULKAQVeAChYi8kJwCUg4BcVkOOiXDgHDACAvXMBQoWQEOw6iahwsMCmdAI8CKoiciUEA
gAJ8aBC4xfKlz3QRsVGcoICMJidKOjhgMKCXqKcAJqSMIkwEuw8OHjCQwNVOggJPvqm4ZUJGuw47
lajlA0Sat28xyJZV9APasGEcvknBkU9TjJ1WrTZZE9hHihAAOw==

--_006_867F4B6A1672E541A94676D556793ACD0C2766DAD4MOPESMBX01eut_--

From ichiroumakino@gmail.com  Tue Nov 22 02:28:18 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3123221F8CFA for ; Tue, 22 Nov 2011 02:28:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.299
X-Spam-Level: 
X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_FORM=2.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 ZXSA4TJI-7hg for ; Tue, 22 Nov 2011 02:28:17 -0800 (PST)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3D18821F849E for ; Tue, 22 Nov 2011 02:28:02 -0800 (PST)
Received: by bkbzv15 with SMTP id zv15so36502bkb.31 for ; Tue, 22 Nov 2011 02:28:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=hTo2rkxcsRt4VaSy6HYkgEMFcX9tBTHGbtYefubdV4Q=; b=WBIbTBVjFUd8pwhCZEDg3CWyRt54BnTp7EUum5O2xWbhNL0RC5deKm6ua1PB1xDuh/ UuyssVcg4oZVYaUL1vwO3lVhcJxZyWLo57wcMM2XlsL9HdbKq8E1t15fBeXui5dH6pyp juY9Bqc6SvDnNXXG1ebkyRj5yojC0YWQbG8t0=
Received: by 10.204.156.6 with SMTP id u6mr17925572bkw.135.1321957681172; Tue, 22 Nov 2011 02:28:01 -0800 (PST)
Received: from gomlefisk.home ([109.247.65.210]) by mx.google.com with ESMTPS id e18sm9644188bkr.15.2011.11.22.02.27.59 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 22 Nov 2011 02:28:00 -0800 (PST)
Sender: Ole Troan 
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Ole Troan 
In-Reply-To: <00f901cca901$129a5f30$37cf1d90$@iname.com>
Date: Tue, 22 Nov 2011 11:27:58 +0100
Content-Transfer-Encoding: 7bit
Message-Id: <07474555-9D04-481C-855C-BEF095CDF55C@employees.org>
References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com><5B6B2B64C9FE2A489045EEEADDAFF2C30354473D@XMB-RCD-109.cisco.com><4EC455D6.8030601@bogus.com><7EB596BF-B175-40BF-ABC8-326599670B04@apple.com><5B6B2B64C9FE2A489045EEEADDAFF2C303544B88@XMB-RCD-109.cisco.com>	<8D342733-88E6-45D3-B388-E001AE32CD77@employees.org>	<750BF7861EBBE048B3E648B4BB6E8F4F20DC4FEA@crexc50p>  <007801cca8c8$5610aa00$0231fe00$@iname.com>  <00f801cca8fd$784fcdf0$68ef69d0$@iname.com> <418C43A6-5E8A-4CBD-83F4-3C5F502213A1@employees.org> <00f901cca901$129a5f30$37cf1d90$@iname. com>
To: 
X-Mailer: Apple Mail (2.1084)
Cc: IPv6 Operations 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Nov 2011 10:28:18 -0000

Frank,

> The way the rfc6402bis (and others) are written today, is there anything
> that would prevent the CPE from doing an IA_PD upon receiving an RA for
> M=O=0?  If not, I think we've left in a good amount of flexibility for the
> future.

no, nothing would prevent it. nothing demands it either.
we're making it 'undefined'. is that what we really want?
the customer call with; my D-link works just fine, but my Linksys doesn't?

cheers,
Ole


From lorenzo@google.com  Tue Nov 22 02:30:40 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A9AD21F8D46 for ; Tue, 22 Nov 2011 02:30:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.904
X-Spam-Level: 
X-Spam-Status: No, score=-102.904 tagged_above=-999 required=5 tests=[AWL=0.072, 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 CdaRSg3IAYBj for ; Tue, 22 Nov 2011 02:30:39 -0800 (PST)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id C615321F8D25 for ; Tue, 22 Nov 2011 02:30:39 -0800 (PST)
Received: by yenm7 with SMTP id m7so39274yen.31 for ; Tue, 22 Nov 2011 02:30:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=83eizi6t6I6gcQQQHMfGYxIdn1PSZ2T8hPFaknb9MXc=; b=rfA7OnW0hpXjF8bD6sk+xyfQoZE5NyHXTq8m1n3u7b2+bUtGswCC6F7qFVHuU1iP1i /hJ3XUwWZ9TYN5knYWJQ==
Received: by 10.236.181.138 with SMTP id l10mr25398783yhm.36.1321957839384; Tue, 22 Nov 2011 02:30:39 -0800 (PST)
Received: by 10.236.181.138 with SMTP id l10mr25398769yhm.36.1321957839284; Tue, 22 Nov 2011 02:30:39 -0800 (PST)
MIME-Version: 1.0
Received: by 10.150.202.14 with HTTP; Tue, 22 Nov 2011 02:30:18 -0800 (PST)
In-Reply-To: <418C43A6-5E8A-4CBD-83F4-3C5F502213A1@employees.org>
References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com>  <5B6B2B64C9FE2A489045EEEADDAFF2C30354473D@XMB-RCD-109.cisco.com> <4EC455D6.8030601@bogus.com>   <7EB596BF-B175-40BF-ABC8-326599670B04@apple.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303544B88@XMB-RCD-109.cisco.com>    <8D342733-88E6-45D3-B388-E001AE32CD77@employees.org> <750BF7861EBBE048B3E648B4BB6E8F4F20DC4FEA@crexc50p>  <007801cca8c8$5610aa00$0231fe00$@iname.com>  <00f801cca8fd$784fcdf0$68ef69d0$@iname.com> <418C43A6-5E8A-4CBD-83F4-3C5F502213A1@employees.org>
From: Lorenzo Colitti 
Date: Tue, 22 Nov 2011 19:30:18 +0900
Message-ID: 
To: Ole Troan 
Content-Type: multipart/alternative; boundary=20cf30434af06b2a4104b2504bc1
X-System-Of-Record: true
Cc: IPv6 Operations 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Nov 2011 10:30:40 -0000

--20cf30434af06b2a4104b2504bc1
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Nov 22, 2011 at 19:03, Ole Troan  wrote:

> there isn't a use case for an ISP wanting to _only_ do IA_PD?
> as in not DHCP for other configuration information nor for address
> assignment.
>

How can you argue that IA_PD is not other configuration information? You
could argue that a prefix is an address and therefore should be controlled
by M=1 (though I would disagree), but if it's not an address, then I would
say it has to be other configuration information.

I don't think you can say that "other configuration information" means
"other configuration information, but not a prefix".

--20cf30434af06b2a4104b2504bc1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Tue, Nov 22, 2011 at 19:03, Ole Troan <otroan@employees.org=
> wrote:


there isn't a use case for an ISP wanting to _only_ do IA_PD?

as in not DHCP for other configuration information nor for address assignme=
nt.

How can you argue that IA_PD is not=
 other configuration information? You could argue that a prefix is an addre=
ss and therefore should be controlled by M=3D1 (though I would disagree), b=
ut if it's not an address, then I would say it has to be other configur=
ation information.




I don't think you can say that "other configur=
ation information" means "other configuration information, but no=
t a prefix".


--20cf30434af06b2a4104b2504bc1--

From Carl.Wuyts@technicolor.com  Tue Nov 22 02:40:19 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11B8521F8DED for ; Tue, 22 Nov 2011 02:40:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.397
X-Spam-Level: 
X-Spam-Status: No, score=-5.397 tagged_above=-999 required=5 tests=[AWL=0.602,  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 1eptetcormRl for ; Tue, 22 Nov 2011 02:40:18 -0800 (PST)
Received: from na3sys009aog120.obsmtp.com (na3sys009aog120.obsmtp.com [74.125.149.140]) by ietfa.amsl.com (Postfix) with ESMTP id 9F20A21F8DE9 for ; Tue, 22 Nov 2011 02:40:16 -0800 (PST)
Received: from mopesedge02.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob120.postini.com ([74.125.148.12]) with SMTP ID DSNKTst8EJ8aFrK0Z6CB6O62M3C2cV3ICROe@postini.com; Tue, 22 Nov 2011 02:40:18 PST
Received: from MOPESMAILHC01.eu.thmulti.com (141.11.100.25) by mopesedge02.eu.thmulti.com (141.11.253.23) with Microsoft SMTP Server (TLS) id 8.3.192.1; Tue, 22 Nov 2011 11:39:53 +0100
Received: from MOPESMBX01.eu.thmulti.com ([169.254.155.121]) by MOPESMAILHC01.eu.thmulti.com ([141.11.100.25]) with mapi; Tue, 22 Nov 2011 11:40:00 +0100
From: Wuyts Carl 
To: Ole Troan , Frank Bulk 
Date: Tue, 22 Nov 2011 11:40:01 +0100
Thread-Topic: [v6ops] DHCPv6 option for MAX_SOL_RT
Thread-Index: Acyo9UuZNPxE5wcJQiePHy7HjeH03wAAhUqw
Message-ID: <867F4B6A1672E541A94676D556793ACD0C2766DAFC@MOPESMBX01.eu.thmulti.com>
References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com><5B6B2B64C9FE2A489045EEEADDAFF2C30354473D@XMB-RCD-109.cisco.com><4EC455D6.8030601@bogus.com><7EB596BF-B175-40BF-ABC8-326599670B04@apple.com><5B6B2B64C9FE2A489045EEEADDAFF2C303544B88@XMB-RCD-109.cisco.com> <8D342733-88E6-45D3-B388-E001AE32CD77@employees.org> <750BF7861EBBE048B3E648B4BB6E8F4F20DC4FEA@crexc50p>  <007801cca8c8$5610aa00$0231fe00$@iname.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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: IPv6 Operations 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Nov 2011 10:40:19 -0000

As I've pointed out before, we leave it open to our customer, read "isp/tel=
co" to decide what they want to do with this.  If they decide to ignore the=
 flags, and just apply what they've config'd in the DHCPv6 client, then the=
y can do this. =20
When they decide to listen, O-flag set indeed means stateless client, so al=
l options (including ia_pd, which is just an option as any other)

Carl Wuyts
GCD System Architect Networking
CONNECT DIVISION
carl.wuyts@technicolor.com
tel.: +32 3 443 65 90


Prins Boudewijnlaan 47=A0=A0-=A0=A02650 Edegem=A0=A0-=A0=A0Belgium
Technicolor Delivery Technologies Belgium NV
Registered office (maatschappelijke zetel): Prins Boudewijnlaan 47, 2650 Ed=
egem, Belgium
Company registration number (ondernemingsnummer): 0428837295 - RPR Antwerpe=
n

Help preserve the color of our world - Think before you print.





-----Original Message-----
From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of O=
le Troan
Sent: dinsdag 22 november 2011 10:01
To: Frank Bulk
Cc: IPv6 Operations
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT

Frank,

> What's fuzzy?

from Barbara:

>  WPD-4:  The IPv6 CE router MUST always initiate DHCPv6 prefix
>          delegation, regardless of the M and O flags in a received
>          Router Advertisement message.
>=20
> I still think this is a reasonable change.
> It doesn't preclude the previous behavior of doing DHCPv6 IA_PD,=20
> regardless of M/O. It just doesn't mandate it. Now it only mandates it=20
> if M or O=3D1. The current language leaves it up to the vendor (or other
> specs) as to what to do when M=3DO=3D0, or no received RA. Devices=20
> compliant under the old requirement are still compliant under the new req=
uirement.

CPE receives and RA with M=3DO=3D0, what is it supposed to do with regards =
to PD?
left up to the vendor to decide?

cheers,
Ole
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops

From ichiroumakino@gmail.com  Tue Nov 22 02:45:07 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70AB821F8D9E for ; Tue, 22 Nov 2011 02:45:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=1.150,  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 L+dJ0tnIoTz3 for ; Tue, 22 Nov 2011 02:45:07 -0800 (PST)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id A9CA221F8D46 for ; Tue, 22 Nov 2011 02:45:06 -0800 (PST)
Received: by fabs1 with SMTP id s1so287249fab.31 for ; Tue, 22 Nov 2011 02:45:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=QfwyoQpivVJYP5aL67UgDLi35me1SsLOqctvM2JYAaA=; b=yCGqjTwjHd4KKQ2POChz50c2JyXn8Oh1WxSFDsfAwJp8AJBBHDpeuIB4nN5pP3AeXw G6iiCfcv9zF0Nsh25kxnwEvM1MFC6UxzD2Pf313h/UgQZKFIvdJStX4Y91PjknLqdjkC PFo+SC43DnHMLFg0N+hSa+oxrgnYEPDWTU4X4=
Received: by 10.204.130.85 with SMTP id r21mr18121733bks.38.1321958705504; Tue, 22 Nov 2011 02:45:05 -0800 (PST)
Received: from gomlefisk.home ([109.247.65.210]) by mx.google.com with ESMTPS id fa8sm1480655bkc.14.2011.11.22.02.44.56 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 22 Nov 2011 02:45:04 -0800 (PST)
Sender: Ole Troan 
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Ole Troan 
In-Reply-To: 
Date: Tue, 22 Nov 2011 11:44:41 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com>  <5B6B2B64C9FE2A489045EEEADDAFF2C30354473D@XMB-RCD-109.cisco.com> <4EC455D6.8030601@bogus.com>   <7EB596BF-B175-40BF-ABC8-326599670B04@apple.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303544B88@XMB-RCD-109.cisco.com>    <8D342733-88E6-45D3-B388-E001AE32CD77@employees.org> <750BF7861EBBE048B3E648B4BB6E8F4F20DC4FEA@crexc50p>  <007801cca8c8$5610aa00$0231fe00$@iname.com>  <00f801cca8fd$784fcdf0$68ef69d0$@iname.com> <418C43A6-5E8A-4CBD-83F4-3C5F502213A1@employees.org> 
To: Lorenzo Colitti 
X-Mailer: Apple Mail (2.1084)
Cc: IPv6 Operations 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Nov 2011 10:45:07 -0000

Lorenzo,

> On Tue, Nov 22, 2011 at 19:03, Ole Troan  wrote:
> there isn't a use case for an ISP wanting to _only_ do IA_PD?
> as in not DHCP for other configuration information nor for address =
assignment.
>=20
> How can you argue that IA_PD is not other configuration information? =
You could argue that a prefix is an address and therefore should be =
controlled by M=3D1 (though I would disagree), but if it's not an =
address, then I would say it has to be other configuration information.
>=20
> I don't think you can say that "other configuration information" means =
"other configuration information, but not a prefix".

I think I've given umpteen reasons why we shouldn't couple M/O bits with =
PD already.
the O bit means _stateless_ DHCP. PD is stateful. please let's stop =
talking about the M/O bits. we have a solution to the DHCP storm problem =
within DHCP.

cheers,
Ole


From frnkblk@iname.com  Tue Nov 22 03:13:27 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30D4C21F8D17 for ; Tue, 22 Nov 2011 03:13:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.695
X-Spam-Level: 
X-Spam-Status: No, score=-0.695 tagged_above=-999 required=5 tests=[AWL=-0.896, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, MANGLED_FORM=2.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 FqJLGFV3CjZW for ; Tue, 22 Nov 2011 03:13:26 -0800 (PST)
Received: from premieronline.net (mail.premieronline.net [96.31.0.20]) by ietfa.amsl.com (Postfix) with ESMTP id 9010321F8CBC for ; Tue, 22 Nov 2011 03:13:25 -0800 (PST)
X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=199.120.69.4; 
Received: from FRANKBULK (unverified [199.120.69.4])  by premieronline.net (SurgeMail 5.0n) with ESMTP (TLS) id 7043076-1729245 for multiple; Tue, 22 Nov 2011 05:13:18 -0600
From: "Frank Bulk" 
To: "'Ole Troan'" 
References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com><5B6B2B64C9FE2A489045EEEADDAFF2C30354473D@XMB-RCD-109.cisco.com><4EC455D6.8030601@bogus.com><7EB596BF-B175-40BF-ABC8-326599670B04@apple.com><5B6B2B64C9FE2A489045EEEADDAFF2C303544B88@XMB-RCD-109.cisco.com>	<8D342733-88E6-45D3-B388-E001AE32CD77@employees.org>	<750BF7861EBBE048B3E648B4BB6E8F4F20DC4FEA@crexc50p>  <007801cca8c8$5610aa00$0231fe00$@iname.com>  <00f801cca8fd$784fcdf0$68ef69d0$@iname.com> <418C43A6-5E8A-4CBD-83F4-3C5F502213A1@employees.org> <00f901cca901$129a5f30$37cf1d90$@iname. com> <07474555-9D04-48 1C-855C-BEF095CDF55C@employees.org>
In-Reply-To: <07474555-9D04-481C-855C-BEF095CDF55C@employees.org>
Date: Tue, 22 Nov 2011 05:13:18 -0600
Message-ID: <000001cca907$bcf4b240$36de16c0$@iname.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AcypAW13ecP/+8WCQ4SyyoUlXCUyDwABfybA
Content-Language: en-us
X-Authenticated-User: fbulk@premieronline.net 
X-SpamDetect: : 0.000000 
X-Info: aspam skipped due to (g_smite_skip_auth)
X-Encryption: SSL encrypted
X-MyRbl: Color=Unknown (rbl) Age=0 Spam=0 Notspam=0 Stars=0 Good=1 Friend=0 Surbl=0 Catch=0 r=0 ip=199.120.69.4
X-IP-stats: Incoming Last 0, First 987, in=1837, out=0, spam=0 ip=199.120.69.4
Cc: IPv6 Operations 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: frnkblk@iname.com
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Nov 2011 11:13:27 -0000

If a service provider wants his customers to get an IPv6 address then he
should send out an RA with O=1.  The service provider should be implementing
configurations on their PE that, based on the RFCs, will allow most of his
customers to get online.

Frank

-----Original Message-----
From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of Ole Troan
Sent: Tuesday, November 22, 2011 4:28 AM
To: frnkblk@iname.com
Cc: IPv6 Operations; Chris Donley
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT

Frank,

> The way the rfc6402bis (and others) are written today, is there anything
> that would prevent the CPE from doing an IA_PD upon receiving an RA for
> M=O=0?  If not, I think we've left in a good amount of flexibility for the
> future.

no, nothing would prevent it. nothing demands it either.
we're making it 'undefined'. is that what we really want?
the customer call with; my D-link works just fine, but my Linksys doesn't?

cheers,
Ole




From hansliu@gmail.com  Tue Nov 22 03:24:22 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B4D621F8BA0 for ; Tue, 22 Nov 2011 03:24:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.198
X-Spam-Level: 
X-Spam-Status: No, score=-3.198 tagged_above=-999 required=5 tests=[AWL=-0.200, 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 mTTf8YIYqrUm for ; Tue, 22 Nov 2011 03:24:21 -0800 (PST)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 92AD121F8BAB for ; Tue, 22 Nov 2011 03:24:21 -0800 (PST)
Received: by ywt34 with SMTP id 34so46888ywt.31 for ; Tue, 22 Nov 2011 03:24:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dlhjnVEy+QEx1S4AB1TH+XixIofLDUsZ5zKdjatU3AA=; b=ikPxhSY+26Mxqz/usLIYJmq9jEJXb6Tl+brgkxnZcQ63aPBlI0u+0P0hTIh/IU6pJI OxNkzYdwNv6JdDPw2rJTbYg0y+Wivk+0B6Wp+41NZBiPF5gqfH/7qwdoWa90pcSJE2ZA lmT2YiOmpYaiJ+FhQmBW2c4nqiGmhK/tXCKEc=
MIME-Version: 1.0
Received: by 10.50.189.231 with SMTP id gl7mr21043826igc.44.1321961060964; Tue, 22 Nov 2011 03:24:20 -0800 (PST)
Received: by 10.231.172.71 with HTTP; Tue, 22 Nov 2011 03:24:20 -0800 (PST)
In-Reply-To: 
References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com>  <5B6B2B64C9FE2A489045EEEADDAFF2C30354473D@XMB-RCD-109.cisco.com> <4EC455D6.8030601@bogus.com>   <7EB596BF-B175-40BF-ABC8-326599670B04@apple.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303544B88@XMB-RCD-109.cisco.com>    <8D342733-88E6-45D3-B388-E001AE32CD77@employees.org> <750BF7861EBBE048B3E648B4BB6E8F4F20DC4FEA@crexc50p>  <007801cca8c8$5610aa00$0231fe00$@iname.com>   
Date: Tue, 22 Nov 2011 19:24:20 +0800
Message-ID: 
From: Hans Liu 
To: Mark Townsley 
Content-Type: multipart/alternative; boundary=14dae93411517217d804b2510b01
Cc: IPv6 Operations 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Nov 2011 11:24:22 -0000

--14dae93411517217d804b2510b01
Content-Type: text/plain; charset=UTF-8

How about the flow in TR-124i2? Doesn't that suggest a RS and
DHCP-Solicitation in parallel?  That's my problem!

Hans

On Tuesday, November 22, 2011, Mark Townsley  wrote:
> Architectural arguments aside and more to running code, did we not hear
that there is equipment in the field already that *expects* home routers to
give up and send DHCPv6 even with no RA received? I think I have now heard
two cases, from two different vendors, where we have this expectation
today. Couple that with CE that send 3-4 RS and, if no RA received, start
sending DHCPv6 from two different large retail CPE vendors, and I worry
that cat is out of the bag on this one. "Conservative in what you send"
already lost the battle, and "liberal in what you accept" is having to make
up for it this time.
> - Mark
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>
>

-- 
Instead of following the fashion, we lead it through.

--14dae93411517217d804b2510b01
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

How about the flow in TR-124i2? Doesn't that suggest a RS and DHCP-Soli=
citation in parallel? =C2=A0That's my problem!

Hans

On Tu=
esday, November 22, 2011, Mark Townsley <mark@townsley.net> wrote:

> Architectural arguments aside and more to running code, did we not hea=
r that there is equipment in the field already that *expects* home routers =
to give up and send DHCPv6 even with no RA received? I think I have now hea=
rd two cases, from two different vendors, where we have this expectation to=
day. Couple that with CE that send 3-4 RS and, if no RA received, start sen=
ding DHCPv6 from two different large retail CPE vendors, and I worry that c=
at is out of the bag on this one. "Conservative in what you send"=
 already lost the battle, and "liberal in what you accept" is hav=
ing to make up for it this time.=C2=A0

> - Mark=C2=A0
>
> _________________________________________=
______
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

>
>

-- 
Instead of following the fashion, we lead it thr=
ough.


--14dae93411517217d804b2510b01--

From hansliu@gmail.com  Tue Nov 22 03:28:33 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE91221F8DA4 for ; Tue, 22 Nov 2011 03:28:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.47
X-Spam-Level: 
X-Spam-Status: No, score=-3.47 tagged_above=-999 required=5 tests=[AWL=0.128,  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 QiUjdHmg-R5O for ; Tue, 22 Nov 2011 03:28:33 -0800 (PST)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 547AF21F8DA3 for ; Tue, 22 Nov 2011 03:28:33 -0800 (PST)
Received: by ghrr14 with SMTP id r14so52426ghr.31 for ; Tue, 22 Nov 2011 03:28:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cV14wV9DgiugdqWYcWjkxjBZKCuSkreiimI/MWOU4Yo=; b=Dx0uoF0ihKFbIgcpJYgmCVSPzxrFCFuToorDF85Hi0XfILzvGkfZ4GEJC2XbpCwO2r M2GuW9zlrSG3+2I9+sR/fXr4mdt/h7czgj7mkRRypkN07a2ode5wJg96HCv62sMgcctE lEBtfsZyju1CmizwFF5aN1Zu0OP+Octq/nQPQ=
MIME-Version: 1.0
Received: by 10.50.189.231 with SMTP id gl7mr21081964igc.44.1321961312711; Tue, 22 Nov 2011 03:28:32 -0800 (PST)
Received: by 10.231.172.71 with HTTP; Tue, 22 Nov 2011 03:28:32 -0800 (PST)
In-Reply-To: <867F4B6A1672E541A94676D556793ACD0C2766DAFC@MOPESMBX01.eu.thmulti.com>
References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com>  <5B6B2B64C9FE2A489045EEEADDAFF2C30354473D@XMB-RCD-109.cisco.com> <4EC455D6.8030601@bogus.com>   <7EB596BF-B175-40BF-ABC8-326599670B04@apple.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303544B88@XMB-RCD-109.cisco.com>    <8D342733-88E6-45D3-B388-E001AE32CD77@employees.org> <750BF7861EBBE048B3E648B4BB6E8F4F20DC4FEA@crexc50p>  <007801cca8c8$5610aa00$0231fe00$@iname.com>  <867F4B6A1672E541A94676D556793ACD0C2766DAFC@MOPESMBX01.eu.thmulti.com>
Date: Tue, 22 Nov 2011 19:28:32 +0800
Message-ID: 
From: Hans Liu 
To: Wuyts Carl 
Content-Type: multipart/alternative; boundary=14dae934115173753a04b2511afb
Cc: IPv6 Operations 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Nov 2011 11:28:34 -0000

--14dae934115173753a04b2511afb
Content-Type: text/plain; charset=UTF-8

On Tuesday, November 22, 2011, Wuyts Carl 
wrote:
> As I've pointed out before, we leave it open to our customer, read
"isp/telco" to decide what they want to do with this.  If they decide to
ignore the flags, and just apply what they've config'd in the DHCPv6
client, then they can do this.
> When they decide to listen, O-flag set indeed means stateless client, so
all options (including ia_pd, which is just an option as any other)
>

I think we are talking about retail products here. For tender project, of
course we do customizations.

-- 
Instead of following the fashion, we lead it through.

--14dae934115173753a04b2511afb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



On Tuesday, November 22, 2011, Wuyts Carl <Carl.Wuyts@technicolor.com> wrote:
> =
As I've pointed out before, we leave it open to our customer, read &quo=
t;isp/telco" to decide what they want to do with this. =C2=A0If they d=
ecide to ignore the flags, and just apply what they've config'd in =
the DHCPv6 client, then they can do this.

> When they decide to listen, O-flag set indeed means stateless client, =
so all options (including ia_pd, which is just an option as any other)
&=
gt;

I think we are talking about retail products here. For tender pr=
oject, of course we do customizations. 


-- 
Instead of following the fashion, we lead it through.


--14dae934115173753a04b2511afb--

From mark@townsley.net  Tue Nov 22 03:53:59 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58F4E21F8D01 for ; Tue, 22 Nov 2011 03:53:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.158
X-Spam-Level: 
X-Spam-Status: No, score=-3.158 tagged_above=-999 required=5 tests=[AWL=-0.160, 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 Zw-4EUXWNZTB for ; Tue, 22 Nov 2011 03:53:58 -0800 (PST)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8AFD421F8CFC for ; Tue, 22 Nov 2011 03:53:58 -0800 (PST)
Received: by fabs1 with SMTP id s1so364256fab.31 for ; Tue, 22 Nov 2011 03:53:57 -0800 (PST)
Received: by 10.180.103.131 with SMTP id fw3mr18234122wib.57.1321962837622; Tue, 22 Nov 2011 03:53:57 -0800 (PST)
Received: from ams-townsley-8712.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id u3sm3696872wiu.10.2011.11.22.03.53.51 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 22 Nov 2011 03:53:52 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-46-58247092
From: Mark Townsley 
In-Reply-To: 
Date: Tue, 22 Nov 2011 12:53:50 +0100
Message-Id: 
References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com>  <5B6B2B64C9FE2A489045EEEADDAFF2C30354473D@XMB-RCD-109.cisco.com> <4EC455D6.8030601@bogus.com>   <7EB596BF-B175-40BF-ABC8-326599670B04@apple.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303544B88@XMB-RCD-109.cisco.com>    <8D342733-88E6-45D3-B388-E001AE32CD77@employees.org> <750BF7861EBBE048B3E648B4BB6E8F4F20DC4FEA@crexc50p>  <007801cca8c8$5610aa00$0231fe00$@iname.com>  <867F4B6A1672E541A94676D556793ACD0C2766DAFC@MOPESMBX01.eu.thmulti.com> 
To: Hans Liu 
X-Mailer: Apple Mail (2.1084)
Cc: IPv6 Operations 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Nov 2011 11:53:59 -0000

--Apple-Mail-46-58247092
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


Yes, the entire context of 6204 and bis is around setting default =
behavior "out of the box". Of course a user or service provider can =
override whatever they like, but we need to know where square one is.=20

- Mark

On Nov 22, 2011, at 12:28 PM, Hans Liu wrote:

>=20
>=20
> On Tuesday, November 22, 2011, Wuyts Carl  =
wrote:
> > As I've pointed out before, we leave it open to our customer, read =
"isp/telco" to decide what they want to do with this.  If they decide to =
ignore the flags, and just apply what they've config'd in the DHCPv6 =
client, then they can do this.
> > When they decide to listen, O-flag set indeed means stateless =
client, so all options (including ia_pd, which is just an option as any =
other)
> >
>=20
> I think we are talking about retail products here. For tender project, =
of course we do customizations.=20
>=20
> --=20
> Instead of following the fashion, we lead it through.
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


--Apple-Mail-46-58247092
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii



Yes, the entire context of 6204 and bis is around setting default behavior "out of the box". Of course a user or service provider can override whatever they like, but we need to know where square one is. 

- Mark

On Nov 22, 2011, at 12:28 PM, Hans Liu wrote:



On Tuesday, November 22, 2011, Wuyts Carl <Carl.Wuyts@technicolor.com> wrote:
> As I've pointed out before, we leave it open to our customer, read "isp/telco" to decide what they want to do with this.  If they decide to ignore the flags, and just apply what they've config'd in the DHCPv6 client, then they can do this.

> When they decide to listen, O-flag set indeed means stateless client, so all options (including ia_pd, which is just an option as any other)
>

I think we are talking about retail products here. For tender project, of course we do customizations. 


-- 
Instead of following the fashion, we lead it through.

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


--Apple-Mail-46-58247092--

From achatz@forthnetgroup.gr  Tue Nov 22 04:02:08 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 739B721F8D6A for ; Tue, 22 Nov 2011 04:02:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.127
X-Spam-Level: 
X-Spam-Status: No, score=-2.127 tagged_above=-999 required=5 tests=[AWL=-0.128, BAYES_00=-2.599, J_CHICKENPOX_33=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 RIedXHeeAZW2 for ; Tue, 22 Nov 2011 04:02:08 -0800 (PST)
Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.115]) by ietfa.amsl.com (Postfix) with ESMTP id A3B8421F8D61 for ; Tue, 22 Nov 2011 04:02:07 -0800 (PST)
Received: from mx-av-03.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 pAMC259T009244 for ; Tue, 22 Nov 2011 14:02:05 +0200
Received: from MX-IN-04.forthnet.gr (mx-in-04.forthnet.gr [193.92.150.163]) by mx-av-03.forthnet.gr (8.14.3/8.14.3) with ESMTP id pAMC24Po023876 for ; Tue, 22 Nov 2011 14:02:04 +0200
Received: from [192.168.1.2] (194.219.107.39.dsl.dyn.forthnet.gr [194.219.107.39]) (authenticated bits=0) by MX-IN-04.forthnet.gr (8.14.4/8.14.4) with ESMTP id pAMC1t7w008898; Tue, 22 Nov 2011 14:01:55 +0200
Authentication-Results: MX-IN-04.forthnet.gr smtp.mail=achatz@forthnetgroup.gr; auth=pass (PLAIN)
Message-ID: <4ECB8F30.7040000@forthnetgroup.gr>
Date: Tue, 22 Nov 2011 14:01:52 +0200
From: Tassos Chatzithomaoglou 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110928 Firefox/7.0.1 SeaMonkey/2.4.1
MIME-Version: 1.0
To: v6ops@ietf.org
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [v6ops] question about initial connections to DNS servers in draft-ietf-v6ops-happy-eyeballs-05
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Nov 2011 12:02:08 -0000

I'm looking at draft-ietf-v6ops-happy-eyeballs-05 and the following diagrams:



            DNS Server                  Client                  Server
                |                          |                       |
          1.    |<--www.example.com A?-----|                       |
          2.    |<--www.example.com AAAA?--|                       |
          3.    |---192.0.2.1------------->|                       |
          4.    |---2001:db8::1----------->|                       |
          5.    |                          |                       |
          6.    |                          |==TCP SYN, IPv6===>X   |
          7.    |                          |--TCP SYN, IPv4------->|
          8.    |                          |<-TCP SYN+ACK, IPv4----|
          9.    |                          |--TCP ACK, IPv4------->|
         10.    |                          |==TCP SYN, IPv6===>X   |

                Figure 2: Happy Eyeballs flow 1, IPv6 broken

            DNS Server                  Client                  Server
                |                          |                       |
          1.    |<--www.example.com A?-----|                       |
          2.    |<--www.example.com AAAA?--|                       |
          3.    |---192.0.2.1------------->|                       |
          4.    |---2001:db8::1----------->|                       |
          5.    |                          |                       |
          6.    |                          |==TCP SYN, IPv6=======>|
          7.    |                          |--TCP SYN, IPv4------->|
          8.    |                          |<=TCP SYN+ACK, IPv6====|
          9.    |                          |<-TCP SYN+ACK, IPv4----|
         10.    |                          |==TCP ACK, IPv6=======>|
         11.    |                          |--TCP ACK, IPv4------->|
         12.    |                          |--TCP RST, IPv4------->|

                Figure 3: Happy Eyeballs flow 2, IPv6 working


Although steps after 6 are described inside the text, i couldn't get a clear indication about steps 1-4 and most notably about 1-2.
I had a quick look at RFC4472, RFC3484 and draft-ietf-6man-rfc3484-revise-05, but i'm still a little bit confused.

If IPv6 is preferred over IPv4, do we assume the A query (over IPv6 transport) will happen before the AAAA query (over IPv6 transport)?
Do we also assume that the client will have IPv6 connectivity to the IPv6 DNS server?

What i'm actually asking for are details about the steps before HE kicks in dual-stack hosts, when both IPv4/IPv6 DNS servers are available to the client.
Is it like below?

A query to IPv6 DNS server
AAAA query to IPv6 DNS server
A query to IPv4 DNS server
AAAA query to IPv4 DNS server

Do these or some of these happen in parallel, or is the IPv4 DNS server asked only if the IPv6 DNS server doesn't respond?


-- 
Tassos


From jason_livingood@cable.comcast.com  Tue Nov 22 04:40:30 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B17E121F8DD0 for ; Tue, 22 Nov 2011 04:40:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.306
X-Spam-Level: 
X-Spam-Status: No, score=-104.306 tagged_above=-999 required=5 tests=[AWL=-2.571, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 jD3GVue8maYW for ; Tue, 22 Nov 2011 04:40:30 -0800 (PST)
Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id 2F4D321F8D0A for ; Tue, 22 Nov 2011 04:40:30 -0800 (PST)
Received: from ([24.40.55.42]) by copdcimo01.cable.comcast.com with ESMTP  id 5503630.62338266; Tue, 22 Nov 2011 05:39:42 -0700
Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%11]) with mapi id 14.01.0339.001; Tue, 22 Nov 2011 07:39:43 -0500
From: "Livingood, Jason" 
To: Brian E Carpenter , "George, Wes" 
Thread-Topic: [v6ops] Update of draft-ietf-v6ops-v6-aaaa-whitelisting-implications-07
Thread-Index: AQHMinjPwilI7MOZ/0e305KMc5hLZ5V7/bLQgACfJQCAPHXEgA==
Date: Tue, 22 Nov 2011 12:39:18 +0000
Message-ID: 
In-Reply-To: <4E98A810.4000303@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.13.0.110805
x-originating-ip: [147.191.227.196]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] Update of draft-ietf-v6ops-v6-aaaa-whitelisting-implications-07
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Nov 2011 12:40:30 -0000

>
>On 2011-10-15 05:30, George, Wes wrote:
>...
>> I think this document is remiss in not mentioning Happy Eyeballs as
>>another method to prevent end-user impact due to impaired IPv6
>>connectivity.
>
>If that is added, I think a reference to RFC6343 is also appropriate.
>That contains specific advice to content providers about how to
>significantly mitigate one class of problems.

Agree with you both, Brian and Wes. I have added a reference to Happy
Eyeballs and to RFC 6343. This will be coming in the -08 version soon.

Thanks,
Jason


From satoru.matsushima@gmail.com  Tue Nov 22 05:00:44 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1137F21F8D70 for ; Tue, 22 Nov 2011 05:00:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.549
X-Spam-Level: 
X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050,  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 NJvsCNPXuord for ; Tue, 22 Nov 2011 05:00:43 -0800 (PST)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id DA30C21F8DAE for ; Tue, 22 Nov 2011 05:00:42 -0800 (PST)
Received: by ggnp4 with SMTP id p4so196868ggn.31 for ; Tue, 22 Nov 2011 05:00:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=mjqaq17kcL4NU5mXxNLz+Sa0lcHPv84lw+xZFSiGgzU=; b=kHa8jL2JwiZPr4RWqoTGxnndYgGN0YS4lFHpCxc/LFXj+OjiswgtYvq9TcepLiabdt tsNvgUkylagWQuKNWRoPnUHglbTUE80ouCVmrCz3IL3BgBoyUlyKdLS2w2Kem/hS3Sdm 9x/bCT1VCPbwzD8/YrUHA9HjhXfatr2Uce2TA=
Received: by 10.50.170.105 with SMTP id al9mr20985302igc.28.1321966842265; Tue, 22 Nov 2011 05:00:42 -0800 (PST)
Received: from [10.201.82.125] ([202.45.12.141]) by mx.google.com with ESMTPS id mb4sm33814732igc.1.2011.11.22.05.00.38 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 22 Nov 2011 05:00:40 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=windows-1252
From: Satoru Matsushima 
In-Reply-To: <3D4D775D-E926-4F89-B279-75F0FE02B98F@nominum.com>
Date: Tue, 22 Nov 2011 22:00:36 +0900
Content-Transfer-Encoding: quoted-printable
Message-Id: <1DCCCE6C-6B84-40B8-B667-1F22CDDCE1A1@gmail.com>
References: <20111115062859.14026.74743.idtracker@ietfa.amsl.com>  <4ECACFF5.6020804@gmail.com>   <3D4D775D-E926-4F89-B279-75F0FE02B98F@nominum.com>
To: Ted Lemon 
X-Mailer: Apple Mail (2.1251.1)
Cc: "v6ops@ietf.org WG" , Wesley Eddy , Pete Resnick , "" , "ietfdbh@comcast.net Harrington" 
Subject: Re: [v6ops] New Version Notification	- draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-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: Tue, 22 Nov 2011 13:00:44 -0000

On 2011/11/22, at 12:42, Ted Lemon wrote:

> On Nov 21, 2011, at 8:43 PM, Satoru Matsushima wrote:
>> This draft mentions not only which prefix hosts use.
>> Please read the scenarios in the draft.
>=20
> I did, but the third scenario is just a MIF scenario, not a =
multihoming scenario.   It's part of the MIF problem statement.
>=20
>>> Fundamentally, what this draft seems to be saying is "a plurality of =
IPv6 implementations are broken.   Some IPv6 implementations are not =
broken.   Here's how you do multihoming for non-broken hosts without =
causing broken hosts to *completely* fail."   I do not love this =
solution.   The right thing to do is to fix the broken hosts.   I'm =
against changing the IPv6 architecture to deal with this problem.
>>>=20
>>=20
>> This draft doesn't mention implementation specific brokenness.
>> Again, please read the scenarios in the draft.
>=20
> It's true that the draft doesn't call it brokenness, but what it talks =
about _is_ brokenness, whether it's called that or not.
>=20
>> I'm not sure what the IPv6 architecture you assume. We don't say that =
RA is not necessary, but we say DHCPv6 is most realistic to solve =
multihoming issue without any kind of IPv6 NAT. Do you say that without =
changing the IPv6 architecture means IPv6 NAT is the right thing to do?
>=20
> No, that is not my position at all.   My position is that none of the =
scenarios you've described require a DHCPv6 route option to fix.   =
Indeed, the DHCPv6 route option is the wrong solution in all three =
scenarios: it perpetuates brokenness instead of fixing the very real =
problems you've described.

While a customer site is multihoming and operators need to advertise its =
routing information, BGP might be an appropriate solution but it's =
obviously too much. RA with RIO should work, but it's too much to =
configure all hosts individually by RA with the current operational =
experience.=20

>=20
> These are exactly the same problem scenarios that I talked about in my =
presentation in the DHC working group meeting.   There is wide agreement =
that these scenarios are a problem.   The MIF working group was =
chartered to fix at least scenario 3, and scenario 1 is in the problem =
statement as well.   Scenario 2 is the "really ugly problem" I described =
in my presentation in the DHC working group.

Ok, you can see these three scenarios in our draft are in a problem. I =
suppose that you have an idea to solve that without DHCPv6. But I didn't =
attend last dhc meeting so I appreciate if you share your presentation =
since I couldn't find your slides on the ietf web site.

>=20
> These problems are solvable, and I think the MIF working group is =
capable of solving them (although Scenario 2 will require some help from =
6man).   I don't think we should be throwing out wholesale pieces of the =
internet architecture (specifically, RA) to solve this problem.   Or =
perhaps I should say that if we are considering doing that, we should =
admit that that's what we're considering.

I understand that. I don't say that we should be throwing RA out. =
However, I say that route option for DHCPv6 is needed for operator's =
reality.

> I'm agnostic=97it's pretty obvious to me that we can solve this with =
some backwards-compatible changes to RA.  So even though I personally =
would have preferred to use DHCP to solve this entire set of problems, =
since we didn't do that, I think we should just fix RA.
>=20

If it is possible to change RA with backword-compatible, I think that it =
should be nice. Unfortunately, it hasn't been done so far vice versa.=20

cheers,
--satoru=

From jason_livingood@cable.comcast.com  Tue Nov 22 05:09:05 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 813B621F8D31 for ; Tue, 22 Nov 2011 05:09:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.877
X-Spam-Level: 
X-Spam-Status: No, score=-103.877 tagged_above=-999 required=5 tests=[AWL=-2.143, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QP1PHKfM4fOy for ; Tue, 22 Nov 2011 05:09:04 -0800 (PST)
Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id 8951321F8CEC for ; Tue, 22 Nov 2011 05:09:04 -0800 (PST)
Received: from ([24.40.55.41]) by copdcimo01.cable.comcast.com with ESMTP  id 5503630.62340661; Tue, 22 Nov 2011 06:09:23 -0700
Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%11]) with mapi id 14.01.0339.001; Tue, 22 Nov 2011 08:08:59 -0500
From: "Livingood, Jason" 
To: "George, Wes" , "v6ops@ietf.org" 
Thread-Topic: [v6ops] Update of draft-ietf-v6ops-v6-aaaa-whitelisting-implications-07
Thread-Index: AQHMinjPwilI7MOZ/0e305KMc5hLZ5V7/bLQgD0dLQA=
Date: Tue, 22 Nov 2011 13:08:58 +0000
Message-ID: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.13.0.110805
x-originating-ip: [147.191.227.196]
Content-Type: multipart/alternative; boundary="_000_CAF102C543A6Ajasonlivingoodcablecomcastcom_"
MIME-Version: 1.0
Subject: Re: [v6ops] Update of draft-ietf-v6ops-v6-aaaa-whitelisting-implications-07
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Nov 2011 13:09:05 -0000

--_000_CAF102C543A6Ajasonlivingoodcablecomcastcom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Thanks for the feedback, Wes. See comments inline below. This will all be i=
n a =9608 shortly.

- Jason

On 10/14/11 12:30 PM, "George, Wes" > wrote:

Section 4 =96 I=92m not sure I=92d call these =93transition techniques=94 =
=96 they are really more methods to resolve or reduce the risk of impaired =
IPv6 connectivity. Transition techniques is unfortunately a pretty overload=
ed term right now, but usually refers to methods to enable IPv6 capability,=
 especially in the case where one or more elements in the path don=92t prop=
erly support IPv6, rather than to manage impairment, and I think this will =
cause confusion.

Ack. Changed to "Potential Migration Tactics".

4.2/5.2 =96 might call these protocol (or address-family)-specific FQDNS in=
stead of IPv6 transition names. Again, transition is sort of an overloaded =
term.

Ack. Changed in the text to use 'address-family-specific names' and in the =
title as using 'IPv6-Specific Names'.

I think this document is remiss in not mentioning Happy Eyeballs as another=
 method to prevent end-user impact due to impaired IPv6 connectivity.

Ack. This reference has been added.

4.4 =96 you say =93It is unclear
   when and if it may be appropriate for a domain to change from
   whitelisting to blacklisting.  Nor is it clear how implementers will
   judge the network conditions to have changed sufficiently to justify
   disabling such controls.=94
I=92m concerned with leaving it at that. This is a good place to put in a w=
arning that these, especially whitelists, should not be considered an open-=
ended deployment, and that before deploying blacklist/whitelist, content pr=
oviders/domain owners should have concrete criteria and means for consisten=
tly (if not continuously) testing those criteria so that it is clear when t=
he risk of impairment has dropped below their threshold and this can be rem=
oved. In other words, I would like us to say =93black/whitelisting shouldn=
=92t be used for longer than is necessary=94 while still acknowledging that=
 everyone has a slightly different value of necessary.

I understand your concern and have previously attempted more direct languag=
e on the duration of these migration tactics. But ultimately the WG, especi=
ally in consultation with implementers, was not able to reach consensus on =
anything beyond the text in 4.4. I am comfortable with it as-is with the co=
nsensus position.

Thanks
Jason



--_000_CAF102C543A6Ajasonlivingoodcablecomcastcom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: 
Content-Transfer-Encoding: quoted-printable











Thanks for the feedback, Wes. See comments inline below. This will all=
 be in a =9608 shortly.













- Jason











On 10/14/11 12:30 PM, "George, Wes" <wesley.george@twcable.com> wrote:




















Sectio=
n 4 =96 I=92m not sure I=92d call these =93transition techniques=94 =96 the=
y are really more methods to resolve or reduce the risk of impaired IPv6 co=
nnectivity. Transition techniques is unfortunately
 a pretty overloaded term right now, but usually refers to methods to enabl=
e IPv6 capability, especially in the case where one or more elements in the=
 path don=92t properly support IPv6, rather than to manage impairment, and =
I think this will cause confusion.
















Ack. Changed to "=
;Potential Migration Tactics". 

















4.2/5.2 =96 might call these protocol (or address-family)-specific FQDNS i=
nstead of IPv6 transition names. Again, transition is sort of an overloaded=
 term.
















Ack. Changed in the t=
ext to use 'address-family-specific names' and in the title as using 'IPv6-=
Specific Names'.





















I thin=
k this document is remiss in not mentioning Happy Eyeballs as another metho=
d to prevent end-user impact due to impaired IPv6 connectivity.

















Ack. This reference has been added.
















<=
span style=3D"color: rgb(31, 73, 125); font-family: Calibri, sans-serif; ">=
4.4 =96 you say =93It
 is unclear




















   when and if it may be appropriate for a=
 domain to change from



   whitelisting to blacklisting.  Nor=
 is it clear how implementers will



   judge the network conditions to have ch=
anged sufficiently to justify=




   disabling such controls.=94



I=92m concerned with leaving it at that. This is a good place to put in a =
warning that these, especially whitelists, should not be considered an open=
-ended deployment, and that before deploying
 blacklist/whitelist, content providers/domain owners should have concrete =
criteria and means for consistently (if not continuously) testing those cri=
teria so that it is clear when the risk of impairment has dropped below the=
ir threshold and this can be removed.
 In other words, I would like us to say =93black/whitelisting shouldn=92t b=
e used for longer than is necessary=94 while still acknowledging that every=
one has a slightly different value of necessary.
















I understand your concern and have previously attempted more direct la=
nguage on the duration of these migration tactics. But ultimately the WG, e=
specially in consultation with implementers, was not able to reach consensu=
s on anything beyond the text in
 4.4. I am comfortable with it as-is with the consensus position.







Thanks


Jason














--_000_CAF102C543A6Ajasonlivingoodcablecomcastcom_--

From jason_livingood@cable.comcast.com  Tue Nov 22 05:23:38 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B88DB21F8DD5 for ; Tue, 22 Nov 2011 05:23:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.935
X-Spam-Level: 
X-Spam-Status: No, score=-106.935 tagged_above=-999 required=5 tests=[AWL=1.527, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, 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 BosoCTDBho86 for ; Tue, 22 Nov 2011 05:23:38 -0800 (PST)
Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id 0957621F8DD3 for ; Tue, 22 Nov 2011 05:23:37 -0800 (PST)
Received: from ([24.40.55.42]) by pacdcimo01.cable.comcast.com with ESMTP  id 5503620.146902173; Tue, 22 Nov 2011 08:23:34 -0500
Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%11]) with mapi id 14.01.0339.001; Tue, 22 Nov 2011 08:23:59 -0500
From: "Livingood, Jason" 
To: Lorenzo Colitti , "George, Wes" 
Thread-Topic: [v6ops] Update of draft-ietf-v6ops-v6-aaaa-whitelisting-implications-07
Thread-Index: AQHMinjPwilI7MOZ/0e305KMc5hLZ5V7/bLQgABr64CAPLVZAA==
Date: Tue, 22 Nov 2011 13:23:34 +0000
Message-ID: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.13.0.110805
x-originating-ip: [147.191.227.196]
Content-Type: multipart/alternative; boundary="_000_CAF1084B43AA5jasonlivingoodcablecomcastcom_"
MIME-Version: 1.0
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] Update of draft-ietf-v6ops-v6-aaaa-whitelisting-implications-07
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Nov 2011 13:23:38 -0000

--_000_CAF1084B43AA5jasonlivingoodcablecomcastcom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Thanks for the feedback, Lorenzo. All of this will be factored into the =96=
08 update shortly. Specific responses inline below.

- Jason


On 10/14/11 2:19 PM, "Lorenzo Colitti" > wrote:

Agreed, the draft should mention happy eyeballs.

Ack. Done in the next version.

Actually, I think you=92re missing an opportunity to clarify that in the ca=
ses where whitelisting is being done, the onus is on the domain doing the w=
hitelisting to ensure that the servers being whitelisted represent a networ=
k that has proven to their satisfaction that they are IPv6-ready and this w=
ill not create unacceptable risk of poor service to the downstream users of=
 the whitelisted server.

Yes, the draft doesn't say anything about how to measure this.

Sounds fine. Added a bit of text to address this in 4.3.
- JL

--_000_CAF1084B43AA5jasonlivingoodcablecomcastcom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <4041A27F43EC824C81CED97FE439FA2C@cable.comcast.com>
Content-Transfer-Encoding: quoted-printable













Thanks for the feedback, Lorenzo. All of this will be factored into th=
e =9608 update shortly. Specific responses inline below.







- Jason





























On 10/14/11 2:19 PM, "Lorenzo Colitti" <lorenzo@google.com> wrote:













Agreed, the draft should mention happy eyeballs.












Ack. Done in the next=
 version.












Actually, =
I think you=92re missing an opportunity to clarify that in the cases where =
whitelisting is being done, the onus is
 on the domain doing the whitelisting to ensure that the servers being whit=
elisted represent a network that has proven to their satisfaction that they=
 are IPv6-ready and this will not create unacceptable risk of poor service =
to the downstream users of the whitelisted
 server.







Yes, the draft doesn'=
t say anything about how to measure this.












Sounds fine. Added a =
bit of text to address this in 4.3.









-=
 JL











--_000_CAF1084B43AA5jasonlivingoodcablecomcastcom_--

From gert@space.net  Tue Nov 22 05:36:15 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 487E521F8CD9 for ; Tue, 22 Nov 2011 05:36:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 9I1aC1Asrlfw for ; Tue, 22 Nov 2011 05:36:14 -0800 (PST)
Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id A7F9721F8CBC for ; Tue, 22 Nov 2011 05:36:13 -0800 (PST)
Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 9367AF8973 for ; Tue, 22 Nov 2011 14:36:12 +0100 (CET)
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 7F5C3F8968 for ; Tue, 22 Nov 2011 14:36:12 +0100 (CET)
Received: (qmail 14523 invoked by uid 1007); 22 Nov 2011 14:36:12 +0100
Date: Tue, 22 Nov 2011 14:36:12 +0100
From: Gert Doering 
To: Lorenzo Colitti 
Message-ID: <20111122133612.GH71280@Space.Net>
References:   <68DAB112-6E32-45FE-9AB7-A34E64898F60@cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30354436E@XMB-RCD-109.cisco.com> <750BF7861EBBE048B3E648B4BB6E8F4F20DC41F6@crexc50p>  <252D3DEA-FF09-42C8-959E-8A7205D9DE67@townsley.net> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-NCC-RegID: de.space
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Claire Cheng , v6ops@ietf.org, Alexandre Cassen 
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Nov 2011 13:36:15 -0000

Hi,

On Tue, Nov 22, 2011 at 06:34:15PM +0900, Lorenzo Colitti wrote:
> If you want to support 6rd service being provided by a different ISP than
> native IPv6 service you may have to deal with ingress filtering issues. 

Even if it's the same ISP, it's two different machineries that terminate
6rd and "native", and neither might have knowledge about "the other" prefix.

So if "straightforward" BCP38 filtering is used, I'd expect this to drop
packets arriving over the "wrong" technology.

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 mark@townsley.net  Tue Nov 22 06:44:10 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31F7021F8DB8 for ; Tue, 22 Nov 2011 06:44:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.449
X-Spam-Level: 
X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D3IEorkA61Ph for ; Tue, 22 Nov 2011 06:44:09 -0800 (PST)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6734F21F8CA5 for ; Tue, 22 Nov 2011 06:44:03 -0800 (PST)
Received: by wwe5 with SMTP id 5so299304wwe.13 for ; Tue, 22 Nov 2011 06:44:02 -0800 (PST)
Received: by 10.216.30.206 with SMTP id k56mr2753873wea.98.1321973042323; Tue, 22 Nov 2011 06:44:02 -0800 (PST)
Received: from ams-townsley-8712.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id ca18sm6777529wib.13.2011.11.22.06.43.59 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 22 Nov 2011 06:44:00 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Mark Townsley 
In-Reply-To: <20111122133612.GH71280@Space.Net>
Date: Tue, 22 Nov 2011 15:43:58 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:   <68DAB112-6E32-45FE-9AB7-A34E64898F60@cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30354436E@XMB-RCD-109.cisco.com> <750BF7861EBBE048B3E648B4BB6E8F4F20DC41F6@crexc50p>  <252D3DEA-FF09-42C8-959E-8A7205D9DE67@townsley.net>  <20111122133612.GH71280@Space.Net>
To: Gert Doering 
X-Mailer: Apple Mail (2.1084)
Cc: Alexandre Cassen , Claire Cheng , v6ops@ietf.org
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Nov 2011 14:44:10 -0000

On Nov 22, 2011, at 2:36 PM, Gert Doering wrote:

> Hi,
>=20
> On Tue, Nov 22, 2011 at 06:34:15PM +0900, Lorenzo Colitti wrote:
>> If you want to support 6rd service being provided by a different ISP =
than
>> native IPv6 service you may have to deal with ingress filtering =
issues.=20
>=20
> Even if it's the same ISP, it's two different machineries that =
terminate
> 6rd and "native", and neither might have knowledge about "the other" =
prefix.
>=20
> So if "straightforward" BCP38 filtering is used, I'd expect this to =
drop
> packets arriving over the "wrong" technology.

The 6rd BR would drop traffic that didn't have a matching IPv4 and =
IPv6-mapped source address as well. So, traffic from a Native Prefix =
source isn't going to get far after reaching the end of the tunnel =
unless there is a way to configure an exception to the 6rd source =
mapping check. Assuming that is even possible, now you have introduced a =
spoofing security issue that you probably didn't want to have, or a ton =
of state if you try to do this per-site.=20

At its base, 6rd + native with two separate prefixes ends up looking a =
lot like regular multihoming. It's one reason why, after Alexandre and I =
walked through the various implications, thought that the "single =
prefix" mode had value for an operator (not to mention the user not =
having to live through a renumbering event) .=20

I'm beginning to think that in the separate prefix mode the CE is going =
to have to be able to do source routing to the two interfaces. The only =
alternatives are dropping traffic, rebooting the entire home, or getting =
liberal in your source address checks in the network. To Lorenzo's =
point, the CE might "get it wrong" just like it might steer packets the =
wrong way over two native interfaces. With 6rd + native the ISP has the =
opportunity to say "well, OK, these are all from my users, I'll let it =
pass" but it may not be easy to do that without a fairly serious =
relaxation of security policy....

- Mark

>=20
> Gert Doering
>        -- NetMaster
> --=20
> have you enabled IPv6 on something today...?
>=20
> 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 marc.blanchet@viagenie.ca  Tue Nov 22 06:52:01 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 107AC21F8E44 for ; Tue, 22 Nov 2011 06:52:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.189
X-Spam-Level: 
X-Spam-Status: No, score=-102.189 tagged_above=-999 required=5 tests=[AWL=-0.190, 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 V1Hz5gGgsgOi for ; Tue, 22 Nov 2011 06:52:00 -0800 (PST)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id 3759B21F8E43 for ; Tue, 22 Nov 2011 06:52:00 -0800 (PST)
Received: from h109.viagenie.ca (h109.viagenie.ca [206.123.31.109]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 5DC6E20D35; Tue, 22 Nov 2011 09:51:29 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=iso-8859-1
From: Marc Blanchet 
In-Reply-To: 
Date: Tue, 22 Nov 2011 09:51:28 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <8CA3E7F0-6A9C-45A1-955D-48D198178A44@viagenie.ca>
References:   <68DAB112-6E32-45FE-9AB7-A34E64898F60@cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30354436E@XMB-RCD-109.cisco.com> <750BF7861EBBE048B3E648B4BB6E8F4F20DC41F6@crexc50p>  <252D3DEA-FF09-42C8-959E-8A7205D9DE67@townsley.net>  <20111122133612.GH71280@Space.Net> 
To: Mark Townsley 
X-Mailer: Apple Mail (2.1251.1)
Cc: Alexandre Cassen , v6ops@ietf.org, Claire Cheng 
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Nov 2011 14:52:01 -0000

Le 2011-11-22 =E0 09:43, Mark Townsley a =E9crit :

>=20
> On Nov 22, 2011, at 2:36 PM, Gert Doering wrote:
>=20
>> Hi,
>>=20
>> On Tue, Nov 22, 2011 at 06:34:15PM +0900, Lorenzo Colitti wrote:
>>> If you want to support 6rd service being provided by a different ISP =
than
>>> native IPv6 service you may have to deal with ingress filtering =
issues.=20
>>=20
>> Even if it's the same ISP, it's two different machineries that =
terminate
>> 6rd and "native", and neither might have knowledge about "the other" =
prefix.
>>=20
>> So if "straightforward" BCP38 filtering is used, I'd expect this to =
drop
>> packets arriving over the "wrong" technology.
>=20
> The 6rd BR would drop traffic that didn't have a matching IPv4 and =
IPv6-mapped source address as well. So, traffic from a Native Prefix =
source isn't going to get far after reaching the end of the tunnel =
unless there is a way to configure an exception to the 6rd source =
mapping check. Assuming that is even possible, now you have introduced a =
spoofing security issue that you probably didn't want to have, or a ton =
of state if you try to do this per-site.=20
>=20
> At its base, 6rd + native with two separate prefixes ends up looking a =
lot like regular multihoming. It's one reason why, after Alexandre and I =
walked through the various implications, thought that the "single =
prefix" mode had value for an operator (not to mention the user not =
having to live through a renumbering event) .=20
>=20
> I'm beginning to think that in the separate prefix mode the CE is =
going to have to be able to do source routing to the two interfaces.

I think that (source routing) is the only way to do it right.

Marc.


> The only alternatives are dropping traffic, rebooting the entire home, =
or getting liberal in your source address checks in the network. To =
Lorenzo's point, the CE might "get it wrong" just like it might steer =
packets the wrong way over two native interfaces. With 6rd + native the =
ISP has the opportunity to say "well, OK, these are all from my users, =
I'll let it pass" but it may not be easy to do that without a fairly =
serious relaxation of security policy....
>=20
> - Mark
>=20
>>=20
>> Gert Doering
>>       -- NetMaster
>> --=20
>> have you enabled IPv6 on something today...?
>>=20
>> 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
>=20
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


From pch-b29AA871B@u-1.phicoh.com  Tue Nov 22 07:06:15 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BBE321F8E4F for ; Tue, 22 Nov 2011 07:06:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.499
X-Spam-Level: 
X-Spam-Status: No, score=-7.499 tagged_above=-999 required=5 tests=[AWL=-0.900, 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 dExTldsQFRc7 for ; Tue, 22 Nov 2011 07:06:14 -0800 (PST)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 3E3B821F8E51 for ; Tue, 22 Nov 2011 07:06:14 -0800 (PST)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #76) id m1RSrvF-0001iZC; Tue, 22 Nov 2011 16:06:09 +0100
Message-Id: 
To: v6ops@ietf.org
From: Philip Homburg 
Sender: pch-b29AA871B@u-1.phicoh.com
Date: Tue, 22 Nov 2011 16:06:04 +0100
Subject: [v6ops] Routers forwarding packet with link local source
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Nov 2011 15:06:15 -0000

Looking at some traceroute output, I found a link local address. This is 
rather surprising given that RFC-4291 (Internet Protocol Version 6 (IPv6)
Addressing Architecture) says:

"2.5.6. Link-Local IPv6 Unicast Addresses
[...]
"Routers must not forward any packets with Link-Local source or
"destination addresses to other links.

The surprising thing is that the router that originates the packet is about
9 hops away from me.

Are router vendors deliberately ignoring this requirement? 



From bs7652@att.com  Tue Nov 22 07:11:47 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B74221F8E4B for ; Tue, 22 Nov 2011 07:11:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.434
X-Spam-Level: 
X-Spam-Status: No, score=-106.434 tagged_above=-999 required=5 tests=[AWL=0.165, 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 UbhNAkGst6-1 for ; Tue, 22 Nov 2011 07:11:46 -0800 (PST)
Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id 3AAB821F8E1B for ; Tue, 22 Nov 2011 07:11:46 -0800 (PST)
X-Env-Sender: bs7652@att.com
X-Msg-Ref: server-11.tower-119.messagelabs.com!1321974704!2311864!1
X-Originating-IP: [144.160.20.146]
X-StarScan-Version: 6.3.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 2018 invoked from network); 22 Nov 2011 15:11:44 -0000
Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-11.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 22 Nov 2011 15:11:44 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pAMFAH77005680; Tue, 22 Nov 2011 10:10:18 -0500
Received: from 01AL10015010627.AD.BLS.COM (sfldmibbcraeninet1.pmtr.mwst.att.com [10.231.16.33]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pAMF7fRr001429; Tue, 22 Nov 2011 10:10:13 -0500
Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01AL10015010627.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 22 Nov 2011 09:10:00 -0600
Received: from 01NC27689010650.AD.BLS.COM ([90.144.44.120]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 22 Nov 2011 10:10:00 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 22 Nov 2011 10:10:47 -0500
Message-ID: <750BF7861EBBE048B3E648B4BB6E8F4F20EA1037@crexc50p>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] DHCPv6 option for MAX_SOL_RT
Thread-Index: Acyo9R9CmN/xJjLbQAOhPBdVx/XREgAKzqcw
References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com><5B6B2B64C9FE2A489045EEEADDAFF2C30354473D@XMB-RCD-109.cisco.com><4EC455D6.8030601@bogus.com><7EB596BF-B175-40BF-ABC8-326599670B04@apple.com><5B6B2B64C9FE2A489045EEEADDAFF2C303544B88@XMB-RCD-109.cisco.com>	<8D342733-88E6-45D3-B388-E001AE32CD77@employees.org>	<750BF7861EBBE048B3E648B4BB6E8F4F20DC4FEA@crexc50p><007801cca8c8$5610aa00$0231fe00$@iname.com> 
From: "STARK, BARBARA H" 
To: "Ole Troan" , "Frank Bulk" 
X-OriginalArrivalTime: 22 Nov 2011 15:10:00.0002 (UTC) FILETIME=[CD98A220:01CCA928]
Cc: IPv6 Operations 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Nov 2011 15:11:47 -0000

> CPE receives and RA with M=3DO=3D0, what is it supposed to do with =
regards
> to PD?
> left up to the vendor to decide?

Yes. Left up to the vendor and other specs.
Basically, we're saying (with the proposed new language) that M=3DO=3D0 =
will
not produce predictable results from a "6204bis" CE router. M=3DO=3D0
becomes a "don't care" state in "6204bis" CE routers. "Don't care"
states are a perfectly valid and ok, IMO. So long as we have states
defined that do allow us to achieve desired predictable behavior.

Previously (under the original 6204 requirement) the access network
could be sure that a CE router would do DHCPv6 Solicit whenever it
received an RA. Under the new proposed requirement, the access network
can only be sure of the Solicit if it sets M=3D1 or O=3D1. Since I'm not
aware of any access network provider who was planning on setting =
M=3DO=3D0
in the RA while operating a DHCPv6 server that was ready and waiting for
any and all Solicits, this doesn't create a hardship on access networks.
Even with the existing 6204 requirement, there was enough unease among
the access network guys (because of M/O history) as to whether the CE
routers would really do DHCPv6 if M=3DO=3D0, that they figured it was =
best
to always set one, the other, or both. It wasn't going to hurt anything,
and better safe than sorry. After all, there's nothing that says an
access network can't set M=3DO=3D1 and then only offer IA_PD. I haven't =
seen
anything that tells a device to go belly-up if it doesn't get offers
consistent with what it thinks M/O "promised". A provider could easily
do just IA_PD and set M=3DO=3D1, M=3D1/O=3D0, or M=3D0/O=3D1 and expect =
things to
work. According to either the current 6204 or the proposed 6204bis.
Please don't suggest that these bits can only be set if they are an
accurate representation of what is being offered. There's nothing
anywhere that says that.

So the access network still has a way to achieve the desired predictable
behavior. And the defined way is consistent with what the network
providers were planning on doing anyway.

Note that under the existing 6204 requirements, we already have some
"don't care" states defined. For example, if no RA is sent by the access
network, it cannot be predicted whether or not the "6204" CE router will
send a Solicit, anyway. This "don't care" (aka "fuzzy") state continues
to exist in the new 6204bis. So long as we have a well-defined way to
achieve the desired result, it's perfectly acceptable to have states
that produce unpredictable results.
Barbara



From wbeebee@cisco.com  Tue Nov 22 07:15:18 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 155CA21F8E6A for ; Tue, 22 Nov 2011 07:15:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.019
X-Spam-Level: 
X-Spam-Status: No, score=-3.019 tagged_above=-999 required=5 tests=[AWL=-0.787, BAYES_00=-2.599, MANGLED_FORM=2.3, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KKEE-WK4iPYe for ; Tue, 22 Nov 2011 07:15:17 -0800 (PST)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 88F4E21F8E65 for ; Tue, 22 Nov 2011 07:15:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wbeebee@cisco.com; l=591; q=dns/txt; s=iport; t=1321974917; x=1323184517; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=UfihSmhOYNlZhX+l15dmVZYGPfbhpEz4Jc5wMjlhldw=; b=KA5gHkMXXmOVrFevCsdWRJs1X8PcN6N6rHCNLs0LpuE/nr5x4tL4w7Si vrkwd6iybXlIL3DjHNdD6AMMVxfUhpl3tWj1qtVPF2VzBZ55CMDvlZpyK UzfwP6k3S3uD/YOf8aRQRD1SvEpp3md6q7TijC2dIDj/BSBeuNUmqySnn A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AnEGAH+7y06tJXHB/2dsb2JhbABDiUmhBAKBBYFyAQEBAwESAScCATwSAQgOgQ8BAQQBDSeHY5YoAZ5aimIEiByMJ4VIgzyEcYQx
X-IronPort-AV: E=Sophos;i="4.69,553,1315180800"; d="scan'208";a="38195563"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-1.cisco.com with ESMTP; 22 Nov 2011 15:15:17 +0000
Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id pAMFFHmu005059;  Tue, 22 Nov 2011 15:15:17 GMT
Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 22 Nov 2011 09:15:17 -0600
Received: from 161.44.175.128 ([161.44.175.128]) by XMB-RCD-201.cisco.com ([72.163.62.208]) with Microsoft Exchange Server HTTP-DAV ;  Tue, 22 Nov 2011 15:15:16 +0000
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Tue, 22 Nov 2011 10:15:06 -0500
From: Wes Beebee 
To: Ole Troan , 
Message-ID: 
Thread-Topic: [v6ops] DHCPv6 option for MAX_SOL_RT
Thread-Index: AcypKYP8/QJDmZSaNECwLv87MF9Syw==
In-Reply-To: <07474555-9D04-481C-855C-BEF095CDF55C@employees.org>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 22 Nov 2011 15:15:17.0190 (UTC) FILETIME=[8AA7AE60:01CCA929]
Cc: IPv6 Operations 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Nov 2011 15:15:18 -0000

>> The way the rfc6402bis (and others) are written today, is there anything
>> that would prevent the CPE from doing an IA_PD upon receiving an RA for
>> M=O=0?  If not, I think we've left in a good amount of flexibility for the
>> future.
> 
> no, nothing would prevent it. nothing demands it either.
> we're making it 'undefined'. is that what we really want?

Ole - 

We're allowing enough flexibility for BBF and CableLabs to do different
things with M=O=0 in their environments and still claim compliance with RFC
6204bis.  You would get rid of their flexibility?

- Wes


From ichiroumakino@gmail.com  Tue Nov 22 07:16:30 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF13F1F0C40 for ; Tue, 22 Nov 2011 07:16:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level: 
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 kYLbgyS+YIBD for ; Tue, 22 Nov 2011 07:16:30 -0800 (PST)
Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 971D31F0C38 for ; Tue, 22 Nov 2011 07:16:29 -0800 (PST)
Received: by eyg24 with SMTP id 24so311723eyg.31 for ; Tue, 22 Nov 2011 07:16:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=U7TGxWiFURUyU4tkrqgmZlM/qO9A/DySHxl3rJ5o8pk=; b=JjT6daAu3/Tfy+pmVbSQlhfyrbB+OjnO6gi9BCyQzGS+9ciBTEMubR5EfMU/3ovh7C ldFkc0eSmtZiu6ej5UObBUmHQkucp7FxxJVFVrxgIM/6BPb4oMIaJmPOVuoWZphIbHlH G+Mna7gsT+ZJF3IngJw7f5rajOY8KxMb1m1Mo=
MIME-Version: 1.0
Received: by 10.213.26.81 with SMTP id d17mr1004138ebc.47.1321974987354; Tue, 22 Nov 2011 07:16:27 -0800 (PST)
Sender: ichiroumakino@gmail.com
Received: by 10.213.105.195 with HTTP; Tue, 22 Nov 2011 07:16:27 -0800 (PST)
In-Reply-To: <750BF7861EBBE048B3E648B4BB6E8F4F20EA1037@crexc50p>
References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com>  <5B6B2B64C9FE2A489045EEEADDAFF2C30354473D@XMB-RCD-109.cisco.com> <4EC455D6.8030601@bogus.com>   <7EB596BF-B175-40BF-ABC8-326599670B04@apple.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303544B88@XMB-RCD-109.cisco.com>    <8D342733-88E6-45D3-B388-E001AE32CD77@employees.org> <750BF7861EBBE048B3E648B4BB6E8F4F20DC4FEA@crexc50p>  <007801cca8c8$5610aa00$0231fe00$@iname.com>  <750BF7861EBBE048B3E648B4BB6E8F4F20EA1037@crexc50p>
Date: Tue, 22 Nov 2011 15:16:27 +0000
X-Google-Sender-Auth: Alf_A764tFyOI6WHtP_dkk2rE7w
Message-ID: 
From: Ole Troan 
To: "STARK, BARBARA H" 
Content-Type: multipart/alternative; boundary=0015174bdca88600d604b25449bc
Cc: IPv6 Operations 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Nov 2011 15:16:31 -0000

--0015174bdca88600d604b25449bc
Content-Type: text/plain; charset=ISO-8859-1

Barbara,

Fully with you on the analysis. What I don't get is what we are trying to
achieve with this change?

Cheers
Ole

On Tuesday, November 22, 2011, STARK, BARBARA H  wrote:
>> CPE receives and RA with M=O=0, what is it supposed to do with regards
>> to PD?
>> left up to the vendor to decide?
>
> Yes. Left up to the vendor and other specs.
> Basically, we're saying (with the proposed new language) that M=O=0 will
> not produce predictable results from a "6204bis" CE router. M=O=0
> becomes a "don't care" state in "6204bis" CE routers. "Don't care"
> states are a perfectly valid and ok, IMO. So long as we have states
> defined that do allow us to achieve desired predictable behavior.
>
> Previously (under the original 6204 requirement) the access network
> could be sure that a CE router would do DHCPv6 Solicit whenever it
> received an RA. Under the new proposed requirement, the access network
> can only be sure of the Solicit if it sets M=1 or O=1. Since I'm not
> aware of any access network provider who was planning on setting M=O=0
> in the RA while operating a DHCPv6 server that was ready and waiting for
> any and all Solicits, this doesn't create a hardship on access networks.
> Even with the existing 6204 requirement, there was enough unease among
> the access network guys (because of M/O history) as to whether the CE
> routers would really do DHCPv6 if M=O=0, that they figured it was best
> to always set one, the other, or both. It wasn't going to hurt anything,
> and better safe than sorry. After all, there's nothing that says an
> access network can't set M=O=1 and then only offer IA_PD. I haven't seen
> anything that tells a device to go belly-up if it doesn't get offers
> consistent with what it thinks M/O "promised". A provider could easily
> do just IA_PD and set M=O=1, M=1/O=0, or M=0/O=1 and expect things to
> work. According to either the current 6204 or the proposed 6204bis.
> Please don't suggest that these bits can only be set if they are an
> accurate representation of what is being offered. There's nothing
> anywhere that says that.
>
> So the access network still has a way to achieve the desired predictable
> behavior. And the defined way is consistent with what the network
> providers were planning on doing anyway.
>
> Note that under the existing 6204 requirements, we already have some
> "don't care" states defined. For example, if no RA is sent by the access
> network, it cannot be predicted whether or not the "6204" CE router will
> send a Solicit, anyway. This "don't care" (aka "fuzzy") state continues
> to exist in the new 6204bis. So long as we have a well-defined way to
> achieve the desired result, it's perfectly acceptable to have states
> that produce unpredictable results.
> Barbara
>
>
>

--0015174bdca88600d604b25449bc
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Barbara,

Fully with you on the analysis. What I don't get is wha=
t we are trying to achieve with this change?

Cheers
Ole

On=
 Tuesday, November 22, 2011, STARK, BARBARA H <bs7652@att.com> wrote:

>> CPE receives and RA with M=3DO=3D0, what is it supposed to do with=
 regards
>> to PD?
>> left up to the vendor to decide?>
> Yes. Left up to the vendor and other specs.
> Basically=
, we're saying (with the proposed new language) that M=3DO=3D0 will

> not produce predictable results from a "6204bis" CE router. =
M=3DO=3D0
> becomes a "don't care" state in "6204b=
is" CE routers. "Don't care"
> states are a perfec=
tly valid and ok, IMO. So long as we have states

> defined that do allow us to achieve desired predictable behavior.
&=
gt;
> Previously (under the original 6204 requirement) the access net=
work
> could be sure that a CE router would do DHCPv6 Solicit wheneve=
r it

> received an RA. Under the new proposed requirement, the access network=

> can only be sure of the Solicit if it sets M=3D1 or O=3D1. Since I=
'm not
> aware of any access network provider who was planning on=
 setting M=3DO=3D0

> in the RA while operating a DHCPv6 server that was ready and waiting f=
or
> any and all Solicits, this doesn't create a hardship on acce=
ss networks.
> Even with the existing 6204 requirement, there was eno=
ugh unease among

> the access network guys (because of M/O history) as to whether the CE<=
br>> routers would really do DHCPv6 if M=3DO=3D0, that they figured it w=
as best
> to always set one, the other, or both. It wasn't going =
to hurt anything,

> and better safe than sorry. After all, there's nothing that says a=
n
> access network can't set M=3DO=3D1 and then only offer IA_PD.=
 I haven't seen
> anything that tells a device to go belly-up if =
it doesn't get offers

> consistent with what it thinks M/O "promised". A provider co=
uld easily
> do just IA_PD and set M=3DO=3D1, M=3D1/O=3D0, or M=3D0/O=
=3D1 and expect things to
> work. According to either the current 620=
4 or the proposed 6204bis.

> Please don't suggest that these bits can only be set if they are a=
n
> accurate representation of what is being offered. There's not=
hing
> anywhere that says that.
>
> So the access network=
 still has a way to achieve the desired predictable

> behavior. And the defined way is consistent with what the network
&=
gt; providers were planning on doing anyway.
>
> Note that unde=
r the existing 6204 requirements, we already have some
> "don=
9;t care" states defined. For example, if no RA is sent by the access<=
br>
> network, it cannot be predicted whether or not the "6204" CE=
 router will
> send a Solicit, anyway. This "don't care"=
; (aka "fuzzy") state continues
> to exist in the new 6204b=
is. So long as we have a well-defined way to

> achieve the desired result, it's perfectly acceptable to have stat=
es
> that produce unpredictable results.
> Barbara
>
&=
gt;
>

--0015174bdca88600d604b25449bc--

From mark@townsley.net  Tue Nov 22 07:19:49 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC8D821F8C1E for ; Tue, 22 Nov 2011 07:19:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.157
X-Spam-Level: 
X-Spam-Status: No, score=-3.157 tagged_above=-999 required=5 tests=[AWL=-0.159, 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 akCdVGU6sSLu for ; Tue, 22 Nov 2011 07:19:49 -0800 (PST)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id DB97221F8C1C for ; Tue, 22 Nov 2011 07:19:48 -0800 (PST)
Received: by fabs1 with SMTP id s1so614208fab.31 for ; Tue, 22 Nov 2011 07:19:48 -0800 (PST)
Received: by 10.180.4.67 with SMTP id i3mr19897039wii.1.1321975187865; Tue, 22 Nov 2011 07:19:47 -0800 (PST)
Received: from ams-townsley-8712.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id n2sm6816901wiz.16.2011.11.22.07.19.44 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 22 Nov 2011 07:19:45 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-59-70599300
From: Mark Townsley 
In-Reply-To: 
Date: Tue, 22 Nov 2011 16:19:42 +0100
Message-Id: 
References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com>  <5B6B2B64C9FE2A489045EEEADDAFF2C30354473D@XMB-RCD-109.cisco.com> <4EC455D6.8030601@bogus.com>   <7EB596BF-B175-40BF-ABC8-326599670B04@apple.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303544B88@XMB-RCD-109.cisco.com>    <8D342733-88E6-45D3-B388-E001AE32CD77@employees.org> <750BF7861EBBE048B3E648B4BB6E8F4F20DC4FEA@crexc50p>  <007801cca8c8$5610aa00$0231fe00$@iname.com>    
To: Hans Liu 
X-Mailer: Apple Mail (2.1084)
Cc: IPv6 Operations 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Nov 2011 15:19:49 -0000

--Apple-Mail-59-70599300
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On Nov 22, 2011, at 12:24 PM, Hans Liu wrote:

> How about the flow in TR-124i2? Doesn't that suggest a RS and =
DHCP-Solicitation in parallel?  That's my problem!

I'll let the authors comment since they are here, but my understanding =
is that our current implementation tries RS 4 times and then falls back =
to DHCPv6 PD. For the "DHCP Storm" problem, this isn't much of a =
consolation.

- Mark

>=20
> Hans
>=20
> On Tuesday, November 22, 2011, Mark Townsley  =
wrote:
> > Architectural arguments aside and more to running code, did we not =
hear that there is equipment in the field already that *expects* home =
routers to give up and send DHCPv6 even with no RA received? I think I =
have now heard two cases, from two different vendors, where we have this =
expectation today. Couple that with CE that send 3-4 RS and, if no RA =
received, start sending DHCPv6 from two different large retail CPE =
vendors, and I worry that cat is out of the bag on this one. =
"Conservative in what you send" already lost the battle, and "liberal in =
what you accept" is having to make up for it this time.=20
> > - Mark=20
> >
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.org
> > https://www.ietf.org/mailman/listinfo/v6ops
> >
> >
>=20
> --=20
> Instead of following the fashion, we lead it through.


--Apple-Mail-59-70599300
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii


On Nov 22, 2011, at 12:24 PM, Hans Liu wrote:

How about the flow in TR-124i2? Doesn't that suggest a RS and DHCP-Solicitation in parallel?  That's my problem!

I'll let the authors comment since they are here, but my understanding is that our current implementation tries RS 4 times and then falls back to DHCPv6 PD. For the "DHCP Storm" problem, this isn't much of a consolation.

- Mark


Hans

On Tuesday, November 22, 2011, Mark Townsley <mark@townsley.net> wrote:

> Architectural arguments aside and more to running code, did we not hear that there is equipment in the field already that *expects* home routers to give up and send DHCPv6 even with no RA received? I think I have now heard two cases, from two different vendors, where we have this expectation today. Couple that with CE that send 3-4 RS and, if no RA received, start sending DHCPv6 from two different large retail CPE vendors, and I worry that cat is out of the bag on this one. "Conservative in what you send" already lost the battle, and "liberal in what you accept" is having to make up for it this time. 

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

>
>

-- 
Instead of following the fashion, we lead it through.




--Apple-Mail-59-70599300--

From Ted.Lemon@nominum.com  Tue Nov 22 07:23:38 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55A891F0C47 for ; Tue, 22 Nov 2011 07:23:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.574
X-Spam-Level: 
X-Spam-Status: No, score=-106.574 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 lsb+WVaTziPb for ; Tue, 22 Nov 2011 07:23:37 -0800 (PST)
Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id 7DB271F0C46 for ; Tue, 22 Nov 2011 07:23:37 -0800 (PST)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKTsu+eG9N7voxjf9awGWcyXJT5mtedGU0@postini.com; Tue, 22 Nov 2011 07:23:37 PST
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 776D51B8164 for ; Tue, 22 Nov 2011 07:23:36 -0800 (PST)
Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 6EBCB190052; Tue, 22 Nov 2011 07:23:36 -0800 (PST) (envelope-from Ted.Lemon@nominum.com)
Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.01.0339.001; Tue, 22 Nov 2011 07:23:36 -0800
From: Ted Lemon 
To: Mr.R.A.Hunter 
Thread-Topic: [v6ops] New Version	Notification	- draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-03.txt
Thread-Index: AQHMqSqzQKDCMSpfPky7tjHQBJUj2Q==
Date: Tue, 22 Nov 2011 15:23:35 +0000
Message-ID: 
References: <20111115062859.14026.74743.idtracker@ietfa.amsl.com>  <4ECACFF5.6020804@gmail.com>  <4ECB6988.4020209@gmail.com>
In-Reply-To: <4ECB6988.4020209@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.1.10]
Content-Type: multipart/alternative; boundary="_000_BFDBE1B271F24DE18BD2A003D06A7E14nominumcom_"
MIME-Version: 1.0
Cc: "v6ops@ietf.org WG" , Wesley Eddy , Pete Resnick , "" , "ietfdbh@comcast.net Harrington" 
Subject: Re: [v6ops] New Version	Notification	-	draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-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: Tue, 22 Nov 2011 15:23:38 -0000

--_000_BFDBE1B271F24DE18BD2A003D06A7E14nominumcom_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

On Nov 22, 2011, at 4:21 AM, Mr.R.A.Hunter wrote:
When you write "trivially control", what's the refresh/flush mechanism to i=
nform end nodes of a (link) status change?

The point of my message was simply to point out that if you want to control=
 the end nodes using DHCPv6, you can just as well do it with stateful DHCPv=
6 as with a DHCPv6 route option.   Your point about the DHCP server not kno=
wing the local state of the network is of course completely true, and yet a=
nother reason not to use the route option.


--_000_BFDBE1B271F24DE18BD2A003D06A7E14nominumcom_
Content-Type: text/html; charset="iso-8859-1"
Content-ID: <7B0599738EA9A641919964993BA8154E@nominum.com>
Content-Transfer-Encoding: quoted-printable









On Nov 22, 2011, at 4:21 AM, Mr.R.A.Hunter wrote:


When
 you write "trivially control", what's the refresh/flush mechanis=
m to inform end nodes of a (link) status change?








The point of my message was simply to point out that if you want to co=
ntrol the end nodes using DHCPv6, you can just as well do it with stateful =
DHCPv6 as with a DHCPv6 route option.   Your point about the DHCP serv=
er not knowing the local state of the
 network is of course completely true, and yet another reason not to use th=
e route option.









--_000_BFDBE1B271F24DE18BD2A003D06A7E14nominumcom_--

From bs7652@att.com  Tue Nov 22 07:34:30 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFE7721F8C7F for ; Tue, 22 Nov 2011 07:34:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.448
X-Spam-Level: 
X-Spam-Status: No, score=-106.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 M-PhVvxg3kbj for ; Tue, 22 Nov 2011 07:34:29 -0800 (PST)
Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id 0D46321F8C57 for ; Tue, 22 Nov 2011 07:34:29 -0800 (PST)
X-Env-Sender: bs7652@att.com
X-Msg-Ref: server-3.tower-120.messagelabs.com!1321976066!50399328!1
X-Originating-IP: [144.160.20.146]
X-StarScan-Version: 6.3.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 20447 invoked from network); 22 Nov 2011 15:34:27 -0000
Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-3.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 22 Nov 2011 15:34:27 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pAMFWxpa010142; Tue, 22 Nov 2011 10:33:00 -0500
Received: from 01AL10015010626.AD.BLS.COM (sfldmibbcraeninet1.enaf.ait.sbc.com [10.231.16.33]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pAMFWqpL009977; Tue, 22 Nov 2011 10:32:53 -0500
Received: from 01NC27689010627.AD.BLS.COM ([90.144.44.202]) by 01AL10015010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 22 Nov 2011 09:33:30 -0600
Received: from 01NC27689010650.AD.BLS.COM ([90.144.44.120]) by 01NC27689010627.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 22 Nov 2011 10:33:29 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCA92C.15855566"
Date: Tue, 22 Nov 2011 10:34:16 -0500
Message-ID: <750BF7861EBBE048B3E648B4BB6E8F4F20EA1083@crexc50p>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] DHCPv6 option for MAX_SOL_RT
Thread-Index: AcypKZ5yg4QrRCwOSlGMImcZvisdXQAAFYOg
References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com><5B6B2B64C9FE2A489045EEEADDAFF2C30354473D@XMB-RCD-109.cisco.com><4EC455D6.8030601@bogus.com><7EB596BF-B175-40BF-ABC8-326599670B04@apple.com><5B6B2B64C9FE2A489045EEEADDAFF2C303544B88@XMB-RCD-109.cisco.com><8D342733-88E6-45D3-B388-E001AE32CD77@employees.org><750BF7861EBBE048B3E648B4BB6E8F4F20DC4FEA@crexc50p><007801cca8c8$5610aa00$0231fe00$@iname.com><750BF7861EBBE048B3E648B4BB6E8F4F20EA1037@crexc50p> 
From: "STARK, BARBARA H" 
To: "Ole Troan" 
X-OriginalArrivalTime: 22 Nov 2011 15:33:29.0362 (UTC) FILETIME=[15A3E720:01CCA92C]
Cc: IPv6 Operations 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Nov 2011 15:34:31 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CCA92C.15855566
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

We're trying to allow cable operators to do the things they want to do,
allow telco operators to do what they want, all while making sure that
the retail CE routers will work in either environment, without
overwhelming complexity.=20

=20

We're like the super committee trying to come up with a way to balance
the budget. Unless we're all willing to compromise and suffer shared
sacrifice, we're going to dig ourselves into a really deep hole. You
know you've got a reasonable compromise when nobody is completely happy
with the result, but most all reckon they can live with it. From my
perspective, this accurately describes the compromise we've defined.

=20

Or as Dr. Phil asks, "Would you rather be right, or happy?" I'd rather
be happy.

Barbara

=20

From: ichiroumakino@gmail.com [mailto:ichiroumakino@gmail.com] On Behalf
Of Ole Troan
Sent: Tuesday, November 22, 2011 10:16 AM
To: STARK, BARBARA H
Cc: Ole Troan; Frank Bulk; IPv6 Operations
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT

=20

Barbara,

Fully with you on the analysis. What I don't get is what we are trying
to achieve with this change?

Cheers
Ole

On Tuesday, November 22, 2011, STARK, BARBARA H  wrote:
>> CPE receives and RA with M=3DO=3D0, what is it supposed to do with
regards
>> to PD?
>> left up to the vendor to decide?
>
> Yes. Left up to the vendor and other specs.
> Basically, we're saying (with the proposed new language) that =
M=3DO=3D0
will
> not produce predictable results from a "6204bis" CE router. M=3DO=3D0
> becomes a "don't care" state in "6204bis" CE routers. "Don't care"
> states are a perfectly valid and ok, IMO. So long as we have states
> defined that do allow us to achieve desired predictable behavior.
>
> Previously (under the original 6204 requirement) the access network
> could be sure that a CE router would do DHCPv6 Solicit whenever it
> received an RA. Under the new proposed requirement, the access network
> can only be sure of the Solicit if it sets M=3D1 or O=3D1. Since I'm =
not
> aware of any access network provider who was planning on setting =
M=3DO=3D0
> in the RA while operating a DHCPv6 server that was ready and waiting
for
> any and all Solicits, this doesn't create a hardship on access
networks.
> Even with the existing 6204 requirement, there was enough unease among
> the access network guys (because of M/O history) as to whether the CE
> routers would really do DHCPv6 if M=3DO=3D0, that they figured it was =
best
> to always set one, the other, or both. It wasn't going to hurt
anything,
> and better safe than sorry. After all, there's nothing that says an
> access network can't set M=3DO=3D1 and then only offer IA_PD. I =
haven't
seen
> anything that tells a device to go belly-up if it doesn't get offers
> consistent with what it thinks M/O "promised". A provider could easily
> do just IA_PD and set M=3DO=3D1, M=3D1/O=3D0, or M=3D0/O=3D1 and =
expect things to
> work. According to either the current 6204 or the proposed 6204bis.
> Please don't suggest that these bits can only be set if they are an
> accurate representation of what is being offered. There's nothing
> anywhere that says that.
>
> So the access network still has a way to achieve the desired
predictable
> behavior. And the defined way is consistent with what the network
> providers were planning on doing anyway.
>
> Note that under the existing 6204 requirements, we already have some
> "don't care" states defined. For example, if no RA is sent by the
access
> network, it cannot be predicted whether or not the "6204" CE router
will
> send a Solicit, anyway. This "don't care" (aka "fuzzy") state
continues
> to exist in the new 6204bis. So long as we have a well-defined way to
> achieve the desired result, it's perfectly acceptable to have states
> that produce unpredictable results.
> Barbara
>
>
>=20


------_=_NextPart_001_01CCA92C.15855566
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


We’re trying to allow cable operators to do the things they =
want to do, allow telco operators to do what they want, all while making =
sure that the retail CE routers will work in either environment, without =
overwhelming complexity. 
 
We’re like the super committee trying to come up with a way to =
balance the budget. Unless we’re all willing to compromise and =
suffer shared sacrifice, we’re going to dig ourselves into a =
really deep hole. You know you’ve got a reasonable compromise when =
nobody is completely happy with the result, but most all reckon they can =
live with it. From my perspective, this accurately describes the =
compromise we’ve defined.
 
Or as Dr. Phil asks, “Would you rather be right, or =
happy?” I’d rather be happy.
Barbara
 
From:=
 =
ichiroumakino@gmail.com [mailto:ichiroumakino@gmail.com] On Behalf Of =
Ole Troan
Sent: Tuesday, November 22, 2011 10:16 =
AM
To: STARK, BARBARA H
Cc: Ole Troan; Frank Bulk; =
IPv6 Operations
Subject: Re: [v6ops] DHCPv6 option for =
MAX_SOL_RT
 
Barbara,

Fully with you on the analysis. What I =
don't get is what we are trying to achieve with this =
change?

Cheers
Ole

On Tuesday, November 22, 2011, =
STARK, BARBARA H <bs7652@att.com> wrote:
>> =
CPE receives and RA with M=3DO=3D0, what is it supposed to do with =
regards
>> to PD?
>> left up to the vendor to =
decide?
>
> Yes. Left up to the vendor and other =
specs.
> Basically, we're saying (with the proposed new language) =
that M=3DO=3D0 will
> not produce predictable results from a =
"6204bis" CE router. M=3DO=3D0
> becomes a "don't =
care" state in "6204bis" CE routers. "Don't =
care"
> states are a perfectly valid and ok, IMO. So long as =
we have states
> defined that do allow us to achieve desired =
predictable behavior.
>
> Previously (under the original =
6204 requirement) the access network
> could be sure that a CE =
router would do DHCPv6 Solicit whenever it
> received an RA. Under =
the new proposed requirement, the access network
> can only be =
sure of the Solicit if it sets M=3D1 or O=3D1. Since I'm not
> =
aware of any access network provider who was planning on setting =
M=3DO=3D0
> in the RA while operating a DHCPv6 server that was =
ready and waiting for
> any and all Solicits, this doesn't create =
a hardship on access networks.
> Even with the existing 6204 =
requirement, there was enough unease among
> the access network =
guys (because of M/O history) as to whether the CE
> routers would =
really do DHCPv6 if M=3DO=3D0, that they figured it was best
> to =
always set one, the other, or both. It wasn't going to hurt =
anything,
> and better safe than sorry. After all, there's nothing =
that says an
> access network can't set M=3DO=3D1 and then only =
offer IA_PD. I haven't seen
> anything that tells a device to go =
belly-up if it doesn't get offers
> consistent with what it thinks =
M/O "promised". A provider could easily
> do just IA_PD =
and set M=3DO=3D1, M=3D1/O=3D0, or M=3D0/O=3D1 and expect things =
to
> work. According to either the current 6204 or the proposed =
6204bis.
> Please don't suggest that these bits can only be set if =
they are an
> accurate representation of what is being offered. =
There's nothing
> anywhere that says that.
>
> So the =
access network still has a way to achieve the desired =
predictable
> behavior. And the defined way is consistent with =
what the network
> providers were planning on doing =
anyway.
>
> Note that under the existing 6204 requirements, =
we already have some
> "don't care" states defined. For =
example, if no RA is sent by the access
> network, it cannot be =
predicted whether or not the "6204" CE router will
> =
send a Solicit, anyway. This "don't care" (aka =
"fuzzy") state continues
> to exist in the new 6204bis. =
So long as we have a well-defined way to
> achieve the desired =
result, it's perfectly acceptable to have states
> that produce =
unpredictable results.
> Barbara
>
>
> =


------_=_NextPart_001_01CCA92C.15855566--

From jason_livingood@cable.comcast.com  Tue Nov 22 07:52:51 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF8A41F0C5D for ; Tue, 22 Nov 2011 07:52:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.142
X-Spam-Level: 
X-Spam-Status: No, score=-103.142 tagged_above=-999 required=5 tests=[AWL=-2.648, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bMR4ksYEnzwu for ; Tue, 22 Nov 2011 07:52:50 -0800 (PST)
Received: from cable.comcast.com (unknown [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id EC15C1F0C4B for ; Tue, 22 Nov 2011 07:52:47 -0800 (PST)
Received: from ([24.40.55.41]) by copdcavout01.cable.comcast.com with ESMTP  id C7WM3M1.64783; Tue, 22 Nov 2011 08:47:14 -0700
Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%11]) with mapi id 14.01.0339.001; Tue, 22 Nov 2011 10:52:40 -0500
From: "Livingood, Jason" 
To: Lorenzo Colitti 
Thread-Topic: [v6ops] Update of draft-ietf-v6ops-v6-aaaa-whitelisting-implications-07
Thread-Index: AQHMinjPwilI7MOZ/0e305KMc5hLZ5V8ocqAgDym2IA=
Date: Tue, 22 Nov 2011 15:52:39 +0000
Message-ID: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.13.0.110805
x-originating-ip: [147.191.227.196]
Content-Type: multipart/alternative; boundary="_000_CAF1033043A6Fjasonlivingoodcablecomcastcom_"
MIME-Version: 1.0
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] Update of draft-ietf-v6ops-v6-aaaa-whitelisting-implications-07
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Nov 2011 15:52:52 -0000

--_000_CAF1033043A6Fjasonlivingoodcablecomcastcom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Thanks for the feedback, Lorenzo. All of this will be factored into the =96=
08 update shortly. Specific responses inline below.

- Jason

On 10/14/11 5:40 PM, "Lorenzo Colitti" > wrote:
1. I don't like the wording "high-traffic domains". This is not about traff=
ic, it is about domains that desire to provide a service level that is grea=
ter than that offered, in the aggregate, by the current IPv6 Internet. When=
 Google implemented whitelisting, we did not do so to control traffic, but =
because it was the only way to serve IPv6 users without imposing an unaccep=
table penalty to users on the rest of the Internet. To a certain extent the=
 two go hand in hand, because large, high-traffic sites tend to have higher=
 SLAs than smaller sites, but you could imagine other cases too, for exampl=
e the website of a financial institution that doesn't serve a lot of traffi=
c but has tightly bound SLAs. I'm not sure what you'd want to use instead. =
"High-SLA domains", maybe?

Ack. Changed to high-service-level domains.

2. "more recent measurements indicate this is declining [Impairment-Tracker=
]." It is not appropriate to cite that URL, because it stopped collecting m=
eaningful data after December 2010 (with the exception of a single week in =
May 2011). Our brokenness numbers for the Internet as a whole have been mos=
tly stable (actually, slowly rising) since after World IPv6 Day. June 10 wa=
s 0.074% and October 10 was 0.078%, with a mostly smooth linear rise in bet=
ween.

Ack. Struck the reference and the last part of the sentence you were concer=
ned with.

3. As Wes points out, "transition" is an overloaded term, so you might want=
 to use something else. "Migration strategies"?

Ack. Changed to "Potential Migration Tactics".

4. Where you say "One potential tactic may be to identify which users have =
such impairments and then to communicate this information to affected users=
" you should note that in many cases this is forbidden by website operators=
' privacy policies.

Ack. That section already has a reference to the Privacy Considerations sec=
tion. So I have added this to that section:
Finally, if a domain chooses to contact end userd directly concerning their=
 IPv6 impairments, that domain should ensure that such communication is per=
missable under any applicable privacy policies of the domain or its website=
s.

5. In section 4.3, "is not users" -> "is not used".

Fixed.

6. I disagree with this piece of text:

   This tactic will not have a direct
   impact on reducing IPv6-related impairments Section 2.1, though it
   can help a domain address operational maturity concerns Section 2.2
   and concerns and risks related to traffic volume Section 2.3.

While whitelisting doesn't solve IPv6-related impairments, it can *avoid us=
ers that have them*. So it completely removes their impact in all but the f=
ew networks that are whitelisted. This is the primary reason why whitelisti=
ng exists, so it should be mentioned. You might also want to note that whit=
elisting allows a website operator to protect non-IPv6 networks (i.e., netw=
orks that don't support IPv6 and/or have plans to do so) from IPv6-related =
impairments in their networks.

Ack. Added this:
While DNS Resolver Whitelisting does not solve IPv6-related impairments, it=
 can help a domain to avoid users that have them. As a result, the tactic r=
emoves their impact in all but the few networks that are whitelisted. DNS R=
esolver Whitelisting also allows a website operator to protect non-IPv6 net=
works (i.e. networks that do not support IPv6 and/or do not have plans to d=
o so in the future) from IPv6-related impairments in their networks.

7. Where you say:

   Additionally, the IP
   address of a DNS recursive resolver is not a precise indicator of the
   IPv6 preparedness, or lack of IPv6-related impairment, of end user
   hosts which query (use) a particular DNS recursive resolver.

While it's true that the IP address of the resolver by itself is not an ind=
icator of IPv6 preparedness, it's possible to measure the level of prepared=
ness of the users behind any given resolver, e.g., by conducting ongoing la=
rge-scale measurements of IPv6 preparedness of clients using one-time hostn=
ames and correlating the DNS logs with web logs. This is what Google does, =
and we have a pretty good picture of which DNS resolvers have working IPv6 =
users behind them and which don't, what the latency impact of turning on IP=
v6 for any given resolver is, etc.

Ack. Have now updated this section as follows, with the new underlined text=
:

While the IP addresses of DNS recursive resolvers on networks known to have=
 deployed IPv6 may be an imperfect proxy for judging IPv6 preparedness, or =
lack of IPv6-related impairment, it is one of the better available methods =
at the current time. For example, implementers have found that it is possib=
le to measure the level of IPv6 preparedness of the end users behind any gi=
ven DNS recursive resolver by conducting ongoing measurement of the IPv6 pr=
eparedness of end users querying for one-time-use hostnames and then correl=
ating the domain's authoritative DNS server logs with their web server logs=
. This can help implementers form a good picture of which DNS recursive res=
olvers have working IPv6 users behind them and which do not, what the laten=
cy impact of turning on IPv6 for any given DNS recursive resolver is, etc.

8. "If a DNS recursive resolver IS NOT matched in the whitelist, then AAAA =
resource records WILL NOT be sent". Do you need capitals here?

Ack. Changed to lower case.

9. I don't think the discussion of middleboxes in section 4.3.5 is relevant=
. It seems to me that "middleboxes" are boxes that are in the path of data =
packets, whereas DNS is completely orthogonal to actual data transport.

Understood. It is a minor note there. I think it is important to keep some =
pointer to such concerns so we don't lose that completely. I think this is =
a pretty well balanced section overall and would prefer not to tweak it fur=
ther.

10. You may want to note that some DNS server implementations such as Bind =
9.7 support filtering out AAAA replies if the original request was made ove=
r IPv4. This can be used by an operator to blacklist its own users. It was =
used by certain networks on World IPv6 Day (e.g., in Japan).

Understood, but this only works if someone is not using DNSSEC validation o=
n their resolver. As this opens up a whole can of worms around DNS filterin=
g with and without DNSSEC =96 tied to the whole SOPA/PIPA thing in the U.S.=
, I'd prefer not to open that can of worms. ;-)

Thanks again,
Jason


--_000_CAF1033043A6Fjasonlivingoodcablecomcastcom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <8D0B9793668C8145847C97893DE8F8DA@cable.comcast.com>
Content-Transfer-Encoding: quoted-printable











Thanks for the feedback, Lorenzo. All of this will be factored into th=
e =9608 update shortly. Specific responses inline below.







- Jason



















On 10/14/11 5:40 PM, "Lorenzo Colitti" <lorenzo@google.com> wrote:







1. I don't like the wording "high-traffic domains". Thi=
s is not about traffic, it is about domains that desire to provide a servic=
e level that is greater than that offered, in the aggregate, by the current=
 IPv6 Internet. When Google implemented whitelisting,
 we did not do so to control traffic, but because it was the only way to se=
rve IPv6 users without imposing an unacceptable penalty to users on the res=
t of the Internet. To a certain extent the two go hand in hand, because lar=
ge, high-traffic sites tend to have
 higher SLAs than smaller sites, but you could imagine other cases too, for=
 example the website of a financial institution that doesn't serve a lot of=
 traffic but has tightly bound SLAs. I'm not sure what you'd want to use in=
stead. "High-SLA domains", maybe?












Ack. Changed to high-service-level domains. 












2. "more recent measurements indicate this is declining [Imp=
airment-Tracker]." It is not appropriate to cite that URL, because it =
stopped collecting meaningful data after December 2010 (with the exception =
of a single week in May 2011). Our brokenness numbers
 for the Internet as a whole have been mostly stable (actually, slowly risi=
ng) since after World IPv6 Day. June 10 was 0.074% and October 10 was 0.078=
%, with a mostly smooth linear rise in between.












Ack. Struck the reference and the last part of the sentence you were c=
oncerned with. 












3. As Wes points out, "transition" is an overloaded term, so=
 you might want to use something else. "Migration strategies"?











Ack. Changed to "Potential Migration Tactics". 












4. Where you say "One potential tactic may be to identify which u=
sers have such impairments and then to communicate this information to=
 affected users" you should note that in many cases this is forbi=
dden by website operators' privacy policies.












Ack. That section already has a reference to the Privacy Consideration=
s section. So I have added this to that section:


Finally, if a domain chooses to contact end userd directly concerni=
ng their IPv6 impairments, that domain should ensure that such communicatio=
n is permissable under any applicable privacy policies of the domain or its=
 websites.












5. In section 4.3, "is not users" -> "is not used&qu=
ot;.












Fixed.












6. I disagree with this piece of text:









   This tactic will not have a direct


   impact on reducing IPv6-related impairments Section 2.1, =
though it


   can help a domain address operational maturity concerns S=
ection 2.2


   and concerns and risks related to traffic volume Section =
2.3.









While whitelisting doesn't solve IPv6-related impairments, it can =
;*avoid users that have them*. So it completely removes their impact in all=
 but the few networks that are whitelisted. This is the primary reason=
 why whitelisting exists, so it should be
 mentioned. You might also want to note that whitelisting allows a website =
operator to protect non-IPv6 networks (i.e., networks that don't suppo=
rt IPv6 and/or have plans to do so) from IPv6-related impairments in their =
networks. 












Ack. Added this: 


While DNS Resolver Whitelisting does not solve IPv6-related impairm=
ents, it can help a domain to avoid users that have them. As a result, the =
tactic removes their impact in all but the few networks that are whiteliste=
d. DNS Resolver Whitelisting also
 allows a website operator to protect non-IPv6 networks (i.e. networks that=
 do not support IPv6 and/or do not have plans to do so in the future) from =
IPv6-related impairments in their networks. 












7. Where you say:









   Additionally, the IP


   address of a DNS recursive resolver is not a precise indi=
cator of the


   IPv6 preparedness, or lack of IPv6-related impairment, of=
 end user


   hosts which query (use) a particular DNS recursive resolv=
er.









While it's true that the IP address of the resolver by itself is not a=
n indicator of IPv6 preparedness, it's possible to measure the level of pre=
paredness of the users behind any given resolver, e.g., by conducting ongoi=
ng large-scale measurements of IPv6
 preparedness of clients using one-time hostnames and correlating the DNS l=
ogs with web logs. This is what Google does, and we have a pretty good pict=
ure of which DNS resolvers have working IPv6 users behind them and which do=
n't, what the latency impact of
 turning on IPv6 for any given resolver is, etc.












Ack. Have now updated this section as follows, with the new underlined=
 text:







While the IP addresses of DNS recursive resolvers on networks known=
 to have deployed IPv6 may be an imperfect proxy for judging IPv6 preparedn=
ess, or lack of IPv6-related impairment, it is one of the better available =
methods at the current time.
For example, implementers have found that it is possible to measure the =
level of IPv6 preparedness of the end users behind any given DNS recursive =
resolver by conducting ongoing measurement of the IPv6 preparedness of end =
users querying for one-time-use
 hostnames and then correlating the domain's authoritative DNS server logs =
with their web server logs. This can help implementers form a good picture =
of which DNS recursive resolvers have working IPv6 users behind them and wh=
ich do not, what the latency impact
 of turning on IPv6 for any given DNS recursive resolver is, etc. =













8. "If a DNS recursive resolver IS NOT matched in the whitel=
ist, then AAAA resource records WILL NOT be sent". Do you need ca=
pitals here?












Ack. Changed to lower case. 












9. I don't think the discussion of middleboxes in section 4.3.5 is rel=
evant. It seems to me that "middleboxes" are boxes that are in th=
e path of data packets, whereas DNS is completely orthogonal to actual data=
 transport.












Understood. It is a minor note there. I think it is important to keep =
some pointer to such concerns so we don't lose that completely. I think thi=
s is a pretty well balanced section overall and would prefer not to tweak i=
t further.












10. You may want to note that some DNS server implementations such as =
Bind 9.7 support filtering out AAAA replies if the original request was mad=
e over IPv4. This can be used by an operator to blacklist its own users. It=
 was used by certain networks on
 World IPv6 Day (e.g., in Japan).












Understood, but this only works if someone is not using DNSSEC validat=
ion on their resolver. As this opens up a whole can of worms around DNS fil=
tering with and without DNSSEC =96 tied to the whole SOPA/PIPA thing in the=
 U.S., I'd prefer not to open that
 can of worms. ;-)







Thanks again, 


Jason









--_000_CAF1033043A6Fjasonlivingoodcablecomcastcom_--

From internet-drafts@ietf.org  Tue Nov 22 07:54:53 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5578F1F0C8C; Tue, 22 Nov 2011 07:54:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zSq5sOzinOyw; Tue, 22 Nov 2011 07:54:52 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D74CF1F0C4A; Tue, 22 Nov 2011 07:54:52 -0800 (PST)
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: 3.64
Message-ID: <20111122155452.389.71704.idtracker@ietfa.amsl.com>
Date: Tue, 22 Nov 2011 07:54:52 -0800
Cc: v6ops@ietf.org
Subject: [v6ops] I-D Action: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Nov 2011 15:54:53 -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           : Considerations for Transitioning Content to IPv6
	Author(s)       : Jason Livingood
	Filename        : draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08.txt
	Pages           : 31
	Date            : 2011-11-22

   This document describes considerations for the transition of end user
   content on the Internet to IPv6.  While this is tailored to address
   end user content, which is typically web-based, many aspects of this
   document may be more broadly applicable to the transition to IPv6 of
   other applications and services.  This document explores the
   challenges involved in the transition to IPv6, potential migration
   tactics, possible migration phases, and other considerations.  The
   audience for this document is the Internet community generally,
   particularly IPv6 implementers.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-v6-aaaa-whitelisting-i=
mplications-08.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-v6ops-v6-aaaa-whitelisting-im=
plications-08.txt


From bs7652@att.com  Tue Nov 22 08:20:16 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E9231F0CB7 for ; Tue, 22 Nov 2011 08:20:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.159
X-Spam-Level: 
X-Spam-Status: No, score=-106.159 tagged_above=-999 required=5 tests=[AWL=-0.161, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 d4Qwkr+ouT2i for ; Tue, 22 Nov 2011 08:20:13 -0800 (PST)
Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id B16731F0CB8 for ; Tue, 22 Nov 2011 08:20:13 -0800 (PST)
X-Env-Sender: bs7652@att.com
X-Msg-Ref: server-9.tower-120.messagelabs.com!1321978811!50284954!1
X-Originating-IP: [144.160.20.146]
X-StarScan-Version: 6.3.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24473 invoked from network); 22 Nov 2011 16:20:12 -0000
Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-9.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 22 Nov 2011 16:20:12 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pAMGIj7e023166; Tue, 22 Nov 2011 11:18:45 -0500
Received: from 01AL10015010626.AD.BLS.COM (sfldmibbcraeninet1.enaf.ait.sbc.com [10.231.16.33]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pAMGIZDY022959; Tue, 22 Nov 2011 11:18:37 -0500
Received: from 01NC27689010627.AD.BLS.COM ([90.144.44.202]) by 01AL10015010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 22 Nov 2011 10:19:13 -0600
Received: from 01NC27689010650.AD.BLS.COM ([90.144.44.120]) by 01NC27689010627.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 22 Nov 2011 11:19:11 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCA932.780C3EBA"
Date: Tue, 22 Nov 2011 11:19:11 -0500
Message-ID: <750BF7861EBBE048B3E648B4BB6E8F4F20EA112B@crexc50p>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] DHCPv6 option for MAX_SOL_RT
Thread-Index: AcypKhixZURKfTiuRySRHnqgLZwxXQAAxB8Q
References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com><5B6B2B64C9FE2A489045EEEADDAFF2C30354473D@XMB-RCD-109.cisco.com><4EC455D6.8030601@bogus.com><7EB596BF-B175-40BF-ABC8-326599670B04@apple.com><5B6B2B64C9FE2A489045EEEADDAFF2C303544B88@XMB-RCD-109.cisco.com><8D342733-88E6-45D3-B388-E001AE32CD77@employees.org><750BF7861EBBE048B3E648B4BB6E8F4F20DC4FEA@crexc50p><007801cca8c8$5610aa00$0231fe00$@iname.com>  
From: "STARK, BARBARA H" 
To: "Mark Townsley" , "Hans Liu" 
X-OriginalArrivalTime: 22 Nov 2011 16:19:11.0777 (UTC) FILETIME=[783F3910:01CCA932]
Cc: IPv6 Operations 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Nov 2011 16:20:16 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CCA932.780C3EBA
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Yes, current TR-124i2 has RS and DHCPv6 Solicit in parallel. TR-124i2
RGs aren't defined for use in an MSO environment. They are defined to
meet the needs of DSL and PON (telco) providers.

=20

The MSOs want the freedom to define their eRouters to not do DHCPv6 if
no RA is present or if RA has M=3DO=3D0. Both contingents want their =
devices
to be able to claim compliance to 6204(bis).

=20

I don't think anybody is under the illusion that the proposed 6204bis
change will cause the number of CE routers to drop to zero, that are
operating on an MSO access network and that will do DHCPv6 every 2
minutes if there's no response. However, perhaps it is reasonable to
expect the number of such CE routers to drop to a manageable level, as a
result of this (6204bis) change.

=20

As has been pointed out, it is possible to make access architecture
decisions, so that this CE router behavior does not bring the access
network to its knees. I would say that any provider who is procuring RGs
per TR-124i2 had best make sure that their access architecture can
tolerate the behavior of the CE routers that they are procuring to run
on their network.

=20

If TR-124i2 requirements are causing problems for a particular operator,
there are options available: (1) modify or don't use TR-124i2
requirements when doing procurement of your RGs, and (2) in BBF, propose
a change to TR-124i2.

Barbara

=20

From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
Of Mark Townsley
Sent: Tuesday, November 22, 2011 10:20 AM
To: Hans Liu
Cc: IPv6 Operations
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT

=20

=20

On Nov 22, 2011, at 12:24 PM, Hans Liu wrote:





How about the flow in TR-124i2? Doesn't that suggest a RS and
DHCP-Solicitation in parallel?  That's my problem!

=20

I'll let the authors comment since they are here, but my understanding
is that our current implementation tries RS 4 times and then falls back
to DHCPv6 PD. For the "DHCP Storm" problem, this isn't much of a
consolation.

=20

- Mark






Hans

On Tuesday, November 22, 2011, Mark Townsley  wrote:
> Architectural arguments aside and more to running code, did we not
hear that there is equipment in the field already that *expects* home
routers to give up and send DHCPv6 even with no RA received? I think I
have now heard two cases, from two different vendors, where we have this
expectation today. Couple that with CE that send 3-4 RS and, if no RA
received, start sending DHCPv6 from two different large retail CPE
vendors, and I worry that cat is out of the bag on this one.
"Conservative in what you send" already lost the battle, and "liberal in
what you accept" is having to make up for it this time.=20
> - Mark=20
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>
>

--=20
Instead of following the fashion, we lead it through.

=20


------_=_NextPart_001_01CCA932.780C3EBA
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Yes, current TR-124i2 has RS and DHCPv6 Solicit in parallel. TR-124i2 =
RGs aren’t defined for use in an MSO environment. They are defined =
to meet the needs of DSL and PON (telco) =
providers.
 
The MSOs want the freedom to define their eRouters to not do DHCPv6 =
if no RA is present or if RA has M=3DO=3D0. Both contingents want their =
devices to be able to claim compliance to =
6204(bis).
 
I don’t think anybody is under the illusion that the proposed =
6204bis change will cause the number of CE routers to drop to zero, that =
are operating on an MSO access network and that will do DHCPv6 every 2 =
minutes if there’s no response. However, perhaps it is reasonable =
to expect the number of such CE routers to drop to a manageable level, =
as a result of this (6204bis) change.
 
As has been pointed out, it is possible to make access architecture =
decisions, so that this CE router behavior does not bring the access =
network to its knees. I would say that any provider who is procuring RGs =
per TR-124i2 had best make sure that their access architecture can =
tolerate the behavior of the CE routers that they are procuring to run =
on their network.
 
If TR-124i2 requirements are causing problems for a particular =
operator, there are options available: (1) modify or don’t use =
TR-124i2 requirements when doing procurement of your RGs, and (2) in =
BBF, propose a change to TR-124i2.
Barbara
 
From:=
 =
v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of =
Mark Townsley
Sent: Tuesday, November 22, 2011 10:20 =
AM
To: Hans Liu
Cc: IPv6 =
Operations
Subject: Re: [v6ops] DHCPv6 option for =
MAX_SOL_RT
 
 
On =
Nov 22, 2011, at 12:24 PM, Hans Liu wrote:


How about =
the flow in TR-124i2? Doesn't that suggest a RS and DHCP-Solicitation in =
parallel?  That's my problem!
 
I'll let the authors comment since they are here, but =
my understanding is that our current implementation tries RS 4 times and =
then falls back to DHCPv6 PD. For the "DHCP Storm" problem, =
this isn't much of a consolation.
 
- =
Mark



Hans

On Tuesday, November 22, 2011, Mark =
Townsley <mark@townsley.net> =
wrote:
> Architectural arguments aside and more to running code, =
did we not hear that there is equipment in the field already that =
*expects* home routers to give up and send DHCPv6 even with no RA =
received? I think I have now heard two cases, from two different =
vendors, where we have this expectation today. Couple that with CE that =
send 3-4 RS and, if no RA received, start sending DHCPv6 from two =
different large retail CPE vendors, and I worry that cat is out of the =
bag on this one. "Conservative in what you send" already lost =
the battle, and "liberal in what you accept" is having to make =
up for it this time. 
> - Mark 
>
> =
_______________________________________________
> v6ops mailing =
list
> v6ops@ietf.org
> https://www.ietf.org=
/mailman/listinfo/v6ops
>
>

-- 
Instead of =
following the fashion, we lead it through.
 

------_=_NextPart_001_01CCA932.780C3EBA--

From pch-b29AA871B@u-1.phicoh.com  Tue Nov 22 09:19:40 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34CE121F8B4A for ; Tue, 22 Nov 2011 09:19:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.435
X-Spam-Level: 
X-Spam-Status: No, score=-8.435 tagged_above=-999 required=5 tests=[AWL=0.164,  BAYES_00=-2.599, GB_I_LETTER=-2, 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 EWRqanKffGbz for ; Tue, 22 Nov 2011 09:19:39 -0800 (PST)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 427EF21F8B43 for ; Tue, 22 Nov 2011 09:19:39 -0800 (PST)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #76) id m1RStzt-0001iMC; Tue, 22 Nov 2011 18:19:05 +0100
Message-Id: 
To: Tassos Chatzithomaoglou 
From: Philip Homburg 
Sender: pch-b29AA871B@u-1.phicoh.com
In-reply-to: Your message of "Tue, 22 Nov 2011 14:01:52 +0200 ." <4ECB8F30.7040000@forthnetgroup.gr> 
Date: Tue, 22 Nov 2011 18:18:59 +0100
Cc: v6ops@ietf.org
Subject: Re: [v6ops] question about initial connections to DNS servers in draft-ietf-v6ops-happy-eyeballs-05
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Nov 2011 17:19:40 -0000

In your letter dated Tue, 22 Nov 2011 14:01:52 +0200 you wrote:
>Although steps after 6 are described inside the text, i couldn't get a clear i
>ndication about steps 1-4 and most notably about 1-2.
>I had a quick look at RFC4472, RFC3484 and draft-ietf-6man-rfc3484-revise-05, 
>but i'm still a little bit confused.
>
>If IPv6 is preferred over IPv4, do we assume the A query (over IPv6 transport)
> will happen before the AAAA query (over IPv6 transport)?
>Do we also assume that the client will have IPv6 connectivity to the IPv6 DNS 
>server?
>
>What i'm actually asking for are details about the steps before HE kicks in du
>al-stack hosts, when both IPv4/IPv6 DNS servers are available to the client.
>Is it like below?
>
>A query to IPv6 DNS server
>AAAA query to IPv6 DNS server
>A query to IPv4 DNS server
>AAAA query to IPv4 DNS server
>
>Do these or some of these happen in parallel, or is the IPv4 DNS server asked 
>only if the IPv6 DNS server doesn't respond?

DNS is not the problem Happy Eyeballs tries to solve. As you are obviously
aware of, DNS queries and DNS transport are independent. This means that if
you configure a broken DNS resolver, then typically you will find out quickly
because things stop working or become slow. This is to a very large extent 
independent of whether any AAAA records exist or not. There are stories
about home routers mangling AAAA records, but it is either not common or
it otherwise does not cause major problems.

So we can safely assume that any user who has IPv6 enabled has a working 
DNS setup that can handle AAAA queries. What we don't know is whether the
IPv6 connection actually works. And that is where Happy Eyeballs comes in.



From internet-drafts@ietf.org  Tue Nov 22 11:05:09 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2FCB11E80B0; Tue, 22 Nov 2011 11:05:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.633
X-Spam-Level: 
X-Spam-Status: No, score=-102.633 tagged_above=-999 required=5 tests=[AWL=-0.034, 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 FMvvmtSr9L11; Tue, 22 Nov 2011 11:05:08 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7856111E80AA; Tue, 22 Nov 2011 11:05:08 -0800 (PST)
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: 3.64
Message-ID: <20111122190508.3293.41916.idtracker@ietfa.amsl.com>
Date: Tue, 22 Nov 2011 11:05:08 -0800
Cc: v6ops@ietf.org
Subject: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-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: Tue, 22 Nov 2011 19:05:09 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the IPv6 Operations Working Group of the =
IETF.

	Title           : Basic Requirements for IPv6 Customer Edge Routers
	Author(s)       : Hemant Singh
                          Wes Beebee
                          Chris Donley
                          Barbara Stark
                          Ole Troan
	Filename        : draft-ietf-v6ops-6204bis-03.txt
	Pages           : 22
	Date            : 2011-11-22

   This document specifies requirements for an IPv6 Customer Edge (CE)
   router.  Specifically, the current version of this document focuses
   on the basic provisioning of an IPv6 CE router and the provisioning
   of IPv6 hosts attached to it.  The document also covers IP transition
   technologies and transition technologies coexistence.  Two transition
   technologies in RFC 5969's 6rd and RFC 6333's DS-Lite. are covered in
   the document.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-6204bis-03.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-v6ops-6204bis-03.txt


From wesley.george@twcable.com  Tue Nov 22 11:05:43 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDF2511E80B8 for ; Tue, 22 Nov 2011 11:05:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.947
X-Spam-Level: 
X-Spam-Status: No, score=-0.947 tagged_above=-999 required=5 tests=[AWL=0.515,  BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368,  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 Lyb6v6AvIWvm for ; Tue, 22 Nov 2011 11:05:41 -0800 (PST)
Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 020EE11E80AA for ; Tue, 22 Nov 2011 11:05:40 -0800 (PST)
X-SENDER-IP: 10.136.163.13
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="4.69,553,1315195200";  d="scan'208,217";a="300835911"
Received: from unknown (HELO PRVPEXHUB04.corp.twcable.com) ([10.136.163.13]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 22 Nov 2011 14:00:55 -0500
Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.26]) by PRVPEXHUB04.corp.twcable.com ([10.136.163.13]) with mapi; Tue, 22 Nov 2011 14:05:38 -0500
From: "George, Wes" 
To: "Livingood, Jason" , "v6ops@ietf.org" 
Date: Tue, 22 Nov 2011 14:05:36 -0500
Thread-Topic: [v6ops] Update of draft-ietf-v6ops-v6-aaaa-whitelisting-implications-07
Thread-Index: AQHMinjPwilI7MOZ/0e305KMc5hLZ5V7/bLQgD0dLQCAAF1RwA==
Message-ID: 
References:  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_DCC302FAA9FE5F4BBA4DCAD4656937791452BBBD9BPRVPEXVS03cor_"
MIME-Version: 1.0
Subject: Re: [v6ops] Update of draft-ietf-v6ops-v6-aaaa-whitelisting-implications-07
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Nov 2011 19:05:44 -0000

--_000_DCC302FAA9FE5F4BBA4DCAD4656937791452BBBD9BPRVPEXVS03cor_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com]
Sent: Tuesday, November 22, 2011 8:09 AM
To: George, Wes; v6ops@ietf.org
Subject: Re: [v6ops] Update of draft-ietf-v6ops-v6-aaaa-whitelisting-implic=
ations-07
4.4 - you say "It
is unclear
   when and if it may be appropriate for a domain to change from
   whitelisting to blacklisting.  Nor is it clear how implementers will
   judge the network conditions to have changed sufficiently to justify
   disabling such controls."
I'm concerned with leaving it at that. This is a good place to put in a war=
ning that these, especially whitelists, should not be considered an open-en=
ded deployment, and that before deploying blacklist/whitelist, content prov=
iders/domain owners should have concrete criteria and means for consistentl=
y (if not continuously) testing those criteria so that it is clear when the=
 risk of impairment has dropped below their threshold and this can be remov=
ed. In other words, I would like us to say "black/whitelisting shouldn't be=
 used for longer than is necessary" while still acknowledging that everyone=
 has a slightly different value of necessary.

I understand your concern and have previously attempted more direct languag=
e on the duration of these migration tactics. But ultimately the WG, especi=
ally in consultation with implementers, was not able to reach consensus on =
anything beyond the text in 4.4. I am comfortable with it as-is with the co=
nsensus position.


[WEG] For clarification, I'm not suggesting that you recommend a timeline/d=
uration, and I'm not surprised that you were unable to obtain consensus on =
that. I fully agree that everyone's timeline is going to be different. My p=
roblem is with the fact that this simply states "it's unclear" instead of a=
cknowledging that everyone's timeline will be different and making a recomm=
endation that you should re-evaluate every so often in order to determine w=
hat *your* specific timeline is - that is, when it is appropriate to change=
 from whitelisting to blacklisting, or to eliminate blacklisting altogether=
. I see that the rev went out already, but  perhaps if this alternate text =
makes sense, you can spin a rev fairly easily:
"This document does not recommend a specific timeline to move from whitelis=
ting to blacklisting or to completely open access. This is because each dom=
ain has different needs, customers, and other considerations that inform th=
at decision. However, it is important to note that whitelisting might not a=
lways be an appropriate open-ended [long-term?] solution, and implementers =
should at least consider the quantitative metrics or criteria by which they=
 measure the success or failure of blacklisting, whitelisting, or open acce=
ss. It is good practice to periodically review those metrics to determine w=
hether whitelisting or blacklisting is still necessary. If removing these m=
echanisms can be done without adversely effecting the end-user experience, =
it may make sense to do so, as removal is likely to reduce the complexity o=
f the implementation."

Thanks
Wes George

________________________________
This E-mail and any of its attachments may contain Time Warner Cable propri=
etary information, which is privileged, confidential, or subject to copyrig=
ht belonging to Time Warner Cable. This E-mail is intended solely for the u=
se of the individual or entity to which it is addressed. If you are not the=
 intended recipient of this E-mail, you are hereby notified that any dissem=
ination, distribution, copying, or action taken in relation to the contents=
 of and attachments to this E-mail is strictly prohibited and may be unlawf=
ul. If you have received this E-mail in error, please notify the sender imm=
ediately and permanently delete the original and any copy of this E-mail an=
d any printout.

--_000_DCC302FAA9FE5F4BBA4DCAD4656937791452BBBD9BPRVPEXVS03cor_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

















From: Livingoo=
d, Jason [mailto:Jason_Livingood@cable.comcast.com]


Sent: Tuesday, November 22, 2011 8:09 AM

To: George, Wes; v6ops@ietf.org

Subject: Re: [v6ops] Update of draft-ietf-v6ops-v6-aaaa-whitelisting=
-implications-07












4.4 – you say “It


is unclear














 &nb=
sp; when and if it may be appropriate for a domain to change from


 &nb=
sp; whitelisting to blacklisting.  Nor is it clear how implementers wi=
ll


 &nb=
sp; judge the network conditions to have changed sufficiently to justify


 &nb=
sp; disabling such controls.”


I’m concerned with leaving it at tha=
t. This is a good place to put in a warning that these, especially whitelis=
ts, should not be considered an open-ended deployment, and that
 before deploying blacklist/whitelist, content providers/domain owners shou=
ld have concrete criteria and means for consistently (if not continuously) =
testing those criteria so that it is clear when the risk of impairment has =
dropped below their threshold and
 this can be removed. In other words, I would like us to say “black/w=
hitelisting shouldn’t be used for longer than is necessary” whi=
le still acknowledging that everyone has a slightly different value of nece=
ssary.










 






I understand your concern and have previousl=
y attempted more direct language on the duration of these migration tactics=
. But ultimately the WG, especially in consultation with
 implementers, was not able to reach consensus on anything beyond the text =
in 4.4. I am comfortable with it as-is with the consensus position.






 






 


[WEG] For clarifica=
tion, I’m not suggesting that you recommend a timeline/duration, and =
I’m not surprised that you were unable to obtain consensus on
 that. I fully agree that everyone’s timeline is going to be differen=
t. My problem is with the fact that this simply states “it’s un=
clear” instead of acknowledging that everyone’s timeline will b=
e different and making a recommendation that you should re-evaluate
 every so often in order to determine what *your* specific timeline is R=
11; that is, when it is appropriate to change from whitelisting to blacklis=
ting, or to eliminate blacklisting altogether. I see that the rev went out =
already, but  perhaps if this alternate
 text makes sense, you can spin a rev fairly easily:<=
/b>


“This document does=
 not recommend a specific timeline to move from whitelisting to blacklistin=
g or to completely open access. This is because each domain has
 different needs, customers, and other considerations that inform that deci=
sion. However, it is important to note that whitelisting might not always b=
e an appropriate open-ended [long-term?] solution, and implementers should =
at least consider the quantitative
 metrics or criteria by which they measure the success or failure of blackl=
isting, whitelisting, or open access. It is good practice to periodically r=
eview those metrics to determine whether whitelisting or blacklisting is st=
ill necessary. If removing these
 mechanisms can be done without adversely effecting the end-user experience=
, it may make sense to do so, as removal is likely to reduce the complexity=
 of the implementation.”


 <=
/p>

Thanks


Wes George











This E-mail and any of its a=
ttachments 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 a=
re not the intended recipient of this E-mail, you are hereby notified that =
any dissemination, distribution, copying, or action taken in relation to th=
e contents of and attachments to
 this E-mail is strictly prohibited and may be unlawful. If you have receiv=
ed this E-mail in error, please notify the sender immediately and permanent=
ly delete the original and any copy of this E-mail and any printout.





--_000_DCC302FAA9FE5F4BBA4DCAD4656937791452BBBD9BPRVPEXVS03cor_--

From achatz@forthnetgroup.gr  Tue Nov 22 11:32:58 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B54421F89B8 for ; Tue, 22 Nov 2011 11:32:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.409
X-Spam-Level: 
X-Spam-Status: No, score=-3.409 tagged_above=-999 required=5 tests=[AWL=1.190,  BAYES_00=-2.599, GB_I_LETTER=-2]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gtBJp6YQrDnM for ; Tue, 22 Nov 2011 11:32:57 -0800 (PST)
Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.115]) by ietfa.amsl.com (Postfix) with ESMTP id 709C921F899F for ; Tue, 22 Nov 2011 11:32:56 -0800 (PST)
Received: from mx-av-05.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 pAMJWtf1003386;  Tue, 22 Nov 2011 21:32:55 +0200
Received: from MX-IN-02.forthnet.gr (mx-in-02.forthnet.gr [193.92.150.185]) by mx-av-05.forthnet.gr (8.14.4/8.14.4) with ESMTP id pAMJWt2H000923; Tue, 22 Nov 2011 21:32:55 +0200
Received: from [192.168.1.2] (194.219.107.39.dsl.dyn.forthnet.gr [194.219.107.39]) (authenticated bits=0) by MX-IN-02.forthnet.gr (8.14.4/8.14.4) with ESMTP id pAMJWiqI013778; Tue, 22 Nov 2011 21:32:45 +0200
Authentication-Results: MX-IN-02.forthnet.gr smtp.mail=achatz@forthnetgroup.gr; auth=pass (PLAIN)
Message-ID: <4ECBF8DC.10702@forthnetgroup.gr>
Date: Tue, 22 Nov 2011 21:32:44 +0200
From: Tassos Chatzithomaoglou 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110928 Firefox/7.0.1 SeaMonkey/2.4.1
MIME-Version: 1.0
To: Philip Homburg 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: v6ops@ietf.org
Subject: Re: [v6ops] question about initial connections to DNS servers in draft-ietf-v6ops-happy-eyeballs-05
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Nov 2011 19:32:58 -0000

Philip, i was actually trying to find out what happens before HE kicks in (that's for an 
implementation we are trying in-home).
This isn't necessarily related to the draft, although i would like to know why in the 
diagrams the A query goes before the AAAA query.
Anyway, thanks for the clarification about the assumption of a working DNS server.

--
Tassos


Philip Homburg wrote on 22/11/2011 19:18:
> In your letter dated Tue, 22 Nov 2011 14:01:52 +0200 you wrote:
>> Although steps after 6 are described inside the text, i couldn't get a clear i
>> ndication about steps 1-4 and most notably about 1-2.
>> I had a quick look at RFC4472, RFC3484 and draft-ietf-6man-rfc3484-revise-05,
>> but i'm still a little bit confused.
>>
>> If IPv6 is preferred over IPv4, do we assume the A query (over IPv6 transport)
>> will happen before the AAAA query (over IPv6 transport)?
>> Do we also assume that the client will have IPv6 connectivity to the IPv6 DNS
>> server?
>>
>> What i'm actually asking for are details about the steps before HE kicks in du
>> al-stack hosts, when both IPv4/IPv6 DNS servers are available to the client.
>> Is it like below?
>>
>> A query to IPv6 DNS server
>> AAAA query to IPv6 DNS server
>> A query to IPv4 DNS server
>> AAAA query to IPv4 DNS server
>>
>> Do these or some of these happen in parallel, or is the IPv4 DNS server asked
>> only if the IPv6 DNS server doesn't respond?
> DNS is not the problem Happy Eyeballs tries to solve. As you are obviously
> aware of, DNS queries and DNS transport are independent. This means that if
> you configure a broken DNS resolver, then typically you will find out quickly
> because things stop working or become slow. This is to a very large extent
> independent of whether any AAAA records exist or not. There are stories
> about home routers mangling AAAA records, but it is either not common or
> it otherwise does not cause major problems.
>
> So we can safely assume that any user who has IPv6 enabled has a working
> DNS setup that can handle AAAA queries. What we don't know is whether the
> IPv6 connection actually works. And that is where Happy Eyeballs comes in.
>
>
>

From simon.perreault@viagenie.ca  Tue Nov 22 11:43:49 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 945BA21F8AEE for ; Tue, 22 Nov 2011 11:43:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 vP8QKf1Xp1rG for ; Tue, 22 Nov 2011 11:43:49 -0800 (PST)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id E8DF921F8AD1 for ; Tue, 22 Nov 2011 11:43:48 -0800 (PST)
Received: from banana.viagenie.ca (unknown [IPv6:2607:fa48:6d77:a020:1e4b:d6ff:fe20:6cfe]) by jazz.viagenie.ca (Postfix) with ESMTPSA id DBB4920D2C; Tue, 22 Nov 2011 14:43:12 -0500 (EST)
Message-ID: <4ECBFB50.2060902@viagenie.ca>
Date: Tue, 22 Nov 2011 14:43:12 -0500
From: Simon Perreault 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc15 Lightning/1.0b3pre Thunderbird/3.1.10
MIME-Version: 1.0
To: Tassos Chatzithomaoglou 
References:  <4ECBF8DC.10702@forthnetgroup.gr>
In-Reply-To: <4ECBF8DC.10702@forthnetgroup.gr>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: Philip Homburg , v6ops@ietf.org
Subject: Re: [v6ops] question about initial connections to DNS servers in draft-ietf-v6ops-happy-eyeballs-05
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Nov 2011 19:43:49 -0000

Tassos Chatzithomaoglou wrote, on 11/22/2011 02:32 PM:
> i would like to know why
> in the diagrams the A query goes before the AAAA query.

It doesn't really matter which one goes first. The intention is for them to go
out simultaneously. Since perfect simultaneity is impossible, one of them has to
go first.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

From shemant@cisco.com  Tue Nov 22 12:05:49 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53E0511E8091 for ; Tue, 22 Nov 2011 12:05:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.963
X-Spam-Level: 
X-Spam-Status: No, score=-5.963 tagged_above=-999 required=5 tests=[AWL=0.036,  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 NOS0+u3tIcra for ; Tue, 22 Nov 2011 12:05:48 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 987E611E8082 for ; Tue, 22 Nov 2011 12:05:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=2191; q=dns/txt; s=iport; t=1321992348; x=1323201948; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=hgaBQdr/6eqO41ginwf5wIhA6PGm9ly8uNgx/3Sspwg=; b=ghtFTg6VDhrhcOiSxJAG7hMmTzeoBDQ6acgHex1PWbXlZzbz+QOy5zMW AzgYQJrT7TdqVBD9E5bkWiL0MqbdQEgfzGtHv4NSNNIsv+1lsi4icriil QcZsWGtTrjhuPurZJdPllPbD0XOp+6au3hCzpbEoZIn4iJb/goqqo9JQ2 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApkAACcAzE6tJV2Y/2dsb2JhbABEmkSQGYEFgXIBAQEEAQEBDwEdCjQXBAIBCBEEAQELBhcBBgEmHwkIAQEEEwgBGYdrliABnkuHTYIyYwSIHJFvhQ2HUg
X-IronPort-AV: E=Sophos;i="4.69,554,1315180800"; d="scan'208";a="38267941"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP; 22 Nov 2011 20:05:48 +0000
Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pAMK5mPk028846 for ; Tue, 22 Nov 2011 20:05:48 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 22 Nov 2011 14:05:48 -0600
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 22 Nov 2011 14:05:47 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3035EED43@XMB-RCD-109.cisco.com>
In-Reply-To: <20111122190508.3293.41916.idtracker@ietfa.amsl.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
Thread-Index: AcypScq4BpUJks9cQk2Hg+q9crVfEAABBxfw
References: <20111122190508.3293.41916.idtracker@ietfa.amsl.com>
From: "Hemant Singh (shemant)" 
To: 
X-OriginalArrivalTime: 22 Nov 2011 20:05:48.0069 (UTC) FILETIME=[2044BD50:01CCA952]
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-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: Tue, 22 Nov 2011 20:05:49 -0000

Folks who are reviewing 6rd sunsetting, please review section 4.4.3 of
this new version of rfc6204bis, especially bullets 5 and 6 and the last
paragraph of the section.  Others, please use the URL provided below to
see a rfcdiff between the -03 and -02 versions.  The DS-Lite bullet
DLW-4 has changed as per Carl's and Francois-Xavier Le Bail comments on
this bullet.

http://tinyurl.com/7rd7bkb

Thanks to all for their comments thus far.

Regards,

Hemant

-----Original Message-----
From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
Of internet-drafts@ietf.org
Sent: Tuesday, November 22, 2011 2:05 PM
To: i-d-announce@ietf.org
Cc: v6ops@ietf.org
Subject: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt


A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the IPv6 Operations Working
Group of the IETF.

	Title           : Basic Requirements for IPv6 Customer Edge
Routers
	Author(s)       : Hemant Singh
                          Wes Beebee
                          Chris Donley
                          Barbara Stark
                          Ole Troan
	Filename        : draft-ietf-v6ops-6204bis-03.txt
	Pages           : 22
	Date            : 2011-11-22

   This document specifies requirements for an IPv6 Customer Edge (CE)
   router.  Specifically, the current version of this document focuses
   on the basic provisioning of an IPv6 CE router and the provisioning
   of IPv6 hosts attached to it.  The document also covers IP transition
   technologies and transition technologies coexistence.  Two transition
   technologies in RFC 5969's 6rd and RFC 6333's DS-Lite. are covered in
   the document.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-6204bis-03.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-v6ops-6204bis-03.txt

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

From brian.e.carpenter@gmail.com  Tue Nov 22 13:04:46 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89B4211E80D2 for ; Tue, 22 Nov 2011 13:04:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.497
X-Spam-Level: 
X-Spam-Status: No, score=-103.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ivZMX-pLlNai for ; Tue, 22 Nov 2011 13:04:46 -0800 (PST)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1396311E80D1 for ; Tue, 22 Nov 2011 13:04:46 -0800 (PST)
Received: by ggnp4 with SMTP id p4so773560ggn.31 for ; Tue, 22 Nov 2011 13:04:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=hcQ8pfgs259e949R2fOKFnLZktwepycXkoykM2DKHRQ=; b=nHLjKm5nsrwSWoR4INwYCE2QeNI1eUedl4jNthqM5MHl/5e/EtaczzcLOpmx+w3d3k j/0qVU/T+DSrT5LP7o5IUQUg7/ZlSvS3Ahs8BQQSVYVWaDULP5Xpy/YCyMPfYWvzr/bq T3XQxDTzHoC0tFV7mvEFAjqAztk64PCBOuL78=
Received: by 10.213.27.20 with SMTP id g20mr421380ebc.34.1321995885029; Tue, 22 Nov 2011 13:04:45 -0800 (PST)
Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id z58sm45377859eea.3.2011.11.22.13.04.40 (version=SSLv3 cipher=OTHER); Tue, 22 Nov 2011 13:04:44 -0800 (PST)
Message-ID: <4ECC0E65.9060607@gmail.com>
Date: Wed, 23 Nov 2011 10:04:37 +1300
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Ted Lemon 
References: <20111115062859.14026.74743.idtracker@ietfa.amsl.com>  <4ECACFF5.6020804@gmail.com>   <3D4D775D-E926-4F89-B279-75F0FE02B98F@nominum.com>
In-Reply-To: <3D4D775D-E926-4F89-B279-75F0FE02B98F@nominum.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "v6ops@ietf.org WG" , Wesley Eddy , Pete Resnick , "" , "ietfdbh@comcast.net Harrington" 
Subject: Re: [v6ops] New Version Notification - draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-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: Tue, 22 Nov 2011 21:04:46 -0000

Ted,

On 2011-11-22 16:42, Ted Lemon wrote:
=2E..
> I'm agnostic=E2=80=94it's pretty obvious to me that we can solve this w=
ith some backwards-compatible changes to RA.  So even though I personally=
 would have preferred to use DHCP to solve this entire set of problems, s=
ince we didn't do that, I think we should just fix RA.

Which draft(s) describe those changes?

Given that the IETF Last Call on this draft ended 2011-06-21,
there's been plenty of time to document the alternatives.

   Brian


From brian.e.carpenter@gmail.com  Tue Nov 22 13:14:57 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA54211E80AA for ; Tue, 22 Nov 2011 13:14:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.515
X-Spam-Level: 
X-Spam-Status: No, score=-103.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RvRbvO5fIGYP for ; Tue, 22 Nov 2011 13:14:57 -0800 (PST)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 67B061F0C5A for ; Tue, 22 Nov 2011 13:14:57 -0800 (PST)
Received: by ggnp4 with SMTP id p4so783391ggn.31 for ; Tue, 22 Nov 2011 13:14:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=s0RH4xm5AEEyIqJOw+sh7tKr06gpXbGvWg3c1NqetmE=; b=TmZ7P+hSVqs2YjiH7vyIPqDSJPlu6uBq8DFB4OgHbrx2H4iRdjMlhqdmEsfARCaiW4 WYhN+lwkP5frQQKsbbl9hSdjTHEJby43SypAPADHc3qMlPxn9l7azEZV+GNP11Q8oQum qIGhBZuG/Tlxehao8+uu97KF9arF1yiDj1C9c=
Received: by 10.213.106.3 with SMTP id v3mr1032311ebo.56.1321996496244; Tue, 22 Nov 2011 13:14:56 -0800 (PST)
Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id 5sm45458633eev.2.2011.11.22.13.14.51 (version=SSLv3 cipher=OTHER); Tue, 22 Nov 2011 13:14:55 -0800 (PST)
Message-ID: <4ECC10C9.5010607@gmail.com>
Date: Wed, 23 Nov 2011 10:14:49 +1300
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: 		<68DAB112-6E32-45FE-9AB7-A34E64898F60@cisco.com>	<5B6B2B64C9FE2A489045EEEADDAFF2C30354436E@XMB-RCD-109.cisco.com>	<750BF7861EBBE048B3E648B4BB6E8F4F20DC41F6@crexc50p>		<252D3DEA-FF09-42C8-959E-8A7205D9DE67@townsley.net>	 <20111122133612.GH71280@Space.Net>
In-Reply-To: <20111122133612.GH71280@Space.Net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: Alexandre Cassen , Claire Cheng , v6ops@ietf.org
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Nov 2011 21:14:58 -0000

On 2011-11-23 02:36, Gert Doering wrote:
> Hi,
> 
> On Tue, Nov 22, 2011 at 06:34:15PM +0900, Lorenzo Colitti wrote:
>> If you want to support 6rd service being provided by a different ISP than
>> native IPv6 service you may have to deal with ingress filtering issues. 

I don't understand why a second ISP would be involved; the
process being documented is how a single ISP moves its customers
over from 6rd.

> Even if it's the same ISP, it's two different machineries that terminate
> 6rd and "native", and neither might have knowledge about "the other" prefix.
> 
> So if "straightforward" BCP38 filtering is used, I'd expect this to drop
> packets arriving over the "wrong" technology.

This, or strict RPF, would be self-foot-shooting by the ISP
wishing to sunset 6rd. It seems fairly simple to specify that
both ingress filtering and RPF should be configured to allow
both prefixes simultaneously. This is a standard need for
multihomed PA customers anyway, and needs to become standard
practice for all IPv6 ISPs.

While we do need a solution for source-prefix based exit
selection, we don't have one yet and it's a separable problem.

    Brian

From brian.e.carpenter@gmail.com  Tue Nov 22 13:26:59 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D37A11E80A4 for ; Tue, 22 Nov 2011 13:26:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.516
X-Spam-Level: 
X-Spam-Status: No, score=-103.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qW7CsL03fKLK for ; Tue, 22 Nov 2011 13:26:59 -0800 (PST)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id C7DB721F8AF4 for ; Tue, 22 Nov 2011 13:26:58 -0800 (PST)
Received: by ghrr14 with SMTP id r14so760344ghr.31 for ; Tue, 22 Nov 2011 13:26:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=tbGJ4ErloZydX04KRiY9vpND4y9N4H8T1+Lx+SidqHk=; b=GqW/tBtp2TNxXsjPDuR657zrVO2MA60jejyQ2K9Dx8maIMFoc0v9vDVyCM5wbw6Tgb l5wt8L5Z8+OWBTX9hsFdlqa8M93AzpRRb147BAb5E4Pdr7HrDmUpLV9zaxTJNcHTh7/n UE6FcJEK+j0cG9+hugVq1SeVfUacz7gxTb81c=
Received: by 10.14.11.20 with SMTP id 20mr1463694eew.61.1321997218158; Tue, 22 Nov 2011 13:26:58 -0800 (PST)
Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id q28sm45509484eea.6.2011.11.22.13.26.55 (version=SSLv3 cipher=OTHER); Tue, 22 Nov 2011 13:26:57 -0800 (PST)
Message-ID: <4ECC139C.9080600@gmail.com>
Date: Wed, 23 Nov 2011 10:26:52 +1300
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: "Livingood, Jason" 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] Title of draft-ietf-v6ops-v6-aaaa-whitelisting-implications-07
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Nov 2011 21:26:59 -0000

I'm not going to insist. I do think the title overstates the
scope of the document somewhat; it is not a complete guide
to transitioning content.

Regards
   Brian

On 2011-11-22 11:04, Livingood, Jason wrote:
> I'll be posting the -08 update tomorrow (list responses formally noting
> the feedback accepted to follow tomorrow). The only open question I see is
> on the title of the I-D - a question raised by Brian Carpenter below.
> 
> The current title is: Considerations for Transitioning Content to IPv6
> 
> Brian has proposed: Considerations for Content Provision during IPv4/IPv6
> Coexistence
> 
> I have not seen other objections to the title or any other feedback since
> Brian's email.
> 
> IMHO the current title is a bit simpler and I am inclined to keep it
> as-is, unless I hear feedback to the contrary here. But I'm open to
> whatever direction the WG wishes to go in.
> 
> - Jason
> 
> 
> 
> On 10/24/11 9:57 PM, "Brian E Carpenter" 
> wrote:
> 
>> I have a slight quibble with the revised title. I understand why the
>> title has been broadened, but it now claims a very wide scope:
>>  Considerations for Transitioning Content to IPv6
>>
>> How about:
>>  Considerations for Content Provision during IPv4/IPv6 Coexistence
> 
> 

From jouni.nospam@gmail.com  Tue Nov 22 13:27:47 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5925E1F0C47 for ; Tue, 22 Nov 2011 13:27:47 -0800 (PST)
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 VmLIZ9xt75dD for ; Tue, 22 Nov 2011 13:27:44 -0800 (PST)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id BD9E721F8AF5 for ; Tue, 22 Nov 2011 13:27:44 -0800 (PST)
Received: by ggnp4 with SMTP id p4so796508ggn.31 for ; Tue, 22 Nov 2011 13:27:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=QISfqV/14c7cgg5xWjwvS7RCDwfa6MflGsSvEIqWdeI=; b=q4yZT+kDj1H1iLpcrG9OA+QCbIHY0EIgDcw1RCJ+pwTofmNdqvhou5h6ra2cREKzDR ST345f7TwHWFOLqNYHagLhsO2MJleR2OMTTTfiE4zNKBxYD3L7NxMkN/XaoaIeR3V7Fc N2XpVJnO5kustrKFoNkI7ZyzCPpvK+cDCUCX4=
Received: by 10.152.104.236 with SMTP id gh12mr13119933lab.49.1321997264073; Tue, 22 Nov 2011 13:27:44 -0800 (PST)
Received: from a83-245-212-188.elisa-laajakaista.fi (a83-245-212-188.elisa-laajakaista.fi. [83.245.212.188]) by mx.google.com with ESMTPS id lq6sm13771426lab.16.2011.11.22.13.27.40 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 22 Nov 2011 13:27:42 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: jouni korhonen 
In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3035EED43@XMB-RCD-109.cisco.com>
Date: Tue, 22 Nov 2011 23:27:37 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20111122190508.3293.41916.idtracker@ietfa.amsl.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EED43@XMB-RCD-109.cisco.com>
To: Hemant Singh (shemant) 
X-Mailer: Apple Mail (2.1084)
Cc: v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-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: Tue, 22 Nov 2011 21:27:47 -0000

A question.. should RFC6204bis also apply to deployments where the CE =
WAN link is some sort of cellular link? If that is the case, then =
current Section 4.2 language may not fit to CEs that e.g. have a LTE =
radio as the WAN link. For example, WAA-3 and -4 seem to imply statefull =
DHCPv6 client for address configuration (IA_NA reference here), which =
would not possible e.g. for LTE. Also, WPD-1 alone would not be enough =
(cf draft-ietf-dhc-pd-exclude).

- Jouni


On Nov 22, 2011, at 10:05 PM, Hemant Singh (shemant) wrote:

> Folks who are reviewing 6rd sunsetting, please review section 4.4.3 of
> this new version of rfc6204bis, especially bullets 5 and 6 and the =
last
> paragraph of the section.  Others, please use the URL provided below =
to
> see a rfcdiff between the -03 and -02 versions.  The DS-Lite bullet
> DLW-4 has changed as per Carl's and Francois-Xavier Le Bail comments =
on
> this bullet.
>=20
> http://tinyurl.com/7rd7bkb
>=20
> Thanks to all for their comments thus far.
>=20
> Regards,
>=20
> Hemant
>=20
> -----Original Message-----
> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
> Of internet-drafts@ietf.org
> Sent: Tuesday, November 22, 2011 2:05 PM
> To: i-d-announce@ietf.org
> Cc: v6ops@ietf.org
> Subject: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
>=20
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the IPv6 Operations Working
> Group of the IETF.
>=20
> 	Title           : Basic Requirements for IPv6 Customer Edge
> Routers
> 	Author(s)       : Hemant Singh
>                          Wes Beebee
>                          Chris Donley
>                          Barbara Stark
>                          Ole Troan
> 	Filename        : draft-ietf-v6ops-6204bis-03.txt
> 	Pages           : 22
> 	Date            : 2011-11-22
>=20
>   This document specifies requirements for an IPv6 Customer Edge (CE)
>   router.  Specifically, the current version of this document focuses
>   on the basic provisioning of an IPv6 CE router and the provisioning
>   of IPv6 hosts attached to it.  The document also covers IP =
transition
>   technologies and transition technologies coexistence.  Two =
transition
>   technologies in RFC 5969's 6rd and RFC 6333's DS-Lite. are covered =
in
>   the document.
>=20
>=20
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-6204bis-03.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-v6ops-6204bis-03.txt
>=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 wbeebee@cisco.com  Tue Nov 22 13:41:43 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4D121F8B40 for ; Tue, 22 Nov 2011 13:41:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.103
X-Spam-Level: 
X-Spam-Status: No, score=-4.103 tagged_above=-999 required=5 tests=[AWL=0.429,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z6bkGs-IK3mw for ; Tue, 22 Nov 2011 13:41:42 -0800 (PST)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB5021F8B3F for ; Tue, 22 Nov 2011 13:41:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=619; q=dns/txt; s=iport; t=1321998102; x=1323207702; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=rKvFPd+9L+NfBPuWT1PUHbQJGRl8QyYPV4hdnB5+yDM=; b=BLdWNAANubB5klUyBBVuAimYiqqYE8X10E0XdJeyt+2rFGu+n/PFVa+q KHE9CpE1yQZQQAnLT+e6/5wL9gUJyIB2j2YUsDyoem4wziuMJdDFPnFrc jpNZh4jbU/G8rqbgkOemltkvpmBD3yZzrRlzhCdbDNofh8kkaZKnTRv8b 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApAGABEppk6tJXG9/2dsb2JhbACIZZV0AniIcItlkjSGGQSGUIlBhDiGa4Nw
X-IronPort-AV: E=Sophos;i="4.69,554,1315180800"; d="scan'208";a="35795462"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-9.cisco.com with ESMTP; 22 Nov 2011 21:41:42 +0000
Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id pAMLfgSJ008979;  Tue, 22 Nov 2011 21:41:42 GMT
Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 22 Nov 2011 15:41:41 -0600
Received: from 161.44.175.128 ([161.44.175.128]) by XMB-RCD-201.cisco.com ([72.163.62.208]) with Microsoft Exchange Server HTTP-DAV ;  Tue, 22 Nov 2011 21:41:41 +0000
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Tue, 22 Nov 2011 16:41:38 -0500
From: Wes Beebee 
To: jouni korhonen , "Hemant Singh   (shemant)" 
Message-ID: 
Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
Thread-Index: AcypX4N+CqQrDGHLjES7grUoz7z86A==
In-Reply-To: 
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 22 Nov 2011 21:41:41.0877 (UTC) FILETIME=[85CE2A50:01CCA95F]
Cc: v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-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: Tue, 22 Nov 2011 21:41:43 -0000

> A question.. should RFC6204bis also apply to deployments where the CE WAN link
> is some sort of cellular link? If that is the case, then current Section 4.2
> language may not fit to CEs that e.g. have a LTE radio as the WAN link. For
> example, WAA-3 and -4 seem to imply statefull DHCPv6 client for address
> configuration (IA_NA reference here), which would not possible e.g. for LTE.
> Also, WPD-1 alone would not be enough (cf draft-ietf-dhc-pd-exclude).

Just out of curiosity, how do you envision cellular networks get their
addresses?  Via SLAAC?  What about the PD used for tethered CPEs?

- Wes


From Ted.Lemon@nominum.com  Tue Nov 22 13:45:39 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB6E321F8B4E for ; Tue, 22 Nov 2011 13:45:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.575
X-Spam-Level: 
X-Spam-Status: No, score=-106.575 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 ayeg+ekOOl51 for ; Tue, 22 Nov 2011 13:45:39 -0800 (PST)
Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id C30E021F8B4D for ; Tue, 22 Nov 2011 13:45:38 -0800 (PST)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKTswYAheI6WHIhcooMsURuhWcWo11ok7d@postini.com; Tue, 22 Nov 2011 13:45:38 PST
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id CF5391B8281 for ; Tue, 22 Nov 2011 13:45:37 -0800 (PST)
Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 72F00190052; Tue, 22 Nov 2011 13:45:36 -0800 (PST) (envelope-from Ted.Lemon@nominum.com)
Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.01.0339.001; Tue, 22 Nov 2011 13:45:36 -0800
From: Ted Lemon 
To: Brian E Carpenter 
Thread-Topic: [v6ops] New Version Notification - draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-03.txt
Thread-Index: AQHMqVpe1l+S/BvDa0e/1SKfqnHqKpW584cA
Date: Tue, 22 Nov 2011 21:45:35 +0000
Message-ID: <682ABB42-2B62-43F5-B555-9B7C2AFE21EA@nominum.com>
References: <20111115062859.14026.74743.idtracker@ietfa.amsl.com>  <4ECACFF5.6020804@gmail.com>   <3D4D775D-E926-4F89-B279-75F0FE02B98F@nominum.com> <4ECC0E65.9060607@gmail.com>
In-Reply-To: <4ECC0E65.9060607@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.1.10]
Content-Type: multipart/alternative; boundary="_000_682ABB422B6243F5B5559B7C2AFE21EAnominumcom_"
MIME-Version: 1.0
Cc: "v6ops@ietf.org WG" , Wesley Eddy , Pete Resnick , "" , "ietfdbh@comcast.net Harrington" 
Subject: Re: [v6ops] New Version Notification - draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-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: Tue, 22 Nov 2011 21:45:39 -0000

--_000_682ABB422B6243F5B5559B7C2AFE21EAnominumcom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

On Nov 22, 2011, at 4:04 PM, Brian E Carpenter wrote:
Given that the IETF Last Call on this draft ended 2011-06-21,
there's been plenty of time to document the alternatives.

When something gets through IETF last call without objections being raised,=
 you can't claim that as a triumphant validation of what it says.   The fac=
t is that there are so many documents going through last call at this point=
, and being worked on, that no sane person can keep up with them all.   I w=
asn't even aware of this one until it came up  in Taiwan.

The fact is that we didn't properly solve the multihoming problem either in=
 RA or in DHCP.   Whether this document actually becomes an RFC or not, we =
need to actually solve the problem it tries to address, because it certainl=
y doesn't solve the problem.


--_000_682ABB422B6243F5B5559B7C2AFE21EAnominumcom_
Content-Type: text/html; charset="us-ascii"
Content-ID: <30894BAEA1FC14478F407496D862DCE7@nominum.com>
Content-Transfer-Encoding: quoted-printable









On Nov 22, 2011, at 4:04 PM, Brian E Carpenter wrote:


Given
 that the IETF Last Call on this draft ended 2011-06-21,

there's been plenty of time to document the alternatives.





When something gets through IETF last call without objections being ra=
ised, you can't claim that as a triumphant validation of what it says. &nbs=
p; The fact is that there are so many documents going through last call at =
this point, and being worked on, that
 no sane person can keep up with them all.   I wasn't even aware of th=
is one until it came up  in Taiwan.







The fact is that we didn't properly solve the multihoming problem eith=
er in RA or in DHCP.   Whether this document actually becomes an RFC o=
r not, we need to actually solve the problem it tries to address, because i=
t certainly doesn't solve the problem.









--_000_682ABB422B6243F5B5559B7C2AFE21EAnominumcom_--

From shemant@cisco.com  Tue Nov 22 13:46:17 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78FA31F0C5C for ; Tue, 22 Nov 2011 13:46:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.263
X-Spam-Level: 
X-Spam-Status: No, score=-6.263 tagged_above=-999 required=5 tests=[AWL=0.336,  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 pd8bB7e85Myk for ; Tue, 22 Nov 2011 13:46:17 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id DC8E91F0C5A for ; Tue, 22 Nov 2011 13:46:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=1208; q=dns/txt; s=iport; t=1321998377; x=1323207977; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=hN+rp1acV6WdcgcRiTlIkq1FDpLF0HGLYjHckTGxK/8=; b=b1h6dUvaxlc7K1zEvskq8iOl7ykv91NVM7puN7tbxcbXmcCFSvKDCNoP fEqn3aSXDQ4AcMyLJeYxj7obuidHAfdBaM9kqJmk2obxRy+F0O1jQKidy arOVL2fnzHZ0s3YyyisTQX8eaEyWWlnp+GuPQJoJpv+eAp/rlXiS8CDX0 g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApkAAHcXzE6tJXHA/2dsb2JhbABEmkSQGYEFgXIBAQEEEgEdCj8MBAIBCBEEAQELBhcBBgEgJQkIAQEEEwganiMBnjyJf2MEiByRb4UMh1M
X-IronPort-AV: E=Sophos;i="4.69,555,1315180800"; d="scan'208";a="38290761"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-2.cisco.com with ESMTP; 22 Nov 2011 21:46:16 +0000
Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id pAMLkGlH024304;  Tue, 22 Nov 2011 21:46:16 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 22 Nov 2011 15:46:15 -0600
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 22 Nov 2011 15:46:14 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3035EEDCA@XMB-RCD-109.cisco.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
Thread-Index: AcypXZaakzuWYQRTSE295Xc5nQqttAAAgBqA
References: <20111122190508.3293.41916.idtracker@ietfa.amsl.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EED43@XMB-RCD-109.cisco.com> 
From: "Hemant Singh (shemant)" 
To: "jouni korhonen" 
X-OriginalArrivalTime: 22 Nov 2011 21:46:15.0928 (UTC) FILETIME=[29270780:01CCA960]
Cc: v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-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: Tue, 22 Nov 2011 21:46:17 -0000

-----Original Message-----
From: jouni korhonen [mailto:jouni.nospam@gmail.com]=20
Sent: Tuesday, November 22, 2011 4:28 PM
To: Hemant Singh (shemant)
Cc: v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt


>A question.. should RFC6204bis also apply to deployments where the CE
WAN link is some sort of cellular link?=20

Certainly if the cellular link standards support RFC 3633 for IA_PD
acquisition.

>If that is the case, then current Section 4.2 language may not fit to
CEs that e.g. have a LTE radio as the WAN link. For example, WAA-3 and
-4 seem to imply >statefull DHCPv6 client for address configuration
(IA_NA reference here), which would not possible e.g. for LTE.

Note any cellular standard that mandates that the LTE acquire an IA_PD,
then the WAN of the LTE (the cellular link) has got to use stateful
DHCPv6 because acquiring the IA_PD is a stateful DHCPv6 operation.

>Also, WPD-1 alone would not be enough (cf draft-ietf-dhc-pd-exclude).

Agree.  However, the exclude document is not an RFC yet and thus the CPE
router document can't reference this work as a requirement. =20

Good to hear from you.

Thanks much.

Hemant





From jouni.nospam@gmail.com  Tue Nov 22 14:04:50 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3E4211E80C1 for ; Tue, 22 Nov 2011 14:04:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.572
X-Spam-Level: 
X-Spam-Status: No, score=-3.572 tagged_above=-999 required=5 tests=[AWL=0.027,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ehUsiVhnn3o2 for ; Tue, 22 Nov 2011 14:04:50 -0800 (PST)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4804C11E80B9 for ; Tue, 22 Nov 2011 14:04:50 -0800 (PST)
Received: by ghrr14 with SMTP id r14so796805ghr.31 for ; Tue, 22 Nov 2011 14:04:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=R/ylyR5xtvXnNufAc475OdLZ8OxR61Rx1BYOGQtJ0EI=; b=NHp/QXeqmmJLQdSW4rgod5uLXDHz1OoI4wh82zXnsrqw6EPLEiiWa4Zo5kZexCOqOZ wADMZAggaDEt/il9cJWQnue1z00usxZvsWU3m+0nLU5d0yLnZy60OVECDZ1uJ8WKjXzN HVSGovAMwS9C8S67VselsQ4pkt8dhCUq3k6P4=
Received: by 10.152.105.226 with SMTP id gp2mr12963536lab.28.1321999489284; Tue, 22 Nov 2011 14:04:49 -0800 (PST)
Received: from a83-245-212-188.elisa-laajakaista.fi (a83-245-212-188.elisa-laajakaista.fi. [83.245.212.188]) by mx.google.com with ESMTPS id pi7sm13878676lab.5.2011.11.22.14.04.47 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 22 Nov 2011 14:04:48 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: jouni korhonen 
In-Reply-To: 
Date: Wed, 23 Nov 2011 00:04:45 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <2D1C0BFF-C4ED-4AF5-8F29-0E4603C07FA0@gmail.com>
References: 
To: Wes Beebee 
X-Mailer: Apple Mail (2.1084)
Cc: v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-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: Tue, 22 Nov 2011 22:04:50 -0000

Wes,

On Nov 22, 2011, at 11:41 PM, Wes Beebee wrote:

>> A question.. should RFC6204bis also apply to deployments where the CE =
WAN link
>> is some sort of cellular link? If that is the case, then current =
Section 4.2
>> language may not fit to CEs that e.g. have a LTE radio as the WAN =
link. For
>> example, WAA-3 and -4 seem to imply statefull DHCPv6 client for =
address
>> configuration (IA_NA reference here), which would not possible e.g. =
for LTE.
>> Also, WPD-1 alone would not be enough (cf draft-ietf-dhc-pd-exclude).
>=20
> Just out of curiosity, how do you envision cellular networks get their
> addresses?  Via SLAAC?  What about the PD used for tethered CPEs?

I do not envision anything but the fact today is that only SLAAC is =
supported for the "WAN link". PD is in pipe for tethering but still the =
WAN side must do SLAAC for CE's own address. And to make life a bit =
harder the delegated prefix set and WAN link address must aggregate.

- Jouni



>=20
> - Wes
>=20


From shemant@cisco.com  Tue Nov 22 14:09:52 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C78F721F85AE for ; Tue, 22 Nov 2011 14:09:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.266
X-Spam-Level: 
X-Spam-Status: No, score=-6.266 tagged_above=-999 required=5 tests=[AWL=0.332,  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 jLQeuVUJ104k for ; Tue, 22 Nov 2011 14:09:50 -0800 (PST)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 5509921F85AA for ; Tue, 22 Nov 2011 14:09:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=8245; q=dns/txt; s=iport; t=1321999790; x=1323209390; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=sODtPTCSEhfCmMVcqrF7uKwd0d3x6vLC8aS7po1Uc/4=; b=Em/fGY110N9LYIfRMOlLiNktGtYOmt+Q5mhma5ROGMhUMRloBxuPCy99 C5AF35qEnCqIMmkPcBxe++I7/dhZWGD2nz1baW7R1C0OuVOrrpt7WXLKX kpgkgaeDCjIGR/slXDKNeQVLtnfUSx+kJ61uXl3PAshu/W8B8rBjCpxlk U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqUAAI8czE6tJXG9/2dsb2JhbABEgk2Xd4giAYd2gQWBcgEBAQQSAQkRA0kMBAIBCBEEAQELBhcBBgFFCQgBAQQBEggMDodrljIBnjuJf2MEiByRb4xf
X-IronPort-AV: E=Sophos;i="4.69,555,1315180800"; d="scan'208,217";a="38300679"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-6.cisco.com with ESMTP; 22 Nov 2011 22:09:50 +0000
Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id pAMM9nt2017747;  Tue, 22 Nov 2011 22:09:49 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 22 Nov 2011 16:09:49 -0600
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCA963.73B843CF"
Date: Tue, 22 Nov 2011 16:09:48 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3035EEDEB@XMB-RCD-109.cisco.com>
In-Reply-To: <8CA3E7F0-6A9C-45A1-955D-48D198178A44@viagenie.ca>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] 6rd Sunsetting
Thread-Index: AcypJlXGuVZKcqOcR1ayKKhQN4SpIQAPAing
References: <68DAB112-6E32-45FE-9AB7-A34E64898F60@cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C30354436E@XMB-RCD-109.cisco.com><750BF7861EBBE048B3E648B4BB6E8F4F20DC41F6@crexc50p><252D3DEA-FF09-42C8-959E-8A7205D9DE67@townsley.net><20111122133612.GH71280@Space.Net> <8CA3E7F0-6A9C-45A1-955D-48D198178A44@viagenie.ca>
From: "Hemant Singh (shemant)" 
To: "Marc Blanchet" , "Mark Townsley" 
X-OriginalArrivalTime: 22 Nov 2011 22:09:49.0834 (UTC) FILETIME=[73E7F6A0:01CCA963]
Cc: Alexandre Cassen , v6ops@ietf.org, Claire Cheng 
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 22 Nov 2011 22:09:52 -0000
X-List-Received-Date: Tue, 22 Nov 2011 22:09:52 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CCA963.73B843CF
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

=20

-----Original Message-----
From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
Of Marc Blanchet
Sent: Tuesday, November 22, 2011 9:51 AM
To: Mark Townsley
Cc: Alexandre Cassen; v6ops@ietf.org; Claire Cheng
Subject: Re: [v6ops] 6rd Sunsetting

=20

>I think that (source routing) is the only way to do it right.

=20

Before even the townsley document was out, the ipv6 cpe router design
team in the -02 version of the document had already specified source
based switching in the CE if 6rd and native IPv6 use different prefixes.
In our design mailer we had also specified in earlier text before -02
was released to prefer native IPv6 over 6rd when both are active and
using the same prefix but we thought this was an obvious case and didn't
add text for the case in the -02 version.  However seeing that the same
prefix case is preferred by the community to specify, we added the text
for even this case to the -03 version.  This is bullet 5 from section
4.4.3 of=20

=20

http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-03

=20

=20

[5.  Selection of 6rd tunnel or native IPv6 output interface on the CE

       router is determined by the source IPv6 address of the packet

       from a host, when different prefixes are available over 6rd vs.

       native IPv6.  If the two interfaces provide the CE router with

       the same prefix, then the CE router prefers the native IPv6

       interface to the 6rd interface for forwarding traffic out the WAN

       when both 6rd and native IPv6 interfaces are active.]

=20

Please also read the whole section of 4.4.3.

=20

Thanks and regards,

=20

Hemant


------_=_NextPart_001_01CCA963.73B843CF
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


 
-----Original Message-----
From: v6ops-bounces@ietf.org =
[mailto:v6ops-bounces@ietf.org] On Behalf Of Marc Blanchet
Sent: =
Tuesday, November 22, 2011 9:51 AM
To: Mark Townsley
Cc: Alexandre =
Cassen; v6ops@ietf.org; Claire Cheng
Subject: Re: [v6ops] 6rd =
Sunsetting
 
>I =
think that (source routing) is the only way to do it =
right.
 
Before =
even the townsley document was out, the ipv6 cpe router design team in =
the -02 version of the document had already specified source based =
switching in the CE if 6rd and native IPv6 use different prefixes.  =
In our design mailer we had also specified in earlier text before -02 =
was released to prefer native IPv6 over 6rd when both are active and =
using the same prefix but we thought this was an obvious case and didn't =
add text for the case in the -02 version.  However seeing that the =
same prefix case is preferred by the community to specify, we added the =
text for even this case to the -03 version.  This is bullet 5 from =
section 4.4.3 of 
 
http://to=
ols.ietf.org/html/draft-ietf-v6ops-6204bis-03
 
 
[5.  Selection of 6rd tunnel or native IPv6 =
output interface on the CE
       router is =
determined by the source IPv6 address of the =
packet
       from a host, when =
different prefixes are available over 6rd vs.
       native =
IPv6.  If the two interfaces provide the CE router =
with
       the same prefix, =
then the CE router prefers the native IPv6
       interface to the =
6rd interface for forwarding traffic out the WAN
       when both 6rd and =
native IPv6 interfaces are active.]
 
Please also read the whole section =
of 4.4.3.
 
Thanks and regards,
 
Hemant

------_=_NextPart_001_01CCA963.73B843CF--

From jouni.nospam@gmail.com  Tue Nov 22 14:11:04 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF8411E80DA for ; Tue, 22 Nov 2011 14:11:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.574
X-Spam-Level: 
X-Spam-Status: No, score=-3.574 tagged_above=-999 required=5 tests=[AWL=0.025,  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 eJnEt2IL7nEC for ; Tue, 22 Nov 2011 14:11:03 -0800 (PST)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id CA03D11E80B9 for ; Tue, 22 Nov 2011 14:11:03 -0800 (PST)
Received: by ywt34 with SMTP id 34so791991ywt.31 for ; Tue, 22 Nov 2011 14:11:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=5bFxAJpGHc45J9ivobOHq7XvPrPdiKuL8H5zeP09O8Q=; b=CXdsTXL2IiWdLepq3omABAsljS0C3skTPzcLrFny03i2PN4ZChTtbrWkj0nR5OqeqZ rmmC9D094yPL+KEWTtx01ECXhR5cST5naJ3adxIFl4qb6lYjYVRkUckh+6qNGB3wd1bY ZRVa9JhwKG2YEHrQCy4Ijn0DSNhWm6webVCA8=
Received: by 10.152.123.144 with SMTP id ma16mr13187842lab.32.1321999862639; Tue, 22 Nov 2011 14:11:02 -0800 (PST)
Received: from a83-245-212-188.elisa-laajakaista.fi (a83-245-212-188.elisa-laajakaista.fi. [83.245.212.188]) by mx.google.com with ESMTPS id hr17sm13869778lab.12.2011.11.22.14.11.00 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 22 Nov 2011 14:11:01 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: jouni korhonen 
In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3035EEDCA@XMB-RCD-109.cisco.com>
Date: Wed, 23 Nov 2011 00:10:58 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20111122190508.3293.41916.idtracker@ietfa.amsl.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EED43@XMB-RCD-109.cisco.com>  <5B6B2B64C9FE2A489045EEEADDAFF2C3035EEDCA@XMB-RCD-109.cisco.com>
To: Hemant Singh (shemant) 
X-Mailer: Apple Mail (2.1084)
Cc: v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-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: Tue, 22 Nov 2011 22:11:04 -0000

Hi Hemant,

On Nov 22, 2011, at 11:46 PM, Hemant Singh (shemant) wrote:

>=20
>=20
> -----Original Message-----
> From: jouni korhonen [mailto:jouni.nospam@gmail.com]=20
> Sent: Tuesday, November 22, 2011 4:28 PM
> To: Hemant Singh (shemant)
> Cc: v6ops@ietf.org
> Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
>=20
>=20
>> A question.. should RFC6204bis also apply to deployments where the CE
> WAN link is some sort of cellular link?=20
>=20
> Certainly if the cellular link standards support RFC 3633 for IA_PD
> acquisition.

Ok. Good.

>=20
>> If that is the case, then current Section 4.2 language may not fit to
> CEs that e.g. have a LTE radio as the WAN link. For example, WAA-3 and
> -4 seem to imply >statefull DHCPv6 client for address configuration
> (IA_NA reference here), which would not possible e.g. for LTE.
>=20
> Note any cellular standard that mandates that the LTE acquire an =
IA_PD,
> then the WAN of the LTE (the cellular link) has got to use stateful
> DHCPv6 because acquiring the IA_PD is a stateful DHCPv6 operation.

That is understood. However, WAA-4 has a MUST for IA_NA, which is out of =
question (in case of WCDMA and LTE).

>> Also, WPD-1 alone would not be enough (cf draft-ietf-dhc-pd-exclude).
>=20
> Agree.  However, the exclude document is not an RFC yet and thus the =
CPE
> router document can't reference this work as a requirement.

Ok. The I-D has been sent to IESG, so maybe it gets out before =
RFC6204bis does.

- Jouni


>=20
> Good to hear from you.
>=20
> Thanks much.
>=20
> Hemant
>=20
>=20
>=20
>=20


From shemant@cisco.com  Tue Nov 22 14:14:05 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C32BA11E80DA for ; Tue, 22 Nov 2011 14:14:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.269
X-Spam-Level: 
X-Spam-Status: No, score=-6.269 tagged_above=-999 required=5 tests=[AWL=0.330,  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 GVByqp8iMdvp for ; Tue, 22 Nov 2011 14:14:05 -0800 (PST)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 40C8311E80DF for ; Tue, 22 Nov 2011 14:14:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=989; q=dns/txt; s=iport; t=1322000045; x=1323209645; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=sIdHmIQh2K549KbFCRmUFdrh/BEUaW+bJSLCuHx3kaE=; b=WyK18hs6VmluuKvUT1PFAzz8anjZUPbVDN+HgKuXM/pvplcS2/IkgUof 3RJS8l+VKvzJAZ/lT89AN1KkVjchEM58qGWDQnfiB3Xxgt5kCXH0SeuE9 Lj1qjcckEFY3LGDPX3olzj8KahH0/kSnJkxlSe+PfaHl0QpjISJ0QB51D Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApkAANwdzE6tJV2b/2dsb2JhbABEmkWQGYEFgXIBAQEEEgEdCj8MBAIBCBEEAQELBhcBBgEgJQkIAQEEARIIEQmeGgGeO4l/YwSIHJFvhQyHUw
X-IronPort-AV: E=Sophos;i="4.69,555,1315180800"; d="scan'208";a="38313885"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 22 Nov 2011 22:14:04 +0000
Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pAMME4PF005824;  Tue, 22 Nov 2011 22:14:04 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 22 Nov 2011 16:14:01 -0600
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 22 Nov 2011 16:14:00 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3035EEDF4@XMB-RCD-109.cisco.com>
In-Reply-To: <2D1C0BFF-C4ED-4AF5-8F29-0E4603C07FA0@gmail.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
Thread-Index: AcypYsFDI4dnp4EnQXCk1QUhPU/znAAAO4QQ
References:  <2D1C0BFF-C4ED-4AF5-8F29-0E4603C07FA0@gmail.com>
From: "Hemant Singh (shemant)" 
To: "jouni korhonen" , "Wes Beebee (wbeebee)" 
X-OriginalArrivalTime: 22 Nov 2011 22:14:01.0571 (UTC) FILETIME=[09F3FB30:01CCA964]
Cc: v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-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: Tue, 22 Nov 2011 22:14:05 -0000

-----Original Message-----
From: jouni korhonen [mailto:jouni.nospam@gmail.com]=20
Sent: Tuesday, November 22, 2011 5:05 PM
To: Wes Beebee (wbeebee)
Cc: Hemant Singh (shemant); v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt

>I do not envision anything but the fact today is that only SLAAC is
supported for the "WAN link". PD is in pipe for tethering but still >the
WAN side must do SLAAC for CE's own address. And to make life a bit
harder the delegated prefix set and WAN link address must >aggregate.

If one does not use the exclude DHC mechanism, then rfc6204 already
specifies use of an unnumbered WAN (WAN has only an IPv6 link-local
address) and then the WAN initiates DHCPv6 for the IA_PD. Once the WAN
acquires the IA_PD, the WAN can use one /128 from this IA_PD prefix and
then delegate the prefix to the LAN segment which would be the tethered
client on the LTE.  The /128 is used to source packets from the WAN.

Hemant

From shemant@cisco.com  Tue Nov 22 14:17:00 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA4211E80DA for ; Tue, 22 Nov 2011 14:17:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.272
X-Spam-Level: 
X-Spam-Status: No, score=-6.272 tagged_above=-999 required=5 tests=[AWL=0.327,  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 pe6-UbcwDtkh for ; Tue, 22 Nov 2011 14:16:59 -0800 (PST)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 5F59E11E80B9 for ; Tue, 22 Nov 2011 14:16:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=553; q=dns/txt; s=iport; t=1322000219; x=1323209819; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=iC2gS10u9vjglC4OLQN8ksLrLWFQrWh2y8K3X2WpgfI=; b=RehWglsc9fiKk6n1tnjRm4pf6flO36w2khBylbqOcshsjGmTl0+9A7N2 kc2bvzmvkZhVVlP/tTaF6Jx+2ORSyWH+na881jZ5CrVkvDsGgvNV6D8ke 2SovujBxU41zFGVznffXbmO6+wYG6z3HNPtSWRe6/A57jGRYpFgyvkwZC c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApkAAJ0ezE6tJXG//2dsb2JhbABEmkWQGYEFgXIBAQEEEgEdCj8MBAIBCBEEAQELBhcBBgEgJQkIAQEEEwgSCJ4aAZ47iX9jBIgckW+FDIdT
X-IronPort-AV: E=Sophos;i="4.69,555,1315180800"; d="scan'208";a="38310780"
Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-5.cisco.com with ESMTP; 22 Nov 2011 22:16:59 +0000
Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id pAMMGwb8010641;  Tue, 22 Nov 2011 22:16:58 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 22 Nov 2011 16:16:58 -0600
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 22 Nov 2011 16:16:58 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3035EEDF8@XMB-RCD-109.cisco.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
Thread-Index: AcypY5/7HBiviHVCSPGoFtkgfTme0gAAKN+w
References: <20111122190508.3293.41916.idtracker@ietfa.amsl.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EED43@XMB-RCD-109.cisco.com>  <5B6B2B64C9FE2A489045EEEADDAFF2C3035EEDCA@XMB-RCD-109.cisco.com> 
From: "Hemant Singh (shemant)" 
To: "jouni korhonen" 
X-OriginalArrivalTime: 22 Nov 2011 22:16:58.0815 (UTC) FILETIME=[739944F0:01CCA964]
Cc: v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-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: Tue, 22 Nov 2011 22:17:00 -0000

-----Original Message-----
From: jouni korhonen [mailto:jouni.nospam@gmail.com]=20
Sent: Tuesday, November 22, 2011 5:11 PM
To: Hemant Singh (shemant)
Cc: v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt


>Ok. The I-D has been sent to IESG, so maybe it gets out before
RFC6204bis does.

This is great news!  Certainly then I and Wes can look into a new
dhc-exclude bullet in rfc6204bis to cater to the cellular LTE case.  Or
if you can propose some text, that would be great as well.

Cheers,

Hemant

From wbeebee@cisco.com  Tue Nov 22 14:20:13 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BE9611E80E4 for ; Tue, 22 Nov 2011 14:20:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.136
X-Spam-Level: 
X-Spam-Status: No, score=-4.136 tagged_above=-999 required=5 tests=[AWL=0.396,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MdELfB9n31Hu for ; Tue, 22 Nov 2011 14:20:12 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id C636511E80B9 for ; Tue, 22 Nov 2011 14:20:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wbeebee@cisco.com; l=344; q=dns/txt; s=iport; t=1322000413; x=1323210013; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=Bj1reY7I1CP+7WoeTtWqwiliQWXm2dxbGcemgsEBAzY=; b=Im+RlfFpoFAJ5qivlJmjK0U2lz8MQCI3WRac2FWAUXnXyZqntIGPVO1V LDHMB+J7KDRnRkHYm4i5mKWE0naruucdUJmwmgJMiMFrBuqhHy4D71TTZ KK1Cvm/2G49S5wY0J9jMU0qPWtEoW2bG7ri3hiGDNghLbIAU/KeiGKVBJ g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AnEFAIwfzE6tJXG//2dsb2JhbABEiUmhEwKBBYFyAQEBAwESAScCATwFDQEIgR0BAQQBDSeHY5Y6AZ47imIEiByMJ4VIiC2EMQ
X-IronPort-AV: E=Sophos;i="4.69,555,1315180800"; d="scan'208";a="38299320"
Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-2.cisco.com with ESMTP; 22 Nov 2011 22:20:12 +0000
Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id pAMMKCg5011796;  Tue, 22 Nov 2011 22:20:12 GMT
Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 22 Nov 2011 16:20:12 -0600
Received: from 161.44.175.128 ([161.44.175.128]) by XMB-RCD-201.cisco.com ([72.163.62.208]) with Microsoft Exchange Server HTTP-DAV ;  Tue, 22 Nov 2011 22:20:11 +0000
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Tue, 22 Nov 2011 17:20:09 -0500
From: Wes Beebee 
To: jouni korhonen , "Hemant Singh   (shemant)" 
Message-ID: 
Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
Thread-Index: AcypZOT1ccsBPfIitk+UTLS2Pmj/Zg==
In-Reply-To: 
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 22 Nov 2011 22:20:12.0183 (UTC) FILETIME=[E6DAE270:01CCA964]
Cc: v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-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: Tue, 22 Nov 2011 22:20:13 -0000

> That is understood. However, WAA-4 has a MUST for IA_NA, which is out of
> question (in case of WCDMA and LTE).

The capability MUST be there, however we do not go so far as to say that it
MUST always request (or receive) an IA_NA.  The CE router WAN supports
unnumbered operation in addition to numbered operation, of course.

- Wes


From jouni.nospam@gmail.com  Tue Nov 22 14:30:56 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5097E11E80F3 for ; Tue, 22 Nov 2011 14:30:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.576
X-Spam-Level: 
X-Spam-Status: No, score=-3.576 tagged_above=-999 required=5 tests=[AWL=0.023,  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 1XXXFTlg4Y-e for ; Tue, 22 Nov 2011 14:30:55 -0800 (PST)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id C704011E80F2 for ; Tue, 22 Nov 2011 14:30:55 -0800 (PST)
Received: by ggnp4 with SMTP id p4so854999ggn.31 for ; Tue, 22 Nov 2011 14:30:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=RKrT9KVfdQ0xlwFlnaJZIrHmhUViJzXHlJP8687mMd8=; b=kRoyBX3VcxUG100BhJGUpjpY3EDiPyajd6bVclRYo5epx0YK4iLihs9PzXUbtKCj7R 4Pm3u8ckaPW8enuTOrwDhNI+lYbZfi+FB+dxMgoZgrrHVhaf+Bu60/ECO3c3MXmTj/zO V3RL7zMj3KJYTBDzl+QxAY/nytMs0dwwY0SKU=
Received: by 10.152.109.33 with SMTP id hp1mr13033569lab.36.1322001053709; Tue, 22 Nov 2011 14:30:53 -0800 (PST)
Received: from a83-245-212-188.elisa-laajakaista.fi (a83-245-212-188.elisa-laajakaista.fi. [83.245.212.188]) by mx.google.com with ESMTPS id pc8sm13920929lab.8.2011.11.22.14.30.50 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 22 Nov 2011 14:30:51 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: jouni korhonen 
In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3035EEDF4@XMB-RCD-109.cisco.com>
Date: Wed, 23 Nov 2011 00:30:49 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <580F21C3-AFB3-4F8D-95F1-202B031CADB7@gmail.com>
References:  <2D1C0BFF-C4ED-4AF5-8F29-0E4603C07FA0@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EEDF4@XMB-RCD-109.cisco.com>
To: "Hemant Singh (shemant)" 
X-Mailer: Apple Mail (2.1084)
Cc: v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-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: Tue, 22 Nov 2011 22:30:56 -0000

Hemant,

On Nov 23, 2011, at 12:14 AM, Hemant Singh (shemant) wrote:

>=20
> -----Original Message-----
> From: jouni korhonen [mailto:jouni.nospam@gmail.com]=20
> Sent: Tuesday, November 22, 2011 5:05 PM
> To: Wes Beebee (wbeebee)
> Cc: Hemant Singh (shemant); v6ops@ietf.org
> Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
>=20
>> I do not envision anything but the fact today is that only SLAAC is
>> supported for the "WAN link". PD is in pipe for tethering but still =
>the
>> WAN side must do SLAAC for CE's own address. And to make life a bit
>> harder the delegated prefix set and WAN link address must >aggregate.
>>=20
> If one does not use the exclude DHC mechanism, then rfc6204 already
> specifies use of an unnumbered WAN (WAN has only an IPv6 link-local
> address) and then the WAN initiates DHCPv6 for the IA_PD. Once the WAN
> acquires the IA_PD, the WAN can use one /128 from this IA_PD prefix =
and
> then delegate the prefix to the LAN segment which would be the =
tethered
> client on the LTE.  The /128 is used to source packets from the WAN.

Hmm.. I need to think some text changes/clarifications here, since =
assuming anything related to unnumbered WAN does not work either.

- Jouni


>=20
> Hemant


From jouni.nospam@gmail.com  Tue Nov 22 14:35:59 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22AB11F0C6F for ; Tue, 22 Nov 2011 14:35:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.578
X-Spam-Level: 
X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[AWL=0.021,  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 e4vOvjV21WmS for ; Tue, 22 Nov 2011 14:35:58 -0800 (PST)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9330A1F0C69 for ; Tue, 22 Nov 2011 14:35:58 -0800 (PST)
Received: by ghrr14 with SMTP id r14so823762ghr.31 for ; Tue, 22 Nov 2011 14:35:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=Y8PntnFngLl/uS4KBS28MDZiamgMzW9MDyquH5ylk7k=; b=CN+us/W7xQNXsNYFkbQSqKC2fHuonaOXHeb15evLLhNEuxoB8qrMO4+xrhXwezLTWt /AiwLnP4Loc61BlhBKp0N+BOYBf1CwYcyYeW9yn8Be1ekQi6YfYRIh5To2J+hUGUGUlL ewHl6xzUcu0e1fQS1WMyTMYVhCbI+T24ZzxUM=
Received: by 10.152.102.138 with SMTP id fo10mr13210386lab.44.1322001357648; Tue, 22 Nov 2011 14:35:57 -0800 (PST)
Received: from a83-245-212-188.elisa-laajakaista.fi (a83-245-212-188.elisa-laajakaista.fi. [83.245.212.188]) by mx.google.com with ESMTPS id lq6sm13907326lab.16.2011.11.22.14.35.55 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 22 Nov 2011 14:35:56 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: jouni korhonen 
In-Reply-To: 
Date: Wed, 23 Nov 2011 00:35:50 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <839139B6-37C1-4C74-825B-F62061E96E78@gmail.com>
References: 
To: Wes Beebee 
X-Mailer: Apple Mail (2.1084)
Cc: v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-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: Tue, 22 Nov 2011 22:35:59 -0000

Wes,

On Nov 23, 2011, at 12:20 AM, Wes Beebee wrote:

>> That is understood. However, WAA-4 has a MUST for IA_NA, which is out =
of
>> question (in case of WCDMA and LTE).
>=20
> The capability MUST be there, however we do not go so far as to say =
that it
> MUST always request (or receive) an IA_NA.  The CE router WAN supports
> unnumbered operation in addition to numbered operation, of course.

I still think WAA-4 needs some clarification here. The issue being: WAN =
does not support unnumbered operation, it does not support IA_NA either =
but does support IA_PD. Therefore, a MUST for IA_NA needs somehow be =
conditioned.

- Jouni

>=20
> - Wes
>=20


From john.mann@monash.edu  Tue Nov 22 16:02:05 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7A961F0C69 for ; Tue, 22 Nov 2011 16:02:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.876
X-Spam-Level: 
X-Spam-Status: No, score=-5.876 tagged_above=-999 required=5 tests=[AWL=0.100,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_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 pCs1BKmRtS0U for ; Tue, 22 Nov 2011 16:02:05 -0800 (PST)
Received: from na3sys009aog105.obsmtp.com (na3sys009aog105.obsmtp.com [74.125.149.75]) by ietfa.amsl.com (Postfix) with ESMTP id C66911F0C51 for ; Tue, 22 Nov 2011 16:02:04 -0800 (PST)
Received: from mail-qy0-f182.google.com ([209.85.216.182]) (using TLSv1) by na3sys009aob105.postini.com ([74.125.148.12]) with SMTP ID DSNKTsw36C4CPLiCCzXpc8oBZGMjuef1be9t@postini.com; Tue, 22 Nov 2011 16:02:04 PST
Received: by mail-qy0-f182.google.com with SMTP id 36so828356qyg.41 for ; Tue, 22 Nov 2011 16:01:44 -0800 (PST)
Received: by 10.182.145.38 with SMTP id sr6mr7182924obb.65.1322006504202; Tue, 22 Nov 2011 16:01:44 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.16.106 with HTTP; Tue, 22 Nov 2011 16:01:23 -0800 (PST)
In-Reply-To: 
References:  
From: John Mann 
Date: Wed, 23 Nov 2011 11:01:23 +1100
Message-ID: 
To: "Livingood, Jason" 
Content-Type: multipart/alternative; boundary=f46d0447f08012dffa04b25ba0dd
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] Update of draft-ietf-v6ops-v6-aaaa-whitelisting-implications-07
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 23 Nov 2011 00:02:05 -0000

--f46d0447f08012dffa04b25ba0dd
Content-Type: text/plain; charset=ISO-8859-1

Hi,

These comments apply to both -07 and -08

As for the title being over-reaching, you could soften it by changing it
from
   Considerations for Transitioning Content to IPv6
to
   Some Considerations for Transitioning Content to IPv6
;-)

---

3.  IPv6 Adoption Implications

---
Can you split the first paragraph into separate ideas e.g. at "A
substantial delay"

Also perhaps add something like
    Over time, there should be more IPv6-capable users and per-user traffic
should increase.
    Delaying (the start of) migration of content will mean that when it
does happen the Section 2.2 Volume-Based Concerns will be larger.

---

4.3.1.  How DNS Resolver Whitelisting Works

   ...  In the case of DNS Resolver

   Whitelisting, the resource that an end user seeks is a name, not an
   IP address or IP address family.  Thus, an end user is seeking a name
   such as www.example.com, without regard to the underlying IP address
   family (IPv4 or IPv6) which may be used to access that resource.

---
I think this is a bit wrong.
A user doesn't seek a "name", they seek a Internet host/service with a
particular name.

---
4.3.1.1

   1.  The authoritative DNS server for example.com receives DNS queries
       for the A (IPv4) and/or AAAA (IPv6) address resource records for
       the Fully Qualified Domain Name (FQDN) www.example.com, for which
       AAAA (IPv6) resource records exist.



   2.  The authoritative DNS server checks the IP address (IPv4, IPv6,
       or both) of the DNS recursive resolver sending the AAAA (IPv6)
       query against the whitelist that is the DNS Whitelist.

---
Step 1 is for A and/or AAAA queries, but step 2 is only for AAAA queries ??

The server does not know all the addresses of the resolver, only the
address used by the query packet.
Also  whitelist ... Whitelist.

    2. The authoritative DNS server checks the source IP address (IPv4 or
IPv6) of the DNS query packet
    from the DNS recursive resolver against the whitelist.

---

6.2.  Privacy Considerations

----
No mention is made here of recursive resolvers.

Questions for whole mailing list, and my view:

Are recursive resolver IP addresses privacy sensitive?
Not much since these addresses are visible on packets flowing across the
open Internet.

Can content providers share recursive resolver white/blacklists?
Probably, since it can improve the Internet without exposing information
widely.
Tricky due to responsibility / liability issues.

Should the general public not/be allowed to discover if a recursive
resolver is on a white/blacklist (as discussed in 4.4 for e-mail
blacklists)?
Probably, but extra work for content providers.

Should netblock owners be allowed to discover if recursive resolvers in
their address range are on a list?
Definitely

Thanks,
    John

--f46d0447f08012dffa04b25ba0dd
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,

These comments apply to both -07 and -08
<=
br>
As for the title being over-reaching, you could soften it by chang=
ing it from
=A0 =A0Considerations for Transitioning Content to IPv6
t=
o


=A0 =A0Some Considerations for Transitioning Content to IPv6
;-)

---


3.  IPv6 Adoption Implications

---
Can you split the first paragraph into separate ideas e.=
g. at "A substantial delay"


Also perhaps add something like
=A0 =A0 Over time,=
 there should be more IPv6-capable users and per-user traffic should increa=
se.
=A0 =A0 Delaying (the start of) migration of content=A0will m=
ean that when it does happen the Section 2.2 Volume-Based Concerns will be =
larger.




---


4.3.1.  How DNS Resolver Whitelisting Works

   ...  In the case of DNS Resolver
   Whitelisting, the resource that an end user seeks is a name, not an
   IP address or IP address family.  Thus, an end user is seeking a name
   such as www.example.com, without =
regard to the underlying IP address
   family (IPv4 or IPv6) which may be used to access that resource.

---
I think this is a bit wrong.
A use=
r doesn't seek a "name", they seek a Internet host/service wi=
th a particular name.

---
4.3.1.1



   1.  The authoritative DNS se=
rver for example.com receives DNS querie=
s
       for the A (IPv4) and/or AAAA (IPv6) address resource records for
       the Fully Qualified Domain Name (FQDN) www.example.com, for which
       AAAA (IPv6) resource records exist.



   2.  The authoritative DNS server checks the IP address (IPv4, IPv6,
       or both) of the DNS recursive resolver sending the AAAA (IPv6)
       query against the whitelist that is the DNS Whitelist.

---
Step 1 is for A and/or AAAA queries, but ste=
p 2 is only for AAAA queries ??

The server does no=
t know all the addresses of the resolver, only the address used by the quer=
y packet.



Also =A0whitelist ... Whitelist.

=A0 =A0 2. T=
he authoritative DNS server checks the source IP address (IPv4 or IPv6) of =
the DNS query packet
=A0 =A0 from the DNS recursive resolver agai=
nst the whitelist.




---


6.2.  Privacy Considerations


----
No mention is made here of recursive resolvers.<=
/div>

Questions for whole mailing list, and my view:

Are recursive resolver IP addresses privacy sensitive=
?



Not much since these addresses are visible on packets flowing across t=
he open Internet.

Can content providers share recu=
rsive resolver white/blacklists?
Probably, since it can improve t=
he Internet without exposing information widely.



Tricky due to responsibility / liability issues.

<=
div>Should the general public not/be allowed to discover if a recursive res=
olver is on a white/blacklist (as discussed in 4.4 for e-mail blacklists)?<=
/div>


Probably, but extra work for content providers.

Should netblock owners be allowed to discover if recursive resolvers in =
their address range are on a list?
Definitely




Thanks,
=A0 =A0 John


--f46d0447f08012dffa04b25ba0dd--

From bs7652@att.com  Tue Nov 22 16:16:39 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A3A911E80C8 for ; Tue, 22 Nov 2011 16:16:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.448
X-Spam-Level: 
X-Spam-Status: No, score=-106.448 tagged_above=-999 required=5 tests=[AWL=0.151, 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 KH5yb3rH5aAX for ; Tue, 22 Nov 2011 16:16:38 -0800 (PST)
Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id 9161C11E80BA for ; Tue, 22 Nov 2011 16:16:38 -0800 (PST)
X-Env-Sender: bs7652@att.com
X-Msg-Ref: server-4.tower-119.messagelabs.com!1322007396!2409774!1
X-Originating-IP: [144.160.20.146]
X-StarScan-Version: 6.3.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11303 invoked from network); 23 Nov 2011 00:16:37 -0000
Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-4.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 23 Nov 2011 00:16:37 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pAN0FAlC024233; Tue, 22 Nov 2011 19:15:11 -0500
Received: from 01AL10015010625.AD.BLS.COM (sfldmibbcraeninet1-v2.pmtr.mwst.att.com [10.231.16.33]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pAN0F37e024149; Tue, 22 Nov 2011 19:15:03 -0500
Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01AL10015010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 22 Nov 2011 18:15:39 -0600
Received: from 01NC27689010650.AD.BLS.COM ([90.144.44.120]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 22 Nov 2011 19:15:39 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 22 Nov 2011 19:16:26 -0500
Message-ID: <750BF7861EBBE048B3E648B4BB6E8F4F20EA14A5@crexc50p>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
Thread-Index: AcypXX65h/vTNDj5Sv2+XwPtjsFZ1AAE4MQQ
References: <20111122190508.3293.41916.idtracker@ietfa.amsl.com><5B6B2B64C9FE2A489045EEEADDAFF2C3035EED43@XMB-RCD-109.cisco.com> 
From: "STARK, BARBARA H" 
To: "jouni korhonen" , "Hemant Singh" 
X-OriginalArrivalTime: 23 Nov 2011 00:15:39.0293 (UTC) FILETIME=[07BBFCD0:01CCA975]
Cc: v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-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, 23 Nov 2011 00:16:39 -0000

> A question.. should RFC6204bis also apply to deployments where the CE
> WAN link is some sort of cellular link? If that is the case, then
> current Section 4.2 language may not fit to CEs that e.g. have a LTE
> radio as the WAN link. For example, WAA-3 and -4 seem to imply
> statefull DHCPv6 client for address configuration (IA_NA reference
> here), which would not possible e.g. for LTE. Also, WPD-1 alone would
> not be enough (cf draft-ietf-dhc-pd-exclude).

IMO, any WAN links that are not supported by the current requirements,
are not supported, and support should not be added.

IMO, there's a whole lot more to supporting LTE connections than just
dhc-pd-exclude. Just based on the little I know, I would guess at least
a year's worth of arguing over functionality, with a need for other new
functionality beyond just dhc-pd-exclude. That is, if you really want to
make consumers happy about a CE router with a 3GPP-defined WAN
connection.

But, again, that's just my opinion.=20
Barbara

From brian.e.carpenter@gmail.com  Tue Nov 22 16:27:53 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFE2811E80BA for ; Tue, 22 Nov 2011 16:27:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.547
X-Spam-Level: 
X-Spam-Status: No, score=-103.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X1l+pXg2aYZR for ; Tue, 22 Nov 2011 16:27:53 -0800 (PST)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 238F711E8098 for ; Tue, 22 Nov 2011 16:27:52 -0800 (PST)
Received: by vbbez10 with SMTP id ez10so952067vbb.31 for ; Tue, 22 Nov 2011 16:27:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=UG4v7+rEAksFmgRcylpwaB3o5baGdCDCI+eb7oj0iWQ=; b=QGCewBVRSnm/fI7JieQxiu6tbqCBcjvs8ySTRL3+uloEIWJr+6rQ4+mB0YoiXYGy2v XMtOT9tp4L2k7qng1PFuXVs4KyCfFiR2YOSXwCax7sXS1vO3nB3pJS7xzwhTJHBUEI53 Mx94LCjYtlY4ER+QATdnthoFzk7OHO7zXt3UY=
Received: by 10.52.22.170 with SMTP id e10mr22708824vdf.75.1322008072549; Tue, 22 Nov 2011 16:27:52 -0800 (PST)
Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id k4sm21096615vdu.2.2011.11.22.16.27.48 (version=SSLv3 cipher=OTHER); Tue, 22 Nov 2011 16:27:51 -0800 (PST)
Message-ID: <4ECC3E0C.4000503@gmail.com>
Date: Wed, 23 Nov 2011 13:27:56 +1300
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Ted Lemon 
References: <20111115062859.14026.74743.idtracker@ietfa.amsl.com>  <4ECACFF5.6020804@gmail.com>   <3D4D775D-E926-4F89-B279-75F0FE02B98F@nominum.com> <4ECC0E65.9060607@gmail.com> <682ABB42-2B62-43F5-B555-9B7C2AFE21EA@nominum.com>
In-Reply-To: <682ABB42-2B62-43F5-B555-9B7C2AFE21EA@nominum.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: "v6ops@ietf.org WG" , Wesley Eddy , Pete Resnick , "" , "ietfdbh@comcast.net Harrington" 
Subject: [v6ops] AD alert: New Version Notification - draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-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, 23 Nov 2011 00:27:53 -0000

Ted,

Understood, and I was very late tuning into MIF and HOMENET.
However, we now have what I consider a serious situation: this
draft is in the final stage of IESG review, but to make any
sense it relies on two MIF documents being approved of which at
least one is contentious. Even though this is an Informational
document, it will look pretty silly if two of its main
dependencies do not get published.

Regards
   Brian Carpenter

On 2011-11-23 10:45, Ted Lemon wrote:
> On Nov 22, 2011, at 4:04 PM, Brian E Carpenter wrote:
> Given that the IETF Last Call on this draft ended 2011-06-21,
> there's been plenty of time to document the alternatives.
> 
> When something gets through IETF last call without objections being raised, you can't claim that as a triumphant validation of what it says.   The fact is that there are so many documents going through last call at this point, and being worked on, that no sane person can keep up with them all.   I wasn't even aware of this one until it came up  in Taiwan.
> 
> The fact is that we didn't properly solve the multihoming problem either in RA or in DHCP.   Whether this document actually becomes an RFC or not, we need to actually solve the problem it tries to address, because it certainly doesn't solve the problem.
> 
> 

From hermin.anggawijaya@gmail.com  Tue Nov 22 16:41:18 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B56431F0C4C for ; Tue, 22 Nov 2011 16:41:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.999
X-Spam-Level: 
X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qJaACNpUwde5 for ; Tue, 22 Nov 2011 16:41:18 -0800 (PST)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 07BD61F0C35 for ; Tue, 22 Nov 2011 16:41:17 -0800 (PST)
Received: by vcbfy13 with SMTP id fy13so990570vcb.31 for ; Tue, 22 Nov 2011 16:41:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XfTwIXWvY1sGOxlEqEBPzk7VYIHhr1+oBi4aEqc8ZcA=; b=yESFPo8zrmUcze2e+u4O4qVl5dY5RFkE26+2Ezr1PtMu7PHk5yEQActfNBMY8sBZrM 0/TjhTYrV0oqr6y891TsZ2OgQ/n1PMHwsX6mFgDx5KzLZy8gAaS18GY5JtZAxIXKxS1X hLvnqm3VuFIQnPM71Ci7gvN6RidgyJ1xG6/Vc=
MIME-Version: 1.0
Received: by 10.52.35.75 with SMTP id f11mr23080982vdj.18.1322008877460; Tue, 22 Nov 2011 16:41:17 -0800 (PST)
Received: by 10.220.185.137 with HTTP; Tue, 22 Nov 2011 16:41:17 -0800 (PST)
In-Reply-To: 
References: 
Date: Wed, 23 Nov 2011 13:41:17 +1300
Message-ID: 
From: Hermin Anggawijaya 
To: Philip Homburg 
Content-Type: text/plain; charset=ISO-8859-1
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Routers forwarding packet with link local source
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 23 Nov 2011 00:41:18 -0000

I assume that none of the 9 routers in the path carry the "IPv6 Ready Logo" ?
not that I claim the IPv6 Ready Logo is good or otherwise - debate
this somewhere else,
but at least to obtain the logo, any router must past self conformance
tests which include
link-local addressed packet forwarding requirement as specified in the RFC.

Speaking as a vendor, no we don't ignore the requirement deliberately.


H. Anggawijaya


On Wed, Nov 23, 2011 at 4:06 AM, Philip Homburg
 wrote:
> Looking at some traceroute output, I found a link local address. This is
> rather surprising given that RFC-4291 (Internet Protocol Version 6 (IPv6)
> Addressing Architecture) says:
>
> "2.5.6. Link-Local IPv6 Unicast Addresses
> [...]
> "Routers must not forward any packets with Link-Local source or
> "destination addresses to other links.
>
> The surprising thing is that the router that originates the packet is about
> 9 hops away from me.
>
> Are router vendors deliberately ignoring this requirement?
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>

From rbonica@juniper.net  Tue Nov 22 16:52:17 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57F7B1F0C6C for ; Tue, 22 Nov 2011 16:52:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.517
X-Spam-Level: 
X-Spam-Status: No, score=-106.517 tagged_above=-999 required=5 tests=[AWL=0.082, 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 NhzZWlAEmxA9 for ; Tue, 22 Nov 2011 16:52:16 -0800 (PST)
Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id 15D801F0C69 for ; Tue, 22 Nov 2011 16:52:16 -0800 (PST)
Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKTsxDuOGgdKJZjaELj2Hsaz1G2DLjOQu7@postini.com; Tue, 22 Nov 2011 16:52:16 PST
Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 22 Nov 2011 16:48:58 -0800
Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Tue, 22 Nov 2011 19:48:57 -0500
From: Ronald Bonica 
To: Brian E Carpenter , Ted Lemon 
Date: Tue, 22 Nov 2011 19:48:58 -0500
Thread-Topic: AD alert: New Version Notification - draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-03.txt
Thread-Index: AcypdsBrI7bL2VWxQc65+0/ARl8g9gAAqETw
Message-ID: <13205C286662DE4387D9AF3AC30EF456D74CE083DD@EMBX01-WF.jnpr.net>
References: <20111115062859.14026.74743.idtracker@ietfa.amsl.com>  <4ECACFF5.6020804@gmail.com>   <3D4D775D-E926-4F89-B279-75F0FE02B98F@nominum.com> <4ECC0E65.9060607@gmail.com> <682ABB42-2B62-43F5-B555-9B7C2AFE21EA@nominum.com> <4ECC3E0C.4000503@gmail.com>
In-Reply-To: <4ECC3E0C.4000503@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "v6ops@ietf.org WG" , Wesley Eddy , Pete Resnick , "" , "ietfdbh@comcast.net Harrington" 
Subject: Re: [v6ops] AD alert: New Version Notification - draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-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, 23 Nov 2011 00:52:17 -0000

QXJlIHRoZSByZWZlcmVuY2VzIG5vcm1hdGl2ZT8gSXQgc291bmRzIGxpa2UgdGhleSBzaG91bGQg
YmUuDQoNCklmIHNvLCB0aGUgcHJvYmxlbSBzb2x2ZXMgaXRzZWxmLiBFdmVuIGlmIHRoZSBJRVNH
IGFwcHJvdmVzIHRoZSBtdWx0aWhvbWluZyBkb2N1bWVudCwgYWxsIGl0IGNhbiBkbyBpcyBsYW5n
dWlzaCBvbiB0aGUgUkZDIGVkaXRvcidzIHF1ZXVlIHVudGlsIHRoZSByZWZlcmVuY2VkIGRvY3Vt
ZW50cyBhcmUgcHVibGlzaGVkLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgUm9uDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTog
QnJpYW4gRSBDYXJwZW50ZXIgW21haWx0bzpicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb21dDQo+
IFNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDIyLCAyMDExIDc6MjggUE0NCj4gVG86IFRlZCBMZW1v
bg0KPiBDYzogU2F0b3J1IE1hdHN1c2hpbWE7IHY2b3BzQGlldGYub3JnIFdHOyBXZXNsZXkgRWRk
eTsgUGV0ZSBSZXNuaWNrOw0KPiA8ZHJhZnQtaWV0Zi12Nm9wcy1pcHY2LW11bHRpaG9taW5nLXdp
dGhvdXQtaXB2Nm5hdEB0b29scy5pZXRmLm9yZz47DQo+IGlldGZkYmhAY29tY2FzdC5uZXQgSGFy
cmluZ3RvbjsgUm9uYWxkIEJvbmljYQ0KPiBTdWJqZWN0OiBBRCBhbGVydDogTmV3IFZlcnNpb24g
Tm90aWZpY2F0aW9uIC0gZHJhZnQtaWV0Zi12Nm9wcy1pcHY2LQ0KPiBtdWx0aWhvbWluZy13aXRo
b3V0LWlwdjZuYXQtMDMudHh0DQo+IA0KPiBUZWQsDQo+IA0KPiBVbmRlcnN0b29kLCBhbmQgSSB3
YXMgdmVyeSBsYXRlIHR1bmluZyBpbnRvIE1JRiBhbmQgSE9NRU5FVC4NCj4gSG93ZXZlciwgd2Ug
bm93IGhhdmUgd2hhdCBJIGNvbnNpZGVyIGEgc2VyaW91cyBzaXR1YXRpb246IHRoaXMNCj4gZHJh
ZnQgaXMgaW4gdGhlIGZpbmFsIHN0YWdlIG9mIElFU0cgcmV2aWV3LCBidXQgdG8gbWFrZSBhbnkN
Cj4gc2Vuc2UgaXQgcmVsaWVzIG9uIHR3byBNSUYgZG9jdW1lbnRzIGJlaW5nIGFwcHJvdmVkIG9m
IHdoaWNoIGF0DQo+IGxlYXN0IG9uZSBpcyBjb250ZW50aW91cy4gRXZlbiB0aG91Z2ggdGhpcyBp
cyBhbiBJbmZvcm1hdGlvbmFsDQo+IGRvY3VtZW50LCBpdCB3aWxsIGxvb2sgcHJldHR5IHNpbGx5
IGlmIHR3byBvZiBpdHMgbWFpbg0KPiBkZXBlbmRlbmNpZXMgZG8gbm90IGdldCBwdWJsaXNoZWQu
DQo+IA0KPiBSZWdhcmRzDQo+ICAgIEJyaWFuIENhcnBlbnRlcg0KPiANCj4gT24gMjAxMS0xMS0y
MyAxMDo0NSwgVGVkIExlbW9uIHdyb3RlOg0KPiA+IE9uIE5vdiAyMiwgMjAxMSwgYXQgNDowNCBQ
TSwgQnJpYW4gRSBDYXJwZW50ZXIgd3JvdGU6DQo+ID4gR2l2ZW4gdGhhdCB0aGUgSUVURiBMYXN0
IENhbGwgb24gdGhpcyBkcmFmdCBlbmRlZCAyMDExLTA2LTIxLA0KPiA+IHRoZXJlJ3MgYmVlbiBw
bGVudHkgb2YgdGltZSB0byBkb2N1bWVudCB0aGUgYWx0ZXJuYXRpdmVzLg0KPiA+DQo+ID4gV2hl
biBzb21ldGhpbmcgZ2V0cyB0aHJvdWdoIElFVEYgbGFzdCBjYWxsIHdpdGhvdXQgb2JqZWN0aW9u
cyBiZWluZw0KPiByYWlzZWQsIHlvdSBjYW4ndCBjbGFpbSB0aGF0IGFzIGEgdHJpdW1waGFudCB2
YWxpZGF0aW9uIG9mIHdoYXQgaXQNCj4gc2F5cy4gICBUaGUgZmFjdCBpcyB0aGF0IHRoZXJlIGFy
ZSBzbyBtYW55IGRvY3VtZW50cyBnb2luZyB0aHJvdWdoIGxhc3QNCj4gY2FsbCBhdCB0aGlzIHBv
aW50LCBhbmQgYmVpbmcgd29ya2VkIG9uLCB0aGF0IG5vIHNhbmUgcGVyc29uIGNhbiBrZWVwDQo+
IHVwIHdpdGggdGhlbSBhbGwuICAgSSB3YXNuJ3QgZXZlbiBhd2FyZSBvZiB0aGlzIG9uZSB1bnRp
bCBpdCBjYW1lIHVwDQo+IGluIFRhaXdhbi4NCj4gPg0KPiA+IFRoZSBmYWN0IGlzIHRoYXQgd2Ug
ZGlkbid0IHByb3Blcmx5IHNvbHZlIHRoZSBtdWx0aWhvbWluZyBwcm9ibGVtDQo+IGVpdGhlciBp
biBSQSBvciBpbiBESENQLiAgIFdoZXRoZXIgdGhpcyBkb2N1bWVudCBhY3R1YWxseSBiZWNvbWVz
IGFuDQo+IFJGQyBvciBub3QsIHdlIG5lZWQgdG8gYWN0dWFsbHkgc29sdmUgdGhlIHByb2JsZW0g
aXQgdHJpZXMgdG8gYWRkcmVzcywNCj4gYmVjYXVzZSBpdCBjZXJ0YWlubHkgZG9lc24ndCBzb2x2
ZSB0aGUgcHJvYmxlbS4NCj4gDQo+ID4NCj4gPg0K

From brian.e.carpenter@gmail.com  Tue Nov 22 17:10:52 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6C7E21F84D7 for ; Tue, 22 Nov 2011 17:10:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.547
X-Spam-Level: 
X-Spam-Status: No, score=-103.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TN3oOeitHEKP for ; Tue, 22 Nov 2011 17:10:46 -0800 (PST)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9547321F8478 for ; Tue, 22 Nov 2011 17:10:45 -0800 (PST)
Received: by vcbfy13 with SMTP id fy13so1005576vcb.31 for ; Tue, 22 Nov 2011 17:10:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=XWfwZjW1zduiiI7Atf+OU31VAFtZgHFX2VqKemosIoQ=; b=xQxKmzoQtnMjnsj0CrIYSHCtlnQbTOrW+iILD1qdFiBqPE4YnffhY6Wplq4KrBAUPa ooFQPX17CQLHe0SspH/hTtn9yN9nSZFS33y/3EZ9wu3Kx53iLI74TaRLrgfIcjaHA0LR K0ZWfW9Xhby7L8cizzODbpHFY7XSUYdQLmvEo=
Received: by 10.52.69.52 with SMTP id b20mr22722940vdu.85.1322010622669; Tue, 22 Nov 2011 17:10:22 -0800 (PST)
Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id eo2sm13395202vdb.5.2011.11.22.17.10.18 (version=SSLv3 cipher=OTHER); Tue, 22 Nov 2011 17:10:22 -0800 (PST)
Message-ID: <4ECC4802.7080708@gmail.com>
Date: Wed, 23 Nov 2011 14:10:26 +1300
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Ronald Bonica 
References: <20111115062859.14026.74743.idtracker@ietfa.amsl.com>  <4ECACFF5.6020804@gmail.com>   <3D4D775D-E926-4F89-B279-75F0FE02B98F@nominum.com> <4ECC0E65.9060607@gmail.com> <682ABB42-2B62-43F5-B555-9B7C2AFE21EA@nominum.com> <4ECC3E0C.4000503@gmail.com> <13205C286662DE4387D9AF3AC30EF456D74CE083DD@EMBX01-WF.jnpr.net>
In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D74CE083DD@EMBX01-WF.jnpr.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: "v6ops@ietf.org WG" , Wesley Eddy , Pete Resnick , "" , "ietfdbh@comcast.net Harrington" 
Subject: Re: [v6ops] AD alert: New Version Notification - draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-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, 23 Nov 2011 01:10:52 -0000

They are normative, and I believe appropriately so. Indeed
that prevents a purely formal problem - but the real problem
remains until we resolve the discussion around whether
draft-ietf-mif-dhcpv6-route-option is standardised. If not,
it's back to the drawing board as far as I can see.

Regards
   Brian

On 2011-11-23 13:48, Ronald Bonica wrote:
> Are the references normative? It sounds like they should be.
> 
> If so, the problem solves itself. Even if the IESG approves the multihoming document, all it can do is languish on the RFC editor's queue until the referenced documents are published.
> 
>                                               Ron
> 
>> -----Original Message-----
>> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]
>> Sent: Tuesday, November 22, 2011 7:28 PM
>> To: Ted Lemon
>> Cc: Satoru Matsushima; v6ops@ietf.org WG; Wesley Eddy; Pete Resnick;
>> ;
>> ietfdbh@comcast.net Harrington; Ronald Bonica
>> Subject: AD alert: New Version Notification - draft-ietf-v6ops-ipv6-
>> multihoming-without-ipv6nat-03.txt
>>
>> Ted,
>>
>> Understood, and I was very late tuning into MIF and HOMENET.
>> However, we now have what I consider a serious situation: this
>> draft is in the final stage of IESG review, but to make any
>> sense it relies on two MIF documents being approved of which at
>> least one is contentious. Even though this is an Informational
>> document, it will look pretty silly if two of its main
>> dependencies do not get published.
>>
>> Regards
>>    Brian Carpenter
>>
>> On 2011-11-23 10:45, Ted Lemon wrote:
>>> On Nov 22, 2011, at 4:04 PM, Brian E Carpenter wrote:
>>> Given that the IETF Last Call on this draft ended 2011-06-21,
>>> there's been plenty of time to document the alternatives.
>>>
>>> When something gets through IETF last call without objections being
>> raised, you can't claim that as a triumphant validation of what it
>> says.   The fact is that there are so many documents going through last
>> call at this point, and being worked on, that no sane person can keep
>> up with them all.   I wasn't even aware of this one until it came up
>> in Taiwan.
>>> The fact is that we didn't properly solve the multihoming problem
>> either in RA or in DHCP.   Whether this document actually becomes an
>> RFC or not, we need to actually solve the problem it tries to address,
>> because it certainly doesn't solve the problem.
>>
>>>

From Ted.Lemon@nominum.com  Tue Nov 22 18:48:46 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90DC61F0C4F for ; Tue, 22 Nov 2011 18:48:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.575
X-Spam-Level: 
X-Spam-Status: No, score=-106.575 tagged_above=-999 required=5 tests=[AWL=0.024, 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 ktRxy9VgBzkN for ; Tue, 22 Nov 2011 18:48:45 -0800 (PST)
Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id 9ADDF21F85A8 for ; Tue, 22 Nov 2011 18:48:45 -0800 (PST)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKTsxfAeMcoyTAJq03wC50/AopfS41kmqv@postini.com; Tue, 22 Nov 2011 18:48:45 PST
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 3FAD61B812A for ; Tue, 22 Nov 2011 18:48:33 -0800 (PST)
Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 26EFB190052; Tue, 22 Nov 2011 18:48:33 -0800 (PST) (envelope-from Ted.Lemon@nominum.com)
Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.01.0339.001; Tue, 22 Nov 2011 18:48:33 -0800
From: Ted Lemon 
To: Brian E Carpenter 
Thread-Topic: AD alert: New Version Notification - draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-03.txt
Thread-Index: AQHMqXa+G9+g6xQAnE69luWwWgkspZW6JowAgAAGAAD//5VMFQ==
Date: Wed, 23 Nov 2011 02:48:31 +0000
Message-ID: <348C068C-3378-42B7-A97F-E0E8D44EB33F@nominum.com>
References: <20111115062859.14026.74743.idtracker@ietfa.amsl.com>  <4ECACFF5.6020804@gmail.com>   <3D4D775D-E926-4F89-B279-75F0FE02B98F@nominum.com> <4ECC0E65.9060607@gmail.com> <682ABB42-2B62-43F5-B555-9B7C2AFE21EA@nominum.com> <4ECC3E0C.4000503@gmail.com> <13205C286662DE4387D9AF3AC30EF456D74CE083DD@EMBX01-WF.jnpr.net>, <4ECC4802.7080708@gmail.com>
In-Reply-To: <4ECC4802.7080708@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "v6ops@ietf.org WG" , Wesley Eddy , Pete Resnick , "" , "ietfdbh@comcast.net Harrington" 
Subject: Re: [v6ops] AD alert: New Version Notification - draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-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, 23 Nov 2011 02:48:46 -0000

On Nov 22, 2011, at 8:10 PM, "Brian E Carpenter"  wrote:
> They are normative, and I believe appropriately so. Indeed
> that prevents a purely formal problem - but the real problem
> remains until we resolve the discussion around whether
> draft-ietf-mif-dhcpv6-route-option is standardised. If not,
> it's back to the drawing board as far as I can see.

I really don't see the rush.  If we conclude that the route option should m=
ove forward, this draft gets published; if not, it gets updated. I presume =
that the authors don't agree with me that this isn't the right solution to =
the multihoming problem, but it seems like a worthwhile topic to discuss, s=
ince we certainly agree that there is a problem, and I think have in common=
 a motivation to fix it. =

From jouni.nospam@gmail.com  Tue Nov 22 22:35:34 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7E021F8AE6 for ; Tue, 22 Nov 2011 22:35:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.579
X-Spam-Level: 
X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[AWL=0.020,  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 FgFFJt2GRc87 for ; Tue, 22 Nov 2011 22:35:33 -0800 (PST)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5786521F8AD8 for ; Tue, 22 Nov 2011 22:35:33 -0800 (PST)
Received: by fabs1 with SMTP id s1so1511691fab.31 for ; Tue, 22 Nov 2011 22:35:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=hGddk18gs2RXAvb2RTqv86uD6/T5PYjxhwACSNkaFKY=; b=UPdhNjncQWppymMcF+baJhkpbnsReB8pW+BO1UiWEK1rZrjoRIMlXRfKisQZsT81MK WqZIcx0x24f1d0ijNS7jPf5Y/b+9JLGz3T3cN1VhdnLDAh6F46y0da59xMlr1QshyR8c GDlOYLS8xwAJMuoLlATiLf4dfvi6qnMNHu5Yg=
Received: by 10.152.144.2 with SMTP id si2mr13702218lab.8.1322030132400; Tue, 22 Nov 2011 22:35:32 -0800 (PST)
Received: from a83-245-212-188.elisa-laajakaista.fi (a83-245-212-188.elisa-laajakaista.fi. [83.245.212.188]) by mx.google.com with ESMTPS id mt9sm8392827lab.6.2011.11.22.22.35.29 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 22 Nov 2011 22:35:30 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: jouni korhonen 
In-Reply-To: <750BF7861EBBE048B3E648B4BB6E8F4F20EA14A5@crexc50p>
Date: Wed, 23 Nov 2011 08:35:27 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <8295A151-79B7-452B-BF7B-30241EDBBFF2@gmail.com>
References: <20111122190508.3293.41916.idtracker@ietfa.amsl.com><5B6B2B64C9FE2A489045EEEADDAFF2C3035EED43@XMB-RCD-109.cisco.com>  <750BF7861EBBE048B3E648B4BB6E8F4F20EA14A5@crexc50p>
To: "STARK, BARBARA H" 
X-Mailer: Apple Mail (2.1084)
Cc: v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-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, 23 Nov 2011 06:35:34 -0000

Barbara,

On Nov 23, 2011, at 2:16 AM, STARK, BARBARA H wrote:

>> A question.. should RFC6204bis also apply to deployments where the CE
>> WAN link is some sort of cellular link? If that is the case, then
>> current Section 4.2 language may not fit to CEs that e.g. have a LTE
>> radio as the WAN link. For example, WAA-3 and -4 seem to imply
>> statefull DHCPv6 client for address configuration (IA_NA reference
>> here), which would not possible e.g. for LTE. Also, WPD-1 alone would
>> not be enough (cf draft-ietf-dhc-pd-exclude).
>=20
> IMO, any WAN links that are not supported by the current requirements,
> are not supported, and support should not be added.
>=20
> IMO, there's a whole lot more to supporting LTE connections than just
> dhc-pd-exclude. Just based on the little I know, I would guess at =
least

Yes. This was just scratching the surface and poking for the interest.

There are non-trivial scenarios related, for example, lifetimes of =
delegated prefixes since the WAN link prefix and delegated prefixes are =
interlinked. But I guess any CE independent of technology would have =
some level of issues if WAN link prefix renumbering would cause =
renumbering of the delegated prefix set.

> a year's worth of arguing over functionality, with a need for other =
new
> functionality beyond just dhc-pd-exclude. That is, if you really want =
to

So far the PD peculiarities and WAN interface DHCPv6 details are the =
issues. Other stuff seems to be OK.

> make consumers happy about a CE router with a 3GPP-defined WAN
> connection.

Current breakdown by form factor indicates that ~36% of LTE devices are =
routers (according to gsacom). No idea what is the actual deployment =
percentage.

- Jouni


>=20
> But, again, that's just my opinion.=20
> Barbara


From gert@space.net  Wed Nov 23 00:01:21 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6ABA11E80FD for ; Wed, 23 Nov 2011 00:01:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6TRW1q6yqVpf for ; Wed, 23 Nov 2011 00:01:21 -0800 (PST)
Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7B63111E80F7 for ; Wed, 23 Nov 2011 00:01:15 -0800 (PST)
Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 2495AF897A for ; Wed, 23 Nov 2011 09:01:14 +0100 (CET)
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 0B6E2F8980 for ; Wed, 23 Nov 2011 09:01:14 +0100 (CET)
Received: (qmail 27791 invoked by uid 1007); 23 Nov 2011 09:01:13 +0100
Date: Wed, 23 Nov 2011 09:01:13 +0100
From: Gert Doering 
To: Brian E Carpenter 
Message-ID: <20111123080113.GI71280@Space.Net>
References:   <68DAB112-6E32-45FE-9AB7-A34E64898F60@cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30354436E@XMB-RCD-109.cisco.com> <750BF7861EBBE048B3E648B4BB6E8F4F20DC41F6@crexc50p>  <252D3DEA-FF09-42C8-959E-8A7205D9DE67@townsley.net>  <20111122133612.GH71280@Space.Net> <4ECC10C9.5010607@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KA+op4RcMj4kG0BL"
Content-Disposition: inline
In-Reply-To: <4ECC10C9.5010607@gmail.com>
X-NCC-RegID: de.space
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Alexandre Cassen , Claire Cheng , v6ops@ietf.org
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 23 Nov 2011 08:01:22 -0000

--KA+op4RcMj4kG0BL
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,

On Wed, Nov 23, 2011 at 10:14:49AM +1300, Brian E Carpenter wrote:
> This, or strict RPF, would be self-foot-shooting by the ISP
> wishing to sunset 6rd. It seems fairly simple to specify that
> both ingress filtering and RPF should be configured to allow
> both prefixes simultaneously.=20

Permit me a polite cough here.

*The* benefit of 6rd on the gateway side is that it's stateless, which
means "no per-subscriber information needs to be gathered, kept, and
validated for incoming packets".

So either you want RPF filtering on the 6rd side, or not - but there is
no reasonable way you can ISP subscriber data for a reasonable-sized
ISP into the 6rd gateways to enable RPF filtering "plus extra prefixes
for some of the subscribers" on the 6rd gateway.


> This is a standard need for
> multihomed PA customers anyway, and needs to become standard
> practice for all IPv6 ISPs.

This is a standard *problem*, not a "standard need".

You're not going to see large-scale ISPs that do deploy RPF filtering
(few enough, alas) add "oh, this customer also has prefix X from ISP Z
this week!" to their subscriber management platform, which is where the=20
routers get configured from.  Including verification that this=20
customer is even entitled to *use* prefix X at this time.


> While we do need a solution for source-prefix based exit
> selection, we don't have one yet and it's a separable problem.

I strongly disagree.  This is the core of the problem for multi-PA-based
multihoming, and one variant presents itself now with "two different
access technologies with different prefixes to the same ISP".

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

--KA+op4RcMj4kG0BL
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (FreeBSD)

iQCVAwUBTsyoSakuBuNlUUl1AQL/zAQArIUNkVWavlHyhNwffK2KSHy58ZpRjMWb
33Y9Pycc8Sv/8E3v6Camh3O2fNoewxnX96DLxlkI12SnwhEpdtnP+sQQG4ZmmVuG
Mt847F40l2dCEfxGJ/8d2IREVrViUBRYRQzKBxvsH+y2vOjZIiooJtGfitQpsenH
BpD6JPPtTkM=
=z4ZK
-----END PGP SIGNATURE-----

--KA+op4RcMj4kG0BL--

From shemant@cisco.com  Wed Nov 23 01:54:05 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2957C21F8C18 for ; Wed, 23 Nov 2011 01:54:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.275
X-Spam-Level: 
X-Spam-Status: No, score=-6.275 tagged_above=-999 required=5 tests=[AWL=0.323,  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 GzOCNl0JUia8 for ; Wed, 23 Nov 2011 01:54:04 -0800 (PST)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE0521F8C17 for ; Wed, 23 Nov 2011 01:54:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=9073; q=dns/txt; s=iport; t=1322042044; x=1323251644; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=I4lQkRHInObxAWIiTHs18m1bY5JJsitIPgwZ6HSWitU=; b=TAvUDzMjVG4BtW+wl5R9O6fEFr9Myu28HhTExAunzRxdUOkX8ec57K4q hJ3eJbGoMWh01Ysz0RqoeHulKJQ3Z/DJAvCDDe1ZTIMgUH2Bsg2fXXqan RLQtxiiI/icqVz2BqDue/SX4qPVMtC+RVysve0uQh3AASfbui9M3vchmU g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqsAAOjBzE6tJV2d/2dsb2JhbABEgk2XfpAYgQWBcgEBAQQSAQkRA0kMBAIBCBEEAQELBhcBBgEgJQkIAQEEEwganiQBnjGJf2MEiCCWfYdU
X-IronPort-AV: E=Sophos;i="4.69,558,1315180800"; d="scan'208,217";a="38426424"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 23 Nov 2011 09:54:04 +0000
Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id pAN9s4J6004956;  Wed, 23 Nov 2011 09:54:04 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 23 Nov 2011 03:54:03 -0600
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCA9C5.D507EF37"
Date: Wed, 23 Nov 2011 03:54:02 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3035EEEB3@XMB-RCD-109.cisco.com>
In-Reply-To: <8295A151-79B7-452B-BF7B-30241EDBBFF2@gmail.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
Thread-Index: AcypqhqKdbbVwVeKTleilbkpNBpyGgAGSOHQ
References: <20111122190508.3293.41916.idtracker@ietfa.amsl.com><5B6B2B64C9FE2A489045EEEADDAFF2C3035EED43@XMB-RCD-109.cisco.com>  <750BF7861EBBE048B3E648B4BB6E8F4F20EA14A5@crexc50p> <8295A151-79B7-452B-BF7B-30241EDBBFF2@gmail.com>
From: "Hemant Singh (shemant)" 
To: "jouni korhonen" , "STARK, BARBARA H" 
X-OriginalArrivalTime: 23 Nov 2011 09:54:03.0966 (UTC) FILETIME=[D554D5E0:01CCA9C5]
Cc: v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-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, 23 Nov 2011 09:54:05 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CCA9C5.D507EF37
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

=20

=20

-----Original Message-----
From: jouni korhonen [mailto:jouni.nospam@gmail.com]=20
Sent: Wednesday, November 23, 2011 1:35 AM
To: STARK, BARBARA H
Cc: Hemant Singh (shemant); v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt

=20

=20

>There are non-trivial scenarios related, for example, lifetimes of
delegated prefixes since the WAN link prefix and delegated prefixes >are
interlinked. But I guess any CE independent of technology would have
some level of issues if WAN link prefix renumbering would cause
>renumbering of the delegated prefix set.

=20

The above issues are clearly clarified in RFC 3633.  See this text from
section 12.1.

=20

[Each prefix has valid and preferred lifetimes whose durations are

specified in the IA_PD Prefix option for that prefix.  The requesting

router uses Renew and Rebind messages to request the extension of the

lifetimes of a delegated prefix.]

=20

The same text also applies to the exclude pd option.

=20

=20

>So far the PD peculiarities and WAN interface DHCPv6 details are the
issues. Other stuff seems to be OK.

=20

It would be interesting to know the peculiarities.=20

=20

Hemant

=20


------_=_NextPart_001_01CCA9C5.D507EF37
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


 
 
-----Original Message-----
From: jouni korhonen =
[mailto:jouni.nospam@gmail.com] 
Sent: Wednesday, November 23, 2011 =
1:35 AM
To: STARK, BARBARA H
Cc: Hemant Singh (shemant); =
v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: =
draft-ietf-v6ops-6204bis-03.txt
 
 
>There are non-trivial scenarios related, for =
example, lifetimes of delegated prefixes since the WAN link prefix and =
delegated prefixes >are interlinked. But I guess any CE independent =
of technology would have some level of issues if WAN link prefix =
renumbering would cause >renumbering of the delegated prefix =
set.
 
The above issues are =
clearly clarified in RFC 3633.  See this text from section =
12.1.
 
[Each prefix has valid =
and preferred lifetimes whose durations are
 specified in the IA_PD =
Prefix option for that prefix.  The =
requesting
 router uses Renew and Rebind messages to request =
the extension of the
 lifetimes of a delegated =
prefix.]
 
The same text also =
applies to the exclude pd option.
 
 
>So =
far the PD peculiarities and WAN interface DHCPv6 details are the =
issues. Other stuff seems to be OK.
 
It would be interesting to know the peculiarities. =

 
Hemant
 

------_=_NextPart_001_01CCA9C5.D507EF37--

From Carl.Wuyts@technicolor.com  Wed Nov 23 02:00:34 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 141C921F8C1C for ; Wed, 23 Nov 2011 02:00:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.504
X-Spam-Level: 
X-Spam-Status: No, score=-4.504 tagged_above=-999 required=5 tests=[AWL=-0.326, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wVeCcEU8r8x8 for ; Wed, 23 Nov 2011 02:00:32 -0800 (PST)
Received: from na3sys009aog108.obsmtp.com (na3sys009aog108.obsmtp.com [74.125.149.199]) by ietfa.amsl.com (Postfix) with ESMTP id 0EF2221F8432 for ; Wed, 23 Nov 2011 02:00:31 -0800 (PST)
Received: from mopesedge02.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob108.postini.com ([74.125.148.12]) with SMTP ID DSNKTszEOfKzknbeyW0mzvSvGonRnuQ6PE5R@postini.com; Wed, 23 Nov 2011 02:00:32 PST
Received: from MOPESMAILHC02.eu.thmulti.com (141.11.100.29) by mopesedge02.eu.thmulti.com (141.11.253.23) with Microsoft SMTP Server (TLS) id 8.3.192.1; Wed, 23 Nov 2011 10:58:48 +0100
Received: from MOPESMBX01.eu.thmulti.com ([169.254.155.121]) by MOPESMAILHC02.eu.thmulti.com ([141.11.100.29]) with mapi; Wed, 23 Nov 2011 10:58:59 +0100
From: Wuyts Carl 
To: "v6ops@ietf.org" 
Date: Wed, 23 Nov 2011 10:58:57 +0100
Thread-Topic: RFC6204bis-03
Thread-Index: AcypxoQV5eFbzgXCTbaCf1D51oSJ6w==
Message-ID: <867F4B6A1672E541A94676D556793ACD0C2766DEE7@MOPESMBX01.eu.thmulti.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/related; boundary="_006_867F4B6A1672E541A94676D556793ACD0C2766DEE7MOPESMBX01eut_"; type="multipart/alternative"
MIME-Version: 1.0
Subject: [v6ops] RFC6204bis-03
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 23 Nov 2011 10:00:34 -0000

--_006_867F4B6A1672E541A94676D556793ACD0C2766DEE7MOPESMBX01eut_
Content-Type: multipart/alternative;
	boundary="_000_867F4B6A1672E541A94676D556793ACD0C2766DEE7MOPESMBX01eut_"

--_000_867F4B6A1672E541A94676D556793ACD0C2766DEE7MOPESMBX01eut_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I must say I'm a bit surprised to already see the SOL_MAX_RT req popping up=
 as a "MUST" into this version of RFC6204bis as it's still quite heavily di=
scussed (and by the looks of it, not really commonly accepted).  Isn't it a=
 bit too early to do this already ?

This is the req I'm talking about:
WAA-8:  The CE Router MUST parse the DHCPv6 SOL_MAX_RT option
           [I-D.droms-dhc-dhcpv6-maxsolrt-update] in a received DHCPv6
           Advertise or Reply message and set its internal SOL_MAX_RT
           parameter to the value contained in the SOL_MAX_RT option.

Appendix message:
9.   Added a new WAN DHCPv6 requirement for SOL_MAX_RT of DHCPv6 so
        that if an service provider does not have DHCPv6 service enabled
        CE routers do not send too frequent DHCPv6 requests to the
        service provider DHCPv6 server



Carl Wuyts
GCD System Architect Networking
Connect Division

carl.wuyts@technicolor.com
tel.: +32 3 443 65 90
[cid:image001.gif@01CCA9CE.E5DA0710]
[cid:image002.gif@01CCA9CE.E5DA0710]
Prins Boudewijnlaan 47  -  2650 Edegem  -  Belgium

Technicolor Delivery Technologies Belgium NV
Registered office (maatschappelijke zetel): Prins Boudewijnlaan 47, 2650 Ed=
egem, Belgium
Company registration number (ondernemingsnummer): 0428837295 - RPR Antwerpe=
n
[cid:image003.gif@01CCA9CE.E5DA0710]

Help preserve the color of our world - Think before you print.






--_000_867F4B6A1672E541A94676D556793ACD0C2766DEE7MOPESMBX01eut_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


I must say IR=
17;m a bit surprised to already see the SOL_MAX_RT req popping up as a R=
20;MUST” into this version of RFC6204bis as it’s still quite he=
avily discussed (and by the looks of it, not really commonly accepted).&nbs=
p; Isn’t it a bit too early to do this already ?
 
This is the req I&=
#8217;m talking about:
WAA-8:  The =
CE Router MUST parse the DHCPv6 SOL_MAX_RT option
           [I-D=
.droms-dhc-dhcpv6-maxsolrt-update] in a received DHCPv6
          =
; Advertise or Reply message and set its internal SOL_MAX_RT
=

         =
  parameter to the value contained in the SOL_MAX_RT option.
 
 Append=
ix message:
9.   Added a new W=
AN DHCPv6 requirement for SOL_MAX_RT of DHCPv6 so
        that if an service pro=
vider does not have DHCPv6 service enabled
        CE routers do not send too fr=
equent DHCPv6 requests to the
 &nbs=
p;      service provider DHCPv6 server<=
/p>
 
&nbs=
p;
 
Carl Wuyts
GCD System Ar=
chitect Networking
Connect Division
carl.wuyts=
@technicolor.com
tel.: +3=
2 3 443 65 90
3Dtwitter
3D"Visit
Prins Boudewijnlaa=
n 47  -  2650 Edegem  -  Belgium
Technicolor Delivery Technologies Belgium NV
Registered office (maatschappelijke zetel): Prins Boudewijnla=
an 47, 2650 Edegem, Belgium
<=
b>Company registration number (ondernemingsnummer): 0428837295 - RPR An=
twerpen
3DEco<=
o:p>
Help preserve the color of our world - Think=
 before you print.
 
 
=

--_000_867F4B6A1672E541A94676D556793ACD0C2766DEE7MOPESMBX01eut_--

--_006_867F4B6A1672E541A94676D556793ACD0C2766DEE7MOPESMBX01eut_
Content-Type: image/gif; name="image001.gif"
Content-Description: image001.gif
Content-Disposition: inline; filename="image001.gif"; size=1351;
	creation-date="Wed, 23 Nov 2011 09:58:57 GMT";
	modification-date="Wed, 23 Nov 2011 09:58:57 GMT"
Content-ID: 
Content-Transfer-Encoding: base64

R0lGODlhGAAYAPcAAAAAAP///1Sfum/L64bW8o7h/ofU74fT7pHb9pfa8u75/VbD5VzG6FvF5l3G
513F5l/G51/F5mHH52PH6GPI6GPI52TH6GXJ6GbI6GnK6mjJ6WjK6WzL6m/M63HN6nPN6nTN63fR
7XnR7XTI5FeVqnnN537T7n7R7H/T7X3O6Y3f+4jV73m903/E2oDE2pTf+ZPc9JTa8Zfa8aDd8LDj
9MXr9+z5/er3+/r9/imy1yyx1S202S2z1zK43TW63jW32zS22Ta53Te73za32zq84Dm53Du73j2/
4j2+4T283z273kHB5D++4EHA4kG/4UPA40K/4UTB5EbD5UbB40rJ7EjD5ErG6EnE5knE5Ua720rE
5kvG507J607I6U3G50/K60u+3U2/4U7A4k2/3lLI6E/A31XN7lHC4VnP8FfL61PD4lXD5FXF41vR
8VfG5VO92lrJ51a+21i/21/O7F7L6VnB3VzE4mHN6l/H5V3D30+lvWDH41/E4GDF4WLH42rL6GvP
6l+2znLZ9W7Q62C1zGO50HXZ9HTY83ba9XXX8mW70nLO6nHN6We803rd+HXV73zf+mm91HXS62vA
12GpvWavw2ixxVmWp2qxxYDW7X3Q52yzxm+2yW60x4HS6HC2yXG3ynzD2I7a75Xb7pvh9F+HkqTg
8ajg76ff7qri8bPo97fm9Ljm9MXw/Mfw/NDz/dDx+tbx+dz0++H1++f5/uv5/Six1S+22jG01zK1
2EXD5E/M7U7H50yvyWPY91zJ5WjZ92za927b+HHY82G4z3Xd+FurwHXa9Xfc93ne+F+rv37h+2u/
1YDi/H7c9YHh+YLh+YXi+mqyxWuzxork+ovj+o3l+3K4ypXn+12PnJrm+qXp+63j8cLx/M/0/ef4
/Jfp+57q+6Xt/Kjv/avv/a3v/a7w/bPw/bzz/uP6/+z7/vP9/7fz/r30/sD0/sX1/sn2/tT4/9L2
/d/6/+X7/+b7/+r8/+v7/sz3/tr5/ub8/+39//v///3///7//////yH5BAEAAP8ALAAAAAAYABgA
AAj/AP8JHEiwoMGCAgggOGCg4YqHEB8aOPCCAEESKmR84MABg0cOHUKGHDCAA4gEBQaOiIHBwgQO
pmrQEEEhg80NGnJewACDhcAUJyBMwBArgL8ACkxc2MBUg8cLEEy0+PkhQoMZAerNmxegBoMLFChc
AFsBQggXAkswerBgVYB8+eLtu7GorgcKDipIcBBi6r8SHtiyCoAPH7x6AXAoxjELRYO9IUIJlGMn
jBi37zLHo2fPXj19/hT8WRMGDzGBb7LosIUqADp07WC7c9eOHbwAmnjwGBNIYBwwuHK0NleOOLnj
5MaxC+BpR64zp//JGQNkx6kA4rKXO8ede7oAe378/1BTSGCdMkNunfIXLhw4eQH6yU88KoiSImzK
/8tzpkiPVP1gg4013gRgYGKmEMEEE0a4oYhAeahhhA/c8FMNNdF0s4466tyzTgCrOAFFEnA0IhAf
bCQhhCkBVPMMNDDC+GI3AUiCBBNwRCJQH24wgUQmAWwjTDJEFllMNAGIcoQTdDAjkB9uODGFFLHw
o00wwGSZpS/bBJDJEk80+eQvTVQhxR2zBECLK6202c0rAchCxhVR3DGJb5I0gYUXVqRBCiy1BFqL
Dd+oMocVW+jyCCEC6ZEIIFps0cUXVOyCRhuYomEGFVx0wcsghlwyUC/DOHPIMcg4AskyzbS6DCSO
ICSDiDOCGFNQNspUYgkmm3TCCSjXgPJJJ9NIYwklpRyk7LIDBQQAOw==

--_006_867F4B6A1672E541A94676D556793ACD0C2766DEE7MOPESMBX01eut_
Content-Type: image/gif; name="image002.gif"
Content-Description: image002.gif
Content-Disposition: inline; filename="image002.gif"; size=1834;
	creation-date="Wed, 23 Nov 2011 09:58:57 GMT";
	modification-date="Wed, 23 Nov 2011 09:58:57 GMT"
Content-ID: 
Content-Transfer-Encoding: base64

R0lGODlhcgBFAOZ/AEGueqipqmgxkACLS4ORyPb294DFpZrMVqvi+sXr2Ie3laLXtnRHnLQlZO3J
2M+pxP7pJvqtgePqmqOIvYLKnACP1fewoXa65/vCov71sdqRnc6OpPvrlcU/benvs7qmzpzR8P/n
rc7imtLntMkhU/V7Hf/yl+fZ6f3HipjL7b+MraKs1h+WXIrU9fNrPv/dkaTIrpQpd/JlIr8kXv/o
ALa3uO0bLwCmUQC68pKSlf/CDgxNosvbKtvb3IzGP8nJyoiJjPaWgH+Ag3Z3euTk5Y3Y+MTfm+3t
7r/AwZubnvBSJQCZ3NLS0//eAwN+yE84la9fmdjkX//RSiPB855BhP/ILiCvY9HeRvLkCvmykSld
q/aNl4Dd+cPT6O85Q2m+Q6zRONnM5OPx0PR3OR2Z2eOttkCr4Lfbm//uQPWMWbeLscPbysbs/OP1
/ZeLwPaLN9blff/iEvXlByCi3nzB69eqvN7r4uzysHfDWSCKzu+Uh8R4pR6j4IVfqm1ucf///yH5
BAEAAH8ALAAAAAByAEUAAAf/gH+Cg4SFhoeIiYqLjI2Oj5CRkpOUlZaXmJmam5ydnp+goaKjpKWm
p6ipqqusra6vsLGys7S1tqF+Oat+freMubu9vorAkkhIlryqBQWXxZBEvD2VyqhEQtPJupJJScnC
pzV+2dTbqdWnSX4BNTWDR+01RIUFSO0/zX/AP+1Mg/x/iLRDku9PO0JH7NXA906hv0Ho/vSId2TQ
xB4Jf1gKwKujoB8deWn8OCTkkIp+gAAJGUBQjnUhgUAEB9Lkx5C58lUr8DLkSHE5Spqb1IMjkh7T
evgZ4o9JyYrR/Mib2FKfHyH4kPBq1rPGkR4lH1ZjsvQH0gDIlA7RSGSlN6uC/zgCmfcjrEFeQuRd
EkeO48g/IN2pQ2boasGV014+/MPRHdw/QsYZUve3wFO4R5YWBOlN3FtMfAetBJKj9EpdEQk9+/My
sWRB4hxXS3koNcdpypRWnXnXMejXf4SWHt4yNcShrVkDjy1o9lDehELnXldIGfNMoV0CJxSZnGrk
kpPDltpc2FZDK+eJlqwsmsx3V3trEvdXK5CKgvKJu59fLHjX5FxXjVz5fHUXEPmAJER5gkQ2UgHq
uHMdJiANkcNIK+WSQ2TraaiZPv8pFyB5jxWwkoUvLWjiVUlkmE01RJQERACRISifJhxR90cBNUTG
YkE1ZAgEYTnsxlgO8wSA5P8/F7pkDo8+AvFgj7wkoR5r5hChzlU1JNjkMGCGKeaYZJZp5pmqsIHA
mmyCkMKbcK4g55wrfGDnnR88oOeedZTh558WBCqoBRgUaigGISSqaAgZNOroHR5EKqkHI1Rq6QKY
ZroADJx2CoMdjxSAQBGkktoCHRekqioBrLZKgBsTxCqrGirUaqsGuOaqgR5B9OprBMAGG8ELxBb7
ggnIJmuCBMw2K4EIRkQb7RkUVGstBQpkq60CazTSRqmlnqrqqq6yCqusstqqrq65+uqusMGiYCyx
HCiLLAfONguttEZQe22122oLQ0GHsAGuqeOSW+656E6grq0bsIuru7/CG4H/vPMea++y+TK7r7T+
/huwtqAiMsXJKE/BBxkst5yHFjDHrAUDNNdMMxU450xFBzz3zLMXQAfthQtjFG30G1UkrXQVEDTt
dNNXRC31FWAcYPXVeFih9dZWsOD11ywAkAgOZJeNwxIVpK22Ezu07fYOTwgg99wCxGD33TE0MMPe
fJNgw9+A26CEDIQXXoIOiCeuQxM0NO44FjxELjkPYPhg+eVf3KD55jcM4PnnA4iNiNllo6122my/
3XbcdMuN9916872334H/PXjhhB+uOOKMO9445JNHXvnllmfOueagfy76IaSTbfrpqavOeuuv2x27
7LTXfjvuuu/eu+/ABz88//HGH5+858sb0vzZp6Ou+uqtu1799X3Xbjvuue/Ou++/By888cU7HvLO
l75CrO95a3sf3OJXt/nJbnb2Exz+ZNA9xX3vcf6jHAB9UD7OnS90Y2seAt33vunRrXp5e+AMshe4
7RlOf4vjHw3CN7nxYU6AnSNgCEk3wgpE720mnBsK6QdB+7kwf/q7YP/8BwcxOPGJC8DhBwtIiAO2
z4cKDKL8XkfEFUbwiBSEoRJpIIcomPGMUbiDIRIgRR2OToRXrEAX5kjHLvSBgUNUIQsBB8YSSOGP
gJRCHGRIA0ewUYBTTAQXFslILswhjoe4Y/zy+EASbOGSmNyCCyYog0OggYeQhgSAKEcJABa40RFm
gKQhThCGVrryAZR84CHSwElPgrISADhlI1J5RUc4IJaym2UtSZHL5FFREbxsny9RuAcHOPOZDjgE
BrJAzWpmoRQLMIA2t7kASCTzdI44ARTGSU4oPABN6EynOtfJzna6853wjKc850nPetrznvjMpz73
yc9++tMUgQAAOw==

--_006_867F4B6A1672E541A94676D556793ACD0C2766DEE7MOPESMBX01eut_
Content-Type: image/gif; name="image003.gif"
Content-Description: image003.gif
Content-Disposition: inline; filename="image003.gif"; size=493;
	creation-date="Wed, 23 Nov 2011 09:58:57 GMT";
	modification-date="Wed, 23 Nov 2011 09:58:57 GMT"
Content-ID: 
Content-Transfer-Encoding: base64

R0lGODlhHAAhAMQAALHNVVqXGZu+IqbFNv79/ury0pK4H2SdaJzAJNjlq/3++vL34srdiSl5Mfj7
8OHrvDmDE5u+Kb3VbtDgm5jCnJC2IqDBJHqqHoazHsfYxcfco+/58f7///7+/v///f///yH5BAAA
AAAALAAAAAAcACEAAAX/4CeOZGmeaKqubOumXSfKL0rT9RiTe65/nl0vxxE1KB3Ph6b8KGYjT/Pn
ORwIHmy0FEQFCZRG5yldJnEqD6ezaWQIHMJDApAwCthgF8hbEqwEBQARAoWFEgskQWgiChwFDRoD
hpQCA3hLQGhxSWABFpQIlAMPT2NoeTIJEBigooavlzJDS0UdHAkBEAivAoSjDklTQAROuBYQn7+/
lBJJS01SUgoJoskWvaECCWUiHEEKtw+8BtegvoWxiYtqSmsLhBblEALn2hLDH3HTAIXYuhfqVeLF
TZ8SR3oSULKAQVeAChYi8kJwCUg4BcVkOOiXDgHDACAvXMBQoWQEOw6iahwsMCmdAI8CKoiciUEA
gAJ8aBC4xfKlz3QRsVGcoICMJidKOjhgMKCXqKcAJqSMIkwEuw8OHjCQwNVOggJPvqm4ZUJGuw47
lajlA0Sat28xyJZV9APasGEcvknBkU9TjJ1WrTZZE9hHihAAOw==

--_006_867F4B6A1672E541A94676D556793ACD0C2766DEE7MOPESMBX01eut_--

From shemant@cisco.com  Wed Nov 23 02:22:41 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28D0221F8C19 for ; Wed, 23 Nov 2011 02:22:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.278
X-Spam-Level: 
X-Spam-Status: No, score=-6.278 tagged_above=-999 required=5 tests=[AWL=0.321,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iiCjQeyCsl1z for ; Wed, 23 Nov 2011 02:22:40 -0800 (PST)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id AD05321F8C1C for ; Wed, 23 Nov 2011 02:22:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=729; q=dns/txt; s=iport; t=1322043758; x=1323253358; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=tftlHEKy6kIileQq/0MplbzNYiSGX2T653IWjx/k1Ls=; b=PChv0j6CzCAu1DBv9iclX3d9dTVgwDIfpjvnp3OCXt5IuzJICCjkTMjZ OvKYJrQ7ixqP/4HWwht7Ea9UBxP2QyslN2CQn8YkepRD7r6d6VaFV9X3p qaVTNJz1GK6JxPJmzHUw1MDvkA+RPPao6ZOYlkToG7MmVfHIyGmjKaY+0 k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqsAABPJzE6tJXG+/2dsb2JhbABEmkuQGIEFgXIBAQEEEgEdCj8MBAIBCA4DBAEBCwYXAQYBRQkIAQEEARIIEweeKAGeM4l/YwSIIJUtiSQ
X-IronPort-AV: E=Sophos;i="4.69,558,1315180800"; d="scan'208";a="38431889"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 23 Nov 2011 10:22:38 +0000
Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id pANAMcZW024100;  Wed, 23 Nov 2011 10:22:38 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 23 Nov 2011 04:22:38 -0600
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 23 Nov 2011 04:22:36 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3035EEEB5@XMB-RCD-109.cisco.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] DHCPv6 option for MAX_SOL_RT
Thread-Index: AcypA9H+X+G7BMvSTTWKWc+qAoyhAQAxb9Gg
References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com><5B6B2B64C9FE2A489045EEEADDAFF2C30354473D@XMB-RCD-109.cisco.com><4EC455D6.8030601@bogus.com><7EB596BF-B175-40BF-ABC8-326599670B04@apple.com><5B6B2B64C9FE2A489045EEEADDAFF2C303544B88@XMB-RCD-109.cisco.com><8D342733-88E6-45D3-B388-E001AE32CD77@employees.org><750BF7861EBBE048B3E648B4BB6E8F4F20DC4FEA@crexc50p><007801cca8c8$5610aa00$0231fe00$@iname.com><00f801cca8fd$784fcdf0$68ef69d0$@iname.com><418C43A6-5E8A-4CBD-83F4-3C5F502213A1@employees.org> 
From: "Hemant Singh (shemant)" 
To: "Ole Troan" , "Lorenzo Colitti" 
X-OriginalArrivalTime: 23 Nov 2011 10:22:38.0155 (UTC) FILETIME=[D31151B0:01CCA9C9]
Cc: IPv6 Operations 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 23 Nov 2011 10:22:41 -0000

-----Original Message-----
From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
Of Ole Troan
Sent: Tuesday, November 22, 2011 5:45 AM
To: Lorenzo Colitti
Cc: IPv6 Operations
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT

>I think I've given umpteen reasons why we shouldn't couple M/O bits
with PD already.
>the O bit means _stateless_ DHCP. PD is stateful. please let's stop
talking about the M/O bits. we have a solution to the DHCP storm
>problem within DHCP.

I have said the same thing over and over again.  +1 to Ole's comments.
rfc6204bis should move forward with the MAX_SOL_RT solution to the
DHCPv6 server storm and please let's stop the M and the O bits
discussion.

Hemant

From shemant@cisco.com  Wed Nov 23 02:29:44 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD7CB21F8C0A for ; Wed, 23 Nov 2011 02:29:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.77
X-Spam-Level: 
X-Spam-Status: No, score=-4.77 tagged_above=-999 required=5 tests=[AWL=-1.192,  BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ybGXCZwIU51K for ; Wed, 23 Nov 2011 02:29:42 -0800 (PST)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 64D5A21F8C00 for ; Wed, 23 Nov 2011 02:29:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=22117; q=dns/txt; s=iport; t=1322044182; x=1323253782; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=1Dw5/3AoB9/683FivP3mtdO7vW8BRHngso5UsYD+EzE=; b=ODWrB7MeimuzC4ldhMjVK09Whut4k1V9ovoRR0aJkcmu9pADRksXKNxd zWY2TV0QPt3jwE5dDCEXIkQEmcmBDx6vzjU/bRjHM1DFzJLcuL27kYgUf GGnGK9RPZ4E3rdNNBkuS4870xcXnTYF8g5q2LH2jULz7cvh9r4DRTJNfk E=;
X-Files: image001.gif, image002.gif, image003.gif : 1351, 1834, 493
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqsAAOnJzE6tJV2c/2dsb2JhbABEgk2XfpAYgQWBcgEBAQQFDQEJCQgBAjQlAgEIBwoEAQEGAQEDBhcBBgEBBRAGCSAJCAEBBAERAQgGFIdrlj0BnjSJf2MEiCCDdYJ/l10
X-IronPort-AV: E=Sophos;i="4.69,558,1315180800";  d="gif'147?scan'147,208,217,147";a="38417018"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 23 Nov 2011 10:29:41 +0000
Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id pANATfir024898;  Wed, 23 Nov 2011 10:29:41 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 23 Nov 2011 04:29:41 -0600
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/related; boundary="----_=_NextPart_001_01CCA9CA.CF160B5D"; type="multipart/alternative"
Date: Wed, 23 Nov 2011 04:29:39 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3035EEEB6@XMB-RCD-109.cisco.com>
In-Reply-To: <867F4B6A1672E541A94676D556793ACD0C2766DEE7@MOPESMBX01.eu.thmulti.com>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] RFC6204bis-03
Thread-Index: AcypxoQV5eFbzgXCTbaCf1D51oSJ6wAA9B8A
References: <867F4B6A1672E541A94676D556793ACD0C2766DEE7@MOPESMBX01.eu.thmulti.com>
From: "Hemant Singh (shemant)" 
To: "Wuyts Carl" , 
X-OriginalArrivalTime: 23 Nov 2011 10:29:41.0330 (UTC) FILETIME=[CF4CB320:01CCA9CA]
Subject: Re: [v6ops] RFC6204bis-03
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 23 Nov 2011 10:29:45 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CCA9CA.CF160B5D
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_002_01CCA9CA.CF160B5D"


------_=_NextPart_002_01CCA9CA.CF160B5D
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Carl,

=20

Not a surprise.  Even the -02 version includes the MAX_SOL_RT text as
shown below.  We changed the text a little since Ralph's draft has been
published and we could reference the document.

=20

[WAA-8:  The IPv6 CE router MUST set SOL_MAX_RT (specified by

           [RFC3315]) to 7200 seconds.]

=20

During the IETF in Taipei the MAX_SOL_RT was discussed in the v6ops WG
and also the DHC WG.  We  have rough consensus to move forward with this
requirement to alleviate a DHCPv6 server storm.=20

=20

Hemant

=20

From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
Of Wuyts Carl
Sent: Wednesday, November 23, 2011 4:59 AM
To: v6ops@ietf.org
Subject: [v6ops] RFC6204bis-03

=20

I must say I'm a bit surprised to already see the SOL_MAX_RT req popping
up as a "MUST" into this version of RFC6204bis as it's still quite
heavily discussed (and by the looks of it, not really commonly
accepted).  Isn't it a bit too early to do this already ?

=20

This is the req I'm talking about:

WAA-8:  The CE Router MUST parse the DHCPv6 SOL_MAX_RT option

           [I-D.droms-dhc-dhcpv6-maxsolrt-update] in a received DHCPv6

           Advertise or Reply message and set its internal SOL_MAX_RT

           parameter to the value contained in the SOL_MAX_RT option.

=20

Appendix message:

9.   Added a new WAN DHCPv6 requirement for SOL_MAX_RT of DHCPv6 so

        that if an service provider does not have DHCPv6 service enabled

        CE routers do not send too frequent DHCPv6 requests to the

        service provider DHCPv6 server

=20

=20

=20

Carl Wuyts

GCD System Architect Networking

Connect Division

carl.wuyts@technicolor.com =20

tel.: +32 3 443 65 90

  =20

  =20

Prins Boudewijnlaan 47  -  2650 Edegem  -  Belgium

Technicolor Delivery Technologies Belgium NV

Registered office (maatschappelijke zetel): Prins Boudewijnlaan 47, 2650
Edegem, Belgium

Company registration number (ondernemingsnummer): 0428837295 - RPR
Antwerpen

=20

Help preserve the color of our world - Think before you print.

=20

=20


------_=_NextPart_002_01CCA9CA.CF160B5D
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Carl,
 
Not a surprise.  =
Even the -02 version includes the MAX_SOL_RT text as shown below.  =
We changed the text a little since Ralph’s draft has been =
published and we could reference the document.
 
[WAA-8:  The IPv6 CE router MUST set SOL_MAX_RT (specified =
by
  =
         [RFC3315]) to 7200 =
seconds.]
 
During the IETF in Taipei the MAX_SOL_RT was =
discussed in the v6ops WG and also the DHC WG.  We  have rough =
consensus to move forward with this requirement to alleviate a DHCPv6 =
server storm. 
 
Hemant
 
From:=
 =
v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of =
Wuyts Carl
Sent: Wednesday, November 23, 2011 4:59 =
AM
To: v6ops@ietf.org
Subject: [v6ops] =
RFC6204bis-03
 
I must say =
I’m a bit surprised to already see the SOL_MAX_RT req popping up =
as a “MUST” into this version of RFC6204bis as it’s =
still quite heavily discussed (and by the looks of it, not really =
commonly accepted).  Isn’t it a bit too early to do this =
already ?
 
This is the req I’m talking =
about:
WAA-8:  The CE Router =
MUST parse the DHCPv6 SOL_MAX_RT option
         &=
nbsp; [I-D.droms-dhc-dhcpv6-maxsolrt-update] in a received =
DHCPv6
         &=
nbsp; Advertise or Reply message and set its internal =
SOL_MAX_RT
         &=
nbsp; parameter to the value contained in the SOL_MAX_RT =
option.
 
Appendix message:
9.   Added a new WAN DHCPv6 requirement for =
SOL_MAX_RT of DHCPv6 so
        that if an =
service provider does not have DHCPv6 service enabled
        CE routers =
do not send too frequent DHCPv6 requests to the
        service =
provider DHCPv6 server
 
 
 
=

Carl =
Wuyts
GCD =
System Architect Networking
Connect Division
carl.wuyts@technicolor.com=

tel.: =
+32 3 443 65 90
3Dtwitter
3D"Visit
Prins =
Boudewijnlaan 47  -  2650 =
Edegem  -  Belgium
=
Technicolor Delivery Technologies Belgium NV
=
Registered office (maatschappelijke zetel): Prins Boudewijnlaan 47, 2650 =
Edegem, Belgium
=
Company registration number (ondernemingsnummer): 0428837295 - RPR =
Antwerpen
3DEco
Help preserve the color of our world - =
Think before you =
print.
 
 

------_=_NextPart_002_01CCA9CA.CF160B5D--

------_=_NextPart_001_01CCA9CA.CF160B5D
Content-Type: image/gif;
	name="image001.gif"
Content-Transfer-Encoding: base64
Content-ID: 
Content-Description: image001.gif
Content-Location: image001.gif

R0lGODlhGAAYAPcAAAAAAP///1Sfum/L64bW8o7h/ofU74fT7pHb9pfa8u75/VbD5VzG6FvF5l3G
513F5l/G51/F5mHH52PH6GPI6GPI52TH6GXJ6GbI6GnK6mjJ6WjK6WzL6m/M63HN6nPN6nTN63fR
7XnR7XTI5FeVqnnN537T7n7R7H/T7X3O6Y3f+4jV73m903/E2oDE2pTf+ZPc9JTa8Zfa8aDd8LDj
9MXr9+z5/er3+/r9/imy1yyx1S202S2z1zK43TW63jW32zS22Ta53Te73za32zq84Dm53Du73j2/
4j2+4T283z273kHB5D++4EHA4kG/4UPA40K/4UTB5EbD5UbB40rJ7EjD5ErG6EnE5knE5Ua720rE
5kvG507J607I6U3G50/K60u+3U2/4U7A4k2/3lLI6E/A31XN7lHC4VnP8FfL61PD4lXD5FXF41vR
8VfG5VO92lrJ51a+21i/21/O7F7L6VnB3VzE4mHN6l/H5V3D30+lvWDH41/E4GDF4WLH42rL6GvP
6l+2znLZ9W7Q62C1zGO50HXZ9HTY83ba9XXX8mW70nLO6nHN6We803rd+HXV73zf+mm91HXS62vA
12GpvWavw2ixxVmWp2qxxYDW7X3Q52yzxm+2yW60x4HS6HC2yXG3ynzD2I7a75Xb7pvh9F+HkqTg
8ajg76ff7qri8bPo97fm9Ljm9MXw/Mfw/NDz/dDx+tbx+dz0++H1++f5/uv5/Six1S+22jG01zK1
2EXD5E/M7U7H50yvyWPY91zJ5WjZ92za927b+HHY82G4z3Xd+FurwHXa9Xfc93ne+F+rv37h+2u/
1YDi/H7c9YHh+YLh+YXi+mqyxWuzxork+ovj+o3l+3K4ypXn+12PnJrm+qXp+63j8cLx/M/0/ef4
/Jfp+57q+6Xt/Kjv/avv/a3v/a7w/bPw/bzz/uP6/+z7/vP9/7fz/r30/sD0/sX1/sn2/tT4/9L2
/d/6/+X7/+b7/+r8/+v7/sz3/tr5/ub8/+39//v///3///7//////yH5BAEAAP8ALAAAAAAYABgA
AAj/AP8JHEiwoMGCAgggOGCg4YqHEB8aOPCCAEESKmR84MABg0cOHUKGHDCAA4gEBQaOiIHBwgQO
pmrQEEEhg80NGnJewACDhcAUJyBMwBArgL8ACkxc2MBUg8cLEEy0+PkhQoMZAerNmxegBoMLFChc
AFsBQggXAkswerBgVYB8+eLtu7GorgcKDipIcBBi6r8SHtiyCoAPH7x6AXAoxjELRYO9IUIJlGMn
jBi37zLHo2fPXj19/hT8WRMGDzGBb7LosIUqADp07WC7c9eOHbwAmnjwGBNIYBwwuHK0NleOOLnj
5MaxC+BpR64zp//JGQNkx6kA4rKXO8ede7oAe378/1BTSGCdMkNunfIXLhw4eQH6yU88KoiSImzK
/8tzpkiPVP1gg4013gRgYGKmEMEEE0a4oYhAeahhhA/c8FMNNdF0s4466tyzTgCrOAFFEnA0IhAf
bCQhhCkBVPMMNDDC+GI3AUiCBBNwRCJQH24wgUQmAWwjTDJEFllMNAGIcoQTdDAjkB9uODGFFLHw
o00wwGSZpS/bBJDJEk80+eQvTVQhxR2zBECLK6202c0rAchCxhVR3DGJb5I0gYUXVqRBCiy1BFqL
Dd+oMocVW+jyCCEC6ZEIIFps0cUXVOyCRhuYomEGFVx0wcsghlwyUC/DOHPIMcg4AskyzbS6DCSO
ICSDiDOCGFNQNspUYgkmm3TCCSjXgPJJJ9NIYwklpRyk7LIDBQQAOw==

------_=_NextPart_001_01CCA9CA.CF160B5D
Content-Type: image/gif;
	name="image002.gif"
Content-Transfer-Encoding: base64
Content-ID: 
Content-Description: image002.gif
Content-Location: image002.gif

R0lGODlhcgBFAOZ/AEGueqipqmgxkACLS4ORyPb294DFpZrMVqvi+sXr2Ie3laLXtnRHnLQlZO3J
2M+pxP7pJvqtgePqmqOIvYLKnACP1fewoXa65/vCov71sdqRnc6OpPvrlcU/benvs7qmzpzR8P/n
rc7imtLntMkhU/V7Hf/yl+fZ6f3HipjL7b+MraKs1h+WXIrU9fNrPv/dkaTIrpQpd/JlIr8kXv/o
ALa3uO0bLwCmUQC68pKSlf/CDgxNosvbKtvb3IzGP8nJyoiJjPaWgH+Ag3Z3euTk5Y3Y+MTfm+3t
7r/AwZubnvBSJQCZ3NLS0//eAwN+yE84la9fmdjkX//RSiPB855BhP/ILiCvY9HeRvLkCvmykSld
q/aNl4Dd+cPT6O85Q2m+Q6zRONnM5OPx0PR3OR2Z2eOttkCr4Lfbm//uQPWMWbeLscPbysbs/OP1
/ZeLwPaLN9blff/iEvXlByCi3nzB69eqvN7r4uzysHfDWSCKzu+Uh8R4pR6j4IVfqm1ucf///yH5
BAEAAH8ALAAAAAByAEUAAAf/gH+Cg4SFhoeIiYqLjI2Oj5CRkpOUlZaXmJmam5ydnp+goaKjpKWm
p6ipqqusra6vsLGys7S1tqF+Oat+freMubu9vorAkkhIlryqBQWXxZBEvD2VyqhEQtPJupJJScnC
pzV+2dTbqdWnSX4BNTWDR+01RIUFSO0/zX/AP+1Mg/x/iLRDku9PO0JH7NXA906hv0Ho/vSId2TQ
xB4Jf1gKwKujoB8deWn8OCTkkIp+gAAJGUBQjnUhgUAEB9Lkx5C58lUr8DLkSHE5Spqb1IMjkh7T
evgZ4o9JyYrR/Mib2FKfHyH4kPBq1rPGkR4lH1ZjsvQH0gDIlA7RSGSlN6uC/zgCmfcjrEFeQuRd
EkeO48g/IN2pQ2boasGV014+/MPRHdw/QsYZUve3wFO4R5YWBOlN3FtMfAetBJKj9EpdEQk9+/My
sWRB4hxXS3koNcdpypRWnXnXMejXf4SWHt4yNcShrVkDjy1o9lDehELnXldIGfNMoV0CJxSZnGrk
kpPDltpc2FZDK+eJlqwsmsx3V3trEvdXK5CKgvKJu59fLHjX5FxXjVz5fHUXEPmAJER5gkQ2UgHq
uHMdJiANkcNIK+WSQ2TraaiZPv8pFyB5jxWwkoUvLWjiVUlkmE01RJQERACRISifJhxR90cBNUTG
YkE1ZAgEYTnsxlgO8wSA5P8/F7pkDo8+AvFgj7wkoR5r5hChzlU1JNjkMGCGKeaYZJZp5pmqsIHA
mmyCkMKbcK4g55wrfGDnnR88oOeedZTh558WBCqoBRgUaigGISSqaAgZNOroHR5EKqkHI1Rq6QKY
ZroADJx2CoMdjxSAQBGkktoCHRekqioBrLZKgBsTxCqrGirUaqsGuOaqgR5B9OprBMAGG8ELxBb7
ggnIJmuCBMw2K4EIRkQb7RkUVGstBQpkq60CazTSRqmlnqrqqq6yCqusstqqrq65+uqusMGiYCyx
HCiLLAfONguttEZQe22122oLQ0GHsAGuqeOSW+656E6grq0bsIuru7/CG4H/vPMea++y+TK7r7T+
/huwtqAiMsXJKE/BBxkst5yHFjDHrAUDNNdMMxU450xFBzz3zLMXQAfthQtjFG30G1UkrXQVEDTt
dNNXRC31FWAcYPXVeFih9dZWsOD11ywAkAgOZJeNwxIVpK22Ezu07fYOTwgg99wCxGD33TE0MMPe
fJNgw9+A26CEDIQXXoIOiCeuQxM0NO44FjxELjkPYPhg+eVf3KD55jcM4PnnA4iNiNllo6122my/
3XbcdMuN9916872334H/PXjhhB+uOOKMO9445JNHXvnllmfOueagfy76IaSTbfrpqavOeuuv2x27
7LTXfjvuuu/eu+/ABz88//HGH5+858sb0vzZp6Ou+uqtu1799X3Xbjvuue/Ou++/By888cU7HvLO
l75CrO95a3sf3OJXt/nJbnb2Exz+ZNA9xX3vcf6jHAB9UD7OnS90Y2seAt33vunRrXp5e+AMshe4
7RlOf4vjHw3CN7nxYU6AnSNgCEk3wgpE720mnBsK6QdB+7kwf/q7YP/8BwcxOPGJC8DhBwtIiAO2
z4cKDKL8XkfEFUbwiBSEoRJpIIcomPGMUbiDIRIgRR2OToRXrEAX5kjHLvSBgUNUIQsBB8YSSOGP
gJRCHGRIA0ewUYBTTAQXFslILswhjoe4Y/zy+EASbOGSmNyCCyYog0OggYeQhgSAKEcJABa40RFm
gKQhThCGVrryAZR84CHSwElPgrISADhlI1J5RUc4IJaym2UtSZHL5FFREbxsny9RuAcHOPOZDjgE
BrJAzWpmoRQLMIA2t7kASCTzdI44ARTGSU4oPABN6EynOtfJzna6853wjKc850nPetrznvjMpz73
yc9++tMUgQAAOw==

------_=_NextPart_001_01CCA9CA.CF160B5D
Content-Type: image/gif;
	name="image003.gif"
Content-Transfer-Encoding: base64
Content-ID: 
Content-Description: image003.gif
Content-Location: image003.gif

R0lGODlhHAAhAMQAALHNVVqXGZu+IqbFNv79/ury0pK4H2SdaJzAJNjlq/3++vL34srdiSl5Mfj7
8OHrvDmDE5u+Kb3VbtDgm5jCnJC2IqDBJHqqHoazHsfYxcfco+/58f7///7+/v///f///yH5BAAA
AAAALAAAAAAcACEAAAX/4CeOZGmeaKqubOumXSfKL0rT9RiTe65/nl0vxxE1KB3Ph6b8KGYjT/Pn
ORwIHmy0FEQFCZRG5yldJnEqD6ezaWQIHMJDApAwCthgF8hbEqwEBQARAoWFEgskQWgiChwFDRoD
hpQCA3hLQGhxSWABFpQIlAMPT2NoeTIJEBigooavlzJDS0UdHAkBEAivAoSjDklTQAROuBYQn7+/
lBJJS01SUgoJoskWvaECCWUiHEEKtw+8BtegvoWxiYtqSmsLhBblEALn2hLDH3HTAIXYuhfqVeLF
TZ8SR3oSULKAQVeAChYi8kJwCUg4BcVkOOiXDgHDACAvXMBQoWQEOw6iahwsMCmdAI8CKoiciUEA
gAJ8aBC4xfKlz3QRsVGcoICMJidKOjhgMKCXqKcAJqSMIkwEuw8OHjCQwNVOggJPvqm4ZUJGuw47
lajlA0Sat28xyJZV9APasGEcvknBkU9TjJ1WrTZZE9hHihAAOw==

------_=_NextPart_001_01CCA9CA.CF160B5D--

From shemant@cisco.com  Wed Nov 23 02:53:54 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F340A21F8BAB for ; Wed, 23 Nov 2011 02:53:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.27
X-Spam-Level: 
X-Spam-Status: No, score=-6.27 tagged_above=-999 required=5 tests=[AWL=0.328,  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 gcy+bF-KqGQq for ; Wed, 23 Nov 2011 02:53:52 -0800 (PST)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 95ED521F8BA9 for ; Wed, 23 Nov 2011 02:53:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=9271; q=dns/txt; s=iport; t=1322045632; x=1323255232; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=LEZ5Mx9FGfPxRZNhWgcumVp0g1kOlZVVeiDJjpR7VS8=; b=XFJwJya4JUP49NgKJEqk95COmK9SpCFEDp1pJCG53fb0Svou0SF8l9/3 1kUBvSa6e5zlhvfh+b3OwKNTjB8vTAKNqnllWdpt3IF4OQBphyMuiaY6Y y1tJaYZQkMmAvLMagn0DQ/8EDCG6S4PHjszQN7AOdMvhwRVs2jzdnM5sH c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqsAAPfPzE6tJXG9/2dsb2JhbABEgk2XfpAYgQWBcgEBAQQSAQkRA1kCAQgRBAEBCwYXAQYBRQkIAQEEARIIGp4fAZ40iX9jBIggnlE
X-IronPort-AV: E=Sophos;i="4.69,558,1315180800"; d="scan'208,217";a="38437255"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-1.cisco.com with ESMTP; 23 Nov 2011 10:53:52 +0000
Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id pANArpMi001937;  Wed, 23 Nov 2011 10:53:51 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 23 Nov 2011 04:53:51 -0600
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCA9CE.2F78F5DC"
Date: Wed, 23 Nov 2011 04:53:50 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3035EEEBA@XMB-RCD-109.cisco.com>
In-Reply-To: <750BF7861EBBE048B3E648B4BB6E8F4F20B124DE@crexc50p>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] 6rd Sunsetting
Thread-Index: AcyjbMdrG8fQqDnpSiuXKDRY89QkRAAOym+wAYlntHA=
References:  <750BF7861EBBE048B3E648B4BB6E8F4F20B124DE@crexc50p>
From: "Hemant Singh (shemant)" 
To: "STARK, BARBARA H" , 
X-OriginalArrivalTime: 23 Nov 2011 10:53:51.0509 (UTC) FILETIME=[2FAC7450:01CCA9CE]
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 23 Nov 2011 10:53:54 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CCA9CE.2F78F5DC
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

=20

From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
Of STARK, BARBARA H
Sent: Tuesday, November 15, 2011 10:33 AM
To: v6ops@ietf.org
Subject: Re: [v6ops] 6rd Sunsetting

=20

=20

>But when the CE router was manually configured for 6rd, I have no clue
what this means. How is the manually-configured CE router supposed to
know whether or not 6rd is configured by >the SP? Some guidance in this
area would be appreciated. For example, should the CE router test to see
if the BR is reachable, and if not assume that 6rd is not configured by
the SP?

=20

How can a subscriber in the home manually configure the CE router for
four 6rd parameters including the IPv4 address of the BR unless the
subscriber called the SP and got the information to configure manually.
Thus the SP knows about the CPE router in the subscriber's home and also
the CE router does not need to test if 6rd is configured by the SP.  If
the CE router still wants to test, then use the NUD specified in section
8 of RFC 5969.

=20

Hemant


------_=_NextPart_001_01CCA9CE.2F78F5DC
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


 
From:=
 =
v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of =
STARK, BARBARA H
Sent: Tuesday, November 15, 2011 10:33 =
AM
To: v6ops@ietf.org
Subject: Re: [v6ops] 6rd =
Sunsetting
 
 
>But when the CE router was manually configured for 6rd, I have no =
clue what this means. How is the manually-configured CE router supposed =
to know whether or not 6rd is configured by >the SP? Some guidance in this area would be appreciated. For example, =
should the CE router test to see if the BR is reachable, and if not =
assume that 6rd is not configured by the SP?
 
How can a subscriber in the home manually configure the CE router for =
four 6rd parameters including the IPv4 address of the BR unless the =
subscriber called the SP and got the information to configure =
manually.  Thus the SP knows about the CPE router in the =
subscriber’s home and also the CE router does not need to test if =
6rd is configured by the SP.  If the CE router still wants to test, =
then use the NUD specified in section 8 of RFC =
5969.
 
Hemant

------_=_NextPart_001_01CCA9CE.2F78F5DC--

From Carl.Wuyts@technicolor.com  Wed Nov 23 02:57:43 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8481121F8BC5 for ; Wed, 23 Nov 2011 02:57:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.195
X-Spam-Level: 
X-Spam-Status: No, score=-4.195 tagged_above=-999 required=5 tests=[AWL=-0.617, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jkn4evimwxSx for ; Wed, 23 Nov 2011 02:57:41 -0800 (PST)
Received: from na3sys009aog106.obsmtp.com (na3sys009aob106.obsmtp.com [74.125.149.76]) by ietfa.amsl.com (Postfix) with ESMTP id 7607321F8BC4 for ; Wed, 23 Nov 2011 02:57:38 -0800 (PST)
Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob106.postini.com ([74.125.148.12]) with SMTP ID DSNKTszRoRfOKUDVs1DydIt5ElEdqj6JhdLF@postini.com; Wed, 23 Nov 2011 02:57:39 PST
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.192.1; Wed, 23 Nov 2011 11:52:59 +0100
Received: from MOPESMBX01.eu.thmulti.com ([169.254.155.121]) by MOPESMAILHC01.eu.thmulti.com ([141.11.100.25]) with mapi; Wed, 23 Nov 2011 11:53:04 +0100
From: Wuyts Carl 
To: "Hemant Singh (shemant)" , "v6ops@ietf.org" 
Date: Wed, 23 Nov 2011 11:53:03 +0100
Thread-Topic: [v6ops] RFC6204bis-03
Thread-Index: AcypxoQV5eFbzgXCTbaCf1D51oSJ6wAA9B8AAADbfRA=
Message-ID: <867F4B6A1672E541A94676D556793ACD0C2766DF60@MOPESMBX01.eu.thmulti.com>
References: <867F4B6A1672E541A94676D556793ACD0C2766DEE7@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EEEB6@XMB-RCD-109.cisco.com>
In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3035EEEB6@XMB-RCD-109.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/related; boundary="_006_867F4B6A1672E541A94676D556793ACD0C2766DF60MOPESMBX01eut_"; type="multipart/alternative"
MIME-Version: 1.0
Subject: Re: [v6ops] RFC6204bis-03
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 23 Nov 2011 10:57:43 -0000

--_006_867F4B6A1672E541A94676D556793ACD0C2766DF60MOPESMBX01eut_
Content-Type: multipart/alternative;
	boundary="_000_867F4B6A1672E541A94676D556793ACD0C2766DF60MOPESMBX01eut_"

--_000_867F4B6A1672E541A94676D556793ACD0C2766DF60MOPESMBX01eut_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Correct, but the req is quite different to implement from CPEs point-of-vie=
w and, as you mention, discussed in DHC WG.  You mention a "rough consensus=
"; I must say I did not really see a real consensus in the big load of emai=
ls on the topic. So might have missed that one.

Carl Wuyts
GCD System Architect Networking
Connect Division

carl.wuyts@technicolor.com
tel.: +32 3 443 65 90
[cid:image001.gif@01CCA9D6.74B42400]
[cid:image002.gif@01CCA9D6.74B42400]
Prins Boudewijnlaan 47  -  2650 Edegem  -  Belgium

Technicolor Delivery Technologies Belgium NV
Registered office (maatschappelijke zetel): Prins Boudewijnlaan 47, 2650 Ed=
egem, Belgium
Company registration number (ondernemingsnummer): 0428837295 - RPR Antwerpe=
n
[cid:image003.gif@01CCA9D6.74B42400]

Help preserve the color of our world - Think before you print.





From: Hemant Singh (shemant) [mailto:shemant@cisco.com]
Sent: woensdag 23 november 2011 11:30
To: Wuyts Carl; v6ops@ietf.org
Subject: RE: [v6ops] RFC6204bis-03

Carl,

Not a surprise.  Even the -02 version includes the MAX_SOL_RT text as shown=
 below.  We changed the text a little since Ralph's draft has been publishe=
d and we could reference the document.

[WAA-8:  The IPv6 CE router MUST set SOL_MAX_RT (specified by
           [RFC3315]) to 7200 seconds.]

During the IETF in Taipei the MAX_SOL_RT was discussed in the v6ops WG and =
also the DHC WG.  We  have rough consensus to move forward with this requir=
ement to alleviate a DHCPv6 server storm.

Hemant

From: v6ops-bounces@ietf.org [mailto:v6ops-b=
ounces@ietf.org] On Behalf Of Wuyts Carl
Sent: Wednesday, November 23, 2011 4:59 AM
To: v6ops@ietf.org
Subject: [v6ops] RFC6204bis-03

I must say I'm a bit surprised to already see the SOL_MAX_RT req popping up=
 as a "MUST" into this version of RFC6204bis as it's still quite heavily di=
scussed (and by the looks of it, not really commonly accepted).  Isn't it a=
 bit too early to do this already ?

This is the req I'm talking about:
WAA-8:  The CE Router MUST parse the DHCPv6 SOL_MAX_RT option
           [I-D.droms-dhc-dhcpv6-maxsolrt-update] in a received DHCPv6
           Advertise or Reply message and set its internal SOL_MAX_RT
           parameter to the value contained in the SOL_MAX_RT option.

Appendix message:
9.   Added a new WAN DHCPv6 requirement for SOL_MAX_RT of DHCPv6 so
        that if an service provider does not have DHCPv6 service enabled
        CE routers do not send too frequent DHCPv6 requests to the
        service provider DHCPv6 server



Carl Wuyts
GCD System Architect Networking
Connect Division

carl.wuyts@technicolor.com
tel.: +32 3 443 65 90
[cid:image001.gif@01CCA9D6.74B42400]
[cid:image002.gif@01CCA9D6.74B42400]
Prins Boudewijnlaan 47  -  2650 Edegem  -  Belgium

Technicolor Delivery Technologies Belgium NV
Registered office (maatschappelijke zetel): Prins Boudewijnlaan 47, 2650 Ed=
egem, Belgium
Company registration number (ondernemingsnummer): 0428837295 - RPR Antwerpe=
n
[cid:image003.gif@01CCA9D6.74B42400]

Help preserve the color of our world - Think before you print.






--_000_867F4B6A1672E541A94676D556793ACD0C2766DF60MOPESMBX01eut_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Correct, but the req is quite different to implement from CPE=
s point-of-view and, as you mention, discussed in DHC WG.  You mention=
 a “rough consensus”; I must say I did not really see a real co=
nsensus in the big load of emails on the topic. So might have missed that o=
ne.
 
<=
/tr>
GCD S=
ystem Architect Networking
Connect Division
carl.wuyts@technicolor.com
tel.: +32 3 443 65 90
=
3Dtwitter<=
/span>
3D"Visit
=

Prins Boudewijnlaan 47  - &n=
bsp;2650 Edegem  -  Belgium
Tec=
hnicolor Delivery Technologies Belgium NV
Registered =
office (maatschappelijke zetel): Prins Boudewijnlaan 47, 2650 Edegem, Belgi=
um
Company registratio=
n number (ondernemingsnummer): 0428837295 - RPR Antwerpen=

3DEco
Help preserve the color of our world - Think before you =
print.
 
 
From: Hemant Sin=
gh (shemant) [mailto:shemant@cisco.com] 
Sent: woensdag 23 novemb=
er 2011 11:30
To: Wuyts Carl; v6ops@ietf.org
Subject: R=
E: [v6ops] RFC6204bis-03
 
Carl,
 
Not a surprise.  Even the -02 version includes the MAX_SOL_RT =
text as shown below.  We changed the text a little since Ralph’s=
 draft has been published and we could reference the document.
 
[WAA-8:  The IPv6 CE router MUST set SOL_MAX_RT (spe=
cified by
       &n=
bsp;   [RFC3315]) to 7200 seconds.]
During the IETF in Taipei the MAX_SOL_RT was discussed in the v6ops W=
G and also the DHC WG.  We  have rough consensus to move forward =
with this requirement to alleviate a DHCPv6 server storm. 
 
Hemant
 =

From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of W=
uyts Carl
Sent: Wednesday, November 23, 2011 4:59 AM
To: v6ops@ietf.org
Subject: [=
v6ops] RFC6204bis-03
=
 
I must say I’m a bit surpri=
sed to already see the SOL_MAX_RT req popping up as a “MUST” in=
to this version of RFC6204bis as it’s still quite heavily discussed (=
and by the looks of it, not really commonly accepted).  Isn’t it=
 a bit too early to do this already ?
 
This is the req I’m talking a=
bout:
WAA-8:  The CE Router MUST pa=
rse the DHCPv6 SOL_MAX_RT option
 &=
nbsp;         [I-D.droms-dhc-dhcpv6=
-maxsolrt-update] in a received DHCPv6
&=
nbsp;          Advertise or Re=
ply message and set its internal SOL_MAX_RT
           parameter =
to the value contained in the SOL_MAX_RT option.
 
Appendix message:
9.   Added a new WAN DHCPv6 requirem=
ent for SOL_MAX_RT of DHCPv6 so
 &n=
bsp;      that if an service provider does not hav=
e DHCPv6 service enabled
  &nb=
sp;     CE routers do not send too frequent DHCPv6 requ=
ests to the
    &nbs=
p;   service provider DHCPv6 server
 
 
 
<=
tr>
Carl Wuyts=

GCD System Architect Networking=

Connect D=
ivision
carl.wuyts@technicolor.com
tel.: +32 3 443 65 90=

3Dtwitter=

3D"Visit
Prins Boudewijnlaan 47  -  2=
650 Edegem  -  Belgium
Technic=
olor Delivery Technologies Belgium NV
Registered office (maatschappelijke zetel): Pr=
ins Boudewijnlaan 47, 2650 Edegem, Belgium
Company registration number (ondernemingsnummer): 0428=
837295 - RPR Antwerpen
3DEco
Help preserve the color of ou=
r world - Think before you print.
 
 
=

--_000_867F4B6A1672E541A94676D556793ACD0C2766DF60MOPESMBX01eut_--

--_006_867F4B6A1672E541A94676D556793ACD0C2766DF60MOPESMBX01eut_
Content-Type: image/gif; name="image001.gif"
Content-Description: image001.gif
Content-Disposition: inline; filename="image001.gif"; size=1351;
	creation-date="Wed, 23 Nov 2011 10:53:02 GMT";
	modification-date="Wed, 23 Nov 2011 10:53:02 GMT"
Content-ID: 
Content-Transfer-Encoding: base64

R0lGODlhGAAYAPcAAAAAAP///1Sfum/L64bW8o7h/ofU74fT7pHb9pfa8u75/VbD5VzG6FvF5l3G
513F5l/G51/F5mHH52PH6GPI6GPI52TH6GXJ6GbI6GnK6mjJ6WjK6WzL6m/M63HN6nPN6nTN63fR
7XnR7XTI5FeVqnnN537T7n7R7H/T7X3O6Y3f+4jV73m903/E2oDE2pTf+ZPc9JTa8Zfa8aDd8LDj
9MXr9+z5/er3+/r9/imy1yyx1S202S2z1zK43TW63jW32zS22Ta53Te73za32zq84Dm53Du73j2/
4j2+4T283z273kHB5D++4EHA4kG/4UPA40K/4UTB5EbD5UbB40rJ7EjD5ErG6EnE5knE5Ua720rE
5kvG507J607I6U3G50/K60u+3U2/4U7A4k2/3lLI6E/A31XN7lHC4VnP8FfL61PD4lXD5FXF41vR
8VfG5VO92lrJ51a+21i/21/O7F7L6VnB3VzE4mHN6l/H5V3D30+lvWDH41/E4GDF4WLH42rL6GvP
6l+2znLZ9W7Q62C1zGO50HXZ9HTY83ba9XXX8mW70nLO6nHN6We803rd+HXV73zf+mm91HXS62vA
12GpvWavw2ixxVmWp2qxxYDW7X3Q52yzxm+2yW60x4HS6HC2yXG3ynzD2I7a75Xb7pvh9F+HkqTg
8ajg76ff7qri8bPo97fm9Ljm9MXw/Mfw/NDz/dDx+tbx+dz0++H1++f5/uv5/Six1S+22jG01zK1
2EXD5E/M7U7H50yvyWPY91zJ5WjZ92za927b+HHY82G4z3Xd+FurwHXa9Xfc93ne+F+rv37h+2u/
1YDi/H7c9YHh+YLh+YXi+mqyxWuzxork+ovj+o3l+3K4ypXn+12PnJrm+qXp+63j8cLx/M/0/ef4
/Jfp+57q+6Xt/Kjv/avv/a3v/a7w/bPw/bzz/uP6/+z7/vP9/7fz/r30/sD0/sX1/sn2/tT4/9L2
/d/6/+X7/+b7/+r8/+v7/sz3/tr5/ub8/+39//v///3///7//////yH5BAEAAP8ALAAAAAAYABgA
AAj/AP8JHEiwoMGCAgggOGCg4YqHEB8aOPCCAEESKmR84MABg0cOHUKGHDCAA4gEBQaOiIHBwgQO
pmrQEEEhg80NGnJewACDhcAUJyBMwBArgL8ACkxc2MBUg8cLEEy0+PkhQoMZAerNmxegBoMLFChc
AFsBQggXAkswerBgVYB8+eLtu7GorgcKDipIcBBi6r8SHtiyCoAPH7x6AXAoxjELRYO9IUIJlGMn
jBi37zLHo2fPXj19/hT8WRMGDzGBb7LosIUqADp07WC7c9eOHbwAmnjwGBNIYBwwuHK0NleOOLnj
5MaxC+BpR64zp//JGQNkx6kA4rKXO8ede7oAe378/1BTSGCdMkNunfIXLhw4eQH6yU88KoiSImzK
/8tzpkiPVP1gg4013gRgYGKmEMEEE0a4oYhAeahhhA/c8FMNNdF0s4466tyzTgCrOAFFEnA0IhAf
bCQhhCkBVPMMNDDC+GI3AUiCBBNwRCJQH24wgUQmAWwjTDJEFllMNAGIcoQTdDAjkB9uODGFFLHw
o00wwGSZpS/bBJDJEk80+eQvTVQhxR2zBECLK6202c0rAchCxhVR3DGJb5I0gYUXVqRBCiy1BFqL
Dd+oMocVW+jyCCEC6ZEIIFps0cUXVOyCRhuYomEGFVx0wcsghlwyUC/DOHPIMcg4AskyzbS6DCSO
ICSDiDOCGFNQNspUYgkmm3TCCSjXgPJJJ9NIYwklpRyk7LIDBQQAOw==

--_006_867F4B6A1672E541A94676D556793ACD0C2766DF60MOPESMBX01eut_
Content-Type: image/gif; name="image002.gif"
Content-Description: image002.gif
Content-Disposition: inline; filename="image002.gif"; size=1834;
	creation-date="Wed, 23 Nov 2011 10:53:03 GMT";
	modification-date="Wed, 23 Nov 2011 10:53:03 GMT"
Content-ID: 
Content-Transfer-Encoding: base64

R0lGODlhcgBFAOZ/AEGueqipqmgxkACLS4ORyPb294DFpZrMVqvi+sXr2Ie3laLXtnRHnLQlZO3J
2M+pxP7pJvqtgePqmqOIvYLKnACP1fewoXa65/vCov71sdqRnc6OpPvrlcU/benvs7qmzpzR8P/n
rc7imtLntMkhU/V7Hf/yl+fZ6f3HipjL7b+MraKs1h+WXIrU9fNrPv/dkaTIrpQpd/JlIr8kXv/o
ALa3uO0bLwCmUQC68pKSlf/CDgxNosvbKtvb3IzGP8nJyoiJjPaWgH+Ag3Z3euTk5Y3Y+MTfm+3t
7r/AwZubnvBSJQCZ3NLS0//eAwN+yE84la9fmdjkX//RSiPB855BhP/ILiCvY9HeRvLkCvmykSld
q/aNl4Dd+cPT6O85Q2m+Q6zRONnM5OPx0PR3OR2Z2eOttkCr4Lfbm//uQPWMWbeLscPbysbs/OP1
/ZeLwPaLN9blff/iEvXlByCi3nzB69eqvN7r4uzysHfDWSCKzu+Uh8R4pR6j4IVfqm1ucf///yH5
BAEAAH8ALAAAAAByAEUAAAf/gH+Cg4SFhoeIiYqLjI2Oj5CRkpOUlZaXmJmam5ydnp+goaKjpKWm
p6ipqqusra6vsLGys7S1tqF+Oat+freMubu9vorAkkhIlryqBQWXxZBEvD2VyqhEQtPJupJJScnC
pzV+2dTbqdWnSX4BNTWDR+01RIUFSO0/zX/AP+1Mg/x/iLRDku9PO0JH7NXA906hv0Ho/vSId2TQ
xB4Jf1gKwKujoB8deWn8OCTkkIp+gAAJGUBQjnUhgUAEB9Lkx5C58lUr8DLkSHE5Spqb1IMjkh7T
evgZ4o9JyYrR/Mib2FKfHyH4kPBq1rPGkR4lH1ZjsvQH0gDIlA7RSGSlN6uC/zgCmfcjrEFeQuRd
EkeO48g/IN2pQ2boasGV014+/MPRHdw/QsYZUve3wFO4R5YWBOlN3FtMfAetBJKj9EpdEQk9+/My
sWRB4hxXS3koNcdpypRWnXnXMejXf4SWHt4yNcShrVkDjy1o9lDehELnXldIGfNMoV0CJxSZnGrk
kpPDltpc2FZDK+eJlqwsmsx3V3trEvdXK5CKgvKJu59fLHjX5FxXjVz5fHUXEPmAJER5gkQ2UgHq
uHMdJiANkcNIK+WSQ2TraaiZPv8pFyB5jxWwkoUvLWjiVUlkmE01RJQERACRISifJhxR90cBNUTG
YkE1ZAgEYTnsxlgO8wSA5P8/F7pkDo8+AvFgj7wkoR5r5hChzlU1JNjkMGCGKeaYZJZp5pmqsIHA
mmyCkMKbcK4g55wrfGDnnR88oOeedZTh558WBCqoBRgUaigGISSqaAgZNOroHR5EKqkHI1Rq6QKY
ZroADJx2CoMdjxSAQBGkktoCHRekqioBrLZKgBsTxCqrGirUaqsGuOaqgR5B9OprBMAGG8ELxBb7
ggnIJmuCBMw2K4EIRkQb7RkUVGstBQpkq60CazTSRqmlnqrqqq6yCqusstqqrq65+uqusMGiYCyx
HCiLLAfONguttEZQe22122oLQ0GHsAGuqeOSW+656E6grq0bsIuru7/CG4H/vPMea++y+TK7r7T+
/huwtqAiMsXJKE/BBxkst5yHFjDHrAUDNNdMMxU450xFBzz3zLMXQAfthQtjFG30G1UkrXQVEDTt
dNNXRC31FWAcYPXVeFih9dZWsOD11ywAkAgOZJeNwxIVpK22Ezu07fYOTwgg99wCxGD33TE0MMPe
fJNgw9+A26CEDIQXXoIOiCeuQxM0NO44FjxELjkPYPhg+eVf3KD55jcM4PnnA4iNiNllo6122my/
3XbcdMuN9916872334H/PXjhhB+uOOKMO9445JNHXvnllmfOueagfy76IaSTbfrpqavOeuuv2x27
7LTXfjvuuu/eu+/ABz88//HGH5+858sb0vzZp6Ou+uqtu1799X3Xbjvuue/Ou++/By888cU7HvLO
l75CrO95a3sf3OJXt/nJbnb2Exz+ZNA9xX3vcf6jHAB9UD7OnS90Y2seAt33vunRrXp5e+AMshe4
7RlOf4vjHw3CN7nxYU6AnSNgCEk3wgpE720mnBsK6QdB+7kwf/q7YP/8BwcxOPGJC8DhBwtIiAO2
z4cKDKL8XkfEFUbwiBSEoRJpIIcomPGMUbiDIRIgRR2OToRXrEAX5kjHLvSBgUNUIQsBB8YSSOGP
gJRCHGRIA0ewUYBTTAQXFslILswhjoe4Y/zy+EASbOGSmNyCCyYog0OggYeQhgSAKEcJABa40RFm
gKQhThCGVrryAZR84CHSwElPgrISADhlI1J5RUc4IJaym2UtSZHL5FFREbxsny9RuAcHOPOZDjgE
BrJAzWpmoRQLMIA2t7kASCTzdI44ARTGSU4oPABN6EynOtfJzna6853wjKc850nPetrznvjMpz73
yc9++tMUgQAAOw==

--_006_867F4B6A1672E541A94676D556793ACD0C2766DF60MOPESMBX01eut_
Content-Type: image/gif; name="image003.gif"
Content-Description: image003.gif
Content-Disposition: inline; filename="image003.gif"; size=493;
	creation-date="Wed, 23 Nov 2011 10:53:03 GMT";
	modification-date="Wed, 23 Nov 2011 10:53:03 GMT"
Content-ID: 
Content-Transfer-Encoding: base64

R0lGODlhHAAhAMQAALHNVVqXGZu+IqbFNv79/ury0pK4H2SdaJzAJNjlq/3++vL34srdiSl5Mfj7
8OHrvDmDE5u+Kb3VbtDgm5jCnJC2IqDBJHqqHoazHsfYxcfco+/58f7///7+/v///f///yH5BAAA
AAAALAAAAAAcACEAAAX/4CeOZGmeaKqubOumXSfKL0rT9RiTe65/nl0vxxE1KB3Ph6b8KGYjT/Pn
ORwIHmy0FEQFCZRG5yldJnEqD6ezaWQIHMJDApAwCthgF8hbEqwEBQARAoWFEgskQWgiChwFDRoD
hpQCA3hLQGhxSWABFpQIlAMPT2NoeTIJEBigooavlzJDS0UdHAkBEAivAoSjDklTQAROuBYQn7+/
lBJJS01SUgoJoskWvaECCWUiHEEKtw+8BtegvoWxiYtqSmsLhBblEALn2hLDH3HTAIXYuhfqVeLF
TZ8SR3oSULKAQVeAChYi8kJwCUg4BcVkOOiXDgHDACAvXMBQoWQEOw6iahwsMCmdAI8CKoiciUEA
gAJ8aBC4xfKlz3QRsVGcoICMJidKOjhgMKCXqKcAJqSMIkwEuw8OHjCQwNVOggJPvqm4ZUJGuw47
lajlA0Sat28xyJZV9APasGEcvknBkU9TjJ1WrTZZE9hHihAAOw==

--_006_867F4B6A1672E541A94676D556793ACD0C2766DF60MOPESMBX01eut_--

From shemant@cisco.com  Wed Nov 23 03:00:37 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5260721F8BDE for ; Wed, 23 Nov 2011 03:00:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.273
X-Spam-Level: 
X-Spam-Status: No, score=-6.273 tagged_above=-999 required=5 tests=[AWL=0.325,  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 B1o49PteLp6Q for ; Wed, 23 Nov 2011 03:00:36 -0800 (PST)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 1CBEF21F8BC5 for ; Wed, 23 Nov 2011 03:00:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=13439; q=dns/txt; s=iport; t=1322046036; x=1323255636; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=/axlyFB90zehscUtxf3reRi+OgEPqAXJXoSo1NZ8Xwk=; b=BLyl/n3S5ES9gJB9eyVusHFdznfKVoi0wH6qT6WbuuZ4B+csyF7xBljc tzqBIzbbwzSHcHn3YOGbkm/OO1nzytW1DJ04UdIZOOAuK/UnV1iJLYrlm gv0rAjD6fnVWU759iz2pIpqBKZdYdFpsb/iB14q89HuludWYmSubYQAfK Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqsAAB7SzE6tJV2d/2dsb2JhbABEgk2XfpAYgQWBcgEBAQQSAQkRA0kMBAIBCBEEAQELBhcBBgEgJQkIAQEEARIIGp4bAZ42iX9jBIggln2HVA
X-IronPort-AV: E=Sophos;i="4.69,558,1315180800"; d="scan'208,217";a="38435590"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP; 23 Nov 2011 11:00:35 +0000
Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id pANB0Zjc031993;  Wed, 23 Nov 2011 11:00:35 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 23 Nov 2011 05:00:35 -0600
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCA9CF.201CBC52"
Date: Wed, 23 Nov 2011 05:00:33 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3035EEEBB@XMB-RCD-109.cisco.com>
In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3035EEEB3@XMB-RCD-109.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
Thread-Index: AcypqhqKdbbVwVeKTleilbkpNBpyGgAGSOHQAALrQ2A=
References: <20111122190508.3293.41916.idtracker@ietfa.amsl.com><5B6B2B64C9FE2A489045EEEADDAFF2C3035EED43@XMB-RCD-109.cisco.com><750BF7861EBBE048B3E648B4BB6E8F4F20EA14A5@crexc50p><8295A151-79B7-452B-BF7B-30241EDBBFF2@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EEEB3@XMB-RCD-109.cisco.com>
From: "Hemant Singh (shemant)" 
To: "Hemant Singh (shemant)" , "jouni korhonen" , "STARK, BARBARA H" 
X-OriginalArrivalTime: 23 Nov 2011 11:00:35.0343 (UTC) FILETIME=[2060A1F0:01CCA9CF]
Cc: v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-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, 23 Nov 2011 11:00:37 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CCA9CF.201CBC52
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Humble apologies that I cut-and-paste the wrong paragraph from section
12.1 of RFC 3633.  The correct paragraph is below.

=20

  [If the requesting router assigns a delegated prefix to a link to

   which the router is attached, and begins to send router

   advertisements for the prefix on the link, the requesting router MUST

   set the valid lifetime in those advertisements to be no later than

   the valid lifetime specified in the IA_PD Prefix option.  A

   requesting router MAY use the preferred lifetime specified in the

   IA_PD Prefix option.]

=20

Hemant

=20

From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
Of Hemant Singh (shemant)
Sent: Wednesday, November 23, 2011 4:54 AM
To: jouni korhonen; STARK, BARBARA H
Cc: v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt

=20

=20

=20

-----Original Message-----
From: jouni korhonen [mailto:jouni.nospam@gmail.com]=20
Sent: Wednesday, November 23, 2011 1:35 AM
To: STARK, BARBARA H
Cc: Hemant Singh (shemant); v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt

=20

=20

>There are non-trivial scenarios related, for example, lifetimes of
delegated prefixes since the WAN link prefix and delegated prefixes >are
interlinked. But I guess any CE independent of technology would have
some level of issues if WAN link prefix renumbering would cause
>renumbering of the delegated prefix set.

=20

The above issues are clearly clarified in RFC 3633.  See this text from
section 12.1.

=20

[Each prefix has valid and preferred lifetimes whose durations are

specified in the IA_PD Prefix option for that prefix.  The requesting

router uses Renew and Rebind messages to request the extension of the

lifetimes of a delegated prefix.]

=20

The same text also applies to the exclude pd option.

=20

=20

>So far the PD peculiarities and WAN interface DHCPv6 details are the
issues. Other stuff seems to be OK.

=20

It would be interesting to know the peculiarities.=20

=20

Hemant

=20


------_=_NextPart_001_01CCA9CF.201CBC52
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Humble apologies that I cut-and-paste the wrong =
paragraph from section 12.1 of RFC 3633.  The correct paragraph is =
below.
 
  [If the requesting router assigns a delegated =
prefix to a link to
   which the router is =
attached, and begins to send router
   advertisements for the =
prefix on the link, the requesting router MUST
   set the valid lifetime =
in those advertisements to be no later than
   the valid lifetime =
specified in the IA_PD Prefix option.  A
   requesting router MAY =
use the preferred lifetime specified in the
   IA_PD Prefix =
option.]
 
Hemant
 
From:=
 =
v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of =
Hemant Singh (shemant)
Sent: Wednesday, November 23, 2011 =
4:54 AM
To: jouni korhonen; STARK, BARBARA H
Cc: =
v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: =
draft-ietf-v6ops-6204bis-03.txt
 
 
 
-----Original Message-----
From: jouni korhonen =
[mailto:jouni.nospam@gmail.com] 
Sent: Wednesday, November 23, 2011 =
1:35 AM
To: STARK, BARBARA H
Cc: Hemant Singh (shemant); =
v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: =
draft-ietf-v6ops-6204bis-03.txt
 
 
>There are non-trivial scenarios related, for =
example, lifetimes of delegated prefixes since the WAN link prefix and =
delegated prefixes >are interlinked. But I guess any CE independent =
of technology would have some level of issues if WAN link prefix =
renumbering would cause >renumbering of the delegated prefix =
set.
 
The above issues are =
clearly clarified in RFC 3633.  See this text from section =
12.1.
 
[Each prefix has valid =
and preferred lifetimes whose durations are
specified in the IA_PD =
Prefix option for that prefix.  The =
requesting
router uses Renew and Rebind messages to request =
the extension of the
lifetimes of a delegated =
prefix.]
 
The same text also =
applies to the exclude pd option.
 
 
>So =
far the PD peculiarities and WAN interface DHCPv6 details are the =
issues. Other stuff seems to be OK.
 
It would be interesting to know the peculiarities. =

 
Hemant
 

------_=_NextPart_001_01CCA9CF.201CBC52--

From pch-b29AA871B@u-1.phicoh.com  Wed Nov 23 03:04:57 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 014CF21F8BDE for ; Wed, 23 Nov 2011 03:04:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.446
X-Spam-Level: 
X-Spam-Status: No, score=-8.446 tagged_above=-999 required=5 tests=[AWL=0.153,  BAYES_00=-2.599, GB_I_LETTER=-2, 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 aJcX7zK-27H5 for ; Wed, 23 Nov 2011 03:04:56 -0800 (PST)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 26FB121F8BE8 for ; Wed, 23 Nov 2011 03:04:56 -0800 (PST)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #76) id m1RTAdJ-0001icC; Wed, 23 Nov 2011 12:04:53 +0100
Message-Id: 
To: Hermin Anggawijaya 
From: Philip Homburg 
Sender: pch-b29AA871B@u-1.phicoh.com
References:  
In-reply-to: Your message of "Wed, 23 Nov 2011 13:41:17 +1300 ."  
Date: Wed, 23 Nov 2011 12:04:52 +0100
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Routers forwarding packet with link local source
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 23 Nov 2011 11:04:57 -0000

In your letter dated Wed, 23 Nov 2011 13:41:17 +1300 you wrote:
>I assume that none of the 9 routers in the path carry the "IPv6 Ready Logo" ?
>not that I claim the IPv6 Ready Logo is good or otherwise - debate
>this somewhere else,
>but at least to obtain the logo, any router must past self conformance
>tests which include
>link-local addressed packet forwarding requirement as specified in the RFC.
>
>Speaking as a vendor, no we don't ignore the requirement deliberately.

It looks like the routers are all Juniper, belonging to 3 different
origanisations. I've no idea whether they are 'IPv6 Ready' or not. :-)

One question is whether this is a bug or a feature. The effect is that the 
error ICMP arrives. Which is good, but proper (ingress) filtering is also good.



From ichiroumakino@gmail.com  Wed Nov 23 03:05:31 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E03A421F8C0C for ; Wed, 23 Nov 2011 03:05:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.26
X-Spam-Level: 
X-Spam-Status: No, score=-3.26 tagged_above=-999 required=5 tests=[AWL=-0.261,  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 9+p9sll67-FW for ; Wed, 23 Nov 2011 03:05:31 -0800 (PST)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id BD51621F8BE8 for ; Wed, 23 Nov 2011 03:05:30 -0800 (PST)
Received: by bkbzv15 with SMTP id zv15so1167717bkb.31 for ; Wed, 23 Nov 2011 03:05:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=qbI7+a1N2/1O/XK3HNj9jM6pmLtObJkiMVO2o+EO0dI=; b=EtwbuAUQX8x6tYRrRw5mXSa07PLibabFBMwKq0UKnJ4g8oPqwlq+y8IaBWMuMpQpyb VSJ2BexlJOK72kMMgNsMuXjjpch3SWBarRmPop38Q7o6IA22Sz20Sj/33zwfKN0xa0YW JBghSo86USp7JmYhsphjzdjwYMg8ckhI8Q46k=
Received: by 10.205.127.142 with SMTP id ha14mr23011375bkc.116.1322046291451;  Wed, 23 Nov 2011 03:04:51 -0800 (PST)
Received: from [10.147.13.57] (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id dq2sm12518220bkb.11.2011.11.23.03.04.50 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 23 Nov 2011 03:04:50 -0800 (PST)
Sender: Ole Troan 
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=windows-1252
From: Ole Troan 
In-Reply-To: <867F4B6A1672E541A94676D556793ACD0C2766DF60@MOPESMBX01.eu.thmulti.com>
Date: Wed, 23 Nov 2011 12:04:49 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <972420B3-D6DD-4843-9A47-B613E3EA4134@employees.org>
References: <867F4B6A1672E541A94676D556793ACD0C2766DEE7@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EEEB6@XMB-RCD-109.cisco.com> <867F4B6A1672E541A94676D556793ACD0C2766DF60@MOPESMBX01.eu.thmulti.com>
To: Wuyts Carl 
X-Mailer: Apple Mail (2.1084)
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] RFC6204bis-03
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 23 Nov 2011 11:05:32 -0000

Carl,

> Correct, but the req is quite different to implement from CPEs =
point-of-view and, as you mention, discussed in DHC WG.  You mention a =
=93rough consensus=94; I must say I did not really see a real consensus =
in the big load of emails on the topic. So might have missed that one.

indeed. this is work in progress. there are other changes needed in DHCP =
too.

cheers,
Ole


> =20
> Carl Wuyts
> GCD System Architect Networking
> CONNECT DIVISION
> carl.wuyts@technicolor.com
> tel.: +32 3 443 65 90
> 
> 
> Prins Boudewijnlaan 47  -  2650 Edegem  -  Belgium
> Technicolor Delivery Technologies Belgium NV
> Registered office (maatschappelijke zetel): Prins Boudewijnlaan 47, =
2650 Edegem, Belgium
> Company registration number (ondernemingsnummer): 0428837295 - RPR =
Antwerpen
> 
> Help preserve the color of our world - Think before you print.
> =20
> =20
> From: Hemant Singh (shemant) [mailto:shemant@cisco.com]=20
> Sent: woensdag 23 november 2011 11:30
> To: Wuyts Carl; v6ops@ietf.org
> Subject: RE: [v6ops] RFC6204bis-03
> =20
> Carl,
> =20
> Not a surprise.  Even the -02 version includes the MAX_SOL_RT text as =
shown below.  We changed the text a little since Ralph=92s draft has =
been published and we could reference the document.
> =20
> [WAA-8:  The IPv6 CE router MUST set SOL_MAX_RT (specified by
>            [RFC3315]) to 7200 seconds.]
> =20
> During the IETF in Taipei the MAX_SOL_RT was discussed in the v6ops WG =
and also the DHC WG.  We  have rough consensus to move forward with this =
requirement to alleviate a DHCPv6 server storm.
> =20
> Hemant
> =20
> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf =
Of Wuyts Carl
> Sent: Wednesday, November 23, 2011 4:59 AM
> To: v6ops@ietf.org
> Subject: [v6ops] RFC6204bis-03
> =20
> I must say I=92m a bit surprised to already see the SOL_MAX_RT req =
popping up as a =93MUST=94 into this version of RFC6204bis as it=92s =
still quite heavily discussed (and by the looks of it, not really =
commonly accepted).  Isn=92t it a bit too early to do this already ?
> =20
> This is the req I=92m talking about:
> WAA-8:  The CE Router MUST parse the DHCPv6 SOL_MAX_RT option
>            [I-D.droms-dhc-dhcpv6-maxsolrt-update] in a received DHCPv6
>            Advertise or Reply message and set its internal SOL_MAX_RT
>            parameter to the value contained in the SOL_MAX_RT option.
> =20
> Appendix message:
> 9.   Added a new WAN DHCPv6 requirement for SOL_MAX_RT of DHCPv6 so
>         that if an service provider does not have DHCPv6 service =
enabled
>         CE routers do not send too frequent DHCPv6 requests to the
>         service provider DHCPv6 server
> =20
> =20
> =20
> Carl Wuyts
> GCD System Architect Networking
> CONNECT DIVISION
> carl.wuyts@technicolor.com
> tel.: +32 3 443 65 90
> 
> 
> Prins Boudewijnlaan 47  -  2650 Edegem  -  Belgium
> Technicolor Delivery Technologies Belgium NV
> Registered office (maatschappelijke zetel): Prins Boudewijnlaan 47, =
2650 Edegem, Belgium
> Company registration number (ondernemingsnummer): 0428837295 - RPR =
Antwerpen
> 
> Help preserve the color of our world - Think before you print.
> =20
> =20
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


From shemant@cisco.com  Wed Nov 23 03:16:15 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A09D21F8C0F for ; Wed, 23 Nov 2011 03:16:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.276
X-Spam-Level: 
X-Spam-Status: No, score=-6.276 tagged_above=-999 required=5 tests=[AWL=0.322,  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 f-hYaTpV60cB for ; Wed, 23 Nov 2011 03:16:14 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 457F621F8B25 for ; Wed, 23 Nov 2011 03:16:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=9595; q=dns/txt; s=iport; t=1322046964; x=1323256564; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=b/IV1tBiLk1hFO7am6f+x6JVZuCkZr1LRdMngylXeMA=; b=nAnjiw2gsoQHlJDoEwEvhiJz1NEebn0MdoOKXsyjCIE+vObvb8dFW6yE FuwDSnX2cy2wr1JkyblUq/CIYSyS8S0U1Qs7zk8ceRA/lTVBFs5/A93+C 0rR8ssyhYQYDECI3KFbBPi1+Jlhj2ssQH9rBaMKC/WOyJaXJZOTAnBZSs o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqwAAHjVzE6tJV2d/2dsb2JhbABEgk2XfogfAYd4gQWBcgEBAQQSAQkRA1kCAQgRBAEBCwYXAQYBRQkIAQEEARIIGodrljQBnjeJf2MEiCCeUQ
X-IronPort-AV: E=Sophos;i="4.69,558,1315180800"; d="scan'208,217";a="38427259"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP; 23 Nov 2011 11:16:04 +0000
Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id pANBG3Ku009456;  Wed, 23 Nov 2011 11:16:03 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 23 Nov 2011 05:16:03 -0600
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCA9D1.49816421"
Date: Wed, 23 Nov 2011 05:16:02 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3035EEEBE@XMB-RCD-109.cisco.com>
In-Reply-To: <867F4B6A1672E541A94676D556793ACD0C2766DF60@MOPESMBX01.eu.thmulti.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] RFC6204bis-03
Thread-Index: AcypxoQV5eFbzgXCTbaCf1D51oSJ6wAA9B8AAADbfRAAAIQ9wA==
References: <867F4B6A1672E541A94676D556793ACD0C2766DEE7@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EEEB6@XMB-RCD-109.cisco.com> <867F4B6A1672E541A94676D556793ACD0C2766DF60@MOPESMBX01.eu.thmulti.com>
From: "Hemant Singh (shemant)" 
To: "Wuyts Carl" , 
X-OriginalArrivalTime: 23 Nov 2011 11:16:03.0810 (UTC) FILETIME=[49C97420:01CCA9D1]
Subject: Re: [v6ops] RFC6204bis-03
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 23 Nov 2011 11:16:15 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CCA9D1.49816421
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

=20

From: Wuyts Carl [mailto:Carl.Wuyts@technicolor.com]=20
Sent: Wednesday, November 23, 2011 5:53 AM
To: Hemant Singh (shemant); v6ops@ietf.org
Subject: RE: [v6ops] RFC6204bis-03

=20

>Correct, but the req is quite different to implement from CPEs
point-of-view and, as you mention, discussed in DHC WG.  You mention a
"rough consensus"; I must say I did not really see a >real consensus in
the big load of emails on the topic. So might have missed that one.

=20

The req changed between the -02 and the -03 versions of rfc6204bis
because at first we were given the 7200 value to change to for the
MAX_SOL_RT.  Then when the draft

=20

http://tools.ietf.org/html/draft-droms-dhc-dhcpv6-maxsolrt-update-00

=20

was published the value change to 3600.  It's RFC3315 that will be
updated by the maxsolrt-update draft for the 3600 value.   See section
2 of the maxsolrt-update draft.   Thereafter the maxsolrt-update draft
defines a new MAX_SOL_RT option in section 3 and that is what the -03
version of rfc6204bis focused on.

=20

Hemant

=20


------_=_NextPart_001_01CCA9D1.49816421
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


 
From:=
 =
Wuyts Carl [mailto:Carl.Wuyts@technicolor.com] 
Sent: =
Wednesday, November 23, 2011 5:53 AM
To: Hemant Singh =
(shemant); v6ops@ietf.org
Subject: RE: [v6ops] =
RFC6204bis-03
 
>Correct, but the req is quite different to =
implement from CPEs point-of-view and, as you mention, discussed in DHC =
WG.  You mention a “rough consensus”; I must say I did =
not really see a >real consensus in the big load of emails on the =
topic. So might have missed that one.
 
The req changed between =
the -02 and the -03 versions of rfc6204bis because at first we were =
given the 7200 value to change to for the MAX_SOL_RT.  Then when =
the draft
 
http://tools.ietf.org/html/draft-droms-dhc-dhcpv6-maxsolrt-update-00=

 
was published the value =
change to 3600.  It’s RFC3315 that will be updated by the =
maxsolrt-update draft for the 3600 value.   See section  =
2 of the maxsolrt-update draft.   Thereafter the =
maxsolrt-update draft defines a new MAX_SOL_RT option in section 3 and =
that is what the -03 version of rfc6204bis focused =
on.
 
Hemant
 

------_=_NextPart_001_01CCA9D1.49816421--

From ichiroumakino@gmail.com  Wed Nov 23 03:39:55 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0F521F8B4D for ; Wed, 23 Nov 2011 03:39:55 -0800 (PST)
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 uJXuCHfHRBEZ for ; Wed, 23 Nov 2011 03:39:54 -0800 (PST)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3490121F8B20 for ; Wed, 23 Nov 2011 03:39:54 -0800 (PST)
Received: by ywt34 with SMTP id 34so1498474ywt.31 for ; Wed, 23 Nov 2011 03:39:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=hVIKf642gSMH4qrbZb1/4JYmY7a3ZbnQuxYtM/2pNTQ=; b=Tu1N9/vypo8tSoG++28FScikh951hnPvOlb4d6wtTd+30a0WUBN75kX1NmXSLoJZWV gtZf+kxvffsspimo0IbJXTGJ/mfkYe6hae1z8c7NyAkmO6L0PUAKAcFlBGXhWjhv3f4/ rGWQpgmYDdFnjE6/+tZBFJDtAo5z7YbvpDz8E=
Received: by 10.205.132.16 with SMTP id hs16mr23324068bkc.7.1322048383863; Wed, 23 Nov 2011 03:39:43 -0800 (PST)
Received: from [10.147.13.57] (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id dq2sm12597351bkb.11.2011.11.23.03.39.42 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 23 Nov 2011 03:39:42 -0800 (PST)
Sender: Ole Troan 
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=windows-1252
From: Ole Troan 
In-Reply-To: <750BF7861EBBE048B3E648B4BB6E8F4F20EA1083@crexc50p>
Date: Wed, 23 Nov 2011 12:39:41 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com><5B6B2B64C9FE2A489045EEEADDAFF2C30354473D@XMB-RCD-109.cisco.com><4EC455D6.8030601@bogus.com><7EB596BF-B175-40BF-ABC8-326599670B04@apple.com><5B6B2B64C9FE2A489045EEEADDAFF2C303544B88@XMB-RCD-109.cisco.com><8D342733-88E6-45D3-B388-E001AE32CD77@employees.org><750BF7861EBBE048B3E648B4BB6E8F4F20DC4FEA@crexc50p><007801cca8c8$5610aa00$0231fe00$@iname.com><750BF7861EBBE048B3E648B4BB6E8F4F20EA1037@crexc50p>  <750BF7861EBBE048B3E6 48B4BB6E8F4F20EA1083@crexc50p>
To: "STARK, BARBARA H" 
X-Mailer: Apple Mail (2.1084)
Cc: IPv6 Operations 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 23 Nov 2011 11:39:55 -0000

Barbara,

> We=92re trying to allow cable operators to do the things they want to =
do, allow telco operators to do what they want, all while making sure =
that the retail CE routers will work in either environment, without =
overwhelming complexity.
> =20
> We=92re like the super committee trying to come up with a way to =
balance the budget. Unless we=92re all willing to compromise and suffer =
shared sacrifice, we=92re going to dig ourselves into a really deep =
hole. You know you=92ve got a reasonable compromise when nobody is =
completely happy with the result, but most all reckon they can live with =
it. =46rom my perspective, this accurately describes the compromise =
we=92ve defined.
> =20
> Or as Dr. Phil asks, =93Would you rather be right, or happy?=94 I=92d =
rather be happy.

I would be happier if we were reasonably certain we resolved the issues.
is there anything with the proposed solution in DHCP, that you don't =
think will make everyone equally unhappy?

without restarting the M/O bits, an RA there or not debate. cause that =
one we are not going to reach consensus on. didn't 10 years ago, didn't =
5 years ago, didn't last year, don't now.

cheers,
Ole=

From Ted.Lemon@nominum.com  Wed Nov 23 04:52:22 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA4EB21F8C68 for ; Wed, 23 Nov 2011 04:52:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.575
X-Spam-Level: 
X-Spam-Status: No, score=-106.575 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 Go8xkpMrQMhv for ; Wed, 23 Nov 2011 04:52:22 -0800 (PST)
Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id E18D921F8C59 for ; Wed, 23 Nov 2011 04:52:21 -0800 (PST)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKTszsfoRVutFlUSYYGUE8RwVaNC5Y82mu@postini.com; Wed, 23 Nov 2011 04:52:21 PST
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 8CC301B82A6 for ; Wed, 23 Nov 2011 04:52:14 -0800 (PST)
Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 7CD1D190052; Wed, 23 Nov 2011 04:52:14 -0800 (PST) (envelope-from Ted.Lemon@nominum.com)
Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.01.0339.001; Wed, 23 Nov 2011 04:52:14 -0800
From: Ted Lemon 
To: Ole Troan 
Thread-Topic: [v6ops] DHCPv6 option for MAX_SOL_RT
Thread-Index: AQHMpBVS9v5OyU3dDEaf8biIUoZIIJWwMYMAgACJcgCAAANuAP//e/aAgAD3r4CAAQPRAIAAGkmAgAAkTwCAAEPzAIAAvrKAgAABC4CAAAnSAIAABdOAgAVG1oCAAFm1gIAAZ3OAgAABloCAAAT6AIABUMqAgAAURIA=
Date: Wed, 23 Nov 2011 12:52:14 +0000
Message-ID: <14640DA2-54E5-46E9-B255-D141F1934596@nominum.com>
References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com><5B6B2B64C9FE2A489045EEEADDAFF2C30354473D@XMB-RCD-109.cisco.com><4EC455D6.8030601@bogus.com><7EB596BF-B175-40BF-ABC8-326599670B04@apple.com><5B6B2B64C9FE2A489045EEEADDAFF2C303544B88@XMB-RCD-109.cisco.com><8D342733-88E6-45D3-B388-E001AE32CD77@employees.org><750BF7861EBBE048B3E648B4BB6E8F4F20DC4FEA@crexc50p><007801cca8c8$5610aa00$0231fe00$@iname.com><750BF7861EBBE048B3E648B4BB6E8F4F20EA1037@crexc50p>  <750BF7861EBBE048B3E6 48B4BB6E8F4F20EA1083@crexc50p> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.1.10]
Content-Type: multipart/alternative; boundary="_000_14640DA254E546E9B255D141F1934596nominumcom_"
MIME-Version: 1.0
Cc: IPv6 Operations 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 23 Nov 2011 12:52:22 -0000

--_000_14640DA254E546E9B255D141F1934596nominumcom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

On Nov 23, 2011, at 6:39 AM, Ole Troan wrote:
without restarting the M/O bits, an RA there or not debate. cause that one =
we are not going to reach consensus on. didn't 10 years ago, didn't 5 years=
 ago, didn't last year, don't now.

I have come to believe that the reason we didn't achieve consensus on this =
was that we didn't have the right architecture, and in the architecture we =
had, the M and O bits didn't work.   I'm not convinced that, if we were to =
fix the architecture, the M and O bits wouldn't suddenly start to make sens=
e.


--_000_14640DA254E546E9B255D141F1934596nominumcom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <45FB3CBEBDE9AC41A6547751DCB4C03D@nominum.com>
Content-Transfer-Encoding: quoted-printable









On Nov 23, 2011, at 6:39 AM, Ole Troan wrote:


without
 restarting the M/O bits, an RA there or not debate. cause that one we are =
not going to reach consensus on. didn't 10 years ago, didn't 5 years ago, d=
idn't last year, don't now.








I have come to believe that the reason we didn't achieve consensus on =
this was that we didn't have the right architecture, and in the architectur=
e we had, the M and O bits didn't work.   I'm not convinced that, if w=
e were to fix the architecture, the M
 and O bits wouldn't suddenly start to make sense.









--_000_14640DA254E546E9B255D141F1934596nominumcom_--

From ichiroumakino@gmail.com  Wed Nov 23 05:03:14 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4338821F8B11 for ; Wed, 23 Nov 2011 05:03:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.552
X-Spam-Level: 
X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[AWL=0.047,  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 4mlTx0ONBteh for ; Wed, 23 Nov 2011 05:03:13 -0800 (PST)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id D5AF821F8AEC for ; Wed, 23 Nov 2011 05:03:09 -0800 (PST)
Received: by bkbzv15 with SMTP id zv15so1303063bkb.31 for ; Wed, 23 Nov 2011 05:03:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=cnTqIyZ7r5lXyuLQYbRLkVGTx+1gTjdtGEEJP7RUS2E=; b=cyydETSUfK1e08Lpkg2CoPgdSSn63IWCJddPV1mLdf+PN6ikur+1IhnUcpl8Irzuip 8zPuwlNrVyUunJeChxo9rYtgGTzkXAcdNAKwKzRKJXmrQJyIU9W1yh9WWGK0a5MPlBQp 8O+/ZgPyPn2SGEOLoewz2aQS5UESwD5ztiCoc=
Received: by 10.205.126.130 with SMTP id gw2mr24272232bkc.59.1322053388762; Wed, 23 Nov 2011 05:03:08 -0800 (PST)
Received: from [10.147.13.57] (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id q6sm12807107bka.6.2011.11.23.05.02.42 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 23 Nov 2011 05:03:07 -0800 (PST)
Sender: Ole Troan 
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Ole Troan 
In-Reply-To: <14640DA2-54E5-46E9-B255-D141F1934596@nominum.com>
Date: Wed, 23 Nov 2011 14:02:40 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <80C28FE2-FC05-4209-84D7-A01B81F2D212@employees.org>
References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com><5B6B2B64C9FE2A489045EEEADDAFF2C30354473D@XMB-RCD-109.cisco.com><4EC455D6.8030601@bogus.com><7EB596BF-B175-40BF-ABC8-326599670B04@apple.com><5B6B2B64C9FE2A489045EEEADDAFF2C303544B88@XMB-RCD-109.cisco.com><8D342733-88E6-45D3-B388-E001AE32CD77@employees.org><750BF7861EBBE048B3E648B4BB6E8F4F20DC4FEA@crexc50p><007801cca8c8$5610aa00$0231fe00$@iname.com><750BF7861EBBE048B3E648B4BB6E8F4F20EA1037@crexc50p>  <750BF7861EBBE048B3E6 48B4BB6E8F4F20EA1083@crexc50p>  <14640DA2-54E5-46E9-B255-D141F1934596@nominum.com>
To: Ted Lemon 
X-Mailer: Apple Mail (2.1084)
Cc: IPv6 Operations 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 23 Nov 2011 13:03:14 -0000

Ted,

>> without restarting the M/O bits, an RA there or not debate. cause =
that one we are not going to reach consensus on. didn't 10 years ago, =
didn't 5 years ago, didn't last year, don't now.
>=20
> I have come to believe that the reason we didn't achieve consensus on =
this was that we didn't have the right architecture, and in the =
architecture we had, the M and O bits didn't work.   I'm not convinced =
that, if we were to fix the architecture, the M and O bits wouldn't =
suddenly start to make sense.

that's hard to argue against until you give us a proposed architecture.
having one configuration protocol depend on another configuration =
protocol before it can start? let's hope we don't invent yet another =
one. ;-)

cheers,
Ole



From jason_livingood@cable.comcast.com  Wed Nov 23 05:06:10 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2053E21F8C8B for ; Wed, 23 Nov 2011 05:06:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.995
X-Spam-Level: 
X-Spam-Status: No, score=-106.995 tagged_above=-999 required=5 tests=[AWL=1.467, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, 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 IzHqKTMGF-xF for ; Wed, 23 Nov 2011 05:06:09 -0800 (PST)
Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id C1D9121F8C8C for ; Wed, 23 Nov 2011 05:06:08 -0800 (PST)
Received: from ([24.40.55.40]) by pacdcimo01.cable.comcast.com with ESMTP  id 5503620.146965481; Wed, 23 Nov 2011 08:06:06 -0500
Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%11]) with mapi id 14.01.0339.001; Wed, 23 Nov 2011 08:06:05 -0500
From: "Livingood, Jason" 
To: John Mann 
Thread-Topic: [v6ops] Update of draft-ietf-v6ops-v6-aaaa-whitelisting-implications-07
Thread-Index: AQHMinjPwilI7MOZ/0e305KMc5hLZ5V8ocqAgDym2ICAANxQgIAAh3wA
Date: Wed, 23 Nov 2011 13:06:05 +0000
Message-ID: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.13.0.110805
x-originating-ip: [147.191.227.196]
Content-Type: multipart/alternative; boundary="_000_CAF256CD43E19jasonlivingoodcablecomcastcom_"
MIME-Version: 1.0
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] Update of draft-ietf-v6ops-v6-aaaa-whitelisting-implications-07
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 23 Nov 2011 13:06:10 -0000

--_000_CAF256CD43E19jasonlivingoodcablecomcastcom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Inline.

- Jason

On 11/22/11 7:01 PM, "John Mann" > wrote:
---

3.  IPv6 Adoption Implications

---
Can you split the first paragraph into separate ideas e.g. at "A substantia=
l delay"

Also perhaps add something like
    Over time, there should be more IPv6-capable users and per-user traffic=
 should increase.
    Delaying (the start of) migration of content will mean that when it doe=
s happen the Section 2.2 Volume-Based Concerns will be larger.

As this seems like a minor stylistic recommendation, I prefer not to make a=
ny more of those in the document given where it stands in the process.

---

4.3.1.  How DNS Resolver Whitelisting Works


   ...  In the case of DNS Resolver

   Whitelisting, the resource that an end user seeks is a name, not an IP a=
ddress or IP address family.  Thus, an end user is seeking a name such as w=
ww.example.com, without regard to the underlying IP=
 address family (IPv4 or IPv6) which may be used to access that resource.


---
I think this is a bit wrong.
A user doesn't seek a "name", they seek a Internet host/service with a part=
icular name.

This specific text was arrived at following detailed discussions with imple=
menters, the WG chairs, and the ADs. I believe it works as-is, and implemen=
ters in particular felt very strongly that end users were seeking a name. I=
 also think it largely stylistic to making it say they are seeking a host o=
r service with a name rather than seeking a name (which is a simpler way of=
 saying it anyway).

---
4.3.1.1

   1.  The authoritative DNS server for example.com rec=
eives DNS queries for the A (IPv4) and/or AAAA (IPv6) address resource reco=
rds for the Fully Qualified Domain Name (FQDN) www.example.com, for which AAAA (IPv6) resource records exist.



   2.  The authoritative DNS server checks the IP address (IPv4, IPv6, or b=
oth) of the DNS recursive resolver sending the AAAA (IPv6) query against th=
e whitelist that is the DNS Whitelist.


---
Step 1 is for A and/or AAAA queries, but step 2 is only for AAAA queries ??
The server does not know all the addresses of the resolver, only the addres=
s used by the query packet.
Also  whitelist ... Whitelist.

Yes, this was intended; this is AAAA whitelisting =96 not both A and AAAA w=
hitelisting. Also, when referring to whitelisting and blacklisting generall=
y, those terms are not capitalized on their own.

---

6.2.  Privacy Considerations

----
No mention is made here of recursive resolvers.

Questions for whole mailing list, and my view:

Are recursive resolver IP addresses privacy sensitive?
Not much since these addresses are visible on packets flowing across the op=
en Internet.

It seems correct and obvious that the IP addresses of DNS recursive resolve=
rs are not privacy sensitive.

Can content providers share recursive resolver white/blacklists?

Sure, why not.

Probably, since it can improve the Internet without exposing information wi=
dely.
Tricky due to responsibility / liability issues.

Liability concepts are out of scope of this document.

Should the general public not/be allowed to discover if a recursive resolve=
r is on a white/blacklist (as discussed in 4.4 for e-mail blacklists)?
Probably, but extra work for content providers.

Should netblock owners be allowed to discover if recursive resolvers in the=
ir address range are on a list?
Definitely

I don't disagree but this is considered out of scope for this document base=
d on IETF discussions. For information about those concerns, please see htt=
p://www.bitag.org/documents/BITAG_TWG_Report-DNS_Whitelisting.pdf

Thanks!
Jason



Thanks,
    John

--_000_CAF256CD43E19jasonlivingoodcablecomcastcom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <19C4F70583869D4B9D8E8EBC754EB360@cable.comcast.com>
Content-Transfer-Encoding: quoted-printable











Inline. 







- Jason







On 11/22/11 7:01 PM, "John Mann" <john.mann@monash.edu> wrote:













---




3.  IPv6 A=
doption Implications



---

Can you split the first paragraph into separate ideas e.g. at "A substantial delay"






Also perhaps add something like


    Over time, there should be more IPv6-capable users and p=
er-user traffic should increase.


    Delaying (the start of) migration of content will m=
ean that when it does happen the Section 2.2 Volume-Based Concerns will be =
larger.














As this seems like a minor stylistic recommendation, I prefer not to m=
ake any more of those in the document given where it stands in the process.=
 














---




4.3.1.  How DNS Resolver Whitelisting Works


   ...  In the case of DNS Resolver


   Whitelisting, the resource that a=
n end user seeks is a name, not an IP address or IP address family.  Thus, =
an end user is seeking a name such as ww=
w.example.com, without regard to the underlying IP address family (IPv4=
 or IPv6) which may be used to access that resource.





---


I think this is a bit wrong.


A user doesn't seek a "name", they seek a Internet host/serv=
ice with a particular name.














This specific text was arrived at following detailed discussions with =
implementers, the WG chairs, and the ADs. I believe it works as-is, and imp=
lementers in particular felt very strongly that end users were seeking a na=
me. I also think it largely stylistic
 to making it say they are seeking a host or service with a name rather tha=
n seeking a name (which is a simpler way of saying it anyway).














---


4.3.1.1




   1.  The authoritative DNS server =
for example.com receives DNS queries for=
 the A (IPv4) and/or AAAA (IPv6) address resource records for the Fully Qua=
lified Domain Name (FQDN) www.example.co=
m, for which AAAA (IPv6) resource records exist.










   2.  The authoritative DNS server =
checks the IP address (IPv4, IPv6, or both) of the DNS recursive resolver s=
ending the AAAA (IPv6) query against the whitelist that is the DNS Whitelis=
t.





---


Step 1 is for A and/or AAAA queries, but step 2 is only for AAAA queri=
es ??















The server does not know all the addresses of the resolver, only the a=
ddress used by the query packet.


Also  whitelist ... Whitelist.














Yes, this was intended; this is AAAA whitelisting =96 not both A and A=
AAA whitelisting. Also, when referring to whitelisting and blacklisting gen=
erally, those terms are not capitalized on their own. 














---




6.2.  Pr=
ivacy Considerations



----


No mention is made here of recursive resolvers.
















Questions for whole mailing list, and my view:







Are recursive resolver IP addresses privacy sensitive?


Not much since these addresses are visible on packets flowing across t=
he open Internet.












It seems correct and obvious that the IP addresses of DNS recursive re=
solvers are not privacy sensitive. 












Can content providers share recursive resolver white/blacklists?












Sure, why not.












Probably, since it can improve the Internet without exposing informati=
on widely.


Tricky due to responsibility / liability issues.












Liability concepts are out of scope of this document.












Should the general public not/be allowed to discover if a recursive re=
solver is on a white/blacklist (as discussed in 4.4 for e-mail blacklists)?=



Probably, but extra work for content providers.
















Should netblock owners be allowed to discover if recursive resolvers i=
n their address range are on a list?


Definitely












I don't disagree but this is considered out of scope for this document=
 based on IETF discussions. For information about those concerns, please se=
e http://www.bitag.org/documents/BITAG_TWG_Report-DNS_Whitelisti=
ng.pdf







Thanks!


Jason




















Thanks,




    John









--_000_CAF256CD43E19jasonlivingoodcablecomcastcom_--

From Ted.Lemon@nominum.com  Wed Nov 23 05:17:18 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70FFC21F8C73 for ; Wed, 23 Nov 2011 05:17:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.575
X-Spam-Level: 
X-Spam-Status: No, score=-106.575 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 au1TtER2CXvz for ; Wed, 23 Nov 2011 05:17:17 -0800 (PST)
Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5ACEE21F8B7E for ; Wed, 23 Nov 2011 05:17:17 -0800 (PST)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKTszyXNLk3TMpgV27vC9bB8SodRVRTtA0@postini.com; Wed, 23 Nov 2011 05:17:17 PST
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 6333F1B82A2 for ; Wed, 23 Nov 2011 05:17:16 -0800 (PST)
Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 264C9190052; Wed, 23 Nov 2011 05:17:13 -0800 (PST) (envelope-from Ted.Lemon@nominum.com)
Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.01.0339.001; Wed, 23 Nov 2011 05:17:13 -0800
From: Ted Lemon 
To: Ole Troan 
Thread-Topic: [v6ops] DHCPv6 option for MAX_SOL_RT
Thread-Index: AQHMpBVS9v5OyU3dDEaf8biIUoZIIJWwMYMAgACJcgCAAANuAP//e/aAgAD3r4CAAQPRAIAAGkmAgAAkTwCAAEPzAIAAvrKAgAABC4CAAAnSAIAABdOAgAVG1oCAAFm1gIAAZ3OAgAABloCAAAT6AIABUMqAgAAURICAAALsAIAABA6A
Date: Wed, 23 Nov 2011 13:17:12 +0000
Message-ID: <0D1E9868-8B72-467D-BAE8-DA5214C68AF7@nominum.com>
References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com><5B6B2B64C9FE2A489045EEEADDAFF2C30354473D@XMB-RCD-109.cisco.com><4EC455D6.8030601@bogus.com><7EB596BF-B175-40BF-ABC8-326599670B04@apple.com><5B6B2B64C9FE2A489045EEEADDAFF2C303544B88@XMB-RCD-109.cisco.com><8D342733-88E6-45D3-B388-E001AE32CD77@employees.org><750BF7861EBBE048B3E648B4BB6E8F4F20DC4FEA@crexc50p><007801cca8c8$5610aa00$0231fe00$@iname.com><750BF7861EBBE048B3E648B4BB6E8F4F20EA1037@crexc50p>  <750BF7861EBBE048B3E6 48B4BB6E8F4F20EA1083@crexc50p>  <14640DA2-54E5-46E9-B255-D141F1934596@nominum.com> <80C28FE2-FC05-4209-84D7-A01B81F2D212@employees.org>
In-Reply-To: <80C28FE2-FC05-4209-84D7-A01B81F2D212@employees.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.1.10]
Content-Type: multipart/alternative; boundary="_000_0D1E98688B72467DBAE8DA5214C68AF7nominumcom_"
MIME-Version: 1.0
Cc: IPv6 Operations 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 23 Nov 2011 13:17:18 -0000

--_000_0D1E98688B72467DBAE8DA5214C68AF7nominumcom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

On Nov 23, 2011, at 8:02 AM, Ole Troan wrote:
that's hard to argue against until you give us a proposed architecture.
having one configuration protocol depend on another configuration protocol =
before it can start? let's hope we don't invent yet another one. ;-)

The problem with DHCP and RA at present is that we don't have any knowledge=
 of who we are listening to.   Suppose two routers send RAs on a wire.   Ar=
e they managed by the same organization, or different organizations?   Is t=
here one DHCP server, or two?   Because we don't know which routers are in =
which provisioning domains, we have no way of telling whether we should tre=
at the information from the two routers as indicative of the state of one p=
rovisioning domain, or two, and hence we have problems like flapping, where=
 one router sets the M and O bits differently than the other, and we trigge=
r DHCP state changes as a result.

If two routers have differing configurations, they are probably in differen=
t provisioning domains.   I'd like to see something in the RA that represen=
ts this information, so that we can tell, instead of having to guess.   I t=
hink if we did this, then M and O would actually work as originally intende=
d, because the only time when M and O would disagree within a provisioning =
domain would be when the administrator had misconfigured the routers.

I'm not proposing that this is a complete architecture statement=97it doesn=
't address the problem of multiple provisioning domains past the edge route=
r=97but I think that needs to be addressed in a similar way; even if there =
is only one router advertising both provisioning domains, the router advert=
isement needs to explicitly say that two provisioning domains are being adv=
ertised.

As far as DHCP goes, I think that if you have an advertised provisioning do=
main identifier in the RA, you can use it in DHCP as well, and this can be =
used to direct traffic appropriately.   If you get RAs from two separate pr=
ovisioning domains, both of which indicate that you should do DHCP, then yo=
u originate two DHCP state machines, one for each provisioning domain.   Ea=
ch state machine, when it sends a DHCP message, marks it with the provision=
ing domain identifier.   Hopefully the relay forwards such messages only to=
 the DHCP server for that provisioning domain.

This prevents RA from breaking DHCP, and it allows DHCP to behave correctly=
 in the multiple-provisioning-domain context, acquiring configuration infor=
mation for each provisioning domain, rather than being forced to choose one=
 or the other.


--_000_0D1E98688B72467DBAE8DA5214C68AF7nominumcom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <83018F5551C4984FBD42E99B6F354068@nominum.com>
Content-Transfer-Encoding: quoted-printable









On Nov 23, 2011, at 8:02 AM, Ole Troan wrote:


that's
 hard to argue against until you give us a proposed architecture.

having one configuration protocol depend on another configuration protocol =
before it can start? let's hope we don't invent yet another one. ;-)=







The problem with DHCP and RA at present is that we don't have any know=
ledge of who we are listening to.   Suppose two routers send RAs on a =
wire.   Are they managed by the same organization, or different organi=
zations?   Is there one DHCP server, or two?
   Because we don't know which routers are in which provisioning domai=
ns, we have no way of telling whether we should treat the information from =
the two routers as indicative of the state of one provisioning domain, or t=
wo, and hence we have problems like flapping,
 where one router sets the M and O bits differently than the other, and we =
trigger DHCP state changes as a result.







If two routers have differing configurations, they are probably in dif=
ferent provisioning domains.   I'd like to see something in the RA tha=
t represents this information, so that we can tell, instead of having to gu=
ess.   I think if we did this, then M
 and O would actually work as originally intended, because the only time wh=
en M and O would disagree within a provisioning domain would be when the ad=
ministrator had misconfigured the routers.







I'm not proposing that this is a complete architecture statement=97it =
doesn't address the problem of multiple provisioning domains past the edge =
router=97but I think that needs to be addressed in a similar way; even if t=
here is only one router advertising
 both provisioning domains, the router advertisement needs to explicitly sa=
y that two provisioning domains are being advertised.







As far as DHCP goes, I think that if you have an advertised provisioni=
ng domain identifier in the RA, you can use it in DHCP as well, and this ca=
n be used to direct traffic appropriately.   If you get RAs from two s=
eparate provisioning domains, both of
 which indicate that you should do DHCP, then you originate two DHCP state =
machines, one for each provisioning domain.   Each state machine, when=
 it sends a DHCP message, marks it with the provisioning domain identifier.=
   Hopefully the relay forwards such
 messages only to the DHCP server for that provisioning domain.







This prevents RA from breaking DHCP, and it allows DHCP to behave corr=
ectly in the multiple-provisioning-domain context, acquiring configuration =
information for each provisioning domain, rather than being forced to choos=
e one or the other.









--_000_0D1E98688B72467DBAE8DA5214C68AF7nominumcom_--

From mark@townsley.net  Wed Nov 23 05:31:05 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A47C21F8CB9 for ; Wed, 23 Nov 2011 05:31:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.148
X-Spam-Level: 
X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 joDdrhbz86PG for ; Wed, 23 Nov 2011 05:31:00 -0800 (PST)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 357B121F8CBC for ; Wed, 23 Nov 2011 05:31:00 -0800 (PST)
Received: by bkbzv15 with SMTP id zv15so1337103bkb.31 for ; Wed, 23 Nov 2011 05:30:59 -0800 (PST)
Received: by 10.204.13.68 with SMTP id b4mr23914701bka.32.1322055058355; Wed, 23 Nov 2011 05:30:58 -0800 (PST)
Received: from ams-townsley-8712.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id x14sm12862039bkf.10.2011.11.23.05.30.55 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 23 Nov 2011 05:30:56 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-71-150469767
From: Mark Townsley 
In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3035EEEBA@XMB-RCD-109.cisco.com>
Date: Wed, 23 Nov 2011 14:30:53 +0100
Message-Id: <82DD1735-321E-44CB-8E1E-FF7C3402A371@townsley.net>
References:  <750BF7861EBBE048B3E648B4BB6E8F4F20B124DE@crexc50p> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EEEBA@XMB-RCD-109.cisco.com>
To: Hemant Singh (shemant) 
X-Mailer: Apple Mail (2.1084)
Cc: v6ops@ietf.org
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 23 Nov 2011 13:31:05 -0000

--Apple-Mail-71-150469767
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


I think that manually configured 6rd, or manually configured anything =
really, should be squarely out of scope whenever possible. I think the =
WG should focus on default behavior and configuration handled via our =
protocols. Once you've opened a user-level interface, all bets are off.=20=


That said, a manually configured 6rd interface should not be difficult =
as long as you don't try to treat it "special". It's just another =
interface like any other on the router. It has its own entry in the =
forwarding table, and rules that are consistent with what we should =
define for an ISP-configured 6rd interface. Everything we have discussed =
here in terms of what is in 6rd-sunsetting and source routing to the =
correct interface apply perfectly well, even if you have manual and =
SP-configured interfaces (not to mention an HE tunnel on the side, etc.)

The hard part comes when the CPE tries to become too intelligent for its =
own good, automatically preferring one type of interface configuration =
over another (note that I didn't say preferring one *route* over another =
when the entries in the forwarding table are otherwise equal, I said =
preferring one type of *configuration* over the other). I think this is =
inherently bad as it means every single time there is a new type of =
interface (virtual or otherwise) you have to fit it into a logic table =
of what is and is not allowed. As long as the router can handle multiple =
interfaces generically, it should "do as it's told", bring up interfaces =
it has SP-supported or explicit manual configuration for, and route =
accordingly. =20

For troubleshooting, RFC 5969 includes advice on how to construct a =
packet that will not only test the path between the CE and BR, it will =
tell you which BR that packet happened to traverse. One could run a =
BFD-like keepalive on a timer on the 6rd tunnel (the "NUD" section =
Hemant refers to), but I think that's overkill for 6rd as long as you =
have a well-supported BR deployment to plug into. If you are using the =
6rd config with a single BR that is not well-supported, you might want =
the CE to declare the interface down when a periodic NUD check fails. It =
should be clear though that this is far removed from a "production" =
ISP-supported 6rd deployment, and much more of a "trial" type of =
operation that I think 6204-bis should not have to worry about.=20

- Mark


On Nov 23, 2011, at 11:53 AM, Hemant Singh (shemant) wrote:

> =20
> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf =
Of STARK, BARBARA H
> Sent: Tuesday, November 15, 2011 10:33 AM
> To: v6ops@ietf.org
> Subject: Re: [v6ops] 6rd Sunsetting
> =20
> =20
> >But when the CE router was manually configured for 6rd, I have no =
clue what this means. How is the manually-configured CE router supposed =
to know whether or not 6rd is configured by >the SP? Some guidance in =
this area would be appreciated. For example, should the CE router test =
to see if the BR is reachable, and if not assume that 6rd is not =
configured by the SP?
> =20
> How can a subscriber in the home manually configure the CE router for =
four 6rd parameters including the IPv4 address of the BR unless the =
subscriber called the SP and got the information to configure manually.  =
Thus the SP knows about the CPE router in the subscriber=92s home and =
also the CE router does not need to test if 6rd is configured by the SP. =
 If the CE router still wants to test, then use the NUD specified in =
section 8 of RFC 5969.
> =20
> Hemant
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


--Apple-Mail-71-150469767
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252



I think that manually =
configured 6rd, or manually configured anything really, should be =
squarely out of scope whenever possible. I think the WG should focus on =
default behavior and configuration handled via our protocols. Once =
you've opened a user-level interface, all bets are =
off. 

That said, a manually configured 6rd =
interface should not be difficult as long as you don't try to treat it =
"special". It's just another interface like any other on the router. It =
has its own entry in the forwarding table, and rules that are consistent =
with what we should define for an ISP-configured 6rd interface. =
Everything we have discussed here in terms of what is in 6rd-sunsetting =
and source routing to the correct interface apply perfectly well, even =
if you have manual and SP-configured interfaces (not to mention an HE =
tunnel on the side, etc.)

The hard part comes =
when the CPE tries to become too intelligent for its own good, =
automatically preferring one type of interface configuration over =
another (note that I didn't say preferring one *route* over another when =
the entries in the forwarding table are otherwise equal, I said =
preferring one type of *configuration* over the other). I think this is =
inherently bad as it means every single time there is a new type of =
interface (virtual or otherwise) you have to fit it into a logic table =
of what is and is not allowed. As long as the router can handle multiple =
interfaces generically, it should "do as it's told", bring up interfaces =
it has SP-supported or explicit manual configuration for, and route =
accordingly.  

For troubleshooting, RFC =
5969 includes advice on how to construct a packet that will not only =
test the path between the CE and BR, it will tell you which BR that =
packet happened to traverse. One could run a BFD-like keepalive on =
a timer on the 6rd tunnel (the "NUD" section Hemant refers to), but I =
think that's overkill for 6rd as long as you have a well-supported BR =
deployment to plug into. If you are using the 6rd config with a single =
BR that is not well-supported, you might want the CE to declare the =
interface down when a periodic NUD check fails. It should be clear =
though that this is far removed from a "production" ISP-supported 6rd =
deployment, and much more of a "trial" type of operation that I think =
6204-bis should not have to worry =
about. 

- =
Mark


On Nov 23, 2011, at =
11:53 AM, Hemant Singh (shemant) wrote:

From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.or=
g] On Behalf =
Of STARK, BARBARA =
H
Sent: Tuesday, November 15, 2011 =
10:33 AM
To: v6ops@ietf.org
Subject: Re: [v6ops] 6rd =
Sunsetting
But when the CE router was =
manually configured for 6rd, I have no clue what this means. How is the =
manually-configured CE router supposed to know whether or not 6rd is =
configured by >the SP? =
Some guidance in this area would be appreciated. For example, should the =
CE router test to see if the BR is reachable, and if not assume that 6rd =
is not configured by the SP?
How =
can a subscriber in the home manually configure the CE router for four =
6rd parameters including the IPv4 address of the BR unless the =
subscriber called the SP and got the information to configure =
manually.  Thus the SP knows about the CPE router in the =
subscriber=92s home and also the CE router does not need to test if 6rd =
is configured by the SP.  If the CE router still wants to test, =
then use the NUD specified in section 8 of RFC =
5969.

x-cbid: 11112314-3534-0000-0000-000002A60740
Cc: IPv6 Operations 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 23 Nov 2011 14:08:02 -0000

> I have come to believe that the reason we didn't achieve consensus
> on this was that we didn't have the right architecture, and in the
> architecture we had, the M and O bits didn't work.  I'm not
> convinced that, if we were to fix the architecture, the M and O bits
> wouldn't suddenly start to make sense.

Classic problem with M/O bits: They were defined before we actually
had DHCP defined. I.e., we were guessing at what the bits would be
used for in the future, and we got it wrong.

If we could do it all over again, I would argue for:

 no M/O bits
 Every client always issues a DHCP request (and RS)
 No difference between address and non-address config
    request/protocol for DHCP
 Client always asks for config info, gets what the network operator
    has configured to send out, whether addresses or other stuff.
 mandate that clients do both DHCP/RAs

I.e., keep it simple/predictable for the client and operator both.

Thomas    


From wbeebee@cisco.com  Wed Nov 23 06:12:06 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F31B21F8C8C for ; Wed, 23 Nov 2011 06:12:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.164
X-Spam-Level: 
X-Spam-Status: No, score=-4.164 tagged_above=-999 required=5 tests=[AWL=0.368,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XtnaCEpxWbIG for ; Wed, 23 Nov 2011 06:12:05 -0800 (PST)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id B239621F8ACA for ; Wed, 23 Nov 2011 06:12:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wbeebee@cisco.com; l=511; q=dns/txt; s=iport; t=1322057525; x=1323267125; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=6v/Prl1nrfONWOmBnnL0tqj3HsEsiSjnpTKR15Uprdo=; b=KcqbA9t/Y0x47muODdqeeeekFExXn9+ep6vZQRPVN3M+lkPwmiXa3twO ja70qoYiS68XjBBfKf+YOApOPWXYA5N5VPd/itUii+fFYgGtMSaxbMkz0 EJg8NYTYVRfkYirN3wDymBAENQ5ADJ4W6RIn/OSN3FrKNsmQldHAkqEY+ k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvkGAPb+zE6tJXHB/2dsb2JhbABEiUmhIAKBBYFyAQEBAwESAScCATwFDQEIgR0BAQQBDRkOh2OVdgGePYpiBIggjCiNdYQz
X-IronPort-AV: E=Sophos;i="4.69,559,1315180800"; d="scan'208";a="38477863"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-1.cisco.com with ESMTP; 23 Nov 2011 14:11:52 +0000
Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id pANEBq2Z026986;  Wed, 23 Nov 2011 14:11:52 GMT
Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 23 Nov 2011 08:11:51 -0600
Received: from 161.44.175.128 ([161.44.175.128]) by XMB-RCD-201.cisco.com ([72.163.62.208]) with Microsoft Exchange Server HTTP-DAV ;  Wed, 23 Nov 2011 14:11:51 +0000
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Wed, 23 Nov 2011 09:11:50 -0500
From: Wes Beebee 
To: "STARK, BARBARA H" , jouni korhonen , Hemant Singh 
Message-ID: 
Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
Thread-Index: AcypXX65h/vTNDj5Sv2+XwPtjsFZ1AAE4MQQAB41geg=
In-Reply-To: <750BF7861EBBE048B3E648B4BB6E8F4F20EA14A5@crexc50p>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 23 Nov 2011 14:11:52.0099 (UTC) FILETIME=[D90E9F30:01CCA9E9]
Cc: v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-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, 23 Nov 2011 14:12:06 -0000

> Just based on the little I know, I would guess at least
> a year's worth of arguing over functionality...

I tend to agree with Barbara.  In the early days of what became RFC 6204, we
had some interest from the 3GPP community.  However, we never got the levels
of engagement necessary to make sure that we satisfied all of their
requirements.  It's not clear that satisfying half of the requirements is
actually useful to anyone and may cause unnecessary confusion to those
already engaged.

- Wes


From marc.blanchet@viagenie.ca  Wed Nov 23 06:22:34 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF9E421F8C8E for ; Wed, 23 Nov 2011 06:22:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.18
X-Spam-Level: 
X-Spam-Status: No, score=-102.18 tagged_above=-999 required=5 tests=[AWL=-0.181, 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 rPsm73NmTgxL for ; Wed, 23 Nov 2011 06:22:34 -0800 (PST)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id B18D221F8B62 for ; Wed, 23 Nov 2011 06:22:29 -0800 (PST)
Received: from [IPv6:2620::230:c000:e958:ea5a:394d:dcc5] (unknown [IPv6:2620:0:230:c000:e958:ea5a:394d:dcc5]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 0563021B94; Wed, 23 Nov 2011 09:21:58 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=iso-8859-1
From: Marc Blanchet 
In-Reply-To: <201111231402.pANE21YK013540@cichlid.raleigh.ibm.com>
Date: Wed, 23 Nov 2011 09:21:58 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com><5B6B2B64C9FE2A489045EEEADDAFF2C30354473D@XMB-RCD-109.cisco.com><4EC455D6.8030601@bogus.com><7EB596BF-B175-40BF-ABC8-326599670B04@apple.com><5B6B2B64C9FE2A489045EEEADDAFF2C303544B88@XMB-RCD-109.cisco.com><8D342733-88E6-45D3-B388-E001AE32CD77@employees.org><750BF7861EBBE048B3E648B4BB6E8F4F20DC4FEA@crexc50p><007801cca8c8$5610aa00$0231fe00$@iname.com><750BF7861EBBE048B3E648B4BB6E8F4F20EA1037@crexc50p>  <750BF7861EBBE048B3E! 6 48B4BB6E8F4F20EA1083@crexc50p>  <14640DA2-54E5-46E9-B255-D141F1934596@nominum.com> <201111231402.pANE21YK013540@cichlid.raleigh.ibm.com>
To: Thomas Narten 
X-Mailer: Apple Mail (2.1251.1)
Cc: IPv6 Operations 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 23 Nov 2011 14:22:35 -0000

Le 2011-11-23 =E0 09:02, Thomas Narten a =E9crit :

>> I have come to believe that the reason we didn't achieve consensus
>> on this was that we didn't have the right architecture, and in the
>> architecture we had, the M and O bits didn't work.  I'm not
>> convinced that, if we were to fix the architecture, the M and O bits
>> wouldn't suddenly start to make sense.
>=20
> Classic problem with M/O bits: They were defined before we actually
> had DHCP defined. I.e., we were guessing at what the bits would be
> used for in the future, and we got it wrong.
>=20
> If we could do it all over again, I would argue for:
>=20
> no M/O bits
> Every client always issues a DHCP request (and RS)
> No difference between address and non-address config
>    request/protocol for DHCP
> Client always asks for config info, gets what the network operator
>    has configured to send out, whether addresses or other stuff.
> mandate that clients do both DHCP/RAs
>=20
> I.e., keep it simple/predictable for the client and operator both.

Thomas, while there is a huge base deployed, all implementations already =
have to somewhat deal with this issue (mix dhcpv6+RA). So I wonder if it =
is, at the end, to better fix the architecture than having many =
conflicting RFCs or RFCs that slightly change one behavior after another =
to make it worst than fixing it all in one place. (however, that =
discussion should be held in 6man I guess.).

However, removing M/O bits won't help the "MIF problem" of how to merge =
config info received from multiple sources, that might or might not (and =
as Ted said: node does not know) come from same or different =
provisioning domains.

Marc.

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


From narten@us.ibm.com  Wed Nov 23 06:22:36 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A894F21F8CA2 for ; Wed, 23 Nov 2011 06:22:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.437
X-Spam-Level: 
X-Spam-Status: No, score=-106.437 tagged_above=-999 required=5 tests=[AWL=0.163, 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 aRVf-zlJHvQZ for ; Wed, 23 Nov 2011 06:22:36 -0800 (PST)
Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.144]) by ietfa.amsl.com (Postfix) with ESMTP id 46AF821F8B72 for ; Wed, 23 Nov 2011 06:22:34 -0800 (PST)
Received: from /spool/local by e4.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for  from ; Wed, 23 Nov 2011 09:22:20 -0500
Received: from d01relay07.pok.ibm.com ([9.56.227.147]) by e4.ny.us.ibm.com ([192.168.1.104]) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted;  Wed, 23 Nov 2011 09:22:16 -0500
Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay07.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id pANEM59i2527342 for ; Wed, 23 Nov 2011 09:22:05 -0500
Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id pANELI4K023753 for ; Wed, 23 Nov 2011 09:21:22 -0500
Received: from cichlid.raleigh.ibm.com (sig-9-65-195-208.mts.ibm.com [9.65.195.208]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id pANELD6h023128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Nov 2011 09:21:14 -0500
Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id pANELBqP013658; Wed, 23 Nov 2011 09:21:12 -0500
Message-Id: <201111231421.pANELBqP013658@cichlid.raleigh.ibm.com>
To: Brian E Carpenter 
In-reply-to: <4ECC139C.9080600@gmail.com>
References:  <4ECC139C.9080600@gmail.com>
Comments: In-reply-to Brian E Carpenter  message dated "Wed, 23 Nov 2011 10:26:52 +1300."
Date: Wed, 23 Nov 2011 09:21:11 -0500
From: Thomas Narten 
x-cbid: 11112314-3534-0000-0000-000002A622DC
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] Title of draft-ietf-v6ops-v6-aaaa-whitelisting-implications-07
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 23 Nov 2011 14:22:36 -0000

> I'm not going to insist. I do think the title overstates the
> scope of the document somewhat; it is not a complete guide
> to transitioning content.

I think it would be helpful to see the word "DNS" in the title
somewhere, since much of this document is related to DNS. Otherwise, I
agree the title is a bit broad.

How about something like:

            On Using the DNS for Transitioning Content to IPv6

Thomas


From mark@townsley.net  Wed Nov 23 06:45:36 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF27D21F8CA3 for ; Wed, 23 Nov 2011 06:45:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.142
X-Spam-Level: 
X-Spam-Status: No, score=-3.142 tagged_above=-999 required=5 tests=[AWL=-0.143, 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 Y7jHjnBA5gbD for ; Wed, 23 Nov 2011 06:45:36 -0800 (PST)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id E778121F8CA0 for ; Wed, 23 Nov 2011 06:45:35 -0800 (PST)
Received: by yenm7 with SMTP id m7so1749739yen.31 for ; Wed, 23 Nov 2011 06:45:35 -0800 (PST)
Received: by 10.152.144.136 with SMTP id sm8mr14750771lab.33.1322059535094; Wed, 23 Nov 2011 06:45:35 -0800 (PST)
Received: from ams-townsley-8712.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id mi5sm16095968lab.14.2011.11.23.06.45.29 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 23 Nov 2011 06:45:32 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Mark Townsley 
In-Reply-To: <20111123080113.GI71280@Space.Net>
Date: Wed, 23 Nov 2011 15:45:27 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:   <68DAB112-6E32-45FE-9AB7-A34E64898F60@cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30354436E@XMB-RCD-109.cisco.com> <750BF7861EBBE048B3E648B4BB6E8F4F20DC41F6@crexc50p>  <252D3DEA-FF09-42C8-959E-8A7205D9DE67@townsley.net>  <20111122133612.GH71280@Space.Net> <4ECC10C9.5010607@gmail.com> <20111123080113.GI71280@Space.Net>
To: Gert Doering 
X-Mailer: Apple Mail (2.1084)
Cc: Alexandre Cassen , v6ops@ietf.org, Claire Cheng 
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 23 Nov 2011 14:45:36 -0000

In practice, source address checking is done, per-subscriber, at the =
first L3 hop (BNG, CMTS, etc.) or before (DSLAM, Access Node, etc.).

6rd tunnels over this part of the network. As long as the IPv6 source =
and IPv4 source are bound, this isn't a problem, as the address checking =
is being done for IPv4 on a per-subscriber basis, and the BR does a =
(stateless) check on decap to ensure that the IPv6 source and IPv4 =
source match. =20

If you introduce an IPv6 packet with a different source address into the =
6rd tunnel and expect it not to be dropped, you are really no longer =
doing 6rd. Without the mapping to rely on, you have to either choose =
between decapsulating any packet that arrives (and the associated =
spoofing implications), or configure ACLs at =
pick-your-favorite-aggregation-level from the entire ISP down to a =
single subscriber where you are then essentially importing all the state =
from the first hop(s) into the BR.=20

So, I think Gert's right here. For all practical purposes, when a 6rd =
and native interface are up with different prefixes for each, the CPE =
has to ensure that it sends packets over the right interface. Same is =
true for multihoming in general. Only way to get around it is to keep =
the prefix the same.=20

- Mark


On Nov 23, 2011, at 9:01 AM, Gert Doering wrote:

> Hi,
>=20
> On Wed, Nov 23, 2011 at 10:14:49AM +1300, Brian E Carpenter wrote:
>> This, or strict RPF, would be self-foot-shooting by the ISP
>> wishing to sunset 6rd. It seems fairly simple to specify that
>> both ingress filtering and RPF should be configured to allow
>> both prefixes simultaneously.=20
>=20
> Permit me a polite cough here.
>=20
> *The* benefit of 6rd on the gateway side is that it's stateless, which
> means "no per-subscriber information needs to be gathered, kept, and
> validated for incoming packets".
>=20
> So either you want RPF filtering on the 6rd side, or not - but there =
is
> no reasonable way you can ISP subscriber data for a reasonable-sized
> ISP into the 6rd gateways to enable RPF filtering "plus extra prefixes
> for some of the subscribers" on the 6rd gateway.
>=20
>=20
>> This is a standard need for
>> multihomed PA customers anyway, and needs to become standard
>> practice for all IPv6 ISPs.
>=20
> This is a standard *problem*, not a "standard need".
>=20
> You're not going to see large-scale ISPs that do deploy RPF filtering
> (few enough, alas) add "oh, this customer also has prefix X from ISP Z
> this week!" to their subscriber management platform, which is where =
the=20
> routers get configured from.  Including verification that this=20
> customer is even entitled to *use* prefix X at this time.
>=20
>=20
>> While we do need a solution for source-prefix based exit
>> selection, we don't have one yet and it's a separable problem.
>=20
> I strongly disagree.  This is the core of the problem for =
multi-PA-based
> multihoming, and one variant presents itself now with "two different
> access technologies with different prefixes to the same ISP".
>=20
> Gert Doering
>        -- NetMaster
> --=20
> have you enabled IPv6 on something today...?
>=20
> 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
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


From v6ops@globis.net  Wed Nov 23 06:49:22 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 350A421F8BA7 for ; Wed, 23 Nov 2011 06:49:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.236
X-Spam-Level: 
X-Spam-Status: No, score=-2.236 tagged_above=-999 required=5 tests=[AWL=-0.238, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 46Ex5lK-NBIN for ; Wed, 23 Nov 2011 06:49:21 -0800 (PST)
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 64E7421F8B82 for ; Wed, 23 Nov 2011 06:49:16 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 38EE48700F3; Wed, 23 Nov 2011 15:49:15 +0100 (CET)
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 MdlDGGU0WKKH; Wed, 23 Nov 2011 15:49:09 +0100 (CET)
Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 558AD870070; Wed, 23 Nov 2011 15:49:09 +0100 (CET)
Message-ID: <4ECD07E5.1000305@globis.net>
Date: Wed, 23 Nov 2011 15:49:09 +0100
From: Ray Hunter 
User-Agent: Postbox Express 1.0.1 (Macintosh/20100705)
MIME-Version: 1.0
To: Marc Blanchet 
References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com><7EB596BF-B175-40BF-ABC8-326599670B04@apple.com><5B6B2B64C9FE2A489045EEEADDAFF2C303544B88@XMB-RCD-109.cisco.com><8D342733-88E6-45D3-B388-E001AE32CD77@employees.org><750BF7861EBBE048B3E648B4BB6E8F4F20DC4FEA@crexc50p><007801cca8c8$5610aa00$0231fe00$@iname.com><750BF7861EBBE048B3E648B4BB6E8F4F20EA1037@crexc50p>		<750BF7861EBBE048B3E! 6 48B4BB6E8F4F20EA1083@crexc50p>		<14640DA2-54E5-46E9-B255-D141F1934596@nominum.com>	<201111231402.pANE21YK013540@cichlid.raleigh.ibm.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------020101010908030708020906"
Cc: Thomas Narten , IPv6 Operations 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 23 Nov 2011 14:49:22 -0000

This is a multi-part message in MIME format.
--------------020101010908030708020906
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

IMVHO In short: the existence of AS boundaries is not fully reflected in 
some protocols.

Running those protocols over an administrative boundary may lead to 
problems.

Marc Blanchet wrote:
> Le 2011-11-23 à 09:02, Thomas Narten a écrit :
>
>    
>>> I have come to believe that the reason we didn't achieve consensus
>>> on this was that we didn't have the right architecture, and in the
>>> architecture we had, the M and O bits didn't work.  I'm not
>>> convinced that, if we were to fix the architecture, the M and O bits
>>> wouldn't suddenly start to make sense.
>>>        
>> Classic problem with M/O bits: They were defined before we actually
>> had DHCP defined. I.e., we were guessing at what the bits would be
>> used for in the future, and we got it wrong.
>>
>> If we could do it all over again, I would argue for:
>>
>> no M/O bits
>> Every client always issues a DHCP request (and RS)
>> No difference between address and non-address config
>>     request/protocol for DHCP
>> Client always asks for config info, gets what the network operator
>>     has configured to send out, whether addresses or other stuff.
>> mandate that clients do both DHCP/RAs
>>
>> I.e., keep it simple/predictable for the client and operator both.
>>      
>
> Thomas, while there is a huge base deployed, all implementations already have to somewhat deal with this issue (mix dhcpv6+RA). So I wonder if it is, at the end, to better fix the architecture than having many conflicting RFCs or RFCs that slightly change one behavior after another to make it worst than fixing it all in one place. (however, that discussion should be held in 6man I guess.).
>
> However, removing M/O bits won't help the "MIF problem" of how to merge config info received from multiple sources, that might or might not (and as Ted said: node does not know) come from same or different provisioning domains.
>
> Marc.
>
>    
>> Thomas
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>>      
>
>
>    

--------------020101010908030708020906
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit




  
  


IMVHO In short: the existence of AS boundaries is not fully reflected
in some protocols.



Running those protocols over an administrative boundary may lead to
problems.



Marc Blanchet wrote:


  
Le 2011-11-23 à 09:02, Thomas Narten a écrit :

  

  

    

      
I have come to believe that the reason we didn't achieve consensus
on this was that we didn't have the right architecture, and in the
architecture we had, the M and O bits didn't work.  I'm not
convinced that, if we were to fix the architecture, the M and O bits
wouldn't suddenly start to make sense.
      

    

    
Classic problem with M/O bits: They were defined before we actually
had DHCP defined. I.e., we were guessing at what the bits would be
used for in the future, and we got it wrong.

If we could do it all over again, I would argue for:

no M/O bits
Every client always issues a DHCP request (and RS)
No difference between address and non-address config
   request/protocol for DHCP
Client always asks for config info, gets what the network operator
   has configured to send out, whether addresses or other stuff.
mandate that clients do both DHCP/RAs

I.e., keep it simple/predictable for the client and operator both.
    

  

  

Thomas, while there is a huge base deployed, all implementations already have to somewhat deal with this issue (mix dhcpv6+RA). So I wonder if it is, at the end, to better fix the architecture than having many conflicting RFCs or RFCs that slightly change one behavior after another to make it worst than fixing it all in one place. (however, that discussion should be held in 6man I guess.).

However, removing M/O bits won't help the "MIF problem" of how to merge config info received from multiple sources, that might or might not (and as Ted said: node does not know) come from same or different provisioning domains.

Marc.

  

  

    
Thomas    

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

  

  


  






--------------020101010908030708020906--

From shemant@cisco.com  Wed Nov 23 07:40:44 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31CA511E8099 for ; Wed, 23 Nov 2011 07:40:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.279
X-Spam-Level: 
X-Spam-Status: No, score=-6.279 tagged_above=-999 required=5 tests=[AWL=0.320,  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 oBmoIMwCQhi3 for ; Wed, 23 Nov 2011 07:40:43 -0800 (PST)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id A2AE221F8C73 for ; Wed, 23 Nov 2011 07:40:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=851; q=dns/txt; s=iport; t=1322062834; x=1323272434; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=dhcpLE02RaO6cGUXbE1JeMpfGVsflJnDrAmOLegkJTc=; b=MjKGAiMI1bHFUzoGYizKjV693tjyRGEUj+EjqlPMpPOHSg2k5BYrXQi6 64LQtZrwm7+oOcLbyVwmLVBCAhrn3V69gIXz7lPeLEHTclsc3KhFItRgH ynZt/gqQ0l0rG0OsqFcB7TFKlHGFOEbLlyKTkI2uK9+cS1pdcOI+1+myQ 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ArQAAFoTzU6tJXG+/2dsb2JhbABDmkuQIIEFgXIBAQEDARIBHQo/BQcEAgEIEQQBAQsGGAYBTggBAQQBEggMDodjlhABnkSJf2MEiCCeUQ
X-IronPort-AV: E=Sophos;i="4.69,559,1315180800"; d="scan'208";a="38488410"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 23 Nov 2011 15:40:34 +0000
Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id pANFeXtN011828;  Wed, 23 Nov 2011 15:40:33 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 23 Nov 2011 09:40:33 -0600
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 23 Nov 2011 09:40:31 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3035EEF7C@XMB-RCD-109.cisco.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
Thread-Index: AcypXX65h/vTNDj5Sv2+XwPtjsFZ1AAE4MQQAB41gegAAwnvQA==
References: <750BF7861EBBE048B3E648B4BB6E8F4F20EA14A5@crexc50p> 
From: "Hemant Singh (shemant)" 
To: "Wes Beebee (wbeebee)" , "STARK, BARBARA H" , "jouni korhonen" 
X-OriginalArrivalTime: 23 Nov 2011 15:40:33.0260 (UTC) FILETIME=[3CB75AC0:01CCA9F6]
Cc: v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-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, 23 Nov 2011 15:40:44 -0000

Ok, we can leave comprehensive support for cellular out of rfc6204bis.

Hemant

-----Original Message-----
From: Wes Beebee (wbeebee)=20
Sent: Wednesday, November 23, 2011 9:12 AM
To: STARK, BARBARA H; jouni korhonen; Hemant Singh (shemant)
Cc: v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt

> Just based on the little I know, I would guess at least
> a year's worth of arguing over functionality...

I tend to agree with Barbara.  In the early days of what became RFC
6204, we
had some interest from the 3GPP community.  However, we never got the
levels
of engagement necessary to make sure that we satisfied all of their
requirements.  It's not clear that satisfying half of the requirements
is
actually useful to anyone and may cause unnecessary confusion to those
already engaged.

- Wes


From shemant@cisco.com  Wed Nov 23 07:42:34 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06EE61F0C73 for ; Wed, 23 Nov 2011 07:42:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.981
X-Spam-Level: 
X-Spam-Status: No, score=-5.981 tagged_above=-999 required=5 tests=[AWL=0.017,  BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 NRrLjdmbR9ky for ; Wed, 23 Nov 2011 07:42:31 -0800 (PST)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2B2B51F0C71 for ; Wed, 23 Nov 2011 07:42:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=14970; q=dns/txt; s=iport; t=1322062951; x=1323272551; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=6Mm+fzl/71+AvB8duoWUZVlar7/ZZjzSmNZxMQREC5w=; b=CJ8PbOkOTM/kUjZn93Xa2UFxxiV7fIAys8TdtgYnz3uQJRWI+5YMKbkY EMR5l2+WnTqqTeOT+d490bBV4lPKPhaYja9OXr4c6wJpS0yhjsLevxoPB df7iaK1VZSERGwpVfs7hdHEAN1NTzpNFn65B7DZqzTvWu8pXVxLJhHCjw M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ArQAAOoTzU6tJV2Z/2dsb2JhbABDgk2XfpAggQWBcgEBAQQBAQEPAQkRAz4LEAIBCBEEAQELBhcBBgEmHwkIAQEEEwgah2uWCwGeQASJf2MEiCCeUQ
X-IronPort-AV: E=Sophos;i="4.69,559,1315180800"; d="scan'208,217";a="38505558"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 23 Nov 2011 15:42:30 +0000
Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pANFgUh2012397;  Wed, 23 Nov 2011 15:42:30 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 23 Nov 2011 09:42:30 -0600
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCA9F6.82295189"
Date: Wed, 23 Nov 2011 09:42:29 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3035EEF82@XMB-RCD-109.cisco.com>
In-Reply-To: <82DD1735-321E-44CB-8E1E-FF7C3402A371@townsley.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] 6rd Sunsetting
Thread-Index: Acyp5CNpIkZczFjvREWkaYbC7PsaVAAEh59A
References:  <750BF7861EBBE048B3E648B4BB6E8F4F20B124DE@crexc50p> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EEEBA@XMB-RCD-109.cisco.com> <82DD1735-321E-44CB-8E1E-FF7C3402A371@townsley.net>
From: "Hemant Singh (shemant)" 
To: "Mark Townsley" 
X-OriginalArrivalTime: 23 Nov 2011 15:42:30.0383 (UTC) FILETIME=[8286E7F0:01CCA9F6]
Cc: v6ops@ietf.org
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 23 Nov 2011 15:42:34 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CCA9F6.82295189
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Mark,

=20

Thanks.  I agree.  Barbara,  based on Mark's reply, do we still need
manual configuration for 6rd in rfc6204bis and if so, what more for
guidance would you like?

=20

Hemant

=20

From: Mark Townsley [mailto:mark@townsley.net]=20
Sent: Wednesday, November 23, 2011 8:31 AM
To: Hemant Singh (shemant)
Cc: STARK, BARBARA H; v6ops@ietf.org
Subject: Re: [v6ops] 6rd Sunsetting

=20

=20

I think that manually configured 6rd, or manually configured anything
really, should be squarely out of scope whenever possible. I think the
WG should focus on default behavior and configuration handled via our
protocols. Once you've opened a user-level interface, all bets are off.=20

=20

That said, a manually configured 6rd interface should not be difficult
as long as you don't try to treat it "special". It's just another
interface like any other on the router. It has its own entry in the
forwarding table, and rules that are consistent with what we should
define for an ISP-configured 6rd interface. Everything we have discussed
here in terms of what is in 6rd-sunsetting and source routing to the
correct interface apply perfectly well, even if you have manual and
SP-configured interfaces (not to mention an HE tunnel on the side, etc.)

=20

The hard part comes when the CPE tries to become too intelligent for its
own good, automatically preferring one type of interface configuration
over another (note that I didn't say preferring one *route* over another
when the entries in the forwarding table are otherwise equal, I said
preferring one type of *configuration* over the other). I think this is
inherently bad as it means every single time there is a new type of
interface (virtual or otherwise) you have to fit it into a logic table
of what is and is not allowed. As long as the router can handle multiple
interfaces generically, it should "do as it's told", bring up interfaces
it has SP-supported or explicit manual configuration for, and route
accordingly. =20

=20

For troubleshooting, RFC 5969 includes advice on how to construct a
packet that will not only test the path between the CE and BR, it will
tell you which BR that packet happened to traverse. One could run a
BFD-like keepalive on a timer on the 6rd tunnel (the "NUD" section
Hemant refers to), but I think that's overkill for 6rd as long as you
have a well-supported BR deployment to plug into. If you are using the
6rd config with a single BR that is not well-supported, you might want
the CE to declare the interface down when a periodic NUD check fails. It
should be clear though that this is far removed from a "production"
ISP-supported 6rd deployment, and much more of a "trial" type of
operation that I think 6204-bis should not have to worry about.=20

=20

- Mark

=20

=20

On Nov 23, 2011, at 11:53 AM, Hemant Singh (shemant) wrote:





=20

From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
Of STARK, BARBARA H
Sent: Tuesday, November 15, 2011 10:33 AM
To: v6ops@ietf.org
Subject: Re: [v6ops] 6rd Sunsetting

=20

=20

>But when the CE router was manually configured for 6rd, I have no clue
what this means. How is the manually-configured CE router supposed to
know whether or not 6rd is configured by >the SP? Some guidance in this
area would be appreciated. For example, should the CE router test to see
if the BR is reachable, and if not assume that 6rd is not configured by
the SP?

=20

How can a subscriber in the home manually configure the CE router for
four 6rd parameters including the IPv4 address of the BR unless the
subscriber called the SP and got the information to configure manually.
Thus the SP knows about the CPE router in the subscriber's home and also
the CE router does not need to test if 6rd is configured by the SP.  If
the CE router still wants to test, then use the NUD specified in section
8 of RFC 5969.

=20

Hemant

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

=20


------_=_NextPart_001_01CCA9F6.82295189
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Mark,
 
Thanks.  I agree.  Barbara,  based on Mark’s =
reply, do we still need manual configuration for 6rd in rfc6204bis and =
if so, what more for guidance would you like?
 
Hemant
 
From:=
 =
Mark Townsley [mailto:mark@townsley.net] 
Sent: Wednesday, =
November 23, 2011 8:31 AM
To: Hemant Singh =
(shemant)
Cc: STARK, BARBARA H; =
v6ops@ietf.org
Subject: Re: [v6ops] 6rd =
Sunsetting
 
 
I =
think that manually configured 6rd, or manually configured anything =
really, should be squarely out of scope whenever possible. I think the =
WG should focus on default behavior and configuration handled via our =
protocols. Once you've opened a user-level interface, all bets are =
off. 
 
That said, a manually configured 6rd interface should =
not be difficult as long as you don't try to treat it =
"special". It's just another interface like any other on the =
router. It has its own entry in the forwarding table, and rules that are =
consistent with what we should define for an ISP-configured 6rd =
interface. Everything we have discussed here in terms of what is in =
6rd-sunsetting and source routing to the correct interface apply =
perfectly well, even if you have manual and SP-configured interfaces =
(not to mention an HE tunnel on the side, =
etc.)
 
The hard part comes when the CPE tries to become too =
intelligent for its own good, automatically preferring one type of =
interface configuration over another (note that I didn't say preferring =
one *route* over another when the entries in the forwarding table are =
otherwise equal, I said preferring one type of *configuration* over the =
other). I think this is inherently bad as it means every single time =
there is a new type of interface (virtual or otherwise) you have to fit =
it into a logic table of what is and is not allowed. As long as the =
router can handle multiple interfaces generically, it should "do as =
it's told", bring up interfaces it has SP-supported or explicit =
manual configuration for, and route accordingly. =
 
 
For troubleshooting, RFC 5969 includes advice on how =
to construct a packet that will not only test the path between the CE =
and BR, it will tell you which BR that packet happened to =
traverse. One could run a BFD-like keepalive on a timer on the 6rd =
tunnel (the "NUD" section Hemant refers to), but I think =
that's overkill for 6rd as long as you have a well-supported BR =
deployment to plug into. If you are using the 6rd config with a single =
BR that is not well-supported, you might want the CE to declare the =
interface down when a periodic NUD check fails. It should be clear =
though that this is far removed from a "production" =
ISP-supported 6rd deployment, and much more of a "trial" type =
of operation that I think 6204-bis should not have to worry =
about. 
 
- =
Mark
 
 
On Nov 23, 2011, at 11:53 AM, Hemant Singh (shemant) =
wrote:


 
From:=
 v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org=
] On Behalf Of STARK, BARBARA =
H
Sent: Tuesday, November 15, 2011 =
10:33 AM
To: v6ops@ietf.org
Subject: Re: [v6ops] 6rd =
Sunsetting
 
 
>But when the CE router was manually configured for 6rd, I have no =
clue what this means. How is the manually-configured CE router supposed =
to know whether or not 6rd is configured by >the SP? Some guidance in =
this area would be appreciated. For example, should the CE router test =
to see if the BR is reachable, and if not assume that 6rd is not =
configured by the SP?
 
How can a subscriber in the home manually configure the CE router for =
four 6rd parameters including the IPv4 address of the BR unless the =
subscriber called the SP and got the information to configure =
manually.  Thus the SP knows about the CPE router in the =
subscriber’s home and also the CE router does not need to test if =
6rd is configured by the SP.  If the CE router still wants to test, =
then use the NUD specified in section 8 of RFC =
5969.
 
Hemant
_________=
______________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org=
/mailman/listinfo/v6ops
 

------_=_NextPart_001_01CCA9F6.82295189--

From hsalgado@nic.cl  Wed Nov 23 08:20:45 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3796521F8C66 for ; Wed, 23 Nov 2011 08:20:45 -0800 (PST)
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 dcYWflphcqWD for ; Wed, 23 Nov 2011 08:20:41 -0800 (PST)
Received: from mail.nic.cl (mail.nic.cl [200.1.123.8]) by ietfa.amsl.com (Postfix) with ESMTP id 31D2521F8C63 for ; Wed, 23 Nov 2011 08:20:37 -0800 (PST)
Received: from mail.nic.cl (localhost.localdomain [127.0.0.1]) by mail.nic.cl (Postfix) with ESMTP id 2BF49CC844F for ; Wed, 23 Nov 2011 13:20:34 -0300 (CLST)
Received: from vulcano.intra.nic.cl (vulcano.intra.nic.cl [172.30.10.58]) by mail.nic.cl (Postfix) with ESMTP id 13445CC844D for ; Wed, 23 Nov 2011 13:20:34 -0300 (CLST)
Message-ID: <4ECD1D52.9080901@nic.cl>
Date: Wed, 23 Nov 2011 13:20:34 -0300
From: Hugo Salgado 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16
MIME-Version: 1.0
To: v6ops@ietf.org
References: <20111122155452.389.71704.idtracker@ietfa.amsl.com>
In-Reply-To: <20111122155452.389.71704.idtracker@ietfa.amsl.com>
X-Enigmail-Version: 1.1.2
OpenPGP: id=B525FA6E
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP on Wed Nov 23 13:20:34 2011 -0300 (CLST)
Subject: Re: [v6ops] I-D Action:	draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Nov 2011 16:20:45 -0000

Hi.
With the new title and scope of the draft I'm missing a reference to
RFC4074 somewhere in the document. I know is not directly related to
someone actively transitioning to IPv6, but in the operations field
I've seen the phenomenon of v4-only sites been side-affected for people
migrating to v6. I presented a talk about this, here's a pdf:
 http://hugo.salga.do/quad-a-blocking-in-dns

Maybe we can give a mention in the "3. IPv6 Adoption Implications"
section, pointing to 4074?

Regards,

Hugo


On 11/22/2011 12:54 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           : Considerations for Transitioning Content to IPv6
> 	Author(s)       : Jason Livingood
> 	Filename        : draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08.txt
> 	Pages           : 31
> 	Date            : 2011-11-22
> 
>    This document describes considerations for the transition of end user
>    content on the Internet to IPv6.  While this is tailored to address
>    end user content, which is typically web-based, many aspects of this
>    document may be more broadly applicable to the transition to IPv6 of
>    other applications and services.  This document explores the
>    challenges involved in the transition to IPv6, potential migration
>    tactics, possible migration phases, and other considerations.  The
>    audience for this document is the Internet community generally,
>    particularly IPv6 implementers.
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08.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-v6ops-v6-aaaa-whitelisting-implications-08.txt
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
> 


From dougb@dougbarton.us  Wed Nov 23 10:43:50 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C29F21F8B06 for ; Wed, 23 Nov 2011 10:43:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.454
X-Spam-Level: 
X-Spam-Status: No, score=-3.454 tagged_above=-999 required=5 tests=[AWL=0.145,  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 TOmLJR2Eke91 for ; Wed, 23 Nov 2011 10:43:49 -0800 (PST)
Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id 6EA3221F8A80 for ; Wed, 23 Nov 2011 10:43:48 -0800 (PST)
Received: (qmail 9062 invoked by uid 399); 23 Nov 2011 18:43:45 -0000
Received: from unknown (HELO ?172.17.198.245?) (dougb@dougbarton.us@12.207.105.210) by mail2.fluidhosting.com with ESMTPAM; 23 Nov 2011 18:43:45 -0000
X-Originating-IP: 12.207.105.210
X-Sender: dougb@dougbarton.us
Message-ID: <4ECD3EDF.2020206@dougbarton.us>
Date: Wed, 23 Nov 2011 10:43:43 -0800
From: Doug Barton 
Organization: http://SupersetSolutions.com/
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Thomas Narten 
References:  <4ECC139C.9080600@gmail.com> <201111231421.pANELBqP013658@cichlid.raleigh.ibm.com>
In-Reply-To: <201111231421.pANELBqP013658@cichlid.raleigh.ibm.com>
X-Enigmail-Version: 1.3.3
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] Title of draft-ietf-v6ops-v6-aaaa-whitelisting-implications-07
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 23 Nov 2011 18:43:50 -0000

On 11/23/2011 6:21 AM, Thomas Narten wrote:
>> I'm not going to insist. I do think the title overstates the
>> scope of the document somewhat; it is not a complete guide
>> to transitioning content.
> 
> I think it would be helpful to see the word "DNS" in the title
> somewhere, since much of this document is related to DNS. Otherwise, I
> agree the title is a bit broad.
> 
> How about something like:
> 
>             On Using the DNS for Transitioning Content to IPv6

If you're going to drag DNS into the title, I'd prefer something that
didn't imply that it's a protocol issue. How about, "DNS Access Control
Lists for Transitioning Content to IPv6." You can add a "Using" to the
beginning of that if you don't think it's too long. (Note, I
specifically rejected s/ACL/Whitelisting/ in order to avoid the
argument, no matter how silly I think the argument is, but I won't
object if you want to use it instead.)


hth,

Doug

-- 

		"We could put the whole Internet into a book."
		"Too practical."

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/


From wbeebee@cisco.com  Wed Nov 23 11:37:50 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8AB91F0C3C for ; Wed, 23 Nov 2011 11:37:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.189
X-Spam-Level: 
X-Spam-Status: No, score=-4.189 tagged_above=-999 required=5 tests=[AWL=0.343,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cKpeZAwggXAn for ; Wed, 23 Nov 2011 11:37:50 -0800 (PST)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 29B431F0C36 for ; Wed, 23 Nov 2011 11:37:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wbeebee@cisco.com; l=1035; q=dns/txt; s=iport; t=1322077070; x=1323286670; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=YHMY6bDVV6m9h+Lymn2YFXIaMjtKEfif4XoBENFInV4=; b=TaNePZBkUx/1K8i2GPbCoQWlli2iYXP0Wuy4huYiWyv+y4CeD43eKGhP aIRAcE+XFoNUx8s38Ydkcxy6C+ljilaOuo++u4GObkk5lB7RNvGQQwuKr b32KhVdzCYU3JDn7VLQ95db7oHH7C7OzNblZvCWbfD2DHHb0h8x/EHt+J o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgMHAFRKzU6tJXG9/2dsb2JhbABDiUmhKAKBBYFyAQEBAwESAScCATwFDQEIgR0BAQQBDSeHY5YZAZ4vimIEiCCMKI11hDM
X-IronPort-AV: E=Sophos;i="4.69,560,1315180800"; d="scan'208";a="38574998"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-4.cisco.com with ESMTP; 23 Nov 2011 19:37:50 +0000
Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id pANJbnEZ018650;  Wed, 23 Nov 2011 19:37:49 GMT
Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 23 Nov 2011 13:37:49 -0600
Received: from 161.44.175.128 ([161.44.175.128]) by XMB-RCD-201.cisco.com ([72.163.62.208]) with Microsoft Exchange Server HTTP-DAV ;  Wed, 23 Nov 2011 19:37:49 +0000
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Wed, 23 Nov 2011 14:37:44 -0500
From: Wes Beebee 
To: Mark Townsley , Gert Doering 
Message-ID: 
Thread-Topic: [v6ops] 6rd Sunsetting
Thread-Index: AcyqF17laM1VlQq2NUyGzISSNTPiVA==
In-Reply-To: 
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 23 Nov 2011 19:37:49.0574 (UTC) FILETIME=[62387A60:01CCAA17]
Cc: Alexandre Cassen , v6ops@ietf.org, Claire Cheng 
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 23 Nov 2011 19:37:51 -0000

> So, I think Gert's right here. For all practical purposes, when a 6rd and
> native interface are up with different prefixes for each, the CPE has to
> ensure that it sends packets over the right interface. Same is true for
> multihoming in general. Only way to get around it is to keep the prefix the
> same. 

Section 4.4.3 of draft-ietf-v6ops-6204bis-03:

"  5.  Selection of 6rd tunnel or native IPv6 output interface on the CE
       router is determined by the source IPv6 address of the packet
       from a host, when different prefixes are available over 6rd vs.
       native IPv6.  If the two interfaces provide the CE router with
       the same prefix, then the CE router prefers the native IPv6
       interface to the 6rd interface for forwarding traffic out the WAN
       when both 6rd and native IPv6 interfaces are active.

   6.  The CE router messages to the host the use of native IPv6 in
       preference to 6rd, in the case where the two interfaces use
       different prefixes."

- Wes


From brian.e.carpenter@gmail.com  Wed Nov 23 12:16:15 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A57DE11E809F for ; Wed, 23 Nov 2011 12:16:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.548
X-Spam-Level: 
X-Spam-Status: No, score=-103.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ikqf-GF01r5f for ; Wed, 23 Nov 2011 12:16:15 -0800 (PST)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2211411E808D for ; Wed, 23 Nov 2011 12:16:15 -0800 (PST)
Received: by vcbfy13 with SMTP id fy13so2040027vcb.31 for ; Wed, 23 Nov 2011 12:16:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=m7Wc+lApl8bnB9jk9PKb7aOsxBzlYuCC/UM9cDAriNE=; b=gUwhDstytKiwLXZXODaDHHN2mU9RdXB1kbVbXPdeUUJg0MgrRyD4MUl4GLDfsQaVYt R6sSdo4NGq9C4A4TuwDzzpEWZIcVHiFfivtRRcR1JO14VUVsplcSXrJktaRoHCzxMEah aiLc8kXUPmbLFz3q4bX7xE9GLUYRM/p7+W+fQ=
Received: by 10.52.26.9 with SMTP id h9mr26749688vdg.99.1322079374613; Wed, 23 Nov 2011 12:16:14 -0800 (PST)
Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id w5sm25386474vdh.17.2011.11.23.12.16.11 (version=SSLv3 cipher=OTHER); Wed, 23 Nov 2011 12:16:13 -0800 (PST)
Message-ID: <4ECD5484.4090009@gmail.com>
Date: Thu, 24 Nov 2011 09:16:04 +1300
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Thomas Narten 
References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com><7EB596BF-B175-40BF-ABC8-326599670B04@apple.com><5B6B2B64C9FE2A489045EEEADDAFF2C303544B88@XMB-RCD-109.cisco.com><8D342733-88E6-45D3-B388-E001AE32CD77@employees.org><750BF7861EBBE048B3E648B4BB6E8F4F20DC4FEA@crexc50p><007801cca8c8$5610aa00$0231fe00$@iname.com><750BF7861EBBE048B3E648B4BB6E8F4F20EA1037@crexc50p>		<750BF7861EBBE048B3E! 6 48B4BB6E8F4F20EA1083@crexc50p>		<14640DA2-54E5-46E9-B255-D141F1934596@nominum.com> <201111231402.pANE21YK013540@cichlid.raleigh.ibm.com>
In-Reply-To: <201111231402.pANE21YK013540@cichlid.raleigh.ibm.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: IPv6 Operations 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 23 Nov 2011 20:16:15 -0000

On 2011-11-24 03:02, Thomas Narten wrote:
>> I have come to believe that the reason we didn't achieve consensus
>> on this was that we didn't have the right architecture, and in the
>> architecture we had, the M and O bits didn't work.  I'm not
>> convinced that, if we were to fix the architecture, the M and O bits
>> wouldn't suddenly start to make sense.
> 
> Classic problem with M/O bits: They were defined before we actually
> had DHCP defined. I.e., we were guessing at what the bits would be
> used for in the future, and we got it wrong.
> 
> If we could do it all over again, I would argue for:
> 
>  no M/O bits
>  Every client always issues a DHCP request (and RS)
>  No difference between address and non-address config
>     request/protocol for DHCP
>  Client always asks for config info, gets what the network operator
>     has configured to send out, whether addresses or other stuff.
>  mandate that clients do both DHCP/RAs
> 
> I.e., keep it simple/predictable for the client and operator both.

Yes, that would have been nice. Cam we get there by making the recommendation
for the future exactly as above *except* that the first line would read
  ignore M/O bits
?

    Brian

From shemant@cisco.com  Wed Nov 23 12:21:34 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D18DC11E808D for ; Wed, 23 Nov 2011 12:21:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.282
X-Spam-Level: 
X-Spam-Status: No, score=-6.282 tagged_above=-999 required=5 tests=[AWL=0.317,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7cjd0RN7KeDf for ; Wed, 23 Nov 2011 12:21:33 -0800 (PST)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 295A911E809F for ; Wed, 23 Nov 2011 12:21:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=532; q=dns/txt; s=iport; t=1322079693; x=1323289293; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=KgxhGXPIern+8S3dXq/Uo/2vackNPGb35h7QjolaK7Y=; b=Q3g8TlAct00lK4sn9DmvV7lKOV+idObniceFeb9mtj3cBU5evp5ff2dS a+4EUX+LM17kdC6/suvvSAA+B4gZ0Bcopa5xve58oWRGhrH0oUaTOFhN8 cQh8HNcC8KHbx1m1ASZa75CC7SskwEfslbLPnZd0R1eMAsJbK6cb6LvjJ k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AocAAFlVzU6tJXHB/2dsb2JhbABDmlGQIoEFgXIBAQEEEgEdCj8MBAIBCBEEAQELBhcBBgFFCQgBAQQBEgganggBniyJf2MEiCCVLYkk
X-IronPort-AV: E=Sophos;i="4.69,561,1315180800"; d="scan'208";a="38575149"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-8.cisco.com with ESMTP; 23 Nov 2011 20:21:32 +0000
Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id pANKLWpM012651;  Wed, 23 Nov 2011 20:21:32 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 23 Nov 2011 14:21:32 -0600
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 23 Nov 2011 14:21:31 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF106@XMB-RCD-109.cisco.com>
In-Reply-To: <4ECD5484.4090009@gmail.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] DHCPv6 option for MAX_SOL_RT
Thread-Index: AcyqHMf0qiezV5GkTxS2S0nQdpvLrgAAJskQ
References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com><7EB596BF-B175-40BF-ABC8-326599670B04@apple.com><5B6B2B64C9FE2A489045EEEADDAFF2C303544B88@XMB-RCD-109.cisco.com><8D342733-88E6-45D3-B388-E001AE32CD77@employees.org><750BF7861EBBE048B3E648B4BB6E8F4F20DC4FEA@crexc50p><007801cca8c8$5610aa00$0231fe00$@iname.com><750BF7861EBBE048B3E648B4BB6E8F4F20EA1037@crexc50p>		<750BF7861EBBE048B3E!648B4BB6E8F4F20EA1083@crexc50p>		<14640DA2-54E5-46E9-B255-D141F1934596@nominum.com><201111231402.pANE21YK013540@cichlid.raleigh.ibm.com> <4ECD5484.4090009@gma il.com>
From: "Hemant Singh (shemant)" 
To: "Brian E Carpenter" , "Thomas Narten" 
X-OriginalArrivalTime: 23 Nov 2011 20:21:32.0592 (UTC) FILETIME=[7DA94300:01CCAA1D]
Cc: IPv6 Operations 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 23 Nov 2011 20:21:34 -0000

-----Original Message-----
From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
Of Brian E Carpenter
Sent: Wednesday, November 23, 2011 3:16 PM
To: Thomas Narten
Cc: IPv6 Operations
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT


>Yes, that would have been nice. Cam we get there by making the
recommendation
>for the future exactly as above *except* that the first line would read
>  ignore M/O bits?

Which document do we add the new text to?  Node-req-bis would be one
choice?

Hemant

From brian.e.carpenter@gmail.com  Wed Nov 23 12:23:43 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5494A11E80E4 for ; Wed, 23 Nov 2011 12:23:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.249
X-Spam-Level: 
X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, 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 CS0x8OKxxV8Y for ; Wed, 23 Nov 2011 12:23:42 -0800 (PST)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id B578C11E808D for ; Wed, 23 Nov 2011 12:23:15 -0800 (PST)
Received: by vcbfy13 with SMTP id fy13so2048396vcb.31 for ; Wed, 23 Nov 2011 12:23:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=hQZyx2abBNB3xULJ4Rj/nx7UHXYHyii2DS+TSuI3su0=; b=E/L8BgqUFXYuVz9KAX9i/WutngN5Ws+RFfRufgRdGzoDL8ye2YGofQWrXA4Th17Cxg 8ISQNfpPSXyllSDhf548SjrRlQQrgHOqdMXZhXmQ72QKSVnf/JQkEoHoleLTzaTeVhD/ Ba3xaVxLf6xTOfE5wTwTl150BOifBQWdZebHg=
Received: by 10.52.187.196 with SMTP id fu4mr641508vdc.9.1322079795267; Wed, 23 Nov 2011 12:23:15 -0800 (PST)
Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id y3sm21121833vdj.4.2011.11.23.12.23.11 (version=SSLv3 cipher=OTHER); Wed, 23 Nov 2011 12:23:13 -0800 (PST)
Message-ID: <4ECD562C.2020501@gmail.com>
Date: Thu, 24 Nov 2011 09:23:08 +1300
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:   <68DAB112-6E32-45FE-9AB7-A34E64898F60@cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30354436E@XMB-RCD-109.cisco.com> <750BF7861EBBE048B3E648B4BB6E8F4F20DC41F6@crexc50p>  <252D3DEA-FF09-42C8-959E-8A7205D9DE67@townsley.net>  <20111122133612.GH71280@Space.Net> <4ECC10C9.5010607@gmail.com> <20111123080113.GI71280@Space.Net>
In-Reply-To: <20111123080113.GI71280@Space.Net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: Alexandre Cassen , Claire Cheng , v6ops@ietf.org
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 23 Nov 2011 20:23:43 -0000

Gert,

On 2011-11-23 21:01, Gert Doering wrote:
> Hi,
> 
> On Wed, Nov 23, 2011 at 10:14:49AM +1300, Brian E Carpenter wrote:
>> This, or strict RPF, would be self-foot-shooting by the ISP
>> wishing to sunset 6rd. It seems fairly simple to specify that
>> both ingress filtering and RPF should be configured to allow
>> both prefixes simultaneously. 
> 
> Permit me a polite cough here.
> 
> *The* benefit of 6rd on the gateway side is that it's stateless, which
> means "no per-subscriber information needs to be gathered, kept, and
> validated for incoming packets".
> 
> So either you want RPF filtering on the 6rd side, or not - but there is
> no reasonable way you can ISP subscriber data for a reasonable-sized
> ISP into the 6rd gateways to enable RPF filtering "plus extra prefixes
> for some of the subscribers" on the 6rd gateway.

I would not propose doing it per-subscriber, for exactly that reason.
During the sunset procedure, you would have to allow a prefix short enough to
cover all subscribers. Yes, that might mean relaxing your anti-spoofing
during the sunset. That's a trade-off.

> 
> 
>> This is a standard need for
>> multihomed PA customers anyway, and needs to become standard
>> practice for all IPv6 ISPs.
> 
> This is a standard *problem*, not a "standard need".
> 
> You're not going to see large-scale ISPs that do deploy RPF filtering
> (few enough, alas) add "oh, this customer also has prefix X from ISP Z
> this week!" to their subscriber management platform, which is where the 
> routers get configured from.  Including verification that this 
> customer is even entitled to *use* prefix X at this time.

It needs to be automated, and that's a protocol gap (which v6ops
by construction cannot fix). It will also end up as part of the
6renum gap analysis.



>> While we do need a solution for source-prefix based exit
>> selection, we don't have one yet and it's a separable problem.
> 
> I strongly disagree.  This is the core of the problem for multi-PA-based
> multihoming, and one variant presents itself now with "two different
> access technologies with different prefixes to the same ISP".

Actually we agree - it is a core problem here, for 6renum, and for
ipv6-multihoming-without-ipv6nat. Probably for MIF and HOMENET too.
That's all I meant by saying it's separable: we need to solve the
general case.

   Brian

From shemant@cisco.com  Wed Nov 23 12:26:55 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B674111E80AC for ; Wed, 23 Nov 2011 12:26:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.984
X-Spam-Level: 
X-Spam-Status: No, score=-5.984 tagged_above=-999 required=5 tests=[AWL=0.015,  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 wMSO0RKee7aj for ; Wed, 23 Nov 2011 12:26:55 -0800 (PST)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id E280B11E809F for ; Wed, 23 Nov 2011 12:26:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=3076; q=dns/txt; s=iport; t=1322080015; x=1323289615; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=QYThaUStbeQrUjGt0570im707B3LJwH2jAaNcGiZPak=; b=h/J5o4VO8eWpbEroD7qTQVi4bf+jL4o2vcOVf5jMxHwVIOUfgF/OKSJJ cXs1v9RlniCCVJHngDlSqFdZaLf4rvGPSUEP4BWU1iNu0EdNebWGMXgId GJ+WGIpx2fWH66L6rdM1H0lzaCin8x08ErYq2fn/TRgvsUb7T2oTA8Qpb M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AocAAGtWzU6tJV2d/2dsb2JhbABEmlGQIoEFgXIBAQEDAQEBAQ8BHQo0CwwEAgEIEQQBAQEKBhcBBgEmHwkIAQEEARIIEweHYwiWFQGeKASJf2MEiCCeUQ
X-IronPort-AV: E=Sophos;i="4.69,561,1315180800"; d="scan'208";a="38575285"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 23 Nov 2011 20:26:54 +0000
Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id pANKQsB2004060;  Wed, 23 Nov 2011 20:26:54 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 23 Nov 2011 14:26:54 -0600
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 23 Nov 2011 14:26:53 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF10A@XMB-RCD-109.cisco.com>
In-Reply-To: <4ECD562C.2020501@gmail.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] 6rd Sunsetting
Thread-Index: AcyqHc/sDZrO6HkcStOu1M+t8iaOJgAAD9Vw
References: <68DAB112-6E32-45FE-9AB7-A34E64898F60@cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C30354436E@XMB-RCD-109.cisco.com><750BF7861EBBE048B3E648B4BB6E8F4F20DC41F6@crexc50p><252D3DEA-FF09-42C8-959E-8A7205D9DE67@townsley.net><20111122133612.GH71280@Space.Net> <4ECC10C9.5010607@gmail.com><20111123080113.GI71280@Space.Net> <4ECD562C.2020501@gmail.com>
From: "Hemant Singh (shemant)" 
To: "Brian E Carpenter" , "Gert Doering" 
X-OriginalArrivalTime: 23 Nov 2011 20:26:54.0489 (UTC) FILETIME=[3D86D890:01CCAA1E]
Cc: Alexandre Cassen , v6ops@ietf.org, Claire Cheng 
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 23 Nov 2011 20:26:55 -0000

Clarifying question:

By 6rd on the gateway side, do we mean the gateway is the 6rd BR (Border
Relay) or the home gateway in the CPE router?  Sorry, I haven't caught
up with all emails on this thread yet,

Hemant

-----Original Message-----
From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
Of Brian E Carpenter
Sent: Wednesday, November 23, 2011 3:23 PM
To: Gert Doering
Cc: Alexandre Cassen; Claire Cheng; v6ops@ietf.org
Subject: Re: [v6ops] 6rd Sunsetting

Gert,

On 2011-11-23 21:01, Gert Doering wrote:
> Hi,
>=20
> On Wed, Nov 23, 2011 at 10:14:49AM +1300, Brian E Carpenter wrote:
>> This, or strict RPF, would be self-foot-shooting by the ISP
>> wishing to sunset 6rd. It seems fairly simple to specify that
>> both ingress filtering and RPF should be configured to allow
>> both prefixes simultaneously.=20
>=20
> Permit me a polite cough here.
>=20
> *The* benefit of 6rd on the gateway side is that it's stateless, which
> means "no per-subscriber information needs to be gathered, kept, and
> validated for incoming packets".
>=20
> So either you want RPF filtering on the 6rd side, or not - but there
is
> no reasonable way you can ISP subscriber data for a reasonable-sized
> ISP into the 6rd gateways to enable RPF filtering "plus extra prefixes
> for some of the subscribers" on the 6rd gateway.

I would not propose doing it per-subscriber, for exactly that reason.
During the sunset procedure, you would have to allow a prefix short
enough to
cover all subscribers. Yes, that might mean relaxing your anti-spoofing
during the sunset. That's a trade-off.

>=20
>=20
>> This is a standard need for
>> multihomed PA customers anyway, and needs to become standard
>> practice for all IPv6 ISPs.
>=20
> This is a standard *problem*, not a "standard need".
>=20
> You're not going to see large-scale ISPs that do deploy RPF filtering
> (few enough, alas) add "oh, this customer also has prefix X from ISP Z
> this week!" to their subscriber management platform, which is where
the=20
> routers get configured from.  Including verification that this=20
> customer is even entitled to *use* prefix X at this time.

It needs to be automated, and that's a protocol gap (which v6ops
by construction cannot fix). It will also end up as part of the
6renum gap analysis.



>> While we do need a solution for source-prefix based exit
>> selection, we don't have one yet and it's a separable problem.
>=20
> I strongly disagree.  This is the core of the problem for
multi-PA-based
> multihoming, and one variant presents itself now with "two different
> access technologies with different prefixes to the same ISP".

Actually we agree - it is a core problem here, for 6renum, and for
ipv6-multihoming-without-ipv6nat. Probably for MIF and HOMENET too.
That's all I meant by saying it's separable: we need to solve the
general case.

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

From brian.e.carpenter@gmail.com  Wed Nov 23 12:28:09 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4479921F852E for ; Wed, 23 Nov 2011 12:28:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.545
X-Spam-Level: 
X-Spam-Status: No, score=-103.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QC8qozHwxItF for ; Wed, 23 Nov 2011 12:28:08 -0800 (PST)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id AE24321F851F for ; Wed, 23 Nov 2011 12:28:08 -0800 (PST)
Received: by vbbez10 with SMTP id ez10so2045183vbb.31 for ; Wed, 23 Nov 2011 12:28:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=uUj6wSrFL62V2WJDFKsyOSMvRwR42VhRvRiWuEQnZSE=; b=QfyniR4cEq5J9DrTYvRjfZ3YxUp3XqULVyvH/kGUctZDzghCuNGmTGjMIFFMrDM1Hr duoWT698Q+p0vnWbkfUs5JX6KymFK3euEX0CrbvHli6zS2wvz9zD044c98DKf3SepbeS yBzwJF3MlSPmaEfYXScpCfCcxH30CCF0ZSHWw=
Received: by 10.52.99.74 with SMTP id eo10mr9457094vdb.12.1322080088250; Wed, 23 Nov 2011 12:28:08 -0800 (PST)
Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id y3sm21139940vdj.4.2011.11.23.12.28.04 (version=SSLv3 cipher=OTHER); Wed, 23 Nov 2011 12:28:07 -0800 (PST)
Message-ID: <4ECD5752.4000504@gmail.com>
Date: Thu, 24 Nov 2011 09:28:02 +1300
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Wes Beebee 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: Alexandre Cassen , v6ops@ietf.org, Claire Cheng 
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 23 Nov 2011 20:28:09 -0000

On 2011-11-24 08:37, Wes Beebee wrote:
>> So, I think Gert's right here. For all practical purposes, when a 6rd and
>> native interface are up with different prefixes for each, the CPE has to
>> ensure that it sends packets over the right interface. Same is true for
>> multihoming in general. Only way to get around it is to keep the prefix the
>> same. 
> 
> Section 4.4.3 of draft-ietf-v6ops-6204bis-03:
> 
> "  5.  Selection of 6rd tunnel or native IPv6 output interface on the CE
>        router is determined by the source IPv6 address of the packet
>        from a host, when different prefixes are available over 6rd vs.
>        native IPv6.  If the two interfaces provide the CE router with
>        the same prefix, then the CE router prefers the native IPv6
>        interface to the 6rd interface for forwarding traffic out the WAN
>        when both 6rd and native IPv6 interfaces are active.
> 
>    6.  The CE router messages to the host the use of native IPv6 in
>        preference to 6rd, in the case where the two interfaces use
>        different prefixes."

I am not sure I understand how rule 5 is implemented algorithmically.
Can you spell it out?

    Brian

From wbeebee@cisco.com  Wed Nov 23 12:40:30 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41C2D11E80BD for ; Wed, 23 Nov 2011 12:40:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[AWL=0.322,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7j-Rc-+4l5xZ for ; Wed, 23 Nov 2011 12:40:29 -0800 (PST)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 93E0E11E80A0 for ; Wed, 23 Nov 2011 12:40:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wbeebee@cisco.com; l=1493; q=dns/txt; s=iport; t=1322080829; x=1323290429; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=+1TNoioiJh6wkX8/kzXAz01TUCsy2Q5a0460Kj271NY=; b=bjDnmJCALLbDUDEAaoluyEe9H4hhaiDg0Limkoq+oTcOJLXlMMHQ4OnL qN4WkSiTdYgMPRPuu6yU1qZNFA/X0aMGXnu/BAQgBE2+oeUzm0JonL1qf fP4wnIGw/3W4imfT7WAT27EGoxf46lgsmh/Tn5M07DAHVKp8TYKmPqt0H 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgMHALpZzU6tJV2b/2dsb2JhbABEiUmhKAKBBYFyAQEBAwESAScCATwSAQiBHQEBBA4nh2OWIAGeK4piBIggjCiNdYQz
X-IronPort-AV: E=Sophos;i="4.69,561,1315180800"; d="scan'208";a="38590282"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 23 Nov 2011 20:40:29 +0000
Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pANKeTFq028326;  Wed, 23 Nov 2011 20:40:29 GMT
Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 23 Nov 2011 14:40:28 -0600
Received: from 161.44.175.128 ([161.44.175.128]) by XMB-RCD-201.cisco.com ([72.163.62.208]) with Microsoft Exchange Server HTTP-DAV ;  Wed, 23 Nov 2011 20:40:28 +0000
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Wed, 23 Nov 2011 15:40:26 -0500
From: Wes Beebee 
To: Brian E Carpenter 
Message-ID: 
Thread-Topic: [v6ops] 6rd Sunsetting
Thread-Index: AcyqICE5ck8JhIQjVUCasntZ2FfVww==
In-Reply-To: <4ECD5752.4000504@gmail.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 23 Nov 2011 20:40:28.0978 (UTC) FILETIME=[23000120:01CCAA20]
Cc: Alexandre Cassen , v6ops@ietf.org, Claire Cheng 
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 23 Nov 2011 20:40:30 -0000

>> Section 4.4.3 of draft-ietf-v6ops-6204bis-03:
>> 
>> "  5.  Selection of 6rd tunnel or native IPv6 output interface on the CE
>>        router is determined by the source IPv6 address of the packet
>>        from a host, when different prefixes are available over 6rd vs.
>>        native IPv6.  If the two interfaces provide the CE router with
>>        the same prefix, then the CE router prefers the native IPv6
>>        interface to the 6rd interface for forwarding traffic out the WAN
>>        when both 6rd and native IPv6 interfaces are active.
>
> I am not sure I understand how rule 5 is implemented algorithmically.
> Can you spell it out?

One possible implementation of rule 5 (e.g. On Cisco routers) would be
Policy-Based Routing (PBR) selecting by an Access Control List (ACL)
matching the source IPv6 address to the native or 6rd prefix (when
different), that would then select the output interface as the PBR action.
When the prefixes are configured to be the same, two routes would be
configured in the Forwarding Information Base (FIB) for native and 6rd and
the native route would have a lower administrative distance metric than the
6rd route.

It's possible to configure this on a Cisco router such that the behavior
described in #5 is observed.  However, for a super cheap home router, they
may not choose to actually implement all of PBR, ACL, etc - and they may
find a more direct way to implement the behavior described in #5.

- Wes 


From john.mann@monash.edu  Wed Nov 23 14:31:24 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC8111E80A0 for ; Wed, 23 Nov 2011 14:31:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.901
X-Spam-Level: 
X-Spam-Status: No, score=-5.901 tagged_above=-999 required=5 tests=[AWL=0.075,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_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 fOYTD8xVjEGJ for ; Wed, 23 Nov 2011 14:31:23 -0800 (PST)
Received: from na3sys009aog124.obsmtp.com (na3sys009aog124.obsmtp.com [74.125.149.151]) by ietfa.amsl.com (Postfix) with ESMTP id ABE1721F844E for ; Wed, 23 Nov 2011 14:31:22 -0800 (PST)
Received: from mail-vx0-f172.google.com ([209.85.220.172]) (using TLSv1) by na3sys009aob124.postini.com ([74.125.148.12]) with SMTP ID DSNKTs10M8VvbeNfBUfkHuD1x7/aGV92uMED@postini.com; Wed, 23 Nov 2011 14:31:22 PST
Received: by mail-vx0-f172.google.com with SMTP id fy13so2164066vcb.31 for ; Wed, 23 Nov 2011 14:31:15 -0800 (PST)
Received: by 10.182.217.105 with SMTP id ox9mr8978603obc.45.1322087475231; Wed, 23 Nov 2011 14:31:15 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.16.106 with HTTP; Wed, 23 Nov 2011 14:30:54 -0800 (PST)
In-Reply-To: 
References:  
From: John Mann 
Date: Thu, 24 Nov 2011 09:30:54 +1100
Message-ID: 
To: "Livingood, Jason" 
Content-Type: multipart/alternative; boundary=f46d0444731152bd5404b26e7a73
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] Update of draft-ietf-v6ops-v6-aaaa-whitelisting-implications-07
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 23 Nov 2011 22:31:24 -0000

--f46d0444731152bd5404b26e7a73
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On 24 November 2011 00:06, Livingood, Jason <
Jason_Livingood@cable.comcast.com> wrote:

>
>   ---
> 4.3.1.1
>
>    1.  The authoritative DNS server for example.com receives DNS queries =
for the A (IPv4) and/or AAAA (IPv6) address resource records for the Fully =
Qualified Domain Name (FQDN) www.example.com, for which AAAA (IPv6) resourc=
e records exist.
>
>
>     2.  The authoritative DNS server checks the IP address (IPv4, IPv6, o=
r both) of the DNS recursive resolver sending the AAAA (IPv6) query against=
 the whitelist that is the DNS Whitelist.
>
>  ---
> Step 1 is for A and/or AAAA queries, but step 2 is only for AAAA queries =
??
>
>   The server does not know all the addresses of the resolver, only the
> address used by the query packet.
> Also  whitelist ... Whitelist.
>
>
>  Yes, this was intended; this is AAAA whitelisting =96 not both A and AAA=
A
> whitelisting. Also, when referring to whitelisting and blacklisting
> generally, those terms are not capitalized on their own.
>

Let me try making myself clearer.

a) "DNS query for the A (IPv4) and/or AAAA (IPv6) address resource records"

   A DNS query for the A resource records would match step 1.
   There is not much need to run this algorithm if the query only asks for
A records.

   I think a DNS query can only ask one question, and so can't explicitly
ask for "A and AAAA" records.

Also, there are other queries that can return AAAA records that the
requestor would then use -- in the Answer section
---
$ dig any www.apnic.net

; <<>> DiG 9.3.6-P1-RedHat-9.3.6-16.P1.el5 <<>> any www.apnic.net
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57785
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 8, ADDITIONAL: 9

;; QUESTION SECTION:
;www.apnic.net. IN ANY

;; ANSWER SECTION:
www.apnic.net. 178 IN AAAA 2001:dc0:2001:11::194
www.apnic.net. 178 IN AAAA 2001:dc0:2001:11::211
www.apnic.net. 11 IN A 202.12.29.194
www.apnic.net. 11 IN A 202.12.29.211
...
---

Or in the Additional section
---
$ dig mx apnic.net

; <<>> DiG 9.3.6-P1-RedHat-9.3.6-16.P1.el5 <<>> mx apnic.net
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4548
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 8, ADDITIONAL: 11

;; QUESTION SECTION:
;apnic.net. IN MX

;; ANSWER SECTION:
apnic.net. 137 IN MX 15 tofu.apnic.net.
apnic.net. 137 IN MX 35 hoisin.apnic.net.
apnic.net. 137 IN MX 40 fennel.apnic.net.

;; AUTHORITY SECTION:
apnic.net. 10429 IN NS ns3.apnic.net.
apnic.net. 10429 IN NS ns4.apnic.com.
apnic.net. 10429 IN NS ns4.apnic.net.
apnic.net. 10429 IN NS sec1.apnic.net.
apnic.net. 10429 IN NS sec1.authdns.ripe.net.
apnic.net. 10429 IN NS tinnie.arin.net.
apnic.net. 10429 IN NS tinnie.apnic.net.
apnic.net. 10429 IN NS ns1.apnic.net.

;; ADDITIONAL SECTION:
tofu.apnic.net. 2422 IN A 202.12.29.195
tofu.apnic.net. 2422 IN AAAA 2001:dc0:2001:11::195
hoisin.apnic.net. 9602 IN A 202.12.29.215
hoisin.apnic.net. 2402 IN AAAA 2001:dc0:2001:11::215
fennel.apnic.net. 2415 IN A 202.12.31.144
fennel.apnic.net. 2415 IN AAAA 2001:dc0:4001:1:0:1836:0:144
...
---
Note here that the AAAA records belong to the mail hosts, not to the FQDN
specified in the query.

So, I think better words could be
---
   1. The authoritative DNS server for example.com receives a DNS query
(AAAA, ANY, MX, NS etc) that could return AAAA (IPv6) resource records.
---


b) In step 2, the server does not know more than one addresses of the
resolver, only the particular address used in the query packet.
    The text ", or both" is wrong.

c) The text repeats itself where it says "the whitelist that is the DNS
Whitelist".

    John

--f46d0444731152bd5404b26e7a73
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable



On 24 November 2011 00:06, Livingood, Ja=
son <Jason_Livingood@cable.comcast.com> wrote:























---


4.3.1.1




   1.  The au=
thoritative DNS server for example.com receives DNS queries for the A (IPv4) and/or AAAA (IPv6) a=
ddress resource records for the Fully Qualified Domain Name (FQDN) www.example.com, for whic=
h AAAA (IPv6) resource records exist.










   2.  The au=
thoritative DNS server checks the IP address (IPv4, IPv6, or both) of the D=
NS recursive resolver sending the AAAA (IPv6) query against the whitelist t=
hat is the DNS Whitelist.





---


Step 1 is for A and/or AAAA queries, but step 2 is only for AAAA queri=
es ??















The server does not know all the addresses of the resolver, only the a=
ddress used by the query packet.


Also =A0whitelist ... Whitelist.














Yes, this was intended; this is AAAA whitelisting =96 not both A=
 and AAAA whitelisting. Also, when referring to whitelisting and blacklisti=
ng generally, those terms are not capitalized on their own.=A0




Let me try making myself clearer.=A0
=


a)=A0"DNS query for th=
e A (IPv4) and/or AAAA (IPv6) address resource records"




=A0 =A0A DNS query for the A resource records would mat=
ch step 1.
=A0 =A0There is not much need to run this algorithm if=
 the query only asks for A records.

=A0 =A0I think=
 a DNS query can only ask one question, and so can't explicitly ask for=
 "A and AAAA" records.




Also, there are other queries that can return AAAA reco=
rds that the requestor would then use -- in the Answer section
--=
-
$ dig any www.apnic.net

=

;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 8, ADDITIONAL: 9

;; QUESTION SECTION:




;; ANSWER SECTION:
www.apnic.net.		178	IN	AAAA	2001:=
dc0:2001:11::194



www.apnic.net.		178	IN	AAAA	2001:dc0:2001:11::211



www.apnic.net.		11	IN	A	202.12.29.194



www.apnic.net.		11	IN	A	202.12.29.211



...
---

Or in the Additional sectio=
n
---
$ dig mx apnic.=
net

; <<>> DiG 9.3.6-P1-RedHat-9.3=
.6-16.P1.el5 <<>> mx apnic.net=




;; global options: =A0printcmd
;; Got answer:
;; -=
>>HEADER<<- opcode: QUERY, status: NOERROR, id: 4548
=
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 8, ADDITIONAL: 11




;; QUESTION SECTION:
;apnic.net.			IN	MX




;; ANSWER SECTION:
apnic.net.	=
	137	IN	MX	15 tofu.apnic.net.



apnic.net.		137	IN	MX	35 hoisin.apnic.net=
.



apnic.net.		137	IN	MX	40 fennel.apnic.net=
.




;; AUTHORITY SECTION:
apnic.net.		10429	<=
/span>IN	NS=
	ns3.apnic.net.



apnic.net.		10429	IN	NS	ns4.apnic.com.



apnic.net.		10429	IN	NS	ns4.apnic.net.



apnic.net.		10429	IN	NS	sec1.apnic.net.




apnic.net.		10429	IN	NS	tinnie.arin.net.


apnic.net.		10429	IN	NS	tinnie.apnic.net.=




apnic.net.		10429	IN	NS	ns1.apnic.net.




;; ADDITIONAL SECTION:
tofu.apnic.net.		2422	IN=
	A	2=
02.12.29.195



tofu.apnic.net.		2422	IN	AAAA	2001:dc0:2001:11::195



hoisin.apnic.net.	9602	IN	A	202.12.29.215



hoisin.apnic.net.	2402	IN	AAAA	2001:dc0:2001:11::215



fennel.apnic.net.	2415	IN	A	202.12.31.144



fennel.apnic.net.	2415	IN	AAAA	2001:dc0:4001:1:0:1836:0:144



...
---
Note here that the AAAA records belong to =
the mail hosts, not to the FQDN specified in the query.

So, I think better words could be
---
=A0 =A01.  The =
authoritative DNS server for example.com=
 receives a DNS query (AAAA, ANY, MX, NS etc) that could return AAAA (IPv6)=
 resource records.



---

b) In step 2, the server does no=
t know more than one addresses of the resolver, only the particular address=
 used in the query packet.



=A0 =A0 The text ", or both" is wrong.

c=
) The text repeats itself where it says "the=A0whitelist that is the D=
NS Whitelist".



=A0 =A0 John


--f46d0444731152bd5404b26e7a73--

From Tina.Tsou.Zouting@huawei.com  Wed Nov 23 14:49:35 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C566A11E80A0 for ; Wed, 23 Nov 2011 14:49:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.44
X-Spam-Level: 
X-Spam-Status: No, score=0.44 tagged_above=-999 required=5 tests=[AWL=0.335, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RDNS_NONE=0.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 4G7XRZLi45ZT for ; Wed, 23 Nov 2011 14:49:35 -0800 (PST)
Received: from szxga03-in.huawei.com (unknown [58.251.152.66]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB6711E808D for ; Wed, 23 Nov 2011 14:49:35 -0800 (PST)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LV4009ICY2E1M@szxga03-in.huawei.com> for v6ops@ietf.org; Thu, 24 Nov 2011 06:49:26 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LV400C0CY2E8X@szxga03-in.huawei.com> for v6ops@ietf.org; Thu, 24 Nov 2011 06:49:26 +0800 (CST)
Received: from szxeml206-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AFG88535; Thu, 24 Nov 2011 06:49:25 +0800
Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 24 Nov 2011 06:49:21 +0800
Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.40]) by szxeml412-hub.china.huawei.com ([10.82.67.91]) with mapi id 14.01.0323.003; Thu, 24 Nov 2011 06:49:15 +0800
Date: Wed, 23 Nov 2011 22:49:13 +0000
From: Tina TSOU 
In-reply-to: 
X-Originating-IP: [10.193.34.142]
To: Wes Beebee , Brian E Carpenter 
Message-id: 
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-language: en-US
Content-transfer-encoding: 7BIT
Accept-Language: en-US, zh-CN
Thread-topic: [v6ops] 6rd Sunsetting
Thread-index: AQHMo2zkiVaVmflTEk2DrH6PcFso4ZWtESmAgAF9cYCAACEjgIABVu+AgAfhuoCAADwWAIAAAlqAgABDmgCAAIAigIAAtJqAgABw8oCAAFGpAIAADg4AgAADdwCAAKk5IA==
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
References: <4ECD5752.4000504@gmail.com> 
Cc: Alexandre Cassen , "v6ops@ietf.org" , Claire Cheng 
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 23 Nov 2011 22:49:35 -0000

Wes,
Would you show some examples of command line of 6rd Sunsetting configuration on BR and CE?

-Tina

-----Original Message-----
From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Wes Beebee
Sent: Wednesday, November 23, 2011 12:40 PM
To: Brian E Carpenter
Cc: Alexandre Cassen; v6ops@ietf.org; Claire Cheng
Subject: Re: [v6ops] 6rd Sunsetting

>> Section 4.4.3 of draft-ietf-v6ops-6204bis-03:
>> 
>> "  5.  Selection of 6rd tunnel or native IPv6 output interface on the CE
>>        router is determined by the source IPv6 address of the packet
>>        from a host, when different prefixes are available over 6rd vs.
>>        native IPv6.  If the two interfaces provide the CE router with
>>        the same prefix, then the CE router prefers the native IPv6
>>        interface to the 6rd interface for forwarding traffic out the WAN
>>        when both 6rd and native IPv6 interfaces are active.
>
> I am not sure I understand how rule 5 is implemented algorithmically.
> Can you spell it out?

One possible implementation of rule 5 (e.g. On Cisco routers) would be
Policy-Based Routing (PBR) selecting by an Access Control List (ACL)
matching the source IPv6 address to the native or 6rd prefix (when
different), that would then select the output interface as the PBR action.
When the prefixes are configured to be the same, two routes would be
configured in the Forwarding Information Base (FIB) for native and 6rd and
the native route would have a lower administrative distance metric than the
6rd route.

It's possible to configure this on a Cisco router such that the behavior
described in #5 is observed.  However, for a super cheap home router, they
may not choose to actually implement all of PBR, ACL, etc - and they may
find a more direct way to implement the behavior described in #5.

- Wes 

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

From mark@townsley.net  Wed Nov 23 15:10:42 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F82F21F877F for ; Wed, 23 Nov 2011 15:10:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.435
X-Spam-Level: 
X-Spam-Status: No, score=-3.435 tagged_above=-999 required=5 tests=[AWL=0.164,  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 HOfvxbWN+rrY for ; Wed, 23 Nov 2011 15:10:42 -0800 (PST)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id DC24921F8770 for ; Wed, 23 Nov 2011 15:10:41 -0800 (PST)
Received: by wwp14 with SMTP id 14so447283wwp.13 for ; Wed, 23 Nov 2011 15:10:40 -0800 (PST)
Received: by 10.227.209.9 with SMTP id ge9mr16461979wbb.1.1322089840679; Wed, 23 Nov 2011 15:10:40 -0800 (PST)
Received: from ams-townsley-8712.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id j5sm8726527wix.20.2011.11.23.15.10.37 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 23 Nov 2011 15:10:38 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Mark Townsley 
In-Reply-To: 
Date: Thu, 24 Nov 2011 00:10:35 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <8DC6BEAC-EF4F-4C39-A9A0-98848CF0234B@townsley.net>
References: 
To: Wes Beebee 
X-Mailer: Apple Mail (2.1084)
Cc: Alexandre Cassen , v6ops@ietf.org, Claire Cheng 
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 23 Nov 2011 23:10:42 -0000

On Nov 23, 2011, at 8:37 PM, Wes Beebee wrote:

>> So, I think Gert's right here. For all practical purposes, when a 6rd =
and
>> native interface are up with different prefixes for each, the CPE has =
to
>> ensure that it sends packets over the right interface. Same is true =
for
>> multihoming in general. Only way to get around it is to keep the =
prefix the
>> same.=20
>=20
> Section 4.4.3 of draft-ietf-v6ops-6204bis-03:
>=20
> "  5.  Selection of 6rd tunnel or native IPv6 output interface on the =
CE
>       router is determined by the source IPv6 address of the packet
>       from a host, when different prefixes are available over 6rd vs.
>       native IPv6.  If the two interfaces provide the CE router with
>       the same prefix, then the CE router prefers the native IPv6
>       interface to the 6rd interface for forwarding traffic out the =
WAN
>       when both 6rd and native IPv6 interfaces are active.

This sounds about right. I think we should be more explicit about the =
"when" and "active" part in the last line though, as that's the crux of =
the issue around what to do when receiving configuration for 6rd and =
native interfaces on the same router. If the router shuts off 6rd =
prematurely (IMHO, before the ISP says its OK by no longer providing =
config), then it risks blackholing traffic from other CEs. =20

>=20
>   6.  The CE router messages to the host the use of native IPv6 in
>       preference to 6rd, in the case where the two interfaces use
>       different prefixes."

I'd be more comfortable with 6rd simply falling in line with general =
advice on multihoming with multiple prefixes. It's really the same case.=20=


Homenet Chair Nit: By specifying what should happen with routers and =
hosts on the LAN side, we're dipping a bit into homenet territory. As =
long as it's consistent with what homenet ends up with, no harm no foul, =
but I'd hate to jump the gun.=20

- Mark

>=20
> - Wes
>=20


From furry13@gmail.com  Wed Nov 23 16:10:26 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2215D21F8AF0 for ; Wed, 23 Nov 2011 16:10:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W6WYf2YXY7+j for ; Wed, 23 Nov 2011 16:10:25 -0800 (PST)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id F13F221F8AEA for ; Wed, 23 Nov 2011 16:10:24 -0800 (PST)
Received: by bkbzv15 with SMTP id zv15so2079874bkb.31 for ; Wed, 23 Nov 2011 16:09:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MKwJAxtf0v2si9+QbjQCFWNZi/u6Ar8nujn8YAojeNU=; b=NC+Sj4KXxzGXfCt5ZxV+p95j22IgyPhxriOv4I8mdnaWAdqJ/4oYUFhSujef0dT0oO j1FHc4DUC4dLR3ru2ys7A2GNtv08txuPW/cKMZSqV2At6PTn71vmhulpZH2Hesa/KTMj 0bEPmxnuST3qNz50pr3ot4WCfixZV9Zm2I/Y4=
MIME-Version: 1.0
Received: by 10.204.10.77 with SMTP id o13mr27701126bko.12.1322093392237; Wed, 23 Nov 2011 16:09:52 -0800 (PST)
Received: by 10.223.1.138 with HTTP; Wed, 23 Nov 2011 16:09:52 -0800 (PST)
In-Reply-To: 
References: 
Date: Thu, 24 Nov 2011 11:09:52 +1100
Message-ID: 
From: Jen Linkova 
To: Philip Homburg 
Content-Type: text/plain; charset=ISO-8859-1
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Routers forwarding packet with link local source
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 24 Nov 2011 00:10:26 -0000

On Wed, Nov 23, 2011 at 2:06 AM, Philip Homburg
 wrote:
> Looking at some traceroute output, I found a link local address. This is
> rather surprising given that RFC-4291 (Internet Protocol Version 6 (IPv6)
> Addressing Architecture) says:
>
> "2.5.6. Link-Local IPv6 Unicast Addresses
> [...]
> "Routers must not forward any packets with Link-Local source or
> "destination addresses to other links.
>
> The surprising thing is that the router that originates the packet is about
> 9 hops away from me.
>
> Are router vendors deliberately ignoring this requirement?

Such a coincidence, I've spent some time on the similar issue
recently. I don't know if vendors are ignoring RFC4291 (and some other
RFCs as 4007) deliberately or unintentionally, but there are a lot of
routers in Internet forwarding packets with link-local src to global
destination IPs.  I've even seen routers sending ICMPv6 type 2 (packet
too big) using link-local src IP to destination address of global
scope ;-\

>One question is whether this is a bug or a feature. The effect is that the
>error ICMP arrives. Which is good, but proper (ingress) filtering is also good.

I'd consider it as a bug indicating that RFCs aren't properly
implemented and more bugs related to address selection and scoped
architecture might exist in the code..

-- 
SY, Jen Linkova aka Furry

From brian.e.carpenter@gmail.com  Wed Nov 23 18:35:22 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08FB111E80B4 for ; Wed, 23 Nov 2011 18:35:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.544
X-Spam-Level: 
X-Spam-Status: No, score=-103.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UhDIqYhi3dsc for ; Wed, 23 Nov 2011 18:35:21 -0800 (PST)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 61D6321F8511 for ; Wed, 23 Nov 2011 18:35:21 -0800 (PST)
Received: by vcbfy13 with SMTP id fy13so2291046vcb.31 for ; Wed, 23 Nov 2011 18:35:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=fL8iBzd3iWntjSpvDkHw2c6RhXKu/eAJpCeC0E4hZqM=; b=KMKkqk7PgUjKeSQQeqCB7q9aVxalieo0f6CIJ9qstnIPL4+Ns0Pa0z4nzzMecWPrie Wt8UA452Sf/hmnUD1lx1GMqlec43YUT/QXEVu5rZqMydxsV+h78dH1C8L8Y7smXQm0Zo BVzqyvHKbvSnAOHd0MJUaximR7JUsP734YIXM=
Received: by 10.52.24.11 with SMTP id q11mr28130347vdf.83.1322102120783; Wed, 23 Nov 2011 18:35:20 -0800 (PST)
Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id f7sm26787254vdj.13.2011.11.23.18.35.16 (version=SSLv3 cipher=OTHER); Wed, 23 Nov 2011 18:35:19 -0800 (PST)
Message-ID: <4ECDAD6B.9040507@gmail.com>
Date: Thu, 24 Nov 2011 15:35:23 +1300
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Wes Beebee 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: Alexandre Cassen , v6ops@ietf.org, Claire Cheng 
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 24 Nov 2011 02:35:22 -0000

On 2011-11-24 09:40, Wes Beebee wrote:
>>> Section 4.4.3 of draft-ietf-v6ops-6204bis-03:
>>>
>>> "  5.  Selection of 6rd tunnel or native IPv6 output interface on the CE
>>>        router is determined by the source IPv6 address of the packet
>>>        from a host, when different prefixes are available over 6rd vs.
>>>        native IPv6.  If the two interfaces provide the CE router with
>>>        the same prefix, then the CE router prefers the native IPv6
>>>        interface to the 6rd interface for forwarding traffic out the WAN
>>>        when both 6rd and native IPv6 interfaces are active.
>> I am not sure I understand how rule 5 is implemented algorithmically.
>> Can you spell it out?
> 
> One possible implementation of rule 5 (e.g. On Cisco routers) would be
> Policy-Based Routing (PBR) selecting by an Access Control List (ACL)
> matching the source IPv6 address to the native or 6rd prefix (when
> different), that would then select the output interface as the PBR action.
> When the prefixes are configured to be the same, two routes would be
> configured in the Forwarding Information Base (FIB) for native and 6rd and
> the native route would have a lower administrative distance metric than the
> 6rd route.
> 
> It's possible to configure this on a Cisco router such that the behavior
> described in #5 is observed.  However, for a super cheap home router, they
> may not choose to actually implement all of PBR, ACL, etc - and they may
> find a more direct way to implement the behavior described in #5.

They'd better. We've been trying to get rules like this set up in our Uni's
border routers, so that we can run some real-world shim6 tests using alternative
paths between two prefixes on our campus (in NZ) and two prefixes on another
campus Somewhere in Europe. Getting it right even for a static test setup is
proving frustrating and quite hard to explain to the operational folk. In a
small enterprise or homenet context it *must* be automatic.

   Brian

From lorenzo@google.com  Wed Nov 23 18:37:19 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22B6121F8541 for ; Wed, 23 Nov 2011 18:37:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.907
X-Spam-Level: 
X-Spam-Status: No, score=-102.907 tagged_above=-999 required=5 tests=[AWL=0.069, 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 RfQPBJE8u9yZ for ; Wed, 23 Nov 2011 18:37:18 -0800 (PST)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8838A21F853E for ; Wed, 23 Nov 2011 18:37:18 -0800 (PST)
Received: by ywt34 with SMTP id 34so2446514ywt.31 for ; Wed, 23 Nov 2011 18:37:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=it2sMM4NziyIhf349e776J/8AyLEl5ydlHwBtinMrbY=; b=AiOa1rNKE0fPizWGOtTIOXJtdX2NWDXq7P6D9kwseW5kLu2Kh/4yD08S6pESzXvs4x LP+8LaZ/CzNuyWbCAcQA==
Received: by 10.236.183.52 with SMTP id p40mr38497110yhm.19.1322102238186; Wed, 23 Nov 2011 18:37:18 -0800 (PST)
Received: by 10.236.183.52 with SMTP id p40mr38497100yhm.19.1322102238089; Wed, 23 Nov 2011 18:37:18 -0800 (PST)
MIME-Version: 1.0
Received: by 10.150.202.14 with HTTP; Wed, 23 Nov 2011 18:36:56 -0800 (PST)
In-Reply-To: <4ECD3EDF.2020206@dougbarton.us>
References:  <4ECC139C.9080600@gmail.com> <201111231421.pANELBqP013658@cichlid.raleigh.ibm.com> <4ECD3EDF.2020206@dougbarton.us>
From: Lorenzo Colitti 
Date: Thu, 24 Nov 2011 11:36:56 +0900
Message-ID: 
To: Doug Barton 
Content-Type: multipart/alternative; boundary=bcaec52c5ea942138504b271ea58
X-System-Of-Record: true
Cc: Thomas Narten , "v6ops@ietf.org" 
Subject: Re: [v6ops] Title of draft-ietf-v6ops-v6-aaaa-whitelisting-implications-07
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 24 Nov 2011 02:37:19 -0000

--bcaec52c5ea942138504b271ea58
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Nov 24, 2011 at 03:43, Doug Barton  wrote:

> >             On Using the DNS for Transitioning Content to IPv6
>
> If you're going to drag DNS into the title, I'd prefer something that
> didn't imply that it's a protocol issue. How about, "DNS Access Control
> Lists for Transitioning Content to IPv6." You can add a "Using" to the
> beginning of that if you don't think it's too long. (Note, I
> specifically rejected s/ACL/Whitelisting/ in order to avoid the
> argument, no matter how silly I think the argument is, but I won't
> object if you want to use it instead.)
>

Please don't use the term access control list. We've been through that
argument already.

I agree with Brian that this document does not provide complete guidance to
a website operator that wants to enable IPv6. However, it deals with the
last stage in the transition to dual-stack, i.e., how to incrementally
enable access to web content that is already available over IPv6 (in the
sense that if a user knew the IPv6 address of the server and sent an HTTP
request, he would get a response). The focus on DNS is that given current
browser behaviour, the only tool for doing so is controlling which DNS
records are published.

--bcaec52c5ea942138504b271ea58
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Thu, Nov 24, 2011 at 03:43, Doug Barton <dougb@dougbarton.us=
> wrote:



> =A0 =A0 =A0 =A0 =A0 =A0 On Using the DNS for Transit=
ioning Content to IPv6




If you're going to drag DNS into the title, I'd prefer someth=
ing that

didn't imply that it's a protocol issue. How about, "DNS Acces=
s Control

Lists for Transitioning Content to IPv6." You can add a "Using&qu=
ot; to the

beginning of that if you don't think it's too long. (Note, I

specifically rejected s/ACL/Whitelisting/ in order to avoid the

argument, no matter how silly I think the argument is, but I won't

object if you want to use it instead.)

=
Please don't use the term access control list. We've been through t=
hat argument already.

I agree with Brian that this=
 document does not provide complete guidance to a website operator that wan=
ts to enable IPv6. However, it deals with the last stage in the transition =
to dual-stack, i.e., how to incrementally enable access to web content that=
 is already available over IPv6 (in the sense that if a user knew the IPv6 =
address of the server and sent an HTTP request, he would get a response). T=
he focus on DNS is that given current browser behaviour, the only tool for =
doing so is controlling which DNS records are published.





--bcaec52c5ea942138504b271ea58--

From brian.e.carpenter@gmail.com  Wed Nov 23 18:49:00 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40F611F0C38 for ; Wed, 23 Nov 2011 18:49:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.545
X-Spam-Level: 
X-Spam-Status: No, score=-103.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Ynkrcil44jc for ; Wed, 23 Nov 2011 18:48:59 -0800 (PST)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9E6521F0C35 for ; Wed, 23 Nov 2011 18:48:59 -0800 (PST)
Received: by vbbez10 with SMTP id ez10so2288024vbb.31 for ; Wed, 23 Nov 2011 18:48:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=5TYE9srZt0JzqIHtIh7M9NB6Xh++cbm1voMU/OvNyyw=; b=OK+SaLTH8VWV6xKjb6tIInmct88I8tMfIiqbEDcuisdA44E7YIUVigCFOZCQMJ9ajz +Nn1JQdXvi5Ucek8C52Zcbo5/Pl2/1rGjnjBSlCxD0UliNZGWdoCKeCU7zLNQqW4sRW+ YwkrI1FrB+DT/Z3XXzw9GoKKClVZFGtklhW2Q=
Received: by 10.52.94.18 with SMTP id cy18mr28474708vdb.24.1322102938936; Wed, 23 Nov 2011 18:48:58 -0800 (PST)
Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id z6sm26816091vdg.18.2011.11.23.18.48.55 (version=SSLv3 cipher=OTHER); Wed, 23 Nov 2011 18:48:57 -0800 (PST)
Message-ID: <4ECDB09E.2090807@gmail.com>
Date: Thu, 24 Nov 2011 15:49:02 +1300
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Jen Linkova 
References:  
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: Philip Homburg , v6ops@ietf.org
Subject: Re: [v6ops] Routers forwarding packet with link local source
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 24 Nov 2011 02:49:00 -0000

On 2011-11-24 13:09, Jen Linkova wrote:
> On Wed, Nov 23, 2011 at 2:06 AM, Philip Homburg
>  wrote:
>> Looking at some traceroute output, I found a link local address. This is
>> rather surprising given that RFC-4291 (Internet Protocol Version 6 (IPv6)
>> Addressing Architecture) says:
>>
>> "2.5.6. Link-Local IPv6 Unicast Addresses
>> [...]
>> "Routers must not forward any packets with Link-Local source or
>> "destination addresses to other links.

That refers to the source or destination address of the packet, not
to the address of the interface forwarding or receiving the packet.
What you see in the trace is surely the address of the router interface,
which can perfectly well be a link-local address on an unnumbered link
between two routers.

In a similar confusion, I have been mystified by IPv6 traceroutes
including addresses assigned to an ISP that was not on the path.
That was simply because the router handling a particular hop did have
an interface numbered from the other ISP, and chose to report that as
its own address in its traceroute replies.

This is just a consequence of multiple addresses being a standard
feature of any IPv6 node, including routers. Some of those addresses
can be link locals.

(You sometimes see RFC 1918 addresses in the middle of an IPv4 trace, and
that's roughly the same thing.)

   Brian

>>
>> The surprising thing is that the router that originates the packet is about
>> 9 hops away from me.
>>
>> Are router vendors deliberately ignoring this requirement?
> 
> Such a coincidence, I've spent some time on the similar issue
> recently. I don't know if vendors are ignoring RFC4291 (and some other
> RFCs as 4007) deliberately or unintentionally, but there are a lot of
> routers in Internet forwarding packets with link-local src to global
> destination IPs.  I've even seen routers sending ICMPv6 type 2 (packet
> too big) using link-local src IP to destination address of global
> scope ;-\
> 
>> One question is whether this is a bug or a feature. The effect is that the
>> error ICMP arrives. Which is good, but proper (ingress) filtering is also good.
> 
> I'd consider it as a bug indicating that RFCs aren't properly
> implemented and more bugs related to address selection and scoped
> architecture might exist in the code..
> 

From lorenzo@google.com  Wed Nov 23 19:07:33 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41EA621F8AE9 for ; Wed, 23 Nov 2011 19:07:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.909
X-Spam-Level: 
X-Spam-Status: No, score=-102.909 tagged_above=-999 required=5 tests=[AWL=0.067, 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 Kg-I+j7HSN2C for ; Wed, 23 Nov 2011 19:07:32 -0800 (PST)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2797321F8ADE for ; Wed, 23 Nov 2011 19:07:31 -0800 (PST)
Received: by ggnp4 with SMTP id p4so2499252ggn.31 for ; Wed, 23 Nov 2011 19:07:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=k8fXjjQ95Ypm24UnYCyIDOZQ/iXJUjC0gsILH3ACzNI=; b=tqXTpGIqc/Cjj7wK/C5WSFedSNOaEaWBaeNXGT8fpaxtiWQ4nRy4ootLUaOaNeRxm4 CxUV7hBY1MJ+5vJOckjg==
Received: by 10.236.181.138 with SMTP id l10mr38336596yhm.36.1322104051252; Wed, 23 Nov 2011 19:07:31 -0800 (PST)
Received: by 10.236.181.138 with SMTP id l10mr38336581yhm.36.1322104051134; Wed, 23 Nov 2011 19:07:31 -0800 (PST)
MIME-Version: 1.0
Received: by 10.150.202.14 with HTTP; Wed, 23 Nov 2011 19:07:10 -0800 (PST)
In-Reply-To: 
References:   <68DAB112-6E32-45FE-9AB7-A34E64898F60@cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30354436E@XMB-RCD-109.cisco.com> <750BF7861EBBE048B3E648B4BB6E8F4F20DC41F6@crexc50p>  <252D3DEA-FF09-42C8-959E-8A7205D9DE67@townsley.net>  <20111122133612.GH71280@Space.Net> 
From: Lorenzo Colitti 
Date: Thu, 24 Nov 2011 12:07:10 +0900
Message-ID: 
To: Mark Townsley 
Content-Type: multipart/alternative; boundary=20cf30434af052f1ed04b27256b2
X-System-Of-Record: true
Cc: Claire Cheng , v6ops@ietf.org, Alexandre Cassen 
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 24 Nov 2011 03:07:33 -0000

--20cf30434af052f1ed04b27256b2
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Nov 22, 2011 at 23:43, Mark Townsley  wrote:

> I'm beginning to think that in the separate prefix mode the CE is going to
> have to be able to do source routing to the two interfaces.
>

If the native network drops traffic with 6rd source addresses, and the 6rd
BR drops traffic with native source addresses, then the only way to have
things work is either to use the same prefix or to have the CE not send the
traffic the wrong way.

I do stand by my assertion that relying on the CE router to get this right
all the time is a risky bet and is unlikely to work in all cases unless the
ISP manages the CE (in which case of course they can do what they like
anyway).

--20cf30434af052f1ed04b27256b2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Tue, Nov 22, 2011 at 23:43, Mark Townsley <m=
ark@townsley.net> wrote:




I'm beginning to think that in the separate prefix mode the CE is =
going to have to be able to do source routing to the two interfaces.
<=
/blockquote>

If the native network drops traffic with 6r=
d source addresses, and the 6rd BR drops traffic with native source address=
es, then the only way to have things work is either to use the same prefix =
or to have the CE not send the traffic the wrong way.





I do stand by my assertion that relying on the CE route=
r to get this right all the time is a risky bet and is unlikely to work in =
all cases unless the ISP manages the CE (in which case of course they can d=
o what they like anyway).






--20cf30434af052f1ed04b27256b2--

From lorenzo@google.com  Wed Nov 23 19:17:27 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40F3511E80B3 for ; Wed, 23 Nov 2011 19:17:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.912
X-Spam-Level: 
X-Spam-Status: No, score=-102.912 tagged_above=-999 required=5 tests=[AWL=0.064, 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 UyR0xpwa--sc for ; Wed, 23 Nov 2011 19:17:26 -0800 (PST)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id AB1B311E8091 for ; Wed, 23 Nov 2011 19:17:26 -0800 (PST)
Received: by yenm7 with SMTP id m7so2501417yen.31 for ; Wed, 23 Nov 2011 19:17:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=j67jc+ivVzd+h4HMvope7XRmA5BlOpAV99WUzObQsv0=; b=oZLYBTcMaGUyXcMlz/n/Gqcf/1LoarEdAl+6O5G6vJzz7343Q8QSTX3NMQlERGsYYv F0jfxcthCi4NE+tMh6QA==
Received: by 10.101.180.18 with SMTP id h18mr6154490anp.51.1322104646231; Wed, 23 Nov 2011 19:17:26 -0800 (PST)
Received: by 10.101.180.18 with SMTP id h18mr6154479anp.51.1322104646112; Wed, 23 Nov 2011 19:17:26 -0800 (PST)
MIME-Version: 1.0
Received: by 10.150.202.14 with HTTP; Wed, 23 Nov 2011 19:17:05 -0800 (PST)
In-Reply-To: 
References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com>  <5B6B2B64C9FE2A489045EEEADDAFF2C30354473D@XMB-RCD-109.cisco.com> <4EC455D6.8030601@bogus.com>   <7EB596BF-B175-40BF-ABC8-326599670B04@apple.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303544B88@XMB-RCD-109.cisco.com>    <8D342733-88E6-45D3-B388-E001AE32CD77@employees.org> <750BF7861EBBE048B3E648B4BB6E8F4F20DC4FEA@crexc50p>  <007801cca8c8$5610aa00$0231fe00$@iname.com>  <00f801cca8fd$784fcdf0$68ef69d0$@iname.com> <418C43A6-5E8A-4CBD-83F4-3C5F502213A1@employees.org>  
From: Lorenzo Colitti 
Date: Thu, 24 Nov 2011 12:17:05 +0900
Message-ID: 
To: Ole Troan 
Content-Type: multipart/alternative; boundary=001636c92695c994b504b2727913
X-System-Of-Record: true
Cc: IPv6 Operations 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 24 Nov 2011 03:17:27 -0000

--001636c92695c994b504b2727913
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Nov 22, 2011 at 19:44, Ole Troan  wrote:

> > I don't think you can say that "other configuration information" means
> "other configuration information, but not a prefix".
>
> I think I've given umpteen reasons why we shouldn't couple M/O bits with
> PD already.
> the O bit means _stateless_ DHCP. PD is stateful.


If you want to make the assertion that O means "stateless DHCPv6", you'll
have to find an RFC that says so. If you don't, then O means "other
configuration information" as stated in RFC 4861.

If you want to say that a CE router should ignore the M/O bits entirely,
sure. But you can't decide to use them and then say that PD should be
controlled by the M bit, or that PD shouldn't be controlled by either bit,
because that doesn't make any sense given how the bits are defined.

--001636c92695c994b504b2727913
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Tue, Nov 22, 2011 at 19:44, Ole Troan <otroan@employees.org=
> wrote:



> I don't think you can say that "other =
configuration information" means "other configuration information=
, but not a prefix".




I think I've given umpteen reasons why we shouldn't cou=
ple M/O bits with PD already.

the O bit means _stateless_ DHCP. PD is stateful.

If you want to make the assertion that O means "stateless DHCPv=
6", you'll have to find an RFC that says so. If you don't, the=
n O means "other configuration information" as stated in RFC 4861=
.




If you want to say that a CE router should ignore the M=
/O bits entirely, sure. But you can't decide to use them and then say t=
hat PD should be controlled by the M bit, or that PD shouldn't be contr=
olled by either bit, because that doesn't make any sense given how the =
bits are defined.





--001636c92695c994b504b2727913--

From Ted.Lemon@nominum.com  Wed Nov 23 19:23:55 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6585411E80A4 for ; Wed, 23 Nov 2011 19:23:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.576
X-Spam-Level: 
X-Spam-Status: No, score=-106.576 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 TXgYNvlEZLCq for ; Wed, 23 Nov 2011 19:23:54 -0800 (PST)
Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id 761F711E8091 for ; Wed, 23 Nov 2011 19:23:54 -0800 (PST)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKTs24yYTLjbR3rJHnQj+HJgNJdMrZwy2u@postini.com; Wed, 23 Nov 2011 19:23:54 PST
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 9B9C81B8144 for ; Wed, 23 Nov 2011 19:23:52 -0800 (PST)
Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 878CD190052; Wed, 23 Nov 2011 19:23:51 -0800 (PST) (envelope-from Ted.Lemon@nominum.com)
Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.01.0339.001; Wed, 23 Nov 2011 19:23:51 -0800
From: Ted Lemon 
To: Lorenzo Colitti 
Thread-Topic: [v6ops] DHCPv6 option for MAX_SOL_RT
Thread-Index: AQHMpBVS9v5OyU3dDEaf8biIUoZIIJWwMYMAgACJcgCAAANuAP//e/aAgAD3r4CAAQPRAIAAGkmAgAAkTwCAAEPzAIAAvrKAgAABC4CAAAnSAIAABdOAgAVG1oCAAFm1gIAAEJAAgAABEACAAAd2AIAABASAgAKnm4CAAAHjAA==
Date: Thu, 24 Nov 2011 03:23:51 +0000
Message-ID: <49D07B35-997E-4F99-B7B0-F3A9BBAF00B0@nominum.com>
References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com>  <5B6B2B64C9FE2A489045EEEADDAFF2C30354473D@XMB-RCD-109.cisco.com> <4EC455D6.8030601@bogus.com>   <7EB596BF-B175-40BF-ABC8-326599670B04@apple.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303544B88@XMB-RCD-109.cisco.com>    <8D342733-88E6-45D3-B388-E001AE32CD77@employees.org> <750BF7861EBBE048B3E648B4BB6E8F4F20DC4FEA@crexc50p>  <007801cca8c8$5610aa00$0231fe00$@iname.com>  <00f801cca8fd$784fcdf0$68ef69d0$@iname.com> <418C43A6-5E8A-4CBD-83F4-3C5F502213A1@employees.org>   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.1.10]
Content-Type: multipart/alternative; boundary="_000_49D07B35997E4F99B7B0F3A9BBAF00B0nominumcom_"
MIME-Version: 1.0
Cc: IPv6 Operations 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 24 Nov 2011 03:23:55 -0000

--_000_49D07B35997E4F99B7B0F3A9BBAF00B0nominumcom_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

On Nov 23, 2011, at 10:17 PM, Lorenzo Colitti wrote:
If you want to make the assertion that O means "stateless DHCPv6", you'll h=
ave to find an RFC that says so. If you don't, then O means "other configur=
ation information" as stated in RFC 4861.

Strictly speaking, the M bit means "stateful."   The O bit doesn't mean "st=
ateless," although it's only interesting when the M bit isn't set (and, hen=
ce, address configuration is stateless).



--_000_49D07B35997E4F99B7B0F3A9BBAF00B0nominumcom_
Content-Type: text/html; charset="iso-8859-1"
Content-ID: 
Content-Transfer-Encoding: quoted-printable









On Nov 23, 2011, at 10:17 PM, Lorenzo Colitti wrote:




If you want to make the assertion that O means "stateless DHCPv6&=
quot;, you'll have to find an RFC that says so. If you don't, then O means =
"other configuration information" as stated in RFC 4861.








Strictly speaking, the M bit means "stateful."   The O =
bit doesn't mean "stateless," although it's only interesting when=
 the M bit isn't set (and, hence, address configuration is stateless).










--_000_49D07B35997E4F99B7B0F3A9BBAF00B0nominumcom_--

From lorenzo@google.com  Wed Nov 23 19:32:42 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 506EF11E8091 for ; Wed, 23 Nov 2011 19:32:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.914
X-Spam-Level: 
X-Spam-Status: No, score=-102.914 tagged_above=-999 required=5 tests=[AWL=0.062, 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 uN2vwT3tPopM for ; Wed, 23 Nov 2011 19:32:41 -0800 (PST)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id C4DAE11E808D for ; Wed, 23 Nov 2011 19:32:41 -0800 (PST)
Received: by ggnp4 with SMTP id p4so2519672ggn.31 for ; Wed, 23 Nov 2011 19:32:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=MOMHL5Mgu0nnCUj+Oofpw5hE5ezy9oxJzgquNp9xvsQ=; b=YM4sNQuw90z1x37z4hVwB+PncKOYeQzAaRshl38Z4sNd3grCyek9RgP7a0xixsfntf JWlu9NsVFRmmdOEZ4m9g==
Received: by 10.100.30.34 with SMTP id d34mr94162and.7.1322105561268; Wed, 23 Nov 2011 19:32:41 -0800 (PST)
Received: by 10.100.30.34 with SMTP id d34mr94156and.7.1322105561146; Wed, 23 Nov 2011 19:32:41 -0800 (PST)
MIME-Version: 1.0
Received: by 10.150.202.14 with HTTP; Wed, 23 Nov 2011 19:32:19 -0800 (PST)
In-Reply-To: 
References: <20111122190508.3293.41916.idtracker@ietfa.amsl.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EED43@XMB-RCD-109.cisco.com> 
From: Lorenzo Colitti 
Date: Thu, 24 Nov 2011 12:32:19 +0900
Message-ID: 
To: jouni korhonen 
Content-Type: multipart/alternative; boundary=001485f85d6053e54004b272b0ab
X-System-Of-Record: true
Cc: v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Nov 2011 03:32:42 -0000

--001485f85d6053e54004b272b0ab
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Nov 23, 2011 at 06:27, jouni korhonen wrote:

> Also, WPD-1 alone would not be enough (cf draft-ietf-dhc-pd-exclude).


Why do you need dhc-pd-exclude at all?

1. You give the phone a prefix delegation for a prefix (say, a /56).
2. You give the phone a RA that says that one particular /64 of that /56 is
in on the WAN link and is to be used for SLAAC.

The phone already has all the information it needs. Why do you need to tell
it twice that the /64 is special?

--001485f85d6053e54004b272b0ab
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Wed, Nov 23, 2011 at 06:27, jouni korhonen <jouni.nospam@=
gmail.com> wrote:


Also, WPD-1 alone would not be enough (cf draft-ietf-dhc-pd-exclude).

Why do you need dhc-pd-exclude at all?

1. You give the phone a prefix delegation for a prefix (say=
, a /56).



2. You give the phone a RA that says that one particular /64 of that /=
56 is in on the WAN link and is to be used for SLAAC.

<=
div>The phone already has all the information it needs. Why do you need to =
tell it twice that the /64 is special?





--001485f85d6053e54004b272b0ab--

From lorenzo@google.com  Wed Nov 23 19:33:49 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2017411E80B3 for ; Wed, 23 Nov 2011 19:33:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.916
X-Spam-Level: 
X-Spam-Status: No, score=-102.916 tagged_above=-999 required=5 tests=[AWL=0.060, 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 s4C2cPC-c0hk for ; Wed, 23 Nov 2011 19:33:48 -0800 (PST)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9968111E808D for ; Wed, 23 Nov 2011 19:33:48 -0800 (PST)
Received: by ywt34 with SMTP id 34so2492421ywt.31 for ; Wed, 23 Nov 2011 19:33:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=12UWRMGgW8CjvNr+yuEAOz44gjBqk1ivrsLMq3I0Kd8=; b=A+Aahl8hvR0rdTPy2nqH18xlpSlsqQczbxYk40VJIH8PHavA/LKRCUwHbeiifbvcjq 0TonxDbqA+G9tZgM9X5w==
Received: by 10.101.4.20 with SMTP id g20mr6194689ani.73.1322105622256; Wed, 23 Nov 2011 19:33:42 -0800 (PST)
Received: by 10.101.4.20 with SMTP id g20mr6194683ani.73.1322105622110; Wed, 23 Nov 2011 19:33:42 -0800 (PST)
MIME-Version: 1.0
Received: by 10.150.202.14 with HTTP; Wed, 23 Nov 2011 19:33:22 -0800 (PST)
In-Reply-To: <49D07B35-997E-4F99-B7B0-F3A9BBAF00B0@nominum.com>
References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com>  <5B6B2B64C9FE2A489045EEEADDAFF2C30354473D@XMB-RCD-109.cisco.com> <4EC455D6.8030601@bogus.com>   <7EB596BF-B175-40BF-ABC8-326599670B04@apple.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303544B88@XMB-RCD-109.cisco.com>    <8D342733-88E6-45D3-B388-E001AE32CD77@employees.org> <750BF7861EBBE048B3E648B4BB6E8F4F20DC4FEA@crexc50p>  <007801cca8c8$5610aa00$0231fe00$@iname.com>  <00f801cca8fd$784fcdf0$68ef69d0$@iname.com> <418C43A6-5E8A-4CBD-83F4-3C5F502213A1@employees.org>    <49D07B35-997E-4F99-B7B0-F3A9BBAF00B0@nominum.com>
From: Lorenzo Colitti 
Date: Thu, 24 Nov 2011 12:33:22 +0900
Message-ID: 
To: Ted Lemon 
Content-Type: multipart/alternative; boundary=001636c92af4f622b304b272b389
X-System-Of-Record: true
Cc: IPv6 Operations 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 24 Nov 2011 03:33:49 -0000

--001636c92af4f622b304b272b389
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Nov 24, 2011 at 12:23, Ted Lemon  wrote:

>   If you want to make the assertion that O means "stateless DHCPv6",
> you'll have to find an RFC that says so. If you don't, then O means "other
> configuration information" as stated in RFC 4861.
>
>
>  Strictly speaking, the M bit means "stateful."   The O bit doesn't mean
> "stateless," although it's only interesting when the M bit isn't set (and,
> hence, address configuration is stateless).
>

Where is the text that says that M indicates stateful DHCPv6? I only see
text that says that M indicates managed address configuration.

--001636c92af4f622b304b272b389
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Thu, Nov 24, 2011 at 12:23, Ted Lemon <Ted.Lemon@nominum.c=
om> wrote:











=



If you want to make the assertion that O means "stateless DHCPv6"=
, you'll have to find an RFC that says so. If you don't, then O mea=
ns "other configuration information" as stated in RFC 4861.










Strictly speaking, the M bit means "stateful." =A0 The=
 O bit doesn't mean "stateless," although it's only inter=
esting when the M bit isn't set (and, hence, address configuration is s=
tateless).




Where is the text that says that M i=
ndicates stateful DHCPv6? I only see text that says that M indicates manage=
d address configuration.


--001636c92af4f622b304b272b389--

From Ted.Lemon@nominum.com  Wed Nov 23 19:39:34 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6154F11E808D for ; Wed, 23 Nov 2011 19:39:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.576
X-Spam-Level: 
X-Spam-Status: No, score=-106.576 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 OSsThXCtZoMF for ; Wed, 23 Nov 2011 19:39:33 -0800 (PST)
Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 8FEFB11E808C for ; Wed, 23 Nov 2011 19:39:33 -0800 (PST)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKTs28dSP09PZS2dx56adhv365VeEwqhmn@postini.com; Wed, 23 Nov 2011 19:39:33 PST
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id AAB3B1B813F for ; Wed, 23 Nov 2011 19:39:32 -0800 (PST)
Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 983B5190052; Wed, 23 Nov 2011 19:39:32 -0800 (PST) (envelope-from Ted.Lemon@nominum.com)
Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.01.0339.001; Wed, 23 Nov 2011 19:39:32 -0800
From: Ted Lemon 
To: Lorenzo Colitti 
Thread-Topic: [v6ops] DHCPv6 option for MAX_SOL_RT
Thread-Index: AQHMpBVS9v5OyU3dDEaf8biIUoZIIJWwMYMAgACJcgCAAANuAP//e/aAgAD3r4CAAQPRAIAAGkmAgAAkTwCAAEPzAIAAvrKAgAABC4CAAAnSAIAABdOAgAVG1oCAAFm1gIAAEJAAgAABEACAAAd2AIAABASAgAKnm4CAAAHjAIAAAqoAgAABuIA=
Date: Thu, 24 Nov 2011 03:39:32 +0000
Message-ID: 
References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com>  <5B6B2B64C9FE2A489045EEEADDAFF2C30354473D@XMB-RCD-109.cisco.com> <4EC455D6.8030601@bogus.com>   <7EB596BF-B175-40BF-ABC8-326599670B04@apple.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303544B88@XMB-RCD-109.cisco.com>    <8D342733-88E6-45D3-B388-E001AE32CD77@employees.org> <750BF7861EBBE048B3E648B4BB6E8F4F20DC4FEA@crexc50p>  <007801cca8c8$5610aa00$0231fe00$@iname.com>  <00f801cca8fd$784fcdf0$68ef69d0$@iname.com> <418C43A6-5E8A-4CBD-83F4-3C5F502213A1@employees.org>    <49D07B35-997E-4F99-B7B0-F3A9BBAF00B0@nominum.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.1.10]
Content-Type: multipart/alternative; boundary="_000_BC19861156EA4B8E8DE60E6FC5B862C0nominumcom_"
MIME-Version: 1.0
Cc: IPv6 Operations 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 24 Nov 2011 03:39:34 -0000

--_000_BC19861156EA4B8E8DE60E6FC5B862C0nominumcom_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

On Nov 23, 2011, at 10:33 PM, Lorenzo Colitti wrote:
Where is the text that says that M indicates stateful DHCPv6? I only see te=
xt that says that M indicates managed address configuration.

Yes.   Managed means stateful, unless you can give me an example of a state=
less management process.   :)


--_000_BC19861156EA4B8E8DE60E6FC5B862C0nominumcom_
Content-Type: text/html; charset="iso-8859-1"
Content-ID: 
Content-Transfer-Encoding: quoted-printable









On Nov 23, 2011, at 10:33 PM, Lorenzo Colitti wrote:


Where
 is the text that says that M indicates stateful DHCPv6? I only see text th=
at says that M indicates managed address configuration.






Yes.   Managed means stateful, unless you can give me an example =
of a stateless management process.   :)









--_000_BC19861156EA4B8E8DE60E6FC5B862C0nominumcom_--

From lorenzo@google.com  Wed Nov 23 19:47:28 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44FD211E808D for ; Wed, 23 Nov 2011 19:47:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.918
X-Spam-Level: 
X-Spam-Status: No, score=-102.918 tagged_above=-999 required=5 tests=[AWL=0.058, 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 mOQf5LtCDNin for ; Wed, 23 Nov 2011 19:47:27 -0800 (PST)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id A9BFE11E808C for ; Wed, 23 Nov 2011 19:47:27 -0800 (PST)
Received: by ggnp4 with SMTP id p4so2531684ggn.31 for ; Wed, 23 Nov 2011 19:47:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=JXmp2Wc+ywMklCMsk9BluTc9xZ52vDdf8tYdrYGeIsQ=; b=E92wSBP9SvtvR4ImU3NFrc3qr5NP+kY1x3VGdLPqbrrU+I/ZekhVMxQ17eKFTG5cVJ 18+la/oh7BWGYEJkrmcQ==
Received: by 10.236.183.52 with SMTP id p40mr38698849yhm.19.1322106447320; Wed, 23 Nov 2011 19:47:27 -0800 (PST)
Received: by 10.236.183.52 with SMTP id p40mr38698833yhm.19.1322106447118; Wed, 23 Nov 2011 19:47:27 -0800 (PST)
MIME-Version: 1.0
Received: by 10.150.202.14 with HTTP; Wed, 23 Nov 2011 19:47:06 -0800 (PST)
In-Reply-To: 
References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com>  <5B6B2B64C9FE2A489045EEEADDAFF2C30354473D@XMB-RCD-109.cisco.com> <4EC455D6.8030601@bogus.com>   <7EB596BF-B175-40BF-ABC8-326599670B04@apple.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303544B88@XMB-RCD-109.cisco.com>    <8D342733-88E6-45D3-B388-E001AE32CD77@employees.org> <750BF7861EBBE048B3E648B4BB6E8F4F20DC4FEA@crexc50p>  <007801cca8c8$5610aa00$0231fe00$@iname.com>  <00f801cca8fd$784fcdf0$68ef69d0$@iname.com> <418C43A6-5E8A-4CBD-83F4-3C5F502213A1@employees.org>    <49D07B35-997E-4F99-B7B0-F3A9BBAF00B0@nominum.com>  
From: Lorenzo Colitti 
Date: Thu, 24 Nov 2011 12:47:06 +0900
Message-ID: 
To: Ted Lemon 
Content-Type: multipart/alternative; boundary=bcaec52c5ea922c29004b272e533
X-System-Of-Record: true
Cc: IPv6 Operations 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 24 Nov 2011 03:47:28 -0000

--bcaec52c5ea922c29004b272e533
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Nov 24, 2011 at 12:39, Ted Lemon  wrote:

>  Where is the text that says that M indicates stateful DHCPv6? I only see
> text that says that M indicates managed address configuration.
>
> Yes.   Managed means stateful,
>

What you're saying is not "managed means stateful", it's "managed implies
stateful". Other configuration information could also be stateful, right?


> unless you can give me an example of a stateless management process.   :)
>

An example is a deterministic management process, where, if given MAC
address asks for an IP address, it gets the same IP address until the end
of time (or until the network is decommissioned).

--bcaec52c5ea922c29004b272e533
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Thu, Nov 24, 2011 at 12:39, Ted Lemon <Ted.Lemon@nominum.c=
om> wrote:











=
Where
 is the text that says that M indicates stateful DHCPv6? I only see text th=
at says that M indicates managed address configuration.
=



Yes. =A0 Managed means stateful,
What you're saying is not "managed means stateful&quo=
t;, it's "managed implies stateful". Other configuration info=
rmation could also be stateful, right?



=A0
 unless you can give me an example of a stateless management pr=
ocess. =A0 :)




An example is a deterministic manage=
ment process, where, if given MAC address asks for an IP address, it gets t=
he same IP address until the end of time (or until the network is decommiss=
ioned).





--bcaec52c5ea922c29004b272e533--

From Ted.Lemon@nominum.com  Wed Nov 23 19:57:37 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E377311E808C for ; Wed, 23 Nov 2011 19:57:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.576
X-Spam-Level: 
X-Spam-Status: No, score=-106.576 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 JLHe2pfUSO+f for ; Wed, 23 Nov 2011 19:57:37 -0800 (PST)
Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id 26F9B11E8085 for ; Wed, 23 Nov 2011 19:57:37 -0800 (PST)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKTs3AsFC59oWZVNA9uyRpRq4Q8lqPjUSI@postini.com; Wed, 23 Nov 2011 19:57:37 PST
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id AADB81B8144 for ; Wed, 23 Nov 2011 19:57:35 -0800 (PST)
Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 797B1190052; Wed, 23 Nov 2011 19:57:34 -0800 (PST) (envelope-from Ted.Lemon@nominum.com)
Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.01.0339.001; Wed, 23 Nov 2011 19:57:34 -0800
From: Ted Lemon 
To: Lorenzo Colitti 
Thread-Topic: [v6ops] DHCPv6 option for MAX_SOL_RT
Thread-Index: AQHMpBVS9v5OyU3dDEaf8biIUoZIIJWwMYMAgACJcgCAAANuAP//e/aAgAD3r4CAAQPRAIAAGkmAgAAkTwCAAEPzAIAAvrKAgAABC4CAAAnSAIAABdOAgAVG1oCAAFm1gIAAEJAAgAABEACAAAd2AIAABASAgAKnm4CAAAHjAIAAAqoAgAABuICAAAIeAIAAAugA
Date: Thu, 24 Nov 2011 03:57:33 +0000
Message-ID: 
References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com>  <5B6B2B64C9FE2A489045EEEADDAFF2C30354473D@XMB-RCD-109.cisco.com> <4EC455D6.8030601@bogus.com>   <7EB596BF-B175-40BF-ABC8-326599670B04@apple.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303544B88@XMB-RCD-109.cisco.com>    <8D342733-88E6-45D3-B388-E001AE32CD77@employees.org> <750BF7861EBBE048B3E648B4BB6E8F4F20DC4FEA@crexc50p>  <007801cca8c8$5610aa00$0231fe00$@iname.com>  <00f801cca8fd$784fcdf0$68ef69d0$@iname.com> <418C43A6-5E8A-4CBD-83F4-3C5F502213A1@employees.org>    <49D07B35-997E-4F99-B7B0-F3A9BBAF00B0@nominum.com>   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.1.10]
Content-Type: multipart/alternative; boundary="_000_F5C8EE79D5F74130AE529D6B296080EFnominumcom_"
MIME-Version: 1.0
Cc: IPv6 Operations 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 24 Nov 2011 03:57:38 -0000

--_000_F5C8EE79D5F74130AE529D6B296080EFnominumcom_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

On Nov 23, 2011, at 10:47 PM, Lorenzo Colitti wrote:
An example is a deterministic management process, where, if given MAC addre=
ss asks for an IP address, it gets the same IP address until the end of tim=
e (or until the network is decommissioned).

I think you are splitting hairs.   That would be identical to SLAAC, only w=
ithout DAD, so it's not only useless, but harmful.   In practice, managed i=
s stateful.


--_000_F5C8EE79D5F74130AE529D6B296080EFnominumcom_
Content-Type: text/html; charset="iso-8859-1"
Content-ID: <646EFCCC4AEBAE408442B645B9D42DA7@nominum.com>
Content-Transfer-Encoding: quoted-printable









On Nov 23, 2011, at 10:47 PM, Lorenzo Colitti wrote:


An
 example is a deterministic management process, where, if given MAC address=
 asks for an IP address, it gets the same IP address until the end of time =
(or until the network is decommissioned).






I think you are splitting hairs.   That would be identical to SLA=
AC, only without DAD, so it's not only useless, but harmful.   In prac=
tice, managed is stateful.









--_000_F5C8EE79D5F74130AE529D6B296080EFnominumcom_--

From Ted.Lemon@nominum.com  Wed Nov 23 20:04:20 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B420F1F0C3C for ; Wed, 23 Nov 2011 20:04:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.576
X-Spam-Level: 
X-Spam-Status: No, score=-106.576 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 rBtjbDfHU3n4 for ; Wed, 23 Nov 2011 20:04:20 -0800 (PST)
Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id EF5A71F0C3B for ; Wed, 23 Nov 2011 20:04:19 -0800 (PST)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKTs3CQ6p9QFCH15cnH5jNw8LOglXW3EzN@postini.com; Wed, 23 Nov 2011 20:04:20 PST
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 2452C1B813F for ; Wed, 23 Nov 2011 20:04:19 -0800 (PST)
Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 12B47190052; Wed, 23 Nov 2011 20:04:19 -0800 (PST) (envelope-from Ted.Lemon@nominum.com)
Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.01.0339.001; Wed, 23 Nov 2011 20:04:19 -0800
From: Ted Lemon 
To: Lorenzo Colitti 
Thread-Topic: [v6ops] DHCPv6 option for MAX_SOL_RT
Thread-Index: AQHMpBVS9v5OyU3dDEaf8biIUoZIIJWwMYMAgACJcgCAAANuAP//e/aAgAD3r4CAAQPRAIAAGkmAgAAkTwCAAEPzAIAAvrKAgAABC4CAAAnSAIAABdOAgAVG1oCAAFm1gIAAEJAAgAABEACAAAd2AIAABASAgAKnm4CAAAHjAIAAAqoAgAABuICAAAIeAIAAAugAgAAB5YA=
Date: Thu, 24 Nov 2011 04:04:18 +0000
Message-ID: 
References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com>  <5B6B2B64C9FE2A489045EEEADDAFF2C30354473D@XMB-RCD-109.cisco.com> <4EC455D6.8030601@bogus.com>   <7EB596BF-B175-40BF-ABC8-326599670B04@apple.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303544B88@XMB-RCD-109.cisco.com>    <8D342733-88E6-45D3-B388-E001AE32CD77@employees.org> <750BF7861EBBE048B3E648B4BB6E8F4F20DC4FEA@crexc50p>  <007801cca8c8$5610aa00$0231fe00$@iname.com>  <00f801cca8fd$784fcdf0$68ef69d0$@iname.com> <418C43A6-5E8A-4CBD-83F4-3C5F502213A1@employees.org>    <49D07B35-997E-4F99-B7B0-F3A9BBAF00B0@nominum.com>    
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.1.10]
Content-Type: multipart/alternative; boundary="_000_F1D562F36C0244EDB855CB7368CF7574nominumcom_"
MIME-Version: 1.0
Cc: IPv6 Operations 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 24 Nov 2011 04:04:20 -0000

--_000_F1D562F36C0244EDB855CB7368CF7574nominumcom_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

On Nov 23, 2011, at 10:57 PM, Ted Lemon wrote:
I think you are splitting hairs.   That would be identical to SLAAC, only w=
ithout DAD, so it's not only useless, but harmful.   In practice, managed i=
s stateful.

Also, if you agree that the M bit means 'managed,' then you pretty much hav=
e to agree that it's what signals PD, because PD is quite clearly managed, =
whether you believe it's stateful or not.



--_000_F1D562F36C0244EDB855CB7368CF7574nominumcom_
Content-Type: text/html; charset="iso-8859-1"
Content-ID: 
Content-Transfer-Encoding: quoted-printable









On Nov 23, 2011, at 10:57 PM, Ted Lemon wrote:




I think you are splitting hairs.   That would be identical to SLA=
AC, only without DAD, so it's not only useless, but harmful.   In prac=
tice, managed is stateful.








Also, if you agree that the M bit means 'managed,' then you pretty muc=
h have to agree that it's what signals PD, because PD is quite clearly mana=
ged, whether you believe it's stateful or not.











--_000_F1D562F36C0244EDB855CB7368CF7574nominumcom_--

From jouni.nospam@gmail.com  Wed Nov 23 21:37:12 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EDFE11E80B3 for ; Wed, 23 Nov 2011 21:37:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mv4CXfyQzZrZ for ; Wed, 23 Nov 2011 21:37:11 -0800 (PST)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 698F711E8088 for ; Wed, 23 Nov 2011 21:37:11 -0800 (PST)
Received: by faaq16 with SMTP id q16so699838faa.31 for ; Wed, 23 Nov 2011 21:37:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=mQbQaPTX4LzJ+IEWBn2afxPeTcQkzqQLLgjVA3XuG74=; b=HQXGDFJUIXs1VdQvpr2gjvoL5QC4rZbhV2Inte30ueBlAmry3QVLTTTzh1jGTvWQjd 1uxXoLplyPIukwBJ5vUFQEBeVOyLT/R6Otpe1xzroxuAjbZcgm54lsFwJ47AYL5A/MVS Hy+rsbJIbrtivBLCqs5PwZEJZe9aCYgLy6WCs=
Received: by 10.152.109.48 with SMTP id hp16mr16405804lab.38.1322113029277; Wed, 23 Nov 2011 21:37:09 -0800 (PST)
Received: from [62.237.209.67] ([62.237.209.67]) by mx.google.com with ESMTPS id iy5sm28583lab.16.2011.11.23.21.37.05 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 23 Nov 2011 21:37:08 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: jouni korhonen 
In-Reply-To: 
Date: Thu, 24 Nov 2011 07:37:02 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
To: Wes Beebee 
X-Mailer: Apple Mail (2.1084)
Cc: v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Nov 2011 05:37:12 -0000

Wes,

I understand your (both or you) points. But we also need to keep in mind =
that when RFC6204 came out 3GPP community was adding (or had just added) =
PD into their specs. There was not much point arguing any cellular CE =
requirement before that (except maybe something tethering related).

- Jouni



On Nov 23, 2011, at 4:11 PM, Wes Beebee wrote:

>> Just based on the little I know, I would guess at least
>> a year's worth of arguing over functionality...
>=20
> I tend to agree with Barbara.  In the early days of what became RFC =
6204, we
> had some interest from the 3GPP community.  However, we never got the =
levels
> of engagement necessary to make sure that we satisfied all of their
> requirements.  It's not clear that satisfying half of the requirements =
is
> actually useful to anyone and may cause unnecessary confusion to those
> already engaged.
>=20
> - Wes
>=20


From lorenzo@google.com  Wed Nov 23 21:46:37 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5239421F84BD for ; Wed, 23 Nov 2011 21:46:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.92
X-Spam-Level: 
X-Spam-Status: No, score=-102.92 tagged_above=-999 required=5 tests=[AWL=0.056, 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 8PT+Q-xNPjbQ for ; Wed, 23 Nov 2011 21:46:36 -0800 (PST)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id A8F7E21F84BC for ; Wed, 23 Nov 2011 21:46:36 -0800 (PST)
Received: by yenm7 with SMTP id m7so2619287yen.31 for ; Wed, 23 Nov 2011 21:46:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=Hs80MLK7F4iALuChDC0jdKWHcuThheFYoj6+MrEbNac=; b=PQLLcY3HRtmO/gZQ4hwAcZ+uyxljT80wmtzRc/XbW1uLFSxVEjgct+EnK3dTsXovM3 i1Gksp7KPgyco2He5fgA==
Received: by 10.236.75.167 with SMTP id z27mr39556752yhd.53.1322113596200; Wed, 23 Nov 2011 21:46:36 -0800 (PST)
Received: by 10.236.75.167 with SMTP id z27mr39556742yhd.53.1322113596104; Wed, 23 Nov 2011 21:46:36 -0800 (PST)
MIME-Version: 1.0
Received: by 10.150.202.14 with HTTP; Wed, 23 Nov 2011 21:46:15 -0800 (PST)
In-Reply-To: 
References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com>  <5B6B2B64C9FE2A489045EEEADDAFF2C30354473D@XMB-RCD-109.cisco.com> <4EC455D6.8030601@bogus.com>   <7EB596BF-B175-40BF-ABC8-326599670B04@apple.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303544B88@XMB-RCD-109.cisco.com>    <8D342733-88E6-45D3-B388-E001AE32CD77@employees.org> <750BF7861EBBE048B3E648B4BB6E8F4F20DC4FEA@crexc50p>  <007801cca8c8$5610aa00$0231fe00$@iname.com>  <00f801cca8fd$784fcdf0$68ef69d0$@iname.com> <418C43A6-5E8A-4CBD-83F4-3C5F502213A1@employees.org>    <49D07B35-997E-4F99-B7B0-F3A9BBAF00B0@nominum.com>     
From: Lorenzo Colitti 
Date: Thu, 24 Nov 2011 14:46:15 +0900
Message-ID: 
To: Ted Lemon 
Content-Type: multipart/alternative; boundary=20cf3005dde63f9fd404b2748fb8
X-System-Of-Record: true
Cc: IPv6 Operations 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 24 Nov 2011 05:46:37 -0000

--20cf3005dde63f9fd404b2748fb8
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Nov 24, 2011 at 13:04, Ted Lemon  wrote:

>  On Nov 23, 2011, at 10:57 PM, Ted Lemon wrote:
>
> I think you are splitting hairs.   That would be identical to SLAAC, only
> without DAD, so it's not only useless, but harmful.   In practice, managed
> is stateful.
>
>  Also, if you agree that the M bit means 'managed,' then you pretty much
> have to agree that it's what signals PD, because PD is quite clearly
> managed, whether you believe it's stateful or not.
>

The point I'm trying to make is that it doesn't matter what I believe, it
matters what the RFC says. The RFC says "managed address configuration". So
if it's not managed, and it doesn't involve addresses, it's not covered by
the M bit.

The fact that PD is managed doesn't mean it has to be covered by the M bit.
Everything given via DHCPv6 is managed - that's what DHCPv6 is for.

--20cf3005dde63f9fd404b2748fb8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Thu, Nov 24, 2011 at 13:04, Ted Lemon <Ted.Lemon@nominum.c=
om> wrote:











On Nov 23, 2011, at 10:57 PM, Ted Lemon wrote:




I think you are splitting hairs. =A0 That would be identical to SLAAC,=
 only without DAD, so it's not only useless, but harmful. =A0 In practi=
ce, managed is stateful.




Also, if you agree that the M bit means 'managed,' then =
you pretty much have to agree that it's what signals PD, because PD is =
quite clearly managed, whether you believe it's stateful or not.




The point I'm trying to make is =
that it doesn't matter what I believe, it matters what the RFC says. Th=
e RFC says "managed address configuration". So if it's not ma=
naged, and it doesn't involve addresses, it's not covered by the M =
bit.




The fact that PD is managed doesn't mean it ha=
s to be covered by the M bit. Everything given via DHCPv6 is managed - that=
's what DHCPv6 is for.


--20cf3005dde63f9fd404b2748fb8--

From jouni.nospam@gmail.com  Wed Nov 23 21:47:06 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83D2221F84CC for ; Wed, 23 Nov 2011 21:47:06 -0800 (PST)
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 HcFGiKEoG2vf for ; Wed, 23 Nov 2011 21:47:05 -0800 (PST)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3B01821F84C1 for ; Wed, 23 Nov 2011 21:47:05 -0800 (PST)
Received: by faaq16 with SMTP id q16so705640faa.31 for ; Wed, 23 Nov 2011 21:47:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=3wZK9SvC3SmW+odbb1CCwVJ8dy6htMl9Knsk47x+Rio=; b=eIZruvYPwUinqzyqD+vGTmHB1AK+KQ5S6WlzbSMQHjU47OQkBYCHxi2XC0GW2ggkA3 W6R/P1R2QA50CdXrwGowKQFCax7zmtr+36rlYjmkZFzjAlQXzeL17Ms+R2N4IcnGFYtL DBJnTpHdM/iyARgPTEHSJTyXy4OEnhi5eYO3c=
Received: by 10.152.104.206 with SMTP id gg14mr16571831lab.41.1322113624186; Wed, 23 Nov 2011 21:47:04 -0800 (PST)
Received: from [62.237.209.67] ([62.237.209.67]) by mx.google.com with ESMTPS id hr17sm18154337lab.12.2011.11.23.21.47.01 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 23 Nov 2011 21:47:02 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: jouni korhonen 
In-Reply-To: <0C6A4A8DD60DBF4A99C300DDA771BFAB01E81EF9599D@server3.MUTUALTEL.MTCNET.NET>
Date: Thu, 24 Nov 2011 07:46:58 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <750BF7861EBBE048B3E648B4BB6E8F4F20EA14A5@crexc50p>  <5B6B2B64C9FE2A489045EEEADDAFF2C3035EEF7C@XMB-RCD-109.cisco.com> <0C6A4A8DD60DBF4A99C300DDA771BFAB01E81EF9599D@server3.MUTUALTEL.MTCNET.NET>
To: Frank Bulk 
X-Mailer: Apple Mail (2.1084)
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Nov 2011 05:47:06 -0000

Directly conflicts.. none really. Small nits like MUST for IA_NA on WAN, =
because that is not needed/supported. On PD side, there are supposedly =
no issues that are not already covered by 6204bis if the cellular =
subscription is given a static prefix (on the WAN side). Otherwise, when =
the WAN link goes down, your delegated prefixes are also "gone". A =
reference to pd-exclude would be a nice addition since that is part of =
3GPP defined PD.

- Jouni


On Nov 24, 2011, at 7:36 AM, Frank Bulk wrote:

> What about traditional SOHO routers that support an LTE USB dongle as =
a backup WAN link?
>=20
> While rfc6204bis may not have everything the 3GPP need, is there =
anything that directly conflicts?
>=20
> Frank
>=20
> -----Original Message-----
> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf =
Of Hemant Singh (shemant)
> Sent: Wednesday, November 23, 2011 9:41 AM
> To: Wes Beebee (wbeebee); STARK, BARBARA H; jouni korhonen
> Cc: v6ops@ietf.org
> Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
>=20
> Ok, we can leave comprehensive support for cellular out of rfc6204bis.
>=20
> Hemant
>=20
> -----Original Message-----
> From: Wes Beebee (wbeebee)=20
> Sent: Wednesday, November 23, 2011 9:12 AM
> To: STARK, BARBARA H; jouni korhonen; Hemant Singh (shemant)
> Cc: v6ops@ietf.org
> Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
>=20
>> Just based on the little I know, I would guess at least
>> a year's worth of arguing over functionality...
>=20
> I tend to agree with Barbara.  In the early days of what became RFC
> 6204, we
> had some interest from the 3GPP community.  However, we never got the
> levels
> of engagement necessary to make sure that we satisfied all of their
> requirements.  It's not clear that satisfying half of the requirements
> is
> actually useful to anyone and may cause unnecessary confusion to those
> already engaged.
>=20
> - Wes
>=20
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>=20


From mark@townsley.net  Wed Nov 23 23:43:09 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7038421F8508 for ; Wed, 23 Nov 2011 23:43:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.436
X-Spam-Level: 
X-Spam-Status: No, score=-3.436 tagged_above=-999 required=5 tests=[AWL=0.162,  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 JHFl9jkRq-pk for ; Wed, 23 Nov 2011 23:43:09 -0800 (PST)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9756321F84DA for ; Wed, 23 Nov 2011 23:43:07 -0800 (PST)
Received: by bkbzv15 with SMTP id zv15so2520128bkb.31 for ; Wed, 23 Nov 2011 23:43:07 -0800 (PST)
Received: by 10.204.133.197 with SMTP id g5mr26804524bkt.43.1322120586809; Wed, 23 Nov 2011 23:43:06 -0800 (PST)
Received: from ams-townsley-8712.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id e18sm15014222bkr.15.2011.11.23.23.43.04 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 23 Nov 2011 23:43:05 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-20-215999767
From: Mark Townsley 
In-Reply-To: 
Date: Thu, 24 Nov 2011 08:43:03 +0100
Message-Id: 
References:   <68DAB112-6E32-45FE-9AB7-A34E64898F60@cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30354436E@XMB-RCD-109.cisco.com> <750BF7861EBBE048B3E648B4BB6E8F4F20DC41F6@crexc50p>  <252D3DEA-FF09-42C8-959E-8A7205D9DE67@townsley.net>  <20111122133612.GH71280@Space.Net>  
To: Lorenzo Colitti 
X-Mailer: Apple Mail (2.1084)
Cc: Claire Cheng , v6ops@ietf.org, Alexandre Cassen 
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 24 Nov 2011 07:43:09 -0000

--Apple-Mail-20-215999767
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On Nov 24, 2011, at 4:07 AM, Lorenzo Colitti wrote:

> On Tue, Nov 22, 2011 at 23:43, Mark Townsley  =
wrote:
> I'm beginning to think that in the separate prefix mode the CE is =
going to have to be able to do source routing to the two interfaces.
>=20
> If the native network drops traffic with 6rd source addresses, and the =
6rd BR drops traffic with native source addresses, then the only way to =
have things work is either to use the same prefix or to have the CE not =
send the traffic the wrong way.

Right. And this is one of the reasons, after thinking it through, the =
single prefix option had some attractive characteristics. It lets you =
avoid source routing and RPF issues, as well as not renumbering the user =
and gives you optimal paths in terms of BR traversal to boot. =20

>=20
> I do stand by my assertion that relying on the CE router to get this =
right all the time is a risky bet and is unlikely to work in all cases =
unless the ISP manages the CE (in which case of course they can do what =
they like anyway).

A statement that really should apply to the generic multihoming case as =
well as the 6rd one.=20

- Mark



--Apple-Mail-20-215999767
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii


On Nov 24, 2011, at 4:07 AM, Lorenzo Colitti wrote:

On Tue, Nov 22, 2011 at 23:43, Mark Townsley <mark@townsley.net> wrote:




I'm beginning to think that in the separate prefix mode the CE is going to have to be able to do source routing to the two interfaces.

If the native network drops traffic with 6rd source addresses, and the 6rd BR drops traffic with native source addresses, then the only way to have things work is either to use the same prefix or to have the CE not send the traffic the wrong way.

Right. And this is one of the reasons, after thinking it through, the single prefix option had some attractive characteristics. It lets you avoid source routing and RPF issues, as well as not renumbering the user and gives you optimal paths in terms of BR traversal to boot.  






I do stand by my assertion that relying on the CE router to get this right all the time is a risky bet and is unlikely to work in all cases unless the ISP manages the CE (in which case of course they can do what they like anyway).







A statement that really should apply to the generic multihoming case as well as the 6rd one. 

- Mark



--Apple-Mail-20-215999767--

From pch-b29AA871B@u-1.phicoh.com  Wed Nov 23 23:52:09 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8190321F8AF4 for ; Wed, 23 Nov 2011 23:52:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.455
X-Spam-Level: 
X-Spam-Status: No, score=-8.455 tagged_above=-999 required=5 tests=[AWL=0.144,  BAYES_00=-2.599, GB_I_LETTER=-2, 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 16ajSam2GXhp for ; Wed, 23 Nov 2011 23:52:09 -0800 (PST)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id AC11021F8AF2 for ; Wed, 23 Nov 2011 23:52:08 -0800 (PST)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #76) id m1RTU6I-0001ieC; Thu, 24 Nov 2011 08:52:06 +0100
Message-Id: 
To: Brian E Carpenter 
From: Philip Homburg 
Sender: pch-b29AA871B@u-1.phicoh.com
References:   <4ECDB09E.2090807@gmail.com> 
In-reply-to: Your message of "Thu, 24 Nov 2011 15:49:02 +1300 ." <4ECDB09E.2090807@gmail.com> 
Date: Thu, 24 Nov 2011 08:52:04 +0100
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Routers forwarding packet with link local source
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 24 Nov 2011 07:52:09 -0000

In your letter dated Thu, 24 Nov 2011 15:49:02 +1300 you wrote:
>On 2011-11-24 13:09, Jen Linkova wrote:
>> On Wed, Nov 23, 2011 at 2:06 AM, Philip Homburg
>>  wrote:
>>> Looking at some traceroute output, I found a link local address. This is
>>> rather surprising given that RFC-4291 (Internet Protocol Version 6 (IPv6)
>>> Addressing Architecture) says:
>>>
>>> "2.5.6. Link-Local IPv6 Unicast Addresses
>>> [...]
>>> "Routers must not forward any packets with Link-Local source or
>>> "destination addresses to other links.
>
>That refers to the source or destination address of the packet, not
>to the address of the interface forwarding or receiving the packet.
>What you see in the trace is surely the address of the router interface,
>which can perfectly well be a link-local address on an unnumbered link
>between two routers.
>
>In a similar confusion, I have been mystified by IPv6 traceroutes
>including addresses assigned to an ISP that was not on the path.
>That was simply because the router handling a particular hop did have
>an interface numbered from the other ISP, and chose to report that as
>its own address in its traceroute replies.

I'm not complaining about the router that originated the packet. That can
happen, no problem.

But for that packet to arrive at my laptop, it must have been forwarded by
quite a few routers. And each of those routers forwarded a packet with
link-local source, in direct violation of what it specified in RFC-4291.



From ichiroumakino@gmail.com  Thu Nov 24 00:12:07 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ED2F21F8422 for ; Thu, 24 Nov 2011 00:12:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.554
X-Spam-Level: 
X-Spam-Status: No, score=-3.554 tagged_above=-999 required=5 tests=[AWL=0.045,  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 v4HbW3TKQEIB for ; Thu, 24 Nov 2011 00:12:06 -0800 (PST)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 43F231F0C72 for ; Thu, 24 Nov 2011 00:12:06 -0800 (PST)
Received: by bkbzv15 with SMTP id zv15so2551358bkb.31 for ; Thu, 24 Nov 2011 00:12:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=awjH5wCy5ZipZMIWRPXxcSH0d5drmw3B1kwT7RWobqk=; b=RL6QOGcg6doXTxKyiLPfdh2i9DN9myHc/skkzwiXTPljwCgkHt3WuUcehvX/qe69NE L1LkFqfi0jfO0J6A9tZtb94xZZZRVOVXS19SneuABl0PDAoBpbQyGr9YqbL648NjwGyX bmiLvfAc9FU192PD3l9J+FXysriVPfohe8Pow=
Received: by 10.205.133.4 with SMTP id hw4mr27375626bkc.91.1322122325275; Thu, 24 Nov 2011 00:12:05 -0800 (PST)
Received: from [10.147.12.193] (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id f14sm15123907bkv.3.2011.11.24.00.12.01 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 24 Nov 2011 00:12:02 -0800 (PST)
Sender: Ole Troan 
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Ole Troan 
In-Reply-To: 
Date: Thu, 24 Nov 2011 09:12:00 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <126C5680-43B3-41E7-B534-11F273E3F0B9@employees.org>
References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com>  <5B6B2B64C9FE2A489045EEEADDAFF2C30354473D@XMB-RCD-109.cisco.com> <4EC455D6.8030601@bogus.com>   <7EB596BF-B175-40BF-ABC8-326599670B04@apple.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303544B88@XMB-RCD-109.cisco.com>    <8D342733-88E6-45D3-B388-E001AE32CD77@employees.org> <750BF7861EBBE048B3E648B4BB6E8F4F20DC4FEA@crexc50p>  <007801cca8c8$5610aa00$0231fe00$@iname.com>  <00f801cca8fd$784fcdf0$68ef69d0$@iname.com> <418C43A6-5E8A-4CBD-83F4-3C5F502213A1@employees.org>    <49D07B35-997E-4F99-B7B0-F3A9BBAF00B0@nominum.com>   
To: Lorenzo Colitti 
X-Mailer: Apple Mail (2.1084)
Cc: IPv6 Operations 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 24 Nov 2011 08:12:07 -0000

Lorenzo,

>> Where is the text that says that M indicates stateful DHCPv6? I only =
see text that says that M indicates managed address configuration.
> Yes.   Managed means stateful,
>=20
> What you're saying is not "managed means stateful", it's "managed =
implies stateful". Other configuration information could also be =
stateful, right?
> =20
> unless you can give me an example of a stateless management process.   =
:)
>=20
> An example is a deterministic management process, where, if given MAC =
address asks for an IP address, it gets the same IP address until the =
end of time (or until the network is decommissioned).

rat-hole alert. can we get back to the problem we're trying to solve?

cheers,
Ole


From ichiroumakino@gmail.com  Thu Nov 24 00:17:46 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 870A711E8093 for ; Thu, 24 Nov 2011 00:17:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.555
X-Spam-Level: 
X-Spam-Status: No, score=-3.555 tagged_above=-999 required=5 tests=[AWL=0.044,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E-KnjBiy8ETk for ; Thu, 24 Nov 2011 00:17:46 -0800 (PST)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id BD0C311E808E for ; Thu, 24 Nov 2011 00:17:45 -0800 (PST)
Received: by faaq16 with SMTP id q16so843602faa.31 for ; Thu, 24 Nov 2011 00:17:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=e7e+NXGvlNF0cfqtKo/llOwM+3xEqvP6S3CPyTknftM=; b=AdPPGrbf4jgw+R371GiISMNAhlq6jH//oNCWIuTmI30dd/hzlNgB8aC79xx0+6UcvZ wse+qyZVdPvVyIkh9/2vtbEfIO4qWiKOck5t9mKs1aQh81D2LgwkandOtSwxpoVMn2S4 nmz+Ei3kVMFqULv0goBL+OdgN2Pnwsmp9Y4ks=
Received: by 10.205.141.73 with SMTP id jd9mr28513772bkc.21.1322122664788; Thu, 24 Nov 2011 00:17:44 -0800 (PST)
Received: from [10.147.12.193] (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id x14sm15116464bkf.10.2011.11.24.00.17.42 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 24 Nov 2011 00:17:43 -0800 (PST)
Sender: Ole Troan 
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Ole Troan 
In-Reply-To: 
Date: Thu, 24 Nov 2011 09:17:41 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  
To: jouni korhonen 
X-Mailer: Apple Mail (2.1084)
Cc: v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Nov 2011 08:17:46 -0000

Jouni,

> I understand your (both or you) points. But we also need to keep in =
mind that when RFC6204 came out 3GPP community was adding (or had just =
added) PD into their specs. There was not much point arguing any =
cellular CE requirement before that (except maybe something tethering =
related).

given the exclude option, what else you do need?

cheers,
Ole=

From gert@space.net  Thu Nov 24 01:07:16 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF53121F8BA2 for ; Thu, 24 Nov 2011 01:07:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KmW7ZMwTBM4N for ; Thu, 24 Nov 2011 01:07:16 -0800 (PST)
Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 23C8521F8B9F for ; Thu, 24 Nov 2011 01:07:15 -0800 (PST)
Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id C4C30F896E for ; Thu, 24 Nov 2011 10:07:12 +0100 (CET)
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 876D8F8975 for ; Thu, 24 Nov 2011 10:07:12 +0100 (CET)
Received: (qmail 58859 invoked by uid 1007); 24 Nov 2011 10:07:12 +0100
Date: Thu, 24 Nov 2011 10:07:12 +0100
From: Gert Doering 
To: Brian E Carpenter 
Message-ID: <20111124090712.GT71280@Space.Net>
References: <68DAB112-6E32-45FE-9AB7-A34E64898F60@cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30354436E@XMB-RCD-109.cisco.com> <750BF7861EBBE048B3E648B4BB6E8F4F20DC41F6@crexc50p>  <252D3DEA-FF09-42C8-959E-8A7205D9DE67@townsley.net>  <20111122133612.GH71280@Space.Net> <4ECC10C9.5010607@gmail.com> <20111123080113.GI71280@Space.Net> <4ECD562C.2020501@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+cniFuKpb42BVlrP"
Content-Disposition: inline
In-Reply-To: <4ECD562C.2020501@gmail.com>
X-NCC-RegID: de.space
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Alexandre Cassen , Claire Cheng , v6ops@ietf.org
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 24 Nov 2011 09:07:17 -0000

--+cniFuKpb42BVlrP
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,

On Thu, Nov 24, 2011 at 09:23:08AM +1300, Brian E Carpenter wrote:
> >> While we do need a solution for source-prefix based exit
> >> selection, we don't have one yet and it's a separable problem.
> >=20
> > I strongly disagree.  This is the core of the problem for multi-PA-based
> > multihoming, and one variant presents itself now with "two different
> > access technologies with different prefixes to the same ISP".
>=20
> Actually we agree - it is a core problem here, for 6renum, and for
> ipv6-multihoming-without-ipv6nat. Probably for MIF and HOMENET too.
> That's all I meant by saying it's separable: we need to solve the
> general case.

With that explanation, yes, I can agree - it's a more general problem,
which, when solved, will catch this particular case as well.

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

--+cniFuKpb42BVlrP
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (FreeBSD)

iQCVAwUBTs4JQKkuBuNlUUl1AQIzYAP/fBRyMUIjiqkMUdNA4AEZuUeAjT9qlBGm
M4IO37h8+AmF//DniwSVV+50FLLAZjwoFMj84TEhOcq/4QJlLdyJqJZqOEOXF/ZX
y7eRqG5M8V19TvFF/B9DpR0opyblAeR85nNBNvrSingj7JAarfFs1CK/nUOsL+Tk
Jwiifn4sVbo=
=NBIY
-----END PGP SIGNATURE-----

--+cniFuKpb42BVlrP--

From mark@townsley.net  Thu Nov 24 01:11:00 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD5321F87D9 for ; Thu, 24 Nov 2011 01:11:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.143
X-Spam-Level: 
X-Spam-Status: No, score=-3.143 tagged_above=-999 required=5 tests=[AWL=-0.144, 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 qxBfqnh6JDxB for ; Thu, 24 Nov 2011 01:10:59 -0800 (PST)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id C64AD21F87D3 for ; Thu, 24 Nov 2011 01:10:59 -0800 (PST)
Received: by ggnp4 with SMTP id p4so2805450ggn.31 for ; Thu, 24 Nov 2011 01:10:59 -0800 (PST)
Received: by 10.152.109.199 with SMTP id hu7mr17028075lab.16.1322125858206; Thu, 24 Nov 2011 01:10:58 -0800 (PST)
Received: from ams-townsley-8712.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id pi7sm18659730lab.5.2011.11.24.01.10.55 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 24 Nov 2011 01:10:56 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Mark Townsley 
In-Reply-To: <20111124090712.GT71280@Space.Net>
Date: Thu, 24 Nov 2011 10:10:53 +0100
Content-Transfer-Encoding: 7bit
Message-Id: 
References: <68DAB112-6E32-45FE-9AB7-A34E64898F60@cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30354436E@XMB-RCD-109.cisco.com> <750BF7861EBBE048B3E648B4BB6E8F4F20DC41F6@crexc50p>  <252D3DEA-FF09-42C8-959E-8A7205D9DE67@townsley.net>  <20111122133612.GH71280@Space.Net> <4ECC10C9.5010607@gmail.com> <20111123080113.GI71280@Space.Net> <4ECD562C.2020501@gmail.com> <20111124090712.GT71280@Space.Net>
To: Gert Doering 
X-Mailer: Apple Mail (2.1084)
Cc: Alexandre Cassen , v6ops@ietf.org, Claire Cheng 
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 24 Nov 2011 09:11:00 -0000

On Nov 24, 2011, at 10:07 AM, Gert Doering wrote:

> Hi,
> 
> On Thu, Nov 24, 2011 at 09:23:08AM +1300, Brian E Carpenter wrote:
>>>> While we do need a solution for source-prefix based exit
>>>> selection, we don't have one yet and it's a separable problem.
>>> 
>>> I strongly disagree.  This is the core of the problem for multi-PA-based
>>> multihoming, and one variant presents itself now with "two different
>>> access technologies with different prefixes to the same ISP".
>> 
>> Actually we agree - it is a core problem here, for 6renum, and for
>> ipv6-multihoming-without-ipv6nat. Probably for MIF and HOMENET too.
>> That's all I meant by saying it's separable: we need to solve the
>> general case.
> 
> With that explanation, yes, I can agree - it's a more general problem,
> which, when solved, will catch this particular case as well.

+1

- Mark

> 
> 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
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


From gert@space.net  Thu Nov 24 04:55:48 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB9121F8B34 for ; Thu, 24 Nov 2011 04:55:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 RkQxNPNI7jVX for ; Thu, 24 Nov 2011 04:55:48 -0800 (PST)
Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id CD75C21F877F for ; Thu, 24 Nov 2011 04:55:46 -0800 (PST)
Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 9B078F8949 for ; Thu, 24 Nov 2011 13:55:45 +0100 (CET)
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 80B28F8942 for ; Thu, 24 Nov 2011 13:55:45 +0100 (CET)
Received: (qmail 27702 invoked by uid 1007); 24 Nov 2011 13:55:45 +0100
Date: Thu, 24 Nov 2011 13:55:45 +0100
From: Gert Doering 
To: Philip Homburg 
Message-ID: <20111124125545.GW71280@Space.Net>
References:   <4ECDB09E.2090807@gmail.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-NCC-RegID: de.space
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Routers forwarding packet with link local source
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 24 Nov 2011 12:55:48 -0000

Hi,

On Thu, Nov 24, 2011 at 08:52:04AM +0100, Philip Homburg wrote:
> I'm not complaining about the router that originated the packet. That can
> happen, no problem.

I tend to disagree.  Unless the router has no single global IPv6 address,
it should never send out packets to a global scoped IPv6 address sourced
from a link-local address.

... while I'm not sure that there is an RFC that explicitely says that
this is a MUST NOT, it should be self-explanatory, given that other routers
are expected to drop these packets in-transit...

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 pch-b29AA871B@u-1.phicoh.com  Thu Nov 24 05:01:37 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6A221F8BA6 for ; Thu, 24 Nov 2011 05:01:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.464
X-Spam-Level: 
X-Spam-Status: No, score=-8.464 tagged_above=-999 required=5 tests=[AWL=0.135,  BAYES_00=-2.599, GB_I_LETTER=-2, 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 zfu-PUWa+N3C for ; Thu, 24 Nov 2011 05:01:36 -0800 (PST)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 7E12321F8BA0 for ; Thu, 24 Nov 2011 05:01:36 -0800 (PST)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #76) id m1RTYvm-0001iVC; Thu, 24 Nov 2011 14:01:34 +0100
Message-Id: 
To: Gert Doering 
From: Philip Homburg 
Sender: pch-b29AA871B@u-1.phicoh.com
References:   <4ECDB09E.2090807@gmail.com>  <20111124125545.GW71280@Space.Net> 
In-reply-to: Your message of "Thu, 24 Nov 2011 13:55:45 +0100 ." <20111124125545.GW71280@Space.Net> 
Date: Thu, 24 Nov 2011 14:01:33 +0100
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Routers forwarding packet with link local source
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 24 Nov 2011 13:01:37 -0000

In your letter dated Thu, 24 Nov 2011 13:55:45 +0100 you wrote:
>On Thu, Nov 24, 2011 at 08:52:04AM +0100, Philip Homburg wrote:
>> I'm not complaining about the router that originated the packet. That can
>> happen, no problem.
>
>I tend to disagree.  Unless the router has no single global IPv6 address,
>it should never send out packets to a global scoped IPv6 address sourced
>from a link-local address.
>
>... while I'm not sure that there is an RFC that explicitely says that
>this is a MUST NOT, it should be self-explanatory, given that other routers
>are expected to drop these packets in-transit...

True. But I cannot complain about that, unless I know for certain that the
router actually has a global IPv6 address. Worse is that the router sent me
a truncated error ICMP. The link-local address has the MAC address included,
so I know which brand to avoid :-(



From joelja@bogus.com  Thu Nov 24 12:34:59 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5619E11E8086 for ; Thu, 24 Nov 2011 12:34:59 -0800 (PST)
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 bUxurUizGAGR for ; Thu, 24 Nov 2011 12:34:59 -0800 (PST)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id E57C111E8081 for ; Thu, 24 Nov 2011 12:34:58 -0800 (PST)
Received: from Zorch.local (c-76-115-174-157.hsd1.wa.comcast.net [76.115.174.157]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id pAOKYq48051406 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 24 Nov 2011 20:34:52 GMT (envelope-from joelja@bogus.com)
Message-ID: <4ECEAA67.30002@bogus.com>
Date: Thu, 24 Nov 2011 12:34:47 -0800
From: Joel jaeggli 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Lorenzo Colitti 
References:  <4ECC139C.9080600@gmail.com> <201111231421.pANELBqP013658@cichlid.raleigh.ibm.com> <4ECD3EDF.2020206@dougbarton.us> 
In-Reply-To: 
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]); Thu, 24 Nov 2011 20:34:54 +0000 (UTC)
Cc: Thomas Narten , "v6ops@ietf.org" 
Subject: Re: [v6ops] Title of draft-ietf-v6ops-v6-aaaa-whitelisting-implications-07
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 24 Nov 2011 20:34:59 -0000

On 11/23/11 18:36 , Lorenzo Colitti wrote:
> On Thu, Nov 24, 2011 at 03:43, Doug Barton  > wrote:
> 
>     >             On Using the DNS for Transitioning Content to IPv6
> 
>     If you're going to drag DNS into the title, I'd prefer something that
>     didn't imply that it's a protocol issue. How about, "DNS Access Control
>     Lists for Transitioning Content to IPv6." You can add a "Using" to the
>     beginning of that if you don't think it's too long. (Note, I
>     specifically rejected s/ACL/Whitelisting/ in order to avoid the
>     argument, no matter how silly I think the argument is, but I won't
>     object if you want to use it instead.)
> 
> 
> Please don't use the term access control list. We've been through that
> argument already.

Agree, the selective or differential publication of resource records is
not an ACL, the term whitelisting is not inapropiate because the
prefixes contained in the whitelist are being approved for the reciept
of a(n) additional resource record.

> I agree with Brian that this document does not provide complete guidance
> to a website operator that wants to enable IPv6. However, it deals with
> the last stage in the transition to dual-stack, i.e., how to
> incrementally enable access to web content that is already available
> over IPv6 (in the sense that if a user knew the IPv6 address of the
> server and sent an HTTP request, he would get a response). The focus on
> DNS is that given current browser behaviour, the only tool for doing so
> is controlling which DNS records are published.
> 
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


From shemant@cisco.com  Thu Nov 24 13:02:25 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF8511E8090 for ; Thu, 24 Nov 2011 13:02:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.284
X-Spam-Level: 
X-Spam-Status: No, score=-6.284 tagged_above=-999 required=5 tests=[AWL=0.314,  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 CeTNL3jDVoO2 for ; Thu, 24 Nov 2011 13:02:23 -0800 (PST)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1F411E8073 for ; Thu, 24 Nov 2011 13:02:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=8132; q=dns/txt; s=iport; t=1322168543; x=1323378143; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=lU/Wb24/HZy2qBt6dUuatQOrLyJ21jlBpu6WT+wrJVE=; b=fZWxYbRKcT2O6JbrlKaNjMg32SYVWmrE9kzfkmVRQwcD0nqCbQbdHUkk 2eJ1N6DZNdCHzlzo+0vy9uzDePGep+3ZgN6/XNgp++epjVAoGZ0Im5R3n L7kE3ChhmkseqgsFwyHoOwsgdgN3DxlyfKTbL2bUN0xFP2kptup9i2Znl g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AoIAAEqwzk6tJV2Y/2dsb2JhbABDgk2YAJAmgQWBcgEBAQQSAQkRA0kQAgEIEQQBAQsGFwEGAUUJCAEBBAESCBqeCQGeJIl/YwSIIZ5T
X-IronPort-AV: E=Sophos;i="4.69,567,1315180800"; d="scan'208,217";a="38799512"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP; 24 Nov 2011 21:02:21 +0000
Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pAOL2Lnn004877;  Thu, 24 Nov 2011 21:02:21 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 24 Nov 2011 15:02:20 -0600
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCAAEC.5B2A3B89"
Date: Thu, 24 Nov 2011 15:02:19 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF226@XMB-RCD-109.cisco.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] 6rd Sunsetting
Thread-Index: AcyqVjxgRdqBxYcaRQeHEllQJvU86AAOYPeg
References: <68DAB112-6E32-45FE-9AB7-A34E64898F60@cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C30354436E@XMB-RCD-109.cisco.com><750BF7861EBBE048B3E648B4BB6E8F4F20DC41F6@crexc50p><252D3DEA-FF09-42C8-959E-8A7205D9DE67@townsley.net><20111122133612.GH71280@Space.Net> 
From: "Hemant Singh (shemant)" 
To: "Lorenzo Colitti" , "Mark Townsley" 
X-OriginalArrivalTime: 24 Nov 2011 21:02:20.0911 (UTC) FILETIME=[5B62D7F0:01CCAAEC]
Cc: Claire Cheng , v6ops@ietf.org, Alexandre Cassen 
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 24 Nov 2011 21:02:25 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CCAAEC.5B2A3B89
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

=20

From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
Of Lorenzo Colitti
Sent: Wednesday, November 23, 2011 10:07 PM
To: Mark Townsley
Cc: Claire Cheng; v6ops@ietf.org; Alexandre Cassen
Subject: Re: [v6ops] 6rd Sunsetting

=20

=20

>If the native network drops traffic with 6rd source addresses,

=20

Which network segment are we talking about?  In the network between the
CE router and the 6rd BR, the BR controls the phasing out of 6rd and
hence the BR is likely not to drop 6rd sourced traffic.   If the network
segment is north of the BR why would the network drop an IPv6 packet of
the 6rd prefix?  If the CE router is directly communicating to another
CE router,  we have 6rd traffic that the receiving CE router does not
drop.  Anyhow, don't drop without sending an ICMPv6 Destination
Unreachable error message to the source. =20

=20

>and the 6rd BR drops traffic with native source addresses,

=20

It is the BR who indicated to the CE router via an RA that native IPv6
is available and say, the CE router acquired a new prefix (different
from the 6rd prefix).  So why would the BR drop native IPv6 sourced
traffic if the rfc6204bis, rule 5 in section 4.4.3 is applied?

=20

>I do stand by my assertion that relying on the CE router to get this
right all the time is a risky bet and is unlikely to work in all cases
unless the ISP manages the CE (in which >case of course they can do what
they like anyway).

=20

MarkT has already said, "manual 6rd configuration is out of scope of the
6rd and 6rd sunsetting specification.

=20

Hemant


------_=_NextPart_001_01CCAAEC.5B2A3B89
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


 
From:=
 =
v6ops-bounces@ietf.org [mailto:v6ops-bounces@iet=
f.org] On Behalf Of Lorenzo Colitti
Sent: =
Wednesday, November 23, 2011 10:07 PM
To: Mark =
Townsley
Cc: Claire Cheng; v6ops@ietf.org; Alexandre =
Cassen
Subject: Re: [v6ops] 6rd =
Sunsetting
 
 
>If the native =
network drops traffic with 6rd source addresses,
 
Which network segment are we talking about?  In the network =
between the CE router and the 6rd BR, the BR controls the phasing out of =
6rd and hence the BR is likely not to drop 6rd sourced =
traffic.   If the network segment is north of the BR why would =
the network drop an IPv6 packet of the 6rd prefix?  If the CE =
router is directly communicating to another CE router,  we have 6rd =
traffic that the receiving CE router does not drop.  Anyhow, =
don’t drop without sending an ICMPv6 Destination Unreachable error =
message to the source.  
 
>and the 6rd BR drops traffic with =
native source addresses,
 
It is the BR who indicated to the CE router via an RA that native =
IPv6 is available and say, the CE router acquired a new prefix =
(different from the 6rd prefix).  So why would the BR drop native =
IPv6 sourced traffic if the rfc6204bis, rule 5 in section 4.4.3 is =
applied?
 
>I do stand by =
my assertion that relying on the CE router to get this right all the =
time is a risky bet and is unlikely to work in all cases unless the ISP =
manages the CE (in which >case =
of course they can do what they like anyway).
 
MarkT has already said, “manual 6rd configuration is out of =
scope of the 6rd and 6rd sunsetting =
specification.
 
Hemant

------_=_NextPart_001_01CCAAEC.5B2A3B89--

From hermin.anggawijaya@gmail.com  Thu Nov 24 13:55:19 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D6661F0C45 for ; Thu, 24 Nov 2011 13:55:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.999
X-Spam-Level: 
X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[AWL=1.000,  BAYES_00=-2.599, GB_I_LETTER=-2, 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 RqyMQDcSrDrg for ; Thu, 24 Nov 2011 13:55:18 -0800 (PST)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id A94181F0C3D for ; Thu, 24 Nov 2011 13:55:18 -0800 (PST)
Received: by vcbfy13 with SMTP id fy13so3074576vcb.31 for ; Thu, 24 Nov 2011 13:55:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=XV21d6iHWiE28O5jdyw8PI1Bz3jSv13Ovf0OxSGevXI=; b=X4nfjx9RDOiDeeeOCigP3AiTdkun4xez8XeD4dM/jrEEQqog64TX3XMFWYTFJ1xkNX GOL+803I18CDcYn5/z5cZctuWNuGP1k18YM2uIfFe8x+/2TEBsDCc8KKZIHyRxjLK7cI hVO2cbowWOBWflzVnPOHtHTMEJWJcDW0JfRac=
MIME-Version: 1.0
Received: by 10.220.151.10 with SMTP id a10mr1960573vcw.141.1322171717900; Thu, 24 Nov 2011 13:55:17 -0800 (PST)
Received: by 10.220.185.137 with HTTP; Thu, 24 Nov 2011 13:55:17 -0800 (PST)
In-Reply-To: 
References:   <4ECDB09E.2090807@gmail.com>  <20111124125545.GW71280@Space.Net> 
Date: Fri, 25 Nov 2011 10:55:17 +1300
Message-ID: 
From: Hermin Anggawijaya 
To: Philip Homburg 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Routers forwarding packet with link local source
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 24 Nov 2011 21:55:19 -0000

On Fri, Nov 25, 2011 at 2:01 AM, Philip Homburg
 wrote:
> In your letter dated Thu, 24 Nov 2011 13:55:45 +0100 you wrote:
>>On Thu, Nov 24, 2011 at 08:52:04AM +0100, Philip Homburg wrote:
>>> I'm not complaining about the router that originated the packet. That c=
an
>>> happen, no problem.
>>
>>I tend to disagree. =A0Unless the router has no single global IPv6 addres=
s,
>>it should never send out packets to a global scoped IPv6 address sourced
>>from a link-local address.
>>
>>... while I'm not sure that there is an RFC that explicitely says that
>>this is a MUST NOT, it should be self-explanatory, given that other route=
rs
>>are expected to drop these packets in-transit...
>
> True. But I cannot complain about that, unless I know for certain that th=
e
> router actually has a global IPv6 address. Worse is that the router sent =
me
> a truncated error ICMP. The link-local address has the MAC address includ=
ed,
> so I know which brand to avoid :-(
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>

If the trace is done using the hop limit exceeded method (I presume it
is), the ICMPv6 'Hop limit exceeded in transit'
message (Type 3/Code 0) should be generated with source IP address
following RFC4443 Sec 2.2.b, which says

---
If the message is a response to a message sent to any other address, such a=
s....
       - a unicast address that does not belong to the node
the Source Address of the ICMPv6 packet MUST be a unicast address
belonging to the node.  The address SHOULD be chosen according to
the rules that would be used to select the source address for any
other packet originated by the node, given the destination address of the p=
acket
---

Thus, IMHO, the source address should not be link local address -
unless the trace originate
one hop away, with the destination address of the link-local address
of the target node (ie. the tracer
and the target are on the same link).

This would presumably mean that with router implementation which
supports the rule RFC-4291 sec 2.5.6,
on the near path, any ICMP hop limit exceeded message sent from
routers further along the path with link local addresses
will be dropped and not be seen by the trace originator.

On unnumbered link, the router sending the ICMPv6 packet would need to
select other
interfaces address which makes sense for the destination address (ie.
the source address of the trace packet).
I am not sure what implementations (should) do if there are no
numbered links on the router in question.....

So maybe the path that Philip has on the trace include routers with
unumbered links only, and just so happens that
nearer routers happily pass the ICMP replies along.

From brian.e.carpenter@gmail.com  Thu Nov 24 14:11:40 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37CAC21F8AA9 for ; Thu, 24 Nov 2011 14:11:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.498
X-Spam-Level: 
X-Spam-Status: No, score=-103.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJN1SzPAq-y4 for ; Thu, 24 Nov 2011 14:11:39 -0800 (PST)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id BA6FD21F8AA8 for ; Thu, 24 Nov 2011 14:11:39 -0800 (PST)
Received: by yenl8 with SMTP id l8so468879yen.31 for ; Thu, 24 Nov 2011 14:11:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=1bSOE9HnDLU1rMCWKc7Ws3knV8F3aZMyXSf6fabY1HM=; b=t7HIccC00p883bb1aezMS+2NSZpxtXn5O2cgL/1arj5k9Q02OL4yu4n01zK1voLlSw UgoGUnDA6str2hxmlVrLqGnBuYrlTEVo2nGo9rZxyI7u17zX2kbt0uPRw5odw0D84c0C zYH7NaOB20QfVFar9/VQg6tSwu/kBFR0uVb/U=
Received: by 10.182.139.34 with SMTP id qv2mr9775789obb.46.1322172699184; Thu, 24 Nov 2011 14:11:39 -0800 (PST)
Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id y4sm5780563obj.10.2011.11.24.14.11.36 (version=SSLv3 cipher=OTHER); Thu, 24 Nov 2011 14:11:38 -0800 (PST)
Message-ID: <4ECEC112.6050106@gmail.com>
Date: Fri, 25 Nov 2011 11:11:30 +1300
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Hermin Anggawijaya 
References: 		<4ECDB09E.2090807@gmail.com> 	<20111124125545.GW71280@Space.Net>	 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: Philip Homburg , v6ops@ietf.org
Subject: Re: [v6ops] Routers forwarding packet with link local source
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 24 Nov 2011 22:11:40 -0000

On 2011-11-25 10:55, Hermin Anggawijaya wrote:
...
> So maybe the path that Philip has on the trace include routers with
> unumbered links only, and just so happens that
> nearer routers happily pass the ICMP replies along.

Exactly. And just maybe, that is preferable to never receiving
the ICMPv6 reply at all. This seems to be a genuine hole in
our specs.

   Brian

From Ted.Lemon@nominum.com  Thu Nov 24 15:39:05 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB2FF11E809C for ; Thu, 24 Nov 2011 15:39:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.577
X-Spam-Level: 
X-Spam-Status: No, score=-106.577 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 zkhh7OOG-xUT for ; Thu, 24 Nov 2011 15:39:05 -0800 (PST)
Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id C820411E8099 for ; Thu, 24 Nov 2011 15:39:04 -0800 (PST)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKTs7Vl895NGZuXpjBZGl59WX3JNyzd88w@postini.com; Thu, 24 Nov 2011 15:39:04 PST
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id E424D1B8237 for ; Thu, 24 Nov 2011 15:39:02 -0800 (PST)
Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id EBD6E190052; Thu, 24 Nov 2011 15:38:59 -0800 (PST) (envelope-from Ted.Lemon@nominum.com)
Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.01.0339.001; Thu, 24 Nov 2011 15:39:00 -0800
From: Ted Lemon 
To: Lorenzo Colitti 
Thread-Topic: [v6ops] DHCPv6 option for MAX_SOL_RT
Thread-Index: AQHMpBVS9v5OyU3dDEaf8biIUoZIIJWwMYMAgACJcgCAAANuAP//e/aAgAD3r4CAAQPRAIAAGkmAgAAkTwCAAEPzAIAAvrKAgAABC4CAAAnSAIAABdOAgAVG1oCAAFm1gIAAEJAAgAABEACAAAd2AIAABASAgAKnm4CAAAHjAIAAAqoAgAABuICAAAIeAIAAAugAgAAB5YCAABx9gIAAuogA
Date: Thu, 24 Nov 2011 23:38:59 +0000
Message-ID: <4DF0EE0F-E72C-4CB9-8456-A68C4EA22DCE@nominum.com>
References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com>  <5B6B2B64C9FE2A489045EEEADDAFF2C30354473D@XMB-RCD-109.cisco.com> <4EC455D6.8030601@bogus.com>   <7EB596BF-B175-40BF-ABC8-326599670B04@apple.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303544B88@XMB-RCD-109.cisco.com>    <8D342733-88E6-45D3-B388-E001AE32CD77@employees.org> <750BF7861EBBE048B3E648B4BB6E8F4F20DC4FEA@crexc50p>  <007801cca8c8$5610aa00$0231fe00$@iname.com>  <00f801cca8fd$784fcdf0$68ef69d0$@iname.com> <418C43A6-5E8A-4CBD-83F4-3C5F502213A1@employees.org>    <49D07B35-997E-4F99-B7B0-F3A9BBAF00B0@nominum.com>      
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.1.10]
Content-Type: multipart/alternative; boundary="_000_4DF0EE0FE72C4CB98456A68C4EA22DCEnominumcom_"
MIME-Version: 1.0
Cc: IPv6 Operations 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 24 Nov 2011 23:39:05 -0000

--_000_4DF0EE0FE72C4CB98456A68C4EA22DCEnominumcom_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

On Nov 24, 2011, at 12:46 AM, Lorenzo Colitti wrote:
The point I'm trying to make is that it doesn't matter what I believe, it m=
atters what the RFC says. The RFC says "managed address configuration". So =
if it's not managed, and it doesn't involve addresses, it's not covered by =
the M bit.

The fact that PD is managed doesn't mean it has to be covered by the M bit.=
 Everything given via DHCPv6 is managed - that's what DHCPv6 is for.

I think you were originally trying to make the point that the O bit is what=
 signifies an interest in PD, but that's contrary to the intention of the w=
orking group at the time the spec was written.   The managed bit specifical=
ly refers to address allocation being managed.   PD is address allocation; =
hence, the managed bit signifies PD, not the Other bit.

In any case, if you look at section 12 of RFC3633, it specifically says tha=
t the requesting router is supposed to behave in the same way as described =
in RFC3315 for a client-initiated configuration exchange, which means that =
it has to do whatever a stateful DHCPv6 client would do, and _not_ what a s=
tateless DHCPv6 client would do.


--_000_4DF0EE0FE72C4CB98456A68C4EA22DCEnominumcom_
Content-Type: text/html; charset="iso-8859-1"
Content-ID: <9341A16150BB694A9BB6B76D2726EF3B@nominum.com>
Content-Transfer-Encoding: quoted-printable









On Nov 24, 2011, at 12:46 AM, Lorenzo Colitti wrote:




The point I'm trying to make is that it doesn't matter what I believe,=
 it matters what the RFC says. The RFC says "managed address configura=
tion". So if it's not managed, and it doesn't involve addresses, it's =
not covered by the M bit.









The fact that PD is managed doesn't mean it has to be covered by the M=
 bit. Everything given via DHCPv6 is managed - that's what DHCPv6 is for.









I think you were originally trying to make the point that the O bit is=
 what signifies an interest in PD, but that's contrary to the intention of =
the working group at the time the spec was written.   The managed bit =
specifically refers to address allocation
 being managed.   PD is address allocation; hence, the managed bit sig=
nifies PD, not the Other bit.







In any case, if you look at section 12 of RFC3633, it specifically say=
s that the requesting router is supposed to behave in the same way as descr=
ibed in RFC3315 for a client-initiated configuration exchange, which means =
that it has to do whatever a stateful
 DHCPv6 client would do, and _not_ what a stateless DHCPv6 client would do.=










--_000_4DF0EE0FE72C4CB98456A68C4EA22DCEnominumcom_--

From dougb@dougbarton.us  Thu Nov 24 15:44:08 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B5431F0C5D for ; Thu, 24 Nov 2011 15:44:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.46
X-Spam-Level: 
X-Spam-Status: No, score=-3.46 tagged_above=-999 required=5 tests=[AWL=0.139,  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 oavPIZfmrF6e for ; Thu, 24 Nov 2011 15:44:08 -0800 (PST)
Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id BF1051F0C36 for ; Thu, 24 Nov 2011 15:44:07 -0800 (PST)
Received: (qmail 9481 invoked by uid 399); 24 Nov 2011 23:44:01 -0000
Received: from unknown (HELO 172-17-198-245.globalsuite.net) (dougb@dougbarton.us@12.207.105.210) by mail2.fluidhosting.com with ESMTPAM; 24 Nov 2011 23:44:01 -0000
X-Originating-IP: 12.207.105.210
X-Sender: dougb@dougbarton.us
Message-ID: <4ECED6C0.8060406@dougbarton.us>
Date: Thu, 24 Nov 2011 15:44:00 -0800
From: Doug Barton 
Organization: http://SupersetSolutions.com/
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111110 Thunderbird/8.0
MIME-Version: 1.0
To: Lorenzo Colitti 
References:  <4ECC139C.9080600@gmail.com> <201111231421.pANELBqP013658@cichlid.raleigh.ibm.com> <4ECD3EDF.2020206@dougbarton.us> 
In-Reply-To: 
X-Enigmail-Version: undefined
OpenPGP: id=1A1ABC84
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: Thomas Narten , "v6ops@ietf.org" 
Subject: Re: [v6ops] Title of draft-ietf-v6ops-v6-aaaa-whitelisting-implications-07
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 24 Nov 2011 23:44:08 -0000

On 11/23/2011 18:36, Lorenzo Colitti wrote:
> On Thu, Nov 24, 2011 at 03:43, Doug Barton  > wrote:
> 
>     >             On Using the DNS for Transitioning Content to IPv6
> 
>     If you're going to drag DNS into the title, I'd prefer something that
>     didn't imply that it's a protocol issue. How about, "DNS Access Control
>     Lists for Transitioning Content to IPv6." You can add a "Using" to the
>     beginning of that if you don't think it's too long. (Note, I
>     specifically rejected s/ACL/Whitelisting/ in order to avoid the
>     argument, no matter how silly I think the argument is, but I won't
>     object if you want to use it instead.)
> 
> 
> Please don't use the term access control list. We've been through that
> argument already.

Seriously? Are we so far down the rabbit hole that calling something
what it actually is can't be tolerated?

> I agree with Brian that this document does not provide complete guidance
> to a website operator that wants to enable IPv6. However, it deals with
> the last stage in the transition to dual-stack, 

No it doesn't. It offers one (bad) alternative to migrating, it's
certainly not a necessary step.

> i.e., how to
> incrementally enable access to web content that is already available
> over IPv6 (in the sense that if a user knew the IPv6 address of the
> server and sent an HTTP request, he would get a response). The focus on
> DNS is that given current browser behaviour, the only tool for doing so
> is controlling which DNS records are published.

So what you're saying is that it's a list, that controls who gets access
to the IPv6 records? Interesting. :)

-- 

		"We could put the whole Internet into a book."
		"Too practical."

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/


From furry13@gmail.com  Thu Nov 24 16:45:17 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC9DC11E80A5 for ; Thu, 24 Nov 2011 16:45:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0eqnNbhJonY for ; Thu, 24 Nov 2011 16:45:17 -0800 (PST)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 24F9F11E809D for ; Thu, 24 Nov 2011 16:45:16 -0800 (PST)
Received: by bkbzv15 with SMTP id zv15so3699277bkb.31 for ; Thu, 24 Nov 2011 16:45:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=w7Fs5BP8Nd9AEKXEcRnHKcXl3elPW7NS3OcuW272++Q=; b=C8ua3heK87fJaomIrBiW2FvNED5QE+Oqq4LB6pMaZDKCVzdN9vvoc8hmYVI6EweICc u4swr3DwODAcKV62rOJlJNdrsmoezgZh2xde2wYYbOGG8FM6iou4Yx2s2MWKZgdvyYGC Eo57S8BtTT3WxDwuZW5UGR0W3SS8gwp3QRQU4=
MIME-Version: 1.0
Received: by 10.204.38.16 with SMTP id z16mr32114408bkd.66.1322181916227; Thu, 24 Nov 2011 16:45:16 -0800 (PST)
Received: by 10.223.1.138 with HTTP; Thu, 24 Nov 2011 16:45:16 -0800 (PST)
In-Reply-To: <20111124125545.GW71280@Space.Net>
References:   <4ECDB09E.2090807@gmail.com>  <20111124125545.GW71280@Space.Net>
Date: Fri, 25 Nov 2011 11:45:16 +1100
Message-ID: 
From: Jen Linkova 
To: Gert Doering 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Philip Homburg , v6ops@ietf.org
Subject: Re: [v6ops] Routers forwarding packet with link local source
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 25 Nov 2011 00:45:18 -0000

On Thu, Nov 24, 2011 at 11:55 PM, Gert Doering  wrote:
> On Thu, Nov 24, 2011 at 08:52:04AM +0100, Philip Homburg wrote:
>> I'm not complaining about the router that originated the packet. That ca=
n
>> happen, no problem.
>
> I tend to disagree. =A0Unless the router has no single global IPv6 addres=
s,
> it should never send out packets to a global scoped IPv6 address sourced
> from a link-local address.

I was going to say 'exactly so we are dealing either with broken
address selection or with an internet-connected router
w/o *any* global-scope IPv6 address' but then I looked into RFC 3484:

"It is RECOMMENDED that the candidate source addresses be the set of
   unicast addresses assigned to the interface that will be used to send
   to the destination.  (The "outgoing" interface.)  On routers, the
   candidate set MAY include unicast addresses assigned to any interface
   that forwards packets, subject to the restrictions described below.

     [skip]
     Implementations that wish to support the use
      of global source addresses assigned to a loopback interface should
      behave as if the loopback interface originates and forwards the
      packet."

So looks like that if router has link-local address only on the
outgoing interface
even with global IP on the loopback might include only link-local to
the list of candidate source addresses..

Although I still have a hope that most implementations are more
reasonable and do include at least the loopback IP into the list..

> ... while I'm not sure that there is an RFC that explicitely says that
> this is a MUST NOT, it should be self-explanatory, given that other route=
rs
> are expected to drop these packets in-transit...

"5. Source Address Selection:
...
 If the eight rules fail to choose a
   single address, some unspecified tie-breaker should be used."

Looks like it isn't prohibited, the behavior is undefined.

--=20
SY, Jen Linkova aka Furry

From lorenzo@google.com  Thu Nov 24 16:59:52 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A08911E80B8 for ; Thu, 24 Nov 2011 16:59:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.92
X-Spam-Level: 
X-Spam-Status: No, score=-102.92 tagged_above=-999 required=5 tests=[AWL=0.056, 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 0TGCOcg0B6dw for ; Thu, 24 Nov 2011 16:59:51 -0800 (PST)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8A5EC11E80B7 for ; Thu, 24 Nov 2011 16:59:51 -0800 (PST)
Received: by yenl8 with SMTP id l8so561467yen.31 for ; Thu, 24 Nov 2011 16:59:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=jp1azrmgwi+woqu4n+XcekN54hCc1h7IhSYF2f0RCT0=; b=XAVQi3VtqMsKN8plAXOETWjTTi/sMqxTV6085kZSKdmRgkygSMX/Gpd98HRLzRPYH+ uW/GHrnq8p2ATzt3yneg==
Received: by 10.236.75.167 with SMTP id z27mr44877459yhd.53.1322182791212; Thu, 24 Nov 2011 16:59:51 -0800 (PST)
Received: by 10.236.75.167 with SMTP id z27mr44877447yhd.53.1322182791109; Thu, 24 Nov 2011 16:59:51 -0800 (PST)
MIME-Version: 1.0
Received: by 10.150.202.14 with HTTP; Thu, 24 Nov 2011 16:59:30 -0800 (PST)
In-Reply-To: <4ECED6C0.8060406@dougbarton.us>
References:  <4ECC139C.9080600@gmail.com> <201111231421.pANELBqP013658@cichlid.raleigh.ibm.com> <4ECD3EDF.2020206@dougbarton.us>  <4ECED6C0.8060406@dougbarton.us>
From: Lorenzo Colitti 
Date: Fri, 25 Nov 2011 09:59:30 +0900
Message-ID: 
To: Doug Barton 
Content-Type: multipart/alternative; boundary=20cf3005dde6979f0b04b284ab2a
X-System-Of-Record: true
Cc: Thomas Narten , "v6ops@ietf.org" 
Subject: Re: [v6ops] Title of draft-ietf-v6ops-v6-aaaa-whitelisting-implications-07
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 25 Nov 2011 00:59:52 -0000

--20cf3005dde6979f0b04b284ab2a
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Nov 25, 2011 at 08:44, Doug Barton  wrote:

> > Please don't use the term access control list. We've been through that
> > argument already.
>
> Seriously? Are we so far down the rabbit hole that calling something
> what it actually is can't be tolerated?
>

Ok, then let's repeat the argument. It is not an access control list
because it does not control access to a resource that the user is trying to
reach. The user is requesting a resource (e.g., a web page), and the
resource is available regardless of what protocol is used to transport
it. Just as Google does not hand out an IP addresses for datacenters in
Tokyo to users on the East coast because it would lead to bad performance.
Similarly, Google doesn't want to hand out AAAA records if doing so would
cause your connectivity to break.

No it doesn't. It offers one (bad) alternative to migrating, it's
> certainly not a necessary step.
>

And yet, major website operators like Google and Facebook are currently
doing it, and Akamai has publicly said they will be doing it. What should
they be doing instead? Publish AAAA records and if half a million users
can't reach their website and have no idea what's going on, then it's just
too bad?


> So what you're saying is that it's a list, that controls who gets access
> to the IPv6 records? Interesting. :)


It's a component in a system that tries to hand out the IP addresses that
will result in the best user experience.

--20cf3005dde6979f0b04b284ab2a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Fri, Nov 25, 2011 at 08:44, Doug Barton <dougb@dougbarton.us=
> wrote:



> Please don't use the term access control list. W=
e've been through that

> argument already.




Seriously? Are we so far down the rabbit hole that calling something<=
br>
what it actually is can't be tolerated?

=

Ok, then let's repeat the argument. It is not an access control li=
st because it does not control access to a resource that the user is trying=
 to reach.=A0The user is requesting a resource (e.g., a web page), and the =
resource=A0is available regardless of what protocol is used to transport it=
.=A0Just as Google does not hand out an=A0IP addresses for datacenters in T=
okyo to users on the East coast because it would lead to bad performance. S=
imilarly, Google doesn't want to hand out AAAA records if doing so woul=
d cause your connectivity to break.




No it doesn't. It offers=
 one (bad) alternative to migrating, it's

certainly not a necessary step.

And yet=
, major website operators like Google and Facebook are currently doing it, =
and Akamai has publicly said they will be doing it. What should they be doi=
ng instead? Publish AAAA records and if half a million users can't reac=
h their website and have no idea what's going on, then it's just to=
o bad?



=A0


So what you're saying is that it's a list, that c=
ontrols who gets access

to the IPv6 records? Interesting. :)

It'=
;s a component in a system that tries to hand out the IP addresses that wil=
l result in the best user experience.


--20cf3005dde6979f0b04b284ab2a--

From lorenzo@google.com  Thu Nov 24 17:03:39 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10F881F0C7B for ; Thu, 24 Nov 2011 17:03:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.922
X-Spam-Level: 
X-Spam-Status: No, score=-102.922 tagged_above=-999 required=5 tests=[AWL=0.054, 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 xz0p3Bv6bg9r for ; Thu, 24 Nov 2011 17:03:38 -0800 (PST)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 85D691F0C76 for ; Thu, 24 Nov 2011 17:03:38 -0800 (PST)
Received: by yenl8 with SMTP id l8so563844yen.31 for ; Thu, 24 Nov 2011 17:03:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=HAkjpzRo1/1OJ13ui/OUSP5eCLqdzo9RB6lkt+ePW48=; b=pdBSPuw0KOto9YOgMBdaPL6maVOQzE+Ln/PmNjKm/3mvuAxVWRA4c3Gji3dDq/V2V6 3+LuVGn/JBX0sQcV6G2Q==
Received: by 10.236.183.52 with SMTP id p40mr44310774yhm.19.1322183018201; Thu, 24 Nov 2011 17:03:38 -0800 (PST)
Received: by 10.236.183.52 with SMTP id p40mr44310759yhm.19.1322183018116; Thu, 24 Nov 2011 17:03:38 -0800 (PST)
MIME-Version: 1.0
Received: by 10.150.202.14 with HTTP; Thu, 24 Nov 2011 17:03:17 -0800 (PST)
In-Reply-To: <4DF0EE0F-E72C-4CB9-8456-A68C4EA22DCE@nominum.com>
References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com>  <5B6B2B64C9FE2A489045EEEADDAFF2C30354473D@XMB-RCD-109.cisco.com> <4EC455D6.8030601@bogus.com>   <7EB596BF-B175-40BF-ABC8-326599670B04@apple.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303544B88@XMB-RCD-109.cisco.com>    <8D342733-88E6-45D3-B388-E001AE32CD77@employees.org> <750BF7861EBBE048B3E648B4BB6E8F4F20DC4FEA@crexc50p>  <007801cca8c8$5610aa00$0231fe00$@iname.com>  <00f801cca8fd$784fcdf0$68ef69d0$@iname.com> <418C43A6-5E8A-4CBD-83F4-3C5F502213A1@employees.org>    <49D07B35-997E-4F99-B7B0-F3A9BBAF00B0@nominum.com>       <4DF0EE0F-E72C-4CB9-8456-A68C4EA22DCE@nominum.com>
From: Lorenzo Colitti 
Date: Fri, 25 Nov 2011 10:03:17 +0900
Message-ID: 
To: Ted Lemon 
Content-Type: multipart/alternative; boundary=bcaec52c5ea91f759b04b284b920
X-System-Of-Record: true
Cc: IPv6 Operations 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 25 Nov 2011 01:03:39 -0000

--bcaec52c5ea91f759b04b284b920
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Nov 25, 2011 at 08:38, Ted Lemon  wrote:

>  I think you were originally trying to make the point that the O bit is
> what signifies an interest in PD, but that's contrary to the intention of
> the working group at the time the spec was written.
>

What I'm trying to say that I think the current text of the spec says that
M = managed address configuration and O = other configuration, and that
unless you believe that a prefix is an address, DHCPv6 PD should not be
controlled by M.

I don't know what the intention was at the time the spec (which one are you
referring to?) was written, but if that was not the intention, then the
spec is poorly worded and we should fix it. That's all.

But yes, we're ratholing here.

--bcaec52c5ea91f759b04b284b920
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Fri, Nov 25, 2011 at 08:38, Ted Lemon <Ted.Lemon@nominum.c=
om> wrote:











I think you were originally trying to make the point that the O bit is=
 what signifies an interest in PD, but that's contrary to the intention=
 of the working group at the time the spec was written.




What I'm trying to say that I th=
ink the current text of the spec says that M =3D managed address configurat=
ion and O =3D other configuration, and that unless you believe that a prefi=
x is an address, DHCPv6 PD should not be controlled by M.




I don't know what the intention was at the time the=
 spec (which one are you referring to?) was written, but if that was not th=
e intention, then the spec is poorly worded and we should fix it. That'=
s all.




But yes, we're ratholing here.


--bcaec52c5ea91f759b04b284b920--

From furry13@gmail.com  Thu Nov 24 17:27:45 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA06B21F8C54 for ; Thu, 24 Nov 2011 17:27:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NpxSCE8dqyyY for ; Thu, 24 Nov 2011 17:27:45 -0800 (PST)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0A23E21F8C53 for ; Thu, 24 Nov 2011 17:27:44 -0800 (PST)
Received: by bkbzv15 with SMTP id zv15so3731758bkb.31 for ; Thu, 24 Nov 2011 17:27:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PZfvYeDTqZGIwHySl3s4ZA+FX6VWYzrUZLnEBTW2IwE=; b=fm3sGVy3HuYYhpw8tdt6Lf/qLyrkhIfQlTaheK7OtTYUgxSoclgNDLQX+AEsvQfeP6 oxANEGpVqNRLjYqhod1GpzbxHjOFEeYwmx4UV7wOSe8otrzDEPKqeKbzEc6jrDsw4VW4 gd6A1d3n69CKtZdPa1mDduKzOQaLH6fRGhmSw=
MIME-Version: 1.0
Received: by 10.204.157.151 with SMTP id b23mr31622828bkx.30.1322184464094; Thu, 24 Nov 2011 17:27:44 -0800 (PST)
Received: by 10.223.1.138 with HTTP; Thu, 24 Nov 2011 17:27:43 -0800 (PST)
In-Reply-To: 
References:   
Date: Fri, 25 Nov 2011 12:27:43 +1100
Message-ID: 
From: Jen Linkova 
To: Philip Homburg 
Content-Type: text/plain; charset=ISO-8859-1
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Routers forwarding packet with link local source
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 25 Nov 2011 01:27:45 -0000

On Wed, Nov 23, 2011 at 10:04 PM, Philip Homburg
 wrote:
> One question is whether this is a bug or a feature.

1) a router sending ICMPv6 using link-local as a source. Might be a
bug, might be a lazy implementation, or might be a legitimate behavior
(in the last case I'm inclined to blame the network design..).
Not explicitly prohibited but shall be avoided as it contradicts common-sense.

2) other routers on the path forwarded such packets. Indubitably, this
is a direct violation of at least two RFCs.

This should be fixed (for non-ICMP packets the gateway shall also
respond with ICMPv6 type 1 code 2 to the host, AFAIR).

>The effect is that the
> error ICMP arrives. Which is good, but proper (ingress) filtering is also good.

This is about 'security vs usability' tradeoff.  In this particular
case I'd take security side providing such packets shouldn't normally
appear in the network and can be used for attacks.

-- 
SY, Jen Linkova aka Furry

From Ted.Lemon@nominum.com  Thu Nov 24 18:25:32 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3A7F11E80D6 for ; Thu, 24 Nov 2011 18:25:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.577
X-Spam-Level: 
X-Spam-Status: No, score=-106.577 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 AmgZZROrHDwi for ; Thu, 24 Nov 2011 18:25:31 -0800 (PST)
Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 338B711E80B2 for ; Thu, 24 Nov 2011 18:25:30 -0800 (PST)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKTs78lFyBROEcgal0TgzrnMeXiG1e4YJH@postini.com; Thu, 24 Nov 2011 18:25:31 PST
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id B97F81B8240 for ; Thu, 24 Nov 2011 18:25:23 -0800 (PST)
Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id A07B5190052; Thu, 24 Nov 2011 18:25:22 -0800 (PST) (envelope-from Ted.Lemon@nominum.com)
Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.01.0339.001; Thu, 24 Nov 2011 18:25:22 -0800
From: Ted Lemon 
To: Lorenzo Colitti 
Thread-Topic: [v6ops] DHCPv6 option for MAX_SOL_RT
Thread-Index: AQHMpBVS9v5OyU3dDEaf8biIUoZIIJWwMYMAgACJcgCAAANuAP//e/aAgAD3r4CAAQPRAIAAGkmAgAAkTwCAAEPzAIAAvrKAgAABC4CAAAnSAIAABdOAgAVG1oCAAFm1gIAAEJAAgAABEACAAAd2AIAABASAgAKnm4CAAAHjAIAAAqoAgAABuICAAAIeAIAAAugAgAAB5YCAABx9gIAAuogAgACIvoCAABbpgA==
Date: Fri, 25 Nov 2011 02:25:22 +0000
Message-ID: 
References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com>  <5B6B2B64C9FE2A489045EEEADDAFF2C30354473D@XMB-RCD-109.cisco.com> <4EC455D6.8030601@bogus.com>   <7EB596BF-B175-40BF-ABC8-326599670B04@apple.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303544B88@XMB-RCD-109.cisco.com>    <8D342733-88E6-45D3-B388-E001AE32CD77@employees.org> <750BF7861EBBE048B3E648B4BB6E8F4F20DC4FEA@crexc50p>  <007801cca8c8$5610aa00$0231fe00$@iname.com>  <00f801cca8fd$784fcdf0$68ef69d0$@iname.com> <418C43A6-5E8A-4CBD-83F4-3C5F502213A1@employees.org>    <49D07B35-997E-4F99-B7B0-F3A9BBAF00B0@nominum.com>       <4DF0EE0F-E72C-4CB9-8456-A68C4EA22DCE@nominum.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.1.10]
Content-Type: multipart/alternative; boundary="_000_D7A05DD7132F459E8CB991EFF99ADE21nominumcom_"
MIME-Version: 1.0
Cc: IPv6 Operations 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 25 Nov 2011 02:25:32 -0000

--_000_D7A05DD7132F459E8CB991EFF99ADE21nominumcom_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

On Nov 24, 2011, at 8:03 PM, Lorenzo Colitti wrote:
What I'm trying to say that I think the current text of the spec says that =
M =3D managed address configuration and O =3D other configuration, and that=
 unless you believe that a prefix is an address, DHCPv6 PD should not be co=
ntrolled by M.

So despite the fact that RFC3633 explicitly states that the requesting rout=
er is supposed to follow the behavior specified in RFC3315, you think that =
we should do the opposite.


--_000_D7A05DD7132F459E8CB991EFF99ADE21nominumcom_
Content-Type: text/html; charset="iso-8859-1"
Content-ID: <26B3B79671E7724DB031AAB3EE6B912E@nominum.com>
Content-Transfer-Encoding: quoted-printable









On Nov 24, 2011, at 8:03 PM, Lorenzo Colitti wrote:


What
 I'm trying to say that I think the current text of the spec says that M =
=3D managed address configuration and O =3D other configuration, and that u=
nless you believe that a prefix is an address, DHCPv6 PD should not be cont=
rolled by M.






So despite the fact that RFC3633 explicitly states that the requesting=
 router is supposed to follow the behavior specified in RFC3315, you think =
that we should do the opposite.









--_000_D7A05DD7132F459E8CB991EFF99ADE21nominumcom_--

From mark@townsley.net  Thu Nov 24 22:08:30 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F278A21F8BCD for ; Thu, 24 Nov 2011 22:08:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.437
X-Spam-Level: 
X-Spam-Status: No, score=-3.437 tagged_above=-999 required=5 tests=[AWL=0.161,  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 TtyR5cy37gbQ for ; Thu, 24 Nov 2011 22:08:29 -0800 (PST)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5F45B21F8B31 for ; Thu, 24 Nov 2011 22:08:28 -0800 (PST)
Received: by wwp14 with SMTP id 14so2322030wwp.13 for ; Thu, 24 Nov 2011 22:08:27 -0800 (PST)
Received: by 10.180.103.131 with SMTP id fw3mr31680609wib.57.1322201307215; Thu, 24 Nov 2011 22:08:27 -0800 (PST)
Received: from ams-townsley-8712.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id v10sm10268731wiy.23.2011.11.24.22.08.23 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 24 Nov 2011 22:08:24 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-14-296718193
From: Mark Townsley 
In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF226@XMB-RCD-109.cisco.com>
Date: Fri, 25 Nov 2011 07:08:21 +0100
Message-Id: 
References: <68DAB112-6E32-45FE-9AB7-A34E64898F60@cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C30354436E@XMB-RCD-109.cisco.com><750BF7861EBBE048B3E648B4BB6E8F4F20DC41F6@crexc50p><252D3DEA-FF09-42C8-959E-8A7205D9DE67@townsley.net><20111122133612.GH71280@Space.Net>  <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF226@XMB-RCD-109.cisco.com>
To: "Hemant Singh (shemant)" 
X-Mailer: Apple Mail (2.1084)
Cc: Alexandre Cassen , Claire Cheng , v6ops@ietf.org
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 25 Nov 2011 06:08:30 -0000

--Apple-Mail-14-296718193
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


On Nov 24, 2011, at 10:02 PM, Hemant Singh (shemant) wrote:

> =20
> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf =
Of Lorenzo Colitti
> Sent: Wednesday, November 23, 2011 10:07 PM
> To: Mark Townsley
> Cc: Claire Cheng; v6ops@ietf.org; Alexandre Cassen
> Subject: Re: [v6ops] 6rd Sunsetting
> =20
> =20
> >If the native network drops traffic with 6rd source addresses,
> =20
> Which network segment are we talking about?  In the network between =
the CE router and the 6rd BR, the BR controls the phasing out of 6rd and =
hence the BR is likely not to drop 6rd sourced traffic. =20

The *native* IPv6 network. No BR in the native IPv6 network.=20

> If the network segment is north of the BR why would the network drop =
an IPv6 packet of the 6rd prefix?  If the CE router is directly =
communicating to another CE router,  we have 6rd traffic that the =
receiving CE router does not drop.  Anyhow, don=92t drop without sending =
an ICMPv6 Destination Unreachable error message to the source.=20

I think you are confused. Lorenzo is saying that if you send a packet =
from a subscriber into the native IPv6 network with a source address =
that does not match a delegated prefix for that subscriber, it is likely =
to be dropped by the native IPv6 network.=20

> =20
> >and the 6rd BR drops traffic with native source addresses,
> =20
> It is the BR who indicated to the CE router via an RA that native IPv6 =
is available and say,

No, BRs do not send RAs to CEs. BRs have no state, and may be multiple =
L3 hops away from the CE.=20

Are you are confusing "BR" and "BNG"?

> the CE router acquired a new prefix (different from the 6rd prefix).  =
So why would the BR drop native IPv6 sourced traffic if the rfc6204bis, =
rule 5 in section 4.4.3 is applied?

If the BR receives an IPv6 packet encapsulated in IPv4 and destined to =
the 6rd tunnel IPv4 destination address, it will perform a check on the =
source IPv6 and IPv4 addresses to see if they match the configured 6rd =
rule (see RFC 5969). If they do not match, the packet is dropped. An =
IPv6 address from outside the 6rd prefix for the 6rd domain will by =
definition not match.=20

> =20
> >I do stand by my assertion that relying on the CE router to get this =
right all the time is a risky bet and is unlikely to work in all cases =
unless the ISP manages the CE (in which >case of course they can do what =
they like anyway).
> =20
> MarkT has already said, =93manual 6rd configuration is out of scope of =
the 6rd and 6rd sunsetting specification.

That is my point of view, but I don't think Lorenzo is talking about =
manual config in this sentence.

I think Lorenzo is saying that based on his experience, IPv6 =
implementations in home routers are not of the highest quality and that =
anything but the simplest of configurations are not likely to work as =
expected.

- Mark

> =20
> Hemant


--Apple-Mail-14-296718193
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252


On Nov 24, 2011, at 10:02 PM, Hemant =
Singh (shemant) wrote:

From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Lorenzo =
Colitti
Sent: Wednesday, November 23, =
2011 10:07 PM
To: Mark =
Townsley
Cc: Claire Cheng; v6ops@ietf.org; Alexandre =
Cassen
Subject: Re: [v6ops] 6rd =
Sunsetting
>If the native network drops traffic with =
6rd source addresses,Which =
network segment are we talking about?  In the network between the =
CE router and the 6rd BR, the BR controls the phasing out of 6rd and =
hence the BR is likely not to drop 6rd sourced =
traffic.  

The *native* IPv6 network. No BR in the native =
IPv6 network. 

 If =
the network segment is north of the BR why would the network drop an =
IPv6 packet of the 6rd prefix?  If the CE router is directly =
communicating to another CE router,  we have 6rd traffic that the =
receiving CE router does not drop.  Anyhow, don=92t drop without =
sending an ICMPv6 Destination Unreachable error message to the =
source. 

I think you are confused. Lorenzo is saying that if you =
send a packet from a subscriber into the native IPv6 network with a =
source address that does not match a delegated prefix for that =
subscriber, it is likely to be dropped by the native IPv6 =
network. 

>and the 6rd BR drops traffic with native =
source addresses,It is =
the BR who indicated to the CE router via an RA that native IPv6 is =
available and say, =


No, BRs do not send RAs to CEs. BRs have no state, and may be =
multiple L3 hops away from the CE. 

Are =
you are confusing "BR" and "BNG"?

the =
CE router acquired a new prefix (different from the 6rd prefix).  =
So why would the BR drop native IPv6 sourced traffic if the rfc6204bis, =
rule 5 in section 4.4.3 is =
applied?

=

If the BR receives an IPv6 packet encapsulated in IPv4 and =
destined to the 6rd tunnel IPv4 destination address, it will perform a =
check on the source IPv6 and IPv4 addresses to see if they match the =
configured 6rd rule (see RFC 5969). If they do not match, the packet is =
dropped. An IPv6 address from outside the 6rd prefix for the 6rd domain =
will by definition not match. 

 
>I =
do stand by my assertion that relying on the CE router to get this right =
all the time is a risky bet and is unlikely to work in all cases unless =
the ISP manages the CE (in which >case of course they can do what they like =
anyway).MarkT =
has already said, =93manual 6rd configuration is out of scope of the 6rd =
and 6rd sunsetting =
specification.

That is my point of view, but I don't think Lorenzo is =
talking about manual config in this sentence.

I =
think Lorenzo is saying that based on his experience, IPv6 =
implementations in home routers are not of the highest quality and that =
anything but the simplest of configurations are not likely to work as =
expected.

- Mark

 The rest can be handled with a subscriber management in the mobile =
backend.

cheers,
Ole




From jouni.nospam@gmail.com  Fri Nov 25 03:15:09 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E11C21F8C18 for ; Fri, 25 Nov 2011 03:15:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.49
X-Spam-Level: 
X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.490,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 ZP7yBPq1Mhrp for ; Fri, 25 Nov 2011 03:15:09 -0800 (PST)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id B921421F8C13 for ; Fri, 25 Nov 2011 03:15:08 -0800 (PST)
Received: by vbbez10 with SMTP id ez10so3436182vbb.31 for ; Fri, 25 Nov 2011 03:15:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=aYUmQ5jHXYnw1fpmSd88NtxFvz4/gxG0ouwN8OPGguw=; b=BjMvfIbuvUWBBwnysk4w6gRwHzWzY8ZPk1yDfwLxad6k+bi87k/BdxcndUVy9qVSE5 /S2MJ9VMavI/hUWzu1HAz2agVoBjx6r3P3UgOLTOEpZ0deUSWg1c93RC9df/YQFjShG1 bqm7Hi7QouoHe9KrvjKZRzLntkEbjzOMnfd1c=
Received: by 10.52.69.70 with SMTP id c6mr33301085vdu.65.1322219708136; Fri, 25 Nov 2011 03:15:08 -0800 (PST)
Received: from [10.255.137.175] ([192.100.123.77]) by mx.google.com with ESMTPS id z3sm18628937vdg.16.2011.11.25.03.15.06 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 25 Nov 2011 03:15:07 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: jouni korhonen 
In-Reply-To: 
Date: Fri, 25 Nov 2011 13:15:03 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:    <2963F168-45CB-4042-8238-56DF538B0543@gmail.com> 
To: Ole Troan 
X-Mailer: Apple Mail (2.1084)
Cc: v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-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: Fri, 25 Nov 2011 11:15:09 -0000

Ole,

On Nov 25, 2011, at 12:08 PM, Ole Troan wrote:

> Jouni,
>=20
>>>> I understand your (both or you) points. But we also need to keep in =
mind that when RFC6204 came out 3GPP community was adding (or had just =
added) PD into their specs. There was not much point arguing any =
cellular CE requirement before that (except maybe something tethering =
related).
>>>=20
>>> given the exclude option, what else you do need?
>>=20
>> In addition to exclude, probably relaxing MUST for IA_NA (WAA-4) when =
the stateful address configuration is not plain supported on WAN link. I =
want to have a confidence for the case where a CE has e.g. a LTE as a =
backup for fixed connection, the CE does not try to acquire its WAN =
interface address using DHCPv6 when it switches to LTE... and then get =
stuck/confused.
>=20
> I don't see how this case is any different than any other WAN link =
where address assignment isn't done with DHCP?
> the requirement in WAA-4 only says "MUST be capable of".

So you are saying "MUST be able to support" does not mandate me to =
implement something? If that is the case, then fine.

> what is the confusion?
> - CE asks for IA_NA + IA_PD?

This one. What would be the expected CE behavior if the server does not =
include IA_NA in its response?

Can we assume the CE does the right thing (i.e. just asks for IA_PD) =
when the cellular is a backup and the primary on fixed does ask for =
IA_NA+IA_PD? If this is the case based on RFC6204bis recommendation, =
then fine.


> - or CE asks only for IA_PD because it is hardcoded not to do IA_NA on =
LTE links
> - or CE follows the M flag and does only IA_PD?

This is how I hope this to work.=20

>=20
> in IPv6 we've tried to stick with the principle that provisioning is =
done on the network layer and done in the same way regardless of data =
link. I like us to stick to that. which is also why I'm objecting to the =
"watering down" changes proposed in 6204bis to accommodate the cable =
case, where address assignment is always done with DHCP.

Agree.

>=20
>> The rest can be handled with a subscriber management in the mobile =
backend.
>=20
> cheers,
> Ole

- Jouni


>=20
>=20
>=20


From ichiroumakino@gmail.com  Fri Nov 25 03:24:09 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 784DC21F8B4C for ; Fri, 25 Nov 2011 03:24:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.558
X-Spam-Level: 
X-Spam-Status: No, score=-3.558 tagged_above=-999 required=5 tests=[AWL=0.041,  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 W5HlXJzQJaNC for ; Fri, 25 Nov 2011 03:24:08 -0800 (PST)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 987D221F8B98 for ; Fri, 25 Nov 2011 03:24:08 -0800 (PST)
Received: by faaq16 with SMTP id q16so1776799faa.31 for ; Fri, 25 Nov 2011 03:24:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=KctxhP1Aadksd0hnYc70/izCnULXjikuWbTs2dY6FXY=; b=Mx7EDqZDMkwr81prFHSF6baJWg6/I6zcSQKqnWU5TDJYZT/1iYbjNk1+r3sMGgQI5c b3ZkIoSIvHn27oRHgkvzBKSL61Y1ZkFE5kjjMOgSDTxueAa4Q8hbyJJGJXshUgNQiFRI u49ULZD4Z5caXYXUykO8cyOzybisFCqaEEzS4=
Received: by 10.204.8.16 with SMTP id f16mr7498106bkf.134.1322220247682; Fri, 25 Nov 2011 03:24:07 -0800 (PST)
Received: from dhcp-10-55-89-121.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id z7sm18531525bka.1.2011.11.25.03.24.05 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 25 Nov 2011 03:24:06 -0800 (PST)
Sender: Ole Troan 
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Ole Troan 
In-Reply-To: 
Date: Fri, 25 Nov 2011 12:24:04 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org>
References:    <2963F168-45CB-4042-8238-56DF538B0543@gmail.com>  
To: jouni korhonen 
X-Mailer: Apple Mail (2.1084)
Cc: v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-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: Fri, 25 Nov 2011 11:24:09 -0000

Jouni,

>>> In addition to exclude, probably relaxing MUST for IA_NA (WAA-4) =
when the stateful address configuration is not plain supported on WAN =
link. I want to have a confidence for the case where a CE has e.g. a LTE =
as a backup for fixed connection, the CE does not try to acquire its WAN =
interface address using DHCPv6 when it switches to LTE... and then get =
stuck/confused.
>>=20
>> I don't see how this case is any different than any other WAN link =
where address assignment isn't done with DHCP?
>> the requirement in WAA-4 only says "MUST be capable of".
>=20
> So you are saying "MUST be able to support" does not mandate me to =
implement something? If that is the case, then fine.

no, I'm saying it doesn't say you MUST request an IA_NA on the =
interface.
with regards to implementation I presume you have to do IA_NA on e.g. =
wireless interfaces anyway.

>> what is the confusion?
>> - CE asks for IA_NA + IA_PD?
>=20
> This one. What would be the expected CE behavior if the server does =
not include IA_NA in its response?

there is an errata for 3315/33633 describing this issue. I'd like to see =
an update to 3315, as it is written assuming that there will never be =
any other stateful options in existence.
>=20
> Can we assume the CE does the right thing (i.e. just asks for IA_PD) =
when the cellular is a backup and the primary on fixed does ask for =
IA_NA+IA_PD? If this is the case based on RFC6204bis recommendation, =
then fine.
>=20
>=20
>> - or CE asks only for IA_PD because it is hardcoded not to do IA_NA =
on LTE links
>> - or CE follows the M flag and does only IA_PD?
>=20
> This is how I hope this to work.=20

>> in IPv6 we've tried to stick with the principle that provisioning is =
done on the network layer and done in the same way regardless of data =
link. I like us to stick to that. which is also why I'm objecting to the =
"watering down" changes proposed in 6204bis to accommodate the cable =
case, where address assignment is always done with DHCP.
>=20
> Agree.
>=20
>>=20
>>> The rest can be handled with a subscriber management in the mobile =
backend.
>>=20

cheers,
Ole


From jouni.nospam@gmail.com  Fri Nov 25 05:14:51 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B25921F8B8B for ; Fri, 25 Nov 2011 05:14:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.653
X-Spam-Level: 
X-Spam-Status: No, score=-2.653 tagged_above=-999 required=5 tests=[AWL=0.327,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 YUlGYH82dPVu for ; Fri, 25 Nov 2011 05:14:50 -0800 (PST)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 931E721F8B89 for ; Fri, 25 Nov 2011 05:14:50 -0800 (PST)
Received: by vbbez10 with SMTP id ez10so3525253vbb.31 for ; Fri, 25 Nov 2011 05:14:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=DyxqS3i8Gp5OeMC0ylps8QnHSS8lfbT26oRE6TYFDxM=; b=CjZOAhCAS7Dopl2kDb0XrvAA0B92gYJpF5Fh6v5PoVqDLFBhHybsLdg8WlA+j9j7/T NIw9UHEcNPL04rPiC3uQiZw/cjLwd7m9/q5SFv9iIUvBi+aLXhrWYmI+0O+l9EhxNXB7 RSx/Y7zLipcMYxHpw9CZcplaMiqG5byvsNBpY=
Received: by 10.52.174.65 with SMTP id bq1mr33578669vdc.30.1322226890055; Fri, 25 Nov 2011 05:14:50 -0800 (PST)
Received: from [10.255.137.175] ([192.100.123.77]) by mx.google.com with ESMTPS id ib2sm34398833vdb.1.2011.11.25.05.14.48 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 25 Nov 2011 05:14:49 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: jouni korhonen 
In-Reply-To: <2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org>
Date: Fri, 25 Nov 2011 15:14:45 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <7177275A-54B7-4390-9F40-2BE17DCBB152@gmail.com>
References:    <2963F168-45CB-4042-8238-56DF538B0543@gmail.com>   <2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org>
To: Ole Troan 
X-Mailer: Apple Mail (2.1084)
Cc: v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-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: Fri, 25 Nov 2011 13:14:51 -0000

Ole,

On Nov 25, 2011, at 1:24 PM, Ole Troan wrote:

>>>=20
>>> I don't see how this case is any different than any other WAN link =
where address assignment isn't done with DHCP?
>>> the requirement in WAA-4 only says "MUST be capable of".
>>=20
>> So you are saying "MUST be able to support" does not mandate me to =
implement something? If that is the case, then fine.
>=20
> no, I'm saying it doesn't say you MUST request an IA_NA on the =
interface.

Ok.

> with regards to implementation I presume you have to do IA_NA on e.g. =
wireless interfaces anyway.

Assuming the code for fixed side would implement it already, sure. Then =
it is just up to client not to request IA_NA on certain WAN link types. =
That's ok.


>>> what is the confusion?
>>> - CE asks for IA_NA + IA_PD?
>>=20
>> This one. What would be the expected CE behavior if the server does =
not include IA_NA in its response?
>=20
> there is an errata for 3315/33633 describing this issue. I'd like to =
see an update to 3315, as it is written assuming that there will never =
be any other stateful options in existence.

Right, thanks. I did not remember these erratas. These would solve my =
concern on the above case. What's the impact of those as they are still =
in "reported" status.

- Jouni


>>>=20
>=20
> cheers,
> Ole
>=20
>>>=20


From ichiroumakino@gmail.com  Fri Nov 25 06:06:01 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C9A021F8C7F for ; Fri, 25 Nov 2011 06:06:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.559
X-Spam-Level: 
X-Spam-Status: No, score=-3.559 tagged_above=-999 required=5 tests=[AWL=0.040,  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 VegfbhiwkVmJ for ; Fri, 25 Nov 2011 06:06:00 -0800 (PST)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 670F121F8C78 for ; Fri, 25 Nov 2011 06:06:00 -0800 (PST)
Received: by faaq16 with SMTP id q16so1910269faa.31 for ; Fri, 25 Nov 2011 06:05:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=WTAm9LXoarifLPR24QeGiQOtEzYvwqKMfzufd+0sVAk=; b=I1vplz/oVOY4k0xqjnb0UmT7PMDdkCwbP5F+PYeu/PppusUGcFT578Njew5kyWbtS5 oVD9IRXoJtf3j7CU/OUS8N9BiUxlSIJGEsXDW3iOhcirrzfzlVoHoI5vocINqfQWIhzG YwpyVPeL9nK2IkIxlaKjL9F6M6oYY/mv3xQWk=
Received: by 10.152.105.83 with SMTP id gk19mr20729379lab.30.1322229959107; Fri, 25 Nov 2011 06:05:59 -0800 (PST)
Received: from dhcp-10-55-84-111.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id px20sm3745474lab.2.2011.11.25.06.05.56 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 25 Nov 2011 06:05:57 -0800 (PST)
Sender: Ole Troan 
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Ole Troan 
In-Reply-To: <7177275A-54B7-4390-9F40-2BE17DCBB152@gmail.com>
Date: Fri, 25 Nov 2011 15:05:55 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <5DF1AC5D-A4D5-4812-B220-D6BB95E7C65C@employees.org>
References:    <2963F168-45CB-4042-8238-56DF538B0543@gmail.com>   <2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org> <7177275A-54B7-4390-9F40-2BE17DCBB152@gmail.com>
To: jouni korhonen 
X-Mailer: Apple Mail (2.1084)
Cc: IPv6 Operations 
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-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: Fri, 25 Nov 2011 14:06:01 -0000

Jouni,

>> there is an errata for 3315/33633 describing this issue. I'd like to =
see an update to 3315, as it is written assuming that there will never =
be any other stateful options in existence.
>=20
> Right, thanks. I did not remember these erratas. These would solve my =
concern on the above case. What's the impact of those as they are still =
in "reported" status.

1) nag the DHC chairs to verify the reports (done)
2) do an update of 3315/3633. I don't know if the DHC chairs have any =
plans for that? or if it just takes some volunteers to get started...

cheers,
Ole



From shemant@cisco.com  Fri Nov 25 08:44:16 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF8E21F8B48 for ; Fri, 25 Nov 2011 08:44:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.286
X-Spam-Level: 
X-Spam-Status: No, score=-6.286 tagged_above=-999 required=5 tests=[AWL=0.312,  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 RvSTHw-YXrii for ; Fri, 25 Nov 2011 08:44:15 -0800 (PST)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id C81BE21F8B5E for ; Fri, 25 Nov 2011 08:44:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=7966; q=dns/txt; s=iport; t=1322239455; x=1323449055; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=Rt6wyysDGuJl1i3sJ4alfDDr2dTQmvL/i6zl0kAYa9A=; b=g4k6ifPA9ict6vDs7GDxBNR9PD38pWDhHuigEzc75/ekDiNTB2Ii79E4 mmGCmlkSLSgSrF8S7T25MrfzxdeD3URCFgxKbUaxc3VLA266jSmCbIjlw WgbZpp222OxCr62j03i8rm6oren3VcetubxStgrrFybBh7f2NF1WLnJVY o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqMAAMTEz06tJXG9/2dsb2JhbABEgk2YAJAwgQWBcgEBAQQSAQkRA0kQAgEIEQQBAQsGFwEGAUUJCAEBBBMIGp9QAZ4IiX9jBIghnlM
X-IronPort-AV: E=Sophos;i="4.69,572,1315180800"; d="scan'208,217";a="38984016"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 25 Nov 2011 16:44:14 +0000
Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id pAPGiEev005463;  Fri, 25 Nov 2011 16:44:14 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 25 Nov 2011 10:44:14 -0600
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCAB91.7402F01B"
Date: Fri, 25 Nov 2011 10:44:08 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF285@XMB-RCD-109.cisco.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] 6rd Sunsetting
Thread-Index: AcyrOKg9mqgh/j97QVC1S9rqMvxacgAVhrSA
References: <68DAB112-6E32-45FE-9AB7-A34E64898F60@cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C30354436E@XMB-RCD-109.cisco.com><750BF7861EBBE048B3E648B4BB6E8F4F20DC41F6@crexc50p><252D3DEA-FF09-42C8-959E-8A7205D9DE67@townsley.net><20111122133612.GH71280@Space.Net>  <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF226@XMB-RCD-109.cisco.com> 
From: "Hemant Singh (shemant)" 
To: "Mark Townsley" 
X-OriginalArrivalTime: 25 Nov 2011 16:44:14.0070 (UTC) FILETIME=[76EC3160:01CCAB91]
Cc: Alexandre Cassen , Claire Cheng , v6ops@ietf.org
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 25 Nov 2011 16:44:16 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CCAB91.7402F01B
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

=20

From: Mark Townsley [mailto:mark@townsley.net]=20
Sent: Friday, November 25, 2011 1:08 AM
To: Hemant Singh (shemant)
Cc: Lorenzo Colitti; Claire Cheng; v6ops@ietf.org; Alexandre Cassen
Subject: Re: [v6ops] 6rd Sunsetting

=20

=20

>The *native* IPv6 network. No BR in the native IPv6 network.=20


It would be good to mention such details.  No further discussion is
possible unless a network topology diagram is presented and then we can
discuss what node sends and what node drops packets.

=20

=20

>I think you are confused.

=20

Given the short text Lorenzo sent out with no diagram one can't even
verify what the problem is.

=20

>Lorenzo is saying that if you send a packet from a subscriber into the
native IPv6 network with a source address that does not match a
delegated prefix for that subscriber, it is >likely to be dropped by the
native IPv6 network.=20

=20

The CE router has a 6rd prefix and possibly a native IPv6 different
prefix.  Why are routes for such prefixes not injected in the network
northbound?  That is why a network diagram would be useful for any
further conversation.

=20

>No, BRs do not send RAs to CEs. BRs have no state, and may be multiple
L3 hops away from the CE.=20

=20

>Are you are confusing "BR" and "BNG"?

=20

BNG and BR are co-resident.  Even if they are not, the BNG sends the RA
and the BNG routing propagates new routes for a different prefix in the
northbound BR.  =20


Hemant

=20


------_=_NextPart_001_01CCAB91.7402F01B
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


 
From:=
 =
Mark Townsley [mailto:mark@townsley.net] 
Sent: Friday, =
November 25, 2011 1:08 AM
To: Hemant Singh =
(shemant)
Cc: Lorenzo Colitti; Claire Cheng; v6ops@ietf.org; =
Alexandre Cassen
Subject: Re: [v6ops] 6rd =
Sunsetting
 
 
>The *native* =
IPv6 network. No BR in the native IPv6 =
network. 

It would be good to mention such details.  =
No further discussion is possible unless a network topology diagram is =
presented and then we can discuss what node sends and what node drops =
packets.
 
 
>I think you =
are confused.
 
Given the short text Lorenzo sent out with no diagram one can’t =
even verify what the problem is.
 
>Lorenzo is saying that if you send a =
packet from a subscriber into the native IPv6 network with a source =
address that does not match a delegated prefix for that subscriber, it =
is >likely to be dropped by the =
native IPv6 network. 
 
 The CE router has a 6rd prefix and possibly a native IPv6 =
different prefix.  Why are routes for such prefixes not injected in =
the network northbound?  That is why a network diagram would be =
useful for any further =
conversation.
 
>No, BRs do =
not send RAs to CEs. BRs have no state, and may be multiple L3 hops away =
from the CE. 
 
>Are you are =
confusing "BR" and "BNG"?
 
BNG and BR are co-resident.  Even if they are not, the BNG sends =
the RA and the BNG routing propagates new routes for a different prefix =
in the northbound BR.   

Hemant
 

------_=_NextPart_001_01CCAB91.7402F01B--

From mr.r.a.hunter@gmail.com  Tue Nov 22 01:21:18 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B54FB21F8D5B for ; Tue, 22 Nov 2011 01:21:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ew1fgLMoUumg for ; Tue, 22 Nov 2011 01:21:18 -0800 (PST)
Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id B11D421F8D52 for ; Tue, 22 Nov 2011 01:21:17 -0800 (PST)
Received: by eyg24 with SMTP id 24so7209926eyg.31 for ; Tue, 22 Nov 2011 01:21:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=21PWkWAY+8ejV0g3hdO6OCd/aFME2A9vBNcFRllP+9s=; b=LYNbDHn5R8KTpdKhlOxe71FbBOQT2E45Pv8u8G1vc9SZWusZYg+rP74Uo4KckSgJQY 5E4AwalT+fi8TQRAECSnNXpR0eDV61VxjmxIK7wlL93yhax94cD4ju2h7pAEFlPq5ZsK xwfcn3K/wkuLZClRFwXqAaz8jEx+IgX8xkjuQ=
Received: by 10.14.4.193 with SMTP id 41mr1263485eej.89.1321953676787; Tue, 22 Nov 2011 01:21:16 -0800 (PST)
Received: from Rays-iMac.local (machine.globis.net. [2001:470:d38c:2::4]) by mx.google.com with ESMTPS id o4sm39852359eeb.0.2011.11.22.01.21.15 (version=SSLv3 cipher=OTHER); Tue, 22 Nov 2011 01:21:16 -0800 (PST)
Message-ID: <4ECB6988.4020209@gmail.com>
Date: Tue, 22 Nov 2011 10:21:12 +0100
From: "Mr.R.A.Hunter" 
User-Agent: Postbox Express 1.0.1 (Macintosh/20100705)
MIME-Version: 1.0
To: Ted Lemon 
References: <20111115062859.14026.74743.idtracker@ietfa.amsl.com>		<4ECACFF5.6020804@gmail.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------020604050301050109090706"
X-Mailman-Approved-At: Fri, 25 Nov 2011 09:38:48 -0800
Cc: "v6ops@ietf.org WG" , Wesley Eddy , Pete Resnick , "" , "ietfdbh@comcast.net Harrington" 
Subject: Re: [v6ops] New Version	Notification	-	draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-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: Tue, 22 Nov 2011 09:21:55 -0000

This is a multi-part message in MIME format.
--------------020604050301050109090706
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

When you write "trivially control", what's the refresh/flush mechanism 
to inform end nodes of a (link) status change?

Setting low values for DHCPv6 lifetimes so each host individually and 
regularly pulls the new DHCP settings via renew and rebind messages?
DHCPv6 reconfigure message via a push to each host individually via unicast?
RA PIO valid lifetime = 0?

In my customers, it's highly likely that there'll be a pair of 
enterprise-wide centrally-managed highly-available DHCPv6 servers 
located off-site in a central data centre, contacted via a DHCPv6 relay 
agent configured on the local site router. I'm not sure how that 
off-site DHCPv6 server will know of local link status changes, or 
whether it will be reachable whilst links are bouncing. I'm also not 
sure it will be practicable to install local DHCPv6 servers per site 
(with central content admin). Generally speaking, there are no servers 
or technical administrators left on remote sites.

Thanks
RayH

Ted Lemon wrote:
> On Nov 21, 2011, at 5:25 PM, Brian E Carpenter wrote:
>> 
>
> Using the DHCPv6 route option, even if it is approved, to solve this 
> problem is unnecessary and, I would claim, harmful.   What you should 
> actually do is clear the A bit on one of the two advertised prefixes, 
> and also set the M bit in the RA message.   Now you can trivially 
> control which hosts use the second prefix, using DHCP, which prevents 
> broken hosts from autoconfiguring addresses on it.
>
> 
>


--------------020604050301050109090706
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit




  


When you write "trivially control", what's the refresh/flush mechanism
to inform end nodes of a (link) status change?



Setting low values for DHCPv6 lifetimes so each host individually and
regularly pulls the new DHCP settings via renew and rebind messages?

DHCPv6 reconfigure message via a push to each host individually via
unicast?

RA PIO valid lifetime = 0?



In my customers, it's highly likely that there'll be a pair of
enterprise-wide centrally-managed highly-available DHCPv6 servers
located off-site in a central data centre, contacted via a DHCPv6 relay
agent configured on the local site router. I'm not sure how that
off-site DHCPv6 server will know of local link status changes, or
whether it will be reachable whilst links are bouncing. I'm also not
sure it will be practicable to install local DHCPv6 servers per site
(with central content admin). Generally speaking, there are no servers
or technical administrators left on remote sites.



Thanks

RayH



Ted Lemon wrote:


  
  

  
On Nov 21, 2011, at 5:25 PM, Brian E Carpenter wrote:

  
<snip>

  

  

  
Using the DHCPv6 route option, even if it is approved, to solve
this problem is unnecessary and, I would claim, harmful.   What you
should actually do is clear the A bit on one of the two advertised
prefixes, and also set the M bit in the RA message.   Now you can
trivially control which hosts use the second prefix, using DHCP, which
prevents broken hosts from autoconfiguring addresses on it.

  


  

<snip>
  


  








--------------020604050301050109090706--

From Ted.Lemon@nominum.com  Fri Nov 25 09:44:04 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23BC521F8B1A for ; Fri, 25 Nov 2011 09:44:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.577
X-Spam-Level: 
X-Spam-Status: No, score=-106.577 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 K5c8OBYm+QhB for ; Fri, 25 Nov 2011 09:44:03 -0800 (PST)
Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 57C1221F8B18 for ; Fri, 25 Nov 2011 09:44:03 -0800 (PST)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKTs/T4eASFFxSStOmEwH7J69bDzT44Xlt@postini.com; Fri, 25 Nov 2011 09:44:03 PST
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 24B271B813F for ; Fri, 25 Nov 2011 09:44:01 -0800 (PST)
Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 749BC190052; Fri, 25 Nov 2011 09:43:58 -0800 (PST) (envelope-from Ted.Lemon@nominum.com)
Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.01.0339.001; Fri, 25 Nov 2011 09:43:58 -0800
From: Ted Lemon 
To: Ole Troan 
Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
Thread-Index: AcypXX65hiQDlw7m00i9I5kWpNL4DwAE4MQQAC75CgAAIE/uAAAFnFOAADTSzoAAAVefgAACUfaAAABQnQAAA92WgAAByXeAAAedOQA=
Date: Fri, 25 Nov 2011 17:43:58 +0000
Message-ID: 
References:    <2963F168-45CB-4042-8238-56DF538B0543@gmail.com>   <2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org> <7177275A-54B7-4390-9F40-2BE17DCBB152@gmail.com> <5DF1AC5D-A4D5-4812-B220-D6BB95E7C65C@employees.org>
In-Reply-To: <5DF1AC5D-A4D5-4812-B220-D6BB95E7C65C@employees.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.1.10]
Content-Type: multipart/alternative; boundary="_000_AEAEC8C970BF4D06B2FD0B6BD85EC909nominumcom_"
MIME-Version: 1.0
Cc: IPv6 Operations 
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-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: Fri, 25 Nov 2011 17:44:04 -0000

--_000_AEAEC8C970BF4D06B2FD0B6BD85EC909nominumcom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

On Nov 25, 2011, at 9:05 AM, Ole Troan wrote:
2) do an update of 3315/3633. I don't know if the DHC chairs have any plans=
 for that? or if it just takes some volunteers to get started...

There's been talk.   We have some thinking to do first.


--_000_AEAEC8C970BF4D06B2FD0B6BD85EC909nominumcom_
Content-Type: text/html; charset="us-ascii"
Content-ID: <9BDBFFA860A7EE48A4D5E98C8CE563AC@nominum.com>
Content-Transfer-Encoding: quoted-printable









On Nov 25, 2011, at 9:05 AM, Ole Troan wrote:


2)
 do an update of 3315/3633. I don't know if the DHC chairs have any plans f=
or that? or if it just takes some volunteers to get started...








There's been talk.   We have some thinking to do first.









--_000_AEAEC8C970BF4D06B2FD0B6BD85EC909nominumcom_--

From shemant@cisco.com  Fri Nov 25 09:48:26 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE79D21F8B3C for ; Fri, 25 Nov 2011 09:48:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.289
X-Spam-Level: 
X-Spam-Status: No, score=-6.289 tagged_above=-999 required=5 tests=[AWL=0.310,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IsKE-xi+AHHN for ; Fri, 25 Nov 2011 09:48:26 -0800 (PST)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1A53821F8B3B for ; Fri, 25 Nov 2011 09:48:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=2614; q=dns/txt; s=iport; t=1322243306; x=1323452906; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=mzVLitpkPsmMHbo/hc0BAjDlcVDMR8VKX9DnArahwMw=; b=QCMNKc3JtXT4o1pmJnNuo3wAKsJLyxGR9Dwp72tva82p1XxJVEFT1nsy ywOThrc5cP2VIjK4ttnjgaQj8kSmgp8LlM0hT38WrS7NYd5qKBA0gtKlK OMTNw7rfBfELmSSqdyLDmjJpJSO40DDQbZydXovoWdayNThhL/6X0iLZi U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqMAADjUz06tJV2d/2dsb2JhbABEmk2QMoEFgXIBAQEEEgEdCj8MBAIBCBEEAQELBhcBBgFFCQgBAQQBEggan2gBngiJf2MEiCGeUw
X-IronPort-AV: E=Sophos;i="4.69,572,1315180800"; d="scan'208";a="38984818"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 25 Nov 2011 17:48:25 +0000
Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id pAPHmPM9032621;  Fri, 25 Nov 2011 17:48:25 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 25 Nov 2011 11:48:25 -0600
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 25 Nov 2011 11:48:24 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF298@XMB-RCD-109.cisco.com>
In-Reply-To: <8DC6BEAC-EF4F-4C39-A9A0-98848CF0234B@townsley.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] 6rd Sunsetting
Thread-Index: AcyqNSY7uJKOXtnFT3CX4Ly8rg+XnQBYZslg
References:  <8DC6BEAC-EF4F-4C39-A9A0-98848CF0234B@townsley.net>
From: "Hemant Singh (shemant)" 
To: "Mark Townsley" , "Wes Beebee (wbeebee)" 
X-OriginalArrivalTime: 25 Nov 2011 17:48:25.0334 (UTC) FILETIME=[6E747160:01CCAB9A]
Cc: Alexandre Cassen , v6ops@ietf.org, Claire Cheng 
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 25 Nov 2011 17:48:26 -0000

Mark,

-----Original Message-----
From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
Of Mark Townsley
Sent: Wednesday, November 23, 2011 6:11 PM
To: Wes Beebee (wbeebee)
Cc: Alexandre Cassen; v6ops@ietf.org; Claire Cheng
Subject: Re: [v6ops] 6rd Sunsetting


>This sounds about right. I think we should be more explicit about the
"when" and "active" part in the last line though, as that's the >crux of
the issue around what to do when receiving configuration for 6rd and
native interfaces on the same router. If the router shuts >off 6rd
prematurely (IMHO, before the ISP says its OK by no longer providing
config), then it risks blackholing traffic from other CEs. =20

Thanks for the review.  In rfc6204bis it was deliberate that bullet 5 in
section 4.4.3 only deals with concurrent operation rules for 6rd and
native IPv6.  How the CE router enters concurrent operation to phase out
6rd is in the subsequent paragraph below the bullets.  The paragraph
assumes 6rd is deprecated immediately on the CE router on acquiring
native IPv6 addressing. This is what Fred Baker also said on the
subject.=20

"I think the argument for thinking about routing is to direct traffic to
the wider PMTU when possible and to have native deployment obsolete 6rd
deployment quickly."=20

We can discuss if immediate deprecation is not required what does the CE
router do.  The cue has to come from the SP and the townsley 6rd
sunsetting document specifies how the SP cue is signaled.  I have some
thought on the SP cue that I can discuss with you offline and contribute
text to the 6rd sunsetting document.


>I'd be more comfortable with 6rd simply falling in line with general
advice on multihoming with multiple prefixes. It's really the same
>case.=20

Totally agree.  That is why we have a simplistic source-based switching
rule in bullet 5 specified for the real cheap CE router.  The general
case of multihoming with different multiple prefixes is solved by PBR
that operates on the source-address bit. =20

>Homenet Chair Nit: By specifying what should happen with routers and
hosts on the LAN side, we're dipping a bit into homenet territory. >As
long as it's consistent with what homenet ends up with, no harm no foul,
but I'd hate to jump the gun.=20

Agree with being consistent with homenet.  Please note rfc6204 is a
single router WAN and LAN specification and rfc6204bis has continued on
the same path.  Thus rfc6204bis is legal to specify LAN behavior.  Thus
it would be good for the homenet folks to review bullet 6.

Thanks,

Hemant

From mark@townsley.net  Fri Nov 25 17:09:04 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B022F21F889A for ; Fri, 25 Nov 2011 17:09:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.443
X-Spam-Level: 
X-Spam-Status: No, score=-3.443 tagged_above=-999 required=5 tests=[AWL=0.156,  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 bIKF4NQGuck5 for ; Fri, 25 Nov 2011 17:09:04 -0800 (PST)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id DBA0421F87C5 for ; Fri, 25 Nov 2011 17:09:03 -0800 (PST)
Received: by wwp14 with SMTP id 14so3578854wwp.13 for ; Fri, 25 Nov 2011 17:08:59 -0800 (PST)
Received: by 10.227.207.146 with SMTP id fy18mr19315286wbb.18.1322269739820; Fri, 25 Nov 2011 17:08:59 -0800 (PST)
Received: from ams-townsley-8712.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id fg15sm5920314wbb.7.2011.11.25.17.08.55 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 25 Nov 2011 17:08:56 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Mark Townsley 
In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF298@XMB-RCD-109.cisco.com>
Date: Sat, 26 Nov 2011 02:08:54 +0100
Content-Transfer-Encoding: 7bit
Message-Id: 
References:  <8DC6BEAC-EF4F-4C39-A9A0-98848CF0234B@townsley.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF298@XMB-RCD-109.cisco.com>
To: "Hemant Singh (shemant)" 
X-Mailer: Apple Mail (2.1084)
Cc: Alexandre Cassen , v6ops@ietf.org, Claire Cheng 
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 26 Nov 2011 01:09:04 -0000

On Nov 25, 2011, at 6:48 PM, Hemant Singh (shemant) wrote:

> Mark,
> 
> -----Original Message-----
> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
> Of Mark Townsley
> Sent: Wednesday, November 23, 2011 6:11 PM
> To: Wes Beebee (wbeebee)
> Cc: Alexandre Cassen; v6ops@ietf.org; Claire Cheng
> Subject: Re: [v6ops] 6rd Sunsetting
> 
> 
>> This sounds about right. I think we should be more explicit about the
> "when" and "active" part in the last line though, as that's the >crux of
> the issue around what to do when receiving configuration for 6rd and
> native interfaces on the same router. If the router shuts >off 6rd
> prematurely (IMHO, before the ISP says its OK by no longer providing
> config), then it risks blackholing traffic from other CEs.  
> 
> Thanks for the review.  In rfc6204bis it was deliberate that bullet 5 in
> section 4.4.3 only deals with concurrent operation rules for 6rd and
> native IPv6.  How the CE router enters concurrent operation to phase out
> 6rd is in the subsequent paragraph below the bullets.  The paragraph
> assumes 6rd is deprecated immediately on the CE router on acquiring
> native IPv6 addressing. This is what Fred Baker also said on the
> subject. 
> 
> "I think the argument for thinking about routing is to direct traffic to
> the wider PMTU when possible and to have native deployment obsolete 6rd
> deployment quickly." 

"when possible" and "quickly" != immediately 

> 
> We can discuss if immediate deprecation is not required what does the CE
> router do.  

I think it is a lot simpler if the router just does what it is told. 

> The cue has to come from the SP and the townsley 6rd
> sunsetting document specifies how the SP cue is signaled.  I have some
> thought on the SP cue that I can discuss with you offline and contribute
> text to the 6rd sunsetting document.

OK. I hope it does not involve changes to RFC 5969 though.

- Mark

> 
> 
>> I'd be more comfortable with 6rd simply falling in line with general
> advice on multihoming with multiple prefixes. It's really the same
>> case. 
> 
> Totally agree.  That is why we have a simplistic source-based switching
> rule in bullet 5 specified for the real cheap CE router.  The general
> case of multihoming with different multiple prefixes is solved by PBR
> that operates on the source-address bit.  
> 
>> Homenet Chair Nit: By specifying what should happen with routers and
> hosts on the LAN side, we're dipping a bit into homenet territory. >As
> long as it's consistent with what homenet ends up with, no harm no foul,
> but I'd hate to jump the gun. 
> 
> Agree with being consistent with homenet.  Please note rfc6204 is a
> single router WAN and LAN specification and rfc6204bis has continued on
> the same path.  Thus rfc6204bis is legal to specify LAN behavior.  Thus
> it would be good for the homenet folks to review bullet 6.
> 
> Thanks,
> 
> Hemant


From ales.vizdal@t-mobile.cz  Sat Nov 26 14:02:09 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4947621F8BF0 for ; Sat, 26 Nov 2011 14:02:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.95
X-Spam-Level: 
X-Spam-Status: No, score=-0.95 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, 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 Rw6pGZs7TZZa for ; Sat, 26 Nov 2011 14:02:08 -0800 (PST)
Received: from mailhub1.t-mobile.cz (mailhub1.t-mobile.cz [62.141.0.149]) by ietfa.amsl.com (Postfix) with ESMTP id 5AEF021F8B92 for ; Sat, 26 Nov 2011 14:02:08 -0800 (PST)
Received: from srvhk504.rdm.cz (unknown [10.246.143.96]) by mailhub1.t-mobile.cz (Postfix) with ESMTP id 937742857E0; Sat, 26 Nov 2011 23:02:02 +0100 (CET)
Received: from SRVHKE02.rdm.cz ([fe80::94ce:8456:f6fa:86a8]) by srvhk504.rdm.cz ([fe80::506:b9a6:d353:9494%12]) with mapi; Sat, 26 Nov 2011 23:02:02 +0100
From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= 
To: Ole Troan , jouni korhonen 
Date: Sat, 26 Nov 2011 23:01:48 +0100
Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
Thread-Index: AcyrZM6Op71ZUQDvQZGUHCE73sbQ2wBHO07Q
Message-ID: <1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz>
References:    <2963F168-45CB-4042-8238-56DF538B0543@gmail.com>   <2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org>
In-Reply-To: <2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-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: Sat, 26 Nov 2011 22:02:09 -0000

Hi Ole, Jouni,

> -----Original Message-----
> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of=
 Ole
> Troan
> Sent: Friday, November 25, 2011 12:24 PM
> To: jouni korhonen
> Cc: v6ops@ietf.org
> Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
>=20
> Jouni,
>=20
> >>> In addition to exclude, probably relaxing MUST for IA_NA (WAA-4) when=
 the
> stateful address configuration is not plain supported on WAN link. I want=
 to have a
> confidence for the case where a CE has e.g. a LTE as a backup for fixed c=
onnection,
> the CE does not try to acquire its WAN interface address using DHCPv6 whe=
n it
> switches to LTE... and then get stuck/confused.
> >>
> >> I don't see how this case is any different than any other WAN link whe=
re address
> assignment isn't done with DHCP?
> >> the requirement in WAA-4 only says "MUST be capable of".
> >
> > So you are saying "MUST be able to support" does not mandate me to impl=
ement
> something? If that is the case, then fine.
>=20
> no, I'm saying it doesn't say you MUST request an IA_NA on the interface.
> with regards to implementation I presume you have to do IA_NA on e.g. wir=
eless
> interfaces anyway.

I have the same concern as Jouni that the IPv6 CE router (e.g. Mi-Fi device=
) having a 3GPP access=20
based WAN link only would be required to support the IA_NA option on the WA=
N link to be able to be
compliant to this RFC (I am saying on the WAN link, because this requiremen=
t is placed under the WAA=20
- WAN Address Allocation section).=20

So carefully relaxing it for non-DHCPv6 based address allocation would help=
 to avoid potential=20
confusion later.

Would it be possible to use something along the lines of 'The IPv6 CE route=
r MUST be able to support=20
the following DHCPv6 options (if DHCPv6 based address allocation supported =
on the WAN link)' as=20
written below?

   WAA-4:  The IPv6 CE router MUST be able to support the following DHCPv6 =
options=20
	(if DHCPv6 based address allocation supported on the WAN link): IA_NA,=20
	Reconfigure Accept [RFC3315], and DNS_SERVERS [RFC3646]. The IPv6 CE=20
	router SHOULD be able to support the DNS Search List DNSSL option as specf=
ied*=20
	in [RFC6106].

* there seems to be a typo - specified

> cheers,
> Ole

Cheers,
Ales

From internet-drafts@ietf.org  Sat Nov 26 16:53:11 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9AD421F85A4; Sat, 26 Nov 2011 16:53:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.587
X-Spam-Level: 
X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 Gh5StBUvTO1G; Sat, 26 Nov 2011 16:53:11 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26CCD21F8551; Sat, 26 Nov 2011 16:53:11 -0800 (PST)
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: 3.64
Message-ID: <20111127005311.10679.35441.idtracker@ietfa.amsl.com>
Date: Sat, 26 Nov 2011 16:53:11 -0800
Cc: v6ops@ietf.org
Subject: [v6ops] I-D Action: draft-ietf-v6ops-wireline-incremental-ipv6-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, 27 Nov 2011 00:53:11 -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-00.txt
	Pages           : 24
	Date            : 2011-11-26

   Operators worldwide are in various stages of preparing for, or
   deploying IPv6 into their networks.  The operators often face
   challenges related to both IPv6 introduction along with a growing
   risk of IPv4 run out within their organizations.  The overall problem
   for many operators will be to meet the simultaneous needs of IPv6
   connectivity and continue support for IPv4 connectivity for legacy
   devices and systems with a depleting supply of IPv4 addresses.  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 Wireline providers who may be faced with many of these challenges
   as they consider what IPv6 transition technologies to use, how to use
   the selected technologies and when to use them.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-wireline-incremental-i=
pv6-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-v6ops-wireline-incremental-ip=
v6-00.txt


From mark@townsley.net  Sun Nov 27 04:51:49 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6D4E21F8586 for ; Sun, 27 Nov 2011 04:51:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.448
X-Spam-Level: 
X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=0.150,  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 q6NLS0Cdq2ea for ; Sun, 27 Nov 2011 04:51:49 -0800 (PST)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB2D21F8770 for ; Sun, 27 Nov 2011 04:51:48 -0800 (PST)
Received: by wwp14 with SMTP id 14so5380647wwp.13 for ; Sun, 27 Nov 2011 04:51:43 -0800 (PST)
Received: by 10.227.206.82 with SMTP id ft18mr26098680wbb.21.1322398303184; Sun, 27 Nov 2011 04:51:43 -0800 (PST)
Received: from ams-townsley-8712.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id 6sm22345454wby.22.2011.11.27.04.51.38 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 27 Nov 2011 04:51:39 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-27-493712345
From: Mark Townsley 
In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF285@XMB-RCD-109.cisco.com>
Date: Sun, 27 Nov 2011 13:51:35 +0100
Message-Id: <540B4315-C19D-4D9F-A1E8-683A2C70E292@townsley.net>
References: <68DAB112-6E32-45FE-9AB7-A34E64898F60@cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C30354436E@XMB-RCD-109.cisco.com><750BF7861EBBE048B3E648B4BB6E8F4F20DC41F6@crexc50p><252D3DEA-FF09-42C8-959E-8A7205D9DE67@townsley.net><20111122133612.GH71280@Space.Net>  <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF226@XMB-RCD-109.cisco.com>  <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF285@XMB-RCD-109.cisco.com>
To: Hemant Singh (shemant) 
X-Mailer: Apple Mail (2.1084)
Cc: Alexandre Cassen , Claire Cheng , v6ops@ietf.org
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 27 Nov 2011 12:51:50 -0000

--Apple-Mail-27-493712345
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


On Nov 25, 2011, at 5:44 PM, Hemant Singh (shemant) wrote:

> =20
> From: Mark Townsley [mailto:mark@townsley.net]=20
> Sent: Friday, November 25, 2011 1:08 AM
> To: Hemant Singh (shemant)
> Cc: Lorenzo Colitti; Claire Cheng; v6ops@ietf.org; Alexandre Cassen
> Subject: Re: [v6ops] 6rd Sunsetting
> =20
> =20
> >The *native* IPv6 network. No BR in the native IPv6 network.=20
>=20
> It would be good to mention such details.  No further discussion is =
possible unless a network topology diagram is presented and then we can =
discuss what node sends and what node drops packets.

Seriously?  Why would a native IPv6 network need a 6rd Border Relay (BR) =
function.=20

> =20
> >I think you are confused.
> =20
> Given the short text Lorenzo sent out with no diagram one can=92t even =
verify what the problem is.
> =20
> >Lorenzo is saying that if you send a packet from a subscriber into =
the native IPv6 network with a source address that does not match a =
delegated prefix for that subscriber, it is >likely to be dropped by the =
native IPv6 network.=20
> =20
> The CE router has a 6rd prefix and possibly a native IPv6 different =
prefix.  Why are routes for such prefixes not injected in the network =
northbound?=20

Because of the additional overhead of doing so.

> That is why a network diagram would be useful for any further =
conversation.

> =20
> >No, BRs do not send RAs to CEs. BRs have no state, and may be =
multiple L3 hops away from the CE.=20
> =20
> >Are you are confusing "BR" and "BNG"?
> =20
> BNG and BR are co-resident.=20

Absolutely not.=20

The 6rd BR function, whether within the BNG or not (and in today's =
deployments it typically is not), is entirely separate from the BNG =
functionality.=20

> Even if they are not, the BNG sends the RA and the BNG routing =
propagates new routes for a different prefix in the northbound BR. =20

You could if you wanted to, but that's additional state.=20

Still, if a packet arrives over the 6rd tunnel with anything by a 6rd =
source prefix, the 6rd security check is going to drop the packet. =
Bypassing this check opens a security hole, and requires lots of state =
to close it back up properly.

- Mark

>=20
> Hemant
> =20


--Apple-Mail-27-493712345
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252


On Nov 25, 2011, at 5:44 PM, Hemant =
Singh (shemant) wrote:

From: Mark Townsley =
[mailto:mark@townsley.net] 
Sent: Friday, November 25, 2011 =
1:08 AM
To: Hemant Singh =
(shemant)
Cc: Lorenzo Colitti; Claire =
Cheng; v6ops@ietf.org; Alexandre =
Cassen
Subject: Re: [v6ops] 6rd =
Sunsetting
>The *native* IPv6 network. No BR in the =
native IPv6 network. 

It would be good to mention such =
details.  No further discussion is possible unless a network =
topology diagram is presented and then we can discuss what node sends =
and what node drops =
packets.

Seriously?  Why would a native IPv6 network need a 6rd =
Border Relay (BR) function. 

>I think you are confused.
Given the short text Lorenzo sent out with no =
diagram one can=92t even verify what the problem =
is.
 
 >likely to be dropped by the native IPv6 =
network. 
 
The CE router has a 6rd prefix =
and possibly a native IPv6 different prefix.  Why are routes for =
such prefixes not injected in the network northbound?  =


Because of the additional overhead of doing so.

That is why a network =
diagram would be useful for any further =
conversation.

>Are you are confusing "BR" and =
"BNG"?
 
BNG and BR are =
co-resident.  =


Absolutely not. 

The 6rd BR function, =
whether within the BNG or not (and in today's deployments it typically =
is not), is entirely separate from the BNG =
functionality. 

Even if =
they are not, the BNG sends the RA and the BNG routing propagates new =
routes for a different prefix in the northbound =
BR.  

You could if you wanted to, but that's additional =
state. 

Still, if a packet arrives over =
the 6rd tunnel with anything by a 6rd source prefix, the 6rd security =
check is going to drop the packet. Bypassing this check opens a security =
hole, and requires lots of state to close it back up =
properly.

- Mark



Message-Id: <201111271455.pAREt0614120@ftpeng-update.cisco.com>
To: v6ops@ietf.org
Cc: draft-ietf-v6ops-wireline-incremental-ipv6@tools.ietf.org
Subject: [v6ops] new draft: draft-ietf-v6ops-wireline-incremental-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, 27 Nov 2011 14:55:04 -0000

A new draft has been posted, at http://tools.ietf.org/html/draft-ietf-v6ops-wireline-incremental-ipv6. Please take a look at it and comment.

From shemant@cisco.com  Sun Nov 27 09:05:47 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55EAB21F8BD5 for ; Sun, 27 Nov 2011 09:05:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.142
X-Spam-Level: 
X-Spam-Status: No, score=-6.142 tagged_above=-999 required=5 tests=[AWL=0.157,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 QL08+RjWqoPu for ; Sun, 27 Nov 2011 09:05:46 -0800 (PST)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9E40621F8BB7 for ; Sun, 27 Nov 2011 09:05:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=1163; q=dns/txt; s=iport; t=1322413546; x=1323623146; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=s+mnvlm/NLnGnLTUQXRGLcr3mGQKXU7hLKxsgL/E0c8=; b=KdQzdNnjt/n7LIcAzRsaFOU+hs/YFylnJnmzrn6v/1/QiJjGc/RoWObI bk9hVe2nVTVaCFPc3kHj/S91ND3PsDcLLJBG7DShuQls0sAci20/70bSA Z+XmY1hqF2IFHOjPUxkMwpqnM3atWsCBg280BdBxY0QVzWRXF9iv2MR0s k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApgAAAlt0k6tJV2a/2dsb2JhbABEmlKQMIEFgXIBAQEBAxIBHUkMBAIBCBEEAQELBhcBBgFFCQgBAQQBEgganxMBnTyJf2MEiCGeUw
X-IronPort-AV: E=Sophos;i="4.69,579,1315180800"; d="scan'208";a="39214761"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 27 Nov 2011 17:05:46 +0000
Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pARH5khf025245;  Sun, 27 Nov 2011 17:05:46 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Sun, 27 Nov 2011 11:05:45 -0600
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
Date: Sun, 27 Nov 2011 11:05:43 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com>
In-Reply-To: <1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
Thread-Index: AcyrZM6Op71ZUQDvQZGUHCE73sbQ2wBHO07QACkJ/mA=
References: <2963F168-45CB-4042-8238-56DF538B0543@gmail.com><2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz>
From: "Hemant Singh (shemant)" 
To: =?iso-8859-2?B?Vu16ZGFsIEFsZbk=?= , "Ole Troan" , "jouni korhonen" 
X-OriginalArrivalTime: 27 Nov 2011 17:05:45.0535 (UTC) FILETIME=[CD859CF0:01CCAD26]
Cc: v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-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: Sun, 27 Nov 2011 17:05:47 -0000

Vizdal,

-----Original Message-----
From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf =
Of V=EDzdal Ale=B9
Sent: Saturday, November 26, 2011 5:02 PM
To: Ole Troan; jouni korhonen
Cc: v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt


>I have the same concern as Jouni that the IPv6 CE router (e.g. Mi-Fi =
device) having a 3GPP access=20
>based WAN link only would be required to support the IA_NA option on =
the WAN link to be able to be
>compliant to this RFC (I am saying on the WAN link, because this =
requirement is placed under the WAA=20
>- WAN Address Allocation section).=20

The rfc6204bis document only supports a cellular client for DHCPv6 PD.  =
Thus any legacy 3GPP cellular client that does not support DHCPv6 PD =
acquisition is not supported by rfc6204bis.  Thereafter if the cellular =
client supports DHCPv6 PD, the device already supports the IA_PD option, =
so what is the big deal for the client to also support the IA_NA option =
but the client does not use this option?  Thanks for catching the =
spelling error for "specified".  It has been fixed.

Hemant


From shemant@cisco.com  Sun Nov 27 09:17:19 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD2BC21F8C18 for ; Sun, 27 Nov 2011 09:17:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.293
X-Spam-Level: 
X-Spam-Status: No, score=-6.293 tagged_above=-999 required=5 tests=[AWL=0.305,  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 R0fbFF7nd23c for ; Sun, 27 Nov 2011 09:17:19 -0800 (PST)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id CAFEF21F8B4B for ; Sun, 27 Nov 2011 09:17:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=5732; q=dns/txt; s=iport; t=1322414238; x=1323623838; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=9vxZmC2ftpbZfRq6XzeDQRCpG9ldkwaUf109O+cAaOo=; b=bSywftsyGe7xseFc2KcIgNxtebXpl4dX/05DRhSZ3Oj47huVHicLub1h pN3Q/ztQYVDkDxm59Qmbeq38yK00jOM+R/Gpt90EwxKQKhJP7A3uarOIA mHmlyq1quByKTQvwFZQX7OerRWgsHu/NAchAmu0kBMX9c8T5Xf5h4syAd I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApkAANZv0k6tJXG9/2dsb2JhbABEgk2YBZAwgQWBcgEBAQEDEgEJEQNJEAIBCBEEAQELBhcBBgFFCQgBAQQTCBqfBgGdO4l/YwSIIZ5T
X-IronPort-AV: E=Sophos;i="4.69,579,1315180800"; d="scan'208,217";a="39211758"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-4.cisco.com with ESMTP; 27 Nov 2011 17:17:18 +0000
Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id pARHHIZW016414;  Sun, 27 Nov 2011 17:17:18 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Sun, 27 Nov 2011 11:17:17 -0600
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCAD28.6A2DA948"
Date: Sun, 27 Nov 2011 11:17:17 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30D@XMB-RCD-109.cisco.com>
In-Reply-To: <540B4315-C19D-4D9F-A1E8-683A2C70E292@townsley.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] 6rd Sunsetting
Thread-Index: AcytA1EYu9M7pSu6TbKmOWsrUchapQAI5yWg
References: <68DAB112-6E32-45FE-9AB7-A34E64898F60@cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C30354436E@XMB-RCD-109.cisco.com><750BF7861EBBE048B3E648B4BB6E8F4F20DC41F6@crexc50p><252D3DEA-FF09-42C8-959E-8A7205D9DE67@townsley.net><20111122133612.GH71280@Space.Net>  <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF226@XMB-RCD-109.cisco.com>  <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF285@XMB-RCD-109.cisco.com> <540B4315-C19D-4D9F-A1E8-683A2C70E292@townsley.net>
From: "Hemant Singh (shemant)" 
To: "Mark Townsley" 
X-OriginalArrivalTime: 27 Nov 2011 17:17:17.0997 (UTC) FILETIME=[6A42EDD0:01CCAD28]
Cc: Alexandre Cassen , Claire Cheng , v6ops@ietf.org
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 27 Nov 2011 17:17:20 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CCAD28.6A2DA948
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

=20

From: Mark Townsley [mailto:mark@townsley.net]=20
Sent: Sunday, November 27, 2011 7:52 AM
To: Hemant Singh (shemant)
Cc: Lorenzo Colitti; Claire Cheng; v6ops@ietf.org; Alexandre Cassen
Subject: Re: [v6ops] 6rd Sunsetting

=20

>>BNG and BR are co-resident. =20

=20

>Absolutely not.

=20

Why is it absolutely not?  What document or technical problems prohibits
one from including the BR in the BNG?  Anyway, if the BR and the BNG are
not co-resident,  what protocol exists between the BR and the BNG to
sunset 6rd?  Which of BR or the BNG signals start of 6rd sunsetting and
then how does the BR/BNG get notified?   If a protocol is not used one
has to use ad hoc means to coordinate the sunsetting between devices in
the SP domain.  Let's specify the ad hoc steps or the protocol. =20

=20

Hemant

=20

=20

=20


------_=_NextPart_001_01CCAD28.6A2DA948
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


 
From:=
 =
Mark Townsley [mailto:mark@townsley.net] 
Sent: Sunday, =
November 27, 2011 7:52 AM
To: Hemant Singh =
(shemant)
Cc: Lorenzo Colitti; Claire Cheng; v6ops@ietf.org; =
Alexandre Cassen
Subject: Re: [v6ops] 6rd =
Sunsetting
 
>>BNG and BR are co-resident.  =

 
>Absolutely =
not.
 
Why is it absolutely not?  What document or technical problems =
prohibits one from including the BR in the BNG?  Anyway, if the BR =
and the BNG are not co-resident,  what protocol exists between the =
BR and the BNG to sunset 6rd?  Which of BR or the BNG signals start =
of 6rd sunsetting and then how does the BR/BNG get notified?  =
 If a protocol is not used one has to use ad hoc means to =
coordinate the sunsetting between devices in the SP domain.  =
Let’s specify the ad hoc steps or the protocol. =
 
 
Hemant
 
 
 

------_=_NextPart_001_01CCAD28.6A2DA948--

From Tina.Tsou.Zouting@huawei.com  Sun Nov 27 10:23:15 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97BA821F87C5 for ; Sun, 27 Nov 2011 10:23:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.082
X-Spam-Level: 
X-Spam-Status: No, score=-6.082 tagged_above=-999 required=5 tests=[AWL=0.516,  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 vFcLhLBcm4YQ for ; Sun, 27 Nov 2011 10:23:15 -0800 (PST)
Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id C43BC21F877F for ; Sun, 27 Nov 2011 10:23:14 -0800 (PST)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LVC003790EJSN@szxga04-in.huawei.com> for v6ops@ietf.org; Mon, 28 Nov 2011 02:23:07 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LVC002D70EJGZ@szxga04-in.huawei.com> for v6ops@ietf.org; Mon, 28 Nov 2011 02:23:07 +0800 (CST)
Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AFI18015; Mon, 28 Nov 2011 02:23:04 +0800
Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 28 Nov 2011 02:23:04 +0800
Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.40]) by szxeml403-hub.china.huawei.com ([10.82.67.35]) with mapi id 14.01.0323.003; Mon, 28 Nov 2011 02:22:40 +0800
Date: Sun, 27 Nov 2011 18:22:39 +0000
From: Tina TSOU 
In-reply-to: <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30D@XMB-RCD-109.cisco.com>
To: "Hemant Singh (shemant)" 
Message-id: <664DDE6A-43B3-4B4E-8318-6B31F58543C4@huawei.com>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_Fx+JB1nMzGXM/2hKrkzbMQ)"
Content-language: en-US
Accept-Language: en-US, zh-CN
Thread-topic: [v6ops] 6rd Sunsetting
Thread-index: AQHMo2zkiVaVmflTEk2DrH6PcFso4ZWtESmAgAF9cYCAACEjgIABVu+AgAfhuoCAADwWAIAAAlqAgABDmgCAABLvAIACYfoAgAEsZYCAAJiPgIAAsaMAgALjsICAAEo9gIAAmGCp
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
References:   <68DAB112-6E32-45FE-9AB7-A34E64898F60@cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30354436E@XMB-RCD-109.cisco.com> <750BF7861EBBE048B3E648B4BB6E8F4F20DC41F6@crexc50p>  <252D3DEA-FF09-42C8-959E-8A7205D9DE67@townsley.net>  <20111122133612.GH71280@Space.Net>   <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF226@XMB-RCD-109.cisco.com>  <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF285@XMB-RCD-109.cisco.com> <540B4315-C19D-4D9F-A1E8-683A2C70E292@townsley.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30D@XMB-RCD-109.cisco.com>
Cc: Alexandre Cassen , "v6ops@ietf.org" , Claire Cheng 
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 27 Nov 2011 18:23:15 -0000

--Boundary_(ID_Fx+JB1nMzGXM/2hKrkzbMQ)
Content-type: text/plain; charset=Windows-1252
Content-transfer-encoding: quoted-printable

Same questions here.

Sent from my iPad

On Nov 27, 2011, at 7:17 AM, "Hemant Singh (shemant)" > wrote:


From: Mark Townsley [mailto:mark@townsley.net]
Sent: Sunday, November 27, 2011 7:52 AM
To: Hemant Singh (shemant)
Cc: Lorenzo Colitti; Claire Cheng; v6ops@ietf.org; A=
lexandre Cassen
Subject: Re: [v6ops] 6rd Sunsetting

>>BNG and BR are co-resident.

>Absolutely not.

Why is it absolutely not?  What document or technical problems prohibits on=
e from including the BR in the BNG?  Anyway, if the BR and the BNG are not =
co-resident,  what protocol exists between the BR and the BNG to sunset 6rd=
?  Which of BR or the BNG signals start of 6rd sunsetting and then how does=
 the BR/BNG get notified?   If a protocol is not used one has to use ad hoc=
 means to coordinate the sunsetting between devices in the SP domain.  Let=
=92s specify the ad hoc steps or the protocol.

Hemant




--Boundary_(ID_Fx+JB1nMzGXM/2hKrkzbMQ)
Content-type: text/html; charset=Windows-1252
Content-transfer-encoding: quoted-printable







Same questions here.



Sent from my iPad




On Nov 27, 2011, at 7:17 AM, "Hemant Singh (shemant)" <shemant@cisco.com> wrote:














 <=
/p>





From: Mark Tow=
nsley [mailto:mark@townsley.net]


Sent: Sunday, November 27, 2011 7:52 AM

To: Hemant Singh (shemant)

Cc: Lorenzo Colitti; Claire Cheng; v6ops@ietf.org; Alexandre Cassen

Subject: Re: [v6ops] 6rd Sunsetting






 










>>=
BNG and BR are co-resident. 











 






>Absolutely =
not.


 <=
/p>

Why is it absolutely not?=
  What document or technical problems prohibits one from including the=
 BR in the BNG?  Anyway, if the BR and the BNG are not co-resident,
  what protocol exists between the BR and the BNG to sunset 6rd? =
 Which of BR or the BNG signals start of 6rd sunsetting and then how does t=
he BR/BNG get notified?   If a protocol is not used one has to us=
e ad hoc means to coordinate the sunsetting between
 devices in the SP domain.  Let=92s specify the ad hoc steps or the pr=
otocol.  


 <=
/p>

Hemant<=
/p>

 








 








 
















--Boundary_(ID_Fx+JB1nMzGXM/2hKrkzbMQ)--

From mark@townsley.net  Sun Nov 27 11:46:37 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6339021F8C50 for ; Sun, 27 Nov 2011 11:46:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.894
X-Spam-Level: 
X-Spam-Status: No, score=-2.894 tagged_above=-999 required=5 tests=[AWL=0.104,  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 yoO4JnM2nQm4 for ; Sun, 27 Nov 2011 11:46:36 -0800 (PST)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 377BB21F8C4C for ; Sun, 27 Nov 2011 11:46:35 -0800 (PST)
Received: by bkbzv15 with SMTP id zv15so8001578bkb.31 for ; Sun, 27 Nov 2011 11:46:33 -0800 (PST)
Received: by 10.204.151.144 with SMTP id c16mr8825930bkw.45.1322423193603; Sun, 27 Nov 2011 11:46:33 -0800 (PST)
Received: from ?IPv6:2a01:e35:2ef3:a3f0:66b9:e8ff:fecc:84b0? ([2a01:e35:2ef3:a3f0:66b9:e8ff:fecc:84b0]) by mx.google.com with ESMTPS id q16sm36600418fae.6.2011.11.27.11.46.31 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 27 Nov 2011 11:46:31 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-29-518597875
From: Mark Townsley 
In-Reply-To: <664DDE6A-43B3-4B4E-8318-6B31F58543C4@huawei.com>
Date: Sun, 27 Nov 2011 20:46:21 +0100
Message-Id: <4C468F52-C08B-4B25-86FF-E599F0078946@townsley.net>
References:   <68DAB112-6E32-45FE-9AB7-A34E64898F60@cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30354436E@XMB-RCD-109.cisco.com> <750BF7861EBBE048B3E648B4BB6E8F4F20DC41F6@crexc50p>  <252D3DEA-FF09-42C8-959E-8A7205D9DE67@townsley.net>  <20111122133612.GH71280@Space.Net>   <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF226@XMB-RCD-109.cisco.com>  <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF285@XMB-RCD-109.cisco.com> <540B4315-C19D-4D9F-A1E8-683A2C70E292@townsley.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30D@XMB-RCD-109.cisco.com> <664DDE6A-43B3-4B4E-8318-6B31F58543C4@huawei.c om>
To: Tina TSOU 
X-Mailer: Apple Mail (2.1084)
Cc: Alexandre Cassen , "v6ops@ietf.org" , Claire Cheng 
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 27 Nov 2011 19:46:37 -0000

--Apple-Mail-29-518597875
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


There is nothing to stop the BR from being the same piece of equipment =
as the BNG, but the BR function itself described in RFC 5569 or 5969 is =
not "subscriber aware" by design. The BR and BNG are very much =
functionally separate. I'll note that the deployment at Free and most of =
the others I am aware of today, the BR is a separate box not co-located =
with the BNG. I have seen designs where the plan was to enable BR =
functionality on the BNG over time, and there is nothing wrong with =
that. What I am saying here is that it is "absolutely not" *necessary* =
to make them co-resident.

There is no need for the BR and BNG to communicate directly to sunset =
6rd, and certainly no new protocol to invent here. The steps necessary =
for two methods are outlined in 6rd-sunsetting, and graphically in the =
presentation I rushed through in v6ops (though the slides should be part =
of the proceedings). These are guidelines, leading to the more important =
part: requirements for the CPE. An operator will certainly have its own =
environment to consider, and may move very quickly or very slowly, with =
one prefix or more than one, when sunsetting.

The only "ISP to CE" control protocol needed to turn off 6rd is the same =
needed to turn on 6rd. As described in 6rd-subsetting, If using the =
"same prefix" method (#2 in the draft and my presentation) the operator =
can choose to inject routes into the IGP (or configure static routes) to =
direct downstream traffic towards the native or BR path (when and for =
what level of aggregate to do this is a choice, it is not necessary for =
packets to continue to reach the subscriber). If using the =
"different-prefix" method, then this isn't necessary as 6rd and native =
together "simply" looks like multihoming with distinct routing for each =
prefix until 6rd is no longer available on that CE.=20

Please don't make this more difficult that it is. All we are doing here =
is moving the subscriber from one interface type to another.=20

- Mark

On Nov 27, 2011, at 7:22 PM, Tina TSOU wrote:

> Same questions here.
>=20
> Sent from my iPad
>=20
> On Nov 27, 2011, at 7:17 AM, "Hemant Singh (shemant)" =
 wrote:
>=20
>> =20
>>=20
>> From: Mark Townsley [mailto:mark@townsley.net]=20
>> Sent: Sunday, November 27, 2011 7:52 AM
>> To: Hemant Singh (shemant)
>> Cc: Lorenzo Colitti; Claire Cheng; v6ops@ietf.org; Alexandre Cassen
>> Subject: Re: [v6ops] 6rd Sunsetting
>>=20
>> =20
>>=20
>> >>BNG and BR are co-resident.=20
>>=20
>> =20
>>=20
>> >Absolutely not.
>>=20
>> =20
>>=20
>> Why is it absolutely not?  What document or technical problems =
prohibits one from including the BR in the BNG?  Anyway, if the BR and =
the BNG are not co-resident,  what protocol exists between the BR and =
the BNG to sunset 6rd?  Which of BR or the BNG signals start of 6rd =
sunsetting and then how does the BR/BNG get notified?   If a protocol is =
not used one has to use ad hoc means to coordinate the sunsetting =
between devices in the SP domain.  Let=92s specify the ad hoc steps or =
the protocol. =20
>>=20
>> =20
>>=20
>> Hemant
>>=20
>> =20
>>=20
>> =20
>>=20
>> =20
>>=20
>>=20


--Apple-Mail-29-518597875
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252



There is =
no need for the BR and BNG to communicate directly to sunset 6rd, and =
certainly no new protocol to invent here. The steps necessary for two =
methods are outlined in 6rd-sunsetting, and graphically in the =
presentation I rushed through in v6ops (though the slides should be part =
of the proceedings). These are guidelines, leading to the more important =
part: requirements for the CPE. An operator will certainly have its own =
environment to consider, and may move very quickly or very slowly, with =
one prefix or more than one, when =
sunsetting.

The only "ISP to CE" control =
protocol needed to turn off 6rd is the same needed to turn on 6rd. As =
described in 6rd-subsetting, If using the "same prefix" method (#2 in =
the draft and my presentation) the operator can choose to inject routes =
into the IGP (or configure static routes) to direct downstream traffic =
towards the native or BR path (when and for what level of aggregate to =
do this is a choice, it is not necessary for packets to continue to =
reach the subscriber). If using the "different-prefix" method, then this =
isn't necessary as 6rd and native together "simply" looks like =
multihoming with distinct routing for each prefix until 6rd is no longer =
available on that CE. 

Please don't make =
this more difficult that it is. All we are doing here is moving the =
subscriber from one interface type to =
another. 

- Mark

On Nov =
27, 2011, at 7:22 PM, Tina TSOU wrote:








Same questions here.



Sent from my iPad




On Nov 27, 2011, at 7:17 AM, "Hemant Singh (shemant)" <shemant@cisco.com> wrote:












 




From: Mark Townsley [mailto:mark@townsley.net]


Sent: Sunday, November 27, 2011 7:52 AM

To: Hemant Singh (shemant)

Cc: Lorenzo Colitti; Claire Cheng; v6ops@ietf.org; Alexandre Cassen

Subject: Re: [v6ops] 6rd Sunsetting




 








>>BNG and BR are co-resident. 









 




>Absolutely not.
 
Why is it absolutely not?  What document or =
technical problems prohibits one from including the BR in the BNG?  =
Anyway, if the BR and the BNG are not co-resident,
  what protocol exists between the BR and the BNG to sunset =
6rd?  Which of BR or the BNG signals start of 6rd sunsetting and =
then how does the BR/BNG get notified?   If a protocol is not =
used one has to use ad hoc means to coordinate the sunsetting between
 devices in the SP domain.  Let=92s specify the ad hoc steps or the =
protocol.  
 
Hemant
 






 






 


















=

--Apple-Mail-29-518597875--

From victor.kuarsingh@gmail.com  Sun Nov 27 14:10:53 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A72EF21F8C2D for ; Sun, 27 Nov 2011 14:10:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[AWL=-0.999, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 fPcdLUzWDgX0 for ; Sun, 27 Nov 2011 14:10:51 -0800 (PST)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0D21821F8C2B for ; Sun, 27 Nov 2011 14:10:50 -0800 (PST)
Received: by vbbez10 with SMTP id ez10so4783238vbb.31 for ; Sun, 27 Nov 2011 14:10:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type; bh=PeYZjPOe1DcOIUUosAmLTdIMrHCB2moeeCfozwxYS4I=; b=OVVM8otY/r2YBhGsVi+5NG1VANrHrKQANNVcfY4zBKV/TLWnXZ7uC7M6x9ljaGMDfk RUPF4DxeJnfj1bjqjDtt9DxWtVRZ7mYo7Y8R2fgHQbyB2sx3Fgk6GfsNrovV1rLYiZr0 vK6GXOTJVqLZUgrSRR+3O/DFuPt0YonWRJ0S8=
Received: by 10.52.65.236 with SMTP id a12mr36402468vdt.91.1322431848472; Sun, 27 Nov 2011 14:10:48 -0800 (PST)
Received: from [192.168.200.166] (CPE24ab81b96d12-CM001a666bafe6.cpe.net.cable.rogers.com. [99.230.124.175]) by mx.google.com with ESMTPS id a8sm6928220vdj.11.2011.11.27.14.10.46 (version=SSLv3 cipher=OTHER); Sun, 27 Nov 2011 14:10:47 -0800 (PST)
User-Agent: Microsoft-MacOutlook/14.0.0.100825
Date: Sun, 27 Nov 2011 17:10:43 -0500
From: Victor Kuarsingh 
To: Mark Townsley , Tina TSOU 
Message-ID: 
Thread-Topic: [v6ops] 6rd Sunsetting
In-Reply-To: <4C468F52-C08B-4B25-86FF-E599F0078946@townsley.net>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3405258646_19419188"
Cc: Alexandre Cassen , "v6ops@ietf.org" , Claire Cheng 
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 27 Nov 2011 22:10:53 -0000

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3405258646_19419188
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

**  Biased Operator View **

>There is nothing to stop the BR from being the same piece of equipment as =
the
BNG, but the BR function itself described in >RFC 5569 or 5969 is not
"subscriber aware" by design. The BR and BNG are very much functionally
separate. I'll note that >the deployment at Free and most of the others I a=
m
aware of today, the BR is a separate box not co-located with the BNG. I >ha=
ve
seen designs where the plan was to enable BR functionality on the BNG over =
time,
and there is nothing wrong with >that. What I am saying here is that it is
"absolutely not" *necessary* to make them co-resident.

I would say that the likelihood that BNG and BR are co-resident are not
likely in early 6RD deployments (if ever).  If the BR functionality was
built into the BNG maybe, but I am not sure how common that is today.

What ever we do here should not assume this mode of operation (but as noted=
,
does not preclude it either).  From our point of view, BRs will be planted
in various parts of the network and would be scaled according to load (sinc=
e
there are other functions that an operator may want to co-locate with the B=
R
that would need to scale out too).

Even if the BR was co-resident, the return path of the IPv6 flow may be
serviced by a different BR (since the ingress and egress paths need not be
the same).  This would of course be highly dependant on the operators BR an=
d
routing design.


>There is no need for the BR and BNG to communicate directly to sunset 6rd,=
 and
certainly no new protocol to invent here. >The steps necessary for two meth=
ods
are outlined in 6rd-sunsetting, and graphically in the presentation I rushe=
d
through in >v6ops (though the slides should be part of the proceedings). Th=
ese
are guidelines, leading to the more important part: >requirements for the C=
PE.
An operator will certainly have its own environment to consider, and may mo=
ve
very quickly or >very slowly, with one prefix or more than one, when sunset=
ting.

>Please don't make this more difficult that it is. All we are doing here is
moving the subscriber from one interface type to another.

In my opinion, the simpler the requirements on the CPE the better
(especially when it comes to how the CPE interacts with the network).   You
cannot imagine the /fun/ we have with CPE behaviour today in our networks
(coming from all kinds of places and vendors),  I would suggest too much
more complexity on the CPE would exasperate this.


Victor K



>- Mark

On Nov 27, 2011, at 7:22 PM, Tina TSOU wrote:

> Same questions here.
>=20
> Sent from my iPad
>=20
> On Nov 27, 2011, at 7:17 AM, "Hemant Singh (shemant)" 
> wrote:
>=20
>> =20
>>=20
>> From: Mark Townsley [mailto:mark@townsley.net]
>> Sent: Sunday, November 27, 2011 7:52 AM
>> To: Hemant Singh (shemant)
>> Cc: Lorenzo Colitti; Claire Cheng; v6ops@ietf.org; Alexandre Cassen
>> Subject: Re: [v6ops] 6rd Sunsetting
>> =20
>>=20
>>>> >>BNG and BR are co-resident.
>>=20
>> =20
>>=20
>>> >Absolutely not.
>> =20
>> Why is it absolutely not?  What document or technical problems prohibits=
 one
>> from including the BR in the BNG?  Anyway, if the BR and the BNG are not
>> co-resident,  what protocol exists between the BR and the BNG to sunset =
6rd?
>> Which of BR or the BNG signals start of 6rd sunsetting and then how does=
 the
>> BR/BNG get notified?   If a protocol is not used one has to use ad hoc m=
eans
>> to coordinate the sunsetting between devices in the SP domain.  Let=B9s sp=
ecify
>> the ad hoc steps or the protocol.
>> =20
>> Hemant
>> =20
>>=20
>> =20
>> =20

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


--B_3405258646_19419188
Content-type: text/html;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable


**  Biased Operator View **

>There is nothing=
 to stop the BR from being the same piece of equipment as the BNG, but the B=
R function itself described in >RFC 5569 or 5969 is not "subscriber aware=
" by design. The BR and BNG are very much functionally separate. I'll note t=
hat >the deployment at Free and most of the others I am aware of today, t=
he BR is a separate box not co-located with the BNG. I >have seen designs=
 where the plan was to enable BR functionality on the BNG over time, and the=
re is nothing wrong with >that. What I am saying here is that it is "abso=
lutely not" *necessary* to make them co-resident.

I would say that the likelihood that BNG and BR are co-res=
ident are not likely in early 6RD deployments (if ever).  If the BR fun=
ctionality was built into the BNG maybe, but I am not sure how common that i=
s today.

What ever we do here should not assume thi=
s mode of operation (but as noted, does not preclude it either).  From =
our point of view, BRs will be planted in various parts of the network and w=
ould be scaled according to load (since there are other functions that an op=
erator may want to co-locate with the BR that would need to scale out too).<=
/div>

Even if the BR was co-resident, the return path of =
the IPv6 flow may be serviced by a different BR (since the ingress and egres=
s paths need not be the same).  This would of course be highly dependan=
t on the operators BR and routing design.


>The=
re is no need for the BR and BNG to communicate directly to sunset 6rd, and =
certainly no new protocol to invent here. >The steps necessary for two me=
thods are outlined in 6rd-sunsetting, and graphically in the presentation I =
rushed through in >v6ops (though the slides should be part of the proceed=
ings). These are guidelines, leading to the more important part: >require=
ments for the CPE. An operator will certainly have its own environment to co=
nsider, and may move very quickly or >very slowly, with one prefix or mor=
e than one, when sunsetting.

>=
;Please don't make this more difficult that it is. All we are doing here is =
moving the subscriber from one interface type to another. 
In my opinion, the simpler the requirements on the CPE the bett=
er (especially when it comes to how the CPE interacts with the network). &nb=
sp; You cannot imagine the /fun/ we have with CPE behaviour today in ou=
r networks (coming from all kinds of places and vendors),  I would sugg=
est too much more complexity on the CPE would exasperate this.
<=
br>
Victor K



>- Mark

On Nov 27, 2011, at 7:22 PM, Tina TSOU=
 wrote:

<=
meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1252">
Same questions here.


Sent from my iPad


On Nov 27, 2011, at 7:17 AM, "Hemant Singh (shemant)" <shemant@cisco.com> wrote:

<=
blockquote type=3D"cite">
<=
span style=3D"font-size: 11pt; color: rgb(31, 73, 125); font-family: Calibri, =
sans-serif; "> 
From: Mark=
 Townsley [mailto:mark@townsley.net]

Sent: Sunday, November 27, 2011 7:52 AM
To: Hemant Sin=
gh (shemant)
Cc: Lorenzo Colitti; Claire Cheng; v6ops@ietf.org; Alexandre Cassen
Subject: Re: [v=
6ops] 6rd Sunsetting
<=
o:p> 
BNG and BR are co-resident. 

=
 
=
>Absolutely not.
=

 
Why is it absolutely not?  What document or tec=
hnical problems prohibits one from including the BR in the BNG?  Anyway=
, if the BR and the BNG are not co-resident,
  what protocol exists between the BR and the BNG to sunset 6rd? =
 Which of BR or the BNG signals start of 6rd sunsetting and then how does th=
e BR/BNG get notified?   If a protocol is not used one has to use =
ad hoc means to coordinate the sunsetting between
 devices in the SP domain.  Let’s specify the ad hoc steps or th=
e protocol.  
=
 
Hemant<=
/o:p>
 
 
 

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


--B_3405258646_19419188--



From shemant@cisco.com  Sun Nov 27 15:34:43 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F222D21F8CA7 for ; Sun, 27 Nov 2011 15:34:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.295
X-Spam-Level: 
X-Spam-Status: No, score=-6.295 tagged_above=-999 required=5 tests=[AWL=0.303,  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 S0P4jr21N3e5 for ; Sun, 27 Nov 2011 15:34:42 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id C21AC21F8C3A for ; Sun, 27 Nov 2011 15:34:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=5824; q=dns/txt; s=iport; t=1322436882; x=1323646482; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=ZgtGGqJO88FPeBnIVGrbOq8kVK6ZHCVoRe90bKeQB8M=; b=ihBqkQ/i2dxSEvqwesWdHh5wuzU5Y2kAz0/2DB1zAOZ+4ERSaTUrgPTd 2HswFyNE7c06zHNDcWRblWvWD1cnjaAA/1ZrSb4anZhyxguaIx7OvXdxe JNLuTStKpxO39sDb1DucdC0/Aztl56IYv45MeVLI8eGywH3KY9ylO/E+l k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AocAANbH0k6tJXHA/2dsb2JhbABEgk2YC5AwgQWBcgEBAQQSAQkRA0kQAgEIEQQBAQsGFwEGAUUJCAEBBAESCBqedwGdNIl/YwSIIZ5T
X-IronPort-AV: E=Sophos;i="4.69,580,1315180800"; d="scan'208,217";a="39226353"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-2.cisco.com with ESMTP; 27 Nov 2011 23:34:41 +0000
Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id pARNYfie013725;  Sun, 27 Nov 2011 23:34:41 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Sun, 27 Nov 2011 17:34:41 -0600
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCAD5D.22525B0D"
Date: Sun, 27 Nov 2011 17:34:39 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF325@XMB-RCD-109.cisco.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] 6rd Sunsetting
Thread-Index: AcytUXWvhPRw+uzmQIOYvzeHelqEGQACtzKA
References: <4C468F52-C08B-4B25-86FF-E599F0078946@townsley.net> 
From: "Hemant Singh (shemant)" 
To: "Victor Kuarsingh" , "Mark Townsley" , "Tina TSOU" 
X-OriginalArrivalTime: 27 Nov 2011 23:34:41.0076 (UTC) FILETIME=[22969740:01CCAD5D]
Cc: Alexandre Cassen , v6ops@ietf.org, Claire Cheng 
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 27 Nov 2011 23:34:44 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CCAD5D.22525B0D
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

=20

From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
Of Victor Kuarsingh
Sent: Sunday, November 27, 2011 5:11 PM
To: Mark Townsley; Tina TSOU
Cc: Alexandre Cassen; v6ops@ietf.org; Claire Cheng
Subject: Re: [v6ops] 6rd Sunsetting

=20

>In my opinion, the simpler the requirements on the CPE the better
(especially when it comes to how the CPE interacts with the network).
You cannot imagine the /fun/ we have with CPE behaviour today in our
networks (coming from all kinds of >places and vendors),  I would
suggest too much more complexity on the CPE would exasperate this.

=20

Agreed.  However, I am not discussing the CPE router.   I am discussing
the SP 6rd and native IPv6 domain and questioning a few SP issues.
Certainly the BR is not co-resident with the BNG/CMTS but when the  BR
is not I have already said where is the extra protocol to communicate
between the different BNG's/CMTS 's and the BR's to sunset 6rd?   I will
reply to Mark's response in another email.

=20

Hemant


------_=_NextPart_001_01CCAD5D.22525B0D
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


 
From:=
 =
v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of =
Victor Kuarsingh
Sent: Sunday, November 27, 2011 5:11 =
PM
To: Mark Townsley; Tina TSOU
Cc: Alexandre =
Cassen; v6ops@ietf.org; Claire Cheng
Subject: Re: [v6ops] 6rd =
Sunsetting
 
>In my =
opinion, the simpler the requirements on the CPE the better (especially =
when it comes to how the CPE interacts with the network).   You =
cannot imagine the /fun/ we have with CPE behaviour today in our =
networks (coming from all kinds of >places =
and vendors),  I would suggest too much more complexity on the CPE =
would exasperate this.
=
 
Agreed.  However, I am not discussing the CPE =
router.   I am discussing the SP 6rd and native IPv6 domain =
and questioning a few SP issues.   Certainly the BR is not =
co-resident with the BNG/CMTS but when the  BR is not I have =
already said where is the extra protocol to communicate between the =
different BNG’s/CMTS ‘s and the BR’s to sunset =
6rd?   I will reply to Mark’s response in another =
email.
 
Hemant

------_=_NextPart_001_01CCAD5D.22525B0D--

From mark@townsley.net  Sun Nov 27 22:37:46 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA0D21F854D for ; Sun, 27 Nov 2011 22:37:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.398
X-Spam-Level: 
X-Spam-Status: No, score=-0.398 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 oZL0s7UpgdsC for ; Sun, 27 Nov 2011 22:37:45 -0800 (PST)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4954221F8549 for ; Sun, 27 Nov 2011 22:37:41 -0800 (PST)
Received: by wwp14 with SMTP id 14so6439110wwp.13 for ; Sun, 27 Nov 2011 22:37:41 -0800 (PST)
Received: by 10.180.3.71 with SMTP id a7mr43453786wia.0.1322462259415; Sun, 27 Nov 2011 22:37:39 -0800 (PST)
Received: from ams-townsley-8712.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id gg1sm22917808wbb.17.2011.11.27.22.37.35 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 27 Nov 2011 22:37:36 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-32-557670441
From: Mark Townsley 
In-Reply-To: 
Date: Mon, 28 Nov 2011 07:37:33 +0100
Message-Id: <262225DB-E7CF-42C4-B4C1-996AB17560C6@townsley.net>
References: 
To: Victor Kuarsingh 
X-Mailer: Apple Mail (2.1084)
Cc: Alexandre Cassen , "v6ops@ietf.org" , Claire Cheng 
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 28 Nov 2011 06:37:46 -0000

--Apple-Mail-32-557670441
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


On Nov 27, 2011, at 11:10 PM, Victor Kuarsingh wrote:

> **  Biased Operator View **

Precisely the right forum for such.

> In my opinion, the simpler the requirements on the CPE the better =
(especially when it comes to how the CPE interacts with the network).   =
You cannot imagine the /fun/ we have with CPE behaviour today in our =
networks (coming from all kinds of places and vendors),  I would suggest =
too much more complexity on the CPE would exasperate this.

I'm trying to boil down the CPE requirements to the point that, when it =
comes to 6rd and native interaction, it is very simple and predictable =
so that the operator can control the sunsetting. While I am aware that =
some CPEs are trying to do so, I think it is more troublesome when the =
CPE tries to automatically prefer one configuration vs. another as it is =
more logic for the standards forums to define and the CPE folks to =
follow.
=20
- Mark

>=20
>=20
> Victor K
>=20
>=20
>=20
> >- Mark
>=20
> On Nov 27, 2011, at 7:22 PM, Tina TSOU wrote:
>=20
>> Same questions here.
>>=20
>> Sent from my iPad
>>=20
>> On Nov 27, 2011, at 7:17 AM, "Hemant Singh (shemant)" =
 wrote:
>>=20
>>> =20
>>> From: Mark Townsley [mailto:mark@townsley.net]=20
>>> Sent: Sunday, November 27, 2011 7:52 AM
>>> To: Hemant Singh (shemant)
>>> Cc: Lorenzo Colitti; Claire Cheng; v6ops@ietf.org; Alexandre Cassen
>>> Subject: Re: [v6ops] 6rd Sunsetting
>>> =20
>>> >>BNG and BR are co-resident.=20
>>> =20
>>> >Absolutely not.
>>> =20
>>> Why is it absolutely not?  What document or technical problems =
prohibits one from including the BR in the BNG?  Anyway, if the BR and =
the BNG are not co-resident,  what protocol exists between the BR and =
the BNG to sunset 6rd?  Which of BR or the BNG signals start of 6rd =
sunsetting and then how does the BR/BNG get notified?   If a protocol is =
not used one has to use ad hoc means to coordinate the sunsetting =
between devices in the SP domain.  Let=92s specify the ad hoc steps or =
the protocol. =20
>>> =20
>>> Hemant
>>> =20
>>> =20
>>> =20
>>>=20
>=20
> _______________________________________________ v6ops mailing list =
v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops


--Apple-Mail-32-557670441
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252


**  Biased Operator View =
**

Precisely the =
right forum for such.

In my opinion, the =
simpler the requirements on the CPE the better (especially when it comes =
to how the CPE interacts with the network).   You cannot imagine =
the /fun/ we have with CPE behaviour today in our networks (coming =
from all kinds of places and vendors),  I would suggest too much =
more complexity on the CPE would exasperate =
this.

I'm trying to boil =
down the CPE requirements to the point that, when it comes to 6rd and =
native interaction, it is very simple and predictable so that the =
operator can control the sunsetting. While I am aware that some CPEs are =
trying to do so, I think it is more troublesome when the CPE tries to =
automatically prefer one configuration vs. another as it is more logic =
for the standards forums to define and the CPE folks to =
follow.
 
- Mark


Victor =
K


Same questions =
here.


Sent from my iPad


On Nov 27, 2011, at 7:17 AM, "Hemant Singh (shemant)" <shemant@cisco.com> =
wrote:

From: Mark =
Townsley [mailto:mark@townsley.net]

Sent: Sunday, November 27, 2011 7:52 AM
To: Hemant =
Singh (shemant)
Cc: Lorenzo Colitti; Claire Cheng; v6ops@ietf.org; Alexandre =
Cassen
Subject: Re: [v6ops] 6rd =
Sunsetting
 
BNG and BR are =
co-resident. 

 
>Absolutely =
not.
Why is it absolutely not?  What document or technical =
problems prohibits one from including the BR in the BNG?  Anyway, =
if the BR and the BNG are not co-resident,
  what protocol exists between the BR and the BNG to sunset =
6rd?  Which of BR or the BNG signals start of 6rd sunsetting and =
then how does the BR/BNG get notified?   If a protocol is not =
used one has to use ad hoc means to coordinate the sunsetting between
 devices in the SP domain.  Let=92s specify the ad hoc steps or the =
protocol.  
 
Hemant
 
 
 

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


=

--Apple-Mail-32-557670441--

From mark@townsley.net  Sun Nov 27 22:42:44 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C76C11E8086 for ; Sun, 27 Nov 2011 22:42:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AWL=1.600,  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 OYLJUySAzZaO for ; Sun, 27 Nov 2011 22:42:43 -0800 (PST)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 21E0021F8672 for ; Sun, 27 Nov 2011 22:42:42 -0800 (PST)
Received: by wwp14 with SMTP id 14so6445434wwp.13 for ; Sun, 27 Nov 2011 22:42:42 -0800 (PST)
Received: by 10.216.134.29 with SMTP id r29mr1445233wei.41.1322462562337; Sun, 27 Nov 2011 22:42:42 -0800 (PST)
Received: from ams-townsley-8712.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id y3sm14125280wiy.3.2011.11.27.22.42.39 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 27 Nov 2011 22:42:40 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-33-557974849
From: Mark Townsley 
In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF325@XMB-RCD-109.cisco.com>
Date: Mon, 28 Nov 2011 07:42:38 +0100
Message-Id: <902984B4-71FE-4641-8E59-5F26006937C6@townsley.net>
References: <4C468F52-C08B-4B25-86FF-E599F0078946@townsley.net>  <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF325@XMB-RCD-109.cisco.com>
To: Hemant Singh (shemant) 
X-Mailer: Apple Mail (2.1084)
Cc: Alexandre Cassen , v6ops@ietf.org, Claire Cheng 
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 28 Nov 2011 06:42:44 -0000

--Apple-Mail-33-557974849
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


On Nov 28, 2011, at 12:34 AM, Hemant Singh (shemant) wrote:

> =20
> =20
> Agreed.  However, I am not discussing the CPE router.   I am =
discussing the SP 6rd and native IPv6 domain and questioning a few SP =
issues.   Certainly the BR is not co-resident with the BNG/CMTS but when =
the  BR is not I have already said where is the extra protocol to =
communicate between the different BNG=92s/CMTS =91s and the BR=92s to =
sunset 6rd? =20

The BNG/CMTS and BR do not need an "extra protocol." I'm at a complete =
loss as to where you are dreaming up this requirement.=20

> I will reply to Mark=92s response in another email.

When/if you do, please describe why in the world you think the BNG/CMTS =
and the 6rd BR need to "communicate" with one another.

- Mark

> =20
> Hemant


--Apple-Mail-33-557974849
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252


On Nov 28, 2011, at 12:34 AM, Hemant =
Singh (shemant) wrote:

Agreed.  However, I am not =
discussing the CPE router.   I am discussing the SP 6rd and =
native IPv6 domain and questioning a few SP issues.   =
Certainly the BR is not co-resident with the BNG/CMTS but when the  =
BR is not I have already said where is the extra protocol to communicate =
between the different BNG=92s/CMTS =91s and the BR=92s to sunset =
6rd?  

The BNG/CMTS and BR do not need an "extra =
protocol." I'm at a complete loss as to where you are dreaming up =
this requirement. 

 I =
will reply to Mark=92s response in another =
email.
=

When/if you do, please describe why in the world you =
think the BNG/CMTS and the 6rd BR need to "communicate" with one =
another.

- Mark

On Fri, Nov 25, 2011 at 11:25, Ted Lemon <Ted.Lemon@nominum.c=
om> wrote:











On Nov 24, 2011, at 8:03 PM, Lorenzo Colitti wrote:


=
What
 I'm trying to say that I think the current text of the spec says that =
M =3D managed address configuration and O =3D other configuration, and that=
 unless you believe that a prefix is an address, DHCPv6 PD should not be co=
ntrolled by M.








So despite the fact that RFC3633 explicitly states that the requ=
esting router is supposed to follow the behavior specified in RFC3315, you =
think that we should do the opposite.




What text are you referring to?


--20cf303f6d283e94eb04b2c67d49--

From Ted.Lemon@nominum.com  Mon Nov 28 00:28:28 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC92F21F8BEE for ; Mon, 28 Nov 2011 00:28:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.185
X-Spam-Level: 
X-Spam-Status: No, score=-104.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 e6JjXBebMTlc for ; Mon, 28 Nov 2011 00:28:28 -0800 (PST)
Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id 2CB4021F8BBC for ; Mon, 28 Nov 2011 00:28:27 -0800 (PST)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKTtNGH6791n0w1CuktVl0M0fHb+9kuE39@postini.com; Mon, 28 Nov 2011 00:28:28 PST
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id C94C71B827A for ; Mon, 28 Nov 2011 00:28:14 -0800 (PST)
Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 991A2190052; Mon, 28 Nov 2011 00:28:13 -0800 (PST) (envelope-from Ted.Lemon@nominum.com)
Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.01.0339.001; Mon, 28 Nov 2011 00:28:13 -0800
From: Ted Lemon 
To: Lorenzo Colitti , Ralph Droms 
Thread-Topic: [v6ops] DHCPv6 option for MAX_SOL_RT
Thread-Index: AQHMpBVS9v5OyU3dDEaf8biIUoZIIJWwMYMAgACJcgCAAANuAP//e/aAgAD3r4CAAQPRAIAAGkmAgAAkTwCAAEPzAIAAvrKAgAABC4CAAAnSAIAABdOAgAVG1oCAAFm1gIAAEJAAgAABEACAAAd2AIAABASAgAKnm4CAAAHjAIAAAqoAgAABuICAAAIeAIAAAugAgAAB5YCAABx9gIAAuogAgACIvoCAABbpgIAFDGiAgAAP+gA=
Date: Mon, 28 Nov 2011 08:28:13 +0000
Message-ID: 
References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com>  <5B6B2B64C9FE2A489045EEEADDAFF2C30354473D@XMB-RCD-109.cisco.com> <4EC455D6.8030601@bogus.com>   <7EB596BF-B175-40BF-ABC8-326599670B04@apple.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303544B88@XMB-RCD-109.cisco.com>    <8D342733-88E6-45D3-B388-E001AE32CD77@employees.org> <750BF7861EBBE048B3E648B4BB6E8F4F20DC4FEA@crexc50p>  <007801cca8c8$5610aa00$0231fe00$@iname.com>  <00f801cca8fd$784fcdf0$68ef69d0$@iname.com> <418C43A6-5E8A-4CBD-83F4-3C5F502213A1@employees.org>    <49D07B35-997E-4F99-B7B0-F3A9BBAF00B0@nominum.com>       <4DF0EE0F-E72C-4CB9-8456-A68C4EA22DCE@nominum.com>   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.1.10]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <3C35430A9626A741B001F061601B17DE@nominum.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: IPv6 Operations 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 28 Nov 2011 08:28:29 -0000

On Nov 28, 2011, at 2:30 AM, Lorenzo Colitti wrote:
> What text are you referring to?

Sections 11 and 12 of RFC3633.   These are the sum total of the text descri=
bing how requesting routers initiate configuration exchanges.   It's pretty=
 clear that when Ralph wrote this he was saying "do what's done in RFC3315,=
 only with IA_PD instead of IA_NA."   That's certainly what I remember him =
saying at the time.   However, there is an unfortunate degree of vagueness =
in the RFCs about this whole process.   I feel like we are debating differe=
nt interpretations of Talmudic commentaries.


From lorenzo@google.com  Mon Nov 28 00:42:48 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABFF121F8C14 for ; Mon, 28 Nov 2011 00:42:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.676
X-Spam-Level: 
X-Spam-Status: No, score=-101.676 tagged_above=-999 required=5 tests=[AWL=1.300, 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 SNDVRvUayU6O for ; Mon, 28 Nov 2011 00:42:48 -0800 (PST)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 073BF21F8B87 for ; Mon, 28 Nov 2011 00:42:47 -0800 (PST)
Received: by ghrr18 with SMTP id r18so1029712ghr.31 for ; Mon, 28 Nov 2011 00:42:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=rSyvQdGr3lBi7+gqPHU9h9tZ8LA2Tf3krgyeTAtPWPY=; b=ja4WmjiJj2LWw3QDisAm1NJpLe532mLTcJKVumJJM6j3M68eFROEQ44hZgtdii5fd2 kQKB4H9e9glNTT/s9kpA==
Received: by 10.236.75.167 with SMTP id z27mr60713166yhd.53.1322469767342; Mon, 28 Nov 2011 00:42:47 -0800 (PST)
Received: by 10.236.75.167 with SMTP id z27mr60713142yhd.53.1322469767152; Mon, 28 Nov 2011 00:42:47 -0800 (PST)
MIME-Version: 1.0
Received: by 10.150.202.14 with HTTP; Mon, 28 Nov 2011 00:42:25 -0800 (PST)
In-Reply-To: 
References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com>  <5B6B2B64C9FE2A489045EEEADDAFF2C30354473D@XMB-RCD-109.cisco.com> <4EC455D6.8030601@bogus.com>   <7EB596BF-B175-40BF-ABC8-326599670B04@apple.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303544B88@XMB-RCD-109.cisco.com>    <8D342733-88E6-45D3-B388-E001AE32CD77@employees.org> <750BF7861EBBE048B3E648B4BB6E8F4F20DC4FEA@crexc50p>  <007801cca8c8$5610aa00$0231fe00$@iname.com>  <00f801cca8fd$784fcdf0$68ef69d0$@iname.com> <418C43A6-5E8A-4CBD-83F4-3C5F502213A1@employees.org>    <49D07B35-997E-4F99-B7B0-F3A9BBAF00B0@nominum.com>       <4DF0EE0F-E72C-4CB9-8456-A68C4EA22DCE@nominum.com>    
From: Lorenzo Colitti 
Date: Mon, 28 Nov 2011 17:42:25 +0900
Message-ID: 
To: Ted Lemon 
Content-Type: multipart/alternative; boundary=20cf3005dde6b2853f04b2c77c7a
X-System-Of-Record: true
Cc: IPv6 Operations , Ralph Droms 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 28 Nov 2011 08:42:48 -0000

--20cf3005dde6b2853f04b2c77c7a
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Nov 28, 2011 at 17:28, Ted Lemon  wrote:

> On Nov 28, 2011, at 2:30 AM, Lorenzo Colitti wrote:
> > What text are you referring to?
>
> Sections 11 and 12 of RFC3633.   These are the sum total of the text
> describing how requesting routers initiate configuration exchanges.   It's
> pretty clear that when Ralph wrote this he was saying "do what's done in
> RFC3315, only with IA_PD instead of IA_NA."   That's certainly what I
> remember him saying at the time.   However, there is an unfortunate degree
> of vagueness in the RFCs about this whole process.   I feel like we are
> debating different interpretations of Talmudic commentaries.
>

Agreed, the RFCs are vague. That said, what little they do say is in RFC
4861 (RFC 3633 doesn't mention router advertisements at all, except in the
background section), so I would say that's the place we need to look to see
what the semantics of the M and O bits should be.

Of course, if we want to change them or deprecate them (and have consensus
to do so) that's fine, but until we do, the meaning of the bits should be
as defined in RFC 4861, because they aren't mentioned anywhere else :-)

--20cf3005dde6b2853f04b2c77c7a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Mon, Nov 28, 2011 at 17:28, Ted Lemon <Ted.Lemon@nominum.c=
om> wrote:



On Nov 28, 2011, at 2:30 AM, Lorenzo Colitti wrote:

> What text are you referring to?




Sections 11 and 12 of RFC3633. =A0 These are the sum total of the tex=
t describing how requesting routers initiate configuration exchanges. =A0 I=
t's pretty clear that when Ralph wrote this he was saying "do what=
's done in RFC3315, only with IA_PD instead of IA_NA." =A0 That=
9;s certainly what I remember him saying at the time. =A0 However, there is=
 an unfortunate degree of vagueness in the RFCs about this whole process. =
=A0 I feel like we are debating different interpretations of Talmudic comme=
ntaries.




Agreed, the RFCs are vague.=A0That said, w=
hat little they do say is in RFC 4861 (RFC 3633 doesn't mention router =
advertisements at all, except in the background section), so I would say th=
at's the place we need to look to see what the semantics of the M and O=
 bits should be.




Of course, if we want to change them or deprecate them =
(and have consensus to do so) that's fine, but until we do, the meaning=
 of the bits should be as defined in RFC 4861, because they aren't ment=
ioned anywhere else :-)





--20cf3005dde6b2853f04b2c77c7a--

From Ted.Lemon@nominum.com  Mon Nov 28 00:50:23 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C638B21F8C41 for ; Mon, 28 Nov 2011 00:50:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.391
X-Spam-Level: 
X-Spam-Status: No, score=-105.391 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 FAnEkXIuRK+q for ; Mon, 28 Nov 2011 00:50:23 -0800 (PST)
Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id DA38E21F8C45 for ; Mon, 28 Nov 2011 00:50:18 -0800 (PST)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKTtNLRunQ6d4MWNMQfUD1cpDMWYVuzNYn@postini.com; Mon, 28 Nov 2011 00:50:19 PST
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id BD9241B8228 for ; Mon, 28 Nov 2011 00:50:13 -0800 (PST)
Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id ADD60190052; Mon, 28 Nov 2011 00:50:13 -0800 (PST) (envelope-from Ted.Lemon@nominum.com)
Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.01.0339.001; Mon, 28 Nov 2011 00:50:13 -0800
From: Ted Lemon 
To: Lorenzo Colitti 
Thread-Topic: [v6ops] DHCPv6 option for MAX_SOL_RT
Thread-Index: AQHMpBVS9v5OyU3dDEaf8biIUoZIIJWwMYMAgACJcgCAAANuAP//e/aAgAD3r4CAAQPRAIAAGkmAgAAkTwCAAEPzAIAAvrKAgAABC4CAAAnSAIAABdOAgAVG1oCAAFm1gIAAEJAAgAABEACAAAd2AIAABASAgAKnm4CAAAHjAIAAAqoAgAABuICAAAIeAIAAAugAgAAB5YCAABx9gIAAuogAgACIvoCAABbpgIAFDGiAgAAP+gCAAAP7gIAAAimA
Date: Mon, 28 Nov 2011 08:50:13 +0000
Message-ID: <3BDEA3F6-0096-4611-84B4-98FDC890366C@nominum.com>
References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com>  <5B6B2B64C9FE2A489045EEEADDAFF2C30354473D@XMB-RCD-109.cisco.com> <4EC455D6.8030601@bogus.com>   <7EB596BF-B175-40BF-ABC8-326599670B04@apple.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303544B88@XMB-RCD-109.cisco.com>    <8D342733-88E6-45D3-B388-E001AE32CD77@employees.org> <750BF7861EBBE048B3E648B4BB6E8F4F20DC4FEA@crexc50p>  <007801cca8c8$5610aa00$0231fe00$@iname.com>  <00f801cca8fd$784fcdf0$68ef69d0$@iname.com> <418C43A6-5E8A-4CBD-83F4-3C5F502213A1@employees.org>    <49D07B35-997E-4F99-B7B0-F3A9BBAF00B0@nominum.com>       <4DF0EE0F-E72C-4CB9-8456-A68C4EA22DCE@nominum.com>     
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.1.10]
Content-Type: multipart/alternative; boundary="_000_3BDEA3F60096461184B498FDC890366Cnominumcom_"
MIME-Version: 1.0
Cc: IPv6 Operations , Ralph Droms 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 28 Nov 2011 08:50:23 -0000

--_000_3BDEA3F60096461184B498FDC890366Cnominumcom_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

On Nov 28, 2011, at 3:42 AM, Lorenzo Colitti wrote:
Agreed, the RFCs are vague. That said, what little they do say is in RFC 48=
61 (RFC 3633 doesn't mention router advertisements at all, except in the ba=
ckground section), so I would say that's the place we need to look to see w=
hat the semantics of the M and O bits should be.

Of course, if we want to change them or deprecate them (and have consensus =
to do so) that's fine, but until we do, the meaning of the bits should be a=
s defined in RFC 4861, because they aren't mentioned anywhere else :-)

Right, but this is where we descend into Talmudic interpretation.   It's re=
ally clear to me that RFC3633 says "do what RFC3315 does," which means to m=
e that requesting routers solicit prefix delegations under the same circums=
tances that DHCP clients solicit addresses.

You claim that RFC4861 says to do the opposite, because you claim that the =
M bit only applies to addresses, and a prefix delegation, despite being a r=
ange of addresses, is not an address, and therefore must be "other configur=
ation information."

While I don't think the RFCs are crystal clear about this, your interpretat=
ion seems a bit surprising from my perspective as a DHCP protocol wonk who =
was around when RFC3633 was developed.


--_000_3BDEA3F60096461184B498FDC890366Cnominumcom_
Content-Type: text/html; charset="iso-8859-1"
Content-ID: 
Content-Transfer-Encoding: quoted-printable









On Nov 28, 2011, at 3:42 AM, Lorenzo Colitti wrote:




Agreed, the RFCs are vague. That said, what little they do say is=
 in RFC 4861 (RFC 3633 doesn't mention router advertisements at all, except=
 in the background section), so I would say that's the place we need to loo=
k to see what the semantics of the M
 and O bits should be.







Of course, if we want to change them or deprecate them (and have conse=
nsus to do so) that's fine, but until we do, the meaning of the bits should=
 be as defined in RFC 4861, because they aren't mentioned anywhere else :-)=









Right, but this is where we descend into Talmudic interpretation. &nbs=
p; It's really clear to me that RFC3633 says "do what RFC3315 does,&qu=
ot; which means to me that requesting routers solicit prefix delegations un=
der the same circumstances that DHCP clients solicit
 addresses.







You claim that RFC4861 says to do the opposite, because you claim that=
 the M bit only applies to addresses, and a prefix delegation, despite bein=
g a range of addresses, is not an address, and therefore must be "othe=
r configuration information."







While I don't think the RFCs are crystal clear about this, your interp=
retation seems a bit surprising from my perspective as a DHCP protocol wonk=
 who was around when RFC3633 was developed.









--_000_3BDEA3F60096461184B498FDC890366Cnominumcom_--

From lorenzo@google.com  Mon Nov 28 00:55:57 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A1BF21F8ABE for ; Mon, 28 Nov 2011 00:55:57 -0800 (PST)
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.893, 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 kbcwPl38ps2A for ; Mon, 28 Nov 2011 00:55:56 -0800 (PST)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9A5EF21F8A7B for ; Mon, 28 Nov 2011 00:55:56 -0800 (PST)
Received: by ywm13 with SMTP id 13so3569750ywm.31 for ; Mon, 28 Nov 2011 00:55:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=lRHJcOEzh+we9aUVzQUnR9PeuNNpT+Je87uEMpTaItE=; b=DmUvrSpEgrrsc8LfCk+VV77wb9CsLiFIF2/G2dcOkc0ZgKw3Mv8BBEE8NgL3mMzzPi YB/3bGphSp28kcFGnahQ==
Received: by 10.236.131.82 with SMTP id l58mr3626952yhi.36.1322470556222; Mon, 28 Nov 2011 00:55:56 -0800 (PST)
Received: by 10.236.131.82 with SMTP id l58mr3626942yhi.36.1322470556116; Mon, 28 Nov 2011 00:55:56 -0800 (PST)
MIME-Version: 1.0
Received: by 10.150.202.14 with HTTP; Mon, 28 Nov 2011 00:55:35 -0800 (PST)
In-Reply-To: <3BDEA3F6-0096-4611-84B4-98FDC890366C@nominum.com>
References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com>  <5B6B2B64C9FE2A489045EEEADDAFF2C30354473D@XMB-RCD-109.cisco.com> <4EC455D6.8030601@bogus.com>   <7EB596BF-B175-40BF-ABC8-326599670B04@apple.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303544B88@XMB-RCD-109.cisco.com>    <8D342733-88E6-45D3-B388-E001AE32CD77@employees.org> <750BF7861EBBE048B3E648B4BB6E8F4F20DC4FEA@crexc50p>  <007801cca8c8$5610aa00$0231fe00$@iname.com>  <00f801cca8fd$784fcdf0$68ef69d0$@iname.com> <418C43A6-5E8A-4CBD-83F4-3C5F502213A1@employees.org>    <49D07B35-997E-4F99-B7B0-F3A9BBAF00B0@nominum.com>       <4DF0EE0F-E72C-4CB9-8456-A68C4EA22DCE@nominum.com>      <3BDEA3F6-0096-4611-84B4-98FDC890366C@nominum.com>
From: Lorenzo Colitti 
Date: Mon, 28 Nov 2011 17:55:35 +0900
Message-ID: 
To: Ted Lemon 
Content-Type: multipart/alternative; boundary=20cf3011e203b9279204b2c7ab21
X-System-Of-Record: true
Cc: IPv6 Operations , Ralph Droms 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 28 Nov 2011 08:55:57 -0000

--20cf3011e203b9279204b2c7ab21
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Nov 28, 2011 at 17:50, Ted Lemon  wrote:

>  On Nov 28, 2011, at 3:42 AM, Lorenzo Colitti wrote:
>
> Agreed, the RFCs are vague. That said, what little they do say is in RFC
> 4861 (RFC 3633 doesn't mention router advertisements at all, except in the
> background section), so I would say that's the place we need to look to see
> what the semantics of the M and O bits should be.
>
>  Of course, if we want to change them or deprecate them (and have
> consensus to do so) that's fine, but until we do, the meaning of the bits
> should be as defined in RFC 4861, because they aren't mentioned anywhere
> else :-)
>
>
> Right, but this is where we descend into Talmudic interpretation.   It's
> really clear to me that RFC3633 says "do what RFC3315 does," which means to
> me that requesting routers solicit prefix delegations under the same
> circumstances that DHCP clients solicit addresses.
>
>  You claim that RFC4861 says to do the opposite, because you claim that
> the M bit only applies to addresses, and a prefix delegation, despite being
> a range of addresses, is not an address, and therefore must be "other
> configuration information."
>
>  While I don't think the RFCs are crystal clear about this, your
> interpretation seems a bit surprising from my perspective as a DHCP
> protocol wonk who was around when RFC3633 was developed.
>

All I'm saying is that if you get a conflict between Talmudic
interpretation actual RFC text, then the actual text should take
precedence. It's all very well to say "this is what we meant to do do when
we designed it", but how is an implementer supposed to know this?

I think that if we're writing the standards, then we need to stand by the
standards that we write. :-) If we don't agree with them or we feel that
they're wrong, then we should change them. We can't just say "well, but
this is not what we intended when we wrote them".

--20cf3011e203b9279204b2c7ab21
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Mon, Nov 28, 2011 at 17:50, Ted Lemon <T=
ed.Lemon@nominum.com> wrote:




On Nov 28, 2011, at 3:42 AM, Lorenzo Colitti wrote:




Agreed, the RFCs are vague.=A0That said, what little they do say is in=
 RFC 4861 (RFC 3633 doesn't mention router advertisements at all, excep=
t in the background section), so I would say that's the place we need t=
o look to see what the semantics of the M
 and O bits should be.







Of course, if we want to change them or deprecate them (and have conse=
nsus to do so) that's fine, but until we do, the meaning of the bits sh=
ould be as defined in RFC 4861, because they aren't mentioned anywhere =
else :-)











Right, but this is where we descend into Talmudic interpretation=
. =A0 It's really clear to me that RFC3633 says "do what RFC3315 d=
oes," which means to me that requesting routers solicit prefix delegat=
ions under the same circumstances that DHCP clients solicit
 addresses.







You claim that RFC4861 says to do the opposite, because you claim that=
 the M bit only applies to addresses, and a prefix delegation, despite bein=
g a range of addresses, is not an address, and therefore must be "othe=
r configuration information."










While I don't think the RFCs are crystal clear about this, your in=
terpretation seems a bit surprising from my perspective as a DHCP protocol =
wonk who was around when RFC3633 was developed.






All I'm saying is that if you get a conflic=
t between Talmudic interpretation actual RFC text, then the actual text sho=
uld take precedence. It's all very well to say "this is what we me=
ant to do do when we designed it", but how is an implementer supposed =
to know this?





I think that if we're writing the standards, then w=
e need to stand by the standards that we write. :-) If we don't agree w=
ith them or we feel that they're wrong, then we should change them. We =
can't just say "well, but this is not what we intended when we wro=
te them".




--20cf3011e203b9279204b2c7ab21--

From Ted.Lemon@nominum.com  Mon Nov 28 00:57:47 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C438B21F8586 for ; Mon, 28 Nov 2011 00:57:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.995
X-Spam-Level: 
X-Spam-Status: No, score=-105.995 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 wVSIl2f0sGJk for ; Mon, 28 Nov 2011 00:57:47 -0800 (PST)
Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id D654021F8569 for ; Mon, 28 Nov 2011 00:57:46 -0800 (PST)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKTtNNCi0edNgJYU/ezgR6CJJteeNFaRIX@postini.com; Mon, 28 Nov 2011 00:57:46 PST
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 0190A1B827A for ; Mon, 28 Nov 2011 00:57:46 -0800 (PST)
Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id E7EAB190052; Mon, 28 Nov 2011 00:57:45 -0800 (PST) (envelope-from Ted.Lemon@nominum.com)
Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.01.0339.001; Mon, 28 Nov 2011 00:57:45 -0800
From: Ted Lemon 
To: Lorenzo Colitti 
Thread-Topic: [v6ops] DHCPv6 option for MAX_SOL_RT
Thread-Index: AQHMpBVS9v5OyU3dDEaf8biIUoZIIJWwMYMAgACJcgCAAANuAP//e/aAgAD3r4CAAQPRAIAAGkmAgAAkTwCAAEPzAIAAvrKAgAABC4CAAAnSAIAABdOAgAVG1oCAAFm1gIAAEJAAgAABEACAAAd2AIAABASAgAKnm4CAAAHjAIAAAqoAgAABuICAAAIeAIAAAugAgAAB5YCAABx9gIAAuogAgACIvoCAABbpgIAFDGiAgAAP+gCAAAP7gIAAAimAgAACG4A=
Date: Mon, 28 Nov 2011 08:57:45 +0000
Message-ID: <8C812D9E-6C64-4CAE-A307-4AC2618AC2BF@nominum.com>
References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com>  <5B6B2B64C9FE2A489045EEEADDAFF2C30354473D@XMB-RCD-109.cisco.com> <4EC455D6.8030601@bogus.com>   <7EB596BF-B175-40BF-ABC8-326599670B04@apple.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303544B88@XMB-RCD-109.cisco.com>    <8D342733-88E6-45D3-B388-E001AE32CD77@employees.org> <750BF7861EBBE048B3E648B4BB6E8F4F20DC4FEA@crexc50p>  <007801cca8c8$5610aa00$0231fe00$@iname.com>  <00f801cca8fd$784fcdf0$68ef69d0$@iname.com> <418C43A6-5E8A-4CBD-83F4-3C5F502213A1@employees.org>    <49D07B35-997E-4F99-B7B0-F3A9BBAF00B0@nominum.com>       <4DF0EE0F-E72C-4CB9-8456-A68C4EA22DCE@nominum.com>      <3BDEA3F6-0096-4611-84B4-98FDC890366C@nominum.com>
In-Reply-To: <3BDEA3F6-0096-4611-84B4-98FDC890366C@nominum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.1.10]
Content-Type: multipart/alternative; boundary="_000_8C812D9E6C644CAEA3074AC2618AC2BFnominumcom_"
MIME-Version: 1.0
Cc: IPv6 Operations , Ralph Droms 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 28 Nov 2011 08:57:47 -0000

--_000_8C812D9E6C644CAEA3074AC2618AC2BFnominumcom_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

On Nov 28, 2011, at 3:50 AM, Ted Lemon wrote:
While I don't think the RFCs are crystal clear about this, your interpretat=
ion seems a bit surprising from my perspective as a DHCP protocol wonk who =
was around when RFC3633 was developed.

To be clear, what I mean here is that if I were doing an implementation of =
an RFC3633 requesting router, the code I would write would depend on the M =
bit, not the O bit, based solely on reading RFCs.   It may be that you are =
correct, for some value of correct, but what matters is what implementors w=
ill do.   If we want implementors to do the right thing, the RFC should say=
 _explicitly_ what to do, not leave it up to Talmudic interpretation.

BTW, we've digressed quite a bit from the original topic.   In case some pe=
ople following this thread weren't aware, Ralph privately talked me out of =
my position that the MAX_SOL_RT option would create a denial of service opp=
ortunity.   If you still care about that debate, you might want to circle b=
ack.


--_000_8C812D9E6C644CAEA3074AC2618AC2BFnominumcom_
Content-Type: text/html; charset="iso-8859-1"
Content-ID: <009723B0676F87418316AFD9E187B869@nominum.com>
Content-Transfer-Encoding: quoted-printable









On Nov 28, 2011, at 3:50 AM, Ted Lemon wrote:


While
 I don't think the RFCs are crystal clear about this, your interpretation s=
eems a bit surprising from my perspective as a DHCP protocol wonk who was a=
round when RFC3633 was developed.






To be clear, what I mean here is that if I were doing an implementatio=
n of an RFC3633 requesting router, the code I would write would depend on t=
he M bit, not the O bit, based solely on reading RFCs.   It may be tha=
t you are correct, for some value of
 correct, but what matters is what implementors will do.   If we want =
implementors to do the right thing, the RFC should say _explicitly_ what to=
 do, not leave it up to Talmudic interpretation.







BTW, we've digressed quite a bit from the original topic.   In ca=
se some people following this thread weren't aware, Ralph privately talked =
me out of my position that the MAX_SOL_RT option would create a denial of s=
ervice opportunity.   If you still care
 about that debate, you might want to circle back.









--_000_8C812D9E6C644CAEA3074AC2618AC2BFnominumcom_--

From ichiroumakino@gmail.com  Mon Nov 28 01:12:19 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA9F21F8C5B for ; Mon, 28 Nov 2011 01:12:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ldiHmj3Mmm8 for ; Mon, 28 Nov 2011 01:12:19 -0800 (PST)
Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id A550621F8C5A for ; Mon, 28 Nov 2011 01:12:18 -0800 (PST)
Received: by lahj13 with SMTP id j13so588754lah.31 for ; Mon, 28 Nov 2011 01:12:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=GYT2xTg+2NtvA9FSloWsXxZVqejXkIDLMgt9yBZwok8=; b=hMWWs0YWxFCDON0AQMuriUq4xPcB/lAKsYEcJDg/fXQkh61D2KeoGJiA5IHF/uHBrl k1YGsZdVbXYAcyCfiMgdgaFM8YHLPXuBjOXguVXYemxz2EdyxEGt5jFc1qf7WG44J2de PGeqFfZfJfcHYM3PTmO6jRzuAPhUBcfX2xspU=
Received: by 10.152.144.136 with SMTP id sm8mr27733457lab.33.1322471537631; Mon, 28 Nov 2011 01:12:17 -0800 (PST)
Received: from dhcp-10-55-84-217.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id iy5sm12872822lab.16.2011.11.28.01.12.09 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 28 Nov 2011 01:12:11 -0800 (PST)
Sender: Ole Troan 
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Ole Troan 
In-Reply-To: <8C812D9E-6C64-4CAE-A307-4AC2618AC2BF@nominum.com>
Date: Mon, 28 Nov 2011 10:12:08 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com>  <5B6B2B64C9FE2A489045EEEADDAFF2C30354473D@XMB-RCD-109.cisco.com> <4EC455D6.8030601@bogus.com>   <7EB596BF-B175-40BF-ABC8-326599670B04@apple.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303544B88@XMB-RCD-109.cisco.com>    <8D342733-88E6-45D3-B388-E001AE32CD77@employees.org> <750BF7861EBBE048B3E648B4BB6E8F4F20DC4FEA@crexc50p>  <007801cca8c8$5610aa00$0231fe00$@iname.com>  <00f801cca8fd$784fcdf0$68ef69d0$@iname.com> <418C43A6-5E8A-4CBD-83F4-3C5F502213A1@employees.org>    <49D07B35-997E-4F99-B7B0-F3A9BBAF00B0@nominum.com>       <4DF0EE0F-E72C-4CB9-8456-A68C4EA22DCE@nominum.com>      <3BDEA3F6-0096-4611-84B4-98FDC890366C@nominum.com> <8C81 2D9E-6C64-4CAE-A307-4AC2618AC2BF@nominum.com>
To: Ted Lemon 
X-Mailer: Apple Mail (2.1084)
Cc: IPv6 Operations , Ralph Droms 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 28 Nov 2011 09:12:19 -0000

Ted,

>> While I don't think the RFCs are crystal clear about this, your =
interpretation seems a bit surprising from my perspective as a DHCP =
protocol wonk who was around when RFC3633 was developed.
>=20
> To be clear, what I mean here is that if I were doing an =
implementation of an RFC3633 requesting router, the code I would write =
would depend on the M bit, not the O bit, based solely on reading RFCs.  =
 It may be that you are correct, for some value of correct, but what =
matters is what implementors will do.   If we want implementors to do =
the right thing, the RFC should say _explicitly_ what to do, not leave =
it up to Talmudic interpretation.

that's certainly _not_ the intention when we wrote 3633. where in =
section 6.2.7 of 4861 does it say a router should do anything with the =
M/O flags, apart from consistency checking them? 3633 is a protocol =
between _routers_.

> BTW, we've digressed quite a bit from the original topic.   In case =
some people following this thread weren't aware, Ralph privately talked =
me out of my position that the MAX_SOL_RT option would create a denial =
of service opportunity.   If you still care about that debate, you might =
want to circle back.

cheers,
Ole=

From lorenzo@google.com  Mon Nov 28 01:30:37 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEE3B21F8C7C for ; Mon, 28 Nov 2011 01:30:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.306
X-Spam-Level: 
X-Spam-Status: No, score=-102.306 tagged_above=-999 required=5 tests=[AWL=0.669, 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 6SGQAohepczG for ; Mon, 28 Nov 2011 01:30:37 -0800 (PST)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id DE0CE21F8C69 for ; Mon, 28 Nov 2011 01:30:36 -0800 (PST)
Received: by ggnp4 with SMTP id p4so6162695ggn.31 for ; Mon, 28 Nov 2011 01:30:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=7NTddUMWEwqlIFHxyNj5aXczE1MVXaE1wgLBToa5cts=; b=NLHx6rM1EeRzL4tGqqjGB+zn4wLFfptTiia5s2UjVhIFWqcxsy3WkS0A0mNpNuXEha syKvvV/hifVsR81B/4NA==
Received: by 10.236.183.52 with SMTP id p40mr60216404yhm.19.1322472636240; Mon, 28 Nov 2011 01:30:36 -0800 (PST)
Received: by 10.236.183.52 with SMTP id p40mr60216385yhm.19.1322472636138; Mon, 28 Nov 2011 01:30:36 -0800 (PST)
MIME-Version: 1.0
Received: by 10.150.202.14 with HTTP; Mon, 28 Nov 2011 01:30:14 -0800 (PST)
In-Reply-To: 
References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com>  <5B6B2B64C9FE2A489045EEEADDAFF2C30354473D@XMB-RCD-109.cisco.com> <4EC455D6.8030601@bogus.com>   <7EB596BF-B175-40BF-ABC8-326599670B04@apple.com> <5B6B2B64C9FE2A489045EEEADDAFF2C303544B88@XMB-RCD-109.cisco.com>    <8D342733-88E6-45D3-B388-E001AE32CD77@employees.org> <750BF7861EBBE048B3E648B4BB6E8F4F20DC4FEA@crexc50p>  <007801cca8c8$5610aa00$0231fe00$@iname.com>  <00f801cca8fd$784fcdf0$68ef69d0$@iname.com> <418C43A6-5E8A-4CBD-83F4-3C5F502213A1@employees.org>    <49D07B35-997E-4F99-B7B0-F3A9BBAF00B0@nominum.com>       <4DF0EE0F-E72C-4CB9-8456-A68C4EA22DCE@nominum.com>      <3BDEA3F6-0096-4611-84B4-98FDC890366C@nominum.com> <8C812D9E-6C64-4CAE-A307-4AC2618AC2BF@nominum.com> 
From: Lorenzo Colitti 
Date: Mon, 28 Nov 2011 18:30:14 +0900
Message-ID: 
To: Ole Troan 
Content-Type: multipart/alternative; boundary=bcaec52c5ea9b3c5ed04b2c82760
X-System-Of-Record: true
Cc: IPv6 Operations , Ralph Droms 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 28 Nov 2011 09:30:37 -0000

--bcaec52c5ea9b3c5ed04b2c82760
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Nov 28, 2011 at 18:12, Ole Troan  wrote:

> that's certainly _not_ the intention when we wrote 3633. where in section
> 6.2.7 of 4861 does it say a router should do anything with the M/O flags,
> apart from consistency checking them? 3633 is a protocol between _routers_.
>

Section 6.2.7 of RFC 4861 doesn't say what nodes (either hosts or routers)
are supposed to do with the M and O flags. It only defines the meaning of
the flags.

--bcaec52c5ea9b3c5ed04b2c82760
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Mon, Nov 28, 2011 at 18:12, Ole Troan <otroan@employees.org=
> wrote:


that's certainly _not_ the intention when we wrote 3633. where in secti=
on 6.2.7 of 4861 does it say a router should do anything with the M/O flags=
, apart from consistency checking them? 3633 is a protocol between _routers=
_.




Section 6.2.7 of RFC 4861 doesn't say =
what nodes (either hosts or routers) are supposed to do with the M and O fl=
ags. It only defines the meaning of the flags.


--bcaec52c5ea9b3c5ed04b2c82760--

From ales.vizdal@t-mobile.cz  Mon Nov 28 02:20:12 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9E8B21F8CAF for ; Mon, 28 Nov 2011 02:20:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.539
X-Spam-Level: 
X-Spam-Status: No, score=0.539 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, 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 Y-a5AxUEjEvn for ; Mon, 28 Nov 2011 02:20:12 -0800 (PST)
Received: from mailhub1.t-mobile.cz (mailhub1.t-mobile.cz [62.141.0.149]) by ietfa.amsl.com (Postfix) with ESMTP id 1368F21F8CA6 for ; Mon, 28 Nov 2011 02:20:12 -0800 (PST)
Received: from srvhk504.rdm.cz (unknown [10.246.143.96]) by mailhub1.t-mobile.cz (Postfix) with ESMTP id E7C25285899; Mon, 28 Nov 2011 11:20:10 +0100 (CET)
Received: from SRVHKE02.rdm.cz ([fe80::94ce:8456:f6fa:86a8]) by srvhk504.rdm.cz ([fe80::506:b9a6:d353:9494%12]) with mapi; Mon, 28 Nov 2011 11:20:10 +0100
From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= 
To: "Hemant Singh (shemant)" , Ole Troan , jouni korhonen 
Date: Mon, 28 Nov 2011 11:20:09 +0100
Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
Thread-Index: AcyrZM6Op71ZUQDvQZGUHCE73sbQ2wBHO07QACkJ/mAAIjKr4A==
Message-ID: <1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz>
References: <2963F168-45CB-4042-8238-56DF538B0543@gmail.com><2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com>
In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.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="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-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, 28 Nov 2011 10:20:12 -0000

Hemant,

> -----Original Message-----
> From: Hemant Singh (shemant) [mailto:shemant@cisco.com]
> Sent: Sunday, November 27, 2011 6:06 PM
> To: V=EDzdal Ale=B9; Ole Troan; jouni korhonen
> Cc: v6ops@ietf.org
> Subject: RE: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
>=20
> Vizdal,
>=20
> -----Original Message-----
> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of=
 V=EDzdal
> Ale=B9
> Sent: Saturday, November 26, 2011 5:02 PM
> To: Ole Troan; jouni korhonen
> Cc: v6ops@ietf.org
> Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
>=20
>=20
> >I have the same concern as Jouni that the IPv6 CE router (e.g. Mi-Fi dev=
ice) having a
> 3GPP access
> >based WAN link only would be required to support the IA_NA option on the=
 WAN link
> to be able to be
> >compliant to this RFC (I am saying on the WAN link, because this require=
ment is
> placed under the WAA
> >- WAN Address Allocation section).
>=20
> The rfc6204bis document only supports a cellular client for DHCPv6 PD.  T=
hus any
> legacy 3GPP cellular client that does not support DHCPv6 PD acquisition i=
s not
> supported by rfc6204bis. =20

OK.

> Thereafter if the cellular client supports DHCPv6 PD, the
> device already supports the IA_PD option, so what is the big deal for the=
 client to also
> support the IA_NA option but the client does not use this option? =20

What is the issue you currently see with relaxing this one for a non-DHCPv6=
 based address=20
allocation?

Even if supported by the IPv6 CE, the support for it cannot be verified as =
the 3GPP nodes=20
along the path do not support statefull address allocation.=20

I would see beneficial to allow 'current' 3GPP compliant CEs to be complian=
t to this RFC as well.

> Thanks for catching the spelling error for "specified".  It has been fixe=
d.

You're welcome.

> Hemant

Cheers,
Ales

From ichiroumakino@gmail.com  Mon Nov 28 02:48:29 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B02A21F8CFA for ; Mon, 28 Nov 2011 02:48:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.449
X-Spam-Level: 
X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, 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 iqk4oaqxEMPa for ; Mon, 28 Nov 2011 02:48:28 -0800 (PST)
Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 79C6821F8CE6 for ; Mon, 28 Nov 2011 02:48:28 -0800 (PST)
Received: by lahj13 with SMTP id j13so619631lah.31 for ; Mon, 28 Nov 2011 02:48:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=DyG3XfE8KiKSbedHO4+E1G/b96BuWZtPbhMGzdQGTGg=; b=EIyMYSRbHijlhSQsBwpLD5oMdEIaLmPRgAR425NibE+zk+qc+rDDdYYeQ0dW11O9ZC wf54HVb5b2nT85k6/gDII0SnGm2lCU85Ka+zF1vxhaqJETGecDFKND96I4C8UN/tB9+g Mjqt1Hl3gPtOmzTulfhhxGYBG9WpK39X93CiA=
Received: by 10.152.144.2 with SMTP id si2mr27713568lab.8.1322477307464; Mon, 28 Nov 2011 02:48:27 -0800 (PST)
Received: from dhcp-10-55-84-217.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id nw10sm31250653lab.4.2011.11.28.02.48.23 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 28 Nov 2011 02:48:23 -0800 (PST)
Sender: Ole Troan 
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=windows-1252
From: Ole Troan 
In-Reply-To: <1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz>
Date: Mon, 28 Nov 2011 11:48:20 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <8AF88A07-C1C5-4CD9-9E87-9D0F26504641@employees.org>
References: <2963F168-45CB-4042-8238-56DF538B0543@gmail.com><2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz>
To: =?windows-1252?Q?V=EDzdal_Ale=9A?= 
X-Mailer: Apple Mail (2.1084)
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-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, 28 Nov 2011 10:48:29 -0000

Vizdal,

different access networks may have different policies or the data link =
type may have various restrictions with regards
to address allocation. if it is unnumbered, SLAAC, DHCP or both SLAAC =
and DHCP.

e.g. typically Cable networks only use DHCP. DSL networks do either =
model. 6rd makes up an address based on an IPv4 address and so on.

I don't understand how 3GPP links are any different. does it harm =
functioning on a 3GPP link if the CE is _capable_ of doing DHCP address =
assignment?

cheers,
Ole

On Nov 28, 2011, at 11:20 , V=EDzdal Ale=9A wrote:

> Hemant,
>=20
>> -----Original Message-----
>> From: Hemant Singh (shemant) [mailto:shemant@cisco.com]
>> Sent: Sunday, November 27, 2011 6:06 PM
>> To: V=EDzdal Ale=9A; Ole Troan; jouni korhonen
>> Cc: v6ops@ietf.org
>> Subject: RE: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
>>=20
>> Vizdal,
>>=20
>> -----Original Message-----
>> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On =
Behalf Of V=EDzdal
>> Ale=9A
>> Sent: Saturday, November 26, 2011 5:02 PM
>> To: Ole Troan; jouni korhonen
>> Cc: v6ops@ietf.org
>> Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
>>=20
>>=20
>>> I have the same concern as Jouni that the IPv6 CE router (e.g. Mi-Fi =
device) having a
>> 3GPP access
>>> based WAN link only would be required to support the IA_NA option on =
the WAN link
>> to be able to be
>>> compliant to this RFC (I am saying on the WAN link, because this =
requirement is
>> placed under the WAA
>>> - WAN Address Allocation section).
>>=20
>> The rfc6204bis document only supports a cellular client for DHCPv6 =
PD.  Thus any
>> legacy 3GPP cellular client that does not support DHCPv6 PD =
acquisition is not
>> supported by rfc6204bis. =20
>=20
> OK.
>=20
>> Thereafter if the cellular client supports DHCPv6 PD, the
>> device already supports the IA_PD option, so what is the big deal for =
the client to also
>> support the IA_NA option but the client does not use this option? =20
>=20
> What is the issue you currently see with relaxing this one for a =
non-DHCPv6 based address=20
> allocation?
>=20
> Even if supported by the IPv6 CE, the support for it cannot be =
verified as the 3GPP nodes=20
> along the path do not support statefull address allocation.=20
>=20
> I would see beneficial to allow 'current' 3GPP compliant CEs to be =
compliant to this RFC as well.
>=20
>> Thanks for catching the spelling error for "specified".  It has been =
fixed.
>=20
> You're welcome.
>=20
>> Hemant
>=20
> Cheers,
> Ales


From v6ops@globis.net  Mon Nov 28 03:14:40 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9685121F8D03 for ; Mon, 28 Nov 2011 03:14:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.002
X-Spam-Level: 
X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 OZNtltHpH77x for ; Mon, 28 Nov 2011 03:14:39 -0800 (PST)
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 C7AEF21F8CC1 for ; Mon, 28 Nov 2011 03:14:38 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 0870E8700EC; Mon, 28 Nov 2011 12:14:35 +0100 (CET)
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 QF5EZzKc-WEZ; Mon, 28 Nov 2011 12:14:27 +0100 (CET)
Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id BC8EC8700D6; Mon, 28 Nov 2011 12:14:27 +0100 (CET)
Message-ID: <4ED36D13.5030002@globis.net>
Date: Mon, 28 Nov 2011 12:14:27 +0100
From: Ray Hunter 
User-Agent: Postbox Express 1.0.1 (Macintosh/20100705)
MIME-Version: 1.0
To: "v6ops@ietf.org WG" ,  "Livingood, Jason" 
Content-Type: multipart/alternative; boundary="------------020709070506080209000403"
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Nov 2011 11:14:40 -0000

This is a multi-part message in MIME format.
--------------020709070506080209000403
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I've followed progress of this document over various versions and IMHO 
you're doing a great job.

I have no major comments, but quite a lot of detailed editorial comments 
/ nits, included below.

Editorial Comments
===============

re: Title.
A slightly alternative way of looking at this operationally: is this not 
simply about Information Security and "Risk Mitigation Whilst 
Transitioning Content To IPv6"?

Operations people should be well used to that via Prince 2, ITIL, and 
other methodologies.
It's not "daunting": It's just another transformation project, where 
business risks need to be managed.

My take on an alternative title: s/Transitioning Content to IPv6/Risk 
Mitigation Whilst Transitioning Content To IPv6/


Section 4.1: If we mention [W6D], should we not also mention [v6ops] ?

Normally for risk mitigation, you'd introduce a table of potential risks 
cross-referenced to the potential/selected mitigation tactics. You've 
done this  descriptively already within the subsections, but a summary 
table might prove enlightening/useful.


Section 4.3.1-4.3.4:
/ When implemented on an automated basis in the future, DNS recursive 
resolvers listed in the whitelist could expand and contract dynamically/

Is this defined anywhere as a WG item? Otherwise would suggest s/When/If/

I have a concern with automation of whitelisting and potential DNS 
content instability as different providers implement uncoordinated 
changes on a "near-real-time basis", which could lead to some serious 
traffic flip-flopping at mega scale (IPv6 detected as stable -> IPv6 DNS 
record added -> IPv6 load increases -> link/device/network saturates -> 
IPv6 impairment (just 0.078% loss) -> IPv6 record deleted -> 
link/device/network stable -> IPv6 detected as stable)

 From the perspective of a remote (feeder) network this is NOT like 
global server load balancing of IPv4, where the traffic to other ISP 
peers may change, but the peering point will probably anyway be 
physically co-located at the same GIX, so traffic patterns _within_ the 
remote feeder network probably won't be greatly impacted any more than 
say a local BGP peering failure. DNS A->AAAA record changes could 
trigger use of a completely different network path, equipment, or 
peering, and so may even impact traffic flows within the feeder network.


Section 4.3.4 "Split DNS" Add a reference to BIND "view" configuration 
command?


/ DNS Blacklisting is also likely less labor intensive for a domain than 
performing DNS Resolver Whitelisting on a manual basis./

Is there any basis or evidence for this statement? Otherwise s/is also 
likely less/may be less/


I see no reference to the risk of assuming a "do nothing" tactic and 
staying with IPv4 for as long as possible, or a mitigation tactic of 
relying on others to provide IPv6 to IPv4 translation somewhere else 
outside of your domain as its "not my problem." That's always option one 
and two on any risk management plan, and the preferred/default option of 
many managements. You could well argue it's out of scope, but a pointer 
to an existing document would be nice.


nits
====

Section 2
s/Challenges When Transitioning Content to IPv6/Risks When Transitioning 
Content to IPv6/

Section 3
s/Challenges/Risks/

Section 4
s/Potential Migration Tactics/Potential Risk Mitigation Tactics/ ???

whole document
s/migration tactics/risk mitigation tactics/

s/there is not one approach/there is no single prescriptive approach/
s/in Section 2.1 
. 
One challenge/in Section 2.1 
, 
one challenge/
s/ the potential solutions [I-D.ietf-v6ops-happy-eyeballs 
]/the 
potential solutions e.g. [I-D.ietf-v6ops-happy-eyeballs 
]/
s/turning on a significant amount of IPv6 traffic is quite daunting and 
would carry a relatively high risk of network/turning on a significant 
amount of IPv6 traffic may carry a relatively high risk of network/
s/used to facilitate the migration to IPv6/used to mitigate risks during 
migration to IPv6/
s/key tactics/key risk mitigation tactics/
s/Use IPv6-Specicic Names/Use IPv6-Specific Names/
s/recursive resolver is, etc./recursive resolver is, and any other 
operational impacts./
s/These authoritative DNS servers selectively return AAAA resource 
records using the IP address of the DNS recursive resolver that has sent 
it a query/These authoritative DNS servers selectively return AAAA 
resource records or not, dependent on the IP address of the DNS 
recursive resolver that has sent it a query/
s/and an A record would be sent/any A resource records associated with 
the name WILL be sent/
s/However, if a DNS recursive resolver is matched in the whitelist, then 
AAAA resource records WILL be sent/However, if a DNS recursive resolver 
is matched in the whitelist, then AAAA resource records WILL be sent 
(any A resource records associated with the name MAY still be sent)/
s/manually-based/manually-maintained/

/Similarities to Content Delivery Networks and Global Server Load 
Balancing/ something odd with the formatting here. /Balancing/ is 
outside the HTML  tag.

s/cannot send email to a domain at all, with DNS Resolver 
Whitelisting/cannot send email to a domain at all, with DNS Resolver 
Blacklisting/

s/It is then up to end users with IPv6-related impairments to discover 
and fix any applicable impairments./The onus is then on end users with 
IPv6-related impairments to discover and fix any applicable impairments 
themselves. The advantage of this approach being that IPv6-related 
impairments should reduce over time, rather than being worked around ad 
infinitum./

s/Finally, the tactics listed in Section 4 are by no means 
exclusive./Finally, the tactics listed in Section 4 are by no means 
exclusive, nor exhaustive./

s/contact end userd directly concerning/contact end users directly 
concerning/

regards
RayH



--------------020709070506080209000403
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit








I've followed progress of this document over various versions and IMHO
you're doing a great job.



I have no major comments, but quite a lot of detailed editorial
comments / nits, included below.



Editorial Comments

===============



re: Title.

A slightly alternative way of looking at this operationally: is this
not simply about Information Security and "Risk Mitigation Whilst
Transitioning Content To IPv6"?



Operations people should be well used to that via Prince 2, ITIL, and
other methodologies.

It's not "daunting": It's just another transformation project, where
business risks need to be managed.



My take on an alternative title: s/Transitioning Content to IPv6/Risk
Mitigation Whilst Transitioning Content To IPv6/





Section 4.1: If we mention [W6D], should we not also mention [v6ops] ?



Normally for risk mitigation, you'd introduce a table of potential
risks cross-referenced to the potential/selected mitigation tactics.
You've done this  descriptively already within the subsections, but a
summary table might prove enlightening/useful.





Section 4.3.1-4.3.4:

/ When implemented on an automated basis in the future, DNS recursive
resolvers listed in the whitelist could expand and contract
dynamically/ 



Is this defined anywhere as a WG item? Otherwise would suggest
s/When/If/



I have a concern with automation of whitelisting and potential DNS
content
instability as different providers implement uncoordinated changes on a
"near-real-time basis", which could lead to some
serious traffic flip-flopping at mega scale (IPv6 detected as stable
-> IPv6 DNS record added -> IPv6 load increases ->
link/device/network saturates -> IPv6 impairment (just 0.078% loss)
-> IPv6 record deleted -> link/device/network stable -> IPv6
detected as stable)



>From the perspective of a remote (feeder) network this is NOT like
global server load balancing of IPv4, where the traffic to other ISP
peers may
change, but the peering point will probably anyway be physically
co-located at the same GIX, so traffic patterns _within_ the remote
feeder network
probably won't be greatly impacted any more than say a local BGP
peering failure. DNS A->AAAA record changes could trigger use of a
completely different network path, equipment, or peering, and so may
even impact traffic flows within the feeder network.





Section 4.3.4 "Split DNS" Add a reference to BIND "view" configuration
command?





/ DNS Blacklisting is also likely less labor intensive for a domain
than performing DNS Resolver Whitelisting on a manual basis./



Is there any basis or evidence for this statement? Otherwise s/is also
likely less/may be less/





I see no reference to the risk of assuming a "do nothing" tactic and
staying with IPv4 for as long as possible, or a mitigation tactic of
relying on others to provide IPv6 to IPv4 translation somewhere else
outside of your domain as its "not my problem." That's always option
one and two on any risk management plan, and the preferred/default
option of many managements. You could well argue it's out of scope, but
a pointer to an existing document would be nice.





nits

====



Section 2

s/Challenges When Transitioning Content to IPv6/Risks When
Transitioning Content to IPv6/



Section 3

s/Challenges/Risks/



Section 4

s/Potential Migration Tactics/Potential Risk
Mitigation Tactics/ ???



whole document

s/migration tactics/risk mitigation tactics/



s/there is not one approach/there is no single prescriptive approach/

s/in Section
2.1. One challenge/in Section
2.1, one challenge/

s/ the potential solutions [I-D.ietf-v6ops-happy-eyeballs]/the
potential solutions e.g. [I-D.ietf-v6ops-happy-eyeballs]/

s/turning on a significant amount of IPv6 traffic is quite daunting and
would carry a relatively high risk of network/turning on a significant
amount of IPv6 traffic may carry a relatively high risk of network/

s/used to facilitate the migration to IPv6/used to mitigate risks
during migration to IPv6/

s/key tactics/key risk mitigation tactics/

s/Use IPv6-Specicic Names/Use IPv6-Specific Names/

s/recursive resolver is, etc./recursive resolver is, and any other
operational impacts./

s/These authoritative DNS servers selectively return AAAA resource
records using the IP address of the DNS recursive resolver that has
sent it a query/These authoritative DNS servers selectively return AAAA
resource records or not, dependent on the IP address of the DNS
recursive resolver that has sent it a query/

s/and an A record would be sent/any A resource records associated with
the name WILL be sent/

s/However, if a DNS recursive resolver is matched in the whitelist,
then AAAA resource records WILL be sent/However, if a DNS recursive
resolver is matched in the whitelist, then AAAA resource records WILL
be sent (any A resource records associated with the name MAY still be
sent)/

s/manually-based/manually-maintained/



/Similarities to Content Delivery Networks and Global Server Load
Balancing/ something odd with the formatting here. /Balancing/ is
outside the HTML <span> tag.



s/cannot send email to a domain at all, with DNS Resolver
Whitelisting/cannot send email to a domain at all, with DNS Resolver
Blacklisting/



s/It is then up to end users with IPv6-related impairments to discover
and fix any applicable impairments./The onus is then on end users with
IPv6-related impairments to discover and fix any applicable impairments
themselves. The advantage of this approach being that IPv6-related
impairments should reduce over time, rather than being worked around ad
infinitum./



s/Finally, the tactics listed in Section 4 are by no means
exclusive./Finally, the tactics listed in Section 4 are by no means
exclusive, nor exhaustive./



s/contact end userd directly concerning/contact end users directly
concerning/



regards

RayH








--------------020709070506080209000403--

From ales.vizdal@t-mobile.cz  Mon Nov 28 03:30:49 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19EAE21F8CBF for ; Mon, 28 Nov 2011 03:30:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.206
X-Spam-Level: 
X-Spam-Status: No, score=-0.206 tagged_above=-999 required=5 tests=[AWL=0.744,  BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, 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 uCDaCmGMT-ZK for ; Mon, 28 Nov 2011 03:30:48 -0800 (PST)
Received: from mailhub1.t-mobile.cz (mailhub1.t-mobile.cz [62.141.0.149]) by ietfa.amsl.com (Postfix) with ESMTP id 476CD21F8CBC for ; Mon, 28 Nov 2011 03:30:48 -0800 (PST)
Received: from srvhk504.rdm.cz (unknown [10.246.143.96]) by mailhub1.t-mobile.cz (Postfix) with ESMTP id 77B0B28580B; Mon, 28 Nov 2011 12:30:47 +0100 (CET)
Received: from SRVHKE02.rdm.cz ([fe80::94ce:8456:f6fa:86a8]) by srvhk504.rdm.cz ([fe80::506:b9a6:d353:9494%12]) with mapi; Mon, 28 Nov 2011 12:30:47 +0100
From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= 
To: Ole Troan , jouni korhonen 
Date: Mon, 28 Nov 2011 12:30:42 +0100
Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
Thread-Index: Acytu0Lu227GtLQmS22fPV+mUTUqUwAA7DpQ
Message-ID: <1808340F7EC362469DDFFB112B37E2FCC5E99477F1@SRVHKE02.rdm.cz>
References: <2963F168-45CB-4042-8238-56DF538B0543@gmail.com><2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz> <8AF88A07-C1C5-4CD9-9E87-9D0F26504641@employees.org>
In-Reply-To: <8AF88A07-C1C5-4CD9-9E87-9D0F26504641@employees.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-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, 28 Nov 2011 11:30:49 -0000

Ole,

> -----Original Message-----
> From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of Ole Troan
> Sent: Monday, November 28, 2011 11:48 AM
> To: V=EDzdal Ale=B9
> Cc: Hemant Singh (shemant); jouni korhonen; v6ops@ietf.org
> Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
>=20
> Vizdal,
>=20
> different access networks may have different policies or the data link ty=
pe may have
> various restrictions with regards
> to address allocation. if it is unnumbered, SLAAC, DHCP or both SLAAC and=
 DHCP.
>=20
> e.g. typically Cable networks only use DHCP. DSL networks do either model=
. 6rd makes
> up an address based on an IPv4 address and so on.
>=20
> I don't understand how 3GPP links are any different. does it harm functio=
ning on a 3GPP
> link if the CE is _capable_ of doing DHCP address assignment?

There seems to be a misunderstanding, the point Jouni and myself are trying=
 to make is that=20
the IA_NA option is not required by the current 3GPP specs, so is less like=
ly to be supported
by the CEs (e.g. MiFi) and potentially preventing them to be compliant to t=
his RFC which we=20
see beneficial (the compliancy).

@Jouni, would you agree?

> cheers,
> Ole

Cheers,
Ales

> On Nov 28, 2011, at 11:20 , V=EDzdal Ale=B9 wrote:
>=20
> > Hemant,
> >
> >> -----Original Message-----
> >> From: Hemant Singh (shemant) [mailto:shemant@cisco.com]
> >> Sent: Sunday, November 27, 2011 6:06 PM
> >> To: V=EDzdal Ale=B9; Ole Troan; jouni korhonen
> >> Cc: v6ops@ietf.org
> >> Subject: RE: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
> >>
> >> Vizdal,
> >>
> >> -----Original Message-----
> >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf=
 Of V=EDzdal
> >> Ale=B9
> >> Sent: Saturday, November 26, 2011 5:02 PM
> >> To: Ole Troan; jouni korhonen
> >> Cc: v6ops@ietf.org
> >> Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
> >>
> >>
> >>> I have the same concern as Jouni that the IPv6 CE router (e.g. Mi-Fi =
device)
> having a
> >> 3GPP access
> >>> based WAN link only would be required to support the IA_NA option on =
the WAN
> link
> >> to be able to be
> >>> compliant to this RFC (I am saying on the WAN link, because this requ=
irement is
> >> placed under the WAA
> >>> - WAN Address Allocation section).
> >>
> >> The rfc6204bis document only supports a cellular client for DHCPv6 PD.=
  Thus any
> >> legacy 3GPP cellular client that does not support DHCPv6 PD acquisitio=
n is not
> >> supported by rfc6204bis.
> >
> > OK.
> >
> >> Thereafter if the cellular client supports DHCPv6 PD, the
> >> device already supports the IA_PD option, so what is the big deal for =
the client to
> also
> >> support the IA_NA option but the client does not use this option?
> >
> > What is the issue you currently see with relaxing this one for a non-DH=
CPv6 based
> address
> > allocation?
> >
> > Even if supported by the IPv6 CE, the support for it cannot be verified=
 as the 3GPP
> nodes
> > along the path do not support statefull address allocation.
> >
> > I would see beneficial to allow 'current' 3GPP compliant CEs to be comp=
liant to this
> RFC as well.
> >
> >> Thanks for catching the spelling error for "specified".  It has been f=
ixed.
> >
> > You're welcome.
> >
> >> Hemant
> >
> > Cheers,
> > Ales


From wbeebee@cisco.com  Mon Nov 28 06:23:20 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F70E21F8AE9 for ; Mon, 28 Nov 2011 06:23:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.532
X-Spam-Level: 
X-Spam-Status: No, score=-4.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q2TcpBASlKBJ for ; Mon, 28 Nov 2011 06:23:16 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id BC04921F84BA for ; Mon, 28 Nov 2011 06:23:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wbeebee@cisco.com; l=692; q=dns/txt; s=iport; t=1322490196; x=1323699796; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=m805KDI4/oTmbq0GEivF0YE2qsOQxctGOsQSZSsdWTs=; b=e/cVWrxdVfYh3QEZjtjDZ+bW/ymKbykezupGcmsmpD/B7rkG5PKcMa4W oC9bHxN9Z/rCYLUUOlLI5sWedzejwhmclohprgkishVpUW7/7PCeFgjjy +pUi3RXHcaGe/xKpA1oxFZo5y3NIS/8fkoV1Yg9RZ6sLARE0EA5PdHMX6 c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ar0FAPaY006tJV2Z/2dsb2JhbABDiUuhMQKBBYFyAQEBAwESAScCATwFDQEIgR0BAQQBDSeHY5gzAZ43imIEiCGMKY12hDM
X-IronPort-AV: E=Sophos;i="4.69,584,1315180800"; d="scan'208";a="39397144"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 28 Nov 2011 14:23:16 +0000
Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pASENGgC020526;  Mon, 28 Nov 2011 14:23:16 GMT
Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 28 Nov 2011 08:23:16 -0600
Received: from 161.44.175.128 ([161.44.175.128]) by XMB-RCD-201.cisco.com ([72.163.62.208]) with Microsoft Exchange Server HTTP-DAV ;  Mon, 28 Nov 2011 14:23:15 +0000
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Mon, 28 Nov 2011 09:23:15 -0500
From: Wes Beebee 
To: Mark Townsley , Victor Kuarsingh 
Message-ID: 
Thread-Topic: [v6ops] 6rd Sunsetting
Thread-Index: Acyt2UQph938xRYcKEeam6DOp2mMAA==
In-Reply-To: <262225DB-E7CF-42C4-B4C1-996AB17560C6@townsley.net>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 28 Nov 2011 14:23:16.0257 (UTC) FILETIME=[44E99910:01CCADD9]
Cc: Alexandre Cassen , "v6ops@ietf.org" , Claire Cheng 
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 28 Nov 2011 14:23:20 -0000

> I'm trying to boil down the CPE requirements to the point that, when it comes
> to 6rd and native interaction, it is very simple and predictable so that the
> operator can control the sunsetting. While I am aware that some CPEs are
> trying to do so, I think it is more troublesome when the CPE tries to
> automatically prefer one configuration vs. another as it is more logic for the
> standards forums to define and the CPE folks to follow.

A packet comes into the CE router from a host in the home and is destined
out of the home.  Is that packet encapsulated or not?

We HAVE to be able to answer that question in a completely deterministic and
consistent manner.

- Wes


From mark@townsley.net  Mon Nov 28 07:31:05 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7651D21F8B78 for ; Mon, 28 Nov 2011 07:31:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.799
X-Spam-Level: 
X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[AWL=0.801,  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 6wITiMEv3ixo for ; Mon, 28 Nov 2011 07:31:05 -0800 (PST)
Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id A261F21F8B29 for ; Mon, 28 Nov 2011 07:31:04 -0800 (PST)
Received: by lahj13 with SMTP id j13so704318lah.31 for ; Mon, 28 Nov 2011 07:31:03 -0800 (PST)
Received: by 10.152.123.144 with SMTP id ma16mr29005575lab.32.1322494263568; Mon, 28 Nov 2011 07:31:03 -0800 (PST)
Received: from ams-townsley-8712.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id pw12sm31975471lab.13.2011.11.28.07.30.57 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 28 Nov 2011 07:31:01 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Mark Townsley 
In-Reply-To: 
Date: Mon, 28 Nov 2011 16:30:55 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <97F6A3CC-E700-486E-A55D-FA982FB119E6@townsley.net>
References: 
To: Wes Beebee 
X-Mailer: Apple Mail (2.1084)
Cc: Alexandre Cassen , "v6ops@ietf.org" , Claire Cheng 
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 28 Nov 2011 15:31:05 -0000

On Nov 28, 2011, at 3:23 PM, Wes Beebee wrote:

>> I'm trying to boil down the CPE requirements to the point that, when =
it comes
>> to 6rd and native interaction, it is very simple and predictable so =
that the
>> operator can control the sunsetting. While I am aware that some CPEs =
are
>> trying to do so, I think it is more troublesome when the CPE tries to
>> automatically prefer one configuration vs. another as it is more =
logic for the
>> standards forums to define and the CPE folks to follow.
>=20
> A packet comes into the CE router from a host in the home and is =
destined
> out of the home.  Is that packet encapsulated or not?
>=20
> We HAVE to be able to answer that question in a completely =
deterministic and
> consistent manner.

To get your answer, I will ask you to first think of the 6rd interface =
as like any other interface, just virtual rather than physical. Also, =
that this virtual interface has two associated RIB entries, one for "CE =
to CE" traffic, and another "default route" for Internet destined =
traffic.=20

Since most networks beyond the CE will drop packets which are not =
sourced from within the delegated prefix for the given CE interface, the =
CE must route packets by their source address to the CE interface which =
has the correct associated delegated prefix. I believe you have captured =
this requirement in 6204bis, it just needs to apply to the 6rd virtual =
interface in the same way as any other interface with its own delegated =
prefix.=20

If there happen to be two interfaces with the same delegated prefix (one =
of the cases listed in 6rd-sunsetting), then the CE must decide which to =
send the packet on. Everything else being equal, physical over virtual =
is probably a good metric to have, and it works well in this case as =
well. So, for the specific case of one 6rd and one native interface, =
Internet-destined traffic should always prefer native over 6rd.

The more-specific "CE-to-CE" route continues to point to the 6rd virtual =
interface, so traffic destined for within the 6rd domain continues to be =
encapsulated and sent directly to other CEs (without traversing the BR).=20=


- Mark

>=20
> - Wes
>=20


From shemant@cisco.com  Mon Nov 28 07:44:52 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73C0821F8CF4 for ; Mon, 28 Nov 2011 07:44:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[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 34xh5+d4uNmp for ; Mon, 28 Nov 2011 07:44:51 -0800 (PST)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 24FA921F8CED for ; Mon, 28 Nov 2011 07:44:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=7830; q=dns/txt; s=iport; t=1322495091; x=1323704691; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=nBauNDXZIjr4mlXqVH+r3JnJ2VDeoe1nvbACFYD12gU=; b=C6cMSZFKEM9errbJgxfV0tVfPTXwmG1z+svQUeTm9qNWtLAetiRIO2Sa w02eCJFSMdo7D7cSg6wIJswN9sSFdDH58jFa7DdagnxN8xGkOqtdsaONY sjYwNxeJmj0iNqNrSAEAZbYYqyXnsmNnVkNkN5jdm0FxJqJZvFw8SvIF4 Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Aq0AAEmr006tJV2a/2dsb2JhbABDgk2YEZAggQWBcgEBAQQSAQkRA0kQAgEIEQQBAQsGFwEGAUUJCAEBBBMIGqA3AZ47iX9jBIghnlM
X-IronPort-AV: E=Sophos;i="4.69,584,1315180800"; d="scan'208,217";a="39397794"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 28 Nov 2011 15:44:50 +0000
Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pASFioMp016148;  Mon, 28 Nov 2011 15:44:50 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 28 Nov 2011 09:44:50 -0600
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCADE4.A9D71525"
Date: Mon, 28 Nov 2011 09:44:49 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF3FC@XMB-RCD-109.cisco.com>
In-Reply-To: <902984B4-71FE-4641-8E59-5F26006937C6@townsley.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] 6rd Sunsetting
Thread-Index: AcytmO7yIpwje82qTW+gFFSxJqlJdwASyXLw
References: <4C468F52-C08B-4B25-86FF-E599F0078946@townsley.net>  <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF325@XMB-RCD-109.cisco.com> <902984B4-71FE-4641-8E59-5F26006937C6@townsley.net>
From: "Hemant Singh (shemant)" 
To: "Mark Townsley" 
X-OriginalArrivalTime: 28 Nov 2011 15:44:50.0408 (UTC) FILETIME=[AA0DC680:01CCADE4]
Cc: Alexandre Cassen , v6ops@ietf.org, Claire Cheng 
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 28 Nov 2011 15:44:52 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CCADE4.A9D71525
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Mark,

=20

As I have already said in another email that either a protocol is needed
between the BR and the BNG/CMTS or an ad hoc set of steps to sunset 6rd.
The ad hoc set of steps to sunset will work and thus we can dispense
with any new protocol.   =20

=20

Hemant

=20

From: Mark Townsley [mailto:mark@townsley.net]=20
Sent: Monday, November 28, 2011 1:43 AM
To: Hemant Singh (shemant)
Cc: Victor Kuarsingh; Tina TSOU; Alexandre Cassen; v6ops@ietf.org;
Claire Cheng
Subject: Re: [v6ops] 6rd Sunsetting

=20

=20

On Nov 28, 2011, at 12:34 AM, Hemant Singh (shemant) wrote:





=20

=20

Agreed.  However, I am not discussing the CPE router.   I am discussing
the SP 6rd and native IPv6 domain and questioning a few SP issues.
Certainly the BR is not co-resident with the BNG/CMTS but when the  BR
is not I have already said where is the extra protocol to communicate
between the different BNG's/CMTS 's and the BR's to sunset 6rd? =20

=20

The BNG/CMTS and BR do not need an "extra protocol." I'm at a complete
loss as to where you are dreaming up this requirement.=20





I will reply to Mark's response in another email.

=20

When/if you do, please describe why in the world you think the BNG/CMTS
and the 6rd BR need to "communicate" with one another.

=20

- Mark





=20

Hemant

=20


------_=_NextPart_001_01CCADE4.A9D71525
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Mark,
 
As I have already said in another email that either a protocol is =
needed between the BR and the BNG/CMTS or an ad hoc set of steps to =
sunset 6rd.   The ad hoc set of steps to sunset will work and =
thus we can dispense with any new protocol.   =
 
 
Hemant
 
From:=
 =
Mark Townsley [mailto:mark@townsley.net] 
Sent: Monday, =
November 28, 2011 1:43 AM
To: Hemant Singh =
(shemant)
Cc: Victor Kuarsingh; Tina TSOU; Alexandre Cassen; =
v6ops@ietf.org; Claire Cheng
Subject: Re: [v6ops] 6rd =
Sunsetting
 
 
On =
Nov 28, 2011, at 12:34 AM, Hemant Singh (shemant) =
wrote:


 
=
 
Agreed.  However, I am not discussing the CPE =
router.   I am discussing the SP 6rd and native IPv6 domain =
and questioning a few SP issues.   Certainly the BR is not =
co-resident with the BNG/CMTS but when the  BR is not I have =
already said where is the extra protocol to communicate between the =
different BNG’s/CMTS ‘s and the BR’s to sunset =
6rd?  
=

 
The BNG/CMTS and BR do not need an "extra =
protocol." I'm at a complete loss as to where you are dreaming =
up this requirement. 


I will reply to Mark’s response in another =
email.
 
When/if you do, please describe why in the world you =
think the BNG/CMTS and the 6rd BR need to "communicate" with =
one another.
 
- =
Mark


 
Hemant
 

------_=_NextPart_001_01CCADE4.A9D71525--

From mark@townsley.net  Mon Nov 28 07:47:08 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3160D21F8CED for ; Mon, 28 Nov 2011 07:47:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.065
X-Spam-Level: 
X-Spam-Status: No, score=-3.065 tagged_above=-999 required=5 tests=[AWL=0.533,  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 Fj0te6jzJ1ld for ; Mon, 28 Nov 2011 07:47:07 -0800 (PST)
Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6A15121F8BF4 for ; Mon, 28 Nov 2011 07:47:07 -0800 (PST)
Received: by qyk32 with SMTP id 32so4002644qyk.31 for ; Mon, 28 Nov 2011 07:47:06 -0800 (PST)
Received: by 10.224.195.10 with SMTP id ea10mr11863205qab.16.1322495226524; Mon, 28 Nov 2011 07:47:06 -0800 (PST)
Received: from ams-townsley-8712.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id ha3sm34231371qab.2.2011.11.28.07.47.03 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 28 Nov 2011 07:47:04 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-44-590637962
From: Mark Townsley 
In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF3FC@XMB-RCD-109.cisco.com>
Date: Mon, 28 Nov 2011 16:47:01 +0100
Message-Id: 
References: <4C468F52-C08B-4B25-86FF-E599F0078946@townsley.net>  <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF325@XMB-RCD-109.cisco.com> <902984B4-71FE-4641-8E59-5F26006937C6@townsley.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF3FC@XMB-RCD-109.cisco.com>
To: "Hemant Singh (shemant)" 
X-Mailer: Apple Mail (2.1084)
Cc: Alexandre Cassen , v6ops@ietf.org, Claire Cheng 
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 28 Nov 2011 15:47:08 -0000

--Apple-Mail-44-590637962
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


On Nov 28, 2011, at 4:44 PM, Hemant Singh (shemant) wrote:

> Mark,
> =20
> As I have already said in another email that either a protocol is =
needed between the BR and the BNG/CMTS or an ad hoc set of steps to =
sunset 6rd.   The ad hoc set of steps to sunset will work and thus we =
can dispense with any new protocol.   =20

Great. As long as we agree not to invent a protocol here, I'm happy.=20

- Mark

> =20
> Hemant
> =20
> From: Mark Townsley [mailto:mark@townsley.net]=20
> Sent: Monday, November 28, 2011 1:43 AM
> To: Hemant Singh (shemant)
> Cc: Victor Kuarsingh; Tina TSOU; Alexandre Cassen; v6ops@ietf.org; =
Claire Cheng
> Subject: Re: [v6ops] 6rd Sunsetting
> =20
> =20
> On Nov 28, 2011, at 12:34 AM, Hemant Singh (shemant) wrote:
>=20
>=20
> =20
> =20
> Agreed.  However, I am not discussing the CPE router.   I am =
discussing the SP 6rd and native IPv6 domain and questioning a few SP =
issues.   Certainly the BR is not co-resident with the BNG/CMTS but when =
the  BR is not I have already said where is the extra protocol to =
communicate between the different BNG=92s/CMTS =91s and the BR=92s to =
sunset 6rd? =20
> =20
> The BNG/CMTS and BR do not need an "extra protocol." I'm at a complete =
loss as to where you are dreaming up this requirement.=20
>=20
>=20
> I will reply to Mark=92s response in another email.
> =20
> When/if you do, please describe why in the world you think the =
BNG/CMTS and the 6rd BR need to "communicate" with one another.
> =20
> - Mark
>=20
>=20
> =20
> Hemant
> =20


--Apple-Mail-44-590637962
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252


On Nov 28, 2011, at 4:44 PM, Hemant =
Singh (shemant) wrote:

As I =
have already said in another email that either a protocol is needed =
between the BR and the BNG/CMTS or an ad hoc set of steps to sunset =
6rd.   The ad hoc set of steps to sunset will work and thus we =
can dispense with any new protocol.   =
 

Gre=
at. As long as we agree not to invent a protocol here, I'm =
happy. 

- Mark

From: Mark Townsley =
[mailto:mark@townsley.net] 
Sent: Monday, November 28, 2011 =
1:43 AM
To: Hemant Singh =
(shemant)
Cc: Victor Kuarsingh; Tina =
TSOU; Alexandre Cassen; v6ops@ietf.org; Claire Cheng
Subject: Re: [v6ops] 6rd =
Sunsetting
On Nov 28, 2011, at 12:34 =
AM, Hemant Singh (shemant) wrote:


 
Agreed.  However, I am not =
discussing the CPE router.   I am discussing the SP 6rd and =
native IPv6 domain and questioning a few SP issues.   =
Certainly the BR is not co-resident with the BNG/CMTS but when the  =
BR is not I have already said where is the extra protocol to communicate =
between the different BNG=92s/CMTS =91s and the BR=92s to sunset =
6rd?  
 
The BNG/CMTS and BR do not need an "extra =
protocol." I'm at a complete loss as to where you are dreaming up =
this requirement. 
I will reply to Mark=92s response =
in another =
email.
 
When/if you do, please describe why in the world you =
think the BNG/CMTS and the 6rd BR need to "communicate" with one =
another.
- =
Mark

In-Reply-To: <262225DB-E7CF-42C4-B4C1-996AB17560C6@townsley.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] 6rd Sunsetting
Thread-Index: AcytmE2jJwoVM4ZdS1KaQw8L0sIePAATRHeA
References:  <262225DB-E7CF-42C4-B4C1-996AB17560C6@townsley.net>
From: "Hemant Singh (shemant)" 
To: "Mark Townsley" , "Victor Kuarsingh" 
X-OriginalArrivalTime: 28 Nov 2011 16:24:14.0005 (UTC) FILETIME=[2ADE0E50:01CCADEA]
Cc: Alexandre Cassen , v6ops@ietf.org, Claire Cheng 
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 28 Nov 2011 16:24:17 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CCADEA.2AA905F9
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Mark,

=20

Ad hoc steps are fine and we can skip defining any new protocol between
the BNG and the BR.   Please see below for a response to your "trying to
boil down the CPE requirements".  =20

=20

From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
Of Mark Townsley
Sent: Monday, November 28, 2011 1:38 AM
To: Victor Kuarsingh
Cc: Alexandre Cassen; v6ops@ietf.org; Claire Cheng
Subject: Re: [v6ops] 6rd Sunsetting

=20

=20

>I'm trying to boil down the CPE requirements to the point that, when it
comes to 6rd and native interaction, it is very simple and predictable
so >that the operator can control the sunsetting. While I am aware >that
some CPEs are trying to do so, I think it is more troublesome when the
CPE >tries to automatically prefer one configuration vs. another as it
is more logic for the standards forums to define and the CPE >folks to
follow.

=20

The Coexistence section of rfc6204bis in section 4.4.3 in bullet 5 and
the last paragraph already includes everything the CPE needs to do for
6rd and native interaction.  Folks should review the complete text below
and please point out what is missing that does not take care of CPE
router requirements that address (a) concurrent 6rd and native IPv6
operation, (b) sunsetting 6rd for both cases of native IPv6 prefix being
same or different than the 6rd prefix, (c) provide a use case that
explains why 6rd and native IPv6 run concurrently (in the last paragraph
with text related to RFC 4862 and the two-hour rule).   Apparently the
use case was not known to some folks.  Again, bullet 5 outlines
concurrent operation of 6rd and native IPv6 while the last paragraph of
the section outlines how 6rd is sunset.  The last paragraph is pertinent
to only when 6rd and native IPV6 use different prefixes with text such
as "multiple prefixes" used in the paragraph.  When prefixes are same,
there is a no-op on the CPE for any 6rd  prefix deprecation.  Further,
the deprecation of 6rd occurs when the CPE DHCPv4 Renew is not responded
to by the SP provisioning system and that forces the CPE to reset
DHCPv4.  On a new DHCPv4, the SP provisioning system does not return the
6rd DHCPv4 option and the CPE disables 6rd.  Note 6rd is already
disabled when the CPE resets to kick of a new DHCPv4. =20

=20

  [5.  Selection of 6rd tunnel or native IPv6 output interface on the CE
       router is determined by the source IPv6 address of the packet
       from a host, when different prefixes are available over 6rd vs.
       native IPv6.  If the two interfaces provide the CE router with
       the same prefix, then the CE router prefers the native IPv6
       interface to the 6rd interface for forwarding traffic out the WAN
       when both 6rd and native IPv6 interfaces are active.]
=20

=20

  [During a sunsetting activity such as deprecating 6rd and moving to
   native IPv6, the IPv6 CE router MUST immediately advertise the 6rd
   prefix with a Preferred Lifetime of zero and a Valid Lifetime of the
   lower of the current Valid Lifetime and two hours (which must be
   decremented in real time) in a Router Advertisement message as
   described in Section 5.5.3, (e) of [RFC4862].  Due to the two hours
   rule specified in [RFC4862], the 6rd and the native IPv6 prefix will
   coexist in the home network.  The two hours rule specified in section
   5.5.3 of [RFC4862] causes any deprecated prefix to linger on the node
   even when an RA has sent a Preferred Lifetime of zero to expire the
   prefix to the node.  During such coexistence of multiple prefixes,
   the CE router sends an ICMPv6 error for packets sourced or destined
   related to the deprecated prefix.  Note this document already
   includes text in bullet L-14 in section 4.3 for such a provision.]

=20

Thanks,

=20

Hemant


------_=_NextPart_001_01CCADEA.2AA905F9
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Mark,
 
Ad hoc steps are fine and we can skip defining any =
new protocol between the BNG and the BR.   Please see below =
for a response to your “trying to boil down the CPE =
requirements”.   
 
From:=
 =
v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of =
Mark Townsley
Sent: Monday, November 28, 2011 1:38 =
AM
To: Victor Kuarsingh
Cc: Alexandre Cassen; =
v6ops@ietf.org; Claire Cheng
Subject: Re: [v6ops] 6rd =
Sunsetting
 
 
>I'm trying to boil =
down the CPE requirements to the point that, when it comes to 6rd and =
native interaction, it is very simple and predictable so >that the operator can control the =
sunsetting. While I am aware >that some CPEs are trying to do so, I =
think it is more troublesome when the CPE >tries to automatically prefer one =
configuration vs. another as it is more logic for the standards forums =
to define and the CPE >folks to =
follow.
 
The =
Coexistence section of rfc6204bis in section 4.4.3 in bullet 5 and the =
last paragraph already includes everything the CPE needs to do for 6rd =
and native interaction.  Folks should review the complete text =
below and please point out what is missing that does not take care of =
CPE router requirements that address (a) concurrent 6rd and native IPv6 =
operation, (b) sunsetting 6rd for both cases of native IPv6 prefix being =
same or different than the 6rd prefix, (c) provide a use case that =
explains why 6rd and native IPv6 run concurrently (in the last paragraph =
with text related to RFC 4862 and the two-hour rule).   =
Apparently the use case was not known to some folks.  Again, bullet =
5 outlines concurrent operation of 6rd and native IPv6 while the last =
paragraph of the section outlines how 6rd is sunset.  The last =
paragraph is pertinent to only when 6rd and native IPV6 use different =
prefixes with text such as “multiple prefixes” used in the =
paragraph.  When prefixes are same, there is a no-op on the CPE for =
any 6rd  prefix deprecation.  Further, the deprecation of 6rd =
occurs when the CPE DHCPv4 Renew is not responded to by the SP =
provisioning system and that forces the CPE to reset DHCPv4.  On a =
new DHCPv4, the SP provisioning system does not return the 6rd DHCPv4 =
option and the CPE disables 6rd.  Note 6rd is already disabled when =
the CPE resets to kick of a new DHCPv4.  
 
  [5.  Selection of 6rd tunnel or =
native IPv6 output interface on the CE
       router =
is determined by the source IPv6 address of the =
packet
       from a =
host, when different prefixes are available over 6rd =
vs.
       native =
IPv6.  If the two interfaces provide the CE router =
with
       the same =
prefix, then the CE router prefers the native =
IPv6
       =
interface to the 6rd interface for forwarding traffic out the =
WAN
       when =
both 6rd and native IPv6 interfaces are =
active.]
 
 
  [During a sunsetting activity such as =
deprecating 6rd and moving to
   =
native IPv6, the IPv6 CE router MUST immediately advertise the =
6rd
   prefix with a Preferred Lifetime =
of zero and a Valid Lifetime of the
   =
lower of the current Valid Lifetime and two hours (which must =
be
   decremented in real time) in a =
Router Advertisement message as
   =
described in Section 5.5.3, (e) of [RFC4862].  Due to the two =
hours
   rule specified in [RFC4862], the =
6rd and the native IPv6 prefix will
   =
coexist in the home network.  The two hours rule specified in =
section
   5.5.3 of [RFC4862] causes any =
deprecated prefix to linger on the =
node
   even when an RA has sent a =
Preferred Lifetime of zero to expire =
the
   prefix to the node.  During =
such coexistence of multiple =
prefixes,
   the CE router sends an =
ICMPv6 error for packets sourced or =
destined
   related to the deprecated =
prefix.  Note this document =
already
   includes text in bullet L-14 =
in section 4.3 for such a provision.]
 
Thanks,
 
Hemant

------_=_NextPart_001_01CCADEA.2AA905F9--

From tom111.taylor@bell.net  Mon Nov 28 08:35:02 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 989CE21F8B14 for ; Mon, 28 Nov 2011 08:35:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.337
X-Spam-Level: 
X-Spam-Status: No, score=-99.337 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, J_CHICKENPOX_13=0.6, MSGID_FROM_MTA_HEADER=0.803, 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 OgpT4LitdsUj for ; Mon, 28 Nov 2011 08:35:02 -0800 (PST)
Received: from blu0-omc4-s18.blu0.hotmail.com (blu0-omc4-s18.blu0.hotmail.com [65.55.111.157]) by ietfa.amsl.com (Postfix) with ESMTP id 2281221F8B12 for ; Mon, 28 Nov 2011 08:35:02 -0800 (PST)
Received: from BLU0-SMTP92 ([65.55.111.135]) by blu0-omc4-s18.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 28 Nov 2011 08:35:01 -0800
X-Originating-IP: [76.70.77.190]
X-Originating-Email: [tom111.taylor@bell.net]
Message-ID: 
Received: from [192.168.2.17] ([76.70.77.190]) by BLU0-SMTP92.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 28 Nov 2011 08:35:00 -0800
Date: Mon, 28 Nov 2011 11:34:56 -0500
From: Tom Taylor 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Mark Townsley 
References:  <97F6A3CC-E700-486E-A55D-FA982FB119E6@townsley.net>
In-Reply-To: <97F6A3CC-E700-486E-A55D-FA982FB119E6@townsley.net>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 28 Nov 2011 16:35:00.0748 (UTC) FILETIME=[AC5B34C0:01CCADEB]
Cc: Alexandre Cassen , "v6ops@ietf.org" , Claire Cheng 
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 28 Nov 2011 16:35:02 -0000

Below, snipped to key points.

On 28/11/2011 10:30 AM, Mark Townsley wrote:
>
> On Nov 28, 2011, at 3:23 PM, Wes Beebee wrote:
>
...
>>
>> A packet comes into the CE router from a host in the home and is
>> destined out of the home.  Is that packet encapsulated or not?
>>
>> We HAVE to be able to answer that question in a completely
>> deterministic and consistent manner.
>
...
>
> If there happen to be two interfaces with the same delegated prefix
> (one of the cases listed in 6rd-sunsetting), then the CE must decide
> which to send the packet on. Everything else being equal, physical
> over virtual is probably a good metric to have, and it works well in
> this case as well. So, for the specific case of one 6rd and one
> native interface, Internet-destined traffic should always prefer
> native over 6rd.
>
[PTT] It would be a mistake to send encapsulated packets over the 
physical interface. This is Wes's point: how to avoid that mistake?
>
> - Mark
>
>>
>> - Wes
>>
>
> _______________________________________________ v6ops mailing list
> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops
>
>

From shemant@cisco.com  Mon Nov 28 09:33:17 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3204A21F8797 for ; Mon, 28 Nov 2011 09:33:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[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 E5MTGw3e3fcA for ; Mon, 28 Nov 2011 09:33:16 -0800 (PST)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 374D221F8713 for ; Mon, 28 Nov 2011 09:33:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=10943; q=dns/txt; s=iport; t=1322501596; x=1323711196; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=SMnRuFF63aHRiNDzIgVhmIAXRHZV2/btRx2xFCiH3Cc=; b=C04nW+RiGYMphShqZq0lwKFxlt5FWQ6pQro3kpbOWCpI8dGC78Ii9QqG MYO3KuzfrE+94KZcwsDHofQKNfT/N9KoBtF3FUVKdjMHTz+DxI9KMVCzF EZq7U/EUVPBSrgyLbPFSbNSE07yL5iSey20m9g2tT7oJC/o8UkhbyvPDi I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ArcAADTF006tJV2c/2dsb2JhbABDgk2XfIgfAYgAgQWBcgEBAQQSAQkRA0kMBAIBCBEEAQELBhcBBgFFCQgBAQQBEggah2uYXwGeRYl/YwSIIZ5T
X-IronPort-AV: E=Sophos;i="4.69,585,1315180800"; d="scan'208,217";a="39436285"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP; 28 Nov 2011 17:33:16 +0000
Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id pASHXFgK003574;  Mon, 28 Nov 2011 17:33:15 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 28 Nov 2011 11:33:15 -0600
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCADF3.CF3BE7D9"
Date: Mon, 28 Nov 2011 11:33:14 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF4CA@XMB-RCD-109.cisco.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] 6rd Sunsetting
Thread-Index: Acyt67K1dQZs3OZwStK2ELEdJdQbAgAB61pQ
References: <97F6A3CC-E700-486E-A55D-FA982FB119E6@townsley.net> 
From: "Hemant Singh (shemant)" 
To: "Tom Taylor" , "Mark Townsley" 
X-OriginalArrivalTime: 28 Nov 2011 17:33:15.0431 (UTC) FILETIME=[CF598370:01CCADF3]
Cc: Alexandre Cassen , v6ops@ietf.org, Claire Cheng 
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 28 Nov 2011 17:33:17 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CCADF3.CF3BE7D9
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Tom,

=20

-----Original Message-----
From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
Of Tom Taylor
Sent: Monday, November 28, 2011 11:35 AM
To: Mark Townsley
Cc: Alexandre Cassen; v6ops@ietf.org; Claire Cheng
Subject: Re: [v6ops] 6rd Sunsetting

=20

>[PTT] It would be a mistake to send encapsulated packets over the=20

>physical interface. This is Wes's point: how to avoid that mistake?

=20

See bullets 5 and 6 from section 4.4.3 of rfc6404bis which is at

=20

http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-03

=20

For your convenience, the bullets are reproduced below as well.

=20

[5.  Selection of 6rd tunnel or native IPv6 output interface on the CE

       router is determined by the source IPv6 address of the packet

       from a host, when different prefixes are available over 6rd vs.

       native IPv6.  If the two interfaces provide the CE router with

       the same prefix, then the CE router prefers the native IPv6

       interface to the 6rd interface for forwarding traffic out the WAN

       when both 6rd and native IPv6 interfaces are active.

=20

   6.  The CE router messages to the host the use of native IPv6 in

       preference to 6rd, in the case where the two interfaces use

       different prefixes.]

=20

Hemant


------_=_NextPart_001_01CCADF3.CF3BE7D9
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Tom,
 
-----Original Message-----
From: =
v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Tom =
Taylor
Sent: Monday, November 28, 2011 11:35 AM
To: Mark =
Townsley
Cc: Alexandre Cassen; v6ops@ietf.org; Claire =
Cheng
Subject: Re: [v6ops] 6rd Sunsetting
 
>[PTT] It would be a mistake to send =
encapsulated packets over the 
>physical interface. This is Wes's point: how to =
avoid that mistake?
 
See =
bullets 5 and 6 from section 4.4.3 of rfc6404bis which is =
at
 
http://to=
ols.ietf.org/html/draft-ietf-v6ops-6204bis-03
 
For =
your convenience, the bullets are reproduced below as =
well.
 
[5.  Selection of 6rd tunnel or native IPv6 =
output interface on the CE
       router is =
determined by the source IPv6 address of the =
packet
       from a host, when =
different prefixes are available over 6rd vs.
       native =
IPv6.  If the two interfaces provide the CE router =
with
       the same prefix, =
then the CE router prefers the native IPv6
       interface to the =
6rd interface for forwarding traffic out the WAN
       when both 6rd and =
native IPv6 interfaces are active.
 
   6.  The CE router messages to the =
host the use of native IPv6 in
       preference to =
6rd, in the case where the two interfaces use
       different =
prefixes.]
 
Hemant

------_=_NextPart_001_01CCADF3.CF3BE7D9--

From mark@townsley.net  Mon Nov 28 09:36:59 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B13421F8B8A for ; Mon, 28 Nov 2011 09:36:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.899
X-Spam-Level: 
X-Spam-Status: No, score=-2.899 tagged_above=-999 required=5 tests=[AWL=0.100,  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 bp1HX76bekWT for ; Mon, 28 Nov 2011 09:36:58 -0800 (PST)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7B5A021F8AC3 for ; Mon, 28 Nov 2011 09:36:58 -0800 (PST)
Received: by faap14 with SMTP id p14so458120faa.31 for ; Mon, 28 Nov 2011 09:36:57 -0800 (PST)
Received: by 10.205.127.135 with SMTP id ha7mr32251067bkc.3.1322501817310; Mon, 28 Nov 2011 09:36:57 -0800 (PST)
Received: from ams-townsley-8712.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id l5sm27550579bkv.9.2011.11.28.09.36.53 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 28 Nov 2011 09:36:54 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Mark Townsley 
In-Reply-To: 
Date: Mon, 28 Nov 2011 18:36:52 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <97F6A3CC-E700-486E-A55D-FA982FB119E6@townsley.net> 
To: Tom Taylor 
X-Mailer: Apple Mail (2.1084)
Cc: Alexandre Cassen , "v6ops@ietf.org" , Claire Cheng 
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 28 Nov 2011 17:36:59 -0000

On Nov 28, 2011, at 5:34 PM, Tom Taylor wrote:

> Below, snipped to key points.
>=20
> On 28/11/2011 10:30 AM, Mark Townsley wrote:
>>=20
>> On Nov 28, 2011, at 3:23 PM, Wes Beebee wrote:
>>=20
> ...
>>>=20
>>> A packet comes into the CE router from a host in the home and is
>>> destined out of the home.  Is that packet encapsulated or not?
>>>=20
>>> We HAVE to be able to answer that question in a completely
>>> deterministic and consistent manner.
>>=20
> ...
>>=20
>> If there happen to be two interfaces with the same delegated prefix
>> (one of the cases listed in 6rd-sunsetting), then the CE must decide
>> which to send the packet on. Everything else being equal, physical
>> over virtual is probably a good metric to have, and it works well in
>> this case as well. So, for the specific case of one 6rd and one
>> native interface, Internet-destined traffic should always prefer
>> native over 6rd.
>>=20
> [PTT] It would be a mistake to send encapsulated packets over the =
physical interface. This is Wes's point: how to avoid that mistake?

IPv6 traffic destined outside the 6rd domain should be over the native =
link, with no encapsulation in IPv4.=20

Traffic destined for within the 6rd domain ("CE to CE traffic") will =
most likely traverse a shorter path if encapsulated in IPv4, and does =
not require traversal of the 6rd BR path as well.  So, this traffic =
continues over 6rd until 6rd can be fully disabled on the CE.=20

The idea here is to choose what is most likely the shortest path, and to =
reduce BR utilization.=20

- Mark

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


From Ted.Lemon@nominum.com  Mon Nov 28 09:43:50 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B61C21F8801 for ; Mon, 28 Nov 2011 09:43:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.196
X-Spam-Level: 
X-Spam-Status: No, score=-106.196 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 4OaWbeQ9tiXb for ; Mon, 28 Nov 2011 09:43:50 -0800 (PST)
Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id A18F221F8AFC for ; Mon, 28 Nov 2011 09:43:49 -0800 (PST)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKTtPIVStPRhbSrbvWXcjTniN0e5UjDNc/@postini.com; Mon, 28 Nov 2011 09:43:49 PST
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id B054D1B809F for ; Mon, 28 Nov 2011 09:43:48 -0800 (PST)
Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 1761B190052; Mon, 28 Nov 2011 09:43:46 -0800 (PST) (envelope-from Ted.Lemon@nominum.com)
Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.01.0339.001; Mon, 28 Nov 2011 09:43:46 -0800
From: Ted Lemon 
To: Ole Troan 
Thread-Topic: [v6ops] DHCPv6 option for MAX_SOL_RT
Thread-Index: AQHMpBVS9v5OyU3dDEaf8biIUoZIIJWwMYMAgACJcgCAAANuAP//e/aAgAD3r4CAAQPRAIAAGkmAgAAkTwCAAEPzAIAAvrKAgAABC4CAAAnSAIAABdOAgAVG1oCAAFm1gIAAEJAAgAABEACAAAd2AIAABASAgAKnm4CAAAHjAIAAAqoAgAABuICAAAIeAIAAAugAgAAB5YCAABx9gIAAuogAgACIvoCAABbpgIAFDGiAgAAP+gCAAAP7gIAAAimAgAACG4CAAAQKAIAAjuWA
Date: Mon, 28 Nov 2011 17:43:45 +0000
Message-ID: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.1.10]
Content-Type: multipart/alternative; boundary="_000_B7B62E0968B443DDB28A2FF1633DA2F2nominumcom_"
MIME-Version: 1.0
Cc: IPv6 Operations , Ralph Droms 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 28 Nov 2011 17:43:50 -0000

--_000_B7B62E0968B443DDB28A2FF1633DA2F2nominumcom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

On Nov 28, 2011, at 4:12 AM, Ole Troan wrote:
that's certainly _not_ the intention when we wrote 3633. where in section 6=
.2.7 of 4861 does it say a router should do anything with the M/O flags, ap=
art from consistency checking them? 3633 is a protocol between _routers_.

Interesting.   Of course, the requesting router isn't really a router until=
 its request is satisfied.   Possibly it's a DHCP client that's only going =
to get an IA_NA.   But this is certainly a good point.


--_000_B7B62E0968B443DDB28A2FF1633DA2F2nominumcom_
Content-Type: text/html; charset="us-ascii"
Content-ID: <1E73147A93F2F54FB33CDAF461E483E9@nominum.com>
Content-Transfer-Encoding: quoted-printable









On Nov 28, 2011, at 4:12 AM, Ole Troan wrote:


that's
 certainly _not_ the intention when we wrote 3633. where in section 6.2.7 o=
f 4861 does it say a router should do anything with the M/O flags, apart fr=
om consistency checking them? 3633 is a protocol between _routers_.








Interesting.   Of course, the requesting router isn't really a ro=
uter until its request is satisfied.   Possibly it's a DHCP client tha=
t's only going to get an IA_NA.   But this is certainly a good point.<=
/div>








--_000_B7B62E0968B443DDB28A2FF1633DA2F2nominumcom_--

From victor.kuarsingh@gmail.com  Mon Nov 28 10:10:48 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9487721F8CAE for ; Mon, 28 Nov 2011 10:10:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.38
X-Spam-Level: 
X-Spam-Status: No, score=-2.38 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, 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 eEdZdiSWhQgt for ; Mon, 28 Nov 2011 10:10:48 -0800 (PST)
Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6CCD421F8D4E for ; Mon, 28 Nov 2011 10:10:47 -0800 (PST)
Received: by qyk32 with SMTP id 32so4189021qyk.31 for ; Mon, 28 Nov 2011 10:10:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding; bh=sM41IsNJjZNVXwrXBbEDvVnONvvHd2cNjqWh9lLqJxo=; b=JpdRE7OQI9+BgsCJGF8sU3Stu17H7u+ewp0Ucbp4FJYUNQHK1OZlBa48H4jYlf41PU yrzeumBH031OuZKbambu6DZR6aRdCAUuZz/KhlPBPgHDzNQfK1F7OEQ1pVv7He3TIz1T 2GjqDJY7Ccw8U9Xi5Umjo25Y/jzCVdPV39n1I=
Received: by 10.229.11.141 with SMTP id t13mr3442744qct.275.1322503838266; Mon, 28 Nov 2011 10:10:38 -0800 (PST)
Received: from [192.168.1.13] ([74.198.9.74]) by mx.google.com with ESMTPS id ed2sm34689324qab.15.2011.11.28.10.10.35 (version=SSLv3 cipher=OTHER); Mon, 28 Nov 2011 10:10:36 -0800 (PST)
User-Agent: Microsoft-MacOutlook/14.0.0.100825
Date: Mon, 28 Nov 2011 13:10:32 -0500
From: Victor Kuarsingh 
To: Mark Townsley , Tom Taylor 
Message-ID: 
Thread-Topic: [v6ops] 6rd Sunsetting
In-Reply-To: 
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: Alexandre Cassen , "v6ops@ietf.org" , Claire Cheng 
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 28 Nov 2011 18:10:48 -0000

Mark,

>
>On Nov 28, 2011, at 5:34 PM, Tom Taylor wrote:
>
>> Below, snipped to key points.
>> 
>> On 28/11/2011 10:30 AM, Mark Townsley wrote:
>>> 
>>> On Nov 28, 2011, at 3:23 PM, Wes Beebee wrote:
>>> 
>> ...
>>>> 
>>>> A packet comes into the CE router from a host in the home and is
>>>> destined out of the home.  Is that packet encapsulated or not?
>>>> 
>>>> We HAVE to be able to answer that question in a completely
>>>> deterministic and consistent manner.
>>> 
>> ...
>>> 
>>> If there happen to be two interfaces with the same delegated prefix
>>> (one of the cases listed in 6rd-sunsetting), then the CE must decide
>>> which to send the packet on. Everything else being equal, physical
>>> over virtual is probably a good metric to have, and it works well in
>>> this case as well. So, for the specific case of one 6rd and one
>>> native interface, Internet-destined traffic should always prefer
>>> native over 6rd.
>>> 
>> [PTT] It would be a mistake to send encapsulated packets over the
>>physical interface. This is Wes's point: how to avoid that mistake?
>
>IPv6 traffic destined outside the 6rd domain should be over the native
>link, with no encapsulation in IPv4.
>
>Traffic destined for within the 6rd domain ("CE to CE traffic") will most
>likely traverse a shorter path if encapsulated in IPv4, and does not
>require traversal of the 6rd BR path as well.  So, this traffic continues
>over 6rd until 6rd can be fully disabled on the CE.
>
>The idea here is to choose what is most likely the shortest path, and to
>reduce BR utilization.

* Sorry for long email....

I am not trying to be too disruptive in this thread, but did want to note
a few points (which you may or may not agree with).

I think we are assuming that the CE to CE path would be "shortest" if
using 6RD directly on both endpoints (where one is now Native v6/6RD and
the other only 6RD). In my mind, "shortest" path would also include
performance and overall delay to get form one host to the other (home
network host to home network host).

I think that the performance of the 6RD function (I.e.
Encapsulation/decapsulation performance) on the CE would be a factor when
compared to a network placed/resident BR.  Also, the placement of BRs may
be be optimally placed such that the actual network path may be similar
(but unless co-located with the BNG there will be uses cases where this
may not be possible).

If utilization on the BR is not the key point here, then how important is
CE to CE performance (let's say that there is a small to measurable
difference) when considering the entire transition eco-system?  Does
making this specific flow type (one flow use case) warrant us solving this
issue by adding in state/routing complexity into the CPE to achieve this?

In my mind (which seems to be somewhat at odds with others), I would want
to choose an option which would cause a device to stop doing 6RD when
Native IPv6 is available (bias declared).

I say this since it would add a level of determinism to what I would
expect (say an operator has only course level control as to what
parameters they give each CPE).  This type of determinism goes a long way
for operations and customer care folks (when troubleshooting problems).

I am not saying we cannot make the suggested behaviour (as per drafts in
discussion) work, but other then some optimizations on the CE to CE flows
(within a given 6RD domain), are there other significant gains? (perhaps I
am somewhat ignorant to the gambit of benefits).

(this next point may be a bit off topic)

If re-addressing is one of the the big issues, I am not sure if this can
be avoided (in totality).  6RD to Native IPv6 transition is just one use
case where I need to re-address a CPE/home network.  I have all sorts of
uses cases where this will happen - so we will need to solve the IPv6
renumbering/stability case anyway.  In our network, I would see the move
from 6RD to Native IPv6 (in the prefix retention case) a renumbering
exercise from one Interface type to another (if I can figure out how to
offer the same prefix and not break all types of rules and provisioning
systems at the same time).

Again, I would prefer a cut over from one interface to the other (virtual
to native).  This is what I would ask my vendor to implement.  Once I add
in Native to a capable CPE, I would expect the CPE to go native. I am
hoping there is an option for this within all the proposals.

Sorry to be potentially digging up old bones on this.. I tried to review
entire email thread.

Thoughts?

Victor K




> 
>
>- Mark
>
>>> 
>>> - Mark
>>> 
>>>> 
>>>> - Wes
>>>> 
>>> 
>>> _______________________________________________ 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 shemant@cisco.com  Mon Nov 28 10:20:03 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39D3321F899F for ; Mon, 28 Nov 2011 10:20:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001,  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 7g6LKHwfyDak for ; Mon, 28 Nov 2011 10:20:02 -0800 (PST)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 9442F21F88B7 for ; Mon, 28 Nov 2011 10:20:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=910; q=dns/txt; s=iport; t=1322504402; x=1323714002; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=dlk6pdzZlBfUa/MrktF93jnV67CPXFz5Z3GgeohVq9Q=; b=RheTo6N37fQVr2YQ1nRxwUOm2q7Owo3280mPqL4RXBq1HdxeJL1+Tm8t tof3RbhKASQfUjkC+zEafrNwdBehH9zhJFGoY2ROIIxLiMQ1fSeCYZbKt 5AZHrCEE8WGBFQDTBTHCicPsjrmDvwpw0aAvsdgzzXyIXB0k36zJgwkl/ I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Aq0AAGrQ006tJXHA/2dsb2JhbABDmkuQIIEFgXIBAQEEEgEdCj8MBAIBCBEEAQELBhcBBgFFCQgBAQQBEggaoEsBnkiJf2MEiCGeUw
X-IronPort-AV: E=Sophos;i="4.69,585,1315180800"; d="scan'208";a="39458774"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-4.cisco.com with ESMTP; 28 Nov 2011 18:20:02 +0000
Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id pASIK1SC013296;  Mon, 28 Nov 2011 18:20:01 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 28 Nov 2011 12:20:01 -0600
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 28 Nov 2011 12:20:00 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF539@XMB-RCD-109.cisco.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] 6rd Sunsetting
Thread-Index: Acyt9FmHGVoYXKE1SlWwJlc/+eTrAwABZaew
References: <97F6A3CC-E700-486E-A55D-FA982FB119E6@townsley.net> 
From: "Hemant Singh (shemant)" 
To: "Mark Townsley" , "Tom Taylor" 
X-OriginalArrivalTime: 28 Nov 2011 18:20:01.0719 (UTC) FILETIME=[58071470:01CCADFA]
Cc: Alexandre Cassen , v6ops@ietf.org, Claire Cheng 
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 28 Nov 2011 18:20:03 -0000

Mark,

-----Original Message-----
From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
Of Mark Townsley
Sent: Monday, November 28, 2011 12:37 PM
To: Tom Taylor
Cc: Alexandre Cassen; v6ops@ietf.org; Claire Cheng
Subject: Re: [v6ops] 6rd Sunsetting


>IPv6 traffic destined outside the 6rd domain should be over the native
link, with no encapsulation in IPv4.=20

>Traffic destined for within the 6rd domain ("CE to CE traffic") will
most likely traverse a shorter path if encapsulated in IPv4, and does
not require traversal >of the 6rd BR path as well.  So, this traffic
continues over 6rd until 6rd can be fully disabled on the CE.=20

>The idea here is to choose what is most likely the shortest path, and
to reduce BR utilization.=20

Good rule above.  If you see RFC 3484, its section 6, and Rule 7, the
rule specifies what you have mentioned above. =20

Hemant

From bs7652@att.com  Mon Nov 28 11:02:57 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5159121F845E for ; Mon, 28 Nov 2011 11:02:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.998
X-Spam-Level: 
X-Spam-Status: No, score=-105.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 c1pYy2HAbHPl for ; Mon, 28 Nov 2011 11:02:54 -0800 (PST)
Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id 8AD6E1F0C34 for ; Mon, 28 Nov 2011 11:02:53 -0800 (PST)
X-Env-Sender: bs7652@att.com
X-Msg-Ref: server-11.tower-119.messagelabs.com!1322506969!3189719!1
X-Originating-IP: [144.160.20.146]
X-StarScan-Version: 6.3.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 32169 invoked from network); 28 Nov 2011 19:02:49 -0000
Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-11.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 28 Nov 2011 19:02:49 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pASJ1Lr8018735; Mon, 28 Nov 2011 14:01:22 -0500
Received: from 01AL10015010626.AD.BLS.COM (sfldmibbcraeninet1-v2.pmtr.mwst.att.com [10.231.16.33]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pASJ1GHw018569; Mon, 28 Nov 2011 14:01:17 -0500
Received: from 01NC27689010627.AD.BLS.COM ([90.144.44.202]) by 01AL10015010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 28 Nov 2011 13:01:53 -0600
Received: from 01NC27689010650.AD.BLS.COM ([90.144.44.120]) by 01NC27689010627.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 28 Nov 2011 14:01:51 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCAE00.2FD1BB84"
Date: Mon, 28 Nov 2011 14:01:51 -0500
Message-ID: <750BF7861EBBE048B3E648B4BB6E8F4F2106F5DE@crexc50p>
In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3035EEF82@XMB-RCD-109.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] 6rd Sunsetting
Thread-Index: Acyp5CNpIkZczFjvREWkaYbC7PsaVAAEh59AAPyk8PA=
References:  <750BF7861EBBE048B3E648B4BB6E8F4F20B124DE@crexc50p> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EEEBA@XMB-RCD-109.cisco.com> <82DD1735-321E-44CB-8E1E-FF7C3402A371@townsley.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EEF82@XMB-RCD-109.cisco.com>
From: "STARK, BARBARA H" 
To: "Hemant Singh (shemant)" , "Mark Townsley" 
X-OriginalArrivalTime: 28 Nov 2011 19:01:51.0603 (UTC) FILETIME=[3008FC30:01CCAE00]
Cc: v6ops@ietf.org
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 28 Nov 2011 19:02:57 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CCAE00.2FD1BB84
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Yes, We still need manual configuration. Not all access networks
currently have DHCPv4 servers (e.g., PPPoE), so it will not be possible
to supply 6rd config via DHCPv4. Some consumers will be happy to get
TR-069-managed routers from their ISP, which will take care of
automating 6rd config for them. But there exist people who do not like
or want to use an ISP router. They want to use their own. And they
should have that right. Manual configuration is for them.

=20

I see no need for additional guidance. To me, the context of the "manual
configuration" requirement makes it clear that we are talking about
exactly the same parameters as the DHCPv4 6rd option. Those parameters
are all non-customer-specific. They can be easily conveyed to the type
of people who would want to use an off-the-shelf router for this
purpose. There's nothing special about them.

Barbara

=20

From: Hemant Singh (shemant) [mailto:shemant@cisco.com]=20
Sent: Wednesday, November 23, 2011 10:42 AM
To: Mark Townsley
Cc: STARK, BARBARA H; v6ops@ietf.org
Subject: RE: [v6ops] 6rd Sunsetting

=20

Mark,

=20

Thanks.  I agree.  Barbara,  based on Mark's reply, do we still need
manual configuration for 6rd in rfc6204bis and if so, what more for
guidance would you like?

=20

Hemant

=20

From: Mark Townsley [mailto:mark@townsley.net]=20
Sent: Wednesday, November 23, 2011 8:31 AM
To: Hemant Singh (shemant)
Cc: STARK, BARBARA H; v6ops@ietf.org
Subject: Re: [v6ops] 6rd Sunsetting

=20

=20

I think that manually configured 6rd, or manually configured anything
really, should be squarely out of scope whenever possible. I think the
WG should focus on default behavior and configuration handled via our
protocols. Once you've opened a user-level interface, all bets are off.=20

=20

That said, a manually configured 6rd interface should not be difficult
as long as you don't try to treat it "special". It's just another
interface like any other on the router. It has its own entry in the
forwarding table, and rules that are consistent with what we should
define for an ISP-configured 6rd interface. Everything we have discussed
here in terms of what is in 6rd-sunsetting and source routing to the
correct interface apply perfectly well, even if you have manual and
SP-configured interfaces (not to mention an HE tunnel on the side, etc.)

=20

The hard part comes when the CPE tries to become too intelligent for its
own good, automatically preferring one type of interface configuration
over another (note that I didn't say preferring one *route* over another
when the entries in the forwarding table are otherwise equal, I said
preferring one type of *configuration* over the other). I think this is
inherently bad as it means every single time there is a new type of
interface (virtual or otherwise) you have to fit it into a logic table
of what is and is not allowed. As long as the router can handle multiple
interfaces generically, it should "do as it's told", bring up interfaces
it has SP-supported or explicit manual configuration for, and route
accordingly. =20

=20

For troubleshooting, RFC 5969 includes advice on how to construct a
packet that will not only test the path between the CE and BR, it will
tell you which BR that packet happened to traverse. One could run a
BFD-like keepalive on a timer on the 6rd tunnel (the "NUD" section
Hemant refers to), but I think that's overkill for 6rd as long as you
have a well-supported BR deployment to plug into. If you are using the
6rd config with a single BR that is not well-supported, you might want
the CE to declare the interface down when a periodic NUD check fails. It
should be clear though that this is far removed from a "production"
ISP-supported 6rd deployment, and much more of a "trial" type of
operation that I think 6204-bis should not have to worry about.=20

=20

- Mark

=20

=20

On Nov 23, 2011, at 11:53 AM, Hemant Singh (shemant) wrote:

=20

=20

From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
Of STARK, BARBARA H
Sent: Tuesday, November 15, 2011 10:33 AM
To: v6ops@ietf.org
Subject: Re: [v6ops] 6rd Sunsetting

=20

=20

>But when the CE router was manually configured for 6rd, I have no clue
what this means. How is the manually-configured CE router supposed to
know whether or not 6rd is configured by >the SP? Some guidance in this
area would be appreciated. For example, should the CE router test to see
if the BR is reachable, and if not assume that 6rd is not configured by
the SP?

=20

How can a subscriber in the home manually configure the CE router for
four 6rd parameters including the IPv4 address of the BR unless the
subscriber called the SP and got the information to configure manually.
Thus the SP knows about the CPE router in the subscriber's home and also
the CE router does not need to test if 6rd is configured by the SP.  If
the CE router still wants to test, then use the NUD specified in section
8 of RFC 5969.

=20

Hemant

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

=20


------_=_NextPart_001_01CCAE00.2FD1BB84
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Yes, We =
still need manual configuration. Not all access networks currently have =
DHCPv4 servers (e.g., PPPoE), so it will not be possible to supply 6rd =
config via DHCPv4. Some consumers will be happy to get TR-069-managed =
routers from their ISP, which will take care of automating 6rd config =
for them. But there exist people who do not like or want to use an ISP =
router. They want to use their own. And they should have that right. =
Manual configuration is for them.
 =

I see no =
need for additional guidance. To me, the context of the “manual =
configuration” requirement makes it clear that we are talking =
about exactly the same parameters as the DHCPv4 6rd option. Those =
parameters are all non-customer-specific. They can be easily conveyed to =
the type of people who would want to use an off-the-shelf router for =
this purpose. There’s nothing special about =
them.
Barbara
 
From:=
 =
Hemant Singh (shemant) [mailto:shemant@cisco.com] 
Sent: =
Wednesday, November 23, 2011 10:42 AM
To: Mark =
Townsley
Cc: STARK, BARBARA H; =
v6ops@ietf.org
Subject: RE: [v6ops] 6rd =
Sunsetting
 
Mark,
 
Thanks.  I agree.  Barbara,  based on Mark’s =
reply, do we still need manual configuration for 6rd in rfc6204bis and =
if so, what more for guidance would you like?
 
Hemant
 
From:=
 =
Mark Townsley [mailto:mark@townsley.net] 
Sent: Wednesday, =
November 23, 2011 8:31 AM
To: Hemant Singh =
(shemant)
Cc: STARK, BARBARA H; =
v6ops@ietf.org
Subject: Re: [v6ops] 6rd =
Sunsetting
 
 
I =
think that manually configured 6rd, or manually configured anything =
really, should be squarely out of scope whenever possible. I think the =
WG should focus on default behavior and configuration handled via our =
protocols. Once you've opened a user-level interface, all bets are =
off. 
 
That said, a manually configured 6rd interface should =
not be difficult as long as you don't try to treat it =
"special". It's just another interface like any other on the =
router. It has its own entry in the forwarding table, and rules that are =
consistent with what we should define for an ISP-configured 6rd =
interface. Everything we have discussed here in terms of what is in =
6rd-sunsetting and source routing to the correct interface apply =
perfectly well, even if you have manual and SP-configured interfaces =
(not to mention an HE tunnel on the side, =
etc.)
 
The hard part comes when the CPE tries to become too =
intelligent for its own good, automatically preferring one type of =
interface configuration over another (note that I didn't say preferring =
one *route* over another when the entries in the forwarding table are =
otherwise equal, I said preferring one type of *configuration* over the =
other). I think this is inherently bad as it means every single time =
there is a new type of interface (virtual or otherwise) you have to fit =
it into a logic table of what is and is not allowed. As long as the =
router can handle multiple interfaces generically, it should "do as =
it's told", bring up interfaces it has SP-supported or explicit =
manual configuration for, and route accordingly. =
 
 
For troubleshooting, RFC 5969 includes advice on how =
to construct a packet that will not only test the path between the CE =
and BR, it will tell you which BR that packet happened to =
traverse. One could run a BFD-like keepalive on a timer on the 6rd =
tunnel (the "NUD" section Hemant refers to), but I think =
that's overkill for 6rd as long as you have a well-supported BR =
deployment to plug into. If you are using the 6rd config with a single =
BR that is not well-supported, you might want the CE to declare the =
interface down when a periodic NUD check fails. It should be clear =
though that this is far removed from a "production" =
ISP-supported 6rd deployment, and much more of a "trial" type =
of operation that I think 6204-bis should not have to worry =
about. 
 
- =
Mark
 
 
On Nov 23, 2011, at 11:53 AM, Hemant Singh (shemant) =
wrote:
 
 
From:=
 v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org=
] On Behalf Of STARK, BARBARA =
H
Sent: Tuesday, November 15, 2011 =
10:33 AM
To: v6ops@ietf.org
Subject: Re: [v6ops] 6rd =
Sunsetting
 
 
>But when the CE router was manually configured for 6rd, I have no =
clue what this means. How is the manually-configured CE router supposed =
to know whether or not 6rd is configured by >the SP? Some guidance in =
this area would be appreciated. For example, should the CE router test =
to see if the BR is reachable, and if not assume that 6rd is not =
configured by the SP?
 
How can a subscriber in the home manually configure the CE router for =
four 6rd parameters including the IPv4 address of the BR unless the =
subscriber called the SP and got the information to configure =
manually.  Thus the SP knows about the CPE router in the =
subscriber’s home and also the CE router does not need to test if =
6rd is configured by the SP.  If the CE router still wants to test, =
then use the NUD specified in section 8 of RFC =
5969.
 
Hemant
_________=
______________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org=
/mailman/listinfo/v6ops
 

------_=_NextPart_001_01CCAE00.2FD1BB84--

From mark@townsley.net  Mon Nov 28 11:07:58 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1946A1F0C34 for ; Mon, 28 Nov 2011 11:07:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.919
X-Spam-Level: 
X-Spam-Status: No, score=-2.919 tagged_above=-999 required=5 tests=[AWL=0.080,  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 ygxtOoBLa42S for ; Mon, 28 Nov 2011 11:07:57 -0800 (PST)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id CF8301F0C59 for ; Mon, 28 Nov 2011 11:07:56 -0800 (PST)
Received: by faap14 with SMTP id p14so535525faa.31 for ; Mon, 28 Nov 2011 11:07:56 -0800 (PST)
Received: by 10.205.139.65 with SMTP id iv1mr34651355bkc.34.1322507275711; Mon, 28 Nov 2011 11:07:55 -0800 (PST)
Received: from ams-townsley-8712.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id p13sm9688831bkd.4.2011.11.28.11.07.51 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 28 Nov 2011 11:07:53 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Mark Townsley 
In-Reply-To: 
Date: Mon, 28 Nov 2011 20:07:50 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <7D1B37E6-74D2-4205-9D85-FB1032866CCF@townsley.net>
References: 
To: Victor Kuarsingh 
X-Mailer: Apple Mail (2.1084)
Cc: Alexandre Cassen , "v6ops@ietf.org" , Claire Cheng 
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 28 Nov 2011 19:07:58 -0000

On Nov 28, 2011, at 7:10 PM, Victor Kuarsingh wrote:

>>=20
>=20
> * Sorry for long email....
>=20
> I am not trying to be too disruptive in this thread, but did want to =
note
> a few points (which you may or may not agree with).
>=20
> I think we are assuming that the CE to CE path would be "shortest" if
> using 6RD directly on both endpoints (where one is now Native v6/6RD =
and
> the other only 6RD). In my mind, "shortest" path would also include
> performance and overall delay to get form one host to the other (home
> network host to home network host).
>=20
> I think that the performance of the 6RD function (I.e.
> Encapsulation/decapsulation performance) on the CE would be a factor =
when
> compared to a network placed/resident BR.  Also, the placement of BRs =
may
> be be optimally placed such that the actual network path may be =
similar
> (but unless co-located with the BNG there will be uses cases where =
this
> may not be possible).
>=20
> If utilization on the BR is not the key point here, then how important =
is
> CE to CE performance (let's say that there is a small to measurable
> difference) when considering the entire transition eco-system?  Does
> making this specific flow type (one flow use case) warrant us solving =
this
> issue by adding in state/routing complexity into the CPE to achieve =
this?
>=20
> In my mind (which seems to be somewhat at odds with others), I would =
want
> to choose an option which would cause a device to stop doing 6RD when
> Native IPv6 is available (bias declared).

You get exactly this by using the model #1, where you bring up native =
and 6rd with different delegated prefixes.=20

>=20
> I say this since it would add a level of determinism to what I would
> expect (say an operator has only course level control as to what
> parameters they give each CPE).  This type of determinism goes a long =
way
> for operations and customer care folks (when troubleshooting =
problems).
>=20
> I am not saying we cannot make the suggested behaviour (as per drafts =
in
> discussion) work, but other then some optimizations on the CE to CE =
flows
> (within a given 6RD domain), are there other significant gains? =
(perhaps I
> am somewhat ignorant to the gambit of benefits).

We chose what was the most obvious in terms of following general =
principles of routing, which is why I wanted to answer Wes' question =
more generally than what he asked.
=09
Of course, you *could* send all traffic over the native link, and if you =
have granular control over the CPE that can be done, but you cannot =
control the other 6rd CEs in the deployment that do not yet have a =
native link and will be sending you traffic over the 6rd tunnel.=20

Back to general principles: 6rd installs two routes, one "more specific" =
with the magic of mapping to individual CEs, the other for "the =
Internet". If you combine this with a native interface that has nothing =
other than a default route for "the Internet" then you naturally end up =
with 6rd remaining for the CE-CE more specific route and an equivalent =
route for "the Internet" that requires a tie-breaker. The tie is broken =
by preferring native over virtual.

If you are sunsetting in the "same prefix" mode, you are *required* to =
leave 6rd up to receive traffic from other 6rd CEs (else you blackhole =
that traffic, there is no scalable way around it). To me it actually =
seems "less surprising" operationally to have all CE-to-CE traffic being =
sent and received over 6rd than some CE to CE traffic going up over =
native and returning encapsulated by the BR and some going direct =
depending on whether the native link of your peer CE is up or not.=20

But, again, if you want to keep the native and 6rd deployment very =
separate, you can do that via separate prefixes. This "more =
deterministic" property in the network comes at the expense of the CE =
being able to handle multihoming properly, or the home handling a flash =
renumber. These are the 3 fundamental tradeoff areas. I'm striving to =
allow you to make that operational choice.=20

>=20
> (this next point may be a bit off topic)
>=20
> If re-addressing is one of the the big issues, I am not sure if this =
can
> be avoided (in totality). 6RD to Native IPv6 transition is just one =
use
> case where I need to re-address a CPE/home network.  I have all sorts =
of
> uses cases where this will happen - so we will need to solve the IPv6
> renumbering/stability case anyway.  In our network, I would see the =
move
> from 6RD to Native IPv6 (in the prefix retention case) a renumbering
> exercise from one Interface type to another (if I can figure out how =
to
> offer the same prefix and not break all types of rules and =
provisioning
> systems at the same time).

The "same prefix" mode doesn't aim to eliminate renumbering, it just =
allows you to divorce the 6rd to native migration from requiring it. So, =
it becomes one less reason to have to renumber, and one less thing in =
the checklist of issues, when sunsetting 6rd. I'm trying to make it =
easier for you to turn off 6rd, not harder ;-)

Of course, there could be a dozen other reasons why you might need to =
renumber (please ask the renum WG to put residential in their charter =
;-).=20

>=20
> Again, I would prefer a cut over from one interface to the other =
(virtual
> to native).  This is what I would ask my vendor to implement.  Once I =
add
> in Native to a capable CPE, I would expect the CPE to go native. I am
> hoping there is an option for this within all the proposals.

I don't want to limit the ability for you to move a customer from 6rd to =
native immediately, but I want others to be able to do it incrementally =
as well. If you want to move them immediately, all you need to do is =
provision DHCPv6 PD at the same time you deprovision the 6rd option in =
DHCPv4 and be sure you use a different prefix for native than 6rd. Once =
the home router reboots or the DHCPv4 lease and associated 6rd delegated =
prefix lifetime times out, the 6rd and its associated prefix will be =
gone never to return.=20

- Mark

>=20
> Sorry to be potentially digging up old bones on this.. I tried to =
review
> entire email thread.
>=20
> Thoughts?
>=20
> Victor K
>=20
>=20
>=20
>=20
>>=20
>>=20
>> - Mark
>>=20
>>>>=20
>>>> - Mark
>>>>=20
>>>>>=20
>>>>> - Wes
>>>>>=20
>>>>=20
>>>> _______________________________________________ v6ops mailing list
>>>> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops
>>>>=20
>>>>=20
>>=20
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>=20
>=20


From shemant@cisco.com  Mon Nov 28 11:11:06 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B05BA21F8C9F for ; Mon, 28 Nov 2011 11:11:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.298
X-Spam-Level: 
X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 7bLNT0n5S+1Y for ; Mon, 28 Nov 2011 11:10:58 -0800 (PST)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id A990321F8C76 for ; Mon, 28 Nov 2011 11:10:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=23210; q=dns/txt; s=iport; t=1322507457; x=1323717057; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=Rt+mz4s/HaTtUpKf7pRxst4bHHJDJ6nv1MO11e8O3V4=; b=gXkHHjmP6pmNVfnPhAjL6hWpHAu8KEiycdRje+FdRpHKO+sTA5L/79fH Sx/aJ49V316D8rFdzElKHqXLyltm9saloLW3CXrxsP2mibajYNRKkNzEn WWDMXW1Er3dTZtYdp3f7EUUV/+wnV+t6YIDzVVCJJBXWv9RwtB3cjaDaf E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Aq0AADLc006tJXHB/2dsb2JhbABDgk2YAJAggQWBcgEBAQQBAQEPAQkRAz4LEAIBCBEEAQELBhAHAQYBJh8JCAEBBAESCBqHa5hQAZ5QBIl/YwSIIZ5T
X-IronPort-AV: E=Sophos;i="4.69,585,1315180800"; d="scan'208,217";a="39472543"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-4.cisco.com with ESMTP; 28 Nov 2011 19:10:53 +0000
Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id pASJArE4011146;  Mon, 28 Nov 2011 19:10:53 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 28 Nov 2011 13:10:53 -0600
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCAE01.72DDDB71"
Date: Mon, 28 Nov 2011 13:10:52 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3036CD724@XMB-RCD-109.cisco.com>
In-Reply-To: <750BF7861EBBE048B3E648B4BB6E8F4F2106F5DE@crexc50p>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] 6rd Sunsetting
Thread-Index: Acyp5CNpIkZczFjvREWkaYbC7PsaVAAEh59AAPyk8PAABiKWcA==
References:  <750BF7861EBBE048B3E648B4BB6E8F4F20B124DE@crexc50p> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EEEBA@XMB-RCD-109.cisco.com> <82DD1735-321E-44CB-8E1E-FF7C3402A371@townsley.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EEF82@XMB-RCD-109.cisco.com> <750BF7861EBBE048B3E648B4BB6E8F4F2106F5DE@crexc50p>
From: "Hemant Singh (shemant)" 
To: "STARK, BARBARA H" , "Mark Townsley" 
X-OriginalArrivalTime: 28 Nov 2011 19:10:53.0398 (UTC) FILETIME=[72F85760:01CCAE01]
Cc: v6ops@ietf.org
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 28 Nov 2011 19:11:06 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CCAE01.72DDDB71
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Barbara,

=20

Thanks for your input.   We will keep the manual 6rd config in
rfc6204bis.

=20

Hemant

=20

From: STARK, BARBARA H [mailto:bs7652@att.com]=20
Sent: Monday, November 28, 2011 2:02 PM
To: Hemant Singh (shemant); Mark Townsley
Cc: v6ops@ietf.org
Subject: RE: [v6ops] 6rd Sunsetting

=20

Yes, We still need manual configuration. Not all access networks
currently have DHCPv4 servers (e.g., PPPoE), so it will not be possible
to supply 6rd config via DHCPv4. Some consumers will be happy to get
TR-069-managed routers from their ISP, which will take care of
automating 6rd config for them. But there exist people who do not like
or want to use an ISP router. They want to use their own. And they
should have that right. Manual configuration is for them.

=20

I see no need for additional guidance. To me, the context of the "manual
configuration" requirement makes it clear that we are talking about
exactly the same parameters as the DHCPv4 6rd option. Those parameters
are all non-customer-specific. They can be easily conveyed to the type
of people who would want to use an off-the-shelf router for this
purpose. There's nothing special about them.

Barbara

=20

From: Hemant Singh (shemant) [mailto:shemant@cisco.com]=20
Sent: Wednesday, November 23, 2011 10:42 AM
To: Mark Townsley
Cc: STARK, BARBARA H; v6ops@ietf.org
Subject: RE: [v6ops] 6rd Sunsetting

=20

Mark,

=20

Thanks.  I agree.  Barbara,  based on Mark's reply, do we still need
manual configuration for 6rd in rfc6204bis and if so, what more for
guidance would you like?

=20

Hemant

=20

From: Mark Townsley [mailto:mark@townsley.net]=20
Sent: Wednesday, November 23, 2011 8:31 AM
To: Hemant Singh (shemant)
Cc: STARK, BARBARA H; v6ops@ietf.org
Subject: Re: [v6ops] 6rd Sunsetting

=20

=20

I think that manually configured 6rd, or manually configured anything
really, should be squarely out of scope whenever possible. I think the
WG should focus on default behavior and configuration handled via our
protocols. Once you've opened a user-level interface, all bets are off.=20

=20

That said, a manually configured 6rd interface should not be difficult
as long as you don't try to treat it "special". It's just another
interface like any other on the router. It has its own entry in the
forwarding table, and rules that are consistent with what we should
define for an ISP-configured 6rd interface. Everything we have discussed
here in terms of what is in 6rd-sunsetting and source routing to the
correct interface apply perfectly well, even if you have manual and
SP-configured interfaces (not to mention an HE tunnel on the side, etc.)

=20

The hard part comes when the CPE tries to become too intelligent for its
own good, automatically preferring one type of interface configuration
over another (note that I didn't say preferring one *route* over another
when the entries in the forwarding table are otherwise equal, I said
preferring one type of *configuration* over the other). I think this is
inherently bad as it means every single time there is a new type of
interface (virtual or otherwise) you have to fit it into a logic table
of what is and is not allowed. As long as the router can handle multiple
interfaces generically, it should "do as it's told", bring up interfaces
it has SP-supported or explicit manual configuration for, and route
accordingly. =20

=20

For troubleshooting, RFC 5969 includes advice on how to construct a
packet that will not only test the path between the CE and BR, it will
tell you which BR that packet happened to traverse. One could run a
BFD-like keepalive on a timer on the 6rd tunnel (the "NUD" section
Hemant refers to), but I think that's overkill for 6rd as long as you
have a well-supported BR deployment to plug into. If you are using the
6rd config with a single BR that is not well-supported, you might want
the CE to declare the interface down when a periodic NUD check fails. It
should be clear though that this is far removed from a "production"
ISP-supported 6rd deployment, and much more of a "trial" type of
operation that I think 6204-bis should not have to worry about.=20

=20

- Mark

=20

=20

On Nov 23, 2011, at 11:53 AM, Hemant Singh (shemant) wrote:

=20

=20

From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
Of STARK, BARBARA H
Sent: Tuesday, November 15, 2011 10:33 AM
To: v6ops@ietf.org
Subject: Re: [v6ops] 6rd Sunsetting

=20

=20

>But when the CE router was manually configured for 6rd, I have no clue
what this means. How is the manually-configured CE router supposed to
know whether or not 6rd is configured by >the SP? Some guidance in this
area would be appreciated. For example, should the CE router test to see
if the BR is reachable, and if not assume that 6rd is not configured by
the SP?

=20

How can a subscriber in the home manually configure the CE router for
four 6rd parameters including the IPv4 address of the BR unless the
subscriber called the SP and got the information to configure manually.
Thus the SP knows about the CPE router in the subscriber's home and also
the CE router does not need to test if 6rd is configured by the SP.  If
the CE router still wants to test, then use the NUD specified in section
8 of RFC 5969.

=20

Hemant

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

=20


------_=_NextPart_001_01CCAE01.72DDDB71
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Barbara,
 
Thanks for your input.   We will keep the manual 6rd config =
in rfc6204bis.
 
Hemant
 
From:=
 =
STARK, BARBARA H [mailto:bs7652@att.com] 
Sent: Monday, =
November 28, 2011 2:02 PM
To: Hemant Singh (shemant); Mark =
Townsley
Cc: v6ops@ietf.org
Subject: RE: [v6ops] 6rd =
Sunsetting
 
Yes, We =
still need manual configuration. Not all access networks currently have =
DHCPv4 servers (e.g., PPPoE), so it will not be possible to supply 6rd =
config via DHCPv4. Some consumers will be happy to get TR-069-managed =
routers from their ISP, which will take care of automating 6rd config =
for them. But there exist people who do not like or want to use an ISP =
router. They want to use their own. And they should have that right. =
Manual configuration is for them.
 =

I see no =
need for additional guidance. To me, the context of the “manual =
configuration” requirement makes it clear that we are talking =
about exactly the same parameters as the DHCPv4 6rd option. Those =
parameters are all non-customer-specific. They can be easily conveyed to =
the type of people who would want to use an off-the-shelf router for =
this purpose. There’s nothing special about =
them.
Barbara
 
From:=
 =
Hemant Singh (shemant) [mailto:shemant@cisco.com] 
Sent: =
Wednesday, November 23, 2011 10:42 AM
To: Mark =
Townsley
Cc: STARK, BARBARA H; =
v6ops@ietf.org
Subject: RE: [v6ops] 6rd =
Sunsetting
 
Mark,
 
Thanks.  I agree.  Barbara,  based on Mark’s =
reply, do we still need manual configuration for 6rd in rfc6204bis and =
if so, what more for guidance would you like?
 
Hemant
 
From:=
 =
Mark Townsley [mailto:mark@townsley.net] 
Sent: Wednesday, =
November 23, 2011 8:31 AM
To: Hemant Singh =
(shemant)
Cc: STARK, BARBARA H; =
v6ops@ietf.org
Subject: Re: [v6ops] 6rd =
Sunsetting
 
 
I =
think that manually configured 6rd, or manually configured anything =
really, should be squarely out of scope whenever possible. I think the =
WG should focus on default behavior and configuration handled via our =
protocols. Once you've opened a user-level interface, all bets are =
off. 
 
That said, a manually configured 6rd interface should =
not be difficult as long as you don't try to treat it =
"special". It's just another interface like any other on the =
router. It has its own entry in the forwarding table, and rules that are =
consistent with what we should define for an ISP-configured 6rd =
interface. Everything we have discussed here in terms of what is in =
6rd-sunsetting and source routing to the correct interface apply =
perfectly well, even if you have manual and SP-configured interfaces =
(not to mention an HE tunnel on the side, =
etc.)
 
The hard part comes when the CPE tries to become too =
intelligent for its own good, automatically preferring one type of =
interface configuration over another (note that I didn't say preferring =
one *route* over another when the entries in the forwarding table are =
otherwise equal, I said preferring one type of *configuration* over the =
other). I think this is inherently bad as it means every single time =
there is a new type of interface (virtual or otherwise) you have to fit =
it into a logic table of what is and is not allowed. As long as the =
router can handle multiple interfaces generically, it should "do as =
it's told", bring up interfaces it has SP-supported or explicit =
manual configuration for, and route accordingly. =
 
 
For troubleshooting, RFC 5969 includes advice on how =
to construct a packet that will not only test the path between the CE =
and BR, it will tell you which BR that packet happened to =
traverse. One could run a BFD-like keepalive on a timer on the 6rd =
tunnel (the "NUD" section Hemant refers to), but I think =
that's overkill for 6rd as long as you have a well-supported BR =
deployment to plug into. If you are using the 6rd config with a single =
BR that is not well-supported, you might want the CE to declare the =
interface down when a periodic NUD check fails. It should be clear =
though that this is far removed from a "production" =
ISP-supported 6rd deployment, and much more of a "trial" type =
of operation that I think 6204-bis should not have to worry =
about. 
 
- =
Mark
 
 
On Nov 23, 2011, at 11:53 AM, Hemant Singh (shemant) =
wrote:
 
 
From:=
 v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org=
] On Behalf Of STARK, BARBARA =
H
Sent: Tuesday, November 15, 2011 =
10:33 AM
To: v6ops@ietf.org
Subject: Re: [v6ops] 6rd =
Sunsetting
 
 
>But when the CE router was manually configured for 6rd, I have no =
clue what this means. How is the manually-configured CE router supposed =
to know whether or not 6rd is configured by >the SP? Some guidance in =
this area would be appreciated. For example, should the CE router test =
to see if the BR is reachable, and if not assume that 6rd is not =
configured by the SP?
 
How can a subscriber in the home manually configure the CE router for =
four 6rd parameters including the IPv4 address of the BR unless the =
subscriber called the SP and got the information to configure =
manually.  Thus the SP knows about the CPE router in the =
subscriber’s home and also the CE router does not need to test if =
6rd is configured by the SP.  If the CE router still wants to test, =
then use the NUD specified in section 8 of RFC =
5969.
 
Hemant
_________=
______________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org=
/mailman/listinfo/v6ops
 

------_=_NextPart_001_01CCAE01.72DDDB71--

From mark@townsley.net  Mon Nov 28 11:17:56 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16E9F11E80C6 for ; Mon, 28 Nov 2011 11:17:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.632
X-Spam-Level: 
X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[AWL=-0.234, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 sU5XomhKaNih for ; Mon, 28 Nov 2011 11:17:55 -0800 (PST)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5854511E80A1 for ; Mon, 28 Nov 2011 11:17:48 -0800 (PST)
Received: by bkbzv15 with SMTP id zv15so9696793bkb.31 for ; Mon, 28 Nov 2011 11:17:47 -0800 (PST)
Received: by 10.205.122.17 with SMTP id ge17mr45934233bkc.109.1322507867100; Mon, 28 Nov 2011 11:17:47 -0800 (PST)
Received: from ams-townsley-8712.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id jf4sm26036869bkc.5.2011.11.28.11.17.40 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 28 Nov 2011 11:17:42 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-49-603275679
From: Mark Townsley 
In-Reply-To: <750BF7861EBBE048B3E648B4BB6E8F4F2106F5DE@crexc50p>
Date: Mon, 28 Nov 2011 20:17:39 +0100
Message-Id: 
References:  <750BF7861EBBE048B3E648B4BB6E8F4F20B124DE@crexc50p> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EEEBA@XMB-RCD-109.cisco.com> <82DD1735-321E-44CB-8E1E-FF7C3402A371@townsley.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EEF82@XMB-RCD-109.cisco.com> <750BF7861EBBE048B3E648B4BB6E8F4F2106F5DE@crexc50p>
To: "STARK, BARBARA H" 
X-Mailer: Apple Mail (2.1084)
Cc: v6ops@ietf.org
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 28 Nov 2011 19:17:56 -0000

--Apple-Mail-49-603275679
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


On Nov 28, 2011, at 8:01 PM, STARK, BARBARA H wrote:

> Yes, We still need manual configuration. Not all access networks =
currently have DHCPv4 servers (e.g., PPPoE), so it will not be possible =
to supply 6rd config via DHCPv4.

DHCPv4 can be run over PPPoE for options not supplied in PPP (see DHCP =
INFORM message). This has been the standard answer from pppext just =
about every time we have tried to add any new IP config options to IPCP.=20=


That said, if you think this:=20

http://tools.ietf.org/html/draft-freedman-pppext-ipv6-6rd-00

...would be useful and BNG+CE vendors would actually implement it, =
please speak up:

> Some consumers will be happy to get TR-069-managed routers from their =
ISP, which will take care of automating 6rd config for them. But there =
exist people who do not like or want to use an ISP router. They want to =
use their own. And they should have that right. Manual configuration is =
for them.
> =20
> I see no need for additional guidance. To me, the context of the =
=93manual configuration=94 requirement makes it clear that we are =
talking about exactly the same parameters as the DHCPv4 6rd option. =
Those parameters are all non-customer-specific. They can be easily =
conveyed to the type of people who would want to use an off-the-shelf =
router for this purpose. There=92s nothing special about them.

OK, I won't stand in the way of including manual requirements under =
protest, but if they go in then it becomes that much more important that =
the CE be able to rationalize 6rd and native at the same time. I don't =
think it changes the requirements at all if we follow the same general =
principle that the CE "does what it is told" rather than trying to =
enable and disable 6rd configuration dynamically based on the presence =
of native IPv6.=20

- Mark

> Barbara
> =20
> From: Hemant Singh (shemant) [mailto:shemant@cisco.com]=20
> Sent: Wednesday, November 23, 2011 10:42 AM
> To: Mark Townsley
> Cc: STARK, BARBARA H; v6ops@ietf.org
> Subject: RE: [v6ops] 6rd Sunsetting
> =20
> Mark,
> =20
> Thanks.  I agree.  Barbara,  based on Mark=92s reply, do we still need =
manual configuration for 6rd in rfc6204bis and if so, what more for =
guidance would you like?
> =20
> Hemant
> =20
> From: Mark Townsley [mailto:mark@townsley.net]=20
> Sent: Wednesday, November 23, 2011 8:31 AM
> To: Hemant Singh (shemant)
> Cc: STARK, BARBARA H; v6ops@ietf.org
> Subject: Re: [v6ops] 6rd Sunsetting
> =20
> =20
> I think that manually configured 6rd, or manually configured anything =
really, should be squarely out of scope whenever possible. I think the =
WG should focus on default behavior and configuration handled via our =
protocols. Once you've opened a user-level interface, all bets are off.=20=

> =20
> That said, a manually configured 6rd interface should not be difficult =
as long as you don't try to treat it "special". It's just another =
interface like any other on the router. It has its own entry in the =
forwarding table, and rules that are consistent with what we should =
define for an ISP-configured 6rd interface. Everything we have discussed =
here in terms of what is in 6rd-sunsetting and source routing to the =
correct interface apply perfectly well, even if you have manual and =
SP-configured interfaces (not to mention an HE tunnel on the side, etc.)
> =20
> The hard part comes when the CPE tries to become too intelligent for =
its own good, automatically preferring one type of interface =
configuration over another (note that I didn't say preferring one =
*route* over another when the entries in the forwarding table are =
otherwise equal, I said preferring one type of *configuration* over the =
other). I think this is inherently bad as it means every single time =
there is a new type of interface (virtual or otherwise) you have to fit =
it into a logic table of what is and is not allowed. As long as the =
router can handle multiple interfaces generically, it should "do as it's =
told", bring up interfaces it has SP-supported or explicit manual =
configuration for, and route accordingly. =20
> =20
> For troubleshooting, RFC 5969 includes advice on how to construct a =
packet that will not only test the path between the CE and BR, it will =
tell you which BR that packet happened to traverse. One could run a =
BFD-like keepalive on a timer on the 6rd tunnel (the "NUD" section =
Hemant refers to), but I think that's overkill for 6rd as long as you =
have a well-supported BR deployment to plug into. If you are using the =
6rd config with a single BR that is not well-supported, you might want =
the CE to declare the interface down when a periodic NUD check fails. It =
should be clear though that this is far removed from a "production" =
ISP-supported 6rd deployment, and much more of a "trial" type of =
operation that I think 6204-bis should not have to worry about.=20
> =20
> - Mark
> =20
> =20
> On Nov 23, 2011, at 11:53 AM, Hemant Singh (shemant) wrote:
> =20
>=20
> =20
> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf =
Of STARK, BARBARA H
> Sent: Tuesday, November 15, 2011 10:33 AM
> To: v6ops@ietf.org
> Subject: Re: [v6ops] 6rd Sunsetting
> =20
> =20
> >But when the CE router was manually configured for 6rd, I have no =
clue what this means. How is the manually-configured CE router supposed =
to know whether or not 6rd is configured by >the SP? Some guidance in =
this area would be appreciated. For example, should the CE router test =
to see if the BR is reachable, and if not assume that 6rd is not =
configured by the SP?
> =20
> How can a subscriber in the home manually configure the CE router for =
four 6rd parameters including the IPv4 address of the BR unless the =
subscriber called the SP and got the information to configure manually.  =
Thus the SP knows about the CPE router in the subscriber=92s home and =
also the CE router does not need to test if 6rd is configured by the SP. =
 If the CE router still wants to test, then use the NUD specified in =
section 8 of RFC 5969.
> =20
> Hemant
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
> =20


--Apple-Mail-49-603275679
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252


On Nov 28, 2011, at 8:01 PM, STARK, =
BARBARA H wrote:

Yes, We still need manual configuration. Not all =
access networks currently have DHCPv4 servers (e.g., PPPoE), so it will =
not be possible to supply 6rd config via DHCPv4. =


DHCPv4 =
can be run over PPPoE for options not supplied in PPP (see DHCP INFORM =
message). This has been the standard answer from pppext just about every =
time we have tried to add any new IP config options to =
IPCP. 

That said, if you think =
this: 

...would be useful and BNG+CE vendors would actually =
implement it, please speak up:

Some consumers will be happy to get =
TR-069-managed routers from their ISP, which will take care of =
automating 6rd config for them. But there exist people who do not like =
or want to use an ISP router. They want to use their own. And they =
should have that right. Manual configuration is for =
them.
I see no need for additional =
guidance. To me, the context of the =93manual configuration=94 =
requirement makes it clear that we are talking about exactly the same =
parameters as the DHCPv4 6rd option. Those parameters are all =
non-customer-specific. They can be easily conveyed to the type of people =
who would want to use an off-the-shelf router for this purpose. There=92s =
nothing special about =
them.

OK, I =
won't stand in the way of including manual requirements under protest, =
but if they go in then it becomes that much more important that the CE =
be able to rationalize 6rd and native at the same time. I don't think it =
changes the requirements at all if we follow the same general principle =
that the CE "does what it is told" rather than trying to enable and =
disable 6rd configuration dynamically based on the presence of native =
IPv6. 

- Mark

Barbara
 
From: Hemant Singh (shemant) =
[mailto:shemant@cisco.com] 
Sent: Wednesday, November 23, =
2011 10:42 AM
To: Mark =
Townsley
Cc: STARK, BARBARA H; v6ops@ietf.org
Subject: RE: [v6ops] 6rd =
Sunsetting
From: Mark Townsley =
[mailto:mark@townsley.net] 
Sent: Wednesday, November 23, =
2011 8:31 AM
To: Hemant Singh =
(shemant)
Cc: STARK, BARBARA H; v6ops@ietf.org
Subject: Re: [v6ops] 6rd =
Sunsetting
I think that manually =
configured 6rd, or manually configured anything really, should be =
squarely out of scope whenever possible. I think the WG should focus on =
default behavior and configuration handled via our protocols. Once =
you've opened a user-level interface, all bets are =
off. 
That said, a manually =
configured 6rd interface should not be difficult as long as you don't =
try to treat it "special". It's just another interface like any other on =
the router. It has its own entry in the forwarding table, and rules that =
are consistent with what we should define for an ISP-configured 6rd =
interface. Everything we have discussed here in terms of what is in =
6rd-sunsetting and source routing to the correct interface apply =
perfectly well, even if you have manual and SP-configured interfaces =
(not to mention an HE tunnel on the side, =
etc.)
The hard part comes when =
the CPE tries to become too intelligent for its own good, automatically =
preferring one type of interface configuration over another (note that I =
didn't say preferring one *route* over another when the entries in the =
forwarding table are otherwise equal, I said preferring one type of =
*configuration* over the other). I think this is inherently bad as it =
means every single time there is a new type of interface (virtual or =
otherwise) you have to fit it into a logic table of what is and is not =
allowed. As long as the router can handle multiple interfaces =
generically, it should "do as it's told", bring up interfaces it has =
SP-supported or explicit manual configuration for, and route =
accordingly.  
For troubleshooting, RFC =
5969 includes advice on how to construct a packet that will not only =
test the path between the CE and BR, it will tell you which BR that =
packet happened to traverse. One could run a BFD-like keepalive on =
a timer on the 6rd tunnel (the "NUD" section Hemant refers to), but I =
think that's overkill for 6rd as long as you have a well-supported BR =
deployment to plug into. If you are using the 6rd config with a single =
BR that is not well-supported, you might want the CE to declare the =
interface down when a periodic NUD check fails. It should be clear =
though that this is far removed from a "production" ISP-supported 6rd =
deployment, and much more of a "trial" type of operation that I think =
6204-bis should not have to worry =
about. 
- =
Mark
On Nov 23, 2011, at 11:53 =
AM, Hemant Singh (shemant) wrote:
 
 
>But when the CE router was manually configured =
for 6rd, I have no clue what this means. How is the manually-configured =
CE router supposed to know whether or not 6rd is configured by >the SP? Some guidance =
in this area would be appreciated. For example, should the CE router =
test to see if the BR is reachable, and if not assume that 6rd is not =
configured by the SP?
How can a subscriber in the home manually configure =
the CE router for four 6rd parameters including the IPv4 address of the =
BR unless the subscriber called the SP and got the information to =
configure manually.  Thus the SP knows about the CPE router in the =
subscriber=92s home and also the CE router does not need to test if 6rd =
is configured by the SP.  If the CE router still wants to test, =
then use the NUD specified in section 8 of RFC =
5969.
Hemant
v6ops@ietf.org

In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] 6rd Sunsetting
Thread-Index: AcyuAmpv+fZNG/NuSCWk/S1D1TbU1QAAHJWg
References:  <750BF7861EBBE048B3E648B4BB6E8F4F20B124DE@crexc50p> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EEEBA@XMB-RCD-109.cisco.com> <82DD1735-321E-44CB-8E1E-FF7C3402A371@townsley.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EEF82@XMB-RCD-109.cisco.com> <750BF7861EBBE048B3E648B4BB6E8F4F2106F5DE@crexc50p> 
From: "Hemant Singh (shemant)" 
To: "Mark Townsley" , "STARK, BARBARA H" 
X-OriginalArrivalTime: 28 Nov 2011 19:25:27.0822 (UTC) FILETIME=[7C2ADAE0:01CCAE03]
Cc: v6ops@ietf.org
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 28 Nov 2011 19:25:31 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CCAE03.7BF5FF64
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

=20

From: Mark Townsley [mailto:mark@townsley.net]=20
Sent: Monday, November 28, 2011 2:18 PM
To: STARK, BARBARA H
Cc: Hemant Singh (shemant); v6ops@ietf.org
Subject: Re: [v6ops] 6rd Sunsetting

=20

>OK, I won't stand in the way of including manual requirements under
protest, but if they go in then it becomes that much more important that
the CE be able to rationalize 6rd and native at the same time. I >don't
think it changes the requirements at all if we follow the same general
principle that the CE "does what it is told" rather than trying to
enable and disable 6rd configuration dynamically based on the >presence
of native IPv6.=20

=20

The retail, manually-configured CPE will be fine with 6rd sunsetting
based on the rules already specified in rfc6204bis.  The rules are
agnostic to a SP-managed or a user-configured 6rd CPE router. The retail
CPE will start native IPv6 operation when cued to do so with a RA from
the SP BNG and sunset 6rd when the DHCPv4 lease_time expires and the SP
does not reply to the DHCPv4 Renew from the CPE and the SP has also
changing the provisioning system to not include the 6rd DHCPv4 option in
DHCPv4 responses.

=20

Thanks,

=20

Hemant





=20


------_=_NextPart_001_01CCAE03.7BF5FF64
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


 
From:=
 =
Mark Townsley [mailto:mark@townsley.net] 
Sent: Monday, =
November 28, 2011 2:18 PM
To: STARK, BARBARA H
Cc: =
Hemant Singh (shemant); v6ops@ietf.org
Subject: Re: [v6ops] =
6rd Sunsetting
 
>OK, I won't =
stand in the way of including manual requirements under protest, but if =
they go in then it becomes that much more important that the CE be able =
to rationalize 6rd and native at the same time. I >don't think it changes the =
requirements at all if we follow the same general principle that the CE =
"does what it is told" rather than trying to enable and =
disable 6rd configuration dynamically based on the >presence of native =
IPv6. 
 
The retail, manually-configured CPE will be fine =
with 6rd sunsetting based on the rules already specified in =
rfc6204bis.  The rules are agnostic to a SP-managed or a =
user-configured 6rd CPE router. The retail CPE will start native IPv6 =
operation when cued to do so with a RA from the SP BNG and sunset 6rd =
when the DHCPv4 lease_time expires and the SP does not reply to the =
DHCPv4 Renew from the CPE and the SP has also changing the provisioning =
system to not include the 6rd DHCPv4 option in DHCPv4 =
responses.
 
Thanks,
 
Hemant


 

------_=_NextPart_001_01CCAE03.7BF5FF64--

From shemant@cisco.com  Mon Nov 28 11:38:41 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48CAF1F0C40 for ; Mon, 28 Nov 2011 11:38:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.548
X-Spam-Level: 
X-Spam-Status: No, score=-6.548 tagged_above=-999 required=5 tests=[AWL=0.050,  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 7dku9jTtm9Jb for ; Mon, 28 Nov 2011 11:38:40 -0800 (PST)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id C279711E80AE for ; Mon, 28 Nov 2011 11:38:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=12556; q=dns/txt; s=iport; t=1322509120; x=1323718720; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=ZtrC9dNFcdfI9HmVqwuLEx+NP1SYP3sFGYjyfXSoJAA=; b=lx5XhDjyf7bQz9VWRU46ctlbCO9Ulrv99FWN2MjKY8i9tanhr53txqhl WPokO5ExPoYWtSX5dWVPppNkXDtn7u/mp/wklAd/xUS2H4PNmfkht5Klc xlXlXA96m6dyIHQXFik/Q2u8plhtxGseBG3syn7swHzRD1ghZZ05UmVPr E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Aq0AAAni006tJXG8/2dsb2JhbABDgk2YAZAggQWBcgEBAQQSAQkRA0kMBAIBCBEEAQELBhcBBgFFCQgBAQQBEggBGYdrmFMBnlqJf2MEiCGeUw
X-IronPort-AV: E=Sophos;i="4.69,585,1315180800"; d="scan'208,217";a="39479106"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 28 Nov 2011 19:38:39 +0000
Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id pASJcdYn016909;  Mon, 28 Nov 2011 19:38:39 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 28 Nov 2011 13:38:39 -0600
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCAE05.53977BF4"
Date: Mon, 28 Nov 2011 13:38:38 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3036CD757@XMB-RCD-109.cisco.com>
In-Reply-To: <7D1B37E6-74D2-4205-9D85-FB1032866CCF@townsley.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] 6rd Sunsetting
Thread-Index: AcyuAQ/pMVIdks2DTfa+ETm57IX5vAAAuR/Q
References:  <7D1B37E6-74D2-4205-9D85-FB1032866CCF@townsley.net>
From: "Hemant Singh (shemant)" 
To: "Mark Townsley" , "Victor Kuarsingh" 
X-OriginalArrivalTime: 28 Nov 2011 19:38:39.0171 (UTC) FILETIME=[53D92130:01CCAE05]
Cc: Alexandre Cassen , v6ops@ietf.org, Claire Cheng 
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 28 Nov 2011 19:38:41 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CCAE05.53977BF4
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

=20

=20

-----Original Message-----
From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
Of Mark Townsley
Sent: Monday, November 28, 2011 2:08 PM
To: Victor Kuarsingh
Cc: Alexandre Cassen; v6ops@ietf.org; Claire Cheng
Subject: Re: [v6ops] 6rd Sunsetting

=20

=20

>You get exactly this by using the model #1, where you bring up native
and 6rd with different delegated prefixes.=20

=20

Including the fact that the current -03 version of rfc6204bis addresses
the model above correctly with bullet 5 in section 4.4.3.

=20

>Back to general principles: 6rd installs two routes, one "more
specific" with the magic of mapping to individual CEs, the other for
"the >Internet". If you >combine this with a native interface that has
nothing other than a default route for "the Internet" then you naturally
end up >with 6rd remaining for the CE-CE >more specific route and an
equivalent route for "the Internet" that requires a tie-breaker. The tie
is broken by >preferring native over virtual.

=20

Including the fact that the current -03 version of rfc6204bis addresses
the model above correctly with bullet 5 in section 4.4.3.

=20

=20

>If you are sunsetting in the "same prefix" mode, you are *required* to
leave 6rd up to receive traffic from other 6rd CEs (else you blackhole
that >traffic, there >is no scalable way around it).=20

=20

Including the fact that the current -03 version of rfc6204bis addresses
the issue Mark mentioned above in the last paragraph of section 4.4.3.
6rd is maintained as long as the SP does not disable 6rd via DHCPv4.
See more details in

=20

http://www.ietf.org/mail-archive/web/v6ops/current/msg11428.html

=20

=20

>I don't want to limit the ability for you to move a customer from 6rd
to native immediately, but I want others to be able to do it
incrementally >as well. If you >want to move them immediately, all you
need to do is provision DHCPv6 PD at the same time you deprovision the
6rd option in >DHCPv4 and be sure you use a >different prefix for native
than 6rd. Once the home router reboots or the DHCPv4 lease and
associated 6rd delegated >prefix lifetime times out, the 6rd and its
>associated prefix will be gone never to return.=20

=20

Correct.  The above text is a SP function (to immediately turn off 6rd
when native IPv6 is turned on) and does not add any new text to -03
rfc6404bis document.

=20

Hemant


------_=_NextPart_001_01CCAE05.53977BF4
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


 
 
-----Original Message-----
From: =
v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Mark =
Townsley
Sent: Monday, November 28, 2011 2:08 PM
To: Victor =
Kuarsingh
Cc: Alexandre Cassen; v6ops@ietf.org; Claire =
Cheng
Subject: Re: [v6ops] 6rd Sunsetting
 
 
>You get exactly this by using =
the model #1, where you bring up native and 6rd with different delegated =
prefixes. 
 
Including the fact that the current -03 version of =
rfc6204bis addresses the model above correctly with bullet 5 in section =
4.4.3.
 
>Back =
to general principles: 6rd installs two routes, one "more =
specific" with the magic of mapping to individual CEs, the other =
for "the >Internet". If you >combine this with a native =
interface that has nothing other than a default route for "the =
Internet" then you naturally end up >with 6rd remaining for the =
CE-CE >more specific route and an equivalent route for "the =
Internet" that requires a tie-breaker. The tie is broken by =
>preferring native over virtual.
 
Including the fact that =
the current -03 version of rfc6204bis addresses the model above =
correctly with bullet 5 in section 4.4.3.
 
 
>If =
you are sunsetting in the "same prefix" mode, you are =
*required* to leave 6rd up to receive traffic from other 6rd CEs (else =
you blackhole that >traffic, there >is no scalable way around it). =

 
Including =
the fact that the current -03 version of rfc6204bis addresses the issue =
Mark mentioned above in the last paragraph of section 4.4.3.  6rd =
is maintained as long as the SP does not disable 6rd via DHCPv4.  =
See more details in
 
http://www.ietf.org/mail-archive/web/v6ops/current/msg11428.html
 
 
>I =
don't want to limit the ability for you to move a customer from 6rd to =
native immediately, but I want others to be able to do it incrementally =
>as well. If you >want to move them immediately, all you need to =
do is provision DHCPv6 PD at the same time you deprovision the 6rd =
option in >DHCPv4 and be sure you use a >different prefix for =
native than 6rd. Once the home router reboots or the DHCPv4 lease and =
associated 6rd delegated >prefix lifetime times out, the 6rd and its =
>associated prefix will be gone never to return. =

 
Correct.  The above text is a SP function (to =
immediately turn off 6rd when native IPv6 is turned on) and does not add =
any new text to -03 rfc6404bis document.
 
Hemant

------_=_NextPart_001_01CCAE05.53977BF4--

From bs7652@att.com  Mon Nov 28 12:00:07 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C294911E80F9 for ; Mon, 28 Nov 2011 12:00:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.849
X-Spam-Level: 
X-Spam-Status: No, score=-105.849 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, 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 fwEJZHKH5-jW for ; Mon, 28 Nov 2011 12:00:07 -0800 (PST)
Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id DF1F611E80F3 for ; Mon, 28 Nov 2011 12:00:06 -0800 (PST)
X-Env-Sender: bs7652@att.com
X-Msg-Ref: server-4.tower-120.messagelabs.com!1322510404!51216972!1
X-Originating-IP: [144.160.20.146]
X-StarScan-Version: 6.3.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16787 invoked from network); 28 Nov 2011 20:00:05 -0000
Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-4.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 28 Nov 2011 20:00:05 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pASJwbF6015422; Mon, 28 Nov 2011 14:58:38 -0500
Received: from 01AL10015010626.AD.BLS.COM (sfldmibbcraeninet1-v2.enaf.ait.sbc.com [10.231.16.33]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pASJwVMC015334; Mon, 28 Nov 2011 14:58:32 -0500
Received: from 01NC27689010627.AD.BLS.COM ([90.144.44.202]) by 01AL10015010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 28 Nov 2011 13:59:08 -0600
Received: from 01NC27689010650.AD.BLS.COM ([90.144.44.120]) by 01NC27689010627.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 28 Nov 2011 14:59:08 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-2"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 28 Nov 2011 14:59:56 -0500
Message-ID: <750BF7861EBBE048B3E648B4BB6E8F4F2106F69E@crexc50p>
In-Reply-To: <1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
Thread-Index: AcyrZM6Op71ZUQDvQZGUHCE73sbQ2wBHO07QACkJ/mAAIjKr4AAV1ChQ
References: <2963F168-45CB-4042-8238-56DF538B0543@gmail.com><2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org><1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz><5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz>
From: "STARK, BARBARA H" 
To: =?ISO-8859-2?B?Vu16ZGFsIEFsZbk=?= , "Hemant Singh (shemant)" , "Ole Troan" , "jouni korhonen" 
X-OriginalArrivalTime: 28 Nov 2011 19:59:08.0356 (UTC) FILETIME=[307FE040:01CCAE08]
Cc: v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-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, 28 Nov 2011 20:00:07 -0000

I'll re-iterate what I've said before, as to what I need from 6204:

Above all, this document MUST provide guidance for off-the-shelf routers =
that have no knowledge, whatsoever, of who or what is providing the WAN =
interface. I will not support any proposed language that strays from =
this.

BBF, CableLabs, 3GPP, et al are 100% free to specify whatever they want =
for devices that they are able to specify. If they want to stray from =
6204, they are free to do so.=20

With that said, I understand that (a) 6204 is driving "IPv6 Ready" logo =
for routers (b) other orgs would like for their devices to also be able =
to receive the logo, and (c) it would be nice if we could avoid =
providing lots of reasons for other orgs to want to stray.

So what we have agreed in a few instances is to use language that makes =
it clear when it's ok not to do something that would be required of a =
router with no clue as to its WAN. For example, in WAA-7, it is proposed =
to add the phrase "... unless configured to require a global IPv6 =
address on the WAN interface." A WAN-clueless CE router would not be so =
configured, unless it has knowledge of what to expect on its WAN.=20

If you want to propose language that stipulates when it's ok not to =
request IA-NA, I'm willing to consider that. But I'm not willing to =
consider any change that would allow a WAN-clueless CE router to not =
request IA_NA, and still be compliant with 6204(bis).
Barbara

> -----Original Message-----
> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
> Of V=EDzdal Ale=B9
> Sent: Monday, November 28, 2011 5:20 AM
> To: Hemant Singh (shemant); Ole Troan; jouni korhonen
> Cc: v6ops@ietf.org
> Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
>=20
> Hemant,
>=20
> > -----Original Message-----
> > From: Hemant Singh (shemant) [mailto:shemant@cisco.com]
> > Sent: Sunday, November 27, 2011 6:06 PM
> > To: V=EDzdal Ale=B9; Ole Troan; jouni korhonen
> > Cc: v6ops@ietf.org
> > Subject: RE: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
> >
> > Vizdal,
> >
> > -----Original Message-----
> > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On
> Behalf Of V=EDzdal
> > Ale=B9
> > Sent: Saturday, November 26, 2011 5:02 PM
> > To: Ole Troan; jouni korhonen
> > Cc: v6ops@ietf.org
> > Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
> >
> >
> > >I have the same concern as Jouni that the IPv6 CE router (e.g. =
Mi-Fi
> device) having a
> > 3GPP access
> > >based WAN link only would be required to support the IA_NA option =
on
> the WAN link
> > to be able to be
> > >compliant to this RFC (I am saying on the WAN link, because this
> requirement is
> > placed under the WAA
> > >- WAN Address Allocation section).
> >
> > The rfc6204bis document only supports a cellular client for DHCPv6
> PD.  Thus any
> > legacy 3GPP cellular client that does not support DHCPv6 PD
> acquisition is not
> > supported by rfc6204bis.
>=20
> OK.
>=20
> > Thereafter if the cellular client supports DHCPv6 PD, the
> > device already supports the IA_PD option, so what is the big deal =
for
> the client to also
> > support the IA_NA option but the client does not use this option?
>=20
> What is the issue you currently see with relaxing this one for a non-
> DHCPv6 based address
> allocation?
>=20
> Even if supported by the IPv6 CE, the support for it cannot be =
verified
> as the 3GPP nodes
> along the path do not support statefull address allocation.
>=20
> I would see beneficial to allow 'current' 3GPP compliant CEs to be
> compliant to this RFC as well.
>=20
> > Thanks for catching the spelling error for "specified".  It has been
> fixed.
>=20
> You're welcome.
>=20
> > Hemant
>=20
> Cheers,
> Ales
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

From Jean-Francois.TremblayING@videotron.com  Mon Nov 28 12:26:01 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A91991F0C7F; Mon, 28 Nov 2011 12:26:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id svEbn-fL+lwh; Mon, 28 Nov 2011 12:26:00 -0800 (PST)
Received: from mx01.videotron.com (mx01.videotron.com [24.201.243.152]) by ietfa.amsl.com (Postfix) with ESMTP id C5C9F1F0C35; Mon, 28 Nov 2011 12:26:00 -0800 (PST)
In-Reply-To: 
To: victor.kuarsingh@gmail.com
MIME-Version: 1.0
X-KeepSent: 71EE1350:995EAF10-85257956:006D6C19; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006
Message-ID: 
From: Jean-Francois.TremblayING@videotron.com
Date: Mon, 28 Nov 2011 15:25:53 -0500
X-MIMETrack: Serialize by Router on DOMMSG01/SRV/GVL(Release 8.5.2FP2|March 22, 2011) at 11/28/2011 15:25:55, Serialize complete at 11/28/2011 15:25:55
Content-Type: multipart/alternative; boundary="=_alternative 00703C5585257956_="
Cc: "v6ops@ietf.org" , v6ops-bounces@ietf.org
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 28 Nov 2011 20:26:01 -0000

Message en plusieurs parties au format MIME
--=_alternative 00703C5585257956_=
Content-Type: text/plain; charset="US-ASCII"


Following on Victor's comments...

> In my mind (which seems to be somewhat at odds with others), I would 
want
> to choose an option which would cause a device to stop doing 6RD when
> Native IPv6 is available (bias declared).
+1

> I say this since it would add a level of determinism to what I would
> expect (say an operator has only course level control as to what
> parameters they give each CPE).  This type of determinism goes a long 
way
> for operations and customer care folks (when troubleshooting problems).
+1. This is a huge operational gain. 

> If re-addressing is one of the the big issues, I am not sure if this can
> be avoided (in totality).  6RD to Native IPv6 transition is just one use
> case where I need to re-address a CPE/home network. 

I just don't see user re-addressing being such a big pain compared to 
the pain of implementing 6RD sunset. This requires 1) important changes in 

CPE implementations, 2) the same prefix length on 6RD and native and 
3) major pain in network architecture if both IPv4 and IPv6 internal 
aggregation are not aligned. 

On 3), my point here is that 6RD sunset will only work if 6RD adressing 
space (based on IPv4) and native v6 PD space align nicely. Any gain 
in aggregation brought by native IPv6 will disappear if v4 aggregation 
is not already done nicely (which is certainly not the case in many 
networks I've seen). 

> Again, I would prefer a cut over from one interface to the other 
(virtual
> to native).  This is what I would ask my vendor to implement.  Once I 
add
> in Native to a capable CPE, I would expect the CPE to go native. I am
> hoping there is an option for this within all the proposals.
+1


/JFT

> Sorry to be potentially digging up old bones on this.. I tried to review
> entire email thread.
> Thoughts?
> Victor K

--=_alternative 00703C5585257956_=
Content-Type: text/html; charset="US-ASCII"



<another-operator-view>

Following on Victor's comments...



> In my mind (which seems to be somewhat at odds
with others), I would want

> to choose an option which would cause a device to stop doing 6RD when

> Native IPv6 is available (bias declared).

+1



> I say this since it would add a level of determinism to what I would

> expect (say an operator has only course level control as to what

> parameters they give each CPE).  This type of determinism goes
a long way

> for operations and customer care folks (when troubleshooting problems).

+1. This is a huge operational gain. 



> If re-addressing is one of the the big issues,
I am not sure if this can

> be avoided (in totality).  6RD to Native IPv6 transition is just
one use

> case where I need to re-address a CPE/home network.  



I just don't see user re-addressing being such a big
pain compared to 

the pain of implementing 6RD sunset. This requires
1) important changes in 

CPE implementations, 2) the same prefix length on
6RD and native and 

3) major pain in network architecture if both IPv4
and IPv6 internal 

aggregation are not aligned. 



On 3), my point here is that 6RD sunset will only
work if 6RD adressing 

space (based on IPv4) and native v6 PD space align
nicely. Any gain 

in aggregation brought by native IPv6 will disappear
if v4 aggregation 

is not already done nicely (which is certainly not
the case in many 

networks I've seen). 



> Again, I would prefer a cut over from one interface to the other (virtual

> to native).  This is what I would ask my vendor to implement.
 Once I add

> in Native to a capable CPE, I would expect the CPE to go native. I
am

> hoping there is an option for this within all the proposals.

+1



</another-operator-view>

/JFT



> Sorry to be potentially digging up old bones on this.. I tried to
review

> entire email thread.

> Thoughts?

> Victor K


--=_alternative 00703C5585257956_=--

From shemant@cisco.com  Mon Nov 28 12:50:33 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02DA111E80E5; Mon, 28 Nov 2011 12:50:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.555
X-Spam-Level: 
X-Spam-Status: No, score=-6.555 tagged_above=-999 required=5 tests=[AWL=0.043,  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 SAzBU-YDwk62; Mon, 28 Nov 2011 12:50:32 -0800 (PST)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id BF44E11E808E; Mon, 28 Nov 2011 12:50:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11479; q=dns/txt; s=iport; t=1322513432; x=1323723032; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=ERpCiid0lGRQUWP6zB4q1le5wEU5glTQL08UBTlJGak=; b=nJkaZpMnhAI5EotW/dWLwv2pjliQPYeLIZExmR0VKepHQRKgOaWDD/az dc8IJbFbVWwzW0utX2AZwa5Lt4t0fC7HYNWePJA5OczaImtrQH2Fcg9QP Df4w/iXolK1Wf7Tfe/IDO1HtHMsOBx7k+NYBHKm3X8m8rZXKWdgz9xK6g w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhEBABEppk6tJV2b/2dsb2JhbACCJY4gjhZ4iHCLZZI0hhkEhlCNeYQThkk
X-IronPort-AV: E=Sophos;i="4.69,585,1315180800"; d="scan'208,217";a="36993903"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 28 Nov 2011 20:50:31 +0000
Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pASKoVZ0027539;  Mon, 28 Nov 2011 20:50:31 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 28 Nov 2011 14:50:31 -0600
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCAE0F.5DBF2E23"
Date: Mon, 28 Nov 2011 14:50:30 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3036CD7EE@XMB-RCD-109.cisco.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] 6rd Sunsetting
Thread-Index: AcyuC/fkvakE7Hc+TCawGVTNTcjRJQAAt1Jw
References:  
From: "Hemant Singh (shemant)" 
To: , 
X-OriginalArrivalTime: 28 Nov 2011 20:50:31.0147 (UTC) FILETIME=[5DFC73B0:01CCAE0F]
Cc: v6ops@ietf.org, v6ops-bounces@ietf.org
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 28 Nov 2011 20:50:33 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CCAE0F.5DBF2E23
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

=20

=20

From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
Of Jean-Francois.TremblayING@videotron.com
Sent: Monday, November 28, 2011 3:26 PM
To: victor.kuarsingh@gmail.com
Cc: v6ops@ietf.org; v6ops-bounces@ietf.org
Subject: Re: [v6ops] 6rd Sunsetting

=20


>> Again, I would prefer a cut over from one interface to the other
(virtual
>> to native).  This is what I would ask my vendor to implement.  Once I
add
>> in Native to a capable CPE, I would expect the CPE to go native. I am
>> hoping there is an option for this within all the proposals.
>+1=20



That is what the intent is in rfc6204bis.  Please see text in bold below
from section 4.4.3 of rfc6204bis.  I said already in another email today
when the 6rd prefix and native IPv6 prefix are the same, we have a no-op
in the CPE for  any functionality listed in the text below.

=20

  [During a sunsetting activity such as deprecating 6rd and moving to
   native IPv6, the IPv6 CE router MUST immediately advertise the 6rd
   prefix with a Preferred Lifetime of zero and a Valid Lifetime of the
   lower of the current Valid Lifetime and two hours (which must be
   decremented in real time) in a Router Advertisement message as
   described in Section 5.5.3, (e) of [RFC4862].  Due to the two hours
   rule specified in [RFC4862], the 6rd and the native IPv6 prefix will
   coexist in the home network.  The two hours rule specified in section
   5.5.3 of [RFC4862] causes any deprecated prefix to linger on the node
   even when an RA has sent a Preferred Lifetime of zero to expire the
   prefix to the node.  During such coexistence of multiple prefixes,
   the CE router sends an ICMPv6 error for packets sourced or destined
   related to the deprecated prefix.  Note this document already
   includes text in bullet L-14 in section 4.3 for such a provision.]

=20

Hemant


------_=_NextPart_001_01CCAE0F.5DBF2E23
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


 
 
From:=
 =
v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of =
Jean-Francois.TremblayING@videotron.com
Sent: Monday, =
November 28, 2011 3:26 PM
To: =
victor.kuarsingh@gmail.com
Cc: v6ops@ietf.org; =
v6ops-bounces@ietf.org
Subject: Re: [v6ops] 6rd =
Sunsetting
 

>> Again, I would prefer a cut over from =
one interface to the other (virtual
>> to native).  This is what I =
would ask my vendor to implement.  Once I add
>> in Native to a capable CPE, I =
would expect the CPE to go native. I am
>> hoping there is an option for =
this within all the proposals.
>+1 

That is what the intent is in rfc6204bis.  Please see text in =
bold below from section 4.4.3 of rfc6204bis.  I said already in =
another email today when the 6rd prefix and native IPv6 prefix are the =
same, we have a no-op in the CPE for  any functionality listed in =
the text below.
 
  [During a sunsetting activity such as =
deprecating 6rd and moving to
   =
native IPv6, the IPv6 CE router MUST immediately advertise the =
6rd
   prefix with a Preferred Lifetime =
of zero and a Valid Lifetime of the
   =
lower of the current Valid Lifetime and two hours (which must =
be
   decremented in real time) in a =
Router Advertisement message as
   =
described in Section 5.5.3, (e) of [RFC4862].  Due to the two =
hours
   rule specified in [RFC4862], the =
6rd and the native IPv6 prefix will
   =
coexist in the home network.  The two hours rule specified in =
section
   5.5.3 of [RFC4862] causes any =
deprecated prefix to linger on the =
node
   even when an RA has sent a =
Preferred Lifetime of zero to expire =
the
   prefix to the node.  =
During such coexistence of multiple =
prefixes,
   the CE router sends =
an ICMPv6 error for packets sourced or =
destined
   related to the =
deprecated prefix.  Note this document =
already
   includes text in bullet L-14 =
in section 4.3 for such a provision.]
 
Hemant

------_=_NextPart_001_01CCAE0F.5DBF2E23--

From brian.e.carpenter@gmail.com  Mon Nov 28 13:58:37 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F7D011E811F for ; Mon, 28 Nov 2011 13:58:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level: 
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z94ZZvMNu2M1 for ; Mon, 28 Nov 2011 13:58:35 -0800 (PST)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5048911E80FC for ; Mon, 28 Nov 2011 13:58:35 -0800 (PST)
Received: by bkbzv15 with SMTP id zv15so9889314bkb.31 for ; Mon, 28 Nov 2011 13:58:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Li2th0gAGqB7SlVrXvccKsecLMzZptheBf82WjHat8g=; b=J2XAkjTVlLNEv9VY66HyztZwbHH/JEhFyYgjgv1LVjlNkHQRpRCPVxJhyYAwXf5zhH /f8e3F689PhLyY2OF94BC6tXBHKN6atezRIVgmKzLOOvzQFaVX+AgvXcQdRPSGSuksq9 IE9htwcVcrubebKcUbBrMR7cpkhfL7lhJ49v4=
Received: by 10.205.117.134 with SMTP id fm6mr43376260bkc.93.1322517514272; Mon, 28 Nov 2011 13:58:34 -0800 (PST)
Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id c4sm32559832bkk.13.2011.11.28.13.58.31 (version=SSLv3 cipher=OTHER); Mon, 28 Nov 2011 13:58:33 -0800 (PST)
Message-ID: <4ED40404.9060708@gmail.com>
Date: Tue, 29 Nov 2011 10:58:28 +1300
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: "Hemant Singh (shemant)" 
References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com><7EB596BF-B175-40BF-ABC8-326599670B04@apple.com><5B6B2B64C9FE2A489045EEEADDAFF2C303544B88@XMB-RCD-109.cisco.com><8D342733-88E6-45D3-B388-E001AE32CD77@employees.org><750BF7861EBBE048B3E648B4BB6E8F4F20DC4FEA@crexc50p><007801cca8c8$5610aa00$0231fe00$@iname.com><750BF7861EBBE048B3E648B4BB6E8F4F20EA1037@crexc50p>		<750BF7861EBBE048B3E!648B4BB6E8F4F20EA1083@crexc50p>		<14640DA2-54E5-46E9-B255-D141F1934596@nominum.com><201111231402.pANE21YK013540@cichlid.raleigh.ibm.com> <4ECD5484.4090009@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF106@XMB-RCD-109.cisco. com>
In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF106@XMB-RCD-109.cisco.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: Thomas Narten , IPv6 Operations 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 28 Nov 2011 21:58:37 -0000

Hemant,

On 2011-11-24 09:21, Hemant Singh (shemant) wrote:
> 
> -----Original Message-----
> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
> Of Brian E Carpenter
> Sent: Wednesday, November 23, 2011 3:16 PM
> To: Thomas Narten
> Cc: IPv6 Operations
> Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
> 
> 
>> Yes, that would have been nice. Cam we get there by making the
> recommendation
>> for the future exactly as above *except* that the first line would read
>>  ignore M/O bits?
> 
> Which document do we add the new text to?  Node-req-bis would be one
> choice?

No, let's have pity on that document. I think that the hermeneutics
of the M/O bits has come up in so many contexts that a stand-alone document
is needed. I am not volunteering.

    Brian

From hansliu@gmail.com  Mon Nov 28 18:29:22 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8B5121F8BAA for ; Mon, 28 Nov 2011 18:29:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IzIevxyFwg3I for ; Mon, 28 Nov 2011 18:29:22 -0800 (PST)
Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 161BF21F8BA0 for ; Mon, 28 Nov 2011 18:29:21 -0800 (PST)
Received: by lahj13 with SMTP id j13so891313lah.31 for ; Mon, 28 Nov 2011 18:29:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Sl6rZnGRUJm2N7ljSQZpaVIv3ZFeIyVcs5CGIRS54Ug=; b=ENOWqTcaWcruw+56ekANY7BqleI5VpMkRm1kijeKdrdRv7QQTJuRguLIo3ewZ/kRgN FVLR75oj91dENl41cuVrVTLYUtuducQhXmVy4zKC2LCWSDIKVOXglPp4dEgp4HIkjK6K Q644vfe+JdyllOyflQI9zdrKHjyI1IWnkUdR8=
MIME-Version: 1.0
Received: by 10.152.104.6 with SMTP id ga6mr29970373lab.45.1322533761097; Mon, 28 Nov 2011 18:29:21 -0800 (PST)
Received: by 10.152.13.164 with HTTP; Mon, 28 Nov 2011 18:29:21 -0800 (PST)
In-Reply-To: <750BF7861EBBE048B3E648B4BB6E8F4F2106F69E@crexc50p>
References:    <2963F168-45CB-4042-8238-56DF538B0543@gmail.com>   <2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz> <750BF7861EBBE048B3E648B4BB6E8F4F2106F69E@crexc50p>
Date: Tue, 29 Nov 2011 10:29:21 +0800
Message-ID: 
From: Hans Liu 
To: "STARK, BARBARA H" 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-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: Tue, 29 Nov 2011 02:29:22 -0000

Barbara,

2011/11/29 STARK, BARBARA H :
> I'll re-iterate what I've said before, as to what I need from 6204:
>
> Above all, this document MUST provide guidance for off-the-shelf routers =
that have no knowledge, whatsoever, of who or what is providing the WAN int=
erface. I will not support any proposed language that strays from this.
>
> BBF, CableLabs, 3GPP, et al are 100% free to specify whatever they want f=
or devices that they are able to specify. If they want to stray from 6204, =
they are free to do so.
>
That will be a headache to us small manufactures.

> With that said, I understand that (a) 6204 is driving "IPv6 Ready" logo f=
or routers (b) other orgs would like for their devices to also be able to r=
eceive the logo, and (c) it would be nice if we could avoid providing lots =
of reasons for other orgs to want to stray.
>
ow a WAN-clueless CE router to not request IA_NA, and still be
compliant with 6204(bis).
> Barbara

From Tina.Tsou.Zouting@huawei.com  Mon Nov 28 19:35:40 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02AA521F8B01 for ; Mon, 28 Nov 2011 19:35:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.998
X-Spam-Level: 
X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 wU4tJC0S2NvC for ; Mon, 28 Nov 2011 19:35:37 -0800 (PST)
Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id CD1B921F8AFE for ; Mon, 28 Nov 2011 19:35:35 -0800 (PST)
Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LVE00HA2KN10J@szxga05-in.huawei.com> for v6ops@ietf.org; Tue, 29 Nov 2011 11:35:25 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LVE00LVIKN0C0@szxga05-in.huawei.com> for v6ops@ietf.org; Tue, 29 Nov 2011 11:35:25 +0800 (CST)
Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AFH99062; Tue, 29 Nov 2011 11:35:23 +0800
Received: from SZXEML413-HUB.china.huawei.com (10.82.67.152) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 29 Nov 2011 11:35:14 +0800
Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.40]) by szxeml413-hub.china.huawei.com ([10.82.67.152]) with mapi id 14.01.0323.003; Tue, 29 Nov 2011 11:35:05 +0800
Date: Tue, 29 Nov 2011 03:35:04 +0000
From: Tina TSOU 
In-reply-to: 
X-Originating-IP: [10.193.34.145]
To: "gert@space.net" 
Message-id: 
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_fq6J3tRqsK9hScoSW+rKOg)"
Content-language: en-US
Accept-Language: en-US, zh-CN
Thread-topic: [v6ops] 6rd Sunsetting
Thread-index: AQHMo2zkiVaVmflTEk2DrH6PcFso4ZWtESmAgAF9cYCAACEjgIABVu+AgAfhuoCAADwWAIAAAlqAgABDmgCAAIAigIAAtJqAgABw8oCAAQQ29YAIFkuwgAAdbVA=
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
References:   <68DAB112-6E32-45FE-9AB7-A34E64898F60@cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30354436E@XMB-RCD-109.cisco.com> <750BF7861EBBE048B3E648B4BB6E8F4F20DC41F6@crexc50p>  <252D3DEA-FF09-42C8-959E-8A7205D9DE67@townsley.net>  <20111122133612.GH71280@Space.Net> <4ECC10C9.5010607@gmail.com> <20111123080113.GI71280@Space.Net>   
Cc: Alexandre Cassen , "v6ops@ietf.org" , Claire Cheng 
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 29 Nov 2011 03:35:40 -0000

--Boundary_(ID_fq6J3tRqsK9hScoSW+rKOg)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

Hi,
How does "the CPE has to ensure that it sends packets over the right interface"?
Lets say you have 6rd prefix 2002::/16 which is also the native IPv6 prefix. So if we have a static route like "ipv6 static route 2002::/16 tunnel-interface", how can we have another static route for this prefix with native IPv6 interface?

Tina

From: Mark Townsley >
Date: November 23, 2011 6:45:27 AM PST
To: Gert Doering >
Cc: Alexandre Cassen >, >, Claire Cheng >
Subject: Re: [v6ops] 6rd Sunsetting

In practice, source address checking is done, per-subscriber, at the first L3 hop (BNG, CMTS, etc.) or before (DSLAM, Access Node, etc.).

6rd tunnels over this part of the network. As long as the IPv6 source and IPv4 source are bound, this isn't a problem, as the address checking is being done for IPv4 on a per-subscriber basis, and the BR does a (stateless) check on decap to ensure that the IPv6 source and IPv4 source match.

If you introduce an IPv6 packet with a different source address into the 6rd tunnel and expect it not to be dropped, you are really no longer doing 6rd. Without the mapping to rely on, you have to either choose between decapsulating any packet that arrives (and the associated spoofing implications), or configure ACLs at pick-your-favorite-aggregation-level from the entire ISP down to a single subscriber where you are then essentially importing all the state from the first hop(s) into the BR.

So, I think Gert's right here. For all practical purposes, when a 6rd and native interface are up with different prefixes for each, the CPE has to ensure that it sends packets over the right interface. Same is true for multihoming in general. Only way to get around it is to keep the prefix the same.

- Mark


On Nov 23, 2011, at 9:01 AM, Gert Doering wrote:

Hi,

On Wed, Nov 23, 2011 at 10:14:49AM +1300, Brian E Carpenter wrote:
This, or strict RPF, would be self-foot-shooting by the ISP
wishing to sunset 6rd. It seems fairly simple to specify that
both ingress filtering and RPF should be configured to allow
both prefixes simultaneously.

Permit me a polite cough here.

*The* benefit of 6rd on the gateway side is that it's stateless, which
means "no per-subscriber information needs to be gathered, kept, and
validated for incoming packets".

So either you want RPF filtering on the 6rd side, or not - but there is
no reasonable way you can ISP subscriber data for a reasonable-sized
ISP into the 6rd gateways to enable RPF filtering "plus extra prefixes
for some of the subscribers" on the 6rd gateway.


This is a standard need for
multihomed PA customers anyway, and needs to become standard
practice for all IPv6 ISPs.

This is a standard *problem*, not a "standard need".

You're not going to see large-scale ISPs that do deploy RPF filtering
(few enough, alas) add "oh, this customer also has prefix X from ISP Z
this week!" to their subscriber management platform, which is where the
routers get configured from.  Including verification that this
customer is even entitled to *use* prefix X at this time.


While we do need a solution for source-prefix based exit
selection, we don't have one yet and it's a separable problem.

I strongly disagree.  This is the core of the problem for multi-PA-based
multihoming, and one variant presents itself now with "two different
access technologies with different prefixes to the same ISP".

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
_______________________________________________
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

--Boundary_(ID_fq6J3tRqsK9hScoSW+rKOg)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: quoted-printable













Hi,


How does “the CPE has to ensure that it sends packets over th=
e right interface”?


Lets say you have 6rd pr=
efix 2002::/16 which is also the native
IPv=
6 prefix. So if we have a static route like “ipv6 static route 2002:<=
span class=3D"GramE">:/16 tunnel-interface”, how can we have a=
nother static route for this prefix with native IPv6
 interface?


 




Tina


 








From: Mark Tow=
nsley <mark@townsley.net>
Date: November 23, 2011 6:45:27 AM PST

To: Gert Doering <gert@space.ne=
t>

Cc: Alexandre Cassen <acass=
en@freebox.fr>, <v6ops@ietf.org=
>, Claire Cheng <cla=
ire_cheng@dlink.com.tw>

Subject: Re: [v6ops] 6rd Sunsetting












In practice, source address checking is done, per-subscriber, at the first =
L3 hop (BNG, CMTS, etc.) or before (DSLAM, Access Node, etc.).



6rd tunnels over this part of the network. As long as the IPv6 source and I=
Pv4 source are bound, this isn't a problem, as the address checking is bein=
g done for IPv4 on a per-subscriber basis, and the BR does a (stateless) ch=
eck on decap to ensure that the
 IPv6 source and IPv4 source match.  



If you introduce an IPv6 packet with a different source address into the 6r=
d tunnel and expect it not to be dropped, you are really no longer doing 6r=
d. Without the mapping to rely on, you have to either choose between decaps=
ulating any packet that arrives
 (and the associated spoofing implications), or configure ACLs at pick-your=
-favorite-aggregation-level from the entire ISP down to a single subscriber=
 where you are then essentially importing all the state from the first hop(=
s) into the BR.




So, I think Gert's right here. For all practical purposes, when a 6rd and n=
ative interface are up with different prefixes for each, the CPE has to ens=
ure that it sends packets over the right interface. Same is true for multih=
oming in general. Only way to get
 around it is to keep the prefix the same. 



- Mark





On Nov 23, 2011, at 9:01 AM, Gert Doering wrote:






Hi,




 






On Wed, Nov 23, 2011 at 10:14:49AM +1300, Brian =
E Carpenter wrote:








This, or strict RPF, would be self-foot-shooting by =
the ISP










wishing to sunset 6rd. It seems fairly simple to spe=
cify that










both ingress filtering and RPF should be configured =
to allow










both prefixes simultaneously. 








 






Permit me a polite cough here.






 






*The* benefit of 6rd on the gateway side is that it'=
s stateless, which






means "no per-subscriber information needs to b=
e gathered, kept, and






validated for incoming packets".






 






So either you want RPF filtering on the 6rd side, or=
 not - but there is






no reasonable way you can ISP subscriber data for a =
reasonable-sized






ISP into the 6rd gateways to enable RPF filtering &q=
uot;plus extra prefixes






for some of the subscribers" on the 6rd gateway=
.






 






 








This is a standard need for










multihomed PA customers anyway, and needs to become =
standard










practice for all IPv6 ISPs.








 






This is a standard *problem*, not a "standard n=
eed".






 






You're not going to see large-scale ISPs that do dep=
loy RPF filtering






(few enough, alas) add "oh, this customer also =
has prefix X from ISP Z






this week!" to their subscriber management plat=
form, which is where the







routers get configured from.  Including verific=
ation that this







customer is even entitled to *use* prefix X at this =
time.






 






 








While we do need a solution for source-prefix based =
exit










selection, we don't have one yet and it's a separabl=
e problem.








 






I strongly disagree.  This is the core of the p=
roblem for multi-PA-based






multihoming, and one variant presents itself now wit=
h "two different






access technologies with different prefixes to the s=
ame ISP".






 






Gert Doering






      -- NetMaster






-- 






have you enabled IPv6 on something today...?






 






SpaceNet AG       &nbs=
p;            &=
nbsp;   Vorstand: Sebastian v. Bomhard






Joseph-Dollinger-Bogen 14     &n=
bsp;    Aufsichtsratsvors.: A. Grundner-Culemann






D-80807 Muenchen       =
;            HR=
B: 136055 (AG Muenchen)






Tel: +49 (89) 32356-444     =
       USt-IdNr.: DE813185279=







_______________________________________________=







v6ops mailing list






v6ops@ietf.org=







https://www.ietf.org/mailman/listinfo/v6ops






_______________________________________________

v6ops mailing list

v6ops@ietf.org

https://www.ietf.or=
g/mailman/listinfo/v6ops










--Boundary_(ID_fq6J3tRqsK9hScoSW+rKOg)--

From shemant@cisco.com  Mon Nov 28 19:43:44 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9525B21F8B5E for ; Mon, 28 Nov 2011 19:43:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.561
X-Spam-Level: 
X-Spam-Status: No, score=-6.561 tagged_above=-999 required=5 tests=[AWL=0.037,  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 RTu6TVEROhdQ for ; Mon, 28 Nov 2011 19:43:42 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id E6AD921F8C29 for ; Mon, 28 Nov 2011 19:43:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=8584; q=dns/txt; s=iport; t=1322538221; x=1323747821; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=YAIAuGdHj2hhBPVefvO6u02YEyR3tYVzjiUl9NgHg3k=; b=Yfsrx6qbutje8uCbPcUxls6nWMRV3+eTanP4HEk2gW6s19tij3RpDNAd Pf3Zsuc5jz1eUH/TdHSZvbK9omRgLZIeUT9YdCsoFShroq+zO+reJC51I XjHmqklxS8yN1QH4lTIpvGAEnaybcuuVCUVfqX74Tsqt8TxFc+katCovE k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ap0AACdU1E6tJXG8/2dsb2JhbABDgk2YCpAigQWBcgEBAQQSAQkRA0kMBAIBCBEEAQELBhcBBgFFCQgBAQQBEggTB6AsAZ5WihFjBIghnlY
X-IronPort-AV: E=Sophos;i="4.69,589,1315180800"; d="scan'208,217";a="39577096"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 29 Nov 2011 03:43:40 +0000
Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id pAT3heWR022576;  Tue, 29 Nov 2011 03:43:40 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 28 Nov 2011 21:43:39 -0600
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCAE49.151EB2AD"
Date: Mon, 28 Nov 2011 21:43:37 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3036CD90A@XMB-RCD-109.cisco.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] 6rd Sunsetting
Thread-Index: Acyt+R4rpDoGpQLYTMewEQaKcqdkPgATEhDQ
References:  
From: "Hemant Singh (shemant)" 
To: "Victor Kuarsingh" , "Mark Townsley" , "Tom Taylor" 
X-OriginalArrivalTime: 29 Nov 2011 03:43:39.0951 (UTC) FILETIME=[1543C3F0:01CCAE49]
Cc: Alexandre Cassen , v6ops@ietf.org
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 29 Nov 2011 03:43:44 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CCAE49.151EB2AD
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Victor,

=20

-----Original Message-----
From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
Of Victor Kuarsingh
Sent: Monday, November 28, 2011 1:11 PM
To: Mark Townsley; Tom Taylor
Cc: Alexandre Cassen; v6ops@ietf.org; Claire Cheng
Subject: Re: [v6ops] 6rd Sunsetting

=20

=20

>I think we are assuming that the CE to CE path would be "shortest" if

>using 6RD directly on both endpoints (where one is now Native v6/6RD
and

>the other only 6RD). In my mind, "shortest" path would also include

>performance and overall delay to get form one host to the other (home

>network host to home network host).

=20

Good use case.  Note the rule that Mark specified, as I said, is already
part of RFC 3484, section 6, and Rule 7.  Thus a CPE is entitled to use
the rule 7 and rfc6204bis can still be silent about this rule because
the rule is already specified in RFC 3484.  So here is a potential
solution for the problem above.  If a mistake is made, we need the
network path to issue an ICMPv6 Destination Unreachable back to the
source.  The network path constitutes a direct CPE to CPE path or a path
through the BR.  Thus even when the destination CPE has disabled 6rd to
operate in native IPv6 mode, or the BR has disabled 6rd, each device
still maintains processing for protocol 41.  If protocol 41 processing
is maintained then the BR or the CPE in native IPv6 mode issues an
ICMPv4/ICMPv6 Destination Unreachable.  Barbara can confirm being a DSL
person, but I think direct CE to CE communications in 6rd and DSL is not
really direct.  The data flows thru a BNG or some router.  At least in a
cable network the traffic between two CPEs has to flow through the CMTS
even if the CPEs span the same IPv6 link.  Thus the BNG processes
protocol 41 as well and issues ICMPv4/ICMPv6 Destination Unreachable to
the source CPE.  This solution is agnostic to whether the receiving CPE
changed mode to a different native IPv6 prefix or same IPv6 prefix as
the 6rd prefix.  Likewise the solution is also agnostic to where the BR
and the BNG are co-located or separate - appropriate routes have to be
injected in the BR and the BNG when they are separate.=20

=20

Thanks and regards,

=20

Hemant

=20

=20


------_=_NextPart_001_01CCAE49.151EB2AD
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Victor,
 
-----Original Message-----
From: =
v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of =
Victor Kuarsingh
Sent: Monday, November 28, 2011 1:11 PM
To: Mark =
Townsley; Tom Taylor
Cc: Alexandre Cassen; v6ops@ietf.org; Claire =
Cheng
Subject: Re: [v6ops] 6rd Sunsetting
 
 
>I think we are assuming that the =
CE to CE path would be "shortest" if
>using =
6RD directly on both endpoints (where one is now Native v6/6RD =
and
>the other only 6RD). In my mind, =
"shortest" path would also include
>performance and overall delay to get form one host to the =
other (home
>network host to home network =
host).
 
Good use case.  Note the rule that Mark =
specified, as I said, is already part of RFC 3484, section 6, and Rule =
7.  Thus a CPE is entitled to use the rule 7 and rfc6204bis can =
still be silent about this rule because the rule is already specified in =
RFC 3484.  So here is a potential solution for the problem above. =
 If a mistake is made, we need the network path to issue an ICMPv6 =
Destination Unreachable back to the source.  The network path =
constitutes a direct CPE to CPE path or a path through the BR.  =
Thus even when the destination CPE has disabled 6rd to operate in native =
IPv6 mode, or the BR has disabled 6rd, each device still maintains =
processing for protocol 41.  If protocol 41 processing is =
maintained then the BR or the CPE in native IPv6 mode issues an =
ICMPv4/ICMPv6 Destination Unreachable.  Barbara can confirm =
being a DSL person, but I think direct CE to CE communications in 6rd =
and DSL is not really direct.  The data flows thru a BNG or =
some router.  At least in a cable network the traffic between two =
CPEs has to flow through the CMTS even if the CPEs span the same IPv6 =
link.  Thus the BNG processes protocol 41 as well and issues =
ICMPv4/ICMPv6 Destination Unreachable to the source CPE.  This =
solution is agnostic to whether the receiving CPE changed mode to a =
different native IPv6 prefix or same IPv6 prefix as the 6rd prefix. =
 Likewise the solution is also agnostic to where the BR and the BNG =
are co-located or separate – appropriate routes have to be =
injected in the BR and the BNG when they are separate. =

 
Thanks =
and regards,
 
Hemant
 
 

------_=_NextPart_001_01CCAE49.151EB2AD--

From shemant@cisco.com  Mon Nov 28 20:01:16 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60B1311E8097 for ; Mon, 28 Nov 2011 20:01:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.565
X-Spam-Level: 
X-Spam-Status: No, score=-6.565 tagged_above=-999 required=5 tests=[AWL=0.033,  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 nBS0+rw7OmHf for ; Mon, 28 Nov 2011 20:01:15 -0800 (PST)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 49E9F11E8090 for ; Mon, 28 Nov 2011 20:01:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=10538; q=dns/txt; s=iport; t=1322539275; x=1323748875; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=jJ/Fy6+or4dFrajL7bAxhKmHROqMjs8g4KyptNQ+i04=; b=VzBYjt3DfqljRHN13ajJ/TzHlozh2c26Fik3mV4X3DdfIE8w+08ea8NG WOOjRuK8nuqOfGvLpD8rGNblGWd7pOAVSP2RJOtsLgNgbr80ytinZ6LZF ApiRXs0AFtHtmbdKifYNltqQI2Y5DN+/G9Obd5+7/xTz8utMNCG9eU3Fb Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ap0AAOBY1E6tJXG//2dsb2JhbABDgk2CNpVUjxCBEoEFgXIBAQEDARIBCQcKA0kMBAIBCBEEAQELBhcBAgICAQEfJQkIAQEEEwgah2OYTgGMW5F3iV4zYwSIIZcCh1Q
X-IronPort-AV: E=Sophos;i="4.69,589,1315180800"; d="scan'208,217";a="39557827"
Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-8.cisco.com with ESMTP; 29 Nov 2011 04:01:14 +0000
Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id pAT41EpD027976;  Tue, 29 Nov 2011 04:01:14 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 28 Nov 2011 22:01:14 -0600
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCAE4B.898D1B71"
Date: Mon, 28 Nov 2011 22:01:13 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3036CD910@XMB-RCD-109.cisco.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
Thread-Index: AcyuPrdl+CPuCX+USj6zrA590tWMnwAC/abA
References: <2963F168-45CB-4042-8238-56DF538B0543@gmail.com><2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org><1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz><5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com><1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz><750BF7861EBBE048B3E648B4BB6E8F4F2106F69E@crexc50p> 
From: "Hemant Singh (shemant)" 
To: "Hans Liu" , "STARK, BARBARA H" 
X-OriginalArrivalTime: 29 Nov 2011 04:01:14.0372 (UTC) FILETIME=[89BFA440:01CCAE4B]
Cc: v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-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: Tue, 29 Nov 2011 04:01:16 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CCAE4B.898D1B71
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: base64

SGFucywNCg0KIA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSGFucyBMaXUg
W21haWx0bzpoYW5zbGl1QGdtYWlsLmNvbV0gDQpTZW50OiBNb25kYXksIE5vdmVtYmVyIDI4LCAy
MDExIDk6MjkgUE0NClRvOiBTVEFSSywgQkFSQkFSQSBIDQpDYzogVsOtemRhbCBBbGXFoTsgSGVt
YW50IFNpbmdoIChzaGVtYW50KTsgT2xlIFRyb2FuOyBqb3VuaSBrb3Job25lbjsgdjZvcHNAaWV0
Zi5vcmcNClN1YmplY3Q6IFJlOiBbdjZvcHNdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtdjZvcHMt
NjIwNGJpcy0wMy50eHQNCg0KIA0KDQo+PiBCQkYsIENhYmxlTGFicywgM0dQUCwgZXQgYWwgYXJl
IDEwMCUgZnJlZSB0byBzcGVjaWZ5IHdoYXRldmVyIHRoZXkgd2FudCBmb3IgZGV2aWNlcyB0aGF0
IHRoZXkgYXJlIGFibGUgdG8gc3BlY2lmeS4gSWYgdGhleSA+PndhbnQgdG8gc3RyYXkgZnJvbSA2
MjA0LCB0aGV5IGFyZSBmcmVlIHRvIGRvIHNvLg0KDQogDQoNCj5UaGF0IHdpbGwgYmUgYSBoZWFk
YWNoZSB0byB1cyBzbWFsbCBtYW51ZmFjdHVyZXMuDQoNCiANCg0KV291bGQgeW91ciBoZWFkYWNo
ZSBiZSByZWR1Y2VkIGlmIHJmYzYyMDRiaXMgYWRkZWQgYSBuZXcgc2VjdGlvbiBmb3IgQ29uY2Vw
dHVhbCBDb25maWd1cmF0aW9uIFZhcmlhYmxlcz8gIE9uZSBjb25jZXB0dWFsIGNvbmZpZ3VyYXRp
b24gdmFyaWFibGUgd291bGQgYmUgYSBXQU4gc2V0dGluZyBmb3IgdGhlIFdBTiB0byBiZSAoYSkg
VW5udW1iZXJlZCAod2l0aCBvbmx5IGFuIElQdjYgbGluay1sb2NhbCBhZGRyZXNzKSBhbmQgREhD
UHY2IGFjcXVpcmVzIG9ubHkgSUFfUEQsIChiKSBOdW1iZXJlZCB3aGVyZSB0aGUgV0FOIGFjcXVp
cmVzIGEgZ2xvYmFsIElQdjYgYWRkcmVzcyBmcm9tIERIQ1B2NiBJQV9OQSBJQV9hZGRyZXNzIGFu
ZCBhIHByZWZpeCB2aWEgSUFfUEQsIGFuZCBwZXJoYXBzIGFuIG9wdGlvbiAoYykgd2hlcmUgdGhl
IFdBTiBpcyBhc3NpZ25lZCBhIHN0YXRpYyBJUHY2IGdsb2JhbCBhZGRyZXNzLiAgRFNMLCBDYWJs
ZSwgYW5kIGNlbGx1bGFyIHdpcmVsZXNzIHN1cHBvcnRpbmcgSUFfUEQgd2lsbCBiZSBjb3ZlcmVk
IGJ5IHRoZSBXQU4gc2V0dGluZyBkZXNjcmliZWQgYWJvdmUuDQoNCg0KSGVtYW50DQoNCg==

------_=_NextPart_001_01CCAE4B.898D1B71
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z
b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206
b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm
aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw
QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4
MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj
Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw
dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl
YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u
ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm
aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2
YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z
OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9
Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB
VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z
Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n
cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y
MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz
ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h
cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu
dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht
bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu
dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg
eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz
LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9
Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0
cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0
dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw
Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw
Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i
aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3
Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv
IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp
Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp
Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0
cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v
c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s
bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4
bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw
Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv
aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j
b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl
bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6
cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl
TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No
YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46
c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3
LnczLm9yZy9UUi9SRUMtaHRtbDQwIj48aGVhZD48bWV0YSBodHRwLWVxdWl2PUNvbnRlbnQtVHlw
ZSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjxtZXRhIG5hbWU9R2VuZXJhdG9y
IGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj48c3R5bGU+PCEt
LQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2Ft
YnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UN
Cgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9
DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5
IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGku
TXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTou
MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z
LXNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0
eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp
dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN
Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWlu
VGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlv
cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGlu
Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuNXB0Ow0KCWZvbnQtZmFt
aWx5OkNvbnNvbGFzO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxh
aW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6
IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCi5Nc29DaHBEZWZhdWx0DQoJ
e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl
OjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2Lldv
cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl
IG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy
NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh
cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+
DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGxhbmc9RU4t
VVMgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT48ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBjbGFz
cz1Nc29QbGFpblRleHQ+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPkhh
bnMsPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48bzpwPiZuYnNw
OzwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t
LS08YnI+RnJvbTogSGFucyBMaXUgW21haWx0bzpoYW5zbGl1QGdtYWlsLmNvbV0gPGJyPlNlbnQ6
IE1vbmRheSwgTm92ZW1iZXIgMjgsIDIwMTEgOToyOSBQTTxicj5UbzogU1RBUkssIEJBUkJBUkEg
SDxicj5DYzogVsOtemRhbCBBbGXFoTsgSGVtYW50IFNpbmdoIChzaGVtYW50KTsgT2xlIFRyb2Fu
OyBqb3VuaSBrb3Job25lbjsgdjZvcHNAaWV0Zi5vcmc8YnI+U3ViamVjdDogUmU6IFt2Nm9wc10g
SS1EIEFjdGlvbjogZHJhZnQtaWV0Zi12Nm9wcy02MjA0YmlzLTAzLnR4dDwvcD48cCBjbGFzcz1N
c29QbGFpblRleHQ+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gc3R5bGU9
J2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsmZ3Q7IEJCRiwgQ2FibGVMYWJzLCAzR1BQ
LCBldCBhbCBhcmUgMTAwJSBmcmVlIHRvIHNwZWNpZnkgd2hhdGV2ZXIgdGhleSB3YW50IGZvciBk
ZXZpY2VzIHRoYXQgdGhleSBhcmUgYWJsZSB0byBzcGVjaWZ5LiBJZiB0aGV5ICZndDsmZ3Q7d2Fu
dCB0byBzdHJheSBmcm9tIDYyMDQsIHRoZXkgYXJlIGZyZWUgdG8gZG8gc28uPG86cD48L286cD48
L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6
IkNvdXJpZXIgTmV3Iic+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1Bs
YWluVGV4dD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0O1RoYXQg
d2lsbCBiZSBhIGhlYWRhY2hlIHRvIHVzIHNtYWxsIG1hbnVmYWN0dXJlcy48bzpwPjwvbzpwPjwv
c3Bhbj48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNs
YXNzPU1zb1BsYWluVGV4dD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtj
b2xvcjpibGFjayc+V291bGQgeW91ciBoZWFkYWNoZSBiZSByZWR1Y2VkIGlmIHJmYzYyMDRiaXMg
YWRkZWQgYSBuZXcgc2VjdGlvbiBmb3IgQ29uY2VwdHVhbCBDb25maWd1cmF0aW9uIFZhcmlhYmxl
cz/CoCBPbmUgY29uY2VwdHVhbCBjb25maWd1cmF0aW9uIHZhcmlhYmxlIHdvdWxkIGJlIGEgV0FO
IHNldHRpbmcgZm9yIHRoZSBXQU4gdG8gYmUgKGEpIFVubnVtYmVyZWQgKHdpdGggb25seSBhbiBJ
UHY2IGxpbmstbG9jYWwgYWRkcmVzcykgYW5kIERIQ1B2NiBhY3F1aXJlcyBvbmx5IElBX1BELCAo
YikgTnVtYmVyZWQgd2hlcmUgdGhlIFdBTiBhY3F1aXJlcyBhIGdsb2JhbCBJUHY2IGFkZHJlc3Mg
ZnJvbSBESENQdjYgSUFfTkEgSUFfYWRkcmVzcyBhbmQgYSBwcmVmaXggdmlhIElBX1BELCBhbmQg
cGVyaGFwcyBhbiBvcHRpb24gKGMpIHdoZXJlIHRoZSBXQU4gaXMgYXNzaWduZWQgYSBzdGF0aWMg
SVB2NiBnbG9iYWwgYWRkcmVzcy7CoCBEU0wsIENhYmxlLCBhbmQgY2VsbHVsYXIgd2lyZWxlc3Mg
c3VwcG9ydGluZyBJQV9QRCB3aWxsIGJlIGNvdmVyZWQgYnkgdGhlIFdBTiBzZXR0aW5nIGRlc2Ny
aWJlZCBhYm92ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0Pjxz
cGFuIHN0eWxlPSdmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOmJsYWNrJz48YnI+SGVt
YW50PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvYm9keT48L2h0bWw+

------_=_NextPart_001_01CCAE4B.898D1B71--

From shemant@cisco.com  Mon Nov 28 20:10:41 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF9DB11E80A3 for ; Mon, 28 Nov 2011 20:10:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.568
X-Spam-Level: 
X-Spam-Status: No, score=-6.568 tagged_above=-999 required=5 tests=[AWL=0.030,  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 hR-pCnF+Nl0X for ; Mon, 28 Nov 2011 20:10:40 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 0364821F8ACA for ; Mon, 28 Nov 2011 20:10:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=11414; q=dns/txt; s=iport; t=1322539840; x=1323749440; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=YvADvdvQ3XXFm5nkUzu4ccftTz216YceKIDMD3pSqGI=; b=Aj5YtfOuxzefcB57xUPDVakQS5OHI0qUZrQ7LYfDKsx14g06tEmYu1tK NGBX+HDGBO44MyjNQ/yl/lTGayHDUXsLW6wiD3m6Xz3LrIkmqdyypxIQi nYq7EQU3jrOqTlkgyMcVgn8b41c9QVtWE4tjEmfTwqBBYHX++kYMEHmuz 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ap0AAAxa1E6tJXG9/2dsb2JhbABDgk2YCpAigQWBcgEBAQQSAQkRA0kQAgEIEQQBAQsGFwEGAUUJCAIEARIIGqAzAZ5Sg2GGMGMEiCGeVg
X-IronPort-AV: E=Sophos;i="4.69,589,1315180800"; d="scan'208,217";a="39583286"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-7.cisco.com with ESMTP; 29 Nov 2011 04:10:31 +0000
Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id pAT4AVDX014260;  Tue, 29 Nov 2011 04:10:31 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 28 Nov 2011 22:10:30 -0600
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCAE4C.D546AACB"
Date: Mon, 28 Nov 2011 22:10:29 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3036CD912@XMB-RCD-109.cisco.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] 6rd Sunsetting
Thread-Index: AQHMo2zkiVaVmflTEk2DrH6PcFso4ZWtESmAgAF9cYCAACEjgIABVu+AgAfhuoCAADwWAIAAAlqAgABDmgCAAIAigIAAtJqAgABw8oCAAQQ29YAIFkuwgAAdbVCAAAjLgA==
References: <68DAB112-6E32-45FE-9AB7-A34E64898F60@cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C30354436E@XMB-RCD-109.cisco.com><750BF7861EBBE048B3E648B4BB6E8F4F20DC41F6@crexc50p><252D3DEA-FF09-42C8-959E-8A7205D9DE67@townsley.net><20111122133612.GH71280@Space.Net> <4ECC10C9.5010607@gmail.com><20111123080113.GI71280@Space.Net> 
From: "Hemant Singh (shemant)" 
To: "Tina TSOU" , 
X-OriginalArrivalTime: 29 Nov 2011 04:10:30.0763 (UTC) FILETIME=[D5622BB0:01CCAE4C]
Cc: Alexandre Cassen , v6ops@ietf.org, Claire Cheng 
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 29 Nov 2011 04:10:42 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CCAE4C.D546AACB
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Tina,

=20

From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
Of Tina TSOU
Sent: Monday, November 28, 2011 10:35 PM
To: gert@space.net
Cc: Alexandre Cassen; v6ops@ietf.org; Claire Cheng
Subject: Re: [v6ops] 6rd Sunsetting

=20

=20

>How does "the CPE has to ensure that it sends packets over the right
interface"?

>Lets say you have 6rd prefix 2002::/16 which is also the native IPv6
prefix. So if we have a static route like >"ipv6 static route 2002::/16
tunnel-interface", how can we have >another static route for this prefix
with native >IPv6 interface?

=20

See a configuration example from my IPv6 router for a static IPv6 route
supporting two different network interfaces.

=20

rtr# show run | I ipv6 route

ipv6 route 3001:1234:5678::/48 Bundle1

ipv6 route 3001:1234:5678::/48 GigabitEthernet4/0/0

rtr#

rtr#sh ipv6 route

...

S   3001:1234:5678::/48 [1/0]

     via GigabitEthernet4/0/0, directly connected

     via Bundle1, directly connected

=20

For the same prefix between 6rd and native IPv6, the native IPv6 link is
preferred as specified in bullet 5 of section 4.4.3 of rfc6204bis.

=20

Hemant


------_=_NextPart_001_01CCAE4C.D546AACB
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Tina,
 
From:=
 =
v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of =
Tina TSOU
Sent: Monday, November 28, 2011 10:35 =
PM
To: gert@space.net
Cc: Alexandre Cassen; =
v6ops@ietf.org; Claire Cheng
Subject: Re: [v6ops] 6rd =
Sunsetting
 
 
>How =
does “the CPE has to ensure that it sends packets over the =
right interface”?
>Lets say you have 6rd =
prefix 2002::/16 which is also the native IPv6 prefix. So if we have =
a static route like >“ipv6 static route 2002::/16 =
tunnel-interface”, how can we have >another static route for =
this prefix with native >IPv6 interface?
 
See a configuration example from my IPv6 router for =
a static IPv6 route supporting two different network =
interfaces.
 
rtr# show run | I ipv6 route
ipv6 route 3001:1234:5678::/48 =
Bundle1
ipv6 =
route 3001:1234:5678::/48 GigabitEthernet4/0/0
rtr#
rtr#sh ipv6 route
…
S   3001:1234:5678::/48 =
[1/0]
     via GigabitEthernet4/0/0, =
directly connected
     via Bundle1, directly =
connected
 
For the same prefix between 6rd and native IPv6, the =
native IPv6 link is preferred as specified in bullet 5 of section 4.4.3 =
of rfc6204bis.
 
Hemant

------_=_NextPart_001_01CCAE4C.D546AACB--

From shemant@cisco.com  Mon Nov 28 20:26:28 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D01851F0C45 for ; Mon, 28 Nov 2011 20:26:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.571
X-Spam-Level: 
X-Spam-Status: No, score=-6.571 tagged_above=-999 required=5 tests=[AWL=0.027,  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 woZ7XmPiuY1a for ; Mon, 28 Nov 2011 20:26:28 -0800 (PST)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id DB7FD1F0C3B for ; Mon, 28 Nov 2011 20:26:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=13944; q=dns/txt; s=iport; t=1322540788; x=1323750388; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=SmIe7g0EtyQn0f50ai6OqZ134YIvmEROMSO63s0/MLM=; b=bj7NkD1gwbKTN/Ko4hM+rKBpcEukxR4860WcLi3QItkSUD/t/tpdxtaZ YIq3Zd/k+RTmBwPyBl/AVy4oktpJHhP12jzpa61PzeeistaaeL/62j72Q vHW8F2E2jEP+Ai+uEE1sDJjfoYVDQ+9cRBLS3nUdUkk8Wt38w9PWmhPQl E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ap0AAHRe1E6tJXG8/2dsb2JhbABDgk2CNpVUjxCBEoEFgXIBAQEDARIBCQcKA0kMBAIBCBEEAQELBhcBAgICAQEfJQkIAQEEARIIGodjmFYBjFuReIleM2MEiCGXAodU
X-IronPort-AV: E=Sophos;i="4.69,589,1315180800"; d="scan'208,217";a="39563653"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-8.cisco.com with ESMTP; 29 Nov 2011 04:26:27 +0000
Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id pAT4QR4q005622;  Tue, 29 Nov 2011 04:26:27 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 28 Nov 2011 22:26:27 -0600
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCAE4F.0F41A39B"
Date: Mon, 28 Nov 2011 22:26:26 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3036CD917@XMB-RCD-109.cisco.com>
In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3036CD910@XMB-RCD-109.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
Thread-Index: AcyuPrdl+CPuCX+USj6zrA590tWMnwAC/abAAAD5jqA=
References: <2963F168-45CB-4042-8238-56DF538B0543@gmail.com><2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org><1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz><5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com><1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz><750BF7861EBBE048B3E648B4BB6E8F4F2106F69E@crexc50p> <5B6B2B64C9FE2A489045EEEADDAFF2C3036CD910@XMB-RCD-109.cisco.com>
From: "Hemant Singh (shemant)" 
To: "Hemant Singh (shemant)" , "Hans Liu" , "STARK, BARBARA H" 
X-OriginalArrivalTime: 29 Nov 2011 04:26:27.0173 (UTC) FILETIME=[0F72C150:01CCAE4F]
Cc: v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-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: Tue, 29 Nov 2011 04:26:28 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CCAE4F.0F41A39B
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: base64

SGFucywNCg0KIA0KDQpPbmUgbW9yZSBjbGFyaWZpY2F0aW9uLiAgIEF0IGxlYXN0IHRoZSBjYWJs
ZSBjaGFuZ2VzIG92ZXIgcmZjNjIwNGJpcyBhcmUgb25seSBmb3Igd2hhdOKAmXMgY2FsbGVkIGFz
IGFuIGVSb3V0ZXIgY2FibGUgbW9kZW0gKENNKSB3aGljaCBpcyBhIENNIGNvbWJpbmVkIHdpdGgg
YW4gSVB2NiBDRSByb3V0ZXIgaW4gb25lIHNpbmdsZSBkZXZpY2UuICAgSWYgYSBzbWFsbCByZXRh
aWwgQ0Ugcm91dGVyIHZlbmRvciBzdWNoIGFzIHlvdXJzZWxmIGJ1aWxkcyBvbmx5IGEgc3RhbmRh
bG9uZSBJUHY2IENFIHJvdXRlciwgdGhlIGNhYmxlIGNoYW5nZXMgZG8gbm90IGFmZmVjdCB5b3Vy
IGRldmljZS4gIEJhcmJhcmEgY2FuIHJlcGx5IGZvciB0aGUgRFNMIGNoYW5nZXMgZm9yIHN0YW5k
YWxvbmUgYW5kIGNvbWJpbmVkIERTTCBtb2RlbSBhbmQgSVB2NiBDRSByb3V0ZXIgaW4gb25lIGRl
dmljZS4NCg0KIA0KDQpIZW1hbnQNCg0KIA0KDQpGcm9tOiB2Nm9wcy1ib3VuY2VzQGlldGYub3Jn
IFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEhlbWFudCBTaW5n
aCAoc2hlbWFudCkNClNlbnQ6IE1vbmRheSwgTm92ZW1iZXIgMjgsIDIwMTEgMTE6MDEgUE0NClRv
OiBIYW5zIExpdTsgU1RBUkssIEJBUkJBUkEgSA0KQ2M6IHY2b3BzQGlldGYub3JnDQpTdWJqZWN0
OiBSZTogW3Y2b3BzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXY2b3BzLTYyMDRiaXMtMDMudHh0
DQoNCiANCg0KSGFucywNCg0KIA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog
SGFucyBMaXUgW21haWx0bzpoYW5zbGl1QGdtYWlsLmNvbV0gDQpTZW50OiBNb25kYXksIE5vdmVt
YmVyIDI4LCAyMDExIDk6MjkgUE0NClRvOiBTVEFSSywgQkFSQkFSQSBIDQpDYzogVsOtemRhbCBB
bGXFoTsgSGVtYW50IFNpbmdoIChzaGVtYW50KTsgT2xlIFRyb2FuOyBqb3VuaSBrb3Job25lbjsg
djZvcHNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbdjZvcHNdIEktRCBBY3Rpb246IGRyYWZ0LWll
dGYtdjZvcHMtNjIwNGJpcy0wMy50eHQNCg0KIA0KDQo+PiBCQkYsIENhYmxlTGFicywgM0dQUCwg
ZXQgYWwgYXJlIDEwMCUgZnJlZSB0byBzcGVjaWZ5IHdoYXRldmVyIHRoZXkgd2FudCBmb3IgZGV2
aWNlcyB0aGF0IHRoZXkgYXJlIGFibGUgdG8gc3BlY2lmeS4gSWYgdGhleSA+PndhbnQgdG8gc3Ry
YXkgZnJvbSA2MjA0LCB0aGV5IGFyZSBmcmVlIHRvIGRvIHNvLg0KDQogDQoNCj5UaGF0IHdpbGwg
YmUgYSBoZWFkYWNoZSB0byB1cyBzbWFsbCBtYW51ZmFjdHVyZXMuDQoNCiANCg0KV291bGQgeW91
ciBoZWFkYWNoZSBiZSByZWR1Y2VkIGlmIHJmYzYyMDRiaXMgYWRkZWQgYSBuZXcgc2VjdGlvbiBm
b3IgQ29uY2VwdHVhbCBDb25maWd1cmF0aW9uIFZhcmlhYmxlcz8gIE9uZSBjb25jZXB0dWFsIGNv
bmZpZ3VyYXRpb24gdmFyaWFibGUgd291bGQgYmUgYSBXQU4gc2V0dGluZyBmb3IgdGhlIFdBTiB0
byBiZSAoYSkgVW5udW1iZXJlZCAod2l0aCBvbmx5IGFuIElQdjYgbGluay1sb2NhbCBhZGRyZXNz
KSBhbmQgREhDUHY2IGFjcXVpcmVzIG9ubHkgSUFfUEQsIChiKSBOdW1iZXJlZCB3aGVyZSB0aGUg
V0FOIGFjcXVpcmVzIGEgZ2xvYmFsIElQdjYgYWRkcmVzcyBmcm9tIERIQ1B2NiBJQV9OQSBJQV9h
ZGRyZXNzIGFuZCBhIHByZWZpeCB2aWEgSUFfUEQsIGFuZCBwZXJoYXBzIGFuIG9wdGlvbiAoYykg
d2hlcmUgdGhlIFdBTiBpcyBhc3NpZ25lZCBhIHN0YXRpYyBJUHY2IGdsb2JhbCBhZGRyZXNzLiAg
RFNMLCBDYWJsZSwgYW5kIGNlbGx1bGFyIHdpcmVsZXNzIHN1cHBvcnRpbmcgSUFfUEQgd2lsbCBi
ZSBjb3ZlcmVkIGJ5IHRoZSBXQU4gc2V0dGluZyBkZXNjcmliZWQgYWJvdmUuDQoNCg0KSGVtYW50
DQoNCg==

------_=_NextPart_001_01CCAE4F.0F41A39B
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z
b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206
b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm
aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw
QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4
MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj
Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw
dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl
YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u
ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm
aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2
YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z
OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9
Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB
VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z
Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n
cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y
MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz
ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h
cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu
dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht
bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu
dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg
eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz
LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9
Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0
cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0
dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw
Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw
Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i
aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3
Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv
IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp
Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp
Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0
cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v
c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s
bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4
bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw
Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv
aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j
b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl
bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6
cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl
TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No
YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46
c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3
LnczLm9yZy9UUi9SRUMtaHRtbDQwIj48aGVhZD48bWV0YSBodHRwLWVxdWl2PUNvbnRlbnQtVHlw
ZSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjxtZXRhIG5hbWU9R2VuZXJhdG9y
IGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj48c3R5bGU+PCEt
LQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2Ft
YnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UN
Cgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9
DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAz
IDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9z
ZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1z
b05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFy
Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNh
bGlicmkiLCJzYW5zLXNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z
dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp
bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w
cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9
DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21z
by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsN
CgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuNXB0
Ow0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5
bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv
LXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4u
RW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt
aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVm
YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N
CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g
MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u
MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0
cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b
aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt
YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k
aWZdLS0+PC9oZWFkPjxib2R5IGxhbmc9RU4tVVMgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT48ZGl2
IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9y
OiMxRjQ5N0QnPkhhbnMsPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48
c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxw
IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+T25lIG1vcmUgY2xh
cmlmaWNhdGlvbi7CoMKgIEF0IGxlYXN0IHRoZSBjYWJsZSBjaGFuZ2VzIG92ZXIgcmZjNjIwNGJp
cyBhcmUgb25seSBmb3Igd2hhdOKAmXMgY2FsbGVkIGFzIGFuIGVSb3V0ZXIgY2FibGUgbW9kZW0g
KENNKSB3aGljaCBpcyBhIENNIGNvbWJpbmVkIHdpdGggYW4gSVB2NiBDRSByb3V0ZXIgaW4gb25l
IHNpbmdsZSBkZXZpY2UuwqAgwqBJZiBhIHNtYWxsIHJldGFpbCBDRSByb3V0ZXIgdmVuZG9yIHN1
Y2ggYXMgeW91cnNlbGYgYnVpbGRzIG9ubHkgYSBzdGFuZGFsb25lIElQdjYgQ0Ugcm91dGVyLCB0
aGUgY2FibGUgY2hhbmdlcyBkbyBub3QgYWZmZWN0IHlvdXIgZGV2aWNlLiDCoEJhcmJhcmEgY2Fu
IHJlcGx5IGZvciB0aGUgRFNMIGNoYW5nZXMgZm9yIHN0YW5kYWxvbmUgYW5kIGNvbWJpbmVkIERT
TCBtb2RlbSBhbmQgSVB2NiBDRSByb3V0ZXIgaW4gb25lIGRldmljZS48bzpwPjwvbzpwPjwvc3Bh
bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdj
b2xvcjojMUY0OTdEJz5IZW1hbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y
bWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYg
MS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbic+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxz
cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNl
cmlmIic+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IHY2b3BzLWJvdW5jZXNAaWV0Zi5vcmcgW21h
aWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YgPC9iPkhlbWFudCBT
aW5naCAoc2hlbWFudCk8YnI+PGI+U2VudDo8L2I+IE1vbmRheSwgTm92ZW1iZXIgMjgsIDIwMTEg
MTE6MDEgUE08YnI+PGI+VG86PC9iPiBIYW5zIExpdTsgU1RBUkssIEJBUkJBUkEgSDxicj48Yj5D
Yzo8L2I+IHY2b3BzQGlldGYub3JnPGJyPjxiPlN1YmplY3Q6PC9iPiBSZTogW3Y2b3BzXSBJLUQg
QWN0aW9uOiBkcmFmdC1pZXRmLXY2b3BzLTYyMDRiaXMtMDMudHh0PG86cD48L286cD48L3NwYW4+
PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48
cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l
dyInPkhhbnMsPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48bzpw
PiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+LS0tLS1PcmlnaW5hbCBNZXNz
YWdlLS0tLS08YnI+RnJvbTogSGFucyBMaXUgW21haWx0bzpoYW5zbGl1QGdtYWlsLmNvbV0gPGJy
PlNlbnQ6IE1vbmRheSwgTm92ZW1iZXIgMjgsIDIwMTEgOToyOSBQTTxicj5UbzogU1RBUkssIEJB
UkJBUkEgSDxicj5DYzogVsOtemRhbCBBbGXFoTsgSGVtYW50IFNpbmdoIChzaGVtYW50KTsgT2xl
IFRyb2FuOyBqb3VuaSBrb3Job25lbjsgdjZvcHNAaWV0Zi5vcmc8YnI+U3ViamVjdDogUmU6IFt2
Nm9wc10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi12Nm9wcy02MjA0YmlzLTAzLnR4dDxvOnA+PC9v
OnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNv
dXJpZXIgTmV3Iic+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1BsYWlu
VGV4dD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyZndDsgQkJG
LCBDYWJsZUxhYnMsIDNHUFAsIGV0IGFsIGFyZSAxMDAlIGZyZWUgdG8gc3BlY2lmeSB3aGF0ZXZl
ciB0aGV5IHdhbnQgZm9yIGRldmljZXMgdGhhdCB0aGV5IGFyZSBhYmxlIHRvIHNwZWNpZnkuIElm
IHRoZXkgJmd0OyZndDt3YW50IHRvIHN0cmF5IGZyb20gNjIwNCwgdGhleSBhcmUgZnJlZSB0byBk
byBzby48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIHN0
eWxlPSdmb250LWZhbWlseToiQ291cmllciBOZXciJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ291cmll
ciBOZXciJz4mZ3Q7VGhhdCB3aWxsIGJlIGEgaGVhZGFjaGUgdG8gdXMgc21hbGwgbWFudWZhY3R1
cmVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PG86cD4mbmJz
cDs8L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIHN0eWxlPSdmb250LWZhbWls
eToiQ291cmllciBOZXciO2NvbG9yOmJsYWNrJz5Xb3VsZCB5b3VyIGhlYWRhY2hlIGJlIHJlZHVj
ZWQgaWYgcmZjNjIwNGJpcyBhZGRlZCBhIG5ldyBzZWN0aW9uIGZvciBDb25jZXB0dWFsIENvbmZp
Z3VyYXRpb24gVmFyaWFibGVzPyZuYnNwOyBPbmUgY29uY2VwdHVhbCBjb25maWd1cmF0aW9uIHZh
cmlhYmxlIHdvdWxkIGJlIGEgV0FOIHNldHRpbmcgZm9yIHRoZSBXQU4gdG8gYmUgKGEpIFVubnVt
YmVyZWQgKHdpdGggb25seSBhbiBJUHY2IGxpbmstbG9jYWwgYWRkcmVzcykgYW5kIERIQ1B2NiBh
Y3F1aXJlcyBvbmx5IElBX1BELCAoYikgTnVtYmVyZWQgd2hlcmUgdGhlIFdBTiBhY3F1aXJlcyBh
IGdsb2JhbCBJUHY2IGFkZHJlc3MgZnJvbSBESENQdjYgSUFfTkEgSUFfYWRkcmVzcyBhbmQgYSBw
cmVmaXggdmlhIElBX1BELCBhbmQgcGVyaGFwcyBhbiBvcHRpb24gKGMpIHdoZXJlIHRoZSBXQU4g
aXMgYXNzaWduZWQgYSBzdGF0aWMgSVB2NiBnbG9iYWwgYWRkcmVzcy4mbmJzcDsgRFNMLCBDYWJs
ZSwgYW5kIGNlbGx1bGFyIHdpcmVsZXNzIHN1cHBvcnRpbmcgSUFfUEQgd2lsbCBiZSBjb3ZlcmVk
IGJ5IHRoZSBXQU4gc2V0dGluZyBkZXNjcmliZWQgYWJvdmUuPG86cD48L286cD48L3NwYW4+PC9w
PjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNvdXJpZXIg
TmV3Ijtjb2xvcjpibGFjayc+PGJyPkhlbWFudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48
L2JvZHk+PC9odG1sPg==

------_=_NextPart_001_01CCAE4F.0F41A39B--

From shemant@cisco.com  Mon Nov 28 20:30:19 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C92821F8B6C for ; Mon, 28 Nov 2011 20:30:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.574
X-Spam-Level: 
X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TOf0guBEYFjy for ; Mon, 28 Nov 2011 20:30:18 -0800 (PST)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id BB46B21F8ADE for ; Mon, 28 Nov 2011 20:30:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=674; q=dns/txt; s=iport; t=1322541018; x=1323750618; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=NfiKGzlJ0tCM/3sPEeCwJTPtHlPqULUF9oVTItgLb00=; b=PgMqUlL3G8b6rxVh/4gdSLeViJr4OlaOwRHPGqbyGixtawUuZf/3Dx2Z 9Yt2uDwsNwl3zLGBPVDZCrU92kXhJqWhI0CEki+mTpw5LMQG154TqBYTM QJGf1hF63zRMPz7biDF65d/Dl3C3RMXlu5kNndlL+ArVOtA741Zt4Ax6E k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ap0AACtf1E6tJXG9/2dsb2JhbABDhQOVVI8QgRKBBYFyAQEBBBIBEA0ERQwEAgEIEQQBAQMCBgYXAQICAgEBHyUJCAEBBBMIGqA4AYxbkXeBMIguM2MEiCGVMoFQh1Q
X-IronPort-AV: E=Sophos;i="4.69,589,1315180800"; d="scan'208";a="39579635"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-1.cisco.com with ESMTP; 29 Nov 2011 04:30:18 +0000
Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id pAT4UIpr019650;  Tue, 29 Nov 2011 04:30:18 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 28 Nov 2011 22:30:17 -0600
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64
Date: Mon, 28 Nov 2011 22:30:16 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3036CD919@XMB-RCD-109.cisco.com>
In-Reply-To: <4ED40404.9060708@gmail.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] DHCPv6 option for MAX_SOL_RT
Thread-Index: AcyuGODsYyODKpoqQIi3r8r0kQmEzgANpmSw
References: <269B69AA-6A20-4A15-A1E2-63A54FB973FB@gmail.com><7EB596BF-B175-40BF-ABC8-326599670B04@apple.com><5B6B2B64C9FE2A489045EEEADDAFF2C303544B88@XMB-RCD-109.cisco.com><8D342733-88E6-45D3-B388-E001AE32CD77@employees.org><750BF7861EBBE048B3E648B4BB6E8F4F20DC4FEA@crexc50p><007801cca8c8$5610aa00$0231fe00$@iname.com><750BF7861EBBE048B3E648B4BB6E8F4F20EA1037@crexc50p>		<750BF7861EBBE048B3E!648B4BB6E8F4F20EA1083@crexc50p>		<14640DA2-54E5-46E9-B255-D141F1934596@nominum.com><201111231402.pANE21YK013540@cichlid.raleigh.ibm.com> <4ECD5484.4090009@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF106@XMB-RCD-109.cisco. com> <4E D40404.9060708@gmail.com>
From: "Hemant Singh (shemant)" 
To: "Brian E Carpenter" 
X-OriginalArrivalTime: 29 Nov 2011 04:30:17.0841 (UTC) FILETIME=[98EFE610:01CCAE4F]
Cc: Thomas Narten , IPv6 Operations 
Subject: Re: [v6ops] DHCPv6 option for MAX_SOL_RT
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 29 Nov 2011 04:30:19 -0000

QnJpYW4sDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBCcmlhbiBFIENhcnBl
bnRlciBbbWFpbHRvOmJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbV0gDQpTZW50OiBNb25kYXks
IE5vdmVtYmVyIDI4LCAyMDExIDQ6NTggUE0NClRvOiBIZW1hbnQgU2luZ2ggKHNoZW1hbnQpDQpD
YzogVGhvbWFzIE5hcnRlbjsgSVB2NiBPcGVyYXRpb25zDQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBE
SENQdjYgb3B0aW9uIGZvciBNQVhfU09MX1JUDQoNCg0KPk5vLCBsZXQncyBoYXZlIHBpdHkgb24g
dGhhdCBkb2N1bWVudC4gSSB0aGluayB0aGF0IHRoZSBoZXJtZW5ldXRpY3MNCj5vZiB0aGUgTS9P
IGJpdHMgaGFzIGNvbWUgdXAgaW4gc28gbWFueSBjb250ZXh0cyB0aGF0IGEgc3RhbmQtYWxvbmUg
ZG9jdW1lbnQNCj5pcyBuZWVkZWQuIEkgYW0gbm90IHZvbHVudGVlcmluZy4NCg0KT2ssIEkgYWdy
ZWUgd2l0aCB5b3UuDQoNClRoYW5rcywNCg0KSGVtYW50DQo=

From ichiroumakino@gmail.com  Tue Nov 29 03:07:27 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C537321F8C10 for ; Tue, 29 Nov 2011 03:07:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.224
X-Spam-Level: 
X-Spam-Status: No, score=-3.224 tagged_above=-999 required=5 tests=[AWL=-0.225, 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 Px3cSchnX-GC for ; Tue, 29 Nov 2011 03:07:27 -0800 (PST)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9159421F8BFE for ; Tue, 29 Nov 2011 03:07:26 -0800 (PST)
Received: by bkbzv15 with SMTP id zv15so10844181bkb.31 for ; Tue, 29 Nov 2011 03:07:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=VLj2yQVToGvN74GvVHKQ5kJy4qaT+2eYzNAIGkFO5rQ=; b=IyN+3jPHhklhRDEvgSuFu8ih5xO2M2CN2AJd7o1JUAj4CWn+fcDsgb9Oj1G3COc6hP WmYFr5zUFjDOzPKJ5axw774AmQX8AFZb8xlX5AcdSDXrPusiQ9llWcSqtBLrNKGifDhs 2ZP78m8Lqop4r0OULW9kdB/poHRBsAuSo8VuA=
Received: by 10.204.15.75 with SMTP id j11mr27066170bka.25.1322564845561; Tue, 29 Nov 2011 03:07:25 -0800 (PST)
Received: from [10.147.12.109] (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id h7sm36258722bkw.12.2011.11.29.03.07.19 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 29 Nov 2011 03:07:20 -0800 (PST)
Sender: Ole Troan 
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=windows-1252
From: Ole Troan 
In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3036CD90A@XMB-RCD-109.cisco.com>
Date: Tue, 29 Nov 2011 12:07:17 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:   <5B6B2B64C9FE2A489045EEEADDAFF2C3036CD90A@XMB-RCD-109.cisco.com>
To: Hemant Singh (shemant) 
X-Mailer: Apple Mail (2.1084)
Cc: Alexandre Cassen , v6ops@ietf.org
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 29 Nov 2011 11:07:27 -0000

Hemant,

I don't want to be blunt, but you are spreading misinformation.

a router forwarding packets does not use RFC3484. that's for hosts.
a router in forwarding tunnelled packets (like the CMTS or the BNG in =
your example) does _NOT_ process the payload packet in any way. that's =
kinda the point with tunnels.

cheers,
Ole

> >I think we are assuming that the CE to CE path would be "shortest" if
> >using 6RD directly on both endpoints (where one is now Native v6/6RD =
and
> >the other only 6RD). In my mind, "shortest" path would also include
> >performance and overall delay to get form one host to the other (home
> >network host to home network host).
> =20
> Good use case.  Note the rule that Mark specified, as I said, is =
already part of RFC 3484, section 6, and Rule 7.  Thus a CPE is entitled =
to use the rule 7 and rfc6204bis can still be silent about this rule =
because the rule is already specified in RFC 3484.  So here is a =
potential solution for the problem above.  If a mistake is made, we need =
the network path to issue an ICMPv6 Destination Unreachable back to the =
source.  The network path constitutes a direct CPE to CPE path or a path =
through the BR.  Thus even when the destination CPE has disabled 6rd to =
operate in native IPv6 mode, or the BR has disabled 6rd, each device =
still maintains processing for protocol 41.  If protocol 41 processing =
is maintained then the BR or the CPE in native IPv6 mode issues an =
ICMPv4/ICMPv6 Destination Unreachable.  Barbara can confirm being a DSL =
person, but I think direct CE to CE communications in 6rd and DSL is not =
really direct.  The data flows thru a BNG or some router.  At least in a =
cable network the traffic between two CPEs has to flow through the CMTS =
even if the CPEs span the same IPv6 link.  Thus the BNG processes =
protocol 41 as well and issues ICMPv4/ICMPv6 Destination Unreachable to =
the source CPE.  This solution is agnostic to whether the receiving CPE =
changed mode to a different native IPv6 prefix or same IPv6 prefix as =
the 6rd prefix.  Likewise the solution is also agnostic to where the BR =
and the BNG are co-located or separate =96 appropriate routes have to be =
injected in the BR and the BNG when they are separate.
> =20
> Thanks and regards,
> =20
> Hemant
> =20
> =20
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


From jouni.nospam@gmail.com  Tue Nov 29 03:54:45 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F7C321F8669 for ; Tue, 29 Nov 2011 03:54:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.68
X-Spam-Level: 
X-Spam-Status: No, score=-2.68 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, 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 fwG0GlJ4CEu2 for ; Tue, 29 Nov 2011 03:54:44 -0800 (PST)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 58FB221F8A66 for ; Tue, 29 Nov 2011 03:54:44 -0800 (PST)
Received: by faap14 with SMTP id p14so762601faa.31 for ; Tue, 29 Nov 2011 03:54:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=L2iVYgoODh1OaGL5sluoMJk7P8E5ryjw0BLa7BazCa4=; b=sqjLEAhmi/ypYzdHaZJYJQcU3ZDybD6XXx28P+6bQladbJXAx69RrLjfBOkXr0I3GC AtB0woyuOOdsXnSGe1SnGWoLSuwBemf7IyZ3S7gXZ9n4QoeNXmHkQDWDmMKdUs30dFZQ 7ix5whg6AvkBISJh2fqJczy0mO6J0xOI6/D3M=
Received: by 10.180.4.37 with SMTP id h5mr49072782wih.45.1322567683389; Tue, 29 Nov 2011 03:54:43 -0800 (PST)
Received: from [10.255.131.156] ([192.100.123.77]) by mx.google.com with ESMTPS id 6sm29628753wby.22.2011.11.29.03.54.41 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 29 Nov 2011 03:54:42 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=windows-1252
From: jouni korhonen 
In-Reply-To: <1808340F7EC362469DDFFB112B37E2FCC5E99477F1@SRVHKE02.rdm.cz>
Date: Tue, 29 Nov 2011 13:54:37 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <2963F168-45CB-4042-8238-56DF538B0543@gmail.com><2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz> <8AF88A07-C1C5-4CD9-9E87-9D0F26504641@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99477F1@SRVHKE02.rdm.cz>
To: =?windows-1252?Q?V=EDzdal_Ale=9A?= 
X-Mailer: Apple Mail (2.1084)
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-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: Tue, 29 Nov 2011 11:54:45 -0000

On Nov 28, 2011, at 1:30 PM, V=EDzdal Ale=9A wrote:

> Ole,
>=20
>> -----Original Message-----
>> From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of Ole =
Troan
>> Sent: Monday, November 28, 2011 11:48 AM
>> To: V=EDzdal Ale=9A
>> Cc: Hemant Singh (shemant); jouni korhonen; v6ops@ietf.org
>> Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
>>=20
>> Vizdal,
>>=20
>> different access networks may have different policies or the data =
link type may have
>> various restrictions with regards
>> to address allocation. if it is unnumbered, SLAAC, DHCP or both SLAAC =
and DHCP.
>>=20
>> e.g. typically Cable networks only use DHCP. DSL networks do either =
model. 6rd makes
>> up an address based on an IPv4 address and so on.
>>=20
>> I don't understand how 3GPP links are any different. does it harm =
functioning on a 3GPP
>> link if the CE is _capable_ of doing DHCP address assignment?
>=20
> There seems to be a misunderstanding, the point Jouni and myself are =
trying to make is that=20
> the IA_NA option is not required by the current 3GPP specs, so is less =
likely to be supported
> by the CEs (e.g. MiFi) and potentially preventing them to be compliant =
to this RFC which we=20
> see beneficial (the compliancy).
>=20
> @Jouni, would you agree?

Yes..ish. My main concerns are on off-the-shelf routers that have no =
knowledge, whatsoever, of who or what is providing the WAN interface. =
This can be summarized:

o if CE router sends both IA_NA+IA_PD simultaneously and either receives
  NoAddrsAvail in Advertise/Reply(?) for IA_NA or no IA_NA at all, what
  happens. RFC3315 errata 2471 (and RFC3633 errata 2469) should cover =
this.
  Maybe s short note along the lines of errata texts in WPD-7 would =
suffice?

And then a reference to pd-exclude (I guess this was already accepted.. =
once it is out as an RFC).

Is this reasonable?

- Jouni


>=20
>> cheers,
>> Ole
>=20
> Cheers,
> Ales
>=20
>> On Nov 28, 2011, at 11:20 , V=EDzdal Ale=9A wrote:
>>=20
>>> Hemant,
>>>=20
>>>> -----Original Message-----
>>>> From: Hemant Singh (shemant) [mailto:shemant@cisco.com]
>>>> Sent: Sunday, November 27, 2011 6:06 PM
>>>> To: V=EDzdal Ale=9A; Ole Troan; jouni korhonen
>>>> Cc: v6ops@ietf.org
>>>> Subject: RE: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
>>>>=20
>>>> Vizdal,
>>>>=20
>>>> -----Original Message-----
>>>> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On =
Behalf Of V=EDzdal
>>>> Ale=9A
>>>> Sent: Saturday, November 26, 2011 5:02 PM
>>>> To: Ole Troan; jouni korhonen
>>>> Cc: v6ops@ietf.org
>>>> Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
>>>>=20
>>>>=20
>>>>> I have the same concern as Jouni that the IPv6 CE router (e.g. =
Mi-Fi device)
>> having a
>>>> 3GPP access
>>>>> based WAN link only would be required to support the IA_NA option =
on the WAN
>> link
>>>> to be able to be
>>>>> compliant to this RFC (I am saying on the WAN link, because this =
requirement is
>>>> placed under the WAA
>>>>> - WAN Address Allocation section).
>>>>=20
>>>> The rfc6204bis document only supports a cellular client for DHCPv6 =
PD.  Thus any
>>>> legacy 3GPP cellular client that does not support DHCPv6 PD =
acquisition is not
>>>> supported by rfc6204bis.
>>>=20
>>> OK.
>>>=20
>>>> Thereafter if the cellular client supports DHCPv6 PD, the
>>>> device already supports the IA_PD option, so what is the big deal =
for the client to
>> also
>>>> support the IA_NA option but the client does not use this option?
>>>=20
>>> What is the issue you currently see with relaxing this one for a =
non-DHCPv6 based
>> address
>>> allocation?
>>>=20
>>> Even if supported by the IPv6 CE, the support for it cannot be =
verified as the 3GPP
>> nodes
>>> along the path do not support statefull address allocation.
>>>=20
>>> I would see beneficial to allow 'current' 3GPP compliant CEs to be =
compliant to this
>> RFC as well.
>>>=20
>>>> Thanks for catching the spelling error for "specified".  It has =
been fixed.
>>>=20
>>> You're welcome.
>>>=20
>>>> Hemant
>>>=20
>>> Cheers,
>>> Ales
>=20


From shemant@cisco.com  Tue Nov 29 05:53:27 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32BA821F8AC9 for ; Tue, 29 Nov 2011 05:53:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.575
X-Spam-Level: 
X-Spam-Status: No, score=-6.575 tagged_above=-999 required=5 tests=[AWL=0.023,  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 GiZFA9LhGOt6 for ; Tue, 29 Nov 2011 05:53:26 -0800 (PST)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id BCF3621F8ABC for ; Tue, 29 Nov 2011 05:53:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8386; q=dns/txt; s=iport; t=1322574805; x=1323784405; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=shUYxqBDHiRMH96tHwhwwjgrNE5ZuqFWdLTE+viWgZI=; b=V6BFLvezYuciJsKlTEPi8v6exJGDrzVJu7CUldG64vBtd59qFcMAHVQO 5WPwrzjGUia1BOkKG7ZgtbRcvi5SMUGaFfARltCmqOrW4KMmi94OEgOZo IxPaDMCQiU0kt6T84JREZZzzwM2+chwUreq+aG+vzUsAsasP3QFKStVzF U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhEBABEppk6tJV2c/2dsb2JhbACCJY4gjhZ4lFWSNIYZBIZQjXmEE4ZJ
X-IronPort-AV: E=Sophos;i="4.69,590,1315180800"; d="scan'208,217";a="37173622"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 29 Nov 2011 13:53:22 +0000
Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id pATDrMSi023029;  Tue, 29 Nov 2011 13:53:22 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 29 Nov 2011 07:53:22 -0600
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCAE9E.420114D2"
Date: Tue, 29 Nov 2011 07:53:21 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3036CD978@XMB-RCD-109.cisco.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] 6rd Sunsetting
Thread-Index: AcyuhxQ49aAuFxu0T5OuQO7+mNjhpQAFVlpg
References:   <5B6B2B64C9FE2A489045EEEADDAFF2C3036CD90A@XMB-RCD-109.cisco.com> 
From: "Hemant Singh (shemant)" 
To: "Ole Troan" 
X-OriginalArrivalTime: 29 Nov 2011 13:53:22.0752 (UTC) FILETIME=[42503400:01CCAE9E]
Cc: Alexandre Cassen , v6ops@ietf.org
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 29 Nov 2011 13:53:27 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CCAE9E.420114D2
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

=20

-----Original Message-----
From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of Ole Troan
Sent: Tuesday, November 29, 2011 6:07 AM
To: Hemant Singh (shemant)
Cc: Victor Kuarsingh; Mark Townsley; Tom Taylor; Alexandre Cassen;
v6ops@ietf.org
Subject: Re: [v6ops] 6rd Sunsetting

=20

=20

>a router forwarding packets does not use RFC3484. that's for hosts.

>a router in forwarding tunnelled packets (like the CMTS or the BNG in
your example) does _NOT_ process the payload packet in any way. >that's
kinda the point with tunnels.

=20

The CE router is doing source-based forwarding and will switch tunneled
or native for different prefixes between native and 6rd.  The rule that
Mark specified is the same rule as in RFC 3484 to decide between
tunneled vs. native.  It's a matter of opinion what text to use and add
to any of townsley or the rfc6204bis document.  Anyway, back to the use
case that Victor raised.  First the use case makes sense to add to the
townsley 6rd sunsetting document.  Then we discuss the solution for the
problem that the use case raises.=20

=20

Hemant

=20


------_=_NextPart_001_01CCAE9E.420114D2
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


 
-----Original Message-----
From: Ole Troan =
[mailto:ichiroumakino@gmail.com] On Behalf Of Ole Troan
Sent: =
Tuesday, November 29, 2011 6:07 AM
To: Hemant Singh (shemant)
Cc: =
Victor Kuarsingh; Mark Townsley; Tom Taylor; Alexandre Cassen; =
v6ops@ietf.org
Subject: Re: [v6ops] 6rd Sunsetting
 
 
>a =
router forwarding packets does not use RFC3484. that's for =
hosts.
>a router in forwarding tunnelled =
packets (like the CMTS or the BNG in your example) does _NOT_ process =
the payload packet in any way. >that's kinda the point with =
tunnels.
 
The CE router is doing source-based forwarding and =
will switch tunneled or native for different prefixes between native and =
6rd.  The rule that Mark specified is the same rule as in RFC 3484 =
to decide between tunneled vs. native.  It’s a matter of =
opinion what text to use and add to any of townsley or the rfc6204bis =
document.  Anyway, back to the use case that Victor raised. =
 First the use case makes sense to add to the townsley 6rd =
sunsetting document.  Then we discuss the solution for the problem =
that the use case raises. 
 
Hemant
 

------_=_NextPart_001_01CCAE9E.420114D2--

From hansliu@gmail.com  Tue Nov 29 08:29:07 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F23621F8C5F for ; Tue, 29 Nov 2011 08:29:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7UFpC57CRBo4 for ; Tue, 29 Nov 2011 08:29:06 -0800 (PST)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id B37C221F8C5E for ; Tue, 29 Nov 2011 08:29:06 -0800 (PST)
Received: by iaeo4 with SMTP id o4so12990836iae.31 for ; Tue, 29 Nov 2011 08:29:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=WpE1pma9FHZv107FL/zGgZyGM3bm+xNmiS3d9dqHdxo=; b=DFJNh3kiNyacJO6BQRs2xMt7Cy7461gW095uCeINLfZoq7E5H+40cNDQ1cbOnc46fl Ihl3FBFsHsxExM1kLgz4gHVf+U2xuei7fivqQ9914tbYjnHZOA2UtiH0E6iYDBMjvk/Y milW8BzddOa+UliYW9G/oVep0LBPeh4Wo2HQU=
MIME-Version: 1.0
Received: by 10.50.189.231 with SMTP id gl7mr60020812igc.44.1322584146079; Tue, 29 Nov 2011 08:29:06 -0800 (PST)
Received: by 10.231.172.71 with HTTP; Tue, 29 Nov 2011 08:29:05 -0800 (PST)
In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3036CD917@XMB-RCD-109.cisco.com>
References:    <2963F168-45CB-4042-8238-56DF538B0543@gmail.com>   <2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz> <750BF7861EBBE048B3E648B4BB6E8F4F2106F69E@crexc50p>  <5B6B2B64C9FE2A489045EEEADDAFF2C3036CD910@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3036CD917@XMB-RCD-109.cisco.com>
Date: Wed, 30 Nov 2011 00:29:05 +0800
Message-ID: 
From: Hans Liu 
To: "Hemant Singh (shemant)" 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Claire Cheng , v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-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: Tue, 29 Nov 2011 16:29:07 -0000

Hemant,

> One more clarification.=C2=A0=C2=A0 At least the cable changes over rfc62=
04bis are
> only for what=E2=80=99s called as an eRouter cable modem (CM) which is a =
CM combined
> with an IPv6 CE router in one single device.=C2=A0 =C2=A0If a small retai=
l CE router
> vendor such as yourself builds only a standalone IPv6 CE router, the cabl=
e
> changes do not affect your device. =C2=A0Barbara can reply for the DSL ch=
anges
> for standalone and combined DSL modem and IPv6 CE router in one device.

Really?  : -)

>>> BBF, CableLabs, 3GPP, et al are 100% free to specify whatever they want
>>> for devices that they are able to specify. If they >>want to stray from
>>> 6204, they are free to do so.
>
>>That will be a headache to us small manufactures.
>
> Would your headache be reduced if rfc6204bis added a new section for
> Conceptual Configuration Variables?=C2=A0 One conceptual configuration va=
riable
> would be a WAN setting for the WAN to be (a) Unnumbered (with only an IPv=
6
> link-local address) and DHCPv6 acquires only IA_PD, (b) Numbered where th=
e
> WAN acquires a global IPv6 address from DHCPv6 IA_NA IA_address and a pre=
fix
> via IA_PD, and perhaps an option (c) where the WAN is assigned a static I=
Pv6
> global address.=C2=A0 DSL, Cable, and cellular wireless supporting IA_PD =
will be
> covered by the WAN setting described above.

I think so. At least, it is clear what are covered and what are out of scop=
e.

>
> Hemant

Hans

From shemant@cisco.com  Tue Nov 29 08:53:01 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDE1A21F8508 for ; Tue, 29 Nov 2011 08:53:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.577
X-Spam-Level: 
X-Spam-Status: No, score=-6.577 tagged_above=-999 required=5 tests=[AWL=0.022,  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 v3gy-moXjW+h for ; Tue, 29 Nov 2011 08:53:01 -0800 (PST)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0F20B21F8505 for ; Tue, 29 Nov 2011 08:53:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=2558; q=dns/txt; s=iport; t=1322585581; x=1323795181; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=APTpf9rPEkSt0E2bOuJtwTI2lchJT0Gs3LHfXSUIw7c=; b=CmNE9v7l38OaGi9YyAjw66YKKcTL8BmRERsPoFRW1wP6KubXVoa8nrvy 84LQndUbToWp/zvTEJrLWdXLCxAOAt4DE8w8bxb8gZBNzLSBqYMu5SKl6 ZsEag8++ER4Ff1I52UpISGy9+fFqD8PnW/9qZYf7nvbJwf4y8sm/wMrM2 M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApwAAGIN1U6tJV2Z/2dsb2JhbABDhQOVX48TgQWBBYFyAQEBAwESARANBEUFBwQCAQgRBAEBAwIGBhcBAgICAQEfJQkIAQEEEwgah2OZAQGMW5FzgTCIWDNjBIgnlwmHVA
X-IronPort-AV: E=Sophos;i="4.69,591,1315180800"; d="scan'208";a="39727264"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 29 Nov 2011 16:53:00 +0000
Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pATGr0qc031528;  Tue, 29 Nov 2011 16:53:00 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 29 Nov 2011 10:52:59 -0600
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64
Date: Tue, 29 Nov 2011 10:52:59 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3036CDA8B@XMB-RCD-109.cisco.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
Thread-Index: AcyutAREIT/MAnn4T6Ss5xJ1kwXwVQAAynVw
References: <2963F168-45CB-4042-8238-56DF538B0543@gmail.com><2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org><1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz><5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com><1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz><750BF7861EBBE048B3E648B4BB6E8F4F2106F69E@crexc50p><5B6B2B64C9FE2A489045EEEADDAFF2C3036CD910@XMB-RCD-109.cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C3036CD917@XMB-RCD-109.cisco.com> 
From: "Hemant Singh (shemant)" 
To: "Hans Liu" 
X-OriginalArrivalTime: 29 Nov 2011 16:52:59.0623 (UTC) FILETIME=[59D43770:01CCAEB7]
Cc: Claire Cheng , v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-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: Tue, 29 Nov 2011 16:53:02 -0000

SGFucywNCg0KSSB3aWxsIGRpc2N1c3Mgd2l0aCB0aGUgQ1BFIGRlc2lnbiB0ZWFtIGFuZCBnZXQg
dGhlaXIgaW5wdXQgb24gYWRkaW5nIHRoZSBDb25jZXB0dWFsIENvbmZpZ3VyYXRpb24gc2VjdGlv
biB0byByZmM2MjA0YmlzLiAgDQoNClRoYW5rcywNCg0KSGVtYW50DQoNCi0tLS0tT3JpZ2luYWwg
TWVzc2FnZS0tLS0tDQpGcm9tOiBIYW5zIExpdSBbbWFpbHRvOmhhbnNsaXVAZ21haWwuY29tXSAN
ClNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDI5LCAyMDExIDExOjI5IEFNDQpUbzogSGVtYW50IFNp
bmdoIChzaGVtYW50KQ0KQ2M6IFNUQVJLLCBCQVJCQVJBIEg7IHY2b3BzQGlldGYub3JnOyBDbGFp
cmUgQ2hlbmcNClN1YmplY3Q6IFJlOiBbdjZvcHNdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtdjZv
cHMtNjIwNGJpcy0wMy50eHQNCg0KSGVtYW50LA0KDQo+IE9uZSBtb3JlIGNsYXJpZmljYXRpb24u
wqDCoCBBdCBsZWFzdCB0aGUgY2FibGUgY2hhbmdlcyBvdmVyIHJmYzYyMDRiaXMgYXJlDQo+IG9u
bHkgZm9yIHdoYXTigJlzIGNhbGxlZCBhcyBhbiBlUm91dGVyIGNhYmxlIG1vZGVtIChDTSkgd2hp
Y2ggaXMgYSBDTSBjb21iaW5lZA0KPiB3aXRoIGFuIElQdjYgQ0Ugcm91dGVyIGluIG9uZSBzaW5n
bGUgZGV2aWNlLsKgIMKgSWYgYSBzbWFsbCByZXRhaWwgQ0Ugcm91dGVyDQo+IHZlbmRvciBzdWNo
IGFzIHlvdXJzZWxmIGJ1aWxkcyBvbmx5IGEgc3RhbmRhbG9uZSBJUHY2IENFIHJvdXRlciwgdGhl
IGNhYmxlDQo+IGNoYW5nZXMgZG8gbm90IGFmZmVjdCB5b3VyIGRldmljZS4gwqBCYXJiYXJhIGNh
biByZXBseSBmb3IgdGhlIERTTCBjaGFuZ2VzDQo+IGZvciBzdGFuZGFsb25lIGFuZCBjb21iaW5l
ZCBEU0wgbW9kZW0gYW5kIElQdjYgQ0Ugcm91dGVyIGluIG9uZSBkZXZpY2UuDQoNClJlYWxseT8g
IDogLSkNCg0KPj4+IEJCRiwgQ2FibGVMYWJzLCAzR1BQLCBldCBhbCBhcmUgMTAwJSBmcmVlIHRv
IHNwZWNpZnkgd2hhdGV2ZXIgdGhleSB3YW50DQo+Pj4gZm9yIGRldmljZXMgdGhhdCB0aGV5IGFy
ZSBhYmxlIHRvIHNwZWNpZnkuIElmIHRoZXkgPj53YW50IHRvIHN0cmF5IGZyb20NCj4+PiA2MjA0
LCB0aGV5IGFyZSBmcmVlIHRvIGRvIHNvLg0KPg0KPj5UaGF0IHdpbGwgYmUgYSBoZWFkYWNoZSB0
byB1cyBzbWFsbCBtYW51ZmFjdHVyZXMuDQo+DQo+IFdvdWxkIHlvdXIgaGVhZGFjaGUgYmUgcmVk
dWNlZCBpZiByZmM2MjA0YmlzIGFkZGVkIGEgbmV3IHNlY3Rpb24gZm9yDQo+IENvbmNlcHR1YWwg
Q29uZmlndXJhdGlvbiBWYXJpYWJsZXM/wqAgT25lIGNvbmNlcHR1YWwgY29uZmlndXJhdGlvbiB2
YXJpYWJsZQ0KPiB3b3VsZCBiZSBhIFdBTiBzZXR0aW5nIGZvciB0aGUgV0FOIHRvIGJlIChhKSBV
bm51bWJlcmVkICh3aXRoIG9ubHkgYW4gSVB2Ng0KPiBsaW5rLWxvY2FsIGFkZHJlc3MpIGFuZCBE
SENQdjYgYWNxdWlyZXMgb25seSBJQV9QRCwgKGIpIE51bWJlcmVkIHdoZXJlIHRoZQ0KPiBXQU4g
YWNxdWlyZXMgYSBnbG9iYWwgSVB2NiBhZGRyZXNzIGZyb20gREhDUHY2IElBX05BIElBX2FkZHJl
c3MgYW5kIGEgcHJlZml4DQo+IHZpYSBJQV9QRCwgYW5kIHBlcmhhcHMgYW4gb3B0aW9uIChjKSB3
aGVyZSB0aGUgV0FOIGlzIGFzc2lnbmVkIGEgc3RhdGljIElQdjYNCj4gZ2xvYmFsIGFkZHJlc3Mu
wqAgRFNMLCBDYWJsZSwgYW5kIGNlbGx1bGFyIHdpcmVsZXNzIHN1cHBvcnRpbmcgSUFfUEQgd2ls
bCBiZQ0KPiBjb3ZlcmVkIGJ5IHRoZSBXQU4gc2V0dGluZyBkZXNjcmliZWQgYWJvdmUuDQoNCkkg
dGhpbmsgc28uIEF0IGxlYXN0LCBpdCBpcyBjbGVhciB3aGF0IGFyZSBjb3ZlcmVkIGFuZCB3aGF0
IGFyZSBvdXQgb2Ygc2NvcGUuDQoNCj4NCj4gSGVtYW50DQoNCkhhbnMNCg==

From bs7652@att.com  Tue Nov 29 09:03:14 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 657C31F0C45 for ; Tue, 29 Nov 2011 09:03:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.223
X-Spam-Level: 
X-Spam-Status: No, score=-106.223 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 MkoPseJjRkPa for ; Tue, 29 Nov 2011 09:03:13 -0800 (PST)
Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id 14A941F0C52 for ; Tue, 29 Nov 2011 09:03:13 -0800 (PST)
X-Env-Sender: bs7652@att.com
X-Msg-Ref: server-9.tower-120.messagelabs.com!1322586182!51267973!1
X-Originating-IP: [144.160.20.146]
X-StarScan-Version: 6.3.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 7531 invoked from network); 29 Nov 2011 17:03:03 -0000
Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-9.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Nov 2011 17:03:03 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.5) with ESMTP id pATH1Zqa018495; Tue, 29 Nov 2011 12:01:35 -0500
Received: from 01AL10015010626.AD.BLS.COM (sfldmibbcraeninet1-v2.enaf.ait.sbc.com [10.231.16.33]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.5) with ESMTP id pATH1UWd018413; Tue, 29 Nov 2011 12:01:31 -0500
Received: from 01NC27689010627.AD.BLS.COM ([90.144.44.202]) by 01AL10015010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 29 Nov 2011 11:02:07 -0600
Received: from 01NC27689010650.AD.BLS.COM ([90.144.44.120]) by 01NC27689010627.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 29 Nov 2011 12:02:07 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCAEB8.889DAB70"
Date: Tue, 29 Nov 2011 12:02:15 -0500
Message-ID: <750BF7861EBBE048B3E648B4BB6E8F4F212EB1F3@crexc50p>
In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3036CD910@XMB-RCD-109.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
Thread-Index: AcyuPrdl+CPuCX+USj6zrA590tWMnwAC/abAABrXfVA=
References: <2963F168-45CB-4042-8238-56DF538B0543@gmail.com><2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org><1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz><5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com><1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz><750BF7861EBBE048B3E648B4BB6E8F4F2106F69E@crexc50p>  <5B6B2B64C9FE2A489045EEEADDAFF2C3036CD910@XMB-RCD-109.cisco.com>
From: "STARK, BARBARA H" 
To: "Hemant Singh (shemant)" , "Hans Liu" 
X-OriginalArrivalTime: 29 Nov 2011 17:02:07.0475 (UTC) FILETIME=[A05FCC30:01CCAEB8]
Cc: v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-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: Tue, 29 Nov 2011 17:03:14 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CCAEB8.889DAB70
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: base64

VGhlIHNwZWNpZmljIG9yZ3MgY3JlYXRlIHJlcXVpcmVtZW50cyB0aGF0IGFyZSB1c2VkIGJ5IHRo
ZWlyIGNvbnN0aXR1ZW50cyB3aGVuIHByb2N1cmluZyBkZXZpY2VzIHRoYXQgYXJlIHNwZWNpZmlj
YWxseSBpbnRlbmRlZCB0byBvcGVyYXRlIG9uIHRoZSBjb25zdGl0dWVudHPigJkgbmV0d29ya3Mu
IFRoZXNlIGFyZSBvZnRlbiBtYW5hZ2VkIGRldmljZXMuIFRoZXkgYXJlIG5vdCBXQU4tY2x1ZWxl
c3MgZGV2aWNlcy4gVGhleSBleGlzdCwgdGhlIHNwZWNzIGV4aXN0LCBhbmQgdGhpcyBpcyBqdXN0
IHRoZSB3YXkgdGhpbmdzIGFyZS4gSeKAmW0gbm90IGF3YXJlIG9mIGFueXRoaW5nIGFueWJvZHkg
Y2FuIGRvIHRvIGNoYW5nZSB0aGlzLiBNeSByZWFzb24gZm9yIHN0YXRpbmcgdGhpcyBmYWN0IHdh
cyB0byBzaW1wbHkgbWFrZSBzdXJlIHdlIGFsbCB1bmRlcnN0b29kIHRoaXMgZmFjdC4gSXQgaXMg
d2hhdCBpdCBpcy4NCg0KIA0KDQpIZW1hbnQsIEkgZG9u4oCZdCBxdWl0ZSB1bmRlcnN0YW5kIHdo
YXQgeW914oCZcmUgcHJvcG9zaW5nLCBidXQgaXQgbWFrZXMgbWUgdW5jb21mb3J0YWJsZS4gVGhl
IFdBTi1jbHVlbGVzcyBkZXZpY2UgbXVzdCBub3QgcmVxdWlyZSB1c2VyIGNvbmZpZ3VyYXRpb24g
d2hlbiBjb25uZWN0ZWQgdG8gYSBwYXJ0aWN1bGFyIFdBTiwgaWYgYXQgYWxsIHBvc3NpYmxlLiBU
aGF0IHdhcyBhIHZlcnkgaW1wb3J0YW50IGRlc2lnbiBwcmluY2lwbGUuIFRoZSA2MjA0IHJlcXVp
cmVtZW50cyB3ZXJlIGludGVuZGVkIHRvIGFsbG93IHRoZSBXQU4gaW50ZXJmYWNlIHRvIGF1dG9t
YXRpY2FsbHkgZXN0YWJsaXNoIGNvbm5lY3Rpdml0eSwgbm8gbWF0dGVyIHdoaWNoIFdBTiBpdCBj
b25uZWN0ZWQgdG8gKHRvIHRoZSBncmVhdGVzdCBleHRlbnQgcG9zc2libGUpLiBJ4oCZbSBvayBp
ZiBzb21lIG9mIHRoZSA2MjA0YmlzIHJlcXVpcmVtZW50cyBwcm92aWRlIGV4Y2VwdGlvbnMgZm9y
IGRldmljZXMgdGhhdCBhcmUgY29uZmlndXJlZCBjZXJ0YWluIHdheXMuIFRoaXMgYWNrbm93bGVk
Z2VzIHRoYXQgaXQgaXMgcG9zc2libGUgZm9yIHN1Y2ggcHJlLWNvbmZpZ3VyZWQgZGV2aWNlcyB0
byBleGlzdC4gQnV0IGV4cGxpY2l0bHkgZGVzY3JpYmluZyBhbmQgY2FsbGluZyBvdXQgdGhlc2Ug
Y29uZmlndXJhdGlvbiBwb3NzaWJpbGl0aWVzIGluIHRoZWlyIG93biBzZWN0aW9uIGlzIHNvbWV0
aGluZyBJ4oCZbSBub3QgaW4gZmF2b3Igb2YuIFRoZSBjb25maWd1cmF0aW9uIGV4Y2x1c2lvbnMg
YXJlIHRoZXJlIHRvIGFsbG93IG90aGVyIG9yZ3Mgd2lnZ2xlLXJvb20gd2hlbiB3cml0aW5nIHRo
ZWlyIG93biBzcGVjcy4gVGhleSBhcmVu4oCZdCBzb21ldGhpbmcgdGhhdCBXQU4tY2x1ZWxlc3Mg
ZGV2aWNlcyBzaG91bGQgbmVlZCB0byBrbm93IGFueXRoaW5nIGFib3V0Lg0KDQpCYXJiYXJhDQoN
CiANCg0KRnJvbTogSGVtYW50IFNpbmdoIChzaGVtYW50KSBbbWFpbHRvOnNoZW1hbnRAY2lzY28u
Y29tXSANClNlbnQ6IE1vbmRheSwgTm92ZW1iZXIgMjgsIDIwMTEgMTE6MDEgUE0NClRvOiBIYW5z
IExpdTsgU1RBUkssIEJBUkJBUkEgSA0KQ2M6IFbDrXpkYWwgQWxlxaE7IE9sZSBUcm9hbjsgam91
bmkga29yaG9uZW47IHY2b3BzQGlldGYub3JnDQpTdWJqZWN0OiBSRTogW3Y2b3BzXSBJLUQgQWN0
aW9uOiBkcmFmdC1pZXRmLXY2b3BzLTYyMDRiaXMtMDMudHh0DQoNCiANCg0KSGFucywNCg0KIA0K
DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSGFucyBMaXUgW21haWx0bzpoYW5z
bGl1QGdtYWlsLmNvbV0gDQpTZW50OiBNb25kYXksIE5vdmVtYmVyIDI4LCAyMDExIDk6MjkgUE0N
ClRvOiBTVEFSSywgQkFSQkFSQSBIDQpDYzogVsOtemRhbCBBbGXFoTsgSGVtYW50IFNpbmdoIChz
aGVtYW50KTsgT2xlIFRyb2FuOyBqb3VuaSBrb3Job25lbjsgdjZvcHNAaWV0Zi5vcmcNClN1Ympl
Y3Q6IFJlOiBbdjZvcHNdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtdjZvcHMtNjIwNGJpcy0wMy50
eHQNCg0KIA0KDQo+PiBCQkYsIENhYmxlTGFicywgM0dQUCwgZXQgYWwgYXJlIDEwMCUgZnJlZSB0
byBzcGVjaWZ5IHdoYXRldmVyIHRoZXkgd2FudCBmb3IgZGV2aWNlcyB0aGF0IHRoZXkgYXJlIGFi
bGUgdG8gc3BlY2lmeS4gSWYgdGhleSA+PndhbnQgdG8gc3RyYXkgZnJvbSA2MjA0LCB0aGV5IGFy
ZSBmcmVlIHRvIGRvIHNvLg0KDQogDQoNCj5UaGF0IHdpbGwgYmUgYSBoZWFkYWNoZSB0byB1cyBz
bWFsbCBtYW51ZmFjdHVyZXMuDQoNCiANCg0KV291bGQgeW91ciBoZWFkYWNoZSBiZSByZWR1Y2Vk
IGlmIHJmYzYyMDRiaXMgYWRkZWQgYSBuZXcgc2VjdGlvbiBmb3IgQ29uY2VwdHVhbCBDb25maWd1
cmF0aW9uIFZhcmlhYmxlcz8gIE9uZSBjb25jZXB0dWFsIGNvbmZpZ3VyYXRpb24gdmFyaWFibGUg
d291bGQgYmUgYSBXQU4gc2V0dGluZyBmb3IgdGhlIFdBTiB0byBiZSAoYSkgVW5udW1iZXJlZCAo
d2l0aCBvbmx5IGFuIElQdjYgbGluay1sb2NhbCBhZGRyZXNzKSBhbmQgREhDUHY2IGFjcXVpcmVz
IG9ubHkgSUFfUEQsIChiKSBOdW1iZXJlZCB3aGVyZSB0aGUgV0FOIGFjcXVpcmVzIGEgZ2xvYmFs
IElQdjYgYWRkcmVzcyBmcm9tIERIQ1B2NiBJQV9OQSBJQV9hZGRyZXNzIGFuZCBhIHByZWZpeCB2
aWEgSUFfUEQsIGFuZCBwZXJoYXBzIGFuIG9wdGlvbiAoYykgd2hlcmUgdGhlIFdBTiBpcyBhc3Np
Z25lZCBhIHN0YXRpYyBJUHY2IGdsb2JhbCBhZGRyZXNzLiAgRFNMLCBDYWJsZSwgYW5kIGNlbGx1
bGFyIHdpcmVsZXNzIHN1cHBvcnRpbmcgSUFfUEQgd2lsbCBiZSBjb3ZlcmVkIGJ5IHRoZSBXQU4g
c2V0dGluZyBkZXNjcmliZWQgYWJvdmUuDQoNCg0KSGVtYW50DQoNCg==

------_=_NextPart_001_01CCAEB8.889DAB70
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z
b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206
b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm
aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw
QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4
MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj
Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw
dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl
YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u
ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm
aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2
YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z
OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9
Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB
VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z
Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n
cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y
MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz
ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h
cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu
dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht
bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu
dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg
eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz
LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9
Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0
cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0
dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw
Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw
Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i
aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3
Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv
IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp
Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp
Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0
cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v
c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s
bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4
bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw
Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv
aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j
b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl
bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6
cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl
TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No
YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46
c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3
LnczLm9yZy9UUi9SRUMtaHRtbDQwIj48aGVhZD48bWV0YSBodHRwLWVxdWl2PUNvbnRlbnQtVHlw
ZSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjxtZXRhIG5hbWU9R2VuZXJhdG9y
IGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj48c3R5bGU+PCEt
LQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2Ft
YnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UN
Cgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9
DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAz
IDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9z
ZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1z
b05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFy
Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNh
bGlicmkiLCJzYW5zLXNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z
dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp
bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w
cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9
DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21z
by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsN
CgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuNXB0
Ow0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5
bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv
LXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4u
RW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt
aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVm
YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N
CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g
MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u
MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0
cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b
aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt
YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k
aWZdLS0+PC9oZWFkPjxib2R5IGxhbmc9RU4tVVMgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT48ZGl2
IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9y
OiMxRjQ5N0QnPlRoZSBzcGVjaWZpYyBvcmdzIGNyZWF0ZSByZXF1aXJlbWVudHMgdGhhdCBhcmUg
dXNlZCBieSB0aGVpciBjb25zdGl0dWVudHMgd2hlbiBwcm9jdXJpbmcgZGV2aWNlcyB0aGF0IGFy
ZSBzcGVjaWZpY2FsbHkgaW50ZW5kZWQgdG8gb3BlcmF0ZSBvbiB0aGUgY29uc3RpdHVlbnRz4oCZ
IG5ldHdvcmtzLiBUaGVzZSBhcmUgb2Z0ZW4gbWFuYWdlZCBkZXZpY2VzLiBUaGV5IGFyZSBub3Qg
V0FOLWNsdWVsZXNzIGRldmljZXMuIFRoZXkgZXhpc3QsIHRoZSBzcGVjcyBleGlzdCwgYW5kIHRo
aXMgaXMganVzdCB0aGUgd2F5IHRoaW5ncyBhcmUuIEnigJltIG5vdCBhd2FyZSBvZiBhbnl0aGlu
ZyBhbnlib2R5IGNhbiBkbyB0byBjaGFuZ2UgdGhpcy4gTXkgcmVhc29uIGZvciBzdGF0aW5nIHRo
aXMgZmFjdCB3YXMgdG8gc2ltcGx5IG1ha2Ugc3VyZSB3ZSBhbGwgdW5kZXJzdG9vZCB0aGlzIGZh
Y3QuIEl0IGlzIHdoYXQgaXQgaXMuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v
cm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+SGVtYW50
LCBJIGRvbuKAmXQgcXVpdGUgdW5kZXJzdGFuZCB3aGF0IHlvdeKAmXJlIHByb3Bvc2luZywgYnV0
IGl0IG1ha2VzIG1lIHVuY29tZm9ydGFibGUuIFRoZSBXQU4tY2x1ZWxlc3MgZGV2aWNlIG11c3Qg
bm90IHJlcXVpcmUgdXNlciBjb25maWd1cmF0aW9uIHdoZW4gY29ubmVjdGVkIHRvIGEgcGFydGlj
dWxhciBXQU4sIGlmIGF0IGFsbCBwb3NzaWJsZS4gVGhhdCB3YXMgYSB2ZXJ5IGltcG9ydGFudCBk
ZXNpZ24gcHJpbmNpcGxlLiBUaGUgNjIwNCByZXF1aXJlbWVudHMgd2VyZSBpbnRlbmRlZCB0byBh
bGxvdyB0aGUgV0FOIGludGVyZmFjZSB0byBhdXRvbWF0aWNhbGx5IGVzdGFibGlzaCBjb25uZWN0
aXZpdHksIG5vIG1hdHRlciB3aGljaCBXQU4gaXQgY29ubmVjdGVkIHRvICh0byB0aGUgZ3JlYXRl
c3QgZXh0ZW50IHBvc3NpYmxlKS4gSeKAmW0gb2sgaWYgc29tZSBvZiB0aGUgNjIwNGJpcyByZXF1
aXJlbWVudHMgcHJvdmlkZSBleGNlcHRpb25zIGZvciBkZXZpY2VzIHRoYXQgYXJlIGNvbmZpZ3Vy
ZWQgY2VydGFpbiB3YXlzLiBUaGlzIGFja25vd2xlZGdlcyB0aGF0IGl0IGlzIHBvc3NpYmxlIGZv
ciBzdWNoIHByZS1jb25maWd1cmVkIGRldmljZXMgdG8gZXhpc3QuIEJ1dCBleHBsaWNpdGx5IGRl
c2NyaWJpbmcgYW5kIGNhbGxpbmcgb3V0IHRoZXNlIGNvbmZpZ3VyYXRpb24gcG9zc2liaWxpdGll
cyBpbiB0aGVpciBvd24gc2VjdGlvbiBpcyBzb21ldGhpbmcgSeKAmW0gbm90IGluIGZhdm9yIG9m
LiBUaGUgY29uZmlndXJhdGlvbiBleGNsdXNpb25zIGFyZSB0aGVyZSB0byBhbGxvdyBvdGhlciBv
cmdzIHdpZ2dsZS1yb29tIHdoZW4gd3JpdGluZyB0aGVpciBvd24gc3BlY3MuIFRoZXkgYXJlbuKA
mXQgc29tZXRoaW5nIHRoYXQgV0FOLWNsdWVsZXNzIGRldmljZXMgc2hvdWxkIG5lZWQgdG8ga25v
dyBhbnl0aGluZyBhYm91dC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs
PjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5CYXJiYXJhPG86cD48L286cD48L3NwYW4+PC9w
PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wPjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv
bGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCc+PGRpdj48ZGl2IHN0eWxl
PSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw
dCAwaW4gMGluIDBpbic+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+
PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJz
YW5zLXNlcmlmIic+IEhlbWFudCBTaW5naCAoc2hlbWFudCkgW21haWx0bzpzaGVtYW50QGNpc2Nv
LmNvbV0gPGJyPjxiPlNlbnQ6PC9iPiBNb25kYXksIE5vdmVtYmVyIDI4LCAyMDExIDExOjAxIFBN
PGJyPjxiPlRvOjwvYj4gSGFucyBMaXU7IFNUQVJLLCBCQVJCQVJBIEg8YnI+PGI+Q2M6PC9iPiBW
w616ZGFsIEFsZcWhOyBPbGUgVHJvYW47IGpvdW5pIGtvcmhvbmVuOyB2Nm9wc0BpZXRmLm9yZzxi
cj48Yj5TdWJqZWN0OjwvYj4gUkU6IFt2Nm9wc10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi12Nm9w
cy02MjA0YmlzLTAzLnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFz
cz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0Pjxz
cGFuIHN0eWxlPSdmb250LWZhbWlseToiQ291cmllciBOZXciJz5IYW5zLDxvOnA+PC9vOnA+PC9z
cGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xh
c3M9TXNvUGxhaW5UZXh0Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPkZyb206IEhhbnMg
TGl1IFttYWlsdG86aGFuc2xpdUBnbWFpbC5jb21dIDxicj5TZW50OiBNb25kYXksIE5vdmVtYmVy
IDI4LCAyMDExIDk6MjkgUE08YnI+VG86IFNUQVJLLCBCQVJCQVJBIEg8YnI+Q2M6IFbDrXpkYWwg
QWxlxaE7IEhlbWFudCBTaW5naCAoc2hlbWFudCk7IE9sZSBUcm9hbjsgam91bmkga29yaG9uZW47
IHY2b3BzQGlldGYub3JnPGJyPlN1YmplY3Q6IFJlOiBbdjZvcHNdIEktRCBBY3Rpb246IGRyYWZ0
LWlldGYtdjZvcHMtNjIwNGJpcy0wMy50eHQ8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFp
blRleHQ+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gc3R5bGU9J2ZvbnQt
ZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsmZ3Q7IEJCRiwgQ2FibGVMYWJzLCAzR1BQLCBldCBh
bCBhcmUgMTAwJSBmcmVlIHRvIHNwZWNpZnkgd2hhdGV2ZXIgdGhleSB3YW50IGZvciBkZXZpY2Vz
IHRoYXQgdGhleSBhcmUgYWJsZSB0byBzcGVjaWZ5LiBJZiB0aGV5ICZndDsmZ3Q7d2FudCB0byBz
dHJheSBmcm9tIDYyMDQsIHRoZXkgYXJlIGZyZWUgdG8gZG8gc28uPG86cD48L286cD48L3NwYW4+
PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNvdXJp
ZXIgTmV3Iic+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4
dD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0O1RoYXQgd2lsbCBi
ZSBhIGhlYWRhY2hlIHRvIHVzIHNtYWxsIG1hbnVmYWN0dXJlcy48bzpwPjwvbzpwPjwvc3Bhbj48
L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1z
b1BsYWluVGV4dD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjpi
bGFjayc+V291bGQgeW91ciBoZWFkYWNoZSBiZSByZWR1Y2VkIGlmIHJmYzYyMDRiaXMgYWRkZWQg
YSBuZXcgc2VjdGlvbiBmb3IgQ29uY2VwdHVhbCBDb25maWd1cmF0aW9uIFZhcmlhYmxlcz8mbmJz
cDsgT25lIGNvbmNlcHR1YWwgY29uZmlndXJhdGlvbiB2YXJpYWJsZSB3b3VsZCBiZSBhIFdBTiBz
ZXR0aW5nIGZvciB0aGUgV0FOIHRvIGJlIChhKSBVbm51bWJlcmVkICh3aXRoIG9ubHkgYW4gSVB2
NiBsaW5rLWxvY2FsIGFkZHJlc3MpIGFuZCBESENQdjYgYWNxdWlyZXMgb25seSBJQV9QRCwgKGIp
IE51bWJlcmVkIHdoZXJlIHRoZSBXQU4gYWNxdWlyZXMgYSBnbG9iYWwgSVB2NiBhZGRyZXNzIGZy
b20gREhDUHY2IElBX05BIElBX2FkZHJlc3MgYW5kIGEgcHJlZml4IHZpYSBJQV9QRCwgYW5kIHBl
cmhhcHMgYW4gb3B0aW9uIChjKSB3aGVyZSB0aGUgV0FOIGlzIGFzc2lnbmVkIGEgc3RhdGljIElQ
djYgZ2xvYmFsIGFkZHJlc3MuJm5ic3A7IERTTCwgQ2FibGUsIGFuZCBjZWxsdWxhciB3aXJlbGVz
cyBzdXBwb3J0aW5nIElBX1BEIHdpbGwgYmUgY292ZXJlZCBieSB0aGUgV0FOIHNldHRpbmcgZGVz
Y3JpYmVkIGFib3ZlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+
PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6YmxhY2snPjxicj5I
ZW1hbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PC9ib2R5PjwvaHRtbD4=

------_=_NextPart_001_01CCAEB8.889DAB70--

From sarikaya2012@gmail.com  Tue Nov 29 09:07:23 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC0511F0C45 for ; Tue, 29 Nov 2011 09:07:23 -0800 (PST)
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 Rc+Rbfdxnrqh for ; Tue, 29 Nov 2011 09:07:23 -0800 (PST)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id DDDA31F0C60 for ; Tue, 29 Nov 2011 09:07:22 -0800 (PST)
Received: by ywm13 with SMTP id 13so5600116ywm.31 for ; Tue, 29 Nov 2011 09:07:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=o7EHdEtisQjgJhT8KbqmZoqKrkOM/9B4X3yZ468GGdA=; b=tk8Cx+KhCMT6wWPIF7dNriKwsocPLLBECP+YabNxKt/Hxyv5kengO73j8ePEa4Jm0W fFJ7sURKPNYKeIvbk196Qa98FMHNwtF6JcNVXuYgN7VhcKogOdT1Xj1K33KsZ9OqD9DE UoKHXw4uOOvW8A5/2vovZaS0FJUFf550wHT8s=
MIME-Version: 1.0
Received: by 10.236.181.225 with SMTP id l61mr71354916yhm.131.1322586442259; Tue, 29 Nov 2011 09:07:22 -0800 (PST)
Received: by 10.236.191.228 with HTTP; Tue, 29 Nov 2011 09:07:21 -0800 (PST)
In-Reply-To: 
References:   <5B6B2B64C9FE2A489045EEEADDAFF2C3036CD90A@XMB-RCD-109.cisco.com> 
Date: Tue, 29 Nov 2011 11:07:21 -0600
Message-ID: 
From: Behcet Sarikaya 
To: Ole Troan 
Content-Type: multipart/alternative; boundary=20cf305639ab135cc204b2e2a706
Cc: Alexandre Cassen , v6ops@ietf.org
Subject: Re: [v6ops] 6rd Sunsetting
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, 29 Nov 2011 17:07:24 -0000

--20cf305639ab135cc204b2e2a706
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi Ole,

What Hemant is saying, i.e. packets always go to BNG from CE is correct.
CE to CE routing idea makes sense in case BR or CGN are located far from
BNG.

Regards,

Behcet

On Tue, Nov 29, 2011 at 5:07 AM, Ole Troan  wrote:

> Hemant,
>
> I don't want to be blunt, but you are spreading misinformation.
>
> a router forwarding packets does not use RFC3484. that's for hosts.
> a router in forwarding tunnelled packets (like the CMTS or the BNG in you=
r
> example) does _NOT_ process the payload packet in any way. that's kinda t=
he
> point with tunnels.
>
> cheers,
> Ole
>
> > >I think we are assuming that the CE to CE path would be "shortest" if
> > >using 6RD directly on both endpoints (where one is now Native v6/6RD a=
nd
> > >the other only 6RD). In my mind, "shortest" path would also include
> > >performance and overall delay to get form one host to the other (home
> > >network host to home network host).
> >
> > Good use case.  Note the rule that Mark specified, as I said, is alread=
y
> part of RFC 3484, section 6, and Rule 7.  Thus a CPE is entitled to use t=
he
> rule 7 and rfc6204bis can still be silent about this rule because the rul=
e
> is already specified in RFC 3484.  So here is a potential solution for th=
e
> problem above.  If a mistake is made, we need the network path to issue a=
n
> ICMPv6 Destination Unreachable back to the source.  The network path
> constitutes a direct CPE to CPE path or a path through the BR.  Thus even
> when the destination CPE has disabled 6rd to operate in native IPv6 mode,
> or the BR has disabled 6rd, each device still maintains processing for
> protocol 41.  If protocol 41 processing is maintained then the BR or the
> CPE in native IPv6 mode issues an ICMPv4/ICMPv6 Destination Unreachable.
>  Barbara can confirm being a DSL person, but I think direct CE to CE
> communications in 6rd and DSL is not really direct.  The data flows thru =
a
> BNG or some router.  At least in a cable network the traffic between two
> CPEs has to flow through the CMTS even if the CPEs span the same IPv6 lin=
k.
>  Thus the BNG processes protocol 41 as well and issues ICMPv4/ICMPv6
> Destination Unreachable to the source CPE.  This solution is agnostic to
> whether the receiving CPE changed mode to a different native IPv6 prefix =
or
> same IPv6 prefix as the 6rd prefix.  Likewise the solution is also agnost=
ic
> to where the BR and the BNG are co-located or separate =96 appropriate ro=
utes
> have to be injected in the BR and the BNG when they are separate.
> >
> > Thanks and regards,
> >
> > Hemant
> >
> >
> > _______________________________________________
> > 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
>

--20cf305639ab135cc204b2e2a706
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi Ole,

What Hemant is saying, i.e. packets always go to BNG from CE=
 is correct.
CE to CE routing idea makes sense in case BR or CGN are loc=
ated far from BNG.

Regards,

Behcet


On Tue, Nov 29, 2011 at 5:07 AM, Ole Troan <otroan@employees.org> wrote:

Hemant,



I don't want to be blunt, but you are spreading misinformation.



a router forwarding packets does not use RFC3484. that's for hosts.

a router in forwarding tunnelled packets (like the CMTS or the BNG in your =
example) does _NOT_ process the payload packet in any way. that's kinda=
 the point with tunnels.



cheers,

Ole




> >I think we are assuming that the CE to CE path would be "shor=
test" if

> >using 6RD directly on both endpoints (where one is now Native v6/6=
RD and

> >the other only 6RD). In my mind, "shortest" path would a=
lso include

> >performance and overall delay to get form one host to the other (h=
ome

> >network host to home network host).

>

> Good use case. =A0Note the rule that Mark specified, as I said, is alr=
eady part of RFC 3484, section 6, and Rule 7. =A0Thus a CPE is entitled to =
use the rule 7 and rfc6204bis can still be silent about this rule because t=
he rule is already specified in RFC 3484. =A0So here is a potential solutio=
n for the problem above. =A0If a mistake is made, we need the network path =
to issue an ICMPv6 Destination Unreachable back to the source. =A0The netwo=
rk path constitutes a direct CPE to CPE path or a path through the BR. =A0T=
hus even when the destination CPE has disabled 6rd to operate in native IPv=
6 mode, or the BR has disabled 6rd, each device still maintains processing =
for protocol 41. =A0If protocol 41 processing is maintained then the BR or =
the CPE in native IPv6 mode issues an ICMPv4/ICMPv6 Destination Unreachable=
. =A0Barbara can confirm being a DSL person, but I think direct CE to CE co=
mmunications in 6rd and DSL is not really direct. =A0The data flows thru a =
BNG or some router. =A0At least in a cable network the traffic between two =
CPEs has to flow through the CMTS even if the CPEs span the same IPv6 link.=
 =A0Thus the BNG processes protocol 41 as well and issues ICMPv4/ICMPv6 Des=
tination Unreachable to the source CPE. =A0This solution is agnostic to whe=
ther the receiving CPE changed mode to a different native IPv6 prefix or sa=
me IPv6 prefix as the 6rd prefix. =A0Likewise the solution is also agnostic=
 to where the BR and the BNG are co-located or separate =96 appropriate rou=
tes have to be injected in the BR and the BNG when they are separate.


>

> Thanks and regards,

>

> Hemant

>

>


> ________________________=
_______________________

> v6ops mailing list

> v6ops@ietf.org

> https://www.ietf.org/mailman/listinfo/v6ops



_______________________________________________

v6ops mailing list

v6ops@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/v6ops





--20cf305639ab135cc204b2e2a706--

From ichiroumakino@gmail.com  Tue Nov 29 09:11:04 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3497D21F8C3C for ; Tue, 29 Nov 2011 09:11:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.149
X-Spam-Level: 
X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ev421xlQ4Lxt for ; Tue, 29 Nov 2011 09:11:02 -0800 (PST)
Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5F44721F86EC for ; Tue, 29 Nov 2011 09:11:02 -0800 (PST)
Received: by eear51 with SMTP id r51so1361396eea.31 for ; Tue, 29 Nov 2011 09:10:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=jhJtU/Idly5gHTOwsUN+1NjGpM5s8usrDTENJb9Lt30=; b=LM4UQQBi8A/oilnQWwi44coCKUAAvxfCScvYoCYqDxt3jGpbmb6pLbBHrazFn6XTC+ C7gCJBzzxSXSxiXWLy8Uq1S4T1bunktX7QpZNvBGhwrPiK22crU0pbtPJPG8pqvGIi1N x9Zt7YHp2oVnXszwg0q2INcl0r7/TseNk8ghc=
Received: by 10.227.60.12 with SMTP id n12mr2494251wbh.13.1322586657245; Tue, 29 Nov 2011 09:10:57 -0800 (PST)
Received: from [10.147.12.109] (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id f18sm15809990wiv.14.2011.11.29.09.10.53 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 29 Nov 2011 09:10:53 -0800 (PST)
Sender: Ole Troan 
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=windows-1252
From: Ole Troan 
In-Reply-To: 
Date: Tue, 29 Nov 2011 18:10:52 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <2C39C0C8-7BD8-46E4-AC87-B81B256753F7@employees.org>
References:   <5B6B2B64C9FE2A489045EEEADDAFF2C3036CD90A@XMB-RCD-109.cisco.com>  
To: sarikaya@ieee.org
X-Mailer: Apple Mail (2.1084)
Cc: Alexandre Cassen , v6ops@ietf.org
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 29 Nov 2011 17:11:04 -0000

Bechet,

> What Hemant is saying, i.e. packets always go to BNG from CE is =
correct.

not quite. he says the BNG does protocol 41 processing.
from the BNG perspective a 6rd packet is just another IPv4 packet. as =
for all other routers between the tunnel end points.

> CE to CE routing idea makes sense in case BR or CGN are located far =
from BNG.

we're not discussing the "idea". 6rd is a mesh link and CE to CE is an =
intrinsic property of 6rd.

cheers,
Ole



>=20
> Regards,
>=20
> Behcet
>=20
> On Tue, Nov 29, 2011 at 5:07 AM, Ole Troan  =
wrote:
> Hemant,
>=20
> I don't want to be blunt, but you are spreading misinformation.
>=20
> a router forwarding packets does not use RFC3484. that's for hosts.
> a router in forwarding tunnelled packets (like the CMTS or the BNG in =
your example) does _NOT_ process the payload packet in any way. that's =
kinda the point with tunnels.
>=20
> cheers,
> Ole
>=20
> > >I think we are assuming that the CE to CE path would be "shortest" =
if
> > >using 6RD directly on both endpoints (where one is now Native =
v6/6RD and
> > >the other only 6RD). In my mind, "shortest" path would also include
> > >performance and overall delay to get form one host to the other =
(home
> > >network host to home network host).
> >
> > Good use case.  Note the rule that Mark specified, as I said, is =
already part of RFC 3484, section 6, and Rule 7.  Thus a CPE is entitled =
to use the rule 7 and rfc6204bis can still be silent about this rule =
because the rule is already specified in RFC 3484.  So here is a =
potential solution for the problem above.  If a mistake is made, we need =
the network path to issue an ICMPv6 Destination Unreachable back to the =
source.  The network path constitutes a direct CPE to CPE path or a path =
through the BR.  Thus even when the destination CPE has disabled 6rd to =
operate in native IPv6 mode, or the BR has disabled 6rd, each device =
still maintains processing for protocol 41.  If protocol 41 processing =
is maintained then the BR or the CPE in native IPv6 mode issues an =
ICMPv4/ICMPv6 Destination Unreachable.  Barbara can confirm being a DSL =
person, but I think direct CE to CE communications in 6rd and DSL is not =
really direct.  The data flows thru a BNG or some router.  At least in a =
cable network the traffic between two CPEs has to flow through the CMTS =
even if the CPEs span the same IPv6 link.  Thus the BNG processes =
protocol 41 as well and issues ICMPv4/ICMPv6 Destination Unreachable to =
the source CPE.  This solution is agnostic to whether the receiving CPE =
changed mode to a different native IPv6 prefix or same IPv6 prefix as =
the 6rd prefix.  Likewise the solution is also agnostic to where the BR =
and the BNG are co-located or separate =96 appropriate routes have to be =
injected in the BR and the BNG when they are separate.
> >
> > Thanks and regards,
> >
> > Hemant
> >
> >
> > _______________________________________________
> > 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 shemant@cisco.com  Tue Nov 29 09:54:48 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71E8E1F0C62 for ; Tue, 29 Nov 2011 09:54:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.278
X-Spam-Level: 
X-Spam-Status: No, score=-6.278 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 ngfkBfcv81ug for ; Tue, 29 Nov 2011 09:54:44 -0800 (PST)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 8611F1F0C36 for ; Tue, 29 Nov 2011 09:54:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=16846; q=dns/txt; s=iport; t=1322589284; x=1323798884; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=kgaLQg3LE48fuqvwX605hqXx5pW8EmKXo3o4voNCSqE=; b=A3Ybg3V/X1ZtGWyOG1Ezj9YwxOoYplHEHuUY9aNad5qmHm00pCQQE/ws FKf+S2kxLrW4KUh2A9Vj5mGMFFj7bKa5po9P3gg22ZXa5zZqPQ0gBwydf A0Fpkzqxxd3ODhlhrUuBn9bMFcI2+mbvMDVahzLNVWWDO0vUlolPE9Iap g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApwAAF8b1U6tJXG8/2dsb2JhbABDgk2YFZAYgQWBcgEBAQMBAQEBDwEJEQM+CwUHBAIBCA4DBAEBCwYXAQYBIAYfCQgBAQQBEggTB4djCJh5AZ5EBIo7YwSIJ5cJh1Q
X-IronPort-AV: E=Sophos;i="4.69,592,1315180800"; d="scan'208,217";a="39745206"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-8.cisco.com with ESMTP; 29 Nov 2011 17:54:44 +0000
Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id pATHshnD025240;  Tue, 29 Nov 2011 17:54:43 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 29 Nov 2011 11:54:43 -0600
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCAEBF.F9664F0F"
Date: Tue, 29 Nov 2011 11:54:42 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3036CDAE4@XMB-RCD-109.cisco.com>
In-Reply-To: <2C39C0C8-7BD8-46E4-AC87-B81B256753F7@employees.org>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] 6rd Sunsetting
Thread-Index: Acyuud1EBndumgTcQ9W+GyG9hcRApwABcMfQ
References:   <5B6B2B64C9FE2A489045EEEADDAFF2C3036CD90A@XMB-RCD-109.cisco.com>   <2C39C0C8-7BD8-46E4-AC87-B81B256753F7@employees.org>
From: "Hemant Singh (shemant)" 
To: "Ole Troan" , 
X-OriginalArrivalTime: 29 Nov 2011 17:54:43.0773 (UTC) FILETIME=[F9ACA6D0:01CCAEBF]
Cc: Alexandre Cassen , v6ops@ietf.org
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 29 Nov 2011 17:54:48 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CCAEBF.F9664F0F
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Should we file an errata against RFC5969 when it says=20

=20

[The 6rd link is modeled as an NBMA link similar to other automatic

IPv6 in IPv4 tunneling mechanisms like [RFC5214], with all 6rd CEs

and BRs defined as off-link neighbors from one other.]

=20

Off-link means a node sends traffic to the default router(s) rather than
communicating directly with another client on the link.  With text
above, all 6rd CEs are off-link to each other, so how is a CE
communicating directly to another CE as Barbara has also alluded to?

=20

Hemant

=20

-----Original Message-----
From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of Ole Troan
Sent: Tuesday, November 29, 2011 12:11 PM
To: sarikaya@ieee.org
Cc: Hemant Singh (shemant); Alexandre Cassen; v6ops@ietf.org
Subject: Re: [v6ops] 6rd Sunsetting

=20

Bechet,

=20

> What Hemant is saying, i.e. packets always go to BNG from CE is
correct.

=20

not quite. he says the BNG does protocol 41 processing.

from the BNG perspective a 6rd packet is just another IPv4 packet. as
for all other routers between the tunnel end points.

=20

> CE to CE routing idea makes sense in case BR or CGN are located far
from BNG.

=20

we're not discussing the "idea". 6rd is a mesh link and CE to CE is an
intrinsic property of 6rd.

=20

cheers,

Ole

=20

=20

=20

>=20

> Regards,

>=20

> Behcet

>=20

> On Tue, Nov 29, 2011 at 5:07 AM, Ole Troan 
wrote:

> Hemant,

>=20

> I don't want to be blunt, but you are spreading misinformation.

>=20

> a router forwarding packets does not use RFC3484. that's for hosts.

> a router in forwarding tunnelled packets (like the CMTS or the BNG in
your example) does _NOT_ process the payload packet in any way. that's
kinda the point with tunnels.

>=20

> cheers,

> Ole

>=20

> > >I think we are assuming that the CE to CE path would be "shortest"
if

> > >using 6RD directly on both endpoints (where one is now Native
v6/6RD and

> > >the other only 6RD). In my mind, "shortest" path would also include

> > >performance and overall delay to get form one host to the other
(home

> > >network host to home network host).

> >

> > Good use case.  Note the rule that Mark specified, as I said, is
already part of RFC 3484, section 6, and Rule 7.  Thus a CPE is entitled
to use the rule 7 and rfc6204bis can still be silent about this rule
because the rule is already specified in RFC 3484.  So here is a
potential solution for the problem above.  If a mistake is made, we need
the network path to issue an ICMPv6 Destination Unreachable back to the
source.  The network path constitutes a direct CPE to CPE path or a path
through the BR.  Thus even when the destination CPE has disabled 6rd to
operate in native IPv6 mode, or the BR has disabled 6rd, each device
still maintains processing for protocol 41.  If protocol 41 processing
is maintained then the BR or the CPE in native IPv6 mode issues an
ICMPv4/ICMPv6 Destination Unreachable.  Barbara can confirm being a DSL
person, but I think direct CE to CE communications in 6rd and DSL is not
really direct.  The data flows thru a BNG or some router.  At least in a
cable network the traffic between two CPEs has to flow through the CMTS
even if the CPEs span the same IPv6 link.  Thus the BNG processes
protocol 41 as well and issues ICMPv4/ICMPv6 Destination Unreachable to
the source CPE.  This solution is agnostic to whether the receiving CPE
changed mode to a different native IPv6 prefix or same IPv6 prefix as
the 6rd prefix.  Likewise the solution is also agnostic to where the BR
and the BNG are co-located or separate - appropriate routes have to be
injected in the BR and the BNG when they are separate.

> >

> > Thanks and regards,

> >

> > Hemant

> >

> >

> > _______________________________________________

> > v6ops mailing list

> > v6ops@ietf.org

> > https://www.ietf.org/mailman/listinfo/v6ops

>=20

> _______________________________________________

> v6ops mailing list

> v6ops@ietf.org

> https://www.ietf.org/mailman/listinfo/v6ops

>=20

=20


------_=_NextPart_001_01CCAEBF.F9664F0F
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Should we file an errata against =
RFC5969 when it says 
 
[The 6rd =
link is modeled as an NBMA link similar to other =
automatic
 IPv6 in IPv4 tunneling mechanisms =
like [RFC5214], with all 6rd CEs
 and BRs =
defined as off-link neighbors from one other.]
 
Off-link means a node sends traffic to the default =
router(s) rather than communicating directly with another client on the =
link.  With text above, all 6rd CEs are off-link to each other, so =
how is a CE communicating directly to another CE as Barbara has also =
alluded to?
 
Hemant
 
-----Original Message-----
From: Ole Troan =
[mailto:ichiroumakino@gmail.com] On Behalf Of Ole Troan
Sent: =
Tuesday, November 29, 2011 12:11 PM
To: sarikaya@ieee.org
Cc: =
Hemant Singh (shemant); Alexandre Cassen; v6ops@ietf.org
Subject: Re: =
[v6ops] 6rd Sunsetting
 
Bechet,
 
> =
What Hemant is saying, i.e. packets always go to BNG from CE is =
correct.
 
not quite. he says the BNG does protocol 41 =
processing.
from the BNG =
perspective a 6rd packet is just another IPv4 packet. as for all other =
routers between the tunnel end points.
 
> =
CE to CE routing idea makes sense in case BR or CGN are located far from =
BNG.
 
we're not discussing the "idea". 6rd is a =
mesh link and CE to CE is an intrinsic property of 6rd.
 
cheers,
Ole
 
 
 
> =

> Regards,
> 
> =
Behcet
> 
> On Tue, Nov 29, 2011 at 5:07 AM, Ole Troan =
<otroan@employees.org> wrote:
> Hemant,
> 
> I =
don't want to be blunt, but you are spreading =
misinformation.
> =

> a router forwarding packets =
does not use RFC3484. that's for hosts.
> a router in forwarding tunnelled packets (like =
the CMTS or the BNG in your example) does _NOT_ process the payload =
packet in any way. that's kinda the point with tunnels.
> 
> =
cheers,
> Ole
> 
> =
> >I think we are assuming that the CE to CE path would be =
"shortest" if
> > =
>using 6RD directly on both endpoints (where one is now Native v6/6RD =
and
> > >the other only =
6RD). In my mind, "shortest" path would also =
include
> > >performance =
and overall delay to get form one host to the other =
(home
> > >network host =
to home network host).
> =
>
> > Good use =
case.  Note the rule that Mark specified, as I said, is already =
part of RFC 3484, section 6, and Rule 7.  Thus a CPE is entitled to =
use the rule 7 and rfc6204bis can still be silent about this rule =
because the rule is already specified in RFC 3484.  So here is a =
potential solution for the problem above.  If a mistake is made, we =
need the network path to issue an ICMPv6 Destination Unreachable back to =
the source.  The network path constitutes a direct CPE to CPE path =
or a path through the BR.  Thus even when the destination CPE has =
disabled 6rd to operate in native IPv6 mode, or the BR has disabled 6rd, =
each device still maintains processing for protocol 41.  If =
protocol 41 processing is maintained then the BR or the CPE in native =
IPv6 mode issues an ICMPv4/ICMPv6 Destination Unreachable.  Barbara =
can confirm being a DSL person, but I think direct CE to CE =
communications in 6rd and DSL is not really direct.  The data flows =
thru a BNG or some router.  At least in a cable network the traffic =
between two CPEs has to flow through the CMTS even if the CPEs span the =
same IPv6 link.  Thus the BNG processes protocol 41 as well and =
issues ICMPv4/ICMPv6 Destination Unreachable to the source CPE.  =
This solution is agnostic to whether the receiving CPE changed mode to a =
different native IPv6 prefix or same IPv6 prefix as the 6rd =
prefix.  Likewise the solution is also agnostic to where the BR and =
the BNG are co-located or separate – appropriate routes have to be =
injected in the BR and the BNG when they are separate.
> >
> > Thanks and regards,
> >
> > Hemant
> >
> >
> > =
_______________________________________________
> > 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
> 
 

------_=_NextPart_001_01CCAEBF.F9664F0F--

From wbeebee@cisco.com  Tue Nov 29 10:08:28 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22F0021F87C5 for ; Tue, 29 Nov 2011 10:08:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.532
X-Spam-Level: 
X-Spam-Status: No, score=-4.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZHeaz5QzggM for ; Tue, 29 Nov 2011 10:08:27 -0800 (PST)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 7E8A421F8B4F for ; Tue, 29 Nov 2011 10:08:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wbeebee@cisco.com; l=428; q=dns/txt; s=iport; t=1322590107; x=1323799707; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=WV4SSF6E9TarR/yOmXzpYI5epi/Ngrn/3qhpCFQms9E=; b=l67oVaYpGcyDSNPlXXLmFtX8jBdKPKki7jbDZ1JVHS3/K6zdsuLj2JSU ByXfjmGntEqwtW2U80mCciadWOB9UGirj4p5vnzu7+Zx94b8gwAC5LWWt C/W+KMLWhnpcklGl4hqKDjclc5fUivB87EmrZ49p95l6NLWvmeGWJS11f I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AikHAPAe1U6tJXG+/2dsb2JhbABDiUuhLgKBBYFyAQEBAwESAScCATwFDQEIgR0BAQQOJ4djmHwBnkiICYMVBIgnjC2NfIQz
X-IronPort-AV: E=Sophos;i="4.69,592,1315180800"; d="scan'208";a="39749772"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 29 Nov 2011 18:08:27 +0000
Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id pATI88hm029226;  Tue, 29 Nov 2011 18:08:27 GMT
Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 29 Nov 2011 12:08:11 -0600
Received: from 161.44.175.128 ([161.44.175.128]) by XMB-RCD-201.cisco.com ([72.163.62.208]) with Microsoft Exchange Server HTTP-DAV ;  Tue, 29 Nov 2011 18:08:10 +0000
User-Agent: Microsoft-Entourage/12.31.0.110725
Date: Tue, 29 Nov 2011 13:08:07 -0500
From: Wes Beebee 
To: 
Message-ID: 
Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
Thread-Index: AcyuwdhvzoX23EUJXk6aRxQgcbjXyQ==
In-Reply-To: 
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 29 Nov 2011 18:08:11.0663 (UTC) FILETIME=[DB36E1F0:01CCAEC1]
Cc: v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-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: Tue, 29 Nov 2011 18:08:28 -0000

> o if CE router sends both IA_NA+IA_PD simultaneously and either receives
>  NoAddrsAvail in Advertise/Reply(?) for IA_NA or no IA_NA at all, what
>  happens. RFC3315 errata 2471 (and RFC3633 errata 2469) should cover this.
>  Maybe s short note along the lines of errata texts in WPD-7 would suffice?
>
>And then a reference to pd-exclude (I guess this was already accepted.. once it
>is out as an RFC).

+1

- Wes


From ichiroumakino@gmail.com  Tue Nov 29 10:29:23 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 525C711E80AC for ; Tue, 29 Nov 2011 10:29:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.119
X-Spam-Level: 
X-Spam-Status: No, score=-3.119 tagged_above=-999 required=5 tests=[AWL=-0.120, 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 r+oaHoGicLNx for ; Tue, 29 Nov 2011 10:29:22 -0800 (PST)
Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2120321F8B47 for ; Tue, 29 Nov 2011 10:29:18 -0800 (PST)
Received: by eabm6 with SMTP id m6so3917755eab.31 for ; Tue, 29 Nov 2011 10:29:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=zqhCVUjXograB1vcwoERQbso0H24Zn94sQXk8iUe+G8=; b=dzIsqPumwV+UdoZQLIHEjeKMimqQUtTakDxjJut2VM3i63ndf9bxHei7BxE11V3eQs ewMeXeWAt9Xq58QKf/wdD1vTNaqoNmkqrvNOPaHWSgPwvGtrsJ0KLDwPRFsVqEDqZKRa 80Nf99LhbzxtLw2rd0RZ6GbpLDUf+1sZoBbUY=
Received: by 10.213.19.136 with SMTP id a8mr3749150ebb.128.1322591357992; Tue, 29 Nov 2011 10:29:17 -0800 (PST)
Received: from dhcp-10-61-106-199.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id o4sm107895758eeb.0.2011.11.29.10.29.16 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 29 Nov 2011 10:29:17 -0800 (PST)
Sender: Ole Troan 
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=windows-1252
From: Ole Troan 
In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3036CDAE4@XMB-RCD-109.cisco.com>
Date: Tue, 29 Nov 2011 19:29:14 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:   <5B6B2B64C9FE2A489045EEEADDAFF2C3036CD90A@XMB-RCD-109.cisco.com>   <2C39C0C8-7BD8-46E4-AC87-B81B256753F7@employees.org> <5B6B2B64C9FE2A489045EEEADDAFF2C3036CDAE4@XMB-RCD-109.cisco.com>
To: Hemant Singh (shemant) 
X-Mailer: Apple Mail (2.1084)
Cc: Alexandre Cassen , v6ops@ietf.org
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 29 Nov 2011 18:29:23 -0000

Hemant,

> Should we file an errata against RFC5969 when it says
> =20
> [The 6rd link is modeled as an NBMA link similar to other automatic
> IPv6 in IPv4 tunneling mechanisms like [RFC5214], with all 6rd CEs
> and BRs defined as off-link neighbors from one other.]
> =20
> Off-link means a node sends traffic to the default router(s) rather =
than communicating directly with another client on the link.  With text =
above, all 6rd CEs are off-link to each other, so how is a CE =
communicating directly to another CE as Barbara has also alluded to?

following your logic, the CE wouldn't be able to reach the BR (it's =
default router) either. ;-)
try configuring two routers on a point to point link, with each having =
an address with prefix length 128. run a routing protocol between them. =
they are off link. can they reach each other?

cheers,
Ole

> -----Original Message-----
> From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of Ole =
Troan
> Sent: Tuesday, November 29, 2011 12:11 PM
> To: sarikaya@ieee.org
> Cc: Hemant Singh (shemant); Alexandre Cassen; v6ops@ietf.org
> Subject: Re: [v6ops] 6rd Sunsetting
> =20
> Bechet,
> =20
> > What Hemant is saying, i.e. packets always go to BNG from CE is =
correct.
> =20
> not quite. he says the BNG does protocol 41 processing.
> from the BNG perspective a 6rd packet is just another IPv4 packet. as =
for all other routers between the tunnel end points.
> =20
> > CE to CE routing idea makes sense in case BR or CGN are located far =
from BNG.
> =20
> we're not discussing the "idea". 6rd is a mesh link and CE to CE is an =
intrinsic property of 6rd.
> =20
> cheers,
> Ole
> =20
> =20
> =20
> >
> > Regards,
> >
> > Behcet
> >
> > On Tue, Nov 29, 2011 at 5:07 AM, Ole Troan  =
wrote:
> > Hemant,
> >
> > I don't want to be blunt, but you are spreading misinformation.
> >
> > a router forwarding packets does not use RFC3484. that's for hosts.
> > a router in forwarding tunnelled packets (like the CMTS or the BNG =
in your example) does _NOT_ process the payload packet in any way. =
that's kinda the point with tunnels.
> >
> > cheers,
> > Ole
> >
> > > >I think we are assuming that the CE to CE path would be =
"shortest" if
> > > >using 6RD directly on both endpoints (where one is now Native =
v6/6RD and
> > > >the other only 6RD). In my mind, "shortest" path would also =
include
> > > >performance and overall delay to get form one host to the other =
(home
> > > >network host to home network host).
> > >
> > > Good use case.  Note the rule that Mark specified, as I said, is =
already part of RFC 3484, section 6, and Rule 7.  Thus a CPE is entitled =
to use the rule 7 and rfc6204bis can still be silent about this rule =
because the rule is already specified in RFC 3484.  So here is a =
potential solution for the problem above.  If a mistake is made, we need =
the network path to issue an ICMPv6 Destination Unreachable back to the =
source.  The network path constitutes a direct CPE to CPE path or a path =
through the BR.  Thus even when the destination CPE has disabled 6rd to =
operate in native IPv6 mode, or the BR has disabled 6rd, each device =
still maintains processing for protocol 41.  If protocol 41 processing =
is maintained then the BR or the CPE in native IPv6 mode issues an =
ICMPv4/ICMPv6 Destination Unreachable.  Barbara can confirm being a DSL =
person, but I think direct CE to CE communications in 6rd and DSL is not =
really direct.  The data flows thru a BNG or some router.  At least in a =
cable network the traffic between two CPEs has to flow through the CMTS =
even if the CPEs span the same IPv6 link.  Thus the BNG processes =
protocol 41 as well and issues ICMPv4/ICMPv6 Destination Unreachable to =
the source CPE.  This solution is agnostic to whether the receiving CPE =
changed mode to a different native IPv6 prefix or same IPv6 prefix as =
the 6rd prefix.  Likewise the solution is also agnostic to where the BR =
and the BNG are co-located or separate =96 appropriate routes have to be =
injected in the BR and the BNG when they are separate.
> > >
> > > Thanks and regards,
> > >
> > > Hemant
> > >
> > >
> > > _______________________________________________
> > > v6ops mailing list
> > > v6ops@ietf.org
> > > https://www.ietf.org/mailman/listinfo/v6ops
> >
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.org
> > https://www.ietf.org/mailman/listinfo/v6ops
> >
> =20


From shemant@cisco.com  Tue Nov 29 10:29:48 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59D3C21F8B4D for ; Tue, 29 Nov 2011 10:29:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.561
X-Spam-Level: 
X-Spam-Status: No, score=-6.561 tagged_above=-999 required=5 tests=[AWL=0.037,  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 t39DMo1seRJy for ; Tue, 29 Nov 2011 10:29:47 -0800 (PST)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id A586F21F8B47 for ; Tue, 29 Nov 2011 10:29:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14394; q=dns/txt; s=iport; t=1322591387; x=1323800987; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=b2/CMPOrJhtCdKVSVHCjIcln8Hrk1FH4D+ORzmGSZZI=; b=VSDvV08NgL5lF21zXC2XxSg1KEZs5VuCu1x+omFcNf+UbD/v/wknFuV5 uDKwO0h03FWB6F39SiXTirFq/lcooG2U3oXc16OjIR8DIbYRyyk+Wyk90 qzEu7YWXiJz8VzIeRmg3QyUoD2FfzhF3Y1uWnMt3OOP63wEOG9K+9GoTO 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiQBABEppk6tJV2c/2dsb2JhbACCJYF3jCmNWD54lFWLaIZMhRKBBwSGUI15ilw
X-IronPort-AV: E=Sophos;i="4.69,592,1315180800"; d="scan'208,217";a="37264598"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 29 Nov 2011 18:29:44 +0000
Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id pATITifI019424;  Tue, 29 Nov 2011 18:29:44 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 29 Nov 2011 12:29:43 -0600
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCAEC4.DD3ADAFC"
Date: Tue, 29 Nov 2011 12:29:42 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3036CDB13@XMB-RCD-109.cisco.com>
In-Reply-To: <750BF7861EBBE048B3E648B4BB6E8F4F212EB1F3@crexc50p>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
Thread-Index: AcyuPrdl+CPuCX+USj6zrA590tWMnwAC/abAABrXfVAAA2n1sA==
References: <2963F168-45CB-4042-8238-56DF538B0543@gmail.com><2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org><1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz><5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com><1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz><750BF7861EBBE048B3E648B4BB6E8F4F2106F69E@crexc50p>  <5B6B2B64C9FE2A489045EEEADDAFF2C3036CD910@XMB-RCD-109.cisco.com> <750BF7861EBBE048B3E648B4BB6E8F4F212EB1F3@crexc50p>
From: "Hemant Singh (shemant)" 
To: "STARK, BARBARA H" , "Hans Liu" 
X-OriginalArrivalTime: 29 Nov 2011 18:29:43.0859 (UTC) FILETIME=[DD6C5830:01CCAEC4]
Cc: v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-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: Tue, 29 Nov 2011 18:29:48 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CCAEC4.DD3ADAFC
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: base64

QmFyYmFyYSwNCg0KIA0KDQpGcm9tOiBTVEFSSywgQkFSQkFSQSBIIFttYWlsdG86YnM3NjUyQGF0
dC5jb21dIA0KU2VudDogVHVlc2RheSwgTm92ZW1iZXIgMjksIDIwMTEgMTI6MDIgUE0NClRvOiBI
ZW1hbnQgU2luZ2ggKHNoZW1hbnQpOyBIYW5zIExpdQ0KQ2M6IFbDrXpkYWwgQWxlxaE7IE9sZSBU
cm9hbjsgam91bmkga29yaG9uZW47IHY2b3BzQGlldGYub3JnDQpTdWJqZWN0OiBSRTogW3Y2b3Bz
XSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXY2b3BzLTYyMDRiaXMtMDMudHh0DQoNCiANCg0KPkhl
bWFudCwgSSBkb27igJl0IHF1aXRlIHVuZGVyc3RhbmQgd2hhdCB5b3XigJlyZSBwcm9wb3Npbmcs
IGJ1dCBpdCBtYWtlcyBtZSB1bmNvbWZvcnRhYmxlLiBUaGUgV0FOLWNsdWVsZXNzIGRldmljZSBt
dXN0IG5vdCByZXF1aXJlIHVzZXIgY29uZmlndXJhdGlvbiB3aGVuIGNvbm5lY3RlZCB0byBhIHBh
cnRpY3VsYXIgV0FOLCBpZiBhdCBhbGwgcG9zc2libGUuIFRoYXQgd2FzIGEgPnZlcnkgaW1wb3J0
YW50IGRlc2lnbiBwcmluY2lwbGUuIFRoZSA2MjA0IHJlcXVpcmVtZW50cyB3ZXJlIGludGVuZGVk
IHRvIGFsbG93IHRoZSBXQU4gaW50ZXJmYWNlIHRvIGF1dG9tYXRpY2FsbHkgZXN0YWJsaXNoIGNv
bm5lY3Rpdml0eSwgbm8gbWF0dGVyIHdoaWNoIFdBTiBpdCBjb25uZWN0ZWQgdG8gKHRvIHRoZSBn
cmVhdGVzdCBleHRlbnQgcG9zc2libGUpLiBJ4oCZbSBvayBpZiA+c29tZSBvZiB0aGUgNjIwNGJp
cyByZXF1aXJlbWVudHMgcHJvdmlkZSBleGNlcHRpb25zIGZvciBkZXZpY2VzIHRoYXQgYXJlIGNv
bmZpZ3VyZWQgY2VydGFpbiB3YXlzLiBUaGlzIGFja25vd2xlZGdlcyB0aGF0IGl0IGlzIHBvc3Np
YmxlIGZvciBzdWNoIHByZS1jb25maWd1cmVkIGRldmljZXMgdG8gZXhpc3QuIEJ1dCBleHBsaWNp
dGx5IGRlc2NyaWJpbmcgYW5kIGNhbGxpbmcgb3V0IHRoZXNlID5jb25maWd1cmF0aW9uIHBvc3Np
YmlsaXRpZXMgaW4gdGhlaXIgb3duIHNlY3Rpb24gaXMgc29tZXRoaW5nIEnigJltIG5vdCBpbiBm
YXZvciBvZi4gVGhlIGNvbmZpZ3VyYXRpb24gZXhjbHVzaW9ucyBhcmUgdGhlcmUgdG8gYWxsb3cg
b3RoZXIgb3JncyB3aWdnbGUtcm9vbSB3aGVuIHdyaXRpbmcgdGhlaXIgb3duIHNwZWNzLiBUaGV5
IGFyZW7igJl0IHNvbWV0aGluZyB0aGF0IFdBTi0+Y2x1ZWxlc3MgZGV2aWNlcyBzaG91bGQgbmVl
ZCB0byBrbm93IGFueXRoaW5nIGFib3V0Lg0KDQogDQoNClNwZWNpZmljYWxseSwgdGhlIHJmYzYy
MDRiaXMgZG9jdW1lbnQgaGFzIGF1Z21lbnRlZCBidWxsZXRzIGZyb20gcmZjNjIwNCB3aXRoIHRl
eHQgc3VjaCBhcyDigJx1bmxlc3MgY29uZmlndXJlZCB0byBhY3F1aXJlIGEgZ2xvYmFsIGFkZHJl
c3PigKbigJ0uICBTbyB0aGUgdXNlciBvZiBhIENFIGlzIGdvaW5nIHRvIGNvbmZpZ3VyZSB0aGUg
Q0UgZm9yIG9uZSBzcGVjaWZpYyBXQU4gSVAgYWRkcmVzcyBhY3F1aXNpdGlvbiBiZWhhdmlvci4g
IFRodXMgIHdoeSBub3Qgc2VsbCBvdXQgdGhlIENvbmNlcHR1YWwgQ29uZmlndXJhdGlvbiBWYXJp
YWJsZXM/ICBGdXJ0aGVyIHRoZSB1bm51bWJlcmVkIG1vZGVsIGlzIGJ1cmllZCBpbiB0ZXh0IG9m
IHJmYzYyMDQgYW5kIHJmYzYyMDRiaXMgYW5kIGluY3JlYXNpbmdseSB3ZSBzZWUgbmV3IHJlYWRl
cnMgb2YgdGhlIGRvY3VtZW50cyBoYXZpbmcgbWlzc2VkIHRoZSB1bm51bWJlcmVkIG1vZGVsLiAg
IEhlbmNlIHdoeSBub3QgIGRlZmluZSBzdWNoIHZhcmlhYmxlcyB0byBtYXAgb3V0IHRoZSB0b3Rh
bCBzY29wZSBvZiB0aGUgV0FOIElQIGNvbmZpZ3VyYXRpb24gZm9yIHRoZSBDRS4gICBUaGUgdmFy
aWFibGVzIGRvIG5vdCBwcm9oaWJpdCBhIENFIHRvIGltcGxlbWVudCBhdXRvbWF0ZWQgV0FOIElQ
djYgYWRkcmVzcyBhY3F1aXNpdGlvbi9jcmVhdGlvbi4gICBJZiB5b3Ugd2FudCBhbmQgaWYgd2Ug
ZGVmaW5lIENvbmNlcHR1YWwgQ29uZmlndXJhdGlvbiBWYXJpYWJsZXMsIHdlIGNhbiBhZGQgYSBs
aW5lIHRoYXQgc2F5cyB0aGUgV0FOIElQdjYgYWRkcmVzcyBhY3F1aXNpdGlvbiBpcyBhdXRvbWF0
ZWQgYW5kIHNvbWUgZ3VpZGVsaW5lcyBhcmUgcHJvdmlkZWQgZm9yIGF1dG9tYXRhIGluIHNlY3Rp
b24gNC40LjMuDQoNCiANCg0KSGVtYW50DQoNCg==

------_=_NextPart_001_01CCAEC4.DD3ADAFC
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z
b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206
b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm
aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw
QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4
MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj
Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw
dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl
YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u
ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm
aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2
YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z
OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9
Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB
VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z
Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n
cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y
MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz
ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h
cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu
dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht
bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu
dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg
eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz
LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9
Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0
cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0
dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw
Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw
Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i
aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3
Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv
IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp
Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp
Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0
cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v
c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s
bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4
bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw
Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv
aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j
b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl
bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6
cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl
TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No
YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46
c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3
LnczLm9yZy9UUi9SRUMtaHRtbDQwIj48aGVhZD48bWV0YSBodHRwLWVxdWl2PUNvbnRlbnQtVHlw
ZSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjxtZXRhIG5hbWU9R2VuZXJhdG9y
IGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj48c3R5bGU+PCEt
LQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2Ft
YnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UN
Cgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9
DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAz
IDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9z
ZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1z
b05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFy
Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNh
bGlicmkiLCJzYW5zLXNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z
dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp
bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w
cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9
DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21z
by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsN
CgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuNXB0
Ow0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5
bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv
LXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4u
RW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJD
YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUy
MA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJy
aSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv
LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3Jk
U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu
IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z
dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk
aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g
OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl
ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVh
ZD48Ym9keSBsYW5nPUVOLVVTIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1Xb3Jk
U2VjdGlvbjE+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5C
YXJiYXJhLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5
bGU9J2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxkaXYg
c3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5n
OjMuMHB0IDBpbiAwaW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2Zv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwv
c3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9t
YSIsInNhbnMtc2VyaWYiJz4gU1RBUkssIEJBUkJBUkEgSCBbbWFpbHRvOmJzNzY1MkBhdHQuY29t
XSA8YnI+PGI+U2VudDo8L2I+IFR1ZXNkYXksIE5vdmVtYmVyIDI5LCAyMDExIDEyOjAyIFBNPGJy
PjxiPlRvOjwvYj4gSGVtYW50IFNpbmdoIChzaGVtYW50KTsgSGFucyBMaXU8YnI+PGI+Q2M6PC9i
PiBWw616ZGFsIEFsZcWhOyBPbGUgVHJvYW47IGpvdW5pIGtvcmhvbmVuOyB2Nm9wc0BpZXRmLm9y
Zzxicj48Yj5TdWJqZWN0OjwvYj4gUkU6IFt2Nm9wc10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi12
Nm9wcy02MjA0YmlzLTAzLnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBj
bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5
N0QnPiZndDs8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPkhlbWFudCwgSSBkb27i
gJl0IHF1aXRlIHVuZGVyc3RhbmQgd2hhdCB5b3XigJlyZSBwcm9wb3NpbmcsIGJ1dCBpdCBtYWtl
cyBtZSB1bmNvbWZvcnRhYmxlLiBUaGUgV0FOLWNsdWVsZXNzIGRldmljZSBtdXN0IG5vdCByZXF1
aXJlIHVzZXIgY29uZmlndXJhdGlvbiB3aGVuIGNvbm5lY3RlZCB0byBhIHBhcnRpY3VsYXIgV0FO
LCBpZiBhdCBhbGwgcG9zc2libGUuIFRoYXQgd2FzIGEgPC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xv
cjojMUY0OTdEJz4mZ3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz52ZXJ5IGlt
cG9ydGFudCBkZXNpZ24gcHJpbmNpcGxlLiBUaGUgNjIwNCByZXF1aXJlbWVudHMgd2VyZSBpbnRl
bmRlZCB0byBhbGxvdyB0aGUgV0FOIGludGVyZmFjZSB0byBhdXRvbWF0aWNhbGx5IGVzdGFibGlz
aCBjb25uZWN0aXZpdHksIG5vIG1hdHRlciB3aGljaCBXQU4gaXQgY29ubmVjdGVkIHRvICh0byB0
aGUgZ3JlYXRlc3QgZXh0ZW50IHBvc3NpYmxlKS4gSeKAmW0gb2sgaWYgPC9zcGFuPjxzcGFuIHN0
eWxlPSdjb2xvcjojMUY0OTdEJz4mZ3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdE
Jz5zb21lIG9mIHRoZSA2MjA0YmlzIHJlcXVpcmVtZW50cyBwcm92aWRlIGV4Y2VwdGlvbnMgZm9y
IGRldmljZXMgdGhhdCBhcmUgY29uZmlndXJlZCBjZXJ0YWluIHdheXMuIFRoaXMgYWNrbm93bGVk
Z2VzIHRoYXQgaXQgaXMgcG9zc2libGUgZm9yIHN1Y2ggcHJlLWNvbmZpZ3VyZWQgZGV2aWNlcyB0
byBleGlzdC4gQnV0IGV4cGxpY2l0bHkgZGVzY3JpYmluZyBhbmQgY2FsbGluZyBvdXQgdGhlc2Ug
PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz4mZ3Q7PC9zcGFuPjxzcGFuIHN0eWxl
PSdjb2xvcjojMUY0OTdEJz5jb25maWd1cmF0aW9uIHBvc3NpYmlsaXRpZXMgaW4gdGhlaXIgb3du
IHNlY3Rpb24gaXMgc29tZXRoaW5nIEnigJltIG5vdCBpbiBmYXZvciBvZi4gVGhlIGNvbmZpZ3Vy
YXRpb24gZXhjbHVzaW9ucyBhcmUgdGhlcmUgdG8gYWxsb3cgb3RoZXIgb3JncyB3aWdnbGUtcm9v
bSB3aGVuIHdyaXRpbmcgdGhlaXIgb3duIHNwZWNzLiBUaGV5IGFyZW7igJl0IHNvbWV0aGluZyB0
aGF0IFdBTi08L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPiZndDs8L3NwYW4+PHNw
YW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPmNsdWVsZXNzIGRldmljZXMgc2hvdWxkIG5lZWQgdG8g
a25vdyBhbnl0aGluZyBhYm91dC48L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9y
OiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+
PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPlNwZWNpZmljYWxseSwgdGhlIHJmYzYyMDRiaXMg
ZG9jdW1lbnQgaGFzIGF1Z21lbnRlZCBidWxsZXRzIGZyb20gcmZjNjIwNCB3aXRoIHRleHQgc3Vj
aCBhcyDigJx1bmxlc3MgY29uZmlndXJlZCB0byBhY3F1aXJlIGEgZ2xvYmFsIGFkZHJlc3PigKbi
gJ0uwqAgU28gdGhlIHVzZXIgb2YgYSBDRSBpcyBnb2luZyB0byBjb25maWd1cmUgdGhlIENFIGZv
ciBvbmUgc3BlY2lmaWMgV0FOIElQIGFkZHJlc3MgYWNxdWlzaXRpb24gYmVoYXZpb3IuwqAgVGh1
cyDCoHdoeSBub3Qgc2VsbCBvdXQgdGhlIENvbmNlcHR1YWwgQ29uZmlndXJhdGlvbiBWYXJpYWJs
ZXM/wqAgRnVydGhlciB0aGUgdW5udW1iZXJlZCBtb2RlbCBpcyBidXJpZWQgaW4gdGV4dCBvZiBy
ZmM2MjA0IGFuZCByZmM2MjA0YmlzIGFuZCBpbmNyZWFzaW5nbHkgd2Ugc2VlIG5ldyByZWFkZXJz
IG9mIHRoZSBkb2N1bWVudHMgaGF2aW5nIG1pc3NlZCB0aGUgdW5udW1iZXJlZCBtb2RlbC4gwqDC
oEhlbmNlIHdoeSBub3TCoCBkZWZpbmUgc3VjaCB2YXJpYWJsZXMgdG8gbWFwIG91dCB0aGUgdG90
YWwgc2NvcGUgb2YgdGhlIFdBTiBJUCBjb25maWd1cmF0aW9uIGZvciB0aGUgQ0UuwqDCoCBUaGUg
dmFyaWFibGVzIGRvIG5vdCBwcm9oaWJpdCBhIENFIHRvIGltcGxlbWVudCBhdXRvbWF0ZWQgV0FO
IElQdjYgYWRkcmVzcyBhY3F1aXNpdGlvbi9jcmVhdGlvbi7CoMKgIElmIHlvdSB3YW50IGFuZCBp
ZiB3ZSBkZWZpbmUgQ29uY2VwdHVhbCBDb25maWd1cmF0aW9uIFZhcmlhYmxlcywgd2UgY2FuIGFk
ZCBhIGxpbmUgdGhhdCBzYXlzIHRoZSBXQU4gSVB2NiBhZGRyZXNzIGFjcXVpc2l0aW9uIGlzIGF1
dG9tYXRlZCBhbmQgc29tZSBndWlkZWxpbmVzIGFyZSBwcm92aWRlZCBmb3IgYXV0b21hdGEgaW4g
c2VjdGlvbiA0LjQuMy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz
cGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAg
Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5IZW1hbnQ8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9ib2R5PjwvaHRtbD4=

------_=_NextPart_001_01CCAEC4.DD3ADAFC--

From bs7652@att.com  Tue Nov 29 11:32:17 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2953C21F8CA0 for ; Tue, 29 Nov 2011 11:32:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.392
X-Spam-Level: 
X-Spam-Status: No, score=-106.392 tagged_above=-999 required=5 tests=[AWL=0.207, 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 wWRNLrMlgyHi for ; Tue, 29 Nov 2011 11:32:16 -0800 (PST)
Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id 9D49421F8C9E for ; Tue, 29 Nov 2011 11:32:16 -0800 (PST)
X-Env-Sender: bs7652@att.com
X-Msg-Ref: server-7.tower-120.messagelabs.com!1322595134!51433043!1
X-Originating-IP: [144.160.20.146]
X-StarScan-Version: 6.3.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 30886 invoked from network); 29 Nov 2011 19:32:15 -0000
Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-7.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Nov 2011 19:32:15 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.5) with ESMTP id pATJUlxF023975; Tue, 29 Nov 2011 14:30:47 -0500
Received: from 01AL10015010626.AD.BLS.COM (sfldmibbcraeninet1.pmtr.mwst.att.com [10.231.16.33]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.5) with ESMTP id pATJUdAa023819; Tue, 29 Nov 2011 14:30:40 -0500
Received: from 01NC27689010625.AD.BLS.COM ([90.144.44.200]) by 01AL10015010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 29 Nov 2011 13:31:17 -0600
Received: from 01NC27689010650.AD.BLS.COM ([90.144.44.120]) by 01NC27689010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 29 Nov 2011 14:31:17 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64
Date: Tue, 29 Nov 2011 14:31:42 -0500
Message-ID: <750BF7861EBBE048B3E648B4BB6E8F4F212EB3BC@crexc50p>
In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3036CDB13@XMB-RCD-109.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
Thread-Index: AcyuPrdl+CPuCX+USj6zrA590tWMnwAC/abAABrXfVAAA2n1sAACE9RA
References: <2963F168-45CB-4042-8238-56DF538B0543@gmail.com><2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org><1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz><5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com><1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz><750BF7861EBBE048B3E648B4BB6E8F4F2106F69E@crexc50p>  <5B6B2B64C9FE2A489045EEEADDAFF2C3036CD910@XMB-RCD-109.cisco.com> <750BF7861EBBE048B3E648B4BB6E8F4F212EB1F3@crexc50p> <5B6B2B64C9FE2A489045EEEADDAFF2C3036CDB13@XMB-RCD-109.cisco.com>
From: "STARK, BARBARA H" 
To: "Hemant Singh (shemant)" , "Hans Liu" 
X-OriginalArrivalTime: 29 Nov 2011 19:31:17.0608 (UTC) FILETIME=[7711B680:01CCAECD]
Cc: v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-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: Tue, 29 Nov 2011 19:32:17 -0000

PiBTcGVjaWZpY2FsbHksIHRoZSByZmM2MjA0YmlzIGRvY3VtZW50IGhhcyBhdWdtZW50ZWQgYnVs
bGV0cyBmcm9tIHJmYzYyMDQgd2l0aCB0ZXh0IHN1Y2ggYXMg4oCcdW5sZXNzIGNvbmZpZ3VyZWQg
dG8gYWNxdWlyZSBhIGdsb2JhbCBhZGRyZXNz4oCm4oCdLsKgIFNvIHRoZSB1c2VyIG9mIGEgQ0Ug
aXMgZ29pbmcgdG8gY29uZmlndXJlIHRoZSBDRSBmb3Igb25lIHNwZWNpZmljIFdBTiBJUCBhZGRy
ZXNzIGFjcXVpc2l0aW9uIGJlaGF2aW9yLsKgIFRodXMgwqB3aHkgbm90IHNlbGwgb3V0IHRoZSBD
b25jZXB0dWFsIENvbmZpZ3VyYXRpb24gVmFyaWFibGVzP8KgIEZ1cnRoZXIgdGhlIHVubnVtYmVy
ZWQgbW9kZWwgaXMgYnVyaWVkIGluIHRleHQgb2YgcmZjNjIwNCBhbmQgcmZjNjIwNGJpcyBhbmQg
aW5jcmVhc2luZ2x5IHdlIHNlZSBuZXcgcmVhZGVycyBvZiB0aGUgZG9jdW1lbnRzIGhhdmluZyBt
aXNzZWQgdGhlIHVubnVtYmVyZWQgbW9kZWwuIMKgwqBIZW5jZSB3aHkgbm90wqAgZGVmaW5lIHN1
Y2ggdmFyaWFibGVzIHRvIG1hcCBvdXQgdGhlIHRvdGFsIHNjb3BlIG9mIHRoZSBXQU4gSVAgY29u
ZmlndXJhdGlvbiBmb3IgdGhlIENFLsKgwqAgVGhlIHZhcmlhYmxlcyBkbyBub3QgcHJvaGliaXQg
YSBDRSB0byBpbXBsZW1lbnQgYXV0b21hdGVkIFdBTiBJUHY2IGFkZHJlc3MgYWNxdWlzaXRpb24v
Y3JlYXRpb24uwqDCoCBJZiB5b3Ugd2FudCBhbmQgaWYgd2UgZGVmaW5lIENvbmNlcHR1YWwgQ29u
ZmlndXJhdGlvbiBWYXJpYWJsZXMsIHdlIGNhbiBhZGQgYSBsaW5lIHRoYXQgc2F5cyB0aGUgV0FO
IElQdjYgYWRkcmVzcyBhY3F1aXNpdGlvbiBpcyBhdXRvbWF0ZWQgYW5kIHNvbWUgZ3VpZGVsaW5l
cyBhcmUgcHJvdmlkZWQgZm9yIGF1dG9tYXRhIGluIHNlY3Rpb24gNC40LjMuIDwNCg0KPGJocz4g
Tm8uIFRoZXJlIGlzIG5vIGV4cGVjdGF0aW9uIHRoYXQgdGhlIHVzZXIgb2YgdGhlIENFIHdpbGwg
Y29uZmlndXJlIGl0IGZvciBhIHNwZWNpZmljIFdBTi4gVGhlIGV4cGVjdGF0aW9uIGlzIHRoYXQg
dGhlIENFIHdpbGwgaGF2ZSBhIGZhY3RvcnkgZGVmYXVsdCBjb25maWd1cmF0aW9uLCBiZWNhdXNl
IHRoZSBwYXJ0aWN1bGFyIENFIGlzIGludGVuZGVkIGZvciB1c2UgaW4gYSBwYXJ0aWN1bGFyIGVu
dmlyb25tZW50LiBUaGVzZSBjb25maWd1cmF0aW9uIGV4Y2VwdGlvbnMgYXJlIG5vdCBpbnRlbmRl
ZCBmb3IgV0FOLWNsdWVsZXNzIENFIHJvdXRlcnMuIFRoZXkgYXJlIGludGVuZGVkIGZvciBXQU4t
c3BlY2lmaWMgQ0Ugcm91dGVycy4NCg0KVGhlIGV4Y2VwdGlvbnMgZ2l2ZSB0aGUgc3BlY2lmaWVy
cyBvZiBXQU4tc3BlY2lmaWMgQ0Ugcm91dGVycyAoQ2FibGVMYWJzLCBCQkYsIDNHUFApIHRoZSBm
cmVlZG9tIHRvIG5vdCBpbXBsZW1lbnQgY2VydGFpbiBjYXBhYmlsaXRpZXMsIGJlY2F1c2UgdGhl
aXIgV0FOIGlzIGtub3duIHRvIHRoZW0uIFRoZSBleGNlcHRpb25zIG5lZWQgdG8gYmUgaWdub3Jl
ZCBieSBXQU4tY2x1ZWxlc3Mgcm91dGVyIGltcGxlbWVudGVycy4gV0FOLWNsdWVsZXNzIENFIHJv
dXRlcnMgaGF2ZSBubyBuZWVkIGZvciB0aGVzZSBjb25maWd1cmF0aW9uIGNvbmNlcHRzLiBJIGRv
bid0IHdhbnQgdG8gZ2l2ZSB0aGUgaW1wcmVzc2lvbiB0aGF0IHN1Y2ggY29uZmlndXJhYmlsaXR5
IGlzIG5lZWRlZCBvciBlbmNvdXJhZ2VkIGluIFdBTi1jbHVlbGVzcyBDRSByb3V0ZXJzLiBPZiBj
b3Vyc2UgdGhleSBhcmUgbm90IHByb2hpYml0ZWQgZnJvbSBvZmZlcmluZyBzdWNoIGNvbmZpZ3Vy
YXRpb24sIGJ1dCBieSByZW1haW5pbmcgc2lsZW50IG9uIHRoZSB0b3BpYywgc3VjaCBjb25maWd1
cmFiaWxpdHkgaXMgbmVpdGhlciBlbmNvdXJhZ2VkIG5vciBwcm9oaWJpdGVkLiAgPC9iaHMNCkJh
cmJhcmENCg==

From Tina.Tsou.Zouting@huawei.com  Tue Nov 29 11:45:38 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFFCA21F8AFB for ; Tue, 29 Nov 2011 11:45:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.148
X-Spam-Level: 
X-Spam-Status: No, score=-6.148 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_32=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 fJXfGffQJfR7 for ; Tue, 29 Nov 2011 11:45:37 -0800 (PST)
Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id A495721F8AF4 for ; Tue, 29 Nov 2011 11:45:36 -0800 (PST)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LVF00JR0TJSGR@szxga04-in.huawei.com> for v6ops@ietf.org; Wed, 30 Nov 2011 03:45:28 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LVF0089ITJR5N@szxga04-in.huawei.com> for v6ops@ietf.org; Wed, 30 Nov 2011 03:45:28 +0800 (CST)
Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AFI42896; Wed, 30 Nov 2011 03:45:27 +0800
Received: from SZXEML418-HUB.china.huawei.com (10.82.67.157) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 30 Nov 2011 03:45:23 +0800
Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.40]) by szxeml418-hub.china.huawei.com ([10.82.67.157]) with mapi id 14.01.0218.012; Wed, 30 Nov 2011 03:45:18 +0800
Date: Tue, 29 Nov 2011 19:45:17 +0000
From: Tina TSOU 
In-reply-to: 
X-Originating-IP: [10.193.34.145]
To: "Hemant Singh (shemant)" 
Message-id: 
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_BdNnQzJgv1bNFQa3DkKvuQ)"
Content-language: en-US
Accept-Language: en-US, zh-CN
Thread-topic: [v6ops] 6rd Sunsetting
Thread-index: AQHMo2zkiVaVmflTEk2DrH6PcFso4ZWtESmAgAF9cYCAACEjgIABVu+AgAfhuoCAADwWAIAAAlqAgABDmgCAAIAigIAAtJqAgABw8oCAAQQ29YAIFkuwgAAdbVCAAAjLgIAAFeR6gADeqmCAABIVMA==
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
References:   <68DAB112-6E32-45FE-9AB7-A34E64898F60@cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30354436E@XMB-RCD-109.cisco.com> <750BF7861EBBE048B3E648B4BB6E8F4F20DC41F6@crexc50p>  <252D3DEA-FF09-42C8-959E-8A7205D9DE67@townsley.net>  <20111122133612.GH71280@Space.Net> <4ECC10C9.5010607@gmail.com> <20111123080113.GI71280@Space.Net>     <5B6B2B64C9FE2A489045EEEADDAFF2C3036CD912@XMB-RCD-109.cisco.com> <54ADF508-673A-47EE-AF1F-ABAF68A72D0A@huawei.com> 
Cc: Alexandre Cassen , "v6ops@ietf.org" , Claire Cheng 
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 29 Nov 2011 19:45:38 -0000

--Boundary_(ID_BdNnQzJgv1bNFQa3DkKvuQ)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

Yes I have similar example in mind too......I am only unclear as to where we provide the preference for the route over native interface........in the code or there is a configuration command to assign higher priority to the native route.

Tina
From: "Hemant Singh (shemant)" >
Date: November 28, 2011 8:10:29 PM PST
To: Tina TSOU >, >
Cc: Alexandre Cassen >, >, Claire Cheng >
Subject: RE: [v6ops] 6rd Sunsetting
Tina,

From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Tina TSOU
Sent: Monday, November 28, 2011 10:35 PM
To: gert@space.net
Cc: Alexandre Cassen; v6ops@ietf.org; Claire Cheng
Subject: Re: [v6ops] 6rd Sunsetting


>How does "the CPE has to ensure that it sends packets over the right interface"?
>Lets say you have 6rd prefix 2002::/16 which is also the native IPv6 prefix. So if we have a static route like >"ipv6 static route 2002::/16 tunnel-interface", how can we have >another static route for this prefix with native >IPv6 interface?

See a configuration example from my IPv6 router for a static IPv6 route supporting two different network interfaces.

rtr# show run | I ipv6 route
ipv6 route 3001:1234:5678::/48 Bundle1
ipv6 route 3001:1234:5678::/48 GigabitEthernet4/0/0
rtr#
rtr#sh ipv6 route
...
S   3001:1234:5678::/48 [1/0]
     via GigabitEthernet4/0/0, directly connected
     via Bundle1, directly connected

For the same prefix between 6rd and native IPv6, the native IPv6 link is preferred as specified in bullet 5 of section 4.4.3 of rfc6204bis.

Hemant

--Boundary_(ID_BdNnQzJgv1bNFQa3DkKvuQ)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: quoted-printable













Yes I have similar exampl=
e in mind too……I am only unclear as to where we provide the pre=
ference for the route over native interface……..in the code or t=
here
 is a configuration command to assign higher priority to the native route.<=
o:p>




 


Tina








From: "He=
mant Singh (shemant)" <shemant=
@cisco.com>

Date: November 28, 2011 8:10:29 PM PST

To: Tina TSOU <Ti=
na.Tsou.Zouting@huawei.com>, <g=
ert@space.net>

Cc: Alexandre Cassen <acass=
en@freebox.fr>, <v6ops@ietf.org=
>, Claire Cheng <cla=
ire_cheng@dlink.com.tw>

Subject: RE: [v6ops] 6rd Sunsetting












Tina,


 






From:
v6ops-bounces@ietf.org [mailt=
o:v6ops-bounces@ietf.org]
On Behalf Of Tina TSOU

Sent: Monday, November 28, 2011 10:35 PM

To: gert@space.net

Cc: Alexandre Cassen; v6ops@ietf.o=
rg; Claire Cheng

Subject: Re: [v6ops] 6rd Sunsetting






 


 


>How does “the
 CPE has to ensure that it sends packets over the right interface”?


=
>=
Lets say you have 6rd prefix 2002::/16 which is also the native
IP=
v6 p=
refix. So if we have a static route like
&g=
t;&#=
8220;ipv6 static route 2002::/16 tunnel-interface”, how can we have
&g=
t;an=
other static route for this prefix with native
&g=
t;IP=
v6 interface?


=
 


See a configuration example from my IPv6 router for a stat=
ic IPv6 route supporting two different network interfaces.


 


rtr# show run | I ipv6 route


ipv6 route 3001:1234:5678::/48 Bundle1

ipv6 route 3001:1234:5678::/48 GigabitEthernet4/0/0=



rtr#


rtr#sh ipv6 route


…


S   3001:1234:5678::/48 [1/0]<=
/p>

     via GigabitEthernet4/0/0, directl=
y connected


     via Bundle1, directly connected


 


For the same prefix between 6rd and native IPv6, the nativ=
e IPv6 link is preferred as specified in bullet
 5 of section 4.4.3 of rfc6204bis.


 


Hemant












--Boundary_(ID_BdNnQzJgv1bNFQa3DkKvuQ)--

From Tina.Tsou.Zouting@huawei.com  Tue Nov 29 11:46:57 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A7C211E810B for ; Tue, 29 Nov 2011 11:46:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.098
X-Spam-Level: 
X-Spam-Status: No, score=-6.098 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_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 bmipmch9V1pw for ; Tue, 29 Nov 2011 11:46:53 -0800 (PST)
Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 0D1B111E8102 for ; Tue, 29 Nov 2011 11:46:53 -0800 (PST)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LVF00HB5TM432@szxga04-in.huawei.com> for v6ops@ietf.org; Wed, 30 Nov 2011 03:46:52 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LVF008BXTM35N@szxga04-in.huawei.com> for v6ops@ietf.org; Wed, 30 Nov 2011 03:46:52 +0800 (CST)
Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AFI42910; Wed, 30 Nov 2011 03:46:51 +0800
Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 30 Nov 2011 03:46:47 +0800
Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.40]) by szxeml404-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Wed, 30 Nov 2011 03:46:42 +0800
Date: Tue, 29 Nov 2011 19:46:42 +0000
From: Tina TSOU 
In-reply-to: 
X-Originating-IP: [10.193.34.145]
To: Victor Kuarsingh 
Message-id: 
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_nRpQQwFHjO8XxgV8FpswCQ)"
Content-language: en-US
Accept-Language: en-US, zh-CN
Thread-topic: [v6ops] 6rd Sunsetting
Thread-index: AQHMo2zkiVaVmflTEk2DrH6PcFso4ZWtESmAgAF9cYCAACEjgIABVu+AgAfhuoCAADwWAIAAAlqAgABDmgCAABLvAIACYfoAgAEsZYCAAJiPgIAAsaMAgALjsICAAEo9gIAAmGCp//+RRoCAAChWgIAAjZuAgACCHoCAABLogIAAEeIAgAARTgCAAAloAIABPLELgADbSDCAABr7UA==
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
References:    
Cc: Alexandre Cassen , "v6ops@ietf.org" , Claire Cheng 
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 29 Nov 2011 19:46:57 -0000

--Boundary_(ID_nRpQQwFHjO8XxgV8FpswCQ)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

As per the mail below from Victor, if we stop 6rd on a CPE completely when native is enabled, what if the destination CPE inside the domain is still only 6rd??This can be reached only through 6rd . The SP can stop 6rd completely only if he is sure that all CPE's in his domain are on native v6 n/w.

Tina
From: Victor Kuarsingh >
Date: November 28, 2011 10:10:32 AM PST
To: Mark Townsley >, Tom Taylor >
Cc: Alexandre Cassen >, "v6ops@ietf.org" >, Claire Cheng >
Subject: Re: [v6ops] 6rd Sunsetting
Mark,


On Nov 28, 2011, at 5:34 PM, Tom Taylor wrote:

Below, snipped to key points.

On 28/11/2011 10:30 AM, Mark Townsley wrote:

On Nov 28, 2011, at 3:23 PM, Wes Beebee wrote:

...

A packet comes into the CE router from a host in the home and is
destined out of the home.  Is that packet encapsulated or not?

We HAVE to be able to answer that question in a completely
deterministic and consistent manner.

...

If there happen to be two interfaces with the same delegated prefix
(one of the cases listed in 6rd-sunsetting), then the CE must decide
which to send the packet on. Everything else being equal, physical
over virtual is probably a good metric to have, and it works well in
this case as well. So, for the specific case of one 6rd and one
native interface, Internet-destined traffic should always prefer
native over 6rd.

[PTT] It would be a mistake to send encapsulated packets over the
physical interface. This is Wes's point: how to avoid that mistake?

IPv6 traffic destined outside the 6rd domain should be over the native
link, with no encapsulation in IPv4.

Traffic destined for within the 6rd domain ("CE to CE traffic") will most
likely traverse a shorter path if encapsulated in IPv4, and does not
require traversal of the 6rd BR path as well.  So, this traffic continues
over 6rd until 6rd can be fully disabled on the CE.

The idea here is to choose what is most likely the shortest path, and to
reduce BR utilization.

* Sorry for long email....

I am not trying to be too disruptive in this thread, but did want to note
a few points (which you may or may not agree with).

I think we are assuming that the CE to CE path would be "shortest" if
using 6RD directly on both endpoints (where one is now Native v6/6RD and
the other only 6RD). In my mind, "shortest" path would also include
performance and overall delay to get form one host to the other (home
network host to home network host).

I think that the performance of the 6RD function (I.e.
Encapsulation/decapsulation performance) on the CE would be a factor when
compared to a network placed/resident BR.  Also, the placement of BRs may
be be optimally placed such that the actual network path may be similar
(but unless co-located with the BNG there will be uses cases where this
may not be possible).

If utilization on the BR is not the key point here, then how important is
CE to CE performance (let's say that there is a small to measurable
difference) when considering the entire transition eco-system?  Does
making this specific flow type (one flow use case) warrant us solving this
issue by adding in state/routing complexity into the CPE to achieve this?

In my mind (which seems to be somewhat at odds with others), I would want
to choose an option which would cause a device to stop doing 6RD when
Native IPv6 is available (bias declared).

I say this since it would add a level of determinism to what I would
expect (say an operator has only course level control as to what
parameters they give each CPE).  This type of determinism goes a long way
for operations and customer care folks (when troubleshooting problems).

I am not saying we cannot make the suggested behaviour (as per drafts in
discussion) work, but other then some optimizations on the CE to CE flows
(within a given 6RD domain), are there other significant gains? (perhaps I
am somewhat ignorant to the gambit of benefits).

(this next point may be a bit off topic)

If re-addressing is one of the the big issues, I am not sure if this can
be avoided (in totality).  6RD to Native IPv6 transition is just one use
case where I need to re-address a CPE/home network.  I have all sorts of
uses cases where this will happen - so we will need to solve the IPv6
renumbering/stability case anyway.  In our network, I would see the move
from 6RD to Native IPv6 (in the prefix retention case) a renumbering
exercise from one Interface type to another (if I can figure out how to
offer the same prefix and not break all types of rules and provisioning
systems at the same time).

Again, I would prefer a cut over from one interface to the other (virtual
to native).  This is what I would ask my vendor to implement.  Once I add
in Native to a capable CPE, I would expect the CPE to go native. I am
hoping there is an option for this within all the proposals.

Sorry to be potentially digging up old bones on this.. I tried to review
entire email thread.

Thoughts?

Victor K






- Mark


- Mark


- Wes


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



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


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

--Boundary_(ID_nRpQQwFHjO8XxgV8FpswCQ)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: quoted-printable













As per the mail below fro=
m Victor, if we stop 6rd on a CPE completely when native is enabled, what i=
f the destination CPE inside the domain is still only 6rd??This
 can be reached only through 6rd . The SP can stop 6rd completely only if h=
e is sure that all CPE’s in his domain are on native v6 n/w.




 


Tina








From: Victor K=
uarsingh <victor.kuarsingh=
@gmail.com>

Date: November 28, 2011 10:10:32 AM PST

To: Mark Townsley <mark@town=
sley.net>, Tom Taylor <=
tom111.taylor@bell.net>

Cc: Alexandre Cassen <acass=
en@freebox.fr>, "v6ops@ietf.o=
rg" <v6ops@ietf.org>, =
Claire Cheng <claire_cheng@=
dlink.com.tw>

Subject: Re: [v6ops] 6rd Sunsetting










Mark,






 




On Nov 28, 2011, at 5:34 PM, Tom Taylor wrote:<=
/o:p>






 








Below, snipped to key points.










 










On 28/11/2011 10:30 AM, Mark Townsley wrote:












 














On Nov 28, 2011, at 3:23 PM, Wes Beebee wrote:<=
/o:p>














 












...














 


















A packet comes into the CE router from a host in the=
 home and is


















destined out of the home.  Is that packet encap=
sulated or not?


















 


















We HAVE to be able to answer that question in a comp=
letely


















deterministic and consistent manner.
















 












...












 














If there happen to be two interfaces with the same d=
elegated prefix














(one of the cases listed in 6rd-sunsetting), then th=
e CE must decide














which to send the packet on. Everything else being e=
qual, physical














over virtual is probably a good metric to have, and =
it works well in














this case as well. So, for the specific case of one =
6rd and one














native interface, Internet-destined traffic should a=
lways prefer














native over 6rd.














 












[PTT] It would be a mistake to send encapsulated pac=
kets over the










physical interface. This is Wes's point: how to avoi=
d that mistake?








 






IPv6 traffic destined outside the 6rd domain should =
be over the native






link, with no encapsulation in IPv4.






 






Traffic destined for within the 6rd domain ("CE=
 to CE traffic") will most






likely traverse a shorter path if encapsulated in IP=
v4, and does not






require traversal of the 6rd BR path as well.  =
So, this traffic continues






over 6rd until 6rd can be fully disabled on the CE.<=
o:p>






 






The idea here is to choose what is most likely the s=
hortest path, and to






reduce BR utilization.






* Sorry for long email....



I am not trying to be too disruptive in this thread, but did want to note
a few points (which you may or may not agree with).



I think we are assuming that the CE to CE path would be "shortest"=
; if

using 6RD directly on both endpoints (where one is now Native v6/6RD and
the other only 6RD). In my mind, "shortest" path would also inclu=
de

performance and overall delay to get form one host to the other (home

network host to home network host).



I think that the performance of the 6RD function (I.e.

Encapsulation/decapsulation performance) on the CE would be a factor when
compared to a network placed/resident BR.  Also, the placement of BRs =
may

be be optimally placed such that the actual network path may be similar

(but unless co-located with the BNG there will be uses cases where this

may not be possible).



If utilization on the BR is not the key point here, then how important is
CE to CE performance (let's say that there is a small to measurable

difference) when considering the entire transition eco-system?  Does
making this specific flow type (one flow use case) warrant us solving this<=
br>
issue by adding in state/routing complexity into the CPE to achieve this?


In my mind (which seems to be somewhat at odds with others), I would want
to choose an option which would cause a device to stop doing 6RD when

Native IPv6 is available (bias declared).



I say this since it would add a level of determinism to what I would

expect (say an operator has only course level control as to what

parameters they give each CPE).  This type of determinism goes a long =
way

for operations and customer care folks (when troubleshooting problems).



I am not saying we cannot make the suggested behaviour (as per drafts in
discussion) work, but other then some optimizations on the CE to CE flows
(within a given 6RD domain), are there other significant gains? (perhaps I<=
br>
am somewhat ignorant to the gambit of benefits).



(this next point may be a bit off topic)



If re-addressing is one of the the big issues, I am not sure if this can
be avoided (in totality).  6RD to Native IPv6 transition is just one u=
se

case where I need to re-address a CPE/home network.  I have all sorts =
of

uses cases where this will happen - so we will need to solve the IPv6

renumbering/stability case anyway.  In our network, I would see the mo=
ve

from 6RD to Native IPv6 (in the prefix retention case) a renumbering

exercise from one Interface type to another (if I can figure out how to

offer the same prefix and not break all types of rules and provisioning

systems at the same time).



Again, I would prefer a cut over from one interface to the other (virtual
to native).  This is what I would ask my vendor to implement.  On=
ce I add

in Native to a capable CPE, I would expect the CPE to go native. I am

hoping there is an option for this within all the proposals.



Sorry to be potentially digging up old bones on this.. I tried to review
entire email thread.



Thoughts?



Victor K












 




 






- Mark






 










 














- Mark














 
















 


















- Wes


















 
















 














_______________________________________________ v6op=
s mailing list














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














 














 










 






_______________________________________________=







v6ops mailing list






v6ops@ietf.org=







https://www.ietf.org/mailman/listinfo/v6ops








_______________________________________________

v6ops mailing list

v6ops@ietf.org

https://www.ietf.or=
g/mailman/listinfo/v6ops










--Boundary_(ID_nRpQQwFHjO8XxgV8FpswCQ)--

From mark@townsley.net  Tue Nov 29 12:06:00 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 664841F0C89 for ; Tue, 29 Nov 2011 12:06:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.018
X-Spam-Level: 
X-Spam-Status: No, score=-3.018 tagged_above=-999 required=5 tests=[AWL=-0.020, 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 plE+Kho+4XZI for ; Tue, 29 Nov 2011 12:05:59 -0800 (PST)
Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7854B1F0C75 for ; Tue, 29 Nov 2011 12:05:58 -0800 (PST)
Received: by eabm6 with SMTP id m6so4028463eab.31 for ; Tue, 29 Nov 2011 12:05:57 -0800 (PST)
Received: by 10.213.2.70 with SMTP id 6mr18243ebi.68.1322597157518; Tue, 29 Nov 2011 12:05:57 -0800 (PST)
Received: from ams-townsley-8712.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id d6sm108678240eec.10.2011.11.29.12.05.54 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 29 Nov 2011 12:05:56 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-65-692569445
From: Mark Townsley 
In-Reply-To: 
Date: Tue, 29 Nov 2011 21:05:52 +0100
Message-Id: <51C5A220-150E-4C8F-BEE4-DA9B5D5A5D15@townsley.net>
References:     
To: Tina TSOU 
X-Mailer: Apple Mail (2.1084)
Cc: Alexandre Cassen , "v6ops@ietf.org" , Claire Cheng 
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 29 Nov 2011 20:06:00 -0000

--Apple-Mail-65-692569445
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


On Nov 29, 2011, at 8:46 PM, Tina TSOU wrote:

> As per the mail below from Victor, if we stop 6rd on a CPE completely =
when native is enabled, what if the destination CPE inside the domain is =
still only 6rd??This can be reached only through 6rd . The SP can stop =
6rd completely only if he is sure that all CPE=92s in his domain are on =
native v6 n/w.

Exactly.

- Mark

> =20
>=20
> Tina
>=20
> From: Victor Kuarsingh 
> Date: November 28, 2011 10:10:32 AM PST
> To: Mark Townsley , Tom Taylor =

> Cc: Alexandre Cassen , "v6ops@ietf.org" =
, Claire Cheng 
> Subject: Re: [v6ops] 6rd Sunsetting
>=20
> Mark,
>=20
>=20
> =20
> On Nov 28, 2011, at 5:34 PM, Tom Taylor wrote:
> =20
> Below, snipped to key points.
> =20
> On 28/11/2011 10:30 AM, Mark Townsley wrote:
> =20
> On Nov 28, 2011, at 3:23 PM, Wes Beebee wrote:
> =20
> ...
> =20
> A packet comes into the CE router from a host in the home and is
> destined out of the home.  Is that packet encapsulated or not?
> =20
> We HAVE to be able to answer that question in a completely
> deterministic and consistent manner.
> =20
> ...
> =20
> If there happen to be two interfaces with the same delegated prefix
> (one of the cases listed in 6rd-sunsetting), then the CE must decide
> which to send the packet on. Everything else being equal, physical
> over virtual is probably a good metric to have, and it works well in
> this case as well. So, for the specific case of one 6rd and one
> native interface, Internet-destined traffic should always prefer
> native over 6rd.
> =20
> [PTT] It would be a mistake to send encapsulated packets over the
> physical interface. This is Wes's point: how to avoid that mistake?
> =20
> IPv6 traffic destined outside the 6rd domain should be over the native
> link, with no encapsulation in IPv4.
> =20
> Traffic destined for within the 6rd domain ("CE to CE traffic") will =
most
> likely traverse a shorter path if encapsulated in IPv4, and does not
> require traversal of the 6rd BR path as well.  So, this traffic =
continues
> over 6rd until 6rd can be fully disabled on the CE.
> =20
> The idea here is to choose what is most likely the shortest path, and =
to
> reduce BR utilization.
>=20
> * Sorry for long email....
>=20
> I am not trying to be too disruptive in this thread, but did want to =
note
> a few points (which you may or may not agree with).
>=20
> I think we are assuming that the CE to CE path would be "shortest" if
> using 6RD directly on both endpoints (where one is now Native v6/6RD =
and
> the other only 6RD). In my mind, "shortest" path would also include
> performance and overall delay to get form one host to the other (home
> network host to home network host).
>=20
> I think that the performance of the 6RD function (I.e.
> Encapsulation/decapsulation performance) on the CE would be a factor =
when
> compared to a network placed/resident BR.  Also, the placement of BRs =
may
> be be optimally placed such that the actual network path may be =
similar
> (but unless co-located with the BNG there will be uses cases where =
this
> may not be possible).
>=20
> If utilization on the BR is not the key point here, then how important =
is
> CE to CE performance (let's say that there is a small to measurable
> difference) when considering the entire transition eco-system?  Does
> making this specific flow type (one flow use case) warrant us solving =
this
> issue by adding in state/routing complexity into the CPE to achieve =
this?
>=20
> In my mind (which seems to be somewhat at odds with others), I would =
want
> to choose an option which would cause a device to stop doing 6RD when
> Native IPv6 is available (bias declared).
>=20
> I say this since it would add a level of determinism to what I would
> expect (say an operator has only course level control as to what
> parameters they give each CPE).  This type of determinism goes a long =
way
> for operations and customer care folks (when troubleshooting =
problems).
>=20
> I am not saying we cannot make the suggested behaviour (as per drafts =
in
> discussion) work, but other then some optimizations on the CE to CE =
flows
> (within a given 6RD domain), are there other significant gains? =
(perhaps I
> am somewhat ignorant to the gambit of benefits).
>=20
> (this next point may be a bit off topic)
>=20
> If re-addressing is one of the the big issues, I am not sure if this =
can
> be avoided (in totality).  6RD to Native IPv6 transition is just one =
use
> case where I need to re-address a CPE/home network.  I have all sorts =
of
> uses cases where this will happen - so we will need to solve the IPv6
> renumbering/stability case anyway.  In our network, I would see the =
move
> from 6RD to Native IPv6 (in the prefix retention case) a renumbering
> exercise from one Interface type to another (if I can figure out how =
to
> offer the same prefix and not break all types of rules and =
provisioning
> systems at the same time).
>=20
> Again, I would prefer a cut over from one interface to the other =
(virtual
> to native).  This is what I would ask my vendor to implement.  Once I =
add
> in Native to a capable CPE, I would expect the CPE to go native. I am
> hoping there is an option for this within all the proposals.
>=20
> Sorry to be potentially digging up old bones on this.. I tried to =
review
> entire email thread.
>=20
> Thoughts?
>=20
> Victor K
>=20
>=20
>=20
>=20
>=20
> =20
> =20
> - Mark
> =20
> =20
> - Mark
> =20
> =20
> - Wes
> =20
> =20
> _______________________________________________ v6ops mailing list
> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops
> =20
> =20
> =20
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>=20
>=20
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


--Apple-Mail-65-692569445
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252


On Nov 29, 2011, at 8:46 PM, Tina =
TSOU wrote:

As per the mail below from =
Victor, if we stop 6rd on a CPE completely when native is enabled, what =
if the destination CPE inside the domain is still only 6rd??This can be =
reached only through 6rd . The SP can stop 6rd completely only if he is =
sure that all CPE=92s in his domain are on native v6 =
n/w.

Exact=
ly.

- Mark

Tina
Mark,

<=
blockquote style=3D"margin-top: 5pt; margin-bottom: 5pt; ">
We HAVE to be able to answer that question in a =
completely
deterministic and consistent =
manner.
over virtual =
is probably a good metric to have, and it works well =
in

* Sorry for long email....

I am not trying to be too =
disruptive in this thread, but did want to note
a few points (which =
you may or may not agree with).

I think we are assuming that the =
CE to CE path would be "shortest" if
using 6RD directly on both =
endpoints (where one is now Native v6/6RD and
the other only 6RD). In =
my mind, "shortest" path would also include
performance and overall =
delay to get form one host to the other (home
network host to home =
network host).

I think that the performance of the 6RD function =
(I.e.
Encapsulation/decapsulation performance) on the CE would be a =
factor when
compared to a network placed/resident BR.  Also, the =
placement of BRs may
be be optimally placed such that the actual =
network path may be similar
(but unless co-located with the BNG there =
will be uses cases where this
may not be possible).

If =
utilization on the BR is not the key point here, then how important =
is
CE to CE performance (let's say that there is a small to =
measurable
difference) when considering the entire transition =
eco-system?  Does
making this specific flow type (one flow use =
case) warrant us solving this
issue by adding in state/routing =
complexity into the CPE to achieve this?

In my mind (which seems =
to be somewhat at odds with others), I would want
to choose an option =
which would cause a device to stop doing 6RD when
Native IPv6 is =
available (bias declared).

I say this since it would add a level =
of determinism to what I would
expect (say an operator has only =
course level control as to what
parameters they give each CPE). =
 This type of determinism goes a long way
for operations and =
customer care folks (when troubleshooting problems).

I am not =
saying we cannot make the suggested behaviour (as per drafts =
in
discussion) work, but other then some optimizations on the CE to =
CE flows
(within a given 6RD domain), are there other significant =
gains? (perhaps I
am somewhat ignorant to the gambit of =
benefits).

(this next point may be a bit off topic)

If =
re-addressing is one of the the big issues, I am not sure if this =
can
be avoided (in totality).  6RD to Native IPv6 transition is =
just one use
case where I need to re-address a CPE/home network. =
 I have all sorts of
uses cases where this will happen - so we =
will need to solve the IPv6
renumbering/stability case anyway. =
 In our network, I would see the move
from 6RD to Native IPv6 =
(in the prefix retention case) a renumbering
exercise from one =
Interface type to another (if I can figure out how to
offer the same =
prefix and not break all types of rules and provisioning
systems at =
the same time).

Again, I would prefer a cut over from one =
interface to the other (virtual
to native).  This is what I =
would ask my vendor to implement.  Once I add
in Native to a =
capable CPE, I would expect the CPE to go native. I am
hoping there =
is an option for this within all the proposals.

Sorry to be =
potentially digging up old bones on this.. I tried to review
entire =
email thread.

Thoughts?

Victor =
K




v6ops@ietf.org 
 
v6ops mailing =
list
v6ops@ietf.org

In-Reply-To: <750BF7861EBBE048B3E648B4BB6E8F4F212EB3BC@crexc50p>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
Thread-Index: AcyuPrdl+CPuCX+USj6zrA590tWMnwAC/abAABrXfVAAA2n1sAACE9RAAAHEFdA=
References: <2963F168-45CB-4042-8238-56DF538B0543@gmail.com><2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org><1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz><5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com><1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz><750BF7861EBBE048B3E648B4BB6E8F4F2106F69E@crexc50p>  <5B6B2B64C9FE2A489045EEEADDAFF2C3036CD910@XMB-RCD-109.cisco.com> <750BF7861EBBE048B3E648B4BB6E8F4F212EB1F3@crexc50p> <5B6B2B64C9FE2A489045EEEADDAFF2C3036CDB13@XMB-RCD-109.cisco.com> <750BF7861EBBE048B3E648B4BB6E8F4F212EB3BC@crexc50p>
From: "Hemant Singh (shemant)" 
To: "STARK, BARBARA H" , "Hans Liu" 
X-OriginalArrivalTime: 29 Nov 2011 20:12:44.0331 (UTC) FILETIME=[414587B0:01CCAED3]
Cc: v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-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: Tue, 29 Nov 2011 20:12:49 -0000

QmFyYmFyYSwNCg0KT0sgLSBhcHByZWNpYXRlIHRoZSBpbnB1dC4gIEkgd2lsbCBsZXQgSGFucyBh
bmQgeW91IGRlY2lkZSBvbiB0aGlzIG9uZSBzaW5jZSBIYW5zIGlzIGxlYW5pbmcgdG93YXJkcyBh
IENvbmNlcHR1YWwgQ29uZmlndXJhdGlvbiBWYXJpYWJsZXMgc2VjdGlvbi4gDQoNCkhlbWFudA0K
DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogU1RBUkssIEJBUkJBUkEgSCBbbWFp
bHRvOmJzNzY1MkBhdHQuY29tXSANClNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDI5LCAyMDExIDI6
MzIgUE0NClRvOiBIZW1hbnQgU2luZ2ggKHNoZW1hbnQpOyBIYW5zIExpdQ0KQ2M6IFbDrXpkYWwg
QWxlxaE7IE9sZSBUcm9hbjsgam91bmkga29yaG9uZW47IHY2b3BzQGlldGYub3JnDQpTdWJqZWN0
OiBSRTogW3Y2b3BzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXY2b3BzLTYyMDRiaXMtMDMudHh0
DQoNCj4gU3BlY2lmaWNhbGx5LCB0aGUgcmZjNjIwNGJpcyBkb2N1bWVudCBoYXMgYXVnbWVudGVk
IGJ1bGxldHMgZnJvbSByZmM2MjA0IHdpdGggdGV4dCBzdWNoIGFzIOKAnHVubGVzcyBjb25maWd1
cmVkIHRvIGFjcXVpcmUgYSBnbG9iYWwgYWRkcmVzc+KApuKAnS7CoCBTbyB0aGUgdXNlciBvZiBh
IENFIGlzIGdvaW5nIHRvIGNvbmZpZ3VyZSB0aGUgQ0UgZm9yIG9uZSBzcGVjaWZpYyBXQU4gSVAg
YWRkcmVzcyBhY3F1aXNpdGlvbiBiZWhhdmlvci7CoCBUaHVzIMKgd2h5IG5vdCBzZWxsIG91dCB0
aGUgQ29uY2VwdHVhbCBDb25maWd1cmF0aW9uIFZhcmlhYmxlcz/CoCBGdXJ0aGVyIHRoZSB1bm51
bWJlcmVkIG1vZGVsIGlzIGJ1cmllZCBpbiB0ZXh0IG9mIHJmYzYyMDQgYW5kIHJmYzYyMDRiaXMg
YW5kIGluY3JlYXNpbmdseSB3ZSBzZWUgbmV3IHJlYWRlcnMgb2YgdGhlIGRvY3VtZW50cyBoYXZp
bmcgbWlzc2VkIHRoZSB1bm51bWJlcmVkIG1vZGVsLiDCoMKgSGVuY2Ugd2h5IG5vdMKgIGRlZmlu
ZSBzdWNoIHZhcmlhYmxlcyB0byBtYXAgb3V0IHRoZSB0b3RhbCBzY29wZSBvZiB0aGUgV0FOIElQ
IGNvbmZpZ3VyYXRpb24gZm9yIHRoZSBDRS7CoMKgIFRoZSB2YXJpYWJsZXMgZG8gbm90IHByb2hp
Yml0IGEgQ0UgdG8gaW1wbGVtZW50IGF1dG9tYXRlZCBXQU4gSVB2NiBhZGRyZXNzIGFjcXVpc2l0
aW9uL2NyZWF0aW9uLsKgwqAgSWYgeW91IHdhbnQgYW5kIGlmIHdlIGRlZmluZSBDb25jZXB0dWFs
IENvbmZpZ3VyYXRpb24gVmFyaWFibGVzLCB3ZSBjYW4gYWRkIGEgbGluZSB0aGF0IHNheXMgdGhl
IFdBTiBJUHY2IGFkZHJlc3MgYWNxdWlzaXRpb24gaXMgYXV0b21hdGVkIGFuZCBzb21lIGd1aWRl
bGluZXMgYXJlIHByb3ZpZGVkIGZvciBhdXRvbWF0YSBpbiBzZWN0aW9uIDQuNC4zLiA8DQoNCjxi
aHM+IE5vLiBUaGVyZSBpcyBubyBleHBlY3RhdGlvbiB0aGF0IHRoZSB1c2VyIG9mIHRoZSBDRSB3
aWxsIGNvbmZpZ3VyZSBpdCBmb3IgYSBzcGVjaWZpYyBXQU4uIFRoZSBleHBlY3RhdGlvbiBpcyB0
aGF0IHRoZSBDRSB3aWxsIGhhdmUgYSBmYWN0b3J5IGRlZmF1bHQgY29uZmlndXJhdGlvbiwgYmVj
YXVzZSB0aGUgcGFydGljdWxhciBDRSBpcyBpbnRlbmRlZCBmb3IgdXNlIGluIGEgcGFydGljdWxh
ciBlbnZpcm9ubWVudC4gVGhlc2UgY29uZmlndXJhdGlvbiBleGNlcHRpb25zIGFyZSBub3QgaW50
ZW5kZWQgZm9yIFdBTi1jbHVlbGVzcyBDRSByb3V0ZXJzLiBUaGV5IGFyZSBpbnRlbmRlZCBmb3Ig
V0FOLXNwZWNpZmljIENFIHJvdXRlcnMuDQoNClRoZSBleGNlcHRpb25zIGdpdmUgdGhlIHNwZWNp
ZmllcnMgb2YgV0FOLXNwZWNpZmljIENFIHJvdXRlcnMgKENhYmxlTGFicywgQkJGLCAzR1BQKSB0
aGUgZnJlZWRvbSB0byBub3QgaW1wbGVtZW50IGNlcnRhaW4gY2FwYWJpbGl0aWVzLCBiZWNhdXNl
IHRoZWlyIFdBTiBpcyBrbm93biB0byB0aGVtLiBUaGUgZXhjZXB0aW9ucyBuZWVkIHRvIGJlIGln
bm9yZWQgYnkgV0FOLWNsdWVsZXNzIHJvdXRlciBpbXBsZW1lbnRlcnMuIFdBTi1jbHVlbGVzcyBD
RSByb3V0ZXJzIGhhdmUgbm8gbmVlZCBmb3IgdGhlc2UgY29uZmlndXJhdGlvbiBjb25jZXB0cy4g
SSBkb24ndCB3YW50IHRvIGdpdmUgdGhlIGltcHJlc3Npb24gdGhhdCBzdWNoIGNvbmZpZ3VyYWJp
bGl0eSBpcyBuZWVkZWQgb3IgZW5jb3VyYWdlZCBpbiBXQU4tY2x1ZWxlc3MgQ0Ugcm91dGVycy4g
T2YgY291cnNlIHRoZXkgYXJlIG5vdCBwcm9oaWJpdGVkIGZyb20gb2ZmZXJpbmcgc3VjaCBjb25m
aWd1cmF0aW9uLCBidXQgYnkgcmVtYWluaW5nIHNpbGVudCBvbiB0aGUgdG9waWMsIHN1Y2ggY29u
ZmlndXJhYmlsaXR5IGlzIG5laXRoZXIgZW5jb3VyYWdlZCBub3IgcHJvaGliaXRlZC4gIDwvYmhz
DQpCYXJiYXJhDQo=

From shemant@cisco.com  Tue Nov 29 12:16:18 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 093CF21F8B40 for ; Tue, 29 Nov 2011 12:16:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.565
X-Spam-Level: 
X-Spam-Status: No, score=-6.565 tagged_above=-999 required=5 tests=[AWL=0.033,  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 Dye77epzQpEA for ; Tue, 29 Nov 2011 12:16:14 -0800 (PST)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id E704A21F8B30 for ; Tue, 29 Nov 2011 12:16:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=8169; q=dns/txt; s=iport; t=1322597774; x=1323807374; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=5SZuSz5RGPsH1Ro7MR3npPaqyLQibbdJ6FiMjUoPYas=; b=Ro80z771rstYSal0wY7BzINpoTdue1afcIB51sAJOE3NAtFwlHNBrhtZ 5JJM+NFaq7L5w5kFZXNm6vkZl0szPSvfxIlhlyyHUneC9pK9wAxukR+ED vMVFvoENGHaMk2aZlgakrLzDvNm9kyUPm8PiZ9pDP+8fcokytauTFFiGL o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqMAAEM81U6tJXHB/2dsb2JhbABDgk2YGpAYgQWBcgEBAQQSAQkRA0kQAgEIEQQBAQsGFwEGAUUJCAIEEwgaoHQBnjaKO2MEiCeeXQ
X-IronPort-AV: E=Sophos;i="4.69,592,1315180800"; d="scan'208,217";a="39789887"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-6.cisco.com with ESMTP; 29 Nov 2011 20:16:13 +0000
Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id pATKGDfs030428;  Tue, 29 Nov 2011 20:16:13 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 29 Nov 2011 14:16:13 -0600
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCAED3.BDA14A80"
Date: Tue, 29 Nov 2011 14:16:12 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3036CDBF8@XMB-RCD-109.cisco.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] 6rd Sunsetting
Thread-Index: AQHMo2zkiVaVmflTEk2DrH6PcFso4ZWtESmAgAF9cYCAACEjgIABVu+AgAfhuoCAADwWAIAAAlqAgABDmgCAAIAigIAAtJqAgABw8oCAAQQ29YAIFkuwgAAdbVCAAAjLgIAAFeR6gADeqmCAABIVMIAACGCA
References:   <68DAB112-6E32-45FE-9AB7-A34E64898F60@cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30354436E@XMB-RCD-109.cisco.com> <750BF7861EBBE048B3E648B4BB6E8F4F20DC41F6@crexc50p>  <252D3DEA-FF09-42C8-959E-8A7205D9DE67@townsley.net>  <20111122133612.GH71280@Space.Net> <4ECC10C9.5010607@gmail.com> <20111123080113.GI71280@Space.Net>     <5B6B2B64C9FE2A489045EEEADDAFF2C3036CD912@XMB-RCD-109.cisco.com> <54ADF508-673A-47EE-AF1F-ABAF68A72D0A@huawei.com>  
From: "Hemant Singh (shemant)" 
To: "Tina TSOU" 
X-OriginalArrivalTime: 29 Nov 2011 20:16:13.0188 (UTC) FILETIME=[BDC29440:01CCAED3]
Cc: Alexandre Cassen , v6ops@ietf.org, Claire Cheng 
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 29 Nov 2011 20:16:18 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CCAED3.BDA14A80
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Tina,

=20

At least all router CLI that I have dealt with such as Cisco routers has
an administrative distance argument that is used to assign higher
priority.  =20

=20

Hemant

=20

From: Tina TSOU [mailto:Tina.Tsou.Zouting@huawei.com]=20
Sent: Tuesday, November 29, 2011 2:45 PM
To: Hemant Singh (shemant)
Cc: v6ops@ietf.org; gert@space.net; Alexandre Cassen; Claire Cheng
Subject: RE: [v6ops] 6rd Sunsetting

=20

Yes I have similar example in mind too......I am only unclear as to
where we provide the preference for the route over native
interface........in the code or there is a configuration command to
assign higher priority to the native route.

=20


------_=_NextPart_001_01CCAED3.BDA14A80
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Tina,
 
At least all router CLI that I have dealt with such as Cisco routers =
has an administrative distance argument that is used to assign higher =
priority.   
 
Hemant
 
From:=
 =
Tina TSOU [mailto:Tina.Tsou.Zouting@huawei.com] 
Sent: =
Tuesday, November 29, 2011 2:45 PM
To: Hemant Singh =
(shemant)
Cc: v6ops@ietf.org; gert@space.net; Alexandre =
Cassen; Claire Cheng
Subject: RE: [v6ops] 6rd =
Sunsetting
 
Yes I have similar example in mind too……I am only unclear =
as to where we provide the preference for the route over native =
interface……..in the code or there is a configuration command =
to assign higher priority to the native =
route.
 

------_=_NextPart_001_01CCAED3.BDA14A80--

From brian.e.carpenter@gmail.com  Tue Nov 29 12:29:39 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 121381F0CD6 for ; Tue, 29 Nov 2011 12:29:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level: 
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eXfRMbyqN7cm for ; Tue, 29 Nov 2011 12:29:38 -0800 (PST)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 440D11F0CD3 for ; Tue, 29 Nov 2011 12:29:38 -0800 (PST)
Received: by bkbzv15 with SMTP id zv15so11556586bkb.31 for ; Tue, 29 Nov 2011 12:29:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=SH6QArFh7ChPWA0TqhIMyoBiVwvdd3llwhz3cSgsrw4=; b=ZmTrej+m/6qwY5KYhiJYOXsilDBadPoCB0Sn01/utThb6N2Hk314+jCfWcRUcMy0Ob jLsR1q6FlHKPXDGTzIT7tAXRhe5am2wnTpxn8Iii+SFcIKgWn8meE40FEAgCEnxs4IOH 4VdhBReMMUKMaxYffjRIoo48bblLNV5IGiWhg=
Received: by 10.205.121.1 with SMTP id ga1mr49443947bkc.60.1322598577297; Tue, 29 Nov 2011 12:29:37 -0800 (PST)
Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id e8sm39444371bkd.7.2011.11.29.12.29.34 (version=SSLv3 cipher=OTHER); Tue, 29 Nov 2011 12:29:36 -0800 (PST)
Message-ID: <4ED540AB.1010506@gmail.com>
Date: Wed, 30 Nov 2011 09:29:31 +1300
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: "STARK, BARBARA H" 
References: <2963F168-45CB-4042-8238-56DF538B0543@gmail.com><2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org><1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz><5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com><1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz><750BF7861EBBE048B3E648B4BB6E8F4F2106F69E@crexc50p>		<5B6B2B64C9FE2A489045EEEADDAFF2C3036CD910@XMB-RCD-109.cisco.com>	<750BF7861EBBE048B3E648B4BB6E8F4F212EB1F3@crexc50p>	<5B6B2B64C9FE2A489045EEEADDAFF2C3036CDB13@XMB-RCD-109.cisco.com> <750BF7861EBBE048B3E648B4BB6E8F4F212EB3BC@crexc50p>
In-Reply-To: <750BF7861EBBE048B3E648B4BB6E8F4F212EB3BC@crexc50p>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-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: Tue, 29 Nov 2011 20:29:39 -0000

On 2011-11-30 08:31, STARK, BARBARA H wrote:
>> Specifically, the rfc6204bis document has augmented bullets
>> from rfc6204 with text such as =E2=80=9Cunless configured to
>> acquire a global address=E2=80=A6=E2=80=9D.  So the user of a CE is go=
ing
>> to configure the CE for one specific WAN IP address
>> acquisition behavior.  Thus  why not sell out the
>> Conceptual Configuration Variables?  Further the unnumbered
>> model is buried in text of rfc6204 and rfc6204bis and
>> increasingly we see new readers of the documents having
>> missed the unnumbered model.   Hence why not  define such
>> variables to map out the total scope of the WAN IP
>> configuration for the CE.   The variables do not prohibit a
>> CE to implement automated WAN IPv6 address
>> acquisition/creation.   If you want and if we define
>> Conceptual Configuration Variables, we can add a line that
>> says the WAN IPv6 address acquisition is automated and some
>> guidelines are provided for automata in section 4.4.3. <
>=20
>  No. There is no expectation that the user of the CE
> will configure it for a specific WAN. The expectation is that
> the CE will have a factory default configuration, because the
> particular CE is intended for use in a particular
> environment. These configuration exceptions are not intended
> for WAN-clueless CE routers. They are intended for
> WAN-specific CE routers.

Conceptually, it seems to me that we (the IETF) should model a
WAN-specific CE as a WAN-clueless CE with one or more
WAN-specific modules attached; the two aspects should be
described separately.

That is not to say that vendors will implement WAN-specific
devices in this way, but it seems like the only way to make the
spec future-proof.

   Brian

>=20
> The exceptions give the specifiers of WAN-specific CE routers
> (CableLabs, BBF, 3GPP) the freedom to not implement certain
> capabilities, because their WAN is known to them. The
> exceptions need to be ignored by WAN-clueless router
> implementers. WAN-clueless CE routers have no need for these
> configuration concepts. I don't want to give the impression
> that such configurability is needed or encouraged in
> WAN-clueless CE routers. Of course they are not prohibited
> from offering such configuration, but by remaining silent on
> the topic, such configurability is neither encouraged nor
> prohibited.  
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF73421F8B49 for ; Tue, 29 Nov 2011 13:12:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.015
X-Spam-Level: 
X-Spam-Status: No, score=-3.015 tagged_above=-999 required=5 tests=[AWL=-0.017, 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 T8ftE6jtskXC for ; Tue, 29 Nov 2011 13:12:46 -0800 (PST)
Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3155721F8B59 for ; Tue, 29 Nov 2011 13:12:46 -0800 (PST)
Received: by eear51 with SMTP id r51so1506380eea.31 for ; Tue, 29 Nov 2011 13:12:45 -0800 (PST)
Received: by 10.216.137.86 with SMTP id x64mr153524wei.2.1322601165219; Tue, 29 Nov 2011 13:12:45 -0800 (PST)
Received: from ams-townsley-8712.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id gd6sm43981359wbb.1.2011.11.29.13.12.42 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 29 Nov 2011 13:12:44 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-67-696578005
From: Mark Townsley 
In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3036CDBF8@XMB-RCD-109.cisco.com>
Date: Tue, 29 Nov 2011 22:12:41 +0100
Message-Id: <936D4BE5-E946-4F66-9070-4D5AD647FF4E@townsley.net>
References:   <68DAB112-6E32-45FE-9AB7-A34E64898F60@cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30354436E@XMB-RCD-109.cisco.com> <750BF7861EBBE048B3E648B4BB6E8F4F20DC41F6@crexc50p>  <252D3DEA-FF09-42C8-959E-8A7205D9DE67@townsley.net>  <20111122133612.GH71280@Space.Net> <4ECC10C9.5010607@gmail.com> <20111123080113.GI71280@Space.Net>     <5B6B2B64C9FE2A489045EEEADDAFF2C3036CD912@XMB-RCD-109.cisco.com> <54ADF508-673A-47EE-AF1F-ABAF68A72D0A@huawei.com>   <5B6B2B64C9FE2A489045EEEADDAFF2C3036CDBF8@XMB-RCD-109.cisco.com>
To: "Hemant Singh (shemant)" 
X-Mailer: Apple Mail (2.1084)
Cc: Alexandre Cassen , v6ops@ietf.org, Claire Cheng 
Subject: Re: [v6ops] 6rd Sunsetting
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 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, 29 Nov 2011 21:12:50 -0000

--Apple-Mail-67-696578005
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


On Nov 29, 2011, at 9:16 PM, Hemant Singh (shemant) wrote:

> Tina,
> =20
> At least all router CLI that I have dealt with such as Cisco routers =
has an administrative distance argument that is used to assign higher =
priority.  =20

As much as IOS config is a wonderful playground for anything and =
everything one might ever think of configuring, the more important point =
is to get the defaults nailed down.

IMHO, the default tie-breaker between two otherwise identical routes =
would specify native with a lower distance than virtual (e.g. 6rd). This =
means that the native path would be preferred over virtual, everything =
else being equal. That said, a more-specific prefix still wins over =
these metrics, and source-based routing even above destination-based =
forwarding so that the correct interface is chosen in multihoming =
situations.=20

- Mark=20

> =20
> Hemant
> =20
> From: Tina TSOU [mailto:Tina.Tsou.Zouting@huawei.com]=20
> Sent: Tuesday, November 29, 2011 2:45 PM
> To: Hemant Singh (shemant)
> Cc: v6ops@ietf.org; gert@space.net; Alexandre Cassen; Claire Cheng
> Subject: RE: [v6ops] 6rd Sunsetting
> =20
> Yes I have similar example in mind too=85=85I am only unclear as to =
where we provide the preference for the route over native =
interface=85=85..in the code or there is a configuration command to =
assign higher priority to the native route.
> =20
>=20
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


--Apple-Mail-67-696578005
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252


On Nov 29, 2011, at 9:16 PM, Hemant =
Singh (shemant) wrote:

Tina,
At =
least all router CLI that I have dealt with such as Cisco routers has an =
administrative distance argument that is used to assign higher priority. =
  

As much as IOS config is a wonderful playground for anything and =
everything one might ever think of configuring, the more important point =
is to get the defaults nailed down.

IMHO, the =
default tie-breaker between two otherwise identical routes would specify =
native with a lower distance than virtual (e.g. 6rd). This means that =
the native path would be preferred over virtual, everything else being =
equal. That said, a more-specific prefix still wins over these metrics, =
and source-based routing even above destination-based forwarding so that =
the correct interface is chosen in multihoming =
situations. 

- =
Mark 

Yes I have =
similar example in mind too=85=85I am only unclear as to where we =
provide the preference for the route over native interface=85=85..in the =
code or there is a configuration command to assign higher priority to =
the native route.

Content-Type: multipart/alternative; boundary=20cf303bff66dcd28204b2f4b483
Cc: "v6ops@ietf.org" 
Subject: [v6ops]  I-D Action: draft-ietf-v6ops-6204bis-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, 30 Nov 2011 14:39:44 -0000

--20cf303bff66dcd28204b2f4b483
Content-Type: text/plain; charset=UTF-8

Barbara,
>  No. There is no expectation that the user of the CE will configure
it for a specific WAN. The expectation is that the CE will have a >factory
default configuration, because the particular CE is intended for use in a
particular environment. These configuration exceptions are >not intended
for WAN-clueless CE routers. They are intended for WAN-specific CE routers.
>
> The exceptions give the specifiers of WAN-specific CE routers (CableLabs,
BBF, 3GPP) the freedom to not implement certain capabilities, >because
their WAN is known to them. The exceptions need to be ignored by
WAN-clueless router implementers. WAN-clueless CE routers >have no need for
these configuration concepts. I don't want to give the impression that such
configurability is needed or encouraged in WAN->clueless CE routers. Of
course they are not prohibited from offering such configuration, but by
remaining silent on the topic, such >configurability is neither encouraged
nor prohibited.   Barbara

CE in the retail have a factory default configuration, but it doesn't
exactly mean it is intended for use in a particular environment. Tender
project, yes, but not retail products.  In addition to Cable and Broadband,
lots of CE routers in the market have a USB port and support 3G as well.

Take my own implementation as an example. My previous implementation sends
RS, waits for an RA, and then initiates DHCP Solicitation. It is good with
6204 (I assume it is since it passed UNH-IOL in May).  I was later informed
by a BGN vendor that I should also follow the flow addressed in TR-124i2
since it is a MUST (WAN.IPv6.1), and my implementation has an IOT issue
with their BNG.  It only hands out RA after a DHCPv6 process, so I update
my implementation, and my current implementation does RS and DHCP
Solicitation in parallel. I believe my current implementation is still good
with 6204 (It once again passed UNH-IOL in this Nov.)

It is a retail CE router device (with USB, supporting 3G).  Can I keep my
previous implementation and ignore the IOT since it looks ok under
6204/6204bis?  If there is no logo program, maybe we're cool. However, if
there is a logo program and the program is gonna based on a particular RFC
or document, then I believe it will be great if we can make it clear.  If I
can get the logo with my previous implementation, then it means here is the
logo on the giftbox but it cannot promise the device works for an end
user's environment!?

I'm not an expert here but as a vendor, I just want to highlight the
concerns we faced. Devices vendors may hesitate to move into IPv6 if they
don't have a clear guideline to follow.


Hans


-- 
Instead of following the fashion, we lead it through.

--20cf303bff66dcd28204b2f4b483
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



Barbara,
> <bhs> No. There is no expectation that the u=
ser of the CE will configure it for a specific WAN. The expectation is that=
 the CE will have a >factory default configuration, because the particul=
ar CE is intended for use in a particular environment. These configuration =
exceptions are >not intended for WAN-clueless CE routers. They are inten=
ded for WAN-specific CE routers.

>
> The exceptions give the specifiers of WAN-specific CE routers =
(CableLabs, BBF, 3GPP) the freedom to not implement certain capabilities, &=
gt;because their WAN is known to them. The exceptions need to be ignored by=
 WAN-clueless router implementers. WAN-clueless CE routers >have no need=
 for these configuration concepts. I don't want to give the impression =
that such configurability is needed or encouraged in WAN->clueless CE ro=
uters. Of course they are not prohibited from offering such configuration, =
but by remaining silent on the topic, such >configurability is neither e=
ncouraged nor prohibited. =C2=A0</bhs

> Barbara

CE in the retail have a factory default configuration, =
but it doesn't exactly mean it is intended for use in a particular envi=
ronment. Tender project, yes, but not retail products. =C2=A0In addition to=
 Cable and Broadband, lots of CE routers in the market have a USB port and =
support 3G as well.


Take my own implementation as an example. My previous implementation se=
nds RS, waits for an RA, and then initiates DHCP Solicitation. It is good w=
ith 6204 (I assume it is since it passed UNH-IOL in May). =C2=A0I was later=
 informed by a BGN vendor that I should also follow the flow addressed in T=
R-124i2 since it is a MUST (WAN.IPv6.1), and my implementation has an IOT i=
ssue with their BNG. =C2=A0It only hands out RA after a DHCPv6 process, so =
I update my implementation, and my current implementation does RS and DHCP =
Solicitation in parallel. I believe my current implementation is still good=
 with 6204 (It once again passed UNH-IOL in this Nov.)


It is a retail CE router device (with USB, supporting 3G). =C2=A0Can I =
keep my previous implementation and ignore the IOT since it looks ok under =
6204/6204bis? =C2=A0If there is no logo program, maybe we're cool. Howe=
ver, if there is a logo program and the program is gonna based on a particu=
lar RFC or document, then I believe it will be great if we can make it clea=
r. =C2=A0If I can get the logo with my previous implementation, then it mea=
ns here is the logo on the giftbox but it cannot promise the device works f=
or an end user's environment!? 


I'm not an expert here but as a vendor, I just want to highlight th=
e concerns we faced. Devices vendors may hesitate to move into IPv6 if they=
 don't have a clear guideline to follow. 


Hans



-- 
Instead of following the fashion, we lead it through.


--20cf303bff66dcd28204b2f4b483--

From lorenzo@google.com  Wed Nov 30 11:00:30 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF63121F8C14 for ; Wed, 30 Nov 2011 11:00:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.53
X-Spam-Level: 
X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.446, 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 rL4Da-2imPkj for ; Wed, 30 Nov 2011 11:00:30 -0800 (PST)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 20BE521F8C13 for ; Wed, 30 Nov 2011 11:00:26 -0800 (PST)
Received: by ywm13 with SMTP id 13so1176754ywm.31 for ; Wed, 30 Nov 2011 11:00:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=qwxnKaIy41gAk8NywtVPJ4WUUvYRj7o786zao6WHqP0=; b=VjMzJxv7pUP9j7f3frM3UlwDeZm/G5NQx7kX1ZR/D5ooFOJG3HxhAGrrUfXJ23WDzw nJof5OcfsNNV2l8K3phw==
Received: by 10.236.75.167 with SMTP id z27mr6029153yhd.53.1322679625659; Wed, 30 Nov 2011 11:00:25 -0800 (PST)
Received: by 10.236.75.167 with SMTP id z27mr6029132yhd.53.1322679625519; Wed, 30 Nov 2011 11:00:25 -0800 (PST)
MIME-Version: 1.0
Received: by 10.150.202.14 with HTTP; Wed, 30 Nov 2011 11:00:04 -0800 (PST)
In-Reply-To: 
References:    <2963F168-45CB-4042-8238-56DF538B0543@gmail.com>   <2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz> <8AF88A07-C1C5-4CD9-9E87-9D0F26504641@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99477F1@SRVHKE02.rdm.cz> 
From: Lorenzo Colitti 
Date: Wed, 30 Nov 2011 11:00:04 -0800
Message-ID: 
To: jouni korhonen 
Content-Type: multipart/alternative; boundary=20cf3005dde63b10d304b2f8595a
X-System-Of-Record: true
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-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, 30 Nov 2011 19:00:30 -0000

--20cf3005dde63b10d304b2f8595a
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Nov 29, 2011 at 03:54, jouni korhonen wrote:

> And then a reference to pd-exclude (I guess this was already accepted..
> once it is out as an RFC).
>

Why do we need pd-exclude again? It seems to me that it's just a way of
giving a mobile terminal information that it already has (via the PD and
the O bit in the RA). Am I missing something?

--20cf3005dde63b10d304b2f8595a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Tue, Nov 29, 2011 at 03:54, jouni korhonen <jouni.nospam@=
gmail.com> wrote:



And then a reference to pd-exclude (I guess this was alre=
ady accepted.. once it is out as an RFC).

=

Why do we need pd-exclude again? It seems to me that it's just a w=
ay of giving a mobile terminal information that it already has (via the PD =
and the O bit in the RA). Am I missing something?





--20cf3005dde63b10d304b2f8595a--

From roberta.maglione@telecomitalia.it  Wed Nov 30 11:14:20 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DCD81F0C4E for ; Wed, 30 Nov 2011 11:14:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.14
X-Spam-Level: *
X-Spam-Status: No, score=1.14 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QUPLhG6Cveza for ; Wed, 30 Nov 2011 11:14:19 -0800 (PST)
Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id 66C831F0C38 for ; Wed, 30 Nov 2011 11:14:19 -0800 (PST)
Received: from GRFHUB703BA020.griffon.local (10.188.101.113) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 30 Nov 2011 20:14:16 +0100
Received: from GRFMBX704BA020.griffon.local ([10.188.101.16]) by GRFHUB703BA020.griffon.local ([10.188.101.113]) with mapi; Wed, 30 Nov 2011 20:14:16 +0100
From: Maglione Roberta 
To: Lorenzo Colitti , jouni korhonen 
Date: Wed, 30 Nov 2011 20:12:45 +0100
Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
Thread-Index: Acyvkms5G0RJLDYJSiKMcxSXQF2FFAAAZ8mA
Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE3EBC900F88@GRFMBX704BA020.griffon.local>
References:    <2963F168-45CB-4042-8238-56DF538B0543@gmail.com>   <2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz> <8AF88A07-C1C5-4CD9-9E87-9D0F26504641@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99477F1@SRVHKE02.rdm.cz> , 
In-Reply-To: 
Accept-Language: en-US, it-IT
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, it-IT
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-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, 30 Nov 2011 19:14:20 -0000

I support the Jouni=92s proposal to add a reference to pd-exclude.
Pd-exclude was initially designed for mobile scenario but it is actually ap=
plicable to broadband case too in the scenario where you want to represent =
one customer with a single prefix,  instead of using one  prefix for the li=
nk between the delegating router and the requesting router and another pref=
ix for the home network network.

PD-exclude allows to delegate a single prefix to the home network and than =
use the PD-exclude option to tell the CPE to exclude a portion of the deleg=
ated prefix and use it to number the point to point WAN link between the re=
questing router (CPE) and the delegated router (BNG)


Regards,
Roberta

________________________________________
From: v6ops-bounces@ietf.org [v6ops-bounces@ietf.org] On Behalf Of Lorenzo =
Colitti [lorenzo@google.com]
Sent: Wednesday, November 30, 2011 8:00 PM
To: jouni korhonen
Cc: v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt

On Tue, Nov 29, 2011 at 03:54, jouni korhonen > wrote:
And then a reference to pd-exclude (I guess this was already accepted.. onc=
e it is out as an RFC).

Why do we need pd-exclude again? It seems to me that it's just a way of giv=
ing a mobile terminal information that it already has (via the PD and the O=
 bit in the RA). Am I missing something?

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per=
sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall=
a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb=
iate ricevuto questo documento per errore siete cortesemente pregati di dar=
ne immediata comunicazione al mittente e di provvedere alla sua distruzione=
, Grazie.

This e-mail and any attachments is confidential and may contain privileged =
information intended for the addressee(s) only. Dissemination, copying, pri=
nting or use by anybody else is unauthorised. If you are not the intended r=
ecipient, please delete this message and any attachments and advise the sen=
der by return e-mail, Thanks.


From lorenzo@google.com  Wed Nov 30 11:24:25 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FFD721F8A71 for ; Wed, 30 Nov 2011 11:24:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.593
X-Spam-Level: 
X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.383, 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 QNfWnPuGVlkv for ; Wed, 30 Nov 2011 11:24:24 -0800 (PST)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id C6D7B21F8532 for ; Wed, 30 Nov 2011 11:24:24 -0800 (PST)
Received: by ywm13 with SMTP id 13so1205291ywm.31 for ; Wed, 30 Nov 2011 11:24:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=OO/zHXLQo7xZxgZev67EvvMopwcLK365d1i5Ziew/4k=; b=PY4oi5Q8lIbH3RYlKjojmMgBLMzIxaOWRNVs7a2Os/BH3MhBChfZHEIWYmmwd80tpH ATGGjD6ftobrUDyffQZA==
Received: by 10.236.183.52 with SMTP id p40mr6213781yhm.19.1322681064389; Wed, 30 Nov 2011 11:24:24 -0800 (PST)
Received: by 10.236.183.52 with SMTP id p40mr6213757yhm.19.1322681064275; Wed, 30 Nov 2011 11:24:24 -0800 (PST)
MIME-Version: 1.0
Received: by 10.150.202.14 with HTTP; Wed, 30 Nov 2011 11:24:03 -0800 (PST)
In-Reply-To: <282BBE8A501E1F4DA9C775F964BB21FE3EBC900F88@GRFMBX704BA020.griffon.local>
References:    <2963F168-45CB-4042-8238-56DF538B0543@gmail.com>   <2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz> <8AF88A07-C1C5-4CD9-9E87-9D0F26504641@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99477F1@SRVHKE02.rdm.cz>   <282BBE8A501E1F4DA9C775F964BB21FE3EBC900F88@GRFMBX704BA020.griffon.local>
From: Lorenzo Colitti 
Date: Thu, 1 Dec 2011 04:24:03 +0900
Message-ID: 
To: Maglione Roberta 
Content-Type: multipart/alternative; boundary=bcaec52c5ea9fcc02c04b2f8aeb4
X-System-Of-Record: true
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-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, 30 Nov 2011 19:24:25 -0000

--bcaec52c5ea9fcc02c04b2f8aeb4
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Dec 1, 2011 at 04:12, Maglione Roberta <
roberta.maglione@telecomitalia.it> wrote:

> PD-exclude allows to delegate a single prefix to the home network and than
> use the PD-exclude option to tell the CPE to exclude a portion of the
> delegated prefix and use it to number the point to point WAN link between
> the requesting router (CPE) and the delegated router (BNG)
>

I still don't see why this is needed.

If you're using the /64 to number the link between the BNG and the CE
router, then the CE router already knows that the /64 is assigned to that
link via the O bit in the prefix information option in the RA.

If you're not using the /64 to number the link between the BNG and the CE,
then you can make the link unnumbered and you don't need to exclude
anything.

So...?

--bcaec52c5ea9fcc02c04b2f8aeb4
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Thu, Dec 1, 2011 at 04:12, Maglione Roberta <=
span dir=3D"ltr"><r=
oberta.maglione@telecomitalia.it> wrote:


PD-exclude allows to delegate a single prefix to the home network and than =
use the PD-exclude option to tell the CPE to exclude a portion of the deleg=
ated prefix and use it to number the point to point WAN link between the re=
questing router (CPE) and the delegated router (BNG)




I still don't see why this is needed.<=
/div>

If you're using the /64 to number the link bet=
ween the BNG and the CE router, then the CE router already knows that the /=
64 is assigned to that link via the O bit in the prefix information option =
in the RA.




If you're not using the /64 to number the link betw=
een the BNG and the CE, then you can make the link unnumbered and you don&#=
39;t need to exclude anything.

So...?



--bcaec52c5ea9fcc02c04b2f8aeb4--

From roberta.maglione@telecomitalia.it  Wed Nov 30 11:32:27 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 222E311E8096 for ; Wed, 30 Nov 2011 11:32:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.955
X-Spam-Level: 
X-Spam-Status: No, score=0.955 tagged_above=-999 required=5 tests=[AWL=0.185,  BAYES_05=-1.11, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2qNnylnWJkFm for ; Wed, 30 Nov 2011 11:32:26 -0800 (PST)
Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id 0437911E8093 for ; Wed, 30 Nov 2011 11:32:25 -0800 (PST)
Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 30 Nov 2011 20:32:22 +0100
Received: from GRFMBX704BA020.griffon.local ([10.188.101.16]) by grfhub701ba020.griffon.local ([10.188.101.111]) with mapi; Wed, 30 Nov 2011 20:32:21 +0100
From: Maglione Roberta 
To: Lorenzo Colitti 
Date: Wed, 30 Nov 2011 20:31:29 +0100
Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
Thread-Index: Acyvlax0RrOOo3qZRvS68CtujW1BuAAAPwC3
Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE3EBC900F89@GRFMBX704BA020.griffon.local>
References:    <2963F168-45CB-4042-8238-56DF538B0543@gmail.com>   <2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz> <8AF88A07-C1C5-4CD9-9E87-9D0F26504641@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99477F1@SRVHKE02.rdm.cz>   <282BBE8A501E1F4DA9C775F964BB21FE3EBC900F88@GRFMBX704BA020.griffon.local>, 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-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, 30 Nov 2011 19:32:27 -0000

> If you're not using the /64 to number the link between the BNG and the CE=
, then you can make the link unnumbered and you don't need to exclude
> anything.

You could make the link unnumbered, but the WAN link could also be numbered=
.
If you refer to BBF TR-187, TR-177, TR-124i2  you can see that both unnumbe=
red and numbered  are considered valid scenarios.
PD-exclude is need in order to build the WAN numbered scenario with a singl=
e  prefix.

Roberta

________________________________________
From: Lorenzo Colitti [lorenzo@google.com]
Sent: Wednesday, November 30, 2011 8:24 PM
To: Maglione Roberta
Cc: jouni korhonen; v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt

On Thu, Dec 1, 2011 at 04:12, Maglione Roberta > wrote:
PD-exclude allows to delegate a single prefix to the home network and than =
use the PD-exclude option to tell the CPE to exclude a portion of the deleg=
ated prefix and use it to number the point to point WAN link between the re=
questing router (CPE) and the delegated router (BNG)

I still don't see why this is needed.

If you're using the /64 to number the link between the BNG and the CE route=
r, then the CE router already knows that the /64 is assigned to that link v=
ia the O bit in the prefix information option in the RA.

If you're not using the /64 to number the link between the BNG and the CE, =
then you can make the link unnumbered and you don't need to exclude anythin=
g.

So...?

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per=
sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall=
a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb=
iate ricevuto questo documento per errore siete cortesemente pregati di dar=
ne immediata comunicazione al mittente e di provvedere alla sua distruzione=
, Grazie.

This e-mail and any attachments is confidential and may contain privileged =
information intended for the addressee(s) only. Dissemination, copying, pri=
nting or use by anybody else is unauthorised. If you are not the intended r=
ecipient, please delete this message and any attachments and advise the sen=
der by return e-mail, Thanks.


From lorenzo@google.com  Wed Nov 30 11:34:35 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9A6F11E8096 for ; Wed, 30 Nov 2011 11:34:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.641
X-Spam-Level: 
X-Spam-Status: No, score=-102.641 tagged_above=-999 required=5 tests=[AWL=0.335, 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 tTX7akqqBHYF for ; Wed, 30 Nov 2011 11:34:35 -0800 (PST)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id D26F811E8093 for ; Wed, 30 Nov 2011 11:34:34 -0800 (PST)
Received: by yenl2 with SMTP id l2so1082222yen.31 for ; Wed, 30 Nov 2011 11:34:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=qnKu1ET7RuCuplYyeN7S+fKhDHmd/WGWsyKKG5usg9M=; b=OV4Ma59k3Ejsmr1I3/gV2i4lO+HfhSUAghXuvmZ9vCdsyrN7ljZ9BS3ty8gLITFlPV eUztxRToIodPeEodJ2eQ==
Received: by 10.236.75.167 with SMTP id z27mr6286424yhd.53.1322681674211; Wed, 30 Nov 2011 11:34:34 -0800 (PST)
Received: by 10.236.75.167 with SMTP id z27mr6286410yhd.53.1322681674105; Wed, 30 Nov 2011 11:34:34 -0800 (PST)
MIME-Version: 1.0
Received: by 10.150.202.14 with HTTP; Wed, 30 Nov 2011 11:34:13 -0800 (PST)
In-Reply-To: <282BBE8A501E1F4DA9C775F964BB21FE3EBC900F89@GRFMBX704BA020.griffon.local>
References:    <2963F168-45CB-4042-8238-56DF538B0543@gmail.com>   <2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz> <8AF88A07-C1C5-4CD9-9E87-9D0F26504641@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99477F1@SRVHKE02.rdm.cz>   <282BBE8A501E1F4DA9C775F964BB21FE3EBC900F88@GRFMBX704BA020.griffon.local>  <282BBE8A501E1F4DA9C775F964BB21FE3EBC900F89@GRFMBX704BA020.griffon.local>
From: Lorenzo Colitti 
Date: Wed, 30 Nov 2011 11:34:13 -0800
Message-ID: 
To: Maglione Roberta 
Content-Type: multipart/alternative; boundary=20cf3005dde656048804b2f8d353
X-System-Of-Record: true
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-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, 30 Nov 2011 19:34:35 -0000

--20cf3005dde656048804b2f8d353
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Nov 30, 2011 at 11:31, Maglione Roberta <
roberta.maglione@telecomitalia.it> wrote:

> > If you're not using the /64 to number the link between the BNG and the
> CE, then you can make the link unnumbered and you don't need to exclude
> > anything.
>
> You could make the link unnumbered, but the WAN link could also be
> numbered.
> If you refer to BBF TR-187, TR-177, TR-124i2  you can see that both
> unnumbered and numbered  are considered valid scenarios.
> PD-exclude is need in order to build the WAN numbered scenario with a
> single  prefix.
>

As I stated in the part of my email that you didn't quote: in the numbered
scenario, why can't you use the O bit in the RA to indicate that the prefix
is assigned to the link? Then the CE router will have all the information
that it needs.

--20cf3005dde656048804b2f8d353
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Wed, Nov 30, 2011 at 11:31, Maglione Roberta =
<=
roberta.maglione@telecomitalia.it> wrote:



> If you're not using the /64 to number the link b=
etween the BNG and the CE, then you can make the link unnumbered and you do=
n't need to exclude

> anything.




You could make the link unnumbered, but the WAN link could also be nu=
mbered.

If you refer to BBF TR-187, TR-177, TR-124i2 =A0you can see that both unnum=
bered and numbered =A0are considered valid scenarios.

PD-exclude is need in order to build the WAN numbered scenario with a singl=
e =A0prefix.

As I stated in the part of=
 my email that you didn't quote: in the numbered scenario, why can'=
t you use the O bit in the RA to indicate that the prefix is assigned to th=
e link? Then the CE router will have all the information that it needs.




--20cf3005dde656048804b2f8d353--

From ales.vizdal@t-mobile.cz  Wed Nov 30 12:03:43 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B1DA1F0C51 for ; Wed, 30 Nov 2011 12:03:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.577
X-Spam-Level: 
X-Spam-Status: No, score=-0.577 tagged_above=-999 required=5 tests=[AWL=0.372,  BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, 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 DrkR6HpaMGnI for ; Wed, 30 Nov 2011 12:03:40 -0800 (PST)
Received: from mailhub1.t-mobile.cz (mailhub1.t-mobile.cz [62.141.0.149]) by ietfa.amsl.com (Postfix) with ESMTP id 0194D21F84AB for ; Wed, 30 Nov 2011 12:03:40 -0800 (PST)
Received: from srvhk503.rdm.cz (unknown [10.246.143.95]) by mailhub1.t-mobile.cz (Postfix) with ESMTP id E08BB285820; Wed, 30 Nov 2011 21:03:38 +0100 (CET)
Received: from SRVHKE02.rdm.cz ([fe80::94ce:8456:f6fa:86a8]) by srvhk503.rdm.cz ([fe80::a0bc:fdcc:adf9:5f66%12]) with mapi; Wed, 30 Nov 2011 21:03:38 +0100
From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= 
To: Lorenzo Colitti , jouni korhonen 
Date: Wed, 30 Nov 2011 21:03:37 +0100
Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
Thread-Index: AcyvklMIau++0ix4QAmH3+OQiXH0IAABtWTw
Message-ID: <1808340F7EC362469DDFFB112B37E2FCC5E999F158@SRVHKE02.rdm.cz>
References:    <2963F168-45CB-4042-8238-56DF538B0543@gmail.com>   <2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz> <8AF88A07-C1C5-4CD9-9E87-9D0F26504641@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99477F1@SRVHKE02.rdm.cz>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_1808340F7EC362469DDFFB112B37E2FCC5E999F158SRVHKE02rdmcz_"
MIME-Version: 1.0
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-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, 30 Nov 2011 20:03:43 -0000

--_000_1808340F7EC362469DDFFB112B37E2FCC5E999F158SRVHKE02rdmcz_
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable

Hi Lorenzo,

the Prefix Delegation RFC 3633 states a limitation in section 12.1 that 'a =
prefix delegated to
a requesting router cannot be used by the delegating router'. This limitati=
on is a problem for
the 3GPP case where they have standardised that the link prefix (/64) and t=
he delegated prefix
shall be aggregatable to a single prefix. So, you can use pd-exclude to sig=
nal the prefix part
in use.

Cheers,
Ales

From: Lorenzo Colitti [mailto:lorenzo@google.com]
Sent: Wednesday, November 30, 2011 8:00 PM
To: jouni korhonen
Cc: V=EDzdal Ale=B9; v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt

On Tue, Nov 29, 2011 at 03:54, jouni korhonen > wrote:
And then a reference to pd-exclude (I guess this was already accepted.. onc=
e it is out as an RFC).

Why do we need pd-exclude again? It seems to me that it's just a way of giv=
ing a mobile terminal information that it already has (via the PD and the O=
 bit in the RA). Am I missing something?

--_000_1808340F7EC362469DDFFB112B37E2FCC5E999F158SRVHKE02rdmcz_
Content-Type: text/html; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable


Hi Lorenz=
o,
 
the Prefix Delegation RFC 3633 states a li=
mitation in section 12.1 that 'a prefix delegated to 
=

a requesting router cannot be used by the deleg=
ating router'. This limitation is a problem for 
the 3GPP case where they have standardised that the =
link prefix (/64) and the delegated prefix 
shall be aggregatable to a single prefix. So, you can u=
se pd-exclude to signal the prefix part 
in use. 
 
Cheers,
Ales
 
From: Lorenzo Colitti [mailto:lorenzo@goo=
gle.com] 
Sent: Wednesday, November 30, 2011 8:00 PM
To: jouni korhonen
Cc: V=EDzdal Ale=B9; v6ops@ietf.org
Subjec=
t: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
 
On Tue, Nov 29, 2011 at 03:54, jouni korhonen <jouni.nospam@gmail.com> wrote:
And then a reference to pd-exclude (I gue=
ss this was already accepted.. once it is out as an RFC).
 
Why do we need pd-exclude again? It seems to me that it's just a way=
 of giving a mobile terminal information that it already has (via the PD an=
d the O bit in the RA). Am I missing something?
=

--_000_1808340F7EC362469DDFFB112B37E2FCC5E999F158SRVHKE02rdmcz_--

From lorenzo@google.com  Wed Nov 30 12:12:29 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53C2A21F8B7A for ; Wed, 30 Nov 2011 12:12:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.528
X-Spam-Level: 
X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.148, 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 AuHiaISqP9-5 for ; Wed, 30 Nov 2011 12:12:28 -0800 (PST)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id C0B6721F8B78 for ; Wed, 30 Nov 2011 12:12:28 -0800 (PST)
Received: by yenl2 with SMTP id l2so1125482yen.31 for ; Wed, 30 Nov 2011 12:12:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=e8/0U80UrW7uCYOh/4yj9WiUzmFjSJjxLCY/uNAIUGw=; b=rMX5mGAhNnmRGR6ae3WYtlnJeJLp0NQhhPi1mIoKx6P9xA95Kpp6qLD9m9j6O8U1Xz 60e5zErslxeKR9USyU0A==
Received: by 10.236.75.167 with SMTP id z27mr6560953yhd.53.1322683948266; Wed, 30 Nov 2011 12:12:28 -0800 (PST)
Received: by 10.236.75.167 with SMTP id z27mr6560934yhd.53.1322683948156; Wed, 30 Nov 2011 12:12:28 -0800 (PST)
MIME-Version: 1.0
Received: by 10.150.202.14 with HTTP; Wed, 30 Nov 2011 12:12:07 -0800 (PST)
In-Reply-To: <1808340F7EC362469DDFFB112B37E2FCC5E999F158@SRVHKE02.rdm.cz>
References:    <2963F168-45CB-4042-8238-56DF538B0543@gmail.com>   <2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz> <8AF88A07-C1C5-4CD9-9E87-9D0F26504641@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99477F1@SRVHKE02.rdm.cz>   <1808340F7EC362469DDFFB112B37E2FCC5E999F158@SRVHKE02.rdm.cz>
From: Lorenzo Colitti 
Date: Wed, 30 Nov 2011 12:12:07 -0800
Message-ID: 
To: =?UTF-8?B?VsOtemRhbCBBbGXFoQ==?= 
Content-Type: multipart/alternative; boundary=20cf3005dde6e1470404b2f95a50
X-System-Of-Record: true
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-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, 30 Nov 2011 20:12:29 -0000

--20cf3005dde6e1470404b2f95a50
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Nov 30, 2011 at 12:03, V=C3=ADzdal Ale=C5=A1  wrote:

> the Prefix Delegation RFC 3633 states a limitation in section 12.1 that '=
a
> prefix delegated to a requesting router cannot be used by the delegating
> router'. This limitation is a problem for the 3GPP case where they have
> standardised that the link prefix (/64) and the delegated prefix shall be
> aggregatable to a single prefix. So, you can use pd-exclude to signal the
> prefix part
>
> in use.
>

Fine, but if the only problem is that text, then why do we need a new
option? Can't we just say somewhere that if the part of the prefix is used
to connect the requesting router to the network, then the network MUST
signal that to the client using some other means such as an RA?

--20cf3005dde6e1470404b2f95a50
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On Wed, Nov 30, 2011 at 12:03, V=C3=ADzdal Ale=
=C5=A1 <ale=
s.vizdal@t-mobile.cz> wrote:



the Prefix Delegation RFC 3633 states a limitation in=
 section 12.1 that 'a prefix delegated to=C2=A0a requesting router cannot be used by the delegating router'. This lim=
itation is a problem for=C2=A0the 3GPP case where =
they have standardised that the link prefix (/64) and the delegated prefix=
=C2=A0shall be aggregatable to a single prefix. So=
, you can use pd-exclude to signal the prefix part



in use.
<=
/div>

Fine, but if the only problem is that=
 text, then why do we need a new option? Can't we just say somewhere th=
at if the part of the prefix is used to connect the requesting router to th=
e network, then the network MUST signal that to the client using some other=
 means such as an RA?=C2=A0





--20cf3005dde6e1470404b2f95a50--

From roberta.maglione@telecomitalia.it  Wed Nov 30 12:27:00 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05D9911E8093 for ; Wed, 30 Nov 2011 12:27:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.013
X-Spam-Level: *
X-Spam-Status: No, score=1.013 tagged_above=-999 required=5 tests=[AWL=-0.057,  BAYES_05=-1.11, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, 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 o-w1BkqBYOeB for ; Wed, 30 Nov 2011 12:26:59 -0800 (PST)
Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id 4405711E809A for ; Wed, 30 Nov 2011 12:26:59 -0800 (PST)
Received: from grfhub704ba020.griffon.local (10.188.101.117) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 30 Nov 2011 21:26:56 +0100
Received: from GRFMBX704BA020.griffon.local ([10.188.101.16]) by grfhub704ba020.griffon.local ([10.188.101.117]) with mapi; Wed, 30 Nov 2011 21:26:57 +0100
From: Maglione Roberta 
To: Lorenzo Colitti , =?Windows-1252?Q?V=EDzdal_Ale=9A?= 
Date: Wed, 30 Nov 2011 21:25:06 +0100
Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
Thread-Index: AcyvnG7+t18xGi+tQPOZC2KNlFu2UQAAbcEN
Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE3EBC900F8C@GRFMBX704BA020.griffon.local>
References:    <2963F168-45CB-4042-8238-56DF538B0543@gmail.com>   <2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz> <8AF88A07-C1C5-4CD9-9E87-9D0F26504641@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99477F1@SRVHKE02.rdm.cz>   <1808340F7EC362469DDFFB112B37E2FCC5E999F158@SRVHKE02.rdm.cz>, 
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="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-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, 30 Nov 2011 20:27:00 -0000

Why using =93some other means=94 when  you can achieve this behavior with j=
ust a single DHCPv6 message with DHCPv6-PD plus PD-exclude option?

________________________________________
From: v6ops-bounces@ietf.org [v6ops-bounces@ietf.org] On Behalf Of Lorenzo =
Colitti [lorenzo@google.com]
Sent: Wednesday, November 30, 2011 9:12 PM
To: V=EDzdal Ale=9A
Cc: v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt

On Wed, Nov 30, 2011 at 12:03, V=EDzdal Ale=9A > wrote:
the Prefix Delegation RFC 3633 states a limitation in section 12.1 that 'a =
prefix delegated to a requesting router cannot be used by the delegating ro=
uter'. This limitation is a problem for the 3GPP case where they have stand=
ardised that the link prefix (/64) and the delegated prefix shall be aggreg=
atable to a single prefix. So, you can use pd-exclude to signal the prefix =
part
in use.

Fine, but if the only problem is that text, then why do we need a new optio=
n? Can't we just say somewhere that if the part of the prefix is used to co=
nnect the requesting router to the network, then the network MUST signal th=
at to the client using some other means such as an RA?

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per=
sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall=
a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb=
iate ricevuto questo documento per errore siete cortesemente pregati di dar=
ne immediata comunicazione al mittente e di provvedere alla sua distruzione=
, Grazie.

This e-mail and any attachments is confidential and may contain privileged =
information intended for the addressee(s) only. Dissemination, copying, pri=
nting or use by anybody else is unauthorised. If you are not the intended r=
ecipient, please delete this message and any attachments and advise the sen=
der by return e-mail, Thanks.


From ichiroumakino@gmail.com  Wed Nov 30 12:31:40 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68EB721F84CC for ; Wed, 30 Nov 2011 12:31:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.099
X-Spam-Level: 
X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.100, 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 0t06IXYn-rW6 for ; Wed, 30 Nov 2011 12:31:39 -0800 (PST)
Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9576221F8922 for ; Wed, 30 Nov 2011 12:31:39 -0800 (PST)
Received: by eear51 with SMTP id r51so728850eea.31 for ; Wed, 30 Nov 2011 12:31:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=gyYqm58Zt+oYJHufOJwSIFXrrTmip+0KFUgBysKfjvE=; b=A1LuJvx3/9NN1zAC1j+gTxvcSc2vrFnc4H+Aw0bJNsIf119vZhSIXO078JV2ta2dF4 EmAyKKiqVqH6g7jga1hM146mb06NqtdXzQzm+OwBSncOz5unvVtIM7fUPr6C6ebCmIJm bMDmZAWF/36tZJiBrNRLqPUQko/Bq4MAjOQqs=
Received: by 10.227.60.14 with SMTP id n14mr1610846wbh.5.1322685098548; Wed, 30 Nov 2011 12:31:38 -0800 (PST)
Received: from dhcp-10-61-108-3.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id ca18sm905032wib.13.2011.11.30.12.31.36 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 30 Nov 2011 12:31:37 -0800 (PST)
Sender: Ole Troan 
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=windows-1252
From: Ole Troan 
In-Reply-To: <282BBE8A501E1F4DA9C775F964BB21FE3EBC900F8C@GRFMBX704BA020.griffon.local>
Date: Wed, 30 Nov 2011 21:31:34 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <23C35D5A-EC84-4249-B93A-71DEC865F895@employees.org>
References:    <2963F168-45CB-4042-8238-56DF538B0543@gmail.com>   <2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz> <8AF88A07-C1C5-4CD9-9E87-9D0F26504641@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99477F1@SRVHKE02.rdm.cz>   <1808340F7EC362469DDFFB112B37E2FCC5E999F158@SRVHKE02.rdm.cz>,  <282BBE8A501E1F4DA9C775F964BB21FE3EBC900F8C@GRFMBX704BA020.griffon.local>
To: Maglione Roberta 
X-Mailer: Apple Mail (2.1084)
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-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, 30 Nov 2011 20:31:40 -0000

> Why using =93some other means=94 when  you can achieve this behavior =
with just a single DHCPv6 message with DHCPv6-PD plus PD-exclude option?

indeed. you can't first delegate a prefix to some other administrative =
entity, and then expect to be able to take that back without explicit =
signaling. if you did this through an RA or a routing protocol or some =
other means, you still have to handle potential conflicts. signalling up =
front is a lot cleaner and it avoids the corner cases.

cheers,
Ole


> From: v6ops-bounces@ietf.org [v6ops-bounces@ietf.org] On Behalf Of =
Lorenzo Colitti [lorenzo@google.com]
> Sent: Wednesday, November 30, 2011 9:12 PM
> To: V=EDzdal Ale=9A
> Cc: v6ops@ietf.org
> Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
>=20
> On Wed, Nov 30, 2011 at 12:03, V=EDzdal Ale=9A =
> wrote:
> the Prefix Delegation RFC 3633 states a limitation in section 12.1 =
that 'a prefix delegated to a requesting router cannot be used by the =
delegating router'. This limitation is a problem for the 3GPP case where =
they have standardised that the link prefix (/64) and the delegated =
prefix shall be aggregatable to a single prefix. So, you can use =
pd-exclude to signal the prefix part
> in use.
>=20
> Fine, but if the only problem is that text, then why do we need a new =
option? Can't we just say somewhere that if the part of the prefix is =
used to connect the requesting router to the network, then the network =
MUST signal that to the client using some other means such as an RA?
>=20
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente =
alle persone indicate. La diffusione, copia o qualsiasi altra azione =
derivante dalla conoscenza di queste informazioni sono rigorosamente =
vietate. Qualora abbiate ricevuto questo documento per errore siete =
cortesemente pregati di darne immediata comunicazione al mittente e di =
provvedere alla sua distruzione, Grazie.
>=20
> This e-mail and any attachments is confidential and may contain =
privileged information intended for the addressee(s) only. =
Dissemination, copying, printing or use by anybody else is unauthorised. =
If you are not the intended recipient, please delete this message and =
any attachments and advise the sender by return e-mail, Thanks.
>=20
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


From brian.e.carpenter@gmail.com  Wed Nov 30 12:58:08 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF8C1F0C7C for ; Wed, 30 Nov 2011 12:58:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level: 
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bDl0q-AC0faL for ; Wed, 30 Nov 2011 12:58:06 -0800 (PST)
Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 06F021F0C74 for ; Wed, 30 Nov 2011 12:58:03 -0800 (PST)
Received: by eabm6 with SMTP id m6so1389956eab.31 for ; Wed, 30 Nov 2011 12:58:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=LUZNbRTXXhZftqW6DzbyWFCOfZlxC5uyBBUxSrX/MI4=; b=u/ZvK22Czz3HeWP05Fkl3RCS2Y8DGm/ez26lj1g8vuEVWK1VoWl4A3RZnTUGKfi5xk FpCkmmtzo+/9KLNinQykQkUogtKf4ocyBLwNFLc8hR5zHVPR9Ql7IujZppnSNaMZ1QUo Yt78jYBKsY2Aw6ZiOCekRIYO42Zaq+OZZb0jA=
Received: by 10.216.137.141 with SMTP id y13mr86295wei.12.1322686683053; Wed, 30 Nov 2011 12:58:03 -0800 (PST)
Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id v10sm921492wiy.23.2011.11.30.12.58.00 (version=SSLv3 cipher=OTHER); Wed, 30 Nov 2011 12:58:02 -0800 (PST)
Message-ID: <4ED698D6.5090305@gmail.com>
Date: Thu, 01 Dec 2011 09:57:58 +1300
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Lorenzo Colitti 
References: 			<2963F168-45CB-4042-8238-56DF538B0543@gmail.com>			<2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org>	<1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz>	<5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com>	<1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz>	<8AF88A07-C1C5-4CD9-9E87-9D0F26504641@employees.org>	<1808340F7EC362469DDFFB112B37E2FCC5E99477F1@SRVHKE02.rdm.cz>			<1808340F7EC362469DDFFB112B37E2FCC5E999F158@SRVHKE02.rdm.cz> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-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, 30 Nov 2011 20:58:08 -0000

On 2011-12-01 09:12, Lorenzo Colitti wrote:
> On Wed, Nov 30, 2011 at 12:03, V=C3=ADzdal Ale=C5=A1  wrote:
>=20
>> the Prefix Delegation RFC 3633 states a limitation in section 12.1 tha=
t 'a
>> prefix delegated to a requesting router cannot be used by the delegati=
ng
>> router'. This limitation is a problem for the 3GPP case where they hav=
e
>> standardised that the link prefix (/64) and the delegated prefix shall=
 be
>> aggregatable to a single prefix. So, you can use pd-exclude to signal =
the
>> prefix part in use.
>>
>=20
> Fine, but if the only problem is that text, then why do we need a new
> option? Can't we just say somewhere that if the part of the prefix is u=
sed
> to connect the requesting router to the network, then the network MUST
> signal that to the client using some other means such as an RA?

Better would be for someone who visits 3GPP land to persuade them to remo=
ve
that restriction, which is obviously annoying.

    Brian


From lorenzo@google.com  Wed Nov 30 13:12:31 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28C5B1F0C5F for ; Wed, 30 Nov 2011 13:12:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.693
X-Spam-Level: 
X-Spam-Status: No, score=-102.693 tagged_above=-999 required=5 tests=[AWL=0.283, 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 43HpcS34VvJi for ; Wed, 30 Nov 2011 13:12:30 -0800 (PST)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9ADCE1F0C38 for ; Wed, 30 Nov 2011 13:12:30 -0800 (PST)
Received: by yenl9 with SMTP id l9so47510yen.31 for ; Wed, 30 Nov 2011 13:12:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=OzLtdPILbcrla2M31XXgD2PQZgAZg/pmzgnGkeUa61Q=; b=Sij3ZrlueHX1AUVg7v7cesqxvJwrVvklTZav2pNBT6SHy2NiVaXl4JC+hMNT86KssV XFjKopWrzP3mB7/TXNkA==
Received: by 10.236.75.167 with SMTP id z27mr6971596yhd.53.1322687550261; Wed, 30 Nov 2011 13:12:30 -0800 (PST)
Received: by 10.236.75.167 with SMTP id z27mr6971568yhd.53.1322687550132; Wed, 30 Nov 2011 13:12:30 -0800 (PST)
MIME-Version: 1.0
Received: by 10.150.202.14 with HTTP; Wed, 30 Nov 2011 13:12:08 -0800 (PST)
In-Reply-To: <282BBE8A501E1F4DA9C775F964BB21FE3EBC900F8C@GRFMBX704BA020.griffon.local>
References:    <2963F168-45CB-4042-8238-56DF538B0543@gmail.com>   <2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz> <8AF88A07-C1C5-4CD9-9E87-9D0F26504641@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99477F1@SRVHKE02.rdm.cz>   <1808340F7EC362469DDFFB112B37E2FCC5E999F158@SRVHKE02.rdm.cz>  <282BBE8A501E1F4DA9C775F964BB21FE3EBC900F8C@GRFMBX704BA020.griffon.local>
From: Lorenzo Colitti 
Date: Wed, 30 Nov 2011 13:12:08 -0800
Message-ID: 
To: Maglione Roberta 
Content-Type: multipart/alternative; boundary=20cf3005dde693114e04b2fa3169
X-System-Of-Record: true
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-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, 30 Nov 2011 21:12:31 -0000

--20cf3005dde693114e04b2fa3169
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Wed, Nov 30, 2011 at 12:25, Maglione Roberta <
roberta.maglione@telecomitalia.it> wrote:

> Why using =93some other means=94 when  you can achieve this behavior with=
 just
> a single DHCPv6 message with DHCPv6-PD plus PD-exclude option?
>

Because you need the RA anyway. If the RA is sufficient, then we don't have
to define another option and manufacturers don't have to implement it.

--20cf3005dde693114e04b2fa3169
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


On Wed, Nov 30, 2011 at 12:25, Maglione Roberta =
<=
roberta.maglione@telecomitalia.it> wrote:


Why using =93some other means=94 when =A0you can achieve this behavior with=
 just a single DHCPv6 message with DHCPv6-PD plus PD-exclude option?

Because you need the RA anyway. If the RA is =
sufficient, then we don't have to define another option and manufacture=
rs don't have to implement it.





--20cf3005dde693114e04b2fa3169--

From lorenzo@google.com  Wed Nov 30 13:17:41 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3750111E80DA for ; Wed, 30 Nov 2011 13:17:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.719
X-Spam-Level: 
X-Spam-Status: No, score=-102.719 tagged_above=-999 required=5 tests=[AWL=0.257, 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 7i-cJFSkgHdn for ; Wed, 30 Nov 2011 13:17:40 -0800 (PST)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 994B711E80D7 for ; Wed, 30 Nov 2011 13:17:40 -0800 (PST)
Received: by ywm13 with SMTP id 13so1335861ywm.31 for ; Wed, 30 Nov 2011 13:17:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=jFdmFJI9mIfZmmU0KrVSzLJkM7YE2aGh5oiHoU+LYxk=; b=G9J89Jmvp/rKVCIzpG2H08K12xQVLpfAVKOhqHQonpWLz4PivYTtGBuh932DeUHBGi xt8zr0TZQ/RPModwYfBw==
Received: by 10.236.183.52 with SMTP id p40mr6998212yhm.19.1322687860263; Wed, 30 Nov 2011 13:17:40 -0800 (PST)
Received: by 10.236.183.52 with SMTP id p40mr6998187yhm.19.1322687860151; Wed, 30 Nov 2011 13:17:40 -0800 (PST)
MIME-Version: 1.0
Received: by 10.150.202.14 with HTTP; Wed, 30 Nov 2011 13:17:19 -0800 (PST)
In-Reply-To: <23C35D5A-EC84-4249-B93A-71DEC865F895@employees.org>
References:    <2963F168-45CB-4042-8238-56DF538B0543@gmail.com>   <2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz> <8AF88A07-C1C5-4CD9-9E87-9D0F26504641@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99477F1@SRVHKE02.rdm.cz>   <1808340F7EC362469DDFFB112B37E2FCC5E999F158@SRVHKE02.rdm.cz>  <282BBE8A501E1F4DA9C775F964BB21FE3EBC900F8C@GRFMBX704BA020.griffon.local> <23C35D5A-EC84-4249-B93A-71DEC865F895@employees.org>
From: Lorenzo Colitti 
Date: Wed, 30 Nov 2011 13:17:19 -0800
Message-ID: 
To: Ole Troan 
Content-Type: multipart/alternative; boundary=bcaec52c5ea90d975704b2fa444b
X-System-Of-Record: true
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-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, 30 Nov 2011 21:17:41 -0000

--bcaec52c5ea90d975704b2fa444b
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Wed, Nov 30, 2011 at 12:31, Ole Troan  wrote:

> > Why using =93some other means=94 when  you can achieve this behavior wi=
th
> just a single DHCPv6 message with DHCPv6-PD plus PD-exclude option?
>
> indeed. you can't first delegate a prefix to some other administrative
> entity, and then expect to be able to take that back without explicit
> signaling. if you did this through an RA or a routing protocol or some
> other means, you still have to handle potential conflicts. signalling up
> front is a lot cleaner and it avoids the corner cases.
>

Signaling exclusion by itself is not sufficient, because you also need to
tell the requesting router where the excluded prefix is.

For example, what is an implementation supposed to do if it gets a PD of
2001:db8:1::/56 with an exclude for 2001:db8:1:2::/64? What's the next hop
for 2001:db8:1:2::/64? Discard? It needs to know, at least for the purpose
of sending unreachables.

Since you need to tell the requesting router where the prefix is anyway,
you might as well just tell it where it is and not bother to tell it that
the prefix is excluded.

--bcaec52c5ea90d975704b2fa444b
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


On Wed, Nov 30, 2011 at 12:31, Ole Troan <otroan@employees.org=
> wrote:



> Why using =93some other means=94 when =A0you can ach=
ieve this behavior with just a single DHCPv6 message with DHCPv6-PD plus PD=
-exclude option?




indeed. you can't first delegate a prefix to some other administr=
ative entity, and then expect to be able to take that back without explicit=
 signaling. if you did this through an RA or a routing protocol or some oth=
er means, you still have to handle potential conflicts. signalling up front=
 is a lot cleaner and it avoids the corner cases.




Signaling exclusion=A0by itself=A0is not s=
ufficient, because you also need to tell the requesting router where the ex=
cluded prefix is.

For example, what is an implemen=
tation supposed to do if it gets a PD of 2001:db8:1::/56 with an exclude fo=
r 2001:db8:1:2::/64? What's the next hop for=A02001:db8:1:2::/64? Disca=
rd? It needs to know, at least for the purpose of sending unreachables.



Since you need to tell the requesting router where the =
prefix is anyway, you might as well just tell it where it is and not bother=
 to tell it that the prefix is excluded.


--bcaec52c5ea90d975704b2fa444b--

From sarikaya2012@gmail.com  Wed Nov 30 15:22:09 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCB2621F8C09 for ; Wed, 30 Nov 2011 15:22:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.148
X-Spam-Level: 
X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 5Zlq4bOntz+c for ; Wed, 30 Nov 2011 15:22:08 -0800 (PST)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id A390021F8BFE for ; Wed, 30 Nov 2011 15:22:07 -0800 (PST)
Received: by ggnp4 with SMTP id p4so1461774ggn.31 for ; Wed, 30 Nov 2011 15:22:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=CbAkXS7AgxXPdbYiLAyRjJgQlVkEuCHb07RccRO1Gwk=; b=jikvBx5Q7ls4+Gt8HvkAvQSLvmKUDjIP8bTiSX3xzm2/WqLLiS6C4smVBmAkeJbuJW nW6cRevQ9awUTu3eh03mbGhzn8ehVjcY5haQp/kdN21/6GKnNvO/m5sLBKkXw414M67V aMqa/UuntIkIN6to5nF0IoeZmitBOxH2uvrL0=
MIME-Version: 1.0
Received: by 10.236.46.72 with SMTP id q48mr7777996yhb.80.1322695327259; Wed, 30 Nov 2011 15:22:07 -0800 (PST)
Received: by 10.236.191.228 with HTTP; Wed, 30 Nov 2011 15:22:07 -0800 (PST)
In-Reply-To: <282BBE8A501E1F4DA9C775F964BB21FE3EBC900F89@GRFMBX704BA020.griffon.local>
References:    <2963F168-45CB-4042-8238-56DF538B0543@gmail.com>   <2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz> <8AF88A07-C1C5-4CD9-9E87-9D0F26504641@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99477F1@SRVHKE02.rdm.cz>   <282BBE8A501E1F4DA9C775F964BB21FE3EBC900F88@GRFMBX704BA020.griffon.local>  <282BBE8A501E1F4DA9C775F964BB21FE3EBC900F89@GRFMBX704BA020.griffon.local>
Date: Wed, 30 Nov 2011 17:22:07 -0600
Message-ID: 
From: Behcet Sarikaya 
To: Maglione Roberta 
Content-Type: multipart/alternative; boundary=20cf303b428d209c3004b2fc0101
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.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: Wed, 30 Nov 2011 23:22:09 -0000

--20cf303b428d209c3004b2fc0101
Content-Type: text/plain; charset=ISO-8859-1

Hi Roberta,

You don't need to restrict yourself to the use of a single prefix in IPv6.
Usually DR can allocate many prefixes to the RR.

Besides these prefixes are used for some time and then not needed any more.
I don't see any reason to be so frugal.

Regards,

Behcet

On Wed, Nov 30, 2011 at 1:31 PM, Maglione Roberta <
roberta.maglione@telecomitalia.it> wrote:

> > If you're not using the /64 to number the link between the BNG and the
> CE, then you can make the link unnumbered and you don't need to exclude
> > anything.
>
> You could make the link unnumbered, but the WAN link could also be
> numbered.
> If you refer to BBF TR-187, TR-177, TR-124i2  you can see that both
> unnumbered and numbered  are considered valid scenarios.
> PD-exclude is need in order to build the WAN numbered scenario with a
> single  prefix.
>
> Roberta
>
> ________________________________________
> From: Lorenzo Colitti [lorenzo@google.com]
> Sent: Wednesday, November 30, 2011 8:24 PM
> To: Maglione Roberta
> Cc: jouni korhonen; v6ops@ietf.org
> Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
>
> On Thu, Dec 1, 2011 at 04:12, Maglione Roberta <
> roberta.maglione@telecomitalia.it>
> wrote:
> PD-exclude allows to delegate a single prefix to the home network and than
> use the PD-exclude option to tell the CPE to exclude a portion of the
> delegated prefix and use it to number the point to point WAN link between
> the requesting router (CPE) and the delegated router (BNG)
>
> I still don't see why this is needed.
>
> If you're using the /64 to number the link between the BNG and the CE
> router, then the CE router already knows that the /64 is assigned to that
> link via the O bit in the prefix information option in the RA.
>
> If you're not using the /64 to number the link between the BNG and the CE,
> then you can make the link unnumbered and you don't need to exclude
> anything.
>
> So...?
>
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle
> persone indicate. La diffusione, copia o qualsiasi altra azione derivante
> dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora
> abbiate ricevuto questo documento per errore siete cortesemente pregati di
> darne immediata comunicazione al mittente e di provvedere alla sua
> distruzione, Grazie.
>
> This e-mail and any attachments is confidential and may contain privileged
> information intended for the addressee(s) only. Dissemination, copying,
> printing or use by anybody else is unauthorised. If you are not the
> intended recipient, please delete this message and any attachments and
> advise the sender by return e-mail, Thanks.
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>

--20cf303b428d209c3004b2fc0101
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Roberta,

You don't need to restrict yourself to the use of a =
single prefix in IPv6. Usually DR can allocate many prefixes to the RR.
=

Besides these prefixes are used for some time and then not needed any m=
ore. I don't see any reason to be so frugal.


Regards,

Behcet

On Wed, Nov 30=
, 2011 at 1:31 PM, Maglione Roberta <roberta.maglione@telecomitalia.it&g=
t; wrote:


> If you're not using the /64 to num=
ber the link between the BNG and the CE, then you can make the link unnumbe=
red and you don't need to exclude


> anything.



You could make the link unnumbered, but the WAN link could also be numbered=
.

If you refer to BBF TR-187, TR-177, TR-124i2 =A0you can see that both unnum=
bered and numbered =A0are considered valid scenarios.

PD-exclude is need in order to build the WAN numbered scenario with a singl=
e =A0prefix.



Roberta



________________________________________

From: Lorenzo Colitti [lorenzo@google=
.com]

Sent: Wednesday, November 30, 2011 8:24 PM

To: Maglione Roberta

Cc: jouni korhonen; v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt



On Thu, Dec 1, 2011 at 04:12, Maglione Roberta <roberta.maglione@telecomitalia.it<mailt=
o:roberta.maglione@tel=
ecomitalia.it>> wrote:


PD-exclude allows to delegate a single prefix to the home network and than =
use the PD-exclude option to tell the CPE to exclude a portion of the deleg=
ated prefix and use it to number the point to point WAN link between the re=
questing router (CPE) and the delegated router (BNG)




I still don't see why this is needed.



If you're using the /64 to number the link between the BNG and the CE r=
outer, then the CE router already knows that the /64 is assigned to that li=
nk via the O bit in the prefix information option in the RA.



If you're not using the /64 to number the link between the BNG and the =
CE, then you can make the link unnumbered and you don't need to exclude=
 anything.



So...?



Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per=
sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall=
a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb=
iate ricevuto questo documento per errore siete cortesemente pregati di dar=
ne immediata comunicazione al mittente e di provvedere alla sua distruzione=
, Grazie.




This e-mail and any attachments is confidential and may contain privileged =
information intended for the addressee(s) only. Dissemination, copying, pri=
nting or use by anybody else is unauthorised. If you are not the intended r=
ecipient, please delete this message and any attachments and advise the sen=
der by return e-mail, Thanks.




_______________________________________________

v6ops mailing list

v6ops@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/v6ops





--20cf303b428d209c3004b2fc0101--

From roberta.maglione@telecomitalia.it  Wed Nov 30 15:28:36 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD9711E8097 for ; Wed, 30 Nov 2011 15:28:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.437
X-Spam-Level: 
X-Spam-Status: No, score=0.437 tagged_above=-999 required=5 tests=[AWL=0.556,  BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, 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 d11fLDmZwPFZ for ; Wed, 30 Nov 2011 15:28:35 -0800 (PST)
Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id F290C11E8094 for ; Wed, 30 Nov 2011 15:28:34 -0800 (PST)
Received: from GRFHUB702BA020.griffon.local (10.188.101.112) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 1 Dec 2011 00:28:31 +0100
Received: from GRFMBX704BA020.griffon.local ([10.188.101.16]) by GRFHUB702BA020.griffon.local ([10.188.101.112]) with mapi; Thu, 1 Dec 2011 00:28:31 +0100
From: Maglione Roberta 
To: "sarikaya@ieee.org" 
Date: Thu, 1 Dec 2011 00:26:41 +0100
Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
Thread-Index: AcyvtuHoRJfdtwZ7Q9mlJ/RdXDG5LgAAKJfE
Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE3EBC900F8D@GRFMBX704BA020.griffon.local>
References:    <2963F168-45CB-4042-8238-56DF538B0543@gmail.com>   <2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz> <8AF88A07-C1C5-4CD9-9E87-9D0F26504641@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99477F1@SRVHKE02.rdm.cz>   <282BBE8A501E1F4DA9C775F964BB21FE3EBC900F88@GRFMBX704BA020.griffon.local>  <282BBE8A501E1F4DA9C775F964BB21FE3EBC900F89@GRFMBX704BA020.griffon.local>, 
In-Reply-To: 
Accept-Language: en-US, it-IT
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, it-IT
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-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, 30 Nov 2011 23:28:36 -0000

Behcet,
   the reason why you may need to have a single prefix instead of two per c=
ustomer is in order to have just a single route to install on the BNG inste=
ad of two.

Regards
Roberta
________________________________________
From: Behcet Sarikaya [sarikaya2012@gmail.com]
Sent: Thursday, December 01, 2011 12:22 AM
To: Maglione Roberta
Cc: Lorenzo Colitti; v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt

Hi Roberta,

You don't need to restrict yourself to the use of a single prefix in IPv6. =
Usually DR can allocate many prefixes to the RR.

Besides these prefixes are used for some time and then not needed any more.=
 I don't see any reason to be so frugal.

Regards,

Behcet

On Wed, Nov 30, 2011 at 1:31 PM, Maglione Roberta > wrote:
> If you're not using the /64 to number the link between the BNG and the CE=
, then you can make the link unnumbered and you don't need to exclude
> anything.

You could make the link unnumbered, but the WAN link could also be numbered=
.
If you refer to BBF TR-187, TR-177, TR-124i2  you can see that both unnumbe=
red and numbered  are considered valid scenarios.
PD-exclude is need in order to build the WAN numbered scenario with a singl=
e  prefix.

Roberta

________________________________________
From: Lorenzo Colitti [lorenzo@google.com]
Sent: Wednesday, November 30, 2011 8:24 PM
To: Maglione Roberta
Cc: jouni korhonen; v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt

On Thu, Dec 1, 2011 at 04:12, Maglione Roberta >> wrote:
PD-exclude allows to delegate a single prefix to the home network and than =
use the PD-exclude option to tell the CPE to exclude a portion of the deleg=
ated prefix and use it to number the point to point WAN link between the re=
questing router (CPE) and the delegated router (BNG)

I still don't see why this is needed.

If you're using the /64 to number the link between the BNG and the CE route=
r, then the CE router already knows that the /64 is assigned to that link v=
ia the O bit in the prefix information option in the RA.

If you're not using the /64 to number the link between the BNG and the CE, =
then you can make the link unnumbered and you don't need to exclude anythin=
g.

So...?

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per=
sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall=
a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb=
iate ricevuto questo documento per errore siete cortesemente pregati di dar=
ne immediata comunicazione al mittente e di provvedere alla sua distruzione=
, Grazie.

This e-mail and any attachments is confidential and may contain privileged =
information intended for the addressee(s) only. Dissemination, copying, pri=
nting or use by anybody else is unauthorised. If you are not the intended r=
ecipient, please delete this message and any attachments and advise the sen=
der by return e-mail, Thanks.

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


Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per=
sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall=
a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb=
iate ricevuto questo documento per errore siete cortesemente pregati di dar=
ne immediata comunicazione al mittente e di provvedere alla sua distruzione=
, Grazie.

This e-mail and any attachments is confidential and may contain privileged =
information intended for the addressee(s) only. Dissemination, copying, pri=
nting or use by anybody else is unauthorised. If you are not the intended r=
ecipient, please delete this message and any attachments and advise the sen=
der by return e-mail, Thanks.


From sarikaya2012@gmail.com  Wed Nov 30 16:17:54 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EEE221F8B68 for ; Wed, 30 Nov 2011 16:17:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.098
X-Spam-Level: 
X-Spam-Status: No, score=-3.098 tagged_above=-999 required=5 tests=[AWL=-0.100, 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 r+DXpRd1WXMx for ; Wed, 30 Nov 2011 16:17:53 -0800 (PST)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC9E21F8B63 for ; Wed, 30 Nov 2011 16:17:53 -0800 (PST)
Received: by ghrr18 with SMTP id r18so1500204ghr.31 for ; Wed, 30 Nov 2011 16:17:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=RiaSPDN6P6uNt4an+uBKhAkL6uWDvSx1gb4OV0l52dI=; b=AbaG27ub3BewGPRLNzaniMTeESj3ARV6wmOnVWzaZJn2BMclEaDqNcAC1O68VZy8Po qPMTFDKWJw4K3LrN6NawFhjWGtSEi+XAaFUBINofWl2W6UjhhnkE4Wk+oLjV8G1Kv0X2 8bA2Vj04y6KB3j5sf2XHyZOgH0KCbjr4rFEl0=
MIME-Version: 1.0
Received: by 10.236.193.68 with SMTP id j44mr7735415yhn.97.1322698669589; Wed, 30 Nov 2011 16:17:49 -0800 (PST)
Received: by 10.236.191.228 with HTTP; Wed, 30 Nov 2011 16:17:49 -0800 (PST)
In-Reply-To: <282BBE8A501E1F4DA9C775F964BB21FE3EBC900F8D@GRFMBX704BA020.griffon.local>
References:    <2963F168-45CB-4042-8238-56DF538B0543@gmail.com>   <2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz> <8AF88A07-C1C5-4CD9-9E87-9D0F26504641@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99477F1@SRVHKE02.rdm.cz>   <282BBE8A501E1F4DA9C775F964BB21FE3EBC900F88@GRFMBX704BA020.griffon.local>  <282BBE8A501E1F4DA9C775F964BB21FE3EBC900F89@GRFMBX704BA020.griffon.local>  <282BBE8A501E1F4DA9C775F964BB21FE3EBC900F8D@GRFMBX704BA020.griffon.local>
Date: Wed, 30 Nov 2011 18:17:49 -0600
Message-ID: 
From: Behcet Sarikaya 
To: Maglione Roberta 
Content-Type: multipart/alternative; boundary=20cf305b0c6458838f04b2fcc80c
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.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: Thu, 01 Dec 2011 00:17:54 -0000

--20cf305b0c6458838f04b2fcc80c
Content-Type: text/plain; charset=ISO-8859-1

Roberta,

I don't see that a problem either because usually you can install an
aggregate route.

Regards,

Behcet

On Wed, Nov 30, 2011 at 5:26 PM, Maglione Roberta <
roberta.maglione@telecomitalia.it> wrote:

> Behcet,
>   the reason why you may need to have a single prefix instead of two per
> customer is in order to have just a single route to install on the BNG
> instead of two.
>
> Regards
> Roberta
> ________________________________________
> From: Behcet Sarikaya [sarikaya2012@gmail.com]
> Sent: Thursday, December 01, 2011 12:22 AM
> To: Maglione Roberta
> Cc: Lorenzo Colitti; v6ops@ietf.org
> Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
>
> Hi Roberta,
>
> You don't need to restrict yourself to the use of a single prefix in IPv6.
> Usually DR can allocate many prefixes to the RR.
>
> Besides these prefixes are used for some time and then not needed any
> more. I don't see any reason to be so frugal.
>
> Regards,
>
> Behcet
>
> On Wed, Nov 30, 2011 at 1:31 PM, Maglione Roberta <
> roberta.maglione@telecomitalia.it>
> wrote:
> > If you're not using the /64 to number the link between the BNG and the
> CE, then you can make the link unnumbered and you don't need to exclude
> > anything.
>
> You could make the link unnumbered, but the WAN link could also be
> numbered.
> If you refer to BBF TR-187, TR-177, TR-124i2  you can see that both
> unnumbered and numbered  are considered valid scenarios.
> PD-exclude is need in order to build the WAN numbered scenario with a
> single  prefix.
>
> Roberta
>
> ________________________________________
> From: Lorenzo Colitti [lorenzo@google.com]
> Sent: Wednesday, November 30, 2011 8:24 PM
> To: Maglione Roberta
> Cc: jouni korhonen; v6ops@ietf.org
> Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
>
> On Thu, Dec 1, 2011 at 04:12, Maglione Roberta <
> roberta.maglione@telecomitalia.it > roberta.maglione@telecomitalia.it>>> wrote:
> PD-exclude allows to delegate a single prefix to the home network and than
> use the PD-exclude option to tell the CPE to exclude a portion of the
> delegated prefix and use it to number the point to point WAN link between
> the requesting router (CPE) and the delegated router (BNG)
>
> I still don't see why this is needed.
>
> If you're using the /64 to number the link between the BNG and the CE
> router, then the CE router already knows that the /64 is assigned to that
> link via the O bit in the prefix information option in the RA.
>
> If you're not using the /64 to number the link between the BNG and the CE,
> then you can make the link unnumbered and you don't need to exclude
> anything.
>
> So...?
>
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle
> persone indicate. La diffusione, copia o qualsiasi altra azione derivante
> dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora
> abbiate ricevuto questo documento per errore siete cortesemente pregati di
> darne immediata comunicazione al mittente e di provvedere alla sua
> distruzione, Grazie.
>
> This e-mail and any attachments is confidential and may contain privileged
> information intended for the addressee(s) only. Dissemination, copying,
> printing or use by anybody else is unauthorised. If you are not the
> intended recipient, please delete this message and any attachments and
> advise the sender by return e-mail, Thanks.
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>
>
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle
> persone indicate. La diffusione, copia o qualsiasi altra azione derivante
> dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora
> abbiate ricevuto questo documento per errore siete cortesemente pregati di
> darne immediata comunicazione al mittente e di provvedere alla sua
> distruzione, Grazie.
>
> This e-mail and any attachments is confidential and may contain privileged
> information intended for the addressee(s) only. Dissemination, copying,
> printing or use by anybody else is unauthorised. If you are not the
> intended recipient, please delete this message and any attachments and
> advise the sender by return e-mail, Thanks.
>
>

--20cf305b0c6458838f04b2fcc80c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Roberta,

I don't see that a problem either because usually you c=
an install an aggregate route.

Regards,

Behcet

On Wed, Nov 30, 2011 at 5:26 PM, Maglione Roberta <rober=
ta.maglione@telecomitalia.it> wrote:


Behcet,

 =A0 the reason why you may need to have a single prefix instead of two per=
 customer is in order to have just a single route to install on the BNG ins=
tead of two.



Regards

Roberta

________________________________________

From: Behcet Sarikaya [sarikaya20=
12@gmail.com]

Sent: Thursday, December 01, 2011 12:22 AM

To: Maglione Roberta

Cc: Lorenzo Colitti; v6ops@ietf.org

Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis=
-03.txt




Hi Roberta,



You don't need to restrict yourself to the use of a single prefix in IP=
v6. Usually DR can allocate many prefixes to the RR.



Besides these prefixes are used for some time and then not needed any more.=
 I don't see any reason to be so frugal.



Regards,



Behcet




On Wed, Nov 30, 2011 at 1:31 PM, Maglione Roberta &=
lt;roberta.maglione@te=
lecomitalia.it<mailto:roberta.maglione@telecomitalia.it>> wrote:


> If you're not using the /64 to number the link between the BNG and=
 the CE, then you can make the link unnumbered and you don't need to ex=
clude

> anything.



You could make the link unnumbered, but the WAN link could also be numbered=
.

If you refer to BBF TR-187, TR-177, TR-124i2 =A0you can see that both unnum=
bered and numbered =A0are considered valid scenarios.

PD-exclude is need in order to build the WAN numbered scenario with a singl=
e =A0prefix.



Roberta



________________________________________


From: Lorenzo Colitti [lorenzo@=
google.com<mailto:lorenzo@goog=
le.com>]


Sent: Wednesday, November 30, 2011 8:24 PM

To: Maglione Roberta


Cc: jouni korhonen; v6ops@ietf.org<=
/a><mailto:v6ops@ietf.org>


Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis=
-03.txt




On Thu, Dec 1, 2011 at 04:12, Maglione Roberta <=
roberta.maglione@telec=
omitalia.it<mailto:roberta.maglione@telecomitalia.it><mailto:roberta.maglione@telecomitalia.it<=
mailto:roberta.maglion=
e@telecomitalia.it>>> wrote:


PD-exclude allows to delegate a single prefix to the home network and than =
use the PD-exclude option to tell the CPE to exclude a portion of the deleg=
ated prefix and use it to number the point to point WAN link between the re=
questing router (CPE) and the delegated router (BNG)




I still don't see why this is needed.



If you're using the /64 to number the link between the BNG and the CE r=
outer, then the CE router already knows that the /64 is assigned to that li=
nk via the O bit in the prefix information option in the RA.



If you're not using the /64 to number the link between the BNG and the =
CE, then you can make the link unnumbered and you don't need to exclude=
 anything.



So...?



Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per=
sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall=
a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb=
iate ricevuto questo documento per errore siete cortesemente pregati di dar=
ne immediata comunicazione al mittente e di provvedere alla sua distruzione=
, Grazie.




This e-mail and any attachments is confidential and may contain privileged =
information intended for the addressee(s) only. Dissemination, copying, pri=
nting or use by anybody else is unauthorised. If you are not the intended r=
ecipient, please delete this message and any attachments and advise the sen=
der by return e-mail, Thanks.




_______________________________________________

v6ops mailing list


v6ops@ietf.org<mailto:v6ops@ietf.org>

h=
ttps://www.ietf.org/mailman/listinfo/v6ops






Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per=
sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall=
a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb=
iate ricevuto questo documento per errore siete cortesemente pregati di dar=
ne immediata comunicazione al mittente e di provvedere alla sua distruzione=
, Grazie.




This e-mail and any attachments is confidential and may contain privileged =
information intended for the addressee(s) only. Dissemination, copying, pri=
nting or use by anybody else is unauthorised. If you are not the intended r=
ecipient, please delete this message and any attachments and advise the sen=
der by return e-mail, Thanks.








--20cf305b0c6458838f04b2fcc80c--

From roberta.maglione@telecomitalia.it  Wed Nov 30 17:19:57 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D63421F8B39 for ; Wed, 30 Nov 2011 17:19:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.298
X-Spam-Level: 
X-Spam-Status: No, score=0.298 tagged_above=-999 required=5 tests=[AWL=0.417,  BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, 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 2IwcBRtyuEn3 for ; Wed, 30 Nov 2011 17:19:56 -0800 (PST)
Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id 31A8E21F8B36 for ; Wed, 30 Nov 2011 17:19:56 -0800 (PST)
Received: from GRFHUB702BA020.griffon.local (10.188.101.112) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 1 Dec 2011 02:19:54 +0100
Received: from GRFMBX704BA020.griffon.local ([10.188.101.16]) by GRFHUB702BA020.griffon.local ([10.188.101.112]) with mapi; Thu, 1 Dec 2011 02:19:54 +0100
From: Maglione Roberta 
To: "sarikaya@ieee.org" 
Date: Thu, 1 Dec 2011 02:16:25 +0100
Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
Thread-Index: AcyvvqtFe71xQAubQBOgc8pspmJjdQACC1Jq
Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE3EBC900F8E@GRFMBX704BA020.griffon.local>
References:    <2963F168-45CB-4042-8238-56DF538B0543@gmail.com>   <2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz> <5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com> <1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz> <8AF88A07-C1C5-4CD9-9E87-9D0F26504641@employees.org> <1808340F7EC362469DDFFB112B37E2FCC5E99477F1@SRVHKE02.rdm.cz>   <282BBE8A501E1F4DA9C775F964BB21FE3EBC900F88@GRFMBX704BA020.griffon.local>  <282BBE8A501E1F4DA9C775F964BB21FE3EBC900F89@GRFMBX704BA020.griffon.local>  <282BBE8A501E1F4DA9C775F964BB21FE3EBC900F8D@GRFMBX704BA020.griffon.local>, 
In-Reply-To: 
Accept-Language: en-US, it-IT
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, it-IT
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "v6ops@ietf.org" 
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 01 Dec 2011 01:19:57 -0000

Yes you can install the aggregate route but you would need either another d=
hc option that tells the BNG what aggregate route needs to be installed per=
 each customer or you have to do by manual configuration.
In my opinion using PD-exclude is operational much simpler

Roberta
________________________________________
From: Behcet Sarikaya [sarikaya2012@gmail.com]
Sent: Thursday, December 01, 2011 1:17 AM
To: Maglione Roberta
Cc: Lorenzo Colitti; v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt

Roberta,

I don't see that a problem either because usually you can install an aggreg=
ate route.

Regards,

Behcet

On Wed, Nov 30, 2011 at 5:26 PM, Maglione Roberta > wrote:
Behcet,
  the reason why you may need to have a single prefix instead of two per cu=
stomer is in order to have just a single route to install on the BNG instea=
d of two.

Regards
Roberta
________________________________________
From: Behcet Sarikaya [sarikaya2012@gmail.com]
Sent: Thursday, December 01, 2011 12:22 AM
To: Maglione Roberta
Cc: Lorenzo Colitti; v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt

Hi Roberta,

You don't need to restrict yourself to the use of a single prefix in IPv6. =
Usually DR can allocate many prefixes to the RR.

Besides these prefixes are used for some time and then not needed any more.=
 I don't see any reason to be so frugal.

Regards,

Behcet

On Wed, Nov 30, 2011 at 1:31 PM, Maglione Roberta >> wrote:
> If you're not using the /64 to number the link between the BNG and the CE=
, then you can make the link unnumbered and you don't need to exclude
> anything.

You could make the link unnumbered, but the WAN link could also be numbered=
.
If you refer to BBF TR-187, TR-177, TR-124i2  you can see that both unnumbe=
red and numbered  are considered valid scenarios.
PD-exclude is need in order to build the WAN numbered scenario with a singl=
e  prefix.

Roberta

________________________________________
From: Lorenzo Colitti [lorenzo@google.com>]
Sent: Wednesday, November 30, 2011 8:24 PM
To: Maglione Roberta
Cc: jouni korhonen; v6ops@ietf.org>
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt

On Thu, Dec 1, 2011 at 04:12, Maglione Roberta >>>=
> wrote:
PD-exclude allows to delegate a single prefix to the home network and than =
use the PD-exclude option to tell the CPE to exclude a portion of the deleg=
ated prefix and use it to number the point to point WAN link between the re=
questing router (CPE) and the delegated router (BNG)

I still don't see why this is needed.

If you're using the /64 to number the link between the BNG and the CE route=
r, then the CE router already knows that the /64 is assigned to that link v=
ia the O bit in the prefix information option in the RA.

If you're not using the /64 to number the link between the BNG and the CE, =
then you can make the link unnumbered and you don't need to exclude anythin=
g.

So...?

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per=
sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall=
a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb=
iate ricevuto questo documento per errore siete cortesemente pregati di dar=
ne immediata comunicazione al mittente e di provvedere alla sua distruzione=
, Grazie.

This e-mail and any attachments is confidential and may contain privileged =
information intended for the addressee(s) only. Dissemination, copying, pri=
nting or use by anybody else is unauthorised. If you are not the intended r=
ecipient, please delete this message and any attachments and advise the sen=
der by return e-mail, Thanks.

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


Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per=
sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall=
a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb=
iate ricevuto questo documento per errore siete cortesemente pregati di dar=
ne immediata comunicazione al mittente e di provvedere alla sua distruzione=
, Grazie.

This e-mail and any attachments is confidential and may contain privileged =
information intended for the addressee(s) only. Dissemination, copying, pri=
nting or use by anybody else is unauthorised. If you are not the intended r=
ecipient, please delete this message and any attachments and advise the sen=
der by return e-mail, Thanks.



Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per=
sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall=
a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb=
iate ricevuto questo documento per errore siete cortesemente pregati di dar=
ne immediata comunicazione al mittente e di provvedere alla sua distruzione=
, Grazie.

This e-mail and any attachments is confidential and may contain privileged =
information intended for the addressee(s) only. Dissemination, copying, pri=
nting or use by anybody else is unauthorised. If you are not the intended r=
ecipient, please delete this message and any attachments and advise the sen=
der by return e-mail, Thanks.


From shemant@cisco.com  Wed Nov 30 21:58:31 2011
Return-Path: 
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5204911E80A1 for ; Wed, 30 Nov 2011 21:58:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.57
X-Spam-Level: 
X-Spam-Status: No, score=-6.57 tagged_above=-999 required=5 tests=[AWL=0.028,  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 f0y1QH8ByR7F for ; Wed, 30 Nov 2011 21:58:30 -0800 (PST)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 540C11F0C36 for ; Wed, 30 Nov 2011 21:58:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=10337; q=dns/txt; s=iport; t=1322719110; x=1323928710; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=HYNaQC1Mg5rZOomYffjbTcP5eReST1GixJmEXVnBHXE=; b=at5RTlsCzKaAxHCIvYUO1zeSRN8BDDwLLw2YimwFFnhdVxcFRi2rabM8 k+0/lie+/a1GZ4jdaWe2QKbxMGr4lfK1mfKpdno0QINJuBpaxNxvd9wgn SnXzlgcMhRFnuZPmRCalyrE1QjZ7ONsFIfDaoPBtNrrdXa1FRiGHzDy0c 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqsAAN0W106tJV2a/2dsb2JhbABEgk2YJogjAYd/gQWBcgEBAQQSAQkRA0kQAgEIEQQBAQsGFwEGAUUJCAEBBAESCBqHbZlsAZ4yij1jBIgonmA
X-IronPort-AV: E=Sophos;i="4.71,276,1320624000"; d="scan'208,217";a="40226804"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 01 Dec 2011 05:58:29 +0000
Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pB15wTc9010149;  Thu, 1 Dec 2011 05:58:29 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 30 Nov 2011 23:58:29 -0600
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCAFEE.3F55EF36"
Date: Wed, 30 Nov 2011 23:58:27 -0600
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3036CE267@XMB-RCD-109.cisco.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
Thread-Index: AcyvpYgIPkDa+j+4QpGgPzqtkjQemQAR1eVA
References: <2963F168-45CB-4042-8238-56DF538B0543@gmail.com><2E33369F-19B7-4437-B4C1-A58762DF8F9B@employees.org><1808340F7EC362469DDFFB112B37E2FCC5E99475F3@SRVHKE02.rdm.cz><5B6B2B64C9FE2A489045EEEADDAFF2C3035EF30B@XMB-RCD-109.cisco.com><1808340F7EC362469DDFFB112B37E2FCC5E994777C@SRVHKE02.rdm.cz><8AF88A07-C1C5-4CD9-9E87-9D0F26504641@employees.org><1808340F7EC362469DDFFB112B37E2FCC5E99477F1@SRVHKE02.rdm.cz><1808340F7EC362469DDFFB112B37E2FCC5E999F158@SRVHKE02.rdm.cz><282BBE8A501E1F4DA9C775F964BB21FE3EBC900F8C@GRFMBX704BA020.griffon.local><23C35D5A-EC84-4249-B93A-71DEC 865F895@ employees.or g> 
From: "Hemant Singh (shemant)" 
To: "Lorenzo Colitti" , "Ole Troan" 
X-OriginalArrivalTime: 01 Dec 2011 05:58:29.0168 (UTC) FILETIME=[3FA3D300:01CCAFEE]
Cc: v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 01 Dec 2011 05:58:31 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CCAFEE.3F55EF36
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

=20

From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
Of Lorenzo Colitti
Sent: Wednesday, November 30, 2011 4:17 PM
To: Ole Troan
Cc: v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-03.txt

=20

=20

>For example, what is an implementation supposed to do if it gets a PD
of 2001:db8:1::/56 with an exclude for 2001:db8:1:2::/64? What's the
next hop for 2001:db8:1:2::/64?=20

=20

If I read the exclude document
(http://tools.ietf.org/html/draft-ietf-dhc-pd-exclude-03), I see that
the /64 above is used on the RR for the link between the RR and the DR.
Since the DR is the first-hop router for the RR (section 3 of the
exclude document says so), the next-hop for the global /64 above is the
IPv6 link-local address of the DR.  See also this text from section 6.1
of the exclude document.

=20

[The requesting router must create sink routes for the delegated

prefixes minus the excluded prefixes.  This may be done by creating

sink routes for delegated prefixes and more specific routes for the

excluded prefixes.]

=20

I could use a /128 from the excluded /64 on any virtual interface to
source ICMPv6 errors.

=20

Hemant


------_=_NextPart_001_01CCAFEE.3F55EF36
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


 
From:=
 =
v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of =
Lorenzo Colitti
Sent: Wednesday, November 30, 2011 4:17 =
PM
To: Ole Troan
Cc: =
v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: =
draft-ietf-v6ops-6204bis-03.txt
 
 
>For example, what =
is an implementation supposed to do if it gets a PD of 2001:db8:1::/56 =
with an exclude for 2001:db8:1:2::/64? What's the next hop =
for 2001:db8:1:2::/64? 
 
If I read the exclude document (http://t=
ools.ietf.org/html/draft-ietf-dhc-pd-exclude-03), I see that the /64 =
above is used on the RR for the link between the RR and the =
DR.    Since the DR is the first-hop router for the RR =
(section 3 of the exclude document says so), the next-hop for the global =
/64 above is the IPv6 link-local address of the DR.  See =
also this text from section 6.1 of the exclude =
document.
 
[The requesting router must create sink routes =
for the delegated
 prefixes minus the =
excluded prefixes.  This may be done by =
creating
 sink routes for =
delegated prefixes and more specific routes for =
the
 excluded =
prefixes.]
 
I could use a /128 from the excluded /64 on any =
virtual interface to source ICMPv6 errors.
 
Hemant
=

------_=_NextPart_001_01CCAFEE.3F55EF36--