From Branimir.Rajtar@t.ht.hr Mon Jul 1 00:59:35 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A33C721F9A63 for ; Mon, 1 Jul 2013 00:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FydFBHYUpxdw for ; Mon, 1 Jul 2013 00:59:31 -0700 (PDT) Received: from mx01.t.ht.hr (mx01.t.ht.hr [195.29.161.88]) by ietfa.amsl.com (Postfix) with SMTP id CEC0D21F9A47 for ; Mon, 1 Jul 2013 00:59:30 -0700 (PDT) Received: from (unknown [172.17.66.76]) by mx01.t.ht.hr with smtp id 3bd4_0d36_25ed2456_e224_11e2_85f6_00221951415f; Mon, 01 Jul 2013 09:59:25 +0200 Received: from S2010EXCHCA1.ad.local ([10.240.132.138]) by mailgw.ad.local with Microsoft SMTPSVC(6.0.3790.4675); Mon, 1 Jul 2013 09:59:25 +0200 Received: from S2010EXCH1.ad.local ([fe80::2d7b:39dd:876e:f277]) by S2010EXCHCA1.ad.local ([::1]) with mapi id 14.03.0123.003; Mon, 1 Jul 2013 09:59:25 +0200 From: Branimir Rajtar To: "behave@ietf.org" Thread-Topic: [BEHAVE] v6 content for IPv4-only clients Thread-Index: Ac52MOccILvZa1PcSlqudYX1D1MV8g== Date: Mon, 1 Jul 2013 07:59:25 +0000 Message-ID: <786F13AA11E69F4DB2CCA23F7400C2FB0146E019@S2010EXCH1.ad.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.10.22] Content-Type: multipart/alternative; boundary="_000_786F13AA11E69F4DB2CCA23F7400C2FB0146E019S2010EXCH1adloc_" MIME-Version: 1.0 X-OriginalArrivalTime: 01 Jul 2013 07:59:25.0741 (UTC) FILETIME=[E7A87DD0:01CE7630] Subject: [BEHAVE] v6 content for IPv4-only clients X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 07:59:35 -0000 --_000_786F13AA11E69F4DB2CCA23F7400C2FB0146E019S2010EXCH1adloc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 SGVsbG8gZXZlcnlib2R5LAoKSnVzdCB3YW50ZWQgdG8gbGV0IHlvdSBrbm93IG15IGNvbGxlYWd1 ZXMgYW5kIG1lIGp1c3QgcG9zdGVkIGEgbmV3IGRyYWZ0IGRlc2NyaWJpbmcgaG93IElQdjQtb25s eSBjbGllbnRzIGNhbiBhY2Nlc3MgY29udGVudCBhdmFpbGFibGUgb25seSBvbiBJUHY2LiBQbGVh c2UgdGFrZSBhIGxvb2sgYW5kIGNvbW1lbnQ6Cmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtcmZ2bGItYmVoYXZlLXY2LWNvbnRlbnQtZm9yLXY0LWNsaWVudHMvCgpLaW5kIFJl Z2FyZHMsCkJyYW5pbWlyCgoKCjxIVE1MPjxQPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9Izk5OTk5 OSBzaXplPTE+DQoNCklaSkFWQSBPIE9EUklDQU5KVSBPREdPVk9STk9TVEk6IFNhZHLFvmFqIG92 ZSBwb3J1a2UgaSBldmVudHVhbG5vIHByaWxvxb5lbmloIGRhdG90ZWthIGplIHBvdmplcmxqaXYg aSBuYW1pamVuamVuIGplIHNhbW8gb3NvYmFtYSBpbGkgc3ViamVrdGltYSBrb2ppIHN1IG5hdmVk ZW5pIHUgYWRyZXNpLiBVa29saWtvIHN0ZSBwcmltaWxpIG92dSBwb3J1a3UgZ3JlxaFrb20sIG1v bGltbyBWYXMsIG9iYXZpamVzdGl0ZSBwb8WhaWxqYXRlbGphLCBhIHBvcnVrdSBpIHN2ZSBuamVu ZSBwcml2aXRrZSBvZG1haCwgYmV6IMSNaXRhbmphLCB0cmFqbm8gdWtsb25pdGUgcyByYcSNdW5h bGEuIEJpbG8ga2Frdm8gcHJlbm/FoWVuamUsIGtvcGlyYW5qZSBpbGkgZGlzdHJpYnVjaWphIGlu Zm9ybWFjaWphIHNhZHLFvmFuaWggdSBwb3J1Y2kgdHJlxIdpbSBvc29iYW1hIGplIHphYnJhbmpl bm8gaSBtb8W+ZSBiaXRpIHpha29uc2tpIGthxb5uaml2by4gU2FkcsW+YWosIHN0YXZvdmkgaSBt acWhbGplbmphIGl6bmVzZW5pIHUgcG9ydWNpIHN1IGF1dG9yb3ZpIGkgbmUgcHJlZHN0YXZsamFq dSBudcW+bm8gc3Rhdm92ZSBIVCAtIEhydmF0c2tpaCB0ZWxla29tdW5pa2FjaWphIGQuZC4gSFQg bmUgcHJpaHZhxIdhIG5pa2FrdnUgb2Rnb3Zvcm5vc3QgemEgZXZlbnR1YWxudSDFoXRldHUgbmFz dGFsdSBwcmltaXRrb20gb3ZlIHBvcnVrZSBpIHByaWxvZ2Egc2FkcsW+YW5paCB1IHBvcnVjaS4N Cg0KPC9GT05UPjwvUD48UD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSM5OTk5OTkgc2l6ZT0xPg0K DQogRElTQ0xBSU1FUjpUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhcyB3ZWxsIGFzIGFueSBm aWxlcyBhdHRhY2hlZCB0byBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkg Zm9yIGluZGl2aWR1YWxzIG9yIGVudGl0aWVzIHdoaWNoIHRoZXkgYXJlIGFkZHJlc3NlZCB0by4g SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBtZXNzYWdlIGluIGVycm9yLCBwbGVhc2Ug bm90aWZ5IHRoZSBzZW5kZXIgYW5kIHBlcm1hbmVudGx5IHJlbW92ZSB0aGUgbWVzc2FnZSBhbmQg YWxsIGF0dGFjaGVkIGZpbGVzIGZyb20gdGhlIGNvbXB1dGVyLiBBbnkgZGlzY2xvc3VyZSwgY29w eWluZyBvciBkaXN0cmlidXRpb24gb2YgYWxsIG9yIGEgcGFydCBvZiBpbmZvcm1hdGlvbiBjb250 YWluZWQgaGVyZWluIHRvIG9yIGJ5IHRoaXJkIHBhcnRpZXMgaXMgcHJvaGliaXRlZCBhbmQgbWF5 IGJlIHVubGF3ZnVsLiBQbGVhc2Ugbm90ZSB0aGF0IGFueSB2aWV3cyBvciBvcGluaW9ucyBwcmVz ZW50ZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSBzb2xlbHkgdGhvc2Ugb2YgdGhlIGF1dGhvciBhbmQg ZG8gbm90IG5lY2Vzc2FyaWx5IHJlcHJlc2VudCB0aGUgdmlld3MgYW5kIG9waW5pb25zIG9mIENy b2F0aWFuIFRlbGVjb20gSW5jLiBDcm9hdGlhbiBUZWxlY29tIEluYy4gYWNjZXB0cyBubyBsaWFi aWxpdHkgZm9yIGFueSBwb3RlbnRpYWwgZGFtYWdlIGNhdXNlZCBieSB0aGlzIG1lc3NhZ2UgYW5k IGZpbGVzIGF0dGFjaGVkIHRvIGl0Lg0KDQo8L0ZPTlQ+PC9QPjwvSFRNTD4K --_000_786F13AA11E69F4DB2CCA23F7400C2FB0146E019S2010EXCH1adloc_ Content-Type: text/HTML; charset="utf-8" Content-Transfer-Encoding: base64 X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+CjxoZWFkPgo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNv bnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11cy1hc2NpaSI+CjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPgo8c3R5bGU+ PCEtLQovKiBGb250IERlZmluaXRpb25zICovCkBmb250LWZhY2UKCXtmb250LWZhbWlseToiQ2Ft YnJpYSBNYXRoIjsKCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQpAZm9udC1mYWNlCgl7 Zm9udC1mYW1pbHk6Q2FsaWJyaTsKCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30KLyog U3R5bGUgRGVmaW5pdGlvbnMgKi8KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05v cm1hbAoJe21hcmdpbjowY207CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7Cglmb250LXNpemU6MTEu MHB0OwoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9CmE6bGluaywgc3Bhbi5N c29IeXBlcmxpbmsKCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7Cgljb2xvcjpibHVlOwoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dl ZAoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsKCWNvbG9yOnB1cnBsZTsKCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQpzcGFuLkVtYWlsU3R5bGUxNwoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LWNvbXBvc2U7Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOwoJY29sb3I6d2lu ZG93dGV4dDt9Ci5Nc29DaHBEZWZhdWx0Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQpA cGFnZSBXb3JkU2VjdGlvbjEKCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsKCW1hcmdpbjo3MC44NXB0 IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30KZGl2LldvcmRTZWN0aW9uMQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4KPC9oZWFkPgo8Ym9keSBsYW5nPSJIUiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj5IZWxsbyBldmVyeWJvZHksPG86cD48L286cD48L3NwYW4+PC9wPgo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SnVzdCB3YW50ZWQg dG8gbGV0IHlvdSBrbm93IG15IGNvbGxlYWd1ZXMgYW5kIG1lIGp1c3QgcG9zdGVkIGEgbmV3IGRy YWZ0IGRlc2NyaWJpbmcgaG93IElQdjQtb25seSBjbGllbnRzIGNhbiBhY2Nlc3MgY29udGVudCBh dmFpbGFibGUgb25seSBvbiBJUHY2LiBQbGVhc2UgdGFrZSBhIGxvb2sgYW5kIGNvbW1lbnQ6PG86 cD48L286cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+PGEgaHJlZj0iaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1yZnZsYi1i ZWhhdmUtdjYtY29udGVudC1mb3ItdjQtY2xpZW50cy8iPmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtcmZ2bGItYmVoYXZlLXY2LWNvbnRlbnQtZm9yLXY0LWNsaWVudHMvPC9h PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPktpbmQgUmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+Cjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5CcmFuaW1pcjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iREUiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4KPC9kaXY+Cgo8RElWPjxQPjxIUj4KPFA+PEZPTlQgY29sb3I9 Izk5OTk5OSBzaXplPTEgZmFjZT1BcmlhbD5JWkpBVkEgTyBPRFJJQ0FOSlUgT0RHT1ZPUk5PU1RJ OiBTYWRyJiMzODI7YWogb3ZlIHBvcnVrZSBpIGV2ZW50dWFsbm8gcHJpbG8mIzM4MjtlbmloIGRh dG90ZWthIGplIHBvdmplcmxqaXYgaSBuYW1pamVuamVuIGplIHNhbW8gb3NvYmFtYSBpbGkgc3Vi amVrdGltYSBrb2ppIHN1IG5hdmVkZW5pIHUgYWRyZXNpLiBVa29saWtvIHN0ZSBwcmltaWxpIG92 dSBwb3J1a3UgZ3JlJiMzNTM7a29tLCBtb2xpbW8gVmFzLCBvYmF2aWplc3RpdGUgcG8mIzM1Mztp bGphdGVsamEsIGEgcG9ydWt1IGkgc3ZlIG5qZW5lIHByaXZpdGtlIG9kbWFoLCBiZXogJiMyNjk7 aXRhbmphLCB0cmFqbm8gdWtsb25pdGUgcyByYSYjMjY5O3VuYWxhLiBCaWxvIGtha3ZvIHByZW5v JiMzNTM7ZW5qZSwga29waXJhbmplIGlsaSBkaXN0cmlidWNpamEgaW5mb3JtYWNpamEgc2FkciYj MzgyO2FuaWggdSBwb3J1Y2kgdHJlJiMyNjM7aW0gb3NvYmFtYSBqZSB6YWJyYW5qZW5vIGkgbW8m IzM4MjtlIGJpdGkgemFrb25za2kga2EmIzM4Mjtuaml2by4gU2FkciYjMzgyO2FqLCBzdGF2b3Zp IGkgbWkmIzM1MztsamVuamEgaXpuZXNlbmkgdSBwb3J1Y2kgc3UgYXV0b3JvdmkgaSBuZSBwcmVk c3RhdmxqYWp1IG51JiMzODI7bm8gc3Rhdm92ZSBIVCAtIEhydmF0c2tvZyBUZWxla29tYSBkLmQu IEhUIG5lIHByaWh2YSYjMjYzO2EgbmlrYWt2dSBvZGdvdm9ybm9zdCB6YSBldmVudHVhbG51ICYj MzUzO3RldHUgbmFzdGFsdSBwcmltaXRrb20gb3ZlIHBvcnVrZSBpIHByaWxvZ2Egc2FkciYjMzgy O2FuaWggdSBwb3J1Y2kuIDwvRk9OVD48L1A+DQo8UD48Rk9OVCBjb2xvcj0jOTk5OTk5IHNpemU9 MSBmYWNlPUFyaWFsPkRJU0NMQUlNRVI6VGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYXMgd2Vs bCBhcyBhbnkgZmlsZXMgYXR0YWNoZWQgdG8gaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5k ZWQgc29sZWx5IGZvciBpbmRpdmlkdWFscyBvciBlbnRpdGllcyB3aGljaCB0aGV5IGFyZSBhZGRy ZXNzZWQgdG8uIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgbWVzc2FnZSBpbiBlcnJv ciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBwZXJtYW5lbnRseSByZW1vdmUgdGhlIG1l c3NhZ2UgYW5kIGFsbCBhdHRhY2hlZCBmaWxlcyBmcm9tIHRoZSBjb21wdXRlci4gQW55IGRpc2Ns b3N1cmUsIGNvcHlpbmcgb3IgZGlzdHJpYnV0aW9uIG9mIGFsbCBvciBhIHBhcnQgb2YgaW5mb3Jt YXRpb24gY29udGFpbmVkIGhlcmVpbiB0byBvciBieSB0aGlyZCBwYXJ0aWVzIGlzIHByb2hpYml0 ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gUGxlYXNlIG5vdGUgdGhhdCBhbnkgdmlld3Mgb3Igb3Bp bmlvbnMgcHJlc2VudGVkIGluIHRoaXMgbWVzc2FnZSBhcmUgc29sZWx5IHRob3NlIG9mIHRoZSBh dXRob3IgYW5kIGRvIG5vdCBuZWNlc3NhcmlseSByZXByZXNlbnQgdGhlIHZpZXdzIGFuZCBvcGlu aW9ucyBvZiBDcm9hdGlhbiBUZWxlY29tIEluYy4gQ3JvYXRpYW4gVGVsZWNvbSBJbmMuIGFjY2Vw dHMgbm8gbGlhYmlsaXR5IGZvciBhbnkgcG90ZW50aWFsIGRhbWFnZSBjYXVzZWQgYnkgdGhpcyBt ZXNzYWdlIGFuZCBmaWxlcyBhdHRhY2hlZCB0byBpdC4gPC9GT05UPjwvUD4KPC9QPjwvRElWPgo8 L2JvZHk+CjwvaHRtbD4K --_000_786F13AA11E69F4DB2CCA23F7400C2FB0146E019S2010EXCH1adloc_-- From dwing@cisco.com Mon Jul 1 10:07:13 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB97921F9B25 for ; Mon, 1 Jul 2013 10:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.229 X-Spam-Level: X-Spam-Status: No, score=-110.229 tagged_above=-999 required=5 tests=[AWL=0.370, 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 iu9AeItuqrXf for ; Mon, 1 Jul 2013 10:07:00 -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 4A20D21F9B17 for ; Mon, 1 Jul 2013 10:06:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16076; q=dns/txt; s=iport; t=1372698419; x=1373908019; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=baOSjkOc5fKC8EiNRNkWGI356LcXAqmEgTCHj6dPH+M=; b=gPy6WQzS8FV26TH/5bp3XV7DhB5SKf+DhIsidpIAJZOFuRC1ZfKQt4h3 nIeAOepN9nY10ua4ZyABWKWeoLzT5k/0LClJXffrbvAdDKOLsaJ/yYuxU xEmH1xwnBNAVNhAASQ5pgp+0DLh0a/dS/AovYJiFMN5NHCHKVrZVY1DCd Y=; X-IronPort-AV: E=Sophos;i="4.87,975,1363132800"; d="scan'208";a="82354545" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 01 Jul 2013 17:06:59 +0000 Received: from sjc-vpn2-667.cisco.com (sjc-vpn2-667.cisco.com [10.21.114.155]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r61H6vR8029021; Mon, 1 Jul 2013 17:06:57 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dan Wing In-Reply-To: Date: Mon, 1 Jul 2013 10:06:55 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <57AD5629-373C-4D2C-ACB4-6F0DD57D3D56@cisco.com> References: To: Senthil Sivakumar (ssenthil) X-Mailer: Apple Mail (2.1508) Cc: "behave@ietf.org" , Tom Taylor Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-syslog-nat-logging-01.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 17:07:13 -0000 On Jun 28, 2013, at 10:45 AM, Senthil Sivakumar (ssenthil) = wrote: > Sorry for the long delay in responding.. Please see inline. >=20 > On 5/20/13 9:56 PM, "Dan Wing (dwing)" wrote: >=20 >> Thanks for writing this document. >>=20 >> My personal review, not as chair, >>=20 >> Section 2.1 seems to be trying to distinguish between mechanisms that = are >> dynamic and those that are static. Static are DS-Lite with >> [I-D.tsou-behave-natx4-log-reduction] and [I-D.pcp-port-set], MAP-E, = and >> lightweight 4over6. Dynamic is dynamic. Then there is the = combination, >> which is popularly described in = draft-donley-behave-deterministic-cgn. I >> would suggest separate sections explaining these three things, and = more >> concisely. Also, Section 2.1 is titled "NAT Logging Requirements For >> Different Transition Methods" and has 3 paragraphs describing MAP-E, >> which does not do network address translation in the ISP's network; a >> different title for the section that discusses MAP-E seems useful. >> Afterall, with MAP-E the NAT function occurs in the customer premise = NAT, >> which is not going to generate logging messages. It seems Section 2 >> might be something we would want common between the SYSLOG and IPFIX >> documents, perhaps? >=20 > Do you think those would have to be repeated or one document just = refers > to the other. I prefer the later approach. Ok if it can be an informational reference. >=20 >>=20 >> I noticed the non-normative "Note:" regarding Gateway-Initiated = DS-Lite >> underneath Figure 1. Can that be moved to somewhere else so it is = more >> normative? (It looks like a centered ). Perhaps it = should be >> explained in Section 2.1, rather than here. >=20 > This is specific to syslog. So I am going to let the syslog authors > address this. >=20 >>=20 >> In Figure 1, can the user identifier be generalized a bit? There are >> lots of NATs which use interface identifiers (e.g., en0, en1, en2), = VLAN >> IDs, VRFs, to separate the inside addresses -- rather than using the >> fields shown here in Figure 1. This seems to have happened in = Section >> 3.1 (which shows VLAN ID and VRFs) but the table does not appear to = allow >> that sort of flexibility. >=20 > This is specific to syslog. So I am going to let the syslog authors > address this. >=20 >>=20 >>=20 >> Section 3.1, >> "NAT session creation and deletion events are recorded when a binding >> to a specific destination address and port is recorded in or deleted >> from the session database. See the discussion in Section 3 of >> [RFC6146]." >>=20 >> That does not align with the endpoint-independent mapping described = in >> Section 3 of RFC6146. That is, a 'creation' event does not occur = with >> every new destination address. >>=20 >> I found Section 3.1 really difficult to understand what is generated = for >> a TCP/UDP mapping, versus what is supposed to be generated for an = ICMP >> mapping. =20 >>=20 >> " o Destination IPv4 (for NAT44) or IPv6 (for NAT64) address >> (OPTIONAL);" >>=20 >> A NAT64 would have an IPv4 destination address. Note this is for >> *destination logging*, which needs its own discussion beyond just >> "(OPTIONAL)" and beyond the citation that RFC6888 recommends against >> destination logging. There are implementation issues with = destination >> logging (state creation in the logging device to avoid generating a = log >> event with every packet), and it deserves mentioning in a logging >> document that destination logging more than destroys the log = reduction >> benefit of bulk port assignment. >=20 > Agree, I will add a paragraph on the destination logging and its = effects. >=20 >>=20 >>=20 >> " o Post-NAT destination IPv4 address (OPTIONAL);" >>=20 >> Seems redundant with the preceding item. >>=20 >> "The pre-NAT value of destination >> address will differ from the post-NAT value only in a double-NAT >> situation. Hence in most cases even with destination logging the >> pre-NAT value will not be recorded." >>=20 >> I don't understand what that means. Please make it clearer in the >> document. This is the first and only time the term "double-NAT" = appears >> in the document, which might be part of my confusion. >=20 > Seems specific to syslog document. >=20 >>=20 >>=20 >> Section 3.4 says: "The same allocation applies to each protocol = supported >> by the NAT." -> but you really only mean UDP and TCP, even though the = NAT >> supports ICMP (which doesn't use ports) or even if it were to support >> SCTP (which does not expect NAPT devices to rewrite port numbers). = So, >> please say "The same ports are allocated for TCP and UDP." >>=20 >> Section 3.4, why are the starting and ending port numbers optional, = can >> this work? =20 >>=20 >> Section 3.4, the Port Range Size and Range Step are too complicated. = Are >=20 > I guess your words are truncated here. There has been some interest on > having non-contiguous ports. It has been established that this doesn=B9t= > provide any added security, but it isnt as complex as you think it is = to > implement. There are implementations that uses a range and step size. The problem is changes, and getting those changes communicated and = coordinated to the logging system and to the network devices that need = to know of the changes, such as CPE (if the CPE need to know the range = and steps). This is additional operational complexity, but I don't see = a way for protocols to make this work better. When a change occurs, = what happens to existing sessions that are not using the 'wrong' ports = (which aren't assigned)? This same problem exists if contiguous port = range is reduced (e.g., from 1000 ports to 200 ports), but it is more = complex with ports scattered across the port range. >=20 >>=20 >>=20 >> Section 3.4 needs to explain if the same single logging event will be >> generated when ports are deleted, or if they are consolidated. For >> example, let's say ports 100-200 are allocated to a subscriber and a >> logging event generated, then ports 200-250 are (later) allocated to = the >> same subscriber and a logging event generated. Will that second = logging >> event indicate ports 100-250? (I could see someone reasonably >> implementing that). Would two separate deletion log events be = generated, >> one deletion for 100-200, and another deletion for 201-250? Or would >> only one log deletion event be generated? All of these corner cases = need >> discussion with some rules for how this is expected to work. This = could >> perhaps be left to implementation decision, but if that is the = decision >> it should clearly say. >=20 > I think it is clearly an implementation choice. But I agree, we should > have some text explaining some possible options and leave it to the > implementation. >=20 >>=20 >> General comment for all of sections 3.5, 3.6, and 3.7: Can a SYSLOG >> message be generated *before* we hit a limit? It seems there is no >> highwater mark for any of those. I expect operators would prefer = knowing >> before hitting a limit and also when hitting a limit (because users = will >> notice the hard failure when a limit is hit). Thoughts? >=20 > Interesting thought. I have always thought that logging is more useful = in > case of post mortem, to understand what happened and when. And MIB is = used > as a proactive monitoring tool. We have added the threshold values in = the > new mib for the address and pool exhaustion, this would serve as an > alarm/trap.=20 >=20 >>=20 >> "3.5. NAT Address Exhaustion Event", is there expected to be = anything to >> prevent this event from being continually generated? Because, if the = NAT >> is running near its limit and hits it, it will likely have a port >> released, then one allocated (hitting the limit again), over and over >> again. Same question for Section 3.4 (port exhaustion). And, are = both >> events generated when the final port is allocated (seems like both = would >> be generated). =20 >=20 > These events should be rate limited. It shouldn=B9t be generated on a > per-packet basis. In our current implementation, we generate an event = when > we first hit the limit, and then either periodically, every n secs if > there are packets still getting dropped because of the lack of = resources > OR when some ports were released back into the pool and exhausted = again. I > am pretty sure there are other ways to implement this rate limiting = but I > think adding some text around this would be helpful to the = implementors. I > will do this in the ipfix document. Thanks. >=20 >>=20 >> Section 3.7, Quota exhausted -- for the (per-user) quota a citation = to >> REQ-11 of RFC6888 would be helpful. I found the paragraph describing >> which fields are mandatory for which sort of quota difficult to >> understand. I played around with a table (which did not help = clarity) >> and some alternative wording. But I couldn't improve the text much, >> because I don't really know what fields are best to send for the >> different sort of events. This feels very free-form and a cause of >> interoperability problems with the various ways a NAT or the SYSLOG >> parsing code would interpret the presence of certain fields. For >> example, does the lack of a subscriber-identifying address mean that = a >> non-subscriber-specific administrative limit was hit? It seems that = is >> the case, which is okay, but more explicit explanation could be = helpful. >> Or creating separate events like was done with 3.5 and 3.6 >>=20 >> =09 >> Section 5.2.1, "NTyp: NAT Type" where it mentions NAT44 it should = cite >> the canonical NAPT44 definition in RFC3022. For NAT64, probably want = to >> reference both stateful NAT64 (RFC6146) and stateless (RFC6145). >>=20 >> 5.2.5. PreS4: Pre-NAT IPv4 Source Address >>=20 >> PARAM-VALUE: part or all of an IPv4 address, represented in dotted >> decimal form. >>=20 >> Why provide only part of the IPv4 address? For on-the-wire = efficiency? >> If some of the address is omitted, is it the first NNN bits that are >> omitted, or the last NNN bits that are omitted. I would omit the = first >> NNN bits if all the internal addresses shared those same NNN bits = (e.g., >> all were 100.64/10, I could omit the first 10 bits). I would omit = the >> last NNN bits if assigning a /24 to a subscriber and I don't care = which >> of their devices caused the NAT event. >>=20 >> 5.2.6. PreS6: Pre-NAT IPv6 Source Address: "PARAM-VALUE: Part or = all >> of an IPv6 address, represented in the form specified by [ >> RFC5952]." >>=20 >> Same question -- the first part or the last part of the address? = Most >> subscribers are assigned a /64, so reporting the full 128 bit address = is >> awkward, I agree. But, similarly, most of an ISP's network will use = the >> same IPv6 prefix so reporting the first 8 or 24 bits is redundant. = The >> document needs to clarify. >>=20 >> And as this is string-encoded, what rules should be followed for = "::", as >> that has changed in the last couple of years and would be good to = cite. >=20 > All of the above three comments are specific to Syslog, hence = ignoring. >=20 >>=20 >> In IANA considerations a new IANA registry is created. This needs to >> additionally provide guidance for how that new registry can be = extended >> in teh future, and a few other things. RFC5226 has details. >=20 > IPFIX registry is already in place and is being used by people to add = new > fields. >=20 >>=20 >> Security considerations: >>=20 >> " When logs are being recorded for regulatory reasons, preservation = of >> their integrity and authentication of their origin is essential." >>=20 >> The accuracy and unambiguity of the information is important, as = well. >> To that point, the address compression has me concerned and address >> compression needs more text in the document, and may deserve calling = out >> explicitly in the security considerations section. Also worth = pointing >> out is the address ranges and "step range" (whatever that is) might = be >> changed while the NAT is operating -- which impacts almost everything >> reported to the SYSLOG server. Seems useful to add NAT Configuration >> Changed events when such things occur? >>=20 >> In security considerations, missing messages are not mentioned. They >> should be. Would it be worthwhile to include a sequence number = (which >> does not appear to be part of the SYSLOG header, nor of the messages >> defined in this spec.) >=20 > Thanks for the review, let me know if there is anything specific to = IPFIX > that I have missed to respond in this review. Will do. - >=20 > Senthil >=20 >>=20 >> -d >>=20 >>=20 >> On May 8, 2013, at 8:55 AM, Tom Taylor = wrote: >>=20 >>> Done at last. The updated document has two new sections: >>>=20 >>> 2. Deployment Considerations >>> - discusses the logging implications of the various Softwires >>> transition methods, as well some considerations arising out >>> of the architectural role of the NAT. >>>=20 >>> 3. NAT-Related Events and Parameters >>> - is a description at a generally coding-independent level of >>> the events to be logged at NATs and their associated parameters. >>> In principle the contents are the same as in the IPFIX >>> document, but some reconciliation may be required. >>>=20 >>> These sections are followed by SYSLOG-specific stuff: applicability >>> statement, parameter and event encoding (with lots examples of = complete >>> logs), and an extensive IANA section. Then the usual remaining = sections. >>>=20 >>> Comments are welcome. Fire away. >>>=20 >>> Tom Taylor >>>=20 >>> On 08/05/2013 11:44 AM, internet-drafts@ietf.org wrote: >>>>=20 >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> This draft is a work item of the Behavior Engineering for Hindrance >>>> Avoidance Working Group of the IETF. >>>>=20 >>>> Title : Syslog Format for NAT Logging >>>> Author(s) : Zhonghua Chen >>>> Cathy Zhou >>>> Tina Tsou >>>> T. Taylor >>>> Filename : draft-ietf-behave-syslog-nat-logging-01.txt >>>> Pages : 31 >>>> Date : 2013-05-08 >>>>=20 >>>> Abstract: >>>> With the wide deployment of Carrier Grade NAT (CGN) devices, the >>>> logging of NAT-related events has become very important for legal >>>> purposes. The logs may be required to identify a host that was = used >>>> to launch malicious attacks or engage in illegal behaviour, = and/or >>>> may be required for accounting purposes. This document = identifies >>>> the events that need to be logged and the parameters that are >>>> required in the logs depending on the context in which the NAT is >>>> being used. It goes on to standardize formats for reporting = these >>>> events and parameters using SYSLOG (RFC 5424). A companion = document >>>> specifies formats for reporting the same events and parameters = using >>>> IPFIX (RFC 5101). Applicability statements are provided in this >>>> document and its companion to guide operators and implementors in >>>> their choice of which technology to use for logging. >>>>=20 >>> ... >>> _______________________________________________ >>> Behave mailing list >>> Behave@ietf.org >>> https://www.ietf.org/mailman/listinfo/behave >>=20 >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >=20 From dwing@cisco.com Mon Jul 1 10:11:22 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C29311E8198 for ; Mon, 1 Jul 2013 10:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.322 X-Spam-Level: X-Spam-Status: No, score=-110.322 tagged_above=-999 required=5 tests=[AWL=0.277, 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 R2p14n2S+dWu for ; Mon, 1 Jul 2013 10:11:18 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 20A3A11E81D5 for ; Mon, 1 Jul 2013 10:11:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5300; q=dns/txt; s=iport; t=1372698670; x=1373908270; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=POQh6HFoRIWehbWtcN/17relS1V6RbTZihyaLhchQRo=; b=lByorzLE/2xTxaLG5wSN60/Zj7AMpBP0risFs7kUZ9w7s3ym9uVAVSz2 dSHmB5gKpek8LByg2bTP0f0XUrvMuGo+FMJAk6cf7+iWM3SVBi2h4fnny pHJPE7WTaD5IQe7e/aaIREWh641XTWxVLpJzXrdtacl3wvPpoMFuFC+qX w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFABa30VGrRDoH/2dsb2JhbABagwkyv2N/FnSCIwEBAQMBAQEBNzQLBQsLGC4hBjAGE4d9AwkFDbNADYhOBIx1gSWBETMHgwRjA4kjjD6BZ4wghSWDMRyBLA X-IronPort-AV: E=Sophos;i="4.87,975,1363132800"; d="scan'208";a="84863525" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 01 Jul 2013 17:11:09 +0000 Received: from sjc-vpn2-667.cisco.com (sjc-vpn2-667.cisco.com [10.21.114.155]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r61HB8GE013214; Mon, 1 Jul 2013 17:11:08 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dan Wing In-Reply-To: <51D04BEF.60206@gmail.com> Date: Mon, 1 Jul 2013 10:11:06 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130508154447.24024.36769.idtracker@ietfa.amsl.com> <518A757F.5000701@gmail.com> <6ACBECAC-F476-4947-8F02-FC267403219C@cisco.com> <51D04BEF.60206@gmail.com> To: Tom Taylor X-Mailer: Apple Mail (2.1508) Cc: behave@ietf.org Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-syslog-nat-logging-01.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 17:11:22 -0000 On Jun 30, 2013, at 8:17 AM, Tom Taylor = wrote: > Thanks again for the time you put into this. Sorry I took so long to = get > back to you. >=20 > On 20/05/2013 9:56 PM, Dan Wing wrote: >> Thanks for writing this document. >>=20 >> My personal review, not as chair, >>=20 >> Section 2.1 seems to be trying to distinguish between mechanisms that >> are dynamic and those that are static. Static are DS-Lite with >> [I-D.tsou-behave-natx4-log-reduction] and [I-D.pcp-port-set], MAP-E, >> and lightweight 4over6. Dynamic is dynamic. Then there is the >> combination, which is popularly described in >> draft-donley-behave-deterministic-cgn. I would suggest separate >> sections explaining these three things, and more concisely. Also, >> Section 2.1 is titled "NAT Logging Requirements For Different >> Transition Methods" and has 3 paragraphs describing MAP-E, which does >> not do network address translation in the ISP's network; a different >> title for the section that discusses MAP-E seems useful. Afterall, >> with MAP-E the NAT function occurs in the customer premise NAT, which >> is not going to generate logging messages. It seems Section 2 might >> be something we would want common between the SYSLOG and IPFIX >> documents, perhaps? >=20 > [PTT] I receive your suggestions with enthusiasm. I had a problem with = logs that would be generated during provisioning rather than = dynamically, and drew an arbitrary line that said provisioning-time logs = would be out of scope of this draft. By sorting things out as you = suggest, I have a neat framework for specifying the log requirements in = each case. The Donley draft has a section on the topic to which we can = refer. >=20 >>=20 >> I noticed the non-normative "Note:" regarding Gateway-Initiated >> DS-Lite underneath Figure 1. Can that be moved to somewhere else so >> it is more normative? (It looks like a centered ). >> Perhaps it should be explained in Section 2.1, rather than here. >=20 > [PTT] OK, the note was really to open the question of whether we = should deal with the case of GW-initiated DS-Lite. I'll take it from = your comment that we should. BTW I don't see why this is a = SYSLOG-specific matter, as Senthil suggested. >>=20 >> In Figure 1, can the user identifier be generalized a bit? There are >> lots of NATs which use interface identifiers (e.g., en0, en1, en2), >> VLAN IDs, VRFs, to separate the inside addresses -- rather than using >> the fields shown here in Figure 1. This seems to have happened in >> Section 3.1 (which shows VLAN ID and VRFs) but the table does not >> appear to allow that sort of flexibility. >>=20 > [PTT] Will do. Are interface identifiers, VLAN IDs and VRFs an = exhaustive list or should we provide for arbitrary strings including = type identification (opaque to the logging system)? Should probably allow arbitrary strings. -d >>=20 >> Section 3.1, "NAT session creation and deletion events are recorded >> when a binding to a specific destination address and port is recorded >> in or deleted from the session database. See the discussion in >> Section 3 of [RFC6146]." >>=20 >> That does not align with the endpoint-independent mapping described >> in Section 3 of RFC6146. That is, a 'creation' event does not occur >> with every new destination address. >>=20 >> I found Section 3.1 really difficult to understand what is generated >> for a TCP/UDP mapping, versus what is supposed to be generated for an >> ICMP mapping. >>=20 > [PTT] I think Senthil and I have to sort out a few details in Sections = 3.1 to 3.3. >=20 >> " o Destination IPv4 (for NAT44) or IPv6 (for NAT64) address >> (OPTIONAL);" >>=20 >> A NAT64 would have an IPv4 destination address. Note this is for >> *destination logging*, which needs its own discussion beyond just >> "(OPTIONAL)" and beyond the citation that RFC6888 recommends against >> destination logging. There are implementation issues with >> destination logging (state creation in the logging device to avoid >> generating a log event with every packet), and it deserves mentioning >> in a logging document that destination logging more than destroys the >> log reduction benefit of bulk port assignment. >>=20 >=20 > [PTT] OK >>=20 >> " o Post-NAT destination IPv4 address (OPTIONAL);" >>=20 >> Seems redundant with the preceding item. >>=20 >> "The pre-NAT value of destination address will differ from the >> post-NAT value only in a double-NAT situation. Hence in most cases >> even with destination logging the pre-NAT value will not be >> recorded." >>=20 >> I don't understand what that means. Please make it clearer in the >> document. This is the first and only time the term "double-NAT" >> appears in the document, which might be part of my confusion. >>=20 >=20 > [PTT] I ran into this when doing the Midcom semantics. Basically the = problem occurs when you map from one private space to another, or when = hairpinning. >=20 > ... >=20 > [PTT] I'll respond to the rest of your remarks later. > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From dwing@cisco.com Mon Jul 1 10:19:13 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98B4A21F9FF6 for ; Mon, 1 Jul 2013 10:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.377 X-Spam-Level: X-Spam-Status: No, score=-110.377 tagged_above=-999 required=5 tests=[AWL=0.222, 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 iFGh4itJExzh for ; Mon, 1 Jul 2013 10:19:09 -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 2EFC821F9F6A for ; Mon, 1 Jul 2013 10:18:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1728; q=dns/txt; s=iport; t=1372699126; x=1373908726; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=SG8Jeym71A2haw6pIfRO/esThaU+Bfv+k9pXb+zIUnQ=; b=MNaxXgBnYH0VKZkPnF0N5/wNXN+tO5T2GuTQzuhySP/HTVOc+jahsQ0m oCRqwDS6WfpOJiC5g72BgLH0GFPZXlhWjdg8N3bPr68fIIs1uqd6t5Sr3 VZewp9qOUSisvW+E6C8OQRv5kByostP8Gd1U9vk2/ARU1IkPVKa6W0uPg s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAJe40VGrRDoG/2dsb2JhbABagwkyv2N/FnSCIwEBAQMBOjINBQsLRlcGE4gJBQ28HI4mgQUzB4MEYwOJI44lgSmQHIMxHIEs X-IronPort-AV: E=Sophos;i="4.87,975,1363132800"; d="scan'208";a="84929880" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 01 Jul 2013 17:18:45 +0000 Received: from sjc-vpn2-667.cisco.com (sjc-vpn2-667.cisco.com [10.21.114.155]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r61HIi5N021541; Mon, 1 Jul 2013 17:18:45 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dan Wing In-Reply-To: <786F13AA11E69F4DB2CCA23F7400C2FB0146E019@S2010EXCH1.ad.local> Date: Mon, 1 Jul 2013 10:18:44 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <779AE7C6-8349-4DEA-92FC-00E520B80632@cisco.com> References: <786F13AA11E69F4DB2CCA23F7400C2FB0146E019@S2010EXCH1.ad.local> To: Branimir Rajtar X-Mailer: Apple Mail (2.1508) Cc: "behave@ietf.org" Subject: Re: [BEHAVE] v6 content for IPv4-only clients X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 17:19:13 -0000 On Jul 1, 2013, at 12:59 AM, Branimir Rajtar = wrote: > Hello everybody, > =20 > Just wanted to let you know my colleagues and me just posted a new = draft describing how IPv4-only clients can access content available only = on IPv6. Please take a look and comment: > = http://datatracker.ietf.org/doc/draft-rfvlb-behave-v6-content-for-v4-clien= ts/ The document says: 1.2. Covered Scenarios As described in [RFC6144], there are multiple scenarios for IPv4/IPv6 translation. This document covers mainly Scenario 4: An IPv4 Network to the IPv6 Internet, but is not limited to be used for the following scenarios as well: o Scenario 2: The IPv4 Internet to an IPv6 Network o Scenario 6: An IPv4 Network to an IPv6 Network These scenarios are not subject of this draft and can be elaborated in future documents, if deemed necessary. I don't think Scenario 2 is solvable with the approach described in = draft-rfvlb-behave-v6-content-for-v4-clients, because = draft-rfvlb-behave-v6-content-for-v4-clients describes assigning IPv4 = addresses from RFC1918 space. If public space were to be assigned = instead of RFC1918 space, public IPv4 space would be consumed at the = same rate as running a normal dual-stack server, so nothing is gained = compared to operating a normal dual-stack server. It would be helpful to include a network diagram showing the location of = the DNS proxy (which is a new function), the NAT46 function, and the = Internet. I have a topology in my head, and I believe my topology is = accurate, but I can't be sure until I see a diagram of where these = elements would be located. Thanks. -d From Branimir.Rajtar@t.ht.hr Tue Jul 2 00:45:21 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57D8311E83FD for ; Tue, 2 Jul 2013 00:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UgDCgKMcX-uJ for ; Tue, 2 Jul 2013 00:45:17 -0700 (PDT) Received: from mx02.t.ht.hr (mx02.t.ht.hr [195.29.161.89]) by ietfa.amsl.com (Postfix) with SMTP id 24C9411E8400 for ; Tue, 2 Jul 2013 00:45:14 -0700 (PDT) Received: from (unknown [172.17.66.76]) by mx02.t.ht.hr with smtp id 5bb2_00bd_53ce8e2e_e2eb_11e2_b39a_00219b931f47; Tue, 02 Jul 2013 09:45:12 +0200 Received: from S2010EXCHCA1.ad.local ([10.240.132.138]) by mailgw.ad.local with Microsoft SMTPSVC(6.0.3790.4675); Tue, 2 Jul 2013 09:45:12 +0200 Received: from S2010EXCH1.ad.local ([fe80::2d7b:39dd:876e:f277]) by S2010EXCHCA1.ad.local ([::1]) with mapi id 14.03.0123.003; Tue, 2 Jul 2013 09:45:12 +0200 From: Branimir Rajtar To: Dan Wing Thread-Topic: [BEHAVE] v6 content for IPv4-only clients Thread-Index: AQHOdn8OWNsxC9tn+0SigmuhfdiZVZlRAYyQ Date: Tue, 2 Jul 2013 07:45:11 +0000 Message-ID: <786F13AA11E69F4DB2CCA23F7400C2FB0146E94E@S2010EXCH1.ad.local> References: <786F13AA11E69F4DB2CCA23F7400C2FB0146E019@S2010EXCH1.ad.local> <779AE7C6-8349-4DEA-92FC-00E520B80632@cisco.com> In-Reply-To: <779AE7C6-8349-4DEA-92FC-00E520B80632@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.10.22] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 02 Jul 2013 07:45:12.0576 (UTC) FILETIME=[158B9800:01CE76F8] X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] v6 content for IPv4-only clients X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 07:45:21 -0000 SGksCgpUaGFua3MgZm9yIHlvdXIgcmV2aWV3LCB5b3VyIGNvbW1lbnRzIG1ha2Ugc2Vuc2UgLSBv bmNlIEkgZ2F0aGVyIGFsbCBvdGhlciBjb21tZW50cywgSSdsbCByZW1vdmUgU2NlbmFyaW8gMiBm cm9tIHRoZSBkb2N1bWVudCBhbmQgaW5jbHVkZSBhIG5ldHdvcmsgZGlhZ3JhbS4KCkJyYW5pbWly CgoKLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0KRnJvbTogRGFuIFdpbmcgW21haWx0bzpkd2lu Z0BjaXNjby5jb21dIApTZW50OiBNb25kYXksIEp1bHkgMDEsIDIwMTMgNzoxOSBQTQpUbzogQnJh bmltaXIgUmFqdGFyCkNjOiBiZWhhdmVAaWV0Zi5vcmcKU3ViamVjdDogUmU6IFtCRUhBVkVdIHY2 IGNvbnRlbnQgZm9yIElQdjQtb25seSBjbGllbnRzCgoKT24gSnVsIDEsIDIwMTMsIGF0IDEyOjU5 IEFNLCBCcmFuaW1pciBSYWp0YXIgPEJyYW5pbWlyLlJhanRhckB0Lmh0LmhyPiB3cm90ZToKCj4g SGVsbG8gZXZlcnlib2R5LAo+ICAKPiBKdXN0IHdhbnRlZCB0byBsZXQgeW91IGtub3cgbXkgY29s bGVhZ3VlcyBhbmQgbWUganVzdCBwb3N0ZWQgYSBuZXcgZHJhZnQgZGVzY3JpYmluZyBob3cgSVB2 NC1vbmx5IGNsaWVudHMgY2FuIGFjY2VzcyBjb250ZW50IGF2YWlsYWJsZSBvbmx5IG9uIElQdjYu IFBsZWFzZSB0YWtlIGEgbG9vayBhbmQgY29tbWVudDoKPiBodHRwOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LXJmdmxiLWJlaGF2ZS12Ni1jb250ZW50LWZvci12NC1jbGllbnRzLwoK VGhlIGRvY3VtZW50IHNheXM6CgogIDEuMi4gIENvdmVyZWQgU2NlbmFyaW9zCgogICBBcyBkZXNj cmliZWQgaW4gW1JGQzYxNDRdLCB0aGVyZSBhcmUgbXVsdGlwbGUgc2NlbmFyaW9zIGZvciBJUHY0 L0lQdjYKICAgdHJhbnNsYXRpb24uICBUaGlzIGRvY3VtZW50IGNvdmVycyBtYWlubHkgU2NlbmFy aW8gNDogQW4gSVB2NCBOZXR3b3JrCiAgIHRvIHRoZSBJUHY2IEludGVybmV0LCBidXQgaXMgbm90 IGxpbWl0ZWQgdG8gYmUgdXNlZCBmb3IgdGhlIGZvbGxvd2luZwogICBzY2VuYXJpb3MgYXMgd2Vs bDoKCiAgIG8gIFNjZW5hcmlvIDI6IFRoZSBJUHY0IEludGVybmV0IHRvIGFuIElQdjYgTmV0d29y awoKICAgbyAgU2NlbmFyaW8gNjogQW4gSVB2NCBOZXR3b3JrIHRvIGFuIElQdjYgTmV0d29yawoK ICAgVGhlc2Ugc2NlbmFyaW9zIGFyZSBub3Qgc3ViamVjdCBvZiB0aGlzIGRyYWZ0IGFuZCBjYW4g YmUgZWxhYm9yYXRlZAogICBpbiBmdXR1cmUgZG9jdW1lbnRzLCBpZiBkZWVtZWQgbmVjZXNzYXJ5 LgoKCkkgZG9uJ3QgdGhpbmsgU2NlbmFyaW8gMiBpcyBzb2x2YWJsZSB3aXRoIHRoZSBhcHByb2Fj aCBkZXNjcmliZWQgaW4gZHJhZnQtcmZ2bGItYmVoYXZlLXY2LWNvbnRlbnQtZm9yLXY0LWNsaWVu dHMsIGJlY2F1c2UgZHJhZnQtcmZ2bGItYmVoYXZlLXY2LWNvbnRlbnQtZm9yLXY0LWNsaWVudHMg ZGVzY3JpYmVzIGFzc2lnbmluZyBJUHY0IGFkZHJlc3NlcyBmcm9tIFJGQzE5MTggc3BhY2UuICBJ ZiBwdWJsaWMgc3BhY2Ugd2VyZSB0byBiZSBhc3NpZ25lZCBpbnN0ZWFkIG9mIFJGQzE5MTggc3Bh Y2UsIHB1YmxpYyBJUHY0IHNwYWNlIHdvdWxkIGJlIGNvbnN1bWVkIGF0IHRoZSBzYW1lIHJhdGUg YXMgcnVubmluZyBhIG5vcm1hbCBkdWFsLXN0YWNrIHNlcnZlciwgc28gbm90aGluZyBpcyBnYWlu ZWQgY29tcGFyZWQgdG8gb3BlcmF0aW5nIGEgbm9ybWFsIGR1YWwtc3RhY2sgc2VydmVyLgoKSXQg d291bGQgYmUgaGVscGZ1bCB0byBpbmNsdWRlIGEgbmV0d29yayBkaWFncmFtIHNob3dpbmcgdGhl IGxvY2F0aW9uIG9mIHRoZSBETlMgcHJveHkgKHdoaWNoIGlzIGEgbmV3IGZ1bmN0aW9uKSwgdGhl IE5BVDQ2IGZ1bmN0aW9uLCBhbmQgdGhlIEludGVybmV0LiBJIGhhdmUgYSB0b3BvbG9neSBpbiBt eSBoZWFkLCBhbmQgSSBiZWxpZXZlIG15IHRvcG9sb2d5IGlzIGFjY3VyYXRlLCBidXQgSSBjYW4n dCBiZSBzdXJlIHVudGlsIEkgc2VlIGEgZGlhZ3JhbSBvZiB3aGVyZSB0aGVzZSBlbGVtZW50cyB3 b3VsZCBiZSBsb2NhdGVkLiAgVGhhbmtzLgoKLWQKCgoKPEhUTUw+PFA+PEZPTlQgZmFjZT1Bcmlh bCBjb2xvcj0jOTk5OTk5IHNpemU9MT4NCg0KSVpKQVZBIE8gT0RSSUNBTkpVIE9ER09WT1JOT1NU STogU2FkcsW+YWogb3ZlIHBvcnVrZSBpIGV2ZW50dWFsbm8gcHJpbG/FvmVuaWggZGF0b3Rla2Eg amUgcG92amVybGppdiBpIG5hbWlqZW5qZW4gamUgc2FtbyBvc29iYW1hIGlsaSBzdWJqZWt0aW1h IGtvamkgc3UgbmF2ZWRlbmkgdSBhZHJlc2kuIFVrb2xpa28gc3RlIHByaW1pbGkgb3Z1IHBvcnVr dSBncmXFoWtvbSwgbW9saW1vIFZhcywgb2JhdmlqZXN0aXRlIHBvxaFpbGphdGVsamEsIGEgcG9y dWt1IGkgc3ZlIG5qZW5lIHByaXZpdGtlIG9kbWFoLCBiZXogxI1pdGFuamEsIHRyYWpubyB1a2xv bml0ZSBzIHJhxI11bmFsYS4gQmlsbyBrYWt2byBwcmVub8WhZW5qZSwga29waXJhbmplIGlsaSBk aXN0cmlidWNpamEgaW5mb3JtYWNpamEgc2FkcsW+YW5paCB1IHBvcnVjaSB0cmXEh2ltIG9zb2Jh bWEgamUgemFicmFuamVubyBpIG1vxb5lIGJpdGkgemFrb25za2kga2HFvm5qaXZvLiBTYWRyxb5h aiwgc3Rhdm92aSBpIG1pxaFsamVuamEgaXpuZXNlbmkgdSBwb3J1Y2kgc3UgYXV0b3JvdmkgaSBu ZSBwcmVkc3RhdmxqYWp1IG51xb5ubyBzdGF2b3ZlIEhUIC0gSHJ2YXRza2loIHRlbGVrb211bmlr YWNpamEgZC5kLiBIVCBuZSBwcmlodmHEh2EgbmlrYWt2dSBvZGdvdm9ybm9zdCB6YSBldmVudHVh bG51IMWhdGV0dSBuYXN0YWx1IHByaW1pdGtvbSBvdmUgcG9ydWtlIGkgcHJpbG9nYSBzYWRyxb5h bmloIHUgcG9ydWNpLg0KDQo8L0ZPTlQ+PC9QPjxQPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9Izk5 OTk5OSBzaXplPTE+DQoNCiBESVNDTEFJTUVSOlRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFz IHdlbGwgYXMgYW55IGZpbGVzIGF0dGFjaGVkIHRvIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGlu dGVuZGVkIHNvbGVseSBmb3IgaW5kaXZpZHVhbHMgb3IgZW50aXRpZXMgd2hpY2ggdGhleSBhcmUg YWRkcmVzc2VkIHRvLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIG1lc3NhZ2UgaW4g ZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgcGVybWFuZW50bHkgcmVtb3ZlIHRo ZSBtZXNzYWdlIGFuZCBhbGwgYXR0YWNoZWQgZmlsZXMgZnJvbSB0aGUgY29tcHV0ZXIuIEFueSBk aXNjbG9zdXJlLCBjb3B5aW5nIG9yIGRpc3RyaWJ1dGlvbiBvZiBhbGwgb3IgYSBwYXJ0IG9mIGlu Zm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gdG8gb3IgYnkgdGhpcmQgcGFydGllcyBpcyBwcm9o aWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIFBsZWFzZSBub3RlIHRoYXQgYW55IHZpZXdzIG9y IG9waW5pb25zIHByZXNlbnRlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHNvbGVseSB0aG9zZSBvZiB0 aGUgYXV0aG9yIGFuZCBkbyBub3QgbmVjZXNzYXJpbHkgcmVwcmVzZW50IHRoZSB2aWV3cyBhbmQg b3BpbmlvbnMgb2YgQ3JvYXRpYW4gVGVsZWNvbSBJbmMuIENyb2F0aWFuIFRlbGVjb20gSW5jLiBh Y2NlcHRzIG5vIGxpYWJpbGl0eSBmb3IgYW55IHBvdGVudGlhbCBkYW1hZ2UgY2F1c2VkIGJ5IHRo aXMgbWVzc2FnZSBhbmQgZmlsZXMgYXR0YWNoZWQgdG8gaXQuDQoNCjwvRk9OVD48L1A+PC9IVE1M Pgo= From palmarti@cisco.com Tue Jul 2 05:48:25 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E6DB21F9A0A for ; Tue, 2 Jul 2013 05:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.446 X-Spam-Level: X-Spam-Status: No, score=-9.446 tagged_above=-999 required=5 tests=[AWL=1.153, 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 cr2ZvMzYoOxP for ; Tue, 2 Jul 2013 05:48:25 -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 6BE2721F99FA for ; Tue, 2 Jul 2013 05:48:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2074; q=dns/txt; s=iport; t=1372769305; x=1373978905; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=lkCQmuMmRPJJ5oyw91g+xFSCzHM0wSTkkcAC+MpwYSQ=; b=B/6f76CkKyEpvuv7YNyJXenMgeaHCtt6naOUrVSKdiIKq21ElPueqTa2 B17WUpInTd2S4K4lzBkYdlIYa9IxszEffXcds6j4Qt1MfznXRqPmmAviS 6v3eoSbeVxLeyahsvPfa1SsMrbimyhf/AJ67nQK+fBS16IHZkACj6BmLK M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAI/K0lGtJV2b/2dsb2JhbABagwkySb9NgQAWdIIjAQEBAwF3FAEqVicEGwGIAAYMmz2gNI8pgzxnA4hrkAeQHIMRgig X-IronPort-AV: E=Sophos;i="4.87,980,1363132800"; d="scan'208";a="229921732" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 02 Jul 2013 12:48:25 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r62CmOVW025623 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 2 Jul 2013 12:48:24 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.251]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Tue, 2 Jul 2013 07:48:24 -0500 From: "Pal Martinsen (palmarti)" To: "behave@ietf.org" Thread-Topic: New Version Notification for draft-martinsen-mmusic-malice-00.txt Thread-Index: AQHOdyJw37AbkWrJrEWjp30Gn/2WHw== Date: Tue, 2 Jul 2013 12:48:23 +0000 Message-ID: <1373AC9C23D80E44856F5CF6F883ACAB1142B636@xmb-rcd-x06.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.160.14] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [BEHAVE] New Version Notification for draft-martinsen-mmusic-malice-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 12:48:25 -0000 Hi, We submitted a new draft called MALICE today. It is all about smarter appli= cation/network communication. Se abstract for some details. Read the whole = draft to get a lot more details. >=20 > A new version of I-D, draft-martinsen-mmusic-malice-00.txt > has been successfully submitted by Reinaldo Penno and posted to the > IETF repository. >=20 > Filename: draft-martinsen-mmusic-malice > Revision: 00 > Title: Meta-data Attribute signaLling with ICE > Creation date: 2013-07-02 > Group: Individual Submission > Number of pages: 33 > URL: http://www.ietf.org/internet-drafts/draft-martinsen-mmus= ic-malice-00.txt > Status: http://datatracker.ietf.org/doc/draft-martinsen-mmusic-m= alice > Htmlized: http://tools.ietf.org/html/draft-martinsen-mmusic-malice= -00 >=20 >=20 > Abstract: > It can be useful for applications to provide flow metadata > information to on-path devices to influence flow treatment in the > network. Provided that the network is able to provide useful > feedback, this can also influence path selection if an application > have multiple flow paths to choose from. >=20 > This draft describes how this can be achieved by adding metadata to > the STUN packets sent during the ICE connectivity checks or a > slightly modified version of the keep-alive mechanism. Devices on > the media path can use the metadata information to prioritize the > flow, perform traffic engineering, or provide network analytics and > notifications as requested by the endpoints. On-path devices can > append or modify the existing metadata information in the STUN/ICE > messages to enable feedback to other on-path devices or the > applications in both ends of the media session. >=20 > This document describes a framework mechanism for how such metadata > can be transported by STUN when ICE is in use and it covers the > endpoint and on path device processing. The functionality described > here is referred to as MALICE. .-. P=E5l-Erik= From ivan@cacaoweb.org Tue Jul 2 11:23:45 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEFF921F9BD3 for ; Tue, 2 Jul 2013 11:23:43 -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 8Oj6Lt4QUiiR for ; Tue, 2 Jul 2013 11:23:38 -0700 (PDT) Received: from mail.cacaoweb.org (mail.cacaoweb.org [46.105.102.78]) by ietfa.amsl.com (Postfix) with ESMTP id B027221F9BB7 for ; Tue, 2 Jul 2013 11:23:36 -0700 (PDT) Received: from www-data by mail.cacaoweb.org with local (Exim 4.72) (envelope-from ) id 1Uu5Fm-00011I-D6; Tue, 02 Jul 2013 20:24:38 +0200 To: Simon Perreault X-PHP-Originating-Script: 0:func.inc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Date: Tue, 02 Jul 2013 20:24:38 +0200 From: ivan c Organization: cacaoweb In-Reply-To: <51CAA325.8080201@viagenie.ca> References: <9637befefe07c43417c758a004e03f3c@cacaoweb.org> <51C4053D.5050703@viagenie.ca> <51CAA325.8080201@viagenie.ca> Message-ID: X-Sender: ivan@cacaoweb.org User-Agent: RoundCube Webmail/0.3.1 Cc: Behave Subject: Re: [BEHAVE] TCP port overloading, preservation and CGNs X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ivan@cacaoweb.org List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 18:23:45 -0000 On Wed, 26 Jun 2013 10:15:33 +0200, Simon Perreault wrote: > Le 2013-06-25 19:20, ivan c a écrit : >>> Some NATs don't implement EDM and thus cannot switch to it. >>> >> >> By definition, all NATs are "EDM". > > Please explain. > >> "Endpoint-dependent Mapping" really means "Address and port-dependent >> Mapping". This is the most general case of NAT, where no requirement is >> made on the type of mapping. For instance, "EIM" is a particular case of >> this general case. > > I don't understand how this could be true. "Endpoint-dependent Mapping" definition is that mappings with the same internal endpoint may be assigned to different external endpoints. It is verified for all NATs. > >> Maybe we should use the term APDM instead of EDM for the sake of clarity, >> but the best is probably to avoid using the "EDM" acronym altogether if >> it >> leads to confusion. > > EDM is defined in RFC 6887. Let's keep using already-defined terminology > if it fits. If it doesn't confuse anyone, I have no problem using it. See above. Although new acronyms in general are best avoided since they require readers to learn new acronyms for no particular reason. > >> Instead, we can use the term "no particular >> requirement >> on the mapping scheme" or something similar. This way, people new to the >> discussion can understand the point immediately and we also avoid the use >> of new obscure acronyms. > > EIM and EDM are not requirements. They are qualifiers of NAT behaviour. Nope, "Endpoint-Independent Mapping" can be a requirement, for example REQ 1. of RFC 4787. > >> Again, the goal here should be to suggest options for NAT to behave in >> p2p >> friendly ways. Some useful optional features for CGNs, like port >> overloading, do have minor caveats that should be detailed in the >> document, >> and they also don't apply to "3-tuple" NATs as you mentioned. >> This is the best way in my opinion to write a Best Current Practices >> document. > > I would simply like to first understand technically what you're proposing. Sounds great. > > Simon -- _Ivan Chollet_ From ivan@cacaoweb.org Tue Jul 2 12:33:46 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC82A21F9B4B for ; Tue, 2 Jul 2013 12:33:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9qPSrv9zKon for ; Tue, 2 Jul 2013 12:33:41 -0700 (PDT) Received: from mail.cacaoweb.org (mail.cacaoweb.org [46.105.102.78]) by ietfa.amsl.com (Postfix) with ESMTP id 9D85C21F9B44 for ; Tue, 2 Jul 2013 12:33:41 -0700 (PDT) Received: from www-data by mail.cacaoweb.org with local (Exim 4.72) (envelope-from ) id 1Uu6LZ-000236-Gw; Tue, 02 Jul 2013 21:34:41 +0200 To: Simon Perreault X-PHP-Originating-Script: 0:func.inc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Date: Tue, 02 Jul 2013 21:34:41 +0200 From: ivan c Organization: cacaoweb In-Reply-To: <51CD7B7A.8000604@viagenie.ca> References: <2f7dce8264c8a9a72640629502a44295@cacaoweb.org> <51C1681A.5030909@viagenie.ca> <51C40374.8080403@viagenie.ca> <21e25b7ae1501228a67656b2fa4bc009@cacaoweb.org> <51CAA20F.4070307@viagenie.ca> <7f35bf30538732e3953bd33bcab7a791@cacaoweb.org> <51CC444C.1030507@viagenie.ca> <20130627141434.3B0BD365EA62@drugs.dv.isc.org> <51CC4A59.8080801@viagenie.ca> <20130627143612.51ECB365ED5A@drugs.dv.isc.org> <51CC50AE.2080909@viagenie.ca> <20130627221133.4FBF936609FC@drugs.dv.isc.org> <51CD7B7A.8000604@viagenie.ca> Message-ID: <06230d10cf8b2b57f2825dcd86bc3fd0@cacaoweb.org> X-Sender: ivan@cacaoweb.org User-Agent: RoundCube Webmail/0.3.1 Cc: behave@ietf.org, Mark Andrews Subject: Re: [BEHAVE] DNS vs port overloading X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ivan@cacaoweb.org List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 19:33:46 -0000 On Fri, 28 Jun 2013 14:03:06 +0200, Simon Perreault wrote: > Le 2013-06-28 00:11, Mark Andrews a écrit : >>> Right, but, port overloading is not what kills the randomization done by >>> the DNS client. Non-port preserving NAT is what kills it. >> >> Deterministic (e.g. sequential) port assignment kills it. Port >> overloading kills it if not done sensibly. > > Sure, but isn't all that already covered by RFC 6056? > > That is, does anything still need to be said about this? > > Simon I would agree that a reference to RFC 6056 is enough. This point is about the allocation algorithm used by the NAT. A NAT should try to preserve port randomness, which excludes some allocation algorithms. This applies equally to the allocation algorithms that use port overloading and the ones that don't. -- _Ivan Chollet_ From washam.fan@gmail.com Tue Jul 2 23:06:23 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1AE121F9C45 for ; Tue, 2 Jul 2013 23:06:23 -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, HTML_MESSAGE=0.001, 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 BOV8q2xZcODU for ; Tue, 2 Jul 2013 23:06:23 -0700 (PDT) Received: from mail-vc0-x235.google.com (mail-vc0-x235.google.com [IPv6:2607:f8b0:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 249B621F9C2C for ; Tue, 2 Jul 2013 23:06:22 -0700 (PDT) Received: by mail-vc0-f181.google.com with SMTP id lf11so3307617vcb.26 for ; Tue, 02 Jul 2013 23:06:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5hK9xdWqLPj+3ziDfAvVChGH77Tq4D6u0PSO0b3nkAE=; b=OLLYqbmzLUfVs1JbRsI3HgAq9aVh4qg0YKJuwp3aW6DYg3R9YVR3gkBAh4Wk2Zgy3Q Q/eR7hgUfNdmp99NtruKZrlF3/u25yANLz+DCxLH9xrgN/tqiQWK5Z0PjEmckqeR8ze/ eyO0z+fFtbwMdmxbt7w7fD9bV57Z0KNJk5lN78sMD0iRvagQt0PfMaLbHopYJd3KKFPl QyusFBuTzlZS+xXXmusH5CPGFIm9epR+UnGehAtb8EtOdABZ+8IISXRe/Y8D+K9yyXoU okNWTAqioMT/qaACxvj5dRuQ+FugvtnOpSfVmX89+sRWSTqeeZSmLVGv4zbWXYaOf67p t/rA== MIME-Version: 1.0 X-Received: by 10.220.41.77 with SMTP id n13mr9054833vce.36.1372831582549; Tue, 02 Jul 2013 23:06:22 -0700 (PDT) Received: by 10.220.158.133 with HTTP; Tue, 2 Jul 2013 23:06:22 -0700 (PDT) In-Reply-To: <51C3F11D.1030501@lab.ntt.co.jp> References: <3a724be2431cf7249b3d46cf378f85bf@cacaoweb.org> <51BFE896.2000006@lab.ntt.co.jp> <1d235e99689e55aba94258ff65895f75@cacaoweb.org> <51C3F11D.1030501@lab.ntt.co.jp> Date: Wed, 3 Jul 2013 14:06:22 +0800 Message-ID: From: Washam Fan To: Kengo Naito Content-Type: multipart/alternative; boundary=047d7b3a90eed07c6404e0954279 Cc: Behave , ivan@cacaoweb.org Subject: Re: [BEHAVE] review of draft-penno-behave-rfc4787-5382-5508-bis X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 06:06:23 -0000 --047d7b3a90eed07c6404e0954279 Content-Type: text/plain; charset=ISO-8859-1 Hi, > >> 3.1.2.2 I was unable to fully grasp the idea and its relationship with the >> TIME_WAIT state, it would be nice if you could elaborate on this. >> > In this mechanism, usable port set are splited to each client, which means > that for each port, > arriving packets have monotonically increasing values of TCP timestamp or > ISN. > In this case, as values are monotonically increasing, 6191 will work and > terminate TIME_WAIT. > > Please note that linux kernel checks if values are monotonically increasing for each remote IP instead of (IP, port) pair. at least for kernel 3.6.6 and earlier. B.R. washam --047d7b3a90eed07c6404e0954279 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,





3.1.2.2 I was unable to fully grasp the idea and its relationship with the<= br> TIME_WAIT state, it would be nice if you could elaborate on this.
In this mechanism, usable port set are splited to each client, which means = that for each port,
arriving packets have monotonically increasing values of TCP timestamp or I= SN.
In this case, as values are monotonically increasing, 6191 will work and te= rminate TIME_WAIT.

Please note that linux kernel = checks if values are monotonically increasing for each remote IP instead of= (IP, port) pair. at least=A0 for kernel 3.6.6 and earlier.

B.R.
washam
--047d7b3a90eed07c6404e0954279-- From dwing@cisco.com Fri Jul 5 14:23:55 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F91021F9F6C for ; Fri, 5 Jul 2013 14:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.488 X-Spam-Level: X-Spam-Status: No, score=-110.488 tagged_above=-999 required=5 tests=[AWL=0.111, 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 KmvzixnHJBfN for ; Fri, 5 Jul 2013 14:23:50 -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 154D321F9F58 for ; Fri, 5 Jul 2013 14:23:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1241; q=dns/txt; s=iport; t=1373059429; x=1374269029; h=from:content-transfer-encoding:subject:date:references: to:message-id:mime-version; bh=gUZ4YGnT9wNRAY7v5q5ZHOidpJDPJ6+xzXfG7XJv5lU=; b=GdwtlXcG7OUApAcrl81BszFygic7G/S4ptSBjv3I/DpMpKTqrv2V6Ari fvWHRiARWDjbslbcPdH3HQETJLYxBQRgstnETxW7Ac5JDPsEDQXPZ7FW6 T/dhs5XE9uwlfJXb0CLraiEy7eFFQYuVLZc97F3UkLoHXRsS5tLlfnLq1 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAJM411GrRDoJ/2dsb2JhbABagwnBSoECFnSCIwEBAQMBOkQLHAMBAi9PCAYTiAkFrAuMbo94gn5pA4kjjiaRRYMxHA X-IronPort-AV: E=Sophos;i="4.87,1004,1363132800"; d="scan'208";a="82290967" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 05 Jul 2013 21:23:47 +0000 Received: from sjc-vpn7-1196.cisco.com (sjc-vpn7-1196.cisco.com [10.21.148.172]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r65LN7cw023444 for ; Fri, 5 Jul 2013 21:23:47 GMT From: Dan Wing Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 5 Jul 2013 14:23:47 -0700 References: <20130705204849.4458.83201.idtracker@ietfa.amsl.com> To: "behave@ietf.org" Message-Id: <5465D1D3-7862-4AF2-8613-FCAC48460750@cisco.com> Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [BEHAVE] BEHAVE session moved to Monday X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 21:23:55 -0000 FYI, BEHAVE will now be meeting on Monday afternoon. Details below. -d Begin forwarded message: > From: "\"IETF Secretariat\"" > Subject: behave - Requested session has been scheduled for IETF 87 > Date: July 5, 2013 1:48:49 PM PDT > To: > Cc: , , = , >=20 > Dear Dan Wing, >=20 > The session(s) that you have requested have been scheduled. > Below is the scheduled session information followed by > the original request.=20 >=20 > behave Session 1 (1:30:00) > Monday, Afternoon Session I 1300-1500 > Room Name: Charlottenburg 1 > --------------------------------------------- >=20 >=20 >=20 > Request Information: >=20 >=20 > --------------------------------------------------------- > Working Group Name:=20 > Area Name:=20 > Session Requester:=20 >=20 > Number of Sessions: 1 > Length of Session(s): 1.5 Hours > Number of Attendees: 50 > Conflicts to Avoid:=20 > First Priority: pcp mif dnsop dnsext 6man softwire sunset4 intarea = tsvarea >=20 >=20 >=20 >=20 > Special Requests: >=20 > --------------------------------------------------------- >=20 From phdgang@gmail.com Mon Jul 8 23:23:54 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A8B521F9EB3 for ; Mon, 8 Jul 2013 23:23:54 -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 tADHBWRbyhe2 for ; Mon, 8 Jul 2013 23:23:53 -0700 (PDT) Received: from mail-qe0-x22b.google.com (mail-qe0-x22b.google.com [IPv6:2607:f8b0:400d:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 2373121F9E0D for ; Mon, 8 Jul 2013 23:23:53 -0700 (PDT) Received: by mail-qe0-f43.google.com with SMTP id q19so2806404qeb.16 for ; Mon, 08 Jul 2013 23:23:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=52w4Cql9TEgrwpb1x05INr1fpVipG9JR+wnDE8vnhUY=; b=DHWzov9FTwX+aS2nrGX5hXmdc6HlZdAfZTrRNONCXuZQMAy0NtLj6eVgmAv/NXW51o jiyQ9x6dRtPlrHn3pIACtUqlQUJ+RueBmRP+2GsEimptrYmn5ZhUvMNMlZjyEzFD63/Q 0tyilPsmqLF41LUfOjX6IE4HeGwSscbekgVBlRjtifVG2ywHDVBECZex4mM10fjhObDu n1d0RkDGJohYJXh+Z+CqzVOg2Nhs3vI3ARS435k8ZSLdxN9eTGc0akuksBSdtcYbHQsJ 0YySaorYQjbfAznvLIBhHiHFVTSUX0aLYl8ukLnfhjPEs2yR52TrfrXV07G2QFUPLybf jp1A== MIME-Version: 1.0 X-Received: by 10.224.34.133 with SMTP id l5mr22017496qad.103.1373351032599; Mon, 08 Jul 2013 23:23:52 -0700 (PDT) Received: by 10.224.193.195 with HTTP; Mon, 8 Jul 2013 23:23:52 -0700 (PDT) In-Reply-To: <20130708151636.25487.48986.idtracker@ietfa.amsl.com> References: <20130708151636.25487.48986.idtracker@ietfa.amsl.com> Date: Tue, 9 Jul 2013 14:23:52 +0800 Message-ID: From: GangChen To: Behave WG Content-Type: text/plain; charset=ISO-8859-1 Subject: [BEHAVE] Fwd: I-D Action: draft-chen-behave-nat64-radius-extension-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 06:23:54 -0000 wg, We just uploaded the draft-chen-behave-nat64-radius-extension-00 The draft proposes new Radius attributes to convey IPv6 source addresses when a NAT64 is deployed. Your comments/reviews are appreciated. Best Regards Gang ---------- Forwarded message ---------- From: internet-drafts@ietf.org Date: Mon, 08 Jul 2013 08:16:36 -0700 Subject: I-D Action: draft-chen-behave-nat64-radius-extension-00.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Radius Attributes for Stateful NAT64 Author(s) : Gang Chen David Binet Filename : draft-chen-behave-nat64-radius-extension-00.txt Pages : 10 Date : 2013-07-08 Abstract: This document proposes new radius attributes for stateful NAT64. The extensions are used to provide geo-location services with an exact IPv6 soruce address. The message flow to deliver the NAT64 binding information between radius clients and servers is also described. Therefore, accurate location could be traced out depending on the radius method. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-chen-behave-nat64-radius-extension There's also a htmlized version available at: http://tools.ietf.org/html/draft-chen-behave-nat64-radius-extension-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From bingxuere@gmail.com Tue Jul 9 07:18:13 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ADB021F9EC7 for ; Tue, 9 Jul 2013 07:18:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 zLyoya4twewg for ; Tue, 9 Jul 2013 07:18:12 -0700 (PDT) Received: from mail-ve0-x229.google.com (mail-ve0-x229.google.com [IPv6:2607:f8b0:400c:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 6488E21F9EC5 for ; Tue, 9 Jul 2013 07:18:12 -0700 (PDT) Received: by mail-ve0-f169.google.com with SMTP id m1so4689095ves.28 for ; Tue, 09 Jul 2013 07:18:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=l0IdYZ/pAdnjAI1B4vHV9QNXUPjPen7UJnUfCosfoYo=; b=zYUlYzvzWWYdv0oCjibD8rUEKhkLniRst6iaHO0MTbjd7bJaK3Fy2zjMN34uAphmCT 3ft/48SnFZ5kOBXMArzn1pKCEk717b091Esa2f8lxePv/MLJI94fd46wA7gU1nStbG1H QNEvbRd022hq6Vd3gRWmi2WGiuxwYfWj2DSK9YmfnVr8awpFXYdHDXViswwyPxS6OKNY RgbKOM2Ei7KVx7zeOjzIV9uu5n6A3EjObJql8FpqLhr0ogVtSPh+fqxuo0rufMY3ygX2 vIZ7wRnhE/Ekm0akhhvIhNlzQ7ZoWFdVPK9UlhL6pkQMRfuEwtq4WimawjQ7PN5gkYK6 kLNw== X-Received: by 10.220.47.131 with SMTP id n3mr16644144vcf.7.1373379491716; Tue, 09 Jul 2013 07:18:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.210.202 with HTTP; Tue, 9 Jul 2013 07:17:31 -0700 (PDT) From: Qiong Date: Tue, 9 Jul 2013 22:17:31 +0800 Message-ID: To: "behave@ietf.org" Content-Type: multipart/alternative; boundary=001a11c1f6c4bee57f04e114d405 Subject: [BEHAVE] Fwd: I-D Action: draft-sun-behave-v4tov6-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 14:18:13 -0000 --001a11c1f6c4bee57f04e114d405 Content-Type: text/plain; charset=UTF-8 Dear all, We have submitted a new draft for IPv4 client to IPv6 server. It is designed to cover the Scenario 2 in RFC6144. It can save the public IPv4 addresses consumed by IPv6 side and does not have impact on existing applications. Your comments/reviews are appreciated. Best wishes Qiong ---------- Forwarded message ---------- From: internet-drafts@ietf.org Date: Mon, 08 Jul 2013 08:16:36 -0700 Subject: I-D Action: draft-sun-behave-v4tov6-00.txt To: i-d-announce@ietf.org A new version of I-D, draft-sun-behave-v4tov6-00.txt has been successfully submitted by Chongfeng Xie and posted to the IETF repository. Filename: draft-sun-behave-v4tov6 Revision: 00 Title: The Approach for IPv4-only users to access IPv6-only Content Creation date: 2013-07-08 Group: Individual Submission Number of pages: 13 URL: http://www.ietf.org/internet-drafts/draft-sun-behave-v4tov6-00.txt Status: http://datatracker.ietf.org/doc/draft-sun-behave-v4tov6 Htmlized: http://tools.ietf.org/html/draft-sun-behave-v4tov6-00 Abstract: Current approaches can not solve the scenario that the users from IPv4 Internet to access IPv6-only content. When IPv6 content are becoming more and more popular, it is important to ensure that IPv6- only content can be reachable from legacy IPv4-only clients via some IPv4-only network. This document proposes two approaches for IPv4- only users to access IPv6-only content. It is designed to cover the Scenario 2 in [RFC6144]. The IETF Secretariat -- ============================================== Qiong Sun China Telecom Beijing Research Institute Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/* PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * =============================================== --001a11c1f6c4bee57f04e114d405 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear all,

We have submitted a new draft f= or IPv4 client to IPv6 server. It is designed to cover the Scenario=C2=A02= =C2=A0in RFC6144. It can save the public IPv4 addresses consumed by IPv6 si= de and does not have impact on existing applications.

Your comments/reviews are appreciated.

Best wishes
Qiong


---------- Forwarded message ----------
From:=C2=A0internet-drafts@ietf.org
Date: Mon, 08 J= ul 2013 08:16:36 -0700
Sub= ject: I-D Action:=C2=A0draft-sun-be= have-v4tov6-00.txt
To:=C2=A0i-d-announce@ietf.org

A=C2=A0new=C2=A0version=C2=A0of=C2=A0I-D,=C2=A0dr= aft-sun-behave-v4tov6-00.txt
has=C2=A0been=C2=A0successfully=C2=A0submitted=C2=A0by=C2=A0Chongfeng= =C2=A0Xie=C2=A0and=C2=A0posted=C2=A0to=C2=A0the
IETF=C2=A0repository.
=C2=A0
Filename: =C2=A0draft-sun-behave-v4tov6
Revision: =C2=A000
Title: =C2=A0The=C2=A0Approach=C2=A0for=C2=A0IPv4-only=C2=A0users=C2= =A0to=C2=A0access=C2=A0IPv6-only=C2=A0Content
Creation=C2=A0date: =C2=A02013-07-08
Group: =C2=A0Individual=C2=A0Submission
Number=C2=A0of=C2=A0pages:=C2=A013
=C2=A0
=C2=A0
Abstract:
=C2=A0=C2=A0=C2=A0Current=C2=A0approaches=C2=A0can=C2=A0not=C2=A0solve= =C2=A0the=C2=A0scenario=C2=A0that=C2=A0the=C2=A0users=C2=A0from
=C2=A0=C2=A0=C2=A0IPv4=C2=A0Internet=C2=A0to=C2=A0access=C2=A0IPv6-onl= y=C2=A0content.=C2=A0=C2=A0When=C2=A0IPv6=C2=A0content=C2=A0are
=C2=A0=C2=A0=C2=A0becoming=C2=A0more=C2=A0and=C2=A0more=C2=A0popular,= =C2=A0it=C2=A0is=C2=A0important=C2=A0to=C2=A0ensure=C2=A0that=C2=A0IPv6-
=C2=A0=C2=A0=C2=A0only=C2=A0content=C2=A0can=C2=A0be=C2=A0reachable=C2= =A0from=C2=A0legacy=C2=A0IPv4-only=C2=A0clients=C2=A0via=C2=A0some
=C2=A0=C2=A0=C2=A0IPv4-only=C2=A0network.=C2=A0=C2=A0This=C2=A0documen= t=C2=A0proposes=C2=A0two=C2=A0approaches=C2=A0for=C2=A0IPv4-
=C2=A0=C2=A0=C2=A0only=C2=A0users=C2=A0to=C2=A0access=C2=A0IPv6-only= =C2=A0content.=C2=A0=C2=A0It=C2=A0is=C2=A0designed=C2=A0to=C2=A0cover=C2=A0= the
=C2=A0=C2=A0=C2=A0Scenario=C2=A02=C2=A0in=C2=A0[RFC6144].
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
=C2=A0
=C2=A0
The=C2=A0IETF=C2=A0Secretariat

--
=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Qiong Sun
China T= elecom Beijing Research Institute


Open source code:
lightweig= ht 4over6: http://sourceforge.net/projects/laft6/
PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--001a11c1f6c4bee57f04e114d405-- From simon.perreault@viagenie.ca Wed Jul 10 06:52:01 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D62A221F9E94 for ; Wed, 10 Jul 2013 06:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.467 X-Spam-Level: X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=0.133, 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 1mN1qaV7jlQw for ; Wed, 10 Jul 2013 06:52:01 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id DBC7B21F9E88 for ; Wed, 10 Jul 2013 06:52:00 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:c15b:51e7:d305:cc6c]) by jazz.viagenie.ca (Postfix) with ESMTPSA id BEF8740430; Wed, 10 Jul 2013 09:51:59 -0400 (EDT) Message-ID: <51DD6700.10901@viagenie.ca> Date: Wed, 10 Jul 2013 15:52:00 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: ietfdbh References: <7bc37af6cf764c2e965778b6b265a2d4@BY2PR03MB269.namprd03.prod.outlook.com> <51A72041.6060208@viagenie.ca> <2d6b12df967d4faf8fcfd6d6891b2ca2@BN1PR03MB267.namprd03.prod.outlook.com> <51A8565B.5070700@viagenie.ca> <004a01ce5e05$6bf10c90$43d325b0$@comcast.net> In-Reply-To: <004a01ce5e05$6bf10c90$43d325b0$@comcast.net> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: draft-ietf-behave-nat-mib@tools.ietf.org, behave@ietf.org, 'Dave Thaler' Subject: Re: [BEHAVE] WGLC on draft-ietf-behave-nat-mib X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 13:52:02 -0000 Le 2013-05-31 15:47, ietfdbh a crit : > 1) A while back, I suggested that, if you are deprecating all of the NAT-MIB > in rfc4008, that it would be better to do this as a separate document from > the NEW-NAT-MIB (or whatever the new module gets called). Simon asked me to > get consensus from the MIB Doctors. > > I checked with the MIB Doctor list, and only got one reply - from Juergen, > who apparently recommended a single document. His response: > " I have probably been pushing them into this because at the beginning it > was not really clear why the existing NAT-MIB is fatally flawed such that it > needs a complete replacement. If the behave WG has meanwhile reached > consensus that indeed the existing NAT-MIB is fatally flawed and needs a > complete replacement, then indeed what you suggest makes sense. I assume the > WG has checked with those who have implementations of the existing NAT-MIB > (if any) that they agree on a need for a complete new MIB." I'm having trouble parsing this. Our position, and we feel we have the consensus of the WG with us, is that the existing NAT-MIB is fatally flawed and we need a complete replacement. The reasons are explained in section 3.1. https://tools.ietf.org/html/draft-ietf-behave-nat-mib-06#section-3.1 That's why we initially started with a brand new MIB, called the NEW-NAT-MIB. We changed into the current structure based on feedback from the working group in general and Juergen in particular. So, what would be your advice? > 2) Since deprecated objects are not obsoleted, I think new security > considerations might be called for relating to the deprecated objects - > especially if there are security implications of implementing BOTH the > current and deprecated objects. > > Some NMS applications will support only the old MIB module; others may > support only the new MIB module. Some agents will want to implement both, to > make their devices manageable from either type of NMS application. Some NMS > applications will want to support both, to deal with both legacy and new > agents. Totally agreed. > MIB modules often make information available that could potentially be used > by attackers. > Are there particular risks involved in exposing the information of these two > NAT-MIBs in combination? > Are there potential risks associated with the potential confusion of looking > at a NAT from the different perspectives used by these two NAT MIB > approaches? Well, I don't see any possible synergistic security hole that would be created by the combination of the old and new MIB. So I would be inclined to just creating new security considerations for the deprecated objects. > 3) I notice there is no "Operational Considerations" section. I wonder if > one is called for here, because operators may be faced with NMS applications > and/or agents that support both the deprecated and the new MIB module. What > should operators (and NMS applications) do with this potentially conflicting > information? What should they explicitly NOT do? E.g., What assumptions > should they NOT make about the relationships between specific objects in the > old and new versions? It's a good question, but I can't think of anything specific. I'll keep this in mind. > My impression is that the old and the new MIB modules might be appropriate > depending on the environment in which they exist, and the old MIB is > implemented (to whatever degree of compliance) in existing legacy devices, > so simply saying "never use the old MIB" is not going to be an acceptable > approach. Indeed. And that's not what the document says. Simon From j.schoenwaelder@jacobs-university.de Wed Jul 10 07:19:40 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F10221E8091 for ; Wed, 10 Jul 2013 07:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.089 X-Spam-Level: X-Spam-Status: No, score=-103.089 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4UZeY6aPcCM for ; Wed, 10 Jul 2013 07:19:36 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id E4EE721E808E for ; Wed, 10 Jul 2013 07:19:17 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id C40B420BDA; Wed, 10 Jul 2013 16:19:16 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id lNGzmF3HoFP6; Wed, 10 Jul 2013 16:19:16 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1C0BE2090B; Wed, 10 Jul 2013 16:19:15 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 292632730DEE; Wed, 10 Jul 2013 16:19:12 +0200 (CEST) Date: Wed, 10 Jul 2013 16:19:12 +0200 From: Juergen Schoenwaelder To: Simon Perreault Message-ID: <20130710141912.GA64394@elstar.local> Mail-Followup-To: Simon Perreault , ietfdbh , draft-ietf-behave-nat-mib@tools.ietf.org, behave@ietf.org, 'Dave Thaler' References: <7bc37af6cf764c2e965778b6b265a2d4@BY2PR03MB269.namprd03.prod.outlook.com> <51A72041.6060208@viagenie.ca> <2d6b12df967d4faf8fcfd6d6891b2ca2@BN1PR03MB267.namprd03.prod.outlook.com> <51A8565B.5070700@viagenie.ca> <004a01ce5e05$6bf10c90$43d325b0$@comcast.net> <51DD6700.10901@viagenie.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <51DD6700.10901@viagenie.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: draft-ietf-behave-nat-mib@tools.ietf.org, ietfdbh , 'Dave Thaler' , behave@ietf.org Subject: Re: [BEHAVE] WGLC on draft-ietf-behave-nat-mib X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 14:19:40 -0000 On Wed, Jul 10, 2013 at 03:52:00PM +0200, Simon Perreault wrote: > Le 2013-05-31 15:47, ietfdbh a crit : > > 1) A while back, I suggested that, if you are deprecating all of the NAT-MIB > > in rfc4008, that it would be better to do this as a separate document from > > the NEW-NAT-MIB (or whatever the new module gets called). Simon asked me to > > get consensus from the MIB Doctors. > > > > I checked with the MIB Doctor list, and only got one reply - from Juergen, > > who apparently recommended a single document. His response: > > " I have probably been pushing them into this because at the beginning it > > was not really clear why the existing NAT-MIB is fatally flawed such that it > > needs a complete replacement. If the behave WG has meanwhile reached > > consensus that indeed the existing NAT-MIB is fatally flawed and needs a > > complete replacement, then indeed what you suggest makes sense. I assume the > > WG has checked with those who have implementations of the existing NAT-MIB > > (if any) that they agree on a need for a complete new MIB." > > I'm having trouble parsing this. > > Our position, and we feel we have the consensus of the WG with us, is > that the existing NAT-MIB is fatally flawed and we need a complete > replacement. The reasons are explained in section 3.1. > https://tools.ietf.org/html/draft-ietf-behave-nat-mib-06#section-3.1 > > That's why we initially started with a brand new MIB, called the > NEW-NAT-MIB. We changed into the current structure based on feedback > from the working group in general and Juergen in particular. As far as I recall, it was initially not clear whether there is consensus that the NAT-MIB is fatally flawed. (And the text that is now in section 3.1 did not exist at that time in the current level of detail as far as I recall.) I suggest a consensus call is made by the chairs on this fundamental question. If there is consensus that the NAT-MIB is fatally flawed (and note that opinions of implementors in particular matter here), then declaring the MIB module in RFC 4008 historic (e.g. marking RFC 4008 historic) and creating a new MIB module may indeed be the right thing to do. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From trac+behave@trac.tools.ietf.org Wed Jul 10 13:53:08 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5D2821F9E52 for ; Wed, 10 Jul 2013 13:53:08 -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 TphAmHumQIDF for ; Wed, 10 Jul 2013 13:52:56 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id A67C621F9EC6 for ; Wed, 10 Jul 2013 13:52:52 -0700 (PDT) Received: from localhost ([127.0.0.1]:40506 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Ux1NW-00038n-Kn; Wed, 10 Jul 2013 22:52:46 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "behave issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-behave-nat-mib@tools.ietf.org, j.schoenwaelder@jacobs-university.de X-Trac-Project: behave Date: Wed, 10 Jul 2013 20:52:46 -0000 X-URL: http://tools.ietf.org/wg/behave/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/behave/trac/ticket/19 Message-ID: <080.384a977c63e7c9bb6aa8d09e46f079ac@trac.tools.ietf.org> X-Trac-Ticket-ID: 19 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-behave-nat-mib@tools.ietf.org, j.schoenwaelder@jacobs-university.de, behave@ietf.org X-SA-Exim-Mail-From: trac+behave@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: simon.perreault@viagenie.ca, ssenthil@cisco.com, tina.tsou.zouting@huawei.com Resent-Message-Id: <20130710205252.A67C621F9EC6@ietfa.amsl.com> Resent-Date: Wed, 10 Jul 2013 13:52:52 -0700 (PDT) Resent-From: trac+behave@trac.tools.ietf.org Cc: behave@ietf.org Subject: [BEHAVE] [behave] #19: Juergen's comments on new MIB module vs update existing MIB module X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Reply-To: behave@ietf.org List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 20:53:09 -0000 #19: Juergen's comments on new MIB module vs update existing MIB module As far as I recall, it was initially not clear whether there is consensus that the NAT-MIB is fatally flawed. (And the text that is now in section 3.1 did not exist at that time in the current level of detail as far as I recall.) I suggest a consensus call is made by the chairs on this fundamental question. If there is consensus that the NAT-MIB is fatally flawed (and note that opinions of implementors in particular matter here), then declaring the MIB module in RFC 4008 historic (e.g. marking RFC 4008 historic) and creating a new MIB module may indeed be the right thing to do. -- -------------------------------------+------------------------------------- Reporter: j.schoenwaelder@jacobs- | Owner: draft-ietf-behave-nat- university.de | mib@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: milestone1 Component: nat-mib | Version: -06 Severity: In WG Last Call | Keywords: -------------------------------------+------------------------------------- Ticket URL: behave From tireddy@cisco.com Thu Jul 11 22:06:28 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFA0B21F99A8 for ; Thu, 11 Jul 2013 22:06:28 -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 TihBhtMAFqbe for ; Thu, 11 Jul 2013 22:06:23 -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 18F5B21F99A9 for ; Thu, 11 Jul 2013 22:06:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2348; q=dns/txt; s=iport; t=1373605575; x=1374815175; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=hRADHERQh/gJd1k3LsYZ/zGjXqO6lg31us/mbSAk+7s=; b=FRbwHNg9b7SfcY158ucl56Cy2GKFQilom3pzPRDwXam/ETNBMnrFbBuy 1b0Q8HYYxgZJDOh61DU5JM0eA1EeXFJP7Z9qptJdXS26X6Lu6qGQH2mHV be3oG0FtQPE74mWqXq4qVqDhvXRiD6bP8mapR4Uvk0/DPY7q+iXCYfm1t k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFACKO31GtJV2b/2dsb2JhbABagwY0T8FQgQcWdIIjAQEBBAEBATc0CwwEAgEIEQMBAQELFAkHIQYLFAkIAgQBDQUIAYd0Aw8MrjUNiF6MeII4MQIFBoMDbAOVc4MTin4DhSODEYIo X-IronPort-AV: E=Sophos;i="4.89,650,1367971200"; d="scan'208";a="233879283" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 12 Jul 2013 05:06:11 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r6C56BtE006738 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Jul 2013 05:06:11 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Fri, 12 Jul 2013 00:06:10 -0500 From: "Tirumaleswar Reddy (tireddy)" To: GangChen , Behave WG Thread-Topic: [BEHAVE] Fwd: I-D Action: draft-chen-behave-nat64-radius-extension-00.txt Thread-Index: AQHOfNa30jhfjjzeGkCsnMI500GMZJlgfALg Date: Fri, 12 Jul 2013 05:06:09 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A14B9815A@xmb-rcd-x10.cisco.com> References: <20130708151636.25487.48986.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.69.243] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mohamed.boucadair@orange.com" Subject: Re: [BEHAVE] Fwd: I-D Action: draft-chen-behave-nat64-radius-extension-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 05:06:29 -0000 Hi Gang, The problems mentioned in the draft can also be solved using PCP QUERY opco= de introduced in http://tools.ietf.org/html/draft-boucadair-pcp-nat-reveal-= 01 --Tiru. > -----Original Message----- > From: GangChen [mailto:phdgang@gmail.com] > Sent: Tuesday, July 09, 2013 11:54 AM > To: Behave WG > Subject: [BEHAVE] Fwd: I-D Action: draft-chen-behave-nat64-radius-extensi= on- > 00.txt >=20 > wg, >=20 > We just uploaded the draft-chen-behave-nat64-radius-extension-00 > The draft proposes new Radius attributes to convey IPv6 source > addresses when a NAT64 is deployed. >=20 > Your comments/reviews are appreciated. >=20 > Best Regards >=20 > Gang >=20 > ---------- Forwarded message ---------- > From: internet-drafts@ietf.org > Date: Mon, 08 Jul 2013 08:16:36 -0700 > Subject: I-D Action: draft-chen-behave-nat64-radius-extension-00.txt > To: i-d-announce@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >=20 >=20 > Title : Radius Attributes for Stateful NAT64 > Author(s) : Gang Chen > David Binet > Filename : draft-chen-behave-nat64-radius-extension-00.txt > Pages : 10 > Date : 2013-07-08 >=20 > Abstract: > This document proposes new radius attributes for stateful NAT64. The > extensions are used to provide geo-location services with an exact > IPv6 soruce address. The message flow to deliver the NAT64 binding > information between radius clients and servers is also described. > Therefore, accurate location could be traced out depending on the > radius method. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-chen-behave-nat64-radius-extension >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-chen-behave-nat64-radius-extension-00 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From internet-drafts@ietf.org Sun Jul 14 19:16:58 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B08621F9D38; Sun, 14 Jul 2013 19:16:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.061, 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 S346YCRVBEpF; Sun, 14 Jul 2013 19:16:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E4FD21F9CA0; Sun, 14 Jul 2013 19:16:58 -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.51.p2 Message-ID: <20130715021657.24315.36123.idtracker@ietfa.amsl.com> Date: Sun, 14 Jul 2013 19:16:57 -0700 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action: draft-ietf-behave-syslog-nat-logging-02.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 02:16:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Behavior Engineering for Hindrance Avoida= nce Working Group of the IETF. Title : Syslog Format for NAT Logging Author(s) : Zhonghua Chen Cathy Zhou Tina Tsou T. Taylor Filename : draft-ietf-behave-syslog-nat-logging-02.txt Pages : 26 Date : 2013-07-14 Abstract: With the wide deployment of Carrier Grade NAT (CGN) devices, the logging of NAT-related events has become very important for various operational purposes. The logs may be required for troubleshooting, to identify a host that was used to launch malicious attacks, and/or for accounting purposes. This document identifies the events that need to be logged and the parameters that are required in the logs depending on the context in which the NAT is being used. It goes on to standardize formats for reporting these events and parameters using SYSLOG (RFC 5424). A companion document specifies formats for reporting the same events and parameters using IPFIX (RFC 5101). Applicability statements are provided in this document and its companion to guide operators and implementors in their choice of which technology to use for logging. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-behave-syslog-nat-logging There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-behave-syslog-nat-logging-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-behave-syslog-nat-logging-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From tom.taylor.stds@gmail.com Sun Jul 14 19:17:24 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4F9321F9CA0 for ; Sun, 14 Jul 2013 19:17:24 -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 8RuWGGV2TcYx for ; Sun, 14 Jul 2013 19:17:23 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 95F9821F9BA2 for ; Sun, 14 Jul 2013 19:17:23 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id aq17so23512196iec.8 for ; Sun, 14 Jul 2013 19:17:23 -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; bh=PzfDXyxvKZA++O+Ld/p7BuTEmeBD47cBjBtZRxTN1So=; b=S72/ENaPFLhYEkTU7Vyy+kmtWDgHm9pxO0KYzA1TjR4NVgn3UKDbLbhRRIGPPolS8X IYTXZKpUZKQYhxLMrZ81xvgIOaIucWhE9ZBG6FxVi5a3uu+vb9FniUfnBrm9X24iR9xu 9nPqM19Lx7B3gGI/rmleMc5LorRS008PVHLBZ35tzVXOPhtIUNj2pJzWPqwwQCgCWgX1 W7Bv958YwhmKZLPwCmKFFLNaWrU4E+h09unU+ARBp3rn8ax+l00K5CrdXaTq5WsO/r73 PyCWWM6vQ4OlH3nsg33GbHKWzBkAOH8D6907ewcGb0CJeCWrDgCJsE8r3lhnxChfUsBR tWBg== X-Received: by 10.50.120.103 with SMTP id lb7mr5860913igb.14.1373854643159; Sun, 14 Jul 2013 19:17:23 -0700 (PDT) Received: from [192.168.1.64] ([216.254.161.150]) by mx.google.com with ESMTPSA id r6sm15684430igp.8.2013.07.14.19.17.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 14 Jul 2013 19:17:22 -0700 (PDT) Message-ID: <51E35BB2.3010609@gmail.com> Date: Sun, 14 Jul 2013 22:17:22 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Dan Wing References: <20130508154447.24024.36769.idtracker@ietfa.amsl.com> <518A757F.5000701@gmail.com> <6ACBECAC-F476-4947-8F02-FC267403219C@cisco.com> In-Reply-To: <6ACBECAC-F476-4947-8F02-FC267403219C@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: behave@ietf.org Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-syslog-nat-logging-01.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 02:17:25 -0000 This is a report on what I changed in response to your review. Thank you very much for your time and expertise. On 20/05/2013 9:56 PM, Dan Wing wrote: > Thanks for writing this document. > > My personal review, not as chair, > > Section 2.1 seems to be trying to distinguish between mechanisms that > are dynamic and those that are static. Static are DS-Lite with > [I-D.tsou-behave-natx4-log-reduction] and [I-D.pcp-port-set], MAP-E, > and lightweight 4over6. Dynamic is dynamic. Then there is the > combination, which is popularly described in > draft-donley-behave-deterministic-cgn. I would suggest separate > sections explaining these three things, and more concisely. Also, > Section 2.1 is titled "NAT Logging Requirements For Different > Transition Methods" and has 3 paragraphs describing MAP-E, which does > not do network address translation in the ISP's network; a different > title for the section that discusses MAP-E seems useful. Afterall, > with MAP-E the NAT function occurs in the customer premise NAT, which > is not going to generate logging messages. [PTT] Rewrote with 2.1 talking about static, dynamic, and hybrid, and 2.2 still talking about transition methods but with reference to 2.1. Dropped 2.3. It seems Section 2 might > be something we would want common between the SYSLOG and IPFIX > documents, perhaps? [PTT] I am hoping both Section 2 and Section 3 could be common once we get them in shape. > > I noticed the non-normative "Note:" regarding Gateway-Initiated > DS-Lite underneath Figure 1. Can that be moved to somewhere else so > it is more normative? (It looks like a centered ). > Perhaps it should be explained in Section 2.1, rather than here. [PTT] Explicitly accounted for when talking about the general-purpose subscriber site identifier in the introductory part of Section 3. > > In Figure 1, can the user identifier be generalized a bit? There are > lots of NATs which use interface identifiers (e.g., en0, en1, en2), > VLAN IDs, VRFs, to separate the inside addresses -- rather than using > the fields shown here in Figure 1. This seems to have happened in > Section 3.1 (which shows VLAN ID and VRFs) but the table does not > appear to allow that sort of flexibility. > [PTT] Done. I expect leaving the exact contents to implementation/deployment (current position) will be a matter of discussion. Section 3 does suggest what should theoretically be reported. > > Section 3.1, "NAT session creation and deletion events are recorded > when a binding to a specific destination address and port is recorded > in or deleted from the session database. See the discussion in > Section 3 of [RFC6146]." > > That does not align with the endpoint-independent mapping described > in Section 3 of RFC6146. That is, a 'creation' event does not occur > with every new destination address. > > I found Section 3.1 really difficult to understand what is generated > for a TCP/UDP mapping, versus what is supposed to be generated for an > ICMP mapping. [PTT] This may still be an open issue. Have to review. > > " o Destination IPv4 (for NAT44) or IPv6 (for NAT64) address > (OPTIONAL);" > > A NAT64 would have an IPv4 destination address. Note this is for > *destination logging*, which needs its own discussion beyond just > "(OPTIONAL)" and beyond the citation that RFC6888 recommends against > destination logging. There are implementation issues with > destination logging (state creation in the logging device to avoid > generating a log event with every packet), and it deserves mentioning > in a logging document that destination logging more than destroys the > log reduction benefit of bulk port assignment. > > > " o Post-NAT destination IPv4 address (OPTIONAL);" > > Seems redundant with the preceding item. > > "The pre-NAT value of destination address will differ from the > post-NAT value only in a double-NAT situation. Hence in most cases > even with destination logging the pre-NAT value will not be > recorded." > > I don't understand what that means. Please make it clearer in the > document. This is the first and only time the term "double-NAT" > appears in the document, which might be part of my confusion. [PTT] Dropped destination logging from the session creation/deletion events. This made them identical to the BIB entry events, so I dropped the latter. Added a sub-section of 3.1 explaining why destination logging would be so rare as to not merit standardization. > > > Section 3.4 says: "The same allocation applies to each protocol > supported by the NAT." -> but you really only mean UDP and TCP, even > though the NAT supports ICMP (which doesn't use ports) or even if it > were to support SCTP (which does not expect NAPT devices to rewrite > port numbers). So, please say "The same ports are allocated for TCP > and UDP." [PTT] Done. > > Section 3.4, why are the starting and ending port numbers optional, > can this work? > > Section 3.4, the Port Range Size and Range Step are too complicated. > Are > > Section 3.4 needs to explain if the same single logging event will be > generated when ports are deleted, or if they are consolidated. For > example, let's say ports 100-200 are allocated to a subscriber and a > logging event generated, then ports 200-250 are (later) allocated to > the same subscriber and a logging event generated. Will that second > logging event indicate ports 100-250? (I could see someone > reasonably implementing that). Would two separate deletion log > events be generated, one deletion for 100-200, and another deletion > for 201-250? Or would only one log deletion event be generated? All > of these corner cases need discussion with some rules for how this is > expected to work. This could perhaps be left to implementation > decision, but if that is the decision it should clearly say. [PTT] I realized there are even more potential complications than you have pointed out. Evaded all of them by redefining the log as a "Port Allocation Change" event, with a full report of the current allocation at the time of reporting. Added text to allow range consolidation. > > General comment for all of sections 3.5, 3.6, and 3.7: Can a SYSLOG > message be generated *before* we hit a limit? It seems there is no > highwater mark for any of those. I expect operators would prefer > knowing before hitting a limit and also when hitting a limit (because > users will notice the hard failure when a limit is hit). Thoughts? [PTT] I think Senthil answered this, but the first line of defense is the Quota event. > > "3.5. NAT Address Exhaustion Event", is there expected to be > anything to prevent this event from being continually generated? > Because, if the NAT is running near its limit and hits it, it will > likely have a port released, then one allocated (hitting the limit > again), over and over again. Same question for Section 3.4 (port > exhaustion). And, are both events generated when the final port is > allocated (seems like both would be generated). [PTT] For this and other error conditions, added text requiring implementations to provide the capability for event-specific rate limiting. > > Section 3.7, Quota exhausted -- for the (per-user) quota a citation > to REQ-11 of RFC6888 would be helpful. I found the paragraph > describing which fields are mandatory for which sort of quota > difficult to understand. I played around with a table (which did not > help clarity) and some alternative wording. But I couldn't improve > the text much, because I don't really know what fields are best to > send for the different sort of events. This feels very free-form and > a cause of interoperability problems with the various ways a NAT or > the SYSLOG parsing code would interpret the presence of certain > fields. For example, does the lack of a subscriber-identifying > address mean that a non-subscriber-specific administrative limit was > hit? It seems that is the case, which is okay, but more explicit > explanation could be helpful. Or creating separate events like was > done with 3.5 and 3.6 [PTT] Refactored the parameters to make things more understandable. Instead of QTyp, now have site scope (single, multiple, all) and protocol scope (TCP, UDP, ICMP, all). > > Section 5.2.1, "NTyp: NAT Type" where it mentions NAT44 it should > cite the canonical NAPT44 definition in RFC3022. For NAT64, probably > want to reference both stateful NAT64 (RFC6146) and stateless > (RFC6145). [PTT] Done. Also decided (absent input to the contrary) that no one would monitor logs at a universal CPE, so dropped that. Added the LW4over6 and MAP-E BR, hence renamed the field "Device Type" rather than "NAT Type". > > 5.2.5. PreS4: Pre-NAT IPv4 Source Address > > PARAM-VALUE: part or all of an IPv4 address, represented in dotted > decimal form. > > Why provide only part of the IPv4 address? For on-the-wire > efficiency? If some of the address is omitted, is it the first NNN > bits that are omitted, or the last NNN bits that are omitted. I > would omit the first NNN bits if all the internal addresses shared > those same NNN bits (e.g., all were 100.64/10, I could omit the first > 10 bits). I would omit the last NNN bits if assigning a /24 to a > subscriber and I don't care which of their devices caused the NAT > event. [PTT] Made PostS4 the full IPv4 address. All the Pre- addresses are absorbed into the general purpose SiteID. > > 5.2.6. PreS6: Pre-NAT IPv6 Source Address: "PARAM-VALUE: Part or > all of an IPv6 address, represented in the form specified by [ > RFC5952]." > > Same question -- the first part or the last part of the address? > Most subscribers are assigned a /64, so reporting the full 128 bit > address is awkward, I agree. But, similarly, most of an ISP's > network will use the same IPv6 prefix so reporting the first 8 or 24 > bits is redundant. The document needs to clarify. > > And as this is string-encoded, what rules should be followed for > "::", as that has changed in the last couple of years and would be > good to cite. [PTT] Absorbed into SiteID, which is left to local implementation with the requirement that it be a human-readable string. > > In IANA considerations a new IANA registry is created. This needs to > additionally provide guidance for how that new registry can be > extended in teh future, and a few other things. RFC5226 has details. [PTT] It already says "IETF Review", since I expect the IETF wants a strong say on what might be added (e.g., "66"). Is any more needed? > > Security considerations: > > " When logs are being recorded for regulatory reasons, preservation > of their integrity and authentication of their origin is essential." > > The accuracy and unambiguity of the information is important, as > well. To that point, the address compression has me concerned and > address compression needs more text in the document, and may deserve > calling out explicitly in the security considerations section. Also > worth pointing out is the address ranges and "step range" (whatever > that is) might be changed while the NAT is operating -- which impacts > almost everything reported to the SYSLOG server. Seems useful to add > NAT Configuration Changed events when such things occur? > > In security considerations, missing messages are not mentioned. They > should be. Would it be worthwhile to include a sequence number > (which does not appear to be part of the SYSLOG header, nor of the > messages defined in this spec.) [PTT] Haven't dealt with this yet. > > -d ... From phdgang@gmail.com Sun Jul 14 19:41:53 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEBF821F9950 for ; Sun, 14 Jul 2013 19:41:53 -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 DRrV7F3uOota for ; Sun, 14 Jul 2013 19:41:53 -0700 (PDT) Received: from mail-qe0-x22d.google.com (mail-qe0-x22d.google.com [IPv6:2607:f8b0:400d:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id B3E3B21F9CEF for ; Sun, 14 Jul 2013 19:41:51 -0700 (PDT) Received: by mail-qe0-f45.google.com with SMTP id w7so6156149qeb.4 for ; Sun, 14 Jul 2013 19:41: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=yWXkEBP9fpb2kZlwFcCucuzg/clOTblz893LSsM/5Zs=; b=Oooxeclrqm9+rhFe6csVLrM8PkzgQVOU0F3qSMzK6T9DToTVww6CdBYeT4wAgQMEaP mwDC4MhMiXYwbahgSaZjJAtOLB9I5vL03OccNDOES6iQmZfmc2hW4UCJsWXGKWsEteSn wQpG1ueCcz0YRWNDTpyARCjTAwsRTW+DfsBvyE6ItS4mzT6vMOJaGgESzI2DPda5eKIi DF0HV9cssvvvZlunPQQxY1um9p42ngx546crtiDA9pW66w6XlMNvLizJWvSzpMh6bS2A 4pu4kK+xP+WukJnM5neR4FUSye9jHP6j9bWL10I+lglw4XZztt8e0TeDxrsvzHyFrWvf AQ2Q== MIME-Version: 1.0 X-Received: by 10.224.212.199 with SMTP id gt7mr50269091qab.80.1373856110153; Sun, 14 Jul 2013 19:41:50 -0700 (PDT) Received: by 10.224.182.74 with HTTP; Sun, 14 Jul 2013 19:41:50 -0700 (PDT) In-Reply-To: <913383AAA69FF945B8F946018B75898A14B9815A@xmb-rcd-x10.cisco.com> References: <20130708151636.25487.48986.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A14B9815A@xmb-rcd-x10.cisco.com> Date: Mon, 15 Jul 2013 10:41:50 +0800 Message-ID: From: GangChen To: "Tirumaleswar Reddy (tireddy)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "mohamed.boucadair@orange.com" , Behave WG Subject: Re: [BEHAVE] Fwd: I-D Action: draft-chen-behave-nat64-radius-extension-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 02:41:53 -0000 Hi Tiru, You are right. Please check the sentence in the draft "It's also possible to extend Port Control Protocol (PCP) to support those network information queries from external servers. ....." The radius-based proposal intended to fit into the environment, where geo-location system is already deployed based on a radius database[RFC5580]. Some benefits have been described related to this context. 1) radius-based solution would be a in-band solution 2) fewer impacts to NAT64 performance because the process is independent with NAT64 translation BRs Gang 2013/7/12, Tirumaleswar Reddy (tireddy) : > Hi Gang, > > The problems mentioned in the draft can also be solved using PCP QUERY > opcode introduced in > http://tools.ietf.org/html/draft-boucadair-pcp-nat-reveal-01 > > --Tiru. > >> -----Original Message----- >> From: GangChen [mailto:phdgang@gmail.com] >> Sent: Tuesday, July 09, 2013 11:54 AM >> To: Behave WG >> Subject: [BEHAVE] Fwd: I-D Action: >> draft-chen-behave-nat64-radius-extension- >> 00.txt >> >> wg, >> >> We just uploaded the draft-chen-behave-nat64-radius-extension-00 >> The draft proposes new Radius attributes to convey IPv6 source >> addresses when a NAT64 is deployed. >> >> Your comments/reviews are appreciated. >> >> Best Regards >> >> Gang >> >> ---------- Forwarded message ---------- >> From: internet-drafts@ietf.org >> Date: Mon, 08 Jul 2013 08:16:36 -0700 >> Subject: I-D Action: draft-chen-behave-nat64-radius-extension-00.txt >> To: i-d-announce@ietf.org >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : Radius Attributes for Stateful NAT64 >> Author(s) : Gang Chen >> David Binet >> Filename : draft-chen-behave-nat64-radius-extension-00.txt >> Pages : 10 >> Date : 2013-07-08 >> >> Abstract: >> This document proposes new radius attributes for stateful NAT64. The >> extensions are used to provide geo-location services with an exact >> IPv6 soruce address. The message flow to deliver the NAT64 binding >> information between radius clients and servers is also described. >> Therefore, accurate location could be traced out depending on the >> radius method. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-chen-behave-nat64-radius-extension >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-chen-behave-nat64-radius-extension-00 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > From internet-drafts@ietf.org Mon Jul 15 02:43:37 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65F9D21F9ECF; Mon, 15 Jul 2013 02:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.062, 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 BBqikbk3Jcrg; Mon, 15 Jul 2013 02:43:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D30321F95EF; Mon, 15 Jul 2013 02:43:27 -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.51.p2 Message-ID: <20130715094308.13253.79373.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 02:43:08 -0700 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action: draft-ietf-behave-nat-mib-07.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 09:43:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Behavior Engineering for Hindrance Avoida= nce Working Group of the IETF. Title : Additional Managed Objects for Network Address Translato= rs (NAT) Author(s) : Simon Perreault Tina Tsou Senthil Sivakumar Filename : draft-ietf-behave-nat-mib-07.txt Pages : 82 Date : 2013-07-15 Abstract: This memo defines a portion of the Management Information Base (MIB) for devices implementing Network Address Translator (NAT) function. This MIB module may be used for monitoring of a device capable of NAT function. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-behave-nat-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-behave-nat-mib-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-behave-nat-mib-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From meng.wei2@zte.com.cn Mon Jul 15 02:44:10 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 071CD21F9F2D for ; Mon, 15 Jul 2013 02:44:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.175 X-Spam-Level: X-Spam-Status: No, score=-101.175 tagged_above=-999 required=5 tests=[AWL=1.423, 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 XB0X8vc+x6vi for ; Mon, 15 Jul 2013 02:44:04 -0700 (PDT) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 30CAE21F9ED3 for ; Mon, 15 Jul 2013 02:44:01 -0700 (PDT) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 15E5412CA797 for ; Mon, 15 Jul 2013 17:43:31 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id r6F9hQim086751 for ; Mon, 15 Jul 2013 17:43:29 +0800 (GMT-8) (envelope-from meng.wei2@zte.com.cn) In-Reply-To: To: behave@ietf.org MIME-Version: 1.0 X-KeepSent: 36CCC8D7:D36790EB-48257BA9:0034A5D5; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: meng.wei2@zte.com.cn Date: Mon, 15 Jul 2013 17:43:27 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2013-07-15 17:43:27, Serialize complete at 2013-07-15 17:43:27 Content-Type: multipart/alternative; boundary="=_alternative 00357F9148257BA9_=" X-MAIL: mse01.zte.com.cn r6F9hQim086751 Subject: [BEHAVE] NAPGT request for comments, THANKS! X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 09:44:10 -0000 This is a multipart message in MIME format. --=_alternative 00357F9148257BA9_= Content-Type: text/plain; charset="US-ASCII" Hi all, I have submitted a new draft. The objective is to solve a problem that prevents an external client from accessing an internal server. https://datatracker.ietf.org/doc/draft-meng-behave-napgt/ I expect your comments. Thanks a lot! Cheers, Wei --=_alternative 00357F9148257BA9_= Content-Type: text/html; charset="US-ASCII"
Hi all,

    I have submitted a new draft. The objective is to solve a problem that
    prevents an external client from accessing an internal server.

    https://datatracker.ietf.org/doc/draft-meng-behave-napgt/

    I expect your comments. Thanks a lot!

Cheers,
Wei
--=_alternative 00357F9148257BA9_=-- From simon.perreault@viagenie.ca Mon Jul 15 02:50:07 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 176C921F9FDA for ; Mon, 15 Jul 2013 02:50:07 -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 e1MxgzJK7zqq for ; Mon, 15 Jul 2013 02:50:06 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 018AF21F9703 for ; Mon, 15 Jul 2013 02:50:06 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:5b8:1f9e:c21b:48d7]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 45533403FF for ; Mon, 15 Jul 2013 05:50:05 -0400 (EDT) Message-ID: <51E3C5CE.1090500@viagenie.ca> Date: Mon, 15 Jul 2013 11:50:06 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: behave@ietf.org References: <20130715094308.13253.79373.idtracker@ietfa.amsl.com> In-Reply-To: <20130715094308.13253.79373.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-nat-mib-07.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 09:50:08 -0000 This verision fixes many issues noted by David Harrington, Dave Thaler, and Dan Wing. To our knowledge, two issues remain: a) Do we need a separate MIB or do we update the one from 4008? Aka "the Juergen conundrum". http://trac.tools.ietf.org/wg/behave/trac/ticket/19 b) We're missing security considerations for the deprecated objects. That depends on resolution of issue a). We expect them to be resolved in Berlin. Simon Le 2013-07-15 11:43, internet-drafts@ietf.org a crit : > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. > > Title : Additional Managed Objects for Network Address Translators (NAT) > Author(s) : Simon Perreault > Tina Tsou > Senthil Sivakumar > Filename : draft-ietf-behave-nat-mib-07.txt > Pages : 82 > Date : 2013-07-15 > > Abstract: > This memo defines a portion of the Management Information Base (MIB) > for devices implementing Network Address Translator (NAT) function. > This MIB module may be used for monitoring of a device capable of NAT > function. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-behave-nat-mib > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-behave-nat-mib-07 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-behave-nat-mib-07 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From mperumal@cisco.com Mon Jul 15 11:42:40 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C5B111E817C for ; Mon, 15 Jul 2013 11:42:40 -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 LZ4PGdZfQvgv for ; Mon, 15 Jul 2013 11:42:35 -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 BB2C311E8179 for ; Mon, 15 Jul 2013 11:42:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2064; q=dns/txt; s=iport; t=1373913755; x=1375123355; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=kwX7kO4Hm1HZuUZy8C7jxt20NftWDf2R2fEcYvBfr+c=; b=VeIwUY2pqJixOq+rx2JZ7+eJUuZ9yD7H5pMxROgyOcul+vMVHNHbIvCl 79DXrRD8DjRCk5+/AR/KfIrTihDtWBtMerBd+quAQt6dAJ+gbAPRp6fJh VHz1jdCa/Y7uZeElGzKjxnpt8LAhQSvX+9WXA1+x2HdYNzmNHm5FGq7qY I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FABxC5FGtJXHB/2dsb2JhbABagwY0SQbBUoETFnSCIwEBAQQBAQE3NBcEAgEIEQQBAQsUCQcnCxQHAQEFAwIEEwgBiAcHBbVzjzMzBQaDBW0DmQWLAYUjgxKCKA X-IronPort-AV: E=Sophos;i="4.89,670,1367971200"; d="scan'208";a="235089966" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-3.cisco.com with ESMTP; 15 Jul 2013 18:42:35 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r6FIgZ1X001809 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 15 Jul 2013 18:42:35 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.192]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.02.0318.004; Mon, 15 Jul 2013 13:42:34 -0500 From: "Muthu Arul Mozhi Perumal (mperumal)" To: "behave@ietf.org" Thread-Topic: I-D Action: draft-muthu-behave-consent-freshness-04.txt Thread-Index: AQHOgYIhJ+v92XkONkuATNVM7xrPPZlmEicg Date: Mon, 15 Jul 2013 18:42:34 +0000 Message-ID: References: <20130715173816.18605.12504.idtracker@ietfa.amsl.com> In-Reply-To: <20130715173816.18605.12504.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.56.130] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 18:42:40 -0000 The text and the algorithm in the draft are significantly simplified in thi= s updated version.=20 Comments welcome.. - Authors -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] = On Behalf Of internet-drafts@ietf.org Sent: Monday, July 15, 2013 11:08 PM To: i-d-announce@ietf.org Subject: I-D Action: draft-muthu-behave-consent-freshness-04.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : STUN Usage for Consent Freshness Author(s) : Muthu Arul Mozhi Perumal Dan Wing Ram Mohan Ravindranath Tirumaleswar Reddy Filename : draft-muthu-behave-consent-freshness-04.txt Pages : 7 Date : 2013-07-15 Abstract: Verification of peer consent before sending traffic is necessary in WebRTC deployments to ensure that a malicious JavaScript cannot use the browser as a platform for launching attacks. A related problem is session liveness. WebRTC application may want to detect connection failure and take appropriate action. This document describes how a WebRTC browser can verify peer consent to continue sending traffic and detect connection failure. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-muthu-behave-consent-freshness There's also a htmlized version available at: http://tools.ietf.org/html/draft-muthu-behave-consent-freshness-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-muthu-behave-consent-freshness-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From simon.perreault@viagenie.ca Tue Jul 16 02:35:03 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF8E821E81D7 for ; Tue, 16 Jul 2013 02:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.23 X-Spam-Level: X-Spam-Status: No, score=-2.23 tagged_above=-999 required=5 tests=[AWL=-0.231, BAYES_00=-2.599, J_CHICKENPOX_54=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 3-+KrcgkmiTm for ; Tue, 16 Jul 2013 02:35:03 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 853DC21E81E0 for ; Tue, 16 Jul 2013 02:34:56 -0700 (PDT) Received: from [127.0.0.1] (h228.viagenie.ca [206.123.31.228]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 5141D470FB for ; Tue, 16 Jul 2013 05:34:55 -0400 (EDT) Message-ID: <51E513BF.2040405@viagenie.ca> Date: Tue, 16 Jul 2013 11:34:55 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: behave@ietf.org References: <20130715173816.18605.12504.idtracker@ietfa.amsl.com> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 09:35:04 -0000 Le 2013-07-15 20:42, Muthu Arul Mozhi Perumal (mperumal) a crit : > The text and the algorithm in the draft are significantly simplified in this updated version. > > Comments welcome.. MUCH better introduction. Now I feel like I understand the need exactly. The "Design Considerations" section is still very confusing to me. > Though ICE specifies STUN Binding indications to be used for > keepalives, it requires that an agent be prepared to receive > connectivity check as well. If a connectivity check is received, a > response is generated, but there is no impact on ICE processing, as > described in section 10 of [RFC5245]. ...so? Why is "an impact on ICE processing" necessary? > While a WebRTC browser could verify whether the peer continues to > send SRTCP reports before sending traffic to the peer, the usage of > SRTCP together with Security Descriptions [RFC4568] requires exposing > the media keys to the JavaScript and renders SRTCP unsuitable for > consent freshness. Why does it "require exposing the media keys to the JavaScript"? Is this because of a law of nature, or is it because of the way the JavaScript API is being designed? Could the JS API be changed to accommodate SRTCP+SDES? > For consent, calculating the SHA1 HMAC is necessary for MESSAGE- > INTEGRITY which is computationally expensive. You need to qualify "expensive". It's certainly not expensive in all cases. > Security analysis > concluded that the STUN 96 bits transaction ID is sufficient for > consent, without needing MESSAGE-INTEGRITY. What analysis? You would need to explain it in detail. But if that's not part of your suggested solution, just remove the sentence. Now on to section "4. Solution Overview"... > Every Tc seconds, the WebRTC browser sends a STUN Binding Request to > the peer. This request MUST use a new, cryptographically random > Transaction ID [RFC4086], and is formatted as for an ICE connectivity > check [RFC5245]. A valid STUN Binding Response is also formatted as > for an ICE connectivity check [RFC5245]. The STUN Binding Request > and STUN Binding Response are validated as for an ICE connectivity > check [RFC5245]. Couldn't this whole paragraph be simplified to "Every Tc seconds, the WebRTC browser sends an ICE connectivity check."? Is there anything new here besides the "every Tc" thing? > Liveness timer: If no packets have been received on the local port in > Tr seconds, the WebRTC browser MUST inform the JavaScript that > connectivity has been lost. The JavaScript application will use this > notification however it desires (e.g., cease transmitting to the > remote peer, provide a notification to the user, etc.). This seems to me like it will not fulfill the goal set in the abstract: "to ensure that a malicious JavaScript cannot use the browser as a platform for launching attacks". If the JavaScript is free to ignore the notification from the browser, then it has no security benefits. If you want to reach that goal, the browser needs to forcefully stop transmitting. > When not actively sending traffic on a nominated candidate pair, > performing consent freshness does not serve any purpose from a > security perspective. I don't understand what this means. Why is the "security perspective" important here? Aren't we concerned about keepalives? > In ICE [RFC5245] the STUN request/response are protected with > MESSAGE-INTEGRITY, using an ephemeral username and password exchanged > in the SDP ice-ufrag and ice-pwd attributes. This prevents ICE from > accidentally connecting to an in-intended peer, in that ICE will only > connect to a peer that also knows the same username and password > (exchanged in call signaling). Once that connection to the remote > peer has been established with ICE, the consent to continue sending > traffic does not benefit from re-asserting that same username and > password, so long as the senders and receiver's IP addresses remain > the same (as they usually do). I had not understood from the text that there was no auth stuff in the request. The text said "This request [...] is formatted as for an ICE connectivity check [RFC5245]." I thought that included auth stuff. The explanation why no auth stuff in the request is acceptable should be moved to section 3. Simon From mperumal@cisco.com Tue Jul 16 03:49:15 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C076E11E80AE; Tue, 16 Jul 2013 03:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.399 X-Spam-Level: X-Spam-Status: No, score=-10.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 Qfj1aG5b7bxd; Tue, 16 Jul 2013 03:49:10 -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 3E63321E8091; Tue, 16 Jul 2013 03:49:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6594; q=dns/txt; s=iport; t=1373971750; x=1375181350; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Po4m7Ra9CAvA43jLU366UxgT7gkxW2+ystwk/lVI/Pw=; b=b6mw8HJ6RG/DecOFPmBRKVNGzhf5V7loTsQTSXnRU694P1sdWJAgqlm7 pzEPSPpwSVySXNvGshmZlJ1I+qQLXrDIDgrKNq7xo8F2xIAgwfuysxoTe kpbXplFshrSM2QItDCCaSdNDavsV/ohtp8neskPeFsXwfu4RJl/3BIo7Y M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFADck5VGtJXG//2dsb2JhbABagwY0T8FegREWdIIjAQEBBAEBAWsXBAIBCBEEAQELDg8HJwsUCAEIAgQBEggTh3UMthoEjzM4BhKCc20DiG+UYYtZgxKBaiQa X-IronPort-AV: E=Sophos;i="4.89,676,1367971200"; d="scan'208";a="235447897" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-4.cisco.com with ESMTP; 16 Jul 2013 10:49:08 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r6GAn8nW007407 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Jul 2013 10:49:08 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.192]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Tue, 16 Jul 2013 05:49:07 -0500 From: "Muthu Arul Mozhi Perumal (mperumal)" To: Simon Perreault , "behave@ietf.org" , "rtcweb@ietf.org" Thread-Topic: [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt Thread-Index: AQHOggfD5W/HlPrVS02D/hotnG5s6plnD7Qg Date: Tue, 16 Jul 2013 10:49:07 +0000 Message-ID: References: <20130715173816.18605.12504.idtracker@ietfa.amsl.com> <51E513BF.2040405@viagenie.ca> In-Reply-To: <51E513BF.2040405@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [72.163.208.173] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 10:49:15 -0000 [Added rtcweb since I am not sure if everyone involved there are following = this discussion in behave] Thanks for the review. See inline..=20 |-----Original Message----- |From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf O= f Simon Perreault |Sent: Tuesday, July 16, 2013 3:05 PM |To: behave@ietf.org |Subject: Re: [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness= -04.txt | |Le 2013-07-15 20:42, Muthu Arul Mozhi Perumal (mperumal) a =E9crit : |> The text and the algorithm in the draft are significantly simplified in = this updated version. |> |> Comments welcome.. | |MUCH better introduction. Now I feel like I understand the need exactly. | |The "Design Considerations" section is still very confusing to me. | |> Though ICE specifies STUN Binding indications to be used for |> keepalives, it requires that an agent be prepared to receive |> connectivity check as well. If a connectivity check is received, a |> response is generated, but there is no impact on ICE processing, as |> described in section 10 of [RFC5245]. | |...so? Why is "an impact on ICE processing" necessary? Meant to stress these Binding request/response doesn't trigger an ICE resta= rt.. | |> While a WebRTC browser could verify whether the peer continues to |> send SRTCP reports before sending traffic to the peer, the usage of |> SRTCP together with Security Descriptions [RFC4568] requires exposing |> the media keys to the JavaScript and renders SRTCP unsuitable for |> consent freshness. | |Why does it "require exposing the media keys to the JavaScript"? Is this |because of a law of nature, or is it because of the way the JavaScript |API is being designed? Could the JS API be changed to accommodate |SRTCP+SDES? That's how the API construct looks like today -- the JavaScript would get a= n SDP blob from the browser containing the crypto keys used for SDES-SRTP. = Of course, the browser could hide those keys by putting a "****" in SDP -:)= . SRTP itself is still being debated in RTCWEB, so nothing is final, yet. | |> For consent, calculating the SHA1 HMAC is necessary for MESSAGE- |> INTEGRITY which is computationally expensive. | |You need to qualify "expensive". It's certainly not expensive in all cases= . | |> Security analysis |> concluded that the STUN 96 bits transaction ID is sufficient for |> consent, without needing MESSAGE-INTEGRITY. | |What analysis? You would need to explain it in detail. But if that's not |part of your suggested solution, just remove the sentence. Agree it could be elaborated. The intention was to say the foll: STUN requires the 96 bits transaction ID to be uniformly and randomly chosen from the interval 0 .. 2**96-1, and be cryptographically random. This should suffice to prevent off path attacks on consent=20 freshness, so MESSAGE-INTEGRITY is not necessary from a security perspective. However, MESSAGE-INTEGRITY is still used to maintain backward compatibility= =20 with legacy ICE/ICE-lite implementations. | |Now on to section "4. Solution Overview"... | |> Every Tc seconds, the WebRTC browser sends a STUN Binding Request to |> the peer. This request MUST use a new, cryptographically random |> Transaction ID [RFC4086], and is formatted as for an ICE connectivity |> check [RFC5245]. A valid STUN Binding Response is also formatted as |> for an ICE connectivity check [RFC5245]. The STUN Binding Request |> and STUN Binding Response are validated as for an ICE connectivity |> check [RFC5245]. | |Couldn't this whole paragraph be simplified to "Every Tc seconds, the |WebRTC browser sends an ICE connectivity check."? Is there anything new |here besides the "every Tc" thing? The difference from the ICE connectivity check is that there is no exponent= ial back off for retransmissions. =20 | |> Liveness timer: If no packets have been received on the local port in |> Tr seconds, the WebRTC browser MUST inform the JavaScript that |> connectivity has been lost. The JavaScript application will use this |> notification however it desires (e.g., cease transmitting to the |> remote peer, provide a notification to the user, etc.). | |This seems to me like it will not fulfill the goal set in the abstract: |"to ensure that a malicious JavaScript cannot use the browser as a |platform for launching attacks". If the JavaScript is free to ignore the |notification from the browser, then it has no security benefits. If you |want to reach that goal, the browser needs to forcefully stop transmitting= . That goal is fulfilled by the consent checks -- the browser would stop tran= smitting everything on that candidate pair, including liveness checks, if t= here is a consent failure. | |> When not actively sending traffic on a nominated candidate pair, |> performing consent freshness does not serve any purpose from a |> security perspective. | |I don't understand what this means. Why is the "security perspective" |important here? Aren't we concerned about keepalives? You mean one could use keepalives (Binding indications) for launching attac= ks, so consent freshness would be required for sending them as well? | |> In ICE [RFC5245] the STUN request/response are protected with |> MESSAGE-INTEGRITY, using an ephemeral username and password exchanged |> in the SDP ice-ufrag and ice-pwd attributes. This prevents ICE from |> accidentally connecting to an in-intended peer, in that ICE will only |> connect to a peer that also knows the same username and password |> (exchanged in call signaling). Once that connection to the remote |> peer has been established with ICE, the consent to continue sending |> traffic does not benefit from re-asserting that same username and |> password, so long as the senders and receiver's IP addresses remain |> the same (as they usually do). | |I had not understood from the text that there was no auth stuff in the |request. The text said "This request [...] is formatted as for an ICE |connectivity check [RFC5245]." I thought that included auth stuff. | |The explanation why no auth stuff in the request is acceptable should be |moved to section 3. Agree, it could be moved under design considerations. Muthu=20 | |Simon |_______________________________________________ |Behave mailing list |Behave@ietf.org |https://www.ietf.org/mailman/listinfo/behave From simon.perreault@viagenie.ca Tue Jul 16 05:04:21 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6794821E805F; Tue, 16 Jul 2013 05:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.073, 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 kr0OM1chKled; Tue, 16 Jul 2013 05:04:20 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 06B3711E80D7; Tue, 16 Jul 2013 05:04:17 -0700 (PDT) Received: from [127.0.0.1] (h228.viagenie.ca [206.123.31.228]) by jazz.viagenie.ca (Postfix) with ESMTPSA id A197B470FB; Tue, 16 Jul 2013 08:04:15 -0400 (EDT) Message-ID: <51E536C1.1080507@viagenie.ca> Date: Tue, 16 Jul 2013 14:04:17 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Muthu Arul Mozhi Perumal (mperumal)" References: <20130715173816.18605.12504.idtracker@ietfa.amsl.com> <51E513BF.2040405@viagenie.ca> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "rtcweb@ietf.org" , "behave@ietf.org" Subject: Re: [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 12:04:21 -0000 Le 2013-07-16 12:49, Muthu Arul Mozhi Perumal (mperumal) a crit : > |> Though ICE specifies STUN Binding indications to be used for > |> keepalives, it requires that an agent be prepared to receive > |> connectivity check as well. If a connectivity check is received, a > |> response is generated, but there is no impact on ICE processing, as > |> described in section 10 of [RFC5245]. > | > |...so? Why is "an impact on ICE processing" necessary? > > Meant to stress these Binding request/response doesn't trigger an ICE restart.. Ok, then s/but/and/. > |> While a WebRTC browser could verify whether the peer continues to > |> send SRTCP reports before sending traffic to the peer, the usage of > |> SRTCP together with Security Descriptions [RFC4568] requires exposing > |> the media keys to the JavaScript and renders SRTCP unsuitable for > |> consent freshness. > | > |Why does it "require exposing the media keys to the JavaScript"? Is this > |because of a law of nature, or is it because of the way the JavaScript > |API is being designed? Could the JS API be changed to accommodate > |SRTCP+SDES? > > That's how the API construct looks like today -- the JavaScript would get an SDP blob from the browser containing the crypto keys used for SDES-SRTP. Of course, the browser could hide those keys by putting a "****" in SDP -:). SRTP itself is still being debated in RTCWEB, so nothing is final, yet. Ok, then say so in the draft. > |> Security analysis > |> concluded that the STUN 96 bits transaction ID is sufficient for > |> consent, without needing MESSAGE-INTEGRITY. > | > |What analysis? You would need to explain it in detail. But if that's not > |part of your suggested solution, just remove the sentence. > > Agree it could be elaborated. The intention was to say the foll: > > STUN requires the 96 bits transaction ID to be uniformly and randomly > chosen from the interval 0 .. 2**96-1, and be cryptographically > random. This should suffice to prevent off path attacks on consent > freshness, so MESSAGE-INTEGRITY is not necessary from a security > perspective. > > However, MESSAGE-INTEGRITY is still used to maintain backward compatibility > with legacy ICE/ICE-lite implementations. Ok, then say so in the draft. > |Now on to section "4. Solution Overview"... > | > |> Every Tc seconds, the WebRTC browser sends a STUN Binding Request to > |> the peer. This request MUST use a new, cryptographically random > |> Transaction ID [RFC4086], and is formatted as for an ICE connectivity > |> check [RFC5245]. A valid STUN Binding Response is also formatted as > |> for an ICE connectivity check [RFC5245]. The STUN Binding Request > |> and STUN Binding Response are validated as for an ICE connectivity > |> check [RFC5245]. > | > |Couldn't this whole paragraph be simplified to "Every Tc seconds, the > |WebRTC browser sends an ICE connectivity check."? Is there anything new > |here besides the "every Tc" thing? > > The difference from the ICE connectivity check is that there is no exponential back off for retransmissions. Ok, then say so in the draft. > |> Liveness timer: If no packets have been received on the local port in > |> Tr seconds, the WebRTC browser MUST inform the JavaScript that > |> connectivity has been lost. The JavaScript application will use this > |> notification however it desires (e.g., cease transmitting to the > |> remote peer, provide a notification to the user, etc.). > | > |This seems to me like it will not fulfill the goal set in the abstract: > |"to ensure that a malicious JavaScript cannot use the browser as a > |platform for launching attacks". If the JavaScript is free to ignore the > |notification from the browser, then it has no security benefits. If you > |want to reach that goal, the browser needs to forcefully stop transmitting. > > That goal is fulfilled by the consent checks -- the browser would stop transmitting everything on that candidate pair, including liveness checks, if there is a consent failure. That's not what the draft says. It says that the browser "notifies" the JS app. It needs to say that the browser MUST stop sending. > |> When not actively sending traffic on a nominated candidate pair, > |> performing consent freshness does not serve any purpose from a > |> security perspective. > | > |I don't understand what this means. Why is the "security perspective" > |important here? Aren't we concerned about keepalives? > > You mean one could use keepalives (Binding indications) for launching attacks, so consent freshness would be required for sending them as well? No. This is a section about keepalives. I just don't understand this sentence, and I don't understand why it talks about security. Simon From mperumal@cisco.com Tue Jul 16 05:43:32 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E032A11E80D7; Tue, 16 Jul 2013 05:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.549 X-Spam-Level: X-Spam-Status: No, score=-10.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 MNF-AY3tkM+n; Tue, 16 Jul 2013 05:43:27 -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 1100021F9C4F; Tue, 16 Jul 2013 05:43:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6200; q=dns/txt; s=iport; t=1373978607; x=1375188207; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=LsbzuIhIyAnXUeD6G6plhhi4nUlH2PrPe91sDRqnMdg=; b=eC+sK2jLvvpVOT7m/1jFIsYs986ugDmhW10SxPPqruvDl9YN5k/7FkHf 5SQ35oRU9ZLBMKEw5kl48x4/KTLy21Sb7y8MNUv+AuWAuwiDAi+iwp7Pz OQLnSzrhACUceKq1XF3EFF84yIVGdDlO16e5qcV5AkZUtpPpZiramPhGZ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFADs/5VGtJV2b/2dsb2JhbABagwaBA8FdgQ4WdIIjAQEBBHkMBAIBCBEEAQELHQcyFAgBCAIEDgUIE4d1tiaPLjEHBoMGbQOIb6A6gxKBaiQa X-IronPort-AV: E=Sophos;i="4.89,676,1367971200"; d="scan'208";a="235403631" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 16 Jul 2013 12:43:26 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r6GChQrI011223 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Jul 2013 12:43:26 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.192]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Tue, 16 Jul 2013 07:43:26 -0500 From: "Muthu Arul Mozhi Perumal (mperumal)" To: Simon Perreault Thread-Topic: [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt Thread-Index: AQHOgiIQwKpPGdZXK0Ooeh9Y1O+0Lw== Date: Tue, 16 Jul 2013 12:43:26 +0000 Message-ID: References: <20130715173816.18605.12504.idtracker@ietfa.amsl.com> <51E513BF.2040405@viagenie.ca> <51E536C1.1080507@viagenie.ca> In-Reply-To: <51E536C1.1080507@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.77.66] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtcweb@ietf.org" , "behave@ietf.org" Subject: Re: [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 12:43:33 -0000 Inline.. |-----Original Message----- |From: Simon Perreault [mailto:simon.perreault@viagenie.ca] |Sent: Tuesday, July 16, 2013 5:34 PM |To: Muthu Arul Mozhi Perumal (mperumal) |Cc: behave@ietf.org; rtcweb@ietf.org |Subject: Re: [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness= -04.txt | |Le 2013-07-16 12:49, Muthu Arul Mozhi Perumal (mperumal) a =E9crit : |> |> Though ICE specifies STUN Binding indications to be used for |> |> keepalives, it requires that an agent be prepared to receive |> |> connectivity check as well. If a connectivity check is received, = a |> |> response is generated, but there is no impact on ICE processing, a= s |> |> described in section 10 of [RFC5245]. |> | |> |...so? Why is "an impact on ICE processing" necessary? |> |> Meant to stress these Binding request/response doesn't trigger an ICE re= start.. | |Ok, then s/but/and/. | |> |> While a WebRTC browser could verify whether the peer continues to |> |> send SRTCP reports before sending traffic to the peer, the usage o= f |> |> SRTCP together with Security Descriptions [RFC4568] requires expos= ing |> |> the media keys to the JavaScript and renders SRTCP unsuitable for |> |> consent freshness. |> | |> |Why does it "require exposing the media keys to the JavaScript"? Is thi= s |> |because of a law of nature, or is it because of the way the JavaScript |> |API is being designed? Could the JS API be changed to accommodate |> |SRTCP+SDES? |> |> That's how the API construct looks like today -- the JavaScript would ge= t an SDP blob from the |browser containing the crypto keys used for SDES-SRTP. Of course, the brow= ser could hide those keys by |putting a "****" in SDP -:). SRTP itself is still being debated in RTCWEB,= so nothing is final, yet. | |Ok, then say so in the draft. | |> |> Security analysis |> |> concluded that the STUN 96 bits transaction ID is sufficient for |> |> consent, without needing MESSAGE-INTEGRITY. |> | |> |What analysis? You would need to explain it in detail. But if that's no= t |> |part of your suggested solution, just remove the sentence. |> |> Agree it could be elaborated. The intention was to say the foll: |> |> STUN requires the 96 bits transaction ID to be uniformly and randomly |> chosen from the interval 0 .. 2**96-1, and be cryptographically |> random. This should suffice to prevent off path attacks on consent |> freshness, so MESSAGE-INTEGRITY is not necessary from a security |> perspective. |> |> However, MESSAGE-INTEGRITY is still used to maintain backward compatibil= ity |> with legacy ICE/ICE-lite implementations. | |Ok, then say so in the draft. | |> |Now on to section "4. Solution Overview"... |> | |> |> Every Tc seconds, the WebRTC browser sends a STUN Binding Request = to |> |> the peer. This request MUST use a new, cryptographically random |> |> Transaction ID [RFC4086], and is formatted as for an ICE connectiv= ity |> |> check [RFC5245]. A valid STUN Binding Response is also formatted = as |> |> for an ICE connectivity check [RFC5245]. The STUN Binding Request |> |> and STUN Binding Response are validated as for an ICE connectivity |> |> check [RFC5245]. |> | |> |Couldn't this whole paragraph be simplified to "Every Tc seconds, the |> |WebRTC browser sends an ICE connectivity check."? Is there anything new |> |here besides the "every Tc" thing? |> |> The difference from the ICE connectivity check is that there is no expon= ential back off for |retransmissions. | |Ok, then say so in the draft. | |> |> Liveness timer: If no packets have been received on the local port= in |> |> Tr seconds, the WebRTC browser MUST inform the JavaScript that |> |> connectivity has been lost. The JavaScript application will use t= his |> |> notification however it desires (e.g., cease transmitting to the |> |> remote peer, provide a notification to the user, etc.). |> | |> |This seems to me like it will not fulfill the goal set in the abstract: |> |"to ensure that a malicious JavaScript cannot use the browser as a |> |platform for launching attacks". If the JavaScript is free to ignore th= e |> |notification from the browser, then it has no security benefits. If you |> |want to reach that goal, the browser needs to forcefully stop transmitt= ing. |> |> That goal is fulfilled by the consent checks -- the browser would stop t= ransmitting everything on |that candidate pair, including liveness checks, if there is a consent fail= ure. | |That's not what the draft says. It says that the browser "notifies" the |JS app. It needs to say that the browser MUST stop sending. No. That section is about liveness check and its intention is just notify t= he JavaScript of a potential connectivity loss. It is when the consent chec= k fails the browser actually stops sending everything. Does the draft need = more text on the distinction between consent and liveness tests? | |> |> When not actively sending traffic on a nominated candidate pair, |> |> performing consent freshness does not serve any purpose from a |> |> security perspective. |> | |> |I don't understand what this means. Why is the "security perspective" |> |important here? Aren't we concerned about keepalives? |> |> You mean one could use keepalives (Binding indications) for launching at= tacks, so consent freshness |would be required for sending them as well? | |No. | |This is a section about keepalives. I just don't understand this |sentence, and I don't understand why it talks about security. Ok, let me elaborate: - Consent freshness is not necessary when the browser is not sending any=20 traffic on a candidate pair. - If the browser is not performing consent freshness on a candidate pair=20 for the above reason, it performs ICE keepalives (or RTP keepalives) to refresh NAT bindings. Of course, the browser could continue performing consent freshness even whe= n it is not sending any other traffic on that candidate pair and skip ICE k= eepalives. Muthu | |Simon From simon.perreault@viagenie.ca Tue Jul 16 06:04:00 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1F1821F9A1E; Tue, 16 Jul 2013 06:04:00 -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 y2jWGTIflMph; Tue, 16 Jul 2013 06:04:00 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 60EE211E80F3; Tue, 16 Jul 2013 06:03:59 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:5b8:1f9e:c21b:48d7]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 57898470FB; Tue, 16 Jul 2013 09:03:58 -0400 (EDT) Message-ID: <51E544BC.6000608@viagenie.ca> Date: Tue, 16 Jul 2013 15:03:56 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Muthu Arul Mozhi Perumal (mperumal)" References: <20130715173816.18605.12504.idtracker@ietfa.amsl.com> <51E513BF.2040405@viagenie.ca> <51E536C1.1080507@viagenie.ca> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "rtcweb@ietf.org" , "behave@ietf.org" Subject: Re: [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 13:04:00 -0000 Le 2013-07-16 14:43, Muthu Arul Mozhi Perumal (mperumal) a crit : > |> |> Liveness timer: If no packets have been received on the local port in > |> |> Tr seconds, the WebRTC browser MUST inform the JavaScript that > |> |> connectivity has been lost. The JavaScript application will use this > |> |> notification however it desires (e.g., cease transmitting to the > |> |> remote peer, provide a notification to the user, etc.). > |> | > |> |This seems to me like it will not fulfill the goal set in the abstract: > |> |"to ensure that a malicious JavaScript cannot use the browser as a > |> |platform for launching attacks". If the JavaScript is free to ignore the > |> |notification from the browser, then it has no security benefits. If you > |> |want to reach that goal, the browser needs to forcefully stop transmitting. > |> > |> That goal is fulfilled by the consent checks -- the browser would stop transmitting everything on > |that candidate pair, including liveness checks, if there is a consent failure. > | > |That's not what the draft says. It says that the browser "notifies" the > |JS app. It needs to say that the browser MUST stop sending. > > No. That section is about liveness check and its intention is just notify the JavaScript of a potential connectivity loss. It is when the consent check fails the browser actually stops sending everything. Does the draft need more text on the distinction between consent and liveness tests? Ah! No, you're right, and the text is already perfectly clear about this. No need to change. I was just confused. > |> |> When not actively sending traffic on a nominated candidate pair, > |> |> performing consent freshness does not serve any purpose from a > |> |> security perspective. > |> | > |> |I don't understand what this means. Why is the "security perspective" > |> |important here? Aren't we concerned about keepalives? > |> > |> You mean one could use keepalives (Binding indications) for launching attacks, so consent freshness > |would be required for sending them as well? > | > |No. > | > |This is a section about keepalives. I just don't understand this > |sentence, and I don't understand why it talks about security. > > Ok, let me elaborate: > - Consent freshness is not necessary when the browser is not sending any > traffic on a candidate pair. > - If the browser is not performing consent freshness on a candidate pair > for the above reason, it performs ICE keepalives (or RTP keepalives) to > refresh NAT bindings. > > Of course, the browser could continue performing consent freshness even when it is not sending any other traffic on that candidate pair and skip ICE keepalives. Ah, ok I understand with your explanation. It makes sense. There should be a way to reformulate the text to make it clearer. Thanks, Simon From juberti@google.com Mon Jul 15 14:53:21 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D763511E8176 for ; Mon, 15 Jul 2013 14:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.711 X-Spam-Level: X-Spam-Status: No, score=-1.711 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 uSXRBV1cmIHU for ; Mon, 15 Jul 2013 14:53:21 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id C64CB21E8122 for ; Mon, 15 Jul 2013 14:53:11 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id m15so10624086wgh.23 for ; Mon, 15 Jul 2013 14:53:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=kZJQsxBiAw05nki2tgUF/S1Y5FUUOXBcb0ILt4zUXVs=; b=hG+kkEwuZhGvEMh9XzDy3mRuiLqPZfQsQiFwZ5tS6yfQPMoMb5cv2o61Qj/f71blaV Pfvgj+RX+AL8g5EFsm4PBj1nJeAoaoyJfpu4u9QjJf4gPTcIYLM1BNRaCqc/KkJKoRsH AliE5yT8P1pfrSU6yBhpkHAhsrDnoQHgB9a3pS61WTGjymx+CVZRi89pCGHse/C/KoyX rsgA3my6naU8uhFRRBr0Uhta8G5fF6BdSfekyGaRnqxjDUZg6QPKPaPm0lrALywrZOzG +vt5swu0fJFd++K6Pw4Mj5vqcUwCHrXFhh9E+t9BHvbj0uHIXrGdw6XrLVvz5iKV5109 oXpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=kZJQsxBiAw05nki2tgUF/S1Y5FUUOXBcb0ILt4zUXVs=; b=j9qoMIyoGoISvrzq5NVqJtZ4bUp3Mu7lDvDHctRC5PfZekzKpWFJALPbd0ljIwA6Ps quSaJ+IO77UfyCfHZwK92TiZX+lWzKyDzg6DpNdmLMMzoUbDfIQ/Is68p4CT2iJMXNhf qig0/Xv3TghUik2GL9LJba1XpCpbFJEY4Gqni6USHQ2S+D10g2R0VUa/HVbkmbKJy0Dg HJObCYqAMqt4V8V4Yyg9TAHXtf+nFpI4sKyhi5CpO5b2bZfnWqUoRxhIL45NbYn0tOUx CEP4L+/vClSIzCMV4e8xrUV40b5CuV3nercHFI+nZ8ShPIPRboiV5NNOeU6bcv5ctlYX uQKQ== X-Received: by 10.194.58.239 with SMTP id u15mr33051859wjq.87.1373925190894; Mon, 15 Jul 2013 14:53:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.62.113 with HTTP; Mon, 15 Jul 2013 14:52:50 -0700 (PDT) In-Reply-To: References: <20130715214906.5314.83583.idtracker@ietfa.amsl.com> From: Justin Uberti Date: Mon, 15 Jul 2013 17:52:50 -0400 Message-ID: To: "rtcweb@ietf.org" , behave@ietf.org Content-Type: multipart/alternative; boundary=047d7ba97b94f39ea604e193e2dd X-Gm-Message-State: ALoCoQlhgzOeHwAdv0/qRrFZfXJ3S0WgTqThUsguJiqKueQAPR+LxgVEv+eFjF2QMGzS5xQi46nK/6r74F5xrDR/ikeMsq269SL9CEz4mK4m/GsWmDxw4rC9LbvJQlVtPywdn8xsUzDbPZDUCTwAgCMj5LwgyaDzzWJnt0qskO3C/cmig6e1iYmbtSNpyhW+eJ9j09fwFtJ0 X-Mailman-Approved-At: Tue, 16 Jul 2013 11:18:37 -0700 Subject: [BEHAVE] Fwd: New Version Notification for draft-uberti-behave-turn-rest-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 21:53:22 -0000 --047d7ba97b94f39ea604e193e2dd Content-Type: text/plain; charset=UTF-8 I have changed the WG for this draft from RTCWEB to BEHAVE. Many, but not all of the comments I received on the RTCWEB mailing list have been addressed. BEHAVE chairs, I would like 10 minutes of agenda time to discuss this draft. ---------- Forwarded message ---------- From: Date: Mon, Jul 15, 2013 at 5:49 PM Subject: New Version Notification for draft-uberti-behave-turn-rest-00.txt To: Justin Uberti A new version of I-D, draft-uberti-behave-turn-rest-00.txt has been successfully submitted by Justin Uberti and posted to the IETF repository. Filename: draft-uberti-behave-turn-rest Revision: 00 Title: A REST API For Access To TURN Services Creation date: 2013-07-15 Group: Individual Submission Number of pages: 8 URL: http://www.ietf.org/internet-drafts/draft-uberti-behave-turn-rest-00.txt Status: http://datatracker.ietf.org/doc/draft-uberti-behave-turn-rest Htmlized: http://tools.ietf.org/html/draft-uberti-behave-turn-rest-00 Abstract: This document describes a proposed standard REST API for obtaining access to TURN services via ephemeral (i.e. time-limited) credentials. These credentials are vended by a web service over HTTP, and then supplied to and checked by a TURN server using the standard TURN protocol. The usage of ephemeral credentials ensures that access to the TURN server can be controlled even if the credentials can be discovered by the user, as is the case in WebRTC where TURN credentials must be specified in Javascript. The IETF Secretariat --047d7ba97b94f39ea604e193e2dd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have changed the WG for this draft from RTCWEB to BEHAVE= . Many, but not all of the comments I received on the RTCWEB mailing list h= ave been addressed.

BEHA= VE chairs, I would like 10 minutes of agenda time to discuss this draft.
---------- Forwarded message ----------
F= rom: <internet-drafts@ietf.org>
Date: Mon, Jul 15, 2013 at 5:49 PM
Subject: New Version Notification for= draft-uberti-behave-turn-rest-00.txt
To: Justin Uberti <justin@uberti.name>



A new version of I-D, draft-uberti-behave-turn-rest-00.txt
has been successfully submitted by Justin Uberti and posted to the
IETF repository.

Filename: =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-uberti-behave-turn-rest
Revision: =C2=A0 =C2=A0 =C2=A0 =C2=A000
Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A REST API For Access To TURN Ser= vices
Creation date: =C2=A0 2013-07-15
Group: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Number of pages: 8
URL: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = http://www.ietf.org/internet-drafts/draft-uberti-behave-turn-rest-00.txt
Status: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://datatrack= er.ietf.org/doc/draft-uberti-behave-turn-rest
Htmlized: =C2=A0 =C2=A0 =C2=A0 =C2=A0http://tools.ietf.org/h= tml/draft-uberti-behave-turn-rest-00


Abstract:
=C2=A0 =C2=A0This document describes a proposed standard REST API for obtai= ning
=C2=A0 =C2=A0access to TURN services via ephemeral (i.e. time-limited)
=C2=A0 =C2=A0credentials. =C2=A0These credentials are vended by a web servi= ce over
=C2=A0 =C2=A0HTTP, and then supplied to and checked by a TURN server using = the
=C2=A0 =C2=A0standard TURN protocol. =C2=A0The usage of ephemeral credentia= ls ensures
=C2=A0 =C2=A0that access to the TURN server can be controlled even if the =C2=A0 =C2=A0credentials can be discovered by the user, as is the case in W= ebRTC
=C2=A0 =C2=A0where TURN credentials must be specified in Javascript.




The IETF Secretariat



--047d7ba97b94f39ea604e193e2dd-- From dwing@cisco.com Tue Jul 16 15:31:16 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 312E721F9D8A for ; Tue, 16 Jul 2013 15:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.498 X-Spam-Level: X-Spam-Status: No, score=-110.498 tagged_above=-999 required=5 tests=[AWL=0.100, 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 lfQ07f+ILF9M for ; Tue, 16 Jul 2013 15:31:11 -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 CAFEE21F9F6E for ; Tue, 16 Jul 2013 15:31:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3325; q=dns/txt; s=iport; t=1374013871; x=1375223471; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=/iJnIx2PLMgr1ncIKqSlDqVcNOLPH4Nlj4YHzU45OAo=; b=ABgBYKe9g57l5wJPgjCD4smiKFj3OUdRJjOqh766KPwhNw2buyDQSzHd be7ozLbi2n29D1ZIuSaKTYc1dklbpTGyhoegMTAM0A5O5ByLtOk4tDrXo ayBIv0Q5EDoczG/B4LagfkB2R0Y8rcrlM1kK6ZshIFLsGcYc64OCIf8lD E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAFAKHI5VGrRDoJ/2dsb2JhbABagwY0hRa0fYg9gQ8WdIIjAQEBAwF5BQsLBEJXGYgKBQ21TI4TgUgEBxaCdm0DiSeONYEpkCSDMhyBNQ X-IronPort-AV: E=Sophos;i="4.89,679,1367971200"; d="scan'208,217";a="83696027" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 16 Jul 2013 22:30:50 +0000 Received: from sjc-vpn3-945.cisco.com (sjc-vpn3-945.cisco.com [10.21.67.177]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r6GMUkQ6003367; Tue, 16 Jul 2013 22:30:50 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_2F65D268-C10A-44CC-8D87-C5C08664C25F" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dan Wing In-Reply-To: Date: Tue, 16 Jul 2013 15:30:49 -0700 Message-Id: References: To: meng.wei2@zte.com.cn X-Mailer: Apple Mail (2.1508) Cc: behave@ietf.org Subject: Re: [BEHAVE] NAPGT request for comments, THANKS! X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 22:31:16 -0000 --Apple-Mail=_2F65D268-C10A-44CC-8D87-C5C08664C25F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 15, 2013, at 2:43 AM, meng.wei2@zte.com.cn wrote: > I have submitted a new draft. The objective is to solve a problem = that=20 > prevents an external client from accessing an internal server.=20 >=20 > https://datatracker.ietf.org/doc/draft-meng-behave-napgt/=20 >=20 > I expect your comments. Thanks a lot!=20 Draft-meng-behave-napgt appears to describe something that is very = similar to the long-standing "DMZ host" configuration available on = almost all residential-class NAT devices. I don't think we could = standardize that behavior, but perhaps that is possible. Draft-meng-behave-napgt also describes an update to the port assignment = behavior described in http://tools.ietf.org/html/rfc5382#section-7.1 = (TCP) and http://tools.ietf.org/html/rfc4787#section-4.2.1 (UDP). If I = understand Section 4 of draft-meng-behave-napgt properly, it is saying = that NATs should not assign ports below 1024 to dynamic connections. = This might be something worth considering for = draft-ietf-behave-requirements-update? -d --Apple-Mail=_2F65D268-C10A-44CC-8D87-C5C08664C25F Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On Jul 15, 2013, at 2:43 AM, meng.wei2@zte.com.cn wrote:

    I have submitted a new draft. The objective is to solve a problem that
    prevents an external client from accessing an internal server.

    https://datatracker.ietf.org/doc/draft-meng-behave-napgt/

    I expect your comments. Thanks a lot!

Draft-meng-behave-napgt appears to describe something that is very similar to the long-standing "DMZ host" configuration available on almost all residential-class NAT devices.  I don't think we could standardize that behavior, but perhaps that is possible.

Draft-meng-behave-napgt also describes an update to the port assignment behavior described in http://tools.ietf.org/html/rfc5382#section-7.1 (TCP) and http://tools.ietf.org/html/rfc4787#section-4.2.1 (UDP).  If I understand Section 4 of draft-meng-behave-napgt properly, it is saying that NATs should not assign ports below 1024 to dynamic connections.  This might be something worth considering for draft-ietf-behave-requirements-update?

-d

--Apple-Mail=_2F65D268-C10A-44CC-8D87-C5C08664C25F-- From dwing@cisco.com Tue Jul 16 15:42:08 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5727D21F9E5C for ; Tue, 16 Jul 2013 15:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.504 X-Spam-Level: X-Spam-Status: No, score=-110.504 tagged_above=-999 required=5 tests=[AWL=0.095, 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 oGAIjpqe4Eht for ; Tue, 16 Jul 2013 15:42:03 -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 E168521F9DFB for ; Tue, 16 Jul 2013 15:42:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5193; q=dns/txt; s=iport; t=1374014524; x=1375224124; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=lxtfk2GBmuI4CShZHWZ710ITDfkPlwVPN+/An8EdmGA=; b=fb8MNA5bzJUuiM8A3+vqJGdznyiTV5gVCkYSigi+EIBncWHX6p6EaPNw OYWWr6M9K92AaFxIQgQYqV4ICwjHiNQgyS8bIErX/UJnECjtlyNjLpYku nvL4U/ljVhMpUpjb3M2g9tjTDbijtSPZmP+W2P9TCQX7LIyUclIwwv9Hd E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAFnL5VGrRDoI/2dsb2JhbABagwY0wlKBDxZ0giMBAQEDAQEBAWsLBQsLMBYnMAYTG4dvBQ21RQSOF4EVMwcYgnRtA4knjjWRTYMyHIEuJA X-IronPort-AV: E=Sophos;i="4.89,680,1367971200"; d="scan'208";a="83697216" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 16 Jul 2013 22:42:03 +0000 Received: from sjc-vpn3-945.cisco.com (sjc-vpn3-945.cisco.com [10.21.67.177]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6GMg2Rm013604; Tue, 16 Jul 2013 22:42:02 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dan Wing In-Reply-To: <51E513BF.2040405@viagenie.ca> Date: Tue, 16 Jul 2013 15:42:02 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130715173816.18605.12504.idtracker@ietfa.amsl.com> <51E513BF.2040405@viagenie.ca> To: Simon Perreault X-Mailer: Apple Mail (2.1508) Cc: behave@ietf.org Subject: Re: [BEHAVE] I-D Action: draft-muthu-behave-consent-freshness-04.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 22:42:08 -0000 On Jul 16, 2013, at 2:34 AM, Simon Perreault = wrote: > Le 2013-07-15 20:42, Muthu Arul Mozhi Perumal (mperumal) a =E9crit : >> The text and the algorithm in the draft are significantly simplified = in this updated version.=20 >>=20 >> Comments welcome.. >=20 > MUCH better introduction. Now I feel like I understand the need = exactly. Great. > The "Design Considerations" section is still very confusing to me. ... Yes, it needs work. > Now on to section "4. Solution Overview"... >=20 >> Every Tc seconds, the WebRTC browser sends a STUN Binding Request = to >> the peer. This request MUST use a new, cryptographically random >> Transaction ID [RFC4086], and is formatted as for an ICE = connectivity >> check [RFC5245]. A valid STUN Binding Response is also formatted = as >> for an ICE connectivity check [RFC5245]. The STUN Binding Request >> and STUN Binding Response are validated as for an ICE connectivity >> check [RFC5245]. >=20 > Couldn't this whole paragraph be simplified to "Every Tc seconds, the > WebRTC browser sends an ICE connectivity check."? Is there anything = new > here besides the "every Tc" thing? Nope, it's all the same rules as for ICE. We need to somehow reference = ICE although I agree it could be more tersely done than that long = paragraph. >=20 >> Liveness timer: If no packets have been received on the local port = in >> Tr seconds, the WebRTC browser MUST inform the JavaScript that >> connectivity has been lost. The JavaScript application will use = this >> notification however it desires (e.g., cease transmitting to the >> remote peer, provide a notification to the user, etc.). >=20 > This seems to me like it will not fulfill the goal set in the = abstract: > "to ensure that a malicious JavaScript cannot use the browser as a > platform for launching attacks". The liveness timer doesn't protect from that; rather, the consent timer = protects from that. The liveness timer is only intended to give an = /earlier/ alert to the (JavaScript) application that connectivity = appears to have been lost, should it want an earlier alert. > If the JavaScript is free to ignore the > notification from the browser, then it has no security benefits. If = you > want to reach that goal, the browser needs to forcefully stop = transmitting. If that isn't clear in the document, we need to more clearly separate = the consent check from the liveliness check. This version is improved, = but it appears we need more improvement, perhaps separate sections and = separate text would help. >> When not actively sending traffic on a nominated candidate pair, >> performing consent freshness does not serve any purpose from a >> security perspective. >=20 > I don't understand what this means. Why is the "security perspective" > important here? Aren't we concerned about keepalives? Keeping alive a NAT or firewall binding is not a concern of consent, = though. The point of that sentence in the I-D is that we don't need to = send Consent packets if we aren't sending RTP data or aren't sending = SCTP data. Unfortunately, we had another change that didn't make the = I-D cutoff which would have made that clearer in the normative text. WG = consensus appears to have been that consent is only necessary if data is = being actively sent; otherwise, there isn't much point in waking up both = endpoints periodically to verify "are you still there?" (batteries is = the often cited reason). >=20 >> In ICE [RFC5245] the STUN request/response are protected with >> MESSAGE-INTEGRITY, using an ephemeral username and password = exchanged >> in the SDP ice-ufrag and ice-pwd attributes. This prevents ICE = from >> accidentally connecting to an in-intended peer, in that ICE will = only >> connect to a peer that also knows the same username and password >> (exchanged in call signaling). Once that connection to the remote >> peer has been established with ICE, the consent to continue sending >> traffic does not benefit from re-asserting that same username and >> password, so long as the senders and receiver's IP addresses remain >> the same (as they usually do). >=20 > I had not understood from the text that there was no auth stuff in the > request. The text said "This request [...] is formatted as for an ICE > connectivity check [RFC5245]." I thought that included auth stuff. Editing mistake, which was my fault. Sorry. That last sentence = shouldn't be there (the sentence starting with "Once that connection to = the remote ..."). WG consensus seemed to be that MESSAGE-INTEGRITY was = needed, and that's why Section 4 (Solution Overview) tries to be clearer = that the message is formatted as described by ICE (which includes a = MESSAGE-INTEGRITY). -d >=20 > The explanation why no auth stuff in the request is acceptable should = be > moved to section 3. >=20 > Simon > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From repenno@cisco.com Tue Jul 16 18:52:44 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D4E821F868C for ; Tue, 16 Jul 2013 18:52:44 -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=[AWL=-0.000, 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 vLYXoGSRHm6f for ; Tue, 16 Jul 2013 18:52:39 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id D11EB21F8A53 for ; Tue, 16 Jul 2013 18:52:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4923; q=dns/txt; s=iport; t=1374025959; x=1375235559; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=L9Kt3F+Z2q/p/jSqxgiouExx+ApedJJfvLrArbX+cvo=; b=ins3PvlI2ssNUyF5KXRRwvmQu7muPoolNq5bHtGxixAKKYsCR2Do/21n chjBh9PzkKXyf28I8C8gc6JS9MRYH46bXxNw393B+GlgN3PVFbaKv4IpB +14LR7f3XpFdpPbGw9//s3TUxE42ZT0a/E8qTlEQEg17pGdfhLQUtb57j w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqkFAH325VGtJXG//2dsb2JhbABagkJENE+5YIg9gRAWdIIjAQEBBHkQAgEIBA0EAQELHQcyFAkIAgQBDQUIiAgMtU2OIoEbLQQGAYMMbgOIb5AWkCSDEoFxNw X-IronPort-AV: E=Sophos;i="4.89,681,1367971200"; d="scan'208,217";a="235695574" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-2.cisco.com with ESMTP; 17 Jul 2013 01:52:35 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r6H1qZ4f005196 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Jul 2013 01:52:35 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.56]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Tue, 16 Jul 2013 20:52:35 -0500 From: "Reinaldo Penno (repenno)" To: "Dan Wing (dwing)" , "meng.wei2@zte.com.cn" Thread-Topic: [BEHAVE] NAPGT request for comments, THANKS! Thread-Index: AQHOgnQzZ6Pf4Kbi5E6IWVEkv2NcnZloG0QV Date: Wed, 17 Jul 2013 01:52:34 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F0604090C7C43@xmb-rcd-x04.cisco.com> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.242.15] Content-Type: multipart/alternative; boundary="_000_45A697A8FFD7CF48BCF2BE7E106F0604090C7C43xmbrcdx04ciscoc_" MIME-Version: 1.0 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] NAPGT request for comments, THANKS! X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 01:52:44 -0000 --_000_45A697A8FFD7CF48BCF2BE7E106F0604090C7C43xmbrcdx04ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'm not sure this is a good idea. There are still some protocols around tha= t use ports < 1024 and maintaining the source port after translation in thi= s range is important. ________________________________ From: behave-bounces@ietf.org [behave-bounces@ietf.org] on behalf of Dan Wi= ng (dwing) Sent: Tuesday, July 16, 2013 3:30 PM To: meng.wei2@zte.com.cn Cc: behave@ietf.org Subject: Re: [BEHAVE] NAPGT request for comments, THANKS! On Jul 15, 2013, at 2:43 AM, meng.wei2@zte.com.cn wrote: I have submitted a new draft. The objective is to solve a problem that prevents an external client from accessing an internal server. https://datatracker.ietf.org/doc/draft-meng-behave-napgt/ I expect your comments. Thanks a lot! Draft-meng-behave-napgt appears to describe something that is very similar = to the long-standing "DMZ host" configuration available on almost all resid= ential-class NAT devices. I don't think we could standardize that behavior= , but perhaps that is possible. Draft-meng-behave-napgt also describes an update to the port assignment beh= avior described in http://tools.ietf.org/html/rfc5382#section-7.1 (TCP) and= http://tools.ietf.org/html/rfc4787#section-4.2.1 (UDP). If I understand S= ection 4 of draft-meng-behave-napgt properly, it is saying that NATs should= not assign ports below 1024 to dynamic connections. This might be somethi= ng worth considering for draft-ietf-behave-requirements-update? -d --_000_45A697A8FFD7CF48BCF2BE7E106F0604090C7C43xmbrcdx04ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I'm not sure this is a good idea. There are still some protocols aro= und that use ports < 1024 and maintaining the source port after translat= ion in this range is important.

From: behave-bounces@ietf.org [behave-bo= unces@ietf.org] on behalf of Dan Wing (dwing)
Sent: Tuesday, July 16, 2013 3:30 PM
To: meng.wei2@zte.com.cn
Cc: behave@ietf.org
Subject: Re: [BEHAVE] NAPGT request for comments, THANKS!


On Jul 15, 2013, at 2:43 AM, meng.wei2@zte.com.cn wrote:

    I have submitted a= new draft. The objective is to solve a problem that
    prevents an external client from accessing a= n internal server.

    https://datatracker.ietf.org/doc/draft-meng-behave-napgt/

    I expect your comments. Thanks a lot!=

Draft-meng-behave-napgt appears to describe something that is very similar = to the long-standing "DMZ host" configuration available on a= lmost all residential-class NAT devices.  I don't think we could stand= ardize that behavior, but perhaps that is possible.

Draft-meng-behave-napgt also describes an update to the port assignmen= t behavior described in http://tools.ietf.org/html/rfc5382#section-7.1 (TCP) and http://tools.ietf.org/html/rfc4787#section-4.2.1 (UDP).  If I = understand Section 4 of draft-meng-behave-napgt properly, it is saying that= NATs should not assign ports below 1024 to dynamic connections.  This might be something worth considering fo= r draft-ietf-behave-requirements-update?

-d

--_000_45A697A8FFD7CF48BCF2BE7E106F0604090C7C43xmbrcdx04ciscoc_-- From meng.wei2@zte.com.cn Tue Jul 16 20:09:02 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3D7321F9C06; Tue, 16 Jul 2013 20:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.773 X-Spam-Level: X-Spam-Status: No, score=-100.773 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mgoTMHh9D-Gc; Tue, 16 Jul 2013 20:08:57 -0700 (PDT) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 78B9121F9C08; Tue, 16 Jul 2013 20:08:57 -0700 (PDT) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id A64E912F2B01; Wed, 17 Jul 2013 11:08:31 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id r6H38ZZi065802; Wed, 17 Jul 2013 11:08:35 +0800 (GMT-8) (envelope-from meng.wei2@zte.com.cn) In-Reply-To: To: Dan Wing MIME-Version: 1.0 X-KeepSent: F344D30E:46107F83-48257BAB:000C79F7; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: meng.wei2@zte.com.cn Date: Wed, 17 Jul 2013 11:08:35 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2013-07-17 11:08:30, Serialize complete at 2013-07-17 11:08:30 Content-Type: multipart/alternative; boundary="=_alternative 001158EA48257BAB_=" X-MAIL: mse01.zte.com.cn r6H38ZZi065802 Cc: behave-bounces@ietf.org, behave@ietf.org Subject: Re: [BEHAVE] NAPGT request for comments, THANKS! X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 03:09:02 -0000 This is a multipart message in MIME format. --=_alternative 001158EA48257BAB_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgQ2hhaXKjrA0KICBUaGFua3MgZm9yIGNvbW1lbnRzLiANCiAgT25jZSBJIGNvbW11bmljYXRl ZCB3aXRoIHNvbWUgb3BlcmF0b3JzIGFuZCBjb2xsZWdlcyBhYm91dCBjdXJyZW50IA0Kc2l0dWF0 aW9uIG9mIA0KTkFUcyBkZXBsb3ltZW50LiBUaGV5IHJhaXNlZCBhbiBpc3N1ZSB0aGF0IGFuIGlu dGVybmFsIHNlcnZlciBjYW4gbm90IA0Kc2hhcmUgYW4gcHVibGljDQpJUCBhZGRyZXNzIHdpdGgg b3RoZXIgaW50ZXJuYWwgc3Vic2NyaWJlcnMuIFRoZSBzY2VuYXJpbyBpcyBzaW1pbGFyIHRvIA0K IkRNWiBob3N0cyIgaW5kZWVkLg0KICBTbyB0aGlzIGRyYWZ0IGRlc2NyaWJlcyBhIG1ldGhvZCBv ZiBwb3J0IGFzc2lnbm1lbnQuIEJlY2F1c2UgYSBzZXJ2aWNlIA0KdGhhdCB1c2UgcHJpdmF0ZQ0K cG9ydCBtYXkgYmUgcHJvdmlkZWQsIHNvIHBvcnQgcmFuZ2Ugc2hvdWxkIG5vdCBiZSBjb25zdGFu dCwgbm90IG9ubHkgDQo8MS0xMDI0PiwgYnV0IGFsc28gDQo8MTAyNS0yMDQ4Piwgb3IgPHgteT4u ICBBbmQgYWxzbywgdGhlIHJlc3QgcG9ydHMgc2hvdWxkIG5vdCBiZSB3YXN0ZWQgYW5kIA0KdGhl eSBjb3VsZCBiZSANCmFzc2lnbmVkIGJ5IG90aGVycy4NCiAgV2l0aCBkZXBsb3lpbmcgb2YgTkFU cywgaXQgbWF5IG9mZnNldCBuZWdhdGl2ZSBlZmZlY3RzIHRoYXQgYnJpbmcgdG8gdGhlIA0KcGVv cGxlIHdobyANCmFyZSBlcmVjdGluZyBzZXJ2ZXJzIGluIGhpcy9oZXIgaG9tZS4NCg0KQ2hlZXJz LA0KV2VpDQoNCg0KYmVoYXZlLWJvdW5jZXNAaWV0Zi5vcmcgIDIwMTMtMDctMTcgMDY6MzA6NDk6 DQoNCj4gT24gSnVsIDE1LCAyMDEzLCBhdCAyOjQzIEFNLCBtZW5nLndlaTJAenRlLmNvbS5jbiB3 cm90ZToNCj4gDQo+ICAgICBJIGhhdmUgc3VibWl0dGVkIGEgbmV3IGRyYWZ0LiBUaGUgb2JqZWN0 aXZlIGlzIHRvIHNvbHZlIGEgcHJvYmxlbSANCnRoYXQgDQo+ICAgICBwcmV2ZW50cyBhbiBleHRl cm5hbCBjbGllbnQgZnJvbSBhY2Nlc3NpbmcgYW4gaW50ZXJuYWwgc2VydmVyLiANCj4gDQo+ICAg ICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1tZW5nLWJlaGF2ZS1uYXBn dC8gDQo+IA0KPiAgICAgSSBleHBlY3QgeW91ciBjb21tZW50cy4gVGhhbmtzIGEgbG90ISANCj4g DQo+IERyYWZ0LW1lbmctYmVoYXZlLW5hcGd0IGFwcGVhcnMgdG8gZGVzY3JpYmUgc29tZXRoaW5n IHRoYXQgaXMgdmVyeSANCj4gc2ltaWxhciB0byB0aGUgbG9uZy1zdGFuZGluZyAiRE1aIGhvc3Qi IGNvbmZpZ3VyYXRpb24gYXZhaWxhYmxlIG9uIA0KPiBhbG1vc3QgYWxsIHJlc2lkZW50aWFsLWNs YXNzIE5BVCBkZXZpY2VzLiAgSSBkb24ndCB0aGluayB3ZSBjb3VsZCANCj4gc3RhbmRhcmRpemUg dGhhdCBiZWhhdmlvciwgYnV0IHBlcmhhcHMgdGhhdCBpcyBwb3NzaWJsZS4NCj4gDQo+IERyYWZ0 LW1lbmctYmVoYXZlLW5hcGd0IGFsc28gZGVzY3JpYmVzIGFuIHVwZGF0ZSB0byB0aGUgcG9ydCAN Cj4gYXNzaWdubWVudCBiZWhhdmlvciBkZXNjcmliZWQgaW4gaHR0cDovL3Rvb2xzLmlldGYuDQo+ IG9yZy9odG1sL3JmYzUzODIjc2VjdGlvbi03LjEgKFRDUCkgYW5kIGh0dHA6Ly90b29scy5pZXRm Lg0KPiBvcmcvaHRtbC9yZmM0Nzg3I3NlY3Rpb24tNC4yLjEgKFVEUCkuICBJZiBJIHVuZGVyc3Rh bmQgU2VjdGlvbiA0IG9mIA0KPiBkcmFmdC1tZW5nLWJlaGF2ZS1uYXBndCBwcm9wZXJseSwgaXQg aXMgc2F5aW5nIHRoYXQgTkFUcyBzaG91bGQgbm90IA0KPiBhc3NpZ24gcG9ydHMgYmVsb3cgMTAy NCB0byBkeW5hbWljIGNvbm5lY3Rpb25zLiAgVGhpcyBtaWdodCBiZSANCj4gc29tZXRoaW5nIHdv cnRoIGNvbnNpZGVyaW5nIGZvciBkcmFmdC1pZXRmLWJlaGF2ZS1yZXF1aXJlbWVudHMtdXBkYXRl Pw0KPiANCj4gLWQNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gQmVoYXZlIG1haWxpbmcgbGlzdA0KPiBCZWhhdmVAaWV0Zi5vcmcNCj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9iZWhhdmUNCg0K --=_alternative 001158EA48257BAB_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIENoYWlyo6w8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyBUaGFua3MgZm9yIGNvbW1l bnRzLiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyBP bmNlIEkgY29tbXVuaWNhdGVkIHdpdGggc29tZQ0Kb3BlcmF0b3JzIGFuZCBjb2xsZWdlcyBhYm91 dCBjdXJyZW50IHNpdHVhdGlvbiBvZiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPk5BVHMgZGVwbG95bWVudC4gVGhleSByYWlzZWQgYW4gaXNzdWUNCnRoYXQgYW4g aW50ZXJuYWwgc2VydmVyIGNhbiBub3Qgc2hhcmUgYW4gcHVibGljPC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5JUCBhZGRyZXNzIHdpdGggb3RoZXIgaW50ZXJuYWwg c3Vic2NyaWJlcnMuDQpUaGUgc2NlbmFyaW8gaXMgc2ltaWxhciB0byAmcXVvdDtETVogaG9zdHMm cXVvdDsgaW5kZWVkLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ Jm5ic3A7IFNvIHRoaXMgZHJhZnQgZGVzY3JpYmVzIGEgbWV0aG9kDQpvZiBwb3J0IGFzc2lnbm1l bnQuIEJlY2F1c2UgYSBzZXJ2aWNlIHRoYXQgdXNlIHByaXZhdGU8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPnBvcnQgbWF5IGJlIHByb3ZpZGVkLCBzbyBwb3J0IHJh bmdlDQpzaG91bGQgbm90IGJlIGNvbnN0YW50LCBub3Qgb25seSAmbHQ7MS0xMDI0Jmd0OywgYnV0 IGFsc28gPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbHQ7MTAy NS0yMDQ4Jmd0Oywgb3IgJmx0O3gteSZndDsuICZuYnNwO0FuZA0KYWxzbywgdGhlIHJlc3QgcG9y dHMgc2hvdWxkIG5vdCBiZSB3YXN0ZWQgYW5kIHRoZXkgY291bGQgYmUgPC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5hc3NpZ25lZCBieSBvdGhlcnMuPC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgPC9mb250Pjxmb250IHNp emU9Mj5XaXRoIGRlcGxveWluZw0Kb2YgTkFUcywgaXQgbWF5IG9mZnNldCBuZWdhdGl2ZSBlZmZl Y3RzIHRoYXQgYnJpbmcgdG8gdGhlIHBlb3BsZSB3aG8gPC9mb250Pg0KPGJyPjxmb250IHNpemU9 Mj5hcmUgZXJlY3Rpbmcgc2VydmVycyBpbiBoaXMvaGVyIGhvbWUuPC9mb250Pg0KPGJyPg0KPGJy Pjxmb250IHNpemU9Mj5DaGVlcnMsPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj5XZWk8L2ZvbnQ+ DQo8YnI+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5iZWhhdmUtYm91bmNlc0BpZXRmLm9y ZyAmbmJzcDsyMDEzLTA3LTE3IDA2OjMwOjQ5Ojxicj4NCjxicj4NCiZndDsgT24gSnVsIDE1LCAy MDEzLCBhdCAyOjQzIEFNLCBtZW5nLndlaTJAenRlLmNvbS5jbiB3cm90ZTo8L2ZvbnQ+PC90dD4N Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IEkgaGF2 ZSBzdWJtaXR0ZWQgYSBuZXcgZHJhZnQuIFRoZSBvYmplY3RpdmUgaXMgdG8gc29sdmUNCmEgcHJv YmxlbSB0aGF0IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBwcmV2ZW50cyBhbiBleHRlcm5hbCBj bGllbnQgZnJvbSBhY2Nlc3NpbmcgYW4gaW50ZXJuYWwNCnNlcnZlci4gPGJyPg0KJmd0OyA8YnI+ DQomZ3Q7ICZuYnNwOyAmbmJzcDsgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtbWVuZy1iZWhhdmUtbmFwZ3QvDQo8YnI+DQomZ3Q7IDxicj4NCiZndDsgJm5ic3A7ICZuYnNw OyBJIGV4cGVjdCB5b3VyIGNvbW1lbnRzLiBUaGFua3MgYSBsb3QhIDwvZm9udD48L3R0Pg0KPGJy Pjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IERyYWZ0LW1lbmctYmVoYXZlLW5hcGd0 IGFwcGVhcnMgdG8gZGVzY3JpYmUgc29tZXRoaW5nIHRoYXQgaXMgdmVyeQ0KPGJyPg0KJmd0OyBz aW1pbGFyIHRvIHRoZSBsb25nLXN0YW5kaW5nICZxdW90O0RNWiBob3N0JnF1b3Q7IGNvbmZpZ3Vy YXRpb24gYXZhaWxhYmxlDQpvbiA8YnI+DQomZ3Q7IGFsbW9zdCBhbGwgcmVzaWRlbnRpYWwtY2xh c3MgTkFUIGRldmljZXMuICZuYnNwO0kgZG9uJ3QgdGhpbmsgd2UgY291bGQNCjxicj4NCiZndDsg c3RhbmRhcmRpemUgdGhhdCBiZWhhdmlvciwgYnV0IHBlcmhhcHMgdGhhdCBpcyBwb3NzaWJsZS48 L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBEcmFmdC1t ZW5nLWJlaGF2ZS1uYXBndCBhbHNvIGRlc2NyaWJlcyBhbiB1cGRhdGUgdG8gdGhlIHBvcnQgPGJy Pg0KJmd0OyBhc3NpZ25tZW50IGJlaGF2aW9yIGRlc2NyaWJlZCBpbiBodHRwOi8vdG9vbHMuaWV0 Zi48YnI+DQomZ3Q7IG9yZy9odG1sL3JmYzUzODIjc2VjdGlvbi03LjEgKFRDUCkgYW5kIGh0dHA6 Ly90b29scy5pZXRmLjxicj4NCiZndDsgb3JnL2h0bWwvcmZjNDc4NyNzZWN0aW9uLTQuMi4xIChV RFApLiAmbmJzcDtJZiBJIHVuZGVyc3RhbmQgU2VjdGlvbg0KNCBvZiA8YnI+DQomZ3Q7IGRyYWZ0 LW1lbmctYmVoYXZlLW5hcGd0IHByb3Blcmx5LCBpdCBpcyBzYXlpbmcgdGhhdCBOQVRzIHNob3Vs ZCBub3QNCjxicj4NCiZndDsgYXNzaWduIHBvcnRzIGJlbG93IDEwMjQgdG8gZHluYW1pYyBjb25u ZWN0aW9ucy4gJm5ic3A7VGhpcyBtaWdodCBiZQ0KPGJyPg0KJmd0OyBzb21ldGhpbmcgd29ydGgg Y29uc2lkZXJpbmcgZm9yIGRyYWZ0LWlldGYtYmVoYXZlLXJlcXVpcmVtZW50cy11cGRhdGU/PC9m b250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgLWQ8L2ZvbnQ+ PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IEJlaGF2ZSBtYWlsaW5nIGxpc3Q8YnI+ DQomZ3Q7IEJlaGF2ZUBpZXRmLm9yZzxicj4NCiZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9iZWhhdmU8YnI+DQo8L2ZvbnQ+PC90dD4NCg== --=_alternative 001158EA48257BAB_=-- From meng.wei2@zte.com.cn Tue Jul 16 20:23:13 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B7AE21F9C08; Tue, 16 Jul 2013 20:23:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.667 X-Spam-Level: X-Spam-Status: No, score=-101.667 tagged_above=-999 required=5 tests=[AWL=0.931, 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 KXxvPK-oiBRM; Tue, 16 Jul 2013 20:23:08 -0700 (PDT) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 3F73021F9AEE; Tue, 16 Jul 2013 20:23:07 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 6C0EE12F2DF2; Wed, 17 Jul 2013 11:22:42 +0800 (CST) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id 73528703065; Wed, 17 Jul 2013 11:22:41 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id r6H3McLm086529; Wed, 17 Jul 2013 11:22:38 +0800 (GMT-8) (envelope-from meng.wei2@zte.com.cn) In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F0604090C7C43@xmb-rcd-x04.cisco.com> To: "Reinaldo Penno (repenno)" MIME-Version: 1.0 X-KeepSent: 4C144215:B48DC7CC-48257BAB:0011BD2C; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: meng.wei2@zte.com.cn Date: Wed, 17 Jul 2013 11:22:39 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2013-07-17 11:22:33, Serialize complete at 2013-07-17 11:22:33 Content-Type: multipart/alternative; boundary="=_alternative 0012A25B48257BAB_=" X-MAIL: mse02.zte.com.cn r6H3McLm086529 Cc: behave-bounces@ietf.org, "behave@ietf.org" , "Dan Wing \(dwing\)" Subject: Re: [BEHAVE] NAPGT request for comments, THANKS! X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 03:23:13 -0000 This is a multipart message in MIME format. --=_alternative 0012A25B48257BAB_= Content-Type: text/plain; charset="US-ASCII" Hi Reinaldo, So I suppose <1-1024> might be used as NAT, <1025-65535> might be used as dynamic NAPT. That is what this view says in the draft. Cheers, Wei behave-bounces@ietf.org 2013-07-17 09:52:34: > I'm not sure this is a good idea. There are still some protocols > around that use ports < 1024 and maintaining the source port after > translation in this range is important. > > From: behave-bounces@ietf.org [behave-bounces@ietf.org] on behalf of > Dan Wing (dwing) > Sent: Tuesday, July 16, 2013 3:30 PM > To: meng.wei2@zte.com.cn > Cc: behave@ietf.org > Subject: Re: [BEHAVE] NAPGT request for comments, THANKS! > > On Jul 15, 2013, at 2:43 AM, meng.wei2@zte.com.cn wrote: > > I have submitted a new draft. The objective is to solve a problem that > prevents an external client from accessing an internal server. > > https://datatracker.ietf.org/doc/draft-meng-behave-napgt/ > > I expect your comments. Thanks a lot! > > Draft-meng-behave-napgt appears to describe something that is very > similar to the long-standing "DMZ host" configuration available on > almost all residential-class NAT devices. I don't think we could > standardize that behavior, but perhaps that is possible. > > Draft-meng-behave-napgt also describes an update to the port > assignment behavior described in http://tools.ietf. > org/html/rfc5382#section-7.1 (TCP) and http://tools.ietf. > org/html/rfc4787#section-4.2.1 (UDP). If I understand Section 4 of > draft-meng-behave-napgt properly, it is saying that NATs should not > assign ports below 1024 to dynamic connections. This might be > something worth considering for draft-ietf-behave-requirements-update? > > -d > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave --=_alternative 0012A25B48257BAB_= Content-Type: text/html; charset="US-ASCII"
Hi Reinaldo,
  So I suppose <1-1024> might be used as NAT, <1025-65535> might be used as
dynamic NAPT.
  That is what this view says in the draft.

Cheers,
Wei


behave-bounces@ietf.org 2013-07-17 09:52:34:

> I'm not sure this is a good idea. There are still some protocols
> around that use ports < 1024 and maintaining the source port after
> translation in this range is important.
>
> From: behave-bounces@ietf.org [behave-bounces@ietf.org] on behalf of
> Dan Wing (dwing)
> Sent: Tuesday, July 16, 2013 3:30 PM
> To: meng.wei2@zte.com.cn
> Cc: behave@ietf.org
> Subject: Re: [BEHAVE] NAPGT request for comments, THANKS!
>
> On Jul 15, 2013, at 2:43 AM, meng.wei2@zte.com.cn wrote:
>
>     I have submitted a new draft. The objective is to solve a problem that
>     prevents an external client from accessing an internal server.
>
>     https://datatracker.ietf.org/doc/draft-meng-behave-napgt/
>
>     I expect your comments. Thanks a lot!
>
> Draft-meng-behave-napgt appears to describe something that is very
> similar to the long-standing "DMZ host" configuration available on
> almost all residential-class NAT devices.  I don't think we could
> standardize that behavior, but perhaps that is possible.
>
> Draft-meng-behave-napgt also describes an update to the port
> assignment behavior described in http://tools.ietf.
> org/html/rfc5382#section-7.1 (TCP) and http://tools.ietf.
> org/html/rfc4787#section-4.2.1 (UDP).  If I understand Section 4 of
> draft-meng-behave-napgt properly, it is saying that NATs should not
> assign ports below 1024 to dynamic connections.  This might be
> something worth considering for draft-ietf-behave-requirements-update?
>
> -d
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave
 --=_alternative 0012A25B48257BAB_=-- From repenno@cisco.com Tue Jul 16 21:36:36 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D766621F9B0E; Tue, 16 Jul 2013 21:36:36 -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=[AWL=-0.000, 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 htSVWON6imT0; Tue, 16 Jul 2013 21:36:31 -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 643CE21F9294; Tue, 16 Jul 2013 21:36:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8274; q=dns/txt; s=iport; t=1374035791; x=1375245391; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=AI+xVVlrTOz3RgdlgWOA4lkPtpFG0qBRyye0lAQwpRM=; b=j2GMux5Yf2iElSoZVEMiCGOsVrJ7zIURh3PawA+R+GjoPfTk9xlPWa21 VJKdWPKiumVTweQu+V9GqDhz8XomApTRNEQTchVnp8V3rzqQfHBNwNrp2 tDHHj+oPNY+JRC4YtLmRAsHkm8z4XkClpLFvfz/5qJKZcpX/mvBbaVPPa 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkwFAHcd5lGtJXHA/2dsb2JhbABagkJENE/CM4EOFnSCIwEBAQMBAQEBawsFCwIBCBEEAQEBCiQnCx0IAgQOBQiIAgYMtUoEjiKBGzEHgwxuA4hvoDqDEoFxNw X-IronPort-AV: E=Sophos;i="4.89,682,1367971200"; d="scan'208,217";a="235564650" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-1.cisco.com with ESMTP; 17 Jul 2013 04:36:31 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r6H4aUP4032247 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Jul 2013 04:36:30 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.56]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Tue, 16 Jul 2013 23:36:30 -0500 From: "Reinaldo Penno (repenno)" To: "meng.wei2@zte.com.cn" Thread-Topic: [BEHAVE] NAPGT request for comments, THANKS! Thread-Index: AQHOgnQzZ6Pf4Kbi5E6IWVEkv2NcnZloG0QVgABtbYD//7zUxA== Date: Wed, 17 Jul 2013 04:36:30 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F0604090C7C7E@xmb-rcd-x04.cisco.com> References: <45A697A8FFD7CF48BCF2BE7E106F0604090C7C43@xmb-rcd-x04.cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.242.96] Content-Type: multipart/alternative; boundary="_000_45A697A8FFD7CF48BCF2BE7E106F0604090C7C7Exmbrcdx04ciscoc_" MIME-Version: 1.0 Cc: "behave@ietf.org" , "behave-bounces@ietf.org" , "Dan Wing \(dwing\)" Subject: Re: [BEHAVE] NAPGT request for comments, THANKS! X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 04:36:37 -0000 --_000_45A697A8FFD7CF48BCF2BE7E106F0604090C7C7Exmbrcdx04ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I'm not sure what exactly you man by "might be used as NAT". 0-1024 might be used for NAPT in a FCFS basis where port preservation (this= is what we are talking about here, right?) is needed. As a concrete example, many IPsec Servers still expect to see the source po= rt within 0-1024 and preferably a specific source port. If that source port= is used by the NAT, and more than one IPsec client is behind it, there are= a some choices available. - Some funky IPSec ALG (implemented in many products) - Give a port above 1024 and hope for the best - Deny the connection - others.. Other ports for the same public IP can be used by any other internal IP add= ress. This is very common in implementations. thanks, ________________________________ From: behave-bounces@ietf.org [behave-bounces@ietf.org] on behalf of meng.w= ei2@zte.com.cn [meng.wei2@zte.com.cn] Sent: Tuesday, July 16, 2013 8:22 PM To: Reinaldo Penno (repenno) Cc: behave-bounces@ietf.org; behave@ietf.org; Dan Wing (dwing) Subject: Re: [BEHAVE] NAPGT request for comments, THANKS! Hi Reinaldo, So I suppose <1-1024> might be used as NAT, <1025-65535> might be used as dynamic NAPT. That is what this view says in the draft. Cheers, Wei behave-bounces@ietf.org 2013-07-17 09:52:34: > I'm not sure this is a good idea. There are still some protocols > around that use ports < 1024 and maintaining the source port after > translation in this range is important. > > From: behave-bounces@ietf.org [behave-bounces@ietf.org] on behalf of > Dan Wing (dwing) > Sent: Tuesday, July 16, 2013 3:30 PM > To: meng.wei2@zte.com.cn > Cc: behave@ietf.org > Subject: Re: [BEHAVE] NAPGT request for comments, THANKS! > > On Jul 15, 2013, at 2:43 AM, meng.wei2@zte.com.cn wrote: > > I have submitted a new draft. The objective is to solve a problem tha= t > prevents an external client from accessing an internal server. > > https://datatracker.ietf.org/doc/draft-meng-behave-napgt/ > > I expect your comments. Thanks a lot! > > Draft-meng-behave-napgt appears to describe something that is very > similar to the long-standing "DMZ host" configuration available on > almost all residential-class NAT devices. I don't think we could > standardize that behavior, but perhaps that is possible. > > Draft-meng-behave-napgt also describes an update to the port > assignment behavior described in http://tools.ietf. > org/html/rfc5382#section-7.1 (TCP) and http://tools.ietf. > org/html/rfc4787#section-4.2.1 (UDP). If I understand Section 4 of > draft-meng-behave-napgt properly, it is saying that NATs should not > assign ports below 1024 to dynamic connections. This might be > something worth considering for draft-ietf-behave-requirements-update? > > -d > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave --_000_45A697A8FFD7CF48BCF2BE7E106F0604090C7C7Exmbrcdx04ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,

I'm not sure what exactly you man by "might be used as NAT".=   

0-1024 might be used for NAPT in a FCFS basis where port preservation = (this is what we are talking about here, right?) is needed. 

As a concrete example, many IPsec Servers still expect to see the sour= ce port within 0-1024 and preferably a specific source port. If that source= port is used by the NAT, and more than one IPsec client is behind it, ther= e are a some choices available.

- Some funky IPSec ALG (implemented in many products)
- Give a port above 1024 and hope for the best
- Deny the connection
- others..

Other ports for the same public IP can be used by any other internal I= P address. This is very common in implementations.

thanks,

From: behave-bounces@ietf.org [behave-bo= unces@ietf.org] on behalf of meng.wei2@zte.com.cn [meng.wei2@zte.com.cn] Sent: Tuesday, July 16, 2013 8:22 PM
To: Reinaldo Penno (repenno)
Cc: behave-bounces@ietf.org; behave@ietf.org; Dan Wing (dwing)
Subject: Re: [BEHAVE] NAPGT request for comments, THANKS!


Hi Reinaldo,
  So I suppose <1-1024> mig= ht be used as NAT, <1025-65535> might be used as
dynamic NAPT.
  That is what this view says in = the draft.

Cheers,
Wei


behave-bounces@ietf.org 2013-07-17 09:52:34:

> I'm not sure this is a good idea. There are still some protocols
> around that use ports < 1024 and maintaining the source port after =
> translation in this range is important.
>
> From: behave-bounces@ietf.org [behave-bounces@ietf.org] on behalf of > Dan Wing (dwing)
> Sent: Tuesday, July 16, 2013 3:30 PM
> To: meng.wei2@zte.com.cn
> Cc: behave@ietf.org
> Subject: Re: [BEHAVE] NAPGT request for comments, THANKS!

>
> On Jul 15, 2013, at 2:43 AM, meng.wei2@zte.com.cn wrote: <= br> >
>     I have submitted a new draft. The objective is to solve = a problem that
>     prevents an external client from accessing an internal s= erver.
>
>     https://datatracker.ietf.org/doc/draft-meng-behave-napgt= /
>
>     I expect your comments. Thanks a lot!
>
> Draft-meng-behave-napgt appears to describe something that is very > similar to the long-standing "DMZ host" configuration availa= ble on
> almost all residential-class NAT devices.  I don't think we could=
> standardize that behavior, but perhaps that is possible. <= br> >
> Draft-meng-behave-napgt also describes an update to the port
> assignment behavior described in http://tools.ietf.
> org/html/rfc5382#section-7.1 (TCP) and http://tools.ietf.
> org/html/rfc4787#section-4.2.1 (UDP).  If I understand Section 4 = of
> draft-meng-behave-napgt properly, it is saying that NATs should not > assign ports below 1024 to dynamic connections.  This might be > something worth considering for draft-ietf-behave-requirements-update?=
>
> -d
> _______________________________________________ > Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave
--_000_45A697A8FFD7CF48BCF2BE7E106F0604090C7C7Exmbrcdx04ciscoc_-- From mperumal@cisco.com Tue Jul 16 23:37:22 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1339221F9D4A; Tue, 16 Jul 2013 23:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.427 X-Spam-Level: X-Spam-Status: No, score=-10.427 tagged_above=-999 required=5 tests=[AWL=0.172, 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 iFYc2UfNHoHx; Tue, 16 Jul 2013 23:37:16 -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 A770B21F9D12; Tue, 16 Jul 2013 23:37:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4666; q=dns/txt; s=iport; t=1374043036; x=1375252636; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=kacILdAJAaZOItV8uLV5qERGnmYWwob0yAqANn1IcBQ=; b=duMAhSoKL7YIQDDyswPKg9arZko5YKT9uT7+Zpi7/BnuvvJ7wNHf8Epn 1VuW2/rOtldq/UmAf8Y9650mpUBx03mF1ZXxBNu1G/Z4wo7xUqdRbHV2G P80yHTitBknLxZTYmMEB/08wKET5XxtiyjCTeKrpczvlNMetoTwmZOASR M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAPQ55lGtJXG8/2dsb2JhbABagwY0T8IygQ0WdIIjAQEBBAEBAWsLDAQCAQgRBAEBCx0HJwsUCAEIAgQOBQiICAy1YwSPPTEHBoMGbgOIb6A6gVmBOYIo X-IronPort-AV: E=Sophos;i="4.89,682,1367971200"; d="scan'208";a="235793175" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-5.cisco.com with ESMTP; 17 Jul 2013 06:37:15 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6H6bFL9002810 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Jul 2013 06:37:15 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.192]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Wed, 17 Jul 2013 01:37:15 -0500 From: "Muthu Arul Mozhi Perumal (mperumal)" To: "Avasarala, Ranjit (NSN - IN/Bangalore)" Thread-Topic: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt Thread-Index: AQHOgiT6JQEMzVPeD0imnIi9kp/qUZloXWjAgAAJRoA= Date: Wed, 17 Jul 2013 06:37:15 +0000 Message-ID: References: <20130715173816.18605.12504.idtracker@ietfa.amsl.com> <51E513BF.2040405@viagenie.ca> <51E536C1.1080507@viagenie.ca> <51E544BC.6000608@viagenie.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [72.163.208.222] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "behave@ietf.org" , "rtcweb@ietf.org" Subject: Re: [BEHAVE] [rtcweb] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 06:37:22 -0000 Ranjit, |Many publicly available STUN servers or those that are part of Call server= s |may not support this. Public STUN servers and call servers are not expected to support this. |Can't there be some other neutral mechanism to query peer's consent - thro= ugh=20 |signaling? No. That signaling between the JS and the web server could be anything (SIP= or XMPP or proprietary or whatever) and the browser has no control over it= . Muthu |-----Original Message----- |From: Avasarala, Ranjit (NSN - IN/Bangalore) [mailto:ranjit.avasarala@nsn.= com] |Sent: Wednesday, July 17, 2013 11:19 AM |To: Muthu Arul Mozhi Perumal (mperumal) |Cc: rtcweb@ietf.org; behave@ietf.org |Subject: RE: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-= freshness-04.txt | |Hi Muthu | |Though using STUN request/response may be good for querying about consent,= I feel it is overloading |the functionality of STUN. Many publicly available STUN servers or those t= hat are part of Call servers |may not support this. | |Can't there be some other neutral mechanism to query peer's consent - thro= ugh signaling? | | |Regards |Ranjit | | | |-----Original Message----- |From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf O= f ext Simon Perreault |Sent: Tuesday, July 16, 2013 6:34 PM |To: Muthu Arul Mozhi Perumal (mperumal) |Cc: rtcweb@ietf.org; behave@ietf.org |Subject: Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-= freshness-04.txt | |Le 2013-07-16 14:43, Muthu Arul Mozhi Perumal (mperumal) a =E9crit : |> |> |> Liveness timer: If no packets have been received on the local p= ort in |> |> |> Tr seconds, the WebRTC browser MUST inform the JavaScript that |> |> |> connectivity has been lost. The JavaScript application will us= e this |> |> |> notification however it desires (e.g., cease transmitting to th= e |> |> |> remote peer, provide a notification to the user, etc.). |> |> | |> |> |This seems to me like it will not fulfill the goal set in the abstra= ct: |> |> |"to ensure that a malicious JavaScript cannot use the browser as a |> |> |platform for launching attacks". If the JavaScript is free to ignore= the |> |> |notification from the browser, then it has no security benefits. If = you |> |> |want to reach that goal, the browser needs to forcefully stop transm= itting. |> |> |> |> That goal is fulfilled by the consent checks -- the browser would sto= p transmitting everything on |> |that candidate pair, including liveness checks, if there is a consent f= ailure. |> | |> |That's not what the draft says. It says that the browser "notifies" the |> |JS app. It needs to say that the browser MUST stop sending. |> |> No. That section is about liveness check and its intention is just notif= y the JavaScript of a |potential connectivity loss. It is when the consent check fails the browse= r actually stops sending |everything. Does the draft need more text on the distinction between conse= nt and liveness tests? | |Ah! No, you're right, and the text is already perfectly clear about |this. No need to change. I was just confused. | |> |> |> When not actively sending traffic on a nominated candidate pair= , |> |> |> performing consent freshness does not serve any purpose from a |> |> |> security perspective. |> |> | |> |> |I don't understand what this means. Why is the "security perspective= " |> |> |important here? Aren't we concerned about keepalives? |> |> |> |> You mean one could use keepalives (Binding indications) for launching= attacks, so consent |freshness |> |would be required for sending them as well? |> | |> |No. |> | |> |This is a section about keepalives. I just don't understand this |> |sentence, and I don't understand why it talks about security. |> |> Ok, let me elaborate: |> - Consent freshness is not necessary when the browser is not sending any |> traffic on a candidate pair. |> - If the browser is not performing consent freshness on a candidate pair |> for the above reason, it performs ICE keepalives (or RTP keepalives) t= o |> refresh NAT bindings. |> |> Of course, the browser could continue performing consent freshness even = when it is not sending any |other traffic on that candidate pair and skip ICE keepalives. | |Ah, ok I understand with your explanation. It makes sense. There should |be a way to reformulate the text to make it clearer. | |Thanks, |Simon |_______________________________________________ |rtcweb mailing list |rtcweb@ietf.org |https://www.ietf.org/mailman/listinfo/rtcweb From meng.wei2@zte.com.cn Wed Jul 17 01:08:38 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D08A21F89C3; Wed, 17 Jul 2013 01:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.722 X-Spam-Level: X-Spam-Status: No, score=-101.722 tagged_above=-999 required=5 tests=[AWL=0.876, 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 0yVmfEA3vaEz; Wed, 17 Jul 2013 01:08:34 -0700 (PDT) Received: from zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id D84A521F9D12; Wed, 17 Jul 2013 01:08:33 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 791E5ACB0C; Wed, 17 Jul 2013 16:08:01 +0800 (CST) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id 5994C7062A3; Wed, 17 Jul 2013 16:07:59 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id r6H880ig049654; Wed, 17 Jul 2013 16:08:00 +0800 (GMT-8) (envelope-from meng.wei2@zte.com.cn) In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F0604090C7C7E@xmb-rcd-x04.cisco.com> To: "Reinaldo Penno (repenno)" MIME-Version: 1.0 X-KeepSent: 50A98C07:6E747C89-48257BAB:00257C5C; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: meng.wei2@zte.com.cn Date: Wed, 17 Jul 2013 16:08:02 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2013-07-17 16:07:56, Serialize complete at 2013-07-17 16:07:56 Content-Type: multipart/alternative; boundary="=_alternative 002CC34948257BAB_=" X-MAIL: mse02.zte.com.cn r6H880ig049654 Cc: "behave-bounces@ietf.org" , "behave@ietf.org" , "Dan Wing \(dwing\)" Subject: Re: [BEHAVE] NAPGT request for comments, THANKS! X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 08:08:38 -0000 This is a multipart message in MIME format. --=_alternative 002CC34948257BAB_= Content-Type: text/plain; charset="US-ASCII" Hi, I got what the example means. 1-1024 is just an example, the range could be any valid value. "<1-1024> might be used as NAT, <1025-65535> might be used as dynamic NAPT", example is as below. +----------+ +-----+ +--------+ + Internet + ----+ NAT +----+ Server + +----------+ +-----+ +--------+ (1) "<1-1024> might be used as NAT" means, A server behind a NAT. A message, sent by server, its source port is in 1-1024 (or 4500-4501 or ...). The source address will be converted by NAT, the source port remains the same. (2)<1025-65535> might be used as dynamic NAPT Meanwhile, many hosts are behind NAT. They attempt to access to internet. A message, sent by a host, both its source address and port will be converted by NAT, and the new port will be in 1025-65535. It will make IP address assignment more effective. Cheers, Wei behave-bounces@ietf.org 2013-07-17 12:36:30: > Hi, > > I'm not sure what exactly you man by "might be used as NAT". > > 0-1024 might be used for NAPT in a FCFS basis where port > preservation (this is what we are talking about here, right?) is needed. > > As a concrete example, many IPsec Servers still expect to see the > source port within 0-1024 and preferably a specific source port. If > that source port is used by the NAT, and more than one IPsec client > is behind it, there are a some choices available. > > - Some funky IPSec ALG (implemented in many products) > - Give a port above 1024 and hope for the best > - Deny the connection > - others.. > > Other ports for the same public IP can be used by any other internal > IP address. This is very common in implementations. > > thanks, > > From: behave-bounces@ietf.org [behave-bounces@ietf.org] on behalf of > meng.wei2@zte.com.cn [meng.wei2@zte.com.cn] > Sent: Tuesday, July 16, 2013 8:22 PM > To: Reinaldo Penno (repenno) > Cc: behave-bounces@ietf.org; behave@ietf.org; Dan Wing (dwing) > Subject: Re: [BEHAVE] NAPGT request for comments, THANKS! > > Hi Reinaldo, > So I suppose <1-1024> might be used as NAT, <1025-65535> might be used as > dynamic NAPT. > That is what this view says in the draft. > > Cheers, > Wei > > > behave-bounces@ietf.org 2013-07-17 09:52:34: > > > I'm not sure this is a good idea. There are still some protocols > > around that use ports < 1024 and maintaining the source port after > > translation in this range is important. > > > > From: behave-bounces@ietf.org [behave-bounces@ietf.org] on behalf of > > Dan Wing (dwing) > > Sent: Tuesday, July 16, 2013 3:30 PM > > To: meng.wei2@zte.com.cn > > Cc: behave@ietf.org > > Subject: Re: [BEHAVE] NAPGT request for comments, THANKS! > > > > > On Jul 15, 2013, at 2:43 AM, meng.wei2@zte.com.cn wrote: > > > > I have submitted a new draft. The objective is to solve a problem that > > prevents an external client from accessing an internal server. > > > > https://datatracker.ietf.org/doc/draft-meng-behave-napgt/ > > > > I expect your comments. Thanks a lot! > > > > Draft-meng-behave-napgt appears to describe something that is very > > similar to the long-standing "DMZ host" configuration available on > > almost all residential-class NAT devices. I don't think we could > > standardize that behavior, but perhaps that is possible. > > > > Draft-meng-behave-napgt also describes an update to the port > > assignment behavior described in http://tools.ietf. > > org/html/rfc5382#section-7.1 (TCP) and http://tools.ietf. > > org/html/rfc4787#section-4.2.1 (UDP). If I understand Section 4 of > > draft-meng-behave-napgt properly, it is saying that NATs should not > > assign ports below 1024 to dynamic connections. This might be > > something worth considering for draft-ietf-behave-requirements-update? > > > > -d > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave --=_alternative 002CC34948257BAB_= Content-Type: text/html; charset="US-ASCII"
Hi,
  I got what the example means.

  1-1024 is just an example, the range could be any valid value.

  "<1-1024> might be used as NAT, <1025-65535> might be used as
dynamic NAPT", example is as below.

   +----------+     +-----+    +--------+
   + Internet + ----+ NAT +----+ Server +
   +----------+     +-----+    +--------+

   (1) "<1-1024> might be used as NAT" means,
       A server behind a NAT.
   A message, sent by server, its source port is in 1-1024 (or 4500-4501 or ...).
   The source address will be converted by NAT, the source port remains
   the same.

   (2)<1025-65535> might be used as dynamic NAPT
       Meanwhile, many hosts are behind NAT. They attempt to access to
    internet.
       A message, sent by a host, both its source address and port will
    be converted by NAT, and the new port will be in 1025-65535.

   
It will make IP address assignment more effective.

Cheers,
Wei



behave-bounces@ietf.org  2013-07-17 12:36:30:

> Hi,
>
> I'm not sure what exactly you man by "might be used as NAT".  
>
> 0-1024 might be used for NAPT in a FCFS basis where port
> preservation (this is what we are talking about here, right?) is needed.
>
> As a concrete example, many IPsec Servers still expect to see the
> source port within 0-1024 and preferably a specific source port. If
> that source port is used by the NAT, and more than one IPsec client
> is behind it, there are a some choices available.
>
> - Some funky IPSec ALG (implemented in many products)
> - Give a port above 1024 and hope for the best
> - Deny the connection
> - others..
>
> Other ports for the same public IP can be used by any other internal
> IP address. This is very common in implementations.
>
> thanks,
>
> From: behave-bounces@ietf.org [behave-bounces@ietf.org] on behalf of
> meng.wei2@zte.com.cn [meng.wei2@zte.com.cn]
> Sent: Tuesday, July 16, 2013 8:22 PM
> To: Reinaldo Penno (repenno)
> Cc: behave-bounces@ietf.org; behave@ietf.org; Dan Wing (dwing)
> Subject: Re: [BEHAVE] NAPGT request for comments, THANKS!
>
> Hi Reinaldo,
>   So I suppose <1-1024> might be used as NAT, <1025-65535> might be used as
> dynamic NAPT.
>   That is what this view says in the draft.
>
> Cheers,
> Wei
>
>
> behave-bounces@ietf.org 2013-07-17 09:52:34:
>
> > I'm not sure this is a good idea. There are still some protocols
> > around that use ports < 1024 and maintaining the source port after
> > translation in this range is important.
> >
> > From: behave-bounces@ietf.org [behave-bounces@ietf.org] on behalf of
> > Dan Wing (dwing)
> > Sent: Tuesday, July 16, 2013 3:30 PM
> > To: meng.wei2@zte.com.cn
> > Cc: behave@ietf.org
> > Subject: Re: [BEHAVE] NAPGT request for comments, THANKS!
>
> >
> > On Jul 15, 2013, at 2:43 AM, meng.wei2@zte.com.cn wrote:
> >
> >     I have submitted a new draft. The objective is to solve a problem that
> >     prevents an external client from accessing an internal server.
> >
> >     https://datatracker.ietf.org/doc/draft-meng-behave-napgt/
> >
> >     I expect your comments. Thanks a lot!
> >
> > Draft-meng-behave-napgt appears to describe something that is very
> > similar to the long-standing "DMZ host" configuration available on
> > almost all residential-class NAT devices.  I don't think we could
> > standardize that behavior, but perhaps that is possible.
> >
> > Draft-meng-behave-napgt also describes an update to the port
> > assignment behavior described in http://tools.ietf.
> > org/html/rfc5382#section-7.1 (TCP) and http://tools.ietf.
> > org/html/rfc4787#section-4.2.1 (UDP).  If I understand Section 4 of
> > draft-meng-behave-napgt properly, it is saying that NATs should not
> > assign ports below 1024 to dynamic connections.  This might be
> > something worth considering for draft-ietf-behave-requirements-update?
> >
> > -d
> > _______________________________________________
> > Behave mailing list
> > Behave@ietf.org
> > https://www.ietf.org/mailman/listinfo/behave
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave
 --=_alternative 002CC34948257BAB_=-- From simon.perreault@viagenie.ca Wed Jul 17 01:33:58 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8E0F21F9CA1 for ; Wed, 17 Jul 2013 01:33:57 -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 Ifs3crtN7cOO for ; Wed, 17 Jul 2013 01:33:57 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1064621F99FB for ; Wed, 17 Jul 2013 01:33:56 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:5b8:1f9e:c21b:48d7]) by jazz.viagenie.ca (Postfix) with ESMTPSA id DA7C7403F5; Wed, 17 Jul 2013 04:33:55 -0400 (EDT) Message-ID: <51E656F2.6050309@viagenie.ca> Date: Wed, 17 Jul 2013 10:33:54 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Dan Wing References: <20130715173816.18605.12504.idtracker@ietfa.amsl.com> <51E513BF.2040405@viagenie.ca> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: behave@ietf.org Subject: Re: [BEHAVE] I-D Action: draft-muthu-behave-consent-freshness-04.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 08:33:58 -0000 Le 2013-07-17 00:42, Dan Wing a crit : >>> Every Tc seconds, the WebRTC browser sends a STUN Binding Request to >>> the peer. This request MUST use a new, cryptographically random >>> Transaction ID [RFC4086], and is formatted as for an ICE connectivity >>> check [RFC5245]. A valid STUN Binding Response is also formatted as >>> for an ICE connectivity check [RFC5245]. The STUN Binding Request >>> and STUN Binding Response are validated as for an ICE connectivity >>> check [RFC5245]. >> >> Couldn't this whole paragraph be simplified to "Every Tc seconds, the >> WebRTC browser sends an ICE connectivity check."? Is there anything new >> here besides the "every Tc" thing? > > Nope, it's all the same rules as for ICE. We need to somehow reference ICE although I agree it could be more tersely done than that long paragraph. Ok. I understand it's exactly the same as an ICE connectivity check except with new re-transmission rules. If that could be explicitly and succinctly stated, it would help. >>> Liveness timer: If no packets have been received on the local port in >>> Tr seconds, the WebRTC browser MUST inform the JavaScript that >>> connectivity has been lost. The JavaScript application will use this >>> notification however it desires (e.g., cease transmitting to the >>> remote peer, provide a notification to the user, etc.). >> >> This seems to me like it will not fulfill the goal set in the abstract: >> "to ensure that a malicious JavaScript cannot use the browser as a >> platform for launching attacks". > > The liveness timer doesn't protect from that; rather, the consent timer protects from that. The liveness timer is only intended to give an /earlier/ alert to the (JavaScript) application that connectivity appears to have been lost, should it want an earlier alert. > >> If the JavaScript is free to ignore the >> notification from the browser, then it has no security benefits. If you >> want to reach that goal, the browser needs to forcefully stop transmitting. > > If that isn't clear in the document, we need to more clearly separate the consent check from the liveliness check. This version is improved, but it appears we need more improvement, perhaps separate sections and separate text would help. Yes, separate sections would help. Maybe an example with a flow diagram showing what happens when a peer goes away: after X seconds the liveness check fails and the app is notified, then after Y seconds the consent check fails and transmission stops. Also, it could be useful to discuss what happens when the peer comes back... a) ...after a liveness check failed (the session goes on as if nothing happened I suppose) b) ...after a consent check failed (can the session be resumed with some signalling (ICE restart? re-INVITE?) or is it irrevocably terminated?) >>> When not actively sending traffic on a nominated candidate pair, >>> performing consent freshness does not serve any purpose from a >>> security perspective. >> >> I don't understand what this means. Why is the "security perspective" >> important here? Aren't we concerned about keepalives? > > Keeping alive a NAT or firewall binding is not a concern of consent, though. The point of that sentence in the I-D is that we don't need to send Consent packets if we aren't sending RTP data or aren't sending SCTP data. Unfortunately, we had another change that didn't make the I-D cutoff which would have made that clearer in the normative text. WG consensus appears to have been that consent is only necessary if data is being actively sent; otherwise, there isn't much point in waking up both endpoints periodically to verify "are you still there?" (batteries is the often cited reason). That makes total sense. I'm curious about how the rule will be written. Do you stop asking for consent if the user presses the mute button? What if you're sending comfort noise? Simon From simon.perreault@viagenie.ca Wed Jul 17 01:41:19 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A00D21F9D0E for ; Wed, 17 Jul 2013 01:41:19 -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 19VFBjOu4w1P for ; Wed, 17 Jul 2013 01:41:18 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 518B621F9A43 for ; Wed, 17 Jul 2013 01:41:18 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:5b8:1f9e:c21b:48d7]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 95293403F5 for ; Wed, 17 Jul 2013 04:41:17 -0400 (EDT) Message-ID: <51E658AC.9070006@viagenie.ca> Date: Wed, 17 Jul 2013 10:41:16 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: behave@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [BEHAVE] NAPGT request for comments, THANKS! X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 08:41:19 -0000 It seems you guys are forgetting about RFC 4787 REQ-3 a): a) If the host's source port was in the range 0-1023, it is RECOMMENDED the NAT's source port be in the same range. If the host's source port was in the range 1024-65535, it is RECOMMENDED that the NAT's source port be in that range. Does anything more need to be said about this? Simon Le 2013-07-17 10:08, meng.wei2@zte.com.cn a crit : > > Hi, > I got what the example means. > > 1-1024 is just an example, the range could be any valid value. > > "<1-1024> might be used as NAT, <1025-65535> might be used as > dynamic NAPT", example is as below. > > +----------+ +-----+ +--------+ > + Internet + ----+ NAT +----+ Server + > +----------+ +-----+ +--------+ > > (1) "<1-1024> might be used as NAT" means, > A server behind a NAT. > A message, sent by server, its source port is in 1-1024 (or 4500-4501 > or ...). > The source address will be converted by NAT, the source port remains > the same. > > (2)<1025-65535> might be used as dynamic NAPT > Meanwhile, many hosts are behind NAT. They attempt to access to > internet. > A message, sent by a host, both its source address and port will > be converted by NAT, and the new port will be in 1025-65535. > > > It will make IP address assignment more effective. > > Cheers, > Wei > > > > behave-bounces@ietf.org 2013-07-17 12:36:30: > >> Hi, >> >> I'm not sure what exactly you man by "might be used as NAT". >> >> 0-1024 might be used for NAPT in a FCFS basis where port >> preservation (this is what we are talking about here, right?) is needed. >> >> As a concrete example, many IPsec Servers still expect to see the >> source port within 0-1024 and preferably a specific source port. If >> that source port is used by the NAT, and more than one IPsec client >> is behind it, there are a some choices available. >> >> - Some funky IPSec ALG (implemented in many products) >> - Give a port above 1024 and hope for the best >> - Deny the connection >> - others.. >> >> Other ports for the same public IP can be used by any other internal >> IP address. This is very common in implementations. >> >> thanks, >> >> From: behave-bounces@ietf.org [behave-bounces@ietf.org] on behalf of >> meng.wei2@zte.com.cn [meng.wei2@zte.com.cn] >> Sent: Tuesday, July 16, 2013 8:22 PM >> To: Reinaldo Penno (repenno) >> Cc: behave-bounces@ietf.org; behave@ietf.org; Dan Wing (dwing) >> Subject: Re: [BEHAVE] NAPGT request for comments, THANKS! > >> >> Hi Reinaldo, >> So I suppose <1-1024> might be used as NAT, <1025-65535> might be > used as >> dynamic NAPT. >> That is what this view says in the draft. >> >> Cheers, >> Wei >> >> >> behave-bounces@ietf.org 2013-07-17 09:52:34: >> >> > I'm not sure this is a good idea. There are still some protocols >> > around that use ports < 1024 and maintaining the source port after >> > translation in this range is important. >> > >> > From: behave-bounces@ietf.org [behave-bounces@ietf.org] on behalf of >> > Dan Wing (dwing) >> > Sent: Tuesday, July 16, 2013 3:30 PM >> > To: meng.wei2@zte.com.cn >> > Cc: behave@ietf.org >> > Subject: Re: [BEHAVE] NAPGT request for comments, THANKS! >> >> > >> > On Jul 15, 2013, at 2:43 AM, meng.wei2@zte.com.cn wrote: >> > >> > I have submitted a new draft. The objective is to solve a > problem that >> > prevents an external client from accessing an internal server. >> > >> > https://datatracker.ietf.org/doc/draft-meng-behave-napgt/ >> > >> > I expect your comments. Thanks a lot! >> > >> > Draft-meng-behave-napgt appears to describe something that is very >> > similar to the long-standing "DMZ host" configuration available on >> > almost all residential-class NAT devices. I don't think we could >> > standardize that behavior, but perhaps that is possible. >> > >> > Draft-meng-behave-napgt also describes an update to the port >> > assignment behavior described in http://tools.ietf. >> > org/html/rfc5382#section-7.1 (TCP) and http://tools.ietf. >> > org/html/rfc4787#section-4.2.1 (UDP). If I understand Section 4 of >> > draft-meng-behave-napgt properly, it is saying that NATs should not >> > assign ports below 1024 to dynamic connections. This might be >> > something worth considering for draft-ietf-behave-requirements-update? >> > >> > -d From simon.perreault@viagenie.ca Wed Jul 17 01:44:47 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAE5521F9958 for ; Wed, 17 Jul 2013 01:44:47 -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 sV2dh8yYh2rE for ; Wed, 17 Jul 2013 01:44:47 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7A22D21F849C for ; Wed, 17 Jul 2013 01:44:47 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:5b8:1f9e:c21b:48d7]) by jazz.viagenie.ca (Postfix) with ESMTPSA id DE4D8403F5 for ; Wed, 17 Jul 2013 04:44:46 -0400 (EDT) Message-ID: <51E6597D.1090006@viagenie.ca> Date: Wed, 17 Jul 2013 10:44:45 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: behave@ietf.org References: <20130715173816.18605.12504.idtracker@ietfa.amsl.com> <51E513BF.2040405@viagenie.ca> <51E536C1.1080507@viagenie.ca> <51E544BC.6000608@viagenie.ca> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [BEHAVE] [rtcweb] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 08:44:48 -0000 Le 2013-07-17 08:37, Muthu Arul Mozhi Perumal (mperumal) a crit : > |Many publicly available STUN servers or those that are part of Call servers > |may not support this. > > Public STUN servers and call servers are not expected to support this. In addition, if I read the specs correctly, any unmodified ICE UA should already support this, right? That's a big plus. Simon From ekr@rtfm.com Wed Jul 17 02:02:54 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B14A21F999C for ; Wed, 17 Jul 2013 02:02:54 -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 JI31hOTzfr2i for ; Wed, 17 Jul 2013 02:02:48 -0700 (PDT) Received: from mail-qc0-f178.google.com (mail-qc0-f178.google.com [209.85.216.178]) by ietfa.amsl.com (Postfix) with ESMTP id 0D06E21F9D1C for ; Wed, 17 Jul 2013 02:02:47 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id c11so952886qcv.9 for ; Wed, 17 Jul 2013 02:02:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=Ii69YmhragN4j/hHMeXfek5F74aJ9PAidKrto1vJDBc=; b=Jzhvic1Q9e+KtrLAMokjHRecb6Uod4z8LgdpGHZfgG749fMul8jiiIm0Pf3k3DJPDp TgOtfAHrAcM7H1Sp5EplbMq3mKfqaZ37vrlPSmwnEmg1mAFh9/I38XIAK/SlIP3thEOP EALa/TlVj+IXynmBZs8lVbTVYSVSSrGHK5xnEzsM27yuaJDB/H3W37ogsjXnVRj05Zz9 7Amd7YyktxG9Aoq/TKHqbOqArssnBbnsyYMOh/ewLe1pLMXMWjdqhbrzO9iEtrujCWej LC3WDRiVXA+0o+MboQjAJjGHeC08gAo48nSqO1awHmaFFTl5Qq3YvaeVvZklMO+QwcXs L/jA== X-Received: by 10.224.4.202 with SMTP id 10mr8144132qas.1.1374051767268; Wed, 17 Jul 2013 02:02:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.48.234 with HTTP; Wed, 17 Jul 2013 02:02:07 -0700 (PDT) X-Originating-IP: [220.136.0.192] In-Reply-To: References: <20130715173816.18605.12504.idtracker@ietfa.amsl.com> <51E513BF.2040405@viagenie.ca> From: Eric Rescorla Date: Wed, 17 Jul 2013 17:02:07 +0800 Message-ID: To: "Muthu Arul Mozhi Perumal (mperumal)" Content-Type: multipart/alternative; boundary=001a11c20dfe7dc3c104e1b15bda X-Gm-Message-State: ALoCoQnRFmCIdOZ1/o89inqcwRqnWEE/6eJ4DhyAjHLdl7TLkkRK+1n6enobmp2E+5mGHTCrkn7U Cc: "behave@ietf.org" , "rtcweb@ietf.org" Subject: Re: [BEHAVE] [rtcweb] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 09:02:54 -0000 --001a11c20dfe7dc3c104e1b15bda Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Jul 16, 2013 at 6:49 PM, Muthu Arul Mozhi Perumal (mperumal) < mperumal@cisco.com> wrote: > [Added rtcweb since I am not sure if everyone involved there are followin= g > this discussion in behave] > > Thanks for the review. See inline.. > > |-----Original Message----- > |From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf > Of Simon Perreault > |Sent: Tuesday, July 16, 2013 3:05 PM > |To: behave@ietf.org > |Subject: Re: [BEHAVE] FW: I-D Action: > draft-muthu-behave-consent-freshness-04.txt > | > |Le 2013-07-15 20:42, Muthu Arul Mozhi Perumal (mperumal) a =E9crit : > |> The text and the algorithm in the draft are significantly simplified i= n > this updated version. > |> > |> Comments welcome.. > | > |MUCH better introduction. Now I feel like I understand the need exactly. > | > |The "Design Considerations" section is still very confusing to me. > | > |> Though ICE specifies STUN Binding indications to be used for > |> keepalives, it requires that an agent be prepared to receive > |> connectivity check as well. If a connectivity check is received, a > |> response is generated, but there is no impact on ICE processing, as > |> described in section 10 of [RFC5245]. > | > |...so? Why is "an impact on ICE processing" necessary? > > Meant to stress these Binding request/response doesn't trigger an ICE > restart.. > > | > |> While a WebRTC browser could verify whether the peer continues to > |> send SRTCP reports before sending traffic to the peer, the usage of > |> SRTCP together with Security Descriptions [RFC4568] requires exposi= ng > |> the media keys to the JavaScript and renders SRTCP unsuitable for > |> consent freshness. > | > |Why does it "require exposing the media keys to the JavaScript"? Is this > |because of a law of nature, or is it because of the way the JavaScript > |API is being designed? Could the JS API be changed to accommodate > |SRTCP+SDES? > > That's how the API construct looks like today -- the JavaScript would get > an SDP blob from the browser containing the crypto keys used for SDES-SRT= P. > Of course, the browser could hide those keys by putting a "****" in SDP -= :). Uh, then how would they be sent to the other side? As far as I can tell, with any plausible API SDES requires exposing the keys to JS. -Ekr --001a11c20dfe7dc3c104e1b15bda Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Jul 16, 2013 at 6:49 PM, Muthu Arul Mozhi Perumal (mperumal= ) <mperumal@cisco.com> wrote:
[Added rtcweb since I am not sure if everyon= e involved there are following this discussion in behave]

Thanks for the review. See inline..

|-----Original Message-----
|From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.o= rg] On Behalf Of Simon Perreault
|Sent: Tuesday, July 16, 2013 3:05 PM
|To: behave@ietf.org
|Subject: Re: [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness= -04.txt
|
|Le 2013-07-15 20:42, Muthu Arul Mozhi Perumal (mperumal) a =E9crit :
|> The text and the algorithm in the draft are signifi= cantly simplified in this updated version.
|>
|> Comments welcome..
|
|MUCH better introduction. Now I feel like I understand the need exac= tly.
|
|The "Design Considerations" section is still very confusing to m= e.
|
|> =A0 =A0Though ICE specifies STUN Binding indications to be used for |> =A0 =A0keepalives, it requires that an agent be prepared to receive |> =A0 =A0connectivity check as well. =A0If a connectivity check is rece= ived, a
|> =A0 =A0response is generated, but there is no impact on ICE processin= g, as
|> =A0 =A0described in section 10 of [RFC5245].
|
|...so? Why is "an impact on ICE processing" necessary?

Meant to stress these Binding request/response doesn't trigger an ICE r= estart..

|
|> =A0 =A0While a WebRTC browser could verify whether the peer continues= to
|> =A0 =A0send SRTCP reports before sending traffic to the peer, the usa= ge of
|> =A0 =A0SRTCP together with Security Descriptions [RFC4568] requires e= xposing
|> =A0 =A0the media keys to the JavaScript and renders SRTCP unsuitable = for
|> =A0 =A0consent freshness.
|
|Why does it "require exposing the media keys to the JavaScript"?= Is this
|because of a law of nature, or is it because of the way the JavaScript
|API is being designed? Could the JS API be changed to accommodate
|SRTCP+SDES?

That's how the API construct looks like today -- the JavaScript would g= et an SDP blob from the browser containing the crypto keys used for SDES-SR= TP. Of course, the browser could hide those keys by putting a "****&qu= ot; in SDP -:).


Uh, then how would they be sent to the o= ther side?

As far as I can tell, with any plausibl= e API SDES requires exposing the keys to JS.

-Ekr

--001a11c20dfe7dc3c104e1b15bda-- From mperumal@cisco.com Wed Jul 17 05:40:00 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CE5F21F9EF5 for ; Wed, 17 Jul 2013 05:40:00 -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 Wf0QsifD2fMd for ; Wed, 17 Jul 2013 05:39:55 -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 6228221F9EA3 for ; Wed, 17 Jul 2013 05:39:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=881; q=dns/txt; s=iport; t=1374064795; x=1375274395; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=D3Q8agntdGtiXwNvc3DvAh/Uylp2pMRxw8KzSrTKRBg=; b=iUQTzCAMJj5JVpPEdp/vK28Btlm7sVyfcWvEtp2SaihrZqLN8MIuvMXx znsNUKdy1VbJ4NbQZDkbnO6l3LFBVl+BjJkZqI1jq5+z+CCrVfBOv75P3 1tUCtLy52CFQX7et0jQeBvBG5Hhh+MKVmWrcrWNCTcorgSzN49Sq3XDYE E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak0FAIuP5lGtJV2c/2dsb2JhbABagwY0T4I/wBOBDxZ0giMBAQEEAQEBaxcEAgEIEQQBAQsdBycLFAgBCAIEARIIiAgMtWgEjz04BoMGbgOIb6A6gVmBOYIo X-IronPort-AV: E=Sophos;i="4.89,684,1367971200"; d="scan'208";a="235710600" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 17 Jul 2013 12:39:52 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r6HCdqJX004468 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Jul 2013 12:39:52 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.192]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Wed, 17 Jul 2013 07:39:51 -0500 From: "Muthu Arul Mozhi Perumal (mperumal)" To: Simon Perreault , "behave@ietf.org" Thread-Topic: [BEHAVE] [rtcweb] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt Thread-Index: AQHOgsnpFrGRfhytOkm0KNETlqXUqploj+Rg Date: Wed, 17 Jul 2013 12:39:51 +0000 Message-ID: References: <20130715173816.18605.12504.idtracker@ietfa.amsl.com> <51E513BF.2040405@viagenie.ca> <51E536C1.1080507@viagenie.ca> <51E544BC.6000608@viagenie.ca> <51E6597D.1090006@viagenie.ca> In-Reply-To: <51E6597D.1090006@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.55.164] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] [rtcweb] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 12:40:00 -0000 |-----Original Message----- |From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf O= f Simon Perreault |Sent: Wednesday, July 17, 2013 2:15 PM |To: behave@ietf.org |Subject: Re: [BEHAVE] [rtcweb] FW: I-D Action: draft-muthu-behave-consent-= freshness-04.txt | |Le 2013-07-17 08:37, Muthu Arul Mozhi Perumal (mperumal) a =E9crit : |> |Many publicly available STUN servers or those that are part of Call ser= vers |> |may not support this. |> |> Public STUN servers and call servers are not expected to support this. | |In addition, if I read the specs correctly, any unmodified ICE UA should |already support this, right? That's a big plus. Exactly..it is fully backward compatible. Muthu | |Simon |_______________________________________________ |Behave mailing list |Behave@ietf.org |https://www.ietf.org/mailman/listinfo/behave From mperumal@cisco.com Wed Jul 17 05:47:11 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9056521F9F1F; Wed, 17 Jul 2013 05:47:11 -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=[AWL=-0.000, 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 dpwx76Zv98hK; Wed, 17 Jul 2013 05:47:06 -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 100C121F93F3; Wed, 17 Jul 2013 05:47:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10713; q=dns/txt; s=iport; t=1374065224; x=1375274824; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=acefHav8uesKiFqyNunNL1n1Q7yunoMBUteqB8MR/3Q=; b=gGLLWJbHrMKl6YuA509eqwLvslbAzPuXas3EcX0PcKZ02UoxIt/b97Co vHG2uKxELYd6avK8D0u2FwY5tIb6o/PqMbO9VXAX9XHYyWcFa0m+tXTUf /lP5XuR9tgcrTe8nWqqZ6Xgh4fqBA98ieP1zLXJKcShWTMlYJ7tjFBtV4 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AksFAAqR5lGtJXHA/2dsb2JhbABagkJEgQPCUoEPFnSCIwEBAQQtTAwEAgEIDgMEAQELHQcyFAgBCAIEDgUIiAi1do89MQYBBoMGbgOIb6A6gVmBOYIo X-IronPort-AV: E=Sophos;i="4.89,684,1367971200"; d="scan'208,217";a="235907664" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-5.cisco.com with ESMTP; 17 Jul 2013 12:47:03 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r6HCl334027265 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Jul 2013 12:47:03 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.192]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Wed, 17 Jul 2013 07:47:02 -0500 From: "Muthu Arul Mozhi Perumal (mperumal)" To: Eric Rescorla Thread-Topic: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt Thread-Index: AQHOguu8ib6iXKrxjkSuS/iDhawvUw== Date: Wed, 17 Jul 2013 12:47:02 +0000 Message-ID: References: <20130715173816.18605.12504.idtracker@ietfa.amsl.com> <51E513BF.2040405@viagenie.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.55.164] Content-Type: multipart/alternative; boundary="_000_E721D8C6A2E1544DB2DEBC313AF54DE22419C35Dxmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "behave@ietf.org" , "rtcweb@ietf.org" Subject: Re: [BEHAVE] [rtcweb] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 12:47:11 -0000 --_000_E721D8C6A2E1544DB2DEBC313AF54DE22419C35Dxmbrcdx02ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable |Uh, then how would they be sent to the other side? Ah, the browser would have to modify the SDP when it is sent on the wire.. |As far as I can tell, with any plausible API SDES requires exposing the ke= ys to JS. That helps..thanks. Muthu From: Eric Rescorla [mailto:ekr@rtfm.com] Sent: Wednesday, July 17, 2013 2:32 PM To: Muthu Arul Mozhi Perumal (mperumal) Cc: Simon Perreault; behave@ietf.org; rtcweb@ietf.org Subject: Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-f= reshness-04.txt On Tue, Jul 16, 2013 at 6:49 PM, Muthu Arul Mozhi Perumal (mperumal) > wrote: [Added rtcweb since I am not sure if everyone involved there are following = this discussion in behave] Thanks for the review. See inline.. |-----Original Message----- |From: behave-bounces@ietf.org [mailto:beha= ve-bounces@ietf.org] On Behalf Of Simon Per= reault |Sent: Tuesday, July 16, 2013 3:05 PM |To: behave@ietf.org |Subject: Re: [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness= -04.txt | |Le 2013-07-15 20:42, Muthu Arul Mozhi Perumal (mperumal) a =E9crit : |> The text and the algorithm in the draft are significantly simplified in = this updated version. |> |> Comments welcome.. | |MUCH better introduction. Now I feel like I understand the need exactly. | |The "Design Considerations" section is still very confusing to me. | |> Though ICE specifies STUN Binding indications to be used for |> keepalives, it requires that an agent be prepared to receive |> connectivity check as well. If a connectivity check is received, a |> response is generated, but there is no impact on ICE processing, as |> described in section 10 of [RFC5245]. | |...so? Why is "an impact on ICE processing" necessary? Meant to stress these Binding request/response doesn't trigger an ICE resta= rt.. | |> While a WebRTC browser could verify whether the peer continues to |> send SRTCP reports before sending traffic to the peer, the usage of |> SRTCP together with Security Descriptions [RFC4568] requires exposing |> the media keys to the JavaScript and renders SRTCP unsuitable for |> consent freshness. | |Why does it "require exposing the media keys to the JavaScript"? Is this |because of a law of nature, or is it because of the way the JavaScript |API is being designed? Could the JS API be changed to accommodate |SRTCP+SDES? That's how the API construct looks like today -- the JavaScript would get a= n SDP blob from the browser containing the crypto keys used for SDES-SRTP. = Of course, the browser could hide those keys by putting a "****" in SDP -:)= . Uh, then how would they be sent to the other side? As far as I can tell, with any plausible API SDES requires exposing the key= s to JS. -Ekr --_000_E721D8C6A2E1544DB2DEBC313AF54DE22419C35Dxmbrcdx02ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

|Uh, then how would they be sent to the other side?

 

Ah, the browser would have to modify the SDP when it is se= nt on the wire..

 

|As far as I can tell, with any plausible API SDES require= s exposing the keys to JS.

 

That helps..thanks.

 

Muthu

 

From: Eric Res= corla [mailto:ekr@rtfm.com]
Sent: Wednesday, July 17, 2013 2:32 PM
To: Muthu Arul Mozhi Perumal (mperumal)
Cc: Simon Perreault; behave@ietf.org; rtcweb@ietf.org
Subject: Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-co= nsent-freshness-04.txt

 

 

 

On Tue, Jul 16, 2013 at 6:49 PM, Muthu Arul Mozhi Pe= rumal (mperumal) <mperumal@cisco.com> wrote:

[Added rtcweb since I am not sure if everyone involv= ed there are following this discussion in behave]

Thanks for the review. See inline..

|-----Original Message-----
|From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.o= rg] On Behalf Of Simon Perreault
|Sent: Tuesday, July 16, 2013 3:05 PM
|To: behave@ietf.org
|Subject: Re: [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness= -04.txt
|
|Le 2013-07-15 20:42, Muthu Arul Mozhi Perumal (mperumal) a =E9crit :<= /o:p>

|> The text and the algorithm in the draft are si= gnificantly simplified in this updated version.
|>
|> Comments welcome..
|

|MUCH better introduction. Now I feel like I underst= and the need exactly.
|
|The "Design Considerations" section is still very confusing to m= e.
|
|>    Though ICE specifies STUN Binding indications to be used= for
|>    keepalives, it requires that an agent be prepared to rec= eive
|>    connectivity check as well.  If a connectivity chec= k is received, a
|>    response is generated, but there is no impact on ICE pro= cessing, as
|>    described in section 10 of [RFC5245].
|
|...so? Why is "an impact on ICE processing" necessary?

Meant to stress these Binding request/response doesn't trigger an ICE resta= rt..

|
|>    While a WebRTC browser could verify whether the peer con= tinues to
|>    send SRTCP reports before sending traffic to the peer, t= he usage of
|>    SRTCP together with Security Descriptions [RFC4568] requ= ires exposing
|>    the media keys to the JavaScript and renders SRTCP unsui= table for
|>    consent freshness.
|
|Why does it "require exposing the media keys to the JavaScript"?= Is this
|because of a law of nature, or is it because of the way the JavaScript
|API is being designed? Could the JS API be changed to accommodate
|SRTCP+SDES?

That's how the API construct looks like today -- the JavaScript would get a= n SDP blob from the browser containing the crypto keys used for SDES-SRTP. = Of course, the browser could hide those keys by putting a "****" = in SDP -:).

 

 

Uh, then how would they be sent to the other side?

 

As far as I can tell, with any plausible API SDES re= quires exposing the keys to JS.

 

-Ekr

 

--_000_E721D8C6A2E1544DB2DEBC313AF54DE22419C35Dxmbrcdx02ciscoc_-- From ssenthil@cisco.com Wed Jul 17 06:30:31 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0776421F9EA7; Wed, 17 Jul 2013 06:30: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=[AWL=-0.000, 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 H6GRJyiApTMZ; Wed, 17 Jul 2013 06:30:26 -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 D26ED21F9EF2; Wed, 17 Jul 2013 06:30:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16015; q=dns/txt; s=iport; t=1374067826; x=1375277426; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=XBLY5ryJdPIHhZoVdxPITZxasUQX3p+HgX8//pno/AY=; b=DqfcelWqE5CzjI02G7XOTDNJrAXLzro6qukaMqXPPWvQ91qlYBOkE9ZY LMNRjA9ogWdD6s7f6twrfcHqIp0WmlDSWcXhV5k+VR5UpK5iqp61t9uMC iDb71YcJ+yaKD1mv/1Q4rSxHnazETj6rEg2sGWv2AVD5FX6h4kVAZLigP g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqoFAImb5lGtJXHA/2dsb2JhbABagkJENE+6FYg9gREWdIIjAQEBAwEBAQFrCwUNAQgRAwEBAQEKHS4LFAkIAgQBDQUIiAIGDLV7jiKBGyANBAcGA4MDbgOZBZAkgxKBcTc X-IronPort-AV: E=Sophos;i="4.89,684,1367971200"; d="scan'208,217";a="235947328" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-3.cisco.com with ESMTP; 17 Jul 2013 13:30:25 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r6HDUOBv011821 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Jul 2013 13:30:24 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.94]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Wed, 17 Jul 2013 08:30:24 -0500 From: "Senthil Sivakumar (ssenthil)" To: "meng.wei2@zte.com.cn" , "Reinaldo Penno (repenno)" Thread-Topic: [BEHAVE] NAPGT request for comments, THANKS! Thread-Index: AQHOgT/xKd1JQDPEfEGuYnya6wJotJloOY+AgAA4XwCAABkrgIAAFKIAgAA7GgCAABcBAA== Date: Wed, 17 Jul 2013 13:30:24 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.117.198.132] Content-Type: multipart/alternative; boundary="_000_CB1B483277FEC94E9B58357040EE5D02325CF41Exmbrcdx15ciscoc_" MIME-Version: 1.0 Cc: "behave@ietf.org" , "behave-bounces@ietf.org" , "Dan Wing \(dwing\)" Subject: Re: [BEHAVE] NAPGT request for comments, THANKS! X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 13:30:31 -0000 --_000_CB1B483277FEC94E9B58357040EE5D02325CF41Exmbrcdx15ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable From: "meng.wei2@zte.com.cn" > Date: Wednesday, July 17, 2013 4:08 AM To: "Reinaldo Penno (repenno)" = > Cc: "behave-bounces@ietf.org" >, "behave@ietf.org" >, "Dan Wing (dwing)" = > Subject: Re: [BEHAVE] NAPGT request for comments, THANKS! Hi, I got what the example means. 1-1024 is just an example, the range could be any valid value. "<1-1024> might be used as NAT, <1025-65535> might be used as dynamic NAPT", example is as below. +----------+ +-----+ +--------+ + Internet + ----+ NAT +----+ Server + +----------+ +-----+ +--------+ (1) "<1-1024> might be used as NAT" means, A server behind a NAT. A message, sent by server, its source port is in 1-1024 (or 4500-4501 or= ...). The source address will be converted by NAT, the source port remains the same. [Senthil] Sorry, I didn=92t read the draft, but the above logic wont work i= f there are multiple servers using the same source port. Also, in some applications (I think rcmd, rshell etc), the source port does= n=92t have to be preserved but must be below 1024. Senthil (2)<1025-65535> might be used as dynamic NAPT Meanwhile, many hosts are behind NAT. They attempt to access to internet. A message, sent by a host, both its source address and port will be converted by NAT, and the new port will be in 1025-65535. It will make IP address assignment more effective. Cheers, Wei behave-bounces@ietf.org 2013-07-17 12:36:3= 0: > Hi, > > I'm not sure what exactly you man by "might be used as NAT". > > 0-1024 might be used for NAPT in a FCFS basis where port > preservation (this is what we are talking about here, right?) is needed. > > As a concrete example, many IPsec Servers still expect to see the > source port within 0-1024 and preferably a specific source port. If > that source port is used by the NAT, and more than one IPsec client > is behind it, there are a some choices available. > > - Some funky IPSec ALG (implemented in many products) > - Give a port above 1024 and hope for the best > - Deny the connection > - others.. > > Other ports for the same public IP can be used by any other internal > IP address. This is very common in implementations. > > thanks, > > From: behave-bounces@ietf.org [behave-bou= nces@ietf.org] on behalf of > meng.wei2@zte.com.cn [meng.wei2@zte.com.cn] > Sent: Tuesday, July 16, 2013 8:22 PM > To: Reinaldo Penno (repenno) > Cc: behave-bounces@ietf.org; behave@ietf.= org; Dan Wing (dwing) > Subject: Re: [BEHAVE] NAPGT request for comments, THANKS! > > Hi Reinaldo, > So I suppose <1-1024> might be used as NAT, <1025-65535> might be used = as > dynamic NAPT. > That is what this view says in the draft. > > Cheers, > Wei > > > behave-bounces@ietf.org 2013-07-17 09:52:= 34: > > > I'm not sure this is a good idea. There are still some protocols > > around that use ports < 1024 and maintaining the source port after > > translation in this range is important. > > > > From: behave-bounces@ietf.org [behave-b= ounces@ietf.org] on behalf of > > Dan Wing (dwing) > > Sent: Tuesday, July 16, 2013 3:30 PM > > To: meng.wei2@zte.com.cn > > Cc: behave@ietf.org > > Subject: Re: [BEHAVE] NAPGT request for comments, THANKS! > > > > > On Jul 15, 2013, at 2:43 AM, meng.wei2@zte.com.cn wrote: > > > > I have submitted a new draft. The objective is to solve a problem t= hat > > prevents an external client from accessing an internal server. > > > > https://datatracker.ietf.org/doc/draft-meng-behave-napgt/ > > > > I expect your comments. Thanks a lot! > > > > Draft-meng-behave-napgt appears to describe something that is very > > similar to the long-standing "DMZ host" configuration available on > > almost all residential-class NAT devices. I don't think we could > > standardize that behavior, but perhaps that is possible. > > > > Draft-meng-behave-napgt also describes an update to the port > > assignment behavior described in http://tools.ietf. > > org/html/rfc5382#section-7.1 (TCP) and http://tools.ietf. > > org/html/rfc4787#section-4.2.1 (UDP). If I understand Section 4 of > > draft-meng-behave-napgt properly, it is saying that NATs should not > > assign ports below 1024 to dynamic connections. This might be > > something worth considering for draft-ietf-behave-requirements-update? > > > > -d > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave --_000_CB1B483277FEC94E9B58357040EE5D02325CF41Exmbrcdx15ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <62B45759E35EA7489B91C1A5BF5199BB@emea.cisco.com> Content-Transfer-Encoding: quoted-printable


From: "meng.wei2@zte.com.cn" <meng.wei2@zte.com.cn>
Date: Wednesday, July 17, 2013 4:08= AM
To: "Reinaldo Penno (repenno)&= quot; <repenno@cisco.com> Cc: "behave-bounces@ietf.org" <behave-bounces@ietf.org>, "behave@ietf.org" <behave@ietf.org>, "Dan Wing (dwing)" <dwing@= cisco.com>
Subject: Re: [BEHAVE] NAPGT request= for comments, THANKS!


Hi,
  I got what the example means. <= /font>

  1-1024 is just an example, the = range could be any valid value.

  &qu= ot;<1-1024> might be used as NAT, <1025-65535> might be used as
dynamic NAPT", example is as below. <= br>
   +----------+     +-= ----+    +--------+
   + Internet + ----+ NAT +-= ---+ Server +
   +----------+     +-= ----+    +--------+

   (1) "<1-1024> might be used as= NAT" means,
       A server behind a NAT.
   A message, sent by server, its source por= t is in 1-1024 (or 4500-4501 or ...).
   The source address will be converted by N= AT, the source port remains
   the same.

[Senthil] Sorry, I didn=92t read the draft, but the above logic wont w= ork if there are multiple servers using the same source port.
Also, in some applications (I think rcmd, rshell etc), the source port= doesn=92t have to be preserved but must be below 1024.

Senthil



   (2)<1025-65535> might be used as dy= namic NAPT
       Meanwhile, many hosts are b= ehind NAT. They attempt to access to
    internet.
       A message, sent by a host, = both its source address and port will
    be converted by NAT, and the new port wi= ll be in 1025-65535.

   
It will make IP address assignment more effective.

Cheers,
Wei



behave-boun= ces@ietf.org  2013-07-17 12:36:30:

> Hi,
>
> I'm not sure what exactly you man by "might be used as NAT".=  
>
> 0-1024 might be used for NAPT in a FCFS basis where port
> preservation (this is what we are talking about here, right?) is neede= d.
>
> As a concrete example, many IPsec Servers still expect to see the
> source port within 0-1024 and preferably a specific source port. If > that source port is used by the NAT, and more than one IPsec client > is behind it, there are a some choices available.
>
> - Some funky IPSec ALG (implemented in many products)
> - Give a port above 1024 and hope for the best
> - Deny the connection
> - others..
>
> Other ports for the same public IP can be used by any other internal > IP address. This is very common in implementations.
>
> thanks,
>
> From: behave-bounces@ietf.o= rg [behave-bounces@ietf.org<= /a>] on behalf of
> meng.wei2@zte.com.cn [meng.wei2@zte.com.cn]
> Sent: Tuesday, July 16, 2013 8:22 PM
> To: Reinaldo Penno (repenno)
> Cc: behave-bounces@ietf.org= ; behave@ietf.org; Dan Wing (dwing)
> Subject: Re: [BEHAVE] NAPGT request for comments, THANKS!

>
> Hi Reinaldo,
>   So I suppose <1-1024> might be used as NAT, <1025-6553= 5> might be used as
> dynamic NAPT.
>   That is what this view says in the draft.
>
> Cheers,
> Wei
>
>
> behave-bounces@ietf.org= 2013-07-17 09:52:34:
>
> > I'm not sure this is a good idea. There are still some protocols =
> > around that use ports < 1024 and maintaining the source port a= fter
> > translation in this range is important.
> >
> > From: behave-bounces@i= etf.org [behave-bounces@ietf= .org] on behalf of
> > Dan Wing (dwing)
> > Sent: Tuesday, July 16, 2013 3:30 PM
> > To: meng.wei2@zte.com.cn<= /a>
> > Cc: behave@ietf.org
> > Subject: Re: [BEHAVE] NAPGT request for comments, THANKS!
>
> >
> > On Jul 15, 2013, at 2:43 AM, meng.wei2@zte.com.cn wrote:
> >
> >     I have submitted a new draft. The objective is to s= olve a problem that
> >     prevents an external client from accessing an inter= nal server.
> >
> >     https://datatracker.ietf.org/doc/draft-meng-behave-napgt= /
> >
> >     I expect your comments. Thanks a lot!
> >
> > Draft-meng-behave-napgt appears to describe something that is ver= y
> > similar to the long-standing "DMZ host" configuration a= vailable on
> > almost all residential-class NAT devices.  I don't think we = could
> > standardize that behavior, but perhaps that is possible.
> >
> > Draft-meng-behave-napgt also describes an update to the port
> > assignment behavior described in ht= tp://tools.ietf.
> > org/html/rfc5382#section-7.1 (TCP) and http://tools.ietf.
> > org/html/rfc4787#section-4.2.1 (UDP).  If I understand Secti= on 4 of
> > draft-meng-behave-napgt properly, it is saying that NATs should n= ot
> > assign ports below 1024 to dynamic connections.  This might = be
> > something worth considering for draft-ietf-behave-requirements-up= date?
> >
> > -d
> > _______________________________________________
> > Behave mailing list
> > Behave@ietf.org
> > https://= www.ietf.org/mailman/listinfo/behave
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.i= etf.org/mailman/listinfo/behave
 --_000_CB1B483277FEC94E9B58357040EE5D02325CF41Exmbrcdx15ciscoc_-- From ranjit.avasarala@nsn.com Tue Jul 16 22:50:58 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC5221F9D7E; Tue, 16 Jul 2013 22:50:58 -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 B+z7keczTavn; Tue, 16 Jul 2013 22:50:53 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id F225D21F9D75; Tue, 16 Jul 2013 22:50:51 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r6H5okNv000695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 17 Jul 2013 07:50:46 +0200 Received: from SGSIHTC002.nsn-intra.net ([10.159.225.19]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r6H5oYFP019158 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Jul 2013 07:50:45 +0200 Received: from SGSIHTC008.nsn-intra.net (10.159.225.25) by SGSIHTC002.nsn-intra.net (10.159.225.19) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 17 Jul 2013 13:48:52 +0800 Received: from SGSIMBX001.nsn-intra.net ([169.254.1.242]) by SGSIHTC008.nsn-intra.net ([10.159.225.25]) with mapi id 14.03.0123.003; Wed, 17 Jul 2013 13:48:52 +0800 From: "Avasarala, Ranjit (NSN - IN/Bangalore)" To: "Muthu Arul Mozhi Perumal (mperumal)" Thread-Topic: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt Thread-Index: AQHOgiT6JQEMzVPeD0imnIi9kp/qUZloXWjA Date: Wed, 17 Jul 2013 05:48:51 +0000 Message-ID: References: <20130715173816.18605.12504.idtracker@ietfa.amsl.com> <51E513BF.2040405@viagenie.ca> <51E536C1.1080507@viagenie.ca> <51E544BC.6000608@viagenie.ca> In-Reply-To: <51E544BC.6000608@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.225.122] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 3795 X-purgate-ID: 151667::1374040247-00002EAE-9CF423F9/0-0/0-0 X-Mailman-Approved-At: Wed, 17 Jul 2013 09:05:52 -0700 Cc: "behave@ietf.org" , "rtcweb@ietf.org" Subject: Re: [BEHAVE] [rtcweb] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 05:50:58 -0000 Hi Muthu Though using STUN request/response may be good for querying about consent, = I feel it is overloading the functionality of STUN. Many publicly available= STUN servers or those that are part of Call servers may not support this. Can't there be some other neutral mechanism to query peer's consent - throu= gh signaling?=20 Regards Ranjit -----Original Message----- From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of= ext Simon Perreault Sent: Tuesday, July 16, 2013 6:34 PM To: Muthu Arul Mozhi Perumal (mperumal) Cc: rtcweb@ietf.org; behave@ietf.org Subject: Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-f= reshness-04.txt Le 2013-07-16 14:43, Muthu Arul Mozhi Perumal (mperumal) a =E9crit : > |> |> Liveness timer: If no packets have been received on the local po= rt in > |> |> Tr seconds, the WebRTC browser MUST inform the JavaScript that > |> |> connectivity has been lost. The JavaScript application will use= this > |> |> notification however it desires (e.g., cease transmitting to the > |> |> remote peer, provide a notification to the user, etc.). > |> | > |> |This seems to me like it will not fulfill the goal set in the abstrac= t: > |> |"to ensure that a malicious JavaScript cannot use the browser as a > |> |platform for launching attacks". If the JavaScript is free to ignore = the > |> |notification from the browser, then it has no security benefits. If y= ou > |> |want to reach that goal, the browser needs to forcefully stop transmi= tting. > |> > |> That goal is fulfilled by the consent checks -- the browser would stop= transmitting everything on > |that candidate pair, including liveness checks, if there is a consent fa= ilure. > | > |That's not what the draft says. It says that the browser "notifies" the > |JS app. It needs to say that the browser MUST stop sending. >=20 > No. That section is about liveness check and its intention is just notify= the JavaScript of a potential connectivity loss. It is when the consent ch= eck fails the browser actually stops sending everything. Does the draft nee= d more text on the distinction between consent and liveness tests? Ah! No, you're right, and the text is already perfectly clear about this. No need to change. I was just confused. > |> |> When not actively sending traffic on a nominated candidate pair, > |> |> performing consent freshness does not serve any purpose from a > |> |> security perspective. > |> | > |> |I don't understand what this means. Why is the "security perspective" > |> |important here? Aren't we concerned about keepalives? > |> > |> You mean one could use keepalives (Binding indications) for launching = attacks, so consent freshness > |would be required for sending them as well? > | > |No. > | > |This is a section about keepalives. I just don't understand this > |sentence, and I don't understand why it talks about security. >=20 > Ok, let me elaborate: > - Consent freshness is not necessary when the browser is not sending any= =20 > traffic on a candidate pair. > - If the browser is not performing consent freshness on a candidate pair= =20 > for the above reason, it performs ICE keepalives (or RTP keepalives) to > refresh NAT bindings. >=20 > Of course, the browser could continue performing consent freshness even w= hen it is not sending any other traffic on that candidate pair and skip ICE= keepalives. Ah, ok I understand with your explanation. It makes sense. There should be a way to reformulate the text to make it clearer. Thanks, Simon _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From juberti@google.com Wed Jul 17 13:52:29 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A952C21F9FBD for ; Wed, 17 Jul 2013 13:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.912 X-Spam-Level: X-Spam-Status: No, score=-0.912 tagged_above=-999 required=5 tests=[AWL=-0.601, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qq0dvFsc+svo for ; Wed, 17 Jul 2013 13:52:29 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 9BDB721F9F59 for ; Wed, 17 Jul 2013 13:52:06 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id k10so5921177wiv.13 for ; Wed, 17 Jul 2013 13:52: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; bh=xIb0opwds0tFvYPj5l1fhcvdpSisaYIntBXdJYyLFbg=; b=CK2z3GinCjX0eABj3U/O+VFkyBP7wFhPay0KGRd/FdZbxzjruzugkg3MZgV3kWtQLJ ER3aow2Mzo/6NjTVFuHpSDaA5UGyD8r2AU5BcNcF22EtWsgFVgZRmFi7ulk0q8u+vlFy 1uCPRIA6wDo8i1/1TrpWdkSUBtsGQ+WMiFS1NLmnejujoAt1gzomGfK/taqvkF9Ijunk vagfqEYUqYimklS1a1kddhzB1NsRO1qn73IXP2pcumkoBRjbizwJfHrkG9aMr5oBXFQq X7wi6jgmuKrfizjwQKtPRi9TXspeknnUGImLDQ/F9X/ezbaxjVYZcwKOjdHiPXQiQw6y Esow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=xIb0opwds0tFvYPj5l1fhcvdpSisaYIntBXdJYyLFbg=; b=oWMcZndnCVFP8AVCAQd0g7cxfkebhyf83BxUUlKnbWQAVAmlHZFpGLE1+Co2KJ+DfP tWH75We4hZxNSLx9HXvwbjiYzOZJYx+7JVWVW62MZCwxt/ms6BqD4k+/T77XWxN2Tark 4lto3pS0AEcb5DG7tf+QD366zJvWcZWMVhrgSN+vMdvai9hVWLhDer7bcBrkQB29NDYG 4DpueDWwUpC5M5zDvhKcEZpKCBzhvnRqZdCf1QFUacz/1G7Kw94RK2PF2DR2P0xYj0QA /0lgAoTuK0B22WvQZM3cqlZUY9hOPORCSNq2z6POIzBfPSFlcZ8StRj8lZ+CxXIJbaAO Lsbw== X-Received: by 10.194.58.239 with SMTP id u15mr6169979wjq.87.1374094325595; Wed, 17 Jul 2013 13:52:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.62.113 with HTTP; Wed, 17 Jul 2013 13:51:45 -0700 (PDT) In-Reply-To: References: <20130715214906.5314.83583.idtracker@ietfa.amsl.com> From: Justin Uberti Date: Wed, 17 Jul 2013 16:51:45 -0400 Message-ID: To: Rajmohan Banavi Content-Type: multipart/alternative; boundary=047d7ba97b942a598a04e1bb44fa X-Gm-Message-State: ALoCoQkoX0T6KgshldpNl9NfszE1LnsBgHSH9l51emeDbIGxCXbIeeh47o2yygsx/rBW00DGTUtEXIPUpiNHBrbMMvJlHGfxwllzLR1NTA5AHhR37mfJSFIiVNKsuk1w5qZqDprNjsmM4twSpiAW5p0txnUh2xgbM0fxYANh5cjXf6eLOfayJSE00w/q3xjC+Dpfyw7WG32g Cc: behave@ietf.org, "rtcweb@ietf.org" Subject: Re: [BEHAVE] [rtcweb] Fwd: New Version Notification for draft-uberti-behave-turn-rest-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 20:52:30 -0000 --047d7ba97b942a598a04e1bb44fa Content-Type: text/plain; charset=UTF-8 Thanks for your comments. Responses inline. On Wed, Jul 17, 2013 at 2:56 PM, Rajmohan Banavi wrote: > Hi Justin, > > I reviewed draft-uberti-behave-turn-rest-00 and have the following > comments. > > 1. IMHO, calling the API as REST does not seem to be appropriate since > the API does not follow the REST principles of addressing/operating on a > resource. > > This came up in some earlier rtcweb feedback, but I think it falls within the definition of REST, as it meets the REST design constraints: http://en.wikipedia.org/wiki/**Representational_state_**transfer#Constraints > > 1. Sec 4.3 last paragraph - "Because the password is derived from the > USERNAME, successful verification of the MESSAGE-INTEGRITY ensures that the > username is trustworthy". I believe this validation is taken care of in the > TURN RFC itself. In order to generate the MESSAGE-INTEGRITY, the TURN > client generates a long term key which is computed as => key = > MD5(username ":" realm ":" SASLprep(password)). This key is used to perform > hmac on the message. The same is done on the TURN server end as well. If > the MESSAGE-INTEGRITY is verified, then it implies that the username is > trustworthy. So why not just generate a TURN password randomly? This > would avoid the need to have a secret key between the TURN server and the > webrtc app. Am I missing any scenario here where this extra security is > required? > > RFC 5766 doesn't make any guarantees regarding the USERNAME attribute. You know it hasn't been tampered with on the wire, via MESSAGE-INTEGRITY, but you don't know that the USERNAME value is in fact something that the *web server* previously gave out. The construct defines in this draft ties the password to the USERNAME, so that the client cannot change the USERNAME value and still have MESSAGE-INTEGRITY validate properly. This is also why a TURN password can't be generated randomly - the TURN server wouldn't know what random value to use when computing its own MESSAGE-INTEGRITY. > > 1. sec 4.1 Client - Does it make it more clear if we reword the last > sentence as - and the "password" value as input to generate the HMAC digest > key used while calculating MESSAGE-INTEGRITY hash. > > Yes, thanks. > > 1. Sec 5.1 Revocation - Why is revoking of specific credentials not > possible? Probably need more clarity on who would try to revoke the > credentials and under what scenario? > > There is no way to revoke credentials through the REST interface, since there is no communication path between the web server and the TURN server. > > 1. Sec 5.2 Key Rotation - I presume here that the shared secret > mentioned is the one shared between the TURN server and the webrtc > application. The TURN password once generated using say secretkey1 and > user1 will be valid on the TURN server till the expiry timeout (as per > suggested value of 1 day) value. Why do we then need the TURN server to > validate the message integrity against 2 secret keys? Wouldn't this > behavior not contradict the one stated in TURN RFC? > > The lifetime of vended credentials may be 1 day, but if key rotation is performed, sometimes a key rotation will occur during the lifetime of a credential set. As such, the credentials will always need to be validated against secretkey1 (old) and secretkey2(current) until 1 day after the key rotation. > > > Thanks, > Rajmohan > MindBricks > > > On Tue, Jul 16, 2013 at 3:22 AM, Justin Uberti wrote: > >> I have changed the WG for this draft from RTCWEB to BEHAVE. Many, but not >> all of the comments I received on the RTCWEB mailing list have been >> addressed. >> >> BEHAVE chairs, I would like 10 minutes of agenda time to discuss this >> draft. >> >> ---------- Forwarded message ---------- >> From: >> Date: Mon, Jul 15, 2013 at 5:49 PM >> Subject: New Version Notification for draft-uberti-behave-turn-rest-00.txt >> To: Justin Uberti >> >> >> >> A new version of I-D, draft-uberti-behave-turn-rest-00.txt >> has been successfully submitted by Justin Uberti and posted to the >> IETF repository. >> >> Filename: draft-uberti-behave-turn-rest >> Revision: 00 >> Title: A REST API For Access To TURN Services >> Creation date: 2013-07-15 >> Group: Individual Submission >> Number of pages: 8 >> URL: >> http://www.ietf.org/internet-drafts/draft-uberti-behave-turn-rest-00.txt >> Status: >> http://datatracker.ietf.org/doc/draft-uberti-behave-turn-rest >> Htmlized: >> http://tools.ietf.org/html/draft-uberti-behave-turn-rest-00 >> >> >> Abstract: >> This document describes a proposed standard REST API for obtaining >> access to TURN services via ephemeral (i.e. time-limited) >> credentials. These credentials are vended by a web service over >> HTTP, and then supplied to and checked by a TURN server using the >> standard TURN protocol. The usage of ephemeral credentials ensures >> that access to the TURN server can be controlled even if the >> credentials can be discovered by the user, as is the case in WebRTC >> where TURN credentials must be specified in Javascript. >> >> >> >> >> The IETF Secretariat >> >> >> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> > > > -- > > Life is here and now, not yesterday, not tomorrow...! > --047d7ba97b942a598a04e1bb44fa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for your comments. Responses inline.

On Wed, Jul 17, 2013 at 2:56 PM,= Rajmohan Banavi <rajmohanbanavi@gmail.com> wrote:
Hi Justin,

I reviewed=C2=A0draft-uberti-behav= e-turn-rest-00=C2=A0and have the following = comments.
  1. IMHO, calling the API as REST does not seem to be appropriate since= the API does not follow the REST principles of addressing/operating on a r= esource.
This came up in some earlie= r rtcweb feedback, but I think it falls within the definition of REST, as it meets the REST design constraints:
http://en.wikipedia.org/wiki/Representational_state_tr= ansfer#Constraints
=C2=A0
  1. Sec 4.3 last par= agraph - "Because the password is derived from the USERNAME, successfu= l verification of the MESSAGE-INTEGRITY ensures that the username is trustw= orthy". I believe this validation is taken care of in the TURN RFC its= elf. In order to generate the MESSAGE-INTEGRITY, the TURN client generates = a long term key which is computed as =3D>=C2=A0key =3D MD5(username ":" realm ":" SASLprep(passwo= rd)). This key is used to perform hmac on the message. The same is done on = the TURN server end as well. If the MESSAGE-INTEGRITY is verified, then it = implies that the username is trustworthy. So=C2=A0why not just gener= ate a TURN password randomly? This would avoid the need to have a secret ke= y between the TURN server and the webrtc app. Am I missing any scenario her= e where this extra security is required?
RFC 5766 doesn't make any guarantees= regarding the USERNAME attribute. You know it hasn't been tampered wit= h on the wire, via MESSAGE-INTEGRITY, but you don't know that the USERN= AME value is in fact something that the *web server* previously gave out.= =C2=A0

The construct defines in this draft ties the pass= word to the USERNAME, so that the client cannot change the USERNAME value a= nd still have MESSAGE-INTEGRITY validate properly.

This is also why a TURN password can't be generated randomly - the= TURN server wouldn't know what random value to use when computing its = own MESSAGE-INTEGRITY.
  1. sec 4.1 Client - Does it make it more clear if we reword the last sente= nce as - and the "password" value as input to generate the HMAC d= igest key used while calculating MESSAGE-INTEGRITY hash.
Yes, thanks.=C2=A0
  1. Sec 5.1 Revocation - Why is revoking of specific credentials n= ot possible? Probably need more clarity on who would try to revoke the cred= entials and under what scenario?
There is no way to revoke credentials through the REST interface, since the= re is no communication path between the web server and the TURN server.=C2= =A0
  1. Sec 5.2 Key Rotation - I presume here that the shared secret mentioned = is the one shared between the TURN server and the webrtc application. The T= URN password once generated using say secretkey1 and user1 will be valid on= the TURN server till the expiry timeout (as per suggested value of 1 day) = value. Why do we then need the TURN server to validate the message integrit= y against 2 secret keys? Wouldn't this behavior not contradict the one = stated in TURN RFC?
The lifetime of vended credentials may b= e 1 day, but if key rotation is performed, sometimes a key rotation will oc= cur during the lifetime of a credential set. As such, the credentials will = always need to be validated against secretkey1 (old) and secretkey2(current= ) until 1 day after the key rotation.
Thanks,
Rajmohan
MindBricks


On Tue, Ju= l 16, 2013 at 3:22 AM, Justin Uberti <juberti@google.com> w= rote:
I have changed the = WG for this draft from RTCWEB to BEHAVE. Many, but not all of the comments = I received on the RTCWEB mailing list have been addressed.

BEHAVE chairs, I would like= 10 minutes of agenda time to discuss this draft.

---------- Forwarded message ----------
F= rom: <internet-drafts@ietf.org>
Date: Mon, Jul 15, 2013 at 5:49 PM
Subject: New Version Notification for= draft-uberti-behave-turn-rest-00.txt
To: Justin Uberti <justin@uberti.name>



A new version of I-D, draft-uberti-behave-turn-rest-00.txt
has been successfully submitted by Justin Uberti and posted to the
IETF repository.

Filename: =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-uberti-behave-turn-rest
Revision: =C2=A0 =C2=A0 =C2=A0 =C2=A000
Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A REST API For Access To TURN Ser= vices
Creation date: =C2=A0 2013-07-15
Group: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Number of pages: 8
URL: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = http://www.ietf.org/internet-drafts/draft-uberti-behave-turn-rest-00.txt
Status: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://datatrack= er.ietf.org/doc/draft-uberti-behave-turn-rest
Htmlized: =C2=A0 =C2=A0 =C2=A0 =C2=A0http://tools.ietf.org/h= tml/draft-uberti-behave-turn-rest-00


Abstract:
=C2=A0 =C2=A0This document describes a proposed standard REST API for obtai= ning
=C2=A0 =C2=A0access to TURN services via ephemeral (i.e. time-limited)
=C2=A0 =C2=A0credentials. =C2=A0These credentials are vended by a web servi= ce over
=C2=A0 =C2=A0HTTP, and then supplied to and checked by a TURN server using = the
=C2=A0 =C2=A0standard TURN protocol. =C2=A0The usage of ephemeral credentia= ls ensures
=C2=A0 =C2=A0that access to the TURN server can be controlled even if the =C2=A0 =C2=A0credentials can be discovered by the user, as is the case in W= ebRTC
=C2=A0 =C2=A0where TURN credentials must be specified in Javascript.




The IETF Secretariat




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




--

Life is here and now, not yesterday, not to= morrow...!

--047d7ba97b942a598a04e1bb44fa-- From ekr@rtfm.com Wed Jul 17 15:00:27 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7476621F9E5C for ; Wed, 17 Jul 2013 15:00:27 -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 EmkMSbO-Yvys for ; Wed, 17 Jul 2013 15:00:21 -0700 (PDT) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by ietfa.amsl.com (Postfix) with ESMTP id 7266421F9E0B for ; Wed, 17 Jul 2013 15:00:21 -0700 (PDT) Received: by mail-qc0-f182.google.com with SMTP id e10so1364531qcy.41 for ; Wed, 17 Jul 2013 15:00:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=1kl0FiMgbzIOlmmkviZphtkH32h7K+ZXj5O3h1Rmku4=; b=eBqyZbV5Uv9Z5vhF9bNPY6yvOYU/jcP66e9wikGfJJVI7E+1ktxuF83jGUiyoyEo+B T7l+HALUvE7VhG8nh9APOXQyeBabozoSSup6y0qDH8BFQwMGC94SEdcUCuX0eg2FaDlw rY65A7rIWtwYcD/77MsF9YkACoQyA+ZwPKAQ5iw2cHO6kehPsaM3Rsn4niCS9yH+WUzG MMiyj7qr94JRANpMF4zGv3CYGunoV2BtfNNBTajR6jqa628qsKfj8AtuqKQ9eDq59l7r zWRkzfsEslXJB3bVfhXoKIfLb95poGlaekUvfjZY4JIVqFyhAd4GaYiMMwwudBGEodX+ vITg== X-Received: by 10.49.85.4 with SMTP id d4mr10169429qez.10.1374098420747; Wed, 17 Jul 2013 15:00:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.48.234 with HTTP; Wed, 17 Jul 2013 14:59:40 -0700 (PDT) X-Originating-IP: [203.69.99.16] In-Reply-To: References: <20130715173816.18605.12504.idtracker@ietfa.amsl.com> <51E513BF.2040405@viagenie.ca> From: Eric Rescorla Date: Thu, 18 Jul 2013 05:59:40 +0800 Message-ID: To: "Muthu Arul Mozhi Perumal (mperumal)" Content-Type: multipart/alternative; boundary=047d7bb03e6a41619d04e1bc38e6 X-Gm-Message-State: ALoCoQkQzsvDqOUAVqe5cpYXmtpmW+cwWWltURz/gtYEGIGy311A0yZemqlIGtbvA3rsO+o8zJDf Cc: "behave@ietf.org" , "rtcweb@ietf.org" Subject: Re: [BEHAVE] [rtcweb] FW: I-D Action: draft-muthu-behave-consent-freshness-04.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 22:00:27 -0000 --047d7bb03e6a41619d04e1bc38e6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Jul 17, 2013 at 8:47 PM, Muthu Arul Mozhi Perumal (mperumal) < mperumal@cisco.com> wrote: > |Uh, then how would they be sent to the other side?**** > > ** ** > > Ah, the browser would have to modify the SDP when it is sent on the wire.= . > I don't really see how this helps since the server is going to see it and call tell the JS (remember, that's where the JS came from). -Ekr > > |As far as I can tell, with any plausible API SDES requires exposing the > keys to JS.**** > > ** ** > > That helps..thanks.**** > > ** ** > > Muthu**** > > ** ** > > *From:* Eric Rescorla [mailto:ekr@rtfm.com] > *Sent:* Wednesday, July 17, 2013 2:32 PM > *To:* Muthu Arul Mozhi Perumal (mperumal) > *Cc:* Simon Perreault; behave@ietf.org; rtcweb@ietf.org > *Subject:* Re: [rtcweb] [BEHAVE] FW: I-D Action: > draft-muthu-behave-consent-freshness-04.txt**** > > ** ** > > ** ** > > ** ** > > On Tue, Jul 16, 2013 at 6:49 PM, Muthu Arul Mozhi Perumal (mperumal) < > mperumal@cisco.com> wrote:**** > > [Added rtcweb since I am not sure if everyone involved there are followin= g > this discussion in behave] > > Thanks for the review. See inline.. > > |-----Original Message----- > |From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf > Of Simon Perreault > |Sent: Tuesday, July 16, 2013 3:05 PM > |To: behave@ietf.org > |Subject: Re: [BEHAVE] FW: I-D Action: > draft-muthu-behave-consent-freshness-04.txt > | > |Le 2013-07-15 20:42, Muthu Arul Mozhi Perumal (mperumal) a =E9crit :**** > > |> The text and the algorithm in the draft are significantly simplified i= n > this updated version. > |> > |> Comments welcome.. > |**** > > |MUCH better introduction. Now I feel like I understand the need exactly. > | > |The "Design Considerations" section is still very confusing to me. > | > |> Though ICE specifies STUN Binding indications to be used for > |> keepalives, it requires that an agent be prepared to receive > |> connectivity check as well. If a connectivity check is received, a > |> response is generated, but there is no impact on ICE processing, as > |> described in section 10 of [RFC5245]. > | > |...so? Why is "an impact on ICE processing" necessary? > > Meant to stress these Binding request/response doesn't trigger an ICE > restart.. > > | > |> While a WebRTC browser could verify whether the peer continues to > |> send SRTCP reports before sending traffic to the peer, the usage of > |> SRTCP together with Security Descriptions [RFC4568] requires exposi= ng > |> the media keys to the JavaScript and renders SRTCP unsuitable for > |> consent freshness. > | > |Why does it "require exposing the media keys to the JavaScript"? Is this > |because of a law of nature, or is it because of the way the JavaScript > |API is being designed? Could the JS API be changed to accommodate > |SRTCP+SDES? > > That's how the API construct looks like today -- the JavaScript would get > an SDP blob from the browser containing the crypto keys used for SDES-SRT= P. > Of course, the browser could hide those keys by putting a "****" in SDP -= :). > **** > > ** ** > > ** ** > > Uh, then how would they be sent to the other side?**** > > ** ** > > As far as I can tell, with any plausible API SDES requires exposing the > keys to JS.**** > > ** ** > > -Ekr**** > > ** ** > --047d7bb03e6a41619d04e1bc38e6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Jul 17, 2013 at 8:47 PM, Muthu Arul Mozhi Perumal (mperumal= ) <mperumal@cisco.com> wrote:

|Uh, then how would they be sent to the other side?=

=A0

Ah, the browser would have to modify the SDP when it= is sent on the wire..


I don't really see how this helps since the server is going to see it a= nd call tell
the JS (remember, that's where the JS came from)= .

-Ekr

=A0

|As far as I can tell, with any plausible API SDES require= s exposing the keys to JS.

=A0

That helps..thanks.

=A0

Muthu

=A0

From: Eric Res= corla [mailto:ekr@rtfm.co= m]
Sent: Wednesday, July 17, 2013 2:32 PM
To: Muthu Arul Mozhi Perumal (mperumal)
Cc: Simon Perreault; behave@ietf.org; rtcweb@ietf.org
Subject: Re: [rtcweb] [BEHAVE] FW: I-D Action: draft-muthu-behave-co= nsent-freshness-04.txt

=A0

=A0

=A0

On Tue, Jul 16, 2013 at 6:49 PM, Muthu Arul Mozhi Pe= rumal (mperumal) <mperumal@cisco.com> wrote:

[Added rtcweb since I am not sure if everyone involv= ed there are following this discussion in behave]

Thanks for the review. See inline..

|-----Original Message-----
|From: behave-= bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of Simon Perreault |Sent: Tuesday, July 16, 2013 3:05 PM
|To: behave@ietf.org
|Subject: Re: [BEHAVE] FW: I-D Action: draft-muthu-behave-consent-freshness= -04.txt
|
|Le 2013-07-15 20:42, Muthu Arul Mozhi Perumal (mperumal) a =E9crit :

|> The text and the algorithm in the draft are si= gnificantly simplified in this updated version.
|>
|> Comments welcome..
|

|MUCH better introduction. Now I feel like I underst= and the need exactly.
|
|The "Design Considerations" section is still very confusing to m= e.
|
|> =A0 =A0Though ICE specifies STUN Binding indications to be used for |> =A0 =A0keepalives, it requires that an agent be prepared to receive |> =A0 =A0connectivity check as well. =A0If a connectivity check is rece= ived, a
|> =A0 =A0response is generated, but there is no impact on ICE processin= g, as
|> =A0 =A0described in section 10 of [RFC5245].
|
|...so? Why is "an impact on ICE processing" necessary?

Meant to stress these Binding request/response doesn't trigger an ICE r= estart..

|
|> =A0 =A0While a WebRTC browser could verify whether the peer continues= to
|> =A0 =A0send SRTCP reports before sending traffic to the peer, the usa= ge of
|> =A0 =A0SRTCP together with Security Descriptions [RFC4568] requires e= xposing
|> =A0 =A0the media keys to the JavaScript and renders SRTCP unsuitable = for
|> =A0 =A0consent freshness.
|
|Why does it "require exposing the media keys to the JavaScript"?= Is this
|because of a law of nature, or is it because of the way the JavaScript
|API is being designed? Could the JS API be changed to accommodate
|SRTCP+SDES?

That's how the API construct looks like today -- the JavaScript would g= et an SDP blob from the browser containing the crypto keys used for SDES-SR= TP. Of course, the browser could hide those keys by putting a "****&qu= ot; in SDP -:).

=A0

=A0

Uh, then how would they be sent to the other side?

=A0

As far as I can tell, with any plausible API SDES re= quires exposing the keys to JS.

=A0

-Ekr

=A0


--047d7bb03e6a41619d04e1bc38e6-- From juberti@google.com Wed Jul 17 15:12:10 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C348821F9FCC for ; Wed, 17 Jul 2013 15:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[AWL=0.299, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 4iveyWLLZ70T for ; Wed, 17 Jul 2013 15:12:09 -0700 (PDT) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 28BE221F9EAD for ; Wed, 17 Jul 2013 15:12:02 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id q58so2325159wes.33 for ; Wed, 17 Jul 2013 15:12:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=q9hk7ezbueSHDE6DyXVKPX334cUUJEP2DDnXj8fImEk=; b=J74VEE0yXBGBdpZc9KVEuhj9jOgrQJWqY2qdIyG9SnN8HoWRpT3PdcVPAhC6ojCHzF nxd4zLAWkHI022GI5i5mdYAJKsHmUEfEzbZiMqCDUlIgVMK3QcH3AXd4cB43OBUJ/5jY P4UJXNS/flA5cKATDlZ2YHq7vUCj7T5l6HRiJ1cCMuEY2RKE3XMthyog2T6BWFg5shAJ 4EnL+8Lp/uV3PE8EbB22EG162vGx5eXuWQdV+oDCXW4ZNvoFtOFdnSBetq/FHh8BtvsU tX637dA73/eIb3dNeckN+TfZKO4eZvP9i+Qb/igAlp+93ncalbKHKkzCs5WGhmzmlm54 n8zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=q9hk7ezbueSHDE6DyXVKPX334cUUJEP2DDnXj8fImEk=; b=XctkL5RF3oQymXPrUwdYI27x9qc92ksFjQm8A+WTja9YSyoBN6UQUZR6MqEaiWyzl/ qU2GqClGy6PvXj/jBdAzGaWflPeBjNHFMPb7W7LWF9OIHMMd/cJllejmpmlOSiZnW/+V q4BzWPYbsekw72L/vRRqrdL3w7WrKYaPHwDXdCNy6VXKfNANhOsZ00Yrz9l4LiNkzrN0 p3sn6btj0Cbl3Eonk+nxc5RsJfwtdSy6LzUcUnrdcss2J4A0jDhFCmcLF31gEGlZzA+d K8kTSU8dDOyBhZ+dRCYJpFei+oHp5l8TdkNTdMIgo9aEaUjkUWHttc/gFOU4WmVtxna4 1G/A== X-Received: by 10.180.80.6 with SMTP id n6mr17535435wix.59.1374099122181; Wed, 17 Jul 2013 15:12:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.62.113 with HTTP; Wed, 17 Jul 2013 15:11:42 -0700 (PDT) In-Reply-To: References: <20130715214906.5314.83583.idtracker@ietfa.amsl.com> <51E70106.8060100@goodadvice.pages.de> From: Justin Uberti Date: Wed, 17 Jul 2013 18:11:42 -0400 Message-ID: To: Rajmohan Banavi Content-Type: multipart/alternative; boundary=14dae9cc955c1083aa04e1bc627c X-Gm-Message-State: ALoCoQm8gyZc1IM1hANMZXPos4fbj9W0AdoEg6ntguASg94iyTPjDEOYrnDyub53ubgR/MHqoI7BzO6WCVcP8Q/CTsO8nk1cSSbLnKkGp/EQxe7ha/LAgUsf4BcghzjSrO/XM2FaI+qTD9XJzWsmnTGuqrEJri02QNOM5nSxiV/Kt3MjbuP+lkb2c8GijOpRTaT8Vr4We6vE Cc: "rtcweb@ietf.org" , Philipp Hancke , behave@ietf.org Subject: Re: [BEHAVE] [rtcweb] Fwd: New Version Notification for draft-uberti-behave-turn-rest-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 22:12:10 -0000 --14dae9cc955c1083aa04e1bc627c Content-Type: text/plain; charset=UTF-8 On Wed, Jul 17, 2013 at 5:09 PM, Rajmohan Banavi wrote: > Thanks for the detailed example. I agree with the entire flow you have > given. My only concern is - why should the ephemeral password be generated > by TURN server using HMAC SHA on then username string? Why can't this be > some random unique string? > > Taking your example - > > Suppose TURN server generates credentials, username = > "12334939:mbzrxpgjys" and password ="+somerandomstring+". This is a > randomly generated string and passed onto webrtc app. The TURN server also > stores these credentials for later validation. > var iceServer = { > "username": 12334939:mbzrxpgjys, > "credential": +somerandomstring+, > }; > > These credentials are passed from JS to the webrtc client stack in the > browser. > > On Browser WebTRC Client. > key = MD5(12334939:mbzrxpgjys ":" realm ":" +somerandomstring+) > Similarly on the TURN server, the key for MESSAGE-INTEGRITY is calculated > using > key = MD5(12334939:mbzrxpgjys ":" realm ":" +somerandomstring+) > > So the browser and turn server use the same input to the M-I. The one > implementation related advantage I see with this way of generation of TURN > password using HMAC is that the TURN server need not really store the HMAC > generated password, but can calculate the same using the USERNAME attribute > in the received TURN request. > Correct, but that is a significant advantage, especially when the web and TURN servers are separate entities. > > In fact, I do not see why the sharedsecret needs to be shared between the > TURN server and the WebRTC application. The sharedsecret key "secret" is > only required by the TURN server for validating the received TURN ALLOCATE > requests once it has generated and sent out the ephemeral credentials. What > does the WebRTC application do with the shared secret key? > The WebRTC client application doesn't see the secret key, this is only shared between the web and TURN servers. > > On Thu, Jul 18, 2013 at 2:09 AM, Philipp Hancke > wrote: > >> Am 17.07.2013 20:56, schrieb Rajmohan Banavi: >> >> Hi Justin, >>> >>> I reviewed draft-uberti-behave-turn-rest-**00 and have the following >>> comments. >>> >> [...] >> >>> 2. Sec 4.3 last paragraph - "Because the password is derived from the >>> >>> USERNAME, successful verification of the MESSAGE-INTEGRITY ensures >>> that the >>> username is trustworthy". I believe this validation is taken care of >>> in the >>> TURN RFC itself. In order to generate the MESSAGE-INTEGRITY, the TURN >>> client generates a long term key which is computed as => key = >>> MD5(username ":" realm ":" SASLprep(password)). This key is used to >>> perform >>> hmac on the message. The same is done on the TURN server end as >>> well. If >>> the MESSAGE-INTEGRITY is verified, then it implies that the username >>> is >>> trustworthy. >>> >> >> Let me try to address that with a lenghty example: >> The web server returns >> password = BASE64(HMAC-SHA1(username, sharedsecret)) >> to the browser. >> >> For example, with username = "12334939:mbzrxpgjys" and sharedsecret >> "secret", the password given to the browser would be >> "+4pCXR06gx/cqAikLYnBajtZW6E=" (hopefully) >> >> >> >> >> The browser passes the username, uri and password to it's webrtc stack. >> The password is exposed to the user of the browser (which might be anyone >> surfing your website) during that process. >> >> That stack does long term authentication and uses this password string as >> input for calculating MESSAGE-INTEGRITY with >> key = MD5(username ":" realm ":" SASLprep(password)) >> >> For the example this would be >> key =MD5("12334939:mbzrxpgjys" ":" realm ":" SASLprep("+4pCXR06gx/** >> cqAikLYnBajtZW6E=") >> >> >> >> >> On the TURN server, the key for MESSAGE-INTEGRITY is calculated using >> key = MD5(username ":" realm ":" SASLprep(BASE64(HMAC-SHA1(**USERNAME, >> sharedsecret)) >> >> So for the example this would be >> = MD5("12334939:mbzrxpgjys" ":" realm ":" SASLprep(BASE64(HMAC-SHA1("**12334939:mbzrxpgjys", >> "secret")) >> = MD5("12334939:mbzrxpgjys" ":" realm ":" SASLprep("+4pCXR06gx/** >> cqAikLYnBajtZW6E=") >> >> So the browser and turn server use the same input to the M-I. This can be >> done by looking at the request alone given the shared secret. >> >> >> Does that make it clearer? >> >> philipp, >> who only understood it after implementing it >> > > > > -- > > Life is here and now, not yesterday, not tomorrow...! > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --14dae9cc955c1083aa04e1bc627c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Wed, Jul 17, 2013 at 5:09 PM, Rajmohan Banavi = <rajmohanb= anavi@gmail.com> wrote:
Thanks for the detailed exa= mple. I agree with the entire flow you have given. My only concern is - why= should the ephemeral password be generated by TURN server using HMAC SHA o= n then username string? Why can't this be some random unique string?
Taking your example -=C2=A0

Suppose TURN server ge= nerates credentials, username =3D "12334939:mbzrxpgjys" and passw= ord =3D&= quot;+somerandomstring+". This is a randomly generated string and pass= ed onto webrtc app. The TURN server also stores these credentials for later= validation.
var iceServer =3D {
= =C2=A0 =C2=A0 =C2=A0"username":= =C2=A012= 334939:mbzrxpgjys,
=C2=A0 =C2=A0 =C2=A0"credential&= quot;:=C2=A0+somerandomstring+,
=C2=A0 =C2=A0};

These credentials are passed from JS to the webrtc clien= t stack in the browser.

On Brows= er WebTRC Client.=C2=A0
key =3D MD5(12334939:mbzrxpgjys=C2=A0":" realm ":&= quot;=C2=A0+somerandomstring+)
Similarly = on the TURN server, the key for MESSAGE-INTEGRITY is calculated using
key =3D MD5(12334939:mbzrxpgjys= =C2=A0":&q= uot; realm ":"=C2=A0+somerandomstring+)

So the browser and turn server u= se the same input to the M-I. The one implementation related advantage I se= e with this way of generation of TURN password using HMAC is that the TURN = server need not really store the HMAC generated password, but can calculate= the same using the USERNAME attribute in the received TURN request.=

Correct, but that is a significant a= dvantage, especially when the web and TURN servers are separate entities.= =C2=A0

In = fact, I do not see why the sharedsecret needs to be shared between the TURN= server and the WebRTC application. The sharedsecret key "secret"= is only required by the TURN server for validating the received TURN ALLOC= ATE requests once it has generated and sent out the ephemeral credentials. = What does the WebRTC application do with the shared secret key?

The WebRTC client application doesn&= #39;t see the secret key, this is only shared between the web and TURN serv= ers.
=C2=A0

On Thu, Jul 18, 2013 at 2:09 AM, Ph= ilipp Hancke <fippo@goodadvice.pages.de> wrote:
Am 17.07.2013 20:56, schrieb Rajmohan Banavi= :

Hi Justin,

I reviewed draft-uberti-behave-turn-rest-00 and have the following c= omments.
[...]
=C2=A0 =C2=A0 2. Sec 4.3 last paragraph - "Because the password is der= ived from the

=C2=A0 =C2=A0 USERNAME, successful verification of the MESSAGE-INTEGRITY en= sures that the
=C2=A0 =C2=A0 username is trustworthy". I believe this validation is t= aken care of in the
=C2=A0 =C2=A0 TURN RFC itself. In order to generate the MESSAGE-INTEGRITY, = the TURN
=C2=A0 =C2=A0 client generates a long term key which is computed as =3D>= key =3D
=C2=A0 =C2=A0 MD5(username ":" realm ":" SASLprep(passw= ord)). This key is used to perform
=C2=A0 =C2=A0 hmac on the message. The same is done on the TURN server end = as well. If
=C2=A0 =C2=A0 the MESSAGE-INTEGRITY is verified, then it implies that the u= sername is
=C2=A0 =C2=A0 trustworthy.

Let me try to address that with a lenghty example:
The web server returns
password =3D BASE64(HMAC-SHA1(username, sharedsecret))
to the browser.

For example, with username =3D "12334939:mbzrxpgjys" and sharedse= cret "secret", the password given to the browser would be
"+4pCXR06gx/cqAikLYnBajtZW6E=3D" (hopefully)




The browser passes the username, uri and password to it's webrtc stack.=
The password is exposed to the user of the browser (which might be anyone s= urfing your website) during that process.

That stack does long term authentication and uses this password string as i= nput for calculating MESSAGE-INTEGRITY with
key =3D MD5(username ":" realm ":" SASLprep(password))<= br>
For the example this would be
key =3DMD5("12334939:mbzrxpgjys" ":" realm ":"= ; SASLprep("+4pCXR06gx/cqAikLYnBajtZW6E=3D")




On the TURN server, the key for MESSAGE-INTEGRITY is calculated using
key =3D MD5(username ":" realm ":" SASLprep(BASE64(HMAC= -SHA1(USERNAME, sharedsecret))

So for the example this would be
=C2=A0=3D MD5("12334939:mbzrxpgjys" ":" realm ":&q= uot; SASLprep(BASE64(HMAC-SHA1("12334939:mbzrxpgjys", &quo= t;secret"))
=C2=A0=3D MD5("12334939:mbzrxpgjys" ":" realm ":&q= uot; SASLprep("+4pCXR06gx/cqAikLYnBajtZW6E=3D")

So the browser and turn server use the same input to the M-I. This can be d= one by looking at the request alone given the shared secret.


Does that make it clearer?

philipp,
who only understood it after implementing it



--

Life is here and now, not yesterday, not tomorrow...!

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


--14dae9cc955c1083aa04e1bc627c-- From meng.wei2@zte.com.cn Wed Jul 17 18:20:27 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E241021F9971; Wed, 17 Jul 2013 18:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.677 X-Spam-Level: X-Spam-Status: No, score=-100.677 tagged_above=-999 required=5 tests=[AWL=-0.432, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, MIME_BASE64_TEXT=1.753, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YtGY7dvuZK+B; Wed, 17 Jul 2013 18:20:22 -0700 (PDT) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 0694C21F9ABB; Wed, 17 Jul 2013 18:20:21 -0700 (PDT) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id 11D8912FEBC9; Thu, 18 Jul 2013 09:19:56 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id r6I1JkZs043238; Thu, 18 Jul 2013 09:19:46 +0800 (GMT-8) (envelope-from meng.wei2@zte.com.cn) In-Reply-To: To: "Senthil Sivakumar (ssenthil)" MIME-Version: 1.0 X-KeepSent: B6524529:8A50AC25-48257BAC:00046B40; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: meng.wei2@zte.com.cn Date: Thu, 18 Jul 2013 09:19:46 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2013-07-18 09:19:39, Serialize complete at 2013-07-18 09:19:39 Content-Type: multipart/alternative; boundary="=_alternative 0007626448257BAC_=" X-MAIL: mse02.zte.com.cn r6I1JkZs043238 Cc: "Reinaldo Penno \(repenno\)" , "behave-bounces@ietf.org" , "behave@ietf.org" , "Dan Wing \(dwing\)" Subject: Re: [BEHAVE] NAPGT request for comments, THANKS! X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 01:20:27 -0000 This is a multipart message in MIME format. --=_alternative 0007626448257BAC_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksDQogIFBsZWFzZSBzZWUgaW5saW5lLg0KDQpUaGFua3MsDQpXZWkNCg0KIlNlbnRoaWwgU2l2 YWt1bWFyIChzc2VudGhpbCkiIDxzc2VudGhpbEBjaXNjby5jb20+ICAyMDEzLTA3LTE3IDIxOjMw OjI0Og0KDQo+IEZyb206ICJtZW5nLndlaTJAenRlLmNvbS5jbiIgPG1lbmcud2VpMkB6dGUuY29t LmNuPg0KPiBEYXRlOiBXZWRuZXNkYXksIEp1bHkgMTcsIDIwMTMgNDowOCBBTQ0KPiBUbzogIlJl aW5hbGRvIFBlbm5vIChyZXBlbm5vKSIgPHJlcGVubm9AY2lzY28uY29tPg0KPiBDYzogImJlaGF2 ZS1ib3VuY2VzQGlldGYub3JnIiA8YmVoYXZlLWJvdW5jZXNAaWV0Zi5vcmc+LCANCiJiZWhhdmVA aWV0Zi5vcmciIDwNCj4gYmVoYXZlQGlldGYub3JnPiwgIkRhbiBXaW5nIChkd2luZykiIDxkd2lu Z0BjaXNjby5jb20+DQo+IFN1YmplY3Q6IFJlOiBbQkVIQVZFXSBOQVBHVCByZXF1ZXN0IGZvciBj b21tZW50cywgVEhBTktTIQ0KPiANCj4gDQo+IEhpLCANCj4gICBJIGdvdCB3aGF0IHRoZSBleGFt cGxlIG1lYW5zLiANCj4gDQo+ICAgMS0xMDI0IGlzIGp1c3QgYW4gZXhhbXBsZSwgdGhlIHJhbmdl IGNvdWxkIGJlIGFueSB2YWxpZCB2YWx1ZS4NCj4gDQo+ICAgIjwxLTEwMjQ+IG1pZ2h0IGJlIHVz ZWQgYXMgTkFULCA8MTAyNS02NTUzNT4gbWlnaHQgYmUgdXNlZCBhcyANCj4gZHluYW1pYyBOQVBU IiwgZXhhbXBsZSBpcyBhcyBiZWxvdy4gDQo+IA0KPiAgICArLS0tLS0tLS0tLSsgICAgICstLS0t LSsgICAgKy0tLS0tLS0tKyANCj4gICAgKyBJbnRlcm5ldCArIC0tLS0rIE5BVCArLS0tLSsgU2Vy dmVyICsgDQo+ICAgICstLS0tLS0tLS0tKyAgICAgKy0tLS0tKyAgICArLS0tLS0tLS0rIA0KPiAN Cj4gICAgKDEpICI8MS0xMDI0PiBtaWdodCBiZSB1c2VkIGFzIE5BVCIgbWVhbnMsIA0KPiAgICAg ICAgQSBzZXJ2ZXIgYmVoaW5kIGEgTkFULiANCj4gICAgQSBtZXNzYWdlLCBzZW50IGJ5IHNlcnZl ciwgaXRzIHNvdXJjZSBwb3J0IGlzIGluIDEtMTAyNCAob3IgDQo+IDQ1MDAtNDUwMSBvciAuLi4p Lg0KPiAgICBUaGUgc291cmNlIGFkZHJlc3Mgd2lsbCBiZSBjb252ZXJ0ZWQgYnkgTkFULCB0aGUg c291cmNlIHBvcnQgcmVtYWlucw0KPiAgICB0aGUgc2FtZS4gDQo+IA0KPiBbU2VudGhpbF0gU29y cnksIEkgZGlkbqGvdCByZWFkIHRoZSBkcmFmdCwgYnV0IHRoZSBhYm92ZSBsb2dpYyB3b250IA0K PiB3b3JrIGlmIHRoZXJlIGFyZSBtdWx0aXBsZSBzZXJ2ZXJzIHVzaW5nIHRoZSBzYW1lIHNvdXJj ZSBwb3J0Lg0KPiBBbHNvLCBpbiBzb21lIGFwcGxpY2F0aW9ucyAoSSB0aGluayByY21kLCByc2hl bGwgZXRjKSwgdGhlIHNvdXJjZSANCj4gcG9ydCBkb2VzbqGvdCBoYXZlIHRvIGJlIHByZXNlcnZl ZCBidXQgbXVzdCBiZSBiZWxvdyAxMDI0Lg0KPiANCj4gU2VudGhpbA0KDQpbV2VpXSBJJ20gcHJl c2VudGluZyB0aGUgcHJvcG9zYWwgc28gYXMgdG8gc29sdmUgdGhpcyBwcm9ibGVtIDogYXNzaWdu IA0KcG9ydCANCngteShpLmUuIDEtMTAyNCkgdG8gYSBzZXJ2ZXIoZm9yIHBvcnQgcHJlc2Vydmlu ZyBmdW5jdGlvbiwgbGlrZSBOQVQpLCANCmFzc2lnbiANCnRoZSByZXN0IG9mIHBvcnRzIHRvIG90 aGVycyhmb3IgY29tbW9uIE5BUFQpLg0KICBPZiBjb3Vyc2UsIGlmIHRoZXJlIGFyZSBtYW55IHNl cnZlcnMgYmViaW5kIE5BVCBhbmQgd2hldGhlciBvciBub3QgdXNpbmcgDQoNCnRoZSBzYW1lIHNv dXJjZSBwb3J0LCBOQVQgaGFzIHRvIG5lZWQgbW9yZSB0aGFuIG9uZSBwdWJsaWMgYWRkcmVzcy4N CiAgQnV0IGluIHRoaXMgY2FzZSAsYSBzZXJ2ZXIgd2lsbCBuZXZlciBvY2N1cHlzIGFsbCBwb3J0 cyBvZiBhIHB1YmxpYyANCmFkZHJlc3MsIA0KanVzdCAieC15Ii4gDQoNCldlaQ0KDQo+IA0KPiAN Cj4gDQo+ICAgICgyKTwxMDI1LTY1NTM1PiBtaWdodCBiZSB1c2VkIGFzIGR5bmFtaWMgTkFQVCAN Cj4gICAgICAgIE1lYW53aGlsZSwgbWFueSBob3N0cyBhcmUgYmVoaW5kIE5BVC4gVGhleSBhdHRl bXB0IHRvIGFjY2VzcyB0byANCj4gICAgIGludGVybmV0LiANCj4gICAgICAgIEEgbWVzc2FnZSwg c2VudCBieSBhIGhvc3QsIGJvdGggaXRzIHNvdXJjZSBhZGRyZXNzIGFuZCBwb3J0IHdpbGwNCj4g ICAgIGJlIGNvbnZlcnRlZCBieSBOQVQsIGFuZCB0aGUgbmV3IHBvcnQgd2lsbCBiZSBpbiAxMDI1 LTY1NTM1Lg0KPiANCj4gDQo+IEl0IHdpbGwgbWFrZSBJUCBhZGRyZXNzIGFzc2lnbm1lbnQgbW9y ZSBlZmZlY3RpdmUuDQo+IA0KPiBDaGVlcnMsIA0KPiBXZWkgDQo+IA0KPiANCj4gDQo+IGJlaGF2 ZS1ib3VuY2VzQGlldGYub3JnICAyMDEzLTA3LTE3IDEyOjM2OjMwOg0KPiANCj4gPiBIaSwgDQo+ ID4gDQo+ID4gSSdtIG5vdCBzdXJlIHdoYXQgZXhhY3RseSB5b3UgbWFuIGJ5ICJtaWdodCBiZSB1 c2VkIGFzIE5BVCIuIA0KPiA+IA0KPiA+IDAtMTAyNCBtaWdodCBiZSB1c2VkIGZvciBOQVBUIGlu IGEgRkNGUyBiYXNpcyB3aGVyZSBwb3J0IA0KPiA+IHByZXNlcnZhdGlvbiAodGhpcyBpcyB3aGF0 IHdlIGFyZSB0YWxraW5nIGFib3V0IGhlcmUsIHJpZ2h0PykgaXMgDQpuZWVkZWQuIA0KPiA+IA0K PiA+IEFzIGEgY29uY3JldGUgZXhhbXBsZSwgbWFueSBJUHNlYyBTZXJ2ZXJzIHN0aWxsIGV4cGVj dCB0byBzZWUgdGhlIA0KPiA+IHNvdXJjZSBwb3J0IHdpdGhpbiAwLTEwMjQgYW5kIHByZWZlcmFi bHkgYSBzcGVjaWZpYyBzb3VyY2UgcG9ydC4gSWYgDQo+ID4gdGhhdCBzb3VyY2UgcG9ydCBpcyB1 c2VkIGJ5IHRoZSBOQVQsIGFuZCBtb3JlIHRoYW4gb25lIElQc2VjIGNsaWVudCANCj4gPiBpcyBi ZWhpbmQgaXQsIHRoZXJlIGFyZSBhIHNvbWUgY2hvaWNlcyBhdmFpbGFibGUuIA0KPiA+IA0KPiA+ IC0gU29tZSBmdW5reSBJUFNlYyBBTEcgKGltcGxlbWVudGVkIGluIG1hbnkgcHJvZHVjdHMpIA0K PiA+IC0gR2l2ZSBhIHBvcnQgYWJvdmUgMTAyNCBhbmQgaG9wZSBmb3IgdGhlIGJlc3QgDQo+ID4g LSBEZW55IHRoZSBjb25uZWN0aW9uIA0KPiA+IC0gb3RoZXJzLi4gDQo+ID4gDQo+ID4gT3RoZXIg cG9ydHMgZm9yIHRoZSBzYW1lIHB1YmxpYyBJUCBjYW4gYmUgdXNlZCBieSBhbnkgb3RoZXIgaW50 ZXJuYWwNCj4gPiBJUCBhZGRyZXNzLiBUaGlzIGlzIHZlcnkgY29tbW9uIGluIGltcGxlbWVudGF0 aW9ucy4gDQo+ID4gDQo+ID4gdGhhbmtzLCANCj4gPiANCj4gPiBGcm9tOiBiZWhhdmUtYm91bmNl c0BpZXRmLm9yZyBbYmVoYXZlLWJvdW5jZXNAaWV0Zi5vcmddIG9uIGJlaGFsZiBvZg0KPiA+IG1l bmcud2VpMkB6dGUuY29tLmNuIFttZW5nLndlaTJAenRlLmNvbS5jbl0NCj4gPiBTZW50OiBUdWVz ZGF5LCBKdWx5IDE2LCAyMDEzIDg6MjIgUE0NCj4gPiBUbzogUmVpbmFsZG8gUGVubm8gKHJlcGVu bm8pDQo+ID4gQ2M6IGJlaGF2ZS1ib3VuY2VzQGlldGYub3JnOyBiZWhhdmVAaWV0Zi5vcmc7IERh biBXaW5nIChkd2luZykNCj4gPiBTdWJqZWN0OiBSZTogW0JFSEFWRV0gTkFQR1QgcmVxdWVzdCBm b3IgY29tbWVudHMsIFRIQU5LUyENCj4gDQo+ID4gDQo+ID4gSGkgUmVpbmFsZG8sIA0KPiA+ICAg U28gSSBzdXBwb3NlIDwxLTEwMjQ+IG1pZ2h0IGJlIHVzZWQgYXMgTkFULCA8MTAyNS02NTUzNT4g bWlnaHQgYmUgDQp1c2VkIGFzIA0KPiA+IGR5bmFtaWMgTkFQVC4gDQo+ID4gICBUaGF0IGlzIHdo YXQgdGhpcyB2aWV3IHNheXMgaW4gdGhlIGRyYWZ0LiANCj4gPiANCj4gPiBDaGVlcnMsIA0KPiA+ IFdlaSANCj4gPiANCj4gPiANCj4gPiBiZWhhdmUtYm91bmNlc0BpZXRmLm9yZyAyMDEzLTA3LTE3 IDA5OjUyOjM0Og0KPiA+IA0KPiA+ID4gSSdtIG5vdCBzdXJlIHRoaXMgaXMgYSBnb29kIGlkZWEu IFRoZXJlIGFyZSBzdGlsbCBzb21lIHByb3RvY29scyANCj4gPiA+IGFyb3VuZCB0aGF0IHVzZSBw b3J0cyA8IDEwMjQgYW5kIG1haW50YWluaW5nIHRoZSBzb3VyY2UgcG9ydCBhZnRlciANCj4gPiA+ IHRyYW5zbGF0aW9uIGluIHRoaXMgcmFuZ2UgaXMgaW1wb3J0YW50LiANCj4gPiA+IA0KPiA+ID4g RnJvbTogYmVoYXZlLWJvdW5jZXNAaWV0Zi5vcmcgW2JlaGF2ZS1ib3VuY2VzQGlldGYub3JnXSBv biBiZWhhbGYgb2YNCj4gPiA+IERhbiBXaW5nIChkd2luZykNCj4gPiA+IFNlbnQ6IFR1ZXNkYXks IEp1bHkgMTYsIDIwMTMgMzozMCBQTQ0KPiA+ID4gVG86IG1lbmcud2VpMkB6dGUuY29tLmNuDQo+ ID4gPiBDYzogYmVoYXZlQGlldGYub3JnDQo+ID4gPiBTdWJqZWN0OiBSZTogW0JFSEFWRV0gTkFQ R1QgcmVxdWVzdCBmb3IgY29tbWVudHMsIFRIQU5LUyENCj4gPiANCj4gPiA+IA0KPiA+ID4gT24g SnVsIDE1LCAyMDEzLCBhdCAyOjQzIEFNLCBtZW5nLndlaTJAenRlLmNvbS5jbiB3cm90ZTogDQo+ ID4gPiANCj4gPiA+ICAgICBJIGhhdmUgc3VibWl0dGVkIGEgbmV3IGRyYWZ0LiBUaGUgb2JqZWN0 aXZlIGlzIHRvIHNvbHZlIGEgDQo+IHByb2JsZW0gdGhhdCANCj4gPiA+ICAgICBwcmV2ZW50cyBh biBleHRlcm5hbCBjbGllbnQgZnJvbSBhY2Nlc3NpbmcgYW4gaW50ZXJuYWwgc2VydmVyLiANCj4g PiA+IA0KPiA+ID4gICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW1l bmctYmVoYXZlLW5hcGd0LyANCj4gPiA+IA0KPiA+ID4gICAgIEkgZXhwZWN0IHlvdXIgY29tbWVu dHMuIFRoYW5rcyBhIGxvdCEgDQo+ID4gPiANCj4gPiA+IERyYWZ0LW1lbmctYmVoYXZlLW5hcGd0 IGFwcGVhcnMgdG8gZGVzY3JpYmUgc29tZXRoaW5nIHRoYXQgaXMgdmVyeSANCj4gPiA+IHNpbWls YXIgdG8gdGhlIGxvbmctc3RhbmRpbmcgIkRNWiBob3N0IiBjb25maWd1cmF0aW9uIGF2YWlsYWJs ZSBvbiANCj4gPiA+IGFsbW9zdCBhbGwgcmVzaWRlbnRpYWwtY2xhc3MgTkFUIGRldmljZXMuICBJ IGRvbid0IHRoaW5rIHdlIGNvdWxkIA0KPiA+ID4gc3RhbmRhcmRpemUgdGhhdCBiZWhhdmlvciwg YnV0IHBlcmhhcHMgdGhhdCBpcyBwb3NzaWJsZS4gDQo+ID4gPiANCj4gPiA+IERyYWZ0LW1lbmct YmVoYXZlLW5hcGd0IGFsc28gZGVzY3JpYmVzIGFuIHVwZGF0ZSB0byB0aGUgcG9ydCANCj4gPiA+ IGFzc2lnbm1lbnQgYmVoYXZpb3IgZGVzY3JpYmVkIGluIGh0dHA6Ly90b29scy5pZXRmLg0KPiA+ ID4gb3JnL2h0bWwvcmZjNTM4MiNzZWN0aW9uLTcuMSAoVENQKSBhbmQgaHR0cDovL3Rvb2xzLmll dGYuDQo+ID4gPiBvcmcvaHRtbC9yZmM0Nzg3I3NlY3Rpb24tNC4yLjEgKFVEUCkuICBJZiBJIHVu ZGVyc3RhbmQgU2VjdGlvbiA0IG9mIA0KPiA+ID4gZHJhZnQtbWVuZy1iZWhhdmUtbmFwZ3QgcHJv cGVybHksIGl0IGlzIHNheWluZyB0aGF0IE5BVHMgc2hvdWxkIG5vdCANCj4gPiA+IGFzc2lnbiBw b3J0cyBiZWxvdyAxMDI0IHRvIGR5bmFtaWMgY29ubmVjdGlvbnMuICBUaGlzIG1pZ2h0IGJlIA0K PiA+ID4gc29tZXRoaW5nIHdvcnRoIGNvbnNpZGVyaW5nIGZvciANCmRyYWZ0LWlldGYtYmVoYXZl LXJlcXVpcmVtZW50cy11cGRhdGU/IA0KPiA+ID4gDQo+ID4gPiAtZCANCj4gPiA+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiBCZWhhdmUgbWFp bGluZyBsaXN0DQo+ID4gPiBCZWhhdmVAaWV0Zi5vcmcNCj4gPiA+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vYmVoYXZlDQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBCZWhhdmUgbWFpbGluZyBsaXN0DQo+ID4gQmVo YXZlQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9i ZWhhdmUNCg== --=_alternative 0007626448257BAC_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLDwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7IFBsZWFzZSBzZWUgaW5saW5lLjwvZm9u dD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhhbmtzLDwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+V2VpPC9mb250Pg0KPGJyPg0K PGJyPjx0dD48Zm9udCBzaXplPTI+JnF1b3Q7U2VudGhpbCBTaXZha3VtYXIgKHNzZW50aGlsKSZx dW90OyAmbHQ7c3NlbnRoaWxAY2lzY28uY29tJmd0Ow0KJm5ic3A7MjAxMy0wNy0xNyAyMTozMDoy NDo8YnI+DQo8YnI+DQomZ3Q7IEZyb206ICZxdW90O21lbmcud2VpMkB6dGUuY29tLmNuJnF1b3Q7 ICZsdDttZW5nLndlaTJAenRlLmNvbS5jbiZndDs8YnI+DQomZ3Q7IERhdGU6IFdlZG5lc2RheSwg SnVseSAxNywgMjAxMyA0OjA4IEFNPGJyPg0KJmd0OyBUbzogJnF1b3Q7UmVpbmFsZG8gUGVubm8g KHJlcGVubm8pJnF1b3Q7ICZsdDtyZXBlbm5vQGNpc2NvLmNvbSZndDs8YnI+DQomZ3Q7IENjOiAm cXVvdDtiZWhhdmUtYm91bmNlc0BpZXRmLm9yZyZxdW90OyAmbHQ7YmVoYXZlLWJvdW5jZXNAaWV0 Zi5vcmcmZ3Q7LA0KJnF1b3Q7YmVoYXZlQGlldGYub3JnJnF1b3Q7ICZsdDs8YnI+DQomZ3Q7IGJl aGF2ZUBpZXRmLm9yZyZndDssICZxdW90O0RhbiBXaW5nIChkd2luZykmcXVvdDsgJmx0O2R3aW5n QGNpc2NvLmNvbSZndDs8YnI+DQomZ3Q7IFN1YmplY3Q6IFJlOiBbQkVIQVZFXSBOQVBHVCByZXF1 ZXN0IGZvciBjb21tZW50cywgVEhBTktTITwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXpl PTI+Jmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgSGksIDxicj4NCiZndDsgJm5ic3A7IEkgZ290 IHdoYXQgdGhlIGV4YW1wbGUgbWVhbnMuIDxicj4NCiZndDsgPGJyPg0KJmd0OyAmbmJzcDsgMS0x MDI0IGlzIGp1c3QgYW4gZXhhbXBsZSwgdGhlIHJhbmdlIGNvdWxkIGJlIGFueSB2YWxpZCB2YWx1 ZS48YnI+DQomZ3Q7IDxicj4NCiZndDsgJm5ic3A7ICZxdW90OyZsdDsxLTEwMjQmZ3Q7IG1pZ2h0 IGJlIHVzZWQgYXMgTkFULCAmbHQ7MTAyNS02NTUzNSZndDsNCm1pZ2h0IGJlIHVzZWQgYXMgPGJy Pg0KJmd0OyBkeW5hbWljIE5BUFQmcXVvdDssIGV4YW1wbGUgaXMgYXMgYmVsb3cuIDxicj4NCiZn dDsgPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7Ky0tLS0tLS0tLS0rICZuYnNwOyAmbmJzcDsgKy0t LS0tKyAmbmJzcDsgJm5ic3A7Ky0tLS0tLS0tKw0KPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7KyBJ bnRlcm5ldCArIC0tLS0rIE5BVCArLS0tLSsgU2VydmVyICsgPGJyPg0KJmd0OyAmbmJzcDsgJm5i c3A7Ky0tLS0tLS0tLS0rICZuYnNwOyAmbmJzcDsgKy0tLS0tKyAmbmJzcDsgJm5ic3A7Ky0tLS0t LS0tKw0KPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsoMSkgJnF1b3Q7Jmx0OzEt MTAyNCZndDsgbWlnaHQgYmUgdXNlZCBhcyBOQVQmcXVvdDsgbWVhbnMsDQo8YnI+DQomZ3Q7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0Egc2VydmVyIGJlaGluZCBhIE5BVC4gPGJyPg0KJmd0 OyAmbmJzcDsgJm5ic3A7QSBtZXNzYWdlLCBzZW50IGJ5IHNlcnZlciwgaXRzIHNvdXJjZSBwb3J0 IGlzIGluIDEtMTAyNA0KKG9yIDxicj4NCiZndDsgNDUwMC00NTAxIG9yIC4uLikuPGJyPg0KJmd0 OyAmbmJzcDsgJm5ic3A7VGhlIHNvdXJjZSBhZGRyZXNzIHdpbGwgYmUgY29udmVydGVkIGJ5IE5B VCwgdGhlIHNvdXJjZQ0KcG9ydCByZW1haW5zPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7dGhlIHNh bWUuIDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IFtT ZW50aGlsXSBTb3JyeSwgSSBkaWRuoa90IHJlYWQgdGhlIGRyYWZ0LCBidXQgdGhlIGFib3ZlIGxv Z2ljIHdvbnQNCjxicj4NCiZndDsgd29yayBpZiB0aGVyZSBhcmUgbXVsdGlwbGUgc2VydmVycyB1 c2luZyB0aGUgc2FtZSBzb3VyY2UgcG9ydC48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6 ZT0yPiZndDsgQWxzbywgaW4gc29tZSBhcHBsaWNhdGlvbnMgKEkgdGhpbmsgcmNtZCwgcnNoZWxs DQpldGMpLCB0aGUgc291cmNlIDxicj4NCiZndDsgcG9ydCBkb2VzbqGvdCBoYXZlIHRvIGJlIHBy ZXNlcnZlZCBidXQgbXVzdCBiZSBiZWxvdyAxMDI0LjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9u dCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IFNlbnRoaWw8L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48 dHQ+PGZvbnQgc2l6ZT0yPltXZWldIEknbSBwcmVzZW50aW5nIHRoZSBwcm9wb3NhbCBzbyBhcyB0 byBzb2x2ZSB0aGlzDQpwcm9ibGVtIDogYXNzaWduIHBvcnQgPC9mb250PjwvdHQ+DQo8YnI+PHR0 Pjxmb250IHNpemU9Mj54LXkoaS5lLiAxLTEwMjQpIHRvIGEgc2VydmVyKGZvciBwb3J0IHByZXNl cnZpbmcgZnVuY3Rpb24sDQpsaWtlIE5BVCksIGFzc2lnbiA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+ PGZvbnQgc2l6ZT0yPnRoZSByZXN0IG9mIHBvcnRzIHRvIG90aGVycyhmb3IgY29tbW9uIE5BUFQp LjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jm5ic3A7IE9mIGNvdXJzZSwgaWYg dGhlcmUgYXJlIG1hbnkgc2VydmVycyBiZWJpbmQNCk5BVCBhbmQgd2hldGhlciBvciBub3QgdXNp bmcgPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj50aGUgc2FtZSBzb3VyY2UgcG9y dCwgTkFUIGhhcyB0byBuZWVkIG1vcmUgdGhhbiBvbmUNCnB1YmxpYyBhZGRyZXNzLjwvZm9udD48 L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jm5ic3A7IEJ1dCBpbiB0aGlzIGNhc2UgLGEgc2Vy dmVyIHdpbGwgbmV2ZXIgb2NjdXB5cw0KYWxsIHBvcnRzIG9mIGEgcHVibGljIGFkZHJlc3MsIDwv Zm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+anVzdCAmcXVvdDt4LXkmcXVvdDsuIDwv Zm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+V2VpPC9mb250PjwvdHQ+DQo8 YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+ DQomZ3Q7ICZuYnNwOyAmbmJzcDsoMikmbHQ7MTAyNS02NTUzNSZndDsgbWlnaHQgYmUgdXNlZCBh cyBkeW5hbWljIE5BUFQgPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtNZWFu d2hpbGUsIG1hbnkgaG9zdHMgYXJlIGJlaGluZCBOQVQuIFRoZXkNCmF0dGVtcHQgdG8gYWNjZXNz IHRvIDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBpbnRlcm5ldC4gPGJyPg0KJmd0OyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDtBIG1lc3NhZ2UsIHNlbnQgYnkgYSBob3N0LCBib3RoIGl0cyBz b3VyY2UNCmFkZHJlc3MgYW5kIHBvcnQgd2lsbDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyBiZSBj b252ZXJ0ZWQgYnkgTkFULCBhbmQgdGhlIG5ldyBwb3J0IHdpbGwgYmUgaW4gMTAyNS02NTUzNS48 YnI+DQomZ3Q7IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyA8YnI+DQomZ3Q7IEl0IHdpbGwgbWFr ZSBJUCBhZGRyZXNzIGFzc2lnbm1lbnQgbW9yZSBlZmZlY3RpdmUuPGJyPg0KJmd0OyA8YnI+DQom Z3Q7IENoZWVycywgPGJyPg0KJmd0OyBXZWkgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZn dDsgPGJyPg0KJmd0OyBiZWhhdmUtYm91bmNlc0BpZXRmLm9yZyAmbmJzcDsyMDEzLTA3LTE3IDEy OjM2OjMwOjxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IEhpLCA8YnI+DQomZ3Q7ICZndDsgPGJy Pg0KJmd0OyAmZ3Q7IEknbSBub3Qgc3VyZSB3aGF0IGV4YWN0bHkgeW91IG1hbiBieSAmcXVvdDtt aWdodCBiZSB1c2VkIGFzIE5BVCZxdW90Oy4NCiZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0K Jmd0OyAmZ3Q7IDAtMTAyNCBtaWdodCBiZSB1c2VkIGZvciBOQVBUIGluIGEgRkNGUyBiYXNpcyB3 aGVyZSBwb3J0IDxicj4NCiZndDsgJmd0OyBwcmVzZXJ2YXRpb24gKHRoaXMgaXMgd2hhdCB3ZSBh cmUgdGFsa2luZyBhYm91dCBoZXJlLCByaWdodD8pDQppcyBuZWVkZWQuIDxicj4NCiZndDsgJmd0 OyA8YnI+DQomZ3Q7ICZndDsgQXMgYSBjb25jcmV0ZSBleGFtcGxlLCBtYW55IElQc2VjIFNlcnZl cnMgc3RpbGwgZXhwZWN0IHRvIHNlZQ0KdGhlIDxicj4NCiZndDsgJmd0OyBzb3VyY2UgcG9ydCB3 aXRoaW4gMC0xMDI0IGFuZCBwcmVmZXJhYmx5IGEgc3BlY2lmaWMgc291cmNlIHBvcnQuDQpJZiA8 YnI+DQomZ3Q7ICZndDsgdGhhdCBzb3VyY2UgcG9ydCBpcyB1c2VkIGJ5IHRoZSBOQVQsIGFuZCBt b3JlIHRoYW4gb25lIElQc2VjDQpjbGllbnQgPGJyPg0KJmd0OyAmZ3Q7IGlzIGJlaGluZCBpdCwg dGhlcmUgYXJlIGEgc29tZSBjaG9pY2VzIGF2YWlsYWJsZS4gPGJyPg0KJmd0OyAmZ3Q7IDxicj4N CiZndDsgJmd0OyAtIFNvbWUgZnVua3kgSVBTZWMgQUxHIChpbXBsZW1lbnRlZCBpbiBtYW55IHBy b2R1Y3RzKSA8YnI+DQomZ3Q7ICZndDsgLSBHaXZlIGEgcG9ydCBhYm92ZSAxMDI0IGFuZCBob3Bl IGZvciB0aGUgYmVzdCA8YnI+DQomZ3Q7ICZndDsgLSBEZW55IHRoZSBjb25uZWN0aW9uIDxicj4N CiZndDsgJmd0OyAtIG90aGVycy4uIDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgT3Ro ZXIgcG9ydHMgZm9yIHRoZSBzYW1lIHB1YmxpYyBJUCBjYW4gYmUgdXNlZCBieSBhbnkgb3RoZXIg aW50ZXJuYWw8YnI+DQomZ3Q7ICZndDsgSVAgYWRkcmVzcy4gVGhpcyBpcyB2ZXJ5IGNvbW1vbiBp biBpbXBsZW1lbnRhdGlvbnMuIDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgdGhhbmtz LCA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEZyb206IGJlaGF2ZS1ib3VuY2VzQGll dGYub3JnIFtiZWhhdmUtYm91bmNlc0BpZXRmLm9yZ10gb24gYmVoYWxmDQpvZjxicj4NCiZndDsg Jmd0OyBtZW5nLndlaTJAenRlLmNvbS5jbiBbbWVuZy53ZWkyQHp0ZS5jb20uY25dPGJyPg0KJmd0 OyAmZ3Q7IFNlbnQ6IFR1ZXNkYXksIEp1bHkgMTYsIDIwMTMgODoyMiBQTTxicj4NCiZndDsgJmd0 OyBUbzogUmVpbmFsZG8gUGVubm8gKHJlcGVubm8pPGJyPg0KJmd0OyAmZ3Q7IENjOiBiZWhhdmUt Ym91bmNlc0BpZXRmLm9yZzsgYmVoYXZlQGlldGYub3JnOyBEYW4gV2luZyAoZHdpbmcpPGJyPg0K Jmd0OyAmZ3Q7IFN1YmplY3Q6IFJlOiBbQkVIQVZFXSBOQVBHVCByZXF1ZXN0IGZvciBjb21tZW50 cywgVEhBTktTITxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBIaSBS ZWluYWxkbywgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyBTbyBJIHN1cHBvc2UgJmx0OzEtMTAyNCZn dDsgbWlnaHQgYmUgdXNlZCBhcyBOQVQsICZsdDsxMDI1LTY1NTM1Jmd0Ow0KbWlnaHQgYmUgdXNl ZCBhcyA8YnI+DQomZ3Q7ICZndDsgZHluYW1pYyBOQVBULiA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7 IFRoYXQgaXMgd2hhdCB0aGlzIHZpZXcgc2F5cyBpbiB0aGUgZHJhZnQuIDxicj4NCiZndDsgJmd0 OyA8YnI+DQomZ3Q7ICZndDsgQ2hlZXJzLCA8YnI+DQomZ3Q7ICZndDsgV2VpIDxicj4NCiZndDsg Jmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IGJlaGF2ZS1ib3VuY2VzQGlldGYu b3JnIDIwMTMtMDctMTcgMDk6NTI6MzQ6PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAm Z3Q7IEknbSBub3Qgc3VyZSB0aGlzIGlzIGEgZ29vZCBpZGVhLiBUaGVyZSBhcmUgc3RpbGwgc29t ZSBwcm90b2NvbHMNCjxicj4NCiZndDsgJmd0OyAmZ3Q7IGFyb3VuZCB0aGF0IHVzZSBwb3J0cyAm bHQ7IDEwMjQgYW5kIG1haW50YWluaW5nIHRoZSBzb3VyY2UNCnBvcnQgYWZ0ZXIgPGJyPg0KJmd0 OyAmZ3Q7ICZndDsgdHJhbnNsYXRpb24gaW4gdGhpcyByYW5nZSBpcyBpbXBvcnRhbnQuIDxicj4N CiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IEZyb206IGJlaGF2ZS1ib3VuY2Vz QGlldGYub3JnIFtiZWhhdmUtYm91bmNlc0BpZXRmLm9yZ10NCm9uIGJlaGFsZiBvZjxicj4NCiZn dDsgJmd0OyAmZ3Q7IERhbiBXaW5nIChkd2luZyk8YnI+DQomZ3Q7ICZndDsgJmd0OyBTZW50OiBU dWVzZGF5LCBKdWx5IDE2LCAyMDEzIDM6MzAgUE08YnI+DQomZ3Q7ICZndDsgJmd0OyBUbzogbWVu Zy53ZWkyQHp0ZS5jb20uY248YnI+DQomZ3Q7ICZndDsgJmd0OyBDYzogYmVoYXZlQGlldGYub3Jn PGJyPg0KJmd0OyAmZ3Q7ICZndDsgU3ViamVjdDogUmU6IFtCRUhBVkVdIE5BUEdUIHJlcXVlc3Qg Zm9yIGNvbW1lbnRzLCBUSEFOS1MhPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7 IDxicj4NCiZndDsgJmd0OyAmZ3Q7IE9uIEp1bCAxNSwgMjAxMywgYXQgMjo0MyBBTSwgbWVuZy53 ZWkyQHp0ZS5jb20uY24gd3JvdGU6DQo8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZn dDsgJmd0OyAmbmJzcDsgJm5ic3A7IEkgaGF2ZSBzdWJtaXR0ZWQgYSBuZXcgZHJhZnQuIFRoZSBv YmplY3RpdmUNCmlzIHRvIHNvbHZlIGEgPGJyPg0KJmd0OyBwcm9ibGVtIHRoYXQgPGJyPg0KJmd0 OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyBwcmV2ZW50cyBhbiBleHRlcm5hbCBjbGllbnQgZnJv bSBhY2Nlc3NpbmcNCmFuIGludGVybmFsIHNlcnZlci4gPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyBodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1tZW5nLWJlaGF2ZS1uYXBndC8NCjxicj4NCiZndDsgJmd0OyAmZ3Q7IDxi cj4NCiZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgSSBleHBlY3QgeW91ciBjb21tZW50cy4g VGhhbmtzIGEgbG90ISA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBE cmFmdC1tZW5nLWJlaGF2ZS1uYXBndCBhcHBlYXJzIHRvIGRlc2NyaWJlIHNvbWV0aGluZyB0aGF0 DQppcyB2ZXJ5IDxicj4NCiZndDsgJmd0OyAmZ3Q7IHNpbWlsYXIgdG8gdGhlIGxvbmctc3RhbmRp bmcgJnF1b3Q7RE1aIGhvc3QmcXVvdDsgY29uZmlndXJhdGlvbg0KYXZhaWxhYmxlIG9uIDxicj4N CiZndDsgJmd0OyAmZ3Q7IGFsbW9zdCBhbGwgcmVzaWRlbnRpYWwtY2xhc3MgTkFUIGRldmljZXMu ICZuYnNwO0kgZG9uJ3QNCnRoaW5rIHdlIGNvdWxkIDxicj4NCiZndDsgJmd0OyAmZ3Q7IHN0YW5k YXJkaXplIHRoYXQgYmVoYXZpb3IsIGJ1dCBwZXJoYXBzIHRoYXQgaXMgcG9zc2libGUuDQo8YnI+ DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBEcmFmdC1tZW5nLWJlaGF2ZS1u YXBndCBhbHNvIGRlc2NyaWJlcyBhbiB1cGRhdGUgdG8gdGhlDQpwb3J0IDxicj4NCiZndDsgJmd0 OyAmZ3Q7IGFzc2lnbm1lbnQgYmVoYXZpb3IgZGVzY3JpYmVkIGluIGh0dHA6Ly90b29scy5pZXRm Ljxicj4NCiZndDsgJmd0OyAmZ3Q7IG9yZy9odG1sL3JmYzUzODIjc2VjdGlvbi03LjEgKFRDUCkg YW5kIGh0dHA6Ly90b29scy5pZXRmLjxicj4NCiZndDsgJmd0OyAmZ3Q7IG9yZy9odG1sL3JmYzQ3 ODcjc2VjdGlvbi00LjIuMSAoVURQKS4gJm5ic3A7SWYgSSB1bmRlcnN0YW5kDQpTZWN0aW9uIDQg b2YgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgZHJhZnQtbWVuZy1iZWhhdmUtbmFwZ3QgcHJvcGVybHks IGl0IGlzIHNheWluZyB0aGF0IE5BVHMNCnNob3VsZCBub3QgPGJyPg0KJmd0OyAmZ3Q7ICZndDsg YXNzaWduIHBvcnRzIGJlbG93IDEwMjQgdG8gZHluYW1pYyBjb25uZWN0aW9ucy4gJm5ic3A7VGhp cw0KbWlnaHQgYmUgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgc29tZXRoaW5nIHdvcnRoIGNvbnNpZGVy aW5nIGZvciBkcmFmdC1pZXRmLWJlaGF2ZS1yZXF1aXJlbWVudHMtdXBkYXRlPw0KPGJyPg0KJmd0 OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgLWQgPGJyPg0KJmd0OyAmZ3Q7ICZndDsg X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7 ICZndDsgJmd0OyBCZWhhdmUgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7ICZndDsgQmVoYXZl QGlldGYub3JnPGJyPg0KJmd0OyAmZ3Q7ICZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9iZWhhdmU8YnI+DQomZ3Q7ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7ICZndDsgQmVoYXZlIG1haWxpbmcgbGlz dDxicj4NCiZndDsgJmd0OyBCZWhhdmVAaWV0Zi5vcmc8YnI+DQomZ3Q7ICZndDsgaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9iZWhhdmU8L2ZvbnQ+PC90dD4NCg== --=_alternative 0007626448257BAC_=-- From dwing@cisco.com Wed Jul 17 18:23:17 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C83321F8AD5 for ; Wed, 17 Jul 2013 18:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.513 X-Spam-Level: X-Spam-Status: No, score=-110.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ivh3FerF4EKy for ; Wed, 17 Jul 2013 18:23:12 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 5E82621F86AE for ; Wed, 17 Jul 2013 18:23:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5338; q=dns/txt; s=iport; t=1374110592; x=1375320192; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=fPi18czM+KI5vxtILulhVK7jV9vU+oJT0FAOLGB4iI8=; b=Dgv3NJ0/JGWTG4xm+hvxMyINa7KNnwsiIWL4acSOHE5jHb/EX4OhaPo8 VM19/4axreDDKRt6CXHhtHGV/2zmNYG1NgzFmcQDADNzbfVfJepgXa64T eRse6JNmvPy+BrRwtvBI5oDTleqZkGqhLXeW4iDXbeQTz2CB4Pu2PSz0b U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAA1C51GrRDoH/2dsb2JhbABagwY0wQ+BExZ0giMBAQEDAXkFCwtGVwYTCYgBBQ22PI4yFn8zB4MNbgOJJ441kU2DMhyBLgcXBg X-IronPort-AV: E=Sophos;i="4.89,689,1367971200"; d="scan'208";a="83813728" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 18 Jul 2013 01:23:06 +0000 Received: from sjc-vpn1-1467.cisco.com (sjc-vpn1-1467.cisco.com [10.21.101.187]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r6I1N5x1005203; Thu, 18 Jul 2013 01:23:05 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dan Wing In-Reply-To: <51E656F2.6050309@viagenie.ca> Date: Wed, 17 Jul 2013 18:23:05 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7CD19415-9EB0-4A58-BA6B-11692D1923DD@cisco.com> References: <20130715173816.18605.12504.idtracker@ietfa.amsl.com> <51E513BF.2040405@viagenie.ca> <51E656F2.6050309@viagenie.ca> To: Simon Perreault X-Mailer: Apple Mail (2.1508) Cc: behave@ietf.org Subject: Re: [BEHAVE] I-D Action: draft-muthu-behave-consent-freshness-04.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 01:23:17 -0000 On Jul 17, 2013, at 1:33 AM, Simon Perreault = wrote: > Le 2013-07-17 00:42, Dan Wing a =E9crit : >>>> Every Tc seconds, the WebRTC browser sends a STUN Binding Request = to >>>> the peer. This request MUST use a new, cryptographically random >>>> Transaction ID [RFC4086], and is formatted as for an ICE = connectivity >>>> check [RFC5245]. A valid STUN Binding Response is also formatted = as >>>> for an ICE connectivity check [RFC5245]. The STUN Binding Request >>>> and STUN Binding Response are validated as for an ICE connectivity >>>> check [RFC5245]. >>>=20 >>> Couldn't this whole paragraph be simplified to "Every Tc seconds, = the >>> WebRTC browser sends an ICE connectivity check."? Is there anything = new >>> here besides the "every Tc" thing? >>=20 >> Nope, it's all the same rules as for ICE. We need to somehow = reference ICE although I agree it could be more tersely done than that = long paragraph. >=20 > Ok. I understand it's exactly the same as an ICE connectivity check > except with new re-transmission rules. If that could be explicitly and > succinctly stated, it would help. Ok. >=20 >>>> Liveness timer: If no packets have been received on the local port = in >>>> Tr seconds, the WebRTC browser MUST inform the JavaScript that >>>> connectivity has been lost. The JavaScript application will use = this >>>> notification however it desires (e.g., cease transmitting to the >>>> remote peer, provide a notification to the user, etc.). >>>=20 >>> This seems to me like it will not fulfill the goal set in the = abstract: >>> "to ensure that a malicious JavaScript cannot use the browser as a >>> platform for launching attacks". >>=20 >> The liveness timer doesn't protect from that; rather, the consent = timer protects from that. The liveness timer is only intended to give = an /earlier/ alert to the (JavaScript) application that connectivity = appears to have been lost, should it want an earlier alert. >>=20 >>> If the JavaScript is free to ignore the >>> notification from the browser, then it has no security benefits. If = you >>> want to reach that goal, the browser needs to forcefully stop = transmitting. >>=20 >> If that isn't clear in the document, we need to more clearly separate = the consent check from the liveliness check. This version is improved, = but it appears we need more improvement, perhaps separate sections and = separate text would help. >=20 > Yes, separate sections would help. >=20 > Maybe an example with a flow diagram showing what happens when a peer > goes away: after X seconds the liveness check fails and the app is > notified, then after Y seconds the consent check fails and = transmission > stops. That's a great suggestion, thank you. We will add that. > Also, it could be useful to discuss what happens when the peer comes = back... > a) ...after a liveness check failed (the session goes on as if nothing > happened I suppose) > b) ...after a consent check failed (can the session be resumed with = some > signalling (ICE restart? re-INVITE?) or is it irrevocably terminated?) RTCWeb has not discussed that, to my recollection. But that is worth = discussing and I agree the document needs to say something. >>>> When not actively sending traffic on a nominated candidate pair, >>>> performing consent freshness does not serve any purpose from a >>>> security perspective. >>>=20 >>> I don't understand what this means. Why is the "security = perspective" >>> important here? Aren't we concerned about keepalives? >>=20 >> Keeping alive a NAT or firewall binding is not a concern of consent, = though. The point of that sentence in the I-D is that we don't need to = send Consent packets if we aren't sending RTP data or aren't sending = SCTP data. Unfortunately, we had another change that didn't make the = I-D cutoff which would have made that clearer in the normative text. WG = consensus appears to have been that consent is only necessary if data is = being actively sent; otherwise, there isn't much point in waking up both = endpoints periodically to verify "are you still there?" (batteries is = the often cited reason). >=20 > That makes total sense. I'm curious about how the rule will be = written. The authors are still arguing^Wrefining the exact wording. :-) > Do you stop asking for consent if the user presses the mute button? = What > if you're sending comfort noise? The purpose of consent, as explained better in the new introduction, is = to prevent RTP or data traffic from flooding a victim. You are asking = about slower traffic. I am only aware of = http://www.ietf.org/mail-archive/web/rtcweb/current/msg04893.html where = Martin Thomson seemed to concur that RTCP feedback doesn't need consent. = I don't think the WG has really thought about slower traffic being an = attack vector. Another slow attack vector is STUN Binding Indications = or the other keep-alive techniques from RFC6263. With enough clients = involved, such slow attacks could be interesting. That is why I want to = get our text refined, so folks can consider if we want to use two = thresholds (a timer-based threshold and a packet-count-based threshold). -d From harald@alvestrand.no Thu Jul 18 06:27:37 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A08921E80F1 for ; Thu, 18 Jul 2013 06:27:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.498 X-Spam-Level: X-Spam-Status: No, score=-110.498 tagged_above=-999 required=5 tests=[AWL=0.100, 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 T-SSvd0ytPEF for ; Thu, 18 Jul 2013 06:27:26 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD2621E80F2 for ; Thu, 18 Jul 2013 06:27:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DF8E139E202; Thu, 18 Jul 2013 15:27:12 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80DoCZyqleY3; Thu, 18 Jul 2013 15:27:11 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 8755839E0FA; Thu, 18 Jul 2013 15:27:11 +0200 (CEST) Message-ID: <51E7ED2E.1020809@alvestrand.no> Date: Thu, 18 Jul 2013 15:27:10 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Rajmohan Banavi References: <20130715214906.5314.83583.idtracker@ietfa.amsl.com> <51E70106.8060100@goodadvice.pages.de> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080603050901010404070502" Cc: behave , Justin Uberti Subject: Re: [BEHAVE] [rtcweb] Fwd: New Version Notification for draft-uberti-behave-turn-rest-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 13:27:37 -0000 This is a multi-part message in MIME format. --------------080603050901010404070502 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 07/18/2013 02:28 PM, Rajmohan Banavi wrote: > Hi Justin, comments inline with additional comments at the end. > > Correct, but that is a significant advantage, especially when the > web and TURN servers are separate entities. > > > IMHO, the standard spec should not be based on any specific > implementation method. Now I agree that the TURN server validation > becomes easier using this method because it does not have to do some > sort of lookup. However, some another TURN server implementer can > achieve the same functionality by providing REST API but using > randomly generated pasword (rather than use HMAC) and using some sort > of lookup for TURN username when TURN ALLOCATE request is received. > > Now lets look at the collateral affects of using this proposed > implementation way > - TURN server needs to perform MESSAGE-INTEGRITY validation across two > secrets (worst case due to key rotation) when TURN ALLOCATE request is > received > - TURN username needs to consist of entire state (user identifier + > expiry time). And upon receiving the ALLOCATE request, TURN server > must check if the username is still valid based on expiry time part > (of username) > - Time sync needs to be maintained across the web server and the TURN > server. > > All of the above are not needed if one does not use the implementation > method specified in the draft but still provide REST API to generate > ephemeral credentials. How these ephemeral credentials are generated > and how the TURN requests are validated is an implementation decision. Playing devil's advocate: If you leave it to the implementation to decide how to do this, it means that the mechanism specified is a valid implementation. So your proposal specifies exactly the same protocol as the current proposal. On the other hand, leaving this to the implementation would preclude the option of getting a credential generator from one vendor and a TURN server from another vendor and having them validate correctly - thus, specifying the mechanism in the specification increases interoperability. I believe specifying enough to have separate implementations of the TURN server and the credential generator is a valuable feature of this specification. --------------080603050901010404070502 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 07/18/2013 02:28 PM, Rajmohan Banavi wrote:
Hi  Justin, comments inline with additional comments at the end.

Correct, but that is a significant advantage, especially when the web and TURN servers are separate entities. 

IMHO, the standard spec should not be based on any specific implementation method. Now I agree that the TURN server validation becomes easier using this method because it does not have to do some sort of lookup. However, some another TURN server implementer can achieve the same functionality by providing REST API but using randomly generated pasword (rather than use HMAC) and using some sort of lookup for TURN username when TURN ALLOCATE request is received.

Now lets look at the collateral affects of using this proposed implementation way
- TURN server needs to perform MESSAGE-INTEGRITY validation across two secrets (worst case due to key rotation) when TURN ALLOCATE request is received
- TURN username needs to consist of entire state (user identifier + expiry time). And upon receiving the ALLOCATE request, TURN server must check if the username is still valid based on expiry time part (of username)
- Time sync needs to be maintained across the web server and the TURN server.

All of the above are not needed if one does not use the implementation method specified in the draft but still provide REST API to generate ephemeral credentials. How these ephemeral credentials are generated and how the TURN requests are validated is an implementation decision.

Playing devil's advocate:

If you leave it to the implementation to decide how to do this, it means that the mechanism specified is a valid implementation. So your proposal specifies exactly the same protocol as the current proposal.

On the other hand, leaving this to the implementation would preclude the option of getting a credential generator from one vendor and a TURN server from another vendor and having them validate correctly - thus, specifying the mechanism in the specification increases interoperability.

I believe specifying enough to have separate implementations of the TURN server and the credential generator is a valuable feature of this specification.

--------------080603050901010404070502-- From ssenthil@cisco.com Thu Jul 18 07:31:08 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32AE711E813D; Thu, 18 Jul 2013 07:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=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 XBry4PaXllR0; Thu, 18 Jul 2013 07:31:03 -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 108C111E80A2; Thu, 18 Jul 2013 07:31:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19930; q=dns/txt; s=iport; t=1374157863; x=1375367463; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=Tb5rhaWvXCBr3kDIv11vqy3OpwbCKqO1PJj/U/JTU0E=; b=ME1qe+yGwfyUQQj8/VZHF8jO1dl2GF4Gh6z+K6fOszY9ti267cV5pit5 zzL+Rr+oSZdX+wH4MIhM6cB0uZwjt1EiOgcbS19CvwVilq42Ocs73vJgg ZV6kzX+URydE9Fm8J3DfQRwV5W/gMU8POZ2aJrwuHnGya8DGXbGiR7xXI c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsUFAOT651GtJXG9/2dsb2JhbABagkJENVC4B4g8gQ4WdIIkAQEBAQIBAQEBawsFDQEIEQMBAQEBCh0uCxQJCAIEDgUIEYdxBgy2D45DgRsgDQQHBgODBW4DmQaQJIMSgXE5 X-IronPort-AV: E=Sophos;i="4.89,694,1367971200"; d="scan'208,217";a="236464058" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-8.cisco.com with ESMTP; 18 Jul 2013 14:31:02 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r6IEV1Y6013738 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Jul 2013 14:31:01 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.94]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Thu, 18 Jul 2013 09:31:01 -0500 From: "Senthil Sivakumar (ssenthil)" To: "meng.wei2@zte.com.cn" Thread-Topic: [BEHAVE] NAPGT request for comments, THANKS! Thread-Index: AQHOg8NsNWewfH9dsEGq6rcfY/Tw+w== Date: Thu, 18 Jul 2013 14:31:00 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.117.198.132] Content-Type: multipart/alternative; boundary="_000_CB1B483277FEC94E9B58357040EE5D02325D26B4xmbrcdx15ciscoc_" MIME-Version: 1.0 Cc: "Reinaldo Penno \(repenno\)" , "behave-bounces@ietf.org" , "behave@ietf.org" , "Dan Wing \(dwing\)" Subject: Re: [BEHAVE] NAPGT request for comments, THANKS! X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 14:31:08 -0000 --_000_CB1B483277FEC94E9B58357040EE5D02325D26B4xmbrcdx15ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable From: "meng.wei2@zte.com.cn" > Date: Wednesday, July 17, 2013 9:19 PM To: Senthil Sivakumar > Cc: "behave@ietf.org" >, "behave-bounces@ietf.org" >, "Dan Wing (dwing)" = >, "Reinaldo Penno (repenno)" > Subject: Re: Re: [BEHAVE] NAPGT request for comments, THANKS! Hi, Please see inline. Thanks, Wei "Senthil Sivakumar (ssenthil)" > 2013-07-17 21:30:24: > From: "meng.wei2@zte.com.cn" > > Date: Wednesday, July 17, 2013 4:08 AM > To: "Reinaldo Penno (repenno)" > > Cc: "behave-bounces@ietf.org" >, "behave@ietf.org" < > behave@ietf.org>, "Dan Wing (dwing)" > > Subject: Re: [BEHAVE] NAPGT request for comments, THANKS! > > > Hi, > I got what the example means. > > 1-1024 is just an example, the range could be any valid value. > > "<1-1024> might be used as NAT, <1025-65535> might be used as > dynamic NAPT", example is as below. > > +----------+ +-----+ +--------+ > + Internet + ----+ NAT +----+ Server + > +----------+ +-----+ +--------+ > > (1) "<1-1024> might be used as NAT" means, > A server behind a NAT. > A message, sent by server, its source port is in 1-1024 (or > 4500-4501 or ...). > The source address will be converted by NAT, the source port remains > the same. > > [Senthil] Sorry, I didn=92t read the draft, but the above logic wont > work if there are multiple servers using the same source port. > Also, in some applications (I think rcmd, rshell etc), the source > port doesn=92t have to be preserved but must be below 1024. > > Senthil [Wei] I'm presenting the proposal so as to solve this problem : assign port x-y(i.e. 1-1024) to a server(for port preserving function, like NAT), assig= n the rest of ports to others(for common NAPT). Of course, if there are many servers bebind NAT and whether or not using the same source port, NAT has to need more than one public address. But in this case ,a server will never occupys all ports of a public addre= ss, just "x-y". [Senthil] I don=92t really understand what is the use case for this? Can yo= u provide a real life use case that would benefit by this? What if the server listens on a port > 1024? Why would the server multiple = ports? Why cant a simple port forwarding work? Senthil Wei > > > > (2)<1025-65535> might be used as dynamic NAPT > Meanwhile, many hosts are behind NAT. They attempt to access to > internet. > A message, sent by a host, both its source address and port will > be converted by NAT, and the new port will be in 1025-65535. > > > It will make IP address assignment more effective. > > Cheers, > Wei > > > > behave-bounces@ietf.org 2013-07-17 12:36= :30: > > > Hi, > > > > I'm not sure what exactly you man by "might be used as NAT". > > > > 0-1024 might be used for NAPT in a FCFS basis where port > > preservation (this is what we are talking about here, right?) is needed= . > > > > As a concrete example, many IPsec Servers still expect to see the > > source port within 0-1024 and preferably a specific source port. If > > that source port is used by the NAT, and more than one IPsec client > > is behind it, there are a some choices available. > > > > - Some funky IPSec ALG (implemented in many products) > > - Give a port above 1024 and hope for the best > > - Deny the connection > > - others.. > > > > Other ports for the same public IP can be used by any other internal > > IP address. This is very common in implementations. > > > > thanks, > > > > From: behave-bounces@ietf.org [behave-b= ounces@ietf.org] on behalf of > > meng.wei2@zte.com.cn [meng.wei2@zte.com.cn= ] > > Sent: Tuesday, July 16, 2013 8:22 PM > > To: Reinaldo Penno (repenno) > > Cc: behave-bounces@ietf.org; behave@iet= f.org; Dan Wing (dwing) > > Subject: Re: [BEHAVE] NAPGT request for comments, THANKS! > > > > > Hi Reinaldo, > > So I suppose <1-1024> might be used as NAT, <1025-65535> might be use= d as > > dynamic NAPT. > > That is what this view says in the draft. > > > > Cheers, > > Wei > > > > > > behave-bounces@ietf.org 2013-07-17 09:5= 2:34: > > > > > I'm not sure this is a good idea. There are still some protocols > > > around that use ports < 1024 and maintaining the source port after > > > translation in this range is important. > > > > > > From: behave-bounces@ietf.org [behave= -bounces@ietf.org] on behalf of > > > Dan Wing (dwing) > > > Sent: Tuesday, July 16, 2013 3:30 PM > > > To: meng.wei2@zte.com.cn > > > Cc: behave@ietf.org > > > Subject: Re: [BEHAVE] NAPGT request for comments, THANKS! > > > > > > > > On Jul 15, 2013, at 2:43 AM, meng.wei2@zte.com.cn wrote: > > > > > > I have submitted a new draft. The objective is to solve a > problem that > > > prevents an external client from accessing an internal server. > > > > > > https://datatracker.ietf.org/doc/draft-meng-behave-napgt/ > > > > > > I expect your comments. Thanks a lot! > > > > > > Draft-meng-behave-napgt appears to describe something that is very > > > similar to the long-standing "DMZ host" configuration available on > > > almost all residential-class NAT devices. I don't think we could > > > standardize that behavior, but perhaps that is possible. > > > > > > Draft-meng-behave-napgt also describes an update to the port > > > assignment behavior described in http://tools.ietf. > > > org/html/rfc5382#section-7.1 (TCP) and http://tools.ietf. > > > org/html/rfc4787#section-4.2.1 (UDP). If I understand Section 4 of > > > draft-meng-behave-napgt properly, it is saying that NATs should not > > > assign ports below 1024 to dynamic connections. This might be > > > something worth considering for draft-ietf-behave-requirements-update= ? > > > > > > -d > > > _______________________________________________ > > > Behave mailing list > > > Behave@ietf.org > > > https://www.ietf.org/mailman/listinfo/behave > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave --_000_CB1B483277FEC94E9B58357040EE5D02325D26B4xmbrcdx15ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable


From: "meng.wei2@zte.com.cn" <meng.wei2@zte.com.cn>
Date: Wednesday, July 17, 2013 9:19= PM
To: Senthil Sivakumar <ssenthil@cisco.com>
Cc: "behave@ietf.org" <= behave@ietf.org>, "b= ehave-bounces@ietf.org" <behave-bounces@ietf.org>, "Dan Wing (dwing)" <dwing@= cisco.com>, "Reinaldo Penno (repenno)" <repenno@cisco.com>
Subject: Re: Re: [BEHAVE] NAPGT req= uest for comments, THANKS!


Hi,
  Please see inline.

Thanks,
Wei

"Senthil Sivakumar (ssenthil)" <ssenthil@cisco.com>  2013-07-17 = 21:30:24:

> From: "meng.wei2@zte.com.= cn" <meng.wei2@zte.com.= cn>
> Date: Wednesday, July 17, 2013 4:08 AM
> To: "Reinaldo Penno (repenno)" <repenno@cisco.com>
> Cc: "behave-bounces@ie= tf.org" <behave-boun= ces@ietf.org>, "behave@ietf.= org" <
> behave@ietf.org>, "Dan = Wing (dwing)" <dwing@cisco.com>
> Subject: Re: [BEHAVE] NAPGT request for comments, THANKS! =
>
>
> Hi,
>   I got what the example means.
>
>   1-1024 is just an example, the range could be any valid value.<= br> >
>   "<1-1024> might be used as NAT, <1025-65535> m= ight be used as
> dynamic NAPT", example is as below.
>
>    +----------+     +-----+  =  +--------+
>    + Internet + ----+ NAT +----+ Server = +
>    +----------+     +-----+  =  +--------+
>
>    (1) "<1-1024> might be used as NAT" means= ,
>        A server behind a NAT.
>    A message, sent by server, its source port is in 1-1024 (= or
> 4500-4501 or ...).
>    The source address will be converted by NAT, the source p= ort remains
>    the same.
>
> [Senthil] Sorry, I didn=92t read the draft, but the above logic wont <= br> > work if there are multiple servers using the same source port.<= /tt>
> Also, in some applications (I think rcmd, rshell = etc), the source
> port doesn=92t have to be preserved but must be below 1024.
>
> Senthil

[Wei] I'm presenting the proposal so as to solve this = problem : assign port
x-y(i.e. 1-1024) to a server(for port preserving funct= ion, like NAT), assign
the rest of ports to others(for common NAPT).
  Of course, if there are many servers bebind NAT= and whether or not using
the same source port, NAT has to need more than one pu= blic address.
  But in this case ,a server will never occupys a= ll ports of a public address,
just "x-y".

[Senthil] I don=92t really understand what is the use case for this? C= an you provide a real life use case that would benefit by this?
What if the server listens on a port > 1024? Why would the server m= ultiple ports? Why cant a simple port forwarding work?

Senthil

Wei

>
>
>
>    (2)<1025-65535> might be used as dynamic NAPT
>        Meanwhile, many hosts are behind NAT. They = attempt to access to
>     internet.
>        A message, sent by a host, both its source = address and port will
>     be converted by NAT, and the new port will be in 1025-65= 535.
>
>    
> It will make IP address assignment more effective.
>
> Cheers,
> Wei
>
>
>
> behave-bounces@ietf.org=  2013-07-17 12:36:30:
>
> > Hi,
> >
> > I'm not sure what exactly you man by "might be used as NAT&q= uot;.  
> >
> > 0-1024 might be used for NAPT in a FCFS basis where port
> > preservation (this is what we are talking about here, right?) is = needed.
> >
> > As a concrete example, many IPsec Servers still expect to see the=
> > source port within 0-1024 and preferably a specific source port. = If
> > that source port is used by the NAT, and more than one IPsec clie= nt
> > is behind it, there are a some choices available.
> >
> > - Some funky IPSec ALG (implemented in many products)
> > - Give a port above 1024 and hope for the best
> > - Deny the connection
> > - others..
> >
> > Other ports for the same public IP can be used by any other inter= nal
> > IP address. This is very common in implementations.
> >
> > thanks,
> >
> > From: behave-bounces@i= etf.org [behave-bounces@ietf= .org] on behalf of
> > meng.wei2@zte.com.cn = [meng.wei2@zte.com.cn]
> > Sent: Tuesday, July 16, 2013 8:22 PM
> > To: Reinaldo Penno (repenno)
> > Cc: behave-bounces@iet= f.org; behave@ietf.org; Dan Wing (dwing)
> > Subject: Re: [BEHAVE] NAPGT request for comments, THANKS!
>
> >
> > Hi Reinaldo,
> >   So I suppose <1-1024> might be used as NAT, <1025= -65535> might be used as
> > dynamic NAPT.
> >   That is what this view says in the draft.
> >
> > Cheers,
> > Wei
> >
> >
> > behave-bounces@ietf.or= g 2013-07-17 09:52:34:
> >
> > > I'm not sure this is a good idea. There are still some proto= cols
> > > around that use ports < 1024 and maintaining the source p= ort after
> > > translation in this range is important.
> > >
> > > From: behave-boun= ces@ietf.org [behave-bounces= @ietf.org] on behalf of
> > > Dan Wing (dwing)
> > > Sent: Tuesday, July 16, 2013 3:30 PM
> > > To: meng.wei2@zte.co= m.cn
> > > Cc: behave@ietf.org > > > Subject: Re: [BEHAVE] NAPGT request for comments, THANKS! > >
> > >
> > > On Jul 15, 2013, at 2:43 AM, meng.wei2@zte.com.cn wrote:
> > >
> > >     I have submitted a new draft. The objective is= to solve a
> problem that
> > >     prevents an external client from accessing an = internal server.
> > >
> > >     https://datatracker.ietf.org/doc/draft-meng-behave-= napgt/
> > >
> > >     I expect your comments. Thanks a lot!
> > >
> > > Draft-meng-behave-napgt appears to describe something that i= s very
> > > similar to the long-standing "DMZ host" configurat= ion available on
> > > almost all residential-class NAT devices.  I don't thin= k we could
> > > standardize that behavior, but perhaps that is possible. > > >
> > > Draft-meng-behave-napgt also describes an update to the port=
> > > assignment behavior described in http://tools.ietf.
> > > org/html/rfc5382#section-7.1 (TCP) and http://tools.ietf.
> > > org/html/rfc4787#section-4.2.1 (UDP).  If I understand = Section 4 of
> > > draft-meng-behave-napgt properly, it is saying that NATs sho= uld not
> > > assign ports below 1024 to dynamic connections.  This m= ight be
> > > something worth considering for draft-ietf-behave-requiremen= ts-update?
> > >
> > > -d
> > > _______________________________________________
> > > Behave mailing list
> > > Behave@ietf.org
> > > htt= ps://www.ietf.org/mailman/listinfo/behave
> > _______________________________________________
> > Behave mailing list
> > Behave@ietf.org
> > https://= www.ietf.org/mailman/listinfo/behave
--_000_CB1B483277FEC94E9B58357040EE5D02325D26B4xmbrcdx15ciscoc_-- From tireddy@cisco.com Thu Jul 18 10:38:26 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D9D511E81B2 for ; Thu, 18 Jul 2013 10:38:26 -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=[AWL=0.000, 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 6eMS6MySL-fY for ; Thu, 18 Jul 2013 10:38:21 -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 6C6B121E8152 for ; Thu, 18 Jul 2013 10:38:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4642; q=dns/txt; s=iport; t=1374169094; x=1375378694; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=c/NqKiHdTmxcmSR9ukaw/Lvj6hDIzJi/nM+ZSFzoatA=; b=fEcvkbH4gVllJ8Z1P/rBo27IR3KW/c0tvR3stBo1tDsJ5NSBBobNntLt F8Qeu2uz9ON9REZt6vyhTQPXPZjgzvJqxNfNVWTpMKlNLWJWJsxq7ioie QKxWC1/4Rms7UaPFUyw4yrDSvzuIOtt2oTGW3SToGqCcyImXWfMQgziDo 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFAIsn6FGtJV2a/2dsb2JhbABagwY1UMBDgRIWdIIkAQEBAQIBAQEBNzQLBQcEAgEIEQMBAQELFAkHIQYLFAkIAgQOBQgBEodjAwkGDK1FDYhejSOCOzECBQaDCG4DlXSDEop+A4UjgxKCKg X-IronPort-AV: E=Sophos;i="4.89,695,1367971200"; d="scan'208";a="236535866" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 18 Jul 2013 17:38:13 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6IHcDlW019127 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Jul 2013 17:38:13 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Thu, 18 Jul 2013 12:38:12 -0500 From: "Tirumaleswar Reddy (tireddy)" To: GangChen Thread-Topic: [BEHAVE] Fwd: I-D Action: draft-chen-behave-nat64-radius-extension-00.txt Thread-Index: AQHOgQTiad4NIKrfvUWc7EkQlMHxpZlqm8Qg Date: Thu, 18 Jul 2013 17:38:12 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A14B9CA90@xmb-rcd-x10.cisco.com> References: <20130708151636.25487.48986.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A14B9815A@xmb-rcd-x10.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.48.187] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mohamed.boucadair@orange.com" , Behave WG Subject: Re: [BEHAVE] Fwd: I-D Action: draft-chen-behave-nat64-radius-extension-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 17:38:26 -0000 Hi Gang, Please see inline > -----Original Message----- > From: GangChen [mailto:phdgang@gmail.com] > Sent: Monday, July 15, 2013 8:12 AM > To: Tirumaleswar Reddy (tireddy) > Cc: Behave WG; mohamed.boucadair@orange.com > Subject: Re: [BEHAVE] Fwd: I-D Action: draft-chen-behave-nat64-radius- > extension-00.txt >=20 > Hi Tiru, >=20 > You are right. Please check the sentence in the draft "It's also > possible to extend Port Control Protocol (PCP) to support those > network information queries from external servers. ....." >=20 > The radius-based proposal intended to fit into the environment, where > geo-location system is already deployed based on a radius > database[RFC5580]. Some benefits have been described related to this > context. Why is this problem specific to NAT64 ? (it looks like a problem with any o= ther flavor of NAT) >From the draft it looks like for every mapping create, Radius server has to= be informed which is unconditional PUSH model and could create a lot of ne= twork chatter. In PCP draft-boucadair-pcp-nat-reveal-01 it's a PULL model w= here only for interesting flows PCP-controlled NAT device is requested to p= rovide the internal IP address. > 1) radius-based solution would be a in-band solution Can you please clarify why you call radius-based solution in-band ? The example of X-Forwarded-For header provided in the draft is in-band and = any other method like Radius, PCP are out-of-band. > 2) fewer impacts to NAT64 performance because the process is > independent with NAT64 translation Even draft-boucadair-pcp-nat-reveal-01 should not impact the NAT64 performa= nce. =3D=3D=3D If you could provide more details of an example use case with topology of t= he client, NAT64, Radius Server and third party entity which will query the= Radius server for the IPv6 address and how the learnt IPv6 address will be= used for some policy decision, it will help understanding of reviewers. Cheers, --Tiru. >=20 > BRs >=20 > Gang >=20 > 2013/7/12, Tirumaleswar Reddy (tireddy) : > > Hi Gang, > > > > The problems mentioned in the draft can also be solved using PCP QUERY > > opcode introduced in > > http://tools.ietf.org/html/draft-boucadair-pcp-nat-reveal-01 > > > > --Tiru. > > > >> -----Original Message----- > >> From: GangChen [mailto:phdgang@gmail.com] > >> Sent: Tuesday, July 09, 2013 11:54 AM > >> To: Behave WG > >> Subject: [BEHAVE] Fwd: I-D Action: > >> draft-chen-behave-nat64-radius-extension- > >> 00.txt > >> > >> wg, > >> > >> We just uploaded the draft-chen-behave-nat64-radius-extension-00 > >> The draft proposes new Radius attributes to convey IPv6 source > >> addresses when a NAT64 is deployed. > >> > >> Your comments/reviews are appreciated. > >> > >> Best Regards > >> > >> Gang > >> > >> ---------- Forwarded message ---------- > >> From: internet-drafts@ietf.org > >> Date: Mon, 08 Jul 2013 08:16:36 -0700 > >> Subject: I-D Action: draft-chen-behave-nat64-radius-extension-00.txt > >> To: i-d-announce@ietf.org > >> > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts > >> directories. > >> > >> > >> Title : Radius Attributes for Stateful NAT64 > >> Author(s) : Gang Chen > >> David Binet > >> Filename : draft-chen-behave-nat64-radius-extension-00.txt > >> Pages : 10 > >> Date : 2013-07-08 > >> > >> Abstract: > >> This document proposes new radius attributes for stateful NAT64. T= he > >> extensions are used to provide geo-location services with an exact > >> IPv6 soruce address. The message flow to deliver the NAT64 binding > >> information between radius clients and servers is also described. > >> Therefore, accurate location could be traced out depending on the > >> radius method. > >> > >> > >> The IETF datatracker status page for this draft is: > >> https://datatracker.ietf.org/doc/draft-chen-behave-nat64-radius-extens= ion > >> > >> There's also a htmlized version available at: > >> http://tools.ietf.org/html/draft-chen-behave-nat64-radius-extension-00 > >> > >> > >> Internet-Drafts are also available by anonymous FTP at: > >> ftp://ftp.ietf.org/internet-drafts/ > >> > >> _______________________________________________ > >> I-D-Announce mailing list > >> I-D-Announce@ietf.org > >> https://www.ietf.org/mailman/listinfo/i-d-announce > >> Internet-Draft directories: http://www.ietf.org/shadow.html > >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > From rajmohanbanavi@gmail.com Wed Jul 17 11:56:24 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 421D921E804D; Wed, 17 Jul 2013 11:56:24 -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, HTML_MESSAGE=0.001, 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 abFslb4-zksj; Wed, 17 Jul 2013 11:56:23 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 2408C21F9F3A; Wed, 17 Jul 2013 11:56:23 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id u16so4851653iet.23 for ; Wed, 17 Jul 2013 11:56:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kT2Gvojh7D6+x9vC06KDxYq/tyr+eD3rI7eNZ/5V4QI=; b=bztslltZO4fwWEH+i5uADB2fpu1DJ8QppKHJl0b5Y3YmFGGHVTf8CwEhVKtk458T+V 3ORRrqOjNZkU5TdMl5ICQEuMtetVCOj3gxBDWUhv3FbU4QqoY9bkdlGogFHK2j0jsstV 2R39Sd+JAErusJarWqdMt55ViuYu62pper4j3DVMflBpkQPKCCrhsKD/OPXwuHsm0zMv v1ds7EHYyx5/4AQEpxeK5CfX9gUjoquOrfXi2sspsDMATAVwLj9BNnoUYOPHEj//twz/ wsZAEVi/bICf3IUlKpRKcFSBGtgaZmgjadj8fWocxS4oI3L+m2cxFGE1JNSSjUxDqL19 RELg== MIME-Version: 1.0 X-Received: by 10.50.66.210 with SMTP id h18mr11086023igt.19.1374087382679; Wed, 17 Jul 2013 11:56:22 -0700 (PDT) Received: by 10.42.152.9 with HTTP; Wed, 17 Jul 2013 11:56:22 -0700 (PDT) In-Reply-To: References: <20130715214906.5314.83583.idtracker@ietfa.amsl.com> Date: Thu, 18 Jul 2013 00:26:22 +0530 Message-ID: From: Rajmohan Banavi To: Justin Uberti Content-Type: multipart/alternative; boundary=047d7bdca46855c97504e1b9a6dd X-Mailman-Approved-At: Thu, 18 Jul 2013 12:36:59 -0700 Cc: behave@ietf.org, "rtcweb@ietf.org" Subject: Re: [BEHAVE] [rtcweb] Fwd: New Version Notification for draft-uberti-behave-turn-rest-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 18:56:24 -0000 --047d7bdca46855c97504e1b9a6dd Content-Type: text/plain; charset=ISO-8859-1 Hi Justin, I reviewed draft-uberti-behave-turn-rest-00 and have the following comments. 1. IMHO, calling the API as REST does not seem to be appropriate since the API does not follow the REST principles of addressing/operating on a resource. 2. Sec 4.3 last paragraph - "Because the password is derived from the USERNAME, successful verification of the MESSAGE-INTEGRITY ensures that the username is trustworthy". I believe this validation is taken care of in the TURN RFC itself. In order to generate the MESSAGE-INTEGRITY, the TURN client generates a long term key which is computed as => key = MD5(username ":" realm ":" SASLprep(password)). This key is used to perform hmac on the message. The same is done on the TURN server end as well. If the MESSAGE-INTEGRITY is verified, then it implies that the username is trustworthy. So why not just generate a TURN password randomly? This would avoid the need to have a secret key between the TURN server and the webrtc app. Am I missing any scenario here where this extra security is required? 3. sec 4.1 Client - Does it make it more clear if we reword the last sentence as - and the "password" value as input to generate the HMAC digest key used while calculating MESSAGE-INTEGRITY hash. 4. Sec 5.1 Revocation - Why is revoking of specific credentials not possible? Probably need more clarity on who would try to revoke the credentials and under what scenario? 5. Sec 5.2 Key Rotation - I presume here that the shared secret mentioned is the one shared between the TURN server and the webrtc application. The TURN password once generated using say secretkey1 and user1 will be valid on the TURN server till the expiry timeout (as per suggested value of 1 day) value. Why do we then need the TURN server to validate the message integrity against 2 secret keys? Wouldn't this behavior not contradict the one stated in TURN RFC? Thanks, Rajmohan MindBricks On Tue, Jul 16, 2013 at 3:22 AM, Justin Uberti wrote: > I have changed the WG for this draft from RTCWEB to BEHAVE. Many, but not > all of the comments I received on the RTCWEB mailing list have been > addressed. > > BEHAVE chairs, I would like 10 minutes of agenda time to discuss this > draft. > > ---------- Forwarded message ---------- > From: > Date: Mon, Jul 15, 2013 at 5:49 PM > Subject: New Version Notification for draft-uberti-behave-turn-rest-00.txt > To: Justin Uberti > > > > A new version of I-D, draft-uberti-behave-turn-rest-00.txt > has been successfully submitted by Justin Uberti and posted to the > IETF repository. > > Filename: draft-uberti-behave-turn-rest > Revision: 00 > Title: A REST API For Access To TURN Services > Creation date: 2013-07-15 > Group: Individual Submission > Number of pages: 8 > URL: > http://www.ietf.org/internet-drafts/draft-uberti-behave-turn-rest-00.txt > Status: > http://datatracker.ietf.org/doc/draft-uberti-behave-turn-rest > Htmlized: > http://tools.ietf.org/html/draft-uberti-behave-turn-rest-00 > > > Abstract: > This document describes a proposed standard REST API for obtaining > access to TURN services via ephemeral (i.e. time-limited) > credentials. These credentials are vended by a web service over > HTTP, and then supplied to and checked by a TURN server using the > standard TURN protocol. The usage of ephemeral credentials ensures > that access to the TURN server can be controlled even if the > credentials can be discovered by the user, as is the case in WebRTC > where TURN credentials must be specified in Javascript. > > > > > The IETF Secretariat > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > -- Life is here and now, not yesterday, not tomorrow...! --047d7bdca46855c97504e1b9a6dd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Justin,

I reviewed=A0draft-uberti-behave-turn-rest-<= span style=3D"font-family:arial,sans-serif;font-size:13px">00=A0and have the following comments.
  1. IMHO, calling the API as REST does not seem to be appropriate since= the API does not follow the REST principles of addressing/operating on a r= esource.
  2. Sec 4.3 last paragraph - "Because the password is der= ived from the USERNAME, successful verification of the MESSAGE-INTEGRITY en= sures that the username is trustworthy". I believe this validation is = taken care of in the TURN RFC itself. In order to generate the MESSAGE-INTE= GRITY, the TURN client generates a long term key which is computed as =3D&g= t;=A0key =3D MD5(username &q= uot;:" realm ":" SASLprep(password)). This key is used to pe= rform hmac on the message. The same is done on the TURN server end as well.= If the MESSAGE-INTEGRITY is verified, then it implies that the username is= trustworthy. So=A0why not just generate a TURN password randomly? T= his would avoid the need to have a secret key between the TURN server and t= he webrtc app. Am I missing any scenario here where this extra security is = required?
  3. sec 4.1 Client - Does it make it more clear if we reword the last sente= nce as - and the "password" value as input to generate the HMAC d= igest key used while calculating MESSAGE-INTEGRITY hash.
  4. Sec 5.1 Re= vocation - Why is revoking of specific credentials not possible? Probably n= eed more clarity on who would try to revoke the credentials and under what = scenario?
  5. Sec 5.2 Key Rotation - I presume here that the shared secret mentioned = is the one shared between the TURN server and the webrtc application. The T= URN password once generated using say secretkey1 and user1 will be valid on= the TURN server till the expiry timeout (as per suggested value of 1 day) = value. Why do we then need the TURN server to validate the message integrit= y against 2 secret keys? Wouldn't this behavior not contradict the one = stated in TURN RFC?
Thanks,
Rajmohan
MindBricks


On Tue, Jul 16, 2013= at 3:22 AM, Justin Uberti <juberti@google.com> wrote:
I have changed the WG for t= his draft from RTCWEB to BEHAVE. Many, but not all of the comments I receiv= ed on the RTCWEB mailing list have been addressed.

BEHAVE chairs, I would like= 10 minutes of agenda time to discuss this draft.

---------- Forwarded message ----------
F= rom: <internet-drafts@ietf.org>
Date: Mon, Jul 15, 2013 at 5:49 PM
Subject: New Version Notification for= draft-uberti-behave-turn-rest-00.txt
To: Justin Uberti <justin@uberti.name>



A new version of I-D, draft-uberti-behave-turn-rest-00.txt
has been successfully submitted by Justin Uberti and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-uberti-behave-turn-rest
Revision: =A0 =A0 =A0 =A000
Title: =A0 =A0 =A0 =A0 =A0 A REST API For Access To TURN Services
Creation date: =A0 2013-07-15
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 8
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.or= g/internet-drafts/draft-uberti-behave-turn-rest-00.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc= /draft-uberti-behave-turn-rest
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-ub= erti-behave-turn-rest-00


Abstract:
=A0 =A0This document describes a proposed standard REST API for obtaining =A0 =A0access to TURN services via ephemeral (i.e. time-limited)
=A0 =A0credentials. =A0These credentials are vended by a web service over =A0 =A0HTTP, and then supplied to and checked by a TURN server using the =A0 =A0standard TURN protocol. =A0The usage of ephemeral credentials ensure= s
=A0 =A0that access to the TURN server can be controlled even if the
=A0 =A0credentials can be discovered by the user, as is the case in WebRTC<= br> =A0 =A0where TURN credentials must be specified in Javascript.




The IETF Secretariat




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




--

Life= is here and now, not yesterday, not tomorrow...!
--047d7bdca46855c97504e1b9a6dd-- From fippo@goodadvice.pages.de Wed Jul 17 13:40:09 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19D6D21F9DFA; Wed, 17 Jul 2013 13:40:09 -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 1ZpfXPyWas-2; Wed, 17 Jul 2013 13:39:50 -0700 (PDT) Received: from lo.psyced.org (lost.IN.psyced.org [188.40.42.221]) by ietfa.amsl.com (Postfix) with ESMTP id 6F4FA21F9344; Wed, 17 Jul 2013 13:39:49 -0700 (PDT) Received: from [192.168.2.100] (p549700D7.dip0.t-ipconnect.de [84.151.0.215]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id r6HKddb9026363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Jul 2013 22:39:44 +0200 Message-ID: <51E70106.8060100@goodadvice.pages.de> Date: Wed, 17 Jul 2013 22:39:34 +0200 From: Philipp Hancke User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: rajmohanbanavi@gmail.com References: <20130715214906.5314.83583.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 18 Jul 2013 12:36:59 -0700 Cc: behave@ietf.org, rtcweb@ietf.org Subject: Re: [BEHAVE] [rtcweb] Fwd: New Version Notification for draft-uberti-behave-turn-rest-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 20:40:09 -0000 Am 17.07.2013 20:56, schrieb Rajmohan Banavi: > Hi Justin, > > I reviewed draft-uberti-behave-turn-rest-00 and have the following comments. [...] > 2. Sec 4.3 last paragraph - "Because the password is derived from the > USERNAME, successful verification of the MESSAGE-INTEGRITY ensures that the > username is trustworthy". I believe this validation is taken care of in the > TURN RFC itself. In order to generate the MESSAGE-INTEGRITY, the TURN > client generates a long term key which is computed as => key = > MD5(username ":" realm ":" SASLprep(password)). This key is used to perform > hmac on the message. The same is done on the TURN server end as well. If > the MESSAGE-INTEGRITY is verified, then it implies that the username is > trustworthy. Let me try to address that with a lenghty example: The web server returns password = BASE64(HMAC-SHA1(username, sharedsecret)) to the browser. For example, with username = "12334939:mbzrxpgjys" and sharedsecret "secret", the password given to the browser would be "+4pCXR06gx/cqAikLYnBajtZW6E=" (hopefully) The browser passes the username, uri and password to it's webrtc stack. The password is exposed to the user of the browser (which might be anyone surfing your website) during that process. That stack does long term authentication and uses this password string as input for calculating MESSAGE-INTEGRITY with key = MD5(username ":" realm ":" SASLprep(password)) For the example this would be key =MD5("12334939:mbzrxpgjys" ":" realm ":" SASLprep("+4pCXR06gx/cqAikLYnBajtZW6E=") On the TURN server, the key for MESSAGE-INTEGRITY is calculated using key = MD5(username ":" realm ":" SASLprep(BASE64(HMAC-SHA1(USERNAME, sharedsecret)) So for the example this would be = MD5("12334939:mbzrxpgjys" ":" realm ":" SASLprep(BASE64(HMAC-SHA1("12334939:mbzrxpgjys", "secret")) = MD5("12334939:mbzrxpgjys" ":" realm ":" SASLprep("+4pCXR06gx/cqAikLYnBajtZW6E=") So the browser and turn server use the same input to the M-I. This can be done by looking at the request alone given the shared secret. Does that make it clearer? philipp, who only understood it after implementing it From rajmohanbanavi@gmail.com Wed Jul 17 14:09:16 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 004BD21E8056; Wed, 17 Jul 2013 14:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 2ftoC1RjchGA; Wed, 17 Jul 2013 14:09:15 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id B06CE21E8055; Wed, 17 Jul 2013 14:09:14 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id 10so5202767ied.14 for ; Wed, 17 Jul 2013 14:09:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XSY0uoWPDRiCPpiu9+WoyqJnEG2LNDdqGP3KoTKOass=; b=YAD5I2MF2ICVikl9m+tX4fo93W/h5jBIGI2Ii/bS9q9Xbemz2Hv7XO2VNCElZtdxmn geMBPmVTx+4a5X8ncbURgmTPxuPQXL289UdvBmlXJzkKoLU6G1/O+52QYDlK+xMl/EWQ QAZVlQEpBsCrsTLSj72q1raCfzkkz3XaLdBsIXCQvDCWmqfjygywoHOruNb12ED0KuI1 JgVttTCF93rCNIn5ad5d13TMih3o4hwVddbQ3daHj72nV6IH5TVFZOH+z/7RfbX7gL3g tAeoRgOZx2j2WvzQDH2hAChj2ABTBJBder+NxItoAm17UaaPjsNGZXcIblqE4O4jiKDY EIjw== MIME-Version: 1.0 X-Received: by 10.50.62.75 with SMTP id w11mr2027212igr.19.1374095354174; Wed, 17 Jul 2013 14:09:14 -0700 (PDT) Received: by 10.42.152.9 with HTTP; Wed, 17 Jul 2013 14:09:14 -0700 (PDT) In-Reply-To: <51E70106.8060100@goodadvice.pages.de> References: <20130715214906.5314.83583.idtracker@ietfa.amsl.com> <51E70106.8060100@goodadvice.pages.de> Date: Thu, 18 Jul 2013 02:39:14 +0530 Message-ID: From: Rajmohan Banavi To: Philipp Hancke Content-Type: multipart/alternative; boundary=047d7bdc10e47923a204e1bb811b X-Mailman-Approved-At: Thu, 18 Jul 2013 12:36:59 -0700 Cc: behave@ietf.org, "rtcweb@ietf.org" Subject: Re: [BEHAVE] [rtcweb] Fwd: New Version Notification for draft-uberti-behave-turn-rest-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 21:09:16 -0000 --047d7bdc10e47923a204e1bb811b Content-Type: text/plain; charset=ISO-8859-1 Thanks for the detailed example. I agree with the entire flow you have given. My only concern is - why should the ephemeral password be generated by TURN server using HMAC SHA on then username string? Why can't this be some random unique string? Taking your example - Suppose TURN server generates credentials, username = "12334939:mbzrxpgjys" and password ="+somerandomstring+". This is a randomly generated string and passed onto webrtc app. The TURN server also stores these credentials for later validation. var iceServer = { "username": 12334939:mbzrxpgjys, "credential": +somerandomstring+, }; These credentials are passed from JS to the webrtc client stack in the browser. On Browser WebTRC Client. key = MD5(12334939:mbzrxpgjys ":" realm ":" +somerandomstring+) Similarly on the TURN server, the key for MESSAGE-INTEGRITY is calculated using key = MD5(12334939:mbzrxpgjys ":" realm ":" +somerandomstring+) So the browser and turn server use the same input to the M-I. The one implementation related advantage I see with this way of generation of TURN password using HMAC is that the TURN server need not really store the HMAC generated password, but can calculate the same using the USERNAME attribute in the received TURN request. In fact, I do not see why the sharedsecret needs to be shared between the TURN server and the WebRTC application. The sharedsecret key "secret" is only required by the TURN server for validating the received TURN ALLOCATE requests once it has generated and sent out the ephemeral credentials. What does the WebRTC application do with the shared secret key? Thanks, Rajmohan On Thu, Jul 18, 2013 at 2:09 AM, Philipp Hancke wrote: > Am 17.07.2013 20:56, schrieb Rajmohan Banavi: > > Hi Justin, >> >> I reviewed draft-uberti-behave-turn-rest-**00 and have the following >> comments. >> > [...] > >> 2. Sec 4.3 last paragraph - "Because the password is derived from the >> >> USERNAME, successful verification of the MESSAGE-INTEGRITY ensures >> that the >> username is trustworthy". I believe this validation is taken care of >> in the >> TURN RFC itself. In order to generate the MESSAGE-INTEGRITY, the TURN >> client generates a long term key which is computed as => key = >> MD5(username ":" realm ":" SASLprep(password)). This key is used to >> perform >> hmac on the message. The same is done on the TURN server end as well. >> If >> the MESSAGE-INTEGRITY is verified, then it implies that the username >> is >> trustworthy. >> > > Let me try to address that with a lenghty example: > The web server returns > password = BASE64(HMAC-SHA1(username, sharedsecret)) > to the browser. > > For example, with username = "12334939:mbzrxpgjys" and sharedsecret > "secret", the password given to the browser would be > "+4pCXR06gx/cqAikLYnBajtZW6E=" (hopefully) > > > > > The browser passes the username, uri and password to it's webrtc stack. > The password is exposed to the user of the browser (which might be anyone > surfing your website) during that process. > > That stack does long term authentication and uses this password string as > input for calculating MESSAGE-INTEGRITY with > key = MD5(username ":" realm ":" SASLprep(password)) > > For the example this would be > key =MD5("12334939:mbzrxpgjys" ":" realm ":" SASLprep("+4pCXR06gx/** > cqAikLYnBajtZW6E=") > > > > > On the TURN server, the key for MESSAGE-INTEGRITY is calculated using > key = MD5(username ":" realm ":" SASLprep(BASE64(HMAC-SHA1(**USERNAME, > sharedsecret)) > > So for the example this would be > = MD5("12334939:mbzrxpgjys" ":" realm ":" SASLprep(BASE64(HMAC-SHA1("**12334939:mbzrxpgjys", > "secret")) > = MD5("12334939:mbzrxpgjys" ":" realm ":" SASLprep("+4pCXR06gx/** > cqAikLYnBajtZW6E=") > > So the browser and turn server use the same input to the M-I. This can be > done by looking at the request alone given the shared secret. > > > Does that make it clearer? > > philipp, > who only understood it after implementing it > -- Life is here and now, not yesterday, not tomorrow...! --047d7bdc10e47923a204e1bb811b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks for the detailed example. I agree with the entire f= low you have given. My only concern is - why should the ephemeral password = be generated by TURN server using HMAC SHA on then username string? Why can= 't this be some random unique string?

Taking your example -=A0

Suppose= TURN server generates credentials, username =3D "12334939:mbzrxpgjys&= quot; and password =3D"+somerandomstring+". This is a randomly generated = string and passed onto webrtc app. The TURN server also stores these creden= tials for later validation.
var iceServer =3D {
= =A0 =A0 =A0"username":=A0= 12334939:mbzrxp= gjys,
=A0 =A0 =A0"credential":=A0= +someran= domstring+,
=A0 =A0};

These credentials are passed from JS to the webrtc clien= t stack in the browser.

On= Browser WebTRC Client.=A0
key =3D MD5(12334939:mbzrxpgjys=A0":" realm &q= uot;:"=A0+somerandomstring+)
Simi= larly on the TURN server, the key for MESSAGE-INTEGRITY is calculated using=
key =3D MD5(12334939:mbzrxpgjys=A0":= " realm ":"=A0+somerandomstring+)

So the browser and turn server u= se the same input to the M-I. The one implementation related advantage I se= e with this way of generation of TURN password using HMAC is that the TURN = server need not really store the HMAC generated password, but can calculate= the same using the USERNAME attribute in the received TURN request.=

=
In fact, I do not see why the sharedsecret needs to be shared betw= een the TURN server and the WebRTC application. The sharedsecret key "= secret" is only required by the TURN server for validating the receive= d TURN ALLOCATE requests once it has generated and sent out the ephemeral c= redentials. What does the WebRTC application do with the shared secret key?=

Thanks,
Rajmohan


On Thu,= Jul 18, 2013 at 2:09 AM, Philipp Hancke <fippo@goodadvice.pages.d= e> wrote:
Am 17.07.2013 20:56, schrieb Rajmohan Banavi= :

Hi Justin,

I reviewed draft-uberti-behave-turn-rest-00 and have the following c= omments.
[...]
=A0 =A0 2. Sec 4.3 last paragraph - "Because the password is derived f= rom the

=A0 =A0 USERNAME, successful verification of the MESSAGE-INTEGRITY ensures = that the
=A0 =A0 username is trustworthy". I believe this validation is taken c= are of in the
=A0 =A0 TURN RFC itself. In order to generate the MESSAGE-INTEGRITY, the TU= RN
=A0 =A0 client generates a long term key which is computed as =3D> key = =3D
=A0 =A0 MD5(username ":" realm ":" SASLprep(password)).= This key is used to perform
=A0 =A0 hmac on the message. The same is done on the TURN server end as wel= l. If
=A0 =A0 the MESSAGE-INTEGRITY is verified, then it implies that the usernam= e is
=A0 =A0 trustworthy.

Let me try to address that with a lenghty example:
The web server returns
password =3D BASE64(HMAC-SHA1(username, sharedsecret))
to the browser.

For example, with username =3D "12334939:mbzrxpgjys" and sharedse= cret "secret", the password given to the browser would be
"+4pCXR06gx/cqAikLYnBajtZW6E=3D" (hopefully)




The browser passes the username, uri and password to it's webrtc stack.=
The password is exposed to the user of the browser (which might be anyone s= urfing your website) during that process.

That stack does long term authentication and uses this password string as i= nput for calculating MESSAGE-INTEGRITY with
key =3D MD5(username ":" realm ":" SASLprep(password))<= br>
For the example this would be
key =3DMD5("12334939:mbzrxpgjys" ":" realm ":"= ; SASLprep("+4pCXR06gx/cqAikLYnBajtZW6E=3D")




On the TURN server, the key for MESSAGE-INTEGRITY is calculated using
key =3D MD5(username ":" realm ":" SASLprep(BASE64(HMAC= -SHA1(USERNAME, sharedsecret))

So for the example this would be
=A0=3D MD5("12334939:mbzrxpgjys" ":" realm ":"= ; SASLprep(BASE64(HMAC-SHA1("12334939:mbzrxpgjys", "s= ecret"))
=A0=3D MD5("12334939:mbzrxpgjys" ":" realm ":"= ; SASLprep("+4pCXR06gx/cqAikLYnBajtZW6E=3D")

So the browser and turn server use the same input to the M-I. This can be d= one by looking at the request alone given the shared secret.


Does that make it clearer?

philipp,
who only understood it after implementing it



--

Life is = here and now, not yesterday, not tomorrow...!
--047d7bdc10e47923a204e1bb811b-- From rajmohanbanavi@gmail.com Thu Jul 18 05:28:18 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FBA221F8D0D; Thu, 18 Jul 2013 05:28: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, HTML_MESSAGE=0.001, 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 Wi0RqG+PGIVl; Thu, 18 Jul 2013 05:28:17 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id AB68A21F8895; Thu, 18 Jul 2013 05:28:17 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id 10so6968332ied.0 for ; Thu, 18 Jul 2013 05:28:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/sGhxOCPIg1cfuS5hK+Pf+YrhGs8LYx6AoGDVazxhPk=; b=SvCK1F/zJqqgeWcU0lX7+g4lftHYH+nZIttdZ/7ihMKGQu77XNZw8q+sKf93NyQ5Zq GKPl18RGLxAOExuW3kEPzKAaGuvQbPOey/TNXf17RbaYI9c5JVK4m+Q6xiMP1wpYmJ+d ZYfxCL6scYS1g/wuO66ZzjbE3VQ1AYtsYxX8oWxcFyAR+3wuPKAfWfY+VdZkP6C3JI+p OwRrg6qFnfAxOEkxu7+I+xf8HAfOBIxv9A6QBaEEncK3Qy9GQc7NhbHKDCqvFfCHQOxX FGfx1/cuuP5U4ht9GyPcxhtLp0FT+m7aZKHrDM86jZJJemjWtHJy+T+0xb99exQvjnY6 FPRQ== MIME-Version: 1.0 X-Received: by 10.50.1.78 with SMTP id 14mr2951908igk.60.1374150497256; Thu, 18 Jul 2013 05:28:17 -0700 (PDT) Received: by 10.42.152.9 with HTTP; Thu, 18 Jul 2013 05:28:17 -0700 (PDT) In-Reply-To: References: <20130715214906.5314.83583.idtracker@ietfa.amsl.com> <51E70106.8060100@goodadvice.pages.de> Date: Thu, 18 Jul 2013 17:58:17 +0530 Message-ID: From: Rajmohan Banavi To: Justin Uberti Content-Type: multipart/alternative; boundary=047d7bdc119a41cf0c04e1c85826 X-Mailman-Approved-At: Thu, 18 Jul 2013 12:36:59 -0700 Cc: "rtcweb@ietf.org" , Philipp Hancke , behave Subject: Re: [BEHAVE] [rtcweb] Fwd: New Version Notification for draft-uberti-behave-turn-rest-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 12:28:18 -0000 --047d7bdc119a41cf0c04e1c85826 Content-Type: text/plain; charset=ISO-8859-1 Hi Justin, comments inline with additional comments at the end. Correct, but that is a significant advantage, especially when the web and > TURN servers are separate entities. > IMHO, the standard spec should not be based on any specific implementation method. Now I agree that the TURN server validation becomes easier using this method because it does not have to do some sort of lookup. However, some another TURN server implementer can achieve the same functionality by providing REST API but using randomly generated pasword (rather than use HMAC) and using some sort of lookup for TURN username when TURN ALLOCATE request is received. Now lets look at the collateral affects of using this proposed implementation way - TURN server needs to perform MESSAGE-INTEGRITY validation across two secrets (worst case due to key rotation) when TURN ALLOCATE request is received - TURN username needs to consist of entire state (user identifier + expiry time). And upon receiving the ALLOCATE request, TURN server must check if the username is still valid based on expiry time part (of username) - Time sync needs to be maintained across the web server and the TURN server. All of the above are not needed if one does not use the implementation method specified in the draft but still provide REST API to generate ephemeral credentials. How these ephemeral credentials are generated and how the TURN requests are validated is an implementation decision. And it is not desirable to have standards which caters to each implementation method. > The WebRTC client application doesn't see the secret key, this is only > shared between the web and TURN servers. > What does the web server do with the secret key? This is not clear from the text. Additional comments. 1. Sec 4.2 Server - "Note that the REALM value supplied by the server is not meaningful in this context, and can be set to any valid value". Which realm value is being referred here? The REALM attribute value in the 401 challenge response sent by the TURN server (in response to initial ALLOCATE request)? 2. The implementation method proposed is implicit and not clear from the draft text for the reader. The text states that username must be so and so, password must be HMAC processed etc, but it is not clear why these need to be done. It must be made clear somewhere in the draft that these are being proposed to ensure that the TURN server can validate the TURN ALLOCATE requests by performing HMAC on the USERNAME attribute received. And that the TURN server does not have to maintain/store ephemeral credentials. This will help the reader to comprehend the draft in a better way. Hope it is clear. Thanks, Rajmohan Banavi --047d7bdc119a41cf0c04e1c85826 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi =A0Justin, comments inline with additional comments at = the end.

Correct, but that is a significant advantage, especially when the web and = TURN servers are separate entities.=A0
=

IMHO, the standard spec should not be based on any specific = implementation method. Now I agree that the TURN server validation becomes = easier using this method because it does not have to do some sort of lookup= . However, some another TURN server implementer can achieve the same functi= onality by providing REST API but using randomly generated pasword (rather = than use HMAC) and using some sort of lookup for TURN username when TURN AL= LOCATE request is received.

Now lets look at the collateral affects of using this p= roposed implementation way
- TURN server needs to perform MESSAGE= -INTEGRITY validation across two secrets (worst case due to key rotation) w= hen TURN ALLOCATE request is received
- TURN username needs to consist of entire state (user identifier + ex= piry time). And upon receiving the ALLOCATE request, TURN server must check= if the username is still valid based on expiry time part (of username)
- Time sync needs to be maintained across the web server and the TURN = server.

All of the above are not needed if one doe= s not use the implementation method specified in the draft but still provid= e REST API to generate ephemeral credentials. How these ephemeral credentia= ls are generated and how the TURN requests are validated is an implementati= on decision. And it is not desirable to have standards which caters to each= implementation method.=A0
=A0
The WebRTC client application doesn't see the secret key, this is only= shared between the web and TURN servers.

What does the web server do with the secre= t key? This is not clear from the text.

Additional= comments.
  1. Sec 4.2 Server - "Note that the REALM val= ue supplied by the server is not meaningful in this context, and can be set= to any valid value". Which realm value is being referred here? The RE= ALM attribute value in the 401 challenge response sent by the TURN server (= in response to initial ALLOCATE request)?
  2. The implementation method proposed is implicit and not clear from = the draft text for the reader. The text states that username must be so and= so, password must be HMAC processed etc, but it is not clear why these nee= d to be done. It must be made clear somewhere in the draft that these are b= eing proposed to ensure that the TURN server can validate the TURN ALLOCATE= requests by performing HMAC on the USERNAME attribute received. And that t= he TURN server does not have to maintain/store ephemeral credentials. This = will help the reader to comprehend the draft in a better way.
Hope it is clear.

Thanks,
Rajmohan Banavi

--047d7bdc119a41cf0c04e1c85826-- From dwing@cisco.com Thu Jul 18 18:33:05 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC93811E824D for ; Thu, 18 Jul 2013 18:33:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.408 X-Spam-Level: X-Spam-Status: No, score=-109.408 tagged_above=-999 required=5 tests=[AWL=-1.028, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, TVD_SPACE_RATIO=2.219, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tWV8oR2ovQmT for ; Thu, 18 Jul 2013 18:32:50 -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 D35AA11E81DD for ; Thu, 18 Jul 2013 18:32:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=104; q=dns/txt; s=iport; t=1374197570; x=1375407170; h=from:content-transfer-encoding:subject:message-id:date: to:mime-version; bh=f2TleRMt/4vhkzorHqEpqc8qKAYBPF6THFvmsV2bl9c=; b=LlR/ZMslnra/pNYNaTChJpZ2P+veGDSnRHlAllkSzweiGf0sS4OlucDS fN4IanN+6oDPhfg4Zt1JQeWqCfQaVH/8GiW+YG+hAUb2PuswI+ijjKhX6 j8okN2XkwR7aci3k2/IPMcOh9gPhejGR63V/nqSS6zqO3BL7uiTDyDg7y s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuUMAPKV6FGrRDoH/2dsb2JhbABagwY1ARWCeYk3tEkCAgICgRUWcASCZYF9HIgGDZV1oEGOfYQnbgOJKI41hiOLKoMyHA X-IronPort-AV: E=Sophos;i="4.89,697,1367971200"; d="scan'208";a="83405520" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 19 Jul 2013 01:32:44 +0000 Received: from [10.156.16.29] ([10.156.16.29]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r6J1WiQb014838 for ; Fri, 19 Jul 2013 01:32:44 GMT From: Dan Wing Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: Date: Thu, 18 Jul 2013 18:32:44 -0700 To: "" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [BEHAVE] BEHAVE preliminary agenda X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 01:33:05 -0000 Our preliminary agenda is posted at http://www.ietf.org/proceedings/87/agenda/agenda-87-behave -d From phdgang@gmail.com Fri Jul 19 02:50:52 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D357021F9FD1 for ; Fri, 19 Jul 2013 02:50:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.105 X-Spam-Level: X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[AWL=-0.105, BAYES_00=-2.599, J_CHICKENPOX_82=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 r6+p2d5uwCof for ; Fri, 19 Jul 2013 02:50:52 -0700 (PDT) Received: from mail-qe0-x236.google.com (mail-qe0-x236.google.com [IPv6:2607:f8b0:400d:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 0189721F9F85 for ; Fri, 19 Jul 2013 02:50:51 -0700 (PDT) Received: by mail-qe0-f54.google.com with SMTP id ne12so2306667qeb.13 for ; Fri, 19 Jul 2013 02:50: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=a4AnCPAsTgyywotVuUesbeBi88paDWjgQl+krQIrQdg=; b=w1+C9ImH7BRhKMlHoVyHZU7IghinQhFxa+Pl+Ul4d11GwZU4bJ0NB2k+LXR6SX+Vss WE+1ZSnkXhIjXRbzq17tYt9QKEbOaHNb74wwK33I1q+MbqmScu6FUPi9ZGjM5SsDMp8d e5YLf5FRjc/k2rjdLlfIMEJ3CIdd1J63fJ2UiVc4z3Vz41dPTLZ+Ie81PqJFe8fOxBK8 3pG8k+29DAasPMd7rDl+qyi8CG1euieMBVi+7YMqShDE/BEI/e8lU9FsXqi6Zl02fPxx 7DbReBtA4l+3pNGJt+3fqSUxmDZ5sGVXhYMazVmvZXx8SwDaLf7u0380KPaaMDFRIa7H lOmg== MIME-Version: 1.0 X-Received: by 10.49.0.140 with SMTP id 12mr16727796qee.26.1374227451371; Fri, 19 Jul 2013 02:50:51 -0700 (PDT) Received: by 10.224.182.74 with HTTP; Fri, 19 Jul 2013 02:50:51 -0700 (PDT) In-Reply-To: <913383AAA69FF945B8F946018B75898A14B9CA90@xmb-rcd-x10.cisco.com> References: <20130708151636.25487.48986.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A14B9815A@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A14B9CA90@xmb-rcd-x10.cisco.com> Date: Fri, 19 Jul 2013 17:50:51 +0800 Message-ID: From: GangChen To: "Tirumaleswar Reddy (tireddy)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "mohamed.boucadair@orange.com" , Behave WG Subject: Re: [BEHAVE] Fwd: I-D Action: draft-chen-behave-nat64-radius-extension-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 09:50:52 -0000 Hi Tiru, Thanks for the comments. 2013/7/19, Tirumaleswar Reddy (tireddy) : > Hi Gang, > > Please see inline > >> -----Original Message----- >> From: GangChen [mailto:phdgang@gmail.com] >> Sent: Monday, July 15, 2013 8:12 AM >> To: Tirumaleswar Reddy (tireddy) >> Cc: Behave WG; mohamed.boucadair@orange.com >> Subject: Re: [BEHAVE] Fwd: I-D Action: draft-chen-behave-nat64-radius- >> extension-00.txt >> >> Hi Tiru, >> >> You are right. Please check the sentence in the draft "It's also >> possible to extend Port Control Protocol (PCP) to support those >> network information queries from external servers. ....." >> >> The radius-based proposal intended to fit into the environment, where >> geo-location system is already deployed based on a radius >> database[RFC5580]. Some benefits have been described related to this >> context. > > Why is this problem specific to NAT64 ? (it looks like a problem with any > other flavor of NAT) The problem is general to all the NAT-based deployments. But NAT64 has the uniqueness, because the internal source is a IPv6 address, which has a global meaning. The system doesn't have to correlate other information to identify user. > From the draft it looks like for every mapping create, Radius server has to > be informed which is unconditional PUSH model and could create a lot of > network chatter. No. If you take a look at Fig.1 Requested-Binding-Info message would convey the conditions. Only the matched mappings should report to the Radius server. It's a PULL model. > In PCP draft-boucadair-pcp-nat-reveal-01 it's a PULL model > where only for interesting flows PCP-controlled NAT device is requested to > provide the internal IP address. I don't want to make much comparisons because it may be "don't have to". Every case has their benefits and suitable cases. RFC6967 lists multiple solutions to reveal the source. That gives several possibilities for the deployment. As you can see, we are also using different approaches to discover NAT64 prefix. I don't see the harm. The document just intends to describe the unique needs. >> 1) radius-based solution would be a in-band solution > > Can you please clarify why you call radius-based solution in-band ? Some geo-location systems receive the information through radius messages(as described in RFC5580). The proposed radius message could be get along with same radius systems. Therefore, that is an in-band solution. > The example of X-Forwarded-For header provided in the draft is in-band and > any other method like Radius, PCP are out-of-band. Yes. it's a different definition. >> 2) fewer impacts to NAT64 performance because the process is >> independent with NAT64 translation > Even draft-boucadair-pcp-nat-reveal-01 should not impact the NAT64 > performance. Yes. We don't intent to say your solution impacts NAT64 performance. This context is limited to radius vs application aware functions. > === > > If you could provide more details of an example use case with topology of > the client, NAT64, Radius Server and third party entity which will query the > Radius server for the IPv6 address and how the learnt IPv6 address will be > used for some policy decision, it will help understanding of reviewers. Good suggestions. I will add the additional descriptions Best Regards Gang > Cheers, > > --Tiru. > >> >> BRs >> >> Gang >> >> 2013/7/12, Tirumaleswar Reddy (tireddy) : >> > Hi Gang, >> > >> > The problems mentioned in the draft can also be solved using PCP QUERY >> > opcode introduced in >> > http://tools.ietf.org/html/draft-boucadair-pcp-nat-reveal-01 >> > >> > --Tiru. >> > >> >> -----Original Message----- >> >> From: GangChen [mailto:phdgang@gmail.com] >> >> Sent: Tuesday, July 09, 2013 11:54 AM >> >> To: Behave WG >> >> Subject: [BEHAVE] Fwd: I-D Action: >> >> draft-chen-behave-nat64-radius-extension- >> >> 00.txt >> >> >> >> wg, >> >> >> >> We just uploaded the draft-chen-behave-nat64-radius-extension-00 >> >> The draft proposes new Radius attributes to convey IPv6 source >> >> addresses when a NAT64 is deployed. >> >> >> >> Your comments/reviews are appreciated. >> >> >> >> Best Regards >> >> >> >> Gang >> >> >> >> ---------- Forwarded message ---------- >> >> From: internet-drafts@ietf.org >> >> Date: Mon, 08 Jul 2013 08:16:36 -0700 >> >> Subject: I-D Action: draft-chen-behave-nat64-radius-extension-00.txt >> >> To: i-d-announce@ietf.org >> >> >> >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> >> directories. >> >> >> >> >> >> Title : Radius Attributes for Stateful NAT64 >> >> Author(s) : Gang Chen >> >> David Binet >> >> Filename : draft-chen-behave-nat64-radius-extension-00.txt >> >> Pages : 10 >> >> Date : 2013-07-08 >> >> >> >> Abstract: >> >> This document proposes new radius attributes for stateful NAT64. >> >> The >> >> extensions are used to provide geo-location services with an exact >> >> IPv6 soruce address. The message flow to deliver the NAT64 binding >> >> information between radius clients and servers is also described. >> >> Therefore, accurate location could be traced out depending on the >> >> radius method. >> >> >> >> >> >> The IETF datatracker status page for this draft is: >> >> https://datatracker.ietf.org/doc/draft-chen-behave-nat64-radius-extension >> >> >> >> There's also a htmlized version available at: >> >> http://tools.ietf.org/html/draft-chen-behave-nat64-radius-extension-00 >> >> >> >> >> >> Internet-Drafts are also available by anonymous FTP at: >> >> ftp://ftp.ietf.org/internet-drafts/ >> >> >> >> _______________________________________________ >> >> I-D-Announce mailing list >> >> I-D-Announce@ietf.org >> >> https://www.ietf.org/mailman/listinfo/i-d-announce >> >> Internet-Draft directories: http://www.ietf.org/shadow.html >> >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> > >> > > From tireddy@cisco.com Fri Jul 19 06:00:08 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6111D11E8118 for ; Fri, 19 Jul 2013 06:00:08 -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_82=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 t+NeqAHu+iLA for ; Fri, 19 Jul 2013 06:00:03 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id D679011E8117 for ; Fri, 19 Jul 2013 06:00:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7298; q=dns/txt; s=iport; t=1374238803; x=1375448403; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=OtaJ9tSvjIHhCL5g/qBKM3Cr9gY0cH6X3xYTa4C6uC4=; b=T4cXlLw4j5i0BWXRLjCnr47Q5id5l0xL2cuPsgbImCuVjYAvBgxrjvRO 1dXT5/9I7Ggo/P2e8kuPF9m8Yer4650oP/Yg+RUj0KCQbdseJBaNhIYPb ks7pOlmaEtO3b2hfZEwDwWjmbZs3zU8g/yrWG6GGhBMgXHCyTjZg4g4iZ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAEs36VGtJXHA/2dsb2JhbABQCoMGNVDARoEQFnSCJAEBAQMBAQEBNzQLDAQCAQgRAwEBAQsUCQchBgsUCQgCBA4FCAESh2MDCQYMrgoNiF6NI4EwBIEHMQIFBoMKbgOVdIMSin4DhSODEoFoQg X-IronPort-AV: E=Sophos;i="4.89,701,1367971200"; d="scan'208";a="236932511" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-6.cisco.com with ESMTP; 19 Jul 2013 13:00:02 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r6JD01XF018017 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 19 Jul 2013 13:00:02 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.02.0318.004; Fri, 19 Jul 2013 08:00:01 -0500 From: "Tirumaleswar Reddy (tireddy)" To: GangChen Thread-Topic: [BEHAVE] Fwd: I-D Action: draft-chen-behave-nat64-radius-extension-00.txt Thread-Index: AQHOgQTiad4NIKrfvUWc7EkQlMHxpZlqm8QggAGA64D//94ScA== Date: Fri, 19 Jul 2013 13:00:00 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A14B9E551@xmb-rcd-x10.cisco.com> References: <20130708151636.25487.48986.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A14B9815A@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A14B9CA90@xmb-rcd-x10.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.64.159] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mohamed.boucadair@orange.com" , Behave WG Subject: Re: [BEHAVE] Fwd: I-D Action: draft-chen-behave-nat64-radius-extension-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 13:00:08 -0000 Hi Gang, Please see inline > -----Original Message----- > From: GangChen [mailto:phdgang@gmail.com] > Sent: Friday, July 19, 2013 3:21 PM > To: Tirumaleswar Reddy (tireddy) > Cc: Behave WG; mohamed.boucadair@orange.com > Subject: Re: [BEHAVE] Fwd: I-D Action: draft-chen-behave-nat64-radius- > extension-00.txt >=20 > Hi Tiru, >=20 > Thanks for the comments. >=20 > 2013/7/19, Tirumaleswar Reddy (tireddy) : > > Hi Gang, > > > > Please see inline > > > >> -----Original Message----- > >> From: GangChen [mailto:phdgang@gmail.com] > >> Sent: Monday, July 15, 2013 8:12 AM > >> To: Tirumaleswar Reddy (tireddy) > >> Cc: Behave WG; mohamed.boucadair@orange.com > >> Subject: Re: [BEHAVE] Fwd: I-D Action: draft-chen-behave-nat64-radius- > >> extension-00.txt > >> > >> Hi Tiru, > >> > >> You are right. Please check the sentence in the draft "It's also > >> possible to extend Port Control Protocol (PCP) to support those > >> network information queries from external servers. ....." > >> > >> The radius-based proposal intended to fit into the environment, where > >> geo-location system is already deployed based on a radius > >> database[RFC5580]. Some benefits have been described related to this > >> context. > > > > Why is this problem specific to NAT64 ? (it looks like a problem with a= ny > > other flavor of NAT) >=20 > The problem is general to all the NAT-based deployments. > But NAT64 has the uniqueness, because the internal source is a IPv6 > address, which has a global meaning. The system doesn't have to > correlate other information to identify user. Thanks, that clarifies. If required updated the draft to make it more clear= . >=20 > > From the draft it looks like for every mapping create, Radius server ha= s to > > be informed which is unconditional PUSH model and could create a lot of > > network chatter. >=20 > No. If you take a look at Fig.1 Requested-Binding-Info message would > convey the conditions. Only the matched mappings should report to the > Radius server. It's a PULL model. Now I get it. It would be good if you could provide a full example just lik= e in [RFC5580]. >=20 > > In PCP draft-boucadair-pcp-nat-reveal-01 it's a PULL model > > where only for interesting flows PCP-controlled NAT device is requested= to > > provide the internal IP address. >=20 > I don't want to make much comparisons because it may be "don't have > to". Every case has their benefits and suitable cases. RFC6967 lists > multiple solutions to reveal the source. That gives several > possibilities for the deployment. As you can see, we are also using > different approaches to discover NAT64 prefix. I don't see the harm. > The document just intends to describe the unique needs. Ok. >=20 >=20 > >> 1) radius-based solution would be a in-band solution > > > > Can you please clarify why you call radius-based solution in-band ? >=20 > Some geo-location systems receive the information through radius > messages(as described in RFC5580). The proposed radius message could > be get along with same radius systems. Therefore, that is an in-band > solution. Got it. you may want to say the same point in the draft, which is a good ad= vantage of not requiring any interworking function. >=20 > > The example of X-Forwarded-For header provided in the draft is in-band = and > > any other method like Radius, PCP are out-of-band. >=20 > Yes. it's a different definition. >=20 > >> 2) fewer impacts to NAT64 performance because the process is > >> independent with NAT64 translation > > Even draft-boucadair-pcp-nat-reveal-01 should not impact the NAT64 > > performance. >=20 > Yes. We don't intent to say your solution impacts NAT64 performance. > This context is limited to radius vs application aware functions. Ok. >=20 > > =3D=3D=3D > > > > If you could provide more details of an example use case with topology = of > > the client, NAT64, Radius Server and third party entity which will quer= y the > > Radius server for the IPv6 address and how the learnt IPv6 address will= be > > used for some policy decision, it will help understanding of reviewers. >=20 > Good suggestions. I will add the additional descriptions Cheers, --Tiru. >=20 > Best Regards >=20 > Gang >=20 >=20 > > Cheers, > > > > --Tiru. > > > >> > >> BRs > >> > >> Gang > >> > >> 2013/7/12, Tirumaleswar Reddy (tireddy) : > >> > Hi Gang, > >> > > >> > The problems mentioned in the draft can also be solved using PCP QUE= RY > >> > opcode introduced in > >> > http://tools.ietf.org/html/draft-boucadair-pcp-nat-reveal-01 > >> > > >> > --Tiru. > >> > > >> >> -----Original Message----- > >> >> From: GangChen [mailto:phdgang@gmail.com] > >> >> Sent: Tuesday, July 09, 2013 11:54 AM > >> >> To: Behave WG > >> >> Subject: [BEHAVE] Fwd: I-D Action: > >> >> draft-chen-behave-nat64-radius-extension- > >> >> 00.txt > >> >> > >> >> wg, > >> >> > >> >> We just uploaded the draft-chen-behave-nat64-radius-extension-00 > >> >> The draft proposes new Radius attributes to convey IPv6 source > >> >> addresses when a NAT64 is deployed. > >> >> > >> >> Your comments/reviews are appreciated. > >> >> > >> >> Best Regards > >> >> > >> >> Gang > >> >> > >> >> ---------- Forwarded message ---------- > >> >> From: internet-drafts@ietf.org > >> >> Date: Mon, 08 Jul 2013 08:16:36 -0700 > >> >> Subject: I-D Action: draft-chen-behave-nat64-radius-extension-00.tx= t > >> >> To: i-d-announce@ietf.org > >> >> > >> >> > >> >> A New Internet-Draft is available from the on-line Internet-Drafts > >> >> directories. > >> >> > >> >> > >> >> Title : Radius Attributes for Stateful NAT64 > >> >> Author(s) : Gang Chen > >> >> David Binet > >> >> Filename : draft-chen-behave-nat64-radius-extension-00.txt > >> >> Pages : 10 > >> >> Date : 2013-07-08 > >> >> > >> >> Abstract: > >> >> This document proposes new radius attributes for stateful NAT64. > >> >> The > >> >> extensions are used to provide geo-location services with an exa= ct > >> >> IPv6 soruce address. The message flow to deliver the NAT64 bind= ing > >> >> information between radius clients and servers is also described= . > >> >> Therefore, accurate location could be traced out depending on th= e > >> >> radius method. > >> >> > >> >> > >> >> The IETF datatracker status page for this draft is: > >> >> https://datatracker.ietf.org/doc/draft-chen-behave-nat64-radius- > extension > >> >> > >> >> There's also a htmlized version available at: > >> >> http://tools.ietf.org/html/draft-chen-behave-nat64-radius-extension= -00 > >> >> > >> >> > >> >> Internet-Drafts are also available by anonymous FTP at: > >> >> ftp://ftp.ietf.org/internet-drafts/ > >> >> > >> >> _______________________________________________ > >> >> I-D-Announce mailing list > >> >> I-D-Announce@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/i-d-announce > >> >> Internet-Draft directories: http://www.ietf.org/shadow.html > >> >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >> > > >> > > > From tireddy@cisco.com Mon Jul 22 05:53:54 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25E2911E8101; Mon, 22 Jul 2013 05:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.448 X-Spam-Level: X-Spam-Status: No, score=-10.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dMvUaTygEjDb; Mon, 22 Jul 2013 05:53:49 -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 B372111E80D5; Mon, 22 Jul 2013 05:53:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16328; q=dns/txt; s=iport; t=1374497628; x=1375707228; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=DS4BgToDvmWpXeDOeTHhcHlWSodOgS93fVmyfGSnsDU=; b=H+tjn9r/Ug2g2qBKOOZOa492c8VD9XAEj7fGvSRmUFnpecTkxg9c09cX g92WGxlfmk/KkJ3qCWTzoYWhLB41KJGl4fxWAtxpHJlKNdgl61Y2+35Rm Z+74rjw7rKA6LxExaP7AaaekNw55+I70LJPx2L9gAoySPvsyECFhI76ET 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuMFAIoq7VGtJV2b/2dsb2JhbABagkJENVCDCqs2iTeIORd3FnSCJAEBAQQjCkEJAhACAQgOAwMBAQELHQMCAgIwFAkIAgQOBQgBiAcMphGRFY5egQcgEQYBBoJXM24DmQaQJIFZgTmBaCICHg X-IronPort-AV: E=Sophos;i="4.89,719,1367971200"; d="scan'208,217";a="234787165" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 22 Jul 2013 12:53:48 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r6MCrlRr011792 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Jul 2013 12:53:47 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Mon, 22 Jul 2013 07:53:47 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Justin Uberti Thread-Topic: [rtcweb] Fwd: New Version Notification for draft-uberti-behave-turn-rest-00.txt Thread-Index: AQHOgaXFxG8B2qhG1UKzVBv1DFSHsZlvKhOQ Date: Mon, 22 Jul 2013 12:53:47 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A14B9F74D@xmb-rcd-x10.cisco.com> References: <20130715214906.5314.83583.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.64.58] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A14B9F74Dxmbrcdx10ciscoc_" MIME-Version: 1.0 Cc: Behave WG , "rtcweb@ietf.org" Subject: Re: [BEHAVE] [rtcweb] Fwd: New Version Notification for draft-uberti-behave-turn-rest-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 12:53:54 -0000 --_000_913383AAA69FF945B8F946018B75898A14B9F74Dxmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSnVzdGluLA0KDQpZb3UgbWF5IGFsc28gd2FudCB0byBjb25zaWRlciB5b3VyIHVzaW5nIE9B dXRoIDIuMCBmcmFtZXdvcmsuIEZvciBleGFtcGxlIGNvbnNpZGVyIGRyYWZ0IChodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXYyLWh0dHAtbWFjLTA0I3NlY3Rpb24t Ni4xKSBXaGVyZSBXZWJTZXJ2ZXIgd291bGQgYWN0IGFzIEF1dGhvcml6YXRpb24gU2VydmVyIChB UyksIFRVUk4gU2VydmVyIGFzIFJlc291cmNlIFNlcnZlciAoUlMpIGFuZCBDbGllbnQgd2lsbCBi ZSB0aGUgV2ViUlRDIENsaWVudC4NCg0KVGhlIGFkdmFudGFnZSBvZiB1c2luZyBPQXV0aCBpcyB0 aGF0DQoNClsxXSBJZiBoYW5kbGUgdG9rZW4gaXMgY2hvc2VuLCBBUyBjYW4gcmV2b2tlIHRoZSBj cmVkZW50aWFscyBhZnRlciB0aGUgY2FsbCBpcyB0ZXJtaW5hdGVkLiBUaGlzIHdvdWxkIGVuc3Vy ZSB0aGF0IGV2ZW4gaWYgdGhlIHRlbXBvcmFyeSBjcmVkZW50aWFscyBhcmUgZXhwb3NlZCB0byBK YXZhU2NyaXB0LCB0aGVzZSBjcmVkZW50aWFscyBjYW4gYmUgb25seSB1c2VkIGZvciB0aGUgZHVy YXRpb24gb2YgdGhlIGNhbGwuIFRoaXMgd291bGQgcHJldmVudCBhbnkgYXR0YWNrcyBwb3NzaWJs ZSBvZiBzb21lb25lIGVsc2UgdXNpbmcgdGhlIHRlbXBvcmFyeSBjcmVkZW50aWFscyBldmVuIGFm dGVyIHRoZSBjYWxsIGlzIHRlcm1pbmF0ZWQuDQoNClsyXSBBUyBhbmQgUlMgbmVlZCB0byBub3Qg YmUgY28tbG9jYXRlZC4NCg0KWzNdIEFTIGFuZCBSUyBuZWVkIG5vdCB1c2Ugc3RhdGljIHNoYXJl ZCBzZWNyZXQ7IE9BdXRoIHByb3ZpZGVzIGZsZXhpYmlsaXR5IGZvciB0aGUgQVMgdG8gdXBkYXRl IHRoZSBSUyB3aXRoIHNlc3Npb24ga2V5cy4NCg0KWzRdIEkgYmVsaWV2ZSB0aGVyZSBhcmUgYWxy ZWFkeSBpbXBsZW1lbnRhdGlvbnMgYXZhaWxhYmxlIG9mIE9BdXRoLg0KDQpCZXN0IFJlZ2FyZHMs DQotLVRpcnUuDQpGcm9tOiBydGN3ZWItYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnJ0Y3dlYi1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSnVzdGluIFViZXJ0aQ0KU2VudDogVHVlc2Rh eSwgSnVseSAxNiwgMjAxMyAzOjIzIEFNDQpUbzogcnRjd2ViQGlldGYub3JnOyBiZWhhdmVAaWV0 Zi5vcmcNClN1YmplY3Q6IFtydGN3ZWJdIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv ciBkcmFmdC11YmVydGktYmVoYXZlLXR1cm4tcmVzdC0wMC50eHQNCg0KSSBoYXZlIGNoYW5nZWQg dGhlIFdHIGZvciB0aGlzIGRyYWZ0IGZyb20gUlRDV0VCIHRvIEJFSEFWRS4gTWFueSwgYnV0IG5v dCBhbGwgb2YgdGhlIGNvbW1lbnRzIEkgcmVjZWl2ZWQgb24gdGhlIFJUQ1dFQiBtYWlsaW5nIGxp c3QgaGF2ZSBiZWVuIGFkZHJlc3NlZC4NCg0KQkVIQVZFIGNoYWlycywgSSB3b3VsZCBsaWtlIDEw IG1pbnV0ZXMgb2YgYWdlbmRhIHRpbWUgdG8gZGlzY3VzcyB0aGlzIGRyYWZ0Lg0KLS0tLS0tLS0t LSBGb3J3YXJkZWQgbWVzc2FnZSAtLS0tLS0tLS0tDQpGcm9tOiA8aW50ZXJuZXQtZHJhZnRzQGll dGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+Pg0KRGF0ZTogTW9uLCBKdWwg MTUsIDIwMTMgYXQgNTo0OSBQTQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv ciBkcmFmdC11YmVydGktYmVoYXZlLXR1cm4tcmVzdC0wMC50eHQNClRvOiBKdXN0aW4gVWJlcnRp IDxqdXN0aW5AdWJlcnRpLm5hbWU8bWFpbHRvOmp1c3RpbkB1YmVydGkubmFtZT4+DQoNCg0KDQpB IG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtdWJlcnRpLWJlaGF2ZS10dXJuLXJlc3QtMDAudHh0 DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEp1c3RpbiBVYmVydGkgYW5kIHBv c3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6ICAgICAgICBkcmFmdC11 YmVydGktYmVoYXZlLXR1cm4tcmVzdA0KUmV2aXNpb246ICAgICAgICAwMA0KVGl0bGU6ICAgICAg ICAgICBBIFJFU1QgQVBJIEZvciBBY2Nlc3MgVG8gVFVSTiBTZXJ2aWNlcw0KQ3JlYXRpb24gZGF0 ZTogICAyMDEzLTA3LTE1DQpHcm91cDogICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0K TnVtYmVyIG9mIHBhZ2VzOiA4DQpVUkw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXViZXJ0aS1iZWhhdmUtdHVybi1yZXN0LTAwLnR4dA0KU3Rh dHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXViZXJ0 aS1iZWhhdmUtdHVybi1yZXN0DQpIdG1saXplZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LXViZXJ0aS1iZWhhdmUtdHVybi1yZXN0LTAwDQoNCg0KQWJzdHJhY3Q6DQog ICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIHByb3Bvc2VkIHN0YW5kYXJkIFJFU1QgQVBJIGZv ciBvYnRhaW5pbmcNCiAgIGFjY2VzcyB0byBUVVJOIHNlcnZpY2VzIHZpYSBlcGhlbWVyYWwgKGku ZS4gdGltZS1saW1pdGVkKQ0KICAgY3JlZGVudGlhbHMuICBUaGVzZSBjcmVkZW50aWFscyBhcmUg dmVuZGVkIGJ5IGEgd2ViIHNlcnZpY2Ugb3Zlcg0KICAgSFRUUCwgYW5kIHRoZW4gc3VwcGxpZWQg dG8gYW5kIGNoZWNrZWQgYnkgYSBUVVJOIHNlcnZlciB1c2luZyB0aGUNCiAgIHN0YW5kYXJkIFRV Uk4gcHJvdG9jb2wuICBUaGUgdXNhZ2Ugb2YgZXBoZW1lcmFsIGNyZWRlbnRpYWxzIGVuc3VyZXMN CiAgIHRoYXQgYWNjZXNzIHRvIHRoZSBUVVJOIHNlcnZlciBjYW4gYmUgY29udHJvbGxlZCBldmVu IGlmIHRoZQ0KICAgY3JlZGVudGlhbHMgY2FuIGJlIGRpc2NvdmVyZWQgYnkgdGhlIHVzZXIsIGFz IGlzIHRoZSBjYXNlIGluIFdlYlJUQw0KICAgd2hlcmUgVFVSTiBjcmVkZW50aWFscyBtdXN0IGJl IHNwZWNpZmllZCBpbiBKYXZhc2NyaXB0Lg0KDQoNCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0K DQoNCg== --_000_913383AAA69FF945B8F946018B75898A14B9F74Dxmbrcdx10ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl Pg0KPCEtLQ0KIC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCiBAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIg MTEgNiA0IDMgNSA0IDQgMiA0O30NCiAvKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KIHAuTXNvTm9y bWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAu MHB0O30NCkBwYWdlIFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBp biAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuU2VjdGlvbjENCgl7cGFnZTpTZWN0aW9uMTt9DQot LT4NCjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCiAgPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQogPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+SGkgSnVzdGluLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9y OiMxRjQ5N0QiPllvdSBtYXkgYWxzbyB3YW50IHRvIGNvbnNpZGVyIHlvdXIgdXNpbmcgT0F1dGgg Mi4wIGZyYW1ld29yay4gRm9yIGV4YW1wbGUgY29uc2lkZXIgZHJhZnQgKDxhIGhyZWY9Imh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtdjItaHR0cC1tYWMtMDQjc2Vj dGlvbi02LjEiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtdjIt aHR0cC1tYWMtMDQjc2VjdGlvbi02LjE8L2E+KQ0KIFdoZXJlIFdlYlNlcnZlciB3b3VsZCBhY3Qg YXMgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgKEFTKSwgVFVSTiBTZXJ2ZXIgYXMgUmVzb3VyY2UgU2Vy dmVyIChSUykgYW5kIENsaWVudCB3aWxsIGJlIHRoZSBXZWJSVEMgQ2xpZW50LjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OzsNCmNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5 N0QiPlRoZSBhZHZhbnRhZ2Ugb2YgdXNpbmcgT0F1dGggaXMgdGhhdA0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ow0KY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+ WzFdIElmIGhhbmRsZSB0b2tlbiBpcyBjaG9zZW4sIEFTIGNhbiByZXZva2UgdGhlIGNyZWRlbnRp YWxzIGFmdGVyIHRoZSBjYWxsIGlzIHRlcm1pbmF0ZWQuIFRoaXMgd291bGQgZW5zdXJlIHRoYXQg ZXZlbiBpZiB0aGUgdGVtcG9yYXJ5IGNyZWRlbnRpYWxzIGFyZSBleHBvc2VkDQogdG8gSmF2YVNj cmlwdCwgdGhlc2UgY3JlZGVudGlhbHMgY2FuIGJlIG9ubHkgdXNlZCBmb3IgdGhlIGR1cmF0aW9u IG9mIHRoZSBjYWxsLiBUaGlzIHdvdWxkIHByZXZlbnQgYW55IGF0dGFja3MgcG9zc2libGUgb2Yg c29tZW9uZSBlbHNlIHVzaW5nIHRoZSB0ZW1wb3JhcnkgY3JlZGVudGlhbHMgZXZlbiBhZnRlciB0 aGUgY2FsbCBpcyB0ZXJtaW5hdGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPlsyXSBBUyBhbmQgUlMgbmVlZCB0 byBub3QgYmUgY28tbG9jYXRlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj5bM10gQVMgYW5kIFJTIG5lZWQgbm90 IHVzZSBzdGF0aWMgc2hhcmVkIHNlY3JldDsgT0F1dGggcHJvdmlkZXMgZmxleGliaWxpdHkgZm9y IHRoZSBBUyB0byB1cGRhdGUgdGhlIFJTIHdpdGggc2Vzc2lvbiBrZXlzLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OzsNCmNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0Qi Pls0XSBJIGJlbGlldmUgdGhlcmUgYXJlIGFscmVhZHkgaW1wbGVtZW50YXRpb25zIGF2YWlsYWJs ZSBvZiBPQXV0aC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj5CZXN0IFJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0K Y29sb3I6IzFGNDk3RCI+LS1UaXJ1LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGlu IDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnIFtt YWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkp1c3Rp biBVYmVydGk8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgSnVseSAxNiwgMjAxMyAzOjIzIEFN PGJyPg0KPGI+VG86PC9iPiBydGN3ZWJAaWV0Zi5vcmc7IGJlaGF2ZUBpZXRmLm9yZzxicj4NCjxi PlN1YmplY3Q6PC9iPiBbcnRjd2ViXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3Ig ZHJhZnQtdWJlcnRpLWJlaGF2ZS10dXJuLXJlc3QtMDAudHh0PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaGF2ZSBjaGFuZ2VkIHRoZSBXRyBm b3IgdGhpcyBkcmFmdCBmcm9tIFJUQ1dFQiB0byBCRUhBVkUuIE1hbnksIGJ1dCBub3QgYWxsIG9m IHRoZSBjb21tZW50cyBJIHJlY2VpdmVkIG9uIHRoZSBSVENXRUIgbWFpbGluZyBsaXN0IGhhdmUg YmVlbiBhZGRyZXNzZWQuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5CRUhBVkUgY2hhaXJzLCBJIHdvdWxkIGxpa2UgMTAg bWludXRlcyBvZiBhZ2VuZGEgdGltZSB0byBkaXNjdXNzIHRoaXMgZHJhZnQuPG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij4tLS0tLS0tLS0tIEZvcndhcmRlZCBtZXNzYWdlIC0tLS0tLS0tLS08YnI+DQpGcm9tOiAm bHQ7PGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KRGF0ZTogTW9uLCBKdWwg MTUsIDIwMTMgYXQgNTo0OSBQTTxicj4NClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv biBmb3IgZHJhZnQtdWJlcnRpLWJlaGF2ZS10dXJuLXJlc3QtMDAudHh0PGJyPg0KVG86IEp1c3Rp biBVYmVydGkgJmx0OzxhIGhyZWY9Im1haWx0bzpqdXN0aW5AdWJlcnRpLm5hbWUiIHRhcmdldD0i X2JsYW5rIj5qdXN0aW5AdWJlcnRpLm5hbWU8L2E+Jmd0Ozxicj4NCjxicj4NCjxicj4NCjxicj4N CkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC11YmVydGktYmVoYXZlLXR1cm4tcmVzdC0wMC50 eHQ8YnI+DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEp1c3RpbiBVYmVydGkg YW5kIHBvc3RlZCB0byB0aGU8YnI+DQpJRVRGIHJlcG9zaXRvcnkuPGJyPg0KPGJyPg0KRmlsZW5h bWU6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2RyYWZ0LXViZXJ0aS1iZWhhdmUtdHVybi1y ZXN0PGJyPg0KUmV2aXNpb246ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzAwPGJyPg0KVGl0 bGU6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgQSBSRVNUIEFQSSBGb3IgQWNj ZXNzIFRvIFRVUk4gU2VydmljZXM8YnI+DQpDcmVhdGlvbiBkYXRlOiAmbmJzcDsgMjAxMy0wNy0x NTxicj4NCkdyb3VwOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEluZGl2aWR1 YWwgU3VibWlzc2lvbjxicj4NCk51bWJlciBvZiBwYWdlczogODxicj4NClVSTDogJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRm Lm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtdWJlcnRpLWJlaGF2ZS10dXJuLXJlc3QtMDAudHh0 IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9k cmFmdC11YmVydGktYmVoYXZlLXR1cm4tcmVzdC0wMC50eHQ8L2E+PGJyPg0KU3RhdHVzOiAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0iaHR0cDovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC11YmVydGktYmVoYXZlLXR1cm4tcmVzdCIgdGFyZ2V0PSJfYmxh bmsiPmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdWJlcnRpLWJlaGF2ZS10 dXJuLXJlc3Q8L2E+PGJyPg0KSHRtbGl6ZWQ6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxh IGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXViZXJ0aS1iZWhhdmUtdHVy bi1yZXN0LTAwIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtdWJlcnRpLWJlaGF2ZS10dXJuLXJlc3QtMDA8L2E+PGJyPg0KPGJyPg0KPGJyPg0KQWJzdHJh Y3Q6PGJyPg0KJm5ic3A7ICZuYnNwO1RoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgcHJvcG9zZWQg c3RhbmRhcmQgUkVTVCBBUEkgZm9yIG9idGFpbmluZzxicj4NCiZuYnNwOyAmbmJzcDthY2Nlc3Mg dG8gVFVSTiBzZXJ2aWNlcyB2aWEgZXBoZW1lcmFsIChpLmUuIHRpbWUtbGltaXRlZCk8YnI+DQom bmJzcDsgJm5ic3A7Y3JlZGVudGlhbHMuICZuYnNwO1RoZXNlIGNyZWRlbnRpYWxzIGFyZSB2ZW5k ZWQgYnkgYSB3ZWIgc2VydmljZSBvdmVyPGJyPg0KJm5ic3A7ICZuYnNwO0hUVFAsIGFuZCB0aGVu IHN1cHBsaWVkIHRvIGFuZCBjaGVja2VkIGJ5IGEgVFVSTiBzZXJ2ZXIgdXNpbmcgdGhlPGJyPg0K Jm5ic3A7ICZuYnNwO3N0YW5kYXJkIFRVUk4gcHJvdG9jb2wuICZuYnNwO1RoZSB1c2FnZSBvZiBl cGhlbWVyYWwgY3JlZGVudGlhbHMgZW5zdXJlczxicj4NCiZuYnNwOyAmbmJzcDt0aGF0IGFjY2Vz cyB0byB0aGUgVFVSTiBzZXJ2ZXIgY2FuIGJlIGNvbnRyb2xsZWQgZXZlbiBpZiB0aGU8YnI+DQom bmJzcDsgJm5ic3A7Y3JlZGVudGlhbHMgY2FuIGJlIGRpc2NvdmVyZWQgYnkgdGhlIHVzZXIsIGFz IGlzIHRoZSBjYXNlIGluIFdlYlJUQzxicj4NCiZuYnNwOyAmbmJzcDt3aGVyZSBUVVJOIGNyZWRl bnRpYWxzIG11c3QgYmUgc3BlY2lmaWVkIGluIEphdmFzY3JpcHQuPGJyPg0KPGJyPg0KPGJyPg0K PGJyPg0KPGJyPg0KVGhlIElFVEYgU2VjcmV0YXJpYXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_913383AAA69FF945B8F946018B75898A14B9F74Dxmbrcdx10ciscoc_-- From dwing@cisco.com Mon Jul 22 09:21:42 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FE8211E8118 for ; Mon, 22 Jul 2013 09:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.476 X-Spam-Level: X-Spam-Status: No, score=-110.476 tagged_above=-999 required=5 tests=[AWL=0.122, 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 9hA5SFelkQa0 for ; Mon, 22 Jul 2013 09:21:37 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 7FAC611E8123 for ; Mon, 22 Jul 2013 09:21:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9898; q=dns/txt; s=iport; t=1374510096; x=1375719696; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=TynC1eiO9tD3x591QIQPxhADyBjnRG1Y1fTRQC/jg/w=; b=f5wEidUunuxCG4sgAqzYSDAn9pg87hZlQUpdNYqpWUwgWfmJ77z3pydL yz0R8SwB9uruRGvVaoXrMjUTx72g+PVsim8Ey63Zqigu8HK7TaoYOSFty v862JRhBobUYbUQc0XY+FaDasT/i7PvJdr/pY5InBHEh6GDrBoKeBxf7o w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au0FAEhb7VGrRDoH/2dsb2JhbABbgkJENQGvEIk3iDmBFhZ0giQBAQEDAQEBAWsLBQsLEQMBAi8hBigIGQmHdQMJBQ2udQ2IXo0qglsRBwaDCm4DiSiKHYIvgWmBKYR6hgSFJoMyHA X-IronPort-AV: E=Sophos;i="4.89,720,1367971200"; d="scan'208,217";a="86785505" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 22 Jul 2013 16:21:19 +0000 Received: from [10.21.103.25] ([10.21.103.25]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r6MGLIQj025597; Mon, 22 Jul 2013 16:21:18 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_7B551CB9-395C-4152-9F0D-A756A7FF2B35" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dan Wing In-Reply-To: Date: Mon, 22 Jul 2013 09:21:18 -0700 Message-Id: <4E0C46AA-706D-4F12-9099-EBF996AC41BE@cisco.com> References: To: behave@ietf.org X-Mailer: Apple Mail (2.1508) Cc: Qiong Subject: Re: [BEHAVE] I-D Action: draft-sun-behave-v4tov6-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 16:21:42 -0000 --Apple-Mail=_7B551CB9-395C-4152-9F0D-A756A7FF2B35 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 9, 2013, at 7:17 AM, Qiong wrote: > Dear all, >=20 > We have submitted a new draft for IPv4 client to IPv6 server. It is = designed to cover the Scenario 2 in RFC6144. It can save the public IPv4 = addresses consumed by IPv6 side and does not have impact on existing = applications. >=20 > Your comments/reviews are appreciated. This maps private IPv4 addresses to an IPv6 address so solves RFC6144's = Scenario 4: "An IPv4 Network to the IPv6 Internet". I am interested in comments from the working group if Scenario 4 is a = problem on your networks, or anticipated to become a problem on your = networks. -d >=20 > Best wishes > Qiong >=20 >=20 > ---------- Forwarded message ---------- > From: internet-drafts@ietf.org > Date: Mon, 08 Jul 2013 08:16:36 -0700 > Subject: I-D Action: draft-sun-behave-v4tov6-00.txt > To: i-d-announce@ietf.org >=20 > A new version of I-D, draft-sun-behave-v4tov6-00.txt > has been successfully submitted by Chongfeng Xie and posted to the > IETF repository. > =20 > Filename: draft-sun-behave-v4tov6 > Revision: 00 > Title: The Approach for IPv4-only users to access IPv6-only Content > Creation date: 2013-07-08 > Group: Individual Submission > Number of pages: 13 > URL: = http://www.ietf.org/internet-drafts/draft-sun-behave-v4tov6-00.txt > Status: http://datatracker.ietf.org/doc/draft-sun-behave-v4tov6 > Htmlized: http://tools.ietf.org/html/draft-sun-behave-v4tov6-00 > =20 > =20 > Abstract: > Current approaches can not solve the scenario that the users from > IPv4 Internet to access IPv6-only content. When IPv6 content are > becoming more and more popular, it is important to ensure that = IPv6- > only content can be reachable from legacy IPv4-only clients via = some > IPv4-only network. This document proposes two approaches for IPv4- > only users to access IPv6-only content. It is designed to cover = the > Scenario 2 in [RFC6144]. > =20 > = =20 > =20 > =20 > The IETF Secretariat >=20 > --=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Qiong Sun > China Telecom Beijing Research Institute >=20 >=20 > Open source code: > lightweight 4over6: http://sourceforge.net/projects/laft6/ > PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave --Apple-Mail=_7B551CB9-395C-4152-9F0D-A756A7FF2B35 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On Jul 9, 2013, at 7:17 AM, Qiong <bingxuere@gmail.com> wrote:

Dear all,

We have submitted a new draft for IPv4 client to IPv6 server. It is designed to cover the Scenario 2 in RFC6144. It can save the public IPv4 addresses consumed by IPv6 side and does not have impact on existing applications.

Your comments/reviews are appreciated.

This maps private IPv4 addresses to an IPv6 address so solves RFC6144's Scenario 4: "An IPv4 Network to the IPv6 Internet".

I am interested in comments from the working group if Scenario 4 is a problem on your networks, or anticipated to become a problem on your networks.

-d



Best wishes
Qiong


---------- Forwarded message ----------
From: internet-drafts@ietf.org
Date: Mon, 08 Jul 2013 08:16:36 -0700
Subject: I-D Action: draft-sun-behave-v4tov6-00.txt
To: i-d-announce@ietf.org

A new version of I-D, draft-sun-behave-v4tov6-00.txt
has been successfully submitted by Chongfeng Xie and posted to the
IETF repository.
 
Filename:  draft-sun-behave-v4tov6
Revision:  00
Title:  The Approach for IPv4-only users to access IPv6-only Content
Creation date:  2013-07-08
Group:  Individual Submission
Number of pages: 13
 
 
Abstract:
   Current approaches can not solve the scenario that the users from
   IPv4 Internet to access IPv6-only content.  When IPv6 content are
   becoming more and more popular, it is important to ensure that IPv6-
   only content can be reachable from legacy IPv4-only clients via some
   IPv4-only network.  This document proposes two approaches for IPv4-
   only users to access IPv6-only content.  It is designed to cover the
   Scenario 2 in [RFC6144].
 
                                                                                  
 
 
The IETF Secretariat

--
==============================================
Qiong Sun
China Telecom Beijing Research Institute


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

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

--Apple-Mail=_7B551CB9-395C-4152-9F0D-A756A7FF2B35-- From adam@nostrum.com Mon Jul 22 13:16:37 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E66611E813F; Mon, 22 Jul 2013 13:16:37 -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, HTML_MESSAGE=0.001, SPF_PASS=-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 0xIj3z6JHUKN; Mon, 22 Jul 2013 13:16:36 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 699C911E8145; Mon, 22 Jul 2013 13:16:36 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r6MKGTvC065788 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 22 Jul 2013 15:16:30 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <51ED9318.6000003@nostrum.com> Date: Mon, 22 Jul 2013 15:16:24 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Rajmohan Banavi References: <20130715214906.5314.83583.idtracker@ietfa.amsl.com> <51E70106.8060100@goodadvice.pages.de> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070307020801070707040107" Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) Cc: behave , "rtcweb@ietf.org" , Justin Uberti Subject: Re: [BEHAVE] [rtcweb] Fwd: New Version Notification for draft-uberti-behave-turn-rest-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 20:16:37 -0000 This is a multi-part message in MIME format. --------------070307020801070707040107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 7/18/13 07:28, Rajmohan Banavi wrote: > Hi Justin, comments inline with additional comments at the end. > > Correct, but that is a significant advantage, especially when the > web and TURN servers are separate entities. > > > IMHO, the standard spec should not be based on any specific > implementation method. Now I agree that the TURN server validation > becomes easier using this method because it does not have to do some > sort of lookup. However, some another TURN server implementer can > achieve the same functionality by providing REST API but using > randomly generated pasword (rather than use HMAC) and using some sort > of lookup for TURN username when TURN ALLOCATE request is received. I think the value here -- the value in defining a common scheme for password generation -- is that I could get an off-the-shelf TURN server from arbitrary vendor A, and run an off-the-shelf credential server from abitrary vendor B, and it would all work together. What you propose requires collusion between the TURN server provider and the credential server provider, using a not-yet-defined (and, if I read your proposal, never-publicly-defined) protocol to share credential information via a back-channel. What Justin proposes gets us this inter-vendor interop cheaply and easily. What you're counterproposing forces people into a single-vendor (or, at least, partnered) solution, which kinda defeats the purpose of defining this in an SDO in the first place. /a --------------070307020801070707040107 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 7/18/13 07:28, Rajmohan Banavi wrote:
Hi  Justin, comments inline with additional comments at the end.

Correct, but that is a significant advantage, especially when the web and TURN servers are separate entities. 

IMHO, the standard spec should not be based on any specific implementation method. Now I agree that the TURN server validation becomes easier using this method because it does not have to do some sort of lookup. However, some another TURN server implementer can achieve the same functionality by providing REST API but using randomly generated pasword (rather than use HMAC) and using some sort of lookup for TURN username when TURN ALLOCATE request is received.

I think the value here -- the value in defining a common scheme for password generation -- is that I could get an off-the-shelf TURN server from arbitrary vendor A, and run an off-the-shelf credential server from abitrary vendor B, and it would all work together. What you propose requires collusion between the TURN server provider and the credential server provider, using a not-yet-defined (and, if I read your proposal, never-publicly-defined) protocol to share credential information via a back-channel.

What Justin proposes gets us this inter-vendor interop cheaply and easily. What you're counterproposing forces people into a single-vendor (or, at least, partnered) solution, which kinda defeats the purpose of defining this in an SDO in the first place.

/a
--------------070307020801070707040107-- From fippo@goodadvice.pages.de Mon Jul 22 13:47:08 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9744F11E814E; Mon, 22 Jul 2013 13:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.588 X-Spam-Level: X-Spam-Status: No, score=-1.588 tagged_above=-999 required=5 tests=[AWL=1.011, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uv1B3cAJhYYJ; Mon, 22 Jul 2013 13:47:02 -0700 (PDT) Received: from lo.psyced.org (lost.IN.psyced.org [188.40.42.221]) by ietfa.amsl.com (Postfix) with ESMTP id 4BBC821F9C12; Mon, 22 Jul 2013 13:47:01 -0700 (PDT) Received: from [192.168.2.100] (p54970320.dip0.t-ipconnect.de [84.151.3.32]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id r6MKkvug017375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Jul 2013 22:47:00 +0200 Message-ID: <51ED9A3C.4060307@goodadvice.pages.de> Date: Mon, 22 Jul 2013 22:46:52 +0200 From: Philipp Hancke User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Adam Roach References: <20130715214906.5314.83583.idtracker@ietfa.amsl.com> <51E70106.8060100@goodadvice.pages.de> <51ED9318.6000003@nostrum.com> In-Reply-To: <51ED9318.6000003@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtcweb@ietf.org" , mom040267@gmail.com, behave Subject: Re: [BEHAVE] [rtcweb] Fwd: New Version Notification for draft-uberti-behave-turn-rest-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 20:47:08 -0000 Am 22.07.2013 22:16, schrieb Adam Roach: > What Justin proposes gets us this inter-vendor interop cheaply and > easily. What you're counterproposing forces people into a single-vendor > (or, at least, partnered) solution, which kinda defeats the purpose of > defining this in an SDO in the first place. Right. What Justin proposed was originally located at https://code.google.com/p/webrtc/issues/detail?id=1197 I liked the plan, implemented it in restund and improved it a litle. It was discussed at https://groups.google.com/forum/#!topic/discuss-webrtc/nn8b6UboqRA/discussion and also implemented in rfc-5766-turn-server. Rough consensus and running code... From bingxuere@gmail.com Tue Jul 23 06:01:34 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E824811E80CC for ; Tue, 23 Jul 2013 06:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, 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 RE+jhFHJ6pR7 for ; Tue, 23 Jul 2013 06:01:34 -0700 (PDT) Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [IPv6:2607:f8b0:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 36EDF11E8120 for ; Tue, 23 Jul 2013 06:01:33 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id m17so4036488vca.3 for ; Tue, 23 Jul 2013 06:01:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=R8TcTCBFiUp+edfaeljY6Qq5YlPfrn0h2pSk2ecKgl8=; b=vZ+riLFHTgQJl6bcIkJhPPxQvYNySkTw1K+nfvmaSjcWFZfjvVSPAK4L6w5Y20hban APWadFxWHOA2qC2RhL3jUBKBKPsjBbw5/mNZ2yNMnKjtaIHhGgYPOq4VMnDHFD66bl6h wAHAJM+t68WiYcDO3y/Av4VpXyU36Ysuc/4/csEgRxq8QhLfPuv6HQ9NhivYrB8mO+g4 6rklHS5o8H2tGz1VKMtosrC9BabDHXRrG1C9SM7PFC3/Ub7XCRaKz+4m4fgHVRd41/GO W0fBtsoE6piYATbIc9bkEVx8EwLlmXl9XVekmDImBa7+c2Obz1qchkpER1glgJE0+7/4 lJEg== X-Received: by 10.220.249.67 with SMTP id mj3mr2558863vcb.23.1374584492612; Tue, 23 Jul 2013 06:01:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.210.202 with HTTP; Tue, 23 Jul 2013 06:00:52 -0700 (PDT) In-Reply-To: <4E0C46AA-706D-4F12-9099-EBF996AC41BE@cisco.com> References: <4E0C46AA-706D-4F12-9099-EBF996AC41BE@cisco.com> From: Qiong Date: Tue, 23 Jul 2013 21:00:52 +0800 Message-ID: To: Dan Wing Content-Type: multipart/alternative; boundary=089e013a15e66560b504e22d647b Cc: =?UTF-8?B?5L2V55Cq?= , "Cathy Zhou\(Qian\)" , sunqiong , "behave@ietf.org" , xiechf Subject: Re: [BEHAVE] I-D Action: draft-sun-behave-v4tov6-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 13:01:35 -0000 --089e013a15e66560b504e22d647b Content-Type: text/plain; charset=UTF-8 Dear Dan, Thanks a lot for your comments. Please see my reply inline. On Tue, Jul 23, 2013 at 12:21 AM, Dan Wing wrote: > > On Jul 9, 2013, at 7:17 AM, Qiong wrote: > > Dear all, > > We have submitted a new draft for IPv4 client to IPv6 server. It is > designed to cover the Scenario 2 in RFC6144. It can save the public IPv4 > addresses consumed by IPv6 side and does not have impact on existing > applications. > > Your comments/reviews are appreciated. > > > This maps private IPv4 addresses to an IPv6 address so solves RFC6144's > Scenario 4: "An IPv4 Network to the IPv6 Internet". > [Qiong] It can work for private IPv4 address. But in this draft, our primary design is to use public address as the destination address for IPv6 server, and achieve address sharing by using the address selection mechanism. > > I am interested in comments from the working group if Scenario 4 is a > problem on your networks, or anticipated to become a problem on your > networks. > [Qiong] In our company, we have both requirements to Scenario 2 and Scenario 4. Scenario 2 is mainly used when an enterprise/data center can offer IPv6-only service, but still needs connectivity from legacy IPv4 users. Scenario 4 is used when part of our network and services has been upgraded to IPv6, but we still have legacy IPv4 users need to access IPv6 content. In both scenarios, we need to achieve address sharing as IPv4 address has become a scarce resource. Thanks a lot! Best wishes Qiong > > -d > > > > Best wishes > Qiong > > > ---------- Forwarded message ---------- > From: internet-drafts@ietf.org > Date: Mon, 08 Jul 2013 08:16:36 -0700 > Subject: I-D Action: draft-sun-behave-v4tov6-00.txt > To: i-d-announce@ietf.org > > A new version of I-D, draft-sun-behave-v4tov6-00.txt > has been successfully submitted by Chongfeng Xie and posted to the > IETF repository. > > Filename: draft-sun-behave-v4tov6 > Revision: 00 > Title: The Approach for IPv4-only users to access IPv6-only Content > Creation date: 2013-07-08 > Group: Individual Submission > Number of pages: 13 > URL: http://www.ietf.org/internet-drafts/draft-sun-behave-v4tov6-00.txt > Status: http://datatracker.ietf.org/doc/draft-sun-behave-v4tov6 > Htmlized: http://tools.ietf.org/html/draft-sun-behave-v4tov6-00 > > > Abstract: > Current approaches can not solve the scenario that the users from > IPv4 Internet to access IPv6-only content. When IPv6 content are > becoming more and more popular, it is important to ensure that IPv6- > only content can be reachable from legacy IPv4-only clients via some > IPv4-only network. This document proposes two approaches for IPv4- > only users to access IPv6-only content. It is designed to cover the > Scenario 2 in [RFC6144]. > > > > > > The IETF Secretariat > > -- > ============================================== > Qiong Sun > China Telecom Beijing Research Institute > > > Open source code: > lightweight 4over6: *http://sourceforge.net/projects/laft6/* > PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * > =============================================== > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > > -- ============================================== Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/* PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * =============================================== --089e013a15e66560b504e22d647b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Dan,

Thanks a lot for your c= omments. Please see my reply inline.

On Tue, Jul 23, 2013 at 12:21 AM, Dan Wing <dwi= ng@cisco.com> wrote:

On Jul 9, 2013, at 7:17 AM, Qiong <bingxuere@gmail.com> wrote:

Dear all,

We = have submitted a new draft for IPv4 client to IPv6 server. It is designed t= o cover the Scenario=C2=A02= =C2=A0in RFC6144. It can save the public IPv4 addresses consumed by IPv6 si= de and does not have impact on existing applications.

Your comments/reviews are appreciated.

This maps private IPv4 addresses to an IPv6 address so solves RFC6144&= #39;s Scenario 4: "An IPv4 Network to th= e IPv6 Internet".
[Qio= ng] It can work for private IPv4 address. But in this draft, our primary de= sign is to use public address as=C2=A0the destination address for IPv6 serv= er, and achieve address sharing by using the address selection mechanism. = =C2=A0

I am interested in comments from the working group if Scenario 4 is a probl= em on your networks, or anticipated to become a problem on your networks.
[Qiong] In our company, we have bot= h requirements to Scenario 2 and Scenario 4. Scenario 2 is mainly used when= an enterprise/data center can offer IPv6-only service, but still needs con= nectivity from legacy IPv4 users. Scenario 4 is used when part of our netwo= rk and services has been upgraded to IPv6, but we still have legacy IPv4 us= ers need to access IPv6 content. In both scenarios, we need to achieve addr= ess sharing as IPv4 address has become a scarce resource. =C2=A0

Thanks a lot!

Best wishes
Qiong =C2=A0

-d
<= br>


Best wishes
Qiong


---------- Forwarded message ----------
From:=C2=A0internet-drafts@ietf.org Date: Mon, 08 J= ul 2013 08:16:36 -0700
Sub= ject: I-D Action:=C2=A0draft-sun-be= have-v4tov6-00.txt
To:=C2=A0i-d-announce@ietf.org

A=C2=A0new=C2=A0version=C2=A0of=C2=A0I-D,=C2=A0dr= aft-sun-behave-v4tov6-00.txt
has=C2=A0been=C2=A0successfully=C2=A0submitted=C2=A0by=C2=A0Chongfeng= =C2=A0Xie=C2=A0and=C2=A0posted=C2=A0to=C2=A0the
IETF=C2=A0repository.
=C2=A0
Filename: =C2=A0draft-sun-behave-v4tov6
Revision: =C2=A000
Title: =C2=A0The=C2=A0Approach=C2=A0for=C2=A0IPv4-only=C2=A0users=C2= =A0to=C2=A0access=C2=A0IPv6-only=C2=A0Content
Creation=C2=A0date: =C2=A02013-07-08
Group: =C2=A0Individual=C2=A0Submission
Number=C2=A0of=C2=A0pages:=C2=A013
=C2=A0
=C2=A0
Abstract:
=C2=A0=C2=A0=C2=A0Current=C2=A0approaches=C2=A0can=C2=A0not=C2=A0solve= =C2=A0the=C2=A0scenario=C2=A0that=C2=A0the=C2=A0users=C2=A0from
=C2=A0=C2=A0=C2=A0IPv4=C2=A0Internet=C2=A0to=C2=A0access=C2=A0IPv6-onl= y=C2=A0content.=C2=A0=C2=A0When=C2=A0IPv6=C2=A0content=C2=A0are
=C2=A0=C2=A0=C2=A0becoming=C2=A0more=C2=A0and=C2=A0more=C2=A0popular,= =C2=A0it=C2=A0is=C2=A0important=C2=A0to=C2=A0ensure=C2=A0that=C2=A0IPv6-
=C2=A0=C2=A0=C2=A0only=C2=A0content=C2=A0can=C2=A0be=C2=A0reachable=C2= =A0from=C2=A0legacy=C2=A0IPv4-only=C2=A0clients=C2=A0via=C2=A0some
=C2=A0=C2=A0=C2=A0IPv4-only=C2=A0network.=C2=A0=C2=A0This=C2=A0documen= t=C2=A0proposes=C2=A0two=C2=A0approaches=C2=A0for=C2=A0IPv4-
=C2=A0=C2=A0=C2=A0only=C2=A0users=C2=A0to=C2=A0access=C2=A0IPv6-only= =C2=A0content.=C2=A0=C2=A0It=C2=A0is=C2=A0designed=C2=A0to=C2=A0cover=C2=A0= the
=C2=A0=C2=A0=C2=A0Scenario=C2=A02=C2=A0in=C2=A0[RFC6144].
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
=C2=A0
=C2=A0
The=C2=A0IETF=C2=A0Secretariat

--
=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Qiong Sun
China T= elecom Beijing Research Institute


Open source code:
lightweig= ht 4over6: http://sourceforge.net/projects/laft6/
PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
_______________________________________________
Behave mailing list
<= a href=3D"mailto:Behave@ietf.org" target=3D"_blank">Behave@ietf.org
= = https://www.ietf.org/mailman/listinfo/behave



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


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

--089e013a15e66560b504e22d647b-- From mom040267@gmail.com Mon Jul 22 14:37:42 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F33611E80D3; Mon, 22 Jul 2013 14:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 kjvMciVvfu5j; Mon, 22 Jul 2013 14:37:41 -0700 (PDT) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB5211E80C5; Mon, 22 Jul 2013 14:37:41 -0700 (PDT) Received: by mail-pa0-f52.google.com with SMTP id kq13so2001418pab.25 for ; Mon, 22 Jul 2013 14:37:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jHtorqB2C5+52J6XaCzxXZQmK3XA4ITi9oNjG5oq4VU=; b=rPcdVr0zFWJmm5/Fu1AA3zZSIKwlv9pwgBbbBDV3kz201DkZiycgP+gx3uUNEo2CeN GjA3aeOQhgsT3or0gINV6Brjg5bwEwGY2B4uWXtFyb+v49U24YGwp9yFSW8WesEsa+yK pbTYU/b6AXb7wLy6wfa/sN+rmStuFK26j0MLsWddIsQdgOlt3CjhSLKnNBMc1HVA7VhR lvBTP040dB4GaSORUoURKck6wgiNolpKtZtXgrRrn+U9BelSL9Ayw/5BjUcza+Se2R/4 yRkhkULP5Uixsb19Wj/e1RjrjJEDsBTjMmxVvwYY/DMDA308ufoNSVx77fkHZxObz8Of UiAg== MIME-Version: 1.0 X-Received: by 10.68.243.65 with SMTP id ww1mr33587316pbc.62.1374529061034; Mon, 22 Jul 2013 14:37:41 -0700 (PDT) Received: by 10.68.92.132 with HTTP; Mon, 22 Jul 2013 14:37:40 -0700 (PDT) In-Reply-To: <51ED9A3C.4060307@goodadvice.pages.de> References: <20130715214906.5314.83583.idtracker@ietfa.amsl.com> <51E70106.8060100@goodadvice.pages.de> <51ED9318.6000003@nostrum.com> <51ED9A3C.4060307@goodadvice.pages.de> Date: Mon, 22 Jul 2013 14:37:40 -0700 Message-ID: From: Oleg Moskalenko To: Philipp Hancke Content-Type: multipart/alternative; boundary=047d7b2e13156aa20804e2207cea X-Mailman-Approved-At: Tue, 23 Jul 2013 08:09:07 -0700 Cc: behave , "rtcweb@ietf.org" Subject: Re: [BEHAVE] [rtcweb] Fwd: New Version Notification for draft-uberti-behave-turn-rest-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 21:39:26 -0000 --047d7b2e13156aa20804e2207cea Content-Type: text/plain; charset=ISO-8859-1 The overall proposal by Justin: http://tools.ietf.org/html/draft-uberti-rtcweb-turn-rest-00 has been implemented in our rfc5766-turn-server for months, and I see nothing proprietary in the proposal. I liked the proposal from the beginning. Its been discussed and its been quite handy for the users - I hear stories of success from the users. I believe that Philipp shares the same view. One especially good thing about the proposal is that is does not contradict by any means to the RFC 5766. It just specifies the way how the passwords are stored/generated - and the RFC 5766 does not say anything about that matter. It means that Justin's proposal is 100% compatible with RFC 5766. Thanks Oleg http://code.google.com/p/rfc5766-turn-server/ On Mon, Jul 22, 2013 at 1:46 PM, Philipp Hancke wrote: > Am 22.07.2013 22:16, schrieb Adam Roach: > >> What Justin proposes gets us this inter-vendor interop cheaply and >> easily. What you're counterproposing forces people into a single-vendor >> (or, at least, partnered) solution, which kinda defeats the purpose of >> defining this in an SDO in the first place. >> > > Right. What Justin proposed was originally located at > https://code.google.com/p/**webrtc/issues/detail?id=1197 > I liked the plan, implemented it in restund and improved it a litle. It > was discussed at https://groups.google.com/**forum/#!topic/discuss-webrtc/ > **nn8b6UboqRA/discussionand also implemented in rfc-5766-turn-server. > > Rough consensus and running code... > --047d7b2e13156aa20804e2207cea Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
has been= implemented in our rfc5766-turn-server for months, and I see nothing propr= ietary in the proposal. I liked the proposal from the beginning. Its been d= iscussed and its been quite handy for the users - I hear stories of success= from the users.=A0 I believe that Philipp shares the same view.

One especially good thing about the proposal is that is does= not contradict by any means to the RFC 5766. It just specifies the way how= the passwords are stored/generated - and the RFC 5766 does not say anythin= g about that matter. It means that Justin's proposal is 100% compatible= with RFC 5766.

Thanks
Oleg
http://code.google.com/p/rfc5766-turn-server/
=



On Mon, Jul 22, 2013 at 1:46 PM, Philipp Hancke <fippo@goodadvice= .pages.de> wrote:
Am 22.07.2013 22:16, schrieb Adam Roach:
What Justin proposes gets us this inter-vendor interop cheaply and
easily. What you're counterproposing forces people into a single-vendor=
(or, at least, partnered) solution, which kinda defeats the purpose of
defining this in an SDO in the first place.

Right. What Justin proposed was originally located at
https://code.google.com/p/webrtc/issues/detail?id=3D1197=
I liked the plan, implemented it in restund and improved it a litle. It was= discussed at https://groups.google.com/forum/#!topic/discuss-webrtc/nn8b6UboqRA/discussion and als= o implemented in rfc-5766-turn-server.

Rough consensus and running code...

--047d7b2e13156aa20804e2207cea-- From juberti@google.com Tue Jul 23 13:50:30 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B345F11E8141 for ; Tue, 23 Jul 2013 13:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 JfmQ657UWw2y for ; Tue, 23 Jul 2013 13:50:29 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id C8E0711E810C for ; Tue, 23 Jul 2013 13:50:27 -0700 (PDT) Received: by mail-ob0-f169.google.com with SMTP id up14so11395529obb.28 for ; Tue, 23 Jul 2013 13:50:27 -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; bh=1WzahDGv5zenHpXjNXipRrGEVMAhrUSugYqiDAvm0lU=; b=HuNq4+SMxc5MuyfFOEthUtF01iBYtFe/1Wn9o/dgdEqtnHiddgytQxIyvP+REyQwhX l9WEZQcI5qsbr+fjFnKTYJNwyKr7sM+/s1bq4DISPP+UhnJjWfyrwJT9hwK6BbuCUa0F dwxu/Z3ThdRnubs5l4TGznZjc7Oq9dJUcA+BtusAlSt2yclFuLIFgbG1onY3IYLRfCS7 YmJg+vHKDgM5wYT9uIaX4Xe0sxoSuBlzlaO6JAN2qzXLUPrZAro4qFYWICOXv5C7TSsX MrZ1YUy8nwh4HCa6L7c0pnwRIkUDPcuJ2a8hmuN6BoqAuLdSxqcXYapVcGXbImNhkkEV KXWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=1WzahDGv5zenHpXjNXipRrGEVMAhrUSugYqiDAvm0lU=; b=MciLsjF1jn1jNFCA21kgNICua0StOF5trMvVK5liG1vmHX6+1h9UUspoa61mMY2UDd zyfBCFgT87u3qa8PhOlc/Pi/hGFExMQ+mSIYWGxh6idpRvyqY1H1f0QYeuOnkWUFVw9h xUzXNPeiOSnabeGKK4Kh0C4LxkaJBewoch1buW9SLpAiMuuKMXSI9/QGNl9sz1Y35bYW 7SmaT51umRYvZy7L0UWf5b0LZX530r7gH5WnDn3d4ZWZCiH3G5U4IQtgAPP5ruX4YHYE Nv0ttzDN8GWtwjgtC8XwdN4aPP5jLAbcGAXB02yWJ3qZj+09DyaWwgdMlSPmvBo8uNh5 FAnA== X-Received: by 10.50.134.72 with SMTP id pi8mr63574igb.7.1374612627197; Tue, 23 Jul 2013 13:50:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.97.132 with HTTP; Tue, 23 Jul 2013 13:45:12 -0700 (PDT) In-Reply-To: References: <20130715214906.5314.83583.idtracker@ietfa.amsl.com> <51E70106.8060100@goodadvice.pages.de> <51ED9318.6000003@nostrum.com> <51ED9A3C.4060307@goodadvice.pages.de> From: Justin Uberti Date: Tue, 23 Jul 2013 16:45:12 -0400 Message-ID: To: Oleg Moskalenko Content-Type: multipart/alternative; boundary=047d7b2e429a59343f04e233f183 X-Gm-Message-State: ALoCoQn5Y0yFRCgrde47ICYG0IDpo0gqTw1B1OUuXLOXlIM6blsaqIvqee618837s/oOpF1mA7S2ZpJJ2yM2Gsu/J0ZTnN9sLjyjSi8alOKrhZr7n+YWkB2/7JiiExz14ns4jwHj/pOo64U6YFP0EUXwSewyBkIbsNKEl+xosb20DXsSEMrBJ8Kyz1TSFhR5NblfuNU7RZ8H Cc: "rtcweb@ietf.org" , Philipp Hancke , behave Subject: Re: [BEHAVE] [rtcweb] Fwd: New Version Notification for draft-uberti-behave-turn-rest-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 20:50:30 -0000 --047d7b2e429a59343f04e233f183 Content-Type: text/plain; charset=UTF-8 So there are two parts to the proposal - the HTTP request for the credentials and interactions with WebRTC, and the stateless implementation that avoids the need for communication between web and TURN servers. And it is true that other implementations besides the suggested stateless one are possible, e.g. OAuth2. Would you prefer that I address the protocol and implementation parts separately in the document, and mention that other implementations with the same HTTP protocol are possible? RFC 5766 does something similar, where it defines the TURN protocol, but in Section 6.2 talks about how a "stateless stack" implementation can be used to simplify the processing on the TURN server. On Mon, Jul 22, 2013 at 5:37 PM, Oleg Moskalenko wrote: > The overall proposal by Justin: > > http://tools.ietf.org/html/draft-uberti-rtcweb-turn-rest-00 > > has been implemented in our rfc5766-turn-server for months, and I see > nothing proprietary in the proposal. I liked the proposal from the > beginning. Its been discussed and its been quite handy for the users - I > hear stories of success from the users. I believe that Philipp shares the > same view. > > One especially good thing about the proposal is that is does not > contradict by any means to the RFC 5766. It just specifies the way how the > passwords are stored/generated - and the RFC 5766 does not say anything > about that matter. It means that Justin's proposal is 100% compatible with > RFC 5766. > > Thanks > Oleg > http://code.google.com/p/rfc5766-turn-server/ > > > > > On Mon, Jul 22, 2013 at 1:46 PM, Philipp Hancke > wrote: > >> Am 22.07.2013 22:16, schrieb Adam Roach: >> >>> What Justin proposes gets us this inter-vendor interop cheaply and >>> easily. What you're counterproposing forces people into a single-vendor >>> (or, at least, partnered) solution, which kinda defeats the purpose of >>> defining this in an SDO in the first place. >>> >> >> Right. What Justin proposed was originally located at >> https://code.google.com/p/**webrtc/issues/detail?id=1197 >> I liked the plan, implemented it in restund and improved it a litle. It >> was discussed at https://groups.google.com/** >> forum/#!topic/discuss-webrtc/**nn8b6UboqRA/discussionand also implemented in rfc-5766-turn-server. >> >> Rough consensus and running code... >> > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > --047d7b2e429a59343f04e233f183 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
So there are two parts to the proposal - the HTTP request = for the credentials and interactions with WebRTC, and the stateless impleme= ntation that avoids the need for communication between web and TURN servers= . And it is true that other implementations besides the suggested stateless= one are possible, e.g. OAuth2.

Would you prefer that I address the protocol and implem= entation parts separately in the document, and mention that other implement= ations with the same HTTP protocol are possible? RFC 5766 does something si= milar, where it defines the TURN protocol, but in Section 6.2 talks about h= ow a "stateless stack" implementation can be used to simplify the= processing on the TURN server.


On Mon,= Jul 22, 2013 at 5:37 PM, Oleg Moskalenko <mom040267@gmail.com> wrote:
has been implemented in our rfc5766-turn-server for months, and I= see nothing proprietary in the proposal. I liked the proposal from the beg= inning. Its been discussed and its been quite handy for the users - I hear = stories of success from the users.=C2=A0 I believe that Philipp shares the = same view.

One especially good thing about the proposal is that is does= not contradict by any means to the RFC 5766. It just specifies the way how= the passwords are stored/generated - and the RFC 5766 does not say anythin= g about that matter. It means that Justin's proposal is 100% compatible= with RFC 5766.

Thanks
Oleg
http://code.google.com/p/rfc5766-tu= rn-server/




On Mon, Jul 22, 2013 at 1:46 PM, Philipp= Hancke <fippo@goodadvice.pages.de> wrote:
Am 22.07.2013 22:16, schrieb Adam Roach:
What Justin proposes gets us this inter-vendor interop cheaply and
easily. What you're counterproposing forces people into a single-vendor=
(or, at least, partnered) solution, which kinda defeats the purpose of
defining this in an SDO in the first place.

Right. What Justin proposed was originally located at
https://code.google.com/p/webrtc/issues/detail?id=3D1197=
I liked the plan, implemented it in restund and improved it a litle. It was= discussed at https://groups.google.com/forum/#!topic/discuss-webrtc/nn8b6UboqRA/discussion and als= o implemented in rfc-5766-turn-server.

Rough consensus and running code...


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


--047d7b2e429a59343f04e233f183-- From liushucheng@huawei.com Tue Jul 23 20:56:29 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0C3111E8289 for ; Tue, 23 Jul 2013 20:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RMkXdygbPEvg for ; Tue, 23 Jul 2013 20:56:25 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id AAA0F11E8271 for ; Tue, 23 Jul 2013 20:56:24 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATS63122; Wed, 24 Jul 2013 03:56:23 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 24 Jul 2013 04:55:23 +0100 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 24 Jul 2013 04:56:08 +0100 Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.53]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.01.0323.007; Wed, 24 Jul 2013 11:56:05 +0800 From: "Will Liu (Shucheng)" To: "behave@ietf.org" Thread-Topic: [BEHAVE] I-D Action: draft-sun-behave-v4tov6-00.txt Thread-Index: AQHOhvebynQwcSDRaUiHQ3S4Ao1W15lzNIKw Date: Wed, 24 Jul 2013 03:56:04 +0000 Message-ID: References: <4E0C46AA-706D-4F12-9099-EBF996AC41BE@cisco.com> In-Reply-To: <4E0C46AA-706D-4F12-9099-EBF996AC41BE@cisco.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.78.79] Content-Type: multipart/alternative; boundary="_000_C9B5F12337F6F841B35C404CF0554ACB4B9DCD53szxeml546mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Qiong , Dan Wing Subject: Re: [BEHAVE] I-D Action: draft-sun-behave-v4tov6-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 03:56:29 -0000 --_000_C9B5F12337F6F841B35C404CF0554ACB4B9DCD53szxeml546mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Folks, >From the discussion with some of our customers, scenario 4 may be a real pr= oblem in their networks, especially when the operators have deployed IPv6 n= etwork or part of the contents have supported IPv6/IPv6-only. In this case,= the operators have to solve their own problems. In addition, scenario 2 me= ntioned in the document may be a problem when the Internet Content Provider= supports IPv6-only, but still provides connection for IPv4 hosts. The IPv4= address has been a scarce resource, some ways to reduce the IPv4 address c= onsumption may be needed. My two cents. Regards, Will From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of= Dan Wing Sent: Tuesday, July 23, 2013 12:21 AM To: behave@ietf.org Cc: Qiong Subject: Re: [BEHAVE] I-D Action: draft-sun-behave-v4tov6-00.txt On Jul 9, 2013, at 7:17 AM, Qiong > wrote: Dear all, We have submitted a new draft for IPv4 client to IPv6 server. It is designe= d to cover the Scenario 2 in RFC6144. It can save the public IPv4 addresses= consumed by IPv6 side and does not have impact on existing applications. Your comments/reviews are appreciated. This maps private IPv4 addresses to an IPv6 address so solves RFC6144's Sce= nario 4: "An IPv4 Network to the IPv6 Internet". I am interested in comments from the working group if Scenario 4 is a probl= em on your networks, or anticipated to become a problem on your networks. -d Best wishes Qiong ---------- Forwarded message ---------- From: internet-drafts@ietf.org Date: Mon, 08 Jul 2013 08:16:36 -0700 Subject: I-D Action: draft-sun-behave-v4tov6-00.txt To: i-d-announce@ietf.org A new version of I-D, draft-sun-behave-v4tov6-00.txt has been successfully submitted by Chongfeng Xie and posted to the IETF repository. Filename: draft-sun-behave-v4tov6 Revision: 00 Title: The Approach for IPv4-only users to access IPv6-only Content Creation date: 2013-07-08 Group: Individual Submission Number of pages: 13 URL: http://www.ietf.org/internet-drafts/draft-sun-behave-v4tov6-00.txt Status: http://datatracker.ietf.org/doc/draft-sun-behave-v4tov6 Htmlized: http://tools.ietf.org/html/draft-sun-behave-v4tov6-00 Abstract: Current approaches can not solve the scenario that the users from IPv4 Internet to access IPv6-only content. When IPv6 content are becoming more and more popular, it is important to ensure that IPv6- only content can be reachable from legacy IPv4-only clients via some IPv4-only network. This document proposes two approaches for IPv4- only users to access IPv6-only content. It is designed to cover the Scenario 2 in [RFC6144]. The IETF Secretariat -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Qiong Sun China Telecom Beijing Research Institute Open source code: lightweight 4over6: http://sourceforge.net/projects/laft6/ PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave --_000_C9B5F12337F6F841B35C404CF0554ACB4B9DCD53szxeml546mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Folks,<= /p>

 

From the discussion with som= e of our customers, scenario 4 may be a real problem in their networks, esp= ecially when the operators have deployed IPv6 network or part of the conten= ts have supported IPv6/IPv6-only. In this case, the operators have to solve their own problems. In addition, sc= enario 2 mentioned in the document may be a problem when the Internet Conte= nt Provider supports IPv6-only, but still provides connection for IPv4 host= s. The IPv4 address has been a scarce resource, some ways to reduce the IPv4 address consumption may be needed.<= o:p>

 

My two cents.

 

Rega= rds,

Will=

 = ;

From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.o= rg] On Behalf Of Dan Wing
Sent: Tuesday, July 23, 2013 12:21 AM
To: behave@ietf.org
Cc: Qiong
Subject: Re: [BEHAVE] I-D Action: draft-sun-behave-v4tov6-00.txt

 

 

On Jul 9, 2013, at 7:17 AM, Qio= ng <bingxuere@gmail.com> w= rote:



Dear all,

 

We have submitted a new dra= ft for IPv4 client to IPv6 server. It is designed to cover the Scenario 2 in RFC6144. It can save the public IPv4 addresses consumed by IPv6 side and d= oes not have impact on existing applications.

 

Your comments/reviews are a= ppreciated.

 

This maps private IPv4 addresse= s to an IPv6 address so solves RFC6144's Scenario 4: "An IPv4 Network = to the IPv6 Internet".

 

I am interested in comments fro= m the working group if Scenario 4 is a problem on your networks, or anticip= ated to become a problem on your networks.

 

-d

 



 

Best wishes

Qiong

 

 

---------- Forwarded messag= e ----------
From: internet-drafts@ietf.org
Date: Mon, 08 Jul 2013 08:16:36 -0700
Subject: I-D Action: draft-sun-behave-v4tov6-00.txt
To: i-d-announce@ietf.org

 

A new version of=  I-D, draft-sun-behave-v4tov6-00.txt

has been successfully=  submitted by Chongfeng Xie and posted t= o the

IETF repository.

 

Filename:  draft-sun-behav= e-v4tov6

Revision:  00

Title:  The Approach&= nbsp;for IPv4-only users to access IPv6-only = Content

Creation date:  2013-= 07-08

Group:  Individual Su= bmission

Number of pages: = ;13

 

 

Abstract:

   Current = approaches can not solve the scenario that&nb= sp;the users from

   IPv4 Int= ernet to access IPv6-only content.  When = ;IPv6 content are

   becoming = ;more and more popular, it is important = to ensure that IPv6-

   only con= tent can be reachable from legacy IPv4-only&n= bsp;clients via some

   IPv4-only&nbs= p;network.  This document proposes two approa= ches for IPv4-

   only use= rs to access IPv6-only content.  It is&n= bsp;designed to cover the

   Scenario = ;2 in [RFC6144].

 

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

 

 

The IETF Secretariat<= o:p>

 

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


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

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

 

--_000_C9B5F12337F6F841B35C404CF0554ACB4B9DCD53szxeml546mbxchi_-- From rajmohanbanavi@gmail.com Tue Jul 23 23:54:37 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C71B11E81FF; Tue, 23 Jul 2013 23:54:37 -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, HTML_MESSAGE=0.001, 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 5v4Ee7YqYGTW; Tue, 23 Jul 2013 23:54:36 -0700 (PDT) Received: from mail-oa0-x22d.google.com (mail-oa0-x22d.google.com [IPv6:2607:f8b0:4003:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 3028611E80E3; Tue, 23 Jul 2013 23:54:36 -0700 (PDT) Received: by mail-oa0-f45.google.com with SMTP id j1so76597oag.32 for ; Tue, 23 Jul 2013 23:54:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yeAOOUID4SqBHOremPsOvPkkv9C6njiYcfA6HHmeWKk=; b=eC98Q+FKhnP2CLoP1XzDrw3Q1cygqnHgud/kxolLt0KYOt4UWduk7t3qcFI2dk/LoK 0wwqp4b7QfXmKBjgQ3Vi80HnOWkP92y2Cxkf958GfHhsr9gADETp3jREozujhOCSjqn0 93TVszfFTeI23RCEKDOMP8QTTD2D6DkeyRxxZTmlMe9fb/wck02bUVmrG7JyQ/eaGnGQ CgWgc6cLhfDwlWgleAbmIXe2nPjEn8Dsi4lbY9Y5pJ2nex+c+nl+Hd9NxQeEHMHm2j0c iLOhtgHATkQhlXuly1dVJ8WEvw1e/jGZfNPfDvTiwzBr0jHBi1J8WcxF/Rp8HvXWMg5c r8Gw== MIME-Version: 1.0 X-Received: by 10.50.1.78 with SMTP id 14mr244058igk.60.1374648874510; Tue, 23 Jul 2013 23:54:34 -0700 (PDT) Received: by 10.42.96.5 with HTTP; Tue, 23 Jul 2013 23:54:34 -0700 (PDT) In-Reply-To: References: <20130715214906.5314.83583.idtracker@ietfa.amsl.com> <51E70106.8060100@goodadvice.pages.de> <51ED9318.6000003@nostrum.com> <51ED9A3C.4060307@goodadvice.pages.de> Date: Wed, 24 Jul 2013 12:24:34 +0530 Message-ID: From: Rajmohan Banavi To: Justin Uberti Content-Type: multipart/alternative; boundary=047d7bdc119adb319c04e23c619a Cc: behave , Oleg Moskalenko , Philipp Hancke , "rtcweb@ietf.org" Subject: Re: [BEHAVE] [rtcweb] Fwd: New Version Notification for draft-uberti-behave-turn-rest-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 06:54:37 -0000 --047d7bdc119adb319c04e23c619a Content-Type: text/plain; charset=ISO-8859-1 > So there are two parts to the proposal - the HTTP request for the > credentials and interactions with WebRTC, and the stateless implementation > that avoids the need for communication between web and TURN servers. And it > is true that other implementations besides the suggested stateless one are > possible, e.g. OAuth2. > > Would you prefer that I address the protocol and implementation parts > separately in the document, and mention that other implementations with the > same HTTP protocol are possible? RFC 5766 does something similar, where it > defines the TURN protocol, but in Section 6.2 talks about how a "stateless > stack" implementation can be used to simplify the processing on the TURN > server. > > As you pointed out, the draft essentially has 2 parts - the REST API and the stateless stack implementation which are completely independent. So yes, separating them would help because we want other implementations to also be compliant to the spec. Having said that, I would like opinions and consensus from others as well. Just to make my earlier point clearer - The credentials are generated by TURN server and validated by TURN server. None of the other components in the chain - web server, web application and the webrtc client, are concerned with it (sort of like a blob). So the interoperability is not an issue at all irrespective of what implementation approach you take. I had some other comments earlier, which are collated below. 1. What does the web server do with the shared (with TURN server) secret key? This is not clear from the text. 2. Sec 4.2 Server - "Note that the REALM value supplied by the server is not meaningful in this context, and can be set to any valid value". Which realm value is being referred here? The REALM attribute value in the 401 challenge response sent by the TURN server (in response to initial ALLOCATE request)? 3. The 2 statements seem to be contradictory: sec 1 "However, as a relay service, it imposes a nontrivial cost on the service provider". sec 5.1 "The assumption is that TURN services are of low enough value that waiting for the timeout to expire is a valid approach for dealing with possibly-compromised credentials". I am OK with the text, but would prefer if this could be reworded in anyway. --047d7bdc119adb319c04e23c619a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

=
So there are two parts to the proposal - the HTTP request = for the credentials and interactions with WebRTC, and the stateless impleme= ntation that avoids the need for communication between web and TURN servers= . And it is true that other implementations besides the suggested stateless= one are possible, e.g. OAuth2.

Would you prefer that I address the protocol and implem= entation parts separately in the document, and mention that other implement= ations with the same HTTP protocol are possible? RFC 5766 does something si= milar, where it defines the TURN protocol, but in Section 6.2 talks about h= ow a "stateless stack" implementation can be used to simplify the= processing on the TURN server.

As you pointe= d out, the draft essentially has 2 parts - the REST API and the stateless s= tack implementation which are completely independent. So yes, separating th= em would help because we want other implementations to also be compliant to= the spec. Having said that, I would like opinions and consensus from other= s as well.

Just to mak= e my earlier point clearer - The credentials are generated by TURN server a= nd validated by TURN server. None of the other components in the chain - we= b server, web application and the webrtc client, are concerned with it (sor= t of like a blob). So the interoperability is not an issue at all irrespect= ive of what implementation approach you take.

I had some = other comments earlier, which are collated below.
  1. What does the web server do with the shared (with TURN serve= r) secret key? This is not clear from the text.
  2. Sec 4.2 Server - "Note that the REALM value supplied by the s= erver is not meaningful in this context, and can be set to any valid value&= quot;. Which realm value is being referred here? The REALM attribute value = in the 401 challenge response sent by the TURN server (in response to initi= al ALLOCATE request)?
  3. The 2 statements seem to be contradictory: sec 1 "However, as= a relay service, it imposes a nontrivial cost on the service provider"= ;. sec 5.1 "The assumption is that TURN services are of low enough val= ue that waiting for the timeout to expire is a valid approach for dealing w= ith possibly-compromised credentials". I am OK with the text, but woul= d prefer if this could be reworded in anyway.
--047d7bdc119adb319c04e23c619a-- From rajmohanbanavi@gmail.com Wed Jul 24 01:47:00 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD39611E83C9; Wed, 24 Jul 2013 01:47:00 -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, HTML_MESSAGE=0.001, 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 9wHi-bAQ4aq9; Wed, 24 Jul 2013 01:47:00 -0700 (PDT) Received: from mail-oa0-x22d.google.com (mail-oa0-x22d.google.com [IPv6:2607:f8b0:4003:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 1A87811E810F; Wed, 24 Jul 2013 01:47:00 -0700 (PDT) Received: by mail-oa0-f45.google.com with SMTP id j1so301168oag.4 for ; Wed, 24 Jul 2013 01:46:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PEvJv44cQbAZtchg0lSCzitqeXS3fuE+DY/c7cQcivs=; b=rJsEfCva3rPRMglp1moJjiOBrP4CVjnVcvljs1EeTdlQzMbekXHBXRA5cCprnXl1Kc mDTiv2CUyI5K1ANezJSkdubOccH0iMN58kXoyBs0hMJ3q0/9uDEYHe2daO6Kq5E71KFL QDpdyLxjDhJyWpRZVmGtnzgGYb5dqWjwHe9zupTxXlvLR2wekC5zmS0HWXQbmsQFPx0H eEs4axKybjFRdoaxK1UbCJQiZgfUfoGKAwjAFL7L+JzC6CcKq2P8DNUcRgP/Q4OyzIir qcktMwmJXspYrZ++MyKD6/nOZ9L1QYj2m7nZulNgckfuWuDvnxauP+DewdfLi+qcpc3y sXoA== MIME-Version: 1.0 X-Received: by 10.43.0.67 with SMTP id nl3mr19413969icb.2.1374655619586; Wed, 24 Jul 2013 01:46:59 -0700 (PDT) Received: by 10.42.96.5 with HTTP; Wed, 24 Jul 2013 01:46:59 -0700 (PDT) In-Reply-To: References: <20130715214906.5314.83583.idtracker@ietfa.amsl.com> <51E70106.8060100@goodadvice.pages.de> <51ED9318.6000003@nostrum.com> <51ED9A3C.4060307@goodadvice.pages.de> Date: Wed, 24 Jul 2013 14:16:59 +0530 Message-ID: From: Rajmohan Banavi To: Oleg Moskalenko Content-Type: multipart/alternative; boundary=bcaec511e1b6e4e6be04e23df36a Cc: behave , Philipp Hancke , "rtcweb@ietf.org" , Justin Uberti Subject: Re: [BEHAVE] [rtcweb] Fwd: New Version Notification for draft-uberti-behave-turn-rest-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 08:47:00 -0000 --bcaec511e1b6e4e6be04e23df36a Content-Type: text/plain; charset=ISO-8859-1 This is the draft (BEHAVE WG) I am referring to - http://tools.ietf.org/html/draft-uberti-behave-turn-rest-00 > This is not the case. It is not the TURN server who generates the > credentials. The web server must generate the temporary password, and to be > able to do that the web server must have the shared secret - the same as > TURN server has. How they share the same shared secret I'd leave outside > the proposed specs. > > OK fine. > It is rather clear - the web server takes the shared secret and it > generates the temporary password for long-term TURN credentials. The TURN > server can reproduce that generation process and obtain the same temporary > password - because the TURN server knows the same shared secret as the web > server. > OK fine. Thanks, Rajmohan --bcaec511e1b6e4e6be04e23df36a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This is the draft (BEHAVE WG) I am referring to -=A0http://tools.ietf.or= g/html/draft-uberti-behave-turn-rest-00


This is not the case. It is not the TURN server who generat= es the credentials. The web server must generate the temporary password, an= d to be able to do that the web server must have the shared secret - the sa= me as TURN server has. How they share the same shared secret I'd leave = outside the proposed specs.

OK fine.
=A0
It is rather clear - the web server takes the shared secret and it generat= es the temporary password for long-term TURN credentials. The TURN server c= an reproduce that generation process and obtain the same temporary password= - because the TURN server knows the same shared secret as the web server.<= br>

<= /div>
OK fine.

Thanks,<= /div>
Rajmohan
--bcaec511e1b6e4e6be04e23df36a-- From dthaler@microsoft.com Wed Jul 24 12:57:59 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66F9B21F9DA1 for ; Wed, 24 Jul 2013 12:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.466 X-Spam-Level: X-Spam-Status: No, score=-100.466 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGZ3ECtnzbZC for ; Wed, 24 Jul 2013 12:57:54 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe005.messaging.microsoft.com [213.199.154.208]) by ietfa.amsl.com (Postfix) with ESMTP id EA72611E8239 for ; Wed, 24 Jul 2013 12:57:34 -0700 (PDT) Received: from mail44-am1-R.bigfish.com (10.3.201.250) by AM1EHSOBE012.bigfish.com (10.3.207.134) with Microsoft SMTP Server id 14.1.225.22; Wed, 24 Jul 2013 19:57:33 +0000 Received: from mail44-am1 (localhost [127.0.0.1]) by mail44-am1-R.bigfish.com (Postfix) with ESMTP id C6566480074 for ; Wed, 24 Jul 2013 19:57:33 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:autodiscover.service.exchange.microsoft.com; EFVD:NLI X-SpamScore: -18 X-BigFish: VS-18(zz98dIc85fh1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1d7338h1033IL17326ah8275dh18c673h1de097h1de096h8275bhz2fh2a8h683h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh17ej9a9j1155h) Received-SPF: pass (mail44-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14HUBC105.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT004.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail44-am1 (localhost.localdomain [127.0.0.1]) by mail44-am1 (MessageSwitch) id 1374695851694154_6113; Wed, 24 Jul 2013 19:57:31 +0000 (UTC) Received: from AM1EHSMHS014.bigfish.com (unknown [10.3.201.239]) by mail44-am1.bigfish.com (Postfix) with ESMTP id A488E40049 for ; Wed, 24 Jul 2013 19:57:31 +0000 (UTC) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS014.bigfish.com (10.3.207.152) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 24 Jul 2013 19:57:31 +0000 Received: from co1outboundpool.messaging.microsoft.com (157.54.51.114) by mail.microsoft.com (157.54.80.48) with Microsoft SMTP Server (TLS) id 14.3.136.1; Wed, 24 Jul 2013 19:57:20 +0000 Received: from mail170-co1-R.bigfish.com (10.243.78.253) by CO1EHSOBE038.bigfish.com (10.243.66.103) with Microsoft SMTP Server id 14.1.225.22; Wed, 24 Jul 2013 19:54:12 +0000 Received: from mail170-co1 (localhost [127.0.0.1]) by mail170-co1-R.bigfish.com (Postfix) with ESMTP id ECE4B6200D6 for ; Wed, 24 Jul 2013 19:54:11 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(51704005)(24454002)(189002)(199002)(46102001)(47736001)(19300405004)(33646001)(54316002)(4396001)(76786001)(77096001)(56776001)(19580395003)(74502001)(47446002)(83322001)(74366001)(76796001)(31966008)(74706001)(74662001)(19580385001)(76482001)(56816003)(63696002)(16406001)(16236675002)(79102001)(83072001)(69226001)(74876001)(81542001)(76576001)(51856001)(76176001)(49866001)(54356001)(59766001)(77982001)(53806001)(50986001)(65816001)(74316001)(15202345003)(47976001)(81342001)(80022001)(24736002)(3826001); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR03MB268; H:BN1PR03MB267.namprd03.prod.outlook.com; CLIP:2001:4898:80e0:ed43::49; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail170-co1 (localhost.localdomain [127.0.0.1]) by mail170-co1 (MessageSwitch) id 137469565054555_17052; Wed, 24 Jul 2013 19:54:10 +0000 (UTC) Received: from CO1EHSMHS019.bigfish.com (unknown [10.243.78.249]) by mail170-co1.bigfish.com (Postfix) with ESMTP id 08B48CE0048; Wed, 24 Jul 2013 19:54:10 +0000 (UTC) Received: from BL2PRD0310HT004.namprd03.prod.outlook.com (157.56.240.21) by CO1EHSMHS019.bigfish.com (10.243.66.29) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 24 Jul 2013 19:54:07 +0000 Received: from BN1PR03MB268.namprd03.prod.outlook.com (10.255.200.20) by BL2PRD0310HT004.namprd03.prod.outlook.com (10.255.97.39) with Microsoft SMTP Server (TLS) id 14.16.329.3; Wed, 24 Jul 2013 19:54:05 +0000 Received: from BN1PR03MB267.namprd03.prod.outlook.com (10.255.200.17) by BN1PR03MB268.namprd03.prod.outlook.com (10.255.200.20) with Microsoft SMTP Server (TLS) id 15.0.731.11; Wed, 24 Jul 2013 19:54:03 +0000 Received: from BN1PR03MB267.namprd03.prod.outlook.com ([169.254.15.34]) by BN1PR03MB267.namprd03.prod.outlook.com ([169.254.15.34]) with mapi id 15.00.0731.000; Wed, 24 Jul 2013 19:54:03 +0000 From: Dave Thaler To: "behave@ietf.org" Thread-Topic: Consensus call regarding nat-mib Thread-Index: Ac6IpoQ9/9IdQ+rFR36+IHgpReQ81Q== Date: Wed, 24 Jul 2013 19:54:02 +0000 Message-ID: <25e5cbb559ce438c9b419e20200f890a@BN1PR03MB267.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e0:ed43::49] x-forefront-prvs: 0917DFAC67 Content-Type: multipart/alternative; boundary="_000_25e5cbb559ce438c9b419e20200f890aBN1PR03MB267namprd03pro_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: BN1PR03MB268.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%VIAGENIE.CA$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%JACOBS-UNIVERSITY.DE$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC105.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC105.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: Juergen Schoenwaelder Subject: [BEHAVE] Consensus call regarding nat-mib X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 19:57:59 -0000 --_000_25e5cbb559ce438c9b419e20200f890aBN1PR03MB267namprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > Simon wrote: >> Our position, and we feel we have the consensus of the WG with us, is >> that the existing NAT-MIB is fatally flawed and we need a complete >> replacement. The reasons are explained in section 3.1. >> https://tools.ietf.org/html/draft-ietf-behave-nat-mib-06#section-3.1 >> >> That's why we initially started with a brand new MIB, called the >> NEW-NAT-MIB. We changed into the current structure based on feedback >> from the working group in general and Juergen in particular. > > Juergen responded: >> As far as I recall, it was initially not clear whether there is >> consensus that the NAT-MIB is fatally flawed. (And the text that is >> now in section >> 3.1 did not exist at that time in the current level of detail as far >> as I recall.) >> >> I suggest a consensus call is made by the chairs on this fundamental >> question. If there is consensus that the NAT-MIB is fatally flawed >> (and note that opinions of implementors in particular matter here), >> then declaring the MIB module in RFC 4008 historic (e.g. marking RFC >> 4008 historic) and creating a new MIB module may indeed be the right >> thing to do. I believe we've heard from many folks that RFC 4008 is not appropriate for carrier-grade NATs. The authors of draft-ietf-behave-nat-mib have put the reasons into section 3.1 as noted above. However, the chairs discussed Juergen's request and are fine asking for confirmation of this point. This email asks for confirmation of the posit= ion that "RFC 4008 should be historic and a new MIB module is needed" for all NATs (to cover both CGNs and non-CGNs). If you have an opinion on this matter, please respond with "Agree" (and state reason if it doesn't already appear in section 3.1) or "Object: ". Please respond before the WG meeting in Berlin. -Dave and Dan --_000_25e5cbb559ce438c9b419e20200f890aBN1PR03MB267namprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

> Simon wrote:

>> Our position, and we feel we have the co= nsensus of the WG with us, is

>> that the existing NAT-MIB is fatally fla= wed and we need a complete

>> replacement. The reasons are explained i= n section 3.1.

>> https://tools.ietf.org/html/draft-ietf-behave-nat-mib-06#section-3.1

>>

>> That's why we initially started with a b= rand new MIB, called the

>> NEW-NAT-MIB. We changed into the current= structure based on feedback

>> from the working group in general and Ju= ergen in particular.

>

> Juergen responded:

>> As far as I recall, it was initially not= clear whether there is

>> consensus that the NAT-MIB is fatally fl= awed. (And the text that is

>> now in section

>> 3.1 did not exist at that time in the cu= rrent level of detail as far

>> as I recall.)

>>

>> I suggest a consensus call is made by th= e chairs on this fundamental

>> question. If there is consensus that the= NAT-MIB is fatally flawed

>> (and note that opinions of implementors = in particular matter here),

>> then declaring the MIB module in RFC 400= 8 historic (e.g. marking RFC

>> 4008 historic) and creating a new MIB mo= dule may indeed be the right

>> thing to do.

 

I believe we’ve heard from many folks that = RFC 4008 is not appropriate

for carrier-grade NATs.  The authors of draf= t-ietf-behave-nat-mib have

put the reasons into section 3.1 as noted above.<= o:p>

 

However, the chairs discussed Juergen’s req= uest and are fine asking for

confirmation of this point.   This emai= l asks for confirmation of the position

that “RFC 4008 should be historic and a new= MIB module is needed” for all

NATs (to cover both CGNs and non-CGNs).

 

If you have an opinion on this matter, please res= pond with “Agree”

(and state reason if it doesn’t already app= ear in section 3.1) or

“Object: <state reason>”.<= /o:p>

 

Please respond before the WG meeting in Berlin.=

 

-Dave and Dan

--_000_25e5cbb559ce438c9b419e20200f890aBN1PR03MB267namprd03pro_-- From mom040267@gmail.com Wed Jul 24 00:11:22 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EAC221F9B0D; Wed, 24 Jul 2013 00:11:22 -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, HTML_MESSAGE=0.001, J_CHICKENPOX_52=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 KkLGO9PF5Ygq; Wed, 24 Jul 2013 00:11:21 -0700 (PDT) Received: from mail-pb0-x229.google.com (mail-pb0-x229.google.com [IPv6:2607:f8b0:400e:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id B19AE21F9011; Wed, 24 Jul 2013 00:11:21 -0700 (PDT) Received: by mail-pb0-f41.google.com with SMTP id rp16so9471149pbb.28 for ; Wed, 24 Jul 2013 00:11:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ckE9drNK/meu1p7jSl2RuPZEg2xWJoLnM99Co79r52Y=; b=DBExkhiUDBuwucEr6PnZxVhp/ySyDnVWhjFwiXLSY/YfyeuSDDcG9VxsAFDp+SRxZQ BSLNYgVpwvOh11kfVFfdwWRW63cBfmTfoLrDZAnlSsvKtmHy3fFN8EwHGW9fqCIRvn1d JLyyn0lNlX8CR8vcI3LLIpwXAA49ilVzVNniQ+xUrLCWPsGSxaEg77X+g6dO+N79D+A0 TUCI0PhRrnUXbzk38yPHRPF/7owllL6Ls0CyKZUR7QP9/1HEwvtzyfc5il1z8v+TuWvj VQ0nQO9aMo8YGmHvvvS0YbcRozc0e5/qVPsek3r4T6+eNh7TbABc/ir49EB5Vxbi9z2K HiVA== MIME-Version: 1.0 X-Received: by 10.68.111.129 with SMTP id ii1mr40987113pbb.95.1374649881412; Wed, 24 Jul 2013 00:11:21 -0700 (PDT) Received: by 10.68.92.132 with HTTP; Wed, 24 Jul 2013 00:11:21 -0700 (PDT) In-Reply-To: References: <20130715214906.5314.83583.idtracker@ietfa.amsl.com> <51E70106.8060100@goodadvice.pages.de> <51ED9318.6000003@nostrum.com> <51ED9A3C.4060307@goodadvice.pages.de> Date: Wed, 24 Jul 2013 00:11:21 -0700 Message-ID: From: Oleg Moskalenko To: Rajmohan Banavi Content-Type: multipart/alternative; boundary=047d7b5d9ff7df488e04e23c9d1f X-Mailman-Approved-At: Wed, 24 Jul 2013 14:01:51 -0700 Cc: behave , Philipp Hancke , "rtcweb@ietf.org" , Justin Uberti Subject: Re: [BEHAVE] [rtcweb] Fwd: New Version Notification for draft-uberti-behave-turn-rest-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 07:11:22 -0000 --047d7b5d9ff7df488e04e23c9d1f Content-Type: text/plain; charset=ISO-8859-1 Please see my comments in the text: On Tue, Jul 23, 2013 at 11:54 PM, Rajmohan Banavi wrote: > > Just to make my earlier point clearer - The credentials are generated by > TURN server and validated by TURN server. None of the other components in > the chain - web server, web application and the webrtc client, are > concerned with it (sort of like a blob). So the interoperability is not an > issue at all irrespective of what implementation approach you take. > This is not the case. It is not the TURN server who generates the credentials. The web server must generate the temporary password, and to be able to do that the web server must have the shared secret - the same as TURN server has. How they share the same shared secret I'd leave outside the proposed specs. > > I had some other comments earlier, which are collated below. > > 1. What does the web server do with the shared (with TURN server) > secret key? This is not clear from the text. > > It is rather clear - the web server takes the shared secret and it generates the temporary password for long-term TURN credentials. The TURN server can reproduce that generation process and obtain the same temporary password - because the TURN server knows the same shared secret as the web server. > > 1. > 2. Sec 4.2 Server - "Note that the REALM value supplied by the server > is not meaningful in this context, and can be set to any valid value". > Which realm value is being referred here? The REALM attribute value in the > 401 challenge response sent by the TURN server (in response to initial > ALLOCATE request)? > > I do not see those words in the draft text on the Internet: http://tools.ietf.org/html/draft-uberti-rtcweb-turn-rest-00 is there a newer version somewhere ? > > 1. > 2. The 2 statements seem to be contradictory: sec 1 "However, as a > relay service, it imposes a nontrivial cost on the service provider". sec > 5.1 "The assumption is that TURN services are of low enough value that > waiting for the timeout to expire is a valid approach for dealing with > possibly-compromised credentials". I am OK with the text, but would prefer > if this could be reworded in anyway. > > I'd really like to have an access to the fresh draft,it seems like it was not posted publicly - I cannot find it. Thanks Oleg --047d7b5d9ff7df488e04e23c9d1f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Please see my comments in the text:


On Tue, Jul 23, 2013 at 11:54 PM= , Rajmohan Banavi <rajmohanbanavi@gmail.com> wrote:

Just= to make my earlier point clearer - The credentials are generated by TURN s= erver and validated by TURN server. None of the other components in the cha= in - web server, web application and the webrtc client, are concerned with = it (sort of like a blob). So the interoperability is not an issue at all ir= respective of what implementation approach you take.

This is not the case. It is not the = TURN server who generates the credentials. The web server must generate the= temporary password, and to be able to do that the web server must have the= shared secret - the same as TURN server has. How they share the same share= d secret I'd leave outside the proposed specs.

=A0
<= div dir=3D"ltr">

I had some other comments earlier, which are collated below.
  1. What does the web server do with the sha= red (with TURN server) secret key? This is not clear from the text.
It is rather clear - the web server tak= es the shared secret and it generates the temporary password for long-term = TURN credentials. The TURN server can reproduce that generation process and= obtain the same temporary password - because the TURN server knows the sam= e shared secret as the web server.
=A0
  2. Sec 4.2 Server - "Note that the REALM value supplied by the s= erver is not meaningful in this context, and can be set to any valid value&= quot;. Which realm value is being referred here? The REALM attribute value = in the 401 challenge response sent by the TURN server (in response to initi= al ALLOCATE request)?

I do not see those w= ords in the draft text on the Internet:

http://tools.ietf.org/html/draf= t-uberti-rtcweb-turn-rest-00

is there a newer version somewhere ?
=A0
=
  2. The 2 statements seem to be contradictory: sec 1 "However, as= a relay service, it imposes a nontrivial cost on the service provider"= ;. sec 5.1 "The assumption is that TURN services are of low enough val= ue that waiting for the timeout to expire is a valid approach for dealing w= ith possibly-compromised credentials". I am OK with the text, but woul= d prefer if this could be reworded in anyway.

I'd really like= to have an access to the fresh draft,it seems like it was not posted publi= cly - I cannot find it.

Thanks
Oleg

--047d7b5d9ff7df488e04e23c9d1f-- From mom040267@gmail.com Wed Jul 24 07:06:54 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E50711E8104; Wed, 24 Jul 2013 07:06:54 -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, HTML_MESSAGE=0.001, 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 J9DnzXIg-Pap; Wed, 24 Jul 2013 07:06:52 -0700 (PDT) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 932AF11E80CC; Wed, 24 Jul 2013 07:06:52 -0700 (PDT) Received: by mail-pa0-f52.google.com with SMTP id kq13so693808pab.25 for ; Wed, 24 Jul 2013 07:06: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=xUzLCbuf1A4hw8HxbtvBxxnd974xTtPiJ5TGpIT4ZtA=; b=ubxJtuA7dMtj2YeJZKqGdmWXe7ApSM5hFIV4oKw3fd6kjlg1ZwVshMDekptTOimSX+ eE67xVwFnde3d9UAy/03D5f+PHfvgLwN+uUP0NthQ0foN1/GEIkDU2oSz155qxMEA+QR k9+gVZmjWsGOqAvTHTCipJviHWiobUrGlAlNwyMXkzTVMH7BevM11d3R+ZxA/NsMX16d wMMnRJAlXYtcKP97D8mDR4r3eEGGJlBr1YbWhjrmcL4kzCAOAjiDtt4rXfRLpgWYxhv8 rq5AWQbE7AYvZDFskhgnXWDrpyIDAzv4d0fXXbP4fS+hTwxShSo3B3MFmXKgDb9aAuTm I3yA== MIME-Version: 1.0 X-Received: by 10.68.99.98 with SMTP id ep2mr41730581pbb.6.1374674787666; Wed, 24 Jul 2013 07:06:27 -0700 (PDT) Received: by 10.68.92.132 with HTTP; Wed, 24 Jul 2013 07:06:27 -0700 (PDT) In-Reply-To: References: <20130715214906.5314.83583.idtracker@ietfa.amsl.com> <51E70106.8060100@goodadvice.pages.de> <51ED9318.6000003@nostrum.com> <51ED9A3C.4060307@goodadvice.pages.de> Date: Wed, 24 Jul 2013 07:06:27 -0700 Message-ID: From: Oleg Moskalenko To: Rajmohan Banavi Content-Type: multipart/alternative; boundary=047d7b6d7a6466913a04e2426a0e X-Mailman-Approved-At: Wed, 24 Jul 2013 14:01:52 -0700 Cc: behave , Philipp Hancke , "rtcweb@ietf.org" , Justin Uberti Subject: Re: [BEHAVE] [rtcweb] Fwd: New Version Notification for draft-uberti-behave-turn-rest-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 14:06:54 -0000 --047d7b6d7a6466913a04e2426a0e Content-Type: text/plain; charset=ISO-8859-1 Thank you for the new link. I checked the new version of the draft and I personally see no problem in the text. There is no proprietary software requirements in the draft. It simply defines the logic how the TURN server and web server can organize the temporary password generation, without imposing any proprietary requirements and specs on the software. It is mentioning a possible communication channel between web server and TURN server without defining any specs and as it is written that channel is not required. As it is written, I do not think that it has to be separated into two pieces - it is a single solid logical functionality definition. Thanks Oleg On Wed, Jul 24, 2013 at 1:46 AM, Rajmohan Banavi wrote: > This is the draft (BEHAVE WG) I am referring to - > http://tools.ietf.org/html/draft-uberti-behave-turn-rest-00 > > >> This is not the case. It is not the TURN server who generates the >> credentials. The web server must generate the temporary password, and to be >> able to do that the web server must have the shared secret - the same as >> TURN server has. How they share the same shared secret I'd leave outside >> the proposed specs. >> >> OK fine. > > >> It is rather clear - the web server takes the shared secret and it >> generates the temporary password for long-term TURN credentials. The TURN >> server can reproduce that generation process and obtain the same temporary >> password - because the TURN server knows the same shared secret as the web >> server. >> > > OK fine. > > Thanks, > Rajmohan > --047d7b6d7a6466913a04e2426a0e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thank you for the new link.

I checked th= e new version of the draft and I personally see no problem in the text. The= re is no proprietary software requirements in the draft. It simply defines = the logic how the TURN server and web server can organize the temporary pas= sword generation, without imposing any proprietary requirements and specs o= n the software. It is mentioning a possible communication channel between w= eb server and TURN server without defining any specs and as it is written t= hat channel is not required. As it is written, I do not think that it has t= o be separated into two pieces - it is a single solid logical functionality= definition.

Thanks
Oleg


On Wed, Jul 24, 2013 at 1:46 AM, Rajmohan Banavi <rajmohanbanavi@gmail.com> wrote:
This is the draft (BEHAVE WG) I am referri= ng to -=A0http://tools.ietf.org/html/draft-uberti-behave-turn-rest-00=


This is not the case. It is not the TURN server who generat= es the credentials. The web server must generate the temporary password, an= d to be able to do that the web server must have the shared secret - the sa= me as TURN server has. How they share the same shared secret I'd leave = outside the proposed specs.

OK fin= e.
=A0
It is rather clear - the web server takes the shared secret and it generat= es the temporary password for long-term TURN credentials. The TURN server c= an reproduce that generation process and obtain the same temporary password= - because the TURN server knows the same shared secret as the web server.<= br>

<= /div>
OK fine.

Th= anks,
Rajmohan

--047d7b6d7a6466913a04e2426a0e-- From ssenthil@cisco.com Wed Jul 24 14:20:59 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E591C11E8130 for ; Wed, 24 Jul 2013 14:20:57 -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 SelunMAkQQZR for ; Wed, 24 Jul 2013 14:20:52 -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 4FDF611E80DE for ; Wed, 24 Jul 2013 14:20:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4176; q=dns/txt; s=iport; t=1374700851; x=1375910451; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=YBK+9Ukb6oLouy+cb6Q+TJn7hdkECQ/8HdqjthZuOAw=; b=i3U7QywXLHrOXSDbI0qEvoMeAL7YAVmY+FkBfrnW447O5Rrs3Mu4/wyB //dyY+m2uGZaws7nNEQ04iImz8g6Ym9shlSpWD4dGSJFUB3c+JKyhaue0 5t3guv7yVvmHe6Ez7FQEmwfQCBDDVdssVlxR8ah/WkdHRgWD4I/kSUFvM Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoIIAFlE8FGtJV2d/2dsb2JhbABbgkJEgQWBH7xIgRYWdIImAQSBCwEMHlYlAgQbiAiZP6BQj0w4gxJuA6IQhxyDFIIq X-IronPort-AV: E=Sophos;i="4.89,737,1367971200"; d="scan'208,217";a="239044368" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 24 Jul 2013 21:20:50 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r6OLKndW026969 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 24 Jul 2013 21:20:49 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.80]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Wed, 24 Jul 2013 16:20:49 -0500 From: "Senthil Sivakumar (ssenthil)" To: "behave@ietf.org" Thread-Topic: Issue #1 : Logging drafts and destination information logging Thread-Index: AQHOiLOqgf+yokjfYEiu6LcOsswURQ== Date: Wed, 24 Jul 2013 21:20:48 +0000 Message-ID: In-Reply-To: <25e5cbb559ce438c9b419e20200f890a@BN1PR03MB267.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.117.198.132] Content-Type: multipart/alternative; boundary="_000_CB1B483277FEC94E9B58357040EE5D023266B7A5xmbrcdx15ciscoc_" MIME-Version: 1.0 Subject: [BEHAVE] Issue #1 : Logging drafts and destination information logging X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 21:20:59 -0000 --_000_CB1B483277FEC94E9B58357040EE5D023266B7A5xmbrcdx15ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am starting a couple of threads to track the inconsistencies between the = syslog and IPFIX logging drafts that requires input from the WG. This is th= e first issue that we need input on. Logging of destination information has been discouraged in general for vari= ous reasons, log record size, privacy reasons etc. However, both the drafts= had provided the facility to log destination information if the operator c= hooses to do so. IPFIX draft has had information elements for destination i= nformation for a long time and syslog had the provision too until last vers= ion. However, syslog draft has removed this provision to log destination in= formation in the latest draft. We are seeking WG guidance on if we should we have provisions for destinati= on logging or not. Personally, I would like to see the ability to log destination information = if one desires, but have text in the drafts to recommend that the destinati= on logging be turned off by default. Thanks Senthil --_000_CB1B483277FEC94E9B58357040EE5D023266B7A5xmbrcdx15ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <3AFDBCB4483DB04A8A315C20122CA184@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
I am starting a couple of threads to track the inconsistencies between= the syslog and IPFIX logging drafts that requires input from the WG. This = is the first issue that we need input on.

Logging of destination information has been discouraged in general for= various reasons, log record size, privacy reasons etc. However, both the d= rafts had provided the facility to log destination information if the opera= tor chooses to do so. IPFIX draft has had information elements for destination information for a long time a= nd syslog had the provision too until last version. However, syslog draft h= as removed this provision to log destination information in the latest draf= t. 

We are seeking WG guidance on if we should we have provisions for dest= ination logging or not.

Personally, I would like to see the ability to log destination informa= tion if one desires, but have text in the drafts to recommend that the dest= ination logging be turned off by default.

Thanks
Senthil
--_000_CB1B483277FEC94E9B58357040EE5D023266B7A5xmbrcdx15ciscoc_-- From ssenthil@cisco.com Wed Jul 24 14:21:01 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41D5C11E8134 for ; Wed, 24 Jul 2013 14:21:01 -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 1HkwFG28tcCm for ; Wed, 24 Jul 2013 14:20:55 -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 1BA4E11E810B for ; Wed, 24 Jul 2013 14:20:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1471; q=dns/txt; s=iport; t=1374700855; x=1375910455; h=from:to:subject:date:message-id:mime-version; bh=Vk/Kweu8CrDpq1CdqzTQ+7KGZRFjlnPbgT6vqz/7VB0=; b=RhbeZ+xlV6AuUugHZtLHnbDtfJIsex7W2+KN5b68IfVu1SdyGkDa+7Ai MUCpZ5Q+QBRMSmhiqAuz3RYMccLwGk8lUKzzXTGinmJ4xJwaTVLHltj10 dpM8xzEro1sktbpZKQyPX3/CwUV7LLAvFgBL3vErwjz72UzerdJwnoevc M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnELAOFD8FGtJV2b/2dsb2JhbABbgkJEgQWIHLVLgRYWdIIbCwEEgQsBCwEeVicEG4gImT+gUI9Mg0puA6ksgxSCKg X-IronPort-AV: E=Sophos;i="4.89,737,1367971200"; d="scan'208,217";a="239105576" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 24 Jul 2013 21:20:54 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r6OLKs1b015556 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 24 Jul 2013 21:20:54 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.80]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Wed, 24 Jul 2013 16:20:53 -0500 From: "Senthil Sivakumar (ssenthil)" To: "behave@ietf.org" Thread-Topic: Issue #2 : Logging drafts and device ID Thread-Index: AQHOiLOtermPsfeCrEy1va0h8VSPUg== Date: Wed, 24 Jul 2013 21:20:53 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.117.198.132] Content-Type: multipart/alternative; boundary="_000_CB1B483277FEC94E9B58357040EE5D023266B7B0xmbrcdx15ciscoc_" MIME-Version: 1.0 Subject: [BEHAVE] Issue #2 : Logging drafts and device ID X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 21:21:01 -0000 --_000_CB1B483277FEC94E9B58357040EE5D023266B7B0xmbrcdx15ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Syslog draft has a device ID/type field (optional) that specifies if the de= vice is NAT44/NAT64/DS-Lite etc. This device ID is not present in IPFIX dra= ft, and I don=92t know if this information is useful. We need working group input on this if a device ID needs to be added to all= messages. Thanks Senthil --_000_CB1B483277FEC94E9B58357040EE5D023266B7B0xmbrcdx15ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <58E4DCEDA1291D44843B9604BB978F00@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Syslog draft has a device ID/type field (optional) that specifies if t= he device is NAT44/NAT64/DS-Lite etc. This device ID is not present in IPFI= X draft, and I don=92t know if this information is useful.
We need working group input on this if a device ID needs to be added t= o all messages.

Thanks
Senthil
--_000_CB1B483277FEC94E9B58357040EE5D023266B7B0xmbrcdx15ciscoc_-- From xing@cernet.edu.cn Wed Jul 24 18:31:57 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F07BD21F9A34 for ; Wed, 24 Jul 2013 18:31: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 bXKxjfzjvUbj for ; Wed, 24 Jul 2013 18:31:52 -0700 (PDT) Received: from cernet.edu.cn (mail.cernet.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with ESMTP id 5AAA421F99A6 for ; Wed, 24 Jul 2013 18:31:50 -0700 (PDT) Received: from [IPv6:::1] (unknown [202.112.35.224]) by centos (Coremail) with SMTP id AQAAf3CLhgTef_BRpRUTAA--.61789S5; Thu, 25 Jul 2013 09:31:25 +0800 (CST) Message-ID: <51F07FEB.1040709@cernet.edu.cn> Date: Thu, 25 Jul 2013 09:31:23 +0800 From: Xing Li User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Dan Wing References: <4E0C46AA-706D-4F12-9099-EBF996AC41BE@cisco.com> In-Reply-To: <4E0C46AA-706D-4F12-9099-EBF996AC41BE@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CM-TRANSID: AQAAf3CLhgTef_BRpRUTAA--.61789S5 X-Coremail-Antispam: 1UD129KBjvJXoWxury7Gry3Xw17Jw1rAry5urg_yoW5ZryfpF 93JFWxKr48J3s7GwnrXw18XrnYvay8Jry7Grn5tr1rZ34DAF1jgr42yFWrXayDWryrAr4j qFyUu345Xw1rJr7anT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUqmb7Iv0xC_Cr1lb4IE77IF4wAFF20E14v26r4j6ryUM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2z4x0Y4vE2Ix0cI8IcVAFwI0_Jr0_JF4l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Gr0_ Cr1l84ACjcxK6I8E87Iv67AKxVW8JVWxJwA2z4x0Y4vEx4A2jsIEc7CjxVAFwI0_Gr0_Gr 1UM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI64kE6c02F40Ex7xfMcIj6xII jxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr 1lF7xvr2IY64vIr41lc2xSY4AK67AK6w4l42xK82IYc2Ij64vIr41lx2IqxVAqx4xG67AK xVWUJVWUGwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1Y6r17MIIYrx kI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v2 6r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0rVWrJr0_WFyUJwCI42IY6I8E87Iv67AKxVWUJV W8JwCI42IY6I8E87Iv6xkF7I0E14v26r4j6r4UJbIYCTnIWIevJa73UjIFyTuYvjxU7tku UUUUU X-CM-SenderInfo: p0lqwqxfhu0vvwohv3gofq/ Cc: Qiong , behave@ietf.org Subject: Re: [BEHAVE] I-D Action: draft-sun-behave-v4tov6-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 01:31:57 -0000 Hi, Dan and All, Dan Wing 写道: > > On Jul 9, 2013, at 7:17 AM, Qiong > wrote: > >> Dear all, >> >> We have submitted a new draft for IPv4 client to IPv6 server. It is >> designed to cover the Scenario 2 in RFC6144. It can save the public >> IPv4 addresses consumed by IPv6 side and does not have impact on >> existing applications. >> >> Your comments/reviews are appreciated. > > This maps private IPv4 addresses to an IPv6 address so solves > RFC6144's Scenario 4: "An IPv4 Network to the IPv6 Internet". > > I am interested in comments from the working group if Scenario 4 is a > problem on your networks, or anticipated to become a problem on your > networks. Yes, according to CERNET/CERNET2's experience, after we providing the services for scenario 1 and 2 (RFC6219) via IVI, the uses then ask us provide services for scenario 3 and 4, which currently under development and testing. Best regards, xing > > -d > > >> >> Best wishes >> Qiong >> >> >> ---------- Forwarded message ---------- >> From: internet-drafts@ietf.org >> Date: Mon, 08 Jul 2013 08:16:36 -0700 >> Subject: I-D Action: draft-sun-behave-v4tov6-00.txt >> To: i-d-announce@ietf.org >> >> A new version of I-D, draft-sun-behave-v4tov6-00.txt >> has been successfully submitted by Chongfeng Xie and posted to the >> IETF repository. >> Filename: draft-sun-behave-v4tov6 >> Revision: 00 >> Title: The Approach for IPv4-only users to access IPv6-only Content >> Creation date: 2013-07-08 >> Group: Individual Submission >> Number of pages: 13 >> URL: http://www.ietf.org/internet-drafts/draft-sun-behave-v4tov6-00.txt >> Status: http://datatracker.ietf.org/doc/draft-sun-behave-v4tov6 >> Htmlized: http://tools.ietf.org/html/draft-sun-behave-v4tov6-00 >> Abstract: >> Current approaches can not solve the scenario that the users from >> IPv4 Internet to access IPv6-only content. When IPv6 content are >> becoming more and more popular, it is important to ensure that IPv6- >> only content can be reachable from legacy IPv4-only clients via some >> IPv4-only network. This document proposes two approaches for IPv4- >> only users to access IPv6-only content. It is designed to cover the >> Scenario 2 in [RFC6144]. >> The IETF Secretariat >> >> -- >> ============================================== >> Qiong Sun >> China Telecom Beijing Research Institute >> >> >> Open source code: >> lightweight 4over6: /http://sourceforge.net/projects/laft6// >> PCP-natcoord:/ http://sourceforge.net/projects/pcpportsetdemo/ / >> =============================================== >> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave > > ------------------------------------------------------------------------ > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From cathy.zhou@huawei.com Wed Jul 24 20:21:30 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ABCD21F99BF for ; Wed, 24 Jul 2013 20:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z9wqkpALFdsL for ; Wed, 24 Jul 2013 20:21:25 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 29BF121F9302 for ; Wed, 24 Jul 2013 20:21:13 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVK00798; Thu, 25 Jul 2013 03:21:11 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 25 Jul 2013 04:19:27 +0100 Received: from SZXEML460-HUB.china.huawei.com (10.82.67.203) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 25 Jul 2013 04:20:25 +0100 Received: from SZXEML513-MBX.china.huawei.com ([169.254.7.119]) by szxeml460-hub.china.huawei.com ([10.82.67.203]) with mapi id 14.01.0323.007; Thu, 25 Jul 2013 11:20:18 +0800 From: "Zhouqian (Cathy)" To: "Senthil Sivakumar (ssenthil)" , "behave@ietf.org" Thread-Topic: [BEHAVE] Issue #1 : Logging drafts and destination information logging Thread-Index: AQHOiLO3+K/SdSL5YUmqRpF/zE6cSpl0uLXg Date: Thu, 25 Jul 2013 03:20:18 +0000 Message-ID: References: <25e5cbb559ce438c9b419e20200f890a@BN1PR03MB267.namprd03.prod.outlook.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.76.105] Content-Type: multipart/alternative; boundary="_000_A6A061BEE5DDC94A9692D9D81AF776DF326519A0szxeml513mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [BEHAVE] Issue #1 : Logging drafts and destination information logging X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 03:21:30 -0000 --_000_A6A061BEE5DDC94A9692D9D81AF776DF326519A0szxeml513mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with Senthil that the logging of destination information should be = optional. And we will put it in the next version of syslog logging draft. Best Regards, Cathy From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of= Senthil Sivakumar (ssenthil) Sent: Thursday, July 25, 2013 5:21 AM To: behave@ietf.org Subject: [BEHAVE] Issue #1 : Logging drafts and destination information log= ging I am starting a couple of threads to track the inconsistencies between the = syslog and IPFIX logging drafts that requires input from the WG. This is th= e first issue that we need input on. Logging of destination information has been discouraged in general for vari= ous reasons, log record size, privacy reasons etc. However, both the drafts= had provided the facility to log destination information if the operator c= hooses to do so. IPFIX draft has had information elements for destination i= nformation for a long time and syslog had the provision too until last vers= ion. However, syslog draft has removed this provision to log destination in= formation in the latest draft. We are seeking WG guidance on if we should we have provisions for destinati= on logging or not. Personally, I would like to see the ability to log destination information = if one desires, but have text in the drafts to recommend that the destinati= on logging be turned off by default. Thanks Senthil --_000_A6A061BEE5DDC94A9692D9D81AF776DF326519A0szxeml513mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agree with Senthil that the logging of destination information = should be optional. And we will put it in the next version of syslog loggin= g draft.

 

Best Re= gards,

Cathy

 

From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.o= rg] On Behalf Of Senthil Sivakumar (ssenthil)
Sent: Thursday, July 25, 2013 5:21 AM
To: behave@ietf.org
Subject: [BEHAVE] Issue #1 : Logging drafts and destination informat= ion logging

 

I am starting a couple of threads to track the inconsistencies betwe= en the syslog and IPFIX logging drafts that requires input from the WG. Thi= s is the first issue that we need input on.

 

Logging of destination information has been discouraged in general f= or various reasons, log record size, privacy reasons etc. However, both the= drafts had provided the facility to log destination information if the operator chooses to do so. IPFIX draft has = had information elements for destination information for a long time and sy= slog had the provision too until last version. However, syslog draft has re= moved this provision to log destination information in the latest draft. 

 

We are seeking WG guidance on if we should we have provisions for de= stination logging or not.

 

Personally, I would like to see the ability to log destination infor= mation if one desires, but have text in the drafts to recommend that the de= stination logging be turned off by default.

 

Thanks

Senthil

--_000_A6A061BEE5DDC94A9692D9D81AF776DF326519A0szxeml513mbxchi_-- From simon.perreault@viagenie.ca Thu Jul 25 00:56:19 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98B2221F9A17 for ; Thu, 25 Jul 2013 00:56:19 -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 3Egqe8oN-42Y for ; Thu, 25 Jul 2013 00:56:19 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 114B321F99F7 for ; Thu, 25 Jul 2013 00:56:19 -0700 (PDT) Received: from [IPv6:::1] (unknown [IPv6:2001:660:3001:4012:245a:a34b:600:fe8b]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 7DF9847105 for ; Thu, 25 Jul 2013 03:56:17 -0400 (EDT) Message-ID: <51F0DA20.1060200@viagenie.ca> Date: Thu, 25 Jul 2013 09:56:16 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: behave@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [BEHAVE] Issue #1 : Logging drafts and destination information logging X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 07:56:19 -0000 Le 2013-07-24 23:20, Senthil Sivakumar (ssenthil) a crit : > Personally, I would like to see the ability to log destination > information if one desires, but have text in the drafts to recommend > that the destination logging be turned off by default. +1 Simon From dwing@cisco.com Thu Jul 25 17:19:40 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4541221F918C for ; Thu, 25 Jul 2013 17:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.549 X-Spam-Level: X-Spam-Status: No, score=-110.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 enfr7lu7Y-FL for ; Thu, 25 Jul 2013 17:19:35 -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 411B721F90DC for ; Thu, 25 Jul 2013 17:19:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=430; q=dns/txt; s=iport; t=1374797975; x=1376007575; h=from:content-transfer-encoding:subject:message-id:date: to:mime-version; bh=r59r5t8Wk0WT0T0ZX8+m2LjrcDhl2WkvZ1KCOMn5D/k=; b=TWPfmhUIrIni4WiRwMpkhNfeNSE/T0XYU+t40dnUqu6FmBCvfYhcQp4f V+UIqqic2EvLiReCP2FLt6UdPJqRqwEilYGZM9LSinyAcxfkm8EBXuCZ3 vexL2kiFPPuw3UmASaQJjmIJaKWCCIKPlYy9dfosXC1WBObPiiJSaq/dT o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAAvA8VGrRDoI/2dsb2JhbABagwa/fRZ0gmWBfYgimFKgQ5MWbgOJKo41kU2DNBw X-IronPort-AV: E=Sophos;i="4.89,746,1367971200"; d="scan'208";a="87301270" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 26 Jul 2013 00:19:31 +0000 Received: from sjc-vpn7-2043.cisco.com (sjc-vpn7-2043.cisco.com [10.21.151.251]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6Q0JUfp012776 for ; Fri, 26 Jul 2013 00:19:30 GMT From: Dan Wing Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <9B6672F8-4718-49B3-A009-F0270BDEBF2F@cisco.com> Date: Thu, 25 Jul 2013 17:19:30 -0700 To: "behave@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [BEHAVE] walking RFC4008 (NAT MIB) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 00:19:40 -0000 Looking at RFC4008, it seems a bunch of gets would need to be necessary = to answer a simple question: how many mappings does subscriber "A" have = mapped, which seems a reasonable question to an ISP's technical support = line. To determine this, it seems to require walking the entire mapping = table to the end, and displaying every time subscriber "A" matches. Is = there some way to shortcut that with RFC4008? -d From j.schoenwaelder@jacobs-university.de Thu Jul 25 21:32:49 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F18421F8B04 for ; Thu, 25 Jul 2013 21:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a+HPFXVeWh3I for ; Thu, 25 Jul 2013 21:32:44 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id C9D7221F8BCE for ; Thu, 25 Jul 2013 21:32:39 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 244B220F77; Fri, 26 Jul 2013 06:32:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id t5lFo5YiXHMN; Fri, 26 Jul 2013 06:32:38 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 82D6220F66; Fri, 26 Jul 2013 06:32:37 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id BA392277A4F9; Fri, 26 Jul 2013 06:32:33 +0200 (CEST) Date: Fri, 26 Jul 2013 06:32:33 +0200 From: Juergen Schoenwaelder To: Dan Wing Message-ID: <20130726043233.GB44013@elstar.local> Mail-Followup-To: Dan Wing , "behave@ietf.org" References: <9B6672F8-4718-49B3-A009-F0270BDEBF2F@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9B6672F8-4718-49B3-A009-F0270BDEBF2F@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "behave@ietf.org" Subject: Re: [BEHAVE] walking RFC4008 (NAT MIB) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 04:32:49 -0000 On Thu, Jul 25, 2013 at 05:19:30PM -0700, Dan Wing wrote: > Looking at RFC4008, it seems a bunch of gets would need to be > necessary to answer a simple question: how many mappings does > subscriber "A" have mapped, which seems a reasonable question to an > ISP's technical support line. To determine this, it seems to > require walking the entire mapping table to the end, and displaying > every time subscriber "A" matches. Is there some way to shortcut > that with RFC4008? >From looking at the RFC 4008 tables, I think the answer depends on the type of NAT you are facing. If the natAddrBindTable (natAddrPortBindTable) is populated, will you not get away with walking all bindings for customer "A"'s interface and customer "A"'s local address? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dwing@cisco.com Fri Jul 26 10:08:26 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7271C21F918F for ; Fri, 26 Jul 2013 10:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.562 X-Spam-Level: X-Spam-Status: No, score=-110.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 1yyYv+LQ2svb for ; Fri, 26 Jul 2013 10:08:21 -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 C499921F9675 for ; Fri, 26 Jul 2013 10:08:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1635; q=dns/txt; s=iport; t=1374858501; x=1376068101; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=tK4Ptn/yQlbhMikKbfll1aJVC0OncWhtD4q13lsHm2c=; b=QWWA3FD0tlXfIY6T4DIcWqvPuQKIJ1RQx2JC3JgVBjIRdkUe3eQkL713 sLplPtwAvTDVtdvfBCHHBwoQQzurQu/jTCJOO4XUoC56M4zyWxDsR6Kg+ buLnwp8i7RYnSq7/V+Ui0NHlaTBWyb32+0iQifQjMjacmde00WkoXELJM s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAIis8lGrRDoJ/2dsb2JhbABYA4MGNb4ugRkWdIIkAQEBAwE6PwUJAgsOAgguGzwGE4gKBbhdBI9GIxAHEYMFbwOJKo41kUyDNBw X-IronPort-AV: E=Sophos;i="4.89,752,1367971200"; d="scan'208";a="87323703" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 26 Jul 2013 17:08:20 +0000 Received: from sjc-vpn7-2043.cisco.com (sjc-vpn7-2043.cisco.com [10.21.151.251]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r6QH8JV1032568; Fri, 26 Jul 2013 17:08:19 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dan Wing In-Reply-To: <20130726043233.GB44013@elstar.local> Date: Fri, 26 Jul 2013 10:08:19 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <27F057BA-F248-4CAE-8FA0-88382F6BE78A@cisco.com> References: <9B6672F8-4718-49B3-A009-F0270BDEBF2F@cisco.com> <20130726043233.GB44013@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1508) Cc: "behave@ietf.org" Subject: Re: [BEHAVE] walking RFC4008 (NAT MIB) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 17:08:26 -0000 On Jul 25, 2013, at 9:32 PM, Juergen Schoenwaelder = wrote: > On Thu, Jul 25, 2013 at 05:19:30PM -0700, Dan Wing wrote: >=20 >> Looking at RFC4008, it seems a bunch of gets would need to be >> necessary to answer a simple question: how many mappings does >> subscriber "A" have mapped, which seems a reasonable question to an >> ISP's technical support line. To determine this, it seems to >> require walking the entire mapping table to the end, and displaying >> every time subscriber "A" matches. Is there some way to shortcut >> that with RFC4008? >=20 > =46rom looking at the RFC 4008 tables, I think the answer depends on = the > type of NAT you are facing. >=20 > If the natAddrBindTable (natAddrPortBindTable) is populated, will you > not get away with walking all bindings for customer "A"'s interface > and customer "A"'s local address? Yes, thanks -- that would work if all the subscribers have unique = natAddrBindLocalAddr (IP address). But it wouldn't work where the = unique selector is something else, such as DS-Lite (where every = subscriber could and will use the same IPv4 address, but different IPv6 = tunnels), or NATs where VRF or VLAN are used as the subscriber = identifier. Is there some other way RFC4008 could work for those cases = of IPv6, VRF, VLAN being the subscriber identifier? -d >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Fri Jul 26 11:20:47 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E10511E8117 for ; Fri, 26 Jul 2013 11:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T7Fa8jMU4EDw for ; Fri, 26 Jul 2013 11:20:42 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 99E4F11E80F6 for ; Fri, 26 Jul 2013 11:20:40 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 20D8D20BF3; Fri, 26 Jul 2013 20:20:40 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id x75v5wFRpOiH; Fri, 26 Jul 2013 20:20:40 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CE76F20BEE; Fri, 26 Jul 2013 20:20:38 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4D23F277A924; Fri, 26 Jul 2013 20:20:34 +0200 (CEST) Date: Fri, 26 Jul 2013 20:20:33 +0200 From: Juergen Schoenwaelder To: Dan Wing Message-ID: <20130726182033.GA45380@elstar.local> Mail-Followup-To: Dan Wing , "behave@ietf.org" References: <9B6672F8-4718-49B3-A009-F0270BDEBF2F@cisco.com> <20130726043233.GB44013@elstar.local> <27F057BA-F248-4CAE-8FA0-88382F6BE78A@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <27F057BA-F248-4CAE-8FA0-88382F6BE78A@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "behave@ietf.org" Subject: Re: [BEHAVE] walking RFC4008 (NAT MIB) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 18:20:47 -0000 On Fri, Jul 26, 2013 at 10:08:19AM -0700, Dan Wing wrote: > Yes, thanks -- that would work if all the subscribers have unique > natAddrBindLocalAddr (IP address). But it wouldn't work where the > unique selector is something else, such as DS-Lite (where every > subscriber could and will use the same IPv4 address, but different > IPv6 tunnels), or NATs where VRF or VLAN are used as the subscriber > identifier. Is there some other way RFC4008 could work for those > cases of IPv6, VRF, VLAN being the subscriber identifier? Do the DS-Lite tunnels not end at different tunnel interfaces? Same for VLAN interfaces? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dwing@cisco.com Fri Jul 26 12:34:17 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C1F211E812E for ; Fri, 26 Jul 2013 12:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.569 X-Spam-Level: X-Spam-Status: No, score=-110.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 WI-e5UqDGWIZ for ; Fri, 26 Jul 2013 12:34:13 -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 075BC11E812D for ; Fri, 26 Jul 2013 12:34:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1158; q=dns/txt; s=iport; t=1374867253; x=1376076853; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=4fau7ONAPcE2Uf3bScSdndeFsbT5kVEd+Ky29y9Gv8M=; b=TV4Qq0Oe9DPzvf8zXM5wyTjGC8ZGdeYunrb24RgP+Up41mQzi+L+fKoC N4y/l1+4aDsfxc0+0PEo/JA+A0J/pOezDnad1fXT0PtRf4achhXFTtO3C n7K9C+WuiyTGVuPSOSDN02oyL+UslMIPmnRph+oLMwhzEOR7LlCG47cip o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAPrO8lGrRDoI/2dsb2JhbABbgwY1vi6BGRZ0giQBAQEDATo/BQsLDgIILlcGE4gKBQ24aY4/EXozB4MWbwOJKo41gSmQI4M0HIEt X-IronPort-AV: E=Sophos;i="4.89,752,1367971200"; d="scan'208";a="87402003" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 26 Jul 2013 19:34:11 +0000 Received: from sjc-vpn7-2043.cisco.com (sjc-vpn7-2043.cisco.com [10.21.151.251]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6QJY9et004632; Fri, 26 Jul 2013 19:34:10 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dan Wing In-Reply-To: <20130726182033.GA45380@elstar.local> Date: Fri, 26 Jul 2013 12:34:09 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9B6672F8-4718-49B3-A009-F0270BDEBF2F@cisco.com> <20130726043233.GB44013@elstar.local> <27F057BA-F248-4CAE-8FA0-88382F6BE78A@cisco.com> <20130726182033.GA45380@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1508) Cc: "behave@ietf.org" Subject: Re: [BEHAVE] walking RFC4008 (NAT MIB) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 19:34:17 -0000 On Jul 26, 2013, at 11:20 AM, Juergen Schoenwaelder = wrote: > On Fri, Jul 26, 2013 at 10:08:19AM -0700, Dan Wing wrote: >=20 >> Yes, thanks -- that would work if all the subscribers have unique >> natAddrBindLocalAddr (IP address). But it wouldn't work where the >> unique selector is something else, such as DS-Lite (where every >> subscriber could and will use the same IPv4 address, but different >> IPv6 tunnels), or NATs where VRF or VLAN are used as the subscriber >> identifier. Is there some other way RFC4008 could work for those >> cases of IPv6, VRF, VLAN being the subscriber identifier? >=20 > Do the DS-Lite tunnels not end at different tunnel interfaces? Same > for VLAN interfaces? The SYSLOG and IPFIX logging documents are emitting VLAN and VRF = numbers, rather than tunnel interface numbers. =20 SYSLOG logging example of its quota exceeded event, = http://tools.ietf.org/html/draft-ietf-behave-syslog-nat-logging-02#section= -3.6 IPFIX logging example of its vlanID and ingressVRFID, = http://tools.ietf.org/html/draft-ietf-behave-ipfix-nat-logging-00#page-6 -d From j.schoenwaelder@jacobs-university.de Fri Jul 26 13:24:42 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 202B711E8140 for ; Fri, 26 Jul 2013 13:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VDQnXVfS2hyc for ; Fri, 26 Jul 2013 13:24:37 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 92FEA11E80FB for ; Fri, 26 Jul 2013 13:24:37 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id B6D0E20BF3; Fri, 26 Jul 2013 22:24:36 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id wIQPdgY8YOu7; Fri, 26 Jul 2013 22:24:36 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2DA2720BF5; Fri, 26 Jul 2013 22:24:36 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 9F946277B0E7; Fri, 26 Jul 2013 22:24:31 +0200 (CEST) Date: Fri, 26 Jul 2013 22:24:31 +0200 From: Juergen Schoenwaelder To: Dan Wing Message-ID: <20130726202431.GB45709@elstar.local> Mail-Followup-To: Dan Wing , "behave@ietf.org" References: <9B6672F8-4718-49B3-A009-F0270BDEBF2F@cisco.com> <20130726043233.GB44013@elstar.local> <27F057BA-F248-4CAE-8FA0-88382F6BE78A@cisco.com> <20130726182033.GA45380@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "behave@ietf.org" Subject: Re: [BEHAVE] walking RFC4008 (NAT MIB) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 20:24:42 -0000 On Fri, Jul 26, 2013 at 12:34:09PM -0700, Dan Wing wrote: > > On Jul 26, 2013, at 11:20 AM, Juergen Schoenwaelder wrote: > > > On Fri, Jul 26, 2013 at 10:08:19AM -0700, Dan Wing wrote: > > > >> Yes, thanks -- that would work if all the subscribers have unique > >> natAddrBindLocalAddr (IP address). But it wouldn't work where the > >> unique selector is something else, such as DS-Lite (where every > >> subscriber could and will use the same IPv4 address, but different > >> IPv6 tunnels), or NATs where VRF or VLAN are used as the subscriber > >> identifier. Is there some other way RFC4008 could work for those > >> cases of IPv6, VRF, VLAN being the subscriber identifier? > > > > Do the DS-Lite tunnels not end at different tunnel interfaces? Same > > for VLAN interfaces? > > The SYSLOG and IPFIX logging documents are emitting VLAN and VRF numbers, rather than tunnel interface numbers. > > SYSLOG logging example of its quota exceeded event, http://tools.ietf.org/html/draft-ietf-behave-syslog-nat-logging-02#section-3.6 > IPFIX logging example of its vlanID and ingressVRFID, http://tools.ietf.org/html/draft-ietf-behave-ipfix-nat-logging-00#page-6 > This design limits things to VLANs and VRFs - back when the NAT-MIB was created, an interface identifier as this makes things quite generic - it works for any current and future interface type. But then I am told NATs do not work this way anymore... /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dwing@cisco.com Fri Jul 26 13:34:11 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D08C11E8182 for ; Fri, 26 Jul 2013 13:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.574 X-Spam-Level: X-Spam-Status: No, score=-110.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 mmvSCe-zwPrr for ; Fri, 26 Jul 2013 13:34:07 -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 4C87211E8181 for ; Fri, 26 Jul 2013 13:34:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1983; q=dns/txt; s=iport; t=1374870841; x=1376080441; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=gfW9QrmhchWkDGQGK8n3n/ttTN9sT/iZgv2y/XzR2gw=; b=eOP2N0vWkHNWcQHy/mbHELmdRn7TzkdfOze7MeVEX8sXMHU8ZnSOWW/8 3+M8eK2lo7BFYR2VKPw/J++c/eT43fRwpEwt2G3G4IFpxUhwYprwsquT5 9TVlFwFXoBrqKUMkY38ExgTLCwL3dGkaNPgzvg4SddNtpEEfysEtJ+zeS M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAI7c8lGrRDoJ/2dsb2JhbABYA4MGNb4ugRkWdIIkAQEBAwE6PwUJAgsOAgguGzwGE4gKBQ24dgSOOxF6IxAHEYMFbwOJKo41gSmQI4M0HIEt X-IronPort-AV: E=Sophos;i="4.89,753,1367971200"; d="scan'208";a="87343065" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 26 Jul 2013 20:34:01 +0000 Received: from sjc-vpn7-2043.cisco.com (sjc-vpn7-2043.cisco.com [10.21.151.251]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r6QKXwUh006528; Fri, 26 Jul 2013 20:33:58 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Dan Wing In-Reply-To: <20130726202431.GB45709@elstar.local> Date: Fri, 26 Jul 2013 13:33:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5EAF1327-3118-4AF9-85FD-EF97B4013BE5@cisco.com> References: <9B6672F8-4718-49B3-A009-F0270BDEBF2F@cisco.com> <20130726043233.GB44013@elstar.local> <27F057BA-F248-4CAE-8FA0-88382F6BE78A@cisco.com> <20130726182033.GA45380@elstar.local> <20130726202431.GB45709@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1508) Cc: "behave@ietf.org" Subject: Re: [BEHAVE] walking RFC4008 (NAT MIB) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 20:34:11 -0000 On Jul 26, 2013, at 1:24 PM, Juergen Schoenwaelder = wrote: > On Fri, Jul 26, 2013 at 12:34:09PM -0700, Dan Wing wrote: >>=20 >> On Jul 26, 2013, at 11:20 AM, Juergen Schoenwaelder = wrote: >>=20 >>> On Fri, Jul 26, 2013 at 10:08:19AM -0700, Dan Wing wrote: >>>=20 >>>> Yes, thanks -- that would work if all the subscribers have unique >>>> natAddrBindLocalAddr (IP address). But it wouldn't work where the >>>> unique selector is something else, such as DS-Lite (where every >>>> subscriber could and will use the same IPv4 address, but different >>>> IPv6 tunnels), or NATs where VRF or VLAN are used as the subscriber >>>> identifier. Is there some other way RFC4008 could work for those >>>> cases of IPv6, VRF, VLAN being the subscriber identifier? >>>=20 >>> Do the DS-Lite tunnels not end at different tunnel interfaces? Same >>> for VLAN interfaces? >>=20 >> The SYSLOG and IPFIX logging documents are emitting VLAN and VRF = numbers, rather than tunnel interface numbers. =20 >>=20 >> SYSLOG logging example of its quota exceeded event, = http://tools.ietf.org/html/draft-ietf-behave-syslog-nat-logging-02#section= -3.6 >> IPFIX logging example of its vlanID and ingressVRFID, = http://tools.ietf.org/html/draft-ietf-behave-ipfix-nat-logging-00#page-6 >>=20 >=20 > This design limits things to VLANs and VRFs - back when the NAT-MIB > was created, an interface identifier as this makes things quite > generic - it works for any current and future interface type. But then > I am told NATs do not work this way anymore... Seems we should have consistency or, at minimum, a way to map = between/among them. -d >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From kaiduanx@gmail.com Fri Jul 26 06:42:59 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29E1421F88FB; Fri, 26 Jul 2013 06:42: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, HTML_MESSAGE=0.001, 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 dT2J9XPfMX6F; Fri, 26 Jul 2013 06:42:58 -0700 (PDT) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id DFED921F8793; Fri, 26 Jul 2013 06:42:57 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id q54so1852693wes.5 for ; Fri, 26 Jul 2013 06:42:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=th49Cr7NJWQ55YHFYkmT+pyoT5QPwLLqV+wzVVw8mIY=; b=Su75fsqClNA/bBWLrmlw7U3URsb+aJxi32n+3/x10k+fvDMn4sfVHcO30NlcSM5NyL gCq/20Fs/zNGAT+jhul64xSLp1FQBn9FO50H1DXuTdv/Wt1Kiwq+nTi2yCL4d36R6tQa REyaAErT9FpHhSY+e/iE5KigIdHlef5qvibdjos3wiVjycoSrxY6WXRDJIV+yoX31HaF gGBK2crKRNhIyP06ND0ZaTd6dccjgdU1XywBVpMub26tmw8KMEz1YX7p41Wq97NoYVDW kpBr5X6gjN15CKX8xGehgXEMmxMAh03YGOalMfiIL657YPBWMf3YqP5uSCcF9kpux/fO y5EQ== MIME-Version: 1.0 X-Received: by 10.180.211.171 with SMTP id nd11mr5796542wic.17.1374846177031; Fri, 26 Jul 2013 06:42:57 -0700 (PDT) Received: by 10.216.248.194 with HTTP; Fri, 26 Jul 2013 06:42:56 -0700 (PDT) In-Reply-To: References: <20130715214906.5314.83583.idtracker@ietfa.amsl.com> <51E70106.8060100@goodadvice.pages.de> <51ED9318.6000003@nostrum.com> <51ED9A3C.4060307@goodadvice.pages.de> Date: Fri, 26 Jul 2013 09:42:56 -0400 Message-ID: From: Kaiduan Xie To: Oleg Moskalenko Content-Type: multipart/alternative; boundary=001a11c3850000c0fa04e26a52cb X-Mailman-Approved-At: Sat, 27 Jul 2013 09:06:06 -0700 Cc: Rajmohan Banavi , "rtcweb@ietf.org" , behave Subject: Re: [BEHAVE] [rtcweb] Fwd: New Version Notification for draft-uberti-behave-turn-rest-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 13:42:59 -0000 --001a11c3850000c0fa04e26a52cb Content-Type: text/plain; charset=ISO-8859-1 Justin, I recommend you to put a note into the draft to state the following two points, 1) The user name and password are generated by the web server instead of the TURN server. 2) There is no communication channel required between web server and TURN server. >From the title (TURN Server REST API) and the text, it is easy to misunderstand that TURN server processes the HTTP POST request. Thanks, /Kaiduan On Wed, Jul 24, 2013 at 10:06 AM, Oleg Moskalenko wrote: > Thank you for the new link. > > I checked the new version of the draft and I personally see no problem in > the text. There is no proprietary software requirements in the draft. It > simply defines the logic how the TURN server and web server can organize > the temporary password generation, without imposing any proprietary > requirements and specs on the software. It is mentioning a possible > communication channel between web server and TURN server without defining > any specs and as it is written that channel is not required. As it is > written, I do not think that it has to be separated into two pieces - it is > a single solid logical functionality definition. > > Thanks > Oleg > > > On Wed, Jul 24, 2013 at 1:46 AM, Rajmohan Banavi > wrote: > >> This is the draft (BEHAVE WG) I am referring to - >> http://tools.ietf.org/html/draft-uberti-behave-turn-rest-00 >> >> >>> This is not the case. It is not the TURN server who generates the >>> credentials. The web server must generate the temporary password, and to be >>> able to do that the web server must have the shared secret - the same as >>> TURN server has. How they share the same shared secret I'd leave outside >>> the proposed specs. >>> >>> OK fine. >> >> >>> It is rather clear - the web server takes the shared secret and it >>> generates the temporary password for long-term TURN credentials. The TURN >>> server can reproduce that generation process and obtain the same temporary >>> password - because the TURN server knows the same shared secret as the web >>> server. >>> >> >> OK fine. >> >> Thanks, >> Rajmohan >> > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a11c3850000c0fa04e26a52cb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Justin,

I recommend you to put a = note into the draft to state the following two points,

1= ) The user name and password are generated by the web server instead of the= TURN server.

2) There is no communication channel required between w= eb server and TURN server.

From the title (TURN Se= rver REST API) and the text, it is easy to misunderstand that TURN server p= rocesses the HTTP POST request.

Thanks,

/Kaiduan<= br>
On Wed, Jul 24, 2013 at 10:06 AM, Oleg Mo= skalenko <mom040267@gmail.com> wrote:
Thank you for the= new link.

I checked the new version of the draft and I personally = see no problem in the text. There is no proprietary software requirements i= n the draft. It simply defines the logic how the TURN server and web server= can organize the temporary password generation, without imposing any propr= ietary requirements and specs on the software. It is mentioning a possible = communication channel between web server and TURN server without defining a= ny specs and as it is written that channel is not required. As it is writte= n, I do not think that it has to be separated into two pieces - it is a sin= gle solid logical functionality definition.

Thanks
<= /span>
Oleg
=


On Wed, Jul 24, 2013 at 1:46 AM, Rajmohan Banavi <rajmohanbanavi@gm= ail.com> wrote:
This is the draft (BEHAVE WG) I am referri= ng to -=A0http://tools.ietf.org/html/draft-uberti-behave-turn-rest-00=


This is not the case. It is not the TURN server who generat= es the credentials. The web server must generate the temporary password, an= d to be able to do that the web server must have the shared secret - the sa= me as TURN server has. How they share the same shared secret I'd leave = outside the proposed specs.

OK fin= e.
=A0
It is rather clear - the web server takes the shared secret and it generat= es the temporary password for long-term TURN credentials. The TURN server c= an reproduce that generation process and obtain the same temporary password= - because the TURN server knows the same shared secret as the web server.<= br>

<= /div>
OK fine.

Th= anks,
Rajmohan


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


--001a11c3850000c0fa04e26a52cb-- From dthaler@microsoft.com Sat Jul 27 10:17:31 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A103221F9AA1 for ; Sat, 27 Jul 2013 10:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.466 X-Spam-Level: X-Spam-Status: No, score=-99.466 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0TbbYdQcwPix for ; Sat, 27 Jul 2013 10:17:26 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0186.outbound.messaging.microsoft.com [213.199.154.186]) by ietfa.amsl.com (Postfix) with ESMTP id EE9F421F9AA3 for ; Sat, 27 Jul 2013 10:17:23 -0700 (PDT) Received: from mail140-db8-R.bigfish.com (10.174.8.229) by DB8EHSOBE015.bigfish.com (10.174.4.78) with Microsoft SMTP Server id 14.1.225.22; Sat, 27 Jul 2013 17:17:23 +0000 Received: from mail140-db8 (localhost [127.0.0.1]) by mail140-db8-R.bigfish.com (Postfix) with ESMTP id D2A151C007D for ; Sat, 27 Jul 2013 17:17:22 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:autodiscover.service.exchange.microsoft.com; EFVD:NLI X-SpamScore: -21 X-BigFish: VS-21(zz98dI9371Ic85fh1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hz97hz1d7338h1de098h1033IL17326ah18c673h1de096h8275bh8275dh1de097hz2fh2a8h683h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1b0ah1bceh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh9a9j1155h) Received-SPF: pass (mail140-db8: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14MLTC102.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT002.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail140-db8 (localhost.localdomain [127.0.0.1]) by mail140-db8 (MessageSwitch) id 1374945440566928_1846; Sat, 27 Jul 2013 17:17:20 +0000 (UTC) Received: from DB8EHSMHS022.bigfish.com (unknown [10.174.8.245]) by mail140-db8.bigfish.com (Postfix) with ESMTP id 7B299180048 for ; Sat, 27 Jul 2013 17:17:20 +0000 (UTC) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.8) by DB8EHSMHS022.bigfish.com (10.174.4.32) with Microsoft SMTP Server (TLS) id 14.16.227.3; Sat, 27 Jul 2013 17:17:20 +0000 Received: from DB8EHSOBE038.bigfish.com (157.54.51.114) by mail.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.3.136.1; Sat, 27 Jul 2013 17:17:01 +0000 Received: from mail174-db8-R.bigfish.com (10.174.8.239) by DB8EHSOBE038.bigfish.com (10.174.4.101) with Microsoft SMTP Server id 14.1.225.22; Sat, 27 Jul 2013 17:16:59 +0000 Received: from mail174-db8 (localhost [127.0.0.1]) by mail174-db8-R.bigfish.com (Postfix) with ESMTP id 6A1381001E5 for ; Sat, 27 Jul 2013 17:16:59 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(377454003)(24454002)(199002)(189002)(51704005)(65816001)(74502001)(80022001)(66066001)(49866001)(83072001)(15202345003)(47736001)(16406001)(47446002)(1511001)(19580405001)(63696002)(19580385001)(33646001)(77096001)(50986001)(47976001)(83322001)(19300405004)(76576001)(74662001)(56816003)(31966008)(79102001)(76786001)(76796001)(19580395003)(54356001)(56776001)(77982001)(59766001)(54316002)(51856001)(46102001)(81542001)(76482001)(16236675002)(81342001)(74706001)(53806001)(4396001)(74876001)(74316001)(74366001)(69226001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB272; H:BY2PR03MB269.namprd03.prod.outlook.com; CLIP:130.129.71.101; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail174-db8 (localhost.localdomain [127.0.0.1]) by mail174-db8 (MessageSwitch) id 1374945417653450_1481; Sat, 27 Jul 2013 17:16:57 +0000 (UTC) Received: from DB8EHSMHS003.bigfish.com (unknown [10.174.8.229]) by mail174-db8.bigfish.com (Postfix) with ESMTP id 9B5B2E0246; Sat, 27 Jul 2013 17:16:57 +0000 (UTC) Received: from BL2PRD0310HT002.namprd03.prod.outlook.com (157.56.240.21) by DB8EHSMHS003.bigfish.com (10.174.4.13) with Microsoft SMTP Server (TLS) id 14.16.227.3; Sat, 27 Jul 2013 17:16:57 +0000 Received: from BY2PR03MB272.namprd03.prod.outlook.com (10.242.37.24) by BL2PRD0310HT002.namprd03.prod.outlook.com (10.255.97.37) with Microsoft SMTP Server (TLS) id 14.16.341.1; Sat, 27 Jul 2013 17:16:57 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com (10.242.37.11) by BY2PR03MB272.namprd03.prod.outlook.com (10.242.37.24) with Microsoft SMTP Server (TLS) id 15.0.731.11; Sat, 27 Jul 2013 17:16:48 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.171]) by BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.234]) with mapi id 15.00.0731.000; Sat, 27 Jul 2013 17:16:41 +0000 From: Dave Thaler To: Dave Thaler , "behave@ietf.org" Thread-Topic: Consensus call regarding nat-mib Thread-Index: Ac6IpoQ9/9IdQ+rFR36+IHgpReQ81QCRd3gg Date: Sat, 27 Jul 2013 17:16:40 +0000 Message-ID: References: <25e5cbb559ce438c9b419e20200f890a@BN1PR03MB267.namprd03.prod.outlook.com> In-Reply-To: <25e5cbb559ce438c9b419e20200f890a@BN1PR03MB267.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.129.71.101] x-forefront-prvs: 0920602B08 Content-Type: multipart/alternative; boundary="_000_a23e33ab5c434f1ab93b7ee090e667b9BY2PR03MB269namprd03pro_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: BY2PR03MB272.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%JACOBS-UNIVERSITY.DE$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14MLTC102.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14MLTC102.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: Juergen Schoenwaelder Subject: Re: [BEHAVE] Consensus call regarding nat-mib X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jul 2013 17:17:31 -0000 --_000_a23e33ab5c434f1ab93b7ee090e667b9BY2PR03MB269namprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I read through the entire document with this question in mind. In short I = believe that much, but not all, of RFC 4008 is flawed. The difference comes down to th= e definition of "flawed". It's applicable to certain types of NATs but not all NATs. As such it's no= t flawed if there's a separate compliance statement for such types of NATs. I think the current approach= of including all objects from RFC 4008 in an update to the RFC is the approach I prefer. In doing this read through, I have a number of other technical issues, whic= h I will put into a separate thread. -Dave From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of= Dave Thaler Sent: Wednesday, July 24, 2013 9:54 PM To: behave@ietf.org Cc: Juergen Schoenwaelder Subject: [BEHAVE] Consensus call regarding nat-mib > Simon wrote: >> Our position, and we feel we have the consensus of the WG with us, is >> that the existing NAT-MIB is fatally flawed and we need a complete >> replacement. The reasons are explained in section 3.1. >> https://tools.ietf.org/html/draft-ietf-behave-nat-mib-06#section-3.1 >> >> That's why we initially started with a brand new MIB, called the >> NEW-NAT-MIB. We changed into the current structure based on feedback >> from the working group in general and Juergen in particular. > > Juergen responded: >> As far as I recall, it was initially not clear whether there is >> consensus that the NAT-MIB is fatally flawed. (And the text that is >> now in section >> 3.1 did not exist at that time in the current level of detail as far >> as I recall.) >> >> I suggest a consensus call is made by the chairs on this fundamental >> question. If there is consensus that the NAT-MIB is fatally flawed >> (and note that opinions of implementors in particular matter here), >> then declaring the MIB module in RFC 4008 historic (e.g. marking RFC >> 4008 historic) and creating a new MIB module may indeed be the right >> thing to do. I believe we've heard from many folks that RFC 4008 is not appropriate for carrier-grade NATs. The authors of draft-ietf-behave-nat-mib have put the reasons into section 3.1 as noted above. However, the chairs discussed Juergen's request and are fine asking for confirmation of this point. This email asks for confirmation of the posit= ion that "RFC 4008 should be historic and a new MIB module is needed" for all NATs (to cover both CGNs and non-CGNs). If you have an opinion on this matter, please respond with "Agree" (and state reason if it doesn't already appear in section 3.1) or "Object: ". Please respond before the WG meeting in Berlin. -Dave and Dan --_000_a23e33ab5c434f1ab93b7ee090e667b9BY2PR03MB269namprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

<personal opinion, = no hats>

I read through the ent= ire document with this question in mind.  In short I believe that=

much, but not all, of = RFC 4008 is flawed.   The difference comes down to the definition= of “flawed”.

It’s applicable = to certain types of NATs but not all NATs.  As such it’s not fla= wed if there’s a separate

compliance statement f= or such types of NATs.   I think the current approach of includin= g all objects

from RFC 4008 in an up= date to the RFC is the approach I prefer.

 

In doing this read thr= ough, I have a number of other technical issues, which I will put into a se= parate thread.

 

-Dave

 

From: behave-bounces@ietf.org [mailto:behave-= bounces@ietf.org] On Behalf Of Dave Thaler
Sent: Wednesday, July 24, 2013 9:54 PM
To: behave@ietf.org
Cc: Juergen Schoenwaelder
Subject: [BEHAVE] Consensus call regarding nat-mib

 

> Simon wrote:

>> Our position, and we feel we have the co= nsensus of the WG with us, is

>> that the existing NAT-MIB is fatally fla= wed and we need a complete

>> replacement. The reasons are explained i= n section 3.1.

>> https://tools.ietf.org/html/draft-ietf-behave-nat-mib-06#section-3.1

>>

>> That's why we initially started with a b= rand new MIB, called the

>> NEW-NAT-MIB. We changed into the current= structure based on feedback

>> from the working group in general and Ju= ergen in particular.

>

> Juergen responded:

>> As far as I recall, it was initially not= clear whether there is

>> consensus that the NAT-MIB is fatally fl= awed. (And the text that is

>> now in section

>> 3.1 did not exist at that time in the cu= rrent level of detail as far

>> as I recall.)

>>

>> I suggest a consensus call is made by th= e chairs on this fundamental

>> question. If there is consensus that the= NAT-MIB is fatally flawed

>> (and note that opinions of implementors = in particular matter here),

>> then declaring the MIB module in RFC 400= 8 historic (e.g. marking RFC

>> 4008 historic) and creating a new MIB mo= dule may indeed be the right

>> thing to do.

 

I believe we’ve heard from many folks that = RFC 4008 is not appropriate

for carrier-grade NATs.  The authors of draf= t-ietf-behave-nat-mib have

put the reasons into section 3.1 as noted above.<= o:p>

 

However, the chairs discussed Juergen’s req= uest and are fine asking for

confirmation of this point.   This emai= l asks for confirmation of the position

that “RFC 4008 should be historic and a new= MIB module is needed” for all

NATs (to cover both CGNs and non-CGNs).

 

If you have an opinion on this matter, please res= pond with “Agree”

(and state reason if it doesn’t already app= ear in section 3.1) or

“Object: <state reason>”.<= /o:p>

 

Please respond before the WG meeting in Berlin.=

 

-Dave and Dan

--_000_a23e33ab5c434f1ab93b7ee090e667b9BY2PR03MB269namprd03pro_-- From dthaler@microsoft.com Sat Jul 27 10:25:15 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADFAF21F9A97 for ; Sat, 27 Jul 2013 10:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.166 X-Spam-Level: X-Spam-Status: No, score=-100.166 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OEP4xWQfV5vl for ; Sat, 27 Jul 2013 10:25:09 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id D524821F9A1E for ; Sat, 27 Jul 2013 10:25:08 -0700 (PDT) Received: from mail7-tx2-R.bigfish.com (10.9.14.240) by TX2EHSOBE006.bigfish.com (10.9.40.26) with Microsoft SMTP Server id 14.1.225.22; Sat, 27 Jul 2013 17:25:07 +0000 Received: from mail7-tx2 (localhost [127.0.0.1]) by mail7-tx2-R.bigfish.com (Postfix) with ESMTP id BC24A4400E4 for ; Sat, 27 Jul 2013 17:25:07 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:autodiscover.service.exchange.microsoft.com; EFVD:NLI X-SpamScore: -6 X-BigFish: VS-6(zzc85fhdb82hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1d7338h17326ah18c673h186M1de096h5eeeK8275bh8275dh1de097hz2fh2a8h683h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1b0ah1bceh1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh9a9j1155h) Received-SPF: pass (mail7-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14HUBC107.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT001.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail7-tx2 (localhost.localdomain [127.0.0.1]) by mail7-tx2 (MessageSwitch) id 1374945905453886_3165; Sat, 27 Jul 2013 17:25:05 +0000 (UTC) Received: from TX2EHSMHS022.bigfish.com (unknown [10.9.14.249]) by mail7-tx2.bigfish.com (Postfix) with ESMTP id 609CE2C0046 for ; Sat, 27 Jul 2013 17:25:05 +0000 (UTC) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS022.bigfish.com (10.9.99.122) with Microsoft SMTP Server (TLS) id 14.16.227.3; Sat, 27 Jul 2013 17:25:05 +0000 Received: from ch1outboundpool.messaging.microsoft.com (157.54.51.113) by mail.microsoft.com (157.54.80.67) with Microsoft SMTP Server (TLS) id 14.3.136.1; Sat, 27 Jul 2013 17:24:48 +0000 Received: from mail42-ch1-R.bigfish.com (10.43.68.245) by CH1EHSOBE009.bigfish.com (10.43.70.59) with Microsoft SMTP Server id 14.1.225.22; Sat, 27 Jul 2013 17:24:46 +0000 Received: from mail42-ch1 (localhost [127.0.0.1]) by mail42-ch1-R.bigfish.com (Postfix) with ESMTP id CE0EE2C02C0 for ; Sat, 27 Jul 2013 17:24:46 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(243025003)(189002)(199002)(51856001)(53806001)(66066001)(47736001)(561944002)(74366001)(80022001)(65816001)(81542001)(50986001)(81342001)(19300405004)(47976001)(49866001)(74316001)(69226001)(83322001)(74662001)(56816003)(19580395003)(56776001)(54356001)(77096001)(33646001)(76482001)(74502001)(76176001)(76796001)(4396001)(83072001)(54316002)(74876001)(19580385001)(47446002)(16236675002)(63696002)(74706001)(16406001)(15202345003)(76786001)(79102001)(77982001)(59766001)(46102001)(76576001)(31966008)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB269; H:BY2PR03MB269.namprd03.prod.outlook.com; CLIP:130.129.71.101; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail42-ch1 (localhost.localdomain [127.0.0.1]) by mail42-ch1 (MessageSwitch) id 1374945883822875_28916; Sat, 27 Jul 2013 17:24:43 +0000 (UTC) Received: from CH1EHSMHS011.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.232]) by mail42-ch1.bigfish.com (Postfix) with ESMTP id C35FE16004A; Sat, 27 Jul 2013 17:24:43 +0000 (UTC) Received: from BL2PRD0310HT001.namprd03.prod.outlook.com (157.56.240.21) by CH1EHSMHS011.bigfish.com (10.43.70.11) with Microsoft SMTP Server (TLS) id 14.16.227.3; Sat, 27 Jul 2013 17:24:43 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com (10.242.37.11) by BL2PRD0310HT001.namprd03.prod.outlook.com (10.255.97.36) with Microsoft SMTP Server (TLS) id 14.16.341.1; Sat, 27 Jul 2013 17:24:43 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com (10.242.37.11) by BY2PR03MB269.namprd03.prod.outlook.com (10.242.37.11) with Microsoft SMTP Server (TLS) id 15.0.731.11; Sat, 27 Jul 2013 17:24:40 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.171]) by BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.234]) with mapi id 15.00.0731.000; Sat, 27 Jul 2013 17:24:40 +0000 From: Dave Thaler To: "draft-ietf-behave-nat-mib@tools.ietf.org" Thread-Topic: Comments on draft-ietf-behave-nat-mib-07 Thread-Index: Ac6K7TuYIeG10oPDT4KnQMenb0X6jA== Date: Sat, 27 Jul 2013 17:24:39 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.129.71.101] x-forefront-prvs: 0920602B08 Content-Type: multipart/alternative; boundary="_000_f13b541d70c04f6d9b985cf61e30f9f2BY2PR03MB269namprd03pro_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: BY2PR03MB269.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%TOOLS.IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC107.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC107.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "behave@ietf.org" Subject: [BEHAVE] Comments on draft-ietf-behave-nat-mib-07 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jul 2013 17:25:15 -0000 --_000_f13b541d70c04f6d9b985cf61e30f9f2BY2PR03MB269namprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A marked up copy with my comments (including editorial items not mentioned = here) is at http://research.microsoft.com/~dthaler/draft-ietf-behave-nat-mib-07.pdf (or replace .pdf with .docx for a docx version). A list of the key technical issues follows: 1. Section 3.1 does not contain sufficient justification to deprecate= all the objects it deprecates. It does contain justification for making s= ome be in separate conformance groups, but if we want to deprecate all of t= hem, we need better justification. 2. Section 3.1 argues that writability and exposing configuration par= ameters is bad. The document then goes on to define new writable configura= tion parameters without explanation. Furthermore, some of them appear ques= tionable for exactly the reasons pointed out in section 3.1. 3. The relationship between using the NAT MIB for logging/eventing/n= otifications vs using IPFIX or SYSLOG for such is unclear. The chairs direc= ted that IPFIX and SYSLOG must be consistent (or any inconsistency explaine= d and agreed on). This same requirement should apply to any other logging= /eventing/notification proposals including SNMP. Personally I would prefer = not using SNMP for notifications. 4. The natCntProtocolTable was added without any explanation of what = management question it would answer. Why would the question be global and = not (say) per-realm? 5. The compliance statements and conformance groups assume all NATs a= re stateful. They aren't. This is labeled the "NAT MIB", not the "statef= ul NAT MIB", and so should cover applicability to stateless-only NATs too. 6. The MIB (e.g. NatMapIntAddrTable) assumes there's an "external" ad= dress. That's not a safe assumption, a NAT can be nat'ing between two inte= rnal realms. 7. The subscriber table is indexed with a single address and doesn't = seem to work for subscribers with multiple addresses/prefixes (e.g. IPv4 an= d IPv6). 8. Objects relating to quotas (e.g. natCntQuota, watermarks, etc) sho= uld be in CGN-specific conformance groups, not the basic ones required for = all NATs. -Dave --_000_f13b541d70c04f6d9b985cf61e30f9f2BY2PR03MB269namprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

A marked up copy with my comments (including editori= al items not mentioned here) is at

http://research.microsoft.com/~dthaler/draf= t-ietf-behave-nat-mib-07.pdf

(or replace .pdf with .docx for a docx version).

 

A list of the key technical issues follows:

 

1.     &= nbsp; Section 3.1 does not contain sufficient justificati= on to deprecate all the objects it deprecates.  It does contain justif= ication for making some be in separate conformance groups, but if we want t= o deprecate all of them, we need better justification.

2.     &= nbsp; Section 3.1 argues that writability and exposing co= nfiguration parameters is bad.  The document then goes on to define ne= w writable configuration parameters without explanation.  Furthermore,= some of them appear questionable for exactly the reasons pointed out in section 3.1.

3.     &= nbsp; The relationship between using  the NAT MIB fo= r logging/eventing/notifications vs using IPFIX or SYSLOG for such is uncle= ar. The chairs directed that IPFIX and SYSLOG must be consistent (or any in= consistency explained and agreed on).   This same requirement should apply to any other logging/eventing/notificat= ion proposals including SNMP. Personally I would prefer not using SNMP for = notifications.

4.     &= nbsp; The natCntProtocolTable was added without any expla= nation of what management question it would answer.  Why would the que= stion be global and not (say) per-realm?

5.     &= nbsp; The compliance statements and conformance groups as= sume all NATs are stateful.  They aren’t.   This is la= beled the “NAT MIB”, not the “stateful NAT MIB”, an= d so should cover applicability to stateless-only NATs too.

6.     &= nbsp; The MIB (e.g. NatMapIntAddrTable) assumes thereR= 17;s an “external” address.  That’s not a safe assum= ption, a NAT can be nat’ing between two internal realms.

7.     &= nbsp; The subscriber table is indexed with a single addre= ss and doesn’t seem to work for subscribers with multiple addresses/p= refixes (e.g. IPv4 and IPv6).

8.     &= nbsp; Objects relating to quotas (e.g. natCntQuota, water= marks, etc) should be in CGN-specific conformance groups, not the basic one= s required for all NATs.

 

-Dave

--_000_f13b541d70c04f6d9b985cf61e30f9f2BY2PR03MB269namprd03pro_-- From dthaler@microsoft.com Sat Jul 27 10:31:46 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B68021E8051 for ; Sat, 27 Jul 2013 10:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.516 X-Spam-Level: X-Spam-Status: No, score=-98.516 tagged_above=-999 required=5 tests=[AWL=-1.650, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZ2grVH98LWE for ; Sat, 27 Jul 2013 10:31:39 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0185.outbound.messaging.microsoft.com [213.199.154.185]) by ietfa.amsl.com (Postfix) with ESMTP id 0476B21E804E for ; Sat, 27 Jul 2013 10:31:39 -0700 (PDT) Received: from mail128-db8-R.bigfish.com (10.174.8.231) by DB8EHSOBE026.bigfish.com (10.174.4.89) with Microsoft SMTP Server id 14.1.225.22; Sat, 27 Jul 2013 17:31:38 +0000 Received: from mail128-db8 (localhost [127.0.0.1]) by mail128-db8-R.bigfish.com (Postfix) with ESMTP id 239031601CD for ; Sat, 27 Jul 2013 17:31:38 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:autodiscover.service.exchange.microsoft.com; EFVD:NLI X-SpamScore: -27 X-BigFish: VS-27(zz9371Ic85fhdb82hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1d7338h1de098h1033IL17326ah18c673h186M1de096h5eeeK8275bh8275dh1de097hz2fh2a8h683h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1b0ah1bceh1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh9a9j1155h) Received-SPF: pass (mail128-db8: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14HUBC102.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT001.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail128-db8 (localhost.localdomain [127.0.0.1]) by mail128-db8 (MessageSwitch) id 1374946296535201_4761; Sat, 27 Jul 2013 17:31:36 +0000 (UTC) Received: from DB8EHSMHS018.bigfish.com (unknown [10.174.8.251]) by mail128-db8.bigfish.com (Postfix) with ESMTP id 7D0A44E0046 for ; Sat, 27 Jul 2013 17:31:36 +0000 (UTC) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.8) by DB8EHSMHS018.bigfish.com (10.174.4.28) with Microsoft SMTP Server (TLS) id 14.16.227.3; Sat, 27 Jul 2013 17:31:35 +0000 Received: from va3outboundpool.messaging.microsoft.com (157.54.51.80) by mail.microsoft.com (157.54.7.154) with Microsoft SMTP Server (TLS) id 14.3.136.1; Sat, 27 Jul 2013 17:29:33 +0000 Received: from mail230-va3-R.bigfish.com (10.7.14.249) by VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id 14.1.225.22; Sat, 27 Jul 2013 17:29:31 +0000 Received: from mail230-va3 (localhost [127.0.0.1]) by mail230-va3-R.bigfish.com (Postfix) with ESMTP id BB3A4700629 for ; Sat, 27 Jul 2013 17:29:31 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(243025003)(189002)(199002)(377454003)(59766001)(19580395003)(561944002)(76482001)(15202345003)(19580405001)(19580385001)(80022001)(56776001)(77096001)(76576001)(77982001)(83322001)(54356001)(54316002)(56816003)(16236675002)(53806001)(83072001)(74316001)(79102001)(65816001)(76786001)(66066001)(63696002)(50986001)(4396001)(69226001)(76796001)(47736001)(16406001)(31966008)(49866001)(46102001)(74502001)(74706001)(74876001)(51856001)(74366001)(19300405004)(47446002)(74662001)(81342001)(47976001)(33646001)(76176001)(81542001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB270; H:BY2PR03MB269.namprd03.prod.outlook.com; CLIP:130.129.71.101; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail230-va3 (localhost.localdomain [127.0.0.1]) by mail230-va3 (MessageSwitch) id 1374946168770677_27226; Sat, 27 Jul 2013 17:29:28 +0000 (UTC) Received: from VA3EHSMHS041.bigfish.com (unknown [10.7.14.249]) by mail230-va3.bigfish.com (Postfix) with ESMTP id B8CE23A025B; Sat, 27 Jul 2013 17:29:28 +0000 (UTC) Received: from BL2PRD0310HT001.namprd03.prod.outlook.com (157.56.240.21) by VA3EHSMHS041.bigfish.com (10.7.99.51) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 27 Jul 2013 17:29:26 +0000 Received: from BY2PR03MB270.namprd03.prod.outlook.com (10.242.37.12) by BL2PRD0310HT001.namprd03.prod.outlook.com (10.255.97.36) with Microsoft SMTP Server (TLS) id 14.16.341.1; Sat, 27 Jul 2013 17:29:26 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com (10.242.37.11) by BY2PR03MB270.namprd03.prod.outlook.com (10.242.37.12) with Microsoft SMTP Server (TLS) id 15.0.731.11; Sat, 27 Jul 2013 17:29:17 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.171]) by BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.234]) with mapi id 15.00.0731.000; Sat, 27 Jul 2013 17:29:17 +0000 From: Dave Thaler To: "draft-ietf-behave-nat-mib@tools.ietf.org" Thread-Topic: Comments on draft-ietf-behave-nat-mib-07 Thread-Index: Ac6K7TuYIeG10oPDT4KnQMenb0X6jAAATe7A Date: Sat, 27 Jul 2013 17:29:17 +0000 Message-ID: <26179c30a79d4c6d9ac5faf54d049796@BY2PR03MB269.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.129.71.101] x-forefront-prvs: 0920602B08 Content-Type: multipart/alternative; boundary="_000_26179c30a79d4c6d9ac5faf54d049796BY2PR03MB269namprd03pro_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: BY2PR03MB270.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%TOOLS.IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC102.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC102.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "behave@ietf.org" Subject: Re: [BEHAVE] Comments on draft-ietf-behave-nat-mib-07 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jul 2013 17:31:46 -0000 --_000_26179c30a79d4c6d9ac5faf54d049796BY2PR03MB269namprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On issue #2, my preferred resolution is that the document should expose (on= ly) configuration parameters that are required by other RFCs and WG documen= ts, and that the text in 3.1 should be updated accordingly. I note that th= e Syslog document currently has required configuration parameters that are = not exposed in the NAT MIB. The two documents should be consistent in my v= iew. Various other resolutions would also be acceptable, but above is the one I'= d recommend. -Dave From: Dave Thaler Sent: Saturday, July 27, 2013 7:25 PM To: draft-ietf-behave-nat-mib@tools.ietf.org Cc: behave@ietf.org Subject: Comments on draft-ietf-behave-nat-mib-07 A marked up copy with my comments (including editorial items not mentioned = here) is at http://research.microsoft.com/~dthaler/draft-ietf-behave-nat-mib-07.pdf (or replace .pdf with .docx for a docx version). A list of the key technical issues follows: 1. Section 3.1 does not contain sufficient justification to deprecate= all the objects it deprecates. It does contain justification for making s= ome be in separate conformance groups, but if we want to deprecate all of t= hem, we need better justification. 2. Section 3.1 argues that writability and exposing configuration par= ameters is bad. The document then goes on to define new writable configura= tion parameters without explanation. Furthermore, some of them appear ques= tionable for exactly the reasons pointed out in section 3.1. 3. The relationship between using the NAT MIB for logging/eventing/n= otifications vs using IPFIX or SYSLOG for such is unclear. The chairs direc= ted that IPFIX and SYSLOG must be consistent (or any inconsistency explaine= d and agreed on). This same requirement should apply to any other logging= /eventing/notification proposals including SNMP. Personally I would prefer = not using SNMP for notifications. 4. The natCntProtocolTable was added without any explanation of what = management question it would answer. Why would the question be global and = not (say) per-realm? 5. The compliance statements and conformance groups assume all NATs a= re stateful. They aren't. This is labeled the "NAT MIB", not the "statef= ul NAT MIB", and so should cover applicability to stateless-only NATs too. 6. The MIB (e.g. NatMapIntAddrTable) assumes there's an "external" ad= dress. That's not a safe assumption, a NAT can be nat'ing between two inte= rnal realms. 7. The subscriber table is indexed with a single address and doesn't = seem to work for subscribers with multiple addresses/prefixes (e.g. IPv4 an= d IPv6). 8. Objects relating to quotas (e.g. natCntQuota, watermarks, etc) sho= uld be in CGN-specific conformance groups, not the basic ones required for = all NATs. -Dave --_000_26179c30a79d4c6d9ac5faf54d049796BY2PR03MB269namprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

On issue #2, my prefer= red resolution is that the document should expose (only) configuration para= meters that are required by other RFCs and WG documents, and that the text = in 3.1 should be updated accordingly.  I note that the Syslog document currently has required configuration param= eters that are not exposed in the NAT MIB.  The two documents should b= e consistent in my view.

 

Various other resoluti= ons would also be acceptable, but above is the one I’d recommend.

 

-Dave

 

From: Dave Thaler
Sent: Saturday, July 27, 2013 7:25 PM
To: draft-ietf-behave-nat-mib@tools.ietf.org
Cc: behave@ietf.org
Subject: Comments on draft-ietf-behave-nat-mib-07

 

A marked up copy with my comments (including editori= al items not mentioned here) is at

http://research.microsoft.com/~dthaler/draf= t-ietf-behave-nat-mib-07.pdf

(or replace .pdf with .docx for a docx version).

 

A list of the key technical issues follows:

 

1.     &= nbsp; Section 3.1 does not contain sufficient justificati= on to deprecate all the objects it deprecates.  It does contain justif= ication for making some be in separate conformance groups, but if we want t= o deprecate all of them, we need better justification.

2.     &= nbsp; Section 3.1 argues that writability and exposing co= nfiguration parameters is bad.  The document then goes on to define ne= w writable configuration parameters without explanation.  Furthermore,= some of them appear questionable for exactly the reasons pointed out in section 3.1.

3.     &= nbsp; The relationship between using  the NAT MIB fo= r logging/eventing/notifications vs using IPFIX or SYSLOG for such is uncle= ar. The chairs directed that IPFIX and SYSLOG must be consistent (or any in= consistency explained and agreed on).   This same requirement should apply to any other logging/eventing/notificat= ion proposals including SNMP. Personally I would prefer not using SNMP for = notifications.

4.     &= nbsp; The natCntProtocolTable was added without any expla= nation of what management question it would answer.  Why would the que= stion be global and not (say) per-realm?

5.     &= nbsp; The compliance statements and conformance groups as= sume all NATs are stateful.  They aren’t.   This is la= beled the “NAT MIB”, not the “stateful NAT MIB”, an= d so should cover applicability to stateless-only NATs too.

6.     &= nbsp; The MIB (e.g. NatMapIntAddrTable) assumes thereR= 17;s an “external” address.  That’s not a safe assum= ption, a NAT can be nat’ing between two internal realms.

7.     &= nbsp; The subscriber table is indexed with a single addre= ss and doesn’t seem to work for subscribers with multiple addresses/p= refixes (e.g. IPv4 and IPv6).

8.     &= nbsp; Objects relating to quotas (e.g. natCntQuota, water= marks, etc) should be in CGN-specific conformance groups, not the basic one= s required for all NATs.

 

-Dave

--_000_26179c30a79d4c6d9ac5faf54d049796BY2PR03MB269namprd03pro_-- From dthaler@microsoft.com Sat Jul 27 10:47:27 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA6CD11E80DE for ; Sat, 27 Jul 2013 10:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.466 X-Spam-Level: X-Spam-Status: No, score=-100.466 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g23URPK5-4Iv for ; Sat, 27 Jul 2013 10:47:21 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id 5960021E805A for ; Sat, 27 Jul 2013 10:47:13 -0700 (PDT) Received: from mail56-tx2-R.bigfish.com (10.9.14.233) by TX2EHSOBE014.bigfish.com (10.9.40.34) with Microsoft SMTP Server id 14.1.225.22; Sat, 27 Jul 2013 17:47:12 +0000 Received: from mail56-tx2 (localhost [127.0.0.1]) by mail56-tx2-R.bigfish.com (Postfix) with ESMTP id 96B133C00BC for ; Sat, 27 Jul 2013 17:47:12 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:autodiscover.service.exchange.microsoft.com; EFVD:NLI X-SpamScore: -8 X-BigFish: VS-8(zz1b0aLc85fhzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1d7338h17326ah18c673h186M1de096h5eeeK8275bh8275dh1de097hz2fh2a8h683h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh17ej9a9j1155h) Received-SPF: pass (mail56-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14MLTC103.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT002.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail56-tx2 (localhost.localdomain [127.0.0.1]) by mail56-tx2 (MessageSwitch) id 1374947229867655_341; Sat, 27 Jul 2013 17:47:09 +0000 (UTC) Received: from TX2EHSMHS038.bigfish.com (unknown [10.9.14.251]) by mail56-tx2.bigfish.com (Postfix) with ESMTP id C9230120047 for ; Sat, 27 Jul 2013 17:47:09 +0000 (UTC) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS038.bigfish.com (10.9.99.138) with Microsoft SMTP Server (TLS) id 14.16.227.3; Sat, 27 Jul 2013 17:47:09 +0000 Received: from DB8EHSOBE034.bigfish.com (157.54.51.113) by mail.microsoft.com (157.54.79.174) with Microsoft SMTP Server (TLS) id 14.3.136.1; Sat, 27 Jul 2013 17:46:33 +0000 Received: from mail111-db8-R.bigfish.com (10.174.8.252) by DB8EHSOBE034.bigfish.com (10.174.4.97) with Microsoft SMTP Server id 14.1.225.22; Sat, 27 Jul 2013 17:46:31 +0000 Received: from mail111-db8 (localhost [127.0.0.1]) by mail111-db8-R.bigfish.com (Postfix) with ESMTP id 154892A02FD for ; Sat, 27 Jul 2013 17:46:31 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(69224002)(189002)(199002)(243025003)(65816001)(74502001)(80022001)(49866001)(83072001)(15202345003)(47736001)(16406001)(47446002)(63696002)(19580385001)(33646001)(77096001)(50986001)(47976001)(19300405004)(83322001)(76576001)(74662001)(76176001)(56816003)(31966008)(79102001)(76786001)(76796001)(19580395003)(54356001)(56776001)(77982001)(59766001)(54316002)(51856001)(46102001)(81542001)(76482001)(16236675002)(81342001)(74706001)(53806001)(4396001)(74876001)(74316001)(74366001)(69226001)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB272; H:BY2PR03MB269.namprd03.prod.outlook.com; CLIP:2001:df8:0:64:ad8b:1daa:4db9:e67d; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail111-db8 (localhost.localdomain [127.0.0.1]) by mail111-db8 (MessageSwitch) id 1374947188586467_32749; Sat, 27 Jul 2013 17:46:28 +0000 (UTC) Received: from DB8EHSMHS010.bigfish.com (unknown [10.174.8.250]) by mail111-db8.bigfish.com (Postfix) with ESMTP id 80B4E20049; Sat, 27 Jul 2013 17:46:28 +0000 (UTC) Received: from BL2PRD0310HT002.namprd03.prod.outlook.com (157.56.240.21) by DB8EHSMHS010.bigfish.com (10.174.4.20) with Microsoft SMTP Server (TLS) id 14.16.227.3; Sat, 27 Jul 2013 17:46:28 +0000 Received: from BY2PR03MB272.namprd03.prod.outlook.com (10.242.37.24) by BL2PRD0310HT002.namprd03.prod.outlook.com (10.255.97.37) with Microsoft SMTP Server (TLS) id 14.16.341.1; Sat, 27 Jul 2013 17:46:24 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com (10.242.37.11) by BY2PR03MB272.namprd03.prod.outlook.com (10.242.37.24) with Microsoft SMTP Server (TLS) id 15.0.731.11; Sat, 27 Jul 2013 17:45:54 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.171]) by BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.234]) with mapi id 15.00.0731.000; Sat, 27 Jul 2013 17:45:54 +0000 From: Dave Thaler To: "draft-ietf-behave-syslog-nat-logging@tools.ietf.org" Thread-Topic: Comments on draft-ietf-behave-syslog-nat-logging-02 Thread-Index: Ac6K7u3YV03+dpQNTW2umngN57YqSw== Date: Sat, 27 Jul 2013 17:45:53 +0000 Message-ID: <9c6e4d956a264bd781bb66a412e5cce3@BY2PR03MB269.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:df8:0:64:ad8b:1daa:4db9:e67d] x-forefront-prvs: 0920602B08 Content-Type: multipart/alternative; boundary="_000_9c6e4d956a264bd781bb66a412e5cce3BY2PR03MB269namprd03pro_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: BY2PR03MB272.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%TOOLS.IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14MLTC103.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14MLTC103.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "behave@ietf.org" Subject: [BEHAVE] Comments on draft-ietf-behave-syslog-nat-logging-02 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jul 2013 17:47:27 -0000 --_000_9c6e4d956a264bd781bb66a412e5cce3BY2PR03MB269namprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Of the 10 documents I read while traveling to Berlin, this one was the long= est, but also probably the easiest to read and most well written in my opinion, so t= hanks for all the work put into this recently! A summary of my technical comments follows. 1. The syslog doc and the NAT MIB are not currently aligned. The NAT MIB has low/high watermark objects for one type of notification (which I think is a good approach), but it appears to only affect SNMP noti= fications not Syslog notifications. The syslog doc requires rate limiting various t= hings, with required knobs that are not in the NAT MIB. And the syslog doesn't recommend low/high watermarks but probably should, as I think it's currentl= y underspecified. 2. The use of UTF-8 strings for identifiers needs clarification. Is = non-ASCII really required? If so, what normalization form? Any constraints on set of lega= l characters? What are the uniqueness requirements? E.g., is it ok to have two values that differ only in normalization form? What about differing in case? What about being visually identical/confusable? 3. The document assumes a single "internal" and a single "external" r= ealm. This Is not a safe assumption in general, and especially not in scenarios like "An IPv4 Network to An IPv6 Network" and vice versa, where there could be (for instance) 2 internal realms and 0 external realms. Furthermore, th= e terms are ambiguous. For example in the "IPv6 Internet to An IPv4 Network" scenario where sessions are initiated from the Internet, which side is "external"? 4. The type registry is not sufficiently motivated. Why are standard= values needed here? And if they are, then why is FCFS not sufficient? 5. The mechanism should not be limited to cases where the external ad= dress is IPv4. Since it's passed as a string, there's no reason for such a limi= tation. A marked up copy that also includes my editorial comments can be found at http://research.microsoft.com/~dthaler/draft-ietf-behave-syslog-nat-logging= -02.pdf (or a .docx version if you replace .pdf with .docx). -Dave --_000_9c6e4d956a264bd781bb66a412e5cce3BY2PR03MB269namprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Of the 10 documents I read while traveling to Berlin= , this one was the longest, but

also probably the easiest to read and most well writ= ten in my opinion, so thanks for

all the work put into this recently!

 

A summary of my technical comments follows.

 

1.     &= nbsp; The syslog doc and the NAT MIB are not currently al= igned.

The NAT MIB has low/high watermark objects fo= r one type of notification

(which I think is a good approach), but it ap= pears to only affect SNMP notifications

not Syslog notifications.   The sys= log doc requires rate limiting various things,

with required knobs that are not in the NAT M= IB.  And the syslog doesn’t

recommend low/high watermarks but probably sh= ould, as I think it’s currently

underspecified.

2.     &= nbsp; The use of UTF-8 strings for identifiers needs clar= ification.  Is non-ASCII really

required?   If so, what normalizati= on form?  Any constraints on set of legal

characters?  What are the uniqueness req= uirements?  E.g., is it ok to have

two values that differ only in normalization = form?  What about differing in

case?  What about being visually identic= al/confusable?

3.     &= nbsp; The document assumes a single “internal”= ; and a single “external” realm. This

Is not a safe assumption in general, and espe= cially not in scenarios like

“An IPv4 Network to An IPv6 NetworkR= 21; and vice versa, where there could

be (for instance) 2 internal realms and 0 ext= ernal realms.  Furthermore, the

terms are ambiguous. For example in the ̶= 0;IPv6 Internet to An IPv4 Network”

scenario where sessions are initiated from th= e Internet, which side is

“external”?

4.     &= nbsp; The type registry is not sufficiently motivated.&nb= sp; Why are standard values

needed here?  And if they are, then why = is FCFS not sufficient?

5.     &= nbsp; The mechanism should not be limited to cases where = the external address

is IPv4.   Since it’s passed = as a string, there’s no reason for such a limitation.

 

A marked up copy that also includes my

editorial comments can be found at

http://research.microsoft.com/~d= thaler/draft-ietf-behave-syslog-nat-logging-02.pdf

(or a .docx version if you replace .pdf with .docx).=

 

-Dave

--_000_9c6e4d956a264bd781bb66a412e5cce3BY2PR03MB269namprd03pro_-- From dthaler@microsoft.com Sat Jul 27 10:58:49 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87FF721F99E7 for ; Sat, 27 Jul 2013 10:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.799 X-Spam-Level: X-Spam-Status: No, score=-98.799 tagged_above=-999 required=5 tests=[AWL=-1.333, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQaAEUr4dsBv for ; Sat, 27 Jul 2013 10:58:41 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0249.outbound.messaging.microsoft.com [213.199.154.249]) by ietfa.amsl.com (Postfix) with ESMTP id 9B61F21F99E1 for ; Sat, 27 Jul 2013 10:58:40 -0700 (PDT) Received: from mail9-db9-R.bigfish.com (10.174.16.237) by DB9EHSOBE024.bigfish.com (10.174.14.87) with Microsoft SMTP Server id 14.1.225.22; Sat, 27 Jul 2013 17:58:39 +0000 Received: from mail9-db9 (localhost [127.0.0.1]) by mail9-db9-R.bigfish.com (Postfix) with ESMTP id 83B37C802C6 for ; Sat, 27 Jul 2013 17:58:39 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:autodiscover.service.exchange.microsoft.com; EFVD:NLI X-SpamScore: -4 X-BigFish: VS-4(zzc85fhzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1d7338h17326ah18c673h186M1de096h5eeeK8275bh8275dh1de097hz2fh2a8h683h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh17ej9a9j1155h) Received-SPF: pass (mail9-db9: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14MLTC102.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT005.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail9-db9 (localhost.localdomain [127.0.0.1]) by mail9-db9 (MessageSwitch) id 137494791780371_25385; Sat, 27 Jul 2013 17:58:37 +0000 (UTC) Received: from DB9EHSMHS015.bigfish.com (unknown [10.174.16.226]) by mail9-db9.bigfish.com (Postfix) with ESMTP id 0F464920049 for ; Sat, 27 Jul 2013 17:58:37 +0000 (UTC) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.8) by DB9EHSMHS015.bigfish.com (10.174.14.25) with Microsoft SMTP Server (TLS) id 14.16.227.3; Sat, 27 Jul 2013 17:58:36 +0000 Received: from ch1outboundpool.messaging.microsoft.com (157.54.51.112) by mail.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.3.136.1; Sat, 27 Jul 2013 17:57:28 +0000 Received: from mail148-ch1-R.bigfish.com (10.43.68.241) by CH1EHSOBE022.bigfish.com (10.43.70.79) with Microsoft SMTP Server id 14.1.225.22; Sat, 27 Jul 2013 17:57:26 +0000 Received: from mail148-ch1 (localhost [127.0.0.1]) by mail148-ch1-R.bigfish.com (Postfix) with ESMTP id B53082011B for ; Sat, 27 Jul 2013 17:57:26 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(243025003)(189002)(199002)(59766001)(19580395003)(76482001)(15202345003)(56776001)(77096001)(76576001)(19580385001)(80022001)(77982001)(83322001)(54356001)(54316002)(56816003)(16236675002)(53806001)(83072001)(74316001)(79102001)(65816001)(76786001)(63696002)(50986001)(4396001)(69226001)(76796001)(47736001)(16406001)(31966008)(49866001)(46102001)(74502001)(74706001)(74876001)(51856001)(74366001)(19300405004)(47446002)(74662001)(81342001)(47976001)(33646001)(76176001)(81542001)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB270; H:BY2PR03MB269.namprd03.prod.outlook.com; CLIP:2001:df8:0:64:ad8b:1daa:4db9:e67d; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail148-ch1 (localhost.localdomain [127.0.0.1]) by mail148-ch1 (MessageSwitch) id 137494784571414_30472; Sat, 27 Jul 2013 17:57:25 +0000 (UTC) Received: from CH1EHSMHS017.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.242]) by mail148-ch1.bigfish.com (Postfix) with ESMTP id 021E7460048; Sat, 27 Jul 2013 17:57:25 +0000 (UTC) Received: from BL2PRD0310HT005.namprd03.prod.outlook.com (157.56.240.21) by CH1EHSMHS017.bigfish.com (10.43.70.17) with Microsoft SMTP Server (TLS) id 14.16.227.3; Sat, 27 Jul 2013 17:57:23 +0000 Received: from BY2PR03MB270.namprd03.prod.outlook.com (10.242.37.12) by BL2PRD0310HT005.namprd03.prod.outlook.com (10.255.97.40) with Microsoft SMTP Server (TLS) id 14.16.341.1; Sat, 27 Jul 2013 17:57:22 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com (10.242.37.11) by BY2PR03MB270.namprd03.prod.outlook.com (10.242.37.12) with Microsoft SMTP Server (TLS) id 15.0.731.11; Sat, 27 Jul 2013 17:57:20 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.171]) by BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.234]) with mapi id 15.00.0731.000; Sat, 27 Jul 2013 17:57:13 +0000 From: Dave Thaler To: "draft-ietf-behave-requirements-update@tools.ietf.org" Thread-Topic: Comments on draft-ietf-behave-requirements-update-00 Thread-Index: Ac6K8eY1WjMmAsN8T3uc58Qwkd4dfA== Date: Sat, 27 Jul 2013 17:57:13 +0000 Message-ID: <9a0966c1a5754a0d949885910dd72d5a@BY2PR03MB269.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:df8:0:64:ad8b:1daa:4db9:e67d] x-forefront-prvs: 0920602B08 Content-Type: multipart/alternative; boundary="_000_9a0966c1a5754a0d949885910dd72d5aBY2PR03MB269namprd03pro_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: BY2PR03MB270.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%TOOLS.IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14MLTC102.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14MLTC102.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "behave@ietf.org" Subject: [BEHAVE] Comments on draft-ietf-behave-requirements-update-00 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jul 2013 17:58:49 -0000 --_000_9a0966c1a5754a0d949885910dd72d5aBY2PR03MB269namprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable High level comments: 1) There are too many MAY's for a Best Current Practice. If it's rea= lly a Best Practice, it should be a SHOULD. If it's not a Best Practice, i= t shouldn't be in a BCP. 2) I am strongly against scoping to just NAT44. For each problem, eit= her a) it applies to both NAT44 and NAT64 equally, so both should be in scope, = or b) it applies to only NAT44 and the doc should explain why it's not a probl= em in NAT64 (e.g., because the NAT64 document already addresses the problem= ). Some problems in the doc already sufficiently cover (b). Others don't say = anything and I expect (a) would apply. A marked up copy that also includes my editorial comments can be found at http://research.microsoft.com/~dthaler/draft-ietf-behave-requirements-updat= e-00.pdf (or a .docx version if you replace .pdf with .docx). -Dave --_000_9a0966c1a5754a0d949885910dd72d5aBY2PR03MB269namprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

High level comments:

1)      There are too many MAY's for a Best Current Practic= e.   If it’s really a Best Practice, it should be a SHOULD.=   If it’s not a Best Practice, it shouldn’t be in a BCP.

2)      I am strongly against scoping to just NAT44.  = For each problem, either

a) it applies to both NAT44 and NAT64 equally= , so both should be in scope, or

b) it applies to only NAT44 and the doc shoul= d explain why it’s not a problem in NAT64 (e.g., because the NAT64 do= cument already addresses the problem).  

Some problems in the doc already sufficiently= cover (b).  Others don’t say anything and I expect (a) would ap= ply.

 

A marked up copy that also includes my editorial com= ments can be found at

http://research.microsoft.com/~= dthaler/draft-ietf-behave-requirements-update-00.pdf

(or a .docx version if you replace .pdf with .docx).=

 

-Dave

--_000_9a0966c1a5754a0d949885910dd72d5aBY2PR03MB269namprd03pro_-- From tom.taylor.stds@gmail.com Sat Jul 27 12:57:51 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CA2911E80FA for ; Sat, 27 Jul 2013 12:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 1C-JXTFubs+O for ; Sat, 27 Jul 2013 12:57:50 -0700 (PDT) Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 6F26211E80F8 for ; Sat, 27 Jul 2013 12:57:50 -0700 (PDT) Received: by mail-qa0-f44.google.com with SMTP id hu16so988442qab.10 for ; Sat, 27 Jul 2013 12:57:49 -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; bh=kPIwMkiXK2Zb9xnTY3QUcQzLNRzLnfaRs/ZHKoqsC0I=; b=B81OoADbsfPRJFRzufVgTx+J3wOQlYcXv/HgA+/BRE5T6DS7G4131OBLfm/Y/qWL7z 6z9/bpIlWQmI4lFpUeaL5CY58eG7zOC2Jkjwz6nKw9IG+NGHxZBJ5l/u10/H5uq1cj8l 9gDDG8V5ROqIRiG9tw9Tqp3ZhdX8L44GcU6h6xvamCh5I51FDr7/1+RQfwEr2wCm44RC cI4J/c/PkZcoi4pKJVd0Awnzc1gyc91ylCEfzVqA1dhzyVArIfbaQAjl+0GgnFLXMPZ7 +dxymmeUNY03kp3e6D9hbss8Ucn9V7BRawA/3RngkwFMvQqntjs5HVabOJDLlSHtEmCH 5AEw== X-Received: by 10.49.103.228 with SMTP id fz4mr37787596qeb.72.1374955069866; Sat, 27 Jul 2013 12:57:49 -0700 (PDT) Received: from [192.168.1.64] (dsl-173-206-92-228.tor.primus.ca. [173.206.92.228]) by mx.google.com with ESMTPSA id h6sm8907956qah.1.2013.07.27.12.57.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 27 Jul 2013 12:57:49 -0700 (PDT) Message-ID: <51F4263A.8050309@gmail.com> Date: Sat, 27 Jul 2013 15:57:46 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Dan Wing References: <9B6672F8-4718-49B3-A009-F0270BDEBF2F@cisco.com> <20130726043233.GB44013@elstar.local> <27F057BA-F248-4CAE-8FA0-88382F6BE78A@cisco.com> <20130726182033.GA45380@elstar.local> <20130726202431.GB45709@elstar.local> <5EAF1327-3118-4AF9-85FD-EF97B4013BE5@cisco.com> In-Reply-To: <5EAF1327-3118-4AF9-85FD-EF97B4013BE5@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "behave@ietf.org" , Juergen Schoenwaelder Subject: Re: [BEHAVE] walking RFC4008 (NAT MIB) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jul 2013 19:57:51 -0000 On 26/07/2013 4:33 PM, Dan Wing wrote: > > On Jul 26, 2013, at 1:24 PM, Juergen Schoenwaelder wrote: > >> On Fri, Jul 26, 2013 at 12:34:09PM -0700, Dan Wing wrote: >>> >>> On Jul 26, 2013, at 11:20 AM, Juergen Schoenwaelder wrote: >>> >>>> On Fri, Jul 26, 2013 at 10:08:19AM -0700, Dan Wing wrote: >>>> >>>>> Yes, thanks -- that would work if all the subscribers have unique >>>>> natAddrBindLocalAddr (IP address). But it wouldn't work where the >>>>> unique selector is something else, such as DS-Lite (where every >>>>> subscriber could and will use the same IPv4 address, but different >>>>> IPv6 tunnels), or NATs where VRF or VLAN are used as the subscriber >>>>> identifier. Is there some other way RFC4008 could work for those >>>>> cases of IPv6, VRF, VLAN being the subscriber identifier? >>>> >>>> Do the DS-Lite tunnels not end at different tunnel interfaces? Same >>>> for VLAN interfaces? >>> >>> The SYSLOG and IPFIX logging documents are emitting VLAN and VRF numbers, rather than tunnel interface numbers. >>> >>> SYSLOG logging example of its quota exceeded event, http://tools.ietf.org/html/draft-ietf-behave-syslog-nat-logging-02#section-3.6 >>> IPFIX logging example of its vlanID and ingressVRFID, http://tools.ietf.org/html/draft-ietf-behave-ipfix-nat-logging-00#page-6 >>> >> >> This design limits things to VLANs and VRFs - back when the NAT-MIB >> was created, an interface identifier as this makes things quite >> generic - it works for any current and future interface type. But then >> I am told NATs do not work this way anymore... > > Seems we should have consistency or, at minimum, a way to map between/among them. > > -d > I'm certainly eager to see a resolution here. I'm rather vague on what the SYSLOG Subscriber Site Identifier will contain. From tom.taylor.stds@gmail.com Sun Jul 28 01:13:03 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD22921F9E3A for ; Sun, 28 Jul 2013 01:13:02 -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 vq4JuTwiKwuc for ; Sun, 28 Jul 2013 01:12:59 -0700 (PDT) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 2834321F9E15 for ; Sun, 28 Jul 2013 01:12:56 -0700 (PDT) Received: by mail-ob0-f171.google.com with SMTP id tb18so7370281obb.30 for ; Sun, 28 Jul 2013 01:12:55 -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; bh=bhBJ45FIAMHanQyrkiqJCuwOJ/Lg3bZabh2GLODFMwo=; b=mA3Kv+oGEPX3wF+dYQHbfROtnPMqUb99hay9otT7FazO+El6k5+jO69nTY4ZjkdvLn SX4OwRjxsdpxSBOmI9RIwv0DXXSGzR33cW2nlIU/Yest1ezRPALQqa9t/4v26s5qGVaS 9VIGNGfPTS69jx+FUL4GrZ7oS9q6LlVh4DC3O3yLDo/ypxJsh5xsCXCRu1XjIRBycx5v 7qJJwKXHK5mybCHhZ1BgaUjsbBEq8mnqdfcQ8HrU0dk323Xh8Z2qBKxiLenPIqocokB2 j/Vu7PQQrPgJKnTm46UX3z2j93u+RCptsBtcte1Qq3LMO4a2xlNje9zFW88uxZWd3hOy NveQ== X-Received: by 10.60.92.162 with SMTP id cn2mr17563194oeb.103.1374999175567; Sun, 28 Jul 2013 01:12:55 -0700 (PDT) Received: from [192.168.1.64] (dsl-173-206-92-228.tor.primus.ca. [173.206.92.228]) by mx.google.com with ESMTPSA id g1sm80844288oeq.6.2013.07.28.01.12.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 28 Jul 2013 01:12:54 -0700 (PDT) Message-ID: <51F4D283.2040501@gmail.com> Date: Sun, 28 Jul 2013 04:12:51 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Dave Thaler References: <9c6e4d956a264bd781bb66a412e5cce3@BY2PR03MB269.namprd03.prod.outlook.com> In-Reply-To: <9c6e4d956a264bd781bb66a412e5cce3@BY2PR03MB269.namprd03.prod.outlook.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "draft-ietf-behave-syslog-nat-logging@tools.ietf.org" , "behave@ietf.org" Subject: Re: [BEHAVE] Comments on draft-ietf-behave-syslog-nat-logging-02 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2013 08:13:03 -0000 Thanks for taking the time for this. Responses below. On 27/07/2013 1:45 PM, Dave Thaler wrote: > Of the 10 documents I read while traveling to Berlin, this one was the longest, but > also probably the easiest to read and most well written in my opinion, so thanks for > all the work put into this recently! > > A summary of my technical comments follows. > > > 1. The syslog doc and the NAT MIB are not currently aligned. > > The NAT MIB has low/high watermark objects for one type of notification > > (which I think is a good approach), but it appears to only affect SNMP notifications > > not Syslog notifications. The syslog doc requires rate limiting various things, > > with required knobs that are not in the NAT MIB. And the syslog doesn't > > recommend low/high watermarks but probably should, as I think it's currently > > underspecified. [PTT] I wonder if, in the interest of orderly procedure, we first draw up the configuration requirements by adding a Management Considerations section to the logging draft. Then we can figure out how to propagate that to the MIB or other configuration models. [PTT] The watermark system I'm familiar with from my telephony days would be based on observations over a fixed time interval (e.g., 5 minutes, 30 minutes, possibly an hour). Is this what you would have in mind, with a log being generated at the end of each observation interval? > > 2. The use of UTF-8 strings for identifiers needs clarification. Is non-ASCII really > > required? If so, what normalization form? Any constraints on set of legal > > characters? What are the uniqueness requirements? E.g., is it ok to have > > two values that differ only in normalization form? What about differing in > > case? What about being visually identical/confusable? [PTT] I agree this needs a closer look. We ended up having to add stuff to ANCP to support the use of UTF-8. I'm getting the picture of an occasional (hourly and whenever configuration changes) ADMIN event type which would have miscellaneous stuff like the byte masks used to truncate IPv4 and IPv6 addresses (suggested by Dan in his review), and could also have the additional information needed to make UTF-8 work. Of course, as you say, we should first determine whether anything more than US-ASCII is needed. > > 3. The document assumes a single "internal" and a single "external" realm. This > > Is not a safe assumption in general, and especially not in scenarios like > > "An IPv4 Network to An IPv6 Network" and vice versa, where there could > > be (for instance) 2 internal realms and 0 external realms. Furthermore, the > > terms are ambiguous. For example in the "IPv6 Internet to An IPv4 Network" > > scenario where sessions are initiated from the Internet, which side is > > "external"? [PTT] Ironic -- I changed the terminology because the terminology implicit in the IPFIX draft always takes the point of view of outgoing packets without saying so and I thought that was ambiguous. Looks like we need to fall back to that position and state the convention in the terminology section. > > 4. The type registry is not sufficiently motivated. Why are standard values > > needed here? And if they are, then why is FCFS not sufficient? [PTT] Because, to be blunt, I sense that if anyone wanted to add NAT66 to the list it would trigger a fairly strong reaction. > > 5. The mechanism should not be limited to cases where the external address > > is IPv4. Since it's passed as a string, there's no reason for such a limitation. > > A marked up copy that also includes my > editorial comments can be found at > http://research.microsoft.com/~dthaler/draft-ietf-behave-syslog-nat-logging-02.pdf > (or a .docx version if you replace .pdf with .docx). > > -Dave > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From dthaler@microsoft.com Sun Jul 28 05:45:14 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0761521F9D1E for ; Sun, 28 Jul 2013 05:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.842 X-Spam-Level: X-Spam-Status: No, score=-99.842 tagged_above=-999 required=5 tests=[AWL=-0.375, BAYES_00=-2.599, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aLQrLUbZrws9 for ; Sun, 28 Jul 2013 05:45:08 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0184.outbound.messaging.microsoft.com [213.199.154.184]) by ietfa.amsl.com (Postfix) with ESMTP id 2EC3821F9D21 for ; Sun, 28 Jul 2013 05:45:08 -0700 (PDT) Received: from mail215-db8-R.bigfish.com (10.174.8.251) by DB8EHSOBE019.bigfish.com (10.174.4.82) with Microsoft SMTP Server id 14.1.225.22; Sun, 28 Jul 2013 12:45:07 +0000 Received: from mail215-db8 (localhost [127.0.0.1]) by mail215-db8-R.bigfish.com (Postfix) with ESMTP id 335703A0104 for ; Sun, 28 Jul 2013 12:45:07 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:autodiscover.service.exchange.microsoft.com; EFVD:NLI X-SpamScore: -20 X-BigFish: VS-20(zz98dI9371I542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah1de096h8275dh1de097hz2fh2a8h683h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh17ej9a9j1155h) Received-SPF: pass (mail215-db8: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14HUBC105.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT004.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail215-db8 (localhost.localdomain [127.0.0.1]) by mail215-db8 (MessageSwitch) id 1375015505563715_22463; Sun, 28 Jul 2013 12:45:05 +0000 (UTC) Received: from DB8EHSMHS013.bigfish.com (unknown [10.174.8.241]) by mail215-db8.bigfish.com (Postfix) with ESMTP id 722ACE0046 for ; Sun, 28 Jul 2013 12:45:05 +0000 (UTC) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.8) by DB8EHSMHS013.bigfish.com (10.174.4.23) with Microsoft SMTP Server (TLS) id 14.16.227.3; Sun, 28 Jul 2013 12:45:05 +0000 Received: from DB8EHSOBE018.bigfish.com (157.54.51.80) by mail.microsoft.com (157.54.80.48) with Microsoft SMTP Server (TLS) id 14.3.136.1; Sun, 28 Jul 2013 12:44:16 +0000 Received: from mail166-db8-R.bigfish.com (10.174.8.230) by DB8EHSOBE018.bigfish.com (10.174.4.81) with Microsoft SMTP Server id 14.1.225.22; Sun, 28 Jul 2013 12:44:14 +0000 Received: from mail166-db8 (localhost [127.0.0.1]) by mail166-db8-R.bigfish.com (Postfix) with ESMTP id D8EADA80306 for ; Sun, 28 Jul 2013 12:44:14 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(13464003)(377454003)(24454002)(51704005)(189002)(199002)(65816001)(80976001)(74502001)(49866001)(15202345003)(83072001)(47736001)(19580405001)(47446002)(31966008)(76576001)(63696002)(19580385001)(50986001)(47976001)(83322001)(74662001)(56816003)(19580395003)(33646001)(80022001)(77096001)(16406001)(76796001)(79102001)(76786001)(59766001)(54356001)(56776001)(77982001)(46102001)(81542001)(76482001)(54316002)(74706001)(74876001)(74366001)(53806001)(81342001)(4396001)(74316001)(69226001)(51856001)(24736002)(3826001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB272; H:BY2PR03MB269.namprd03.prod.outlook.com; CLIP:2001:df8:0:64:4081:a95b:44c9:973; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail166-db8 (localhost.localdomain [127.0.0.1]) by mail166-db8 (MessageSwitch) id 1375015452462173_10593; Sun, 28 Jul 2013 12:44:12 +0000 (UTC) Received: from DB8EHSMHS012.bigfish.com (unknown [10.174.8.228]) by mail166-db8.bigfish.com (Postfix) with ESMTP id 612F26C0045; Sun, 28 Jul 2013 12:44:12 +0000 (UTC) Received: from BL2PRD0310HT004.namprd03.prod.outlook.com (157.56.240.21) by DB8EHSMHS012.bigfish.com (10.174.4.22) with Microsoft SMTP Server (TLS) id 14.16.227.3; Sun, 28 Jul 2013 12:44:12 +0000 Received: from BY2PR03MB272.namprd03.prod.outlook.com (10.242.37.24) by BL2PRD0310HT004.namprd03.prod.outlook.com (10.255.97.39) with Microsoft SMTP Server (TLS) id 14.16.341.1; Sun, 28 Jul 2013 12:44:09 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com (10.242.37.11) by BY2PR03MB272.namprd03.prod.outlook.com (10.242.37.24) with Microsoft SMTP Server (TLS) id 15.0.731.11; Sun, 28 Jul 2013 12:43:39 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.171]) by BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.234]) with mapi id 15.00.0731.000; Sun, 28 Jul 2013 12:43:33 +0000 From: Dave Thaler To: Dan Wing , Juergen Schoenwaelder Thread-Topic: [BEHAVE] walking RFC4008 (NAT MIB) Thread-Index: AQHOiZYU8CcvRvL1fk2YsClx2BrfIJl2Xx6AgADTKYCAABQugIAAFJGAgAAOEoCAAAKkAIACoPHg Date: Sun, 28 Jul 2013 12:43:33 +0000 Message-ID: References: <9B6672F8-4718-49B3-A009-F0270BDEBF2F@cisco.com> <20130726043233.GB44013@elstar.local> <27F057BA-F248-4CAE-8FA0-88382F6BE78A@cisco.com> <20130726182033.GA45380@elstar.local> <20130726202431.GB45709@elstar.local> <5EAF1327-3118-4AF9-85FD-EF97B4013BE5@cisco.com> In-Reply-To: <5EAF1327-3118-4AF9-85FD-EF97B4013BE5@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:df8:0:64:4081:a95b:44c9:973] x-forefront-prvs: 0921D55E4F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BY2PR03MB272.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%JACOBS-UNIVERSITY.DE$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%CISCO.COM$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC105.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC105.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "behave@ietf.org" Subject: Re: [BEHAVE] walking RFC4008 (NAT MIB) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2013 12:45:14 -0000 > -----Original Message----- > From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On > Behalf Of Dan Wing > Sent: Friday, July 26, 2013 10:34 PM > To: Juergen Schoenwaelder > Cc: behave@ietf.org > Subject: Re: [BEHAVE] walking RFC4008 (NAT MIB) >=20 >=20 > On Jul 26, 2013, at 1:24 PM, Juergen Schoenwaelder > wrote: >=20 > > On Fri, Jul 26, 2013 at 12:34:09PM -0700, Dan Wing wrote: > >> > >> On Jul 26, 2013, at 11:20 AM, Juergen Schoenwaelder > wrote: > >> > >>> On Fri, Jul 26, 2013 at 10:08:19AM -0700, Dan Wing wrote: > >>> > >>>> Yes, thanks -- that would work if all the subscribers have unique > >>>> natAddrBindLocalAddr (IP address). But it wouldn't work where the > >>>> unique selector is something else, such as DS-Lite (where every > >>>> subscriber could and will use the same IPv4 address, but different > >>>> IPv6 tunnels), or NATs where VRF or VLAN are used as the subscriber > >>>> identifier. Is there some other way RFC4008 could work for those > >>>> cases of IPv6, VRF, VLAN being the subscriber identifier? > >>> > >>> Do the DS-Lite tunnels not end at different tunnel interfaces? Same > >>> for VLAN interfaces? > >> > >> The SYSLOG and IPFIX logging documents are emitting VLAN and VRF > numbers, rather than tunnel interface numbers. > >> > >> SYSLOG logging example of its quota exceeded event, > >> http://tools.ietf.org/html/draft-ietf-behave-syslog-nat-logging-02#se > >> ction-3.6 IPFIX logging example of its vlanID and ingressVRFID, > >> http://tools.ietf.org/html/draft-ietf-behave-ipfix-nat-logging-00#pag > >> e-6 > >> > > > > This design limits things to VLANs and VRFs - back when the NAT-MIB > > was created, an interface identifier as this makes things quite > > generic - it works for any current and future interface type. But then > > I am told NATs do not work this way anymore... >=20 > Seems we should have consistency or, at minimum, a way to map > between/among them. >=20 > -d On that topic, I think we probably need a generic "realm id" (which may spa= n multiple interfaces for example). -Dave From simon.perreault@viagenie.ca Sun Jul 28 06:03:14 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD24821F99D0 for ; Sun, 28 Jul 2013 06:03: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 xQGruPtm-DoU for ; Sun, 28 Jul 2013 06:03:13 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 48B8721F9546 for ; Sun, 28 Jul 2013 06:03:13 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:2002::1004]) by jazz.viagenie.ca (Postfix) with ESMTPSA id ECC8E40415 for ; Sun, 28 Jul 2013 09:03:11 -0400 (EDT) Message-ID: <51F5168E.5000404@viagenie.ca> Date: Sun, 28 Jul 2013 15:03:10 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: behave@ietf.org References: <9B6672F8-4718-49B3-A009-F0270BDEBF2F@cisco.com> <20130726043233.GB44013@elstar.local> <27F057BA-F248-4CAE-8FA0-88382F6BE78A@cisco.com> <20130726182033.GA45380@elstar.local> <20130726202431.GB45709@elstar.local> <5EAF1327-3118-4AF9-85FD-EF97B4013BE5@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [BEHAVE] walking RFC4008 (NAT MIB) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2013 13:03:14 -0000 Le 2013-07-28 14:43, Dave Thaler a crit : > On that topic, I think we probably need a generic "realm id" (which may span > multiple interfaces for example). Isn't that exactly what we have in the NAT MIB? 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 dthaler@microsoft.com Sun Jul 28 06:13:07 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 690C621F8F2E for ; Sun, 28 Jul 2013 06:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.313 X-Spam-Level: X-Spam-Status: No, score=-100.313 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVbzAt2jN2AQ for ; Sun, 28 Jul 2013 06:13:01 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id C326C21F9D31 for ; Sun, 28 Jul 2013 06:13:00 -0700 (PDT) Received: from mail11-ch1-R.bigfish.com (10.43.68.250) by CH1EHSOBE002.bigfish.com (10.43.70.52) with Microsoft SMTP Server id 14.1.225.22; Sun, 28 Jul 2013 13:13:00 +0000 Received: from mail11-ch1 (localhost [127.0.0.1]) by mail11-ch1-R.bigfish.com (Postfix) with ESMTP id 0E19134027E for ; Sun, 28 Jul 2013 13:13:00 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:autodiscover.service.exchange.microsoft.com; EFVD:NLI X-SpamScore: 1 X-BigFish: VS1(zz98dIc89bh936eI1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzzz2fh2a8h683h839h947hd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh17ej9a9j1155h) Received-SPF: pass (mail11-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14MLTC102.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT002.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail11-ch1 (localhost.localdomain [127.0.0.1]) by mail11-ch1 (MessageSwitch) id 1375017177656847_30498; Sun, 28 Jul 2013 13:12:57 +0000 (UTC) Received: from CH1EHSMHS039.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.246]) by mail11-ch1.bigfish.com (Postfix) with ESMTP id 9A9D71C004A for ; Sun, 28 Jul 2013 13:12:57 +0000 (UTC) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS039.bigfish.com (10.43.69.248) with Microsoft SMTP Server (TLS) id 14.16.227.3; Sun, 28 Jul 2013 13:12:57 +0000 Received: from ch1outboundpool.messaging.microsoft.com (157.54.51.81) by mail.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.3.136.1; Sun, 28 Jul 2013 13:12:56 +0000 Received: from mail108-ch1-R.bigfish.com (10.43.68.244) by CH1EHSOBE012.bigfish.com (10.43.70.62) with Microsoft SMTP Server id 14.1.225.22; Sun, 28 Jul 2013 13:12:54 +0000 Received: from mail108-ch1 (localhost [127.0.0.1]) by mail108-ch1-R.bigfish.com (Postfix) with ESMTP id B034A2C0157 for ; Sun, 28 Jul 2013 13:12:54 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(377424004)(199002)(189002)(51704005)(24454002)(69226001)(31966008)(74706001)(49866001)(33646001)(47736001)(80976001)(50986001)(65816001)(74876001)(76786001)(47976001)(80022001)(74662001)(74502001)(51856001)(74366001)(16406001)(81542001)(63696002)(4396001)(47446002)(81342001)(46102001)(83322001)(54316002)(83072001)(54356001)(59766001)(56776001)(76576001)(77096001)(76482001)(79102001)(74316001)(56816003)(76796001)(77982001)(53806001)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB270; H:BY2PR03MB269.namprd03.prod.outlook.com; CLIP:2001:df8:0:64:4081:a95b:44c9:973; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail108-ch1 (localhost.localdomain [127.0.0.1]) by mail108-ch1 (MessageSwitch) id 1375017172128979_12553; Sun, 28 Jul 2013 13:12:52 +0000 (UTC) Received: from CH1EHSMHS030.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.237]) by mail108-ch1.bigfish.com (Postfix) with ESMTP id 1A36A200047; Sun, 28 Jul 2013 13:12:52 +0000 (UTC) Received: from BL2PRD0310HT002.namprd03.prod.outlook.com (157.56.240.21) by CH1EHSMHS030.bigfish.com (10.43.70.30) with Microsoft SMTP Server (TLS) id 14.16.227.3; Sun, 28 Jul 2013 13:12:51 +0000 Received: from BY2PR03MB270.namprd03.prod.outlook.com (10.242.37.12) by BL2PRD0310HT002.namprd03.prod.outlook.com (10.255.97.37) with Microsoft SMTP Server (TLS) id 14.16.341.1; Sun, 28 Jul 2013 13:12:44 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com (10.242.37.11) by BY2PR03MB270.namprd03.prod.outlook.com (10.242.37.12) with Microsoft SMTP Server (TLS) id 15.0.731.11; Sun, 28 Jul 2013 13:12:42 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.171]) by BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.234]) with mapi id 15.00.0731.000; Sun, 28 Jul 2013 13:12:41 +0000 From: Dave Thaler To: Simon Perreault , "behave@ietf.org" Thread-Topic: [BEHAVE] walking RFC4008 (NAT MIB) Thread-Index: AQHOiZYU8CcvRvL1fk2YsClx2BrfIJl2Xx6AgADTKYCAABQugIAAFJGAgAAOEoCAAAKkAIACoPHggAAFxQCAAAIJ4A== Date: Sun, 28 Jul 2013 13:12:40 +0000 Message-ID: <14d0e7edcfb340b1a497758398c84b67@BY2PR03MB269.namprd03.prod.outlook.com> References: <9B6672F8-4718-49B3-A009-F0270BDEBF2F@cisco.com> <20130726043233.GB44013@elstar.local> <27F057BA-F248-4CAE-8FA0-88382F6BE78A@cisco.com> <20130726182033.GA45380@elstar.local> <20130726202431.GB45709@elstar.local> <5EAF1327-3118-4AF9-85FD-EF97B4013BE5@cisco.com> <51F5168E.5000404@viagenie.ca> In-Reply-To: <51F5168E.5000404@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:df8:0:64:4081:a95b:44c9:973] x-forefront-prvs: 0921D55E4F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BY2PR03MB270.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%VIAGENIE.CA$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14MLTC102.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14MLTC102.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [BEHAVE] walking RFC4008 (NAT MIB) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2013 13:13:07 -0000 [inserting context back in] > Dan Wing wrote: >>> This design limits things to VLANs and VRFs - back when the NAT-MIB=20 >> was created, an interface identifier as this makes things quite=20 >> generic - it works for any current and future interface type. But=20 >> then I am told NATs do not work this way anymore... > > Seems we should have consistency or, at minimum, a way to map between/amo= ng them. Simon wrote: > Le 2013-07-28 14:43, Dave Thaler a =E9crit : > > On that topic, I think we probably need a generic "realm id" (which > > may span multiple interfaces for example). >=20 > Isn't that exactly what we have in the NAT MIB? Yes, except there's no way to map one to a set of interfaces. Add that and then yes I think the logging doc(s) should use the same id. -Dave From simon.perreault@viagenie.ca Sun Jul 28 06:19:16 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 131E021F9C4A for ; Sun, 28 Jul 2013 06:19:16 -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 dsavpt5r-b4A for ; Sun, 28 Jul 2013 06:19:15 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6E2F721F9CAC for ; Sun, 28 Jul 2013 06:19:15 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:2002::1004]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 90B0640415; Sun, 28 Jul 2013 09:19:14 -0400 (EDT) Message-ID: <51F51A50.2040509@viagenie.ca> Date: Sun, 28 Jul 2013 15:19:12 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Dave Thaler References: <9B6672F8-4718-49B3-A009-F0270BDEBF2F@cisco.com> <20130726043233.GB44013@elstar.local> <27F057BA-F248-4CAE-8FA0-88382F6BE78A@cisco.com> <20130726182033.GA45380@elstar.local> <20130726202431.GB45709@elstar.local> <5EAF1327-3118-4AF9-85FD-EF97B4013BE5@cisco.com> <51F5168E.5000404@viagenie.ca> <14d0e7edcfb340b1a497758398c84b67@BY2PR03MB269.namprd03.prod.outlook.com> In-Reply-To: <14d0e7edcfb340b1a497758398c84b67@BY2PR03MB269.namprd03.prod.outlook.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "behave@ietf.org" Subject: Re: [BEHAVE] walking RFC4008 (NAT MIB) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2013 13:19:16 -0000 Le 2013-07-28 15:12, Dave Thaler a crit : > [inserting context back in] > >> Dan Wing wrote: >>>> This design limits things to VLANs and VRFs - back when the NAT-MIB >>> was created, an interface identifier as this makes things quite >>> generic - it works for any current and future interface type. But >>> then I am told NATs do not work this way anymore... >> >> Seems we should have consistency or, at minimum, a way to map between/among them. > > Simon wrote: >> Le 2013-07-28 14:43, Dave Thaler a crit : >>> On that topic, I think we probably need a generic "realm id" (which >>> may span multiple interfaces for example). >> >> Isn't that exactly what we have in the NAT MIB? > > Yes, except there's no way to map one to a set of interfaces. > Add that and then yes I think the logging doc(s) should use the same id. I'm not following. Why do we need a standard way of expressing mappings from realm IDs to interface sets? And how would that information be provided? I agree that the NAT MIB's realm id should correspond to the logging doc(s) realm id. 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 dthaler@microsoft.com Sun Jul 28 08:13:59 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32C7C21F9C53 for ; Sun, 28 Jul 2013 08:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.341 X-Spam-Level: X-Spam-Status: No, score=-100.341 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XBtPjcdiGxT0 for ; Sun, 28 Jul 2013 08:13:52 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe002.messaging.microsoft.com [213.199.154.205]) by ietfa.amsl.com (Postfix) with ESMTP id 2C3D321F99AF for ; Sun, 28 Jul 2013 08:13:38 -0700 (PDT) Received: from mail37-am1-R.bigfish.com (10.3.201.234) by AM1EHSOBE019.bigfish.com (10.3.207.141) with Microsoft SMTP Server id 14.1.225.22; Sun, 28 Jul 2013 15:13:36 +0000 Received: from mail37-am1 (localhost [127.0.0.1]) by mail37-am1-R.bigfish.com (Postfix) with ESMTP id 2DB58E012F for ; Sun, 28 Jul 2013 15:13:36 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:autodiscover.service.exchange.microsoft.com; EFVD:NLI X-SpamScore: 3 X-BigFish: VS3(z4c5Izc85fhzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1d7338h17326ah18c673h1de096h8275bh8275dh1de097hz2fh2a8h683h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh17ej9a9j1155h) Received-SPF: pass (mail37-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14HUBC102.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT002.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail37-am1 (localhost.localdomain [127.0.0.1]) by mail37-am1 (MessageSwitch) id 1375024413888954_15037; Sun, 28 Jul 2013 15:13:33 +0000 (UTC) Received: from AM1EHSMHS004.bigfish.com (unknown [10.3.201.243]) by mail37-am1.bigfish.com (Postfix) with ESMTP id CBC8E100069 for ; Sun, 28 Jul 2013 15:13:33 +0000 (UTC) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS004.bigfish.com (10.3.207.104) with Microsoft SMTP Server (TLS) id 14.16.227.3; Sun, 28 Jul 2013 15:13:29 +0000 Received: from va3outboundpool.messaging.microsoft.com (157.54.51.80) by mail.microsoft.com (157.54.7.154) with Microsoft SMTP Server (TLS) id 14.3.136.1; Sun, 28 Jul 2013 15:12:24 +0000 Received: from mail186-va3-R.bigfish.com (10.7.14.242) by VA3EHSOBE010.bigfish.com (10.7.40.12) with Microsoft SMTP Server id 14.1.225.22; Sun, 28 Jul 2013 15:12:23 +0000 Received: from mail186-va3 (localhost [127.0.0.1]) by mail186-va3-R.bigfish.com (Postfix) with ESMTP id 1C5D54201BC for ; Sun, 28 Jul 2013 15:12:23 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(12213003)(189002)(199002)(77982001)(54316002)(74876001)(47446002)(63696002)(83072001)(16236675002)(74706001)(76796001)(74662001)(76786001)(19580385001)(77096001)(74502001)(558084003)(33646001)(83322001)(54356001)(76482001)(76576001)(46102001)(59766001)(56816003)(79102001)(4396001)(31966008)(56776001)(19580395003)(76176001)(15202345003)(16406001)(19300405004)(81542001)(50986001)(51856001)(47976001)(80976001)(53806001)(47736001)(49866001)(80022001)(74366001)(74316001)(69226001)(65816001)(81342001)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB269; H:BY2PR03MB269.namprd03.prod.outlook.com; CLIP:2001:df8:0:64:3c1d:68cd:d64c:aadd; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail186-va3 (localhost.localdomain [127.0.0.1]) by mail186-va3 (MessageSwitch) id 1375024341410406_15251; Sun, 28 Jul 2013 15:12:21 +0000 (UTC) Received: from VA3EHSMHS038.bigfish.com (unknown [10.7.14.226]) by mail186-va3.bigfish.com (Postfix) with ESMTP id 5BC60220054 for ; Sun, 28 Jul 2013 15:12:21 +0000 (UTC) Received: from BL2PRD0310HT002.namprd03.prod.outlook.com (157.56.240.21) by VA3EHSMHS038.bigfish.com (10.7.99.48) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sun, 28 Jul 2013 15:12:14 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com (10.242.37.11) by BL2PRD0310HT002.namprd03.prod.outlook.com (10.255.97.37) with Microsoft SMTP Server (TLS) id 14.16.341.1; Sun, 28 Jul 2013 15:12:13 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com (10.242.37.11) by BY2PR03MB269.namprd03.prod.outlook.com (10.242.37.11) with Microsoft SMTP Server (TLS) id 15.0.731.11; Sun, 28 Jul 2013 15:11:44 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.171]) by BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.234]) with mapi id 15.00.0731.000; Sun, 28 Jul 2013 15:11:38 +0000 From: Dave Thaler To: "behave@ietf.org" Thread-Topic: Reminder to presenters: submit slides Thread-Index: Ac6LpIcdxhdXQBWsQJ+Gj7eBk/kKJw== Date: Sun, 28 Jul 2013 15:11:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:df8:0:64:3c1d:68cd:d64c:aadd] x-forefront-prvs: 0921D55E4F Content-Type: multipart/alternative; boundary="_000_d04b2030500d44f789e5c23e895442abBY2PR03MB269namprd03pro_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: BY2PR03MB269.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC102.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC102.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: [BEHAVE] Reminder to presenters: submit slides X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2013 15:13:59 -0000 --_000_d04b2030500d44f789e5c23e895442abBY2PR03MB269namprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If you are on the agenda tomorrow and haven't send slides yet, please do so= asap. All the slides I've seen so far are currently posted. We plan to have all slides on the same laptop so you don't need to use your= own. -Dave --_000_d04b2030500d44f789e5c23e895442abBY2PR03MB269namprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

If you are on the agenda tomorrow and haven’t = send slides yet, please do so asap.

All the slides I’ve seen so far are currently = posted.

 

We plan to have all slides on the same laptop so you= don’t need to use your own.

 

-Dave

--_000_d04b2030500d44f789e5c23e895442abBY2PR03MB269namprd03pro_-- From maxpassion@gmail.com Mon Jul 29 05:26:25 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B584421F9DA3 for ; Mon, 29 Jul 2013 05:26:24 -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, HTML_MESSAGE=0.001, 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 Pehk+yRuka2g for ; Mon, 29 Jul 2013 05:26:22 -0700 (PDT) Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 033D421F9AB4 for ; Mon, 29 Jul 2013 05:25:59 -0700 (PDT) Received: by mail-vc0-f174.google.com with SMTP id gd11so2006714vcb.19 for ; Mon, 29 Jul 2013 05:25:53 -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=HaFgtzSYcWs1sEPF6X1AtnE5ZZI4deSpk42Ltg42Wpw=; b=G67yZW+5bD3aZ6hp0Q4Kp0xGR2SSUxTrh7NgKN80qP6Q5NJ+UxNrcfGcwqJRlCF+HB Oa1zJWjVjVcPAV11iII0IvGro8zm2X7njaC/kaPLlIGHI4P21g6oBU0aVIvECWrL7C8J HOU88mD05oZzTYBOo5bdenjcpQNW80XpIcF031DaAt6RAIceUL7SzlYH62RjnzmN2qi4 sKWj4klKpbKZxfnjelYjU8H25yQ67VFRITYPDpmJMePeGco8EwOafTL7Jwy3NuvcDVZ/ SO0x9m7I/IwJoEOIu5t5bOC37IVM4NcqIFPL/Y6WB+EbAC1QbyRLO1YQ2/sqV05TjX8Z zIhw== MIME-Version: 1.0 X-Received: by 10.220.167.2 with SMTP id o2mr8464007vcy.61.1375100753784; Mon, 29 Jul 2013 05:25:53 -0700 (PDT) Received: by 10.220.142.130 with HTTP; Mon, 29 Jul 2013 05:25:53 -0700 (PDT) In-Reply-To: References: Date: Mon, 29 Jul 2013 20:25:53 +0800 Message-ID: From: Liu Dapeng To: Qiong Content-Type: multipart/alternative; boundary=089e011618cef5b42d04e2a597a9 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] Fwd: I-D Action: draft-sun-behave-v4tov6-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 12:26:25 -0000 --089e011618cef5b42d04e2a597a9 Content-Type: text/plain; charset=ISO-8859-1 Hi Qiong: I am wondering whether you are aware of that NAT46 has been discussed three years ago in Behave. For example http://tools.ietf.org/html/draft-liu-behave-nat46-02 have proposed a solution for NAT46. Maybe you could leverage on that. Dapeng Liu 2013/7/9 Qiong > Dear all, > > We have submitted a new draft for IPv4 client to IPv6 server. It is > designed to cover the Scenario 2 in RFC6144. It can save the public IPv4 > addresses consumed by IPv6 side and does not have impact on existing > applications. > > Your comments/reviews are appreciated. > > Best wishes > Qiong > > > ---------- Forwarded message ---------- > From: internet-drafts@ietf.org > Date: Mon, 08 Jul 2013 08:16:36 -0700 > Subject: I-D Action: draft-sun-behave-v4tov6-00.txt > To: i-d-announce@ietf.org > > A new version of I-D, draft-sun-behave-v4tov6-00.txt > has been successfully submitted by Chongfeng Xie and posted to the > IETF repository. > > Filename: draft-sun-behave-v4tov6 > Revision: 00 > Title: The Approach for IPv4-only users to access IPv6-only Content > Creation date: 2013-07-08 > Group: Individual Submission > Number of pages: 13 > URL: http://www.ietf.org/internet-drafts/draft-sun-behave-v4tov6-00.txt > Status: http://datatracker.ietf.org/doc/draft-sun-behave-v4tov6 > Htmlized: http://tools.ietf.org/html/draft-sun-behave-v4tov6-00 > > > Abstract: > Current approaches can not solve the scenario that the users from > IPv4 Internet to access IPv6-only content. When IPv6 content are > becoming more and more popular, it is important to ensure that IPv6- > only content can be reachable from legacy IPv4-only clients via some > IPv4-only network. This document proposes two approaches for IPv4- > only users to access IPv6-only content. It is designed to cover the > Scenario 2 in [RFC6144]. > > > > > > The IETF Secretariat > > -- > ============================================== > Qiong Sun > China Telecom Beijing Research Institute > > > Open source code: > lightweight 4over6: *http://sourceforge.net/projects/laft6/* > PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * > =============================================== > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > -- ------ Best Regards, Dapeng Liu --089e011618cef5b42d04e2a597a9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Qiong:

I am wondering whether = you are aware of that NAT46 has been discussed three years ago in Behave. F= or example http://tools.ietf.org/html/draft-liu-behave-nat46-02 have proposed a s= olution for NAT46. Maybe you could leverage on that.

Dapeng Liu


2013/7/9 Qiong &= lt;bingxuere@gmail= .com>
Dear all,

We have submitted a new draft for IPv4 client to IPv6 server. It is desi= gned to cover the Scenario=A02=A0= in RFC6144. It can save the public IPv4 addresses consumed by IPv6 side and= does not have impact on existing applications.

Your comments/reviews are appreciated.

Best wishes
Qiong


---------- Forwarded message ----------
From:=A0= internet-drafts@ietf.org
Date: Mon, 08 J= ul 2013 08:16:36 -0700
Sub= ject: I-D Action:=A0draft-sun-behav= e-v4tov6-00.txt
To:=A0i-d-announce@ietf.org

A=A0new=A0version=A0of=A0I-D,=A0draft-sun-behave-= v4tov6-00.txt
has=A0been=A0successfully=A0submitted=A0by=A0Chongfeng=A0Xie=A0and=A0p= osted=A0to=A0the
IETF=A0repository.
=A0
Filename: =A0draft-sun-behave-v4tov6
Revision: =A000
Title: =A0The=A0Approach=A0for=A0IPv4-only=A0users=A0to=A0access=A0IPv= 6-only=A0Content
Creation=A0date: =A02013-07-08
Group: =A0Individual=A0Submission
Number=A0of=A0pages:=A013
=A0
=A0
Abstract:
=A0=A0=A0Current=A0approaches=A0can=A0not=A0solve=A0the=A0scenario=A0t= hat=A0the=A0users=A0from
=A0=A0=A0IPv4=A0Internet=A0to=A0access=A0IPv6-only=A0content.=A0=A0Whe= n=A0IPv6=A0content=A0are
=A0=A0=A0becoming=A0more=A0and=A0more=A0popular,=A0it=A0is=A0important= =A0to=A0ensure=A0that=A0IPv6-
=A0=A0=A0only=A0content=A0can=A0be=A0reachable=A0from=A0legacy=A0IPv4-= only=A0clients=A0via=A0some
=A0=A0=A0IPv4-only=A0network.=A0=A0This=A0document=A0proposes=A0two=A0= approaches=A0for=A0IPv4-
=A0=A0=A0only=A0users=A0to=A0access=A0IPv6-only=A0content.=A0=A0It=A0i= s=A0designed=A0to=A0cover=A0the
=A0=A0=A0Scenario=A02=A0in=A0[RFC6144].
=A0
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0
=A0
=A0
The=A0IETF=A0Secretariat

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


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

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




--

----= --
Best Regards,
Dapeng Liu
--089e011618cef5b42d04e2a597a9-- From egied.dekoster@belgacom.be Mon Jul 29 05:38:30 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00AC421F9D17 for ; Mon, 29 Jul 2013 05:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.379 X-Spam-Level: X-Spam-Status: No, score=-0.379 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, TVD_SPACE_RATIO=2.219] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v+uWdCgcgQxY for ; Mon, 29 Jul 2013 05:38:25 -0700 (PDT) Received: from mx13.belgacom.be (mx13.belgacom.be [195.13.15.233]) by ietfa.amsl.com (Postfix) with ESMTP id E987B21F9E34 for ; Mon, 29 Jul 2013 05:38:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,768,1367964000"; d="scan'208,217";a="30646861" Received: from a03007.bgc.net ([10.120.129.162]) by mx13.belgacom.be with ESMTP; 29 Jul 2013 14:38:13 +0200 X-TM-IMSS-Message-ID: <22bb610d00066604@belgacom.be> Received: from A04023.BGC.NET ([10.120.135.24]) by belgacom.be ([10.120.129.162]) with ESMTP (TREND IMSS SMTP Service 7.1; TLSv1/SSLv3 AES128-SHA (128/128)) id 22bb610d00066604 ; Mon, 29 Jul 2013 14:38:11 +0200 Received: from A04046.BGC.NET ([10.120.135.32]) by A04023.BGC.NET ([10.120.135.24]) with mapi id 14.02.0318.004; Mon, 29 Jul 2013 14:38:11 +0200 From: "DEKOSTER Egied (NEO/NBE)" To: "Behave@ietf.org" Thread-Topic: unsubscribe Thread-Index: Ac6MWHtvPAG+w5otROKoazgwpkQSMA== Date: Mon, 29 Jul 2013 12:38:10 +0000 Message-ID: Accept-Language: nl-BE, en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.115.45.17] Content-Type: multipart/alternative; boundary="_000_E3B89F472923B344B9BE944CF4A841101D261176A04046BGCNET_" MIME-Version: 1.0 Subject: [BEHAVE] unsubscribe X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 12:38:30 -0000 --_000_E3B89F472923B344B9BE944CF4A841101D261176A04046BGCNET_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ________________________________ ***** Disclaimer ***** http://www.belgacom.be/maildisclaimer --_000_E3B89F472923B344B9BE944CF4A841101D261176A04046BGCNET_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 



***** Disclaimer *****
http://www.belgacom.be/maildisclaimer
 --_000_E3B89F472923B344B9BE944CF4A841101D261176A04046BGCNET_-- From maxpassion@gmail.com Mon Jul 29 05:44:43 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 217E421F9F59 for ; Mon, 29 Jul 2013 05:44:43 -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, HTML_MESSAGE=0.001, 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 rjaXuEP7dsii for ; Mon, 29 Jul 2013 05:44:42 -0700 (PDT) Received: from mail-ve0-x22a.google.com (mail-ve0-x22a.google.com [IPv6:2607:f8b0:400c:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 1CEBE21F9E24 for ; Mon, 29 Jul 2013 05:44:29 -0700 (PDT) Received: by mail-ve0-f170.google.com with SMTP id 15so228805vea.29 for ; Mon, 29 Jul 2013 05:44:28 -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=efRoNgtgPc/LPnsvEvgl3ddjlyjdujlmKl9ZARlUP6o=; b=bjxd/b+6RfUp3xyzRLMIgniSmLJSkZaL/l8zhCc5O+3NkVDS9tx4UpD67GTRs+zBaq V/8G45WbKFwTGm8PEkEOZmbIRLuUCmko0WBAh+wGQDNdNbKGVQmUeka7AfWhMv8r+M/X ve45Ky20zTebEYGxBf9RO9U66QHuARd6FzGzZ1GJLbkxNpg31mQuzUe1cyY7nGlJ/tAU b0WFixuXGvTMMymZz7PbKt6/ZNR3RWz8UIpcHkTfwl+iMmVY+Ksf1NnYGczziR6e6SfI gFx0fcZL/TuMWYzEOa/6nuGJ5SFW4rDPOhs0uBR19v1dguyj9xaiSnDj+eGTCasFFyHq /gXg== MIME-Version: 1.0 X-Received: by 10.52.34.40 with SMTP id w8mr21413622vdi.7.1375101868582; Mon, 29 Jul 2013 05:44:28 -0700 (PDT) Received: by 10.220.142.130 with HTTP; Mon, 29 Jul 2013 05:44:28 -0700 (PDT) Date: Mon, 29 Jul 2013 20:44:28 +0800 Message-ID: From: Liu Dapeng To: branimir.rajtar@t.ht.hr, Behave WG Content-Type: multipart/alternative; boundary=20cf307cfec0682c7804e2a5da97 Subject: [BEHAVE] NAT46 draft X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 12:44:43 -0000 --20cf307cfec0682c7804e2a5da97 Content-Type: text/plain; charset=ISO-8859-1 Hello Branimir and all, Below is the link of the NAT46 solution draft that I mentioned in the meeting. http://tools.ietf.org/html/draft-liu-behave-nat46-02 -- ------ Best Regards, Dapeng Liu --20cf307cfec0682c7804e2a5da97 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello=A0Bra= nimir and all,

Below is the link of the NAT46= solution draft that I mentioned in the meeting.

<= a href=3D"http://tools.ietf.org/html/draft-liu-behave-nat46-02">http://tool= s.ietf.org/html/draft-liu-behave-nat46-02

--

------
Best Regards,
Dapeng Liu
--20cf307cfec0682c7804e2a5da97-- From ivan@cacaoweb.org Mon Jul 29 06:01:57 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECE0421F9E01 for ; Mon, 29 Jul 2013 06:01: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 CZC8SixSAka7 for ; Mon, 29 Jul 2013 06:01:51 -0700 (PDT) Received: from mail.cacaoweb.org (mail.cacaoweb.org [46.105.102.78]) by ietfa.amsl.com (Postfix) with ESMTP id 3D29B21F9E27 for ; Mon, 29 Jul 2013 06:01:48 -0700 (PDT) Received: from www-data by mail.cacaoweb.org with local (Exim 4.72) (envelope-from ) id 1V3n6N-0005Y0-Rc; Mon, 29 Jul 2013 15:03:03 +0200 To: Simon Perreault X-PHP-Originating-Script: 0:func.inc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Date: Mon, 29 Jul 2013 15:03:03 +0200 From: ivan c Organization: cacaoweb In-Reply-To: <51F60AA1.6010900@viagenie.ca> References: <51F60AA1.6010900@viagenie.ca> Message-ID: X-Sender: ivan@cacaoweb.org User-Agent: RoundCube Webmail/0.3.1 Cc: Behave , draft-ietf-behave-requirements-update@tools.ietf.org, behave-chairs@tools.ietf.org Subject: Re: [BEHAVE] requirements-update slides X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ivan@cacaoweb.org List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 13:01:57 -0000 On Mon, 29 Jul 2013 08:24:33 +0200, Simon Perreault wrote: > (previous mail sent by mistake) > > This is what I have. > > Co-authors, let me know if anything needs changing. > > Ivan, the BEHAVE meeting is today. See here: > https://tools.ietf.org/wg/behave/agenda > > Please have a look especially at slide titled "Proposal B". I tried to > capture your proposal, but I'm sure I didn't do it perfectly. Let me > know if you could provide a better description. > > Remote attending is possible. There is an audio stream: > http://ietf87streaming.dnsalias.net/ietf/ietf872.m3u > > and a jabber chatroom: xmpp:behave@jabber.ietf.org?join > > You can ask questions in the jabber chatroom and people will relay them > to the mic. > > Simon About the proposal A: The "MAY do EDM" seems reasonable at first but one shortcoming is the "how to determine this is out of scope" because in general, it is not possible to classify a protocol based on network traffic (by DPI or behavioral observations). For example, P2P applications often wrap their traffic in HTTP or HTTPS to avoid blocking or throttling by the ISP. Also, non-P2P applications will generally use new ephemeral ports for each new communication anyway, so I would suspect the real-world use cases for this to be empty. About the proposal B: This captures accurately some of the ideas we exchanged on this mailing list. I'm going to write a structured text about the topic to translate these ideas into something consistent. Give it a day or two. -- _Ivan Chollet_ From bingxuere@gmail.com Mon Jul 29 06:12:50 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A8BF21F9F6C for ; Mon, 29 Jul 2013 06:12:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 LlhB+VCytSfh for ; Mon, 29 Jul 2013 06:12:49 -0700 (PDT) Received: from mail-ve0-x236.google.com (mail-ve0-x236.google.com [IPv6:2607:f8b0:400c:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id BB60121F9FCA for ; Mon, 29 Jul 2013 06:12:48 -0700 (PDT) Received: by mail-ve0-f182.google.com with SMTP id m1so2440835ves.41 for ; Mon, 29 Jul 2013 06:12:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=JqX0qb7jFSJQ0JxLRUTyqYtTla+BoYHZ/d+hY307Frs=; b=GWKyYBRYW9bBc1NZFHW7esA8NUMEhr2RKtVeV9OpcZuIOBGKyL30/LMOFL5FaLCXYC zs5VJjkzuvyOwsq0b6LdOVQPTKWWihsUClnKRlhP6hFZUrd1R4ShzogIU9lIK1P30wYq qa/NO6C5UvryuTTci98qSV7cVmr2+h0DkXpM5JhgRrsLoUQ5Ck1c2llAdqkmb/f5bt/9 lCdgd3Rjlpj6p+bAT+BxfDICTUMxxAyFZPT7k8cXw4eOrmALsmMto+zhox/vLaNl+62/ rqtw+8Fod1ltUGIRecqzR3nyFt+rWXAuZzv8XKfMDhzJRc5WdXE/gXOyYT/gfXoPYbJ2 I2zw== X-Received: by 10.221.56.194 with SMTP id wd2mr115298vcb.7.1375103567057; Mon, 29 Jul 2013 06:12:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.187.66 with HTTP; Mon, 29 Jul 2013 06:12:06 -0700 (PDT) In-Reply-To: References: From: Qiong Date: Mon, 29 Jul 2013 21:12:06 +0800 Message-ID: To: Liu Dapeng Content-Type: multipart/alternative; boundary=001a11337ef6a4dd8204e2a63fb4 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] Fwd: I-D Action: draft-sun-behave-v4tov6-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 13:12:50 -0000 --001a11337ef6a4dd8204e2a63fb4 Content-Type: text/plain; charset=UTF-8 Hi Dapeng, Thanks for pointing out. I think the major difference is that we use static mapping while draft-liu-behave-nat46 uses dynamic mapping. That's why we do not need to embed DNS46 in the translator. Best wishes Qiong On Mon, Jul 29, 2013 at 8:25 PM, Liu Dapeng wrote: > Hi Qiong: > > I am wondering whether you are aware of that NAT46 has been discussed > three years ago in Behave. For example > http://tools.ietf.org/html/draft-liu-behave-nat46-02 have proposed a > solution for NAT46. Maybe you could leverage on that. > > Dapeng Liu > > > 2013/7/9 Qiong > >> Dear all, >> >> We have submitted a new draft for IPv4 client to IPv6 server. It is >> designed to cover the Scenario 2 in RFC6144. It can save the public IPv4 >> addresses consumed by IPv6 side and does not have impact on existing >> applications. >> >> Your comments/reviews are appreciated. >> >> Best wishes >> Qiong >> >> >> ---------- Forwarded message ---------- >> From: internet-drafts@ietf.org >> Date: Mon, 08 Jul 2013 08:16:36 -0700 >> Subject: I-D Action: draft-sun-behave-v4tov6-00.txt >> To: i-d-announce@ietf.org >> >> A new version of I-D, draft-sun-behave-v4tov6-00.txt >> has been successfully submitted by Chongfeng Xie and posted to the >> IETF repository. >> >> Filename: draft-sun-behave-v4tov6 >> Revision: 00 >> Title: The Approach for IPv4-only users to access IPv6-only Content >> Creation date: 2013-07-08 >> Group: Individual Submission >> Number of pages: 13 >> URL: http://www.ietf.org/internet-drafts/draft-sun-behave-v4tov6-00.txt >> Status: http://datatracker.ietf.org/doc/draft-sun-behave-v4tov6 >> Htmlized: http://tools.ietf.org/html/draft-sun-behave-v4tov6-00 >> >> >> Abstract: >> Current approaches can not solve the scenario that the users from >> IPv4 Internet to access IPv6-only content. When IPv6 content are >> becoming more and more popular, it is important to ensure that IPv6- >> only content can be reachable from legacy IPv4-only clients via some >> IPv4-only network. This document proposes two approaches for IPv4- >> only users to access IPv6-only content. It is designed to cover the >> Scenario 2 in [RFC6144]. >> >> >> >> >> >> The IETF Secretariat >> >> -- >> ============================================== >> Qiong Sun >> China Telecom Beijing Research Institute >> >> >> Open source code: >> lightweight 4over6: *http://sourceforge.net/projects/laft6/* >> PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * >> =============================================== >> >> >> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave >> >> > > > -- > > ------ > Best Regards, > Dapeng Liu > -- ============================================== Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/* PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * =============================================== --001a11337ef6a4dd8204e2a63fb4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Dapeng,

Thanks for pointing ou= t. I think the major difference is that we use static mapping while draft-l= iu-behave-nat46 uses dynamic mapping. That's why we do not need to embe= d DNS46 in the translator.

Best wishes
Qiong


On Mon, Jul= 29, 2013 at 8:25 PM, Liu Dapeng <maxpassion@gmail.com> w= rote:
Hi Qiong:

I am wondering whether you are aware of that NAT46 has been discussed thr= ee years ago in Behave. For example http://tools.ietf.org/html/draf= t-liu-behave-nat46-02 have proposed a solution for NAT46. Maybe you cou= ld leverage on that.

Dapeng Liu

2013/7/9 Qiong <bingxuere@gmail.com&g= t;
Dear all,

We have submitted a new draft for IPv4 client to IPv6 server. It is desi= gned to cover the Scenario=C2=A02= =C2=A0in RFC6144. It can save the public IPv4 addresses consumed by IPv6 si= de and does not have impact on existing applications.

Your comments/reviews are appreciated.

Best wishes
Qiong


---------- Forwarded message ----------
From:=C2=A0internet-drafts@ietf.org Date: Mon, 08 J= ul 2013 08:16:36 -0700
Sub= ject: I-D Action:=C2=A0draft-sun-be= have-v4tov6-00.txt
To:=C2=A0i-d-announce@ietf.org

A=C2=A0new=C2=A0version=C2=A0of=C2=A0I-D,=C2=A0dr= aft-sun-behave-v4tov6-00.txt
has=C2=A0been=C2=A0successfully=C2=A0submitted=C2=A0by=C2=A0Chongfeng= =C2=A0Xie=C2=A0and=C2=A0posted=C2=A0to=C2=A0the
IETF=C2=A0repository.
=C2=A0
Filename: =C2=A0draft-sun-behave-v4tov6
Revision: =C2=A000
Title: =C2=A0The=C2=A0Approach=C2=A0for=C2=A0IPv4-only=C2=A0users=C2= =A0to=C2=A0access=C2=A0IPv6-only=C2=A0Content
Creation=C2=A0date: =C2=A02013-07-08
Group: =C2=A0Individual=C2=A0Submission
Number=C2=A0of=C2=A0pages:=C2=A013
=C2=A0
=C2=A0
Abstract:
=C2=A0=C2=A0=C2=A0Current=C2=A0approaches=C2=A0can=C2=A0not=C2=A0solve= =C2=A0the=C2=A0scenario=C2=A0that=C2=A0the=C2=A0users=C2=A0from
=C2=A0=C2=A0=C2=A0IPv4=C2=A0Internet=C2=A0to=C2=A0access=C2=A0IPv6-onl= y=C2=A0content.=C2=A0=C2=A0When=C2=A0IPv6=C2=A0content=C2=A0are
=C2=A0=C2=A0=C2=A0becoming=C2=A0more=C2=A0and=C2=A0more=C2=A0popular,= =C2=A0it=C2=A0is=C2=A0important=C2=A0to=C2=A0ensure=C2=A0that=C2=A0IPv6-
=C2=A0=C2=A0=C2=A0only=C2=A0content=C2=A0can=C2=A0be=C2=A0reachable=C2= =A0from=C2=A0legacy=C2=A0IPv4-only=C2=A0clients=C2=A0via=C2=A0some
=C2=A0=C2=A0=C2=A0IPv4-only=C2=A0network.=C2=A0=C2=A0This=C2=A0documen= t=C2=A0proposes=C2=A0two=C2=A0approaches=C2=A0for=C2=A0IPv4-
=C2=A0=C2=A0=C2=A0only=C2=A0users=C2=A0to=C2=A0access=C2=A0IPv6-only= =C2=A0content.=C2=A0=C2=A0It=C2=A0is=C2=A0designed=C2=A0to=C2=A0cover=C2=A0= the
=C2=A0=C2=A0=C2=A0Scenario=C2=A02=C2=A0in=C2=A0[RFC6144].
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
=C2=A0
=C2=A0
The=C2=A0IETF=C2=A0Secretariat

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


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

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




--

------
Best Regards,Dapeng Liu



--
=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Qiong Sun
China T= elecom Beijing Research Institude


Open source code:
lightweig= ht 4over6: http://sourceforge.net/projects/laft6/
PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--001a11337ef6a4dd8204e2a63fb4-- From repenno@cisco.com Mon Jul 29 06:33:42 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 934FE21F8E98 for ; Mon, 29 Jul 2013 06:33:42 -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=[AWL=-0.000, 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 TEGGYxsNWyDj for ; Mon, 29 Jul 2013 06:33:36 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id AB97D21F9F9D for ; Mon, 29 Jul 2013 06:33:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1143; q=dns/txt; s=iport; t=1375104816; x=1376314416; h=from:to:subject:date:message-id:mime-version; bh=8wX3RiBrfUXrfRrxqJywWO1gucB/vapHobQjC9gDAWQ=; b=NoFhcNHl26DEXv44wP75uhAy54M3lA/Bonc58dov+Q0wJWIV1a0U4uFJ /X+uTVT3Id8VUEWgLApPFqrmquMLEGY/6/+SvtFKagZdMoidECpUh6unQ pPXjbpPUYHnpbeQaZbErL+o7DwKBk6RQLQsibdQcoQnMWlnYxaGiK9k0T Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AngFAF9u9lGtJXG8/2dsb2JhbABbgkJEgQW8SoEOgRcWdIIbCwEEgQsBCwECHFYnBBuICJdYoCyPTINQbwOpK4MUgio X-IronPort-AV: E=Sophos;i="4.89,769,1367971200"; d="scan'208,217";a="240819103" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-6.cisco.com with ESMTP; 29 Jul 2013 13:33:36 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6TDXZhM018557 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 29 Jul 2013 13:33:35 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.99]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Mon, 29 Jul 2013 08:33:35 -0500 From: "Reinaldo Penno (repenno)" To: "behave@ietf.org" Thread-Topic: draft-meng-behave-napgt can be met by PCP port set Thread-Index: AQHOjGA59IdJN/lsnUyDa+btgAHUzQ== Date: Mon, 29 Jul 2013 13:33:35 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F0604090E84AA@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.86.247.249] Content-Type: multipart/alternative; boundary="_000_45A697A8FFD7CF48BCF2BE7E106F0604090E84AAxmbrcdx04ciscoc_" MIME-Version: 1.0 Subject: [BEHAVE] draft-meng-behave-napgt can be met by PCP port set X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 13:33:42 -0000 --_000_45A697A8FFD7CF48BCF2BE7E106F0604090E84AAxmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable After watching this presentation that generated some ML discussion, it seem= s to me requirements can be fully met with PCP port set. Thanks, Reinaldo --_000_45A697A8FFD7CF48BCF2BE7E106F0604090E84AAxmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <4363A7DBAF5C8047844696F3E285A862@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
After watching this presentation that generated some ML discussion, it= seems to me requirements can be fully met with PCP port set.

Thanks,

Reinaldo
--_000_45A697A8FFD7CF48BCF2BE7E106F0604090E84AAxmbrcdx04ciscoc_-- From ajs@anvilwalrusden.com Mon Jul 29 06:46:38 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 845E421F9EDF for ; Mon, 29 Jul 2013 06:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vU8v47Xs3YHy for ; Mon, 29 Jul 2013 06:46:30 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id B172E21F9ECA for ; Mon, 29 Jul 2013 06:46:26 -0700 (PDT) Received: from mx1.yitter.info (dhcp-64bf.meeting.ietf.org [130.129.100.191]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 93A0F8A031 for ; Mon, 29 Jul 2013 13:46:24 +0000 (UTC) Date: Mon, 29 Jul 2013 09:46:23 -0400 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20130729134623.GD51737@mx1.yitter.info> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [BEHAVE] Fwd: I-D Action: draft-sun-behave-v4tov6-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 13:46:38 -0000 On Mon, Jul 29, 2013 at 09:12:06PM +0800, Qiong wrote: > Thanks for pointing out. I think the major difference is that we use static > mapping while draft-liu-behave-nat46 uses dynamic mapping. That's why we do > not need to embed DNS46 in the translator. Regardless of the advantages of any one technique, I don't understand why this is a thing that one ought to do at all. What problem does it solve to make v4-only nodes initiate connections to the v6 network? Why is that a problem we ought to solve? I suggest that it is a problem we do _not_ want to solve. It keeps v4-only nodes alive longer. That's not a goal I share. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From meng.wei2@zte.com.cn Mon Jul 29 06:53:40 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C384B21F9926; Mon, 29 Jul 2013 06:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.245 X-Spam-Level: X-Spam-Status: No, score=-100.245 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, MIME_BASE64_TEXT=1.753, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OGGfvBx86wo2; Mon, 29 Jul 2013 06:53:32 -0700 (PDT) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 90ABB11E80DE; Mon, 29 Jul 2013 06:52:25 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 2E3791339480; Mon, 29 Jul 2013 21:51:52 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 547607397DA; Mon, 29 Jul 2013 21:51:51 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id r6TDpfvc094019; Mon, 29 Jul 2013 21:51:41 +0800 (GMT-8) (envelope-from meng.wei2@zte.com.cn) In-Reply-To: To: "Senthil Sivakumar (ssenthil)" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: meng.wei2@zte.com.cn Date: Mon, 29 Jul 2013 21:51:40 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2013-07-29 21:51:29, Serialize complete at 2013-07-29 21:51:29 Content-Type: multipart/alternative; boundary="=_alternative 004C2B2D48257BB7_=" X-MAIL: mse01.zte.com.cn r6TDpfvc094019 Cc: "Reinaldo Penno \(repenno\)" , "behave-bounces@ietf.org" , "behave@ietf.org" , "Dan Wing \(dwing\)" Subject: Re: [BEHAVE] NAPGT request for comments, THANKS! X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 13:53:41 -0000 This is a multipart message in MIME format. --=_alternative 004C2B2D48257BB7_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgYWxsLA0KICBJdCdzIGEgcGl0dHkgSSBnb3Qgbm8gY29tbWVudCBhZnRlciBteSBwcmVzZW50 YXRpb24gZHVlIHRvIGxhY2sgb2YgDQptZWV0aW5nIHRpbWUuDQogIEl0IGlzIGFuIGltcG9ydGFu dCBpc3N1ZSB3aGljaCBzbWFsbCBmaXJtcy9mYW1pbHkgRElZZXJzLy4uLiBtdXN0IGZhY2UgDQp0 bw0Kd2hlbiBOQVQgaGFzIGJlZW4gZGVwbG95ZWQuIFRoZXkgYXR0ZW1wdCB0byBhY2hpZXZlIGFj Y2Vzc2luZyBpbnRlcm5hbCANCnNlcnZlciANCmZyb20gZXh0ZXJuYWwgbmV0d29yayBlbnZpcm9u bWVudCB3aXRob3V0IGFuIGV4dHJhIHB1YmxpYyBJUCBhZGRyZXNzLg0KDQogIEFyZSB5b3UgaW50 ZXJlc3RlZCBpbiB0aGlzIHRvcGljPw0KDQogIFBsZWFzZSBzZWUgdGhlIHNjZW5hcmlvIGluIHNs aWRlcy4gDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvYWdlbmRhLzg3L3NsaWRlcy9zbGlkZXMtODct YmVoYXZlLTQucGRmDQoNClRoYW5rcyBmb3IgY29tbWVudHMuDQoNCkNoZWVycywNCldlaQ0KIA0K DQoNCmJlaGF2ZS1ib3VuY2VzQGlldGYub3JnICAyMDEzLzA3LzE4IDIyOjMxOjAwOg0KDQo+IEZy b206ICJtZW5nLndlaTJAenRlLmNvbS5jbiIgPG1lbmcud2VpMkB6dGUuY29tLmNuPg0KPiBEYXRl OiBXZWRuZXNkYXksIEp1bHkgMTcsIDIwMTMgOToxOSBQTQ0KPiBUbzogU2VudGhpbCBTaXZha3Vt YXIgPHNzZW50aGlsQGNpc2NvLmNvbT4NCj4gQ2M6ICJiZWhhdmVAaWV0Zi5vcmciIDxiZWhhdmVA aWV0Zi5vcmc+LCAiYmVoYXZlLWJvdW5jZXNAaWV0Zi5vcmciIDwNCj4gYmVoYXZlLWJvdW5jZXNA aWV0Zi5vcmc+LCAiRGFuIFdpbmcgKGR3aW5nKSIgPGR3aW5nQGNpc2NvLmNvbT4sIA0KPiAiUmVp bmFsZG8gUGVubm8gKHJlcGVubm8pIiA8cmVwZW5ub0BjaXNjby5jb20+DQo+IFN1YmplY3Q6IFJl OiBSZTogW0JFSEFWRV0gTkFQR1QgcmVxdWVzdCBmb3IgY29tbWVudHMsIFRIQU5LUyENCj4gDQo+ IA0KPiBIaSwgDQo+ICAgUGxlYXNlIHNlZSBpbmxpbmUuIA0KPiANCj4gVGhhbmtzLCANCj4gV2Vp IA0KPiANCj4gIlNlbnRoaWwgU2l2YWt1bWFyIChzc2VudGhpbCkiIDxzc2VudGhpbEBjaXNjby5j b20+ICAyMDEzLTA3LTE3IA0KMjE6MzA6MjQ6DQo+IA0KPiA+IEZyb206ICJtZW5nLndlaTJAenRl LmNvbS5jbiIgPG1lbmcud2VpMkB6dGUuY29tLmNuPg0KPiA+IERhdGU6IFdlZG5lc2RheSwgSnVs eSAxNywgMjAxMyA0OjA4IEFNDQo+ID4gVG86ICJSZWluYWxkbyBQZW5ubyAocmVwZW5ubykiIDxy ZXBlbm5vQGNpc2NvLmNvbT4NCj4gPiBDYzogImJlaGF2ZS1ib3VuY2VzQGlldGYub3JnIiA8YmVo YXZlLWJvdW5jZXNAaWV0Zi5vcmc+LCANCiJiZWhhdmVAaWV0Zi5vcmciIDwNCj4gPiBiZWhhdmVA aWV0Zi5vcmc+LCAiRGFuIFdpbmcgKGR3aW5nKSIgPGR3aW5nQGNpc2NvLmNvbT4NCj4gPiBTdWJq ZWN0OiBSZTogW0JFSEFWRV0gTkFQR1QgcmVxdWVzdCBmb3IgY29tbWVudHMsIFRIQU5LUyEgDQo+ ID4gDQo+ID4gDQo+ID4gSGksIA0KPiA+ICAgSSBnb3Qgd2hhdCB0aGUgZXhhbXBsZSBtZWFucy4g DQo+ID4gDQo+ID4gICAxLTEwMjQgaXMganVzdCBhbiBleGFtcGxlLCB0aGUgcmFuZ2UgY291bGQg YmUgYW55IHZhbGlkIHZhbHVlLg0KPiA+IA0KPiA+ICAgIjwxLTEwMjQ+IG1pZ2h0IGJlIHVzZWQg YXMgTkFULCA8MTAyNS02NTUzNT4gbWlnaHQgYmUgdXNlZCBhcyANCj4gPiBkeW5hbWljIE5BUFQi LCBleGFtcGxlIGlzIGFzIGJlbG93LiANCj4gPiANCj4gPiAgICArLS0tLS0tLS0tLSsgICAgICst LS0tLSsgICAgKy0tLS0tLS0tKyANCj4gPiAgICArIEludGVybmV0ICsgLS0tLSsgTkFUICstLS0t KyBTZXJ2ZXIgKyANCj4gPiAgICArLS0tLS0tLS0tLSsgICAgICstLS0tLSsgICAgKy0tLS0tLS0t KyANCj4gPiANCj4gPiAgICAoMSkgIjwxLTEwMjQ+IG1pZ2h0IGJlIHVzZWQgYXMgTkFUIiBtZWFu cywgDQo+ID4gICAgICAgIEEgc2VydmVyIGJlaGluZCBhIE5BVC4gDQo+ID4gICAgQSBtZXNzYWdl LCBzZW50IGJ5IHNlcnZlciwgaXRzIHNvdXJjZSBwb3J0IGlzIGluIDEtMTAyNCAob3IgDQo+ID4g NDUwMC00NTAxIG9yIC4uLikuDQo+ID4gICAgVGhlIHNvdXJjZSBhZGRyZXNzIHdpbGwgYmUgY29u dmVydGVkIGJ5IE5BVCwgdGhlIHNvdXJjZSBwb3J0IA0KcmVtYWlucw0KPiA+ICAgIHRoZSBzYW1l LiANCj4gPiANCj4gPiBbU2VudGhpbF0gU29ycnksIEkgZGlkbqGvdCByZWFkIHRoZSBkcmFmdCwg YnV0IHRoZSBhYm92ZSBsb2dpYyB3b250IA0KPiA+IHdvcmsgaWYgdGhlcmUgYXJlIG11bHRpcGxl IHNlcnZlcnMgdXNpbmcgdGhlIHNhbWUgc291cmNlIHBvcnQuIA0KPiA+IEFsc28sIGluIHNvbWUg YXBwbGljYXRpb25zIChJIHRoaW5rIHJjbWQsIHJzaGVsbCBldGMpLCB0aGUgc291cmNlIA0KPiA+ IHBvcnQgZG9lc26hr3QgaGF2ZSB0byBiZSBwcmVzZXJ2ZWQgYnV0IG11c3QgYmUgYmVsb3cgMTAy NC4gDQo+ID4gDQo+ID4gU2VudGhpbCANCj4gDQo+IFtXZWldIEknbSBwcmVzZW50aW5nIHRoZSBw cm9wb3NhbCBzbyBhcyB0byBzb2x2ZSB0aGlzIHByb2JsZW0gOiBhc3NpZ24gDQpwb3J0IA0KPiB4 LXkoaS5lLiAxLTEwMjQpIHRvIGEgc2VydmVyKGZvciBwb3J0IHByZXNlcnZpbmcgZnVuY3Rpb24s IGxpa2UgTkFUKSwgDQphc3NpZ24gDQo+IHRoZSByZXN0IG9mIHBvcnRzIHRvIG90aGVycyhmb3Ig Y29tbW9uIE5BUFQpLiANCj4gICBPZiBjb3Vyc2UsIGlmIHRoZXJlIGFyZSBtYW55IHNlcnZlcnMg YmViaW5kIE5BVCBhbmQgd2hldGhlciBvciBub3QgDQp1c2luZyANCj4gdGhlIHNhbWUgc291cmNl IHBvcnQsIE5BVCBoYXMgdG8gbmVlZCBtb3JlIHRoYW4gb25lIHB1YmxpYyBhZGRyZXNzLg0KPiAg IEJ1dCBpbiB0aGlzIGNhc2UgLGEgc2VydmVyIHdpbGwgbmV2ZXIgb2NjdXB5cyBhbGwgcG9ydHMg b2YgYSANCj4gcHVibGljIGFkZHJlc3MsIA0KPiBqdXN0ICJ4LXkiLiANCj4gDQo+IFtTZW50aGls XSBJIGRvbqGvdCByZWFsbHkgdW5kZXJzdGFuZCB3aGF0IGlzIHRoZSB1c2UgY2FzZSBmb3IgdGhp cz8gDQo+IENhbiB5b3UgcHJvdmlkZSBhIHJlYWwgbGlmZSB1c2UgY2FzZSB0aGF0IHdvdWxkIGJl bmVmaXQgYnkgdGhpcz8NCj4gV2hhdCBpZiB0aGUgc2VydmVyIGxpc3RlbnMgb24gYSBwb3J0ID4g MTAyND8gV2h5IHdvdWxkIHRoZSBzZXJ2ZXIgDQo+IG11bHRpcGxlIHBvcnRzPyBXaHkgY2FudCBh IHNpbXBsZSBwb3J0IGZvcndhcmRpbmcgd29yaz8NCj4gDQo+IFNlbnRoaWwNCj4gDQo+IFdlaSAN Cj4gDQo+ID4gDQo+ID4gDQo+ID4gDQo+ID4gICAgKDIpPDEwMjUtNjU1MzU+IG1pZ2h0IGJlIHVz ZWQgYXMgZHluYW1pYyBOQVBUIA0KPiA+ICAgICAgICBNZWFud2hpbGUsIG1hbnkgaG9zdHMgYXJl IGJlaGluZCBOQVQuIFRoZXkgYXR0ZW1wdCB0byBhY2Nlc3MgdG8gDQoNCj4gPiAgICAgaW50ZXJu ZXQuIA0KPiA+ICAgICAgICBBIG1lc3NhZ2UsIHNlbnQgYnkgYSBob3N0LCBib3RoIGl0cyBzb3Vy Y2UgYWRkcmVzcyBhbmQgcG9ydCANCndpbGwNCj4gPiAgICAgYmUgY29udmVydGVkIGJ5IE5BVCwg YW5kIHRoZSBuZXcgcG9ydCB3aWxsIGJlIGluIDEwMjUtNjU1MzUuDQo+ID4gDQo+ID4gDQo+ID4g SXQgd2lsbCBtYWtlIElQIGFkZHJlc3MgYXNzaWdubWVudCBtb3JlIGVmZmVjdGl2ZS4NCj4gPiAN Cj4gPiBDaGVlcnMsIA0KPiA+IFdlaSANCj4gPiANCj4gPiANCj4gPiANCj4gPiBiZWhhdmUtYm91 bmNlc0BpZXRmLm9yZyAgMjAxMy0wNy0xNyAxMjozNjozMDoNCj4gPiANCj4gPiA+IEhpLCANCj4g PiA+IA0KPiA+ID4gSSdtIG5vdCBzdXJlIHdoYXQgZXhhY3RseSB5b3UgbWFuIGJ5ICJtaWdodCBi ZSB1c2VkIGFzIE5BVCIuIA0KPiA+ID4gDQo+ID4gPiAwLTEwMjQgbWlnaHQgYmUgdXNlZCBmb3Ig TkFQVCBpbiBhIEZDRlMgYmFzaXMgd2hlcmUgcG9ydCANCj4gPiA+IHByZXNlcnZhdGlvbiAodGhp cyBpcyB3aGF0IHdlIGFyZSB0YWxraW5nIGFib3V0IGhlcmUsIHJpZ2h0PykgaXMgDQpuZWVkZWQu IA0KPiA+ID4gDQo+ID4gPiBBcyBhIGNvbmNyZXRlIGV4YW1wbGUsIG1hbnkgSVBzZWMgU2VydmVy cyBzdGlsbCBleHBlY3QgdG8gc2VlIHRoZSANCj4gPiA+IHNvdXJjZSBwb3J0IHdpdGhpbiAwLTEw MjQgYW5kIHByZWZlcmFibHkgYSBzcGVjaWZpYyBzb3VyY2UgcG9ydC4gSWYgDQo+ID4gPiB0aGF0 IHNvdXJjZSBwb3J0IGlzIHVzZWQgYnkgdGhlIE5BVCwgYW5kIG1vcmUgdGhhbiBvbmUgSVBzZWMg Y2xpZW50IA0KPiA+ID4gaXMgYmVoaW5kIGl0LCB0aGVyZSBhcmUgYSBzb21lIGNob2ljZXMgYXZh aWxhYmxlLiANCj4gPiA+IA0KPiA+ID4gLSBTb21lIGZ1bmt5IElQU2VjIEFMRyAoaW1wbGVtZW50 ZWQgaW4gbWFueSBwcm9kdWN0cykgDQo+ID4gPiAtIEdpdmUgYSBwb3J0IGFib3ZlIDEwMjQgYW5k IGhvcGUgZm9yIHRoZSBiZXN0IA0KPiA+ID4gLSBEZW55IHRoZSBjb25uZWN0aW9uIA0KPiA+ID4g LSBvdGhlcnMuLiANCj4gPiA+IA0KPiA+ID4gT3RoZXIgcG9ydHMgZm9yIHRoZSBzYW1lIHB1Ymxp YyBJUCBjYW4gYmUgdXNlZCBieSBhbnkgb3RoZXIgaW50ZXJuYWwNCj4gPiA+IElQIGFkZHJlc3Mu IFRoaXMgaXMgdmVyeSBjb21tb24gaW4gaW1wbGVtZW50YXRpb25zLiANCj4gPiA+IA0KPiA+ID4g dGhhbmtzLCANCj4gPiA+IA0KPiA+ID4gRnJvbTogYmVoYXZlLWJvdW5jZXNAaWV0Zi5vcmcgW2Jl aGF2ZS1ib3VuY2VzQGlldGYub3JnXSBvbiBiZWhhbGYgb2YNCj4gPiA+IG1lbmcud2VpMkB6dGUu Y29tLmNuIFttZW5nLndlaTJAenRlLmNvbS5jbl0NCj4gPiA+IFNlbnQ6IFR1ZXNkYXksIEp1bHkg MTYsIDIwMTMgODoyMiBQTQ0KPiA+ID4gVG86IFJlaW5hbGRvIFBlbm5vIChyZXBlbm5vKQ0KPiA+ ID4gQ2M6IGJlaGF2ZS1ib3VuY2VzQGlldGYub3JnOyBiZWhhdmVAaWV0Zi5vcmc7IERhbiBXaW5n IChkd2luZykNCj4gPiA+IFN1YmplY3Q6IFJlOiBbQkVIQVZFXSBOQVBHVCByZXF1ZXN0IGZvciBj b21tZW50cywgVEhBTktTIQ0KPiA+IA0KPiA+ID4gDQo+ID4gPiBIaSBSZWluYWxkbywgDQo+ID4g PiAgIFNvIEkgc3VwcG9zZSA8MS0xMDI0PiBtaWdodCBiZSB1c2VkIGFzIE5BVCwgPDEwMjUtNjU1 MzU+IG1pZ2h0DQo+IGJlIHVzZWQgYXMgDQo+ID4gPiBkeW5hbWljIE5BUFQuIA0KPiA+ID4gICBU aGF0IGlzIHdoYXQgdGhpcyB2aWV3IHNheXMgaW4gdGhlIGRyYWZ0LiANCj4gPiA+IA0KPiA+ID4g Q2hlZXJzLCANCj4gPiA+IFdlaSANCj4gPiA+IA0KPiA+ID4gDQo+ID4gPiBiZWhhdmUtYm91bmNl c0BpZXRmLm9yZyAyMDEzLTA3LTE3IDA5OjUyOjM0Og0KPiA+ID4gDQo+ID4gPiA+IEknbSBub3Qg c3VyZSB0aGlzIGlzIGEgZ29vZCBpZGVhLiBUaGVyZSBhcmUgc3RpbGwgc29tZSBwcm90b2NvbHMg DQo+ID4gPiA+IGFyb3VuZCB0aGF0IHVzZSBwb3J0cyA8IDEwMjQgYW5kIG1haW50YWluaW5nIHRo ZSBzb3VyY2UgcG9ydCBhZnRlciANCg0KPiA+ID4gPiB0cmFuc2xhdGlvbiBpbiB0aGlzIHJhbmdl IGlzIGltcG9ydGFudC4gDQo+ID4gPiA+IA0KPiA+ID4gPiBGcm9tOiBiZWhhdmUtYm91bmNlc0Bp ZXRmLm9yZyBbYmVoYXZlLWJvdW5jZXNAaWV0Zi5vcmddIG9uIGJlaGFsZiANCm9mDQo+ID4gPiA+ IERhbiBXaW5nIChkd2luZykNCj4gPiA+ID4gU2VudDogVHVlc2RheSwgSnVseSAxNiwgMjAxMyAz OjMwIFBNDQo+ID4gPiA+IFRvOiBtZW5nLndlaTJAenRlLmNvbS5jbg0KPiA+ID4gPiBDYzogYmVo YXZlQGlldGYub3JnDQo+ID4gPiA+IFN1YmplY3Q6IFJlOiBbQkVIQVZFXSBOQVBHVCByZXF1ZXN0 IGZvciBjb21tZW50cywgVEhBTktTIQ0KPiA+ID4gDQo+ID4gPiA+IA0KPiA+ID4gPiBPbiBKdWwg MTUsIDIwMTMsIGF0IDI6NDMgQU0sIG1lbmcud2VpMkB6dGUuY29tLmNuIHdyb3RlOiANCj4gPiA+ ID4gDQo+ID4gPiA+ICAgICBJIGhhdmUgc3VibWl0dGVkIGEgbmV3IGRyYWZ0LiBUaGUgb2JqZWN0 aXZlIGlzIHRvIHNvbHZlIGEgDQo+ID4gcHJvYmxlbSB0aGF0IA0KPiA+ID4gPiAgICAgcHJldmVu dHMgYW4gZXh0ZXJuYWwgY2xpZW50IGZyb20gYWNjZXNzaW5nIGFuIGludGVybmFsIHNlcnZlci4g DQoNCj4gPiA+ID4gDQo+ID4gPiA+ICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1tZW5nLWJlaGF2ZS1uYXBndC8gDQo+ID4gPiA+IA0KPiA+ID4gPiAgICAgSSBleHBl Y3QgeW91ciBjb21tZW50cy4gVGhhbmtzIGEgbG90ISANCj4gPiA+ID4gDQo+ID4gPiA+IERyYWZ0 LW1lbmctYmVoYXZlLW5hcGd0IGFwcGVhcnMgdG8gZGVzY3JpYmUgc29tZXRoaW5nIHRoYXQgaXMg dmVyeSANCg0KPiA+ID4gPiBzaW1pbGFyIHRvIHRoZSBsb25nLXN0YW5kaW5nICJETVogaG9zdCIg Y29uZmlndXJhdGlvbiBhdmFpbGFibGUgb24gDQoNCj4gPiA+ID4gYWxtb3N0IGFsbCByZXNpZGVu dGlhbC1jbGFzcyBOQVQgZGV2aWNlcy4gIEkgZG9uJ3QgdGhpbmsgd2UgY291bGQgDQo+ID4gPiA+ IHN0YW5kYXJkaXplIHRoYXQgYmVoYXZpb3IsIGJ1dCBwZXJoYXBzIHRoYXQgaXMgcG9zc2libGUu IA0KPiA+ID4gPiANCj4gPiA+ID4gRHJhZnQtbWVuZy1iZWhhdmUtbmFwZ3QgYWxzbyBkZXNjcmli ZXMgYW4gdXBkYXRlIHRvIHRoZSBwb3J0IA0KPiA+ID4gPiBhc3NpZ25tZW50IGJlaGF2aW9yIGRl c2NyaWJlZCBpbiBodHRwOi8vdG9vbHMuaWV0Zi4NCj4gPiA+ID4gb3JnL2h0bWwvcmZjNTM4MiNz ZWN0aW9uLTcuMSAoVENQKSBhbmQgaHR0cDovL3Rvb2xzLmlldGYuDQo+ID4gPiA+IG9yZy9odG1s L3JmYzQ3ODcjc2VjdGlvbi00LjIuMSAoVURQKS4gIElmIEkgdW5kZXJzdGFuZCBTZWN0aW9uIDQg DQpvZiANCj4gPiA+ID4gZHJhZnQtbWVuZy1iZWhhdmUtbmFwZ3QgcHJvcGVybHksIGl0IGlzIHNh eWluZyB0aGF0IE5BVHMgc2hvdWxkIA0Kbm90IA0KPiA+ID4gPiBhc3NpZ24gcG9ydHMgYmVsb3cg MTAyNCB0byBkeW5hbWljIGNvbm5lY3Rpb25zLiAgVGhpcyBtaWdodCBiZSANCj4gPiA+ID4gc29t ZXRoaW5nIHdvcnRoIGNvbnNpZGVyaW5nIGZvciANCmRyYWZ0LWlldGYtYmVoYXZlLXJlcXVpcmVt ZW50cy11cGRhdGU/IA0KPiA+ID4gPiANCj4gPiA+ID4gLWQgDQo+ID4gPiA+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiA+IEJlaGF2ZSBtYWls aW5nIGxpc3QNCj4gPiA+ID4gQmVoYXZlQGlldGYub3JnDQo+ID4gPiA+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vYmVoYXZlDQo+ID4gPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gQmVoYXZlIG1haWxpbmcgbGlzdA0K PiA+ID4gQmVoYXZlQGlldGYub3JnDQo+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2JlaGF2ZQ0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiBCZWhhdmUgbWFpbGluZyBsaXN0DQo+IEJlaGF2ZUBpZXRmLm9yZw0KPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2JlaGF2ZQ0KDQo= --=_alternative 004C2B2D48257BB7_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIGFsbCw8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyBJdCdzIGEgcGl0dHkgSSBnb3Qg bm8gY29tbWVudA0KYWZ0ZXIgbXkgcHJlc2VudGF0aW9uIGR1ZSB0byBsYWNrIG9mIDwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+bWVldGluZyB0aW1lLjwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7IEl0IGlzIGFuIGltcG9y dGFudCBpc3N1ZSB3aGljaA0Kc21hbGwgZmlybXMvZmFtaWx5IERJWWVycy8uLi4gbXVzdCBmYWNl IHRvPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj53aGVuIE5BVCBo YXMgYmVlbiBkZXBsb3llZC4gVGhleSBhdHRlbXB0DQp0byBhY2hpZXZlIGFjY2Vzc2luZyBpbnRl cm5hbCBzZXJ2ZXIgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5m cm9tIGV4dGVybmFsIG5ldHdvcmsgZW52aXJvbm1lbnQgd2l0aG91dA0KYW4gZXh0cmEgcHVibGlj IElQIGFkZHJlc3MuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj4mbmJzcDsgQXJlIHlvdSBpbnRlcmVzdGVkIGluIHRoaXMgdG9waWM/PC9mb250Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgUGxlYXNlIHNlZSB0 aGUgc2NlbmFyaW8gaW4gc2xpZGVzLg0KJm5ic3A7IGh0dHA6Ly90b29scy5pZXRmLm9yZy9hZ2Vu ZGEvODcvc2xpZGVzL3NsaWRlcy04Ny1iZWhhdmUtNC5wZGY8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoYW5rcyBmb3IgY29tbWVudHMuPC9mb250Pg0K PGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5DaGVlcnMsPC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5XZWk8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD4NCjxicj4NCjxicj4NCjxicj48 Zm9udCBzaXplPTI+PHR0PmJlaGF2ZS1ib3VuY2VzQGlldGYub3JnICZuYnNwOzIwMTMvMDcvMTgg MjI6MzE6MDA6PGJyPg0KPGJyPg0KJmd0OyBGcm9tOiAmcXVvdDttZW5nLndlaTJAenRlLmNvbS5j biZxdW90OyAmbHQ7bWVuZy53ZWkyQHp0ZS5jb20uY24mZ3Q7PGJyPg0KJmd0OyBEYXRlOiBXZWRu ZXNkYXksIEp1bHkgMTcsIDIwMTMgOToxOSBQTTxicj4NCiZndDsgVG86IFNlbnRoaWwgU2l2YWt1 bWFyICZsdDtzc2VudGhpbEBjaXNjby5jb20mZ3Q7PGJyPg0KJmd0OyBDYzogJnF1b3Q7YmVoYXZl QGlldGYub3JnJnF1b3Q7ICZsdDtiZWhhdmVAaWV0Zi5vcmcmZ3Q7LCAmcXVvdDtiZWhhdmUtYm91 bmNlc0BpZXRmLm9yZyZxdW90Ow0KJmx0Ozxicj4NCiZndDsgYmVoYXZlLWJvdW5jZXNAaWV0Zi5v cmcmZ3Q7LCAmcXVvdDtEYW4gV2luZyAoZHdpbmcpJnF1b3Q7ICZsdDtkd2luZ0BjaXNjby5jb20m Z3Q7LA0KPGJyPg0KJmd0OyAmcXVvdDtSZWluYWxkbyBQZW5ubyAocmVwZW5ubykmcXVvdDsgJmx0 O3JlcGVubm9AY2lzY28uY29tJmd0Ozxicj4NCiZndDsgU3ViamVjdDogUmU6IFJlOiBbQkVIQVZF XSBOQVBHVCByZXF1ZXN0IGZvciBjb21tZW50cywgVEhBTktTITwvdHQ+PC9mb250Pg0KPGJyPjxm b250IHNpemU9Mj48dHQ+Jmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgSGksIDxicj4NCiZndDsg Jm5ic3A7IFBsZWFzZSBzZWUgaW5saW5lLiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhhbmtzLCA8 YnI+DQomZ3Q7IFdlaSA8YnI+DQomZ3Q7IDxicj4NCiZndDsgJnF1b3Q7U2VudGhpbCBTaXZha3Vt YXIgKHNzZW50aGlsKSZxdW90OyAmbHQ7c3NlbnRoaWxAY2lzY28uY29tJmd0Ow0KJm5ic3A7MjAx My0wNy0xNyAyMTozMDoyNDo8YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0OyBGcm9tOiAmcXVvdDtt ZW5nLndlaTJAenRlLmNvbS5jbiZxdW90OyAmbHQ7bWVuZy53ZWkyQHp0ZS5jb20uY24mZ3Q7PGJy Pg0KJmd0OyAmZ3Q7IERhdGU6IFdlZG5lc2RheSwgSnVseSAxNywgMjAxMyA0OjA4IEFNPGJyPg0K Jmd0OyAmZ3Q7IFRvOiAmcXVvdDtSZWluYWxkbyBQZW5ubyAocmVwZW5ubykmcXVvdDsgJmx0O3Jl cGVubm9AY2lzY28uY29tJmd0Ozxicj4NCiZndDsgJmd0OyBDYzogJnF1b3Q7YmVoYXZlLWJvdW5j ZXNAaWV0Zi5vcmcmcXVvdDsgJmx0O2JlaGF2ZS1ib3VuY2VzQGlldGYub3JnJmd0OywNCiZxdW90 O2JlaGF2ZUBpZXRmLm9yZyZxdW90OyAmbHQ7PGJyPg0KJmd0OyAmZ3Q7IGJlaGF2ZUBpZXRmLm9y ZyZndDssICZxdW90O0RhbiBXaW5nIChkd2luZykmcXVvdDsgJmx0O2R3aW5nQGNpc2NvLmNvbSZn dDs8YnI+DQomZ3Q7ICZndDsgU3ViamVjdDogUmU6IFtCRUhBVkVdIE5BUEdUIHJlcXVlc3QgZm9y IGNvbW1lbnRzLCBUSEFOS1MhIDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0K Jmd0OyAmZ3Q7IEhpLCA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7IEkgZ290IHdoYXQgdGhlIGV4YW1w bGUgbWVhbnMuIDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7IDEtMTAyNCBp cyBqdXN0IGFuIGV4YW1wbGUsIHRoZSByYW5nZSBjb3VsZCBiZSBhbnkgdmFsaWQNCnZhbHVlLjxi cj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZxdW90OyZsdDsxLTEwMjQmZ3Q7 IG1pZ2h0IGJlIHVzZWQgYXMgTkFULCAmbHQ7MTAyNS02NTUzNSZndDsNCm1pZ2h0IGJlIHVzZWQg YXMgPGJyPg0KJmd0OyAmZ3Q7IGR5bmFtaWMgTkFQVCZxdW90OywgZXhhbXBsZSBpcyBhcyBiZWxv dy4gPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7Ky0tLS0tLS0t LS0rICZuYnNwOyAmbmJzcDsgKy0tLS0tKyAmbmJzcDsgJm5ic3A7Ky0tLS0tLS0tKw0KPGJyPg0K Jmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsrIEludGVybmV0ICsgLS0tLSsgTkFUICstLS0tKyBTZXJ2 ZXIgKyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOystLS0tLS0tLS0tKyAmbmJzcDsgJm5i c3A7ICstLS0tLSsgJm5ic3A7ICZuYnNwOystLS0tLS0tLSsNCjxicj4NCiZndDsgJmd0OyA8YnI+ DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOygxKSAmcXVvdDsmbHQ7MS0xMDI0Jmd0OyBtaWdodCBi ZSB1c2VkIGFzIE5BVCZxdW90Ow0KbWVhbnMsIDxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDtBIHNlcnZlciBiZWhpbmQgYSBOQVQuIDxicj4NCiZndDsgJmd0OyAmbmJz cDsgJm5ic3A7QSBtZXNzYWdlLCBzZW50IGJ5IHNlcnZlciwgaXRzIHNvdXJjZSBwb3J0IGlzIGlu DQoxLTEwMjQgKG9yIDxicj4NCiZndDsgJmd0OyA0NTAwLTQ1MDEgb3IgLi4uKS48YnI+DQomZ3Q7 ICZndDsgJm5ic3A7ICZuYnNwO1RoZSBzb3VyY2UgYWRkcmVzcyB3aWxsIGJlIGNvbnZlcnRlZCBi eSBOQVQsIHRoZQ0Kc291cmNlIHBvcnQgcmVtYWluczxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5i c3A7dGhlIHNhbWUuIDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgW1NlbnRoaWxdIFNv cnJ5LCBJIGRpZG6hr3QgcmVhZCB0aGUgZHJhZnQsIGJ1dCB0aGUgYWJvdmUgbG9naWMNCndvbnQg PGJyPg0KJmd0OyAmZ3Q7IHdvcmsgaWYgdGhlcmUgYXJlIG11bHRpcGxlIHNlcnZlcnMgdXNpbmcg dGhlIHNhbWUgc291cmNlIHBvcnQuDQo8YnI+DQomZ3Q7ICZndDsgQWxzbywgaW4gc29tZSBhcHBs aWNhdGlvbnMgKEkgdGhpbmsgcmNtZCwgcnNoZWxsIGV0YyksIHRoZSBzb3VyY2UNCjxicj4NCiZn dDsgJmd0OyBwb3J0IGRvZXNuoa90IGhhdmUgdG8gYmUgcHJlc2VydmVkIGJ1dCBtdXN0IGJlIGJl bG93IDEwMjQuIDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgU2VudGhpbCA8YnI+DQom Z3Q7IDxicj4NCiZndDsgW1dlaV0gSSdtIHByZXNlbnRpbmcgdGhlIHByb3Bvc2FsIHNvIGFzIHRv IHNvbHZlIHRoaXMgcHJvYmxlbSA6IGFzc2lnbg0KcG9ydCA8YnI+DQomZ3Q7IHgteShpLmUuIDEt MTAyNCkgdG8gYSBzZXJ2ZXIoZm9yIHBvcnQgcHJlc2VydmluZyBmdW5jdGlvbiwgbGlrZSBOQVQp LA0KYXNzaWduIDxicj4NCiZndDsgdGhlIHJlc3Qgb2YgcG9ydHMgdG8gb3RoZXJzKGZvciBjb21t b24gTkFQVCkuIDxicj4NCiZndDsgJm5ic3A7IE9mIGNvdXJzZSwgaWYgdGhlcmUgYXJlIG1hbnkg c2VydmVycyBiZWJpbmQgTkFUIGFuZCB3aGV0aGVyDQpvciBub3QgdXNpbmcgPGJyPg0KJmd0OyB0 aGUgc2FtZSBzb3VyY2UgcG9ydCwgTkFUIGhhcyB0byBuZWVkIG1vcmUgdGhhbiBvbmUgcHVibGlj IGFkZHJlc3MuPGJyPg0KJmd0OyAmbmJzcDsgQnV0IGluIHRoaXMgY2FzZSAsYSBzZXJ2ZXIgd2ls bCBuZXZlciBvY2N1cHlzIGFsbCBwb3J0cyBvZg0KYSA8YnI+DQomZ3Q7IHB1YmxpYyBhZGRyZXNz LCA8YnI+DQomZ3Q7IGp1c3QgJnF1b3Q7eC15JnF1b3Q7LiA8L3R0PjwvZm9udD4NCjxicj48Zm9u dCBzaXplPTI+PHR0PiZndDsgPGJyPg0KJmd0OyBbU2VudGhpbF0gSSBkb26hr3QgcmVhbGx5IHVu ZGVyc3RhbmQgd2hhdCBpcyB0aGUgdXNlIGNhc2UgZm9yIHRoaXM/DQo8YnI+DQomZ3Q7IENhbiB5 b3UgcHJvdmlkZSBhIHJlYWwgbGlmZSB1c2UgY2FzZSB0aGF0IHdvdWxkIGJlbmVmaXQgYnkgdGhp cz88L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0PiZndDsgV2hhdCBpZiB0aGUgc2Vy dmVyIGxpc3RlbnMgb24gYSBwb3J0ICZndDsgMTAyND8NCldoeSB3b3VsZCB0aGUgc2VydmVyIDxi cj4NCiZndDsgbXVsdGlwbGUgcG9ydHM/IFdoeSBjYW50IGEgc2ltcGxlIHBvcnQgZm9yd2FyZGlu ZyB3b3JrPzwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+Jmd0OyA8YnI+DQomZ3Q7 IFNlbnRoaWw8L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0PiZndDsgPGJyPg0KJmd0 OyBXZWkgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZn dDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOygyKSZsdDsxMDI1LTY1NTM1Jmd0 OyBtaWdodCBiZSB1c2VkIGFzIGR5bmFtaWMgTkFQVA0KPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO01lYW53aGlsZSwgbWFueSBob3N0cyBhcmUgYmVoaW5kIE5BVC4N ClRoZXkgYXR0ZW1wdCB0byBhY2Nlc3MgdG8gPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsg aW50ZXJuZXQuIDxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtBIG1l c3NhZ2UsIHNlbnQgYnkgYSBob3N0LCBib3RoIGl0cw0Kc291cmNlIGFkZHJlc3MgYW5kIHBvcnQg d2lsbDxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7IGJlIGNvbnZlcnRlZCBieSBOQVQsIGFu ZCB0aGUgbmV3IHBvcnQgd2lsbCBiZSBpbg0KMTAyNS02NTUzNS48YnI+DQomZ3Q7ICZndDsgPGJy Pg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7IEl0IHdpbGwgbWFrZSBJ UCBhZGRyZXNzIGFzc2lnbm1lbnQgbW9yZSBlZmZlY3RpdmUuPGJyPg0KJmd0OyAmZ3Q7IDxicj4N CiZndDsgJmd0OyBDaGVlcnMsIDxicj4NCiZndDsgJmd0OyBXZWkgPGJyPg0KJmd0OyAmZ3Q7IDxi cj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IGJlaGF2ZS1ib3Vu Y2VzQGlldGYub3JnICZuYnNwOzIwMTMtMDctMTcgMTI6MzY6MzA6PGJyPg0KJmd0OyAmZ3Q7IDxi cj4NCiZndDsgJmd0OyAmZ3Q7IEhpLCA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZn dDsgJmd0OyBJJ20gbm90IHN1cmUgd2hhdCBleGFjdGx5IHlvdSBtYW4gYnkgJnF1b3Q7bWlnaHQg YmUgdXNlZA0KYXMgTkFUJnF1b3Q7LiAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0K Jmd0OyAmZ3Q7ICZndDsgMC0xMDI0IG1pZ2h0IGJlIHVzZWQgZm9yIE5BUFQgaW4gYSBGQ0ZTIGJh c2lzIHdoZXJlIHBvcnQNCjxicj4NCiZndDsgJmd0OyAmZ3Q7IHByZXNlcnZhdGlvbiAodGhpcyBp cyB3aGF0IHdlIGFyZSB0YWxraW5nIGFib3V0IGhlcmUsIHJpZ2h0PykNCmlzIG5lZWRlZC4gPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgQXMgYSBjb25jcmV0ZSBleGFt cGxlLCBtYW55IElQc2VjIFNlcnZlcnMgc3RpbGwgZXhwZWN0IHRvDQpzZWUgdGhlIDxicj4NCiZn dDsgJmd0OyAmZ3Q7IHNvdXJjZSBwb3J0IHdpdGhpbiAwLTEwMjQgYW5kIHByZWZlcmFibHkgYSBz cGVjaWZpYyBzb3VyY2UNCnBvcnQuIElmIDxicj4NCiZndDsgJmd0OyAmZ3Q7IHRoYXQgc291cmNl IHBvcnQgaXMgdXNlZCBieSB0aGUgTkFULCBhbmQgbW9yZSB0aGFuIG9uZSBJUHNlYw0KY2xpZW50 IDxicj4NCiZndDsgJmd0OyAmZ3Q7IGlzIGJlaGluZCBpdCwgdGhlcmUgYXJlIGEgc29tZSBjaG9p Y2VzIGF2YWlsYWJsZS4gPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsg LSBTb21lIGZ1bmt5IElQU2VjIEFMRyAoaW1wbGVtZW50ZWQgaW4gbWFueSBwcm9kdWN0cykgPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgLSBHaXZlIGEgcG9ydCBhYm92ZSAxMDI0IGFuZCBob3BlIGZvciB0 aGUgYmVzdCA8YnI+DQomZ3Q7ICZndDsgJmd0OyAtIERlbnkgdGhlIGNvbm5lY3Rpb24gPGJyPg0K Jmd0OyAmZ3Q7ICZndDsgLSBvdGhlcnMuLiA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7 ICZndDsgJmd0OyBPdGhlciBwb3J0cyBmb3IgdGhlIHNhbWUgcHVibGljIElQIGNhbiBiZSB1c2Vk IGJ5IGFueSBvdGhlcg0KaW50ZXJuYWw8YnI+DQomZ3Q7ICZndDsgJmd0OyBJUCBhZGRyZXNzLiBU aGlzIGlzIHZlcnkgY29tbW9uIGluIGltcGxlbWVudGF0aW9ucy4gPGJyPg0KJmd0OyAmZ3Q7ICZn dDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgdGhhbmtzLCA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+ DQomZ3Q7ICZndDsgJmd0OyBGcm9tOiBiZWhhdmUtYm91bmNlc0BpZXRmLm9yZyBbYmVoYXZlLWJv dW5jZXNAaWV0Zi5vcmddDQpvbiBiZWhhbGYgb2Y8YnI+DQomZ3Q7ICZndDsgJmd0OyBtZW5nLndl aTJAenRlLmNvbS5jbiBbbWVuZy53ZWkyQHp0ZS5jb20uY25dPGJyPg0KJmd0OyAmZ3Q7ICZndDsg U2VudDogVHVlc2RheSwgSnVseSAxNiwgMjAxMyA4OjIyIFBNPGJyPg0KJmd0OyAmZ3Q7ICZndDsg VG86IFJlaW5hbGRvIFBlbm5vIChyZXBlbm5vKTxicj4NCiZndDsgJmd0OyAmZ3Q7IENjOiBiZWhh dmUtYm91bmNlc0BpZXRmLm9yZzsgYmVoYXZlQGlldGYub3JnOyBEYW4gV2luZyAoZHdpbmcpPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgU3ViamVjdDogUmU6IFtCRUhBVkVdIE5BUEdUIHJlcXVlc3QgZm9y IGNvbW1lbnRzLCBUSEFOS1MhPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxi cj4NCiZndDsgJmd0OyAmZ3Q7IEhpIFJlaW5hbGRvLCA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmbmJz cDsgU28gSSBzdXBwb3NlICZsdDsxLTEwMjQmZ3Q7IG1pZ2h0IGJlIHVzZWQgYXMgTkFULA0KJmx0 OzEwMjUtNjU1MzUmZ3Q7IG1pZ2h0PGJyPg0KJmd0OyBiZSB1c2VkIGFzIDxicj4NCiZndDsgJmd0 OyAmZ3Q7IGR5bmFtaWMgTkFQVC4gPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJm5ic3A7IFRoYXQgaXMg d2hhdCB0aGlzIHZpZXcgc2F5cyBpbiB0aGUgZHJhZnQuIDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxi cj4NCiZndDsgJmd0OyAmZ3Q7IENoZWVycywgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgV2VpIDxicj4N CiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7 IGJlaGF2ZS1ib3VuY2VzQGlldGYub3JnIDIwMTMtMDctMTcgMDk6NTI6MzQ6PGJyPg0KJmd0OyAm Z3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBJJ20gbm90IHN1cmUgdGhpcyBpcyBh IGdvb2QgaWRlYS4gVGhlcmUgYXJlIHN0aWxsIHNvbWUNCnByb3RvY29scyA8YnI+DQomZ3Q7ICZn dDsgJmd0OyAmZ3Q7IGFyb3VuZCB0aGF0IHVzZSBwb3J0cyAmbHQ7IDEwMjQgYW5kIG1haW50YWlu aW5nIHRoZQ0Kc291cmNlIHBvcnQgYWZ0ZXIgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyB0cmFu c2xhdGlvbiBpbiB0aGlzIHJhbmdlIGlzIGltcG9ydGFudC4gPGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IEZyb206IGJlaGF2ZS1ib3VuY2VzQGlldGYu b3JnIFtiZWhhdmUtYm91bmNlc0BpZXRmLm9yZ10NCm9uIGJlaGFsZiBvZjxicj4NCiZndDsgJmd0 OyAmZ3Q7ICZndDsgRGFuIFdpbmcgKGR3aW5nKTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgU2Vu dDogVHVlc2RheSwgSnVseSAxNiwgMjAxMyAzOjMwIFBNPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0 OyBUbzogbWVuZy53ZWkyQHp0ZS5jb20uY248YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IENjOiBi ZWhhdmVAaWV0Zi5vcmc8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IFN1YmplY3Q6IFJlOiBbQkVI QVZFXSBOQVBHVCByZXF1ZXN0IGZvciBjb21tZW50cywgVEhBTktTITxicj4NCiZndDsgJmd0OyAm Z3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBP biBKdWwgMTUsIDIwMTMsIGF0IDI6NDMgQU0sIG1lbmcud2VpMkB6dGUuY29tLmNuIHdyb3RlOg0K PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNw OyAmbmJzcDsgSSBoYXZlIHN1Ym1pdHRlZCBhIG5ldyBkcmFmdC4gVGhlIG9iamVjdGl2ZQ0KaXMg dG8gc29sdmUgYSA8YnI+DQomZ3Q7ICZndDsgcHJvYmxlbSB0aGF0IDxicj4NCiZndDsgJmd0OyAm Z3Q7ICZndDsgJm5ic3A7ICZuYnNwOyBwcmV2ZW50cyBhbiBleHRlcm5hbCBjbGllbnQgZnJvbSBh Y2Nlc3NpbmcNCmFuIGludGVybmFsIHNlcnZlci4gPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8 YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtbWVuZy1iZWhhdmUtbmFwZ3QvDQo8YnI+DQomZ3Q7ICZndDsg Jmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyBJIGV4cGVj dCB5b3VyIGNvbW1lbnRzLiBUaGFua3MgYSBsb3QhDQo8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7 IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgRHJhZnQtbWVuZy1iZWhhdmUtbmFwZ3QgYXBwZWFy cyB0byBkZXNjcmliZSBzb21ldGhpbmcNCnRoYXQgaXMgdmVyeSA8YnI+DQomZ3Q7ICZndDsgJmd0 OyAmZ3Q7IHNpbWlsYXIgdG8gdGhlIGxvbmctc3RhbmRpbmcgJnF1b3Q7RE1aIGhvc3QmcXVvdDsg Y29uZmlndXJhdGlvbg0KYXZhaWxhYmxlIG9uIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgYWxt b3N0IGFsbCByZXNpZGVudGlhbC1jbGFzcyBOQVQgZGV2aWNlcy4gJm5ic3A7SSBkb24ndA0KdGhp bmsgd2UgY291bGQgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBzdGFuZGFyZGl6ZSB0aGF0IGJl aGF2aW9yLCBidXQgcGVyaGFwcyB0aGF0IGlzIHBvc3NpYmxlLg0KPGJyPg0KJmd0OyAmZ3Q7ICZn dDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IERyYWZ0LW1lbmctYmVoYXZlLW5hcGd0 IGFsc28gZGVzY3JpYmVzIGFuIHVwZGF0ZSB0bw0KdGhlIHBvcnQgPGJyPg0KJmd0OyAmZ3Q7ICZn dDsgJmd0OyBhc3NpZ25tZW50IGJlaGF2aW9yIGRlc2NyaWJlZCBpbiBodHRwOi8vdG9vbHMuaWV0 Zi48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IG9yZy9odG1sL3JmYzUzODIjc2VjdGlvbi03LjEg KFRDUCkgYW5kIGh0dHA6Ly90b29scy5pZXRmLjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgb3Jn L2h0bWwvcmZjNDc4NyNzZWN0aW9uLTQuMi4xIChVRFApLiAmbmJzcDtJZiBJIHVuZGVyc3RhbmQN ClNlY3Rpb24gNCBvZiA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IGRyYWZ0LW1lbmctYmVoYXZl LW5hcGd0IHByb3Blcmx5LCBpdCBpcyBzYXlpbmcgdGhhdA0KTkFUcyBzaG91bGQgbm90IDxicj4N CiZndDsgJmd0OyAmZ3Q7ICZndDsgYXNzaWduIHBvcnRzIGJlbG93IDEwMjQgdG8gZHluYW1pYyBj b25uZWN0aW9ucy4gJm5ic3A7VGhpcw0KbWlnaHQgYmUgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0 OyBzb21ldGhpbmcgd29ydGggY29uc2lkZXJpbmcgZm9yIGRyYWZ0LWlldGYtYmVoYXZlLXJlcXVp cmVtZW50cy11cGRhdGU/DQo8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0 OyAmZ3Q7ICZndDsgLWQgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg QmVoYXZlIG1haWxpbmcgbGlzdDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgQmVoYXZlQGlldGYu b3JnPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2JlaGF2ZTxicj4NCiZndDsgJmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7ICZndDsgQmVoYXZlIG1h aWxpbmcgbGlzdDxicj4NCiZndDsgJmd0OyAmZ3Q7IEJlaGF2ZUBpZXRmLm9yZzxicj4NCiZndDsg Jmd0OyAmZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYmVoYXZlPGJy Pg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4NCiZndDsgQmVoYXZlIG1haWxpbmcgbGlzdDxicj4NCiZndDsgQmVoYXZlQGlldGYub3JnPGJy Pg0KJmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2JlaGF2ZTxicj4N CjwvdHQ+PC9mb250Pg0K --=_alternative 004C2B2D48257BB7_=-- From simon.perreault@viagenie.ca Mon Jul 29 06:58:54 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB9511E80D9 for ; Mon, 29 Jul 2013 06:58:42 -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] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jDPr3V4Z2V0e for ; Mon, 29 Jul 2013 06:58:28 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0413321F9AD3 for ; Mon, 29 Jul 2013 06:57:40 -0700 (PDT) Received: from porto.nomis80.org (h230.viagenie.ca [206.123.31.230]) by jazz.viagenie.ca (Postfix) with ESMTPSA id A00B0403DC for ; Mon, 29 Jul 2013 09:57:38 -0400 (EDT) Message-ID: <51F674D0.3040603@viagenie.ca> Date: Mon, 29 Jul 2013 15:57:36 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: behave@ietf.org References: <20130729134623.GD51737@mx1.yitter.info> In-Reply-To: <20130729134623.GD51737@mx1.yitter.info> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [BEHAVE] Fwd: I-D Action: draft-sun-behave-v4tov6-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 13:58:55 -0000 Le 2013-07-29 15:46, Andrew Sullivan a crit : > Regardless of the advantages of any one technique, I don't understand > why this is a thing that one ought to do at all. > > What problem does it solve to make v4-only nodes initiate connections > to the v6 network? Why is that a problem we ought to solve? > > I suggest that it is a problem we do _not_ want to solve. It keeps > v4-only nodes alive longer. That's not a goal I share. By that logic, dual stack servers should move to v6-only. 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 maxpassion@gmail.com Mon Jul 29 07:01:25 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18BF311E810C for ; Mon, 29 Jul 2013 07:01:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 HYHab1ZCTo+P for ; Mon, 29 Jul 2013 07:01:23 -0700 (PDT) Received: from mail-ve0-x230.google.com (mail-ve0-x230.google.com [IPv6:2607:f8b0:400c:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 540CA21F9F2D for ; Mon, 29 Jul 2013 07:00:56 -0700 (PDT) Received: by mail-ve0-f176.google.com with SMTP id b10so863872vea.35 for ; Mon, 29 Jul 2013 07:00:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+KuO3rPw8PBzdzi7JtlDeAaeK+NdcjqdrZ2r4/Ap6DQ=; b=uYrwJZ2Ztwaj6Fus+toI5PxPhLUkNmUkbKPxKgkUWh5zhRHR4SdV554lXF4CZDtYmo RY6GYnMRXuArNZCcsycBhhvvH9CdobVzEHSYs5BJcWylUbGlxbL2gbIo+LpbmkbT3Y49 E++T53aMIQq2s3Pi8Cj/LAUzij1JryHCBYc8FfBxmdnLtatiPdRvc643/rRLkrmvC18Q S/ncf68y9g8hx0uO434Us8SM51z2H2cWkjtmWuTKt7zRngWnMf6GOGBNegDbJdWLxcD8 Dh5asgQd8zHgkQ8w8+wlhy9bQvyKoNb+kJbHnwkeTwNpCr4+GT6Cbhii41GWpycYe+aT eFXw== MIME-Version: 1.0 X-Received: by 10.220.90.71 with SMTP id h7mr8581206vcm.16.1375106454578; Mon, 29 Jul 2013 07:00:54 -0700 (PDT) Received: by 10.220.142.130 with HTTP; Mon, 29 Jul 2013 07:00:54 -0700 (PDT) In-Reply-To: References: Date: Mon, 29 Jul 2013 22:00:54 +0800 Message-ID: From: Liu Dapeng To: Qiong Content-Type: multipart/alternative; boundary=047d7b3a8c12c0e93904e2a6ebe0 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] Fwd: I-D Action: draft-sun-behave-v4tov6-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 14:01:25 -0000 --047d7b3a8c12c0e93904e2a6ebe0 Content-Type: text/plain; charset=ISO-8859-1 Hi Qiong, Thanks for the clarification. Configuring static mapping in DNS requires the operator has control of both the authoritative DNS server and the translator. That could be possible in data center scenario but for large scale deployment, I am afraid that the dynamic mapping still would be needed? Regards, Dapeng Liu 2013/7/29 Qiong > Hi Dapeng, > > Thanks for pointing out. I think the major difference is that we use > static mapping while draft-liu-behave-nat46 uses dynamic mapping. That's > why we do not need to embed DNS46 in the translator. > > Best wishes > Qiong > > > On Mon, Jul 29, 2013 at 8:25 PM, Liu Dapeng wrote: > >> Hi Qiong: >> >> I am wondering whether you are aware of that NAT46 has been discussed >> three years ago in Behave. For example >> http://tools.ietf.org/html/draft-liu-behave-nat46-02 have proposed a >> solution for NAT46. Maybe you could leverage on that. >> >> Dapeng Liu >> >> >> 2013/7/9 Qiong >> >>> Dear all, >>> >>> We have submitted a new draft for IPv4 client to IPv6 server. It is >>> designed to cover the Scenario 2 in RFC6144. It can save the public >>> IPv4 addresses consumed by IPv6 side and does not have impact on existing >>> applications. >>> >>> Your comments/reviews are appreciated. >>> >>> Best wishes >>> Qiong >>> >>> >>> ---------- Forwarded message ---------- >>> From: internet-drafts@ietf.org >>> Date: Mon, 08 Jul 2013 08:16:36 -0700 >>> Subject: I-D Action: draft-sun-behave-v4tov6-00.txt >>> To: i-d-announce@ietf.org >>> >>> A new version of I-D, draft-sun-behave-v4tov6-00.txt >>> has been successfully submitted by Chongfeng Xie and posted to the >>> IETF repository. >>> >>> Filename: draft-sun-behave-v4tov6 >>> Revision: 00 >>> Title: The Approach for IPv4-only users to access IPv6-only Content >>> Creation date: 2013-07-08 >>> Group: Individual Submission >>> Number of pages: 13 >>> URL: http://www.ietf.org/internet-drafts/draft-sun-behave-v4tov6-00.txt >>> Status: http://datatracker.ietf.org/doc/draft-sun-behave-v4tov6 >>> Htmlized: http://tools.ietf.org/html/draft-sun-behave-v4tov6-00 >>> >>> >>> Abstract: >>> Current approaches can not solve the scenario that the users from >>> IPv4 Internet to access IPv6-only content. When IPv6 content are >>> becoming more and more popular, it is important to ensure that IPv6- >>> only content can be reachable from legacy IPv4-only clients via some >>> IPv4-only network. This document proposes two approaches for IPv4- >>> only users to access IPv6-only content. It is designed to cover the >>> Scenario 2 in [RFC6144]. >>> >>> >>> >>> >>> >>> The IETF Secretariat >>> >>> -- >>> ============================================== >>> Qiong Sun >>> China Telecom Beijing Research Institute >>> >>> >>> Open source code: >>> lightweight 4over6: *http://sourceforge.net/projects/laft6/* >>> PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * >>> =============================================== >>> >>> >>> _______________________________________________ >>> Behave mailing list >>> Behave@ietf.org >>> https://www.ietf.org/mailman/listinfo/behave >>> >>> >> >> >> -- >> >> ------ >> Best Regards, >> Dapeng Liu >> > > > > -- > ============================================== > Qiong Sun > China Telecom Beijing Research Institude > > > > Open source code: > lightweight 4over6: *http://sourceforge.net/projects/laft6/* > PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * > =============================================== > > -- ------ Best Regards, Dapeng Liu --047d7b3a8c12c0e93904e2a6ebe0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Qiong,

Thanks for the clarific= ation. Configuring static mapping in DNS requires the operator has control = of both the=A0authoritative DNS server and the translator. That could be po= ssible in data center scenario but for large scale deployment, I am=A0afrai= d that the dynamic mapping still would be needed?

Regards,
Dapeng Liu=A0


2013/7= /29 Qiong <bingxuere@gmail.com>
Hi Dapeng,

Thanks for pointing out. I think the major difference is that we use sta= tic mapping while draft-liu-behave-nat46 uses dynamic mapping. That's w= hy we do not need to embed DNS46 in the translator.

Best wishes
Qiong


On Mon= , Jul 29, 2013 at 8:25 PM, Liu Dapeng <maxpassion@gmail.com> wrote:
Hi Qiong:

I am wondering whether you are aware of that NAT46 has been discussed thr= ee years ago in Behave. For example http://tools.ietf.org/html/draf= t-liu-behave-nat46-02 have proposed a solution for NAT46. Maybe you cou= ld leverage on that.

Dapeng Liu

2013/7/9 Qiong <bingxuere@gmail.com&g= t;
Dear all,

We have submitted a new draft for IPv4 client to IPv6 server. It is desi= gned to cover the Scenario=A02=A0= in RFC6144. It can save the public IPv4 addresses consumed by IPv6 side and= does not have impact on existing applications.

Your comments/reviews are appreciated.

Best wishes
Qiong


---------- Forwarded message ----------
From:=A0= internet-drafts@ietf.org
Date: Mon, 08 J= ul 2013 08:16:36 -0700
Sub= ject: I-D Action:=A0draft-sun-behav= e-v4tov6-00.txt
To:=A0i-d-announce@ietf.org

A=A0new=A0version=A0of=A0I-D,=A0draft-sun-behave-= v4tov6-00.txt
has=A0been=A0successfully=A0submitted=A0by=A0Chongfeng=A0Xie=A0and=A0p= osted=A0to=A0the
IETF=A0repository.
=A0
Filename: =A0draft-sun-behave-v4tov6
Revision: =A000
Title: =A0The=A0Approach=A0for=A0IPv4-only=A0users=A0to=A0access=A0IPv= 6-only=A0Content
Creation=A0date: =A02013-07-08
Group: =A0Individual=A0Submission
Number=A0of=A0pages:=A013
=A0
=A0
Abstract:
=A0=A0=A0Current=A0approaches=A0can=A0not=A0solve=A0the=A0scenario=A0t= hat=A0the=A0users=A0from
=A0=A0=A0IPv4=A0Internet=A0to=A0access=A0IPv6-only=A0content.=A0=A0Whe= n=A0IPv6=A0content=A0are
=A0=A0=A0becoming=A0more=A0and=A0more=A0popular,=A0it=A0is=A0important= =A0to=A0ensure=A0that=A0IPv6-
=A0=A0=A0only=A0content=A0can=A0be=A0reachable=A0from=A0legacy=A0IPv4-= only=A0clients=A0via=A0some
=A0=A0=A0IPv4-only=A0network.=A0=A0This=A0document=A0proposes=A0two=A0= approaches=A0for=A0IPv4-
=A0=A0=A0only=A0users=A0to=A0access=A0IPv6-only=A0content.=A0=A0It=A0i= s=A0designed=A0to=A0cover=A0the
=A0=A0=A0Scenario=A02=A0in=A0[RFC6144].
=A0
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0
=A0
=A0
The=A0IETF=A0Secretariat

<= /div>--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
Qiong Sun
China Telecom Beijing Research Institute


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

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




--

------
Best Regards,
Dapeng Liu



--
=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Qiong Sun
<= /div>China Telecom Beijing Research Institude



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



--

------Best Regards,
Dapeng Liu
--047d7b3a8c12c0e93904e2a6ebe0-- From satoru.matsushima@gmail.com Mon Jul 29 07:12:42 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0791711E80EA for ; Mon, 29 Jul 2013 07:12:41 -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] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d-9aKtu0bBAB for ; Mon, 29 Jul 2013 07:12:37 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 8055711E80E6 for ; Mon, 29 Jul 2013 07:12:32 -0700 (PDT) Received: by mail-pa0-f48.google.com with SMTP id kp13so4659219pab.35 for ; Mon, 29 Jul 2013 07:12:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=Oh3f1cBZZMpwIo7WQ/G+jcpG/loLhdFE9QPMdeapffM=; b=Ic3+As8pnToFpbzbFIZuhZd94CI01XW4/06uzxm7/HvF8c5J5NG6lPyF/mCCvzOVC1 MbbF+udCu27nRCzh5XB60PnpleDWImqGCjEw64Tecvi7mxIDPDAGyc+vCpBQtgA6uEl0 p/FNEk+0e8Yv7+ClbgB0OOGDPla3cqDy67rjtICnufMyCyCsu0zDlCYl9NnYEvhSu8uC ZxJIkIQSSoLLhbAIb1K6E242zvtXB1Dw18HX8Z6KFK6PVYT/AdXWXZmdJKZ7Uwv4D06J 3wFNtsFJ/EEAcOtatbzYA78dm/yeUM+uGIrmRqW8LginIjXlcdZIMZNuqF3V+0xqE7UO q5hQ== X-Received: by 10.69.8.65 with SMTP id di1mr60907470pbd.32.1375107152119; Mon, 29 Jul 2013 07:12:32 -0700 (PDT) Received: from dhcp-560e.meeting.ietf.org (dhcp-560e.meeting.ietf.org. [130.129.86.14]) by mx.google.com with ESMTPSA id ys4sm77253060pbb.9.2013.07.29.07.12.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Jul 2013 07:12:28 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Satoru Matsushima In-Reply-To: Date: Mon, 29 Jul 2013 16:12:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Qiong X-Mailer: Apple Mail (2.1508) Cc: "behave@ietf.org" , Satoru Matsushima Subject: Re: [BEHAVE] I-D Action: draft-sun-behave-v4tov6-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 14:12:42 -0000 Hi Qiong, Thanks for the interesting draft.=20 Just one comment on the mapping table described in the draft.=20 What I though is that it seems that the mapping table is very similar = with FMR on MAP-T CE. (I believe you can share my thought. ;) Both two approach mentioned in the draft would be trigger to register = FMR dynamically into MAP-T CE as NAT46 device. Hope it helps --satoru=20 On 2013/07/09, at 16:17, Qiong wrote: > Dear all, >=20 > We have submitted a new draft for IPv4 client to IPv6 server. It is = designed to cover the Scenario 2 in RFC6144. It can save the public IPv4 = addresses consumed by IPv6 side and does not have impact on existing = applications. >=20 > Your comments/reviews are appreciated. >=20 > Best wishes > Qiong >=20 >=20 > ---------- Forwarded message ---------- > From: internet-drafts@ietf.org > Date: Mon, 08 Jul 2013 08:16:36 -0700 > Subject: I-D Action: draft-sun-behave-v4tov6-00.txt > To: i-d-announce@ietf.org >=20 > A new version of I-D, draft-sun-behave-v4tov6-00.txt > has been successfully submitted by Chongfeng Xie and posted to the > IETF repository. > =20 > Filename: draft-sun-behave-v4tov6 > Revision: 00 > Title: The Approach for IPv4-only users to access IPv6-only Content > Creation date: 2013-07-08 > Group: Individual Submission > Number of pages: 13 > URL: = http://www.ietf.org/internet-drafts/draft-sun-behave-v4tov6-00.txt > Status: http://datatracker.ietf.org/doc/draft-sun-behave-v4tov6 > Htmlized: http://tools.ietf.org/html/draft-sun-behave-v4tov6-00 > =20 > =20 > Abstract: > Current approaches can not solve the scenario that the users from > IPv4 Internet to access IPv6-only content. When IPv6 content are > becoming more and more popular, it is important to ensure that = IPv6- > only content can be reachable from legacy IPv4-only clients via = some > IPv4-only network. This document proposes two approaches for IPv4- > only users to access IPv6-only content. It is designed to cover = the > Scenario 2 in [RFC6144]. > =20 > = =20 > =20 > =20 > The IETF Secretariat >=20 > --=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Qiong Sun > China Telecom Beijing Research Institute >=20 >=20 > Open source code: > lightweight 4over6: http://sourceforge.net/projects/laft6/ > PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave From ajs@anvilwalrusden.com Mon Jul 29 07:39:37 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4ED921F992B for ; Mon, 29 Jul 2013 07:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qg+CDnL-Q7jA for ; Mon, 29 Jul 2013 07:39:32 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id BA28C21F9D12 for ; Mon, 29 Jul 2013 07:39:31 -0700 (PDT) Received: from mx1.yitter.info (dhcp-64bf.meeting.ietf.org [130.129.100.191]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id D33518A031 for ; Mon, 29 Jul 2013 14:39:11 +0000 (UTC) Date: Mon, 29 Jul 2013 10:39:11 -0400 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20130729143910.GB51823@mx1.yitter.info> References: <20130729134623.GD51737@mx1.yitter.info> <51F674D0.3040603@viagenie.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51F674D0.3040603@viagenie.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [BEHAVE] Fwd: I-D Action: draft-sun-behave-v4tov6-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 14:39:38 -0000 On Mon, Jul 29, 2013 at 03:57:36PM +0200, Simon Perreault wrote: > >I suggest that it is a problem we do _not_ want to solve. It keeps > >v4-only nodes alive longer. That's not a goal I share. > > By that logic, dual stack servers should move to v6-only. I don't see why. Dual-stack servers need no new work to make them function. As near as I can tell, dual stack works just fine today. In contrast, the v4-initiates-to-v6 problem requires lots of new work, and new work to solve a fundamentally insoluble problem (i.e. to make a much larger address space work seamlessly inside a much smaller address space). The IETF has finite intellectual resources, and I claim that it is wasteful to spend some of those on the problem of initiating connections from a v4 network towards a v6 network. Anyone who has a v4 address today ought to be able to get a v6 address too. So they _could_ all operate dual stack, and should have no trouble getting to v6-only nodes. If there are nodes that are so incapable that they just can't have a v6 stack at all, I am not convinced that we should standardize a protocol to make that problem better. The best we're ever going to come up with is a kludge, and for such systems any kluge will probably do, so the uninteroperatable kludges that are already commercially available are probably good enough for such cases. Way back when we had the v4/v6 co-existence interim in Montreal, we were urged to pick the cases that we were going to solve, and we have since then been busy filling in all the other boxes in the space no matter whether the work makes anything better. V4-to-v6 NATs, in my opinion, fall into the "make things worse" bucket, and I therefore argue that such things should not be standardized. They're at best temporary hacks, and they're never going to be good anyway. Just Say No. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From brian.e.carpenter@gmail.com Mon Jul 29 14:01:24 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8644E21F995B for ; Mon, 29 Jul 2013 14:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, 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 p-GWeKFqcFGQ for ; Mon, 29 Jul 2013 14:01:24 -0700 (PDT) Received: from mail-pb0-x22c.google.com (mail-pb0-x22c.google.com [IPv6:2607:f8b0:400e:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id E277821F9946 for ; Mon, 29 Jul 2013 14:01:18 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id wy7so5113181pbc.3 for ; Mon, 29 Jul 2013 14:01:14 -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=s5J/c9GXeZb/SI+uDdOj5Bae1NrMXBSb0GoqukWR3dM=; b=VY7s2OSp1JOWsi4flwYQn6V3MWQTX0A+Y41cli0TN0gjoys/zs3Baxy0DwJT8cAVmS MXSpYI47YKjZcYSdolAII+M2hQUuRK6hx72pP24WSc360NGHL532zYpxlDxF8J6TVu2r GLYPy9dZxh+9M5ftocIWb1iLN8ByMCQOC80XTE652R+AVSfaVYE18QJ8UMalmTGeHyt5 Vuy19VBHwIDZSdktHYVcxZMtQYRDp2R1z7sDLDi7KPjYTJfYpVeOTeMe9rGgJrWhBFUz PDh/zVI9Q/dYljZrf9IJ+vWXoeR3jjqudtAzHzGdyvyLTCvzCevIoedJvyB1eA/m/E6j /64A== X-Received: by 10.66.50.104 with SMTP id b8mr72068357pao.39.1375131674743; Mon, 29 Jul 2013 14:01:14 -0700 (PDT) Received: from [192.168.178.23] (225.199.69.111.dynamic.snap.net.nz. [111.69.199.225]) by mx.google.com with ESMTPSA id ss8sm22717463pab.6.2013.07.29.14.01.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Jul 2013 14:01:14 -0700 (PDT) Message-ID: <51F6D81A.4010608@gmail.com> Date: Tue, 30 Jul 2013 09:01:14 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Andrew Sullivan References: <20130729134623.GD51737@mx1.yitter.info> <51F674D0.3040603@viagenie.ca> <20130729143910.GB51823@mx1.yitter.info> In-Reply-To: <20130729143910.GB51823@mx1.yitter.info> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: behave@ietf.org Subject: Re: [BEHAVE] Fwd: I-D Action: draft-sun-behave-v4tov6-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 21:01:24 -0000 On 30/07/2013 02:39, Andrew Sullivan wrote: > On Mon, Jul 29, 2013 at 03:57:36PM +0200, Simon Perreault wrote: >>> I suggest that it is a problem we do _not_ want to solve. It keeps >>> v4-only nodes alive longer. That's not a goal I share. >> By that logic, dual stack servers should move to v6-only. > > I don't see why. Dual-stack servers need no new work to make them > function. As near as I can tell, dual stack works just fine today. > > In contrast, the v4-initiates-to-v6 problem requires lots of new work, > and new work to solve a fundamentally insoluble problem (i.e. to make > a much larger address space work seamlessly inside a much smaller > address space). > > The IETF has finite intellectual resources, and I claim that it is > wasteful to spend some of those on the problem of initiating > connections from a v4 network towards a v6 network. I fully agree. Why should we spend precious resources helping legacy ISPs to delay IPv6? I think it's time for a further charter update. This case is already in the category "will not be solved by BEHAVE" but for some reason also in the category "in scope for discussion". I suggest simply removing scenario (4) from the charter. Any effort released can be devoted to sunset4. Brian Anyone who has a > v4 address today ought to be able to get a v6 address too. So they > _could_ all operate dual stack, and should have no trouble getting to > v6-only nodes. If there are nodes that are so incapable that they > just can't have a v6 stack at all, I am not convinced that we should > standardize a protocol to make that problem better. The best we're > ever going to come up with is a kludge, and for such systems any kluge > will probably do, so the uninteroperatable kludges that are already > commercially available are probably good enough for such cases. > > Way back when we had the v4/v6 co-existence interim in Montreal, we > were urged to pick the cases that we were going to solve, and we have > since then been busy filling in all the other boxes in the space no > matter whether the work makes anything better. V4-to-v6 NATs, in my > opinion, fall into the "make things worse" bucket, and I therefore > argue that such things should not be standardized. They're at best > temporary hacks, and they're never going to be good anyway. Just Say > No. > > Best, > > A > From Branimir.Rajtar@t.ht.hr Mon Jul 29 14:03:44 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02AB911E814D for ; Mon, 29 Jul 2013 14:03: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 QDwFBqqJjf2H for ; Mon, 29 Jul 2013 14:03:39 -0700 (PDT) Received: from mx02.t.ht.hr (mx02.t.ht.hr [195.29.161.89]) by ietfa.amsl.com (Postfix) with SMTP id 2853A21F9AF8 for ; Mon, 29 Jul 2013 14:03:38 -0700 (PDT) Received: from (unknown [172.17.66.76]) by mx02.t.ht.hr with smtp id 1d64_19a4_563da66a_f892_11e2_9988_00219b931f47; Mon, 29 Jul 2013 23:03:36 +0200 Received: from S2010EXCHCA2.ad.local ([10.240.132.165]) by mailgw.ad.local with Microsoft SMTPSVC(6.0.3790.4675); Mon, 29 Jul 2013 23:03:36 +0200 Received: from S2010EXCH1.ad.local ([fe80::2d7b:39dd:876e:f277]) by S2010EXCHCA2.ad.local ([::1]) with mapi id 14.03.0123.003; Mon, 29 Jul 2013 23:03:36 +0200 From: Branimir Rajtar To: Andrew Sullivan , "behave@ietf.org" Thread-Topic: [BEHAVE] Fwd: I-D Action: draft-sun-behave-v4tov6-00.txt Thread-Index: AQHOjFblzsHEEv8Vykiq3dM2cuYBjZl7gD0AgAAJlICAAAMiAIAAC5+AgACKOfA= Date: Mon, 29 Jul 2013 21:03:35 +0000 Message-ID: <786F13AA11E69F4DB2CCA23F7400C2FB01477A83@S2010EXCH1.ad.local> References: <20130729134623.GD51737@mx1.yitter.info> <51F674D0.3040603@viagenie.ca> <20130729143910.GB51823@mx1.yitter.info> In-Reply-To: <20130729143910.GB51823@mx1.yitter.info> Accept-Language: en-US, hr-HR Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.5.13] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 29 Jul 2013 21:03:36.0958 (UTC) FILETIME=[17EF71E0:01CE8C9F] X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 Subject: Re: [BEHAVE] Fwd: I-D Action: draft-sun-behave-v4tov6-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 21:03:44 -0000 SGkgQW5kcmV3LAoKSSBtdXN0IGRpc2FncmVlIHdpdGggeW91LiAKCkZpcnN0IG9mIGFsbCwgSSBm ZWVsIHRoYXQgdGhlcmUgYXJlIGEgbG90IG9mIHBlb3BsZSB3aXRoaW4gdGhlIHdvcmtpbmcgZ3Jv dXAgd2hvIHdpc2ggdGhpcyBwcm9ibGVtIHRvIGJlIHNvbHZlZC4gTG9vayBhdCB0aGUgYW1vdW50 IG9mIHdvcmsgdGhhdCB3YXMgcHV0IGludG8gUkZDNjE0NSwgSSBiZWxpZXZlIHlvdSdyZSB0cnlp bmcgdG8gc2F5IHRoYXQgdGhlIHdvcmsgdGhleSBkaWQgaXMgd29ydGhsZXNzIC0gYXMgSSB1bmRl cnN0YW5kLCB5b3Ugc2F5IHRoYXQgZXZlcnlib2R5IHNob3VsZCBuYXRpdmVseSBoYXZlIHY2IGFj Y2VzcyBhbmQgdGhlcmVmb3JlIHRyYW5zbGF0aW9uIGlzIG5vdCBuZWVkZWQuIEkgYWdyZWUgdGhh dCBldmVyeWJvZHkgc2hvdWxkIGhhdmUgSVB2NiwgYnV0IHRoYXQncyBqdXN0IG5vdCB0aGUgd29y bGQgd2UgbGl2ZSBpbi4KClNlY29uZGx5LCB3ZSdyZSBub3QgdHJ5aW5nIHRvIGludmVudCBhbnkg bmV3IHByb3RvY29sLCB3ZSdyZSBqdXN0IHRyeWluZyB0byBwdXQgdG9nZXRoZXIgcGllY2VzIHdl IGhhdmUgYWxyZWFkeS4gSSBkb24ndCB0aGluayB0aGlzIGlzIGEgYmlnIGVmZm9ydCB0byBpbXBs ZW1lbnQsIGl0IGp1c3QgbmVlZHMgdG8gYmUgYWxpZ25lZCBob3cgaXQgc2hvdWxkIHdvcmsuCgpG aW5hbGx5LCBJIHRoaW5rIHRoaXMgd291bGQgbm90IHByb2xvbmcgdGhlIGxpZmUgb2YgSVB2NCBh cyB5b3Ugc2F5LiBPbiB0aGUgY29udHJhcnksIGNvbnRlbnQgd291bGQgYmUgYWNjZXNzZWQgbW9y ZSBhbmQgbW9yZSB2aWEgSVB2NiBhbmQgdGhlcmVmb3JlIHRoZSBuZWVkIGZvciBtYWludGFpbmlu ZyBkdWFsLXN0YWNrIHNlcnZlcnMgd291bGQgZGVjbGluZTsgb25seSBJUHY2IHdvdWxkIGJlIG5l ZWRlZC4KIApCUiwKQnJhbmltaXIKCgotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQpGcm9tOiBi ZWhhdmUtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmJlaGF2ZS1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgQW5kcmV3IFN1bGxpdmFuClNlbnQ6IE1vbmRheSwgSnVseSAyOSwgMjAxMyA0 OjM5IFBNClRvOiBiZWhhdmVAaWV0Zi5vcmcKU3ViamVjdDogUmU6IFtCRUhBVkVdIEZ3ZDogSS1E IEFjdGlvbjogZHJhZnQtc3VuLWJlaGF2ZS12NHRvdjYtMDAudHh0CgpPbiBNb24sIEp1bCAyOSwg MjAxMyBhdCAwMzo1NzozNlBNICswMjAwLCBTaW1vbiBQZXJyZWF1bHQgd3JvdGU6Cj4gPkkgc3Vn Z2VzdCB0aGF0IGl0IGlzIGEgcHJvYmxlbSB3ZSBkbyBfbm90XyB3YW50IHRvIHNvbHZlLiAgSXQg a2VlcHMKPiA+djQtb25seSBub2RlcyBhbGl2ZSBsb25nZXIuICBUaGF0J3Mgbm90IGEgZ29hbCBJ IHNoYXJlLgo+IAo+IEJ5IHRoYXQgbG9naWMsIGR1YWwgc3RhY2sgc2VydmVycyBzaG91bGQgbW92 ZSB0byB2Ni1vbmx5LgoKSSBkb24ndCBzZWUgd2h5LiAgRHVhbC1zdGFjayBzZXJ2ZXJzIG5lZWQg bm8gbmV3IHdvcmsgdG8gbWFrZSB0aGVtCmZ1bmN0aW9uLiAgQXMgbmVhciBhcyBJIGNhbiB0ZWxs LCBkdWFsIHN0YWNrIHdvcmtzIGp1c3QgZmluZSB0b2RheS4KCkluIGNvbnRyYXN0LCB0aGUgdjQt aW5pdGlhdGVzLXRvLXY2IHByb2JsZW0gcmVxdWlyZXMgbG90cyBvZiBuZXcgd29yaywKYW5kIG5l dyB3b3JrIHRvIHNvbHZlIGEgZnVuZGFtZW50YWxseSBpbnNvbHVibGUgcHJvYmxlbSAoaS5lLiB0 byBtYWtlCmEgbXVjaCBsYXJnZXIgYWRkcmVzcyBzcGFjZSB3b3JrIHNlYW1sZXNzbHkgaW5zaWRl IGEgbXVjaCBzbWFsbGVyCmFkZHJlc3Mgc3BhY2UpLgoKVGhlIElFVEYgaGFzIGZpbml0ZSBpbnRl bGxlY3R1YWwgcmVzb3VyY2VzLCBhbmQgSSBjbGFpbSB0aGF0IGl0IGlzCndhc3RlZnVsIHRvIHNw ZW5kIHNvbWUgb2YgdGhvc2Ugb24gdGhlIHByb2JsZW0gb2YgaW5pdGlhdGluZwpjb25uZWN0aW9u cyBmcm9tIGEgdjQgbmV0d29yayB0b3dhcmRzIGEgdjYgbmV0d29yay4gIEFueW9uZSB3aG8gaGFz IGEKdjQgYWRkcmVzcyB0b2RheSBvdWdodCB0byBiZSBhYmxlIHRvIGdldCBhIHY2IGFkZHJlc3Mg dG9vLiAgU28gdGhleQpfY291bGRfIGFsbCBvcGVyYXRlIGR1YWwgc3RhY2ssIGFuZCBzaG91bGQg aGF2ZSBubyB0cm91YmxlIGdldHRpbmcgdG8KdjYtb25seSBub2Rlcy4gIElmIHRoZXJlIGFyZSBu b2RlcyB0aGF0IGFyZSBzbyBpbmNhcGFibGUgdGhhdCB0aGV5Cmp1c3QgY2FuJ3QgaGF2ZSBhIHY2 IHN0YWNrIGF0IGFsbCwgSSBhbSBub3QgY29udmluY2VkIHRoYXQgd2Ugc2hvdWxkCnN0YW5kYXJk aXplIGEgcHJvdG9jb2wgdG8gbWFrZSB0aGF0IHByb2JsZW0gYmV0dGVyLiAgVGhlIGJlc3Qgd2Un cmUKZXZlciBnb2luZyB0byBjb21lIHVwIHdpdGggaXMgYSBrbHVkZ2UsIGFuZCBmb3Igc3VjaCBz eXN0ZW1zIGFueSBrbHVnZQp3aWxsIHByb2JhYmx5IGRvLCBzbyB0aGUgdW5pbnRlcm9wZXJhdGFi bGUga2x1ZGdlcyB0aGF0IGFyZSBhbHJlYWR5CmNvbW1lcmNpYWxseSBhdmFpbGFibGUgYXJlIHBy b2JhYmx5IGdvb2QgZW5vdWdoIGZvciBzdWNoIGNhc2VzLgoKV2F5IGJhY2sgd2hlbiB3ZSBoYWQg dGhlIHY0L3Y2IGNvLWV4aXN0ZW5jZSBpbnRlcmltIGluIE1vbnRyZWFsLCB3ZQp3ZXJlIHVyZ2Vk IHRvIHBpY2sgdGhlIGNhc2VzIHRoYXQgd2Ugd2VyZSBnb2luZyB0byBzb2x2ZSwgYW5kIHdlIGhh dmUKc2luY2UgdGhlbiBiZWVuIGJ1c3kgZmlsbGluZyBpbiBhbGwgdGhlIG90aGVyIGJveGVzIGlu IHRoZSBzcGFjZSBubwptYXR0ZXIgd2hldGhlciB0aGUgd29yayBtYWtlcyBhbnl0aGluZyBiZXR0 ZXIuICBWNC10by12NiBOQVRzLCBpbiBteQpvcGluaW9uLCBmYWxsIGludG8gdGhlICJtYWtlIHRo aW5ncyB3b3JzZSIgYnVja2V0LCBhbmQgSSB0aGVyZWZvcmUKYXJndWUgdGhhdCBzdWNoIHRoaW5n cyBzaG91bGQgbm90IGJlIHN0YW5kYXJkaXplZC4gIFRoZXkncmUgYXQgYmVzdAp0ZW1wb3Jhcnkg aGFja3MsIGFuZCB0aGV5J3JlIG5ldmVyIGdvaW5nIHRvIGJlIGdvb2QgYW55d2F5LiAgSnVzdCBT YXkKTm8uCgpCZXN0LAoKQQoKLS0gCkFuZHJldyBTdWxsaXZhbgphanNAYW52aWx3YWxydXNkZW4u Y29tCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCkJlaGF2 ZSBtYWlsaW5nIGxpc3QKQmVoYXZlQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vYmVoYXZlCgoKPEhUTUw+PFA+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jOTk5 OTk5IHNpemU9MT4NCg0KSVpKQVZBIE8gT0RSSUNBTkpVIE9ER09WT1JOT1NUSTogU2FkcsW+YWog b3ZlIHBvcnVrZSBpIGV2ZW50dWFsbm8gcHJpbG/FvmVuaWggZGF0b3Rla2EgamUgcG92amVybGpp diBpIG5hbWlqZW5qZW4gamUgc2FtbyBvc29iYW1hIGlsaSBzdWJqZWt0aW1hIGtvamkgc3UgbmF2 ZWRlbmkgdSBhZHJlc2kuIFVrb2xpa28gc3RlIHByaW1pbGkgb3Z1IHBvcnVrdSBncmXFoWtvbSwg bW9saW1vIFZhcywgb2JhdmlqZXN0aXRlIHBvxaFpbGphdGVsamEsIGEgcG9ydWt1IGkgc3ZlIG5q ZW5lIHByaXZpdGtlIG9kbWFoLCBiZXogxI1pdGFuamEsIHRyYWpubyB1a2xvbml0ZSBzIHJhxI11 bmFsYS4gQmlsbyBrYWt2byBwcmVub8WhZW5qZSwga29waXJhbmplIGlsaSBkaXN0cmlidWNpamEg aW5mb3JtYWNpamEgc2FkcsW+YW5paCB1IHBvcnVjaSB0cmXEh2ltIG9zb2JhbWEgamUgemFicmFu amVubyBpIG1vxb5lIGJpdGkgemFrb25za2kga2HFvm5qaXZvLiBTYWRyxb5haiwgc3Rhdm92aSBp IG1pxaFsamVuamEgaXpuZXNlbmkgdSBwb3J1Y2kgc3UgYXV0b3JvdmkgaSBuZSBwcmVkc3Rhdmxq YWp1IG51xb5ubyBzdGF2b3ZlIEhUIC0gSHJ2YXRza2loIHRlbGVrb211bmlrYWNpamEgZC5kLiBI VCBuZSBwcmlodmHEh2EgbmlrYWt2dSBvZGdvdm9ybm9zdCB6YSBldmVudHVhbG51IMWhdGV0dSBu YXN0YWx1IHByaW1pdGtvbSBvdmUgcG9ydWtlIGkgcHJpbG9nYSBzYWRyxb5hbmloIHUgcG9ydWNp Lg0KDQo8L0ZPTlQ+PC9QPjxQPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9Izk5OTk5OSBzaXplPTE+ DQoNCiBESVNDTEFJTUVSOlRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFzIHdlbGwgYXMgYW55 IGZpbGVzIGF0dGFjaGVkIHRvIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVs eSBmb3IgaW5kaXZpZHVhbHMgb3IgZW50aXRpZXMgd2hpY2ggdGhleSBhcmUgYWRkcmVzc2VkIHRv LiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIG1lc3NhZ2UgaW4gZXJyb3IsIHBsZWFz ZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgcGVybWFuZW50bHkgcmVtb3ZlIHRoZSBtZXNzYWdlIGFu ZCBhbGwgYXR0YWNoZWQgZmlsZXMgZnJvbSB0aGUgY29tcHV0ZXIuIEFueSBkaXNjbG9zdXJlLCBj b3B5aW5nIG9yIGRpc3RyaWJ1dGlvbiBvZiBhbGwgb3IgYSBwYXJ0IG9mIGluZm9ybWF0aW9uIGNv bnRhaW5lZCBoZXJlaW4gdG8gb3IgYnkgdGhpcmQgcGFydGllcyBpcyBwcm9oaWJpdGVkIGFuZCBt YXkgYmUgdW5sYXdmdWwuIFBsZWFzZSBub3RlIHRoYXQgYW55IHZpZXdzIG9yIG9waW5pb25zIHBy ZXNlbnRlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHNvbGVseSB0aG9zZSBvZiB0aGUgYXV0aG9yIGFu ZCBkbyBub3QgbmVjZXNzYXJpbHkgcmVwcmVzZW50IHRoZSB2aWV3cyBhbmQgb3BpbmlvbnMgb2Yg Q3JvYXRpYW4gVGVsZWNvbSBJbmMuIENyb2F0aWFuIFRlbGVjb20gSW5jLiBhY2NlcHRzIG5vIGxp YWJpbGl0eSBmb3IgYW55IHBvdGVudGlhbCBkYW1hZ2UgY2F1c2VkIGJ5IHRoaXMgbWVzc2FnZSBh bmQgZmlsZXMgYXR0YWNoZWQgdG8gaXQuDQoNCjwvRk9OVD48L1A+PC9IVE1MPgo= From ajs@anvilwalrusden.com Mon Jul 29 16:11:09 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77E2B21F9C0E for ; Mon, 29 Jul 2013 16:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lhobOkBVsizu for ; Mon, 29 Jul 2013 16:11:03 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id DFF2921E8094 for ; Mon, 29 Jul 2013 16:11:01 -0700 (PDT) Received: from mx1.yitter.info (dhcp-4783.meeting.ietf.org [130.129.71.131]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 946958A031 for ; Mon, 29 Jul 2013 23:10:58 +0000 (UTC) Date: Mon, 29 Jul 2013 19:10:59 -0400 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20130729231058.GB52180@mx1.yitter.info> References: <20130729134623.GD51737@mx1.yitter.info> <51F674D0.3040603@viagenie.ca> <20130729143910.GB51823@mx1.yitter.info> <786F13AA11E69F4DB2CCA23F7400C2FB01477A83@S2010EXCH1.ad.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <786F13AA11E69F4DB2CCA23F7400C2FB01477A83@S2010EXCH1.ad.local> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [BEHAVE] Fwd: I-D Action: draft-sun-behave-v4tov6-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 23:11:09 -0000 Hi, On Mon, Jul 29, 2013 at 09:03:35PM +0000, Branimir Rajtar wrote: > First of all, I feel that there are a lot of people within the > working group who wish this problem to be solved. I am aware of that. But, as the old saw goes around here, "I want a pony." Merely wishing a problem to be solved is not enough to show that it should be solved. Among other considerations, from the point of view of the overall network, there is the question of whether that solution imposes costs on the rest of the network. I argue that, in this case, the solution _does_ impose such costs. At the very least, these documents need review, and the review distracts people from doing other useful work. But also, building a system for a v4-only host to cope with the address range of the entire IPv6 world is unlikely to be without effects elsewhere. And once this sort of sludge is deployed on the Internet, it is not in the future possible to discount it. We live with it forever. (Look at the DNS. Or the other issues that plain old NAT44 imposes.) > of work that was put into RFC6145, I believe you're trying to say > that the work they did is worthless I am not. I also worked hard on some transition mechanisms, and while I think DNS64 imposes a lot of costs and has many undesirable properties, I still think it was the right thing to do. I was not especially delighted with RFC 6145, but it seemed to me to be, on balance, not an obviously bad solution to some problems people actually had. > - as I understand, you say that everybody should natively have v6 > access and therefore translation is not needed. No. What I am saying is that anyone who in the future has only IPv4 connectivity and needs to reach an IPv6 address will have basically two choices: 1. Get an IPv6 address, and run dual stack. 2. Add a bunch of sludge to the system to attempt to map the enormous IPv6 space into the much smaller IPv4 space. I can think of very few cases where the choice between these two options demands even three nanoseconds of thought. (1) will work. (2) will at the very least present a much worse experience than (1). So what are the use cases for (2)? A. Can't get IPv6. But of course, with the various tunnel systems (some of which are free), this isn't true of anyone except people running incredibly inflexible systems. See below. B. A device which is mission critical, too valuable to replace, and too ill-maintained to upgrade. (These people literally can't handle IPv6 addresses, and have no hope of being able to do.) The problem here is that every case of (B) is too specialized for there to be a useful generic system anyway. If your system is _actually_ that creaky, then there is every reason to suppose that one of the ways in which the v4/v6 translation mechanism doesn't work perfectly is going to cause problems anyway. So in effect, every real example of this is going to require a bespoke effort. Most of the cases of (B) I've heard offered are actually more like this: C. I have a device which is valuable, and a lot of work for me to upgrade, so I want to externalise those costs to the network. To offer a parody, "I want a pony. Also, someone else has to buy it, feed it, and groom it." And that's why I think we should not work on this scenario. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From brian.e.carpenter@gmail.com Mon Jul 29 16:42:39 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BED6A11E8146 for ; Mon, 29 Jul 2013 16:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.402 X-Spam-Level: X-Spam-Status: No, score=-102.402 tagged_above=-999 required=5 tests=[AWL=-0.118, BAYES_00=-2.599, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BB6OL+3akV2S for ; Mon, 29 Jul 2013 16:42:38 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 0928011E813A for ; Mon, 29 Jul 2013 16:42:33 -0700 (PDT) Received: by mail-pa0-f49.google.com with SMTP id bi5so6397431pad.8 for ; Mon, 29 Jul 2013 16:42: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=/RMZntZnCDlJkkkJweRJNhkPEYeGbgb2j7iydMIFO00=; b=RuZguxptWTy1Y5or4RC9pag2+7b1gfmpXVAjilL/j3qMxOhONLMuQUaYB2Ys4ghYnT yVXIPB0/0p9xFy4Sp3IcRYu7ULMXIWfRaLwiMVr81d38i3PhQbFVDS8TeWo8eGvalR93 FYRWtHUT14rovED2PPqjrPFrmxuE0ajVPTiBLjSlVNcceMCC8oQXQlprMPJgBn6TUwCV eu/hHJis8/1xMB6qvn12Y0rUod8f/Ixzwkfnff4YxBLEEx7e26JnmRMm3PGFo9pYHkwi fhljkbzp7RxKM2yEj/r2QZFtZQxYk3uu9lHutl7dUZwyAaemqpWZ5kYP+7Y2wGgPulga T8wQ== X-Received: by 10.68.232.41 with SMTP id tl9mr71032006pbc.204.1375141353471; Mon, 29 Jul 2013 16:42:33 -0700 (PDT) Received: from [192.168.178.23] (225.199.69.111.dynamic.snap.net.nz. [111.69.199.225]) by mx.google.com with ESMTPSA id xe9sm6735051pab.0.2013.07.29.16.42.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Jul 2013 16:42:32 -0700 (PDT) Message-ID: <51F6FDE9.7060608@gmail.com> Date: Tue, 30 Jul 2013 11:42:33 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Andrew Sullivan References: <20130729134623.GD51737@mx1.yitter.info> <51F674D0.3040603@viagenie.ca> <20130729143910.GB51823@mx1.yitter.info> <786F13AA11E69F4DB2CCA23F7400C2FB01477A83@S2010EXCH1.ad.local> <20130729231058.GB52180@mx1.yitter.info> In-Reply-To: <20130729231058.GB52180@mx1.yitter.info> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: behave@ietf.org Subject: Re: [BEHAVE] Fwd: I-D Action: draft-sun-behave-v4tov6-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 23:42:39 -0000 On 30/07/2013 11:10, Andrew Sullivan wrote: > Hi, > > On Mon, Jul 29, 2013 at 09:03:35PM +0000, Branimir Rajtar wrote: > >> First of all, I feel that there are a lot of people within the >> working group who wish this problem to be solved. > > I am aware of that. But, as the old saw goes around here, "I want a > pony." Merely wishing a problem to be solved is not enough to show > that it should be solved. Among other considerations, from the point > of view of the overall network, there is the question of whether that > solution imposes costs on the rest of the network. > > I argue that, in this case, the solution _does_ impose such costs. At > the very least, these documents need review, and the review distracts > people from doing other useful work. But also, building a system for > a v4-only host to cope with the address range of the entire IPv6 world > is unlikely to be without effects elsewhere. And once this sort of > sludge is deployed on the Internet, it is not in the future possible > to discount it. We live with it forever. (Look at the DNS. Or the > other issues that plain old NAT44 imposes.) > >> of work that was put into RFC6145, I believe you're trying to say >> that the work they did is worthless > > I am not. I also worked hard on some transition mechanisms, and while > I think DNS64 imposes a lot of costs and has many undesirable > properties, I still think it was the right thing to do. I was not > especially delighted with RFC 6145, but it seemed to me to be, on > balance, not an obviously bad solution to some problems people > actually had. It was a necessary component of making the NAT64/DNS64 chain work, to satisfy scenarios that BEHAVE was chartered to work on. I don't see why this is relevant to Andrew's argument that we should not invest effort in NAT46, which only serves to artificially prolong the life of IPv4-only. It's just the wrong place for the IETF and the whole industry to put millions of $$. Brian > >> - as I understand, you say that everybody should natively have v6 >> access and therefore translation is not needed. > > No. What I am saying is that anyone who in the future has only IPv4 > connectivity and needs to reach an IPv6 address will have basically > two choices: > > 1. Get an IPv6 address, and run dual stack. > > 2. Add a bunch of sludge to the system to attempt to map the > enormous IPv6 space into the much smaller IPv4 space. > > I can think of very few cases where the choice between these two > options demands even three nanoseconds of thought. (1) will work. > (2) will at the very least present a much worse experience than (1). > So what are the use cases for (2)? > > A. Can't get IPv6. But of course, with the various tunnel > systems (some of which are free), this isn't true of anyone > except people running incredibly inflexible systems. See > below. > > B. A device which is mission critical, too valuable to > replace, and too ill-maintained to upgrade. (These people > literally can't handle IPv6 addresses, and have no hope of > being able to do.) > > The problem here is that every case of (B) is too specialized for > there to be a useful generic system anyway. If your system is > _actually_ that creaky, then there is every reason to suppose that one > of the ways in which the v4/v6 translation mechanism doesn't work > perfectly is going to cause problems anyway. So in effect, every > real example of this is going to require a bespoke effort. > > Most of the cases of (B) I've heard offered are actually more like > this: > > C. I have a device which is valuable, and a lot of work for > me to upgrade, so I want to externalise those costs to the > network. > > To offer a parody, "I want a pony. Also, someone else has to buy it, > feed it, and groom it." And that's why I think we should not work on > this scenario. > > Best, > > A > From bingxuere@gmail.com Mon Jul 29 18:42:21 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B6CF11E817F for ; Mon, 29 Jul 2013 18:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 3KuhZ3UWIcIT for ; Mon, 29 Jul 2013 18:42:19 -0700 (PDT) Received: from mail-vb0-x22b.google.com (mail-vb0-x22b.google.com [IPv6:2607:f8b0:400c:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 7C51F21F9B25 for ; Mon, 29 Jul 2013 18:42:19 -0700 (PDT) Received: by mail-vb0-f43.google.com with SMTP id h11so2435592vbh.30 for ; Mon, 29 Jul 2013 18:42:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=UkT0dC/XerD3TGxrq6T71SkvQehtK7bzqdKDo2/Kfoc=; b=DPb17kF90TzRTjGJ/5c8b7dhgqOptHRL1yyQdwQv3b854aclAvOi9H0BPKn2CnsboH fmtAU4ZmMPl4DGILhdIoIufp16wgx/UkLNfB1b9EParN0LxS829o2t5YFZr5tuwKxEG/ z5CaAMr3V/AjW8OVPcg+pLPvmQp1zXaq1osWiXXQxLOCPrgd7SZTSvzgEGJISrsHUhfq O6KSl3ZXGDblkEHSOCf0iVSCYYpTZgO63eh6wmZOPlZmbUlOvL3T0PFg2yWOpfvidsDe tdPBeBsrbPE3QvarmSLw+0Iy0oYNkknSg8Z2sTV7utWkNRggM3P+55FU3ee0RLdvfmXi 50JA== X-Received: by 10.220.123.195 with SMTP id q3mr9253963vcr.64.1375148538870; Mon, 29 Jul 2013 18:42:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.187.66 with HTTP; Mon, 29 Jul 2013 18:41:38 -0700 (PDT) In-Reply-To: References: From: Qiong Date: Tue, 30 Jul 2013 09:41:38 +0800 Message-ID: To: Liu Dapeng Content-Type: multipart/alternative; boundary=089e013cb7282c425d04e2b0b8fa Cc: "behave@ietf.org" Subject: Re: [BEHAVE] Fwd: I-D Action: draft-sun-behave-v4tov6-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 01:42:21 -0000 --089e013cb7282c425d04e2b0b8fa Content-Type: text/plain; charset=UTF-8 Hi Dapeng, Thanks for your reply. See some comments inline. On Mon, Jul 29, 2013 at 10:00 PM, Liu Dapeng wrote: > Hi Qiong, > > Thanks for the clarification. Configuring static mapping in DNS requires > the operator has control of both the authoritative DNS server and the > translator. > [Qiong] Operator may tell the ICP which IPv4 address can be used, and the ICP can configure it as A record in the authoritative DNS server. > That could be possible in data center scenario but for large scale > deployment, I am afraid that the dynamic mapping still would be needed? > [Qiong] Yes, I agree. For larger scale deployment (e.g. IPv4 Internet to IPv6 Internet), I think it is not possible to use static mapping. Best wishes Qiong > > Regards, > Dapeng Liu > > > 2013/7/29 Qiong > >> Hi Dapeng, >> >> Thanks for pointing out. I think the major difference is that we use >> static mapping while draft-liu-behave-nat46 uses dynamic mapping. That's >> why we do not need to embed DNS46 in the translator. >> >> Best wishes >> Qiong >> >> >> On Mon, Jul 29, 2013 at 8:25 PM, Liu Dapeng wrote: >> >>> Hi Qiong: >>> >>> I am wondering whether you are aware of that NAT46 has been discussed >>> three years ago in Behave. For example >>> http://tools.ietf.org/html/draft-liu-behave-nat46-02 have proposed a >>> solution for NAT46. Maybe you could leverage on that. >>> >>> Dapeng Liu >>> >>> >>> 2013/7/9 Qiong >>> >>>> Dear all, >>>> >>>> We have submitted a new draft for IPv4 client to IPv6 server. It is >>>> designed to cover the Scenario 2 in RFC6144. It can save the public >>>> IPv4 addresses consumed by IPv6 side and does not have impact on existing >>>> applications. >>>> >>>> Your comments/reviews are appreciated. >>>> >>>> Best wishes >>>> Qiong >>>> >>>> >>>> ---------- Forwarded message ---------- >>>> From: internet-drafts@ietf.org >>>> Date: Mon, 08 Jul 2013 08:16:36 -0700 >>>> Subject: I-D Action: draft-sun-behave-v4tov6-00.txt >>>> To: i-d-announce@ietf.org >>>> >>>> A new version of I-D, draft-sun-behave-v4tov6-00.txt >>>> has been successfully submitted by Chongfeng Xie and posted to the >>>> IETF repository. >>>> >>>> Filename: draft-sun-behave-v4tov6 >>>> Revision: 00 >>>> Title: The Approach for IPv4-only users to access IPv6-only Content >>>> Creation date: 2013-07-08 >>>> Group: Individual Submission >>>> Number of pages: 13 >>>> URL: http://www.ietf.org/internet-drafts/draft-sun-behave-v4tov6-00.txt >>>> Status: http://datatracker.ietf.org/doc/draft-sun-behave-v4tov6 >>>> Htmlized: http://tools.ietf.org/html/draft-sun-behave-v4tov6-00 >>>> >>>> >>>> Abstract: >>>> Current approaches can not solve the scenario that the users from >>>> IPv4 Internet to access IPv6-only content. When IPv6 content are >>>> becoming more and more popular, it is important to ensure that IPv6- >>>> only content can be reachable from legacy IPv4-only clients via some >>>> IPv4-only network. This document proposes two approaches for IPv4- >>>> only users to access IPv6-only content. It is designed to cover the >>>> Scenario 2 in [RFC6144]. >>>> >>>> >>>> >>>> >>>> >>>> The IETF Secretariat >>>> >>>> -- >>>> ============================================== >>>> Qiong Sun >>>> China Telecom Beijing Research Institute >>>> >>>> >>>> Open source code: >>>> lightweight 4over6: *http://sourceforge.net/projects/laft6/* >>>> PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * >>>> =============================================== >>>> >>>> >>>> _______________________________________________ >>>> Behave mailing list >>>> Behave@ietf.org >>>> https://www.ietf.org/mailman/listinfo/behave >>>> >>>> >>> >>> >>> -- >>> >>> ------ >>> Best Regards, >>> Dapeng Liu >>> >> >> >> >> -- >> ============================================== >> Qiong Sun >> China Telecom Beijing Research Institude >> >> >> >> Open source code: >> lightweight 4over6: *http://sourceforge.net/projects/laft6/* >> PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * >> =============================================== >> >> > > > -- > > ------ > Best Regards, > Dapeng Liu > -- ============================================== Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/* PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * =============================================== --089e013cb7282c425d04e2b0b8fa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Dapeng,

Thanks for your r= eply. See some comments inline.=C2=A0

On = Mon, Jul 29, 2013 at 10:00 PM, Liu Dapeng <maxpassion@gmail.com>= wrote:
Hi Qiong,

Thanks for the clarification. Configuring static mapping in DNS requires = the operator has control of both the=C2=A0authoritative DNS server and the = translator.
[Qiong] Operator may tell the ICP which IPv4 = address can be used, and the ICP can configure it as A record in the author= itative DNS server.=C2=A0
That could be possible in data center scenario but fo= r large scale deployment, I am=C2=A0afraid that the dynamic mapping still w= ould be needed?
[Qiong] Yes, I agree. Fo= r larger scale deployment (e.g. IPv4 Internet to IPv6 Internet), I think it= is not possible to use static mapping.

Best wishes
Qiong

Regards,
Dapeng Liu=C2=A0


2013/7/29 Qiong <bingxuere@gmail.com>
Hi Dapeng,

Thanks for pointing out. I think the major difference is that we use sta= tic mapping while draft-liu-behave-nat46 uses dynamic mapping. That's w= hy we do not need to embed DNS46 in the translator.

Best wishes
Qiong


On Mon, Jul 29, 201= 3 at 8:25 PM, Liu Dapeng <maxpassion@gmail.com> wrote:
Hi Qiong:

I am wondering whether you are aware of that NAT46 has been discussed thr= ee years ago in Behave. For example http://tools.ietf.org/html/draf= t-liu-behave-nat46-02 have proposed a solution for NAT46. Maybe you cou= ld leverage on that.

Dapeng Liu

2013/7/9 Qiong <bingxuere@gmail.com&g= t;
Dear all,

We have submitted a new draft for IPv4 client to IPv6 server. It is desi= gned to cover the Scenario=C2=A02= =C2=A0in RFC6144. It can save the public IPv4 addresses consumed by IPv6 si= de and does not have impact on existing applications.

Your comments/reviews are appreciated.

Best wishes
Qiong


---------- Forwarded message ----------
From:=C2=A0internet-drafts@ietf.org Date: Mon, 08 J= ul 2013 08:16:36 -0700
Sub= ject: I-D Action:=C2=A0draft-sun-be= have-v4tov6-00.txt
To:=C2=A0i-d-announce@ietf.org

A=C2=A0new=C2=A0version=C2=A0of=C2=A0I-D,=C2=A0dr= aft-sun-behave-v4tov6-00.txt
has=C2=A0been=C2=A0successfully=C2=A0submitted=C2=A0by=C2=A0Chongfeng= =C2=A0Xie=C2=A0and=C2=A0posted=C2=A0to=C2=A0the
IETF=C2=A0repository.
=C2=A0
Filename: =C2=A0draft-sun-behave-v4tov6
Revision: =C2=A000
Title: =C2=A0The=C2=A0Approach=C2=A0for=C2=A0IPv4-only=C2=A0users=C2= =A0to=C2=A0access=C2=A0IPv6-only=C2=A0Content
Creation=C2=A0date: =C2=A02013-07-08
Group: =C2=A0Individual=C2=A0Submission
Number=C2=A0of=C2=A0pages:=C2=A013
=C2=A0
=C2=A0
Abstract:
=C2=A0=C2=A0=C2=A0Current=C2=A0approaches=C2=A0can=C2=A0not=C2=A0solve= =C2=A0the=C2=A0scenario=C2=A0that=C2=A0the=C2=A0users=C2=A0from
=C2=A0=C2=A0=C2=A0IPv4=C2=A0Internet=C2=A0to=C2=A0access=C2=A0IPv6-onl= y=C2=A0content.=C2=A0=C2=A0When=C2=A0IPv6=C2=A0content=C2=A0are
=C2=A0=C2=A0=C2=A0becoming=C2=A0more=C2=A0and=C2=A0more=C2=A0popular,= =C2=A0it=C2=A0is=C2=A0important=C2=A0to=C2=A0ensure=C2=A0that=C2=A0IPv6-
=C2=A0=C2=A0=C2=A0only=C2=A0content=C2=A0can=C2=A0be=C2=A0reachable=C2= =A0from=C2=A0legacy=C2=A0IPv4-only=C2=A0clients=C2=A0via=C2=A0some
=C2=A0=C2=A0=C2=A0IPv4-only=C2=A0network.=C2=A0=C2=A0This=C2=A0documen= t=C2=A0proposes=C2=A0two=C2=A0approaches=C2=A0for=C2=A0IPv4-
=C2=A0=C2=A0=C2=A0only=C2=A0users=C2=A0to=C2=A0access=C2=A0IPv6-only= =C2=A0content.=C2=A0=C2=A0It=C2=A0is=C2=A0designed=C2=A0to=C2=A0cover=C2=A0= the
=C2=A0=C2=A0=C2=A0Scenario=C2=A02=C2=A0in=C2=A0[RFC6144].
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
=C2=A0
=C2=A0
The=C2=A0IETF=C2=A0Secretariat

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


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

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




--

------
Best Regards,
Dapeng Liu



--
=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Qiong Sun
<= /div>China Telecom Beijing Research Institude



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



--

------Best Regards,
Dapeng Liu



--
= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Qiong Su= n
China Telecom Beijing Research Institude


Open source code:<= br>lightweight 4over6: http://sourceforge.net/projects/laft6/
PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--089e013cb7282c425d04e2b0b8fa-- From bingxuere@gmail.com Mon Jul 29 19:18:26 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1BD321F9DC9 for ; Mon, 29 Jul 2013 19:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 WXS20uIzI1z6 for ; Mon, 29 Jul 2013 19:18:26 -0700 (PDT) Received: from mail-vc0-x22d.google.com (mail-vc0-x22d.google.com [IPv6:2607:f8b0:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id D7B1621F9DC6 for ; Mon, 29 Jul 2013 19:18:25 -0700 (PDT) Received: by mail-vc0-f173.google.com with SMTP id id13so2657621vcb.32 for ; Mon, 29 Jul 2013 19:18:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=A4PemxsFY6tocszzErSllx307RWnHEy2MjIAZHHvtOs=; b=TD+hdN15HtJFpe7vOkikUU4TN11t5pulYSZvXlJPZP9UEKsQelvw8X0rRFSP33SXk0 u8IPq4EWDRXSlVEWUN4UWP3RiR9kOiZERte5omVErdIyhsbwBWZyLo4NkTF1yytVWsMV VYlcAIQ1gJsfijPiepeo715xW5HgjtAYlES6rTdC14t04/JOUMIpJgTdMechwAIimBN9 Sz9Iau+T6JiNTeg2MsWZOO1Aj8DYDBzir0zhkz1WozfgdvP02SoIr/J1TEjv35qj3ebE gKw+daHhmaSxfMKqEhV2gFh7cbjmEdZPk6XWl0xzP2T/EG4ePt14hvW/XvoR0ExFNyj+ 48GQ== X-Received: by 10.58.211.7 with SMTP id my7mr26537390vec.54.1375150705145; Mon, 29 Jul 2013 19:18:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.187.66 with HTTP; Mon, 29 Jul 2013 19:17:45 -0700 (PDT) In-Reply-To: References: From: Qiong Date: Tue, 30 Jul 2013 10:17:45 +0800 Message-ID: To: Satoru Matsushima Content-Type: multipart/alternative; boundary=047d7bd6b2b24afeea04e2b13931 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] I-D Action: draft-sun-behave-v4tov6-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 02:18:26 -0000 --047d7bd6b2b24afeea04e2b13931 Content-Type: text/plain; charset=UTF-8 Hi Satoru, Thanks for sharing this interesting viewpoint. I tend to agree with you that we both use static mapping and address sharing. But there are some different features for server-side and client-side. Our initial idea is to built on RFC6145, and do not want to embed particular bits into IPv6 prefix. We may explore it more from this perspective :) Thanks a lot! Best wishes Qiong On Mon, Jul 29, 2013 at 10:12 PM, Satoru Matsushima < satoru.matsushima@gmail.com> wrote: > Hi Qiong, > > Thanks for the interesting draft. > Just one comment on the mapping table described in the draft. > What I though is that it seems that the mapping table is very similar with > FMR on MAP-T CE. (I believe you can share my thought. ;) > Both two approach mentioned in the draft would be trigger to register FMR > dynamically into MAP-T CE as NAT46 device. > > Hope it helps > --satoru > > > On 2013/07/09, at 16:17, Qiong wrote: > > > Dear all, > > > > We have submitted a new draft for IPv4 client to IPv6 server. It is > designed to cover the Scenario 2 in RFC6144. It can save the public IPv4 > addresses consumed by IPv6 side and does not have impact on existing > applications. > > > > Your comments/reviews are appreciated. > > > > Best wishes > > Qiong > > > > > > ---------- Forwarded message ---------- > > From: internet-drafts@ietf.org > > Date: Mon, 08 Jul 2013 08:16:36 -0700 > > Subject: I-D Action: draft-sun-behave-v4tov6-00.txt > > To: i-d-announce@ietf.org > > > > A new version of I-D, draft-sun-behave-v4tov6-00.txt > > has been successfully submitted by Chongfeng Xie and posted to the > > IETF repository. > > > > Filename: draft-sun-behave-v4tov6 > > Revision: 00 > > Title: The Approach for IPv4-only users to access IPv6-only Content > > Creation date: 2013-07-08 > > Group: Individual Submission > > Number of pages: 13 > > URL: http://www.ietf.org/internet-drafts/draft-sun-behave-v4tov6-00.txt > > Status: http://datatracker.ietf.org/doc/draft-sun-behave-v4tov6 > > Htmlized: http://tools.ietf.org/html/draft-sun-behave-v4tov6-00 > > > > > > Abstract: > > Current approaches can not solve the scenario that the users from > > IPv4 Internet to access IPv6-only content. When IPv6 content are > > becoming more and more popular, it is important to ensure that IPv6- > > only content can be reachable from legacy IPv4-only clients via some > > IPv4-only network. This document proposes two approaches for IPv4- > > only users to access IPv6-only content. It is designed to cover the > > Scenario 2 in [RFC6144]. > > > > > > > > > > The IETF Secretariat > > > > -- > > ============================================== > > Qiong Sun > > China Telecom Beijing Research Institute > > > > > > Open source code: > > lightweight 4over6: http://sourceforge.net/projects/laft6/ > > PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/ > > =============================================== > > > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave > > -- ============================================== Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/* PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * =============================================== --047d7bd6b2b24afeea04e2b13931 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Satoru,

Thanks for sharing thi= s interesting viewpoint. I tend to agree with you that we both use static m= apping and address sharing.=C2=A0But there are some different features for = server-side and client-side.=C2=A0Our initial idea is to built on RFC6145, = and do not want to embed particular bits into IPv6 prefix. We may explore i= t more from this perspective :)

Thanks a lot!

Best wishes
Qiong

=C2=A0


On Mon, Jul 29, 2013 at 10:12 PM, Satoru Matsushima <<= a href=3D"mailto:satoru.matsushima@gmail.com" target=3D"_blank">satoru.mats= ushima@gmail.com> wrote:
Hi Qiong,

Thanks for the interesting draft.
Just one comment on the mapping table described in the draft.
What I though is that it seems that the mapping table is very similar with = FMR on MAP-T CE. (I believe you can share my thought. ;)
Both two approach mentioned in the draft would be trigger to register FMR d= ynamically into MAP-T CE as NAT46 device.

Hope it helps
--satoru


On 2013/07/09, at 16:17, Qiong <b= ingxuere@gmail.com> wrote:

> Dear all,
>
> We have submitted a new draft for IPv4 client to IPv6 server. It is de= signed to cover the Scenario 2 in RFC6144. It can save the public IPv4 addr= esses consumed by IPv6 side and does not have impact on existing applicatio= ns.
>
> Your comments/reviews are appreciated.
>
> Best wishes
> Qiong
>
>
> ---------- Forwarded message ----------
> From: internet-drafts@ietf= .org
> Date: Mon, 08 Jul 2013 08:16:36 -0700
> Subject: I-D Action: draft-sun-behave-v4tov6-00.txt
> To: i-d-announce@ietf.org=
>
> A new version of I-D, draft-sun-behave-v4tov6-00.txt
> has been successfully submitted by Chongfeng Xie and posted to the
> IETF repository.
>
> Filename: =C2=A0draft-sun-behave-v4tov6
> Revision: =C2=A000
> Title: =C2=A0The Approach for IPv4-only users to access IPv6-only Cont= ent
> Creation date: =C2=A02013-07-08
> Group: =C2=A0Individual Submission
> Number of pages: 13
> URL: http://www.ietf.org/internet-drafts/draft-s= un-behave-v4tov6-00.txt
> Status: http://datatracker.ietf.org/doc/draft-sun-behave-v4= tov6
> Htmlized: http://tools.ietf.org/html/draft-sun-behave-v4tov6-= 00
>
>
> Abstract:
> =C2=A0 =C2=A0Current approaches can not solve the scenario that the us= ers from
> =C2=A0 =C2=A0IPv4 Internet to access IPv6-only content. =C2=A0When IPv= 6 content are
> =C2=A0 =C2=A0becoming more and more popular, it is important to ensure= that IPv6-
> =C2=A0 =C2=A0only content can be reachable from legacy IPv4-only clien= ts via some
> =C2=A0 =C2=A0IPv4-only network. =C2=A0This document proposes two appro= aches for IPv4-
> =C2=A0 =C2=A0only users to access IPv6-only content. =C2=A0It is desig= ned to cover the
> =C2=A0 =C2=A0Scenario 2 in [RFC6144].
>
>
>
>
> The IETF Secretariat
>
> --
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> Qiong Sun
> China Telecom Beijing Research Institute
>
>
> Open source code:
> lightweight 4over6: http://sourceforge.net/projects/laft6/
> PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/ > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >
> __________________= _____________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave




--
= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Qiong Su= n
China Telecom Beijing Research Institude


Open source code:<= br>lightweight 4over6: http://sourceforge.net/projects/laft6/
PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--047d7bd6b2b24afeea04e2b13931-- From bingxuere@gmail.com Mon Jul 29 19:56:24 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3121D11E81AB for ; Mon, 29 Jul 2013 19:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 WRdC9kH6FUo3 for ; Mon, 29 Jul 2013 19:56:23 -0700 (PDT) Received: from mail-ve0-x235.google.com (mail-ve0-x235.google.com [IPv6:2607:f8b0:400c:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id EE6F711E81A9 for ; Mon, 29 Jul 2013 19:56:22 -0700 (PDT) Received: by mail-ve0-f181.google.com with SMTP id jz10so3571217veb.12 for ; Mon, 29 Jul 2013 19:56:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=GAKiBxtUeg7cmPArnHj/cXshTh+/yKZ5fAYdfzu6fKI=; b=lL880wTZJyQqxN4fTIojnu91uaw8LcExyNLj0EF4HBKr75bSPkC5aG8cfCID4d7Fqp uquMX2GTHdfqDJY4bZ/y7DMB+XiQy5CNA4qKtPLU7oA0w3oeGoG2KofrZnA7M7tXMzpJ J5e9hydd7YMnMu7f+xfbvKxzGJMrWDhG67wNJkOvD/jRo7LoCPX6vP0uWiLY/cPQpQHY zdmhsKcpalIox6ikh/61WDmbDZzPk/sOsUBz111DfxPB7GONxVEL7zXCFjV60PjWT8sL Q6sGfpYxZlTEsjChE9rYI/Q9FfSfkVEYIXt2SFxoxawHzO8Wppj+CWYY0i5Tsi5CB5mV 7KHg== X-Received: by 10.220.123.195 with SMTP id q3mr9319197vcr.64.1375152982253; Mon, 29 Jul 2013 19:56:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.187.66 with HTTP; Mon, 29 Jul 2013 19:55:42 -0700 (PDT) In-Reply-To: <20130729143910.GB51823@mx1.yitter.info> References: <20130729134623.GD51737@mx1.yitter.info> <51F674D0.3040603@viagenie.ca> <20130729143910.GB51823@mx1.yitter.info> From: Qiong Date: Tue, 30 Jul 2013 10:55:42 +0800 Message-ID: To: Andrew Sullivan Content-Type: multipart/alternative; boundary=089e013cb72804e7e604e2b1c18e Cc: "behave@ietf.org" Subject: Re: [BEHAVE] Fwd: I-D Action: draft-sun-behave-v4tov6-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 02:56:24 -0000 --089e013cb72804e7e604e2b1c18e Content-Type: text/plain; charset=UTF-8 Hi Andrew, I have to disagree with you. See my comments inline. On Mon, Jul 29, 2013 at 10:39 PM, Andrew Sullivan wrote: > On Mon, Jul 29, 2013 at 03:57:36PM +0200, Simon Perreault wrote: > > >I suggest that it is a problem we do _not_ want to solve. It keeps > > >v4-only nodes alive longer. That's not a goal I share. > > > > By that logic, dual stack servers should move to v6-only. > > I don't see why. Dual-stack servers need no new work to make them > function. As near as I can tell, dual stack works just fine today. > [Qiong] I guess this is a question for sunset4. If everything remains dual-stack, then there will be no _sunset 4_. I think it is important to solve v6-only problem, both for v6-only client and v6-only server. We are still in the chicken-and-egg circle. Breaking one part does not mean the other part will live in v4 forever, but rather, it will help the v6 part to gain the confidence for further development. For example, we now have NAT64 and so v6-only client can emerge and talk to v4 server. So v6-only clients may be more and more in the future. I see nobody argues that if we have NAT64, v4 server may live in v4 forever. Then for v4-to-v6 scenario, this is the same since it will bring the ability to support v6-only server to be reachable by v4-only clients. Therefore, v6-only server may emerge because they do not need to worry about losing v4 clients. So v6-only server maybe more and more in the future. This will promote v6-development, rather than the opposite one. > The IETF has finite intellectual resources, and I claim that it is > wasteful to spend some of those on the problem of initiating > connections from a v4 network towards a v6 network. Anyone who has a > v4 address today ought to be able to get a v6 address too. [Qiong] From the long history of IPv6 development, I think it is clear this assumption has never hardly existed. If anyone *ought to be able to get a v6 address*, we would have reached the v6-world long ago, rather than debating how to transit. Best wishes Qiong > So they > _could_ all operate dual stack, and should have no trouble getting to > v6-only nodes. If there are nodes that are so incapable that they > just can't have a v6 stack at all, I am not convinced that we should > standardize a protocol to make that problem better. The best we're > ever going to come up with is a kludge, and for such systems any kluge > will probably do, so the uninteroperatable kludges that are already > commercially available are probably good enough for such cases. > > Way back when we had the v4/v6 co-existence interim in Montreal, we > were urged to pick the cases that we were going to solve, and we have > since then been busy filling in all the other boxes in the space no > matter whether the work makes anything better. V4-to-v6 NATs, in my > opinion, fall into the "make things worse" bucket, and I therefore > argue that such things should not be standardized. They're at best > temporary hacks, and they're never going to be good anyway. Just Say > No. > > Best, > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > -- ============================================== Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/* PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * =============================================== --089e013cb72804e7e604e2b1c18e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Andrew,

I have to dis= agree with you. See my comments inline.

O= n Mon, Jul 29, 2013 at 10:39 PM, Andrew Sullivan <ajs@anvilwalrusden.= com> wrote:
On Mon, Jul 29, 2013 at 03:57:36PM +0200= , Simon Perreault wrote:
> >I suggest that it is a problem we do _not_ want to solve. =C2=A0It= keeps
> >v4-only nodes alive longer. =C2=A0That's not a goal I share. >
> By that logic, dual stack servers should move to v6-only.

I don't see why. =C2=A0Dual-stack servers need no new work to mak= e them
function. =C2=A0As near as I can tell, dual stack works just fine today.
[Qiong] I guess this is a question for sunset4. If= everything remains dual-stack, then there will be no _sunset 4_.=C2=A0

I think it is important to solve v6-only problem, both= for v6-only client and v6-only server. We are still in the chicken-and-egg= circle. Breaking one part does not mean the other part will live in v4 for= ever, but rather, it will help the v6 part to gain the confidence for furth= er development. For example, we now have NAT64 and so v6-only client can em= erge and talk to v4 server. So v6-only clients may be more and more in the = future. I see nobody argues that if we have NAT64, v4 server may live in v4= forever.

Then for v4-to-v6 scenario, this is the sam= e since it will bring the ability to support v6-only server to be reachable= by v4-only clients. Therefore, v6-only server may emerge because they do n= ot need to worry about losing v4 clients. So v6-only server maybe more and = more in the future. This will promote v6-development, rather than the oppos= ite one.
=C2=A0
The IETF has finite intellectual resources, and I claim that it is
wasteful to spend some of those on the problem of initiating
connections from a v4 network towards a v6 network. =C2=A0Anyone who has a<= br> v4 address today ought to be able to get a v6 address too. =C2=A0
[Qiong] From the long history of IPv6 development, I think it= is clear this assumption has never hardly existed. If anyone *ought to be = able to get a v6 address*, we would have reached the v6-world long ago, rat= her than debating how to transit.=C2=A0

Best wishes
Qiong
=C2=A0
So they
_could_ all operate dual stack, and should have no trouble getting to
v6-only nodes. =C2=A0If there are nodes that are so incapable that they
just can't have a v6 stack at all, I am not convinced that we should standardize a protocol to make that problem better. =C2=A0The best we'r= e
ever going to come up with is a kludge, and for such systems any kluge
will probably do, so the uninteroperatable kludges that are already
commercially available are probably good enough for such cases.

Way back when we had the v4/v6 co-existence interim in Montreal, we
were urged to pick the cases that we were going to solve, and we have
since then been busy filling in all the other boxes in the space no
matter whether the work makes anything better. =C2=A0V4-to-v6 NATs, in my opinion, fall into the "make things worse" bucket, and I therefor= e
argue that such things should not be standardized. =C2=A0They're at bes= t
temporary hacks, and they're never going to be good anyway. =C2=A0Just = Say
No.

Best,

A

--
Andrew Sullivan
ajs@anvilwalrusden.com
___________________________________= ____________
Behave mailing list
Behave@ietf.org
= https://www.ietf.org/mailman/listinfo/behave



--
= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Qiong Su= n
China Telecom Beijing Research Institude


Open source code:<= br>lightweight 4over6: http://sourceforge.net/projects/laft6/
PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--089e013cb72804e7e604e2b1c18e-- From bingxuere@gmail.com Mon Jul 29 20:11:42 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26B1121F9C9A for ; Mon, 29 Jul 2013 20:11:42 -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.149, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 znbAIRNdDibu for ; Mon, 29 Jul 2013 20:11:41 -0700 (PDT) Received: from mail-vb0-x232.google.com (mail-vb0-x232.google.com [IPv6:2607:f8b0:400c:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 30C9F21F9C99 for ; Mon, 29 Jul 2013 20:11:41 -0700 (PDT) Received: by mail-vb0-f50.google.com with SMTP id x13so3022318vbb.9 for ; Mon, 29 Jul 2013 20:11:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=rmniPlmTaZp0DXJihj4sE77CQ3kDsmxJeup1JhlgGD4=; b=aINesVmVz0P2l18TTvM7t8yaNxIogzjYrJAoEJXZEZnwTIGgi+GD7hlFx6pWkCtItY DL+d8HJ2Er3BsqKfLG6l+d0boHesSIehlfU+2Ml+nrFa2AG9JHOLrbgELEfYXvwuznsk zBLEqv2cCsohOVPIwfsxmd0gXhTa4CJjGMmPzL2JNSJS/74j/Oz1iXcsmAivHxLU1HU/ uwGdUYY1wUU+9uPatzzLldh6S8ZfaTKiQ9HXiw7iqJP7x105zmquN8+QgO+e485wBN1W KQrNe8zh61dyA8c9yoP/3X/bqg909diT1OmmAcipytAqbb6FQBC+yGUBqq0Ivs1V84By Sbvg== X-Received: by 10.58.211.7 with SMTP id my7mr26584445vec.54.1375153900690; Mon, 29 Jul 2013 20:11:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.187.66 with HTTP; Mon, 29 Jul 2013 20:11:00 -0700 (PDT) In-Reply-To: <20130729231058.GB52180@mx1.yitter.info> References: <20130729134623.GD51737@mx1.yitter.info> <51F674D0.3040603@viagenie.ca> <20130729143910.GB51823@mx1.yitter.info> <786F13AA11E69F4DB2CCA23F7400C2FB01477A83@S2010EXCH1.ad.local> <20130729231058.GB52180@mx1.yitter.info> From: Qiong Date: Tue, 30 Jul 2013 11:11:00 +0800 Message-ID: To: Andrew Sullivan Content-Type: multipart/alternative; boundary=047d7bd6b2b2c3238104e2b1f71d Cc: "behave@ietf.org" Subject: Re: [BEHAVE] Fwd: I-D Action: draft-sun-behave-v4tov6-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 03:11:42 -0000 --047d7bd6b2b2c3238104e2b1f71d Content-Type: text/plain; charset=UTF-8 Hi Andrew, On Tue, Jul 30, 2013 at 7:10 AM, Andrew Sullivan wrote: > > > - as I understand, you say that everybody should natively have v6 > > access and therefore translation is not needed. > > No. What I am saying is that anyone who in the future has only IPv4 > connectivity and needs to reach an IPv6 address will have basically > two choices: > [Qiong] How many years do you mean by *the future*, when all the IPv4 clients will have the ability to get an IPv6 address ? We hope to solve the problem sooner, not 10 years or 20 years later, so that IPv6 would come sooner. Best wishes Qiong > 1. Get an IPv6 address, and run dual stack. > > 2. Add a bunch of sludge to the system to attempt to map the > enormous IPv6 space into the much smaller IPv4 space. > > I can think of very few cases where the choice between these two > options demands even three nanoseconds of thought. (1) will work. > (2) will at the very least present a much worse experience than (1). > So what are the use cases for (2)? > > A. Can't get IPv6. But of course, with the various tunnel > systems (some of which are free), this isn't true of anyone > except people running incredibly inflexible systems. See > below. > > B. A device which is mission critical, too valuable to > replace, and too ill-maintained to upgrade. (These people > literally can't handle IPv6 addresses, and have no hope of > being able to do.) > > The problem here is that every case of (B) is too specialized for > there to be a useful generic system anyway. If your system is > _actually_ that creaky, then there is every reason to suppose that one > of the ways in which the v4/v6 translation mechanism doesn't work > perfectly is going to cause problems anyway. So in effect, every > real example of this is going to require a bespoke effort. > > Most of the cases of (B) I've heard offered are actually more like > this: > > C. I have a device which is valuable, and a lot of work for > me to upgrade, so I want to externalise those costs to the > network. > > To offer a parody, "I want a pony. Also, someone else has to buy it, > feed it, and groom it." And that's why I think we should not work on > this scenario. > > Best, > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > -- ============================================== Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/* PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * =============================================== --047d7bd6b2b2c3238104e2b1f71d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Andrew,


On Tue, Jul 30, 2013 at 7:10 AM, Andrew Sullivan <ajs@a= nvilwalrusden.com> wrote:

> - as I understand, you say that everybody should natively have v6
> access and therefore translation is not needed.

No. =C2=A0What I am saying is that anyone who in the future has only = IPv4
connectivity and needs to reach an IPv6 address will have basically
two choices:
[Qiong] How many years do you mean = by *the future*, when all the IPv4 clients will have the ability to get an = IPv6 address ? =C2=A0We hope to solve the problem sooner, not 10 years or 2= 0 years later, so that IPv6 would come sooner. =C2=A0

Best wishes
Qiong


=C2=A0 =C2=A0 =C2=A0 =C2=A0 1. =C2=A0Get an IPv6 address, and run dual stac= k.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 2. =C2=A0Add a bunch of sludge to the system to= attempt to map the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 enormous IPv6 space into the much smaller IPv4 = space.

I can think of very few cases where the choice between these two
options demands even three nanoseconds of thought. =C2=A0(1) will work.
(2) will at the very least present a much worse experience than (1).
So what are the use cases for (2)?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 A. =C2=A0Can't get IPv6. =C2=A0But of cours= e, with the various tunnel
=C2=A0 =C2=A0 =C2=A0 =C2=A0 systems (some of which are free), this isn'= t true of anyone
=C2=A0 =C2=A0 =C2=A0 =C2=A0 except people running incredibly inflexible sys= tems. =C2=A0See
=C2=A0 =C2=A0 =C2=A0 =C2=A0 below.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 B. =C2=A0A device which is mission critical, to= o valuable to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 replace, and too ill-maintained to upgrade. =C2= =A0(These people
=C2=A0 =C2=A0 =C2=A0 =C2=A0 literally can't handle IPv6 addresses, and = have no hope of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 being able to do.)

The problem here is that every case of (B) is too specialized for
there to be a useful generic system anyway. =C2=A0If your system is
_actually_ that creaky, then there is every reason to suppose that one
of the ways in which the v4/v6 translation mechanism doesn't work
perfectly is going to cause problems anyway. =C2=A0So in effect, every
real example of this is going to require a bespoke effort.

Most of the cases of (B) I've heard offered are actually more like
this:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 C. =C2=A0I have a device which is valuable, and= a lot of work for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 me to upgrade, so I want to externalise those c= osts to the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 network.

To offer a parody, "I want a pony. =C2=A0Also, someone else has to buy= it,
feed it, and groom it." =C2=A0And that's why I think we should not= work on
this scenario.

Best,

A

--
Andrew Sullivan
ajs@anvilwalrusden.com
_______________________________________________
Behave mailing list
Behave@ietf.org
= https://www.ietf.org/mailman/listinfo/behave



--
= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Qiong Su= n
China Telecom Beijing Research Institude


Open source code:<= br>lightweight 4over6: http://sourceforge.net/projects/laft6/
PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--047d7bd6b2b2c3238104e2b1f71d-- From bingxuere@gmail.com Mon Jul 29 20:16:44 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6177911E81AC for ; Mon, 29 Jul 2013 20:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 wKjQa3uByZ3Y for ; Mon, 29 Jul 2013 20:16:43 -0700 (PDT) Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [IPv6:2607:f8b0:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 64ED411E81A9 for ; Mon, 29 Jul 2013 20:16:43 -0700 (PDT) Received: by mail-vc0-f169.google.com with SMTP id ib11so2722434vcb.0 for ; Mon, 29 Jul 2013 20:16: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:from:date:message-id:subject:to :cc:content-type; bh=UyXygcIM4k+zoar3L0dVtF+HYB96yijlyTinJFgtWiU=; b=wZjVKnMaMfz/B1ZgdkrM1S5wWcuUjzvzYKkvg4LENSA4zQYKVAVCGJZz/Ejfux7gmv cOjpsIMyIQ1O+ry5G81ujlyg0AZ4HQmKQi9o2wW+OLXg0WPDiUJ/g9cUY1QY/6uZoZWq VlsQP1m1DMEMxWT1xZYyoMNj+WuR9jUaRefQJHm2uQudgILZWOOTnfeUvkFMBvYcrd4l Q1kqWmVTOnD6Cpm4XLTfCk1lCSqhBuneg5ApYABlx8hE5eBOrEX5LiGcajwTwtrgFm7J yhHRhMg0IzQrud+TTGiNkEhCuhclnIk9zRHgBjTqvCzcRsgDwvgxGLOUBn3CwvrhgQ09 mJ1A== X-Received: by 10.52.185.101 with SMTP id fb5mr12965325vdc.1.1375154202830; Mon, 29 Jul 2013 20:16:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.187.66 with HTTP; Mon, 29 Jul 2013 20:16:02 -0700 (PDT) In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F0604090E84AA@xmb-rcd-x04.cisco.com> References: <45A697A8FFD7CF48BCF2BE7E106F0604090E84AA@xmb-rcd-x04.cisco.com> From: Qiong Date: Tue, 30 Jul 2013 11:16:02 +0800 Message-ID: To: "Reinaldo Penno (repenno)" Content-Type: multipart/alternative; boundary=bcaec548a6d3c56dd704e2b2099f Cc: "behave@ietf.org" Subject: Re: [BEHAVE] draft-meng-behave-napgt can be met by PCP port set X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 03:16:44 -0000 --bcaec548a6d3c56dd704e2b2099f Content-Type: text/plain; charset=UTF-8 Hi Reinaldo, Yes, I agree with you. This can be achieved by PCP port-set. Best wishes Qiong On Mon, Jul 29, 2013 at 9:33 PM, Reinaldo Penno (repenno) wrote: > After watching this presentation that generated some ML discussion, it > seems to me requirements can be fully met with PCP port set. > > Thanks, > > Reinaldo > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > -- ============================================== Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/* PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * =============================================== --bcaec548a6d3c56dd704e2b2099f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Reinaldo,

Yes= , I agree with you. This can be achieved by PCP port-set.
Best wishes
Qiong


On Mon, Jul 29, 2013 at 9:33 PM, Reinald= o Penno (repenno) <repenno@cisco.com> wrote:
After watching this presentation that generated some ML discussion, it= seems to me requirements can be fully met with PCP port set.

Thanks,

Reinaldo

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




--
=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Qiong Sun
C= hina Telecom Beijing Research Institude


Open source code:
lig= htweight 4over6: http://sourceforge.net/projects/laft6/
PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--bcaec548a6d3c56dd704e2b2099f-- From petithug@acm.org Mon Jul 29 21:37:06 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DC5011E81B9 for ; Mon, 29 Jul 2013 21:37: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=[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 QMm7uEEwp-yP for ; Mon, 29 Jul 2013 21:37:05 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 9AF6A11E81B7 for ; Mon, 29 Jul 2013 21:37:05 -0700 (PDT) Received: from [IPv6:2001:df8:0:64:ca0a:a9ff:fe2e:a4f6] (unknown [IPv6:2001:df8:0:64:ca0a:a9ff:fe2e:a4f6]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 33FC62021A for ; Tue, 30 Jul 2013 06:37:03 +0200 (CEST) Message-ID: <51F742F8.3070903@acm.org> Date: Tue, 30 Jul 2013 06:37:12 +0200 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130630 Icedove/17.0.7 MIME-Version: 1.0 To: "Behave@ietf.org" X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [BEHAVE] Comments on the TURN REST Server API presentation X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 04:37:06 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 About this presentation, I agree with what Martin Thomson said on the microphone (trying to paraphrase from memory as the audio recording is not available yet): There is no need to standardize a RESTful API because the server can send the username/password in the web page that uses rtcweb, or can use any proprietary API between the javascript client and the server. There is no interoperability issue here. Second, I do not think that trying to overload the long-term authentication mechanism is wise - and I take exceptions with the previous presentation that characterized long-term authentication as having problems. This is how long-term authentication works, and that should be left alone. IMO what is needed is to design a third authentication option for TURN (probably with new attributes) that is doing the username/password stateless verification. Here there is a need to define how the web server and the turn server can generate/verify the same username/password, so an I-D is required to ensure interoperability. Finally a small nit: In the presentation the wrong syntax was used for the turn uri: the parameter name is transport=, not proto=. Thanks. - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iQIcBAEBCAAGBQJR90LqAAoJECnERZXWan7EoiMP/R90khv1Ez+2652uCRIBjNhS JyGpoNNVsqaPFPHo9jJ5pvJu0qYEUKrzXwoZtRn80UFFUojJIFsx0XmzwkDl7qAq hsz+rPxCvVL3iTBvNGSee8HEZiLzzSkba34nwDoH4qrVEiWX3njcJH1P1bfbrrhk rOxVMTSoXK7P118RFp0iQYyfTAf5RlH292u9vrCRljW2OjE644APBNgWyEyoi/J5 vJnPPvBSrR5hYftn0DrCRLsOm5PPc+6lZ23BzEa+0yJdp2C4Fez7Z4uHTMhw4bBP UOpXb88ZpuUlcLUjj+XU9JMYm7VhP+CKZw+AkXMGXAmiMa4jc6Ria1sTkeCXdT8J cXyyxjBl/CYuhxqMhM3Hxm2ifeV6jQEX5bdk+5y+Qp8Jg++cjjeNYd/Yt8uJPYe3 nFxkKHAK4kr63NIwfPJFWfVE44NwbvmyCsHmTNcDXloq4DFeWGKxsEnngWjeSOIE 3HddtKgcTtL8AtNY9FVlPZMlmDI+Lh9eO+l+05IRIizIDsL8w3WMlpCXiPfrUq1X SQcCxMBJHSAINqMGT4U0sw+VAI6lCTAnJW9AQFZebdDmf2KAsWDxLGwkW0G47/yg rwKGAZhi14OuMc8yY8eWIbU+KRxPUkbS3p7AWVh5qNhTXYdllVjzJORvZ584vp0I RjEwVbloGz5LYN0CCCBh =L8qI -----END PGP SIGNATURE----- From mperumal@cisco.com Mon Jul 29 22:40:21 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A3C921F9F86 for ; Mon, 29 Jul 2013 22:40:21 -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 N0kQF-qrvaAd for ; Mon, 29 Jul 2013 22:40:17 -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 0FF3C21F9F95 for ; Mon, 29 Jul 2013 22:40:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3565; q=dns/txt; s=iport; t=1375162817; x=1376372417; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=y1xqpPVWdTJfvR+K//IzruIEHK7s+/ga+f5tvTnE08M=; b=MrSHq/G+TpZ3MlseRSaArsLTKCPUuqVycZgj4on+xmcMSkJQvVVFQ9qw cYczHVJ/T2Fqm+BIiReblf044fkafCYSZUNVY1tLimmeul/ykHWt2bJX/ hc5BWQ6MwAZycs0bl0HxonbVZJThPgjdGqNC/0Q9vgeTfVV8UvrXXrt2R w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFANBQ91GtJXHA/2dsb2JhbABbgwY1UL4NgSAWdIIkAQEBBAEBATc0FwQCAQgRBAEBCw4GCQcnCxQJCAIEARIIDId8DLkKjH6BOIEXOAYSgwBvA5kIkCODFIFxOQ X-IronPort-AV: E=Sophos;i="4.89,775,1367971200"; d="scan'208";a="241125099" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-5.cisco.com with ESMTP; 30 Jul 2013 05:40:16 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r6U5eGAd000913 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Jul 2013 05:40:16 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.27]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Tue, 30 Jul 2013 00:40:15 -0500 From: "Muthu Arul Mozhi Perumal (mperumal)" To: Marc Petit-Huguenin , "Behave@ietf.org" Thread-Topic: [BEHAVE] Comments on the TURN REST Server API presentation Thread-Index: AQHOjN52FJxox98FVEaUB36YwOMq2Zl8sqUg Date: Tue, 30 Jul 2013 05:40:15 +0000 Message-ID: References: <51F742F8.3070903@acm.org> In-Reply-To: <51F742F8.3070903@acm.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [72.163.208.204] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] Comments on the TURN REST Server API presentation X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 05:40:21 -0000 Marc, |Second, I do not think that trying to overload the long-term authenticatio= n |mechanism is wise - and I take exceptions with the previous presentation t= hat |characterized long-term authentication as having problems. Would it be wise to say there are indeed problems with long-term authentica= tion and document them for the benefit of the community? |This is how long-term authentication works, and that should be left alone.= =20 |IMO what is needed is to design a third authentication option for TURN (pr= obably=20 |with new attributes) that is doing the username/password stateless verific= ation. =20 |Here there is a need to define how the web server and the turn server can |generate/verify the same username/password, so an I-D is required to ensur= e |interoperability. +1 Muthu |-----Original Message----- |From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf O= f Marc Petit-Huguenin |Sent: Tuesday, July 30, 2013 10:07 AM |To: Behave@ietf.org |Subject: [BEHAVE] Comments on the TURN REST Server API presentation | |-----BEGIN PGP SIGNED MESSAGE----- |Hash: SHA256 | |About this presentation, I agree with what Martin Thomson said on the |microphone (trying to paraphrase from memory as the audio recording is not |available yet): There is no need to standardize a RESTful API because the |server can send the username/password in the web page that uses rtcweb, or= can |use any proprietary API between the javascript client and the server. The= re |is no interoperability issue here. | |Second, I do not think that trying to overload the long-term authenticatio= n |mechanism is wise - and I take exceptions with the previous presentation t= hat |characterized long-term authentication as having problems. This is how |long-term authentication works, and that should be left alone. IMO what i= s |needed is to design a third authentication option for TURN (probably with = new |attributes) that is doing the username/password stateless verification. H= ere |there is a need to define how the web server and the turn server can |generate/verify the same username/password, so an I-D is required to ensur= e |interoperability. | |Finally a small nit: In the presentation the wrong syntax was used for th= e |turn uri: the parameter name is transport=3D, not proto=3D. | |Thanks. | |- -- |Marc Petit-Huguenin |Email: marc@petit-huguenin.org |Blog: http://blog.marc.petit-huguenin.org |Profile: http://www.linkedin.com/in/petithug |-----BEGIN PGP SIGNATURE----- |Version: GnuPG v1.4.14 (GNU/Linux) | |iQIcBAEBCAAGBQJR90LqAAoJECnERZXWan7EoiMP/R90khv1Ez+2652uCRIBjNhS |JyGpoNNVsqaPFPHo9jJ5pvJu0qYEUKrzXwoZtRn80UFFUojJIFsx0XmzwkDl7qAq |hsz+rPxCvVL3iTBvNGSee8HEZiLzzSkba34nwDoH4qrVEiWX3njcJH1P1bfbrrhk |rOxVMTSoXK7P118RFp0iQYyfTAf5RlH292u9vrCRljW2OjE644APBNgWyEyoi/J5 |vJnPPvBSrR5hYftn0DrCRLsOm5PPc+6lZ23BzEa+0yJdp2C4Fez7Z4uHTMhw4bBP |UOpXb88ZpuUlcLUjj+XU9JMYm7VhP+CKZw+AkXMGXAmiMa4jc6Ria1sTkeCXdT8J |cXyyxjBl/CYuhxqMhM3Hxm2ifeV6jQEX5bdk+5y+Qp8Jg++cjjeNYd/Yt8uJPYe3 |nFxkKHAK4kr63NIwfPJFWfVE44NwbvmyCsHmTNcDXloq4DFeWGKxsEnngWjeSOIE |3HddtKgcTtL8AtNY9FVlPZMlmDI+Lh9eO+l+05IRIizIDsL8w3WMlpCXiPfrUq1X |SQcCxMBJHSAINqMGT4U0sw+VAI6lCTAnJW9AQFZebdDmf2KAsWDxLGwkW0G47/yg |rwKGAZhi14OuMc8yY8eWIbU+KRxPUkbS3p7AWVh5qNhTXYdllVjzJORvZ584vp0I |RjEwVbloGz5LYN0CCCBh |=3DL8qI |-----END PGP SIGNATURE----- |_______________________________________________ |Behave mailing list |Behave@ietf.org |https://www.ietf.org/mailman/listinfo/behave From simon.perreault@viagenie.ca Mon Jul 29 22:58:21 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFDC021F9F5E for ; Mon, 29 Jul 2013 22:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9625iPOa3tOD for ; Mon, 29 Jul 2013 22:58:20 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0E1EE21F8FB4 for ; Mon, 29 Jul 2013 22:58:20 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:2001::1000]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 79E80403DC for ; Tue, 30 Jul 2013 01:58:19 -0400 (EDT) Message-ID: <51F755FA.5010400@viagenie.ca> Date: Tue, 30 Jul 2013 07:58:18 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: behave@ietf.org References: <51F742F8.3070903@acm.org> In-Reply-To: <51F742F8.3070903@acm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [BEHAVE] Comments on the TURN REST Server API presentation X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 05:58:21 -0000 Le 2013-07-30 06:37, Marc Petit-Huguenin a crit : > Second, I do not think that trying to overload the long-term authentication > mechanism is wise - and I take exceptions with the previous presentation that > characterized long-term authentication as having problems. This is how > long-term authentication works, and that should be left alone. IMO what is > needed is to design a third authentication option for TURN (probably with new > attributes) that is doing the username/password stateless verification. Here > there is a need to define how the web server and the turn server can > generate/verify the same username/password, so an I-D is required to ensure > interoperability. After hearing the presentation and the discussion, that's the way I'm thinking too. I would expect that third option to not be username/password based, but rather token-based. 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 petithug@acm.org Mon Jul 29 23:26:09 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3091721E804D for ; Mon, 29 Jul 2013 23:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILt8EMTo8aoY for ; Mon, 29 Jul 2013 23:26:07 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id CF83121F9BF7 for ; Mon, 29 Jul 2013 23:26:07 -0700 (PDT) Received: from [IPv6:2001:df8:0:64:ca0a:a9ff:fe2e:a4f6] (unknown [IPv6:2001:df8:0:64:ca0a:a9ff:fe2e:a4f6]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 92FA12021A; Tue, 30 Jul 2013 08:26:05 +0200 (CEST) Message-ID: <51F75C86.4060400@acm.org> Date: Tue, 30 Jul 2013 08:26:14 +0200 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130630 Icedove/17.0.7 MIME-Version: 1.0 To: "Muthu Arul Mozhi Perumal (mperumal)" References: <51F742F8.3070903@acm.org> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "Behave@ietf.org" Subject: Re: [BEHAVE] Comments on the TURN REST Server API presentation X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 06:26:09 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 07/30/2013 07:40 AM, Muthu Arul Mozhi Perumal (mperumal) wrote: > Marc, > > |Second, I do not think that trying to overload the long-term > authentication |mechanism is wise - and I take exceptions with the previous > presentation that |characterized long-term authentication as having > problems. > > Would it be wise to say there are indeed problems with long-term > authentication and document them for the benefit of the community? > There is no undocumented problem with long-term authentication (as this is similar to HTTP digest). TURN over DTLS can help, and I plan to write an I-D describing it as I need the reference in another draft developed in P2PSIP. - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iQIcBAEBCAAGBQJR91yEAAoJECnERZXWan7EXvsQANOnVeBhvgnuhIN7Kj7CJRyH FRkZVTQP+7wix1+JPie9PQawyQkJ4ef3YVK0D/WNHJOx7DtoBUxFsGx69ttvZ6IQ F6mbWfi7vmGeZhlc54dpgcOzsK5zUynQgVG3/jiat4LPEEoy1PDh1M1elVdNl0qx 4ZPtoAzep9VqBiDyGlqDx4n/yEKMJgasF3SQihhqsxnfeSvC1hByrHc0eo1uzAa1 0iJTgVDVTQDUQD/BZ6EvkJ0rs8I3fDM/xaMxOHpEGWTRa/a8iszXGRlQkZqmLy05 bI1EZMIjkogUN086Lvx92iIU7yuRUTn0mCocmI5wEh4ZMqjqk62q1+HJFilsLPuz aVn5ckrJb7pxvQaOLp/JWvqDWtLXUSF+zkJTVb3uYzYGWQElEMUIyTlANRuq0Mdp MntVcPrwTLxOzFylwnkqZgRIWQ4agXRrq7j+PokkBam/zC0+wZHTrWlb2VbcTmYw vFfVKLqPUSw4vGmU+nN+Yy1oGWmlBzFoZdFUHPyML7Y+bB7Qy6uQs/RGlMTwrD0f dKD3ECsQm5m4Fm5YdFBnbdaUus2SDCY1eySHVoVIFJyYLo5tLQXY54C63qU2O3JQ oudSjsBiqDS2g2Lf6G3J+0dAZgFBuoad9YbOq15uU86LebGllGxmBeifj9b/HacC n6YlqkFeLfBm9qOyKuHs =cg/q -----END PGP SIGNATURE----- From praspati@cisco.com Mon Jul 29 23:49:58 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6450D21F9F7F for ; Mon, 29 Jul 2013 23:49:58 -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 z5jEQkoMW56W for ; Mon, 29 Jul 2013 23:49:53 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id B940121F9BC3 for ; Mon, 29 Jul 2013 23:49:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2038; q=dns/txt; s=iport; t=1375166993; x=1376376593; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=dIU8Mpe++eB1rWTKbLV+2OxJrn4GKBZlL9VcWCwQ7oA=; b=kAnwiRgvEtpNt1mHlumhjyxgaxE8ERm8n95oH6DgSOUqrmO5TVIawE4/ lIGda6sPVsbeGDYXExxdssLhVCgcq7Lzu/S8y/R4ClTtBPIx8qdjfNIsn ypHjOacx4SmM0Zd9l5FboePpxvqAMAZbaImPUYynINEeZw10git1Bzt7B c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFALxg91GtJXHA/2dsb2JhbABbgwY1UL4OgR8WdIImAQQBAQEkRx0BCCIOPQslAgQBEgiICAy5J49NOBiDAG8DiHKQFpAjgxSCKg X-IronPort-AV: E=Sophos;i="4.89,776,1367971200"; d="scan'208";a="241118499" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-2.cisco.com with ESMTP; 30 Jul 2013 06:49:53 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r6U6nrtn025021 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Jul 2013 06:49:53 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.106]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Tue, 30 Jul 2013 01:49:53 -0500 From: "Prashanth Patil (praspati)" To: Simon Perreault , "behave@ietf.org" Thread-Topic: [BEHAVE] Comments on the TURN REST Server API presentation Thread-Index: AQHOjPD9ljSFjX8YrUuaxh0z+iMJeA== Date: Tue, 30 Jul 2013 06:49:52 +0000 Message-ID: In-Reply-To: <51F755FA.5010400@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.61.194.174] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <1B0E848321B18F46AFD360E74E21DABC@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] Comments on the TURN REST Server API presentation X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 06:49:58 -0000 On 30/07/13 11:28 AM, "Simon Perreault" wrote: >Le 2013-07-30 06:37, Marc Petit-Huguenin a =E9crit : >> Second, I do not think that trying to overload the long-term >>authentication >> mechanism is wise - and I take exceptions with the previous >>presentation that >> characterized long-term authentication as having problems. This is how >> long-term authentication works, and that should be left alone. IMO >>what is >> needed is to design a third authentication option for TURN (probably >>with new >> attributes) that is doing the username/password stateless verification. >> Here >> there is a need to define how the web server and the turn server can >> generate/verify the same username/password, so an I-D is required to >>ensure >> interoperability. > >After hearing the presentation and the discussion, that's the way I'm >thinking too. I would expect that third option to not be >username/password based, but rather token-based. Yes, a token based approach should be considered. A TURN server can then also, more easily, cater to regular clients that want to use username/password like they do today. The draft does not provide details on the mechanics of shared secret exchange between the web-server and turn-server. The assumption is that the two are always well known to each other, but that not may not be the case always - a turn server should be able to fetch shared secret from a previously unknown server, on demand. Also, what if multiple web-servers want to avail the services of the same turn server? How does the turn server know which shared secret to choose, realm maybe? -Prashanth > >Simon >--=20 >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 >_______________________________________________ >Behave mailing list >Behave@ietf.org >https://www.ietf.org/mailman/listinfo/behave From ajs@anvilwalrusden.com Tue Jul 30 01:05:50 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B67B21E80E5 for ; Tue, 30 Jul 2013 01:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VJgFMrzj5J-e for ; Tue, 30 Jul 2013 01:05:43 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id AEC9321E80DE for ; Tue, 30 Jul 2013 01:05:21 -0700 (PDT) Received: from mx1.yitter.info (dhcp-4783.meeting.ietf.org [130.129.71.131]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id C27C58A031 for ; Tue, 30 Jul 2013 08:05:20 +0000 (UTC) Date: Tue, 30 Jul 2013 04:05:04 -0400 From: Andrew Sullivan To: behave@ietf.org Message-ID: <20130730080504.GA52575@mx1.yitter.info> References: <20130729134623.GD51737@mx1.yitter.info> <51F674D0.3040603@viagenie.ca> <20130729143910.GB51823@mx1.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [BEHAVE] Fwd: I-D Action: draft-sun-behave-v4tov6-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 08:05:51 -0000 Hi, I'm already violating my usual rules about over-posting, so I'm going to endeavour to shut up after this. But there's a subtle but, in my opinion, mistaken parallelism here, and I want to challenge it. On Tue, Jul 30, 2013 at 10:55:42AM +0800, Qiong wrote: > For example, we now have NAT64 and so v6-only client can emerge and talk to > v4 server. So v6-only clients may be more and more in the future. I see > nobody argues that if we have NAT64, v4 server may live in v4 forever. > > Then for v4-to-v6 scenario, this is the same since it will bring the > ability to support v6-only server to be reachable by v4-only clients. > Therefore, v6-only server may emerge because they do not need to worry > about losing v4 clients. So v6-only server maybe more and more in the > future. This will promote v6-development, rather than the opposite one. The key reason to have defined NAT64 was because we had a supply problem. If you were a v6-only node, you couldn't reach servers on the v4 Internet. But _most_ things were on the v4 Internet. So NAT64 gave us a way of permitting people to have v6-only connectivity without paying the cost of losing access to the entire Internet. The argument above turns this on its head, and says that if you are standing up a service, you are worried about losing the possible customers on v4-only networks. Therefore, you will go dual stack. Implicitly, if we say, "New v4 service bad," we think it would be better that the service be v6-only. So, we should have a mechanism by which v4-only clients can access the v6 Internet, and this will in some sense increase v6 use because the service is actually accessed over v6. I think the argument is subtle but wrong. First, it depends on the premise that there is an interesting population that will (economically) remain v4-only while v6-only service deployment is in some sense (likely economically) a reasonable plan. As I already argued elsewhere in this thread, that premise needs a lot of supporting argument, because it seems to me to be false. Second, it confuses the goal of IPv6 deployment in the sense of native use with a supposed goal of merely carrying traffic over v6. The latter is not an interesting goal in any sense: if tomorrow we simply encapsulated all v4 traffic inside v6, I do not think it would be an interesting advance in v6 deployment. So I reject the claim that this sort of 4-to-6 NAT is a positive contributor to IPv6 deployment. The right message is, "If you want to reach this v6-only service, get a v6 address." If the service is valuable, the customers will come, since v6 communications are no longer an enormous big deal. As for the risk that dual stack everywhere permits v4 to persist: so what? If v6 is working everywhere, then the v4 network will gradually wither away because it is not economical to keep that network interface active. (Lee Howard has done interesting analysis in this area, and his models at least suggest a pretty significant changeover incentive once a not very large number of services come up on IPv6.) The goal is not to make the evil, bad, wrong v4 go away, any more than the goal was in itself to kill X.25 and dance about on its grave singing hallelujah. That was just a happy consequence. > From the long history of IPv6 development, I think it is clear this > assumption has never hardly existed. If anyone *ought to be able to get a > v6 address*, we would have reached the v6-world long ago, rather than > debating how to transit. Surely not. V6 deployment has never been impeded by lack of v6 addresses. As long as v4 was good enough and it was still possible to get address space for reasonable cost, there was little incentive to move to a network technology that seemed like it was still under development. But we're out of v4 addresses now, the experience is _not_ good enough, and so one might suppose the incentives have changed. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From meng.wei2@zte.com.cn Tue Jul 30 01:18:06 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4F3A21E805F; Tue, 30 Jul 2013 01:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.421 X-Spam-Level: X-Spam-Status: No, score=-101.421 tagged_above=-999 required=5 tests=[AWL=1.176, 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 p28KwdS6Rjvk; Tue, 30 Jul 2013 01:17:58 -0700 (PDT) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 1099121F9BB1; Tue, 30 Jul 2013 01:17:47 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 4EF1412A09DC; Tue, 30 Jul 2013 16:17:17 +0800 (CST) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id 65DB573E0AC; Tue, 30 Jul 2013 16:17:16 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id r6U8GxoL057379; Tue, 30 Jul 2013 16:16:59 +0800 (GMT-8) (envelope-from meng.wei2@zte.com.cn) In-Reply-To: To: Qiong MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: meng.wei2@zte.com.cn Date: Tue, 30 Jul 2013 16:16:58 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2013-07-30 16:16:46, Serialize complete at 2013-07-30 16:16:46 Content-Type: multipart/alternative; boundary="=_alternative 002D873648257BB8_=" X-MAIL: mse02.zte.com.cn r6U8GxoL057379 Cc: "Reinaldo Penno \(repenno\)" , behave-bounces@ietf.org, "behave@ietf.org" Subject: Re: [BEHAVE] draft-meng-behave-napgt can be met by PCP port set X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 08:18:06 -0000 This is a multipart message in MIME format. --=_alternative 002D873648257BB8_= Content-Type: text/plain; charset="US-ASCII" Hi Qiong, Reinaldo, Although port preservation could be achieved by PCP port-set, but how can port-set ensure the port remaining the same before and after the NAT translation? That is the behavior of port assignment of NAT and it is the very requirement of the scenario. Thanks, Wei behave-bounces@ietf.org 2013/07/30 11:16:02: > Hi Reinaldo, > > Yes, I agree with you. This can be achieved by PCP port-set. > > Best wishes > Qiong > > On Mon, Jul 29, 2013 at 9:33 PM, Reinaldo Penno (repenno) > wrote: > After watching this presentation that generated some ML discussion, > it seems to me requirements can be fully met with PCP port set. > > Thanks, > > Reinaldo > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > > -- > ============================================== > Qiong Sun > China Telecom Beijing Research Institude > > > Open source code: > lightweight 4over6: http://sourceforge.net/projects/laft6/ > PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/ > =============================================== > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave --=_alternative 002D873648257BB8_= Content-Type: text/html; charset="US-ASCII"
Hi Qiong, Reinaldo,
  Although port preservation could be achieved by PCP port-set, but how can port-set
ensure the port remaining the same before and after the NAT translation? That is the
behavior of port assignment of NAT and it is the very requirement of the scenario.
 
Thanks,
Wei


behave-bounces@ietf.org 2013/07/30 11:16:02:

> Hi Reinaldo,
>
> Yes, I agree with you. This can be achieved by PCP port-set.
>
> Best wishes
> Qiong
>

> On Mon, Jul 29, 2013 at 9:33 PM, Reinaldo Penno (repenno) <repenno@cisco.com
> > wrote:
> After watching this presentation that generated some ML discussion,
> it seems to me requirements can be fully met with PCP port set.
>
> Thanks,
>
> Reinaldo
>
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave
>

>
> --
> ==============================================
> Qiong Sun
> China Telecom Beijing Research Institude
>
>
> Open source code:
> lightweight 4over6: http://sourceforge.net/projects/laft6/
> PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/
> ===============================================
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave
 --=_alternative 002D873648257BB8_=-- From repenno@cisco.com Tue Jul 30 01:42:52 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7FE921E80D3; Tue, 30 Jul 2013 01:42:50 -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=[AWL=-0.000, 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 jFAunRNl7oXU; Tue, 30 Jul 2013 01:42:44 -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 8924821E80C2; Tue, 30 Jul 2013 01:41:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7439; q=dns/txt; s=iport; t=1375173714; x=1376383314; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=Sr6uuzYh0z97O8lqm5HVET25todzXAC6U9xy/Jh6Hn8=; b=UR/n5TZ5T9zuldGXm5LeoN3uhlVhgGNnw3M8rbl697w8v5JQzRFhmiEU 7yWbhV71IKIaWfAdRuuVi3haSJaBuE0cZtlsbKY3ZGNLt5j0VOKnrxcem Ic8mMRl2Ni0ep/qP2g/JUjeRiTEeDQUto+V6oH3ZymPDIMYRDfAZj5kiN c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq8GAPp691GtJV2d/2dsb2JhbABbgkJENVCsHpBkAYELgRsWdIIkAQEBAwEBAQFrCwUNAQgRAwECAQodKAYLFAkIAgQBDQUIh3YDCQYMsBANiF6NDYJAIA0EB4MYbwOVdoMSin2FJoMUgio X-IronPort-AV: E=Sophos;i="4.89,776,1367971200"; d="scan'208,217";a="238176298" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP; 30 Jul 2013 08:41:54 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r6U8frq9002545 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Jul 2013 08:41:54 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.99]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Tue, 30 Jul 2013 03:41:53 -0500 From: "Reinaldo Penno (repenno)" To: "meng.wei2@zte.com.cn" , Qiong Thread-Topic: [BEHAVE] draft-meng-behave-napgt can be met by PCP port set Thread-Index: AQHOjQCkbkdodjLYsUSCJF1I6dGlsA== Date: Tue, 30 Jul 2013 08:41:53 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F0604090E8DE5@xmb-rcd-x04.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.86.253.186] Content-Type: multipart/alternative; boundary="_000_45A697A8FFD7CF48BCF2BE7E106F0604090E8DE5xmbrcdx04ciscoc_" MIME-Version: 1.0 Cc: "behave-bounces@ietf.org" , "behave@ietf.org" Subject: Re: [BEHAVE] draft-meng-behave-napgt can be met by PCP port set X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 08:42:52 -0000 --_000_45A697A8FFD7CF48BCF2BE7E106F0604090E8DE5xmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Also possible with port set. It would be good to get your review of the PCP= port set draft since you have a concrete use-case. From: > Date: Tue, 30 Jul 2013 16:16:58 +0800 To: Qiong > Cc: "behave@ietf.org" >, >, Re= inaldo Penno > Subject: Re: Re: [BEHAVE] draft-meng-behave-napgt can be met by PCP port se= t Hi Qiong, Reinaldo, Although port preservation could be achieved by PCP port-set, but how can= port-set ensure the port remaining the same before and after the NAT translation? Th= at is the behavior of port assignment of NAT and it is the very requirement of the sc= enario. Thanks, Wei behave-bounces@ietf.org 2013/07/30 11:16:02= : > Hi Reinaldo, > > Yes, I agree with you. This can be achieved by PCP port-set. > > Best wishes > Qiong > > On Mon, Jul 29, 2013 at 9:33 PM, Reinaldo Penno (repenno) > > wrote: > After watching this presentation that generated some ML discussion, > it seems to me requirements can be fully met with PCP port set. > > Thanks, > > Reinaldo > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > > -- > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Qiong Sun > China Telecom Beijing Research Institude > > > Open source code: > lightweight 4over6: http://sourceforge.net/projects/laft6/ > PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/ > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave --_000_45A697A8FFD7CF48BCF2BE7E106F0604090E8DE5xmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <8011DF327B16BE4E888E247576C143E0@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Also possible with port set. It would be good to get your review of th= e PCP port set draft since you have a concrete use-case.

From: <meng.wei2@zte.com.cn>
Date: Tue, 30 Jul 2013 16:16:58 = 3;0800
To: Qiong <bingxuere@gmail.com>
Cc: "behave@ietf.org" <= behave@ietf.org>, <beh= ave-bounces@ietf.org>, Reinaldo Penno <repenno@cisco.com>
Subject: Re: Re: [BEHAVE] draft-men= g-behave-napgt can be met by PCP port set


Hi Qiong, = Reinaldo,
  Although port preservation coul= d be achieved by PCP port-set, but how can port-set
ensure the port remaining the same bef= ore and after the NAT translation? That is the
behavior of port assignment of NAT and= it is the very requirement of the scenario.
 
Thanks,
Wei


behave-boun= ces@ietf.org 2013/07/30 11:16:02:

> Hi Reinaldo,
>
> Yes, I agree with you. This can be achieved by PCP port-set.
>
> Best wishes
> Qiong
>

> On Mon, Jul 29, 2013 at 9:33 PM, Reinaldo Penno (= repenno) <repenno@cisco.com
> > wrote:
> After watching this presentation that generated s= ome ML discussion,
> it seems to me requirements can be fully met with PCP port set.
>
> Thanks,
>
> Reinaldo
>
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.i= etf.org/mailman/listinfo/behave

>

>
> --
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> Qiong Sun
> China Telecom Beijing Research Institude
>
>
> Open source code:
> lightweight 4over6: http://sourceforge.net/projects/laft6/
> PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.i= etf.org/mailman/listinfo/behave
 --_000_45A697A8FFD7CF48BCF2BE7E106F0604090E8DE5xmbrcdx04ciscoc_-- From Branimir.Rajtar@t.ht.hr Tue Jul 30 01:46:52 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B719421F9C40 for ; Tue, 30 Jul 2013 01:46:52 -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 SwzND33w9BMN for ; Tue, 30 Jul 2013 01:46:47 -0700 (PDT) Received: from mx02.t.ht.hr (mx02.t.ht.hr [195.29.161.89]) by ietfa.amsl.com (Postfix) with SMTP id E00DA21E80D8 for ; Tue, 30 Jul 2013 01:46:21 -0700 (PDT) Received: from (unknown [172.17.66.76]) by mx02.t.ht.hr with smtp id 0a78_1869_812f10cc_f8f4_11e2_a866_00219b931f47; Tue, 30 Jul 2013 10:46:19 +0200 Received: from S2010EXCHCA1.ad.local ([10.240.132.138]) by mailgw.ad.local with Microsoft SMTPSVC(6.0.3790.4675); Tue, 30 Jul 2013 10:46:19 +0200 Received: from S2010EXCH1.ad.local ([fe80::2d7b:39dd:876e:f277]) by S2010EXCHCA1.ad.local ([::1]) with mapi id 14.03.0123.003; Tue, 30 Jul 2013 10:46:19 +0200 From: Branimir Rajtar To: "ajs@anvilwalrusden.com" , "behave@ietf.org" Thread-Topic: [BEHAVE] Fwd: I-D Action: draft-sun-behave-v4tov6-00.txt Thread-Index: AQHOjNBH7KZnViUbv0K3Et3zbLdQ3Jl8u9YAgAAtDus= Date: Tue, 30 Jul 2013 08:46:19 +0000 Message-ID: References: <20130729134623.GD51737@mx1.yitter.info> <51F674D0.3040603@viagenie.ca> <20130729143910.GB51823@mx1.yitter.info> , <20130730080504.GA52575@mx1.yitter.info> In-Reply-To: <20130730080504.GA52575@mx1.yitter.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 30 Jul 2013 08:46:19.0705 (UTC) FILETIME=[42E41290:01CE8D01] X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 Subject: Re: [BEHAVE] Fwd: I-D Action: draft-sun-behave-v4tov6-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Branimir Rajtar List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 08:46:52 -0000 SGksCgpZb3VyIGFyZ3VtZW50YXRpb24gc2F5cyB0aGF0IGV2ZXJ5Ym9keSBuZWVkcyB0byBoYXZl IElQdjYgYWNjZXNzIGFuZCBJIGFncmVlIGNvbXBsZXRlbHkgdGhhdCB3b3VsZCBzb2x2ZSBhbGwg aXNzdWVzLiBIb3dldmVyLCB3ZSB3aWxsIG5vdCBiZSBpbiB0aGF0IHBvaW50IG9mIHRpbWUgZm9y IGF0IGxlYXN0IGZpdmUgeWVhcnMuIEFuZCBJIHRoaW5rIEknbSBvcHRpbWlzdGljIC0gYnkgbG9v a2luZyBhdCB0aGUgY3VycmVudCBJUHY2IGRlcGxveW1lbnQgcGVyY2VudGFnZXMsIGl0IG1pZ2h0 IGJlIG11Y2ggbW9yZS4KCklTUHMgYXJlIG5vdCByZWFsbHkga2VlbiBvbiBkZXBsb3lpbmcgSVB2 NiwgdGhleSByYXRoZXIgZG8gQ0dOLiBOQVQ0NiB3b3VsZCBiZSBjaGVhcGVyIGFuZCB3b3VsZCBw cm92aWRlIGEgcmVhc29uIGZvciBzZXJ2ZXJzIHdoaWNoIGFyZSBjdXJyZW50bHkgSVB2NC1vbmx5 IHRvIHN3aXRjaCB0byBkdWFsLXN0YWNrIGFuZCBldmVudHVhbGx5IHRvIElQdjYtb25seS4KCkkg dGhpbmsgd2UgY291bGQgZGlzY3VzcyB0aGlzIHRvcGljIGZvciB0aGUgbmV4dCBjb3VwbGUgb2Yg d2Vla3MgKHdoaWNoIHdvdWxkIGJlIHF1aXRlIGRpZmZpY3VsdCBzaW5jZSBJJ20gd3JpdGluZyBm cm9tIG15IHNtYXJ0cGhvbmUpIHNvIEkgc3VnZ2VzdCB0byBsZWF2ZSB0aGUgZGVjaXNpb24gb24g dGhlIHdvcmtpbmcgZ3JvdXAuCgpCUiwKQnJhbmltaXIKCgoKCi0tLS0tLS0tIEl6dm9ybmEgcG9y dWthIC0tLS0tLS0tCsWgYWxqZTogQW5kcmV3IFN1bGxpdmFuIDxhanNAYW52aWx3YWxydXNkZW4u Y29tPgpEYXR1bToKVG86IGJlaGF2ZUBpZXRmLm9yZwpOYXNsb3Y6IFJlOiBbQkVIQVZFXSBGd2Q6 IEktRCBBY3Rpb246IGRyYWZ0LXN1bi1iZWhhdmUtdjR0b3Y2LTAwLnR4dAoKCkhpLAoKSSdtIGFs cmVhZHkgdmlvbGF0aW5nIG15IHVzdWFsIHJ1bGVzIGFib3V0IG92ZXItcG9zdGluZywgc28gSSdt IGdvaW5nCnRvIGVuZGVhdm91ciB0byBzaHV0IHVwIGFmdGVyIHRoaXMuICBCdXQgdGhlcmUncyBh IHN1YnRsZSBidXQsIGluIG15Cm9waW5pb24sIG1pc3Rha2VuIHBhcmFsbGVsaXNtIGhlcmUsIGFu ZCBJIHdhbnQgdG8gY2hhbGxlbmdlIGl0LgoKT24gVHVlLCBKdWwgMzAsIDIwMTMgYXQgMTA6NTU6 NDJBTSArMDgwMCwgUWlvbmcgd3JvdGU6Cgo+IEZvciBleGFtcGxlLCB3ZSBub3cgaGF2ZSBOQVQ2 NCBhbmQgc28gdjYtb25seSBjbGllbnQgY2FuIGVtZXJnZSBhbmQgdGFsayB0bwo+IHY0IHNlcnZl ci4gU28gdjYtb25seSBjbGllbnRzIG1heSBiZSBtb3JlIGFuZCBtb3JlIGluIHRoZSBmdXR1cmUu IEkgc2VlCj4gbm9ib2R5IGFyZ3VlcyB0aGF0IGlmIHdlIGhhdmUgTkFUNjQsIHY0IHNlcnZlciBt YXkgbGl2ZSBpbiB2NCBmb3JldmVyLgo+Cj4gVGhlbiBmb3IgdjQtdG8tdjYgc2NlbmFyaW8sIHRo aXMgaXMgdGhlIHNhbWUgc2luY2UgaXQgd2lsbCBicmluZyB0aGUKPiBhYmlsaXR5IHRvIHN1cHBv cnQgdjYtb25seSBzZXJ2ZXIgdG8gYmUgcmVhY2hhYmxlIGJ5IHY0LW9ubHkgY2xpZW50cy4KPiBU aGVyZWZvcmUsIHY2LW9ubHkgc2VydmVyIG1heSBlbWVyZ2UgYmVjYXVzZSB0aGV5IGRvIG5vdCBu ZWVkIHRvIHdvcnJ5Cj4gYWJvdXQgbG9zaW5nIHY0IGNsaWVudHMuIFNvIHY2LW9ubHkgc2VydmVy IG1heWJlIG1vcmUgYW5kIG1vcmUgaW4gdGhlCj4gZnV0dXJlLiBUaGlzIHdpbGwgcHJvbW90ZSB2 Ni1kZXZlbG9wbWVudCwgcmF0aGVyIHRoYW4gdGhlIG9wcG9zaXRlIG9uZS4KClRoZSBrZXkgcmVh c29uIHRvIGhhdmUgZGVmaW5lZCBOQVQ2NCB3YXMgYmVjYXVzZSB3ZSBoYWQgYSBzdXBwbHkKcHJv YmxlbS4gIElmIHlvdSB3ZXJlIGEgdjYtb25seSBub2RlLCB5b3UgY291bGRuJ3QgcmVhY2ggc2Vy dmVycyBvbgp0aGUgdjQgSW50ZXJuZXQuICBCdXQgX21vc3RfIHRoaW5ncyB3ZXJlIG9uIHRoZSB2 NCBJbnRlcm5ldC4gIFNvIE5BVDY0CmdhdmUgdXMgYSB3YXkgb2YgcGVybWl0dGluZyBwZW9wbGUg dG8gaGF2ZSB2Ni1vbmx5IGNvbm5lY3Rpdml0eQp3aXRob3V0IHBheWluZyB0aGUgY29zdCBvZiBs b3NpbmcgYWNjZXNzIHRvIHRoZSBlbnRpcmUgSW50ZXJuZXQuCgpUaGUgYXJndW1lbnQgYWJvdmUg dHVybnMgdGhpcyBvbiBpdHMgaGVhZCwgYW5kIHNheXMgdGhhdCBpZiB5b3UgYXJlCnN0YW5kaW5n IHVwIGEgc2VydmljZSwgeW91IGFyZSB3b3JyaWVkIGFib3V0IGxvc2luZyB0aGUgcG9zc2libGUK Y3VzdG9tZXJzIG9uIHY0LW9ubHkgbmV0d29ya3MuICBUaGVyZWZvcmUsIHlvdSB3aWxsIGdvIGR1 YWwgc3RhY2suCkltcGxpY2l0bHksIGlmIHdlIHNheSwgIk5ldyB2NCBzZXJ2aWNlIGJhZCwiIHdl IHRoaW5rIGl0IHdvdWxkIGJlCmJldHRlciB0aGF0IHRoZSBzZXJ2aWNlIGJlIHY2LW9ubHkuICBT bywgd2Ugc2hvdWxkIGhhdmUgYSBtZWNoYW5pc20gYnkKd2hpY2ggdjQtb25seSBjbGllbnRzIGNh biBhY2Nlc3MgdGhlIHY2IEludGVybmV0LCBhbmQgdGhpcyB3aWxsIGluCnNvbWUgc2Vuc2UgaW5j cmVhc2UgdjYgdXNlIGJlY2F1c2UgdGhlIHNlcnZpY2UgaXMgYWN0dWFsbHkgYWNjZXNzZWQKb3Zl ciB2Ni4KCkkgdGhpbmsgdGhlIGFyZ3VtZW50IGlzIHN1YnRsZSBidXQgd3JvbmcuICBGaXJzdCwg aXQgZGVwZW5kcyBvbiB0aGUKcHJlbWlzZSB0aGF0IHRoZXJlIGlzIGFuIGludGVyZXN0aW5nIHBv cHVsYXRpb24gdGhhdCB3aWxsCihlY29ub21pY2FsbHkpIHJlbWFpbiB2NC1vbmx5IHdoaWxlIHY2 LW9ubHkgc2VydmljZSBkZXBsb3ltZW50IGlzIGluCnNvbWUgc2Vuc2UgKGxpa2VseSBlY29ub21p Y2FsbHkpIGEgcmVhc29uYWJsZSBwbGFuLiAgQXMgSSBhbHJlYWR5CmFyZ3VlZCBlbHNld2hlcmUg aW4gdGhpcyB0aHJlYWQsIHRoYXQgcHJlbWlzZSBuZWVkcyBhIGxvdCBvZgpzdXBwb3J0aW5nIGFy Z3VtZW50LCBiZWNhdXNlIGl0IHNlZW1zIHRvIG1lIHRvIGJlIGZhbHNlLiAgU2Vjb25kLCBpdApj b25mdXNlcyB0aGUgZ29hbCBvZiBJUHY2IGRlcGxveW1lbnQgaW4gdGhlIHNlbnNlIG9mIG5hdGl2 ZSB1c2Ugd2l0aCBhCnN1cHBvc2VkIGdvYWwgb2YgbWVyZWx5IGNhcnJ5aW5nIHRyYWZmaWMgb3Zl ciB2Ni4gIFRoZSBsYXR0ZXIgaXMgbm90CmFuIGludGVyZXN0aW5nIGdvYWwgaW4gYW55IHNlbnNl OiBpZiB0b21vcnJvdyB3ZSBzaW1wbHkgZW5jYXBzdWxhdGVkCmFsbCB2NCB0cmFmZmljIGluc2lk ZSB2NiwgSSBkbyBub3QgdGhpbmsgaXQgd291bGQgYmUgYW4gaW50ZXJlc3RpbmcKYWR2YW5jZSBp biB2NiBkZXBsb3ltZW50LiAgU28gSSByZWplY3QgdGhlIGNsYWltIHRoYXQgdGhpcyBzb3J0IG9m CjQtdG8tNiBOQVQgaXMgYSBwb3NpdGl2ZSBjb250cmlidXRvciB0byBJUHY2IGRlcGxveW1lbnQu ICBUaGUgcmlnaHQKbWVzc2FnZSBpcywgIklmIHlvdSB3YW50IHRvIHJlYWNoIHRoaXMgdjYtb25s eSBzZXJ2aWNlLCBnZXQgYSB2NgphZGRyZXNzLiIgIElmIHRoZSBzZXJ2aWNlIGlzIHZhbHVhYmxl LCB0aGUgY3VzdG9tZXJzIHdpbGwgY29tZSwgc2luY2UKdjYgY29tbXVuaWNhdGlvbnMgYXJlIG5v IGxvbmdlciBhbiBlbm9ybW91cyBiaWcgZGVhbC4KCkFzIGZvciB0aGUgcmlzayB0aGF0IGR1YWwg c3RhY2sgZXZlcnl3aGVyZSBwZXJtaXRzIHY0IHRvIHBlcnNpc3Q6IHNvCndoYXQ/ICBJZiB2NiBp cyB3b3JraW5nIGV2ZXJ5d2hlcmUsIHRoZW4gdGhlIHY0IG5ldHdvcmsgd2lsbCBncmFkdWFsbHkK d2l0aGVyIGF3YXkgYmVjYXVzZSBpdCBpcyBub3QgZWNvbm9taWNhbCB0byBrZWVwIHRoYXQgbmV0 d29yawppbnRlcmZhY2UgYWN0aXZlLiAgKExlZSBIb3dhcmQgaGFzIGRvbmUgaW50ZXJlc3Rpbmcg YW5hbHlzaXMgaW4gdGhpcwphcmVhLCBhbmQgaGlzIG1vZGVscyBhdCBsZWFzdCBzdWdnZXN0IGEg cHJldHR5IHNpZ25pZmljYW50IGNoYW5nZW92ZXIKaW5jZW50aXZlIG9uY2UgYSBub3QgdmVyeSBs YXJnZSBudW1iZXIgb2Ygc2VydmljZXMgY29tZSB1cCBvbiBJUHY2LikKVGhlIGdvYWwgaXMgbm90 IHRvIG1ha2UgdGhlIGV2aWwsIGJhZCwgd3JvbmcgdjQgZ28gYXdheSwgYW55IG1vcmUgdGhhbgp0 aGUgZ29hbCB3YXMgaW4gaXRzZWxmIHRvIGtpbGwgWC4yNSBhbmQgZGFuY2UgYWJvdXQgb24gaXRz IGdyYXZlCnNpbmdpbmcgaGFsbGVsdWphaC4gIFRoYXQgd2FzIGp1c3QgYSBoYXBweSBjb25zZXF1 ZW5jZS4KCj4gRnJvbSB0aGUgbG9uZyBoaXN0b3J5IG9mIElQdjYgZGV2ZWxvcG1lbnQsIEkgdGhp bmsgaXQgaXMgY2xlYXIgdGhpcwo+IGFzc3VtcHRpb24gaGFzIG5ldmVyIGhhcmRseSBleGlzdGVk LiBJZiBhbnlvbmUgKm91Z2h0IHRvIGJlIGFibGUgdG8gZ2V0IGEKPiB2NiBhZGRyZXNzKiwgd2Ug d291bGQgaGF2ZSByZWFjaGVkIHRoZSB2Ni13b3JsZCBsb25nIGFnbywgcmF0aGVyIHRoYW4KPiBk ZWJhdGluZyBob3cgdG8gdHJhbnNpdC4KClN1cmVseSBub3QuICBWNiBkZXBsb3ltZW50IGhhcyBu ZXZlciBiZWVuIGltcGVkZWQgYnkgbGFjayBvZiB2NgphZGRyZXNzZXMuICBBcyBsb25nIGFzIHY0 IHdhcyBnb29kIGVub3VnaCBhbmQgaXQgd2FzIHN0aWxsIHBvc3NpYmxlIHRvCmdldCBhZGRyZXNz IHNwYWNlIGZvciByZWFzb25hYmxlIGNvc3QsIHRoZXJlIHdhcyBsaXR0bGUgaW5jZW50aXZlIHRv Cm1vdmUgdG8gYSBuZXR3b3JrIHRlY2hub2xvZ3kgdGhhdCBzZWVtZWQgbGlrZSBpdCB3YXMgc3Rp bGwgdW5kZXIKZGV2ZWxvcG1lbnQuICBCdXQgd2UncmUgb3V0IG9mIHY0IGFkZHJlc3NlcyBub3cs IHRoZSBleHBlcmllbmNlIGlzCl9ub3RfIGdvb2QgZW5vdWdoLCBhbmQgc28gb25lIG1pZ2h0IHN1 cHBvc2UgdGhlIGluY2VudGl2ZXMgaGF2ZSBjaGFuZ2VkLgoKQmVzdCwKCkEKCi0tCkFuZHJldyBT dWxsaXZhbgphanNAYW52aWx3YWxydXNkZW4uY29tCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fCkJlaGF2ZSBtYWlsaW5nIGxpc3QKQmVoYXZlQGlldGYub3Jn Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYmVoYXZlCgoKPEhUTUw+PFA+ PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jOTk5OTk5IHNpemU9MT4NCg0KSVpKQVZBIE8gT0RSSUNB TkpVIE9ER09WT1JOT1NUSTogU2FkcsW+YWogb3ZlIHBvcnVrZSBpIGV2ZW50dWFsbm8gcHJpbG/F vmVuaWggZGF0b3Rla2EgamUgcG92amVybGppdiBpIG5hbWlqZW5qZW4gamUgc2FtbyBvc29iYW1h IGlsaSBzdWJqZWt0aW1hIGtvamkgc3UgbmF2ZWRlbmkgdSBhZHJlc2kuIFVrb2xpa28gc3RlIHBy aW1pbGkgb3Z1IHBvcnVrdSBncmXFoWtvbSwgbW9saW1vIFZhcywgb2JhdmlqZXN0aXRlIHBvxaFp bGphdGVsamEsIGEgcG9ydWt1IGkgc3ZlIG5qZW5lIHByaXZpdGtlIG9kbWFoLCBiZXogxI1pdGFu amEsIHRyYWpubyB1a2xvbml0ZSBzIHJhxI11bmFsYS4gQmlsbyBrYWt2byBwcmVub8WhZW5qZSwg a29waXJhbmplIGlsaSBkaXN0cmlidWNpamEgaW5mb3JtYWNpamEgc2FkcsW+YW5paCB1IHBvcnVj aSB0cmXEh2ltIG9zb2JhbWEgamUgemFicmFuamVubyBpIG1vxb5lIGJpdGkgemFrb25za2kga2HF vm5qaXZvLiBTYWRyxb5haiwgc3Rhdm92aSBpIG1pxaFsamVuamEgaXpuZXNlbmkgdSBwb3J1Y2kg c3UgYXV0b3JvdmkgaSBuZSBwcmVkc3RhdmxqYWp1IG51xb5ubyBzdGF2b3ZlIEhUIC0gSHJ2YXRz a2loIHRlbGVrb211bmlrYWNpamEgZC5kLiBIVCBuZSBwcmlodmHEh2EgbmlrYWt2dSBvZGdvdm9y bm9zdCB6YSBldmVudHVhbG51IMWhdGV0dSBuYXN0YWx1IHByaW1pdGtvbSBvdmUgcG9ydWtlIGkg cHJpbG9nYSBzYWRyxb5hbmloIHUgcG9ydWNpLg0KDQo8L0ZPTlQ+PC9QPjxQPjxGT05UIGZhY2U9 QXJpYWwgY29sb3I9Izk5OTk5OSBzaXplPTE+DQoNCiBESVNDTEFJTUVSOlRoZSBjb250ZW50cyBv ZiB0aGlzIGVtYWlsIGFzIHdlbGwgYXMgYW55IGZpbGVzIGF0dGFjaGVkIHRvIGl0IGFyZSBjb25m aWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgaW5kaXZpZHVhbHMgb3IgZW50aXRpZXMg d2hpY2ggdGhleSBhcmUgYWRkcmVzc2VkIHRvLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVt YWlsIG1lc3NhZ2UgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgcGVybWFu ZW50bHkgcmVtb3ZlIHRoZSBtZXNzYWdlIGFuZCBhbGwgYXR0YWNoZWQgZmlsZXMgZnJvbSB0aGUg Y29tcHV0ZXIuIEFueSBkaXNjbG9zdXJlLCBjb3B5aW5nIG9yIGRpc3RyaWJ1dGlvbiBvZiBhbGwg b3IgYSBwYXJ0IG9mIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gdG8gb3IgYnkgdGhpcmQg cGFydGllcyBpcyBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIFBsZWFzZSBub3RlIHRo YXQgYW55IHZpZXdzIG9yIG9waW5pb25zIHByZXNlbnRlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHNv bGVseSB0aG9zZSBvZiB0aGUgYXV0aG9yIGFuZCBkbyBub3QgbmVjZXNzYXJpbHkgcmVwcmVzZW50 IHRoZSB2aWV3cyBhbmQgb3BpbmlvbnMgb2YgQ3JvYXRpYW4gVGVsZWNvbSBJbmMuIENyb2F0aWFu IFRlbGVjb20gSW5jLiBhY2NlcHRzIG5vIGxpYWJpbGl0eSBmb3IgYW55IHBvdGVudGlhbCBkYW1h Z2UgY2F1c2VkIGJ5IHRoaXMgbWVzc2FnZSBhbmQgZmlsZXMgYXR0YWNoZWQgdG8gaXQuDQoNCjwv Rk9OVD48L1A+PC9IVE1MPgo= From simon.perreault@viagenie.ca Tue Jul 30 02:14:29 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 894B521F93E4 for ; Tue, 30 Jul 2013 02:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 lGSUL6R45780 for ; Tue, 30 Jul 2013 02:14:28 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 42E5621E80DE for ; Tue, 30 Jul 2013 02:08:26 -0700 (PDT) Received: from porto.nomis80.org (h194.viagenie.ca [206.123.31.194]) by jazz.viagenie.ca (Postfix) with ESMTPSA id C3BC740428 for ; Tue, 30 Jul 2013 05:08:24 -0400 (EDT) Message-ID: <51F78287.7070108@viagenie.ca> Date: Tue, 30 Jul 2013 11:08:23 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: behave@ietf.org References: <45A697A8FFD7CF48BCF2BE7E106F0604090E8DE5@xmb-rcd-x04.cisco.com> In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F0604090E8DE5@xmb-rcd-x04.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [BEHAVE] draft-meng-behave-napgt can be met by PCP port set X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 09:14:29 -0000 Le 2013-07-30 10:41, Reinaldo Penno (repenno) a crit : > Also possible with port set. +1 > It would be good to get your review of the > PCP port set draft since you have a concrete use-case. +1 Simon > Although port preservation could be achieved by PCP port-set, but how > can port-set > ensure the port remaining the same before and after the NAT translation? > That is the > behavior of port assignment of NAT and it is the very requirement of the > scenario. > > Thanks, > Wei -- 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 petithug@acm.org Tue Jul 30 03:53:51 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11B9811E810D for ; Tue, 30 Jul 2013 03:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=-0.105, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_RMML_Stock1=0.21] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id khQ8EB3VWs5O for ; Tue, 30 Jul 2013 03:53:50 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id CABE221F9D5C for ; Tue, 30 Jul 2013 03:53:45 -0700 (PDT) Received: from [IPv6:2001:df8:0:64:ca0a:a9ff:fe2e:a4f6] (unknown [IPv6:2001:df8:0:64:ca0a:a9ff:fe2e:a4f6]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 41C1E2021A; Tue, 30 Jul 2013 12:53:44 +0200 (CEST) Message-ID: <51F79B41.4020003@acm.org> Date: Tue, 30 Jul 2013 12:53:53 +0200 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130630 Icedove/17.0.7 MIME-Version: 1.0 To: "Prashanth Patil (praspati)" References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "behave@ietf.org" Subject: Re: [BEHAVE] Comments on the TURN REST Server API presentation X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 10:53:51 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 07/30/2013 08:49 AM, Prashanth Patil (praspati) wrote: > > > On 30/07/13 11:28 AM, "Simon Perreault" > wrote: > >> Le 2013-07-30 06:37, Marc Petit-Huguenin a écrit : >>> Second, I do not think that trying to overload the long-term >>> authentication mechanism is wise - and I take exceptions with the >>> previous presentation that characterized long-term authentication as >>> having problems. This is how long-term authentication works, and that >>> should be left alone. IMO what is needed is to design a third >>> authentication option for TURN (probably with new attributes) that is >>> doing the username/password stateless verification. Here there is a >>> need to define how the web server and the turn server can >>> generate/verify the same username/password, so an I-D is required to >>> ensure interoperability. >> >> After hearing the presentation and the discussion, that's the way I'm >> thinking too. I would expect that third option to not be >> username/password based, but rather token-based. > > Yes, a token based approach should be considered. A TURN server can then > also, more easily, cater to regular clients that want to use > username/password like they do today. > > The draft does not provide details on the mechanics of shared secret > exchange between the web-server and turn-server. The assumption is that > the two are always well known to each other, but that not may not be the > case always - a turn server should be able to fetch shared secret from a > previously unknown server, on demand. Also, what if multiple web-servers > want to avail the services of the same turn server? How does the turn > server know which shared secret to choose, realm maybe? Yes, I was talking with someone about that yesterday. We need two different ways to provision the shared key: - - In the model proposed by Justin, the key is manually shared between the TURN server and the Web server. This requires that the two servers are under the control of the same entity. - - A different model would be necessary when the TURN server is not directly controlled by the same entity that is controlling the Web server. That would require a protocol between the Web server and the TURN server so they agree on a common key (but also can rollover new keys). That would require a second I-D to define this protocol. - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iQIcBAEBCAAGBQJR95s8AAoJECnERZXWan7ERM0QAI6KuNDQFJ2BmRqhpKZ0ct/r CbESwBlnoxjQvKEnsSM6yyqx6xSbcKnULOgkhaKnyJ4YfEDHLetbNdUrDSWPHI1k AGOhV9riCI3OurikhrPfgA75UqfqunrjmT3bhsf3LgQMLaF9uL4cWlORmmX55Onz 1w/3hr1ETkcgnHMQMop1fSSdmh76vmtpj4WTIvJe5PXRa5HnLyLEharll3ICP6HM Gkp25HRz6apiHIiVg91ZA+RjzONmYDOc6WYYW7XXcIkHOtx5yKOUK/eCfNUfE56G QE5Jp5I6qxzz0lcrpCUT2BZhaXg8LbRsRgieIjnIRKkhIv+jEWVWqI3svTJzk+Zj BYOLWhJOancJT8WPbrXmfIipCurPEv7MhaoX+nSGEWAZJuCf1XRkFIeseFtMullx XtXKHZ9lIADZxW6z1Dd53NJzlNnyDEyKriPiPD5vTvCPp5dY5HYTCLufxvGsmLI+ yoNRaJl9wyVSMQFn8vSCGy1h/W5bV93+E1bLwfB1AqgQeZUgyK7DX4VZZSFDOwPX W2oQOOeHvUt7DBvj6hZHd+1CpeiyDhqmeqJZpct4qoHxUezgMCVmhB2BV2ypcNxw 2OPZ5OTY9jdcvXG0Q0oL73cB0M5PXMZdoJCQRuhhAT9ZiQchsktCYpIW0TcXusCW OHS7q8zuv+Zuu1wBtRVZ =DiAq -----END PGP SIGNATURE----- From ssenthil@cisco.com Tue Jul 30 07:37:03 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84F0221E80D8; Tue, 30 Jul 2013 07:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=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 Ui8LF2z6AdaO; Tue, 30 Jul 2013 07:36:56 -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 7336A21E80F5; Tue, 30 Jul 2013 07:36:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24947; q=dns/txt; s=iport; t=1375194997; x=1376404597; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=qrZFjJnmRmwYGm1SiBV4vPa+pQbRdoK/0XHQKpwHboQ=; b=aGvBsG2gkxlLi81tWp3GPHFv7Sqp2v045YFWAcE74e3Z+M1cytk8q/cy bZZFVVQLZrHS9pKqfyGBNLVFiw7OOd1HJhcmRrI0gqihgSuF1YkVeJglH fSOGztHhLCUehlCrZ6ngW8jCcNU+KeoNHjymulEKgWUdmfQTWpysUE/DK M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8FAOHO91GtJV2b/2dsb2JhbABbgkJENVC1VYg/gRwWdIIkAQEBAgEBAQEBawsFDQEIEQMBAQEBCh0uCxQJCAIEDgUIEYdxBgy5NY4sgSEgDQQHBgODD3EDmQiQI4MUgXE5 X-IronPort-AV: E=Sophos;i="4.89,778,1367971200"; d="scan'208,217";a="241119390" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 30 Jul 2013 14:36:30 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r6UEaUt0016122 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Jul 2013 14:36:30 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.80]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Tue, 30 Jul 2013 09:36:29 -0500 From: "Senthil Sivakumar (ssenthil)" To: "meng.wei2@zte.com.cn" Thread-Topic: [BEHAVE] NAPGT request for comments, THANKS! Thread-Index: AQHOjTIthhxgeWbMQkepK95HBDTyQQ== Date: Tue, 30 Jul 2013 14:36:28 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.117.198.132] Content-Type: multipart/alternative; boundary="_000_CB1B483277FEC94E9B58357040EE5D0232673A8Dxmbrcdx15ciscoc_" MIME-Version: 1.0 Cc: "Reinaldo Penno \(repenno\)" , "behave-bounces@ietf.org" , "behave@ietf.org" , "Dan Wing \(dwing\)" Subject: Re: [BEHAVE] NAPGT request for comments, THANKS! X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 14:37:03 -0000 --_000_CB1B483277FEC94E9B58357040EE5D0232673A8Dxmbrcdx15ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable What kind of a server is this? That requires to listen on contiguous ports?= Or is it a series of servers? Is this a real world use case? Thanks Senthil From: "meng.wei2@zte.com.cn" > Date: Monday, July 29, 2013 9:51 AM To: Senthil Sivakumar > Cc: "behave@ietf.org" >, "behave-bounces@ietf.org" >, "Dan Wing (dwing)" = >, "Reinaldo Penno (repenno)" > Subject: Re: Re: [BEHAVE] NAPGT request for comments, THANKS! Hi all, It's a pitty I got no comment after my presentation due to lack of meeting time. It is an important issue which small firms/family DIYers/... must face to when NAT has been deployed. They attempt to achieve accessing internal serv= er from external network environment without an extra public IP address. Are you interested in this topic? Please see the scenario in slides. http://tools.ietf.org/agenda/87/slid= es/slides-87-behave-4.pdf Thanks for comments. Cheers, Wei behave-bounces@ietf.org 2013/07/18 22:31:0= 0: > From: "meng.wei2@zte.com.cn" > > Date: Wednesday, July 17, 2013 9:19 PM > To: Senthil Sivakumar > > Cc: "behave@ietf.org" >, "behave-bounces@ietf.org" < > behave-bounces@ietf.org>, "Dan Wing (dwin= g)" >, > "Reinaldo Penno (repenno)" > > Subject: Re: Re: [BEHAVE] NAPGT request for comments, THANKS! > > > Hi, > Please see inline. > > Thanks, > Wei > > "Senthil Sivakumar (ssenthil)" > 2013-07-17 21:30:24: > > > From: "meng.wei2@zte.com.cn" > > > Date: Wednesday, July 17, 2013 4:08 AM > > To: "Reinaldo Penno (repenno)" > > > Cc: "behave-bounces@ietf.org" >, "behave@ietf.org" < > > behave@ietf.org>, "Dan Wing (dwing)" > > > Subject: Re: [BEHAVE] NAPGT request for comments, THANKS! > > > > > > Hi, > > I got what the example means. > > > > 1-1024 is just an example, the range could be any valid value. > > > > "<1-1024> might be used as NAT, <1025-65535> might be used as > > dynamic NAPT", example is as below. > > > > +----------+ +-----+ +--------+ > > + Internet + ----+ NAT +----+ Server + > > +----------+ +-----+ +--------+ > > > > (1) "<1-1024> might be used as NAT" means, > > A server behind a NAT. > > A message, sent by server, its source port is in 1-1024 (or > > 4500-4501 or ...). > > The source address will be converted by NAT, the source port remains > > the same. > > > > [Senthil] Sorry, I didn=92t read the draft, but the above logic wont > > work if there are multiple servers using the same source port. > > Also, in some applications (I think rcmd, rshell etc), the source > > port doesn=92t have to be preserved but must be below 1024. > > > > Senthil > > [Wei] I'm presenting the proposal so as to solve this problem : assign po= rt > x-y(i.e. 1-1024) to a server(for port preserving function, like NAT), ass= ign > the rest of ports to others(for common NAPT). > Of course, if there are many servers bebind NAT and whether or not usin= g > the same source port, NAT has to need more than one public address. > But in this case ,a server will never occupys all ports of a > public address, > just "x-y". > > [Senthil] I don=92t really understand what is the use case for this? > Can you provide a real life use case that would benefit by this? > What if the server listens on a port > 1024? Why would the server > multiple ports? Why cant a simple port forwarding work? > > Senthil > > Wei > > > > > > > > > (2)<1025-65535> might be used as dynamic NAPT > > Meanwhile, many hosts are behind NAT. They attempt to access to > > internet. > > A message, sent by a host, both its source address and port will > > be converted by NAT, and the new port will be in 1025-65535. > > > > > > It will make IP address assignment more effective. > > > > Cheers, > > Wei > > > > > > > > behave-bounces@ietf.org 2013-07-17 12:= 36:30: > > > > > Hi, > > > > > > I'm not sure what exactly you man by "might be used as NAT". > > > > > > 0-1024 might be used for NAPT in a FCFS basis where port > > > preservation (this is what we are talking about here, right?) is need= ed. > > > > > > As a concrete example, many IPsec Servers still expect to see the > > > source port within 0-1024 and preferably a specific source port. If > > > that source port is used by the NAT, and more than one IPsec client > > > is behind it, there are a some choices available. > > > > > > - Some funky IPSec ALG (implemented in many products) > > > - Give a port above 1024 and hope for the best > > > - Deny the connection > > > - others.. > > > > > > Other ports for the same public IP can be used by any other internal > > > IP address. This is very common in implementations. > > > > > > thanks, > > > > > > From: behave-bounces@ietf.org [behave= -bounces@ietf.org] on behalf of > > > meng.wei2@zte.com.cn [meng.wei2@zte.com.= cn] > > > Sent: Tuesday, July 16, 2013 8:22 PM > > > To: Reinaldo Penno (repenno) > > > Cc: behave-bounces@ietf.org; behave@i= etf.org; Dan Wing (dwing) > > > Subject: Re: [BEHAVE] NAPGT request for comments, THANKS! > > > > > > > > Hi Reinaldo, > > > So I suppose <1-1024> might be used as NAT, <1025-65535> might > be used as > > > dynamic NAPT. > > > That is what this view says in the draft. > > > > > > Cheers, > > > Wei > > > > > > > > > behave-bounces@ietf.org 2013-07-17 09= :52:34: > > > > > > > I'm not sure this is a good idea. There are still some protocols > > > > around that use ports < 1024 and maintaining the source port after > > > > translation in this range is important. > > > > > > > > From: behave-bounces@ietf.org [beha= ve-bounces@ietf.org] on behalf of > > > > Dan Wing (dwing) > > > > Sent: Tuesday, July 16, 2013 3:30 PM > > > > To: meng.wei2@zte.com.cn > > > > Cc: behave@ietf.org > > > > Subject: Re: [BEHAVE] NAPGT request for comments, THANKS! > > > > > > > > > > > On Jul 15, 2013, at 2:43 AM, meng.wei2@zte.com.cn wrote: > > > > > > > > I have submitted a new draft. The objective is to solve a > > problem that > > > > prevents an external client from accessing an internal server. > > > > > > > > https://datatracker.ietf.org/doc/draft-meng-behave-napgt/ > > > > > > > > I expect your comments. Thanks a lot! > > > > > > > > Draft-meng-behave-napgt appears to describe something that is very > > > > similar to the long-standing "DMZ host" configuration available on > > > > almost all residential-class NAT devices. I don't think we could > > > > standardize that behavior, but perhaps that is possible. > > > > > > > > Draft-meng-behave-napgt also describes an update to the port > > > > assignment behavior described in http://tools.ietf. > > > > org/html/rfc5382#section-7.1 (TCP) and http://tools.ietf. > > > > org/html/rfc4787#section-4.2.1 (UDP). If I understand Section 4 of > > > > draft-meng-behave-napgt properly, it is saying that NATs should not > > > > assign ports below 1024 to dynamic connections. This might be > > > > something worth considering for draft-ietf-behave-requirements-upda= te? > > > > > > > > -d > > > > _______________________________________________ > > > > Behave mailing list > > > > Behave@ietf.org > > > > https://www.ietf.org/mailman/listinfo/behave > > > _______________________________________________ > > > Behave mailing list > > > Behave@ietf.org > > > https://www.ietf.org/mailman/listinfo/behave > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave --_000_CB1B483277FEC94E9B58357040EE5D0232673A8Dxmbrcdx15ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <0CF1DE52B573C945A8D2DAFD8F991468@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
What kind of a server is this? That requires to listen on contiguous p= orts? Or is it a series of servers? 
Is this a real world use case?

Thanks
Senthil

From: "meng.wei2@zte.com.cn" <meng.wei2@zte.com.cn>
Date: Monday, July 29, 2013 9:51 AM=
To: Senthil Sivakumar <ssenthil@cisco.com>
Cc: "behave@ietf.org" <= behave@ietf.org>, "b= ehave-bounces@ietf.org" <behave-bounces@ietf.org>, "Dan Wing (dwing)" <dwing@= cisco.com>, "Reinaldo Penno (repenno)" <repenno@cisco.com>
Subject: Re: Re: [BEHAVE] NAPGT req= uest for comments, THANKS!


Hi all,
  It's a pitty I got no comment a= fter my presentation due to lack of
meeting time.
  It is an important issue which = small firms/family DIYers/... must face to
when NAT has been deployed. They attem= pt to achieve accessing internal server
from external network environment with= out an extra public IP address.

  Are you interested in this topi= c?

  Please see the scenario in slid= es.   http://tools.ietf.org/agenda/87/slides/slides-87-behave-4.pdf
Thanks for comments.

Cheers,
Wei
 


behave-boun= ces@ietf.org  2013/07/18 22:31:00:

> From: "meng.wei2@zte.com.= cn" <meng.wei2@zte.com.= cn>
> Date: Wednesday, July 17, 2013 9:19 PM
> To: Senthil Sivakumar <ssenth= il@cisco.com>
> Cc: "behave@ietf.org"= <behave@ietf.org>, "behave-bounces@ietf.org" &l= t;
> behave-bounces@ietf.org= >, "Dan Wing (dwing)" <d= wing@cisco.com>,
> "Reinaldo Penno (repenno)" <repenno@cisco.com>
> Subject: Re: Re: [BEHAVE] NAPGT request for comments, THANKS!
>
>
> Hi,
>   Please see inline.
>
> Thanks,
> Wei
>
> "Senthil Sivakumar (ssenthil)" <ssenthil@cisco.com>  2013-07-17 21:30:24:
>
> > From: "meng.wei2@zte= .com.cn" <meng.wei2@zte= .com.cn>
> > Date: Wednesday, July 17, 2013 4:08 AM
> > To: "Reinaldo Penno (repenno)" <repenno@cisco.com>
> > Cc: "behave-bounc= es@ietf.org" <behave= -bounces@ietf.org>, "behave@= ietf.org" <
> > behave@ietf.org>, "= ;Dan Wing (dwing)" <dwing@cisco.= com>
> > Subject: Re: [BEHAVE] NAPGT request for comments, THANKS!
> >
> >
> > Hi,
> >   I got what the example means.
> >
> >   1-1024 is just an example, the range could be any valid va= lue.
> >
> >   "<1-1024> might be used as NAT, <1025-65535&= gt; might be used as
> > dynamic NAPT", example is as below.
> >
> >    +----------+     +-----+ &= nbsp;  +--------+
> >    + Internet + ----+ NAT +----+ Se= rver +
> >    +----------+     +-----+ &= nbsp;  +--------+
> >
> >    (1) "<1-1024> might be used as NAT" = means,
> >        A server behind a NAT.
> >    A message, sent by server, its source port is in 1-1= 024 (or
> > 4500-4501 or ...).
> >    The source address will be converted by NAT, the sou= rce port remains
> >    the same.
> >
> > [Senthil] Sorry, I didn=92t read the draft, but the above logic w= ont
> > work if there are multiple servers using the same source port. > > Also, in some applications (I think rcmd, rshell etc), the source=
> > port doesn=92t have to be preserved but must be below 1024.
> >
> > Senthil
>
> [Wei] I'm presenting the proposal so as to solve this problem : assign= port
> x-y(i.e. 1-1024) to a server(for port preserving function, like NAT), = assign
> the rest of ports to others(for common NAPT).
>   Of course, if there are many servers bebind NAT and whether or = not using
> the same source port, NAT has to need more than one public address. >   But in this case ,a server will never occupys all ports of a > public address,
> just "x-y".
>
> [Senthil] I don=92t really understand what is the use case for this? <= br> > Can you provide a real life use case that would benefit by this?<= /font>
> What if the server listens on a port > 1024? W= hy would the server
> multiple ports? Why cant a simple port forwarding work? >
> Senthil
>
> Wei
>
> >
> >
> >
> >    (2)<1025-65535> might be used as dynamic NAPT =
> >        Meanwhile, many hosts are behind NAT. = They attempt to access to
> >     internet.
> >        A message, sent by a host, both its so= urce address and port will
> >     be converted by NAT, and the new port will be in 10= 25-65535.
> >
> >    
> > It will make IP address assignment more effective.
> >
> > Cheers,
> > Wei
> >
> >
> >
> > behave-bounces@ietf.or= g  2013-07-17 12:36:30:
> >
> > > Hi,
> > >
> > > I'm not sure what exactly you man by "might be used as = NAT".  
> > >
> > > 0-1024 might be used for NAPT in a FCFS basis where port > > > preservation (this is what we are talking about here, right?= ) is needed.
> > >
> > > As a concrete example, many IPsec Servers still expect to se= e the
> > > source port within 0-1024 and preferably a specific source p= ort. If
> > > that source port is used by the NAT, and more than one IPsec= client
> > > is behind it, there are a some choices available.
> > >
> > > - Some funky IPSec ALG (implemented in many products)
> > > - Give a port above 1024 and hope for the best
> > > - Deny the connection
> > > - others..
> > >
> > > Other ports for the same public IP can be used by any other = internal
> > > IP address. This is very common in implementations.
> > >
> > > thanks,
> > >
> > > From: behave-boun= ces@ietf.org [behave-bounces= @ietf.org] on behalf of
> > > meng.wei2@zte.com.cn= [meng.wei2@zte.com.cn]
> > > Sent: Tuesday, July 16, 2013 8:22 PM
> > > To: Reinaldo Penno (repenno)
> > > Cc: behave-bounce= s@ietf.org; behave@ietf.org; Dan Wing (dwing)
> > > Subject: Re: [BEHAVE] NAPGT request for comments, THANKS! > >
> > >
> > > Hi Reinaldo,
> > >   So I suppose <1-1024> might be used as NAT, <= ;1025-65535> might
> be used as
> > > dynamic NAPT.
> > >   That is what this view says in the draft.
> > >
> > > Cheers,
> > > Wei
> > >
> > >
> > > behave-bounces@ie= tf.org 2013-07-17 09:52:34:
> > >
> > > > I'm not sure this is a good idea. There are still some = protocols
> > > > around that use ports < 1024 and maintaining the sou= rce port after
> > > > translation in this range is important.
> > > >
> > > > From: behave= -bounces@ietf.org [behave-bo= unces@ietf.org] on behalf of
> > > > Dan Wing (dwing)
> > > > Sent: Tuesday, July 16, 2013 3:30 PM
> > > > To: meng.wei2@z= te.com.cn
> > > > Cc: behave@ietf.org<= /a>
> > > > Subject: Re: [BEHAVE] NAPGT request for comments, THANK= S!
> > >
> > > >
> > > > On Jul 15, 2013, at 2:43 AM, meng.wei2@zte.com.cn wrote:
> > > >
> > > >     I have submitted a new draft. The objecti= ve is to solve a
> > problem that
> > > >     prevents an external client from accessin= g an internal server.
> > > >
> > > >     https://datatracker.ietf.org/doc/draft-meng-be= have-napgt/
> > > >
> > > >     I expect your comments. Thanks a lot! > > > >
> > > > Draft-meng-behave-napgt appears to describe something t= hat is very
> > > > similar to the long-standing "DMZ host" confi= guration available on
> > > > almost all residential-class NAT devices.  I don't= think we could
> > > > standardize that behavior, but perhaps that is possible= .
> > > >
> > > > Draft-meng-behave-napgt also describes an update to the= port
> > > > assignment behavior described in http://tools.ietf.
> > > > org/html/rfc5382#section-7.1 (TCP) and http://tools.ietf.
> > > > org/html/rfc4787#section-4.2.1 (UDP).  If I unders= tand Section 4 of
> > > > draft-meng-behave-napgt properly, it is saying that NAT= s should not
> > > > assign ports below 1024 to dynamic connections.  T= his might be
> > > > something worth considering for draft-ietf-behave-requi= rements-update?
> > > >
> > > > -d
> > > > _______________________________________________
> > > > Behave mailing list
> > > > Behave@ietf.org<= br> > > > > https://www.ietf.org/mailman/listinfo/behave
> > > _______________________________________________
> > > Behave mailing list
> > > Behave@ietf.org
> > > htt= ps://www.ietf.org/mailman/listinfo/behave
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.i= etf.org/mailman/listinfo/behave
 --_000_CB1B483277FEC94E9B58357040EE5D0232673A8Dxmbrcdx15ciscoc_-- From xiechf01@gmail.com Tue Jul 30 08:22:01 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2F5221F9ADD for ; Tue, 30 Jul 2013 08:22:01 -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 jR-F0Ryo2eug for ; Tue, 30 Jul 2013 08:21:58 -0700 (PDT) Received: from mail-ee0-x22a.google.com (mail-ee0-x22a.google.com [IPv6:2a00:1450:4013:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 9C41E21E80C8 for ; Tue, 30 Jul 2013 08:21:50 -0700 (PDT) Received: by mail-ee0-f42.google.com with SMTP id b45so840947eek.15 for ; Tue, 30 Jul 2013 08:21:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:reply-to:subject:x-priority:x-has-attach:x-mailer :mime-version:message-id:content-type; bh=+PNY2tRpQzul/RadF/pcM4nFmkwR8PRtqRKJO/2NGmU=; b=wtEwsWbgEpV1m5aW4DbC+GhC061lMbSIjf1pUL7Y9ts0vPgzqr3tZ6wP8Z9YuEPhiN RBtseItmMBvVXzMZjmvSX19edCY2kXD0h3mCt60rLR1GDZ3tTFiCqx51Jd8RIBF336zV A0aQLNsW1wbuHZbJhX1tOmm1IwIK2T344MeZKHz7Nli754OV2yV/1bY+bzCGNkFQ1d+W BhFJsbrxCGluioqezha3vJvkU7FaiUJ4C5p55XYNE3ExBXA6CUKUrrJTJkACN6+DJUNG vPJfyfpYr4pA7vEebSKM6jXKfS4mH064DC/s/Zy6yL4+maLlFxwlhZOETZCoXCme5fkM z+Qw== X-Received: by 10.14.198.201 with SMTP id v49mr651567een.52.1375197710022; Tue, 30 Jul 2013 08:21:50 -0700 (PDT) Received: from xiechf-PC2 ([46.189.28.34]) by mx.google.com with ESMTPSA id ci50sm111332701eeb.12.2013.07.30.08.21.48 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 30 Jul 2013 08:21:49 -0700 (PDT) Date: Tue, 30 Jul 2013 17:21:45 +0200 From: xiechf01-Gmail To: behave X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.92[cn] Mime-Version: 1.0 Message-ID: <201307301721445003124@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart022525551504_=----" Subject: Re: [BEHAVE] Fwd: I-D Action: draft-sun-behave-v4tov6-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: xiechf01 List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 15:22:01 -0000 This is a multi-part message in MIME format. ------=_001_NextPart022525551504_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAgDQpIaSwNCg0KICAgICAgVGhlIHJlcXVpcmVtZW50cyBpbiBkcmFmdC1zdW4tYmVoYXZlLXY0 dG92Ni0wMCBvcmdpbmF0ZXMgZnJvbSB0aGUgcmVhbCBleHBlcmllbmNlIGFuZCBleHBlY3RhdGlv bnMgb2Ygb3VyIHByb2R1Y3QgbmV0d29yay4gIA0KDQogICAgICBSZWNlbnRseSwgSVB2NCBhZGRy ZXNzIHNob3J0YWdlIGJlZ2luIHRvIG9jY291ciBpbiBzb21lIGRhdGEgY2VudGVycywgYW5kIHdl IGd1ZXNzIHRoYXQgdGhpcyBzaXR1YXRpb24gd2lsbCBiZWNvbWUgd29yc2UgYXMgdGhlIGRheXMg cGFzcy4gIFNpbmNlIHRoZSBJUHY0IGFkZHJlc3Mgb3duZWQgYnkgYSBnaXZlbiBkYXRhIGNlbnRl ciBpcyBmaW5pdGUsIHNvIElQdjQgYWRkcmVzcyBpbiB0aGVpciBoYW5kcyB3aWxsIHJ1biBvdXQg c29vbiwgaXQgaXMgaW5ldml0YWJsZSB0aGF0IElQdjYtb25seSBzZXJ2ZXIgd2lsbCBhcGVhci4g RHVhbC1zdGFjayBzZXJ2aWNlcyB0byBuZXcgSUNQcyBpcyBiYXNlZCBvbiBzdWZmaWNpZW50IElQ djQgYWRkcmVzcyBwcm92aXNpb25naW5nLCBidXQgdGhpcyBpcyBub3QgdGhlIGZ1dHVyZSBmb3Ig bW9zdCBJRENzLiANCg0KICAgICAgIE9uIHRoZSBvdGhlciBzaWRlLCBhbHRob3VnaCBzb21lIG9w ZXJhdG9ycyBpbiB0aGUgd29ybGQgYmVnaW4gdG8gZGVwbG95IElQdjYgZm9yIHRoZWlyIGJyb2Fk YmFuZCB1c2VycywgYSBncmVhdCBwb3J0aW9uIG9mIHVzZXJzIHdvcmxkd2lkZSB3aWxsIHN0aWxs IGJlIElQdjQtb25seSBpbiB0aGUgbG9uZyBmdXR1cmUgZHVlIHRvIG1hbnkgd2VsbC1rbm93biBm YWN0b3JzLCAgd2UgY2FuIG5vdCBhc3N1bWUgdGhhdCBhbGwgdGhlIHVzZXJzIHdpbGwgYmVjb21l IGR1YWwtc3RhY2sgaW4gYSBzaG9ydCBwZXJpb2QuIFJpZ2h0IG5vdywgSVB2NiBwZW5lcmF0aW9u IGluIG1vc3QgcmVnaW9ucyBpcyBiZWxvdyAxMCUuDQoNCiAgICAgICBDb21iaW5nIHRoZSAyIGZh Y3RvcnMgdG9nZXRoZXIsIHdlIGRlZW0gaXQgaXMgbmVjZXNzYXJ5IHRvIHNvbHZlIDR0bzYgYWNl c3MgcHJvYmxlbSBkdXJpbmcgdGhlIGxvbmcgdHJhbnNpdGlvbiBwZXJpb2QuICAgDQoNCkNob25n ZmVuZw0KDQoNClRvOiAiYWpzIGF0IGFudmlsd2FscnVzZGVuLmNvbSIgPGFqcyBhdCBhbnZpbHdh bHJ1c2Rlbi5jb20+LCAiYmVoYXZlIGF0IGlldGYub3JnIiA8YmVoYXZlIGF0IGlldGYub3JnPiAN ClN1YmplY3Q6IFJlOiBbQkVIQVZFXSBGd2Q6IEktRCBBY3Rpb246IGRyYWZ0LXN1bi1iZWhhdmUt djR0b3Y2LTAwLnR4dCANCkZyb206IEJyYW5pbWlyIFJhanRhciA8QnJhbmltaXIuUmFqdGFyIGF0 IHQuaHQuaHI+IA0KRGF0ZTogVHVlLCAzMCBKdWwgMjAxMyAwODo0NjoxOSArMDAwMCANCkFjY2Vw dC1sYW5ndWFnZTogZW4tVVMgDQpEZWxpdmVyZWQtdG86IGJlaGF2ZSBhdCBpZXRmYS5hbXNsLmNv bSANCkluLXJlcGx5LXRvOiA8MjAxMzA3MzAwODA1MDQuR0E1MjU3NSBhdCBteDEueWl0dGVyLmlu Zm8+IA0KTGlzdC1hcmNoaXZlOiA8aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2Vi L2JlaGF2ZT4gDQpMaXN0LWhlbHA6IDxtYWlsdG86YmVoYXZlLXJlcXVlc3RAaWV0Zi5vcmc/c3Vi amVjdD1oZWxwPiANCkxpc3QtaWQ6IG1haWxpbmcgbGlzdCBvZiBCRUhBVkUgSUVURiBXRyA8YmVo YXZlLmlldGYub3JnPiANCkxpc3QtcG9zdDogPG1haWx0bzpiZWhhdmVAaWV0Zi5vcmc+IA0KTGlz dC1zdWJzY3JpYmU6IDxodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2JlaGF2 ZT4sIDxtYWlsdG86YmVoYXZlLXJlcXVlc3RAaWV0Zi5vcmc/c3ViamVjdD1zdWJzY3JpYmU+IA0K TGlzdC11bnN1YnNjcmliZTogPGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vb3B0aW9ucy9i ZWhhdmU+LCA8bWFpbHRvOmJlaGF2ZS1yZXF1ZXN0QGlldGYub3JnP3N1YmplY3Q9dW5zdWJzY3Jp YmU+IA0KUmVmZXJlbmNlczogPENBSDNiZkFCdE14WmtFeWhvQUFpaDVic0R6UDZIN0J6ek1yODho NlR4NitNMlNpcWJndyBhdCBtYWlsLmdtYWlsLmNvbT4gPENBS2NjNkFlcDdjS19EdD1DRnNRTTNG NUZuOE95OVVpMV85Z2Q3dTZfZDRwWU9kMU9aUSBhdCBtYWlsLmdtYWlsLmNvbT4gPENBSDNiZkFC MWRMdkJKMkZyTXZjN2JBTmNVc25lWl94Y09rX1JQSmFNa089UnJXbkdDQSBhdCBtYWlsLmdtYWls LmNvbT4gPDIwMTMwNzI5MTM0NjIzLkdENTE3MzcgYXQgbXgxLnlpdHRlci5pbmZvPiA8NTFGNjc0 RDAuMzA0MDYwMyBhdCB2aWFnZW5pZS5jYT4gPDIwMTMwNzI5MTQzOTEwLkdCNTE4MjMgYXQgbXgx LnlpdHRlci5pbmZvPiA8Q0FIM2JmQUMzQ2FzdXVkcFh5YjNYV09NeitUd1pVR2V5YV8xaD1qZDJN R1g0b0xNMFZnIGF0IG1haWwuZ21haWwuY29tPiwgPDIwMTMwNzMwMDgwNTA0LkdBNTI1NzUgYXQg bXgxLnlpdHRlci5pbmZvPiANClJlcGx5LXRvOiBCcmFuaW1pciBSYWp0YXIgPEJyYW5pbWlyLlJh anRhciBhdCB0Lmh0LmhyPiANClRocmVhZC1pbmRleDogQVFIT2pOQkg3S1puVmlVYnYwSzNFdDN6 YkxkUTNKbDh1OVlBZ0FBdER1cz0gDQpUaHJlYWQtdG9waWM6IFtCRUhBVkVdIEZ3ZDogSS1EIEFj dGlvbjogZHJhZnQtc3VuLWJlaGF2ZS12NHRvdjYtMDAudHh0IA0KDQoNCg0KSGksDQoNCllvdXIg YXJndW1lbnRhdGlvbiBzYXlzIHRoYXQgZXZlcnlib2R5IG5lZWRzIHRvIGhhdmUgSVB2NiBhY2Nl c3MgYW5kIEkgYWdyZWUgY29tcGxldGVseSB0aGF0IHdvdWxkIHNvbHZlIGFsbCBpc3N1ZXMuIEhv d2V2ZXIsIHdlIHdpbGwgbm90IGJlIGluIHRoYXQgcG9pbnQgb2YgdGltZSBmb3IgYXQgbGVhc3Qg Zml2ZSB5ZWFycy4gQW5kIEkgdGhpbmsgSSdtIG9wdGltaXN0aWMgLSBieSBsb29raW5nIGF0IHRo ZSBjdXJyZW50IElQdjYgZGVwbG95bWVudCBwZXJjZW50YWdlcywgaXQgbWlnaHQgYmUgbXVjaCBt b3JlLg0KDQpJU1BzIGFyZSBub3QgcmVhbGx5IGtlZW4gb24gZGVwbG95aW5nIElQdjYsIHRoZXkg cmF0aGVyIGRvIENHTi4gTkFUNDYgd291bGQgYmUgY2hlYXBlciBhbmQgd291bGQgcHJvdmlkZSBh IHJlYXNvbiBmb3Igc2VydmVycyB3aGljaCBhcmUgY3VycmVudGx5IElQdjQtb25seSB0byBzd2l0 Y2ggdG8gZHVhbC1zdGFjayBhbmQgZXZlbnR1YWxseSB0byBJUHY2LW9ubHkuDQoNCkkgdGhpbmsg d2UgY291bGQgZGlzY3VzcyB0aGlzIHRvcGljIGZvciB0aGUgbmV4dCBjb3VwbGUgb2Ygd2Vla3Mg KHdoaWNoIHdvdWxkIGJlIHF1aXRlIGRpZmZpY3VsdCBzaW5jZSBJJ20gd3JpdGluZyBmcm9tIG15 IHNtYXJ0cGhvbmUpIHNvIEkgc3VnZ2VzdCB0byBsZWF2ZSB0aGUgZGVjaXNpb24gb24gdGhlIHdv cmtpbmcgZ3JvdXAuDQoNCkJSLA0KQnJhbmltaXINCg0KDQoNCg0KLS0tLS0tLS0gSXp2b3JuYSBw b3J1a2EgLS0tLS0tLS0NCsOFYWxqZTogQW5kcmV3IFN1bGxpdmFuIDxhanMgYXQgYW52aWx3YWxy dXNkZW4uY29tPg0KRGF0dW06DQpUbzogYmVoYXZlIGF0IGlldGYub3JnDQpOYXNsb3Y6IFJlOiBb QkVIQVZFXSBGd2Q6IEktRCBBY3Rpb246IGRyYWZ0LXN1bi1iZWhhdmUtdjR0b3Y2LTAwLnR4dA0K DQoNCkhpLA0KDQpJJ20gYWxyZWFkeSB2aW9sYXRpbmcgbXkgdXN1YWwgcnVsZXMgYWJvdXQgb3Zl ci1wb3N0aW5nLCBzbyBJJ20gZ29pbmcNCnRvIGVuZGVhdm91ciB0byBzaHV0IHVwIGFmdGVyIHRo aXMuICBCdXQgdGhlcmUncyBhIHN1YnRsZSBidXQsIGluIG15DQpvcGluaW9uLCBtaXN0YWtlbiBw YXJhbGxlbGlzbSBoZXJlLCBhbmQgSSB3YW50IHRvIGNoYWxsZW5nZSBpdC4NCg0KT24gVHVlLCBK dWwgMzAsIDIwMTMgYXQgMTA6NTU6NDJBTSArMDgwMCwgUWlvbmcgd3JvdGU6DQoNCj4gRm9yIGV4 YW1wbGUsIHdlIG5vdyBoYXZlIE5BVDY0IGFuZCBzbyB2Ni1vbmx5IGNsaWVudCBjYW4gZW1lcmdl IGFuZCB0YWxrIHRvDQo+IHY0IHNlcnZlci4gU28gdjYtb25seSBjbGllbnRzIG1heSBiZSBtb3Jl IGFuZCBtb3JlIGluIHRoZSBmdXR1cmUuIEkgc2VlDQo+IG5vYm9keSBhcmd1ZXMgdGhhdCBpZiB3 ZSBoYXZlIE5BVDY0LCB2NCBzZXJ2ZXIgbWF5IGxpdmUgaW4gdjQgZm9yZXZlci4NCj4NCj4gVGhl biBmb3IgdjQtdG8tdjYgc2NlbmFyaW8sIHRoaXMgaXMgdGhlIHNhbWUgc2luY2UgaXQgd2lsbCBi cmluZyB0aGUNCj4gYWJpbGl0eSB0byBzdXBwb3J0IHY2LW9ubHkgc2VydmVyIHRvIGJlIHJlYWNo YWJsZSBieSB2NC1vbmx5IGNsaWVudHMuDQo+IFRoZXJlZm9yZSwgdjYtb25seSBzZXJ2ZXIgbWF5 IGVtZXJnZSBiZWNhdXNlIHRoZXkgZG8gbm90IG5lZWQgdG8gd29ycnkNCj4gYWJvdXQgbG9zaW5n IHY0IGNsaWVudHMuIFNvIHY2LW9ubHkgc2VydmVyIG1heWJlIG1vcmUgYW5kIG1vcmUgaW4gdGhl DQo+IGZ1dHVyZS4gVGhpcyB3aWxsIHByb21vdGUgdjYtZGV2ZWxvcG1lbnQsIHJhdGhlciB0aGFu IHRoZSBvcHBvc2l0ZSBvbmUuDQoNClRoZSBrZXkgcmVhc29uIHRvIGhhdmUgZGVmaW5lZCBOQVQ2 NCB3YXMgYmVjYXVzZSB3ZSBoYWQgYSBzdXBwbHkNCnByb2JsZW0uICBJZiB5b3Ugd2VyZSBhIHY2 LW9ubHkgbm9kZSwgeW91IGNvdWxkbid0IHJlYWNoIHNlcnZlcnMgb24NCnRoZSB2NCBJbnRlcm5l dC4gIEJ1dCBfbW9zdF8gdGhpbmdzIHdlcmUgb24gdGhlIHY0IEludGVybmV0LiAgU28gTkFUNjQN CmdhdmUgdXMgYSB3YXkgb2YgcGVybWl0dGluZyBwZW9wbGUgdG8gaGF2ZSB2Ni1vbmx5IGNvbm5l Y3Rpdml0eQ0Kd2l0aG91dCBwYXlpbmcgdGhlIGNvc3Qgb2YgbG9zaW5nIGFjY2VzcyB0byB0aGUg ZW50aXJlIEludGVybmV0Lg0KDQpUaGUgYXJndW1lbnQgYWJvdmUgdHVybnMgdGhpcyBvbiBpdHMg aGVhZCwgYW5kIHNheXMgdGhhdCBpZiB5b3UgYXJlDQpzdGFuZGluZyB1cCBhIHNlcnZpY2UsIHlv dSBhcmUgd29ycmllZCBhYm91dCBsb3NpbmcgdGhlIHBvc3NpYmxlDQpjdXN0b21lcnMgb24gdjQt b25seSBuZXR3b3Jrcy4gIFRoZXJlZm9yZSwgeW91IHdpbGwgZ28gZHVhbCBzdGFjay4NCkltcGxp Y2l0bHksIGlmIHdlIHNheSwgIk5ldyB2NCBzZXJ2aWNlIGJhZCwiIHdlIHRoaW5rIGl0IHdvdWxk IGJlDQpiZXR0ZXIgdGhhdCB0aGUgc2VydmljZSBiZSB2Ni1vbmx5LiAgU28sIHdlIHNob3VsZCBo YXZlIGEgbWVjaGFuaXNtIGJ5DQp3aGljaCB2NC1vbmx5IGNsaWVudHMgY2FuIGFjY2VzcyB0aGUg djYgSW50ZXJuZXQsIGFuZCB0aGlzIHdpbGwgaW4NCnNvbWUgc2Vuc2UgaW5jcmVhc2UgdjYgdXNl IGJlY2F1c2UgdGhlIHNlcnZpY2UgaXMgYWN0dWFsbHkgYWNjZXNzZWQNCm92ZXIgdjYuDQoNCkkg dGhpbmsgdGhlIGFyZ3VtZW50IGlzIHN1YnRsZSBidXQgd3JvbmcuICBGaXJzdCwgaXQgZGVwZW5k cyBvbiB0aGUNCnByZW1pc2UgdGhhdCB0aGVyZSBpcyBhbiBpbnRlcmVzdGluZyBwb3B1bGF0aW9u IHRoYXQgd2lsbA0KKGVjb25vbWljYWxseSkgcmVtYWluIHY0LW9ubHkgd2hpbGUgdjYtb25seSBz ZXJ2aWNlIGRlcGxveW1lbnQgaXMgaW4NCnNvbWUgc2Vuc2UgKGxpa2VseSBlY29ub21pY2FsbHkp IGEgcmVhc29uYWJsZSBwbGFuLiAgQXMgSSBhbHJlYWR5DQphcmd1ZWQgZWxzZXdoZXJlIGluIHRo aXMgdGhyZWFkLCB0aGF0IHByZW1pc2UgbmVlZHMgYSBsb3Qgb2YNCnN1cHBvcnRpbmcgYXJndW1l bnQsIGJlY2F1c2UgaXQgc2VlbXMgdG8gbWUgdG8gYmUgZmFsc2UuICBTZWNvbmQsIGl0DQpjb25m dXNlcyB0aGUgZ29hbCBvZiBJUHY2IGRlcGxveW1lbnQgaW4gdGhlIHNlbnNlIG9mIG5hdGl2ZSB1 c2Ugd2l0aCBhDQpzdXBwb3NlZCBnb2FsIG9mIG1lcmVseSBjYXJyeWluZyB0cmFmZmljIG92ZXIg djYuICBUaGUgbGF0dGVyIGlzIG5vdA0KYW4gaW50ZXJlc3RpbmcgZ29hbCBpbiBhbnkgc2Vuc2U6 IGlmIHRvbW9ycm93IHdlIHNpbXBseSBlbmNhcHN1bGF0ZWQNCmFsbCB2NCB0cmFmZmljIGluc2lk ZSB2NiwgSSBkbyBub3QgdGhpbmsgaXQgd291bGQgYmUgYW4gaW50ZXJlc3RpbmcNCmFkdmFuY2Ug aW4gdjYgZGVwbG95bWVudC4gIFNvIEkgcmVqZWN0IHRoZSBjbGFpbSB0aGF0IHRoaXMgc29ydCBv Zg0KNC10by02IE5BVCBpcyBhIHBvc2l0aXZlIGNvbnRyaWJ1dG9yIHRvIElQdjYgZGVwbG95bWVu dC4gIFRoZSByaWdodA0KbWVzc2FnZSBpcywgIklmIHlvdSB3YW50IHRvIHJlYWNoIHRoaXMgdjYt b25seSBzZXJ2aWNlLCBnZXQgYSB2Ng0KYWRkcmVzcy4iICBJZiB0aGUgc2VydmljZSBpcyB2YWx1 YWJsZSwgdGhlIGN1c3RvbWVycyB3aWxsIGNvbWUsIHNpbmNlDQp2NiBjb21tdW5pY2F0aW9ucyBh cmUgbm8gbG9uZ2VyIGFuIGVub3Jtb3VzIGJpZyBkZWFsLg0KDQpBcyBmb3IgdGhlIHJpc2sgdGhh dCBkdWFsIHN0YWNrIGV2ZXJ5d2hlcmUgcGVybWl0cyB2NCB0byBwZXJzaXN0OiBzbw0Kd2hhdD8g IElmIHY2IGlzIHdvcmtpbmcgZXZlcnl3aGVyZSwgdGhlbiB0aGUgdjQgbmV0d29yayB3aWxsIGdy YWR1YWxseQ0Kd2l0aGVyIGF3YXkgYmVjYXVzZSBpdCBpcyBub3QgZWNvbm9taWNhbCB0byBrZWVw IHRoYXQgbmV0d29yaw0KaW50ZXJmYWNlIGFjdGl2ZS4gIChMZWUgSG93YXJkIGhhcyBkb25lIGlu dGVyZXN0aW5nIGFuYWx5c2lzIGluIHRoaXMNCmFyZWEsIGFuZCBoaXMgbW9kZWxzIGF0IGxlYXN0 IHN1Z2dlc3QgYSBwcmV0dHkgc2lnbmlmaWNhbnQgY2hhbmdlb3Zlcg0KaW5jZW50aXZlIG9uY2Ug YSBub3QgdmVyeSBsYXJnZSBudW1iZXIgb2Ygc2VydmljZXMgY29tZSB1cCBvbiBJUHY2LikNClRo ZSBnb2FsIGlzIG5vdCB0byBtYWtlIHRoZSBldmlsLCBiYWQsIHdyb25nIHY0IGdvIGF3YXksIGFu eSBtb3JlIHRoYW4NCnRoZSBnb2FsIHdhcyBpbiBpdHNlbGYgdG8ga2lsbCBYLjI1IGFuZCBkYW5j ZSBhYm91dCBvbiBpdHMgZ3JhdmUNCnNpbmdpbmcgaGFsbGVsdWphaC4gIFRoYXQgd2FzIGp1c3Qg YSBoYXBweSBjb25zZXF1ZW5jZS4NCg0KPiBGcm9tIHRoZSBsb25nIGhpc3Rvcnkgb2YgSVB2NiBk ZXZlbG9wbWVudCwgSSB0aGluayBpdCBpcyBjbGVhciB0aGlzDQo+IGFzc3VtcHRpb24gaGFzIG5l dmVyIGhhcmRseSBleGlzdGVkLiBJZiBhbnlvbmUgKm91Z2h0IHRvIGJlIGFibGUgdG8gZ2V0IGEN Cj4gdjYgYWRkcmVzcyosIHdlIHdvdWxkIGhhdmUgcmVhY2hlZCB0aGUgdjYtd29ybGQgbG9uZyBh Z28sIHJhdGhlciB0aGFuDQo+IGRlYmF0aW5nIGhvdyB0byB0cmFuc2l0Lg0KDQpTdXJlbHkgbm90 LiAgVjYgZGVwbG95bWVudCBoYXMgbmV2ZXIgYmVlbiBpbXBlZGVkIGJ5IGxhY2sgb2YgdjYNCmFk ZHJlc3Nlcy4gIEFzIGxvbmcgYXMgdjQgd2FzIGdvb2QgZW5vdWdoIGFuZCBpdCB3YXMgc3RpbGwg cG9zc2libGUgdG8NCmdldCBhZGRyZXNzIHNwYWNlIGZvciByZWFzb25hYmxlIGNvc3QsIHRoZXJl IHdhcyBsaXR0bGUgaW5jZW50aXZlIHRvDQptb3ZlIHRvIGEgbmV0d29yayB0ZWNobm9sb2d5IHRo YXQgc2VlbWVkIGxpa2UgaXQgd2FzIHN0aWxsIHVuZGVyDQpkZXZlbG9wbWVudC4gIEJ1dCB3ZSdy ZSBvdXQgb2YgdjQgYWRkcmVzc2VzIG5vdywgdGhlIGV4cGVyaWVuY2UgaXMNCl9ub3RfIGdvb2Qg ZW5vdWdoLCBhbmQgc28gb25lIG1pZ2h0IHN1cHBvc2UgdGhlIGluY2VudGl2ZXMgaGF2ZSBjaGFu Z2VkLg0KDQpCZXN0LA0KDQpBDQoNCi0tDQpBbmRyZXcgU3VsbGl2YW4NCmFqcyBhdCBhbnZpbHdh bHJ1c2Rlbi5jb20NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpCZWhhdmUgbWFpbGluZyBsaXN0DQpCZWhhdmUgYXQgaWV0Zi5vcmcNCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYmVoYXZlDQoNCg0KPEhUTUw+PFA+PEZPTlQgZmFj ZT1BcmlhbCBjb2xvcj0jOTk5OTk5IHNpemU9MT4NCg0KSVpKQVZBIE8gT0RSSUNBTkpVIE9ER09W T1JOT1NUSTogU2FkcsOFYWogb3ZlIHBvcnVrZSBpIGV2ZW50dWFsbm8gcHJpbG/DhWVuaWggZGF0 b3Rla2EgamUgcG92amVybGppdiBpIG5hbWlqZW5qZW4gamUgc2FtbyBvc29iYW1hIGlsaSBzdWJq ZWt0aW1hIGtvamkgc3UgbmF2ZWRlbmkgdSBhZHJlc2kuIFVrb2xpa28gc3RlIHByaW1pbGkgb3Z1 IHBvcnVrdSBncmXDhWtvbSwgbW9saW1vIFZhcywgb2JhdmlqZXN0aXRlIHBvw4VpbGphdGVsamEs IGEgcG9ydWt1IGkgc3ZlIG5qZW5lIHByaXZpdGtlIG9kbWFoLCBiZXogw4RpdGFuamEsIHRyYWpu byB1a2xvbml0ZSBzIHJhw4R1bmFsYS4gQmlsbyBrYWt2byBwcmVub8OFZW5qZSwga29waXJhbmpl IGlsaSBkaXN0cmlidWNpamEgaW5mb3JtYWNpamEgc2FkcsOFYW5paCB1IHBvcnVjaSB0cmXDhGlt IG9zb2JhbWEgamUgemFicmFuamVubyBpIG1vw4VlIGJpdGkgemFrb25za2kga2HDhW5qaXZvLiBT YWRyw4Vhaiwgc3Rhdm92aSBpIG1pw4VsamVuamEgaXpuZXNlbmkgdSBwb3J1Y2kgc3UgYXV0b3Jv dmkgaSBuZSBwcmVkc3RhdmxqYWp1IG51w4VubyBzdGF2b3ZlIEhUIC0gSHJ2YXRza2loIHRlbGVr b211bmlrYWNpamEgZC5kLiBIVCBuZSBwcmlodmHDhGEgbmlrYWt2dSBvZGdvdm9ybm9zdCB6YSBl dmVudHVhbG51IMOFdGV0dSBuYXN0YWx1IHByaW1pdGtvbSBvdmUgcG9ydWtlIGkgcHJpbG9nYSBz YWRyw4VhbmloIHUgcG9ydWNpLg0KDQo8L0ZPTlQ+PC9QPjxQPjxGT05UIGZhY2U9QXJpYWwgY29s b3I9Izk5OTk5OSBzaXplPTE+DQoNCiBESVNDTEFJTUVSOlRoZSBjb250ZW50cyBvZiB0aGlzIGVt YWlsIGFzIHdlbGwgYXMgYW55IGZpbGVzIGF0dGFjaGVkIHRvIGl0IGFyZSBjb25maWRlbnRpYWwg YW5kIGludGVuZGVkIHNvbGVseSBmb3IgaW5kaXZpZHVhbHMgb3IgZW50aXRpZXMgd2hpY2ggdGhl eSBhcmUgYWRkcmVzc2VkIHRvLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIG1lc3Nh Z2UgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgcGVybWFuZW50bHkgcmVt b3ZlIHRoZSBtZXNzYWdlIGFuZCBhbGwgYXR0YWNoZWQgZmlsZXMgZnJvbSB0aGUgY29tcHV0ZXIu IEFueSBkaXNjbG9zdXJlLCBjb3B5aW5nIG9yIGRpc3RyaWJ1dGlvbiBvZiBhbGwgb3IgYSBwYXJ0 IG9mIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gdG8gb3IgYnkgdGhpcmQgcGFydGllcyBp cyBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIFBsZWFzZSBub3RlIHRoYXQgYW55IHZp ZXdzIG9yIG9waW5pb25zIHByZXNlbnRlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHNvbGVseSB0aG9z ZSBvZiB0aGUgYXV0aG9yIGFuZCBkbyBub3QgbmVjZXNzYXJpbHkgcmVwcmVzZW50IHRoZSB2aWV3 cyBhbmQgb3BpbmlvbnMgb2YgQ3JvYXRpYW4gVGVsZWNvbSBJbmMuIENyb2F0aWFuIFRlbGVjb20g SW5jLiBhY2NlcHRzIG5vIGxpYWJpbGl0eSBmb3IgYW55IHBvdGVudGlhbCBkYW1hZ2UgY2F1c2Vk IGJ5IHRoaXMgbWVzc2FnZSBhbmQgZmlsZXMgYXR0YWNoZWQgdG8gaXQuDQoNCjwvRk9OVD48L1A+ PC9IVE1MPg0KDQoNCg0KDQpSZWZlcmVuY2VzOiANCltCRUhBVkVdIEZ3ZDogSS1EIEFjdGlvbjog ZHJhZnQtc3VuLWJlaGF2ZS12NHRvdjYtMDAudHh0IA0KRnJvbTogUWlvbmcNClJlOiBbQkVIQVZF XSBGd2Q6IEktRCBBY3Rpb246IGRyYWZ0LXN1bi1iZWhhdmUtdjR0b3Y2LTAwLnR4dCANCkZyb206 IExpdSBEYXBlbmcNClJlOiBbQkVIQVZFXSBGd2Q6IEktRCBBY3Rpb246IGRyYWZ0LXN1bi1iZWhh dmUtdjR0b3Y2LTAwLnR4dCANCkZyb206IFFpb25nDQpSZTogW0JFSEFWRV0gRndkOiBJLUQgQWN0 aW9uOiBkcmFmdC1zdW4tYmVoYXZlLXY0dG92Ni0wMC50eHQgDQpGcm9tOiBBbmRyZXcgU3VsbGl2 YW4NClJlOiBbQkVIQVZFXSBGd2Q6IEktRCBBY3Rpb246IGRyYWZ0LXN1bi1iZWhhdmUtdjR0b3Y2 LTAwLnR4dCANCkZyb206IFNpbW9uIFBlcnJlYXVsdA0KUmU6IFtCRUhBVkVdIEZ3ZDogSS1EIEFj dGlvbjogZHJhZnQtc3VuLWJlaGF2ZS12NHRvdjYtMDAudHh0IA0KRnJvbTogQW5kcmV3IFN1bGxp dmFuDQpSZTogW0JFSEFWRV0gRndkOiBJLUQgQWN0aW9uOiBkcmFmdC1zdW4tYmVoYXZlLXY0dG92 Ni0wMC50eHQgDQpGcm9tOiBRaW9uZw0KUmU6IFtCRUhBVkVdIEZ3ZDogSS1EIEFjdGlvbjogZHJh ZnQtc3VuLWJlaGF2ZS12NHRvdjYtMDAudHh0IA0KRnJvbTogQW5kcmV3IFN1bGxpdmFuDQpQcmV2 IGJ5IERhdGU6IFJlOiBbQkVIQVZFXSBkcmFmdC1tZW5nLWJlaGF2ZS1uYXBndCBjYW4gYmUgbWV0 IGJ5IFBDUCBwb3J0IHNldCANCk5leHQgYnkgRGF0ZTogUmU6IFtCRUhBVkVdIGRyYWZ0LW1lbmct YmVoYXZlLW5hcGd0IGNhbiBiZSBtZXQgYnkgUENQIHBvcnQgc2V0IA0KUHJldmlvdXMgYnkgdGhy ZWFkOiBSZTogW0JFSEFWRV0gRndkOiBJLUQgQWN0aW9uOiBkcmFmdC1zdW4tYmVoYXZlLXY0dG92 Ni0wMC50eHQgDQpOZXh0IGJ5IHRocmVhZDogUmU6IFtCRUhBVkVdIEZ3ZDogSS1EIEFjdGlvbjog ZHJhZnQtc3VuLWJlaGF2ZS12NHRvdjYtMDAudHh0IA0KSW5kZXgoZXMpOiANCkRhdGUgDQpUaHJl YWQgDQpOb3RlOiBNZXNzYWdlcyBzZW50IHRvIHRoaXMgbGlzdCBhcmUgdGhlIG9waW5pb25zIG9m IHRoZSBzZW5kZXJzIGFuZCBkbyBub3QgaW1wbHkgZW5kb3JzZW1lbnQgDQoNCg0KDQoNCnhpZWNo ZjAxLUdtYWls ------=_001_NextPart022525551504_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
   
Hi,
 
      The=20 requirements in draft-sun-behave-v4tov6-00 orginates f= rom the real experience and expectations of&= nbsp;our product network.  
 
      Recently,=20 IPv4 address shortage begin to occour in&nbs= p;some data centers, and we guess that = this situation will become worse as the = ;days pass. =20 Since the IPv4 address owned by a given=  data center is finite, so IPv4 address=  in their hands will run out soon, = ;it is inevitable that IPv6-only server will=  apear. Dual-stack services to new=20 ICPs is based on sufficient IPv4 address&nbs= p;provisionging, but this is not the=20 future for most IDCs. 
 
      =20 On the other side, although some operators&n= bsp;in the world begin to deploy IPv6 f= or their broadband users, a great portion&nb= sp;of users worldwide will still be IPv4-only in the&nbs= p;long future due to many well-known factors= , =20 we can not assume that all the users&nb= sp;will become dual-stack in a short period.= =20 Right now, IPv6 peneration in most regions is below 10%.
 
    =20   Combing the 2 factors together, we&nb= sp;deem it is necessary to solve 4to6 a= cess problem during the long transition peri= od.   
 
Chongfeng
 
 
  • To: "ajs at=20 anvilwalrusden.com" <ajs at=20 anvilwalrusden.com>, "beh= ave at=20 ietf.org" <behave at=20 ietf.org>=20
  • Subject: Re: [BEHAVE] Fwd: I-D Action:=20 draft-sun-behave-v4tov6-00.txt=20
  • From: Branimir Rajtar <Branimir.Rajtar at t.ht.hr= >=20
  • Date: Tue, 30 Jul 2013 08:46:19 +0000=20
  • Accept-language: en-US=20
  • Delivered-to: behav= e at=20 ietfa.amsl.com=20
  • In-reply-to: <20130730080504.GA52= 575 at=20 mx1.yitter.info>=20
  • List-archive: <http://www.ietf.org= /mail-archive/web/behave>=20
  • List-help: <mailto:behave-req= uest@ietf.org?subject=3Dhelp>=20
  • List-id: mailing list of BEHAVE IETF WG <behave.ietf.org= >=20
  • List-post: <mailto:behave@ietf.org>=20
  • List-subscribe: <https://www.ietf.o= rg/mailman/listinfo/behave>,=20 <mailto:behav= e-request@ietf.org?subject=3Dsubscribe>=20
  • List-unsubscribe: <https://www.ietf.or= g/mailman/options/behave>,=20 <mailto:beh= ave-request@ietf.org?subject=3Dunsubscribe>=20
  • References: <CAH3bfABtMxZkEyhoAAih5bsDzP6H7BzzMr88h6Tx6+M2Siqbgw=20 at mail.gmail.com> <CAKcc6Aep7cK_Dt=3DCFsQM3F5Fn8Oy9Ui1_9gd7u6_d4pYOd1OZQ=20 at mail.gmail.com> <CAH3bfAB1dLvBJ2FrMvc7bANcUsneZ_xcOk_RPJaMkO=3DRrWnGCA=20 at mail.gmail.com> <20130729134623.GD51= 737 at=20 mx1.yitter.info> <51F674D0.3040603 at=20 viagenie.ca> <20130729143910.GB51= 823 at=20 mx1.yitter.info> <CAH3bfAC3CasuudpXyb3XWOMz+TwZUGeya_1h=3Djd2MGX4oLM0Vg=20 at mail.gmail.com>, <20130730080504.GA52= 575 at=20 mx1.yitter.info>=20
  • Reply-to: Branimir Rajtar <Branimir.Rajtar at t.ht.hr= >=20
  • Thread-index: AQHOjNBH7KZnViUbv0K3Et3zbLdQ3Jl8u9YAgAAtDus= =3D=20
  • Thread-topic: [BEHAVE] Fwd: I-D Action:=20 draft-sun-behave-v4tov6-00.txt 
Hi,

Your argumentation says that everybody needs to have IPv6 access and I agr=
ee completely that would solve all issues. However, we will not be in that=
 point of time for at least five years. And I think I'm optimistic - by lo=
oking at the current IPv6 deployment percentages, it might be much more.

ISPs are not really keen on deploying IPv6, they rather do CGN. NAT46 woul=
d be cheaper and would provide a reason for servers which are currently IP=
v4-only to switch to dual-stack and eventually to IPv6-only.

I think we could discuss this topic for the next couple of weeks (which wo=
uld be quite difficult since I'm writing from my smartphone) so I suggest =
to leave the decision on the working group.

BR,
Branimir




-------- Izvorna poruka --------
=C3=85alje: Andrew Sullivan <ajs at anvilwalrusden.com>
Datum:
To: behave at ietf.org
Naslov: Re: [BEHAVE] Fwd: I-D Action: draft-sun-behave-v4tov6-00.txt


Hi,

I'm already violating my usual rules about over-posting, so I'm going
to endeavour to shut up after this.  But there's a subtle but, in my
opinion, mistaken parallelism here, and I want to challenge it.

On Tue, Jul 30, 2013 at 10:55:42AM +0800, Qiong wrote:

> For example, we now have NAT64 and so v6-only client can emerge and t=
alk to
> v4 server. So v6-only clients may be more and more in the future. I s=
ee
> nobody argues that if we have NAT64, v4 server may live in v4 forever=
.
>
> Then for v4-to-v6 scenario, this is the same since it will bring the
> ability to support v6-only server to be reachable by v4-only clients.
> Therefore, v6-only server may emerge because they do not need to worr=
y
> about losing v4 clients. So v6-only server maybe more and more in the
> future. This will promote v6-development, rather than the opposite on=
e.

The key reason to have defined NAT64 was because we had a supply
problem.  If you were a v6-only node, you couldn't reach servers on
the v4 Internet.  But _most_ things were on the v4 Internet.  So NAT64
gave us a way of permitting people to have v6-only connectivity
without paying the cost of losing access to the entire Internet.

The argument above turns this on its head, and says that if you are
standing up a service, you are worried about losing the possible
customers on v4-only networks.  Therefore, you will go dual stack.
Implicitly, if we say, "New v4 service bad," we think it would be
better that the service be v6-only.  So, we should have a mechanism by
which v4-only clients can access the v6 Internet, and this will in
some sense increase v6 use because the service is actually accessed
over v6.

I think the argument is subtle but wrong.  First, it depends on the
premise that there is an interesting population that will
(economically) remain v4-only while v6-only service deployment is in
some sense (likely economically) a reasonable plan.  As I already
argued elsewhere in this thread, that premise needs a lot of
supporting argument, because it seems to me to be false.  Second, it
confuses the goal of IPv6 deployment in the sense of native use with a
supposed goal of merely carrying traffic over v6.  The latter is not
an interesting goal in any sense: if tomorrow we simply encapsulated
all v4 traffic inside v6, I do not think it would be an interesting
advance in v6 deployment.  So I reject the claim that this sort of
4-to-6 NAT is a positive contributor to IPv6 deployment.  The right
message is, "If you want to reach this v6-only service, get a v6
address."  If the service is valuable, the customers will come, since
v6 communications are no longer an enormous big deal.

As for the risk that dual stack everywhere permits v4 to persist: so
what?  If v6 is working everywhere, then the v4 network will gradually
wither away because it is not economical to keep that network
interface active.  (Lee Howard has done interesting analysis in this
area, and his models at least suggest a pretty significant changeover
incentive once a not very large number of services come up on IPv6.)
The goal is not to make the evil, bad, wrong v4 go away, any more than
the goal was in itself to kill X.25 and dance about on its grave
singing hallelujah.  That was just a happy consequence.

> From the long history of IPv6 development, I think it is clear this
> assumption has never hardly existed. If anyone *ought to be able to g=
et a
> v6 address*, we would have reached the v6-world long ago, rather than
> debating how to transit.

Surely not.  V6 deployment has never been impeded by lack of v6
addresses.  As long as v4 was good enough and it was still possible to
get address space for reasonable cost, there was little incentive to
move to a network technology that seemed like it was still under
development.  But we're out of v4 addresses now, the experience is
_not_ good enough, and so one might suppose the incentives have changed.

Best,

A

--
Andrew Sullivan
ajs at anvilwalrusden.com
_______________________________________________
Behave mailing list
Behave at ietf.org
ht=
tps://www.ietf.org/mailman/listinfo/behave


<HTML><P><FONT face=3DArial color=3D#999999 size=3D1>

IZJAVA O ODRICANJU ODGOVORNOSTI: Sadr=C3=85aj ove poruke i eventualno pril=
o=C3=85enih datoteka je povjerljiv i namijenjen je samo osobama ili subjek=
tima koji su navedeni u adresi. Ukoliko ste primili ovu poruku gre=C3=85ko=
m, molimo Vas, obavijestite po=C3=85iljatelja, a poruku i sve njene privit=
ke odmah, bez =C3=84itanja, trajno uklonite s ra=C3=84unala. Bilo kakvo pr=
eno=C3=85enje, kopiranje ili distribucija informacija sadr=C3=85anih u por=
uci tre=C3=84im osobama je zabranjeno i mo=C3=85e biti zakonski ka=C3=85nj=
ivo. Sadr=C3=85aj, stavovi i mi=C3=85ljenja izneseni u poruci su autorovi =
i ne predstavljaju nu=C3=85no stavove HT - Hrvatskih telekomunikacija d.d.=
 HT ne prihva=C3=84a nikakvu odgovornost za eventualnu =C3=85tetu nastalu =
primitkom ove poruke i priloga sadr=C3=85anih u poruci.

</FONT></P><P><FONT face=3DArial color=3D#999999 size=
=3D1>

 DISCLAIMER:The contents of this email as well as any files attached to it=
 are confidential and intended solely for individuals or entities which th=
ey are addressed to. If you have received this email message in error, ple=
ase notify the sender and permanently remove the message and all attached =
files from the computer. Any disclosure, copying or distribution of all or=
 a part of information contained herein to or by third parties is prohibit=
ed and may be unlawful. Please note that any views or opinions presented i=
n this message are solely those of the author and do not necessarily repre=
sent the views and opinions of Croatian Telecom Inc. Croatian Telecom Inc.=
 accepts no liability for any potential damage caused by this message and =
files attached to it.

</FONT></P></HTML>
  • References:=20
    • [BEHAVE] Fwd: I-D Action:=20 draft-sun-behave-v4tov6-00.txt=20
      • From: Qiong
    • Re: [BEHAVE] Fwd: I-D Action:=20 draft-sun-behave-v4tov6-00.txt=20
      • From: Liu Dapeng
    • Re: [BEHAVE] Fwd: I-D Action:=20 draft-sun-behave-v4tov6-00.txt=20
      • From: Qiong
    • Re: [BEHAVE] Fwd: I-D Action:=20 draft-sun-behave-v4tov6-00.txt=20
      • From: Andrew Sullivan
    • Re: [BEHAVE] Fwd: I-D Action:=20 draft-sun-behave-v4tov6-00.txt=20
      • From: Simon Perreault
    • Re: [BEHAVE] Fwd: I-D Action:=20 draft-sun-behave-v4tov6-00.txt=20
      • From: Andrew Sullivan
    • Re: [BEHAVE] Fwd: I-D Action:=20 draft-sun-behave-v4tov6-00.txt=20
      • From: Qiong
    • Re: [BEHAVE] Fwd: I-D Action:=20 draft-sun-behave-v4tov6-00.txt=20
      • From: Andrew Sullivan
  • Prev by Date: Re:=20 [BEHAVE] draft-meng-behave-napgt can be met by PCP port set= =20
  • Next by Date: Re:=20 [BEHAVE] draft-meng-behave-napgt can be met by PCP port set= =20
  • Previous by thread: Re:=20 [BEHAVE] Fwd: I-D Action: draft-sun-behave-v4tov6-00.txt=20
  • Next by thread: Re:=20 [BEHAVE] Fwd: I-D Action: draft-sun-behave-v4tov6-00.txt=20
  • Index(es):=20
    • Date=20
    • Thread=20

Note: Messages sent to this list are the opinions of the senders and d= o not=20 imply endorsement

 
xiechf01-Gmail
------=_001_NextPart022525551504_=------ From xiechf01@gmail.com Tue Jul 30 08:30:37 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 883DF11E8103 for ; Tue, 30 Jul 2013 08:30:37 -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 cXrkrldJb4uk for ; Tue, 30 Jul 2013 08:30:35 -0700 (PDT) Received: from mail-bk0-x234.google.com (mail-bk0-x234.google.com [IPv6:2a00:1450:4008:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 49F6711E80F9 for ; Tue, 30 Jul 2013 08:30:34 -0700 (PDT) Received: by mail-bk0-f52.google.com with SMTP id mx10so2514534bkb.25 for ; Tue, 30 Jul 2013 08:30:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:reply-to:subject:x-priority:x-has-attach:x-mailer :mime-version:message-id:content-type; bh=f0getrcA5YW5Vubz86DX4wngN8gOKaIHgAdUpaauUkY=; b=r3KLLKtvYv+0K17P4GETqeYB+nFna2dkcST2CJDqoHl+C5Wu9F1kBypt+DEt9lhwhB 14X2+7ac2IWMBU684PX4e0jbvh90LpR/roAXGzFXgkQCg8M84/sMVAmd9oMlmq+Vwdmu q2RAHR5JtN57aoVTgga6ssiKU+DFJI4YYIuDhFBocXEzZy5hXARJOugYHBuk87A48jvb Ur6bVTs5wgt48RjhsUl+lvIQ5xfoXJTrn5Mb/n7qe38yDQ6hz8LqjuiPo1QopD+wb5yX KJ5pdynw4Uuy7Pb5ofrKe82yzTreCyiv4uRpPyj3AweKQy/w3OJLRgspyWAgtJOq6Lrq 5e+Q== X-Received: by 10.205.116.137 with SMTP id fi9mr9335190bkc.149.1375198232940; Tue, 30 Jul 2013 08:30:32 -0700 (PDT) Received: from xiechf-PC2 ([46.189.28.34]) by mx.google.com with ESMTPSA id ok9sm17611801bkb.8.2013.07.30.08.30.30 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 30 Jul 2013 08:30:32 -0700 (PDT) Date: Tue, 30 Jul 2013 17:30:27 +0200 From: xiechf01-Gmail To: behave X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.92[cn] Mime-Version: 1.0 Message-ID: <201307301730264218665@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart311384300757_=----" Subject: Re: [BEHAVE] Fwd: I-D Action: draft-sun-behave-v4tov6-00.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: xiechf01 List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 15:30:37 -0000 This is a multi-part message in MIME format. ------=_001_NextPart311384300757_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAgDQpIaSwNCg0KICAgICAgVGhlIHJlcXVpcmVtZW50cyBpbiBkcmFmdC1zdW4tYmVoYXZlLXY0 dG92Ni0wMCBvcmdpbmF0ZXMgZnJvbSB0aGUgcmVhbCBleHBlcmllbmNlIGFuZCBleHBlY3RhdGlv bnMgb2Ygb3VyIHByb2R1Y3QgbmV0d29yay4gIA0KDQogICAgICBSZWNlbnRseSwgSVB2NCBhZGRy ZXNzIHNob3J0YWdlIGJlZ2luIHRvIG9jY291ciBpbiBzb21lIGRhdGEgY2VudGVycywgYW5kIHdl IGd1ZXNzIHRoYXQgdGhpcyBzaXR1YXRpb24gd2lsbCBiZWNvbWUgd29yc2UgYXMgdGhlIGRheXMg cGFzcy4gIFNpbmNlIHRoZSBJUHY0IGFkZHJlc3Mgb3duZWQgYnkgYSBnaXZlbiBkYXRhIGNlbnRl ciBpcyBmaW5pdGUsIHNvIElQdjQgYWRkcmVzcyBpbiB0aGVpciBoYW5kcyB3aWxsIHJ1biBvdXQg c29vbiwgaXQgaXMgaW5ldml0YWJsZSB0aGF0IElQdjYtb25seSBzZXJ2ZXIgd2lsbCBhcGVhci4g RHVhbC1zdGFjayBzZXJ2aWNlcyB0byBuZXcgSUNQcyBpcyBiYXNlZCBvbiBzdWZmaWNpZW50IElQ djQgYWRkcmVzcyBwcm92aXNpb25naW5nLCBidXQgdGhpcyBpcyBub3QgdGhlIGZ1dHVyZSBmb3Ig bW9zdCBJRENzLiANCg0KICAgICAgIE9uIHRoZSBvdGhlciBzaWRlLCBhbHRob3VnaCBzb21lIG9w ZXJhdG9ycyBpbiB0aGUgd29ybGQgYmVnaW4gdG8gZGVwbG95IElQdjYgZm9yIHRoZWlyIGJyb2Fk YmFuZCB1c2VycywgYSBncmVhdCBwb3J0aW9uIG9mIHVzZXJzIHdvcmxkd2lkZSB3aWxsIHN0aWxs IGJlIElQdjQtb25seSBpbiB0aGUgbG9uZyBmdXR1cmUgZHVlIHRvIG1hbnkgd2VsbC1rbm93biBm YWN0b3JzLCAgd2UgY2FuIG5vdCBhc3N1bWUgdGhhdCBhbGwgdGhlIHVzZXJzIHdpbGwgYmVjb21l IGR1YWwtc3RhY2sgaW4gYSBzaG9ydCBwZXJpb2QuIFJpZ2h0IG5vdywgSVB2NiBwZW5lcmF0aW9u IGluIG1vc3QgcmVnaW9ucyBpcyBiZWxvdyAxMCUuDQoNCiAgICAgICBDb21iaW5nIHRoZSAyIGZh Y3RvcnMgdG9nZXRoZXIsIHdlIGRlZW0gaXQgaXMgbmVjZXNzYXJ5IHRvIHNvbHZlIDR0bzYgYWNl c3MgcHJvYmxlbSBkdXJpbmcgdGhlIGxvbmcgdHJhbnNpdGlvbiBwZXJpb2QuICAgDQoNCkNob25n ZmVuZw0KDQoNClRvOiAiYWpzIGF0IGFudmlsd2FscnVzZGVuLmNvbSIgPGFqcyBhdCBhbnZpbHdh bHJ1c2Rlbi5jb20+LCAiYmVoYXZlIGF0IGlldGYub3JnIiA8YmVoYXZlIGF0IGlldGYub3JnPiAN ClN1YmplY3Q6IFJlOiBbQkVIQVZFXSBGd2Q6IEktRCBBY3Rpb246IGRyYWZ0LXN1bi1iZWhhdmUt djR0b3Y2LTAwLnR4dCANCkZyb206IEJyYW5pbWlyIFJhanRhciA8QnJhbmltaXIuUmFqdGFyIGF0 IHQuaHQuaHI+IA0KRGF0ZTogVHVlLCAzMCBKdWwgMjAxMyAwODo0NjoxOSArMDAwMCANCkFjY2Vw dC1sYW5ndWFnZTogZW4tVVMgDQpEZWxpdmVyZWQtdG86IGJlaGF2ZSBhdCBpZXRmYS5hbXNsLmNv bSANCkluLXJlcGx5LXRvOiA8MjAxMzA3MzAwODA1MDQuR0E1MjU3NSBhdCBteDEueWl0dGVyLmlu Zm8+IA0KTGlzdC1hcmNoaXZlOiA8aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2Vi L2JlaGF2ZT4gDQpMaXN0LWhlbHA6IDxtYWlsdG86YmVoYXZlLXJlcXVlc3RAaWV0Zi5vcmc/c3Vi amVjdD1oZWxwPiANCkxpc3QtaWQ6IG1haWxpbmcgbGlzdCBvZiBCRUhBVkUgSUVURiBXRyA8YmVo YXZlLmlldGYub3JnPiANCkxpc3QtcG9zdDogPG1haWx0bzpiZWhhdmVAaWV0Zi5vcmc+IA0KTGlz dC1zdWJzY3JpYmU6IDxodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2JlaGF2 ZT4sIDxtYWlsdG86YmVoYXZlLXJlcXVlc3RAaWV0Zi5vcmc/c3ViamVjdD1zdWJzY3JpYmU+IA0K TGlzdC11bnN1YnNjcmliZTogPGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vb3B0aW9ucy9i ZWhhdmU+LCA8bWFpbHRvOmJlaGF2ZS1yZXF1ZXN0QGlldGYub3JnP3N1YmplY3Q9dW5zdWJzY3Jp YmU+IA0KUmVmZXJlbmNlczogPENBSDNiZkFCdE14WmtFeWhvQUFpaDVic0R6UDZIN0J6ek1yODho NlR4NitNMlNpcWJndyBhdCBtYWlsLmdtYWlsLmNvbT4gPENBS2NjNkFlcDdjS19EdD1DRnNRTTNG NUZuOE95OVVpMV85Z2Q3dTZfZDRwWU9kMU9aUSBhdCBtYWlsLmdtYWlsLmNvbT4gPENBSDNiZkFC MWRMdkJKMkZyTXZjN2JBTmNVc25lWl94Y09rX1JQSmFNa089UnJXbkdDQSBhdCBtYWlsLmdtYWls LmNvbT4gPDIwMTMwNzI5MTM0NjIzLkdENTE3MzcgYXQgbXgxLnlpdHRlci5pbmZvPiA8NTFGNjc0 RDAuMzA0MDYwMyBhdCB2aWFnZW5pZS5jYT4gPDIwMTMwNzI5MTQzOTEwLkdCNTE4MjMgYXQgbXgx LnlpdHRlci5pbmZvPiA8Q0FIM2JmQUMzQ2FzdXVkcFh5YjNYV09NeitUd1pVR2V5YV8xaD1qZDJN R1g0b0xNMFZnIGF0IG1haWwuZ21haWwuY29tPiwgPDIwMTMwNzMwMDgwNTA0LkdBNTI1NzUgYXQg bXgxLnlpdHRlci5pbmZvPiANClJlcGx5LXRvOiBCcmFuaW1pciBSYWp0YXIgPEJyYW5pbWlyLlJh anRhciBhdCB0Lmh0LmhyPiANClRocmVhZC1pbmRleDogQVFIT2pOQkg3S1puVmlVYnYwSzNFdDN6 YkxkUTNKbDh1OVlBZ0FBdER1cz0gDQpUaHJlYWQtdG9waWM6IFtCRUhBVkVdIEZ3ZDogSS1EIEFj dGlvbjogZHJhZnQtc3VuLWJlaGF2ZS12NHRvdjYtMDAudHh0IA0KDQoNCg0KSGksDQoNCllvdXIg YXJndW1lbnRhdGlvbiBzYXlzIHRoYXQgZXZlcnlib2R5IG5lZWRzIHRvIGhhdmUgSVB2NiBhY2Nl c3MgYW5kIEkgYWdyZWUgY29tcGxldGVseSB0aGF0IHdvdWxkIHNvbHZlIGFsbCBpc3N1ZXMuIEhv d2V2ZXIsIHdlIHdpbGwgbm90IGJlIGluIHRoYXQgcG9pbnQgb2YgdGltZSBmb3IgYXQgbGVhc3Qg Zml2ZSB5ZWFycy4gQW5kIEkgdGhpbmsgSSdtIG9wdGltaXN0aWMgLSBieSBsb29raW5nIGF0IHRo ZSBjdXJyZW50IElQdjYgZGVwbG95bWVudCBwZXJjZW50YWdlcywgaXQgbWlnaHQgYmUgbXVjaCBt b3JlLg0KDQpJU1BzIGFyZSBub3QgcmVhbGx5IGtlZW4gb24gZGVwbG95aW5nIElQdjYsIHRoZXkg cmF0aGVyIGRvIENHTi4gTkFUNDYgd291bGQgYmUgY2hlYXBlciBhbmQgd291bGQgcHJvdmlkZSBh IHJlYXNvbiBmb3Igc2VydmVycyB3aGljaCBhcmUgY3VycmVudGx5IElQdjQtb25seSB0byBzd2l0 Y2ggdG8gZHVhbC1zdGFjayBhbmQgZXZlbnR1YWxseSB0byBJUHY2LW9ubHkuDQoNCkkgdGhpbmsg d2UgY291bGQgZGlzY3VzcyB0aGlzIHRvcGljIGZvciB0aGUgbmV4dCBjb3VwbGUgb2Ygd2Vla3Mg KHdoaWNoIHdvdWxkIGJlIHF1aXRlIGRpZmZpY3VsdCBzaW5jZSBJJ20gd3JpdGluZyBmcm9tIG15 IHNtYXJ0cGhvbmUpIHNvIEkgc3VnZ2VzdCB0byBsZWF2ZSB0aGUgZGVjaXNpb24gb24gdGhlIHdv cmtpbmcgZ3JvdXAuDQoNCkJSLA0KQnJhbmltaXINCg0KDQoNCg0KLS0tLS0tLS0gSXp2b3JuYSBw b3J1a2EgLS0tLS0tLS0NCsOFYWxqZTogQW5kcmV3IFN1bGxpdmFuIDxhanMgYXQgYW52aWx3YWxy dXNkZW4uY29tPg0KRGF0dW06DQpUbzogYmVoYXZlIGF0IGlldGYub3JnDQpOYXNsb3Y6IFJlOiBb QkVIQVZFXSBGd2Q6IEktRCBBY3Rpb246IGRyYWZ0LXN1bi1iZWhhdmUtdjR0b3Y2LTAwLnR4dA0K DQoNCkhpLA0KDQpJJ20gYWxyZWFkeSB2aW9sYXRpbmcgbXkgdXN1YWwgcnVsZXMgYWJvdXQgb3Zl ci1wb3N0aW5nLCBzbyBJJ20gZ29pbmcNCnRvIGVuZGVhdm91ciB0byBzaHV0IHVwIGFmdGVyIHRo aXMuICBCdXQgdGhlcmUncyBhIHN1YnRsZSBidXQsIGluIG15DQpvcGluaW9uLCBtaXN0YWtlbiBw YXJhbGxlbGlzbSBoZXJlLCBhbmQgSSB3YW50IHRvIGNoYWxsZW5nZSBpdC4NCg0KT24gVHVlLCBK dWwgMzAsIDIwMTMgYXQgMTA6NTU6NDJBTSArMDgwMCwgUWlvbmcgd3JvdGU6DQoNCj4gRm9yIGV4 YW1wbGUsIHdlIG5vdyBoYXZlIE5BVDY0IGFuZCBzbyB2Ni1vbmx5IGNsaWVudCBjYW4gZW1lcmdl IGFuZCB0YWxrIHRvDQo+IHY0IHNlcnZlci4gU28gdjYtb25seSBjbGllbnRzIG1heSBiZSBtb3Jl IGFuZCBtb3JlIGluIHRoZSBmdXR1cmUuIEkgc2VlDQo+IG5vYm9keSBhcmd1ZXMgdGhhdCBpZiB3 ZSBoYXZlIE5BVDY0LCB2NCBzZXJ2ZXIgbWF5IGxpdmUgaW4gdjQgZm9yZXZlci4NCj4NCj4gVGhl biBmb3IgdjQtdG8tdjYgc2NlbmFyaW8sIHRoaXMgaXMgdGhlIHNhbWUgc2luY2UgaXQgd2lsbCBi cmluZyB0aGUNCj4gYWJpbGl0eSB0byBzdXBwb3J0IHY2LW9ubHkgc2VydmVyIHRvIGJlIHJlYWNo YWJsZSBieSB2NC1vbmx5IGNsaWVudHMuDQo+IFRoZXJlZm9yZSwgdjYtb25seSBzZXJ2ZXIgbWF5 IGVtZXJnZSBiZWNhdXNlIHRoZXkgZG8gbm90IG5lZWQgdG8gd29ycnkNCj4gYWJvdXQgbG9zaW5n IHY0IGNsaWVudHMuIFNvIHY2LW9ubHkgc2VydmVyIG1heWJlIG1vcmUgYW5kIG1vcmUgaW4gdGhl DQo+IGZ1dHVyZS4gVGhpcyB3aWxsIHByb21vdGUgdjYtZGV2ZWxvcG1lbnQsIHJhdGhlciB0aGFu IHRoZSBvcHBvc2l0ZSBvbmUuDQoNClRoZSBrZXkgcmVhc29uIHRvIGhhdmUgZGVmaW5lZCBOQVQ2 NCB3YXMgYmVjYXVzZSB3ZSBoYWQgYSBzdXBwbHkNCnByb2JsZW0uICBJZiB5b3Ugd2VyZSBhIHY2 LW9ubHkgbm9kZSwgeW91IGNvdWxkbid0IHJlYWNoIHNlcnZlcnMgb24NCnRoZSB2NCBJbnRlcm5l dC4gIEJ1dCBfbW9zdF8gdGhpbmdzIHdlcmUgb24gdGhlIHY0IEludGVybmV0LiAgU28gTkFUNjQN CmdhdmUgdXMgYSB3YXkgb2YgcGVybWl0dGluZyBwZW9wbGUgdG8gaGF2ZSB2Ni1vbmx5IGNvbm5l Y3Rpdml0eQ0Kd2l0aG91dCBwYXlpbmcgdGhlIGNvc3Qgb2YgbG9zaW5nIGFjY2VzcyB0byB0aGUg ZW50aXJlIEludGVybmV0Lg0KDQpUaGUgYXJndW1lbnQgYWJvdmUgdHVybnMgdGhpcyBvbiBpdHMg aGVhZCwgYW5kIHNheXMgdGhhdCBpZiB5b3UgYXJlDQpzdGFuZGluZyB1cCBhIHNlcnZpY2UsIHlv dSBhcmUgd29ycmllZCBhYm91dCBsb3NpbmcgdGhlIHBvc3NpYmxlDQpjdXN0b21lcnMgb24gdjQt b25seSBuZXR3b3Jrcy4gIFRoZXJlZm9yZSwgeW91IHdpbGwgZ28gZHVhbCBzdGFjay4NCkltcGxp Y2l0bHksIGlmIHdlIHNheSwgIk5ldyB2NCBzZXJ2aWNlIGJhZCwiIHdlIHRoaW5rIGl0IHdvdWxk IGJlDQpiZXR0ZXIgdGhhdCB0aGUgc2VydmljZSBiZSB2Ni1vbmx5LiAgU28sIHdlIHNob3VsZCBo YXZlIGEgbWVjaGFuaXNtIGJ5DQp3aGljaCB2NC1vbmx5IGNsaWVudHMgY2FuIGFjY2VzcyB0aGUg djYgSW50ZXJuZXQsIGFuZCB0aGlzIHdpbGwgaW4NCnNvbWUgc2Vuc2UgaW5jcmVhc2UgdjYgdXNl IGJlY2F1c2UgdGhlIHNlcnZpY2UgaXMgYWN0dWFsbHkgYWNjZXNzZWQNCm92ZXIgdjYuDQoNCkkg dGhpbmsgdGhlIGFyZ3VtZW50IGlzIHN1YnRsZSBidXQgd3JvbmcuICBGaXJzdCwgaXQgZGVwZW5k cyBvbiB0aGUNCnByZW1pc2UgdGhhdCB0aGVyZSBpcyBhbiBpbnRlcmVzdGluZyBwb3B1bGF0aW9u IHRoYXQgd2lsbA0KKGVjb25vbWljYWxseSkgcmVtYWluIHY0LW9ubHkgd2hpbGUgdjYtb25seSBz ZXJ2aWNlIGRlcGxveW1lbnQgaXMgaW4NCnNvbWUgc2Vuc2UgKGxpa2VseSBlY29ub21pY2FsbHkp IGEgcmVhc29uYWJsZSBwbGFuLiAgQXMgSSBhbHJlYWR5DQphcmd1ZWQgZWxzZXdoZXJlIGluIHRo aXMgdGhyZWFkLCB0aGF0IHByZW1pc2UgbmVlZHMgYSBsb3Qgb2YNCnN1cHBvcnRpbmcgYXJndW1l bnQsIGJlY2F1c2UgaXQgc2VlbXMgdG8gbWUgdG8gYmUgZmFsc2UuICBTZWNvbmQsIGl0DQpjb25m dXNlcyB0aGUgZ29hbCBvZiBJUHY2IGRlcGxveW1lbnQgaW4gdGhlIHNlbnNlIG9mIG5hdGl2ZSB1 c2Ugd2l0aCBhDQpzdXBwb3NlZCBnb2FsIG9mIG1lcmVseSBjYXJyeWluZyB0cmFmZmljIG92ZXIg djYuICBUaGUgbGF0dGVyIGlzIG5vdA0KYW4gaW50ZXJlc3RpbmcgZ29hbCBpbiBhbnkgc2Vuc2U6 IGlmIHRvbW9ycm93IHdlIHNpbXBseSBlbmNhcHN1bGF0ZWQNCmFsbCB2NCB0cmFmZmljIGluc2lk ZSB2NiwgSSBkbyBub3QgdGhpbmsgaXQgd291bGQgYmUgYW4gaW50ZXJlc3RpbmcNCmFkdmFuY2Ug aW4gdjYgZGVwbG95bWVudC4gIFNvIEkgcmVqZWN0IHRoZSBjbGFpbSB0aGF0IHRoaXMgc29ydCBv Zg0KNC10by02IE5BVCBpcyBhIHBvc2l0aXZlIGNvbnRyaWJ1dG9yIHRvIElQdjYgZGVwbG95bWVu dC4gIFRoZSByaWdodA0KbWVzc2FnZSBpcywgIklmIHlvdSB3YW50IHRvIHJlYWNoIHRoaXMgdjYt b25seSBzZXJ2aWNlLCBnZXQgYSB2Ng0KYWRkcmVzcy4iICBJZiB0aGUgc2VydmljZSBpcyB2YWx1 YWJsZSwgdGhlIGN1c3RvbWVycyB3aWxsIGNvbWUsIHNpbmNlDQp2NiBjb21tdW5pY2F0aW9ucyBh cmUgbm8gbG9uZ2VyIGFuIGVub3Jtb3VzIGJpZyBkZWFsLg0KDQpBcyBmb3IgdGhlIHJpc2sgdGhh dCBkdWFsIHN0YWNrIGV2ZXJ5d2hlcmUgcGVybWl0cyB2NCB0byBwZXJzaXN0OiBzbw0Kd2hhdD8g IElmIHY2IGlzIHdvcmtpbmcgZXZlcnl3aGVyZSwgdGhlbiB0aGUgdjQgbmV0d29yayB3aWxsIGdy YWR1YWxseQ0Kd2l0aGVyIGF3YXkgYmVjYXVzZSBpdCBpcyBub3QgZWNvbm9taWNhbCB0byBrZWVw IHRoYXQgbmV0d29yaw0KaW50ZXJmYWNlIGFjdGl2ZS4gIChMZWUgSG93YXJkIGhhcyBkb25lIGlu dGVyZXN0aW5nIGFuYWx5c2lzIGluIHRoaXMNCmFyZWEsIGFuZCBoaXMgbW9kZWxzIGF0IGxlYXN0 IHN1Z2dlc3QgYSBwcmV0dHkgc2lnbmlmaWNhbnQgY2hhbmdlb3Zlcg0KaW5jZW50aXZlIG9uY2Ug YSBub3QgdmVyeSBsYXJnZSBudW1iZXIgb2Ygc2VydmljZXMgY29tZSB1cCBvbiBJUHY2LikNClRo ZSBnb2FsIGlzIG5vdCB0byBtYWtlIHRoZSBldmlsLCBiYWQsIHdyb25nIHY0IGdvIGF3YXksIGFu eSBtb3JlIHRoYW4NCnRoZSBnb2FsIHdhcyBpbiBpdHNlbGYgdG8ga2lsbCBYLjI1IGFuZCBkYW5j ZSBhYm91dCBvbiBpdHMgZ3JhdmUNCnNpbmdpbmcgaGFsbGVsdWphaC4gIFRoYXQgd2FzIGp1c3Qg YSBoYXBweSBjb25zZXF1ZW5jZS4NCg0KPiBGcm9tIHRoZSBsb25nIGhpc3Rvcnkgb2YgSVB2NiBk ZXZlbG9wbWVudCwgSSB0aGluayBpdCBpcyBjbGVhciB0aGlzDQo+IGFzc3VtcHRpb24gaGFzIG5l dmVyIGhhcmRseSBleGlzdGVkLiBJZiBhbnlvbmUgKm91Z2h0IHRvIGJlIGFibGUgdG8gZ2V0IGEN Cj4gdjYgYWRkcmVzcyosIHdlIHdvdWxkIGhhdmUgcmVhY2hlZCB0aGUgdjYtd29ybGQgbG9uZyBh Z28sIHJhdGhlciB0aGFuDQo+IGRlYmF0aW5nIGhvdyB0byB0cmFuc2l0Lg0KDQpTdXJlbHkgbm90 LiAgVjYgZGVwbG95bWVudCBoYXMgbmV2ZXIgYmVlbiBpbXBlZGVkIGJ5IGxhY2sgb2YgdjYNCmFk ZHJlc3Nlcy4gIEFzIGxvbmcgYXMgdjQgd2FzIGdvb2QgZW5vdWdoIGFuZCBpdCB3YXMgc3RpbGwg cG9zc2libGUgdG8NCmdldCBhZGRyZXNzIHNwYWNlIGZvciByZWFzb25hYmxlIGNvc3QsIHRoZXJl IHdhcyBsaXR0bGUgaW5jZW50aXZlIHRvDQptb3ZlIHRvIGEgbmV0d29yayB0ZWNobm9sb2d5IHRo YXQgc2VlbWVkIGxpa2UgaXQgd2FzIHN0aWxsIHVuZGVyDQpkZXZlbG9wbWVudC4gIEJ1dCB3ZSdy ZSBvdXQgb2YgdjQgYWRkcmVzc2VzIG5vdywgdGhlIGV4cGVyaWVuY2UgaXMNCl9ub3RfIGdvb2Qg ZW5vdWdoLCBhbmQgc28gb25lIG1pZ2h0IHN1cHBvc2UgdGhlIGluY2VudGl2ZXMgaGF2ZSBjaGFu Z2VkLg0KDQpCZXN0LA0KDQpBDQoNCi0tDQpBbmRyZXcgU3VsbGl2YW4NCmFqcyBhdCBhbnZpbHdh bHJ1c2Rlbi5jb20NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpCZWhhdmUgbWFpbGluZyBsaXN0DQpCZWhhdmUgYXQgaWV0Zi5vcmcNCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYmVoYXZlDQoNCg0KPEhUTUw+PFA+PEZPTlQgZmFj ZT1BcmlhbCBjb2xvcj0jOTk5OTk5IHNpemU9MT4NCg0KSVpKQVZBIE8gT0RSSUNBTkpVIE9ER09W T1JOT1NUSTogU2FkcsOFYWogb3ZlIHBvcnVrZSBpIGV2ZW50dWFsbm8gcHJpbG/DhWVuaWggZGF0 b3Rla2EgamUgcG92amVybGppdiBpIG5hbWlqZW5qZW4gamUgc2FtbyBvc29iYW1hIGlsaSBzdWJq ZWt0aW1hIGtvamkgc3UgbmF2ZWRlbmkgdSBhZHJlc2kuIFVrb2xpa28gc3RlIHByaW1pbGkgb3Z1 IHBvcnVrdSBncmXDhWtvbSwgbW9saW1vIFZhcywgb2JhdmlqZXN0aXRlIHBvw4VpbGphdGVsamEs IGEgcG9ydWt1IGkgc3ZlIG5qZW5lIHByaXZpdGtlIG9kbWFoLCBiZXogw4RpdGFuamEsIHRyYWpu byB1a2xvbml0ZSBzIHJhw4R1bmFsYS4gQmlsbyBrYWt2byBwcmVub8OFZW5qZSwga29waXJhbmpl IGlsaSBkaXN0cmlidWNpamEgaW5mb3JtYWNpamEgc2FkcsOFYW5paCB1IHBvcnVjaSB0cmXDhGlt IG9zb2JhbWEgamUgemFicmFuamVubyBpIG1vw4VlIGJpdGkgemFrb25za2kga2HDhW5qaXZvLiBT YWRyw4Vhaiwgc3Rhdm92aSBpIG1pw4VsamVuamEgaXpuZXNlbmkgdSBwb3J1Y2kgc3UgYXV0b3Jv dmkgaSBuZSBwcmVkc3RhdmxqYWp1IG51w4VubyBzdGF2b3ZlIEhUIC0gSHJ2YXRza2loIHRlbGVr b211bmlrYWNpamEgZC5kLiBIVCBuZSBwcmlodmHDhGEgbmlrYWt2dSBvZGdvdm9ybm9zdCB6YSBl dmVudHVhbG51IMOFdGV0dSBuYXN0YWx1IHByaW1pdGtvbSBvdmUgcG9ydWtlIGkgcHJpbG9nYSBz YWRyw4VhbmloIHUgcG9ydWNpLg0KDQo8L0ZPTlQ+PC9QPjxQPjxGT05UIGZhY2U9QXJpYWwgY29s b3I9Izk5OTk5OSBzaXplPTE+DQoNCiBESVNDTEFJTUVSOlRoZSBjb250ZW50cyBvZiB0aGlzIGVt YWlsIGFzIHdlbGwgYXMgYW55IGZpbGVzIGF0dGFjaGVkIHRvIGl0IGFyZSBjb25maWRlbnRpYWwg YW5kIGludGVuZGVkIHNvbGVseSBmb3IgaW5kaXZpZHVhbHMgb3IgZW50aXRpZXMgd2hpY2ggdGhl eSBhcmUgYWRkcmVzc2VkIHRvLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIG1lc3Nh Z2UgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgcGVybWFuZW50bHkgcmVt b3ZlIHRoZSBtZXNzYWdlIGFuZCBhbGwgYXR0YWNoZWQgZmlsZXMgZnJvbSB0aGUgY29tcHV0ZXIu IEFueSBkaXNjbG9zdXJlLCBjb3B5aW5nIG9yIGRpc3RyaWJ1dGlvbiBvZiBhbGwgb3IgYSBwYXJ0 IG9mIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gdG8gb3IgYnkgdGhpcmQgcGFydGllcyBp cyBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIFBsZWFzZSBub3RlIHRoYXQgYW55IHZp ZXdzIG9yIG9waW5pb25zIHByZXNlbnRlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHNvbGVseSB0aG9z ZSBvZiB0aGUgYXV0aG9yIGFuZCBkbyBub3QgbmVjZXNzYXJpbHkgcmVwcmVzZW50IHRoZSB2aWV3 cyBhbmQgb3BpbmlvbnMgb2YgQ3JvYXRpYW4gVGVsZWNvbSBJbmMuIENyb2F0aWFuIFRlbGVjb20g SW5jLiBhY2NlcHRzIG5vIGxpYWJpbGl0eSBmb3IgYW55IHBvdGVudGlhbCBkYW1hZ2UgY2F1c2Vk IGJ5IHRoaXMgbWVzc2FnZSBhbmQgZmlsZXMgYXR0YWNoZWQgdG8gaXQuDQoNCjwvRk9OVD48L1A+ PC9IVE1MPg0KDQoNCg0KDQpSZWZlcmVuY2VzOiANCltCRUhBVkVdIEZ3ZDogSS1EIEFjdGlvbjog ZHJhZnQtc3VuLWJlaGF2ZS12NHRvdjYtMDAudHh0IA0KRnJvbTogUWlvbmcNClJlOiBbQkVIQVZF XSBGd2Q6IEktRCBBY3Rpb246IGRyYWZ0LXN1bi1iZWhhdmUtdjR0b3Y2LTAwLnR4dCANCkZyb206 IExpdSBEYXBlbmcNClJlOiBbQkVIQVZFXSBGd2Q6IEktRCBBY3Rpb246IGRyYWZ0LXN1bi1iZWhh dmUtdjR0b3Y2LTAwLnR4dCANCkZyb206IFFpb25nDQpSZTogW0JFSEFWRV0gRndkOiBJLUQgQWN0 aW9uOiBkcmFmdC1zdW4tYmVoYXZlLXY0dG92Ni0wMC50eHQgDQpGcm9tOiBBbmRyZXcgU3VsbGl2 YW4NClJlOiBbQkVIQVZFXSBGd2Q6IEktRCBBY3Rpb246IGRyYWZ0LXN1bi1iZWhhdmUtdjR0b3Y2 LTAwLnR4dCANCkZyb206IFNpbW9uIFBlcnJlYXVsdA0KUmU6IFtCRUhBVkVdIEZ3ZDogSS1EIEFj dGlvbjogZHJhZnQtc3VuLWJlaGF2ZS12NHRvdjYtMDAudHh0IA0KRnJvbTogQW5kcmV3IFN1bGxp dmFuDQpSZTogW0JFSEFWRV0gRndkOiBJLUQgQWN0aW9uOiBkcmFmdC1zdW4tYmVoYXZlLXY0dG92 Ni0wMC50eHQgDQpGcm9tOiBRaW9uZw0KUmU6IFtCRUhBVkVdIEZ3ZDogSS1EIEFjdGlvbjogZHJh ZnQtc3VuLWJlaGF2ZS12NHRvdjYtMDAudHh0IA0KRnJvbTogQW5kcmV3IFN1bGxpdmFuDQpQcmV2 IGJ5IERhdGU6IFJlOiBbQkVIQVZFXSBkcmFmdC1tZW5nLWJlaGF2ZS1uYXBndCBjYW4gYmUgbWV0 IGJ5IFBDUCBwb3J0IHNldCANCk5leHQgYnkgRGF0ZTogUmU6IFtCRUhBVkVdIGRyYWZ0LW1lbmct YmVoYXZlLW5hcGd0IGNhbiBiZSBtZXQgYnkgUENQIHBvcnQgc2V0IA0KUHJldmlvdXMgYnkgdGhy ZWFkOiBSZTogW0JFSEFWRV0gRndkOiBJLUQgQWN0aW9uOiBkcmFmdC1zdW4tYmVoYXZlLXY0dG92 Ni0wMC50eHQgDQpOZXh0IGJ5IHRocmVhZDogUmU6IFtCRUhBVkVdIEZ3ZDogSS1EIEFjdGlvbjog ZHJhZnQtc3VuLWJlaGF2ZS12NHRvdjYtMDAudHh0IA0KSW5kZXgoZXMpOiANCkRhdGUgDQpUaHJl YWQgDQpOb3RlOiBNZXNzYWdlcyBzZW50IHRvIHRoaXMgbGlzdCBhcmUgdGhlIG9waW5pb25zIG9m IHRoZSBzZW5kZXJzIGFuZCBkbyBub3QgaW1wbHkgZW5kb3JzZW1lbnQgDQoNCg0KDQoNCnhpZWNo ZjAxLUdtYWls ------=_001_NextPart311384300757_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
   
Hi,
 
      The=20 requirements in draft-sun-behave-v4tov6-00 orginates f= rom the real experience and expectations of&= nbsp;our product network.  
 
      Recently,=20 IPv4 address shortage begin to occour in&nbs= p;some data centers, and we guess that = this situation will become worse as the = ;days pass. =20 Since the IPv4 address owned by a given=  data center is finite, so IPv4 address=  in their hands will run out soon, = ;it is inevitable that IPv6-only server will=  apear. Dual-stack services to new=20 ICPs is based on sufficient IPv4 address&nbs= p;provisionging, but this is not the=20 future for most IDCs. 
 
      =20 On the other side, although some operators&n= bsp;in the world begin to deploy IPv6 f= or their broadband users, a great portion&nb= sp;of users worldwide will still be IPv4-only in the&nbs= p;long future due to many well-known factors= , =20 we can not assume that all the users&nb= sp;will become dual-stack in a short period.= =20 Right now, IPv6 peneration in most regions is below 10%.
 
    =20   Combing the 2 factors together, we&nb= sp;deem it is necessary to solve 4to6 a= cess problem during the long transition peri= od.   
 
Chongfeng
 
 
  • To: "ajs at=20 anvilwalrusden.com" <ajs at=20 anvilwalrusden.com>, "beh= ave at=20 ietf.org" <behave at=20 ietf.org>=20
  • Subject: Re: [BEHAVE] Fwd: I-D Action:=20 draft-sun-behave-v4tov6-00.txt=20
  • From: Branimir Rajtar <Branimir.Rajtar at t.ht.hr= >=20
  • Date: Tue, 30 Jul 2013 08:46:19 +0000=20
  • Accept-language: en-US=20
  • Delivered-to: behav= e at=20 ietfa.amsl.com=20
  • In-reply-to: <20130730080504.GA52= 575 at=20 mx1.yitter.info>=20
  • List-archive: <http://www.ietf.org= /mail-archive/web/behave>=20
  • List-help: <mailto:behave-req= uest@ietf.org?subject=3Dhelp>=20
  • List-id: mailing list of BEHAVE IETF WG <behave.ietf.org= >=20
  • List-post: <mailto:behave@ietf.org>=20
  • List-subscribe: <https://www.ietf.o= rg/mailman/listinfo/behave>,=20 <mailto:behav= e-request@ietf.org?subject=3Dsubscribe>=20
  • List-unsubscribe: <https://www.ietf.or= g/mailman/options/behave>,=20 <mailto:beh= ave-request@ietf.org?subject=3Dunsubscribe>=20
  • References: <CAH3bfABtMxZkEyhoAAih5bsDzP6H7BzzMr88h6Tx6+M2Siqbgw=20 at mail.gmail.com> <CAKcc6Aep7cK_Dt=3DCFsQM3F5Fn8Oy9Ui1_9gd7u6_d4pYOd1OZQ=20 at mail.gmail.com> <CAH3bfAB1dLvBJ2FrMvc7bANcUsneZ_xcOk_RPJaMkO=3DRrWnGCA=20 at mail.gmail.com> <20130729134623.GD51= 737 at=20 mx1.yitter.info> <51F674D0.3040603 at=20 viagenie.ca> <20130729143910.GB51= 823 at=20 mx1.yitter.info> <CAH3bfAC3CasuudpXyb3XWOMz+TwZUGeya_1h=3Djd2MGX4oLM0Vg=20 at mail.gmail.com>, <20130730080504.GA52= 575 at=20 mx1.yitter.info>=20
  • Reply-to: Branimir Rajtar <Branimir.Rajtar at t.ht.hr= >=20
  • Thread-index: AQHOjNBH7KZnViUbv0K3Et3zbLdQ3Jl8u9YAgAAtDus= =3D=20
  • Thread-topic: [BEHAVE] Fwd: I-D Action:=20 draft-sun-behave-v4tov6-00.txt 
Hi,

Your argumentation says that everybody needs to have IPv6 access and I agr=
ee completely that would solve all issues. However, we will not be in that=
 point of time for at least five years. And I think I'm optimistic - by lo=
oking at the current IPv6 deployment percentages, it might be much more.

ISPs are not really keen on deploying IPv6, they rather do CGN. NAT46 woul=
d be cheaper and would provide a reason for servers which are currently IP=
v4-only to switch to dual-stack and eventually to IPv6-only.

I think we could discuss this topic for the next couple of weeks (which wo=
uld be quite difficult since I'm writing from my smartphone) so I suggest =
to leave the decision on the working group.

BR,
Branimir




-------- Izvorna poruka --------
=C3=85alje: Andrew Sullivan <ajs at anvilwalrusden.com>
Datum:
To: behave at ietf.org
Naslov: Re: [BEHAVE] Fwd: I-D Action: draft-sun-behave-v4tov6-00.txt


Hi,

I'm already violating my usual rules about over-posting, so I'm going
to endeavour to shut up after this.  But there's a subtle but, in my
opinion, mistaken parallelism here, and I want to challenge it.

On Tue, Jul 30, 2013 at 10:55:42AM +0800, Qiong wrote:

> For example, we now have NAT64 and so v6-only client can emerge and t=
alk to
> v4 server. So v6-only clients may be more and more in the future. I s=
ee
> nobody argues that if we have NAT64, v4 server may live in v4 forever=
.
>
> Then for v4-to-v6 scenario, this is the same since it will bring the
> ability to support v6-only server to be reachable by v4-only clients.
> Therefore, v6-only server may emerge because they do not need to worr=
y
> about losing v4 clients. So v6-only server maybe more and more in the
> future. This will promote v6-development, rather than the opposite on=
e.

The key reason to have defined NAT64 was because we had a supply
problem.  If you were a v6-only node, you couldn't reach servers on
the v4 Internet.  But _most_ things were on the v4 Internet.  So NAT64
gave us a way of permitting people to have v6-only connectivity
without paying the cost of losing access to the entire Internet.

The argument above turns this on its head, and says that if you are
standing up a service, you are worried about losing the possible
customers on v4-only networks.  Therefore, you will go dual stack.
Implicitly, if we say, "New v4 service bad," we think it would be
better that the service be v6-only.  So, we should have a mechanism by
which v4-only clients can access the v6 Internet, and this will in
some sense increase v6 use because the service is actually accessed
over v6.

I think the argument is subtle but wrong.  First, it depends on the
premise that there is an interesting population that will
(economically) remain v4-only while v6-only service deployment is in
some sense (likely economically) a reasonable plan.  As I already
argued elsewhere in this thread, that premise needs a lot of
supporting argument, because it seems to me to be false.  Second, it
confuses the goal of IPv6 deployment in the sense of native use with a
supposed goal of merely carrying traffic over v6.  The latter is not
an interesting goal in any sense: if tomorrow we simply encapsulated
all v4 traffic inside v6, I do not think it would be an interesting
advance in v6 deployment.  So I reject the claim that this sort of
4-to-6 NAT is a positive contributor to IPv6 deployment.  The right
message is, "If you want to reach this v6-only service, get a v6
address."  If the service is valuable, the customers will come, since
v6 communications are no longer an enormous big deal.

As for the risk that dual stack everywhere permits v4 to persist: so
what?  If v6 is working everywhere, then the v4 network will gradually
wither away because it is not economical to keep that network
interface active.  (Lee Howard has done interesting analysis in this
area, and his models at least suggest a pretty significant changeover
incentive once a not very large number of services come up on IPv6.)
The goal is not to make the evil, bad, wrong v4 go away, any more than
the goal was in itself to kill X.25 and dance about on its grave
singing hallelujah.  That was just a happy consequence.

> From the long history of IPv6 development, I think it is clear this
> assumption has never hardly existed. If anyone *ought to be able to g=
et a
> v6 address*, we would have reached the v6-world long ago, rather than
> debating how to transit.

Surely not.  V6 deployment has never been impeded by lack of v6
addresses.  As long as v4 was good enough and it was still possible to
get address space for reasonable cost, there was little incentive to
move to a network technology that seemed like it was still under
development.  But we're out of v4 addresses now, the experience is
_not_ good enough, and so one might suppose the incentives have changed.

Best,

A

--
Andrew Sullivan
ajs at anvilwalrusden.com
_______________________________________________
Behave mailing list
Behave at ietf.org
ht=
tps://www.ietf.org/mailman/listinfo/behave


<HTML><P><FONT face=3DArial color=3D#999999 size=3D1>

IZJAVA O ODRICANJU ODGOVORNOSTI: Sadr=C3=85aj ove poruke i eventualno pril=
o=C3=85enih datoteka je povjerljiv i namijenjen je samo osobama ili subjek=
tima koji su navedeni u adresi. Ukoliko ste primili ovu poruku gre=C3=85ko=
m, molimo Vas, obavijestite po=C3=85iljatelja, a poruku i sve njene privit=
ke odmah, bez =C3=84itanja, trajno uklonite s ra=C3=84unala. Bilo kakvo pr=
eno=C3=85enje, kopiranje ili distribucija informacija sadr=C3=85anih u por=
uci tre=C3=84im osobama je zabranjeno i mo=C3=85e biti zakonski ka=C3=85nj=
ivo. Sadr=C3=85aj, stavovi i mi=C3=85ljenja izneseni u poruci su autorovi =
i ne predstavljaju nu=C3=85no stavove HT - Hrvatskih telekomunikacija d.d.=
 HT ne prihva=C3=84a nikakvu odgovornost za eventualnu =C3=85tetu nastalu =
primitkom ove poruke i priloga sadr=C3=85anih u poruci.

</FONT></P><P><FONT face=3DArial color=3D#999999 size=
=3D1>

 DISCLAIMER:The contents of this email as well as any files attached to it=
 are confidential and intended solely for individuals or entities which th=
ey are addressed to. If you have received this email message in error, ple=
ase notify the sender and permanently remove the message and all attached =
files from the computer. Any disclosure, copying or distribution of all or=
 a part of information contained herein to or by third parties is prohibit=
ed and may be unlawful. Please note that any views or opinions presented i=
n this message are solely those of the author and do not necessarily repre=
sent the views and opinions of Croatian Telecom Inc. Croatian Telecom Inc.=
 accepts no liability for any potential damage caused by this message and =
files attached to it.

</FONT></P></HTML>
  • References:=20
    • [BEHAVE] Fwd: I-D Action:=20 draft-sun-behave-v4tov6-00.txt=20
      • From: Qiong
    • Re: [BEHAVE] Fwd: I-D Action:=20 draft-sun-behave-v4tov6-00.txt=20
      • From: Liu Dapeng
    • Re: [BEHAVE] Fwd: I-D Action:=20 draft-sun-behave-v4tov6-00.txt=20
      • From: Qiong
    • Re: [BEHAVE] Fwd: I-D Action:=20 draft-sun-behave-v4tov6-00.txt=20
      • From: Andrew Sullivan
    • Re: [BEHAVE] Fwd: I-D Action:=20 draft-sun-behave-v4tov6-00.txt=20
      • From: Simon Perreault
    • Re: [BEHAVE] Fwd: I-D Action:=20 draft-sun-behave-v4tov6-00.txt=20
      • From: Andrew Sullivan
    • Re: [BEHAVE] Fwd: I-D Action:=20 draft-sun-behave-v4tov6-00.txt=20
      • From: Qiong
    • Re: [BEHAVE] Fwd: I-D Action:=20 draft-sun-behave-v4tov6-00.txt=20
      • From: Andrew Sullivan
  • Prev by Date: Re:=20 [BEHAVE] draft-meng-behave-napgt can be met by PCP port set= =20
  • Next by Date: Re:=20 [BEHAVE] draft-meng-behave-napgt can be met by PCP port set= =20
  • Previous by thread: Re:=20 [BEHAVE] Fwd: I-D Action: draft-sun-behave-v4tov6-00.txt=20
  • Next by thread: Re:=20 [BEHAVE] Fwd: I-D Action: draft-sun-behave-v4tov6-00.txt=20
  • Index(es):=20
    • Date=20
    • Thread=20

Note: Messages sent to this list are the opinions of the senders and d= o not=20 imply endorsement

 
xiechf01-Gmail
------=_001_NextPart311384300757_=------ From tireddy@cisco.com Tue Jul 30 09:00:10 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA98B21F9C26 for ; Tue, 30 Jul 2013 09:00:08 -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 JaScZZMCB7Z7 for ; Tue, 30 Jul 2013 09:00:02 -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 84D1F21F9B5F for ; Tue, 30 Jul 2013 08:59:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2526; q=dns/txt; s=iport; t=1375199984; x=1376409584; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=ZyaW00zzRPJfDoFLJdaUc9A5/oDuZ48AxKTN6/kn6LI=; b=OJGrapD25svY/hw3hVOc4C5ESH97i4WHzmBha1YUSPuK6E6ZThGcA5RC zngvFnizMBrgSZ7tykFgkgDyLd1wEO/tuli2UCmUbpZ3CMqVmK2MslrGK FcQvwHrJpBT38VsVW/mM0cs6leq35FK30rwKs1w2qrX6l9kC3cyMRm2y7 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAJji91GtJXG9/2dsb2JhbABbgwY1UL4TgR0WdIIkAQEBAwEBAQEkRxcEAgEIEQQBAQEKDhYnCx0IAgQBEgiIAgYMuFePTTgGEoMAcQOIcpAWkCODFIIq X-IronPort-AV: E=Sophos;i="4.89,778,1367971200"; d="scan'208";a="241336440" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-7.cisco.com with ESMTP; 30 Jul 2013 15:59:43 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r6UFxglZ022798 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Jul 2013 15:59:42 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.159]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Tue, 30 Jul 2013 10:59:42 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "Prashanth Patil (praspati)" , Simon Perreault , "behave@ietf.org" Thread-Topic: [BEHAVE] Comments on the TURN REST Server API presentation Thread-Index: AQHOjTiRpEo4ItDKvEeFioaMwxZH3Jl9YGdg Date: Tue, 30 Jul 2013 15:59:42 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A19007CBE@xmb-rcd-x10.cisco.com> References: <51F755FA.5010400@viagenie.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.83.33] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [BEHAVE] Comments on the TURN REST Server API presentation X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 16:00:10 -0000 > -----Original Message----- > From: Prashanth Patil (praspati) > Sent: Tuesday, July 30, 2013 12:20 PM > To: Simon Perreault; behave@ietf.org > Subject: Re: [BEHAVE] Comments on the TURN REST Server API presentation >=20 >=20 >=20 > On 30/07/13 11:28 AM, "Simon Perreault" > wrote: >=20 > >Le 2013-07-30 06:37, Marc Petit-Huguenin a =E9crit : > >> Second, I do not think that trying to overload the long-term > >>authentication > >> mechanism is wise - and I take exceptions with the previous > >>presentation that > >> characterized long-term authentication as having problems. This is ho= w > >> long-term authentication works, and that should be left alone. IMO > >>what is > >> needed is to design a third authentication option for TURN (probably > >>with new > >> attributes) that is doing the username/password stateless verification= . > >> Here > >> there is a need to define how the web server and the turn server can > >> generate/verify the same username/password, so an I-D is required to > >>ensure > >> interoperability. > > > >After hearing the presentation and the discussion, that's the way I'm > >thinking too. I would expect that third option to not be > >username/password based, but rather token-based. Agreed. OAuth 2.0 framework could be used to solve the problem which discus= ses both self-contained and handle tokens. --Tiru. >=20 > Yes, a token based approach should be considered. A TURN server can then > also, more easily, cater to regular clients that want to use > username/password like they do today. >=20 > The draft does not provide details on the mechanics of shared secret > exchange between the web-server and turn-server. The assumption is that > the two are always well known to each other, but that not may not be the > case always - a turn server should be able to fetch shared secret from a > previously unknown server, on demand. Also, what if multiple web-servers > want to avail the services of the same turn server? How does the turn > server know which shared secret to choose, realm maybe? >=20 > -Prashanth >=20 > > > >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 > >_______________________________________________ > >Behave mailing list > >Behave@ietf.org > >https://www.ietf.org/mailman/listinfo/behave >=20 From mperumal@cisco.com Tue Jul 30 10:59:21 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4D3E11E8219 for ; Tue, 30 Jul 2013 10:59:20 -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 RqSCotrgGwVL for ; Tue, 30 Jul 2013 10:59:14 -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 D641F11E8106 for ; Tue, 30 Jul 2013 10:59:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2970; q=dns/txt; s=iport; t=1375207154; x=1376416754; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=0I2jVWy4hyVHA62YHehzgJvVzrqiNBwddET7laHwULY=; b=GRD2c+59R8h/s1dv25+4LJEU85uWP7oJ3bFVz79L2TEUoXc/9o4A9r5S pwOM04TTd8YBTkVYC1mDnlPMtVjXJ/9S1f3HiIeRDHmCBVXX/YC9BKZGF cYqUzkkpGpCFeJ98/Ss8uCkpst2s3PZ/WSYf+qeK9PWx7AebMbeJ+49Gh I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiQFAED+91GtJXHA/2dsb2JhbABbgwY1UIMQuwYXgQcWdIIkAQEBBCMRRQwEAgEIEQQBAQMCBh0DAgICMBQBCAgCBA4FCAyHfAymbZFdgSiLVoE4gRcWGwcGgl8zcQOZCJAjgxSBcTk X-IronPort-AV: E=Sophos;i="4.89,778,1367971200"; d="scan'208";a="241397457" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-5.cisco.com with ESMTP; 30 Jul 2013 17:59:13 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r6UHxD1e032247 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Jul 2013 17:59:13 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.27]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Tue, 30 Jul 2013 12:59:13 -0500 From: "Muthu Arul Mozhi Perumal (mperumal)" To: Marc Petit-Huguenin Thread-Topic: [BEHAVE] Comments on the TURN REST Server API presentation Thread-Index: AQHOjN52FJxox98FVEaUB36YwOMq2Zl8sqUggABi0QCAAGRZYA== Date: Tue, 30 Jul 2013 17:59:12 +0000 Message-ID: References: <51F742F8.3070903@acm.org> <51F75C86.4060400@acm.org> In-Reply-To: <51F75C86.4060400@acm.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.75.120] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "Behave@ietf.org" Subject: Re: [BEHAVE] Comments on the TURN REST Server API presentation X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 17:59:21 -0000 fC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQp8RnJvbTogTWFyYyBQZXRpdC1IdWd1ZW5pbiBb bWFpbHRvOnBldGl0aHVnQGFjbS5vcmddDQp8U2VudDogVHVlc2RheSwgSnVseSAzMCwgMjAxMyAx MTo1NiBBTQ0KfFRvOiBNdXRodSBBcnVsIE1vemhpIFBlcnVtYWwgKG1wZXJ1bWFsKQ0KfENjOiBC ZWhhdmVAaWV0Zi5vcmcNCnxTdWJqZWN0OiBSZTogW0JFSEFWRV0gQ29tbWVudHMgb24gdGhlIFRV Uk4gUkVTVCBTZXJ2ZXIgQVBJIHByZXNlbnRhdGlvbg0KfA0KfC0tLS0tQkVHSU4gUEdQIFNJR05F RCBNRVNTQUdFLS0tLS0NCnxIYXNoOiBTSEEyNTYNCnwNCnxPbiAwNy8zMC8yMDEzIDA3OjQwIEFN LCBNdXRodSBBcnVsIE1vemhpIFBlcnVtYWwgKG1wZXJ1bWFsKSB3cm90ZToNCnw+IE1hcmMsDQp8 Pg0KfD4gfFNlY29uZCwgSSBkbyBub3QgdGhpbmsgdGhhdCB0cnlpbmcgdG8gb3ZlcmxvYWQgdGhl IGxvbmctdGVybQ0KfD4gYXV0aGVudGljYXRpb24gfG1lY2hhbmlzbSBpcyB3aXNlIC0gYW5kIEkg dGFrZSBleGNlcHRpb25zIHdpdGggdGhlIHByZXZpb3VzDQp8PiBwcmVzZW50YXRpb24gdGhhdCB8 Y2hhcmFjdGVyaXplZCBsb25nLXRlcm0gYXV0aGVudGljYXRpb24gYXMgaGF2aW5nDQp8PiBwcm9i bGVtcy4NCnw+DQp8PiBXb3VsZCBpdCBiZSB3aXNlIHRvIHNheSB0aGVyZSBhcmUgaW5kZWVkIHBy b2JsZW1zIHdpdGggbG9uZy10ZXJtDQp8PiBhdXRoZW50aWNhdGlvbiBhbmQgZG9jdW1lbnQgdGhl bSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlIGNvbW11bml0eT8NCnw+DQp8DQp8VGhlcmUgaXMgbm8g dW5kb2N1bWVudGVkIHByb2JsZW0gd2l0aCBsb25nLXRlcm0gYXV0aGVudGljYXRpb24gKGFzIHRo aXMgaXMNCnxzaW1pbGFyIHRvIEhUVFAgZGlnZXN0KS4gIFRVUk4gb3ZlciBEVExTIGNhbiBoZWxw LCBhbmQgSSBwbGFuIHRvIHdyaXRlIGFuIEktRA0KfGRlc2NyaWJpbmcgaXQgYXMgSSBuZWVkIHRo ZSByZWZlcmVuY2UgaW4gYW5vdGhlciBkcmFmdCBkZXZlbG9wZWQgaW4gUDJQU0lQLg0KDQpXaGF0 IGFyZSB0aGUgbW90aXZhdGlvbnMgZm9yIHRoZSB0aGlyZCBhdXRoZW50aWNhdGlvbiBtZWNoYW5p c20gZm9yIFRVUk4gYW5kIHdoeSBpcyBUVVJOIG92ZXIgRFRMUyBuZWVkZWQ/DQoNCk11dGh1DQoN CnwNCnwtIC0tDQp8TWFyYyBQZXRpdC1IdWd1ZW5pbg0KfEVtYWlsOiBtYXJjQHBldGl0LWh1Z3Vl bmluLm9yZw0KfEJsb2c6IGh0dHA6Ly9ibG9nLm1hcmMucGV0aXQtaHVndWVuaW4ub3JnDQp8UHJv ZmlsZTogaHR0cDovL3d3dy5saW5rZWRpbi5jb20vaW4vcGV0aXRodWcNCnwtLS0tLUJFR0lOIFBH UCBTSUdOQVRVUkUtLS0tLQ0KfFZlcnNpb246IEdudVBHIHYxLjQuMTQgKEdOVS9MaW51eCkNCnwN CnxpUUljQkFFQkNBQUdCUUpSOTF5RUFBb0pFQ25FUlpYV2FuN0VYdnNRQU5PblZlQmh2Z251aElO N0tqN0NKUnlIDQp8RlJrWlZUUVArN3dpeDErSlBpZTlQUWF3eVFrSjRlZjNZVkswRC9XTkhKT3g3 RHRvQlV4RnNHeDY5dHR2WjZJUQ0KfEY2bWJXZmk3dm1HZVpobGM1NGRwZ2NPenNLNXpVeW5RZ1ZH My9qaWF0NExQRUVveTFQRGgxTTFlbFZkTmwwcXgNCnw0WlB0b0F6ZXA5VnFCaUR5R2xxRHg0bi95 RUtNSmdhc0YzU1FpaGhxc3huZmVTdkMxaEJ5ckhjMGVvMXV6QWExDQp8MGlKVGdWRFZUUURVUUQv Qlo2RXZrSjByczhJM2ZETS94YU14T0hwRUdXVFJhL2E4aXN6WEdSbFFrWnFtTHkwNQ0KfGJJMUVa TUlqa29nVU4wODZMdng5MmlJVTd5dVJVVG4wbUNvY21JNXdFaDRaTXFqcWs2MnExK0hKRmlsc0xQ dXoNCnxhVm41Y2tySmI3cHh2UWFPTHAvSld2cURXdExYVVNGK3prSlRWYjN1WXpZR1dRRWxFTVVJ eVRsQU5SdXEwTWRwDQp8TW50VmNQcndUTHhPekZ5bHdua3FaZ1JJV1E0YWdYUnJxN2orUG9ra0Jh bS96QzArd1pIVHJXbGIyVmJjVG1Zdw0KfHZGZlZLTHFQVVN3NHZHbVUrbk4rWXkxb0dXbWxCekZv WmRGVUhQeU1MN1krYkI3UXk2dVFzL1JHbE1Ud3JEMGYNCnxkS0QzRUNzUW01bTRGbTVZZEZCbmJk YVV1czJTRENZMWV5U0hWb1ZJRkp5WUxvNXRMUVhZNTRDNjNxVTJPM0pRDQp8b3VkU2pzQmlxRFMy ZzJMZjZHM0orMGRBWmdGQnVvYWQ5WWJPcTE1dVU4NkxlYkdsbEd4bUJlaWZqOWIvSGFjQw0KfG42 WWxxa0ZlTGZCbTlxT3lLdUhzDQp8PWNnL3ENCnwtLS0tLUVORCBQR1AgU0lHTkFUVVJFLS0tLS0N Cg== From juberti@google.com Wed Jul 31 04:56:55 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53BDF11E80F0 for ; Wed, 31 Jul 2013 04:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 Ztf0Bj3KKoW5 for ; Wed, 31 Jul 2013 04:56:53 -0700 (PDT) Received: from mail-oa0-x22f.google.com (mail-oa0-x22f.google.com [IPv6:2607:f8b0:4003:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 3FD8921E8125 for ; Wed, 31 Jul 2013 04:56:51 -0700 (PDT) Received: by mail-oa0-f47.google.com with SMTP id g12so783058oah.34 for ; Wed, 31 Jul 2013 04:56:50 -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; bh=W6KaKZ2D6MzvWcEbqsPasbe1H35yROCYNyzBRx3Uvuc=; b=YSYaz9f+skY+AK16ef2JFFN3EeaL2RUVC9fVGdsl4mleMH6igcFRq1vXNA4SNHD9+m uNbblLhBpuRMH8vSSINJfOTrWO7/brVhaJcsh89PF71uGRbe7hDguQBHlJMX6slHleBm iHIgTEH4HiQ2g9b4aaXEE9N/IwqplO0zx/Cewz4gE/qUj5zQY+EGf1Oo4sxwSo/LCkUY sg9cxtePZyPPhvbkQryfpxDU1/DX/1CrPJcl1OCZfgVcKeI+u0N4X/dAJSGXh495iHpf zFeArZX7A33Z/+7EKmXOrmKsdcA43DRRHEHG30mnUokL7pG8rCJUzxda33Sje5FDn3va 1uow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=W6KaKZ2D6MzvWcEbqsPasbe1H35yROCYNyzBRx3Uvuc=; b=TY45OIqcSIlNKGO9PPxeO827H/2u5/aYf3C3x6Ld7MTylwBg1lll75SlppkzsdQOKb CoW2nd+YIV0/DudbeF7S0EQlJAIIxKNzupCe1af6OQDMMpZgqDDqfXuAlO+kcMBBjcaS KXzfwD1TrCpS84VOyHL+5xzm9kuOS8v9SQvb0UHbvtrhghZlFRo8CiHwb38mo04bxYEF TM1rkKsgStCAqFMDF09BMX2uWUfgfr3yc1BHpqB0O/mi5kmzF56yPegKRqeF8NdUt9Wd 7k6DEXlB2nqyi2X7La/5L+a8Uh7zvVSbUJBPvfgCYP6tjpLbSjmXrrmDArSVXXJ6uBjU +Lrg== X-Received: by 10.43.65.144 with SMTP id xm16mr22172568icb.112.1375271810661; Wed, 31 Jul 2013 04:56:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.97.132 with HTTP; Wed, 31 Jul 2013 04:56:30 -0700 (PDT) In-Reply-To: <51F742F8.3070903@acm.org> References: <51F742F8.3070903@acm.org> From: Justin Uberti Date: Wed, 31 Jul 2013 13:56:30 +0200 Message-ID: To: Marc Petit-Huguenin Content-Type: multipart/alternative; boundary=bcaec51b1b6fbeac5c04e2cd6bf6 X-Gm-Message-State: ALoCoQn2wRKdIgGu0M8Sxb0rdaTSjbovmPUWbkQfxiJKB1zVtyqRmeLiVl3oSg5DWeW1s29Dbb07RZx4BQlTPb47LyVFtvE+zNqZpcSw/q3F4HWdF0VsRZiyO+G7skfrS052XQwPo8KFr2oARvqH/cogU/cK2kSrJm44N1VuWQi0Hl+4OHuWsIIiz2jR9qJK10Whdvl5DZ5m Cc: "Behave@ietf.org" Subject: Re: [BEHAVE] Comments on the TURN REST Server API presentation X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 11:56:55 -0000 --bcaec51b1b6fbeac5c04e2cd6bf6 Content-Type: text/plain; charset=UTF-8 On Tue, Jul 30, 2013 at 6:37 AM, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > About this presentation, I agree with what Martin Thomson said on the > microphone (trying to paraphrase from memory as the audio recording is not > available yet): There is no need to standardize a RESTful API because the > server can send the username/password in the web page that uses rtcweb, or > can > use any proprietary API between the javascript client and the server. > There > is no interoperability issue here. > I think rtcweb (including non-browser clients) would benefit from having a common interface defined to get access to TURN servers, so that it would be easy to use different providers. But perhaps the IETF is not the right forum for this. > > Second, I do not think that trying to overload the long-term authentication > mechanism is wise - and I take exceptions with the previous presentation > that > characterized long-term authentication as having problems. This is how > long-term authentication works, and that should be left alone. IMO what is > needed is to design a third authentication option for TURN (probably with > new > attributes) that is doing the username/password stateless verification. > Here > there is a need to define how the web server and the turn server can > generate/verify the same username/password, so an I-D is required to ensure > interoperability. > I think it's clear that there are limitations to long-term authentication. Some (cleartext USERNAME, dictionary attacks on M-I) can be largely mitigated if we add support for TURN over DTLS, which I think is a good idea. The others (rtcweb password exposure, TURN credential DB) are addressed by the ephemeral/token based approach. There seems to be a general desire to do this through OAuth, using either normal tokens that are checked back against the AS, or self-contained tokens which can be checked directly at the TURN server, so I will look at updating the draft to use OAuth. This will also resolve the issues raised about how separate web and TURN servers can share a secret. The main question here is whether this requires an update to the TURN protocol to specify a token-based auth mechanism, or if it is possible to overload the long-term auth mechanism, since I think they will be fairly similar in operation. > > Finally a small nit: In the presentation the wrong syntax was used for the > turn uri: the parameter name is transport=, not proto=. > My mistake. Thanks. > > Thanks. > > - -- > Marc Petit-Huguenin > Email: marc@petit-huguenin.org > Blog: http://blog.marc.petit-huguenin.org > Profile: http://www.linkedin.com/in/petithug > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.14 (GNU/Linux) > > iQIcBAEBCAAGBQJR90LqAAoJECnERZXWan7EoiMP/R90khv1Ez+2652uCRIBjNhS > JyGpoNNVsqaPFPHo9jJ5pvJu0qYEUKrzXwoZtRn80UFFUojJIFsx0XmzwkDl7qAq > hsz+rPxCvVL3iTBvNGSee8HEZiLzzSkba34nwDoH4qrVEiWX3njcJH1P1bfbrrhk > rOxVMTSoXK7P118RFp0iQYyfTAf5RlH292u9vrCRljW2OjE644APBNgWyEyoi/J5 > vJnPPvBSrR5hYftn0DrCRLsOm5PPc+6lZ23BzEa+0yJdp2C4Fez7Z4uHTMhw4bBP > UOpXb88ZpuUlcLUjj+XU9JMYm7VhP+CKZw+AkXMGXAmiMa4jc6Ria1sTkeCXdT8J > cXyyxjBl/CYuhxqMhM3Hxm2ifeV6jQEX5bdk+5y+Qp8Jg++cjjeNYd/Yt8uJPYe3 > nFxkKHAK4kr63NIwfPJFWfVE44NwbvmyCsHmTNcDXloq4DFeWGKxsEnngWjeSOIE > 3HddtKgcTtL8AtNY9FVlPZMlmDI+Lh9eO+l+05IRIizIDsL8w3WMlpCXiPfrUq1X > SQcCxMBJHSAINqMGT4U0sw+VAI6lCTAnJW9AQFZebdDmf2KAsWDxLGwkW0G47/yg > rwKGAZhi14OuMc8yY8eWIbU+KRxPUkbS3p7AWVh5qNhTXYdllVjzJORvZ584vp0I > RjEwVbloGz5LYN0CCCBh > =L8qI > -----END PGP SIGNATURE----- > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > --bcaec51b1b6fbeac5c04e2cd6bf6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Tue, Jul 30, 2013 at 6:37 AM, Marc Petit-Huguenin <= petithug@acm.org&= gt; wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

About this presentation, I agree with what Martin Thomson said on the
microphone (trying to paraphrase from memory as the audio recording is not<= br> available yet): =C2=A0There is no need to standardize a RESTful API because= the
server can send the username/password in the web page that uses rtcweb, or = can
use any proprietary API between the javascript client and the server. =C2= =A0There
is no interoperability issue here.

I th= ink rtcweb (including non-browser clients) would benefit from having a comm= on interface defined to get access to TURN servers, so that it would be eas= y to use different providers. But perhaps the IETF is not the right forum f= or this.
=C2=A0

Second, I do not think that trying to overload the long-term authentication=
mechanism is wise - and I take exceptions with the previous presentation th= at
characterized long-term authentication as having problems. =C2=A0This is ho= w
long-term authentication works, and that should be left alone. =C2=A0IMO wh= at is
needed is to design a third authentication option for TURN (probably with n= ew
attributes) that is doing the username/password stateless verification. =C2= =A0Here
there is a need to define how the web server and the turn server can
generate/verify the same username/password, so an I-D is required to ensure=
interoperability.

I think it's clea= r that there are limitations to long-term authentication. Some (cleartext U= SERNAME, dictionary attacks on M-I) can be largely mitigated if we add supp= ort for TURN over DTLS, which I think is a good idea.

The others (rtcweb password exposure, TURN credential D= B) are addressed by the ephemeral/token based approach. There seems to be a= general desire to do this through OAuth, using either normal tokens that a= re checked back against the AS, or self-contained tokens which can be check= ed directly at the TURN server, so I will look at updating the draft to use= OAuth. This will also resolve the issues raised about how separate web and= TURN servers can share a secret.=C2=A0

The main question here is whether this requires an upda= te to the TURN protocol to specify a token-based auth mechanism, or if it i= s possible to overload the long-term auth mechanism, since I think they wil= l be fairly similar in operation.

Finally a small nit: =C2=A0In the presentation the wrong syntax was used fo= r the
turn uri: =C2=A0the parameter name is transport=3D, not proto=3D.

My mistake. Thanks.=C2=A0

Thanks.

- --
Marc Petit-Huguenin
Email: marc@pe= tit-huguenin.org
Blog: htt= p://blog.marc.petit-huguenin.org
Profile: = http://www.linkedin.com/in/petithug
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)

iQIcBAEBCAAGBQJR90LqAAoJECnERZXWan7EoiMP/R90khv1Ez+2652uCRIBjNhS
JyGpoNNVsqaPFPHo9jJ5pvJu0qYEUKrzXwoZtRn80UFFUojJIFsx0XmzwkDl7qAq
hsz+rPxCvVL3iTBvNGSee8HEZiLzzSkba34nwDoH4qrVEiWX3njcJH1P1bfbrrhk
rOxVMTSoXK7P118RFp0iQYyfTAf5RlH292u9vrCRljW2OjE644APBNgWyEyoi/J5
vJnPPvBSrR5hYftn0DrCRLsOm5PPc+6lZ23BzEa+0yJdp2C4Fez7Z4uHTMhw4bBP
UOpXb88ZpuUlcLUjj+XU9JMYm7VhP+CKZw+AkXMGXAmiMa4jc6Ria1sTkeCXdT8J
cXyyxjBl/CYuhxqMhM3Hxm2ifeV6jQEX5bdk+5y+Qp8Jg++cjjeNYd/Yt8uJPYe3
nFxkKHAK4kr63NIwfPJFWfVE44NwbvmyCsHmTNcDXloq4DFeWGKxsEnngWjeSOIE
3HddtKgcTtL8AtNY9FVlPZMlmDI+Lh9eO+l+05IRIizIDsL8w3WMlpCXiPfrUq1X
SQcCxMBJHSAINqMGT4U0sw+VAI6lCTAnJW9AQFZebdDmf2KAsWDxLGwkW0G47/yg
rwKGAZhi14OuMc8yY8eWIbU+KRxPUkbS3p7AWVh5qNhTXYdllVjzJORvZ584vp0I
RjEwVbloGz5LYN0CCCBh
=3DL8qI
-----END PGP SIGNATURE-----
_______________________________________________
Behave mailing list
Behave@ietf.org = https://www.ietf.org/mailman/listinfo/behave

--bcaec51b1b6fbeac5c04e2cd6bf6-- From petithug@acm.org Wed Jul 31 07:28:30 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 942A621E8083 for ; Wed, 31 Jul 2013 07:28:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.018, 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 1L5ot9q4ZmiY for ; Wed, 31 Jul 2013 07:28:29 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id A528E21F9F1F for ; Wed, 31 Jul 2013 07:28:28 -0700 (PDT) Received: from [IPv6:2001:df8:0:64:ca0a:a9ff:fe2e:a4f6] (unknown [IPv6:2001:df8:0:64:ca0a:a9ff:fe2e:a4f6]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id B4A8B20454; Wed, 31 Jul 2013 16:28:16 +0200 (CEST) Message-ID: <51F91F0A.2070308@acm.org> Date: Wed, 31 Jul 2013 16:28:26 +0200 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130630 Icedove/17.0.7 MIME-Version: 1.0 To: "Muthu Arul Mozhi Perumal (mperumal)" References: <51F742F8.3070903@acm.org> <51F75C86.4060400@acm.org> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "Behave@ietf.org" Subject: Re: [BEHAVE] Comments on the TURN REST Server API presentation X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 14:28:31 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 07/30/2013 07:59 PM, Muthu Arul Mozhi Perumal (mperumal) wrote: > |-----Original Message----- |From: Marc Petit-Huguenin > [mailto:petithug@acm.org] |Sent: Tuesday, July 30, 2013 11:56 AM |To: Muthu > Arul Mozhi Perumal (mperumal) |Cc: Behave@ietf.org |Subject: Re: [BEHAVE] > Comments on the TURN REST Server API presentation | |-----BEGIN PGP SIGNED > MESSAGE----- |Hash: SHA256 | |On 07/30/2013 07:40 AM, Muthu Arul Mozhi > Perumal (mperumal) wrote: |> Marc, |> |> |Second, I do not think that > trying to overload the long-term |> authentication |mechanism is wise - and > I take exceptions with the previous |> presentation that |characterized > long-term authentication as having |> problems. |> |> Would it be wise to > say there are indeed problems with long-term |> authentication and document > them for the benefit of the community? |> | |There is no undocumented > problem with long-term authentication (as this is |similar to HTTP digest). > TURN over DTLS can help, and I plan to write an I-D |describing it as I > need the reference in another draft developed in P2PSIP. > > What are the motivations for the third authentication mechanism for TURN The server side implementation of the long-term authentication as proposed by Justin would be different than an server-side implementation of the long-term authentication described in RFC 5389. Having a different authentication protocol (on the wire) would permit to have TURN server implementation that can implement the two variants of long-term authentication (e.g. if a TURN server is used for both SIP and Webrtc) > and why is TURN over DTLS needed? For the same reasons HTTPS is needed for Digest Authentication. > > Muthu > > | |- -- |Marc Petit-Huguenin |Email: marc@petit-huguenin.org |Blog: > http://blog.marc.petit-huguenin.org |Profile: > http://www.linkedin.com/in/petithug |-----BEGIN PGP SIGNATURE----- > |Version: GnuPG v1.4.14 (GNU/Linux) | > |iQIcBAEBCAAGBQJR91yEAAoJECnERZXWan7EXvsQANOnVeBhvgnuhIN7Kj7CJRyH > |FRkZVTQP+7wix1+JPie9PQawyQkJ4ef3YVK0D/WNHJOx7DtoBUxFsGx69ttvZ6IQ > |F6mbWfi7vmGeZhlc54dpgcOzsK5zUynQgVG3/jiat4LPEEoy1PDh1M1elVdNl0qx > |4ZPtoAzep9VqBiDyGlqDx4n/yEKMJgasF3SQihhqsxnfeSvC1hByrHc0eo1uzAa1 > |0iJTgVDVTQDUQD/BZ6EvkJ0rs8I3fDM/xaMxOHpEGWTRa/a8iszXGRlQkZqmLy05 > |bI1EZMIjkogUN086Lvx92iIU7yuRUTn0mCocmI5wEh4ZMqjqk62q1+HJFilsLPuz > |aVn5ckrJb7pxvQaOLp/JWvqDWtLXUSF+zkJTVb3uYzYGWQElEMUIyTlANRuq0Mdp > |MntVcPrwTLxOzFylwnkqZgRIWQ4agXRrq7j+PokkBam/zC0+wZHTrWlb2VbcTmYw > |vFfVKLqPUSw4vGmU+nN+Yy1oGWmlBzFoZdFUHPyML7Y+bB7Qy6uQs/RGlMTwrD0f > |dKD3ECsQm5m4Fm5YdFBnbdaUus2SDCY1eySHVoVIFJyYLo5tLQXY54C63qU2O3JQ > |oudSjsBiqDS2g2Lf6G3J+0dAZgFBuoad9YbOq15uU86LebGllGxmBeifj9b/HacC > |n6YlqkFeLfBm9qOyKuHs |=cg/q |-----END PGP SIGNATURE----- > - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iQIcBAEBCAAGBQJR+R75AAoJECnERZXWan7EzY4P/RjYrTzVIXDrt/6rYmmXW+TR g71FZxMCSUhy0ODcKNkqDnAQr2As0GX27JgWnDqDLfzOb0n23BA/aVvaA5R3gv8B JYnVxXLAYf62xiNjx4h54AzQo5CutO01yBk2dvfV5AdosfHrcUfHLfjJsC7S3jJb 20YVv6MH+PqrsyAjNc4i4hGmFWZBbofpPc98SAZgiXjNE80pVOvgILSNQnKM4hT3 WnLNG1NGiSzUSGc8xmr6NDxuGG39JHFHP1UEk/I+t9XWUki6AVJ31N30Q15yM9lK UydlMuWJVGCfF+wM0VrwPIg3FRoICgNPyBAKG3P3ttYHlO4qoeBoQL251o/tgzZb n7FJ44Pr0tJqbjV1zVjMIOlxT+vHpEdbzSiE4AbXiuVcRww4tq9OmlMNFVs9v+i4 7RdlLg5xshomyH1TCVpEpkG9d1RKL1fma/hZitO1z6dbjf6U7lfjHcVlBQS0cgSF PzrxRnQhABLFp4laO4J4vQARcjAtToPgLE/TWDFjQqjqEVlzi9F7TcM+Euy9R298 frj5FiWacCjEjVO+3R5+m4SynW2F5lQ4jpRK/+NcN8xItgUsdyDn6TWBL7/EXWmS yTrjattLNIm8bUsWCHOr/C6BnRdLb9PbDfjerNVGN5FZ/+FySR6UY5vKnKKB7BMI HFrWrFxq3sak7uu8BUJG =82hG -----END PGP SIGNATURE----- From fippo@goodadvice.pages.de Wed Jul 31 07:51:04 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 308D321F8607 for ; Wed, 31 Jul 2013 07:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HnLm1g9J7WQq for ; Wed, 31 Jul 2013 07:50:58 -0700 (PDT) Received: from lo.psyced.org (lost.IN.psyced.org [188.40.42.221]) by ietfa.amsl.com (Postfix) with ESMTP id 0D0F721F9EA1 for ; Wed, 31 Jul 2013 07:50:55 -0700 (PDT) Received: from [130.129.18.133] (dhcp-1285.meeting.ietf.org [130.129.18.133]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id r6VEorXq014479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 31 Jul 2013 16:50:54 +0200 Message-ID: <51F9244D.5010905@goodadvice.pages.de> Date: Wed, 31 Jul 2013 16:50:53 +0200 From: Philipp Hancke User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: behave@ietf.org References: <51F742F8.3070903@acm.org> <51F75C86.4060400@acm.org> <51F91F0A.2070308@acm.org> In-Reply-To: <51F91F0A.2070308@acm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] Comments on the TURN REST Server API presentation X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 14:51:04 -0000 [...] >> What are the motivations for the third authentication mechanism for TURN > > The server side implementation of the long-term authentication as proposed by > Justin would be different than an server-side implementation of the long-term > authentication described in RFC 5389. Having a different authentication > protocol (on the wire) would permit to have TURN server implementation that > can implement the two variants of long-term authentication (e.g. if a TURN > server is used for both SIP and Webrtc) I do not think this is a problem. The authentication can be attempted first against the (known) set of sip users and if the user is not known, shared secret authentication is tried. The other difference between the two groups is that for ssauth users, the timestamp needs to be checked for expiration. The other way round this might be phrased as "expiration is indefinite for sip users". From petithug@acm.org Wed Jul 31 08:01:45 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F10C121F9ADA for ; Wed, 31 Jul 2013 08:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.015, 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 y1aU2akD6fFF for ; Wed, 31 Jul 2013 08:01:43 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB5021F9D5A for ; Wed, 31 Jul 2013 07:59:52 -0700 (PDT) Received: from [IPv6:2001:df8:0:64:ca0a:a9ff:fe2e:a4f6] (unknown [IPv6:2001:df8:0:64:ca0a:a9ff:fe2e:a4f6]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 973A720454; Wed, 31 Jul 2013 16:59:51 +0200 (CEST) Message-ID: <51F92672.6020506@acm.org> Date: Wed, 31 Jul 2013 17:00:02 +0200 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130630 Icedove/17.0.7 MIME-Version: 1.0 To: Justin Uberti References: <51F742F8.3070903@acm.org> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "Behave@ietf.org" Subject: Re: [BEHAVE] Comments on the TURN REST Server API presentation X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 15:01:45 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 07/31/2013 01:56 PM, Justin Uberti wrote: > > On Tue, Jul 30, 2013 at 6:37 AM, Marc Petit-Huguenin > wrote: > > About this presentation, I agree with what Martin Thomson said on the > microphone (trying to paraphrase from memory as the audio recording is not > available yet): There is no need to standardize a RESTful API because the > server can send the username/password in the web page that uses rtcweb, or > can use any proprietary API between the javascript client and the server. > There is no interoperability issue here. > > >> I think rtcweb (including non-browser clients) would benefit from having >> a common interface defined to get access to TURN servers, so that it >> would be easy to use different providers. I agree, but in this case you probably also need to define the mechanism to share the key with the provider of the TURN server. I would suggest to have the RESTful API and this key sharing mechanism in a separate document, and to keep the new authentication alone in this one (i.e. when the Web server and turn server are from the same provider, so key provisioning can stay unspecified). >> But perhaps the IETF is not the right forum for this. > > > > Second, I do not think that trying to overload the long-term > authentication mechanism is wise - and I take exceptions with the previous > presentation that characterized long-term authentication as having > problems. This is how long-term authentication works, and that should be > left alone. IMO what is needed is to design a third authentication option > for TURN (probably with new attributes) that is doing the username/password > stateless verification. Here there is a need to define how the web server > and the turn server can generate/verify the same username/password, so an > I-D is required to ensure interoperability. > > >> I think it's clear that there are limitations to long-term >> authentication. Some (cleartext USERNAME, dictionary attacks on M-I) can >> be largely mitigated if we add support for TURN over DTLS, which I think >> is a good idea. As I said I plan to release such I-D before Vancouver. > >> The others (rtcweb password exposure, TURN credential DB) are addressed >> by the ephemeral/token based approach. There seems to be a general desire >> to do this through OAuth, using either normal tokens that are checked >> back against the AS, or self-contained tokens which can be checked >> directly at the TURN server, so I will look at updating the draft to use >> OAuth. This will also resolve the issues raised about how separate web >> and TURN servers can share a secret. > >> The main question here is whether this requires an update to the TURN >> protocol to specify a token-based auth mechanism, or if it is possible to >> overload the long-term auth mechanism, since I think they will be fairly >> similar in operation. My vote is on specifying a token-based authentication mechanism. > > > Finally a small nit: In the presentation the wrong syntax was used for > the turn uri: the parameter name is transport=, not proto=. > > >> My mistake. Thanks. > - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iQIcBAEBCAAGBQJR+SZwAAoJECnERZXWan7EIywQAIP+RUdkihdwQjZDBocEAhvK /c8ILDNLa+S+zb/lCHkmOuJPHL+SjXPs5qxePbvtoKSd8TejwEZTF+eSFOkXZhVW os+8gtMLeDGUtFOFW60ATw8XazSKP0xJWrb60rMliUr0xQeoQhua948o62ldNdkO TKKIJ9I1aXJfkne0XzTuiQXw1y7lQ+b3tbOpYHRr19uXK0TGUAlZTvZnrC802CO6 yG6KdWzTAkyGZArOijVabTDvTF8mxLKHf2E6yQMQD2AD9nKmiYaOAceNGM97xt/d XQtAIl8oMwpkcPufKgMCGELF2nJdh8ALaWzjCeDyVwfuI8nIb+wFe95UQWM237c/ i8dO/Lg+LQoWSAyN3qZWR8HoUcxbfjOUnT73yHUk0q9eQIRbWYuo90PRdS0WtPJu MSdtv4UVogHKKdGUUP3xlsVjMqxzXfGoHrlVtQo4g+BTPDzbv7I43r5lQdftqX1G hoK/FKGIF0pT/QIs7y+Kb59W7UVajNaZl1Xhpm0EY+m2+kkYESqcZmnyiyVju7YI 4jRCYKpFcthyfj/qYJxZwy/hanmU4HUpfqIrqrOHMQRGkVhQOZQPobZ0cwpslPZd JDMjXKiwBP7pboEMW3ypGlPRzmIhO5WbuTBcUqmFXZ1Cm77ft0U0doi1D22FI5Cy /RUgBwhXYLGHLfNfFCOm =5PlB -----END PGP SIGNATURE----- From juberti@google.com Wed Jul 31 12:16:28 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B934C21F92C2 for ; Wed, 31 Jul 2013 12:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.144 X-Spam-Level: X-Spam-Status: No, score=-1.144 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 718l4wdkADjS for ; Wed, 31 Jul 2013 12:16:28 -0700 (PDT) Received: from mail-oa0-x234.google.com (mail-oa0-x234.google.com [IPv6:2607:f8b0:4003:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id EF8E021F880F for ; Wed, 31 Jul 2013 12:16:27 -0700 (PDT) Received: by mail-oa0-f52.google.com with SMTP id n12so2329345oag.39 for ; Wed, 31 Jul 2013 12:16:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=x393hKfmVPIDWL9LKh03qFkyBhnAuGrFsjWYet7S1Fs=; b=W/wICiC/xEfk+FwOCVnufWdzDD8motWpsKTcgmkKxTqYDCGC0LRQftE74ym16ob1IF 69DLQFyWziDmfUV+Hp368pEa+ZhZ2iLVZ5xm/PGWW27R41E1vhaha4IMfHUBI8r9ubt8 J2OOyRRjyhYnqSa+sM2LXmrvLR9lPOA2AmoZLu67JmvBkY3zlExdOGRZxGX+RUxOpytH d4DtftP4AiKSJvDp96sbfL7KZXW4W5gVT216YE8FMki3+7YVbZMAB53iJVC3+lrOzcu0 cCOpBST+lKLnd1XziiGNkAW6IhWDwO17xZKNb8lp6TlejXYcFzFUpR0q0tzh0QfxETsD 7YVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=x393hKfmVPIDWL9LKh03qFkyBhnAuGrFsjWYet7S1Fs=; b=NrVQRkOp7L4Vo9yYMmQyOzlV+kTDyDpmjk6zFUp7YMZ63o5xh+4Wn4f9AsjDgMO3Bm aVlzBRDvr7vgsMz401mMKUPDUL6h7KpC5n9SGOHsMko6bAvPvCdkkLnjhvfe0YTzGa9A zkslJ/FYqBQlsDTuauFc8+7dc4yWZhVD8pCfYI31E2uJaRZ5x4zPRundmrf4mMf1Bmyq /FpGqbPwkI30DgCltSA3E1P34cbKbfsij4yJnk+JgbKkQ8JlJuXqyMA6YnF7rW/a7qqo eh29Yp3UiOwTd5CxSJ6Xp0WsOMJiJ25x3LGMQaM48BJ5FIPRnF0p0FZ5trKuQsKtfxfu 839A== X-Received: by 10.42.128.140 with SMTP id m12mr874731ics.69.1375298186241; Wed, 31 Jul 2013 12:16:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.97.132 with HTTP; Wed, 31 Jul 2013 12:16:06 -0700 (PDT) In-Reply-To: <51F9244D.5010905@goodadvice.pages.de> References: <51F742F8.3070903@acm.org> <51F75C86.4060400@acm.org> <51F91F0A.2070308@acm.org> <51F9244D.5010905@goodadvice.pages.de> From: Justin Uberti Date: Wed, 31 Jul 2013 21:16:06 +0200 Message-ID: To: Philipp Hancke Content-Type: multipart/alternative; boundary=20cf3010e9efda06f404e2d38f2b X-Gm-Message-State: ALoCoQnaZS3SAzCkKF1/mkhm51AJgvmgzF75Dzk1O91W5MsLaTBLc4xDvDRNu8fN1uZ5NsWCXp7iKWLJk0JysyydzhE29XWOt45/BRp8CQQnOlt0264bobP4J4XnE0t6/h+1WP4wqI9srZFbrg/CrHyjc+73NogC/Q5KAOvOiklL68weKTneSSqWF0w4Ic0Qpb/8iRrMWJHE Cc: behave Subject: Re: [BEHAVE] Comments on the TURN REST Server API presentation X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 19:16:29 -0000 --20cf3010e9efda06f404e2d38f2b Content-Type: text/plain; charset=UTF-8 On Wed, Jul 31, 2013 at 4:50 PM, Philipp Hancke wrote: > [...] > > What are the motivations for the third authentication mechanism for TURN >>> >> >> The server side implementation of the long-term authentication as >> proposed by >> Justin would be different than an server-side implementation of the >> long-term >> authentication described in RFC 5389. Having a different authentication >> protocol (on the wire) would permit to have TURN server implementation >> that >> can implement the two variants of long-term authentication (e.g. if a TURN >> server is used for both SIP and Webrtc) >> > > I do not think this is a problem. The authentication can be attempted > first against the (known) set of sip users and if the user is not known, > shared secret authentication is tried. > > The other difference between the two groups is that for ssauth users, the > timestamp needs to be checked for expiration. The other way round this > might be phrased as "expiration is indefinite for sip users". To avoid the possible double check, we could just define a prefix that is part of the username, e.g. the complete username would be "rest:12345678:foo". > > ______________________________**_________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/**listinfo/behave > --20cf3010e9efda06f404e2d38f2b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Wed, Jul 31, 2013 at 4:50 PM, Philipp Hancke &= lt;fippo@goo= dadvice.pages.de> wrote:
[...]

What are the motivations for the third authentication mechanism for TURN

The server side implementation of the long-term authentication as proposed = by
Justin would be different than an server-side implementation of the long-te= rm
authentication described in RFC 5389. =C2=A0Having a different authenticati= on
protocol (on the wire) would permit to have TURN server implementation that=
can implement the two variants of long-term authentication (e.g. if a TURN<= br> server is used for both SIP and Webrtc)

I do not think this is a problem. The authentication can be attempted first= against the (known) set of sip users and if the user is not known, shared = secret authentication is tried.

The other difference between the two groups is that for ssauth users, the t= imestamp needs to be checked for expiration. The other way round this might= be phrased as "expiration is indefinite for sip users".

To avoid the possible double check, we could just defin= e a prefix that is part of the username, e.g. the complete username would b= e "rest:12345678:foo".

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

--20cf3010e9efda06f404e2d38f2b-- From fippo@goodadvice.pages.de Wed Jul 31 23:56:52 2013 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E411021F9C8C for ; Wed, 31 Jul 2013 23:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.109, 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 7t7f6fV-o8wp for ; Wed, 31 Jul 2013 23:56:47 -0700 (PDT) Received: from lo.psyced.org (lost.IN.psyced.org [188.40.42.221]) by ietfa.amsl.com (Postfix) with ESMTP id D139721F9C29 for ; Wed, 31 Jul 2013 23:56:46 -0700 (PDT) Received: from [130.129.18.133] (dhcp-1285.meeting.ietf.org [130.129.18.133]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id r716ufvK001696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 1 Aug 2013 08:56:45 +0200 Message-ID: <51FA06A9.9070500@goodadvice.pages.de> Date: Thu, 01 Aug 2013 08:56:41 +0200 From: Philipp Hancke User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: behave@ietf.org References: <51F742F8.3070903@acm.org> <51F75C86.4060400@acm.org> <51F91F0A.2070308@acm.org> <51F9244D.5010905@goodadvice.pages.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [BEHAVE] Comments on the TURN REST Server API presentation X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 06:56:52 -0000 Am 31.07.2013 21:16, schrieb Justin Uberti: [...] >> I do not think this is a problem. The authentication can be attempted >> first against the (known) set of sip users and if the user is not known, >> shared secret authentication is tried. >> >> The other difference between the two groups is that for ssauth users, the >> timestamp needs to be checked for expiration. The other way round this >> might be phrased as "expiration is indefinite for sip users". > > > To avoid the possible double check, we could just define a prefix that is > part of the username, e.g. the complete username would be > "rest:12345678:foo". For differentiating shared secret and sip users this shouldn't even be necessary since sip localparts typically don't contain a colon (see e.g. the table of disallowed characters in http://tools.ietf.org/html/draft-ietf-stox-core-00#section-4.2).