From huangcc_gsta@189.cn Sun Apr 1 05:25:57 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AEA021F8E4B for ; Sun, 1 Apr 2012 05:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.072 X-Spam-Level: ** X-Spam-Status: No, score=2.072 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_IS_SMALL6=0.556, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, J_CHICKENPOX_13=0.6, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0FqZuQtu-nkP for ; Sun, 1 Apr 2012 05:25:53 -0700 (PDT) Received: from 189.cn (mta.189.cn [121.14.53.137]) by ietfa.amsl.com (Postfix) with ESMTP id 015BA21F8E6C for ; Sun, 1 Apr 2012 05:25:49 -0700 (PDT) Received: from ip?222.244.209.87? (as9.inner-189.cn [10.62.8.19]) by 189.cn (HERMES) with ESMTP id 19E0811C0C5; Sun, 1 Apr 2012 20:25:47 +0800 (CST) HMM_ATTACHE_NUM: 0000 HMM_SOURCE_IP: wmail.10.62.8.19.594419928 HMM_SOURCE_TYPE: WEBMAIL Received: from ip<222.244.209.87> ([222.244.209.87]) by 189CN(Yuwen filter gate 10.62.8.19) with ESMTP id 1333283146.1812 for fred@cisco.com ; Sun Apr 1 20:25:48 2012 0/X-Total-Score: 13: X-FILTER-SCORE: to=<8793868561848a9484904f84908e85938287954e9a828f884e97579091944e8782949557619590908d944f8a8695874f90938897579091944e8489828a9394619590908d944f8a8695874f9093889757909194618a8695874f909388>, score=<13332831484y84eqM+yxBQ84q84M84+8lBo8aGilU1DBoaBoGBoiBo> Message-ID: <11118744.33311333283147279.JavaMail.hermes@yt-webmail27> Date: Sun, 1 Apr 2012 20:25:46 +0800 (CST) From: huangcc_gsta@189.cn To: fred@cisco.com, draft-yang-v6ops-fast6@tools.ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_3310_26956204.1333283146784" HMM_WEBCLN_IP: 222.244.209.87 X-Priority: 3 Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org Subject: Re: [v6ops] Some questions on draft-yang-v6ops-fast6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2012 12:25:57 -0000 ------=_Part_3310_26956204.1333283146784 Content-Type: text/html;charset=UTF-8 Content-Transfer-Encoding: base64 PFA+SGksIEZyZWQ6PC9QPg0KPFA+Jm5ic3A7PC9QPg0KPFA+MSkgUGxlYXNlIHByb3ZpZGUgYSBz dWNjaW5jdCBwcm9ibGVtIHN0YXRlbWVudCBmb3IgeW91ciBkcmFmdC4gV2hhdCBwcm9ibGVtL2lz c3VlIGlzIHRoaXMgZHJhZnQgZGlzY3Vzc2luZz8gV2hhdCBvcGVyYXRpb25hbCBwcm9ibGVtcyBk b2VzIHRoZSBwcm9wb3NhbCBhZGRyZXNzIGluIHJlYWwgbGlmZSBuZXR3b3Jrcz88L1A+DQo8UD4v LyZuYnNwOzxTUEFOIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RhaG9tYScsJ3NhbnMtc2VyaWYnOyBG T05ULVNJWkU6IDlwdCI+PFNQQU4gc3R5bGU9IkNPTE9SOiByZWQiIGxhbmc9RU4tVVM+V2hlbiB3 ZSBtYWRlIHNlcmllcyB0cmlhbHMgaW4gdGhlIHJlYWwgbGlmZSBuZXR3b3JrIGluIHRoZSBsYXN0 IHR3byB5ZWFycywgd2UgZm91bmQgdGhlcmUgYXJlIG1hbnkgcHJvYmxlbXMgYXJvc2UgaW4gdGhl IHByYWN0aWNlIGFuZCBOYXRpdmUgZHVhbCBzdGFjayBzb3VuZHMgbGlrZSBhIHN1aXRhYmxlIG1l dGhvZCBmb3Igb3VyIG5ldHdvcmsgbWlncmF0aW9uLiBUaGUgcmVhc29ucyB3aHkgb3RoZXIga2lu ZHMgb2YgdHJhbnNpdGlvbiB0ZWNobm9sb2dpZXMgYXJlIG5vdCB2ZXJ5IHN1aXRhYmxlIGZvciBv dXIgbmV0d29yaywgc3VjaCBhcyA0b3ZlcjYsIDZvdmVyNCwgYXJlIGJyaWVmbHkgbGlzdGVkIGlu IHRoZSBJbnRyb2R1Y3Rpb24gaW4gdGhpcyBkcmFmdCBhbmQgZGV0YWlsZWQgZXhwbGFpbmVkIGlu IOKAnGRyYWZ0LXlhbmctdjZvcHMtRkFTVDYtdG9vbC1zZWxlY3Rpb24tMDHigJ0uIDw/eG1sOm5h bWVzcGFjZSBwcmVmaXggPSBvIG5zID0gInVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNl Om9mZmljZSIgLz48bzpwPjwvbzpwPjwvU1BBTj48L1NQQU4+PC9QPg0KPFA+PFNQQU4gc3R5bGU9 IkZPTlQtRkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJpZic7IENPTE9SOiByZWQ7IEZPTlQtU0la RTogOXB0OyBtc28tZmFyZWFzdC1mb250LWZhbWlseTog5a6L5L2TOyBtc28tZmFyZWFzdC10aGVt ZS1mb250OiBtaW5vci1mYXJlYXN0OyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVM7IG1zby1mYXJl YXN0LWxhbmd1YWdlOiBaSC1DTjsgbXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNBIiBsYW5nPUVOLVVT PjxTUEFOIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7IDwvU1BBTj5Ib3dl dmVyLCBpbiBvcmRlciB0byBtYWtlIGEgcXVpY2sgcmVzcG9uc2UgdG8gYWRkcmVzcyBleGhhdXN0 aW9uLCBuYXRpdmUgZHVhbCBzdGFjayBoYXMgdG8gY29vcGVyYXRlIHdpdGggYWRkcmVzcyBzaGFy aW5nIHRlY2hub2xvZ3kuIFdlIG1hZGUgYSB0cmlhbCBpbiByZWFsIGxpZmUgbmV0d29yayB1c2lu ZyDigJxuYXRpdmUgZHVhbCBzdGFjaysgY2FycmllciBncmFkZSBOQVTigJ0gYW5kJm5ic3A7IHdl IGZpbmQgdGhlcmUgaXMgbWl4ZWQgcm91dGluZyBwcm9ibGVtIGluIHRoZSBuZXR3b3JrLiA8U1BB TiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJzsgQ09MT1I6IHJlZDsg Rk9OVC1TSVpFOiA5cHQ7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiDlrovkvZM7IG1zby1mYXJl YXN0LXRoZW1lLWZvbnQ6IG1pbm9yLWZhcmVhc3Q7IG1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUzsg bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IFpILUNOOyBtc28tYmlkaS1sYW5ndWFnZTogQVItU0EiIGxh bmc9RU4tVVM+SW4gdGhlIGluaXRpYWwgc3RhZ2UsIHRoZSBDR05zIGhhdmUgdG8gYmUgZGlzdHJp YnV0ZWQgaW4gdGhlIE5ldHdvcmsgRWRnZSAoc3VjaCBhcyBCTkcpIHNpbmNlIHRoZSBsYXJnZSBh bW91bnQgb2YgSVB2NCB0cmFmZmljIChhY2NvcmRpbmcgdG8gdGhlIHByZWRpY3Rpb24gZGF0YSBm b3Igb3VyIG5ldHdvcmsgKS4gSW4gdGhpcyBjYXNlLCBwcml2YXRlIElQdjQgcm91dGluZyBhbmQg cHVibGljIElQdjQgcm91dGluZyB3aWxsIGNvZXhpc3QgaW4gdGhlIG5ldHdvcmsuPC9TUEFOPjwv U1BBTj48QlI+Jm5ic3A7Jm5ic3A7IDxTUEFOIGNsYXNzPWVkaXRtYWlsPjxTUEFOIHN0eWxlPSJG T05ULUZBTUlMWTogJ1RhaG9tYScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogcmVkOyBGT05ULVNJWkU6 IDlwdDsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IOWui+S9kzsgbXNvLWZhcmVhc3QtdGhlbWUt Zm9udDogbWlub3ItZmFyZWFzdDsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFz dC1sYW5ndWFnZTogWkgtQ047IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1TQSIgbGFuZz1FTi1VUz5U aGUgcHJvcG9zYWwsIEZBU1Q2IGFkZHJlc3NlcyB0aGlzIHByb2JsZW1zIGRlc2NyaWJlZCBhYm92 ZSBpbiByZWFsIGxpZmUgbmV0d29yayB0aHJvdWdoIGVzdGFibGlzaGluZyBhIHByaXZhdGUtaW4t cHVibGljIElQdjQgdHVubmVsIGJldHdlZW4gRlRTIGFuZCBGVE4gdG8gaXNvbGF0ZSB0aGUgcm91 dGluZ3MgaW4gbmV0d29yay48U1BBTiBjbGFzcz1lZGl0bWFpbD48U1BBTiBzdHlsZT0iRk9OVC1G QU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJzsgQ09MT1I6IHJlZDsgRk9OVC1TSVpFOiA5cHQi IGxhbmc9RU4tVVM+SW4gcHJhY3RpY2UgLCB0aGUgdHVubmVsIGJldHdlZW4gRlRTIGFuZCBGVE4g aXMgdXN1YWxseSBhIHR1bm5lbCBiZXR3ZWVuIEJORyBhbmQgQ1IuIFNvIGl0IGNhbiBzb2x2ZSB0 aGUgbWl4ZWQgcm91dGluZyBwcm9ibGVtIGluIG5ldHdvcmsuPG86cD48L286cD48L1NQQU4+PC9T UEFOPjwvUD4NCjxQPjwvU1BBTj48L1NQQU4+PEJSPjIpIFdoZXJlIGRvZXMgdGhpcyBkcmFmdCBv ciBwcmVzZW50YXRpb24gZml0cyBpbnRvIHY2b3BzJyBjdXJyZW50IGNoYXJ0ZXIgKGh0dHA6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy93Zy92Nm9wcy9jaGFydGVyLyk/IENpdGluZyBzcGVjaWZpYyBh IHNlY3Rpb24ocykgb2YgdGhlIGNoYXJ0ZXIgaXMgcHJlZmVyYWJsZS4gPC9QPg0KPFAgc3R5bGU9 IlRFWFQtSU5ERU5UOiAxOHB0OyBNQVJHSU46IDBjbSAwY20gMHB0OyBtc28tY2hhci1pbmRlbnQt Y291bnQ6IDIuMCIgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlMWTogJ1Rh aG9tYScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogcmVkOyBGT05ULVNJWkU6IDlwdCIgbGFuZz1FTi1V Uz5XZSBsaXN0IHRoZSBwcm92aXNpb25zIGluIGNoYXJ0IHRoaXMgZHJhZnQgZml0IGludG8gYXMg YmVsb3c6IDxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCjxQIHN0eWxlPSJURVhULUlOREVOVDogLTE4 cHQ7IE1BUkdJTjogMGNtIDBjbSAwcHQgMThwdDsgbXNvLWNoYXItaW5kZW50LWNvdW50OiAwOyBt c28tbGlzdDogbDAgbGV2ZWwxIGxmbzEiIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGg+PFNQQU4gc3R5 bGU9IkZPTlQtRkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJpZic7IENPTE9SOiByZWQ7IEZPTlQt U0laRTogOXB0OyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogVGFob21hIiBsYW5nPUVOLVVTPjxT UEFOIHN0eWxlPSJtc28tbGlzdDogSWdub3JlIj4oMSk8U1BBTiBzdHlsZT0iRk9OVDogN3B0ICdU aW1lcyBOZXcgUm9tYW4nIj4mbmJzcDsmbmJzcDsgPC9TUEFOPjwvU1BBTj48L1NQQU4+PFNQQU4g c3R5bGU9IkZPTlQtRkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJpZic7IENPTE9SOiByZWQ7IEZP TlQtU0laRTogOXB0IiBsYW5nPUVOLVVTPlRoZSBJUHY2IE9wZXJhdGlvbnMgV29ya2luZyBHcm91 cCAodjZvcHMpIGRldmVsb3BzIGd1aWRlbGluZXMgZm9yIHRoZSBvcGVyYXRpb24gb2YgYSBzaGFy ZWQgSVB2NC9JUHY2IEludGVybmV0LjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCjxQIHN0eWxlPSJU RVhULUlOREVOVDogLTE4cHQ7IE1BUkdJTjogMGNtIDBjbSAwcHQgMThwdDsgbXNvLWNoYXItaW5k ZW50LWNvdW50OiAwOyBtc28tbGlzdDogbDAgbGV2ZWwxIGxmbzEiIGNsYXNzPU1zb0xpc3RQYXJh Z3JhcGg+PEIgc3R5bGU9Im1zby1iaWRpLWZvbnQtd2VpZ2h0OiBub3JtYWwiPjxTUEFOIHN0eWxl PSJGT05ULUZBTUlMWTogJ1RhaG9tYScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogcmVkOyBGT05ULVNJ WkU6IDlwdDsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IFRhaG9tYSIgbGFuZz1FTi1VUz48U1BB TiBzdHlsZT0ibXNvLWxpc3Q6IElnbm9yZSI+KDIpPFNQQU4gc3R5bGU9IkZPTlQ6IDdwdCAnVGlt ZXMgTmV3IFJvbWFuJyI+Jm5ic3A7IDwvU1BBTj48L1NQQU4+PC9TUEFOPjwvQj48U1BBTiBzdHls ZT0iRk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJzsgQ09MT1I6IHJlZDsgRk9OVC1T SVpFOiA5cHQiIGxhbmc9RU4tVVM+VGhlIG1haW4gZm9jdXMgb2YgdGhlIHY2b3BzIFdHIGlzIHRv IGxvb2sgYXQgdGhlIGltbWVkaWF0ZSBkZXBsb3ltZW50IGlzc3Vlcy4gPEIgc3R5bGU9Im1zby1i aWRpLWZvbnQtd2VpZ2h0OiBub3JtYWwiPjxVPkZBU1Q2IGlzIGRlc2lnbmVkIGZvciB2ZXJ5IGlu aXRpYWwgc3RlcCBvZiBkZXBsb3ltZW50LjxvOnA+PC9vOnA+PC9VPjwvQj48L1NQQU4+PC9QPg0K PFAgc3R5bGU9IlRFWFQtSU5ERU5UOiAtMThwdDsgTUFSR0lOOiAwY20gMGNtIDBwdCAxOHB0OyBt c28tY2hhci1pbmRlbnQtY291bnQ6IDA7IG1zby1saXN0OiBsMCBsZXZlbDEgbGZvMSIgY2xhc3M9 TXNvTGlzdFBhcmFncmFwaD48QiBzdHlsZT0ibXNvLWJpZGktZm9udC13ZWlnaHQ6IG5vcm1hbCI+ PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJpZic7IENPTE9SOiBy ZWQ7IEZPTlQtU0laRTogOXB0OyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogVGFob21hIiBsYW5n PUVOLVVTPjxTUEFOIHN0eWxlPSJtc28tbGlzdDogSWdub3JlIj4oMyk8U1BBTiBzdHlsZT0iRk9O VDogN3B0ICdUaW1lcyBOZXcgUm9tYW4nIj4mbmJzcDsgPC9TUEFOPjwvU1BBTj48L1NQQU4+PC9C PjxTUEFOIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RhaG9tYScsJ3NhbnMtc2VyaWYnOyBDT0xPUjog cmVkOyBGT05ULVNJWkU6IDlwdCIgbGFuZz1FTi1VUz5Tb2xpY2l0IGlucHV0IGZyb20gbmV0d29y ayBvcGVyYXRvcnMgYW5kIHVzZXJzIHRvIGlkZW50aWZ5IG9wZXJhdGlvbmFsIGlzc3VlcyB3aXRo IHRoZSBJUHY0L0lQdjYgSW50ZXJuZXQsIGFuZCBkZXRlcm1pbmUgc29sdXRpb25zIG9yIHdvcmth cm91bmRzIHRvIHRob3NlIGlzc3Vlcy4gPEIgc3R5bGU9Im1zby1iaWRpLWZvbnQtd2VpZ2h0OiBu b3JtYWwiPjxVPkZBU1Q2IGhhdmUgZGVzY3JpYmUgdGhlIG9wZXJhdGlvbiBwcm9ibGVtIHdlIG1l ZXQgaW4gcHJhY3RpY2UgYW5kIGdpdmUgdGhlIHNvbHV0aW9uLjxvOnA+PC9vOnA+PC9VPjwvQj48 L1NQQU4+PC9QPg0KPFA+PEJSPjMpIFdobyBpcyB0aGlzIGRyYWZ0J3MgYXVkaWVuY2U/IDwvUD4N CjxQIHN0eWxlPSJURVhULUlOREVOVDogMThwdDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgbXNvLWNo YXItaW5kZW50LWNvdW50OiAyLjAiIGNsYXNzPU1zb05vcm1hbD48U1BBTiBzdHlsZT0iRk9OVC1G QU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJzsgQ09MT1I6IHJlZDsgRk9OVC1TSVpFOiA5cHQi PjxTUEFOIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7PC9TUEFOPjxTUEFOIGxhbmc9 RU4tVVM+QWx0aG91Z2ggRkFTVDYgaXMgZGVzaWduZWQgd2l0aCBvdXIgb3duIG5ldHdvcmsgZXhw ZXJpZW5jZSwgaXQgaXMgc3VpdGFibGUgZm9yIG1hbnkgb3RoZXIgb3BlcmF0b3JzLiBUaGUgYXVk aWVuY2VzIGFyZSA8L1NQQU4+PC9TUEFOPjxBIHN0eWxlPSJtc28tY29tbWVudC1yZWZlcmVuY2U6 IFlfMTsgbXNvLWNvbW1lbnQtZGF0ZTogMjAxMjA0MDFUMTkzNyI+PFNQQU4gc3R5bGU9IkZPTlQt RkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJpZic7IENPTE9SOiByZWQ7IEZPTlQtU0laRTogOXB0 IiBsYW5nPUVOLVVTPm5ldHdvcmsgb3BlcmF0b3JzIHdob3NlIHB1YmxpYyBhZGRyZXNzIHNwYWNl IGlzIHZlcnkgbGltaXRlZCBhbmQgd2lsbCBiZSBleGhhdXN0ZWQgaW4gdmVyeSBzaG9ydCByZWNl bnRseSB3aGljaCBtZWFucyB0aGV5IGhhdmUgbm8gdGltZSB0byByZWZvcm0gdGhlaXIgbmV0d29y ayB0byBuYXRpdmUgSVB2NiBpbiBzcGVjaWZpZWQgc2hvcnQgdGltZS4gVGhleSBtYXkgaGF2ZSB0 byB1c2UgY2FycmllciBncmFkZSBOQVQgdG8gZGVhbCB0aGUgZW1lcmdlbnQgc2l0dWF0aW9uLCBG QVNUNiBjYW4gaW5mbyB0aGVtIHNvbWUgb3BlcmF0aW9uIHByb2JsZW1zIGluIHJlYWwgbGlmZSBu ZXR3b3JrIGFuZCB0aGUgc29sdXRpb24uPC9TUEFOPjwvQT48L1A+DQo8UD48QlI+NCkgSGF2ZSBh bnkgb3BlcmF0b3JzIGV4cHJlc3NlZCBpbnRlcmVzdCBpbiB0aGlzIGRyYWZ0IG9yIGl0cyBwcm9i bGVtIHNwYWNlLCBlaXRoZXIgdmlhIHJldmlldyBvciBvdGhlciBkaXNjdXNzaW9uPyA8QlI+PFNQ QU4gc3R5bGU9IkJBQ0tHUk9VTkQtQ09MT1I6ICNmZmZmZmY7IENPTE9SOiAjZTUzMzMzIj4mbmJz cDs8L1NQQU4+PFNQQU4gc3R5bGU9IkJBQ0tHUk9VTkQtQ09MT1I6ICNmZmZmZmY7IENPTE9SOiAj ZTUzMzMzIj4mbmJzcDsgQ2hpbmEgVGVsZWNvbSBleHByZXNzIHN0cm9uZyBpbnRlcmVzdCBpbiB0 aGlzIGRyYWZ0LjxTUEFOIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RhaG9tYScsJ3NhbnMtc2VyaWYn OyBDT0xPUjogcmVkOyBGT05ULVNJWkU6IDlwdDsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IOWu i+S9kzsgbXNvLWZhcmVhc3QtdGhlbWUtZm9udDogbWlub3ItZmFyZWFzdDsgbXNvLWFuc2ktbGFu Z3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogWkgtQ047IG1zby1iaWRpLWxhbmd1 YWdlOiBBUi1TQSIgbGFuZz1FTi1VUz48U1BBTiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZu YnNwOzwvU1BBTj5XZSBhcmUgZWFnZXJseSBob3BpbmcgdGhlIG90aGVyJm5ic3A7b3BlcmF0b3Jz 4oCZIHJlc3BvbnNlIGluIHRoZSBkcmFmdC48L1NQQU4+PFNQQU4gY2xhc3M9ZWRpdG1haWw+PFNQ QU4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnOyBGT05ULVNJWkU6 IDEwLjVwdDsgbXNvLWJpZGktZm9udC1zaXplOiAxMS4wcHQ7IG1zby1hc2NpaS10aGVtZS1mb250 OiBtaW5vci1sYXRpbjsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IOWui+S9kzsgbXNvLWZhcmVh c3QtdGhlbWUtZm9udDogbWlub3ItZmFyZWFzdDsgbXNvLWhhbnNpLXRoZW1lLWZvbnQ6IG1pbm9y LWxhdGluOyBtc28tYmlkaS1mb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7IG1zby1iaWRp LXRoZW1lLWZvbnQ6IG1pbm9yLWJpZGk7IG1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUzsgbXNvLWZh cmVhc3QtbGFuZ3VhZ2U6IFpILUNOOyBtc28tYmlkaS1sYW5ndWFnZTogQVItU0EiIGxhbmc9RU4t VVM+PEZPTlQgY29sb3I9IzAwMDAwMD4gPC9GT05UPjwvU1BBTj48L1NQQU4+PC9TUEFOPjxCUj41 KSBJcyB0aGlzIGRyYWZ0IHB1cnN1aW5nIGRpc2N1c3Npb24gaW4gYW55IG90aGVyIFdHcz8gSWYg c28sIHBsZWFzZSBsaXN0IHRoZW0gaGVyZSwgYWxvbmcgd2l0aCByYXRpb25hbGUgZm9yIHRoZSBp bnRlcmFjdGlvbiB3aXRoIG11bHRpcGxlIFdHcyBpbiBwYXJhbGxlbC4mbmJzcDs8QlI+Jm5ic3A7 Jm5ic3A7IDxTUEFOIGNsYXNzPWVkaXRtYWlsPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlMWTogJ1Rh aG9tYScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogcmVkOyBGT05ULVNJWkU6IDlwdDsgbXNvLWZhcmVh c3QtZm9udC1mYW1pbHk6IOWui+S9kzsgbXNvLWZhcmVhc3QtdGhlbWUtZm9udDogbWlub3ItZmFy ZWFzdDsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogWkgt Q047IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1TQSIgbGFuZz1FTi1VUz5XZSBvbmx5IHBvc3QgaXQg aW4gdjZvcHMgV0cgYW5kIGRpZG7igJl0IGhhdmUgZGlzY3Vzc2lvbiBpbiBvdGhlciBXR3MgeWV0 LjwvU1BBTj48L1NQQU4+PC9QPg0KPFA+NikgSXMgYW55IHByb3RvY29sIHdvcmsgYmVpbmcgcmVj b21tZW5kZWQgaW4gdGhlIGRyYWZ0PyA8QlI+PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGFo b21hJywnc2Fucy1zZXJpZic7IENPTE9SOiByZWQ7IEZPTlQtU0laRTogOXB0OyBtc28tZmFyZWFz dC1mb250LWZhbWlseTog5a6L5L2TOyBtc28tZmFyZWFzdC10aGVtZS1mb250OiBtaW5vci1mYXJl YXN0OyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBaSC1D TjsgbXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNBIiBsYW5nPUVOLVVTPiZuYnNwOyZuYnNwOyZuYnNw OyBUaGVyZSBpcyBubyBjaGFuZ2Ugb2YgYW55IHByb3RvY29sIGluIHRoaXMgZHJhZnQuIDwvU1BB Tj48QlI+PEJSPjxCUj48L1A+DQo8UD48QlI+PC9QPg0KPFA+PEJSPjwvUD4NCjxQPjxCUj48L1A+ PFNQQU4gaWQ9ZWRpdERpdiBjbGFzcz1lZGl0TWFpbD48U1BBTiBpZD1ub3REcmFmdD48L1NQQU4+ PFNQQU4gaWQ9dW5kZXJTaWduPjwvU1BBTj48U1BBTiBpZD1jb250ZW50X29sZD48QlI+PEJSPjxC Uj48QlI+PEJSPjxCUj48QlI+PT09PT0g5Zue5aSN5YmN5Y6f5aeL6YKu5Lu2ID09PT09PEJSPjxC Uj48QlI+PEI+5Y+R5Lu25Lq677yaPC9CPmZyZWRAY2lzY28uY29tPEJSPjxCPuaXpeacn++8mjwv Qj4yMDEyLzAzLzMxIDIwOjQ1OjAxPEJSPjxCPuaUtuS7tuS6uu+8mjwvQj5kcmFmdC15YW5nLXY2 b3BzLWZhc3Q2QHRvb2xzLmlldGYub3JnPEJSPjxCPuaKhOmAge+8mjwvQj52Nm9wcy1jaGFpcnNA dG9vbHMuaWV0Zi5vcmc8QlI+PEI+5Li76aKY77yaPC9CPlNvbWUgcXVlc3Rpb25zIG9uIGRyYWZ0 LXlhbmctdjZvcHMtZmFzdDY8QlI+PEJSPkxldCBtZSBhc2sgc29tZSBxdWVzdGlvbnMuIFRoaXMg aXMgbm90IGludGVuZGVkIHRvIHB1dCB5b3Ugb2ZmIG9yIG9mZmVuZCwgYnV0IHRvIGhlbHAgdGhl IGNoYWlycyBpbiB1bmRlcnN0YW5kaW5nIHdoZXJlIHRoZSBkcmFmdCBmaXRzIGluIHRoZSBiaWcg c2NoZW1lIG9mIHRoaW5ncy4gPEJSPjxCUj4xKSBQbGVhc2UgcHJvdmlkZSBhIHN1Y2NpbmN0IHBy b2JsZW0gc3RhdGVtZW50IGZvciB5b3VyIGRyYWZ0LiBXaGF0IHByb2JsZW0vaXNzdWUgaXMgdGhp cyBkcmFmdCBkaXNjdXNzaW5nPyBXaGF0IG9wZXJhdGlvbmFsIHByb2JsZW1zIGRvZXMgdGhlIHBy b3Bvc2FsIGFkZHJlc3MgaW4gcmVhbCBsaWZlIG5ldHdvcmtzPyA8QlI+PEJSPjIpIFdoZXJlIGRv ZXMgdGhpcyBkcmFmdCBvciBwcmVzZW50YXRpb24gZml0cyBpbnRvIHY2b3BzJyBjdXJyZW50IGNo YXJ0ZXIgKGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy93Zy92Nm9wcy9jaGFydGVyLyk/IENp dGluZyBzcGVjaWZpYyBhIHNlY3Rpb24ocykgb2YgdGhlIGNoYXJ0ZXIgaXMgcHJlZmVyYWJsZS4g PEJSPjxCUj4zKSBXaG8gaXMgdGhpcyBkcmFmdCdzIGF1ZGllbmNlPyA8QlI+PEJSPjQpIEhhdmUg YW55IG9wZXJhdG9ycyBleHByZXNzZWQgaW50ZXJlc3QgaW4gdGhpcyBkcmFmdCBvciBpdHMgcHJv YmxlbSBzcGFjZSwgZWl0aGVyIHZpYSByZXZpZXcgb3Igb3RoZXIgZGlzY3Vzc2lvbj8gPEJSPjxC Uj41KSBJcyB0aGlzIGRyYWZ0IHB1cnN1aW5nIGRpc2N1c3Npb24gaW4gYW55IG90aGVyIFdHcz8g SWYgc28sIHBsZWFzZSBsaXN0IHRoZW0gaGVyZSwgYWxvbmcgd2l0aCByYXRpb25hbGUgZm9yIHRo ZSBpbnRlcmFjdGlvbiB3aXRoIG11bHRpcGxlIFdHcyBpbiBwYXJhbGxlbC4gPEJSPjxCUj42KSBJ cyBhbnkgcHJvdG9jb2wgd29yayBiZWluZyByZWNvbW1lbmRlZCBpbiB0aGUgZHJhZnQ/IDxCUj48 QlI+dGhlIGNyaXRlcmlhIHRoZSBXRyBhc2tlZCBtZSB0byBhcHBseSBmb3IgbmV3IHdvcmsgb3Ig cHJlc2VudGF0aW9uIHNsb3RzIGFyZTogPEJSPi0gcmVjZW50IG9yIHJlY2VudGx5IHVwZGF0ZWQg ZHJhZnQgPEJSPi0gd2l0aGluIGNoYXJ0ZXIgPEJSPi0gcmVzdWx0cyBpbiBjb25zdHJ1Y3RpdmUg ZGlzY3Vzc2lvbiBvbiB0aGUgbWFpbGluZyBsaXN0IDxCUj48QlI+SSBuZWVkIGZvciB5b3UgdG8g cHJvdm9rZSBkaXNjdXNzaW9uIG9uIHRoZSBsaXN0LiBZb3UgbWF5IHJlc3BvbmQgdG8gbXkgb3Bl bmluZyBlbWFpbCB0byBkbyBzbyBpZiBpdCdzIGhlbHBmdWwuIDxCUj48L1NQQU4+PC9TUEFOPg== ------=_Part_3310_26956204.1333283146784-- From huangcc_gsta@189.cn Sun Apr 1 05:35:18 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42F3221F921F for ; Sun, 1 Apr 2012 05:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.072 X-Spam-Level: ** X-Spam-Status: No, score=2.072 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_IS_SMALL6=0.556, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, HTML_OBFUSCATE_05_10=0.001, J_CHICKENPOX_13=0.6, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: 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-VnbnIV62PJ for ; Sun, 1 Apr 2012 05:35:17 -0700 (PDT) Received: from 189.cn (mta.189.cn [121.14.53.137]) by ietfa.amsl.com (Postfix) with ESMTP id 6882021F9217 for ; Sun, 1 Apr 2012 05:35:17 -0700 (PDT) Received: from ip?222.244.209.87? (as10.inner-189.cn [10.62.8.20]) by 189.cn (HERMES) with ESMTP id 83E9120128; Sun, 1 Apr 2012 20:35:15 +0800 (CST) HMM_ATTACHE_NUM: 0000 HMM_SOURCE_IP: wmail.10.62.8.20.218880485 HMM_SOURCE_TYPE: WEBMAIL Received: from ip<222.244.209.87> ([222.244.209.87]) by 189CN(Yuwen filter gate 10.62.8.20) with ESMTP id 1333283715.5230 for fred@cisco.com ; Sun Apr 1 20:35:16 2012 0/X-Total-Score: 13: X-FILTER-SCORE: to=<8793868561848a9484904f84908e85938287954e9a828f884e97579091944e8782949557619590908d944f8a8695874f90938897579091944e8489828a9394619590908d944f8a8695874f9093889757909194618a8695874f909388>, score=<1333283716kBo7ZFykqM2BoZBoFBoyBoQ82qVyKQUgX82V82y82K82> Message-ID: <846948.33531333283715720.JavaMail.hermes@yt-webmail27> Date: Sun, 1 Apr 2012 20:35:15 +0800 (CST) From: huangcc_gsta@189.cn To: fred@cisco.com, draft-yang-v6ops-fast6@tools.ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_3333_17184723.1333283715416" HMM_WEBCLN_IP: 222.244.209.87 X-Priority: 3 Cc: v6ops , v6ops-chairs@tools.ietf.org Subject: Re: [v6ops] Some questions on draft-yang-v6ops-fast6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2012 12:35:18 -0000 ------=_Part_3333_17184723.1333283715416 Content-Type: text/html;charset=UTF-8 Content-Transfer-Encoding: base64 PFA+SGksIEZyZWQ6PC9QPg0KPFA+Jm5ic3A7PC9QPg0KPFA+Jm5ic3A7IEkgZm9yZ2V0IHRvIG1l bnRpb24sIGZvciB5b3VyIGZpc3J0IHF1ZXN0aW9uICJQbGVhc2UgcHJvdmlkZSBhIHN1Y2NpbmN0 IHByb2JsZW0gc3RhdGVtZW50IGZvciB5b3VyIGRyYWZ0LiBXaGF0IHByb2JsZW0vaXNzdWUgaXMg dGhpcyBkcmFmdCBkaXNjdXNzaW5nPyBXaGF0IG9wZXJhdGlvbmFsIiwgd2Ugd2lsbCZuYnNwO3Zl cmlmeSBvdXIgc2Vjb25kIHZlcnNpb24mbmJzcDt3aXRoIG1vcmUgaW50dWl0aXZlJm5ic3A7ZGVz Y3JpcHRpb24uJm5ic3A7PEJSPjwvUD4NCjxQPjxCUj48L1A+DQo8UD48QlI+PC9QPg0KPFA+PEJS PjwvUD48U1BBTiBpZD1lZGl0RGl2IGNsYXNzPWVkaXRNYWlsPjxTUEFOIGlkPW5vdERyYWZ0Pjwv U1BBTj48U1BBTiBpZD11bmRlclNpZ24+PC9TUEFOPjxTUEFOIGlkPWNvbnRlbnRfb2xkPjxCUj48 QlI+PEJSPjxCUj48QlI+PEJSPjxCUj49PT09PSDlm57lpI3liY3ljp/lp4vpgq7ku7YgPT09PT08 QlI+PEJSPjxCUj48Qj7lj5Hku7bkurrvvJo8L0I+ZnJlZEBjaXNjby5jb208QlI+PEI+5pel5pyf 77yaPC9CPjIwMTIvMDMvMzEgMjA6NDU6MDE8QlI+PEI+5pS25Lu25Lq677yaPC9CPmRyYWZ0LXlh bmctdjZvcHMtZmFzdDZAdG9vbHMuaWV0Zi5vcmc8QlI+PEI+5oqE6YCB77yaPC9CPnY2b3BzLWNo YWlyc0B0b29scy5pZXRmLm9yZzxCUj48Qj7kuLvpopjvvJo8L0I+U29tZSBxdWVzdGlvbnMgb24g ZHJhZnQteWFuZy12Nm9wcy1mYXN0NjxCUj48QlI+TGV0IG1lIGFzayBzb21lIHF1ZXN0aW9ucy4g VGhpcyBpcyBub3QgaW50ZW5kZWQgdG8gcHV0IHlvdSBvZmYgb3Igb2ZmZW5kLCBidXQgdG8gaGVs cCB0aGUgY2hhaXJzIGluIHVuZGVyc3RhbmRpbmcgd2hlcmUgdGhlIGRyYWZ0IGZpdHMgaW4gdGhl IGJpZyBzY2hlbWUgb2YgdGhpbmdzLiA8QlI+PEJSPjEpIFBsZWFzZSBwcm92aWRlIGEgc3VjY2lu Y3QgcHJvYmxlbSBzdGF0ZW1lbnQgZm9yIHlvdXIgZHJhZnQuIFdoYXQgcHJvYmxlbS9pc3N1ZSBp cyB0aGlzIGRyYWZ0IGRpc2N1c3Npbmc/IFdoYXQgb3BlcmF0aW9uYWwgcHJvYmxlbXMgZG9lcyB0 aGUgcHJvcG9zYWwgYWRkcmVzcyBpbiByZWFsIGxpZmUgbmV0d29ya3M/IDxCUj48QlI+MikgV2hl cmUgZG9lcyB0aGlzIGRyYWZ0IG9yIHByZXNlbnRhdGlvbiBmaXRzIGludG8gdjZvcHMnIGN1cnJl bnQgY2hhcnRlciAoaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL3dnL3Y2b3BzL2NoYXJ0ZXIv KT8gQ2l0aW5nIHNwZWNpZmljIGEgc2VjdGlvbihzKSBvZiB0aGUgY2hhcnRlciBpcyBwcmVmZXJh YmxlLiA8QlI+PEJSPjMpIFdobyBpcyB0aGlzIGRyYWZ0J3MgYXVkaWVuY2U/IDxCUj48QlI+NCkg SGF2ZSBhbnkgb3BlcmF0b3JzIGV4cHJlc3NlZCBpbnRlcmVzdCBpbiB0aGlzIGRyYWZ0IG9yIGl0 cyBwcm9ibGVtIHNwYWNlLCBlaXRoZXIgdmlhIHJldmlldyBvciBvdGhlciBkaXNjdXNzaW9uPyA8 QlI+PEJSPjUpIElzIHRoaXMgZHJhZnQgcHVyc3VpbmcgZGlzY3Vzc2lvbiBpbiBhbnkgb3RoZXIg V0dzPyBJZiBzbywgcGxlYXNlIGxpc3QgdGhlbSBoZXJlLCBhbG9uZyB3aXRoIHJhdGlvbmFsZSBm b3IgdGhlIGludGVyYWN0aW9uIHdpdGggbXVsdGlwbGUgV0dzIGluIHBhcmFsbGVsLiA8QlI+PEJS PjYpIElzIGFueSBwcm90b2NvbCB3b3JrIGJlaW5nIHJlY29tbWVuZGVkIGluIHRoZSBkcmFmdD8g PEJSPjxCUj50aGUgY3JpdGVyaWEgdGhlIFdHIGFza2VkIG1lIHRvIGFwcGx5IGZvciBuZXcgd29y ayBvciBwcmVzZW50YXRpb24gc2xvdHMgYXJlOiA8QlI+LSByZWNlbnQgb3IgcmVjZW50bHkgdXBk YXRlZCBkcmFmdCA8QlI+LSB3aXRoaW4gY2hhcnRlciA8QlI+LSByZXN1bHRzIGluIGNvbnN0cnVj dGl2ZSBkaXNjdXNzaW9uIG9uIHRoZSBtYWlsaW5nIGxpc3QgPEJSPjxCUj5JIG5lZWQgZm9yIHlv dSB0byBwcm92b2tlIGRpc2N1c3Npb24gb24gdGhlIGxpc3QuIFlvdSBtYXkgcmVzcG9uZCB0byBt eSBvcGVuaW5nIGVtYWlsIHRvIGRvIHNvIGlmIGl0J3MgaGVscGZ1bC4gPEJSPjwvU1BBTj48L1NQ QU4+ ------=_Part_3333_17184723.1333283715416-- From fred@cisco.com Sun Apr 1 13:22:17 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D11D311E808E for ; Sun, 1 Apr 2012 13:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.299 X-Spam-Level: X-Spam-Status: No, score=-109.299 tagged_above=-999 required=5 tests=[AWL=1.299, 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 qACuDVOHN6lT for ; Sun, 1 Apr 2012 13:22:17 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 00A4311E8080 for ; Sun, 1 Apr 2012 13:22:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2211; q=dns/txt; s=iport; t=1333311737; x=1334521337; h=from:subject:date:message-id:cc:to:mime-version; bh=1l1f2hAZjW5tgAmdAr8ek+fnF97dj8vm89WQH/kBZiQ=; b=JyhrKoltgpsUnBEYE5XfGNBMKIU+mc16hKk1GNt5rdSB54Ix2bX59281 NJqdh4m2O1RIED29zWVwh5uMwrjskiz4pOhssCQ/Ak6n1v7IVCSXaXiXB wYv0aIMU4j1AjUE278I+r68aSzqjHA0kerQ4EWMb5DocgpllSh6Yst9sT o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAMm3eE+Q/khL/2dsb2JhbABCglO2N4EHgiIBZh8BgR41h2egDZYnkDljBJVhhXCIV4Fogmk X-IronPort-AV: E=Sophos;i="4.75,353,1330905600"; d="scan'208,217";a="133957491" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 01 Apr 2012 20:22:15 +0000 Received: from Freds-Computer.local (dhcp-10-55-88-198.cisco.com [10.55.88.198]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q31KMFET006480; Sun, 1 Apr 2012 20:22:15 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Sun, 01 Apr 2012 22:22:17 +0200 X-PGP-Universal: processed; by Freds-Computer.local on Sun, 01 Apr 2012 22:22:17 +0200 From: Fred Baker Date: Sun, 1 Apr 2012 20:01:35 +0200 Message-Id: <43F84362-C062-401E-97D5-C8DB27CE0E1F@cisco.com> To: IPv6 Operations Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Content-Type: multipart/alternative; boundary=Apple-Mail-77-661293961 Cc: v6ops-chairs@tools.ietf.org, Ron Bonica Subject: [v6ops] draft-ietf-v6ops-ivi-icmp-address WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2012 20:22:17 -0000 --Apple-Mail-77-661293961 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This is to initiate a two week working group last call of = draft-ietf-v6ops-ivi-icmp-address. Please read it now. If you find nits = (spelling errors, minor suggested wording changes, etc), comment to the = authors; if you find greater issues, such as disagreeing with a = statement or finding additional issues that need to be addressed, please = post your comments to the list. We are looking specifically for comments on the importance of the = document as well as its content. If you have read the document and = believe it to be of operational utility, that is also an important = comment to make.= --Apple-Mail-77-661293961 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii This is to initiate a two week working = group last call of draft-ietf-v6ops-ivi-icmp-address. Please read it = now. If you find nits (spelling errors, minor suggested = wording changes, etc), comment to the authors; if you find greater = issues, such as disagreeing with a statement or finding additional = issues that need to be addressed, please post your comments to the = list.

We are looking specifically for comments on the = importance of the document as well as its content. If you have read the = document and believe it to be of operational utility, that is also = an important comment to make.
= --Apple-Mail-77-661293961-- From joelja@bogus.com Sun Apr 1 23:40:56 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B105A11E8097 for ; Sun, 1 Apr 2012 23:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.14 X-Spam-Level: X-Spam-Status: No, score=-100.14 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 GVsgKwS2Uq5a for ; Sun, 1 Apr 2012 23:40:56 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 02AC511E8073 for ; Sun, 1 Apr 2012 23:40:55 -0700 (PDT) Received: from Joels-MacBook-Pro.local (20.128.152.78.rev.sfr.net [78.152.128.20]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q326enGc000355 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Mon, 2 Apr 2012 06:40:52 GMT (envelope-from joelja@bogus.com) Message-ID: <4F7949EA.8060701@bogus.com> Date: Mon, 02 Apr 2012 08:40:42 +0200 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: Cameron Byrne References: <4F719752.4060601@viagenie.ca> 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]); Mon, 02 Apr 2012 06:40:54 +0000 (UTC) Cc: v6ops@ietf.org Subject: Re: [v6ops] BIH vs 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 06:40:56 -0000 On 3/27/12 12:59 , Cameron Byrne wrote: > On Tue, Mar 27, 2012 at 3:32 AM, Simon Perreault > wrote: >> I was thinking that bump-in-the-host (BIH) could be used for something like >> 464XLAT, and after some questioning I was pointed to the following extract from >> RFC6535: >> >> The IETF recommends using solutions based on dual stack or tunneling >> for IPv6 transition and specifically recommends against deployments >> utilizing double protocol translation. Use of BIH together with a >> NAT64 is NOT RECOMMENDED [RFC6180]. >> > > FYI -- i fought this restriction in BEHAVE. Lost. For whatever it's worth undesirable things are still sometime necessary. >> Wouldn't this anti-recommendation also apply to 464XLAT? >> >> Did the consensus on double translation change? >> > > I have to assume so since Softwires has mountain of work that is > double translation, and in fact MAP-T is triple translation, NAT4464 Without it you're kind stuck beyond a certain point. in the 464xlat case, it's seems like that point is where you've been handed a v4 literal and you have to do something with it other than fail. > It is perhaps the situation that BIH came a few months too soon for > the IESG to be responsive to the realistic need of double translation. > > That said, 464XLAT seldom uses double translation in practice when > used together with DNS64 > > http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-01#section-6.3 > > Double translation is only invoked in the case when NAT64/DNS64 alone > would result in failure of communication due to IPv4-only sockets or > IPv4 literals. > > So, the tradeoff is double translation or communication failure. > Subscribers who don't know what IP is like the double translation > solution that loads Skype. > > There is also the fact the IESG passed this > http://tools.ietf.org/html/draft-weil-shared-transition-space-request-15 > ... which is clearly a tip of the hat to NAT444. It would be > unconscionable for the IESG to support NAT444 and not support > something that required IPv6 and enabled IPv6 like 464XLAT > > CB > >> 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 >> _______________________________________________ >> 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 v6ops@globis.net Mon Apr 2 23:38:42 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0871921F86AF for ; Mon, 2 Apr 2012 23:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jRoexkCaUpZ6 for ; Mon, 2 Apr 2012 23:38:41 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0E7EA21F86AA for ; Mon, 2 Apr 2012 23:38:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 6D6FE870130; Tue, 3 Apr 2012 08:38:39 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1nEUR42Q0kfo; Tue, 3 Apr 2012 08:38:34 +0200 (CEST) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 50BA08700D7; Tue, 3 Apr 2012 08:38:34 +0200 (CEST) Message-ID: <4F7A9AEA.5030501@globis.net> Date: Tue, 03 Apr 2012 08:38:34 +0200 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: Fred Baker References: <43F84362-C062-401E-97D5-C8DB27CE0E1F@cisco.com> In-Reply-To: <43F84362-C062-401E-97D5-C8DB27CE0E1F@cisco.com> Content-Type: multipart/alternative; boundary="------------080404000700040505060002" Cc: IPv6 Operations , v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-ivi-icmp-address WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 06:38:42 -0000 This is a multi-part message in MIME format. --------------080404000700040505060002 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I've stated previously on this list that I fundamentally disagree with this draft. After reviewing the latest text, I continue to hold this viewpoint. For the mechanism in the draft to work, untraceable packets have to be allowed across an AS boundary (section 4). It therefore negates the good work of BCP84 RFC3704 in mitigating DDoS and other untraceable attacks from spoofed addresses. This untraceable source address range will be abused. So IHMO, either network operators will filter all traffic from the newly assigned shared range, and the draft will not achieve its stated goal, or network operators will not filter this traffic, and thus expose themselves to being a transit for a DDoS attack that they cannot prove was not sourced within their AS. Either way, it will lead to an undesirable operational situation (draft not working, or operator exposed to untraceable abuse). The authors have spent considerable effort on defining mitigation measures, such as rate limiting at source, but the fact of the matter is that bad guys don't obey RFC's, and so the mitigation measures defined in the draft will not adequately protect against abuse. There are also alternatives available to assigning the proposed address range: using RFC1918 addresses within an AS, assigning a small range from a provider's existing IPv4 allocation, or even sharing assigned IPv4 PI address space across multiple providers (with one network provider taking the lead in coordinating help desk responses to queries upon abuse.) These alternatives are in no way ideal, but they will work, and are traceable back to a source/ network abuse help desk. IPv4 addresses may have run out, but we shouldn't break existing implementations and operations. regards, RayH Fred Baker wrote: > This is to initiate a two week working group last call of > draft-ietf-v6ops-ivi-icmp-address. Please read it now. If you find > nits (spelling errors, minor suggested wording changes, etc), comment > to the authors; if you find greater issues, such as disagreeing with a > statement or finding additional issues that need to be addressed, > please post your comments to the list. > > We are looking specifically for comments on the importance of the > document as well as its content. If you have read the document and > believe it to be of operational utility, that is also an important > comment to make. --------------080404000700040505060002 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I've stated previously on this list that I fundamentally disagree with this draft. After reviewing the latest text, I continue to hold this viewpoint.

For the mechanism in the draft to work, untraceable packets have to be allowed across an AS boundary (section 4). It therefore negates the good work of BCP84 RFC3704 in mitigating DDoS and other untraceable attacks from spoofed addresses.

This untraceable source address range will be abused.

So IHMO, either network operators will filter all traffic from the newly assigned shared range, and the draft will not achieve its stated goal, or network operators will not filter this traffic, and thus expose themselves to being a transit for a DDoS attack that they cannot prove was not sourced within their AS. Either way, it will lead to an undesirable operational situation (draft not working, or operator exposed to untraceable abuse).

The authors have spent considerable effort on defining mitigation measures, such as rate limiting at source, but the fact of the matter is that bad guys don't obey RFC's, and so the mitigation measures defined in the draft will not adequately protect against abuse.

There are also alternatives available to assigning the proposed address range: using RFC1918 addresses within an AS, assigning a small range from a provider's existing IPv4 allocation, or even sharing assigned IPv4 PI address space across multiple providers (with one network provider taking the lead in coordinating help desk responses to queries upon abuse.) These alternatives are in no way ideal, but they will work, and are traceable back to a source/ network abuse help desk.

IPv4 addresses may have run out, but we shouldn't break existing implementations and operations.

regards,
RayH

Fred Baker wrote:
This is to initiate a two week working group last call of draft-ietf-v6ops-ivi-icmp-address. Please read it now. If you find nits (spelling errors, minor suggested wording changes, etc), comment to the authors; if you find greater issues, such as disagreeing with a statement or finding additional issues that need to be addressed, please post your comments to the list.

We are looking specifically for comments on the importance of the document as well as its content. If you have read the document and believe it to be of operational utility, that is also an important comment to make.
--------------080404000700040505060002-- From despres.remi@laposte.net Tue Apr 3 00:32:30 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3961C21F850F for ; Tue, 3 Apr 2012 00:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[AWL=-0.200, 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 T-WF5+0lxGtH for ; Tue, 3 Apr 2012 00:32:29 -0700 (PDT) Received: from smtpout.laposte.net (smtpout3.laposte.net [193.253.67.228]) by ietfa.amsl.com (Postfix) with ESMTP id 1AC0821F84D2 for ; Tue, 3 Apr 2012 00:32:28 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8506-out with ME id tKYN1i00537Y3f403KYNYM; Tue, 03 Apr 2012 09:32:26 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 3 Apr 2012 09:32:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1825062D-D4EB-4310-A2BA-8B8F3870B9B4@laposte.net> References: <7E1BD96D-E7EC-4C78-B382-66F0F694DAA4@laposte.net> To: Cameron Byrne X-Mailer: Apple Mail (2.1084) Cc: IPv6 Operations , draft-ietf-v6ops-464xlat@tools.ietf.org, v6ops-ads@tools.ietf.org, Softwire Chairs Subject: Re: [v6ops] A way forward for 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 07:32:30 -0000 Hi, Cameron, Sorry for the late answer (was on second priority for a few days). Le 2012-03-27 =E0 12:38, Cameron Byrne a =E9crit : > hi, >=20 > On Tue, Mar 27, 2012 at 1:17 AM, R=E9mi Despr=E9s = wrote: >>=20 >> Le 2012-03-27 =E0 04:34, Fred Baker a =E9crit : ... >>>=20 >>> The objections raised in the working group come down to: >>> - the authors of said other documents would like to have a = conversation with the 464XLAT folks >>> - What's this about a prefix::/96? >>> - What's this about a proxy service? >>=20 >> There was also a point about NAT44 in CLAT nodes or not (point = discussed on the ML) >>=20 >=20 > The NAT44 text on the CLAT has been integrated here: >=20 > http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-01#section-6.5 >=20 > "Alternatively, the CLAT may do NAT44 > such that all private IPv4 sourced LAN packets appears from one > private IPv4 address which is statelessly translated to one IPv6 > address that the CLAT will own as a host IPv6 address from an IPv6 > /64 interface." Thanks, good enough for me. >> May I add that the relationship between 464XLAT and BIH (RFC6535) = would also be worth clarifying. (I see high similarity: v4 only = applications communicating in IPv6). >>=20 >=20 > BIH explicitly does not allow double translation, it's scope is > explicitly limited to the case of using IPv4 applications to IPv6-only > servers. I objected to this limitation in BEHAVE. But, it is what it > is. BIH "recommends" to avoid double translation. This AFAIK permits it if good reasons are found. > That said, 464XLAT authors have found rfc6145 to be the best fit for > IPv4->IPv6 translation, including support for the function in a more > generic node such as a router (home gateway CPE, mobile phone as a > host, mobile phone as a wifi router, ...) BIH does include RFC6145 translation. > where BIH is constrained to > a host only style implementation that relies on host level API > modification and interaction A host can also be also a router, in particular if it includes a NAT44. I see nothing that prevents using it in this case. >>> - What's this about normative language? >>=20 >>> - How does it fit the the mdt-softwire-map specifications, which >>> appear to have a growing consensus behind them in softwire? >>=20 >> The point made during the meeting was about the work in Softwire in = general. replacing this point by a reference to the mdt draft is a = biased interpretation. >> In Softwire, a choice between MAP and Unified is scheduled for Friday = morning. As chair of v6ops, it would be better to avoid making a = Softwire choice before the scheduled debate has taken place (IMHO). >> Thanks. >>=20 >=20 > I hope my previous emails have made the case for a stateful solution > clear and useful I thought we had both understood that there are needs for stateful AND = ALSO for stateless, in particular where mesh topologies are desirable. = This depends on provider cases. End of this issue for me. =20 > As it stands, there is no workable stateful (more IPv4 address > efficient / intensive) IETF method of operating in an IPv6-only access > network. =20 > NAT64/DNS64 is not workable, since 15% of applications on > mobile (something similar for desktop) fail to work without some way > to deal with IPv4 specific sockets and IPv4 literals. Can we agree to only say that NAT64/DNS64 is NOT SUFFICIENT? (Without = saying that it doesn't do work for what it has been designed for).=20 Regards, RD >=20 > CB >> regards, >> RD >>=20 >>=20 >>>=20 >>> Before you continue reading this note, please stop and read these = two sections: >>> http://tools.ietf.org/html/rfc2026#section-4.2.2 >>> http://tools.ietf.org/html/rfc2026#section-5 >>>=20 >>> =46rom my perspective, and from reading those definitions, an = Informational Document is a white paper, while a BCP is something that a = significant and relevant part of the Internet COmmunity agrees to, and >>>=20 >>> ...since the Internet itself is composed of networks operated by a = great >>> variety of organizations, with diverse goals and rules, good user >>> service requires that the operators and administrators of the >>> Internet follow some common guidelines for policies and operations. >>>=20 >>> In other words, operational service models, while not strictly = speaking "protocols", can be described in a BCP *standard* as "how to = implement a certain service". This is in no sense "the best" or "only = way to deploy RFCs 6145/6146", but it might be "the best way to deploy = the CLAT service". v6ops is authorized, by charter, to write = informational and BCP documents. >>>=20 >>> And since a BCP describes the set of things that one MUST or SHOULD = do in deploying such a service, RFC 2119 language regarding that = specific service may be acceptable in a BCP describing that service. >>>=20 >>>=20 >>> With that preparatory reasoning, it seems to me that we need to = separate the contentious parts of the specification so that = uncontentious parts can go forward, and other parts can be discussed - = whether in this working group or another one. >>>=20 >>>=20 >>> Given the points of contention, it seems that the separation needs = to be among three documents. >>>=20 >>> The first is a specification - a BCP - for the CLAT service. It = refers to RFCs 6052/6144/6145/6146/6147, and describes how translation = is used in this context using normative language. It does not refer to a = prefix::/96; it refers to RFC 6052. My understanding is that several = people have said that this specification is interesting and useful. >>>=20 >>> The second is a separate specification for the proxy service, which = is contentious. Being separated, it can be discussed and beaten to death = as needed. The first specification says that the CLAT service MAY = implement this proxy service. I'm not sure whether that is BCP or = Informational; we can discuss that in the context of the rest of the = discussion of the proxy service. >>>=20 >>> The third is a report on the trial deployment of the CLAT service by = the various companies in question. This is an informational document. >>>=20 >>> Am I making sense? Would this be an acceptable way forward? >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops From cb.list6@gmail.com Tue Apr 3 07:15:12 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E206B11E80B2 for ; Tue, 3 Apr 2012 07:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.898 X-Spam-Level: X-Spam-Status: No, score=-3.898 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wRPRMXp3TqCB for ; Tue, 3 Apr 2012 07:15:11 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 75E0D11E809A for ; Tue, 3 Apr 2012 07:15:11 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so3688055obb.31 for ; Tue, 03 Apr 2012 07:15:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MTFWikAa9tAp7zKWWNzWBad74fX3Czb+SLGXSCF0faI=; b=bfszTGMExGZvBavoQHvlAfpuUwWTQZW8SympRlM/BVh35mPWA8Vp7mysT5AKxwVrxV zauksHNdCN/uODcf1KnAhj5ZeqwyaiSWco1SYj9CYsnxMFQY5+lw8MfGGMoy818/CiAb J3pwz0qj0lArWComg/NU1bWoZRKDea6vkOuj5fNrBUCBXzAbMDJm/upELmrtHPdZbTxP 5NCl7BNNX/jwlUiMKesKSHIrv/QdbmMEyQsalyzIB+FrUqJbMh/UU7B8YbMesaf7z3Ty 4Mb3WpKVpI9JQNgHyb97/LbFDQUdUhzCR3UA7BIYjH/pgIBRUtpqGF4kggerO8GComgf Incw== MIME-Version: 1.0 Received: by 10.182.227.37 with SMTP id rx5mr19043671obc.53.1333462511050; Tue, 03 Apr 2012 07:15:11 -0700 (PDT) Received: by 10.182.226.72 with HTTP; Tue, 3 Apr 2012 07:15:10 -0700 (PDT) Received: by 10.182.226.72 with HTTP; Tue, 3 Apr 2012 07:15:10 -0700 (PDT) In-Reply-To: <1825062D-D4EB-4310-A2BA-8B8F3870B9B4@laposte.net> References: <7E1BD96D-E7EC-4C78-B382-66F0F694DAA4@laposte.net> <1825062D-D4EB-4310-A2BA-8B8F3870B9B4@laposte.net> Date: Tue, 3 Apr 2012 07:15:10 -0700 Message-ID: From: Cameron Byrne To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=f46d0444737d4ae19b04bcc6efe5 Cc: IPv6 Operations , Softwire Chairs , v6ops-ads@tools.ietf.org, draft-ietf-v6ops-464xlat Subject: Re: [v6ops] A way forward for 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 14:15:13 -0000 --f46d0444737d4ae19b04bcc6efe5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Apr 3, 2012 12:32 AM, "R=E9mi Despr=E9s" wrot= e: > > Hi, Cameron, > > Sorry for the late answer (was on second priority for a few days). > > Le 2012-03-27 =E0 12:38, Cameron Byrne a =E9crit : > > > hi, > > > > On Tue, Mar 27, 2012 at 1:17 AM, R=E9mi Despr=E9s wrote: > >> > >> Le 2012-03-27 =E0 04:34, Fred Baker a =E9crit : > ... > >>> > >>> The objections raised in the working group come down to: > >>> - the authors of said other documents would like to have a conversation with the 464XLAT folks > >>> - What's this about a prefix::/96? > >>> - What's this about a proxy service? > >> > >> There was also a point about NAT44 in CLAT nodes or not (point discussed on the ML) > >> > > > > The NAT44 text on the CLAT has been integrated here: > > > > http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-01#section-6.5 > > > > "Alternatively, the CLAT may do NAT44 > > such that all private IPv4 sourced LAN packets appears from one > > private IPv4 address which is statelessly translated to one IPv6 > > address that the CLAT will own as a host IPv6 address from an IPv6 > > /64 interface." > > Thanks, good enough for me. > > >> May I add that the relationship between 464XLAT and BIH (RFC6535) would also be worth clarifying. (I see high similarity: v4 only applications communicating in IPv6). > >> > > > > BIH explicitly does not allow double translation, it's scope is > > explicitly limited to the case of using IPv4 applications to IPv6-only > > servers. I objected to this limitation in BEHAVE. But, it is what it > > is. > > BIH "recommends" to avoid double translation. > This AFAIK permits it if good reasons are found. > Yes, it is an all capital letter recommendation. As you likely well know, ipv6 transition is an ecosystem transition and recommendations like the one in BIH become a lightening rod for confusion. We can leave it at that. > > That said, 464XLAT authors have found rfc6145 to be the best fit for > > IPv4->IPv6 translation, including support for the function in a more > > generic node such as a router (home gateway CPE, mobile phone as a > > host, mobile phone as a wifi router, ...) > > BIH does include RFC6145 translation. > If I read section 2.3 correctly of bih, it requires all sessions be created by enr. In the network implementation of bih, bih cannot support ipv4 communication that does not start with DNS because DNS triggers the enr. So, bih on a router cannot facilitate for a client of the router a Skype call since Skype signals ipv4 literals. The bih router (which does not exist) cannot create the enr triggered session mappings with capturing DNS first. > > where BIH is constrained to > > a host only style implementation that relies on host level API > > modification and interaction > > A host can also be also a router, in particular if it includes a NAT44. > I see nothing that prevents using it in this case. > I don't believe bih had this use case in scope. The diagrams and text in bih make reference to a host, not a host / router. Trust me, if bih worked as you suggest, my life would be much easier. If bih officially worked with nat64 and did not require the enr mapper so that it supported ipv4 literals in network mode, that would be great. In fact, I pushed for both when bih was a draft in behave. > >>> - What's this about normative language? > >> > >>> - How does it fit the the mdt-softwire-map specifications, which > >>> appear to have a growing consensus behind them in softwire? > >> > >> The point made during the meeting was about the work in Softwire in general. replacing this point by a reference to the mdt draft is a biased interpretation. > >> In Softwire, a choice between MAP and Unified is scheduled for Friday morning. As chair of v6ops, it would be better to avoid making a Softwire choice before the scheduled debate has taken place (IMHO). > >> Thanks. > >> > > > > I hope my previous emails have made the case for a stateful solution > > clear and useful > > I thought we had both understood that there are needs for stateful AND ALSO for stateless, in particular where mesh topologies are desirable. This depends on provider cases. > End of this issue for me. > We do agree. > > As it stands, there is no workable stateful (more IPv4 address > > efficient / intensive) IETF method of operating in an IPv6-only access > > network. > > > NAT64/DNS64 is not workable, since 15% of applications on > > mobile (something similar for desktop) fail to work without some way > > to deal with IPv4 specific sockets and IPv4 literals. > > Can we agree to only say that NAT64/DNS64 is NOT SUFFICIENT? (Without saying that it doesn't do work for what it has been designed for). > We agree on this too. Cb > Regards, > RD > > > > > CB > >> regards, > >> RD > >> > >> > >>> > >>> Before you continue reading this note, please stop and read these two sections: > >>> http://tools.ietf.org/html/rfc2026#section-4.2.2 > >>> http://tools.ietf.org/html/rfc2026#section-5 > >>> > >>> From my perspective, and from reading those definitions, an Informational Document is a white paper, while a BCP is something that a significant and relevant part of the Internet COmmunity agrees to, and > >>> > >>> ...since the Internet itself is composed of networks operated by a great > >>> variety of organizations, with diverse goals and rules, good user > >>> service requires that the operators and administrators of the > >>> Internet follow some common guidelines for policies and operations. > >>> > >>> In other words, operational service models, while not strictly speaking "protocols", can be described in a BCP *standard* as "how to implement a certain service". This is in no sense "the best" or "only way to deploy RFCs 6145/6146", but it might be "the best way to deploy the CLAT service". v6ops is authorized, by charter, to write informational and BCP documents. > >>> > >>> And since a BCP describes the set of things that one MUST or SHOULD do in deploying such a service, RFC 2119 language regarding that specific service may be acceptable in a BCP describing that service. > >>> > >>> > >>> With that preparatory reasoning, it seems to me that we need to separate the contentious parts of the specification so that uncontentious parts can go forward, and other parts can be discussed - whether in this working group or another one. > >>> > >>> > >>> Given the points of contention, it seems that the separation needs to be among three documents. > >>> > >>> The first is a specification - a BCP - for the CLAT service. It refers to RFCs 6052/6144/6145/6146/6147, and describes how translation is used in this context using normative language. It does not refer to a prefix::/96; it refers to RFC 6052. My understanding is that several people have said that this specification is interesting and useful. > >>> > >>> The second is a separate specification for the proxy service, which is contentious. Being separated, it can be discussed and beaten to death as needed. The first specification says that the CLAT service MAY implement this proxy service. I'm not sure whether that is BCP or Informational; we can discuss that in the context of the rest of the discussion of the proxy service. > >>> > >>> The third is a report on the trial deployment of the CLAT service by the various companies in question. This is an informational document. > >>> > >>> Am I making sense? Would this be an acceptable way forward? > >> > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops > --f46d0444737d4ae19b04bcc6efe5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Apr 3, 2012 12:32 AM, "R=E9mi Despr=E9s" <despres.remi@laposte.net> wrote:
>
> Hi, Cameron,
>
> Sorry for the late answer (was on second priority for a few days).
>
> Le 2012-03-27 =E0 12:38, Cameron Byrne a =E9crit :
>
> > hi,
> >
> > On Tue, Mar 27, 2012 at 1:17 AM, R=E9mi Despr=E9s <despres.remi@laposte.net> wrote: > >>
> >> Le 2012-03-27 =E0 04:34, Fred Baker a =E9crit :
> ...
> >>>
> >>> The objections raised in the working group come down to:<= br> > >>> =A0 - the authors of said other documents would like to h= ave a conversation with the 464XLAT folks
> >>> =A0 - What's this about a prefix::/96?
> >>> =A0 - What's this about a proxy service?
> >>
> >> There was also a point about NAT44 in CLAT nodes or not (poin= t discussed on the ML)
> >>
> >
> > The NAT44 text on the CLAT has been integrated here:
> >
> > http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-01#sectio= n-6.5
> >
> > "Alternatively, the CLAT may do NAT44
> > =A0 such that all private IPv4 sourced LAN packets appears from o= ne
> > =A0 private IPv4 address which is statelessly translated to one I= Pv6
> > =A0 address that the CLAT will own as a host IPv6 address from an= IPv6
> > =A0 /64 interface."
>
> Thanks, good enough for me.
>
> >> May I add that the relationship between 464XLAT and BIH (RFC6= 535) would also be worth clarifying. (I see high similarity: v4 only applic= ations communicating in IPv6).
> >>
> >
> > BIH explicitly does not allow double translation, it's scope = is
> > explicitly limited to the case of using IPv4 applications to IPv6= -only
> > servers. =A0I objected to this limitation in BEHAVE. =A0But, it i= s what it
> > is.
>
> BIH "recommends" to avoid double translation.
> This AFAIK permits it if good reasons are found.
>

Yes, it is an all capital letter recommendation.=A0 As you likely well k= now, ipv6 transition is an ecosystem transition and recommendations like th= e one in BIH become a lightening rod for confusion. We can leave it at that= .

> > That said, 464XLAT authors have found rfc6145 to be the best f= it for
> > IPv4->IPv6 translation, including support for the function in = a more
> > generic node such as a router (home gateway CPE, mobile phone as = a
> > host, mobile phone as a wifi router, ...)
>
> BIH does include RFC6145 translation.
>

If I read section 2.3 correctly of bih, it requires all sessions be crea= ted by enr.

In the network implementation of bih, bih cannot support ipv4 communicat= ion that does not start with DNS because DNS triggers the enr. So, bih on a= router cannot facilitate for a client of=A0 the router a Skype call=A0 sin= ce Skype signals ipv4 literals.
The bih router (which does not exist) cannot create the enr triggered sessi= on mappings with capturing DNS first.

> > where BIH is constrained to
> > a host only style implementation that relies on host level API > > modification and interaction
>
> A host can also be also a router, in particular if it includes a NAT44= .
> I see nothing that prevents using it in this case.
>

I don't believe bih had this use case in scope. The diagrams and tex= t in bih make reference to a host, not a host / router.

Trust me, if bih worked as you suggest, my life would be much easier. If= bih officially worked with nat64 and did not require the enr mapper so tha= t it supported ipv4 literals in network mode, that would be great. In fact,= I pushed for both when bih was a draft in behave.

> >>> =A0 - What's this about normative language?
> >>
> >>> =A0 - How does it fit the the mdt-softwire-map specificat= ions, which
> >>> =A0 =A0 appear to have a growing consensus behind them in= softwire?
> >>
> >> The point made during the meeting was about the work in Softw= ire in general. replacing this point by a reference to the mdt draft is a b= iased interpretation.
> >> In Softwire, a choice between MAP and Unified is scheduled fo= r Friday morning. As chair of v6ops, it would be better to avoid making a S= oftwire choice before the scheduled debate has taken place (IMHO).
> >> Thanks.
> >>
> >
> > I hope my previous emails have made the case for a stateful solut= ion
> > clear and useful
>
> I thought we had both understood that there are needs for stateful AND= ALSO for stateless, in particular where mesh topologies are desirable. Thi= s depends on provider cases.
> End of this issue for me.
>

We do agree.

> > As it stands, there is no workable stateful (more IPv4 address=
> > efficient / intensive) IETF method of operating in an IPv6-only a= ccess
> > network.
>
> > NAT64/DNS64 is not workable, since 15% of applications on
> > mobile (something similar for desktop) fail to work without some = way
> > to deal with IPv4 specific sockets and IPv4 literals.
>
> Can we agree to only say that NAT64/DNS64 is NOT SUFFICIENT? (Without = saying that it doesn't do work for what it has been designed for).
>

We agree on this too.

Cb
> Regards,
> RD
>
> >
> > CB
> >> regards,
> >> RD
> >>
> >>
> >>>
> >>> Before you continue reading this note, please stop and re= ad these two sections:
> >>> =A0 http://tools.ietf.org/html/rfc2026#section-4.2.2
> >>> =A0 http://tools.ietf.org/html/rfc2026#section-5
> >>>
> >>> From my perspective, and from reading those definitions, = an Informational Document is a white paper, while a BCP is something that a= significant and relevant part of the Internet COmmunity agrees to, and
> >>>
> >>> ...since the Internet itself is composed of networks oper= ated by a great
> >>> =A0variety of organizations, with diverse goals and rules= , good user
> >>> =A0service requires that the operators and administrators= of the
> >>> =A0Internet follow some common guidelines for policies an= d operations.
> >>>
> >>> In other words, operational service models, while not str= ictly speaking "protocols", can be described in a BCP *standard* = as "how to implement a certain service". This is in no sense &quo= t;the best" or "only way to deploy RFCs 6145/6146", but it m= ight be "the best way to deploy the CLAT service". v6ops is autho= rized, by charter, to write informational and BCP documents.
> >>>
> >>> And since a BCP describes the set of things that one MUST= or SHOULD do in deploying such a service, RFC 2119 language regarding that= specific service may be acceptable in a BCP describing that service.
> >>>
> >>>
> >>> With that preparatory reasoning, it seems to me that we n= eed to separate the contentious parts of the specification so that unconten= tious parts can go forward, and other parts can be discussed - whether in t= his working group or another one.
> >>>
> >>>
> >>> Given the points of contention, it seems that the separat= ion needs to be among three documents.
> >>>
> >>> The first is a specification - a BCP - for the CLAT servi= ce. It refers to RFCs 6052/6144/6145/6146/6147, and describes how translati= on is used in this context using normative language. It does not refer to a= prefix::/96; it refers to RFC 6052. My understanding is that several peopl= e have said that this specification is interesting and useful.
> >>>
> >>> The second is a separate specification for the proxy serv= ice, which is contentious. Being separated, it can be discussed and beaten = to death as needed. The first specification says that the CLAT service MAY = implement this proxy service. I'm not sure whether that is BCP or Infor= mational; we can discuss that in the context of the rest of the discussion = of the proxy service.
> >>>
> >>> The third is a report on the trial deployment of the CLAT= service by the various companies in question. This is an informational doc= ument.
> >>>
> >>> Am I making sense? Would this be an acceptable way forwar= d?
> >>
> >> _______________________________________________
> >> v6ops mailing list
> >> v6ops@ietf.org
> >> https= ://www.ietf.org/mailman/listinfo/v6ops
>

--f46d0444737d4ae19b04bcc6efe5-- From sarikaya2012@gmail.com Wed Apr 4 08:36:41 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E36C821F85AA; Wed, 4 Apr 2012 08:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gs9PE1uZOnR2; Wed, 4 Apr 2012 08:36:41 -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 31B0421F859A; Wed, 4 Apr 2012 08:36:41 -0700 (PDT) Received: by iazz13 with SMTP id z13so596447iaz.31 for ; Wed, 04 Apr 2012 08:36:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:cc :content-type; bh=0IFHs7OmCVojInDug3WkMb1WhOQO6LcSt1FccI8v8WM=; b=ZtGzpL97wafhTgK7TgxNeafQaQWMC8Fd1jslNFzqc1sjmK6tDKcbMp+G4ah4cm85+/ A5IEbZG2GW9doGIukrio1pvu8rCvve8/kUs1+McxTPDHr5iAignkaqJsJJZLipErpRn2 RVVoqJVDXT0k4kv7lzfANvO2Dw7KUe+kDetTpFQ7x8J27G8huJPvLXt7F4tec7WF8E20 /3ZTHMXzqevehKm1RsWuXKfOFVYU3M9mWghwtn9qhAYC0jCY+yvrkpn1/EEItI3ESM5H ABHR44rDzxAbl9QLOKJNFhfoXOSBRDm0gJSdZp8S0ZUjFcCMPH02JiOHq+y/+RJ6YOhq ZoxQ== MIME-Version: 1.0 Received: by 10.50.222.131 with SMTP id qm3mr2023195igc.66.1333553800886; Wed, 04 Apr 2012 08:36:40 -0700 (PDT) Received: by 10.231.8.99 with HTTP; Wed, 4 Apr 2012 08:36:40 -0700 (PDT) Date: Wed, 4 Apr 2012 10:36:40 -0500 Message-ID: From: Behcet Sarikaya To: Internet Area , v6ops@ietf.org, Softwires-wg , netext@ietf.org, dmm@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Dirk.von-Hugo@telekom.de Subject: [v6ops] Announcing fmc mailing list 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, 04 Apr 2012 15:36:42 -0000 A new list has been created for fixed mobile convergence (FMC) discussions, fmc@ietf.org. If interested, please subscribe the list using this link: https://www.ietf.org/mailman/listinfo/fmc Regards, Behcet & Dirk From marc.blanchet@viagenie.ca Wed Apr 4 08:41:31 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2262221F858A; Wed, 4 Apr 2012 08:41:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.448 X-Spam-Level: X-Spam-Status: No, score=-102.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, 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 4wuzBGjVL9VC; Wed, 4 Apr 2012 08:41:30 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 9C63721F8589; Wed, 4 Apr 2012 08:41:30 -0700 (PDT) Received: from h99.viagenie.ca (h99.viagenie.ca [206.123.31.99]) by jazz.viagenie.ca (Postfix) with ESMTPSA id A1731400B4; Wed, 4 Apr 2012 11:41:28 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_4827F702-2DE3-4027-B041-1A0954E2F14D" From: Marc Blanchet In-Reply-To: Date: Wed, 4 Apr 2012 11:41:27 -0400 Message-Id: <0012EA6C-65E9-4B1C-8411-86C2B4ABCC24@viagenie.ca> References: To: sarikaya@ieee.org X-Mailer: Apple Mail (2.1257) Cc: v6ops@ietf.org, Internet Area , netext@ietf.org, dmm@ietf.org, Dirk.von-Hugo@telekom.de, Softwires-wg Subject: Re: [v6ops] [Int-area] Announcing fmc mailing list X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 15:41:31 -0000 --Apple-Mail=_4827F702-2DE3-4027-B041-1A0954E2F14D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi, the description of the mailing list says: " serving access to = multi-interface terminals". Looks like MIF to me. - how is this different from MIF? - why did the MIF ML was not part of the "multicast"? Marc. Le 2012-04-04 =E0 11:36, Behcet Sarikaya a =E9crit : > A new list has been created for fixed mobile convergence (FMC) > discussions, fmc@ietf.org. >=20 > If interested, please subscribe the list using this link: >=20 > https://www.ietf.org/mailman/listinfo/fmc >=20 > Regards, >=20 > Behcet & Dirk > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area --Apple-Mail=_4827F702-2DE3-4027-B041-1A0954E2F14D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1  serving access to multi-interface terminals".  Looks = like MIF to me.
- how is this different from = MIF?
- why did the MIF ML was not part = of the "multicast"?

Marc.

Le 2012-04-04 =E0 11:36, Behcet = Sarikaya a =E9crit :

A new = list has been created for fixed mobile convergence (FMC)
discussions, = fmc@ietf.org.

If interested, = please subscribe the list using this link:

https://www.ietf.org/ma= ilman/listinfo/fmc

Regards,

Behcet & = Dirk
_______________________________________________
Int-area = mailing = list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-are= a

= --Apple-Mail=_4827F702-2DE3-4027-B041-1A0954E2F14D-- From wwwrun@rfc-editor.org Wed Apr 4 07:24:54 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 467AE21F86D3 for ; Wed, 4 Apr 2012 07:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.225 X-Spam-Level: X-Spam-Status: No, score=-102.225 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8gIYw77i3Msv for ; Wed, 4 Apr 2012 07:24:52 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id ABE6C21F8739 for ; Wed, 4 Apr 2012 07:24:44 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 0427E72E041; Wed, 4 Apr 2012 07:24:29 -0700 (PDT) To: shemant@cisco.com, wbeebee@cisco.com, c.donley@cablelabs.com, barbara.stark@att.com, ot@cisco.com, rbonica@juniper.net, bclaise@cisco.com, fred.baker@cisco.com, joelja@bogus.com From: RFC Errata System Message-Id: <20120404142429.0427E72E041@rfc-editor.org> Date: Wed, 4 Apr 2012 07:24:29 -0700 (PDT) X-Mailman-Approved-At: Wed, 04 Apr 2012 13:10:43 -0700 Cc: v6ops@ietf.org, rfc-editor@rfc-editor.org, Sathya_1981_25@yahoo.co.in Subject: [v6ops] [Technical Errata Reported] RFC6204 (3175) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 14:24:54 -0000 The following errata report has been submitted for RFC6204, "Basic Requirements for IPv6 Customer Edge Routers". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6204&eid=3175 -------------------------------------- Type: Technical Reported by: Sathyanarayana Venkataramanappa Section: 4.2 Original Text ------------- WPD-3: The IPv6 CE router MUST be prepared to accept a delegated prefix size different from what is given in the hint. If the delegated prefix is too small to address all of its interfaces, the IPv6 CE router SHOULD log a system management error. Corrected Text -------------- WPD-3: The IPv6 CE router MUST be prepared to accept a delegated prefix size different from what is given in the hint. If the delegated prefix is too small to address all of its interfaces or delegated prefix size is greater than /64, the IPv6 CE router SHOULD log a system management error. Notes ----- Stateless Address Auto configuration uses 64 bit long EUI-64. If Delegated prefix size obtained on the wan side is greater than /64. This Prefix cannot be used on Lan side nodes to create SLAAC address using EUI-64 Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6204 (draft-ietf-v6ops-ipv6-cpe-router-09) -------------------------------------- Title : Basic Requirements for IPv6 Customer Edge Routers Publication Date : April 2011 Author(s) : H. Singh, W. Beebee, C. Donley, B. Stark, O. Troan, Ed. Category : INFORMATIONAL Source : IPv6 Operations Area : Operations and Management Stream : IETF Verifying Party : IESG From wbeebee@cisco.com Wed Apr 4 10:11:13 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91BA921F8770 for ; Wed, 4 Apr 2012 10:11:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.532 X-Spam-Level: X-Spam-Status: No, score=-8.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 7cy8sZLt8Q-f for ; Wed, 4 Apr 2012 10:11:08 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 29C1421F8793 for ; Wed, 4 Apr 2012 10:11:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wbeebee@cisco.com; l=2709; q=dns/txt; s=iport; t=1333559468; x=1334769068; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=0AIKEtIEWp6e9Zj/lNIqtorZ7BkcZCu4q5BlcjpEfmk=; b=Pwgjpc44o+dzAHy3vXjktlojsb7nUtYhN3x3MlwA4dbzPAOQ4heT9/dm sm5KPVesHPrGG+rfw0bYZClBjMZCFcTaTWLXklf+XS1yw2+7wCZScoGK+ sMyYH/jva9DW13+BvX4aYjcZVgLlxC99y23m4tcLQ7Vz7QmfY5AITEups M=; X-IronPort-AV: E=Sophos;i="4.75,370,1330905600"; d="scan'208";a="71860165" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 04 Apr 2012 17:11:07 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id q34HB73d015602; Wed, 4 Apr 2012 17:11:07 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, 4 Apr 2012 12:11:07 -0500 Received: from 161.44.175.143 ([161.44.175.143]) by XMB-RCD-201.cisco.com ([72.163.62.208]) with Microsoft Exchange Server HTTP-DAV ; Wed, 4 Apr 2012 17:11:07 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Wed, 04 Apr 2012 13:11:06 -0400 From: Wes Beebee To: "rfc-editor@rfc-editor.org" , , , , , , , , Message-ID: Thread-Topic: [Technical Errata Reported] RFC6204 (3175) Thread-Index: Ac0ShevSTsGRm7Mzt0WRa8b9W6WVJQ== In-Reply-To: <20120404142429.0427E72E041@rfc-editor.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 04 Apr 2012 17:11:07.0650 (UTC) FILETIME=[ECCE3620:01CD1285] X-Mailman-Approved-At: Wed, 04 Apr 2012 13:10:43 -0700 Cc: v6ops@ietf.org, Sathya_1981_25@yahoo.co.in Subject: Re: [v6ops] [Technical Errata Reported] RFC6204 (3175) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 17:11:13 -0000 Given that part of "addressing all of its interfaces" implies handing out prefixes on those interfaces from which SLAAC addresses will be constructed, the "greater than /64" is already implied in the original WPD-3. Do we need to make this implication explicit? - Wes On 4/4/12 10:24 AM, "rfc-editor@rfc-editor.org" wrote: > > The following errata report has been submitted for RFC6204, > "Basic Requirements for IPv6 Customer Edge Routers". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6204&eid=3175 > > -------------------------------------- > Type: Technical > Reported by: Sathyanarayana Venkataramanappa > > Section: 4.2 > > Original Text > ------------- > WPD-3: The IPv6 CE router MUST be prepared to accept a delegated > > prefix size different from what is given in the hint. If the > > delegated prefix is too small to address all of its > > interfaces, the IPv6 CE router SHOULD log a system management > > error. > > > > > > Corrected Text > -------------- > WPD-3: The IPv6 CE router MUST be prepared to accept a delegated > > prefix size different from what is given in the hint. If the > > delegated prefix is too small to address all of its > > interfaces or delegated prefix size is greater than /64, the > > IPv6 CE router SHOULD log a system management > > error. > > > > > > > > Notes > ----- > Stateless Address Auto configuration uses 64 bit long EUI-64. If Delegated > prefix size obtained on the wan side is greater than /64. This Prefix cannot > be used on Lan side nodes to create SLAAC address using EUI-64 > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC6204 (draft-ietf-v6ops-ipv6-cpe-router-09) > -------------------------------------- > Title : Basic Requirements for IPv6 Customer Edge Routers > Publication Date : April 2011 > Author(s) : H. Singh, W. Beebee, C. Donley, B. Stark, O. Troan, Ed. > Category : INFORMATIONAL > Source : IPv6 Operations > Area : Operations and Management > Stream : IETF > Verifying Party : IESG From joelja@bogus.com Thu Apr 5 18:18:30 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67B8321F86F1 for ; Thu, 5 Apr 2012 18:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.347 X-Spam-Level: X-Spam-Status: No, score=-98.347 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, LOCALPART_IN_SUBJECT=2.02, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPwB8r5AgiKM for ; Thu, 5 Apr 2012 18:18:29 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id C113D21F8624 for ; Thu, 5 Apr 2012 18:18:29 -0700 (PDT) Received: from Joels-MacBook-Pro.local (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q361IQ3r099499 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 6 Apr 2012 01:18:27 GMT (envelope-from joelja@bogus.com) Message-ID: <4F7D563D.1030805@bogus.com> Date: Thu, 05 Apr 2012 10:22:21 +0200 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: IPv6 Ops WG , V6ops Chairs Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Fri, 06 Apr 2012 01:18:29 +0000 (UTC) Subject: [v6ops] v6ops - Draft minutes Monday March 26th 0900 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 01:18:30 -0000 0900 meeting commences Agenda Bashing 6204bis dicussion is moved to thursday. draft-carpenter-v6ops-label-balance moves to moday Fred - iesg is asking about interim meeting to coincided with ripe meeting e.g. 24-28th of sept Question, how many will be a at ripe anyway? Answer, about a dozen hands. Low hum in favor. No opposition. First presentation - Experiences from IPv6-Only Networks with Transition Technologies in the WIDE Camp Spring 2012 http://www.ietf.org/proceedings/83/slides/slides-83-v6ops-0.pdf mtu issues particularly with udp vpn applications many implmentation issues with nat64 and dns64 Fred B - Question, long term plans for the draft? Answer, and camp in sept updated version of the draft will follow. Second presentation - draft-donley-behave-deterministic-cgn-01 http://www.ietf.org/proceedings/83/slides/slides-83-v6ops-1.pdf hinges on the question of address assignment efficiency due to fixed assignment of port resources. documented in draft that compression works fairly well between 10-100 users per ip. Fred B - Postponing question of whether would should take it until it ADs get back to us. test for donneley (done after following presentation) hum (mostly in favor) (minor opposition) Third presentation - NAT64 Operational Experience http://www.ietf.org/proceedings/83/slides/slides-83-v6ops-2.ppt comments leading to updates of draft-chen-v6ops-nat64- experience-01 Moake chen - same question on the mtu statement Iljitsch B - so the ipv4 servers should set their mtu to at least 1260. good work item for v4 exit wg. Fred B - hold off or do it now? assuming there is no v4 exit is this a document suitable for this wg? hum (no support for) (or against) Fourth Presentation - 464XLAT Combination of Stateful and Stateless Translation http://www.ietf.org/proceedings/83/slides/slides-83-v6ops-3.ppt Lorenzo C - like this as a hack to bring carrier pigeon quality v4 to v6 only devices. don't understand why the device needs a /96 (teathering) should should work with a /128 Fred B - history of draft ask softwire and behave chairs what they thought of it. right resolution to the narmative language is to split the document into the bcp for providing the service and another draft on the implementation report. seperate them. Lorenzo C - it's not a bcp right, you can do this using existing technology Philip M - service providers like standards. Janos M - I am very much against BCP Remi D - Support informational think coordination with software is required. Hui D - useful as short term before 3gpp rel 8 Question, does /96 requirement removal, remove objections to progress? Answer, 6 hands consider it a problem, 3 would not object after removal. Fifth Presentation - Stateless Source address mapping for ICMPv6 packets http://www.ietf.org/proceedings/83/slides/slides-83-v6ops-5.ppt Fred B - we'll take it to WG last call on the mailing list. Sixth Presentation - IPv6 Guidance for Internet Content and Application Service Providers Lee H - it's a good doc Erik K - it's probably a good starting point. Hum for acceptance (some yes ) (no opposition) Fred B - repost as draft IETF Seventh Presentation - IPv6 Flow label for server load balancing http://www.ietf.org/proceedings/83/slides/slides-83-v6ops-8.ppt Iljitsch B - it's dangerous to assume that the flow label is never going to change mid-session Lorenzo C - if the lb trusts the client to determine lb then you probably need to reset the label on ingress the draft should state that you don't trust the end host flow label. Erik K - having the policy says that you reserve the high bit for labels you set yourself could be worthwhile. Iljitsch B - I don't like this draft. Question, is it a indeterminate candidate for wg or not? Answer indeterminate hum in favor vs against. Session complete at 11:27 From joelja@bogus.com Thu Apr 5 18:18:34 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8F9521F872D for ; Thu, 5 Apr 2012 18:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.977 X-Spam-Level: X-Spam-Status: No, score=-99.977 tagged_above=-999 required=5 tests=[AWL=1.630, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4e+eOqlfDX8 for ; Thu, 5 Apr 2012 18:18:34 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 2766E21F8722 for ; Thu, 5 Apr 2012 18:18:34 -0700 (PDT) Received: from Joels-MacBook-Pro.local (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q361IXkj099503 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 6 Apr 2012 01:18:33 GMT (envelope-from joelja@bogus.com) Message-ID: <4F7D5D87.4090009@bogus.com> Date: Thu, 05 Apr 2012 10:53:27 +0200 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: IPv6 Ops WG , V6ops Chairs Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Fri, 06 Apr 2012 01:18:34 +0000 (UTC) Subject: [v6ops] v6ops Draft minutes Thursday March 29th 15:20 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 01:18:34 -0000 v6ops ietf 83 session 2 commenced at 15:20 First presentation - IP Transitioning in CE Routers draft-townsley-troan-ipv6-ce-transitioning (old slides) http://www.ietf.org/proceedings/83/slides/slides-83-v6ops-4.pdf (new slides) http://www.ietf.org/proceedings/83/slides/slides-83-v6ops-13.pptx Second presentation - RFC 6204 bis http://www.ietf.org/proceedings/83/slides/slides-83-v6ops-11.pdf Ole T - DHCP fix going on in dhc WG Fred B - regarding M/O bits read all discussion and take it up in 3315bis Francis D - w 6/7 remove them. Question, ready for last call? Answer - hum, (some in favor) (no opposed) Question - no one prefers 6rd to native? Answer - native prefered Fred B - My perception is that we await an updated draft that deals with the issues highlighted and we can run through a last call and be ready to ship. Third presentation - Implementation Advice for RA-Guard http://www.ietf.org/proceedings/83/slides/slides-83-v6ops-6.pdf Question, ready for wglc? Answer, hum (most in favor) (one opposed) Fourth presentation - Wireline: Incremental IPv6 http://www.ietf.org/proceedings/83/slides/slides-83-v6ops-7.pptx Fred B - going to have at least one more draft revision. Question, hum for new version and after WGLC? Answer, (favored) (no opposed). Fifth presentation - SP Wi-Fi Services over Residential Architectures http://www.ietf.org/proceedings/83/slides/slides-83-v6ops-12.pptx Philip M - does this belong in other standards bodies such as wfa or 3gpp (or bbf) Sixth Presentation - Using Only Link-Local Address In Network Core http://www.ietf.org/proceedings/83/slides/slides-83-v6ops-9.pptx Janos M - wording is rather strong, prefer informational to bcp us of LL address is a matter of taste. Jan H - seems brilliant when you design it less so afterwards. Iljisch B - occasions where this is useful. Janos M - bgp needs global v6 addresses. Francois D - agree with iljisch meeting is concluded 1715 From Carl.Wuyts@technicolor.com Thu Apr 5 23:19:16 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12A8311E8086 for ; Thu, 5 Apr 2012 23:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[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 TzidT2i+NB49 for ; Thu, 5 Apr 2012 23:19:15 -0700 (PDT) Received: from na3sys009aog111.obsmtp.com (na3sys009aog111.obsmtp.com [74.125.149.205]) by ietfa.amsl.com (Postfix) with ESMTP id 4E8C011E8085 for ; Thu, 5 Apr 2012 23:19:12 -0700 (PDT) Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob111.postini.com ([74.125.148.12]) with SMTP ID DSNKT36K1mPq9pHigBIGU2sWlABilAT9i8GC@postini.com; Thu, 05 Apr 2012 23:19:14 PDT Received: from MOPESMAILHC02.eu.thmulti.com (141.11.100.29) by mail3.technicolor.com (141.11.253.22) with Microsoft SMTP Server (TLS) id 8.3.192.1; Fri, 6 Apr 2012 08:18:50 +0200 Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.134]) by MOPESMAILHC02.eu.thmulti.com ([141.11.100.29]) with mapi; Fri, 6 Apr 2012 08:18:56 +0200 From: Wuyts Carl To: Joel jaeggli , IPv6 Ops WG , "V6ops Chairs" Importance: high X-Priority: 1 Date: Fri, 6 Apr 2012 08:18:54 +0200 Thread-Topic: [v6ops] v6ops Draft minutes Thursday March 29th 15:20 Thread-Index: Ac0Tk1+DyDSsyWocQyK8AICOLJnwgQAKK4tg Message-ID: <867F4B6A1672E541A94676D556793ACD108F03E22A@MOPESMBX01.eu.thmulti.com> References: <4F7D5D87.4090009@bogus.com> In-Reply-To: <4F7D5D87.4090009@bogus.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 Subject: Re: [v6ops] v6ops Draft minutes Thursday March 29th 15:20 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 06:19:16 -0000 V2VsbCwgSSByZWFkIG9uIHRoZSBsYXN0IHNsaWRlOg0KIiINCkhvdyBkbyB3ZSBtb3ZlIGZvcndh cmQ/IA0K4oCi4oCvICBTZWVraW5nIGNvbW11bml0eSBmZWVkYmFjayBvbiANCm9wZW4gaXNzdWVz IA0K4oCi4oCvICBSZWNvbW1lbmRhdGlvbjogDQrigKLigK8gIEFkdmFuY2UgNjIwNGJpcyBhcy1p cywgYW5kIHJlc29sdmUgDQpESEMgaXNzdWVzIHdpdGggREhDIFdHIGR1cmluZyANCklFU0cgcmV2 aWV3IA0K4oCi4oCvICBBZGRpdGlvbmFsIENFLXRyYW5zaXRpb25pbmcgYW5kIERIQyANCnJlcXVp cmVtZW50cyBzaG91bGQgd2FpdCBmb3IgYSANCnN1YnNlcXVlbnQgZHJhZnQgYW5kIGd1aWRhbmNl IGZyb20gDQpob21lbmV0L3Y0ZXhpdCg/KS4NCiIiDQoNClNvLCB3aGF0IEkgcmVtZW1iZXIgZnJv bSB0aGUgdjYgd29ybGQgY29uZ3Jlc3MgaW4gUGFyaXMgbGFzdCBGZWJydWFyeSBpcyB0aGF0LCBp biBvcmRlciB0byBiZSBhYmxlIHRvIHByb2dyZXNzLCB3ZSBuZWVkIHRvIGRyYXcgYSBsaW5lIHNv bWV3aGVyZSBhbmQgdG8gZ2V0IHRvIGEgY29tbW9uIHNldCBvcCByZXF1aXJlbWVudHMgZm9yIHRo ZSBDUEUsIHNvIGl0IGNhbiBiZSBndWFyYW50ZWVkIHRoYXQgQ1BFIHZlbmRvcnMgY2FuIGJlIGNv bXBsaWFudCB0byBpdC4gIEkgcmUtcXVvdGUgbXkgc3RhdGVtZW50cyBmb3JtIHRoZSAiQ2FuIHdl IGdldCBhbiBJUHY2IHBhbmVsIHNlc3Npb24gb24gRnJpZGF5IiBhZ2FpbjogIlN0b3AgYWRkaW5n IHRoaW5ncywgZHJhdyBhIGxpbmUgc29tZXdoZXJlIGJlY2F1c2UgaWYgd2UgZG9u4oCZdCBkbyB0 aGlzLCBuZXh0IHllYXIgd2UnbGwgYmUgaGVyZSBhZ2FpbiBhbmQgbG90cyBvZiBzbGlkZXMgd2ls bCBhZ2FpbiBpbmNsdWRlIGEgc3RhdGVtZW50IHNheWluZyAibm8gSVB2NiBDUEUgYXZhaWxhYmxl Ii4gIE5vdyBJIHJlYWQgdGhhdCBhZ2FpbiBtb3JlIGRyYWZ0cyBjb3VsZC9taWdodCBiZSBhZGRl ZCB0byB0aGUgcmVxcywgc28gSSBBR0FJTiByYWlzZSBteSBjb25jZXJuIGhlcmUgYW5kIEFHQUlO IHJlY29tbWVuZCB0byBOT1QgZG8gdGhpcy4gIFBsZWFzZSBzdGljayB0byB3aGF0IHdhcyBhZ3Jl ZWQgYW5kIHN0b3AgYWRkaW5nIHRoaW5ncyBwbGVhc2UuDQpBbHNvIGFsbG93IERIQ1AgV0cgdG8g d29yayBvbiB0aGUgZGlzY3Vzc2VkIGl0ZW1zIHJlbGF0ZWQgdG8gdGhlbSwgc2FtZSBhcHBsaWVz IGZvciB0aGUgaG9tZW5ldCBzdHVmZi4NCg0KSSdtIHF1aXRlIHN1cmUgdGhhdCBtb3JlIHRoaW5n cyB3aWxsIHBvcC11cCBpbiBjb3Vyc2Ugb2YgdGhlIG5leHQgY291cGxlIG9mIHdlZWtzL21vbnRo cywgc28gcHJlcGFyZSB5b3VyIHJvYWRtYXAgYW5kIHNjaGVkdWxlIGFuIHVwZGF0ZSB0byBpbmNs dWRlIG5ldyByZXFzIGluIGEgTEFURVIgcGhhc2UuDQoNClRoeCBhbmQgcmVncw0KQ2FybA0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogdjZvcHMtYm91bmNlc0BpZXRmLm9yZyBb bWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKb2VsIGphZWdnbGkN ClNlbnQ6IGRvbmRlcmRhZyA1IGFwcmlsIDIwMTIgMTA6NTMNClRvOiBJUHY2IE9wcyBXRzsgVjZv cHMgQ2hhaXJzDQpTdWJqZWN0OiBbdjZvcHNdIHY2b3BzIERyYWZ0IG1pbnV0ZXMgVGh1cnNkYXkg TWFyY2ggMjl0aCAxNToyMA0KDQp2Nm9wcyBpZXRmIDgzIHNlc3Npb24gMiBjb21tZW5jZWQgYXQg MTU6MjANCg0KRmlyc3QgcHJlc2VudGF0aW9uIC0gSVAgVHJhbnNpdGlvbmluZyBpbiBDRSBSb3V0 ZXJzIGRyYWZ0LXRvd25zbGV5LXRyb2FuLWlwdjYtY2UtdHJhbnNpdGlvbmluZw0KKG9sZCBzbGlk ZXMpIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvODMvc2xpZGVzL3NsaWRlcy04My12 Nm9wcy00LnBkZg0KKG5ldyBzbGlkZXMpDQpodHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdz LzgzL3NsaWRlcy9zbGlkZXMtODMtdjZvcHMtMTMucHB0eA0KDQpTZWNvbmQgcHJlc2VudGF0aW9u IC0gUkZDIDYyMDQgYmlzDQpodHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzgzL3NsaWRl cy9zbGlkZXMtODMtdjZvcHMtMTEucGRmDQoNCglPbGUgVCAtIERIQ1AgZml4IGdvaW5nIG9uIGlu IGRoYyBXRw0KDQoNCkZyZWQgQiAtIHJlZ2FyZGluZyBNL08gYml0cyByZWFkIGFsbCBkaXNjdXNz aW9uIGFuZCB0YWtlIGl0IHVwIGluIDMzMTViaXMNCg0KCUZyYW5jaXMgRCAtIHcgNi83IHJlbW92 ZSB0aGVtLg0KDQpRdWVzdGlvbiwgcmVhZHkgZm9yIGxhc3QgY2FsbD8NCg0KQW5zd2VyIC0gaHVt LCAoc29tZSBpbiBmYXZvcikgKG5vIG9wcG9zZWQpDQoNClF1ZXN0aW9uIC0gbm8gb25lIHByZWZl cnMgNnJkIHRvIG5hdGl2ZT8NCg0KQW5zd2VyIC0gbmF0aXZlIHByZWZlcmVkDQoNCkZyZWQgQiAt IE15IHBlcmNlcHRpb24gaXMgdGhhdCB3ZSBhd2FpdCBhbiB1cGRhdGVkIGRyYWZ0IHRoYXQgZGVh bHMgd2l0aCB0aGUgaXNzdWVzIGhpZ2hsaWdodGVkIGFuZCB3ZSBjYW4gcnVuIHRocm91Z2ggYSBs YXN0IGNhbGwgYW5kIGJlIHJlYWR5IHRvIHNoaXAuDQoNClRoaXJkIHByZXNlbnRhdGlvbiAtIElt cGxlbWVudGF0aW9uIEFkdmljZSBmb3IgUkEtR3VhcmQgaHR0cDovL3d3dy5pZXRmLm9yZy9wcm9j ZWVkaW5ncy84My9zbGlkZXMvc2xpZGVzLTgzLXY2b3BzLTYucGRmDQoNClF1ZXN0aW9uLCByZWFk eSBmb3Igd2dsYz8NCkFuc3dlciwgaHVtIChtb3N0IGluIGZhdm9yKSAob25lIG9wcG9zZWQpDQoN CkZvdXJ0aCBwcmVzZW50YXRpb24gLSAgV2lyZWxpbmU6IEluY3JlbWVudGFsIElQdjYgaHR0cDov L3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy84My9zbGlkZXMvc2xpZGVzLTgzLXY2b3BzLTcucHB0 eA0KDQpGcmVkIEIgLSBnb2luZyB0byBoYXZlIGF0IGxlYXN0IG9uZSBtb3JlIGRyYWZ0IHJldmlz aW9uLg0KDQpRdWVzdGlvbiwgaHVtIGZvciBuZXcgdmVyc2lvbiBhbmQgYWZ0ZXIgV0dMQz8NCkFu c3dlciwgKGZhdm9yZWQpIChubyBvcHBvc2VkKS4NCg0KRmlmdGggcHJlc2VudGF0aW9uIC0gU1Ag V2ktRmkgU2VydmljZXMgb3ZlciBSZXNpZGVudGlhbCBBcmNoaXRlY3R1cmVzIGh0dHA6Ly93d3cu aWV0Zi5vcmcvcHJvY2VlZGluZ3MvODMvc2xpZGVzL3NsaWRlcy04My12Nm9wcy0xMi5wcHR4DQoN CglQaGlsaXAgTSAtIGRvZXMgdGhpcyBiZWxvbmcgaW4gb3RoZXIgc3RhbmRhcmRzIGJvZGllcyBz dWNoIGFzDQoJd2ZhIG9yIDNncHAgKG9yIGJiZikNCg0KU2l4dGggUHJlc2VudGF0aW9uIC0gVXNp bmcgT25seSBMaW5rLUxvY2FsIEFkZHJlc3MgSW4gTmV0d29yayBDb3JlIGh0dHA6Ly93d3cuaWV0 Zi5vcmcvcHJvY2VlZGluZ3MvODMvc2xpZGVzL3NsaWRlcy04My12Nm9wcy05LnBwdHgNCg0KCUph bm9zIE0gLSB3b3JkaW5nIGlzIHJhdGhlciBzdHJvbmcsIHByZWZlciBpbmZvcm1hdGlvbmFsIHRv DQoJYmNwIHVzIG9mIExMIGFkZHJlc3MgaXMgYSBtYXR0ZXIgb2YgdGFzdGUuDQoNCglKYW4gSCAt IHNlZW1zIGJyaWxsaWFudCB3aGVuIHlvdSBkZXNpZ24gaXQgbGVzcyBzbyBhZnRlcndhcmRzLg0K DQoJSWxqaXNjaCBCIC0gb2NjYXNpb25zIHdoZXJlIHRoaXMgaXMgdXNlZnVsLg0KDQoJSmFub3Mg TSAtIGJncCBuZWVkcyBnbG9iYWwgdjYgYWRkcmVzc2VzLg0KDQoJRnJhbmNvaXMgRCAtIGFncmVl IHdpdGggaWxqaXNjaA0KDQptZWV0aW5nIGlzIGNvbmNsdWRlZCAxNzE1DQoNCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnY2b3BzIG1haWxpbmcgbGlz dA0KdjZvcHNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v djZvcHMNCg== From despres.remi@laposte.net Fri Apr 6 04:48:24 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8007321F852B for ; Fri, 6 Apr 2012 04:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[AWL=-0.776, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Xdp9N-q7cXT for ; Fri, 6 Apr 2012 04:48:23 -0700 (PDT) Received: from smtpout.laposte.net (smtpout1.laposte.net [193.253.67.226]) by ietfa.amsl.com (Postfix) with ESMTP id 7807921F8526 for ; Fri, 6 Apr 2012 04:48:22 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8501-out with ME id uboG1i00137Y3f403boGBS; Fri, 06 Apr 2012 13:48:21 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4F7D563D.1030805@bogus.com> Date: Fri, 6 Apr 2012 13:48:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F7D563D.1030805@bogus.com> To: Joel jaeggli X-Mailer: Apple Mail (2.1084) Cc: IPv6 Ops WG , V6ops Chairs Subject: Re: [v6ops] v6ops - Draft minutes Monday March 26th 0900 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 11:48:24 -0000 Hi, Joel,=20 Minor typo correction in what I said: "coordination with Softwire is required." ^^^ (not software) Thanks, RD Le 2012-04-05 =E0 10:22, Joel jaeggli a =E9crit : > 0900 meeting commences >=20 > Agenda Bashing > 6204bis dicussion is moved to thursday. >=20 > draft-carpenter-v6ops-label-balance moves to moday >=20 >=20 > Fred - > iesg is asking about interim meeting to coincided with ripe > meeting e.g. 24-28th of sept >=20 > Question, how many will be a at ripe anyway? > Answer, about a dozen hands. >=20 > Low hum in favor. No opposition. >=20 > First presentation - Experiences from IPv6-Only Networks with = Transition > Technologies in the WIDE Camp Spring 2012 >=20 > http://www.ietf.org/proceedings/83/slides/slides-83-v6ops-0.pdf >=20 > mtu issues particularly with udp vpn applications >=20 > many implmentation issues with nat64 and dns64 >=20 > Fred B - > Question, long term plans for the draft? >=20 > Answer, and camp in sept updated version of the draft will > follow. > =09 > Second presentation - draft-donley-behave-deterministic-cgn-01 >=20 > http://www.ietf.org/proceedings/83/slides/slides-83-v6ops-1.pdf >=20 > hinges on the question of address assignment efficiency due to > fixed assignment of port resources. >=20 > documented in draft that compression works fairly well between > 10-100 users per ip. >=20 > Fred B - > Postponing question of whether would should take it until it > ADs get back to us. >=20 > test for donneley (done after following presentation) > hum (mostly in favor) (minor opposition) >=20 > Third presentation - NAT64 Operational Experience >=20 > http://www.ietf.org/proceedings/83/slides/slides-83-v6ops-2.ppt >=20 > comments leading to updates of draft-chen-v6ops-nat64- > experience-01 >=20 > Moake chen - same question on the mtu statement >=20 > Iljitsch B - so the ipv4 servers should set their mtu to at > least 1260. good work item for v4 exit wg. >=20 > Fred B - > hold off or do it now? > assuming there is no v4 exit is this a document suitable for > this wg? >=20 > hum (no support for) (or against) >=20 > Fourth Presentation - 464XLAT Combination of Stateful and Stateless > Translation >=20 > http://www.ietf.org/proceedings/83/slides/slides-83-v6ops-3.ppt >=20 > Lorenzo C - like this as a hack to bring carrier pigeon quality > v4 to v6 only devices. >=20 > don't understand why the device needs a /96 (teathering) should > should work with a /128 >=20 > Fred B - > history of draft > ask softwire and behave chairs what they thought of it. >=20 > right resolution to the narmative language is to split the > document into the bcp for providing the service and another > draft on the implementation report. seperate them. >=20 > Lorenzo C - it's not a bcp right, you can do this using > existing technology >=20 > Philip M - service providers like standards. >=20 > Janos M - I am very much against BCP >=20 > Remi D - Support informational think coordination with software > is required. >=20 > Hui D - useful as short term before 3gpp rel 8 >=20 > Question, does /96 requirement removal, remove objections to progress? >=20 > Answer, 6 hands consider it a problem, 3 would not object after = removal. >=20 > Fifth Presentation - Stateless Source address mapping for ICMPv6 = packets >=20 > http://www.ietf.org/proceedings/83/slides/slides-83-v6ops-5.ppt >=20 > Fred B - we'll take it to WG last call on the mailing list. >=20 > Sixth Presentation - IPv6 Guidance for Internet Content and = Application > Service Providers >=20 > Lee H - it's a good doc >=20 > Erik K - it's probably a good starting point. >=20 > Hum for acceptance (some yes ) (no opposition) >=20 > Fred B - repost as draft IETF >=20 > Seventh Presentation - IPv6 Flow label for server load balancing >=20 > http://www.ietf.org/proceedings/83/slides/slides-83-v6ops-8.ppt >=20 > Iljitsch B - it's dangerous to assume that the flow label is > never going to change mid-session >=20 > Lorenzo C - if the lb trusts the client to determine lb then > you probably need to reset the label on ingress >=20 > the draft should state that you don't trust the end host flow > label. >=20 > Erik K - having the policy says that you reserve the high bit > for labels you set yourself could be worthwhile. >=20 > Iljitsch B - I don't like this draft. >=20 > Question, is it a indeterminate candidate for wg or not? >=20 > Answer indeterminate hum in favor vs against. >=20 > Session complete at 11:27 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From internet-drafts@ietf.org Fri Apr 6 09:47:20 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B48621F8568; Fri, 6 Apr 2012 09:47:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 407TaRHWiLao; Fri, 6 Apr 2012 09:47:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2D9E21F8531; Fri, 6 Apr 2012 09:47:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120406164719.26737.37272.idtracker@ietfa.amsl.com> Date: Fri, 06 Apr 2012 09:47:19 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-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: Fri, 06 Apr 2012 16:47:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the = IETF. Title : Basic Requirements for IPv6 Customer Edge Routers Author(s) : Hemant Singh Wes Beebee Chris Donley Barbara Stark Ole Troan Filename : draft-ietf-v6ops-6204bis-08.txt Pages : 22 Date : 2012-04-06 This document specifies requirements for an IPv6 Customer Edge (CE) router. Specifically, the current version of this document focuses on the basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it. The document also covers IP transition technologies. Two transition technologies in RFC 5969's 6rd and RFC 6333's DS-Lite are covered in the document. The document obsoletes RFC 6204, if approved. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-6204bis-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-6204bis-08.txt From wwwrun@rfc-editor.org Fri Apr 6 14:12:10 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F191B11E80AC; Fri, 6 Apr 2012 14:12:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.025 X-Spam-Level: X-Spam-Status: No, score=-102.025 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00IZqh9bEzrp; Fri, 6 Apr 2012 14:12:09 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 754E411E809B; Fri, 6 Apr 2012 14:12:09 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id E05A672E041; Fri, 6 Apr 2012 14:11:50 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20120406211150.E05A672E041@rfc-editor.org> Date: Fri, 6 Apr 2012 14:11:50 -0700 (PDT) Cc: v6ops@ietf.org, rfc-editor@rfc-editor.org Subject: [v6ops] RFC 6555 on Happy Eyeballs: Success with Dual-Stack Hosts X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 21:12:10 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6555 Title: Happy Eyeballs: Success with Dual-Stack Hosts Author: D. Wing, A. Yourtchenko Status: Standards Track Stream: IETF Date: April 2012 Mailbox: dwing@cisco.com, ayourtch@cisco.com Pages: 15 Characters: 34048 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-v6ops-happy-eyeballs-07.txt URL: http://www.rfc-editor.org/rfc/rfc6555.txt When a server's IPv4 path and protocol are working, but the server's IPv6 path and protocol are not working, a dual-stack client application experiences significant connection delay compared to an IPv4-only client. This is undesirable because it causes the dual- stack client to have a worse user experience. This document specifies requirements for algorithms that reduce this user-visible delay and provides an algorithm. [STANDARDS-TRACK] This document is a product of the IPv6 Operations Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From joelja@bogus.com Sat Apr 7 08:55:08 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E84D21F8555 for ; Sat, 7 Apr 2012 08:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.459 X-Spam-Level: X-Spam-Status: No, score=-100.459 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uyhr3zG8OJMy for ; Sat, 7 Apr 2012 08:55:07 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id C92A921F852B for ; Sat, 7 Apr 2012 08:55:07 -0700 (PDT) Received: from Joels-MacBook-Pro.local (21.sub-166-250-46.myvzw.com [166.250.46.21]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q37Ft3Id040667 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sat, 7 Apr 2012 15:55:06 GMT (envelope-from joelja@bogus.com) Message-ID: <4F806351.1030409@bogus.com> Date: Sat, 07 Apr 2012 08:54:57 -0700 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= References: <4F7D563D.1030805@bogus.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 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]); Sat, 07 Apr 2012 15:55:07 +0000 (UTC) Cc: IPv6 Ops WG , V6ops Chairs Subject: Re: [v6ops] v6ops - Draft minutes Monday March 26th 0900 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2012 15:55:08 -0000 thanks joel On 4/6/12 04:48 , Rémi Després wrote: > Hi, Joel, > > Minor typo correction in what I said: > "coordination with Softwire is required." > ^^^ (not software) > > Thanks, > RD > > Le 2012-04-05 à 10:22, Joel jaeggli a écrit : > >> 0900 meeting commences >> >> Agenda Bashing >> 6204bis dicussion is moved to thursday. >> >> draft-carpenter-v6ops-label-balance moves to moday >> >> >> Fred - >> iesg is asking about interim meeting to coincided with ripe >> meeting e.g. 24-28th of sept >> >> Question, how many will be a at ripe anyway? >> Answer, about a dozen hands. >> >> Low hum in favor. No opposition. >> >> First presentation - Experiences from IPv6-Only Networks with Transition >> Technologies in the WIDE Camp Spring 2012 >> >> http://www.ietf.org/proceedings/83/slides/slides-83-v6ops-0.pdf >> >> mtu issues particularly with udp vpn applications >> >> many implmentation issues with nat64 and dns64 >> >> Fred B - >> Question, long term plans for the draft? >> >> Answer, and camp in sept updated version of the draft will >> follow. >> >> Second presentation - draft-donley-behave-deterministic-cgn-01 >> >> http://www.ietf.org/proceedings/83/slides/slides-83-v6ops-1.pdf >> >> hinges on the question of address assignment efficiency due to >> fixed assignment of port resources. >> >> documented in draft that compression works fairly well between >> 10-100 users per ip. >> >> Fred B - >> Postponing question of whether would should take it until it >> ADs get back to us. >> >> test for donneley (done after following presentation) >> hum (mostly in favor) (minor opposition) >> >> Third presentation - NAT64 Operational Experience >> >> http://www.ietf.org/proceedings/83/slides/slides-83-v6ops-2.ppt >> >> comments leading to updates of draft-chen-v6ops-nat64- >> experience-01 >> >> Moake chen - same question on the mtu statement >> >> Iljitsch B - so the ipv4 servers should set their mtu to at >> least 1260. good work item for v4 exit wg. >> >> Fred B - >> hold off or do it now? >> assuming there is no v4 exit is this a document suitable for >> this wg? >> >> hum (no support for) (or against) >> >> Fourth Presentation - 464XLAT Combination of Stateful and Stateless >> Translation >> >> http://www.ietf.org/proceedings/83/slides/slides-83-v6ops-3.ppt >> >> Lorenzo C - like this as a hack to bring carrier pigeon quality >> v4 to v6 only devices. >> >> don't understand why the device needs a /96 (teathering) should >> should work with a /128 >> >> Fred B - >> history of draft >> ask softwire and behave chairs what they thought of it. >> >> right resolution to the narmative language is to split the >> document into the bcp for providing the service and another >> draft on the implementation report. seperate them. >> >> Lorenzo C - it's not a bcp right, you can do this using >> existing technology >> >> Philip M - service providers like standards. >> >> Janos M - I am very much against BCP >> >> Remi D - Support informational think coordination with software >> is required. >> >> Hui D - useful as short term before 3gpp rel 8 >> >> Question, does /96 requirement removal, remove objections to progress? >> >> Answer, 6 hands consider it a problem, 3 would not object after removal. >> >> Fifth Presentation - Stateless Source address mapping for ICMPv6 packets >> >> http://www.ietf.org/proceedings/83/slides/slides-83-v6ops-5.ppt >> >> Fred B - we'll take it to WG last call on the mailing list. >> >> Sixth Presentation - IPv6 Guidance for Internet Content and Application >> Service Providers >> >> Lee H - it's a good doc >> >> Erik K - it's probably a good starting point. >> >> Hum for acceptance (some yes ) (no opposition) >> >> Fred B - repost as draft IETF >> >> Seventh Presentation - IPv6 Flow label for server load balancing >> >> http://www.ietf.org/proceedings/83/slides/slides-83-v6ops-8.ppt >> >> Iljitsch B - it's dangerous to assume that the flow label is >> never going to change mid-session >> >> Lorenzo C - if the lb trusts the client to determine lb then >> you probably need to reset the label on ingress >> >> the draft should state that you don't trust the end host flow >> label. >> >> Erik K - having the policy says that you reserve the high bit >> for labels you set yourself could be worthwhile. >> >> Iljitsch B - I don't like this draft. >> >> Question, is it a indeterminate candidate for wg or not? >> >> Answer indeterminate hum in favor vs against. >> >> Session complete at 11:27 >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > > From fred@cisco.com Sun Apr 8 16:17:58 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B16B121F8557 for ; Sun, 8 Apr 2012 16:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, 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 TMzJfU14QswU for ; Sun, 8 Apr 2012 16:17:58 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 30A7C21F854F for ; Sun, 8 Apr 2012 16:17:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1000; q=dns/txt; s=iport; t=1333927078; x=1335136678; h=from:subject:date:message-id:cc:to:mime-version; bh=O6ErifBR9cC5Y8yUFxk0yigyzj8s7k49qcIFAx3o9nw=; b=Hd2GbPhIgHkHN/HFXMgDVFJy3hIac0NfPdXz9DJzG1AKuSKprjXxItmo OTzggVUUw001QcO22z6IejzXtxnIonSCMM5pmJDchXmMDcUkkfB4NMjz2 HuqYP2JOaz0ipWK++vUvwl8W97rgM5KXoH81c8smBdVJKCQdLPy7FoAtu 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EACYcgk+rRDoG/2dsb2JhbABDgka2YIEHggAiAQpcHgGBVIdrmhSfCI02gkFjBIhajRKFcohbgWmDBw X-IronPort-AV: E=Sophos;i="4.75,391,1330905600"; d="scan'208,217";a="39524380" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 08 Apr 2012 23:17:57 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q38NHv8Q010294; Sun, 8 Apr 2012 23:17:57 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Sun, 08 Apr 2012 16:17:57 -0700 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Sun, 08 Apr 2012 16:17:57 -0700 From: Fred Baker Date: Sun, 8 Apr 2012 16:17:04 -0700 Message-Id: <287364FA-E8C5-4918-92D2-E4DD29089A6B@cisco.com> To: v6ops@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Content-Type: multipart/alternative; boundary=Apple-Mail-70--862460744 Cc: v6ops-chairs@tools.ietf.org, Ron Bonica Subject: [v6ops] Reminder: draft-ietf-v6ops-ivi-icmp-address WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2012 23:17:58 -0000 --Apple-Mail-70--862460744 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The working group last call for this draft announced last week continues = for another week. Please feel free to comment on it. --Apple-Mail-70--862460744 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
The working group last call for this draft announced last week continues for another week. Please feel free to comment on it.

--Apple-Mail-70--862460744-- From randy@psg.com Sun Apr 8 20:50:04 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC20121F8616 for ; Sun, 8 Apr 2012 20:50: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 uY+drG4z49Cr for ; Sun, 8 Apr 2012 20:50:04 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE7B21F8613 for ; Sun, 8 Apr 2012 20:50:04 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SH5c9-000AG0-7A; Mon, 09 Apr 2012 03:50:01 +0000 Date: Mon, 09 Apr 2012 12:49:59 +0900 Message-ID: From: Randy Bush To: Fred Baker In-Reply-To: <287364FA-E8C5-4918-92D2-E4DD29089A6B@cisco.com> References: <287364FA-E8C5-4918-92D2-E4DD29089A6B@cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] Reminder: draft-ietf-v6ops-ivi-icmp-address WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 03:50:04 -0000 section 4 worries me. i think it means that, if uprf filtering is in play, either o the source of the packets must announce the well-known prefix, or o the router doing uprf filtering needs a static to the interface from which it may receive such packets. are people really gonna do all this custom configuration? reliably? Such routing advertisements are non-exclusive and should be accepted from any originating AS in an anycast fashion. hmmm. i wonder if we should advise the uprf filterer not to propagate the announcement, and for non-uprf players to filter it as a martian? randy From fred@cisco.com Mon Apr 9 09:11:39 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1341221F86E0 for ; Mon, 9 Apr 2012 09:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6l7BfE9PDmo2 for ; Mon, 9 Apr 2012 09:11:38 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 36D3E21F8659 for ; Mon, 9 Apr 2012 09:11:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1416; q=dns/txt; s=iport; t=1333987898; x=1335197498; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=NCGPb0IUbQpHQgg0oDNcgLUejEnDYPklse4+Y9qjzeI=; b=WOsuyKpycjl7ZdqOucUAh5ejBZgggENlysWFUjaDMATgWib90CiXV5OO VuREbH/NOomUtcxFVeFpju1+JOffchyGlpsw7HmPcpn6+GStE5CeNs0xt 8vnjuFU9dH9zywYiFmcSbXuVbHjb+dzRtPZgXa4CtIwbrjP/GVC6f3ZNN 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAHAJg0+tJXHB/2dsb2JhbABDuS2BB4IJAQEBAwESASc/BQsLRlcGATSHZwWeepgZj3djBIhajRKFcohbgWmDBw X-IronPort-AV: E=Sophos;i="4.75,393,1330905600"; d="scan'208";a="72964192" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-1.cisco.com with ESMTP; 09 Apr 2012 16:11:36 +0000 Received: from Freds-Computer.local (stealth-10-32-244-218.cisco.com [10.32.244.218]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id q39GBYwQ010209; Mon, 9 Apr 2012 16:11:35 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Mon, 09 Apr 2012 09:11:35 -0700 X-PGP-Universal: processed; by Freds-Computer.local on Mon, 09 Apr 2012 09:11:35 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Mon, 9 Apr 2012 09:11:15 -0700 Message-Id: <3AEC3FA7-7162-4507-B27D-D35AD7E2D429@cisco.com> References: <287364FA-E8C5-4918-92D2-E4DD29089A6B@cisco.com> To: Randy Bush , draft-ietf-v6ops-ivi-icmp-address@tools.ietf.org X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations , Ron Bonica Subject: Re: [v6ops] Reminder: draft-ietf-v6ops-ivi-icmp-address WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 16:11:39 -0000 On Apr 8, 2012, at 8:49 PM, Randy Bush wrote: > section 4 worries me. i think it means that, if uprf filtering is in > play, either > o the source of the packets must announce the well-known prefix, or > o the router doing uprf filtering needs a static to the interface > from which it may receive such packets. >=20 > are people really gonna do all this custom configuration? reliably? >=20 > Such routing advertisements are non-exclusive and should be accepted > from any originating AS in an anycast fashion. >=20 > hmmm. i wonder if we should advise the uprf filterer not to propagate > the announcement, and for non-uprf players to filter it as a martian? Hmm 4. Routing Considerations Addresses from the assigned address prefix are intended to be used as source addresses and not as destination addresses in the context of the public network. As packets passing through the public network need to pass through conventional packet filters, including uRPF filters [RFC3704], this implies that the assigned address may be used in routing advertisements. Such routing advertisements are non- exclusive and should be accepted from any originating AS in an anycast fashion. For some reason, I have been thinking of this prefix as only being used = in the ICMP message, not the IPv4 header.=20 Could the authors comment on this please?= From cb.list6@gmail.com Mon Apr 9 14:53:31 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C47C21F87FE for ; Mon, 9 Apr 2012 14:53:31 -0700 (PDT) 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 2moiMjmnHsSH for ; Mon, 9 Apr 2012 14:53:30 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id CA2F521F87EF for ; Mon, 9 Apr 2012 14:53:30 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so5101619pbb.31 for ; Mon, 09 Apr 2012 14:53:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=lzURxifuQEaWkjhz0UQ8b5fUYNmEoBMwCXPCIxLJccc=; b=iVKASgfNSEYE/gkhsv2YlXQek1f8WLHQ9zEnQYWLZXvmM0vgzrAwEYd41d+CrTO3Re fchIjrH2noAleGPcinzrDqIYmFw4DUBpshcA/Z96e4aGqb7Xg/KTINEAnvZcrv5Z9qLE WbIvovDIe+aVCA3wWAvPTf5/36tp6M3lrgQ5yb0KaSAXCJ4InzdvMBKnfZp3xxRGIUb4 NC6My6BNt+Vr0fgVjQXoau7uQ8E2XpJlvYlfbtxho4jBxfRQePt9bZlJ0xRLc4YFiXiV od0YfUEsEGukntLN+qMi8i4YP2OvWcnoYHd81tQCdhK7/l4UvLjltHP3GyxION9v3TWP PWig== MIME-Version: 1.0 Received: by 10.68.132.36 with SMTP id or4mr22806946pbb.115.1334008410620; Mon, 09 Apr 2012 14:53:30 -0700 (PDT) Received: by 10.143.16.3 with HTTP; Mon, 9 Apr 2012 14:53:30 -0700 (PDT) Date: Mon, 9 Apr 2012 14:53:30 -0700 Message-ID: From: Cameron Byrne To: IPv6 Ops WG Content-Type: text/plain; charset=ISO-8859-1 Subject: [v6ops] 464XLAT testing experience X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 21:53:31 -0000 Folks, In an effort to share as much information as possible about setting up a 464XLAT IPv6-only network and testing it, i have put some information together here for you to review. https://sites.google.com/site/tmoipv6/464xlat I have documented the following proof of concepts: 4.1 Android + CLAT on a UMTS IPv6-only network with DNS64/NAT64 4.2 Cisco ASR 1000 as CLAT and LITNET public implementation of Linux NAT64 and BIND DNS64 as PLAT 4.2.1 NOT 464XLAT Case: IPv6-only host, IPv6-only WAN, using LITNET NAT64/DNS64, no CLAT 4.2.2 464XLAT Case: Dual-stack host, IPv6-only WAN, using LITNET NAT64/DNS64 + ASR 1000 as CLAT 4.2.3 464XLAT Case: IPv4-only host, IPv6-only WAN, using LITNET NAT64, 8.8.8.8 DNS, and ASR 1000 as CLAT Please feel free to comment to me off-line with questions or on the list as you see appropriated Thanks, Cameron From randy@psg.com Mon Apr 9 21:52:15 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DD2621F8698 for ; Mon, 9 Apr 2012 21:52:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 biZjhY9zXfLk for ; Mon, 9 Apr 2012 21:52:15 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 3876A21F8697 for ; Mon, 9 Apr 2012 21:52:15 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SHT3q-0000UT-Qn; Tue, 10 Apr 2012 04:52:10 +0000 Date: Tue, 10 Apr 2012 13:52:09 +0900 Message-ID: From: Randy Bush To: "Ramji Vaithianathan (rvaithia)" In-Reply-To: References: <287364FA-E8C5-4918-92D2-E4DD29089A6B@cisco.com> <3AEC3FA7-7162-4507-B27D-D35AD7E2D429@cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: IPv6 Operations , draft-ietf-v6ops-ivi-icmp-address@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] Reminder: draft-ietf-v6ops-ivi-icmp-address WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 04:52:15 -0000 >> Such routing advertisements are non-exclusive and should be accepted >> from any originating AS in an anycast fashion. >> >> hmmm. i wonder if we should advise the uprf filterer not to propagate >> the announcement, and for non-uprf players to filter it as a martian? > > What does announcement mean here - is it the ICMP packet or is it the > routing advertisements? Also what does non-urpf players mean? announcements are routing announcements. i have never heard the term used in the data plane. by non-uprf players, i meant routers which are not applying urpf filters. is there a reason they should propagate the announcement of your wka? randy From randy@psg.com Mon Apr 9 22:15:05 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E03CF21F8782 for ; Mon, 9 Apr 2012 22:15: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 z3yOeb8vnzXw for ; Mon, 9 Apr 2012 22:15:03 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 1155621F880C for ; Mon, 9 Apr 2012 22:15:02 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SHTPx-0000YC-PT; Tue, 10 Apr 2012 05:15:02 +0000 Date: Tue, 10 Apr 2012 14:15:00 +0900 Message-ID: From: Randy Bush To: Ramji Vaithianathan In-Reply-To: References: <287364FA-E8C5-4918-92D2-E4DD29089A6B@cisco.com> <3AEC3FA7-7162-4507-B27D-D35AD7E2D429@cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: IETF v6ops list Subject: Re: [v6ops] Reminder: draft-ietf-v6ops-ivi-icmp-address WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 05:15:06 -0000 > RAMJI: Even if a router is a non-urpf player, the subsequent routers to > which the route is propagated could do uRPF, hence should they not > receive the routing advertisement? so all routers in the entire internet should have a route to your wka to all their interfaces? randy From joelja@bogus.com Mon Apr 9 23:40:34 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3009221F87AA for ; Mon, 9 Apr 2012 23:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.684 X-Spam-Level: X-Spam-Status: No, score=-101.684 tagged_above=-999 required=5 tests=[AWL=0.315, 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 LIVSp-ZkZKcv for ; Mon, 9 Apr 2012 23:40:33 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 9189221F875E for ; Mon, 9 Apr 2012 23:40:33 -0700 (PDT) Received: from Joels-MacBook-Pro.local (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q3A6eTY0005914 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 10 Apr 2012 06:40:30 GMT (envelope-from joelja@bogus.com) Message-ID: <4F83D5DD.6010001@bogus.com> Date: Mon, 09 Apr 2012 23:40:29 -0700 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: Randy Bush References: <287364FA-E8C5-4918-92D2-E4DD29089A6B@cisco.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]); Tue, 10 Apr 2012 06:40:30 +0000 (UTC) Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] Reminder: draft-ietf-v6ops-ivi-icmp-address WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 06:40:34 -0000 On 4/8/12 20:49 , Randy Bush wrote: > section 4 worries me. i think it means that, if uprf filtering is in > play, either > o the source of the packets must announce the well-known prefix, or > o the router doing uprf filtering needs a static to the interface > from which it may receive such packets. if you're doing strict mode with customers I would imagine that each one would be required to advertise this prefix in order to originate packets from this source. It's seems clear to me that the goal is that packets from this source address be unequivically accepted which as I've stated before strikes me as a rather bad idea since I cannot by definition know their source. > are people really gonna do all this custom configuration? reliably? > > Such routing advertisements are non-exclusive and should be accepted > from any originating AS in an anycast fashion. > > hmmm. i wonder if we should advise the uprf filterer not to propagate > the announcement, and for non-uprf players to filter it as a martian? > > randy > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From rvaithia@cisco.com Mon Apr 9 21:43:55 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 551A321F86AA for ; Mon, 9 Apr 2012 21:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A0nnxOVyGSzs for ; Mon, 9 Apr 2012 21:43:54 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 27F1121F858D for ; Mon, 9 Apr 2012 21:43:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rvaithia@cisco.com; l=2315; q=dns/txt; s=iport; t=1334033034; x=1335242634; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=1KaqgbggDzrozMKM/MbDtahEbGgldjqyZqNnwmfepgY=; b=QCkxamADYPBptSe+tJ/YLGmX4elsnRvUJAuJUQuDNMHc9GWJsakrQYTR HEJ0BuhzyZzQUd6nWUL8oP6TDgRxuxjIdP/vMdAXThZmPN3NbekpIlEBP K+C7+hL/K4RxEF4GpVeukB6WhOxDBj4gNsFN4tooufTFjEwSrwj+tYFyI Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAF25g0+rRDoI/2dsb2JhbABDuVOBB4IJAQEBAwESARQJCj8FBwQCAQgRBAEBCwYYBgFOCAEBBAESCBqHZwQBmiigKI9+YwSIWptfgWmDBw X-IronPort-AV: E=Sophos;i="4.75,396,1330905600"; d="scan'208";a="39797173" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 10 Apr 2012 04:43:54 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3A4hrlQ026141; Tue, 10 Apr 2012 04:43:53 GMT Received: from xmb-sjc-22e.amer.cisco.com ([128.107.191.115]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 Apr 2012 21:43:53 -0700 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, 9 Apr 2012 21:43:50 -0700 Message-ID: In-Reply-To: <3AEC3FA7-7162-4507-B27D-D35AD7E2D429@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] Reminder: draft-ietf-v6ops-ivi-icmp-address WGLC Thread-Index: Ac0Wa4IdB+/zembxScyrTcleJaTG+wAZ2CfQ References: <287364FA-E8C5-4918-92D2-E4DD29089A6B@cisco.com> <3AEC3FA7-7162-4507-B27D-D35AD7E2D429@cisco.com> From: "Ramji Vaithianathan (rvaithia)" To: "Fred Baker (fred)" , "Randy Bush" , X-OriginalArrivalTime: 10 Apr 2012 04:43:53.0746 (UTC) FILETIME=[8831DF20:01CD16D4] X-Mailman-Approved-At: Tue, 10 Apr 2012 09:41:34 -0700 Cc: IPv6 Operations , Ron Bonica Subject: Re: [v6ops] Reminder: draft-ietf-v6ops-ivi-icmp-address WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 04:43:55 -0000 These addresses are source addresses in the L3 (IPv4) header of the ICMP packets after translation of a non-translatable IPv6 source address that was present before L3 (v4->v6) translation. >=20 > Such routing advertisements are non-exclusive and should be accepted > from any originating AS in an anycast fashion. > > hmmm. i wonder if we should advise the uprf filterer not to propagate > the announcement, and for non-uprf players to filter it as a martian? What does announcement mean here - is it the ICMP packet or is it the routing advertisements? Also what does non-urpf players mean? Thanks, Ramji -----Original Message----- From: Fred Baker (fred)=20 Sent: Monday, April 09, 2012 9:41 PM To: Randy Bush; draft-ietf-v6ops-ivi-icmp-address@tools.ietf.org Cc: IPv6 Operations; Ron Bonica Subject: Re: [v6ops] Reminder: draft-ietf-v6ops-ivi-icmp-address WGLC On Apr 8, 2012, at 8:49 PM, Randy Bush wrote: > section 4 worries me. i think it means that, if uprf filtering is in > play, either > o the source of the packets must announce the well-known prefix, or > o the router doing uprf filtering needs a static to the interface > from which it may receive such packets. >=20 > are people really gonna do all this custom configuration? reliably? >=20 > Such routing advertisements are non-exclusive and should be accepted > from any originating AS in an anycast fashion. >=20 > hmmm. i wonder if we should advise the uprf filterer not to propagate > the announcement, and for non-uprf players to filter it as a martian? Hmm 4. Routing Considerations Addresses from the assigned address prefix are intended to be used as source addresses and not as destination addresses in the context of the public network. As packets passing through the public network need to pass through conventional packet filters, including uRPF filters [RFC3704], this implies that the assigned address may be used in routing advertisements. Such routing advertisements are non- exclusive and should be accepted from any originating AS in an anycast fashion. For some reason, I have been thinking of this prefix as only being used in the ICMP message, not the IPv4 header.=20 Could the authors comment on this please? From rvaithia@cisco.com Mon Apr 9 22:04:49 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67F0221F87B4 for ; Mon, 9 Apr 2012 22:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQRdbLByxucn for ; Mon, 9 Apr 2012 22:04: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 ACB7621F87B0 for ; Mon, 9 Apr 2012 22:04:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rvaithia@cisco.com; l=1387; q=dns/txt; s=iport; t=1334034288; x=1335243888; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=AP1zQan02s1nZX6GlnbRbXRiB+equtrDotdReGhodHM=; b=e9a3Ju1k0MpP2zmfttzX8mm0974PSt5QUBOuuC8jwZtEpZg04PU+LEde fn93vUnsZ9ADLqog36dBE/ZbCym4YF5CB9Xc/FRcbMCGc57ZM0pfHKH+Z Z+8T4SoCsx+dgqyrmeKCgJ+8esDYx2/aJ6vvcGoezxTG5TmacMqI8Opkf A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EACG/g0+rRDoH/2dsb2JhbABDuVOBB4IJAQEBAwESAR0KPwwEAgEIEQQBAQsGFwEGAUUJCAEBBBMIGodnBAGaJ6Aqj35jBIham1+BaYMHgTQF X-IronPort-AV: E=Sophos;i="4.75,396,1330905600"; d="scan'208";a="39798747" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 10 Apr 2012 05:04:48 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q3A54jU6020118; Tue, 10 Apr 2012 05:04:45 GMT Received: from xmb-sjc-22e.amer.cisco.com ([128.107.191.115]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 Apr 2012 22:04:45 -0700 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, 9 Apr 2012 22:04:42 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] Reminder: draft-ietf-v6ops-ivi-icmp-address WGLC Thread-Index: Ac0W1bOD+Xs1mq8hSLayYh8V7jGeFwAALXZA References: <287364FA-E8C5-4918-92D2-E4DD29089A6B@cisco.com><3AEC3FA7-7162-4507-B27D-D35AD7E2D429@cisco.com> From: "Ramji Vaithianathan (rvaithia)" To: "Randy Bush" X-OriginalArrivalTime: 10 Apr 2012 05:04:45.0051 (UTC) FILETIME=[7207DCB0:01CD16D7] X-Mailman-Approved-At: Tue, 10 Apr 2012 09:41:34 -0700 Cc: IPv6 Operations , draft-ietf-v6ops-ivi-icmp-address@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] Reminder: draft-ietf-v6ops-ivi-icmp-address WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 05:04:49 -0000 Inline, Ramji -----Original Message----- From: Randy Bush [mailto:randy@psg.com]=20 Sent: Tuesday, April 10, 2012 10:22 AM To: Ramji Vaithianathan (rvaithia) Cc: Fred Baker (fred); draft-ietf-v6ops-ivi-icmp-address@tools.ietf.org; IPv6 Operations; Ron Bonica Subject: Re: [v6ops] Reminder: draft-ietf-v6ops-ivi-icmp-address WGLC >> Such routing advertisements are non-exclusive and should be accepted >> from any originating AS in an anycast fashion. >> >> hmmm. i wonder if we should advise the uprf filterer not to propagate >> the announcement, and for non-uprf players to filter it as a martian? >=20 > What does announcement mean here - is it the ICMP packet or is it the > routing advertisements? Also what does non-urpf players mean? announcements are routing announcements. i have never heard the term used in the data plane. RAMJI: As I see, ICMP pkts are more then dataplane pkts, they do indicate conditions such as Packet too big etc. - basically they announce something. Hence my question. by non-uprf players, i meant routers which are not applying urpf filters. is there a reason they should propagate the announcement of your wka? RAMJI: Even if a router is a non-urpf player, the subsequent routers to which the route is propagated could do uRPF, hence should they not receive the routing advertisement? randy From rvaithia@cisco.com Tue Apr 10 09:29:46 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 023F611E8106 for ; Tue, 10 Apr 2012 09:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id INHmeVmpzyZd for ; Tue, 10 Apr 2012 09:29:45 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 89A2411E80BE for ; Tue, 10 Apr 2012 09:29:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rvaithia@cisco.com; l=1348; q=dns/txt; s=iport; t=1334075385; x=1335284985; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=cw7cYJ3XB/iJ9wQFabSMKG91jDR9a9OjT94Qlo5vS7w=; b=ADisT/GYDHBf3b8n5ey5Kphl56sphgFZyZH7LFfaBX/vZSoECs1cOpXH A3BHSXTClttnXws3jV8Mhgzy1sS8MMBgr6Yucohbzj/am2pFZEJqsXPil 4DClem9z/fMdAFf+vicbuiE8PuDhl290/ACFXQ7RMJzfN/71dPAWuao2F U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAMpfhE+rRDoJ/2dsb2JhbABEuSuBB4IJAQEBAwESAR0KPwUHBAIBCBEEAQELBhcBBgFFCQgBAQQTCBqHZwQBmm2gQI9+YwSIWptfgWmDB4E0BQ X-IronPort-AV: E=Sophos;i="4.75,399,1330905600"; d="scan'208";a="39783699" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 10 Apr 2012 16:29:45 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q3AGTj84002807; Tue, 10 Apr 2012 16:29:45 GMT Received: from xmb-sjc-22e.amer.cisco.com ([128.107.191.115]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Apr 2012 09:29:44 -0700 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, 10 Apr 2012 09:29:42 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] Reminder: draft-ietf-v6ops-ivi-icmp-address WGLC Thread-Index: Ac0W2OdWPummbVgWQoSI8t1RvyKdYwAXXiDg References: <287364FA-E8C5-4918-92D2-E4DD29089A6B@cisco.com><3AEC3FA7-7162-4507-B27D-D35AD7E2D429@cisco.com> From: "Ramji Vaithianathan (rvaithia)" To: "Randy Bush" X-OriginalArrivalTime: 10 Apr 2012 16:29:44.0936 (UTC) FILETIME=[23789E80:01CD1737] X-Mailman-Approved-At: Tue, 10 Apr 2012 09:41:34 -0700 Cc: IETF v6ops list Subject: Re: [v6ops] Reminder: draft-ietf-v6ops-ivi-icmp-address WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 16:29:46 -0000 Hi Randy, Let us look at a stateless NAT64 device, where the V6 translatable addresses have an associated V4 address. Basically the set of these V6 hosts will have an associated V4 prefix which will need to be advertised on the V4 side of the network. If the V4 side of the network is internet, then the prefix associated with the V6 hosts should ideally be advertised to all the routers in the internet, assuming all hosts in the internet need to reach these V6 hosts with translatable addresses. So along with this prefix, we could potentially advertise the WKA as well - basically instead of 1 prefix we have 2 of them. Not sure if this will create additional scalability issues. Basically the V4 prefix associated with the V6 hosts and the wka both go hand-in-hand. Thanks, Ramji -----Original Message----- From: Randy Bush [mailto:randy@psg.com]=20 Sent: Tuesday, April 10, 2012 10:45 AM To: Ramji Vaithianathan (rvaithia) Cc: IETF v6ops list Subject: Re: [v6ops] Reminder: draft-ietf-v6ops-ivi-icmp-address WGLC > RAMJI: Even if a router is a non-urpf player, the subsequent routers to > which the route is propagated could do uRPF, hence should they not > receive the routing advertisement? so all routers in the entire internet should have a route to your wka to all their interfaces? randy From randy@psg.com Tue Apr 10 15:06:44 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1962E11E8137 for ; Tue, 10 Apr 2012 15:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LLXaLFcXhj4k for ; Tue, 10 Apr 2012 15:06:43 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 493E311E812C for ; Tue, 10 Apr 2012 15:06:43 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SHjD0-000Dna-OR; Tue, 10 Apr 2012 22:06:42 +0000 Date: Wed, 11 Apr 2012 07:06:41 +0900 Message-ID: From: Randy Bush To: Ramji Vaithianathan In-Reply-To: References: <287364FA-E8C5-4918-92D2-E4DD29089A6B@cisco.com> <3AEC3FA7-7162-4507-B27D-D35AD7E2D429@cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: IETF v6ops list Subject: Re: [v6ops] Reminder: draft-ietf-v6ops-ivi-icmp-address WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 22:06:44 -0000 ramji: > Let us look at a stateless NAT64 device, where the V6 translatable > addresses have an associated V4 address. Basically the set of these V6 > hosts will have an associated V4 prefix which will need to be advertised > on the V4 side of the network. If the V4 side of the network is > internet, then the prefix associated with the V6 hosts should ideally be > advertised to all the routers in the internet, assuming all hosts in the > internet need to reach these V6 hosts with translatable addresses. So > along with this prefix, we could potentially advertise the WKA as well - > basically instead of 1 prefix we have 2 of them. Not sure if this will > create additional scalability issues. perhaps we should be sure before we propose it? i am not sure we currently have an ipv4 prefix which is agreed to be globally present. globally announced, aren't we all? globally present, not so much. globally present on all interfaces (where uprf is deployed), uh, ... > Basically the V4 prefix associated with the V6 hosts and the wka both go > hand-in-hand. as i conjected from reading. randy From warren@kumari.net Wed Apr 11 17:51:43 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8706A11E80FD for ; Wed, 11 Apr 2012 17:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.283 X-Spam-Level: X-Spam-Status: No, score=-106.283 tagged_above=-999 required=5 tests=[AWL=-0.284, 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 VIQcdB3M1v8i for ; Wed, 11 Apr 2012 17:51:43 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 900A411E8116 for ; Wed, 11 Apr 2012 17:51:38 -0700 (PDT) Received: from [192.168.0.12] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 339F31B40339; Wed, 11 Apr 2012 20:51:37 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Warren Kumari In-Reply-To: <43F84362-C062-401E-97D5-C8DB27CE0E1F@cisco.com> Date: Wed, 11 Apr 2012 20:52:21 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <43F84362-C062-401E-97D5-C8DB27CE0E1F@cisco.com> To: Fred Baker X-Mailer: Apple Mail (2.1257) Cc: IPv6 Operations , v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-ivi-icmp-address WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 00:51:43 -0000 On Apr 1, 2012, at 2:01 PM, Fred Baker wrote: > This is to initiate a two week working group last call of = draft-ietf-v6ops-ivi-icmp-address. Phew, just before the cut-off=85. > Please read it now. If you find nits (spelling errors, minor suggested = wording changes, etc), comment to the authors; if you find greater = issues, such as disagreeing with a statement or finding additional = issues that need to be addressed, please post your comments to the list. Sure -- I (still) have some serious concerns about this draft... It is basically proposing something that looks kinda like source address = anycast ;-) I cannot really understand what an operator is expected to do here. As I = see it, there are two options: Option 1: Simply permit all packets from this address block into the = network, with no regard for uRPF, etc. This options seems like an obvious fail from a DoS / DDoS standpoint -- = I'll have no real way to track these back, know which are legitimate, = etc and so it will become a standard DoS vector=85=20 This leaves me with option 2=85 Option 2: Simply filter all packets from $MAGIC_BLOCK and drop them on = the floor. Now I am back to where we are currently -- might as well just use = RFC1918 space=85 >=20 > We are looking specifically for comments on the importance of the = document as well as its content. If you have read the document and = believe it to be of operational utility, that is also an important = comment to make. I believe it to either be of no operational utility (I'll simply filter = this block) or actual harm (folk will allow it in, and then it will be = used for DoS=85 Sorry, W > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From ietf@cdl.asgaard.org Wed Apr 11 20:27:07 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF2D21F8473 for ; Wed, 11 Apr 2012 20:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uC7211pD3vU1 for ; Wed, 11 Apr 2012 20:27:06 -0700 (PDT) Received: from asgaard.org (odin.asgaard.org [204.29.151.68]) by ietfa.amsl.com (Postfix) with ESMTP id C8A7C21F8472 for ; Wed, 11 Apr 2012 20:27:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by asgaard.org (Postfix) with ESMTP id B3BF210436F1 for ; Thu, 12 Apr 2012 03:27:06 +0000 (UTC) X-Virus-Scanned: amavisd-new at asgaard.org Received: from asgaard.org ([127.0.0.1]) by localhost (odin.asgaard.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oDDgWCsjfbF5 for ; Thu, 12 Apr 2012 03:27:05 +0000 (UTC) Received: from fenrir.asgaard.org (50-76-34-185-ip-static.hfc.comcastbusiness.net [50.76.34.185]) by asgaard.org (Postfix) with ESMTPSA id 8658D10436E5 for ; Thu, 12 Apr 2012 03:27:05 +0000 (UTC) From: Christopher LILJENSTOLPE Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Apr 2012 20:27:04 -0700 Message-Id: To: IPv6 Operations Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [v6ops] Reminder: 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: Thu, 12 Apr 2012 03:27:07 -0000 Greetings, I oppose this draft in its current form. As others have stated here, = the requirement to carry a WKP everywhere in the network. The chances = of abuse are high, and the ability to track is limited, to say the = least. If necessary, a ivi provider COULD use some of their own (or = 1918) address space to generate the ICMP source address, if required. = This should NOT leave the administrative horizon, however. Chris -- =20 =E6=9D=8E=E6=9F=AF=E7=9D=BF Check my PGP key here: https://www.asgaard.org/~cdl/cdl.asc Current vCard here: https://www.asgaard.org/~cdl/cdl.vcf Check my calendar availability: https://tungle.me/cdl From rvaithia@cisco.com Thu Apr 12 00:18:07 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08DF921F85C0 for ; Thu, 12 Apr 2012 00:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.149 X-Spam-Level: X-Spam-Status: No, score=-10.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XtSjP8iqWM-1 for ; Thu, 12 Apr 2012 00:18:06 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD3D21F85BB for ; Thu, 12 Apr 2012 00:18:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rvaithia@cisco.com; l=1531; q=dns/txt; s=iport; t=1334215086; x=1335424686; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=7LpgW3l2UstFoQO6qldQQOHedgi6ziOMMFPyb9jYAyU=; b=b7LWyAl3BCdKz9PJE+DscE8yxQxZE0nyEvSVi9Pky916ULfWahis33BZ 0fPqnP65Wdmv2J6FIKx2paBDCMf84OEaLHbHFluh6LuCoaUqCIyxVWUkQ 85V/7CdC9eksTdjonNk3/XokbByutrzWEvzy7R5dKMpkQ48FGm3z6oRZb g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFiBhk+rRDoJ/2dsb2JhbABDuXCBB4IJAQEBAwESAR0KPwUHBAIBCBEEAQELBhcBBgFFCQgBAQQTCBqHZwQBnnaYIpEWYwSIWptfgWmDBw X-IronPort-AV: E=Sophos;i="4.75,410,1330905600"; d="scan'208";a="37617940" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 12 Apr 2012 07:18:06 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q3C7I5NX017476; Thu, 12 Apr 2012 07:18:06 GMT Received: from xmb-sjc-22e.amer.cisco.com ([128.107.191.115]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 Apr 2012 00:18:06 -0700 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, 12 Apr 2012 00:18:03 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] Reminder: draft-ietf-v6ops-ivi-icmp-address WGLC Thread-Index: Ac0XZjyH264O1jUfQx6G79PAZjR/3QBEJ50w References: <287364FA-E8C5-4918-92D2-E4DD29089A6B@cisco.com><3AEC3FA7-7162-4507-B27D-D35AD7E2D429@cisco.com> From: "Ramji Vaithianathan (rvaithia)" To: "Randy Bush" X-OriginalArrivalTime: 12 Apr 2012 07:18:06.0055 (UTC) FILETIME=[67D3AF70:01CD187C] Cc: IETF v6ops list Subject: Re: [v6ops] Reminder: draft-ietf-v6ops-ivi-icmp-address WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 07:18:07 -0000 One example I could locate is the 6to4 prefix 192.88.99.0/24 which are advertised by 6to4 routers to attract 6to4 traffic. Thanks, Ramji=20 -----Original Message----- From: Randy Bush [mailto:randy@psg.com]=20 Sent: Wednesday, April 11, 2012 3:37 AM To: Ramji Vaithianathan (rvaithia) Cc: IETF v6ops list Subject: Re: [v6ops] Reminder: draft-ietf-v6ops-ivi-icmp-address WGLC ramji: > Let us look at a stateless NAT64 device, where the V6 translatable > addresses have an associated V4 address. Basically the set of these V6 > hosts will have an associated V4 prefix which will need to be advertised > on the V4 side of the network. If the V4 side of the network is > internet, then the prefix associated with the V6 hosts should ideally be > advertised to all the routers in the internet, assuming all hosts in the > internet need to reach these V6 hosts with translatable addresses. So > along with this prefix, we could potentially advertise the WKA as well - > basically instead of 1 prefix we have 2 of them. Not sure if this will > create additional scalability issues. perhaps we should be sure before we propose it? i am not sure we currently have an ipv4 prefix which is agreed to be globally present. globally announced, aren't we all? globally present, not so much. globally present on all interfaces (where uprf is deployed), uh, ... > Basically the V4 prefix associated with the V6 hosts and the wka both go > hand-in-hand. as i conjected from reading. randy From rvaithia@cisco.com Thu Apr 12 00:25:25 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE4AC21F85CD for ; Thu, 12 Apr 2012 00:25:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.119 X-Spam-Level: X-Spam-Status: No, score=-10.119 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uiugpSxGgxry for ; Thu, 12 Apr 2012 00:25:25 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 1430321F85CC for ; Thu, 12 Apr 2012 00:25:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rvaithia@cisco.com; l=2475; q=dns/txt; s=iport; t=1334215525; x=1335425125; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=ZPvqG+zQG4A8KBhr8IqQzHlimSWDzdZonX3hczocYo0=; b=R4YQKdAyX56rdGEM4+c+e84jM8xFlafdx55RV6Yu2LCK5Bu0IlA9DlrG QQ3ZB8JCQAl82TEf8LP0L+GwV+pA2XXeJW7gA79VM0HjQPIGCWIwgzVaR EmbdOUcRS4cbY2pC8rnkDvlWFgInRhcq9cEYGXidO9bRUay7vBlTPq1LP 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAHaChk+rRDoH/2dsb2JhbABDuXCBB4IJAQEBAwEBAQEPAR0KNAsFBwQCAQgRBAEBCwYXAQYBJh8JCAEBBAESCBqHZwQBC55rmB0EkRZjBIham1+BaYMH X-IronPort-AV: E=Sophos;i="4.75,410,1330905600"; d="scan'208";a="40105697" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 12 Apr 2012 07:25:24 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q3C7POrR009239; Thu, 12 Apr 2012 07:25:24 GMT Received: from xmb-sjc-22e.amer.cisco.com ([128.107.191.115]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 Apr 2012 00:25:24 -0700 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, 12 Apr 2012 00:25:22 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] draft-ietf-v6ops-ivi-icmp-address WGLC Thread-Index: Ac0YRnWhtndpVITVStqzjfPD3rXrVgANhRRA References: <43F84362-C062-401E-97D5-C8DB27CE0E1F@cisco.com> From: "Ramji Vaithianathan (rvaithia)" To: "Warren Kumari" , "Fred Baker (fred)" X-OriginalArrivalTime: 12 Apr 2012 07:25:24.0646 (UTC) FILETIME=[6D3F5C60:01CD187D] Cc: IPv6 Operations , v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-ivi-icmp-address WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 07:25:26 -0000 Regarding Option 1, the draft talks about advertising the special prefix, so routers can do an uRPF check to ensure that the pkts have a reverse path to the NAT64 translator which supports this prefix. Thanks, Ramji -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Warren Kumari Sent: Thursday, April 12, 2012 6:22 AM To: Fred Baker (fred) Cc: IPv6 Operations; v6ops-chairs@tools.ietf.org; Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-ivi-icmp-address WGLC On Apr 1, 2012, at 2:01 PM, Fred Baker wrote: > This is to initiate a two week working group last call of draft-ietf-v6ops-ivi-icmp-address. Phew, just before the cut-off.... > Please read it now. If you find nits (spelling errors, minor suggested wording changes, etc), comment to the authors; if you find greater issues, such as disagreeing with a statement or finding additional issues that need to be addressed, please post your comments to the list. Sure -- I (still) have some serious concerns about this draft... It is basically proposing something that looks kinda like source address anycast ;-) I cannot really understand what an operator is expected to do here. As I see it, there are two options: Option 1: Simply permit all packets from this address block into the network, with no regard for uRPF, etc. This options seems like an obvious fail from a DoS / DDoS standpoint -- I'll have no real way to track these back, know which are legitimate, etc and so it will become a standard DoS vector...=20 This leaves me with option 2... Option 2: Simply filter all packets from $MAGIC_BLOCK and drop them on the floor. Now I am back to where we are currently -- might as well just use RFC1918 space... >=20 > We are looking specifically for comments on the importance of the document as well as its content. If you have read the document and believe it to be of operational utility, that is also an important comment to make. I believe it to either be of no operational utility (I'll simply filter this block) or actual harm (folk will allow it in, and then it will be used for DoS... Sorry, W > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From randy@psg.com Thu Apr 12 00:35:32 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ABB321F858D for ; Thu, 12 Apr 2012 00:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 GpdiJ6yI97sg for ; Thu, 12 Apr 2012 00:35:31 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id CD51621F850C for ; Thu, 12 Apr 2012 00:35:31 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SIEZ0-0005zW-J7; Thu, 12 Apr 2012 07:35:30 +0000 Date: Thu, 12 Apr 2012 16:35:29 +0900 Message-ID: From: Randy Bush To: Ramji Vaithianathan In-Reply-To: References: <287364FA-E8C5-4918-92D2-E4DD29089A6B@cisco.com> <3AEC3FA7-7162-4507-B27D-D35AD7E2D429@cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: IETF v6oops list Subject: Re: [v6ops] Reminder: draft-ietf-v6ops-ivi-icmp-address WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 07:35:32 -0000 > One example I could locate is the 6to4 prefix 192.88.99.0/24 which > are advertised by 6to4 routers to attract 6to4 traffic. these are normal advertisements, and do not require configuration on my routers (which are not otherwise connected to the 6to4 disaster). and note how well the 6to4 disaster worked out. your hack will require me to manually configure fake routes on all interfaces of all my routers which use urpf. not bloody likely. randy From wesley.george@twcable.com Thu Apr 12 09:47:47 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E1B521F8604 for ; Thu, 12 Apr 2012 09:47:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.464 X-Spam-Level: X-Spam-Status: No, score=0.464 tagged_above=-999 required=5 tests=[AWL=-0.563, BAYES_05=-1.11, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E0Axzry0Y51l for ; Thu, 12 Apr 2012 09:47:44 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 3035D21F864D for ; Thu, 12 Apr 2012 09:47:44 -0700 (PDT) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.75,411,1330923600"; d="scan'208,217";a="350365817" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 12 Apr 2012 12:47:00 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Thu, 12 Apr 2012 12:47:43 -0400 From: "George, Wes" To: Fred Baker , IPv6 Operations Date: Thu, 12 Apr 2012 12:47:42 -0400 Thread-Topic: [v6ops] draft-ietf-v6ops-ivi-icmp-address WGLC Thread-Index: Ac0QRSmQmHNavsJwQAKIUNv4LpLRAQIg5ptA Message-ID: References: <43F84362-C062-401E-97D5-C8DB27CE0E1F@cisco.com> In-Reply-To: <43F84362-C062-401E-97D5-C8DB27CE0E1F@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_DCC302FAA9FE5F4BBA4DCAD465693779173DCB5EBEPRVPEXVS03cor_" MIME-Version: 1.0 Cc: "v6ops-chairs@tools.ietf.org" , Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-ivi-icmp-address WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 16:47:47 -0000 --_000_DCC302FAA9FE5F4BBA4DCAD465693779173DCB5EBEPRVPEXVS03cor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm opposed to this draft in its current form. Others have already expressed the concern about a WKP and its security impl= ications, so I won't retread. I also have misgivings about the effectiveness of managing something like a= n MTU problem across a translator by expecting networks to carry these tran= slated IPv4 packets from what amounts to an unknown source to convey "packe= t too big" such that it results in correct behavior more than about half of= the time. We can't make this work reliably today (people filtering more IC= MP types than they should because "ICMP is bad")! Further, the draft doesn'= t provide too many other examples of critical ICMP messages that would be n= eeded from end host to end host. Some other examples, along with explanatio= ns about why this is the only way to resolve them would go a long way to bo= lstering the case for this implementation. For example, if we're talking ab= out traces and pings, I don't view this as a robust troubleshooting method = - if I get timeouts, how do I know whether there's a problem on the path, o= r if I've simply strayed into Warren's network and he's decided to block pa= ckets with this source address? I'm not sure an enhanced traceroute fixes t= his. Ok I lied, I will mention one security problem that I haven't seen mentione= d already. I think that there is a potential for a crafted-packet DoS attac= k on the end user or the gateways. What's to stop an attacker from sending = "packet to big" messages sourced from this WKP to the endpoints such that t= he MTU continues to get reduced and reduced until it's sending out 64-byte = packets? Anything under 1280 would require some sort of intervening fragmen= tation between the IPv6 endpoints (whatever is acting as the "host"), or if= you're looking in the opposite direction, would simply create IPv6 packets= that have a larger header than data payload (because the original IPv4 pac= ket was 64 bytes), and packets that small create all sorts of nasty problem= s with things like firewalls, linerate packet forwarding, etc. I think I like the idea of recommending that the solution to this problem i= s that the carrier managing this stateless translator MUST provide an IP ad= dress or block to be used as the source address for ICMP messages from untr= anslatable IPv6 addresses. No WKP, just let them allocate one. You could th= en discuss what the pros and cons are to using 1918 addresses for this purp= ose vs. a real globally unique address or block. I'm not sure that this met= hod would address the security concerns to everyone's satisfaction either, = but I think I'm seeing clear opposition to a WKP. Thanks, Wes George From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of F= red Baker Sent: Sunday, April 01, 2012 2:02 PM To: IPv6 Operations Cc: v6ops-chairs@tools.ietf.org; Ron Bonica Subject: [v6ops] draft-ietf-v6ops-ivi-icmp-address WGLC This is to initiate a two week working group last call of draft-ietf-v6ops-= ivi-icmp-address. Please read it now. If you find nits (spelling errors, mi= nor suggested wording changes, etc), comment to the authors; if you find gr= eater issues, such as disagreeing with a statement or finding additional is= sues that need to be addressed, please post your comments to the list. We are looking specifically for comments on the importance of the document = as well as its content. If you have read the document and believe it to be = of operational utility, that is also an important comment to make. ________________________________ 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_DCC302FAA9FE5F4BBA4DCAD465693779173DCB5EBEPRVPEXVS03cor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m opposed to this= draft in its current form.

 <= /p>

Others have already expre= ssed the concern about a WKP and its security implications, so I won’= t retread.

 <= /p>

I also have misgivings ab= out the effectiveness of managing something like an MTU problem across a tr= anslator by expecting networks to carry these translated IPv4 packets from what amounts to an unknown source to convey “packe= t too big” such that it results in correct behavior more than about h= alf of the time. We can’t make this work reliably today (people filte= ring more ICMP types than they should because “ICMP is bad”)! Further, the draft doesn’t provide too many other ex= amples of critical ICMP messages that would be needed from end host to end = host. Some other examples, along with explanations about why this is the on= ly way to resolve them would go a long way to bolstering the case for this implementation. For example, if we’re t= alking about traces and pings, I don’t view this as a robust troubles= hooting method – if I get timeouts, how do I know whether there’= ;s a problem on the path, or if I’ve simply strayed into Warren’s network and he’s decided to block packets with this s= ource address? I’m not sure an enhanced traceroute fixes this.

 <= /p>

Ok I lied, I will mention= one security problem that I haven’t seen mentioned already. I think = that there is a potential for a crafted-packet DoS attack on the end user or the gateways. What’s to stop an attacker from sending &#= 8220;packet to big” messages sourced from this WKP to the endpoints s= uch that the MTU continues to get reduced and reduced until it’s send= ing out 64-byte packets? Anything under 1280 would require some sort of intervening fragmentation between the IPv6 endpoints (whateve= r is acting as the “host”), or if you’re looking in the o= pposite direction, would simply create IPv6 packets that have a larger head= er than data payload (because the original IPv4 packet was 64 bytes), and packets that small create all sorts of nasty problems w= ith things like firewalls, linerate packet forwarding, etc.

 <= /p>

I think I like the idea o= f recommending that the solution to this problem is that the carrier managi= ng this stateless translator MUST provide an IP address or block to be used as the source address for ICMP messages from untransla= table IPv6 addresses. No WKP, just let them allocate one. You could then di= scuss what the pros and cons are to using 1918 addresses for this purpose v= s. a real globally unique address or block. I’m not sure that this method would address the security c= oncerns to everyone’s satisfaction either, but I think I’m seei= ng clear opposition to a WKP.

 <= /p>

Thanks,=

 <= /p>

Wes George

 <= /p>

From: v6ops-bo= unces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Fred Baker
Sent: Sunday, April 01, 2012 2:02 PM
To: IPv6 Operations
Cc: v6ops-chairs@tools.ietf.org; Ron Bonica
Subject: [v6ops] draft-ietf-v6ops-ivi-icmp-address WGLC

 

This is to initiate a two week working= group last call of draft-ietf-v6ops-ivi-icmp-address. Please read it now. = If you find nits (spelling errors, minor suggested wording changes, etc), comment to the authors; if you find greater issues, such as disagree= ing with a statement or finding additional issues that need to be addressed= , please post your comments to the list.

 

We are looking specifically for commen= ts on the importance of the document as well as its content. If you have re= ad the document and believe it to be of operational utility, that is also an important comment to make.


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_DCC302FAA9FE5F4BBA4DCAD465693779173DCB5EBEPRVPEXVS03cor_-- From rajiva@cisco.com Thu Apr 12 09:58:09 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA7121F86C3 for ; Thu, 12 Apr 2012 09:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.339 X-Spam-Level: X-Spam-Status: No, score=-10.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdVmhCWMMo-G for ; Thu, 12 Apr 2012 09:58:08 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 62B2521F8623 for ; Thu, 12 Apr 2012 09:58:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=5353; q=dns/txt; s=iport; t=1334249887; x=1335459487; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=Fyze94kVEUhKxJsE4clt85oi26Kari40EpVpaz17bK0=; b=l4V9venj9TdK6B62koiSElHcIlnCPAMP47nLnqKDxjRB1V0hO2AGmEuo ElNYASWfdbe7WX4NBwcagxPz7zaFOEZ65zU+yea8U8tvRm7AeNNzZPoij XEe7jK7AeOzNkcADGVTOxNwg76gP1TuSNt2kg9dw5ipMxE6/GkkUeR+Nu Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIAIh0+tJV2c/2dsb2JhbABEuXaBB4IJAQEBAwESAR0KLQsHBQcEAgEIEQQBAQsGFwEGAUUJCAEBBAESCBMHh2cFmiygDIszhWhjBIham1+BaYMFgT4 X-IronPort-AV: E=Sophos;i="4.75,411,1330905600"; d="scan'208";a="74209061" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP; 12 Apr 2012 16:58:07 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id q3CGw6Ku026586; Thu, 12 Apr 2012 16:58:06 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 Apr 2012 11:58:06 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Apr 2012 11:58:05 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C07F1EEFA@XMB-RCD-111.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] draft-ietf-v6ops-ivi-icmp-address WGLC Thread-Index: Ac0QRSmQmHNavsJwQAKIUNv4LpLRAQIg5ptAAAD/C8A= References: <43F84362-C062-401E-97D5-C8DB27CE0E1F@cisco.com> From: "Rajiv Asati (rajiva)" To: "George, Wes" , "Fred Baker (fred)" , "IPv6 Operations" X-OriginalArrivalTime: 12 Apr 2012 16:58:06.0483 (UTC) FILETIME=[6E7F9630:01CD18CD] Cc: v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-ivi-icmp-address WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 16:58:09 -0000 > I think I like the idea of recommending that the solution to this problem is that > the carrier managing this stateless translator MUST provide an IP address or > block to be used as the source address for ICMP messages from untranslatable > IPv6 addresses. No WKP, just let them allocate one. =20 +1. Just follow what 6rd did by letting go WKP and allowing the operator to allocate one of their own prefixes. Cheers, Rajiv > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > George, Wes > Sent: Thursday, April 12, 2012 12:48 PM > To: Fred Baker (fred); IPv6 Operations > Cc: v6ops-chairs@tools.ietf.org; Ron Bonica > Subject: Re: [v6ops] draft-ietf-v6ops-ivi-icmp-address WGLC >=20 > I'm opposed to this draft in its current form. >=20 >=20 >=20 > Others have already expressed the concern about a WKP and its security > implications, so I won't retread. >=20 >=20 >=20 > I also have misgivings about the effectiveness of managing something like an > MTU problem across a translator by expecting networks to carry these > translated IPv4 packets from what amounts to an unknown source to convey > "packet too big" such that it results in correct behavior more than about half of > the time. We can't make this work reliably today (people filtering more ICMP > types than they should because "ICMP is bad")! Further, the draft doesn't > provide too many other examples of critical ICMP messages that would be > needed from end host to end host. Some other examples, along with > explanations about why this is the only way to resolve them would go a long > way to bolstering the case for this implementation. For example, if we're > talking about traces and pings, I don't view this as a robust troubleshooting > method - if I get timeouts, how do I know whether there's a problem on the > path, or if I've simply strayed into Warren's network and he's decided to block > packets with this source address? I'm not sure an enhanced traceroute fixes > this. >=20 >=20 >=20 > Ok I lied, I will mention one security problem that I haven't seen mentioned > already. I think that there is a potential for a crafted-packet DoS attack on the > end user or the gateways. What's to stop an attacker from sending "packet to > big" messages sourced from this WKP to the endpoints such that the MTU > continues to get reduced and reduced until it's sending out 64-byte packets? > Anything under 1280 would require some sort of intervening fragmentation > between the IPv6 endpoints (whatever is acting as the "host"), or if you're > looking in the opposite direction, would simply create IPv6 packets that have a > larger header than data payload (because the original IPv4 packet was 64 > bytes), and packets that small create all sorts of nasty problems with things like > firewalls, linerate packet forwarding, etc. >=20 >=20 >=20 > I think I like the idea of recommending that the solution to this problem is that > the carrier managing this stateless translator MUST provide an IP address or > block to be used as the source address for ICMP messages from untranslatable > IPv6 addresses. No WKP, just let them allocate one. You could then discuss what > the pros and cons are to using 1918 addresses for this purpose vs. a real > globally unique address or block. I'm not sure that this method would address > the security concerns to everyone's satisfaction either, but I think I'm seeing > clear opposition to a WKP. >=20 >=20 >=20 > Thanks, >=20 >=20 >=20 > Wes George >=20 >=20 >=20 > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Fred Baker > Sent: Sunday, April 01, 2012 2:02 PM > To: IPv6 Operations > Cc: v6ops-chairs@tools.ietf.org; Ron Bonica > Subject: [v6ops] draft-ietf-v6ops-ivi-icmp-address WGLC >=20 >=20 >=20 > This is to initiate a two week working group last call of draft-ietf-v6ops-ivi- > icmp-address. Please read it now. If you find nits (spelling errors, minor > suggested wording changes, etc), comment to the authors; if you find greater > issues, such as disagreeing with a statement or finding additional issues that > need to be addressed, please post your comments to the list. >=20 >=20 >=20 > We are looking specifically for comments on the importance of the document > as well as its content. If you have read the document and believe it to be of > operational utility, that is also an important comment to make. >=20 >=20 > ________________________________ >=20 > This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or subject to > copyright belonging to Time Warner Cable. This E-mail is intended solely for > the use of the individual or entity to which it is addressed. If you are not the > intended recipient of this E-mail, you are hereby notified that any > dissemination, distribution, copying, or action taken in relation to the contents > of and attachments to this E-mail is strictly prohibited and may be unlawful. If > you have received this E-mail in error, please notify the sender immediately > and permanently delete the original and any copy of this E-mail and any > printout. From fred@cisco.com Thu Apr 12 10:21:50 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DD5F21F86B0 for ; Thu, 12 Apr 2012 10:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8RZC5LpKxGIg for ; Thu, 12 Apr 2012 10:21:49 -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 4EC8921F86A7 for ; Thu, 12 Apr 2012 10:21:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1254; q=dns/txt; s=iport; t=1334251309; x=1335460909; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=/Aiu9euonfB5pJ48q1uhtnM8bHs1Em86lVhrukDTNPQ=; b=PwEMFkb/hIiU6Q9m1dJ9v6kVAILcuY/WZ1EnzLGfbb5+ffogJKNw+zW9 P7dnSB/dwSmFZpG0Nse23UcqONIwKasrVOx2uYuAwH123G1NxO4Vdy+Pq 4Mzn+qPDZrLrvNwGTENvasS4LWE/1JTjvY4d0YXstTkddPUvGy06Av14d E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAGYOh0+rRDoI/2dsb2JhbAA6Crl2gQeCCgEBBBIBJz8QC0ZXBjWHawGaLKAOiyqFcWMEiFqNEoVyiFuBaYMH X-IronPort-AV: E=Sophos;i="4.75,411,1330905600"; d="scan'208";a="40289988" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 12 Apr 2012 17:21:44 +0000 Received: from dhcp-64-101-108-127.cisco.com (dhcp-64-101-108-127.cisco.com [64.101.108.127]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3CHLh63016294; Thu, 12 Apr 2012 17:21:44 GMT Received: from [127.0.0.1] by dhcp-64-101-108-127.cisco.com (PGP Universal service); Thu, 12 Apr 2012 10:21:44 -0700 X-PGP-Universal: processed; by dhcp-64-101-108-127.cisco.com on Thu, 12 Apr 2012 10:21:44 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <43F84362-C062-401E-97D5-C8DB27CE0E1F@cisco.com> Date: Thu, 12 Apr 2012 10:21:29 -0700 Message-Id: References: <43F84362-C062-401E-97D5-C8DB27CE0E1F@cisco.com> To: IPv6 Operations X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-ivi-icmp-address WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 17:21:50 -0000 So, let me see if I can summarize the comments so far. I'm going to = leave out a lot of detail, and focus on the big picture, and in that I = *think* develop a way forward. This is not a pronouncement, it's a = question, and what I'm looking for is agreement, disagreement, and = additional nuance where needed. I haven't heard any complaints about using RFC 5837 extensions to = identify the actual IPv6 address of a system that is identifying a = problem. I have heard that currently-deployed applications may or may = not use it effectively, and so it is less useful than it might be. What I have heard is an issue about using a specified IPv4 address as = source in data directed from the translator to an application. Issues = raised include BCP 38 issues, operational requirements to advertise an = address that is not intended to be used as a destination, and the = possibility of attacks on that address. So, I think the fairest thing we can say is that working group consensus = does not support the draft as it stands, and specifically does not = support the allocation of a prefix for the purpose. What the working = group *might* support is guidance on how best to use RFC 5837 for the = purpose. Your thoughts?= From cb.list6@gmail.com Thu Apr 12 18:42:47 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED84D21F8692 for ; Thu, 12 Apr 2012 18:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.57 X-Spam-Level: X-Spam-Status: No, score=-3.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 4rM3u0kMeyh5 for ; Thu, 12 Apr 2012 18:42:46 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD2F21F8680 for ; Thu, 12 Apr 2012 18:42:46 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so1110656pbb.31 for ; Thu, 12 Apr 2012 18:42:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=fYdKwObo0jrd0qN3gLmdfswPgT4POmw1errTuRmbGkA=; b=oWMdbiSUbAr3kYf/QQhNo9NFcK02b1pVy9eGmqTWt7YT/ubFmxrFGKT9KbPbsQtaZm dx1g1cYqGAk+ZUdkwO8+z4tfQodWRAac4tfBdhG/WrwoAWkMxhi0couWT7UTKH65WQhI 4IsX7aI4lXdPCwVBskzdxyxrHDpnTafMQsHUGSXRhKBVh0K0ljSrsofxzeNxSKrlUHUG 4QfcQm4cV0Wd6Dh/fSHt/iungUFiUTn6m96ix53F2g3qxMq1myy7CyCuhtpHKtvG4J0z HEoUn60C3a683CL1o2trZ1iqDL0BQZwyivaFcDdY9I5ke366QuWpQQw6lY5IzS6/TWw7 3rWg== MIME-Version: 1.0 Received: by 10.68.223.67 with SMTP id qs3mr280982pbc.142.1334281366179; Thu, 12 Apr 2012 18:42:46 -0700 (PDT) Received: by 10.142.102.1 with HTTP; Thu, 12 Apr 2012 18:42:46 -0700 (PDT) In-Reply-To: References: Date: Thu, 12 Apr 2012 18:42:46 -0700 Message-ID: From: Cameron Byrne To: IPv6 Ops WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [v6ops] 464XLAT from informational to BCP -- Document Change Manifest X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 01:42:47 -0000 Hi all, We are preparing to publish the next revision of 464XLAT as BCP 2 questions: 1. BCP OK as Fred suggested? Or informational? 2. Any other changes aside from the ones listed below? Thanks! CB PS: Easy button to the draft -> http://tools.ietf.org/html/draft-ietf-v6ops-464xlat PPS: Hopefully useful info on how you too can try 464XLAT, as well as test results, https://sites.google.com/site/tmoipv6/464xlat On Wed, Mar 28, 2012 at 3:01 PM, Cameron Byrne wrote: > Folks, > > For the sake of clarity, what i understand from Fred's email, and has > been supported by 3 people so far, is that there is desire to move > from informational to BCP and some changes are required along the way. > > I believe these specific changes are required from my reading of > Fred's mail, let me know if something is missing: > > 1. Change document category from informational to BCP > > 2. =A0Re-insert RFC 2119 keywords > > 3. Replace all text in section in 6.1 with this one sentence "The XLAT > Prefix format used on the CLAT for RFC6145 translation =A0is defined in > =A0 Section 2.2 of [RFC6052]. " =A0Also, remove all references to /96 in > section 6.5. =A0Update diagram in 6.2 to remove /96. > > 4. =A0The DNS proxy section will add a reference to RFC5625, such as > adding the sentence to the beginning of section 6.4 stating "The CLAT > SHOULD implement a DNS proxy as defined in RFC 5625." > > Am I missing something? > > Are these the agreeable terms of moving forward with 464XLAT as a BCP > instead of informational? > > Thanks for the feedback and helping to clarify the path forward > > Cameron From lorenzo@google.com Thu Apr 12 19:32:18 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3247221F84B2 for ; Thu, 12 Apr 2012 19:32:18 -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 9m5inxDucPHl for ; Thu, 12 Apr 2012 19:32:17 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id AA2A321F84AE for ; Thu, 12 Apr 2012 19:32:17 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so4089746obb.31 for ; Thu, 12 Apr 2012 19:32:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=KSi47McTGHX+GC7l0tLV4pQ8yS6trWxNeyTYPECm2aA=; b=FQab+0jnyCkB8C9MrFnz/u7PS1ImZLbNA6qYLOSOUKhs4N/C5tHG6EWVBdU9+1cv0R RoGiMed2PkmzCIqi4b8HrpRvWW/R+wEwq4HEG9Y4obcqP8wa/dO497IH/FPHaxQZBlLZ +nkWX7zaLrhkp1P7giFIg9TrJUbFBE08Q/CfAXGcJM0Ed69zjsCTKcW05hxKh03SC1da OEsuaiPD6pNMYXccYt458uvq9EyDTwNFlYgAzYnjR+jutQWiT55eUmkej1PMbNox3SSw taOAfLtzxYD0hmEtLvM3FQKJlNCEMyuJNeR7vYDYV8Ye8H0AV6ci9oaMt2UtIDizJtaA g1rQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=KSi47McTGHX+GC7l0tLV4pQ8yS6trWxNeyTYPECm2aA=; b=n9F2sTGYWQ/rOW9BHeTaebLcqcnoDiYZxtgav8XN9b5+J0cID0Jp5/68+lTk0p7Mks GAmW0X5nLpnIY21VDOtfpqKkus1RDzyKbDvFOf2zfDJ1u3OtbIAS8wq/EIHDd7MsEeAy mBXAMe3qY8pKXzfEB2MLhfnqHJ5Nd1tnxNjNu8uSNbnrvgic0wwaZvxKJS/ssXYKaWMd FL2pIfHI8yiYg4k/HRA0APWp2/qwinMLr2s2opwjJeiX24lSHEaiV/DSh5Oq+N58PlXY hbKSV9pmQFoTCCpU//JDVM7vadbp+8gZx4Qp/dlSbUML4KAqVtQ0LxyurvgrSBOR8H+U RFOQ== Received: by 10.60.0.226 with SMTP id 2mr629351oeh.18.1334284337192; Thu, 12 Apr 2012 19:32:17 -0700 (PDT) Received: by 10.60.0.226 with SMTP id 2mr629270oeh.18.1334284335451; Thu, 12 Apr 2012 19:32:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.61.193 with HTTP; Thu, 12 Apr 2012 19:31:55 -0700 (PDT) In-Reply-To: References: From: Lorenzo Colitti Date: Fri, 13 Apr 2012 11:31:55 +0900 Message-ID: To: Cameron Byrne Content-Type: multipart/alternative; boundary=e89a8fb1fbc6d80e7204bd86474b X-System-Of-Record: true X-Gm-Message-State: ALoCoQn4gQHP2U9wykYN0yT8JX/Cpz5OCqSEA4CTIra8Tr4S3JwVKWN9PWmvmLbcehbrEOK5GR5oO8LlQ+gRF5/TroMUpyJauwkK8N/Czsg5Tlu0gMORXMPLyj2DyEfSXzLjp8fTNdwE Cc: IPv6 Ops WG Subject: Re: [v6ops] 464XLAT from informational to BCP -- Document Change Manifest X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 02:32:18 -0000 --e89a8fb1fbc6d80e7204bd86474b Content-Type: text/plain; charset=ISO-8859-1 On Fri, Apr 13, 2012 at 10:42, Cameron Byrne wrote: > 2. Any other changes aside from the ones listed below? > Why do we need to say anything about DNS proxying? I thought the controversy around proxying was about for neighbour discovery proxying, not DNS proxying. --e89a8fb1fbc6d80e7204bd86474b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Apr 13, 2012 at 10:42, Cameron Byrne <cb.list6@gmail.com= > wrote:
2. =A0Any other changes aside from the ones listed below?
<= div>
Why do we need to say anything about DNS proxying? I tho= ught the controversy around proxying was about for neighbour discovery prox= ying, not DNS proxying.
--e89a8fb1fbc6d80e7204bd86474b-- From cb.list6@gmail.com Thu Apr 12 20:19:09 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C04C21F86F4 for ; Thu, 12 Apr 2012 20:19:09 -0700 (PDT) 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 7RquooR9CmQi for ; Thu, 12 Apr 2012 20:19:09 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7184221F86E2 for ; Thu, 12 Apr 2012 20:19:02 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so1180827pbb.31 for ; Thu, 12 Apr 2012 20:19:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=4a9gWAQcMQXxVbUqel06+z5eYgSUug+wzQYv3oD/kk4=; b=zVTrUw5gO2YcUNld1aJ+HNxE6bqqC8x5blwDcEXj2ieW7yawd1hkZrzCvGUs2BAThp IQEroD80i1219ZGR9ezR7PXo2LKDQ01TMxsqDuNeaDDLLfQOXYdRsYhlNdI3mH0snMlW Czg+nOqjrksbssMuImUioCuE2LnkBdfRsRmPYbJfmSsfyMuwIWXjpHAlohcFNiZdNrk+ CXRfu3G+r7/BE/jVvVcvkvOtLxBza73uNDCsf4hRu90r3j3LQj+nkSHCD3nINJiGbAfW 4BjJGrEoqkC7LrVZS8ZEZGwk1JMrEyNqB01U/xWusOdGuyMqUsKAEs3OcIAwOgD+rLGY 5kGQ== MIME-Version: 1.0 Received: by 10.68.195.232 with SMTP id ih8mr920866pbc.118.1334287142264; Thu, 12 Apr 2012 20:19:02 -0700 (PDT) Received: by 10.142.102.1 with HTTP; Thu, 12 Apr 2012 20:19:02 -0700 (PDT) In-Reply-To: References: Date: Thu, 12 Apr 2012 20:19:02 -0700 Message-ID: From: Cameron Byrne To: Lorenzo Colitti Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Ops WG Subject: Re: [v6ops] 464XLAT from informational to BCP -- Document Change Manifest X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 03:19:09 -0000 On Thu, Apr 12, 2012 at 7:31 PM, Lorenzo Colitti wrote= : > On Fri, Apr 13, 2012 at 10:42, Cameron Byrne wrote: >> >> 2. =A0Any other changes aside from the ones listed below? > > > Why do we need to say anything about DNS proxying? I thought the controve= rsy > around proxying was about for neighbour discovery proxying, not DNS > proxying. There have been several mails about DNS proxy as well as claiming IPv6 addresses for sourcing CLAT RFC 6145 translations. I believe the draft in its current form makes it clear that neither are mandatory, but they both provide utility in certain circumstances. DNS Proxy -- http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-01#section= -6.4 We suggest that CLAT proxy DNS to make the DNS transaction native IPv6 from the CLAT and avoid stateful translation of every DNS query on the PLAT. But, double translation of client IPv4 DNS queries to an arbitrary IPv4 DNS server is supported. The change log reflects adding a reference to RFC5625 Prefix handing --http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-01#sec= tion-6.5 Multiple methods are defined, including doing NAT446 on the CLAT so that all LAN IPv4 flows are NAT44 to a single IPv4 address, then that single IPv4 address is mapped to single IPv6 source address. Is there something specific that needs to be added or deleted from the current draft or change log? CB From lorenzo@google.com Thu Apr 12 20:48:17 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76CAE21F877C for ; Thu, 12 Apr 2012 20:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.676 X-Spam-Level: X-Spam-Status: No, score=-102.676 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XDwhYlHhJnFY for ; Thu, 12 Apr 2012 20:48:16 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id C22A721F8767 for ; Thu, 12 Apr 2012 20:48:16 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so4170654obb.31 for ; Thu, 12 Apr 2012 20:48:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=DGLVah/k3ZqU8cAN5HJRGfiYGG95xCl+7CYeiicdy0Y=; b=looT0FuD16kqXVdHMW6c+FIALxEvactdvn7HjDyTQELoiHW/mE3H+kOjO9PnXEC5uy 6GpLLAELB66++RkgMyznwtUgZ0N1q1CJ2+ZhGPnPPG38aBzdmiu6+vGGfO0tPYCYw8mC HBmJtisM0rDMZth13SvwiBVKZfPz1MhaxYFenj5pwo3ezikJNCaiPajfYNs+gGgP8Nz4 k/h+mGJlAk4auYa64HLz86OxHTifDBM+Dg5pfhA1d4mhsKmRZUD1wyFi7bgGk5DCuTxd ciRc1+1o9+PCMbylGFssuzBsM+gBf7dEL2542QbaiqRSZSHpCUHEvLcXCTNq7nwLLHZ5 b+pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=DGLVah/k3ZqU8cAN5HJRGfiYGG95xCl+7CYeiicdy0Y=; b=Z0/PO6NrO0kWwyFPq0c1a5y4SGXUnYAk1fIFKew2cyJpIsqvESIcxAVt6Ek8GLUQQS k+Z8Vs9RCRoja64Mfd3SqynsuFoFRBh+2zknOLsAJ5J70ydRGUpzEm1G53DHwqA78tHG rUW2Vs1FGDdOJf8qT+Q9RAh5HyQ1vlTzyRZ92RyOa1b0KPvXbiE6X5MRPlV2oYdTt6li Iu7HkY/ij/hs0XE7elxye0UosztoZTD0FRGy6zwiekAmKloQnzOftf2jYmaWnzDN6rlI NlBCDJD1xHG0CND89ik/HkW8k6fttPIONX+wjqtmfOe6XbMi34BC0Eak/NiB0GeF0dF7 7Sxg== Received: by 10.60.8.129 with SMTP id r1mr147266oea.28.1334288896447; Thu, 12 Apr 2012 20:48:16 -0700 (PDT) Received: by 10.60.8.129 with SMTP id r1mr147253oea.28.1334288896265; Thu, 12 Apr 2012 20:48:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.61.193 with HTTP; Thu, 12 Apr 2012 20:47:56 -0700 (PDT) In-Reply-To: References: From: Lorenzo Colitti Date: Fri, 13 Apr 2012 12:47:56 +0900 Message-ID: To: Cameron Byrne Content-Type: multipart/alternative; boundary=e89a8f839cbdb08f0d04bd8757fa X-System-Of-Record: true X-Gm-Message-State: ALoCoQm2LcLrI3FGh2oVEqVoq3EELXeNHUM1/7RjBDb4QE35j8SHdTZGqdmpwMeHddyMbHxR7WCHXOhk5H8ZwStvjUFa3GbHIlptBOmHYNs/WocR3QAu/OJjYc459mKqFeRx2jEOgc7Q Cc: IPv6 Ops WG Subject: Re: [v6ops] 464XLAT from informational to BCP -- Document Change Manifest X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 03:48:17 -0000 --e89a8f839cbdb08f0d04bd8757fa Content-Type: text/plain; charset=ISO-8859-1 On Fri, Apr 13, 2012 at 12:19, Cameron Byrne wrote: > We suggest that CLAT proxy DNS to make the DNS transaction native > IPv6 from the CLAT and avoid stateful translation of every DNS query on the > PLAT. I think this is not controversial, because you don't need to define any new behaviour. You simply run a DNS forwarder on the CLAT. Was there objection to stating this as being optional but recommended? Prefix handing -- > http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-01#section-6.5 > > Multiple methods are defined, including doing NAT446 on the CLAT so > that all LAN IPv4 flows are NAT44 to a single IPv4 address, then that > single IPv4 address is mapped to single IPv6 source address. > > Is there something specific that needs to be added or deleted from the > current draft or change log? I think the "take ownership of a /96" text was controversial. I believe the objection is as follows: - If you claim a /96 on the link, you have to ensure that DAD fails for addresses in that /96. This behaviour is not specified anywhere, and the operational implications (e.g., the possibility of other hosts giving up because every address they try is taken) are not considered anywhere. - The reason why this document is in v6ops is that it does not define any new behaviour, but only how to cobble together existing behaviour to achieve a useful result. - v6ops cannot define new behaviour; that belongs elsewhere So if you want to keep this in the draft, you have to specify how to do it (probably in 6man) and possibly write up the operational implications (here in v6ops). And of course, you also have to implement it, and it's much more complex to implement than simply using a /128. I think that if you're in a hurry to get this document through the process, you should just remove the /112 mode from the draft completely. I don't see it as being particularly useful either. What can you do with the /112 mode that you can't do with a NAT44 on the CLAT? If the use case is a mobile device, then they implement NAT44 anyway. If you want to provide "better quality" IPv4 access to nodes behind the CLAT, then my personal opinion is not to use 464xlat at all. 464xlat is already little better than IPv4 over carrier pigeon, and if you want high quality, you're better off using one of the higher-quality mechanisms being worked on in softwires. Cheers, Lorenzo --e89a8f839cbdb08f0d04bd8757fa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Apr 13, 2012 at 12:19, Cameron Byrne <cb.list6@gmail.com= > wrote:
We suggest that CLAT proxy DNS to m= ake the DNS transaction native IPv6=A0from the CLAT and avoid stateful tran= slation of every DNS query on the
PLAT.

I think this is not controversial, be= cause you don't need to define any new behaviour. You simply run a DNS = forwarder on the CLAT. Was there objection to stating this as being optiona= l but recommended?

Prefix handing --http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-01#section-= 6.5

Multiple methods are defined, including doing NAT446 on the CLAT so
that all LAN IPv4 flows are NAT44 to a single IPv4 address, then that
single IPv4 address is mapped to single IPv6 source address.

Is there something specific that needs to be added or deleted from the
current draft or change log?

I think the &q= uot;take ownership of a /96" text was controversial. I believe the obj= ection is as follows:

- If you claim a /96 on the = link, you have to ensure that DAD fails for addresses in that /96. This=A0b= ehaviour is not specified anywhere, and the operational implications (e.g.,= the possibility of other hosts giving up because every address they try is= taken) are not considered anywhere.
-=A0The reason why this document is in v6ops is that it does not defin= e any new behaviour, but only how to cobble together existing behaviour to = achieve a useful result.
- v6ops cannot define new behaviour; tha= t belongs elsewhere

So if you want to keep this in the draft, you have to s= pecify how to do it (probably in 6man) and possibly write up the operationa= l implications (here in v6ops).

And of course, you= also have to implement it, and it's much more complex to implement tha= n simply using a /128.

I think that if you're in a hurry to get this docum= ent through the process, you should just remove the /112 mode from the draf= t completely. I don't see it as being particularly useful either. What = can you do with the /112 mode that you can't do with a NAT44 on the CLA= T? If the use case is a mobile device, then they implement NAT44 anyway.

If you want to provide "better quality" IPv4 = access to nodes behind the CLAT, then my personal opinion is not to use 464= xlat at all. 464xlat is already little better than IPv4 over carrier pigeon= , and if you want high quality, you're better off using one of the high= er-quality mechanisms being worked on in softwires.
=A0
Cheers,
Lorenzo
--e89a8f839cbdb08f0d04bd8757fa-- From ichiroumakino@gmail.com Fri Apr 13 00:42:23 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC4B21F8699 for ; Fri, 13 Apr 2012 00:42:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.771 X-Spam-Level: X-Spam-Status: No, score=-2.771 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jqTH0R+21G2N for ; Fri, 13 Apr 2012 00:42:22 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 04BB321F845F for ; Fri, 13 Apr 2012 00:42:21 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so1874343wgb.13 for ; Fri, 13 Apr 2012 00:42:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=JAe7PGjDzmuFwckpIFwgeF26a4wn1nlXGUVNewPSm3s=; b=e96qgdBzV7gAMzyXG48ErKPes7SajBnENAhSw9GdwuEmdYifZUxtHhTzjunuz9FrMD 6P04UTceLeZFhngzriw4E2V9YNzVbDeQl71zRoSMOup3iXUx/ZBQvh1NdlYSxRNEsXiP 3uCpu8BpMiagUv85k14rLg6F6Dg+edl/B0Bt6dWXzzFxnhKpqvBaAH0Z+34rBKtd3gT/ OV+OdLWaJALEPpsEwhPM0wMq+L0EwambIwfcuw1uK0m41G4x747ZvO+1Jb0EALb1r/UR 7ayrN6Wh6Fkl8j3k+rRdJmvBdyN33BsmfCEifDf5pXixZRlGTlKDuKiDhtFHuPBOntD0 r/mg== Received: by 10.216.131.30 with SMTP id l30mr315483wei.111.1334302941194; Fri, 13 Apr 2012 00:42:21 -0700 (PDT) Received: from dhcp-10-61-97-199.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id w10sm5156041wiy.3.2012.04.13.00.42.19 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 13 Apr 2012 00:42:20 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Fri, 13 Apr 2012 09:42:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Lorenzo Colitti X-Mailer: Apple Mail (2.1257) Cc: IPv6 Ops WG Subject: Re: [v6ops] 464XLAT from informational to BCP -- Document Change Manifest X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 07:42:23 -0000 > - If you claim a /96 on the link, you have to ensure that DAD fails = for addresses in that /96. This behaviour is not specified anywhere, and = the operational implications (e.g., the possibility of other hosts = giving up because every address they try is taken) are not considered = anywhere. > - The reason why this document is in v6ops is that it does not define = any new behaviour, but only how to cobble together existing behaviour to = achieve a useful result. > - v6ops cannot define new behaviour; that belongs elsewhere >=20 > So if you want to keep this in the draft, you have to specify how to = do it (probably in 6man) and possibly write up the operational = implications (here in v6ops). >=20 > And of course, you also have to implement it, and it's much more = complex to implement than simply using a /128. >=20 > I think that if you're in a hurry to get this document through the = process, you should just remove the /112 mode from the draft completely. = I don't see it as being particularly useful either. What can you do with = the /112 mode that you can't do with a NAT44 on the CLAT? If the use = case is a mobile device, then they implement NAT44 anyway. >=20 > If you want to provide "better quality" IPv4 access to nodes behind = the CLAT, then my personal opinion is not to use 464xlat at all. 464xlat = is already little better than IPv4 over carrier pigeon, and if you want = high quality, you're better off using one of the higher-quality = mechanisms being worked on in softwires. I think you could define two modes here. 1) use a single IPv6 address for the translation 2) reserve a full /64 for the purpose of translation cheers, Ole= From sarikaya2012@gmail.com Fri Apr 13 08:38:50 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0071A21F87CB for ; Fri, 13 Apr 2012 08:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.105 X-Spam-Level: X-Spam-Status: No, score=-3.105 tagged_above=-999 required=5 tests=[AWL=-0.406, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1KhSPsJypx9N for ; Fri, 13 Apr 2012 08:38: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 61E1B21F86A1 for ; Fri, 13 Apr 2012 08:38:49 -0700 (PDT) Received: by iazz13 with SMTP id z13so5294807iaz.31 for ; Fri, 13 Apr 2012 08:38:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=OXlJ9KldyLaNtQF8UpHXDVOOO04HO1DG0hj8PnEBL5I=; b=AGqb1HTKC7tjdtSbbOD+r2sQht37XRUM9g1SjfweeSOa7tvsgO8TFckOxHn96dJWtZ lIyJmnk2RhiOmTqtFhewbYkKc8jmkdUpYAPWegL3V07zfs1fqW8XQXScTPEojJ3+/2pc wYTlzDgDM3ADNphQ/yy1D2Tb24U/snwK7uKGUDjzleqxhecNMV6GDSLi10nuqG5kyrxc zRL4CNOIBWgDgJSga5IlaAtMPVHInK7NBYxjQHCDqME+AxmlUczymip/eK5Nxe/oyg1r zN2dwSbbLn+FsVBuUhCbLjpSLqiEJC+yqo2/TmqB4gD3q4qiHPGkC3FoZeGRF0JrcRlr QnyA== MIME-Version: 1.0 Received: by 10.43.52.74 with SMTP id vl10mr1467537icb.55.1334331528922; Fri, 13 Apr 2012 08:38:48 -0700 (PDT) Received: by 10.231.194.73 with HTTP; Fri, 13 Apr 2012 08:38:48 -0700 (PDT) In-Reply-To: References: Date: Fri, 13 Apr 2012 10:38:48 -0500 Message-ID: From: Behcet Sarikaya To: =?ISO-8859-1?Q?Ole_Tr=F8an?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Ops WG Subject: Re: [v6ops] 464XLAT from informational to BCP -- Document Change Manifest X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 15:38:50 -0000 On Fri, Apr 13, 2012 at 2:42 AM, Ole Tr=F8an wrote: >> - If you claim a /96 on the link, you have to ensure that DAD fails for = addresses in that /96. This behaviour is not specified anywhere, and the op= erational implications (e.g., the possibility of other hosts giving up beca= use every address they try is taken) are not considered anywhere. >> - The reason why this document is in v6ops is that it does not define an= y new behaviour, but only how to cobble together existing behaviour to achi= eve a useful result. >> - v6ops cannot define new behaviour; that belongs elsewhere >> >> So if you want to keep this in the draft, you have to specify how to do = it (probably in 6man) and possibly write up the operational implications (h= ere in v6ops). >> >> And of course, you also have to implement it, and it's much more complex= to implement than simply using a /128. >> >> I think that if you're in a hurry to get this document through the proce= ss, you should just remove the /112 mode from the draft completely. I don't= see it as being particularly useful either. What can you do with the /112 = mode that you can't do with a NAT44 on the CLAT? If the use case is a mobil= e device, then they implement NAT44 anyway. >> >> If you want to provide "better quality" IPv4 access to nodes behind the = CLAT, then my personal opinion is not to use 464xlat at all. 464xlat is alr= eady little better than IPv4 over carrier pigeon, and if you want high qual= ity, you're better off using one of the higher-quality mechanisms being wor= ked on in softwires. > > I think you could define two modes here. > 1) use a single IPv6 address for the translation > 2) reserve a full /64 for the purpose of translation This is actually what RFC 6052 is also recommending: When the prefix is 64 bits long, the IPv4 address is encoded in positions 72 to 103. 6052 also allows the well-known prefix which is /96 but no one is supportin= g it. Behcet From despres.remi@laposte.net Fri Apr 13 08:53:28 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0965C21F87E7 for ; Fri, 13 Apr 2012 08:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[AWL=-0.197, 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 Ljq+si7W3JfV for ; Fri, 13 Apr 2012 08:53:26 -0700 (PDT) Received: from smtpout.laposte.net (smtpout1.laposte.net [193.253.67.226]) by ietfa.amsl.com (Postfix) with ESMTP id 768BD21F87E5 for ; Fri, 13 Apr 2012 08:53:24 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8502-out with ME id xTtN1i00E37Y3f403TtNtw; Fri, 13 Apr 2012 17:53:23 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Fri, 13 Apr 2012 17:53:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Cameron Byrne X-Mailer: Apple Mail (2.1084) Cc: IPv6 Ops WG Subject: Re: [v6ops] 464XLAT from informational to BCP -- Document Change Manifest X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 15:53:28 -0000 Le 2012-04-13 =E0 03:42, Cameron Byrne a =E9crit : > Hi all, >=20 > We are preparing to publish the next revision of 464XLAT as BCP >=20 > 2 questions: >=20 > 1. BCP OK as Fred suggested? Or informational? (1) This draft is IMHO quite useful. Reason is that it is AFAIK the only one so far to deal with: v4-oly-APP / v6-only network / Stateful translator / v4-only Internet / = v4 server (2) Keeping it Informational (and without RFC2119 vocabulary) is IMHO = much better. Reasons are:=20 a) Some requirements that amount to new specifications would not be = acceptable in a BCP. (The need to exclude some prefix on the LAN side, = and the need for a DHCPv6 option to provide a 464XLAT prefix, are AFAIK = new specifications) b) No information needs to be lost just because the RFC is Informational c) Quick publication is less controversial (no need to clarify the = relationship with the BIH of RFC6535) d) Convergence of this work and that of Softwire, at least on address = formats, might permit to complete and improve the design (see, for = example, (3) below) (3) =20 If CLAT addresses would have the format proposed for 4rd-u in Softwire: - each CLAT would need nothing more than is delegated /64 or shorter=20 - v4-originated addresses would be deterministically distinguishable = from native IPv6 addresses, both in CLAT themselves and in middle boxes NB: this isn't to say that Softwire will necessarily publish the 4rd-u = specification (the subject is still open). But it is to suggest that = future coordination might be fruitful. Regards, RD >=20 > 2. Any other changes aside from the ones listed below? >=20 > Thanks! >=20 > CB >=20 > PS: Easy button to the draft -> > http://tools.ietf.org/html/draft-ietf-v6ops-464xlat > PPS: Hopefully useful info on how you too can try 464XLAT, as well as > test results, https://sites.google.com/site/tmoipv6/464xlat >=20 > On Wed, Mar 28, 2012 at 3:01 PM, Cameron Byrne = wrote: >> Folks, >>=20 >> For the sake of clarity, what i understand from Fred's email, and has >> been supported by 3 people so far, is that there is desire to move >> from informational to BCP and some changes are required along the = way. >>=20 >> I believe these specific changes are required from my reading of >> Fred's mail, let me know if something is missing: >>=20 >> 1. Change document category from informational to BCP >>=20 >> 2. Re-insert RFC 2119 keywords >>=20 >> 3. Replace all text in section in 6.1 with this one sentence "The = XLAT >> Prefix format used on the CLAT for RFC6145 translation is defined in >> Section 2.2 of [RFC6052]. " Also, remove all references to /96 in >> section 6.5. Update diagram in 6.2 to remove /96. >>=20 >> 4. The DNS proxy section will add a reference to RFC5625, such as >> adding the sentence to the beginning of section 6.4 stating "The CLAT >> SHOULD implement a DNS proxy as defined in RFC 5625." >>=20 >> Am I missing something? >>=20 >> Are these the agreeable terms of moving forward with 464XLAT as a BCP >> instead of informational? >>=20 >> Thanks for the feedback and helping to clarify the path forward >>=20 >> Cameron > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From rbonica@juniper.net Fri Apr 13 09:20:04 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B242421F861C for ; Fri, 13 Apr 2012 09:20:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.525 X-Spam-Level: X-Spam-Status: No, score=-106.525 tagged_above=-999 required=5 tests=[AWL=0.075, 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 GhlhKP2HNBEv for ; Fri, 13 Apr 2012 09:20:04 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id D899D21F861A for ; Fri, 13 Apr 2012 09:19:59 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKT4hSLRflOS6bBRSVGP7Gt5n6OPUFgJZC@postini.com; Fri, 13 Apr 2012 09:20:03 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 13 Apr 2012 09:18:38 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Fri, 13 Apr 2012 12:18:37 -0400 From: Ronald Bonica To: "draft-ietf-v6ops-ipv6-discard-prefix@tools.ietf.org" , "v6ops@ietf.org" Date: Fri, 13 Apr 2012 12:18:35 -0400 Thread-Topic: Mail regarding draft-ietf-v6ops-ipv6-discard-prefix Thread-Index: Ac0ZkRPFwlO4pVtRRhea9fjdBDJC5Q== Message-ID: <13205C286662DE4387D9AF3AC30EF456D76A059DC2@EMBX01-WF.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [v6ops] Mail regarding draft-ietf-v6ops-ipv6-discard-prefix X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 16:20:04 -0000 Folks, As I recall, you came to an agreement with Ralph and we are waiting for a n= ew version. Do I have that right? Michelle is cleaning up the registries, so those DISCUSSes should go away s= oon. -------------------------- Ron Bonica vcard: www.bonica.org/ron/ronbonica.vcf From rbonica@juniper.net Fri Apr 13 09:28:44 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C881421F87D2 for ; Fri, 13 Apr 2012 09:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.231 X-Spam-Level: X-Spam-Status: No, score=-106.231 tagged_above=-999 required=5 tests=[AWL=-0.232, 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 GXtDKcN8JxrX for ; Fri, 13 Apr 2012 09:28:44 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id 7536A21F867F for ; Fri, 13 Apr 2012 09:28:37 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKT4hUM1fK/lWBlnqOeePpJ+kYFGOvIwew@postini.com; Fri, 13 Apr 2012 09:28:43 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 13 Apr 2012 09:27:33 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Fri, 13 Apr 2012 12:27:32 -0400 From: Ronald Bonica To: "draft-ietf-v6ops-ipv6-discard-prefix@tools.ietf.org" , "v6ops@ietf.org" Date: Fri, 13 Apr 2012 12:27:31 -0400 Thread-Topic: Mail regarding draft-ietf-v6ops-ipv6-discard-prefix Thread-Index: Ac0ZkRPFwlO4pVtRRhea9fjdBDJC5QAAR4bw Message-ID: <13205C286662DE4387D9AF3AC30EF456D76A059DE8@EMBX01-WF.jnpr.net> References: <13205C286662DE4387D9AF3AC30EF456D76A059DC2@EMBX01-WF.jnpr.net> In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D76A059DC2@EMBX01-WF.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] Mail regarding draft-ietf-v6ops-ipv6-discard-prefix X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 16:28:44 -0000 Sorry, I meant to post this to v6ops-chairs, not v6ops. Apologies for the spam. Ron > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Ronald Bonica > Sent: Friday, April 13, 2012 12:19 PM > To: draft-ietf-v6ops-ipv6-discard-prefix@tools.ietf.org; v6ops@ietf.org > Subject: [v6ops] Mail regarding draft-ietf-v6ops-ipv6-discard-prefix >=20 > Folks, >=20 > As I recall, you came to an agreement with Ralph and we are waiting for > a new version. Do I have that right? >=20 > Michelle is cleaning up the registries, so those DISCUSSes should go > away soon. >=20 > -------------------------- > Ron Bonica > vcard: www.bonica.org/ron/ronbonica.vcf >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From warren@kumari.net Sat Apr 14 22:55:22 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0FDB21F8739 for ; Sat, 14 Apr 2012 22:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.105 X-Spam-Level: X-Spam-Status: No, score=-106.105 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, 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 BEJT9g0TgJtZ for ; Sat, 14 Apr 2012 22:55:21 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 42C5D21F8710 for ; Sat, 14 Apr 2012 22:55:21 -0700 (PDT) Received: from [192.168.179.109] (unknown [74.125.122.49]) by vimes.kumari.net (Postfix) with ESMTPSA id 266721B40373; Sun, 15 Apr 2012 01:55:20 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Warren Kumari In-Reply-To: Date: Sat, 14 Apr 2012 22:42:42 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <90B7509D-6A87-479B-A999-59A2EF33BA7F@kumari.net> References: <43F84362-C062-401E-97D5-C8DB27CE0E1F@cisco.com> To: Ramji Vaithianathan (rvaithia) X-Mailer: Apple Mail (2.1257) Cc: IPv6 Operations , v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-ivi-icmp-address WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2012 05:55:22 -0000 On Apr 12, 2012, at 3:25 AM, Ramji Vaithianathan (rvaithia) wrote: > Regarding Option 1, the draft talks about advertising the special > prefix, so routers can do an uRPF check to ensure that the pkts have a > reverse path to the NAT64 translator which supports this prefix. Yes, you you say this like it's a feature, I via it as a bug=85 In a network that peers with a large number of folk I'll see this on a = large number of interfaces[0], and so I'll accept packets on all those = interfaces -- I understand that that is (from your viewpoint) the Right = Thing to do, but you completely seem to be ignoring the DoS problem=85 = The whole point of uRPF is to prevent solo spoofing addresses -- you are = proposing a: defeating this protection, and b: providing a prefix = tailored for hiding in=85 I simply don't want to be accepting a whole heap-o-packets that I cannot = trust / do anything with, so my only option would be to simply filter = them=85=20 W [0]: Assuming this got traction... >=20 > Thanks, >=20 > Ramji >=20 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Warren Kumari > Sent: Thursday, April 12, 2012 6:22 AM > To: Fred Baker (fred) > Cc: IPv6 Operations; v6ops-chairs@tools.ietf.org; Ron Bonica > Subject: Re: [v6ops] draft-ietf-v6ops-ivi-icmp-address WGLC >=20 >=20 > On Apr 1, 2012, at 2:01 PM, Fred Baker wrote: >=20 >> This is to initiate a two week working group last call of > draft-ietf-v6ops-ivi-icmp-address. >=20 > Phew, just before the cut-off.... >=20 >=20 >> Please read it now. If you find nits (spelling errors, minor = suggested > wording changes, etc), comment to the authors; if you find greater > issues, such as disagreeing with a statement or finding additional > issues that need to be addressed, please post your comments to the = list. >=20 > Sure -- I (still) have some serious concerns about this draft... >=20 > It is basically proposing something that looks kinda like source = address > anycast ;-) >=20 > I cannot really understand what an operator is expected to do here. As = I > see it, there are two options: >=20 > Option 1: Simply permit all packets from this address block into the > network, with no regard for uRPF, etc. > This options seems like an obvious fail from a DoS / DDoS standpoint = -- > I'll have no real way to track these back, know which are legitimate, > etc and so it will become a standard DoS vector...=20 >=20 > This leaves me with option 2... >=20 > Option 2: Simply filter all packets from $MAGIC_BLOCK and drop them on > the floor. > Now I am back to where we are currently -- might as well just use > RFC1918 space... >=20 >=20 >=20 >>=20 >> We are looking specifically for comments on the importance of the > document as well as its content. If you have read the document and > believe it to be of operational utility, that is also an important > comment to make. >=20 > I believe it to either be of no operational utility (I'll simply = filter > this block) or actual harm (folk will allow it in, and then it will be > used for DoS... >=20 > Sorry, > W >=20 >=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From fred@cisco.com Sun Apr 15 13:54:44 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF30821F8867 for ; Sun, 15 Apr 2012 13:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.71 X-Spam-Level: X-Spam-Status: No, score=-110.71 tagged_above=-999 required=5 tests=[AWL=-0.112, 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 ZEf5FKaAcVrH for ; Sun, 15 Apr 2012 13:54:44 -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 5FA7221F8862 for ; Sun, 15 Apr 2012 13:54:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1605; q=dns/txt; s=iport; t=1334523284; x=1335732884; h=from:subject:date:message-id:cc:to:mime-version; bh=eheFHtmo2jEhHQlJzDISz6zGLq7MAf1y9xX723VR5i8=; b=j4M47CGjptPucPyRCmHWLxXJBHDFcqw5I/WutdO0JqJh6GB8T7d3ZUoh TPU1y8JiJMkj3jZEcMv6d3L+rZ7rW1/cfsyODDkFoPEfxkRNY2OdAneog Ah6wrsClfLaAEA/2PBSPiUDX6iA9LAoYATmiR2liNfafbHV2piVgpQIbk c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAAM1i0+rRDoJ/2dsb2JhbABEgkayRYEHggAiAWYeAYFUh2uYdp5ojiWCQWMEiFqNE4VyiFqBaYMH X-IronPort-AV: E=Sophos;i="4.75,425,1330905600"; d="scan'208,217";a="40663091" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 15 Apr 2012 20:54:43 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q3FKsg6o025592; Sun, 15 Apr 2012 20:54:42 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Sun, 15 Apr 2012 13:54:43 -0700 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Sun, 15 Apr 2012 13:54:43 -0700 From: Fred Baker Date: Sun, 15 Apr 2012 13:54:00 -0700 Message-Id: <2FEFE40E-25F2-4D02-A608-0CADCBBAAE9C@cisco.com> To: v6ops@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Content-Type: multipart/alternative; boundary=Apple-Mail-111--266244770 Cc: v6ops-chairs@tools.ietf.org, Ron Bonica Subject: [v6ops] draft-ietf-v6ops-6204bis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2012 20:54:45 -0000 --Apple-Mail-111--266244770 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This is to initiate a ONE week working group last call of = draft-ietf-v6ops-6204bis, seeing as we just completed a two week event = and finished some comments at IETF 83. Please read it now, or at least = the diff from the previous version. If you find nits (spelling errors, = minor suggested wording changes, etc), comment to the authors; if you = find greater issues, such as disagreeing with a statement or finding = additional issues that need to be addressed, please post your comments = to the list.= --Apple-Mail-111--266244770 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
This is to initiate a ONE week working group last call of draft-ietf-v6ops-6204bis, seeing as we just completed a two week event and finished some comments at IETF 83. Please read it now, or at least the diff from the previous version. If you find nits (spelling errors, minor suggested wording changes, etc), comment to the authors; if you find greater issues, such as disagreeing with a statement or finding additional issues that need to be addressed, please post your comments to the list.
--Apple-Mail-111--266244770-- From despres.remi@laposte.net Mon Apr 16 01:09:50 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F82E21F86EE for ; Mon, 16 Apr 2012 01:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.958 X-Spam-Level: X-Spam-Status: No, score=-1.958 tagged_above=-999 required=5 tests=[AWL=-0.073, BAYES_40=-0.185, GB_I_LETTER=-2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0yOPL2ScXqLC for ; Mon, 16 Apr 2012 01:09:49 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 4287D21F86FC for ; Mon, 16 Apr 2012 01:09:47 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 01240940141; Mon, 16 Apr 2012 10:09:34 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-7--225711682 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Mon, 16 Apr 2012 10:09:33 +0200 Message-Id: <22BD6607-5DEC-48F3-B2E5-DCEECC9EF643@laposte.net> References: <7E1BD96D-E7EC-4C78-B382-66F0F694DAA4@laposte.net> <1825062D-D4EB-4310-A2BA-8B8F3870B9B4@laposte.net> To: Cameron Byrne X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] A way forward for 464XLAT - using BIH X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 08:09:50 -0000 --Apple-Mail-7--225711682 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 2012-04-03 =E0 16:15, Cameron Byrne : > On Apr 3, 2012 12:32 AM, "R=E9mi Despr=E9s" = wrote: >=20 ... > > BIH "recommends" to avoid double translation. > > This AFAIK permits it if good reasons are found. > > >=20 > Yes, it is an all capital letter recommendation.=20 >=20 - RFC 6535 says "Use of BIH together with a NAT64 is NOT RECOMMENDED". - RFC 2119 says that "NOT RECOMMENDED" means that "there may exist valid = reasons in particular circumstances when the particular behavior is = acceptable or even useful". - 464XLAT-like scenarios are IMHO "valid reasons in particular = circumstances" that justify using "BIH together with a NAT44"=20 > As you likely well know, ipv6 transition is an ecosystem transition = and recommendations like the one in BIH become a lightening rod for = confusion. >=20 Having not followed the Behave debate on BIH, I just read the resulting = RFC with an open mind. So far, I don't know anything that justifies this negative appreciation.=20= > We can leave it at that. >=20 IMHO, BIH is not only valuable for its documented v4-only-to-v6-only use = cases, but also for use cases targeted by 464XLAT. =20 For such scenarios, it looks sufficient that: (a) RFC 6535 is used in its socket-layer variant (ignoring the network = layer variant, as already recommended in sec. 4) (b) In hosts whose only interface is IPv6, all IPv4 packets are subject = to protocol translation (as already implicitly suggested in sec 4.5) (c) IPv6 addresses that, for (b), need to be used as substitute of = public IPv4 addresses are synthesized according to RFC 6052 (the = available RFC for this). Thus, a BIH host works in face of an ordinary NAT64 with the same e2e = effect as that of a CLAT in face of a PLAT. Anything missed? > > > That said, 464XLAT authors have found rfc6145 to be the best fit = for > > > IPv4->IPv6 translation, including support for the function in a = more > > > generic node such as a router (home gateway CPE, mobile phone as a > > > host, mobile phone as a wifi router, ...) >=20 (*) A BIH host that includes a NAT44 can be an IPv4 router on its LAN = side, without needing any new specification for this. ... > If I read section 2.3 correctly of bih, it requires all sessions be = created by enr. >=20 (**) - Section 2.3 of RFC 6535 says "if a DNS A record reply contains = non-excluded real IPv4 addresses, the ENR MUST NOT synthesize IPv4 = addresses". ENR doesn't apply to public IPv4 addresses. - With RFC 6052 used for 1:1 mappings between public IPv4 address and an = IPv6 addresses, sessions are possible with IPv4 referrals (neither DNS = nor ENR needed).=20 > In the network implementation of bih, bih cannot support ipv4 = communication that does not start with DNS because DNS triggers the enr. = So, bih on a router cannot facilitate for a client of the router a = Skype call since Skype signals ipv4 literals.=20 > The bih router (which does not exist) cannot create the enr triggered = session mappings with capturing DNS first. >=20 No problem with the socket-layer variant (see (a) above)=20 > > A host can also be also a router, in particular if it includes a = NAT44. > > I see nothing that prevents using it in this case. > > >=20 > I don't believe bih had this use case in scope. The diagrams and text = in bih make reference to a host, not a host / router. >=20 Discussed in (*) above > Trust me, if bih worked as you suggest, my life would be much easier. >=20 Unless I miss something, this can still be the case :-). > If bih officially worked with nat64 and did not require the enr mapper = so that it supported ipv4 literals in network mode, that would be great. >=20 Discussed in (**) above. > In fact, I pushed for both when bih was a draft in behave.=20 Maybe time has come to acknowledge that what was a "NOT RECOMMENDED" = (not a "MUST NOT") is in fact useful for the following use case: (IPv4-only appli or NAT44) (BIH with RFC6146) v IPv6-only network v (stateful NAT64) v IPv4 Internet v (IPv4 server) Regards, RD --Apple-Mail-7--225711682 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

On Apr 3, 2012 12:32 AM, "R=E9mi Despr=E9s" <despres.remi@laposte.net> = wrote:

...

> BIH "recommends" to avoid double translation.
> This AFAIK permits it if good reasons are found.
>

Yes, it is an all capital letter = recommendation. 

- RFC 6535 says "Use of BIH together with a NAT64 is = NOT RECOMMENDED".
- RFC = 2119 says that "NOT RECOMMENDED" means that "there may exist valid = reasons in particular circumstances when the particular behavior is = acceptable or even useful".

As you = likely well know, ipv6 transition is an ecosystem transition and = recommendations like the one in BIH become a lightening rod for = confusion.

Having not followed the Behave debate on = BIH, I just read the resulting RFC with an open mind.
So far, = I don't know anything that justifies this negative = appreciation. 

We can leave it at that.

IMHO, = BIH is not only valuable for its documented v4-only-to-v6-only use = cases, but also for use cases targeted by 464XLAT.  
For = such scenarios, it looks sufficient that:
(a) RFC 6535 is used = in its socket-layer variant (ignoring the network layer = variant, as already recommended in sec. 4)
(b) In hosts = whose only interface is IPv6, all IPv4 packets are subject = to protocol translation (as already implicitly suggested in sec = 4.5)
(c) IPv6 addresses that, for (b), need to be used as = substitute of public IPv4 addresses are synthesized according = to RFC 6052 (the available RFC for = this).

Thus, a BIH host works in face = of an ordinary NAT64 with the same e2e effect as that of = a CLAT in face of a PLAT.

Anything = missed?

> > That = said, 464XLAT authors have found rfc6145 to be the best fit for
> > IPv4->IPv6 translation, including support for the function = in a more
> > generic node such as a router (home gateway CPE, mobile phone = as a
> > host, mobile phone as a wifi router, = ...)

(*) A BIH host that includes a NAT44 = can be an IPv4 router on its LAN side, without needing any new = specification for this.

...

If I read section 2.3 correctly of bih, it requires all = sessions be created by enr.

(**)
- = Section 2.3 of RFC 6535 says "if a DNS A record reply contains = non-excluded real IPv4 addresses, the ENR MUST NOT synthesize IPv4 = addresses". ENR doesn't apply to public IPv4 addresses.
- With = RFC 6052 used for 1:1 mappings between public IPv4 address and an IPv6 = addresses, sessions are possible with IPv4 referrals (neither DNS nor = ENR needed). 

In the network = implementation of bih, bih cannot support ipv4 communication that does = not start with DNS because DNS triggers the enr. So, bih on a router = cannot facilitate for a client of  the router a Skype call  = since Skype signals ipv4 literals.
The bih router (which does not exist) cannot create the enr triggered = session mappings with capturing DNS first.

No = problem with the socket-layer variant (see (a) = above) 

> A host can also be also a router, in particular if it includes a = NAT44.
> I see nothing that prevents using it in this case.
>

I don't believe bih had this use case in scope. The diagrams = and text in bih make reference to a host, not a host / router. =

Discussed in (*) above

Trust me, if bih worked as you suggest, my life would = be much easier.

Unless I miss something, this can still = be the case :-).

If bih officially = worked with nat64 and did not require the enr mapper so that it = supported ipv4 literals in network mode, that would be great. =

Discussed in (**) = above.

In fact, I = pushed for both when bih was a draft in behave.

Maybe time = has come to acknowledge that what was a "NOT RECOMMENDED" (not = a "MUST NOT") is in fact useful for
the following use = case:

 (IPv4-only appli or = NAT44)
 (BIH with RFC6146)
    = v
 IPv6-only network
    = v
 (stateful NAT64)
    = v
  IPv4 Internet
    = v
 (IPv4 = server)


Regards,
RD


= --Apple-Mail-7--225711682-- From lorenzo@google.com Mon Apr 16 01:22:37 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD59321F8690 for ; Mon, 16 Apr 2012 01:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.766 X-Spam-Level: X-Spam-Status: No, score=-102.766 tagged_above=-999 required=5 tests=[AWL=-0.090, 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 4ZzlDYGvHjXe for ; Mon, 16 Apr 2012 01:22:36 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id ABD7621F8687 for ; Mon, 16 Apr 2012 01:22:36 -0700 (PDT) Received: by obbwd20 with SMTP id wd20so2193404obb.31 for ; Mon, 16 Apr 2012 01:22:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=9gjlTHsrj3NdcLeNgdoY+a12ita4+fm5HIsQjng6SAA=; b=DSMg9+NAxhElBDjUA5q07yy0uOl+wGl8831eDF0NagrHYqCGgrRgyBglOlDJxicDLg E/PoB5SCrqC1jm1BuVgMTJf5CCQ5s1IOSerUufE3nXnjFnK+BgrjQnqS0UQD4HpXOPtO vbfInRaEACemP0HpMStwqLF7vHXjBxfuObGTBvq8SB5m8PG5tR4YrrmIUi404vPBQTcp kTDiitlWZNfIz/gSbTTnoBMD/MI61pah5/ebWXpJCHRLUotW/RZz7P4oaHCuSljkhJMH LzpCwqHE5YXHdqAouobp+HwwqjZ+f84VaYXj2QIqdISCZ9sHOVUVkrXLjY3GnZPTjzUR bqEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=9gjlTHsrj3NdcLeNgdoY+a12ita4+fm5HIsQjng6SAA=; b=jcUeIEq0pWXjFHHYwRXpq6Yw5Su3MDf37wH26Qug53JmUBouxemlwRQrCQUQTvJ00D 1DoxasHTEMbL8TgqNBJ+bcO1gFtZRb58pCDmOET4Fl9G1nzaAVF6KcKgAfXrpltHTte7 cF09t7gc1Rp7L5QGXsFx8snkP143k5lb/1vOPHMEQ6O1KmS5GK0sythewMvzVsljym9X kqoTOlLniQsKi+xRMKzHP6UUYCViHFOLUaJzgYBaR7j3krFcl6Y0zH4p9eWYkmJbg8Jc FcYnxGeoPw9Q1ls2OcVWz2b6jx2WtGljaahaDUIOCBWgd0uxAT7akIPD+eEU3fp4Rl/3 JwTA== Received: by 10.182.177.101 with SMTP id cp5mr14675451obc.38.1334564556059; Mon, 16 Apr 2012 01:22:36 -0700 (PDT) Received: by 10.182.177.101 with SMTP id cp5mr14675434obc.38.1334564555870; Mon, 16 Apr 2012 01:22:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.220.3 with HTTP; Mon, 16 Apr 2012 01:22:15 -0700 (PDT) In-Reply-To: <22BD6607-5DEC-48F3-B2E5-DCEECC9EF643@laposte.net> References: <7E1BD96D-E7EC-4C78-B382-66F0F694DAA4@laposte.net> <1825062D-D4EB-4310-A2BA-8B8F3870B9B4@laposte.net> <22BD6607-5DEC-48F3-B2E5-DCEECC9EF643@laposte.net> From: Lorenzo Colitti Date: Mon, 16 Apr 2012 17:22:15 +0900 Message-ID: To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=e89a8f83a51348504a04bdc78603 X-System-Of-Record: true X-Gm-Message-State: ALoCoQm4b9KdEtrZF40Xu/Iq9thVToUOSSLZKsLYZXbaYez/0a/UJGHblt08tThsC8IVhC0VwrOK10ByWVL3DwCYuIn4NMvjgciCh2474Roo15k45wFe1c1Pyu+laCL50rmuLL7O22/t Cc: v6ops WG Subject: Re: [v6ops] A way forward for 464XLAT - using BIH X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 08:22:37 -0000 --e89a8f83a51348504a04bdc78603 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Apr 16, 2012 at 17:09, R=E9mi Despr=E9s w= rote: > IMHO, BIH is not only valuable for its documented v4-only-to-v6-only use > cases, but also for use cases targeted by 464XLAT. > For such scenarios, it looks sufficient that: > (a) RFC 6535 is used in its socket-layer variant (ignoring the network > layer variant, as already recommended in sec. 4) > (b) In hosts whose only interface is IPv6, all IPv4 packets are subject > to protocol translation (as already implicitly suggested in sec 4.5) > (c) IPv6 addresses that, for (b), need to be used as substitute of public > IPv4 addresses are synthesized according to RFC 6052 (the available RFC f= or > this). > > Thus, a BIH host works in face of an ordinary NAT64 with the same e2e > effect as that of a CLAT in face of a PLAT. > Are you saying that 464xlat can be seen as a particular configuration of BIH (RFC 6535) in addition of as a particular configuration of RFC 6145 and RFC 6146? If so, then that's fine. Since the 464xlat draft defines no new behaviour but only how to combine existing technologies to achieve a particular result, the draft can simply say something along the lines of: It may be noted that this could also be seen as a particular configuration of [RFC 6535] used in its socket-layer variant as well as a particular configuration of [RFC 6145] and [RFC 6146]. The 464xlat draft should still exist though (perhaps as a BCP as per Fred's suggestion), to describe the actual scenario, how to configure it, and so on. --e89a8f83a51348504a04bdc78603 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Apr 16, 2012 at 17:09, R=E9mi Despr=E9s = <despres.r= emi@laposte.net> wrote:
IMHO, BIH is not only valuabl= e for its documented v4-only-to-v6-only use cases, but also for use cases t= argeted by 464XLAT. =A0
For such scenarios, it looks s= ufficient that:
(a) RFC 6535 is used in its socket-layer variant=A0(ignoring=A0the net= work layer variant, as already recommended in sec. 4)
(b)=A0In ho= sts whose only interface is IPv6, all=A0IPv4 packets are subject to=A0proto= col translation (as already implicitly suggested in sec 4.5)
(c)=A0IPv6 addresses that, for (b), need to be used as substitute of p= ublic IPv4 addresses are synthesized according to=A0RFC 6052 (the available= RFC for this).

Thus,=A0a BIH host works=A0in face= of an ordinary=A0NAT64 with the same e2e effect as that of a=A0CLAT in fac= e of a PLAT.

Are you saying that 464xlat ca= n be seen as a particular configuration of BIH (RFC 6535) in addition of as= a particular configuration of RFC 6145 and RFC 6146?

If so, then that's fine. Since the 464xlat draft defines no new be= haviour but only how to combine existing technologies to achieve a particul= ar result, the draft can simply say something along the lines of:

=A0 It may be noted that this could also be seen as a p= articular
=A0 configuration of [RFC 6535] used in its socket-laye= r variant
=A0 as well as a particular configuration of [RFC 6145]= and
=A0 [RFC 6146].

The 464xlat draft should stil= l exist though (perhaps as a BCP as per Fred's suggestion), to describe= the actual scenario, how to configure it, and so on.
--e89a8f83a51348504a04bdc78603-- From despres.remi@laposte.net Mon Apr 16 01:58:01 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 150DC21F86E3 for ; Mon, 16 Apr 2012 01:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.191 X-Spam-Level: X-Spam-Status: No, score=-2.191 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, 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 IlAbmLQFMRX5 for ; Mon, 16 Apr 2012 01:58:00 -0700 (PDT) Received: from smtpout.laposte.net (smtpout5.laposte.net [193.253.67.230]) by ietfa.amsl.com (Postfix) with ESMTP id E107A21F86A5 for ; Mon, 16 Apr 2012 01:57:59 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8509-out with ME id yYxx1i00337Y3f403YxxK7; Mon, 16 Apr 2012 10:57:57 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-8--222808489 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Mon, 16 Apr 2012 10:57:56 +0200 Message-Id: References: <7E1BD96D-E7EC-4C78-B382-66F0F694DAA4@laposte.net> <1825062D-D4EB-4310-A2BA-8B8F3870B9B4@laposte.net> <22BD6607-5DEC-48F3-B2E5-DCEECC9EF643@laposte.net> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] A way forward for 464XLAT - using BIH X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 08:58:01 -0000 --Apple-Mail-8--222808489 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-04-16 =E0 10:22, Lorenzo Colitti a =E9crit : > On Mon, Apr 16, 2012 at 17:09, R=E9mi Despr=E9s = wrote: > IMHO, BIH is not only valuable for its documented v4-only-to-v6-only = use cases, but also for use cases targeted by 464XLAT. =20 > For such scenarios, it looks sufficient that: > (a) RFC 6535 is used in its socket-layer variant (ignoring the network = layer variant, as already recommended in sec. 4) > (b) In hosts whose only interface is IPv6, all IPv4 packets are = subject to protocol translation (as already implicitly suggested in sec = 4.5) > (c) IPv6 addresses that, for (b), need to be used as substitute of = public IPv4 addresses are synthesized according to RFC 6052 (the = available RFC for this). >=20 > Thus, a BIH host works in face of an ordinary NAT64 with the same e2e = effect as that of a CLAT in face of a PLAT. >=20 > Are you saying that 464xlat can be seen as a particular configuration = of BIH (RFC 6535) in addition of as a particular configuration of RFC = 6145 and RFC 6146? The point is that RFC 6535 and RFC6052 are sufficient. The only (very minor problem) is that RFC 6535 doesn't recommend what = should better be recommended for operators that want: - IPv6-only network operation - Support of IPv4-only applications - Possible use of "deep packet inspection solutions like 3GPP = standardized Policy and Charging Control (PCC)" > If so, then that's fine. Since the 464xlat draft defines no new = behaviour but only how to combine existing technologies to achieve a = particular result, the draft can simply say something along the lines = of: >=20 > It may be noted that this could also be seen as a particular > configuration of [RFC 6535] used in its socket-layer variant > as well as a particular configuration of [RFC 6145] and > [RFC 6146]. >=20 > The 464xlat draft should still exist though (perhaps as a BCP as per = Fred's suggestion), to describe the actual scenario, how to configure = it, and so on. The best approach IMHO would be a BCP just explaining that BIH, used = with RFC6052 for v4-v6 address translation, is now recommended for = IPv4-only-application support via networks supporting stateful NAT64s = (without developing other ways to get a similar result). Whether such a use case should have its own name, such as 464XLAT, is an = open question AFAIAC but, provided the BCP is as simple as it can be, I = personally don't care. RD --Apple-Mail-8--222808489 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On Mon, Apr 16, 2012 at 17:09, = R=E9mi Despr=E9s <despres.remi@laposte.net><= /span> wrote:
IMHO, BIH is not only = valuable for its documented v4-only-to-v6-only use cases, but also for = use cases targeted by 464XLAT.  
For such = scenarios, it looks sufficient that:
(a) RFC 6535 is used in its socket-layer = variant (ignoring the network layer variant, as already = recommended in sec. 4)
(b) In hosts whose only interface = is IPv6, all IPv4 packets are subject to protocol translation = (as already implicitly suggested in sec 4.5)
(c) IPv6 addresses that, for (b), need to be used as = substitute of public IPv4 addresses are synthesized according = to RFC 6052 (the available RFC for = this).

Thus, a BIH host works in face = of an ordinary NAT64 with the same e2e effect as that of = a CLAT in face of a PLAT.

Are you saying that 464xlat = can be seen as a particular configuration of BIH (RFC 6535) in addition = of as a particular configuration of RFC 6145 and RFC = 6146?

The point is that RFC = 6535 and RFC6052 are sufficient.

The only (very = minor problem) is that RFC 6535 doesn't recommend what should better be = recommended for operators that want:
- IPv6-only network = operation
- Support of IPv4-only applications
- = Possible use of "deep packet inspection solutions like = 3GPP standardized Policy and Charging = Control (PCC)"


If so, then that's fine. Since the 464xlat draft defines no new = behaviour but only how to combine existing technologies to achieve a = particular result, the draft can simply say something along the lines = of:

  It may be noted that this could also be seen = as a particular
  configuration of [RFC 6535] used in its = socket-layer variant
  as well as a particular = configuration of [RFC 6145] and
  [RFC 6146].

The 464xlat draft = should still exist though (perhaps as a BCP as per Fred's suggestion), = to describe the actual scenario, how to configure it, and so = on.

The best approach IMHO would be a BCP just = explaining that BIH, used with RFC6052 for v4-v6 address translation, is = now recommended for IPv4-only-application support via networks = supporting stateful NAT64s (without developing other ways to get a = similar result).

Whether such a use case should = have its own name, such as 464XLAT, is an open question AFAIAC but, = provided the BCP is as simple as it can be, I personally don't = care.

RD


= --Apple-Mail-8--222808489-- From denghui02@gmail.com Mon Apr 16 02:07:32 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFA1B21F8713 for ; Mon, 16 Apr 2012 02:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.948 X-Spam-Level: X-Spam-Status: No, score=-103.948 tagged_above=-999 required=5 tests=[AWL=0.750, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 kxCpP4SomDJL for ; Mon, 16 Apr 2012 02:07:31 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9F0AE21F862B for ; Mon, 16 Apr 2012 02:07:31 -0700 (PDT) Received: by yenm5 with SMTP id m5so2616912yen.31 for ; Mon, 16 Apr 2012 02:07:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ACOKgd8gkXZ0fPfxa6RHO3D4V6lx0hPR7+I9wax4RQ4=; b=geZZk57aOHbP5svUooKqGa/k/DO30cB6KPdt7hZiayye9QbWAvpB+j8AzDDXjgHlOm K/2Qx+xs9CSghmJ0SdS1Cv7/fiO0WU7sYPX4eMpE31w/tgC+RSFU59vbbnQBdMBDHR68 AGJ1Ivoui/jSZnTDXOiSyxb/G++W9uN0iVfGulPNfd1bMKaZKz1KtzbaYzfqx9i9jHp7 3uew1AFe70FuauLNqtDdWoJ8arvs4pE9yG9XOK03SfxPk/uvHFp87qE8BSJziotw3/T6 K0x1Y9szNZ4gXOasgvY0dlu+VyPtKUgLLohrVaA5uHdV+eXrlonGpMjwve9Y9x3jz/xw eG0w== MIME-Version: 1.0 Received: by 10.101.6.8 with SMTP id j8mr2889709ani.10.1334567251170; Mon, 16 Apr 2012 02:07:31 -0700 (PDT) Received: by 10.146.20.14 with HTTP; Mon, 16 Apr 2012 02:07:31 -0700 (PDT) In-Reply-To: <22BD6607-5DEC-48F3-B2E5-DCEECC9EF643@laposte.net> References: <7E1BD96D-E7EC-4C78-B382-66F0F694DAA4@laposte.net> <1825062D-D4EB-4310-A2BA-8B8F3870B9B4@laposte.net> <22BD6607-5DEC-48F3-B2E5-DCEECC9EF643@laposte.net> Date: Mon, 16 Apr 2012 17:07:31 +0800 Message-ID: From: Hui Deng To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=001636c5bd73ef581404bdc826f2 Cc: v6ops WG Subject: Re: [v6ops] A way forward for 464XLAT - using BIH X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 09:07:32 -0000 --001636c5bd73ef581404bdc826f2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I don't know where this discussion comes from, but just clarify one thing, For socket based translation, it match with the host only For header translation, it is not necessraily always host, could be others. Does anybody know where is the definition of the host? -Hui 2012/4/16 R=E9mi Despr=E9s > 2012-04-03 =E0 16:15, Cameron Byrne : > > On Apr 3, 2012 12:32 AM, "R=E9mi Despr=E9s" wr= ote: > > ... > > > BIH "recommends" to avoid double translation. > > This AFAIK permits it if good reasons are found. > > > > Yes, it is an all capital letter recommendation. > > - RFC 6535 says "Use of BIH together with a NAT64 is NOT RECOMMENDED". > - RFC 2119 says that "NOT RECOMMENDED" means that "there may exist valid > reasons in particular circumstances when the particular behavior is > acceptable or even useful". > - 464XLAT-like scenarios are IMHO "valid reasons in particular > circumstances" that justify using "BIH together with a NAT44" > > As you likely well know, ipv6 transition is an ecosystem transition and > recommendations like the one in BIH become a lightening rod for confusion= . > > Having not followed the Behave debate on BIH, I just read the resulting > RFC with an open mind. > So far, I don't know anything that justifies this negative appreciation. > > We can leave it at that. > > IMHO, BIH is not only valuable for its documented v4-only-to-v6-only use > cases, but also for use cases targeted by 464XLAT. > For such scenarios, it looks sufficient that: > (a) RFC 6535 is used in its socket-layer variant (ignoring the network > layer variant, as already recommended in sec. 4) > (b) In hosts whose only interface is IPv6, all IPv4 packets are subject > to protocol translation (as already implicitly suggested in sec 4.5) > (c) IPv6 addresses that, for (b), need to be used as substitute of public > IPv4 addresses are synthesized according to RFC 6052 (the available RFC f= or > this). > > Thus, a BIH host works in face of an ordinary NAT64 with the same e2e > effect as that of a CLAT in face of a PLAT. > > Anything missed? > > > > That said, 464XLAT authors have found rfc6145 to be the best fit for > > > IPv4->IPv6 translation, including support for the function in a more > > > generic node such as a router (home gateway CPE, mobile phone as a > > > host, mobile phone as a wifi router, ...) > > (*) A BIH host that includes a NAT44 can be an IPv4 router on its LAN > side, without needing any new specification for this. > > ... > > If I read section 2.3 correctly of bih, it requires all sessions be > created by enr. > > (**) > - Section 2.3 of RFC 6535 says "if a DNS A record reply contains > non-excluded real IPv4 addresses, the ENR MUST NOT synthesize IPv4 > addresses". ENR doesn't apply to public IPv4 addresses. > - With RFC 6052 used for 1:1 mappings between public IPv4 address and an > IPv6 addresses, sessions are possible with IPv4 referrals (neither DNS no= r > ENR needed). > > In the network implementation of bih, bih cannot support ipv4 > communication that does not start with DNS because DNS triggers the enr. > So, bih on a router cannot facilitate for a client of the router a Skype > call since Skype signals ipv4 literals. > The bih router (which does not exist) cannot create the enr triggered > session mappings with capturing DNS first. > > No problem with the socket-layer variant (see (a) above) > > > A host can also be also a router, in particular if it includes a NAT44= . > > I see nothing that prevents using it in this case. > > > > I don't believe bih had this use case in scope. The diagrams and text in > bih make reference to a host, not a host / router. > > Discussed in (*) above > > Trust me, if bih worked as you suggest, my life would be much easier. > > Unless I miss something, this can still be the case :-). > > If bih officially worked with nat64 and did not require the enr mapper so > that it supported ipv4 literals in network mode, that would be great. > > Discussed in (**) above. > > In fact, I pushed for both when bih was a draft in behave. > > Maybe time has come to acknowledge that what was a "NOT RECOMMENDED" > (not a "MUST NOT") is in fact useful for > the following use case: > > (IPv4-only appli or NAT44) > (BIH with RFC6146) > v > IPv6-only network > v > (stateful NAT64) > v > IPv4 Internet > v > (IPv4 server) > > > Regards, > RD > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --001636c5bd73ef581404bdc826f2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I don't know where this discussion comes from, but just clarify on= e thing,
For socket based translation, it match with the host only
For header translation, it is not necessraily always host, could be ot= hers.
=A0
Does anybody know where is the definition of the host?
=A0
-Hui

2012/4/16 R=E9mi Despr=E9s <= ;despres.remi@laposte.net&g= t;
2012-04-03 =E0 16:15, Cameron Byrne :

On Apr 3, 2012 12:32 AM, "R=E9mi Despr=E9s" <despres.remi@laposte.net> wrote:

...

> BIH "recommends" to avoid double translation.
> Thi= s AFAIK permits it if good reasons are found.
>

Yes, it is an all capital letter recommendation.=A0

- RFC 6535 says "Use of BIH toget= her with a=A0NAT64 is NOT RECOMMENDED".
- RFC 2119 says that=A0"NOT RECOM= MENDED" means that "there may exist valid reasons in particular= =A0circumstances when the particular behavior is acceptable or even useful&= quot;.
- 464XLAT-like scenarios are IMHO &quo= t;valid reasons in=A0particular circumstances" that justify using &quo= t;BIH together with a NAT44"=A0

As you likely well know, ipv6 transition is an ecosystem transition and = recommendations like the one in BIH become a lightening rod for confusion. =

Having not followed the Behave debate on BIH, I just read = the resulting RFC with an open mind.
So far, I don't know anything that justifies this negative appreci= ation.=A0

We can leave it at that.

IMHO, BIH is not only valuable for its documented v4-only-to-v6-only u= se cases, but also for use cases targeted by 464XLAT. =A0
For such scenarios, it looks sufficient that:
(a) RFC 6535 is used in its socket-layer variant=A0(ignoring=A0the net= work layer variant, as already recommended in sec. 4)
(b)=A0In hosts whose only interface is IPv6, all=A0IPv4 packets are su= bject to=A0protocol translation (as already implicitly suggested in sec 4.5= )
(c)=A0IPv6 addresses that, for (b), need to be used as substitute of p= ublic IPv4 addresses are synthesized according to=A0RFC 6052 (the available= RFC for this).

Thus,=A0a BIH host works=A0in face of an ordinary=A0NAT64 with the sam= e e2e effect as that of a=A0CLAT in face of a PLAT.

Anything missed?

> > That said, 464XLAT authors have found rfc6145 to be the best f= it for
> > IPv4->IPv6 translation, including support for the fu= nction in a more
> > generic node such as a router (home gateway C= PE, mobile phone as a
> > host, mobile phone as a wifi router, ...)

(*)=A0A BIH host that includes a NAT44 can be an IPv4 router on its LA= N side, without needing any new specification for this.

...

If I read section 2.3 correctly of bih, it requires all sessions be crea= ted by enr.

(**)
- Section 2.3 of RFC 6535 says "if a DNS A record reply contains = non-excluded real IPv4 addresses, the ENR MUST NOT synthesize IPv4 addresse= s". ENR doesn't apply to public IPv4 addresses.
- With RFC 6052 used for 1:1 mappings between public IPv4 address and = an IPv6 addresses, sessions are possible with IPv4 referrals (neither DNS n= or ENR needed).=A0

In the network implementation of bih, bih cannot support ipv4 communicat= ion that does not start with DNS because DNS triggers the enr. So, bih on a= router cannot facilitate for a client of=A0 the router a Skype call=A0 sin= ce Skype signals ipv4 literals.
The bih router (which does not exist) cannot create the enr triggered sessi= on mappings with capturing DNS first.

No problem with the socket-layer variant (see (a) above)=A0

> A host can also be also a router, in particular if it includes a NA= T44.
> I see nothing that prevents using it in this case.
>

I don't believe bih had this use case in scope. The diagrams and tex= t in bih make reference to a host, not a host / router.

Discussed in (*) above

Trust me, if bih worked as you suggest, my life would be much easier.

Unless I miss something, this can still be the case :-).

If bih officially worked with nat64 and did not require the enr mapper s= o that it supported ipv4 literals in network mode, that would be great.

Discussed in (**) above.

In fact, I pushed for both when bih was a draft in behave.

Maybe time has come to acknowledge that what was=A0a=A0"NOT RECOM= MENDED" (not a "MUST NOT") is in fact=A0useful for
the following use case:

=A0(IPv4-only appli or NAT44)
=A0(BIH with RFC6146)
=A0 =A0 v
=A0IPv6-only network
=A0 =A0 v
=A0(stateful NAT64)
=A0 =A0 v
=A0 IPv4 Internet
=A0 =A0 v
=A0(IPv4 server)


Regards,
RD



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


--001636c5bd73ef581404bdc826f2-- From despres.remi@laposte.net Mon Apr 16 02:20:53 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2A5D21F874A for ; Mon, 16 Apr 2012 02:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.893 X-Spam-Level: X-Spam-Status: No, score=-2.893 tagged_above=-999 required=5 tests=[AWL=0.805, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, 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 1SrNgRKeLrVw for ; Mon, 16 Apr 2012 02:20:49 -0700 (PDT) Received: from smtpout.laposte.net (smtpout1.laposte.net [193.253.67.226]) by ietfa.amsl.com (Postfix) with ESMTP id ED7C621F8734 for ; Mon, 16 Apr 2012 02:20:48 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8501-out with ME id yZLm1i00437Y3f403ZLmad; Mon, 16 Apr 2012 11:20:47 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-9--221439374 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Mon, 16 Apr 2012 11:20:46 +0200 Message-Id: <1ECBF7E2-B595-4644-A6F9-725FA08844E4@laposte.net> References: <7E1BD96D-E7EC-4C78-B382-66F0F694DAA4@laposte.net> <1825062D-D4EB-4310-A2BA-8B8F3870B9B4@laposte.net> <22BD6607-5DEC-48F3-B2E5-DCEECC9EF643@laposte.net> To: Hui Deng X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] A way forward for 464XLAT - using BIH X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 09:20:53 -0000 --Apple-Mail-9--221439374 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-04-16 =E0 11:07, Hui Deng a =E9crit : > I don't know where this discussion comes from, but just clarify one = thing, > For socket based translation, it match with the host only > For header translation, it is not necessraily always host, could be = others. If the host IPv4-only application which uses the IPv4 API happens to be = a NAT44, is there anything that would prevent this host from also = including an IPv4 router (with a private IPv4 address space)?=20 > Does anybody know where is the definition of the host? In my understanding, a host is the node that is reached at a destination = address.=20 (If a received packet is forwarded after modification, it must have a = new destination address.) Regards, RD =20 > =20 > -Hui >=20 > 2012/4/16 R=E9mi Despr=E9s > 2012-04-03 =E0 16:15, Cameron Byrne : >> On Apr 3, 2012 12:32 AM, "R=E9mi Despr=E9s" = wrote: >>=20 > ... >> > BIH "recommends" to avoid double translation. >> > This AFAIK permits it if good reasons are found. >> > >>=20 >> Yes, it is an all capital letter recommendation.=20 >>=20 > - RFC 6535 says "Use of BIH together with a NAT64 is NOT RECOMMENDED". > - RFC 2119 says that "NOT RECOMMENDED" means that "there may exist = valid reasons in particular circumstances when the particular behavior = is acceptable or even useful". > - 464XLAT-like scenarios are IMHO "valid reasons in particular = circumstances" that justify using "BIH together with a NAT44"=20 >=20 >> As you likely well know, ipv6 transition is an ecosystem transition = and recommendations like the one in BIH become a lightening rod for = confusion. >>=20 > Having not followed the Behave debate on BIH, I just read the = resulting RFC with an open mind. > So far, I don't know anything that justifies this negative = appreciation.=20 >=20 >> We can leave it at that. >>=20 > IMHO, BIH is not only valuable for its documented v4-only-to-v6-only = use cases, but also for use cases targeted by 464XLAT. =20 > For such scenarios, it looks sufficient that: > (a) RFC 6535 is used in its socket-layer variant (ignoring the network = layer variant, as already recommended in sec. 4) > (b) In hosts whose only interface is IPv6, all IPv4 packets are = subject to protocol translation (as already implicitly suggested in sec = 4.5) > (c) IPv6 addresses that, for (b), need to be used as substitute of = public IPv4 addresses are synthesized according to RFC 6052 (the = available RFC for this). >=20 > Thus, a BIH host works in face of an ordinary NAT64 with the same e2e = effect as that of a CLAT in face of a PLAT. >=20 > Anything missed? >=20 >> > > That said, 464XLAT authors have found rfc6145 to be the best fit = for >> > > IPv4->IPv6 translation, including support for the function in a = more >> > > generic node such as a router (home gateway CPE, mobile phone as = a >> > > host, mobile phone as a wifi router, ...) >>=20 > (*) A BIH host that includes a NAT44 can be an IPv4 router on its LAN = side, without needing any new specification for this. >=20 > ... >> If I read section 2.3 correctly of bih, it requires all sessions be = created by enr. >>=20 > (**) > - Section 2.3 of RFC 6535 says "if a DNS A record reply contains = non-excluded real IPv4 addresses, the ENR MUST NOT synthesize IPv4 = addresses". ENR doesn't apply to public IPv4 addresses. > - With RFC 6052 used for 1:1 mappings between public IPv4 address and = an IPv6 addresses, sessions are possible with IPv4 referrals (neither = DNS nor ENR needed).=20 >=20 >> In the network implementation of bih, bih cannot support ipv4 = communication that does not start with DNS because DNS triggers the enr. = So, bih on a router cannot facilitate for a client of the router a = Skype call since Skype signals ipv4 literals.=20 >> The bih router (which does not exist) cannot create the enr triggered = session mappings with capturing DNS first. >>=20 > No problem with the socket-layer variant (see (a) above)=20 >=20 >> > A host can also be also a router, in particular if it includes a = NAT44. >> > I see nothing that prevents using it in this case. >> > >>=20 >> I don't believe bih had this use case in scope. The diagrams and text = in bih make reference to a host, not a host / router. >>=20 > Discussed in (*) above >=20 >> Trust me, if bih worked as you suggest, my life would be much easier. >>=20 > Unless I miss something, this can still be the case :-). >> If bih officially worked with nat64 and did not require the enr = mapper so that it supported ipv4 literals in network mode, that would be = great. >>=20 > Discussed in (**) above. >=20 >> In fact, I pushed for both when bih was a draft in behave.=20 >>=20 > Maybe time has come to acknowledge that what was a "NOT RECOMMENDED" = (not a "MUST NOT") is in fact useful for > the following use case: >=20 > (IPv4-only appli or NAT44) > (BIH with RFC6146) > v > IPv6-only network > v > (stateful NAT64) > v > IPv4 Internet > v > (IPv4 server) >=20 >=20 > Regards, > RD >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 --Apple-Mail-9--221439374 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
I = don't know where this discussion comes from, but just clarify one = thing,
For socket based translation, it match with the host only
For header translation, it is not necessraily always host, could be = others.

If the host IPv4-only = application which uses the IPv4 API happens to be a NAT44, is there = anything that would prevent this host from also including an IPv4 router = (with a private IPv4 address = space)? 


Does anybody know where is the definition of the = host?

In my understanding, a host is = the node that is reached at a destination address. 
(If a = received packet is forwarded after modification, it must have = a new destination = address.)

Regards,
RD



  
 
-Hui

2012/4/16 R=E9mi Despr=E9s <despres.remi@laposte.net><= /span>
2012-04-03 =E0 16:15, Cameron Byrne :

On Apr 3, 2012 12:32 AM, "R=E9mi Despr=E9s" = <despres.remi@laposte.net> = wrote:

...

> BIH "recommends" to avoid double = translation.
> This AFAIK permits it if good reasons are = found.
>

Yes, it is an all capital letter = recommendation. 

- RFC 6535 says "Use of BIH = together with a NAT64 is NOT RECOMMENDED".
- RFC 2119 says that "NOT = RECOMMENDED" means that "there may exist valid reasons in = particular circumstances when the particular behavior is acceptable = or even useful".
- 464XLAT-like scenarios are IMHO = "valid reasons in particular circumstances" that justify using "BIH = together with a NAT44" 

As you likely well know, ipv6 transition is = an ecosystem transition and recommendations like the one in BIH become a = lightening rod for confusion.

Having not followed the = Behave debate on BIH, I just read the resulting RFC with an open = mind.
So far, I don't know anything that justifies this negative = appreciation. 

We can leave it at that.

IMHO, BIH is not only valuable for its documented = v4-only-to-v6-only use cases, but also for use cases targeted by = 464XLAT.  
For such scenarios, it looks sufficient that:
(a) RFC 6535 is used in its socket-layer = variant (ignoring the network layer variant, as already = recommended in sec. 4)
(b) In hosts whose only interface is IPv6, all IPv4 = packets are subject to protocol translation (as already implicitly = suggested in sec 4.5)
(c) IPv6 addresses that, for (b), need to be used as = substitute of public IPv4 addresses are synthesized according = to RFC 6052 (the available RFC for this).

Thus, a BIH host works in face of an ordinary NAT64 = with the same e2e effect as that of a CLAT in face of a PLAT.

Anything missed?

> > That said, 464XLAT authors have = found rfc6145 to be the best fit for
> > IPv4->IPv6 = translation, including support for the function in a more
> > = generic node such as a router (home gateway CPE, mobile phone as a
> > host, mobile phone as a wifi router, ...)

(*) A BIH host that includes a NAT44 can be an IPv4 router on = its LAN side, without needing any new specification for this.

...

If I read section 2.3 correctly of bih, it = requires all sessions be created by enr.

(**)
- Section 2.3 of RFC 6535 says "if a DNS A record reply contains = non-excluded real IPv4 addresses, the ENR MUST NOT synthesize IPv4 = addresses". ENR doesn't apply to public IPv4 addresses.
- With RFC 6052 used for 1:1 mappings between public IPv4 address = and an IPv6 addresses, sessions are possible with IPv4 referrals = (neither DNS nor ENR needed). 

In the network implementation of bih, bih = cannot support ipv4 communication that does not start with DNS because = DNS triggers the enr. So, bih on a router cannot facilitate for a client = of  the router a Skype call  since Skype signals ipv4 = literals.
The bih router (which does not exist) cannot create the enr triggered = session mappings with capturing DNS first.

No problem with the socket-layer variant (see (a) = above) 

> A host can also be also a router, in = particular if it includes a NAT44.
> I see nothing that prevents = using it in this case.
>

I don't believe bih had this use = case in scope. The diagrams and text in bih make reference to a host, = not a host / router.

Discussed in (*) above

Trust me, if bih worked as you suggest, my = life would be much easier.

Unless I miss something, = this can still be the case :-).

If bih officially worked with nat64 and did = not require the enr mapper so that it supported ipv4 literals in network = mode, that would be great.

Discussed in (**) above.

In fact, I pushed for both when bih was a = draft in behave.

Maybe time has come to acknowledge that what was a "NOT = RECOMMENDED" (not a "MUST NOT") is in fact useful for
the following use case:

 (IPv4-only appli or NAT44)
 (BIH with RFC6146)
    v
 IPv6-only network
    v
 (stateful NAT64)
    v
  IPv4 Internet
    v
 (IPv4 server)


Regards,
RD

=


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



= --Apple-Mail-9--221439374-- From denghui02@gmail.com Mon Apr 16 02:22:39 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EEB621F8763 for ; Mon, 16 Apr 2012 02:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.136 X-Spam-Level: X-Spam-Status: No, score=-104.136 tagged_above=-999 required=5 tests=[AWL=0.563, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 RjenRssXZU1W for ; Mon, 16 Apr 2012 02:22:38 -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 DFB2C21F8647 for ; Mon, 16 Apr 2012 02:22:37 -0700 (PDT) Received: by ghbg16 with SMTP id g16so2611629ghb.31 for ; Mon, 16 Apr 2012 02:22:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1px38ZVgcQTMt261IC7obQSv+mta7Y0btuqOMCjufAE=; b=Fc4P+f6PkczQNJiz3h0kMUatAJSCNimI88X1vG9vFGPEvimt34zFChh+K+pykCc/3V eup5/+QD/m7wqep3gLc4qfnhd+VWCmUtbxLOlSffqAd+WHm+2K7fDtlSVAqKjETLdWJg f6zhlgJNjfwet9fPVfX5sZhk6AcgGLdtrVLO9xLkFaTy5CNmHX/WnOYRP8DhDP1355HX qMsxA3Jh4qCEqODssTsW0387/U3Vg8BCe3kxX9Te4LFrqut17w0clHkULLFzEQXL3/wm wEwGe2h3OCMmWF9RQvWne1EmwSV74cPfD1BbNhLJD6jFYPrTgCoics1ggHFDKGxq1LH/ ZIQw== MIME-Version: 1.0 Received: by 10.101.180.40 with SMTP id h40mr2909518anp.4.1334568157489; Mon, 16 Apr 2012 02:22:37 -0700 (PDT) Received: by 10.146.20.14 with HTTP; Mon, 16 Apr 2012 02:22:37 -0700 (PDT) In-Reply-To: <1ECBF7E2-B595-4644-A6F9-725FA08844E4@laposte.net> References: <7E1BD96D-E7EC-4C78-B382-66F0F694DAA4@laposte.net> <1825062D-D4EB-4310-A2BA-8B8F3870B9B4@laposte.net> <22BD6607-5DEC-48F3-B2E5-DCEECC9EF643@laposte.net> <1ECBF7E2-B595-4644-A6F9-725FA08844E4@laposte.net> Date: Mon, 16 Apr 2012 17:22:37 +0800 Message-ID: From: Hui Deng To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=001636c92acaf4aaac04bdc85c63 Cc: v6ops WG Subject: Re: [v6ops] A way forward for 464XLAT - using BIH X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 09:22:39 -0000 --001636c92acaf4aaac04bdc85c63 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2012/4/16 R=E9mi Despr=E9s > > Le 2012-04-16 =E0 11:07, Hui Deng a =E9crit : > > I don't know where this discussion comes from, but just clarify one > thing, > For socket based translation, it match with the host only > For header translation, it is not necessraily always host, could be other= s. > > > If the host IPv4-only application which uses the IPv4 API happens to be a > NAT44, is there anything that would prevent this host from also including > an IPv4 router (with a private IPv4 address space)? > No, it can do both simutanesouly. -Hui > > > Does anybody know where is the definition of the host? > > > In my understanding, a host is the node that is reached at a destination > address. > (If a received packet is forwarded after modification, it must have a new > destination address.) > > Regards, > RD > > > > > > > -Hui > > 2012/4/16 R=E9mi Despr=E9s > >> 2012-04-03 =E0 16:15, Cameron Byrne : >> >> On Apr 3, 2012 12:32 AM, "R=E9mi Despr=E9s" w= rote: >> >> ... >> >> > BIH "recommends" to avoid double translation. >> > This AFAIK permits it if good reasons are found. >> > >> >> Yes, it is an all capital letter recommendation. >> >> - RFC 6535 says "Use of BIH together with a NAT64 is NOT RECOMMENDED". >> - RFC 2119 says that "NOT RECOMMENDED" means that "there may exist valid >> reasons in particular circumstances when the particular behavior is >> acceptable or even useful". >> - 464XLAT-like scenarios are IMHO "valid reasons in particular >> circumstances" that justify using "BIH together with a NAT44" >> >> As you likely well know, ipv6 transition is an ecosystem transition and >> recommendations like the one in BIH become a lightening rod for confusio= n. >> >> Having not followed the Behave debate on BIH, I just read the resulting >> RFC with an open mind. >> So far, I don't know anything that justifies this negative appreciation. >> >> We can leave it at that. >> >> IMHO, BIH is not only valuable for its documented v4-only-to-v6-only use >> cases, but also for use cases targeted by 464XLAT. >> For such scenarios, it looks sufficient that: >> (a) RFC 6535 is used in its socket-layer variant (ignoring the network >> layer variant, as already recommended in sec. 4) >> (b) In hosts whose only interface is IPv6, all IPv4 packets are subject >> to protocol translation (as already implicitly suggested in sec 4.5) >> (c) IPv6 addresses that, for (b), need to be used as substitute of publi= c >> IPv4 addresses are synthesized according to RFC 6052 (the available RFC = for >> this). >> >> Thus, a BIH host works in face of an ordinary NAT64 with the same e2e >> effect as that of a CLAT in face of a PLAT. >> >> Anything missed? >> >> > > That said, 464XLAT authors have found rfc6145 to be the best fit fo= r >> > > IPv4->IPv6 translation, including support for the function in a more >> > > generic node such as a router (home gateway CPE, mobile phone as a >> > > host, mobile phone as a wifi router, ...) >> >> (*) A BIH host that includes a NAT44 can be an IPv4 router on its LAN >> side, without needing any new specification for this. >> >> ... >> >> If I read section 2.3 correctly of bih, it requires all sessions be >> created by enr. >> >> (**) >> - Section 2.3 of RFC 6535 says "if a DNS A record reply contains >> non-excluded real IPv4 addresses, the ENR MUST NOT synthesize IPv4 >> addresses". ENR doesn't apply to public IPv4 addresses. >> - With RFC 6052 used for 1:1 mappings between public IPv4 address and an >> IPv6 addresses, sessions are possible with IPv4 referrals (neither DNS n= or >> ENR needed). >> >> In the network implementation of bih, bih cannot support ipv4 >> communication that does not start with DNS because DNS triggers the enr. >> So, bih on a router cannot facilitate for a client of the router a Skyp= e >> call since Skype signals ipv4 literals. >> The bih router (which does not exist) cannot create the enr triggered >> session mappings with capturing DNS first. >> >> No problem with the socket-layer variant (see (a) above) >> >> > A host can also be also a router, in particular if it includes a >> NAT44. >> > I see nothing that prevents using it in this case. >> > >> >> I don't believe bih had this use case in scope. The diagrams and text in >> bih make reference to a host, not a host / router. >> >> Discussed in (*) above >> >> Trust me, if bih worked as you suggest, my life would be much easier. >> >> Unless I miss something, this can still be the case :-). >> >> If bih officially worked with nat64 and did not require the enr mapper s= o >> that it supported ipv4 literals in network mode, that would be great. >> >> Discussed in (**) above. >> >> In fact, I pushed for both when bih was a draft in behave. >> >> Maybe time has come to acknowledge that what was a "NOT RECOMMENDED" >> (not a "MUST NOT") is in fact useful for >> the following use case: >> >> (IPv4-only appli or NAT44) >> (BIH with RFC6146) >> v >> IPv6-only network >> v >> (stateful NAT64) >> v >> IPv4 Internet >> v >> (IPv4 server) >> >> >> Regards, >> RD >> >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> >> > > --001636c92acaf4aaac04bdc85c63 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/4/16 R=E9mi Despr=E9s <= ;despres.remi@laposte.net&g= t;

Le 2012-04-16 =E0 11:07, Hui Deng a =E9crit :

I don't know where this discussion comes from, but just clarify on= e thing,
For socket based translation, it match with the host only
For header translation, it is not necessraily always host, could be ot= hers.

If the host IPv4-only application which uses the IPv4 API happens to b= e a NAT44, is there anything that would prevent this host from also includi= ng an IPv4 router (with a private IPv4 address space)?=A0
No, it can do both simutanesouly.
=A0
-Hui
=A0


Does anybody know where is the definition of the host?

In my understanding, a host is the node that is reache= d at a destination address.=A0
(If a received packet=A0is forwarded=A0after modification, it must hav= e a new destination address.)

Regards,
RD



=A0=A0
=A0
-Hui

2012/4/16 R=E9mi Despr=E9s <= ;despres.remi= @laposte.net>
2012-04-03 =E0 16:15, Cameron Byrne :

On Apr 3, 2012 12:32 AM, "R=E9mi Despr=E9s" <despres.remi@laposte.net> wrote:

...

> BIH "recommends" to avoid double translation.
> Thi= s AFAIK permits it if good reasons are found.
>

Yes, it is an all capital letter recommendation.=A0

- RFC 6535 says "Use of BIH toget= her with a=A0NAT64 is NOT RECOMMENDED".
- RFC 2119 says that=A0"NOT RECOM= MENDED" means that "there may exist valid reasons in particular= =A0circumstances when the particular behavior is acceptable or even useful&= quot;.
- 464XLAT-like scenarios are IMHO &quo= t;valid reasons in=A0particular circumstances" that justify using &quo= t;BIH together with a NAT44"=A0

As you likely well know, ipv6 transition is an ecosystem transition and = recommendations like the one in BIH become a lightening rod for confusion. =

Having not followed the Behave debate on BIH, I just read = the resulting RFC with an open mind.
So far, I don't know anything that justifies this negative appreci= ation.=A0

We can leave it at that.

IMHO, BIH is not only valuable for its documented v4-only-to-v6-only u= se cases, but also for use cases targeted by 464XLAT. =A0
For such scenarios, it looks sufficient that:
(a) RFC 6535 is used in its socket-layer variant=A0(ignoring=A0the net= work layer variant, as already recommended in sec. 4)
(b)=A0In hosts whose only interface is IPv6, all=A0IPv4 packets are su= bject to=A0protocol translation (as already implicitly suggested in sec 4.5= )
(c)=A0IPv6 addresses that, for (b), need to be used as substitute of p= ublic IPv4 addresses are synthesized according to=A0RFC 6052 (the available= RFC for this).

Thus,=A0a BIH host works=A0in face of an ordinary=A0NAT64 with the sam= e e2e effect as that of a=A0CLAT in face of a PLAT.

Anything missed?

> > That said, 464XLAT authors have found rfc6145 to be the best f= it for
> > IPv4->IPv6 translation, including support for the fu= nction in a more
> > generic node such as a router (home gateway C= PE, mobile phone as a
> > host, mobile phone as a wifi router, ...)

(*)=A0A BIH host that includes a NAT44 can be an IPv4 router on its LA= N side, without needing any new specification for this.

...

If I read section 2.3 correctly of bih, it requires all sessions be crea= ted by enr.

(**)
- Section 2.3 of RFC 6535 says "if a DNS A record reply contains = non-excluded real IPv4 addresses, the ENR MUST NOT synthesize IPv4 addresse= s". ENR doesn't apply to public IPv4 addresses.
- With RFC 6052 used for 1:1 mappings between public IPv4 address and = an IPv6 addresses, sessions are possible with IPv4 referrals (neither DNS n= or ENR needed).=A0

In the network implementation of bih, bih cannot support ipv4 communicat= ion that does not start with DNS because DNS triggers the enr. So, bih on a= router cannot facilitate for a client of=A0 the router a Skype call=A0 sin= ce Skype signals ipv4 literals.
The bih router (which does not exist) cannot create the enr triggered sessi= on mappings with capturing DNS first.

No problem with the socket-layer variant (see (a) above)=A0

> A host can also be also a router, in particular if it includes a NA= T44.
> I see nothing that prevents using it in this case.
>

I don't believe bih had this use case in scope. The diagrams and tex= t in bih make reference to a host, not a host / router.

Discussed in (*) above

Trust me, if bih worked as you suggest, my life would be much easier.

Unless I miss something, this can still be the case :-).

If bih officially worked with nat64 and did not require the enr mapper s= o that it supported ipv4 literals in network mode, that would be great.

Discussed in (**) above.

In fact, I pushed for both when bih was a draft in behave.

Maybe time has come to acknowledge that what was=A0a=A0"NOT RECOM= MENDED" (not a "MUST NOT") is in fact=A0useful for
the following use case:

=A0(IPv4-only appli or NAT44)
=A0(BIH with RFC6146)
=A0 =A0 v
=A0IPv6-only network
=A0 =A0 v
=A0(stateful NAT64)
=A0 =A0 v
=A0 IPv4 Internet
=A0 =A0 v
=A0(IPv4 server)


Regards,
RD



________________________________= _______________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinf= o/v6ops




--001636c92acaf4aaac04bdc85c63-- From lorenzo@google.com Mon Apr 16 02:33:45 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EA7D21F8670 for ; Mon, 16 Apr 2012 02:33:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.751 X-Spam-Level: X-Spam-Status: No, score=-102.751 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1pWp5fSeRVo7 for ; Mon, 16 Apr 2012 02:33:44 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id E6A6D21F86CA for ; Mon, 16 Apr 2012 02:33:29 -0700 (PDT) Received: by obbwd20 with SMTP id wd20so2285502obb.31 for ; Mon, 16 Apr 2012 02:33:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=bBFAq77ri8fsFQVtes/OAsw8/0IR23lubm0rr9qAhyc=; b=DySZt1r4hogDaJqq6WCJ5+urFQiEMWM72RFieI/l5UNiD35uR4C/YwDFGNQVZSievW ict9bAL2NDRrYuV0pgfFYTFhT64Pa06Omwk1JbgNKu7PBPSgrerGWITTLShH1LKc6opv YCSdSFelCyF+DSbod3p6CbRJXw34BoKwdmLBmxz1p0Y53LnyKm1rdffbMlgvGL2GtLAK rQHyab8ohraGheEBF3e7PDCjoiEzEnuYWICIk6Bd6Ft+X7J0H8ZbjbE1T0m+R0ooo0/t Ef/lvEFYUawDziTf6KZ5UcSOyw0ZnwUnVslMmvnC1P1w0TViwzKmAqFnQnYohLarvXIr kM1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=bBFAq77ri8fsFQVtes/OAsw8/0IR23lubm0rr9qAhyc=; b=WTiplcZiH2zb0/eWPrxVqAE5xP0u5QybBYw8bj4TjKTlb6O0OQ8VY1wTVfaccoTAr1 9/dka6abmjAk1ry1aD9l8fp/0tJS/sorZub8dBXW4buvhyvQmlkVMb9TUm/FWRJZx2tv FVmP7hU61JxR2Z1LvkCxTYIDUJ0m3G1gkGNqK393tHzZGWPLVHSkbNEIG7nXSjoI1dsr Gp8pHLzSdpYMz30eR87atlfnuYf79sUh6jidxDrEk6C86hpWuWmlUmS/PwhM7lBONrha vU8gj49mxloKNe+EhCenSrIl/zItCc/xVvXOwE1SceC5wuG1spO75pyKis1PKTRhwJoG UEBA== Received: by 10.60.0.226 with SMTP id 2mr14725856oeh.18.1334568809266; Mon, 16 Apr 2012 02:33:29 -0700 (PDT) Received: by 10.60.0.226 with SMTP id 2mr14725839oeh.18.1334568809101; Mon, 16 Apr 2012 02:33:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.220.3 with HTTP; Mon, 16 Apr 2012 02:33:08 -0700 (PDT) In-Reply-To: References: <7E1BD96D-E7EC-4C78-B382-66F0F694DAA4@laposte.net> <1825062D-D4EB-4310-A2BA-8B8F3870B9B4@laposte.net> <22BD6607-5DEC-48F3-B2E5-DCEECC9EF643@laposte.net> From: Lorenzo Colitti Date: Mon, 16 Apr 2012 18:33:08 +0900 Message-ID: To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=e89a8fb1fbc6cb776404bdc883e8 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnyI5B/jc4skSOdUGC3oaXWMz9lq1805uhjlCREmS9+kAASHs5Ok2x5lrScm07OyRYtpVFCx1xYGoo+El28Dvz+yTQ3/G0qd0buJYgs7fpgEKSXX6RetamicTOnVZVGrAdxAxyR Cc: v6ops WG Subject: Re: [v6ops] A way forward for 464XLAT - using BIH X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 09:33:45 -0000 --e89a8fb1fbc6cb776404bdc883e8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Apr 16, 2012 at 17:57, R=E9mi Despr=E9s w= rote: > The best approach IMHO would be a BCP just explaining that BIH, used with > RFC6052 for v4-v6 address translation, is now recommended > for IPv4-only-application support via networks supporting stateful NAT64s > (without developing other ways to get a similar result). > > Whether such a use case should have its own name, such as 464XLAT, is an > open question AFAIAC but, provided the BCP is as simple as it can be, I > personally don't care. > But it wouldn't necessarily be an application scenario of BIH. It could just as well be an application scenario for RFC 6145 and RFC 6146, right? In either case there needs to be a BCP. --e89a8fb1fbc6cb776404bdc883e8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Apr 16, 2012 at 17:57, R=E9mi Despr=E9s = <despres.r= emi@laposte.net> wrote:
The best approach IMHO would be a = BCP just explaining that BIH, used with RFC6052 for v4-v6 address translati= on, is now recommended for=A0IPv4-only-application support via networks sup= porting=A0stateful NAT64s (without developing other ways to get a similar r= esult).

Whether such a use case should have its own name, such = as 464XLAT, is an open question AFAIAC but, provided the BCP is as simple a= s it can be, I personally don't care.

But it wouldn't necessarily be an application scenario o= f BIH. It could just as well be an application scenario for=A0RFC 6145 and = RFC 6146, right?

In either case there needs to be = a BCP.
--e89a8fb1fbc6cb776404bdc883e8-- From despres.remi@laposte.net Mon Apr 16 02:33:50 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CEF421F8704 for ; Mon, 16 Apr 2012 02:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.911 X-Spam-Level: X-Spam-Status: No, score=-2.911 tagged_above=-999 required=5 tests=[AWL=0.787, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, 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 z56GJufnqYjG for ; Mon, 16 Apr 2012 02:33:48 -0700 (PDT) Received: from smtpout.laposte.net (smtpout2.laposte.net [193.253.67.227]) by ietfa.amsl.com (Postfix) with ESMTP id 2E2D421F86DE for ; Mon, 16 Apr 2012 02:33:47 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8503-out with ME id yZZl1i00237Y3f403ZZlXg; Mon, 16 Apr 2012 11:33:46 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-10--220660261 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Mon, 16 Apr 2012 11:33:45 +0200 Message-Id: <6A73544B-D931-45E2-AAA3-ECF95C1E7AA0@laposte.net> References: <7E1BD96D-E7EC-4C78-B382-66F0F694DAA4@laposte.net> <1825062D-D4EB-4310-A2BA-8B8F3870B9B4@laposte.net> <22BD6607-5DEC-48F3-B2E5-DCEECC9EF643@laposte.net> <1ECBF7E2-B595-4644-A6F9-725FA08844E4@laposte.net> To: Hui Deng X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] A way forward for 464XLAT - using BIH X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 09:33:50 -0000 --Apple-Mail-10--220660261 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-04-16 =E0 11:22, Hui Deng a =E9crit : >=20 >=20 > 2012/4/16 R=E9mi Despr=E9s >=20 > Le 2012-04-16 =E0 11:07, Hui Deng a =E9crit : >=20 >> I don't know where this discussion comes from, but just clarify one = thing, >> For socket based translation, it match with the host only >> For header translation, it is not necessraily always host, could be = others. >=20 > If the host IPv4-only application which uses the IPv4 API happens to = be a NAT44, is there anything that would prevent this host from also = including an IPv4 router (with a private IPv4 address space)?=20 > No, it can do both simutanesouly. Same understanding on this, then. Thanks RD > =20 > -Hui > =20 >=20 >=20 >> Does anybody know where is the definition of the host? >=20 > In my understanding, a host is the node that is reached at a = destination address.=20 > (If a received packet is forwarded after modification, it must have a = new destination address.) >=20 > Regards, > RD >=20 >=20 >=20 > =20 >> =20 >> -Hui >>=20 >> 2012/4/16 R=E9mi Despr=E9s >> 2012-04-03 =E0 16:15, Cameron Byrne : >>> On Apr 3, 2012 12:32 AM, "R=E9mi Despr=E9s" = wrote: >>>=20 >> ... >>> > BIH "recommends" to avoid double translation. >>> > This AFAIK permits it if good reasons are found. >>> > >>>=20 >>> Yes, it is an all capital letter recommendation.=20 >>>=20 >> - RFC 6535 says "Use of BIH together with a NAT64 is NOT = RECOMMENDED". >> - RFC 2119 says that "NOT RECOMMENDED" means that "there may exist = valid reasons in particular circumstances when the particular behavior = is acceptable or even useful". >> - 464XLAT-like scenarios are IMHO "valid reasons in particular = circumstances" that justify using "BIH together with a NAT44"=20 >>=20 >>> As you likely well know, ipv6 transition is an ecosystem transition = and recommendations like the one in BIH become a lightening rod for = confusion. >>>=20 >> Having not followed the Behave debate on BIH, I just read the = resulting RFC with an open mind. >> So far, I don't know anything that justifies this negative = appreciation.=20 >>=20 >>> We can leave it at that. >>>=20 >> IMHO, BIH is not only valuable for its documented v4-only-to-v6-only = use cases, but also for use cases targeted by 464XLAT. =20 >> For such scenarios, it looks sufficient that: >> (a) RFC 6535 is used in its socket-layer variant (ignoring the = network layer variant, as already recommended in sec. 4) >> (b) In hosts whose only interface is IPv6, all IPv4 packets are = subject to protocol translation (as already implicitly suggested in sec = 4.5) >> (c) IPv6 addresses that, for (b), need to be used as substitute of = public IPv4 addresses are synthesized according to RFC 6052 (the = available RFC for this). >>=20 >> Thus, a BIH host works in face of an ordinary NAT64 with the same e2e = effect as that of a CLAT in face of a PLAT. >>=20 >> Anything missed? >>=20 >>> > > That said, 464XLAT authors have found rfc6145 to be the best fit = for >>> > > IPv4->IPv6 translation, including support for the function in a = more >>> > > generic node such as a router (home gateway CPE, mobile phone as = a >>> > > host, mobile phone as a wifi router, ...) >>>=20 >> (*) A BIH host that includes a NAT44 can be an IPv4 router on its LAN = side, without needing any new specification for this. >>=20 >> ... >>> If I read section 2.3 correctly of bih, it requires all sessions be = created by enr. >>>=20 >> (**) >> - Section 2.3 of RFC 6535 says "if a DNS A record reply contains = non-excluded real IPv4 addresses, the ENR MUST NOT synthesize IPv4 = addresses". ENR doesn't apply to public IPv4 addresses. >> - With RFC 6052 used for 1:1 mappings between public IPv4 address and = an IPv6 addresses, sessions are possible with IPv4 referrals (neither = DNS nor ENR needed).=20 >>=20 >>> In the network implementation of bih, bih cannot support ipv4 = communication that does not start with DNS because DNS triggers the enr. = So, bih on a router cannot facilitate for a client of the router a = Skype call since Skype signals ipv4 literals.=20 >>> The bih router (which does not exist) cannot create the enr = triggered session mappings with capturing DNS first. >>>=20 >> No problem with the socket-layer variant (see (a) above)=20 >>=20 >>> > A host can also be also a router, in particular if it includes a = NAT44. >>> > I see nothing that prevents using it in this case. >>> > >>>=20 >>> I don't believe bih had this use case in scope. The diagrams and = text in bih make reference to a host, not a host / router. >>>=20 >> Discussed in (*) above >>=20 >>> Trust me, if bih worked as you suggest, my life would be much = easier. >>>=20 >> Unless I miss something, this can still be the case :-). >>> If bih officially worked with nat64 and did not require the enr = mapper so that it supported ipv4 literals in network mode, that would be = great. >>>=20 >> Discussed in (**) above. >>=20 >>> In fact, I pushed for both when bih was a draft in behave.=20 >>>=20 >> Maybe time has come to acknowledge that what was a "NOT RECOMMENDED" = (not a "MUST NOT") is in fact useful for >> the following use case: >>=20 >> (IPv4-only appli or NAT44) >> (BIH with RFC6146) >> v >> IPv6-only network >> v >> (stateful NAT64) >> v >> IPv4 Internet >> v >> (IPv4 server) >>=20 >>=20 >> Regards, >> RD >>=20 >>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >>=20 >=20 >=20 --Apple-Mail-10--220660261 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1


2012/4/16 R=E9mi Despr=E9s <despres.remi@laposte.net><= /span>

Le 2012-04-16 =E0 11:07, Hui Deng a =E9crit :

I don't know where this discussion comes from, but just clarify one = thing,
For socket based translation, it match with the host only
For header translation, it is not necessraily always host, could be = others.

If the host IPv4-only application which uses the IPv4 API happens = to be a NAT44, is there anything that would prevent this host from also = including an IPv4 router (with a private IPv4 address = space)? 
No, it can do both = simutanesouly.

Same = understanding on this, = then.
Thanks

RD

 
-Hui
 


Does anybody know where is the definition of the = host?

In my understanding, a host is the node that is = reached at a destination address. 
(If a received packet is forwarded after modification, it = must have a new destination address.)

Regards,
RD



  
 
-Hui

2012/4/16 R=E9mi Despr=E9s <despres.remi@laposte.net>
2012-04-03 =E0 16:15, Cameron Byrne :

On Apr 3, 2012 12:32 AM, "R=E9mi Despr=E9s" = <despres.remi@laposte.net> = wrote:

...

> BIH "recommends" to avoid double = translation.
> This AFAIK permits it if good reasons are = found.
>

Yes, it is an all capital letter = recommendation. 

- RFC 6535 says "Use of BIH = together with a NAT64 is NOT RECOMMENDED".
- RFC 2119 says that "NOT = RECOMMENDED" means that "there may exist valid reasons in = particular circumstances when the particular behavior is acceptable = or even useful".
- 464XLAT-like scenarios are IMHO = "valid reasons in particular circumstances" that justify using "BIH = together with a NAT44" 

As you likely well know, ipv6 transition is = an ecosystem transition and recommendations like the one in BIH become a = lightening rod for confusion.

Having not followed the = Behave debate on BIH, I just read the resulting RFC with an open = mind.
So far, I don't know anything that justifies this negative = appreciation. 

We can leave it at that.

IMHO, BIH is not only valuable for its documented = v4-only-to-v6-only use cases, but also for use cases targeted by = 464XLAT.  
For such scenarios, it looks sufficient that:
(a) RFC 6535 is used in its socket-layer = variant (ignoring the network layer variant, as already = recommended in sec. 4)
(b) In hosts whose only interface is IPv6, all IPv4 = packets are subject to protocol translation (as already implicitly = suggested in sec 4.5)
(c) IPv6 addresses that, for (b), need to be used as = substitute of public IPv4 addresses are synthesized according = to RFC 6052 (the available RFC for this).

Thus, a BIH host works in face of an ordinary NAT64 = with the same e2e effect as that of a CLAT in face of a PLAT.

Anything missed?

> > That said, 464XLAT authors have = found rfc6145 to be the best fit for
> > IPv4->IPv6 = translation, including support for the function in a more
> > = generic node such as a router (home gateway CPE, mobile phone as a
> > host, mobile phone as a wifi router, ...)

(*) A BIH host that includes a NAT44 can be an IPv4 router on = its LAN side, without needing any new specification for this.

...

If I read section 2.3 correctly of bih, it = requires all sessions be created by enr.

(**)
- Section 2.3 of RFC 6535 says "if a DNS A record reply contains = non-excluded real IPv4 addresses, the ENR MUST NOT synthesize IPv4 = addresses". ENR doesn't apply to public IPv4 addresses.
- With RFC 6052 used for 1:1 mappings between public IPv4 address = and an IPv6 addresses, sessions are possible with IPv4 referrals = (neither DNS nor ENR needed). 

In the network implementation of bih, bih = cannot support ipv4 communication that does not start with DNS because = DNS triggers the enr. So, bih on a router cannot facilitate for a client = of  the router a Skype call  since Skype signals ipv4 = literals.
The bih router (which does not exist) cannot create the enr triggered = session mappings with capturing DNS first.

No problem with the socket-layer variant (see (a) = above) 

> A host can also be also a router, in = particular if it includes a NAT44.
> I see nothing that prevents = using it in this case.
>

I don't believe bih had this use = case in scope. The diagrams and text in bih make reference to a host, = not a host / router.

Discussed in (*) above

Trust me, if bih worked as you suggest, my = life would be much easier.

Unless I miss something, = this can still be the case :-).

If bih officially worked with nat64 and did = not require the enr mapper so that it supported ipv4 literals in network = mode, that would be great.

Discussed in (**) above.

In fact, I pushed for both when bih was a = draft in behave.

Maybe time has come to acknowledge that what was a "NOT = RECOMMENDED" (not a "MUST NOT") is in fact useful for
the following use case:

 (IPv4-only appli or NAT44)
 (BIH with RFC6146)
    v
 IPv6-only network
    v
 (stateful NAT64)
    v
  IPv4 Internet
    v
 (IPv4 server)


Regards,
RD

=


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




= --Apple-Mail-10--220660261-- From despres.remi@laposte.net Mon Apr 16 02:51:14 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC77721F8650 for ; Mon, 16 Apr 2012 02:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.607 X-Spam-Level: X-Spam-Status: No, score=-1.607 tagged_above=-999 required=5 tests=[AWL=-0.549, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6WfdncwDfiH for ; Mon, 16 Apr 2012 02:51:13 -0700 (PDT) Received: from smtpout.laposte.net (smtpout1.laposte.net [193.253.67.226]) by ietfa.amsl.com (Postfix) with ESMTP id 2A2C521F8733 for ; Mon, 16 Apr 2012 02:51:12 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8501-out with ME id yZr61i00337Y3f403Zr6Nn; Mon, 16 Apr 2012 11:51:11 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-11--219619849 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Mon, 16 Apr 2012 11:51:05 +0200 Message-Id: <986EAD24-4612-4AD0-B366-012BA0B3751C@laposte.net> References: <7E1BD96D-E7EC-4C78-B382-66F0F694DAA4@laposte.net> <1825062D-D4EB-4310-A2BA-8B8F3870B9B4@laposte.net> <22BD6607-5DEC-48F3-B2E5-DCEECC9EF643@laposte.net> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) Cc: v6ops WG , Bill Huang , Teemu Savolainen Subject: Re: [v6ops] A way forward for 464XLAT - using BIH X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 09:51:14 -0000 --Apple-Mail-11--219619849 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-04-16 =E0 11:33, Lorenzo Colitti a =E9crit : > On Mon, Apr 16, 2012 at 17:57, R=E9mi Despr=E9s = wrote: > The best approach IMHO would be a BCP just explaining that BIH, used = with RFC6052 for v4-v6 address translation, is now recommended for = IPv4-only-application support via networks supporting stateful NAT64s = (without developing other ways to get a similar result). >=20 > Whether such a use case should have its own name, such as 464XLAT, is = an open question AFAIAC but, provided the BCP is as simple as it can be, = I personally don't care. >=20 > But it wouldn't necessarily be an application scenario of BIH. It = could just as well be an application scenario for RFC 6145 and RFC 6146, = right? The BIH-NAT64 scenario uses only a subset of BIH functions, right. But: - Other BIH functions are useful (IPv4-only applications using IPv6-only = servers) - BIH specifies which local IPv4 addresses are seen by applications = without interfering with the host IPv6 address format.=20 For a short term validation of the RFC6535-RFC6052 combination, I = personally ignore whether there is open-source BIH code, and whether = some devices could be used for a test.=20 Copies of this mail to RFC6535 are added to know more. > In either case there needs to be a BCP. Same view, RD --Apple-Mail-11--219619849 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On Mon, Apr 16, 2012 at 17:57, = R=E9mi Despr=E9s <despres.remi@laposte.net><= /span> wrote:
The best approach IMHO would be = a BCP just explaining that BIH, used with RFC6052 for v4-v6 address = translation, is now recommended for IPv4-only-application support = via networks supporting stateful NAT64s (without developing other = ways to get a similar result).

Whether such a use case should have its own name, = such as 464XLAT, is an open question AFAIAC but, provided the BCP is as = simple as it can be, I personally don't = care.

But it wouldn't necessarily be an application scenario of = BIH. It could just as well be an application scenario for RFC 6145 = and RFC 6146, right?

The = BIH-NAT64 scenario uses only a subset of BIH functions, = right.
But:
- Other BIH functions are useful = (IPv4-only applications using IPv6-only servers)
- BIH = specifies which local IPv4 addresses are seen by applications without = interfering with the host IPv6 address = format. 

For a short term validation of = the RFC6535-RFC6052 combination, I personally ignore whether there is = open-source BIH code, and whether some devices could be used for a = test. 
Copies of this mail to RFC6535 are added to know = more.


In either case there needs to be a BCP.

Same = view,

RD

= --Apple-Mail-11--219619849-- From denghui02@gmail.com Mon Apr 16 03:10:50 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFECE21F867B for ; Mon, 16 Apr 2012 03:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.928 X-Spam-Level: X-Spam-Status: No, score=-102.928 tagged_above=-999 required=5 tests=[AWL=-0.870, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YBLVifEFlpqJ for ; Mon, 16 Apr 2012 03:10:50 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6145121F86D5 for ; Mon, 16 Apr 2012 03:10:49 -0700 (PDT) Received: by yenm5 with SMTP id m5so2631944yen.31 for ; Mon, 16 Apr 2012 03:10:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nD60YkZVEruhsWzCbhGZ8AOKrPKYGmM+UtCptfRk16w=; b=NPT2wxKnITLRzhAGogZVtJZkEB/XTuQmNTXxrfaTUqWao/EcnglC00Fny+waAmj828 u5xmwK8ALBX1i6Ge06PcNR1qifRIeR9M8VySPpFIjr8dl1bogZ/Q7yRRI8T7I5uaQGSW lojquq5RX7P44+w2yuWOrCGxg++nmbOQsNokUEGXVqkghdDwmtfTbQiRpfP5mdLn/2vW 07YNOirt+6xSlW/ggiDt6ajcvAVL/FXoA6lxREmvxuMq5l6cXkourH2B2EqYDj0z4JGL E2yEU9NzGPOPQ9V/bKk9n9+q3oTSKj2DLmyA4gMAZEoFiib7tMCmIQccU7PuO8f7dABM lIRg== MIME-Version: 1.0 Received: by 10.236.195.34 with SMTP id o22mr10360460yhn.75.1334571048108; Mon, 16 Apr 2012 03:10:48 -0700 (PDT) Received: by 10.146.20.14 with HTTP; Mon, 16 Apr 2012 03:10:48 -0700 (PDT) In-Reply-To: <986EAD24-4612-4AD0-B366-012BA0B3751C@laposte.net> References: <7E1BD96D-E7EC-4C78-B382-66F0F694DAA4@laposte.net> <1825062D-D4EB-4310-A2BA-8B8F3870B9B4@laposte.net> <22BD6607-5DEC-48F3-B2E5-DCEECC9EF643@laposte.net> <986EAD24-4612-4AD0-B366-012BA0B3751C@laposte.net> Date: Mon, 16 Apr 2012 18:10:48 +0800 Message-ID: From: Hui Deng To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=20cf3056389f40013404bdc90989 Cc: Teemu Savolainen , v6ops WG , Bill Huang Subject: Re: [v6ops] A way forward for 464XLAT - using BIH X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 10:10:50 -0000 --20cf3056389f40013404bdc90989 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable may I continue to clarify more, why socket layer variation is needed, even for header translation, if you can get a real Ipv4 address, ENR is not needed, skype will go through. -Hui 2012/4/16 R=E9mi Despr=E9s > > Le 2012-04-16 =E0 11:33, Lorenzo Colitti a =E9crit : > > On Mon, Apr 16, 2012 at 17:57, R=E9mi Despr=E9s wrote: > >> The best approach IMHO would be a BCP just explaining that BIH, used >> with RFC6052 for v4-v6 address translation, is now recommended >> for IPv4-only-application support via networks supporting stateful NAT64= s >> (without developing other ways to get a similar result). >> >> Whether such a use case should have its own name, such as 464XLAT, is an >> open question AFAIAC but, provided the BCP is as simple as it can be, I >> personally don't care. >> > > But it wouldn't necessarily be an application scenario of BIH. It could > just as well be an application scenario for RFC 6145 and RFC 6146, right? > > > The BIH-NAT64 scenario uses only a subset of BIH functions, right. > But: > - Other BIH functions are useful (IPv4-only applications using IPv6-only > servers) > - BIH specifies which local IPv4 addresses are seen by applications > without interfering with the host IPv6 address format. > > For a short term validation of the RFC6535-RFC6052 combination, I > personally ignore whether there is open-source BIH code, and whether some > devices could be used for a test. > Copies of this mail to RFC6535 are added to know more. > > > In either case there needs to be a BCP. > > > Same view, > > RD > > --20cf3056389f40013404bdc90989 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
may I continue to clarify more,
=A0
why socket layer variation is needed, even for header translation, if = you can get a real Ipv4 address, ENR is not needed, skype will go through.<= /div>
=A0
-Hui

2012/4/16 R=E9mi Despr=E9s <= ;despres.remi@laposte.net&g= t;

Le 2012-04-16 =E0 11:33, Lorenzo Colitti a =E9crit :

On Mon, Apr 16, 2012 at 17:57, R=E9mi Despr=E9s = <despres.remi@laposte.net> wrote:
The best approach IMHO would be a BCP just explaining that BIH, used w= ith RFC6052 for v4-v6 address translation, is now recommended for=A0IPv4-on= ly-application support via networks supporting=A0stateful NAT64s (without d= eveloping other ways to get a similar result).

Whether such a use case should have its own name, such as 464XLAT, is = an open question AFAIAC but, provided the BCP is as simple as it can be, I = personally don't care.

But it wouldn't necessarily be an application scenario of BIH. It = could just as well be an application scenario for=A0RFC 6145 and RFC 6146, = right?

The BIH-NAT64 scenario uses only a subset of BIH functions, right.
But:
- Other BIH functions are useful (IPv4-only applications using IPv6-on= ly servers)
- BIH specifies which local IPv4 addresses are seen by applications wi= thout interfering with the host IPv6 address format.=A0

For a short term validation of the RFC6535-RFC6052 combination, I pers= onally ignore whether there is open-source BIH code, and whether some devic= es could be used for a test.=A0
Copies of this mail to RFC6535 are added to know more.


In either case there needs to be a BCP.

Same view,

RD


--20cf3056389f40013404bdc90989-- From Francis.Dupont@fdupont.fr Mon Apr 16 04:57:31 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6740321F867C for ; Mon, 16 Apr 2012 04:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.052, 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 CHG+RJTwmIDM for ; Mon, 16 Apr 2012 04:57:30 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 63D9421F8456 for ; Mon, 16 Apr 2012 04:57:30 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q3GBvMXE088261; Mon, 16 Apr 2012 13:57:22 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201204161157.q3GBvMXE088261@givry.fdupont.fr> From: Francis Dupont To: Fred Baker In-reply-to: Your message of Sun, 15 Apr 2012 13:54:00 PDT. <2FEFE40E-25F2-4D02-A608-0CADCBBAAE9C@cisco.com> Date: Mon, 16 Apr 2012 13:57:22 +0200 Sender: Francis.Dupont@fdupont.fr Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 11:57:31 -0000 In your previous mail you wrote: > This is to initiate a ONE week working group last call of > draft-ietf-v6ops-6204bis => I have still a concern about W-6: W-6: The WAN interface of the CE router SHOULD support a PCP client as specified in [I-D.ietf-pcp-base] for use by applications on the CE Router. The PCP client SHOULD follow the procedure specified in Section 8.1 of [I-D.ietf-pcp-base] to discover its PCP server. This document takes no position on whether such functionality is enabled by default or mechanisms by which users would configure the functionality. Handling PCP requests from PCP clients in the LAN side of the CE Router is out of scope. for at least two reasons: - there are other protocols than PCP which provides the function, for instance UPnP IGD v2. - there is no known example of a router application which needs the function So I propose to step back to what was in RFC 6204, i.e., simply remove W-6 (and the PCP reference). Note if the last sentence about the LAN side changes of course W-6 (with another wording) could make sense again. Regards Francis.Dupont@fdupont.fr PS: the draft should be written in US English so without the 'e' in Acknowledgements. ^ From bs7652@att.com Mon Apr 16 06:45:19 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5769F21F8721 for ; Mon, 16 Apr 2012 06:45:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w7IBHjWcFpzE for ; Mon, 16 Apr 2012 06:45:18 -0700 (PDT) Received: from nbfkord-smmo03.seg.att.com (nbfkord-smmo03.seg.att.com [209.65.160.84]) by ietfa.amsl.com (Postfix) with ESMTP id 4800721F870E for ; Mon, 16 Apr 2012 06:45:16 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo03.seg.att.com) by nbfkord-smmo03.seg.att.com(mxl_mta-6.11.0-8) with ESMTP id c622c8f4.79053940.245450.00-599.663243.nbfkord-smmo03.seg.att.com (envelope-from ); Mon, 16 Apr 2012 13:45:16 +0000 (UTC) X-MXL-Hash: 4f8c226c0703f19a-b070c3b42270ebd70b493396159f8dc3fc5e8d55 Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo03.seg.att.com(mxl_mta-6.11.0-8) over TLS secured channel with ESMTP id b522c8f4.0.245327.00-464.662847.nbfkord-smmo03.seg.att.com (envelope-from ); Mon, 16 Apr 2012 13:45:01 +0000 (UTC) X-MXL-Hash: 4f8c225d2b870c7c-52943bee0b5d08e81a2552ee537af583da1f16ce Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q3GDix7r016754; Mon, 16 Apr 2012 09:44:59 -0400 Received: from sflint03.pst.cso.att.com (sflint03.pst.cso.att.com [144.154.234.230]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q3GDihSI016346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Apr 2012 09:44:55 -0400 Received: from GAALPA1MSGHUB9F.ITServices.sbc.com (gaalpa1msghub9f.itservices.sbc.com [130.8.36.92]) by sflint03.pst.cso.att.com (RSA Interceptor); Mon, 16 Apr 2012 09:43:34 -0400 Received: from GAALPA1MSGUSR9N.ITServices.sbc.com ([169.254.6.49]) by GAALPA1MSGHUB9F.ITServices.sbc.com ([130.8.36.92]) with mapi id 14.01.0355.002; Mon, 16 Apr 2012 09:43:34 -0400 From: "STARK, BARBARA H" To: Francis Dupont , Fred Baker Thread-Topic: [v6ops] draft-ietf-v6ops-6204bis WGLC Thread-Index: AQHNG8gUB4s8FsbG5EywClt4abKfyJadcBTg Date: Mon, 16 Apr 2012 13:43:34 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E61109F6E5@GAALPA1MSGUSR9N.ITServices.sbc.com> References: Your message of Sun, 15 Apr 2012 13:54:00 PDT. <2FEFE40E-25F2-4D02-A608-0CADCBBAAE9C@cisco.com> <201204161157.q3GBvMXE088261@givry.fdupont.fr> In-Reply-To: <201204161157.q3GBvMXE088261@givry.fdupont.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.53.199] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=1.0 c=1 a=l9k3qgFx0ZYA:10 a=ClSQgxFuTdMA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=Qs8R1XBwmid1qB] X-AnalysisOut: [FB/a8mmA==:17 a=4tDh4rnD0dllaW-02DUA:9 a=7NOg5b9A3oPZX5LwM] X-AnalysisOut: [O4A:7 a=CjuIK1q_8ugA:10] Cc: "v6ops@ietf.org" , "v6ops-chairs@tools.ietf.org" , Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 13:45:19 -0000 > =3D> I have still a concern about W-6: >=20 > W-6: The WAN interface of the CE router SHOULD support a PCP client > as specified in [I-D.ietf-pcp-base] for use by applications on > the CE Router. The PCP client SHOULD follow the procedure > specified in Section 8.1 of [I-D.ietf-pcp-base] to discover its > PCP server. This document takes no position on whether such > functionality is enabled by default or mechanisms by which > users would configure the functionality. Handling PCP requests > from PCP clients in the LAN side of the CE Router is out of > scope. >=20 > for at least two reasons: > - there are other protocols than PCP which provides the function, > for instance UPnP IGD v2. For any protocol like this to be effective, the server side must exist. Sin= ce this is a CE router spec that is focusing just on changes to the 6204-de= fined WAN interface, the server side must exist in the access network. A nu= mber of European service providers have stated that they intend to provide = a PCP server in conjunction with DS-Lite. I have heard no service providers= say that there is an intention to support any other protocol. I will not s= upport any recommendation to CE router vendors to include functionality tha= t will be useless, due to lack of existence of the server function in the a= ccess network. Please note, that I fully support the CE router having a LAN= -facing UPnP IGD:2 server in it -- but I consider that to be outside the sc= ope of 6204bis. As someone who is very much involved (and has put a lot of = time and effort) in trying to get IPv6 into UPnP, I believe strongly in UPn= P -- inside the LAN. > - there is no known example of a router application which needs the > function I believe FT-Orange and Telecom Italia have both spoken about their need fo= r this function. Perhaps they could do so again, to refresh our memories. > So I propose to step back to what was in RFC 6204, i.e., simply remove W-= 6 > (and the PCP reference). When it was suggested that PCP be mentioned in this draft, I stated that I = would only be in favor if it did not cause problems with getting 6204bis ap= proved. If multiple people have problems with the PCP, then it does needs t= o go. And I absolutely will not support including requirements around LAN-s= ide functionality or inter-working functions, as I consider that to be the = realm of homenet. This is focused on the WAN. Barbara From cb.list6@gmail.com Mon Apr 16 06:52:06 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27F1B21F85B6 for ; Mon, 16 Apr 2012 06:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.806 X-Spam-Level: X-Spam-Status: No, score=-2.806 tagged_above=-999 required=5 tests=[AWL=-0.748, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N8OubsNsO1qm for ; Mon, 16 Apr 2012 06:52:05 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 30D0D21F859E for ; Mon, 16 Apr 2012 06:52:05 -0700 (PDT) Received: by dady13 with SMTP id y13so9590069dad.27 for ; Mon, 16 Apr 2012 06:52:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=D2No02c9D1sb4bWuUr3qin7IADNzmdtMuwMEJ78zE40=; b=pmhGNyaBUC1mVfR9i7d2ufBSHn47ZrdO1FhozOFLCP8eOnyjRITPzcsSodpNAiVnMT jftQz6YJbnKH6wmRjlhUbmEE5yr2aWbeN0dNYiZ56b47KASqjk1oqo9gps/ViloUsw8g fZbwDdJm1SoilGlxvnROL71umrmey6YHjV4TksZqgV3Vc9P//5E3bT0lwL8MKdVXHiBp sxchBPd25qvEtm4MU6ou2HY9vLoFl7rmo0eudaUElSBIMILu0rzkX/Pjtz46BAEDUE3w YpszokAbpL4pcGsmdJGgGeMMVLTRvblNgjgcs9eWLrg3s6ybjAXZVODMX2qjeUfxX9Xx NiCA== MIME-Version: 1.0 Received: by 10.68.195.163 with SMTP id if3mr27838208pbc.127.1334584324903; Mon, 16 Apr 2012 06:52:04 -0700 (PDT) Received: by 10.142.102.1 with HTTP; Mon, 16 Apr 2012 06:52:04 -0700 (PDT) Received: by 10.142.102.1 with HTTP; Mon, 16 Apr 2012 06:52:04 -0700 (PDT) In-Reply-To: <986EAD24-4612-4AD0-B366-012BA0B3751C@laposte.net> References: <7E1BD96D-E7EC-4C78-B382-66F0F694DAA4@laposte.net> <1825062D-D4EB-4310-A2BA-8B8F3870B9B4@laposte.net> <22BD6607-5DEC-48F3-B2E5-DCEECC9EF643@laposte.net> <986EAD24-4612-4AD0-B366-012BA0B3751C@laposte.net> Date: Mon, 16 Apr 2012 06:52:04 -0700 Message-ID: From: Cameron Byrne To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=e89a8ffbad5f9bd4b304bdcc2070 Cc: v6ops WG , Teemu Savolainen , Bill Huang Subject: Re: [v6ops] A way forward for 464XLAT - using BIH X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 13:52:06 -0000 --e89a8ffbad5f9bd4b304bdcc2070 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Apr 16, 2012 2:51 AM, "R=E9mi Despr=E9s" wrot= e: > > > Le 2012-04-16 =E0 11:33, Lorenzo Colitti a =E9crit : > >> On Mon, Apr 16, 2012 at 17:57, R=E9mi Despr=E9s wrote: >>> >>> The best approach IMHO would be a BCP just explaining that BIH, used with RFC6052 for v4-v6 address translation, is now recommended for IPv4-only-application support via networks supporting stateful NAT64s (without developing other ways to get a similar result). >>> >>> Whether such a use case should have its own name, such as 464XLAT, is an open question AFAIAC but, provided the BCP is as simple as it can be, I personally don't care. >> >> >> But it wouldn't necessarily be an application scenario of BIH. It could just as well be an application scenario for RFC 6145 and RFC 6146, right? > > > The BIH-NAT64 scenario uses only a subset of BIH functions, right. > But: > - Other BIH functions are useful (IPv4-only applications using IPv6-only servers) > - BIH specifies which local IPv4 addresses are seen by applications without interfering with the host IPv6 address format. > > For a short term validation of the RFC6535-RFC6052 combination, I personally ignore whether there is open-source BIH code, and whether some devices could be used for a test. > Copies of this mail to RFC6535 are added to know more. > > >> In either case there needs to be a BCP. > > > Same view, > I may be missing something but socket level usually means using sockets and local network stack API. NAT functions like RFC 6145 do not operate like BIH. Right? Local host sockets are not used. Perhaps bih fits a proxy model, not a Nat model. 464xlat operates as defined in RFC 6145, not BIH. Is there a problem with how 464xlat is defined? I see no compelling reason to add bih, as the 464xlat definition is complete with 6145. Cb > RD > --e89a8ffbad5f9bd4b304bdcc2070 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Apr 16, 2012 2:51 AM, "R=E9mi Despr=E9s" <despres.remi@laposte.net> wrote:
>
>
> Le 2012-04-16 =E0 11:33, Lorenzo Colitti a =E9crit :
>
>> On Mon, Apr 16, 2012 at 17:57, R=E9mi Despr=E9s <despres.remi@laposte.net> wrote:
>>>
>>> The best approach IMHO would be a BCP just explaining that BIH= , used with RFC6052 for v4-v6 address translation, is now recommended for= =A0IPv4-only-application support via networks supporting=A0stateful NAT64s = (without developing other ways to get a similar result).
>>>
>>> Whether such a use case should have its own name, such as 464X= LAT, is an open question AFAIAC but, provided the BCP is as simple as it ca= n be, I personally don't care.
>>
>>
>> But it wouldn't necessarily be an application scenario of BIH.= It could just as well be an application scenario for=A0RFC 6145 and RFC 61= 46, right?
>
>
> The BIH-NAT64 scenario uses only a subset of BIH functions, right.
> But:
> - Other BIH functions are useful (IPv4-only applications using IPv6-on= ly servers)
> - BIH specifies which local IPv4 addresses are seen by applications wi= thout interfering with the host IPv6 address format.=A0
>
> For a short term validation of the RFC6535-RFC6052 combination, I pers= onally ignore whether there is open-source BIH code, and whether some devic= es could be used for a test.=A0
> Copies of this mail to RFC6535 are added to know more.
>
>
>> In either case there needs to be a BCP.
>
>
> Same view,
>

I may be missing something but socket level usually means using sockets = and local network stack API.=A0

NAT functions like RFC 6145 do not operate like BIH. Right? Local host s= ockets are not used. Perhaps bih fits a proxy model, not a Nat model.

464xlat operates as defined in RFC 6145, not BIH.=A0

Is there a problem with how 464xlat is defined?=A0 I see no compelling r= eason to add bih, as the 464xlat definition is complete with 6145.

Cb

> RD
>

--e89a8ffbad5f9bd4b304bdcc2070-- From wdec.ietf@gmail.com Mon Apr 16 07:00:29 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EC5E21F8659 for ; Mon, 16 Apr 2012 07:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=-0.770, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O61mtvymkZaa for ; Mon, 16 Apr 2012 07:00:28 -0700 (PDT) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) by ietfa.amsl.com (Postfix) with ESMTP id 888E421F862F for ; Mon, 16 Apr 2012 07:00:27 -0700 (PDT) Received: by qafi31 with SMTP id i31so7011824qaf.15 for ; Mon, 16 Apr 2012 07:00:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=G+QL1PYtru+746OI4bFyf5eotbrKmn7MVB6F3v9RGxI=; b=cgfMk0u/IT15w5Yo1S0SEhFHzNq5ciIBiojrXLiuJ3mvvqh7N2+fNMEAcnBW64Ld/p dx21VEq1RndLgK5kHjfqKPiWq7jTrAzs98LTDqjROeO6L9kDaRA2kYw/pmkRdpDNErNV 580wfmnCOKEz5wIKfHBkScLuRrDPsy4Gxb1OLdf4cdIEu6z98lvETaYEIyv224gzA9on QaqU0miF1lMgmVonlT7TsTN+i20fRQH6Y6QhqfT/if+8QpGG/nX7T8X6jDMMnf+yLsLF PLSqbGVaGVl6fc+PP4p852Sdtmc4SAGTokEtANOCE34pONjIijxp1A6jHTUA1vqYQ+O+ 9dTw== MIME-Version: 1.0 Received: by 10.224.179.201 with SMTP id br9mr15479230qab.34.1334584826936; Mon, 16 Apr 2012 07:00:26 -0700 (PDT) Received: by 10.229.95.199 with HTTP; Mon, 16 Apr 2012 07:00:26 -0700 (PDT) In-Reply-To: References: <7E1BD96D-E7EC-4C78-B382-66F0F694DAA4@laposte.net> <1825062D-D4EB-4310-A2BA-8B8F3870B9B4@laposte.net> <22BD6607-5DEC-48F3-B2E5-DCEECC9EF643@laposte.net> <986EAD24-4612-4AD0-B366-012BA0B3751C@laposte.net> Date: Mon, 16 Apr 2012 16:00:26 +0200 Message-ID: From: Wojciech Dec To: Cameron Byrne Content-Type: multipart/alternative; boundary=20cf30334fd9883d9e04bdcc3edf Cc: v6ops WG , Bill Huang , Teemu Savolainen Subject: Re: [v6ops] A way forward for 464XLAT - using BIH X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 14:00:29 -0000 --20cf30334fd9883d9e04bdcc3edf Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 16 April 2012 15:52, Cameron Byrne wrote: > > On Apr 16, 2012 2:51 AM, "R=E9mi Despr=E9s" wr= ote: > > > > > > Le 2012-04-16 =E0 11:33, Lorenzo Colitti a =E9crit : > > > >> On Mon, Apr 16, 2012 at 17:57, R=E9mi Despr=E9s > wrote: > >>> > >>> The best approach IMHO would be a BCP just explaining that BIH, used > with RFC6052 for v4-v6 address translation, is now recommended > for IPv4-only-application support via networks supporting stateful NAT64s > (without developing other ways to get a similar result). > >>> > >>> Whether such a use case should have its own name, such as 464XLAT, is > an open question AFAIAC but, provided the BCP is as simple as it can be, = I > personally don't care. > >> > >> > >> But it wouldn't necessarily be an application scenario of BIH. It coul= d > just as well be an application scenario for RFC 6145 and RFC 6146, right? > > > > > > The BIH-NAT64 scenario uses only a subset of BIH functions, right. > > But: > > - Other BIH functions are useful (IPv4-only applications using IPv6-onl= y > servers) > > - BIH specifies which local IPv4 addresses are seen by applications > without interfering with the host IPv6 address format. > > > > For a short term validation of the RFC6535-RFC6052 combination, I > personally ignore whether there is open-source BIH code, and whether some > devices could be used for a test. > > Copies of this mail to RFC6535 are added to know more. > > > > > >> In either case there needs to be a BCP. > > > > > > Same view, > > > > I may be missing something but socket level usually means using sockets > and local network stack API. > > NAT functions like RFC 6145 do not operate like BIH. Right? Local host > sockets are not used. Perhaps bih fits a proxy model, not a Nat model. > > 464xlat operates as defined in RFC 6145, not BIH. > > Is there a problem with how 464xlat is defined? I see no compelling > reason to add bih, as the 464xlat definition is complete with 6145. > +1 The working of BIH to support a tethered host, ie BIH at the network layer, appears to be substantially different than with plain 6145/464xlat. -Woj. > Cb > > > RD > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --20cf30334fd9883d9e04bdcc3edf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On 16 April 2012 15:52, Cameron = Byrne <cb.list6@= gmail.com> wrote:


On Apr 16, 2012 2:51 AM, "R=E9mi Despr=E9s" <despres.remi@laposte.net&g= t; wrote:
>
>
> Le 2012-04-16 =E0 11:33, Lorenzo Colitti a =E9crit :
>
>> On Mon, Apr 16, 2012 at 17:57, R=E9mi Despr=E9s <despres.remi@laposte.net> wrote:
>>>
>>> The best approach IMHO would be a BCP just explaining that BIH= , used with RFC6052 for v4-v6 address translation, is now recommended for= =A0IPv4-only-application support via networks supporting=A0stateful NAT64s = (without developing other ways to get a similar result).
>>>
>>> Whether such a use case should have its own name, such as 464X= LAT, is an open question AFAIAC but, provided the BCP is as simple as it ca= n be, I personally don't care.
>>
>>
>> But it wouldn't necessarily be an application scenario of BIH.= It could just as well be an application scenario for=A0RFC 6145 and RFC 61= 46, right?
>
>
> The BIH-NAT64 scenario uses only a subset of BIH functions, right.
> But:
> - Other BIH functions are useful (IPv4-only applications using IPv6-on= ly servers)
> - BIH specifies which local IPv4 addresses are seen by applications wi= thout interfering with the host IPv6 address format.=A0
>
> For a short term validation of the RFC6535-RFC6052 combination, I pers= onally ignore whether there is open-source BIH code, and whether some devic= es could be used for a test.=A0
> Copies of this mail to RFC6535 are added to know more.
>
>
>> In either case there needs to be a BCP.
>
>
> Same view,
>

I may be missing something but socket level usually means us= ing sockets and local network stack API.=A0

NAT functions like RFC 6145 do not operate like BIH. Right? Local host s= ockets are not used. Perhaps bih fits a proxy model, not a Nat model.

464xlat operates as defined in RFC 6145, not BIH.=A0

Is there a problem with how 464xlat is defined?=A0 I see no compelling r= eason to add bih, as the 464xlat definition is complete with 6145.


+1 The working of BIH to support a tethered host, ie BIH = at the network layer, appears to be substantially different than with plain= 6145/464xlat.

-Woj.

Cb

> RD
>


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


--20cf30334fd9883d9e04bdcc3edf-- From tom.taylor.stds@gmail.com Mon Apr 16 07:32:02 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D35B821F85C2 for ; Mon, 16 Apr 2012 07:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.044 X-Spam-Level: X-Spam-Status: No, score=-3.044 tagged_above=-999 required=5 tests=[AWL=-0.045, 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 5lowhoJiSPpS for ; Mon, 16 Apr 2012 07:32:02 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id DA5A421F85A3 for ; Mon, 16 Apr 2012 07:32:01 -0700 (PDT) Received: by lbbgf14 with SMTP id gf14so2136666lbb.31 for ; Mon, 16 Apr 2012 07:32:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-antivirus:x-antivirus-status; bh=EdmsLOfUfEb2ZT9auSeq3PPXRpWuK5r6I0sEZ2MGYx8=; b=WIwGyPazrQCPVfIb9zw2P34zxwMbcfkaBlITYw3a+PPJWUDjfq2yngkjB5/G6tx1y3 F65izaTj9qyEME9jCuFz+w3E2SgcIK6xs6muSHB3wejjeVyl5YV0JsXLE0UDQvsdFoo2 +eAiVDBmu656oks8Q+7nI1RJadaHdy8zPOD4OwIkemIENIMpC8DHXUcCPpAzCqWab+VL ntukxHg2+Ex3ks289xPGkT2DC+D9hEtzsZCJMdDy8lHAujHeRUPfl1m7oToxpVoJpQlS +XqM1hdecp5T9xwYnru/r6wAHyAwjTj2VDqIxU+j7r7tn9163xMacLY95gmp+/g6Pe3A ICig== Received: by 10.112.100.68 with SMTP id ew4mr5185720lbb.104.1334586720813; Mon, 16 Apr 2012 07:32:00 -0700 (PDT) Received: from [127.0.0.1] (dsl-207-112-91-137.tor.primus.ca. [207.112.91.137]) by mx.google.com with ESMTPS id te8sm19587730lab.3.2012.04.16.07.31.56 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 16 Apr 2012 07:31:59 -0700 (PDT) Message-ID: <4F8C2D58.8010402@gmail.com> Date: Mon, 16 Apr 2012 10:31:52 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: v6ops@ietf.org References: <201204161157.q3GBvMXE088261@givry.fdupont.fr> In-Reply-To: <201204161157.q3GBvMXE088261@givry.fdupont.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 120416-0, 16/04/2012), Outbound message X-Antivirus-Status: Clean Cc: Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC -- PCP requirement X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 14:32:02 -0000 This point was discussed in the PCP meeting. While Francis's view seemed to be in the minority, I found it logically compelling. The applications that were described in the meeting that would find it useful were really host functions that happened to be resident on the CPE. Hence implementation of a PCP client would be the task of the people implementing those functions, rather than of the CE Router developers. On the other hand, Barbara mentions interest in its application for DS-Lite. Delving into the PCP-related documents, I note draft-dupont-pcp-dslite, which advocates implementation of a PCP proxy rather than PCP client function in the CE Router. In the PCP base document itself, the main discussion of DS-Lite usage comes in the Security Considerations section, in association with the use of the THIRD_PARTY option. Security issues surrounding use of the THIRD_PARTY option are holding up approval of the PCP base document. The main thrust of the existing DS-Lite discussion in the PCP base document is to say that use of THIRD_PARTY is safe in the DS-Lite case. I'm sure there are earnest discussions going on behind the scenes to get the concerns about THIRD_PARTY resolved. As an outside observer, however, I see various issues around inclusion of a reference to PCP in 6204bis at this time, in terms both of the appropriate technical approach and approval of the specifications. Tom Taylor On 16/04/2012 7:57 AM, Francis Dupont wrote: > In your previous mail you wrote: > >> This is to initiate a ONE week working group last call of >> draft-ietf-v6ops-6204bis > > => I have still a concern about W-6: > > W-6: The WAN interface of the CE router SHOULD support a PCP client > as specified in [I-D.ietf-pcp-base] for use by applications on > the CE Router. The PCP client SHOULD follow the procedure > specified in Section 8.1 of [I-D.ietf-pcp-base] to discover its > PCP server. This document takes no position on whether such > functionality is enabled by default or mechanisms by which > users would configure the functionality. Handling PCP requests > from PCP clients in the LAN side of the CE Router is out of > scope. > > for at least two reasons: > - there are other protocols than PCP which provides the function, > for instance UPnP IGD v2. > > - there is no known example of a router application which needs the > function > > So I propose to step back to what was in RFC 6204, i.e., simply > remove W-6 (and the PCP reference). > > Note if the last sentence about the LAN side changes of course > W-6 (with another wording) could make sense again. > > Regards > > Francis.Dupont@fdupont.fr > > PS: the draft should be written in US English so without the 'e' > in Acknowledgements. > ^ > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From denghui02@gmail.com Mon Apr 16 07:47:16 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ABFC21F85CC for ; Mon, 16 Apr 2012 07:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.933 X-Spam-Level: X-Spam-Status: No, score=-102.933 tagged_above=-999 required=5 tests=[AWL=-0.575, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CKKqb3d14HZ6 for ; Mon, 16 Apr 2012 07:47:15 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 57FA821F85BB for ; Mon, 16 Apr 2012 07:47:15 -0700 (PDT) Received: by yenm5 with SMTP id m5so2812407yen.31 for ; Mon, 16 Apr 2012 07:47:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DxSi7v1JRLnDZWTNtq0BMja32tgngyWksVeNG7xrxB8=; b=0z7Ogox7rVri7t84IdpapOp+Vaf3Uf9pz3pOOsCGHCabOE9HgC37TrZGdDZHZ/ucgS tjnFFebpn2IQCXZr5Fsngs0MR2v4xnNC/YeTE7NG+jLhEZzXTKHXmaGyWWh+KoqEporl k6jLUioIhAVM+25r5qzfrWk6DGiYsglzBXRJFC5kxpR5Mu4KO2kpH7tBWa5u1/jLSXgY F7vEQII2q1u32zo43ndFPBMuUDBNPiKxG5ePdaq8/Bh+3gS8ohu3xCl2fhtq8CWCdCVd f+EqSUNBnh6gm0tBUBw/oKM5mAv/AAbzJHWoE8BmdZyBjvMlxu/qAV3ryXYfKoAu22M3 IxrQ== MIME-Version: 1.0 Received: by 10.236.170.71 with SMTP id o47mr11417086yhl.104.1334587634982; Mon, 16 Apr 2012 07:47:14 -0700 (PDT) Received: by 10.146.20.14 with HTTP; Mon, 16 Apr 2012 07:47:14 -0700 (PDT) In-Reply-To: References: <7E1BD96D-E7EC-4C78-B382-66F0F694DAA4@laposte.net> <1825062D-D4EB-4310-A2BA-8B8F3870B9B4@laposte.net> <22BD6607-5DEC-48F3-B2E5-DCEECC9EF643@laposte.net> <986EAD24-4612-4AD0-B366-012BA0B3751C@laposte.net> Date: Mon, 16 Apr 2012 22:47:14 +0800 Message-ID: From: Hui Deng To: Cameron Byrne Content-Type: multipart/alternative; boundary=20cf302d4c36e7a01204bdcce5e4 Cc: Teemu Savolainen , v6ops WG , Bill Huang Subject: Re: [v6ops] A way forward for 464XLAT - using BIH X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 14:47:16 -0000 --20cf302d4c36e7a01204bdcce5e4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cameron, You could say BIH socket fit proxy model, but BIH header translation does NAT model. I can see Remi's point that once BIH get a real IPv4 address, it could work with RFC 6052, It does the same as 464xlat. Best, -Hui 2012/4/16 Cameron Byrne > > On Apr 16, 2012 2:51 AM, "R=E9mi Despr=E9s" wr= ote: > > > > > > Le 2012-04-16 =E0 11:33, Lorenzo Colitti a =E9crit : > > > >> On Mon, Apr 16, 2012 at 17:57, R=E9mi Despr=E9s > wrote: > >>> > >>> The best approach IMHO would be a BCP just explaining that BIH, used > with RFC6052 for v4-v6 address translation, is now recommended > for IPv4-only-application support via networks supporting stateful NAT64s > (without developing other ways to get a similar result). > >>> > >>> Whether such a use case should have its own name, such as 464XLAT, is > an open question AFAIAC but, provided the BCP is as simple as it can be, = I > personally don't care. > >> > >> > >> But it wouldn't necessarily be an application scenario of BIH. It coul= d > just as well be an application scenario for RFC 6145 and RFC 6146, right? > > > > > > The BIH-NAT64 scenario uses only a subset of BIH functions, right. > > But: > > - Other BIH functions are useful (IPv4-only applications using IPv6-onl= y > servers) > > - BIH specifies which local IPv4 addresses are seen by applications > without interfering with the host IPv6 address format. > > > > For a short term validation of the RFC6535-RFC6052 combination, I > personally ignore whether there is open-source BIH code, and whether some > devices could be used for a test. > > Copies of this mail to RFC6535 are added to know more. > > > > > >> In either case there needs to be a BCP. > > > > > > Same view, > > > > I may be missing something but socket level usually means using sockets > and local network stack API. > > NAT functions like RFC 6145 do not operate like BIH. Right? Local host > sockets are not used. Perhaps bih fits a proxy model, not a Nat model. > > 464xlat operates as defined in RFC 6145, not BIH. > > Is there a problem with how 464xlat is defined? I see no compelling > reason to add bih, as the 464xlat definition is complete with 6145. > > Cb > > > RD > > > --20cf302d4c36e7a01204bdcce5e4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Cameron,
=A0
You could say BIH socket fit proxy model, but BIH header translation d= oes NAT model.
=A0
I can see Remi's point that once BIH get a real IPv4 address, it c= ould work with RFC 6052,
It does the same as 464xlat.
=A0
Best,
=A0
-Hui

2012/4/16 Cameron Byrne <cb.list6@gmail.com>


On Apr 16, 2012 2:51 AM, "R=E9mi Despr=E9s" <despres.remi@laposte.ne= t> wrote:
>
>
> Le 2012-04-16 =E0 11:33, Lorenzo C= olitti a =E9crit :
>
>> On Mon, Apr 16, 2012 at 17:57, R=E9mi Despr=E9s <despres.remi@lapost= e.net> wrote:
>>>
>>> The best approach IMHO= would be a BCP just explaining that BIH, used with RFC6052 for v4-v6 addre= ss translation, is now recommended for=A0IPv4-only-application support via = networks supporting=A0stateful NAT64s (without developing other ways to get= a similar result).
>>>
>>> Whether such a use case should have its own na= me, such as 464XLAT, is an open question AFAIAC but, provided the BCP is as= simple as it can be, I personally don't care.
>>
>><= br> >> But it wouldn't necessarily be an application scenario of BIH.= It could just as well be an application scenario for=A0RFC 6145 and RFC 61= 46, right?
>
>
> The BIH-NAT64 scenario uses only a subse= t of BIH functions, right.
> But:
> - Other BIH functions are useful (IPv4-only applications = using IPv6-only servers)
> - BIH specifies which local IPv4 addresses= are seen by applications without interfering with the host IPv6 address fo= rmat.=A0
>
> For a short term validation of the RFC6535-RFC6052 combination= , I personally ignore whether there is open-source BIH code, and whether so= me devices could be used for a test.=A0
> Copies of this mail to RFC6= 535 are added to know more.
>
>
>> In either case there needs to be a BCP.
>>
> Same view,
>

I may be missing something but socket level usually means using sockets = and local network stack API.=A0

NAT functions like RFC 6145 do not operate like BIH. Right? Local host s= ockets are not used. Perhaps bih fits a proxy model, not a Nat model.

464xlat operates as defined in RFC 6145, not BIH.=A0

Is there a problem with how 464xlat is defined?=A0 I see no compelling r= eason to add bih, as the 464xlat definition is complete with 6145.

Cb

> RD
>


--20cf302d4c36e7a01204bdcce5e4-- From simon.perreault@viagenie.ca Mon Apr 16 07:49:48 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB8B21F85D9 for ; Mon, 16 Apr 2012 07:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1VqEp5B2thOi for ; Mon, 16 Apr 2012 07:49:47 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id CE59A21F85CC for ; Mon, 16 Apr 2012 07:49:47 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:295d:da63:7323:ef17]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 3F958415D0 for ; Mon, 16 Apr 2012 10:49:47 -0400 (EDT) Message-ID: <4F8C318A.4050601@viagenie.ca> Date: Mon, 16 Apr 2012 10:49:46 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: v6ops@ietf.org References: <201204161157.q3GBvMXE088261@givry.fdupont.fr> <4F8C2D58.8010402@gmail.com> In-Reply-To: <4F8C2D58.8010402@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC -- PCP requirement X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 14:49:48 -0000 On 2012-04-16 10:31, Tom Taylor wrote: > This point was discussed in the PCP meeting. While Francis's view seemed > to be in the minority, I found it logically compelling. The applications > that were described in the meeting that would find it useful were really > host functions that happened to be resident on the CPE. Hence > implementation of a PCP client would be the task of the people > implementing those functions, rather than of the CE Router developers. Isn't the set of "people implementing those functions" a subset of "CE Router developers"? 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 denghui02@gmail.com Mon Apr 16 07:54:45 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD2F411E8085 for ; Mon, 16 Apr 2012 07:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.471 X-Spam-Level: X-Spam-Status: No, score=-103.471 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kDrbnbkX9M-N for ; Mon, 16 Apr 2012 07:54:45 -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 D33A711E8083 for ; Mon, 16 Apr 2012 07:54:44 -0700 (PDT) Received: by yhkk25 with SMTP id k25so2800761yhk.31 for ; Mon, 16 Apr 2012 07:54:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=1pOTEqdhdoYq0ah3zZepq7Vijp9Mz+monVRCpxhSFEI=; b=qRb82V0FmFueMIpB6eafNP9N4IlmWeBZThoeUPH5u9pwhp5WD/S7/7SdJ8GTuIviXA EtTyVLLcivzgePEvpoWMH5OSl769lYxkmKjDGCjcTX6ty/1bxerXSbKq8S64ehyvX5Pn ZTcEf2bLbxZeMmf6GiOQ2+Z8nnCE/sXRcMh3w3lyJbQWyQKDp+ndb5w5y7THl+Rx3vVu GO5D0IYkSg5/PPhEvCNIBILX3qGCKi1o2Hg6YZB52bGlGBJbUdKyM+qgVNQX/n1tIvi2 inQSvdhQ8axj613PP/EQEJ6vDif4h/nOIa96txQBumKNF9IkSH0msnorl1ACj1RkW10x XwKQ== MIME-Version: 1.0 Received: by 10.236.114.169 with SMTP id c29mr11484788yhh.37.1334588084341; Mon, 16 Apr 2012 07:54:44 -0700 (PDT) Received: by 10.146.20.14 with HTTP; Mon, 16 Apr 2012 07:54:44 -0700 (PDT) Date: Mon, 16 Apr 2012 22:54:44 +0800 Message-ID: From: Hui Deng To: Cameron Byrne Content-Type: multipart/alternative; boundary=bcaec5431464b04b8c04bdcd00ae Cc: Teemu Savolainen , v6ops WG , Bill Huang Subject: [v6ops] BIH open 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: Mon, 16 Apr 2012 14:54:46 -0000 --bcaec5431464b04b8c04bdcd00ae Content-Type: text/plain; charset=ISO-8859-1 Hello all Please be aware of open source for BIH as below: http://code.google.com/p/bump-in-the-host/source/ Feel free to let us know if you have any questions. Best, -Hui --bcaec5431464b04b8c04bdcd00ae Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello all
=A0
Please be aware of open source for BIH as below:
=A0
Feel free to let us know if you have any questions.
=A0
Best,
=A0
-Hui
--bcaec5431464b04b8c04bdcd00ae-- From lorenzo@google.com Mon Apr 16 07:56:02 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A10211E8076 for ; Mon, 16 Apr 2012 07:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.89 X-Spam-Level: X-Spam-Status: No, score=-102.89 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZErLgBq8-rBm for ; Mon, 16 Apr 2012 07:56:01 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id C45D911E8072 for ; Mon, 16 Apr 2012 07:56:01 -0700 (PDT) Received: by yenm5 with SMTP id m5so2821420yen.31 for ; Mon, 16 Apr 2012 07:56:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=ONZQIB8zPKkDM+23/WxLsm8oUaUmzarbO2JiGle6D/c=; b=fh6m2pQ2oiTx2ZoDMvCj24Mb6QvvmlsLvnxihJ6pGlfbaG7iWhjIcimYQNvw6SNIuv bPShacGW3ZF+mF6Osdt60j/xBOHJwC2rf+ktds8blmL02buJ1saGSmL9/8zKCH2tb/n1 mv+qu0VdYIpnGASSLCqJTOpcUn/w8JKu/JNn2gyOcevNKurnw8XKdeyB9flx9msIWq0D vmjyhU2+AeTJ7Twe3TpxMHnKZwVJ93EKwUnjW/u74I7DDQ+O/0xM4IpAm5fhFV1T2mvP QMVayTFQcW0fkg2scd7VuCOr34xYDHpEe3a9l8KvT1pFnabm76GKZxNfcBEnyFR+0uLF dA1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=ONZQIB8zPKkDM+23/WxLsm8oUaUmzarbO2JiGle6D/c=; b=S0f4JGHoA09ElayB1tPvqUt6hSlDHDW0+s08x2WyBiGcLf3FczJ1RofizO6aF/gXeH DFOzgXAc/sIpVjQ2b1Dokm2tlQTbgZXdsJOFmnUNB38wm4/gOaH4Jdyp9XlfAYZeRQCN fPPEiWOp0Pb0fUpqlOLZy+bLxD1kER75Itd/MY060n1N8Z2B27Wg3S8Upp3/0RtyMdfC LWSFFsJmJe2Dba8G2LgevFPN2/454KrVSoCWOvadRy/eiSS02kxm7mG5DxXBEenwU+YR sMYGIqtoWNHgluDt+wrwHgR13hhH2OmXsBUBTw/dhPz7oZkki3HmsoH27p53JStNpPco rl3g== Received: by 10.182.44.97 with SMTP id d1mr10085922obm.28.1334588161359; Mon, 16 Apr 2012 07:56:01 -0700 (PDT) Received: by 10.182.44.97 with SMTP id d1mr10085897obm.28.1334588161232; Mon, 16 Apr 2012 07:56:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.220.3 with HTTP; Mon, 16 Apr 2012 07:55:40 -0700 (PDT) In-Reply-To: References: <7E1BD96D-E7EC-4C78-B382-66F0F694DAA4@laposte.net> <1825062D-D4EB-4310-A2BA-8B8F3870B9B4@laposte.net> <22BD6607-5DEC-48F3-B2E5-DCEECC9EF643@laposte.net> <986EAD24-4612-4AD0-B366-012BA0B3751C@laposte.net> From: Lorenzo Colitti Date: Mon, 16 Apr 2012 23:55:40 +0900 Message-ID: To: Hui Deng Content-Type: multipart/alternative; boundary=f46d0447a14d4590c904bdcd0554 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkspKuOhK28UaaAAKF0id9l5FH1byh9/7CbKGwLpysimmCVhDWwCI/wePk2PR5Q2rc7+lrkLN2Mocvyw2et128RfrgjZhIcjG7nXr+RTL8UmFeqzUJvxHMv/EM4it2GqMBAcGKn Cc: Teemu Savolainen , Bill Huang , v6ops WG Subject: Re: [v6ops] A way forward for 464XLAT - using BIH X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 14:56:02 -0000 --f46d0447a14d4590c904bdcd0554 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Apr 16, 2012 at 23:47, Hui Deng wrote: > I can see Remi's point that once BIH get a real IPv4 address, it could > work with RFC 6052, > It does the same as 464xlat. > What does "get a real IPv4 address" mean? Apologies if this is already clear to everyone else. --f46d0447a14d4590c904bdcd0554 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Apr 16, 2012 at 23:47, Hui Deng <denghui02@gmail.com> wrote:
I can see Remi's point that once BIH get a real IPv4 address, it c= ould work with RFC 6052,
It does the same as 464xlat.

Wha= t does "get a real IPv4 address" mean? Apologies if this is alrea= dy clear to everyone else.
--f46d0447a14d4590c904bdcd0554-- From despres.remi@laposte.net Mon Apr 16 08:06:53 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E68A11E8072 for ; Mon, 16 Apr 2012 08:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.216 X-Spam-Level: X-Spam-Status: No, score=-2.216 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, 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 TQcIzsSY0soe for ; Mon, 16 Apr 2012 08:06:52 -0700 (PDT) Received: from smtpout.laposte.net (smtpout1.laposte.net [193.253.67.226]) by ietfa.amsl.com (Postfix) with ESMTP id 5272111E8073 for ; Mon, 16 Apr 2012 08:06:51 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8502-out with ME id yf6m1i00137Y3f403f6mpN; Mon, 16 Apr 2012 17:06:50 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-17--200679393 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Mon, 16 Apr 2012 17:06:46 +0200 Message-Id: <86590F14-9C49-48AB-B73F-9BA44A58A467@laposte.net> References: <7E1BD96D-E7EC-4C78-B382-66F0F694DAA4@laposte.net> <1825062D-D4EB-4310-A2BA-8B8F3870B9B4@laposte.net> <22BD6607-5DEC-48F3-B2E5-DCEECC9EF643@laposte.net> <986EAD24-4612-4AD0-B366-012BA0B3751C@laposte.net> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) Cc: v6ops WG , Bill Huang , Teemu Savolainen Subject: Re: [v6ops] A way forward for 464XLAT - using BIH X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 15:06:53 -0000 --Apple-Mail-17--200679393 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-04-16 =E0 16:55, Lorenzo Colitti a =E9crit : > On Mon, Apr 16, 2012 at 23:47, Hui Deng wrote: > I can see Remi's point that once BIH get a real IPv4 address, it could = work with RFC 6052, > It does the same as 464xlat. >=20 > What does "get a real IPv4 address" mean? Sec 2.3 of RFC6535 says: "if a DNS A record reply contains non-excluded real IPv4 addresses, the = ENR MUST NOT synthesize IPv4 addresses." In this case, the remote host IPv6 address has to be obtained according = to 6052 (like in RFC6145) The other case is where the remote-host IPv4 address used by an IPv4 = application is a referral. Hope it clarifies. RD --Apple-Mail-17--200679393 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On Mon, Apr 16, 2012 at 23:47, = Hui Deng <denghui02@gmail.com> = wrote:
I can see Remi's point that once BIH get a real IPv4 address, it = could work with RFC 6052,
It does the same as = 464xlat.

What does "get a real = IPv4 address" mean?

Sec 2.3 = of RFC6535 says:
"if a DNS A record = reply contains non-excluded real IPv4 = addresses, the ENR MUST NOT synthesize IPv4 = addresses."
In this case, the = remote host IPv6 address has to be obtained according to 6052 (like in = RFC6145)
The other case is = where the remote-host IPv4 address used by an IPv4 application is a = referral.
Hope it = clarifies.
In-reply-to: Your message of Mon, 16 Apr 2012 13:43:34 -0000. <2D09D61DDFA73D4C884805CC7865E61109F6E5@GAALPA1MSGUSR9N.ITServices.sbc.com> Date: Mon, 16 Apr 2012 17:30:14 +0200 Sender: Francis.Dupont@fdupont.fr Cc: "v6ops@ietf.org" , "v6ops-chairs@tools.ietf.org" , Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 15:30:23 -0000 In your previous mail you wrote: > When it was suggested that PCP be mentioned in this draft, I stated > that I would only be in favor if it did not cause problems with > getting 6204bis approved. If multiple people have problems with the > PCP, then it does needs to go. And I absolutely will not support > including requirements around LAN-side functionality or > inter-working functions, as I consider that to be the realm of > homenet. This is focused on the WAN. => without something on the LAN side a PCP client on the WAN side doesn't make sense. And as I argued there is no router application using it. And a normative reference to PCP could delay 6204bis, so again I propose: - remove W-6 and the reference - wait for 6204ter and homenet to see what to put for this. Thanks Francis.Dupont@fdupont.fr From despres.remi@laposte.net Mon Apr 16 08:43:28 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 856A921F8701 for ; Mon, 16 Apr 2012 08:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.217 X-Spam-Level: X-Spam-Status: No, score=-2.217 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, 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 Mm5TTyadf68N for ; Mon, 16 Apr 2012 08:43:27 -0700 (PDT) Received: from smtpout.laposte.net (smtpout1.laposte.net [193.253.67.226]) by ietfa.amsl.com (Postfix) with ESMTP id 4EF0821F85F2 for ; Mon, 16 Apr 2012 08:43:26 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8502-out with ME id yfjR1i00137Y3f403fjR9P; Mon, 16 Apr 2012 17:43:25 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-18--198480283 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Mon, 16 Apr 2012 17:43:25 +0200 Message-Id: <5258F2DA-D61A-4327-B7FC-2BD67743C994@laposte.net> References: <7E1BD96D-E7EC-4C78-B382-66F0F694DAA4@laposte.net> <1825062D-D4EB-4310-A2BA-8B8F3870B9B4@laposte.net> <22BD6607-5DEC-48F3-B2E5-DCEECC9EF643@laposte.net> <986EAD24-4612-4AD0-B366-012BA0B3751C@laposte.net> To: Cameron Byrne X-Mailer: Apple Mail (2.1084) Cc: v6ops WG , Teemu Savolainen , Bill Huang Subject: Re: [v6ops] A way forward for 464XLAT - using BIH X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 15:43:28 -0000 --Apple-Mail-18--198480283 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 2012-04-16 15:52, Cameron Byrne: ... > NAT functions like RFC 6145 do not operate like BIH. Right? Local host = sockets are not used. Perhaps bih fits a proxy model, not a Nat model. >=20 > 464xlat operates as defined in RFC 6145, not BIH.=20 >=20 BIH, because it operates between IPv4 and IPv6 APIs doesn't need to do a = field-per-field mapping between IPv4 and IPv6 like that of RFC6145.=20 But the result is also that what applications see as IPv4 transmissions = are IPv6 packets on the wire.=20 > Is there a problem with how 464xlat is defined?=20 >=20 As already said, 464XLAT identifies an important scenario, not = documented before, but proposes for it a solution that is less complete = and less based on existing RFCs than a BIH-based solution. A remaining question is whether the open-source BIH implementation, = which Hui Deng has just kindly referenced, can be used as is for a test = with your unchanged PLAT, or whether some adaptation is needed. Hopefully someone can make progress on that.=20 > I see no compelling reason to add bih, as the 464xlat definition is = complete with 6145. >=20 Proposing several solutions for the same scenario should be avoided. The idea is rather to have a BCP that simply adds the 464XLAT scenario = to the scope of BIH (in addition to its current = IPv4-only-application-to-IPv6-only server scenario which is needed = anyway). BIH, with RFC6052 used where applicable, can thus be THE recommended = solution for the 464XLAT scenario. RD --Apple-Mail-18--198480283 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

NAT functions like RFC 6145 do not operate like BIH. = Right? Local host sockets are not used. Perhaps bih fits a proxy model, = not a Nat model.

464xlat operates as defined in RFC 6145, not = BIH. 

BIH, because it operates between IPv4 and = IPv6 APIs doesn't need to do a field-per-field mapping between IPv4 and = IPv6 like that of RFC6145. 
But the result is also that = what applications see as IPv4 transmissions are IPv6 packets on the = wire. 

Is there a = problem with how 464xlat is = defined? 


As already said, = 464XLAT identifies an important scenario, not documented before, = but proposes for it a solution that is less complete and less based = on existing RFCs than a BIH-based = solution.

A remaining question is whether = the open-source BIH implementation, which Hui Deng has just = kindly referenced, can be used as is for a test with your unchanged = PLAT, or whether some adaptation is = needed.

Hopefully someone can make progress on = that. 

 I see no compelling reason to add bih, as the = 464xlat definition is complete with 6145. =

Proposing several solutions for the same = scenario should be avoided.
The idea is rather to have a BCP = that simply adds the 464XLAT scenario to the scope of BIH (in = addition to its current IPv4-only-application-to-IPv6-only server = scenario which is needed anyway).
BIH, with RFC6052 used where = applicable, can thus be THE recommended solution for the 464XLAT = scenario.


RD

<= /div>

= --Apple-Mail-18--198480283-- From cb.list6@gmail.com Mon Apr 16 09:33:06 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8AB21F8621 for ; Mon, 16 Apr 2012 09:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.052 X-Spam-Level: X-Spam-Status: No, score=-3.052 tagged_above=-999 required=5 tests=[AWL=-0.353, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KzzFu8G7ZLsq for ; Mon, 16 Apr 2012 09:33:04 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id AB99321F861F for ; Mon, 16 Apr 2012 09:33:04 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so4501154pbb.31 for ; Mon, 16 Apr 2012 09:33:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=P9nkjZpEWNVzRrm1n2s9l9jnN9rmabNb9UdUkcc4TII=; b=gd99TKyuhVp9VlsMwLkrUWbn3D2VgzEnAx6y69MBtolzH0HTi+5eLtNguHZyDTPDd9 GDZ7Of6c6bf1lsScwPErH57rVyKRcu5x1HIa6yC8mHhVmUro5i4Rdv0NNNc+BycnEFLs xD4t4rRvVcgOXl0rry277TgR2ZmfRkUeeYYN5QoeD/0x2xWZ4ABkNs/MJEkh6YBJj+Ui 8OyLNUOD9Oa4sgfe+xpnOuToj9tTb0he1ehf1AmLTxH8vstreU2giXGlWuIT58rN8zjN 2lf7Ra9PZG/JE9GVMLjVZADvTlsKr1yipUZsXXJcIu1QETye2Bk59phPhUb7/q/dbdPi IWKQ== MIME-Version: 1.0 Received: by 10.68.195.163 with SMTP id if3mr28791429pbc.127.1334593984361; Mon, 16 Apr 2012 09:33:04 -0700 (PDT) Received: by 10.142.102.1 with HTTP; Mon, 16 Apr 2012 09:33:03 -0700 (PDT) In-Reply-To: <5258F2DA-D61A-4327-B7FC-2BD67743C994@laposte.net> References: <7E1BD96D-E7EC-4C78-B382-66F0F694DAA4@laposte.net> <1825062D-D4EB-4310-A2BA-8B8F3870B9B4@laposte.net> <22BD6607-5DEC-48F3-B2E5-DCEECC9EF643@laposte.net> <986EAD24-4612-4AD0-B366-012BA0B3751C@laposte.net> <5258F2DA-D61A-4327-B7FC-2BD67743C994@laposte.net> Date: Mon, 16 Apr 2012 09:33:03 -0700 Message-ID: From: Cameron Byrne To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops WG , Teemu Savolainen , Bill Huang Subject: Re: [v6ops] A way forward for 464XLAT - using BIH X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 16:33:06 -0000 On Mon, Apr 16, 2012 at 8:43 AM, R=E9mi Despr=E9s wrote: > > 2012-04-16 15:52, Cameron Byrne: > ... > > NAT functions like RFC 6145 do not operate like BIH. Right? Local host > sockets are not used. Perhaps bih fits a proxy model, not a Nat model. > > 464xlat operates as defined in RFC 6145, not BIH. > > BIH, because it operates between IPv4 and IPv6 APIs doesn't need to do a > field-per-field mapping between IPv4 and IPv6 like that of RFC6145. > But the result is also that what applications see as IPv4 transmissions a= re > IPv6 packets on the wire. > > Is there a problem with how 464xlat is defined? > > > As already said, 464XLAT identifies an important scenario, not documented > before, but=A0proposes for it a solution that is less complete and less b= ased > on existing RFCs than a BIH-based solution. > Less complete and less based on existing standars, based on what facts? And what does this mean for v6ops? If you have specific feedback about 464XLAT, please propose it. I have already explained to you that BIH does to fit a NAT model, as it cannot function in a router (BIH in a router) and faciliate a Skype call. The basic scenario BIH fails to meet is this: 1. CLAT is in a router (Home gateway or mobile phone acting as wifi hotspo= t) 2. IPv4-only windows XP host computer running Skype attached to CLAT router via WiFi 3. BIH has 1 modes of operation, neither work for this A. Network mode http://tools.ietf.org/html/rfc6535#section-2.4 "When BIH is implemented at the network layer, the IPv4 packets are intercepted and converted to IPv6 using the IP conversion mechanism defined in the Stateless IP/ICMP Translation Algorithm (SIIT) [RFC6145]. The protocol translation has the same benefits and drawbacks as SIIT." ACK --- BIH does RFC 6145. BUT! It has the following limitation on how how sessions may be initiated from the attached IPv4-only Windows XP host http://tools.ietf.org/html/rfc6535#section-2.3 "The network-layer implementation alternative will only be able to catch applications' name resolution requests that result in actual DNS queries; hence, it is more limited when compared to the socket API-layer implementation alternative. Hence, the socket API-layer alternative is RECOMMENDED." Thus, BIH in network mode CANNOT facilitate IPv4 literals for this scenario B. Socket API mode. BIH may be able to PROXY connections in the API mode, but this requires some sort of special networking scenario to enable proxying for all ports, not basic default routing, where the client communication must pass all the way up the CLAT stack and trigger the some APIs .... i have never seen this work for something like Skype. It may work, but i have never seen it done. And without anyone publishing these results, i must assume it does not exist. Even then, i see no benefit over 6145 as defined in 464XLAT today. We do have published results that using a proxy solution is less optimal than a NAT model http://www.cs.auckland.ac.nz/~brian/IPv4-IPv6coexistenceTechnique-TR.pdf > A=A0remaining question is whether the open-source BIH implementation, > which=A0Hui Deng=A0has just kindly referenced, can be used as is for a te= st with > your unchanged PLAT, or whether some adaptation is needed. > > Hopefully someone can make progress on that. > That sounds like an orthogonal activity to 464XLAT > =A0I see no compelling reason to add bih, as the 464xlat definition is > complete with 6145. > > Proposing several solutions for the same scenario should be avoided. Yes. We have a solution that works and published experimental data. We provided before 464XLAT application behavior (skype and others fail) and post 464XLAT behavior (skype and others work). It is a known and operational solution. > The idea is rather to have a BCP that simply adds=A0the 464XLAT scenario = to > the scope of=A0BIH (in addition to its current > IPv4-only-application-to-IPv6-only server scenario which is needed anyway= ). > BIH, with RFC6052 used where applicable, can thus be THE recommended > solution for the 464XLAT scenario. > That is not possible since there is no published operational experience with BIH and BIH technically fails to make certain scenarios (IPv4 literals, Skype) work in a router for an IPv4 only attached host. I am not sure why you would want to push BIH when 6145 is a known working scenario. BIH, IMHO, is just 6145 with some unfortunate feature (ENR) and specification (do not use for for double translation) limitations. Can you explain to an v6ops audience why BIH is superior in an operational context? Using real scenarios that network operators would have.... so far, all i have seen is that you believe it more "complete" and more "based on existing standards". Those statements do not mean anything specific to me. CB > > RD > > > From despres.remi@laposte.net Mon Apr 16 10:19:27 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5657D21F8564 for ; Mon, 16 Apr 2012 10:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.858 X-Spam-Level: X-Spam-Status: No, score=-1.858 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0iQFyd3PA3Zu for ; Mon, 16 Apr 2012 10:19:26 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id A432321F8557 for ; Mon, 16 Apr 2012 10:19:23 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 272A59401B9; Mon, 16 Apr 2012 19:19:09 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Mon, 16 Apr 2012 19:19:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1E2F23D0-3EFB-4879-9551-DFEE9FD9F6AB@laposte.net> References: <7E1BD96D-E7EC-4C78-B382-66F0F694DAA4@laposte.net> <1825062D-D4EB-4310-A2BA-8B8F3870B9B4@laposte.net> <22BD6607-5DEC-48F3-B2E5-DCEECC9EF643@laposte.net> <986EAD24-4612-4AD0-B366-012BA0B3751C@laposte.net> <5258F2DA-D61A-4327-B7FC-2BD67743C994@laposte.net> To: Cameron Byrne X-Mailer: Apple Mail (2.1084) Cc: v6ops WG , Teemu Savolainen , Bill Huang Subject: Re: [v6ops] A way forward for 464XLAT - using BIH X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 17:19:27 -0000 Le 2012-04-16 =E0 18:33, Cameron Byrne a =E9crit : > On Mon, Apr 16, 2012 at 8:43 AM, R=E9mi Despr=E9s = wrote: >>=20 >> 2012-04-16 15:52, Cameron Byrne: >> ... >>=20 >> NAT functions like RFC 6145 do not operate like BIH. Right? Local = host >> sockets are not used. Perhaps bih fits a proxy model, not a Nat = model. >>=20 >> 464xlat operates as defined in RFC 6145, not BIH. >>=20 >> BIH, because it operates between IPv4 and IPv6 APIs doesn't need to = do a >> field-per-field mapping between IPv4 and IPv6 like that of RFC6145. >> But the result is also that what applications see as IPv4 = transmissions are >> IPv6 packets on the wire. >>=20 >> Is there a problem with how 464xlat is defined? >>=20 >>=20 >> As already said, 464XLAT identifies an important scenario, not = documented >> before, but proposes for it a solution that is less complete and less = based >> on existing RFCs than a BIH-based solution. >>=20 >=20 > Less complete and less based on existing standars, based on what > facts? =20 (*) Here is my understanding:=20 - The RFC6145-based approach for the 464XLAT scenario is less complete = than BIH in that its IPv4-only applications cannot reach IPv6-only = servers. - It is less based on existing standards (meaning "standard-track RFCs") = in that it introduces a new format of IPv6 addresses for CLAT nodes. BIH = uses doesn't need that (any native IPv6 address that the BIH node uses = is sufficient). > And what does this mean for v6ops? A BCP for the 464XLAT use case seems to be appropriate in v6ops, be it = BIH based or not. > If you have specific feedback about 464XLAT, please propose it. That's what I try to do, by clarifying that: - there is the 464XLAT use case, which I support - there is a BIH-based way to support it which, being AFAIK more = complete and more based on existing RFCs, is IMHO preferable. > I have already explained to you that BIH does to fit a NAT model, What you mean by this is unclear to me. > as > it cannot function in a router (BIH in a router) and faciliate a Skype > call. As said, with a NAT44 as BIH IPv4 only application, the node can be an = IPv4 router on its LAN side. Can you explain why, in your understanding, this doesn't work? > The basic scenario BIH fails to meet is this: >=20 > 1. CLAT is in a router (Home gateway or mobile phone acting as wifi = hotspot) >=20 > 2. IPv4-only windows XP host computer running Skype attached to CLAT > router via WiFi Can you explain why this doesn't work with NAT44/BIH, while it works = with your proposed RFC6145-based solution? > 3. BIH has 1 modes of operation, neither work for this >=20 > A. Network mode >=20 > http://tools.ietf.org/html/rfc6535#section-2.4 >=20 > "When BIH is implemented at the network layer, the IPv4 packets are > intercepted and converted to IPv6 using the IP conversion mechanism > defined in the Stateless IP/ICMP Translation Algorithm (SIIT) > [RFC6145]. The protocol translation has the same benefits and > drawbacks as SIIT." >=20 > ACK --- BIH does RFC 6145. >=20 > BUT! It has the following limitation on how how sessions may be > initiated from the attached IPv4-only Windows XP host >=20 > http://tools.ietf.org/html/rfc6535#section-2.3 >=20 > "The network-layer implementation alternative will only be able to > catch applications' name resolution requests that result in actual > DNS queries; hence, it is more limited when compared to the socket > API-layer implementation alternative. Hence, the socket API-layer > alternative is RECOMMENDED." >=20 > Thus, BIH in network mode CANNOT facilitate IPv4 literals for this = scenario Not the proposed mode. > B. Socket API mode. >=20 > BIH may be able to PROXY connections in the API mode, but this > requires some sort of special networking scenario to enable proxying > for all ports, not basic default routing, where the client > communication must pass all the way up the CLAT stack and trigger the > some APIs .... i have never seen this work for something like Skype. > It may work, but i have never seen it done. And without anyone > publishing these results, i must assume it does not exist. That's where making tests could help. In the mean time, if you have an explanation why you believe Skype = shouldn't work, that would be useful. (I don't pretend to know Skype in any detail, but I know there are = already NAT cascades in the field and have not heard so far that they = break Skype.) > Even then, i see no benefit over 6145 as defined in 464XLAT today. > We do have published results that using a proxy solution is less > optimal than a NAT model >=20 > = http://www.cs.auckland.ac.nz/~brian/IPv4-IPv6coexistenceTechnique-TR.pdf Thanks, will look at it. >=20 >> A remaining question is whether the open-source BIH implementation, >> which Hui Deng has just kindly referenced, can be used as is for a = test with >> your unchanged PLAT, or whether some adaptation is needed. >>=20 >> Hopefully someone can make progress on that. >>=20 >=20 > That sounds like an orthogonal activity to 464XLAT Not to the 464XLAT use case. >> I see no compelling reason to add bih, as the 464xlat definition is >> complete with 6145. >>=20 >> Proposing several solutions for the same scenario should be avoided. >=20 > Yes. We have a solution that works and published experimental data. > We provided before 464XLAT application behavior (skype and others > fail) and post 464XLAT behavior (skype and others work). It is a > known and operational solution. >=20 >=20 >> The idea is rather to have a BCP that simply adds the 464XLAT = scenario to >> the scope of BIH (in addition to its current >> IPv4-only-application-to-IPv6-only server scenario which is needed = anyway). >> BIH, with RFC6052 used where applicable, can thus be THE recommended >> solution for the 464XLAT scenario. >>=20 >=20 > That is not possible since there is no published operational > experience with BIH and BIH technically fails to make certain > scenarios (IPv4 literals, Skype) work in a router for an IPv4 only > attached host. Proof of these assertions would certainly clarify the debate. > I am not sure why you would want to push BIH when 6145 is a known > working scenario. BIH, IMHO, is just 6145 with some unfortunate > feature (ENR) and specification (do not use for for double > translation) limitations. This is AFAIK a much too restrictive understanding of RFC6535. > Can you explain to an v6ops audience why BIH is superior in an > operational context? Using real scenarios that network operators would > have.... so far, all i have seen is that you believe it more > "complete" and more "based on existing standards". Those statements > do not mean anything specific to me. That's the point to be clarified. RD >=20 > CB From tom.taylor.stds@gmail.com Mon Apr 16 10:34:38 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1A7011E80AB for ; Mon, 16 Apr 2012 10:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.34 X-Spam-Level: X-Spam-Status: No, score=-3.34 tagged_above=-999 required=5 tests=[AWL=0.259, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xp8mrHBp4-uB for ; Mon, 16 Apr 2012 10:34:38 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 30F1A11E809C for ; Mon, 16 Apr 2012 10:34:38 -0700 (PDT) Received: by lbbgf14 with SMTP id gf14so2300127lbb.31 for ; Mon, 16 Apr 2012 10:34:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-antivirus:x-antivirus-status; bh=E/SoFFYQI6EAwr4O/bYEk5UiVatlonrP6emWzypQzAc=; b=rpKhcepC646PGTOO3e5IOXB2702QyhWBPu1e0oGtDGzhcLOjWSL/K4lcbe1Mw7zLzE U24R/xEP2Ks9ZlU4G9TVswoKrB+fDu6Pq3v5yD3gkj5MozSPW/F+szFk5qCzQfAroQVu ZmiJJhvQurUJgj2vXd77Nb+B9JErK1QW+rSW+IKWwgPyrZkqE7uFMfWxwRnSEBN/YjiW 3T2yJKkCKx26kG/4/fuu0OfGElxjhb6Vbu4CfmElm4Ctc0EvYpI3SeifUVZt4y/Ssjkb RCniwmNb9zLtr03muuQvUWUC4OOzWfqcXBki3vm+d4lFw2LN9BwGyxRny8xPdWfvojGx 3HZw== Received: by 10.112.29.194 with SMTP id m2mr5843170lbh.19.1334597677194; Mon, 16 Apr 2012 10:34:37 -0700 (PDT) Received: from [127.0.0.1] (dsl-207-112-91-137.tor.primus.ca. [207.112.91.137]) by mx.google.com with ESMTPS id h8sm25387246lbx.8.2012.04.16.10.34.33 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 16 Apr 2012 10:34:35 -0700 (PDT) Message-ID: <4F8C5824.9010306@gmail.com> Date: Mon, 16 Apr 2012 13:34:28 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Simon Perreault References: <201204161157.q3GBvMXE088261@givry.fdupont.fr> <4F8C2D58.8010402@gmail.com> <4F8C318A.4050601@viagenie.ca> In-Reply-To: <4F8C318A.4050601@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 120416-0, 16/04/2012), Outbound message X-Antivirus-Status: Clean Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC -- PCP requirement X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 17:34:39 -0000 That's my point: leaving aside the DS-Lite application, not all CE Router developers should be required to implement PCP clients. And for DS-Lite, there are open questions: -- client vs. proxy -- security issues with THIRD_PARTY -- the fact that neither the PCP base specification nor W-6 requires the implementation of the THIRD_PARTY option On 16/04/2012 10:49 AM, Simon Perreault wrote: > On 2012-04-16 10:31, Tom Taylor wrote: >> This point was discussed in the PCP meeting. While Francis's view seemed >> to be in the minority, I found it logically compelling. The applications >> that were described in the meeting that would find it useful were really >> host functions that happened to be resident on the CPE. Hence >> implementation of a PCP client would be the task of the people >> implementing those functions, rather than of the CE Router developers. > > Isn't the set of "people implementing those functions" a subset of "CE > Router developers"? > > Simon From cb.list6@gmail.com Mon Apr 16 11:37:45 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C12EF21F8625 for ; Mon, 16 Apr 2012 11:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.02 X-Spam-Level: X-Spam-Status: No, score=-3.02 tagged_above=-999 required=5 tests=[AWL=-0.321, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YbHTh52MoQJa for ; Mon, 16 Apr 2012 11:37:44 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 602C421F85D7 for ; Mon, 16 Apr 2012 11:37:31 -0700 (PDT) Received: by dady13 with SMTP id y13so10045739dad.27 for ; Mon, 16 Apr 2012 11:37:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=2uYVRzd7Vvo56ha9RZfbExAN5SAOak9LCoxMI2Z2S0I=; b=mfn7cEUIc3qS7BUDrmwg2zwQ6Mq+4X4yH6mgG9hR6LMkBCNhm7J3iUEhpI57QO/5J7 x5+DbgmRedOus4wMvsrAyxa1twd/RaVxzc9vo2OYVQbSzOwSUF7bDrTBxlS/7vKoKTap 64uRz1I0PqNoSE+Q1/+b/sjLhgr00/CsQPTLtS5eNm9/HZ8LrsVbspL/YbUkPskbxkWg rfD+YEhOj0TogsKLCBOpI4dTADhrL6CPn6dVHIjqfgKNZn2br001x0XnHlrEir2KOOEv WCnOTaJHdhFAiIitgdwmxp/dGMm1Xk4T9gQA5FmBSXdQWDnpj1sNwzULZijbnq70ar5C dFRg== MIME-Version: 1.0 Received: by 10.68.216.234 with SMTP id ot10mr29755660pbc.107.1334601450410; Mon, 16 Apr 2012 11:37:30 -0700 (PDT) Received: by 10.142.102.1 with HTTP; Mon, 16 Apr 2012 11:37:30 -0700 (PDT) In-Reply-To: <1E2F23D0-3EFB-4879-9551-DFEE9FD9F6AB@laposte.net> References: <7E1BD96D-E7EC-4C78-B382-66F0F694DAA4@laposte.net> <1825062D-D4EB-4310-A2BA-8B8F3870B9B4@laposte.net> <22BD6607-5DEC-48F3-B2E5-DCEECC9EF643@laposte.net> <986EAD24-4612-4AD0-B366-012BA0B3751C@laposte.net> <5258F2DA-D61A-4327-B7FC-2BD67743C994@laposte.net> <1E2F23D0-3EFB-4879-9551-DFEE9FD9F6AB@laposte.net> Date: Mon, 16 Apr 2012 11:37:30 -0700 Message-ID: From: Cameron Byrne To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops WG , Teemu Savolainen , Bill Huang Subject: Re: [v6ops] A way forward for 464XLAT - using BIH X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 18:37:45 -0000 On Mon, Apr 16, 2012 at 10:19 AM, R=E9mi Despr=E9s wrote: > > Le 2012-04-16 =E0 18:33, Cameron Byrne a =E9crit : > >> On Mon, Apr 16, 2012 at 8:43 AM, R=E9mi Despr=E9s wrote: >>> >>> 2012-04-16 15:52, Cameron Byrne: >>> ... >>> >>> NAT functions like RFC 6145 do not operate like BIH. Right? Local host >>> sockets are not used. Perhaps bih fits a proxy model, not a Nat model. >>> >>> 464xlat operates as defined in RFC 6145, not BIH. >>> >>> BIH, because it operates between IPv4 and IPv6 APIs doesn't need to do = a >>> field-per-field mapping between IPv4 and IPv6 like that of RFC6145. >>> But the result is also that what applications see as IPv4 transmissions= are >>> IPv6 packets on the wire. >>> >>> Is there a problem with how 464xlat is defined? >>> >>> >>> As already said, 464XLAT identifies an important scenario, not document= ed >>> before, but proposes for it a solution that is less complete and less b= ased >>> on existing RFCs than a BIH-based solution. >>> >> >> Less complete and less based on existing standars, based on what >> facts? > > (*) Here is my understanding: > - The RFC6145-based approach for the 464XLAT scenario is less complete th= an BIH in that its IPv4-only applications cannot reach IPv6-only servers. I still do not know what less complete means. My understanding is that BIH is less complete since there is no working model of how it can fit into 464XLAT. Network mode BIH is theoretically not possible API mode BIH is theoretically possible (maybe), but i do not believe a common NAT44 function would trigger the relevant APIs that BIH uses. > - It is less based on existing standards (meaning "standard-track RFCs") = in that it introduces a new format of IPv6 addresses for CLAT nodes. BIH us= es doesn't need that (any native IPv6 address that the BIH node uses is suf= ficient). > The 02 version will be published soon and will include Ole's suggestion of 2 modes, including NAT44 on the CLAT. There will be no new IPv6 address format or ND/DAD activity. >> And what does this mean for v6ops? > > A BCP for the 464XLAT use case seems to be appropriate in v6ops, be it BI= H based or not. > >> If you have specific feedback about 464XLAT, please propose it. > > That's what I try to do, by clarifying that: > - there is the 464XLAT use case, which I support > - there is a BIH-based way to support it which, being AFAIK more complete= and more based on existing RFCs, is IMHO preferable. > > >> I have already explained to you that BIH does to fit a NAT model, > > What you mean by this is unclear to me. > >> as >> it cannot function in a router (BIH in a router) and faciliate a Skype >> call. > > As said, with a NAT44 as BIH IPv4 only application, the node can be an IP= v4 router on its LAN side. > Can you explain why, in your understanding, this doesn't work? > So your case is that NAT44 is the IPv4 application that BIH API can work wi= th. My largely uniformed understanding of NAT44 is that the BIH API calls listed are not involved in common NAT44 http://tools.ietf.org/html/rfc6535#appendix-A I know this list is not exhaustive, but my understanding is that BIH did not have NAT44 as a use case in mind. > >> The basic scenario BIH fails to meet is this: >> >> 1. =A0CLAT is in a router (Home gateway or mobile phone acting as wifi h= otspot) >> >> 2. =A0IPv4-only windows XP host computer running Skype attached to CLAT >> router via WiFi > > Can you explain why this doesn't work with NAT44/BIH, while it works with= your proposed RFC6145-based solution? > I am now just understanding what you have in mind is NAT44 -> BIH API mode -> NAT64 As, where 464XLAT-02 will define NAT44 -> 6145 -> NAT64 The most important difference is that the RFC 6145 exists and i have tested it extensively (use it every day), while i am unaware of any implementation of the "NAT44 -> BIH" method. IMHO, the ENR and API interactions are less general and more complicated than RFC 6145. I have brought several cases of 464XLAT working today with open source commercial solutions https://sites.google.com/site/tmoipv6/464xlat Reaching IPv6-only servers from a IPv4-only host is not a case that i, as a network operator, value very high. > >> 3. =A0 BIH has 1 modes of operation, neither work for this >> >> A. =A0Network mode >> >> http://tools.ietf.org/html/rfc6535#section-2.4 >> >> "When BIH is implemented at the network layer, the IPv4 packets are >> =A0 intercepted and converted to IPv6 using the IP conversion mechanism >> =A0 defined in the Stateless IP/ICMP Translation Algorithm (SIIT) >> =A0 [RFC6145]. =A0The protocol translation has the same benefits and >> =A0 drawbacks as SIIT." >> >> ACK --- BIH does RFC 6145. >> >> BUT! It has the following limitation on how how sessions may be >> initiated from the attached IPv4-only Windows XP host >> >> http://tools.ietf.org/html/rfc6535#section-2.3 >> >> "The network-layer implementation alternative will only be able to >> =A0 catch applications' name resolution requests that result in actual >> =A0 DNS queries; hence, it is more limited when compared to the socket >> =A0 API-layer implementation alternative. =A0Hence, the socket API-layer >> =A0 alternative is RECOMMENDED." >> >> Thus, BIH in network mode CANNOT facilitate IPv4 literals for this scena= rio > > Not the proposed mode. > >> B. =A0Socket API mode. >> >> BIH may be able to PROXY connections in the API mode, but this >> requires some sort of special networking scenario to enable proxying >> for all ports, not basic default routing, where the client >> communication must pass all the way up the CLAT stack and trigger the >> some APIs .... i have never seen this work for something like Skype. >> It may work, but i have never seen it done. =A0And without anyone >> publishing these results, i must assume it does not exist. > > That's where making tests could help. > > In the mean time, if you have an explanation why you believe Skype should= n't work, that would be useful. > (I don't pretend to know Skype in any detail, but I know there are alread= y NAT cascades in the field and have not heard so far that they break Skype= .) > > My understanding has now shifted based on your clarification that BIH could work, if BIH could support NAT44. I do not have the expertise about how NAT44 is implemented to tell if BIH could support NAT44 definitively. Either way, AFAIK, NAT44 -> BIH does not exist today and there is no published experiences of it working. I don't want to be in a situation where i have to prove BIH does not work to justify that RFC 6145 is the right path, especially since i don't believe BIH has any practical or theoretical advantages over RFC 6145. CB >> Even then, i see no benefit over 6145 as defined in 464XLAT today. >> We do have published results that using a proxy solution is less >> optimal than a NAT model >> >> http://www.cs.auckland.ac.nz/~brian/IPv4-IPv6coexistenceTechnique-TR.pdf > > Thanks, will look at it. > >> >>> A remaining question is whether the open-source BIH implementation, >>> which Hui Deng has just kindly referenced, can be used as is for a test= with >>> your unchanged PLAT, or whether some adaptation is needed. >>> >>> Hopefully someone can make progress on that. >>> >> >> That sounds like an orthogonal activity to 464XLAT > > Not to the 464XLAT use case. > >>> =A0I see no compelling reason to add bih, as the 464xlat definition is >>> complete with 6145. >>> >>> Proposing several solutions for the same scenario should be avoided. >> >> Yes. =A0We have a solution that works and published experimental data. >> We provided before 464XLAT application behavior (skype and others >> fail) and post 464XLAT behavior (skype and others work). =A0It is a >> known and operational solution. >> >> >>> The idea is rather to have a BCP that simply adds the 464XLAT scenario = to >>> the scope of BIH (in addition to its current >>> IPv4-only-application-to-IPv6-only server scenario which is needed anyw= ay). >>> BIH, with RFC6052 used where applicable, can thus be THE recommended >>> solution for the 464XLAT scenario. >>> >> >> That is not possible since there is no published operational >> experience with BIH and BIH technically fails to make certain >> scenarios (IPv4 literals, Skype) work in a router for an IPv4 only >> attached host. > > Proof of these assertions would certainly clarify the debate. > > >> I am not sure why you would want to push BIH when 6145 is a known >> working scenario. =A0BIH, IMHO, is just 6145 with some unfortunate >> feature (ENR) and specification (do not use for for double >> translation) limitations. > > This is AFAIK a much too restrictive understanding of RFC6535. > > >> Can you explain to an v6ops audience why BIH is superior in an >> operational context? Using real scenarios that network operators would >> have.... so far, all i have seen is that you believe it more >> "complete" and more "based on existing standards". =A0Those statements >> do not mean anything specific to me. > > That's the point to be clarified. > > RD > > > >> >> CB > From Francis.Dupont@fdupont.fr Mon Apr 16 15:14:38 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93C9F11E80C1 for ; Mon, 16 Apr 2012 15:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, 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 hn-pm7FBMXR1 for ; Mon, 16 Apr 2012 15:14:38 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id CBB2111E808A for ; Mon, 16 Apr 2012 15:14:37 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q3GMEWqp025950; Tue, 17 Apr 2012 00:14:32 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201204162214.q3GMEWqp025950@givry.fdupont.fr> From: Francis Dupont To: Tom Taylor In-reply-to: Your message of Mon, 16 Apr 2012 10:31:52 EDT. <4F8C2D58.8010402@gmail.com> Date: Tue, 17 Apr 2012 00:14:32 +0200 Sender: Francis.Dupont@fdupont.fr Cc: v6ops@ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC -- PCP requirement X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 22:14:38 -0000 In your previous mail you wrote: > On the other hand, Barbara mentions interest in its application for > DS-Lite. Delving into the PCP-related documents, I note > draft-dupont-pcp-dslite, which advocates implementation of a PCP proxy > rather than PCP client function in the CE Router. => yes, it is the homenet/out-of-scope for the benefit of hosts on the LAN part. > In the PCP base document itself, the main discussion of DS-Lite usage > comes in the Security Considerations section, in association with the > use of the THIRD_PARTY option. => independently of the THIRD_PARTY issue this whole text should move to the DS-Lite document (and its authors joined the DS-Lite document team so I can use shall :-). > I see various issues around inclusion of a reference to PCP in > 6204bis at this time, in terms both of the appropriate technical > approach and approval of the specifications. => yes, it is too soon. Regards Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Mon Apr 16 15:18:15 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7662911E808A for ; Mon, 16 Apr 2012 15:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.078, 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 hatpQrUAzTgP for ; Mon, 16 Apr 2012 15:18:15 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id AD29511E80C1 for ; Mon, 16 Apr 2012 15:18:14 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q3GMIDYM026191; Tue, 17 Apr 2012 00:18:13 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201204162218.q3GMIDYM026191@givry.fdupont.fr> From: Francis Dupont To: Simon Perreault In-reply-to: Your message of Mon, 16 Apr 2012 10:49:46 EDT. <4F8C318A.4050601@viagenie.ca> Date: Tue, 17 Apr 2012 00:18:13 +0200 Sender: Francis.Dupont@fdupont.fr Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC -- PCP requirement X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 22:18:15 -0000 In your previous mail you wrote: > On 2012-04-16 10:31, Tom Taylor wrote: > > This point was discussed in the PCP meeting. While Francis's view seemed > > to be in the minority, I found it logically compelling. The applications > > that were described in the meeting that would find it useful were really > > host functions that happened to be resident on the CPE. Hence > > implementation of a PCP client would be the task of the people > > implementing those functions, rather than of the CE Router developers. > > Isn't the set of "people implementing those functions" a subset of "CE > Router developers"? => it is the opposite: "CE Router developers" are a subset of "people implementing stuff" (:-). Note there is perhaps something else in Tom's message: there is no definition of a PCP client as an independent piece of code, i.e., each "application" can embed a PCP client... Regards Francis.Dupont@fdupont.fr From lorenzo@google.com Mon Apr 16 18:48:56 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4CFF11E80F0 for ; Mon, 16 Apr 2012 18:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.751 X-Spam-Level: X-Spam-Status: No, score=-102.751 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vq9akuJtEh5Z for ; Mon, 16 Apr 2012 18:48:56 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2C08311E80A2 for ; Mon, 16 Apr 2012 18:48:55 -0700 (PDT) Received: by obbwd20 with SMTP id wd20so3454557obb.31 for ; Mon, 16 Apr 2012 18:48:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=8PGcoR23sVYXacLtmK6c/RWJ9jkJSvVw36f+lvwf1CE=; b=BE2YzP4gkyW60LU9XSVZK5Z5n+FJpwFdFLgXFUP6S5IQhhNtdG+fYh2/HIOAlb1Ivt HJpcYLDB4Ozzb/PsGhx1VE2lnmdVlnjr3bYPdfUF9xjUllBS4uyWj0wlTUtKTkug705e WIbk++tUOSjrJ+UmLSjl76R58/3pBSAxngVc2+LONGol5UTJoIkHGgHDtODwcF9oBwfj j3Ua/mzbfnD7+9VhF3PL0X4rkDOj74XhmqhFXO8d/xpf31sEnz0oH6WQrVlUCDfqcpiF +GwTV3CVli9mGZxYBMAyOcmUhQV8ybHSEG9z8ISZ53Z6ug5xejuB3ueWgVB6ImL6nUxD lPGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=8PGcoR23sVYXacLtmK6c/RWJ9jkJSvVw36f+lvwf1CE=; b=ROl/rzutR07by0Z9aAoms3ydXmQ03yzCRtklbtdirIq3lPwh2T3lqihNL+eqH18uTj L3/TRULNZK6qLSoeZ4PKwG3j0rsHYIPGYoYLs49aFBuVUpi+OSTbp/ayCg3m8xUGWhfo Zrz+zbxEFFKKkw9P7NHbczUQ+IcLX5cEFL8+njP88ReAjiprcWr+kxRiXYPtZRFB6NVS IIkZUTtmIJVj4EYx1CBOfpBiceJtMkYjaMJ/ueA+7OmLsG28fWiqxhA7zAAd4yih/fz7 ncp2fZmXHPju4hi+TUCDJDUd5OvEYg+gCfZFMCVQC+m5rOyexxDtUMpmL6DNALwq1bp9 uk8w== Received: by 10.182.44.97 with SMTP id d1mr12759452obm.28.1334627335643; Mon, 16 Apr 2012 18:48:55 -0700 (PDT) Received: by 10.182.44.97 with SMTP id d1mr12759439obm.28.1334627335536; Mon, 16 Apr 2012 18:48:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.220.3 with HTTP; Mon, 16 Apr 2012 18:48:35 -0700 (PDT) In-Reply-To: <5258F2DA-D61A-4327-B7FC-2BD67743C994@laposte.net> References: <7E1BD96D-E7EC-4C78-B382-66F0F694DAA4@laposte.net> <1825062D-D4EB-4310-A2BA-8B8F3870B9B4@laposte.net> <22BD6607-5DEC-48F3-B2E5-DCEECC9EF643@laposte.net> <986EAD24-4612-4AD0-B366-012BA0B3751C@laposte.net> <5258F2DA-D61A-4327-B7FC-2BD67743C994@laposte.net> From: Lorenzo Colitti Date: Tue, 17 Apr 2012 10:48:35 +0900 Message-ID: To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=f46d0447a14d3e009004bdd62444 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnthZ9Ev7JaebIxAD6kMlXeSEan5lOxcJ4cwdJgVWFdjOk/+zvVsBs7wgc1yJev+zRxRDbvjfJnEBb7fbn3hlrWtCYGktG2bysF8VeTSZBQMBnL+oUDjGPrFbAQP8EGfjmEsbMP Cc: v6ops WG , Bill Huang , Teemu Savolainen Subject: Re: [v6ops] A way forward for 464XLAT - using BIH X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 01:48:56 -0000 --f46d0447a14d3e009004bdd62444 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Apr 17, 2012 at 00:43, R=E9mi Despr=E9s w= rote: > I see no compelling reason to add bih, as the 464xlat definition is > complete with 6145. > > Proposing several solutions for the same scenario should be avoided. > The idea is rather to have a BCP that simply adds the 464XLAT scenario to > the scope of BIH (in addition to its current > IPv4-only-application-to-IPv6-only server scenario which is needed anyway= ). > I disagree that getting IPv4-only applications to communicate with IPv6-only servers is an important goal that we should pursue now. Servers will need to stay IPv4-capable for many years anyway, in order to continue to support IPv4-only client OSes and networks. So we'd be solving a problem that doesn't actually exist today. >From an implementation perspective, I also really don't like the idea of messing with the socket stack to make this use case work. It's much more complicated than 464xlat, which just translates packets on the wire. So if your statement is "this draft should be presented as a use case for BIH instead of as a use case for RFC 6145, because we need another thing that BIH can do for us anyway", then I disagree. --f46d0447a14d3e009004bdd62444 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Apr 17, 2012 at 00:43, R=E9mi Despr=E9s = <despres.r= emi@laposte.net> wrote:

=A0I see no compelling reason to add bih, as the 464xlat defin= ition is complete with 6145.

Proposing sev= eral solutions for the same scenario should be avoided.
The idea is rather to have a BCP that simply adds=A0the 464XLAT scenar= io to the scope of=A0BIH (in addition to its current IPv4-only-application-= to-IPv6-only server scenario which is needed anyway).

I disagree that getting IPv4-only applicat= ions to communicate with IPv6-only servers is an important goal that we sho= uld pursue now.

Servers will need to stay IPv4-cap= able for many years anyway, in order to continue to support IPv4-only clien= t OSes and networks. So we'd be solving a problem that doesn't actu= ally exist today.

From an implementation perspective, I also really don&#= 39;t like the idea of messing with the socket stack to make this use case w= ork. It's much more complicated than 464xlat, which just translates pac= kets on the wire.

So if your statement is "this draft should be pres= ented as a use case for BIH instead of as a use case for RFC 6145, because = we need another thing that BIH can do for us anyway", then I disagree.=
--f46d0447a14d3e009004bdd62444-- From internet-drafts@ietf.org Mon Apr 16 23:55:47 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 284DD21F8458; Mon, 16 Apr 2012 23:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.502 X-Spam-Level: X-Spam-Status: No, score=-102.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QXZxgzAU9Oxf; Mon, 16 Apr 2012 23:55:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1BE721F844C; Mon, 16 Apr 2012 23:55:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120417065542.31115.95082.idtracker@ietfa.amsl.com> Date: Mon, 16 Apr 2012 23:55:42 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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, 17 Apr 2012 06:55:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the = IETF. Title : 464XLAT: Combination of Stateful and Stateless Translati= on Author(s) : Masataka Mawatari Masanobu Kawashima Cameron Byrne Filename : draft-ietf-v6ops-464xlat-02.txt Pages : 15 Date : 2012-04-16 This document describes an architecture (464XLAT) for providing limited IPv4 connectivity across an IPv6-only network by combining existing and well-known stateful protocol translation RFC 6146 in the core and stateless protocol translation RFC 6145 at the edge. 464XLAT is a simple and scalable technique to quickly deploy limited IPv4 access service to mobile and wireline IPv6-only edge networks without encapsulation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-464xlat-02.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-464xlat-02.txt From kawashimam@vx.jp.nec.com Tue Apr 17 00:01:08 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E6C021F849A for ; Tue, 17 Apr 2012 00:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4QAMe0DxXdPR for ; Tue, 17 Apr 2012 00:01:03 -0700 (PDT) Received: from tyo202.gate.nec.co.jp (TYO202.gate.nec.co.jp [202.32.8.206]) by ietfa.amsl.com (Postfix) with ESMTP id 85D7721F8458 for ; Tue, 17 Apr 2012 00:01:02 -0700 (PDT) Received: from mailgate3.nec.co.jp ([10.7.69.160]) by tyo202.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id q3H7116N004877 for ; Tue, 17 Apr 2012 16:01:01 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id q3H711122141 for v6ops@ietf.org; Tue, 17 Apr 2012 16:01:01 +0900 (JST) Received: from mail01b.kamome.nec.co.jp (mail01b.kamome.nec.co.jp [10.25.43.2]) by mailsv3.nec.co.jp (8.13.8/8.13.4) with ESMTP id q3H710g3021775 for ; Tue, 17 Apr 2012 16:01:00 +0900 (JST) Received: from kogoro.jp.nec.com ([10.26.220.12] [10.26.220.12]) by mail02.kamome.nec.co.jp with ESMTP id BT-MMP-702711; Tue, 17 Apr 2012 16:00:09 +0900 Received: from siznecatg159185 ([10.3.159.185] [10.3.159.185]) by mail.jp.nec.com with ESMTPA id BT-MMP-39689; Tue, 17 Apr 2012 16:00:09 +0900 To: v6ops@ietf.org In-reply-to: <20120417065542.31115.95082.idtracker@ietfa.amsl.com> Message-Id: <20120417160010kawashimam@mail.jp.nec.com> References: <20120417065542.31115.95082.idtracker@ietfa.amsl.com> Mime-Version: 1.0 X-Mailer: StarOffice21/MailClient[4.65 Step9] From: Masanobu Kawashima Date: Tue, 17 Apr 2012 16:00:07 +0900 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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, 17 Apr 2012 07:01:08 -0000 Folks, We have published draft-ietf-v6ops-464xlat-02. Changes are: - Changed document category from Informational to BCP - A normative language(RFC2119) has reinserted. - We did not see any strong opposition on this list except Remi. As Cameron and Lorenzo said, we should not treat as a use case for BIH. Remi's some concerns were fixed by this version as below. If you have any strong opposition, please indicate it. - Section 7.1. IPv6 Address Format - Replaced all text with this one sentence "IPv6 address format in 464XLAT is defined in Section 2.2 of [RFC6052]" - Section 7.2. IPv4/IPv6 address translation chart - Removed all references to /96 - Added case of "CLAT with NAT44" - Section 7.4. DNS Proxy Implementation - Added a reference to RFC5625 - Section 7.5. IPv6 Prefix Handling - Removed all references to /96 - Added a reference to RFC3633 All comments are welcome. Regards, Masanobu > >A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. > > Title : 464XLAT: Combination of Stateful and Stateless Translation > Author(s) : Masataka Mawatari > Masanobu Kawashima > Cameron Byrne > Filename : draft-ietf-v6ops-464xlat-02.txt > Pages : 15 > Date : 2012-04-16 > > This document describes an architecture (464XLAT) for providing > limited IPv4 connectivity across an IPv6-only network by combining > existing and well-known stateful protocol translation RFC 6146 in the > core and stateless protocol translation RFC 6145 at the edge. 464XLAT > is a simple and scalable technique to quickly deploy limited IPv4 > access service to mobile and wireline IPv6-only edge networks without > encapsulation. > > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-v6ops-464xlat-02.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-464xlat-02.txt > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops ======================================== NEC AccessTechnica, Ltd. Product Development Department Masanobu Kawashima kawashimam@vx.jp.nec.com http://www.necat.co.jp/ ======================================== From brian.e.carpenter@gmail.com Tue Apr 17 00:11:49 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C464721F85C7 for ; Tue, 17 Apr 2012 00:11:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.579 X-Spam-Level: X-Spam-Status: No, score=-101.579 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hp3NzB+cnppn for ; Tue, 17 Apr 2012 00:11:49 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 2327D21F85C6 for ; Tue, 17 Apr 2012 00:11:48 -0700 (PDT) Received: by wibhq7 with SMTP id hq7so221922wib.13 for ; Tue, 17 Apr 2012 00:11:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=/L6I5/IOPx0ruQRwyeqnSQMKb0vv6ALgqblkltccDJc=; b=WPDG4nNt5QH1A/Tz+DvojKNbaT6e+VaHbCAM4hYbBJsOuSiBCyjRlv4oIfdNomU4VD GJm3KzO3n43GyDRxUb44TCXz9JPZmtE6zbKwgLrxZ01jv2Vk5QBMKN92NeDgUlGOS0Rh P2CI9ARN+QOiFegrR19pArvj2abjshCZGCMYKYyWLbae4qIDAbIHFyREOQx45R6SDfnK VaC+F+CKCTqw4MMVDtNLT6WhR/jyVVnbGfiKFV6DJ7bOOPkg/a4krbwoJhCpppIOjXGW VHRqmWB74L3B4FWQO7tWY5i+/cZXWFIIOeoiGgVYGH6edwXVmNWp54BkNoX1/GLfEOdE D1NA== Received: by 10.180.103.35 with SMTP id ft3mr25511544wib.0.1334646708102; Tue, 17 Apr 2012 00:11:48 -0700 (PDT) Received: from [192.168.1.69] (host-2-102-216-233.as13285.net. [2.102.216.233]) by mx.google.com with ESMTPS id ff2sm40302169wib.9.2012.04.17.00.11.45 (version=SSLv3 cipher=OTHER); Tue, 17 Apr 2012 00:11:47 -0700 (PDT) Message-ID: <4F8D17AD.7080907@gmail.com> Date: Tue, 17 Apr 2012 08:11:41 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Lorenzo Colitti References: <7E1BD96D-E7EC-4C78-B382-66F0F694DAA4@laposte.net> <1825062D-D4EB-4310-A2BA-8B8F3870B9B4@laposte.net> <22BD6607-5DEC-48F3-B2E5-DCEECC9EF643@laposte.net> <986EAD24-4612-4AD0-B366-012BA0B3751C@laposte.net> <5258F2DA-D61A-4327-B7FC-2BD67743C994@laposte.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops WG , Bill Huang , Teemu Savolainen Subject: Re: [v6ops] A way forward for 464XLAT - using BIH X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 07:11:49 -0000 On 2012-04-17 02:48, Lorenzo Colitti wrote: ... > I disagree that getting IPv4-only applications to communicate with > IPv6-only servers is an important goal that we should pursue now. > > Servers will need to stay IPv4-capable for many years anyway, in order to > continue to support IPv4-only client OSes and networks. So we'd be solving > a problem that doesn't actually exist today. I agree strongly. No rational economic actor will attempt to provide an IPv6-only application service for many years. There really isn't a shortage of IPv4 addresses for content provision or other application services, and there are a few billion IPv4 customers out there. To be clear, this does not rule out running IPv6-only servers fronted by some form of NAT46; some operators might conclude that this would reduce OPEX. But the service offered to the Internet would then appear to be dual stacked. This seems to be completely orthogonal to the 464XLAT use case. Brian From despres.remi@laposte.net Tue Apr 17 01:52:04 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95FA421F84CF for ; Tue, 17 Apr 2012 01:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.22 X-Spam-Level: X-Spam-Status: No, score=-2.22 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J3LnN0Z1zeVG for ; Tue, 17 Apr 2012 01:52:04 -0700 (PDT) Received: from smtpout.laposte.net (smtpout5.laposte.net [193.253.67.230]) by ietfa.amsl.com (Postfix) with ESMTP id B6EF021F8475 for ; Tue, 17 Apr 2012 01:52:02 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8510-out with ME id ywrz1i00437Y3f403wrzck; Tue, 17 Apr 2012 10:52:00 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4F8D17AD.7080907@gmail.com> Date: Tue, 17 Apr 2012 10:51:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <20966399-05D0-4294-B9EC-9AA55DEB390D@laposte.net> References: <7E1BD96D-E7EC-4C78-B382-66F0F694DAA4@laposte.net> <1825062D-D4EB-4310-A2BA-8B8F3870B9B4@laposte.net> <22BD6607-5DEC-48F3-B2E5-DCEECC9EF643@laposte.net> <986EAD24-4612-4AD0-B366-012BA0B3751C@laposte.net> <5258F2DA-D61A-4327-B7FC-2BD67743C994@laposte.net> <4F8D17AD.7080907@gmail.com> To: Lorenzo Colitti , Brian Carpenter , Cameron Byrne X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] A way forward for 464XLAT - using BIH X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 08:52:04 -0000 Lorenzo, Brian, Cameron, Let me explain more. 1. The 464XLAT use case is: (IPv4-only client) LAN =20 (CLAT router) OR (IPv4 appli in CLAT host) =20 || \/ *IPv6-only network* (NAT64) IPv4 Internet (IPv4 server) 2. With BIH in the CLAT CPE, a complementary use case is also available: (IPv4-only client) LAN =20 (CLAT router) =20 || \/ *IPv6-only network* IPv6-Internet *IPv6-only network 2* (IPv6-capable server) =20 Thus, although Network 2 is IPv6 only, its servers remain reachable by = some IPv4-only clients. This contributes to facilitate commercial deployments of IPv6-only = networks, an objective of IETF AFAIK. 3. Conclusion: - RFC6535 does exist on standard track - 464XLAT purpose is to facilitate deployments and use of IPv6-only = networks. - It does this better if combined there is BIH in CLAT nodes. Having not been involved in BIH specification, I feel free to ask for = "no NIH for BIH". 4. Sorry for having mixed in a previous email what applies to = router-supporting hosts with what only applies to router-less hosts. = Contrary to what I wrote, the BIH variant that must be used in = router-supporting hosts (and may be used in router-less hosts) is the = network-layer variant.=20 The node architecture is then: +---------------------------------+ | | | IPv4 stack IPv6 stack | | | | | | +------------+ | | | | NAT44 | | | | +------------+ | | | | | | | +-----------------------+ | | | BIH | | | +-----------------------+ | | | | | IPv6 WAN interface | +---------------------------------+ 5. I will carefully read the newly posted 464XLAT draft, and comment = next. In the mean time, comments on the above are welcome. Regards, RD Le 2012-04-17 =E0 09:11, Brian E Carpenter a =E9crit : > On 2012-04-17 02:48, Lorenzo Colitti wrote: > ... >> I disagree that getting IPv4-only applications to communicate with >> IPv6-only servers is an important goal that we should pursue now. >>=20 >> Servers will need to stay IPv4-capable for many years anyway, in = order to >> continue to support IPv4-only client OSes and networks. So we'd be = solving >> a problem that doesn't actually exist today. >=20 > I agree strongly. No rational economic actor will attempt to provide = an > IPv6-only application service for many years. There really isn't a = shortage > of IPv4 addresses for content provision or other application services, = and > there are a few billion IPv4 customers out there. >=20 > To be clear, this does not rule out running IPv6-only servers fronted > by some form of NAT46; some operators might conclude that this would > reduce OPEX. But the service offered to the Internet would then appear > to be dual stacked. >=20 > This seems to be completely orthogonal to the 464XLAT use case. >=20 > Brian From phdgang@gmail.com Tue Apr 17 07:08:32 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51DED21F84B9 for ; Tue, 17 Apr 2012 07:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=-1.650, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_74=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QduHEpAwrYhT for ; Tue, 17 Apr 2012 07:08:28 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id A998B21F84E1 for ; Tue, 17 Apr 2012 07:08:27 -0700 (PDT) Received: by wibhj6 with SMTP id hj6so457962wib.13 for ; Tue, 17 Apr 2012 07:08:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=yk+ejbn45RlvXPL6D4Jsv7Depe4nuiyV4AL54lVY7iI=; b=QuFo5+0Rsg2H1MB0qErN2y9ihuX3f6FMNa56u519NSGK9ULtMzHMHiATudAiJyK2FW Ns35HUrKjI/iu9fY8pn+5ghheP+79zHgBT9SkOcuU3XM+BDfefFd2EobIj2lfn3gz6vb 2zO1uFer6Kvyo7fKaodavrkAysFU/eM0gAQ2CeeL176JR950KXLTOwiDXcs5asT7wv/f O2KYaZjh8sGYv4wWBfit9LnE33rHL2LYN+FYrRbFQWY8hoH7nI5P4xE+TLLRksTZQSLx hfwTLrnUWZInKsz/CyQgqeu01JnOsODrpCQX4rNMVO5fJon68U5n2Tbb9qF6PipHk/iw jZtA== MIME-Version: 1.0 Received: by 10.216.133.96 with SMTP id p74mr9466975wei.30.1334671706665; Tue, 17 Apr 2012 07:08:26 -0700 (PDT) Received: by 10.180.100.97 with HTTP; Tue, 17 Apr 2012 07:08:26 -0700 (PDT) In-Reply-To: <20966399-05D0-4294-B9EC-9AA55DEB390D@laposte.net> References: <7E1BD96D-E7EC-4C78-B382-66F0F694DAA4@laposte.net> <1825062D-D4EB-4310-A2BA-8B8F3870B9B4@laposte.net> <22BD6607-5DEC-48F3-B2E5-DCEECC9EF643@laposte.net> <986EAD24-4612-4AD0-B366-012BA0B3751C@laposte.net> <5258F2DA-D61A-4327-B7FC-2BD67743C994@laposte.net> <4F8D17AD.7080907@gmail.com> <20966399-05D0-4294-B9EC-9AA55DEB390D@laposte.net> Date: Tue, 17 Apr 2012 22:08:26 +0800 Message-ID: From: GangChen To: =?ISO-8859-1?B?UultaSBEZXNwculz?= , Lorenzo Colitti , Brian Carpenter , Cameron Byrne Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops WG Subject: Re: [v6ops] A way forward for 464XLAT - using BIH X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 14:08:32 -0000 Hello Cameron,Remi, Lorenzo, Brian, As an implementer of BIH, please allow me to share some experiences in 464XLAT contexts. We implemented/tested BIH on both wireless and wireline network in 464 mann= er. Two variants had been developed as listed below. 1) OMS(Android based OS) + BIH with DNS64/NAT64 The mobile handset is a U900 phone (produced by ZTE, OMS 2.0) running the BIH software. NAT64 prefix is preconfigured on the phone Stateful NAT64 and DNS64 are located on a network side. We have tested several applications including Skype, instant message (MSN/QQ/Fetion), HTTP, VoD, etc The outcomes indicate all the tested apps could be supported transparently based on embeded BIH modules This demonstration had been formally shown at 3GPPSA2#85 meeting. http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_85_XiAN/docs/S2-112437.zip 2) PON CPE+BIH with DNS64/NAT64 We implemented BIH on CPE (i.e. ZXA10 F660)as well. Two scenarios are considered so far Scenario 1: IPv4 hosts connect BIH-CPE to access IPv4 server through IPv6 network Scenario 2: IPv4 hosts connect BIH-CPE to access IPv6 server located in IPv6 network Different applications have been tested, including Skype,MSN,... All test cases were passed. We don't see any problem. Please see the report for more information http://code.google.com/p/bump-in-the-host/downloads/list Gang 2012/4/17, R=E9mi Despr=E9s : > Lorenzo, Brian, Cameron, > > Let me explain more. > > 1. The 464XLAT use case is: > > (IPv4-only client) > LAN > (CLAT router) OR (IPv4 appli in CLAT host) > || > \/ > *IPv6-only network* > (NAT64) > IPv4 Internet > (IPv4 server) > > 2. With BIH in the CLAT CPE, a complementary use case is also available: > > > (IPv4-only client) > LAN > (CLAT router) > || > \/ > *IPv6-only network* > IPv6-Internet > *IPv6-only network 2* > (IPv6-capable server) > > Thus, although Network 2 is IPv6 only, its servers remain reachable by so= me > IPv4-only clients. > This contributes to facilitate commercial deployments of IPv6-only networ= ks, > an objective of IETF AFAIK. > > 3. Conclusion: > - RFC6535 does exist on standard track > - 464XLAT purpose is to facilitate deployments and use of IPv6-only > networks. > - It does this better if combined there is BIH in CLAT nodes. > > Having not been involved in BIH specification, I feel free to ask for "no > NIH for BIH". > > 4. Sorry for having mixed in a previous email what applies to > router-supporting hosts with what only applies to router-less hosts. > Contrary to what I wrote, the BIH variant that must be used in > router-supporting hosts (and may be used in router-less hosts) is the > network-layer variant. > > The node architecture is then: > +---------------------------------+ > | | > | IPv4 stack IPv6 stack | > | | | | > | +------------+ | | > | | NAT44 | | | > | +------------+ | | > | | | | > | +-----------------------+ | > | | BIH | | > | +-----------------------+ | > | | | > | IPv6 WAN interface | > +---------------------------------+ > > 5. I will carefully read the newly posted 464XLAT draft, and comment next= . > In the mean time, comments on the above are welcome. > > > Regards, > RD > > > > Le 2012-04-17 =E0 09:11, Brian E Carpenter a =E9crit : > >> On 2012-04-17 02:48, Lorenzo Colitti wrote: >> ... >>> I disagree that getting IPv4-only applications to communicate with >>> IPv6-only servers is an important goal that we should pursue now. >>> >>> Servers will need to stay IPv4-capable for many years anyway, in order = to >>> continue to support IPv4-only client OSes and networks. So we'd be >>> solving >>> a problem that doesn't actually exist today. >> >> I agree strongly. No rational economic actor will attempt to provide an >> IPv6-only application service for many years. There really isn't a >> shortage >> of IPv4 addresses for content provision or other application services, a= nd >> there are a few billion IPv4 customers out there. >> >> To be clear, this does not rule out running IPv6-only servers fronted >> by some form of NAT46; some operators might conclude that this would >> reduce OPEX. But the service offered to the Internet would then appear >> to be dual stacked. >> >> This seems to be completely orthogonal to the 464XLAT use case. >> >> Brian > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From despres.remi@laposte.net Tue Apr 17 07:21:30 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EAAE11E80B3 for ; Tue, 17 Apr 2012 07:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.721 X-Spam-Level: X-Spam-Status: No, score=-0.721 tagged_above=-999 required=5 tests=[AWL=-1.422, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_74=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 TjJB7pd+nJDT for ; Tue, 17 Apr 2012 07:21:26 -0700 (PDT) Received: from smtpout.laposte.net (smtpout1.laposte.net [193.253.67.226]) by ietfa.amsl.com (Postfix) with ESMTP id 5F89411E80A4 for ; Tue, 17 Apr 2012 07:21:24 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8502-out with ME id z2MM1i00437Y3f4032MMpJ; Tue, 17 Apr 2012 16:21:23 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 17 Apr 2012 16:21:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8525AD03-4109-4BC5-997B-5E29B86C4747@laposte.net> References: <7E1BD96D-E7EC-4C78-B382-66F0F694DAA4@laposte.net> <1825062D-D4EB-4310-A2BA-8B8F3870B9B4@laposte.net> <22BD6607-5DEC-48F3-B2E5-DCEECC9EF643@laposte.net> <986EAD24-4612-4AD0-B366-012BA0B3751C@laposte.net> <5258F2DA-D61A-4327-B7FC-2BD67743C994@laposte.net> <4F8D17AD.7080907@gmail.com> <20966399-05D0-4294-B9EC-9AA55DEB390D@laposte.net> To: GangChen X-Mailer: Apple Mail (2.1084) Cc: v6ops WG , Cameron Byrne Subject: Re: [v6ops] A way forward for 464XLAT - using BIH X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 14:21:30 -0000 Le 2012-04-17 =E0 16:08, GangChen a =E9crit : > Hello Cameron,Remi, Lorenzo, Brian, >=20 > As an implementer of BIH, please allow me to share some experiences in > 464XLAT contexts. >=20 > We implemented/tested BIH on both wireless and wireline network in 464 = manner. > Two variants had been developed as listed below. >=20 >=20 > 1) OMS(Android based OS) + BIH with DNS64/NAT64 >=20 > The mobile handset is a U900 phone (produced by ZTE, OMS 2.0) running > the BIH software. > NAT64 prefix is preconfigured on the phone > Stateful NAT64 and DNS64 are located on a network side. > We have tested several applications including Skype, In this scenario, is it right that it illustrates that BIH can be used = by applications that use referrals (and don't use the DNS)? Thanks. RD > instant message > (MSN/QQ/Fetion), HTTP, VoD, etc > The outcomes indicate all the tested apps could be supported > transparently based on embeded BIH modules > This demonstration had been formally shown at 3GPPSA2#85 meeting. > = http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_85_XiAN/docs/S2-112437.zip >=20 >=20 > 2) PON CPE+BIH with DNS64/NAT64 >=20 > We implemented BIH on CPE (i.e. ZXA10 F660)as well. > Two scenarios are considered so far > Scenario 1: IPv4 hosts connect BIH-CPE to access IPv4 server through > IPv6 network > Scenario 2: IPv4 hosts connect BIH-CPE to access IPv6 server located > in IPv6 network > Different applications have been tested, including Skype,MSN,... > All test cases were passed. We don't see any problem. > Please see the report for more information > http://code.google.com/p/bump-in-the-host/downloads/list >=20 >=20 > Gang >=20 > 2012/4/17, R=E9mi Despr=E9s : >> Lorenzo, Brian, Cameron, >>=20 >> Let me explain more. >>=20 >> 1. The 464XLAT use case is: >>=20 >> (IPv4-only client) >> LAN >> (CLAT router) OR (IPv4 appli in CLAT host) >> || >> \/ >> *IPv6-only network* >> (NAT64) >> IPv4 Internet >> (IPv4 server) >>=20 >> 2. With BIH in the CLAT CPE, a complementary use case is also = available: >>=20 >>=20 >> (IPv4-only client) >> LAN >> (CLAT router) >> || >> \/ >> *IPv6-only network* >> IPv6-Internet >> *IPv6-only network 2* >> (IPv6-capable server) >>=20 >> Thus, although Network 2 is IPv6 only, its servers remain reachable = by some >> IPv4-only clients. >> This contributes to facilitate commercial deployments of IPv6-only = networks, >> an objective of IETF AFAIK. >>=20 >> 3. Conclusion: >> - RFC6535 does exist on standard track >> - 464XLAT purpose is to facilitate deployments and use of IPv6-only >> networks. >> - It does this better if combined there is BIH in CLAT nodes. >>=20 >> Having not been involved in BIH specification, I feel free to ask for = "no >> NIH for BIH". >>=20 >> 4. Sorry for having mixed in a previous email what applies to >> router-supporting hosts with what only applies to router-less hosts. >> Contrary to what I wrote, the BIH variant that must be used in >> router-supporting hosts (and may be used in router-less hosts) is the >> network-layer variant. >>=20 >> The node architecture is then: >> +---------------------------------+ >> | | >> | IPv4 stack IPv6 stack | >> | | | | >> | +------------+ | | >> | | NAT44 | | | >> | +------------+ | | >> | | | | >> | +-----------------------+ | >> | | BIH | | >> | +-----------------------+ | >> | | | >> | IPv6 WAN interface | >> +---------------------------------+ >>=20 >> 5. I will carefully read the newly posted 464XLAT draft, and comment = next. >> In the mean time, comments on the above are welcome. >>=20 >>=20 >> Regards, >> RD >>=20 >>=20 >>=20 >> Le 2012-04-17 =E0 09:11, Brian E Carpenter a =E9crit : >>=20 >>> On 2012-04-17 02:48, Lorenzo Colitti wrote: >>> ... >>>> I disagree that getting IPv4-only applications to communicate with >>>> IPv6-only servers is an important goal that we should pursue now. >>>>=20 >>>> Servers will need to stay IPv4-capable for many years anyway, in = order to >>>> continue to support IPv4-only client OSes and networks. So we'd be >>>> solving >>>> a problem that doesn't actually exist today. >>>=20 >>> I agree strongly. No rational economic actor will attempt to provide = an >>> IPv6-only application service for many years. There really isn't a >>> shortage >>> of IPv4 addresses for content provision or other application = services, and >>> there are a few billion IPv4 customers out there. >>>=20 >>> To be clear, this does not rule out running IPv6-only servers = fronted >>> by some form of NAT46; some operators might conclude that this would >>> reduce OPEX. But the service offered to the Internet would then = appear >>> to be dual stacked. >>>=20 >>> This seems to be completely orthogonal to the 464XLAT use case. >>>=20 >>> Brian >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 From phdgang@gmail.com Tue Apr 17 07:28:25 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9392C11E8085 for ; Tue, 17 Apr 2012 07:28:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[AWL=-1.100, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_74=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id famDsnio+GpV for ; Tue, 17 Apr 2012 07:28:21 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id EDB9711E8081 for ; Tue, 17 Apr 2012 07:28:20 -0700 (PDT) Received: by wibhq7 with SMTP id hq7so543073wib.13 for ; Tue, 17 Apr 2012 07:28:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=KJXTvmFoBxbepqfdy3fg4hHAwa0+wl0JdmGfg3FIodk=; b=yy5wyRPrZ5CQTVg8mbzZE2DPy8pOXcEWDnjyVkpKZvRzUo/ioXH+GiTlS/dpTIvysd B/HfxHilGAvYa/ascUy0ghj+EtqaRYkINxdIPBXWkJ15M34JoV24bOlPNy459B3I1hAf hVRq8LMfM7pwlFxDafMQ/P8HAZDA19Vg88PU3GBroTLTIubLcvIZj2DedmUfYUI61D7g NC9LOhVNjnK/nKlLVSIB1VCWcLBiNzc6xMbAbHJuVAaoe1p0cl9uY2dx1CDcq52DoVa9 N8L3zA4b0c4uZPqqeeGmwMu30LBTg6G262VKzCgBSkrWiH2co/AYiqmmwPZChSmpkQLj uonA== MIME-Version: 1.0 Received: by 10.216.133.96 with SMTP id p74mr9508775wei.30.1334672900066; Tue, 17 Apr 2012 07:28:20 -0700 (PDT) Received: by 10.180.100.97 with HTTP; Tue, 17 Apr 2012 07:28:20 -0700 (PDT) In-Reply-To: <8525AD03-4109-4BC5-997B-5E29B86C4747@laposte.net> References: <7E1BD96D-E7EC-4C78-B382-66F0F694DAA4@laposte.net> <1825062D-D4EB-4310-A2BA-8B8F3870B9B4@laposte.net> <22BD6607-5DEC-48F3-B2E5-DCEECC9EF643@laposte.net> <986EAD24-4612-4AD0-B366-012BA0B3751C@laposte.net> <5258F2DA-D61A-4327-B7FC-2BD67743C994@laposte.net> <4F8D17AD.7080907@gmail.com> <20966399-05D0-4294-B9EC-9AA55DEB390D@laposte.net> <8525AD03-4109-4BC5-997B-5E29B86C4747@laposte.net> Date: Tue, 17 Apr 2012 22:28:20 +0800 Message-ID: From: GangChen To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops WG , Cameron Byrne Subject: Re: [v6ops] A way forward for 464XLAT - using BIH X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 14:28:25 -0000 2012/4/17, R=E9mi Despr=E9s : > > Le 2012-04-17 =E0 16:08, GangChen a =E9crit : > >> Hello Cameron,Remi, Lorenzo, Brian, >> >> As an implementer of BIH, please allow me to share some experiences in >> 464XLAT contexts. >> >> We implemented/tested BIH on both wireless and wireline network in 464 >> manner. >> Two variants had been developed as listed below. >> >> >> 1) OMS(Android based OS) + BIH with DNS64/NAT64 >> >> The mobile handset is a U900 phone (produced by ZTE, OMS 2.0) running >> the BIH software. >> NAT64 prefix is preconfigured on the phone >> Stateful NAT64 and DNS64 are located on a network side. > >> We have tested several applications including Skype, > > In this scenario, is it right that it illustrates that BIH can be used by > applications that use referrals (and don't use the DNS)? Positive. because the preconfigured nat64 prefix. Gang PS: Is this RFC6535+RFC6052? > Thanks. > > RD > > >> instant message >> (MSN/QQ/Fetion), HTTP, VoD, etc >> The outcomes indicate all the tested apps could be supported >> transparently based on embeded BIH modules >> This demonstration had been formally shown at 3GPPSA2#85 meeting. >> http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_85_XiAN/docs/S2-112437.zip >> >> >> 2) PON CPE+BIH with DNS64/NAT64 >> >> We implemented BIH on CPE (i.e. ZXA10 F660)as well. >> Two scenarios are considered so far >> Scenario 1: IPv4 hosts connect BIH-CPE to access IPv4 server through >> IPv6 network >> Scenario 2: IPv4 hosts connect BIH-CPE to access IPv6 server located >> in IPv6 network >> Different applications have been tested, including Skype,MSN,... >> All test cases were passed. We don't see any problem. >> Please see the report for more information >> http://code.google.com/p/bump-in-the-host/downloads/list >> >> >> Gang >> >> 2012/4/17, R=E9mi Despr=E9s : >>> Lorenzo, Brian, Cameron, >>> >>> Let me explain more. >>> >>> 1. The 464XLAT use case is: >>> >>> (IPv4-only client) >>> LAN >>> (CLAT router) OR (IPv4 appli in CLAT host) >>> || >>> \/ >>> *IPv6-only network* >>> (NAT64) >>> IPv4 Internet >>> (IPv4 server) >>> >>> 2. With BIH in the CLAT CPE, a complementary use case is also available= : >>> >>> >>> (IPv4-only client) >>> LAN >>> (CLAT router) >>> || >>> \/ >>> *IPv6-only network* >>> IPv6-Internet >>> *IPv6-only network 2* >>> (IPv6-capable server) >>> >>> Thus, although Network 2 is IPv6 only, its servers remain reachable by >>> some >>> IPv4-only clients. >>> This contributes to facilitate commercial deployments of IPv6-only >>> networks, >>> an objective of IETF AFAIK. >>> >>> 3. Conclusion: >>> - RFC6535 does exist on standard track >>> - 464XLAT purpose is to facilitate deployments and use of IPv6-only >>> networks. >>> - It does this better if combined there is BIH in CLAT nodes. >>> >>> Having not been involved in BIH specification, I feel free to ask for "= no >>> NIH for BIH". >>> >>> 4. Sorry for having mixed in a previous email what applies to >>> router-supporting hosts with what only applies to router-less hosts. >>> Contrary to what I wrote, the BIH variant that must be used in >>> router-supporting hosts (and may be used in router-less hosts) is the >>> network-layer variant. >>> >>> The node architecture is then: >>> +---------------------------------+ >>> | | >>> | IPv4 stack IPv6 stack | >>> | | | | >>> | +------------+ | | >>> | | NAT44 | | | >>> | +------------+ | | >>> | | | | >>> | +-----------------------+ | >>> | | BIH | | >>> | +-----------------------+ | >>> | | | >>> | IPv6 WAN interface | >>> +---------------------------------+ >>> >>> 5. I will carefully read the newly posted 464XLAT draft, and comment >>> next. >>> In the mean time, comments on the above are welcome. >>> >>> >>> Regards, >>> RD >>> >>> >>> >>> Le 2012-04-17 =E0 09:11, Brian E Carpenter a =E9crit : >>> >>>> On 2012-04-17 02:48, Lorenzo Colitti wrote: >>>> ... >>>>> I disagree that getting IPv4-only applications to communicate with >>>>> IPv6-only servers is an important goal that we should pursue now. >>>>> >>>>> Servers will need to stay IPv4-capable for many years anyway, in orde= r >>>>> to >>>>> continue to support IPv4-only client OSes and networks. So we'd be >>>>> solving >>>>> a problem that doesn't actually exist today. >>>> >>>> I agree strongly. No rational economic actor will attempt to provide a= n >>>> IPv6-only application service for many years. There really isn't a >>>> shortage >>>> of IPv4 addresses for content provision or other application services, >>>> and >>>> there are a few billion IPv4 customers out there. >>>> >>>> To be clear, this does not rule out running IPv6-only servers fronted >>>> by some form of NAT46; some operators might conclude that this would >>>> reduce OPEX. But the service offered to the Internet would then appear >>>> to be dual stacked. >>>> >>>> This seems to be completely orthogonal to the 464XLAT use case. >>>> >>>> Brian >>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> > > From despres.remi@laposte.net Tue Apr 17 07:53:40 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D46D21F841B for ; Tue, 17 Apr 2012 07:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.694 X-Spam-Level: X-Spam-Status: No, score=-0.694 tagged_above=-999 required=5 tests=[AWL=-1.395, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_74=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 xE9z-DaYClBS for ; Tue, 17 Apr 2012 07:53:36 -0700 (PDT) Received: from smtpout.laposte.net (smtpout1.laposte.net [193.253.67.226]) by ietfa.amsl.com (Postfix) with ESMTP id E725A11E8088 for ; Tue, 17 Apr 2012 07:53:35 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8501-out with ME id z2tZ1i00237Y3f4032tZyH; Tue, 17 Apr 2012 16:53:34 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 17 Apr 2012 16:51:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7E1BD96D-E7EC-4C78-B382-66F0F694DAA4@laposte.net> <1825062D-D4EB-4310-A2BA-8B8F3870B9B4@laposte.net> <22BD6607-5DEC-48F3-B2E5-DCEECC9EF643@laposte.net> <986EAD24-4612-4AD0-B366-012BA0B3751C@laposte.net> <5258F2DA-D61A-4327-B7FC-2BD67743C994@laposte.net> <4F8D17AD.7080907@gmail.com> <20966399-05D0-4294-B9EC-9AA55DEB390D@laposte.net> <8525AD03-4109-4BC5-997B-5E29B86C4747@laposte.net> To: GangChen X-Mailer: Apple Mail (2.1084) Cc: v6ops WG , Cameron Byrne Subject: Re: [v6ops] A way forward for 464XLAT - using BIH X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 14:53:40 -0000 Le 2012-04-17 =E0 16:28, GangChen a =E9crit : > 2012/4/17, R=E9mi Despr=E9s : >>=20 >> Le 2012-04-17 =E0 16:08, GangChen a =E9crit : >>=20 >>> Hello Cameron,Remi, Lorenzo, Brian, >>>=20 >>> As an implementer of BIH, please allow me to share some experiences = in >>> 464XLAT contexts. >>>=20 >>> We implemented/tested BIH on both wireless and wireline network in = 464 >>> manner. >>> Two variants had been developed as listed below. >>>=20 >>>=20 >>> 1) OMS(Android based OS) + BIH with DNS64/NAT64 >>>=20 >>> The mobile handset is a U900 phone (produced by ZTE, OMS 2.0) = running >>> the BIH software. >>> NAT64 prefix is preconfigured on the phone >>> Stateful NAT64 and DNS64 are located on a network side. >>=20 >>> We have tested several applications including Skype, >>=20 >> In this scenario, is it right that it illustrates that BIH can be = used by >> applications that use referrals (and don't use the DNS)? >=20 > Positive. because the preconfigured nat64 prefix. >=20 > Gang >=20 > PS: Is this RFC6535+RFC6052? In my understanding, that's the combination that makes it work. Actually, since RFC6535, in its network-layer variant, explicitly refers = to RFC 6145, which explicitly refers to RFC6052, that's just using BIH = as is ;-). RD >=20 >> Thanks. >>=20 >> RD >>=20 >>=20 >>> instant message >>> (MSN/QQ/Fetion), HTTP, VoD, etc >>> The outcomes indicate all the tested apps could be supported >>> transparently based on embeded BIH modules >>> This demonstration had been formally shown at 3GPPSA2#85 meeting. >>> = http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_85_XiAN/docs/S2-112437.zip >>>=20 >>>=20 >>> 2) PON CPE+BIH with DNS64/NAT64 >>>=20 >>> We implemented BIH on CPE (i.e. ZXA10 F660)as well. >>> Two scenarios are considered so far >>> Scenario 1: IPv4 hosts connect BIH-CPE to access IPv4 server through >>> IPv6 network >>> Scenario 2: IPv4 hosts connect BIH-CPE to access IPv6 server located >>> in IPv6 network >>> Different applications have been tested, including Skype,MSN,... >>> All test cases were passed. We don't see any problem. >>> Please see the report for more information >>> http://code.google.com/p/bump-in-the-host/downloads/list >>>=20 >>>=20 >>> Gang >>>=20 >>> 2012/4/17, R=E9mi Despr=E9s : >>>> Lorenzo, Brian, Cameron, >>>>=20 >>>> Let me explain more. >>>>=20 >>>> 1. The 464XLAT use case is: >>>>=20 >>>> (IPv4-only client) >>>> LAN >>>> (CLAT router) OR (IPv4 appli in CLAT host) >>>> || >>>> \/ >>>> *IPv6-only network* >>>> (NAT64) >>>> IPv4 Internet >>>> (IPv4 server) >>>>=20 >>>> 2. With BIH in the CLAT CPE, a complementary use case is also = available: >>>>=20 >>>>=20 >>>> (IPv4-only client) >>>> LAN >>>> (CLAT router) >>>> || >>>> \/ >>>> *IPv6-only network* >>>> IPv6-Internet >>>> *IPv6-only network 2* >>>> (IPv6-capable server) >>>>=20 >>>> Thus, although Network 2 is IPv6 only, its servers remain reachable = by >>>> some >>>> IPv4-only clients. >>>> This contributes to facilitate commercial deployments of IPv6-only >>>> networks, >>>> an objective of IETF AFAIK. >>>>=20 >>>> 3. Conclusion: >>>> - RFC6535 does exist on standard track >>>> - 464XLAT purpose is to facilitate deployments and use of IPv6-only >>>> networks. >>>> - It does this better if combined there is BIH in CLAT nodes. >>>>=20 >>>> Having not been involved in BIH specification, I feel free to ask = for "no >>>> NIH for BIH". >>>>=20 >>>> 4. Sorry for having mixed in a previous email what applies to >>>> router-supporting hosts with what only applies to router-less = hosts. >>>> Contrary to what I wrote, the BIH variant that must be used in >>>> router-supporting hosts (and may be used in router-less hosts) is = the >>>> network-layer variant. >>>>=20 >>>> The node architecture is then: >>>> +---------------------------------+ >>>> | | >>>> | IPv4 stack IPv6 stack | >>>> | | | | >>>> | +------------+ | | >>>> | | NAT44 | | | >>>> | +------------+ | | >>>> | | | | >>>> | +-----------------------+ | >>>> | | BIH | | >>>> | +-----------------------+ | >>>> | | | >>>> | IPv6 WAN interface | >>>> +---------------------------------+ >>>>=20 >>>> 5. I will carefully read the newly posted 464XLAT draft, and = comment >>>> next. >>>> In the mean time, comments on the above are welcome. >>>>=20 >>>>=20 >>>> Regards, >>>> RD >>>>=20 >>>>=20 >>>>=20 >>>> Le 2012-04-17 =E0 09:11, Brian E Carpenter a =E9crit : >>>>=20 >>>>> On 2012-04-17 02:48, Lorenzo Colitti wrote: >>>>> ... >>>>>> I disagree that getting IPv4-only applications to communicate = with >>>>>> IPv6-only servers is an important goal that we should pursue now. >>>>>>=20 >>>>>> Servers will need to stay IPv4-capable for many years anyway, in = order >>>>>> to >>>>>> continue to support IPv4-only client OSes and networks. So we'd = be >>>>>> solving >>>>>> a problem that doesn't actually exist today. >>>>>=20 >>>>> I agree strongly. No rational economic actor will attempt to = provide an >>>>> IPv6-only application service for many years. There really isn't a >>>>> shortage >>>>> of IPv4 addresses for content provision or other application = services, >>>>> and >>>>> there are a few billion IPv4 customers out there. >>>>>=20 >>>>> To be clear, this does not rule out running IPv6-only servers = fronted >>>>> by some form of NAT46; some operators might conclude that this = would >>>>> reduce OPEX. But the service offered to the Internet would then = appear >>>>> to be dual stacked. >>>>>=20 >>>>> This seems to be completely orthogonal to the 464XLAT use case. >>>>>=20 >>>>> Brian >>>>=20 >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>=20 >>=20 >>=20 From brian.e.carpenter@gmail.com Tue Apr 17 07:53:46 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 038E011E80AA for ; Tue, 17 Apr 2012 07:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.437 X-Spam-Level: X-Spam-Status: No, score=-101.437 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pe6Re0uuhEci for ; Tue, 17 Apr 2012 07:53:45 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id A716E11E80BD for ; Tue, 17 Apr 2012 07:53:44 -0700 (PDT) Received: by bkuw5 with SMTP id w5so5846800bku.31 for ; Tue, 17 Apr 2012 07:53:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=zVZaCYNulLDHmt8ddkug5Q62EKsZqXjRVKhNLwAH2Jg=; b=LbIi5uTWR2Ahy53WadNGpDYawTuj3KUKCO/Uq2FeM78du+MXa1cE0csYye8U2o6/er 7bs+qo7kM6Fdnvr34KxjX5GTXv94nmel3nxgmW8RgV4GiZM4D3ilCuwSiYsPVZ9kL6Jl 8sgcZ9D4OM+S0pp4eQgbLbJzCtE1wJahKhm+nYxSW957xo/3PAr/e5GWiyOTDZ1l2c/r QLbJ8wm9oeWqdn9Ni+EHI8gZGZT2DefW0XjsnfA4U/MbHZdJuF0r8FNbv9zp/Oxnep6Q bEfAoMIk+rc4qH6kplbrsbuet5vg/Epfrt78UKlJYX602YEHcPcGQDAH5O3f1uGrdX00 gyEQ== Received: by 10.205.137.14 with SMTP id im14mr4929094bkc.137.1334674423757; Tue, 17 Apr 2012 07:53:43 -0700 (PDT) Received: from [192.168.1.69] (host-2-102-216-233.as13285.net. [2.102.216.233]) by mx.google.com with ESMTPS id jr13sm38540109bkb.14.2012.04.17.07.53.41 (version=SSLv3 cipher=OTHER); Tue, 17 Apr 2012 07:53:42 -0700 (PDT) Message-ID: <4F8D83F4.80908@gmail.com> Date: Tue, 17 Apr 2012 15:53:40 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= References: <7E1BD96D-E7EC-4C78-B382-66F0F694DAA4@laposte.net> <1825062D-D4EB-4310-A2BA-8B8F3870B9B4@laposte.net> <22BD6607-5DEC-48F3-B2E5-DCEECC9EF643@laposte.net> <986EAD24-4612-4AD0-B366-012BA0B3751C@laposte.net> <5258F2DA-D61A-4327-B7FC-2BD67743C994@laposte.net> <4F8D17AD.7080907@gmail.com> <20966399-05D0-4294-B9EC-9AA55DEB390D@laposte.net> In-Reply-To: <20966399-05D0-4294-B9EC-9AA55DEB390D@laposte.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: v6ops WG , Cameron Byrne Subject: Re: [v6ops] A way forward for 464XLAT - using BIH X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 14:53:46 -0000 Bonjour R=C3=A9mi, On 2012-04-17 09:51, R=C3=A9mi Despr=C3=A9s wrote: =2E.. > Thus, although Network 2 is IPv6 only, its servers remain reachable by = some IPv4-only clients. > This contributes to facilitate commercial deployments of IPv6-only netw= orks, an objective of IETF AFAIK. Really? As far as I know we have always suggested that dual stack was the preferred deployment model. Certainly if I was a commercial application layer provider, I would not consider using an IPv6-only ISP for one moment, because that would disadvantage my IPv4 customers. Note, this is not a comment on the technology, but on whether there's a real operational use case today. Brian From gert@space.net Tue Apr 17 07:58:18 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A6E821F8557 for ; Tue, 17 Apr 2012 07:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7-iGd4B7NE3w for ; Tue, 17 Apr 2012 07:58:17 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7118721F8551 for ; Tue, 17 Apr 2012 07:58:17 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 2172FF8A9C for ; Tue, 17 Apr 2012 16:58:16 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 054DFF8A90 for ; Tue, 17 Apr 2012 16:58:16 +0200 (CEST) Received: (qmail 70206 invoked by uid 1007); 17 Apr 2012 16:58:15 +0200 Date: Tue, 17 Apr 2012 16:58:15 +0200 From: Gert Doering To: Brian E Carpenter Message-ID: <20120417145815.GA37149@Space.Net> References: <986EAD24-4612-4AD0-B366-012BA0B3751C@laposte.net> <5258F2DA-D61A-4327-B7FC-2BD67743C994@laposte.net> <4F8D17AD.7080907@gmail.com> <20966399-05D0-4294-B9EC-9AA55DEB390D@laposte.net> <4F8D83F4.80908@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F8D83F4.80908@gmail.com> X-NCC-RegID: de.space X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.21 (2010-09-15) Cc: v6ops WG , Cameron Byrne Subject: Re: [v6ops] A way forward for 464XLAT - using BIH X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 14:58:18 -0000 Hi, On Tue, Apr 17, 2012 at 03:53:40PM +0100, Brian E Carpenter wrote: > Really? As far as I know we have always suggested that dual stack was > the preferred deployment model. Certainly if I was a commercial > application layer provider, I would not consider using an IPv6-only > ISP for one moment, because that would disadvantage my IPv4 customers. >From an operator perspective, serving content, I do not see any benefit in going to IPv6-only-content any time soon. Content needs to be dual-stacked. OTOH, I see great value in IPv6-single-stacking eyeballs (plus adding a client-ISP side NAT64+DNS64 for v4-only content). Not everybody, not right away, but "soon". Gert Doering -- Operator -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From despres.remi@laposte.net Tue Apr 17 08:02:28 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF9C21F8568 for ; Tue, 17 Apr 2012 08:02:28 -0700 (PDT) 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.156, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id icOWm1q-CtTk for ; Tue, 17 Apr 2012 08:02:27 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 911C821F8566 for ; Tue, 17 Apr 2012 08:02:25 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id A55CF9401EB; Tue, 17 Apr 2012 17:02:14 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4F8D83F4.80908@gmail.com> Date: Tue, 17 Apr 2012 17:02:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7E1BD96D-E7EC-4C78-B382-66F0F694DAA4@laposte.net> <1825062D-D4EB-4310-A2BA-8B8F3870B9B4@laposte.net> <22BD6607-5DEC-48F3-B2E5-DCEECC9EF643@laposte.net> <986EAD24-4612-4AD0-B366-012BA0B3751C@laposte.net> <5258F2DA-D61A-4327-B7FC-2BD67743C994@laposte.net> <4F8D17AD.7080907@gmail.com> <20966399-05D0-4294-B9EC-9AA55DEB390D@laposte.net> <4F8D83F4.80908@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1084) Cc: v6ops WG , Cameron Byrne Subject: Re: [v6ops] A way forward for 464XLAT - using BIH X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 15:02:28 -0000 Le 2012-04-17 =E0 16:53, Brian E Carpenter a =E9crit : >=20 > Bonjour R=E9mi, >=20 > On 2012-04-17 09:51, R=E9mi Despr=E9s wrote: > ... >> Thus, although Network 2 is IPv6 only, its servers remain reachable = by some IPv4-only clients. >> This contributes to facilitate commercial deployments of IPv6-only = networks, an objective of IETF AFAIK. >=20 > Really? As far as I know we have always suggested that dual stack was > the preferred deployment model. Certainly if I was a commercial > application layer provider, I would not consider using an IPv6-only > ISP for one moment, because that would disadvantage my IPv4 customers. >=20 > Note, this is not a comment on the technology, but on whether there's > a real operational use case today. The point is that all this 464XLAT discussion is in the context of = IPv6-only operator networks.=20 My understanding is that deployments of IPv6-only networks are seriously = envisaged in the context of LTE. RD =20 >=20 > Brian >=20 From brian.e.carpenter@gmail.com Tue Apr 17 08:39:03 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F090B21F8576 for ; Tue, 17 Apr 2012 08:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.434 X-Spam-Level: X-Spam-Status: No, score=-101.434 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-GE1fsWbP38 for ; Tue, 17 Apr 2012 08:39:03 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 49F6F21F8565 for ; Tue, 17 Apr 2012 08:39:03 -0700 (PDT) Received: by werb10 with SMTP id b10so5017574wer.31 for ; Tue, 17 Apr 2012 08:39:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=W4e8nlVp+AdjbLBbsEC9wGjBB8UHFpcPO6J+0bc1HRw=; b=rodXU81OxmL5Xh3ScISKpeHAC7QlPiACEsOFh1517lPJFvavj1lgjdSkP/Bmhgsjdd qmduBRI0SrnfpEGCJWLdqcH0YEUbyUFJNiUnClFqFZpWEisgjIyygRQ2c6gsyO8xLgMk 1iJLKhShQyBdN8XSPATrnVe2wJna5bevSA++LSK8R45Zf2uEsmb/Z9LPr+udDWjJ+pUL piUzq9l1y99EfNm1Rp2EF8myUyC6Fa0VFkr0WOVUwPHtBOHcICjHfdl8dyJQQsl5W3W7 gkbqBuHA5kGm/Qxqledq1vYoNECkxdbA/9huqOl+0Dad3/X7Guhhrjw2HKGe26cxW6hm ygmQ== Received: by 10.180.98.8 with SMTP id ee8mr13545217wib.14.1334677142366; Tue, 17 Apr 2012 08:39:02 -0700 (PDT) Received: from [192.168.1.69] (host-2-102-216-233.as13285.net. [2.102.216.233]) by mx.google.com with ESMTPS id b3sm27642734wib.4.2012.04.17.08.39.00 (version=SSLv3 cipher=OTHER); Tue, 17 Apr 2012 08:39:01 -0700 (PDT) Message-ID: <4F8D8E92.7090507@gmail.com> Date: Tue, 17 Apr 2012 16:38:58 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= References: <7E1BD96D-E7EC-4C78-B382-66F0F694DAA4@laposte.net> <1825062D-D4EB-4310-A2BA-8B8F3870B9B4@laposte.net> <22BD6607-5DEC-48F3-B2E5-DCEECC9EF643@laposte.net> <986EAD24-4612-4AD0-B366-012BA0B3751C@laposte.net> <5258F2DA-D61A-4327-B7FC-2BD67743C994@laposte.net> <4F8D17AD.7080907@gmail.com> <20966399-05D0-4294-B9EC-9AA55DEB390D@laposte.net> <4F8D83F4.80908@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: v6ops WG , Cameron Byrne Subject: Re: [v6ops] A way forward for 464XLAT - using BIH X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 15:39:04 -0000 On 2012-04-17 16:02, R=C3=A9mi Despr=C3=A9s wrote: > Le 2012-04-17 =C3=A0 16:53, Brian E Carpenter a =C3=A9crit : >=20 >> Bonjour R=C3=A9mi, >> >> On 2012-04-17 09:51, R=C3=A9mi Despr=C3=A9s wrote: >> ... >>> Thus, although Network 2 is IPv6 only, its servers remain reachable b= y some IPv4-only clients. >>> This contributes to facilitate commercial deployments of IPv6-only ne= tworks, an objective of IETF AFAIK. >> Really? As far as I know we have always suggested that dual stack was >> the preferred deployment model. Certainly if I was a commercial >> application layer provider, I would not consider using an IPv6-only >> ISP for one moment, because that would disadvantage my IPv4 customers.= >> >> Note, this is not a comment on the technology, but on whether there's >> a real operational use case today. >=20 > The point is that all this 464XLAT discussion is in the context of IPv6= -only operator networks.=20 > My understanding is that deployments of IPv6-only networks are seriousl= y envisaged in the context of LTE. Exactly, but that does not put content providers on an IPv6-only network.= I fully agree with Gert Doering's message. Brian From despres.remi@laposte.net Tue Apr 17 09:07:26 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9545D11E8088 for ; Tue, 17 Apr 2012 09:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.168 X-Spam-Level: X-Spam-Status: No, score=-2.168 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XRKL4eJiuf79 for ; Tue, 17 Apr 2012 09:07:26 -0700 (PDT) Received: from smtpout.laposte.net (smtpout3.laposte.net [193.253.67.228]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA5B11E80A3 for ; Tue, 17 Apr 2012 09:07:25 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8506-out with ME id z47N1i00137Y3f40347NJB; Tue, 17 Apr 2012 18:07:23 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4F8D8E92.7090507@gmail.com> Date: Tue, 17 Apr 2012 18:07:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7E1BD96D-E7EC-4C78-B382-66F0F694DAA4@laposte.net> <1825062D-D4EB-4310-A2BA-8B8F3870B9B4@laposte.net> <22BD6607-5DEC-48F3-B2E5-DCEECC9EF643@laposte.net> <986EAD24-4612-4AD0-B366-012BA0B3751C@laposte.net> <5258F2DA-D61A-4327-B7FC-2BD67743C994@laposte.net> <4F8D17AD.7080907@gmail.com> <20966399-05D0-4294-B9EC-9AA55DEB390D@laposte.net> <4F8D83F4.80908@gmail.com> <4F8D8E92.7090507@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1084) Cc: v6ops WG , Cameron Byrne Subject: Re: [v6ops] A way forward for 464XLAT - using BIH X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 16:07:26 -0000 Le 2012-04-17 =E0 17:38, Brian E Carpenter a =E9crit : > On 2012-04-17 16:02, R=E9mi Despr=E9s wrote: >> Le 2012-04-17 =E0 16:53, Brian E Carpenter a =E9crit : >>=20 >>> Bonjour R=E9mi, >>>=20 >>> On 2012-04-17 09:51, R=E9mi Despr=E9s wrote: >>> ... >>>> Thus, although Network 2 is IPv6 only, its servers remain reachable = by some IPv4-only clients. >>>> This contributes to facilitate commercial deployments of IPv6-only = networks, an objective of IETF AFAIK. >>> Really? As far as I know we have always suggested that dual stack = was >>> the preferred deployment model. Certainly if I was a commercial >>> application layer provider, I would not consider using an IPv6-only >>> ISP for one moment, because that would disadvantage my IPv4 = customers. >>>=20 >>> Note, this is not a comment on the technology, but on whether = there's >>> a real operational use case today. >>=20 >> The point is that all this 464XLAT discussion is in the context of = IPv6-only operator networks.=20 >> My understanding is that deployments of IPv6-only networks are = seriously envisaged in the context of LTE. >=20 > Exactly, but that does not put content providers on an IPv6-only = network. I agree that any server, even the smallest one, if intended to be = reached by IPv4-only clients should better be dual-stack capable. This has always been my stand. But now that some IPv6-only networks are seriously envisaged, and = without IPv4 incoming connectivity offered to customer sites, such a = dual-stack-capable server can be unable to use its IPv4 stack.=20 It can however remain reachable by IPv4-only clients whose CPEs are BIH = capable.=20 Importance of this plus can be discussed, sure, but its being a plus can = AFAIK hardly be denied.=20 Since, as we just learned, there is already BIH open-source running = code, why would one refuse to even consider it? In addition, and as I will explain in a response to Masanobu Kawashima, = 4X4XLAT has the problem of using multiple IPv6 prefixes in customer = sites, a problem that doesn't exist with BIH. Kind regards, RD =20 > I fully agree with Gert Doering's message. >=20 > Brian >=20 From despres.remi@laposte.net Tue Apr 17 09:25:19 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8409F11E80BB for ; Tue, 17 Apr 2012 09:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.871 X-Spam-Level: X-Spam-Status: No, score=-1.871 tagged_above=-999 required=5 tests=[AWL=-0.172, 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 NlmnKYYEvOF0 for ; Tue, 17 Apr 2012 09:25:15 -0700 (PDT) Received: from smtpout.laposte.net (smtpout1.laposte.net [193.253.67.226]) by ietfa.amsl.com (Postfix) with ESMTP id C836A11E80B4 for ; Tue, 17 Apr 2012 09:25:14 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8501-out with ME id z4RC1i00137Y3f4034RCgD; Tue, 17 Apr 2012 18:25:13 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <20120417160010kawashimam@mail.jp.nec.com> Date: Tue, 17 Apr 2012 18:25:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <52219CA6-6C5C-408D-A314-6A04F9E173A9@laposte.net> References: <20120417065542.31115.95082.idtracker@ietfa.amsl.com> <20120417160010kawashimam@mail.jp.nec.com> To: Masanobu Kawashima X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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, 17 Apr 2012 16:25:19 -0000 Hi, Masanobu, Thanks for this new version. More comments in line. Le 2012-04-17 =E0 09:00, Masanobu Kawashima a =E9crit : >=20 > Folks, >=20 > We have published draft-ietf-v6ops-464xlat-02. >=20 > Changes are: >=20 > - Changed document category from Informational to BCP > - A normative language(RFC2119) has reinserted. > - We did not see any strong opposition on this list except Remi. Let it be clear that I continuously supported quick publication of an = informational RFC describing what has been tested. OTOH, I objected to any hasty publication a normative BCP, and continue = to do so because: - there are unclear points and significant drawbacks in the = specification (see (1) below) - relationship with BIH (standard-track RFC6535) hasn't been even looked = at (although BIH already supports AFAIK the 4645XLAT scenario plus some = others). > As Cameron and Lorenzo said, we should not treat as a use case > for BIH. Remi's some concerns were fixed by this version as below. > If you have any strong opposition, please indicate it. >=20 > - Section 7.1. IPv6 Address Format > - Replaced all text with this one sentence "IPv6 address format > in 464XLAT is defined in Section 2.2 of [RFC6052]" >=20 > - Section 7.2. IPv4/IPv6 address translation chart > - Removed all references to /96 > - Added case of "CLAT with NAT44" >=20 > - Section 7.4. DNS Proxy Implementation > - Added a reference to RFC5625 >=20 > - Section 7.5. IPv6 Prefix Handling > - Removed all references to /96 > - Added a reference to RFC3633 >=20 > All comments are welcome. (1) Section 7.5 cites two IPv6 prefix-handling variants - The first one explicitly requires two IPv6 prefixes per CLAT node, a = quite expensive constraint.=20 - The second one is supposed to use only one prefix, but: . Section 7.2 says that the CLAT IPv6 address, which is based on a = single IPv4 address due to an NAT44 in the CLAT node, is defined in = Section 2.2 of RFC6052. . Section 2.2 of RFC 6052 says "In these addresses, the prefix shall be = either the "Well-Known Prefix" or a "Network-Specific Prefix" unique to = the organization deploying the address translators." This cannot be the = CLAT-node delegated prefix. In my understanding, this second option cannot work. If I missed something, thank you for explaining. (2) Coming back to the relationship with BIH: - We now know there is open-source running code for BIH. - With BIH, a single IPv6 prefix per customer node is sufficient in = customer nodes. - IPv4-only hosts, if behind BIH-capable CPEs, have connectivity with = servers that, because they are also in customer sites of IPv6-only = networks, can have AAAA records but no A records in the DNS. Regards, RD >=20 > Regards, > Masanobu >=20 >=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the IPv6 Operations Working = Group of the IETF. >>=20 >> Title : 464XLAT: Combination of Stateful and Stateless = Translation >> Author(s) : Masataka Mawatari >> Masanobu Kawashima >> Cameron Byrne >> Filename : draft-ietf-v6ops-464xlat-02.txt >> Pages : 15 >> Date : 2012-04-16 >>=20 >> This document describes an architecture (464XLAT) for providing >> limited IPv4 connectivity across an IPv6-only network by combining >> existing and well-known stateful protocol translation RFC 6146 in = the >> core and stateless protocol translation RFC 6145 at the edge. = 464XLAT >> is a simple and scalable technique to quickly deploy limited IPv4 >> access service to mobile and wireline IPv6-only edge networks = without >> encapsulation. >>=20 >>=20 >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-464xlat-02.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-464xlat-02.txt >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > NEC AccessTechnica, Ltd. =20 > Product Development Department =20 > Masanobu Kawashima =20 > kawashimam@vx.jp.nec.com =20 > http://www.necat.co.jp/ =20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From cb.list6@gmail.com Tue Apr 17 10:30:55 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74D8C21F8546 for ; Tue, 17 Apr 2012 10:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.993 X-Spam-Level: X-Spam-Status: No, score=-2.993 tagged_above=-999 required=5 tests=[AWL=-0.294, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OIFaxuCDT6R7 for ; Tue, 17 Apr 2012 10:30:50 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id CF7D221F8547 for ; Tue, 17 Apr 2012 10:30:50 -0700 (PDT) Received: by dady13 with SMTP id y13so11981861dad.27 for ; Tue, 17 Apr 2012 10:30:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=TJTn/3aDVKhruNvvqv/kx3MrqxdT14L8l5yVrtxk++Y=; b=PwEIfnyqdbZeM5QNzzOaF/lo4lf5MpHzz1mQ8d7wyDjmeNNTvJO91YTWYCtZXA4TWJ gTmxjLH1+2HsFFomEOtGpezFtVNBVMQ5r1pqKJT4ZheUeMgKCQ+J7QJ1AD1QLZiTbx0w zov2/4Wc1fAsJPMZiJpgK0yRXhZSfCZWFCcE4iJvrwVsx3aVDaDQ1yg23Rl/rL6hVYAu yJwTeuJigZVdNzdHeuG0/72CL4NRCNRz/O+UUiOgdqZWriQMDLL7/W3gjawzvHWEHjUG mD2jRa/S8eoXGpvOPlCvPcealuwHHjyJBV5pzPAB5gw6FPoF++9d6b9stSH19WgaBu7x HnBg== MIME-Version: 1.0 Received: by 10.68.216.234 with SMTP id ot10mr37920174pbc.107.1334683850618; Tue, 17 Apr 2012 10:30:50 -0700 (PDT) Received: by 10.142.102.1 with HTTP; Tue, 17 Apr 2012 10:30:50 -0700 (PDT) In-Reply-To: <52219CA6-6C5C-408D-A314-6A04F9E173A9@laposte.net> References: <20120417065542.31115.95082.idtracker@ietfa.amsl.com> <20120417160010kawashimam@mail.jp.nec.com> <52219CA6-6C5C-408D-A314-6A04F9E173A9@laposte.net> Date: Tue, 17 Apr 2012 10:30:50 -0700 Message-ID: From: Cameron Byrne To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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, 17 Apr 2012 17:30:55 -0000 Remi, On Tue, Apr 17, 2012 at 9:25 AM, R=E9mi Despr=E9s wrote: > Hi, Masanobu, > > Thanks for this new version. > More comments in line. > > > Le 2012-04-17 =E0 09:00, Masanobu Kawashima a =E9crit : > >> >> Folks, >> >> We have published draft-ietf-v6ops-464xlat-02. >> >> Changes are: >> >> - Changed document category from Informational to BCP >> =A0- A normative language(RFC2119) has reinserted. >> =A0- We did not see any strong opposition on this list except Remi. > > Let it be clear that I continuously supported quick publication of an inf= ormational RFC describing what has been tested. > > OTOH, I objected to any hasty publication a normative BCP, and continue t= o do so because: > - there are unclear points and significant drawbacks in the specification= (see (1) below) > - relationship with BIH (standard-track RFC6535) hasn't been even looked = at (although BIH already supports AFAIK the 4645XLAT scenario plus some oth= ers). > > >> =A0 =A0As Cameron and Lorenzo said, we should not treat as a use case >> =A0 =A0for BIH. Remi's some concerns were fixed by this version as below= . >> =A0 =A0If you have any strong opposition, please indicate it. >> >> - Section 7.1. IPv6 Address Format >> =A0- Replaced all text with this one sentence "IPv6 address format >> =A0 =A0in 464XLAT is defined in Section 2.2 of [RFC6052]" >> >> - Section 7.2. IPv4/IPv6 address translation chart >> =A0- Removed all references to /96 >> =A0- Added case of "CLAT with NAT44" >> >> - Section 7.4. DNS Proxy Implementation >> =A0- Added a reference to RFC5625 >> >> - Section 7.5. IPv6 Prefix Handling >> =A0- Removed all references to /96 >> =A0- Added a reference to RFC3633 >> >> All comments are welcome. > > > (1) > Section 7.5 cites two IPv6 prefix-handling variants > > - The first one explicitly requires two IPv6 prefixes per CLAT node, a qu= ite expensive constraint. > What is expensive? I think most network operators will say IPv6 /64 subnets have no money value, and /64 subnets should be used where ever it makes operational sense without constraint. > - The second one is supposed to use only one prefix, but: > =A0. Section 7.2 says that the CLAT IPv6 address, which is based on a sin= gle IPv4 address due to an NAT44 in the CLAT node, is defined in Section 2.= 2 of RFC6052. > =A0. Section 2.2 of RFC 6052 says "In these addresses, the prefix shall b= e either the "Well-Known Prefix" or a "Network-Specific Prefix" unique to t= he organization deploying the address translators." This cannot be the CLAT= -node delegated prefix. > Why can this not be the CLAT node prefix? NSP of the home network. > In my understanding, this second option cannot =A0work. > If I missed something, thank you for explaining. > > (2) > Coming back to the relationship with BIH: > - We now know there is open-source running code for BIH. Same as 464XLAT draft > - With BIH, a single IPv6 prefix per customer node is sufficient in custo= mer nodes. Same as defined is this 464XLAT draft > - IPv4-only hosts, if behind BIH-capable CPEs, have connectivity with ser= vers that, because they are also in customer sites of IPv6-only networks, c= an have AAAA records but no A records in the DNS. > Brian, Lorenzo, Gert, and myself, and the market (there is no meaningful market for IPv6-only services on the internet) say this is not a value add. CB > > Regards, > RD > > > > >> >> Regards, >> Masanobu >> >> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. This draft is a work item of the IPv6 Operations Working Group of = the IETF. >>> >>> =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : 464XLAT: Combination of Stateful= and Stateless Translation >>> =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Masataka Mawatari >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Masanobu Kawashima >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Cameron Byrne >>> =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-v6ops-464xlat-02.txt >>> =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 15 >>> =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-04-16 >>> >>> =A0This document describes an architecture (464XLAT) for providing >>> =A0limited IPv4 connectivity across an IPv6-only network by combining >>> =A0existing and well-known stateful protocol translation RFC 6146 in th= e >>> =A0core and stateless protocol translation RFC 6145 at the edge. 464XLA= T >>> =A0is a simple and scalable technique to quickly deploy limited IPv4 >>> =A0access service to mobile and wireline IPv6-only edge networks withou= t >>> =A0encapsulation. >>> >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-464xlat-02.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-464xlat-02.txt >>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> NEC AccessTechnica, Ltd. >> Product Development Department >> Masanobu Kawashima >> kawashimam@vx.jp.nec.com >> http://www.necat.co.jp/ >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From joelja@bogus.com Tue Apr 17 11:05:56 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 226C621F8471 for ; Tue, 17 Apr 2012 11:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bi9jR42IgjEV for ; Tue, 17 Apr 2012 11:05:51 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 9C8A521F8469 for ; Tue, 17 Apr 2012 11:05:51 -0700 (PDT) Received: from Joels-MacBook-Pro.local (host-64-47-153-50.masergy.com [64.47.153.50]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q3HHbdbp002609 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Tue, 17 Apr 2012 17:37:39 GMT (envelope-from joelja@bogus.com) Message-ID: <4F8DAA5E.3070007@bogus.com> Date: Tue, 17 Apr 2012 10:37:34 -0700 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.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]); Tue, 17 Apr 2012 17:37:39 +0000 (UTC) Subject: [v6ops] In the vein of of the icp/dc 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, 17 Apr 2012 18:05:56 -0000 This was presented at ripe64. https://ripe64.ripe.net/presentations/67-20120417-RIPE64-The_Case_for_IPv6_Only_Data_Centres.pdf From phdgang@gmail.com Tue Apr 17 19:38:54 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B19421F8534 for ; Tue, 17 Apr 2012 19:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 DC4fZeaF50tw for ; Tue, 17 Apr 2012 19:38:50 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id AC4D321F84D8 for ; Tue, 17 Apr 2012 19:38:49 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so4750029wgb.13 for ; Tue, 17 Apr 2012 19:38:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=XNUTJPFsDhMFZeuWu0RVXN1iLX28zSYI1l4AgvT7eMo=; b=jUhucwfwNQ7oKqJbkuwn4rxOdmQ702jqPGw9KUN8HEXN3WqkcNygz9prG767w0oD0f 6SMyBsDS/Glwm4H5XsDTH50xOiLH30qTikW+8+t9kmhmU6axG7CDxrvTugpuNbv2f2Ec i5zh7lwLO5lkI/j7ac4soVTYYDMNSCKLwsP+zsYZEJlroYx0R7vy7S5p52Eph6Jy0oVf 6Yuaqst5Tsfqm0IUme/hHC6sVapPJHGVBGwu7JtcZ5PEV1BqpHydveGhrzNl4S+bvuI2 VLwD8fuoPBESbNDVZigYSNVnDhnaNKCtFthvrc1/Hyc7gGcFIahLN7WKOywCxMar6OcR dVLA== MIME-Version: 1.0 Received: by 10.180.83.72 with SMTP id o8mr1863614wiy.5.1334716728777; Tue, 17 Apr 2012 19:38:48 -0700 (PDT) Received: by 10.180.100.97 with HTTP; Tue, 17 Apr 2012 19:38:48 -0700 (PDT) In-Reply-To: References: <20120417065542.31115.95082.idtracker@ietfa.amsl.com> <20120417160010kawashimam@mail.jp.nec.com> <52219CA6-6C5C-408D-A314-6A04F9E173A9@laposte.net> Date: Wed, 18 Apr 2012 10:38:48 +0800 Message-ID: From: GangChen To: Cameron Byrne Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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, 18 Apr 2012 02:38:54 -0000 Hello Cameron, > Brian, Lorenzo, Gert, and myself, and the market (there is no > meaningful market for IPv6-only services on the internet) say this is > not a value add. IMHO, the added value is similar with the benefits of DNS Proxy, i.e. "to make the transaction native IPv6 from the CLAT and avoid stateful translation on the PLAT." For sure, double translation to a dual-stack server should be supported, if severs comply with market/operational demands. BRs Gang 2012/4/18, Cameron Byrne : > Remi, > > On Tue, Apr 17, 2012 at 9:25 AM, R=E9mi Despr=E9s > wrote: >> Hi, Masanobu, >> >> Thanks for this new version. >> More comments in line. >> >> >> Le 2012-04-17 =E0 09:00, Masanobu Kawashima a =E9crit : >> >>> >>> Folks, >>> >>> We have published draft-ietf-v6ops-464xlat-02. >>> >>> Changes are: >>> >>> - Changed document category from Informational to BCP >>> - A normative language(RFC2119) has reinserted. >>> - We did not see any strong opposition on this list except Remi. >> >> Let it be clear that I continuously supported quick publication of an >> informational RFC describing what has been tested. >> >> OTOH, I objected to any hasty publication a normative BCP, and continue = to >> do so because: >> - there are unclear points and significant drawbacks in the specificatio= n >> (see (1) below) >> - relationship with BIH (standard-track RFC6535) hasn't been even looked >> at (although BIH already supports AFAIK the 4645XLAT scenario plus some >> others). >> >> >>> As Cameron and Lorenzo said, we should not treat as a use case >>> for BIH. Remi's some concerns were fixed by this version as below. >>> If you have any strong opposition, please indicate it. >>> >>> - Section 7.1. IPv6 Address Format >>> - Replaced all text with this one sentence "IPv6 address format >>> in 464XLAT is defined in Section 2.2 of [RFC6052]" >>> >>> - Section 7.2. IPv4/IPv6 address translation chart >>> - Removed all references to /96 >>> - Added case of "CLAT with NAT44" >>> >>> - Section 7.4. DNS Proxy Implementation >>> - Added a reference to RFC5625 >>> >>> - Section 7.5. IPv6 Prefix Handling >>> - Removed all references to /96 >>> - Added a reference to RFC3633 >>> >>> All comments are welcome. >> >> >> (1) >> Section 7.5 cites two IPv6 prefix-handling variants >> >> - The first one explicitly requires two IPv6 prefixes per CLAT node, a >> quite expensive constraint. >> > > What is expensive? I think most network operators will say IPv6 /64 > subnets have no money value, and /64 subnets should be used where ever > it makes operational sense without constraint. > >> - The second one is supposed to use only one prefix, but: >> . Section 7.2 says that the CLAT IPv6 address, which is based on a sing= le >> IPv4 address due to an NAT44 in the CLAT node, is defined in Section 2.2 >> of RFC6052. >> . Section 2.2 of RFC 6052 says "In these addresses, the prefix shall be >> either the "Well-Known Prefix" or a "Network-Specific Prefix" unique to >> the organization deploying the address translators." This cannot be the >> CLAT-node delegated prefix. >> > > Why can this not be the CLAT node prefix? NSP of the home network. > >> In my understanding, this second option cannot work. >> If I missed something, thank you for explaining. >> >> (2) >> Coming back to the relationship with BIH: >> - We now know there is open-source running code for BIH. > > Same as 464XLAT draft > >> - With BIH, a single IPv6 prefix per customer node is sufficient in >> customer nodes. > > Same as defined is this 464XLAT draft > >> - IPv4-only hosts, if behind BIH-capable CPEs, have connectivity with >> servers that, because they are also in customer sites of IPv6-only >> networks, can have AAAA records but no A records in the DNS. >> > > Brian, Lorenzo, Gert, and myself, and the market (there is no > meaningful market for IPv6-only services on the internet) say this is > not a value add. > > CB >> >> Regards, >> RD >> >> >> >> >>> >>> Regards, >>> Masanobu >>> >>> >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. This draft is a work item of the IPv6 Operations Working >>>> Group of the IETF. >>>> >>>> Title : 464XLAT: Combination of Stateful and Stateless >>>> Translation >>>> Author(s) : Masataka Mawatari >>>> Masanobu Kawashima >>>> Cameron Byrne >>>> Filename : draft-ietf-v6ops-464xlat-02.txt >>>> Pages : 15 >>>> Date : 2012-04-16 >>>> >>>> This document describes an architecture (464XLAT) for providing >>>> limited IPv4 connectivity across an IPv6-only network by combining >>>> existing and well-known stateful protocol translation RFC 6146 in the >>>> core and stateless protocol translation RFC 6145 at the edge. 464XLAT >>>> is a simple and scalable technique to quickly deploy limited IPv4 >>>> access service to mobile and wireline IPv6-only edge networks without >>>> encapsulation. >>>> >>>> >>>> A URL for this Internet-Draft is: >>>> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-464xlat-02.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-464xlat-02.txt >>>> >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>> >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> NEC AccessTechnica, Ltd. >>> Product Development Department >>> Masanobu Kawashima >>> kawashimam@vx.jp.nec.com >>> http://www.necat.co.jp/ >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >> >> _______________________________________________ >> 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 denghui02@gmail.com Tue Apr 17 21:37:59 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D540411E8095 for ; Tue, 17 Apr 2012 21:37:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.487 X-Spam-Level: X-Spam-Status: No, score=-103.487 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-s2q2h-1ISi for ; Tue, 17 Apr 2012 21:37:55 -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 77D0811E8072 for ; Tue, 17 Apr 2012 21:37:55 -0700 (PDT) Received: by yhkk25 with SMTP id k25so3949782yhk.31 for ; Tue, 17 Apr 2012 21:37:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rDyS4fgoZiV/Ai8GbevBSS4y0YtJF0fWE/DGt7L6xjI=; b=JYpz6i5Ky9KGuSmuttnYrsULTnM3QMuzPzZEEYOsU9op0IO7AxVYtvzXOYhEMQVy8u Z6UP71IIOEqiJE5QZLWZudeZbLWOvO0XciNZQjUOMz+FrKaSU4OMZLhaRWTF2UbCG8S/ ljY1jlyo561AAcUEjFntYOmFnuzjflgQGR+m8W3FMoKFga6ns2UQYSm5HUb41asnJCtb vIIPcPHBlo6UkS2zPbaKJ13DxgRwJQI/T249jJT5uYmiUQbHpGs/DONpi16XIcAXGPq6 XbG5WoHPNpxrccydgpR4ZvnZClql4KRfawAxNzpgpb7Rs/8nlh/wGXF/ysMcu1ulrNCX oi1Q== MIME-Version: 1.0 Received: by 10.236.75.195 with SMTP id z43mr769453yhd.4.1334723871467; Tue, 17 Apr 2012 21:37:51 -0700 (PDT) Received: by 10.146.20.14 with HTTP; Tue, 17 Apr 2012 21:37:51 -0700 (PDT) In-Reply-To: References: <7E1BD96D-E7EC-4C78-B382-66F0F694DAA4@laposte.net> <1825062D-D4EB-4310-A2BA-8B8F3870B9B4@laposte.net> <22BD6607-5DEC-48F3-B2E5-DCEECC9EF643@laposte.net> <986EAD24-4612-4AD0-B366-012BA0B3751C@laposte.net> <5258F2DA-D61A-4327-B7FC-2BD67743C994@laposte.net> Date: Wed, 18 Apr 2012 12:37:51 +0800 Message-ID: From: Hui Deng To: Cameron Byrne Content-Type: multipart/alternative; boundary=bcaec52996633b687d04bdec9eba Cc: Teemu Savolainen , v6ops WG , Bill Huang Subject: Re: [v6ops] A way forward for 464XLAT - using BIH X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 04:38:00 -0000 --bcaec52996633b687d04bdec9eba Content-Type: text/plain; charset=ISO-8859-1 Hello all As I spoke during the last IETF meeting, this scenario is an valid and deserved to solve it. I guess people here who are discussing in order to make it a better IETF document. http://tools.ietf.org/html/rfc6535#section-2.3 "The network-layer implementation alternative will only be able to catch applications' name resolution requests that result in actual DNS queries; hence, it is more limited when compared to the socket API-layer implementation alternative. Hence, the socket API-layer alternative is RECOMMENDED." I would like to comment below wording based on Dave's writeup during shepherd. you can look at the link below: http://datatracker.ietf.org/doc/draft-ietf-behave-v4v6-bih/history/ copy and paste: The present document does not, however, mandate (or even recommend) the RFC 2767-like implementation option. In fact, for the name synthesis part, it recommends the other option, and for the data translation portion, no recommendation is made either way. You could understand only name synthesis is not commended, for literal, I don't see that statement valid. Best -Hui --bcaec52996633b687d04bdec9eba Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello all
=A0
As I spoke during the last IETF meeting, this scenario is an valid and= deserved to solve it.
I guess people here who are discussing in order to=A0make it a better = IETF document.
=A0
http://tools.ietf.org/html/rfc6535#section-2.3

"The = network-layer implementation alternative will only be able to
=A0 catch = applications' name resolution requests that result in actual
=A0 DNS queries; hence, it is more limited when compared to the socket
= =A0 API-layer implementation alternative. =A0Hence, the socket API-layer=A0 alternative is RECOMMENDED."

I would like to comment below wording based on Dave's writeup duri= ng shepherd.
you can look at the link below:
=A0
copy and paste:
The present document does not, however, mandate (or even recommend)the RFC 2767-like implementation option.=A0 In fact, for the name
synth= esis part, it recommends the other option, and for the data
translation = portion, no recommendation is made either way.
You could understand only name synthesis is not commended,=A0
for literal, I don't see that statement valid.
=A0
Best
=A0
-Hui=A0
--bcaec52996633b687d04bdec9eba-- From brian.e.carpenter@gmail.com Wed Apr 18 00:12:38 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDF1F21F860E for ; Wed, 18 Apr 2012 00:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.282 X-Spam-Level: X-Spam-Status: No, score=-101.282 tagged_above=-999 required=5 tests=[AWL=-0.191, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9U-IxfW2BPVT for ; Wed, 18 Apr 2012 00:12:34 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5D43421F84EC for ; Wed, 18 Apr 2012 00:12:34 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so4855491wgb.13 for ; Wed, 18 Apr 2012 00:12:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=cqwmWZj5Xoy1paHAysPYQjCmd+AnWKr3q1pDx113XLs=; b=PUoi6gKQPGu2IDnwt/4yYgh9tZ4HfTKhgyaoD0MvjNT8JPEoaZC+0R9SW8nYYXGzvE WQ3iSCnhlrVj9+J6cEUUCfK6zQgSHh7wqZ4d+krAtnncXKrfHkj1Xkn7siZdXQplgjzt 4nm3vkkfX8XDbqM2KIUARBo0egAEGfr2CY9U3Ih4WA1bkOleI156vhy9XnsrYgr3ZfaF tqP35nRCqhlYXJf+TGJnMRJQ+ZsKIjpO5CRi9Ep4ucjJEYOagrijD0GF5qjEIdV4boIP Gf14gP4VzvHDRPzdLyW6+72l3V9VmvlW0KBMhmwid8MvJQ0c/tuohEEGETYWXlxpNvsz ak7g== Received: by 10.180.81.166 with SMTP id b6mr14141265wiy.0.1334733153524; Wed, 18 Apr 2012 00:12:33 -0700 (PDT) Received: from [192.168.1.69] (host-2-102-216-233.as13285.net. [2.102.216.233]) by mx.google.com with ESMTPS id k6sm32581808wie.9.2012.04.18.00.12.31 (version=SSLv3 cipher=OTHER); Wed, 18 Apr 2012 00:12:32 -0700 (PDT) Message-ID: <4F8E695C.3050705@gmail.com> Date: Wed, 18 Apr 2012 08:12:28 +0100 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: <4F8DAA5E.3070007@bogus.com> In-Reply-To: <4F8DAA5E.3070007@bogus.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] In the vein of of the icp/dc 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, 18 Apr 2012 07:12:38 -0000 It's fine work IMHO, but I expect that most DC operators will not want to jump in at the deep end in this way. Regards Brian On 2012-04-17 18:37, Joel jaeggli wrote: > This was presented at ripe64. > > https://ripe64.ripe.net/presentations/67-20120417-RIPE64-The_Case_for_IPv6_Only_Data_Centres.pdf > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From mohacsi@niif.hu Wed Apr 18 00:32:15 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61F2A21F8547 for ; Wed, 18 Apr 2012 00:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.446 X-Spam-Level: X-Spam-Status: No, score=0.446 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_HU=1.35, HOST_EQ_HU=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 tRc8DBojbFeg for ; Wed, 18 Apr 2012 00:32:11 -0700 (PDT) Received: from mail.ki.iif.hu (mail.ki.iif.hu [IPv6:2001:738:0:411::241]) by ietfa.amsl.com (Postfix) with ESMTP id DD70821F84AE for ; Wed, 18 Apr 2012 00:32:10 -0700 (PDT) Received: from cirkusz.lvs.iif.hu (cirkusz.lvs.iif.hu [193.225.14.182]) by mail.ki.iif.hu (Postfix) with ESMTP id 5F72987B34; Wed, 18 Apr 2012 09:32:09 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at cirkusz.lvs.iif.hu Received: from mail.ki.iif.hu ([IPv6:::ffff:193.6.222.241]) by cirkusz.lvs.iif.hu (cirkusz.lvs.iif.hu [::ffff:193.225.14.72]) (amavisd-new, port 10024) with ESMTP id KrLuAFPLzd02; Wed, 18 Apr 2012 09:32:03 +0200 (CEST) Received: by mail.ki.iif.hu (Postfix, from userid 9002) id 93BE387B09; Wed, 18 Apr 2012 09:32:03 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id 8F833879E1; Wed, 18 Apr 2012 09:32:03 +0200 (CEST) Date: Wed, 18 Apr 2012 09:32:03 +0200 (CEST) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Brian E Carpenter In-Reply-To: <4F8E695C.3050705@gmail.com> Message-ID: References: <4F8DAA5E.3070007@bogus.com> <4F8E695C.3050705@gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IPv6 Ops WG Subject: Re: [v6ops] In the vein of of the icp/dc 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, 18 Apr 2012 07:32:15 -0000 On Wed, 18 Apr 2012, Brian E Carpenter wrote: > It's fine work IMHO, but I expect that most DC operators will > not want to jump in at the deep end in this way. Agreed. DC operators are very conscious of deploying new technologies: - Capable IPv6 load balancers - Stateless IPv4/IPv6 translators - stastics gathering - update for translated IPv6/IPv4 addressess - Hosted Application with full IPv6 capability The biggest challenge will be the users who use DC for hosting... Best Regards, Janos Mohacsi > > Regards > Brian > > On 2012-04-17 18:37, Joel jaeggli wrote: >> This was presented at ripe64. >> >> https://ripe64.ripe.net/presentations/67-20120417-RIPE64-The_Case_for_IPv6_Only_Data_Centres.pdf >> _______________________________________________ >> 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 nick@inex.ie Wed Apr 18 01:17:15 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6707321F85D5 for ; Wed, 18 Apr 2012 01:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.385 X-Spam-Level: X-Spam-Status: No, score=-2.385 tagged_above=-999 required=5 tests=[AWL=0.214, 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 Fc8-vRbHiH9b for ; Wed, 18 Apr 2012 01:17:14 -0700 (PDT) Received: from mail.acquirer.com (mail.acquirer.com [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 3160321F852E for ; Wed, 18 Apr 2012 01:17:13 -0700 (PDT) X-Envelope-To: Received: from vpn-251.int.inex.ie (vpn-251.int.inex.ie [193.242.111.251]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id q3I8H0Xh031029 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 18 Apr 2012 09:17:00 +0100 (IST) (envelope-from nick@inex.ie) Message-ID: <4F8E7888.8080102@inex.ie> Date: Wed, 18 Apr 2012 10:17:12 +0200 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: v6ops@ietf.org References: <4F8DAA5E.3070007@bogus.com> <4F8E695C.3050705@gmail.com> In-Reply-To: <4F8E695C.3050705@gmail.com> X-Enigmail-Version: 1.4 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] In the vein of of the icp/dc 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, 18 Apr 2012 08:17:16 -0000 On 18/04/2012 09:12, Brian E Carpenter wrote: > It's fine work IMHO, but I expect that most DC operators will > not want to jump in at the deep end in this way. I like the idea too. But hosting operators will be very cagey about deploying client-side ipv6 when there is no clear precedent for operating reliable ipv6-only services, where there is an absence of good quality ipv6-only monitoring tools, and where many of the software development companies are still saying "we'll make our products ipv6 aware when we get some customer demand". Nick From jiangsheng@huawei.com Wed Apr 18 01:22:59 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B0D321F85D2 for ; Wed, 18 Apr 2012 01:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WD4xY2SWhuyM for ; Wed, 18 Apr 2012 01:22:55 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0022421F84CD for ; Wed, 18 Apr 2012 01:22:54 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEZ91977; Wed, 18 Apr 2012 04:22:54 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 18 Apr 2012 01:20:06 -0700 Received: from SZXEML435-HUB.china.huawei.com (10.72.61.63) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 18 Apr 2012 01:20:05 -0700 Received: from SZXEML506-MBS.china.huawei.com ([169.254.3.67]) by szxeml435-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Wed, 18 Apr 2012 16:20:02 +0800 From: Sheng Jiang To: Brian E Carpenter , Joel jaeggli Thread-Topic: [v6ops] In the vein of of the icp/dc guidance Thread-Index: AQHNHMTi7rjWpTTrD0ivaUkc/KS9s5afpZMAgACYwVA= Date: Wed, 18 Apr 2012 08:20:01 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B921E48B7E0@SZXEML506-MBS.china.huawei.com> References: <4F8DAA5E.3070007@bogus.com> <4F8E695C.3050705@gmail.com> In-Reply-To: <4F8E695C.3050705@gmail.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.4.115] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: IPv6 Ops WG Subject: Re: [v6ops] In the vein of of the icp/dc 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, 18 Apr 2012 08:22:59 -0000 I think, IPv6-only data centre is a good approach. The most general case wo= uld be a DC operator build up a new IPv6-only DC parallel with the existing= IPv4 DC. Dual stack DC is too complicated for DC internal or transition pu= rpose. Sheng > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Brian E Carpenter > Sent: Wednesday, April 18, 2012 3:12 PM > To: Joel jaeggli > Cc: IPv6 Ops WG > Subject: Re: [v6ops] In the vein of of the icp/dc guidance >=20 > It's fine work IMHO, but I expect that most DC operators will > not want to jump in at the deep end in this way. >=20 > Regards > Brian >=20 > On 2012-04-17 18:37, Joel jaeggli wrote: > > This was presented at ripe64. > > > > https://ripe64.ripe.net/presentations/67-20120417-RIPE64- > The_Case_for_IPv6_Only_Data_Centres.pdf > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From despres.remi@laposte.net Wed Apr 18 05:26:48 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C95821F85B1 for ; Wed, 18 Apr 2012 05:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.168 X-Spam-Level: X-Spam-Status: No, score=-2.168 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TCXScTLIkaSb for ; Wed, 18 Apr 2012 05:26:48 -0700 (PDT) Received: from smtpout.laposte.net (smtpout1.laposte.net [193.253.67.226]) by ietfa.amsl.com (Postfix) with ESMTP id 944EE21F8531 for ; Wed, 18 Apr 2012 05:26:46 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8501-out with ME id zQSj1i00B37Y3f403QSjgu; Wed, 18 Apr 2012 14:26:45 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 18 Apr 2012 14:26:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <832D2D61-034D-46C8-896E-BD34FCDDC271@laposte.net> References: <20120417065542.31115.95082.idtracker@ietfa.amsl.com> <20120417160010kawashimam@mail.jp.nec.com> <52219CA6-6C5C-408D-A314-6A04F9E173A9@laposte.net> To: Cameron Byrne X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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, 18 Apr 2012 12:26:48 -0000 Cameron, 2012-04-17 19:30, Cameron Byrne: ... >> (1) >> Section 7.5 cites two IPv6 prefix-handling variants >>=20 >> - The first one explicitly requires two IPv6 prefixes per CLAT node, = a quite expensive constraint. >>=20 >=20 > What is expensive? I think most network operators will say IPv6 /64 > subnets have no money value, and /64 subnets should be used where ever > it makes operational sense without constraint. OK, expensive may not be the best qualifier. OTOH, the need to delegate TWO IPv6 prefixes per customer, while there = exist solutions that work with the ordinary one-prefix-per-customer = practice, should by no means be called "Best Common Practice". I remain firm on that. >> - The second one is supposed to use only one prefix, but: >> . Section 7.2 says that the CLAT IPv6 address, which is based on a = single IPv4 address due to an NAT44 in the CLAT node, is defined in = Section 2.2 of RFC6052. >> . Section 2.2 of RFC 6052 says "In these addresses, the prefix shall = be either the "Well-Known Prefix" or a "Network-Specific Prefix" unique = to the organization deploying the address translators." This cannot be = the CLAT-node delegated prefix. >>=20 >=20 > Why can this not be the CLAT node prefix? NSP of the home network. AFAIK, a single operator supports many CLATs =20 They cannot be reached at the NSP prefix which, by RFC6052, is "unique = to the organization deploying the address translators" (i.e the = operator). >> In my understanding, this second option cannot work. >> If I missed something, thank you for explaining. >>=20 >> (2) >> Coming back to the relationship with BIH: >> - We now know there is open-source running code for BIH. >=20 > Same as 464XLAT draft Right =3D> not a decision criterion. >> - With BIH, a single IPv6 prefix per customer node is sufficient in = customer nodes. >=20 > Same as defined is this 464XLAT draft BIH can readily be used on any ISPv6 network having a NAT64 accessible = at its well known prefix 64:ff9b::/96. This isn't the case with the proposed 464XLAT design (see above). >> - IPv4-only hosts, if behind BIH-capable CPEs, have connectivity with = servers that, because they are also in customer sites of IPv6-only = networks, can have AAAA records but no A records in the DNS. >>=20 >=20 > Brian, Lorenzo, Gert, and myself, and the market (there is no > meaningful market for IPv6-only services on the internet) say this is > not a value add. When discussing whether a new market exists, those who explain where = they see it are in general more relevant than those who, having not = seen it yet, negate that it can exist. In any case, advantages of BIH for the 464XLAT scenario go beyond BIH = applicability to IPv4-only hosts reaching servers attached to IPv6-only = networks. Regards, RD =20 From fibrib@gmail.com Wed Apr 18 06:14:44 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7286821F8568 for ; Wed, 18 Apr 2012 06:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.913 X-Spam-Level: X-Spam-Status: No, score=-2.913 tagged_above=-999 required=5 tests=[AWL=-0.215, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zANWDhiqnNf4 for ; Wed, 18 Apr 2012 06:14:38 -0700 (PDT) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) by ietfa.amsl.com (Postfix) with ESMTP id 92DAB21F8566 for ; Wed, 18 Apr 2012 06:14:38 -0700 (PDT) Received: by qafi31 with SMTP id i31so508298qaf.15 for ; Wed, 18 Apr 2012 06:14:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8AT7aLch6sO0DuXga40tQRN8ZOrk5c2IlkLxkCA55BE=; b=cjQ/W471u6VSWQAB1ZPg5p7fnuouKIVHNezWmx0/1rtWGT57Vj7vXtb7omgxvYS0TI UVRxGbLG8kVmWhEgaFTgTY3qg+nJe7Z1XnNX7Z20VlzkEWLzpeZKtntLTX05Lp+9Gsmd nKbOD+WZFjqX8XUpkC4koe5j+5hmp8OxXB7kwe0nxMB4ePMM212pRENhjwVtDLLR+CXR a3ogE/cbO5QBkdeMGsN0CrPu4bbl4iG2i46iVz/wYpsjGjiQTQxQz7GaDtHqDwnOFgUy RjE7HovdVzI1F5RauW0wFwwvE71xQ5jP8JIsqLqF2WhbdTFlfbRxeGKmXNqg1j8lMANf jnSA== MIME-Version: 1.0 Received: by 10.224.35.130 with SMTP id p2mr3469802qad.32.1334754878063; Wed, 18 Apr 2012 06:14:38 -0700 (PDT) Received: by 10.229.123.197 with HTTP; Wed, 18 Apr 2012 06:14:37 -0700 (PDT) In-Reply-To: <832D2D61-034D-46C8-896E-BD34FCDDC271@laposte.net> References: <20120417065542.31115.95082.idtracker@ietfa.amsl.com> <20120417160010kawashimam@mail.jp.nec.com> <52219CA6-6C5C-408D-A314-6A04F9E173A9@laposte.net> <832D2D61-034D-46C8-896E-BD34FCDDC271@laposte.net> Date: Wed, 18 Apr 2012 22:14:37 +0900 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=20cf306f744a5e828304bdf3d69d Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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, 18 Apr 2012 13:14:44 -0000 --20cf306f744a5e828304bdf3d69d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Remi, try to understand the question, as a learner. 2012/4/18 R=E9mi Despr=E9s > Cameron, > > 2012-04-17 19:30, Cameron Byrne: > ... > >> (1) > >> Section 7.5 cites two IPv6 prefix-handling variants > >> > >> - The first one explicitly requires two IPv6 prefixes per CLAT node, a > quite expensive constraint. > >> > > > > What is expensive? I think most network operators will say IPv6 /64 > > subnets have no money value, and /64 subnets should be used where ever > > it makes operational sense without constraint. > > OK, expensive may not be the best qualifier. > > OTOH, the need to delegate TWO IPv6 prefixes per customer, while there > exist solutions that work with the ordinary one-prefix-per-customer > practice, should by no means be called "Best Common Practice". > > I remain firm on that. > > >> - The second one is supposed to use only one prefix, but: > >> . Section 7.2 says that the CLAT IPv6 address, which is based on a > single IPv4 address due to an NAT44 in the CLAT node, is defined in Secti= on > 2.2 of RFC6052. > >> . Section 2.2 of RFC 6052 says "In these addresses, the prefix shall > be either the "Well-Known Prefix" or a "Network-Specific Prefix" unique t= o > the organization deploying the address translators." This cannot be the > CLAT-node delegated prefix. > >> > > > > Why can this not be the CLAT node prefix? NSP of the home network. > > AFAIK, a single operator supports many CLATs > They cannot be reached at the NSP prefix which, by RFC6052, is "unique to > the organization deploying the address translators" (i.e the operator). > i understand it depends how we understand the word "organization" in the RFC6052 context. it is not necessarily the "operator" (of the infrastructure or the autonomous system). exactly speaking, it is the aggregator. in the 464xlat sec 7.5 variant case 1, the NSP is the delegated prefix for, e.g., the home network; in the case 2, as the CLAT has not a dedicated IPv6 prefix, the aggregator is the higher level entity (operator or suboperator). in either case, single operator supporting many CLATs, AFAIK, is not a problem according to the 464xlat text. the "unique" in the context of RFC6052 is not a restriction, i think. if my understanding is not correct, please don't hesitate to point out. thanks! - maoke > > >> In my understanding, this second option cannot work. > >> If I missed something, thank you for explaining. > >> > >> (2) > >> Coming back to the relationship with BIH: > >> - We now know there is open-source running code for BIH. > > > > Same as 464XLAT draft > > Right =3D> not a decision criterion. > > >> - With BIH, a single IPv6 prefix per customer node is sufficient in > customer nodes. > > > > Same as defined is this 464XLAT draft > > BIH can readily be used on any ISPv6 network having a NAT64 accessible at > its well known prefix 64:ff9b::/96. > This isn't the case with the proposed 464XLAT design (see above). > > >> - IPv4-only hosts, if behind BIH-capable CPEs, have connectivity with > servers that, because they are also in customer sites of IPv6-only > networks, can have AAAA records but no A records in the DNS. > >> > > > > Brian, Lorenzo, Gert, and myself, and the market (there is no > > meaningful market for IPv6-only services on the internet) say this is > > not a value add. > > When discussing whether a new market exists, those who explain where they > see it are in general more relevant than those who, having not seen it > yet, negate that it can exist. > > In any case, advantages of BIH for the 464XLAT scenario go beyond BIH > applicability to IPv4-only hosts reaching servers attached to IPv6-only > networks. > > Regards, > RD > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --20cf306f744a5e828304bdf3d69d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Remi,

try to=A0understand the question, as=A0a learner. =
2012/4/18 R=E9mi Despr=E9s <despres.remi@lapos= te.net>
Cameron,

2012-04-17 19:30, Cameron Byrne:
...
>> (1)
>> Section 7.5 cites two IPv6 prefix-handling variants
>>
>> - The first one explicitly requires two IPv6 prefixes per CLAT nod= e, a quite expensive constraint.
>>
>
> What is expensive? =A0I think most network operators will say IPv6 /64=
> subnets have no money value, and /64 subnets should be used where ever=
> it makes operational sense without constraint.

OK, expensive may not be the best qualifier.

OTOH, the need to delegate TWO IPv6 prefixes per customer, while there exis= t solutions that work with the ordinary one-prefix-per-customer practice, s= hould by no means be called "Best Common Practice".

I remain firm on that.

>> - The second one is supposed to use only one prefix, but:
>> =A0. Section 7.2 says that the CLAT IPv6 address, which is based o= n a single IPv4 address due to an NAT44 in the CLAT node, is defined in Sec= tion 2.2 of RFC6052.
>> =A0. Section 2.2 of RFC 6052 says "In these addresses, the pr= efix shall be either the "Well-Known Prefix" or a "Network-S= pecific Prefix" unique to the organization deploying the address trans= lators." This cannot be the CLAT-node delegated prefix.
>>
>
> Why can this not be the CLAT node prefix? =A0NSP of the home network.<= br>
AFAIK, a single operator supports many CLATs
They cannot be reached at the NSP prefix which, by RFC6052, is "unique= to the organization deploying the address translators" (i.e the opera= tor).
=A0
if my understanding is not correct, please don't hes= itate to point out. thanks!
=A0
- maoke
=A0

>> In my understanding, this second option cannot =A0work.
>> If I missed something, thank you for explaining.
>>
>> (2)
>> Coming back to the relationship with BIH:
>> - We now know there is open-source running code for BIH.
>
> Same as 464XLAT draft

Right =3D> not a decision criterion.

>> - With BIH, a single IPv6 prefix per customer node is sufficient i= n customer nodes.
>
> Same as defined is this 464XLAT draft

BIH can readily be used on any ISPv6 network having a NAT64 accessibl= e at its well known prefix 64:ff9b::/96.
This isn't the case with the proposed 464XLAT design (see above).

>> - IPv4-only hosts, if behind BIH-capable CPEs, have connectivity w= ith servers that, because they are also in customer sites of IPv6-only netw= orks, can have AAAA records but no A records in the DNS.
>>
>
> Brian, Lorenzo, Gert, and myself, and the market (there is no
> meaningful market for IPv6-only services on the internet) say this is<= br> > not a value add.

When discussing whether a new market exists, those who explain where = they see it are in general more relevant than those who, =A0having not seen= it yet, negate that it can exist.

In any case, advantages of BIH for the 464XLAT scenario go beyond BIH appli= cability to IPv4-only hosts reaching servers attached to IPv6-only networks= .

Regards,
RD

--20cf306f744a5e828304bdf3d69d-- From Internet-Drafts@ietf.org Wed Apr 18 07:38:22 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9B1F21F85B6; Wed, 18 Apr 2012 07:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.229 X-Spam-Level: X-Spam-Status: No, score=-102.229 tagged_above=-999 required=5 tests=[AWL=0.370, 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 l5eynKMHr2SA; Wed, 18 Apr 2012 07:38:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 619B021F85AE; Wed, 18 Apr 2012 07:38:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120418143817.19669.70000.idtracker@ietfa.amsl.com> Date: Wed, 18 Apr 2012 07:38:17 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D ACTION:draft-ietf-v6ops-icp-guidance-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 14:38:22 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : IPv6 Guidance for Internet Content and Application Service Providers Author(s) : B. Carpenter Filename : draft-ietf-v6ops-icp-guidance Pages : 19 Date : April 18, 2012 This document provides guidance and suggestions for Internet Content Providers and Application Service Providers who wish to offer their service to both IPv6 and IPv4 customers. Many of the points will also apply to any enterprise network preparing for IPv6 users. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-icp-guidance-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-v6ops-icp-guidance"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2012-04-18073817.I-D@ietf.org> --NextPart-- From despres.remi@laposte.net Wed Apr 18 08:23:25 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42C6821F85B8 for ; Wed, 18 Apr 2012 08:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.869 X-Spam-Level: X-Spam-Status: No, score=-1.869 tagged_above=-999 required=5 tests=[AWL=-0.171, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 YoAxrZyvvJrb for ; Wed, 18 Apr 2012 08:23:21 -0700 (PDT) Received: from smtpout.laposte.net (smtpout1.laposte.net [193.253.67.226]) by ietfa.amsl.com (Postfix) with ESMTP id ADD0821F84DE for ; Wed, 18 Apr 2012 08:23:20 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8501-out with ME id zTPJ1i00737Y3f403TPJNZ; Wed, 18 Apr 2012 17:23:19 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-23--26887578 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 18 Apr 2012 17:23:17 +0200 Message-Id: <54C3040A-23B1-45A5-A68D-E3A75E05C109@laposte.net> References: <20120417065542.31115.95082.idtracker@ietfa.amsl.com> <20120417160010kawashimam@mail.jp.nec.com> <52219CA6-6C5C-408D-A314-6A04F9E173A9@laposte.net> <832D2D61-034D-46C8-896E-BD34FCDDC271@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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, 18 Apr 2012 15:23:25 -0000 --Apple-Mail-23--26887578 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Maoke, Le 2012-04-18 =E0 15:14, Maoke a =E9crit : > Remi, >=20 > try to understand the question, as a learner.=20 > 2012/4/18 R=E9mi Despr=E9s > Cameron, >=20 > 2012-04-17 19:30, Cameron Byrne: > ... > >> (1) > >> Section 7.5 cites two IPv6 prefix-handling variants > >> > >> - The first one explicitly requires two IPv6 prefixes per CLAT = node, a quite expensive constraint. > >> > > > > What is expensive? I think most network operators will say IPv6 /64 > > subnets have no money value, and /64 subnets should be used where = ever > > it makes operational sense without constraint. >=20 > OK, expensive may not be the best qualifier. >=20 > OTOH, the need to delegate TWO IPv6 prefixes per customer, while there = exist solutions that work with the ordinary one-prefix-per-customer = practice, should by no means be called "Best Common Practice". >=20 > I remain firm on that. >=20 > >> - The second one is supposed to use only one prefix, but: > >> . Section 7.2 says that the CLAT IPv6 address, which is based on a = single IPv4 address due to an NAT44 in the CLAT node, is defined in = Section 2.2 of RFC6052. > >> . Section 2.2 of RFC 6052 says "In these addresses, the prefix = shall be either the "Well-Known Prefix" or a "Network-Specific Prefix" = unique to the organization deploying the address translators." This = cannot be the CLAT-node delegated prefix. > >> > > > > Why can this not be the CLAT node prefix? NSP of the home network. >=20 > AFAIK, a single operator supports many CLATs > They cannot be reached at the NSP prefix which, by RFC6052, is "unique = to the organization deploying the address translators" (i.e the = operator). > =20 > i understand it depends how we understand the word "organization" in = the RFC6052 context. it is not necessarily the "operator" (of the = infrastructure or the autonomous system). exactly speaking, it is the = aggregator. > in the 464xlat sec 7.5 variant case 1, the NSP is the delegated prefix = for, e.g., the home network; This point of the discussion is only about case 2 (Case 1 has two IPv6 = prefixes per customer, something that AFAIK is claimed to be avoided in = case 2) > in the case 2, as the CLAT has not a dedicated IPv6 prefix, Not understood. (It could be taken as meaning that CLAT nodes might have no IPv6 = delegated prefixes.) =20 > the aggregator is the higher level entity (operator or suboperator). = in either case, single operator supporting many CLATs, AFAIK, is not a = problem according to the 464xlat text. the "unique" in the context of = RFC6052 is not a restriction, i think. > =20 > if my understanding is not correct, please don't hesitate to point = out. thanks! RFC6052 specifies addresses that start with a common prefix (WKP or NSP) = followed by IPv4 addresses. I don't see how this could be used to address customer nodes whose = embedded addresses are RFC1918 addresses. Seeing a workable addressing plan for case 2 is for me a prerequisite to = eliminate this doubt. RD > =20 > - maoke > =20 >=20 > >> In my understanding, this second option cannot work. > >> If I missed something, thank you for explaining. > >> > >> (2) > >> Coming back to the relationship with BIH: > >> - We now know there is open-source running code for BIH. > > > > Same as 464XLAT draft >=20 > Right =3D> not a decision criterion. >=20 > >> - With BIH, a single IPv6 prefix per customer node is sufficient in = customer nodes. > > > > Same as defined is this 464XLAT draft >=20 > BIH can readily be used on any ISPv6 network having a NAT64 accessible = at its well known prefix 64:ff9b::/96. > This isn't the case with the proposed 464XLAT design (see above). >=20 > >> - IPv4-only hosts, if behind BIH-capable CPEs, have connectivity = with servers that, because they are also in customer sites of IPv6-only = networks, can have AAAA records but no A records in the DNS. > >> > > > > Brian, Lorenzo, Gert, and myself, and the market (there is no > > meaningful market for IPv6-only services on the internet) say this = is > > not a value add. >=20 > When discussing whether a new market exists, those who explain where = they see it are in general more relevant than those who, having not = seen it yet, negate that it can exist. >=20 > In any case, advantages of BIH for the 464XLAT scenario go beyond BIH = applicability to IPv4-only hosts reaching servers attached to IPv6-only = networks. >=20 > Regards, > RD >=20 >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --Apple-Mail-23--26887578 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
Remi,

try to understand the = question, as a learner.
2012/4/18 R=E9mi Despr=E9s <despres.remi@laposte.net><= /span>
Cameron,

2012-04-17 = 19:30, Cameron Byrne:
...
>> (1)
>> Section 7.5 cites two IPv6 prefix-handling variants
>>
>> - The first one explicitly requires two IPv6 prefixes per CLAT = node, a quite expensive constraint.
>>
>
> What is expensive?  I think most network operators will say = IPv6 /64
> subnets have no money value, and /64 subnets should be used where = ever
> it makes operational sense without constraint.

OK, expensive may not be the best qualifier.

OTOH, the need to delegate TWO IPv6 prefixes per customer, while there = exist solutions that work with the ordinary one-prefix-per-customer = practice, should by no means be called "Best Common Practice".

I remain firm on that.

>> - The second one is supposed to use only one prefix, but:
>>  . Section 7.2 says that the CLAT IPv6 address, which is = based on a single IPv4 address due to an NAT44 in the CLAT node, is = defined in Section 2.2 of RFC6052.
>>  . Section 2.2 of RFC 6052 says "In these addresses, the = prefix shall be either the "Well-Known Prefix" or a "Network-Specific = Prefix" unique to the organization deploying the address translators." = This cannot be the CLAT-node delegated prefix.
>>
>
> Why can this not be the CLAT node prefix?  NSP of the home = network.

AFAIK, a single operator supports many CLATs
They cannot be reached at the NSP prefix which, by RFC6052, is "unique = to the organization deploying the address translators" (i.e the = operator).
 
i understand it depends = how we understand the word "organization" in the RFC6052 context. = it is not necessarily the "operator" (of the infrastructure or the = autonomous system). exactly speaking, it is the aggregator. =

in the 464xlat sec 7.5 variant case 1, = the NSP is the delegated prefix for, e.g., the home network; =

This point of the = discussion is only about case 2 (Case 1 has two IPv6 prefixes per = customer, something that AFAIK is claimed to be avoided in case = 2)

in = the case 2, as the CLAT has not a dedicated IPv6 prefix, =

Not understood.
(It = could be taken as meaning that CLAT nodes might have no IPv6 delegated = prefixes.)
 

the aggregator is the = higher level entity (operator or suboperator). in either case, single = operator supporting many CLATs, AFAIK, is not a problem according to the = 464xlat text. the "unique" in the context of RFC6052 is not a = restriction, i think.
 
if my understanding is not correct, please don't = hesitate to point out. = thanks!

RFC6052 specifies = addresses that start with a common prefix (WKP or NSP) followed by IPv4 = addresses.
I don't see how this could be used to address = customer nodes whose embedded addresses are RFC1918 = addresses.

Seeing a workable addressing plan = for case 2 is for me a prerequisite to eliminate this = doubt.

RD




 
- = maoke
 

>> In my understanding, this second option cannot  work.
>> If I missed something, thank you for explaining.
>>
>> (2)
>> Coming back to the relationship with BIH:
>> - We now know there is open-source running code for BIH.
>
> Same as 464XLAT draft

Right =3D> not a decision criterion.

>> - With BIH, a single IPv6 prefix per customer node is = sufficient in customer nodes.
>
> Same as defined is this 464XLAT draft

BIH can readily be used on any ISPv6 network having a NAT64 = accessible at its well known prefix 64:ff9b::/96.
This isn't the case with the proposed 464XLAT design (see above).

>> - IPv4-only hosts, if behind BIH-capable CPEs, have = connectivity with servers that, because they are also in customer sites = of IPv6-only networks, can have AAAA records but no A records in the = DNS.
>>
>
> Brian, Lorenzo, Gert, and myself, and the market (there is no
> meaningful market for IPv6-only services on the internet) say this = is
> not a value add.

When discussing whether a new market exists, those who explain = where they see it are in general more relevant than those who, =  having not seen it yet, negate that it can exist.

In any case, advantages of BIH for the 464XLAT scenario go beyond BIH = applicability to IPv4-only hosts reaching servers attached to IPv6-only = networks.

Regards,
RD




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


= --Apple-Mail-23--26887578-- From Tina.Tsou.Zouting@huawei.com Wed Apr 18 10:45:27 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94E4521F84D5 for ; Wed, 18 Apr 2012 10:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.214 X-Spam-Level: X-Spam-Status: No, score=-2.214 tagged_above=-999 required=5 tests=[AWL=-0.215, 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 Rni0cRCW2lSJ for ; Wed, 18 Apr 2012 10:45:23 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3850021F84C9 for ; Wed, 18 Apr 2012 10:45:23 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFI28063; Wed, 18 Apr 2012 13:45:23 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 18 Apr 2012 10:43:22 -0700 Received: from SZXEML417-HUB.china.huawei.com (10.82.67.156) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 18 Apr 2012 10:43:26 -0700 Received: from SZXEML526-MBX.china.huawei.com ([169.254.2.22]) by szxeml417-hub.china.huawei.com ([10.82.67.156]) with mapi id 14.01.0323.003; Thu, 19 Apr 2012 01:42:57 +0800 From: Tina TSOU To: Sheng Jiang Thread-Topic: [v6ops] In the vein of of the icp/dc guidance Thread-Index: AQHNHMTi2cMjFJWMukaTo/obkh9VJJafpZMAgAAS4ICAASNjHA== Date: Wed, 18 Apr 2012 17:42:56 +0000 Message-ID: References: <4F8DAA5E.3070007@bogus.com> <4F8E695C.3050705@gmail.com>, <5D36713D8A4E7348A7E10DF7437A4B921E48B7E0@SZXEML506-MBS.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B921E48B7E0@SZXEML506-MBS.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: IPv6 Ops WG Subject: Re: [v6ops] In the vein of of the icp/dc 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, 18 Apr 2012 17:45:27 -0000 In the process of planning the migration of operators' customers to IPv6, t= hose operating (both private and public) data centers asked operators for = advice on both interim and permament solutions, stages to customers and som= e reference to compare different proposals they can get from their provider= s. Not to mention that operators are provindig datacenter services as well.= The idea of http://datatracker.ietf.org/doc/draft-lopez-v6ops-dc-ipv6/ is= to provide a reference framework for DC migration into IPv6 and discuss th= e essential issues at each stage. Datacenter and network operators willing = to evaluate the options for DC infrastructure migration to IPv6, as well as= technology providers interested in positioning their solutions. Sent from my iPad On Apr 18, 2012, at 1:37 AM, "Sheng Jiang" wrote: > I think, IPv6-only data centre is a good approach. The most general case = would be a DC operator build up a new IPv6-only DC parallel with the existi= ng IPv4 DC. Dual stack DC is too complicated for DC internal or transition = purpose. >=20 > Sheng >=20 >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf >> Of Brian E Carpenter >> Sent: Wednesday, April 18, 2012 3:12 PM >> To: Joel jaeggli >> Cc: IPv6 Ops WG >> Subject: Re: [v6ops] In the vein of of the icp/dc guidance >>=20 >> It's fine work IMHO, but I expect that most DC operators will >> not want to jump in at the deep end in this way. >>=20 >> Regards >> Brian >>=20 >> On 2012-04-17 18:37, Joel jaeggli wrote: >>> This was presented at ripe64. >>>=20 >>> https://ripe64.ripe.net/presentations/67-20120417-RIPE64- >> The_Case_for_IPv6_Only_Data_Centres.pdf >>> _______________________________________________ >>> 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 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From fibrib@gmail.com Wed Apr 18 19:15:44 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51C4621F8493 for ; Wed, 18 Apr 2012 19:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.908 X-Spam-Level: X-Spam-Status: No, score=-2.908 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nOvDo9M-A543 for ; Wed, 18 Apr 2012 19:15:40 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id D30C321F8495 for ; Wed, 18 Apr 2012 19:15:39 -0700 (PDT) Received: by qcsq13 with SMTP id q13so5953854qcs.31 for ; Wed, 18 Apr 2012 19:15:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MNd73GwmOUAVZDgYBZKnM+t3PnoF0FlX18ybbLMtNkA=; b=BGKaRRh9Skdw32RmYTgrHCai/NQN4E5ukBHWztyYPgoE/YVEDoRassRST2a37vmPub VvJczETstQKqkG4RAZgRC87wAWCeff8KVyFuycka70CgXpUytISACyXBTDg5kUQULOJv 6wR2cfd0ksv1H5ccoNLh/klOWw7YQyTJ4uRHdlZOSKbS9fKVIAYMv7/gPkUhcdQMnh1J K9/oFmByQQG9VUJ0QcMOl4+HI/Ypx/sb2l0abBt3BR7DX2NI1JzDqvSyDnd3P57h3Ru5 pSwRa1Bfll8Zp3KOE7Hde0rujmv1tUtBf/89zPZrsGkMn58ZDE4Udm6DqqkwPl2xqUEn bwng== MIME-Version: 1.0 Received: by 10.224.35.130 with SMTP id p2mr526364qad.32.1334801739278; Wed, 18 Apr 2012 19:15:39 -0700 (PDT) Received: by 10.229.123.197 with HTTP; Wed, 18 Apr 2012 19:15:38 -0700 (PDT) In-Reply-To: <54C3040A-23B1-45A5-A68D-E3A75E05C109@laposte.net> References: <20120417065542.31115.95082.idtracker@ietfa.amsl.com> <20120417160010kawashimam@mail.jp.nec.com> <52219CA6-6C5C-408D-A314-6A04F9E173A9@laposte.net> <832D2D61-034D-46C8-896E-BD34FCDDC271@laposte.net> <54C3040A-23B1-45A5-A68D-E3A75E05C109@laposte.net> Date: Thu, 19 Apr 2012 02:15:38 +0000 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=20cf306f744a83e8f404bdfebf84 Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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, 19 Apr 2012 02:15:44 -0000 --20cf306f744a83e8f404bdfebf84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Remi, 2012/4/18 R=E9mi Despr=E9s > Maoke, > > > Le 2012-04-18 =E0 15:14, Maoke a =E9crit : > > Remi, > > try to understand the question, as a learner. > 2012/4/18 R=E9mi Despr=E9s > >> Cameron, >> >> 2012-04-17 19:30, Cameron Byrne: >> ... >> >> (1) >> >> Section 7.5 cites two IPv6 prefix-handling variants >> >> >> >> - The first one explicitly requires two IPv6 prefixes per CLAT node, = a >> quite expensive constraint. >> >> >> > >> > What is expensive? I think most network operators will say IPv6 /64 >> > subnets have no money value, and /64 subnets should be used where ever >> > it makes operational sense without constraint. >> >> OK, expensive may not be the best qualifier. >> >> OTOH, the need to delegate TWO IPv6 prefixes per customer, while there >> exist solutions that work with the ordinary one-prefix-per-customer >> practice, should by no means be called "Best Common Practice". >> >> I remain firm on that. >> >> >> - The second one is supposed to use only one prefix, but: >> >> . Section 7.2 says that the CLAT IPv6 address, which is based on a >> single IPv4 address due to an NAT44 in the CLAT node, is defined in Sect= ion >> 2.2 of RFC6052. >> >> . Section 2.2 of RFC 6052 says "In these addresses, the prefix shall >> be either the "Well-Known Prefix" or a "Network-Specific Prefix" unique = to >> the organization deploying the address translators." This cannot be the >> CLAT-node delegated prefix. >> >> >> > >> > Why can this not be the CLAT node prefix? NSP of the home network. >> >> AFAIK, a single operator supports many CLATs >> They cannot be reached at the NSP prefix which, by RFC6052, is "unique t= o >> the organization deploying the address translators" (i.e the operator). >> > > i understand it depends how we understand the word "organization" in the > RFC6052 context. it is not necessarily the "operator" (of the > infrastructure or the autonomous system). exactly speaking, it is the > aggregator. > > > in the 464xlat sec 7.5 variant case 1, the NSP is the delegated prefix > for, e.g., the home network; > > > This point of the discussion is only about case 2 (Case 1 has two IPv6 > prefixes per customer, something that AFAIK is claimed to be avoided in > case 2) > i don't so understand what do you refer to with the "TWO ipv6 prefixes PER customer". do you mean the delegated prefix AND the one /64 for the purpose of 464xlat? if the delegated prefix is larger than /64, i think the 464xlat-use prefix could be selected from this delegated prefix as a more-specific (a /64), dedicated for 464xlat-use only. if the delegated prefix is another /64, it is the case you mean 2 prefixes, right? for the case 2, to my understanding, it is not "claimed to be avoided" but another case of reality, where only the delegated prefix (one /64) is assigned to the CLAT so that a dedicated /64 for 464xlat funtionality is not allowed. in this case, CLAT does NAT44 so that only one IPv4-embedded address is used for the purpose of 464xlat. it also does work. do i miss anything? > > in the case 2, as the CLAT has not a dedicated IPv6 prefix, > > > Not understood. > (It could be taken as meaning that CLAT nodes might have no IPv6 delegate= d > prefixes.) > > > the aggregator is the higher level entity (operator or suboperator). in > either case, single operator supporting many CLATs, AFAIK, is not a probl= em > according to the 464xlat text. the "unique" in the context of RFC6052 is > not a restriction, i think. > > if my understanding is not correct, please don't hesitate to point out. > thanks! > > > RFC6052 specifies addresses that start with a common prefix (WKP or NSP) > followed by IPv4 addresses. > I don't see how this could be used to address customer nodes whose > embedded addresses are RFC1918 addresses. > i understand it is ok because 464xlat's PLAT performs stateful translation between the IPv6 address (with RFC1918 IPv4 embedded) and a global IPv4 address in the pool that held by PLAT. (btw, i don't think WKP is used in 464xlat for the CLAT and CLAT-served hosts. RFC6052 also has the restriction that RFC1918 addresses MUST NOT be used with WKP). is this understanding correct? i think the case1/2 is convining enough as a workabale addressing plan. - maoke > > Seeing a workable addressing plan for case 2 is for me a prerequisite to > eliminate this doubt. > > RD > > > > > > - maoke > > >> >> >> In my understanding, this second option cannot work. >> >> If I missed something, thank you for explaining. >> >> >> >> (2) >> >> Coming back to the relationship with BIH: >> >> - We now know there is open-source running code for BIH. >> > >> > Same as 464XLAT draft >> >> Right =3D> not a decision criterion. >> >> >> - With BIH, a single IPv6 prefix per customer node is sufficient in >> customer nodes. >> > >> > Same as defined is this 464XLAT draft >> >> BIH can readily be used on any ISPv6 network having a NAT64 accessible a= t >> its well known prefix 64:ff9b::/96. >> This isn't the case with the proposed 464XLAT design (see above). >> >> >> - IPv4-only hosts, if behind BIH-capable CPEs, have connectivity with >> servers that, because they are also in customer sites of IPv6-only >> networks, can have AAAA records but no A records in the DNS. >> >> >> > >> > Brian, Lorenzo, Gert, and myself, and the market (there is no >> > meaningful market for IPv6-only services on the internet) say this is >> > not a value add. >> >> When discussing whether a new market exists, those who explain where the= y >> see it are in general more relevant than those who, having not seen it >> yet, negate that it can exist. >> >> In any case, advantages of BIH for the 464XLAT scenario go beyond BIH >> applicability to IPv4-only hosts reaching servers attached to IPv6-only >> networks. >> >> Regards, >> RD >> >> >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > > > --20cf306f744a83e8f404bdfebf84 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Remi,

2012/4/18 R=E9mi Despr=E9s <despres.remi@lapo= ste.net>
Maoke,


Le 2012-04-18 =E0 15:14, Maoke a =E9crit :

Remi,

try to=A0understand the ques= tion, as=A0a learner.
2012/4/18 R=E9mi Despr=E9s <despre= s.remi@laposte.net>
Cameron,

2012-04-17 19:30, Cameron Byrne:
...
>> (1)
>> Section 7.5 cites two IPv6 prefix-handling variants
>>
>> - The first one explicitly requires two IPv6 prefixes per CLAT nod= e, a quite expensive constraint.
>>
>
> What is expensive? =A0I think most network operators will say IPv6 /64=
> subnets have no money value, and /64 subnets should be used where ever=
> it makes operational sense without constraint.

OK, expensive may not be the best qualifier.

OTOH, the need to delegate TWO IPv6 prefixes per customer, while there exis= t solutions that work with the ordinary one-prefix-per-customer practice, s= hould by no means be called "Best Common Practice".

I remain firm on that.

>> - The second one is supposed to use only one prefix, but:
>> =A0. Section 7.2 says that the CLAT IPv6 address, which is based o= n a single IPv4 address due to an NAT44 in the CLAT node, is defined in Sec= tion 2.2 of RFC6052.
>> =A0. Section 2.2 of RFC 6052 says "In these addresses, the pr= efix shall be either the "Well-Known Prefix" or a "Network-S= pecific Prefix" unique to the organization deploying the address trans= lators." This cannot be the CLAT-node delegated prefix.
>>
>
> Why can this not be the CLAT node prefix? =A0NSP of the home network.<= br>
AFAIK, a single operator supports many CLATs
They cannot be reached at the NSP prefix which, by RFC6052, is "unique= to the organization deploying the address translators" (i.e the opera= tor).
=A0
i understand it depends how we und= erstand the word "organization" in the RFC6052 context. it=A0is n= ot necessarily the "operator" (of the infrastructure or the auton= omous system).=A0exactly speaking, it is the aggregator.

in the 464xlat sec 7.5 variant case=A01, the NSP is the delegated pre= fix for, e.g.,=A0the home network;

=
This point of the discussion is only about case 2 (Case 1 has two IPv6= prefixes per customer, something that AFAIK is claimed to be avoided in ca= se 2)

i don't s= o understand what do you refer to with the "TWO ipv6 prefixes PER cust= omer". do you mean the delegated prefix AND the one /64 for the purpos= e of 464xlat? if the delegated prefix is larger than /64, i think the 464xl= at-use prefix could be selected from this delegated prefix as a more-specif= ic (a /64), dedicated for 464xlat-use only. if the delegated prefix is anot= her /64, it is the case you mean 2 prefixes, right?=A0

for the case 2, to my understanding, it is not "cl= aimed to be avoided" but another case of reality, where only the deleg= ated prefix (one /64) is assigned to the CLAT so that a dedicated /64 for 4= 64xlat funtionality is not allowed. in this case, CLAT does NAT44 so that o= nly one IPv4-embedded address is used for the purpose of 464xlat. it also d= oes work. =A0

do i miss anything?
=A0

in the case 2, as= the CLAT has not a dedicated IPv6 prefix,
Not understood.
(It could be taken as meaning that = CLAT nodes might have no IPv6 delegated prefixes.)
=A0

the aggregator is the higher level entit= y (operator or suboperator). in either case, single operator supporting man= y CLATs, AFAIK, is not a problem according to the 464xlat text. the "u= nique" in the context of RFC6052 is not a restriction, i think.
=A0
if my understanding is not correct, please don't hes= itate to point out. thanks!

RFC6052 specifies addresses that start with a common prefix (WKP or NSP)= followed by IPv4 addresses.
I don't see how this could be used to address customer nodes whose= embedded addresses are RFC1918 addresses.

i understand it is ok because 464xlat's PLAT pe= rforms stateful translation between the IPv6 address (with RFC1918 IPv4 emb= edded) and a global IPv4 address in the pool that held by PLAT. (btw, i don= 't think WKP is used in 464xlat for the CLAT and CLAT-served hosts. RFC= 6052 also has the restriction that RFC1918 addresses MUST NOT be used with = WKP). is this understanding correct? i think the case1/2 is convining enoug= h as a workabale addressing plan.=A0

- maoke
=A0

Seeing= a workable addressing plan for case 2 is for me a prerequisite to eliminat= e this doubt.=A0

RD



=
=A0
- maoke
=A0

>> In my understanding, this second option cannot =A0work.
>> If I missed something, thank you for explaining.
>>
>> (2)
>> Coming back to the relationship with BIH:
>> - We now know there is open-source running code for BIH.
>
> Same as 464XLAT draft

Right =3D> not a decision criterion.

>> - With BIH, a single IPv6 prefix per customer node is sufficient i= n customer nodes.
>
> Same as defined is this 464XLAT draft

BIH can readily be used on any ISPv6 network having a NAT64 accessibl= e at its well known prefix 64:ff9b::/96.
This isn't the case with the proposed 464XLAT design (see above).

>> - IPv4-only hosts, if behind BIH-capable CPEs, have connectivity w= ith servers that, because they are also in customer sites of IPv6-only netw= orks, can have AAAA records but no A records in the DNS.
>>
>
> Brian, Lorenzo, Gert, and myself, and the market (there is no
> meaningful market for IPv6-only services on the internet) say this is<= br> > not a value add.

When discussing whether a new market exists, those who explain where = they see it are in general more relevant than those who, =A0having not seen= it yet, negate that it can exist.

In any case, advantages of BIH for the 464XLAT scenario go beyond BIH appli= cability to IPv4-only hosts reaching servers attached to IPv6-only networks= .

Regards,
RD




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



--20cf306f744a83e8f404bdfebf84-- From kawashimam@vx.jp.nec.com Thu Apr 19 00:26:36 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C17A821F84EC for ; Thu, 19 Apr 2012 00:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.21 X-Spam-Level: X-Spam-Status: No, score=0.21 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, 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 4Je--CS5jjWE for ; Thu, 19 Apr 2012 00:26:32 -0700 (PDT) Received: from tyo201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.193]) by ietfa.amsl.com (Postfix) with ESMTP id 1E82021F8441 for ; Thu, 19 Apr 2012 00:26:31 -0700 (PDT) Received: from mailgate3.nec.co.jp ([10.7.69.195]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id q3J7QSL3001407; Thu, 19 Apr 2012 16:26:28 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id q3J7QSv06768; Thu, 19 Apr 2012 16:26:28 +0900 (JST) Received: from mail01b.kamome.nec.co.jp (mail01b.kamome.nec.co.jp [10.25.43.2]) by mailsv3.nec.co.jp (8.13.8/8.13.4) with ESMTP id q3J7QSEj004119; Thu, 19 Apr 2012 16:26:28 +0900 (JST) Received: from shikibu.jp.nec.com ([10.26.220.2] [10.26.220.2]) by mail02.kamome.nec.co.jp with ESMTP id BT-MMP-753412; Thu, 19 Apr 2012 16:25:42 +0900 Received: from siznecatg159185 ([10.3.159.185] [10.3.159.185]) by mail.jp.nec.com with ESMTP; Thu, 19 Apr 2012 16:25:42 +0900 To: Maoke In-reply-to: References: Message-Id: <20120419162541kawashimam@mail.jp.nec.com> Mime-Version: 1.0 X-Mailer: StarOffice21/MailClient[4.65 Step9] From: Masanobu Kawashima Date: Thu, 19 Apr 2012 16:25:39 +0900 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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, 19 Apr 2012 07:26:36 -0000 Hi Maoke, Thank you for explaining it so clearly. >> This point of the discussion is only about case 2 (Case 1 has two IPv6 >> prefixes per customer, something that AFAIK is claimed to be avoided in >> case 2) > >i don't so understand what do you refer to with the "TWO ipv6 prefixes PER >customer". do you mean the delegated prefix AND the one /64 for the purpose >of 464xlat? if the delegated prefix is larger than /64, i think the >464xlat-use prefix could be selected from this delegated prefix as a >more-specific (a /64), dedicated for 464xlat-use only. if the delegated >prefix is another /64, it is the case you mean 2 prefixes, right? Exactly. >for the case 2, to my understanding, it is not "claimed to be avoided" but >another case of reality, where only the delegated prefix (one /64) is >assigned to the CLAT so that a dedicated /64 for 464xlat funtionality is >not allowed. in this case, CLAT does NAT44 so that only one IPv4-embedded >address is used for the purpose of 464xlat. it also does work. Exactly. >> RFC6052 specifies addresses that start with a common prefix (WKP or NSP) >> followed by IPv4 addresses. >> I don't see how this could be used to address customer nodes whose >> embedded addresses are RFC1918 addresses. > >i understand it is ok because 464xlat's PLAT performs stateful translation >between the IPv6 address (with RFC1918 IPv4 embedded) and a global IPv4 >address in the pool that held by PLAT. You're right. >(btw, i don't think WKP is used in 464xlat for the CLAT and CLAT-served >hosts. RFC6052 also has the restriction that RFC1918 addresses MUST NOT >be used with WKP). is this understanding correct? i think the case1/2 is >convining enough as a workabale addressing plan. I also think that non-global IPv4 addresses must not be used with WKP. Regards, Masanobu >Remi, > >2012/4/18 Remi Despres > >> Maoke, >> >> >> Le 2012-04-18 15:14, Maoke a rit : >> >> Remi, >> >> try to understand the question, as a learner. >> 2012/4/18 Remi Despres >> >>> Cameron, >>> >>> 2012-04-17 19:30, Cameron Byrne: >>> ... >>> >> (1) >>> >> Section 7.5 cites two IPv6 prefix-handling variants >>> >> >>> >> - The first one explicitly requires two IPv6 prefixes per CLAT node, a >>> quite expensive constraint. >>> >> >>> > >>> > What is expensive? I think most network operators will say IPv6 /64 >>> > subnets have no money value, and /64 subnets should be used where ever >>> > it makes operational sense without constraint. >>> >>> OK, expensive may not be the best qualifier. >>> >>> OTOH, the need to delegate TWO IPv6 prefixes per customer, while there >>> exist solutions that work with the ordinary one-prefix-per-customer >>> practice, should by no means be called "Best Common Practice". >>> >>> I remain firm on that. >>> >>> >> - The second one is supposed to use only one prefix, but: >>> >> . Section 7.2 says that the CLAT IPv6 address, which is based on a >>> single IPv4 address due to an NAT44 in the CLAT node, is defined in Section >>> 2.2 of RFC6052. >>> >> . Section 2.2 of RFC 6052 says "In these addresses, the prefix shall >>> be either the "Well-Known Prefix" or a "Network-Specific Prefix" unique to >>> the organization deploying the address translators." This cannot be the >>> CLAT-node delegated prefix. >>> >> >>> > >>> > Why can this not be the CLAT node prefix? NSP of the home network. >>> >>> AFAIK, a single operator supports many CLATs >>> They cannot be reached at the NSP prefix which, by RFC6052, is "unique to >>> the organization deploying the address translators" (i.e the operator). >>> >> >> i understand it depends how we understand the word "organization" in the >> RFC6052 context. it is not necessarily the "operator" (of the >> infrastructure or the autonomous system). exactly speaking, it is the >> aggregator. >> >> >> in the 464xlat sec 7.5 variant case 1, the NSP is the delegated prefix >> for, e.g., the home network; >> >> >> This point of the discussion is only about case 2 (Case 1 has two IPv6 >> prefixes per customer, something that AFAIK is claimed to be avoided in >> case 2) >> > >i don't so understand what do you refer to with the "TWO ipv6 prefixes PER >customer". do you mean the delegated prefix AND the one /64 for the purpose >of 464xlat? if the delegated prefix is larger than /64, i think the >464xlat-use prefix could be selected from this delegated prefix as a >more-specific (a /64), dedicated for 464xlat-use only. if the delegated >prefix is another /64, it is the case you mean 2 prefixes, right? > >for the case 2, to my understanding, it is not "claimed to be avoided" but >another case of reality, where only the delegated prefix (one /64) is >assigned to the CLAT so that a dedicated /64 for 464xlat funtionality is >not allowed. in this case, CLAT does NAT44 so that only one IPv4-embedded >address is used for the purpose of 464xlat. it also does work. > >do i miss anything? > > >> >> in the case 2, as the CLAT has not a dedicated IPv6 prefix, >> >> >> Not understood. >> (It could be taken as meaning that CLAT nodes might have no IPv6 delegated >> prefixes.) >> >> >> the aggregator is the higher level entity (operator or suboperator). in >> either case, single operator supporting many CLATs, AFAIK, is not a problem >> according to the 464xlat text. the "unique" in the context of RFC6052 is >> not a restriction, i think. >> >> if my understanding is not correct, please don't hesitate to point out. >> thanks! >> >> >> RFC6052 specifies addresses that start with a common prefix (WKP or NSP) >> followed by IPv4 addresses. >> I don't see how this could be used to address customer nodes whose >> embedded addresses are RFC1918 addresses. >> > >i understand it is ok because 464xlat's PLAT performs stateful translation >between the IPv6 address (with RFC1918 IPv4 embedded) and a global IPv4 >address in the pool that held by PLAT. (btw, i don't think WKP is used in >464xlat for the CLAT and CLAT-served hosts. RFC6052 also has the >restriction that RFC1918 addresses MUST NOT be used with WKP). is this >understanding correct? i think the case1/2 is convining enough as a >workabale addressing plan. > >- maoke > > >> >> Seeing a workable addressing plan for case 2 is for me a prerequisite to >> eliminate this doubt. >> > >> RD >> >> >> >> >> >> - maoke >> >> >>> >>> >> In my understanding, this second option cannot work. >>> >> If I missed something, thank you for explaining. >>> >> >>> >> (2) >>> >> Coming back to the relationship with BIH: >>> >> - We now know there is open-source running code for BIH. >>> > >>> > Same as 464XLAT draft >>> >>> Right => not a decision criterion. >>> >>> >> - With BIH, a single IPv6 prefix per customer node is sufficient in >>> customer nodes. >>> > >>> > Same as defined is this 464XLAT draft >>> >>> BIH can readily be used on any ISPv6 network having a NAT64 accessible at >>> its well known prefix 64:ff9b::/96. >>> This isn't the case with the proposed 464XLAT design (see above). >>> >>> >> - IPv4-only hosts, if behind BIH-capable CPEs, have connectivity with >>> servers that, because they are also in customer sites of IPv6-only >>> networks, can have AAAA records but no A records in the DNS. >>> >> >>> > >>> > Brian, Lorenzo, Gert, and myself, and the market (there is no >>> > meaningful market for IPv6-only services on the internet) say this is >>> > not a value add. >>> >>> When discussing whether a new market exists, those who explain where they >>> see it are in general more relevant than those who, having not seen it >>> yet, negate that it can exist. >>> >>> In any case, advantages of BIH for the 464XLAT scenario go beyond BIH >>> applicability to IPv4-only hosts reaching servers attached to IPv6-only >>> networks. >>> >>> Regards, >>> RD >>> >>> >>> >>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> >> >> >> > ======================================== NEC AccessTechnica, Ltd. Product Development Department Masanobu Kawashima kawashimam@vx.jp.nec.com http://www.necat.co.jp/ ======================================== From despres.remi@laposte.net Thu Apr 19 01:41:42 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0BB321F85E5 for ; Thu, 19 Apr 2012 01:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.867 X-Spam-Level: X-Spam-Status: No, score=-1.867 tagged_above=-999 required=5 tests=[AWL=-0.168, 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 DqNInnirdftv for ; Thu, 19 Apr 2012 01:41:38 -0700 (PDT) Received: from smtpout.laposte.net (smtpout1.laposte.net [193.253.67.226]) by ietfa.amsl.com (Postfix) with ESMTP id E556A21F85C4 for ; Thu, 19 Apr 2012 01:41:37 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8501-out with ME id zkhY1i00737Y3f403khYyq; Thu, 19 Apr 2012 10:41:35 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <20120419162541kawashimam@mail.jp.nec.com> Date: Thu, 19 Apr 2012 10:41:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120419162541kawashimam@mail.jp.nec.com> To: Masanobu Kawashima X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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, 19 Apr 2012 08:41:42 -0000 Masanobu, Please see comments in line. 2012-04-19 09:25, Masanobu Kawashima: >=20 > Hi Maoke, >=20 > Thank you for explaining it so clearly. >=20 >>> This point of the discussion is only about case 2 (Case 1 has two = IPv6 >>> prefixes per customer, something that AFAIK is claimed to be avoided = in >>> case 2) >>=20 >> i don't so understand what do you refer to with the "TWO ipv6 = prefixes PER >> customer". do you mean the delegated prefix AND the one /64 for the = purpose >> of 464xlat? if the delegated prefix is larger than /64, i think the >> 464xlat-use prefix could be selected from this delegated prefix as a >> more-specific (a /64), dedicated for 464xlat-use only. if the = delegated >> prefix is another /64, it is the case you mean 2 prefixes, right? >=20 > Exactly. The text in section 7.5 about case 1 is:=20 "the CLAT will have a dedicated /64 via DHCPv6 prefix delegation = [RFC3633] or other means to source and receive IPv6 packets associated = with the [RFC6145] stateless translation of IPv4 packets to the local = clients. If the CLAT choose one /64 prefix for translation from = delegated prefix, then it SHOULD NOT be used for anything else." - In my understanding, this implies a /64 for 464XLAT, and another = prefix for native IPv6. - In a recent email, Cameron's answer about case 1 which, as I had said = "explicitly requires two IPv6 prefixes per CLAT node, a quite expensive = constraint" was "What is expensive? I think most network operators will = say IPv6 /64 subnets have no money value". This was AFAIK an implicit = acknowledgement that TWO prefixes were needed. (Sorry if I = misinterpreted.) >> for the case 2, to my understanding, it is not "claimed to be = avoided" but >> another case of reality, where only the delegated prefix (one /64) is >> assigned to the CLAT so that a dedicated /64 for 464xlat funtionality = is >> not allowed. in this case, CLAT does NAT44 so that only one = IPv4-embedded >> address is used for the purpose of 464xlat. it also does work. >=20 > Exactly. First, please note that the approach of draft-02 for case 2, being new, = isn't one of those that were tested. How it can work remains for me an open question. In order to understand what you mean, I just ask for a simple example = addressing plan, i.e., to be more precise: (a) The operator NAT64 prefix (b) The delegated /64 of an example CLAT-node (c) The source address this CLAT uses when the IPv6 destination starts = with the NAT64 prefix. Without this, I am lost. >>> RFC6052 specifies addresses that start with a common prefix (WKP or = NSP) >>> followed by IPv4 addresses. >>> I don't see how this could be used to address customer nodes whose >>> embedded addresses are RFC1918 addresses. >>=20 >> i understand it is ok because 464xlat's PLAT performs stateful = translation >> between the IPv6 address (with RFC1918 IPv4 embedded) and a global = IPv4 >> address in the pool that held by PLAT. >=20 > You're right. >=20 >=20 >> (btw, i don't think WKP is used in 464xlat for the CLAT and = CLAT-served >> hosts. RFC6052 also has the restriction that RFC1918 addresses MUST = NOT >> be used with WKP). is this understanding correct? See (**) below >> i think the case1/2 is >> convining enough as a workabale addressing plan. Let's see the example addressing plan you can provide. > I also think that non-global IPv4 addresses must not be used with WKP. (**) Well, not a matter of thinking: its written in RFC6052! =20 =3D> Source addresses from CLATs, which are RFC6052 based in your = proposal, are indeed concerned with this rule. But let's also no forget that destination addresses from CLATs contain = GLOBAL IPv4 addresses =3D> they aren't concerned. My doubt that case 2 can work, as currently specified, is independent = from what RFC6052 says on NSPs and RFC1918 addresses. Only an example addressing plan, with its (a) (b) (c) above, can AFAIK = clarify the issue. Regards, RD >=20 > Regards, > Masanobu >=20 >=20 >> Remi, >>=20 >> 2012/4/18 Remi Despres >>=20 >>> Maoke, >>>=20 >>>=20 >>> Le 2012-04-18 15:14, Maoke a rit : >>>=20 >>> Remi, >>>=20 >>> try to understand the question, as a learner. >>> 2012/4/18 Remi Despres >>>=20 >>>> Cameron, >>>>=20 >>>> 2012-04-17 19:30, Cameron Byrne: >>>> ... >>>>>> (1) >>>>>> Section 7.5 cites two IPv6 prefix-handling variants >>>>>>=20 >>>>>> - The first one explicitly requires two IPv6 prefixes per CLAT = node, a >>>> quite expensive constraint. >>>>>>=20 >>>>>=20 >>>>> What is expensive? I think most network operators will say IPv6 = /64 >>>>> subnets have no money value, and /64 subnets should be used where = ever >>>>> it makes operational sense without constraint. >>>>=20 >>>> OK, expensive may not be the best qualifier. >>>>=20 >>>> OTOH, the need to delegate TWO IPv6 prefixes per customer, while = there >>>> exist solutions that work with the ordinary one-prefix-per-customer >>>> practice, should by no means be called "Best Common Practice". >>>>=20 >>>> I remain firm on that. >>>>=20 >>>>>> - The second one is supposed to use only one prefix, but: >>>>>> . Section 7.2 says that the CLAT IPv6 address, which is based on = a >>>> single IPv4 address due to an NAT44 in the CLAT node, is defined in = Section >>>> 2.2 of RFC6052. >>>>>> . Section 2.2 of RFC 6052 says "In these addresses, the prefix = shall >>>> be either the "Well-Known Prefix" or a "Network-Specific Prefix" = unique to >>>> the organization deploying the address translators." This cannot be = the >>>> CLAT-node delegated prefix. >>>>>>=20 >>>>>=20 >>>>> Why can this not be the CLAT node prefix? NSP of the home = network. >>>>=20 >>>> AFAIK, a single operator supports many CLATs >>>> They cannot be reached at the NSP prefix which, by RFC6052, is = "unique to >>>> the organization deploying the address translators" (i.e the = operator). >>>>=20 >>>=20 >>> i understand it depends how we understand the word "organization" in = the >>> RFC6052 context. it is not necessarily the "operator" (of the >>> infrastructure or the autonomous system). exactly speaking, it is = the >>> aggregator. >>>=20 >>>=20 >>> in the 464xlat sec 7.5 variant case 1, the NSP is the delegated = prefix >>> for, e.g., the home network; >>>=20 >>>=20 >>> This point of the discussion is only about case 2 (Case 1 has two = IPv6 >>> prefixes per customer, something that AFAIK is claimed to be avoided = in >>> case 2) >>>=20 >>=20 >> i don't so understand what do you refer to with the "TWO ipv6 = prefixes PER >> customer". do you mean the delegated prefix AND the one /64 for the = purpose >> of 464xlat? if the delegated prefix is larger than /64, i think the >> 464xlat-use prefix could be selected from this delegated prefix as a >> more-specific (a /64), dedicated for 464xlat-use only. if the = delegated >> prefix is another /64, it is the case you mean 2 prefixes, right? >>=20 >> for the case 2, to my understanding, it is not "claimed to be = avoided" but >> another case of reality, where only the delegated prefix (one /64) is >> assigned to the CLAT so that a dedicated /64 for 464xlat funtionality = is >> not allowed. in this case, CLAT does NAT44 so that only one = IPv4-embedded >> address is used for the purpose of 464xlat. it also does work. >>=20 >> do i miss anything? >>=20 >>=20 >>>=20 >>> in the case 2, as the CLAT has not a dedicated IPv6 prefix, >>>=20 >>>=20 >>> Not understood. >>> (It could be taken as meaning that CLAT nodes might have no IPv6 = delegated >>> prefixes.) >>>=20 >>>=20 >>> the aggregator is the higher level entity (operator or suboperator). = in >>> either case, single operator supporting many CLATs, AFAIK, is not a = problem >>> according to the 464xlat text. the "unique" in the context of = RFC6052 is >>> not a restriction, i think. >>>=20 >>> if my understanding is not correct, please don't hesitate to point = out. >>> thanks! >>>=20 >>>=20 >>> RFC6052 specifies addresses that start with a common prefix (WKP or = NSP) >>> followed by IPv4 addresses. >>> I don't see how this could be used to address customer nodes whose >>> embedded addresses are RFC1918 addresses. >>>=20 >>=20 >> i understand it is ok because 464xlat's PLAT performs stateful = translation >> between the IPv6 address (with RFC1918 IPv4 embedded) and a global = IPv4 >> address in the pool that held by PLAT. (btw, i don't think WKP is = used in >> 464xlat for the CLAT and CLAT-served hosts. RFC6052 also has the >> restriction that RFC1918 addresses MUST NOT be used with WKP). is = this >> understanding correct? i think the case1/2 is convining enough as a >> workabale addressing plan. >>=20 >> - maoke >>=20 >>=20 >>>=20 >>> Seeing a workable addressing plan for case 2 is for me a = prerequisite to >>> eliminate this doubt. >>>=20 >>=20 >>> RD >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> - maoke >>>=20 >>>=20 >>>>=20 >>>>>> In my understanding, this second option cannot work. >>>>>> If I missed something, thank you for explaining. >>>>>>=20 >>>>>> (2) >>>>>> Coming back to the relationship with BIH: >>>>>> - We now know there is open-source running code for BIH. >>>>>=20 >>>>> Same as 464XLAT draft >>>>=20 >>>> Right =3D> not a decision criterion. >>>>=20 >>>>>> - With BIH, a single IPv6 prefix per customer node is sufficient = in >>>> customer nodes. >>>>>=20 >>>>> Same as defined is this 464XLAT draft >>>>=20 >>>> BIH can readily be used on any ISPv6 network having a NAT64 = accessible at >>>> its well known prefix 64:ff9b::/96. >>>> This isn't the case with the proposed 464XLAT design (see above). >>>>=20 >>>>>> - IPv4-only hosts, if behind BIH-capable CPEs, have connectivity = with >>>> servers that, because they are also in customer sites of IPv6-only >>>> networks, can have AAAA records but no A records in the DNS. >>>>>>=20 >>>>>=20 >>>>> Brian, Lorenzo, Gert, and myself, and the market (there is no >>>>> meaningful market for IPv6-only services on the internet) say this = is >>>>> not a value add. >>>>=20 >>>> When discussing whether a new market exists, those who explain = where they >>>> see it are in general more relevant than those who, having not = seen it >>>> yet, negate that it can exist. >>>>=20 >>>> In any case, advantages of BIH for the 464XLAT scenario go beyond = BIH >>>> applicability to IPv4-only hosts reaching servers attached to = IPv6-only >>>> networks. >>>>=20 >>>> Regards, >>>> RD >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>=20 >>>=20 >>>=20 >>>=20 >>=20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > NEC AccessTechnica, Ltd. =20 > Product Development Department =20 > Masanobu Kawashima =20 > kawashimam@vx.jp.nec.com =20 > http://www.necat.co.jp/ =20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 From fibrib@gmail.com Thu Apr 19 04:32:50 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE7121F85E4 for ; Thu, 19 Apr 2012 04:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.603 X-Spam-Level: X-Spam-Status: No, score=-2.603 tagged_above=-999 required=5 tests=[AWL=-0.505, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_41=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l+Ht1Zv-tmKN for ; Thu, 19 Apr 2012 04:32:45 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 342D521F858E for ; Thu, 19 Apr 2012 04:32:45 -0700 (PDT) Received: by qcsq13 with SMTP id q13so6196107qcs.31 for ; Thu, 19 Apr 2012 04:32:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=t8dyV0xQQF68bac80aRgfB724FiuN+r1h6GS2bcxFtQ=; b=Q4pMrV8/gGzcoWrR8lttR7yIPK35nFe1hIqttnsremWtI3zDc7ryPqNSx268+5NIc0 Okzr2XegY4F3WHp1D3p7lxzNKnTuPbcuybQSJVG/fse88dxYlgu5EDZKVIzCDwS6mskm xlwF0hQUwl3/270o9jahbXhkXMjMvB9o4lY3PSn1Bfi2+jkyI8x8qrQa1DRPnB3G40Fk +Ucy4VNeNJ+8jlxRgm/SDBK6ifMSJOvGMr6XTAfZRHQMUB7i7/LJmW3mzGAAoDLucQIP qZwOG3FQE1PGKjQPtrQ6I82KOJfVq0M7jtnr75ZFphQetb/tsn2M5SBgGE7fyfilrwy+ k+6w== MIME-Version: 1.0 Received: by 10.229.136.3 with SMTP id p3mr692200qct.8.1334835164513; Thu, 19 Apr 2012 04:32:44 -0700 (PDT) Received: by 10.229.123.197 with HTTP; Thu, 19 Apr 2012 04:32:44 -0700 (PDT) In-Reply-To: References: <20120419162541kawashimam@mail.jp.nec.com> Date: Thu, 19 Apr 2012 11:32:44 +0000 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=00248c70fe79d0872c04be068728 Cc: v6ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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, 19 Apr 2012 11:32:50 -0000 --00248c70fe79d0872c04be068728 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Remi, only what i have understood (sorry but i answer your mail to Masanobu but let me also verify my understanding). 2012/4/19 R=E9mi Despr=E9s > Masanobu, > > Please see comments in line. > > 2012-04-19 09:25, Masanobu Kawashima: > > > > > Hi Maoke, > > > > Thank you for explaining it so clearly. > > > >>> This point of the discussion is only about case 2 (Case 1 has two IPv= 6 > >>> prefixes per customer, something that AFAIK is claimed to be avoided = in > >>> case 2) > >> > >> i don't so understand what do you refer to with the "TWO ipv6 prefixes > PER > >> customer". do you mean the delegated prefix AND the one /64 for the > purpose > >> of 464xlat? if the delegated prefix is larger than /64, i think the > >> 464xlat-use prefix could be selected from this delegated prefix as a > >> more-specific (a /64), dedicated for 464xlat-use only. if the delegate= d > >> prefix is another /64, it is the case you mean 2 prefixes, right? > > > > Exactly. > > The text in section 7.5 about case 1 is: > "the CLAT will have a dedicated /64 via DHCPv6 prefix delegation [RFC3633= ] > or other means to source and receive IPv6 packets associated with the > [RFC6145] stateless translation of IPv4 packets to the local clients. If > the CLAT choose one /64 prefix for translation from delegated prefix, the= n > it SHOULD NOT be used for anything else." > > - In my understanding, this implies a /64 for 464XLAT, and another prefix > for native IPv6. > > - In a recent email, Cameron's answer about case 1 which, as I had said > "explicitly requires two IPv6 prefixes per CLAT node, a quite expensive > constraint" was "What is expensive? I think most network operators will > say IPv6 /64 subnets have no money value". This was AFAIK an implicit > acknowledgement that TWO prefixes were needed. (Sorry if I misinterpreted= .) > i think this part we are almost on the same floor. "the CLAT will have a dedicated /64 via DHCPv6 prefix delegation [RFC3633] or other means to source and receive IPv6 packets associated with the [RFC6145] stateless translation of IPv4 packets to the local clients." =3D>= a dedicated /64 only for the 464xlat-use; if there is another /64 for native IPv6-use only, then there are two prefixes. e.g., 2001:db8:1234:5678::/64 dedicated for a CLAT'x 464xlat use while another, 2001:db8:1234:5679::/64 for other purposes. "If the CLAT choose one /64 prefix for translation from delegated prefix, then it SHOULD NOT be used for anything else." =3D> "one /64" chosen "from delegated prefix" (surely the delegated prefix should be larger than /64 otherwise one cannot "choose" a /64 from it), then it (=3D> the /64 for 464xlat-use) should not be used for anything else (=3D> but only the 464xlat-use). in this case, you may call it *TWO* prefices or *ONE* prefix because they are able to aggregate, the delegated prefix. e.g., 2001:db8:1234:5670:/60 as the delegated prefix while 2001:db8:1234:5678::/64 is dedicated to 464xlat. i don't find any problem there and Cameron's answer is also qualified. if you certainly refer to these *TWO* prefices, then i think the question has been cleared. > > > >> for the case 2, to my understanding, it is not "claimed to be avoided" > but > >> another case of reality, where only the delegated prefix (one /64) is > >> assigned to the CLAT so that a dedicated /64 for 464xlat funtionality = is > >> not allowed. in this case, CLAT does NAT44 so that only one > IPv4-embedded > >> address is used for the purpose of 464xlat. it also does work. > > > > Exactly. > > First, please note that the approach of draft-02 for case 2, being new, > isn't one of those that were tested. > How it can work remains for me an open question. > > In order to understand what you mean, I just ask for a simple example > addressing plan, i.e., to be more precise: > (a) The operator NAT64 prefix > (b) The delegated /64 of an example CLAT-node > (c) The source address this CLAT uses when the IPv6 destination starts > with the NAT64 prefix. > i think there is not so much "being new", except the /96 being removed. taking the example from the authors' presentation in IETF83 (but let me replace the /96 with RFC6052 format) (a) 2001:db8:1234:0::/64. (b) 2001:db8:aaaa:0::/64. (c) as case 2, 2001:db8:aaaa:0:00c0:a801:0200::/128 (192.168.1.2 =3D 0xc0a80102) only is used for this CLAT 464xlat funtionality (private IPv4 addresses inside in the subnet served by CLAT is translated to 192.168.1.2 through NAT44 integrated in the CLAT.), while destination (when having access to 198.51.100.1 =3D 0xc6336401) will be 2001:db8:1234:0:00c6:3364:0100::. what is the concern? do you mean (a) and (b) are not *a* "unique NSP" (for the organization, in the context of RFC6052)? if this is the concern, i think the problem is you think the "organization" in the RFC6052 =3D "the operator", but here it is not the case. AFAIK, RFC6052 never states that. i understand here the CLAT holder and the PLAT owner are of the "organizations". > > Without this, I am lost. > > > >>> RFC6052 specifies addresses that start with a common prefix (WKP or > NSP) > >>> followed by IPv4 addresses. > >>> I don't see how this could be used to address customer nodes whose > >>> embedded addresses are RFC1918 addresses. > >> > >> i understand it is ok because 464xlat's PLAT performs stateful > translation > >> between the IPv6 address (with RFC1918 IPv4 embedded) and a global IPv= 4 > >> address in the pool that held by PLAT. > > > > You're right. > > > > > >> (btw, i don't think WKP is used in 464xlat for the CLAT and CLAT-serve= d > >> hosts. RFC6052 also has the restriction that RFC1918 addresses MUST NO= T > >> be used with WKP). is this understanding correct? > > See (**) below > > >> i think the case1/2 is > >> convining enough as a workabale addressing plan. > > Let's see the example addressing plan you can provide. > > > I also think that non-global IPv4 addresses must not be used with WKP. > > (**) > Well, not a matter of thinking: its written in RFC6052! > > =3D> Source addresses from CLATs, which are RFC6052 based in your proposa= l, > are indeed concerned with this rule. > But let's also no forget that destination addresses from CLATs contain > GLOBAL IPv4 addresses =3D> they aren't concerned. > they have been concerned, to my understanding. well, maybe source/destination is not accurate because the source CLAT will be the destination for the reply. anyway, we know what it is meaning. let me change the term as "remote peer" rather than "destination". for the remote peer address belonging to the outside IPv4 world, it should be attached with the PLAT 464xlat prefix, and section 7.5 has specified how CLAT know this information. on the other hand, because here it is the GLOBAL IPv4 address and therefore the restriction of not using WKP is not needed for this address (sure it is not necessary to RECOMMEND that we use WKP for the global IPv4 addresses of the remote peers, while neither i, for the time being, have found any reason of FORBID using it.) for both views on CLAT and PLAT, i think the current statement in v02 is enough. sure i do support the wording and phrasing should/could be refined further, with examples where it is needed. > > > My doubt that case 2 can work, as currently specified, is independent fro= m > what RFC6052 says on NSPs and RFC1918 addresses. > Only an example addressing plan, with its (a) (b) (c) above, can AFAIK > clarify the issue. > hope i have clarified it. if there is anything i made wrong, corrections and/or further questions are welcome. - maoke > > Regards, > RD > > > > > > > > > Regards, > > Masanobu > > > > > >> Remi, > >> > >> 2012/4/18 Remi Despres > >> > >>> Maoke, > >>> > >>> > >>> Le 2012-04-18 15:14, Maoke a rit : > >>> > >>> Remi, > >>> > >>> try to understand the question, as a learner. > >>> 2012/4/18 Remi Despres > >>> > >>>> Cameron, > >>>> > >>>> 2012-04-17 19:30, Cameron Byrne: > >>>> ... > >>>>>> (1) > >>>>>> Section 7.5 cites two IPv6 prefix-handling variants > >>>>>> > >>>>>> - The first one explicitly requires two IPv6 prefixes per CLAT > node, a > >>>> quite expensive constraint. > >>>>>> > >>>>> > >>>>> What is expensive? I think most network operators will say IPv6 /6= 4 > >>>>> subnets have no money value, and /64 subnets should be used where > ever > >>>>> it makes operational sense without constraint. > >>>> > >>>> OK, expensive may not be the best qualifier. > >>>> > >>>> OTOH, the need to delegate TWO IPv6 prefixes per customer, while the= re > >>>> exist solutions that work with the ordinary one-prefix-per-customer > >>>> practice, should by no means be called "Best Common Practice". > >>>> > >>>> I remain firm on that. > >>>> > >>>>>> - The second one is supposed to use only one prefix, but: > >>>>>> . Section 7.2 says that the CLAT IPv6 address, which is based on a > >>>> single IPv4 address due to an NAT44 in the CLAT node, is defined in > Section > >>>> 2.2 of RFC6052. > >>>>>> . Section 2.2 of RFC 6052 says "In these addresses, the prefix sha= ll > >>>> be either the "Well-Known Prefix" or a "Network-Specific Prefix" > unique to > >>>> the organization deploying the address translators." This cannot be > the > >>>> CLAT-node delegated prefix. > >>>>>> > >>>>> > >>>>> Why can this not be the CLAT node prefix? NSP of the home network. > >>>> > >>>> AFAIK, a single operator supports many CLATs > >>>> They cannot be reached at the NSP prefix which, by RFC6052, is > "unique to > >>>> the organization deploying the address translators" (i.e the > operator). > >>>> > >>> > >>> i understand it depends how we understand the word "organization" in > the > >>> RFC6052 context. it is not necessarily the "operator" (of the > >>> infrastructure or the autonomous system). exactly speaking, it is the > >>> aggregator. > >>> > >>> > >>> in the 464xlat sec 7.5 variant case 1, the NSP is the delegated prefi= x > >>> for, e.g., the home network; > >>> > >>> > >>> This point of the discussion is only about case 2 (Case 1 has two IPv= 6 > >>> prefixes per customer, something that AFAIK is claimed to be avoided = in > >>> case 2) > >>> > >> > >> i don't so understand what do you refer to with the "TWO ipv6 prefixes > PER > >> customer". do you mean the delegated prefix AND the one /64 for the > purpose > >> of 464xlat? if the delegated prefix is larger than /64, i think the > >> 464xlat-use prefix could be selected from this delegated prefix as a > >> more-specific (a /64), dedicated for 464xlat-use only. if the delegate= d > >> prefix is another /64, it is the case you mean 2 prefixes, right? > >> > >> for the case 2, to my understanding, it is not "claimed to be avoided" > but > >> another case of reality, where only the delegated prefix (one /64) is > >> assigned to the CLAT so that a dedicated /64 for 464xlat funtionality = is > >> not allowed. in this case, CLAT does NAT44 so that only one > IPv4-embedded > >> address is used for the purpose of 464xlat. it also does work. > >> > >> do i miss anything? > >> > >> > >>> > >>> in the case 2, as the CLAT has not a dedicated IPv6 prefix, > >>> > >>> > >>> Not understood. > >>> (It could be taken as meaning that CLAT nodes might have no IPv6 > delegated > >>> prefixes.) > >>> > >>> > >>> the aggregator is the higher level entity (operator or suboperator). = in > >>> either case, single operator supporting many CLATs, AFAIK, is not a > problem > >>> according to the 464xlat text. the "unique" in the context of RFC6052 > is > >>> not a restriction, i think. > >>> > >>> if my understanding is not correct, please don't hesitate to point ou= t. > >>> thanks! > >>> > >>> > >>> RFC6052 specifies addresses that start with a common prefix (WKP or > NSP) > >>> followed by IPv4 addresses. > >>> I don't see how this could be used to address customer nodes whose > >>> embedded addresses are RFC1918 addresses. > >>> > >> > >> i understand it is ok because 464xlat's PLAT performs stateful > translation > >> between the IPv6 address (with RFC1918 IPv4 embedded) and a global IPv= 4 > >> address in the pool that held by PLAT. (btw, i don't think WKP is used > in > >> 464xlat for the CLAT and CLAT-served hosts. RFC6052 also has the > >> restriction that RFC1918 addresses MUST NOT be used with WKP). is this > >> understanding correct? i think the case1/2 is convining enough as a > >> workabale addressing plan. > >> > >> - maoke > >> > >> > >>> > >>> Seeing a workable addressing plan for case 2 is for me a prerequisite > to > >>> eliminate this doubt. > >>> > >> > >>> RD > >>> > >>> > >>> > >>> > >>> > >>> - maoke > >>> > >>> > >>>> > >>>>>> In my understanding, this second option cannot work. > >>>>>> If I missed something, thank you for explaining. > >>>>>> > >>>>>> (2) > >>>>>> Coming back to the relationship with BIH: > >>>>>> - We now know there is open-source running code for BIH. > >>>>> > >>>>> Same as 464XLAT draft > >>>> > >>>> Right =3D> not a decision criterion. > >>>> > >>>>>> - With BIH, a single IPv6 prefix per customer node is sufficient i= n > >>>> customer nodes. > >>>>> > >>>>> Same as defined is this 464XLAT draft > >>>> > >>>> BIH can readily be used on any ISPv6 network having a NAT64 > accessible at > >>>> its well known prefix 64:ff9b::/96. > >>>> This isn't the case with the proposed 464XLAT design (see above). > >>>> > >>>>>> - IPv4-only hosts, if behind BIH-capable CPEs, have connectivity > with > >>>> servers that, because they are also in customer sites of IPv6-only > >>>> networks, can have AAAA records but no A records in the DNS. > >>>>>> > >>>>> > >>>>> Brian, Lorenzo, Gert, and myself, and the market (there is no > >>>>> meaningful market for IPv6-only services on the internet) say this = is > >>>>> not a value add. > >>>> > >>>> When discussing whether a new market exists, those who explain where > they > >>>> see it are in general more relevant than those who, having not seen > it > >>>> yet, negate that it can exist. > >>>> > >>>> In any case, advantages of BIH for the 464XLAT scenario go beyond BI= H > >>>> applicability to IPv4-only hosts reaching servers attached to > IPv6-only > >>>> networks. > >>>> > >>>> Regards, > >>>> RD > >>>> > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> v6ops mailing list > >>>> v6ops@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/v6ops > >>>> > >>> > >>> > >>> > >> > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > NEC AccessTechnica, Ltd. > > Product Development Department > > Masanobu Kawashima > > kawashimam@vx.jp.nec.com > > http://www.necat.co.jp/ > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > --00248c70fe79d0872c04be068728 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Remi,=A0

only what i have understood (sorry b= ut i answer your mail to Masanobu but let me also verify my understanding).= =A0

2012/4/19 R=E9mi Despr= =E9s <despres.remi@laposte.net>
Masanobu,

Please see comments in line.

2012-04-19 09:25, Masanobu Kawashima:

>
> Hi Maoke,
>
> Thank you for explaining it so clearly.
>
>>> This point of the discussion is only about case 2 (Case 1 has = two IPv6
>>> prefixes per customer, something that AFAIK is claimed to be a= voided in
>>> case 2)
>>
>> i don't so understand what do you refer to with the "TWO = ipv6 prefixes PER
>> customer". do you mean the delegated prefix AND the one /64 f= or the purpose
>> of 464xlat? if the delegated prefix is larger than /64, i think th= e
>> 464xlat-use prefix could be selected from this delegated prefix as= a
>> more-specific (a /64), dedicated for 464xlat-use only. if the dele= gated
>> prefix is another /64, it is the case you mean 2 prefixes, right?<= br> >
> Exactly.

The text in section 7.5 about case 1 is:
"the CLAT will have a dedicated /64 via DHCPv6 prefix delegation [RFC3= 633] or other means to source and receive IPv6 packets associated with the = [RFC6145] stateless translation of IPv4 packets to the local clients. =A0If= the CLAT choose one /64 prefix for translation from delegated prefix, then= it SHOULD NOT be used for anything else."

- In my understanding, this implies a /64 for 464XLAT, and another prefix f= or native IPv6.

- In a recent email, Cameron's answer about case 1 which, as I had said= =A0"explicitly requires two IPv6 prefixes per CLAT node, a quite expe= nsive constraint" was "What is expensive? =A0I think most network= operators will say IPv6 /64 subnets have no money value". This was AF= AIK an implicit acknowledgement that TWO prefixes were needed. (Sorry if I = misinterpreted.)

i think this part we are almost on the sam= e floor.=A0

"the CLAT will have a dedicated /= 64 via DHCPv6 prefix delegation [RFC3633] or other means to source and rece= ive IPv6 packets associated with the [RFC6145] stateless translation of IPv= 4 packets to the local clients." =3D> a dedicated /64 only for the = 464xlat-use; if there is another /64 for native IPv6-use only, then there a= re two prefixes. e.g., 2001:db8:1234:5678::/64 dedicated for a CLAT'x 4= 64xlat use while another, 2001:db8:1234:5679::/64 for other purposes.=A0

"If the CLAT choose one /64 prefix for translation= from delegated prefix, then it SHOULD NOT be used for anything else."= =3D> "one /64" chosen "from delegated prefix" (sure= ly the delegated prefix should be larger than /64 otherwise one cannot &quo= t;choose" a /64 from it), then it (=3D> the /64 for 464xlat-use) sh= ould not be used for anything else (=3D> but only the 464xlat-use). in t= his case, you may call it *TWO* prefices or *ONE* prefix because they are a= ble to aggregate, the delegated prefix. e.g., 2001:db8:1234:5670:/60 as the= delegated prefix while 2001:db8:1234:5678::/64 is dedicated to 464xlat.=A0=

i don't find any problem there and Cameron's an= swer is also qualified. if you certainly refer to these *TWO* prefices, the= n i think the question has been cleared.=A0
=A0


>> for the case 2, to my understanding, it is not "claimed to be= avoided" but
>> another case of reality, where only the delegated prefix (one /64)= is
>> assigned to the CLAT so that a dedicated /64 for 464xlat funtional= ity is
>> not allowed. in this case, CLAT does NAT44 so that only one IPv4-e= mbedded
>> address is used for the purpose of 464xlat. it also does work.
>
> Exactly.

First, please note that the approach of draft-02 for case 2, being ne= w, isn't one of those that were tested.
How it can work remains for me an open question.

In order to understand what you mean, I just ask for a simple example addre= ssing plan, i.e., to be more precise:
(a) The operator NAT64 prefix
(b) The delegated /64 of an example CLAT-node
(c) The source address this CLAT uses when the IPv6 destination starts with= the NAT64 prefix.

i think there is not= so much "being new", except the /96 being removed. taking the ex= ample from the authors' presentation in IETF83 (but let me replace the = /96 with RFC6052 format)
(a) 2001:db8:1234:0::/64.
(b) 2001:db8:aaaa:0::/64.=A0
=
(c) as case 2, 2001:db8:aaaa:0:00c0:a801:0200::/128 (192.168.1.2 =3D 0= xc0a80102) only is used for this CLAT 464xlat funtionality (private IPv4 ad= dresses inside in the subnet served by CLAT is translated to 192.168.1.2 th= rough NAT44 integrated in the CLAT.), while destination (when having access= to 198.51.100.1 =3D 0xc6336401) will be 2001:db8:1234:0:00c6:3364:0100::.= =A0

what is the concern? do you mean (a) and (b) are not *a= * "unique NSP" (for the organization, in the context of RFC6052)?= if this is the concern, i think the problem is you think the "organiz= ation" in the RFC6052 =3D "the operator", but here it is not= the case. AFAIK, RFC6052 never states that. i understand here the CLAT hol= der and the PLAT owner are of the "organizations".=A0
=A0

Without this, I am lost.


>>> RFC6052 specifies addresses that start with a common prefix (W= KP or NSP)
>>> followed by IPv4 addresses.
>>> I don't see how this could be used to address customer nod= es whose
>>> embedded addresses are RFC1918 addresses.
>>
>> i understand it is ok because 464xlat's PLAT performs stateful= translation
>> between the IPv6 address (with RFC1918 IPv4 embedded) and a global= IPv4
>> address in the pool that held by PLAT.
>
> You're right.
>
>
>> (btw, i don't think WKP is used in 464xlat for the CLAT and CL= AT-served
>> hosts. RFC6052 also has the restriction that RFC1918 addresses MUS= T NOT
>> be used with WKP). is this understanding correct?

See (**) below

>> i think the case1/2 is
>> convining enough as a workabale addressing plan.

Let's see the example addressing plan you can provide.

> I also think that non-global IPv4 addresses must not be used with WKP.=

(**)
Well, not a matter of thinking: its written in RFC6052!

=3D> Source addresses from CLATs, which are RFC6052 based in your propos= al, are indeed concerned with this rule.
But let's also no forget that destination addresses from CLATs contain = GLOBAL IPv4 addresses =3D> they aren't concerned.

they have been concerned, to my understanding. well, mayb= e source/destination is not accurate because the source CLAT will be the de= stination for the reply. anyway, we know what it is meaning. let me change = the term as "remote peer" rather than "destination".=A0=

for the remote peer address belonging to the outside IP= v4 world, it should be attached with the PLAT 464xlat prefix, and section 7= .5 has specified how CLAT know this information. on the other hand, because= here it is the GLOBAL IPv4 address and therefore the restriction of not us= ing WKP is not needed for this address (sure it is not necessary to RECOMME= ND that we use WKP for the global IPv4 addresses of the remote peers, while= neither i, for the time being, have found any reason of FORBID using it.)<= /div>

for both views on CLAT and PLAT, i think the current st= atement in v02 is enough. sure i do support the wording and phrasing should= /could be refined further, with examples where it is needed.=A0
=A0


My doubt that case 2 can work, as currently specified, is independent from = what RFC6052 says on NSPs and RFC1918 addresses.
Only an example addressing plan, with its (a) (b) (c) above, can AFAIK clar= ify the issue.

hope i have clarified it= . if there is anything i made wrong, corrections and/or further questions a= re welcome.=A0

- maoke
=A0

Regards,
RD





>
> Regards,
> Masanobu
>
>
>> Remi,
>>
>> 2012/4/18 Remi Despres <despres.remi@laposte.net>
>>
>>> Maoke,
>>>
>>>
>>> Le 2012-04-18 15:14, Maoke a rit :
>>>
>>> Remi,
>>>
>>> try to understand the question, as a learner.
>>> 2012/4/18 Remi Despres <despres.remi@laposte.net>
>>>
>>>> Cameron,
>>>>
>>>> 2012-04-17 19:30, Cameron Byrne:
>>>> ...
>>>>>> (1)
>>>>>> Section 7.5 cites two IPv6 prefix-handling variant= s
>>>>>>
>>>>>> - The first one explicitly requires two IPv6 prefi= xes per CLAT node, a
>>>> quite expensive constraint.
>>>>>>
>>>>>
>>>>> What is expensive? =A0I think most network operators w= ill say IPv6 /64
>>>>> subnets have no money value, and /64 subnets should be= used where ever
>>>>> it makes operational sense without constraint.
>>>>
>>>> OK, expensive may not be the best qualifier.
>>>>
>>>> OTOH, the need to delegate TWO IPv6 prefixes per customer,= while there
>>>> exist solutions that work with the ordinary one-prefix-per= -customer
>>>> practice, should by no means be called "Best Common P= ractice".
>>>>
>>>> I remain firm on that.
>>>>
>>>>>> - The second one is supposed to use only one prefi= x, but:
>>>>>> . Section 7.2 says that the CLAT IPv6 address, whi= ch is based on a
>>>> single IPv4 address due to an NAT44 in the CLAT node, is d= efined in Section
>>>> 2.2 of RFC6052.
>>>>>> . Section 2.2 of RFC 6052 says "In these addr= esses, the prefix shall
>>>> be either the "Well-Known Prefix" or a "Net= work-Specific Prefix" unique to
>>>> the organization deploying the address translators." = This cannot be the
>>>> CLAT-node delegated prefix.
>>>>>>
>>>>>
>>>>> Why can this not be the CLAT node prefix? =A0NSP of th= e home network.
>>>>
>>>> AFAIK, a single operator supports many CLATs
>>>> They cannot be reached at the NSP prefix which, by RFC6052= , is "unique to
>>>> the organization deploying the address translators" (= i.e the operator).
>>>>
>>>
>>> i understand it depends how we understand the word "organ= ization" in the
>>> RFC6052 context. it is not necessarily the "operator"= ; (of the
>>> infrastructure or the autonomous system). exactly speaking, it= is the
>>> aggregator.
>>>
>>>
>>> in the 464xlat sec 7.5 variant case 1, the NSP is the delegate= d prefix
>>> for, e.g., the home network;
>>>
>>>
>>> This point of the discussion is only about case 2 (Case 1 has = two IPv6
>>> prefixes per customer, something that AFAIK is claimed to be a= voided in
>>> case 2)
>>>
>>
>> i don't so understand what do you refer to with the "TWO = ipv6 prefixes PER
>> customer". do you mean the delegated prefix AND the one /64 f= or the purpose
>> of 464xlat? if the delegated prefix is larger than /64, i think th= e
>> 464xlat-use prefix could be selected from this delegated prefix as= a
>> more-specific (a /64), dedicated for 464xlat-use only. if the dele= gated
>> prefix is another /64, it is the case you mean 2 prefixes, right?<= br> >>
>> for the case 2, to my understanding, it is not "claimed to be= avoided" but
>> another case of reality, where only the delegated prefix (one /64)= is
>> assigned to the CLAT so that a dedicated /64 for 464xlat funtional= ity is
>> not allowed. in this case, CLAT does NAT44 so that only one IPv4-e= mbedded
>> address is used for the purpose of 464xlat. it also does work.
>>
>> do i miss anything?
>>
>>
>>>
>>> in the case 2, as the CLAT has not a dedicated IPv6 prefix, >>>
>>>
>>> Not understood.
>>> (It could be taken as meaning that CLAT nodes might have no IP= v6 delegated
>>> prefixes.)
>>>
>>>
>>> the aggregator is the higher level entity (operator or suboper= ator). in
>>> either case, single operator supporting many CLATs, AFAIK, is = not a problem
>>> according to the 464xlat text. the "unique" in the c= ontext of RFC6052 is
>>> not a restriction, i think.
>>>
>>> if my understanding is not correct, please don't hesitate = to point out.
>>> thanks!
>>>
>>>
>>> RFC6052 specifies addresses that start with a common prefix (W= KP or NSP)
>>> followed by IPv4 addresses.
>>> I don't see how this could be used to address customer nod= es whose
>>> embedded addresses are RFC1918 addresses.
>>>
>>
>> i understand it is ok because 464xlat's PLAT performs stateful= translation
>> between the IPv6 address (with RFC1918 IPv4 embedded) and a global= IPv4
>> address in the pool that held by PLAT. (btw, i don't think WKP= is used in
>> 464xlat for the CLAT and CLAT-served hosts. RFC6052 also has the >> restriction that RFC1918 addresses MUST NOT be used with WKP). is = this
>> understanding correct? i think the case1/2 is convining enough as = a
>> workabale addressing plan.
>>
>> - maoke
>>
>>
>>>
>>> Seeing a workable addressing plan for case 2 is for me a prere= quisite to
>>> eliminate this doubt.
>>>
>>
>>> RD
>>>
>>>
>>>
>>>
>>>
>>> - maoke
>>>
>>>
>>>>
>>>>>> In my understanding, this second option cannot =A0= work.
>>>>>> If I missed something, thank you for explaining. >>>>>>
>>>>>> (2)
>>>>>> Coming back to the relationship with BIH:
>>>>>> - We now know there is open-source running code fo= r BIH.
>>>>>
>>>>> Same as 464XLAT draft
>>>>
>>>> Right =3D> not a decision criterion.
>>>>
>>>>>> - With BIH, a single IPv6 prefix per customer node= is sufficient in
>>>> customer nodes.
>>>>>
>>>>> Same as defined is this 464XLAT draft
>>>>
>>>> BIH can readily be used on any ISPv6 network having a NAT6= 4 accessible at
>>>> its well known prefix 64:ff9b::/96.
>>>> This isn't the case with the proposed 464XLAT design (= see above).
>>>>
>>>>>> - IPv4-only hosts, if behind BIH-capable CPEs, hav= e connectivity with
>>>> servers that, because they are also in customer sites of I= Pv6-only
>>>> networks, can have AAAA records but no A records in the DN= S.
>>>>>>
>>>>>
>>>>> Brian, Lorenzo, Gert, and myself, and the market (ther= e is no
>>>>> meaningful market for IPv6-only services on the intern= et) say this is
>>>>> not a value add.
>>>>
>>>> When discussing whether a new market exists, those who exp= lain where they
>>>> see it are in general more relevant than those who, =A0hav= ing not seen it
>>>> yet, negate that it can exist.
>>>>
>>>> In any case, advantages of BIH for the 464XLAT scenario go= beyond BIH
>>>> applicability to IPv4-only hosts reaching servers attached= to IPv6-only
>>>> networks.
>>>>
>>>> Regards,
>>>> RD
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> v6ops mailing list
>>>> v6ops@= ietf.org
>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>>
>>>
>>>
>>>
>>
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> NEC AccessTechnica, Ltd.
> Product Development Department
> Masanobu Kawashima
> kawashim= am@vx.jp.nec.com
> http://www.necat= .co.jp/
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>


--00248c70fe79d0872c04be068728-- From fred@cisco.com Thu Apr 19 05:45:05 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1945D21F85CF for ; Thu, 19 Apr 2012 05:45:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Shj2YSA-QndL for ; Thu, 19 Apr 2012 05:45:00 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id CA97321F85C4 for ; Thu, 19 Apr 2012 05:45:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=131; q=dns/txt; s=iport; t=1334839500; x=1336049100; h=date:from:message-id:to:subject:cc; bh=71QyEj/OPOop6hI7lXBwGFBPi5/cq0LXvEVVwhKU6Z0=; b=fkIsnpIfwqUTmvnwBJ2SCh5IVyzmG4qfTMqYrtMsCJjLMDbR5Mt+z45j 23343OPEJjoyUtDaLc6dUbdNRmooHsM0DW20jSNWfAkN+o2sxvPejLKS8 UommtGgCqNGW65oJDBd8pBfwfHv6gVAmgjN+wXki83RnxcQ7Rt9iUGCBI 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnoHAIIHkE+rRDoJ/2dsb2JhbABDoBMBkS2BB4IiAWY8LYEKh2wMmhegPo0YgyUEiFyOJY1AgWmDBw X-IronPort-AV: E=Sophos;i="4.75,446,1330905600"; d="scan'208";a="38139231" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 19 Apr 2012 12:45:00 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q3JCj0h5009847; Thu, 19 Apr 2012 12:45:00 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id q3JCj0q26592; Thu, 19 Apr 2012 05:45:00 -0700 (PDT) Date: Thu, 19 Apr 2012 05:45:00 -0700 (PDT) From: Message-Id: <201204191245.q3JCj0q26592@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-ietf-v6ops-icp-guidance@tools.ietf.org Subject: [v6ops] new draft: draft-ietf-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, 19 Apr 2012 12:45:05 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-ietf-v6ops-icp-guidance. Please take a look at it and comment. From despres.remi@laposte.net Thu Apr 19 06:29:06 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48F4421F860E for ; Thu, 19 Apr 2012 06:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.157 X-Spam-Level: X-Spam-Status: No, score=-2.157 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SCnBiA2E072G for ; Thu, 19 Apr 2012 06:29:05 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 7623521F860B for ; Thu, 19 Apr 2012 06:29:03 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id DE40A94007C; Thu, 19 Apr 2012 15:28:52 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-44-52646090 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Thu, 19 Apr 2012 15:28:51 +0200 Message-Id: <13E111C2-BA64-4EF9-B29D-8F0719B925ED@laposte.net> References: <20120419162541kawashimam@mail.jp.nec.com> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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, 19 Apr 2012 13:29:06 -0000 --Apple-Mail-44-52646090 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 2012-04-19 13:32, Maoke: ... > if you certainly refer to these *TWO* prefices, then i think the = question has been cleared. If we agree that sec.7.5 case 1 requires two delegated prefixes per = customer, yes, this question cleared.=20 > >> for the case 2, to my understanding, it is not "claimed to be = avoided" but > >> another case of reality, where only the delegated prefix (one /64) = is > >> assigned to the CLAT so that a dedicated /64 for 464xlat = funtionality is > >> not allowed. in this case, CLAT does NAT44 so that only one = IPv4-embedded > >> address is used for the purpose of 464xlat. it also does work. > > > > Exactly. >=20 > First, please note that the approach of draft-02 for case 2, being = new, isn't one of those that were tested. > How it can work remains for me an open question. >=20 > In order to understand what you mean, I just ask for a simple example = addressing plan, i.e., to be more precise: > (a) The operator NAT64 prefix > (b) The delegated /64 of an example CLAT-node > (c) The source address this CLAT uses when the IPv6 destination starts = with the NAT64 prefix. >=20 > i think there is not so much "being new", except the /96 being = removed. taking the example from the authors' presentation in IETF83 = (but let me replace the /96 with RFC6052 format) > (a) 2001:db8:1234:0::/64. > (b) 2001:db8:aaaa:0::/64.=20 > (c) as case 2, 2001:db8:aaaa:0:00c0:a801:0200::/128 (192.168.1.2 =3D = 0xc0a80102) only is used for this CLAT 464xlat funtionality (private = IPv4 addresses inside in the subnet served by CLAT is translated to = 192.168.1.2 through NAT44 integrated in the CLAT.), while destination = (when having access to 198.51.100.1 =3D 0xc6336401) will be = 2001:db8:1234:0:00c6:3364:0100::.=20 Thanks for providing this example. As expected, it does clarify what you mean. With this understanding, I will try to make constructive suggestions on = how to progress. Thanks, RD --Apple-Mail-44-52646090 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
2012-04-19  13:32, Maoke:

...
 if you certainly refer to these *TWO* prefices, then i think the question has been cleared.

If we agree that sec.7.5 case 1 requires two delegated prefixes per customer, yes, this question cleared. 


>> for the case 2, to my understanding, it is not "claimed to be avoided" but
>> another case of reality, where only the delegated prefix (one /64) is
>> assigned to the CLAT so that a dedicated /64 for 464xlat funtionality is
>> not allowed. in this case, CLAT does NAT44 so that only one IPv4-embedded
>> address is used for the purpose of 464xlat. it also does work.
>
> Exactly.

First, please note that the approach of draft-02 for case 2, being new, isn't one of those that were tested.
How it can work remains for me an open question.

In order to understand what you mean, I just ask for a simple example addressing plan, i.e., to be more precise:
(a) The operator NAT64 prefix
(b) The delegated /64 of an example CLAT-node
(c) The source address this CLAT uses when the IPv6 destination starts with the NAT64 prefix.

i think there is not so much "being new", except the /96 being removed. taking the example from the authors' presentation in IETF83 (but let me replace the /96 with RFC6052 format)
(a) 2001:db8:1234:0::/64.
(b) 2001:db8:aaaa:0::/64. 
(c) as case 2, 2001:db8:aaaa:0:00c0:a801:0200::/128 (192.168.1.2 = 0xc0a80102) only is used for this CLAT 464xlat funtionality (private IPv4 addresses inside in the subnet served by CLAT is translated to 192.168.1.2 through NAT44 integrated in the CLAT.), while destination (when having access to 198.51.100.1 = 0xc6336401) will be 2001:db8:1234:0:00c6:3364:0100::. 

Thanks for providing this example.
As expected, it does clarify what you mean.
With this understanding, I will try to make constructive suggestions on how to progress.

Thanks,
RD



--Apple-Mail-44-52646090-- From despres.remi@laposte.net Thu Apr 19 07:37:47 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6D821F864B for ; Thu, 19 Apr 2012 07:37:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.164 X-Spam-Level: X-Spam-Status: No, score=-2.164 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3CP+h7Rwks8o for ; Thu, 19 Apr 2012 07:37:46 -0700 (PDT) Received: from smtpout.laposte.net (smtpout5.laposte.net [193.253.67.230]) by ietfa.amsl.com (Postfix) with ESMTP id D2E6121F85D0 for ; Thu, 19 Apr 2012 07:37:37 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8509-out with ME id zqdY1i00937Y3f403qdYMV; Thu, 19 Apr 2012 16:37:35 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <20120417160010kawashimam@mail.jp.nec.com> Date: Thu, 19 Apr 2012 16:37:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <56E2AD61-1C91-4889-914A-353793FCBE43@laposte.net> References: <20120417065542.31115.95082.idtracker@ietfa.amsl.com> <20120417160010kawashimam@mail.jp.nec.com> To: Masanobu Kawashima , Masataka Mawatari , Cameron Byrne X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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, 19 Apr 2012 14:37:47 -0000 Masanobu, Masataka, Cameron, After clarifications exchanged on the ML, both about 464XLAT and about = an available BIH implementation, here is a proposal which, if accepted, = would normally lead me to support a 4X4XLAT BCP: (a) Only describe the solution where a single IPv6 prefix per CLAT node = is enough (i.e. case 2 of Section 7.5, with NAT44 in the node) (b) Add support of CLAT prefixes shorter than /64 (c) Concerning the IPv6 address used in a CLAT node to reach the CLAT, = mention two approaches: - c1 (roughly that of the current case 2): use a RFC6052-based 464XLAT = specific address, based on a locally defined NSP (equal to or starting = with the CLAT-node IPv6 prefix), and embedding the RFC1918 address = chosen as NAT44 external address. For this approach, make clear that, on = the LAN side, two IPv6 addresses need to be excluded instead of one in = absence of 464XLAT support. - c2 (no 464XLAT-specific IPv6 address needed): All CLAT-node incoming = packets coming from the NAT64 (i.e. whose source addresses start with = the NAT64 prefix) are addressed to the NAT44, and all CLAT outgoing = packets have the native IPv6 address of the WAN interface. (d) Explicitly permit the NAT64 prefix to be the NAT64 WKP. (e) Mention that a superset of the CLAT behavior is available in RFC6535 = for nodes supporting the network-layer BIH with a NAT44, the difference = being that, in addition, RFC6535 supports connectivity of IPv4-only = hosts, or applications, with servers whose only public addresses are = IPv6.=20 (f) For clarification, replace "PLAT" by "NAT64" (AFAIK identical, and = already defined). Questions and comments are welcome. The above, made after a serious technical debate for which I thank all = those who participated, will hopefully be taken for what it is: a = constructive contribution to improve an interesting proposal. Kind regards, RD Le 2012-04-17 =E0 09:00, Masanobu Kawashima a =E9crit : >=20 > Folks, >=20 > We have published draft-ietf-v6ops-464xlat-02. >=20 > Changes are: >=20 > - Changed document category from Informational to BCP > - A normative language(RFC2119) has reinserted. > - We did not see any strong opposition on this list except Remi. > As Cameron and Lorenzo said, we should not treat as a use case > for BIH. Remi's some concerns were fixed by this version as below. > If you have any strong opposition, please indicate it. >=20 > - Section 7.1. IPv6 Address Format > - Replaced all text with this one sentence "IPv6 address format > in 464XLAT is defined in Section 2.2 of [RFC6052]" >=20 > - Section 7.2. IPv4/IPv6 address translation chart > - Removed all references to /96 > - Added case of "CLAT with NAT44" >=20 > - Section 7.4. DNS Proxy Implementation > - Added a reference to RFC5625 >=20 > - Section 7.5. IPv6 Prefix Handling > - Removed all references to /96 > - Added a reference to RFC3633 >=20 > All comments are welcome. >=20 > Regards, > Masanobu >=20 From fibrib@gmail.com Thu Apr 19 08:47:49 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7E4A21F86A1 for ; Thu, 19 Apr 2012 08:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.89 X-Spam-Level: X-Spam-Status: No, score=-2.89 tagged_above=-999 required=5 tests=[AWL=-0.192, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o0vkBGyoooIN for ; Thu, 19 Apr 2012 08:47:45 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2ADBE21F861D for ; Thu, 19 Apr 2012 08:47:45 -0700 (PDT) Received: by qcsq13 with SMTP id q13so6413786qcs.31 for ; Thu, 19 Apr 2012 08:47:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WSnXPdy0wfjT8Y18lIsKHQbGFfzwTAU7acq4tHcUcx8=; b=cNX+14iRK7GMb3Ew83h497VJNtc5sS6p4icddFgPHU//2rJh25WgCk9aLzwfK9cohF s4yeMJ4pdy22Um0yLKI96Axr7APIr2GphjiagFhMdmcp7rNPp+EVobihzRbNdvNItVGf 5V1Xl9Wo4Ll8yiIdlVDdUku6AFXohJA93iPRTYwLu/rde57/4YBuI1Qva0gNwXU3nU1F 0PisnHTlaYjW5Hqf8uBu2Ba7hErfYDnd5EdaHbJ99UwAbuLHDlAO9+K1ErpsxrgoZeYX VRc0x/4TSohNEsRqGj5+Ch+WIDOMSktd5QMmbfrPWpr+p5JmmlVJITqn4XJccerhlQYH Sbxw== MIME-Version: 1.0 Received: by 10.224.116.5 with SMTP id k5mr3751540qaq.19.1334850464649; Thu, 19 Apr 2012 08:47:44 -0700 (PDT) Received: by 10.229.123.197 with HTTP; Thu, 19 Apr 2012 08:47:44 -0700 (PDT) In-Reply-To: <56E2AD61-1C91-4889-914A-353793FCBE43@laposte.net> References: <20120417065542.31115.95082.idtracker@ietfa.amsl.com> <20120417160010kawashimam@mail.jp.nec.com> <56E2AD61-1C91-4889-914A-353793FCBE43@laposte.net> Date: Fri, 20 Apr 2012 00:47:44 +0900 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=20cf3074d21ec6115704be0a175a Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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, 19 Apr 2012 15:47:50 -0000 --20cf3074d21ec6115704be0a175a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hi Remi and the authors, as an observer, 1) i don't think (f) is needed (NAT64 is the function while PLAT is a building block of this specific architecture); 2) i don't think (e) is necessary as 464xlat and BIH are in different scopes, with different environment of deployment. i don't think one could be said as a superset of another. only personal point of view. thanks, maoke 2012/4/19 R=E9mi Despr=E9s > Masanobu, Masataka, Cameron, > > After clarifications exchanged on the ML, both about 464XLAT and about an > available BIH implementation, here is a proposal which, if accepted, woul= d > normally lead me to support a 4X4XLAT BCP: > > (a) Only describe the solution where a single IPv6 prefix per CLAT node i= s > enough (i.e. case 2 of Section 7.5, with NAT44 in the node) > > (b) Add support of CLAT prefixes shorter than /64 > > (c) Concerning the IPv6 address used in a CLAT node to reach the CLAT, > mention two approaches: > - c1 (roughly that of the current case 2): use a RFC6052-based 464XLAT > specific address, based on a locally defined NSP (equal to or starting wi= th > the CLAT-node IPv6 prefix), and embedding the RFC1918 address chosen as > NAT44 external address. For this approach, make clear that, on the LAN > side, two IPv6 addresses need to be excluded instead of one in absence of > 464XLAT support. > - c2 (no 464XLAT-specific IPv6 address needed): All CLAT-node incoming > packets coming from the NAT64 (i.e. whose source addresses start with the > NAT64 prefix) are addressed to the NAT44, and all CLAT outgoing packets > have the native IPv6 address of the WAN interface. > > (d) Explicitly permit the NAT64 prefix to be the NAT64 WKP. > > (e) Mention that a superset of the CLAT behavior is available in RFC6535 > for nodes supporting the network-layer BIH with a NAT44, the difference > being that, in addition, RFC6535 supports connectivity of IPv4-only hosts= , > or applications, with servers whose only public addresses are IPv6. > > (f) For clarification, replace "PLAT" by "NAT64" (AFAIK identical, and > already defined). > > Questions and comments are welcome. > > The above, made after a serious technical debate for which I thank all > those who participated, will hopefully be taken for what it is: a > constructive contribution to improve an interesting proposal. > > Kind regards, > RD > > > > > Le 2012-04-17 =E0 09:00, Masanobu Kawashima a =E9crit : > > > > > Folks, > > > > We have published draft-ietf-v6ops-464xlat-02. > > > > Changes are: > > > > - Changed document category from Informational to BCP > > - A normative language(RFC2119) has reinserted. > > - We did not see any strong opposition on this list except Remi. > > As Cameron and Lorenzo said, we should not treat as a use case > > for BIH. Remi's some concerns were fixed by this version as below. > > If you have any strong opposition, please indicate it. > > > > - Section 7.1. IPv6 Address Format > > - Replaced all text with this one sentence "IPv6 address format > > in 464XLAT is defined in Section 2.2 of [RFC6052]" > > > > - Section 7.2. IPv4/IPv6 address translation chart > > - Removed all references to /96 > > - Added case of "CLAT with NAT44" > > > > - Section 7.4. DNS Proxy Implementation > > - Added a reference to RFC5625 > > > > - Section 7.5. IPv6 Prefix Handling > > - Removed all references to /96 > > - Added a reference to RFC3633 > > > > All comments are welcome. > > > > Regards, > > Masanobu > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --20cf3074d21ec6115704be0a175a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
hi Remi and the authors,
=A0
as an observer, 1)=A0= i don't think (f) is needed (NAT64 is the function while PLAT is a buil= ding block of this specific architecture); 2) i don't think (e) is nece= ssary as 464xlat and BIH are in different scopes, with different environmen= t of deployment. i don't think one could be said as a superset of anoth= er. only personal point of view.
=A0
thanks,
maoke
2012/4/19 R=E9mi Despr=E9s <despres.remi@laposte.net>
Masanobu, Masataka, Cameron,

After clarifications exchanged on the ML, both about 464XLAT and about an a= vailable BIH implementation, here is a proposal which, if accepted, would n= ormally lead me to support a 4X4XLAT BCP:

(a) Only describe the solution where a single IPv6 prefix per CLAT node is = enough (i.e. case 2 of Section 7.5, with NAT44 in the node)

(b) Add support of CLAT prefixes shorter than /64

(c) Concerning the IPv6 address used in a CLAT node to reach the CLAT, ment= ion two approaches:
- c1 (roughly that of the current case 2): use a RFC6052-based 464XLAT spec= ific address, based on a locally defined NSP (equal to or starting with the= CLAT-node IPv6 prefix), and embedding the RFC1918 address chosen as NAT44 = external address. For this approach, make clear that, on the LAN side, two = IPv6 addresses need to be excluded instead of one in absence of 464XLAT sup= port.
- c2 (no 464XLAT-specific IPv6 address needed): All CLAT-node incoming pack= ets coming from the NAT64 (i.e. whose source addresses start with the NAT64= prefix) are addressed to the NAT44, and all CLAT outgoing packets have the= native IPv6 address of the WAN interface.

(d) Explicitly permit the NAT64 prefix to be the NAT64 WKP.

(e) Mention that a superset of the CLAT behavior is available in RFC6535 fo= r nodes supporting the network-layer BIH with a NAT44, the difference being= that, in addition, RFC6535 supports connectivity of IPv4-only hosts, or ap= plications, with servers whose only public addresses are IPv6.

(f) For clarification, replace "PLAT" by "NAT64" (AFAIK= identical, and already defined).

Questions and comments are welcome.

The above, made after a serious technical debate for which I thank all thos= e who participated, will hopefully be taken for what it is: a constructive = contribution to improve an interesting proposal.

Kind regards,
RD




Le 2012-04-17 =E0 09:00, Masanobu Kawashima a =E9crit :

>
> Folks,
>
> We have published draft-ietf-v6ops-464xlat-02.
>
> Changes are:
>
> - Changed document category from Informational to BCP
> =A0- A normative language(RFC2119) has reinserted.
> =A0- We did not see any strong opposition on this list except Remi. > =A0 =A0As Cameron and Lorenzo said, we should not treat as a use case<= br> > =A0 =A0for BIH. Remi's some concerns were fixed by this version as= below.
> =A0 =A0If you have any strong opposition, please indicate it.
>
> - Section 7.1. IPv6 Address Format
> =A0- Replaced all text with this one sentence "IPv6 address forma= t
> =A0 =A0in 464XLAT is defined in Section 2.2 of [RFC6052]"
>
> - Section 7.2. IPv4/IPv6 address translation chart
> =A0- Removed all references to /96
> =A0- Added case of "CLAT with NAT44"
>
> - Section 7.4. DNS Proxy Implementation
> =A0- Added a reference to RFC5625
>
> - Section 7.5. IPv6 Prefix Handling
> =A0- Removed all references to /96
> =A0- Added a reference to RFC3633
>
> All comments are welcome.
>
> Regards,
> Masanobu
>

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

--20cf3074d21ec6115704be0a175a-- From dan-v6ops@drown.org Thu Apr 19 10:10:45 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60DDE21F869C for ; Thu, 19 Apr 2012 10:10:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SreODOL2H6DP for ; Thu, 19 Apr 2012 10:10:45 -0700 (PDT) Received: from vps3.drown.org (vps3.drown.org [IPv6:2600:3c00::f03c:91ff:fedf:5654]) by ietfa.amsl.com (Postfix) with ESMTP id E7FDD21F8692 for ; Thu, 19 Apr 2012 10:10:44 -0700 (PDT) Received: by vps3.drown.org (Postfix, from userid 48) id 48E55C157; Thu, 19 Apr 2012 13:10:44 -0400 (EDT) Received: from fan.aus.datapipe.net (fan.aus.datapipe.net [2001:1938:1b2:2:7aac:c0ff:fe97:ce69]) by mail.drown.org (Horde Framework) with HTTP; Thu, 19 Apr 2012 12:10:44 -0500 Message-ID: <20120419121044.17531mk1mv19abr4@mail.drown.org> Date: Thu, 19 Apr 2012 12:10:44 -0500 From: Dan Drown To: v6ops@ietf.org References: <20120417065542.31115.95082.idtracker@ietfa.amsl.com> <20120417160010kawashimam@mail.jp.nec.com> <56E2AD61-1C91-4889-914A-353793FCBE43@laposte.net> In-Reply-To: <56E2AD61-1C91-4889-914A-353793FCBE43@laposte.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.3.9) Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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, 19 Apr 2012 17:10:45 -0000 Quoting R=E9mi Despr=E9s : > (a) Only describe the solution where a single IPv6 prefix per CLAT =20 > node is enough (i.e. case 2 of Section 7.5, with NAT44 in the node) Hello, I believe I can help with this question by using the Android =20 clat implementation as an example. I took these addresses from my phone connected via T-Mobile's network PLAT prefix (detected through DNS64) - fd00:976a:c305:692e::/96 Phone IPv6 subnet - 2607:fb90:800:68c::/64 Phone IPv6 address - 2607:fb90:800:68c::eae6:901 CLAT IPv6 address - 2607:fb90:800:68c:abcd:0:aff:ff01 CLAT IPv4 address - 10.255.255.1 The CLAT v4 and v6 addresses are a simple 1 to 1 relation, and v4 =20 tethering clients are NAT44'd to the CLAT v4 address. v6 tethering =20 would require the phone to proxy ND respond for the CLAT v6 address. =20 Since proxy ND requires joining multicast groups based on the address, =20 it's much easier to proxy ND a /128 than a /96. From despres.remi@laposte.net Thu Apr 19 13:58:26 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D15C21F85D1 for ; Thu, 19 Apr 2012 13:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.866 X-Spam-Level: X-Spam-Status: No, score=-1.866 tagged_above=-999 required=5 tests=[AWL=-0.167, 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 goI7S3U+sjcE for ; Thu, 19 Apr 2012 13:58:25 -0700 (PDT) Received: from smtpout.laposte.net (smtpout3.laposte.net [193.253.67.228]) by ietfa.amsl.com (Postfix) with ESMTP id 599E521F8526 for ; Thu, 19 Apr 2012 13:58:24 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8505-out with ME id zwyJ1i00537Y3f403wyJEV; Thu, 19 Apr 2012 22:58:22 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <20120419121044.17531mk1mv19abr4@mail.drown.org> Date: Thu, 19 Apr 2012 22:58:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0646611B-5594-40EA-A2C4-F99CBA734024@laposte.net> References: <20120417065542.31115.95082.idtracker@ietfa.amsl.com> <20120417160010kawashimam@mail.jp.nec.com> <56E2AD61-1C91-4889-914A-353793FCBE43@laposte.net> <20120419121044.17531mk1mv19abr4@mail.drown.org> To: Dan Drown X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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, 19 Apr 2012 20:58:26 -0000 Dan,=20 Thank you for these data. =20 Le 2012-04-19 =E0 19:10, Dan Drown a =E9crit : > Quoting R=E9mi Despr=E9s : >> (a) Only describe the solution where a single IPv6 prefix per CLAT = node is enough (i.e. case 2 of Section 7.5, with NAT44 in the node) >=20 > Hello, I believe I can help with this question by using the Android = clat implementation as an example. >=20 > I took these addresses from my phone connected via T-Mobile's network >=20 > PLAT prefix (detected through DNS64) - fd00:976a:c305:692e::/96 > Phone IPv6 subnet - 2607:fb90:800:68c::/64 > Phone IPv6 address - 2607:fb90:800:68c::eae6:901 > CLAT IPv6 address - 2607:fb90:800:68c:abcd:0:aff:ff01 > CLAT IPv4 address - 10.255.255.1 >=20 > The CLAT v4 and v6 addresses are a simple 1 to 1 relation, and v4 = tethering clients are NAT44'd to the CLAT v4 address. =20 > v6 tethering would require the phone to proxy ND respond for the CLAT = v6 address. Apparently, then, your Android host only offers IPv4 to tethered hosts. = (Since it is attached to an IPv6-only network, this restriction should = obviously be provisional). > Since proxy ND requires joining multicast groups based on the = address, it's much easier to proxy ND a /128 than a /96. In my understanding, that is two /128s that should be proxied: = 2607:fb90:800:68c::eae6:901 AND 2607:fb90:800:68c:abcd:0:aff:ff01).=20 Note that this need for TWO proxied addresses, which goes beyond what is = done in ordinary IPv6 CPEs, would be avoided with my proposal c2 of = http://www.ietf.org/mail-archive/web/v6ops/current/msg12660.html: - CLAT outgoing packets would have SRC =3D 2607:fb90:800:68c::eae6:901, = and DST starting with fd00:976a:c305:692e::/96 - CLAT incoming packets (to be submitted to the NAT44) would be = recognized by their SRCs starting with fd00:976a:c305:692e::/96=20 - No CLAT IPv4 address would appear anywhere on the wire (but = 10.255.255.1 can be used as NAT external address if needed by the NAT44 = code)=20 Regards, RD > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From dan-v6ops@drown.org Thu Apr 19 16:18:15 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B8D521F858A for ; Thu, 19 Apr 2012 16:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yEUs31IX1tN5 for ; Thu, 19 Apr 2012 16:18:14 -0700 (PDT) Received: from vps3.drown.org (vps3.drown.org [IPv6:2600:3c00::f03c:91ff:fedf:5654]) by ietfa.amsl.com (Postfix) with ESMTP id 862CE21F856F for ; Thu, 19 Apr 2012 16:18:14 -0700 (PDT) Received: by vps3.drown.org (Postfix, from userid 48) id F0673C157; Thu, 19 Apr 2012 19:18:13 -0400 (EDT) Received: from fan.aus.datapipe.net (fan.aus.datapipe.net [2001:1938:1b2:2:7aac:c0ff:fe97:ce69]) by mail.drown.org (Horde Framework) with HTTP; Thu, 19 Apr 2012 18:18:13 -0500 Message-ID: <20120419181813.4524701l3gkq5zks@mail.drown.org> Date: Thu, 19 Apr 2012 18:18:13 -0500 From: Dan Drown To: v6ops WG References: <20120417065542.31115.95082.idtracker@ietfa.amsl.com> <20120417160010kawashimam@mail.jp.nec.com> <56E2AD61-1C91-4889-914A-353793FCBE43@laposte.net> <20120419121044.17531mk1mv19abr4@mail.drown.org> <0646611B-5594-40EA-A2C4-F99CBA734024@laposte.net> In-Reply-To: <0646611B-5594-40EA-A2C4-F99CBA734024@laposte.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.3.9) Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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, 19 Apr 2012 23:18:15 -0000 Quoting R=E9mi Despr=E9s : > Apparently, then, your Android host only offers IPv4 to tethered =20 > hosts. (Since it is attached to an IPv6-only network, this =20 > restriction should obviously be provisional). The handset can source IPv4 traffic using the CLAT IPv4 address as =20 well as NAT44 the IPv4 tethering traffic. > In my understanding, that is two /128s that should be proxied: =20 > 2607:fb90:800:68c::eae6:901 AND 2607:fb90:800:68c:abcd:0:aff:ff01). Thankfully, one can re-use the interface ip =20 (2607:fb90:800:68c::eae6:901 in this case) on both the outside (cell =20 network) and inside (wifi tethering) interfaces. So it's just the =20 CLAT /128 that needs proxy ND. > Note that this need for TWO proxied addresses, which goes beyond =20 > what is done in ordinary IPv6 CPEs, would be avoided with my =20 > proposal c2 of =20 > http://www.ietf.org/mail-archive/web/v6ops/current/msg12660.html: > - CLAT outgoing packets would have SRC =3D =20 > 2607:fb90:800:68c::eae6:901, and DST starting with =20 > fd00:976a:c305:692e::/96 > - CLAT incoming packets (to be submitted to the NAT44) would be =20 > recognized by their SRCs starting with fd00:976a:c305:692e::/96 > - No CLAT IPv4 address would appear anywhere on the wire (but =20 > 10.255.255.1 can be used as NAT external address if needed by the =20 > NAT44 code) I am constrained by my implementation choices. Since I used a tun =20 interface and userland code, I need a dedicated IPv6 address for CLAT =20 (traffic is sent to the tun interface by ipv6 forwarding). An =20 implementation inside the kernel would be able to do what you ask, but =20 it would come at a higher maintenance cost. Perhaps my concerns are =20 outside the relm of what a specification should be concerned about, =20 though. From fibrib@gmail.com Thu Apr 19 18:34:47 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A3DF21F85B5 for ; Thu, 19 Apr 2012 18:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.186 X-Spam-Level: X-Spam-Status: No, score=-3.186 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 EFpWJMpErjJ5 for ; Thu, 19 Apr 2012 18:34:47 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id C99BA21F85AA for ; Thu, 19 Apr 2012 18:34:46 -0700 (PDT) Received: by qaea16 with SMTP id a16so71620qae.10 for ; Thu, 19 Apr 2012 18:34:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=74DEwToLmK7pwMqlibv4LrJ3NjuW+gnu7oA/SNTDsTY=; b=xrDLgbeG9EksBClrX8dURgGXeH+5cUxUeYF0/1POijWnqh70oEaj5/Znk2mUTK121i tv+a6IlBvDxQ7k6bePp6LmnyUzniWWRJ+JmYIwvGnURRd6NjYK8vpsCm4F4msiEdM9Fa 6dMbslZ+C2HZ0yu4urZEOgEqrLOorCel7SDL91shub2JRifwsKsGDokrzIHvu6lY6sii O9knjxwNBHkkr7MJl1m+5W3Bttox9hUWe6dHdj5UopCNhHHNXW4T27cGyB65uyL93QOZ GKtzrLJ7J058BW7iFHWFUzHYkyIByOBu9jBPJisYtn5Yv9BKh8G+daLXNZMs0+hfbvFG A33A== MIME-Version: 1.0 Received: by 10.224.187.210 with SMTP id cx18mr5805446qab.45.1334885684732; Thu, 19 Apr 2012 18:34:44 -0700 (PDT) Received: by 10.229.123.197 with HTTP; Thu, 19 Apr 2012 18:34:44 -0700 (PDT) In-Reply-To: <13E111C2-BA64-4EF9-B29D-8F0719B925ED@laposte.net> References: <20120419162541kawashimam@mail.jp.nec.com> <13E111C2-BA64-4EF9-B29D-8F0719B925ED@laposte.net> Date: Fri, 20 Apr 2012 01:34:44 +0000 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=485b397dd4bb0de48704be124b72 Cc: v6ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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, 20 Apr 2012 01:34:47 -0000 --485b397dd4bb0de48704be124b72 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable sorry i missed to respond this point. 2012/4/19 R=E9mi Despr=E9s > > 2012-04-19 13:32, Maoke: > > ... > > if you certainly refer to these *TWO* prefices, then i think the questio= n > has been cleared. > > > If we agree that sec.7.5 case 1 requires two delegated prefixes per > customer, yes, this question cleared. > "case 1 requires" would be a little misleading, giving an impression that one chooses case 1 then he/she must have two prefices otherwise he/she fails the deployment. it is not incorrect but the logic is inverse to the practice of deployment. the practice is: if i have several prefices for a CLAT or a prefices with higher level of aggregation, then i may consider to deploy case 1; if i have only one /64, i deploy case 2 instead. one prefix or two prefices are of condition of deployment rather than the "requirement". 464xlat doesn't preset either case 1 or 2 as prerequisite of any deployment. as a whole, 464xlat doesn't *require* two delegated prefices per customer, but it suggests to decide (not *choose*) between case 1 and 2 according to the condition in reality. hope it clarifies. - maoke --485b397dd4bb0de48704be124b72 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

sorry i missed to respond this point.=A0

<= div class=3D"gmail_quote">2012/4/19 R=E9mi Despr=E9s <= despres.remi@laposte.net>= ;

2012-04-19 =A013:32, Maoke:

...

=A0if you certainly refer to these *TWO* prefices, then i think the qu= estion has been cleared.

If we= agree that sec.7.5 case 1 requires two delegated prefixes per customer, ye= s, this question cleared.=A0

"case 1 requires" wo= uld be a little misleading, giving an impression that one chooses case 1 th= en he/she must have two prefices otherwise he/she fails the deployment. it = is not incorrect but the logic is inverse to the practice of deployment.=A0=

the practice is: if i have several prefices for a CLAT = or a prefices with higher level of aggregation, then i may consider to depl= oy case 1; if i have only one /64, i deploy case 2 instead. one prefix or t= wo prefices are of condition of deployment rather than the "requiremen= t". 464xlat doesn't preset either case 1 or 2 as prerequisite of a= ny deployment.=A0

as a whole, 464xlat doesn't *require* two del= egated prefices per customer, but it suggests to decide (not *choose*) betw= een case 1 and 2 according to the condition in reality. =A0

hope it clarifies.=A0

- maoke=A0
--485b397dd4bb0de48704be124b72-- From phdgang@gmail.com Thu Apr 19 22:41:10 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35BEB21F8549 for ; Thu, 19 Apr 2012 22:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.525, 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 TxhuFQ-L6KGb for ; Thu, 19 Apr 2012 22:41:09 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id 4341821F84FA for ; Thu, 19 Apr 2012 22:41:09 -0700 (PDT) Received: by wibhr17 with SMTP id hr17so375589wib.1 for ; Thu, 19 Apr 2012 22:41:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ZJpe1krF5iSbGXYCEXRjsTelAUy5KifZNbEFPdHNySQ=; b=etWL027u1IuwIqeOYVd0cATtEStBnOExyhTK+Z0iJY+I4RusgF8zey2WpImSq6RTzy fmR+HfmOxBBCw4OdlMOyTWW49DSS/qFdIbJy7491gS/f8x9K20+Eyl8eDGToCauwxdzJ bOdHNgblofG4K4AQgELxNYtvn/5pC5nkybPRk7/32YndGdarWldSPkeCL+oytJIjZnE6 gVajuA6PhHDCP2mrz66KCROgc5TY89I0/kQvKyFEtgGqucJ5b9TX/Sr0c0ZSPECTWnhe AjZ/lhQi1Vc8LUNS8FlnWeOelmIJhI7NAyObtne+IURKyGOVfgc9o2RfkAsWI717yVqR ZARg== MIME-Version: 1.0 Received: by 10.180.103.229 with SMTP id fz5mr3990221wib.0.1334900468286; Thu, 19 Apr 2012 22:41:08 -0700 (PDT) Received: by 10.180.100.97 with HTTP; Thu, 19 Apr 2012 22:41:08 -0700 (PDT) In-Reply-To: <20120419181813.4524701l3gkq5zks@mail.drown.org> References: <20120417065542.31115.95082.idtracker@ietfa.amsl.com> <20120417160010kawashimam@mail.jp.nec.com> <56E2AD61-1C91-4889-914A-353793FCBE43@laposte.net> <20120419121044.17531mk1mv19abr4@mail.drown.org> <0646611B-5594-40EA-A2C4-F99CBA734024@laposte.net> <20120419181813.4524701l3gkq5zks@mail.drown.org> Date: Fri, 20 Apr 2012 13:41:08 +0800 Message-ID: From: GangChen To: Dan Drown Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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, 20 Apr 2012 05:41:10 -0000 2012/4/20, Dan Drown : > Quoting R=E9mi Despr=E9s : >> Apparently, then, your Android host only offers IPv4 to tethered >> hosts. (Since it is attached to an IPv6-only network, this >> restriction should obviously be provisional). > > The handset can source IPv4 traffic using the CLAT IPv4 address as > well as NAT44 the IPv4 tethering traffic. > >> In my understanding, that is two /128s that should be proxied: >> 2607:fb90:800:68c::eae6:901 AND 2607:fb90:800:68c:abcd:0:aff:ff01). > > Thankfully, one can re-use the interface ip > (2607:fb90:800:68c::eae6:901 in this case) on both the outside (cell > network) and inside (wifi tethering) interfaces. So it's just the > CLAT /128 that needs proxy ND. Just wondering to know how could re-use the ip address, which already used on outside? http://tools.ietf.org/html/draft-ietf-dhc-pd-exclude give me a hint it should be excluded in Lan side >> Note that this need for TWO proxied addresses, which goes beyond >> what is done in ordinary IPv6 CPEs, would be avoided with my >> proposal c2 of >> http://www.ietf.org/mail-archive/web/v6ops/current/msg12660.html: >> - CLAT outgoing packets would have SRC =3D >> 2607:fb90:800:68c::eae6:901, and DST starting with >> fd00:976a:c305:692e::/96 >> - CLAT incoming packets (to be submitted to the NAT44) would be >> recognized by their SRCs starting with fd00:976a:c305:692e::/96 >> - No CLAT IPv4 address would appear anywhere on the wire (but >> 10.255.255.1 can be used as NAT external address if needed by the >> NAT44 code) +1 BRs Gang > I am constrained by my implementation choices. Since I used a tun > interface and userland code, I need a dedicated IPv6 address for CLAT > (traffic is sent to the tun interface by ipv6 forwarding). An > implementation inside the kernel would be able to do what you ask, but > it would come at a higher maintenance cost. Perhaps my concerns are > outside the relm of what a specification should be concerned about, > though. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From denghui02@gmail.com Fri Apr 20 01:42:15 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0107421F8778 for ; Fri, 20 Apr 2012 01:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.199 X-Spam-Level: X-Spam-Status: No, score=-103.199 tagged_above=-999 required=5 tests=[AWL=-0.201, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_45=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 ybeoYwxZ1XaG for ; Fri, 20 Apr 2012 01:42:13 -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 80FF221F8771 for ; Fri, 20 Apr 2012 01:42:13 -0700 (PDT) Received: by ghbg16 with SMTP id g16so5732325ghb.31 for ; Fri, 20 Apr 2012 01:42:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xvVjVNr77g/wCF0NdbL/3ULVN0ztmwAupnsd+1+iJds=; b=pJsV0cH/0GSteaESzoWJhknyBU85vdj7gjF5PPEsm19YcIVDjasPnyVoSkug2aH+06 SazPBk7JUFyndklO3NLzZBbAgoLQFW1TIj7ZsE7QlhF8qDOf4GFL8tt5526xuAwHZMQW tX6OlGohikO1B32IS+5shutlpO/tEV4Yjo6Oss+wFBRdO6/XcQDhQfat4+Xy4wCBlUet ocKPcqvRNDyWD+GlO6G+zsGoluzOSn+mCiTcOkl7ywc2QtVJl2BWcXywHeQjuDCEf3Yr dS1eHAJEG+6GESySH/x8vFHd+nq9goMdMFkqh73SPOWElTHMq3hf3hIBR332NXeTQ7lp iCZA== MIME-Version: 1.0 Received: by 10.236.147.19 with SMTP id s19mr5108689yhj.36.1334911333095; Fri, 20 Apr 2012 01:42:13 -0700 (PDT) Received: by 10.147.115.6 with HTTP; Fri, 20 Apr 2012 01:42:13 -0700 (PDT) In-Reply-To: <00E2D7E99C861A4EB7AD45C85B136FF777586C@EXCHANGE-NAME.blackberry.hq.cmcc> References: <00E2D7E99C861A4EB7AD45C85B136FF777586C@EXCHANGE-NAME.blackberry.hq.cmcc> Date: Fri, 20 Apr 2012 16:42:13 +0800 Message-ID: From: Hui Deng To: "bill.huang" Content-Type: multipart/alternative; boundary=20cf303636e5d0db0d04be18432f Cc: v6ops@ietf.org, dengxiaoning@chinamobile.com, teemu.savolainen@nokia.com, yuchuan@chinamobile.com Subject: Re: [v6ops] BIH open 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, 20 Apr 2012 08:42:15 -0000 --20cf303636e5d0db0d04be18432f Content-Type: text/plain; charset=ISO-8859-1 Bill We have submitted BIH open source to Linux Foundation BIH kernel patch is getting ready to next step after technical advisory board review Please check the link for more information https://events.linuxfoundation.org/events/android-builders-summit/wang http://video.linux.com/videos/bump-in-host-on-android-a-host-based-ipv4-to-ipv6-translation Best, -Hui 2012/4/20 bill.huang > Hui, > > Good to see that. > > Hope that we also submit to Linux foundation as well. > > We shall also advocate to have it distributed as part of the standard > kernel distribution. > > Regards, > > -Bill > > ------------------------------ > *From*: adminJT@chinamobile.com ** > *To*: cb.list6@gmail.com ** > *Cc*: despres.remi@laposte.net **; v6ops@ietf.org **; lorenzo@google.com * > *; bill.huang; teemu.savolainen@nokia.com ** > *Sent*: Mon Apr 16 22:56:38 2012 > *Subject*: BIH open source > > Hello all > > Please be aware of open source for BIH as below: > http://code.google.com/p/bump-in-the-host/source/ > > Feel free to let us know if you have any questions. > > Best, > > -Hui > --20cf303636e5d0db0d04be18432f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Bill
=A0
We have submitted BIH open source to Linux Foundation
=A0
BIH kernel patch is getting ready to next step after technical advisor= y board review
=A0
Please check the link for more information
=A0
Best,
=A0
-Hui
2012/4/20 bill.huang <bill.huang@chinamobile.com>=

Hui,

Good to see that.
Hope that we also submit to Linux foundation as well.

We shall also= advocate to have it distributed as part of the standard kernel distributio= n.

Regards,

-Bill

From: adminJT@chinamobile.com
To: cb.list6@gmail.com =
Cc: de= spres.remi@laposte.net ; v6ops@ietf.org ; lorenzo@google.com ; bill.huang; teemu.savolainen@n= okia.com
Sent: Mon Apr 16 22:56:38 2012
Subject: BIH open source

Hello all
=A0
Please be aware of open source for BIH as below:
=A0
Feel free to let us know if you have any questions.
=A0
Best,
=A0
-Hui


--20cf303636e5d0db0d04be18432f-- From despres.remi@laposte.net Fri Apr 20 02:05:32 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF7AE21F87BA for ; Fri, 20 Apr 2012 02:05:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.864 X-Spam-Level: X-Spam-Status: No, score=-1.864 tagged_above=-999 required=5 tests=[AWL=-0.165, 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 fa+WFmzFF6cZ for ; Fri, 20 Apr 2012 02:05:30 -0700 (PDT) Received: from smtpout.laposte.net (smtpout3.laposte.net [193.253.67.228]) by ietfa.amsl.com (Postfix) with ESMTP id 3D5BA21F87AF for ; Fri, 20 Apr 2012 02:05:29 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8506-out with ME id 095K1j00H37Y3f40395K16; Fri, 20 Apr 2012 11:05:21 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <20120419181813.4524701l3gkq5zks@mail.drown.org> Date: Fri, 20 Apr 2012 11:05:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <45ABAD31-C265-4D63-82E2-3DE6F59B80C0@laposte.net> References: <20120417065542.31115.95082.idtracker@ietfa.amsl.com> <20120417160010kawashimam@mail.jp.nec.com> <56E2AD61-1C91-4889-914A-353793FCBE43@laposte.net> <20120419121044.17531mk1mv19abr4@mail.drown.org> <0646611B-5594-40EA-A2C4-F99CBA734024@laposte.net> <20120419181813.4524701l3gkq5zks@mail.drown.org> To: Dan Drown X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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, 20 Apr 2012 09:05:32 -0000 Le 2012-04-20 =E0 01:18, Dan Drown a =E9crit : > Quoting R=E9mi Despr=E9s : >> Apparently, then, your Android host only offers IPv4 to tethered = hosts. (Since it is attached to an IPv6-only network, this restriction = should obviously be provisional). >=20 > The handset can source IPv4 traffic using the CLAT IPv4 address as = well as NAT44 the IPv4 tethering traffic. >=20 >> In my understanding, that is two /128s that should be proxied: = 2607:fb90:800:68c::eae6:901 AND 2607:fb90:800:68c:abcd:0:aff:ff01). >=20 > Thankfully, one can re-use the interface ip = (2607:fb90:800:68c::eae6:901 in this case) on both the outside (cell = network) and inside (wifi tethering) interfaces. So it's just the CLAT = /128 that needs proxy ND. Two interfaces having the same IPv6 address (2607:fb90:800:68c::eae6:901 = in this case) would break the RFC4291 model which has: "An IPv6 unicast address refers to a single interface." >> Note that this need for TWO proxied addresses, which goes beyond what = is done in ordinary IPv6 CPEs, would be avoided with my proposal c2 of = http://www.ietf.org/mail-archive/web/v6ops/current/msg12660.html: >> - CLAT outgoing packets would have SRC =3D = 2607:fb90:800:68c::eae6:901, and DST starting with = fd00:976a:c305:692e::/96 >> - CLAT incoming packets (to be submitted to the NAT44) would be = recognized by their SRCs starting with fd00:976a:c305:692e::/96 >> - No CLAT IPv4 address would appear anywhere on the wire (but = 10.255.255.1 can be used as NAT external address if needed by the NAT44 = code) >=20 > I am constrained by my implementation choices. Since I used a tun = interface and userland code, I need a dedicated IPv6 address for CLAT = (traffic is sent to the tun interface by ipv6 forwarding). =20 Note that, by using TAP instead of TUN, your implementation could remain = in user space while operating at the link layer = (http://en.wikipedia.org/wiki/TUN/TAP). Then, with my c2 proposal, proxy ND for 2607:fb90:800:68c::eae6:901 can = be enough (607:fb90:800:68c:abcd:0:aff:ff01 isn't used), and RFC4291 is = complied with. Thought?=20 RD > An implementation inside the kernel would be able to do what you ask, = but it would come at a higher maintenance cost. Perhaps my concerns are = outside the relm of what a specification should be concerned about, = though. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From lorenzo@google.com Fri Apr 20 03:32:13 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5218621F8732 for ; Fri, 20 Apr 2012 03:32:13 -0700 (PDT) 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 nTRYcEk8-cMO for ; Fri, 20 Apr 2012 03:32:12 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id A0DF021F8731 for ; Fri, 20 Apr 2012 03:32:12 -0700 (PDT) Received: by obbwd20 with SMTP id wd20so9213220obb.31 for ; Fri, 20 Apr 2012 03:32:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=DUGZXIcpuoWrrWwgO1Ys7AUGvunbmScvLZFDgYaYu94=; b=cmxhAqlH/6ujEjqBe7jF+jBDAUzbUoa1A70N+oJ8jbpFkJobMuqrs0cIL+RR4moSmd scRwLqhiPkNDzjM++G78O8WAkeCsP5re8zjTVAMXuTxJ8peRczPevcKTXPO3ikKQwpiC WUAcNsl6vMKq2J0zaY37djJAh+4uGOJ1ea3vLzN0DEgDS97jwUasMz8kPHMbagottaCq +T0Y3iu05EbuET9bMMCkeN3/h0ijq6v6yJSliAx580thPA/AfIjAd1gXreMccp5wYHsS TYpQa03uhpu3hwmwq5aamNO2GTXl6dXmiToJ0sKuV3vlCqJk2jZzP0maOWmHLVSqfY5u wdQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=DUGZXIcpuoWrrWwgO1Ys7AUGvunbmScvLZFDgYaYu94=; b=LdDZUQMym82BVqXpRqIaC0WPhxKVfNTKJFxBWcSpK6PbAZEepgrObSwwMWNLkWdAYM x2p9coQiHfJUQwMpBhExcp4DsVzy29rjOQ2uRtKodT+wnXTVg+O48zs2zMpkpM+rHHYL IeOUUL2oE+/Y00ItLzJszj8NN5BXvYbmiAmP3ui902wLXxKbq5c+unnT+VLe8BToFqq6 52YIj0Cdrr0zRze+me21EUl+PK+bjQv41xal11CKZg9yav7TV+OxJhPSDaJIB5jAeUiI vcfMlEeUwYti0NO07Lyduo0t/4PmrJB2UzuTjWakw06X+Hg/+n0zUViGbYZzt7lB1O0d uc2g== Received: by 10.182.72.38 with SMTP id a6mr8015727obv.38.1334917932238; Fri, 20 Apr 2012 03:32:12 -0700 (PDT) Received: by 10.182.72.38 with SMTP id a6mr8015708obv.38.1334917932029; Fri, 20 Apr 2012 03:32:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.220.3 with HTTP; Fri, 20 Apr 2012 03:31:51 -0700 (PDT) In-Reply-To: <20120419181813.4524701l3gkq5zks@mail.drown.org> References: <20120417065542.31115.95082.idtracker@ietfa.amsl.com> <20120417160010kawashimam@mail.jp.nec.com> <56E2AD61-1C91-4889-914A-353793FCBE43@laposte.net> <20120419121044.17531mk1mv19abr4@mail.drown.org> <0646611B-5594-40EA-A2C4-F99CBA734024@laposte.net> <20120419181813.4524701l3gkq5zks@mail.drown.org> From: Lorenzo Colitti Date: Fri, 20 Apr 2012 19:31:51 +0900 Message-ID: To: Dan Drown Content-Type: multipart/alternative; boundary=f46d0447a2a92497c104be19cdc6 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmhHLjClcBdn069baenU72RL5Q6oiIHX3BICSuAvFLyAKPhIo65IM/X1RhlsnxyqRQRFBg06rdSOoMG5aFwq2oLm0DK6uVPFCOeIBoSsZo23jfHscLwTt77IPcOkrjlKwXP1guQ Cc: v6ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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, 20 Apr 2012 10:32:13 -0000 --f46d0447a2a92497c104be19cdc6 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Apr 20, 2012 at 08:18, Dan Drown wrote: > >> - No CLAT IPv4 address would appear anywhere on the wire (but >> 10.255.255.1 can be used as NAT external address if needed by the NAT44 >> code) >> > > I am constrained by my implementation choices. Since I used a tun > interface and userland code, I need a dedicated IPv6 address for CLAT > (traffic is sent to the tun interface by ipv6 forwarding). Why does the CLAT interface need an IPv6 address in order to forward packets to it? Is it because you specify 2607:fb90:800:68c:abcd:0:aff:ff01 as the next hop? If so, can't you specify something like "dev clat" instead of "via 2607:fb90:800:68c:abcd:0:aff:ff01" in the route? --f46d0447a2a92497c104be19cdc6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Apr 20, 2012 at 08:18, Dan Drown <dan= -v6ops@drown.org> wrote:

- No CLAT IPv4 address would appear= anywhere on the wire (but 10.255.255.1 can be used as NAT external address= if needed by the NAT44 code)

I am constrained by my implementation choices. =A0Since I used a tun interf= ace and userland code, I need a dedicated IPv6 address for CLAT (traffic is= sent to the tun interface by ipv6 forwarding).

Why does the CLAT interface need an IPv6 address in order to forward p= ackets to it? Is it because you specify 2607:fb90:800:68c:abcd:0:aff:ff01 a= s the next hop? If so, can't you specify something like "dev clat&= quot; instead of "via 2607:fb90:800:68c:abcd:0:aff:ff01" in the r= oute?
--f46d0447a2a92497c104be19cdc6-- From dan-v6ops@drown.org Fri Apr 20 08:42:54 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2C5521F8726 for ; Fri, 20 Apr 2012 08:42:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1E1Lswm8Kzn for ; Fri, 20 Apr 2012 08:42:53 -0700 (PDT) Received: from vps3.drown.org (vps3.drown.org [IPv6:2600:3c00::f03c:91ff:fedf:5654]) by ietfa.amsl.com (Postfix) with ESMTP id 1F39D21F865B for ; Fri, 20 Apr 2012 08:42:48 -0700 (PDT) Received: by vps3.drown.org (Postfix, from userid 48) id 0BBBCC16E; Fri, 20 Apr 2012 11:42:47 -0400 (EDT) Received: from 2001:470:b88f:c8f6:224:1dff:fe16:eb3b ([2001:470:b88f:c8f6:224:1dff:fe16:eb3b]) by mail.drown.org (Horde Framework) with HTTP; Fri, 20 Apr 2012 10:42:46 -0500 Message-ID: <20120420104246.1432746csfcrdqo8@mail.drown.org> Date: Fri, 20 Apr 2012 10:42:46 -0500 From: Dan Drown To: =?iso-8859-1?b?UultaSA=?= =?iso-8859-1?b?RGVzcHLpcw==?= , Lorenzo Colitti , v6ops WG References: <20120417065542.31115.95082.idtracker@ietfa.amsl.com> <20120417160010kawashimam@mail.jp.nec.com> <56E2AD61-1C91-4889-914A-353793FCBE43@laposte.net> <20120419121044.17531mk1mv19abr4@mail.drown.org> <0646611B-5594-40EA-A2C4-F99CBA734024@laposte.net> <20120419181813.4524701l3gkq5zks@mail.drown.org> <45ABAD31-C265-4D63-82E2-3DE6F59B80C0@laposte.net> In-Reply-To: <45ABAD31-C265-4D63-82E2-3DE6F59B80C0@laposte.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.3.9) Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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, 20 Apr 2012 15:42:54 -0000 Quoting R=E9mi Despr=E9s : > Two interfaces having the same IPv6 address =20 > (2607:fb90:800:68c::eae6:901 in this case) would break the RFC4291 =20 > model which has: > "An IPv6 unicast address refers to a single interface." I do not see the harm in re-using a point to point interface's address =20 (which is configured as a /128) on one ethernet interface. The =20 alternative would be to proxy ND that address, and I do not see the =20 benefit. > Note that, by using TAP instead of TUN, your implementation could =20 > remain in user space while operating at the link layer =20 > (http://en.wikipedia.org/wiki/TUN/TAP). > Then, with my c2 proposal, proxy ND for 2607:fb90:800:68c::eae6:901 =20 > can be enough (2607:fb90:800:68c:abcd:0:aff:ff01 isn't used), and =20 > RFC4291 is complied with. TAP would require additional implementation work in two areas: 1. switching the android tethering system to using an ethernet =20 bridging configuration 2. switching the android-clat software from dealing with IP packets to =20 dealing with ethernet packets, including adding ND support Doing this would eliminate the need to proxy ND the clat address. =20 This would not fix the duplicate phone address issue, as the cell =20 network interface is a point to point interface and not ethernet. I believe that using proxy ND is an acceptable alternative to =20 switching to TAP. Quoting Lorenzo Colitti : > Why does the CLAT interface need an IPv6 address in order to forward > packets to it? Is it because you specify 2607:fb90:800:68c:abcd:0:aff:ff0= 1 > as the next hop? If so, can't you specify something like "dev clat" inste= ad > of "via 2607:fb90:800:68c:abcd:0:aff:ff01" in the route? It's not the phone's interface that needs the IP, it's the CLAT =20 function that needs the IP. All v6 traffic to and from the CLAT =20 software needs a v6 address to distinguish it from the phone's native =20 v6 traffic. From despres.remi@laposte.net Fri Apr 20 09:03:32 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37F2321F8736 for ; Fri, 20 Apr 2012 09:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.161 X-Spam-Level: X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aXXwB5HADpvI for ; Fri, 20 Apr 2012 09:03:31 -0700 (PDT) Received: from smtpout.laposte.net (smtpout4.laposte.net [193.253.67.229]) by ietfa.amsl.com (Postfix) with ESMTP id 1429321F85A0 for ; Fri, 20 Apr 2012 09:03:30 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8508-out with ME id 0G3Q1j00137Y3f403G3QwV; Fri, 20 Apr 2012 18:03:25 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <20120420104246.1432746csfcrdqo8@mail.drown.org> Date: Fri, 20 Apr 2012 18:03:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120417065542.31115.95082.idtracker@ietfa.amsl.com> <20120417160010kawashimam@mail.jp.nec.com> <56E2AD61-1C91-4889-914A-353793FCBE43@laposte.net> <20120419121044.17531mk1mv19abr4@mail.drown.org> <0646611B-5594-40EA-A2C4-F99CBA734024@laposte.net> <20120419181813.4524701l3gkq5zks@mail.drown.org> <45ABAD31-C265-4D63-82E2-3DE6F59B80C0@laposte.net> <20120420104246.1432746csfcrdqo8@mail.drown.org> To: Dan Drown X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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, 20 Apr 2012 16:03:32 -0000 Le 2012-04-20 =E0 17:42, Dan Drown a =E9crit : > Quoting R=E9mi Despr=E9s : >> Two interfaces having the same IPv6 address = (2607:fb90:800:68c::eae6:901 in this case) would break the RFC4291 model = which has: >> "An IPv6 unicast address refers to a single interface." >=20 > I do not see the harm in re-using a point to point interface's address = (which is configured as a /128) on one ethernet interface. The = alternative would be to proxy ND that address, and I do not see the = benefit. >=20 >> Note that, by using TAP instead of TUN, your implementation could = remain in user space while operating at the link layer = (http://en.wikipedia.org/wiki/TUN/TAP). >> Then, with my c2 proposal, proxy ND for 2607:fb90:800:68c::eae6:901 = can be enough (2607:fb90:800:68c:abcd:0:aff:ff01 isn't used), and = RFC4291 is complied with. >=20 > TAP would require additional implementation work in two areas: >=20 > 1. switching the android tethering system to using an ethernet = bridging configuration Why? - Can't the CLAT take packets it is concerned with from incoming = Ethernet frames, and return other frames to the kernel, thus changing = nothing for native IPv6? - The IPv4 router, because it is isolated from the WAN interface by the = NAT44, isn't concerned with the WAN side of the CLAT. >=20 > 2. switching the android-clat software from dealing with IP packets to = dealing with ethernet packets, including adding ND support Can't TAP be used to treat incoming traffic at L2, and TUN to treat = outgoing traffic at L3? RD > Doing this would eliminate the need to proxy ND the clat address. = This would not fix the duplicate phone address issue, as the cell = network interface is a point to point interface and not ethernet. >=20 > I believe that using proxy ND is an acceptable alternative to = switching to TAP. >=20 > Quoting Lorenzo Colitti : >> Why does the CLAT interface need an IPv6 address in order to forward >> packets to it? Is it because you specify = 2607:fb90:800:68c:abcd:0:aff:ff01 >> as the next hop? If so, can't you specify something like "dev clat" = instead >> of "via 2607:fb90:800:68c:abcd:0:aff:ff01" in the route? >=20 > It's not the phone's interface that needs the IP, it's the CLAT = function that needs the IP. All v6 traffic to and from the CLAT = software needs a v6 address to distinguish it from the phone's native v6 = traffic. From dan-v6ops@drown.org Fri Apr 20 10:27:16 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91FE721F85AD for ; Fri, 20 Apr 2012 10:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id inkRZqy29Pjp for ; Fri, 20 Apr 2012 10:27:16 -0700 (PDT) Received: from vps3.drown.org (vps3.drown.org [IPv6:2600:3c00::f03c:91ff:fedf:5654]) by ietfa.amsl.com (Postfix) with ESMTP id C298A21F8575 for ; Fri, 20 Apr 2012 10:27:15 -0700 (PDT) Received: by vps3.drown.org (Postfix, from userid 48) id 5B2C1C16E; Fri, 20 Apr 2012 13:27:15 -0400 (EDT) Received: from fan.aus.datapipe.net (fan.aus.datapipe.net [2001:1938:1b2:2:7aac:c0ff:fe97:ce69]) by mail.drown.org (Horde Framework) with HTTP; Fri, 20 Apr 2012 12:27:15 -0500 Message-ID: <20120420122715.1702279xh7eynpus@mail.drown.org> Date: Fri, 20 Apr 2012 12:27:15 -0500 From: Dan Drown To: =?iso-8859-1?b?UsOpbWkg?= =?iso-8859-1?b?RGVzcHLDqXM=?= , v6ops WG References: <20120417065542.31115.95082.idtracker@ietfa.amsl.com> <20120417160010kawashimam@mail.jp.nec.com> <56E2AD61-1C91-4889-914A-353793FCBE43@laposte.net> <20120419121044.17531mk1mv19abr4@mail.drown.org> <0646611B-5594-40EA-A2C4-F99CBA734024@laposte.net> <20120419181813.4524701l3gkq5zks@mail.drown.org> <45ABAD31-C265-4D63-82E2-3DE6F59B80C0@laposte.net> <20120420104246.1432746csfcrdqo8@mail.drown.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.3.9) Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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, 20 Apr 2012 17:27:16 -0000 Quoting R=C3=A9mi Despr=C3=A9s : > Why? > - Can't the CLAT take packets it is concerned with from incoming =20 > Ethernet frames, and return other frames to the kernel, thus =20 > changing nothing for native IPv6? Incoming packets in my case (from the cell network) are not =20 encapsulated in ethernet. The TAP driver in Linux is named somewhat =20 confusingly, because it has nothing to do with "ethernet taps". The =20 TAP driver provides a way to emulate an ethernet interface in =20 user-land software. I believe what you are thinking of something more along the lines of =20 iptable's NFQUEUE target, which can take a packet and pass it to =20 userspace before processing it locally. That could be used to share =20 the same IPv6 address between the CLAT function and the host. It =20 would be tricky to seperate native v6 traffic from the phone to the =20 PLAT prefix (an application that can use DNS64) and CLAT traffic, but =20 mostly possible by reserving port ranges. But I still don't see the value that this added complexity brings. =20 Why all this work to avoid proxy ND? From despres.remi@laposte.net Fri Apr 20 13:08:12 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00BA921F85CE for ; Fri, 20 Apr 2012 13:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.163 X-Spam-Level: X-Spam-Status: No, score=-2.163 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b7ZS07UbG8TQ for ; Fri, 20 Apr 2012 13:08:11 -0700 (PDT) Received: from smtpout.laposte.net (smtpout1.laposte.net [193.253.67.226]) by ietfa.amsl.com (Postfix) with ESMTP id 0160F21F85CC for ; Fri, 20 Apr 2012 13:08:10 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8502-out with ME id 0L881j00437Y3f403L88jy; Fri, 20 Apr 2012 22:08:09 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <20120420122715.1702279xh7eynpus@mail.drown.org> Date: Fri, 20 Apr 2012 22:08:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120417065542.31115.95082.idtracker@ietfa.amsl.com> <20120417160010kawashimam@mail.jp.nec.com> <56E2AD61-1C91-4889-914A-353793FCBE43@laposte.net> <20120419121044.17531mk1mv19abr4@mail.drown.org> <0646611B-5594-40EA-A2C4-F99CBA734024@laposte.net> <20120419181813.4524701l3gkq5zks@mail.drown.org> <45ABAD31-C265-4D63-82E2-3DE6F59B80C0@laposte.net> <20120420104246.1432746csfcrdqo8@mail.drown.org> <20120420122715.1702279xh7eynpus@mail.drown.org> To: Dan Drown X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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, 20 Apr 2012 20:08:12 -0000 Le 2012-04-20 =E0 19:27, Dan Drown a =E9crit : > Quoting R=C3=A9mi Despr=C3=A9s : >> Why? >> - Can't the CLAT take packets it is concerned with from incoming = Ethernet frames, and return other frames to the kernel, thus changing = nothing for native IPv6? >=20 > Incoming packets in my case (from the cell network) are not = encapsulated in ethernet. The TAP driver in Linux is named somewhat = confusingly, because it has nothing to do with "ethernet taps". The TAP = driver provides a way to emulate an ethernet interface in user-land = software. >=20 > I believe what you are thinking of something more along the lines of = iptable's NFQUEUE target, which can take a packet and pass it to = userspace before processing it locally. That could be used to share the = same IPv6 address between the CLAT function and the host. OK, You must be right. (I am not specialist of Linux myself.) > It would be tricky to seperate native v6 traffic from the phone to = the PLAT prefix (an application that can use DNS64) and CLAT traffic, = but mostly possible by reserving port ranges. Not need to mingle with port ranges: CLAT traffic is easily recognizable = by remote IPV6 addresses starting with the NAT64 prefix. RD >=20 > But I still don't see the value that this added complexity brings. = Why all this work to avoid proxy ND? From fred@cisco.com Fri Apr 20 14:36:31 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A1EC21F8570 for ; Fri, 20 Apr 2012 14:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.627 X-Spam-Level: X-Spam-Status: No, score=-110.627 tagged_above=-999 required=5 tests=[AWL=-0.028, 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 2mYJeUeJc-iU for ; Fri, 20 Apr 2012 14:36:30 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id B8D8821F8549 for ; Fri, 20 Apr 2012 14:36:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=826; q=dns/txt; s=iport; t=1334957790; x=1336167390; h=from:subject:date:references:to:message-id:mime-version: content-transfer-encoding; bh=otxfX6ix8KqD1i5iCvvDr5L06tL/mrssN2kG4vL8g7Q=; b=ZF3oHyYYw/JL0PsQG6mvXMKWksI8bcENuK01IWRqJ9wWAK7Fm3jD5T+5 MlmuPKfXJV4ebhgAEkPMG+9SaC0jGnRmQiy9bDDSIoi3Gs7rfvZS0ABOy aQPW4KA/E9XneT53yWHzGRrNVLv3OtbTg7MOP9eSp2byGhQp1L+aj9rEP c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJvVkU+rRDoJ/2dsb2JhbABEsTyBB4IJAQEBAwEBAQEPAScPJRALHAMBAi8nJgIIBhMJGYdoBAybAKAhkEpjBIhjjRaFdIhggWmDBw X-IronPort-AV: E=Sophos;i="4.75,455,1330905600"; d="scan'208";a="41414729" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 20 Apr 2012 21:36:30 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q3KLaOCf013798 for ; Fri, 20 Apr 2012 21:36:30 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Fri, 20 Apr 2012 14:36:30 -0700 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Fri, 20 Apr 2012 14:36:30 -0700 From: Fred Baker Date: Fri, 20 Apr 2012 14:36:01 -0700 References: <13205C286662DE4387D9AF3AC30EF456D76A76104A@EMBX01-WF.jnpr.net> To: IPv6 Operations 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: [OPS-AREA] OPS Area Office Hours X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 21:36:31 -0000 Begin forwarded message: > From: Ronald Bonica > Date: April 20, 2012 9:37:42 AM PDT > To: "ops-area@ietf.org" , "ops-chairs@ietf.org" = > Subject: [OPS-AREA] OPS Area Office Hours >=20 > Folks, >=20 > Benoit and I would like to make ourselves available for office hours = every other week. A schedule of office hours is posted at the following = URL: >=20 > - https://svn.tools.ietf.org/area/ops/trac/wiki/OfficeHours >=20 > Feel free to share this information with your WGs if you wish. >=20 > -------------------------- > Ron Bonica > vcard: www.bonica.org/ron/ronbonica.vcf >=20 > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www.ietf.org/mailman/listinfo/ops-area From dan-v6ops@drown.org Fri Apr 20 15:50:37 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D58C511E8088 for ; Fri, 20 Apr 2012 15:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.375 X-Spam-Level: X-Spam-Status: No, score=-2.375 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id llMmncGET9rm for ; Fri, 20 Apr 2012 15:50:37 -0700 (PDT) Received: from vps3.drown.org (vps3.drown.org [IPv6:2600:3c00::f03c:91ff:fedf:5654]) by ietfa.amsl.com (Postfix) with ESMTP id 805F011E8086 for ; Fri, 20 Apr 2012 15:50:37 -0700 (PDT) Received: by vps3.drown.org (Postfix, from userid 48) id 6FBFDC16E; Fri, 20 Apr 2012 18:50:36 -0400 (EDT) Received: from fan.aus.datapipe.net (fan.aus.datapipe.net [2001:1938:1b2:2:7aac:c0ff:fe97:ce69]) by mail.drown.org (Horde Framework) with HTTP; Fri, 20 Apr 2012 17:50:36 -0500 Message-ID: <20120420175036.70482p5axgf81lq8@mail.drown.org> Date: Fri, 20 Apr 2012 17:50:36 -0500 From: Dan Drown To: =?utf-8?b?UsOpbWkg?= =?utf-8?b?RGVzcHLDqXM=?= , v6ops WG References: <20120417065542.31115.95082.idtracker@ietfa.amsl.com> <20120417160010kawashimam@mail.jp.nec.com> <56E2AD61-1C91-4889-914A-353793FCBE43@laposte.net> <20120419121044.17531mk1mv19abr4@mail.drown.org> <0646611B-5594-40EA-A2C4-F99CBA734024@laposte.net> <20120419181813.4524701l3gkq5zks@mail.drown.org> <45ABAD31-C265-4D63-82E2-3DE6F59B80C0@laposte.net> <20120420104246.1432746csfcrdqo8@mail.drown.org> <20120420122715.1702279xh7eynpus@mail.drown.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.3.9) Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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, 20 Apr 2012 22:50:37 -0000 Quoting R=C3=A9mi Despr=C3=A9s : > Not need to mingle with port ranges: CLAT traffic is easily =20 > recognizable by remote IPV6 addresses starting with the NAT64 prefix. This would be correct if it weren't for DNS64. Traffic from regular =20 applications can send traffic directly to the PLAT prefix from the =20 phone's IPv6 address (for example: typing "http://ipv4.google.com" in =20 a web browser). This traffic does not go through CLAT, and should not =20 conflict with CLAT traffic. On a side note, I apologize for my mail client mangling your name. It =20 was on the default character set, which did a poor job with unicode. =20 I believe it to be fixed now. From wwwrun@rfc-editor.org Fri Apr 20 16:20:18 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8042121E8039; Fri, 20 Apr 2012 16:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.274 X-Spam-Level: X-Spam-Status: No, score=-102.274 tagged_above=-999 required=5 tests=[AWL=0.326, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ryZXhPOdXRHw; Fri, 20 Apr 2012 16:20:18 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 3CED021E8064; Fri, 20 Apr 2012 16:20:17 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id A263EB1E017; Fri, 20 Apr 2012 16:19:07 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20120420231907.A263EB1E017@rfc-editor.org> Date: Fri, 20 Apr 2012 16:19:07 -0700 (PDT) Cc: v6ops@ietf.org, rfc-editor@rfc-editor.org Subject: [v6ops] RFC 6589 on Considerations for Transitioning Content to IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 23:20:18 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6589 Title: Considerations for Transitioning Content to IPv6 Author: J. Livingood Status: Informational Stream: IETF Date: April 2012 Mailbox: jason_livingood@cable.comcast.com Pages: 27 Characters: 68822 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-11.txt URL: http://www.rfc-editor.org/rfc/rfc6589.txt 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. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the IPv6 Operations Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From despres.remi@laposte.net Fri Apr 20 22:45:27 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CEB421E800F for ; Fri, 20 Apr 2012 22:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KOBb1nJ-goBF for ; Fri, 20 Apr 2012 22:45:26 -0700 (PDT) Received: from smtpout.laposte.net (smtpout5.laposte.net [193.253.67.230]) by ietfa.amsl.com (Postfix) with ESMTP id CE0E511E8096 for ; Fri, 20 Apr 2012 22:45:20 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8510-out with ME id 0VlH1j00937Y3f403VlH5T; Sat, 21 Apr 2012 07:45:19 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <20120420175036.70482p5axgf81lq8@mail.drown.org> Date: Sat, 21 Apr 2012 07:45:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120417065542.31115.95082.idtracker@ietfa.amsl.com> <20120417160010kawashimam@mail.jp.nec.com> <56E2AD61-1C91-4889-914A-353793FCBE43@laposte.net> <20120419121044.17531mk1mv19abr4@mail.drown.org> <0646611B-5594-40EA-A2C4-F99CBA734024@laposte.net> <20120419181813.4524701l3gkq5zks@mail.drown.org> <45ABAD31-C265-4D63-82E2-3DE6F59B80C0@laposte.net> <20120420104246.1432746csfcrdqo8@mail.drown.org> <20120420122715.1702279xh7eynpus@mail.drown.org> <20120420175036.70482p5axgf81lq8@mail.drown.org> To: Dan Drown X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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, 21 Apr 2012 05:45:27 -0000 Le 2012-04-21 =E0 00:50, Dan Drown a =E9crit : > Quoting R=E9mi Despr=E9s : >> Not need to mingle with port ranges: CLAT traffic is easily = recognizable by remote IPV6 addresses starting with the NAT64 prefix. >=20 > This would be correct if it weren't for DNS64. Traffic from regular = applications can send traffic directly to the PLAT prefix from the = phone's IPv6 address (for example: typing "http://ipv4.google.com" in a = web browser). This traffic does not go through CLAT, and should not = conflict with CLAT traffic. Why would this be? DNS64 needs to know the NAT64 prefix for AAAA synthesis, and must be = internally configured with this prefix, but its address doesn't start = with this prefix. RD=20 From despres.remi@laposte.net Sat Apr 21 01:50:23 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86E3B21F8594 for ; Sat, 21 Apr 2012 01:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.868 X-Spam-Level: X-Spam-Status: No, score=-1.868 tagged_above=-999 required=5 tests=[AWL=-0.168, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SotxKhv4Mz1p for ; Sat, 21 Apr 2012 01:50:18 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 8A42D21F855D for ; Sat, 21 Apr 2012 01:50:15 -0700 (PDT) Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id DAF41940192; Sat, 21 Apr 2012 10:50:06 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <20120420175036.70482p5axgf81lq8@mail.drown.org> Date: Sat, 21 Apr 2012 10:50:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2950A57B-DA87-4641-8540-8972F5C437CF@laposte.net> References: <20120417065542.31115.95082.idtracker@ietfa.amsl.com> <20120417160010kawashimam@mail.jp.nec.com> <56E2AD61-1C91-4889-914A-353793FCBE43@laposte.net> <20120419121044.17531mk1mv19abr4@mail.drown.org> <0646611B-5594-40EA-A2C4-F99CBA734024@laposte.net> <20120419181813.4524701l3gkq5zks@mail.drown.org> <45ABAD31-C265-4D63-82E2-3DE6F59B80C0@laposte.net> <20120420104246.1432746csfcrdqo8@mail.drown.org> <20120420122715.1702279xh7eynpus@mail.drown.org> <20120420175036.70482p5axgf81lq8@mail.drown.org> To: Dan Drown X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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, 21 Apr 2012 08:50:23 -0000 Dan, Sorry for having answered too hastily (copied mail below). You are right: some incoming packets in CLAT nodes may come from the = NAT64 without being destined to the CLAT. (Destined to an IPv6 = application having obtained a AAAA from a DNS64). Thank you for pointing this out. Now, avoiding ND proxy on two addresses REMAINS POSSIBLE. - It is sufficient that a CLAT interface ID be reserved by IETF/IANA (an = ID that no host may legitimately use). - This can be done, in compliance with RFC 5342, with a modified-EUI-64 = ID based on IANA's OUI. - Proposed ID value is 02-00-5E-10--00-00-00-00 (in the available range = of www.iana.org/assignments/ethernet-numbers for this). Experiments can start immediately and, according to RFC 5342, IANA = registration needs only that: - Sec. 2.2: it "must be documented in an Internet Draft". - Sec. 5.1: after a "light sanity check", an expert appointed by the = IESG has no objection. Then: - Proxying the CLAT address on the LAN interface is no longer needed. - ISPs can, by means of this interface ID, recognize doubly-translated = packets (e.g. for traffic monitoring, as mentioned in section 8 of the = 464XLAT draft-02). =20 Would you agree on this? =20 Regards, RD > De : R=E9mi Despr=E9s > Date : 2012-04-21 07:45 > =C0 : Dan Drown > Cc : v6ops WG > Objet : R=E9p : [v6ops] I-D Action: draft-ietf-v6ops-464xlat-02.txt >=20 >=20 > Le 2012-04-21 =E0 00:50, Dan Drown a =E9crit : >=20 >> Quoting R=E9mi Despr=E9s : >>> Not need to mingle with port ranges: CLAT traffic is easily = recognizable by remote IPV6 addresses starting with the NAT64 prefix. >>=20 >> This would be correct if it weren't for DNS64. Traffic from regular = applications can send traffic directly to the PLAT prefix from the = phone's IPv6 address (for example: typing "http://ipv4.google.com" in a = web browser). This traffic does not go through CLAT, and should not = conflict with CLAT traffic. >=20 > Why would this be? > DNS64 needs to know the NAT64 prefix for AAAA synthesis, and must be = internally configured with this prefix, but its address doesn't start = with this prefix. >=20 > RD=20 From dan-v6ops@drown.org Sat Apr 21 17:20:51 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ADCE21F84E1 for ; Sat, 21 Apr 2012 17:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.36 X-Spam-Level: X-Spam-Status: No, score=-2.36 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fgY-LmSVxxai for ; Sat, 21 Apr 2012 17:20:47 -0700 (PDT) Received: from vps3.drown.org (vps3.drown.org [IPv6:2600:3c00::f03c:91ff:fedf:5654]) by ietfa.amsl.com (Postfix) with ESMTP id 06C4721F84CF for ; Sat, 21 Apr 2012 17:20:46 -0700 (PDT) Received: by vps3.drown.org (Postfix, from userid 48) id 22554C16E; Sat, 21 Apr 2012 20:20:46 -0400 (EDT) Received: from 2001:470:b88f:c8f6:f56f:33a4:de08:afe7 ([2001:470:b88f:c8f6:f56f:33a4:de08:afe7]) by mail.drown.org (Horde Framework) with HTTP; Sat, 21 Apr 2012 19:20:46 -0500 Message-ID: <20120421192046.99723kgkv9zjcq9w@mail.drown.org> Date: Sat, 21 Apr 2012 19:20:46 -0500 From: Dan Drown To: =?utf-8?b?UsOpbWkg?= =?utf-8?b?RGVzcHLDqXM=?= , v6ops WG References: <20120417065542.31115.95082.idtracker@ietfa.amsl.com> <20120417160010kawashimam@mail.jp.nec.com> <56E2AD61-1C91-4889-914A-353793FCBE43@laposte.net> <20120419121044.17531mk1mv19abr4@mail.drown.org> <0646611B-5594-40EA-A2C4-F99CBA734024@laposte.net> <20120419181813.4524701l3gkq5zks@mail.drown.org> <45ABAD31-C265-4D63-82E2-3DE6F59B80C0@laposte.net> <20120420104246.1432746csfcrdqo8@mail.drown.org> <20120420122715.1702279xh7eynpus@mail.drown.org> <20120420175036.70482p5axgf81lq8@mail.drown.org> <2950A57B-DA87-4641-8540-8972F5C437CF@laposte.net> In-Reply-To: <2950A57B-DA87-4641-8540-8972F5C437CF@laposte.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.3.9) Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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: Sun, 22 Apr 2012 00:20:51 -0000 Quoting R=C3=A9mi Despr=C3=A9s : > Now, avoiding ND proxy on two addresses REMAINS POSSIBLE. > - It is sufficient that a CLAT interface ID be reserved by IETF/IANA =20 > (an ID that no host may legitimately use). > - This can be done, in compliance with RFC 5342, with a =20 > modified-EUI-64 ID based on IANA's OUI. > - Proposed ID value is 02-00-5E-10--00-00-00-00 (in the available =20 > range of www.iana.org/assignments/ethernet-numbers for this). ... > Would you agree on this? This sounds good to me. Using IANA's EUI-64 ID would avoid conflicts =20 with possible interface IDs on v6 tethering (as long as a unique =20 EUI-64 address is assigned to clat). Since this is just a config file =20 change, I'll go ahead and use it. Thank you, Dan From joelja@bogus.com Sun Apr 22 00:33:22 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46E2521F85A2 for ; Sun, 22 Apr 2012 00:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.8 X-Spam-Level: X-Spam-Status: No, score=-101.8 tagged_above=-999 required=5 tests=[AWL=0.199, 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 Oa34a+ROy46a for ; Sun, 22 Apr 2012 00:33:21 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id C25C421F8541 for ; Sun, 22 Apr 2012 00:33:21 -0700 (PDT) Received: from Joels-MacBook-Pro.local (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q3M7XJHe023067 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sun, 22 Apr 2012 07:33:20 GMT (envelope-from joelja@bogus.com) Message-ID: <4F93B43F.7030006@bogus.com> Date: Sun, 22 Apr 2012 00:33:19 -0700 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Nick Hilliard References: <4F8DAA5E.3070007@bogus.com> <4F8E695C.3050705@gmail.com> <4F8E7888.8080102@inex.ie> In-Reply-To: <4F8E7888.8080102@inex.ie> 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]); Sun, 22 Apr 2012 07:33:21 +0000 (UTC) Cc: v6ops@ietf.org Subject: Re: [v6ops] In the vein of of the icp/dc 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: Sun, 22 Apr 2012 07:33:22 -0000 On 4/18/12 01:17 , Nick Hilliard wrote: > On 18/04/2012 09:12, Brian E Carpenter wrote: >> It's fine work IMHO, but I expect that most DC operators will >> not want to jump in at the deep end in this way. > > I like the idea too. But hosting operators will be very cagey about > deploying client-side ipv6 when there is no clear precedent for operating > reliable ipv6-only services, where there is an absence of good quality > ipv6-only monitoring tools, So I have to take issue with that statement. the instrumentation I use for v6 enabled assets in datacenters is by-in-large the same as I use for ipv4. the gap analysis is beginging to look rather narrow in fact. > and where many of the software development > companies are still saying "we'll make our products ipv6 aware when we get > some customer demand". excluding them from consideration tends to get the message across... > Nick > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From joelja@bogus.com Sun Apr 22 00:44:45 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A354921F8652 for ; Sun, 22 Apr 2012 00:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.822 X-Spam-Level: X-Spam-Status: No, score=-101.822 tagged_above=-999 required=5 tests=[AWL=0.177, 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 dC5BL4aEa0J5 for ; Sun, 22 Apr 2012 00:44:45 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 17E1821F864B for ; Sun, 22 Apr 2012 00:44:45 -0700 (PDT) Received: from Joels-MacBook-Pro.local (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q3M7ihV3023258 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sun, 22 Apr 2012 07:44:44 GMT (envelope-from joelja@bogus.com) Message-ID: <4F93B6EB.7080900@bogus.com> Date: Sun, 22 Apr 2012 00:44:43 -0700 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Brian E Carpenter References: <4F8DAA5E.3070007@bogus.com> <4F8E695C.3050705@gmail.com> In-Reply-To: <4F8E695C.3050705@gmail.com> 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]); Sun, 22 Apr 2012 07:44:44 +0000 (UTC) Cc: IPv6 Ops WG Subject: Re: [v6ops] In the vein of of the icp/dc 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: Sun, 22 Apr 2012 07:44:45 -0000 On 4/18/12 00:12 , Brian E Carpenter wrote: > It's fine work IMHO, but I expect that most DC operators will > not want to jump in at the deep end in this way. Having a little trouble making internal numbering plan fit in a /12 per site. Hakes alternatives oddly compelling... > Regards > Brian > > On 2012-04-17 18:37, Joel jaeggli wrote: >> This was presented at ripe64. >> >> https://ripe64.ripe.net/presentations/67-20120417-RIPE64-The_Case_for_IPv6_Only_Data_Centres.pdf >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > From brian.e.carpenter@gmail.com Sun Apr 22 00:48:25 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C9CA21F865A for ; Sun, 22 Apr 2012 00:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.664 X-Spam-Level: X-Spam-Status: No, score=-100.664 tagged_above=-999 required=5 tests=[AWL=-0.832, BAYES_20=-0.74, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGen+jO06HYC for ; Sun, 22 Apr 2012 00:48:24 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 49DD021F8653 for ; Sun, 22 Apr 2012 00:48:24 -0700 (PDT) Received: by wibhq7 with SMTP id hq7so1520336wib.13 for ; Sun, 22 Apr 2012 00:48:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=jidYyrmQtU4D7L1KpRBlLWu98Yvlig1gPkxI4DSjsD8=; b=hPAKpNA9iP81n/UQFp21wqhr6UO3qc2obUBgGa6JKYKUau5p+WNRZa5GN7FTli7IvH RHD6OrprHy/NqrYbBzOammpO/ZHAHYz6wZ16nYxW+9qHO0HhLT9lbU3qmDpoL9pinGLJ jdmjEnwn1Tdw8hZtoUg46/xOAEwZyiiJMg95IY6ua8/wKWckxJneh4QA9DRG+TyZsyQ8 WGwT56KzV5nb0nps2F0eYdU+I8f59y+3hMN1AbMSQE0yfn5dZcIQoQVzw7y/dtmc/aqZ HS/0RgAFUp0+8HRLZThirb5HVqGh3C2cJMpiGGc3IVSfCzsFpv2JliNn4MqhpQKKsXyf 3Wtg== Received: by 10.180.95.129 with SMTP id dk1mr13140214wib.3.1335080903347; Sun, 22 Apr 2012 00:48:23 -0700 (PDT) Received: from [192.168.1.64] (host-2-102-216-233.as13285.net. [2.102.216.233]) by mx.google.com with ESMTPS id fn2sm19351531wib.0.2012.04.22.00.48.21 (version=SSLv3 cipher=OTHER); Sun, 22 Apr 2012 00:48:22 -0700 (PDT) Message-ID: <4F93B7C3.7010606@gmail.com> Date: Sun, 22 Apr 2012 08:48:19 +0100 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: <4F8DAA5E.3070007@bogus.com> <4F8E695C.3050705@gmail.com> <4F93B6EB.7080900@bogus.com> In-Reply-To: <4F93B6EB.7080900@bogus.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] In the vein of of the icp/dc 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: Sun, 22 Apr 2012 07:48:25 -0000 On 2012-04-22 08:44, Joel jaeggli wrote: > On 4/18/12 00:12 , Brian E Carpenter wrote: >> It's fine work IMHO, but I expect that most DC operators will >> not want to jump in at the deep end in this way. > > Having a little trouble making internal numbering plan fit in a /12 per > site. Hakes alternatives oddly compelling... Is the small size of IPv4 subnets also an issue? /64 is approximately infinity, after all. Brian From joelja@bogus.com Sun Apr 22 01:10:59 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A61221F856F for ; Sun, 22 Apr 2012 01:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.14 X-Spam-Level: X-Spam-Status: No, score=-102.14 tagged_above=-999 required=5 tests=[AWL=0.459, 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 3qLwKTZO5-UQ for ; Sun, 22 Apr 2012 01:10:58 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id B7F0421F8527 for ; Sun, 22 Apr 2012 01:10:56 -0700 (PDT) Received: from Joels-MacBook-Pro.local (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q3M8AsNh023685 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sun, 22 Apr 2012 08:10:55 GMT (envelope-from joelja@bogus.com) Message-ID: <4F93BD0E.5010808@bogus.com> Date: Sun, 22 Apr 2012 01:10:54 -0700 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Brian E Carpenter References: <4F8DAA5E.3070007@bogus.com> <4F8E695C.3050705@gmail.com> <4F93B6EB.7080900@bogus.com> <4F93B7C3.7010606@gmail.com> In-Reply-To: <4F93B7C3.7010606@gmail.com> 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]); Sun, 22 Apr 2012 08:10:55 +0000 (UTC) Cc: IPv6 Ops WG Subject: Re: [v6ops] In the vein of of the icp/dc 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: Sun, 22 Apr 2012 08:10:59 -0000 On 4/22/12 00:48 , Brian E Carpenter wrote: > On 2012-04-22 08:44, Joel jaeggli wrote: >> On 4/18/12 00:12 , Brian E Carpenter wrote: >>> It's fine work IMHO, but I expect that most DC operators will >>> not want to jump in at the deep end in this way. >> >> Having a little trouble making internal numbering plan fit in a /12 per >> site. Makes alternatives oddly compelling... > > Is the small size of IPv4 subnets also an issue? /64 is > approximately infinity, after all. When you are trying to conserve bits, the number of hosts per subnet drives the mask size directly which as you can imagine can become costly in a number of ways. I'm not sure I'd characterize a /64 as infinite, but you're not going to need to expand it on the basis of host count. > Brian > From nick@inex.ie Sun Apr 22 04:14:30 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 183B421F856A for ; Sun, 22 Apr 2012 04:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id otlBP2P7eOiy for ; Sun, 22 Apr 2012 04:14:29 -0700 (PDT) Received: from mail.acquirer.com (mail.acquirer.com [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 4E92721F854A for ; Sun, 22 Apr 2012 04:14:29 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from crumpet.foobar.org ([IPv6:2001:4d68:2002:100:8568:923d:7948:1fcf]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id q3MBE3es028638 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 22 Apr 2012 12:14:09 +0100 (IST) (envelope-from nick@inex.ie) Message-ID: <4F93E809.6040607@inex.ie> Date: Sun, 22 Apr 2012 12:14:17 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Joel jaeggli References: <4F8DAA5E.3070007@bogus.com> <4F8E695C.3050705@gmail.com> <4F8E7888.8080102@inex.ie> <4F93B43F.7030006@bogus.com> In-Reply-To: <4F93B43F.7030006@bogus.com> X-Enigmail-Version: 1.4.1 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] In the vein of of the icp/dc 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: Sun, 22 Apr 2012 11:14:30 -0000 On 22/04/2012 08:33, Joel jaeggli wrote: > excluding them from consideration tends to get the message across... I agree in theory - and include ipv6 feature parity in all product evaluations, and whine/bitch at vendors who have a lax ipv6 attitude - but excluding them from consideration also tends to put the DC operator at a competitive disadvantage as it removes product choice for ipv4 services. This can have a direct impact on revenue, customer retention and all that. IOW, we're not there yet. For sure, we're a lot better now than we were a couple of years ago, but for many areas/products/services the disparity is still large enough that ipv6-only services are not a viable option. Nick From joelja@bogus.com Sun Apr 22 10:29:21 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73AEC21F85D0 for ; Sun, 22 Apr 2012 10:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.182 X-Spam-Level: X-Spam-Status: No, score=-102.182 tagged_above=-999 required=5 tests=[AWL=0.417, 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 vYzeQZ4iXYcR for ; Sun, 22 Apr 2012 10:29:20 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id C125F21F85CC for ; Sun, 22 Apr 2012 10:29:20 -0700 (PDT) Received: from Joels-MacBook-Pro.local (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q3MHTIhp033221 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sun, 22 Apr 2012 17:29:20 GMT (envelope-from joelja@bogus.com) Message-ID: <4F943FEE.4030705@bogus.com> Date: Sun, 22 Apr 2012 10:29:18 -0700 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Nick Hilliard References: <4F8DAA5E.3070007@bogus.com> <4F8E695C.3050705@gmail.com> <4F8E7888.8080102@inex.ie> <4F93B43F.7030006@bogus.com> <4F93E809.6040607@inex.ie> In-Reply-To: <4F93E809.6040607@inex.ie> 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]); Sun, 22 Apr 2012 17:29:20 +0000 (UTC) Cc: v6ops@ietf.org Subject: Re: [v6ops] In the vein of of the icp/dc 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: Sun, 22 Apr 2012 17:29:21 -0000 On 4/22/12 04:14 , Nick Hilliard wrote: > On 22/04/2012 08:33, Joel jaeggli wrote: >> excluding them from consideration tends to get the message across... > > I agree in theory - and include ipv6 feature parity in all product > evaluations, and whine/bitch at vendors who have a lax ipv6 attitude - but > excluding them from consideration also tends to put the DC operator at a > competitive disadvantage as it removes product choice for ipv4 services. 7 or 8 years ago, people would laugh when I'd put that in an RFP. It ceased being funny a long time ago. Today we have to build, instrument and manage IPV6 and IPV4 networks and we expect to have a lot more of the former if we're lucky or smart enough to stay in business. The tools have to keep up. > This can have a direct impact on revenue, customer retention and all that. > IOW, we're not there yet. For sure, we're a lot better now than we were a > couple of years ago, but for many areas/products/services the disparity is > still large enough that ipv6-only services are not a viable option. > > Nick > From fred@cisco.com Sun Apr 22 11:01:09 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 833C921F856D for ; Sun, 22 Apr 2012 11:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.494 X-Spam-Level: X-Spam-Status: No, score=-100.494 tagged_above=-999 required=5 tests=[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 pEZ6BybMDYXw for ; Sun, 22 Apr 2012 11:01:08 -0700 (PDT) Received: from hsia.quadriga.com (unknown [195.65.225.81]) by ietfa.amsl.com (Postfix) with ESMTP id 72AF621F8564 for ; Sun, 22 Apr 2012 11:01:08 -0700 (PDT) Received: from [192.168.13.122] (helo=Freds-Computer.local) by hsia.quadriga.com with esmtp (Exim 3.34 #1) id 1SM15q-0007RQ-01; Sun, 22 Apr 2012 20:01:02 +0200 Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Sun, 22 Apr 2012 20:01:02 +0200 X-PGP-Universal: processed; by Freds-Computer.local on Sun, 22 Apr 2012 20:01:02 +0200 From: Fred Baker Date: Sun, 22 Apr 2012 20:00:05 +0200 Message-Id: <54469FB9-D118-4157-B9D6-8F52F7F96002@cisco.com> To: v6ops@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Content-Type: multipart/alternative; boundary=Apple-Mail-4-328119775 Cc: v6ops-chairs@tools.ietf.org, Ron Bonica Subject: [v6ops] draft-ietf-v6ops-ra-guard-implementation WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Apr 2012 18:01:09 -0000 --Apple-Mail-4-328119775 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This is to initiate a two week working group last call of = draft-ietf-v6ops-ra-guard-implementation. Please read it now. If you = find nits (spelling errors, minor suggested wording changes, etc), = comment to the authors; if you find greater issues, such as disagreeing = with a statement or finding additional issues that need to be addressed, = please post your comments to the list. We are looking specifically for comments on the importance of the = document as well as its content. If you have read the document and = believe it to be of operational utility, that is also an important = comment to make.= --Apple-Mail-4-328119775 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii This is to initiate a two week working = group last call of draft-ietf-v6ops-ra-guard-implementation. Please read = it now. If you find nits (spelling errors, minor suggested wording = changes, etc), comment to the authors; if you find greater issues, such = as disagreeing with a statement or finding additional issues that need = to be addressed, please post your comments to the = list.

We are looking specifically for comments on the = importance of the document as well as its content. If you have read the = document and believe it to be of operational utility, that is also = an important comment to make.
= --Apple-Mail-4-328119775-- From nick@inex.ie Sun Apr 22 15:25:28 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95A3621F85B6 for ; Sun, 22 Apr 2012 15:25:28 -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 nAV0PCqvb4My for ; Sun, 22 Apr 2012 15:25:28 -0700 (PDT) Received: from mail.acquirer.com (mail.acquirer.com [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id DF0AF21F85AA for ; Sun, 22 Apr 2012 15:25:27 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from crumpet.foobar.org (twinkie.foobar.org [87.192.56.84]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id q3MMOuHk034111 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 22 Apr 2012 23:25:01 +0100 (IST) (envelope-from nick@inex.ie) Message-ID: <4F948546.8040205@inex.ie> Date: Sun, 22 Apr 2012 23:25:10 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Fred Baker References: <54469FB9-D118-4157-B9D6-8F52F7F96002@cisco.com> In-Reply-To: <54469FB9-D118-4157-B9D6-8F52F7F96002@cisco.com> X-Enigmail-Version: 1.4.1 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-ra-guard-implementation WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Apr 2012 22:25:28 -0000 On 22/04/2012 19:00, Fred Baker wrote: > This is to initiate a two week working group last call of > draft-ietf-v6ops-ra-guard-implementation. Please read it now. If you find > nits (spelling errors, minor suggested wording changes, etc), comment to > the authors; if you find greater issues, such as disagreeing with a > statement or finding additional issues that need to be addressed, please > post your comments to the list. reading back over this, I wonder would it be useful to make a recommendation to vendors to implement some form of logging for dropped packets so that operators can choose to have visibility into this problem on their networks. Silently dropping packets is all very well, but many operators like to feel that if a packet is dropped, they should know about it. As a tiny nit, the word "basic" appears in consecutive sentences in the second paragraph of section 1: "The basic concept..." and "The most basic filtering". As an L2 IXP operator, I like this draft very much. It is simply a matter of time before someone writes a trivial script to mount a DoS attack using RAs + v6 options, and even though no IXP participant should ever listen to ipv6 RAs, operator error happens from time to time. Nick From joelja@bogus.com Sun Apr 22 17:50:30 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04DE521F85B5 for ; Sun, 22 Apr 2012 17:50:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.916 X-Spam-Level: X-Spam-Status: No, score=-101.916 tagged_above=-999 required=5 tests=[AWL=0.083, 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 GAhK1d7xfmSf for ; Sun, 22 Apr 2012 17:50:29 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 6F68E21F85A8 for ; Sun, 22 Apr 2012 17:50:28 -0700 (PDT) Received: from Joels-MacBook-Pro.local (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q3N0oNJV040439 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Mon, 23 Apr 2012 00:50:24 GMT (envelope-from joelja@bogus.com) Message-ID: <4F94A74F.6090409@bogus.com> Date: Sun, 22 Apr 2012 17:50:23 -0700 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Nick Hilliard References: <54469FB9-D118-4157-B9D6-8F52F7F96002@cisco.com> <4F948546.8040205@inex.ie> In-Reply-To: <4F948546.8040205@inex.ie> 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, 23 Apr 2012 00:50:25 +0000 (UTC) Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-ra-guard-implementation WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 00:50:30 -0000 On 4/22/12 15:25 , Nick Hilliard wrote: > On 22/04/2012 19:00, Fred Baker wrote: >> This is to initiate a two week working group last call of >> draft-ietf-v6ops-ra-guard-implementation. Please read it now. If you find >> nits (spelling errors, minor suggested wording changes, etc), comment to >> the authors; if you find greater issues, such as disagreeing with a >> statement or finding additional issues that need to be addressed, please >> post your comments to the list. > > reading back over this, I wonder would it be useful to make a > recommendation to vendors to implement some form of logging for dropped > packets so that operators can choose to have visibility into this problem > on their networks. Silently dropping packets is all very well, but many > operators like to feel that if a packet is dropped, they should know about it. implementing a drop counter on what's essentially a firewall rule seems like a good idea, but also an implementation detail. if there's nowhere to log it and nobody to report it to it's not very useful to count them. if there are either of those things then yeah it's certainly worthwhile. > As a tiny nit, the word "basic" appears in consecutive sentences in the > second paragraph of section 1: "The basic concept..." and "The most basic > filtering". > > As an L2 IXP operator, I like this draft very much. It is simply a matter > of time before someone writes a trivial script to mount a DoS attack using > RAs + v6 options, and even though no IXP participant should ever listen to > ipv6 RAs, operator error happens from time to time. Even today inadvertent 6to4 deployments attack consumer networks including those without ipv6 deployed at a frequency that makes this useful hygiene. > Nick > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From joelja@bogus.com Sun Apr 22 18:01:07 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A75021F847D for ; Sun, 22 Apr 2012 18:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.773 X-Spam-Level: X-Spam-Status: No, score=-101.773 tagged_above=-999 required=5 tests=[AWL=-0.074, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c98m7heANucB for ; Sun, 22 Apr 2012 18:01:06 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id CB58221F8475 for ; Sun, 22 Apr 2012 18:01:06 -0700 (PDT) Received: from Joels-MacBook-Pro.local (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q3N1147i040644 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Mon, 23 Apr 2012 01:01:05 GMT (envelope-from joelja@bogus.com) Message-ID: <4F94A9D0.5040809@bogus.com> Date: Sun, 22 Apr 2012 18:01:04 -0700 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= References: <7E1BD96D-E7EC-4C78-B382-66F0F694DAA4@laposte.net> <1825062D-D4EB-4310-A2BA-8B8F3870B9B4@laposte.net> <22BD6607-5DEC-48F3-B2E5-DCEECC9EF643@laposte.net> <986EAD24-4612-4AD0-B366-012BA0B3751C@laposte.net> <5258F2DA-D61A-4327-B7FC-2BD67743C994@laposte.net> <4F8D17AD.7080907@gmail.com> <20966399-05D0-4294-B9EC-9AA55DEB390D@laposte.net> <4F8D83F4.80908@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Mon, 23 Apr 2012 01:01:05 +0000 (UTC) Cc: v6ops WG , Cameron Byrne Subject: Re: [v6ops] A way forward for 464XLAT - using BIH X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 01:01:07 -0000 On 4/17/12 08:02 , Rémi Després wrote: > > Le 2012-04-17 à 16:53, Brian E Carpenter a écrit : > >> >> Bonjour Rémi, >> >> On 2012-04-17 09:51, Rémi Després wrote: >> ... >>> Thus, although Network 2 is IPv6 only, its servers remain reachable by some IPv4-only clients. >>> This contributes to facilitate commercial deployments of IPv6-only networks, an objective of IETF AFAIK. >> >> Really? As far as I know we have always suggested that dual stack was >> the preferred deployment model. Certainly if I was a commercial >> application layer provider, I would not consider using an IPv6-only >> ISP for one moment, because that would disadvantage my IPv4 customers. >> >> Note, this is not a comment on the technology, but on whether there's >> a real operational use case today. > > The point is that all this 464XLAT discussion is in the context of IPv6-only operator networks. > My understanding is that deployments of IPv6-only networks are seriously envisaged in the context of LTE. ipv6 only pdp contexts exist today, lte or no. > RD > > > > >> >> Brian >> > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From phdgang@gmail.com Sun Apr 22 23:25:01 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B622921F85B4 for ; Sun, 22 Apr 2012 23:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.487 X-Spam-Level: X-Spam-Status: No, score=-3.487 tagged_above=-999 required=5 tests=[AWL=0.113, 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 x2aGlRrVoo9F for ; Sun, 22 Apr 2012 23:25:01 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3E6A021F8593 for ; Sun, 22 Apr 2012 23:24:58 -0700 (PDT) Received: by werb10 with SMTP id b10so8897639wer.31 for ; Sun, 22 Apr 2012 23:24:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=03x1C7MKgt4SixdJzIplBa2VFPUOJsDIRk0vfY0Fjg0=; b=DIBbC3w6c9qk5cNexlbpdWoo3uP+CPIf0e91ZlECNec6I7TObPZD5yitr5QNbw/KCL SWBSWV7x/uJ02nbRHhNePg6qA6FvPpOIbB3cIhc8hBGGgjhdRpfUXwnwef3MTWl5yNQl ELb4KtTwPsbSDGggST7OOlMU/LoCZdBnYyfIOMOarjk3DzR3r432Ah7CG0/0Y3ZZFhPB EhH4uMr/OvaOCc5x2jRXdQGAskAs46S8R8RXDkyB7N90msPEILnvFR8vuJzkFYpkM+1n awAHItyfNbMX4/XITFXnC+5Wv+1qozetCwE0pcAjBYrRaNOODSB+lJ2MwQrgnYFM0HfC 8l/A== MIME-Version: 1.0 Received: by 10.180.101.136 with SMTP id fg8mr18320856wib.4.1335162297280; Sun, 22 Apr 2012 23:24:57 -0700 (PDT) Received: by 10.180.106.38 with HTTP; Sun, 22 Apr 2012 23:24:57 -0700 (PDT) In-Reply-To: <20120420104246.1432746csfcrdqo8@mail.drown.org> References: <20120417065542.31115.95082.idtracker@ietfa.amsl.com> <20120417160010kawashimam@mail.jp.nec.com> <56E2AD61-1C91-4889-914A-353793FCBE43@laposte.net> <20120419121044.17531mk1mv19abr4@mail.drown.org> <0646611B-5594-40EA-A2C4-F99CBA734024@laposte.net> <20120419181813.4524701l3gkq5zks@mail.drown.org> <45ABAD31-C265-4D63-82E2-3DE6F59B80C0@laposte.net> <20120420104246.1432746csfcrdqo8@mail.drown.org> Date: Mon, 23 Apr 2012 14:24:57 +0800 Message-ID: From: GangChen To: Dan Drown Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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, 23 Apr 2012 06:25:02 -0000 Hello Dan Drown, 2012/4/20, Dan Drown : > Quoting R=E9mi Despr=E9s : >> Two interfaces having the same IPv6 address >> (2607:fb90:800:68c::eae6:901 in this case) would break the RFC4291 >> model which has: >> "An IPv6 unicast address refers to a single interface." > > I do not see the harm in re-using a point to point interface's address > (which is configured as a /128) on one ethernet interface. Wondering to know which interface (i.e. cell int or wifi tethering int) should be selected if applications on the phone are going to send packages in the case of re-using same IPv6 address BRs Gang From despres.remi@laposte.net Mon Apr 23 00:58:29 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5312B21F85C7 for ; Mon, 23 Apr 2012 00:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.167 X-Spam-Level: X-Spam-Status: No, score=-2.167 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lC1egBerQI2l for ; Mon, 23 Apr 2012 00:58:27 -0700 (PDT) Received: from smtpout.laposte.net (smtpout3.laposte.net [193.253.67.228]) by ietfa.amsl.com (Postfix) with ESMTP id 27C3B21F85C4 for ; Mon, 23 Apr 2012 00:58:26 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8506-out with ME id 1KyN1j00D37Y3f403KyPrU; Mon, 23 Apr 2012 09:58:24 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4F94A9D0.5040809@bogus.com> Date: Mon, 23 Apr 2012 09:58:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <99CF7186-379C-4670-82E5-E2DFAAA1583F@laposte.net> References: <7E1BD96D-E7EC-4C78-B382-66F0F694DAA4@laposte.net> <1825062D-D4EB-4310-A2BA-8B8F3870B9B4@laposte.net> <22BD6607-5DEC-48F3-B2E5-DCEECC9EF643@laposte.net> <986EAD24-4612-4AD0-B366-012BA0B3751C@laposte.net> <5258F2DA-D61A-4327-B7FC-2BD67743C994@laposte.net> <4F8D17AD.7080907@gmail.com> <20966399-05D0-4294-B9EC-9AA55DEB390D@laposte.net> <4F8D83F4.80908@gmail.com> <4F94A9D0.5040809@bogus.com> To: Joel jaeggli X-Mailer: Apple Mail (2.1084) Cc: v6ops WG , Cameron Byrne Subject: Re: [v6ops] A way forward for 464XLAT - using BIH X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 07:58:30 -0000 Le 2012-04-23 =E0 03:01, Joel jaeggli a =E9crit : > On 4/17/12 08:02 , R=E9mi Despr=E9s wrote: >>=20 >> Le 2012-04-17 =E0 16:53, Brian E Carpenter a =E9crit : >>=20 >>>=20 >>> Bonjour R=E9mi, >>>=20 >>> On 2012-04-17 09:51, R=E9mi Despr=E9s wrote: >>> ... >>>> Thus, although Network 2 is IPv6 only, its servers remain reachable = by some IPv4-only clients. >>>> This contributes to facilitate commercial deployments of IPv6-only = networks, an objective of IETF AFAIK. >>>=20 >>> Really? As far as I know we have always suggested that dual stack = was >>> the preferred deployment model. Certainly if I was a commercial >>> application layer provider, I would not consider using an IPv6-only >>> ISP for one moment, because that would disadvantage my IPv4 = customers. >>>=20 >>> Note, this is not a comment on the technology, but on whether = there's >>> a real operational use case today. >>=20 >> The point is that all this 464XLAT discussion is in the context of = IPv6-only operator networks.=20 >> My understanding is that deployments of IPv6-only networks are = seriously envisaged in the context of LTE. >=20 > ipv6 only pdp contexts exist today, lte or no. Yes, the right sentence would have been "IPv6-only networks are = seriously envisaged in the context of 3GPP" Thanks, RD From tore.anderson@redpill-linpro.com Mon Apr 23 02:03:55 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D29D21F8623 for ; Mon, 23 Apr 2012 02:03:55 -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 fFZ8S2BVyAio for ; Mon, 23 Apr 2012 02:03:53 -0700 (PDT) Received: from zimbra.redpill-linpro.com (zimbra.redpill-linpro.com [87.238.49.234]) by ietfa.amsl.com (Postfix) with ESMTP id CCA5721F8668 for ; Mon, 23 Apr 2012 02:03:52 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.redpill-linpro.com (Postfix) with ESMTP id 13DD01918388; Mon, 23 Apr 2012 11:03:51 +0200 (CEST) X-Virus-Scanned: amavisd-new at claudius.linpro.no Received: from zimbra.redpill-linpro.com ([127.0.0.1]) by localhost (zimbra.redpill-linpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OMHVonDl+Ao7; Mon, 23 Apr 2012 11:03:50 +0200 (CEST) Received: from echo.linpro.no (echo.linpro.no [87.238.42.42]) by zimbra.redpill-linpro.com (Postfix) with ESMTPSA id 7FC2718585C2; Mon, 23 Apr 2012 11:03:50 +0200 (CEST) Message-ID: <4F951AF6.5020408@redpill-linpro.com> Date: Mon, 23 Apr 2012 11:03:50 +0200 From: Tore Anderson Organization: Redpill Linpro AS User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: Nick Hilliard References: <4F8DAA5E.3070007@bogus.com> <4F8E695C.3050705@gmail.com> <4F8E7888.8080102@inex.ie> <4F93B43F.7030006@bogus.com> <4F93E809.6040607@inex.ie> In-Reply-To: <4F93E809.6040607@inex.ie> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] In the vein of of the icp/dc 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: Mon, 23 Apr 2012 09:03:56 -0000 * Nick Hilliard > On 22/04/2012 08:33, Joel jaeggli wrote: >> excluding them from consideration tends to get the message >> across... > > I agree in theory - and include ipv6 feature parity in all product > evaluations, and whine/bitch at vendors who have a lax ipv6 attitude > - but excluding them from consideration also tends to put the DC > operator at a competitive disadvantage as it removes product choice > for ipv4 services. This can have a direct impact on revenue, customer > retention and all that. IOW, we're not there yet. For sure, we're a > lot better now than we were a couple of years ago, but for many > areas/products/services the disparity is still large enough that > ipv6-only services are not a viable option. Hi, I'm glad you found my presentation interesting enough to discuss. :-) I agree with you both, actually. We're not religious about IPv6, so we would certainly not turn down a customer who wants us to manage a solution that have components that will either only work with IPv4, or a solution that can not work through stateless translation (so it would have to run either dual-stacked or IPv4-only). On the other hand, in order to cater to these customers we need IPv4 addresses, which are in short supply. So even though we cannot realistically do IPv6-only and stateless translation for *every* customer, it still makes a lot of sense to do it where we can, so we can save those precious IPv4 addresses for use where they are absolutely necessary. And, as it happens, the most of of our customers are running some HTTP-based application on top of a mostly open-source software stack. IPv6 tends to be well supported; I reckon that the customers who are running applications with hard IPv4 dependencies are in the minority. As an added bonus, maintaining those IPv6-only customers' servers and applications gives pretty much the same low operational complexity as IPv4-only operation has. And it requires no stateful devices in the critical network path. To the best of my knowledge, IPv4-only operation is the only other option that will provide these two extremely desirable traits. In any case, the talk itself goes into more detail about our thinking than the slide deck, so in case you have 45 minutes to kill, the recording is available at https://ripe64.ripe.net/archives/video/37/. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com From dan-v6ops@drown.org Mon Apr 23 08:57:31 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39FEC21F8720 for ; Mon, 23 Apr 2012 08:57:29 -0700 (PDT) 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.100, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LSx2KAqSlwIi for ; Mon, 23 Apr 2012 08:57:24 -0700 (PDT) Received: from vps3.drown.org (vps3.drown.org [IPv6:2600:3c00::f03c:91ff:fedf:5654]) by ietfa.amsl.com (Postfix) with ESMTP id DC5A121F8713 for ; Mon, 23 Apr 2012 08:57:17 -0700 (PDT) Received: by vps3.drown.org (Postfix, from userid 48) id DEAA4C135; Mon, 23 Apr 2012 11:57:16 -0400 (EDT) Received: from 2001:470:b88f:c8f6:224:1dff:fe16:eb3b ([2001:470:b88f:c8f6:224:1dff:fe16:eb3b]) by mail.drown.org (Horde Framework) with HTTP; Mon, 23 Apr 2012 10:57:16 -0500 Message-ID: <20120423105716.130762z7e8air84c@mail.drown.org> Date: Mon, 23 Apr 2012 10:57:16 -0500 From: Dan Drown To: GangChen References: <20120417065542.31115.95082.idtracker@ietfa.amsl.com> <20120417160010kawashimam@mail.jp.nec.com> <56E2AD61-1C91-4889-914A-353793FCBE43@laposte.net> <20120419121044.17531mk1mv19abr4@mail.drown.org> <0646611B-5594-40EA-A2C4-F99CBA734024@laposte.net> <20120419181813.4524701l3gkq5zks@mail.drown.org> <45ABAD31-C265-4D63-82E2-3DE6F59B80C0@laposte.net> <20120420104246.1432746csfcrdqo8@mail.drown.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.9) Cc: v6ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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, 23 Apr 2012 15:57:31 -0000 Quoting GangChen : > Wondering to know which interface (i.e. cell int or wifi tethering > int) should be selected if applications on the phone are going to send > packages in the case of re-using same IPv6 address I apologize if I've misunderstood your question, but I believe you're wondering about (kernel) source address selection. http://linux-hacks.blogspot.com/2008/07/default-address-selection-part-2.html has a good description of the process if you want more detail. But in this case (two addresses with the same scope on different interfaces), Linux will prefer the address on the interface associated with the route to the destination. From mark@townsley.net Mon Apr 23 10:27:55 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5D9921F8593 for ; Mon, 23 Apr 2012 10:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id llDbYTmFe-fH for ; Mon, 23 Apr 2012 10:27:54 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0031021F859A for ; Mon, 23 Apr 2012 10:27:46 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so8199773wgb.13 for ; Mon, 23 Apr 2012 10:27:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:mime-version:content-type:subject:date:in-reply-to:to :references:message-id:x-mailer:x-gm-message-state; bh=ybdP5urekDd8plCwBwXeDJ7crmENzsyulfeYEHJFW70=; b=l4BdH44YUwk6vZtN2sH+gUExGZM4sMmVWW/R+2N1UVCssvUdquVa6ejhMqgFVKj3p6 Hgtfrq6N7p9BqDES+nGJXsldgH7XHQlv6qaSE95TNAgfL/pYrTzwhJYfV3MeqaprJWLP 121ftIDKNok/j/8AJOe5QwntQTT/zOilbFjHSXkS6qSwA24LDzTa03Dt4IswJo2Ta5jV cR6jS0cZmMEttcpS41kT6u90atLtF7sO2CdzdXxzLePIx3y1th+w+nt4OGYOB0zskti2 LYl71U63ckLz/cb7kUJlphogvIiY/W+KnqBR4Epju7TSKBiYo7jViVgmP8HryM/QB9Sz jIXQ== Received: by 10.216.198.154 with SMTP id v26mr3725wen.74.1335202065914; Mon, 23 Apr 2012 10:27:45 -0700 (PDT) Received: from ams-townsley-8912.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id n20sm37041677wiw.5.2012.04.23.10.27.38 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 Apr 2012 10:27:44 -0700 (PDT) From: Mark Townsley Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_B35621DC-FBBD-4F04-8933-49502B5A9E42" Date: Mon, 23 Apr 2012 19:27:36 +0200 In-Reply-To: <2FEFE40E-25F2-4D02-A608-0CADCBBAAE9C@cisco.com> To: v6ops@ietf.org References: <2FEFE40E-25F2-4D02-A608-0CADCBBAAE9C@cisco.com> Message-Id: <5DD4D480-328E-4CE4-B9C0-DE65B76597D4@townsley.net> X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQkyaGznW9yQnGzYDck7x2ngQSKrCcheAjDaLatH7XZWSP2G2VXuvAiKD8Bg8pidihKNhlX2 Subject: [v6ops] 6rd sunsetting requirements for 6204-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 17:27:55 -0000 --Apple-Mail=_B35621DC-FBBD-4F04-8933-49502B5A9E42 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 v6ops, In Paris, Fred asked Chris and I to work on text describing the three = 6rd sunsetting requirements discussed during the meeting. Instead, a few = folks pulled together text without as much as a sanity check or heads up = in my inbox. Meanwhile, not knowing anyone else had taken on the project = of adapting their own version of 6rd sunsetting requirements for = 6294-bis, I was working in parallel based on feedback received at the WG = meeting, in the hall, etc. I sent this to Chris and the chairs one week = after the Paris meeting (April 6) for review.=20 I'm sure everyone has the best of intentions here, but what made it into = the document is not only flawed technically, it didn't include all WG = feedback because some of that was directly to me=85 and being left out = of the process of writing the requirements that are in the document, = means that this feedback obviously didn't get incorporated.=20 In any case, here's what I believe the additional 6rd requirements = should be based on what was in my presentation to the group and the = feedback I have received. These are for section 4.4.1, which is already = surrounded by an "if 6rd is supported" clause: 6RD-4: A CE router MUST allow 6rd virtual and IPv6 native WAN interfaces = to be active simultaneously in order to support coexistence of the two technologies during an incremental migration period from 6rd to native IPv6.=20 6RD-5: The CE router MUST associate delegated prefixes with the WAN interface(s) they were learned from (e.g., DHCPv6-PD, 6rd, etc). Each packet sent out a WAN interface MUST have a source address that corresponds to a delegated prefix associated with the given WAN interface, consistent with what is described in section 4.3 of BCP 84 (RFC 3704). 6RD-6: The IPv6 CE router MUST allow different or identical delegated = prefixes on 6rd and native interfaces. A 6rd virtual interface MUST be assigned a=20= higher routing cost than a native IPv6 interface. This is done so that = native=20 traffic will be preferred over 6rd in the event normal IP longest = matching=20 and BCP 84 rules would have otherwise allowed a packet to be equally = sent=20 via 6rd or native IPv6. These would be instead of the four requirements, 6RD-4 through 6RD-7, in = -08.=20 - Mark On Apr 15, 2012, at 10:54 PM, Fred Baker wrote: > This is to initiate a ONE week working group last call of = draft-ietf-v6ops-6204bis, seeing as we just completed a two week event = and finished some comments at IETF 83. Please read it now, or at least = the diff from the previous version. If you find nits (spelling errors, = minor suggested wording changes, etc), comment to the authors; if you = find greater issues, such as disagreeing with a statement or finding = additional issues that need to be addressed, please post your comments = to the list. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_B35621DC-FBBD-4F04-8933-49502B5A9E42 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

6RD-4: A CE router = MUST allow 6rd virtual and IPv6 native WAN interfaces to = be
active simultaneously in order to support coexistence = of the two
technologies during an incremental migration = period from 6rd to = native
IPv6. 

6RD-5: The CE router = MUST associate delegated prefixes with the = WAN
interface(s) they were learned from (e.g., DHCPv6-PD, = 6rd, etc). Each
packet sent out a WAN interface MUST have = a source address that
corresponds to a delegated prefix = associated with the given WAN
interface, consistent with = what is described in section 4.3 of BCP
84 (RFC = 3704).

6RD-6: The IPv6 CE router MUST allow different = or identical delegated prefixes
on 6rd and native = interfaces. A 6rd virtual interface MUST be assigned = a 
higher routing cost than a native IPv6 interface. This = is done so that native 
traffic will be preferred = over 6rd in the event normal IP longest = matching 
and BCP 84 rules would have otherwise allowed a = packet to be equally sent 
via 6rd or native = IPv6.

These would be instead of the = four requirements, 6RD-4 through 6RD-7, in = -08. 

- Mark

On Apr 15, = 2012, at 10:54 PM, Fred Baker wrote:

This is = to initiate a ONE week working group last call of = draft-ietf-v6ops-6204bis, seeing as we just completed a two week event = and finished some comments at IETF 83. Please read it now, or at least = the diff from the previous version. If you find nits (spelling errors, = minor suggested wording changes, etc), comment to the authors; if = you find greater issues, such as disagreeing with a statement or finding = additional issues that need to be addressed, please post = your comments to the list.
=
_______________________________________________
v6ops = mailing list
v6ops@ietf.org
https://www.ietf.org/= mailman/listinfo/v6ops

= --Apple-Mail=_B35621DC-FBBD-4F04-8933-49502B5A9E42-- From v6ops@globis.net Mon Apr 23 10:31:41 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF2A521F86B4 for ; Mon, 23 Apr 2012 10:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 8g1mLQ0y-W68 for ; Mon, 23 Apr 2012 10:31:41 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2427D21F8686 for ; Mon, 23 Apr 2012 10:31:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 133FD8700D5; Mon, 23 Apr 2012 19:31:39 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w7vwZe5q2czN; Mon, 23 Apr 2012 19:31:34 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 3CB54870066; Mon, 23 Apr 2012 19:31:34 +0200 (CEST) Message-ID: <4F9591F5.9000208@globis.net> Date: Mon, 23 Apr 2012 19:31:33 +0200 From: Ray Hunter User-Agent: Postbox 3.0.3 (Macintosh/20120304) MIME-Version: 1.0 To: Fred Baker References: <54469FB9-D118-4157-B9D6-8F52F7F96002@cisco.com> In-Reply-To: <54469FB9-D118-4157-B9D6-8F52F7F96002@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-ra-guard-implementation WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 17:31:41 -0000 I have reviewed this document, and find that it provides important and useful advice to the IPv6 operations community. Fred Baker wrote: > This is to initiate a two week working group last call of > draft-ietf-v6ops-ra-guard-implementation. Please read it now. If you > find nits (spelling errors, minor suggested wording changes, etc), > comment to the authors; if you find greater issues, such as > disagreeing with a statement or finding additional issues that need to > be addressed, please post your comments to the list. > > We are looking specifically for comments on the importance of the > document as well as its content. If you have read the document and > believe it to be of operational utility, that is also an important > comment to make. From bzeeb-lists@lists.zabbadoz.net Mon Apr 23 10:47:53 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A11BC21F8720 for ; Mon, 23 Apr 2012 10:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.371 X-Spam-Level: X-Spam-Status: No, score=-1.371 tagged_above=-999 required=5 tests=[AWL=0.629, 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 wBgBcPrtxydY for ; Mon, 23 Apr 2012 10:47:53 -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 0EFF721F8704 for ; Mon, 23 Apr 2012 10:47:52 -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 9BC1A25D388B; Mon, 23 Apr 2012 17:47:50 +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 558A2BE5782; Mon, 23 Apr 2012 17:47:49 +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 NwWW0L1h-3UR; Mon, 23 Apr 2012 17:47:48 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 3555CBE5781; Mon, 23 Apr 2012 17:47:46 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <54469FB9-D118-4157-B9D6-8F52F7F96002@cisco.com> Date: Mon, 23 Apr 2012 17:47:45 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54469FB9-D118-4157-B9D6-8F52F7F96002@cisco.com> To: Fred Baker X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-ra-guard-implementation WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 17:47:53 -0000 On 22. Apr 2012, at 18:00 , Fred Baker wrote: > This is to initiate a two week working group last call of = draft-ietf-v6ops-ra-guard-implementation. Please read it now. If you = find nits (spelling errors, minor suggested wording changes, etc), = comment to the authors; if you find greater issues, such as disagreeing = with a statement or finding additional issues that need to be addressed, = please post your comments to the list. I had done so at the mic in v6ops and the same day (March 29) to the = list; the draft has not been changed since to limit the packets dropped = by 3.1 to only packets that can actually be RA packets as identifiable = in the L3 header already. I still have concerns as expressed in these emails that we will be = dropping things to unreasonable limits that will be put into Silicon and = stay around with L2+ devices for at least a decade while not knowing how = things like extension headers etc will evolve as development and = deployment continues. /bz --=20 Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! From shemant@cisco.com Mon Apr 23 11:26:06 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C805A21F84C3 for ; Mon, 23 Apr 2012 11:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QHvNsdTUIwv4 for ; Mon, 23 Apr 2012 11:26:05 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id B885E21F84B4 for ; Mon, 23 Apr 2012 11:26:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=5495; q=dns/txt; s=iport; t=1335205562; x=1336415162; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=M45bqsEX787elro4sFKXs41xGY8Pw1TJRd7yWfhOXI0=; b=lK6HgKa9mG4YMZg5BehNgQvI4fD47437E/RgRVoDIrWu5iEbIcvZezc3 aiz66yZTGBWhYX+yYxbXBdQiwNm3IyKIWrgwoeMocb7WUi5WVk2b1mDAG iPNgr2K4YzHXEtfAM08iSmfQ5pSg51HMX/9jHuT22qinNTubl7bEUPriu 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAGydlU+tJV2b/2dsb2JhbABEgkavFIEHggkBAQEEEgEJEQNZAgEIEQQBAQsGFwEGAUUJCAEBBAESCBqHbZpMoCmQbGMEiGObbIFpgwc X-IronPort-AV: E=Sophos;i="4.75,468,1330905600"; d="scan'208,217";a="76890009" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 23 Apr 2012 18:26: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 q3NIQ2dH015583; Mon, 23 Apr 2012 18:26: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, 23 Apr 2012 13:26:02 -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_01CD217E.89481D66" Date: Mon, 23 Apr 2012 13:26:01 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C30483721E@XMB-RCD-109.cisco.com> In-Reply-To: <5DD4D480-328E-4CE4-B9C0-DE65B76597D4@townsley.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] 6rd sunsetting requirements for 6204-bis Thread-Index: Ac0hdnGy/DgHLzebT7WGc4ihBz6+WAAB2PmA References: <2FEFE40E-25F2-4D02-A608-0CADCBBAAE9C@cisco.com> <5DD4D480-328E-4CE4-B9C0-DE65B76597D4@townsley.net> From: "Hemant Singh (shemant)" To: "Mark Townsley" , X-OriginalArrivalTime: 23 Apr 2012 18:26:02.0308 (UTC) FILETIME=[89ADD840:01CD217E] Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 18:26:06 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD217E.89481D66 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 Mark Townsley Sent: Monday, April 23, 2012 1:28 PM To: v6ops@ietf.org Subject: [v6ops] 6rd sunsetting requirements for 6204-bis =20 >6RD-4: A CE router MUST allow 6rd virtual and IPv6 native WAN interfaces to be >active simultaneously in order to support coexistence of the two >technologies during an incremental migration period from 6rd to native >IPv6.=20 =20 I don't think such a requirement is needed, especially with a strong text such as the "MUST" in the requirement. The reason is the device is a CPE router and a router, by default, has no issue with supporting two concurrently IP technologies on the network interfaces of the router. =20 =20 Thanks, =20 Hemant ------_=_NextPart_001_01CD217E.89481D66 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 = Mark Townsley
Sent: Monday, April 23, 2012 1:28 = PM
To: v6ops@ietf.org
Subject: [v6ops] 6rd = sunsetting requirements for 6204-bis

 

>6RD-4: A CE = router MUST allow 6rd virtual and IPv6 native WAN interfaces to = be

>active simultaneously in order to = support coexistence of the two

>technologies = during an incremental migration period from 6rd to = native

>IPv6. 

 

I don’t think such a requirement is needed, especially with a = strong text such as the “MUST” in the requirement. =   The reason is the device is a  CPE router and a router, = by default, has no issue with supporting two concurrently IP = technologies on the network interfaces  of the router.   =

 

Thanks,

 

Hemant

------_=_NextPart_001_01CD217E.89481D66-- From simon.perreault@viagenie.ca Mon Apr 23 11:37:23 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8EA21F85C0 for ; Mon, 23 Apr 2012 11:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6Jeq8RRy719 for ; Mon, 23 Apr 2012 11:37:22 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id C2AD521F85AC for ; Mon, 23 Apr 2012 11:37:22 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:8130:f627:d4d2:65bc]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 4AA7B40064 for ; Mon, 23 Apr 2012 14:37:22 -0400 (EDT) Message-ID: <4F95A161.3040706@viagenie.ca> Date: Mon, 23 Apr 2012 14:37:21 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: v6ops@ietf.org References: <2FEFE40E-25F2-4D02-A608-0CADCBBAAE9C@cisco.com> <5DD4D480-328E-4CE4-B9C0-DE65B76597D4@townsley.net> <5B6B2B64C9FE2A489045EEEADDAFF2C30483721E@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C30483721E@XMB-RCD-109.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 18:37:23 -0000 On 2012-04-23 14:26, Hemant Singh (shemant) wrote: >>6RD-4: A CE router MUST allow 6rd virtual and IPv6 native WAN interfaces to be >>active simultaneously in order to support coexistence of the two >>technologies during an incremental migration period from 6rd to native >>IPv6. > > I don’t think such a requirement is needed, especially with a strong > text such as the “MUST” in the requirement. The reason is the device is > a CPE router and a router, by default, has no issue with supporting two > concurrently IP technologies on the network interfaces of the router. I know of at least one popular home router model currently in stores that doesn't allow native IPv6 simultaneously with 6rd. So this requirement looks necessary to me. 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 Mon Apr 23 11:42:31 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30DBB21F85D3 for ; Mon, 23 Apr 2012 11:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oAJJZnmgeksJ for ; Mon, 23 Apr 2012 11:42:29 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 35F3D21F85AE for ; Mon, 23 Apr 2012 11:42:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=4707; q=dns/txt; s=iport; t=1335206549; x=1336416149; h=mime-version:subject:date:message-id:from:to; bh=D3PAN1zQmTHkoDlB2cwp5QeRE1baPeYkqnKVXDTYPFY=; b=T4uhKrSIlpb0iAjF0Ll6qvsF+XueJovHydctXhm1QAurRhpxKzHxQQ/w dhMRIq1yQ7YN29Xb/XHKwXxQRphF5YhsxVyxZhyp3eMTsb7WJpQKoqiZM 4ushigdJAQJwhNPwm93x+gmVC1umlHapCKOyCEb0qw+0wWohKYB7uLjIz Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFACOilU+tJV2Z/2dsb2JhbABEgkavF4EHggkBAQEEEgEJEQNVBgEIEQQBAQsGFwEHRQcBAQUEAQQBEggah22aSaApkGxjBIhjm2yBaYMH X-IronPort-AV: E=Sophos;i="4.75,468,1330905600"; d="scan'208,217";a="77111437" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 23 Apr 2012 18:42:28 +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 q3NIgSH0020617; Mon, 23 Apr 2012 18:42:28 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, 23 Apr 2012 13:42:28 -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_01CD2180.D4FDB366" Date: Mon, 23 Apr 2012 13:42:27 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C30483722C@XMB-RCD-109.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] 6rd sunsetting requirements for 6204-bis Thread-Index: Ac0hgCUZtw6+QVy/SP+qkFK7os8M9wAAD29A From: "Hemant Singh (shemant)" To: , "Simon Perreault" X-OriginalArrivalTime: 23 Apr 2012 18:42:28.0349 (UTC) FILETIME=[D567C2D0:01CD2180] Subject: [v6ops] FW: 6rd sunsetting requirements for 6204-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 18:42:31 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD2180.D4FDB366 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Simon Perreault Sent: Monday, April 23, 2012 2:37 PM To: v6ops@ietf.org Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis =20 >I know of at least one popular home router model currently in stores=20 >that doesn't allow native IPv6 simultaneously with 6rd. So this=20 >requirement looks necessary to me. =20 Sorry, still does not cut it for me. Fix the bug in the CPE router. We cannot add every bug found in the CPE router for a requirement to the document. This is extremely basic router functionality where a router should support concurrent tunneled and native IP interfaces. =20 =20 Hemant ------_=_NextPart_001_01CD2180.D4FDB366 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 = Simon Perreault
Sent: Monday, April 23, 2012 2:37 PM
To: = v6ops@ietf.org
Subject: Re: [v6ops] 6rd sunsetting requirements for = 6204-bis

 

>I = know of at least one popular home router model currently in stores =

>that doesn't allow native IPv6 = simultaneously with 6rd. So this

>requirement looks necessary to me.

 

Sorry, still does not = cut it for me.  Fix the bug in the CPE router.  We cannot add = every bug found in the CPE router for a requirement to the = document.  This is extremely basic router functionality where a = router should support concurrent tunneled and native IP interfaces. =  

 

Hemant

------_=_NextPart_001_01CD2180.D4FDB366-- From simon.perreault@viagenie.ca Mon Apr 23 11:47:59 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3781E21F85E7 for ; Mon, 23 Apr 2012 11:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8f45yX4xVh43 for ; Mon, 23 Apr 2012 11:47:58 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 85A2121F85E6 for ; Mon, 23 Apr 2012 11:47:58 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:8130:f627:d4d2:65bc]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 4C4AA4037F; Mon, 23 Apr 2012 14:47:54 -0400 (EDT) Message-ID: <4F95A3D9.1010100@viagenie.ca> Date: Mon, 23 Apr 2012 14:47:53 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: "Hemant Singh (shemant)" References: <5B6B2B64C9FE2A489045EEEADDAFF2C30483722C@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C30483722C@XMB-RCD-109.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] FW: 6rd sunsetting requirements for 6204-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 18:47:59 -0000 On 2012-04-23 14:42, Hemant Singh (shemant) wrote: >>I know of at least one popular home router model currently in stores >>that doesn't allow native IPv6 simultaneously with 6rd. So this >>requirement looks necessary to me. > > Sorry, still does not cut it for me. Fix the bug in the CPE router. It's a bug according to which RFC? 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 Mon Apr 23 12:15:30 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8341C21F85A3 for ; Mon, 23 Apr 2012 12:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.298 X-Spam-Level: X-Spam-Status: No, score=-10.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_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-Xbczu35VnU for ; Mon, 23 Apr 2012 12:15:29 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id A141D21F859F for ; Mon, 23 Apr 2012 12:15:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=6733; q=dns/txt; s=iport; t=1335208528; x=1336418128; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=lRhUHhaSKJRMkgLbAYJsS5DI7eL8GlD/aa+v1tvQQj8=; b=KYi6hYaDtZ1jfrX15efl+3mxtmSDUn6S8fsyX99jgxDB6g+JEpX9zgIU K5LYMhMs8nNcctJshoPb9l2zbz6EecsZTAvf7T4CgFjwUEYrWeZcYSmUw o9vC0lWSRE5SVpP0K6YHsc+SUodFBMU4xFB6+5VBA8hy7NBBp8boER5vl g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFACWplU+tJV2Y/2dsb2JhbABEgkavF4EHggkBAQEEEgEJEQNJDAQCAQgRBAEBCwYXAQYBRQgBCAEBBBMIARmHbQuaNqArineFdWMEiGObbIFpgweBPg X-IronPort-AV: E=Sophos;i="4.75,468,1330905600"; d="scan'208,217";a="77121106" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP; 23 Apr 2012 19:15:28 +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 q3NJFSwP002962; Mon, 23 Apr 2012 19:15:28 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, 23 Apr 2012 14:15:27 -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_01CD2185.70DEE98A" Date: Mon, 23 Apr 2012 14:15:26 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C304837261@XMB-RCD-109.cisco.com> In-Reply-To: <4F95A3D9.1010100@viagenie.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: [v6ops] 6rd sunsetting requirements for 6204-bis Thread-Index: Ac0hgZhuvm2IexdOQfywfRl7nr23WQAAV7qw References: <5B6B2B64C9FE2A489045EEEADDAFF2C30483722C@XMB-RCD-109.cisco.com> <4F95A3D9.1010100@viagenie.ca> From: "Hemant Singh (shemant)" To: "Simon Perreault" X-OriginalArrivalTime: 23 Apr 2012 19:15:27.0551 (UTC) FILETIME=[711A04F0:01CD2185] Cc: v6ops@ietf.org Subject: Re: [v6ops] FW: 6rd sunsetting requirements for 6204-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 19:15:30 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD2185.70DEE98A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 -----Original Message----- From: Simon Perreault [mailto:simon.perreault@viagenie.ca]=20 Sent: Monday, April 23, 2012 2:48 PM To: Hemant Singh (shemant) Cc: v6ops@ietf.org Subject: Re: FW: [v6ops] 6rd sunsetting requirements for 6204-bis =20 >It's a bug according to which RFC? =20 Do you really think an RFC would specify router behavior for concurrent operation of a GRE tunnel, native IPv6, and native IPv4 operations on a router? There are Enterprise and network access edge routers shipping for ages where concurrent tunneled and native IP on the router works just fine with specific configuration on the router. =20 =20 The bigger question for the CPE router is, soon as the CPE supports concurrent operation of native IPv6 and 6rd, how is the CPE FIB and RIB supposed to work? There is no specification out there in RFC form that covers the operations insides the CPE for the FIB and the RIB. MarkT and Ole have a draft (draft-townsley-troan-ipv6-ce-transitioning-02) that has started the work with a SourcreRIB and DestRIB. However, this work is incomplete. See an email I sent to v6ops on 03/24/2012 with my review of draft-townsley-troan-ipv6-ce-transitioning-02. =20 http://www.ietf.org/mail-archive/web/v6ops/current/msg12496.html =20 We are putting the cart before the horse if we include Mark's new requirements from today into rfc6204bis. =20 Hemant ------_=_NextPart_001_01CD2185.70DEE98A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

-----Original Message-----
From: Simon Perreault = [mailto:simon.perreault@viagenie.ca]
Sent: Monday, April 23, 2012 = 2:48 PM
To: Hemant Singh (shemant)
Cc: v6ops@ietf.org
Subject: = Re: FW: [v6ops] 6rd sunsetting requirements for = 6204-bis

 

>It's = a bug according to which RFC?

 

Do you really think an = RFC would specify router behavior for concurrent operation of a GRE = tunnel, native IPv6, and native IPv4 operations on a router?  There = are Enterprise and network access edge routers shipping for ages where = concurrent tunneled and native IP on the router works just fine with = specific configuration on the router. 

 

The bigger question for the CPE router is, soon as the = CPE supports concurrent operation of native IPv6 and 6rd, how is the CPE = FIB and RIB supposed to work?  There is no specification out there = in RFC form that covers the operations insides the CPE for the FIB and = the RIB.  MarkT and Ole have a draft = (draft-townsley-troan-ipv6-ce-transitioning-02) that has started the = work with a SourcreRIB and DestRIB.  However, this work is = incomplete. See an email I sent to v6ops on 03/24/2012 with my review of = draft-townsley-troan-ipv6-ce-transitioning-02.

 

http://www.ietf.org/mail-archive/web/v6ops/current/msg12496.html

 

We are putting the cart before the horse if we include = Mark’s new requirements from today into = rfc6204bis.

 

Hemant

------_=_NextPart_001_01CD2185.70DEE98A-- From simon.perreault@viagenie.ca Mon Apr 23 12:21:10 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1C3621F8548 for ; Mon, 23 Apr 2012 12:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NTnv-fjpNms3 for ; Mon, 23 Apr 2012 12:21:06 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id E973E21F853D for ; Mon, 23 Apr 2012 12:21:05 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:8130:f627:d4d2:65bc]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 5BB964037F; Mon, 23 Apr 2012 15:21:05 -0400 (EDT) Message-ID: <4F95ABA0.8090601@viagenie.ca> Date: Mon, 23 Apr 2012 15:21:04 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: "Hemant Singh (shemant)" References: <5B6B2B64C9FE2A489045EEEADDAFF2C30483722C@XMB-RCD-109.cisco.com> <4F95A3D9.1010100@viagenie.ca> <5B6B2B64C9FE2A489045EEEADDAFF2C304837261@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C304837261@XMB-RCD-109.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] FW: 6rd sunsetting requirements for 6204-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 19:21:10 -0000 On 2012-04-23 15:15, Hemant Singh (shemant) wrote: >>It's a bug according to which RFC? > > Do you really think an RFC would specify router behavior for concurrent > operation of a GRE tunnel, native IPv6, and native IPv4 operations on a > router? There are Enterprise and network access edge routers shipping > for ages where concurrent tunneled and native IP on the router works > just fine with specific configuration on the router. Agreed, I don't think this should be specified. But Mark's argument is, if I understand correctly, that not supporting native alongside 6rd *harms the Internet* because it prevents graceful transitioning from 6rd to native. That argument is specific to 6rd, not generic to all tunnel interfaces. 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 Mon Apr 23 12:31:23 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67D9821E8019 for ; Mon, 23 Apr 2012 12:31:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.498 X-Spam-Level: X-Spam-Status: No, score=-10.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ktz+sum+8OQf for ; Mon, 23 Apr 2012 12:31:22 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 9C30D21E801F for ; Mon, 23 Apr 2012 12:31:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=5350; q=dns/txt; s=iport; t=1335209482; x=1336419082; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=xhBZxnToLxLOmvLE/55UA2xUX7bsV34kC9lKZOoJ41o=; b=fPrmqcGETxGw+GJJSifSFPOEXkm5LnmNpbFPYUs3dlSGWuXJBG2FP4EQ vlCtQpUXXhMZEZqegpJ3wnPThe4RvgJwvkewinHptDrPxgBhWQszc/4vh 4J8SYYrh8TapXykFxmmbv82y+69FwhEALrruU5Lf4g+BqDtC0XT9kKkHR M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAL2slU+tJV2a/2dsb2JhbABEgkavGIEHggkBAQEEEgEJEQNJDAQCAQgRBAEBCwYXAQYBRQgBCAEBBBMIGodtmjagLJBsYwSIY5tsgWmDBw X-IronPort-AV: E=Sophos;i="4.75,468,1330905600"; d="scan'208,217";a="77137933" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 23 Apr 2012 19:31:22 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3NJVMvK013304; Mon, 23 Apr 2012 19:31:22 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, 23 Apr 2012 14:31:22 -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_01CD2187.A9B3B116" Date: Mon, 23 Apr 2012 14:31:21 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C304837272@XMB-RCD-109.cisco.com> In-Reply-To: <4F95ABA0.8090601@viagenie.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: [v6ops] 6rd sunsetting requirements for 6204-bis Thread-Index: Ac0hhjsQ4vR3w6CWQTilKttqXXTLgAAAEx3A References: <5B6B2B64C9FE2A489045EEEADDAFF2C30483722C@XMB-RCD-109.cisco.com> <4F95A3D9.1010100@viagenie.ca> <5B6B2B64C9FE2A489045EEEADDAFF2C304837261@XMB-RCD-109.cisco.com> <4F95ABA0.8090601@viagenie.ca> From: "Hemant Singh (shemant)" To: "Simon Perreault" X-OriginalArrivalTime: 23 Apr 2012 19:31:22.0015 (UTC) FILETIME=[AA01AAF0:01CD2187] Cc: v6ops@ietf.org Subject: Re: [v6ops] FW: 6rd sunsetting requirements for 6204-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 19:31:23 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD2187.A9B3B116 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 =20 -----Original Message----- From: Simon Perreault [mailto:simon.perreault@viagenie.ca]=20 Sent: Monday, April 23, 2012 3:21 PM To: Hemant Singh (shemant) Cc: v6ops@ietf.org Subject: Re: FW: [v6ops] 6rd sunsetting requirements for 6204-bis =20 >But Mark's argument is, if I understand correctly, that not supporting=20 >native alongside 6rd *harms the Internet* because it prevents graceful=20 >transitioning from 6rd to native. That argument is specific to 6rd, not >generic to all tunnel interfaces. =20 Fine for an argument. But again, the CPE router is consumer device that needs a specification for automata related to concurrent operation of native IPv6 and 6rd including specifying the transition from native IPv6 6rd or vice versa. Such a specification does not exist in RFC form. Rfc6204bis only accepts technology in RFC form or in rare exceptions, technology where the draft is in the IESG. =20 =20 Hemant=20 ------_=_NextPart_001_01CD2187.A9B3B116 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

-----Original Message-----
From: Simon Perreault = [mailto:simon.perreault@viagenie.ca]
Sent: Monday, April 23, 2012 = 3:21 PM
To: Hemant Singh (shemant)
Cc: v6ops@ietf.org
Subject: = Re: FW: [v6ops] 6rd sunsetting requirements for = 6204-bis

 

>But = Mark's argument is, if I understand correctly, that not supporting =

>native alongside 6rd *harms the = Internet* because it prevents graceful

>transitioning from 6rd to native. That argument is specific to = 6rd, not

>generic to all tunnel = interfaces.

 

Fine for an = argument.  But again, the CPE router is consumer device that needs = a specification for automata related to concurrent operation of native = IPv6 and 6rd including specifying the transition from native IPv6 6rd or = vice versa.  Such a specification does not exist in RFC form. =  Rfc6204bis only accepts technology in RFC form or in rare = exceptions, technology where the draft is in the IESG. =  

 

Hemant

------_=_NextPart_001_01CD2187.A9B3B116-- From warren@kumari.net Mon Apr 23 15:22:02 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D07221E804A for ; Mon, 23 Apr 2012 15:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.238 X-Spam-Level: X-Spam-Status: No, score=-106.238 tagged_above=-999 required=5 tests=[AWL=-0.239, 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 TLmWUZpP9BUF for ; Mon, 23 Apr 2012 15:22:01 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 990E121E800F for ; Mon, 23 Apr 2012 15:22:01 -0700 (PDT) Received: from [192.168.0.12] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 1C4F11B4030E; Mon, 23 Apr 2012 18:22:00 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: <54469FB9-D118-4157-B9D6-8F52F7F96002@cisco.com> Date: Mon, 23 Apr 2012 18:21:56 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54469FB9-D118-4157-B9D6-8F52F7F96002@cisco.com> To: Fred Baker X-Mailer: Apple Mail (2.1257) Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-ra-guard-implementation WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 22:22:02 -0000 On Apr 22, 2012, at 2:00 PM, Fred Baker wrote: > This is to initiate a two week working group last call of = draft-ietf-v6ops-ra-guard-implementation. Yay. > Please read it now. No (I read it a while back and it hasn't changed since then :-)) I support publication of this document. I believe it provides useful = content and solves an important issue. W > If you find nits (spelling errors, minor suggested wording changes, = etc), comment to the authors; if you find greater issues, such as = disagreeing with a statement or finding additional issues that need to = be addressed, please post your comments to the list. >=20 > We are looking specifically for comments on the importance of the = document as well as its content. If you have read the document and = believe it to be of operational utility, that is also an important = comment to make. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From C.Donley@cablelabs.com Mon Apr 23 16:01:42 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 845B021F85B1 for ; Mon, 23 Apr 2012 16:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.462 X-Spam-Level: X-Spam-Status: No, score=-0.462 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cdtbW9LLJe8T for ; Mon, 23 Apr 2012 16:01:41 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id AE07611E8072 for ; Mon, 23 Apr 2012 16:01:41 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id q3NN1bAC027369; Mon, 23 Apr 2012 17:01:37 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Mon, 23 Apr 2012 17:01:37 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Mon, 23 Apr 2012 17:01:36 -0600 From: Chris Donley To: Mark Townsley , "v6ops@ietf.org" Date: Mon, 23 Apr 2012 17:03:38 -0600 Thread-Topic: [v6ops] 6rd sunsetting requirements for 6204-bis Thread-Index: Ac0hpQjBW+0+ruNTS1qIHuPspQerVw== Message-ID: In-Reply-To: <5DD4D480-328E-4CE4-B9C0-DE65B76597D4@townsley.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CBBB1B7F4B232cdonleycablelabscom_" MIME-Version: 1.0 X-Approved: ondar Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 23:01:42 -0000 --_000_CBBB1B7F4B232cdonleycablelabscom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Mark, Please see in-line. Chris From: Mark Townsley > Date: Mon, 23 Apr 2012 11:27:36 -0600 To: "v6ops@ietf.org" > Subject: [v6ops] 6rd sunsetting requirements for 6204-bis 6RD-4: A CE router MUST allow 6rd virtual and IPv6 native WAN interfaces to= be active simultaneously in order to support coexistence of the two technologies during an incremental migration period from 6rd to native IPv6. 1. I think this is covered in 6rd-5 and 6rd-7. 2. I don't think this specific requirement was agreed to in Paris. It's = not on your slide 4 or Slide 15, bullet 1, which were the 'hum's I captured= in my notes. 3. +1 to Hemant's comment =96 I don't think this is needed as a MUST. 6RD-5: The CE router MUST associate delegated prefixes with the WAN interface(s) they were learned from (e.g., DHCPv6-PD, 6rd, etc). Each packet sent out a WAN interface MUST have a source address that corresponds to a delegated prefix associated with the given WAN interface, consistent with what is described in section 4.3 of BCP 84 (RFC 3704). 1. We've been advised by the WG in the past to only include a single norm= ative statement per requirement. 2. This is covered in the existing 6rd-4. 6RD-6: The IPv6 CE router MUST allow different or identical delegated prefi= xes on 6rd and native interfaces. A 6rd virtual interface MUST be assigned a higher routing cost than a native IPv6 interface. This is done so that nati= ve traffic will be preferred over 6rd in the event normal IP longest matching and BCP 84 rules would have otherwise allowed a packet to be equally sent via 6rd or native IPv6. 1. I think this language (=85MUST allow different or identical delegated = prefixes=85) is confusing for people not intimately familiar with your othe= r CE transitioning draft. 2. If I read this correctly, you want to require two operational states = =96 one where 6rd and native IPv6 use the same prefix and a second where th= ey use different prefixes. That requirement is captured in 6rd-5. 3. As I mentioned above, we have been advised to keep requirements to a s= ingle normative statement, so the part about the routing cost is in 6rd-6. 4. I've heard from some CPE vendors that specifying routing "cost" may be= too implementation specific =96 I think it's more neutral to speak of pref= erence =96 e.g. prefer native to 6rd. --_000_CBBB1B7F4B232cdonleycablelabscom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Mark,

Pleas= e see in-line.

Chris
=

= From: Mark Townsley <mark@t= ownsley.net>
Date: Mon, = 23 Apr 2012 11:27:36 -0600
To: = "v6ops@ietf.org" <v6ops@ietf.org>
Subject: [v6ops] 6rd sunsetting requirements for 6204-b= is

6RD-4: A CE ro= uter MUST allow 6rd virtual and IPv6 native WAN interfaces to be
<= div>active simultaneously in order to support coexistence of the two
technologies during an incremental migration period from 6rd to nat= ive
IPv6. 
  1. I think this is covered in 6rd-5 and 6rd-7. =  
  2. I don't think this specific requirement was agreed to in Par= is.  It's not on your slide 4 or Slide 15, bullet 1, which were the 'h= um's I captured in my notes.
  3. +1 to Hemant's comment =96 I don't= think this is needed as a MUST.
=
6RD-5: The CE router MUST associate delegated prefixes with the WA= N
interface(s) they were learned from (e.g., DHCPv6-PD, 6rd, = etc). Each
packet sent out a WAN interface MUST have a source= address that
corresponds to a delegated prefix associated wi= th the given WAN
interface, consistent with what is described= in section 4.3 of BCP
84 (RFC 3704).
=
  1. We've been advised by = the WG in the past to only include a single normative statement per require= ment.
  2. This is covered in the existing 6rd-4.

6RD-6: The IPv6 CE router MUST allow different= or identical delegated prefixes
on 6rd and native interfaces= . A 6rd virtual interface MUST be assigned a 
higher ro= uting cost than a native IPv6 interface. This is done so that native <= /div>
traffic will be preferred over 6rd in the event no= rmal IP longest matching 
and BCP 84 rules would have otherw= ise allowed a packet to be equally sent 
via 6rd or native I= Pv6.
  1. I think this language (=85MUST allow differ= ent or identical delegated prefixes=85) is confusing for people not intimat= ely familiar with your other CE transitioning draft. 
  2. If I rea= d this correctly, you want to require two operational states =96 one where = 6rd and native IPv6 use the same prefix and a second where they use differe= nt prefixes. That requirement is captured in 6rd-5.
  3. As I mentioned = above, we have been advised to keep requirements to a single normative stat= ement, so the part about the routing cost is in 6rd-6.
  4. I've heard f= rom some CPE vendors that specifying routing "cost" may be too im= plementation specific =96 I think it's more neutral to speak of preference = =96 e.g. prefer native to 6rd.
--_000_CBBB1B7F4B232cdonleycablelabscom_-- From xing@cernet.edu.cn Mon Apr 23 17:48:44 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9086121F8704 for ; Mon, 23 Apr 2012 17:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4bczFl4Cj2Kd for ; Mon, 23 Apr 2012 17:48:44 -0700 (PDT) Received: from cernet.edu.cn (mail.cernet.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with ESMTP id 8DAA621F86E1 for ; Mon, 23 Apr 2012 17:48:42 -0700 (PDT) Received: from [127.0.0.1] (unknown [202.38.102.1]) by centos (Coremail) with SMTP id AQAAf3CroAJ795VPEPsCAA--.12880S2; Tue, 24 Apr 2012 08:44:44 +0800 (CST) Message-ID: <4F95F852.7030703@cernet.edu.cn> Date: Tue, 24 Apr 2012 08:48:18 +0800 From: Xing Li User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Fred Baker References: <43F84362-C062-401E-97D5-C8DB27CE0E1F@cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CM-TRANSID: AQAAf3CroAJ795VPEPsCAA--.12880S2 X-Coremail-Antispam: 1UD129KBjvJXoWxJr1xuw43AFWkuw4kAF1kZrb_yoW8CF15pa 9rKw4UGrWkJF1rGw1vgw1UWr4YyrykG3yUC3Z5t34Iya98J3WIyrW2yrn09a4DArs5Jr1q qw4j9r1UXa1kA3DanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUgj14x267AKxVW8JVW5JwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2ocxC64kIII0Yj41l84ACjcxK6xIIjxv20xvE14 v26r4j6ryUM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26r4j6F4UM28EF7xvwVC2z280aVAF wI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIEc7CjxVAFwI0_Gr1j6F4UJwAS0I0E0xvYzxvE52 x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC2z280aVAFwI0_Jr0_Gr1l Ox8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcVAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxw CYjI0SjxkI62AI1cAE67vIY487MxkIecxEwVAFwVWDMxAIw28IcxkI7VAKI48JMI8I3I0E 5I8CrVAFwI0_Jr0_Jr4lx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUtV W8ZwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY 1x0267AKxVWUJVW8JwCI42IY6xAIw20EY4v20xvaj40_WFyUJVCq3wCI42IY6I8E87Iv67 AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r4j6r4UJbIYCTnIWIevJa73UjIFyTuY vjfUYPEfUUUUU X-CM-SenderInfo: p0lqwqxfhu0vvwohv3gofq/ Cc: IPv6 Operations , Ron Bonica , Congxiao Bao Subject: Re: [v6ops] draft-ietf-v6ops-ivi-icmp-address WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 00:48:44 -0000 Hi, Fred and All, Thanks for managing the WGLC for draft-ietf-v6ops-ivi-icmp-address WGLC. Your summary is accurate. Even we think the combination of WKP and RFC5837 is a good method, we also fully understand the worries concerning the uRPF issues of the WKP. Therefore, we will update this draft focusing on the use of public IPv4 address (interface, loopback, or even a pool shared by several stateless translators) + RFC5837 and looking for the WG review. Regards, xing 于 2012/4/13 1:21, Fred Baker ċ†™é“: > So, let me see if I can summarize the comments so far. I'm going to leave out a lot of detail, and focus on the big picture, and in that I *think* develop a way forward. This is not a pronouncement, it's a question, and what I'm looking for is agreement, disagreement, and additional nuance where needed. > > I haven't heard any complaints about using RFC 5837 extensions to identify the actual IPv6 address of a system that is identifying a problem. I have heard that currently-deployed applications may or may not use it effectively, and so it is less useful than it might be. > > What I have heard is an issue about using a specified IPv4 address as source in data directed from the translator to an application. Issues raised include BCP 38 issues, operational requirements to advertise an address that is not intended to be used as a destination, and the possibility of attacks on that address. > > So, I think the fairest thing we can say is that working group consensus does not support the draft as it stands, and specifically does not support the allocation of a prefix for the purpose. What the working group *might* support is guidance on how best to use RFC 5837 for the purpose. > > Your thoughts? > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From fred@cisco.com Mon Apr 23 22:54:32 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B84C11E8099 for ; Mon, 23 Apr 2012 22:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.626 X-Spam-Level: X-Spam-Status: No, score=-110.626 tagged_above=-999 required=5 tests=[AWL=-0.027, 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 vzCc+tj2Lk+L for ; Mon, 23 Apr 2012 22:54:32 -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 18BA611E8081 for ; Mon, 23 Apr 2012 22:54:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=462; q=dns/txt; s=iport; t=1335246872; x=1336456472; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=kC+m72abEN+ZdeQ6VLwIYJyFouP9yxihSmcSIoLoPVA=; b=OXQCXlFYU367S33D6O32hliWZAW8jXU6Z3Q5pS50YM6S3WdytzIJhnCg +OhK7WcaBqimKC41WesiQQJcI4AaYmG7nIe3siV6Q4S+sPjSCqkDdmALM zO7WS3i5WZ1Q6wdfNQxWm/eMjTiBoI9TJJl/Zi8PKe92SEqHDjT4gtNtw o=; X-IronPort-AV: E=Sophos;i="4.75,471,1330905600"; d="scan'208";a="41889738" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 24 Apr 2012 05:54:31 +0000 Received: from Freds-Computer.local (sjc-vpn4-41.cisco.com [10.21.80.41]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3O5sHhx008541; Tue, 24 Apr 2012 05:54:30 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Tue, 24 Apr 2012 07:54:31 +0200 X-PGP-Universal: processed; by Freds-Computer.local on Tue, 24 Apr 2012 07:54:31 +0200 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <4F95F852.7030703@cernet.edu.cn> Date: Tue, 24 Apr 2012 07:54:12 +0200 Message-Id: References: <43F84362-C062-401E-97D5-C8DB27CE0E1F@cisco.com> <4F95F852.7030703@cernet.edu.cn> To: Xing Li X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations , Ron Bonica , Congxiao Bao Subject: Re: [v6ops] draft-ietf-v6ops-ivi-icmp-address WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 05:54:32 -0000 On Apr 24, 2012, at 2:48 AM, Xing Li wrote: > Your summary is accurate. Even we think the combination of WKP and = RFC5837 is a good method, we also fully understand the worries = concerning the uRPF issues of the WKP. Therefore, we will update this = draft focusing on the use of public IPv4 address (interface, loopback, = or even a pool shared by several stateless translators) + RFC5837 and = looking for the WG review. That seems reasonable.= From newbery@gmail.com Mon Apr 23 23:00:56 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B393721F8541; Mon, 23 Apr 2012 23:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQjbgjLocLLX; Mon, 23 Apr 2012 23:00: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 732B321F855D; Mon, 23 Apr 2012 23:00:55 -0700 (PDT) Received: by iazz13 with SMTP id z13so620452iaz.31 for ; Mon, 23 Apr 2012 23:00:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=EDR5EJx2e1HD7zZ5c57oJTPSkM7HQ0oq3w+QnfCwCIU=; b=Cj/cAF3Tbj+pRwQ7NsXUIErgIt3So9TWs69NWOdjjeAmJbsO0GQrdRMlUaALOlxhiW jNeAKxJB75HL342C/+ijMIKXPXvJAY06AZqv7aNpzxcEpxCD1cH0y0mlq5ywr6u5INm8 2vRh9c/c6dOCdUeL8GdkFJjGMzv4eFxVGHhTuhyNBEqn9kJEjQdQCw9B+DBB8PCOO3hV 47jblKTa+LLPUfNqGuWmSbY6rjhuFuZHyqLmNAPRC9ygprDccIU0sva6okTRjDvvzV6H GUFdd06CkoAEEzgy2q1o/qMjMm8BtpF/ArRbK9T8sxnhS4eK/KOx+VYkBVHgURHENLHW zgJA== Received: by 10.50.158.234 with SMTP id wx10mr8415999igb.71.1335247255088; Mon, 23 Apr 2012 23:00:55 -0700 (PDT) Received: from [10.201.64.122] ([203.98.18.214]) by mx.google.com with ESMTPS id k8sm31641385igz.4.2012.04.23.23.00.51 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 Apr 2012 23:00:53 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-1-457761672; protocol="application/pkcs7-signature"; micalg=sha1 From: Michael Newbery In-Reply-To: <20120418143817.19669.70000.idtracker@ietfa.amsl.com> Date: Tue, 24 Apr 2012 18:00:46 +1200 Message-Id: <829911B8-D986-4381-92FE-C85F2C260EB5@gmail.com> References: <20120418143817.19669.70000.idtracker@ietfa.amsl.com> To: Internet-Drafts@ietf.org X-Mailer: Apple Mail (2.1084) Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D ACTION:draft-ietf-v6ops-icp-guidance-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 06:00:56 -0000 --Apple-Mail-1-457761672 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > 5.2. Routing >=20 > In a dual stack network, IPv4 and IPv6 routing protocols operate > quite independently and in parallel. The common routing protocols > all exist in IPv6 versions, such as OSPFv3 [RFC5340], IS-IS > [RFC5308], and even RIPng [RFC2080] [RFC2081]. For trained staff, >=20 >=20 Is it worthwhile to mention the potential advantage of IS-IS here? = Offset of course with the cost of converting the IPv4 routing to use = IS-IS as well if that is not already what you do. This is simply to = point out the situation, rather than to recommend. > 6. Load Balancers >=20 > It is to be expected that IPv6 traffic will initially be low, i.e. = a > small percentage of IPv4 traffic. For this reason, updating load > balancers to fully support IPv6 can perhaps be delayed; however, = such >=20 However, anyone deploying a load balancer is also probably relying on it = providing fail-over protection and so needs to be aware that by = deferring IPv6 support they lose that as well, not just the = load-balancing. --Apple-Mail-1-457761672 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFNDCCBTAw ggMYoAMCAQICAwsyLjANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjAxMDkwNzUxNDdaFw0x MjA3MDcwNzUxNDdaMDwxGDAWBgNVBAMTD0NBY2VydCBXb1QgVXNlcjEgMB4GCSqGSIb3DQEJARYR bmV3YmVyeUBnbWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCwXUkCUQ3y bOYo9Yfpy3qkrF24CUG6Pej/JIQaz8tuzphNo19AqS3o9OQmjGZrptJFG0w4kbyqjMmG0T4dZl8b cuYYLMGxhGZjj+iIb/njKViaiHPma2+iP7TDgcD91GQy9zeKLf2SSFdFddyScFN7bOGJElcNGIUD V2v48ItQghf9kYJV3YxKMPp3R7LArB3JYVCoSfpjYDPZbIagQI+ul1tmL08Vim4IOu6BvRxOWW87 1mZXIqvfG1fRiMnF0QjsXGwjVLr/7PliOBDg5TICKlgVRqbfdwH9LKs+cW9wsufOwfPhQZ+qcXxI 6gKhdYlNPayV2psJTsSX+jDx0Gz1AgMBAAGjgf0wgfowDAYDVR0TAQH/BAIwADBWBglghkgBhvhC AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo dHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEE AYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzAB hhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMBwGA1UdEQQVMBOBEW5ld2JlcnlAZ21haWwuY29tMA0G CSqGSIb3DQEBBQUAA4ICAQBtei29qyBOztk74XBvoJwZ15ydDMFnmsON1TR01e0FV4jgzZ3BjZNG kwp+7vlBZOkkW0kZNJ4aad2nxuk/T9edC5TG5f+C2nIxXTkibwh28aRgMErNaXWKgWWN+eTYUNPB eiu9ZKAIY7ZWIhj+IfOVooexSvgwRrCeAcY4GuXzkV1K8qdWAwYiYc8waVEB195Ew3z5Lb/TFLPH eOFjJrRNiQ2O1PTzJVKFL1pNbCyjV9vkoJgHXqC39QCuVV42qFYCXAHieiOr1Sf/mTuPoFrZlTEa 9TMLKl78dBBvZ2/BIRa+rAQKFAG7Iz/Qes/kZcydkt9WL54g+aYmInww6Qubj3fAF4th0MQQHvOi HB3QjC7kn06K6nlAc7QJUfdsB3ZwqLJzVppwJgRVoPdBT+M0rMhsi24MWzRCLhQc6+HGPdCvWmGG Lqjet/qyb0XMpXvC+gcY3QXpwoc04gxwj05QDrnXRXgED56hkS1Yw2YFGPjxX8Nk5BmxlRB8O8Kq DsnVx6H/JLTAwMhCPWWzftcBmX91N2Ks/aJPY4Y+wFxH6rvihxp3V7ZfAZ0ilJvBNhb+anXHMPMn jmtPq+5kAT/nj/AgbYIMDxQD35+k0JvD7ww1wzFEJ/yogyO4MF0xyXRtEEZYdE3lQcveIuRFzXtW almhg7N7zawEcIEQtFjMFTGCAzMwggMvAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNV BAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhv cml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMLMi4wCQYFKw4DAhoFAKCC AYcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIwNDI0MDYwMDQ3 WjAjBgkqhkiG9w0BCQQxFgQUBsIDxNguEbCnqScALtHgipY67vUwgZEGCSsGAQQBgjcQBDGBgzCB gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAg BgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRA Y2FjZXJ0Lm9yZwIDCzIuMIGTBgsqhkiG9w0BCRACCzGBg6CBgDB5MRAwDgYDVQQKEwdSb290IENB MR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCzIuMA0GCSqG SIb3DQEBAQUABIIBADMwSJtXg/npaCDRFjFb/ngjaTDumVvwuTyZNE0HCjFulOW3Ah6JcYpM2MK3 VjvENtJMcExTdjTRpq7s3WiAAg874NcauMiJxFYBeh3m4VZU/XN1guw4+FmTM9bASpIjAKfNtcP2 btM9Pt40esth31RInY9mOifRpSNd7fNSIHnkcnpynqlEDB6JAvYW/4EkcI1EPaFuTQgJLOqu4ej+ reOVhxiBFbqr5GRGKFgVZfwhwyhbbF0cBmlq1wWIjP3pafVHD4HsK/5VViIHVb85TiBxRP1+3MO5 j5BtdA2c1zn8RJB0y2OOWlz+ot/lCGNaT7B93W6p80yas88zTzFL+KYAAAAAAAA= --Apple-Mail-1-457761672-- From phdgang@gmail.com Mon Apr 23 23:01:09 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F26E611E809B for ; Mon, 23 Apr 2012 23:01:08 -0700 (PDT) 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 1eYU2ZTodlgH for ; Mon, 23 Apr 2012 23:01:07 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE8611E8099 for ; Mon, 23 Apr 2012 23:01:05 -0700 (PDT) Received: by werb10 with SMTP id b10so207975wer.31 for ; Mon, 23 Apr 2012 23:01:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8hPvahK5HzUrfDiIQSfOAftaUxRtCfF+1BPYb71arMg=; b=0i3r93S1pM4zkZut83gV5a9WRcMOVEJ7T+KLP6m0XE+onHq3v8K0Ym5Xw1sVIWjvRV IDOEH1yNz5ykRqq8wc3fBIV9F2gskgmu3JrulJ+tRshQZo8PlJwP0lNwKiB0aRSujWrB HGHy8IcCTQedt5cYcSMtsogam0sJ9Ndvqt3PK/XhHrAWkvrTwIlJ8gTpbN0kiqcNKc/K AFJpQp4Prs7+AYMU+X3N7JAFWIHF8Bz0vbp3b3Pb3G9lUfTkUrmNCUUeRDv6ZmcIp97S btUNo0UkX/S0akQ5av9R6hkC3Un/Jrt8Cb7J8TGnNQKtWlBMJzgKqS9LgqI6CyghPD0l 9EQA== MIME-Version: 1.0 Received: by 10.180.102.100 with SMTP id fn4mr6416466wib.1.1335247265246; Mon, 23 Apr 2012 23:01:05 -0700 (PDT) Received: by 10.180.106.38 with HTTP; Mon, 23 Apr 2012 23:01:05 -0700 (PDT) In-Reply-To: <20120423105716.130762z7e8air84c@mail.drown.org> References: <20120417065542.31115.95082.idtracker@ietfa.amsl.com> <20120417160010kawashimam@mail.jp.nec.com> <56E2AD61-1C91-4889-914A-353793FCBE43@laposte.net> <20120419121044.17531mk1mv19abr4@mail.drown.org> <0646611B-5594-40EA-A2C4-F99CBA734024@laposte.net> <20120419181813.4524701l3gkq5zks@mail.drown.org> <45ABAD31-C265-4D63-82E2-3DE6F59B80C0@laposte.net> <20120420104246.1432746csfcrdqo8@mail.drown.org> <20120423105716.130762z7e8air84c@mail.drown.org> Date: Tue, 24 Apr 2012 14:01:05 +0800 Message-ID: From: GangChen To: Dan Drown Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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, 24 Apr 2012 06:01:09 -0000 Hello Dan 2012/4/23, Dan Drown : > http://linux-hacks.blogspot.com/2008/07/default-address-selection-part-2.html > > has a good description of the process if you want more detail. But in > this case (two addresses with the same scope on different interfaces), > Linux will prefer the address on the interface associated with the > route to the destination. Thanks for providing the information. I listed below to double confirm the process Assuming IPv6 apps on the CLAT would talk to severs either on cell network side or wifi tethering network side I guess CLAT should bind apps to different interface (i.e PPP int or eth int) according to the route to the destination. Eg: PPP_int: 2607:fb90:800:68c::eae6:901 eth_int: 2607:fb90:800:68c::eae6:901 In the case, CLAT set default gateway pointing to 3GPP interface(i.e. PPP_int) Des: eth_int 2607:fb90:800:68c::eae6:902 Select: eth_int: 2607:fb90:800:68c::eae6:901 BRs Gang From Carl.Wuyts@technicolor.com Mon Apr 23 23:02:35 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ACE611E80AB for ; Mon, 23 Apr 2012 23:02:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d5WvHWP8g5Gb for ; Mon, 23 Apr 2012 23:02:32 -0700 (PDT) Received: from na3sys009aog127.obsmtp.com (na3sys009aog127.obsmtp.com [74.125.149.107]) by ietfa.amsl.com (Postfix) with ESMTP id 99A7611E80AA for ; Mon, 23 Apr 2012 23:02:28 -0700 (PDT) Received: from mopesedge02.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob127.postini.com ([74.125.148.12]) with SMTP ID DSNKT5ZB81yhZNOgG5dzYf+k1cM3/9/9HbVb@postini.com; Mon, 23 Apr 2012 23:02:31 PDT Received: from MOPESMAILHC02.eu.thmulti.com (141.11.100.29) by mopesedge02.eu.thmulti.com (141.11.253.23) with Microsoft SMTP Server (TLS) id 8.3.192.1; Tue, 24 Apr 2012 07:59:40 +0200 Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.134]) by MOPESMAILHC02.eu.thmulti.com ([141.11.100.29]) with mapi; Tue, 24 Apr 2012 07:59:47 +0200 From: Wuyts Carl To: Chris Donley , Mark Townsley , "v6ops@ietf.org" Date: Tue, 24 Apr 2012 07:59:45 +0200 Thread-Topic: [v6ops] 6rd sunsetting requirements for 6204-bis Thread-Index: Ac0hpQjBW+0+ruNTS1qIHuPspQerVwAOQBjw Message-ID: <867F4B6A1672E541A94676D556793ACD108F21A569@MOPESMBX01.eu.thmulti.com> References: <5DD4D480-328E-4CE4-B9C0-DE65B76597D4@townsley.net> 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_867F4B6A1672E541A94676D556793ACD108F21A569MOPESMBX01eut_" MIME-Version: 1.0 Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 06:02:35 -0000 --_000_867F4B6A1672E541A94676D556793ACD108F21A569MOPESMBX01eut_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 on Hemants comment. However. Again new requirements are added to the RFC6204, so again more pr= essure is put upon the CPE vendors to be "IPv6-ready", to be "IPv6-complian= t". I don't get it. At the v6 world congress in Paris last February (panel 'ca= n we get an IPV6 CPE please') I think it was clear from all present CPE ven= dors in the panel that it's time to STOP adding requirements over and over = again to the RFC6204, so to finally have a basic set of requirements. But a= gain, reqs are added, so again it will not be possible to have compliancy w= ithin a decent time frame. I've been present on the last 2 v6 world congresses in Paris and the genera= l statements there were always "the CPE is the problem". Well, guess what,= it still is, and it still will be if you don't stop adding requirements. = Please draw a line NOW, and take changes and added requirements into a late= r version so the CPE vendor has the time to cope with all of this!!! I rep= eat my statement from the panel: if we don't stop adding requirements onto = the (nearly free-of-charge) CPE, the next v6 congress will have again sever= al presentations claiming "The CPE is the problem". Just on these specific ones: there is the claim that CPE devices are not "r= eady" (whatever that may mean"). Today, IPv6 roll-out is, unfortunately, s= till very (too) limited, but already "6rd sunsetting" requirements are bein= g added to the basic CPE IPV6 reqs, why ? I don't doubt this issue will pr= esent itself, but for sure not "tomorrow". Regs Carl From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of C= hris Donley Sent: dinsdag 24 april 2012 1:04 To: Mark Townsley; v6ops@ietf.org Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis Mark, Please see in-line. Chris From: Mark Townsley > Date: Mon, 23 Apr 2012 11:27:36 -0600 To: "v6ops@ietf.org" > Subject: [v6ops] 6rd sunsetting requirements for 6204-bis 6RD-4: A CE router MUST allow 6rd virtual and IPv6 native WAN interfaces to= be active simultaneously in order to support coexistence of the two technologies during an incremental migration period from 6rd to native IPv6. 1. I think this is covered in 6rd-5 and 6rd-7. 2. I don't think this specific requirement was agreed to in Paris. It's = not on your slide 4 or Slide 15, bullet 1, which were the 'hum's I captured= in my notes. 3. +1 to Hemant's comment - I don't think this is needed as a MUST. 6RD-5: The CE router MUST associate delegated prefixes with the WAN interface(s) they were learned from (e.g., DHCPv6-PD, 6rd, etc). Each packet sent out a WAN interface MUST have a source address that corresponds to a delegated prefix associated with the given WAN interface, consistent with what is described in section 4.3 of BCP 84 (RFC 3704). 1. We've been advised by the WG in the past to only include a single norm= ative statement per requirement. 2. This is covered in the existing 6rd-4. 6RD-6: The IPv6 CE router MUST allow different or identical delegated prefi= xes on 6rd and native interfaces. A 6rd virtual interface MUST be assigned a higher routing cost than a native IPv6 interface. This is done so that nati= ve traffic will be preferred over 6rd in the event normal IP longest matching and BCP 84 rules would have otherwise allowed a packet to be equally sent via 6rd or native IPv6. 1. I think this language (...MUST allow different or identical delegated = prefixes...) is confusing for people not intimately familiar with your othe= r CE transitioning draft. 2. If I read this correctly, you want to require two operational states -= one where 6rd and native IPv6 use the same prefix and a second where they = use different prefixes. That requirement is captured in 6rd-5. 3. As I mentioned above, we have been advised to keep requirements to a s= ingle normative statement, so the part about the routing cost is in 6rd-6. 4. I've heard from some CPE vendors that specifying routing "cost" may be= too implementation specific - I think it's more neutral to speak of prefer= ence - e.g. prefer native to 6rd. --_000_867F4B6A1672E541A94676D556793ACD108F21A569MOPESMBX01eut_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1 on Hem= ants comment.

 <= /o:p>

However.  Again new requir= ements are added to the RFC6204, so again more pressure is put upon the CPE= vendors to be “IPv6-ready”, to be “IPv6-compliant”= .

I don’t get it.&nb= sp; At the v6 world congress in Paris last February (panel ‘can we ge= t an IPV6 CPE please’) I think it was clear from all present CPE vend= ors in the panel that it’s time to STOP adding requirements over and = over again to the RFC6204, so to finally have a basic set of requirements. = But again, reqs are added, so again it will not be possible to have complia= ncy within a decent time frame. 

 

I= 217;ve been present on the last 2 v6 world congresses in Paris and the gene= ral statements there were always “the CPE is the problem”. = ; Well, guess what, it still is, and it still will be if you don’t st= op adding requirements.  Please draw a line NOW, and take changes and = added requirements into a later version so the CPE vendor has the time to c= ope with all of this!!!  I repeat my statement from the panel: if we d= on’t stop adding requirements onto the (nearly free-of-charge) CPE, t= he next v6 congress will have again several presentations claiming “T= he CPE is the problem”.

 

Just on these s= pecific ones: there is the claim that CPE devices are not “ready̶= 1; (whatever that may mean”).  Today, IPv6 roll-out is, unfortun= ately, still very (too) limited, but already “6rd sunsetting” r= equirements are being added to the basic CPE IPV6 reqs, why ?  I don&#= 8217;t doubt this issue will present itself, but for sure not “tomorr= ow”.

 

Regs

Carl

<= o:p> 

From: v6ops-bou= nces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Chris Don= ley
Sent: dinsdag 24 april 2012 1:04
To: Mark Townsley;= v6ops@ietf.org
Subject: Re: [v6ops] 6rd sunsetting requirements = for 6204-bis

&nb= sp;

Mark,

 

Please see in-line.

<= /div>

 

=

Chris<= /span>

 

From: Mark Townsley <mark@townsley.net>
Date: Mon, 23 Apr 2012 11:2= 7:36 -0600
To: "v6ops@ietf= .org" <v6ops@ietf.org>=
Subject: [v6ops] 6rd sunsetting requirements for 6204-bis

 

6RD-4: A CE router MUST allow 6rd= virtual and IPv6 native WAN interfaces to be

active simultaneously in order to support coex= istence of the two

technologies during an incremental migration period from 6rd to native

IPv6. 

  1. I think this is covered in 6rd-5 and 6rd-7.  
  2. I don't think this specific require= ment was agreed to in Paris.  It's not on your slide 4 or Slide 15, bu= llet 1, which were the 'hum's I captured in my notes.
  3. +1 to Hemant's comment – I don'= t think this is needed as a MUST.

 

6RD-5: The CE= router MUST associate delegated prefixes with the WAN

interface(s) they were learned from (= e.g., DHCPv6-PD, 6rd, etc). Each

packet sent out a WAN interface MUST have a source addres= s that

correspond= s to a delegated prefix associated with the given WAN

=

interface, consistent with what is des= cribed in section 4.3 of BCP

84 (RFC 3704).

  1. We've been advised by the WG in the = past to only include a single normative statement per requirement.
  2. This is covered in the e= xisting 6rd-4.

 

6RD-6: The IPv6 CE router MUST = allow different or identical delegated prefixes

=

on 6rd and native interfaces. A 6rd virtual = interface MUST be assigned a 

higher routing cost than a native IPv6 interface. Th= is is done so that native 

traffic will be preferred over 6rd in the event&nb= sp;normal IP longest matching 

and BCP 84 rules would have otherwise allowed a packet t= o be equally sent 

via 6rd or native IPv6.

  1. I think this language (…MU= ST allow different or identical delegated prefixes…) is confusing for= people not intimately familiar with your other CE transitioning draft.&nbs= p;
  2. If I read thi= s correctly, you want to require two operational states – one where 6= rd and native IPv6 use the same prefix and a second where they use differen= t prefixes. That requirement is captured in 6rd-5.
    3. As I mentioned above, we have been advis= ed to keep requirements to a single normative statement, so the part about = the routing cost is in 6rd-6.
  3. I've heard from some CPE vendors that specifying routing &quo= t;cost" may be too implementation specific – I think it's more n= eutral to speak of preference – e.g. prefer native to 6rd.=
= --_000_867F4B6A1672E541A94676D556793ACD108F21A569MOPESMBX01eut_-- From mark@townsley.net Mon Apr 23 23:09:36 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C04B11E80A4 for ; Mon, 23 Apr 2012 23:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 kPZBPWjLyZV9 for ; Mon, 23 Apr 2012 23:09:35 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5B65B21E8025 for ; Mon, 23 Apr 2012 23:09:34 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so193134wgb.13 for ; Mon, 23 Apr 2012 23:09:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=lemolwJXHa/p6tWlT0AcAC8Jq2o2k3wWA4o0B1FERus=; b=LhoMwsa4CbuoqVWu/66QmAgxrCDYOG9E9Z8y7yLY8MkDdvA9tBi/5IHUcxnv2u7ZZc 3rG+1D4o/yK1YDHpGSuJKv8IJuwTfRL5DpJowpEfPEQNzeNc+bvonNoqVrC2DCtj30xw xaC6jLCyekDyHx+ftpjdc0MGbLNT2BwBh+wgMDJ0STLmNgvt0uK91qR4M9hZvJ/31thw dLcnA/1xXvWwN7Molwe7lSdYwOzu6Z4SLmTPnUnaXnQJg4S2bF6ZZeSDlHfZTCc52W4O 66XLcUedLyAmlxihUzs+K7jYPmSL/BLgUTpJMtgDFbz8f04ujxS6PAtndm6ysra5S7QY OvOg== Received: by 10.216.139.67 with SMTP id b45mr1383991wej.0.1335247773402; Mon, 23 Apr 2012 23:09:33 -0700 (PDT) Received: from ams-townsley-8912.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id e6sm27790893wix.8.2012.04.23.23.09.25 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 Apr 2012 23:09:32 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_5178567C-D21A-4D88-9923-FD2E108AAD26" From: Mark Townsley In-Reply-To: Date: Tue, 24 Apr 2012 08:09:23 +0200 Message-Id: <08B3D023-C383-432F-840D-B688DCD0FB7F@townsley.net> References: To: Chris Donley X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQmFFYzXYgVdmnuUuqEioHfyAU4Td338LsU8Lb6NrRXCt1sHCE1IrW+k8bLpDeuNC+ZkKO7M Cc: "v6ops@ietf.org" Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 06:09:36 -0000 --Apple-Mail=_5178567C-D21A-4D88-9923-FD2E108AAD26 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Chris,=20 Here are the requirements you put in -08, and why they are lacking: =09 > 6RD-4: Per [RFC3704], Section 4.3, the CE router MUST send traffic=09= > using a prefix learned via 6rd over the 6rd tunnel.=09 You must also make sure that traffic sent over native IPv6 has a source = address learned from DHCPv6 PD for that interface. Doing it for 6rd = alone isn't enough for RFC 3704 behavior. > =09 > 6RD-5: The IPv6 CE router MUST support two operational modes:=09 > different prefixes on 6rd and native interfaces or = identical=09 > prefixes on 6rd and native interfaces.=09 I'm not sure why you introduced "operational modes" here. What needs to = be said is simply that interfaces receive delegated prefixes from = somewhere (6rd, DHCv6-PD, etc). They might end up being the same, and = that should not be interpreted as an error condition. It's not like the = CE has to "change mode" for this.=20 > =09 > 6RD-6: By default, the IPv6 CE router MUST prefer a native IPv6=09 > interface over a 6rd virtual interface.=09 The CE router must not prefer native over 6rd blindly. The preference is = only used as a "tie breaker" in the event that normal routing fails to = give you the right WAN egress to use. So, first you do normal IP = longest-match and RFC 3704 source-match, and *if and only if* that = results in an ambiguous choice do you select native over 6rd. It's a = simple routing metric. I think when you separated this single requirement into two, you lost = the sense of it in the process.=20 > =09 > 6RD-7: The IPv6 CE router SHOULD support independent WAN interface=09= > configuration for 6rd and native IPv6.=09 > =20 "Independent" does not mean the same thing as "simultaneously active." = 6rd and native must be active at the same time during the period an = operator is moving from 6rd to native, otherwise the operator loses = flexibility in doing so incrementally (e.g., user traffic may be dropped = as it is tunneled directly to a CPE that has disabled 6rd because it = detected an active native link). Also, you have three MUST requirements that are incumbent upon some form = of 6RD-7 being true, but for some reason you are making this one a = SHOULD. In sum, it seems you have taken the whole concept of 6rd and native IPv6 = operating at the same time to allow a smooth migration (e.g., = multihoming), and neutered it to a form that fits within the confines of = what you think a CPE should do. - Mark On Apr 24, 2012, at 1:03 AM, Chris Donley wrote: > Mark, >=20 > Please see in-line. >=20 > Chris >=20 > From: Mark Townsley > Date: Mon, 23 Apr 2012 11:27:36 -0600 > To: "v6ops@ietf.org" > Subject: [v6ops] 6rd sunsetting requirements for 6204-bis >=20 > 6RD-4: A CE router MUST allow 6rd virtual and IPv6 native WAN = interfaces to be > active simultaneously in order to support coexistence of the two > technologies during an incremental migration period from 6rd to native > IPv6.=20 > I think this is covered in 6rd-5 and 6rd-7. =20 > I don't think this specific requirement was agreed to in Paris. It's = not on your slide 4 or Slide 15, bullet 1, which were the 'hum's I = captured in my notes. > +1 to Hemant's comment =96 I don't think this is needed as a MUST. >=20 > 6RD-5: The CE router MUST associate delegated prefixes with the WAN > interface(s) they were learned from (e.g., DHCPv6-PD, 6rd, etc). Each > packet sent out a WAN interface MUST have a source address that > corresponds to a delegated prefix associated with the given WAN > interface, consistent with what is described in section 4.3 of BCP > 84 (RFC 3704). > We've been advised by the WG in the past to only include a single = normative statement per requirement. > This is covered in the existing 6rd-4. >=20 > 6RD-6: The IPv6 CE router MUST allow different or identical delegated = prefixes > on 6rd and native interfaces. A 6rd virtual interface MUST be assigned = a=20 > higher routing cost than a native IPv6 interface. This is done so that = native=20 > traffic will be preferred over 6rd in the event normal IP longest = matching=20 > and BCP 84 rules would have otherwise allowed a packet to be equally = sent=20 > via 6rd or native IPv6. > I think this language (=85MUST allow different or identical delegated = prefixes=85) is confusing for people not intimately familiar with your = other CE transitioning draft.=20 > If I read this correctly, you want to require two operational states =96= one where 6rd and native IPv6 use the same prefix and a second where = they use different prefixes. That requirement is captured in 6rd-5. > As I mentioned above, we have been advised to keep requirements to a = single normative statement, so the part about the routing cost is in = 6rd-6. > I've heard from some CPE vendors that specifying routing "cost" may be = too implementation specific =96 I think it's more neutral to speak of = preference =96 e.g. prefer native to 6rd. --Apple-Mail=_5178567C-D21A-4D88-9923-FD2E108AAD26 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
 6RD-4:  Per [RFC3704], Section 4.3, the CE = router MUST send traffic
    =        using a prefix learned via 6rd over the 6rd = tunnel. =

You must also make sure that = traffic sent over native IPv6 has a source address learned from DHCPv6 = PD for that interface. Doing it for 6rd alone isn't enough for RFC 3704 = behavior.

  =
  6RD-5:  The IPv6 CE router MUST support two = operational modes:
    =          different prefixes on 6rd and native = interfaces or identical
    =          prefixes on 6rd and native = interfaces. =

I'm not sure why you = introduced "operational modes" here. What needs to be said is = simply that interfaces receive delegated prefixes from somewhere (6rd, = DHCv6-PD, etc). They might end up being the same, and that should not be = interpreted as an error condition. It's not like the CE has to "change = mode" for this. 

 
  6RD-6:  By = default, the IPv6 CE router MUST prefer a native IPv6 =
 =           interface over a 6rd = virtual interface. =

The CE router must not = prefer native over 6rd blindly. The preference is only used as a "tie = breaker" in the event that normal routing fails to give you the right = WAN egress to use. So, first you do normal IP longest-match and RFC 3704 = source-match, and *if and only if* that results in an ambiguous choice = do you select native over 6rd. It's a simple routing = metric.

I think when you separated this = single requirement into two, you lost the sense of it in the = process. 

  =
  6RD-7:  The IPv6 CE router SHOULD support = independent WAN interface
    =          configuration for 6rd and native = IPv6. =
 =                 =                     =               =   

"Independent" does = not mean the same thing as "simultaneously active." 6rd and native must = be active at the same time during the period an operator is moving from = 6rd to native, otherwise the operator loses flexibility in doing so = incrementally (e.g., user traffic may be dropped as it is tunneled = directly to a CPE that has disabled 6rd because it detected an active = native link).

Also, you have three MUST = requirements that are incumbent upon some form of 6RD-7 being true, but = for some reason you are making this one a = SHOULD.

In sum, it seems you have taken the = whole concept of 6rd and native IPv6 operating at the same time to allow = a smooth migration (e.g., multihoming), and neutered it to a form that = fits within the confines of what you think a CPE should = do.

- Mark


On = Apr 24, 2012, at 1:03 AM, Chris Donley wrote:

Please see = in-line.


From: Mark Townsley <mark@townsley.net>
Date: Mon, 23 Apr 2012 11:27:36 = -0600
To: "v6ops@ietf.org" <v6ops@ietf.org>
Subject: [v6ops] 6rd sunsetting = requirements for 6204-bis

6RD-4: A = CE router MUST allow 6rd virtual and IPv6 native WAN interfaces to = be
active simultaneously in order to support coexistence = of the two
technologies during an incremental migration = period from 6rd to = native
IPv6. 
  1. I think this is covered = in 6rd-5 and 6rd-7.  
  2. I don't think this specific = requirement was agreed to in Paris.  It's not on your slide 4 or = Slide 15, bullet 1, which were the 'hum's I captured in my = notes.
  3. +1 to Hemant's comment =96 I don't think this is needed = as a MUST.
  • We've been advised by the WG in the past to only = include a single normative statement per requirement.
  • This is = covered in the existing 6rd-4.

    • = --Apple-Mail=_5178567C-D21A-4D88-9923-FD2E108AAD26-- From mark@townsley.net Mon Apr 23 23:32:07 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A12B811E8081 for ; Mon, 23 Apr 2012 23:32:07 -0700 (PDT) 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 e8XKY2PWkBvd for ; Mon, 23 Apr 2012 23:32:06 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id E7D8C11E8080 for ; Mon, 23 Apr 2012 23:32:05 -0700 (PDT) Received: by wibhr17 with SMTP id hr17so3183359wib.1 for ; Mon, 23 Apr 2012 23:32:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=rNfFUterSqMDp1eKaBlxwb3SqZK+bio+BCHYRQGZvaY=; b=JmL593qlbozF1LYNajjYzeOYfWj1ejsP8VDTpIuhvyo/HmnzwA+ROao7L8Wqg2vit2 OAuBcVkVhpLo5Swi7idxTiHDk2GGWDXGfY5zOgWx1r4tCbnlBFoM2z3aDOiDsZHJjfjN 9mdImFmOcJwB0iozixYsaJbma2JBUbNE1zlt1ehCPUsa8m/mNZwK7LDaMh2VoKmkI+BX 1AVn0kCebrvHMuxKPEadDSa/qM/RNoj3YgVwbRKp1nrFP72UCpszNsXNVfXEtWQE3+o+ vb72L1OH8kIkrR+rKHNfo/pMC0fOySS7q+3HVzfheXdA1811sVm87G/H4TNAK8Y3vO6P 9nmA== Received: by 10.180.100.230 with SMTP id fb6mr31625551wib.3.1335249123915; Mon, 23 Apr 2012 23:32:03 -0700 (PDT) Received: from ams-townsley-8912.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id gg2sm43646753wib.7.2012.04.23.23.31.57 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 Apr 2012 23:32:03 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_19A5540B-9D6F-4E32-A628-3DDBAD936AFF" From: Mark Townsley In-Reply-To: <867F4B6A1672E541A94676D556793ACD108F21A569@MOPESMBX01.eu.thmulti.com> Date: Tue, 24 Apr 2012 08:31:55 +0200 Message-Id: References: <5DD4D480-328E-4CE4-B9C0-DE65B76597D4@townsley.net> <867F4B6A1672E541A94676D556793ACD108F21A569@MOPESMBX01.eu.thmulti.com> To: Wuyts Carl X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQmng3zLD8m+J/gVlKzoS8jefX42VoCzkG15cp/8/ylllKGyTn6UivqlcKuYAWI2fEAb0VcX Cc: "v6ops@ietf.org" Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 06:32:07 -0000 --Apple-Mail=_19A5540B-9D6F-4E32-A628-3DDBAD936AFF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Apr 24, 2012, at 7:59 AM, Wuyts Carl wrote: > +1 on Hemants comment. You mean this comment? Hemant: "Sorry, still does not cut it for me. Fix the bug in the CPE router. = We cannot add every bug found in the CPE router for a requirement to the = document. This is extremely basic router functionality where a router = should support concurrent tunneled and native IP interfaces." I really don't think that lack of support of IPv6 multihoming in a CPE = router is a simple bug that should obviously be fixed by every CPE = vendor. I wish that were true, but its not. >=20 > However. Again new requirements are added to the RFC6204, so again = more pressure is put upon the CPE vendors to be =93IPv6-ready=94, to be = =93IPv6-compliant=94. > I don=92t get it. At the v6 world congress in Paris last February = (panel =91can we get an IPV6 CPE please=92) I think it was clear from = all present CPE vendors in the panel that it=92s time to STOP adding = requirements over and over again to the RFC6204, so to finally have a = basic set of requirements. But again, reqs are added, so again it will = not be possible to have compliancy within a decent time frame.=20 It seems the real scope-creep you are talking about is the addition of = 6rd and DS-Lite to begin with.=20 All I am trying to do is make sure that *if* 6rd is in the document, it = is done correctly so we don't paint ourselves into a corner.=20 I was also trying to do the same with DS-Lite, but have decided to give = up. DS-Lite has become an enormous distraction to the deployment of IPv6 = service to internet users, so I'm going to stop investing energy into = trying to fix it here. Maybe v4-exit can do better in 6204-ter (sigh).=20= As I have said before, I am equally happy with the entire "Transition" = section to be removed from 6204-bis. But, if we step off the cliff, = we're going to get it right, at least for 6rd. Otherwise, it does more = harm than good. > I=92ve been present on the last 2 v6 world congresses in Paris and the = general statements there were always =93the CPE is the problem=94. = Well, guess what, it still is, and it still will be if you don=92t stop = adding requirements.=20 > Please draw a line NOW, and take changes and added requirements into a = later version so the CPE vendor has the time to cope with all of this!!! = I repeat my statement from the panel: if we don=92t stop adding = requirements onto the (nearly free-of-charge) CPE, the next v6 congress = will have again several presentations claiming =93The CPE is the = problem=94. > =20 > Just on these specific ones: there is the claim that CPE devices are = not =93ready=94 (whatever that may mean=94). Today, IPv6 roll-out is, = unfortunately, still very (too) limited, but already =936rd sunsetting=94 = requirements are being added to the basic CPE IPV6 reqs, why ? I don=92t = doubt this issue will present itself, but for sure not =93tomorrow=94. That's why: - Mark > =20 > Regs > Carl > =20 > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Chris Donley > Sent: dinsdag 24 april 2012 1:04 > To: Mark Townsley; v6ops@ietf.org > Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis > =20 > Mark, > =20 > Please see in-line. > =20 > Chris > =20 > From: Mark Townsley > Date: Mon, 23 Apr 2012 11:27:36 -0600 > To: "v6ops@ietf.org" > Subject: [v6ops] 6rd sunsetting requirements for 6204-bis > =20 > 6RD-4: A CE router MUST allow 6rd virtual and IPv6 native WAN = interfaces to be > active simultaneously in order to support coexistence of the two > technologies during an incremental migration period from 6rd to native > IPv6.=20 > I think this is covered in 6rd-5 and 6rd-7. =20 > I don't think this specific requirement was agreed to in Paris. It's = not on your slide 4 or Slide 15, bullet 1, which were the 'hum's I = captured in my notes. > +1 to Hemant's comment =96 I don't think this is needed as a MUST. > =20 > 6RD-5: The CE router MUST associate delegated prefixes with the WAN > interface(s) they were learned from (e.g., DHCPv6-PD, 6rd, etc). Each > packet sent out a WAN interface MUST have a source address that > corresponds to a delegated prefix associated with the given WAN > interface, consistent with what is described in section 4.3 of BCP > 84 (RFC 3704). > We've been advised by the WG in the past to only include a single = normative statement per requirement. > This is covered in the existing 6rd-4. > =20 > 6RD-6: The IPv6 CE router MUST allow different or identical delegated = prefixes > on 6rd and native interfaces. A 6rd virtual interface MUST be assigned = a=20 > higher routing cost than a native IPv6 interface. This is done so that = native=20 > traffic will be preferred over 6rd in the event normal IP longest = matching=20 > and BCP 84 rules would have otherwise allowed a packet to be equally = sent=20 > via 6rd or native IPv6. > I think this language (=85MUST allow different or identical delegated = prefixes=85) is confusing for people not intimately familiar with your = other CE transitioning draft.=20 > If I read this correctly, you want to require two operational states =96= one where 6rd and native IPv6 use the same prefix and a second where = they use different prefixes. That requirement is captured in 6rd-5. > As I mentioned above, we have been advised to keep requirements to a = single normative statement, so the part about the routing cost is in = 6rd-6. > I've heard from some CPE vendors that specifying routing "cost" may be = too implementation specific =96 I think it's more neutral to speak of = preference =96 e.g. prefer native to 6rd. --Apple-Mail=_19A5540B-9D6F-4E32-A628-3DDBAD936AFF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
    On Apr 24, 2012, at 7:59 AM, Wuyts = Carl wrote:

    +1 on = Hemants = comment.

    Y= ou mean this = comment?

    Hemant:

    "Sorry,= still does not cut it for me.  Fix the bug in the CPE router. =  We cannot add every bug found in the CPE router for a = requirement to the document.  This is extremely basic = router functionality where a router should support concurrent = tunneled and native IP interfaces."

    I really = don't think that lack of support of IPv6 multihoming in a CPE router is = a simple bug that should obviously be fixed by every CPE vendor. I wish = that were true, but its not.


    I don=92t get it.  At the v6 = world congress in Paris last February (panel =91can we get an IPV6 CPE = please=92) I think it was clear from all present CPE vendors in the = panel that it=92s time to STOP adding requirements over and over again = to the RFC6204, so to finally have a basic set of requirements. But = again, reqs are added, so again it will not be possible to have = compliancy within a decent time = frame. 

    It = seems the real scope-creep you are talking about is the addition of 6rd = and DS-Lite to begin with. 

    All I am = trying to do is make sure that *if* 6rd is in the document, it is done = correctly so we don't paint ourselves into a = corner. 

    I was also trying to do the same = with DS-Lite, but have decided to give up. DS-Lite has become an = enormous distraction to the deployment of IPv6 service to internet = users, so I'm going to stop investing energy into trying to fix it here. = Maybe v4-exit can do better in 6204-ter = (sigh). 

    As I have said before, I am = equally happy with the entire "Transition" section to be removed from = 6204-bis. But, if we step off the cliff, we're going to get it right, at = least for 6rd. Otherwise, it does more harm than = good.


    I=92ve been = present on the last 2 v6 world congresses in Paris and the general = statements there were always =93the CPE is the problem=94.  Well, = guess what, it still is, and it still will be if you don=92t stop adding = requirements. 
    Please draw a line NOW, and take = changes and added requirements into a later version so the CPE vendor = has the time to cope with all of this!!!  I repeat my statement = from the panel: if we don=92t stop adding requirements onto the (nearly = free-of-charge) CPE, the next v6 congress will have again several = presentations claiming =93The CPE is the = problem=94.
    Just = on these specific ones: there is the claim that CPE devices are not = =93ready=94 (whatever that may mean=94).  Today, IPv6 roll-out is, = unfortunately, still very (too) limited, but already =936rd sunsetting=94 = requirements are being added to the basic CPE IPV6 reqs, why ?  I = don=92t doubt this issue will present itself, but for sure not = =93tomorrow=94.

    T= hat's why:



    - = Mark

    From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.or= g] On Behalf = Of Chris = Donley
    Sent: dinsdag 24 april 2012 = 1:04
    To: Mark = Townsley; v6ops@ietf.org
    Subject: Re: [v6ops] 6rd sunsetting = requirements for 6204-bis
     
    1. We've been advised by the WG in the = past to only include a single normative statement per = requirement.
    2. This is covered in the existing = 6rd-4.
    1. I think this language (=85MUST allow = different or identical delegated prefixes=85) is confusing for people = not intimately familiar with your other CE transitioning = draft. 
    2. If I read this correctly, you want = to require two operational states =96 one where 6rd and native IPv6 use = the same prefix and a second where they use different prefixes. That = requirement is captured in 6rd-5.
    3. As I mentioned above, we = have been advised to keep requirements to a single normative statement, = so the part about the routing cost is in = 6rd-6.

    = = --Apple-Mail=_19A5540B-9D6F-4E32-A628-3DDBAD936AFF-- From Carl.Wuyts@technicolor.com Mon Apr 23 23:48:02 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 226C121E8032 for ; Mon, 23 Apr 2012 23:48:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.448 X-Spam-Level: X-Spam-Status: No, score=-6.448 tagged_above=-999 required=5 tests=[AWL=0.150, 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 H84Fi9a-8OKV for ; Mon, 23 Apr 2012 23:47:56 -0700 (PDT) Received: from na3sys009aog124.obsmtp.com (na3sys009aog124.obsmtp.com [74.125.149.151]) by ietfa.amsl.com (Postfix) with ESMTP id 0766311E809B for ; Mon, 23 Apr 2012 23:47:53 -0700 (PDT) Received: from mopesedge02.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob124.postini.com ([74.125.148.12]) with SMTP ID DSNKT5ZMmcQRPUFi4/dlcKz/QCndFZlSwme5@postini.com; Mon, 23 Apr 2012 23:47:56 PDT Received: from MOPESMAILHC03.eu.thmulti.com (141.11.100.132) by mopesedge02.eu.thmulti.com (141.11.253.23) with Microsoft SMTP Server (TLS) id 8.3.192.1; Tue, 24 Apr 2012 08:45:21 +0200 Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.134]) by MOPESMAILHC03.eu.thmulti.com ([141.11.100.132]) with mapi; Tue, 24 Apr 2012 08:45:28 +0200 From: Wuyts Carl To: Mark Townsley Date: Tue, 24 Apr 2012 08:45:26 +0200 Thread-Topic: [v6ops] 6rd sunsetting requirements for 6204-bis Thread-Index: Ac0h4/qO3KfaOKfYSSOj05KVdp13FgAAHEEA Message-ID: <867F4B6A1672E541A94676D556793ACD108F21A588@MOPESMBX01.eu.thmulti.com> References: <5DD4D480-328E-4CE4-B9C0-DE65B76597D4@townsley.net> <867F4B6A1672E541A94676D556793ACD108F21A569@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: multipart/alternative; boundary="_000_867F4B6A1672E541A94676D556793ACD108F21A588MOPESMBX01eut_" MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 06:48:02 -0000 --_000_867F4B6A1672E541A94676D556793ACD108F21A588MOPESMBX01eut_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Inline Regs Carl From: Mark Townsley [mailto:mark@townsley.net] Sent: dinsdag 24 april 2012 8:32 To: Wuyts Carl Cc: Chris Donley; v6ops@ietf.org Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis On Apr 24, 2012, at 7:59 AM, Wuyts Carl wrote: +1 on Hemants comment. You mean this comment? Hemant: "Sorry, still does not cut it for me. Fix the bug in the CPE router. We c= annot add every bug found in the CPE router for a requirement to the docume= nt. This is extremely basic router functionality where a router should sup= port concurrent tunneled and native IP interfaces." I really don't think that lack of support of IPv6 multihoming in a CPE rout= er is a simple bug that should obviously be fixed by every CPE vendor. I wi= sh that were true, but its not. [Carl] Yes. A CPE is a router, hence should be capable of making routing d= ecisions, taking into account multiple paths, metrics, .... . Load balanci= ng for instance might not be supported, so in case of multiple equal cost p= aths, it will take one of the available routes, but this is a known "issue"= at that moment. Lots of things can be set via TR-069 these days, so ISP c= an influence e.g. metrics when having native/tunneled combination and wanti= ng to enforce a specific route. However. Again new requirements are added to the RFC6204, so again more pr= essure is put upon the CPE vendors to be "IPv6-ready", to be "IPv6-complian= t". I don't get it. At the v6 world congress in Paris last February (panel 'ca= n we get an IPV6 CPE please') I think it was clear from all present CPE ven= dors in the panel that it's time to STOP adding requirements over and over = again to the RFC6204, so to finally have a basic set of requirements. But a= gain, reqs are added, so again it will not be possible to have compliancy w= ithin a decent time frame. It seems the real scope-creep you are talking about is the addition of 6rd = and DS-Lite to begin with. [Carl] Not at all. Our CPE supports both 6rd, static as well as using the = DHCP option 212. But when looking today at our customers, there for sure n= ot hitting a 6rd move to native . All I am trying to do is make sure that *if* 6rd is in the document, it is = done correctly so we don't paint ourselves into a corner. [Carl] Saw the picture, see what you mean, but again, should be tackled, ho= wever not today. Allow some time. I was also trying to do the same with DS-Lite, but have decided to give up.= DS-Lite has become an enormous distraction to the deployment of IPv6 servi= ce to internet users, so I'm going to stop investing energy into trying to = fix it here. Maybe v4-exit can do better in 6204-ter (sigh). [Carl] Same applies here as for 6rd. To start off, we do support it, again= static and dynamic through dhcp option 64, so no issue on that part. But = proper deployment most likely will require some extra's on the CPE, PCP, UP= NP-IGD2, something else.... Similar applies here: people starting today to= look at it (in Residential CPE world), but for sure not (yet) targeting th= e move to native-only, too soon (unfortunately). As I have said before, I am equally happy with the entire "Transition" sect= ion to be removed from 6204-bis. But, if we step off the cliff, we're going= to get it right, at least for 6rd. Otherwise, it does more harm than good. [Carl] Don't fully agree :). I see 6rd being used in various ways at our c= ustomers today. I must say it's working rather smooth, using the features = they have available today, so I'd encourage to keep both 6rd and DSLite in = the doc as is, but not start adding more requirements which are to be appli= ed in later phases. I've been present on the last 2 v6 world congresses in Paris and the genera= l statements there were always "the CPE is the problem". Well, guess what,= it still is, and it still will be if you don't stop adding requirements. Please draw a line NOW, and take changes and added requirements into a late= r version so the CPE vendor has the time to cope with all of this!!! I rep= eat my statement from the panel: if we don't stop adding requirements onto = the (nearly free-of-charge) CPE, the next v6 congress will have again sever= al presentations claiming "The CPE is the problem". Just on these specific ones: there is the claim that CPE devices are not "r= eady" (whatever that may mean"). Today, IPv6 roll-out is, unfortunately, s= till very (too) limited, but already "6rd sunsetting" requirements are bein= g added to the basic CPE IPV6 reqs, why ? I don't doubt this issue will pr= esent itself, but for sure not "tomorrow". That's why: [http://www.randexpainting.com/corner-web1.jpg] [Carl] I usually start from the other end @ home :) - Mark Regs Carl From: v6ops-bounces@ietf.org [mailto:v6ops-b= ounces@ietf.org] On Behalf Of Chris Donley Sent: dinsdag 24 april 2012 1:04 To: Mark Townsley; v6ops@ietf.org Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis Mark, Please see in-line. Chris From: Mark Townsley > Date: Mon, 23 Apr 2012 11:27:36 -0600 To: "v6ops@ietf.org" > Subject: [v6ops] 6rd sunsetting requirements for 6204-bis 6RD-4: A CE router MUST allow 6rd virtual and IPv6 native WAN interfaces to= be active simultaneously in order to support coexistence of the two technologies during an incremental migration period from 6rd to native IPv6. 1. I think this is covered in 6rd-5 and 6rd-7. 2. I don't think this specific requirement was agreed to in Paris. It's = not on your slide 4 or Slide 15, bullet 1, which were the 'hum's I captured= in my notes. 3. +1 to Hemant's comment - I don't think this is needed as a MUST. 6RD-5: The CE router MUST associate delegated prefixes with the WAN interface(s) they were learned from (e.g., DHCPv6-PD, 6rd, etc). Each packet sent out a WAN interface MUST have a source address that corresponds to a delegated prefix associated with the given WAN interface, consistent with what is described in section 4.3 of BCP 84 (RFC 3704). 1. We've been advised by the WG in the past to only include a single norm= ative statement per requirement. 2. This is covered in the existing 6rd-4. 6RD-6: The IPv6 CE router MUST allow different or identical delegated prefi= xes on 6rd and native interfaces. A 6rd virtual interface MUST be assigned a higher routing cost than a native IPv6 interface. This is done so that nati= ve traffic will be preferred over 6rd in the event normal IP longest matching and BCP 84 rules would have otherwise allowed a packet to be equally sent via 6rd or native IPv6. 1. I think this language (...MUST allow different or identical delegated = prefixes...) is confusing for people not intimately familiar with your othe= r CE transitioning draft. 2. If I read this correctly, you want to require two operational states -= one where 6rd and native IPv6 use the same prefix and a second where they = use different prefixes. That requirement is captured in 6rd-5. 3. As I mentioned above, we have been advised to keep requirements to a s= ingle normative statement, so the part about the routing cost is in 6rd-6. 4. I've heard from some CPE vendors that specifying routing "cost" may be= too implementation specific - I think it's more neutral to speak of prefer= ence - e.g. prefer native to 6rd. --_000_867F4B6A1672E541A94676D556793ACD108F21A588MOPESMBX01eut_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Inline

     

    =

    Regs

    = Carl

    From:= Mar= k Townsley [mailto:mark@townsley.net]
    Sent: dinsdag 24 april 201= 2 8:32
    To: Wuyts Carl
    Cc: Chris Donley; v6ops@ietf.org<= br>Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis

     

     

    On Ap= r 24, 2012, at 7:59 AM, Wuyts Carl wrote:



    +1 o= n Hemants comment.

     

    You mean this comme= nt?

     

    Hemant:

     

    "Sorry, st= ill does not cut it for me.  Fix the bug in the CPE router.  We c= annot add every bug found in the CPE router for a requirement to the d= ocument.  This is extremely basic router functionality where a ro= uter should support concurrent tunneled and native IP interfaces."

     

    =

    I really don't think that lack of support of IPv6 mult= ihoming in a CPE router is a simple bug that should obviously be fixed by e= very CPE vendor. I wish that were true, but its not.

     

    [Carl] Yes.  A CPE is a router, hen= ce should be capable of making routing decisions, taking into account multi= ple paths, metrics, …. .  Load balancing for instance might not = be supported, so in case of multiple equal cost paths, it will take one of = the available routes, but this is a known “issue” at that momen= t.  Lots of things can be set via TR-069 these days, so ISP can influe= nce e.g. metrics when having native/tunneled combination and wanting to enf= orce a specific route.

     

     

    However.  Again new requirements are ad= ded to the RFC6204, so again more pressure is put upon the CPE vendors to b= e “IPv6-ready”, to be “IPv6-compliant”.=

    I don’t get it. = ; At the v6 world congress in Paris last February (panel ‘can we get = an IPV6 CPE please’) I think it was clear from all present CPE vendor= s in the panel that it’s time to STOP adding requirements over and ov= er again to the RFC6204, so to finally have a basic set of requirements. Bu= t again, reqs are added, so again it will not be possible to have complianc= y within a decent time frame. 

     

    It seems the real scope-creep you are talking about is the add= ition of 6rd and DS-Lite to begin with. 

    [Carl] Not at all.  Our CPE supports both 6rd, static as = well as using the DHCP option 212.  But when looking today at our cust= omers, there for sure not hitting a 6rd move to native .<= /p>

     

    All I am trying to do is make sure that *if* 6rd= is in the document, it is done correctly so we don't paint ourselves into = a corner. 

    [Carl] Saw the pi= cture, see what you mean, but again, should be tackled, however not today.&= nbsp; Allow some time.

     

    I was also trying to = do the same with DS-Lite, but have decided to give up. DS-Lite has become a= n enormous distraction to the deployment of IPv6 service to internet users,= so I'm going to stop investing energy into trying to fix it here. Maybe v4= -exit can do better in 6204-ter (sigh). 

    [Carl] Same applies here as for 6rd.  To start off, we do= support it, again static and dynamic through dhcp option 64, so no issue o= n that part.  But proper deployment most likely will require some extr= a’s on the CPE, PCP, UPNP-IGD2, something else….  Similar = applies here: people starting today to look at it (in Residential CPE world= ), but for sure not (yet) targeting the move to native-only, too soon (unfo= rtunately).

     = ;

    As I have said before, I am equa= lly happy with the entire "Transition" section to be removed from= 6204-bis. But, if we step off the cliff, we're going to get it right, at l= east for 6rd. Otherwise, it does more harm than good.

    [Carl] Don’t fully agree J. = I see 6rd being used in various ways at our customers today.  I must = say it’s working rather smooth, using the features they have availabl= e today, so I’d encourage to keep both 6rd and DSLite in the doc as i= s, but not start adding more requirements which are to be applied in later = phases.

     



    I’ve been present on the last 2 v6 world congress= es in Paris and the general statements there were always “the CPE is = the problem”.  Well, guess what, it still is, and it still will = be if you don’t stop adding requirements. 

    =

    Please draw a line NOW, and take changes = and added requirements into a later version so the CPE vendor has the time = to cope with all of this!!!  I repeat my statement from the panel: if = we don’t stop adding requirements onto the (nearly free-of-charge) CP= E, the next v6 congress will have again several presentations claiming R= 20;The CPE is the problem”.

     

    Just on these specific ones: there is the claim that CPE device= s are not “ready” (whatever that may mean”).  Today,= IPv6 roll-out is, unfortunately, still very (too) limited, but already = 220;6rd sunsetting” requirements are being added to the basic CPE IPV= 6 reqs, why ?  I don’t doubt this issue will present itself, but= for sure not “tomorrow”.

     

    That's why:

    &nbs= p;

    =

     

    [Carl] I usually start from the oth= er end @ home J<= /span>

     

    - Ma= rk



     

    Regs

    Carl

     

    From: v6ops-bounces@= ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Chris Donley
    Sent: dinsdag 24 april 2012 1:04
    To: Mark Townsley; v6ops@= ietf.org
    Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis=

     

    =

    Mark,

     

    <= /div>

    Please see in-line.

     

    Chris

     <= /p>

    From: Mark Townsley <= mark@townsley.net>
    Date:&n= bsp;Mon, 23 Apr 2012 11:27:36 -0600
    To: "v= 6ops@ietf.org" <v6ops@ietf.or= g>
    Subject: [v6ops] 6rd sunsetting requirements for 6204-bis

     

    6RD-4: A CE router MUST allow= 6rd virtual and IPv6 native WAN interfaces to be

    active simultaneously in order = to support coexistence of the two

    technologies during an incremental migration pe= riod from 6rd to native

    IPv6. 

    1. I think this is covered in 6rd-5 and 6rd-7.  
    2. I don't think this specific requirement was agreed to in Paris.  = ;It's not on your slide 4 or Slide 15, bullet 1, which were the 'hum's I ca= ptured in my notes.
    3. +1 to Hemant's comment – I don't think th= is is needed as a MUST.

     

    6RD-5:= The CE router MUST associate delegated prefixes with the WAN

    interface(s) they w= ere learned from (e.g., DHCPv6-PD, 6rd, etc). Each

    packet sent out a WAN interfac= e MUST have a source address that

    corresponds to a delegated prefix associated wi= th the given WAN

    interface, consistent with what is described in section 4.3 of B= CP

    84 = (RFC 3704).

    1. We've been advised by the WG in the past to only include a single norma= tive statement per requirement.
    2. This is covered in the existing 6rd= -4.

     

    6RD-6: The IPv6 CE router M= UST allow different or identical delegated prefixes

    on 6rd and native interfaces.= A 6rd virtual interface MUST be assigned a 

    higher routing cost than a= native IPv6 interface. This is done so that native =

    traffic will be pr= eferred over 6rd in the event normal IP longest matching 

    and BC= P 84 rules would have otherwise allowed a packet to be equally sent 

    via 6r= d or native IPv6.

    1. I think this language (…MUST allow different or identical d= elegated prefixes…) is confusing for people not intimately familiar w= ith your other CE transitioning draft. 
    2. If I read this correct= ly, you want to require two operational states – one where 6rd and na= tive IPv6 use the same prefix and a second where they use different prefixe= s. That requirement is captured in 6rd-5.
    3. As I mentioned above, w= e have been advised to keep requirements to a single normative statement, s= o the part about the routing cost is in 6rd-6.
    4. I've heard from so= me CPE vendors that specifying routing "cost" may be too implemen= tation specific – I think it's more neutral to speak of preference &#= 8211; e.g. prefer native to 6rd.

     

    = --_000_867F4B6A1672E541A94676D556793ACD108F21A588MOPESMBX01eut_-- From brian.e.carpenter@gmail.com Mon Apr 23 23:52:10 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A05821F852C for ; Mon, 23 Apr 2012 23:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.276 X-Spam-Level: X-Spam-Status: No, score=-101.276 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmcISDLIC0qy for ; Mon, 23 Apr 2012 23:52:09 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 61F6A21F84F8 for ; Mon, 23 Apr 2012 23:52:09 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so213961wgb.13 for ; Mon, 23 Apr 2012 23:52:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=9AwFZKNOrKBHVV+7+PkGCwKSnqkKrt2gWCTrWSpFhIw=; b=nUj7m527cOpUncSasG6IGdEh4hJ7CPKSBGYUF8lt49vMDhiY5k/rfxkbanbKntpCHk ImFIi/NuIYtLMDStW9sBJyi932TURg1CChEnUYgQIowWwbaNqLHAfGzvRnbdtvUXQbq2 vm3Rlyosz/Gz+M5FMZBr9rVCCfY/wU7SNN1r9cfsyYToyHlpcWfV1ISSqNkKywV/ABfh ooaMtthVAhdncIXEEr1kw+8ZrxVMh2FD8KKX958FSqnOD2jrOdqNuDakgBpaD1H29Obi 77jdrP7aEtO2Q90llY8HNiW3Jx6NU736j0ddLityJHUdovR6Eyq2oadBN0+pAU6R4kpA Ll0A== Received: by 10.180.97.41 with SMTP id dx9mr9641273wib.9.1335250328572; Mon, 23 Apr 2012 23:52:08 -0700 (PDT) Received: from [192.168.1.64] (host-2-102-216-233.as13285.net. [2.102.216.233]) by mx.google.com with ESMTPS id gd4sm43821188wib.6.2012.04.23.23.52.06 (version=SSLv3 cipher=OTHER); Mon, 23 Apr 2012 23:52:07 -0700 (PDT) Message-ID: <4F964D94.1010405@gmail.com> Date: Tue, 24 Apr 2012 07:52:04 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Michael Newbery References: <20120418143817.19669.70000.idtracker@ietfa.amsl.com> <829911B8-D986-4381-92FE-C85F2C260EB5@gmail.com> In-Reply-To: <829911B8-D986-4381-92FE-C85F2C260EB5@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D ACTION:draft-ietf-v6ops-icp-guidance-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 06:52:10 -0000 Thanks Michael. But what do you mean by "the potential advantage of IS-IS"? Regards Brian On 2012-04-24 07:00, Michael Newbery wrote: >> 5.2. Routing >> >> In a dual stack network, IPv4 and IPv6 routing protocols operate >> quite independently and in parallel. The common routing protocols >> all exist in IPv6 versions, such as OSPFv3 [RFC5340], IS-IS >> [RFC5308], and even RIPng [RFC2080] [RFC2081]. For trained staff, >> >> > > Is it worthwhile to mention the potential advantage of IS-IS here? Offset of course with the cost of converting the IPv4 routing to use IS-IS as well if that is not already what you do. This is simply to point out the situation, rather than to recommend. > >> 6. Load Balancers >> >> It is to be expected that IPv6 traffic will initially be low, i.e. a >> small percentage of IPv4 traffic. For this reason, updating load >> balancers to fully support IPv6 can perhaps be delayed; however, such >> > However, anyone deploying a load balancer is also probably relying on it providing fail-over protection and so needs to be aware that by deferring IPv6 support they lose that as well, not just the load-balancing. > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From mark@townsley.net Tue Apr 24 00:34:34 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D1FA21F8601 for ; Tue, 24 Apr 2012 00:34:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.198 X-Spam-Level: X-Spam-Status: No, score=-3.198 tagged_above=-999 required=5 tests=[AWL=-0.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 xZMZwqgpsO+g for ; Tue, 24 Apr 2012 00:34:32 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id E96A321F85F1 for ; Tue, 24 Apr 2012 00:34:31 -0700 (PDT) Received: by werb10 with SMTP id b10so264603wer.31 for ; Tue, 24 Apr 2012 00:34:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=lx8NuL4TZ8FnkV39izWyKZk/o9R7v0CZVTFGiZuJmK4=; b=Ev/vEFoILV6DVO9m5yUbBT/9+9hOAD+Y/1miGxrh2SdQTvs7hMoWd9e/3dWybkh1QY fSzoUiR/PNYaisW42vpXE3GXQQBfHGoRLEHTMg3FGy1/3Dt52CJEo9Vlen1TaUTyNlNk 1Lbtd3cVNO3IEcIZteAhhzULwlkdPy7sKkVrxmhgDKiB7i88Iac7q5iH+B/BCpTLlVFT ypvXt5hhijq6qMx1IPPpaBIC1nRdsZ6zLyfht8+ayw4CbVV1cke7gs8lavM8yTpaMhvX nQR+v0llqD6cy+C/TwbAcFIzGJV6WEZTTXVGrD4dm/ilsdMvopE0ZT9D/rKTJwtcV0U3 nbTA== Received: by 10.180.90.102 with SMTP id bv6mr28469922wib.6.1335252871005; Tue, 24 Apr 2012 00:34:31 -0700 (PDT) Received: from ams-townsley-8912.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id e6sm28252816wix.8.2012.04.24.00.34.25 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 24 Apr 2012 00:34:30 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_A87E1171-768E-45D4-8755-A2DD27FDF4CE" From: Mark Townsley In-Reply-To: <867F4B6A1672E541A94676D556793ACD108F21A588@MOPESMBX01.eu.thmulti.com> Date: Tue, 24 Apr 2012 09:34:22 +0200 Message-Id: <501809C1-C185-40A8-AEB8-CDA93D052A65@townsley.net> References: <5DD4D480-328E-4CE4-B9C0-DE65B76597D4@townsley.net> <867F4B6A1672E541A94676D556793ACD108F21A569@MOPESMBX01.eu.thmulti.com> <867F4B6A1672E541A94676D556793ACD108F21A588@MOPESMBX01.eu.thmulti.com> To: Wuyts Carl X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQkIh7m3LWRZfCZQsQe4+jukO27sg7WPAwKT7LVnhGFUd9tghjEtcR6kQe9TPPrZG/PH4J/g Cc: "v6ops@ietf.org" Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 07:34:34 -0000 --Apple-Mail=_A87E1171-768E-45D4-8755-A2DD27FDF4CE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Apr 24, 2012, at 8:45 AM, Wuyts Carl wrote: >=20 > [Carl] Yes. A CPE is a router, hence should be capable of making = routing decisions, taking into account multiple paths, metrics, =85. . = Load balancing for instance might not be supported, so in case of = multiple equal cost paths, it will take one of the available routes, but = this is a known =93issue=94 at that moment. Lots of things can be set = via TR-069 these days, so ISP can influence e.g. metrics when having = native/tunneled combination and wanting to enforce a specific route. We cannot assume all CPE have a TR-69 interface. > [Carl] Not at all. Our CPE supports both 6rd, static as well as using = the DHCP option 212. But when looking today at our customers, there for = sure not hitting a 6rd move to native . Not sure I understand that sentence. But, let's just say I am looking at the largest 6rd deployments in the = world, and working out how to migrate them to native. That's the basis = behind the three requirements, and the reason they are being introduced = in 6204-bis is that this is the first document that considers both = native IPv6 and 6rd at the same time.=20 I gather your primary customer set is a managed CPE with TR-69. WIth = this model, you can of course leave all this up to configuration, and = customize everything for each and every ISP in the world. Retail CPE are = different, and the burden on the RFC greater, in order to achieve the = level of consistency across the market that is needed for the model to = work at all. > =20 > All I am trying to do is make sure that *if* 6rd is in the document, = it is done correctly so we don't paint ourselves into a corner.=20 > [Carl] Saw the picture, see what you mean, but again, should be = tackled, however not today. Allow some time. 6rd has been deployed since 2007, how much longer do we need to get this = right? > =20 > I was also trying to do the same with DS-Lite, but have decided to = give up. DS-Lite has become an enormous distraction to the deployment of = IPv6 service to internet users, so I'm going to stop investing energy = into trying to fix it here. Maybe v4-exit can do better in 6204-ter = (sigh).=20 > [Carl] Same applies here as for 6rd.=20 No. 6rd and DS-Lite are not the same, and do not solve the same = problems. They are night and day different, and every time we lump them = together it causes confusion and trouble. Please stop.=20 > To start off, we do support it, again static and dynamic through dhcp = option 64, so no issue on that part. But proper deployment most likely = will require some extra=92s on the CPE, PCP, UPNP-IGD2, something else=85.= Similar applies here: people starting today to look at it (in = Residential CPE world), but for sure not (yet) targeting the move to = native-only, too soon (unfortunately). The real scope creep is the inclusion of IPv4 delivery in an IPv6 CPE = document to start with. If you want to draw a line, draw it before the = inclusion of DS-Lite. Here in v6ops, we need to get IPv6 Internet = service off the ground, and that's already taking plenty of energy as it = is.=20 > =20 > As I have said before, I am equally happy with the entire "Transition" = section to be removed from 6204-bis. But, if we step off the cliff, = we're going to get it right, at least for 6rd. Otherwise, it does more = harm than good. > [Carl] Don=92t fully agree J. I see 6rd being used in various ways at = our customers today. I must say it=92s working rather smooth, using the = features they have available today, so I=92d encourage to keep both 6rd = and DSLite in the doc as is, but not start adding more requirements = which are to be applied in later phases. Yes, 6rd is working quite well, I cannot argue with you there.=20 But, I also want my customers to be able to turn off 6rd, and for that = to happen smoothly. Including the requirements for that in 6204-bis = won't hurt that. As you have said, its all just what a "real router" = would do anyway. - Mark > I=92ve been present on the last 2 v6 world congresses in Paris and the = general statements there were always =93the CPE is the problem=94. = Well, guess what, it still is, and it still will be if you don=92t stop = adding requirements.=20 > Please draw a line NOW, and take changes and added requirements into a = later version so the CPE vendor has the time to cope with all of this!!! = I repeat my statement from the panel: if we don=92t stop adding = requirements onto the (nearly free-of-charge) CPE, the next v6 congress = will have again several presentations claiming =93The CPE is the = problem=94. > =20 > Just on these specific ones: there is the claim that CPE devices are = not =93ready=94 (whatever that may mean=94). Today, IPv6 roll-out is, = unfortunately, still very (too) limited, but already =936rd sunsetting=94 = requirements are being added to the basic CPE IPV6 reqs, why ? I don=92t = doubt this issue will present itself, but for sure not =93tomorrow=94. > =20 > That's why: > =20 >=20 > =20 > [Carl] I usually start from the other end @ home J > =20 > - Mark >=20 >=20 > =20 > Regs > Carl > =20 > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Chris Donley > Sent: dinsdag 24 april 2012 1:04 > To: Mark Townsley; v6ops@ietf.org > Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis > =20 > Mark, > =20 > Please see in-line. > =20 > Chris > =20 > From: Mark Townsley > Date: Mon, 23 Apr 2012 11:27:36 -0600 > To: "v6ops@ietf.org" > Subject: [v6ops] 6rd sunsetting requirements for 6204-bis > =20 > 6RD-4: A CE router MUST allow 6rd virtual and IPv6 native WAN = interfaces to be > active simultaneously in order to support coexistence of the two > technologies during an incremental migration period from 6rd to native > IPv6.=20 > I think this is covered in 6rd-5 and 6rd-7. =20 > I don't think this specific requirement was agreed to in Paris. It's = not on your slide 4 or Slide 15, bullet 1, which were the 'hum's I = captured in my notes. > +1 to Hemant's comment =96 I don't think this is needed as a MUST. > =20 > 6RD-5: The CE router MUST associate delegated prefixes with the WAN > interface(s) they were learned from (e.g., DHCPv6-PD, 6rd, etc). Each > packet sent out a WAN interface MUST have a source address that > corresponds to a delegated prefix associated with the given WAN > interface, consistent with what is described in section 4.3 of BCP > 84 (RFC 3704). > We've been advised by the WG in the past to only include a single = normative statement per requirement. > This is covered in the existing 6rd-4. > =20 > 6RD-6: The IPv6 CE router MUST allow different or identical delegated = prefixes > on 6rd and native interfaces. A 6rd virtual interface MUST be assigned = a=20 > higher routing cost than a native IPv6 interface. This is done so that = native=20 > traffic will be preferred over 6rd in the event normal IP longest = matching=20 > and BCP 84 rules would have otherwise allowed a packet to be equally = sent=20 > via 6rd or native IPv6. > I think this language (=85MUST allow different or identical delegated = prefixes=85) is confusing for people not intimately familiar with your = other CE transitioning draft.=20 > If I read this correctly, you want to require two operational states =96= one where 6rd and native IPv6 use the same prefix and a second where = they use different prefixes. That requirement is captured in 6rd-5. > As I mentioned above, we have been advised to keep requirements to a = single normative statement, so the part about the routing cost is in = 6rd-6. > I've heard from some CPE vendors that specifying routing "cost" may be = too implementation specific =96 I think it's more neutral to speak of = preference =96 e.g. prefer native to 6rd. > =20 --Apple-Mail=_A87E1171-768E-45D4-8755-A2DD27FDF4CE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
    On Apr 24, 2012, at 8:45 AM, Wuyts = Carl wrote:


    [Carl] = Yes.  A CPE is a router, hence should be capable of making routing = decisions, taking into account multiple paths, metrics, =85. .  = Load balancing for instance might not be supported, so in case of = multiple equal cost paths, it will take one of the available routes, but = this is a known =93issue=94 at that moment.  Lots of things can be = set via TR-069 these days, so ISP can influence e.g. metrics when having = native/tunneled combination and wanting to enforce a specific = route.

    We cannot assume all CPE have a TR-69 = interface.

    All I am = trying to do is make sure that *if* 6rd is in the document, it is done = correctly so we don't paint ourselves into a = corner. 
    I was also trying to do = the same with DS-Lite, but have decided to give up. DS-Lite has become = an enormous distraction to the deployment of IPv6 service to internet = users, so I'm going to stop investing energy into trying to fix it here. = Maybe v4-exit can do better in 6204-ter = (sigh). 
    To = start off, we do support it, again static and dynamic through dhcp = option 64, so no issue on that part.  But proper deployment most = likely will require some extra=92s on the CPE, PCP, UPNP-IGD2, something = else=85.  Similar applies here: people starting today to look at it = (in Residential CPE world), but for sure not (yet) targeting the move to = native-only, too soon = (unfortunately).
    <= div>
    The real scope creep is the inclusion of IPv4 = delivery in an IPv6 CPE document to start with. If you want to draw a = line, draw it before the inclusion of DS-Lite. Here in v6ops, we need to = get IPv6 Internet service off the ground, and that's already taking = plenty of energy as it is. 

    As I have said before, I = am equally happy with the entire "Transition" section to be removed from = 6204-bis. But, if we step off the cliff, we're going to get it right, at = least for 6rd. Otherwise, it does more harm than = good.
    [Carl] Don=92t fully = agree J.  I see 6rd being used in = various ways at our customers today.  I must say it=92s working = rather smooth, using the features they have available today, so I=92d = encourage to keep both 6rd and DSLite in the doc as is, but not start = adding more requirements which are to be applied in later = phases.

    <= /div>
    Yes, 6rd is working quite well, I cannot argue with you = there. 

    But, I also want my customers to = be able to turn off 6rd, and for that to happen smoothly. Including the = requirements for that in 6204-bis won't hurt that. As you have said, its = all just what a "real router" would do = anyway.

    - Mark

    I=92ve = been present on the last 2 v6 world congresses in Paris and the general = statements there were always =93the CPE is the problem=94.  Well, = guess what, it still is, and it still will be if you don=92t stop adding = requirements. 
    Please draw a line NOW, and take = changes and added requirements into a later version so the CPE vendor = has the time to cope with all of this!!!  I repeat my statement = from the panel: if we don=92t stop adding requirements onto the (nearly = free-of-charge) CPE, the next v6 congress will have again several = presentations claiming =93The CPE is the = problem=94.
     
    Just on these specific ones: = there is the claim that CPE devices are not =93ready=94 (whatever that = may mean=94).  Today, IPv6 roll-out is, unfortunately, still very = (too) limited, but already =936rd sunsetting=94 requirements are being = added to the basic CPE IPV6 reqs, why ?  I don=92t doubt this issue = will present itself, but for sure not = =93tomorrow=94.
     
    That's why:
     
     
    [Carl] I = usually start from the other end @ home - = Mark
    Regs
     [mailto:v6ops-bounces@ietf.org] On Behalf Of Chris = Donley
    Sent: dinsdag 24 april 2012 = 1:04
    To: Mark = Townsley; v6ops@ietf.org
    Subject: Re: [v6ops] 6rd sunsetting = requirements for = 6204-bis
     
    Please see = in-line.
    Chris
    <= div>
    1. We've been advised by the WG in the = past to only include a single normative statement per = requirement.
    2. This is covered in the existing = 6rd-4.
    1. I think this language (=85MUST allow = different or identical delegated prefixes=85) is confusing for people = not intimately familiar with your other CE transitioning = draft. 
    2. If I read this correctly, you want = to require two operational states =96 one where 6rd and native IPv6 use = the same prefix and a second where they use different prefixes. That = requirement is captured in 6rd-5.
    3. As I mentioned above, we = have been advised to keep requirements to a single normative statement, = so the part about the routing cost is in = 6rd-6.
    , "Hemant Singh (shemant)" Date: Tue, 24 Apr 2012 09:54:29 +0200 Thread-Topic: [v6ops] 6rd sunsetting requirements for 6204-bis Thread-Index: Ac0hpQjBW+0+ruNTS1qIHuPspQerVwAOQBjwAAREkIA= Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE51370AD04D@GRFMBX704BA020.griffon.local> References: <5DD4D480-328E-4CE4-B9C0-DE65B76597D4@townsley.net> <867F4B6A1672E541A94676D556793ACD108F21A569@MOPESMBX01.eu.thmulti.com> In-Reply-To: <867F4B6A1672E541A94676D556793ACD108F21A569@MOPESMBX01.eu.thmulti.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ullio Mario Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 07:54:36 -0000 Hello, I agree with Carl: main issue delaying our IPv6 deployment is the IPv6 sup= port on the CPE that's why we have been working hard with the editors to tr= y to finalize 6204-bis ASAP. We need an RFC for this document: I keep saying that, but people keep tryin= g to add new things and delay this work. This document was fine and stable before the addition of 6rd sunsetting req= uirements: this discussion just shows that 6rd sunsetting requirements are = NOT mature enough to be added to 6204-bis. As there is already a dedicated draft for 6rd sunsetting (draft-townsley-v6= ops-6rd-sunsetting-00) I would suggest to keep the requirements there and l= et 6204-bis to be published as RFC. Best regards, Roberta ________________________________________ From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of W= uyts Carl Sent: marted=EC 24 aprile 2012 8.00 To: Chris Donley; Mark Townsley; v6ops@ietf.org Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis +1 on Hemants comment. However. Again new requirements are added to the RFC6204, so again more pr= essure is put upon the CPE vendors to be "IPv6-ready", to be "IPv6-complian= t". I don't get it. At the v6 world congress in Paris last February (panel 'ca= n we get an IPV6 CPE please') I think it was clear from all present CPE ven= dors in the panel that it's time to STOP adding requirements over and over = again to the RFC6204, so to finally have a basic set of requirements. But a= gain, reqs are added, so again it will not be possible to have compliancy w= ithin a decent time frame. I've been present on the last 2 v6 world congresses in Paris and the genera= l statements there were always "the CPE is the problem". Well, guess what,= it still is, and it still will be if you don't stop adding requirements. = Please draw a line NOW, and take changes and added requirements into a late= r version so the CPE vendor has the time to cope with all of this!!! I rep= eat my statement from the panel: if we don't stop adding requirements onto = the (nearly free-of-charge) CPE, the next v6 congress will have again sever= al presentations claiming "The CPE is the problem". Just on these specific ones: there is the claim that CPE devices are not "r= eady" (whatever that may mean"). Today, IPv6 roll-out is, unfortunately, s= till very (too) limited, but already "6rd sunsetting" requirements are bein= g added to the basic CPE IPV6 reqs, why ? I don't doubt this issue will pr= esent itself, but for sure not "tomorrow". Regs Carl From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of C= hris Donley Sent: dinsdag 24 april 2012 1:04 To: Mark Townsley; v6ops@ietf.org Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis Mark, Please see in-line. Chris From: Mark Townsley Date: Mon, 23 Apr 2012 11:27:36 -0600 To: "v6ops@ietf.org" Subject: [v6ops] 6rd sunsetting requirements for 6204-bis 6RD-4: A CE router MUST allow 6rd virtual and IPv6 native WAN interfaces to= be active simultaneously in order to support coexistence of the two technologies during an incremental migration period from 6rd to native IPv6. 1. I think this is covered in 6rd-5 and 6rd-7. 2. I don't think this specific requirement was agreed to in Paris. It's no= t on your slide 4 or Slide 15, bullet 1, which were the 'hum's I captured i= n my notes. 3. +1 to Hemant's comment - I don't think this is needed as a MUST. 6RD-5: The CE router MUST associate delegated prefixes with the WAN interface(s) they were learned from (e.g., DHCPv6-PD, 6rd, etc). Each packet sent out a WAN interface MUST have a source address that corresponds to a delegated prefix associated with the given WAN interface, consistent with what is described in section 4.3 of BCP 84 (RFC 3704). 1. We've been advised by the WG in the past to only include a single normat= ive statement per requirement. 2. This is covered in the existing 6rd-4. 6RD-6: The IPv6 CE router MUST allow different or identical delegated prefi= xes on 6rd and native interfaces. A 6rd virtual interface MUST be assigned a higher routing cost than a native IPv6 interface. This is done so that nati= ve traffic will be preferred over 6rd in the event normal IP longest matching and BCP 84 rules would have otherwise allowed a packet to be equally sent via 6rd or native IPv6. 1. I think this language (.MUST allow different or identical delegated pref= ixes.) is confusing for people not intimately familiar with your other CE t= ransitioning draft. 2. If I read this correctly, you want to require two operational states - o= ne where 6rd and native IPv6 use the same prefix and a second where they us= e different prefixes. That requirement is captured in 6rd-5. 3. As I mentioned above, we have been advised to keep requirements to a sin= gle normative statement, so the part about the routing cost is in 6rd-6. 4. I've heard from some CPE vendors that specifying routing "cost" may be t= oo implementation specific - I think it's more neutral to speak of preferen= ce - e.g. prefer native to 6rd. 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 Tue Apr 24 01:51:07 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F375D21F85AC for ; Tue, 24 Apr 2012 01:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.768 X-Spam-Level: X-Spam-Status: No, score=-102.768 tagged_above=-999 required=5 tests=[AWL=-0.092, 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 Ha7JSDSxMtSk for ; Tue, 24 Apr 2012 01:51:05 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9A96321F85A8 for ; Tue, 24 Apr 2012 01:51:05 -0700 (PDT) Received: by obbwd20 with SMTP id wd20so790881obb.31 for ; Tue, 24 Apr 2012 01:51:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=0rDVxPmv2S5h+VJ28eo5xPm7T6GqyWtPaLUyPzTgdvw=; b=IwCQ2rON4KMc3s49fraYOX2TEr1sPCHpUjIlVymWAINMPKte9nvwjIGBmLaKC4+8Xo 4t0EWYWt/Rbk7C+0lQ/QuogzCV2O7A0d4uVKHr595FCjxk9DvRtSvuXxafob8tPnioXF U03arDqjYQfgOo9l0WV7bJZEz/xQtBLSe8c+yP00qq+gauvhVN30Wwtw8kIjYKl4KdE/ QQF6a4hRQ9D8B6jTu7+BEShWYdbWTavHC7UCS0W1ZxR+Vr/HTkA6Ufw052hupQsdVYQB liMSW5HrePWdTKIPtKRCHbEzH6uMn/TL5KWuF7pq00hJIwDtJcCrH29zGsQ5Vb0omVR1 XY4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=0rDVxPmv2S5h+VJ28eo5xPm7T6GqyWtPaLUyPzTgdvw=; b=Htd4dKvYbC3bpUjScQAVbi1vATqZrrwQLzLSqQnOXj5RAz2I9dmLui6UaRZ64rP0Y+ DqGL/liIbdJctDPtodvjyKdJIHSOwAsaEikocPkzOmHxCjKn985x0AY3yqp9i7H4OI1q aZ1X2midw96yzxeebKEGJzMXQXLgpXhw7j/STkoDheEPEim27oOpzpiYM706mm2sr9Dh w7VEvn+3C3UaOL6NCN2RaTzVUSjP68XhFeWbB7CtjZeqJb/R4T+YkfxIopwc4CuzyaYa U7b2oRKbjAyuN48b/MZTyJNEhnuKuZsdms9QplHa8O2bY1km0Yxgi4JuKtXl2A8dgDgf h6pw== Received: by 10.182.111.39 with SMTP id if7mr8007167obb.8.1335257465151; Tue, 24 Apr 2012 01:51:05 -0700 (PDT) Received: by 10.182.111.39 with SMTP id if7mr8007149obb.8.1335257464992; Tue, 24 Apr 2012 01:51:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.220.3 with HTTP; Tue, 24 Apr 2012 01:50:44 -0700 (PDT) In-Reply-To: <2950A57B-DA87-4641-8540-8972F5C437CF@laposte.net> References: <20120417065542.31115.95082.idtracker@ietfa.amsl.com> <20120417160010kawashimam@mail.jp.nec.com> <56E2AD61-1C91-4889-914A-353793FCBE43@laposte.net> <20120419121044.17531mk1mv19abr4@mail.drown.org> <0646611B-5594-40EA-A2C4-F99CBA734024@laposte.net> <20120419181813.4524701l3gkq5zks@mail.drown.org> <45ABAD31-C265-4D63-82E2-3DE6F59B80C0@laposte.net> <20120420104246.1432746csfcrdqo8@mail.drown.org> <20120420122715.1702279xh7eynpus@mail.drown.org> <20120420175036.70482p5axgf81lq8@mail.drown.org> <2950A57B-DA87-4641-8540-8972F5C437CF@laposte.net> From: Lorenzo Colitti Date: Tue, 24 Apr 2012 17:50:44 +0900 Message-ID: To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=14dae9399087e275ab04be68da93 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmmSjQkti3CLauBU9rws7O39avV/s7EdUAyecuSG+0ovXTbmRcLL8y/lKwXJe21P6HZEW2qTDKqUp5WrnK+lQFf2oslS2EC44IpaCM6xqzPG2T2JCdBY54CM+wrSMuLut5dLJ5V Cc: v6ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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, 24 Apr 2012 08:51:07 -0000 --14dae9399087e275ab04be68da93 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, Apr 21, 2012 at 17:50, R=E9mi Despr=E9s w= rote: > Now, avoiding ND proxy on two addresses REMAINS POSSIBLE. > - It is sufficient that a CLAT interface ID be reserved by IETF/IANA (an > ID that no host may legitimately use). > - This can be done, in compliance with RFC 5342, with a modified-EUI-64 I= D > based on IANA's OUI. > - Proposed ID value is 02-00-5E-10--00-00-00-00 (in the available range o= f > www.iana.org/assignments/ethernet-numbers for this). > What if the user manually specifies the interface ID on a tethered device? Will DAD just fail? --14dae9399087e275ab04be68da93 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    On Sat, Apr 21, 2012 = at 17:50, R=E9mi Despr=E9s <despres.remi@laposte.net>= wrote:
    Now, avoiding ND proxy on two addresses REMA= INS POSSIBLE.
    - It is sufficient that a CLAT interface ID be reserved by IETF/IANA (an ID= that no host may legitimately use).
    - This can be done, in compliance with RFC 5342, with a modified-EUI-64 ID = based on IANA's OUI.
    - Proposed ID value is 02-00-5E-10--00-00-00-00 (in the available range of = www.iana.org/assignments/ethernet-numbers for this).

    What if the user manually specifies the interface ID on= a tethered device? Will DAD just fail?
    --14dae9399087e275ab04be68da93-- From Carl.Wuyts@technicolor.com Tue Apr 24 02:29:17 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D16B421F86E1 for ; Tue, 24 Apr 2012 02:29:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.041 X-Spam-Level: X-Spam-Status: No, score=-6.041 tagged_above=-999 required=5 tests=[AWL=-0.358, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, 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 3rSPoggIjjk2 for ; Tue, 24 Apr 2012 02:29:11 -0700 (PDT) Received: from na3sys009aog111.obsmtp.com (na3sys009aog111.obsmtp.com [74.125.149.205]) by ietfa.amsl.com (Postfix) with ESMTP id 1487021F86FD for ; Tue, 24 Apr 2012 02:29:04 -0700 (PDT) Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob111.postini.com ([74.125.148.12]) with SMTP ID DSNKT5ZyX/Sujyz+BypmedHkWRJAcu5vplkK@postini.com; Tue, 24 Apr 2012 02:29:10 PDT Received: from MOPESMAILHC01.eu.thmulti.com (141.11.100.25) by mail3.technicolor.com (141.11.253.22) with Microsoft SMTP Server (TLS) id 8.3.192.1; Tue, 24 Apr 2012 11:23:39 +0200 Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.134]) by MOPESMAILHC01.eu.thmulti.com ([141.11.100.25]) with mapi; Tue, 24 Apr 2012 11:23:41 +0200 From: Wuyts Carl To: Mark Townsley Date: Tue, 24 Apr 2012 11:23:39 +0200 Thread-Topic: [v6ops] 6rd sunsetting requirements for 6204-bis Thread-Index: Ac0h7LcMlN9d850fQEWHbVF/KP9CxAADW6Iw Message-ID: <867F4B6A1672E541A94676D556793ACD108F21A6B7@MOPESMBX01.eu.thmulti.com> References: <5DD4D480-328E-4CE4-B9C0-DE65B76597D4@townsley.net> <867F4B6A1672E541A94676D556793ACD108F21A569@MOPESMBX01.eu.thmulti.com> <867F4B6A1672E541A94676D556793ACD108F21A588@MOPESMBX01.eu.thmulti.com> <501809C1-C185-40A8-AEB8-CDA93D052A65@townsley.net> In-Reply-To: <501809C1-C185-40A8-AEB8-CDA93D052A65@townsley.net> 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_867F4B6A1672E541A94676D556793ACD108F21A6B7MOPESMBX01eut_" MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 09:29:17 -0000 --_000_867F4B6A1672E541A94676D556793ACD108F21A6B7MOPESMBX01eut_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable @ Mark. 1. Indeed we are deploying managed CPEs, so have a bit more flexibil= ity in controlling the config vs retail. Indeed, not all CPEs are TR-069 c= apable, but most of our customers do deploy it (quite typical for managed C= PE). 2. 6rd and DSlite or indeed far from equal, I know. What I meant is = that the same principal applies, i.e. one is not rolling it out today, to d= ecide tomorrow to go fully native all of a sudden. Investments are being m= ade, either 6rd or DSLite, or even both, which will not be thrown away the = day after. So the 6rd sunsetting indeed is something to become useful in = later stages, but no urgency to include them as reqs today. 3. 6rd indeed exists for some time, you probably know a lot better th= an me :), but I've a pretty good view on what our customers are doing today= with IPv6 in general 9so also with 6rd), and can assure you they are not l= ooking at any 6rd sunsetting today. So, as Roberta also says in her latest reply. Please draw a line. You say= before DSLite, maybe, maybe not, I'd say, looking at millions of CPEs in t= he field, the 6rd sunsetting for sure are not needed today. Wrt DSLite. I= don't think we can avoid it (unfortunately), but also here applies that th= e CPE should be able to handle those tunnels, but not yet to also include f= ull PCP support or some other UPnP-kind of mechanism, it's too early for th= at (looking at them being mainly all draft stuff). Of course CPE vendors s= hould look into it today and judge upon its impact, but one cannot expect f= rom the CPE vendor (you know, the very low cost device) to support all of i= t in 1 go. I can even go 1 step further: RFC6106 support. For the record: we do suppo= rt it, however, I see lack of support in the LAN for it, hence not very usa= ble today. OK for CPE to have some basic support for it, but not "all the = way" for simple reason that lots of hosts are not ready + the fact that no = clear view on what should happen in case of both RA and DHCPv6 stateless, w= hat is "best", what if different content, .... This one however is only li= mited present in RFC6204, which is fine I guess. Best regards Carl From: Mark Townsley [mailto:mark@townsley.net] Sent: dinsdag 24 april 2012 9:34 To: Wuyts Carl Cc: Chris Donley; v6ops@ietf.org Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis On Apr 24, 2012, at 8:45 AM, Wuyts Carl wrote: [Carl] Yes. A CPE is a router, hence should be capable of making routing d= ecisions, taking into account multiple paths, metrics, .... . Load balanci= ng for instance might not be supported, so in case of multiple equal cost p= aths, it will take one of the available routes, but this is a known "issue"= at that moment. Lots of things can be set via TR-069 these days, so ISP c= an influence e.g. metrics when having native/tunneled combination and wanti= ng to enforce a specific route. We cannot assume all CPE have a TR-69 interface. [Carl] Not at all. Our CPE supports both 6rd, static as well as using the = DHCP option 212. But when looking today at our customers, there for sure n= ot hitting a 6rd move to native . Not sure I understand that sentence. But, let's just say I am looking at the largest 6rd deployments in the wor= ld, and working out how to migrate them to native. That's the basis behind = the three requirements, and the reason they are being introduced in 6204-bi= s is that this is the first document that considers both native IPv6 and 6r= d at the same time. I gather your primary customer set is a managed CPE with TR-69. WIth this m= odel, you can of course leave all this up to configuration, and customize e= verything for each and every ISP in the world. Retail CPE are different, an= d the burden on the RFC greater, in order to achieve the level of consisten= cy across the market that is needed for the model to work at all. All I am trying to do is make sure that *if* 6rd is in the document, it is = done correctly so we don't paint ourselves into a corner. [Carl] Saw the picture, see what you mean, but again, should be tackled, ho= wever not today. Allow some time. 6rd has been deployed since 2007, how much longer do we need to get this ri= ght? I was also trying to do the same with DS-Lite, but have decided to give up.= DS-Lite has become an enormous distraction to the deployment of IPv6 servi= ce to internet users, so I'm going to stop investing energy into trying to = fix it here. Maybe v4-exit can do better in 6204-ter (sigh). [Carl] Same applies here as for 6rd. No. 6rd and DS-Lite are not the same, and do not solve the same problems. T= hey are night and day different, and every time we lump them together it ca= uses confusion and trouble. Please stop. To start off, we do support it, again static and dynamic through dhcp optio= n 64, so no issue on that part. But proper deployment most likely will req= uire some extra's on the CPE, PCP, UPNP-IGD2, something else.... Similar a= pplies here: people starting today to look at it (in Residential CPE world)= , but for sure not (yet) targeting the move to native-only, too soon (unfor= tunately). The real scope creep is the inclusion of IPv4 delivery in an IPv6 CPE docum= ent to start with. If you want to draw a line, draw it before the inclusion= of DS-Lite. Here in v6ops, we need to get IPv6 Internet service off the gr= ound, and that's already taking plenty of energy as it is. As I have said before, I am equally happy with the entire "Transition" sect= ion to be removed from 6204-bis. But, if we step off the cliff, we're going= to get it right, at least for 6rd. Otherwise, it does more harm than good. [Carl] Don't fully agree :). I see 6rd being used in various ways at our c= ustomers today. I must say it's working rather smooth, using the features = they have available today, so I'd encourage to keep both 6rd and DSLite in = the doc as is, but not start adding more requirements which are to be appli= ed in later phases. Yes, 6rd is working quite well, I cannot argue with you there. But, I also want my customers to be able to turn off 6rd, and for that to h= appen smoothly. Including the requirements for that in 6204-bis won't hurt = that. As you have said, its all just what a "real router" would do anyway. - Mark I've been present on the last 2 v6 world congresses in Paris and the genera= l statements there were always "the CPE is the problem". Well, guess what,= it still is, and it still will be if you don't stop adding requirements. Please draw a line NOW, and take changes and added requirements into a late= r version so the CPE vendor has the time to cope with all of this!!! I rep= eat my statement from the panel: if we don't stop adding requirements onto = the (nearly free-of-charge) CPE, the next v6 congress will have again sever= al presentations claiming "The CPE is the problem". Just on these specific ones: there is the claim that CPE devices are not "r= eady" (whatever that may mean"). Today, IPv6 roll-out is, unfortunately, s= till very (too) limited, but already "6rd sunsetting" requirements are bein= g added to the basic CPE IPV6 reqs, why ? I don't doubt this issue will pr= esent itself, but for sure not "tomorrow". That's why: [http://www.randexpainting.com/corner-web1.jpg] [Carl] I usually start from the other end @ home :) - Mark Regs Carl From: v6ops-bounces@ietf.org [mailto:v6ops-b= ounces@ietf.org] On Behalf Of Chris Donley Sent: dinsdag 24 april 2012 1:04 To: Mark Townsley; v6ops@ietf.org Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis Mark, Please see in-line. Chris From: Mark Townsley > Date: Mon, 23 Apr 2012 11:27:36 -0600 To: "v6ops@ietf.org" > Subject: [v6ops] 6rd sunsetting requirements for 6204-bis 6RD-4: A CE router MUST allow 6rd virtual and IPv6 native WAN interfaces to= be active simultaneously in order to support coexistence of the two technologies during an incremental migration period from 6rd to native IPv6. 1. I think this is covered in 6rd-5 and 6rd-7. 2. I don't think this specific requirement was agreed to in Paris. It's = not on your slide 4 or Slide 15, bullet 1, which were the 'hum's I captured= in my notes. 3. +1 to Hemant's comment - I don't think this is needed as a MUST. 6RD-5: The CE router MUST associate delegated prefixes with the WAN interface(s) they were learned from (e.g., DHCPv6-PD, 6rd, etc). Each packet sent out a WAN interface MUST have a source address that corresponds to a delegated prefix associated with the given WAN interface, consistent with what is described in section 4.3 of BCP 84 (RFC 3704). 1. We've been advised by the WG in the past to only include a single norm= ative statement per requirement. 2. This is covered in the existing 6rd-4. 6RD-6: The IPv6 CE router MUST allow different or identical delegated prefi= xes on 6rd and native interfaces. A 6rd virtual interface MUST be assigned a higher routing cost than a native IPv6 interface. This is done so that nati= ve traffic will be preferred over 6rd in the event normal IP longest matching and BCP 84 rules would have otherwise allowed a packet to be equally sent via 6rd or native IPv6. 1. I think this language (...MUST allow different or identical delegated = prefixes...) is confusing for people not intimately familiar with your othe= r CE transitioning draft. 2. If I read this correctly, you want to require two operational states -= one where 6rd and native IPv6 use the same prefix and a second where they = use different prefixes. That requirement is captured in 6rd-5. 3. As I mentioned above, we have been advised to keep requirements to a s= ingle normative statement, so the part about the routing cost is in 6rd-6. 4. I've heard from some CPE vendors that specifying routing "cost" may be= too implementation specific - I think it's more neutral to speak of prefer= ence - e.g. prefer native to 6rd. --_000_867F4B6A1672E541A94676D556793ACD108F21A6B7MOPESMBX01eut_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    @ Mark. <= o:p>

     

    1.     &nbs= p;  Indeed we are deploying mana= ged CPEs, so have a bit more flexibility in controlling the config vs retai= l.  Indeed, not all CPEs are TR-069 capable, but most of our customers= do deploy it (quite typical for managed CPE).

    2.       6rd and DSlite or indeed far from equal, I know.  What = I meant is that the same principal applies, i.e. one is not rolling it out = today, to decide tomorrow to go fully native all of a sudden.  Investm= ents are being made, either 6rd or DSLite, or even both, which will not be = thrown away the day after.   So the 6rd sunsetting indeed is some= thing to become useful in later stages, but no urgency to include them as r= eqs today.

     &= nbsp;

    3. &= nbsp;     6rd ind= eed exists for some time, you probably know a lot better than me J<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'>, but I’ve a pretty good view on what our customers are doing t= oday with IPv6 in general 9so also with 6rd), and can assure you they are n= ot looking at any 6rd sunsetting today.

     

    So, = as Roberta also says in her latest reply.  Please draw a line.  Y= ou say before DSLite, maybe, maybe not, I’d say, looking at millions = of CPEs in the field, the 6rd sunsetting for sure are not needed today.&nbs= p; Wrt DSLite.  I don’t think we can avoid it (unfortunately), b= ut also here applies that the CPE should be able to handle those tunnels, b= ut not yet to also include full PCP support or some other UPnP-kind of mech= anism, it’s too early for that (looking at them being mainly all draf= t stuff).  Of course CPE vendors should look into it today and judge u= pon its impact, but one cannot expect from the CPE vendor (you know, the ve= ry low cost device) to support all of it in 1 go.

     

    I can even go 1 step further: RFC6106 support.  For the record: w= e do support it, however, I see lack of support in the LAN for it, hence no= t very usable today.  OK for CPE to have some basic support for it, bu= t not “all the way” for simple reason that lots of hosts are no= t ready + the fact that no clear view on what should happen in case of both= RA and DHCPv6 stateless, what is “best”, what if different con= tent, ….  This one however is only limited present in RFC6204, w= hich is fine I guess.

     

    Best regards=

    Carl

     

    From: Mark Townsley [mailto:mark@townsley.net]
    Sent: dinsd= ag 24 april 2012 9:34
    To: Wuyts Carl
    Cc: Chris Donley; = v6ops@ietf.org
    Subject: Re: [v6ops] 6rd sunsetting requirements f= or 6204-bis

    &nbs= p;

     

    On Apr 24, 2012, at 8:45 AM, Wuyts Carl wrote:



     

    [Ca= rl] Yes.  A CPE is a router, hence should be capable of making routing= decisions, taking into account multiple paths, metrics, …. .  L= oad balancing for instance might not be supported, so in case of multiple e= qual cost paths, it will take one of the available routes, but this is a kn= own “issue” at that moment.  Lots of things can be set via= TR-069 these days, so ISP can influence e.g. metrics when having native/tu= nneled combination and wanting to enforce a specific route.

     

    We cannot assume all CPE have a TR-69 int= erface.



    [Carl] Not at all.  Our C= PE supports both 6rd, static as well as using the DHCP option 212.  Bu= t when looking today at our customers, there for sure not hitting a 6rd mov= e to native .

     

    Not sure I u= nderstand that sentence.

     

    But, let's just say I am l= ooking at the largest  6rd deployments in the world, and working out h= ow to migrate them to native. That's the basis behind the three requir= ements, and the reason they are being introduced in 6204-bis is that this i= s the first document that considers both native IPv6 and 6rd at the same ti= me. 

     

    I gather your primary customer set is a m= anaged CPE with TR-69. WIth this model, you can of course leave all this up= to configuration, and customize everything for each and every ISP in the w= orld. Retail CPE are different, and the burden on the RFC greater, in order= to achieve the level of consistency across the market that is needed for t= he model to work at all.



    <= o:p>

     =

    All I am trying t= o do is make sure that *if* 6rd is in the document, it is done correctly so= we don't paint ourselves into a corner. 

    [Carl] Saw the picture, see what you mean, but aga= in, should be tackled, however not today.  Allow some time.

     

    6rd has been deployed since 2007, ho= w much longer do we need to get this right?

     

     

    I was also trying t= o do the same with DS-Lite, but have decided to give up. DS-Lite has become= an enormous distraction to the deployment of IPv6 service to internet user= s, so I'm going to stop investing energy into trying to fix it here. Maybe = v4-exit can do better in 6204-ter (sigh). 

    [Carl] Same applies here as for 6rd. 

     

    No. 6rd and DS-Lit= e are not the same, and do not solve the same problems. They are night and = day different, and every time we lump them together it causes confusion and= trouble. Please stop. 


    <= br>

    To start = off, we do support it, again static and dynamic through dhcp option 64, so = no issue on that part.  But proper deployment most likely will require= some extra’s on the CPE, PCP, UPNP-IGD2, something else…. = ; Similar applies here: people starting today to look at it (in Residential= CPE world), but for sure not (yet) targeting the move to native-only, too = soon (unfortunately).

     

    The = real scope creep is the inclusion of IPv4 delivery in an IPv6 CPE document = to start with. If you want to draw a line, draw it before the inclusion of = DS-Lite. Here in v6ops, we need to get IPv6 Internet service off the ground= , and that's already taking plenty of energy as it is. 

    =



     

    As I have said before, I am equally happy with the entire "Transi= tion" section to be removed from 6204-bis. But, if we step off the cli= ff, we're going to get it right, at least for 6rd. Otherwise, it does more = harm than good.

    [Car= l] Don’t fully agree = J.  I see 6rd being used in various ways at our custome= rs today.  I must say it’s working rather smooth, using the feat= ures they have available today, so I’d encourage to keep both 6rd and= DSLite in the doc as is, but not start adding more requirements which are = to be applied in later phases.

     

    Yes, 6rd is working quite well, I cannot argue with you there. 

     

    But, I also want my customers to be able to turn off= 6rd, and for that to happen smoothly. Including the requirements for that = in 6204-bis won't hurt that. As you have said, its all just what a "re= al router" would do anyway.

     

    - Mark<= /p>



    I’ve been present on the last 2 v6 wor= ld congresses in Paris and the general statements there were always “= the CPE is the problem”.  Well, guess what, it still is, and it = still will be if you don’t stop adding requirements. 

    Please draw a line = NOW, and take changes and added requirements into a later version so the CP= E vendor has the time to cope with all of this!!!  I repeat my stateme= nt from the panel: if we don’t stop adding requirements onto the (nea= rly free-of-charge) CPE, the next v6 congress will have again several prese= ntations claiming “The CPE is the problem”.

     

    Just on these specif= ic ones: there is the claim that CPE devices are not “ready” (w= hatever that may mean”).  Today, IPv6 roll-out is, unfortunately= , still very (too) limited, but already “6rd sunsetting” requir= ements are being added to the basic CPE IPV6 reqs, why ?  I don’= t doubt this issue will present itself, but for sure not “tomorrow= 221;.

     

    That's why:

     

    <= o:p>

     <= /p>

    [Carl] I usually start from the other end @ home J

    &nbs= p;

    - Mark




    <= /p>

     

    Regs

    Carl

     =

    F= rom: v6ops-bounces@ietf.org [mailto:v6= ops-bounces@ietf.org] <= b>On Behalf Of Chris Do= nley
    Sent: dinsda= g 24 april 2012 1:04
    To: = ;Mark Townsley; v6ops@ietf.org
    Subject: Re: [v6ops] 6rd sunsetting require= ments for 6204-bis

    <= p class=3DMsoNormal> 

    Mark,

    <= div>

     

    <= /div>

    Please see in-line.

     

    Chris<= /o:p>

     

    From: Mark Townsley <mark@townsley.net>
    Date: Mon, 23 Apr 2012 11:27:36 -0600
    To:     "v6ops@ietf.org" <v6ops@ietf.org>
    Subject: [v6ops] 6rd sunsetting requirements for 6204-bis<= o:p>

    &n= bsp;

    6RD-4: A CE router MUST allow 6rd virtual and IPv6 native WAN int= erfaces to be

    active simultaneously in order to support coexistence of= the two

    technologies during an incremental migration period from 6rd = to native

    IPv6. 

    1. I think this is covered in 6rd-5 and 6rd-7.  =
    2. I don't think this specific requirement was agreed to in Paris. &n= bsp;It's not on your slide 4 or Slide 15, bullet 1, which were the 'hum's I= captured in my notes.
    3. +1 to Hemant's comment – I don't think= this is needed as a MUST.

    &= nbsp;

    6RD-5: The CE router MUST associate delegated prefixes with the= WAN

    interface(s) they were learned from (e.g., DHCPv6-PD, 6rd, etc). = Each

    packet sent out a WAN interface MUST have a source address that

    <= span style=3D'font-size:13.5pt;font-family:"Calibri","sans-serif";color:bla= ck'>corresponds to a delegated prefix associated with the given WAN<= o:p>

    in= terface, consistent with what is described in section 4.3 of BCP

    84 (R= FC 3704).

    1. We've been advised by the WG in the past to only include a single n= ormative statement per requirement.
    2. This is covered in the existing= 6rd-4.

     =

    6RD-6:= The IPv6 CE router MUST allow different or identical delegated prefixes

    on 6rd and native interfaces. A 6rd virtual interface MUST be assig= ned a 

    higher routing cost than a native IPv6 interface. This is= done so that native 

    traffic will be preferred over 6r= d in the event normal IP longest matching 

    <= /div>

    and BCP 84 rules = would have otherwise allowed a packet to be equally sent <= /o:p>

    via 6r= d or native IPv6.

    1. I think this language (…MUST allow different or ident= ical delegated prefixes…) is confusing for people not intimately fami= liar with your other CE transitioning draft. 
      2. If I read this c= orrectly, you want to require two operational states – one where 6rd = and native IPv6 use the same prefix and a second where they use different p= refixes. That requirement is captured in 6rd-5.
    2. As I mentioned abo= ve, we have been advised to keep requirements to a single normative stateme= nt, so the part about the routing cost is in 6rd-6.
      3. <= li class=3DMsoNormal style=3D'color:black;mso-list:l1 level1 lfo3'>I've heard from= some CPE vendors that specifying routing "cost" may be too imple= mentation specific – I think it's more neutral to speak of preference= – e.g. prefer native to 6rd.
    =

     

     

    = --_000_867F4B6A1672E541A94676D556793ACD108F21A6B7MOPESMBX01eut_-- From despres.remi@laposte.net Tue Apr 24 02:47:00 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A70A21F86FF for ; Tue, 24 Apr 2012 02:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.169 X-Spam-Level: X-Spam-Status: No, score=-2.169 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, 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 jJzdzRd0O+1f for ; Tue, 24 Apr 2012 02:46:59 -0700 (PDT) Received: from smtpout.laposte.net (smtpout4.laposte.net [193.253.67.229]) by ietfa.amsl.com (Postfix) with ESMTP id E2AAE21F86DD for ; Tue, 24 Apr 2012 02:46:58 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8508-out with ME id 1lms1j00837Y3f403lmsZk; Tue, 24 Apr 2012 11:46:57 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-68-471326867 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 24 Apr 2012 11:46:52 +0200 Message-Id: <6B2D2593-EE73-458D-BF42-F6507CF42646@laposte.net> References: <20120417065542.31115.95082.idtracker@ietfa.amsl.com> <20120417160010kawashimam@mail.jp.nec.com> <56E2AD61-1C91-4889-914A-353793FCBE43@laposte.net> <20120419121044.17531mk1mv19abr4@mail.drown.org> <0646611B-5594-40EA-A2C4-F99CBA734024@laposte.net> <20120419181813.4524701l3gkq5zks@mail.drown.org> <45ABAD31-C265-4D63-82E2-3DE6F59B80C0@laposte.net> <20120420104246.1432746csfcrdqo8@mail.drown.org> <20120420122715.1702279xh7eynpus@mail.drown.org> <20120420175036.70482p5axgf81lq8@mail.drown.org> <2950A57B-DA87-4641-8540-8972F5C437CF@laposte.net> To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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, 24 Apr 2012 09:47:00 -0000 --Apple-Mail-68-471326867 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-04-24 =E0 10:50, Lorenzo Colitti a =E9crit : > On Sat, Apr 21, 2012 at 17:50, R=E9mi Despr=E9s = wrote: > Now, avoiding ND proxy on two addresses REMAINS POSSIBLE. > - It is sufficient that a CLAT interface ID be reserved by IETF/IANA = (an ID that no host may legitimately use). > - This can be done, in compliance with RFC 5342, with a = modified-EUI-64 ID based on IANA's OUI. > - Proposed ID value is 02-00-5E-10--00-00-00-00 (in the available = range of www.iana.org/assignments/ethernet-numbers for this). >=20 > What if the user manually specifies the interface ID on a tethered = device? Will DAD just fail? Good point. A host that is manually configured (not typical but possible) might by = mistake try to use the 464XLAT reserved IID. Avoiding possible consequences of such a mis-configuration is = preferable. For this, a requirement can be added that a CLAT node should, in its ND = answers on its LAN side, refuse the 464XLAT-reserved interface ID.=20 The difference with the ND proxy on two legitimate host addresses, is = then only that it is just a security protection, normally no applicable. This difference is very minor, but using a well known interface ID has = other advantages: - It facilitates traffic monitoring, and maintenance. - It also eliminates the need to explain that: . customers are RFC6052 operators having their own NSPs (somewhat = confusing IMHO) . their translators work with two service-provider prefixes (not = needed). RD --Apple-Mail-68-471326867 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
    On = Sat, Apr 21, 2012 at 17:50, R=E9mi Despr=E9s <despres.remi@laposte.net> wrote:
    Now, avoiding ND proxy = on two addresses REMAINS POSSIBLE.
    - It is sufficient that a CLAT interface ID be reserved by IETF/IANA (an = ID that no host may legitimately use).
    - This can be done, in compliance with RFC 5342, with a modified-EUI-64 = ID based on IANA's OUI.
    - Proposed ID value is 02-00-5E-10--00-00-00-00 (in the available range = of www.iana.org/assignments/ethernet-numbers for = this).

    What if the user manually specifies the interface ID = on a tethered device? Will DAD just fail?

    Good point.
    A host that is = manually configured (not typical but possible) might by mistake try to = use the 464XLAT reserved IID.
    Avoiding possible consequences = of such a mis-configuration is preferable.

    For = this, a requirement can be added that a CLAT node should, in its ND = answers on its LAN side, refuse the 464XLAT-reserved interface = ID. 
    The difference with the ND proxy on two legitimate = host addresses, is then only that it is just a security protection, = normally no applicable.
    This difference is very minor, but = using a well known interface ID has other advantages:
    - = It facilitates traffic monitoring, and maintenance.
    - It also = eliminates the need to explain that:
     . customers = are RFC6052 operators having their own NSPs (somewhat = confusing IMHO)
     . their translators work with two = service-provider prefixes (not = needed).

    RD





    = --Apple-Mail-68-471326867-- From fibrib@gmail.com Tue Apr 24 03:53:51 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F60C21F8704 for ; Tue, 24 Apr 2012 03:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.963 X-Spam-Level: X-Spam-Status: No, score=-1.963 tagged_above=-999 required=5 tests=[AWL=-1.115, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BjHQ5B3Omlp8 for ; Tue, 24 Apr 2012 03:53:49 -0700 (PDT) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) by ietfa.amsl.com (Postfix) with ESMTP id AB49821F86F5 for ; Tue, 24 Apr 2012 03:53:49 -0700 (PDT) Received: by qafi31 with SMTP id i31so2703015qaf.15 for ; Tue, 24 Apr 2012 03:53:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=F5GvsAX/X/R+ypU0NjMBiG9JIrf+xRcaruc9V+mjyl4=; b=I16KaZs2irqdOAWrPoxtgoqld7pH5wR4SqWxGMSbPeA3YHICVhHB9jX4m+M8DRFffP 5w7xIKqR3fOtDYKfn1exG3xkK7+wrmHrx/KoM9nHGuo8IDytBJT0kZlRrs0KUejy9wHi HN1xY7qfcOLd2hCk+blLUGmleJ+t3cuzlLZvI3OgWuY3eSxzka9o0aDdmhxudwkLapBJ U0f1wBxaaPJOfu5Lr2f22Winggp77DdVunxHZGC2weCP/1is5KnPPsMx/S+BwywlwX33 CFmLKpg3/r4O8iCOQw8ftYmZtd6o1dmHjLoU6yWedZvt3VDzxrxW2KPGvQ1ArYTOrUNO mGkQ== MIME-Version: 1.0 Received: by 10.224.187.210 with SMTP id cx18mr1637248qab.45.1335264829023; Tue, 24 Apr 2012 03:53:49 -0700 (PDT) Received: by 10.229.123.197 with HTTP; Tue, 24 Apr 2012 03:53:48 -0700 (PDT) In-Reply-To: <6B2D2593-EE73-458D-BF42-F6507CF42646@laposte.net> References: <20120417065542.31115.95082.idtracker@ietfa.amsl.com> <20120417160010kawashimam@mail.jp.nec.com> <56E2AD61-1C91-4889-914A-353793FCBE43@laposte.net> <20120419121044.17531mk1mv19abr4@mail.drown.org> <0646611B-5594-40EA-A2C4-F99CBA734024@laposte.net> <20120419181813.4524701l3gkq5zks@mail.drown.org> <45ABAD31-C265-4D63-82E2-3DE6F59B80C0@laposte.net> <20120420104246.1432746csfcrdqo8@mail.drown.org> <20120420122715.1702279xh7eynpus@mail.drown.org> <20120420175036.70482p5axgf81lq8@mail.drown.org> <2950A57B-DA87-4641-8540-8972F5C437CF@laposte.net> <6B2D2593-EE73-458D-BF42-F6507CF42646@laposte.net> Date: Tue, 24 Apr 2012 19:53:48 +0900 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=485b397dd4bbd0a4e704be6a91e2 Cc: v6ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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, 24 Apr 2012 10:53:51 -0000 --485b397dd4bbd0a4e704be6a91e2 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Remi, =D4=DA 2012=C4=EA4=D4=C224=C8=D5=D0=C7=C6=DA=B6=FE=A3=ACR=A8=A6mi Despr=A8= =A6s =D0=B4=B5=C0=A3=BA > > Le 2012-04-24 =A8=A4 10:50, Lorenzo Colitti a =A8=A6crit : > > On Sat, Apr 21, 2012 at 17:50, R=A8=A6mi Despr=A8=A6s > > wrote: > >> Now, avoiding ND proxy on two addresses REMAINS POSSIBLE. >> - It is sufficient that a CLAT interface ID be reserved by IETF/IANA (an >> ID that no host may legitimately use). >> - This can be done, in compliance with RFC 5342, with a modified-EUI-64 >> ID based on IANA's OUI. >> - Proposed ID value is 02-00-5E-10--00-00-00-00 (in the available range >> of www.iana.org/assignments/ethernet-numbers for this). >> > > What if the user manually specifies the interface ID on a tethered device= ? > Will DAD just fail? > > > Good point. > A host that is manually configured (not typical but possible) might by > mistake try to use the 464XLAT reserved IID. > Avoiding possible consequences of such a mis-configuration is preferable. > > For this, a requirement can be added that a CLAT node should, in its ND > answers on its LAN side, refuse the 464XLAT-reserved interface ID. > The difference with the ND proxy on two legitimate host addresses, is the= n > only that it is just a security protection, normally no applicable. > This difference is very minor, but using a well known interface ID has > other advantages: > - It facilitates traffic monitoring, and maintenance. > - It also eliminates the need to explain that: > . customers are RFC6052 operators having their own NSPs (somewhat > confusing IMHO) > . their translators work with two service-provider prefixes (not needed)= . > > i couldn't catch your point. even now two prefices are not *needed*. - maoke RD > > > > > > --485b397dd4bbd0a4e704be6a91e2 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable Remi,

    =D4=DA 2012=C4=EA4=D4=C224=C8=D5=D0=C7=C6=DA=B6=FE=A3=ACR=A8= =A6mi Despr=A8=A6s =D0=B4=B5=C0=A3=BA

    Le 2012-04-24 =A8=A4 10:50,= Lorenzo Colitti a =A8=A6crit :

    On Sat, Apr 21, 2012 at 17:50, R=A8=A6mi Despr=A8=A6s <despres.remi@laposte.net>= wrote:
    Now, avoiding ND proxy on two addresses REMA= INS POSSIBLE.
    - It is sufficient that a CLAT interface ID be reserved by IETF/IANA (an ID= that no host may legitimately use).
    - This can be done, in compliance with RFC 5342, with a modified-EUI-64 ID = based on IANA's OUI.
    - Proposed ID value is 02-00-5E-10--00-00-00-00 (in the available range of = www.iana.org/assignments/ethernet-numbers for this).

    What if the user manually specifies the interface ID on= a tethered device? Will DAD just fail?

    Good point.
    A host that is manually c= onfigured (not typical but possible) might by mistake try to use the 464XLA= T reserved IID.
    Avoiding possible consequences of such a mis-conf= iguration is preferable.

    For this, a requirement can be added that a CLAT node s= hould, in its ND answers on its LAN side, refuse the 464XLAT-reserved inter= face ID. 
    The difference with the ND proxy on two legitimate= host addresses, is then only that it is just a security protection, normal= ly no applicable.
    This difference is very minor, but using a well known interface I= D has other advantages:
    - It facilitates traffic monitoring, and = maintenance.
    - It also eliminates the need to explain that:
    =
     . customers are RFC6052 operators having their own NSPs&nbs= p;(somewhat confusing IMHO)
     . their translators work with t= wo service-provider prefixes (not needed).


    i couldn't catch your point. even now two prefices are not *needed= *. 
    - maoke


    =
    RD





    --485b397dd4bbd0a4e704be6a91e2-- From fibrib@gmail.com Tue Apr 24 03:56:45 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0D8721F8755 for ; Tue, 24 Apr 2012 03:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.938 X-Spam-Level: X-Spam-Status: No, score=-1.938 tagged_above=-999 required=5 tests=[AWL=-1.090, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id erave000kdY9 for ; Tue, 24 Apr 2012 03:56:45 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id BF3B321F874C for ; Tue, 24 Apr 2012 03:56:44 -0700 (PDT) Received: by qcsq13 with SMTP id q13so297208qcs.31 for ; Tue, 24 Apr 2012 03:56:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CvcPXhnxIY1u1mW3Ylt8B6uDgUBo8pyhdPEXCvKLqSo=; b=y62e+GqStrpCWplRMC0i5pI+Y4Xe04L/RSXvzdcs8KUQS58W+81KmeNbuUdhmeoCz8 qm+Web7+ErobastexYUe7OV/Rw0z5+hA+/In81iP/aoyg22X8Ltez9P7g3DT9ZhRM3cU K996du7VSGDGmTrzNcglLP988xvsrhl8SGSr1EKXWYywbRUZGBW112pTCOCquYXGm0FL 9+3xHqt5GmQpxn+15zC5WsEkaHRYUDIxUgGVRKFgKZE6FdL1M5BpDAYyeqBFPCOadOQ6 e8WxZlQC/rxi8lU0G5Cvs0H3iklePWSEVLNGH7rdUiZoOaxLN89PX3utZyV+ZeIHNDX8 Iuxw== MIME-Version: 1.0 Received: by 10.224.35.130 with SMTP id p2mr16076148qad.32.1335265004289; Tue, 24 Apr 2012 03:56:44 -0700 (PDT) Received: by 10.229.123.197 with HTTP; Tue, 24 Apr 2012 03:56:44 -0700 (PDT) In-Reply-To: <6B2D2593-EE73-458D-BF42-F6507CF42646@laposte.net> References: <20120417065542.31115.95082.idtracker@ietfa.amsl.com> <20120417160010kawashimam@mail.jp.nec.com> <56E2AD61-1C91-4889-914A-353793FCBE43@laposte.net> <20120419121044.17531mk1mv19abr4@mail.drown.org> <0646611B-5594-40EA-A2C4-F99CBA734024@laposte.net> <20120419181813.4524701l3gkq5zks@mail.drown.org> <45ABAD31-C265-4D63-82E2-3DE6F59B80C0@laposte.net> <20120420104246.1432746csfcrdqo8@mail.drown.org> <20120420122715.1702279xh7eynpus@mail.drown.org> <20120420175036.70482p5axgf81lq8@mail.drown.org> <2950A57B-DA87-4641-8540-8972F5C437CF@laposte.net> <6B2D2593-EE73-458D-BF42-F6507CF42646@laposte.net> Date: Tue, 24 Apr 2012 19:56:44 +0900 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=20cf306f744a42fccb04be6a9ccf Cc: v6ops WG Subject: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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, 24 Apr 2012 10:56:45 -0000 --20cf306f744a42fccb04be6a9ccf Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Remi, =D4=DA 2012=C4=EA4=D4=C224=C8=D5=D0=C7=C6=DA=B6=FE=A3=ACR=A8=A6mi Despr=A8= =A6s =D0=B4=B5=C0=A3=BA > > Le 2012-04-24 =A8=A4 10:50, Lorenzo Colitti a =A8=A6crit : > > On Sat, Apr 21, 2012 at 17:50, R=A8=A6mi Despr=A8=A6s wrote: > >> Now, avoiding ND proxy on two addresses REMAINS POSSIBLE. >> - It is sufficient that a CLAT interface ID be reserved by IETF/IANA (an >> ID that no host may legitimately use). >> - This can be done, in compliance with RFC 5342, with a modified-EUI-64 >> ID based on IANA's OUI. >> - Proposed ID value is 02-00-5E-10--00-00-00-00 (in the available range >> of www.iana.org/assignments/ethernet-numbers for this). >> > > What if the user manually specifies the interface ID on a tethered device= ? > Will DAD just fail? > > > Good point. > A host that is manually configured (not typical but possible) might by > mistake try to use the 464XLAT reserved IID. > Avoiding possible consequences of such a mis-configuration is preferable. > > For this, a requirement can be added that a CLAT node should, in its ND > answers on its LAN side, refuse the 464XLAT-reserved interface ID. > The difference with the ND proxy on two legitimate host addresses, is the= n > only that it is just a security protection, normally no applicable. > This difference is very minor, but using a well known interface ID has > other advantages: > - It facilitates traffic monitoring, and maintenance. > - It also eliminates the need to explain that: > . customers are RFC6052 operators having their own NSPs (somewhat > confusing IMHO) > . their translators work with two service-provider prefixes (not needed)= . > > i couldn't catch your point. even now two prefices are not *needed*. RD > > > > > > --20cf306f744a42fccb04be6a9ccf Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable Remi,

    =D4=DA 2012=C4=EA4=D4=C224=C8=D5=D0=C7=C6=DA=B6=FE=A3=ACR=A8= =A6mi Despr=A8=A6s =D0=B4=B5=C0=A3=BA

    Le 2012-04-24 =A8=A4 10:50,= Lorenzo Colitti a =A8=A6crit :

    On Sat, Apr 21, 2012 at 17:50, R=A8=A6mi Despr=A8=A6s <despres.remi@laposte.net> wrote:
    Now, avoiding ND proxy on two addresses REMA= INS POSSIBLE.
    - It is sufficient that a CLAT interface ID be reserved by IETF/IANA (an ID= that no host may legitimately use).
    - This can be done, in compliance with RFC 5342, with a modified-EUI-64 ID = based on IANA's OUI.
    - Proposed ID value is 02-00-5E-10--00-00-00-00 (in the available range of = www.iana.org/assignments/ethernet-numbers for this).

    What if the user manually specifies the interface ID on= a tethered device? Will DAD just fail?

    Good point.
    A host that is manually c= onfigured (not typical but possible) might by mistake try to use the 464XLA= T reserved IID.
    Avoiding possible consequences of such a mis-conf= iguration is preferable.

    For this, a requirement can be added that a CLAT node s= hould, in its ND answers on its LAN side, refuse the 464XLAT-reserved inter= face ID. 
    The difference with the ND proxy on two legitimate= host addresses, is then only that it is just a security protection, normal= ly no applicable.
    This difference is very minor, but using a well known interface I= D has other advantages:
    - It facilitates traffic monitoring, and = maintenance.
    - It also eliminates the need to explain that:
     . customers are RFC6052 operators having their own NSPs&nbs= p;(somewhat confusing IMHO)
     . their translators work with t= wo service-provider prefixes (not needed).


    i couldn't catch your point. even now two prefices are not *needed= *. 



    RD





    --20cf306f744a42fccb04be6a9ccf-- From despres.remi@laposte.net Tue Apr 24 05:11:29 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 987D121F85C4 for ; Tue, 24 Apr 2012 05:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.473 X-Spam-Level: X-Spam-Status: No, score=-1.473 tagged_above=-999 required=5 tests=[AWL=-0.571, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VcIpuD6YT5HC for ; Tue, 24 Apr 2012 05:11:28 -0700 (PDT) Received: from smtpout.laposte.net (smtpout1.laposte.net [193.253.67.226]) by ietfa.amsl.com (Postfix) with ESMTP id 12D7421F85AD for ; Tue, 24 Apr 2012 05:11:27 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8502-out with ME id 1oBR1j00137Y3f403oBRjt; Tue, 24 Apr 2012 14:11:26 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-69-479999511 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 24 Apr 2012 14:11:24 +0200 Message-Id: <5423D1CD-1E7D-4E4F-9FBB-E367D6954F68@laposte.net> References: <20120417065542.31115.95082.idtracker@ietfa.amsl.com> <20120417160010kawashimam@mail.jp.nec.com> <56E2AD61-1C91-4889-914A-353793FCBE43@laposte.net> <20120419121044.17531mk1mv19abr4@mail.drown.org> <0646611B-5594-40EA-A2C4-F99CBA734024@laposte.net> <20120419181813.4524701l3gkq5zks@mail.drown.org> <45ABAD31-C265-4D63-82E2-3DE6F59B80C0@laposte.net> <20120420104246.1432746csfcrdqo8@mail.drown.org> <20120420122715.1702279xh7eynpus@mail.drown.org> <20120420175036.70482p5axgf81lq8@mail.drown.org> <2950A57B-DA87-4641-8540-8972F5C437CF@laposte.net> <6B2D2593-EE73-458D-BF42-F6507CF42646@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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, 24 Apr 2012 12:11:29 -0000 --Apple-Mail-69-479999511 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Le 2012-04-24 =C3=A0 12:53, Maoke a =C3=A9crit : > Remi, >=20 > =E5=9C=A8 2012=E5=B9=B44=E6=9C=8824=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C=EF= =BC=8CR=C3=A9mi Despr=C3=A9s =E5=86=99=E9=81=93=EF=BC=9A >=20 > Le 2012-04-24 =C3=A0 10:50, Lorenzo Colitti a =C3=A9crit : >=20 >> On Sat, Apr 21, 2012 at 17:50, R=C3=A9mi Despr=C3=A9s = wrote: >> Now, avoiding ND proxy on two addresses REMAINS POSSIBLE. >> - It is sufficient that a CLAT interface ID be reserved by IETF/IANA = (an ID that no host may legitimately use). >> - This can be done, in compliance with RFC 5342, with a = modified-EUI-64 ID based on IANA's OUI. >> - Proposed ID value is 02-00-5E-10--00-00-00-00 (in the available = range of www.iana.org/assignments/ethernet-numbers for this). >>=20 >> What if the user manually specifies the interface ID on a tethered = device? Will DAD just fail? >=20 > Good point. > A host that is manually configured (not typical but possible) might by = mistake try to use the 464XLAT reserved IID. > Avoiding possible consequences of such a mis-configuration is = preferable. >=20 > For this, a requirement can be added that a CLAT node should, in its = ND answers on its LAN side, refuse the 464XLAT-reserved interface ID.=20 > The difference with the ND proxy on two legitimate host addresses, is = then only that it is just a security protection, normally no applicable. > This difference is very minor, but using a well known interface ID has = other advantages: > - It facilitates traffic monitoring, and maintenance. > - It also eliminates the need to explain that: > . customers are RFC6052 operators having their own NSPs (somewhat = confusing IMHO) > . their translators work with two service-provider prefixes (not = needed). >=20 >=20 > i couldn't catch your point. even now two prefices are not *needed*.=20= If a CLAT uses the NAT64 prefix for upstream IPv4 addresses and a = CLAT-site prefix for downstream IPv4 addresses, it is my understanding = that it works with two RFC6052 prefixes. RD > - maoke >=20 >=20 >=20 > RD >=20 >=20 >=20 >=20 >=20 --Apple-Mail-69-479999511 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
    Remi,

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

    Le 2012-04-24 =C3=A0 10:50, = Lorenzo Colitti a =C3=A9crit :

    On Sat, Apr 21, 2012 at 17:50, R=C3=A9mi Despr=C3=A9= s <despres.remi@laposte.net> wrote:
    Now, avoiding ND proxy = on two addresses REMAINS POSSIBLE.
    - It is sufficient that a CLAT interface ID be reserved by IETF/IANA (an = ID that no host may legitimately use).
    - This can be done, in compliance with RFC 5342, with a modified-EUI-64 = ID based on IANA's OUI.
    - Proposed ID value is 02-00-5E-10--00-00-00-00 (in the available range = of www.iana.org/assignments/ethernet-numbers for = this).

    What if the user manually specifies the interface ID = on a tethered device? Will DAD just fail?

    Good point.
    A host that is = manually configured (not typical but possible) might by mistake try to = use the 464XLAT reserved IID.
    Avoiding possible consequences = of such a mis-configuration is preferable.

    For this, a requirement can be added that a CLAT = node should, in its ND answers on its LAN side, refuse the = 464XLAT-reserved interface ID. 
    The difference with the = ND proxy on two legitimate host addresses, is then only that it is just = a security protection, normally no applicable.
    This difference is very minor, but using a well known = interface ID has other advantages:
    - It facilitates traffic = monitoring, and maintenance.
    - It also eliminates the need to = explain that:
     . customers are RFC6052 operators having their own = NSPs (somewhat confusing IMHO)
     . their translators = work with two service-provider prefixes (not = needed).


    i couldn't catch your point. even now two prefices are not = *needed*. 

    If a CLAT uses the = NAT64 prefix for upstream IPv4 addresses and  a CLAT-site = prefix for downstream IPv4 addresses, it is my understanding that it = works with two RFC6052 = prefixes.

    RD


    <= div>
    - = maoke



    RD


    =




    = --Apple-Mail-69-479999511-- From fibrib@gmail.com Tue Apr 24 05:24:52 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F95421F87B6 for ; Tue, 24 Apr 2012 05:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.914 X-Spam-Level: X-Spam-Status: No, score=-1.914 tagged_above=-999 required=5 tests=[AWL=-1.066, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0-Wz5YunfCTX for ; Tue, 24 Apr 2012 05:24:51 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 04AAF21F87B5 for ; Tue, 24 Apr 2012 05:24:50 -0700 (PDT) Received: by qaea16 with SMTP id a16so16077qae.10 for ; Tue, 24 Apr 2012 05:24:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LEowoBjhknO9QS/qV0W3xhe/Ok7AHCzIBamDUkiDOSw=; b=nIuE/5PJqyzrfHbzQWc0M6A5zcVaXHnYQ1eqBbMRnX7l1mz50zvYrr6l8JaNFboo3N LrHjeSffc2hwcnMcjse55JAjO5prpwvxszdE3hO6k1tp1HgjR8CRZlLWM+4cYUDqvk4U /hvmm0m8ng8PM3cDvFwYWqbrJblRW2vgBZnQ0lnGpJZ7UL6/kNPfIbmolsePaQy4gFHQ U5KYLp42A53Wd8Kyl7bvYnFAyJietnUfkxB+h6HALEmcmIy/4f/XhEsxxfm3nKjhZkeU 6K26OBrMUqqOQCblNyZd57FHVAJfz4xRJUqNLdXcsU0Oj/69UO5JsZAbOT2RD1RxRtPL NcUA== MIME-Version: 1.0 Received: by 10.224.1.68 with SMTP id 4mr16321409qae.6.1335270290456; Tue, 24 Apr 2012 05:24:50 -0700 (PDT) Received: by 10.229.123.197 with HTTP; Tue, 24 Apr 2012 05:24:50 -0700 (PDT) In-Reply-To: <5423D1CD-1E7D-4E4F-9FBB-E367D6954F68@laposte.net> References: <20120417065542.31115.95082.idtracker@ietfa.amsl.com> <20120417160010kawashimam@mail.jp.nec.com> <56E2AD61-1C91-4889-914A-353793FCBE43@laposte.net> <20120419121044.17531mk1mv19abr4@mail.drown.org> <0646611B-5594-40EA-A2C4-F99CBA734024@laposte.net> <20120419181813.4524701l3gkq5zks@mail.drown.org> <45ABAD31-C265-4D63-82E2-3DE6F59B80C0@laposte.net> <20120420104246.1432746csfcrdqo8@mail.drown.org> <20120420122715.1702279xh7eynpus@mail.drown.org> <20120420175036.70482p5axgf81lq8@mail.drown.org> <2950A57B-DA87-4641-8540-8972F5C437CF@laposte.net> <6B2D2593-EE73-458D-BF42-F6507CF42646@laposte.net> <5423D1CD-1E7D-4E4F-9FBB-E367D6954F68@laposte.net> Date: Tue, 24 Apr 2012 21:24:50 +0900 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=20cf3074d8065781de04be6bd76a Cc: v6ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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, 24 Apr 2012 12:24:52 -0000 --20cf3074d8065781de04be6bd76a Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable j =D4=DA 2012=C4=EA4=D4=C224=C8=D5=D0=C7=C6=DA=B6=FE=A3=ACR=A8=A6mi Despr=A8= =A6s =D0=B4=B5=C0=A3=BA > > Le 2012-04-24 =A8=A4 12:53, Maoke a =A8=A6crit : > > Remi, > > =D4=DA 2012=C4=EA4=D4=C224=C8=D5=D0=C7=C6=DA=B6=FE=A3=ACR=A8=A6mi Despr= =A8=A6s =D0=B4=B5=C0=A3=BA > >> >> Le 2012-04-24 =A8=A4 10:50, Lorenzo Colitti a =A8=A6crit : >> >> On Sat, Apr 21, 2012 at 17:50, R=A8=A6mi Despr=A8=A6s wrote: >> >>> Now, avoiding ND proxy on two addresses REMAINS POSSIBLE. >>> - It is sufficient that a CLAT interface ID be reserved by IETF/IANA (a= n >>> ID that no host may legitimately use). >>> - This can be done, in compliance with RFC 5342, with a modified-EUI-64 >>> ID based on IANA's OUI. >>> - Proposed ID value is 02-00-5E-10--00-00-00-00 (in the available range >>> of www.iana.org/assignments/ethernet-numbers for this). >>> >> >> What if the user manually specifies the interface ID on a tethered >> device? Will DAD just fail? >> >> >> Good point. >> A host that is manually configured (not typical but possible) might by >> mistake try to use the 464XLAT reserved IID. >> Avoiding possible consequences of such a mis-configuration is preferable= . >> >> For this, a requirement can be added that a CLAT node should, in its ND >> answers on its LAN side, refuse the 464XLAT-reserved interface ID. >> The difference with the ND proxy on two legitimate host addresses, is >> then only that it is just a security protection, normally no applicable. >> This difference is very minor, but using a well known interface ID has >> other advantages: >> - It facilitates traffic monitoring, and maintenance. >> - It also eliminates the need to explain that: >> . customers are RFC6052 operators having their own NSPs (somewhat >> confusing IMHO) >> . their translators work with two service-provider prefixes (not needed= ). >> >> > i couldn't catch your point. even now two prefices are not *needed*. > > > If a CLAT uses the NAT64 prefix for upstream IPv4 addresses and a > CLAT-site prefix for downstream IPv4 addresses, it is my understanding th= at > it works with two RFC6052 prefixes. > so you mean a prefix for remote peer while another for local site, right? if so, first, i think it is natural to have different prefices for peers not belonging to the same network; second, the NAT64 prefix is common in the deployment domain and does not belong to a CLAT. if we have n CLATs, we need n+1 prefices rather than 2n. calling them "a CLAT needs two prefices" is IMHO misleading. - maoke > RD > > > > - maoke > > > > RD >> >> >> >> >> >> > --20cf3074d8065781de04be6bd76a Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable j


    =D4=DA 2012=C4=EA4=D4=C224=C8=D5=D0=C7=C6=DA=B6=FE=A3=ACR=A8= =A6mi Despr=A8=A6s =D0=B4=B5=C0=A3=BA

    Le 2012-04-24 =A8=A4 12:53,= Maoke a =A8=A6crit :

    Remi,

    =D4=DA 2012=C4=EA4=D4=C224=C8=D5= =D0=C7=C6=DA=B6=FE=A3=ACR=A8=A6mi Despr=A8=A6s =D0=B4=B5=C0=A3=BA

    Le 2012-04-24 =A8=A4 10:50, Lorenzo Colitti a =A8=A6crit :

    On Sat, Apr 21, 2012 at 17:50, R=A8=A6mi Despr=A8=A6s <despres.remi@laposte.net> wrote:
    Now, avoiding ND proxy on two addresses REMA= INS POSSIBLE.
    - It is sufficient that a CLAT interface ID be reserved by IETF/IANA (an ID= that no host may legitimately use).
    - This can be done, in compliance with RFC 5342, with a modified-EUI-64 ID = based on IANA's OUI.
    - Proposed ID value is 02-00-5E-10--00-00-00-00 (in the available range of = www.iana.org/assignments/ethernet-numbers for this).

    What if the user manually specifies the interface ID on= a tethered device? Will DAD just fail?

    Good point.
    A host that is manually c= onfigured (not typical but possible) might by mistake try to use the 464XLA= T reserved IID.
    Avoiding possible consequences of such a mis-conf= iguration is preferable.

    For this, a requirement can be added that a CLAT node s= hould, in its ND answers on its LAN side, refuse the 464XLAT-reserved inter= face ID. 
    The difference with the ND proxy on two legitimate= host addresses, is then only that it is just a security protection, normal= ly no applicable.
    This difference is very minor, but using a well known interface I= D has other advantages:
    - It facilitates traffic monitoring, and = maintenance.
    - It also eliminates the need to explain that:
     . customers are RFC6052 operators having their own NSPs&nbs= p;(somewhat confusing IMHO)
     . their translators work with t= wo service-provider prefixes (not needed).


    i couldn't catch your point. even now two prefices are not *needed= *. 

    If a CLAT uses the NAT64 prefix f= or upstream IPv4 addresses and  a CLAT-site prefix for downstream= IPv4 addresses, it is my understanding that it works with two RFC6052 pref= ixes.

    so you mean a prefix for remote peer= while another for local site, right? if so, first, i think it is natural t= o have different prefices for peers not belonging to the same network; seco= nd, the NAT64 prefix is common in the deployment domain and does not belong= to a CLAT. if we have n CLATs, we need n+1 prefices rather than 2n. callin= g them "a CLAT needs two prefices" is IMHO misleading. - maoke



    RD


    <= br>
    - maoke



    RD






    --20cf3074d8065781de04be6bd76a-- From despres.remi@laposte.net Tue Apr 24 05:34:39 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A37521F87DE for ; Tue, 24 Apr 2012 05:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.464 X-Spam-Level: X-Spam-Status: No, score=-1.464 tagged_above=-999 required=5 tests=[AWL=-0.562, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UC8EyW4i9O5L for ; Tue, 24 Apr 2012 05:34:38 -0700 (PDT) Received: from smtpout.laposte.net (smtpout3.laposte.net [193.253.67.228]) by ietfa.amsl.com (Postfix) with ESMTP id 0D13221F87DD for ; Tue, 24 Apr 2012 05:34:37 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8505-out with ME id 1oab1j00F37Y3f403oabLL; Tue, 24 Apr 2012 14:34:36 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-70-481389962 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 24 Apr 2012 14:34:35 +0200 Message-Id: <00203A61-8588-4B55-A6FD-406031ACDF27@laposte.net> References: <20120417065542.31115.95082.idtracker@ietfa.amsl.com> <20120417160010kawashimam@mail.jp.nec.com> <56E2AD61-1C91-4889-914A-353793FCBE43@laposte.net> <20120419121044.17531mk1mv19abr4@mail.drown.org> <0646611B-5594-40EA-A2C4-F99CBA734024@laposte.net> <20120419181813.4524701l3gkq5zks@mail.drown.org> <45ABAD31-C265-4D63-82E2-3DE6F59B80C0@laposte.net> <20120420104246.1432746csfcrdqo8@mail.drown.org> <20120420122715.1702279xh7eynpus@mail.drown.org> <20120420175036.70482p5axgf81lq8@mail.drown.org> <2950A57B-DA87-4641-8540-8972F5C437CF@laposte.net> <6B2D2593-EE73-458D-BF42-F6507CF42646@laposte.net> <5423D1CD-1E7D-4E4F-9FBB-E367D6954F68@laposte.net> To: Maoke X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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, 24 Apr 2012 12:34:39 -0000 --Apple-Mail-70-481389962 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Le 2012-04-24 =C3=A0 14:24, Maoke a =C3=A9crit : > j >=20 >=20 > =E5=9C=A8 2012=E5=B9=B44=E6=9C=8824=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C=EF= =BC=8CR=C3=A9mi Despr=C3=A9s =E5=86=99=E9=81=93=EF=BC=9A >=20 > Le 2012-04-24 =C3=A0 12:53, Maoke a =C3=A9crit : >=20 >> Remi, >>=20 >> =E5=9C=A8 2012=E5=B9=B44=E6=9C=8824=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C= =EF=BC=8CR=C3=A9mi Despr=C3=A9s =E5=86=99=E9=81=93=EF=BC=9A >>=20 >> Le 2012-04-24 =C3=A0 10:50, Lorenzo Colitti a =C3=A9crit : >>=20 >>> On Sat, Apr 21, 2012 at 17:50, R=C3=A9mi Despr=C3=A9s = wrote: >>> Now, avoiding ND proxy on two addresses REMAINS POSSIBLE. >>> - It is sufficient that a CLAT interface ID be reserved by IETF/IANA = (an ID that no host may legitimately use). >>> - This can be done, in compliance with RFC 5342, with a = modified-EUI-64 ID based on IANA's OUI. >>> - Proposed ID value is 02-00-5E-10--00-00-00-00 (in the available = range of www.iana.org/assignments/ethernet-numbers for this). >>>=20 >>> What if the user manually specifies the interface ID on a tethered = device? Will DAD just fail? >>=20 >> Good point. >> A host that is manually configured (not typical but possible) might = by mistake try to use the 464XLAT reserved IID. >> Avoiding possible consequences of such a mis-configuration is = preferable. >>=20 >> For this, a requirement can be added that a CLAT node should, in its = ND answers on its LAN side, refuse the 464XLAT-reserved interface ID.=20 >> The difference with the ND proxy on two legitimate host addresses, is = then only that it is just a security protection, normally no applicable. >> This difference is very minor, but using a well known interface ID = has other advantages: >> - It facilitates traffic monitoring, and maintenance. >> - It also eliminates the need to explain that: >> . customers are RFC6052 operators having their own NSPs (somewhat = confusing IMHO) >> . their translators work with two service-provider prefixes (not = needed). >>=20 >>=20 >> i couldn't catch your point. even now two prefices are not *needed*.=20= >=20 > If a CLAT uses the NAT64 prefix for upstream IPv4 addresses and a = CLAT-site prefix for downstream IPv4 addresses, it is my understanding = that it works with two RFC6052 prefixes. >=20 > so you mean a prefix for remote peer while another for local site, = right? if so, first, i think it is natural to have different prefices = for peers not belonging to the same network; The point is that, with a NAT44 in a CLAT node, there is no need for the = CLAT to be configured with a local-site RFC6052 prefix. > second, the NAT64 prefix is common in the deployment domain and does = not belong to a CLAT. The RFC6145 translator of the CLAT must be configured with it to = translate remote peer addresses. > if we have n CLATs, we need n+1 prefices rather than 2n. calling them = "a CLAT needs two prefices" is IMHO misleading. Unless 464XLAT authors or implementers are also interested in this = particular debate, end of this subject for me.=20 RD > - maoke >=20 >=20 >=20 > RD >=20 >=20 >=20 >> - maoke >>=20 >>=20 >>=20 >> RD >>=20 >>=20 >>=20 >>=20 >>=20 >=20 --Apple-Mail-70-481389962 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
    j


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

    Le 2012-04-24 =C3=A0 12:53, = Maoke a =C3=A9crit :

    Remi,

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

    Le 2012-04-24 =C3=A0 10:50, Lorenzo Colitti a =C3=A9crit :

    On Sat, Apr 21, 2012 at 17:50, R=C3=A9mi Despr=C3=A9= s <despres.remi@laposte.net> = wrote:
    Now, avoiding ND proxy = on two addresses REMAINS POSSIBLE.
    - It is sufficient that a CLAT interface ID be reserved by IETF/IANA (an = ID that no host may legitimately use).
    - This can be done, in compliance with RFC 5342, with a modified-EUI-64 = ID based on IANA's OUI.
    - Proposed ID value is 02-00-5E-10--00-00-00-00 (in the available range = of www.iana.org/assignments/ethernet-numbers for = this).

    What if the user manually specifies the interface ID = on a tethered device? Will DAD just fail?

    Good point.
    A host that is = manually configured (not typical but possible) might by mistake try to = use the 464XLAT reserved IID.
    Avoiding possible consequences = of such a mis-configuration is preferable.

    For this, a requirement can be added that a CLAT = node should, in its ND answers on its LAN side, refuse the = 464XLAT-reserved interface ID. 
    The difference with the = ND proxy on two legitimate host addresses, is then only that it is just = a security protection, normally no applicable.
    This difference is very minor, but using a well known = interface ID has other advantages:
    - It facilitates traffic = monitoring, and maintenance.
    - It also eliminates the need to = explain that:
     . customers are RFC6052 operators having their own = NSPs (somewhat confusing IMHO)
     . their translators = work with two service-provider prefixes (not = needed).


    i couldn't catch your point. even now two prefices are not = *needed*. 

    If a CLAT uses the = NAT64 prefix for upstream IPv4 addresses and  a CLAT-site = prefix for downstream IPv4 addresses, it is my understanding that it = works with two RFC6052 prefixes.

    so you mean a prefix for remote = peer while another for local site, right? if so, first, i think it is = natural to have different prefices for peers not belonging to the same = network;

    The point is that, = with a NAT44 in a CLAT node, there is no need for the CLAT to be = configured with a local-site RFC6052 prefix.

    second, the NAT64 prefix is common in the = deployment domain and does not belong to a CLAT. =

    The RFC6145 translator of = the CLAT must be configured with it to translate remote peer = addresses.

    if we have n = CLATs, we need n+1 prefices rather than 2n. calling them "a CLAT needs = two prefices" is IMHO misleading. =

    Unless 464XLAT authors or = implementers are also interested in this particular = debate, end of this subject for = me. 

    RD


    <= br>
    - maoke



    RD

    =


    - = maoke



    RD


    =





    = --Apple-Mail-70-481389962-- From arturo.servin@gmail.com Tue Apr 24 05:57:14 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAC0521F87AB for ; Tue, 24 Apr 2012 05:57:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYjF9Y7JMtI5 for ; Tue, 24 Apr 2012 05:57:14 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id EF4D021F8795 for ; Tue, 24 Apr 2012 05:57:13 -0700 (PDT) Received: by qaea16 with SMTP id a16so36581qae.10 for ; Tue, 24 Apr 2012 05:57:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=2xpjBzi7q5GKs7eJ7FWhUVONnKTPw0ATlWi4+accwMw=; b=0hXw/5/QczSvYlxcYzsQOYGNjYZ4Bks71ZW1zk60z0vsMCy6WFb55J+QqB3flBB323 CLVAWz/huVe5nF2k3r4cojhKgjln/tIvh2+RVuTQsGvsbnh1vLF5erucUs5q0iSPA6Pd fIiqKN1a5P8tAaYarubKlsy8TeKYwZSqbl3llk9qMoeiIYohqmXWWJ2THR6xOMv9DQuj dMGh3Q55+qwjxrf6ZVMs5/AURswL9hdSmgLH1qHeLnPELGLVDMsl57J0N/JbTM5CU3Gc sRaQdPG7ehJxf44Rab6j8QSoCdiJVvaszGMzHrxlMOnXbME68C6jhnsKma8jgO3qTegE 0eUA== Received: by 10.224.175.67 with SMTP id w3mr1971417qaz.82.1335272233268; Tue, 24 Apr 2012 05:57:13 -0700 (PDT) Received: from 85-7-200.lacnic.net.uy ([200.7.85.172]) by mx.google.com with ESMTPS id hv18sm5998950qab.19.2012.04.24.05.57.10 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 24 Apr 2012 05:57:12 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_E3115FC9-878B-484B-8F3E-E2C80397C552" From: Arturo Servin In-Reply-To: <54469FB9-D118-4157-B9D6-8F52F7F96002@cisco.com> Date: Tue, 24 Apr 2012 09:57:07 -0300 Message-Id: References: <54469FB9-D118-4157-B9D6-8F52F7F96002@cisco.com> To: Fred Baker X-Mailer: Apple Mail (2.1257) Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-ra-guard-implementation WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 12:57:15 -0000 --Apple-Mail=_E3115FC9-878B-484B-8F3E-E2C80397C552 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Support. .as On 22 Apr 2012, at 15:00, Fred Baker wrote: > This is to initiate a two week working group last call of = draft-ietf-v6ops-ra-guard-implementation. Please read it now. If you = find nits (spelling errors, minor suggested wording changes, etc), = comment to the authors; if you find greater issues, such as disagreeing = with a statement or finding additional issues that need to be addressed, = please post your comments to the list. >=20 > We are looking specifically for comments on the importance of the = document as well as its content. If you have read the document and = believe it to be of operational utility, that is also an important = comment to make. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_E3115FC9-878B-484B-8F3E-E2C80397C552 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii =     Support.

    .as

    On 22 = Apr 2012, at 15:00, Fred Baker wrote:

    This is = to initiate a two week working group last call of = draft-ietf-v6ops-ra-guard-implementation. Please read it now. If you = find nits (spelling errors, minor suggested wording changes, etc), = comment to the authors; if you find greater issues, such as disagreeing = with a statement or finding additional issues that need to be = addressed, please post your comments to the list.

    We are = looking specifically for comments on the importance of the document as = well as its content. If you have read the document and believe it to be = of operational utility, that is also an important comment to = make.
    =
    _______________________________________________
    v6ops = mailing list
    v6ops@ietf.org
    https://www.ietf.org/= mailman/listinfo/v6ops

    = --Apple-Mail=_E3115FC9-878B-484B-8F3E-E2C80397C552-- From shemant@cisco.com Tue Apr 24 06:31:28 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 519E021F87AA for ; Tue, 24 Apr 2012 06:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.523 X-Spam-Level: X-Spam-Status: No, score=-10.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kFQMGp5qIxE7 for ; Tue, 24 Apr 2012 06:31:26 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 5E6FC21F84EC for ; Tue, 24 Apr 2012 06:31:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=9067; q=dns/txt; s=iport; t=1335274286; x=1336483886; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=Lrv234Vnwp0PGS4aZuCp1KtDcBGLBnEwmnS8Xm7WALE=; b=Pxn0U5BhiNy3TwMxqFpW0/3NQezBUp/V7G03E97luS8dP62gxXcHHRkR iEEhWpnP56QAxfNa2Lmy+ZT8PtclZGnFqYF+W4yUJ771YrW203McKswYX qLDXPNBiz0CmBon+jJHHXjMqrsUyUijWO1pGpSPM7N309ZplG3MSt5Ums g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAM+plk+tJV2Y/2dsb2JhbABEgkavMYEHggkBAQEEEgEJEQNJDAQCAQgRBAEBCwYXAQYBRQgBCAEBBAESCBqHbZpPoFiQbmMEiGObbIFpgwc X-IronPort-AV: E=Sophos;i="4.75,473,1330905600"; d="scan'208,217";a="77355905" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP; 24 Apr 2012 13:31:25 +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 q3ODVP4x031427; Tue, 24 Apr 2012 13:31:25 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, 24 Apr 2012 08:31:25 -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_01CD221E.8B6ACADE" Date: Tue, 24 Apr 2012 08:31:23 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C30483747A@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C304837272@XMB-RCD-109.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] FW: 6rd sunsetting requirements for 6204-bis Thread-Index: Ac0hhjsQ4vR3w6CWQTilKttqXXTLgAAAEx3AACWI3nA= References: <5B6B2B64C9FE2A489045EEEADDAFF2C30483722C@XMB-RCD-109.cisco.com><4F95A3D9.1010100@viagenie.ca><5B6B2B64C9FE2A489045EEEADDAFF2C304837261@XMB-RCD-109.cisco.com><4F95ABA0.8090601@viagenie.ca> <5B6B2B64C9FE2A489045EEEADDAFF2C304837272@XMB-RCD-109.cisco.com> From: "Hemant Singh (shemant)" To: "Hemant Singh (shemant)" , "Simon Perreault" X-OriginalArrivalTime: 24 Apr 2012 13:31:25.0299 (UTC) FILETIME=[8BC61430:01CD221E] Cc: v6ops@ietf.org Subject: Re: [v6ops] FW: 6rd sunsetting requirements for 6204-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 13:31:28 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD221E.8B6ACADE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable V6ops Chairs, =20 I'd like to defer to you on this one. We have been down this road during the past two months where the draft-townsley-troan-ipv6-ce-transitioning-02 is trying to add requirements to rfc6204bis but the draft-townsley-troan-ipv6-ce-transitioning-02 is clearly not completed work. The draft-townsley-troan-ipv6-ce-transitioning-02 seems to be boiling the ocean and is not going to be an RFC even in one year. So could we stop the 6rd thrashing and just ship rfc6204bis with basic 6rd requirements? Further, we are also going in circles. 6rd folks gave Chris some text to add to rfc6304bis at Paris but when Chris adds the text to rfc6204bis we are thrashing with that text too. I don't think any advanced 6rd requirement has gestated for text in the past two months. =20 =20 My humble recommendation is to ship rfc6204bis right now. I am happy to back out the Paris text added for 6rd in the -08 version. =20 Hemant =20 From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Hemant Singh (shemant) Sent: Monday, April 23, 2012 3:31 PM To: Simon Perreault Cc: v6ops@ietf.org Subject: Re: [v6ops] FW: 6rd sunsetting requirements for 6204-bis =20 =20 =20 -----Original Message----- From: Simon Perreault [mailto:simon.perreault@viagenie.ca]=20 Sent: Monday, April 23, 2012 3:21 PM To: Hemant Singh (shemant) Cc: v6ops@ietf.org Subject: Re: FW: [v6ops] 6rd sunsetting requirements for 6204-bis =20 >But Mark's argument is, if I understand correctly, that not supporting=20 >native alongside 6rd *harms the Internet* because it prevents graceful=20 >transitioning from 6rd to native. That argument is specific to 6rd, not >generic to all tunnel interfaces. =20 Fine for an argument. But again, the CPE router is consumer device that needs a specification for automata related to concurrent operation of native IPv6 and 6rd including specifying the transition from native IPv6 6rd or vice versa. Such a specification does not exist in RFC form. Rfc6204bis only accepts technology in RFC form or in rare exceptions, technology where the draft is in the IESG. =20 =20 Hemant=20 ------_=_NextPart_001_01CD221E.8B6ACADE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    V6ops Chairs,

     

    I’d like to defer = to you on this one.  We have been down this road during the past = two months where the draft-townsley-troan-ipv6-ce-transitioning-02 is = trying to add requirements to rfc6204bis but the = draft-townsley-troan-ipv6-ce-transitioning-02 is clearly not completed = work.    The = draft-townsley-troan-ipv6-ce-transitioning-02 seems to be boiling the = ocean and is not going to be an RFC even in one year.   So = could we stop the 6rd thrashing and just ship rfc6204bis with basic 6rd = requirements?  Further, we are also going in circles.  6rd = folks gave Chris some text to add to rfc6304bis at Paris but when Chris = adds the text to rfc6204bis we are thrashing with that text = too.    I don’t think any advanced 6rd requirement = has gestated for text in the past two months. =    

     

    My humble recommendation = is to ship rfc6204bis right now.  I am happy to back out the Paris = text added for 6rd in the -08 version.

     

    Hemant

     

    From:= = v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of = Hemant Singh (shemant)
    Sent: Monday, April 23, 2012 3:31 = PM
    To: Simon Perreault
    Cc: = v6ops@ietf.org
    Subject: Re: [v6ops] FW: 6rd sunsetting = requirements for 6204-bis

     

     

     

    -----Original Message-----
    From: Simon Perreault = [mailto:simon.perreault@viagenie.ca]
    Sent: Monday, April 23, 2012 = 3:21 PM
    To: Hemant Singh (shemant)
    Cc: v6ops@ietf.org
    Subject: = Re: FW: [v6ops] 6rd sunsetting requirements for = 6204-bis

     

    >But = Mark's argument is, if I understand correctly, that not supporting =

    >native alongside 6rd *harms the = Internet* because it prevents graceful

    >transitioning from 6rd to native. That argument is specific to = 6rd, not

    >generic to all tunnel = interfaces.

     

    Fine for an = argument.  But again, the CPE router is consumer device that needs = a specification for automata related to concurrent operation of native = IPv6 and 6rd including specifying the transition from native IPv6 6rd or = vice versa.  Such a specification does not exist in RFC form. =  Rfc6204bis only accepts technology in RFC form or in rare = exceptions, technology where the draft is in the IESG. =  

     

    Hemant

    ------_=_NextPart_001_01CD221E.8B6ACADE-- From fibrib@gmail.com Tue Apr 24 08:29:52 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C865821F87C1 for ; Tue, 24 Apr 2012 08:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.891 X-Spam-Level: X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[AWL=-1.043, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e+xbuGU6b4FT for ; Tue, 24 Apr 2012 08:29:49 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id A49E121F879A for ; Tue, 24 Apr 2012 08:29:49 -0700 (PDT) Received: by qaea16 with SMTP id a16so170431qae.10 for ; Tue, 24 Apr 2012 08:29:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1eGtoX4qNB5CQ2WBGrCc6PfzoJ8dpT3rK2fBOz21PG8=; b=bNBczcB1e0qVfXDBxBsjhHIL/LD5+sfOxnIivJTEF1ncx+etyX6J/ReGeABxOeLe99 +HyM50zUqg99Oq4T2UthxoRzS125y3O+ALZe8zu41k8CHemyKmKZ3cU14kezv585bxUD KY1ohSb7Np8hIkBcGSdvvFoH9nKRPM0Hea+HJO3lPGQEomqDfVomMG6WgzUpMfUmWy6d e2PsBvvYqRz2OCCaroCNK1hwrjyig47xSsEVvgXMnujyIHBqd+ek1dgRew1Q5Cj/Kt09 MLX7jzNqPNisJOmY2sBmh1S6N/MDqxHQo2tGSxAicUIf2x0sJV5QASekpaXlupVTkzRG U2lQ== MIME-Version: 1.0 Received: by 10.224.187.210 with SMTP id cx18mr2576585qab.45.1335281389179; Tue, 24 Apr 2012 08:29:49 -0700 (PDT) Received: by 10.229.123.197 with HTTP; Tue, 24 Apr 2012 08:29:48 -0700 (PDT) In-Reply-To: <00203A61-8588-4B55-A6FD-406031ACDF27@laposte.net> References: <20120417065542.31115.95082.idtracker@ietfa.amsl.com> <20120417160010kawashimam@mail.jp.nec.com> <56E2AD61-1C91-4889-914A-353793FCBE43@laposte.net> <20120419121044.17531mk1mv19abr4@mail.drown.org> <0646611B-5594-40EA-A2C4-F99CBA734024@laposte.net> <20120419181813.4524701l3gkq5zks@mail.drown.org> <45ABAD31-C265-4D63-82E2-3DE6F59B80C0@laposte.net> <20120420104246.1432746csfcrdqo8@mail.drown.org> <20120420122715.1702279xh7eynpus@mail.drown.org> <20120420175036.70482p5axgf81lq8@mail.drown.org> <2950A57B-DA87-4641-8540-8972F5C437CF@laposte.net> <6B2D2593-EE73-458D-BF42-F6507CF42646@laposte.net> <5423D1CD-1E7D-4E4F-9FBB-E367D6954F68@laposte.net> <00203A61-8588-4B55-A6FD-406031ACDF27@laposte.net> Date: Wed, 25 Apr 2012 00:29:48 +0900 Message-ID: From: Maoke To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=485b397dd4bbe0943104be6e6cee Cc: v6ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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, 24 Apr 2012 15:29:52 -0000 --485b397dd4bbe0943104be6e6cee Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable =D4=DA 2012=C4=EA4=D4=C224=C8=D5=D0=C7=C6=DA=B6=FE=A3=ACR=A8=A6mi Despr=A8= =A6s =D0=B4=B5=C0=A3=BA > > Le 2012-04-24 =A8=A4 14:24, Maoke a =A8=A6crit : > > > > =D4=DA 2012=C4=EA4=D4=C224=C8=D5=D0=C7=C6=DA=B6=FE=A3=ACR=A8=A6mi Despr= =A8=A6s =D0=B4=B5=C0=A3=BA > >> >> Le 2012-04-24 =A8=A4 12:53, Maoke a =A8=A6crit : >> >> Remi, >> >> =D4=DA 2012=C4=EA4=D4=C224=C8=D5=D0=C7=C6=DA=B6=FE=A3=ACR=A8=A6mi Despr= =A8=A6s =D0=B4=B5=C0=A3=BA >> >>> >>> Le 2012-04-24 =A8=A4 10:50, Lorenzo Colitti a =A8=A6crit : >>> >>> On Sat, Apr 21, 2012 at 17:50, R=A8=A6mi Despr=A8=A6s wrote: >>> >>>> Now, avoiding ND proxy on two addresses REMAINS POSSIBLE. >>>> - It is sufficient that a CLAT interface ID be reserved by IETF/IANA >>>> (an ID that no host may legitimately use). >>>> - This can be done, in compliance with RFC 5342, with a modified-EUI-6= 4 >>>> ID based on IANA's OUI. >>>> - Proposed ID value is 02-00-5E-10--00-00-00-00 (in the available rang= e >>>> of www.iana.org/assignments/ethernet-numbers for this). >>>> >>> >>> What if the user manually specifies the interface ID on a tethered >>> device? Will DAD just fail? >>> >>> >>> Good point. >>> A host that is manually configured (not typical but possible) might by >>> mistake try to use the 464XLAT reserved IID. >>> Avoiding possible consequences of such a mis-configuration is preferabl= e. >>> >>> For this, a requirement can be added that a CLAT node should, in its ND >>> answers on its LAN side, refuse the 464XLAT-reserved interface ID. >>> The difference with the ND proxy on two legitimate host addresses, is >>> then only that it is just a security protection, normally no applicable= . >>> This difference is very minor, but using a well known interface ID has >>> other advantages: >>> - It facilitates traffic monitoring, and maintenance. >>> - It also eliminates the need to explain that: >>> . customers are RFC6052 operators having their own NSPs (somewhat >>> confusing IMHO) >>> . their translators work with two service-provider prefixes (not >>> needed). >>> >>> >> i couldn't catch your point. even now two prefices are not *needed*. >> >> >> If a CLAT uses the NAT64 prefix for upstream IPv4 addresses and a >> CLAT-site prefix for downstream IPv4 addresses, it is my understanding t= hat >> it works with two RFC6052 prefixes. >> > > so you mean a prefix for remote peer while another for local site, right? > if so, first, i think it is natural to have different prefices for peers > not belonging to the same network; > > > The point is that, with a NAT44 in a CLAT node, there is no need for the > CLAT to be configured with a local-site RFC6052 prefix. > > second, the NAT64 prefix is common in the deployment domain and does not > belong to a CLAT. > > > The RFC6145 translator of the CLAT must be configured with it to translat= e > remote peer addresses. > > if we have n CLATs, we need n+1 prefices rather than 2n. calling them "a > CLAT needs two prefices" is IMHO misleading. > > > Unless 464XLAT authors or implementers are also interested in this > particular debate, end of this subject for me. > thanks for replying the points. sorry if my comment made an impression of "debate" but i only wanted to confirm if there are really different pairs of prefices that you mean. you confirmation is enough. end for me. - maoke --485b397dd4bbe0943104be6e6cee Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable

    =D4=DA 2012=C4=EA4=D4=C224=C8=D5=D0=C7=C6=DA=B6=FE=A3=ACR=A8= =A6mi Despr=A8=A6s =D0=B4=B5=C0=A3=BA

    Le 2012-04-24 =A8=A4 14:24,= Maoke a =A8=A6crit :



    =D4=DA 2012=C4=EA4=D4=C224=C8=D5= =D0=C7=C6=DA=B6=FE=A3=ACR=A8=A6mi Despr=A8=A6s =D0=B4=B5=C0=A3=BA

    Le 2012-04-24 =A8=A4 12:53, Maoke a =A8=A6crit :

    Remi,

    =D4=DA 2012=C4=EA4=D4=C224=C8=D5= =D0=C7=C6=DA=B6=FE=A3=ACR=A8=A6mi Despr=A8=A6s =D0=B4=B5=C0=A3=BA

    Le 2012-04-24 =A8=A4 10:50, Lorenzo Colitti a =A8=A6crit :

    On Sat, Apr 21, 2012 at 17:50, R=A8=A6mi Despr=A8=A6s <despres.remi@laposte.net> wrote:
    Now, avoiding ND proxy on two addresses REMA= INS POSSIBLE.
    - It is sufficient that a CLAT interface ID be reserved by IETF/IANA (an ID= that no host may legitimately use).
    - This can be done, in compliance with RFC 5342, with a modified-EUI-64 ID = based on IANA's OUI.
    - Proposed ID value is 02-00-5E-10--00-00-00-00 (in the available range of = www.iana.org/assignments/ethernet-numbers for this).

    What if the user manually specifies the interface ID on= a tethered device? Will DAD just fail?

    Good point.
    A host that is manually c= onfigured (not typical but possible) might by mistake try to use the 464XLA= T reserved IID.
    Avoiding possible consequences of such a mis-conf= iguration is preferable.

    For this, a requirement can be added that a CLAT node s= hould, in its ND answers on its LAN side, refuse the 464XLAT-reserved inter= face ID. 
    The difference with the ND proxy on two legitimate= host addresses, is then only that it is just a security protection, normal= ly no applicable.
    This difference is very minor, but using a well known interface I= D has other advantages:
    - It facilitates traffic monitoring, and = maintenance.
    - It also eliminates the need to explain that:
     . customers are RFC6052 operators having their own NSPs&nbs= p;(somewhat confusing IMHO)
     . their translators work with t= wo service-provider prefixes (not needed).


    i couldn't catch your point. even now two prefices are not *needed= *. 

    If a CLAT uses the NAT64 prefix f= or upstream IPv4 addresses and  a CLAT-site prefix for downstream= IPv4 addresses, it is my understanding that it works with two RFC6052 pref= ixes.

    so you mean a prefix for remote peer= while another for local site, right? if so, first, i think it is natural t= o have different prefices for peers not belonging to the same network;

    The point is that, with a NAT44 in a= CLAT node, there is no need for the CLAT to be configured with a loca= l-site RFC6052 prefix.

    second,= the NAT64 prefix is common in the deployment domain and does not belong to= a CLAT.

    The RFC6145 translator of the CLAT m= ust be configured with it to translate remote peer addresses.

    if we have n CLATs, we need n+1 prefices ra= ther than 2n. calling them "a CLAT needs two prefices" is IMHO mi= sleading.

    Unless 464XLAT authors or implemente= rs are also interested in this particular debate, end of this sub= ject for me. 


    &n= bsp;thanks for replying the points. sorry if my comment made an impression = of "debate" but i only wanted to confirm if there are really diff= erent pairs of prefices that you mean. you confirmation is enough. end for = me. - maoke
    --485b397dd4bbe0943104be6e6cee-- From dan-v6ops@drown.org Tue Apr 24 09:19:00 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39E2A21F87D8 for ; Tue, 24 Apr 2012 09:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TFtyfsf9HUp5 for ; Tue, 24 Apr 2012 09:18:59 -0700 (PDT) Received: from vps3.drown.org (vps3.drown.org [IPv6:2600:3c00::f03c:91ff:fedf:5654]) by ietfa.amsl.com (Postfix) with ESMTP id CCF9621F87C7 for ; Tue, 24 Apr 2012 09:18:59 -0700 (PDT) Received: by vps3.drown.org (Postfix, from userid 48) id 3C706C136; Tue, 24 Apr 2012 12:18:59 -0400 (EDT) Received: from 2001:470:b88f:c8f6:224:1dff:fe16:eb3b ([2001:470:b88f:c8f6:224:1dff:fe16:eb3b]) by mail.drown.org (Horde Framework) with HTTP; Tue, 24 Apr 2012 11:18:59 -0500 Message-ID: <20120424111859.199819d07k06j140@mail.drown.org> Date: Tue, 24 Apr 2012 11:18:59 -0500 From: Dan Drown To: GangChen , v6ops WG References: <20120417065542.31115.95082.idtracker@ietfa.amsl.com> <20120417160010kawashimam@mail.jp.nec.com> <56E2AD61-1C91-4889-914A-353793FCBE43@laposte.net> <20120419121044.17531mk1mv19abr4@mail.drown.org> <0646611B-5594-40EA-A2C4-F99CBA734024@laposte.net> <20120419181813.4524701l3gkq5zks@mail.drown.org> <45ABAD31-C265-4D63-82E2-3DE6F59B80C0@laposte.net> <20120420104246.1432746csfcrdqo8@mail.drown.org> <20120423105716.130762z7e8air84c@mail.drown.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.9) Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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, 24 Apr 2012 16:19:00 -0000 Quoting GangChen : > Assuming IPv6 apps on the CLAT would talk to severs either on cell > network side or wifi tethering network side > I guess CLAT should bind apps to different interface (i.e PPP int or > eth int) according to the route to the destination. > Eg: > PPP_int: 2607:fb90:800:68c::eae6:901 > eth_int: 2607:fb90:800:68c::eae6:901 > > In the case, > CLAT set default gateway pointing to 3GPP interface(i.e. PPP_int) > Des: eth_int 2607:fb90:800:68c::eae6:902 > > Select: eth_int: 2607:fb90:800:68c::eae6:901 The only thing I would change in your explanation is: this is the generic process that happens to all Linux machines with multiple ipv6 interfaces, it is not something specific to or changed in CLAT or 464XLAT. From acassen@corp.free.fr Tue Apr 24 12:13:46 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B47421E80B3 for ; Tue, 24 Apr 2012 12:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.267 X-Spam-Level: ** X-Spam-Status: No, score=2.267 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, J_CHICKENPOX_12=0.6, J_CHICKENPOX_13=0.6, J_CHICKENPOX_21=0.6, J_CHICKENPOX_31=0.6, J_CHICKENPOX_51=0.6, RDNS_NONE=0.1, 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 GHVhobDPcn8R for ; Tue, 24 Apr 2012 12:13:45 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [IPv6:2a01:e0c:1:1599::14]) by ietfa.amsl.com (Postfix) with ESMTP id AF40F21E809A for ; Tue, 24 Apr 2012 12:13:42 -0700 (PDT) Received: from lnxos-dev (unknown [213.228.1.188]) by smtp5-g21.free.fr (Postfix) with ESMTP id 94E86D48175; Tue, 24 Apr 2012 21:13:33 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by lnxos-dev (Postfix) with ESMTPS id 49B269C0010; Tue, 24 Apr 2012 21:10:12 +0200 (CEST) Date: Tue, 24 Apr 2012 21:10:10 +0200 (CEST) From: Alexandre Cassen X-X-Sender: acassen@lnxos-dev To: Wuyts Carl In-Reply-To: Message-ID: References: <867F4B6A1672E541A94676D556793ACD108F21A6B7@MOPESMBX01.eu.thmulti.com> <72C114C8-6B88-4F06-BC80-0AB4F052C112@townsley.net> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-2035105331-1335294612=:6228" Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Fwd: 6rd sunsetting requirements for 6204-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 19:13:46 -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. --8323329-2035105331-1335294612=:6228 Content-Type: TEXT/PLAIN; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8BIT Hi, I can give you our perspective if usefull. While we are not planning to turn off 6rd tomorow, we have been looking at how to do so. That is the reason why we are supporting this work. regs, Alexandre > From: Wuyts Carl > Subject: RE: [v6ops] 6rd sunsetting requirements for 6204-bis > Date: April 24, 2012 11:23:39 AM GMT+02:00 > To: Mark Townsley > Cc: Chris Donley , "v6ops@ietf.org" > > @ Mark. >   > 1.        Indeed we are deploying managed CPEs, so have a bit more flexibility in controlling the config vs retail.  Indeed, not all CPEs are TR-069 capable, but most > of our customers do deploy it (quite typical for managed CPE). > 2.       6rd and DSlite or indeed far from equal, I know.  What I meant is that the same principal applies, i.e. one is not rolling it out today, to decide tomorrow to > go fully native all of a sudden.  Investments are being made, either 6rd or DSLite, or even both, which will not be thrown away the day after.   So the 6rd sunsetting > indeed is something to become useful in later stages, but no urgency to include them as reqs today. >    > 3.       6rd indeed exists for some time, you probably know a lot better than me J, but I?ve a pretty good view on what our customers are doing today with IPv6 in general > 9so also with 6rd), and can assure you they are not looking at any 6rd sunsetting today. >   > So, as Roberta also says in her latest reply.  Please draw a line.  You say before DSLite, maybe, maybe not, I?d say, looking at millions of CPEs in the field, the 6rd > sunsetting for sure are not needed today.  Wrt DSLite.  I don?t think we can avoid it (unfortunately), but also here applies that the CPE should be able to handle those > tunnels, but not yet to also include full PCP support or some other UPnP-kind of mechanism, it?s too early for that (looking at them being mainly all draft stuff).  Of > course CPE vendors should look into it today and judge upon its impact, but one cannot expect from the CPE vendor (you know, the very low cost device) to support all of > it in 1 go. >   > I can even go 1 step further: RFC6106 support.  For the record: we do support it, however, I see lack of support in the LAN for it, hence not very usable today.  OK for > CPE to have some basic support for it, but not ?all the way? for simple reason that lots of hosts are not ready + the fact that no clear view on what should happen in case > of both RA and DHCPv6 stateless, what is ?best?, what if different content, ?.  This one however is only limited present in RFC6204, which is fine I guess. >   > Best regards > Carl >   > From: Mark Townsley [mailto:mark@townsley.net]  > Sent: dinsdag 24 april 2012 9:34 > To: Wuyts Carl > Cc: Chris Donley; v6ops@ietf.org > Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis >   >   > On Apr 24, 2012, at 8:45 AM, Wuyts Carl wrote: > > >   > [Carl] Yes.  A CPE is a router, hence should be capable of making routing decisions, taking into account multiple paths, metrics, ?..  Load balancing for instance might > not be supported, so in case of multiple equal cost paths, it will take one of the available routes, but this is a known ?issue? at that moment.  Lots of things can be set > via TR-069 these days, so ISP can influence e.g. metrics when having native/tunneled combination and wanting to enforce a specific route. >   > We cannot assume all CPE have a TR-69 interface. > > > [Carl] Not at all.  Our CPE supports both 6rd, static as well as using the DHCP option 212.  But when looking today at our customers, there for sure not hitting a 6rd > move to native . >   > Not sure I understand that sentence. >   > But, let's just say I am looking at the largest  6rd deployments in the world, and working out how to migrate them to native. That's the basis behind the three > requirements, and the reason they are being introduced in 6204-bis is that this is the first document that considers both native IPv6 and 6rd at the same time.  >   > I gather your primary customer set is a managed CPE with TR-69. WIth this model, you can of course leave all this up to configuration, and customize everything for each > and every ISP in the world. Retail CPE are different, and the burden on the RFC greater, in order to achieve the level of consistency across the market that is needed > for the model to work at all. > > >   > All I am trying to do is make sure that *if* 6rd is in the document, it is done correctly so we don't paint ourselves into a corner.  > [Carl] Saw the picture, see what you mean, but again, should be tackled, however not today.  Allow some time. >   > 6rd has been deployed since 2007, how much longer do we need to get this right? >   >   > I was also trying to do the same with DS-Lite, but have decided to give up. DS-Lite has become an enormous distraction to the deployment of IPv6 service to > internet users, so I'm going to stop investing energy into trying to fix it here. Maybe v4-exit can do better in 6204-ter (sigh).  > [Carl] Same applies here as for 6rd.  > >   > No. 6rd and DS-Lite are not the same, and do not solve the same problems. They are night and day different, and every time we lump them together it causes confusion and > trouble. Please stop.  > > > To start off, we do support it, again static and dynamic through dhcp option 64, so no issue on that part.  But proper deployment most likely will require some extra?s on > the CPE, PCP, UPNP-IGD2, something else?.  Similar applies here: people starting today to look at it (in Residential CPE world), but for sure not (yet) targeting the move > to native-only, too soon (unfortunately). >   > The real scope creep is the inclusion of IPv4 delivery in an IPv6 CPE document to start with. If you want to draw a line, draw it before the inclusion of DS-Lite. Here > in v6ops, we need to get IPv6 Internet service off the ground, and that's already taking plenty of energy as it is.  > > >   > As I have said before, I am equally happy with the entire "Transition" section to be removed from 6204-bis. But, if we step off the cliff, we're going to get it right, > at least for 6rd. Otherwise, it does more harm than good. > [Carl] Don?t fully agree J.  I see 6rd being used in various ways at our customers today.  I must say it?s working rather smooth, using the features they have available > today, so I?d encourage to keep both 6rd and DSLite in the doc as is, but not start adding more requirements which are to be applied in later phases. >   > Yes, 6rd is working quite well, I cannot argue with you there.  >   > But, I also want my customers to be able to turn off 6rd, and for that to happen smoothly. Including the requirements for that in 6204-bis won't hurt that. As you have > said, its all just what a "real router" would do anyway. >   > - Mark > > > I?ve been present on the last 2 v6 world congresses in Paris and the general statements there were always ?the CPE is the problem?.  Well, guess what, it still is, and it > still will be if you don?t stop adding requirements.  > Please draw a line NOW, and take changes and added requirements into a later version so the CPE vendor has the time to cope with all of this!!!  I repeat my > statement from the panel: if we don?t stop adding requirements onto the (nearly free-of-charge) CPE, the next v6 congress will have again several > presentations claiming ?The CPE is the problem?. >   > Just on these specific ones: there is the claim that CPE devices are not ?ready? (whatever that may mean?).  Today, IPv6 roll-out is, unfortunately, still very (too) > limited, but already ?6rd sunsetting? requirements are being added to the basic CPE IPV6 reqs, why ?  I don?t doubt this issue will present itself, but for sure not > ?tomorrow?. > >   > That's why: >   > [IMAGE] >   > [Carl] I usually start from the other end @ home J >   > - Mark > > > >   > Regs > Carl >   > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Chris Donley > Sent: dinsdag 24 april 2012 1:04 > To: Mark Townsley; v6ops@ietf.org > Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis >   > Mark, >   > Please see in-line. >   > Chris >   > From: Mark Townsley > Date: Mon, 23 Apr 2012 11:27:36 -0600 > To: "v6ops@ietf.org" > Subject: [v6ops] 6rd sunsetting requirements for 6204-bis >   > 6RD-4: A CE router MUST allow 6rd virtual and IPv6 native WAN interfaces to be > active simultaneously in order to support coexistence of the two > technologies during an incremental migration period from 6rd to native > IPv6.  > 1. I think this is covered in 6rd-5 and 6rd-7.   > 2. I don't think this specific requirement was agreed to in Paris.  It's not on your slide 4 or Slide 15, bullet 1, which were the 'hum's I captured in my notes. > 3. +1 to Hemant's comment ? I don't think this is needed as a MUST. >   > 6RD-5: The CE router MUST associate delegated prefixes with the WAN > interface(s) they were learned from (e.g., DHCPv6-PD, 6rd, etc). Each > packet sent out a WAN interface MUST have a source address that > corresponds to a delegated prefix associated with the given WAN > interface, consistent with what is described in section 4.3 of BCP > 84 (RFC 3704). > 1. We've been advised by the WG in the past to only include a single normative statement per requirement. > 2. This is covered in the existing 6rd-4. >   > 6RD-6: The IPv6 CE router MUST allow different or identical delegated prefixes > on 6rd and native interfaces. A 6rd virtual interface MUST be assigned a  > higher routing cost than a native IPv6 interface. This is done so that native  > traffic will be preferred over 6rd in the event normal IP longest matching  > and BCP 84 rules would have otherwise allowed a packet to be equally sent  > via 6rd or native IPv6. > 1. I think this language (?MUST allow different or identical delegated prefixes?) is confusing for people not intimately familiar with your other CE transitioning draft.  > 2. If I read this correctly, you want to require two operational states ? one where 6rd and native IPv6 use the same prefix and a second where they use different > prefixes. That requirement is captured in 6rd-5. > 3. As I mentioned above, we have been advised to keep requirements to a single normative statement, so the part about the routing cost is in 6rd-6. > 4. I've heard from some CPE vendors that specifying routing "cost" may be too implementation specific ? I think it's more neutral to speak of preference ? e.g. prefer > native to 6rd. >   >   > > > > > --8323329-2035105331-1335294612=:6228-- From mark@townsley.net Tue Apr 24 12:28:49 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 466DA21E80BE for ; Tue, 24 Apr 2012 12:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 ERJ-q7hFvtD4 for ; Tue, 24 Apr 2012 12:28:48 -0700 (PDT) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id DD6AA21E8096 for ; Tue, 24 Apr 2012 12:28:47 -0700 (PDT) Received: by wgbds11 with SMTP id ds11so3783950wgb.1 for ; Tue, 24 Apr 2012 12:28:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:mime-version:content-type:subject:date:in-reply-to:to :references:message-id:x-mailer:x-gm-message-state; bh=17eTxv0+8Pm7hT2q5teQ5snpwvn4WSJYLOyi1jHWPZE=; b=LmydXotrBQFHVofCzTC5fATjlYhyLrM8j/Fm6yDBO3Yz9L+lqqveXQHZDqm+uEQaDH dzzmXUevHy5GeOwIqah6nSX2dMZZqWHaFQe6aPsOnMXKL7b3s0XyErU54FnM6mEaD9o/ n/vVJZuzZm5EMlrwhlvkVtx3BewTLHUxIxi3UdL1Jg7I014vyGVuVhjJrrVG4B3amLY+ 1Ev1gjUvmr5rwFbsoOhJC3rECkfeOs3fP+moPVxQXJCrGwbbW9xcKgaJAWpiuGsf4/4q tB/e40snyOjpDiQZBrwXufkd9uPSh9Tm9YvJjf/GOn4xU5xKqx/y4Tm3UbZL88UNOQyZ iLKQ== Received: by 10.216.133.19 with SMTP id p19mr9194183wei.118.1335295726607; Tue, 24 Apr 2012 12:28:46 -0700 (PDT) Received: from ams-townsley-8912.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id fz9sm31736187wib.3.2012.04.24.12.28.32 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 24 Apr 2012 12:28:37 -0700 (PDT) From: Mark Townsley Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_71DEDB87-5E8E-477B-834C-606BC315DE52" Date: Tue, 24 Apr 2012 21:28:31 +0200 In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C30483747A@XMB-RCD-109.cisco.com> To: v6ops@ietf.org References: <5B6B2B64C9FE2A489045EEEADDAFF2C30483722C@XMB-RCD-109.cisco.com><4F95A3D9.1010100@viagenie.ca><5B6B2B64C9FE2A489045EEEADDAFF2C304837261@XMB-RCD-109.cisco.com><4F95ABA0.8090601@viagenie.ca> <5B6B2B64C9FE2A489045EEEADDAFF2C304837272@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30483747A@XMB-RCD-109.cisco.com> Message-Id: X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQkP84jFUHk6azKe40Hw9DF4LSRWtx4BdiX/QNGpKKOoW0Gtw81nteN7tmBZ8rOSYeRgPfHQ Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 19:28:49 -0000 --Apple-Mail=_71DEDB87-5E8E-477B-834C-606BC315DE52 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Apr 24, 2012, at 3:31 PM, Hemant Singh (shemant) wrote: > V6ops Chairs, > =20 > I=92d like to defer to you on this one.=20 I think the chairs would expect that. For this case, the chairs already made their call. The reason we are = here is that you and Chris didn't follow what was asked by them. What was asked was to Include the three basic requirements based on my = presentation. I sent those to Chris one week after the IETF. He decided = to throw them in the trash, instead giving you a different set to = publish.=20 The best way to end this, is to just take the advice from the people who = have actually built and deployed 6rd for some time, and have planned out = the CPE requirements for how to transition to native and include that = text. Before you didn't have that text, because Chris threw it away. Now = you do.=20 - Mark > We have been down this road during the past two months where the = draft-townsley-troan-ipv6-ce-transitioning-02 is trying to add = requirements to rfc6204bis but the = draft-townsley-troan-ipv6-ce-transitioning-02 is clearly not completed = work. The draft-townsley-troan-ipv6-ce-transitioning-02 seems to be = boiling the ocean and is not going to be an RFC even in one year. So = could we stop the 6rd thrashing and just ship rfc6204bis with basic 6rd = requirements? Further, we are also going in circles. 6rd folks gave = Chris some text to add to rfc6304bis at Paris but when Chris adds the = text to rfc6204bis we are thrashing with that text too. I don=92t = think any advanced 6rd requirement has gestated for text in the past two = months. =20 > =20 > My humble recommendation is to ship rfc6204bis right now. I am happy = to back out the Paris text added for 6rd in the -08 version. > =20 > Hemant > =20 > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Hemant Singh (shemant) > Sent: Monday, April 23, 2012 3:31 PM > To: Simon Perreault > Cc: v6ops@ietf.org > Subject: Re: [v6ops] FW: 6rd sunsetting requirements for 6204-bis > =20 > =20 > =20 > -----Original Message----- > From: Simon Perreault [mailto:simon.perreault@viagenie.ca]=20 > Sent: Monday, April 23, 2012 3:21 PM > To: Hemant Singh (shemant) > Cc: v6ops@ietf.org > Subject: Re: FW: [v6ops] 6rd sunsetting requirements for 6204-bis > =20 > >But Mark's argument is, if I understand correctly, that not = supporting > >native alongside 6rd *harms the Internet* because it prevents = graceful > >transitioning from 6rd to native. That argument is specific to 6rd, = not > >generic to all tunnel interfaces. > =20 > Fine for an argument. But again, the CPE router is consumer device = that needs a specification for automata related to concurrent operation = of native IPv6 and 6rd including specifying the transition from native = IPv6 6rd or vice versa. Such a specification does not exist in RFC = form. Rfc6204bis only accepts technology in RFC form or in rare = exceptions, technology where the draft is in the IESG. =20 > =20 > Hemant > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_71DEDB87-5E8E-477B-834C-606BC315DE52 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252



    = --Apple-Mail=_152DF509-04AB-4DE4-A295-A78FFD26EAEE-- From despres.remi@laposte.net Wed Apr 25 13:14:49 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6F7021F891A for ; Wed, 25 Apr 2012 13:14:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.404 X-Spam-Level: X-Spam-Status: No, score=-1.404 tagged_above=-999 required=5 tests=[AWL=-0.590, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, 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 QkKPbpziNgEB for ; Wed, 25 Apr 2012 13:14:48 -0700 (PDT) Received: from smtpout.laposte.net (smtpout4.laposte.net [193.253.67.229]) by ietfa.amsl.com (Postfix) with ESMTP id 68D1E21F8919 for ; Wed, 25 Apr 2012 13:14:46 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8508-out with ME id 2LEj1j00237Y3f403LEjyQ; Wed, 25 Apr 2012 22:14:45 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-78-595397685 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 25 Apr 2012 22:14:43 +0200 Message-Id: <4CD2AA5D-E6DA-409E-AB78-0F92867BE2E2@laposte.net> References: <5B6B2B64C9FE2A489045EEEADDAFF2C30483722C@XMB-RCD-109.cisco.com><4F95A3D9.1010100@viagenie.ca><5B6B2B64C9FE2A489045EEEADDAFF2C304837261@XMB-RCD-109.cisco.com><4F95ABA0.8090601@viagenie.ca><5B6B2B64C9FE2A489045EEEADDAFF2C304837272@XMB-RCD-109.cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C30483747A@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3048378BB@XMB-RCD-109.cisco.com> <42D0E71D-8599-44C6-91D4-B059A276EB6A@cisco.com> <379ECFD4-C696-4B86-9DCA-75B0887C4370@townsley.net> <504FAF77-A618-4E89-86ED-727FD0FEF473@laposte.net> To: Mark Townsley X-Mailer: Apple Mail (2.1084) Cc: IPv6 Operations Subject: Re: [v6ops] 6rd (and 4rd) sunsetting requirements for 6204-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 20:14:49 -0000 --Apple-Mail-78-595397685 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Le 2012-04-25 =E0 20:17, Mark Townsley a =E9crit : >=20 > On Apr 25, 2012, at 7:09 PM, R=E9mi Despr=E9s wrote: >=20 >> Mark, >>=20 >> While it is important that 6204bis includes 6rd, and while it is also = important to specify a 6rd sunsetting plan (good that you took the = initiative), I don't think it is right to include 6RD-4 to 6RD-6 at this = stage. >>=20 >> Reasons: >> - Proof that no sunsetting solution is possible without these = requirements hasn't been given. >> - I even think that, in a node supporting both IPv6 via IPv4 (6rd) = and IPv4 via IPv6 with public IPv4 addresses (MAP or 4rd), the IPv4 and = IPv4 and IPv6 routers can each see only one interface. (The fact that it = uses link layer interfaces natively or with some tunneling can AFAIK be = kept invisible to the router.) >>=20 >> Until a complete solution is described, doubt remains, but freezing = now the idea that this would be impossible isn't needed. >=20 > Renaming the thread as this is taking a direction towards inclusion of = 4rd as well as 6rd. >=20 > Remi - we agree in that I absolutely do think that 6204-bis has = stepped in the wrong direction by recommending DS-Lite without = considering the stateless alternatives as well as how to handle = deployment alongside native IPv4 in a consistent and predictable manner. = I tried, and failed, to sway the WG here though. The idea of a note = saying that this is "still as of yet undefined" I think would be quite = appropriate in this space. I would definitely support that, but the WG = seems to not be open to much change at all right now. Regarding 6rd and = native IPv6, the solution space is far more straightforward in terms of = their coexistence as well as the fact that 6rd is clearly dominant in = terms of transition solution deployment today. It's a big win to go = ahead and get this defined now, and the idea that we don't understand it = well enough after nearly 5 years of deployed 6rd, would seem a rather = weak statement.=20 >=20 > Referring back to Fred's email, the chairs have decided to take the = three requirements that outline how 6rd and and native IPv6 can coexist = in a way that allows both to be deployed at the same time, while giving = proper preference to native vs. 6rd when the routing decision would = otherwise have found them equal. Let's please focus on whether or not = the requirements are worded properly for that case, > without inclusion of 4rd, MAP-T, MAP-E, MAP-U, Stateless DS-Lite, = SD-NAT, CGN, DS-Lite with Global IPv4 addresses, 464xlat, or any of the = other IPv4 delivery options. Full agreement to not include any of these. If, in my explanation above, there is a reference to tools that assign = public IPv4 addresses across IPv6-only networks, it is only because at = least one such tool is needed for an ISP to eliminate 6rd (and the = IPv4-only network that goes with it) without waiting for customers to no = longer need their IPv4 addresses.=20 Note that my proposal (*) below has purposely none of the acronyms that = neither of us want to include in 6204bis. As such, I hope it is acceptable.=20 > 6rd is quietly enjoying quite a bit of success here in terms of = getting users connected to the IPv6 internet, trying to couple it with = any or all of the v4-exit alternatives has clearly shown the ability to = be a considerable distraction. >=20 > - Mark >=20 >> Suggestion: keep 6RD-1 to 6RD-4, (*) >> replace the others by a note warning that a specification needs to be = added to handle 6RD sunsetting. Regards, RD >> =20 >>=20 >> Regards, >> RD >>=20 >>=20 >> =20 >>=20 >>=20 >> Le 2012-04-25 =E0 12:10, Mark Townsley a =E9crit : >>=20 >>>=20 >>> Whittled down to one sentence each, here are three requirements = necessary in order to support incremental migration from 6rd to native = IPv6:=20 >>>=20 >>>=20 >>> 6RD-4: A CE router MUST allow 6rd virtual and IPv6 native WAN = interfaces to be active simultaneously.=20 >>>=20 >>> 6RD-5: Each packet sent on a 6rd or native WAN interface MUST be = directed such that its source IP address is derived from the delegated = prefix associated with the upstream network the WAN interface is = connected to [section 4.3 of BCP 84, RFC 3704]. >>>=20 >>> 6RD-6: The CE router MUST allow identical or overlapping delegated = prefixes for each WAN interface with a preference for native IPv6 in the = event forwarding rules would have otherwise directed a packet to be sent = equally via 6rd or native IPv6. >>>=20 >>>=20 >>> Summary: The first requirement says 6rd and native must coexist, the = second ensures that packets are directed such that they are not dropped = by the upstream network, and the third ensures native is chosen over 6rd = in the event the paths are otherwise equal.=20 >>>=20 >>> - Mark >>>=20 >>>=20 >>> On Apr 25, 2012, at 5:23 AM, Fred Baker wrote: >>>=20 >>>>=20 >>>> On Apr 25, 2012, at 5:05 AM, Hemant Singh (shemant) wrote: >>>>=20 >>>>> Fred, >>>>> =20 >>>>> Appreciate the quick reply. In MarkT's comments to Chris that = Chris did not follow the Chairs' recommendation, the statement is not = quite correct. Additionally MarkT saying to the mailer that "He = (Chris) decided to throw them in the trash" is not correct either. See = the URL below where Chris clearly said, he has guidance from the IETF = and WG in the past to not include more than one normative statement per = requirement. Thus Chris broke up the MarkT recommendations and the = break up has to stay. Thus it would help if Mark revisits Chris=92 text = and fills in holes Mark thinks the text has because we just cannot go = back to Mark=92s original text that combines multiple normative = statements in one requirement. >>>>=20 >>>> I would like you to please work with Mark, on the mailer, to = accomplish that.=20 >>>>=20 >>>>> http://www.ietf.org/mail-archive/web/v6ops/current/msg12705.html >>>>> Moving on, the requirements provided by MarkT could use tighter = text. For example here is a portion of text provided to us to add. >>>>> =20 >>>>> "6RD-5: The CE router MUST associate delegated prefixes with the = WAN >>>>> interface(s)=94 >>>>> =20 >>>>> The CPE WAN interface can be unnumbered with only an IPv6 = link-local address and thus the CPE WAN does not have a global IPv6 = address. In such an unnumbered model, the CPE uses an address from the = PD on a virtual network interface to source packets out the WAN such as = ICMPv6 errors. I am away from work tomorrow but we can certainly try = and close any text two days from now including any WebEx phone call = between Mark and us authors of rfc6204bis.=20 >>>>=20 >>>> I suspect that you misunderstand Mark's text, which says that the = text he suggested was inadequate.=20 >>>>=20 >>>> RFC 3704, resolving a number of pages into a single sentence, = recommends that if a packet uses a stated source address and that source = address was derived from a stated upstream network, the packet should be = directed to said upstream network. The reason it would do so is that the = upstream networks presumably implement BCP 38, meaning that if it is = directed to a different upstream network it is likely to be dropped. = 3704 goes on to make suggestions regarding the implementation of exit = routing. What Mark is driving at is "implement exit routing; if one is = given multiple prefixes on different interfaces, physical or virtual, = associate each such prefix with its source interface in routing for the = purposes of source-address directed exit routing." >>>>=20 >>>> Explanations and dialog such as this are the reason I am asking you = to TALK WITH MARK about issues you see rather than talking with the = chairs or simply presuming that the working group outcome in Paris is = brain-dead. The outcome was, as near as I could tell, very sensible to = the operators. >>>>=20 >>>>> Another example for tighter text is related to 6RD-4. Why does = 6RD-4 only say =93during an incremental migration period from 6rd to = native IPv6.=94 The SP could encounter a problem moving from 6rd to = native IPv6 and may want to revert back to 6rd. Thus the 6RD-4 bullet = should cater to any migration from 6rd to native IPv6 or vice versa. >>>>> =20 >>>>> Further, when the CPE has different prefixes being used by native = IPV6 and 6rd, a host behind the CPE router has concurrent IPv6 addresses = being used (one IPv6 address from native IPv6 and another from the 6rd = prefix). So what source-address does the host pick to send a packet to = a destination that is totally disjoint with the two prefixes assigned to = the CPE router? Let=92s say the host picked a source address from the = 6rd prefix, then the CPE router ships the packet out the 6rd tunnel = instead of the higher preferred native IPv6 network. So how is the = native IPv6 preference enforced by the CPE router? =20 >>>>> =20 >>>>> We also do not have consensus with the =93MUST=94 in 6RD-4. = Current consensus is mostly towards changing the MUST to a SHOULD. I = also do not see any SP clamoring for 6rd sunsetting. One SP in France = or France that has roughly million 6rd customers does not impress me. I = am a person who gets impressed with 200 million customers which is = roughly what the cable broadband industry is deploying native IPv6 for. =20= >>>>> =20 >>>>> Hemant >>>>> =20 >>>>> =20 >>>>> -----Original Message----- >>>>> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On = Behalf Of Fred Baker (fred) >>>>> Sent: Tuesday, April 24, 2012 5:33 PM >>>>> To: IPv6 Operations >>>>> Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis >>>>> =20 >>>>> We discussed this at IETF 83, and you will find it in the minutes = when they come out. Mark and Ole asked for two things (statements = regarding 6rd and ds-lite), and the working group agreed to one of them. = We are not discussing a "boiling of the ocean", nor are we discussing an = infinite succession of new requirements. We are discussing getting three = no-brainer-class statements into the draft in a manner that the = discussants all recognize and agree to. The three statements were = clarified by hum in the meeting, and were each able to be stated in a = single sentence. >>>>> =20 >>>>> I would ask the different actors in this discussion to please = behave in a courteous manner toward each other, and work together on = this as requested by the chairs at IETF 83. >>>>> _______________________________________________ >>>>> 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 >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >=20 --Apple-Mail-78-595397685 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

    On Apr 25, = 2012, at 7:09 PM, R=E9mi Despr=E9s wrote:

    Mark,

    While = it is important that 6204bis includes 6rd, and while it is also = important to specify a 6rd sunsetting plan (good that you took the = initiative), I don't think it is right to include 6RD-4 to 6RD-6 at this = stage.

    Reasons:
    - Proof that no = sunsetting solution is possible without these requirements hasn't been = given.
    - I even think that, in a node supporting both IPv6 via = IPv4 (6rd) and IPv4 via IPv6 with public IPv4 addresses (MAP or 4rd), = the IPv4 and IPv4 and IPv6 routers can each see only one interface. (The = fact that it uses link layer interfaces natively or with some tunneling = can AFAIK be kept invisible to the = router.)

    Until a complete solution is = described, doubt remains, but freezing now the idea that this would be = impossible isn't needed.

    Renaming = the thread as this is taking a direction towards inclusion of 4rd as = well as 6rd.

    Remi - we agree in that I absolutely = do think that 6204-bis has stepped in the wrong direction by = recommending DS-Lite without considering the stateless alternatives as = well as how to handle deployment alongside native IPv4 in a consistent = and predictable manner. I tried, and failed, to sway the WG here though. = The idea of a note saying that this is "still as of yet undefined" I = think would be quite appropriate in this space. I would definitely = support that, but the WG seems to not be open to much change at all = right now. Regarding 6rd and native IPv6, the solution space is far more = straightforward in terms of their coexistence as well as the fact that = 6rd is clearly dominant in terms of transition solution deployment = today. It's a big win to go ahead and get this defined now, and the idea = that we don't understand it well enough after nearly 5 years of deployed = 6rd, would seem a rather weak = statement. 

    Referring back to Fred's = email, the chairs have decided to take the three requirements that = outline how 6rd and and native IPv6 can coexist in a way that allows = both to be deployed at the same time, while giving proper preference to = native vs. 6rd when the routing decision would otherwise have found them = equal. Let's please focus on whether or not the requirements are worded = properly for that case,

    without = inclusion of 4rd, MAP-T, MAP-E, MAP-U, Stateless DS-Lite, SD-NAT, CGN, = DS-Lite with Global IPv4 addresses, 464xlat, or any of the other IPv4 = delivery options.

    Full = agreement to not include any of these.

    If, in = my explanation above, there is a reference to tools that assign public = IPv4 addresses across IPv6-only networks, it is only  because at = least one such tool is needed for an ISP to eliminate 6rd (and the = IPv4-only network that goes with it) without waiting for customers to no = longer need their IPv4 addresses. 

    Note = that my proposal (*) below has purposely none of the acronyms that = neither of us want to include in 6204bis.
    As such, I hope it = is acceptable. 


    6rd is quietly = enjoying quite a bit of success here in terms of getting users connected = to the IPv6 internet, trying to couple it with any or all of the v4-exit = alternatives has clearly shown the ability to be a considerable = distraction.

    - = Mark

    Suggestion: keep = 6RD-1 to 6RD-4, =

    (*)

    Whittled = down to one sentence each, here are three requirements necessary in = order to support incremental migration from 6rd to = native IPv6: 


    6RD-4: A CE = router MUST allow 6rd virtual and IPv6 native WAN interfaces to = be active simultaneously. 

    6RD-5: Each packet = sent on a 6rd or native WAN interface MUST be directed such that = its source IP address is derived from the delegated prefix = associated with the upstream network the WAN interface is connected = to [section 4.3 of BCP 84, RFC = 3704].

    6RD-6: The CE router MUST allow identical or = overlapping delegated prefixes for each WAN interface with a = preference for native IPv6 in the event forwarding rules would have = otherwise directed a packet to be sent equally via 6rd or native = IPv6.


    Summary: The first = requirement says 6rd and native must coexist, the second ensures that = packets are directed such that they are not dropped by the upstream = network, and the third ensures native is chosen over 6rd in the event = the paths are otherwise equal. 

    - = Mark


    On Apr 25, 2012, at 5:23 AM, Fred = Baker wrote:


    On Apr 25, 2012, at 5:05 AM, Hemant = Singh (shemant) wrote:

    Fred,
     
    Appreciate the quick reply.  In MarkT's comments to Chris = that Chris did not follow the Chairs' recommendation, the statement is = not quite correct.  Additionally MarkT saying to the mailer = that  "He (Chris) decided to throw them in the trash" is not = correct either.  See the URL below where Chris clearly said, he has = guidance from the IETF and WG in the past to not include more than one = normative statement per requirement.  Thus Chris broke up the MarkT = recommendations and the break up has to stay.  Thus it would help if = Mark revisits Chris=92 text and fills in holes Mark thinks the text has = because we just cannot go back to Mark=92s original text that combines = multiple normative statements in one = requirement.

    I would like you to = please work with Mark, on the mailer, to accomplish = that. 

    <= div>

    I suspect that you = misunderstand Mark's text, which says that the text he suggested was = inadequate. 

    RFC 3704, resolving a = number of pages into a single sentence, recommends that if a packet uses = a stated source address and that source address was derived from a = stated upstream network, the packet should be directed to said upstream = network. The reason it would do so is that the upstream networks = presumably implement BCP 38, meaning that if it is directed to a = different upstream network it is likely to be dropped. 3704 goes on to = make suggestions regarding the implementation of exit routing. What Mark = is driving at is "implement exit routing; if one is given multiple = prefixes on different interfaces, physical or virtual, associate each = such prefix with its source interface in routing for the purposes of = source-address directed exit routing."

    Explanations and = dialog such as this are the reason I am asking you to TALK WITH MARK = about issues you see rather than talking with the chairs or simply = presuming that the working group outcome in Paris is brain-dead. The = outcome was, as near as I could tell, very sensible to the = operators.

    Another example for tighter text is related to 6RD-4.  = Why does 6RD-4 only say =93during an incremental migration period from 6rd to native = IPv6.=94    The SP could encounter a problem moving from 6rd to native IPv6 = and may want to revert back to 6rd.  Thus the 6RD-4 bullet should = cater to any migration from 6rd to native IPv6 or vice = versa.
     
    Further, when the CPE has different prefixes being used by = native IPV6 and 6rd, a host behind the CPE router has concurrent IPv6 = addresses being used (one IPv6 address from native IPv6 and another from = the 6rd prefix).  So what source-address does the host pick to send = a packet to a destination that is totally disjoint with the two prefixes = assigned to the CPE router?  Let=92s say the host picked a source = address from the 6rd prefix, then the CPE router ships the packet out = the 6rd tunnel instead of the higher preferred native IPv6 = network.  So how is the native IPv6 preference enforced by the CPE = router?  
     
    We also do not have consensus with the =93MUST=94 in = 6RD-4.  Current consensus is mostly towards changing the MUST to a = SHOULD.  I = also do not see any SP clamoring for 6rd sunsetting.  One SP in = France or France that has roughly million 6rd customers does not impress = me.  I am a person who gets impressed with 200 million customers = which is roughly what the cable broadband industry is deploying native = IPv6 for.  
     
    Hemant
     
     
    -----Original Message-----
    Sent: Tuesday, April 24, 2012 5:33 = PM
    Subject: Re: [v6ops] 6rd sunsetting requirements for = 6204-bis
     
    We discussed this at IETF 83, and you will find it in the = minutes when they come out. Mark and Ole asked for two things = (statements regarding 6rd and ds-lite), and the working group agreed to = one of them. We are not discussing a "boiling of the ocean", nor are we = discussing an infinite succession of new requirements. We are discussing = getting three no-brainer-class statements into the draft in a manner = that the discussants all recognize and agree to. The three statements = were clarified by hum in the meeting, and were each able to be stated in = a single sentence.
     
    I would ask the different actors in this discussion to please = behave in a courteous manner toward each other, and work together on = this as requested by the chairs at IETF 83.
    v6ops mailing = list

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



    = --Apple-Mail-78-595397685-- From shemant@cisco.com Wed Apr 25 18:16:21 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23C5F21F8797 for ; Wed, 25 Apr 2012 18:16:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[AWL=-0.338, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lc1tbB5bzTEi for ; Wed, 25 Apr 2012 18:16:17 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 498D821F8775 for ; Wed, 25 Apr 2012 18:16:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=16687; q=dns/txt; s=iport; t=1335402977; x=1336612577; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=HEnVOr8ZDYvDfOVCmm4Sx96LuWY/zG+NwTR6Rl1Kl2M=; b=Zm/V+eY7XzqqpUFPZc/S4fXziahVY3EK3aTik6K+Z4bJ7oSEBhGzV0gF +vV7aGvQuwi0zglXz4Ef73Zfn99S2lE+I69w+hK/EpTZy8WPqwjZjOcn9 +yyfAsixdFPrxdH9BOr1jl+Ij/Fz60PlyRwkaKtivK6OcYbHV0sLlyFla 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAGihmE+tJXG//2dsb2JhbABFgkavBYEHggkBAQEEEgEJEQNEBRACAQgRBAEBCwYXAQYBRQkIAQEEARIIEwMEh22bK6AYj31jBIgvNIktkkCBaYMHgT4 X-IronPort-AV: E=Sophos;i="4.75,484,1330905600"; d="scan'208,217";a="77924723" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-8.cisco.com with ESMTP; 26 Apr 2012 01:16:02 +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 q3Q1G2tB031068; Thu, 26 Apr 2012 01:16:02 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, 25 Apr 2012 20:16:02 -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_01CD234A.24F924F6" Date: Wed, 25 Apr 2012 20:16:01 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C304837D3A@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] 6rd (and 4rd) sunsetting requirements for 6204-bis Thread-Index: Ac0jD9qZthbqhSwHQxmB4nYwRqph1gANgFZQ References: <5B6B2B64C9FE2A489045EEEADDAFF2C30483722C@XMB-RCD-109.cisco.com><4F95A3D9.1010100@viagenie.ca><5B6B2B64C9FE2A489045EEEADDAFF2C304837261@XMB-RCD-109.cisco.com><4F95ABA0.8090601@viagenie.ca><5B6B2B64C9FE2A489045EEEADDAFF2C304837272@XMB-RCD-109.cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C30483747A@XMB-RCD-109.cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C3048378BB@XMB-RCD-109.cisco.com><42D0E71D-8599-44C6-91D4-B059A276EB6A@cisco.com><379ECFD4-C696-4B86-9DCA-75B0887C4370@townsley.net><504FAF77-A618-4E89-86ED-727FD0FEF473@laposte.net> From: "Hemant Singh (shemant)" To: "Mark Townsley" , =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-OriginalArrivalTime: 26 Apr 2012 01:16:02.0601 (UTC) FILETIME=[256C2990:01CD234A] Cc: IPv6 Operations Subject: Re: [v6ops] 6rd (and 4rd) sunsetting requirements for 6204-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 01:16:21 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD234A.24F924F6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Mark, =20 Sorry, it's hard to read the formatting of your emails to v6ops to = catch what you said vs. what any other person said. Could you please = do me a favor and use the "> bla bla" formatting to show the Remi = statements and then yours without any ">". This is a format you use is = some private emails I have received from you.=20 =20 Secondly, my humble apologies, but it's gets to be a non-starter, if = each time we discuss your 6rd requirements you bring up DS-Lite. Can = we leave DS-Lite out of the 6rd discussion. After all, DS-Lite is one = stateful protocol and the nature of a stateful protocol over a stateless = protocol is that stateful protocol incurs additionally complexity. = However, the benefits of a stateful protocol such as DS-Lite are clear = too. DS-Lite was an RFC when rfc6204bis was getting authored and = stateless 4rd or the slew of other protocols were not. Take this use = case that 6rd or any stateless protocol fails for that a stateful = protocol will not fail for. Victor raised something similar last time = 6rd sunsetting was discussed. =20 =20 A user is involved in a VoIP call from the user's PC behind a CPE router = using 6rd. Midway through the call, the other end of the phone call = switches to native IPv6. The phone call breaks down. How can an SP = really deploy VoIP phone service with such a stateless protocol? =20 =20 Thank you Remi for agreeing with me since I have been asking for over 24 = hours to this mailer as to how can requirements for 6rd sunsetting be = added to rfc6204bis when no RFC exists that specifies the technology for = how to sunset 6rd or reverting back to 6rd. I have been also catching = the fact that not only does one consider sunsetting 6rd but also = consider reverting the sunsetting. =20 Also, Remi, for the record, it was rfc6204bis which first wrote up the = 6rd sunsetting and revert procedure, including concurrent operation of = 6rd and native IPv6. However, some folks pointed out that our = procedure was specifying technology that a v6ops can't do. So our text = was taken out of rfc6204bis and actually incorporated into another = draft. =20 Hemant =20 =20 From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Mark Townsley Sent: Wednesday, April 25, 2012 2:17 PM To: R=E9mi Despr=E9s Cc: IPv6 Operations Subject: Re: [v6ops] 6rd (and 4rd) sunsetting requirements for 6204-bis =20 =20 On Apr 25, 2012, at 7:09 PM, R=E9mi Despr=E9s wrote: Mark, =20 While it is important that 6204bis includes 6rd, and while it is also = important to specify a 6rd sunsetting plan (good that you took the = initiative), I don't think it is right to include 6RD-4 to 6RD-6 at this = stage. =20 Reasons: - Proof that no sunsetting solution is possible without these = requirements hasn't been given. - I even think that, in a node supporting both IPv6 via IPv4 (6rd) and = IPv4 via IPv6 with public IPv4 addresses (MAP or 4rd), the IPv4 and IPv4 = and IPv6 routers can each see only one interface. (The fact that it uses = link layer interfaces natively or with some tunneling can AFAIK be kept = invisible to the router.) =20 Until a complete solution is described, doubt remains, but freezing now = the idea that this would be impossible isn't needed. =20 Renaming the thread as this is taking a direction towards inclusion of = 4rd as well as 6rd. =20 Remi - we agree in that I absolutely do think that 6204-bis has stepped = in the wrong direction by recommending DS-Lite without considering the = stateless alternatives as well as how to handle deployment alongside = native IPv4 in a consistent and predictable manner. I tried, and failed, = to sway the WG here though. The idea of a note saying that this is = "still as of yet undefined" I think would be quite appropriate in this = space. I would definitely support that, but the WG seems to not be open = to much change at all right now. Regarding 6rd and native IPv6, the = solution space is far more straightforward in terms of their coexistence = as well as the fact that 6rd is clearly dominant in terms of transition = solution deployment today. It's a big win to go ahead and get this = defined now, and the idea that we don't understand it well enough after = nearly 5 years of deployed 6rd, would seem a rather weak statement.=20 =20 Referring back to Fred's email, the chairs have decided to take the = three requirements that outline how 6rd and and native IPv6 can coexist = in a way that allows both to be deployed at the same time, while giving = proper preference to native vs. 6rd when the routing decision would = otherwise have found them equal. Let's please focus on whether or not = the requirements are worded properly for that case, without inclusion of = 4rd, MAP-T, MAP-E, MAP-U, Stateless DS-Lite, SD-NAT, CGN, DS-Lite with = Global IPv4 addresses, 464xlat, or any of the other IPv4 delivery = options. 6rd is quietly enjoying quite a bit of success here in terms of = getting users connected to the IPv6 internet, trying to couple it with = any or all of the v4-exit alternatives has clearly shown the ability to = be a considerable distraction. =20 - Mark =20 =20 ------_=_NextPart_001_01CD234A.24F924F6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

    Mark,

     

    Sorry, it’s hard to read the formatting of your emails to = v6ops=A0 to catch what you said vs. what any other person said.=A0=A0 = Could you please do me a favor and use the “> bla = bla” formatting to show the Remi statements and then yours without = any “>”.=A0=A0 This is a format you use is some private = emails I have received from you.

     

    Secondly, my humble apologies, but =A0it’s gets to be a = non-starter, if each time we discuss your 6rd requirements you bring up = DS-Lite.=A0 =A0Can we leave DS-Lite out of the 6rd = discussion.=A0=A0 After all, DS-Lite is one stateful protocol and = the nature of a stateful protocol over a stateless protocol is that = stateful protocol incurs additionally complexity.=A0=A0 However, the = benefits of a stateful protocol such as DS-Lite are clear too.=A0=A0=A0 = DS-Lite was an RFC when rfc6204bis was getting authored and stateless = 4rd or the slew of other protocols were not.=A0 =A0=A0Take this use = case that 6rd or any stateless protocol fails for that a stateful = protocol will not fail for. =A0Victor raised something similar last = time 6rd sunsetting was discussed.=A0=A0=A0

     

    A user is involved in a VoIP call from the user’s PC behind a = CPE router using 6rd.=A0=A0 Midway through the call, the other end of = the phone call switches to native IPv6.=A0=A0 The phone call breaks = down.=A0=A0=A0 How can an SP really deploy VoIP phone service with such = a stateless protocol?=A0

     

    Thank you Remi for agreeing with me since I have been asking for over = 24 hours to this mailer as to how can requirements for 6rd sunsetting be = added to rfc6204bis when no RFC exists that specifies the technology for = how to sunset 6rd or reverting back to 6rd.=A0=A0 I have been also = catching the fact that not only does one consider sunsetting 6rd but = also consider reverting the sunsetting.

     

    Also, Remi, for the record, =A0it was rfc6204bis which first = wrote up the 6rd sunsetting and revert procedure, including concurrent = operation of 6rd and native IPv6.=A0 =A0However,=A0 some folks pointed = out that our procedure was specifying technology that a v6ops = can’t do.=A0 So our text was taken out of rfc6204bis and actually = incorporated into another draft.

     

    Hemant

     

     

    From:= = v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of = Mark Townsley
    Sent: Wednesday, April 25, 2012 2:17 = PM
    To: R=E9mi Despr=E9s
    Cc: IPv6 = Operations
    Subject: Re: [v6ops] 6rd (and 4rd) sunsetting = requirements for 6204-bis

     

     

    On = Apr 25, 2012, at 7:09 PM, R=E9mi Despr=E9s wrote:



    Mark,

     

    While it is important that 6204bis includes 6rd, and = while it is also important to specify a 6rd sunsetting plan (good that = you took the initiative), I don't think it is right to include 6RD-4 to = 6RD-6 at this stage.

     

    Reasons:

    - Proof that no sunsetting solution is possible = without these requirements hasn't been = given.

    - I even think = that, in a node supporting both IPv6 via IPv4 (6rd) and IPv4 via IPv6 = with public IPv4 addresses (MAP or 4rd), the IPv4 and IPv4 and IPv6 = routers can each see only one interface. (The fact that it uses link = layer interfaces natively or with some tunneling can AFAIK be kept = invisible to the router.)

     

    Until a complete solution is described, doubt remains, = but freezing now the idea that this would be impossible isn't = needed.

     

    Renaming the thread as this is taking a direction = towards inclusion of 4rd as well as 6rd.

     

    Remi - we agree in that I absolutely do think that = 6204-bis has stepped in the wrong direction by recommending DS-Lite = without considering the stateless alternatives as well as how to handle = deployment alongside native IPv4 in a consistent and predictable manner. = I tried, and failed, to sway the WG here though. The idea of a note = saying that this is "still as of yet undefined" I think would = be quite appropriate in this space. I would definitely support that, but = the WG seems to not be open to much change at all right now. Regarding = 6rd and native IPv6, the solution space is far more straightforward in = terms of their coexistence as well as the fact that 6rd is clearly = dominant in terms of transition solution deployment today. It's a big = win to go ahead and get this defined now, and the idea that we don't = understand it well enough after nearly 5 years of deployed 6rd, would = seem a rather weak statement. 

     

    Referring back to Fred's email, the chairs have = decided to take the three requirements that outline how 6rd and and = native IPv6 can coexist in a way that allows both to be deployed at the = same time, while giving proper preference to native vs. 6rd when the = routing decision would otherwise have found them equal. Let's please = focus on whether or not the requirements are worded properly for that = case, without inclusion of 4rd, MAP-T, MAP-E, MAP-U, Stateless DS-Lite, = SD-NAT, CGN, DS-Lite with Global IPv4 addresses, 464xlat, or any of the = other IPv4 delivery options. 6rd is quietly enjoying quite a bit of = success here in terms of getting users connected to the IPv6 internet, = trying to couple it with any or all of the v4-exit alternatives has = clearly shown the ability to be a considerable = distraction.

     

    - = Mark

     



     

    ------_=_NextPart_001_01CD234A.24F924F6-- From fred@cisco.com Wed Apr 25 21:05:56 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBD4321F8680 for ; Wed, 25 Apr 2012 21:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.324 X-Spam-Level: X-Spam-Status: No, score=-110.324 tagged_above=-999 required=5 tests=[AWL=-0.325, 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 u6iBgir1cBta for ; Wed, 25 Apr 2012 21:05:56 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 7FA5421F8839 for ; Wed, 25 Apr 2012 21:05:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2131; q=dns/txt; s=iport; t=1335413139; x=1336622739; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=dY8eJL+hY/v1/KYA7aAg+uAidkGC66VkyyxIomhqyNY=; b=IcvNpGm/TMAKho9gUJs1nJ/gvE0OQ0AeSpGdnmvABdNZMbiT1+M8FEou 80QjEd/Waqye6wB9Kwyc4fX9qC/8ALM7R7OOGXA3dFNVy45qLmKbzJ9Bf 0vlIjhmZ4D5GmkcKZYwOJhOnolO0ItEfy4VjJhf7trIkh88ogcux+baBs k=; X-IronPort-AV: E=Sophos;i="4.75,484,1330905600"; d="scan'208";a="39636976" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 26 Apr 2012 04:05:39 +0000 Received: from stealth-10-32-244-221.cisco.com (stealth-10-32-244-221.cisco.com [10.32.244.221]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3Q45OZx005283; Thu, 26 Apr 2012 04:05:39 GMT Received: from [127.0.0.1] by stealth-10-32-244-221.cisco.com (PGP Universal service); Wed, 25 Apr 2012 21:05:39 -0700 X-PGP-Universal: processed; by stealth-10-32-244-221.cisco.com on Wed, 25 Apr 2012 21:05:39 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3048379F6@XMB-RCD-109.cisco.com> Date: Wed, 25 Apr 2012 21:05:31 -0700 Message-Id: <98F51669-A3E2-4AD1-90A3-A0D96FD8DCA5@cisco.com> References: <5B6B2B64C9FE2A489045EEEADDAFF2C30483722C@XMB-RCD-109.cisco.com><4F95A3D9.1010100@viagenie.ca><5B6B2B64C9FE2A489045EEEADDAFF2C304837261@XMB-RCD-109.cisco.com><4F95ABA0.8090601@viagenie.ca><5B6B2B64C9FE2A489045EEEADDAFF2C304837272@XMB-RCD-109.cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C30483747A@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3048378E6@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3048379F6@XMB-RCD-109.cisco.com> To: "Hemant Singh (shemant)" X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 04:05:56 -0000 On Apr 25, 2012, at 8:08 AM, Hemant Singh (shemant) wrote: > We are glossing over lot of unspecified technology with the MarkT 6rd > sunsetting reqs, but if the WG so deems, I'd be happy to put the MarkT > text into rfc6204bis and move rfc6204bis forward. That decision was made a few weeks ago, face to face, at IETF 83. > Hemant > > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Hemant Singh (shemant) > Sent: Wednesday, April 25, 2012 7:09 AM > To: Fred Baker (fred); IPv6 Operations > Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis > > One question. Which RFC specifies the technology for the procedure to > sunset 6rd to native IPv6 or vice versa between the SP and the CPE > router? > > Hemant > > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Fred Baker (fred) > Sent: Tuesday, April 24, 2012 5:33 PM > To: IPv6 Operations > Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis > > We discussed this at IETF 83, and you will find it in the minutes when > they come out. Mark and Ole asked for two things (statements regarding > 6rd and ds-lite), and the working group agreed to one of them. We are > not discussing a "boiling of the ocean", nor are we discussing an > infinite succession of new requirements. We are discussing getting three > no-brainer-class statements into the draft in a manner that the > discussants all recognize and agree to. The three statements were > clarified by hum in the meeting, and were each able to be stated in a > single sentence. > > I would ask the different actors in this discussion to please behave in > a courteous manner toward each other, and work together on this as > requested by the chairs at IETF 83. > _______________________________________________ > 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 Apr 25 23:37:12 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 204E821F88AF for ; Wed, 25 Apr 2012 23:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.697 X-Spam-Level: X-Spam-Status: No, score=-5.697 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 ozbi4e4L-E2n for ; Wed, 25 Apr 2012 23:37:05 -0700 (PDT) Received: from na3sys009aog110.obsmtp.com (na3sys009aog110.obsmtp.com [74.125.149.203]) by ietfa.amsl.com (Postfix) with ESMTP id C865921F88A4 for ; Wed, 25 Apr 2012 23:37:04 -0700 (PDT) Received: from mopesedge02.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob110.postini.com ([74.125.148.12]) with SMTP ID DSNKT5jtD5fwrDMRAbpLb1JKAJoOQCigvqfT@postini.com; Wed, 25 Apr 2012 23:37:04 PDT 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; Thu, 26 Apr 2012 07:50:50 +0200 Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.134]) by MOPESMAILHC01.eu.thmulti.com ([141.11.100.25]) with mapi; Thu, 26 Apr 2012 07:51:04 +0200 From: Wuyts Carl To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= , Mark Townsley Date: Thu, 26 Apr 2012 07:51:03 +0200 Thread-Topic: [v6ops] 6rd sunsetting requirements for 6204-bis Thread-Index: Ac0jBj0DFPP/fy44SH2J+/RXgTdTAQAaeURg Message-ID: <867F4B6A1672E541A94676D556793ACD108F21AD38@MOPESMBX01.eu.thmulti.com> References: <5B6B2B64C9FE2A489045EEEADDAFF2C30483722C@XMB-RCD-109.cisco.com><4F95A3D9.1010100@viagenie.ca><5B6B2B64C9FE2A489045EEEADDAFF2C304837261@XMB-RCD-109.cisco.com><4F95ABA0.8090601@viagenie.ca><5B6B2B64C9FE2A489045EEEADDAFF2C304837272@XMB-RCD-109.cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C30483747A@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3048378BB@XMB-RCD-109.cisco.com> <42D0E71D-8599-44C6-91D4-B059A276EB6A@cisco.com> <379ECFD4-C696-4B86-9DCA-75B0887C4370@townsley.net> <504FAF77-A618-4E89-86ED-727FD0FEF473@laposte.net> In-Reply-To: <504FAF77-A618-4E89-86ED-727FD0FEF473@laposte.net> 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_867F4B6A1672E541A94676D556793ACD108F21AD38MOPESMBX01eut_" MIME-Version: 1.0 Cc: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 06:37:12 -0000 --_000_867F4B6A1672E541A94676D556793ACD108F21AD38MOPESMBX01eut_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable +1 on Remi's suggestion below. I agree with Mark that stateless is often, not always (e.g. some stateless = mechanisms are defined too complex) a better solution over stateful, howeve= r, we should not be blind for the DSLite story so should indeed not be take= n into this discussion. Regs Carl From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of R= =E9mi Despr=E9s Sent: woensdag 25 april 2012 19:09 To: Mark Townsley Cc: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis Mark, While it is important that 6204bis includes 6rd, and while it is also impor= tant to specify a 6rd sunsetting plan (good that you took the initiative), = I don't think it is right to include 6RD-4 to 6RD-6 at this stage. Reasons: - Proof that no sunsetting solution is possible without these requirements = hasn't been given. - I even think that, in a node supporting both IPv6 via IPv4 (6rd) and IPv4= via IPv6 with public IPv4 addresses (MAP or 4rd), the IPv4 and IPv4 and IP= v6 routers can each see only one interface. (The fact that it uses link lay= er interfaces natively or with some tunneling can AFAIK be kept invisible t= o the router.) Until a complete solution is described, doubt remains, but freezing now the= idea that this would be impossible isn't needed. Suggestion: keep 6RD-1 to 6RD-4, replace the others by a note warning that = a specification needs to be added to handle 6RD sunsetting. Regards, RD Le 2012-04-25 =E0 12:10, Mark Townsley a =E9crit : Whittled down to one sentence each, here are three requirements necessary i= n order to support incremental migration from 6rd to native IPv6: 6RD-4: A CE router MUST allow 6rd virtual and IPv6 native WAN interfaces to= be active simultaneously. 6RD-5: Each packet sent on a 6rd or native WAN interface MUST be directed s= uch that its source IP address is derived from the delegated prefix associa= ted with the upstream network the WAN interface is connected to [section 4.= 3 of BCP 84, RFC 3704]. 6RD-6: The CE router MUST allow identical or overlapping delegated prefixes= for each WAN interface with a preference for native IPv6 in the event forw= arding rules would have otherwise directed a packet to be sent equally via = 6rd or native IPv6. Summary: The first requirement says 6rd and native must coexist, the second= ensures that packets are directed such that they are not dropped by the up= stream network, and the third ensures native is chosen over 6rd in the even= t the paths are otherwise equal. - Mark On Apr 25, 2012, at 5:23 AM, Fred Baker wrote: On Apr 25, 2012, at 5:05 AM, Hemant Singh (shemant) wrote: Fred, Appreciate the quick reply. In MarkT's comments to Chris that Chris did no= t follow the Chairs' recommendation, the statement is not quite correct. A= dditionally MarkT saying to the mailer that "He (Chris) decided to throw t= hem in the trash" is not correct either. See the URL below where Chris cle= arly said, he has guidance from the IETF and WG in the past to not include = more than one normative statement per requirement. Thus Chris broke up the= MarkT recommendations and the break up has to stay. Thus it would help if= Mark revisits Chris' text and fills in holes Mark thinks the text has beca= use we just cannot go back to Mark's original text that combines multiple n= ormative statements in one requirement. I would like you to please work with Mark, on the mailer, to accomplish tha= t. http://www.ietf.org/mail-archive/web/v6ops/current/msg12705.html Moving on, the requirements provided by MarkT could use tighter text. For = example here is a portion of text provided to us to add. "6RD-5: The CE router MUST associate delegated prefixes with the WAN interface(s)" The CPE WAN interface can be unnumbered with only an IPv6 link-local addres= s and thus the CPE WAN does not have a global IPv6 address. In such an unn= umbered model, the CPE uses an address from the PD on a virtual network int= erface to source packets out the WAN such as ICMPv6 errors. I am away from= work tomorrow but we can certainly try and close any text two days from no= w including any WebEx phone call between Mark and us authors of rfc6204bis. I suspect that you misunderstand Mark's text, which says that the text he s= uggested was inadequate. RFC 3704, resolving a number of pages into a single sentence, recommends th= at if a packet uses a stated source address and that source address was der= ived from a stated upstream network, the packet should be directed to said = upstream network. The reason it would do so is that the upstream networks p= resumably implement BCP 38, meaning that if it is directed to a different u= pstream network it is likely to be dropped. 3704 goes on to make suggestion= s regarding the implementation of exit routing. What Mark is driving at is = "implement exit routing; if one is given multiple prefixes on different int= erfaces, physical or virtual, associate each such prefix with its source in= terface in routing for the purposes of source-address directed exit routing= ." Explanations and dialog such as this are the reason I am asking you to TALK= WITH MARK about issues you see rather than talking with the chairs or simp= ly presuming that the working group outcome in Paris is brain-dead. The out= come was, as near as I could tell, very sensible to the operators. Another example for tighter text is related to 6RD-4. Why does 6RD-4 only = say "during an incremental migration period from 6rd to native IPv6." Th= e SP could encounter a problem moving from 6rd to native IPv6 and may want = to revert back to 6rd. Thus the 6RD-4 bullet should cater to any migration= from 6rd to native IPv6 or vice versa. Further, when the CPE has different prefixes being used by native IPV6 and = 6rd, a host behind the CPE router has concurrent IPv6 addresses being used = (one IPv6 address from native IPv6 and another from the 6rd prefix). So wh= at source-address does the host pick to send a packet to a destination that= is totally disjoint with the two prefixes assigned to the CPE router? Let= 's say the host picked a source address from the 6rd prefix, then the CPE r= outer ships the packet out the 6rd tunnel instead of the higher preferred n= ative IPv6 network. So how is the native IPv6 preference enforced by the C= PE router? We also do not have consensus with the "MUST" in 6RD-4. Current consensus = is mostly towards changing the MUST to a SHOULD. I also do not see any SP = clamoring for 6rd sunsetting. One SP in France or France that has roughly = million 6rd customers does not impress me. I am a person who gets impresse= d with 200 million customers which is roughly what the cable broadband indu= stry is deploying native IPv6 for. Hemant -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-b= ounces@ietf.org] On Behalf Of Fred = Baker (fred) Sent: Tuesday, April 24, 2012 5:33 PM To: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis We discussed this at IETF 83, and you will find it in the minutes when they= come out. Mark and Ole asked for two things (statements regarding 6rd and = ds-lite), and the working group agreed to one of them. We are not discussin= g a "boiling of the ocean", nor are we discussing an infinite succession of= new requirements. We are discussing getting three no-brainer-class stateme= nts into the draft in a manner that the discussants all recognize and agree= to. The three statements were clarified by hum in the meeting, and were ea= ch able to be stated in a single sentence. I would ask the different actors in this discussion to please behave in a c= ourteous manner toward each other, and work together on this as requested b= y the chairs at IETF 83. _______________________________________________ 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 --_000_867F4B6A1672E541A94676D556793ACD108F21AD38MOPESMBX01eut_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

    +1 on Rem= i’s suggestion below.

     

    I agree with Mark= that stateless is often, not always (e.g. some stateless mechanisms= are defined too complex) a better solution over stateful, however, we shou= ld not be blind for the DSLite story so should indeed not be taken into thi= s discussion.

     <= /o:p>

    Regs

    Carl

     

     =

     

    From: v6ops-bounces@ietf.org [mailto:v6ops-bounces= @ietf.org] On Behalf Of R=E9mi Despr=E9s
    Sent: woensdag 25= april 2012 19:09
    To: Mark Townsley
    Cc: IPv6 Operations=
    Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis

     

    Mark,

     = ;

    While it is important that 6204b= is includes 6rd, and while it is also important to specify a 6rd sunsetting= plan (good that you took the initiative), I don't think it is right to inc= lude 6RD-4 to 6RD-6 at this stage.

     

    Reasons:

    - Proof that no sunsetting solution = is possible without these requirements hasn't been given.

    - I even think that, in a node supporting both= IPv6 via IPv4 (6rd) and IPv4 via IPv6 with public IPv4 addresses (MAP or 4= rd), the IPv4 and IPv4 and IPv6 routers can each see only one interface. (T= he fact that it uses link layer interfaces natively or with some tunneling = can AFAIK be kept invisible to the router.)

     

    Until a= complete solution is described, doubt remains, but freezing now the idea t= hat this would be impossible isn't needed.

     

    Suggesti= on: keep 6RD-1 to 6RD-4, replace the others by a note warning that a specif= ication needs to be added to handle 6RD sunsetting.

      

     

    Regards,

    RD

     

    &nb= sp;

     

     

     

    Le 2012-04-25 =E0 12:1= 0, Mark Townsley a =E9crit :


    <= br>

     

    Whittled down to one sentence each, here are thr= ee requirements necessary in order to support incremental migration from 6r= d to native IPv6: 

    =  


    6RD-4: A CE r= outer MUST allow 6rd virtual and IPv6 native WAN interfaces to be acti= ve simultaneously. 

    6RD-5: Each packet sent on a 6rd = or native WAN interface MUST be directed such that its source IP = address is derived from the delegated prefix associated with the upstr= eam network the WAN interface is connected to [section 4.3 of BCP=  84, RFC 3704].


    6RD-= 6: The CE router MUST allow identical or overlapping delegated prefixe= s for each WAN interface with a preference for native IPv6 in the even= t forwarding rules would have otherwise directed a packet to be sent equall= y via 6rd or native IPv6.

     

     

    Summary: The first requirement says = 6rd and native must coexist, the second ensures that packets are directed s= uch that they are not dropped by the upstream network, and the third ensure= s native is chosen over 6rd in the event the paths are otherwise equal.&nbs= p;

     

    - Mark

     

     

    <= div>

    On Apr 25, 2012, at 5:23 AM, Fred Baker wrote= :



     

    On Apr= 25, 2012, at 5:05 AM, Hemant Singh (shemant) wrote:



    Fred,

     

    Appreciate the quick reply.  = In MarkT's comments to Chris that Chris did not follow the Chairs' recommen= dation, the statement is not quite correct.  Additionally MarkT saying= to the mailer that  "He (Chris) decided to throw them in the tra= sh" is not correct either.  See the URL below where Chris clearly= said, he has guidance from the IETF and WG in the past to not include more= than one normative statement per requirement.  Thus Chris broke up th= e MarkT recommendations and the break up has to stay.  Thus it would help if Mark revisits Chr= is’ text and fills in holes Mark thinks the text has because we just = cannot go back to Mark’s original text that combines multiple normati= ve statements in one requirement.

     =

    I would like you to please work with Mark, on= the mailer, to accomplish that. 

     

    Moving on, the requirements provided by MarkT could use tighter text.  For example h= ere is a portion of text provided to us to add.

    &nb= sp;=

    "6RD-5: The CE router MUST associate delega= ted prefixes with the WAN

    interface(s)”=

     

    The CPE WAN interface can b= e unnumbered with only an IPv6 link-local address and thus the CPE WAN does= not have a global IPv6 address.  In such an unnumbered model, the CPE= uses an address from the PD on a virtual network interface to source packe= ts out the WAN such as ICMPv6 errors.  I am away from work tomorrow bu= t we can certainly try and close any text two days from now including any W= ebEx phone call between Mark and us authors of rfc6204bis. 

     

    I sus= pect that you misunderstand Mark's text, which says that the text he sugges= ted was inadequate. 

     

    RFC 3704, resolvi= ng a number of pages into a single sentence, recommends that if a packet us= es a stated source address and that source address was derived from a state= d upstream network, the packet should be directed to said upstream network.= The reason it would do so is that the upstream networks presumably impleme= nt BCP 38, meaning that if it is directed to a different upstream network i= t is likely to be dropped. 3704 goes on to make suggestions regarding the i= mplementation of exit routing. What Mark is driving at is "implement e= xit routing; if one is given multiple prefixes on different interfaces, phy= sical or virtual, associate each such prefix with its source interface in r= outing for the purposes of source-address directed exit routing."

     

    =

    Explanations and dialog such as this are the reas= on I am asking you to TALK WITH MARK about issues you see rather than talki= ng with the chairs or simply presuming that the working group outcome in Pa= ris is brain-dead. The outcome was, as near as I could tell, very sensible = to the operators.=

    &= nbsp;

    Another example for tighter text is related to 6RD-4.  Why does 6RD-4 only say= “during an incremental migration period from 6rd to native IPv6.R= 21;    The SP could encounter a problem moving from 6rd to native IPv= 6 and may want to revert back to 6rd.  Thus the 6RD-4 bullet should ca= ter to any migration from 6rd to native IPv6 or vice versa.

     

    Further, when the CPE h= as different prefixes being used by native IPV6 and 6rd, a host behind the = CPE router has concurrent IPv6 addresses being used (one IPv6 address from = native IPv6 and another from the 6rd prefix).  So what source-address = does the host pick to send a packet to a destination that is totally disjoi= nt with the two prefixes assigned to the CPE router?  Let’s say = the host picked a source address from the 6rd prefix, then the CPE router s= hips the packet out the 6rd tunnel instead of the higher preferred native I= Pv6 network.  So how is the native IPv6 preference enforced by the CPE= router?  

     

    W= e also do not have consensus with the “MUST” in 6RD-4.  Cu= rrent consensus is mostly towards changing the MUST to a SHOULD.  I also do not see any SP cla= moring for 6rd sunsetting.  One SP in France or France that has ro= ughly million 6rd customers does not impress me.  I am a person who ge= ts impressed with 200 million customers which is roughly what the cable bro= adband industry is deploying native IPv6 for.  

     

    Hemant

     <= span style=3D'font-size:10.5pt;font-family:Consolas'>

    =

     

    -----Original Message-----<= /span>

    From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Fred Baker (fred)

    Sent: Tuesday, April 24, 2012 5:33 PM

    To: IP= v6 Operations<= o:p>

    Subject: Re: [v6ops] 6rd sunsetting re= quirements for 6204-bis

     

     

    I would ask the different actors in thi= s discussion to please behave in a courteous manner toward each other, and = work together on this as requested by the chairs at IETF 83.

    <= div>

    _______________________________________________

    v6ops mailing list

     

    ________________________________________= _______
    v6ops mailing list
    v6ops@ie= tf.org
    https= ://www.ietf.org/mailman/listinfo/v6ops

     

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

     

    = --_000_867F4B6A1672E541A94676D556793ACD108F21AD38MOPESMBX01eut_-- From gilbert_kim@vanguard.com Thu Apr 26 01:13:46 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABB9A21F867B for ; Thu, 26 Apr 2012 01:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.11 X-Spam-Level: X-Spam-Status: No, score=-5.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2mrns33SjtAg for ; Thu, 26 Apr 2012 01:13:43 -0700 (PDT) Received: from pslva865.vanguard.com (pslva865.vanguard.com [192.175.204.35]) by ietfa.amsl.com (Postfix) with ESMTP id 47DFC21F8682 for ; Thu, 26 Apr 2012 01:13:42 -0700 (PDT) Received: from pslva831.vanguard.com (pslva831.vanguard.com [10.17.37.6]) by pslva865.vanguard.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.1.1) with ESMTP id q3Q8DY21026734 for ; Thu, 26 Apr 2012 04:13:37 -0400 X-DKIM: OpenDKIM Filter v2.1.3 pslva865.vanguard.com q3Q8DY21026734 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=vanguard.com; s=vanguard; t=1335428017; bh=+wySwPvnUx1Z98H1YQwljwFl93k=; l=823; h=Subject:From:To:Message-ID:Date:MIME-Version:Content-type; b=i6kiMBwFCo/kNtqAftucpDJ9ds8rylHFMyFeBkOvQAVQBCXxZ7CjBdUZRO3SEWA0v 3O2fJF5/j9XZ7IjlQPIBA== Received: from pslva867.vanguard.com (pslva867.vanguard.com [10.17.9.44]) by pslva831.vanguard.com (8.14.4/8.14.4) with ESMTP id q3Q8DY0r003254 for ; Thu, 26 Apr 2012 04:13:34 -0400 Received: from vgi4mail.vanguard.com (pvnva784.Vanguard.COM [10.17.128.144]) by pslva867.vanguard.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.1.1) with ESMTP id q3Q8DYrC028018 for ; Thu, 26 Apr 2012 04:13:34 -0400 Auto-Submitted: auto-generated From: gilbert_kim@vanguard.com To: v6ops@ietf.org Message-ID: Date: Thu, 26 Apr 2012 04:13:32 -0400 X-MIMETrack: Serialize by Router on VGI4Mail/VGI(Release 8.5.2FP2|March 22, 2011) at 04/26/2012 04:13:30 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: Thu, 26 Apr 2012 08:13:46 -0000 I will be out of the office starting 04/26/2012 and will not return until 04/30/2012. I am currently out of the country with limited access to email. If you need immediate assistance please contact Scott Yarosh. ---------------------------------------------------------------------- CONFIDENTIALITY STATEMENT. The information contained in this e-mail message, including attachments, is the confidential information of, and/or is the property of, Vanguard. The information is intended for use solely by the individual or entity named in the message. If you are not an intended recipient or you received this in error, then any review, printing, copying, or distribution of any such information is prohibited, and please notify the sender immediately by reply e-mail and then delete this e-mail from your system. From ichiroumakino@gmail.com Thu Apr 26 02:17:49 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA84421F867A for ; Thu, 26 Apr 2012 02:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.762 X-Spam-Level: X-Spam-Status: No, score=-2.762 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XOE8fct0YQX8 for ; Thu, 26 Apr 2012 02:17:48 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 23F4921F8672 for ; Thu, 26 Apr 2012 02:17:47 -0700 (PDT) Received: by werb10 with SMTP id b10so751725wer.31 for ; Thu, 26 Apr 2012 02:17:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=vguwkW++UVOkjiCsAUWpiYUst5yTJGUj9RwR2MDusvg=; b=Ki1lAJUow4po99VF3+ubcexChsjkPMu7O9Hk6e1BIGo4rNTqzq2q2kgqMe0o+3MZ3B gE2vQlzd+fw9QqTpql5UD3z0MCsv/vmmHU7yFDNlCF4K88UHTJrBRockHuvkRitgwLWN Ji8JeDx1uEjeWUJkVDsxEvZRS+v8cmwxUM1w1c1BE5MdXmSHz/2OY7pSgDrtiVLBCJXJ aTDOwNlT1XODXTi+50jJMtwl0qkIpW4C8o/xx4LZC96A5O5dq5yWpnfeJuepmXRaCG62 UfZnSTeKhLvwNEaEWXtTVopJTbCmErvzU/t4jYzbIrlgBV1KM+AudeAlqYpYMySpf/9f 07Zw== Received: by 10.180.89.9 with SMTP id bk9mr14610942wib.11.1335431867142; Thu, 26 Apr 2012 02:17:47 -0700 (PDT) Received: from dhcp-lys02-vla252-10-147-117-81.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id j3sm9148240wiw.1.2012.04.26.02.17.45 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 26 Apr 2012 02:17:46 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <867F4B6A1672E541A94676D556793ACD108F21AD38@MOPESMBX01.eu.thmulti.com> Date: Thu, 26 Apr 2012 11:17:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <789E808B-577C-4240-B714-3FBA8D3C5CD4@employees.org> References: <5B6B2B64C9FE2A489045EEEADDAFF2C30483722C@XMB-RCD-109.cisco.com><4F95A3D9.1010100@viagenie.ca><5B6B2B64C9FE2A489045EEEADDAFF2C304837261@XMB-RCD-109.cisco.com><4F95ABA0.8090601@viagenie.ca><5B6B2B64C9FE2A489045EEEADDAFF2C304837272@XMB-RCD-109.cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C30483747A@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3048378BB@XMB-RCD-109.cisco.com> <42D0E71D-8599-44C6-91D4-B059A276EB6A@cisco.com> <379ECFD4-C696-4B86-9DCA-75B0887C4370@townsley.net> <504FAF77-A618-4E89-86ED-727FD0FEF473@laposte.net> <867F4B6A1672E541A94676D556793ACD108F21AD38@MOPESMBX01.eu.thmulti.com> To: Wuyts Carl X-Mailer: Apple Mail (2.1257) Cc: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 09:17:49 -0000 > +1 on Remi=92s suggestion below. disagree. either we include 6rd and define completely how it is going to = work. or we do not include it at all. 6rd is a transitioning mechanism, i.e. = it is going to go away to be replaced by native IPv6 at some point. = hand-waving that issue now, is like peeing in your trousers to keep = warm. ;-) assuming we're defining this for devices that will not readily be = firmware upgradable. (Remi's proposal can be expressed as {RFC6204 + RFC5969}, so if we were = to do that, I don't think that needs any text at all in 6204.) > I agree with Mark that stateless is often, not always (e.g. some = stateless mechanisms are defined too complex) a better solution over = stateful, however, we should not be blind for the DSLite story so should = indeed not be taken into this discussion. agree. DS-lite provides IPv4 service. it is independently of everything = else in 6204. cheers, Ole > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of R=E9mi Despr=E9s > Sent: woensdag 25 april 2012 19:09 > To: Mark Townsley > Cc: IPv6 Operations > Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis > =20 > Mark, > =20 > While it is important that 6204bis includes 6rd, and while it is also = important to specify a 6rd sunsetting plan (good that you took the = initiative), I don't think it is right to include 6RD-4 to 6RD-6 at this = stage. > =20 > Reasons: > - Proof that no sunsetting solution is possible without these = requirements hasn't been given. > - I even think that, in a node supporting both IPv6 via IPv4 (6rd) and = IPv4 via IPv6 with public IPv4 addresses (MAP or 4rd), the IPv4 and IPv4 = and IPv6 routers can each see only one interface. (The fact that it uses = link layer interfaces natively or with some tunneling can AFAIK be kept = invisible to the router.) > =20 > Until a complete solution is described, doubt remains, but freezing = now the idea that this would be impossible isn't needed. > =20 > Suggestion: keep 6RD-1 to 6RD-4, replace the others by a note warning = that a specification needs to be added to handle 6RD sunsetting. > =20 > =20 > Regards, > RD > =20 > =20 > =20 > =20 > =20 > Le 2012-04-25 =E0 12:10, Mark Townsley a =E9crit : >=20 >=20 > =20 > Whittled down to one sentence each, here are three requirements = necessary in order to support incremental migration from 6rd to native = IPv6:=20 > =20 >=20 > 6RD-4: A CE router MUST allow 6rd virtual and IPv6 native WAN = interfaces to be active simultaneously.=20 >=20 > 6RD-5: Each packet sent on a 6rd or native WAN interface MUST be = directed such that its source IP address is derived from the delegated = prefix associated with the upstream network the WAN interface is = connected to [section 4.3 of BCP 84, RFC 3704]. >=20 > 6RD-6: The CE router MUST allow identical or overlapping delegated = prefixes for each WAN interface with a preference for native IPv6 in the = event forwarding rules would have otherwise directed a packet to be sent = equally via 6rd or native IPv6. > =20 > =20 > Summary: The first requirement says 6rd and native must coexist, the = second ensures that packets are directed such that they are not dropped = by the upstream network, and the third ensures native is chosen over 6rd = in the event the paths are otherwise equal.=20 > =20 > - Mark > =20 > =20 > On Apr 25, 2012, at 5:23 AM, Fred Baker wrote: >=20 >=20 > =20 > On Apr 25, 2012, at 5:05 AM, Hemant Singh (shemant) wrote: >=20 >=20 > Fred, > =20 > Appreciate the quick reply. In MarkT's comments to Chris that Chris = did not follow the Chairs' recommendation, the statement is not quite = correct. Additionally MarkT saying to the mailer that "He (Chris) = decided to throw them in the trash" is not correct either. See the URL = below where Chris clearly said, he has guidance from the IETF and WG in = the past to not include more than one normative statement per = requirement. Thus Chris broke up the MarkT recommendations and the = break up has to stay. Thus it would help if Mark revisits Chris=92 text = and fills in holes Mark thinks the text has because we just cannot go = back to Mark=92s original text that combines multiple normative = statements in one requirement. > =20 > I would like you to please work with Mark, on the mailer, to = accomplish that.=20 > =20 > http://www.ietf.org/mail-archive/web/v6ops/current/msg12705.html > Moving on, the requirements provided by MarkT could use tighter text. = For example here is a portion of text provided to us to add. > =20 > "6RD-5: The CE router MUST associate delegated prefixes with the WAN > interface(s)=94 > =20 > The CPE WAN interface can be unnumbered with only an IPv6 link-local = address and thus the CPE WAN does not have a global IPv6 address. In = such an unnumbered model, the CPE uses an address from the PD on a = virtual network interface to source packets out the WAN such as ICMPv6 = errors. I am away from work tomorrow but we can certainly try and close = any text two days from now including any WebEx phone call between Mark = and us authors of rfc6204bis.=20 > =20 > I suspect that you misunderstand Mark's text, which says that the text = he suggested was inadequate.=20 > =20 > RFC 3704, resolving a number of pages into a single sentence, = recommends that if a packet uses a stated source address and that source = address was derived from a stated upstream network, the packet should be = directed to said upstream network. The reason it would do so is that the = upstream networks presumably implement BCP 38, meaning that if it is = directed to a different upstream network it is likely to be dropped. = 3704 goes on to make suggestions regarding the implementation of exit = routing. What Mark is driving at is "implement exit routing; if one is = given multiple prefixes on different interfaces, physical or virtual, = associate each such prefix with its source interface in routing for the = purposes of source-address directed exit routing." > =20 > Explanations and dialog such as this are the reason I am asking you to = TALK WITH MARK about issues you see rather than talking with the chairs = or simply presuming that the working group outcome in Paris is = brain-dead. The outcome was, as near as I could tell, very sensible to = the operators. > =20 > Another example for tighter text is related to 6RD-4. Why does 6RD-4 = only say =93during an incremental migration period from 6rd to native = IPv6.=94 The SP could encounter a problem moving from 6rd to native = IPv6 and may want to revert back to 6rd. Thus the 6RD-4 bullet should = cater to any migration from 6rd to native IPv6 or vice versa. > =20 > Further, when the CPE has different prefixes being used by native IPV6 = and 6rd, a host behind the CPE router has concurrent IPv6 addresses = being used (one IPv6 address from native IPv6 and another from the 6rd = prefix). So what source-address does the host pick to send a packet to = a destination that is totally disjoint with the two prefixes assigned to = the CPE router? Let=92s say the host picked a source address from the = 6rd prefix, then the CPE router ships the packet out the 6rd tunnel = instead of the higher preferred native IPv6 network. So how is the = native IPv6 preference enforced by the CPE router? =20 > =20 > We also do not have consensus with the =93MUST=94 in 6RD-4. Current = consensus is mostly towards changing the MUST to a SHOULD. I also do = not see any SP clamoring for 6rd sunsetting. One SP in France or France = that has roughly million 6rd customers does not impress me. I am a = person who gets impressed with 200 million customers which is roughly = what the cable broadband industry is deploying native IPv6 for. =20 > =20 > Hemant > =20 > =20 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Fred Baker (fred) > Sent: Tuesday, April 24, 2012 5:33 PM > To: IPv6 Operations > Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis > =20 > We discussed this at IETF 83, and you will find it in the minutes when = they come out. Mark and Ole asked for two things (statements regarding = 6rd and ds-lite), and the working group agreed to one of them. We are = not discussing a "boiling of the ocean", nor are we discussing an = infinite succession of new requirements. We are discussing getting three = no-brainer-class statements into the draft in a manner that the = discussants all recognize and agree to. The three statements were = clarified by hum in the meeting, and were each able to be stated in a = single sentence. > =20 > I would ask the different actors in this discussion to please behave = in a courteous manner toward each other, and work together on this as = requested by the chairs at IETF 83. > _______________________________________________ > 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 > _______________________________________________ > 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 mark@townsley.net Thu Apr 26 05:25:58 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC5A21F85B8 for ; Thu, 26 Apr 2012 05:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.981 X-Spam-Level: X-Spam-Status: No, score=-2.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_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 tvcXuSqJxh8A for ; Thu, 26 Apr 2012 05:25:56 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0FFD021F85B7 for ; Thu, 26 Apr 2012 05:25:55 -0700 (PDT) Received: by wibhj6 with SMTP id hj6so4919978wib.13 for ; Thu, 26 Apr 2012 05:25:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=YT7NDTkaLhhOBBw3uiXC6wuH1UMULPO/jN3hia690Ak=; b=d4XbQcB2GzGoZQWDYbYOpRrwTbCnYeG+f92+nCraqeLNd7ae1JXCsoO1Agu+JCrUw6 4RxGJf2iSt8eShR5uM/HX7R52xdbpt9metHKwQ1zKHMv6e/qy/b5S7Liix0ueWl3MXV/ 5oW5xnv2sC85v6v049NZxCEXMbw20uf3y/cxJLC7yAjaSf+eUcNypx8GGzyLl1pI3u8u oZYKMK8KfCTzcz8Xu5myyanEkfcJ0m25FVWRU8CcqLxoqfPgTETQ8UVaHx0S/xpVKOep ueBZ2PGYoN4VYV+bKzplN2CFfAT4kk8RDRodVDTAwPsbZmnjrw8URpHiolxbDO+QmuTj 11Tg== Received: by 10.216.133.96 with SMTP id p74mr4137223wei.30.1335443155011; Thu, 26 Apr 2012 05:25:55 -0700 (PDT) Received: from ams-townsley-8912.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id o2sm10563683wiv.11.2012.04.26.05.25.44 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 26 Apr 2012 05:25:53 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_D87089A1-0C17-484C-8167-4605FC228F61" From: Mark Townsley In-Reply-To: Date: Thu, 26 Apr 2012 14:25:38 +0200 Message-Id: <600EBF0A-AED0-459E-B32E-3C4D9F4884BC@townsley.net> References: To: Chris Donley X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQm+7CshGTegPbP8BBeoHIOvZX3OTJpBsMOadnkbSCN4ZBwg3vetqcr5OVgylBUqyjWabBVk Cc: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 12:25:58 -0000 --Apple-Mail=_D87089A1-0C17-484C-8167-4605FC228F61 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Apr 25, 2012, at 6:19 PM, Chris Donley wrote: > I'm OK with 6rd-5. =20 >=20 > I'm OK in principle with 6rd-4, but I am concerned that as written, it = might be interpreted that both 6rd and native always need to be active = simultaneously, and I think that could cause problems when it's not the = intent of the ISP. =20 "6RD-4: A CE router MUST allow 6rd virtual and IPv6 native WAN = interfaces to be active simultaneously." I find it hard to believe that someone would interpret "allow" as = "always".=20 > Perhaps the following would clarify: > 6RD-4: A CE router MUST support simultaneous operation of 6rd virtual = and IPv6 native WAN interfaces. However, 6rd and native IPv6 can be = configured independently; in many cases, only a single IPv6 WAN = interface (native or 6rd) needs to be active. No, you have added a subjective "in many cases" here that unnecessarily = dates the document. The whole idea is that in the future it will be far = more than "in many cases" as 6rd transitions to native.=20 > 6rd-6 is really two requirements. I am concerned that its current = form is ambiguous. I would prefer: The case where the 6rd path and native path need the tie-breaker will = not happen when the WAN prefixes are different. That's why it's worded = as one requirement, its only applicable when the prefixes are the same. =20= > 6rd-6: The IPv6 CE Router MUST allow the 6rd virtual interface and = IPv6 native interface to use identical or overlapping prefixes. This = requirement does not preclude the IPv6 CE Router from using different = prefixes for the 6rd virtual interface and IPv6 native interface. > 6rd-7: In the event that forwarding rules produce a tie between 6rd = and native IPv6, by default, the IPv6 CE Router MUST prefer native IPv6. I have no technical objection with the above. I think it is back to = being too wordy, which was the original complaint with my text I offered = you and Hemant.=20 And, Fred gave clear guidance, one sentence per requirement, and 3 = requirements.=20 I'll work up a new set and see if the WG prefers it.=20 - Mark >=20 > Chris >=20 > From: Mark Townsley > Date: Wed, 25 Apr 2012 04:10:08 -0600 > To: IPv6 Operations > Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis >=20 >=20 > Whittled down to one sentence each, here are three requirements = necessary in order to support incremental migration from 6rd to native = IPv6:=20 >=20 >=20 > 6RD-4: A CE router MUST allow 6rd virtual and IPv6 native WAN = interfaces to be active simultaneously.=20 >=20 > 6RD-5: Each packet sent on a 6rd or native WAN interface MUST be = directed such that its source IP address is derived from the delegated = prefix associated with the upstream network the WAN interface is = connected to [section 4.3 of BCP 84, RFC 3704]. >=20 > 6RD-6: The CE router MUST allow identical or overlapping delegated = prefixes for each WAN interface with a preference for native IPv6 in the = event forwarding rules would have otherwise directed a packet to be sent = equally via 6rd or native IPv6. >=20 >=20 > Summary: The first requirement says 6rd and native must coexist, the = second ensures that packets are directed such that they are not dropped = by the upstream network, and the third ensures native is chosen over 6rd = in the event the paths are otherwise equal.=20 >=20 > - Mark >=20 >=20 > On Apr 25, 2012, at 5:23 AM, Fred Baker wrote: >=20 >>=20 >> On Apr 25, 2012, at 5:05 AM, Hemant Singh (shemant) wrote: >>=20 >>> Fred, >>> =20 >>> Appreciate the quick reply. In MarkT's comments to Chris that Chris = did not follow the Chairs' recommendation, the statement is not quite = correct. Additionally MarkT saying to the mailer that "He (Chris) = decided to throw them in the trash" is not correct either. See the URL = below where Chris clearly said, he has guidance from the IETF and WG in = the past to not include more than one normative statement per = requirement. Thus Chris broke up the MarkT recommendations and the = break up has to stay. Thus it would help if Mark revisits Chris=92 text = and fills in holes Mark thinks the text has because we just cannot go = back to Mark=92s original text that combines multiple normative = statements in one requirement. >>=20 >> I would like you to please work with Mark, on the mailer, to = accomplish that.=20 >>=20 >>> http://www.ietf.org/mail-archive/web/v6ops/current/msg12705.html >>> Moving on, the requirements provided by MarkT could use tighter = text. For example here is a portion of text provided to us to add. >>> =20 >>> "6RD-5: The CE router MUST associate delegated prefixes with the WAN >>> interface(s)=94 >>> =20 >>> The CPE WAN interface can be unnumbered with only an IPv6 link-local = address and thus the CPE WAN does not have a global IPv6 address. In = such an unnumbered model, the CPE uses an address from the PD on a = virtual network interface to source packets out the WAN such as ICMPv6 = errors. I am away from work tomorrow but we can certainly try and close = any text two days from now including any WebEx phone call between Mark = and us authors of rfc6204bis.=20 >>=20 >> I suspect that you misunderstand Mark's text, which says that the = text he suggested was inadequate.=20 >>=20 >> RFC 3704, resolving a number of pages into a single sentence, = recommends that if a packet uses a stated source address and that source = address was derived from a stated upstream network, the packet should be = directed to said upstream network. The reason it would do so is that the = upstream networks presumably implement BCP 38, meaning that if it is = directed to a different upstream network it is likely to be dropped. = 3704 goes on to make suggestions regarding the implementation of exit = routing. What Mark is driving at is "implement exit routing; if one is = given multiple prefixes on different interfaces, physical or virtual, = associate each such prefix with its source interface in routing for the = purposes of source-address directed exit routing." >>=20 >> Explanations and dialog such as this are the reason I am asking you = to TALK WITH MARK about issues you see rather than talking with the = chairs or simply presuming that the working group outcome in Paris is = brain-dead. The outcome was, as near as I could tell, very sensible to = the operators. >>=20 >>> Another example for tighter text is related to 6RD-4. Why does = 6RD-4 only say =93during an incremental migration period from 6rd to = native IPv6.=94 The SP could encounter a problem moving from 6rd to = native IPv6 and may want to revert back to 6rd. Thus the 6RD-4 bullet = should cater to any migration from 6rd to native IPv6 or vice versa. >>> =20 >>> Further, when the CPE has different prefixes being used by native = IPV6 and 6rd, a host behind the CPE router has concurrent IPv6 addresses = being used (one IPv6 address from native IPv6 and another from the 6rd = prefix). So what source-address does the host pick to send a packet to = a destination that is totally disjoint with the two prefixes assigned to = the CPE router? Let=92s say the host picked a source address from the = 6rd prefix, then the CPE router ships the packet out the 6rd tunnel = instead of the higher preferred native IPv6 network. So how is the = native IPv6 preference enforced by the CPE router? =20 >>> =20 >>> We also do not have consensus with the =93MUST=94 in 6RD-4. Current = consensus is mostly towards changing the MUST to a SHOULD. I also do = not see any SP clamoring for 6rd sunsetting. One SP in France or France = that has roughly million 6rd customers does not impress me. I am a = person who gets impressed with 200 million customers which is roughly = what the cable broadband industry is deploying native IPv6 for. =20 >>> =20 >>> Hemant >>> =20 >>> =20 >>> -----Original Message----- >>> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On = Behalf Of Fred Baker (fred) >>> Sent: Tuesday, April 24, 2012 5:33 PM >>> To: IPv6 Operations >>> Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis >>> =20 >>> We discussed this at IETF 83, and you will find it in the minutes = when they come out. Mark and Ole asked for two things (statements = regarding 6rd and ds-lite), and the working group agreed to one of them. = We are not discussing a "boiling of the ocean", nor are we discussing an = infinite succession of new requirements. We are discussing getting three = no-brainer-class statements into the draft in a manner that the = discussants all recognize and agree to. The three statements were = clarified by hum in the meeting, and were each able to be stated in a = single sentence. >>> =20 >>> I would ask the different actors in this discussion to please behave = in a courteous manner toward each other, and work together on this as = requested by the chairs at IETF 83. >>> _______________________________________________ >>> 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=_D87089A1-0C17-484C-8167-4605FC228F61 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

    I find it = hard to believe that someone would interpret "allow" as = "always". 

    Perhaps the = following would clarify:
    6RD-4: A CE router MUST support = simultaneous operation of 6rd virtual and IPv6 native WAN interfaces. =  However, 6rd and native IPv6 can be configured independently; in = many cases, only a single IPv6 WAN interface (native or 6rd) needs to be = active.

    No, = you have added a subjective "in many cases" here that unnecessarily = dates the document. The whole idea is that in the future it will be far = more than "in many cases" as 6rd transitions to = native. 

    6rd-6 is really two requirements.  I am concerned that its = current form is ambiguous.  I would = prefer:

    The case where the 6rd path and native path need the = tie-breaker will not happen when the WAN prefixes are different. That's = why it's worded as one requirement, its only applicable when the = prefixes are the same. =  


    6rd-6: The IPv6 = CE Router MUST allow the 6rd virtual interface and IPv6 native interface = to use identical or overlapping prefixes. This requirement does not = preclude the IPv6 CE Router from using different prefixes for the 6rd = virtual interface and IPv6 native interface.
    6rd-7: In the = event that forwarding rules produce a tie between 6rd and native IPv6, = by default, the IPv6 CE Router MUST prefer native = IPv6.

    I have no technical objection with the above. I think it is back = to being too wordy, which was the original complaint with my text I = offered you and Hemant. 

    And, Fred gave = clear guidance, one sentence per requirement, and 3 = requirements. 

    I'll work up a new set and = see if the WG prefers it. 

    - = Mark


    Chris

    From: = Mark Townsley <mark@townsley.net>
    Date: Wed, 25 Apr 2012 04:10:08 = -0600
    To: IPv6 Operations = <v6ops@ietf.org>
    Subject: Re: [v6ops] 6rd sunsetting = requirements for 6204-bis


    Whittled = down to one sentence each, here are three requirements necessary in = order to support incremental migration from 6rd to = native IPv6: 


    6RD-4: A CE = router MUST allow 6rd virtual and IPv6 native WAN interfaces to = be active simultaneously. 

    6RD-5: Each packet = sent on a 6rd or native WAN interface MUST be directed such that = its source IP address is derived from the delegated prefix = associated with the upstream network the WAN interface is connected = to [section 4.3 of BCP 84, RFC = 3704].

    6RD-6: The CE router MUST allow identical or = overlapping delegated prefixes for each WAN interface with a = preference for native IPv6 in the event forwarding rules would have = otherwise directed a packet to be sent equally via 6rd or native = IPv6.


    Summary: The first = requirement says 6rd and native must coexist, the second ensures that = packets are directed such that they are not dropped by the upstream = network, and the third ensures native is chosen over 6rd in the event = the paths are otherwise equal. 

    - = Mark


    On Apr 25, 2012, at 5:23 AM, Fred = Baker wrote:


    On Apr 25, 2012, at 5:05 AM, Hemant = Singh (shemant) wrote:

    Fred,
     
    Appreciate the quick reply.  In MarkT's comments to Chris = that Chris did not follow the Chairs' recommendation, the statement is = not quite correct.  Additionally MarkT saying to the mailer = that  "He (Chris) decided to throw them in the trash" is not = correct either.  See the URL below where Chris clearly said, he has = guidance from the IETF and WG in the past to not include more than one = normative statement per requirement.  Thus Chris broke up the MarkT = recommendations and the break up has to stay.  Thus it would help if = Mark revisits Chris=92 text and fills in holes Mark thinks the text has = because we just cannot go back to Mark=92s original text that combines = multiple normative statements in one = requirement.

    I would like you to = please work with Mark, on the mailer, to accomplish = that. 

    <= div>

    I suspect that you = misunderstand Mark's text, which says that the text he suggested was = inadequate. 

    RFC 3704, resolving a = number of pages into a single sentence, recommends that if a packet uses = a stated source address and that source address was derived from a = stated upstream network, the packet should be directed to said upstream = network. The reason it would do so is that the upstream networks = presumably implement BCP 38, meaning that if it is directed to a = different upstream network it is likely to be dropped. 3704 goes on to = make suggestions regarding the implementation of exit routing. What Mark = is driving at is "implement exit routing; if one is given multiple = prefixes on different interfaces, physical or virtual, associate each = such prefix with its source interface in routing for the purposes of = source-address directed exit routing."

    Explanations and dialog = such as this are the reason I am asking you to TALK WITH MARK about = issues you see rather than talking with the chairs or simply presuming = that the working group outcome in Paris is brain-dead. The outcome was, = as near as I could tell, very sensible to the = operators.

    Another example for tighter text is related to 6RD-4.  = Why does 6RD-4 only say =93during an incremental migration period from 6rd to native = IPv6.=94    The SP could encounter a problem moving from 6rd to native IPv6 = and may want to revert back to 6rd.  Thus the 6RD-4 bullet should = cater to any migration from 6rd to native IPv6 or vice = versa.
     
    Further, when the CPE has different prefixes being used by = native IPV6 and 6rd, a host behind the CPE router has concurrent IPv6 = addresses being used (one IPv6 address from native IPv6 and another from = the 6rd prefix).  So what source-address does the host pick to send = a packet to a destination that is totally disjoint with the two prefixes = assigned to the CPE router?  Let=92s say the host picked a source = address from the 6rd prefix, then the CPE router ships the packet out = the 6rd tunnel instead of the higher preferred native IPv6 = network.  So how is the native IPv6 preference enforced by the CPE = router?  
     
    We also do not have consensus with the =93MUST=94 in = 6RD-4.  Current consensus is mostly towards changing the MUST to a = SHOULD.  I = also do not see any SP clamoring for 6rd sunsetting.  One SP in = France or France that has roughly million 6rd customers does not impress = me.  I am a person who gets impressed with 200 million customers = which is roughly what the cable broadband industry is deploying native = IPv6 for.  
     
    Hemant
     
     
    -----Original Message-----
    Sent: Tuesday, April 24, 2012 5:33 = PM
    Subject: Re: [v6ops] 6rd sunsetting requirements for = 6204-bis
     
    We discussed this at IETF 83, and you will find it in the = minutes when they come out. Mark and Ole asked for two things = (statements regarding 6rd and ds-lite), and the working group agreed to = one of them. We are not discussing a "boiling of the ocean", nor are we = discussing an infinite succession of new requirements. We are discussing = getting three no-brainer-class statements into the draft in a manner = that the discussants all recognize and agree to. The three statements = were clarified by hum in the meeting, and were each able to be stated in = a single sentence.
     
    I would ask the different actors in this discussion to please = behave in a courteous manner toward each other, and work together on = this as requested by the chairs at IETF 83.
    v6ops mailing = list


    = --Apple-Mail=_D87089A1-0C17-484C-8167-4605FC228F61-- From mark@townsley.net Thu Apr 26 05:49:16 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F8D221F87FD for ; Thu, 26 Apr 2012 05:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=-0.427, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, 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 LFo3BidwlBFi for ; Thu, 26 Apr 2012 05:49:14 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4762E21F8731 for ; Thu, 26 Apr 2012 05:49:14 -0700 (PDT) Received: by werb10 with SMTP id b10so906974wer.31 for ; Thu, 26 Apr 2012 05:49:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:mime-version:content-type:subject:date:in-reply-to:to :references:message-id:x-mailer:x-gm-message-state; bh=daOLjirNt8DuzfmBSpD98RalTU6yik+SN1q6vriQylA=; b=eQsoeT/D6HN8YRn3NjNFPVqKgCWP+LYQUqta4N/nzhdHwoxlWmAZrqeq+aTQwHk+mZ kOd1CXb72ZPJqCVIj3m2SVBgD0INXrIALwyIfUutheSLHPvoVFWcuoCjshryxUa0UlL1 lkma+Fx8KatSRZMZrNUWSlamxyspq/KjIoDkvvfHIU5jQ1UGy0EtO59iQ89JK9HcNXM4 PZDA+gTtdVCwxMzr/QxAtwrdNcbuxLYuM186tF6DJq1M5dAODGpetTSAWKFTR/tPTl6E zVVIsAYAJycDPVakKRG2Aw+azNiqGdlKQ5d/clAJZcj+PNLrq6jKUq5BRx2ZIMHQ2oPP o8Jg== Received: by 10.180.78.40 with SMTP id y8mr50854348wiw.15.1335444553410; Thu, 26 Apr 2012 05:49:13 -0700 (PDT) Received: from ams-townsley-8912.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id ff9sm44565062wib.2.2012.04.26.05.49.11 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 26 Apr 2012 05:49:12 -0700 (PDT) From: Mark Townsley Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_C7C3C62E-DBB8-4936-A695-3352F593EC40" Date: Thu, 26 Apr 2012 14:49:04 +0200 In-Reply-To: <379ECFD4-C696-4B86-9DCA-75B0887C4370@townsley.net> To: Chris Donley , IPv6 Operations References: <5B6B2B64C9FE2A489045EEEADDAFF2C30483722C@XMB-RCD-109.cisco.com><4F95A3D9.1010100@viagenie.ca><5B6B2B64C9FE2A489045EEEADDAFF2C304837261@XMB-RCD-109.cisco.com><4F95ABA0.8090601@viagenie.ca><5B6B2B64C9FE2A489045EEEADDAFF2C304837272@XMB-RCD-109.cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C30483747A@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3048378BB@XMB-RCD-109.cisco.com> <42D0E71D-8599-44C6-91D4-B059A276EB6A@cisco.com> <379ECFD4-C696-4B86-9DCA-75B0887C4370@townsley.net> Message-Id: <639FE0F2-ECD6-4C83-BB1F-9A9676ABCECB@townsley.net> X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQlwEGUOn6rYqfzO/SpTPLR5G9SLEiOaJn1Ag/y4zAk0TJ+sZEWijCbQC67s/DYS6K5SccQ6 Subject: [v6ops] 6rd sunsetting requirements (version 2) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 12:49:16 -0000 --Apple-Mail=_C7C3C62E-DBB8-4936-A695-3352F593EC40 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Chris, Here is a new set of requirements based on your feedback. In this = version, I adopted some but not all of what you were asking for. = Specifically, - I adopted your 6RD-7 text verbatim (though I still personally prefer = using the term "equal" vs. "tie")=20 - I changed my text that specified only that delegated prefixes could be = identical, to say that they could be identical as well as different. - I couldn't come up with any other way to clarify "allow" not meaning = "always" without complicating the text in 6RD-4.=20 - I did not include text that suggested whether having one active = interface vs. two would be more or less a common case. We now have 4 requirements instead of 3. I am still OK with my original = 3, but if you and the WG prefer these 4 that is fine by me as well.=20 - Mark 6RD-4: A CE router MUST allow 6rd virtual and IPv6 native WAN interfaces = to be active simultaneously.=20 6RD-5: Each packet sent on a 6rd or native WAN interface MUST be = directed such that its source IP address is derived from the delegated = prefix associated with the upstream network the WAN interface is = connected to [section 4.3 of BCP 84, RFC 3704]. 6RD-6: The CE router MUST allow different or identical delegated = prefixes to be configured via each WAN interface. 6RD-7 In the event that forwarding rules produce a tie between 6rd and = native IPv6, by default, the IPv6 CE Router MUST prefer native IPv6. On Apr 25, 2012, at 12:10 PM, Mark Townsley wrote: >=20 > Whittled down to one sentence each, here are three requirements = necessary in order to support incremental migration from 6rd to native = IPv6:=20 >=20 >=20 > 6RD-4: A CE router MUST allow 6rd virtual and IPv6 native WAN = interfaces to be active simultaneously.=20 >=20 > 6RD-5: Each packet sent on a 6rd or native WAN interface MUST be = directed such that its source IP address is derived from the delegated = prefix associated with the upstream network the WAN interface is = connected to [section 4.3 of BCP 84, RFC 3704]. >=20 > 6RD-6: The CE router MUST allow identical or overlapping delegated = prefixes for each WAN interface with a preference for native IPv6 in the = event forwarding rules would have otherwise directed a packet to be sent = equally via 6rd or native IPv6. >=20 >=20 > Summary: The first requirement says 6rd and native must coexist, the = second ensures that packets are directed such that they are not dropped = by the upstream network, and the third ensures native is chosen over 6rd = in the event the paths are otherwise equal.=20 >=20 > - Mark >=20 >=20 > On Apr 25, 2012, at 5:23 AM, Fred Baker wrote: >=20 >>=20 >> On Apr 25, 2012, at 5:05 AM, Hemant Singh (shemant) wrote: >>=20 >>> Fred, >>> =20 >>> Appreciate the quick reply. In MarkT's comments to Chris that Chris = did not follow the Chairs' recommendation, the statement is not quite = correct. Additionally MarkT saying to the mailer that "He (Chris) = decided to throw them in the trash" is not correct either. See the URL = below where Chris clearly said, he has guidance from the IETF and WG in = the past to not include more than one normative statement per = requirement. Thus Chris broke up the MarkT recommendations and the = break up has to stay. Thus it would help if Mark revisits Chris=92 text = and fills in holes Mark thinks the text has because we just cannot go = back to Mark=92s original text that combines multiple normative = statements in one requirement. >>=20 >> I would like you to please work with Mark, on the mailer, to = accomplish that.=20 >>=20 >>> http://www.ietf.org/mail-archive/web/v6ops/current/msg12705.html >>> Moving on, the requirements provided by MarkT could use tighter = text. For example here is a portion of text provided to us to add. >>> =20 >>> "6RD-5: The CE router MUST associate delegated prefixes with the WAN >>> interface(s)=94 >>> =20 >>> The CPE WAN interface can be unnumbered with only an IPv6 link-local = address and thus the CPE WAN does not have a global IPv6 address. In = such an unnumbered model, the CPE uses an address from the PD on a = virtual network interface to source packets out the WAN such as ICMPv6 = errors. I am away from work tomorrow but we can certainly try and close = any text two days from now including any WebEx phone call between Mark = and us authors of rfc6204bis.=20 >>=20 >> I suspect that you misunderstand Mark's text, which says that the = text he suggested was inadequate.=20 >>=20 >> RFC 3704, resolving a number of pages into a single sentence, = recommends that if a packet uses a stated source address and that source = address was derived from a stated upstream network, the packet should be = directed to said upstream network. The reason it would do so is that the = upstream networks presumably implement BCP 38, meaning that if it is = directed to a different upstream network it is likely to be dropped. = 3704 goes on to make suggestions regarding the implementation of exit = routing. What Mark is driving at is "implement exit routing; if one is = given multiple prefixes on different interfaces, physical or virtual, = associate each such prefix with its source interface in routing for the = purposes of source-address directed exit routing." >>=20 >> Explanations and dialog such as this are the reason I am asking you = to TALK WITH MARK about issues you see rather than talking with the = chairs or simply presuming that the working group outcome in Paris is = brain-dead. The outcome was, as near as I could tell, very sensible to = the operators. >>=20 >>> Another example for tighter text is related to 6RD-4. Why does = 6RD-4 only say =93during an incremental migration period from 6rd to = native IPv6.=94 The SP could encounter a problem moving from 6rd to = native IPv6 and may want to revert back to 6rd. Thus the 6RD-4 bullet = should cater to any migration from 6rd to native IPv6 or vice versa. >>> =20 >>> Further, when the CPE has different prefixes being used by native = IPV6 and 6rd, a host behind the CPE router has concurrent IPv6 addresses = being used (one IPv6 address from native IPv6 and another from the 6rd = prefix). So what source-address does the host pick to send a packet to = a destination that is totally disjoint with the two prefixes assigned to = the CPE router? Let=92s say the host picked a source address from the = 6rd prefix, then the CPE router ships the packet out the 6rd tunnel = instead of the higher preferred native IPv6 network. So how is the = native IPv6 preference enforced by the CPE router? =20 >>> =20 >>> We also do not have consensus with the =93MUST=94 in 6RD-4. Current = consensus is mostly towards changing the MUST to a SHOULD. I also do = not see any SP clamoring for 6rd sunsetting. One SP in France or France = that has roughly million 6rd customers does not impress me. I am a = person who gets impressed with 200 million customers which is roughly = what the cable broadband industry is deploying native IPv6 for. =20 >>> =20 >>> Hemant >>> =20 >>> =20 >>> -----Original Message----- >>> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On = Behalf Of Fred Baker (fred) >>> Sent: Tuesday, April 24, 2012 5:33 PM >>> To: IPv6 Operations >>> Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis >>> =20 >>> We discussed this at IETF 83, and you will find it in the minutes = when they come out. Mark and Ole asked for two things (statements = regarding 6rd and ds-lite), and the working group agreed to one of them. = We are not discussing a "boiling of the ocean", nor are we discussing an = infinite succession of new requirements. We are discussing getting three = no-brainer-class statements into the draft in a manner that the = discussants all recognize and agree to. The three statements were = clarified by hum in the meeting, and were each able to be stated in a = single sentence. >>> =20 >>> I would ask the different actors in this discussion to please behave = in a courteous manner toward each other, and work together on this as = requested by the chairs at IETF 83. >>> _______________________________________________ >>> 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=_C7C3C62E-DBB8-4936-A695-3352F593EC40 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

    - I changed my text that specified = only that delegated prefixes could be identical, to say that they could = be identical as well as different.

    - I couldn't = come up with any other way to clarify "allow" not meaning "always" = without complicating the text in 6RD-4. 

    - = I did not include text that suggested whether having one active = interface vs. two would be more or less a common = case.

    We now have 4 requirements instead of 3. = I am still OK with my original 3, but if you and the WG prefer these 4 = that is fine by me as well. 

    - = Mark


    Whittled = down to one sentence each, here are three requirements necessary in = order to support incremental migration from 6rd to = native IPv6: 


    6RD-4: A CE = router MUST allow 6rd virtual and IPv6 native WAN interfaces to = be active simultaneously. 

    6RD-5: Each packet = sent on a 6rd or native WAN interface MUST be directed such that = its source IP address is derived from the delegated prefix = associated with the upstream network the WAN interface is connected = to [section 4.3 of BCP 84, RFC = 3704].

    6RD-6: The CE router MUST allow identical or = overlapping delegated prefixes for each WAN interface with a = preference for native IPv6 in the event forwarding rules would have = otherwise directed a packet to be sent equally via 6rd or native = IPv6.


    Summary: The first = requirement says 6rd and native must coexist, the second ensures that = packets are directed such that they are not dropped by the upstream = network, and the third ensures native is chosen over 6rd in the event = the paths are otherwise equal. 

    - = Mark


    On Apr 25, 2012, at 5:23 AM, Fred = Baker wrote:


    On Apr 25, 2012, at 5:05 AM, Hemant = Singh (shemant) wrote:

    Fred,
     
    Appreciate the quick reply.  In MarkT's comments to Chris = that Chris did not follow the Chairs' recommendation, the statement is = not quite correct.  Additionally MarkT saying to the mailer = that  "He (Chris) decided to throw them in the trash" is not = correct either.  See the URL below where Chris clearly said, he has = guidance from the IETF and WG in the past to not include more than one = normative statement per requirement.  Thus Chris broke up the MarkT = recommendations and the break up has to stay.  Thus it would help if = Mark revisits Chris=92 text and fills in holes Mark thinks the text has = because we just cannot go back to Mark=92s original text that combines = multiple normative statements in one = requirement.

    I would like you to = please work with Mark, on the mailer, to accomplish = that. 

    <= div>

    I suspect that you = misunderstand Mark's text, which says that the text he suggested was = inadequate. 

    RFC 3704, resolving a = number of pages into a single sentence, recommends that if a packet uses = a stated source address and that source address was derived from a = stated upstream network, the packet should be directed to said upstream = network. The reason it would do so is that the upstream networks = presumably implement BCP 38, meaning that if it is directed to a = different upstream network it is likely to be dropped. 3704 goes on to = make suggestions regarding the implementation of exit routing. What Mark = is driving at is "implement exit routing; if one is given multiple = prefixes on different interfaces, physical or virtual, associate each = such prefix with its source interface in routing for the purposes of = source-address directed exit routing."

    Explanations and = dialog such as this are the reason I am asking you to TALK WITH MARK = about issues you see rather than talking with the chairs or simply = presuming that the working group outcome in Paris is brain-dead. The = outcome was, as near as I could tell, very sensible to the = operators.

    Another example for tighter text is related to 6RD-4.  = Why does 6RD-4 only say =93during an incremental migration period from 6rd to native = IPv6.=94    The SP could encounter a problem moving from 6rd to native IPv6 = and may want to revert back to 6rd.  Thus the 6RD-4 bullet should = cater to any migration from 6rd to native IPv6 or vice = versa.
     
    Further, when the CPE has different prefixes being used by = native IPV6 and 6rd, a host behind the CPE router has concurrent IPv6 = addresses being used (one IPv6 address from native IPv6 and another from = the 6rd prefix).  So what source-address does the host pick to send = a packet to a destination that is totally disjoint with the two prefixes = assigned to the CPE router?  Let=92s say the host picked a source = address from the 6rd prefix, then the CPE router ships the packet out = the 6rd tunnel instead of the higher preferred native IPv6 = network.  So how is the native IPv6 preference enforced by the CPE = router?  
     
    We also do not have consensus with the =93MUST=94 in = 6RD-4.  Current consensus is mostly towards changing the MUST to a = SHOULD.  I = also do not see any SP clamoring for 6rd sunsetting.  One SP in = France or France that has roughly million 6rd customers does not impress = me.  I am a person who gets impressed with 200 million customers = which is roughly what the cable broadband industry is deploying native = IPv6 for.  
     
    Hemant
     
     
    -----Original Message-----
    Sent: Tuesday, April 24, 2012 5:33 = PM
    Subject: Re: [v6ops] 6rd sunsetting requirements for = 6204-bis
     
    We discussed this at IETF 83, and you will find it in the = minutes when they come out. Mark and Ole asked for two things = (statements regarding 6rd and ds-lite), and the working group agreed to = one of them. We are not discussing a "boiling of the ocean", nor are we = discussing an infinite succession of new requirements. We are discussing = getting three no-brainer-class statements into the draft in a manner = that the discussants all recognize and agree to. The three statements = were clarified by hum in the meeting, and were each able to be stated in = a single sentence.
     
    I would ask the different actors in this discussion to please = behave in a courteous manner toward each other, and work together on = this as requested by the chairs at IETF 83.
    v6ops mailing = list


    = --Apple-Mail=_C7C3C62E-DBB8-4936-A695-3352F593EC40-- From SRS0=rfyu=DA=WPI.EDU=cra@srs.wpi.edu Thu Apr 26 06:14:12 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C964C21F86DB for ; Thu, 26 Apr 2012 06:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZLLWo24+LPxz for ; Thu, 26 Apr 2012 06:14:12 -0700 (PDT) Received: from MAIL1.WPI.EDU (MAIL1.WPI.EDU [130.215.36.91]) by ietfa.amsl.com (Postfix) with ESMTP id 0E2F021F86C2 for ; Thu, 26 Apr 2012 06:14:11 -0700 (PDT) Received: from MAIL1.WPI.EDU (MAIL1.WPI.EDU [130.215.36.91]) by MAIL1.WPI.EDU (8.14.5/8.14.5) with ESMTP id q3QDE9UW007367; Thu, 26 Apr 2012 09:14:09 -0400 X-DKIM: Sendmail DKIM Filter v2.8.3 MAIL1.WPI.EDU q3QDE9UW007367 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wpi.edu; s=_dkim; t=1335446049; bh=sBMDZ/e+BgGBNKxXH6wUGAR+PHT0Fd0S3YEA8Xwokio=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=OObvyIQu58VNxo/wTAC7tUjqcFmOufJ3aTvaj0YnLgasRt6qgtAvF0RseuhD+fo0Q 2FqhGKLwqFZGWnUJMgDGVJTD7QiHdLL4zGksJFzrqWnL1WuiJVkd+OoqPN8Z71Ixs6 sH8qbcRlhRzQ3TDIo8lBn5o5CIfNFjmtDnTmLrg8= Received: from SMTP.WPI.EDU (SMTP.WPI.EDU [130.215.36.186]) by MAIL1.WPI.EDU (8.14.5/8.14.5) with ESMTP id q3QDE7ql007321; Thu, 26 Apr 2012 09:14:07 -0400 Received: from angus.ind.WPI.EDU (ANGUS.IND.WPI.EDU [130.215.130.21]) by SMTP.WPI.EDU (8.14.4/8.14.4) with ESMTP id q3QDE45U005540; Thu, 26 Apr 2012 09:14:04 -0400 (envelope-from cra@WPI.EDU) Received: from angus.ind.WPI.EDU (angus.ind.WPI.EDU [127.0.0.1]) by angus.ind.WPI.EDU (8.14.2/8.14.2) with ESMTP id q3QDE55B013167; Thu, 26 Apr 2012 09:14:05 -0400 Received: (from cra@localhost) by angus.ind.WPI.EDU (8.14.2/8.14.2/Submit) id q3QDE33f013166; Thu, 26 Apr 2012 09:14:03 -0400 X-Authentication-Warning: angus.ind.WPI.EDU: cra set sender to cra@WPI.EDU using -f Date: Thu, 26 Apr 2012 09:14:03 -0400 From: Chuck Anderson To: Fred Baker Message-ID: <20120426131403.GE27538@angus.ind.WPI.EDU> References: <54469FB9-D118-4157-B9D6-8F52F7F96002@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54469FB9-D118-4157-B9D6-8F52F7F96002@cisco.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-ra-guard-implementation WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 13:15:41 -0000 On Sun, Apr 22, 2012 at 08:00:05PM +0200, Fred Baker wrote: > This is to initiate a two week working group last call of draft-ietf-v6ops-ra-guard-implementation. Please read it now. If you find nits (spelling errors, minor suggested wording changes, etc), comment to the authors; if you find greater issues, such as disagreeing with a statement or finding additional issues that need to be addressed, please post your comments to the list. > > We are looking specifically for comments on the importance of the document as well as its content. If you have read the document and believe it to be of operational utility, that is also an important comment to make. Support. This draft is definitely useful operationally. From bs7652@att.com Thu Apr 26 06:56:12 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30AC621F8319 for ; Thu, 26 Apr 2012 06:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-0.001, 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 o8nwl-K9J7Rh for ; Thu, 26 Apr 2012 06:56:09 -0700 (PDT) Received: from nbfkord-smmo03.seg.att.com (nbfkord-smmo03.seg.att.com [209.65.160.84]) by ietfa.amsl.com (Postfix) with ESMTP id BA16921F8585 for ; Thu, 26 Apr 2012 06:56:00 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo03.seg.att.com(mxl_mta-6.11.0-8) over TLS secured channel with ESMTP id 0f3599f4.0.1553541.00-348.4321445.nbfkord-smmo03.seg.att.com (envelope-from ); Thu, 26 Apr 2012 13:56:00 +0000 (UTC) X-MXL-Hash: 4f9953f03f6684bb-a24d57fa6e64821fb32f47b73cede28c92de4f62 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q3QDtxAR010044 for ; Thu, 26 Apr 2012 09:56:00 -0400 Received: from sflint03.pst.cso.att.com (sflint03.pst.cso.att.com [144.154.234.230]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q3QDtfnQ009425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 26 Apr 2012 09:55:55 -0400 Received: from GAALPA1MSGHUB9C.ITServices.sbc.com (gaalpa1msghub9c.itservices.sbc.com [130.8.36.89]) by sflint03.pst.cso.att.com (RSA Interceptor) for ; Thu, 26 Apr 2012 09:55:11 -0400 Received: from GAALPA1MSGUSR9N.ITServices.sbc.com ([169.254.6.49]) by GAALPA1MSGHUB9C.ITServices.sbc.com ([130.8.36.89]) with mapi id 14.01.0355.002; Thu, 26 Apr 2012 09:55:10 -0400 From: "STARK, BARBARA H" To: IPv6 Operations Thread-Topic: [v6ops] 6rd sunsetting requirements for 6204-bis Thread-Index: Ac0jtC/neSoP0qofQ9iUqDvVUKyQ4w== Date: Thu, 26 Apr 2012 13:55:10 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6110A6C53@GAALPA1MSGUSR9N.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.72.140] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E6110A6C53GAALPA1MSGUSR9NIT_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=1.0 c=1 a=8VfYpJJoovkA:10 a=J3__ZlzwMDAA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a=zZ] X-AnalysisOut: [iFLd_ChWDRYiju1rYA:9 a=-uoI7VpJle9VUdRzoQUA:7 a=CjuIK1q_8u] X-AnalysisOut: [gA:10 a=pYS6VsADCfgcJEnQ:21 a=uLI3iFzuvBkoPEzd:21 a=yMhMjl] X-AnalysisOut: [ubAAAA:8 a=SSmOFEACAAAA:8 a=NxSZYSQBSeN5RAQ6sf8A:7 a=gKO2H] X-AnalysisOut: [q4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10] Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 13:56:12 -0000 --_000_2D09D61DDFA73D4C884805CC7865E6110A6C53GAALPA1MSGUSR9NIT_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm feeling at a real disadvantage, not knowing what really happened at the= IETF meeting, and with trying to decipher everything I'm reading, some of = which was sent in private emails. I thought there used to be attempts to co= nfirm on the list agreements that were reached at IETF meetings. I guess no= t this time. And with every passing email, it's becoming more and more uncl= ear to me exactly what that agreement was. Since I don't know exactly what was or wasn't said or agreed to at the last= IETF, let me start by expressing my general philosophy around this documen= t and specifically around 6rd: 1. I need for this document to express CE Router requirements that wi= ll be sufficient to allow end users to establish IPv6 connectivity, both by= "native" IPv6 and 6rd. 2. This doesn't mean everything has to be automated. Requiring end us= ers to follow simple configuration instructions is acceptable. For example,= end users that have PPPoE connections are often provided instructions for = getting PPPoE up and running. 3. If omitting requirements for a piece of functionality means that t= he IPv6 connection might not work (either at all, or even not quite correct= ly), ever, no matter what configuration options exist, then that's a showst= opper and needs to be remedied. 4. If omitting requirements for a piece of functionality means that t= he user might have to manually do something to the configuration, this is l= ess than desirable but not a showstopper. Some number of calls to the help = desk are always to be expected when manual configuration is needed, and tha= t's not a wonderful thing. But loading up the CE router with potentially co= stly, complex, and half-baked functionality that isn't absolutely necessary= to achieving connectivity (and not necessary for a reasonable migration ex= perience, IMO) may also be less than desirable. As a technology person who = has recommended such useful features internally to my own company, only to = have them stripped out of the product when negotiations around pricing and = timeline occur, I truly do understand the desire to "gold plate" these devi= ces. It's easy for us technology people, because we can throw the recommend= ation out there without having to bear the cost. 5. Requiring support for simultaneous 6rd and native IPv6 connections= , and all that goes with that, may not be all that easy. It certainly seems= to me to add a fair amount of complexity. And the experience of the user w= ho might have to go into the CE router UI at some point in time, say 5 year= s from now, and spend 5 minutes turning off 6rd and bringing native IPv6 up= , and waiting another minute for the home network to renumber itself if nec= essary, just doesn't seem worthy of a "MUST" requirement to prevent such a = "horrible" experience. 6. I need 6rd support, so customers can use these CE routers to get = IPv6 connectivity on a 6rd-enabled access network. Now. 7. If we must have these transition statements, I would prefer that t= his simultaneous 6rd/native operation not be mandated. If the CE router doe= s it, then, yes, it needs to do all the rest, too. But *forcing* support fo= r automated transition into a low-end CE router in order to save the user 6= minutes of effort 5 years from now strikes me as the wrong thing to do. It= isn't *necessary*. What Remi suggests is also reasonable to me. Beautiful,= automated transition would certainly provide a lovelier user experience. B= ut it's not core to giving the user IPv6 connectivity. Providing the user t= he ability to only have either 6rd or native IPv6 operational at any given = time is acceptable. IMO. I would even be happy if transition were addressed= by a requirement that says something like "In the absence of a robust 6rd = to native IPv6 transition capability, the CE router MUST NOT allow simultan= eous 6rd and native IPv6 connections. Detailed requirements for implementin= g a robust transition capability are not addressed in this document." I realize some people will be upset by this stance, and I'm really sorry. F= or me, this isn't personal, and I, for one, believe that absolutely everyon= e on this thread is acting in good faith and expressing what they believe i= s right for the industry as a whole. We just happen to disagree as to what = is right. Barbara --_000_2D09D61DDFA73D4C884805CC7865E6110A6C53GAALPA1MSGUSR9NIT_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    I’m feeling at a real disadvantag= e, not knowing what really happened at the IETF meeting, and with trying to= decipher everything I’m reading, some of which was sent in private emails. I thought there used to be attempts to confirm on the list agreeme= nts that were reached at IETF meetings. I guess not this time. And with eve= ry passing email, it’s becoming more and more unclear to me exactly w= hat that agreement was.

     

    Since I don’t know exactly what w= as or wasn’t said or agreed to at the last IETF, let me start by expr= essing my general philosophy around this document and specifically around 6rd:

    1= .   &= nbsp;   I need for this document to exp= ress CE Router requirements that will be sufficient to allow end users to e= stablish IPv6 connectivity, both by “native” IPv6 and 6rd.

    2= .   &= nbsp;   This doesn’t mean everyth= ing has to be automated. Requiring end users to follow simple configuration= instructions is acceptable. For example, end users that have PPPoE connections are often provided instructions for getting PPPoE up and= running.

    3= .   &= nbsp;   If omitting requirements for a = piece of functionality means that the IPv6 connection might not work (eithe= r at all, or even not quite correctly), ever, no matter what configuration options exist, then that’s a showstopper and need= s to be remedied.

    4= .   &= nbsp;   If omitting requirements for a = piece of functionality means that the user might have to manually do someth= ing to the configuration, this is less than desirable but not a showstopper. Some number of calls to the help desk are always to= be expected when manual configuration is needed, and that’s not a wo= nderful thing. But loading up the CE router with potentially costly, comple= x, and half-baked functionality that isn’t absolutely necessary to achieving connectivity (and not necessary for a re= asonable migration experience, IMO) may also be less than desirable. As a t= echnology person who has recommended such useful features internally to my = own company, only to have them stripped out of the product when negotiations around pricing and timeline occur, I = truly do understand the desire to “gold plate” these devices. I= t’s easy for us technology people, because we can throw the recommend= ation out there without having to bear the cost.

    5= .   &= nbsp;   Requiring support for simultane= ous 6rd and native IPv6 connections, and all that goes with that, may not b= e all that easy. It certainly seems to me to add a fair amount of complexity. And the experience of the user who might have to go = into the CE router UI at some point in time, say 5 years from now, and spen= d 5 minutes turning off 6rd and bringing native IPv6 up, and waiting anothe= r minute for the home network to renumber itself if necessary, just doesn’t seem worthy of a “M= UST” requirement to prevent such a “horrible” experience.

    6= .   &= nbsp;    I need 6rd support, so cu= stomers can use these CE routers to get IPv6 connectivity on a 6rd-enabled = access network. Now.

    7= .   &= nbsp;   If we must have these transitio= n statements, I would prefer that this simultaneous 6rd/native operation no= t be mandated. If the CE router does it, then, yes, it needs to do all the rest, too. But *forcing* support for automated = transition into a low-end CE router in order to save the user 6 minutes of = effort 5 years from now strikes me as the wrong thing to do. It isn’t= *necessary*. What Remi suggests is also reasonable to me. Beautiful, automated transition would certainly = provide a lovelier user experience. But it’s not core to giving the u= ser IPv6 connectivity. Providing the user the ability to only have either 6= rd or native IPv6 operational at any given time is acceptable. IMO. I would even be happy if transition were addresse= d by a requirement that says something like “In the absence of a robu= st 6rd to native IPv6 transition capability, the CE router MUST NOT allow s= imultaneous 6rd and native IPv6 connections. Detailed requirements for implementing a robust transition capability are = not addressed in this document.”

     

    I realize some people will be upset by = this stance, and I’m really sorry. For me, this isn’t personal,= and I, for one, believe that absolutely everyone on this thread is acting in good faith and expressing what they believe is right for the ind= ustry as a whole. We just happen to disagree as to what is right.

    Barbara

    --_000_2D09D61DDFA73D4C884805CC7865E6110A6C53GAALPA1MSGUSR9NIT_-- From jhw@apple.com Thu Apr 26 10:38:36 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7856B21E8028 for ; Thu, 26 Apr 2012 10:38:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id asIBwFPEHInx for ; Thu, 26 Apr 2012 10:38:36 -0700 (PDT) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 0796621E801E for ; Thu, 26 Apr 2012 10:38:36 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay17.apple.com ([17.128.113.18]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0M3300FHJKXGCJS2@mail-out.apple.com> for v6ops@ietf.org; Thu, 26 Apr 2012 10:38:20 -0700 (PDT) X-AuditID: 11807112-b7f826d000004103-e0-4f99880c4d06 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 relay17.apple.com (Apple SCV relay) with SMTP id 21.D1.16643.C08899F4; Thu, 26 Apr 2012 10:38:20 -0700 (PDT) From: james woodyatt In-reply-to: <54469FB9-D118-4157-B9D6-8F52F7F96002@cisco.com> Date: Thu, 26 Apr 2012 10:38:20 -0700 Message-id: References: <54469FB9-D118-4157-B9D6-8F52F7F96002@cisco.com> To: v6ops@ietf.org X-Mailer: Apple Mail (2.1455) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrELMWRmVeSWpSXmKPExsUieJDXQZenY6a/Qe9ECYu3l18wWpw+tpfZ gcljyZKfTB5fLn9mC2CK4rJJSc3JLEst0rdL4MrYe/EHW8ExtoqlvYfZGxiXsHYxcnJICJhI rJp2lQ3CFpO4cG89kM3FISQwm0ni3qLvYAlmAS2JG/9eMoHYvAJ6EvMvrQGLCws4SdxcsYgd xGYTUJH4dvkuWA2ngK1E70OIOIuAqsSb2c+A6jmA5rhJPP0nBTFSW2LZwtfMECNtJJ7faQUr EQKyb3d7gYRFBIQkdjxrYoI4TVbi86O/LBMY+WchOWgWkoNmIZm6gJF5FaNgUWpOYqWhuV5i QUFOql5yfu4mRlDINRQK7WC8v0vvEKMAB6MSD+/PzJn+QqyJZcWVuYcYJTiYlUR4LzEAhXhT EiurUovy44tKc1KLDzFKc7AoifOqNc7wFxJITyxJzU5NLUgtgskycXBKNTD6L/bINFReNEU2 7v5p7lIFhxO+6oK2SwQnLpCZojKTXTn5zq2Yh/ExblIV7UvO+soyz+A2mfZsJf85iwj95MvH 9ZZNn6LFxscSxHtwo5fT1IszGkwqP0pPlhBgCSiwMPhq37t+ysGfMQs9ilacUKy7GPOoqXOe 0ZmCjHTjB7zWC16KuJ5dOUWJpTgj0VCLuag4EQBEIQG7NQIAAA== Cc: "v6ops-chairs@tools.ietf.org Chairs" Subject: Re: [v6ops] draft-ietf-v6ops-ra-guard-implementation WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 17:38:36 -0000 On Apr 22, 2012, at 11:00 , Fred Baker wrote: > This is to initiate a two week working group last call of draft-ietf-v6ops-ra-guard-implementation. Please read it now. If you find nits (spelling errors, minor suggested wording changes, etc), comment to the authors; if you find greater issues, such as disagreeing with a statement or finding additional issues that need to be addressed, please post your comments to the list. I share some of Mr. Zeeb's concerns, but I'm willing to support the draft-- provided that it is updated with an informative reference to "An uniform format for IPv6 extension headers" [RFC6564] in the first numbered paragraph describing the filtering rules in section 3. -- james woodyatt member of technical staff, core os networking From ichiroumakino@gmail.com Thu Apr 26 11:01:56 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35FD321F86A0 for ; Thu, 26 Apr 2012 11:01:56 -0700 (PDT) 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.100, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qwsdaxjXYJaY for ; Thu, 26 Apr 2012 11:01:55 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3DCAB21F86A3 for ; Thu, 26 Apr 2012 11:01:55 -0700 (PDT) Received: by werb10 with SMTP id b10so1147864wer.31 for ; Thu, 26 Apr 2012 11:01:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=5ez0PGhWwoxPTI0GsmadNHLsdm2THpMX+uFg1OgmigI=; b=j96apFwfRWOG2FFwQRQVA80bOUIUHUdMmoEto/ATXPE/bYd1TE7jpogS8dC91ywFeN eC0nA745kihIortk4GWDjMHtOawAn7tB75biEO/lPMb4kPXq1o6efLHbD++iVNxQBFJV aSE2wb+Qs+J+90l/t7/nqbIRjOpV4wIl1ztIQMMq0RqjwcQ93pgqrzJTaZjW7Z6JOBCx 6JX2D3uhRjwWmEOSNxcRCclKtzQfTkw2teEmwDOH6vTFMIQfRzW/9d10Uu+c5wqejYfJ E8e/2dnXDyl5P9uywop9OtLQk3RiBVHJwMF0R72So8IVku6K9qYGxC7TO8mqmjFHKaWH AbTQ== Received: by 10.180.77.4 with SMTP id o4mr18933318wiw.17.1335463314443; Thu, 26 Apr 2012 11:01:54 -0700 (PDT) Received: from dhcp-10-61-99-2.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id b3sm46195911wib.4.2012.04.26.11.01.52 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 26 Apr 2012 11:01:53 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6110A6C53@GAALPA1MSGUSR9N.ITServices.sbc.com> Date: Thu, 26 Apr 2012 20:01:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1F0A766F-BB9F-438E-A286-6AFBA8E3D693@employees.org> References: <2D09D61DDFA73D4C884805CC7865E6110A6C53@GAALPA1MSGUSR9N.ITServices.sbc.com> To: "STARK, BARBARA H" X-Mailer: Apple Mail (2.1257) Cc: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 18:01:56 -0000 Barbara, [...] did you see the v6ops presentation at = http://tools.ietf.org/agenda/83/slides/slides-83-v6ops-13.pdf > IMO. I would even be happy if transition were addressed by a = requirement that says something like =93In the absence of a robust 6rd = to native IPv6 transition capability, the CE router MUST NOT allow = simultaneous 6rd and native IPv6 connections. Detailed requirements for = implementing a robust transition capability are not addressed in this = document.=94 you are proposing "Forced single homing". that is quite complex to = implement. you are creating a dependency between IPv4 and IPv6 on the = interface. how long do you try initiating native IPv6 before allowing = 6rd to come up? what do you do when native IPv6 appears on the WAN? I think the opposite is the case, that implementing the simple = multi-homing solution (choose exit based on source) is much simpler than = trying to get "forced single homing" correctly. in addition this scheme is much more generic, it works with multiple = native IPv6 connections too. cheers, Ole= From ichiroumakino@gmail.com Thu Apr 26 11:02:47 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD5921E80C8 for ; Thu, 26 Apr 2012 11:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.091 X-Spam-Level: X-Spam-Status: No, score=-3.091 tagged_above=-999 required=5 tests=[AWL=0.208, 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 WC8fs0sFPGn1 for ; Thu, 26 Apr 2012 11:02:46 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3BBFD21E809F for ; Thu, 26 Apr 2012 11:02:46 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so984764wgb.13 for ; Thu, 26 Apr 2012 11:02:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=ovEQjJwEzj8771egTNtGid1OSsTJke5whFnF61INTuM=; b=kRIATR7WIauFBQ1TfJbqeozf0zbKxMZEovDtDFZcgfeU3nbCL8TixM0STNOEBR3sOp gu9KFDdo/i9inBlndvFdtzzW27YDEzNRgbqULE/oXHcbFeg4eYogIq4M5F7A1i35OQZt SrHcW7VT8qVpt+/aaUKXsGHGewEstSZYIxTDIW1C/5iR0YSqvWgBDoFMHlwYUbpY29Cg Ib4VejF53XbWPfZcn1EZ8QU4RTnxwUWNTzOJO3OAehOIIxkB23nyJUEhT+DObKxToXAF GTPC3Y5dr4egXqMs408R3Fl8x3tWwCL6ugLwRizkMZ/7Zu4A1/YAIkpvfsNRupYLqAyD U2mg== Received: by 10.180.102.100 with SMTP id fn4mr18903502wib.1.1335463365305; Thu, 26 Apr 2012 11:02:45 -0700 (PDT) Received: from dhcp-10-61-99-2.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id b3sm46195911wib.4.2012.04.26.11.02.43 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 26 Apr 2012 11:02:44 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6110A6C53@GAALPA1MSGUSR9N.ITServices.sbc.com> Date: Thu, 26 Apr 2012 20:02:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <18172371-4C87-4CA6-A861-B1FB772C3D9D@employees.org> References: <2D09D61DDFA73D4C884805CC7865E6110A6C53@GAALPA1MSGUSR9N.ITServices.sbc.com> To: "STARK, BARBARA H" X-Mailer: Apple Mail (2.1257) Cc: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 18:02:47 -0000 Barbara, > 6. I need 6rd support, so customers can use these CE routers to = get IPv6 connectivity on a 6rd-enabled access network. Now. don't you have that already? or how is that not RFC6204 + RFC5969? cheers, Ole From bs7652@att.com Thu Apr 26 11:08:18 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60B7B21E8089 for ; Thu, 26 Apr 2012 11:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.449 X-Spam-Level: X-Spam-Status: No, score=-104.449 tagged_above=-999 required=5 tests=[AWL=-2.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0XEZeMjMbQ40 for ; Thu, 26 Apr 2012 11:08:18 -0700 (PDT) Received: from nbfkord-smmo08.seg.att.com (nbfkord-smmo08.seg.att.com [209.65.160.95]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB2F21F86D9 for ; Thu, 26 Apr 2012 11:08:16 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo08.seg.att.com) by nbfkord-smmo08.seg.att.com(mxl_mta-6.11.0-8) with ESMTP id 01f899f4.2aaae022c940.1491817.00-558.3090010.nbfkord-smmo08.seg.att.com (envelope-from ); Thu, 26 Apr 2012 18:08:16 +0000 (UTC) X-MXL-Hash: 4f998f1068a97ee4-5e4679f2820c734597ed32539bf129f39e440f26 Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo08.seg.att.com(mxl_mta-6.11.0-8) over TLS secured channel with ESMTP id d0f899f4.0.1491794.00-366.3089936.nbfkord-smmo08.seg.att.com (envelope-from ); Thu, 26 Apr 2012 18:08:14 +0000 (UTC) X-MXL-Hash: 4f998f0e74be1b1a-f57adf1b5dd064d5c5bf21139608daec9bc076e8 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q3QI8BdC024640; Thu, 26 Apr 2012 14:08:13 -0400 Received: from sflint04.pst.cso.att.com (sflint04.pst.cso.att.com [144.154.234.231]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q3QI7tTf023812 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Apr 2012 14:08:05 -0400 Received: from GAALPA1MSGHUB9F.ITServices.sbc.com (gaalpa1msghub9f.itservices.sbc.com [130.8.36.92]) by sflint04.pst.cso.att.com (RSA Interceptor); Thu, 26 Apr 2012 14:07:39 -0400 Received: from GAALPA1MSGUSR9N.ITServices.sbc.com ([169.254.6.49]) by GAALPA1MSGHUB9F.ITServices.sbc.com ([130.8.36.92]) with mapi id 14.01.0355.002; Thu, 26 Apr 2012 14:07:38 -0400 From: "STARK, BARBARA H" To: =?iso-8859-1?Q?Ole_Tr=F8an?= Thread-Topic: [v6ops] 6rd sunsetting requirements for 6204-bis Thread-Index: Ac0jtC/neSoP0qofQ9iUqDvVUKyQ4wARB4KAAAhDrQA= Date: Thu, 26 Apr 2012 18:07:37 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6110A6F80@GAALPA1MSGUSR9N.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6110A6C53@GAALPA1MSGUSR9N.ITServices.sbc.com> <18172371-4C87-4CA6-A861-B1FB772C3D9D@employees.org> In-Reply-To: <18172371-4C87-4CA6-A861-B1FB772C3D9D@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.72.140] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=1.0 c=1 a=8VfYpJJoovkA:10 a=J3__ZlzwMDAA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=Qs8R1XBwmid1qB] X-AnalysisOut: [FB/a8mmA==:17 a=S-bRlANFg4PbFUZexXAA:9 a=WdfFjdGPnER8mgTBy] X-AnalysisOut: [owA:7 a=wPNLvfGTeEIA:10] Cc: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 18:08:18 -0000 > Barbara, >=20 > > 6. I need 6rd support, so customers can use these CE routers to = get IPv6 > connectivity on a 6rd-enabled access network. Now. >=20 > don't you have that already? or how is that not RFC6204 + RFC5969? >=20 No, it's not RFC6204 + RFC5969. I need: 6RD-2: If the IPv6 CE router is capable of automated configuration of IPv4 through IPCP (i.e., over a PPP connection), it MUST support user-entered configuration of 6rd. 6RD-3: If the CE router supports configuration mechanisms other than the 6rd DHCPv4 Option 212 (user-entered, TR-69, etc.), the CE router MUST support 6rd in "hub and spoke" mode. 6rd in "hub and spoke" requires all IPv6 traffic to go to the 6rd Border Relay. In effect, this requirement removes the "direct connect to 6rd" route defined in Section 7.1.1 of [RFC5969]. From bs7652@att.com Thu Apr 26 11:31:13 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 984FF21E8127 for ; Thu, 26 Apr 2012 11:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.732 X-Spam-Level: X-Spam-Status: No, score=-103.732 tagged_above=-999 required=5 tests=[AWL=-1.433, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0nP8MAK5aFqM for ; Thu, 26 Apr 2012 11:31:12 -0700 (PDT) Received: from nbfkord-smmo08.seg.att.com (nbfkord-smmo08.seg.att.com [209.65.160.95]) by ietfa.amsl.com (Postfix) with ESMTP id 3B90121E808D for ; Thu, 26 Apr 2012 11:31:08 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo08.seg.att.com) by nbfkord-smmo08.seg.att.com(mxl_mta-6.11.0-8) with ESMTP id c64999f4.50275940.1499835.00-558.3112539.nbfkord-smmo08.seg.att.com (envelope-from ); Thu, 26 Apr 2012 18:31:08 +0000 (UTC) X-MXL-Hash: 4f99946c29a933ee-1adf3e6eaa8950ef755e870e3bc3315d98b9d167 Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo08.seg.att.com(mxl_mta-6.11.0-8) over TLS secured channel with ESMTP id 464999f4.0.1499742.00-428.3112281.nbfkord-smmo08.seg.att.com (envelope-from ); Thu, 26 Apr 2012 18:31:01 +0000 (UTC) X-MXL-Hash: 4f9994652c905be6-b5f865d19c098c6896ee8dc3348a0e62ade2cbad Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q3QIUrSr027548; Thu, 26 Apr 2012 14:31:00 -0400 Received: from sflint03.pst.cso.att.com (sflint03.pst.cso.att.com [144.154.234.230]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q3QIUnZP027393 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Apr 2012 14:30:51 -0400 Received: from GAALPA1MSGHUB9D.ITServices.sbc.com (gaalpa1msghub9d.itservices.sbc.com [130.8.36.90]) by sflint03.pst.cso.att.com (RSA Interceptor); Thu, 26 Apr 2012 14:29:32 -0400 Received: from GAALPA1MSGUSR9N.ITServices.sbc.com ([169.254.6.49]) by GAALPA1MSGHUB9D.ITServices.sbc.com ([130.8.36.90]) with mapi id 14.01.0355.002; Thu, 26 Apr 2012 14:29:32 -0400 From: "STARK, BARBARA H" To: =?iso-8859-1?Q?Ole_Tr=F8an?= Thread-Topic: [v6ops] 6rd sunsetting requirements for 6204-bis Thread-Index: Ac0jtC/neSoP0qofQ9iUqDvVUKyQ4wAQ/3aAAAgsVwA= Date: Thu, 26 Apr 2012 18:29:30 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6110A6FAC@GAALPA1MSGUSR9N.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6110A6C53@GAALPA1MSGUSR9N.ITServices.sbc.com> <1F0A766F-BB9F-438E-A286-6AFBA8E3D693@employees.org> In-Reply-To: <1F0A766F-BB9F-438E-A286-6AFBA8E3D693@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.72.140] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=1.0 c=1 a=8VfYpJJoovkA:10 a=J3__ZlzwMDAA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=Qs8R1XBwmid1qB] X-AnalysisOut: [FB/a8mmA==:17 a=8bJtwierEvrzQejJI0kA:9 a=wPNLvfGTeEIA:10] Cc: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 18:31:13 -0000 > you are proposing "Forced single homing". that is quite complex to > implement. you are creating a dependency between IPv4 and IPv6 on the > interface. how long do you try initiating native IPv6 before allowing 6rd= to > come up? > what do you do when native IPv6 appears on the WAN? >=20 > I think the opposite is the case, that implementing the simple multi-homi= ng > solution (choose exit based on source) is much simpler than trying to get > "forced single homing" correctly. >=20 > in addition this scheme is much more generic, it works with multiple nati= ve > IPv6 connections too. If 6rd is enabled, then don't even try native IPv6. Disable it. If native I= Pv6 is enabled, then 6rd is not enabled. There is no "try initiating IPv6 b= efore allowing 6rd to come up". If 6rd is enabled, and not configured or th= e BR isn't there, then there is no IPv6. When native IPv6 appears on the WA= N, nothing happens until 6rd is disabled and native IPv6 is enabled. This s= cheme works across all devices that are not designed to support multiple IP= v6 connections. It's very simple. Very Boolean. I'm not saying CE routers should have to do this and be precluded from impl= ementing auto-migration. I'm saying exactly the opposite -- CE routers shou= ld not be required to support multiple WAN IPv6 interfaces. Auto-migration = is great. But manual config isn't so horrible that it needs to be forbidden= . And yes, I know all about parents, friends and relatives who can't even do = this simple a configuration change. But I don't need 100% of CE routers to = be designed to meet the needs of those people. TR-069 management exists on = most of the CE routers my company ships. We can do that configuration toggl= e remotely, so it looks auto-migrated to the customer. This would allow us = great flexibility in rolling out the native IPv6, by enabling a few at a ti= me. Simultaneous 6rd and native IPv6 is not required for appearing-to-the-u= ser-to-be-auto-migrated 6rd to IPv6 in TR-069-managed CE routers. The peop= le who don't choose to go with our routers tend to be more tech savvy, and = understand that with freedom from SP-management comes a requirement to be w= illing to do some of your own configuration. I'm not going to tell these te= ch savvy people that their CE router must support auto-migration in order t= o work with our 6rd service and subsequently with our native IPv6 service. = That would be inaccurate. The CE router needs to support IPv6 (and, yes, RF= C 6204 does a great job describing that). And it needs to support 6rd, incl= uding 6RD-2 and 6RD-3, which are not covered in RFC 5969. Barbara From kkumar@google.com Thu Apr 26 11:56:20 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FB2821F8649 for ; Thu, 26 Apr 2012 11:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.376 X-Spam-Level: X-Spam-Status: No, score=-102.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, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3vBv4zgC7cXz for ; Thu, 26 Apr 2012 11:56:19 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 97F6C21F860B for ; Thu, 26 Apr 2012 11:56:17 -0700 (PDT) Received: by mail-lpp01m010-f44.google.com with SMTP id j5so1310411lag.31 for ; Thu, 26 Apr 2012 11:56:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=FLCYncig9cvtHH2QNSDu6/NBvV4tsCzj+RoLkfpVaIw=; b=G3FqdTzWyL37z60g6zuTIrK+bi8Lo8mKnf95xK80PniNuCD6XV0nbwXPbzHgsJ/x4S 3h9mrD1tZndCakxbC8QWJte2+Niqq5JJYedjSVzYEoSVga5SxmankPPAf/5AEjo3iOYL +Wx+VFQ4fmnZYK+dOZBkJqOBvFRQ5pzOjruHMga7I2KpGtU2vH13CfptbclEJuKNPC+l Og+mpsKaOgMMuAr3LGgsQIEKi0+0STQt30M1Nx9XMMSQsz87JoOw1DEp9huorJFAm2ps OJCCEm4m1b8WJbO+94TFiA1T2fOhVnt7mKrBSrUfE15gTGJOS6PGlYmqtbr2AO9hTJ4q pGHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=FLCYncig9cvtHH2QNSDu6/NBvV4tsCzj+RoLkfpVaIw=; b=cZzsE3mGhkpdM/BuyPMnNl/1PS2LA4hzFKJdYNc9GHPaJ+qbyoxU9k+/4lfmN+Jz4G hXYRhgJgirXpLIW5Tptow+nOURsDsPaRF75uw6bcAssJFB7opmfB9zj4/3BErUXqrZK3 ZmG+9p9xbmrDv8kuW0bjXMgvG3t3d8CJatZDOMYrSuXrW5jD7vQ+5QhPU90eb7Lt+EwV CuQQJtV+NZhEhln608GNbW4iQQ58Q4+4sCPCZ9mF6/W9YpClL3eJRdA26P40b7pg7gA6 UPTk3nW8NsmDu8ffE9VhfOJNWzb6SIS2MEOPwWhIw+6nz/s/PavcmFuTUPt5uHNMtzH4 yqkA== Received: by 10.112.40.5 with SMTP id t5mr3900368lbk.55.1335466577259; Thu, 26 Apr 2012 11:56:17 -0700 (PDT) Received: by 10.112.40.5 with SMTP id t5mr3900359lbk.55.1335466577092; Thu, 26 Apr 2012 11:56:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.60.98 with HTTP; Thu, 26 Apr 2012 11:55:56 -0700 (PDT) In-Reply-To: <54469FB9-D118-4157-B9D6-8F52F7F96002@cisco.com> References: <54469FB9-D118-4157-B9D6-8F52F7F96002@cisco.com> From: KK Date: Thu, 26 Apr 2012 11:55:56 -0700 Message-ID: To: Fred Baker Content-Type: multipart/alternative; boundary=485b390f7b9eefe19504be998a21 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlKyE0kw0rmbz/EmZH0hqY4HQNvf4uGGIM1KglCKaIfWb2wVPJA/hg40W6I2tenbmNMpbPDGNcp5MPhHM/ktwapyHaQWoaCWJS3OFXPDYajMqasjquek8Rspta0z5POFW8M7Zi3 Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-ra-guard-implementation WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 18:58:04 -0000 --485b390f7b9eefe19504be998a21 Content-Type: text/plain; charset=ISO-8859-1 I believe that this doc is very useful from an operational point of view. I support. On Sun, Apr 22, 2012 at 11:00 AM, Fred Baker wrote: > This is to initiate a two week working group last call of > draft-ietf-v6ops-ra-guard-implementation. Please read it now. If you find > nits (spelling errors, minor suggested wording changes, etc), comment to > the authors; if you find greater issues, such as disagreeing with a > statement or finding additional issues that need to be addressed, please > post your comments to the list. > > We are looking specifically for comments on the importance of the document > as well as its content. If you have read the document and believe it to be > of operational utility, that is also an important comment to make. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --485b390f7b9eefe19504be998a21 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I believe that this doc is very useful from an operational point of view. I= support.

    On Sun, Apr 22, 2012 at 11:00 = AM, Fred Baker <fred= @cisco.com> wrote:
    This is= to initiate a two week working group last call of draft-ietf-v6ops-ra-guar= d-implementation. Please read it now. If you find nits (spelling errors, mi= nor suggested=A0wording changes, etc), comment to the authors; if you find = greater issues, such as disagreeing with a statement or finding additional = issues that need to be addressed,=A0please post your comments to the list.<= /font>

    <= /div>
    We are = looking specifically for comments on the importance of the document as well= as its content. If you have read the document and believe it to be of oper= ational=A0utility, that is also an important comment to make.

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


    --485b390f7b9eefe19504be998a21-- From shemant@cisco.com Thu Apr 26 12:40:30 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29FDA21E8185 for ; Thu, 26 Apr 2012 12:40:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.148 X-Spam-Level: X-Spam-Status: No, score=-10.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_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vytpSQ31c58c for ; Thu, 26 Apr 2012 12:40:24 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 6382221E817D for ; Thu, 26 Apr 2012 12:40:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=34006; q=dns/txt; s=iport; t=1335469224; x=1336678824; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=Ckz+OlTTZGjWb9lEqq9zvmv4yQK/qewMYT4+Rl4ceEM=; b=jEQYg45BW9XJLzkNz/TQs/SLPkMRa19z60e7HiQVF7C7ujNZJ9uVZ05e jo3MCDulFA0wThJOvLa8Ct9KleNH63zxoXYAl49Uq2VGasOMguYRvkXxR Xx3aRRkNC8HjTG023QYJdyNG0sZ3C9srlvsJo0W1mkMJXvoOZ0dr2CGmU Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAO+jmU+tJV2d/2dsb2JhbABFgkavKoEHggkBAQEEAQEBDwEJEQM+CwwEAgEIEQQBAQsGEAEGAQYBJh8JCAEBBAESCAEZh2sLmk2gIYsChQBjBIhjm3GBaYMGgT4 X-IronPort-AV: E=Sophos;i="4.75,487,1330905600"; d="scan'208,217";a="78220572" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP; 26 Apr 2012 19:40:23 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id q3QJeN4b018473; Thu, 26 Apr 2012 19:40:23 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); Thu, 26 Apr 2012 14:40:23 -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_01CD23E4.6B744BE2" Date: Thu, 26 Apr 2012 14:40:21 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C30483801D@XMB-RCD-109.cisco.com> In-Reply-To: <639FE0F2-ECD6-4C83-BB1F-9A9676ABCECB@townsley.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] 6rd sunsetting requirements (version 2) Thread-Index: Ac0jqwNMpXRKfiA1TuWBVlS4UsAAxgAN9iIw References: <5B6B2B64C9FE2A489045EEEADDAFF2C30483722C@XMB-RCD-109.cisco.com><4F95A3D9.1010100@viagenie.ca><5B6B2B64C9FE2A489045EEEADDAFF2C304837261@XMB-RCD-109.cisco.com><4F95ABA0.8090601@viagenie.ca><5B6B2B64C9FE2A489045EEEADDAFF2C304837272@XMB-RCD-109.cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C30483747A@XMB-RCD-109.cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C3048378BB@XMB-RCD-109.cisco.com><42D0E71D-8599-44C6-91D4-B059A276EB6A@cisco.com><379ECFD4-C696-4B86-9DCA-75B0887C4370@townsley.net> <639FE0F2-ECD6-4C83-BB1F-9A9676ABCECB@townsley.net> From: "Hemant Singh (shemant)" To: "Mark Townsley" , "IPv6 Operations" X-OriginalArrivalTime: 26 Apr 2012 19:40:23.0078 (UTC) FILETIME=[6BBE9460:01CD23E4] Subject: Re: [v6ops] 6rd sunsetting requirements (version 2) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 19:40:30 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD23E4.6B744BE2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I did like the context of 6rd sunsetting with the original 6RD-4 because if we do not provide context, folks may ask to the mailer 6 months or two years from now as to why two concurrent tech? =20 6RD-4: A CE router MUST allow 6rd virtual and IPv6 native WAN interfaces to be active simultaneously such as when the CPE router is sunsetting 6rd or reverting the 6rd sunsetting. =20 Tweaked 6RD-5 a little. =20 6RD-5: Each packet sent out the WAN interface via a 6rd or native IPv6 interface MUST be directed such that its source IPv6 address is derived from the delegated prefix associated with the egress interface. [section 4.3 of BCP 84, RFC 3704]. =20 Hemant =20 From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Mark Townsley Sent: Thursday, April 26, 2012 8:49 AM To: Chris Donley; IPv6 Operations Subject: [v6ops] 6rd sunsetting requirements (version 2) =20 =20 Chris, =20 Here is a new set of requirements based on your feedback. In this version, I adopted some but not all of what you were asking for. Specifically, =20 - I adopted your 6RD-7 text verbatim (though I still personally prefer using the term "equal" vs. "tie")=20 =20 - I changed my text that specified only that delegated prefixes could be identical, to say that they could be identical as well as different. =20 - I couldn't come up with any other way to clarify "allow" not meaning "always" without complicating the text in 6RD-4.=20 =20 - I did not include text that suggested whether having one active interface vs. two would be more or less a common case. =20 We now have 4 requirements instead of 3. I am still OK with my original 3, but if you and the WG prefer these 4 that is fine by me as well.=20 =20 - Mark =20 6RD-4: A CE router MUST allow 6rd virtual and IPv6 native WAN interfaces to be active simultaneously.=20 6RD-5: Each packet sent on a 6rd or native WAN interface MUST be directed such that its source IP address is derived from the delegated prefix associated with the upstream network the WAN interface is connected to [section 4.3 of BCP 84, RFC 3704]. 6RD-6: The CE router MUST allow different or identical delegated prefixes to be configured via each WAN interface. =20 6RD-7 In the event that forwarding rules produce a tie between 6rd and native IPv6, by default, the IPv6 CE Router MUST prefer native IPv6. =20 =20 On Apr 25, 2012, at 12:10 PM, Mark Townsley wrote: =20 Whittled down to one sentence each, here are three requirements necessary in order to support incremental migration from 6rd to native IPv6:=20 =20 6RD-4: A CE router MUST allow 6rd virtual and IPv6 native WAN interfaces to be active simultaneously.=20 6RD-5: Each packet sent on a 6rd or native WAN interface MUST be directed such that its source IP address is derived from the delegated prefix associated with the upstream network the WAN interface is connected to [section 4.3 of BCP 84, RFC 3704]. 6RD-6: The CE router MUST allow identical or overlapping delegated prefixes for each WAN interface with a preference for native IPv6 in the event forwarding rules would have otherwise directed a packet to be sent equally via 6rd or native IPv6. =20 =20 Summary: The first requirement says 6rd and native must coexist, the second ensures that packets are directed such that they are not dropped by the upstream network, and the third ensures native is chosen over 6rd in the event the paths are otherwise equal.=20 =20 - Mark =20 =20 On Apr 25, 2012, at 5:23 AM, Fred Baker wrote: =20 On Apr 25, 2012, at 5:05 AM, Hemant Singh (shemant) wrote: Fred, =20 Appreciate the quick reply. In MarkT's comments to Chris that Chris did not follow the Chairs' recommendation, the statement is not quite correct. Additionally MarkT saying to the mailer that "He (Chris) decided to throw them in the trash" is not correct either. See the URL below where Chris clearly said, he has guidance from the IETF and WG in the past to not include more than one normative statement per requirement. Thus Chris broke up the MarkT recommendations and the break up has to stay. Thus it would help if Mark revisits Chris' text and fills in holes Mark thinks the text has because we just cannot go back to Mark's original text that combines multiple normative statements in one requirement. =20 I would like you to please work with Mark, on the mailer, to accomplish that.=20 =20 http://www.ietf.org/mail-archive/web/v6ops/current/msg12705.html Moving on, the requirements provided by MarkT could use tighter text. For example here is a portion of text provided to us to add. =20 "6RD-5: The CE router MUST associate delegated prefixes with the WAN interface(s)" =20 The CPE WAN interface can be unnumbered with only an IPv6 link-local address and thus the CPE WAN does not have a global IPv6 address. In such an unnumbered model, the CPE uses an address from the PD on a virtual network interface to source packets out the WAN such as ICMPv6 errors. I am away from work tomorrow but we can certainly try and close any text two days from now including any WebEx phone call between Mark and us authors of rfc6204bis.=20 =20 I suspect that you misunderstand Mark's text, which says that the text he suggested was inadequate.=20 =20 RFC 3704, resolving a number of pages into a single sentence, recommends that if a packet uses a stated source address and that source address was derived from a stated upstream network, the packet should be directed to said upstream network. The reason it would do so is that the upstream networks presumably implement BCP 38, meaning that if it is directed to a different upstream network it is likely to be dropped. 3704 goes on to make suggestions regarding the implementation of exit routing. What Mark is driving at is "implement exit routing; if one is given multiple prefixes on different interfaces, physical or virtual, associate each such prefix with its source interface in routing for the purposes of source-address directed exit routing." =20 Explanations and dialog such as this are the reason I am asking you to TALK WITH MARK about issues you see rather than talking with the chairs or simply presuming that the working group outcome in Paris is brain-dead. The outcome was, as near as I could tell, very sensible to the operators. =20 Another example for tighter text is related to 6RD-4. Why does 6RD-4 only say "during an incremental migration period from 6rd to native IPv6." The SP could encounter a problem moving from 6rd to native IPv6 and may want to revert back to 6rd. Thus the 6RD-4 bullet should cater to any migration from 6rd to native IPv6 or vice versa. =20 Further, when the CPE has different prefixes being used by native IPV6 and 6rd, a host behind the CPE router has concurrent IPv6 addresses being used (one IPv6 address from native IPv6 and another from the 6rd prefix). So what source-address does the host pick to send a packet to a destination that is totally disjoint with the two prefixes assigned to the CPE router? Let's say the host picked a source address from the 6rd prefix, then the CPE router ships the packet out the 6rd tunnel instead of the higher preferred native IPv6 network. So how is the native IPv6 preference enforced by the CPE router? =20 =20 We also do not have consensus with the "MUST" in 6RD-4. Current consensus is mostly towards changing the MUST to a SHOULD. I also do not see any SP clamoring for 6rd sunsetting. One SP in France or France that has roughly million 6rd customers does not impress me. I am a person who gets impressed with 200 million customers which is roughly what the cable broadband industry is deploying native IPv6 for. =20 =20 Hemant =20 =20 -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Fred Baker (fred) Sent: Tuesday, April 24, 2012 5:33 PM To: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis =20 We discussed this at IETF 83, and you will find it in the minutes when they come out. Mark and Ole asked for two things (statements regarding 6rd and ds-lite), and the working group agreed to one of them. We are not discussing a "boiling of the ocean", nor are we discussing an infinite succession of new requirements. We are discussing getting three no-brainer-class statements into the draft in a manner that the discussants all recognize and agree to. The three statements were clarified by hum in the meeting, and were each able to be stated in a single sentence. =20 I would ask the different actors in this discussion to please behave in a courteous manner toward each other, and work together on this as requested by the chairs at IETF 83. _______________________________________________ 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_01CD23E4.6B744BE2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    I did like the context of 6rd sunsetting with the original 6RD-4 = because if we do not provide context, folks may ask to the mailer 6 = months or two years from now as to why two concurrent = tech?

     

    6RD-4: A CE router MUST allow 6rd virtual and IPv6 native WAN = interfaces to be active simultaneously such as when the CPE router = is sunsetting 6rd or reverting the 6rd = sunsetting.

     

    Tweaked 6RD-5 a little.

     

    6RD-5: Each packet sent out the WAN interface via a 6rd or = native IPv6 interface MUST be directed such that its = source IPv6 address is derived from the delegated prefix = associated with the egress interface. [section 4.3 of BCP 84, RFC = 3704].

     

    Hemant

     

    From:= = v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of = Mark Townsley
    Sent: Thursday, April 26, 2012 8:49 = AM
    To: Chris Donley; IPv6 Operations
    Subject: = [v6ops] 6rd sunsetting requirements (version = 2)

     

     

    Chris,

     

    Here is a new set of requirements based on your = feedback. In this version, I adopted some but not all of what you were = asking for. Specifically,

     

    - = I adopted your 6RD-7 text verbatim (though I still personally prefer = using the term "equal" vs. = "tie") 

     

    - = I changed my text that specified only that delegated prefixes could be = identical, to say that they could be identical as well as = different.

     

    - = I couldn't come up with any other way to clarify "allow" not = meaning "always" without complicating the text in = 6RD-4. 

     

    - = I did not include text that suggested whether having one active = interface vs. two would be more or less a common = case.

     

    We now have 4 requirements instead of 3. I am still OK = with my original 3, but if you and the WG prefer these 4 that is fine by = me as well. 

     

    - = Mark

     

    6RD-4: A CE router MUST allow 6rd virtual and IPv6 = native WAN interfaces to be active = simultaneously. 

    6RD-5: Each packet sent on a 6rd = or native WAN interface MUST be directed such that its = source IP address is derived from the delegated prefix = associated with the upstream network the WAN interface is connected = to [section 4.3 of BCP 84, RFC = 3704].


    6RD-6: The = CE router MUST allow different or identical delegated prefixes to be = configured via each WAN interface.

     

    6RD-7 In the event that forwarding rules produce a tie = between 6rd and native IPv6, by default, the IPv6 CE Router MUST = prefer native IPv6.

     

     

    On = Apr 25, 2012, at 12:10 PM, Mark Townsley wrote:



     

    Whittled down to one sentence each, here are three = requirements necessary in order to support incremental migration from = 6rd to native IPv6: 

     


    6RD-4: A CE router MUST allow 6rd virtual and IPv6 = native WAN interfaces to be active = simultaneously. 

    6RD-5: Each packet sent on a 6rd = or native WAN interface MUST be directed such that its = source IP address is derived from the delegated prefix = associated with the upstream network the WAN interface is connected = to [section 4.3 of BCP 84, RFC = 3704].


    6RD-6: The = CE router MUST allow identical or overlapping delegated prefixes = for each WAN interface with a preference for native IPv6 in the = event forwarding rules would have otherwise directed a packet to be sent = equally via 6rd or native IPv6.

     

     

    Summary: The first requirement says 6rd and native = must coexist, the second ensures that packets are directed such that = they are not dropped by the upstream network, and the third ensures = native is chosen over 6rd in the event the paths are otherwise = equal. 

     

    - = Mark

     

     

    On = Apr 25, 2012, at 5:23 AM, Fred Baker wrote:



     

    On = Apr 25, 2012, at 5:05 AM, Hemant Singh (shemant) = wrote:



    Fred,

     

    Appreciate the = quick reply.  In MarkT's comments to Chris that Chris did not = follow the Chairs' recommendation, the statement is not quite = correct.  Additionally MarkT saying to the mailer that  = "He (Chris) decided to throw them in the trash" is not correct = either.  See the URL below where Chris clearly said, he has = guidance from the IETF and WG in the past to not include more than one = normative statement per requirement.  Thus Chris broke up the MarkT = recommendations and the break up has to stay.  Thus it would help if Mark = revisits Chris’ text and fills in holes Mark thinks the text has = because we just cannot go back to Mark’s original text that = combines multiple normative statements in one = requirement.

     

    I would like you to please work with Mark, on the mailer, = to accomplish that. 

     

    =

    http://www.ietf.org/mail-archive/web/v6ops/current/msg12705.html

    Moving on, the = requirements provided by MarkT could use tighter text. =  For example here is a portion of text provided to us to = add.

     

    "6RD-5: The CE = router MUST associate delegated prefixes with the WAN

    interface(s)”

     

    The CPE WAN = interface can be unnumbered with only an IPv6 link-local address and = thus the CPE WAN does not have a global IPv6 address.  In such an = unnumbered model, the CPE uses an address from the PD on a virtual = network interface to source packets out the WAN such as ICMPv6 = errors.  I am away from work tomorrow but we can certainly try and = close any text two days from now including any WebEx phone call between = Mark and us authors of rfc6204bis. 

     

    I suspect that you misunderstand Mark's text, which says = that the text he suggested was inadequate. 

     

    RFC 3704, resolving a number of pages into a single = sentence, recommends that if a packet uses a stated source address and = that source address was derived from a stated upstream network, the = packet should be directed to said upstream network. The reason it would = do so is that the upstream networks presumably implement BCP 38, meaning = that if it is directed to a different upstream network it is likely to = be dropped. 3704 goes on to make suggestions regarding the = implementation of exit routing. What Mark is driving at is = "implement exit routing; if one is given multiple prefixes on = different interfaces, physical or virtual, associate each such prefix = with its source interface in routing for the purposes of source-address = directed exit routing."

     

    Explanations and dialog such as this are the reason I am = asking you to TALK WITH MARK about issues you see rather than talking = with the chairs or simply presuming that the working group outcome in = Paris is brain-dead. The outcome was, as near as I could tell, very = sensible to the operators.

     

    =

    Another example for tighter text is related to 6RD-4.  = Why does 6RD-4 only say “during an incremental migration period = from 6rd to native IPv6.”  = ;  The SP could encounter a problem moving from 6rd to native IPv6 = and may want to revert back to 6rd.  Thus the 6RD-4 bullet should = cater to any migration from 6rd to native IPv6 or vice = versa.=

     

    Further, when the = CPE has different prefixes being used by native IPV6 and 6rd, a host = behind the CPE router has concurrent IPv6 addresses being used (one IPv6 = address from native IPv6 and another from the 6rd prefix).  So what = source-address does the host pick to send a packet to a destination that = is totally disjoint with the two prefixes assigned to the CPE = router?  Let’s say the host picked a source address from the = 6rd prefix, then the CPE router ships the packet out the 6rd tunnel = instead of the higher preferred native IPv6 network.  So how is the = native IPv6 preference enforced by the CPE = router?  

     

    We also do not have = consensus with the “MUST” in 6RD-4.  Current consensus = is mostly towards changing the MUST to a SHOULD.  I also do not see any SP = clamoring for 6rd sunsetting.  One SP in France or France that = has roughly million 6rd customers does not impress me.  I am a = person who gets impressed with 200 million customers which is roughly = what the cable broadband industry is deploying native IPv6 for. =  

     

    Hemant

     

     

    -----Original = Message-----

    From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@iet= f.org] On Behalf Of = Fred Baker (fred)

    Sent: Tuesday, = April 24, 2012 5:33 PM

    To: IPv6 = Operations

    Subject: Re: = [v6ops] 6rd sunsetting requirements for 6204-bis

     

    We discussed this = at IETF 83, and you will find it in the minutes when they come out. Mark = and Ole asked for two things (statements regarding 6rd and ds-lite), and = the working group agreed to one of them. We are not discussing a = "boiling of the ocean", nor are we discussing an infinite = succession of new requirements. We are discussing getting three = no-brainer-class statements into the draft in a manner that the = discussants all recognize and agree to. The three statements were = clarified by hum in the meeting, and were each able to be stated in a = single sentence.

     

    I would ask the = different actors in this discussion to please behave in a courteous = manner toward each other, and work together on this as requested by the = chairs at IETF 83.

    _______________________________________________

     

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

     

     

    ------_=_NextPart_001_01CD23E4.6B744BE2-- From fgont@si6networks.com Thu Apr 26 13:13:11 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53D4621F880D for ; Thu, 26 Apr 2012 13:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, 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 Nwid9up1a6HQ for ; Thu, 26 Apr 2012 13:13:06 -0700 (PDT) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 27D9921F8810 for ; Thu, 26 Apr 2012 13:13:06 -0700 (PDT) Received: from [190.50.169.164] (helo=[192.168.1.44]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SNV3a-0001g8-SP; Thu, 26 Apr 2012 22:12:51 +0200 Message-ID: <4F99A9C7.7020504@si6networks.com> Date: Thu, 26 Apr 2012 17:02:15 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <54469FB9-D118-4157-B9D6-8F52F7F96002@cisco.com> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-ra-guard-implementation WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 20:13:11 -0000 On 04/23/2012 02:47 PM, Bjoern A. Zeeb wrote: >> This is to initiate a two week working group last call of >> draft-ietf-v6ops-ra-guard-implementation. Please read it now. If >> you find nits (spelling errors, minor suggested wording changes, >> etc), comment to the authors; if you find greater issues, such as >> disagreeing with a statement or finding additional issues that need >> to be addressed, please post your comments to the list. > > I had done so at the mic in v6ops and the same day (March 29) to the > list; And I responded to your e-mail. > the draft has not been changed since to limit the packets > dropped by 3.1 to only packets that can actually be RA packets as > identifiable in the L3 header already. Clearly, incorporating that would re-introduce the hole of RA-Guard being trivial to circumvent by means of extension headers and fragmentation. Packets that do not include the entire IPv6 header chain are not going to survive in the Internet, because they prevent stateless packet filtering. That said, the filtering rules also take into account the Hop Limit, and the Source Address, so even in those pathological scenarios, the false positives would be reduce to something very close to nil. > I still have concerns as expressed in these emails that we will be > dropping things to unreasonable limits that will be put into Silicon > and stay around with L2+ devices for at least a decade while not > knowing how things like extension headers etc will evolve as > development and deployment continues. Are you really expecting packets with 1280B+ headers, with the headers split into multiple fragments?? Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From mark@townsley.net Thu Apr 26 13:16:55 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3158521F882E for ; Thu, 26 Apr 2012 13:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.94 X-Spam-Level: X-Spam-Status: No, score=-2.94 tagged_above=-999 required=5 tests=[AWL=0.058, 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 BjCaZiBQHQxI for ; Thu, 26 Apr 2012 13:16:53 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA7521F882C for ; Thu, 26 Apr 2012 13:16:52 -0700 (PDT) Received: by werb10 with SMTP id b10so4398wer.31 for ; Thu, 26 Apr 2012 13:16:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=35752wReEp3lRO5iLUNPKydfHcDnXKDDhj17RkrRyAw=; b=Fbj7f1ajJo7Xql08NDs2GvZuA6z8sjYspoicxY8z6v2kp8CBx4CIPEsI62I3+f27QS NVm6mc34M7HsbJZ/qh6tQX0Qmbid4oHuIhOzUxngRIqAiiNNSvK1zDhKmoJIFPM6F7is e819CCLc5PgjHCoVIgktygZGP2aN2eCAD2VmbweFSM+CeP0ULepe1/cJ/T50ye31C7DS PRJvJK8WHXZt6OOw87hJee5M5UALt/SryxG1rXeP9MDyoEulU6PY/zRi76G7uazUE9mD W9iWt69u2Vtdn4h0IHnsKSIpnhAsottE0lCJGCE4Ia8t0VVnNQ4H0lA3uwJkq0jWgzj9 pzgA== Received: by 10.180.88.199 with SMTP id bi7mr8449857wib.12.1335471411737; Thu, 26 Apr 2012 13:16:51 -0700 (PDT) Received: from ams-townsley-8912.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id b3sm47020211wib.4.2012.04.26.13.16.48 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 26 Apr 2012 13:16:50 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_1227F108-3FB8-4B66-953E-692BC9CBE53B" From: Mark Townsley In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C30483801D@XMB-RCD-109.cisco.com> Date: Thu, 26 Apr 2012 22:16:46 +0200 Message-Id: <50C59C32-B117-4EDB-AA8B-B4B207C82034@townsley.net> References: <5B6B2B64C9FE2A489045EEEADDAFF2C30483722C@XMB-RCD-109.cisco.com><4F95A3D9.1010100@viagenie.ca><5B6B2B64C9FE2A489045EEEADDAFF2C304837261@XMB-RCD-109.cisco.com><4F95ABA0.8090601@viagenie.ca><5B6B2B64C9FE2A489045EEEADDAFF2C304837272@XMB-RCD-109.cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C30483747A@XMB-RCD-109.cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C3048378BB@XMB-RCD-109.cisco.com><42D0E71D-8599-44C6-91D4-B059A276EB6A@cisco.com><379ECFD4-C696-4B86-9DCA-75B0887C4370@townsley.net> <639FE0F2-ECD6-4C83-BB1F-9A9676ABCECB@townsley.net> <5B6B2B64C9FE2A489045EEEADDAFF2C30483801D@XMB-RCD-109.cisco.com> To: Hemant Singh (shemant) X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQk146xuzHXlAvGwiWEENRncYm2g0g2rE1ApVLh1qfNqfeusLjMzuHmORfm/xaoQo0ZHJHYj Cc: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements (version 2) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 20:16:55 -0000 --Apple-Mail=_1227F108-3FB8-4B66-953E-692BC9CBE53B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Apr 26, 2012, at 9:40 PM, Hemant Singh (shemant) wrote: > I did like the context of 6rd sunsetting with the original 6RD-4 = because if we do not provide context, folks may ask to the mailer 6 = months or two years from now as to why two concurrent tech? > =20 > 6RD-4: A CE router MUST allow 6rd virtual and IPv6 native WAN = interfaces to be active simultaneously such as when the CPE router is = sunsetting 6rd or reverting the 6rd sunsetting. OK, I had removed that text only since you had complained about the text = not being "tight" enough before.=20 I'd rather not use "sunsetting" once, much less twice, in the same = sentence though. I'd like to avoid the term altogether in any sort of = normative text. How about this? 6RD-4: A CE router MUST allow 6rd virtual and IPv6 native WAN interfaces = to be active simultaneously in order to support coexistence of the two = technologies during an incremental migration period from 6rd to native = IPv6.=20 > =20 > Tweaked 6RD-5 a little. > =20 > 6RD-5: Each packet sent out the WAN interface via a 6rd or native IPv6 = interface MUST be directed such that its source IPv6 address is derived = from the delegated prefix associated with the egress interface. [section = 4.3 of BCP 84, RFC 3704]. This tweak is inconsistent with the rest of the requirements though. For = starters, it says "_the_ WAN interface" and "_the_ egress interface" = when clearly there may be more than one WAN (or is it "egress" now?) = interface active.=20 If you look back to how Fred paraphrased RFC 3704 in his email on this = thread, you'll find that the 6RD-5 I proposed is highly influenced by = what he wrote. Let's not mess with it. - Mark > =20 > Hemant > =20 > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Mark Townsley > Sent: Thursday, April 26, 2012 8:49 AM > To: Chris Donley; IPv6 Operations > Subject: [v6ops] 6rd sunsetting requirements (version 2) > =20 > =20 > Chris, > =20 > Here is a new set of requirements based on your feedback. In this = version, I adopted some but not all of what you were asking for. = Specifically, > =20 > - I adopted your 6RD-7 text verbatim (though I still personally prefer = using the term "equal" vs. "tie")=20 > =20 > - I changed my text that specified only that delegated prefixes could = be identical, to say that they could be identical as well as different. > =20 > - I couldn't come up with any other way to clarify "allow" not meaning = "always" without complicating the text in 6RD-4.=20 > =20 > - I did not include text that suggested whether having one active = interface vs. two would be more or less a common case. > =20 > We now have 4 requirements instead of 3. I am still OK with my = original 3, but if you and the WG prefer these 4 that is fine by me as = well.=20 > =20 > - Mark > =20 > 6RD-4: A CE router MUST allow 6rd virtual and IPv6 native WAN = interfaces to be active simultaneously.=20 >=20 > 6RD-5: Each packet sent on a 6rd or native WAN interface MUST be = directed such that its source IP address is derived from the delegated = prefix associated with the upstream network the WAN interface is = connected to [section 4.3 of BCP 84, RFC 3704]. >=20 > 6RD-6: The CE router MUST allow different or identical delegated = prefixes to be configured via each WAN interface. > =20 > 6RD-7 In the event that forwarding rules produce a tie between 6rd and = native IPv6, by default, the IPv6 CE Router MUST prefer native IPv6. > =20 > =20 > On Apr 25, 2012, at 12:10 PM, Mark Townsley wrote: >=20 >=20 > =20 > Whittled down to one sentence each, here are three requirements = necessary in order to support incremental migration from 6rd to native = IPv6:=20 > =20 >=20 > 6RD-4: A CE router MUST allow 6rd virtual and IPv6 native WAN = interfaces to be active simultaneously.=20 >=20 > 6RD-5: Each packet sent on a 6rd or native WAN interface MUST be = directed such that its source IP address is derived from the delegated = prefix associated with the upstream network the WAN interface is = connected to [section 4.3 of BCP 84, RFC 3704]. >=20 > 6RD-6: The CE router MUST allow identical or overlapping delegated = prefixes for each WAN interface with a preference for native IPv6 in the = event forwarding rules would have otherwise directed a packet to be sent = equally via 6rd or native IPv6. > =20 > =20 > Summary: The first requirement says 6rd and native must coexist, the = second ensures that packets are directed such that they are not dropped = by the upstream network, and the third ensures native is chosen over 6rd = in the event the paths are otherwise equal.=20 > =20 > - Mark > =20 > =20 > On Apr 25, 2012, at 5:23 AM, Fred Baker wrote: >=20 >=20 > =20 > On Apr 25, 2012, at 5:05 AM, Hemant Singh (shemant) wrote: >=20 >=20 > Fred, > =20 > Appreciate the quick reply. In MarkT's comments to Chris that Chris = did not follow the Chairs' recommendation, the statement is not quite = correct. Additionally MarkT saying to the mailer that "He (Chris) = decided to throw them in the trash" is not correct either. See the URL = below where Chris clearly said, he has guidance from the IETF and WG in = the past to not include more than one normative statement per = requirement. Thus Chris broke up the MarkT recommendations and the = break up has to stay. Thus it would help if Mark revisits Chris=92 text = and fills in holes Mark thinks the text has because we just cannot go = back to Mark=92s original text that combines multiple normative = statements in one requirement. > =20 > I would like you to please work with Mark, on the mailer, to = accomplish that.=20 > =20 > http://www.ietf.org/mail-archive/web/v6ops/current/msg12705.html > Moving on, the requirements provided by MarkT could use tighter text. = For example here is a portion of text provided to us to add. > =20 > "6RD-5: The CE router MUST associate delegated prefixes with the WAN > interface(s)=94 > =20 > The CPE WAN interface can be unnumbered with only an IPv6 link-local = address and thus the CPE WAN does not have a global IPv6 address. In = such an unnumbered model, the CPE uses an address from the PD on a = virtual network interface to source packets out the WAN such as ICMPv6 = errors. I am away from work tomorrow but we can certainly try and close = any text two days from now including any WebEx phone call between Mark = and us authors of rfc6204bis.=20 > =20 > I suspect that you misunderstand Mark's text, which says that the text = he suggested was inadequate.=20 > =20 > RFC 3704, resolving a number of pages into a single sentence, = recommends that if a packet uses a stated source address and that source = address was derived from a stated upstream network, the packet should be = directed to said upstream network. The reason it would do so is that the = upstream networks presumably implement BCP 38, meaning that if it is = directed to a different upstream network it is likely to be dropped. = 3704 goes on to make suggestions regarding the implementation of exit = routing. What Mark is driving at is "implement exit routing; if one is = given multiple prefixes on different interfaces, physical or virtual, = associate each such prefix with its source interface in routing for the = purposes of source-address directed exit routing." > =20 > Explanations and dialog such as this are the reason I am asking you to = TALK WITH MARK about issues you see rather than talking with the chairs = or simply presuming that the working group outcome in Paris is = brain-dead. The outcome was, as near as I could tell, very sensible to = the operators. > =20 > Another example for tighter text is related to 6RD-4. Why does 6RD-4 = only say =93during an incremental migration period from 6rd to native = IPv6.=94 The SP could encounter a problem moving from 6rd to native = IPv6 and may want to revert back to 6rd. Thus the 6RD-4 bullet should = cater to any migration from 6rd to native IPv6 or vice versa. > =20 > Further, when the CPE has different prefixes being used by native IPV6 = and 6rd, a host behind the CPE router has concurrent IPv6 addresses = being used (one IPv6 address from native IPv6 and another from the 6rd = prefix). So what source-address does the host pick to send a packet to = a destination that is totally disjoint with the two prefixes assigned to = the CPE router? Let=92s say the host picked a source address from the = 6rd prefix, then the CPE router ships the packet out the 6rd tunnel = instead of the higher preferred native IPv6 network. So how is the = native IPv6 preference enforced by the CPE router? =20 > =20 > We also do not have consensus with the =93MUST=94 in 6RD-4. Current = consensus is mostly towards changing the MUST to a SHOULD. I also do = not see any SP clamoring for 6rd sunsetting. One SP in France or France = that has roughly million 6rd customers does not impress me. I am a = person who gets impressed with 200 million customers which is roughly = what the cable broadband industry is deploying native IPv6 for. =20 > =20 > Hemant > =20 > =20 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Fred Baker (fred) > Sent: Tuesday, April 24, 2012 5:33 PM > To: IPv6 Operations > Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis > =20 > We discussed this at IETF 83, and you will find it in the minutes when = they come out. Mark and Ole asked for two things (statements regarding = 6rd and ds-lite), and the working group agreed to one of them. We are = not discussing a "boiling of the ocean", nor are we discussing an = infinite succession of new requirements. We are discussing getting three = no-brainer-class statements into the draft in a manner that the = discussants all recognize and agree to. The three statements were = clarified by hum in the meeting, and were each able to be stated in a = single sentence. > =20 > I would ask the different actors in this discussion to please behave = in a courteous manner toward each other, and work together on this as = requested by the chairs at IETF 83. > _______________________________________________ > 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 --Apple-Mail=_1227F108-3FB8-4B66-953E-692BC9CBE53B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
    On Apr 26, 2012, at 9:40 PM, Hemant = Singh (shemant) wrote:

    I did like the context = of 6rd sunsetting with the original 6RD-4 because if we do not provide = context, folks may ask to the mailer 6 months or two years from now as = to why two concurrent tech?

    I'd = rather not use "sunsetting" once, much less twice, in the same sentence = though. I'd like to avoid the term altogether in any sort of normative = text. How about this?

    6RD-4: A CE = router MUST allow 6rd virtual and IPv6 native WAN interfaces to = be active simultaneously in order to support coexistence of the = two technologies during an incremental migration period from 6rd to = native IPv6. 

     
    6RD-5: Each packet sent = out the WAN interface via a 6rd or native IPv6 interface MUST be = directed such that its source IPv6 address is = derived from the delegated prefix associated with the egress = interface. [section 4.3 of BCP 84, RFC = 3704].

    Thi= s tweak is inconsistent with the rest of the requirements = though. For starters, it says "_the_ WAN interface" and "_the_ = egress interface" when clearly there may be more than one WAN (or is it = "egress" now?) interface active. 

    If you = look back to how Fred paraphrased RFC 3704 in his email on this thread, = you'll find that the 6RD-5 I proposed is highly influenced by what he = wrote. Let's not mess with it.

    - = Mark


    From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.or= g] On Behalf = Of Mark = Townsley
    Sent: Thursday, April 26, 2012 = 8:49 AM
    To: Chris Donley; IPv6 = Operations
    Subject: [v6ops] 6rd sunsetting = requirements (version 2)
     
    Here is a new set of = requirements based on your feedback. In this version, I adopted some but = not all of what you were asking for. = Specifically,
    - I adopted your 6RD-7 = text verbatim (though I still personally prefer using the term "equal" = vs. "tie") 
    - I changed my text that = specified only that delegated prefixes could be identical, to say that = they could be identical as well as = different.
    - I couldn't come up with = any other way to clarify "allow" not meaning "always" without = complicating the text in 6RD-4. 
     
    - I did not include text that suggested whether having = one active interface vs. two would be more or less a common = case.
    We now have 4 = requirements instead of 3. I am still OK with my original 3, but if you = and the WG prefer these 4 that is fine by me as = well. 
    - = Mark
    6RD-4: A CE router MUST allow 6rd virtual and IPv6 = native WAN interfaces to be active = simultaneously. 

    6RD-5: Each packet sent on a 6rd = or native WAN interface MUST be directed such that its = source IP address is derived from the delegated prefix = associated with the upstream network the WAN interface is connected = to [section 4.3 of BCP 84, RFC = 3704].

    6RD-6: The CE = router MUST allow different or identical delegated prefixes to be = configured via each WAN interface.
     
    6RD-7 In the event that forwarding rules produce a tie = between 6rd and native IPv6, by default, the IPv6 CE Router MUST = prefer native IPv6.
    On Apr 25, 2012, at 12:10 = PM, Mark Townsley wrote:
    Whittled down to one = sentence each, here are three requirements necessary in order to support = incremental migration from 6rd to = native IPv6: 
     

    6RD-4: A CE router MUST allow 6rd virtual and IPv6 = native WAN interfaces to be active = simultaneously. 

    6RD-5: Each packet sent on a 6rd = or native WAN interface MUST be directed such that its = source IP address is derived from the delegated prefix = associated with the upstream network the WAN interface is connected = to [section 4.3 of BCP 84, RFC = 3704].

    6RD-6: The CE = router MUST allow identical or overlapping delegated prefixes = for each WAN interface with a preference for native IPv6 in the = event forwarding rules would have otherwise directed a packet to be sent = equally via 6rd or native IPv6.
     
     
    Summary: The first requirement says 6rd and native must = coexist, the second ensures that packets are directed such that they are = not dropped by the upstream network, and the third ensures native is = chosen over 6rd in the event the paths are otherwise = equal. 
    - = Mark
    On Apr 25, 2012, at 5:23 = AM, Fred Baker wrote:
    On Apr 25, 2012, at 5:05 = AM, Hemant Singh (shemant) wrote:


    Fred,
    Appreciate the quick reply. =  In MarkT's comments to Chris that Chris did not follow the Chairs' = recommendation, the statement is not quite correct.  Additionally = MarkT saying to the mailer that  "He (Chris) decided to throw them = in the trash" is not correct either.  See the URL below where Chris = clearly said, he has guidance from the IETF and WG in the past to not = include more than one normative statement per requirement.  Thus = Chris broke up the MarkT recommendations and the break up has to = stay.  Thus it = would help if Mark revisits Chris=92 text and fills in holes Mark thinks = the text has because we just cannot go back to Mark=92s original text = that combines multiple normative statements in one = requirement.
    I would = like you to please work with Mark, on the mailer, to accomplish = that.  
    Another example for tighter text is related to 6RD-4.  = Why does 6RD-4 only say =93during an incremental migration period from = 6rd to native IPv6.=94    The SP could = encounter a problem moving from 6rd to native IPv6 and may want to = revert back to 6rd.  Thus the 6RD-4 bullet should cater to any = migration from 6rd to native IPv6 or vice versa. Further, when the CPE has = different prefixes being used by native IPV6 and 6rd, a host behind the = CPE router has concurrent IPv6 addresses being used (one IPv6 address = from native IPv6 and another from the 6rd prefix).  So what = source-address does the host pick to send a packet to a destination that = is totally disjoint with the two prefixes assigned to the CPE = router?  Let=92s say the host picked a source address from the 6rd = prefix, then the CPE router ships the packet out the 6rd tunnel instead = of the higher preferred native IPv6 network.  So how is the native = IPv6 preference enforced by the CPE router?   We also do not have consensus with = the =93MUST=94 in 6RD-4.  Current consensus is mostly towards = changing the MUST to a SHOULD.  I also do not see any SP = clamoring for 6rd sunsetting.  One SP in France or France that = has roughly million 6rd customers does not impress me.  I am a = person who gets impressed with 200 million customers which is roughly = what the cable broadband industry is deploying native IPv6 for. =   Hemant  -----Original = Message-----
    From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Fred Baker = (fred)Sent: Tuesday, April 24, 2012 5:33 = PMTo: IPv6 OperationsSubject: Re: [v6ops] 6rd = sunsetting requirements for 6204-bis
     
    We discussed = this at IETF 83, and you will find it in the minutes when they come out. = Mark and Ole asked for two things (statements regarding 6rd and = ds-lite), and the working group agreed to one of them. We are not = discussing a "boiling of the ocean", nor are we discussing an infinite = succession of new requirements. We are discussing getting three = no-brainer-class statements into the draft in a manner that the = discussants all recognize and agree to. The three statements were = clarified by hum in the meeting, and were each able to be stated in a = single sentence.
    I would ask the different actors = in this discussion to please behave in a courteous manner toward each = other, and work together on this as requested by the chairs at IETF = 83.v6ops mailing list
    In-Reply-To: <50C59C32-B117-4EDB-AA8B-B4B207C82034@townsley.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] 6rd sunsetting requirements (version 2) Thread-Index: Ac0j6YekAgMxBHSzSaS8s9HPhywH2QAAgu0w References: <5B6B2B64C9FE2A489045EEEADDAFF2C30483722C@XMB-RCD-109.cisco.com><4F95A3D9.1010100@viagenie.ca><5B6B2B64C9FE2A489045EEEADDAFF2C304837261@XMB-RCD-109.cisco.com><4F95ABA0.8090601@viagenie.ca><5B6B2B64C9FE2A489045EEEADDAFF2C304837272@XMB-RCD-109.cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C30483747A@XMB-RCD-109.cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C3048378BB@XMB-RCD-109.cisco.com><42D0E71D-8599-44C6-91D4-B059A276EB6A@cisco.com><379ECFD4-C696-4B86-9DCA-75B0887C4370@townsley.net> <639FE0F2-ECD6-4C83-BB1F-9A9676ABCECB@townsley.net> <5B6B2B64C9FE2A489045EEEADDAFF2C30483801D@XMB-RCD-109.cisco.com> <50C59C32-B117-4EDB-AA8B-B4B207C82034@townsley.net> From: "Hemant Singh (shemant)" To: "Mark Townsley" X-OriginalArrivalTime: 26 Apr 2012 20:33:16.0572 (UTC) FILETIME=[CF4B55C0:01CD23EB] Cc: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements (version 2) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 20:33:25 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD23EB.CEF9DC3A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 From: Mark Townsley [mailto:mark@townsley.net]=20 Sent: Thursday, April 26, 2012 4:17 PM To: Hemant Singh (shemant) Cc: IPv6 Operations; Chris Donley Subject: Re: [v6ops] 6rd sunsetting requirements (version 2) =20 =20 >6RD-4: A CE router MUST allow 6rd virtual and IPv6 native WAN interfaces to be active simultaneously in order to support coexistence of the two technologies >during an incremental migration period from 6rd to native IPv6.=20 =20 6RD-4: A CE router MUST allow 6rd virtual and IPv6 native WAN interfaces to be active simultaneously in order to support coexistence of the two technologies during an incremental migration period from 6rd to native IPv6 or vice versa. =20 Hemant=20 ------_=_NextPart_001_01CD23EB.CEF9DC3A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

     

    From: Mark Townsley = [mailto:mark@townsley.net]
    Sent: Thursday, April 26, 2012 = 4:17 PM
    To: Hemant Singh (shemant)
    Cc: IPv6 = Operations; Chris Donley
    Subject: Re: [v6ops] 6rd sunsetting = requirements (version 2)

     

     

    >6RD-4: A CE router = MUST allow 6rd virtual and IPv6 native WAN interfaces to be active = simultaneously in order to support coexistence of the = two technologies >during an = incremental migration period from 6rd to = native IPv6. 

     

    6RD-4: A CE router MUST allow 6rd virtual and IPv6 = native WAN interfaces to be active simultaneously in order to = support coexistence of the two technologies during an incremental = migration period from 6rd to native IPv6 or vice = versa.

     

    Hemant 

    ------_=_NextPart_001_01CD23EB.CEF9DC3A-- From ichiroumakino@gmail.com Thu Apr 26 13:37:37 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE1321F8795 for ; Thu, 26 Apr 2012 13:37:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.107 X-Spam-Level: X-Spam-Status: No, score=-3.107 tagged_above=-999 required=5 tests=[AWL=0.192, 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 ZPOdlwuW9Yju for ; Thu, 26 Apr 2012 13:37:36 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4CFD021F8794 for ; Thu, 26 Apr 2012 13:37:36 -0700 (PDT) Received: by wibhj6 with SMTP id hj6so5299521wib.13 for ; Thu, 26 Apr 2012 13:37:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=Lgr5f+zKD6GK7VCFh86XIYCnSom3jUGiOC19MFDNpC0=; b=zN9NXektO38OOmjkh1ya6pPZ8KPNBZ3OLA/iZxNd7I2Y0BXdVFXp5GNrVYT9+J7VXl CSw7jVK0hqzu/GAEsz83gOy2F+AnP+McOrmp9p2IhIJobwopBe2HNmCDVoaj5DDU31QB 6iLhPvWYIQkxij/TOyA6GyW2oVDlp8ktlA18+6NsITrf+kt1QLzX+k8Cyv2axR0Zq7oX VYUCexOO9ap+4N/d3JTCmNkqQFrBmkWTu56XKz8SfP7kJXsMAczO30ITHoO9vRPZLWZT FznGZ2g5PYSmUA4kwnTteAR5TEsbRjBcZUMwCPkblN6UtWK0dXaX7q1Vke0InUkKYDuF 3F6Q== Received: by 10.180.75.176 with SMTP id d16mr1353558wiw.0.1335472655443; Thu, 26 Apr 2012 13:37:35 -0700 (PDT) Received: from dhcp-10-61-99-2.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id ff9sm47147076wib.2.2012.04.26.13.37.33 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 26 Apr 2012 13:37:34 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6110A6FAC@GAALPA1MSGUSR9N.ITServices.sbc.com> Date: Thu, 26 Apr 2012 22:37:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3951111E-CF0D-4502-9A4D-3DC6F286D37A@employees.org> References: <2D09D61DDFA73D4C884805CC7865E6110A6C53@GAALPA1MSGUSR9N.ITServices.sbc.com> <1F0A766F-BB9F-438E-A286-6AFBA8E3D693@employees.org> <2D09D61DDFA73D4C884805CC7865E6110A6FAC@GAALPA1MSGUSR9N.ITServices.sbc.com> To: "STARK, BARBARA H" X-Mailer: Apple Mail (2.1257) Cc: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 20:37:37 -0000 Barbara, >> you are proposing "Forced single homing". that is quite complex to >> implement. you are creating a dependency between IPv4 and IPv6 on the >> interface. how long do you try initiating native IPv6 before allowing = 6rd to >> come up? >> what do you do when native IPv6 appears on the WAN? >>=20 >> I think the opposite is the case, that implementing the simple = multi-homing >> solution (choose exit based on source) is much simpler than trying to = get >> "forced single homing" correctly. >>=20 >> in addition this scheme is much more generic, it works with multiple = native >> IPv6 connections too. >=20 > If 6rd is enabled, then don't even try native IPv6. Disable it. If = native IPv6 is enabled, then 6rd is not enabled. There is no "try = initiating IPv6 before allowing 6rd to come up". If 6rd is enabled, and = not configured or the BR isn't there, then there is no IPv6. When native = IPv6 appears on the WAN, nothing happens until 6rd is disabled and = native IPv6 is enabled. This scheme works across all devices that are = not designed to support multiple IPv6 connections. It's very simple. = Very Boolean. in the managed CPE environments this certainly would work. the = environment I thought we were writing 6204 for, was the retail routers. = those that were not managed by the ISP. where we have the following text in the introduction: This document specifies how an IPv6 CE router automatically provisions its WAN interface, acquires address space for provisioning of its LAN interfaces, and fetches other configuration information from the service provider network. Automatic provisioning of more complex topology than a single router with multiple LAN interfaces is out of scope for this document. as far as I recall we started this effort off with the goal of being = able to specify a retail router, that could be plugged into an access = network, as specified by BBF or CableLabs and that it would work without = requiring any manual configuration. > I'm not saying CE routers should have to do this and be precluded from = implementing auto-migration. I'm saying exactly the opposite -- CE = routers should not be required to support multiple WAN IPv6 interfaces. = Auto-migration is great. But manual config isn't so horrible that it = needs to be forbidden. it certainly isn't, but it is out of scope for this document. > And yes, I know all about parents, friends and relatives who can't = even do this simple a configuration change. But I don't need 100% of CE = routers to be designed to meet the needs of those people. TR-069 = management exists on most of the CE routers my company ships. We can do = that configuration toggle remotely, so it looks auto-migrated to the = customer. This would allow us great flexibility in rolling out the = native IPv6, by enabling a few at a time. Simultaneous 6rd and native = IPv6 is not required for appearing-to-the-user-to-be-auto-migrated 6rd = to IPv6 in TR-069-managed CE routers. The people who don't choose to go = with our routers tend to be more tech savvy, and understand that with = freedom from SP-management comes a requirement to be willing to do some = of your own configuration. I'm not going to tell these tech savvy people = that their CE router must support auto-migration in order to work with = our 6rd service and subsequently with our native IPv6 service. That = would be inaccurate. The CE router needs to support IPv6 (and, yes, RFC = 6204 does a great job describing that). And it needs to support 6rd, = including 6RD-2 and 6RD-3, which are not covered in RFC 5969. but this document isn't for the managed CPE router case. we have TR-124 = and eRouter for that. I just don't understand how the manual configuration option can work... = my ISP offers me a L2 service. I plug in my own CPE. if the ISP uses = 6rd, I will have to manually enable 6rd (assuming the CPE I bought = defaulted to native IPv4 and native IPv6. say I did that (why would I?), = a year later the ISP stops doing 6rd, and offers native IPv6. what do I = then do? buy a new router? or does the ISP call me and ask me to change = setup (for 100s of different CPE models) or most likely I don't ever = notice, and I'm back to having an IPv4 only home. so no, in the case where the end user buys his own CPE, I just cannot = see how your scheme will work. cheers, Ole From ichiroumakino@gmail.com Thu Apr 26 13:45:26 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73A0721F879C for ; Thu, 26 Apr 2012 13:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.12 X-Spam-Level: X-Spam-Status: No, score=-3.12 tagged_above=-999 required=5 tests=[AWL=0.179, 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 swtSFwoSFOkK for ; Thu, 26 Apr 2012 13:45:25 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9663C21F8799 for ; Thu, 26 Apr 2012 13:45:25 -0700 (PDT) Received: by werb10 with SMTP id b10so22526wer.31 for ; Thu, 26 Apr 2012 13:45:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=3cB70LQe+itGI6+vNBNEnCrA+lev4Ojj4YFmgzbBBRA=; b=WzE9EMT5ZmJDFXrQgB1xgp166+JJN0kDIXTZgaYnxWVhQEDPneIIgZi+IaVInA0L7T qI1fwP7V7qD2R4BXIp4M/3Mxfm2VX7Qq5VKDr2SvG3+bppHjuU/vqCpFoysLi+tcWG0F G6Oyw+Ygbjossek4oJzeB9EpdqrDsHkrhXBUyyY9aigys3LLrjcG6M2GM6/KiivBMSBm 4O8lQv0fe7egc8IFdb/SY6RgJfYTDemiD+CHAEJzPIxZUk2uzSo1FnC2zWDZqFpnEJF9 UpMoe9yyAekerfye4qdXonuGa6M8jVMjD0O0rqaA1+UKTteV3OW2EQRbkp75X1D2rxUn 0XRg== Received: by 10.216.136.149 with SMTP id w21mr4872350wei.90.1335473124754; Thu, 26 Apr 2012 13:45:24 -0700 (PDT) Received: from dhcp-10-61-99-2.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id fl2sm14840788wib.2.2012.04.26.13.45.23 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 26 Apr 2012 13:45:24 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6110A6F80@GAALPA1MSGUSR9N.ITServices.sbc.com> Date: Thu, 26 Apr 2012 22:45:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3F92F17C-9317-448B-9344-724899A0360D@employees.org> References: <2D09D61DDFA73D4C884805CC7865E6110A6C53@GAALPA1MSGUSR9N.ITServices.sbc.com> <18172371-4C87-4CA6-A861-B1FB772C3D9D@employees.org> <2D09D61DDFA73D4C884805CC7865E6110A6F80@GAALPA1MSGUSR9N.ITServices.sbc.com> To: "STARK, BARBARA H" X-Mailer: Apple Mail (2.1257) Cc: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 20:45:26 -0000 Barbara, >>> 6. I need 6rd support, so customers can use these CE routers = to get IPv6 >> connectivity on a 6rd-enabled access network. Now. >>=20 >> don't you have that already? or how is that not RFC6204 + RFC5969? >>=20 >=20 > No, it's not RFC6204 + RFC5969. I need: > 6RD-2: If the IPv6 CE router is capable of automated configuration > of IPv4 through IPCP (i.e., over a PPP connection), it MUST > support user-entered configuration of 6rd. if we absolutely need this requirement, I'd much rather have something = like: 6RD-2: The 6rd configuration parameters MUST be user-configurable. > 6RD-3: If the CE router supports configuration mechanisms other = than > the 6rd DHCPv4 Option 212 (user-entered, TR-69, etc.), the = CE > router MUST support 6rd in "hub and spoke" mode. 6rd in "hub > and spoke" requires all IPv6 traffic to go to the 6rd Border > Relay. In effect, this requirement removes the "direct > connect to 6rd" route defined in Section 7.1.1 of [RFC5969]. right. not wanting to sound like Hemant, which RFC is this defined in? = ;-) RFC6204bis is going to be the normative reference for this, as it is not = described elsewhere. this truly belongs in an update to 5969. if we must include this requirement, I'd suggest we simplify it to: 6RD-3: The CE router MUST support 6rd in "hub and spoke" mode. 6rd in = "hub and spoke" requires all IPv6 traffic to go the 6rd Border Relay. In effect, this requirement removes the "direct connect to 6rd" route defined in Section 7.1.1 of [RFC5969]. cheers, Ole= From fernando.gont.netbook.win@gmail.com Thu Apr 26 16:55:58 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 547E121F85CF for ; Thu, 26 Apr 2012 16:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.064 X-Spam-Level: X-Spam-Status: No, score=-3.064 tagged_above=-999 required=5 tests=[AWL=0.535, 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 J1vRObbeds1p for ; Thu, 26 Apr 2012 16:55:57 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 727B421F8653 for ; Thu, 26 Apr 2012 16:55:57 -0700 (PDT) Received: by yenm5 with SMTP id m5so126228yen.31 for ; Thu, 26 Apr 2012 16:55:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=y3ZazVB9vJybVAUQluEPt8OdqOE1fir/7/RL0CP2pwI=; b=uUzaJzoBx9rFBhCWbyTk941kQgM1JZVHzQWmzfGbxbaxhT/2FzlZQAdkkct09WWcrQ J1e+kATgydYP/UyzrKT1f+sqKg+Gv3YnrnDZXc5sAezvmXxlW4qDnWTJ9VV/znfRYbAS 8nsFUflz3WEYGq9PWbjFuYQHZk0LcTvX+Wpy6bwzqgPpRpJbWwo33nb7rolPeudGSxLn TWud9nLnxIjC8aUvyHU2QKHwNtOPGfWp87PCJtlyHh4lmCRjl53S6nny3kdX5/3tCvfb CArQoxg4n/hZ97O7OxCE0pamEWxJoXer83s7/M7GLID917Jjdzseza6WcJqvPjUyr8nq AYNw== Received: by 10.236.85.209 with SMTP id u57mr8973453yhe.20.1335484557114; Thu, 26 Apr 2012 16:55:57 -0700 (PDT) Received: from [192.168.1.114] ([190.190.97.123]) by mx.google.com with ESMTPS id u20sm21314216yhi.10.2012.04.26.16.55.51 (version=SSLv3 cipher=OTHER); Thu, 26 Apr 2012 16:55:56 -0700 (PDT) Sender: Fernando Gont Message-ID: <4F99BAFC.7090505@gont.com.ar> Date: Thu, 26 Apr 2012 18:15:40 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: james woodyatt References: <54469FB9-D118-4157-B9D6-8F52F7F96002@cisco.com> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, "v6ops-chairs@tools.ietf.org Chairs" Subject: Re: [v6ops] draft-ietf-v6ops-ra-guard-implementation WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 23:55:58 -0000 Hi, James, On 04/26/2012 02:38 PM, james woodyatt wrote: > I share some of Mr. Zeeb's concerns, but I'm willing to support the > draft-- provided that it is updated with an informative reference to > "An uniform format for IPv6 extension headers" [RFC6564] in the first > numbered paragraph describing the filtering rules in section 3. Just double-cheking: what would be the purpose of such reference? Noting that even if there's an extension header that they don't support, they can still parse the packets? -- I thought this was implicit. But if you think this would be appropriate and/or valuable, I have no problem with including the aforementioned reference. Thanks! Best regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From cb.list6@gmail.com Fri Apr 27 03:35:43 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD37121F86F5 for ; Fri, 27 Apr 2012 03:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.12 X-Spam-Level: X-Spam-Status: No, score=-3.12 tagged_above=-999 required=5 tests=[AWL=-0.121, 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 1W5rCKzmsAfy for ; Fri, 27 Apr 2012 03:35:43 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 1A88D21F86FC for ; Fri, 27 Apr 2012 03:35:43 -0700 (PDT) Received: by dady13 with SMTP id y13so1089803dad.27 for ; Fri, 27 Apr 2012 03:35:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=K+2IAAaqfWKG0Erz674ztbijCzL2hQg/6akPPsK8k4A=; b=S5/xACykT16SGIJHqho1L1ZOn/3y3iX4/0+AEt3MGI5f8eYhoo8cyIjvYf+waQAiTi DsnxVsbcpqHjhZJglYnjVvjGLaml9R4ZU2X31pCEYCYQViMxcJnzmFmz531OdwCEByk9 MgmJOh4o5w+O/EHj3obm22msB97yfnwRc4KGxSjl6dwKDwTKWNSiN+zKraBdqbOlnHxf wLPO4zcl3EqFS7rrEBDScU934EJRBxPTaepPyKbnRPs2FORGoZ6kX0ihyyM3vw25/fJK XN/dA8InqdDkBILhbuQl144qjnxmKpqOkqJFX9DeVm4+zmFh9If8R2VzMv42YHMoBpV5 U3SQ== MIME-Version: 1.0 Received: by 10.68.220.99 with SMTP id pv3mr22313643pbc.53.1335522942591; Fri, 27 Apr 2012 03:35:42 -0700 (PDT) Received: by 10.142.102.1 with HTTP; Fri, 27 Apr 2012 03:35:42 -0700 (PDT) In-Reply-To: <20120424111859.199819d07k06j140@mail.drown.org> References: <20120417065542.31115.95082.idtracker@ietfa.amsl.com> <20120417160010kawashimam@mail.jp.nec.com> <56E2AD61-1C91-4889-914A-353793FCBE43@laposte.net> <20120419121044.17531mk1mv19abr4@mail.drown.org> <0646611B-5594-40EA-A2C4-F99CBA734024@laposte.net> <20120419181813.4524701l3gkq5zks@mail.drown.org> <45ABAD31-C265-4D63-82E2-3DE6F59B80C0@laposte.net> <20120420104246.1432746csfcrdqo8@mail.drown.org> <20120423105716.130762z7e8air84c@mail.drown.org> <20120424111859.199819d07k06j140@mail.drown.org> Date: Fri, 27 Apr 2012 03:35:42 -0700 Message-ID: From: Cameron Byrne To: Dan Drown Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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, 27 Apr 2012 10:35:43 -0000 Hi All, Is there any suggested text from the conclusion of this threat that should be brought into the 03 update of the draft? CB On Tue, Apr 24, 2012 at 9:18 AM, Dan Drown wrote: > Quoting GangChen : >> >> Assuming IPv6 apps on the CLAT would talk to severs either on cell >> network side or wifi tethering network side >> I guess CLAT should bind apps to different interface (i.e PPP int or >> eth int) according to the route to the destination. >> Eg: >> PPP_int: 2607:fb90:800:68c::eae6:901 >> eth_int: 2607:fb90:800:68c::eae6:901 >> >> In the case, >> CLAT set default gateway pointing to 3GPP interface(i.e. PPP_int) >> Des: eth_int 2607:fb90:800:68c::eae6:902 >> >> Select: eth_int: 2607:fb90:800:68c::eae6:901 > > > The only thing I would change in your explanation is: this is the generic > process that happens to all Linux machines with multiple ipv6 interfaces, it > is not something specific to or changed in CLAT or 464XLAT. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From ichiroumakino@gmail.com Fri Apr 27 04:32:06 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9922F21F8624 for ; Fri, 27 Apr 2012 04:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NGQt4rkSmQFm for ; Fri, 27 Apr 2012 04:32:06 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2A96721F85F0 for ; Fri, 27 Apr 2012 04:32:05 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so405403wgb.13 for ; Fri, 27 Apr 2012 04:32:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:content-type:content-transfer-encoding:subject:date :message-id:cc:to:mime-version:x-mailer; bh=FrYYhOLWIdB2yLM1cSzxqmR+89dlK2Zor1TtcIkdvUc=; b=ELrmPgsDopMzosfaQOvjq+1wNTiPw7WBeQt6qSVQtAR4MedRckPvYqfP2rdyG2DYCD H6LXD4rqofRjnIF2q4iHCCCx8Hh1dcZk8CP4rVvrXiVREBnWQ9nyqMhtXoB2CvsbTMcw zlbXzqjsoiRjGln/oGPy5vzN62CrpATU0Gab5dF12Gl+iFwguJ5R/V0qeLC4KnhCk/XR XwX7iD3Cra+lk0u619+C+ASQO9/hqq6vi54yYUFrkU2LGHCT1taFTwPwbcb/CKmol6tU lHWjCwEGzXMoBPNVfaV+0RsKlWQcb1JgRhDN9I3zUWdn0ahEGnlf6lRlLHb2BBydVoa8 hYbg== Received: by 10.216.132.30 with SMTP id n30mr1783829wei.52.1335526325328; Fri, 27 Apr 2012 04:32:05 -0700 (PDT) Received: from dhcp-10-61-99-132.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id ex2sm6577583wib.8.2012.04.27.04.32.03 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 27 Apr 2012 04:32:04 -0700 (PDT) Sender: Ole Troan From: =?iso-8859-1?Q?Ole_Tr=F8an?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 27 Apr 2012 13:32:02 +0200 Message-Id: To: draft-ietf-v6ops-6204bis@tools.ietf.org, "v6ops-chairs@tools.ietf.org Chairs" Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Cc: IPv6 Operations Subject: [v6ops] 6204bis - editorship X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 11:32:06 -0000 authors, chairs, as a matter of house-keeping; as I haven't been editing the 6204bis = version, could you please take my name off the authors-list before sending it = over to the IESG? cheers, Ole From gert@space.net Fri Apr 27 04:54:59 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B5F821F86F2 for ; Fri, 27 Apr 2012 04:54: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 4zn+OLp8AC-C for ; Fri, 27 Apr 2012 04:54:58 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4378921F86DD for ; Fri, 27 Apr 2012 04:54:57 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 0051DF8AD5 for ; Fri, 27 Apr 2012 13:54:56 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id E0381F8AB9 for ; Fri, 27 Apr 2012 13:54:55 +0200 (CEST) Received: (qmail 36111 invoked by uid 1007); 27 Apr 2012 13:54:55 +0200 Date: Fri, 27 Apr 2012 13:54:55 +0200 From: Gert Doering To: Mark Townsley Message-ID: <20120427115455.GH84425@Space.Net> References: <4F95A3D9.1010100@viagenie.ca> <5B6B2B64C9FE2A489045EEEADDAFF2C304837261@XMB-RCD-109.cisco.com> <4F95ABA0.8090601@viagenie.ca> <5B6B2B64C9FE2A489045EEEADDAFF2C304837272@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30483747A@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3048378BB@XMB-RCD-109.cisco.com> <42D0E71D-8599-44C6-91D4-B059A276EB6A@cisco.com> <379ECFD4-C696-4B86-9DCA-75B0887C4370@townsley.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <379ECFD4-C696-4B86-9DCA-75B0887C4370@townsley.net> X-NCC-RegID: de.space X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.21 (2010-09-15) Cc: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 11:54:59 -0000 Hi, On Wed, Apr 25, 2012 at 12:10:08PM +0200, Mark Townsley wrote: > Whittled down to one sentence each, here are three requirements necessary in order to support incremental migration from 6rd to native IPv6: > > 6RD-4: A CE router MUST allow 6rd virtual and IPv6 native WAN interfaces to be active simultaneously. +1 > 6RD-5: Each packet sent on a 6rd or native WAN interface MUST be directed such that its source IP address is derived from the delegated prefix associated with the upstream network the WAN interface is connected to [section 4.3 of BCP 84, RFC 3704]. I'm a bit unhappy with the wording, but support the idea. Maybe change the "the WAN interface is connected to" bit to "the corresponding interface is connected to" - to make clear that this does applies to 6rd as well. > 6RD-6: The CE router MUST allow identical or overlapping delegated prefixes for each WAN interface with a preference for native IPv6 in the event forwarding rules would have otherwise directed a packet to be sent equally via 6rd or native IPv6. +1 (Maybe change the wording to "... in the event forwarding rules would result in equal preference for 6rd and native interface" - less words, and hopefully more clear) > Summary: The first requirement says 6rd and native must coexist, the second ensures that packets are directed such that they are not dropped by the upstream network, and the third ensures native is chosen over 6rd in the event the paths are otherwise equal. what he said :) Gert Doering -- operator, fighting with existing CPE devices right now -- 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 Fri Apr 27 05:28:11 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0253A21F87D3 for ; Fri, 27 Apr 2012 05:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c6O7XeLEPqyl for ; Fri, 27 Apr 2012 05:28:10 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 467E221F87B7 for ; Fri, 27 Apr 2012 05:28:10 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 4631CF8AD8 for ; Fri, 27 Apr 2012 14:28:09 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 32776F8AD4 for ; Fri, 27 Apr 2012 14:28:09 +0200 (CEST) Received: (qmail 46007 invoked by uid 1007); 27 Apr 2012 14:28:09 +0200 Date: Fri, 27 Apr 2012 14:28:09 +0200 From: Gert Doering To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Message-ID: <20120427122809.GJ84425@Space.Net> References: <5B6B2B64C9FE2A489045EEEADDAFF2C304837272@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30483747A@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3048378BB@XMB-RCD-109.cisco.com> <42D0E71D-8599-44C6-91D4-B059A276EB6A@cisco.com> <379ECFD4-C696-4B86-9DCA-75B0887C4370@townsley.net> <504FAF77-A618-4E89-86ED-727FD0FEF473@laposte.net> <4CD2AA5D-E6DA-409E-AB78-0F92867BE2E2@laposte.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4CD2AA5D-E6DA-409E-AB78-0F92867BE2E2@laposte.net> X-NCC-RegID: de.space X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.21 (2010-09-15) Cc: IPv6 Operations Subject: Re: [v6ops] 6rd (and 4rd) sunsetting requirements for 6204-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 12:28:11 -0000 Hi, On Wed, Apr 25, 2012 at 10:14:43PM +0200, Rémi Després wrote: > If, in my explanation above, there is a reference to tools that > assign public IPv4 addresses across IPv6-only networks, it is only > because at least one such tool is needed for an ISP to eliminate > 6rd (and the IPv4-only network that goes with it) without waiting > for customers to no longer need their IPv4 addresses. I can't see why "sunsetting 6rd" has to be tied in any way to "turning off IPv4". The ISP might just want to migrate to native dual-stack to get rid of the tunneling overhead, get rid of the 6rd relay boxes, or for a myriard of other reasons - and the focus of Mark's new bullets is on "make sure that moving from 6rd to native IPv6 is going smoothly". This is not related to sunsetting IPv4 (and/or moving to ds-lite or 4rd) - it might be done at the same time, or not. Gert Doering -- Operator -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From despres.remi@laposte.net Fri Apr 27 05:32:43 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84E9421F87D4 for ; Fri, 27 Apr 2012 05:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.838 X-Spam-Level: X-Spam-Status: No, score=-1.838 tagged_above=-999 required=5 tests=[AWL=-0.139, 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 hXXXzYZMsPNh for ; Fri, 27 Apr 2012 05:32:42 -0700 (PDT) Received: from smtpout.laposte.net (smtpout2.laposte.net [193.253.67.227]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD5221F87C0 for ; Fri, 27 Apr 2012 05:32:41 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8503-out with ME id 30Yd1j00737Y3f4030Ydoo; Fri, 27 Apr 2012 14:32:39 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Fri, 27 Apr 2012 14:32:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120417065542.31115.95082.idtracker@ietfa.amsl.com> <20120417160010kawashimam@mail.jp.nec.com> <56E2AD61-1C91-4889-914A-353793FCBE43@laposte.net> <20120419121044.17531mk1mv19abr4@mail.drown.org> <0646611B-5594-40EA-A2C4-F99CBA734024@laposte.net> <20120419181813.4524701l3gkq5zks@mail.drown.org> <45ABAD31-C265-4D63-82E2-3DE6F59B80C0@laposte.net> <20120420104246.1432746csfcrdqo8@mail.drown.org> <20120423105716.130762z7e8air84c@mail.drown.org> <20120424111859.199819d07k06j140@mail.drown.org> To: Dan Drown X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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, 27 Apr 2012 12:32:43 -0000 Dan, Gang, Cameron, Could this issue be clarified? In my understanding: - With a NAT44 and an IPv4 router in the CLAT node, IPv4 applications = communicate via this router. - In this router: . WAN-side servers, because they have public IPv4 addresses, are = reached via the NAT44, and in case of IPv6-only network having a NAT64 = via the CLAT (but not via the in-node IPv6 router) . LAN-side servers, because they have RFC1918 addresses, are reached in = IPv4 via the in-node router. They are not concerned with IPv6. With this understanding, no text needs to be added in the specification = (or only to clarify the above). Anything missed? Regards, RD Le 2012-04-27 =E0 12:35, Cameron Byrne a =E9crit : > Hi All, >=20 > Is there any suggested text from the conclusion of this threat that > should be brought into the 03 update of the draft? >=20 > CB >=20 > On Tue, Apr 24, 2012 at 9:18 AM, Dan Drown = wrote: >> Quoting GangChen : >>>=20 >>> Assuming IPv6 apps on the CLAT would talk to severs either on cell >>> network side or wifi tethering network side >>> I guess CLAT should bind apps to different interface (i.e PPP int or >>> eth int) according to the route to the destination. >>> Eg: >>> PPP_int: 2607:fb90:800:68c::eae6:901 >>> eth_int: 2607:fb90:800:68c::eae6:901 >>>=20 >>> In the case, >>> CLAT set default gateway pointing to 3GPP interface(i.e. PPP_int) >>> Des: eth_int 2607:fb90:800:68c::eae6:902 >>>=20 >>> Select: eth_int: 2607:fb90:800:68c::eae6:901 >>=20 >>=20 >> The only thing I would change in your explanation is: this is the = generic >> process that happens to all Linux machines with multiple ipv6 = interfaces, it >> is not something specific to or changed in CLAT or 464XLAT. >>=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 despres.remi@laposte.net Fri Apr 27 06:04:00 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6963F21F85D3 for ; Fri, 27 Apr 2012 06:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.136 X-Spam-Level: X-Spam-Status: No, score=-2.136 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQIyY-Xieahf for ; Fri, 27 Apr 2012 06:03:59 -0700 (PDT) Received: from smtpout.laposte.net (smtpout5.laposte.net [193.253.67.230]) by ietfa.amsl.com (Postfix) with ESMTP id 2252F21F85D2 for ; Fri, 27 Apr 2012 06:03:58 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8509-out with ME id 313v1j00B37Y3f40313weB; Fri, 27 Apr 2012 15:03:57 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <20120427122809.GJ84425@Space.Net> Date: Fri, 27 Apr 2012 15:03:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6C6050DC-DBEF-48A2-A06B-B6E5A99F7733@laposte.net> References: <5B6B2B64C9FE2A489045EEEADDAFF2C304837272@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30483747A@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3048378BB@XMB-RCD-109.cisco.com> <42D0E71D-8599-44C6-91D4-B059A276EB6A@cisco.com> <379ECFD4-C696-4B86-9DCA-75B0887C4370@townsley.net> <504FAF77-A618-4E89-86ED-727FD0FEF473@laposte.net> <4CD2AA5D-E6DA-409E-AB78-0F92867BE2E2@laposte.net> <20120427122809.GJ84425@Space.Net> To: Gert Doering X-Mailer: Apple Mail (2.1084) Cc: IPv6 Operations Subject: Re: [v6ops] 6rd (and 4rd) sunsetting requirements for 6204-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 13:04:01 -0000 Le 2012-04-27 =E0 14:28, Gert Doering a =E9crit : > Hi, >=20 > On Wed, Apr 25, 2012 at 10:14:43PM +0200, R=E9mi Despr=E9s wrote: >> If, in my explanation above, there is a reference to tools that >> assign public IPv4 addresses across IPv6-only networks, it is only >> because at least one such tool is needed for an ISP to eliminate >> 6rd (and the IPv4-only network that goes with it) without waiting >> for customers to no longer need their IPv4 addresses. >=20 > I can't see why "sunsetting 6rd" has to be tied in any way to "turning = off > IPv4". The ISP might just want to migrate to native dual-stack to get > rid of the tunneling overhead, get rid of the 6rd relay boxes, or for > a myriard of other reasons - and the focus of Mark's new bullets is > on "make sure that moving from 6rd to native IPv6 is going smoothly". Right. My comment was indeed about *a particular* 6rd sunsetting, that which = goes from IPv4-only routing to IPv6-routing routing. (This was = implicitly referring to the goal to progress toward less and less IPv4 = functions, provided user experience isn't impacted.) > This is not related to sunsetting IPv4 (and/or moving to ds-lite or = 4rd)=20 > - it might be done at the same time, or not. Actually, all realistic plans from 6rd to IPv6-only routing I can = imagine do include a phase where DS routing is needed. This is one more = reason to agree with your remark.=20 Thanks for the clarification. Note that my suggestion concerning the draft was to just mention that = 6rd sunsetting is likely to lead to additional constraints, thus = avoiding to specify these constraints without better knowledge of what = is actually needed.=20 I don't plan to insist on this if the WG thinks differently. Regards, RD >=20 > Gert Doering > -- Operator > --=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 gert@space.net Fri Apr 27 07:41:41 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C273221F86A0 for ; Fri, 27 Apr 2012 07:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IzAPXZqcZWpq for ; Fri, 27 Apr 2012 07:41:41 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9BADD21F856D for ; Fri, 27 Apr 2012 07:41:40 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 86DBFF8A98 for ; Fri, 27 Apr 2012 16:41:39 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 5C66EF8ABD for ; Fri, 27 Apr 2012 16:41:39 +0200 (CEST) Received: (qmail 84417 invoked by uid 1007); 27 Apr 2012 16:41:39 +0200 Date: Fri, 27 Apr 2012 16:41:39 +0200 From: Gert Doering To: "Hemant Singh \(shemant\)" Message-ID: <20120427144139.GL84425@Space.Net> References: <5B6B2B64C9FE2A489045EEEADDAFF2C304837272@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30483747A@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3048378BB@XMB-RCD-109.cisco.com> <42D0E71D-8599-44C6-91D4-B059A276EB6A@cisco.com> <379ECFD4-C696-4B86-9DCA-75B0887C4370@townsley.net> <504FAF77-A618-4E89-86ED-727FD0FEF473@laposte.net> <5B6B2B64C9FE2A489045EEEADDAFF2C304837D3A@XMB-RCD-109.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C304837D3A@XMB-RCD-109.cisco.com> X-NCC-RegID: de.space X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.21 (2010-09-15) Cc: IPv6 Operations Subject: Re: [v6ops] 6rd (and 4rd) sunsetting requirements for 6204-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 14:41:42 -0000 Hi, On Wed, Apr 25, 2012 at 08:16:01PM -0500, Hemant Singh (shemant) wrote: > A user is involved in a VoIP call from the user's PC behind a CPE > router using 6rd. Midway through the call, the other end of the > phone call switches to native IPv6. The phone call breaks down. Why would anyone do that? This is not "6rd sunsetting", this is just "broken voip setup". > How can an SP really deploy VoIP phone service with such a stateless > protocol? The point is not how a specific service on top of IPv6 is deployed, but how the IPv6 connectivity *itself* is migrated from technology A to technology B without a hard cut-off "break all existing sessions, force users to reload their routers and re-establish the link to their ISP". Being able to run 6rd and native in parallel for a while establishes just that: - start with 6rd - add native - move services from 6rd to native (like your voip service) - of course this would not be done "in the middle of the call" but for example at the next time the client sends a SIP REGISTER, or at the next time a call is setup - when all services have cut over, depreciate 6rd - turn off 6rd - end with native this is really very obvious from an operator perspective. Gert Doering -- Operator -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From sander@steffann.nl Fri Apr 27 08:02:47 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0830021F872D for ; Fri, 27 Apr 2012 08:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.738 X-Spam-Level: X-Spam-Status: No, score=-0.738 tagged_above=-999 required=5 tests=[AWL=-0.310, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.619, 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 28ENkAoc-kWP for ; Fri, 27 Apr 2012 08:02:46 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id D45C721F8716 for ; Fri, 27 Apr 2012 08:02:42 -0700 (PDT) Received: from [10.0.0.119] (unknown [94.200.91.197]) by mail.sintact.nl (Postfix) with ESMTP id D1C662002; Fri, 27 Apr 2012 17:02:40 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_F496A07A-9204-4D41-B0DE-367E7D8C29EE" From: Sander Steffann In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C30483807B@XMB-RCD-109.cisco.com> Date: Fri, 27 Apr 2012 19:02:36 +0400 Message-Id: References: <5B6B2B64C9FE2A489045EEEADDAFF2C30483722C@XMB-RCD-109.cisco.com><4F95A3D9.1010100@viagenie.ca><5B6B2B64C9FE2A489045EEEADDAFF2C304837261@XMB-RCD-109.cisco.com><4F95ABA0.8090601@viagenie.ca><5B6B2B64C9FE2A489045EEEADDAFF2C304837272@XMB-RCD-109.cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C30483747A@XMB-RCD-109.cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C3048378BB@XMB-RCD-109.cisco.com><42D0E71D-8599-44C6-91D4-B059A276EB6A@cisco.com><379ECFD4-C696-4B86-9DCA-75B0887C4370@townsley.net> <639FE0F2-ECD6-4C83-BB1F-9A9676ABCECB@townsley.net> <5B6B2B64C9FE2A489045EEEADDAFF2C30483801D@XMB-RCD-109.cisco.com> <50C59C32-B117-4EDB-AA8B-B4B207C82034@townsley.net> <5B6B2B64C9FE2A489045EEEADDAFF2C30483807B@XMB-RCD-109.cisco.com> To: Hemant Singh (shemant) X-Mailer: Apple Mail (2.1257) Cc: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements (version 2) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 15:02:47 -0000 --Apple-Mail=_F496A07A-9204-4D41-B0DE-367E7D8C29EE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, > 6RD-4: A CE router MUST allow 6rd virtual and IPv6 native WAN = interfaces to be active simultaneously in order to support coexistence = of the two technologies during an incremental migration period from 6rd = to native IPv6 or vice versa. I can't really see anyone who has a native IPv6 network migrate to 6rd, = but that might be a limit of my imagination :-) - Sander --Apple-Mail=_F496A07A-9204-4D41-B0DE-367E7D8C29EE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi,

    6RD-4: A CE = router MUST allow 6rd virtual and IPv6 native WAN interfaces to = be active simultaneously in order to support coexistence of the = two technologies during an incremental migration period from 6rd to = native IPv6 or = vice = versa.

    I can't really see anyone who has a native IPv6 = network migrate to 6rd, but that might be a limit of my imagination = :-)

    - Sander

    = --Apple-Mail=_F496A07A-9204-4D41-B0DE-367E7D8C29EE-- From nick@foobar.org Tue Apr 24 05:27:45 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD6221F87B4 for ; Tue, 24 Apr 2012 05:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gpt4enpWfRRV for ; Tue, 24 Apr 2012 05:27:44 -0700 (PDT) Received: from mail.acquirer.com (mail.acquirer.com [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 7A32B21F8686 for ; Tue, 24 Apr 2012 05:27:43 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.internal.acquirer.com (inet-gw.acquirer.com [87.198.142.10]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id q3OCROQg057410 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 24 Apr 2012 13:27:24 +0100 (IST) (envelope-from nick@foobar.org) Message-ID: <4F969C3C.1020302@foobar.org> Date: Tue, 24 Apr 2012 13:27:40 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Brian E Carpenter References: <20120418143817.19669.70000.idtracker@ietfa.amsl.com> <829911B8-D986-4381-92FE-C85F2C260EB5@gmail.com> <4F964D94.1010405@gmail.com> In-Reply-To: <4F964D94.1010405@gmail.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 27 Apr 2012 08:06:30 -0700 Cc: IPv6 Ops WG Subject: Re: [v6ops] I-D ACTION:draft-ietf-v6ops-icp-guidance-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 12:44:18 -0000 On 24/04/2012 07:52, Brian E Carpenter wrote: > Thanks Michael. But what do you mean by "the potential advantage of IS-IS"? There is no possible datalink layer method by which you can attack an ISIS deployment on your core network. The only thing you do is hope that the provider hasn't enabled control plan policing and qos on their core links. Nick > Regards > Brian > > On 2012-04-24 07:00, Michael Newbery wrote: >>> 5.2. Routing >>> >>> In a dual stack network, IPv4 and IPv6 routing protocols operate >>> quite independently and in parallel. The common routing protocols >>> all exist in IPv6 versions, such as OSPFv3 [RFC5340], IS-IS >>> [RFC5308], and even RIPng [RFC2080] [RFC2081]. For trained staff, >>> >>> >> >> Is it worthwhile to mention the potential advantage of IS-IS here? Offset of course with the cost of converting the IPv4 routing to use IS-IS as well if that is not already what you do. This is simply to point out the situation, rather than to recommend. >> >>> 6. Load Balancers >>> >>> It is to be expected that IPv6 traffic will initially be low, i.e. a >>> small percentage of IPv4 traffic. For this reason, updating load >>> balancers to fully support IPv6 can perhaps be delayed; however, such >>> >> However, anyone deploying a load balancer is also probably relying on it providing fail-over protection and so needs to be aware that by deferring IPv6 support they lose that as well, not just the load-balancing. >> >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From gert@space.net Fri Apr 27 08:25:27 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4B821F8781 for ; Fri, 27 Apr 2012 08:25:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K9AJsxPEFk2q for ; Fri, 27 Apr 2012 08:25:26 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 620CB21F86DB for ; Fri, 27 Apr 2012 08:25:25 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 7FA30F8ABD for ; Fri, 27 Apr 2012 17:25:24 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 5FB53F8AB9 for ; Fri, 27 Apr 2012 17:25:24 +0200 (CEST) Received: (qmail 96666 invoked by uid 1007); 27 Apr 2012 17:25:24 +0200 Date: Fri, 27 Apr 2012 17:25:24 +0200 From: Gert Doering To: "Hemant Singh \(shemant\)" Message-ID: <20120427152524.GN84425@Space.Net> References: <5B6B2B64C9FE2A489045EEEADDAFF2C30483722C@XMB-RCD-109.cisco.com> <4F95A3D9.1010100@viagenie.ca> <5B6B2B64C9FE2A489045EEEADDAFF2C304837261@XMB-RCD-109.cisco.com> <4F95ABA0.8090601@viagenie.ca> <5B6B2B64C9FE2A489045EEEADDAFF2C304837272@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30483747A@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3048378E6@XMB-RCD-109.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3048378E6@XMB-RCD-109.cisco.com> X-NCC-RegID: de.space X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.21 (2010-09-15) Cc: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 15:25:27 -0000 Hi, On Wed, Apr 25, 2012 at 06:08:36AM -0500, Hemant Singh (shemant) wrote: > One question. Which RFC specifies the technology for the procedure to > sunset 6rd to native IPv6 or vice versa between the SP and the CPE > router? I don't think you need a RFC for that (and there isn't). This is just normal ISP operations. The point is that this should not lead to avoidable outages on the client side - and with some operational and implementational experience, one can easily foresee problem spots with multiple active interfaces plus BCP38. ... and with some forethought, one can give advice to implementors how to avoid these problem spots before they hit. Gert Doering -- Operator -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From cb.list6@gmail.com Fri Apr 27 08:39:29 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A28F921F8633 for ; Fri, 27 Apr 2012 08:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.961 X-Spam-Level: X-Spam-Status: No, score=-2.961 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EEYKgY5ugcLV for ; Fri, 27 Apr 2012 08:39:28 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0F81C21F8630 for ; Fri, 27 Apr 2012 08:39:27 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so1145939pbb.31 for ; Fri, 27 Apr 2012 08:39:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tLpx+EYbq4Lam2SK6ZoxLDJgyL9/3lIyGgK0KCcdwF0=; b=cipT7fPPk2kz7LIoEsJg7CF+FUIO3rT9OlsanrLUl4+xR1NV0AmJTZ8U9CcZHJpGA0 KuIyBbGmBHCfTmyW1gpJ/E4rjhICcPBUoNA3FQxkf9f8b/HU1DMhnE9KXxQuM1ijsl1+ 6jPw1MfdaxQFnjp4vUkU+5q3wSlHxNQ7XOeFFk2GVnrmb9mjY92uqJUgBKTNksa/jy1v YouB2Qf1bi5zShVup/rTjCoVQFp5cgQaBCfv/ntpFcY82iaPWe05E8jFes6j39n/g38P QuSveEIOMlg1fDE03TREt0WTdZwQE/rIaa9aVC8NHQqV5ada4Evxz05fdI/8HGA1hVmj +HHg== MIME-Version: 1.0 Received: by 10.68.224.99 with SMTP id rb3mr23744602pbc.79.1335541166861; Fri, 27 Apr 2012 08:39:26 -0700 (PDT) Received: by 10.142.102.1 with HTTP; Fri, 27 Apr 2012 08:39:26 -0700 (PDT) Received: by 10.142.102.1 with HTTP; Fri, 27 Apr 2012 08:39:26 -0700 (PDT) In-Reply-To: References: <20120417065542.31115.95082.idtracker@ietfa.amsl.com> <20120417160010kawashimam@mail.jp.nec.com> <56E2AD61-1C91-4889-914A-353793FCBE43@laposte.net> <20120419121044.17531mk1mv19abr4@mail.drown.org> <0646611B-5594-40EA-A2C4-F99CBA734024@laposte.net> <20120419181813.4524701l3gkq5zks@mail.drown.org> <45ABAD31-C265-4D63-82E2-3DE6F59B80C0@laposte.net> <20120420104246.1432746csfcrdqo8@mail.drown.org> <20120423105716.130762z7e8air84c@mail.drown.org> <20120424111859.199819d07k06j140@mail.drown.org> Date: Fri, 27 Apr 2012 08:39:26 -0700 Message-ID: From: Cameron Byrne To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=047d7b15b1edd56d6c04beaae81a Cc: v6ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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, 27 Apr 2012 15:39:29 -0000 --047d7b15b1edd56d6c04beaae81a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Apr 27, 2012 5:32 AM, "R=E9mi Despr=E9s" wrot= e: > > Dan, Gang, Cameron, > > Could this issue be clarified? > > In my understanding: > - With a NAT44 and an IPv4 router in the CLAT node, IPv4 applications communicate via this router. > - In this router: > . WAN-side servers, because they have public IPv4 addresses, are reached via the NAT44, and in case of IPv6-only network having a NAT64 via the CLAT (but not via the in-node IPv6 router) > . LAN-side servers, because they have RFC1918 addresses, are reached in IPv4 via the in-node router. They are not concerned with IPv6. > With this understanding, no text needs to be added in the specification (or only to clarify the above). > > Anything missed? > I think your understanding is the same as mine, if you are saying the 02 revision does not need modification. For LAN to LAN communication, the CLAT does not modify packets. For LAN to WAN, CLAT does not modify ipv6 packets either to the public ipv6 server or to ipv4 servers that are reached via PLAT + DNS64. For LAN ipv4 to WAN ipv4 across an ipv6-only access network, nat44 & rfc6145 are applied at the clat and rfc 6146 at the PLAT. Unless there is a larger than /64 prefix assigned to the CLAT, then the CLAT only needs to do rfc6145 and no nat44. This behavior is documented in the draft 02 is in the traffic treatment scenario chart. Cb > Regards, > RD > > > > Le 2012-04-27 =E0 12:35, Cameron Byrne a =E9crit : > > > Hi All, > > > > Is there any suggested text from the conclusion of this threat that > > should be brought into the 03 update of the draft? > > > > CB > > > > On Tue, Apr 24, 2012 at 9:18 AM, Dan Drown wrote: > >> Quoting GangChen : > >>> > >>> Assuming IPv6 apps on the CLAT would talk to severs either on cell > >>> network side or wifi tethering network side > >>> I guess CLAT should bind apps to different interface (i.e PPP int or > >>> eth int) according to the route to the destination. > >>> Eg: > >>> PPP_int: 2607:fb90:800:68c::eae6:901 > >>> eth_int: 2607:fb90:800:68c::eae6:901 > >>> > >>> In the case, > >>> CLAT set default gateway pointing to 3GPP interface(i.e. PPP_int) > >>> Des: eth_int 2607:fb90:800:68c::eae6:902 > >>> > >>> Select: eth_int: 2607:fb90:800:68c::eae6:901 > >> > >> > >> The only thing I would change in your explanation is: this is the generic > >> process that happens to all Linux machines with multiple ipv6 interfaces, it > >> is not something specific to or changed in CLAT or 464XLAT. > >> > >> _______________________________________________ > >> 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 > On Apr 27, 2012 5:32 AM, "R=E9mi Despr=E9s" wro= te: > Dan, Gang, Cameron, > > Could this issue be clarified? > > In my understanding: > - With a NAT44 and an IPv4 router in the CLAT node, IPv4 applications > communicate via this router. > - In this router: > . WAN-side servers, because they have public IPv4 addresses, are reached > via the NAT44, and in case of IPv6-only network having a NAT64 via the CL= AT > (but not via the in-node IPv6 router) > . LAN-side servers, because they have RFC1918 addresses, are reached in > IPv4 via the in-node router. They are not concerned with IPv6. > With this understanding, no text needs to be added in the specification > (or only to clarify the above). > > Anything missed? > > Regards, > RD > > > > Le 2012-04-27 =E0 12:35, Cameron Byrne a =E9crit : > > > Hi All, > > > > Is there any suggested text from the conclusion of this threat that > > should be brought into the 03 update of the draft? > > > > CB > > > > On Tue, Apr 24, 2012 at 9:18 AM, Dan Drown wrote: > >> Quoting GangChen : > >>> > >>> Assuming IPv6 apps on the CLAT would talk to severs either on cell > >>> network side or wifi tethering network side > >>> I guess CLAT should bind apps to different interface (i.e PPP int or > >>> eth int) according to the route to the destination. > >>> Eg: > >>> PPP_int: 2607:fb90:800:68c::eae6:901 > >>> eth_int: 2607:fb90:800:68c::eae6:901 > >>> > >>> In the case, > >>> CLAT set default gateway pointing to 3GPP interface(i.e. PPP_int) > >>> Des: eth_int 2607:fb90:800:68c::eae6:902 > >>> > >>> Select: eth_int: 2607:fb90:800:68c::eae6:901 > >> > >> > >> The only thing I would change in your explanation is: this is the > generic > >> process that happens to all Linux machines with multiple ipv6 > interfaces, it > >> is not something specific to or changed in CLAT or 464XLAT. > >> > >> _______________________________________________ > >> 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 > > --047d7b15b1edd56d6c04beaae81a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


    On Apr 27, 2012 5:32 AM, "R=E9mi Despr=E9s" <    despres.remi@laposte.net> wrote:
    >
    > Dan, Gang, Cameron,
    >
    > Could this issue be clarified?
    >
    > In my understanding:
    > - With a NAT44 and an IPv4 router in the CLAT node, IPv4 applications = communicate via this router.
    > - In this router:
    > =A0. WAN-side servers, because they have public IPv4 addresses, are re= ached via the NAT44, and in case of IPv6-only network having a NAT64 via th= e CLAT (but not via the in-node IPv6 router)
    > =A0. LAN-side servers, because they have RFC1918 addresses, are reache= d in IPv4 via the in-node router. They are not concerned with IPv6.
    > With this understanding, no text needs to be added in the specificatio= n (or only to clarify the above).
    >
    > Anything missed?
    >

    I think your understanding is the same as mine, if you are saying the 02= revision does not need modification.

    For LAN to LAN communication, the CLAT does not modify packets.

    For LAN to WAN, CLAT does not modify ipv6 packets either to the public i= pv6 server or to ipv4 servers that are reached via PLAT + DNS64.=A0 For LAN= ipv4 to WAN ipv4 across an ipv6-only access network, nat44 & rfc6145 a= re applied at the clat and rfc 6146 at the PLAT.=A0 Unless there is a large= r than /64 prefix assigned to the CLAT, then the CLAT only needs to do rfc6= 145 and no nat44.

    This behavior is documented in the draft 02 is in the traffic treatment = scenario chart.

    Cb

    > Regards,
    > RD
    >
    >
    >
    > Le 2012-04-27 =E0 12:35, Cameron Byrne a =E9crit :
    >
    > > Hi All,
    > >
    > > Is there any suggested text from the conclusion of this threat th= at
    > > should be brought into the 03 update of the draft?
    > >
    > > CB
    > >
    > > On Tue, Apr 24, 2012 at 9:18 AM, Dan Drown <dan-v6ops@drown.org> wrote:
    > >> Quoting GangChen <phd= gang@gmail.com>:
    > >>>
    > >>> Assuming IPv6 apps on the CLAT would talk to severs eithe= r on cell
    > >>> network side or wifi tethering network side
    > >>> I guess CLAT should bind apps to different interface (i.e= PPP int or
    > >>> eth int) according to the route to the destination.
    > >>> Eg:
    > >>> PPP_int: 2607:fb90:800:68c::eae6:901
    > >>> eth_int: 2607:fb90:800:68c::eae6:901
    > >>>
    > >>> In the case,
    > >>> CLAT set default gateway pointing to 3GPP interface(i.e. = PPP_int)
    > >>> Des: eth_int 2607:fb90:800:68c::eae6:902
    > >>>
    > >>> Select: eth_int: 2607:fb90:800:68c::eae6:901
    > >>
    > >>
    > >> The only thing I would change in your explanation is: this is= the generic
    > >> process that happens to all Linux machines with multiple ipv6= interfaces, it
    > >> is not something specific to or changed in CLAT or 464XLAT. > >>
    > >> _______________________________________________
    > >> v6ops mailing list
    > >> v6ops@ietf.org
    > >> https= ://www.ietf.org/mailman/listinfo/v6ops
    > > _______________________________________________
    > > v6ops mailing list
    > > v6ops@ietf.org
    > > https://w= ww.ietf.org/mailman/listinfo/v6ops
    >

    On Apr 27, 2012 5:32 AM, "R=E9mi Despr=E9s&= quot; <despres.remi@laposte.= net> wrote:
    Dan, Gang, Cameron,

    Could this issue be clarified?

    In my understanding:
    - With a NAT44 and an IPv4 router in the CLAT node, IPv4 applications commu= nicate via this router.
    - In this router:
    =A0. WAN-side servers, because they have public IPv4 addresses, are reached= via the NAT44, and in case of IPv6-only network having a NAT64 via the CLA= T (but not via the in-node IPv6 router)
    =A0. LAN-side servers, because they have RFC1918 addresses, are reached in = IPv4 via the in-node router. They are not concerned with IPv6.
    With this understanding, no text needs to be added in the specification (or= only to clarify the above).

    Anything missed?

    Regards,
    RD



    Le 2012-04-27 =E0 12:35, Cameron Byrne a =E9crit :

    > Hi All,
    >
    > Is there any suggested text from the conclusion of this threat that > should be brought into the 03 update of the draft?
    >
    > CB
    >
    > On Tue, Apr 24, 2012 at 9:18 AM, Dan Drown <dan-v6ops@drown.org> wrote:
    >> Quoting GangChen <phdgang@= gmail.com>:
    >>>
    >>> Assuming IPv6 apps on the CLAT would talk to severs either on = cell
    >>> network side or wifi tethering network side
    >>> I guess CLAT should bind apps to different interface (i.e PPP = int or
    >>> eth int) according to the route to the destination.
    >>> Eg:
    >>> PPP_int: 2607:fb90:800:68c::eae6:901
    >>> eth_int: 2607:fb90:800:68c::eae6:901
    >>>
    >>> In the case,
    >>> CLAT set default gateway pointing to 3GPP interface(i.e. PPP_i= nt)
    >>> Des: eth_int 2607:fb90:800:68c::eae6:902
    >>>
    >>> Select: eth_int: 2607:fb90:800:68c::eae6:901
    >>
    >>
    >> The only thing I would change in your explanation is: this is the = generic
    >> process that happens to all Linux machines with multiple ipv6 inte= rfaces, it
    >> is not something specific to or changed in CLAT or 464XLAT.
    >>
    >> _______________________________________________
    >> 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

    --047d7b15b1edd56d6c04beaae81a-- From randy@psg.com Fri Apr 27 08:58:40 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CCD221F86E8 for ; Fri, 27 Apr 2012 08:58:40 -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 OokvKJmbcZLP for ; Fri, 27 Apr 2012 08:58:40 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id EECDB21F86E4 for ; Fri, 27 Apr 2012 08:58:39 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SNnZ8-0003ea-8C; Fri, 27 Apr 2012 15:58:38 +0000 Date: Fri, 27 Apr 2012 08:58:37 -0700 Message-ID: From: Randy Bush To: Sander Steffann In-Reply-To: <639FE0F2-ECD6-4C83-BB1F-9A9676ABCECB@townsley.net> References: <5B6B2B64C9FE2A489045EEEADDAFF2C30483722C@XMB-RCD-109.cisco.com> <4F95A3D9.1010100@viagenie.ca> <5B6B2B64C9FE2A489045EEEADDAFF2C304837261@XMB-RCD-109.cisco.com> <4F95ABA0.8090601@viagenie.ca> <5B6B2B64C9FE2A489045EEEADDAFF2C304837272@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30483747A@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3048378BB@XMB-RCD-109.cisco.com> <42D0E71D-8599-44C6-91D4-B059A276EB6A@cisco.com> <379ECFD4-C696-4B86-9DCA-75B0887C4370@townsley.net> <639FE0F2-ECD6-4C83-BB1F-9A9676ABCECB@townsley.net> <5B6B2B64C9FE2A489045EEEADDAFF2C30483801D@XMB-RCD-109.cisco.com> <50C59C32-B117-4EDB-AA8B-B4B207C82034@townsley.net> <5B6B2B64C9FE2A489045EEEADDAFF2C30483807B@XMB-RCD-109.cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements (version 2) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 15:58:40 -0000 >> 6RD-4: A CE router MUST allow 6rd virtual and IPv6 native WAN >> interfaces to be active simultaneously in order to support >> coexistence of the two technologies during an incremental migration >> period from 6rd to native IPv6 or vice versa. > I can't really see anyone who has a native IPv6 network migrate to > 6rd, but that might be a limit of my imagination :-) didn't you know that corner cases allow us to complicate things, which makes us more famous and gets more brownie points? Mark Townsley wrote: > 6RD-4: A CE router MUST allow 6rd virtual and IPv6 native WAN > interfaces to be active simultaneously. > > 6RD-5: Each packet sent on a 6rd or native WAN interface MUST be > directed such that its source IP address is derived from the delegated > prefix associated with the upstream network the WAN interface is > connected to [section 4.3 of BCP 84, RFC 3704]. > > 6RD-6: The CE router MUST allow different or identical delegated > prefixes to be configured via each WAN interface. > > 6RD-7 In the event that forwarding rules produce a tie between 6rd and > native IPv6, by default, the IPv6 CE Router MUST prefer native IPv6. wfm randy From despres.remi@laposte.net Fri Apr 27 09:25:26 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1956221F86F3 for ; Fri, 27 Apr 2012 09:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.838 X-Spam-Level: X-Spam-Status: No, score=-1.838 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 RM1DaHtnmhxS for ; Fri, 27 Apr 2012 09:25:25 -0700 (PDT) Received: from smtpout.laposte.net (smtpout4.laposte.net [193.253.67.229]) by ietfa.amsl.com (Postfix) with ESMTP id 6334121F86EC for ; Fri, 27 Apr 2012 09:25:23 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8507-out with ME id 34RJ1j00D37Y3f4034RKgK; Fri, 27 Apr 2012 18:25:22 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-87-754433271 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Fri, 27 Apr 2012 18:25:18 +0200 Message-Id: <5285C70C-89A8-4C99-AF24-5BB6AA055944@laposte.net> References: <20120417065542.31115.95082.idtracker@ietfa.amsl.com> <20120417160010kawashimam@mail.jp.nec.com> <56E2AD61-1C91-4889-914A-353793FCBE43@laposte.net> <20120419121044.17531mk1mv19abr4@mail.drown.org> <0646611B-5594-40EA-A2C4-F99CBA734024@laposte.net> <20120419181813.4524701l3gkq5zks@mail.drown.org> <45ABAD31-C265-4D63-82E2-3DE6F59B80C0@laposte.net> <20120420104246.1432746csfcrdqo8@mail.drown.org> <20120423105716.130762z7e8air84c@mail.drown.org> <20120424111859.199819d07k06j140@mail.drown.org> To: Cameron Byrne X-Mailer: Apple Mail (2.1084) Cc: v6ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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, 27 Apr 2012 16:25:26 -0000 --Apple-Mail-87-754433271 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2012-04-27 =E0 17:39, Cameron Byrne a =E9crit : >=20 > On Apr 27, 2012 5:32 AM, "R=E9mi Despr=E9s" = wrote: > > > > Dan, Gang, Cameron, > > > > Could this issue be clarified? > > > > In my understanding: > > - With a NAT44 and an IPv4 router in the CLAT node, IPv4 = applications communicate via this router. > > - In this router: > > . WAN-side servers, because they have public IPv4 addresses, are = reached via the NAT44, and in case of IPv6-only network having a NAT64 = via the CLAT (but not via the in-node IPv6 router) > > . LAN-side servers, because they have RFC1918 addresses, are = reached in IPv4 via the in-node router. They are not concerned with = IPv6. > > With this understanding, no text needs to be added in the = specification (or only to clarify the above). > > > > Anything missed? > > >=20 > I think your understanding is the same as mine, if you are saying the = 02 revision does not need modification. >=20 > For LAN to LAN communication, the CLAT does not modify packets. >=20 > For LAN to WAN, CLAT does not modify ipv6 packets either to the public = ipv6 server or to ipv4 servers that are reached via PLAT + DNS64. For = LAN ipv4 to WAN ipv4 across an ipv6-only access network, nat44 & rfc6145 = are applied at the clat and rfc 6146 at the PLAT.=20 >=20 In full sync so far. > Unless there is a larger than /64 prefix assigned to the CLAT, then = the CLAT only needs to do rfc6145 and no nat44. >=20 In case of tethering, which is the context discussed by Gang and Dan, = always including a NAT44 is in my understanding much simpler than trying = to dispense with it. I see no need to document anything else in a BCP. Now, I agree that a CLAT node WITHOUT tethering MAY dispense with a = NAT44. But it is worth noting that it MAY include a NAT44, in which case a = common architecture applies to all cases. > This behavior is documented in the draft 02 is in the traffic = treatment scenario chart. >=20 If the NAT44 is the IPv4 client of the scenario chart, the chart can = apply as well to tethering as to tethering-less. It becomes generic. RD =20 > Cb >=20 > > Regards, > > RD > > > > > > > > Le 2012-04-27 =E0 12:35, Cameron Byrne a =E9crit : > > > > > Hi All, > > > > > > Is there any suggested text from the conclusion of this threat = that > > > should be brought into the 03 update of the draft? > > > > > > CB > > > > > > On Tue, Apr 24, 2012 at 9:18 AM, Dan Drown = wrote: > > >> Quoting GangChen : > > >>> > > >>> Assuming IPv6 apps on the CLAT would talk to severs either on = cell > > >>> network side or wifi tethering network side > > >>> I guess CLAT should bind apps to different interface (i.e PPP = int or > > >>> eth int) according to the route to the destination. > > >>> Eg: > > >>> PPP_int: 2607:fb90:800:68c::eae6:901 > > >>> eth_int: 2607:fb90:800:68c::eae6:901 > > >>> > > >>> In the case, > > >>> CLAT set default gateway pointing to 3GPP interface(i.e. = PPP_int) > > >>> Des: eth_int 2607:fb90:800:68c::eae6:902 > > >>> > > >>> Select: eth_int: 2607:fb90:800:68c::eae6:901 > > >> > > >> > > >> The only thing I would change in your explanation is: this is the = generic > > >> process that happens to all Linux machines with multiple ipv6 = interfaces, it > > >> is not something specific to or changed in CLAT or 464XLAT. > > >> > > >> _______________________________________________ > > >> 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 > > > On Apr 27, 2012 5:32 AM, "R=E9mi Despr=E9s" = wrote: > Dan, Gang, Cameron, >=20 > Could this issue be clarified? >=20 > In my understanding: > - With a NAT44 and an IPv4 router in the CLAT node, IPv4 applications = communicate via this router. > - In this router: > . WAN-side servers, because they have public IPv4 addresses, are = reached via the NAT44, and in case of IPv6-only network having a NAT64 = via the CLAT (but not via the in-node IPv6 router) > . LAN-side servers, because they have RFC1918 addresses, are reached = in IPv4 via the in-node router. They are not concerned with IPv6. > With this understanding, no text needs to be added in the = specification (or only to clarify the above). >=20 > Anything missed? >=20 > Regards, > RD >=20 >=20 >=20 > Le 2012-04-27 =E0 12:35, Cameron Byrne a =E9crit : >=20 > > Hi All, > > > > Is there any suggested text from the conclusion of this threat that > > should be brought into the 03 update of the draft? > > > > CB > > > > On Tue, Apr 24, 2012 at 9:18 AM, Dan Drown = wrote: > >> Quoting GangChen : > >>> > >>> Assuming IPv6 apps on the CLAT would talk to severs either on cell > >>> network side or wifi tethering network side > >>> I guess CLAT should bind apps to different interface (i.e PPP int = or > >>> eth int) according to the route to the destination. > >>> Eg: > >>> PPP_int: 2607:fb90:800:68c::eae6:901 > >>> eth_int: 2607:fb90:800:68c::eae6:901 > >>> > >>> In the case, > >>> CLAT set default gateway pointing to 3GPP interface(i.e. PPP_int) > >>> Des: eth_int 2607:fb90:800:68c::eae6:902 > >>> > >>> Select: eth_int: 2607:fb90:800:68c::eae6:901 > >> > >> > >> The only thing I would change in your explanation is: this is the = generic > >> process that happens to all Linux machines with multiple ipv6 = interfaces, it > >> is not something specific to or changed in CLAT or 464XLAT. > >> > >> _______________________________________________ > >> 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 --Apple-Mail-87-754433271 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1


    On Apr 27, 2012 5:32 AM, "R=E9mi Despr=E9s" <despres.remi@laposte.net> = wrote:
    >
    > Dan, Gang, Cameron,
    >
    > Could this issue be clarified?
    >
    > In my understanding:
    > - With a NAT44 and an IPv4 router in the CLAT node, IPv4 = applications communicate via this router.
    > - In this router:
    >  . WAN-side servers, because they have public IPv4 addresses, = are reached via the NAT44, and in case of IPv6-only network having a = NAT64 via the CLAT (but not via the in-node IPv6 router)
    >  . LAN-side servers, because they have RFC1918 addresses, are = reached in IPv4 via the in-node router. They are not concerned with = IPv6.
    > With this understanding, no text needs to be added in the = specification (or only to clarify the above).
    >
    > Anything missed?
    >

    I think your understanding is the same as mine, if you are = saying the 02 revision does not need modification.

    For LAN to LAN = communication, the CLAT does not modify packets.

    For LAN to WAN, = CLAT does not modify ipv6 packets either to the public ipv6 server or to = ipv4 servers that are reached via PLAT + DNS64.  For LAN ipv4 to = WAN ipv4 across an ipv6-only access network, nat44 & rfc6145 are = applied at the clat and rfc 6146 at the PLAT.  =


    In full sync so = far.

    Unless there is a larger than = /64 prefix assigned to the CLAT, then the CLAT only needs to do rfc6145 = and no nat44.

    In case of tethering, which is the = context discussed by Gang and Dan, always including a NAT44 is in my = understanding much simpler than trying to dispense with it.
    I = see no need to document anything else in a = BCP.

    Now, I agree that a CLAT node WITHOUT = tethering MAY dispense with a NAT44.
    But it is worth noting = that it MAY include a NAT44, in which case a common architecture applies = to all cases.

    This = behavior is documented in the draft 02 is in the traffic treatment = scenario chart.

    If the NAT44 is the IPv4 client of the = scenario chart, the chart can apply as well to tethering as to = tethering-less. It becomes = generic.

    RD
     

    Cb

    > Regards,
    > RD
    >
    >
    >
    > Le 2012-04-27 =E0 12:35, Cameron Byrne a =E9crit :
    >
    > > Hi All,
    > >
    > > Is there any suggested text from the conclusion of this threat = that
    > > should be brought into the 03 update of the draft?
    > >
    > > CB
    > >
    > > On Tue, Apr 24, 2012 at 9:18 AM, Dan Drown <dan-v6ops@drown.org> = wrote:
    > >> Quoting GangChen <phdgang@gmail.com>:
    > >>>
    > >>> Assuming IPv6 apps on the CLAT would talk to severs = either on cell
    > >>> network side or wifi tethering network side
    > >>> I guess CLAT should bind apps to different interface = (i.e PPP int or
    > >>> eth int) according to the route to the = destination.
    > >>> Eg:
    > >>> PPP_int: 2607:fb90:800:68c::eae6:901
    > >>> eth_int: 2607:fb90:800:68c::eae6:901
    > >>>
    > >>> In the case,
    > >>> CLAT set default gateway pointing to 3GPP = interface(i.e. PPP_int)
    > >>> Des: eth_int 2607:fb90:800:68c::eae6:902
    > >>>
    > >>> Select: eth_int: 2607:fb90:800:68c::eae6:901
    > >>
    > >>
    > >> The only thing I would change in your explanation is: this = is the generic
    > >> process that happens to all Linux machines with multiple = ipv6 interfaces, it
    > >> is not something specific to or changed in CLAT or = 464XLAT.
    > >>
    > >> _______________________________________________
    > >> 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
    >

    On Apr 27, 2012 5:32 AM, "R=E9mi Despr=E9s" = <despres.remi@laposte.net> = wrote:
    Dan, Gang, Cameron,

    Could this issue be clarified?

    In my understanding:
    - With a NAT44 and an IPv4 router in the CLAT node, IPv4 applications = communicate via this router.
    - In this router:
     . WAN-side servers, because they have public IPv4 addresses, are = reached via the NAT44, and in case of IPv6-only network having a NAT64 = via the CLAT (but not via the in-node IPv6 router)
     . LAN-side servers, because they have RFC1918 addresses, are = reached in IPv4 via the in-node router. They are not concerned with = IPv6.
    With this understanding, no text needs to be added in the specification = (or only to clarify the above).

    Anything missed?

    Regards,
    RD



    Le 2012-04-27 =E0 12:35, Cameron Byrne a =E9crit :

    > Hi All,
    >
    > Is there any suggested text from the conclusion of this threat = that
    > should be brought into the 03 update of the draft?
    >
    > CB
    >
    > On Tue, Apr 24, 2012 at 9:18 AM, Dan Drown <dan-v6ops@drown.org> = wrote:
    >> Quoting GangChen <phdgang@gmail.com>:
    >>>
    >>> Assuming IPv6 apps on the CLAT would talk to severs either = on cell
    >>> network side or wifi tethering network side
    >>> I guess CLAT should bind apps to different interface (i.e = PPP int or
    >>> eth int) according to the route to the destination.
    >>> Eg:
    >>> PPP_int: 2607:fb90:800:68c::eae6:901
    >>> eth_int: 2607:fb90:800:68c::eae6:901
    >>>
    >>> In the case,
    >>> CLAT set default gateway pointing to 3GPP interface(i.e. = PPP_int)
    >>> Des: eth_int 2607:fb90:800:68c::eae6:902
    >>>
    >>> Select: eth_int: 2607:fb90:800:68c::eae6:901
    >>
    >>
    >> The only thing I would change in your explanation is: this is = the generic
    >> process that happens to all Linux machines with multiple ipv6 = interfaces, it
    >> is not something specific to or changed in CLAT or 464XLAT.
    >>
    >> _______________________________________________
    >> 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-87-754433271-- From bs7652@att.com Fri Apr 27 09:38:57 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C66521F85A5 for ; Fri, 27 Apr 2012 09:38:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.524 X-Spam-Level: X-Spam-Status: No, score=-105.524 tagged_above=-999 required=5 tests=[AWL=1.075, 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 SBLAuA5dFY-o for ; Fri, 27 Apr 2012 09:38:57 -0700 (PDT) Received: from nbfkord-smmo03.seg.att.com (nbfkord-smmo03.seg.att.com [209.65.160.84]) by ietfa.amsl.com (Postfix) with ESMTP id 836B221F85A4 for ; Fri, 27 Apr 2012 09:38:24 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo03.seg.att.com(mxl_mta-6.11.0-8) over TLS secured channel with ESMTP id f7bca9f4.0.1896335.00-386.5277693.nbfkord-smmo03.seg.att.com (envelope-from ); Fri, 27 Apr 2012 16:38:25 +0000 (UTC) X-MXL-Hash: 4f9acb814555babf-51324acfec00b85de2d1a7f14ccb7c22844b83e3 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q3RGcNbB011175; Fri, 27 Apr 2012 12:38:23 -0400 Received: from sflint03.pst.cso.att.com (sflint03.pst.cso.att.com [144.154.234.230]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q3RGc5CZ010857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Apr 2012 12:38:19 -0400 Received: from GAALPA1MSGHUB9E.ITServices.sbc.com (gaalpa1msghub9e.itservices.sbc.com [130.8.36.91]) by sflint03.pst.cso.att.com (RSA Interceptor); Fri, 27 Apr 2012 12:37:40 -0400 Received: from GAALPA1MSGUSR9N.ITServices.sbc.com ([169.254.6.49]) by GAALPA1MSGHUB9E.ITServices.sbc.com ([130.8.36.91]) with mapi id 14.01.0355.002; Fri, 27 Apr 2012 12:37:39 -0400 From: "STARK, BARBARA H" To: Randy Bush , Sander Steffann Thread-Topic: [v6ops] 6rd sunsetting requirements (version 2) Thread-Index: AQHNJI6brwJ5hvhBW0+Y6Osyv2bvWZau3jgg Date: Fri, 27 Apr 2012 16:37:38 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6110A7865@GAALPA1MSGUSR9N.ITServices.sbc.com> References: <5B6B2B64C9FE2A489045EEEADDAFF2C30483722C@XMB-RCD-109.cisco.com> <4F95A3D9.1010100@viagenie.ca> <5B6B2B64C9FE2A489045EEEADDAFF2C304837261@XMB-RCD-109.cisco.com> <4F95ABA0.8090601@viagenie.ca> <5B6B2B64C9FE2A489045EEEADDAFF2C304837272@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30483747A@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3048378BB@XMB-RCD-109.cisco.com> <42D0E71D-8599-44C6-91D4-B059A276EB6A@cisco.com> <379ECFD4-C696-4B86-9DCA-75B0887C4370@townsley.net> <639FE0F2-ECD6-4C83-BB1F-9A9676ABCECB@townsley.net> <5B6B2B64C9FE2A489045EEEADDAFF2C30483801D@XMB-RCD-109.cisco.com> <50C59C32-B117-4EDB-AA8B-B4B207C82034@townsley.net> <5B6B2B64C9FE2A489045EEEADDAFF2C30483807B@XMB-RCD-109.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.28.49] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=1.0 c=1 a=nHguZITOP1UA:10 a=vTcfhpdngFkA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=Qs8R1XBwmid1qB] X-AnalysisOut: [FB/a8mmA==:17 a=PhEPzAsMLrkaGNsd3fEA:9 a=CjuIK1q_8ugA:10] Cc: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements (version 2) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 16:38:57 -0000 > >> 6RD-4: A CE router MUST allow 6rd virtual and IPv6 native WAN > >> interfaces to be active simultaneously in order to support > >> coexistence of the two technologies during an incremental migration > >> period from 6rd to native IPv6 or vice versa. > > I can't really see anyone who has a native IPv6 network migrate to > > 6rd, but that might be a limit of my imagination :-) >=20 > didn't you know that corner cases allow us to complicate things, which ma= kes > us more famous and gets more brownie points? It's been suggested that a provider might find themselves needing to back o= ut of a migration from 6rd to native IPv6, if the native deployment starts = running into problems. In effect, this would look like a migration from nat= ive IPv6 (back) to 6rd. Barbara From randy@psg.com Fri Apr 27 10:28:21 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC4921F8697 for ; Fri, 27 Apr 2012 10:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id srnqGab14vJI for ; Fri, 27 Apr 2012 10:28:21 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 049EF21F8694 for ; Fri, 27 Apr 2012 10:28:21 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SNoxu-0003qc-K7; Fri, 27 Apr 2012 17:28:18 +0000 Date: Fri, 27 Apr 2012 10:28:17 -0700 Message-ID: From: Randy Bush To: "STARK, BARBARA H" In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6110A7865@GAALPA1MSGUSR9N.ITServices.sbc.com> References: <5B6B2B64C9FE2A489045EEEADDAFF2C30483722C@XMB-RCD-109.cisco.com> <4F95A3D9.1010100@viagenie.ca> <5B6B2B64C9FE2A489045EEEADDAFF2C304837261@XMB-RCD-109.cisco.com> <4F95ABA0.8090601@viagenie.ca> <5B6B2B64C9FE2A489045EEEADDAFF2C304837272@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30483747A@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3048378BB@XMB-RCD-109.cisco.com> <42D0E71D-8599-44C6-91D4-B059A276EB6A@cisco.com> <379ECFD4-C696-4B86-9DCA-75B0887C4370@townsley.net> <639FE0F2-ECD6-4C83-BB1F-9A9676ABCECB@townsley.net> <5B6B2B64C9FE2A489045EEEADDAFF2C30483801D@XMB-RCD-109.cisco.com> <50C59C32-B117-4EDB-AA8B-B4B207C82034@townsley.net> <5B6B2B64C9FE2A489045EEEADDAFF2C30483807B@XMB-RCD-109.cisco.com> <2D09D61DDFA73D4C884805CC7865E6110A7865@GAALPA1MSGUSR9N.ITServices.sbc.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements (version 2) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 17:28:21 -0000 >> didn't you know that corner cases allow us to complicate things, which makes >> us more famous and gets more brownie points? > It's been suggested that a provider might find themselves needing to > back out of a migration from 6rd to native IPv6, if the native > deployment starts running into problems. In effect, this would look > like a migration from native IPv6 (back) to 6rd. we should also think about migration to decnet-2 randy From randy@psg.com Fri Apr 27 10:38:04 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3392921F8655 for ; Fri, 27 Apr 2012 10:38: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=[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 jEQcp85v4YI4 for ; Fri, 27 Apr 2012 10:38:03 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 95B3121F86EB for ; Fri, 27 Apr 2012 10:38:03 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SNp7L-0003sG-AX; Fri, 27 Apr 2012 17:38:03 +0000 Date: Fri, 27 Apr 2012 10:38:02 -0700 Message-ID: From: Randy Bush To: "STARK, BARBARA H" In-Reply-To: References: <5B6B2B64C9FE2A489045EEEADDAFF2C30483722C@XMB-RCD-109.cisco.com> <4F95A3D9.1010100@viagenie.ca> <5B6B2B64C9FE2A489045EEEADDAFF2C304837261@XMB-RCD-109.cisco.com> <4F95ABA0.8090601@viagenie.ca> <5B6B2B64C9FE2A489045EEEADDAFF2C304837272@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30483747A@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3048378BB@XMB-RCD-109.cisco.com> <42D0E71D-8599-44C6-91D4-B059A276EB6A@cisco.com> <379ECFD4-C696-4B86-9DCA-75B0887C4370@townsley.net> <639FE0F2-ECD6-4C83-BB1F-9A9676ABCECB@townsley.net> <5B6B2B64C9FE2A489045EEEADDAFF2C30483801D@XMB-RCD-109.cisco.com> <50C59C32-B117-4EDB-AA8B-B4B207C82034@townsley.net> <5B6B2B64C9FE2A489045EEEADDAFF2C30483807B@XMB-RCD-109.cisco.com> <2D09D61DDFA73D4C884805CC7865E6110A7865@GAALPA1MSGUSR9N.ITServices.sbc.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements (version 2) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 17:38:04 -0000 >> It's been suggested that a provider might find themselves needing to >> back out of a migration from 6rd to native IPv6, if the native >> deployment starts running into problems. In effect, this would look >> like a migration from native IPv6 (back) to 6rd. > we should also think about migration to decnet-2 sorry, my terseness came out a bit more rude than intended my point, meant generally, not just for this particular issue, is that we should design for the simple, common, clearly 'must have' cases. designing for corner cases gets us way too much complexity. we are very good at saying "what if cosmic rays strike" and not good at saying "damned unlikely, forget it." randy From cb.list6@gmail.com Fri Apr 27 12:02:54 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C90E21F859F for ; Fri, 27 Apr 2012 12:02:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_00=-2.599, J_BACKHAIR_55=1, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XXfvRb2BRKes for ; Fri, 27 Apr 2012 12:02:52 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 1443921F842E for ; Fri, 27 Apr 2012 12:02:52 -0700 (PDT) Received: by dady13 with SMTP id y13so1830935dad.27 for ; Fri, 27 Apr 2012 12:02:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=TxsVycMxkVsjOnZQgadM8Z3wRorv7XsUv5O6DtPn9AI=; b=uzKqX0okqPHAsuAs1x8tXpJxMmXqMUJkx3ANWy99+v5KvFmVw3RTJC3oDjUYVQkXvh zwGk4+gJWT9aSb/y2kqKZOXdkk1os6mnnbBMPZHhOcVMGklshTSLQBdi7Wm9pLyWQ5vi oVcodQV2b9E+W4V7TiiFqEt5LMwQRVtgk6Zrm1wEiE9PTA77pNkWFsK1z319A9qs+V8h pIacGVOWGL8+uHjJHdgcUqgjESE6UvhnZ01v/9NdZZMWT1bNb/rWF9dcLQSV8TydetTg N5f7A3M9tQNgwrzsd7VY0Vw7G20kFRTz5UwBedC9L4Rrh/blaWBrpuAqlBNfvEdR4LnG AerA== MIME-Version: 1.0 Received: by 10.68.240.5 with SMTP id vw5mr25324922pbc.110.1335553371780; Fri, 27 Apr 2012 12:02:51 -0700 (PDT) Received: by 10.142.102.1 with HTTP; Fri, 27 Apr 2012 12:02:51 -0700 (PDT) In-Reply-To: <5285C70C-89A8-4C99-AF24-5BB6AA055944@laposte.net> References: <20120417065542.31115.95082.idtracker@ietfa.amsl.com> <20120417160010kawashimam@mail.jp.nec.com> <56E2AD61-1C91-4889-914A-353793FCBE43@laposte.net> <20120419121044.17531mk1mv19abr4@mail.drown.org> <0646611B-5594-40EA-A2C4-F99CBA734024@laposte.net> <20120419181813.4524701l3gkq5zks@mail.drown.org> <45ABAD31-C265-4D63-82E2-3DE6F59B80C0@laposte.net> <20120420104246.1432746csfcrdqo8@mail.drown.org> <20120423105716.130762z7e8air84c@mail.drown.org> <20120424111859.199819d07k06j140@mail.drown.org> <5285C70C-89A8-4C99-AF24-5BB6AA055944@laposte.net> Date: Fri, 27 Apr 2012 12:02:51 -0700 Message-ID: From: Cameron Byrne To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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, 27 Apr 2012 19:02:54 -0000 R=E9mi On Fri, Apr 27, 2012 at 9:25 AM, R=E9mi Despr=E9s wrote: > > Le 2012-04-27 =E0 17:39, Cameron Byrne a =E9crit : > > > On Apr 27, 2012 5:32 AM, "R=E9mi Despr=E9s" wr= ote: >> >> Dan, Gang, Cameron, >> >> Could this issue be clarified? >> >> In my understanding: >> - With a NAT44 and an IPv4 router in the CLAT node, IPv4 applications >> communicate via this router. >> - In this router: >> =A0. WAN-side servers, because they have public IPv4 addresses, are reac= hed >> via the NAT44, and in case of IPv6-only network having a NAT64 via the C= LAT >> (but not via the in-node IPv6 router) >> =A0. LAN-side servers, because they have RFC1918 addresses, are reached = in >> IPv4 via the in-node router. They are not concerned with IPv6. >> With this understanding, no text needs to be added in the specification >> (or only to clarify the above). >> >> Anything missed? >> > > I think your understanding is the same as mine, if you are saying the 02 > revision does not need modification. > > For LAN to LAN communication, the CLAT does not modify packets. > > For LAN to WAN, CLAT does not modify ipv6 packets either to the public ip= v6 > server or to ipv4 servers that are reached via PLAT + DNS64.=A0 For LAN i= pv4 > to WAN ipv4 across an ipv6-only access network, nat44 & rfc6145 are appli= ed > at the clat and rfc 6146 at the PLAT. > > > In full sync so far. > > Unless there is a larger than /64 prefix assigned to the CLAT, then the C= LAT > only needs to do rfc6145 and no nat44. > > In case of tethering, which is=A0the context discussed by Gang and Dan, a= lways > including a NAT44 is in my understanding much simpler than trying to > dispense with it. > I see no need to document anything else in a BCP. > > Now, I agree that a CLAT node WITHOUT tethering MAY dispense with a NAT44= . > But it is worth noting that it MAY include a NAT44, in which case a commo= n > architecture applies to all cases. > > This behavior is documented in the draft 02 is in the traffic treatment > scenario chart. > > If the NAT44 is the IPv4 client of the scenario chart, the chart can appl= y > as well=A0to tethering=A0as to tethering-less. It becomes generic. > > RD > The use case for not doing NAT44 is not really the mobile phone case we have today on my network. It is more the case of a future mobile phone that allows DHCP-PD or a FTTH network where a block of IPv6 address is provided to the CPE/CLAT. For example, i imagine it will be common for a home broadband user to use DHCP-PD to get a /60 or /56 -- one prefix. From this one delegated prefix, a /64 may be used to simplify the CLAT to just RFC6145 and removing the need for NAT44. I hope you don't see the inclusion of this particular scenario as a road block to BCP, it is known to work, i posted Cisco configs for it here before. There is a balance to be had between "the one scenario" and creating options that make, within reason, that allow networks to deploy what they find most appealing. For example, the NAT4464 scenario looks, on paper, much less desirable than a NAT464 scenario. In the real world, there is no difference in the service level AFAIK ... but there may be difference in CPE implementation level of effort. For example, i cannot get the NAT446<->NAT64 to work on the Cisco CLAT but i can get NAT46<->NAT64 to work using today's generally available implementation. CB > >> Regards, >> RD >> >> >> >> Le 2012-04-27 =E0 12:35, Cameron Byrne a =E9crit : >> >> > Hi All, >> > >> > Is there any suggested text from the conclusion of this threat that >> > should be brought into the 03 update of the draft? >> > >> > CB >> > >> > On Tue, Apr 24, 2012 at 9:18 AM, Dan Drown wrote= : >> >> Quoting GangChen : >> >>> >> >>> Assuming IPv6 apps on the CLAT would talk to severs either on cell >> >>> network side or wifi tethering network side >> >>> I guess CLAT should bind apps to different interface (i.e PPP int or >> >>> eth int) according to the route to the destination. >> >>> Eg: >> >>> PPP_int: 2607:fb90:800:68c::eae6:901 >> >>> eth_int: 2607:fb90:800:68c::eae6:901 >> >>> >> >>> In the case, >> >>> CLAT set default gateway pointing to 3GPP interface(i.e. PPP_int) >> >>> Des: eth_int 2607:fb90:800:68c::eae6:902 >> >>> >> >>> Select: eth_int: 2607:fb90:800:68c::eae6:901 >> >> >> >> >> >> The only thing I would change in your explanation is: this is the >> >> generic >> >> process that happens to all Linux machines with multiple ipv6 >> >> interfaces, it >> >> is not something specific to or changed in CLAT or 464XLAT. >> >> >> >> _______________________________________________ >> >> 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 >> > > On Apr 27, 2012 5:32 AM, "R=E9mi Despr=E9s" wr= ote: >> >> Dan, Gang, Cameron, >> >> Could this issue be clarified? >> >> In my understanding: >> - With a NAT44 and an IPv4 router in the CLAT node, IPv4 applications >> communicate via this router. >> - In this router: >> =A0. WAN-side servers, because they have public IPv4 addresses, are reac= hed >> via the NAT44, and in case of IPv6-only network having a NAT64 via the C= LAT >> (but not via the in-node IPv6 router) >> =A0. LAN-side servers, because they have RFC1918 addresses, are reached = in >> IPv4 via the in-node router. They are not concerned with IPv6. >> With this understanding, no text needs to be added in the specification >> (or only to clarify the above). >> >> Anything missed? >> >> Regards, >> RD >> >> >> >> Le 2012-04-27 =E0 12:35, Cameron Byrne a =E9crit : >> >> > Hi All, >> > >> > Is there any suggested text from the conclusion of this threat that >> > should be brought into the 03 update of the draft? >> > >> > CB >> > >> > On Tue, Apr 24, 2012 at 9:18 AM, Dan Drown wrote= : >> >> Quoting GangChen : >> >>> >> >>> Assuming IPv6 apps on the CLAT would talk to severs either on cell >> >>> network side or wifi tethering network side >> >>> I guess CLAT should bind apps to different interface (i.e PPP int or >> >>> eth int) according to the route to the destination. >> >>> Eg: >> >>> PPP_int: 2607:fb90:800:68c::eae6:901 >> >>> eth_int: 2607:fb90:800:68c::eae6:901 >> >>> >> >>> In the case, >> >>> CLAT set default gateway pointing to 3GPP interface(i.e. PPP_int) >> >>> Des: eth_int 2607:fb90:800:68c::eae6:902 >> >>> >> >>> Select: eth_int: 2607:fb90:800:68c::eae6:901 >> >> >> >> >> >> The only thing I would change in your explanation is: this is the >> >> generic >> >> process that happens to all Linux machines with multiple ipv6 >> >> interfaces, it >> >> is not something specific to or changed in CLAT or 464XLAT. >> >> >> >> _______________________________________________ >> >> 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 jhw@apple.com Fri Apr 27 12:44:01 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD6D21F8613 for ; Fri, 27 Apr 2012 12:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3LlIRhSghBvr for ; Fri, 27 Apr 2012 12:44:00 -0700 (PDT) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 8B94121F85C5 for ; Fri, 27 Apr 2012 12:44:00 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Received: from relay14.apple.com ([17.128.113.52]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPS id <0M350031GLGF4TC1@mail-out.apple.com> for v6ops@ietf.org; Fri, 27 Apr 2012 12:43:34 -0700 (PDT) X-AuditID: 11807134-b7fe56d000004e7a-3d-4f9af6e69659 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 6A.97.20090.6E6FA9F4; Fri, 27 Apr 2012 12:43:34 -0700 (PDT) From: james woodyatt In-reply-to: <4F99BAFC.7090505@gont.com.ar> Date: Fri, 27 Apr 2012 12:43:34 -0700 Content-transfer-encoding: quoted-printable Message-id: References: <54469FB9-D118-4157-B9D6-8F52F7F96002@cisco.com> <4F99BAFC.7090505@gont.com.ar> To: "v6ops@ietf.org WG" X-Mailer: Apple Mail (2.1455) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMLMWRmVeSWpSXmKPExsUieJDXQffZt1n+BocfKlucXnCC0eL0sb3M DkweS5b8ZPL4cvkzWwBTFJdNSmpOZllqkb5dAldGz+4LbAXTOSvW7V3E1sC4gb2LkYNDQsBE 4vSRzC5GTiBTTOLCvfVsXYxcHEICs5kkNtx5ygSSYBbQkdi59Q4biM0roCcx/9IaMFtYwEni 5opF7CA2m4CKxLfLd8HqOQW0JZY8ms8KMp9FQFXi6WI9iDHWEq+/fWWBsLUlli18zQwx0kbi 087nrBB7exglnvw+DTZfREBDomvLHzaI42QlPj/6yzKBkX8WkpNmITlpFpK5CxiZVzEKFqXm JFYamuglFhTkpOol5+duYgQFXUOhyQ7Ggz/5DzEKcDAq8fBmrp3lL8SaWFZcmXuIUYKDWUmE N/MOUIg3JbGyKrUoP76oNCe1+BCjNAeLkjivUuMMfyGB9MSS1OzU1ILUIpgsEwenVANj1em8 DYWl6Zemyb2QWt59J49v44PsTf0if4MnyNi8Xs8t+O7Rz0TdsBU1i1sWi6ox73j7KO9b1rPz O/ITbSrkrtcvPTb11zPRD9IRrNoZmzdO87V6+pFjx8HM82uVDR0N51Q9bt2WotYhOXHCjceB eRd5Hu/UVrVlkZCcu3Atr+EWpaa/m+8dVWIpzkg01GIuKk4EAH8OTMI2AgAA Cc: draft-ietf-v6ops-ra-guard-implementation@tools.ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-ra-guard-implementation WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 19:44:01 -0000 On Apr 26, 2012, at 14:15 , Fernando Gont wrote: >=20 > I thought this was implicit. But if you think this would be = appropriate and/or valuable, I have no problem with including the = aforementioned reference. RFC 6564 is the reason that following the extension header chain all the = way to the transport protocol is even *decidable* under the latest = standards track documentation. The principle reason we wrote RFC 6564 = in the first place was so that it could be cited in drafts like this = one. It would be a shame if all the effort required to get an update to = RFC 2460 for this purpose were to go to waste here. My worry is that implementors may overlook the uniform extension header = specification and encode na=EFve algorithms in hardware deployments with = very long lifespan that incorrectly drop normal packets and/or pass = rogue router advertisement packets with otherwise unidentifiable, yet = uniform, extension headers. I'm pleased that you're willing to make this editorial change during = WGLC. Thank you. -- james woodyatt member of technical staff, core os networking From fernando.gont.netbook.win@gmail.com Sat Apr 28 05:38:45 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA93021F8650 for ; Sat, 28 Apr 2012 05:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.198 X-Spam-Level: X-Spam-Status: No, score=-3.198 tagged_above=-999 required=5 tests=[AWL=0.401, 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 omVbVOKQPWTl for ; Sat, 28 Apr 2012 05:38:45 -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 E280B21F861D for ; Sat, 28 Apr 2012 05:38:44 -0700 (PDT) Received: by ghbg16 with SMTP id g16so1002821ghb.31 for ; Sat, 28 Apr 2012 05:38:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=qswk9fhwKxcLz5tKy7G74oHBcZVd2Bev86FZMQc6YTw=; b=LVnVXMuC5k8UYAlbGJ7an48+NplArvfjR9wigvlQEy1R65Ve8gDId3kk8dEpDdpZ9b 0OB+6xeH+ogrkGltxHvqjOqQucPl8jN5c6Mp6yEYuH/35CuHmC8/iy0WmUlGBv1eJp4S DVmRI7R/UtijKi3gRlBClJHMSucdmbeg3uU+DuaYDfCde9P4tXbxnJfNGGvFw7r10JE1 tAvWxqk0+z2TDXnY3/foLdP6ugEBEDTIHSbvLvkalg9Rywy6BKrtHGVzeJU/4FEk4ojs uCXJ+wioociOgpS071a9bKouQA+7Uz8xcrxdxx7RpkFmroStHCDPn5WZ7uE6jNw3zGKt LqLg== Received: by 10.236.153.36 with SMTP id e24mr7331494yhk.66.1335616724553; Sat, 28 Apr 2012 05:38:44 -0700 (PDT) Received: from [192.168.0.177] ([190.190.97.123]) by mx.google.com with ESMTPS id r6sm27938387yhj.0.2012.04.28.05.38.30 (version=SSLv3 cipher=OTHER); Sat, 28 Apr 2012 05:38:43 -0700 (PDT) Sender: Fernando Gont Message-ID: <4F9BE4A8.2030904@gont.com.ar> Date: Sat, 28 Apr 2012 09:38:00 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120412 Thunderbird/11.0.1 MIME-Version: 1.0 To: james woodyatt References: <54469FB9-D118-4157-B9D6-8F52F7F96002@cisco.com> <4F99BAFC.7090505@gont.com.ar> In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "v6ops@ietf.org WG" , draft-ietf-v6ops-ra-guard-implementation@tools.ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-ra-guard-implementation WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Apr 2012 12:38:45 -0000 On 04/27/2012 04:43 PM, james woodyatt wrote: >> I thought this was implicit. But if you think this would be >> appropriate and/or valuable, I have no problem with including the >> aforementioned reference. > > RFC 6564 is the reason that following the extension header chain all > the way to the transport protocol is even *decidable* under the > latest standards track documentation. Agreed. > My worry is that implementors may overlook the uniform extension > header specification and encode naïve algorithms in hardware > deployments with very long lifespan that incorrectly drop normal > packets and/or pass rogue router advertisement packets with otherwise > unidentifiable, yet uniform, extension headers. Fair enough. > I'm pleased that you're willing to make this editorial change during > WGLC. I've added this parenthetical note right below Filtering Rule #1 of version -02 of the document: [RFC6564] specifies a uniform format for IPv6 Extension Headers, thus meaning that an IPv6 node should be able to parse an IPv6 header chain even if it contains Extension Headers that are not currently supported by that node. Please let me know if this addresses your concern. Thanks! Best regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From fgont@si6networks.com Sat Apr 28 07:02:57 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2021121F8658 for ; Sat, 28 Apr 2012 07:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.427 X-Spam-Level: X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[AWL=0.172, 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 coMz5I09VU73 for ; Sat, 28 Apr 2012 07:02:56 -0700 (PDT) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 894A021F8615 for ; Sat, 28 Apr 2012 07:02:56 -0700 (PDT) Received: from [190.190.97.123] (helo=[192.168.0.177]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SO8EU-0006Yc-J2; Sat, 28 Apr 2012 16:02:44 +0200 Message-ID: <4F9BF857.7080205@si6networks.com> Date: Sat, 28 Apr 2012 11:01:59 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120412 Thunderbird/11.0.1 MIME-Version: 1.0 To: Joel jaeggli References: <54469FB9-D118-4157-B9D6-8F52F7F96002@cisco.com> <4F948546.8040205@inex.ie> <4F94A74F.6090409@bogus.com> In-Reply-To: <4F94A74F.6090409@bogus.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-ra-guard-implementation WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Apr 2012 14:02:57 -0000 On 04/22/2012 09:50 PM, Joel jaeggli wrote: >> reading back over this, I wonder would it be useful to make a >> recommendation to vendors to implement some form of logging for dropped >> packets so that operators can choose to have visibility into this problem >> on their networks. Silently dropping packets is all very well, but many >> operators like to feel that if a packet is dropped, they should know about it. > > implementing a drop counter on what's essentially a firewall rule seems > like a good idea, but also an implementation detail. if there's nowhere > to log it and nobody to report it to it's not very useful to count them. > if there are either of those things then yeah it's certainly worthwhile. So... should I add a small comment about this? A "MAY"? (I think "SHOULD" would be too strong). Or maybe a note without RFC2119-language? What do you folks think? Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nick@inex.ie Sat Apr 28 07:20:52 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97E8A21F86CA for ; Sat, 28 Apr 2012 07:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6NScj1kDpt+0 for ; Sat, 28 Apr 2012 07:20:52 -0700 (PDT) Received: from mail.acquirer.com (mail.acquirer.com [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id E7F8421F86CE for ; Sat, 28 Apr 2012 07:20:50 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from [10.37.11.244] (bla-fw-01-0.fwa.net.o2.ie [62.40.36.13] (may be forged)) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id q3SEKE5Y016210 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 28 Apr 2012 15:20:20 +0100 (IST) (envelope-from nick@inex.ie) References: <54469FB9-D118-4157-B9D6-8F52F7F96002@cisco.com> <4F948546.8040205@inex.ie> <4F94A74F.6090409@bogus.com> <4F9BF857.7080205@si6networks.com> In-Reply-To: <4F9BF857.7080205@si6networks.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (9B176) From: Nick Hilliard Date: Sat, 28 Apr 2012 15:20:39 +0100 To: Fernando Gont Cc: "v6ops@ietf.org" , "v6ops-chairs@tools.ietf.org" , Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-ra-guard-implementation WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Apr 2012 14:20:52 -0000 On 28 Apr 2012, at 15:01, Fernando Gont wrote: > So... should I add a small comment about this? A "MAY"? (I think > "SHOULD" would be too strong). Or maybe a note without RFC2119-language? I was thinking along the lines of SHOULD actually. Silently black holing tra= ffic is pretty unforgivable.=20 Nick From fgont@si6networks.com Sat Apr 28 07:37:21 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7227521F865A for ; Sat, 28 Apr 2012 07:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FscWORXsX2uA for ; Sat, 28 Apr 2012 07:37:21 -0700 (PDT) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id E3DC621F8658 for ; Sat, 28 Apr 2012 07:37:20 -0700 (PDT) Received: from [190.190.97.123] (helo=[192.168.0.177]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SO8ln-0006mc-RX; Sat, 28 Apr 2012 16:37:10 +0200 Message-ID: <4F9C0063.70309@si6networks.com> Date: Sat, 28 Apr 2012 11:36:19 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120412 Thunderbird/11.0.1 MIME-Version: 1.0 To: Nick Hilliard References: <54469FB9-D118-4157-B9D6-8F52F7F96002@cisco.com> <4F948546.8040205@inex.ie> <4F94A74F.6090409@bogus.com> <4F9BF857.7080205@si6networks.com> In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , "v6ops-chairs@tools.ietf.org" , Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-ra-guard-implementation WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Apr 2012 14:37:21 -0000 On 04/28/2012 11:20 AM, Nick Hilliard wrote: > On 28 Apr 2012, at 15:01, Fernando Gont wrote: >> So... should I add a small comment about this? A "MAY"? (I think >> "SHOULD" would be too strong). Or maybe a note without RFC2119-language? > > I was thinking along the lines of SHOULD actually. Silently black holing traffic is pretty unforgivable. I was just thinking considering Joel's notes, and considering that if we were to incorporate this as a SHOULD, and an implementation didn't have the ability to provide this logging facility, it wouldn't be compliant with this document. -- but this is just me thinking out loud (of course, I agree that logging would be useful... just wondering how to actually incorporate this in the document). Can others weigh in? -- FWIW, I have no problem incorporating this as a MAY, SHOULD, or whatever the wg thinks is more appropriate. Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nick@inex.ie Sat Apr 28 10:08:13 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A8D521F85C6 for ; Sat, 28 Apr 2012 10:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3KRo4cvuvtqL for ; Sat, 28 Apr 2012 10:08:12 -0700 (PDT) Received: from mail.acquirer.com (mail.acquirer.com [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 8266321F85BE for ; Sat, 28 Apr 2012 10:08:11 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from crumpet.foobar.org ([IPv6:2001:4d68:2002:100:e8d2:9efa:1bde:be2b]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id q3SH7ahG017263 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 28 Apr 2012 18:07:41 +0100 (IST) (envelope-from nick@inex.ie) Message-ID: <4F9C23EC.90009@inex.ie> Date: Sat, 28 Apr 2012 18:07:56 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Fernando Gont References: <54469FB9-D118-4157-B9D6-8F52F7F96002@cisco.com> <4F948546.8040205@inex.ie> <4F94A74F.6090409@bogus.com> <4F9BF857.7080205@si6networks.com> <4F9C0063.70309@si6networks.com> In-Reply-To: <4F9C0063.70309@si6networks.com> X-Enigmail-Version: 1.4.1 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , "v6ops-chairs@tools.ietf.org" , Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-ra-guard-implementation WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Apr 2012 17:08:13 -0000 On 28/04/2012 15:36, Fernando Gont wrote: > I was just thinking considering Joel's notes, and considering that if we > were to incorporate this as a SHOULD, and an implementation didn't have > the ability to provide this logging facility, it wouldn't be compliant > with this document. -- but this is just me thinking out loud (of course, > I agree that logging would be useful... just wondering how to actually > incorporate this in the document). No, actually: you can omit SHOULDs from an implementation and still be fully compliant with the rfc. SHOULD is a recommendation; MUST is a requirement. Nick From fgont@si6networks.com Sat Apr 28 11:35:30 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC1C21F860D for ; Sat, 28 Apr 2012 11:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i2PPcG0Pbi+Q for ; Sat, 28 Apr 2012 11:35:29 -0700 (PDT) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id CBFE021F85E1 for ; Sat, 28 Apr 2012 11:35:29 -0700 (PDT) Received: from [186.134.11.143] (helo=[192.168.123.103]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SOCUF-0008VU-HF; Sat, 28 Apr 2012 20:35:17 +0200 Message-ID: <4F9C3856.6060706@si6networks.com> Date: Sat, 28 Apr 2012 15:35:02 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120412 Thunderbird/11.0.1 MIME-Version: 1.0 To: Nick Hilliard References: <54469FB9-D118-4157-B9D6-8F52F7F96002@cisco.com> <4F948546.8040205@inex.ie> <4F94A74F.6090409@bogus.com> <4F9BF857.7080205@si6networks.com> <4F9C0063.70309@si6networks.com> <4F9C23EC.90009@inex.ie> In-Reply-To: <4F9C23EC.90009@inex.ie> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , "v6ops-chairs@tools.ietf.org" , Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-ra-guard-implementation WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Apr 2012 18:35:30 -0000 On 04/28/2012 02:07 PM, Nick Hilliard wrote: > On 28/04/2012 15:36, Fernando Gont wrote: >> I was just thinking considering Joel's notes, and considering that if we >> were to incorporate this as a SHOULD, and an implementation didn't have >> the ability to provide this logging facility, it wouldn't be compliant >> with this document. -- but this is just me thinking out loud (of course, >> I agree that logging would be useful... just wondering how to actually >> incorporate this in the document). > > No, actually: you can omit SHOULDs from an implementation and still be > fully compliant with the rfc. I've re-checked, and you're right: such an implementation would be called: "compliant" or "conditionally compliant". -- I've looked this up in RFC 2119, and it's not there, so it might be just "common practice" (similar wording is in many RFCs).. but since I've not got any sleep for 24hs, I will try to find later (hopefully with better luck :-) ). Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From joelja@bogus.com Sun Apr 29 23:10:46 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F075321F8534 for ; Sun, 29 Apr 2012 23:10:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.908 X-Spam-Level: X-Spam-Status: No, score=-101.908 tagged_above=-999 required=5 tests=[AWL=-0.209, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SfAGoNjxOnOb for ; Sun, 29 Apr 2012 23:10:45 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 3139421F852D for ; Sun, 29 Apr 2012 23:10:45 -0700 (PDT) Received: from Joels-MacBook-Pro.local (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q3U6AepD030102 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Mon, 30 Apr 2012 06:10:41 GMT (envelope-from joelja@bogus.com) Message-ID: <4F9E2CE0.50703@bogus.com> Date: Sun, 29 Apr 2012 23:10:40 -0700 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Ole_Tr=F8an?= References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Mon, 30 Apr 2012 06:10:42 +0000 (UTC) Cc: IPv6 Operations , "v6ops-chairs@tools.ietf.org Chairs" , draft-ietf-v6ops-6204bis@tools.ietf.org Subject: Re: [v6ops] 6204bis - editorship X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 06:10:46 -0000 noted On 4/27/12 04:32 , Ole Trĝan wrote: > authors, chairs, > > as a matter of house-keeping; as I haven't been editing the 6204bis version, > could you please take my name off the authors-list before sending it over to the IESG? > > cheers, > Ole > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From fred@cisco.com Sun Apr 29 23:13:44 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2152821F8570 for ; Sun, 29 Apr 2012 23:13:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.604 X-Spam-Level: X-Spam-Status: No, score=-110.604 tagged_above=-999 required=5 tests=[AWL=-0.006, 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 W+Ykm4smFurP for ; Sun, 29 Apr 2012 23:13:43 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 8753821F856A for ; Sun, 29 Apr 2012 23:13:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=997; q=dns/txt; s=iport; t=1335766423; x=1336976023; h=from:subject:date:message-id:cc:to:mime-version; bh=8TY+BxamQ+C02rdiLEOnn/iyq6WAQ/JteL/R4nsF0T8=; b=IPXXXm73bapHldmRE3mFECgJc8QvEXvE+G2MKGkmwt/59KvhY/0sLu15 KSJxAd0FoCce8KsPtA+Uid2Sk+MVIcT3AGPk98+2mPQBgtltM8GFHccrk uginbtt8jD4KNOj2wA+3jev4jxWY+N2ClXWCrhneP7RVKmK89z0xXL3up A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAF8snk+rRDoG/2dsb2JhbABEgkavWoEHggAiAQpcHgGBVIdqmWCfDI19gkJjBIhkjRqFdohjgWmDCA X-IronPort-AV: E=Sophos;i="4.75,502,1330905600"; d="scan'208,217";a="40178439" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 30 Apr 2012 06:13:40 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q3U6DcLi010884; Mon, 30 Apr 2012 06:13:39 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Sun, 29 Apr 2012 23:13:40 -0700 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Sun, 29 Apr 2012 23:13:40 -0700 From: Fred Baker Date: Sun, 29 Apr 2012 23:12:23 -0700 Message-Id: To: v6ops@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Content-Type: multipart/alternative; boundary=Apple-Mail-19-976858214 Cc: v6ops-chairs@tools.ietf.org, Ron Bonica Subject: [v6ops] Reminder: draft-ietf-v6ops-ra-guard-implementation WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 06:13:44 -0000 --Apple-Mail-19-976858214 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The working group last call for this draft announced last week continues = for another week. Please feel free to comment on it. --Apple-Mail-19-976858214 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
    The working group last call for this draft announced last week continues for another week. Please feel free to comment on it.

    --Apple-Mail-19-976858214-- From bs7652@att.com Mon Apr 30 05:06:29 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 576C121F8625 for ; Mon, 30 Apr 2012 05:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.739 X-Spam-Level: X-Spam-Status: No, score=-105.739 tagged_above=-999 required=5 tests=[AWL=0.860, 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 kb3aqeC1uVNh for ; Mon, 30 Apr 2012 05:06:28 -0700 (PDT) Received: from nbfkord-smmo04.seg.att.com (nbfkord-smmo04.seg.att.com [209.65.160.86]) by ietfa.amsl.com (Postfix) with ESMTP id 3DE1521F8621 for ; Mon, 30 Apr 2012 05:06:28 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo04.seg.att.com(mxl_mta-6.11.0-8) over TLS secured channel with ESMTP id 3408e9f4.0.144931.00-476.376358.nbfkord-smmo04.seg.att.com (envelope-from ); Mon, 30 Apr 2012 12:06:28 +0000 (UTC) X-MXL-Hash: 4f9e804459230ca0-84db2220b287f1772c0f1e2c971c37689c5a6b1b Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q3UC6R6T012787 for ; Mon, 30 Apr 2012 08:06:27 -0400 Received: from sflint04.pst.cso.att.com (sflint04.pst.cso.att.com [144.154.234.231]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q3UC6Mco012778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 30 Apr 2012 08:06:22 -0400 Received: from GAALPA1MSGHUB9A.ITServices.sbc.com (gaalpa1msghub9a.itservices.sbc.com [130.8.36.87]) by sflint04.pst.cso.att.com (RSA Interceptor) for ; Mon, 30 Apr 2012 08:05:53 -0400 Received: from GAALPA1MSGUSR9N.ITServices.sbc.com ([169.254.6.49]) by GAALPA1MSGHUB9A.ITServices.sbc.com ([130.8.36.87]) with mapi id 14.01.0355.002; Mon, 30 Apr 2012 08:05:52 -0400 From: "STARK, BARBARA H" To: "v6ops@ietf.org" Thread-Topic: (S)NTP in 6204bis Thread-Index: Ac0myZUhauwjtOVfSFuWu+r+34uEag== Date: Mon, 30 Apr 2012 12:05:51 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6110A7F1D@GAALPA1MSGUSR9N.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.86.158] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=1.0 c=1 a=KfbkHLZveIoA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHo] X-AnalysisOut: [wA:10 a=kj9zAlcOel0A:10 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a=2y] X-AnalysisOut: [sHOlqHyGHzGUtkB0MA:9 a=CjuIK1q_8ugA:10] Subject: [v6ops] (S)NTP in 6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 12:06:29 -0000 A colleague of mine pointed out to me that 6204 and 6204bis reference RFC 4= 075 for the DHCPv6 SNTP server option, and that RFC 5098 claims in the body= of its text (section 7) to deprecate 4075. Should we be recommending use o= f 4075 or 5098 in 6204(bis)? Barbara From shemant@cisco.com Mon Apr 30 05:33:18 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ECF321F8595 for ; Mon, 30 Apr 2012 05:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.149 X-Spam-Level: X-Spam-Status: No, score=-10.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bvp8EhtPkf1A for ; Mon, 30 Apr 2012 05:33:17 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id D179221F8592 for ; Mon, 30 Apr 2012 05:33:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=736; q=dns/txt; s=iport; t=1335789198; x=1336998798; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=0p8MMw6h/NKYByNI2Bi9W1R1S2boJ8GQ81BEVQ/lkyA=; b=NKb+74PtRlZLuJEuGV1w726uQcUonFNXQEL0FfONLqcKNXnInZZbkCg4 xJjWotXNUGs0AieIalB+m85jPZA9s+MBlfLKI7MtZ+TtgBpjxAdyBLCi/ RHnvEgcIAaoXzMHeZPYkDcF/6WgrFsPWHz3j4V9dlA5kONoV7FRKgaxhW M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAOaFnk+tJV2c/2dsb2JhbABEr0eDAIEHggkBAQEEAQEBDwEdCjQXBAIBCBEEAQELBhcBBgEmHwkIAQEEARIIGodrC5l0n0cEkD9jBIhkm3OBaYMG X-IronPort-AV: E=Sophos;i="4.75,504,1330905600"; d="scan'208";a="78806446" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 30 Apr 2012 12:33:17 +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 q3UCXHHS003167; Mon, 30 Apr 2012 12:33:17 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, 30 Apr 2012 07:33: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="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 30 Apr 2012 07:33:16 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3048C36F0@XMB-RCD-109.cisco.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6110A7F1D@GAALPA1MSGUSR9N.ITServices.sbc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] (S)NTP in 6204bis Thread-Index: Ac0myZUhauwjtOVfSFuWu+r+34uEagAA7Azg References: <2D09D61DDFA73D4C884805CC7865E6110A7F1D@GAALPA1MSGUSR9N.ITServices.sbc.com> From: "Hemant Singh (shemant)" To: "STARK, BARBARA H" , X-OriginalArrivalTime: 30 Apr 2012 12:33:17.0233 (UTC) FILETIME=[6B33F210:01CD26CD] Subject: Re: [v6ops] (S)NTP in 6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 12:33:18 -0000 Barbara, Section 7 of RFC 5098 is the Acknowledgements section. Is RFC 5098 the correct RFC? Thanks, Hemant -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of STARK, BARBARA H Sent: Monday, April 30, 2012 8:06 AM To: v6ops@ietf.org Subject: [v6ops] (S)NTP in 6204bis A colleague of mine pointed out to me that 6204 and 6204bis reference RFC 4075 for the DHCPv6 SNTP server option, and that RFC 5098 claims in the body of its text (section 7) to deprecate 4075. Should we be recommending use of 4075 or 5098 in 6204(bis)? Barbara _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From hansliu@gmail.com Mon Apr 30 06:09:12 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0363321F863D for ; Mon, 30 Apr 2012 06:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0MkcQ47VHFz for ; Mon, 30 Apr 2012 06:09:11 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2E53521F8637 for ; Mon, 30 Apr 2012 06:09:10 -0700 (PDT) Received: by lbbgm13 with SMTP id gm13so2043277lbb.31 for ; Mon, 30 Apr 2012 06:09:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=bTJLqJ39HIn0n7VYhmvxDfChlPCclFUTed1DvoAj30Y=; b=OtZFYRGv8QCFuvPR17hqrNj0rHgQjALjsfJfIXodXibyMM1u2o0Y9ht6urH5qv9hxv f55pG5rAbCj4XatcElxdg2K4i9s16s3DuXsOEL/aTwP1wtdmR4mWRb7fpeNQEAui4J4g fVT206l0VVr5lqv1t8oBw8R7oUMFC5MqvE++w1b7Z49chaa5q+1ShKPSv1NBT9H1nLNJ 8vtV9k2SHXD0fFbB7ni7cuYFsOSKBl/S8TDlky0XAV+llJnmqtbiFbiBxC67Oq78rV7P PqqzPZHp0GvQ87deqAOnDn3GnVBA1PTs4U5WSuR1QW8mt5zVbiBnE9lmSybP3y/JHHiF aSiw== MIME-Version: 1.0 Received: by 10.152.110.116 with SMTP id hz20mr19718308lab.33.1335791350045; Mon, 30 Apr 2012 06:09:10 -0700 (PDT) Received: by 10.112.43.8 with HTTP; Mon, 30 Apr 2012 06:09:09 -0700 (PDT) In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3048C36F0@XMB-RCD-109.cisco.com> References: <2D09D61DDFA73D4C884805CC7865E6110A7F1D@GAALPA1MSGUSR9N.ITServices.sbc.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3048C36F0@XMB-RCD-109.cisco.com> Date: Mon, 30 Apr 2012 21:09:09 +0800 Message-ID: From: Hans Liu To: "Hemant Singh (shemant)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org Subject: Re: [v6ops] (S)NTP in 6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 13:09:12 -0000 RFC 5908 !? :) Best regards, Hans On Mon, Apr 30, 2012 at 8:33 PM, Hemant Singh (shemant) wrote: > Barbara, > > Section 7 of RFC 5098 is the Acknowledgements section. =C2=A0Is RFC 5098 = the > correct RFC? > > Thanks, > > Hemant > > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of STARK, BARBARA H > Sent: Monday, April 30, 2012 8:06 AM > To: v6ops@ietf.org > Subject: [v6ops] (S)NTP in 6204bis > > A colleague of mine pointed out to me that 6204 and 6204bis reference > RFC 4075 for the DHCPv6 SNTP server option, and that RFC 5098 claims in > the body of its text (section 7) to deprecate 4075. Should we be > recommending use of 4075 or 5098 in 6204(bis)? > Barbara > _______________________________________________ > 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 Instead of following the fashion, we lead it through. From bs7652@att.com Mon Apr 30 06:30:54 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B0A421F85F4 for ; Mon, 30 Apr 2012 06:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.582 X-Spam-Level: X-Spam-Status: No, score=-103.582 tagged_above=-999 required=5 tests=[AWL=-1.583, 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 vGqkKvBqEGkz for ; Mon, 30 Apr 2012 06:30:53 -0700 (PDT) Received: from nbfkord-smmo08.seg.att.com (nbfkord-smmo08.seg.att.com [209.65.160.95]) by ietfa.amsl.com (Postfix) with ESMTP id A608421F85D9 for ; Mon, 30 Apr 2012 06:30:53 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo08.seg.att.com) by nbfkord-smmo08.seg.att.com(mxl_mta-6.11.0-8) with ESMTP id d049e9f4.5e19c940.559369.00-569.1509043.nbfkord-smmo08.seg.att.com (envelope-from ); Mon, 30 Apr 2012 13:30:53 +0000 (UTC) X-MXL-Hash: 4f9e940d3ad65854-f2493c83adcd41d6f4476767be6f7e33806f4017 Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo08.seg.att.com(mxl_mta-6.11.0-8) over TLS secured channel with ESMTP id 4049e9f4.0.559312.00-477.1508875.nbfkord-smmo08.seg.att.com (envelope-from ); Mon, 30 Apr 2012 13:30:44 +0000 (UTC) X-MXL-Hash: 4f9e9404315eddd5-bb2911906b40bfbcf5fc32838869b8ee46785426 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q3UDUhW7008993; Mon, 30 Apr 2012 09:30:44 -0400 Received: from sflint04.pst.cso.att.com (sflint04.pst.cso.att.com [144.154.234.231]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q3UDUYgn008710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Apr 2012 09:30:38 -0400 Received: from GAALPA1MSGHUB9E.ITServices.sbc.com (gaalpa1msghub9e.itservices.sbc.com [130.8.36.91]) by sflint04.pst.cso.att.com (RSA Interceptor); Mon, 30 Apr 2012 09:30:20 -0400 Received: from GAALPA1MSGUSR9N.ITServices.sbc.com ([169.254.6.49]) by GAALPA1MSGHUB9E.ITServices.sbc.com ([130.8.36.91]) with mapi id 14.01.0355.002; Mon, 30 Apr 2012 09:30:19 -0400 From: "STARK, BARBARA H" To: Hans Liu , "Hemant Singh (shemant)" Thread-Topic: [v6ops] (S)NTP in 6204bis Thread-Index: Ac0myZUhauwjtOVfSFuWu+r+34uEagAA7AzgAAmr4IAAB6el4A== Date: Mon, 30 Apr 2012 13:30:19 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6110A7F88@GAALPA1MSGUSR9N.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6110A7F1D@GAALPA1MSGUSR9N.ITServices.sbc.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3048C36F0@XMB-RCD-109.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.86.158] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=1.0 c=1 a=KfbkHLZveIoA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHo] X-AnalysisOut: [wA:10 a=IkcTkHD0fZMA:10 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a=pG] X-AnalysisOut: [LkceISAAAA:8 a=48vgC7mUAAAA:8 a=AUd_NHdVAAAA:8 a=52XlT8Uxl] X-AnalysisOut: [eMVhiVDLkkA:9 a=-5ZCLnUh3eiPOHb0ekEA:7 a=QEXdDO2ut3YA:10 a] X-AnalysisOut: [=MSl-tDqOz04A:10 a=lZB815dzVvQA:10 a=JfD0Fch1gWkA:10 a=M0g] X-AnalysisOut: [XrGp8dS0EOK6w:21 a=6iKChEM_kfoCJb50:21] Cc: "v6ops@ietf.org" Subject: Re: [v6ops] (S)NTP in 6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 13:30:54 -0000 WWVzLCB0aGFua3MuIDU5MDguDQpCYXJiYXJhDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gRnJvbTogSGFucyBMaXUgW21haWx0bzpoYW5zbGl1QGdtYWlsLmNvbV0NCj4gU2VudDog TW9uZGF5LCBBcHJpbCAzMCwgMjAxMiA5OjA5IEFNDQo+IFRvOiBIZW1hbnQgU2luZ2ggKHNoZW1h bnQpDQo+IENjOiBTVEFSSywgQkFSQkFSQSBIOyB2Nm9wc0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBS ZTogW3Y2b3BzXSAoUylOVFAgaW4gNjIwNGJpcw0KPiANCj4gUkZDIDU5MDggIT8gIDopDQo+IA0K PiBCZXN0IHJlZ2FyZHMsDQo+IEhhbnMNCj4gDQo+IE9uIE1vbiwgQXByIDMwLCAyMDEyIGF0IDg6 MzMgUE0sIEhlbWFudCBTaW5naCAoc2hlbWFudCkNCj4gPHNoZW1hbnRAY2lzY28uY29tPiB3cm90 ZToNCj4gPiBCYXJiYXJhLA0KPiA+DQo+ID4gU2VjdGlvbiA3IG9mIFJGQyA1MDk4IGlzIHRoZSBB Y2tub3dsZWRnZW1lbnRzIHNlY3Rpb24uIMKgSXMgUkZDIDUwOTgNCj4gPiB0aGUgY29ycmVjdCBS RkM/DQo+ID4NCj4gPiBUaGFua3MsDQo+ID4NCj4gPiBIZW1hbnQNCj4gPg0KPiA+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogdjZvcHMtYm91bmNlc0BpZXRmLm9yZyBbbWFp bHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KPiA+IE9mIFNUQVJLLCBCQVJC QVJBIEgNCj4gPiBTZW50OiBNb25kYXksIEFwcmlsIDMwLCAyMDEyIDg6MDYgQU0NCj4gPiBUbzog djZvcHNAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBbdjZvcHNdIChTKU5UUCBpbiA2MjA0YmlzDQo+ ID4NCj4gPiBBIGNvbGxlYWd1ZSBvZiBtaW5lIHBvaW50ZWQgb3V0IHRvIG1lIHRoYXQgNjIwNCBh bmQgNjIwNGJpcyByZWZlcmVuY2UNCj4gPiBSRkMgNDA3NSBmb3IgdGhlIERIQ1B2NiBTTlRQIHNl cnZlciBvcHRpb24sIGFuZCB0aGF0IFJGQyA1MDk4IGNsYWltcw0KPiA+IGluIHRoZSBib2R5IG9m IGl0cyB0ZXh0IChzZWN0aW9uIDcpIHRvIGRlcHJlY2F0ZSA0MDc1LiBTaG91bGQgd2UgYmUNCj4g PiByZWNvbW1lbmRpbmcgdXNlIG9mIDQwNzUgb3IgNTA5OCBpbiA2MjA0KGJpcyk/DQo+ID4gQmFy YmFyYQ0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+ID4gdjZvcHMgbWFpbGluZyBsaXN0DQo+ID4gdjZvcHNAaWV0Zi5vcmcNCj4gPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo+ID4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiB2Nm9wcyBtYWlsaW5nIGxpc3QN Cj4gPiB2Nm9wc0BpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vdjZvcHMNCj4gDQo+IA0KPiANCj4gLS0NCj4gSW5zdGVhZCBvZiBmb2xsb3dpbmcgdGhl IGZhc2hpb24sIHdlIGxlYWQgaXQgdGhyb3VnaC4NCg== From sarikaya2012@gmail.com Mon Apr 30 09:03:29 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED46921F8647 for ; Mon, 30 Apr 2012 09:03:29 -0700 (PDT) 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 xghxLZt5v2Fh for ; Mon, 30 Apr 2012 09:03:29 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 98CA221F8642 for ; Mon, 30 Apr 2012 09:03:28 -0700 (PDT) Received: by yenm5 with SMTP id m5so1640113yen.31 for ; Mon, 30 Apr 2012 09:03:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=HmDc4b7BpcmhvNlRgcGjh+sRvCiA0LoF476Vi+4Ll1k=; b=rKgNcDc2Dp5zio1FCexxpYU7kgNHDIfOLfwbffuu9x+AbJPaYutxzLhf4ylyF5fDXR hELuoNBQnzicCvDP8sOBmVTd63Hhnfo3MsUE55WjE9+2hfVOd6JezPK+0Q3QQYUL240/ 8RhzAIp858nrFESha+Y0m49hQ92HxLPdT3Y1aZeeEOwp/VsMMcYNeMu2vgF1AgJxz05k /47l9TqLCwXeUAJcR0F8gsH5EDj2J1qimlvVNCBNpn8BFVJN9F9a28JtExKfDiAGwwVs sBPkty5Eu04YSWoVbIlaSDjt6JIqaOQA5YuUxjpZbXb77paboe0anTOWYI+Mw5PuXYkl 40Qg== MIME-Version: 1.0 Received: by 10.50.184.166 with SMTP id ev6mr10976217igc.63.1335801806875; Mon, 30 Apr 2012 09:03:26 -0700 (PDT) Received: by 10.231.194.73 with HTTP; Mon, 30 Apr 2012 09:03:26 -0700 (PDT) In-Reply-To: References: <20120417065542.31115.95082.idtracker@ietfa.amsl.com> <20120417160010kawashimam@mail.jp.nec.com> <56E2AD61-1C91-4889-914A-353793FCBE43@laposte.net> <20120419121044.17531mk1mv19abr4@mail.drown.org> <0646611B-5594-40EA-A2C4-F99CBA734024@laposte.net> <20120419181813.4524701l3gkq5zks@mail.drown.org> <45ABAD31-C265-4D63-82E2-3DE6F59B80C0@laposte.net> <20120420104246.1432746csfcrdqo8@mail.drown.org> <20120423105716.130762z7e8air84c@mail.drown.org> <20120424111859.199819d07k06j140@mail.drown.org> <5285C70C-89A8-4C99-AF24-5BB6AA055944@laposte.net> Date: Mon, 30 Apr 2012 11:03:26 -0500 Message-ID: From: Behcet Sarikaya To: Cameron Byrne Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-02.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: Mon, 30 Apr 2012 16:03:30 -0000 Hi Cameron, My questions: In Section 7.5, you have: In another cases where the access network does not allow for a dedicated translation prefix, the CLAT will do NAT44 such that all private IPv4 sourced LAN packets appears from one private IPv4 address which is statelessly translated to one IPv6 address. Can you please explain how this works on UEs? Is it A+P? I think it needs more clarification (in the draft). > supports over 85% of the common applications Is Skype supported? > Is there a CLAT for iPhone? Regards, Behcet From cb.list6@gmail.com Mon Apr 30 09:58:10 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A584C21F87CB for ; Mon, 30 Apr 2012 09:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.348 X-Spam-Level: X-Spam-Status: No, score=-3.348 tagged_above=-999 required=5 tests=[AWL=0.251, 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 MV2SICIGRmug for ; Mon, 30 Apr 2012 09:58:06 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 6690521F87CA for ; Mon, 30 Apr 2012 09:58:06 -0700 (PDT) Received: by dady13 with SMTP id y13so5765290dad.27 for ; Mon, 30 Apr 2012 09:58:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=wZEsbLi5NBjLDW+krlEMMD7Cn68LMG8yv52J+Xrea4A=; b=KHBRhAABV8EzslXuZL/gvDNqw/N7X+krweJ7OCTJcDopts7W/jUZR+uQjSw1xvbbkH qHY5k2SfdqZxggpT70AUJtWyVOMPiOt+Shb5yeu9+I085q4p6eyPzrhn8Yl8u3+evxKz 6BJ2Tv5r7bIcsJIz03GsuO/HnMoYxHnhbqr1Fb7eSif7bwdecuHgRQg5lfJHHtqGLKyo j9tGDsBXVeCatUK8TAa+nDsIZMMlhSjOeSMqD3F9KEpolU3OPdYz5r/60ZLEWTffuNdN Ua+sEjMSPNtTvuw1I91shc30VmLU9znfp5Uidgh58PrnZ6e1vmjNzWbD8Kz/dGbVnKEa r5xA== MIME-Version: 1.0 Received: by 10.68.196.167 with SMTP id in7mr20665721pbc.53.1335805086176; Mon, 30 Apr 2012 09:58:06 -0700 (PDT) Received: by 10.142.102.1 with HTTP; Mon, 30 Apr 2012 09:58:05 -0700 (PDT) In-Reply-To: References: <20120417065542.31115.95082.idtracker@ietfa.amsl.com> <20120417160010kawashimam@mail.jp.nec.com> <56E2AD61-1C91-4889-914A-353793FCBE43@laposte.net> <20120419121044.17531mk1mv19abr4@mail.drown.org> <0646611B-5594-40EA-A2C4-F99CBA734024@laposte.net> <20120419181813.4524701l3gkq5zks@mail.drown.org> <45ABAD31-C265-4D63-82E2-3DE6F59B80C0@laposte.net> <20120420104246.1432746csfcrdqo8@mail.drown.org> <20120423105716.130762z7e8air84c@mail.drown.org> <20120424111859.199819d07k06j140@mail.drown.org> <5285C70C-89A8-4C99-AF24-5BB6AA055944@laposte.net> Date: Mon, 30 Apr 2012 09:58:05 -0700 Message-ID: From: Cameron Byrne To: sarikaya@ieee.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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, 30 Apr 2012 16:58:10 -0000 Hi Behcet On Mon, Apr 30, 2012 at 9:03 AM, Behcet Sarikaya w= rote: > Hi Cameron, > My questions: > > In Section 7.5, you have: > In another cases where the access network does not allow for a > =A0 dedicated translation prefix, the CLAT will do NAT44 such that all > =A0 private IPv4 sourced LAN packets appears from one private IPv4 > =A0 address which is statelessly translated to one IPv6 address. > > Can you please explain how this works on UEs? > Is it A+P? > No, it is not A+P it is RFC6145 For example, incoming source IPv4 packets from the LAN 192.168.1.0/24 are NAT44 to the CLAT host address on the LAN of 192.168.1.1. This allows the CLAT to not have to do NDP for a /96, as discussed on the l= ist. Then, the CLAT will do RFC6145 so that the IPv4 packets from 192.168.1.1 are translate to the CLAT LAN IPv6 address as described in RFC 6052 The destination address of the IPv4 packet described above is also RFC6145 translated to the PREF64 of the PLAT such that it will look like PREF64+IPv4 address in accordance with RFC 6052 as well. All of the above, for most cases, is avoided if the application and service provider are capable of using DNS64... in which case, the only translation is RFC 6146 at the PLAT > I think it needs more clarification (in the draft). > >> supports over 85% of the common applications > > Is Skype supported? > No, Skype does not work with IPv6-only. Yes, Skype does work with 464XLAT. >> > > Is there a CLAT for iPhone? > No, CLAT is not yet an IETF standard, and even then, who knows what Apple will do. They do not pre-announce features. But, there are working implementations on open platforms such as the Android Nexus S. http://dan.drown.org/android/clat/ CB > > Regards, > > Behcet From jhw@apple.com Mon Apr 30 11:43:31 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E90A21F887B for ; Mon, 30 Apr 2012 11:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vFlgILQmZ5N8 for ; Mon, 30 Apr 2012 11:43:31 -0700 (PDT) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 22DDB21F8870 for ; Mon, 30 Apr 2012 11:43:30 -0700 (PDT) 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 Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPS id <0M3B002Z22NJZR51@mail-out.apple.com> for v6ops@ietf.org; Mon, 30 Apr 2012 11:43:08 -0700 (PDT) X-AuditID: 11807134-b7fe56d000004e7a-9a-4f9edd3c5231 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 F3.C2.20090.C3DDE9F4; Mon, 30 Apr 2012 11:43:08 -0700 (PDT) From: james woodyatt In-reply-to: <4F9BE4A8.2030904@gont.com.ar> Date: Mon, 30 Apr 2012 11:43:08 -0700 Message-id: References: <54469FB9-D118-4157-B9D6-8F52F7F96002@cisco.com> <4F99BAFC.7090505@gont.com.ar> <4F9BE4A8.2030904@gont.com.ar> To: Fernando Gont X-Mailer: Apple Mail (2.1457) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHLMWRmVeSWpSXmKPExsUieJDXQdfm7jx/g8/z+C1OLzjBaPFjw0F2 i9PH9jI7MHus3b6AxWPJkp9MHl8uf2YLYI7isklJzcksSy3St0vgyug/spal4AtjxdRdD9kb GPcwdjFyckgImEhMm3GTBcIWk7hwbz1bFyMXh5DAbCaJhpPfwBLMAjoSO7feYQOxeQX0JCbv XwFmCws4SdxcsYgdxGYTUJH4dvkuE4jNKaAt8fn0R9YuRg4OFgFVibW7IyDGJEs82vCKHcKW l9j+dg4zxEgbiYdzW5gh9t5hlNh45zDYHBEBDYl5CzezQhwnK7H6bSvrBEb+WUhOmoXkpFlI 5i5gZF7FKFiUmpNYaWiil1hQkJOql5yfu4kRFIoNhSY7GA/+5D/EKMDBqMTD+3LhPH8h1sSy 4srcQ4wSHMxKIrylE4FCvCmJlVWpRfnxRaU5qcWHGKU5WJTEeRPlZvsLCaQnlqRmp6YWpBbB ZJk4OKUaGLmm8+e9PL9sjoFMZU/bic5Srrntfgnhr2bc73w0iVvR+MrtWbWdLwre3z+5/JpE +a1rVXMZGRgdZJfnmOuwx0UIM20RXmg1R7FtpeC+0P6NTU/dKkubs9d8fTc17vBp6cmOlTaf VWZ6aV68HCOzeOGeSfmeTEKvgvp6ucz2xh8QiEjrYq1SUWIpzkg01GIuKk4EAPR8HIpBAgAA Cc: "v6ops@ietf.org WG" , draft-ietf-v6ops-ra-guard-implementation@tools.ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-ra-guard-implementation WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 18:43:31 -0000 On Apr 28, 2012, at 05:38 , Fernando Gont wrote: > > Please let me know if this addresses your concern. It does, thanks! -- james woodyatt member of technical staff, core os networking From sarikaya2012@gmail.com Mon Apr 30 12:32:30 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 926E221E802B for ; Mon, 30 Apr 2012 12:32:30 -0700 (PDT) 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 srIs0U-ld+b1 for ; Mon, 30 Apr 2012 12:32:29 -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 9822321E8025 for ; Mon, 30 Apr 2012 12:32:29 -0700 (PDT) Received: by yhq56 with SMTP id 56so898608yhq.31 for ; Mon, 30 Apr 2012 12:32:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=ptFGUur1Eykx8cUWFns6dTVpOhlcAjGp5MX4iqb1Oeo=; b=BpQiuWzVz+Tjpyx3P9/U6U+Nhrevd4tiICkNQzE4AlJwYdTTKHqZGWDfltARqe5h3a Q22Q3cqTK/6zP3VxhBJ8yEBEkbB3+VInqkkoW0YoXll/yD7BSBgRVUiLypmXcMqRb8Ev GelQ6l1faKqnjpwI2pyvLZGlqd1e6DDCc8c8Po5N3VnAkuONWkJg7eXJMgLHsyZv4dCm 05iSn48RT7a79Ogu+YCvgqRwxXu+5UFi+IXKgRQflMwZ92AoB1Uznqn32rhlT4ActKjO x+cmjCB2nPAfimjfgex3OukOPdCT5ApyLYWrFoWQl1G2Iiircnl1g3mrIaGLtJ9GBX+i HvIQ== MIME-Version: 1.0 Received: by 10.50.185.193 with SMTP id fe1mr11519119igc.9.1335814348856; Mon, 30 Apr 2012 12:32:28 -0700 (PDT) Received: by 10.231.194.73 with HTTP; Mon, 30 Apr 2012 12:32:28 -0700 (PDT) In-Reply-To: References: <20120417065542.31115.95082.idtracker@ietfa.amsl.com> <20120417160010kawashimam@mail.jp.nec.com> <56E2AD61-1C91-4889-914A-353793FCBE43@laposte.net> <20120419121044.17531mk1mv19abr4@mail.drown.org> <0646611B-5594-40EA-A2C4-F99CBA734024@laposte.net> <20120419181813.4524701l3gkq5zks@mail.drown.org> <45ABAD31-C265-4D63-82E2-3DE6F59B80C0@laposte.net> <20120420104246.1432746csfcrdqo8@mail.drown.org> <20120423105716.130762z7e8air84c@mail.drown.org> <20120424111859.199819d07k06j140@mail.drown.org> <5285C70C-89A8-4C99-AF24-5BB6AA055944@laposte.net> Date: Mon, 30 Apr 2012 14:32:28 -0500 Message-ID: From: Behcet Sarikaya To: Cameron Byrne Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-02.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: Mon, 30 Apr 2012 19:32:30 -0000 On Mon, Apr 30, 2012 at 11:58 AM, Cameron Byrne wrote: > Hi Behcet > > On Mon, Apr 30, 2012 at 9:03 AM, Behcet Sarikaya = wrote: >> Hi Cameron, >> My questions: >> >> In Section 7.5, you have: >> In another cases where the access network does not allow for a >> =A0 dedicated translation prefix, the CLAT will do NAT44 such that all >> =A0 private IPv4 sourced LAN packets appears from one private IPv4 >> =A0 address which is statelessly translated to one IPv6 address. >> >> Can you please explain how this works on UEs? >> Is it A+P? >> > > No, it is not A+P it is RFC6145 > > For example, incoming source IPv4 packets from the LAN 192.168.1.0/24 > are NAT44 to the CLAT host address on the LAN of 192.168.1.1. > > This allows the CLAT to not have to do NDP for a /96, as discussed on the= list. > > Then, the CLAT will do RFC6145 =A0so that the IPv4 packets from > 192.168.1.1 are translate to the CLAT LAN IPv6 address as described in > RFC 6052 I was asking UE operation. Are you saying that the source address from each and every UE after NAT44 is 192.168.1.1? > > The destination address of the IPv4 packet described above is also > RFC6145 translated to the PREF64 of the PLAT such that it will look > like PREF64+IPv4 address in accordance with RFC 6052 as well. > > All of the above, for most cases, is avoided if the application and > service provider are capable of using DNS64... in which case, the only > translation is RFC 6146 at the PLAT > >> I think it needs more clarification (in the draft). >> >>> supports over 85% of the common applications >> >> Is Skype supported? >> > > No, Skype does not work with IPv6-only. you mean with NAT64? >Yes, Skype does work with 464XLAT. Why? Which apps are in 15% then? Regards, Behcet From cb.list6@gmail.com Mon Apr 30 13:07:25 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B9AF21F875D for ; Mon, 30 Apr 2012 13:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.362 X-Spam-Level: X-Spam-Status: No, score=-3.362 tagged_above=-999 required=5 tests=[AWL=0.237, 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 ZYzCOOrcYojg for ; Mon, 30 Apr 2012 13:07:24 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 27A0B21F875C for ; Mon, 30 Apr 2012 13:07:24 -0700 (PDT) Received: by dady13 with SMTP id y13so6022522dad.27 for ; Mon, 30 Apr 2012 13:07:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=mjhbuKCtZ5JdJsoOTrvIWHSokrOiT7gjAHl03f9hgEY=; b=E07gDkR+mVaReaNfiloPvBnE6ukbjsHMKHe8jsaoRI0zmvPxy8KaEVwawcR2ZgzNZZ pKRFjdITTr8GXWQ2QfroQc1W7KdhkLXX+dVv01CuX2/FQUo2greW0sb/ljQg2q9eN3Rq +fhxbtdPvYQon3sMLtm7t3ILiUwIB/6xnY2Kwl4vYspSHYZExBaM3eLXqBtx/aDCZs2m ULoQ8uq1gBJCHDoTea1qFRskJs4j2jBBFnG13yk28X/E3gNk53zeLTk1DhH7rFXsBmHB zWWe/IV9EpucqPznyhQqGE2aM97jCw09JiWWfN/XEVAGO17ZV3UvUS78LwiR3SblcZqm x51A== MIME-Version: 1.0 Received: by 10.68.240.5 with SMTP id vw5mr2744301pbc.110.1335816443778; Mon, 30 Apr 2012 13:07:23 -0700 (PDT) Received: by 10.142.102.1 with HTTP; Mon, 30 Apr 2012 13:07:23 -0700 (PDT) In-Reply-To: References: <20120417065542.31115.95082.idtracker@ietfa.amsl.com> <20120417160010kawashimam@mail.jp.nec.com> <56E2AD61-1C91-4889-914A-353793FCBE43@laposte.net> <20120419121044.17531mk1mv19abr4@mail.drown.org> <0646611B-5594-40EA-A2C4-F99CBA734024@laposte.net> <20120419181813.4524701l3gkq5zks@mail.drown.org> <45ABAD31-C265-4D63-82E2-3DE6F59B80C0@laposte.net> <20120420104246.1432746csfcrdqo8@mail.drown.org> <20120423105716.130762z7e8air84c@mail.drown.org> <20120424111859.199819d07k06j140@mail.drown.org> <5285C70C-89A8-4C99-AF24-5BB6AA055944@laposte.net> Date: Mon, 30 Apr 2012 13:07:23 -0700 Message-ID: From: Cameron Byrne To: sarikaya@ieee.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops WG Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-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, 30 Apr 2012 20:07:25 -0000 Behcet, On Mon, Apr 30, 2012 at 12:32 PM, Behcet Sarikaya wrote: > On Mon, Apr 30, 2012 at 11:58 AM, Cameron Byrne wrot= e: >> Hi Behcet >> >> On Mon, Apr 30, 2012 at 9:03 AM, Behcet Sarikaya wrote: >>> Hi Cameron, >>> My questions: >>> >>> In Section 7.5, you have: >>> In another cases where the access network does not allow for a >>> =A0 dedicated translation prefix, the CLAT will do NAT44 such that all >>> =A0 private IPv4 sourced LAN packets appears from one private IPv4 >>> =A0 address which is statelessly translated to one IPv6 address. >>> >>> Can you please explain how this works on UEs? >>> Is it A+P? >>> >> >> No, it is not A+P it is RFC6145 >> >> For example, incoming source IPv4 packets from the LAN 192.168.1.0/24 >> are NAT44 to the CLAT host address on the LAN of 192.168.1.1. >> >> This allows the CLAT to not have to do NDP for a /96, as discussed on th= e list. >> >> Then, the CLAT will do RFC6145 =A0so that the IPv4 packets from >> 192.168.1.1 are translate to the CLAT LAN IPv6 address as described in >> RFC 6052 > > I was asking UE operation. Are you saying that the source address from > each and every UE after NAT44 is 192.168.1.1? > The exact IP is implementation specific. But, yes, something like that. In a 464XLAT deployment where NAT44 is used in the CLAT, the NAT44 to NAT46 is an internal function which never appears on the wire. >> >> The destination address of the IPv4 packet described above is also >> RFC6145 translated to the PREF64 of the PLAT such that it will look >> like PREF64+IPv4 address in accordance with RFC 6052 as well. >> >> All of the above, for most cases, is avoided if the application and >> service provider are capable of using DNS64... in which case, the only >> translation is RFC 6146 at the PLAT >> >>> I think it needs more clarification (in the draft). >>> >>>> supports over 85% of the common applications >>> >>> Is Skype supported? >>> >> >> No, Skype does not work with IPv6-only. > > you mean with NAT64? > Sorry for being unclear. Skype, today, does not work on a host that lacks IPv4 connectivity. This means Skype does not work on an IPv6-only hos. Generally, IPv6-only host use NAT64 / DNS64 services in the context of this discussion. >From that, you can conclude that Skype does not work with NAT64, which is not precisely correct, but usually correct since IPv6-only hosts do not work with Skype. The key is that Skype, and any application that uses or signals IPv4 literals, requires IPv4 functionality locally on the host. >>Yes, Skype does work with 464XLAT. > > Why? > Skype does work with 464XLAT since 464XLAT provides an IPv4 socket / address / route to which the Skype program can bind to and send native IPv4 packets to. > Which apps are in 15% then? > The 15% of Android apps broken on IPv6-only + NAT64/DNS64 claim is based on this data set goo.gl/z3j3q The red highlights applications that fail on IPv6-only network, the sample suggest that 15% of Android apps fail on an IPv6-only network The green highlights that all the items that failed now work with an IPv6-only attachment network when 464XLAT is used. So, using an IPv6-only access network with standard NAT64/DNS64 results in 15% of Android apps breaking When 464XLAT is used on Android with an IPv6-only access network (such as IPv6 PDP), 100% of applications work. I hope this is now clear. CB > Regards, > > Behcet From mark@townsley.net Mon Apr 30 14:29:02 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1B0921E80A1 for ; Mon, 30 Apr 2012 14:29:02 -0700 (PDT) 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=[AWL=0.023, 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 arBOBWves45V for ; Mon, 30 Apr 2012 14:29:01 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id E4F0E21E8099 for ; Mon, 30 Apr 2012 14:28:58 -0700 (PDT) Received: by wibhq7 with SMTP id hq7so2576296wib.13 for ; Mon, 30 Apr 2012 14:28:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=3WSGlSBrRDKiHzVx/cKUQ/RftuD2pa9V1PVTSvFd6CU=; b=XV5IzF6VJWWDH1AbAv9p5MXjDFglPvn/9NjK7TF7ZWSzowSk57Q058eNWRdDBoR+YN KjFeeY/G/R8PlQP7ql/RyVkLyLeRp4n4HbEDaFHdIusOkNC/LgKdB1TQFRRBcCGrCGp6 RbfpMCJfrHfpPQsyMX/KFEyfV7r6R78S4WqSV4MXNcDEugWWqn17K48aPdUX3xHg7M4j X8JW5d6oa8cjV/VSutDaiNLnghZR3oYoGBirUPV1gOSZsBcf+Ty0pGMa+GOdZ5buZJbK GE7pDw2SyAtq4yU3Hjsl2LDpSm82lEfK1yqjScNms8nVtYinZ/dXagpH9/VGxt1Byngn dD5g== Received: by 10.180.24.66 with SMTP id s2mr32389233wif.7.1335821338079; Mon, 30 Apr 2012 14:28:58 -0700 (PDT) Received: from ams-townsley-8912.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id b3sm31198960wib.4.2012.04.30.14.28.55 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 30 Apr 2012 14:28:57 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6110A7865@GAALPA1MSGUSR9N.ITServices.sbc.com> Date: Mon, 30 Apr 2012 23:28:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <985C167C-7CB6-481D-802E-2CD72683A0C0@townsley.net> References: <5B6B2B64C9FE2A489045EEEADDAFF2C30483722C@XMB-RCD-109.cisco.com> <4F95A3D9.1010100@viagenie.ca> <5B6B2B64C9FE2A489045EEEADDAFF2C304837261@XMB-RCD-109.cisco.com> <4F95ABA0.8090601@viagenie.ca> <5B6B2B64C9FE2A489045EEEADDAFF2C304837272@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30483747A@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3048378BB@XMB-RCD-109.cisco.com> <42D0E71D-8599-44C6-91D4-B059A276EB6A@cisco.com> <379ECFD4-C696-4B86-9DCA-75B0887C4370@townsley.net> <639FE0F2-ECD6-4C83-BB1F-9A9676ABCECB@townsley.net> <5B6B2B64C9FE2A489045EEEADDAFF2C30483801D@XMB-RCD-109.cisco.com> <50C59C32-B117-4EDB-AA8B-B4B207C82034@townsley.net> <5B6B2B64C9FE2A489045EEEADDAFF2C30483807B@XMB-RCD-109.cisco.com> <2D09D61DDFA73D4C884805CC7865E6110A7865@GAALPA1MSGUSR9N.ITServices.sbc.com > To: "STARK, BARBARA H" X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQlXz1+RUJJZxtULj1Q8Zj5ml5KxmzrI8PNlvidjvVjlvOe0Sw8aVKF2ZXo6IGbBedV/j1lL Cc: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements (version 2) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 21:29:02 -0000 On Apr 27, 2012, at 6:37 PM, STARK, BARBARA H wrote: >>>> 6RD-4: A CE router MUST allow 6rd virtual and IPv6 native WAN >>>> interfaces to be active simultaneously in order to support >>>> coexistence of the two technologies during an incremental migration >>>> period from 6rd to native IPv6 or vice versa. >>> I can't really see anyone who has a native IPv6 network migrate to >>> 6rd, but that might be a limit of my imagination :-) >>=20 >> didn't you know that corner cases allow us to complicate things, = which makes >> us more famous and gets more brownie points? >=20 > It's been suggested that a provider might find themselves needing to = back out of a migration from 6rd to native IPv6, if the native = deployment starts running into problems. In effect, this would look like = a migration from native IPv6 (back) to 6rd. The nifty thing is that by making the 6rd and native interfaces operate = independently as we do here, you could do this in reverse and it would = "just work". The CPE operates as a slave to whatever the ISP wants to = send configuration for, in whatever timeline and order it likes.=20 - Mark > Barbara > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From hansliu@gmail.com Mon Apr 30 15:27:49 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E037D21F8705 for ; Mon, 30 Apr 2012 15:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXhK5mZ2A5Q8 for ; Mon, 30 Apr 2012 15:27:49 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id F321E21F8704 for ; Mon, 30 Apr 2012 15:27:48 -0700 (PDT) Received: by lbbgm13 with SMTP id gm13so2430402lbb.31 for ; Mon, 30 Apr 2012 15:27:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=eOJE1qQln/NZ5s6ay8m3V9noY6d1uMZo5u+dUB0eSvk=; b=Ihci5owqV7R1t2vye/+KElLPMB77P3h97a4lrHQPH2AnNOOkUXFW6W8QBxeY2nbBlr eUDDGwNGjpKQE33rT3elcWDFM/zxSJ/6WkHF872BQDdIL7RwxCzci7JDIzUILlGDWJUr AgoLtCDCMpizQNVcTmXiCeqU5W5CTVja2NKIV8qUkfbjNIJf+XB2+F9mOkV7bgH0UMvt 17sH+VKRW7QWOWqwACyzyqwvqLDKBhquuSmVVMYHcnbvYBlRtrI44mDzjAIiGJTSJlEP dwhvVwMb2POiRvDdgWcZlAWos9kVc07rjKPu/hEH0EQe2pZfhe27yXULa4bjA6+EWwz3 VFwA== MIME-Version: 1.0 Received: by 10.112.84.202 with SMTP id b10mr10849823lbz.7.1335824867917; Mon, 30 Apr 2012 15:27:47 -0700 (PDT) Received: by 10.112.43.8 with HTTP; Mon, 30 Apr 2012 15:27:47 -0700 (PDT) In-Reply-To: <985C167C-7CB6-481D-802E-2CD72683A0C0@townsley.net> References: <5B6B2B64C9FE2A489045EEEADDAFF2C30483722C@XMB-RCD-109.cisco.com> <4F95A3D9.1010100@viagenie.ca> <5B6B2B64C9FE2A489045EEEADDAFF2C304837261@XMB-RCD-109.cisco.com> <4F95ABA0.8090601@viagenie.ca> <5B6B2B64C9FE2A489045EEEADDAFF2C304837272@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30483747A@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3048378BB@XMB-RCD-109.cisco.com> <42D0E71D-8599-44C6-91D4-B059A276EB6A@cisco.com> <379ECFD4-C696-4B86-9DCA-75B0887C4370@townsley.net> <639FE0F2-ECD6-4C83-BB1F-9A9676ABCECB@townsley.net> <5B6B2B64C9FE2A489045EEEADDAFF2C30483801D@XMB-RCD-109.cisco.com> <50C59C32-B117-4EDB-AA8B-B4B207C82034@townsley.net> <5B6B2B64C9FE2A489045EEEADDAFF2C30483807B@XMB-RCD-109.cisco.com> <2D09D61DDFA73D4C884805CC7865E6110A7865@GAALPA1MSGUSR9N.ITServices.sbc.com> <985C167C-7CB6-481D-802E-2CD72683A0C0@townsley.net> Date: Tue, 1 May 2012 06:27:47 +0800 Message-ID: From: Hans Liu To: Mark Townsley Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Claire Cheng , IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements (version 2) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 22:27:50 -0000 It looks like a lot of discussions were going on last week during my absenc= e. I'm good with the idea in general while I believe Mark and Chris are working on the text. If a operator chooses to provision both 6rd and native IPv6, a CE router needs to have the capability to support them simultaneously. In terms, CPE has the capability while operators have the privilege whether they would like to do that in their networks. And I will implement the requirements in boxes of my company. Cheers, Hans and I will have it implemented in products of my company. On Tue, May 1, 2012 at 5:28 AM, Mark Townsley wrote: > > On Apr 27, 2012, at 6:37 PM, STARK, BARBARA H wrote: > >>>>> 6RD-4: A CE router MUST allow 6rd virtual and IPv6 native WAN >>>>> interfaces to be active simultaneously in order to support >>>>> coexistence of the two technologies during an incremental migration >>>>> period from 6rd to native IPv6 or vice versa. >>>> I can't really see anyone who has a native IPv6 network migrate to >>>> 6rd, but that might be a limit of my imagination :-) >>> >>> didn't you know that corner cases allow us to complicate things, which = makes >>> us more famous and gets more brownie points? >> >> It's been suggested that a provider might find themselves needing to bac= k out of a migration from 6rd to native IPv6, if the native deployment star= ts running into problems. In effect, this would look like a migration from = native IPv6 (back) to 6rd. > > The nifty thing is that by making the 6rd and native interfaces operate i= ndependently as we do here, you could do this in reverse and it would "just= work". The CPE operates as a slave to whatever the ISP wants to send confi= guration for, in whatever timeline and order it likes. > > - Mark > >> Barbara >> _______________________________________________ >> 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 Instead of following the fashion, we lead it through.
    On Apr 24, 2012, at = 3:31 PM, Hemant Singh (shemant) wrote:

    V6ops Chairs,
     
    I=92d like to = defer to you on this one.  =

    I think = the chairs would expect that.

    For this case, = the chairs already made their call. The reason we are here is that you = and Chris didn't follow what was asked by = them.

    What was asked was to Include the three = basic requirements based on my presentation. I sent those to Chris one = week after the IETF. He decided to throw them in the trash, instead = giving you a different set to = publish. 

    The best way to end this, is to = just take the advice from the people who have actually built and = deployed 6rd for some time, and have planned out the CPE requirements = for how to transition to native and include that text. Before you didn't = have that text, because Chris threw it away. Now you = do. 

    - Mark

    We have been down this road during the past two months where = the draft-townsley-troan-ipv6-ce-transitioning-02 is trying to add = requirements to rfc6204bis but the = draft-townsley-troan-ipv6-ce-transitioning-02 is clearly not completed = work.    The = draft-townsley-troan-ipv6-ce-transitioning-02 seems to be boiling the = ocean and is not going to be an RFC even in one year.   So = could we stop the 6rd thrashing and just ship rfc6204bis with basic 6rd = requirements?  Further, we are also going in circles.  6rd = folks gave Chris some text to add to rfc6304bis at Paris but when Chris = adds the text to rfc6204bis we are thrashing with that text = too.    I don=92t think any advanced 6rd requirement has = gestated for text in the past two months. =    
     
    My humble recommendation is to ship rfc6204bis right = now.  I am happy to back out the Paris text added for 6rd in the = -08 version.
     
    Hemant
     
    From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.or= g] On Behalf = Of Hemant Singh = (shemant)
    Sent: Monday, April 23, 2012 3:31 = PM
    To: Simon = Perreault
    Cc: v6ops@ietf.org
    Subject: Re: [v6ops] FW: 6rd = sunsetting requirements for = 6204-bis
     
     
    -----Original Message-----
    From: Simon Perreault = [mailto:simon.perreault@viagenie.ca] 
    Sent: Monday, April 23, = 2012 3:21 PM
    To: Hemant Singh (shemant)
    Cc: v6ops@ietf.org
    Subject: Re: FW: [v6ops] 6rd = sunsetting requirements for 6204-bis
    >But Mark's argument is, if I understand correctly, that not = supporting
    >native alongside 6rd *harms the Internet* because it = prevents graceful
    >transitioning from 6rd to native. That argument is specific = to 6rd, not
    >generic to all tunnel = interfaces.
     
    Fine for an = argument.  But again, the CPE router is consumer device that needs = a specification for automata related to concurrent operation of native = IPv6 and 6rd including specifying the transition from native IPv6 6rd or = vice versa.  Such a specification does not exist in RFC form. =  Rfc6204bis only accepts technology in RFC form or in rare = exceptions, technology where the draft is in the IESG. =  
     
    ; Tue, 24 Apr 2012 21:33:56 GMT Received: from [127.0.0.1] by ciscodev188.cisco.com (PGP Universal service); Tue, 24 Apr 2012 23:33:56 +0200 X-PGP-Universal: processed; by ciscodev188.cisco.com on Tue, 24 Apr 2012 23:33:56 +0200 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Tue, 24 Apr 2012 23:33:10 +0200 Message-Id: References: <5B6B2B64C9FE2A489045EEEADDAFF2C30483722C@XMB-RCD-109.cisco.com><4F95A3D9.1010100@viagenie.ca><5B6B2B64C9FE2A489045EEEADDAFF2C304837261@XMB-RCD-109.cisco.com><4F95ABA0.8090601@viagenie.ca> <5B6B2B64C9FE2A489045EEEADDAFF2C304837272@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30483747A@XMB-RCD-109.cisco.com> To: IPv6 Operations X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 21:33:59 -0000 We discussed this at IETF 83, and you will find it in the minutes when = they come out. Mark and Ole asked for two things (statements regarding = 6rd and ds-lite), and the working group agreed to one of them. We are = not discussing a "boiling of the ocean", nor are we discussing an = infinite succession of new requirements. We are discussing getting three = no-brainer-class statements into the draft in a manner that the = discussants all recognize and agree to. The three statements were = clarified by hum in the meeting, and were each able to be stated in a = single sentence. I would ask the different actors in this discussion to please behave in = a courteous manner toward each other, and work together on this as = requested by the chairs at IETF 83.= From shemant@cisco.com Tue Apr 24 20:06:21 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED7D521E8012 for ; Tue, 24 Apr 2012 20:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.538 X-Spam-Level: X-Spam-Status: No, score=-10.538 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cxevrqISrmsz for ; Tue, 24 Apr 2012 20:06:17 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 1A12A11E8074 for ; Tue, 24 Apr 2012 20:06:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=14844; q=dns/txt; s=iport; t=1335323165; x=1336532765; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=tyQgIrHWxNQBu08NNBJ985et56iZWeF1cfSB8+zoMO8=; b=hREUf7FuSyM3BrkJvItSBco9wN+2GjP/MN6HgmSLzRzx9g4307LWbca9 Onxol3DieM12Ew31ZY+XV9veloo8H3zGUhU3ML132bayo4D3f33qyx0Gl vN5j5f/GU8BkjNlEF7Jh0Z+nRLj79TMOc2+nEjUOT/djtAo/vb/RnrTCn 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAIJpl0+tJV2Y/2dsb2JhbABEgkavJoEHggkBAQEEAQEBDwEJEQM+FwQCAQgRBAEBCwYXAQYBJh8JCAEBBAESCAEZh20Lmj2gJIlrgRKFF2MEiGObbIFpgweBPg X-IronPort-AV: E=Sophos;i="4.75,477,1330905600"; d="scan'208,217";a="77578507" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 25 Apr 2012 03:05:44 +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 q3P35iQL026542 for ; Wed, 25 Apr 2012 03:05:44 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, 24 Apr 2012 22:05:44 -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_01CD2290.4DDD648E" Date: Tue, 24 Apr 2012 22:05:42 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3048378BB@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] 6rd sunsetting requirements for 6204-bis Thread-Index: Ac0iYhwXyrgS1dI9QLq3wOGDK5tbdgAA9cmA References: <5B6B2B64C9FE2A489045EEEADDAFF2C30483722C@XMB-RCD-109.cisco.com><4F95A3D9.1010100@viagenie.ca><5B6B2B64C9FE2A489045EEEADDAFF2C304837261@XMB-RCD-109.cisco.com><4F95ABA0.8090601@viagenie.ca><5B6B2B64C9FE2A489045EEEADDAFF2C304837272@XMB-RCD-109.cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C30483747A@XMB-RCD-109.cisco.com> From: "Hemant Singh (shemant)" To: "Fred Baker (fred)" , "IPv6 Operations" X-OriginalArrivalTime: 25 Apr 2012 03:05:44.0060 (UTC) FILETIME=[4DDD5BC0:01CD2290] Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 03:06:21 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD2290.4DDD648E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Fred, =20 Appreciate the quick reply. In MarkT's comments to Chris that Chris did not follow the Chairs' recommendation, the statement is not quite correct. Additionally MarkT saying to the mailer that "He (Chris) decided to throw them in the trash" is not correct either. See the URL below where Chris clearly said, he has guidance from the IETF and WG in the past to not include more than one normative statement per requirement. Thus Chris broke up the MarkT recommendations and the break up has to stay. Thus it would help if Mark revisits Chris' text and fills in holes Mark thinks the text has because we just cannot go back to Mark's original text that combines multiple normative statements in one requirement. =20 http://www.ietf.org/mail-archive/web/v6ops/current/msg12705.html Moving on, the requirements provided by MarkT could use tighter text. For example here is a portion of text provided to us to add. =20 "6RD-5: The CE router MUST associate delegated prefixes with the WAN interface(s)" =20 The CPE WAN interface can be unnumbered with only an IPv6 link-local address and thus the CPE WAN does not have a global IPv6 address. In such an unnumbered model, the CPE uses an address from the PD on a virtual network interface to source packets out the WAN such as ICMPv6 errors. I am away from work tomorrow but we can certainly try and close any text two days from now including any WebEx phone call between Mark and us authors of rfc6204bis. =20 =20 Another example for tighter text is related to 6RD-4. Why does 6RD-4 only say "during an incremental migration period from 6rd to native IPv6." The SP could encounter a problem moving from 6rd to native IPv6 and may want to revert back to 6rd. Thus the 6RD-4 bullet should cater to any migration from 6rd to native IPv6 or vice versa. =20 Further, when the CPE has different prefixes being used by native IPV6 and 6rd, a host behind the CPE router has concurrent IPv6 addresses being used (one IPv6 address from native IPv6 and another from the 6rd prefix). So what source-address does the host pick to send a packet to a destination that is totally disjoint with the two prefixes assigned to the CPE router? Let's say the host picked a source address from the 6rd prefix, then the CPE router ships the packet out the 6rd tunnel instead of the higher preferred native IPv6 network. So how is the native IPv6 preference enforced by the CPE router? =20 =20 We also do not have consensus with the "MUST" in 6RD-4. Current consensus is mostly towards changing the MUST to a SHOULD. I also do not see any SP clamoring for 6rd sunsetting. One SP in France or France that has roughly million 6rd customers does not impress me. I am a person who gets impressed with 200 million customers which is roughly what the cable broadband industry is deploying native IPv6 for. =20 =20 Hemant =20 =20 -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Fred Baker (fred) Sent: Tuesday, April 24, 2012 5:33 PM To: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis =20 We discussed this at IETF 83, and you will find it in the minutes when they come out. Mark and Ole asked for two things (statements regarding 6rd and ds-lite), and the working group agreed to one of them. We are not discussing a "boiling of the ocean", nor are we discussing an infinite succession of new requirements. We are discussing getting three no-brainer-class statements into the draft in a manner that the discussants all recognize and agree to. The three statements were clarified by hum in the meeting, and were each able to be stated in a single sentence. =20 I would ask the different actors in this discussion to please behave in a courteous manner toward each other, and work together on this as requested by the chairs at IETF 83. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ------_=_NextPart_001_01CD2290.4DDD648E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Fred,

     

    Appreciate the quick reply.  In = MarkT's comments to Chris that Chris did not follow the Chairs' = recommendation, the statement is not quite correct.  Additionally = MarkT saying to the mailer that  "He (Chris) decided to throw = them in the trash" is not correct either.  See the URL below = where Chris clearly said, he has guidance from the IETF and WG in the = past to not include more than one normative statement per = requirement.  Thus Chris broke up the MarkT recommendations and the = break up has to stay.  Thus it would help if Mark revisits = Chris’ text and fills in holes Mark thinks the text has because we = just cannot go back to Mark’s original text that combines multiple = normative statements in one requirement.

     

    http://www.ietf.org/mail-archive/web/v6ops/current/msg12705.html

    Moving = on, the requirements provided by MarkT could use tighter text. =  For example here is a portion of text provided to us to = add.

     

    "6RD-5: The CE router MUST associate delegated prefixes with = the WAN

    interface(s)”

     

    The CPE WAN interface can be = unnumbered with only an IPv6 link-local address and thus the CPE WAN = does not have a global IPv6 address.  In such an unnumbered model, = the CPE uses an address from the PD on a virtual network interface to = source packets out the WAN such as ICMPv6 errors.  I am away from = work tomorrow but we can certainly try and close any text two days from = now including any WebEx phone call between Mark and us authors of = rfc6204bis. 

     

    Another = example for tighter text is related to 6RD-4.  Why does = 6RD-4 only say “during an incremental migration period from 6rd to native = IPv6.”    The SP could encounter a problem = moving from 6rd to native IPv6 and may want to revert back to 6rd.  = Thus the 6RD-4 bullet should cater to any migration from 6rd to native = IPv6 or vice versa.

     

    Further, = when the CPE has different prefixes being used by native IPV6 and 6rd, a = host behind the CPE router has concurrent IPv6 addresses being used (one = IPv6 address from native IPv6 and another from the 6rd prefix).  So = what source-address does the host pick to send a packet to a destination = that is totally disjoint with the two prefixes assigned to the CPE = router?  Let’s say the host picked a source address from the = 6rd prefix, then the CPE router ships the packet out the 6rd tunnel = instead of the higher preferred native IPv6 network.  So how is the = native IPv6 preference enforced by the CPE router?   =

     

    We also = do not have consensus with the “MUST” in 6RD-4.  = Current consensus is mostly towards changing the MUST to a SHOULD.  = I also do not see any SP clamoring for 6rd sunsetting.  One = SP in France or France that has roughly million 6rd customers does not = impress me.  I am a person who gets impressed with 200 million = customers which is roughly what the cable broadband industry is = deploying native IPv6 for.  

     

    Hemant

     

     

    -----Original Message-----

    From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@iet= f.org] On Behalf Of Fred Baker (fred)

    Sent: = Tuesday, April 24, 2012 5:33 PM

    To: IPv6 = Operations

    Subject: Re: [v6ops] 6rd sunsetting = requirements for 6204-bis

     

    We discussed this at IETF 83, and = you will find it in the minutes when they come out. Mark and Ole asked = for two things (statements regarding 6rd and ds-lite), and the working = group agreed to one of them. We are not discussing a "boiling of = the ocean", nor are we discussing an infinite succession of new = requirements. We are discussing getting three no-brainer-class = statements into the draft in a manner that the discussants all recognize = and agree to. The three statements were clarified by hum in the meeting, = and were each able to be stated in a single = sentence.

     

    I would = ask the different actors in this discussion to please behave in a = courteous manner toward each other, and work together on this as = requested by the chairs at IETF 83.

    _______________________________________________

    v6ops mailing list

    v6ops@ietf.org

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

    ------_=_NextPart_001_01CD2290.4DDD648E-- From fred@cisco.com Tue Apr 24 20:23:46 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B05921E802B for ; Tue, 24 Apr 2012 20:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.605 X-Spam-Level: X-Spam-Status: No, score=-109.605 tagged_above=-999 required=5 tests=[AWL=-0.491, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, 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 2Hxv6babMXnO for ; Tue, 24 Apr 2012 20:23:44 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD5D21E8012 for ; Tue, 24 Apr 2012 20:23:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=25416; q=dns/txt; s=iport; t=1335324223; x=1336533823; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=Bkq3n1pELpc+4+iFl32l9VplRVHtkaf8IXvSGEHMnGI=; b=JxbYVx3RGAdkKQNBn0gGq5tr60g6gtrBtWlwWsv5rhMvhc979+IuDpgY V+EW1zwOdcRq9R23KMcMnjVjEzNHWo2aY+ZqCuZbvZ758IpIbfLokpTNa CSkmcZeetUmHGdfGpEUpvhEydKJPO5habjoUwtB2ef1iTsCrYjreeBUb1 M=; X-IronPort-AV: E=Sophos;i="4.75,477,1330905600"; d="scan'208,217";a="136136737" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 25 Apr 2012 03:23:42 +0000 Received: from ciscodev188.cisco.com (dhcp-10-55-81-155.cisco.com [10.55.81.155]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3P3Nf2Q016291; Wed, 25 Apr 2012 03:23:42 GMT Received: from [127.0.0.1] by ciscodev188.cisco.com (PGP Universal service); Wed, 25 Apr 2012 05:23:42 +0200 X-PGP-Universal: processed; by ciscodev188.cisco.com on Wed, 25 Apr 2012 05:23:42 +0200 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3048378BB@XMB-RCD-109.cisco.com> Date: Wed, 25 Apr 2012 05:23:07 +0200 Message-Id: <42D0E71D-8599-44C6-91D4-B059A276EB6A@cisco.com> References: <5B6B2B64C9FE2A489045EEEADDAFF2C30483722C@XMB-RCD-109.cisco.com><4F95A3D9.1010100@viagenie.ca><5B6B2B64C9FE2A489045EEEADDAFF2C304837261@XMB-RCD-109.cisco.com><4F95ABA0.8090601@viagenie.ca><5B6B2B64C9FE2A489045EEEADDAFF2C304837272@XMB-RCD-109.cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C30483747A@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3048378BB@XMB-RCD-109.cisco.com> To: "Hemant Singh (shemant)" X-Mailer: Apple Mail (2.1084) Content-Type: multipart/alternative; boundary=Apple-Mail-60-534701677 Cc: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 03:23:46 -0000 --Apple-Mail-60-534701677 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Apr 25, 2012, at 5:05 AM, Hemant Singh (shemant) wrote: > Fred, > =20 > Appreciate the quick reply. In MarkT's comments to Chris that Chris = did not follow the Chairs' recommendation, the statement is not quite = correct. Additionally MarkT saying to the mailer that "He (Chris) = decided to throw them in the trash" is not correct either. See the URL = below where Chris clearly said, he has guidance from the IETF and WG in = the past to not include more than one normative statement per = requirement. Thus Chris broke up the MarkT recommendations and the = break up has to stay. Thus it would help if Mark revisits Chris=92 text = and fills in holes Mark thinks the text has because we just cannot go = back to Mark=92s original text that combines multiple normative = statements in one requirement. I would like you to please work with Mark, on the mailer, to accomplish = that.=20 > http://www.ietf.org/mail-archive/web/v6ops/current/msg12705.html > Moving on, the requirements provided by MarkT could use tighter text. = For example here is a portion of text provided to us to add. > =20 > "6RD-5: The CE router MUST associate delegated prefixes with the WAN > interface(s)=94 > =20 > The CPE WAN interface can be unnumbered with only an IPv6 link-local = address and thus the CPE WAN does not have a global IPv6 address. In = such an unnumbered model, the CPE uses an address from the PD on a = virtual network interface to source packets out the WAN such as ICMPv6 = errors. I am away from work tomorrow but we can certainly try and close = any text two days from now including any WebEx phone call between Mark = and us authors of rfc6204bis.=20 I suspect that you misunderstand Mark's text, which says that the text = he suggested was inadequate.=20 RFC 3704, resolving a number of pages into a single sentence, recommends = that if a packet uses a stated source address and that source address = was derived from a stated upstream network, the packet should be = directed to said upstream network. The reason it would do so is that the = upstream networks presumably implement BCP 38, meaning that if it is = directed to a different upstream network it is likely to be dropped. = 3704 goes on to make suggestions regarding the implementation of exit = routing. What Mark is driving at is "implement exit routing; if one is = given multiple prefixes on different interfaces, physical or virtual, = associate each such prefix with its source interface in routing for the = purposes of source-address directed exit routing." Explanations and dialog such as this are the reason I am asking you to = TALK WITH MARK about issues you see rather than talking with the chairs = or simply presuming that the working group outcome in Paris is = brain-dead. The outcome was, as near as I could tell, very sensible to = the operators. > Another example for tighter text is related to 6RD-4. Why does 6RD-4 = only say =93during an incremental migration period from 6rd to native = IPv6.=94 The SP could encounter a problem moving from 6rd to native = IPv6 and may want to revert back to 6rd. Thus the 6RD-4 bullet should = cater to any migration from 6rd to native IPv6 or vice versa. > =20 > Further, when the CPE has different prefixes being used by native IPV6 = and 6rd, a host behind the CPE router has concurrent IPv6 addresses = being used (one IPv6 address from native IPv6 and another from the 6rd = prefix). So what source-address does the host pick to send a packet to = a destination that is totally disjoint with the two prefixes assigned to = the CPE router? Let=92s say the host picked a source address from the = 6rd prefix, then the CPE router ships the packet out the 6rd tunnel = instead of the higher preferred native IPv6 network. So how is the = native IPv6 preference enforced by the CPE router? =20 > =20 > We also do not have consensus with the =93MUST=94 in 6RD-4. Current = consensus is mostly towards changing the MUST to a SHOULD. I also do = not see any SP clamoring for 6rd sunsetting. One SP in France or France = that has roughly million 6rd customers does not impress me. I am a = person who gets impressed with 200 million customers which is roughly = what the cable broadband industry is deploying native IPv6 for. =20 > =20 > Hemant > =20 > =20 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Fred Baker (fred) > Sent: Tuesday, April 24, 2012 5:33 PM > To: IPv6 Operations > Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis > =20 > We discussed this at IETF 83, and you will find it in the minutes when = they come out. Mark and Ole asked for two things (statements regarding = 6rd and ds-lite), and the working group agreed to one of them. We are = not discussing a "boiling of the ocean", nor are we discussing an = infinite succession of new requirements. We are discussing getting three = no-brainer-class statements into the draft in a manner that the = discussants all recognize and agree to. The three statements were = clarified by hum in the meeting, and were each able to be stated in a = single sentence. > =20 > I would ask the different actors in this discussion to please behave = in a courteous manner toward each other, and work together on this as = requested by the chairs at IETF 83. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail-60-534701677 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
    On Apr 25, 2012, at 5:05 AM, Hemant = Singh (shemant) wrote:

    Fred,
     
    Appreciate the quick reply.  In MarkT's comments to Chris = that Chris did not follow the Chairs' recommendation, the statement is = not quite correct.  Additionally MarkT saying to the mailer = that  "He (Chris) decided to throw them in the trash" is not = correct either.  See the URL below where Chris clearly said, he has = guidance from the IETF and WG in the past to not include more than one = normative statement per requirement.  Thus Chris broke up the MarkT = recommendations and the break up has to stay.  Thus it would help if = Mark revisits Chris=92 text and fills in holes Mark thinks the text has = because we just cannot go back to Mark=92s original text that combines = multiple normative statements in one = requirement.

    I would like you to = please work with Mark, on the mailer, to accomplish = that. 

    <= div>

    I suspect that you = misunderstand Mark's text, which says that the text he suggested was = inadequate. 

    RFC 3704, resolving a = number of pages into a single sentence, recommends that if a packet uses = a stated source address and that source address was derived from a = stated upstream network, the packet should be directed to said upstream = network. The reason it would do so is that the upstream networks = presumably implement BCP 38, meaning that if it is directed to a = different upstream network it is likely to be dropped. 3704 goes on to = make suggestions regarding the implementation of exit routing. What Mark = is driving at is "implement exit routing; if one is given multiple = prefixes on different interfaces, physical or virtual, associate each = such prefix with its source interface in routing for the purposes of = source-address directed exit routing."

    Explanations and = dialog such as this are the reason I am asking you to TALK WITH MARK = about issues you see rather than talking with the chairs or simply = presuming that the working group outcome in Paris is brain-dead. The = outcome was, as near as I could tell, very sensible to the = operators.

    Another example for tighter text is related to 6RD-4.  = Why does 6RD-4 only say =93during an incremental migration period from 6rd to native = IPv6.=94    The SP could encounter a problem moving from 6rd to native IPv6 = and may want to revert back to 6rd.  Thus the 6RD-4 bullet should = cater to any migration from 6rd to native IPv6 or vice = versa.
     
    Further, when the CPE has different prefixes being used by = native IPV6 and 6rd, a host behind the CPE router has concurrent IPv6 = addresses being used (one IPv6 address from native IPv6 and another from = the 6rd prefix).  So what source-address does the host pick to send = a packet to a destination that is totally disjoint with the two prefixes = assigned to the CPE router?  Let=92s say the host picked a source = address from the 6rd prefix, then the CPE router ships the packet out = the 6rd tunnel instead of the higher preferred native IPv6 = network.  So how is the native IPv6 preference enforced by the CPE = router?  
     
    We also do not have consensus with the =93MUST=94 in = 6RD-4.  Current consensus is mostly towards changing the MUST to a = SHOULD.  I = also do not see any SP clamoring for 6rd sunsetting.  One SP in = France or France that has roughly million 6rd customers does not impress = me.  I am a person who gets impressed with 200 million customers = which is roughly what the cable broadband industry is deploying native = IPv6 for.  
     
    Hemant
     
     
    -----Original Message-----
    Sent: Tuesday, April 24, 2012 5:33 = PM
    Subject: Re: [v6ops] 6rd sunsetting requirements for = 6204-bis
     
    We discussed this at IETF 83, and you will find it in the = minutes when they come out. Mark and Ole asked for two things = (statements regarding 6rd and ds-lite), and the working group agreed to = one of them. We are not discussing a "boiling of the ocean", nor are we = discussing an infinite succession of new requirements. We are discussing = getting three no-brainer-class statements into the draft in a manner = that the discussants all recognize and agree to. The three statements = were clarified by hum in the meeting, and were each able to be stated in = a single sentence.
     
    I would ask the different actors in this discussion to please = behave in a courteous manner toward each other, and work together on = this as requested by the chairs at IETF 83.
    v6ops mailing = list
    Subject: Re: [v6ops] Fwd: 6rd sunsetting requirements for 6204-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 06:48:16 -0000 Hi Alexandre, Every opinion counts, no doubt about that one. Much appreciate your input. I know that Free is one of the frontrunners on 6rd usage, which already dif= ferentiates you from a lot of others (I think). Apart from that, I also do= support the draft, which does not mean that it should be included in today= 's CPEs 6204 reqs, but it probably should in (one of) the next "release(s)/= version(s)". 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: Alexandre Cassen [mailto:acassen@corp.free.fr]=20 Sent: dinsdag 24 april 2012 21:10 To: Wuyts Carl Cc: Mark Townsley; Chris Donley; v6ops@ietf.org Subject: Re: Fwd: [v6ops] 6rd sunsetting requirements for 6204-bis Hi, I can give you our perspective if usefull. While we are not planning to turn off 6rd tomorow, we have been looking at = how to do so. That is the reason why we are supporting this work. regs, Alexandre > From: Wuyts Carl > Subject: RE: [v6ops] 6rd sunsetting requirements for 6204-bis > Date: April 24, 2012 11:23:39 AM GMT+02:00 > To: Mark Townsley > Cc: Chris Donley , "v6ops@ietf.org"=20 > >=20 > @ Mark. > =A0 > 1.=A0=A0=A0=A0=A0=A0=A0=A0Indeed we are deploying managed CPEs, so have a= bit more=20 > flexibility in controlling the config vs retail.=A0 Indeed, not all CPEs = are TR-069 capable, but most of our customers do deploy it (quite typical f= or managed CPE). > 2.=A0=A0=A0=A0=A0=A0=A06rd and DSlite or indeed far from equal, I know.= =A0 What I=20 > meant is that the same principal applies, i.e. one is not rolling it=20 > out today, to decide tomorrow to go fully native all of a sudden.=A0 Inve= stments are being made, either 6rd or DSLite, or even both, which will not = be thrown away the day after.=A0 =A0So the 6rd sunsetting indeed is somethi= ng to become useful in later stages, but no urgency to include them as reqs= today. > =A0=A0 > 3.=A0=A0=A0=A0=A0=A0=A06rd indeed exists for some time, you probably know= a lot=20 > better than me=A0J, but I?ve a pretty good view on what our customers are= doing today with IPv6 in general 9so also with 6rd), and can assure you th= ey are not looking at any 6rd sunsetting today. > =A0 > So, as Roberta also says in her latest reply.=A0 Please draw a line.=A0=20 > You say before DSLite, maybe, maybe not, I?d say, looking at millions=20 > of CPEs in the field, the 6rd sunsetting for sure are not needed=20 > today.=A0 Wrt DSLite. =A0I don?t think we can avoid it (unfortunately),=20 > but also here applies that the CPE should be able to handle those tunnels= , but not yet to also include full PCP support or some other UPnP-kind of m= echanism, it?s too early for that (looking at them being mainly all draft s= tuff).=A0 Of course CPE vendors should look into it today and judge upon it= s impact, but one cannot expect from the CPE vendor (you know, the very low= cost device) to support all of it in 1 go. > =A0 > I can even go 1 step further: RFC6106 support.=A0 For the record: we do=20 > support it, however, I see lack of support in the LAN for it, hence=20 > not very usable today.=A0 OK for CPE to have some basic support for it, b= ut not ?all the way? for simple reason that lots of hosts are not ready + t= he fact that no clear view on what should happen in case of both RA and DHC= Pv6 stateless, what is ?best?, what if different content, ?.=A0 This one ho= wever is only limited present in RFC6204, which is fine I guess. > =A0 > Best regards > Carl > =A0 > From:=A0Mark Townsley [mailto:mark@townsley.net] > Sent:=A0dinsdag 24 april 2012 9:34 > To:=A0Wuyts Carl > Cc:=A0Chris Donley;=A0v6ops@ietf.org > Subject:=A0Re: [v6ops] 6rd sunsetting requirements for 6204-bis > =A0 > =A0 > On Apr 24, 2012, at 8:45 AM, Wuyts Carl wrote: >=20 >=20 > =A0 > [Carl] Yes.=A0 A CPE is a router, hence should be capable of making=20 > routing decisions, taking into account multiple paths, metrics, ?..=A0=20 > Load balancing for instance might not be supported, so in case of multipl= e equal cost paths, it will take one of the available routes, but this is a= known ?issue? at that moment.=A0 Lots of things can be set via TR-069 thes= e days, so ISP can influence e.g. metrics when having native/tunneled combi= nation and wanting to enforce a specific route. > =A0 > We cannot assume all CPE have a TR-69 interface. >=20 >=20 > [Carl] Not at all.=A0 Our CPE supports both 6rd, static as well as using= =20 > the DHCP option 212.=A0 But when looking today at our customers, there fo= r sure not hitting a 6rd move to native . > =A0 > Not sure I understand that sentence. > =A0 > But, let's just say I am looking at the largest =A06rd deployments in=20 > the world, and working out how to migrate them to native.=A0That's the ba= sis behind the three requirements, and the reason they are being introduced= in 6204-bis is that this is the first document that considers both native = IPv6 and 6rd at the same time. > =A0 > I gather your primary customer set is a managed CPE with TR-69. WIth=20 > this model, you can of course leave all this up to configuration, and=20 > customize everything for each and every ISP in the world. Retail CPE are = different, and the burden on the RFC greater, in order to achieve the level= of consistency across the market that is needed for the model to work at a= ll. >=20 >=20 > =A0 > All I am trying to do is make sure that *if* 6rd is in the document,=20 > it is done correctly so we don't paint ourselves into a corner. [Carl] Sa= w the picture, see what you mean, but again, should be tackled, however not= today.=A0 Allow some time. > =A0 > 6rd has been deployed since 2007, how much longer do we need to get this = right? > =A0 > =A0 > I was also trying to do the same with DS-Lite, but have decided to=20 > give up. DS-Lite has become an enormous distraction to the deployment of = IPv6 service to internet users, so I'm going to stop investing energy into = trying to fix it here. Maybe v4-exit can do better in 6204-ter (sigh). > [Carl] Same applies here as for 6rd. >=20 > =A0 > No. 6rd and DS-Lite are not the same, and do not solve the same=20 > problems. They are night and day different, and every time we lump them t= ogether it causes confusion and trouble. Please stop. >=20 >=20 > To start off, we do support it, again static and dynamic through dhcp=20 > option 64, so no issue on that part.=A0 But proper deployment most=20 > likely will require some extra?s on the CPE, PCP, UPNP-IGD2, something el= se?.=A0 Similar applies here: people starting today to look at it (in Resid= ential CPE world), but for sure not (yet) targeting the move to native-only= , too soon (unfortunately). > =A0 > The real scope creep is the inclusion of IPv4 delivery in an IPv6 CPE=20 > document to start with. If you want to draw a line, draw it before the in= clusion of DS-Lite. Here in v6ops, we need to get IPv6 Internet service off= the ground, and that's already taking plenty of energy as it is. >=20 >=20 > =A0 > As I have said before, I am equally happy with the entire "Transition"=20 > section to be removed from 6204-bis. But, if we step off the cliff, we're= going to get it right, at least for 6rd. Otherwise, it does more harm than= good. > [Carl] Don?t fully agree=A0J.=A0 I see 6rd being used in various ways at= =20 > our customers today.=A0 I must say it?s working rather smooth, using the = features they have available today, so I?d encourage to keep both 6rd and D= SLite in the doc as is, but not start adding more requirements which are to= be applied in later phases. > =A0 > Yes, 6rd is working quite well, I cannot argue with you there. > =A0 > But, I also want my customers to be able to turn off 6rd, and for that=20 > to happen smoothly. Including the requirements for that in 6204-bis won't= hurt that. As you have said, its all just what a "real router" would do an= yway. > =A0 > - Mark >=20 >=20 > I?ve been present on the last 2 v6 world congresses in Paris and the=20 > general statements there were always ?the CPE is the problem?.=A0 Well, g= uess what, it still is, and it still will be if you don?t stop adding requi= rements. > Please draw a line NOW, and take changes and added requirements int= o a later version so the CPE vendor has the time to cope with all of this!!= !=A0 I repeat my > statement from the panel: if we don?t stop adding requirements onto= the (nearly free-of-charge) CPE, the next v6 congress will have again seve= ral > presentations claiming ?The CPE is the problem?. > =A0 > Just on these specific ones: there is the claim that CPE devices are=20 > not ?ready? (whatever that may mean?).=A0 Today, IPv6 roll-out is,=20 > unfortunately, still very (too) limited, but already ?6rd sunsetting? req= uirements are being added to the basic CPE IPV6 reqs, why ?=A0 I don?t doub= t this issue will present itself, but for sure not ?tomorrow?. >=20 > =A0 > That's why: > =A0 > [IMAGE] > =A0 > [Carl] I usually start from the other end @ home=A0J > =A0 > - Mark >=20 >=20 >=20 > =A0 > Regs > Carl > =A0 > From:=A0v6ops-bounces@ietf.org=A0[mailto:v6ops-bounces@ietf.org]=A0On Beh= alf=20 > Of=A0Chris Donley > Sent:=A0dinsdag 24 april 2012 1:04 > To:=A0Mark Townsley;=A0v6ops@ietf.org > Subject:=A0Re: [v6ops] 6rd sunsetting requirements for 6204-bis > =A0 > Mark, > =A0 > Please see in-line. > =A0 > Chris > =A0 > From:=A0Mark Townsley > Date:=A0Mon, 23 Apr 2012 11:27:36 -0600 > To:=A0"v6ops@ietf.org" > Subject:=A0[v6ops] 6rd sunsetting requirements for 6204-bis > =A0 > 6RD-4: A CE router MUST allow 6rd virtual and IPv6 native WAN=20 > interfaces to be active simultaneously in order to support coexistence=20 > of the two technologies during an incremental migration period from=20 > 6rd to native IPv6. > 1. I think this is covered in 6rd-5 and 6rd-7. 2. I don't think this=20 > specific requirement was agreed to in Paris. =A0It's not on your slide 4 = or Slide 15, bullet 1, which were the 'hum's I captured in my notes. > 3. +1 to Hemant's comment ? I don't think this is needed as a MUST. > =A0 > 6RD-5: The CE router MUST associate delegated prefixes with the WAN > interface(s) they were learned from (e.g., DHCPv6-PD, 6rd, etc). Each=20 > packet sent out a WAN interface MUST have a source address that=20 > corresponds to a delegated prefix associated with the given WAN=20 > interface, consistent with what is described in section 4.3 of BCP > 84 (RFC 3704). > 1. We've been advised by the WG in the past to only include a single nor= mative statement per requirement. > 2. This is covered in the existing 6rd-4. > =A0 > 6RD-6: The IPv6 CE router MUST allow different or identical delegated=20 > prefixes on 6rd and native interfaces. A 6rd virtual interface MUST be=A0 > assigned a higher routing cost than a native IPv6 interface. This is=20 > done so that native traffic will be=A0preferred over=A06rd in the event= =A0 > normal IP longest matching and BCP 84 rules would have otherwise=20 > allowed a packet to be equally sent via 6rd or native IPv6. > 1. I think this language (?MUST allow different or identical=20 > delegated prefixes?) is confusing for people not intimately familiar with= your other CE transitioning draft. 2. If I read this correctly, you want = to require two operational states ? one where 6rd and native IPv6 use the s= ame prefix and a second where they use different > prefixes. That requirement is captured in 6rd-5. > 3. As I mentioned above, we have been advised to keep requirements to a = single normative statement, so the part about the routing cost is in 6rd-6. > 4. I've heard from some CPE vendors that specifying routing "cost" may b= e too implementation specific ? I think it's more neutral to speak of prefe= rence ? e.g. prefer > native to 6rd. > =A0 > =A0 >=20 >=20 >=20 >=20 > From mark@townsley.net Wed Apr 25 03:10:24 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C30D21F8738 for ; Wed, 25 Apr 2012 03:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.676 X-Spam-Level: X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[AWL=-0.562, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, 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 A15+I1ioU6Kp for ; Wed, 25 Apr 2012 03:10:23 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8525A21F8773 for ; Wed, 25 Apr 2012 03:10:22 -0700 (PDT) Received: by werb10 with SMTP id b10so1269863wer.31 for ; Wed, 25 Apr 2012 03:10:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=IR8GK054OD4sb/LWW60jTYGEFgRoGSf2bq1BxPwav/M=; b=hwxoM2DqPyxV2llQk4depMDDBjdejcIjalJjff0mrpBSUcfzrpi7eVmDhvh5k6NlqF n4s4Of0PAThssrDSgD4sI9jXs8AQZQ+9OKqHnUfm2m5WyS8deeHE1l03/JVz+IZ+EH+T skZ9Df5X/d+k9KSEnlLLTDIoT8Mm4QXA6O/rHkIvXHJViqXV+/gYnVjcNYcQr8xDI1Yv 98qlGNc4/2HFpPHmbcquOG5WOolATj4dRLTRwOH+sal6TcEdm/Fx38iGcKihWzgJ/Prz NutFZdq2J+s2Q7cegwFJq0ih13a+Mrs//XpTz92qdL+cOtr+wgxx2tZkkx2VMsFNcXqc Cksg== Received: by 10.180.24.66 with SMTP id s2mr5189356wif.7.1335348621723; Wed, 25 Apr 2012 03:10:21 -0700 (PDT) Received: from ams-townsley-8912.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id e6sm36261530wix.8.2012.04.25.03.10.11 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 Apr 2012 03:10:14 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_2FB351A7-F99D-4DBA-9C02-9E72AC82DA4C" From: Mark Townsley In-Reply-To: <42D0E71D-8599-44C6-91D4-B059A276EB6A@cisco.com> Date: Wed, 25 Apr 2012 12:10:08 +0200 Message-Id: <379ECFD4-C696-4B86-9DCA-75B0887C4370@townsley.net> References: <5B6B2B64C9FE2A489045EEEADDAFF2C30483722C@XMB-RCD-109.cisco.com><4F95A3D9.1010100@viagenie.ca><5B6B2B64C9FE2A489045EEEADDAFF2C304837261@XMB-RCD-109.cisco.com><4F95ABA0.8090601@viagenie.ca><5B6B2B64C9FE2A489045EEEADDAFF2C304837272@XMB-RCD-109.cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C30483747A@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3048378BB@XMB-RCD-109.cisco.com> <42D0E71D-8599-44C6-91D4-B059A276EB6A@cisco.com> To: IPv6 Operations X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQm+d2WWFJ/9Hw/ZRwI/VLeraxZ6SK1gkK99x0kimeB6Mq7/l6lltjVyofI0wsW9uGKIvXz5 Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 10:10:24 -0000 --Apple-Mail=_2FB351A7-F99D-4DBA-9C02-9E72AC82DA4C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Whittled down to one sentence each, here are three requirements = necessary in order to support incremental migration from 6rd to native = IPv6:=20 6RD-4: A CE router MUST allow 6rd virtual and IPv6 native WAN interfaces = to be active simultaneously.=20 6RD-5: Each packet sent on a 6rd or native WAN interface MUST be = directed such that its source IP address is derived from the delegated = prefix associated with the upstream network the WAN interface is = connected to [section 4.3 of BCP 84, RFC 3704]. 6RD-6: The CE router MUST allow identical or overlapping delegated = prefixes for each WAN interface with a preference for native IPv6 in the = event forwarding rules would have otherwise directed a packet to be sent = equally via 6rd or native IPv6. Summary: The first requirement says 6rd and native must coexist, the = second ensures that packets are directed such that they are not dropped = by the upstream network, and the third ensures native is chosen over 6rd = in the event the paths are otherwise equal.=20 - Mark On Apr 25, 2012, at 5:23 AM, Fred Baker wrote: >=20 > On Apr 25, 2012, at 5:05 AM, Hemant Singh (shemant) wrote: >=20 >> Fred, >> =20 >> Appreciate the quick reply. In MarkT's comments to Chris that Chris = did not follow the Chairs' recommendation, the statement is not quite = correct. Additionally MarkT saying to the mailer that "He (Chris) = decided to throw them in the trash" is not correct either. See the URL = below where Chris clearly said, he has guidance from the IETF and WG in = the past to not include more than one normative statement per = requirement. Thus Chris broke up the MarkT recommendations and the = break up has to stay. Thus it would help if Mark revisits Chris=92 text = and fills in holes Mark thinks the text has because we just cannot go = back to Mark=92s original text that combines multiple normative = statements in one requirement. >=20 > I would like you to please work with Mark, on the mailer, to = accomplish that.=20 >=20 >> http://www.ietf.org/mail-archive/web/v6ops/current/msg12705.html >> Moving on, the requirements provided by MarkT could use tighter text. = For example here is a portion of text provided to us to add. >> =20 >> "6RD-5: The CE router MUST associate delegated prefixes with the WAN >> interface(s)=94 >> =20 >> The CPE WAN interface can be unnumbered with only an IPv6 link-local = address and thus the CPE WAN does not have a global IPv6 address. In = such an unnumbered model, the CPE uses an address from the PD on a = virtual network interface to source packets out the WAN such as ICMPv6 = errors. I am away from work tomorrow but we can certainly try and close = any text two days from now including any WebEx phone call between Mark = and us authors of rfc6204bis.=20 >=20 > I suspect that you misunderstand Mark's text, which says that the text = he suggested was inadequate.=20 >=20 > RFC 3704, resolving a number of pages into a single sentence, = recommends that if a packet uses a stated source address and that source = address was derived from a stated upstream network, the packet should be = directed to said upstream network. The reason it would do so is that the = upstream networks presumably implement BCP 38, meaning that if it is = directed to a different upstream network it is likely to be dropped. = 3704 goes on to make suggestions regarding the implementation of exit = routing. What Mark is driving at is "implement exit routing; if one is = given multiple prefixes on different interfaces, physical or virtual, = associate each such prefix with its source interface in routing for the = purposes of source-address directed exit routing." >=20 > Explanations and dialog such as this are the reason I am asking you to = TALK WITH MARK about issues you see rather than talking with the chairs = or simply presuming that the working group outcome in Paris is = brain-dead. The outcome was, as near as I could tell, very sensible to = the operators. >=20 >> Another example for tighter text is related to 6RD-4. Why does 6RD-4 = only say =93during an incremental migration period from 6rd to native = IPv6.=94 The SP could encounter a problem moving from 6rd to native = IPv6 and may want to revert back to 6rd. Thus the 6RD-4 bullet should = cater to any migration from 6rd to native IPv6 or vice versa. >> =20 >> Further, when the CPE has different prefixes being used by native = IPV6 and 6rd, a host behind the CPE router has concurrent IPv6 addresses = being used (one IPv6 address from native IPv6 and another from the 6rd = prefix). So what source-address does the host pick to send a packet to = a destination that is totally disjoint with the two prefixes assigned to = the CPE router? Let=92s say the host picked a source address from the = 6rd prefix, then the CPE router ships the packet out the 6rd tunnel = instead of the higher preferred native IPv6 network. So how is the = native IPv6 preference enforced by the CPE router? =20 >> =20 >> We also do not have consensus with the =93MUST=94 in 6RD-4. Current = consensus is mostly towards changing the MUST to a SHOULD. I also do = not see any SP clamoring for 6rd sunsetting. One SP in France or France = that has roughly million 6rd customers does not impress me. I am a = person who gets impressed with 200 million customers which is roughly = what the cable broadband industry is deploying native IPv6 for. =20 >> =20 >> Hemant >> =20 >> =20 >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On = Behalf Of Fred Baker (fred) >> Sent: Tuesday, April 24, 2012 5:33 PM >> To: IPv6 Operations >> Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis >> =20 >> We discussed this at IETF 83, and you will find it in the minutes = when they come out. Mark and Ole asked for two things (statements = regarding 6rd and ds-lite), and the working group agreed to one of them. = We are not discussing a "boiling of the ocean", nor are we discussing an = infinite succession of new requirements. We are discussing getting three = no-brainer-class statements into the draft in a manner that the = discussants all recognize and agree to. The three statements were = clarified by hum in the meeting, and were each able to be stated in a = single sentence. >> =20 >> I would ask the different actors in this discussion to please behave = in a courteous manner toward each other, and work together on this as = requested by the chairs at IETF 83. >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_2FB351A7-F99D-4DBA-9C02-9E72AC82DA4C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

    On Apr 25, 2012, at 5:05 AM, Hemant = Singh (shemant) wrote:

    Fred,
     
    Appreciate the quick reply.  In MarkT's comments to Chris = that Chris did not follow the Chairs' recommendation, the statement is = not quite correct.  Additionally MarkT saying to the mailer = that  "He (Chris) decided to throw them in the trash" is not = correct either.  See the URL below where Chris clearly said, he has = guidance from the IETF and WG in the past to not include more than one = normative statement per requirement.  Thus Chris broke up the MarkT = recommendations and the break up has to stay.  Thus it would help if = Mark revisits Chris=92 text and fills in holes Mark thinks the text has = because we just cannot go back to Mark=92s original text that combines = multiple normative statements in one = requirement.

    I would like you to = please work with Mark, on the mailer, to accomplish = that. 

    <= div>

    I suspect that you = misunderstand Mark's text, which says that the text he suggested was = inadequate. 

    RFC 3704, resolving a = number of pages into a single sentence, recommends that if a packet uses = a stated source address and that source address was derived from a = stated upstream network, the packet should be directed to said upstream = network. The reason it would do so is that the upstream networks = presumably implement BCP 38, meaning that if it is directed to a = different upstream network it is likely to be dropped. 3704 goes on to = make suggestions regarding the implementation of exit routing. What Mark = is driving at is "implement exit routing; if one is given multiple = prefixes on different interfaces, physical or virtual, associate each = such prefix with its source interface in routing for the purposes of = source-address directed exit routing."

    Explanations and = dialog such as this are the reason I am asking you to TALK WITH MARK = about issues you see rather than talking with the chairs or simply = presuming that the working group outcome in Paris is brain-dead. The = outcome was, as near as I could tell, very sensible to the = operators.

    Another example for tighter text is related to 6RD-4.  = Why does 6RD-4 only say =93during an incremental migration period from 6rd to native = IPv6.=94    The SP could encounter a problem moving from 6rd to native IPv6 = and may want to revert back to 6rd.  Thus the 6RD-4 bullet should = cater to any migration from 6rd to native IPv6 or vice = versa.
     
    Further, when the CPE has different prefixes being used by = native IPV6 and 6rd, a host behind the CPE router has concurrent IPv6 = addresses being used (one IPv6 address from native IPv6 and another from = the 6rd prefix).  So what source-address does the host pick to send = a packet to a destination that is totally disjoint with the two prefixes = assigned to the CPE router?  Let=92s say the host picked a source = address from the 6rd prefix, then the CPE router ships the packet out = the 6rd tunnel instead of the higher preferred native IPv6 = network.  So how is the native IPv6 preference enforced by the CPE = router?  
     
    We also do not have consensus with the =93MUST=94 in = 6RD-4.  Current consensus is mostly towards changing the MUST to a = SHOULD.  I = also do not see any SP clamoring for 6rd sunsetting.  One SP in = France or France that has roughly million 6rd customers does not impress = me.  I am a person who gets impressed with 200 million customers = which is roughly what the cable broadband industry is deploying native = IPv6 for.  
     
    Hemant
     
     
    -----Original Message-----
    Sent: Tuesday, April 24, 2012 5:33 = PM
    Subject: Re: [v6ops] 6rd sunsetting requirements for = 6204-bis
     
    We discussed this at IETF 83, and you will find it in the = minutes when they come out. Mark and Ole asked for two things = (statements regarding 6rd and ds-lite), and the working group agreed to = one of them. We are not discussing a "boiling of the ocean", nor are we = discussing an infinite succession of new requirements. We are discussing = getting three no-brainer-class statements into the draft in a manner = that the discussants all recognize and agree to. The three statements = were clarified by hum in the meeting, and were each able to be stated in = a single sentence.
     
    I would ask the different actors in this discussion to please = behave in a courteous manner toward each other, and work together on = this as requested by the chairs at IETF 83.
    v6ops mailing = list
    v6ops@ietf.org
    https://www.ietf.org/= mailman/listinfo/v6ops

    = --Apple-Mail=_2FB351A7-F99D-4DBA-9C02-9E72AC82DA4C-- From sander@steffann.nl Wed Apr 25 03:15:01 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E23121F873C for ; Wed, 25 Apr 2012 03:15:01 -0700 (PDT) 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 sjnxFgpl1qMz for ; Wed, 25 Apr 2012 03:15:00 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id 8F1CA21F86FE for ; Wed, 25 Apr 2012 03:15:00 -0700 (PDT) Received: from [192.168.88.254] (unknown [94.200.91.139]) by mail.sintact.nl (Postfix) with ESMTP id ED0AE2022; Wed, 25 Apr 2012 12:14:58 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Sander Steffann In-Reply-To: <379ECFD4-C696-4B86-9DCA-75B0887C4370@townsley.net> Date: Wed, 25 Apr 2012 14:14:55 +0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5B6B2B64C9FE2A489045EEEADDAFF2C30483722C@XMB-RCD-109.cisco.com><4F95A3D9.1010100@viagenie.ca><5B6B2B64C9FE2A489045EEEADDAFF2C304837261@XMB-RCD-109.cisco.com><4F95ABA0.8090601@viagenie.ca><5B6B2B64C9FE2A489045EEEADDAFF2C304837272@XMB-RCD-109.cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C30483747A@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3048378BB@XMB-RCD-109.cisco.com> <42D0E71D-8599-44C6-91D4-B059A276EB6A@cisco.com> <379ECFD4-C696-4B86-9DCA-75B0887C4370@townsley.net> To: Mark Townsley X-Mailer: Apple Mail (2.1257) Cc: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 10:15:01 -0000 Hi Mark, > Whittled down to one sentence each, here are three requirements = necessary in order to support incremental migration from 6rd to native = IPv6:=20 >=20 > 6RD-4: A CE router MUST allow 6rd virtual and IPv6 native WAN = interfaces to be active simultaneously.=20 >=20 > 6RD-5: Each packet sent on a 6rd or native WAN interface MUST be = directed such that its source IP address is derived from the delegated = prefix associated with the upstream network the WAN interface is = connected to [section 4.3 of BCP 84, RFC 3704]. >=20 > 6RD-6: The CE router MUST allow identical or overlapping delegated = prefixes for each WAN interface with a preference for native IPv6 in the = event forwarding rules would have otherwise directed a packet to be sent = equally via 6rd or native IPv6. >=20 > Summary: The first requirement says 6rd and native must coexist, the = second ensures that packets are directed such that they are not dropped = by the upstream network, and the third ensures native is chosen over 6rd = in the event the paths are otherwise equal.=20 +1 - Sander From shemant@cisco.com Wed Apr 25 04:08:39 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 012A221F870F for ; Wed, 25 Apr 2012 04:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.248 X-Spam-Level: X-Spam-Status: No, score=-10.248 tagged_above=-999 required=5 tests=[AWL=-0.249, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15TUAgBmFNTI for ; Wed, 25 Apr 2012 04:08:38 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 3B79421F86FA for ; Wed, 25 Apr 2012 04:08:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1299; q=dns/txt; s=iport; t=1335352118; x=1336561718; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=bcJvR0SD3VNkboM9ra5npRRjELv7e4PC3T49pxm5MfM=; b=gE7Ln8dgolgS4bBpu2Xa7ZG+8/U76iPxr06Q3OrpZrWyF/p8mc4y4msI htoZnoPhQ46ZG4TZD/WCQ1mzfSRmzfWy7icCitgJ8rhE60CcdNbSrF083 Q0dWTlcfiig2J87iQEVeCbHrdlyDMTKJprntKJahWNP7OgJqJ4ByE6DVh 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAELal0+tJV2c/2dsb2JhbABEsUiBB4IJAQEBBAEBAQ8BHQo0FwQCAQgRBAEBCwYXAQYBJh8JCAEBBAESCBqHbQuac6AhBIlrhiljBIhjm22BaYMH X-IronPort-AV: E=Sophos;i="4.75,480,1330905600"; d="scan'208";a="74644638" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 25 Apr 2012 11:08:37 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id q3PB8b1q029249 for ; Wed, 25 Apr 2012 11:08:37 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, 25 Apr 2012 06:08:37 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 25 Apr 2012 06:08:36 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3048378E6@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] 6rd sunsetting requirements for 6204-bis Thread-Index: Ac0iYhwXyrgS1dI9QLq3wOGDK5tbdgAcL5kg References: <5B6B2B64C9FE2A489045EEEADDAFF2C30483722C@XMB-RCD-109.cisco.com><4F95A3D9.1010100@viagenie.ca><5B6B2B64C9FE2A489045EEEADDAFF2C304837261@XMB-RCD-109.cisco.com><4F95ABA0.8090601@viagenie.ca><5B6B2B64C9FE2A489045EEEADDAFF2C304837272@XMB-RCD-109.cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C30483747A@XMB-RCD-109.cisco.com> From: "Hemant Singh (shemant)" To: "Fred Baker (fred)" , "IPv6 Operations" X-OriginalArrivalTime: 25 Apr 2012 11:08:37.0710 (UTC) FILETIME=[C3817EE0:01CD22D3] Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 11:08:39 -0000 One question. Which RFC specifies the technology for the procedure to sunset 6rd to native IPv6 or vice versa between the SP and the CPE router? =20 Hemant -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Fred Baker (fred) Sent: Tuesday, April 24, 2012 5:33 PM To: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis We discussed this at IETF 83, and you will find it in the minutes when they come out. Mark and Ole asked for two things (statements regarding 6rd and ds-lite), and the working group agreed to one of them. We are not discussing a "boiling of the ocean", nor are we discussing an infinite succession of new requirements. We are discussing getting three no-brainer-class statements into the draft in a manner that the discussants all recognize and agree to. The three statements were clarified by hum in the meeting, and were each able to be stated in a single sentence. I would ask the different actors in this discussion to please behave in a courteous manner toward each other, and work together on this as requested by the chairs at IETF 83. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From shane@castlepoint.net Wed Apr 25 06:52:35 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F0A821F8633 for ; Wed, 25 Apr 2012 06:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_41=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 1YLRPEgziy-x for ; Wed, 25 Apr 2012 06:52:34 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 89ABC21F856F for ; Wed, 25 Apr 2012 06:52:34 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 13659268063; Wed, 25 Apr 2012 07:52:33 -0600 (MDT) Received: from host2.tcb.net (64.78.235.218 [64.78.235.218]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Wed, 25 Apr 2012 07:52:33 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.235.218; client-port=54331; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Shane Amante In-Reply-To: Date: Wed, 25 Apr 2012 07:52:32 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <139C51A6-8305-4368-9E44-E1224631CF16@castlepoint.net> References: <5B6B2B64C9FE2A489045EEEADDAFF2C30483722C@XMB-RCD-109.cisco.com><4F95A3D9.1010100@viagenie.ca><5B6B2B64C9FE2A489045EEEADDAFF2C304837261@XMB-RCD-109.cisco.com><4F95ABA0.8090601@viagenie.ca><5B6B2B64C9FE2A489045EEEADDAFF2C304837272@XMB-RCD-109.cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C30483747A@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3048378BB@XMB-RCD-109.cisco.com> <42D0E71D-8599-44C6-91D4-B059A276EB6A@cisco.com> <379ECFD4-C696-4B86-9DCA-75B0887C4370@townsley.net> To: Sander Steffann X-Mailer: Apple Mail (2.1257) Cc: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 13:52:35 -0000 On Apr 25, 2012, at 4:14 AM, Sander Steffann wrote: > Hi Mark, >=20 >> Whittled down to one sentence each, here are three requirements = necessary in order to support incremental migration from 6rd to native = IPv6:=20 >>=20 >> 6RD-4: A CE router MUST allow 6rd virtual and IPv6 native WAN = interfaces to be active simultaneously.=20 >>=20 >> 6RD-5: Each packet sent on a 6rd or native WAN interface MUST be = directed such that its source IP address is derived from the delegated = prefix associated with the upstream network the WAN interface is = connected to [section 4.3 of BCP 84, RFC 3704]. >>=20 >> 6RD-6: The CE router MUST allow identical or overlapping delegated = prefixes for each WAN interface with a preference for native IPv6 in the = event forwarding rules would have otherwise directed a packet to be sent = equally via 6rd or native IPv6. >>=20 >> Summary: The first requirement says 6rd and native must coexist, the = second ensures that packets are directed such that they are not dropped = by the upstream network, and the third ensures native is chosen over 6rd = in the event the paths are otherwise equal.=20 >=20 > +1 The above are all logical & straightforward, so an addt'l +1. -shane= From shemant@cisco.com Wed Apr 25 08:08:37 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A982321F86DE for ; Wed, 25 Apr 2012 08:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.213 X-Spam-Level: X-Spam-Status: No, score=-10.213 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id os8aUj0PfcnL for ; Wed, 25 Apr 2012 08:08:37 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id E78DA21F86DA for ; Wed, 25 Apr 2012 08:08:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=1908; q=dns/txt; s=iport; t=1335366517; x=1336576117; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=AhI10jF5rqzzEh6tFN9lCF3scOtjp1EP3MKF9sbjfQE=; b=D7o1zJvApJ3I1pcdj6mY58k7keH9PI2tMQ0kad4lfqMCWwP2/4EsRyT0 qWVBS3sRZltaEwsSrOqXyMHbLMsRJwqJPeQ0Q63KvuC1+uCepp/hfBosq INPsy5FRhEQ1XMTwgTYIQXhzfwv5MXaLVg1JNADdNVRuckjgRPzSiYP05 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAEsSmE+tJV2a/2dsb2JhbABFsUyBB4IJAQEBBAEBAQ8BHQo0FwQCAQgRBAEBCwYXAQYBJh8JCAEBBAESCBqHbQubHaAmBIlrhiljBIhjm22BaYMH X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="77740657" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 25 Apr 2012 15:08:36 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3PF8a8L016038 for ; Wed, 25 Apr 2012 15:08:36 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, 25 Apr 2012 10:08: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: Wed, 25 Apr 2012 10:08:35 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3048379F6@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3048378E6@XMB-RCD-109.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] 6rd sunsetting requirements for 6204-bis Thread-Index: Ac0iYhwXyrgS1dI9QLq3wOGDK5tbdgAcL5kgAAiLWDA= References: <5B6B2B64C9FE2A489045EEEADDAFF2C30483722C@XMB-RCD-109.cisco.com><4F95A3D9.1010100@viagenie.ca><5B6B2B64C9FE2A489045EEEADDAFF2C304837261@XMB-RCD-109.cisco.com><4F95ABA0.8090601@viagenie.ca><5B6B2B64C9FE2A489045EEEADDAFF2C304837272@XMB-RCD-109.cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C30483747A@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3048378E6@XMB-RCD-109.cisco.com> From: "Hemant Singh (shemant)" To: "Hemant Singh (shemant)" , "Fred Baker (fred)" , "IPv6 Operations" X-OriginalArrivalTime: 25 Apr 2012 15:08:36.0253 (UTC) FILETIME=[49B4CCD0:01CD22F5] Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 15:08:37 -0000 We are glossing over lot of unspecified technology with the MarkT 6rd sunsetting reqs, but if the WG so deems, I'd be happy to put the MarkT text into rfc6204bis and move rfc6204bis forward. Hemant -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Hemant Singh (shemant) Sent: Wednesday, April 25, 2012 7:09 AM To: Fred Baker (fred); IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis One question. Which RFC specifies the technology for the procedure to sunset 6rd to native IPv6 or vice versa between the SP and the CPE router? =20 Hemant -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Fred Baker (fred) Sent: Tuesday, April 24, 2012 5:33 PM To: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis We discussed this at IETF 83, and you will find it in the minutes when they come out. Mark and Ole asked for two things (statements regarding 6rd and ds-lite), and the working group agreed to one of them. We are not discussing a "boiling of the ocean", nor are we discussing an infinite succession of new requirements. We are discussing getting three no-brainer-class statements into the draft in a manner that the discussants all recognize and agree to. The three statements were clarified by hum in the meeting, and were each able to be stated in a single sentence. I would ask the different actors in this discussion to please behave in a courteous manner toward each other, and work together on this as requested by the chairs at IETF 83. _______________________________________________ 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 C.Donley@cablelabs.com Wed Apr 25 09:17:34 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41E0621F8616 for ; Wed, 25 Apr 2012 09:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.162 X-Spam-Level: X-Spam-Status: No, score=-0.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] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3zfBsqBc7bLl for ; Wed, 25 Apr 2012 09:17:32 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id ABDE921F85E6 for ; Wed, 25 Apr 2012 09:17:32 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id q3PGHVaZ019130; Wed, 25 Apr 2012 10:17:31 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Wed, 25 Apr 2012 10:17:31 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Wed, 25 Apr 2012 10:17:31 -0600 From: Chris Donley To: Mark Townsley , IPv6 Operations Date: Wed, 25 Apr 2012 10:19:35 -0600 Thread-Topic: [v6ops] 6rd sunsetting requirements for 6204-bis Thread-Index: Ac0i/uoU8eO8Vn6dTn6lX2y1QPC/Fg== Message-ID: In-Reply-To: <379ECFD4-C696-4B86-9DCA-75B0887C4370@townsley.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CBBD7B164B851cdonleycablelabscom_" MIME-Version: 1.0 X-Approved: ondar Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 16:17:34 -0000 --_000_CBBD7B164B851cdonleycablelabscom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I'm OK with 6rd-5. I'm OK in principle with 6rd-4, but I am concerned that as written, it migh= t be interpreted that both 6rd and native always need to be active simultan= eously, and I think that could cause problems when it's not the intent of t= he ISP. Perhaps the following would clarify: 6RD-4: A CE router MUST support simultaneous operation of 6rd virtual and I= Pv6 native WAN interfaces. However, 6rd and native IPv6 can be configured = independently; in many cases, only a single IPv6 WAN interface (native or 6= rd) needs to be active. 6rd-6 is really two requirements. I am concerned that its current form is = ambiguous. I would prefer: 6rd-6: The IPv6 CE Router MUST allow the 6rd virtual interface and IPv6 nat= ive interface to use identical or overlapping prefixes. This requirement do= es not preclude the IPv6 CE Router from using different prefixes for the 6r= d virtual interface and IPv6 native interface. 6rd-7: In the event that forwarding rules produce a tie between 6rd and nat= ive IPv6, by default, the IPv6 CE Router MUST prefer native IPv6. Chris From: Mark Townsley > Date: Wed, 25 Apr 2012 04:10:08 -0600 To: IPv6 Operations > Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis Whittled down to one sentence each, here are three requirements necessary i= n order to support incremental migration from 6rd to native IPv6: 6RD-4: A CE router MUST allow 6rd virtual and IPv6 native WAN interfaces to= be active simultaneously. 6RD-5: Each packet sent on a 6rd or native WAN interface MUST be directed s= uch that its source IP address is derived from the delegated prefix associa= ted with the upstream network the WAN interface is connected to [section 4.= 3 of BCP 84, RFC 3704]. 6RD-6: The CE router MUST allow identical or overlapping delegated prefixes= for each WAN interface with a preference for native IPv6 in the event forw= arding rules would have otherwise directed a packet to be sent equally via = 6rd or native IPv6. Summary: The first requirement says 6rd and native must coexist, the second= ensures that packets are directed such that they are not dropped by the up= stream network, and the third ensures native is chosen over 6rd in the even= t the paths are otherwise equal. - Mark On Apr 25, 2012, at 5:23 AM, Fred Baker wrote: On Apr 25, 2012, at 5:05 AM, Hemant Singh (shemant) wrote: Fred, Appreciate the quick reply. In MarkT's comments to Chris that Chris did no= t follow the Chairs' recommendation, the statement is not quite correct. A= dditionally MarkT saying to the mailer that "He (Chris) decided to throw t= hem in the trash" is not correct either. See the URL below where Chris cle= arly said, he has guidance from the IETF and WG in the past to not include = more than one normative statement per requirement. Thus Chris broke up the= MarkT recommendations and the break up has to stay. Thus it would help if= Mark revisits Chris=92 text and fills in holes Mark thinks the text has be= cause we just cannot go back to Mark=92s original text that combines multip= le normative statements in one requirement. I would like you to please work with Mark, on the mailer, to accomplish tha= t. http://www.ietf.org/mail-archive/web/v6ops/current/msg12705.html Moving on, the requirements provided by MarkT could use tighter text. For = example here is a portion of text provided to us to add. "6RD-5: The CE router MUST associate delegated prefixes with the WAN interface(s)=94 The CPE WAN interface can be unnumbered with only an IPv6 link-local addres= s and thus the CPE WAN does not have a global IPv6 address. In such an unn= umbered model, the CPE uses an address from the PD on a virtual network int= erface to source packets out the WAN such as ICMPv6 errors. I am away from= work tomorrow but we can certainly try and close any text two days from no= w including any WebEx phone call between Mark and us authors of rfc6204bis. I suspect that you misunderstand Mark's text, which says that the text he s= uggested was inadequate. RFC 3704, resolving a number of pages into a single sentence, recommends th= at if a packet uses a stated source address and that source address was der= ived from a stated upstream network, the packet should be directed to said = upstream network. The reason it would do so is that the upstream networks p= resumably implement BCP 38, meaning that if it is directed to a different u= pstream network it is likely to be dropped. 3704 goes on to make suggestion= s regarding the implementation of exit routing. What Mark is driving at is = "implement exit routing; if one is given multiple prefixes on different int= erfaces, physical or virtual, associate each such prefix with its source in= terface in routing for the purposes of source-address directed exit routing= ." Explanations and dialog such as this are the reason I am asking you to TALK= WITH MARK about issues you see rather than talking with the chairs or simp= ly presuming that the working group outcome in Paris is brain-dead. The out= come was, as near as I could tell, very sensible to the operators. Another example for tighter text is related to 6RD-4. Why does 6RD-4 only = say =93during an incremental migration period from 6rd to native IPv6.=94 = The SP could encounter a problem moving from 6rd to native IPv6 and may w= ant to revert back to 6rd. Thus the 6RD-4 bullet should cater to any migra= tion from 6rd to native IPv6 or vice versa. Further, when the CPE has different prefixes being used by native IPV6 and = 6rd, a host behind the CPE router has concurrent IPv6 addresses being used = (one IPv6 address from native IPv6 and another from the 6rd prefix). So wh= at source-address does the host pick to send a packet to a destination that= is totally disjoint with the two prefixes assigned to the CPE router? Let= =92s say the host picked a source address from the 6rd prefix, then the CPE= router ships the packet out the 6rd tunnel instead of the higher preferred= native IPv6 network. So how is the native IPv6 preference enforced by the= CPE router? We also do not have consensus with the =93MUST=94 in 6RD-4. Current consen= sus is mostly towards changing the MUST to a SHOULD. I also do not see any= SP clamoring for 6rd sunsetting. One SP in France or France that has roug= hly million 6rd customers does not impress me. I am a person who gets impr= essed with 200 million customers which is roughly what the cable broadband = industry is deploying native IPv6 for. Hemant -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-b= ounces@ietf.org] On Behalf Of Fred = Baker (fred) Sent: Tuesday, April 24, 2012 5:33 PM To: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis We discussed this at IETF 83, and you will find it in the minutes when they= come out. Mark and Ole asked for two things (statements regarding 6rd and = ds-lite), and the working group agreed to one of them. We are not discussin= g a "boiling of the ocean", nor are we discussing an infinite succession of= new requirements. We are discussing getting three no-brainer-class stateme= nts into the draft in a manner that the discussants all recognize and agree= to. The three statements were clarified by hum in the meeting, and were ea= ch able to be stated in a single sentence. I would ask the different actors in this discussion to please behave in a c= ourteous manner toward each other, and work together on this as requested b= y the chairs at IETF 83. _______________________________________________ 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 --_000_CBBD7B164B851cdonleycablelabscom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
    I'm OK with 6rd-5. &n= bsp;

    I'm OK in principle with 6rd-4, but I am conc= erned that as written, it might be interpreted that both 6rd and native alw= ays need to be active simultaneously, and I think that could cause problems= when it's not the intent of the ISP.  Perhaps the following would cla= rify:
    6RD-4: A CE router MUST support simultaneous operation of 6= rd virtual and IPv6 native WAN interfaces.  However, 6rd and native IP= v6 can be configured independently; in many cases, only a single IPv6 WAN i= nterface (native or 6rd) needs to be active.

    6rd-6 is r= eally two requirements.  I am concerned that its current form is ambig= uous.  I would prefer:
    6rd-6: The IPv6 CE Router MUST allow the 6rd virtual in= terface and IPv6 native interface to use identical or overlapping prefixes.= This requirement does not preclude the IPv6 CE Router from using different= prefixes for the 6rd virtual interface and IPv6 native interface.
    6rd-7: In the event that forwarding= rules produce a tie between 6rd and native IPv6, by default, the IPv6 CE R= outer MUST prefer native IPv6.

    <= /span>
    Chris=

    From: Mark Townsley <mark= @townsley.net>
    Date: Wed= , 25 Apr 2012 04:10:08 -0600
    To: IPv6 Operations <v6ops@ietf.org&= gt;
    Subject: Re: [v6ops] 6rd su= nsetting requirements for 6204-bis


    Whittled down to one sentence each, = here are three requirements necessary in order to support incremental migra= tion from 6rd to native IPv6: 


    = 6RD-4: A CE router MUST allow 6rd virtual and IPv6 native WAN interfaces to= be active simultaneously. 

    6RD-5: Each packet s= ent on a 6rd or native WAN interface MUST be directed such that its so= urce IP address is derived from the delegated prefix associated w= ith the upstream network the WAN interface is connected to [secti= on 4.3 of BCP 84, RFC 3704].

    6RD-6: The CE router M= UST allow identical or overlapping delegated prefixes for each WAN int= erface with a preference for native IPv6 in the event forwarding rules woul= d have otherwise directed a packet to be sent equally via 6rd or nativ= e IPv6.


    Summary: The first re= quirement says 6rd and native must coexist, the second ensures that packets= are directed such that they are not dropped by the upstream network, and t= he third ensures native is chosen over 6rd in the event the paths are other= wise equal. 

    - Mark


    <= div>
    On Apr 25, 2012, at 5:23 AM, Fred Baker wrote:


    On Apr 25, 2012, at 5:05 AM= , Hemant Singh (shemant) wrote:

    Fred,
    &nb= sp;
    Appreciate the quick = reply.  In MarkT's comments to Chris that Chris did not follow the Cha= irs' recommendation, the statement is not quite correct.  Additionally= MarkT saying to the mailer that  "He (Chris) decided to throw th= em in the trash" is not correct either.  See the URL below where = Chris clearly said, he has guidance from the IETF and WG in the past to not= include more than one normative statement per requirement.  Thus Chri= s broke up the MarkT recommendations and the break up has to stay.  Thus it would help if Ma= rk revisits Chris=92 text and fills in holes Mark thinks the text has becau= se we just cannot go back to Mark=92s original text that combines multiple = normative statements in one requirement.
    <= /div>

    I would like you to please work with Mark, on = the mailer, to accomplish that. 

    Moving on, the requirements= provided by MarkT could use tighter text.  For example here is a portion of text provid= ed to us to add.
     
    "6RD-5: The= CE router MUST associate delegated prefixes with the WAN=
    interface(s)=94
     
    The CPE WAN interface can be unnumbered with only an = IPv6 link-local address and thus the CPE WAN does not have a global IPv6 ad= dress.  In such an unnumbered model, the CPE uses an address from the = PD on a virtual network interface to source packets out the WAN such as ICM= Pv6 errors.  I am away from work tomorrow but we can certainly try and= close any text two days from now including any WebEx phone call between Ma= rk and us authors of rfc6204bis. 
    <= /span>

    <= /div>
    I suspect that you misunderstand Mark's text, which = says that the text he suggested was inadequate. 

    RFC 3704, resolving a number of= pages into a single sentence, recommends that if a packet uses a stated so= urce address and that source address was derived from a stated upstream net= work, the packet should be directed to said upstream network. The reason it= would do so is that the upstream networks presumably implement BCP 38, mea= ning that if it is directed to a different upstream network it is likely to= be dropped. 3704 goes on to make suggestions regarding the implementation = of exit routing. What Mark is driving at is "implement exit routing; i= f one is given multiple prefixes on different interfaces, physical or virtu= al, associate each such prefix with its source interface in routing for the= purposes of source-address directed exit routing."

    Explanations and dialog such= as this are the reason I am asking you to TALK WITH MARK about issues you = see rather than talking with the chairs or simply presuming that the workin= g group outcome in Paris is brain-dead. The outcome was, as near as I could= tell, very sensible to the operators.

    Another example for tighter text is related to 6RD-4.  Why do= es 6RD-4 only say =93du= ring an incremental migration period from 6rd to native IPv6.=94&nbs= p;   The SP could en= counter a problem moving from 6rd to native IPv6 and may want to revert bac= k to 6rd.  Thus the 6RD-4 bullet should cater to any migration from 6r= d to native IPv6 or vice versa.
     
    F= urther, when the CPE has different prefixes being used by native IPV6 and 6= rd, a host behind the CPE router has concurrent IPv6 addresses being used (= one IPv6 address from native IPv6 and another from the 6rd prefix).  S= o what source-address does the host pick to send a packet to a destination = that is totally disjoint with the two prefixes assigned to the CPE router?&= nbsp; Let=92s say the host picked a source address from the 6rd prefix, the= n the CPE router ships the packet out the 6rd tunnel instead of the higher = preferred native IPv6 network.  So how is the native IPv6 preference e= nforced by the CPE router?  
     
    We also do not have consensus with the =93MUST=94 in 6RD-4.  Cur= rent consensus is mostly towards changing the MUST to a SHOULD.  I also do not see any SP cl= amoring for 6rd sunsetting.  One SP in France or France that has r= oughly million 6rd customers does not impress me.  I am a person who g= ets impressed with 200 million customers which is roughly what the cable br= oadband industry is deploying native IPv6 for.  
     
    Hemant
     
     
    -----Original Mes= sage-----
    From: v6ops-boun= ces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Fred Baker (fred)
    Sent: Tuesday, April 24, 2012 5:= 33 PM
    To: IPv6 Opera= tions
    Subject: Re: [= v6ops] 6rd sunsetting requirements for 6204-bis
     
    We discussed this at IETF 83, and you will find it in the mi= nutes when they come out. Mark and Ole asked for two things (statements reg= arding 6rd and ds-lite), and the working group agreed to one of them. We ar= e not discussing a "boiling of the ocean", nor are we discussing = an infinite succession of new requirements. We are discussing getting three= no-brainer-class statements into the draft in a manner that the discussant= s all recognize and agree to. The three statements were clarified by hum in= the meeting, and were each able to be stated in a single sentence.
     
    I would ask the different actors in this= discussion to please behave in a courteous manner toward each other, and w= ork together on this as requested by the chairs at IETF 83.
    ___________________________________= ____________
    v6ops m= ailing list
    https://www.ietf.org/mailman/listinfo/v= 6ops

    <= /div>_______________________________________________
    v6ops mailing list<= br>v6ops@ietf.org
    https://www.ietf.org/mailman/listin= fo/v6ops

    --_000_CBBD7B164B851cdonleycablelabscom_-- From acassen@corp.free.fr Wed Apr 25 09:53:06 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1604121F86C1 for ; Wed, 25 Apr 2012 09:53:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[AWL=1.657, 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 Ui+mroYqvUSB for ; Wed, 25 Apr 2012 09:53:05 -0700 (PDT) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [IPv6:2a01:e0c:1:1599::14]) by ietfa.amsl.com (Postfix) with ESMTP id 2D45721F863F for ; Wed, 25 Apr 2012 09:53:03 -0700 (PDT) Received: from lnxos-dev (unknown [213.228.1.188]) by smtp5-g21.free.fr (Postfix) with ESMTP id 62E3CD4823F; Wed, 25 Apr 2012 18:52:57 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by lnxos-dev (Postfix) with ESMTPS id 8E0D29C0010; Wed, 25 Apr 2012 18:49:33 +0200 (CEST) Date: Wed, 25 Apr 2012 18:49:32 +0200 (CEST) From: Alexandre Cassen X-X-Sender: acassen@lnxos-dev To: Sander Steffann In-Reply-To: Message-ID: References: <5B6B2B64C9FE2A489045EEEADDAFF2C30483722C@XMB-RCD-109.cisco.com><4F95A3D9.1010100@viagenie.ca><5B6B2B64C9FE2A489045EEEADDAFF2C304837261@XMB-RCD-109.cisco.com><4F95ABA0.8090601@viagenie.ca><5B6B2B64C9FE2A489045EEEADDAFF2C304837272@XMB-RCD-109.cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C30483747A@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3048378BB@XMB-RCD-109.cisco.com> <42D0E71D-8599-44C6-91D4-B059A276EB6A@cisco.com> <379ECFD4-C696-4B86-9DCA-75B0887C4370@townsley.net> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 16:53:06 -0000 On Wed, 25 Apr 2012, Sander Steffann wrote: > Date: Wed, 25 Apr 2012 14:14:55 +0400 > From: Sander Steffann > To: Mark Townsley > Cc: IPv6 Operations > Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis > > Hi Mark, > >> Whittled down to one sentence each, here are three requirements necessary in order to support incremental migration from 6rd to native IPv6: >> >> 6RD-4: A CE router MUST allow 6rd virtual and IPv6 native WAN interfaces to be active simultaneously. >> >> 6RD-5: Each packet sent on a 6rd or native WAN interface MUST be directed such that its source IP address is derived from the delegated prefix associated with the upstream network the WAN interface is connected to [section 4.3 of BCP 84, RFC 3704]. >> >> 6RD-6: The CE router MUST allow identical or overlapping delegated prefixes for each WAN interface with a preference for native IPv6 in the event forwarding rules would have otherwise directed a packet to be sent equally via 6rd or native IPv6. >> >> Summary: The first requirement says 6rd and native must coexist, the second ensures that packets are directed such that they are not dropped by the upstream network, and the third ensures native is chosen over 6rd in the event the paths are otherwise equal. > > +1 +1 regs, Alexandre From despres.remi@laposte.net Wed Apr 25 10:09:16 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5EA721F877F for ; Wed, 25 Apr 2012 10:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.412 X-Spam-Level: X-Spam-Status: No, score=-1.412 tagged_above=-999 required=5 tests=[AWL=-0.598, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, 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 6YP6n83K3lvf for ; Wed, 25 Apr 2012 10:09:13 -0700 (PDT) Received: from smtpout.laposte.net (smtpout5.laposte.net [193.253.67.230]) by ietfa.amsl.com (Postfix) with ESMTP id E228921F8675 for ; Wed, 25 Apr 2012 10:09:05 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8509-out with ME id 2H871j00137Y3f403H91Kk; Wed, 25 Apr 2012 19:09:02 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-77-584255725 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <379ECFD4-C696-4B86-9DCA-75B0887C4370@townsley.net> Date: Wed, 25 Apr 2012 19:09:01 +0200 Message-Id: <504FAF77-A618-4E89-86ED-727FD0FEF473@laposte.net> References: <5B6B2B64C9FE2A489045EEEADDAFF2C30483722C@XMB-RCD-109.cisco.com><4F95A3D9.1010100@viagenie.ca><5B6B2B64C9FE2A489045EEEADDAFF2C304837261@XMB-RCD-109.cisco.com><4F95ABA0.8090601@viagenie.ca><5B6B2B64C9FE2A489045EEEADDAFF2C304837272@XMB-RCD-109.cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C30483747A@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3048378BB@XMB-RCD-109.cisco.com> <42D0E71D-8599-44C6-91D4-B059A276EB6A@cisco.com> <379ECFD4-C696-4B86-9DCA-75B0887C4370@townsley.net> To: Mark Townsley X-Mailer: Apple Mail (2.1084) Cc: IPv6 Operations Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 17:09:16 -0000 --Apple-Mail-77-584255725 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Mark, While it is important that 6204bis includes 6rd, and while it is also = important to specify a 6rd sunsetting plan (good that you took the = initiative), I don't think it is right to include 6RD-4 to 6RD-6 at this = stage. Reasons: - Proof that no sunsetting solution is possible without these = requirements hasn't been given. - I even think that, in a node supporting both IPv6 via IPv4 (6rd) and = IPv4 via IPv6 with public IPv4 addresses (MAP or 4rd), the IPv4 and IPv4 = and IPv6 routers can each see only one interface. (The fact that it uses = link layer interfaces natively or with some tunneling can AFAIK be kept = invisible to the router.) Until a complete solution is described, doubt remains, but freezing now = the idea that this would be impossible isn't needed. Suggestion: keep 6RD-1 to 6RD-4, replace the others by a note warning = that a specification needs to be added to handle 6RD sunsetting. =20 Regards, RD =20 Le 2012-04-25 =E0 12:10, Mark Townsley a =E9crit : >=20 > Whittled down to one sentence each, here are three requirements = necessary in order to support incremental migration from 6rd to native = IPv6:=20 >=20 >=20 > 6RD-4: A CE router MUST allow 6rd virtual and IPv6 native WAN = interfaces to be active simultaneously.=20 >=20 > 6RD-5: Each packet sent on a 6rd or native WAN interface MUST be = directed such that its source IP address is derived from the delegated = prefix associated with the upstream network the WAN interface is = connected to [section 4.3 of BCP 84, RFC 3704]. >=20 > 6RD-6: The CE router MUST allow identical or overlapping delegated = prefixes for each WAN interface with a preference for native IPv6 in the = event forwarding rules would have otherwise directed a packet to be sent = equally via 6rd or native IPv6. >=20 >=20 > Summary: The first requirement says 6rd and native must coexist, the = second ensures that packets are directed such that they are not dropped = by the upstream network, and the third ensures native is chosen over 6rd = in the event the paths are otherwise equal.=20 >=20 > - Mark >=20 >=20 > On Apr 25, 2012, at 5:23 AM, Fred Baker wrote: >=20 >>=20 >> On Apr 25, 2012, at 5:05 AM, Hemant Singh (shemant) wrote: >>=20 >>> Fred, >>> =20 >>> Appreciate the quick reply. In MarkT's comments to Chris that Chris = did not follow the Chairs' recommendation, the statement is not quite = correct. Additionally MarkT saying to the mailer that "He (Chris) = decided to throw them in the trash" is not correct either. See the URL = below where Chris clearly said, he has guidance from the IETF and WG in = the past to not include more than one normative statement per = requirement. Thus Chris broke up the MarkT recommendations and the = break up has to stay. Thus it would help if Mark revisits Chris=92 text = and fills in holes Mark thinks the text has because we just cannot go = back to Mark=92s original text that combines multiple normative = statements in one requirement. >>=20 >> I would like you to please work with Mark, on the mailer, to = accomplish that.=20 >>=20 >>> http://www.ietf.org/mail-archive/web/v6ops/current/msg12705.html >>> Moving on, the requirements provided by MarkT could use tighter = text. For example here is a portion of text provided to us to add. >>> =20 >>> "6RD-5: The CE router MUST associate delegated prefixes with the WAN >>> interface(s)=94 >>> =20 >>> The CPE WAN interface can be unnumbered with only an IPv6 link-local = address and thus the CPE WAN does not have a global IPv6 address. In = such an unnumbered model, the CPE uses an address from the PD on a = virtual network interface to source packets out the WAN such as ICMPv6 = errors. I am away from work tomorrow but we can certainly try and close = any text two days from now including any WebEx phone call between Mark = and us authors of rfc6204bis.=20 >>=20 >> I suspect that you misunderstand Mark's text, which says that the = text he suggested was inadequate.=20 >>=20 >> RFC 3704, resolving a number of pages into a single sentence, = recommends that if a packet uses a stated source address and that source = address was derived from a stated upstream network, the packet should be = directed to said upstream network. The reason it would do so is that the = upstream networks presumably implement BCP 38, meaning that if it is = directed to a different upstream network it is likely to be dropped. = 3704 goes on to make suggestions regarding the implementation of exit = routing. What Mark is driving at is "implement exit routing; if one is = given multiple prefixes on different interfaces, physical or virtual, = associate each such prefix with its source interface in routing for the = purposes of source-address directed exit routing." >>=20 >> Explanations and dialog such as this are the reason I am asking you = to TALK WITH MARK about issues you see rather than talking with the = chairs or simply presuming that the working group outcome in Paris is = brain-dead. The outcome was, as near as I could tell, very sensible to = the operators. >>=20 >>> Another example for tighter text is related to 6RD-4. Why does = 6RD-4 only say =93during an incremental migration period from 6rd to = native IPv6.=94 The SP could encounter a problem moving from 6rd to = native IPv6 and may want to revert back to 6rd. Thus the 6RD-4 bullet = should cater to any migration from 6rd to native IPv6 or vice versa. >>> =20 >>> Further, when the CPE has different prefixes being used by native = IPV6 and 6rd, a host behind the CPE router has concurrent IPv6 addresses = being used (one IPv6 address from native IPv6 and another from the 6rd = prefix). So what source-address does the host pick to send a packet to = a destination that is totally disjoint with the two prefixes assigned to = the CPE router? Let=92s say the host picked a source address from the = 6rd prefix, then the CPE router ships the packet out the 6rd tunnel = instead of the higher preferred native IPv6 network. So how is the = native IPv6 preference enforced by the CPE router? =20 >>> =20 >>> We also do not have consensus with the =93MUST=94 in 6RD-4. Current = consensus is mostly towards changing the MUST to a SHOULD. I also do = not see any SP clamoring for 6rd sunsetting. One SP in France or France = that has roughly million 6rd customers does not impress me. I am a = person who gets impressed with 200 million customers which is roughly = what the cable broadband industry is deploying native IPv6 for. =20 >>> =20 >>> Hemant >>> =20 >>> =20 >>> -----Original Message----- >>> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On = Behalf Of Fred Baker (fred) >>> Sent: Tuesday, April 24, 2012 5:33 PM >>> To: IPv6 Operations >>> Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis >>> =20 >>> We discussed this at IETF 83, and you will find it in the minutes = when they come out. Mark and Ole asked for two things (statements = regarding 6rd and ds-lite), and the working group agreed to one of them. = We are not discussing a "boiling of the ocean", nor are we discussing an = infinite succession of new requirements. We are discussing getting three = no-brainer-class statements into the draft in a manner that the = discussants all recognize and agree to. The three statements were = clarified by hum in the meeting, and were each able to be stated in a = single sentence. >>> =20 >>> I would ask the different actors in this discussion to please behave = in a courteous manner toward each other, and work together on this as = requested by the chairs at IETF 83. >>> _______________________________________________ >>> 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 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail-77-584255725 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

    On Apr 25, 2012, at 5:05 AM, Hemant = Singh (shemant) wrote:

    Fred,
     
    Appreciate the quick reply.  In MarkT's comments to Chris = that Chris did not follow the Chairs' recommendation, the statement is = not quite correct.  Additionally MarkT saying to the mailer = that  "He (Chris) decided to throw them in the trash" is not = correct either.  See the URL below where Chris clearly said, he has = guidance from the IETF and WG in the past to not include more than one = normative statement per requirement.  Thus Chris broke up the MarkT = recommendations and the break up has to stay.  Thus it would help if = Mark revisits Chris=92 text and fills in holes Mark thinks the text has = because we just cannot go back to Mark=92s original text that combines = multiple normative statements in one = requirement.

    I would like you to = please work with Mark, on the mailer, to accomplish = that. 

    <= div>

    I suspect that you = misunderstand Mark's text, which says that the text he suggested was = inadequate. 

    RFC 3704, resolving a = number of pages into a single sentence, recommends that if a packet uses = a stated source address and that source address was derived from a = stated upstream network, the packet should be directed to said upstream = network. The reason it would do so is that the upstream networks = presumably implement BCP 38, meaning that if it is directed to a = different upstream network it is likely to be dropped. 3704 goes on to = make suggestions regarding the implementation of exit routing. What Mark = is driving at is "implement exit routing; if one is given multiple = prefixes on different interfaces, physical or virtual, associate each = such prefix with its source interface in routing for the purposes of = source-address directed exit routing."

    Explanations and = dialog such as this are the reason I am asking you to TALK WITH MARK = about issues you see rather than talking with the chairs or simply = presuming that the working group outcome in Paris is brain-dead. The = outcome was, as near as I could tell, very sensible to the = operators.

    Another example for tighter text is related to 6RD-4.  = Why does 6RD-4 only say =93during an incremental migration period from 6rd to native = IPv6.=94    The SP could encounter a problem moving from 6rd to native IPv6 = and may want to revert back to 6rd.  Thus the 6RD-4 bullet should = cater to any migration from 6rd to native IPv6 or vice = versa.
     
    Further, when the CPE has different prefixes being used by = native IPV6 and 6rd, a host behind the CPE router has concurrent IPv6 = addresses being used (one IPv6 address from native IPv6 and another from = the 6rd prefix).  So what source-address does the host pick to send = a packet to a destination that is totally disjoint with the two prefixes = assigned to the CPE router?  Let=92s say the host picked a source = address from the 6rd prefix, then the CPE router ships the packet out = the 6rd tunnel instead of the higher preferred native IPv6 = network.  So how is the native IPv6 preference enforced by the CPE = router?  
     
    We also do not have consensus with the =93MUST=94 in = 6RD-4.  Current consensus is mostly towards changing the MUST to a = SHOULD.  I = also do not see any SP clamoring for 6rd sunsetting.  One SP in = France or France that has roughly million 6rd customers does not impress = me.  I am a person who gets impressed with 200 million customers = which is roughly what the cable broadband industry is deploying native = IPv6 for.  
     
    Hemant
     
     
    -----Original Message-----
    Sent: Tuesday, April 24, 2012 5:33 = PM
    Subject: Re: [v6ops] 6rd sunsetting requirements for = 6204-bis
     
    We discussed this at IETF 83, and you will find it in the = minutes when they come out. Mark and Ole asked for two things = (statements regarding 6rd and ds-lite), and the working group agreed to = one of them. We are not discussing a "boiling of the ocean", nor are we = discussing an infinite succession of new requirements. We are discussing = getting three no-brainer-class statements into the draft in a manner = that the discussants all recognize and agree to. The three statements = were clarified by hum in the meeting, and were each able to be stated in = a single sentence.
     
    I would ask the different actors in this discussion to please = behave in a courteous manner toward each other, and work together on = this as requested by the chairs at IETF 83.
    v6ops mailing = list

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

    = --Apple-Mail-77-584255725-- From wbeebee@cisco.com Wed Apr 25 10:57:31 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84BA221F884E for ; Wed, 25 Apr 2012 10:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.532 X-Spam-Level: X-Spam-Status: No, score=-8.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 ouOJ1lbgmCld for ; Wed, 25 Apr 2012 10:57:30 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id B5E8421F884F for ; Wed, 25 Apr 2012 10:57:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1232; q=dns/txt; s=iport; t=1335376650; x=1336586250; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=1SA3ODXYfdrVQvbX8nelj0k9U1RIZoTDyeEIOXG3/5I=; b=eR4T5f9cumBRkTc6aZOd8IcRDB94ZGL5+Gk7M8aiHYWXM3kldC72YBDA k1mCr7XlkEfUklUUxW+6aRnafODGto/+9Yi4Iu80hxLIU5xjXAfx1ghkz rDhj3MXvAWngrWSh3P6cQN35dBQKq222f9fQ/6hXh3Q6UfAsM4JL0tcrH 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmcHAFE6mE+tJXG//2dsb2JhbABFiiunIAKBB4IJAQEBAwESAScCAUENAQiBHQEBBAE0h2gFm0mgI5BgBJV7jlUngUKDBQ X-IronPort-AV: E=Sophos;i="4.75,481,1330905600"; d="scan'208";a="74793075" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-9.cisco.com with ESMTP; 25 Apr 2012 17:57:30 +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 q3PHvUWv027978; Wed, 25 Apr 2012 17:57:30 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); Wed, 25 Apr 2012 12:57:30 -0500 Received: from 161.44.175.143 ([161.44.175.143]) by XMB-RCD-201.cisco.com ([72.163.62.208]) with Microsoft Exchange Server HTTP-DAV ; Wed, 25 Apr 2012 17:57:29 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Wed, 25 Apr 2012 13:57:22 -0400 From: Wes Beebee To: Mark Townsley , IPv6 Operations Message-ID: Thread-Topic: [v6ops] 6rd sunsetting requirements for 6204-bis Thread-Index: Ac0jDN0fzrcavtbxM0qUw3TfZ40d3g== In-Reply-To: <379ECFD4-C696-4B86-9DCA-75B0887C4370@townsley.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 25 Apr 2012 17:57:30.0160 (UTC) FILETIME=[E1FC4B00:01CD230C] Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 17:57:31 -0000 > Whittled down to one sentence each, here are three requirements necessary in > order to support incremental migration from 6rd to native IPv6: > > > 6RD-4: A CE router MUST allow 6rd virtual and IPv6 native WAN interfaces to be > active simultaneously. > > 6RD-5: Each packet sent on a 6rd or native WAN interface MUST be directed such > that its source IP address is derived from the delegated prefix associated > with the upstream network the WAN interface is connected to [section 4.3 of > BCP 84, RFC 3704]. > > 6RD-6: The CE router MUST allow identical or overlapping delegated prefixes > for each WAN interface with a preference for native IPv6 in the event > forwarding rules would have otherwise directed a packet to be sent equally via > 6rd or native IPv6. I see no problem with replacing the existing 6RD requirements in 6204bis with this text. Note that this text is sufficiently abstracted to the point where my previous suggested implementation of 6rd/native co-existance AND Mark's suggested implementation can both be accomodated by this text - so that's proof enough that it gives implementers enough "wiggle room" to figure out the best way of interpreting these bullets. - Wes From mark@townsley.net Wed Apr 25 11:17:45 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB1321F8871 for ; Wed, 25 Apr 2012 11:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=-0.618, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wIXICpXiT-Ij for ; Wed, 25 Apr 2012 11:17:44 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id B951A21F8623 for ; Wed, 25 Apr 2012 11:17:41 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so255838wgb.13 for ; Wed, 25 Apr 2012 11:17:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=IlokRDrHLlp9eUThC5CeK7SBkI/SY5nIirS3pO8cVhU=; b=AxymIzNSj6gFTM/sqhdWuvLrlqdo9vgxHJIZ7KfwQsGv1lxQP8JP4yrr/wh+/SBmMt izH0J9qrUMr2iZSV3/HqvWaxP1PItHFhw7rrV3YOTdWGFK4AeAzAL+0UcUGZqqU1HUue kppH26XcjjMNn/ktMbniyCk3ROlyKUBlNacE1HUSIxubKHCnJpzGYzAHTNFOWcI68Ld+ 9Uh1Q/V/5l9nPEgxOOtJy03m408eKPHPc6iKCSPsBiwiyOQ4Ympfnll0aVMOqRyustIb tMgYVs5Qdxp7qpFs/5dqY+ICgEpwVWFG6KDKlKVjZZvqGWnAWRifIVo9XcWlil8IfJno 93pQ== Received: by 10.180.102.100 with SMTP id fn4mr9073706wib.1.1335377860801; Wed, 25 Apr 2012 11:17:40 -0700 (PDT) Received: from ams-townsley-8912.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id b3sm38867240wib.4.2012.04.25.11.17.24 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 Apr 2012 11:17:29 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_152DF509-04AB-4DE4-A295-A78FFD26EAEE" From: Mark Townsley In-Reply-To: <504FAF77-A618-4E89-86ED-727FD0FEF473@laposte.net> Date: Wed, 25 Apr 2012 20:17:22 +0200 Message-Id: References: <5B6B2B64C9FE2A489045EEEADDAFF2C30483722C@XMB-RCD-109.cisco.com><4F95A3D9.1010100@viagenie.ca><5B6B2B64C9FE2A489045EEEADDAFF2C304837261@XMB-RCD-109.cisco.com><4F95ABA0.8090601@viagenie.ca><5B6B2B64C9FE2A489045EEEADDAFF2C304837272@XMB-RCD-109.cisco.com><5B6B2B64C9FE2A489045EEEADDAFF2C30483747A@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3048378BB@XMB-RCD-109.cisco.com> <42D0E71D-8599-44C6-91D4-B059A276EB6A@cisco.com> <379ECFD4-C696-4B86-9DCA-75B0887C4370@townsley.net> <504FAF77-A618-4E89-86ED-727FD0FEF473@laposte.net> To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQmTOXuiHm6VELUrujVAv5axOPzcnchlkuR53nKqAR/+4MSnvFP+mB+GLraO7nVm+e1V1NR1 Cc: IPv6 Operations Subject: Re: [v6ops] 6rd (and 4rd) sunsetting requirements for 6204-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 18:17:45 -0000 --Apple-Mail=_152DF509-04AB-4DE4-A295-A78FFD26EAEE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Apr 25, 2012, at 7:09 PM, R=E9mi Despr=E9s wrote: > Mark, >=20 > While it is important that 6204bis includes 6rd, and while it is also = important to specify a 6rd sunsetting plan (good that you took the = initiative), I don't think it is right to include 6RD-4 to 6RD-6 at this = stage. >=20 > Reasons: > - Proof that no sunsetting solution is possible without these = requirements hasn't been given. > - I even think that, in a node supporting both IPv6 via IPv4 (6rd) and = IPv4 via IPv6 with public IPv4 addresses (MAP or 4rd), the IPv4 and IPv4 = and IPv6 routers can each see only one interface. (The fact that it uses = link layer interfaces natively or with some tunneling can AFAIK be kept = invisible to the router.) >=20 > Until a complete solution is described, doubt remains, but freezing = now the idea that this would be impossible isn't needed. Renaming the thread as this is taking a direction towards inclusion of = 4rd as well as 6rd. Remi - we agree in that I absolutely do think that 6204-bis has stepped = in the wrong direction by recommending DS-Lite without considering the = stateless alternatives as well as how to handle deployment alongside = native IPv4 in a consistent and predictable manner. I tried, and failed, = to sway the WG here though. The idea of a note saying that this is = "still as of yet undefined" I think would be quite appropriate in this = space. I would definitely support that, but the WG seems to not be open = to much change at all right now. Regarding 6rd and native IPv6, the = solution space is far more straightforward in terms of their coexistence = as well as the fact that 6rd is clearly dominant in terms of transition = solution deployment today. It's a big win to go ahead and get this = defined now, and the idea that we don't understand it well enough after = nearly 5 years of deployed 6rd, would seem a rather weak statement.=20 Referring back to Fred's email, the chairs have decided to take the = three requirements that outline how 6rd and and native IPv6 can coexist = in a way that allows both to be deployed at the same time, while giving = proper preference to native vs. 6rd when the routing decision would = otherwise have found them equal. Let's please focus on whether or not = the requirements are worded properly for that case, without inclusion of = 4rd, MAP-T, MAP-E, MAP-U, Stateless DS-Lite, SD-NAT, CGN, DS-Lite with = Global IPv4 addresses, 464xlat, or any of the other IPv4 delivery = options. 6rd is quietly enjoying quite a bit of success here in terms of = getting users connected to the IPv6 internet, trying to couple it with = any or all of the v4-exit alternatives has clearly shown the ability to = be a considerable distraction. - Mark > Suggestion: keep 6RD-1 to 6RD-4, replace the others by a note warning = that a specification needs to be added to handle 6RD sunsetting. > =20 >=20 > Regards, > RD >=20 >=20 > =20 >=20 >=20 > Le 2012-04-25 =E0 12:10, Mark Townsley a =E9crit : >=20 >>=20 >> Whittled down to one sentence each, here are three requirements = necessary in order to support incremental migration from 6rd to native = IPv6:=20 >>=20 >>=20 >> 6RD-4: A CE router MUST allow 6rd virtual and IPv6 native WAN = interfaces to be active simultaneously.=20 >>=20 >> 6RD-5: Each packet sent on a 6rd or native WAN interface MUST be = directed such that its source IP address is derived from the delegated = prefix associated with the upstream network the WAN interface is = connected to [section 4.3 of BCP 84, RFC 3704]. >>=20 >> 6RD-6: The CE router MUST allow identical or overlapping delegated = prefixes for each WAN interface with a preference for native IPv6 in the = event forwarding rules would have otherwise directed a packet to be sent = equally via 6rd or native IPv6. >>=20 >>=20 >> Summary: The first requirement says 6rd and native must coexist, the = second ensures that packets are directed such that they are not dropped = by the upstream network, and the third ensures native is chosen over 6rd = in the event the paths are otherwise equal.=20 >>=20 >> - Mark >>=20 >>=20 >> On Apr 25, 2012, at 5:23 AM, Fred Baker wrote: >>=20 >>>=20 >>> On Apr 25, 2012, at 5:05 AM, Hemant Singh (shemant) wrote: >>>=20 >>>> Fred, >>>> =20 >>>> Appreciate the quick reply. In MarkT's comments to Chris that = Chris did not follow the Chairs' recommendation, the statement is not = quite correct. Additionally MarkT saying to the mailer that "He = (Chris) decided to throw them in the trash" is not correct either. See = the URL below where Chris clearly said, he has guidance from the IETF = and WG in the past to not include more than one normative statement per = requirement. Thus Chris broke up the MarkT recommendations and the = break up has to stay. Thus it would help if Mark revisits Chris=92 text = and fills in holes Mark thinks the text has because we just cannot go = back to Mark=92s original text that combines multiple normative = statements in one requirement. >>>=20 >>> I would like you to please work with Mark, on the mailer, to = accomplish that.=20 >>>=20 >>>> http://www.ietf.org/mail-archive/web/v6ops/current/msg12705.html >>>> Moving on, the requirements provided by MarkT could use tighter = text. For example here is a portion of text provided to us to add. >>>> =20 >>>> "6RD-5: The CE router MUST associate delegated prefixes with the = WAN >>>> interface(s)=94 >>>> =20 >>>> The CPE WAN interface can be unnumbered with only an IPv6 = link-local address and thus the CPE WAN does not have a global IPv6 = address. In such an unnumbered model, the CPE uses an address from the = PD on a virtual network interface to source packets out the WAN such as = ICMPv6 errors. I am away from work tomorrow but we can certainly try = and close any text two days from now including any WebEx phone call = between Mark and us authors of rfc6204bis.=20 >>>=20 >>> I suspect that you misunderstand Mark's text, which says that the = text he suggested was inadequate.=20 >>>=20 >>> RFC 3704, resolving a number of pages into a single sentence, = recommends that if a packet uses a stated source address and that source = address was derived from a stated upstream network, the packet should be = directed to said upstream network. The reason it would do so is that the = upstream networks presumably implement BCP 38, meaning that if it is = directed to a different upstream network it is likely to be dropped. = 3704 goes on to make suggestions regarding the implementation of exit = routing. What Mark is driving at is "implement exit routing; if one is = given multiple prefixes on different interfaces, physical or virtual, = associate each such prefix with its source interface in routing for the = purposes of source-address directed exit routing." >>>=20 >>> Explanations and dialog such as this are the reason I am asking you = to TALK WITH MARK about issues you see rather than talking with the = chairs or simply presuming that the working group outcome in Paris is = brain-dead. The outcome was, as near as I could tell, very sensible to = the operators. >>>=20 >>>> Another example for tighter text is related to 6RD-4. Why does = 6RD-4 only say =93during an incremental migration period from 6rd to = native IPv6.=94 The SP could encounter a problem moving from 6rd to = native IPv6 and may want to revert back to 6rd. Thus the 6RD-4 bullet = should cater to any migration from 6rd to native IPv6 or vice versa. >>>> =20 >>>> Further, when the CPE has different prefixes being used by native = IPV6 and 6rd, a host behind the CPE router has concurrent IPv6 addresses = being used (one IPv6 address from native IPv6 and another from the 6rd = prefix). So what source-address does the host pick to send a packet to = a destination that is totally disjoint with the two prefixes assigned to = the CPE router? Let=92s say the host picked a source address from the = 6rd prefix, then the CPE router ships the packet out the 6rd tunnel = instead of the higher preferred native IPv6 network. So how is the = native IPv6 preference enforced by the CPE router? =20 >>>> =20 >>>> We also do not have consensus with the =93MUST=94 in 6RD-4. = Current consensus is mostly towards changing the MUST to a SHOULD. I = also do not see any SP clamoring for 6rd sunsetting. One SP in France = or France that has roughly million 6rd customers does not impress me. I = am a person who gets impressed with 200 million customers which is = roughly what the cable broadband industry is deploying native IPv6 for. =20= >>>> =20 >>>> Hemant >>>> =20 >>>> =20 >>>> -----Original Message----- >>>> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On = Behalf Of Fred Baker (fred) >>>> Sent: Tuesday, April 24, 2012 5:33 PM >>>> To: IPv6 Operations >>>> Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis >>>> =20 >>>> We discussed this at IETF 83, and you will find it in the minutes = when they come out. Mark and Ole asked for two things (statements = regarding 6rd and ds-lite), and the working group agreed to one of them. = We are not discussing a "boiling of the ocean", nor are we discussing an = infinite succession of new requirements. We are discussing getting three = no-brainer-class statements into the draft in a manner that the = discussants all recognize and agree to. The three statements were = clarified by hum in the meeting, and were each able to be stated in a = single sentence. >>>> =20 >>>> I would ask the different actors in this discussion to please = behave in a courteous manner toward each other, and work together on = this as requested by the chairs at IETF 83. >>>> _______________________________________________ >>>> 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 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 --Apple-Mail=_152DF509-04AB-4DE4-A295-A78FFD26EAEE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

    Referring back to Fred's = email, the chairs have decided to take the three requirements that = outline how 6rd and and native IPv6 can coexist in a way that allows = both to be deployed at the same time, while giving proper preference to = native vs. 6rd when the routing decision would otherwise have found them = equal. Let's please focus on whether or not the requirements are worded = properly for that case, without inclusion of 4rd, MAP-T, MAP-E, MAP-U, = Stateless DS-Lite, SD-NAT, CGN, DS-Lite with Global IPv4 addresses, = 464xlat, or any of the other IPv4 delivery options. 6rd is quietly = enjoying quite a bit of success here in terms of getting users connected = to the IPv6 internet, trying to couple it with any or all of the v4-exit = alternatives has clearly shown the ability to be a considerable = distraction.

    - = Mark


    Suggestion: keep 6RD-1 to = 6RD-4, replace the others by a note warning that a specification needs = to be added to handle 6RD = sunsetting.
      

    Regards,
    =
    RD


     


    Le 2012-04-25 =E0 12:10, Mark Townsley a =E9crit = :


    On Apr 25, 2012, at 5:05 AM, Hemant = Singh (shemant) wrote:

    Fred,
     
    Appreciate the quick reply.  In MarkT's comments to Chris = that Chris did not follow the Chairs' recommendation, the statement is = not quite correct.  Additionally MarkT saying to the mailer = that  "He (Chris) decided to throw them in the trash" is not = correct either.  See the URL below where Chris clearly said, he has = guidance from the IETF and WG in the past to not include more than one = normative statement per requirement.  Thus Chris broke up the MarkT = recommendations and the break up has to stay.  Thus it would help if = Mark revisits Chris=92 text and fills in holes Mark thinks the text has = because we just cannot go back to Mark=92s original text that combines = multiple normative statements in one = requirement.

    I would like you to = please work with Mark, on the mailer, to accomplish = that. 

    <= div>

    I suspect that you = misunderstand Mark's text, which says that the text he suggested was = inadequate. 

    RFC 3704, resolving a = number of pages into a single sentence, recommends that if a packet uses = a stated source address and that source address was derived from a = stated upstream network, the packet should be directed to said upstream = network. The reason it would do so is that the upstream networks = presumably implement BCP 38, meaning that if it is directed to a = different upstream network it is likely to be dropped. 3704 goes on to = make suggestions regarding the implementation of exit routing. What Mark = is driving at is "implement exit routing; if one is given multiple = prefixes on different interfaces, physical or virtual, associate each = such prefix with its source interface in routing for the purposes of = source-address directed exit routing."

    Explanations and = dialog such as this are the reason I am asking you to TALK WITH MARK = about issues you see rather than talking with the chairs or simply = presuming that the working group outcome in Paris is brain-dead. The = outcome was, as near as I could tell, very sensible to the = operators.

    Another example for tighter text is related to 6RD-4.  = Why does 6RD-4 only say =93during an incremental migration period from 6rd to native = IPv6.=94    The SP could encounter a problem moving from 6rd to native IPv6 = and may want to revert back to 6rd.  Thus the 6RD-4 bullet should = cater to any migration from 6rd to native IPv6 or vice = versa.
     
    Further, when the CPE has different prefixes being used by = native IPV6 and 6rd, a host behind the CPE router has concurrent IPv6 = addresses being used (one IPv6 address from native IPv6 and another from = the 6rd prefix).  So what source-address does the host pick to send = a packet to a destination that is totally disjoint with the two prefixes = assigned to the CPE router?  Let=92s say the host picked a source = address from the 6rd prefix, then the CPE router ships the packet out = the 6rd tunnel instead of the higher preferred native IPv6 = network.  So how is the native IPv6 preference enforced by the CPE = router?  
     
    We also do not have consensus with the =93MUST=94 in = 6RD-4.  Current consensus is mostly towards changing the MUST to a = SHOULD.  I = also do not see any SP clamoring for 6rd sunsetting.  One SP in = France or France that has roughly million 6rd customers does not impress = me.  I am a person who gets impressed with 200 million customers = which is roughly what the cable broadband industry is deploying native = IPv6 for.  
     
    Hemant
     
     
    -----Original Message-----
    Sent: Tuesday, April 24, 2012 5:33 = PM
    Subject: Re: [v6ops] 6rd sunsetting requirements for = 6204-bis
     
    We discussed this at IETF 83, and you will find it in the = minutes when they come out. Mark and Ole asked for two things = (statements regarding 6rd and ds-lite), and the working group agreed to = one of them. We are not discussing a "boiling of the ocean", nor are we = discussing an infinite succession of new requirements. We are discussing = getting three no-brainer-class statements into the draft in a manner = that the discussants all recognize and agree to. The three statements = were clarified by hum in the meeting, and were each able to be stated in = a single sentence.
     
    I would ask the different actors in this discussion to please = behave in a courteous manner toward each other, and work together on = this as requested by the chairs at IETF 83.
    v6ops mailing = list

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