From sunqi.csnet.thu@gmail.com Tue Jan 1 08:04:52 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F8D521E803C for ; Tue, 1 Jan 2013 08:04:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ycAizOH81+ZM for ; Tue, 1 Jan 2013 08:04:51 -0800 (PST) Received: from mail-pb0-f46.google.com (mail-pb0-f46.google.com [209.85.160.46]) by ietfa.amsl.com (Postfix) with ESMTP id 0163A21E8039 for ; Tue, 1 Jan 2013 08:04:42 -0800 (PST) Received: by mail-pb0-f46.google.com with SMTP id wy7so7419733pbc.5 for ; Tue, 01 Jan 2013 08:04:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=1XgY/ksBHmhNaGVHKbcaoyA4QuTPfXZZ/Rab8+LQLx4=; b=h+XSBPiiNcup6WEHiAJ5npkvIaXzCsR2i6k383X3nf1WWOUY99Hx21jzOP75P5wPl+ c4GCaxOCN+iOek9N3O/P6bbX8EW0qDMha6fngr5has8AVv+jLccdxggFNWXdyIKNjgna Cm/gAacHQUdWnmYcYLMtQmxIyad0dunTOTvrtPH7dVT0WCndRf5f/oht5TUwqzJtFcSL s5BR4+1qgE5Ysy1Meceg+QO9c9s6/J5lf++Abzclfa+dRRcK9vwJvqRoj1aMInM3+Gmo KZ6Tym9AmiRs59nhuidqfC+66nsJNv++dwq2Xq8z++PhdRez8a9qZWScup/thf0G86kk 1Rxw== X-Received: by 10.68.129.40 with SMTP id nt8mr136537408pbb.113.1357056282423; Tue, 01 Jan 2013 08:04:42 -0800 (PST) Received: from [192.168.43.198] ([219.141.159.48]) by mx.google.com with ESMTPS id pv8sm26841872pbc.26.2013.01.01.08.04.35 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 01 Jan 2013 08:04:41 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=utf-8 From: Qi Sun In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E9D16E4C8@PUEXCB1B.nanterre.francetelecom.fr> Date: Wed, 2 Jan 2013 00:03:24 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <1D244C8C-EF2A-462D-90B0-C227E69C8C45@gmail.com> References: <50CEA09E.8000204@ericsson.com> <94C682931C08B048B7A8645303FDC9F36E9D16E4C8@PUEXCB1B.nanterre.francetelecom.fr> To: X-Mailer: Apple Mail (2.1084) Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] Second working group last call for draft-ietf-softwire-public-4over6-04 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jan 2013 16:04:52 -0000 Dear Med, As an extension to DS-Lite, Public 4over6 can support = intercommunications between nodes within the same domain with public = IPv4 address assigned. However, address sharing transition mechanism = can't do that, i.e. two nodes sharing the same address aren't able to = communicate directly. What's more, Public 4over6 CE, which uses a full IPv4 address, can work = as a server that is IPv4-globally reachable by the nodes outside the = domain. This is of great importance to ICP-side transition. In this = case, address sharing is not expected.=20 In general, there are major differences between pb4o6 and lw4o6. If we = put them together, some important features (as listed above) may be = lost. The mechanism can be confused on some functionality, like = intercommunications within a domain. I think public 4over6 is mature enough to move forward. Best Regards, Qi On 2012-12-17, at =E4=B8=8B=E5=8D=884:54, = wrote: > Dear Suresh, all, >=20 > With all due respect to the authors of this draft, I really think this = document should not move forward.=20 >=20 > The feature described in this draft can be easily integrated in the = current unified CPE effort (binding mode: MAP1:1/Lw4over6) or the = document needs to be extended to cover the port restriction feature. >=20 > Cheers, > Med >=20 >> -----Message d'origine----- >> De : softwires-bounces@ietf.org=20 >> [mailto:softwires-bounces@ietf.org] De la part de Suresh Krishnan >> Envoy=C3=A9 : lundi 17 d=C3=A9cembre 2012 05:34 >> =C3=80 : Softwires WG >> Cc : Yong Cui; Ralph Droms >> Objet : [Softwires] Second working group last call for=20 >> draft-ietf-softwire-public-4over6-04 >>=20 >> Hi all, >> This message starts a second softwire working group last call on >> advancing the draft about providing Public IPv4 over IPv6=20 >> Access Network >> as a Standards Track RFC. The authors believe that this version has >> addressed the issues raised during the previous WGLC. The draft >> is available at >>=20 >> http://www.ietf.org/id/draft-ietf-softwire-public-4over6-04.txt >> http://tools.ietf.org/html/draft-ietf-softwire-public-4over6-04 >>=20 >> Substantive comments and statements of support/opposition for = advancing >> this document should be directed to the mailing list. Editorial >> suggestions can be sent directly to the authors. The chairs=20 >> will send in >> their comments as well during the last call period. This last call = will >> conclude on January 4, 2013. >>=20 >> Regards, >> Suresh & Yong >>=20 >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >>=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From internet-drafts@ietf.org Wed Jan 2 23:51:56 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB0C121F89EE; Wed, 2 Jan 2013 23:51:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VvQGLa20bqat; Wed, 2 Jan 2013 23:51:56 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACCD221F8880; Wed, 2 Jan 2013 23:51:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130103075140.22251.22720.idtracker@ietfa.amsl.com> Date: Wed, 02 Jan 2013 23:51:40 -0800 Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-mesh-mib-01.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 07:51:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Softwires Working Group of the IETF. Title : Softwire Mesh Management Information Base(MIB) Author(s) : Yong Cui Jiang Dong Peng Wu Mingwei Xu Filename : draft-ietf-softwire-mesh-mib-01.txt Pages : 14 Date : 2013-01-02 Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular it defines objects for managing softwire mesh [RFC5565]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-mesh-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-softwire-mesh-mib-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-mesh-mib-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jiangsheng@huawei.com Thu Jan 3 16:49:58 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D36921F8C74 for ; Thu, 3 Jan 2013 16:49:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ecOgXYLOjVW for ; Thu, 3 Jan 2013 16:49:57 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5B01721F8BA1 for ; Thu, 3 Jan 2013 16:49:56 -0800 (PST) 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 ANE41235; Fri, 04 Jan 2013 00:49:55 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 4 Jan 2013 00:49:10 +0000 Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 4 Jan 2013 00:49:54 +0000 Received: from SZXEML545-MBS.china.huawei.com ([169.254.2.174]) by szxeml402-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Fri, 4 Jan 2013 08:49:51 +0800 From: Sheng Jiang To: Qiong , Suresh Krishnan Thread-Topic: [Softwires] Second working group last call for draft-ietf-softwire-public-4over6-04 Thread-Index: AQHN3BAYSUnsIf5l10WG+OUVkGkhx5gx0vmAgAafgEA= Date: Fri, 4 Jan 2013 00:49:50 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B9239FDBFE5@szxeml545-mbs.china.huawei.com> References: <50CEA09E.8000204@ericsson.com> In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B9239FDBFE5szxeml545mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Softwires WG , Yong Cui , Ralph Droms Subject: Re: [Softwires] Second working group last call for draft-ietf-softwire-public-4over6-04 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 00:49:58 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B9239FDBFE5szxeml545mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEgZm9yIHN1cHBvcnQuDQoNClNoZW5nDQoNCkZyb206IHNvZnR3aXJlcy1ib3VuY2VzQGlldGYu b3JnIFttYWlsdG86c29mdHdpcmVzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBRaW9u Zw0KU2VudDogTW9uZGF5LCBEZWNlbWJlciAzMSwgMjAxMiAxMTo0MSBBTQ0KVG86IFN1cmVzaCBL cmlzaG5hbg0KQ2M6IFNvZnR3aXJlcyBXRzsgWW9uZyBDdWk7IFJhbHBoIERyb21zDQpTdWJqZWN0 OiBSZTogW1NvZnR3aXJlc10gU2Vjb25kIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGZvciBkcmFm dC1pZXRmLXNvZnR3aXJlLXB1YmxpYy00b3ZlcjYtMDQNCg0KRGVhciBTdXJlc2gsDQpJIHN1cHBv cnQgdGhpcyBkb2N1bWVudCB0byBtb3ZlIGZvcndhcmQuIFRoaXMgdmVyc2lvbiBoYXMgc29sdmVk IGFsbCB0aGUgdGVjaG5pY2FsIGlzc3VlcywgYW5kIGl0IGlzIHF1aXRlIHNpbXBsZSBmb3Igc29t ZSBzcGVjaWZpYyB1c2UgY2FzZS4gSSB0aGluayBpdCBpcyByZWFkeSB0byBtb3ZlIGZvcndhcmQg OikNCk1lcnJ5IENocmlzdG1hcyBhbmQgSGFwcHkgbmV3IHllYXIgIQ0KUWlvbmcNCg0KT24gTW9u LCBEZWMgMTcsIDIwMTIgYXQgMTI6MzMgUE0sIFN1cmVzaCBLcmlzaG5hbiA8c3VyZXNoLmtyaXNo bmFuQGVyaWNzc29uLmNvbTxtYWlsdG86c3VyZXNoLmtyaXNobmFuQGVyaWNzc29uLmNvbT4+IHdy b3RlOg0KSGkgYWxsLA0KICBUaGlzIG1lc3NhZ2Ugc3RhcnRzIGEgc2Vjb25kIHNvZnR3aXJlIHdv cmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uDQphZHZhbmNpbmcgdGhlIGRyYWZ0IGFib3V0IHByb3Zp ZGluZyBQdWJsaWMgSVB2NCBvdmVyIElQdjYgQWNjZXNzIE5ldHdvcmsNCmFzIGEgU3RhbmRhcmRz IFRyYWNrIFJGQy4gVGhlIGF1dGhvcnMgYmVsaWV2ZSB0aGF0IHRoaXMgdmVyc2lvbiBoYXMNCmFk ZHJlc3NlZCB0aGUgaXNzdWVzIHJhaXNlZCBkdXJpbmcgdGhlIHByZXZpb3VzIFdHTEMuIFRoZSBk cmFmdA0KaXMgYXZhaWxhYmxlIGF0DQoNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0 Zi1zb2Z0d2lyZS1wdWJsaWMtNG92ZXI2LTA0LnR4dA0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1zb2Z0d2lyZS1wdWJsaWMtNG92ZXI2LTA0DQoNClN1YnN0YW50aXZlIGNv bW1lbnRzIGFuZCBzdGF0ZW1lbnRzIG9mIHN1cHBvcnQvb3Bwb3NpdGlvbiBmb3IgYWR2YW5jaW5n DQp0aGlzIGRvY3VtZW50IHNob3VsZCBiZSBkaXJlY3RlZCB0byB0aGUgbWFpbGluZyBsaXN0LiBF ZGl0b3JpYWwNCnN1Z2dlc3Rpb25zIGNhbiBiZSBzZW50IGRpcmVjdGx5IHRvIHRoZSBhdXRob3Jz LiBUaGUgY2hhaXJzIHdpbGwgc2VuZCBpbg0KdGhlaXIgY29tbWVudHMgYXMgd2VsbCBkdXJpbmcg dGhlIGxhc3QgY2FsbCBwZXJpb2QuIFRoaXMgbGFzdCBjYWxsIHdpbGwNCmNvbmNsdWRlIG9uIEph bnVhcnkgNCwgMjAxMy4NCg0KUmVnYXJkcywNClN1cmVzaCAmIFlvbmcNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClNvZnR3aXJlcyBtYWlsaW5nIGxp c3QNClNvZnR3aXJlc0BpZXRmLm9yZzxtYWlsdG86U29mdHdpcmVzQGlldGYub3JnPg0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zb2Z0d2lyZXMNCg0KDQoNCi0tDQo9PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpRaW9uZyBTdW4NCkNo aW5hIFRlbGVjb20gQmVpamluZyBSZXNlYXJjaCBJbnN0aXR1ZGUNCg0KDQpPcGVuIHNvdXJjZSBj b2RlOg0KbGlnaHR3ZWlnaHQgNG92ZXI2OiBodHRwOi8vc291cmNlZm9yZ2UubmV0L3Byb2plY3Rz L2xhZnQ2Lw0KUENQLW5hdGNvb3JkOiBodHRwOi8vc291cmNlZm9yZ2UubmV0L3Byb2plY3RzL3Bj cHBvcnRzZXRkZW1vLw0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT0NCg== --_000_5D36713D8A4E7348A7E10DF7437A4B9239FDBFE5szxeml545mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcy LjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mIzQzOzEg Zm9yIHN1cHBvcnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNoZW5nPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBi bHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHNvZnR3aXJlcy1ib3VuY2VzQGlldGYub3JnIFttYWls dG86c29mdHdpcmVzLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlFpb25n PGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgRGVjZW1iZXIgMzEsIDIwMTIgMTE6NDEgQU08YnI+ DQo8Yj5Ubzo8L2I+IFN1cmVzaCBLcmlzaG5hbjxicj4NCjxiPkNjOjwvYj4gU29mdHdpcmVzIFdH OyBZb25nIEN1aTsgUmFscGggRHJvbXM8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtTb2Z0d2ly ZXNdIFNlY29uZCB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBmb3IgZHJhZnQtaWV0Zi1zb2Z0d2ly ZS1wdWJsaWMtNG92ZXI2LTA0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+RGVh ciBTdXJlc2gsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5JIHN1 cHBvcnQgdGhpcyBkb2N1bWVudCB0byBtb3ZlIGZvcndhcmQuIFRoaXMgdmVyc2lvbiBoYXMgc29s dmVkIGFsbCB0aGUgdGVjaG5pY2FsIGlzc3VlcywgYW5kIGl0IGlzIHF1aXRlIHNpbXBsZSBmb3Ig c29tZSBzcGVjaWZpYyB1c2UgY2FzZS4gSSB0aGluayBpdCBpcyByZWFkeSB0byBtb3ZlIGZvcndh cmQgOik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPk1lcnJ5IENo cmlzdG1hcyBhbmQgSGFwcHkgbmV3IHllYXIgITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlFpb25nPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj5PbiBNb24sIERlYyAxNywgMjAxMiBhdCAxMjozMyBQTSwgU3VyZXNoIEtyaXNobmFuICZs dDs8YSBocmVmPSJtYWlsdG86c3VyZXNoLmtyaXNobmFuQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPnN1cmVzaC5rcmlzaG5hbkBlcmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ SGkgYWxsLDxicj4NCiZuYnNwOyBUaGlzIG1lc3NhZ2Ugc3RhcnRzIGEgc2Vjb25kIHNvZnR3aXJl IHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uPGJyPg0KYWR2YW5jaW5nIHRoZSBkcmFmdCBhYm91 dCBwcm92aWRpbmcgUHVibGljIElQdjQgb3ZlciBJUHY2IEFjY2VzcyBOZXR3b3JrPGJyPg0KYXMg YSBTdGFuZGFyZHMgVHJhY2sgUkZDLiBUaGUgYXV0aG9ycyBiZWxpZXZlIHRoYXQgdGhpcyB2ZXJz aW9uIGhhczxicj4NCmFkZHJlc3NlZCB0aGUgaXNzdWVzIHJhaXNlZCBkdXJpbmcgdGhlIHByZXZp b3VzIFdHTEMuIFRoZSBkcmFmdDxicj4NCmlzIGF2YWlsYWJsZSBhdDxicj4NCjxicj4NCjxhIGhy ZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi1zb2Z0d2lyZS1wdWJsaWMtNG92 ZXI2LTA0LnR4dCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQt aWV0Zi1zb2Z0d2lyZS1wdWJsaWMtNG92ZXI2LTA0LnR4dDwvYT48YnI+DQo8YSBocmVmPSJodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXNvZnR3aXJlLXB1YmxpYy00b3ZlcjYt MDQiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LXNvZnR3aXJlLXB1YmxpYy00b3ZlcjYtMDQ8L2E+PGJyPg0KPGJyPg0KU3Vic3RhbnRpdmUgY29t bWVudHMgYW5kIHN0YXRlbWVudHMgb2Ygc3VwcG9ydC9vcHBvc2l0aW9uIGZvciBhZHZhbmNpbmc8 YnI+DQp0aGlzIGRvY3VtZW50IHNob3VsZCBiZSBkaXJlY3RlZCB0byB0aGUgbWFpbGluZyBsaXN0 LiBFZGl0b3JpYWw8YnI+DQpzdWdnZXN0aW9ucyBjYW4gYmUgc2VudCBkaXJlY3RseSB0byB0aGUg YXV0aG9ycy4gVGhlIGNoYWlycyB3aWxsIHNlbmQgaW48YnI+DQp0aGVpciBjb21tZW50cyBhcyB3 ZWxsIGR1cmluZyB0aGUgbGFzdCBjYWxsIHBlcmlvZC4gVGhpcyBsYXN0IGNhbGwgd2lsbDxicj4N CmNvbmNsdWRlIG9uIEphbnVhcnkgNCwgMjAxMy48YnI+DQo8YnI+DQpSZWdhcmRzLDxicj4NClN1 cmVzaCAmYW1wOyBZb25nPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQpTb2Z0d2lyZXMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJl Zj0ibWFpbHRvOlNvZnR3aXJlc0BpZXRmLm9yZyI+U29mdHdpcmVzQGlldGYub3JnPC9hPjxicj4N CjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc29mdHdpcmVz IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z b2Z0d2lyZXM8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48 YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8YnI+DQotLSA8YnI+DQo9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PGJyPg0KUWlvbmcgU3VuPGJyPg0KQ2hpbmEgVGVs ZWNvbSBCZWlqaW5nIFJlc2VhcmNoIEluc3RpdHVkZTxicj4NCjxicj4NCjxicj4NCk9wZW4gc291 cmNlIGNvZGU6PGJyPg0KbGlnaHR3ZWlnaHQgNG92ZXI2OiA8aT48YSBocmVmPSJodHRwOi8vc291 cmNlZm9yZ2UubmV0L3Byb2plY3RzL2xhZnQ2LyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9zb3Vy Y2Vmb3JnZS5uZXQvcHJvamVjdHMvbGFmdDYvPC9hPjwvaT48YnI+DQpQQ1AtbmF0Y29vcmQ6PGk+ IDxhIGhyZWY9Imh0dHA6Ly9zb3VyY2Vmb3JnZS5uZXQvcHJvamVjdHMvcGNwcG9ydHNldGRlbW8v IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwOi8vc291cmNlZm9yZ2UubmV0L3Byb2plY3RzL3BjcHBv cnRzZXRkZW1vLzwvYT4gPC9pPjxicj4NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_5D36713D8A4E7348A7E10DF7437A4B9239FDBFE5szxeml545mbschi_-- From leo.liubing@huawei.com Thu Jan 3 17:51:34 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C347F21F8E40 for ; Thu, 3 Jan 2013 17:51:34 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ZLDrvJqF1TS for ; Thu, 3 Jan 2013 17:51:34 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 108C421F8E3B for ; Thu, 3 Jan 2013 17:51:32 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOK71436; Fri, 04 Jan 2013 01:51:29 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 4 Jan 2013 01:50:31 +0000 Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 4 Jan 2013 01:51:26 +0000 Received: from SZXEML509-MBX.china.huawei.com ([10.82.67.37]) by szxeml402-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Fri, 4 Jan 2013 09:51:20 +0800 From: "Liubing (Leo)" To: Suresh Krishnan , Softwires WG Thread-Topic: [Softwires] Second working group last call for draft-ietf-softwire-public-4over6-04 Thread-Index: AQHN3BAYCXe6uLJNN02WO2m6letEIJg4fH1g Date: Fri, 4 Jan 2013 01:51:20 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453CD00120@szxeml509-mbx> References: <50CEA09E.8000204@ericsson.com> In-Reply-To: <50CEA09E.8000204@ericsson.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.161] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Yong Cui , Ralph Droms Subject: Re: [Softwires] Second working group last call for draft-ietf-softwire-public-4over6-04 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 01:51:34 -0000 Dear Chairs & WG, I support advancing it.=20 Public IPv4 in 4over6 is a useful use case, especially for the operators wh= o still have plenty of reserved public IPv4 addresses. The architecture is simple, and the v4 address provision is different from = the other 4over6 solutions, so it is quite reasonable to make it as an inde= pendent standard track.=20 All the best Bing > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On > Behalf Of Suresh Krishnan > Sent: Monday, December 17, 2012 12:34 PM > To: Softwires WG > Cc: Yong Cui; Ralph Droms > Subject: [Softwires] Second working group last call for > draft-ietf-softwire-public-4over6-04 >=20 > Hi all, > This message starts a second softwire working group last call on > advancing the draft about providing Public IPv4 over IPv6 Access Network > as a Standards Track RFC. The authors believe that this version has > addressed the issues raised during the previous WGLC. The draft > is available at >=20 > http://www.ietf.org/id/draft-ietf-softwire-public-4over6-04.txt > http://tools.ietf.org/html/draft-ietf-softwire-public-4over6-04 >=20 > Substantive comments and statements of support/opposition for advancing > this document should be directed to the mailing list. Editorial > suggestions can be sent directly to the authors. The chairs will send in > their comments as well during the last call period. This last call will > conclude on January 4, 2013. >=20 > Regards, > Suresh & Yong >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From tom.taylor.stds@gmail.com Fri Jan 4 16:32:33 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 450D821F8A9B for ; Fri, 4 Jan 2013 16:32:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wAZi3zC4zJGB for ; Fri, 4 Jan 2013 16:32:32 -0800 (PST) Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) by ietfa.amsl.com (Postfix) with ESMTP id 340B721F8A6D for ; Fri, 4 Jan 2013 16:32:24 -0800 (PST) Received: by mail-ie0-f178.google.com with SMTP id c12so20251643ieb.37 for ; Fri, 04 Jan 2013 16:32:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding:x-antivirus :x-antivirus-status; bh=OLpwBtKN9d7/+l8ttwbT1l2ucAzDCEe8YGptjGNEpaU=; b=ElZSdM6JfWzaqNPefu0rATSg2w8LAWeyxzqk11vBo8dX3P4Psj5SyrpQJa9MZoU/qI Q9ymyAnZJofC7Dd4nTs0zx8opKjyNYo/qvMcgkzejjZPpKonEnplWyBzyBid6wQBgDxP /lkiOuv10wzqvEYw5tfyn3LnzRzUKVz+YBMnnNRA3CclFnShVBF6hvAynb1mcWoeugsS n8NXvG+u+MBRBNTA0XxulLb6kHrdwJ6d3bMaCldH1ewo635Kf4aceNYbRkEk+SltPCtU PzdkSB8Ne4lhEnAJCSmqHHMXoNsX+WELPdgUdmE9uHqtoe8wSi02MRyjm0ZC/zQoXKIs FwOQ== X-Received: by 10.42.72.132 with SMTP id o4mr30035431icj.44.1357345943803; Fri, 04 Jan 2013 16:32:23 -0800 (PST) Received: from [127.0.0.1] (dsl-173-206-100-109.tor.primus.ca. [173.206.100.109]) by mx.google.com with ESMTPS id k5sm981169igq.9.2013.01.04.16.32.21 (version=SSLv3 cipher=OTHER); Fri, 04 Jan 2013 16:32:23 -0800 (PST) Message-ID: <50E77496.2080808@gmail.com> Date: Fri, 04 Jan 2013 19:32:22 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Softwires , Ole Troan , Wojciech Dec , Xing Li , congxiao@cernet.edu.cn, satoru.matsushima@g.softbank.co.jp, tetsuya@ipinfusion.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130104-0, 04/01/2013), Outbound message X-Antivirus-Status: Clean Subject: [Softwires] Section 5.2 of draft-ietf-softwire-map-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2013 00:32:33 -0000 I find Section 5.2 of draft-ietf-softwire-map-02 very confusing as it stands. It doesn't help that the figures are misplaced and algebraic symbols are reused or used redundantly. I believe the explanation of the various address derivations has to be tied together with some introductory text, then at least one step has to be added at the start. The flow should go something like this: 5.2 Deriving the MAP Address From the End-User IPv6 Prefix and the Basic Mapping Rule 5.2.1 Structure of the End-User IPv6 Prefix 5.2.2 Deriving the MAP IPv6 Prefix 5.2.3 Deriving the MAP IPv6 Interface Identifier 5.2.4 Deriving the Port-Set Associated With the CE 5.2.5 Example The text fleshing this out follows. If something seems wrong, blame my misunderstanding and please correct me. I see that, contrarily to a previous note, it isn't necessary to specify the sharing ratio explicitly as part of the Mapping Rule. Hope this helps. Tom Taylor 5.2 Deriving the MAP IPv6 Address From the End-User IPv6 Prefix and the Basic Mapping Rule As indicated above, the end-user IPv6 prefix is an IPv6 prefix provisioned on the CE and unique to it. This prefix has a special structure described in the next section. The MAP IPv6 address is the address used by other MAP nodes to reach the MAP function of this node. It is constructed using the end-user IPv6 prefix and other information contained in the Basic Mapping Rule. 5.2.1 Structure of the End-User IPv6 Prefix The end-user IPv6 prefix is illustrated in Figure 3. It consists of two parts: a common initial prefix of length n bits followed by a part of length (o + p) bits that is specific to the CE. The initial n bits MUST match the IPv6 prefix given by the Basic MAP Rule applicable to the CE. The o bits immediately following the common initial prefix constitute the Embedded Address (EA), described further below. Additional bits are optional. | n bits | o bits | p bits | +-------------------------+-----------+--------------+ | Common initial prefix | EA bits | Opt. add't'l | +-------------------------+-----------+--------------+ Figure 3: End-user IPv6 prefix format 5.2.2 Structure of the Embedded Address Field (EA Bits) Recall that the Basic Mapping Rule provides the following parameters: * Rule IPv6 prefix (including prefix length n) * Rule IPv4 prefix (including prefix length r). This prefix and length MAY be provisioned either as an explicit part of the Mapping Rule or by other means (e.g., DHCPv6). The length r in the Mapping Rule MAY be 0, indicating that the EA bits contain a complete prefix or address (see below). * Rule EA-bits length (o) * Excluded ports (default, the first block of 4096 ports) [Comment: I don't think this is operationally necessary. Would an operator want to avoid any more than the system ports? More get pulled in because of the block size, but that is implicit and need not be spelled out in the Mapping Rule.] * Offset bits (a, from Section 5.1.3) (default, 4 bits, corresponding to a block size of 4096) One can see that the position of the EA bits within the end-user IPv6 prefix is determined by the values n and o in the Basic Map Rule. The Embedded Address field may be interpreted in any one of four ways, depending on the values of r and o in the Basic Mapping Rule. In all cases, the ability to include part of all of an IPv4 address in that field allows multiple CEs to use the same Basic Mapping Rule if so desired. a. Partial or complete IPv4 prefix: The sum r + o is less than 32. The complete prefix is equal to the concatenation of the Rule IPv4 prefix (or its separately provisioned equivalent) and the contents of the Embedded Address field, as shown in Figure 4. | r bits | o bits | +-------------+---------+ | Rule IPv4 | EA bits | +-------------+---------+ | < 32 bits | Figure 4: IPv4 prefix b. Partial or complete IPv4 address: The sum r + o is 32 exactly. The complete address is equal to the concatenation of the Rule IPv4 prefix (or its separately provisioned equivalent) and the contents of the Embedded Address field, as shown in Figure 5. | r bits | o bits | +-------------+---------+ | Rule IPv4 | EA bits | +-------------+---------+ | 32 bits | Figure 5: Complete IPv4 Address c. Shared IPv4 address: The sum r + o is greater than 32. The EA bits contain the concatenation of an IPv4 suffix with the PSID identifying the port-set associated with this CE. The length of the IPv4 suffix is given by the difference (32 - r), with the remaining bits belonging to the PSID. Figure 6 shows the derivation of the shared IPv4 address and the PSID from the Rule IPv4 address (or its separately provisioned equivalent) and the Embedded Address field. The width (o - (32 - r) bits) of the PSID field MUST be equal to the logarithm base 2 of the sharing ratio R (i.e., the value k defined in Section 5.1.1). | Embedded Address (EA) (o bits) | +---------------------+--------------------+ | (32 - r) bits | o - (32 - r) bits | +---------------------+--------------------+ | IPv4 Address suffix | Port-Set ID | +---------------------+--------------------+ \ \ \ \ \ \ | r bits | (32 - r) bits | +-------------+---------------------+ | Rule IPv4 | IPv4 Address suffix | +-------------+---------------------+ | 32 bits | | Shared IPv4 address | Figure 6: Derivation of Shared IPv4 Address and PSID From the EA Bits and Rule IPv4 Prefix d. Address Independence The length r MAY be 32, with no part of the IPv4 address embedded in the EA bits. This results in a mapping with no dependence between the IPv4 address and the IPv6 address. In addition the length o MAY be zero (no EA bits embedded in the End-User IPv6 prefix), meaning that the PSID is also provisioned using, e.g., a DHCP option. 5.2.2 Deriving the MAP IPv6 Prefix The MAP IPv6 prefix has the structure shown in Figure 7. The MAP IPv6 is created by combining the End-User IPv6 prefix with the all-zero subnet ID and the MAP IPv6 interface identifier. | n + o + p bits | s bits | 128-n-o-p-s bits | +--------------------------------+---------+------------+----------+ | End-user IPv6 prefix |subnet ID| interface ID | +--------------------------------+---------+-----------------------+ Figure 7: MAP IPv6 Address Format The end-user IPv6 prefix was described in Section 5.2.1. The subnet ID field, as just indicated, MUST be all zeroes. A MAP node MUST reserve the all-zero subnet ID for the purpose of MAP. The interface ID MUST be constructed as described in the next sub-section. 5.2.3 Deriving the MAP IPv6 Interface Identifier The Interface identifier format of a MAP node is based on the format specified in section 2.2 of [RFC6052] for a prefix length of 64 bits, with the PSID field added as a suffix if present, as shown in Figure 8. +--+---+---+---+---+---+---+---+---+ |PL| 8 16 24 32 40 48 56 | +--+---+---+---+---+---+---+---+---+ |64| u | IPv4 address | PSID | 0 | +--+---+---+---+---+---+---+---+---+ Figure 8 In the case of an IPv4 prefix, the IPv4 address field is right-padded with zeroes up to 32 bits. The PSID field is left-padded to create a 16 bit field. For an IPv4 prefix or a complete IPv4 address, the PSID field is zero. If the End-user IPv6 prefix length is larger than 64, the most significant parts of the interface identifier are overwritten by the prefix. [COMMENT: the above is copied almost exactly from the existing text, with some expansion in the first paragraph. If the u bits are overwritten, this no longer conforms to RFC 6052. Maybe that attribution should be deleted?] 5.2.4 Deriving the Port-Set Associated With the CE Looking back at Section 5.1 and Figure 2 in Section 5.1.1, recall that the set of port numbers valid for a given CE is calculated using the PSID and two indices i and j. Assume as in Section 5.1.1 that the sharing ratio R and the maximum number M of consecutive ports allocated to a given CE are powers of 2. Then the block index j ranges from a minimum that excludes the system ports, up to the maximum supported by a field that is 'a' bits wide. The PSID occupies a field k bits wide, and the port index i occupies the remaining low-order bits of the port number. From the immediately preceding sub-sections, we have: a is given directly as part of the Basic Mapping Rule; k may be assumed to have the value o - (32 - r), the width of the PSID field in the EA bits, where o and r come from the Basic Mapping Rule; the width m of the port index field is equal to the remainder 16 - a - (o - (32 - r)), or 48 - r - a - o. 5.2.4 Example In the following example, only the suffix (last 8 bits) of the IPv4 address is embedded in the EA bits (r = 24), while the IPv4 prefix (first 24 bits) is given in the BMR Rule IPv4 prefix. Given: End-user IPv6 prefix: 2001:db8:0012:3400::/56 Basic Mapping Rule: {2001:db8:0000::/40 (Rule IPv6 prefix), 192.0.2.0/24 (Rule IPv4 prefix), 16 (Rule EA-bits length)} PSID offset: 4 (default value as per section 5.1.3) The above information gives directly: n = 40 r = 24 o = 16 a = 4 Since r + o = 40 > 32 and r is less than 32, we are looking at a shared IPv4 address rule. Now we can derive the other values we need to calculate the port-set: EA bits are bits 41-56 of the end-user IPv6 prefix, or 0x1234 PSID field width k = 16 - (32 - 24) = 8 bits PSID itself is 0x34 Port index field width m = 16 - a - k = 4 bits From the above one can determine that the port-set consists of a range of 16 consecutive values in each of 15 blocks (the first potential block being excluded). The ranges are as follows: 0x1340-0x134f ( 4928- 4943) 0x2340-0x234f ( 9024- 9039) ... ... 0xf340-0xf34f (62272-62287) As shown in Figure 6, the shared IPv4 address is obtained by concatenating the Rule IPv4 prefix with the suffix given by the upper 8 bits of the EA bit field. Those upper 8 bits are 0x12, or 18 decimal. Hence the shared IPv4 address is 192.0.2.18. Given that the end-user IPv6 prefix is 56 bits long, a subnet identifier field of 8 bits can be allocated while conforming with the interface identifier structure described in Section 5.2.3. The complete MAP IPv6 address then becomes: 2001:db8:0012:3400:00a0:0002:1200:3400 From agmalis@gmail.com Mon Jan 7 08:10:17 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43A1B21F8933; Mon, 7 Jan 2013 08:10:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5a-kxxq4t-+D; Mon, 7 Jan 2013 08:10:16 -0800 (PST) Received: from mail-qc0-f180.google.com (mail-qc0-f180.google.com [209.85.216.180]) by ietfa.amsl.com (Postfix) with ESMTP id D9A3F21F8948; Mon, 7 Jan 2013 08:10:03 -0800 (PST) Received: by mail-qc0-f180.google.com with SMTP id v28so12728669qcm.11 for ; Mon, 07 Jan 2013 08:10:03 -0800 (PST) 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=+or99Gpu8hveajeTJfRMl8slHA5XhWXPvewZr5VGoXM=; b=eMB254dLijA2+Mrq+nqX0zEP4kiV3fwr4pJgc5U2ZzvKKOB4sYGAKF68IaFyB30Agn cScSLRujE+87sT4iIBRU1HCKOCyQwVcVQJQMoY3v0UsQCCe6+HM5jqCFmQrrhgwEGaMV NVLxHpJmcNgq2V3RResiQjABY+U3QklguY6ECYhBy3W483YZe4NWQhL03afzyqOfP4iz Z28t7zJ3+KujNtgMJuC56YxlfDeWz36ZfAd33JJBAZdmy6UABFrGsTE3a2MpwyLSJ6uD v27j9EBGwnoz23LfpTs39W2Xhz6VOwmKS9X2DS1BirW+XyJLLjN7KZlllioBxvbk1j7+ MuPw== Received: by 10.224.72.197 with SMTP id n5mr44463821qaj.38.1357575003368; Mon, 07 Jan 2013 08:10:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.78.72 with HTTP; Mon, 7 Jan 2013 08:09:43 -0800 (PST) In-Reply-To: <0A534525-59E1-418E-826B-177655767B17@gmail.com> References: <0A534525-59E1-418E-826B-177655767B17@gmail.com> From: "Andrew G. Malis" Date: Mon, 7 Jan 2013 11:09:43 -0500 Message-ID: To: Damien Saucez Content-Type: multipart/alternative; boundary=20cf3071d1dad4ee9104d2b50f93 Cc: Softwires@ietf.org, LISP mailing list list , draft-xu-softwire-ip-in-udp@tools.ietf.org Subject: Re: [Softwires] draft-xu-softwire-ip-in-udp X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 16:10:17 -0000 --20cf3071d1dad4ee9104d2b50f93 Content-Type: text/plain; charset=ISO-8859-1 For the benefit of those of you that don't follow the MPLS WG list, this draft is closely related to http://tools.ietf.org/html/draft-xu-mpls-in-udp-06 , which is the subject of a lively discussion there. Cheers, Andy On Sun, Dec 30, 2012 at 3:45 PM, Damien Saucez wrote: > Hello, > > Interesting document, have you ever though of LISP to do that? > > Regards, > > Damien Saucez > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --20cf3071d1dad4ee9104d2b50f93 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
For the benefit of those of you that don't follow= the MPLS WG list, this draft is closely related to http://tools.ietf.org/html/draft-xu= -mpls-in-udp-06 , which is the subject of a lively discussion there.
Cheers,
Andy


On Sun, Dec 30, 2012 at 3:45 PM, Damien Saucez <damien.saucez@gmail.com> wrote:
Hello,

Interesting document, have you ever though of LISP to do that?

Regards,

Damien Saucez
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

--20cf3071d1dad4ee9104d2b50f93-- From agmalis@gmail.com Wed Jan 9 05:50:14 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B58521F86CB; Wed, 9 Jan 2013 05:50:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.043 X-Spam-Level: X-Spam-Status: No, score=-3.043 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1nvwJUWDzAMH; Wed, 9 Jan 2013 05:50:12 -0800 (PST) Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB0F21F86C3; Wed, 9 Jan 2013 05:50:12 -0800 (PST) Received: by mail-qa0-f52.google.com with SMTP id d13so660823qak.18 for ; Wed, 09 Jan 2013 05:50:12 -0800 (PST) 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=8YOIAGhsmR2ImyfDvchq20ZEGXne6neK7SGtnRM0oGs=; b=jXI3Ic06nIAAbmBarTadYMtuLPeBipKA1LxYDbZteZjPu5NKQ9ZLH3v8JwIoZX7z8c A88TY9up7r3fJpzkeO1KmMxSQD+uZ+qRdgUFHlR5MooLObkloPYpcTapvq0f6b5jmOvG p2HHI9axxjK+eQyC6heqcf52VVoFvSXytPOAkAozIA3ChHZ9hSqXS4AVwImp9lINcilZ xFdWxbEwOWfFrNyl8TV9S6jcBFnczbNW+VP08dNYNvoShaZQXotbQlyAGfGrzLIPFSl6 KNs0As+6aLujjk4tKP3LjGYlTWpHCdia5HG1b9uFz2V4XZMuFgTmtDxkOlLwI/y6u7D/ dumQ== Received: by 10.49.118.162 with SMTP id kn2mr59135121qeb.65.1357739411948; Wed, 09 Jan 2013 05:50:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.78.72 with HTTP; Wed, 9 Jan 2013 05:49:51 -0800 (PST) In-Reply-To: References: <0A534525-59E1-418E-826B-177655767B17@gmail.com> From: "Andrew G. Malis" Date: Wed, 9 Jan 2013 08:49:51 -0500 Message-ID: To: Jon Steen Content-Type: multipart/alternative; boundary=047d7b6d98c658c5ae04d2db5797 Cc: Softwires@ietf.org, LISP mailing list list , draft-xu-softwire-ip-in-udp@tools.ietf.org Subject: Re: [Softwires] [lisp] draft-xu-softwire-ip-in-udp X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 13:50:14 -0000 --047d7b6d98c658c5ae04d2db5797 Content-Type: text/plain; charset=ISO-8859-1 Jon, My intent wasn't to show support for the draft, just to point out the relationship to the MPLS draft for those of you on the softwires list that may not have been following it. It's really up to the softwires WG to determine if it supports taking on this draft as a work item. Also, a comment to the draft-xu authors is that both of the draft-xu's should probably cross-reference each other (they don't currently). Cheers, Andy On Wed, Jan 9, 2013 at 12:20 AM, Jon Steen wrote: > Andy, > > I would have to agree with Damien in some sense, what other currently > available standards are available to fulfill this need without adding the > extra overhead. Overhead only adds to the proceessing time it takes to > relay the data. > > Jon Steen > > > > On Mon, Jan 7, 2013 at 11:09 AM, Andrew G. Malis wrote: > >> For the benefit of those of you that don't follow the MPLS WG list, this >> draft is closely related to >> http://tools.ietf.org/html/draft-xu-mpls-in-udp-06 , which is the >> subject of a lively discussion there. >> >> Cheers, >> Andy >> >> >> On Sun, Dec 30, 2012 at 3:45 PM, Damien Saucez wrote: >> >>> Hello, >>> >>> Interesting document, have you ever though of LISP to do that? >>> >>> Regards, >>> >>> Damien Saucez >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >>> >> >> >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >> >> > --047d7b6d98c658c5ae04d2db5797 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Jon,

My intent wasn't to show suppor= t for the draft, just to point out the relationship to the MPLS draft for t= hose of you on the softwires list that may not have been following it. It&#= 39;s really up to the softwires WG to determine if it supports taking on th= is draft as a work item.

Also, a comment to the draft-xu authors is that both of the draft-xu= 9;s should probably cross-reference each other (they don't currently).<= br>
Cheers,
Andy


On Wed, Jan 9, 2013 at 12:20 AM, Jon Steen <steenjj@gmail.com> wrote:
Andy,
=A0
I would have to agree with Damien in som= e sense, what other currently available standards are available to fulfill = this need without adding the extra overhead.=A0 Overhead only adds to the p= roceessing time it takes to relay the data.
=A0
Jon Steen


=A0
On Mon, Jan 7, 2013 at 11:09 AM, Andrew G. M= alis <agmalis@gmail.com> wrote:
F= or the benefit of those of you that don't follow the MPLS WG list, this= draft is closely related to http://tools.ietf.org/html/draft-xu-mpls= -in-udp-06 , which is the subject of a lively discussion there.

Cheers,
Andy


On Sun, Dec 30, 2012 at 3:45 PM, Damien Saucez <= span dir=3D"ltr"><damien.saucez@gmail.com> wrote:
Hello,

Interesting document, have you ever though of LISP to do that?

Regards,

Damien Saucez
_______________________________________________
Softwires mailing list
Softwires@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/softwires


_______________________________________________
lisp mailing list
lisp@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/lisp



--047d7b6d98c658c5ae04d2db5797-- From internet-drafts@ietf.org Thu Jan 10 17:24:00 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B31E21F8941; Thu, 10 Jan 2013 17:24:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iP357W2hOILd; Thu, 10 Jan 2013 17:23:59 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34C6521F8934; Thu, 10 Jan 2013 17:23:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130111012359.16802.46061.idtracker@ietfa.amsl.com> Date: Thu, 10 Jan 2013 17:23:59 -0800 Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-dslite-mib-01.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 01:24:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Softwires Working Group of the IETF. Title : DS-Lite Management Information Base (MIB) Author(s) : Yu Fu Sheng Jiang Jiang Dong Yuchi Chen Filename : draft-ietf-softwire-dslite-mib-01.txt Pages : 30 Date : 2013-01-10 Abstract: This memo defines a portion of the Management Information Base (MIB) for using with network management protocols in the Internet community. In particular, it defines managed objects for DS-Lite. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-dslite-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-softwire-dslite-mib-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-dslite-mib-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Sat Jan 12 07:43:34 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF48621F877B; Sat, 12 Jan 2013 07:43:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lvB+akm54wM6; Sat, 12 Jan 2013 07:43:30 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2345121F8881; Sat, 12 Jan 2013 07:43:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130112154330.4265.6627.idtracker@ietfa.amsl.com> Date: Sat, 12 Jan 2013 07:43:30 -0800 Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-mesh-multicast-04.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jan 2013 15:43:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Softwires Working Group of the IETF. Title : Softwire Mesh Multicast Author(s) : Mingwei Xu Yong Cui Jianping Wu Shu Yang Chris Metz Greg Shepherd Filename : draft-ietf-softwire-mesh-multicast-04.txt Pages : 26 Date : 2013-01-12 Abstract: The Internet needs to support IPv4 and IPv6 packets. Both address families and their attendant protocol suites support multicast of the single-source and any-source varieties. As part of the transition to IPv6, there will be scenarios where a backbone network running one IP address family internally (referred to as internal IP or I-IP) will provide transit services to attached client networks running another IP address family (referred to as external IP or E-IP). It is expected that the I-IP backbone will offer unicast and multicast transit services to the client E-IP networks. Softwire Mesh is a solution to E-IP unicast and multicast support across an I-IP backbone. This document describes the mechanisms for supporting Internet-style multicast across a set of E-IP and I-IP networks supporting softwire mesh. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-mesh-multicast There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-softwire-mesh-multicast-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-mesh-multicast-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From suresh.krishnan@ericsson.com Mon Jan 14 16:18:02 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40BC221F8994 for ; Mon, 14 Jan 2013 16:18:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.21 X-Spam-Level: X-Spam-Status: No, score=-103.21 tagged_above=-999 required=5 tests=[AWL=-2.773, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1lb7snoHJMJs for ; Mon, 14 Jan 2013 16:18:01 -0800 (PST) Received: from usevmg20.ericsson.net (unknown [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id B8F4821F88C4 for ; Mon, 14 Jan 2013 16:18:01 -0800 (PST) X-AuditID: c618062d-b7fcb6d000007ada-fb-50f4a038915f Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 19.90.31450.830A4F05; Tue, 15 Jan 2013 01:18:01 +0100 (CET) Received: from eusaamw0711.eamcs.ericsson.se (147.117.20.178) by EUSAAHC005.ericsson.se (147.117.188.87) with Microsoft SMTP Server (TLS) id 14.2.318.4; Mon, 14 Jan 2013 19:18:00 -0500 Received: from [142.133.112.63] (147.117.20.214) by smtps-am.internal.ericsson.com (147.117.20.178) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 14 Jan 2013 19:18:00 -0500 Message-ID: <50F49FA5.1000901@ericsson.com> Date: Mon, 14 Jan 2013 19:15:33 -0500 From: Suresh Krishnan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Softwires WG , X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNJMWRmVeSWpSXmKPExsUyuXRPuK7lgi8BBrM3c1ssODeVyeLwsq1M DkweS5b8ZPL4cvkzWwBTFJdNSmpOZllqkb5dAlfGmsXvWQua2SuOvl3E2sB4jLWLkZNDQsBE YsWOW8wQtpjEhXvr2boYuTiEBI4wSmx8fIcFwtnDKHH01y2ozDZGiT/zHoC18wpoS9zc8o0J xGYRUJXYMucJWJwNaOyGnZ/B4qICARKLl5xjh6gXlDg58wkLiC0iECGx8PousBphAWuJuc1z oE6SlFg0rROshllAT2LK1RZGCFteYvvbOWCnCgloSmxd8511AqPALCRjZyFpmYWkZQEj8ypG jtLi1LLcdCODTYzAADwmwaa7g3HPS8tDjNIcLErivEGuFwKEBNITS1KzU1MLUovii0pzUosP MTJxcEo1MPL1RDtvM2l2XTtbLmne+92JN7OfrjXuZqpx4twp2cGzZpdUY3XRzCIZDzenzc// nWNKZlmk+3mG+1wHteLNGh/XBShHiOoYTPqWtlRquSlfXKTTleXve/JOLJaPyV28enVg58e5 RWVNT1faPdkh9l74uf51NWVB3w/lC9h3BrHPY9Fa8c22QomlOCPRUIu5qDgRAOQmYfIOAgAA Subject: [Softwires] Chair review of draft-ietf-softwire-dslite-mib-01 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 00:18:02 -0000 Hi authors, I reviewed this document and I found that it is not ready for advancement. The MIB is not even properly formed to start off with and hence the MIB cannot be compiled and checked for validity. I found a few obvious fatal errors that need to be fixed. DEFINITIONS is spelled wrongly as DEFFINITIONS and this means that the MIB is not even recognized. After this is fixed, the MIB could be extracted but there was a syntax error. I found out was caused by a missing comma after "natAddrMapGlobalPortTo" in Page 6. Further errors There is a space between "::" and "=" in several of the definitions again causing an error each time. In summary, this MIB has a bunch of errors that need to be fixed before it can be advanced. Authors please submit a new version with the fixes after verifying its correctness using a MIB validator of your choice. Thanks Suresh From eleven.fuyu@huawei.com Mon Jan 14 17:46:12 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 266F611E80A6 for ; Mon, 14 Jan 2013 17:46:12 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kRiG65ZUq5Ei for ; Mon, 14 Jan 2013 17:46:11 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E98BC11E809B for ; Mon, 14 Jan 2013 17:46:09 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOT78780; Tue, 15 Jan 2013 01:46:08 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 15 Jan 2013 01:45:58 +0000 Received: from SZXEML451-HUB.china.huawei.com (10.82.67.194) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 15 Jan 2013 01:46:05 +0000 Received: from szxeml556-mbx.china.huawei.com ([169.254.3.46]) by szxeml451-hub.china.huawei.com ([10.82.67.194]) with mapi id 14.01.0323.003; Tue, 15 Jan 2013 09:45:59 +0800 From: "Fuyu (Eleven)" To: Suresh Krishnan Thread-Topic: [Softwires] Chair review of draft-ietf-softwire-dslite-mib-01 Thread-Index: AQHN8rXNCeX+J0MNO0WMGWT9hM5CRZhJlgDQ Date: Tue, 15 Jan 2013 01:45:58 +0000 Message-ID: References: <50F49FA5.1000901@ericsson.com> In-Reply-To: <50F49FA5.1000901@ericsson.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.137] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Softwires WG , "draft-ietf-softwire-dslite-mib@tools.ietf.org" Subject: Re: [Softwires] Chair review of draft-ietf-softwire-dslite-mib-01 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 01:46:12 -0000 Dear Suresh, Thank you for your valuable comments.=20 We will fix these errors and compile the mib for further checking befor= e updating a new version. Thanks=20 Yu -----Original Message----- From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Beh= alf Of Suresh Krishnan Sent: Tuesday, January 15, 2013 8:16 AM To: Softwires WG; draft-ietf-softwire-dslite-mib@tools.ietf.org Subject: [Softwires] Chair review of draft-ietf-softwire-dslite-mib-01 Hi authors, I reviewed this document and I found that it is not ready for advancement. The MIB is not even properly formed to start off with and hence the MIB cannot be compiled and checked for validity. I found a few obvious fatal errors that need to be fixed. DEFINITIONS is spelled wrongly as DEFFINITIONS and this means that the MIB is not even recognized. After this is fixed, the MIB could be extracted but there was a syntax error. I found out was caused by a missing comma after "natAddrMapGlobalPortTo" in Page 6. Further errors There is a space between "::" and "=3D" in several of the definitions again causing an error each time. In summary, this MIB has a bunch of errors that need to be fixed before it can be advanced. Authors please submit a new version with the fixes after verifying its correctness using a MIB validator of your choice. Thanks Suresh _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires From internet-drafts@ietf.org Mon Jan 14 21:38:40 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0803121F8844; Mon, 14 Jan 2013 21:38:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.514 X-Spam-Level: X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U6p8KQHxyski; Mon, 14 Jan 2013 21:38:37 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2CF521F883F; Mon, 14 Jan 2013 21:38:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130115053826.20381.63911.idtracker@ietfa.amsl.com> Date: Mon, 14 Jan 2013 21:38:26 -0800 Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-6rd-radius-attrib-10.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 05:38:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Softwires Working Group of the IETF. Title : RADIUS Attribute for 6rd Author(s) : Dayong Guo Sheng Jiang Remi Despres Roberta Maglione Filename : draft-ietf-softwire-6rd-radius-attrib-10.txt Pages : 12 Date : 2013-01-14 Abstract: IPv6 Rapid Deployment (6rd) provides both IPv4 and IPv6 connectivity services simultaneously during the IPv4/IPv6 co-existence period. The Dynamic Host Configuration Protocol (DHCP) 6rd option has been defined to configure the 6rd Customer Edge (CE). However, in many networks, the configuration information may be stored in Authentication Authorization and Accounting (AAA) servers while user configuration is mainly acquired from a Broadband Network Gateway (BNG) through the DHCP protocol. This document defines a Remote Authentication Dial In User Service (RADIUS) attribute that carries 6rd configuration information from the AAA server to BNGs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-6rd-radius-attrib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-softwire-6rd-radius-attrib-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-6rd-radius-attrib-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Thu Jan 17 11:03:02 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A6F321F8635; Thu, 17 Jan 2013 11:03:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.1 X-Spam-Level: X-Spam-Status: No, score=-102.1 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W8SFmxjsG8+Z; Thu, 17 Jan 2013 11:02:57 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3536A21F8587; Thu, 17 Jan 2013 11:02:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130117190256.4571.31182.idtracker@ietfa.amsl.com> Date: Thu, 17 Jan 2013 11:02:56 -0800 Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-dslite-deployment-08.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 19:03:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Softwires Working Group of the IETF. Title : Deployment Considerations for Dual-Stack Lite Author(s) : Yiu L. Lee Roberta Maglione Carl Williams Christian Jacquenet Mohamed Boucadair Filename : draft-ietf-softwire-dslite-deployment-08.txt Pages : 15 Date : 2013-01-17 Abstract: This document discusses the deployment issues and describes requirements for the deployment and operation of Dual-Stack Lite. This document describes the various deployment considerations and applicability of the Dual-Stack Lite architecture. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-dslite-deployment There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-softwire-dslite-deployment-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-dslite-deployment-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From yiu_lee@cable.comcast.com Thu Jan 17 11:09:07 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72DD421F886F for ; Thu, 17 Jan 2013 11:09:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.231 X-Spam-Level: X-Spam-Status: No, score=-105.231 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJnOkw8MIrIC for ; Thu, 17 Jan 2013 11:09:03 -0800 (PST) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 0A7A221F8873 for ; Thu, 17 Jan 2013 11:09:02 -0800 (PST) Received: from ([24.40.56.116]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.51544369; Thu, 17 Jan 2013 11:40:37 -0700 Received: from PACDCEXMB05.cable.comcast.com ([169.254.7.8]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%13]) with mapi id 14.02.0318.001; Thu, 17 Jan 2013 14:08:58 -0500 From: "Lee, Yiu" To: "softwires@ietf.org" Thread-Topic: [Softwires] I-D Action: draft-ietf-softwire-dslite-deployment-08.txt Thread-Index: AQHN9OYan1KhwqC/UU+1KcLacAAbpw== Date: Thu, 17 Jan 2013 19:08:58 +0000 Message-ID: In-Reply-To: <20130117190256.4571.31182.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [24.40.55.71] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3441276537_291688" MIME-Version: 1.0 Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-dslite-deployment-08.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 19:09:07 -0000 --B_3441276537_291688 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit This version addressed the comments addressed by Robert Sparks and Stephen Farrell. I do have a question for the WG. In 07 Section 2.4, we use "user" to indicate the user behind the B4 element. However, Stephen suggested this wasn't clear because we could have multiple users/devices behind a B4 elements. So we change this to household to address a B4 element is represented by a household. I would like to hear suggestions from the WG. Thanks, Yiu On 1/17/13 2:02 PM, "internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Softwires Working Group of the IETF. > > Title : Deployment Considerations for Dual-Stack Lite > Author(s) : Yiu L. Lee > Roberta Maglione > Carl Williams > Christian Jacquenet > Mohamed Boucadair > Filename : draft-ietf-softwire-dslite-deployment-08.txt > Pages : 15 > Date : 2013-01-17 > >Abstract: > This document discusses the deployment issues and describes > requirements for the deployment and operation of Dual-Stack Lite. > This document describes the various deployment considerations and > applicability of the Dual-Stack Lite architecture. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-softwire-dslite-deployment > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-softwire-dslite-deployment-08 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-dslite-deployment-08 > > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires --B_3441276537_291688 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVmQYJKoZIhvcNAQcCoIIVijCCFYYCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EzEwggU0MIIEHKADAgECAhEAzuhISIgzOwSitfbc2LN4WDANBgkqhkiG9w0BAQUFADCBkzEL MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGll bnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMjA4MjgwMDAwMDBa Fw0xMzA4MjgyMzU5NTlaMCoxKDAmBgkqhkiG9w0BCQEWGXlpdV9sZWVAY2FibGUuY29tY2Fz dC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCscOeu5/EoYRdja1jb6L4x o0TIevelc17NsPuRHfr2z3BGUMbfsJY1p0uXO9+inBQoBXwb07ac3SbOjA/6Ef3NlMPItWdT RGeFL6e/sMju9RgVyJURFnFgp7tc2tffnPOupnKZeeRehXeEFjun6+GC6teb1kSMu+WMMaCa D7/XSK+Q+F0Udc2Av0/gUCkGfTDpNnYwutfctEMRnle6EYUqmJMN4C0crEfovmYdMFFgJLKs Wa5Cdc+naFoIqzW8AcZB6+1XUDTzFbgjqgUbFFZFPzVZqNxLDFNy4tn8VlRSp2jBhgwQHtk1 ZA+spFENaeUuebp4tczj0IHG683FhhWjAgMBAAGjggHpMIIB5TAfBgNVHSMEGDAWgBR6E04A dFvGeGNkJ8Ev4qBbvHnFezAdBgNVHQ4EFgQUz03csl7CmjwQY+spX9VWeGb5sVQwDgYDVR0P AQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEB AwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkG CCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEyg SqBIhkZodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlv bmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0 dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2Vj dXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAk BgNVHREEHTAbgRl5aXVfbGVlQGNhYmxlLmNvbWNhc3QuY29tMA0GCSqGSIb3DQEBBQUAA4IB AQBG7LORtWcmzDlw0N/D5AwfsSLe93essAqKFhJ+nt7SmMVBsxGzFnSsZGQHMYQ4UXtiVq9A NjtPk00F3DC3QGxe4mxdwF9LzeYHpHMpCHTzNyilSimKZolLNBO+MO/U0u79rdF2W+dOAwkB dzroWBxK+yMhijJn2DCE/1pgxqBz+c9zbAtJYPVpgbeGNvvfIp6CA/JYsupQNqPX49a4MdJ3 L9yXLTiegSE8uPUlCB3sHZclQOXAttuMewpcKDoIC4wZgERKQqRH61PQO100GLKUO+VrTq+f xNkjOAqA+dih6QO5Djbv3qcMTCcAChJQYK8BS7jved8XgEVa0Ihz7oWKMIIFGjCCBAKgAwIB AgIQbRnqpxlPajMi5iIyeqpx3jANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJU UlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNV BAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0x MTA0MjgwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMS R3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8g Q0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoSEW0tX mNReL4uk4UDIo1NYX2Zl8TJO958yfVXQeExVt0KU4PkncQfFxmmkuTLE8UAakMwnVmJ/F7Vx aa7lIBvky2NeYMqiQfZq4aP/uN8fSG1lQ4wqLitjOHffsReswtqCAtbUMmrUZ28gE49cNfrl VICv2HEKHTcKAlBTbJUdqRAUtJmVWRIx/wmi0kzcUtve4kABW0ho3cVKtODtJB86r3FfB+Os vxQ7sCVxaD30D9YXWEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJkJpFOpZIP/+CxYP0ab2hR mWONGoulzEKbm30iY9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IBSzCCAUcwHwYDVR0j BBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4Y2QnwS/ioFu8 ecV7MA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYE VR0gADBYBgNVHR8EUTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVT RVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRo MGYwPQYIKwYBBQUHMAKGMWh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENs aWVudF9DQS5jcnQwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJ KoZIhvcNAQEFBQADggEBAIXWvnhXVW0zf0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtz bj7pJnzmTJjBMCjfy/tCPKElPgp11tA9OYZm0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqT ecr+4pEeVnSy+I3T4ENyG+2P/WA5IEf7i686ZUg8mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPN M1+b0L1garM7/vrUyTo8H+2b/5tJM75CKTmD7jNpLoKdRU2oadqAGx490hpdfEeZpZsIbRKZ htZdVwcbpzC+S0lEuJB+ytF5OOu0M/qgOl0mWJ5hVRi0IdWZ1eBDQEIwvuql55TSsP7zdfl/ bucwggSdMIIDhaADAgECAhA0PekrrCc0/4/LNJT7zHBUMA0GCSqGSIb3DQEBBQUAMG8xCzAJ BgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0 ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3Qw HhcNMDUwNjA3MDgwOTEwWhcNMjAwNTMwMTA0ODM4WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNV BAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMT LVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjM apjVTTUZuaRC5c5J4oovHnzSMQfHTrSDZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKT zMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1lepS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZG zaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGoLhu21DEgLLyCio6kDqXXiUP8FlqvHXHX EVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0YqoYymiTHqGFfvVHZcv4TVcodNI0 /zC27vZiMBSMLOsCAwEAAaOB9DCB8TAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73gJMtU GjAdBgNVHQ4EFgQUiYJnfcSdJnAAS7RQSHzePa4Ebn0wDgYDVR0PAQH/BAQDAgEGMA8GA1Ud EwEB/wQFMAMBAf8wEQYDVR0gBAowCDAGBgRVHSAAMEQGA1UdHwQ9MDswOaA3oDWGM2h0dHA6 Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFsQ0FSb290LmNybDA1BggrBgEF BQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZI hvcNAQEFBQADggEBAAG8nONjKLDzMQHC33vdYqABnSMxD5ySc1NR6h9M+tafxMovZ354Mw90 FrmRh5H1iib6ZHAA2B75CwRiUIeTgdTa9SPbNLuFVrRwNG54gzcehRzFERWSX4cXvaxq/fHC 0cyJX7F88D5R8jXzfOxgmGs6K+Dv37N9huu1G/Vb7KJ8mBPXAFC50S1z3gN4dOEFhTFey5q5 nZTGuZQ3dXLcRPtn6PD6JR5Sp9ol6UfgoMc8oE6xCjb7d0if75eK+7T+45QUqIO8XC0/0mBx YO7CcYIM6Yg249ogtKOgbKqWS7iAjnXKSQf2OxS639wF2Z/b4LLmTaB4JufnLW5/X8YeiBUw ggQ2MIIDHqADAgECAgEBMA0GCSqGSIb3DQEBBQUAMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQK EwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsx IjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMDAwNTMwMTA0ODM4WhcN MjAwNTMwMTA0ODM4WjBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAk BgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVz dCBFeHRlcm5hbCBDQSBSb290MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt/ca M+byAAQtOeBOW+0fvGwPzbX6I7bO3psRM5ekKUx9k5+9SryT7QMa44/P5W1QWtaXKZRagLBJ etsulf24yr83OC0ePpFBrXBWx/BPP+gynnTKyJBU6cZfD3idmkA8Dqxhql4Uj56HoWpQ3Nea Tq8Fs6ZxlJxxs1BgCscTnTgHhgKo6ahpJhiQq0ywTyOrOk+E2N/On+Fpb7vXQtdrROTHre5t QV9yWnEIN7N5ZaRZoJQ39wAvDcKSctrQOHLbFKhFxF0qfbe01sTurM0TRLfJK91DACX6Yblp algjEbenM49WdVn1zSnXRrcKK2W200JvFbK4e/vv6V1T1TRaJwIDAQABo4HcMIHZMB0GA1Ud DgQWBBStvZh6NLQm9/rEJlTvA73gJMtUGjALBgNVHQ8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB /zCBmQYDVR0jBIGRMIGOgBStvZh6NLQm9/rEJlTvA73gJMtUGqFzpHEwbzELMAkGA1UEBhMC U0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBU VFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdIIBATANBgkq hkiG9w0BAQUFAAOCAQEAsJvghSXC1iPiD5YGkp1BmJzZhHmB2R5bFAcjNmWPsNh3u6xBbEdg g1Gw+TI95/z2JhPHgBalv1r8h894eYkhmuJMBwqGNbzy3lHE0pa33H5O7nD9HDnrDAJRFC2O vRbgwd9Gdeckrez0QrSFk3AQZ7qdBjVKGNMresxRQqF6Y9Hmu6HFK8I2vhMN5r1jfnl7pwkN QKtq3Y+Kw/b2jBpCBVHURfWfp2IhaBUgQzyZ53y9JNipkRdziD9WGzE4GLRxD5rNyA6eji4b 4YyYg8sfMfFETMYEc0l2YA/H+L0XgGsu6cxMDlqaeQ8gCi7VnmMmHlWSlNiCF1p70LzHj06G BDGCAjAwggIsAgEBMIGpMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5 MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBAhEAzuhISIgzOwSitfbc2LN4WDAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFCho 4tlkGDGqZZU9PpZgRBuL1iqqMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTEzMDExNzE5MDg1NlowDQYJKoZIhvcNAQEBBQAEggEAqMJulinG+8+cj90Ojtas /gCHYJW3/YasUDMLvWgO3bEk79zSXbqRjR1nilm6ExQCRtdO1Ryl+1XSSK8nGkCMugK96ReB ClfHFhabBR0OhqDGRLCvFwCAUljo4gTsBGRDEflIzi7qtCZUiFkI1DWHyGRfTFgGJvG06osJ lcpf8jKq5SWb6pgeBcqbGOK3iB4x0CFBiH2+8w4RW7TqMte7VpkudUk5aiID0RPEFPlAQ0nL pogLndpGk69cfK5zkR6yeeDJUhodv50fTR1pO8I9c5RxBrvPP2hemKGaPk0gz0qfgr94Fyfu p8xzrtpxqd6I15+KCvutIOvbhVrmO0Gtaw== --B_3441276537_291688-- From xuxiaohu@huawei.com Thu Jan 17 17:42:19 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B093D21F8ACE; Thu, 17 Jan 2013 17:42:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.057 X-Spam-Level: X-Spam-Status: No, score=-2.057 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id coftekvXhFsM; Thu, 17 Jan 2013 17:42:19 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2606221F8AE3; Thu, 17 Jan 2013 17:42:17 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ANQ40408; Fri, 18 Jan 2013 01:42:16 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 18 Jan 2013 01:41:57 +0000 Received: from SZXEML448-HUB.china.huawei.com (10.82.67.191) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 18 Jan 2013 01:42:14 +0000 Received: from SZXEML525-MBX.china.huawei.com ([169.254.1.166]) by szxeml448-hub.china.huawei.com ([10.82.67.191]) with mapi id 14.01.0323.003; Fri, 18 Jan 2013 09:42:11 +0800 From: Xuxiaohu To: Damien Saucez , "draft-xu-softwire-ip-in-udp@tools.ietf.org" Thread-Topic: [Softwires] draft-xu-softwire-ip-in-udp Thread-Index: AQHN5s6ZupF9+lJbO0ixhTlA3bPV+ZhOaDVQ Date: Fri, 18 Jan 2013 01:42:10 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07597548@szxeml525-mbx.china.huawei.com> References: <0A534525-59E1-418E-826B-177655767B17@gmail.com> In-Reply-To: <0A534525-59E1-418E-826B-177655767B17@gmail.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.130] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "Softwires@ietf.org" , LISP mailing list list Subject: Re: [Softwires] draft-xu-softwire-ip-in-udp X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 01:42:19 -0000 SGkgRGFtaWVuLA0KDQpTb3JyeSBmb3IgbGF0ZSByZXNwb25zZSBkdWUgdG8gYSBsb25nIHZhY2F0 aW9uLiANCg0KWWVzLCBMSVNQIGRhdGEgZm9ybWF0IGNhbiBhbHNvIGJlIHVzZWQgZm9yIFNvZnR3 aXJlIE1lc2guIEhvd2V2ZXIsIG1hbnkgZmllbGRzIGNvbnRhaW5lZCBpbiB0aGUgTElTUCBoZWFk ZXIgYXJlIExJU1Agc3BlY2lmaWMgYW5kIHNlZW1zIHVubmVjZXNzYXJ5IGZvciBTb2Z0d2lyZSBN ZXNoIHNvIGZhciwgSU1ITy4NCg0KQmVzdCByZWdhcmRzLA0KWGlhb2h1DQoNCj4gLS0tLS3Tyrz+ 1K28/i0tLS0tDQo+ILeivP7Iyzogc29mdHdpcmVzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpz b2Z0d2lyZXMtYm91bmNlc0BpZXRmLm9yZ10gtPoNCj4gse0gRGFtaWVuIFNhdWNleg0KPiC3osvN yrG85DogMjAxMsTqMTLUwjMxyNUgNDo0NQ0KPiDK1bz+yMs6IGRyYWZ0LXh1LXNvZnR3aXJlLWlw LWluLXVkcEB0b29scy5pZXRmLm9yZw0KPiCzrcvNOiBTb2Z0d2lyZXNAaWV0Zi5vcmc7IExJU1Ag bWFpbGluZyBsaXN0IGxpc3QNCj4g1vfM4jogW1NvZnR3aXJlc10gZHJhZnQteHUtc29mdHdpcmUt aXAtaW4tdWRwDQo+IA0KPiBIZWxsbywNCj4gDQo+IEludGVyZXN0aW5nIGRvY3VtZW50LCBoYXZl IHlvdSBldmVyIHRob3VnaCBvZiBMSVNQIHRvIGRvIHRoYXQ/DQo+IA0KPiBSZWdhcmRzLA0KPiAN Cj4gRGFtaWVuIFNhdWNleg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiBTb2Z0d2lyZXMgbWFpbGluZyBsaXN0DQo+IFNvZnR3aXJlc0BpZXRmLm9y Zw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NvZnR3aXJlcw0K From xuxiaohu@huawei.com Thu Jan 17 17:56:19 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE78921F8AE7; Thu, 17 Jan 2013 17:56:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.226 X-Spam-Level: X-Spam-Status: No, score=-2.226 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NRSlZNBP6F-i; Thu, 17 Jan 2013 17:56:18 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B033621F8AA6; Thu, 17 Jan 2013 17:56:16 -0800 (PST) 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 AOW61814; Fri, 18 Jan 2013 01:56:15 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 18 Jan 2013 01:55:59 +0000 Received: from SZXEML463-HUB.china.huawei.com (10.82.67.206) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 18 Jan 2013 01:56:14 +0000 Received: from SZXEML525-MBX.china.huawei.com ([169.254.1.166]) by szxeml463-hub.china.huawei.com ([10.82.67.206]) with mapi id 14.01.0323.003; Fri, 18 Jan 2013 09:56:05 +0800 From: Xuxiaohu To: "Andrew G. Malis" , Jon Steen Thread-Topic: [Softwires] [lisp] draft-xu-softwire-ip-in-udp Thread-Index: AQHN7nBOIORRzIT3s0itIVsTqlOEnJhOYI5g Date: Fri, 18 Jan 2013 01:56:05 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07597560@szxeml525-mbx.china.huawei.com> References: <0A534525-59E1-418E-826B-177655767B17@gmail.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.111.98.130] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07597560szxeml525mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "Softwires@ietf.org" , LISP mailing list list , "draft-xu-softwire-ip-in-udp@tools.ietf.org" Subject: Re: [Softwires] [lisp] draft-xu-softwire-ip-in-udp X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 01:56:19 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07597560szxeml525mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 DQoNCreivP7Iyzogc29mdHdpcmVzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpzb2Z0d2lyZXMt Ym91bmNlc0BpZXRmLm9yZ10gtPqx7SBBbmRyZXcgRy4gTWFsaXMNCreiy83KsbzkOiAyMDEzxOox 1MI5yNUgMjE6NTANCsrVvP7IyzogSm9uIFN0ZWVuDQqzrcvNOiBTb2Z0d2lyZXNAaWV0Zi5vcmc7 IExJU1AgbWFpbGluZyBsaXN0IGxpc3Q7IGRyYWZ0LXh1LXNvZnR3aXJlLWlwLWluLXVkcEB0b29s cy5pZXRmLm9yZw0K1vfM4jogUmU6IFtTb2Z0d2lyZXNdIFtsaXNwXSBkcmFmdC14dS1zb2Z0d2ly ZS1pcC1pbi11ZHANCg0KSm9uLA0KTXkgaW50ZW50IHdhc24ndCB0byBzaG93IHN1cHBvcnQgZm9y IHRoZSBkcmFmdCwganVzdCB0byBwb2ludCBvdXQgdGhlIHJlbGF0aW9uc2hpcCB0byB0aGUgTVBM UyBkcmFmdCBmb3IgdGhvc2Ugb2YgeW91IG9uIHRoZSBzb2Z0d2lyZXMgbGlzdCB0aGF0IG1heSBu b3QgaGF2ZSBiZWVuIGZvbGxvd2luZyBpdC4gSXQncyByZWFsbHkgdXAgdG8gdGhlIHNvZnR3aXJl cyBXRyB0byBkZXRlcm1pbmUgaWYgaXQgc3VwcG9ydHMgdGFraW5nIG9uIHRoaXMgZHJhZnQgYXMg YSB3b3JrIGl0ZW0uDQoNCkFsc28sIGEgY29tbWVudCB0byB0aGUgZHJhZnQteHUgYXV0aG9ycyBp cyB0aGF0IGJvdGggb2YgdGhlIGRyYWZ0LXh1J3Mgc2hvdWxkIHByb2JhYmx5IGNyb3NzLXJlZmVy ZW5jZSBlYWNoIG90aGVyICh0aGV5IGRvbid0IGN1cnJlbnRseSkuDQoNCkhpIEFuZHksDQoNClRo YW5rcyBmb3IgdGhpcyBzdWdnZXN0aW9uIGFuZCBpdCB3aWxsIGJlIGZpeGVkIGluIHRoZSBmdXR1 cmUgdmVyc2lvbi4NCg0KQmVzdCByZWdhcmRzLA0KWGlhb2h1DQoNCg0KQ2hlZXJzLA0KQW5keQ0K DQpPbiBXZWQsIEphbiA5LCAyMDEzIGF0IDEyOjIwIEFNLCBKb24gU3RlZW4gPHN0ZWVuampAZ21h aWwuY29tPG1haWx0bzpzdGVlbmpqQGdtYWlsLmNvbT4+IHdyb3RlOg0KQW5keSwNCg0KSSB3b3Vs ZCBoYXZlIHRvIGFncmVlIHdpdGggRGFtaWVuIGluIHNvbWUgc2Vuc2UsIHdoYXQgb3RoZXIgY3Vy cmVudGx5IGF2YWlsYWJsZSBzdGFuZGFyZHMgYXJlIGF2YWlsYWJsZSB0byBmdWxmaWxsIHRoaXMg bmVlZCB3aXRob3V0IGFkZGluZyB0aGUgZXh0cmEgb3ZlcmhlYWQuICBPdmVyaGVhZCBvbmx5IGFk ZHMgdG8gdGhlIHByb2NlZXNzaW5nIHRpbWUgaXQgdGFrZXMgdG8gcmVsYXkgdGhlIGRhdGEuDQoN CkpvbiBTdGVlbg0KDQoNCg0KT24gTW9uLCBKYW4gNywgMjAxMyBhdCAxMTowOSBBTSwgQW5kcmV3 IEcuIE1hbGlzIDxhZ21hbGlzQGdtYWlsLmNvbTxtYWlsdG86YWdtYWxpc0BnbWFpbC5jb20+PiB3 cm90ZToNCkZvciB0aGUgYmVuZWZpdCBvZiB0aG9zZSBvZiB5b3UgdGhhdCBkb24ndCBmb2xsb3cg dGhlIE1QTFMgV0cgbGlzdCwgdGhpcyBkcmFmdCBpcyBjbG9zZWx5IHJlbGF0ZWQgdG8gaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQteHUtbXBscy1pbi11ZHAtMDYgLCB3aGljaCBpcyB0 aGUgc3ViamVjdCBvZiBhIGxpdmVseSBkaXNjdXNzaW9uIHRoZXJlLg0KQ2hlZXJzLA0KQW5keQ0K DQpPbiBTdW4sIERlYyAzMCwgMjAxMiBhdCAzOjQ1IFBNLCBEYW1pZW4gU2F1Y2V6IDxkYW1pZW4u c2F1Y2V6QGdtYWlsLmNvbTxtYWlsdG86ZGFtaWVuLnNhdWNlekBnbWFpbC5jb20+PiB3cm90ZToN CkhlbGxvLA0KDQpJbnRlcmVzdGluZyBkb2N1bWVudCwgaGF2ZSB5b3UgZXZlciB0aG91Z2ggb2Yg TElTUCB0byBkbyB0aGF0Pw0KDQpSZWdhcmRzLA0KDQpEYW1pZW4gU2F1Y2V6DQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KU29mdHdpcmVzIG1haWxpbmcg bGlzdA0KU29mdHdpcmVzQGlldGYub3JnPG1haWx0bzpTb2Z0d2lyZXNAaWV0Zi5vcmc+DQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NvZnR3aXJlcw0KDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpsaXNwIG1haWxpbmcgbGlz dA0KbGlzcEBpZXRmLm9yZzxtYWlsdG86bGlzcEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbGlzcA0KDQoNCg== --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07597560szxeml525mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

 = ;

 = ;

=B7=A2=BC=FE=C8=CB: softwires-bounces@iet= f.org [mailto:softwires-bounces@ietf.org] =B4=FA=B1=ED = Andrew G. Malis
=B7=A2=CB=CD= =CA=B1=BC=E4: 2013=C4=EA1=D4=C2<= span lang=3D"EN-US">9=C8=D5 21:50
=CA=D5=BC=FE=C8=CB: Jon Steen
=B3=AD=CB=CD: Softwires@ietf.org; LISP mailing list list; draft-xu-softwire-ip-in-udp@t= ools.ietf.org
=D6=F7=CC=E2: Re: [Softwires] [lisp] draft-xu-softwire-ip-in-udp

 

= Jon,

My intent wasn't to show suppor= t for the draft, just to point out the relationship to the MPLS draft for t= hose of you on the softwires list that may not have been following it. It's= really up to the softwires WG to determine if it supports taking on this draft as a work item.

Also, a comment to the draft-xu authors is that both of the draft-xu's shou= ld probably cross-reference each other (they don't currently).

Hi Andy,

 = ;

Thanks for= this suggestion and it will be fixed in the future version.

 = ;

Best regar= ds,

Xiaohu

 = ;


Cheers,
Andy

=  

On Wed, Jan 9, 2013 at 12:20 AM= , Jon Steen <stee= njj@gmail.com> wrote:

Andy,

 

I would have to agree with Dami= en in some sense, what other currently available standards are available to= fulfill this need without adding the extra overhead.  Overhead only a= dds to the proceessing time it takes to relay the data.

 

Jon Steen



 

On Mon, Jan 7, 2013 at 11:09 AM= , Andrew G. Malis <agmalis@gmail.com> wrote:

= For the benefit of those of you that don't follow the MPLS WG list, this dr= aft is closely related to http://tools.ietf.org/html/draft-xu-mpls-in-udp-06 , which is the= subject of a lively discussion there.

Cheers,
Andy

=  

On Sun, Dec 30, 2012 at 3:45 PM= , Damien Saucez <damien.saucez@gmail.com> wrote:

Hello,

Interesting document, have you ever though of LISP to do that?

Regards,

Damien Saucez
_______________________________________________

Softwires mailing list
Softwires@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/softwires

 

 

= _______________________________________________
lisp mailing list
lisp@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/lisp

 

 

--_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07597560szxeml525mbxchi_-- From rajiva@cisco.com Sun Jan 20 11:47:01 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD3E921F8795 for ; Sun, 20 Jan 2013 11:47:01 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WqCBX2nbPeiV for ; Sun, 20 Jan 2013 11:47:01 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0EF6221F8780 for ; Sun, 20 Jan 2013 11:47:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=671; q=dns/txt; s=iport; t=1358711221; x=1359920821; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=XSesMJLOrLn9r1ksLKkekIm3MuyO6GHJBKU/fiy8198=; b=aoBg/AMoA1m9u6WOSElZ9/3+ahn5jq25Ab4WeEq6Oe/u6RaU2qwl9FwE FA2DS/NuEagC8rWmTN1H5gBxXHksyiSVC7DKVtxO+2FGD9IakZbMF/P/R K4LqSxUCCkrx8D84AOL5i43N67+IPENyU7hmZjHAcpxK0TKga6iYqp7sa M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAEdI/FCtJXG+/2dsb2JhbABEvjYWc4IgAQQ6UQEqFEInBBuIEZtJn0WQWGEDplWCdYIk X-IronPort-AV: E=Sophos;i="4.84,501,1355097600"; d="scan'208";a="165223919" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 20 Jan 2013 19:47:00 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r0KJl0ob008155 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 20 Jan 2013 19:47:00 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.193]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Sun, 20 Jan 2013 13:47:00 -0600 From: "Rajiv Asati (rajiva)" To: Softwires-wg list Thread-Topic: draft-ietf-softwire-map-t Thread-Index: AQHN90bpN8kb2zryjEWzBxoce/dxYA== Date: Sun, 20 Jan 2013 19:46:59 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.65.74.139] Content-Type: text/plain; charset="us-ascii" Content-ID: <2C4FE4F4F159BD45B59980BE413AA946@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Softwires] draft-ietf-softwire-map-t X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jan 2013 19:47:01 -0000 I just noticed an opportunity for the technical fix-up in section 5.1. The current text suggests reserving the first IPv6 prefix in an End-user IPv6 prefix for MAP. Well, we should't be reserving the entire prefix. We just need an address. Please consider updating the text. OLD: zero) of length s required to make n+o+s=3D64. A MAP CE node MUST reserve the first IPv6 prefix in a End-user IPv6 prefix for the purpose of MAP. NEW: zero) of length s required to make n+o+s=3D64. A MAP CE node MUST reserve an IPv6 address of first IPv6 prefix (of length /64) from an End-user IPv6 prefix for the purpose of MAP. =20 Cheers, Rajiv From tom.taylor.stds@gmail.com Mon Jan 21 07:42:46 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A148D21F873B for ; Mon, 21 Jan 2013 07:42:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1B7a9e9x2aud for ; Mon, 21 Jan 2013 07:42:46 -0800 (PST) Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com [209.85.223.177]) by ietfa.amsl.com (Postfix) with ESMTP id 1551921F8735 for ; Mon, 21 Jan 2013 07:42:46 -0800 (PST) Received: by mail-ie0-f177.google.com with SMTP id k13so10006691iea.22 for ; Mon, 21 Jan 2013 07:42:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding:x-antivirus :x-antivirus-status; bh=lB3YmzTUR0d2Z2Kdh8zTt1rxc4gzI2RnAJ7tUVMfYMc=; b=vO8usMOBVRVQvKfZxKetMAuGkH8zXxx5lHPUlj3gvm451OHbWjpeier8yE3pYYA/RH hXErW6SjAjZ9GckD/qsCb8bJjEOcuElw5NvYjfBfSYa4zGECwojyuT56NmUrKNTKWLUY 4xto2rqV8OVEycdECgscv/6zaUF5t5HnLoUWv1mJxynTZnWAHmp6FVG63PJu3StXivbE ZVgc746TXoPQGE75lrWzSlKtLzpJ7uOItyw9uZ43nP3tKwpkCiDtDIrkAdgHUJQAI3JS 6IgYsslaJEr0lLyiGGtHX1HJYom3pLUQMPIwl4PNhU6NoEkCRpFgsd4j05/Oc6LfVsH9 PiQA== X-Received: by 10.50.187.197 with SMTP id fu5mr9026371igc.95.1358782965789; Mon, 21 Jan 2013 07:42:45 -0800 (PST) Received: from [127.0.0.1] (dsl-173-206-87-33.tor.primus.ca. [173.206.87.33]) by mx.google.com with ESMTPS id mj6sm8619885igc.9.2013.01.21.07.42.44 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 21 Jan 2013 07:42:45 -0800 (PST) Message-ID: <50FD61F5.7060608@gmail.com> Date: Mon, 21 Jan 2013 10:42:45 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Softwires Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130121-0, 21/01/2013), Outbound message X-Antivirus-Status: Clean Subject: [Softwires] Provisioning of "excluded ports" in draft-ietf-softwire-map-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 15:42:46 -0000 Section 5.1.3 calls for the (optional) provisioning of a range of excluded ports as part of a mapping rule. As my notes in Decemeber hopefully made clear, the key issue is really whether system ports (0-1023) are to be excluded or not. How many actually get excluded is a function of block size, or of the sharing ratio if a = 0. The default value of 4096 currently given in Section 5.1.3 is the block size implied by an offset a = 4. I would think an operator would not want to exclude any more ports than necessary. Hence what needs to be provisioned is simply a Boolean indication that system ports are to be excluded or not. If they are to be excluded, then: - for a = 0, as many PSIDs as necessary beginning with PSID = 0 MUST NOT be used because the corresponding port ranges lie within the range 0-1023. - for 1 <= a <= 6, the first block MUST NOT be used, because it contains the system port range. The corresponding number of excluded ports (including the system ports) ranges from 32768 for a = 1, down to exactly 1024 for a = 6. - a > 6, more than one block has to be excluded to make up the complete range of 1024 ports. The above bullets could be part of the explanation of the algorithm in Section 5.1. Section 5.1.3 should change only by replacing "excluded ports" by "whether system ports are excluded" and the default value of that to "yes". Tom Taylor From otroan@employees.org Mon Jan 21 07:55:23 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EAB721F845E for ; Mon, 21 Jan 2013 07:55:23 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MO0xBVS4QH9q for ; Mon, 21 Jan 2013 07:55:22 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 81F7E21F845F for ; Mon, 21 Jan 2013 07:55:22 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAElk/VCQ/khR/2dsb2JhbABEvi0Wc4IeAQEEATo/BQsLRlcGiCYGuxGQWGEDplWCdg X-IronPort-AV: E=Sophos;i="4.84,507,1355097600"; d="scan'208";a="79888871" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 21 Jan 2013 15:55:19 +0000 Received: from dhcp-lys01-vla250-10-147-112-93.cisco.com (dhcp-lys01-vla250-10-147-112-93.cisco.com [10.147.112.93]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r0LFtIkN005142 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 21 Jan 2013 15:55:19 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ole Troan In-Reply-To: <50FD61F5.7060608@gmail.com> Date: Mon, 21 Jan 2013 16:55:18 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7E5D67C7-3C35-43C4-A203-4770E94D05E4@employees.org> References: <50FD61F5.7060608@gmail.com> To: Tom Taylor X-Mailer: Apple Mail (2.1499) Cc: Softwires Subject: Re: [Softwires] Provisioning of "excluded ports" in draft-ietf-softwire-map-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 15:55:23 -0000 Tom, > Section 5.1.3 calls for the (optional) provisioning of a range of = excluded ports as part of a mapping rule. As my notes in Decemeber = hopefully made clear, the key issue is really whether system ports = (0-1023) are to be excluded or not. How many actually get excluded is a = function of block size, or of the sharing ratio if a =3D 0. The default = value of 4096 currently given in Section 5.1.3 is the block size implied = by an offset a =3D 4. >=20 > I would think an operator would not want to exclude any more ports = than necessary. Hence what needs to be provisioned is simply a Boolean = indication that system ports are to be excluded or not. If they are to = be excluded, then: >=20 > - for a =3D 0, as many PSIDs as necessary beginning with PSID =3D 0 = MUST NOT be used because the corresponding port ranges lie within the = range 0-1023. >=20 > - for 1 <=3D a <=3D 6, the first block MUST NOT be used, because it = contains the system port range. The corresponding number of excluded = ports (including the system ports) ranges from 32768 for a =3D 1, down = to exactly 1024 for a =3D 6. >=20 > - a > 6, more than one block has to be excluded to make up the = complete range of 1024 ports. >=20 > The above bullets could be part of the explanation of the algorithm in = Section 5.1. Section 5.1.3 should change only by replacing "excluded = ports" by "whether system ports are excluded" and the default value of = that to "yes". wouldn't it then be simpler to require that a MUST be either 0 or 6? (or = only 6). the discussion we've had earlier was that the benefit of being able to = easily recognise the PSID in a port, made up for the lost 3K ports. which is what lead to an a=3D4. cheers, Ole= From tom.taylor.stds@gmail.com Mon Jan 21 11:42:59 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3976121F8536 for ; Mon, 21 Jan 2013 11:42:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f-HGgnczLItw for ; Mon, 21 Jan 2013 11:42:58 -0800 (PST) Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) by ietfa.amsl.com (Postfix) with ESMTP id 5FAAD21F8526 for ; Mon, 21 Jan 2013 11:42:58 -0800 (PST) Received: by mail-ie0-f174.google.com with SMTP id k11so4588960iea.19 for ; Mon, 21 Jan 2013 11:42:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-antivirus:x-antivirus-status; bh=x7Uh/oUXdlufgDw5jejQtlS94n1ka7Zhl45H2wh2qZg=; b=kFAqvds9sj0qrhYT2N2Omrqf6CwBgSn05FKSUXCkcyY27NOJMNLqt4WwNmvxPthB+D yKI+MryLTHH0vgVxjvmFZu/8oD6WVuvCuWQ5MtbGBkzAKGFpWqFmXAUq/WpA12DXGx4o Gl9+BpJNITpjx4rWzetclqzndEGeKs+mQE2SEvXtcl4AwrUQRhil3f1KjxnAba/P60bt uYIZ1BAapY9P0JFxUb+loI0AcvzFISCCQQ6dx2IFb9Mt03LNt6t5nIEMgP2cic34JXqh carfxTAvzOIAk7AL62AU+JY8nLGrVn5kl4gxZW8bK42HdtE48NGerZYvoXfhugL4JE0t aWOQ== X-Received: by 10.50.213.6 with SMTP id no6mr9813560igc.67.1358797375024; Mon, 21 Jan 2013 11:42:55 -0800 (PST) Received: from [127.0.0.1] (dsl-173-206-87-33.tor.primus.ca. [173.206.87.33]) by mx.google.com with ESMTPS id df6sm8585341igb.15.2013.01.21.11.42.53 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 21 Jan 2013 11:42:54 -0800 (PST) Message-ID: <50FD9A3D.7020201@gmail.com> Date: Mon, 21 Jan 2013 14:42:53 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Ole Troan References: <50FD61F5.7060608@gmail.com> <7E5D67C7-3C35-43C4-A203-4770E94D05E4@employees.org> In-Reply-To: <7E5D67C7-3C35-43C4-A203-4770E94D05E4@employees.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130121-0, 21/01/2013), Outbound message X-Antivirus-Status: Clean Cc: Softwires Subject: Re: [Softwires] Provisioning of "excluded ports" in draft-ietf-softwire-map-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 19:42:59 -0000 Below. On 21/01/2013 10:55 AM, Ole Troan wrote: > Tom, > >> Section 5.1.3 calls for the (optional) provisioning of a range of >> excluded ports as part of a mapping rule. As my notes in Decemeber >> hopefully made clear, the key issue is really whether system ports >> (0-1023) are to be excluded or not. How many actually get excluded >> is a function of block size, or of the sharing ratio if a = 0. The >> default value of 4096 currently given in Section 5.1.3 is the block >> size implied by an offset a = 4. >> >> I would think an operator would not want to exclude any more ports >> than necessary. Hence what needs to be provisioned is simply a >> Boolean indication that system ports are to be excluded or not. If >> they are to be excluded, then: >> >> - for a = 0, as many PSIDs as necessary beginning with PSID = 0 >> MUST NOT be used because the corresponding port ranges lie within >> the range 0-1023. >> >> - for 1 <= a <= 6, the first block MUST NOT be used, because it >> contains the system port range. The corresponding number of >> excluded ports (including the system ports) ranges from 32768 for a >> = 1, down to exactly 1024 for a = 6. >> >> - a > 6, more than one block has to be excluded to make up the >> complete range of 1024 ports. >> >> The above bullets could be part of the explanation of the algorithm >> in Section 5.1. Section 5.1.3 should change only by replacing >> "excluded ports" by "whether system ports are excluded" and the >> default value of that to "yes". > > wouldn't it then be simpler to require that a MUST be either 0 or 6? > (or only 6). the discussion we've had earlier was that the benefit of > being able to easily recognise the PSID in a port, made up for the > lost 3K ports. which is what lead to an a=4. > > cheers, Ole > The trouble is, the value of a is related to the number of blocks by the formula Number of blocks = 2^a The number of blocks determines how many port ranges are allocated to each MAP CE (i.e. with system ports and hence the first block excluded, a = 4 implies that each sharing MAP CE is allocated 15 separate ranges of ports). I think you want to retain the operator's flexibility to allocate fewer blocks or, in the interest of reducing the chance that an attacker can guess the next port allocated, more blocks. Of course, the operators in the WG may disagree. Tom From internet-drafts@ietf.org Thu Jan 24 01:32:03 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1409221F8801; Thu, 24 Jan 2013 01:32:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.454 X-Spam-Level: X-Spam-Status: No, score=-102.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qHSjN21vo7UN; Thu, 24 Jan 2013 01:32:02 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99AD121F883C; Thu, 24 Jan 2013 01:32:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130124093202.19808.80495.idtracker@ietfa.amsl.com> Date: Thu, 24 Jan 2013 01:32:02 -0800 Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-6rd-radius-attrib-11.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 09:32:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Softwires Working Group of the IETF. Title : RADIUS Attribute for 6rd Author(s) : Dayong Guo Sheng Jiang Remi Despres Roberta Maglione Filename : draft-ietf-softwire-6rd-radius-attrib-11.txt Pages : 12 Date : 2013-01-24 Abstract: IPv6 Rapid Deployment (6rd) provides both IPv4 and IPv6 connectivity services simultaneously during the IPv4/IPv6 co-existence period. The Dynamic Host Configuration Protocol (DHCP) 6rd option has been defined to configure the 6rd Customer Edge (CE). However, in many networks, the configuration information may be stored in Authentication Authorization and Accounting (AAA) servers while user configuration is mainly acquired from a Broadband Network Gateway (BNG) through the DHCP protocol. This document defines a Remote Authentication Dial In User Service (RADIUS) attribute that carries 6rd configuration information from the AAA server to BNGs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-6rd-radius-attrib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-softwire-6rd-radius-attrib-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-6rd-radius-attrib-11 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From otroan@employees.org Thu Jan 24 02:37:26 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A16321F8588 for ; Thu, 24 Jan 2013 02:37:26 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b8jLYcOmAVrn for ; Thu, 24 Jan 2013 02:37:25 -0800 (PST) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 890A921F8573 for ; Thu, 24 Jan 2013 02:37:25 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAFQOAVGQ/khN/2dsb2JhbABEvkoWc4IeAQEEAXkFCwtGVwaIJwa9ZpASYQOmVYJ2 X-IronPort-AV: E=Sophos;i="4.84,528,1355097600"; d="scan'208";a="11298658" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-3.cisco.com with ESMTP; 24 Jan 2013 10:37:22 +0000 Received: from dhcp-lys01-vla250-10-147-112-130.cisco.com (dhcp-lys01-vla250-10-147-112-130.cisco.com [10.147.112.130]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r0OAbML3002130 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 24 Jan 2013 10:37:22 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ole Troan In-Reply-To: <50FD9A3D.7020201@gmail.com> Date: Thu, 24 Jan 2013 11:37:22 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50FD61F5.7060608@gmail.com> <7E5D67C7-3C35-43C4-A203-4770E94D05E4@employees.org> <50FD9A3D.7020201@gmail.com> To: Tom Taylor X-Mailer: Apple Mail (2.1499) Cc: Softwires Subject: Re: [Softwires] Provisioning of "excluded ports" in draft-ietf-softwire-map-02 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 10:37:26 -0000 Tom, [...] > The trouble is, the value of a is related to the number of blocks by = the formula >=20 > Number of blocks =3D 2^a >=20 > The number of blocks determines how many port ranges are allocated to = each MAP CE (i.e. with system ports and hence the first block excluded, = a =3D 4 implies that each sharing MAP CE is allocated 15 separate ranges = of ports). I think you want to retain the operator's flexibility to = allocate fewer blocks or, in the interest of reducing the chance that an = attacker can guess the next port allocated, more blocks. Of course, the = operators in the WG may disagree. for the sake of simplicity I'd rather we made the offset fixed to 4, and = that if one wants fine grained control of port ranges use something like = PCP or DHCP. that said, you are suggesting a rule, that would say something like: if = a > 6, then the 6 most significant bits of A MUST not me zero. e.g. with offset =3D 8, PSID length 4 xxxx xxXX PSID yyyy then only the 'x' field > 0. thereby only excluding 1024 ports, with = large offset. cheers, Ole= From otroan@employees.org Thu Jan 24 03:01:14 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED6F521F856C for ; Thu, 24 Jan 2013 03:01:13 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7BQe6mGkBMvQ for ; Thu, 24 Jan 2013 03:01:13 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 45D4221F8552 for ; Thu, 24 Jan 2013 03:01:12 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAFITAVGQ/khR/2dsb2JhbABEvkcWc4JfgX0uh38MnCOhPI0dgn1hA5cojyyCeQ X-IronPort-AV: E=Sophos;i="4.84,528,1355097600"; d="scan'208";a="149718957" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 24 Jan 2013 11:01:11 +0000 Received: from dhcp-lys01-vla250-10-147-112-130.cisco.com (dhcp-lys01-vla250-10-147-112-130.cisco.com [10.147.112.130]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r0OB1Ald012293 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 24 Jan 2013 11:01:11 GMT From: Ole Troan Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <6D18C8BC-4E1A-4E93-9DD4-1C52DCFB64C7@employees.org> Date: Thu, 24 Jan 2013 12:01:09 +0100 To: Softwires WG Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [Softwires] MAP-E - Ticket #21: Fragmentation must not be handled according to RFC 2473 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 11:01:14 -0000 hi, Ticket #21 states = (http://trac.tools.ietf.org/wg/softwire/trac/ticket/21) ---- The current MAP-E specifications says (sec. 10.1): "Multiple BRs using the same anycast source address could send = fragmented packets to the same CE at the same time. If the fragmented = packets from different BRs happen to use the same fragment ID, = incorrect reassembly might occur." Reason for this is that RFC 2473 says, in sec. 7.2: "When an IPv4 original packet enters a tunnel, if the original packet = size exceeds the tunnel MTU ...if in the original packet header the = Don't Fragment - DF - bit flag is CLEAR, the tunnel entry-point node = encapsulates the original packet, and subsequently fragments the = resulting IPv6 tunnel packet into IPv6 fragments that do not exceed the = Path MTU to the tunnel exit-point." Incorrect reassembly is unacceptable but support of duplicated BRs is = really needed, for scalability and relaiability. Fortunately, the solution used in 4rd can be used in MAP-E too (R-13 of = sec. 4.5.1): when a fragmentable IPv4 packet is too large for = encapsulation in a single IPv6 packet, it MUST be fragmented in IPv4 = BEFORE submission to encapsulation. This being done, RFC-2473 = fragmentation never occurs. Multiple BRs can use the same anycast source = address without risk of incorrect reassembly.=20 ---- I see a few possible resolutions to this ticket. 0) declare changes to how RFC2473 specifies fragmentation to be done for = IPv4 over IPv6 tunnels out of scope 1) reference 4459 and suggest section 3.4 as a potential workaround, = without being normative. 2) adopt R-13 from http://tools.ietf.org/html/draft-ietf-softwire-4rd-04 3) split the IPv6 fragmentation-id space between BRs any views on this? Best regards, Ole= From internet-drafts@ietf.org Thu Jan 24 03:15:32 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E73321F8991; Thu, 24 Jan 2013 03:15:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.453 X-Spam-Level: X-Spam-Status: No, score=-102.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23ZwOtCOPCKu; Thu, 24 Jan 2013 03:15:31 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAB4321F8988; Thu, 24 Jan 2013 03:15:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130124111531.12533.96909.idtracker@ietfa.amsl.com> Date: Thu, 24 Jan 2013 03:15:31 -0800 Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-map-03.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 11:15:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Softwires Working Group of the IETF. Title : Mapping of Address and Port with Encapsulation (MAP) Author(s) : Ole Troan Wojciech Dec Xing Li Congxiao Bao Satoru Matsushima Tetsuya Murakami Filename : draft-ietf-softwire-map-03.txt Pages : 29 Date : 2013-01-24 Abstract: This document describes a mechanism for transporting IPv4 packets across an IPv6 network using IP encapsulation, and a generic mechanism for mapping between IPv6 addresses and IPv4 addresses and transport layer ports. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-map There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-softwire-map-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-map-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From otroan@employees.org Thu Jan 24 03:23:08 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A1AF21F86CC for ; Thu, 24 Jan 2013 03:23:07 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8nobtByAiZWS for ; Thu, 24 Jan 2013 03:23:06 -0800 (PST) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id BD18321F86F0 for ; Thu, 24 Jan 2013 03:23:03 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALQYAVGQ/khM/2dsb2JhbABEg3W6UhZzgh4BAQEDAQEBATc0GwtGJzAZCYgLBgcFvWqNUoJIYQOXKI8sgnk X-IronPort-AV: E=Sophos;i="4.84,529,1355097600"; d="scan'208";a="11299679" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-3.cisco.com with ESMTP; 24 Jan 2013 11:23:02 +0000 Received: from dhcp-lys01-vla250-10-147-112-130.cisco.com (dhcp-lys01-vla250-10-147-112-130.cisco.com [10.147.112.130]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r0OBN2mQ016304 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 24 Jan 2013 11:23:02 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ole Troan In-Reply-To: <20130124111531.12533.96909.idtracker@ietfa.amsl.com> Date: Thu, 24 Jan 2013 12:23:02 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2AB6BF8B-8226-4A3B-997C-BD6E0DD7A948@employees.org> References: <20130124111531.12533.96909.idtracker@ietfa.amsl.com> To: softwires@ietf.org X-Mailer: Apple Mail (2.1499) Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-map-03.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 11:23:08 -0000 finally an update to the MAP draft. I believe all the issues apart from #21 is resolved. the main changes are: - a complete rewrite of the port mapping section (going back to the = simpler description from the 4rd draft). - moving examples to a separate appendix - removing the DMR, and replacing with a simple BR address. please review and suggest text for changes. I expect one more revision, and then I hope we can take this to WGLC. Best regards, Ole On Jan 24, 2013, at 12:15 , 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 Softwires Working Group of the IETF. >=20 > Title : Mapping of Address and Port with Encapsulation = (MAP) > Author(s) : Ole Troan > Wojciech Dec > Xing Li > Congxiao Bao > Satoru Matsushima > Tetsuya Murakami > Filename : draft-ietf-softwire-map-03.txt > Pages : 29 > Date : 2013-01-24 >=20 > Abstract: > This document describes a mechanism for transporting IPv4 packets > across an IPv6 network using IP encapsulation, and a generic > mechanism for mapping between IPv6 addresses and IPv4 addresses and > transport layer ports. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-softwire-map >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-softwire-map-03 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-map-03 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From otroan@employees.org Thu Jan 24 08:27:24 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6D8521F8984 for ; Thu, 24 Jan 2013 08:27:24 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h5k9KWV0gjH3 for ; Thu, 24 Jan 2013 08:27:24 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id F3F6B21F895F for ; Thu, 24 Jan 2013 08:27:21 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFAOBfAVGQ/khM/2dsb2JhbABEukiEABZzgh8BBTo/EAtGVwYTiAgDBgkMtDIMiVaNHYJ9YQOXKIodhQ+CeQ X-IronPort-AV: E=Sophos;i="4.84,530,1355097600"; d="scan'208";a="149732100" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 24 Jan 2013 16:27:20 +0000 Received: from dhcp-10-61-104-192.cisco.com (dhcp-10-61-104-192.cisco.com [10.61.104.192]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r0OGRIIZ003166 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 24 Jan 2013 16:27:20 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ole Troan In-Reply-To: <078.5016b38f0fa45b1e08acdf73cc564147@tools.ietf.org> Date: Thu, 24 Jan 2013 17:27:18 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <063.9dc31682f59256171b5d58fdb1cdcc5e@tools.ietf.org> <078.5016b38f0fa45b1e08acdf73cc564147@tools.ietf.org> To: "softwires@ietf.org WG" X-Mailer: Apple Mail (2.1499) Cc: remi.despres@free.fr Subject: Re: [Softwires] [softwire] #19: IPv4 address superfluous in MAP-E Interface IDs X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 16:27:24 -0000 hi, can we please keep discussion on the list. not via the issue tracker? does anyone else have an opinion? (if I don't hear anything from anyone else, I'll default to keep current = text.) cheers, Ole On Jan 24, 2013, at 17:23 , softwire issue tracker = wrote: > #19: IPv4 address superfluous in MAP-E Interface IDs >=20 > Changes (by remi.despres@free.fr): >=20 > * priority: trivial =3D> major > * status: closed =3D> reopened > * resolution: wontfix =3D> >=20 >=20 > Comment: >=20 > Value of having the PSID in MAP-E IIDs for maintenance isn't clear at = all: > - PSID length isn't determined in IIDs (there can be an unknown number = of > trailing zeroes) > - all PSID bits are already readable in the first 64 bits >=20 > Suggestion to close the issue: > - keep IPv4 addresses in IIDs (they contains some bits that aren't in = the > first 64 bits) > - don't keep the PSID in IIDs (insufficiently justified complexity) >=20 > --=20 > = -------------------------+------------------------------------------------= - > Reporter: | Owner: draft-ietf-softwire- > remi.despres@free.fr | map@tools.ietf.org > Type: defect | Status: reopened > Priority: major | Milestone: > Component: map-e | Version: > Severity: Candidate | Resolution: > WG Document | > Keywords: | > = -------------------------+------------------------------------------------= - >=20 > Ticket URL: = > softwire >=20 From tomosann@gmail.com Thu Jan 24 08:54:36 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7083321F89BA for ; Thu, 24 Jan 2013 08:54:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7zPbpuC1FcA for ; Thu, 24 Jan 2013 08:54:35 -0800 (PST) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by ietfa.amsl.com (Postfix) with ESMTP id EB08D21F867B for ; Thu, 24 Jan 2013 08:54:34 -0800 (PST) Received: by mail-oa0-f54.google.com with SMTP id n9so10118374oag.27 for ; Thu, 24 Jan 2013 08:54:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=V8yqg2HktbNJO4qv8SN+w2yr8XmRO3eI85vWw178Bbg=; b=ZUM3GszJkrRRsxGH0PSX0kQlNywXWeAtTKJllMhyM1VXfwBVX/uCDe0idYjCHF1iGV RCWVtPAtvLRVGh5uvrxVzmqz5lTYmxsuHMaqrBg8vOpyweRUEt8IEihOQH0acoMUWxP8 k1WXCazSUSfotb7st0Du1JnNOlyGC6FZVTBJLo5mrMTkWYajGQW89Zly7WGysN3rn2tu v3q1r/YRsHv1MhTawmPjaob8wZ8qYrysNCq0gQIwtxrNwJ0/df/LK6U+8vmZOcpVKIJ6 9YvPl7u5VwXHeTmdbi3XBxApux2Ym7nixYlN55WTRYPWOYDuk8/Nf0FrvkB+dKA4vIjG jL9g== MIME-Version: 1.0 X-Received: by 10.50.33.173 with SMTP id s13mr1933621igi.23.1359046473677; Thu, 24 Jan 2013 08:54:33 -0800 (PST) Sender: tomosann@gmail.com Received: by 10.64.63.111 with HTTP; Thu, 24 Jan 2013 08:54:33 -0800 (PST) In-Reply-To: <2AB6BF8B-8226-4A3B-997C-BD6E0DD7A948@employees.org> References: <20130124111531.12533.96909.idtracker@ietfa.amsl.com> <2AB6BF8B-8226-4A3B-997C-BD6E0DD7A948@employees.org> Date: Fri, 25 Jan 2013 01:54:33 +0900 X-Google-Sender-Auth: HpBfMjimC88f1UkdIBlByX4xUOU Message-ID: From: Tomoyuki Sahara To: Ole Troan Content-Type: text/plain; charset=ISO-8859-1 Cc: softwires@ietf.org Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-map-03.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 16:54:36 -0000 Hi, Example 2&3 were written for MAP-T and not updated for MAP(-E), so we should make some corrections to them. Suggested changes are: draft-ietf-softwire-map-03: > Example 2: > ... > MAP BR Prefix 2001:db8:ffff::/64 => IPv6 address of MAP BR: 2001:db8:ffff::1 > IPv6 source address 2001:db8:ffff:0:0001:0203:0400:: => IPv6 source address 2001:db8:ffff::1 > Example 3 - FMR: >... > configured on the MAP CE as follows: > > IPv6 address of BR used by MAP CE: 2001:db8:ffff::1 >... > IPv6 destination address: 2001:db8:ffff:0:0001:0203:0400:: => IPv6 destination address: 2001:db8:ffff::1 Thanks, Tomoyuki From despres.remi@laposte.net Thu Jan 24 09:09:14 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 947F521F8956 for ; Thu, 24 Jan 2013 09:09:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ssaWosn5l9Yj for ; Thu, 24 Jan 2013 09:09:14 -0800 (PST) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.11]) by ietfa.amsl.com (Postfix) with ESMTP id E536D21F8884 for ; Thu, 24 Jan 2013 09:09:05 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2206.sfr.fr (SMTP Server) with ESMTP id C883D7000120; Thu, 24 Jan 2013 18:09:04 +0100 (CET) Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2206.sfr.fr (SMTP Server) with ESMTP id 85CF87000040; Thu, 24 Jan 2013 18:09:04 +0100 (CET) X-SFR-UUID: 20130124170904548.85CF87000040@msfrf2206.sfr.fr Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Thu, 24 Jan 2013 18:09:02 +0100 Message-Id: <64AAE16E-C71C-493C-9C50-AB72B73A6719@laposte.net> References: <063.9dc31682f59256171b5d58fdb1cdcc5e@tools.ietf.org> <078.5016b38f0fa45b1e08acdf73cc564147@tools.ietf.org> To: "softwires@ietf.org WG" X-Mailer: Apple Mail (2.1499) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: [Softwires] PSID superfluous in MAP-E IIDs (part of ticket #19) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 17:09:14 -0000 2013-01-24 17:27, Ole Troan : > hi, >=20 > can we please keep discussion on the list. not via the issue tracker? - the issue tracker was AFAIK created by the chairs to be used. - I was answering a new input from Ole on the issue tracker itself, and = containing a question (see below). (Yet, if the chairs suggest to now avoid using the tracker, I will act = accordingly.) >=20 > does anyone else have an opinion? > (if I don't hear anything from anyone else, I'll default to keep = current text.) Ole's point was: "The interface-id has to be something. It is useful to put PSID and IPv4 = address in there for troubleshooting purposes. Do you have a proposal for what you'd rather want it to be? As the value is there largely for "pretty printing", just pick = something." My comment has been: "Value of having the PSID in MAP-E IIDs for maintenance isn't clear at = all: =95 PSID length isn't determined in IIDs (there can be an unknown number = of trailing zeroes) =95 all PSID bits are already readable in the first 64 bits Suggestion to close the issue:=20 =95 keep IPv4 addresses in IIDs (they contains some bits that aren't in = the first 64 bits) =95 don't keep the PSID in IIDs (insufficiently justified complexity)" Ole's reason to ignore this proposed simplification hasn't been given. Comments welcome. RD >=20 > cheers, > Ole >=20 > On Jan 24, 2013, at 17:23 , softwire issue tracker = wrote: >=20 >> #19: IPv4 address superfluous in MAP-E Interface IDs >>=20 >> Changes (by remi.despres@free.fr): >>=20 >> * priority: trivial =3D> major >> * status: closed =3D> reopened >> * resolution: wontfix =3D> >>=20 >>=20 >> Comment: >>=20 >> Value of having the PSID in MAP-E IIDs for maintenance isn't clear at = all: >> - PSID length isn't determined in IIDs (there can be an unknown = number of >> trailing zeroes) >> - all PSID bits are already readable in the first 64 bits >>=20 >> Suggestion to close the issue: >> - keep IPv4 addresses in IIDs (they contains some bits that aren't in = the >> first 64 bits) >> - don't keep the PSID in IIDs (insufficiently justified complexity) >>=20 >> --=20 >> = -------------------------+------------------------------------------------= - >> Reporter: | Owner: draft-ietf-softwire- >> remi.despres@free.fr | map@tools.ietf.org >> Type: defect | Status: reopened >> Priority: major | Milestone: >> Component: map-e | Version: >> Severity: Candidate | Resolution: >> WG Document | >> Keywords: | >> = -------------------------+------------------------------------------------= - >>=20 >> Ticket URL: = >> softwire >>=20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From sarikaya2012@gmail.com Thu Jan 24 09:51:49 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D369821F885C for ; Thu, 24 Jan 2013 09:51:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-HmSSAoS8Hd for ; Thu, 24 Jan 2013 09:51:49 -0800 (PST) Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) by ietfa.amsl.com (Postfix) with ESMTP id 698AA21F883C for ; Thu, 24 Jan 2013 09:51:48 -0800 (PST) Received: by mail-lb0-f175.google.com with SMTP id n3so7247259lbo.20 for ; Thu, 24 Jan 2013 09:51:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:reply-to:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=LC87/hDAjF3bX+t0HRfFpZX6QPZB2BYMsUPegKlVinw=; b=0pPW6Q8sbnXWtGs/vSpeqIEwtZYzCbxglKPEWngltS0Qq79FrGND3pgypsuJzVJf22 KoCjRoYyCOsPgrBQ5+BV7vXbJR0aphobTK9Sd/7YYAbn7lFHffJKCTt6NLbYJcMilUfg DfkfiY1CVCzdGky1780UU7Au00aQeDHYlljsfYM/uBoXLGEKbej015fXd342rw024mYu 0gbIo287MQ8MdrvRi50DiNLs6lYNlrqHPTsSMthZ6fiI+mdnnAp6htD6N3tYSuyVuEoa xHh6ZGJNlJQscMERUGdh7GPw17ErEPT86qKcJ85piDDhXRG7VUqk6YGIdJCnz0XZYsRE eq1A== MIME-Version: 1.0 X-Received: by 10.112.101.230 with SMTP id fj6mr1103047lbb.115.1359049907124; Thu, 24 Jan 2013 09:51:47 -0800 (PST) Received: by 10.114.78.37 with HTTP; Thu, 24 Jan 2013 09:51:47 -0800 (PST) In-Reply-To: <64AAE16E-C71C-493C-9C50-AB72B73A6719@laposte.net> References: <063.9dc31682f59256171b5d58fdb1cdcc5e@tools.ietf.org> <078.5016b38f0fa45b1e08acdf73cc564147@tools.ietf.org> <64AAE16E-C71C-493C-9C50-AB72B73A6719@laposte.net> Date: Thu, 24 Jan 2013 11:51:47 -0600 Message-ID: From: Behcet Sarikaya To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=f46d0401f99bf239db04d40c76eb Cc: "softwires@ietf.org WG" Subject: Re: [Softwires] PSID superfluous in MAP-E IIDs (part of ticket #19) X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 17:51:50 -0000 --f46d0401f99bf239db04d40c76eb Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Thu, Jan 24, 2013 at 11:09 AM, R=E9mi Despr=E9s wrote: > > 2013-01-24 17:27, Ole Troan : > > > hi, > > > > can we please keep discussion on the list. not via the issue tracker? > > - the issue tracker was AFAIK created by the chairs to be used. > Authors don't like the issue tracker. No author likes it. Because of this in several WGs, issue tracker is not used. I don't know why? Regards, Behcet - I was answering a new input from Ole on the issue tracker itself, and > containing a question (see below). > > (Yet, if the chairs suggest to now avoid using the tracker, I will act > accordingly.) > > > > > does anyone else have an opinion? > > (if I don't hear anything from anyone else, I'll default to keep curren= t > text.) > > Ole's point was: > "The interface-id has to be something. It is useful to put PSID and IPv4 > address in there for troubleshooting purposes. > Do you have a proposal for what you'd rather want it to be? > As the value is there largely for "pretty printing", just pick something.= " > > My comment has been: > "Value of having the PSID in MAP-E IIDs for maintenance isn't clear at al= l: > =95 PSID length isn't determined in IIDs (there can be an unknown number = of > trailing zeroes) > =95 all PSID bits are already readable in the first 64 bits > Suggestion to close the issue: > =95 keep IPv4 addresses in IIDs (they contains some bits that aren't in t= he > first 64 bits) > =95 don't keep the PSID in IIDs (insufficiently justified complexity)" > > Ole's reason to ignore this proposed simplification hasn't been given. > > Comments welcome. > > RD > > > > > > > > cheers, > > Ole > > > > On Jan 24, 2013, at 17:23 , softwire issue tracker < > trac+softwire@tools.ietf.org> wrote: > > > >> #19: IPv4 address superfluous in MAP-E Interface IDs > >> > >> Changes (by remi.despres@free.fr): > >> > >> * priority: trivial =3D> major > >> * status: closed =3D> reopened > >> * resolution: wontfix =3D> > >> > >> > >> Comment: > >> > >> Value of having the PSID in MAP-E IIDs for maintenance isn't clear at > all: > >> - PSID length isn't determined in IIDs (there can be an unknown number > of > >> trailing zeroes) > >> - all PSID bits are already readable in the first 64 bits > >> > >> Suggestion to close the issue: > >> - keep IPv4 addresses in IIDs (they contains some bits that aren't in > the > >> first 64 bits) > >> - don't keep the PSID in IIDs (insufficiently justified complexity) > >> > >> -- > >> > -------------------------+-----------------------------------------------= -- > >> Reporter: | Owner: draft-ietf-softwire- > >> remi.despres@free.fr | map@tools.ietf.org > >> Type: defect | Status: reopened > >> Priority: major | Milestone: > >> Component: map-e | Version: > >> Severity: Candidate | Resolution: > >> WG Document | > >> Keywords: | > >> > -------------------------+-----------------------------------------------= -- > >> > >> Ticket URL: < > http://trac.tools.ietf.org/wg/softwire/trac/ticket/19#comment:4> > >> softwire > >> > > > > _______________________________________________ > > Softwires mailing list > > Softwires@ietf.org > > https://www.ietf.org/mailman/listinfo/softwires > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --f46d0401f99bf239db04d40c76eb Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On Thu, Jan 24, 2013 at 11:09 AM, R=E9mi= Despr=E9s <despres.remi@laposte.net> wrote:

2013-01-24 17:27, Ole Troan <otr= oan@employees.org> :

> hi,
>
> can we please keep discussion on the list. not via the issue tracker?<= br>
- the issue tracker was AFAIK created by the chairs to be used.


Authors don't like the issue tracker. No author likes= it.
Because of this in several WGs, issue tracker is not used.
=A0
I don't know why?

Regards,

Behcet

- I was answering a new input from Ole on the issue tracker itself, and con= taining a question (see below).

(Yet, if the chairs suggest to now avoid using the tracker, I will act acco= rdingly.)

>
> does anyone else have an opinion?
> (if I don't hear anything from anyone else, I'll default to ke= ep current text.)

Ole's point was:
"The interface-id has to be something. It is useful to put PSID and IP= v4 address in there for troubleshooting purposes.
Do you have a proposal for what you'd rather want it to be?
As the value is there largely for "pretty printing", just pick so= mething."

My comment has been:
"Value of having the PSID in MAP-E IIDs for maintenance isn't clea= r at all:
=95 PSID length isn't determined in IIDs (there can be an unknown numbe= r of trailing zeroes)
=95 all PSID bits are already readable in the first 64 bits
Suggestion to close the issue:
=95 keep IPv4 addresses in IIDs (they contains some bits that aren't in= the first 64 bits)
=95 don't keep the PSID in IIDs (insufficiently justified complexity)&q= uot;

Ole's reason to ignore this proposed simplification hasn't been giv= en.

Comments welcome.

RD




>
> cheers,
> Ole
>
> On Jan 24, 2013, at 17:23 , softwire issue tracker <trac+softwire@tools.ietf.org> wro= te:
>
>> #19: IPv4 address superfluous in MAP-E Interface IDs
>>
>> Changes (by remi.despres@f= ree.fr):
>>
>> * priority: =A0trivial =3D> major
>> * status: =A0closed =3D> reopened
>> * resolution: =A0wontfix =3D>
>>
>>
>> Comment:
>>
>> Value of having the PSID in MAP-E IIDs for maintenance isn't c= lear at all:
>> - PSID length isn't determined in IIDs (there can be an unknow= n number of
>> trailing zeroes)
>> - all PSID bits are already readable in the first 64 bits
>>
>> Suggestion to close the issue:
>> - keep IPv4 addresses in IIDs (they contains some bits that aren&#= 39;t in the
>> first 64 bits)
>> - don't keep the PSID in IIDs (insufficiently justified comple= xity)
>>
>> --
>> -------------------------+----------------------------------------= ---------
>> Reporter: =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 Owner: =A0draf= t-ietf-softwire-
>> remi.despres@free.fr = =A0 | =A0map@tools.ietf.org
>> =A0 =A0Type: =A0defect =A0 =A0 =A0 | =A0 =A0 =A0Status: =A0reopene= d
>> Priority: =A0major =A0 =A0 =A0 =A0| =A0 Milestone:
>> Component: =A0map-e =A0 =A0 =A0 =A0| =A0 =A0 Version:
>> Severity: =A0Candidate =A0 =A0| =A0Resolution:
>> WG Document =A0 =A0 =A0 =A0 =A0 =A0|
>> Keywords: =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
>> -------------------------+----------------------------------------= ---------
>>
>> Ticket URL: <http://trac.tools.ietf.org/wg/s= oftwire/trac/ticket/19#comment:4>
>> softwire <http://tools.ietf.org/softwire/>
>>
>
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

--f46d0401f99bf239db04d40c76eb-- From tom.taylor.stds@gmail.com Thu Jan 24 12:08:37 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13DF411E80A4 for ; Thu, 24 Jan 2013 12:08:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPxWLNhD4Rc9 for ; Thu, 24 Jan 2013 12:08:36 -0800 (PST) Received: from mail-ob0-f179.google.com (mail-ob0-f179.google.com [209.85.214.179]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC0811E80A6 for ; Thu, 24 Jan 2013 12:08:36 -0800 (PST) Received: by mail-ob0-f179.google.com with SMTP id un3so162180obb.38 for ; Thu, 24 Jan 2013 12:08:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-antivirus:x-antivirus-status; bh=UWc/OLrn6B7BDfiJJQJWx5GWnbtui0TnYN8JVLj6pKw=; b=QdCR93aUzlD0f6sGqfSNiaQO3k6sB7tmS/gs191gacr2+AMBXCcO9O0CwPGj49mK+5 vOWgQRwE6izpxzcpGJuAsvdxb6MioRtfHtsLO0AUb5KwvIDeXsftK057VwXyljnSBtTO oYLRctHkZ0IbDdmHRHWFs0+hXKjLR4w/p3OVh3ViOTCidd9VesN8gU8V70hQF8AIUsi/ ARYmVvvoHkXUtKu3109nCryh7IUI72mxAOBEFwclUq5JEQedIYXDe53OOnO26RAnViO3 84s+aoqelDwdmQVp1IJ0Ol7E/BheVsoxbi7QgqF3rEr1CW1ZS2LdhI6DycsNLjT7aLcp Pjxg== X-Received: by 10.50.150.148 with SMTP id ui20mr2323795igb.68.1359058116061; Thu, 24 Jan 2013 12:08:36 -0800 (PST) Received: from [127.0.0.1] (dsl-173-206-87-33.tor.primus.ca. [173.206.87.33]) by mx.google.com with ESMTPS id k5sm2058990igq.9.2013.01.24.12.08.34 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Jan 2013 12:08:35 -0800 (PST) Message-ID: <510194C3.7010001@gmail.com> Date: Thu, 24 Jan 2013 15:08:35 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Ole Troan References: <063.9dc31682f59256171b5d58fdb1cdcc5e@tools.ietf.org> <078.5016b38f0fa45b1e08acdf73cc564147@tools.ietf.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130124-0, 24/01/2013), Outbound message X-Antivirus-Status: Clean Cc: "softwires@ietf.org WG" Subject: Re: [Softwires] [softwire] #19: IPv4 address superfluous in MAP-E Interface IDs X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 20:08:37 -0000 This caught my eye too. Why repeat the PSID? On 24/01/2013 11:27 AM, Ole Troan wrote: > hi, > > can we please keep discussion on the list. not via the issue tracker? > > does anyone else have an opinion? > (if I don't hear anything from anyone else, I'll default to keep current text.) > > cheers, > Ole > > On Jan 24, 2013, at 17:23 , softwire issue tracker wrote: > >> #19: IPv4 address superfluous in MAP-E Interface IDs >> >> Changes (by remi.despres@free.fr): >> >> * priority: trivial => major >> * status: closed => reopened >> * resolution: wontfix => >> >> >> Comment: >> >> Value of having the PSID in MAP-E IIDs for maintenance isn't clear at all: >> - PSID length isn't determined in IIDs (there can be an unknown number of >> trailing zeroes) >> - all PSID bits are already readable in the first 64 bits >> >> Suggestion to close the issue: >> - keep IPv4 addresses in IIDs (they contains some bits that aren't in the >> first 64 bits) >> - don't keep the PSID in IIDs (insufficiently justified complexity) >> ... From otroan@employees.org Thu Jan 24 14:45:03 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5278721F84DE for ; Thu, 24 Jan 2013 14:45:03 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QfqJ5z8dV6uH for ; Thu, 24 Jan 2013 14:45:02 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 8D7191F0CDF for ; Thu, 24 Jan 2013 14:44:59 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADq4AVGQ/khN/2dsb2JhbABEukqEABZzgh4BAQQBeQULCxguVwYTiAgDBgMGtDoMiVaQGmEDplSCeQ X-IronPort-AV: E=Sophos;i="4.84,532,1355097600"; d="scan'208";a="79979755" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 24 Jan 2013 22:44:58 +0000 Received: from dhcp-10-61-108-166.cisco.com (dhcp-10-61-108-166.cisco.com [10.61.108.166]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r0OMiu5f024365 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 24 Jan 2013 22:44:58 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ole Troan In-Reply-To: <510194C3.7010001@gmail.com> Date: Thu, 24 Jan 2013 23:44:56 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <063.9dc31682f59256171b5d58fdb1cdcc5e@tools.ietf.org> <078.5016b38f0fa45b1e08acdf73cc564147@tools.ietf.org> <510194C3.7010001@gmail.com> To: Tom Taylor X-Mailer: Apple Mail (2.1499) Cc: "softwires@ietf.org WG" Subject: Re: [Softwires] [softwire] #19: IPv4 address superfluous in MAP-E Interface IDs X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 22:45:03 -0000 Tom, > This caught my eye too. Why repeat the PSID? the reason I got, if my memory serves me correctly, is that it allows a = intermediate box to look at the PSID, without knowing the mapping rules (which it must to look at the PSID in = the first 64 bits. cheers, Ole >=20 > On 24/01/2013 11:27 AM, Ole Troan wrote: >> hi, >>=20 >> can we please keep discussion on the list. not via the issue tracker? >>=20 >> does anyone else have an opinion? >> (if I don't hear anything from anyone else, I'll default to keep = current text.) >>=20 >> cheers, >> Ole >>=20 >> On Jan 24, 2013, at 17:23 , softwire issue tracker = wrote: >>=20 >>> #19: IPv4 address superfluous in MAP-E Interface IDs >>>=20 >>> Changes (by remi.despres@free.fr): >>>=20 >>> * priority: trivial =3D> major >>> * status: closed =3D> reopened >>> * resolution: wontfix =3D> >>>=20 >>>=20 >>> Comment: >>>=20 >>> Value of having the PSID in MAP-E IIDs for maintenance isn't clear = at all: >>> - PSID length isn't determined in IIDs (there can be an unknown = number of >>> trailing zeroes) >>> - all PSID bits are already readable in the first 64 bits >>>=20 >>> Suggestion to close the issue: >>> - keep IPv4 addresses in IIDs (they contains some bits that aren't = in the >>> first 64 bits) >>> - don't keep the PSID in IIDs (insufficiently justified complexity) >>>=20 > ... From otroan@employees.org Thu Jan 24 14:48:40 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2781721F852B for ; Thu, 24 Jan 2013 14:48:40 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XQdeImligTI8 for ; Thu, 24 Jan 2013 14:48:39 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 7857D21F8518 for ; Thu, 24 Jan 2013 14:48:39 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlIJAJm5AVGQ/khN/2dsb2JhbABEumyCSwQEgQsWc4IeAQEEAXkFCwtGVwaIJwa+HZAaYQOmVIJ5 X-IronPort-AV: E=Sophos;i="4.84,532,1355097600"; d="scan'208";a="79979799" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 24 Jan 2013 22:48:34 +0000 Received: from dhcp-10-61-108-166.cisco.com (dhcp-10-61-108-166.cisco.com [10.61.108.166]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r0OMmXm0024841 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 24 Jan 2013 22:48:34 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ole Troan In-Reply-To: Date: Thu, 24 Jan 2013 23:48:33 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <20130124111531.12533.96909.idtracker@ietfa.amsl.com> <2AB6BF8B-8226-4A3B-997C-BD6E0DD7A948@employees.org> To: Tomoyuki Sahara X-Mailer: Apple Mail (2.1499) Cc: softwires@ietf.org Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-map-03.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 22:48:40 -0000 Tomoyuki-san, > Example 2&3 were written for MAP-T and not updated for MAP(-E), > so we should make some corrections to them. excellent. getting the examples right has proven quite hard. updated with the below. cheers, Ole > > Suggested changes are: > > draft-ietf-softwire-map-03: >> Example 2: >> ... >> MAP BR Prefix 2001:db8:ffff::/64 > > => IPv6 address of MAP BR: 2001:db8:ffff::1 > >> IPv6 source address 2001:db8:ffff:0:0001:0203:0400:: > > => IPv6 source address 2001:db8:ffff::1 > >> Example 3 - FMR: >> ... >> configured on the MAP CE as follows: >> >> IPv6 address of BR used by MAP CE: 2001:db8:ffff::1 >> ... >> IPv6 destination address: 2001:db8:ffff:0:0001:0203:0400:: > > => IPv6 destination address: 2001:db8:ffff::1 > > > Thanks, > Tomoyuki From satoru.matsushima@gmail.com Thu Jan 24 15:56:21 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E7E911E809B for ; Thu, 24 Jan 2013 15:56:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rcVqwe4oMaCP for ; Thu, 24 Jan 2013 15:56:20 -0800 (PST) Received: from mail-pa0-f42.google.com (mail-pa0-f42.google.com [209.85.220.42]) by ietfa.amsl.com (Postfix) with ESMTP id ABC5611E8099 for ; Thu, 24 Jan 2013 15:56:20 -0800 (PST) Received: by mail-pa0-f42.google.com with SMTP id rl6so5854690pac.29 for ; Thu, 24 Jan 2013 15:56:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=KkR6ja0pbd2E/DOPqx07Rc2u1d5reuK0g8xsWizXtDM=; b=w0QuvJUWJ4x0QbqoPz/bh6uvJVBFMBpkBTBg597Zq49zaAPzlCu4kHHOGdWBZyoeku DcimuSaD2Y7hdLiODZucccVnnRD3xmmpdtBtlHU3FJaam7Njqdp7N0lCdd7ic9F0Bkj0 LPZocpZt3vVaOsmvaAIAU6XaiRf4enKRD2upOYkBehmsUjp4Og5XLd2Hntp6mqRjkEVO KBDJwAqPdgS2xKU5P2VpG3NaCQ5Jtov26+iLMys4R0CuIg1e3tWO32nNKeMr38r1tLsE JlMSZ3XFXDpGgs1TsVJQng8PujrH1pX7h8PLkwUX7hP4qDU5F16HBOetv9Wz+MwPbiao Zgtg== X-Received: by 10.69.16.100 with SMTP id fv4mr9451871pbd.135.1359071780514; Thu, 24 Jan 2013 15:56:20 -0800 (PST) Received: from [192.168.12.101] (157-112-198-105.gree.jp. [157.112.198.105]) by mx.google.com with ESMTPS id ov4sm15684059pbb.45.2013.01.24.15.56.18 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Jan 2013 15:56:19 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Satoru Matsushima In-Reply-To: <510194C3.7010001@gmail.com> Date: Fri, 25 Jan 2013 08:56:17 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <6B276195-A334-4F09-9B9A-DDBAD54221D3@gmail.com> References: <063.9dc31682f59256171b5d58fdb1cdcc5e@tools.ietf.org> <078.5016b38f0fa45b1e08acdf73cc564147@tools.ietf.org> <510194C3.7010001@gmail.com> To: Tom Taylor , Ole Troan X-Mailer: Apple Mail (2.1499) Cc: "softwires@ietf.org WG" Subject: Re: [Softwires] [softwire] #19: IPv4 address superfluous in MAP-E Interface IDs X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 23:56:21 -0000 On 2013/01/25, at 5:08, Tom Taylor wrote: > This caught my eye too. Why repeat the PSID? >=20 Does anyone have the reason of it must not? cheers, --satoru > On 24/01/2013 11:27 AM, Ole Troan wrote: >> hi, >>=20 >> can we please keep discussion on the list. not via the issue tracker? >>=20 >> does anyone else have an opinion? >> (if I don't hear anything from anyone else, I'll default to keep = current text.) >>=20 >> cheers, >> Ole >>=20 >> On Jan 24, 2013, at 17:23 , softwire issue tracker = wrote: >>=20 >>> #19: IPv4 address superfluous in MAP-E Interface IDs >>>=20 >>> Changes (by remi.despres@free.fr): >>>=20 >>> * priority: trivial =3D> major >>> * status: closed =3D> reopened >>> * resolution: wontfix =3D> >>>=20 >>>=20 >>> Comment: >>>=20 >>> Value of having the PSID in MAP-E IIDs for maintenance isn't clear = at all: >>> - PSID length isn't determined in IIDs (there can be an unknown = number of >>> trailing zeroes) >>> - all PSID bits are already readable in the first 64 bits >>>=20 >>> Suggestion to close the issue: >>> - keep IPv4 addresses in IIDs (they contains some bits that aren't = in the >>> first 64 bits) >>> - don't keep the PSID in IIDs (insufficiently justified complexity) >>>=20 > ... > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From tom.taylor.stds@gmail.com Thu Jan 24 16:19:57 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D400A11E809B for ; Thu, 24 Jan 2013 16:19:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.776 X-Spam-Level: X-Spam-Status: No, score=-1.776 tagged_above=-999 required=5 tests=[AWL=-1.824, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5LHh8WCuL3Ur for ; Thu, 24 Jan 2013 16:19:57 -0800 (PST) Received: from mail-ia0-x235.google.com (ia-in-x0235.1e100.net [IPv6:2607:f8b0:4001:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 5E67B11E8099 for ; Thu, 24 Jan 2013 16:19:57 -0800 (PST) Received: by mail-ia0-f181.google.com with SMTP id k25so5744647iah.12 for ; Thu, 24 Jan 2013 16:19:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-antivirus:x-antivirus-status; bh=8Zz6HaY83M1gTtGqW0VukNye9YcfjIy/d5/RcJHjXYs=; b=sALkA6KYwi2DGIgWdcwdQ/mahyTNDq0yyZqmlztv5CL6WNc3mirdclNaNdo5kw0udi u8cr/JFewJyoQeBEpGFLJLTxwT9KQBMk5eIJeODnTeXI8S7+Om31YUH2T6IhwfoPN2FH ODKTC0ph1uUu4MJNe06WySQsXgwkbbJ+z5WOZHe7pxHXsrHqtmGCa5xLRoal1JUYJwMa PP0cEtIPSpyt2R4WpeRnpOmIBlmikp14CvOAyF61ufFLIV/Hue2uqFhG6NC6ClpFPeYT uNwL+8efKTz4Ld7dZ3tn9487oYGgwF/AgOqFoF3P6y7qyzk83+1dE88GHx6dxYbxMa/X JgKw== X-Received: by 10.50.40.229 with SMTP id a5mr2878503igl.59.1359073196779; Thu, 24 Jan 2013 16:19:56 -0800 (PST) Received: from [127.0.0.1] (dsl-173-206-87-33.tor.primus.ca. [173.206.87.33]) by mx.google.com with ESMTPS id b13sm2694090igp.7.2013.01.24.16.19.55 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Jan 2013 16:19:56 -0800 (PST) Message-ID: <5101CFAC.8040705@gmail.com> Date: Thu, 24 Jan 2013 19:19:56 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Ole Troan References: <063.9dc31682f59256171b5d58fdb1cdcc5e@tools.ietf.org> <078.5016b38f0fa45b1e08acdf73cc564147@tools.ietf.org> <510194C3.7010001@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130124-1, 24/01/2013), Outbound message X-Antivirus-Status: Clean Cc: "softwires@ietf.org WG" Subject: Re: [Softwires] [softwire] #19: IPv4 address superfluous in MAP-E Interface IDs X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 00:19:57 -0000 I am not sure that's of any use to intermediate nodes without the rest of the rules, but I suppose you have to put something unique into the IID. I have one concern indirectly related to this. Section 6 still says: If the End-user IPv6 prefix length is larger than 64, the most significant parts of the interface identifier is overwritten by the prefix. I believe that makes the IID non-conformant to RFC 6052. On 24/01/2013 5:44 PM, Ole Troan wrote: > Tom, > >> This caught my eye too. Why repeat the PSID? > > the reason I got, if my memory serves me correctly, is that it allows a intermediate box to look at the PSID, > without knowing the mapping rules (which it must to look at the PSID in the first 64 bits. > > cheers, > Ole > > >> >> On 24/01/2013 11:27 AM, Ole Troan wrote: >>> hi, >>> >>> can we please keep discussion on the list. not via the issue tracker? >>> >>> does anyone else have an opinion? >>> (if I don't hear anything from anyone else, I'll default to keep current text.) >>> >>> cheers, >>> Ole >>> >>> On Jan 24, 2013, at 17:23 , softwire issue tracker wrote: >>> >>>> #19: IPv4 address superfluous in MAP-E Interface IDs >>>> >>>> Changes (by remi.despres@free.fr): >>>> >>>> * priority: trivial => major >>>> * status: closed => reopened >>>> * resolution: wontfix => >>>> >>>> >>>> Comment: >>>> >>>> Value of having the PSID in MAP-E IIDs for maintenance isn't clear at all: >>>> - PSID length isn't determined in IIDs (there can be an unknown number of >>>> trailing zeroes) >>>> - all PSID bits are already readable in the first 64 bits >>>> >>>> Suggestion to close the issue: >>>> - keep IPv4 addresses in IIDs (they contains some bits that aren't in the >>>> first 64 bits) >>>> - don't keep the PSID in IIDs (insufficiently justified complexity) >>>> >> ... > > From otroan@employees.org Thu Jan 24 16:22:39 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 562B211E809B for ; Thu, 24 Jan 2013 16:22:39 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1JNpFgfn0fAI for ; Thu, 24 Jan 2013 16:22:38 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 3069D11E8099 for ; Thu, 24 Jan 2013 16:22:38 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At4KALjPAVGQ/khL/2dsb2JhbABEvTcBAwEDgQcWc4IeAQEEAXkFCwtGVwaIJwa+IZAaYQOmVIJ5 X-IronPort-AV: E=Sophos;i="4.84,532,1355097600"; d="scan'208";a="79981290" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 25 Jan 2013 00:22:36 +0000 Received: from dhcp-10-61-108-166.cisco.com (dhcp-10-61-108-166.cisco.com [10.61.108.166]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r0P0Ma06030652 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 25 Jan 2013 00:22:36 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ole Troan In-Reply-To: <5101CFAC.8040705@gmail.com> Date: Fri, 25 Jan 2013 01:22:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0A42A08D-9515-4266-AD49-63CD42C5A0E9@employees.org> References: <063.9dc31682f59256171b5d58fdb1cdcc5e@tools.ietf.org> <078.5016b38f0fa45b1e08acdf73cc564147@tools.ietf.org> <510194C3.7010001@gmail.com> <5101CFAC.8040705@gmail.com> To: Tom Taylor X-Mailer: Apple Mail (2.1499) Cc: "softwires@ietf.org WG" Subject: Re: [Softwires] [softwire] #19: IPv4 address superfluous in MAP-E Interface IDs X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 00:22:39 -0000 Tom, > I believe that makes the IID non-conformant to RFC 6052. it uses an IID similar to 6052... any better suggestion? (my personal view is that 6052 got things wrong with the U octet, but = that's another matter) cheers, Ole From tom.taylor.stds@gmail.com Thu Jan 24 16:25:33 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72F2411E80C5 for ; Thu, 24 Jan 2013 16:25:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.411 X-Spam-Level: X-Spam-Status: No, score=-1.411 tagged_above=-999 required=5 tests=[AWL=-1.459, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S2metvIAJJI1 for ; Thu, 24 Jan 2013 16:25:33 -0800 (PST) Received: from mail-ia0-x22d.google.com (ia-in-x022d.1e100.net [IPv6:2607:f8b0:4001:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id EF41011E8099 for ; Thu, 24 Jan 2013 16:25:32 -0800 (PST) Received: by mail-ia0-f173.google.com with SMTP id l29so5715262iag.4 for ; Thu, 24 Jan 2013 16:25:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding:x-antivirus :x-antivirus-status; bh=7eLknu/Kfva74nJxED6hEBfXNNpXmiCipJKjE5Nb+WQ=; b=i7SQls6OmUAOyLK+AfmsBOcGJt3i3+hVxXPlB0j9bLxgc8Lm4uubHHFu1RzkskLYia x+wZPT7cCdKFAhAgE74XIvI4jPBZUEr+IkRXMiID7QGpb9kMekiGqP6dNdxoxLEXFmIF RbfHno4IMaNiikx7bX93weBKcYq6Ct/UwEPW8WA0xe9iJoMDwqdB9nbzI22UQhbqvoKE RcMOjn/PZT6M1yRn47L4ToPKw0BQI39qa8Iur2nFDJL95+wM9qozcDJZ1HreqOjxzS6P VWhiFTe2tii6ycThu1nMpHvMb+j4p1Sw/9SJcxURuCaWczdjPz35J60SLNzLvSmChoKh WNcw== X-Received: by 10.50.154.229 with SMTP id vr5mr2670859igb.49.1359073532655; Thu, 24 Jan 2013 16:25:32 -0800 (PST) Received: from [127.0.0.1] (dsl-173-206-87-33.tor.primus.ca. [173.206.87.33]) by mx.google.com with ESMTPS id kp4sm2722507igc.1.2013.01.24.16.25.31 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Jan 2013 16:25:32 -0800 (PST) Message-ID: <5101D0FC.5010001@gmail.com> Date: Thu, 24 Jan 2013 19:25:32 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Softwires Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130124-1, 24/01/2013), Outbound message X-Antivirus-Status: Clean Subject: [Softwires] Comments on draft-ietf-softwire-map-03 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 00:25:33 -0000 Section 4 --------- It might be best to describe operations with respect to shared addresses first, then describe the exceptions for full IPv4 addresses or IPv4 prefixes at the end. As it is, you switch back and forth from these to shared addresses and it is not totally clear what applies to one versus the other. The main question that arises in my mind as a result of the current arrangement of text is whether a NAPT is required if a full address or prefix is provisioned. If so, what does it do? Beyond that, I would even question whether a MAP module is needed for a full address or an address derived from a prefix, and not simply an RFC6052-compliant encapsulator. Paragraph 4 talks about MAP provisioning a full address or prefix. I don't think MAP is a provisioning process -- just talk about whether a full address or a prefix was provisioned. Typo in the first line of the section: s/e.g. For/e.g., for/. Section 5 --------- Where is the definition of the optional port parameters? Section 5.2 ----------- The first sentence of paragraph 3 relates to the naive algorithm specified in paragraph 2 and should be part of that paragraph. I was confused the first time I read this part. Section 5 has now abstracted the port mapping algorithm, leaving it unspecified. But the GMA is still there implicitly. I believe it wouldn't hurt to say that the underlying algorithm allocates ports to a given CE as a series of contiguous ranges, occupying the same relative position in each in a series of fixed-sized blocks. More later ... From otroan@employees.org Fri Jan 25 01:47:04 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 578FA21F858A for ; Fri, 25 Jan 2013 01:47:04 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rvvKS5h11ntr for ; Fri, 25 Jan 2013 01:47:03 -0800 (PST) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 8495421F8576 for ; Fri, 25 Jan 2013 01:47:03 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EACVUAlGQ/khM/2dsb2JhbABEvlMWc4IeAQEEATo/BQsLRlcGiCcGvgOQXWEDplSCeQ X-IronPort-AV: E=Sophos;i="4.84,537,1355097600"; d="scan'208";a="11328588" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-3.cisco.com with ESMTP; 25 Jan 2013 09:47:01 +0000 Received: from dhcp-10-61-107-243.cisco.com (dhcp-10-61-107-243.cisco.com [10.61.107.243]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r0P9l0Zi031766 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 25 Jan 2013 09:47:01 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ole Troan In-Reply-To: <5101D0FC.5010001@gmail.com> Date: Fri, 25 Jan 2013 10:47:00 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5101D0FC.5010001@gmail.com> To: Tom Taylor X-Mailer: Apple Mail (2.1499) Cc: Softwires Subject: Re: [Softwires] Comments on draft-ietf-softwire-map-03 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 09:47:04 -0000 Tom, thanks again for thorough comments, very much appreciated! > Section 4 > --------- >=20 > It might be best to describe operations with respect to shared = addresses first, then describe the exceptions for full IPv4 addresses or = IPv4 prefixes at the end. As it is, you switch back and forth from these = to shared addresses and it is not totally clear what applies to one = versus the other. The main question that arises in my mind as a result = of the current arrangement of text is whether a NAPT is required if a = full address or prefix is provisioned. If so, what does it do? Beyond = that, I would even question whether a MAP module is needed for a full = address or an address derived from a prefix, and not simply an = RFC6052-compliant encapsulator. I tend to agree with your concerns with regards to the shared address, = full address, prefix split. would you be able to create a proposal for how the document would be = organised, e.g. with section titles, if we refactor it this way? at NA(P)T is optional in the full IPv4 address or IPv4 prefix case. it would in that case work exactly like IPv4 NAT does on CPEs today. RFC2473 compliant encapsulator? RFC2473 only specifies a point to point tunnel. the MAP modules gives = provisioning and it gives mesh mode. > Paragraph 4 talks about MAP provisioning a full address or prefix. I = don't think MAP is a provisioning process -- just talk about whether a = full address or a prefix was provisioned. what would be a better wording? MAP "calculates" an IPv4 address based on some information from a DHCP = option and some (or none) information from the IPv6 prefix. what's the verb describing that? "the MAP CE _implies_ its IPv4 = addressing information". deduces, calculates, configures?=20 > Typo in the first line of the section: s/e.g. For/e.g., for/. fixed. > Section 5 > --------- >=20 > Where is the definition of the optional port parameters? it is currently described under "a-bits" section 5.1. the optional port parameters only include the offset. although -02 alluded to also a "well known ports" flag. flexibility versus simplicity. in my opinion we should drop the port = parameters from the base MAP spec, and fix the offset to 4. > Section 5.2 > ----------- >=20 > The first sentence of paragraph 3 relates to the naive algorithm = specified in paragraph 2 and should be part of that paragraph. I was = confused the first time I read this part. could you point out the exact paragraphs, I'm not quite sure which ones = you mean? > Section 5 has now abstracted the port mapping algorithm, leaving it = unspecified. But the GMA is still there implicitly. I believe it = wouldn't hurt to say that the underlying algorithm allocates ports to a = given CE as a series of contiguous ranges, occupying the same relative = position in each in a series of fixed-sized blocks. thanks, I've added that more or less verbatim. Best regards, Ole From sarikaya2012@gmail.com Fri Jan 25 09:42:29 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEF8F21F885B for ; Fri, 25 Jan 2013 09:42:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.448 X-Spam-Level: X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8s28HqGqqNXq for ; Fri, 25 Jan 2013 09:42:29 -0800 (PST) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) by ietfa.amsl.com (Postfix) with ESMTP id 5406B21F8844 for ; Fri, 25 Jan 2013 09:42:28 -0800 (PST) Received: by mail-lb0-f173.google.com with SMTP id gf7so1146026lbb.4 for ; Fri, 25 Jan 2013 09:42:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:reply-to:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=SKuNWmkT6Kv1LIlBVwvlmaF6z7/QYlpGhwtmT85s1nE=; b=mtR7mhQPUohwyXSCz1l/xPxj6LS+0EBeJLLwz0irrYicJe1N3+iUVW/4X90tiEjYkD gnM0yGmkJHcgLKpck1wkUVARip9mi3rN3+vB0X4RR2gGF47QHgq5Idh+uhjHEtPZTWhF zgIIkJcSLNioVoFAaB3w/UD1V9vcp0mJ/cAWPjsVJ44kobsNdBxP51+NFOE+iQr5mFOU ed8z6TlfDjypDKSpAFlPGHcTMgvPo5OwedZCIkDzMCMcbMicbC98hmwuydnC9s3LUnyn hHwU0FMUuk8GIVCgDBvtre2SoXWGbluJfkpTOag4qLcCQbuRPIga25bHDPGASeVjaHYU IhKQ== MIME-Version: 1.0 X-Received: by 10.112.38.67 with SMTP id e3mr2422159lbk.105.1359135746941; Fri, 25 Jan 2013 09:42:26 -0800 (PST) Received: by 10.114.78.37 with HTTP; Fri, 25 Jan 2013 09:42:26 -0800 (PST) In-Reply-To: References: <5101D0FC.5010001@gmail.com> Date: Fri, 25 Jan 2013 11:42:26 -0600 Message-ID: From: Behcet Sarikaya To: Ole Troan Content-Type: multipart/alternative; boundary=e0cb4efe2c2465e57b04d4207305 Cc: Softwires , Softwire Chairs Subject: Re: [Softwires] Comments on draft-ietf-softwire-map-03 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 17:42:29 -0000 --e0cb4efe2c2465e57b04d4207305 Content-Type: text/plain; charset=ISO-8859-1 May I suggest that Tom to become the editor of MAP-E draft? Behcet On Fri, Jan 25, 2013 at 3:47 AM, Ole Troan wrote: > Tom, > > thanks again for thorough comments, very much appreciated! > > > Section 4 > > --------- > > > > It might be best to describe operations with respect to shared addresses > first, then describe the exceptions for full IPv4 addresses or IPv4 > prefixes at the end. As it is, you switch back and forth from these to > shared addresses and it is not totally clear what applies to one versus the > other. The main question that arises in my mind as a result of the current > arrangement of text is whether a NAPT is required if a full address or > prefix is provisioned. If so, what does it do? Beyond that, I would even > question whether a MAP module is needed for a full address or an address > derived from a prefix, and not simply an RFC6052-compliant encapsulator. > > I tend to agree with your concerns with regards to the shared address, > full address, prefix split. > would you be able to create a proposal for how the document would be > organised, e.g. with section titles, > if we refactor it this way? > > at NA(P)T is optional in the full IPv4 address or IPv4 prefix case. > it would in that case work exactly like IPv4 NAT does on CPEs today. > > RFC2473 compliant encapsulator? > RFC2473 only specifies a point to point tunnel. the MAP modules gives > provisioning and it gives mesh mode. > > > Paragraph 4 talks about MAP provisioning a full address or prefix. I > don't think MAP is a provisioning process -- just talk about whether a full > address or a prefix was provisioned. > > what would be a better wording? > MAP "calculates" an IPv4 address based on some information from a DHCP > option and some (or none) information from the IPv6 prefix. > what's the verb describing that? "the MAP CE _implies_ its IPv4 addressing > information". deduces, calculates, configures? > > > Typo in the first line of the section: s/e.g. For/e.g., for/. > > fixed. > > > Section 5 > > --------- > > > > Where is the definition of the optional port parameters? > > it is currently described under "a-bits" section 5.1. > the optional port parameters only include the offset. > although -02 alluded to also a "well known ports" flag. > > flexibility versus simplicity. in my opinion we should drop the port > parameters > from the base MAP spec, and fix the offset to 4. > > > Section 5.2 > > ----------- > > > > The first sentence of paragraph 3 relates to the naive algorithm > specified in paragraph 2 and should be part of that paragraph. I was > confused the first time I read this part. > > could you point out the exact paragraphs, I'm not quite sure which ones > you mean? > > > Section 5 has now abstracted the port mapping algorithm, leaving it > unspecified. But the GMA is still there implicitly. I believe it wouldn't > hurt to say that the underlying algorithm allocates ports to a given CE as > a series of contiguous ranges, occupying the same relative position in each > in a series of fixed-sized blocks. > > thanks, I've added that more or less verbatim. > > Best regards, > Ole > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --e0cb4efe2c2465e57b04d4207305 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable May I suggest that Tom to become the editor of MAP-E draft?

Behcet
On Fri, Jan 25, 2013 at 3:47 AM, Ole Troan= <otroan@employees.org> wrote:
Tom,

thanks again for thorough comments, very much appreciated!

> Section 4
> ---------
>
> It might be best to describe operations with respect to shared address= es first, then describe the exceptions for full IPv4 addresses or IPv4 pref= ixes at the end. As it is, you switch back and forth from these to shared a= ddresses and it is not totally clear what applies to one versus the other. = The main question that arises in my mind as a result of the current arrange= ment of text is whether a NAPT is required if a full address or prefix is p= rovisioned. If so, what does it do? Beyond that, I would even question whet= her a MAP module is needed for a full address or an address derived from a = prefix, and not simply an RFC6052-compliant encapsulator.

I tend to agree =A0with your concerns with regards to the shared addr= ess, full address, prefix split.
would you be able to create a proposal for how the document would be organi= sed, e.g. with section titles,
if we refactor it this way?

at NA(P)T is optional in the full IPv4 address or IPv4 prefix case.
it would in that case work exactly like IPv4 NAT does on CPEs today.

RFC2473 compliant encapsulator?
RFC2473 only specifies a point to point tunnel. the MAP modules gives provi= sioning and it gives mesh mode.

> Paragraph 4 talks about MAP provisioning a full address or prefix. I d= on't think MAP is a provisioning process -- just talk about whether a f= ull address or a prefix was provisioned.

what would be a better wording?
MAP "calculates" an IPv4 address based on some information from a= DHCP option and some (or none) information from the IPv6 prefix.
what's the verb describing that? "the MAP CE _implies_ its IPv4 ad= dressing information". deduces, calculates, configures?

> Typo in the first line of the section: s/e.g. For/e.g., for/.

fixed.

> Section 5
> ---------
>
> Where is the definition of the optional port parameters?

it is currently described under "a-bits" section 5.1.
the optional port parameters only include the offset.
although -02 alluded to also a "well known ports" flag.

flexibility versus simplicity. in my opinion we should drop the port parame= ters
from the base MAP spec, and fix the offset to 4.

> Section 5.2
> -----------
>
> The first sentence of paragraph 3 relates to the naive algorithm speci= fied in paragraph 2 and should be part of that paragraph. I was confused th= e first time I read this part.

could you point out the exact paragraphs, I'm not quite sure whic= h ones you mean?

> Section 5 has now abstracted the port mapping algorithm, leaving it un= specified. But the GMA is still there implicitly. I believe it wouldn't= hurt to say that the underlying algorithm allocates ports to a given CE as= a series of contiguous ranges, occupying the same relative position in eac= h in a series of fixed-sized blocks.

thanks, I've added that more or less verbatim.

Best regards,
Ole

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

--e0cb4efe2c2465e57b04d4207305-- From tom.taylor.stds@gmail.com Fri Jan 25 10:09:53 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7FDB21F8831 for ; Fri, 25 Jan 2013 10:09:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.168 X-Spam-Level: X-Spam-Status: No, score=-1.168 tagged_above=-999 required=5 tests=[AWL=-1.216, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WHzFdATPGU-a for ; Fri, 25 Jan 2013 10:09:53 -0800 (PST) Received: from mail-ia0-x22e.google.com (mail-ia0-x22e.google.com [IPv6:2607:f8b0:4001:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 3841121F8842 for ; Fri, 25 Jan 2013 10:09:53 -0800 (PST) Received: by mail-ia0-f174.google.com with SMTP id o25so1007264iad.19 for ; Fri, 25 Jan 2013 10:09:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-antivirus:x-antivirus-status; bh=tEdBSdTy3KF0w8XDI/X7PwUweYfkNuUGS6659EMkpjE=; b=NAoxbtlD5+8kEgRKAA2F42FzcjJG0Fl0ycI9D49rBskvhCpe2LwnU6+JTuXv3AX0v1 69Ox154u+l2aCp04LoiPpBxJaQtm49K/2fBaYPi+azJGzW5tYmoZ38GuGEQYircLJmc3 11+4md+OWKHvNm04Geq4G1MvD2dpLxURvtUjIeCTHftWYoaGRJeLpHwalye01/3GzTLY dE8iTjuU7x7rnRmBemX3RIRQ7pb8zYL4aThUEqE6D7efHvKuJs8A+myqmiL7TA6Q2E45 UBcdVttYX4cIQCbDEl9Liz3qhfKTkU1u0ldDZMffQxI40Olk+i/aB+dSxl1Z7qC6/HNF vVqw== X-Received: by 10.50.91.169 with SMTP id cf9mr4694549igb.44.1359137392749; Fri, 25 Jan 2013 10:09:52 -0800 (PST) Received: from [127.0.0.1] (dsl-173-206-87-33.tor.primus.ca. [173.206.87.33]) by mx.google.com with ESMTPS id bh3sm4225271igc.0.2013.01.25.10.09.51 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Jan 2013 10:09:51 -0800 (PST) Message-ID: <5102CA70.6060700@gmail.com> Date: Fri, 25 Jan 2013 13:09:52 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Ole Troan References: <063.9dc31682f59256171b5d58fdb1cdcc5e@tools.ietf.org> <078.5016b38f0fa45b1e08acdf73cc564147@tools.ietf.org> <510194C3.7010001@gmail.com> <5101CFAC.8040705@gmail.com> <0A42A08D-9515-4266-AD49-63CD42C5A0E9@employees.org> In-Reply-To: <0A42A08D-9515-4266-AD49-63CD42C5A0E9@employees.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130125-0, 25/01/2013), Outbound message X-Antivirus-Status: Clean Cc: "softwires@ietf.org WG" Subject: Re: [Softwires] [softwire] #19: IPv4 address superfluous in MAP-E Interface IDs X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 18:09:54 -0000 We have two choices on this one: a) prohibit the use of an end user IPv6 prefix of length greater than 64 bits; b) simply remove the reference to RFC6052, or qualify it by saying that the IID conforms to Section 2.2 of RFC 6052 except in the case of end user IPv6 prefixes of length greater than 64 bits. Any preferences? On 24/01/2013 7:22 PM, Ole Troan wrote: > Tom, > >> I believe that makes the IID non-conformant to RFC 6052. > > it uses an IID similar to 6052... any better suggestion? > (my personal view is that 6052 got things wrong with the U octet, but that's another matter) > > cheers, > Ole > > From otroan@employees.org Fri Jan 25 10:36:49 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 125B921F84CA for ; Fri, 25 Jan 2013 10:36:49 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gFK023TTRKMr for ; Fri, 25 Jan 2013 10:36:47 -0800 (PST) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 9239021F843D for ; Fri, 25 Jan 2013 10:36:47 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlAJAPrPAlGQ/khN/2dsb2JhbABFvUcEBIEEFnOCHgEBBAF5BQsLRlcGiBwGvmONDoNQYQOmVYJ4gWU X-IronPort-AV: E=Sophos;i="4.84,540,1355097600"; d="scan'208";a="11355113" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-4.cisco.com with ESMTP; 25 Jan 2013 18:36:44 +0000 Received: from dhcp-10-61-104-241.cisco.com (dhcp-10-61-104-241.cisco.com [10.61.104.241]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r0PIaiZE021783 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 25 Jan 2013 18:36:44 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ole Troan In-Reply-To: <5102CA70.6060700@gmail.com> Date: Fri, 25 Jan 2013 19:36:44 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <541F885C-9F86-4C03-9293-A4E959BCCA9A@employees.org> References: <063.9dc31682f59256171b5d58fdb1cdcc5e@tools.ietf.org> <078.5016b38f0fa45b1e08acdf73cc564147@tools.ietf.org> <510194C3.7010001@gmail.com> <5101CFAC.8040705@gmail.com> <0A42A08D-9515-4266-AD49-63CD42C5A0E9@employees.org> <5102CA70.6060700@gmail.com> To: Tom Taylor X-Mailer: Apple Mail (2.1499) Cc: "softwires@ietf.org WG" Subject: Re: [Softwires] [softwire] #19: IPv4 address superfluous in MAP-E Interface IDs X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 18:36:49 -0000 Tom, > We have two choices on this one: >=20 > a) prohibit the use of an end user IPv6 prefix of length greater than = 64 bits; >=20 > b) simply remove the reference to RFC6052, or qualify it by saying = that the IID conforms to Section 2.2 of RFC 6052 except in the case of = end user IPv6 prefixes of length greater than 64 bits. >=20 > Any preferences? RFC6052 permits prefix lengths longer than /64. which isn't at odds with = the current text. MAP of course permits any prefix length, while 6052 is limited to only 6 = sets. the current text do state that the format is "based on", rfc6052, it = does not say it uses the format from rfc6052. nor is 6052 a normative reference. what if we change s/based on/similar = to/ ? is that clearer? cheers, Ole= From tom.taylor.stds@gmail.com Fri Jan 25 11:25:36 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15C9921F85A3 for ; Fri, 25 Jan 2013 11:25:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.994 X-Spam-Level: X-Spam-Status: No, score=-0.994 tagged_above=-999 required=5 tests=[AWL=-1.042, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8n7C1Dl08UNa for ; Fri, 25 Jan 2013 11:25:35 -0800 (PST) Received: from mail-ia0-x234.google.com (ia-in-x0234.1e100.net [IPv6:2607:f8b0:4001:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 3DE9E21F8443 for ; Fri, 25 Jan 2013 11:25:35 -0800 (PST) Received: by mail-ia0-f180.google.com with SMTP id f27so1112986iae.25 for ; Fri, 25 Jan 2013 11:25:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-antivirus:x-antivirus-status; bh=HqyskFApaDJciU88E1A3X9WKuL7XloO5yI1mTMG05kI=; b=hNEqdjVKYu4L9+7SSoVKiO0L3D0pv5iMHMqr/+EYU2mIbw+K5mLV3occIgfPrZe9ss FxTKJunKzWPVOT8xjFuP4V6gG3VTHest3ILBtDnqwQjQc966/x8k+nscClpErKeqS2d7 MIFG3EgvrzKQfl7QDPykM1eYiBXCItHzTAO5slktWZHP3uo3SsnbM8Fp0foOWH83ASab OuZRZ7b/Tx2R4CCu5aOq4UcMo+sG3w4EbNnOR6/3LQtZ/eOpeA6oa7ckJ4b0Bh0/scVB J/1qOJ8zD87/RhjGp6BM5GOuuzGxxUCWxajInvC29kzZjQd43/F/Q9fiNDFprLS25N23 T0Yg== X-Received: by 10.50.187.169 with SMTP id ft9mr4770665igc.25.1359141934846; Fri, 25 Jan 2013 11:25:34 -0800 (PST) Received: from [127.0.0.1] (dsl-173-206-87-33.tor.primus.ca. [173.206.87.33]) by mx.google.com with ESMTPS id fv6sm4330487igc.17.2013.01.25.11.25.33 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Jan 2013 11:25:33 -0800 (PST) Message-ID: <5102DC2F.2090705@gmail.com> Date: Fri, 25 Jan 2013 14:25:35 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Ole Troan References: <063.9dc31682f59256171b5d58fdb1cdcc5e@tools.ietf.org> <078.5016b38f0fa45b1e08acdf73cc564147@tools.ietf.org> <510194C3.7010001@gmail.com> <5101CFAC.8040705@gmail.com> <0A42A08D-9515-4266-AD49-63CD42C5A0E9@employees.org> <5102CA70.6060700@gmail.com> <541F885C-9F86-4C03-9293-A4E959BCCA9A@employees.org> In-Reply-To: <541F885C-9F86-4C03-9293-A4E959BCCA9A@employees.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130125-0, 25/01/2013), Outbound message X-Antivirus-Status: Clean Cc: "softwires@ietf.org WG" Subject: Re: [Softwires] [softwire] #19: IPv4 address superfluous in MAP-E Interface IDs X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 19:25:36 -0000 That should be OK. On 25/01/2013 1:36 PM, Ole Troan wrote: > Tom, > >> We have two choices on this one: >> >> a) prohibit the use of an end user IPv6 prefix of length greater than 64 bits; >> >> b) simply remove the reference to RFC6052, or qualify it by saying that the IID conforms to Section 2.2 of RFC 6052 except in the case of end user IPv6 prefixes of length greater than 64 bits. >> >> Any preferences? > > RFC6052 permits prefix lengths longer than /64. which isn't at odds with the current text. > MAP of course permits any prefix length, while 6052 is limited to only 6 sets. > > the current text do state that the format is "based on", rfc6052, it does not say it uses the format from rfc6052. > nor is 6052 a normative reference. what if we change s/based on/similar to/ ? is that clearer? > > cheers, > Ole > From ssenthil@cisco.com Fri Jan 25 12:13:18 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC43621F87F7 for ; Fri, 25 Jan 2013 12:13:18 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ppgFcMlC+Cdv for ; Fri, 25 Jan 2013 12:13:18 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 007A521F878F for ; Fri, 25 Jan 2013 12:13:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2019; q=dns/txt; s=iport; t=1359144798; x=1360354398; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=39O+mobseuuO0fIBtscuZbjCb3MVy4kwwx9o2E4KVxw=; b=R9aei2S1gEP1zHnEI1O/CC9SRMeoHV/EoKB3RNVZ45qtmCGmhyUVZS5V mcFegzroVPj7RsN6BSlCMwN0JFDl0zi52cJ2DLXvZVl+bb2rNMspv1T2e 2TuSWwfGKaw5SeDHHDgmlaqlYhEF+mCO+nOOVPvelyd/Hb1D37DX9YJXT Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AioGAJHmAlGtJXG//2dsb2JhbABFulqDeRZzgh4BAQEEAQEBawsSAQgYCkUGCyUCBAENBQiHdQMGCQy0awwBiVEEjA2EUWEDiCyMC40MhRKCd4Ik X-IronPort-AV: E=Sophos;i="4.84,540,1355097600"; d="scan'208";a="168266901" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-8.cisco.com with ESMTP; 25 Jan 2013 20:13:17 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r0PKDHvI003643 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Jan 2013 20:13:17 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.248]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Fri, 25 Jan 2013 14:13:17 -0600 From: "Senthil Sivakumar (ssenthil)" To: Satoru Matsushima , Tom Taylor , Ole Troan Thread-Topic: [Softwires] [softwire] #19: IPv4 address superfluous in MAP-E Interface IDs Thread-Index: AQHN+zhpGOBIyhLxnU+H046q7KRS5g== Date: Fri, 25 Jan 2013 20:13:16 +0000 Message-ID: In-Reply-To: <6B276195-A334-4F09-9B9A-DDBAD54221D3@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.117.198.136] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <68F1FF52E99B4042BFBBC674BB069E6A@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org WG" Subject: Re: [Softwires] [softwire] #19: IPv4 address superfluous in MAP-E Interface IDs X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 20:13:19 -0000 On 1/24/13 6:56 PM, "Satoru Matsushima" wrote: >On 2013/01/25, at 5:08, Tom Taylor wrote: > >> This caught my eye too. Why repeat the PSID? >>=20 > >Does anyone have the reason of it must not? I guess the question should be the converse, why should it be duplicated, not why it shouldn=B9t be. I had direct discussions with Ole and other authors a long time ago, but I fail to see the rationale on why it is repeated. > >cheers, >--satoru > > >> On 24/01/2013 11:27 AM, Ole Troan wrote: >>> hi, >>>=20 >>> can we please keep discussion on the list. not via the issue tracker? >>>=20 >>> does anyone else have an opinion? >>> (if I don't hear anything from anyone else, I'll default to keep >>>current text.) >>>=20 >>> cheers, >>> Ole >>>=20 >>> On Jan 24, 2013, at 17:23 , softwire issue tracker >>> wrote: >>>=20 >>>> #19: IPv4 address superfluous in MAP-E Interface IDs >>>>=20 >>>> Changes (by remi.despres@free.fr): >>>>=20 >>>> * priority: trivial =3D> major >>>> * status: closed =3D> reopened >>>> * resolution: wontfix =3D> >>>>=20 >>>>=20 >>>> Comment: >>>>=20 >>>> Value of having the PSID in MAP-E IIDs for maintenance isn't clear at >>>>all: >>>> - PSID length isn't determined in IIDs (there can be an unknown >>>>number of >>>> trailing zeroes) >>>> - all PSID bits are already readable in the first 64 bits >>>>=20 >>>> Suggestion to close the issue: >>>> - keep IPv4 addresses in IIDs (they contains some bits that aren't in >>>>the >>>> first 64 bits) >>>> - don't keep the PSID in IIDs (insufficiently justified complexity) >>>>=20 >> ... >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires > >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires From ssenthil@cisco.com Fri Jan 25 12:14:49 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B14621F8795 for ; Fri, 25 Jan 2013 12:14:49 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mhSCLj8+Crsi for ; Fri, 25 Jan 2013 12:14:49 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 11C0B21F8782 for ; Fri, 25 Jan 2013 12:14:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1144; q=dns/txt; s=iport; t=1359144889; x=1360354489; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=w/hwk1ZlLQPJ+R6d73ZrXMZuWqNJJPYxz540yqJNJ34=; b=BrGEDsTE1tY1uJfND6yw9nXZ46iHMAnShAU7Xkxv5MrOJs/HGXUPU738 WH2NIqIbe107kXrXgYbVRMc+X/e5kCK3yPCRLEHqSuOxbOAAkY/uAlRFz VdlGCcidIKI46213P8BjvLxWPLT3zZ4yFfHcsUfAXOCSU1StQJlQMhUqk Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EACrnAlGtJV2a/2dsb2JhbABFvlMWc4IgAQQBAQE3NAsSAQgOFBQ3CyUCBAENBQiIBwy+SQSNDoNQYQOmVYJ3gWY+ X-IronPort-AV: E=Sophos;i="4.84,540,1355097600"; d="scan'208";a="168308293" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 25 Jan 2013 20:14:48 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r0PKElPL018573 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Jan 2013 20:14:47 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.248]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Fri, 25 Jan 2013 14:14:47 -0600 From: "Senthil Sivakumar (ssenthil)" To: Ole Troan , Tom Taylor Thread-Topic: [Softwires] [softwire] #19: IPv4 address superfluous in MAP-E Interface IDs Thread-Index: AQHN+zif1RR+7xD+fEmYr2BiRgrs8A== Date: Fri, 25 Jan 2013 20:14:46 +0000 Message-ID: In-Reply-To: <541F885C-9F86-4C03-9293-A4E959BCCA9A@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.117.198.136] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org WG" Subject: Re: [Softwires] [softwire] #19: IPv4 address superfluous in MAP-E Interface IDs X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 20:14:49 -0000 Could we make this explicit the prefix lengths can be of any arbitrary length? Or bit boundaries? Or nibble boundaries? Thanks On 1/25/13 1:36 PM, "Ole Troan" wrote: >Tom, > >> We have two choices on this one: >>=20 >> a) prohibit the use of an end user IPv6 prefix of length greater than >>64 bits; >>=20 >> b) simply remove the reference to RFC6052, or qualify it by saying that >>the IID conforms to Section 2.2 of RFC 6052 except in the case of end >>user IPv6 prefixes of length greater than 64 bits. >>=20 >> Any preferences? > >RFC6052 permits prefix lengths longer than /64. which isn't at odds with >the current text. >MAP of course permits any prefix length, while 6052 is limited to only 6 >sets. > >the current text do state that the format is "based on", rfc6052, it does >not say it uses the format from rfc6052. >nor is 6052 a normative reference. what if we change s/based on/similar >to/ ? is that clearer? > >cheers, >Ole >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires From ssenthil@cisco.com Fri Jan 25 12:20:22 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F385E21F8834 for ; Fri, 25 Jan 2013 12:20:21 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JY-n44x0+Uet for ; Fri, 25 Jan 2013 12:20:21 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id D42BC21F8455 for ; Fri, 25 Jan 2013 12:20:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1094; q=dns/txt; s=iport; t=1359145221; x=1360354821; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=0BbxipOFsGHvSAKKnRDlsvKlvGcqW5zZ683OB2XKg7A=; b=DJZVh4Pf0RuqZNlxmTeOREq6Vk8lFgYKyelaR/niwUn9CkMzLm1l7/tc 42mpP/XMbEnHmr2xl0nrz/AZYkFVVlpyNVDACA63klcuBK/wEszqy88JH x3Lbx7xkQM7PoPiE+lt0XU3lP9u8bvg9PmCGLmjOwvWuYXr9G8UJ8W3di g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOvnAlGtJXG8/2dsb2JhbABFvlMWc4IeAQEBBAEBATc0CxIBCBgKFDEGCyUCBAENBQiHdQMPDLRsDYlRBIwNhFFhA5Q3jQyFEoJ3giQ X-IronPort-AV: E=Sophos;i="4.84,540,1355097600"; d="scan'208";a="168272694" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 25 Jan 2013 20:20:20 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r0PKKKK6030745 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Jan 2013 20:20:20 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.248]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Fri, 25 Jan 2013 14:20:19 -0600 From: "Senthil Sivakumar (ssenthil)" To: Tom Taylor , Ole Troan Thread-Topic: [Softwires] [softwire] #19: IPv4 address superfluous in MAP-E Interface IDs Thread-Index: AQHN+ycyKyqmWcFrY02vsI1TxtI7wphajTyA Date: Fri, 25 Jan 2013 20:20:19 +0000 Message-ID: In-Reply-To: <5102CA70.6060700@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.117.198.136] Content-Type: text/plain; charset="us-ascii" Content-ID: <1E7F7A9957FC0749A3E16052C8D5C6CA@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org WG" Subject: Re: [Softwires] [softwire] #19: IPv4 address superfluous in MAP-E Interface IDs X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 20:20:22 -0000 On 1/25/13 1:09 PM, "Tom Taylor" wrote: >We have two choices on this one: > >a) prohibit the use of an end user IPv6 prefix of length greater than 64 >bits; I would think that is restrictive. > >b) simply remove the reference to RFC6052, or qualify it by saying that >the IID conforms to Section 2.2 of RFC 6052 except in the case of end >user IPv6 prefixes of length greater than 64 bits. That would be fine, but it is not clear now in the current draft if we should skip the u bits or overwrite them if the prefix length is greater than 64. Senthil > >Any preferences? > >On 24/01/2013 7:22 PM, Ole Troan wrote: >> Tom, >> >>> I believe that makes the IID non-conformant to RFC 6052. >> >> it uses an IID similar to 6052... any better suggestion? >> (my personal view is that 6052 got things wrong with the U octet, but >>that's another matter) >> >> cheers, >> Ole >> >> >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires From otroan@employees.org Fri Jan 25 12:22:19 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE57D21F87F5 for ; Fri, 25 Jan 2013 12:22:19 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pgRBNYrEGTeD for ; Fri, 25 Jan 2013 12:22:19 -0800 (PST) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 01AA021F8455 for ; Fri, 25 Jan 2013 12:22:18 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,540,1355097600"; d="scan'208";a="11357126" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-4.cisco.com with ESMTP; 25 Jan 2013 20:22:18 +0000 Received: from dhcp-10-61-97-190.cisco.com (dhcp-10-61-97-190.cisco.com [10.61.97.190]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r0PKMHWu016066 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 25 Jan 2013 20:22:17 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ole Troan In-Reply-To: Date: Fri, 25 Jan 2013 21:22:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Senthil Sivakumar (ssenthil)" X-Mailer: Apple Mail (2.1499) Cc: "softwires@ietf.org WG" Subject: Re: [Softwires] [softwire] #19: IPv4 address superfluous in MAP-E Interface IDs X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 20:22:19 -0000 Senthil, > Could we make this explicit the prefix lengths can be of any arbitrary > length? Or bit boundaries? Or nibble boundaries? we could... MAP has to handle whatever the operator decided to delegate = or assign to the end-user. can you propose text? cheers, Ole >=20 > Thanks >=20 > On 1/25/13 1:36 PM, "Ole Troan" wrote: >=20 >> Tom, >>=20 >>> We have two choices on this one: >>>=20 >>> a) prohibit the use of an end user IPv6 prefix of length greater = than >>> 64 bits; >>>=20 >>> b) simply remove the reference to RFC6052, or qualify it by saying = that >>> the IID conforms to Section 2.2 of RFC 6052 except in the case of = end >>> user IPv6 prefixes of length greater than 64 bits. >>>=20 >>> Any preferences? >>=20 >> RFC6052 permits prefix lengths longer than /64. which isn't at odds = with >> the current text. >> MAP of course permits any prefix length, while 6052 is limited to = only 6 >> sets. >>=20 >> the current text do state that the format is "based on", rfc6052, it = does >> not say it uses the format from rfc6052. >> nor is 6052 a normative reference. what if we change s/based = on/similar >> to/ ? is that clearer? >>=20 >> cheers, >> Ole >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires From otroan@employees.org Fri Jan 25 12:23:32 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA2AA21F87F5 for ; Fri, 25 Jan 2013 12:23:32 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7XdpSKqOz0t6 for ; Fri, 25 Jan 2013 12:23:32 -0800 (PST) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id AED9B21F8788 for ; Fri, 25 Jan 2013 12:23:31 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,540,1355097600"; d="scan'208";a="11357138" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-4.cisco.com with ESMTP; 25 Jan 2013 20:23:30 +0000 Received: from dhcp-10-61-97-190.cisco.com (dhcp-10-61-97-190.cisco.com [10.61.97.190]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r0PKNTZY006468 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 25 Jan 2013 20:23:30 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ole Troan In-Reply-To: Date: Fri, 25 Jan 2013 21:23:30 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Senthil Sivakumar (ssenthil)" X-Mailer: Apple Mail (2.1499) Cc: "softwires@ietf.org WG" Subject: Re: [Softwires] [softwire] #19: IPv4 address superfluous in MAP-E Interface IDs X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 20:23:33 -0000 > That would be fine, but it is not clear now in the current draft if we > should skip the u bits > or overwrite them if the prefix length is greater than 64. the current draft says overwrite. rfc6052 implies overwrite (and goes on = to say it is the operator's responsibility to ensure the u-octet is = there). cheers, Ole From ssenthil@cisco.com Fri Jan 25 12:33:30 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F62121F8864 for ; Fri, 25 Jan 2013 12:33:30 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oFEHALWyAy63 for ; Fri, 25 Jan 2013 12:33:29 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC8521F8849 for ; Fri, 25 Jan 2013 12:33:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2134; q=dns/txt; s=iport; t=1359146009; x=1360355609; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=3v2123rEk6fMG4IuuARkcsG11wtQVyUCPU+kn89HC1Q=; b=FSQMcynC04yDNAsE2IeelGXIkEI4FaF8N9vuFit8+lWJblJ9ipsOUJFu ZRUlQp4RrE7fIAUHdpepv5CIojPvD3IXNIoE3xcDeLkt0FROP2Bfp+7hR mq12iNlSy3k09AhG7ZpgHiORzOcwzfubQjZwn9ap7QvRSEseGZluT2IZr k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAITrAlGtJV2Y/2dsb2JhbABFvlMWc4IeAQEBBAEBATc0CxIBCA4KChQ3CyUCBA4FCBGHdgy+TgSNDoNQYQOmVYJ3gWY+ X-IronPort-AV: E=Sophos;i="4.84,540,1355097600"; d="scan'208";a="168309560" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 25 Jan 2013 20:33:14 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r0PKXErH029239 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Jan 2013 20:33:14 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.248]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Fri, 25 Jan 2013 14:33:13 -0600 From: "Senthil Sivakumar (ssenthil)" To: Ole Troan Thread-Topic: [Softwires] [softwire] #19: IPv4 address superfluous in MAP-E Interface IDs Thread-Index: AQHN+zif1RR+7xD+fEmYr2BiRgrs8Jha4XqA//+vOoA= Date: Fri, 25 Jan 2013 20:33:13 +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.2.5.121010 x-originating-ip: [10.117.198.136] Content-Type: text/plain; charset="us-ascii" Content-ID: <0CC9E9DCED700648B5F76672BED6B773@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "softwires@ietf.org WG" Subject: Re: [Softwires] [softwire] #19: IPv4 address superfluous in MAP-E Interface IDs X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 20:33:30 -0000 As an implementor, I would like to see the prefix length to be either in byte boundaries or atleast nibble boundaries. It makes life a little easier. How about this: "The prefix lengths can be of arbitrary length and does not have to be in byte boundaries. The MAP devices SHOULD allow the prefixes of any length less than 96 bits. If the prefix length Is greater than 64 bits, the u bits (bits 64-72) should be overwritten." Note I said "should" be overwritten (or MUST), because a loose terminlogy will allow the wiggle room to interpret it either way, which should be avoided. Thanks Senthil On 1/25/13 3:22 PM, "Ole Troan" wrote: >Senthil, > >> Could we make this explicit the prefix lengths can be of any arbitrary >> length? Or bit boundaries? Or nibble boundaries? > >we could... MAP has to handle whatever the operator decided to delegate >or assign to the end-user. >can you propose text? > >cheers, >Ole > > >>=20 >> Thanks >>=20 >> On 1/25/13 1:36 PM, "Ole Troan" wrote: >>=20 >>> Tom, >>>=20 >>>> We have two choices on this one: >>>>=20 >>>> a) prohibit the use of an end user IPv6 prefix of length greater than >>>> 64 bits; >>>>=20 >>>> b) simply remove the reference to RFC6052, or qualify it by saying >>>>that >>>> the IID conforms to Section 2.2 of RFC 6052 except in the case of end >>>> user IPv6 prefixes of length greater than 64 bits. >>>>=20 >>>> Any preferences? >>>=20 >>> RFC6052 permits prefix lengths longer than /64. which isn't at odds >>>with >>> the current text. >>> MAP of course permits any prefix length, while 6052 is limited to only >>>6 >>> sets. >>>=20 >>> the current text do state that the format is "based on", rfc6052, it >>>does >>> not say it uses the format from rfc6052. >>> nor is 6052 a normative reference. what if we change s/based on/similar >>> to/ ? is that clearer? >>>=20 >>> cheers, >>> Ole >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires > From despres.remi@laposte.net Sat Jan 26 02:50:43 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C23F021F8605 for ; Sat, 26 Jan 2013 02:50:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ee-8bMMTqaiG for ; Sat, 26 Jan 2013 02:50:43 -0800 (PST) Received: from smtp25.services.sfr.fr (smtp25.services.sfr.fr [93.17.128.120]) by ietfa.amsl.com (Postfix) with ESMTP id 1875521F85FC for ; Sat, 26 Jan 2013 02:50:42 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2512.sfr.fr (SMTP Server) with ESMTP id A745370000BE; Sat, 26 Jan 2013 11:50:40 +0100 (CET) Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2512.sfr.fr (SMTP Server) with ESMTP id 3E703700009F; Sat, 26 Jan 2013 11:50:40 +0100 (CET) X-SFR-UUID: 20130126105040255.3E703700009F@msfrf2512.sfr.fr Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Sat, 26 Jan 2013 11:50:40 +0100 Message-Id: References: To: Senthil Sivakumar X-Mailer: Apple Mail (2.1499) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "softwires@ietf.org WG" Subject: Re: [Softwires] [softwire] #19: IPv4 address superfluous in MAP-E Interface IDs X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jan 2013 10:50:43 -0000 Hi, Senthil, 2013-01-25 =E0 21:20, Senthil Sivakumar (ssenthil) = : >=20 >=20 > On 1/25/13 1:09 PM, "Tom Taylor" wrote: >=20 >> We have two choices on this one: >>=20 >> a) prohibit the use of an end user IPv6 prefix of length greater than = 64 >> bits; >=20 > I would think that is restrictive. Why? RFC 4291 says "For all unicast addresses, except those that start with = the binary value 000, Interface IDs are required to be 64 bits long = ...". Doesn't this imply that MAP subnet prefixes always have 64 bits too? RD >=20 >>=20 >> b) simply remove the reference to RFC6052, or qualify it by saying = that >> the IID conforms to Section 2.2 of RFC 6052 except in the case of end >> user IPv6 prefixes of length greater than 64 bits. >=20 > That would be fine, but it is not clear now in the current draft if we > should skip the u bits > or overwrite them if the prefix length is greater than 64. >=20 > Senthil >=20 >>=20 >> Any preferences? >>=20 >> On 24/01/2013 7:22 PM, Ole Troan wrote: >>> Tom, >>>=20 >>>> I believe that makes the IID non-conformant to RFC 6052. >>>=20 >>> it uses an IID similar to 6052... any better suggestion? >>> (my personal view is that 6052 got things wrong with the U octet, = but >>> that's another matter) >>>=20 >>> cheers, >>> Ole >>>=20 >>>=20 >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From tom.taylor.stds@gmail.com Sat Jan 26 18:24:33 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2BCE21F88F5 for ; Sat, 26 Jan 2013 18:24:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.864 X-Spam-Level: X-Spam-Status: No, score=-0.864 tagged_above=-999 required=5 tests=[AWL=-0.912, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2SYKTai+t5dR for ; Sat, 26 Jan 2013 18:24:33 -0800 (PST) Received: from mail-ia0-x229.google.com (mail-ia0-x229.google.com [IPv6:2607:f8b0:4001:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id DF84821F88EF for ; Sat, 26 Jan 2013 18:24:32 -0800 (PST) Received: by mail-ia0-f169.google.com with SMTP id j5so2668738iaf.28 for ; Sat, 26 Jan 2013 18:24:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding:x-antivirus :x-antivirus-status; bh=CqZz/7wUalPG3G0qDOnLvAPyOIzweSCA+HdgH4KIsHg=; b=J2j9p9jAWVDp56POLLfpBuIDEw7gCjT8XWcROAe5sSvsSUEbr9NuEP2KWg2+qXHXbR WYrB3L0QBbbcUNqGbCMckjnGTOYfkDeJA90uEQPOZKLNjd4uDKlyRqkqGq+dMKmXk3d4 GspzooVykEKI9zpd+aVAr/bJjEKRJ4JRFB5Heiwxs4yjB0AP3LhWsNNu3m5iU0PTGven FUbtvUXfV1gBJPYvnL9ATtvt8/ubza4hyLst9PAc65yrzcuAAwrke9+qQVM9WePpRXNH ODy5PXkwyM8IDqWwuzBW9mvUr5BrtaUqrVURZWiVSTJh+g1y36UqQNGGAMN5Aw4WgOwu UkjA== X-Received: by 10.50.135.8 with SMTP id po8mr2102477igb.23.1359253472242; Sat, 26 Jan 2013 18:24:32 -0800 (PST) Received: from [127.0.0.1] (dsl-173-206-87-33.tor.primus.ca. [173.206.87.33]) by mx.google.com with ESMTPS id vq4sm2778989igb.10.2013.01.26.18.24.30 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 26 Jan 2013 18:24:31 -0800 (PST) Message-ID: <51048FE0.8070507@gmail.com> Date: Sat, 26 Jan 2013 21:24:32 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Softwires Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130126-1, 26/01/2013), Outbound message X-Antivirus-Status: Clean Subject: [Softwires] Suggested modifications to Section 4 of draft-ietf-softwire-map-03 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2013 02:24:33 -0000 Here is my suggested change. Most of the text is the same as now, just rearranged. 4. Architecture In accordance with the requirements stated above, the MAP mechanism can operate with shared IPv4 addresses, but also with full IPv4 addresses and IPv4 prefixes. Operation with shared IPv4 addresses is described now, and the differences for full IPv4 addresses and prefixes are described below. The MAP mechanism uses existing standard building blocks. The existing NAPT on the CE is used with additional support for restricting transport protocol ports, ICMP identifiers and fragment identifiers to the configured port set. For packets outbound from the private IPv4 network, the CE NAPT MUST translate transport identifiers (e.g. TCP and UDP port numbers) so that they fall within the CE's assigned port-range. The NAPT MUST in turn be connected to a MAP aware forwarding function, that does encapsulation/ decapsulation of IPv4 packets in IPv6. MAP supports the encapsulation mode specified in [RFC2473]. In addition MAP specifies an algorithm to do "address resolution" from an IPv4 address and port to an IPv6 address. This algorithmic mapping is specified in Section 5. The MAP architecture described here, restricts the use of the shared IPv4 address to only be used as the global address (outside) of the NAPT [RFC2663] running on the CE. A shared IPv4 address MUST NOT be used to identify an interface. While it is theoretically possible to make host stacks and applications port- aware, that is considered too drastic a change to the IP model [RFC6250]. For full IPv4 addresses and IPv4 prefixes, the architecture just described applies with two differences. First, a full IPv4 address or IPv4 prefix can be used as it is today, e.g., for identifying an interface or as a DHCP pool, respectively. Secondly, the NAPT is not required to restrict the ports used on outgoing packets. This architecture is illustrated in Figure 1. User N Private IPv4 | Network | O--+---------------O | | MAP CE | | +-----+--------+ | | NAPT44| MAP | | | +-----+ | |\ ,-------. .------. | +--------+ | \ ,-' `-. ,-' `-. O------------------O / \ O---------O / Public \ / IPv6 only \ | MAP | / IPv4 \ ( Network --+ Border +- Network ) \ (MAP Domain) / | Relay | \ / O------------------O \ / O---------O \ / | MAP CE | /". ,-' `-. ,-' | +-----+--------+ | / `----+--' ------' | NAPT44| MAP | |/ | +-----+ | | | | +--------+ | O---.--------------O | User M Private IPv4 Network Figure 1: Network Topology Just to complete the description of Figure 1: the MAP BR is responsible for connecting external IPv4 networks to the IPv4 nodes in one or more MAP domains. Tom Taylor From tom.taylor.stds@gmail.com Sun Jan 27 07:13:27 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE00021F8634 for ; Sun, 27 Jan 2013 07:13:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.762 X-Spam-Level: X-Spam-Status: No, score=-0.762 tagged_above=-999 required=5 tests=[AWL=-0.810, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qB9M+rI69Qen for ; Sun, 27 Jan 2013 07:13:27 -0800 (PST) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 67C9521F8609 for ; Sun, 27 Jan 2013 07:13:27 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c10so439622ieb.3 for ; Sun, 27 Jan 2013 07:13:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding:x-antivirus :x-antivirus-status; bh=zthY5cuNVYxguB5YCPnOlFmu6c3J9NhQar+3AJHsQyg=; b=da8ssxllffIupuwoUCJJSEQO5fo+A8wxs09RPkqYqrTCSBwk1ptnxadl/zW4ULMNrl APwT3ES4QblabtMxtKJiu3z9TbBKTZhYX2viSDcEnL9Eufj9fZcEk2Ip5stn3Rl2N8TX LG4z6As56ATHNtvfH4u7F5hxSUrj8EyCvX+42T5GIXJWk68B5Vz5FgVFramynVBmOV+W FUs9zuJ4JuosJumdx2G0BQvjvAtywUx/iYRAa1oZLtr853d6jPGc7pb6DRnKy4Z9O5wR aFgxwSWH2z3KtuRgXgcu+N2+3IDyXPM6MIFNc/k08CzqNY+oEA70+goFHhH/YV6mWYfb uLJQ== X-Received: by 10.50.45.168 with SMTP id o8mr124026igm.41.1359299606942; Sun, 27 Jan 2013 07:13:26 -0800 (PST) Received: from [127.0.0.1] (dsl-173-206-87-33.tor.primus.ca. [173.206.87.33]) by mx.google.com with ESMTPS id l8sm4257007igo.13.2013.01.27.07.13.25 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 27 Jan 2013 07:13:25 -0800 (PST) Message-ID: <51054414.2070804@gmail.com> Date: Sun, 27 Jan 2013 10:13:24 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Softwires Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130127-0, 27/01/2013), Outbound message X-Antivirus-Status: Clean Subject: [Softwires] Sharing a Basic Mapping Rule in draft-ietf-softwire-map-03.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2013 15:13:28 -0000 Section 5.2 talks about BMRs being shared amongst CEs. This is only possible with certain restrictions, which should perhaps be enumerated. Fundamentally, anything unique to a specific CE MUST be provisioned separately instead of being part of the BMR. Hence: - In the case of a shared IPv4 address, the PSID MUST be provisioned by other means. - In the case of an IPv4 prefix or full IPv4 address, one could theoretically share BMRs, but the CEs concerned would have distinct IPv4 prefixes which MUST be provisioned by other means, combined with suffixes (in the EA bits) which are common to the sharing CEs. This seems like a peculiar thing to do in practice. It would be simpler just to say that if BMRs relating to IPv4 prefixes or full IPv4 addresses are shared, the EA bits MUST be absent (o = 0). Even simpler: forbid sharing of BMRs for IPv4 prefixes or full IPv4 addresses. BTW: potential global change: instead of "full address", how about "unrestricted address"? Tom Taylor From tom.taylor.stds@gmail.com Sun Jan 27 07:19:46 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3845121F8634 for ; Sun, 27 Jan 2013 07:19:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.681 X-Spam-Level: X-Spam-Status: No, score=-0.681 tagged_above=-999 required=5 tests=[AWL=-0.729, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KDGi9dp2QKMm for ; Sun, 27 Jan 2013 07:19:45 -0800 (PST) Received: from mail-ia0-x234.google.com (mail-ia0-x234.google.com [IPv6:2607:f8b0:4001:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id BAA7721F84E9 for ; Sun, 27 Jan 2013 07:19:45 -0800 (PST) Received: by mail-ia0-f180.google.com with SMTP id f27so2996189iae.39 for ; Sun, 27 Jan 2013 07:19:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding :x-antivirus:x-antivirus-status; bh=hsMObLNVTGMReuhZaHOcSBr6peySbjIB0SFRHDSA4yk=; b=YNCbbfGOC7ggkNjwO7Btw0LSrdZG/hYXQAo2bBikUJmxZgs+c+E1ZG6XwaM6QNDBRj rdf0+EIu+XxFf31wulCvSkWocrNutxnBeqMfy9uLJ/4wxGAcCT78dMJsct/YnzEwk7oF hG2vjls9D6Y49+VsxejxptBqmjZpTqSPk9Ix9+L8zT9d4UPW0uZSMMzMfJR256jNvB+q rKUjhef7bLac1Xwbtf5m/9afQJHb3MfP6jxt69U0IHetxwqTljZ5BDEdKYvh3ltUeK3M ObDdvdhsLRDqG0vvvb4tMlv6o+I7Rx8XBkNAGXRJn9JlBaAkk39WUq8bqskMbbBxEHyv xe1w== X-Received: by 10.50.192.197 with SMTP id hi5mr2898750igc.45.1359299985255; Sun, 27 Jan 2013 07:19:45 -0800 (PST) Received: from [127.0.0.1] (dsl-173-206-87-33.tor.primus.ca. [173.206.87.33]) by mx.google.com with ESMTPS id ww6sm3858654igb.2.2013.01.27.07.19.44 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 27 Jan 2013 07:19:44 -0800 (PST) Message-ID: <5105458F.9050000@gmail.com> Date: Sun, 27 Jan 2013 10:19:43 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Softwires References: <51054414.2070804@gmail.com> In-Reply-To: <51054414.2070804@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130127-0, 27/01/2013), Outbound message X-Antivirus-Status: Clean Subject: [Softwires] PLEASE DISREGARD: Sharing a Basic Mapping Rule in draft-ietf-softwire-map-03.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2013 15:19:46 -0000 Oops. Got mixed up between the Rule IPv6 prefix and the end-user IPv6 prefix. On 27/01/2013 10:13 AM, Tom Taylor wrote: > Section 5.2 talks about BMRs being shared amongst CEs. This is only > possible with certain restrictions, which should perhaps be enumerated. > Fundamentally, anything unique to a specific CE MUST be provisioned > separately instead of being part of the BMR. Hence: > > - In the case of a shared IPv4 address, the PSID MUST be provisioned by > other means. > > - In the case of an IPv4 prefix or full IPv4 address, one could > theoretically share BMRs, but the CEs concerned would have distinct IPv4 > prefixes which MUST be provisioned by other means, combined with > suffixes (in the EA bits) which are common to the sharing CEs. This > seems like a peculiar thing to do in practice. It would be simpler just > to say that if BMRs relating to IPv4 prefixes or full IPv4 addresses are > shared, the EA bits MUST be absent (o = 0). Even simpler: forbid sharing > of BMRs for IPv4 prefixes or full IPv4 addresses. > > BTW: potential global change: instead of "full address", how about > "unrestricted address"? > > Tom Taylor > From tom.taylor.stds@gmail.com Sun Jan 27 08:32:54 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C044721F8678 for ; Sun, 27 Jan 2013 08:32:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.465 X-Spam-Level: X-Spam-Status: No, score=-0.465 tagged_above=-999 required=5 tests=[AWL=-0.813, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, MIME_8BIT_HEADER=0.3, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O+4+JPMR4Idj for ; Sun, 27 Jan 2013 08:32:54 -0800 (PST) Received: from mail-ia0-x234.google.com (ia-in-x0234.1e100.net [IPv6:2607:f8b0:4001:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id C901C21F853E for ; Sun, 27 Jan 2013 08:32:49 -0800 (PST) Received: by mail-ia0-f180.google.com with SMTP id f27so3161134iae.11 for ; Sun, 27 Jan 2013 08:32:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-antivirus:x-antivirus-status; bh=Iixp7yTNLzv5PAwKa4va0PP2fYIVlz3Nfov1ZpT/KRU=; b=OeMPWSjgzLBMUnxHPVVWtT/6q0urFbyyUQ9IcYu7YSNp/NklPnBgrFpFZoJ6KSsJrM Sz/rt5YOqQGseBAazjDgm7Wd6HhieETJXTHepYHT4OLERVe7LRo2b2qWQhkQg3QuT3dD KiqvISdSUAwQqelH5jtCnqz4iZpf0bKf+ZnZkNWhKTzTFJQ2NswG/Ef1znov/RBG927N FRhzzFVsECXfsTzF9T1SsIXNmF/iHJkI58Mv78td9+k/uTYi4XOR0hVo2fIn0dtqRCzM Wq7+lVOoNumopeePpzmhxoDw1IAYAcx5xzzzDu3OjwJgSrJnFi2SUUcqWcOTEpFK1oXt DxQA== X-Received: by 10.50.216.170 with SMTP id or10mr3111458igc.44.1359304369301; Sun, 27 Jan 2013 08:32:49 -0800 (PST) Received: from [127.0.0.1] (dsl-173-206-87-33.tor.primus.ca. [173.206.87.33]) by mx.google.com with ESMTPS id eo7sm4407136igc.12.2013.01.27.08.32.47 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 27 Jan 2013 08:32:48 -0800 (PST) Message-ID: <510556AE.2070701@gmail.com> Date: Sun, 27 Jan 2013 11:32:46 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 130127-0, 27/01/2013), Outbound message X-Antivirus-Status: Clean Cc: "softwires@ietf.org WG" Subject: Re: [Softwires] [softwire] #19: IPv4 address superfluous in MAP-E Interface IDs X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2013 16:32:54 -0000 Rmi has a point. RFC 4291 doesn't seem to leave wiggle room. Section 2.5.1 says: For all unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format. However, the modified EUI-64 requirement is negotiable. Appendix A of RFC 4291 says: Links without Identifiers There are a number of links that do not have any type of built-in identifier. The most common of these are serial links and configured tunnels. Interface identifiers that are unique within a subnet prefix must be chosen. The MAP case is an example of "configured tunnels", I'd say. So there is no requirement on the specific contents of the last 64 bits except that the u bit has to be zero, since the IID isn't guaranteed to be universally unique. This leaves the requirement that the IID be 64 bits long. I can't see how to get around this one without going to 6man and asking for a change. Just a further thought: requiring that the first subnet (the all-zeroes subnet) be reserved for MAP doesn't mean much if the prefix doesn't contain a subnet field. Does this provision have to change if the prefix reaches 64 bits in length? Arithmetic example of what I would consider reasonable: - /56 assigned to the subscriber - sharing ratio = 64, implying 6 bits for the PSID field - BMR shared only between CEs sharing the same IPv4 address, hence no address bits needed in the EA bits field => 6 EA bits, Rule IPv6 prefix is a /50. Here's an alternative example (assuming we can say something sensible about what gets reserved if there is no subnet ID field): - /64 assigned to the subscriber - same assumptions as above on sharing => Rule IPv6 prefix is a /58 Tom Taylor On 26/01/2013 5:50 AM, Rmi Desprs wrote: > Hi, Senthil, > > 2013-01-25 21:20, Senthil Sivakumar (ssenthil) : > >> >> >> On 1/25/13 1:09 PM, "Tom Taylor" wrote: >> >>> We have two choices on this one: >>> >>> a) prohibit the use of an end user IPv6 prefix of length greater than 64 >>> bits; >> >> I would think that is restrictive. > > Why? > RFC 4291 says "For all unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long ...". > Doesn't this imply that MAP subnet prefixes always have 64 bits too? > > RD > > >> >>> >>> b) simply remove the reference to RFC6052, or qualify it by saying that >>> the IID conforms to Section 2.2 of RFC 6052 except in the case of end >>> user IPv6 prefixes of length greater than 64 bits. >> >> That would be fine, but it is not clear now in the current draft if we >> should skip the u bits >> or overwrite them if the prefix length is greater than 64. >> >> Senthil >> >>> >>> Any preferences? >>> >>> On 24/01/2013 7:22 PM, Ole Troan wrote: >>>> Tom, >>>> >>>>> I believe that makes the IID non-conformant to RFC 6052. >>>> >>>> it uses an IID similar to 6052... any better suggestion? >>>> (my personal view is that 6052 got things wrong with the U octet, but >>>> that's another matter) >>>> >>>> cheers, >>>> Ole >>>> >>>> >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >> >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires > From tom.taylor.stds@gmail.com Sun Jan 27 12:39:56 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E13B521F85BB for ; Sun, 27 Jan 2013 12:39:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.547 X-Spam-Level: X-Spam-Status: No, score=-0.547 tagged_above=-999 required=5 tests=[AWL=-0.595, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7mEcb-0vtG6q for ; Sun, 27 Jan 2013 12:39:56 -0800 (PST) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 629CF21F8455 for ; Sun, 27 Jan 2013 12:39:56 -0800 (PST) Received: by mail-ie0-f176.google.com with SMTP id 13so654556iea.21 for ; Sun, 27 Jan 2013 12:39:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding:x-antivirus :x-antivirus-status; bh=Vqj13zqNfAM272mNUMKzhYFSmBDScbuJGrxvPLX5xN0=; b=mrNrKtGXx1r8UjjMt7E2rVJ06OE9IMtXL71tIFHBWoXBPWCEntt+wG89nyP+laB76w SGRrYoa+8Nhxf2Kq530j2WmeRyF2K/+CyBmLTPhdX1j2t4clzMmVCkK/7hhmwZexgYQL uvYADLvnVj99GuP9D5fhq2mP7mpzW7mJA+i/pUahfshIeCXCCBVjhPzv/wh4yhF6kTEr ubUkkZsa+jswX8kWQIaw05jSSB0HXW+2Q0vCa8U7sIk2GmfdhiJef3MSol+KN8W7Jc6V +m5ymX6K8y8HbeDZBRR4YxnAXwgkZbeNs/0mnNJ6exOyFuPudCvU5f5bojycV15Lq9Cn Jqsw== X-Received: by 10.50.237.103 with SMTP id vb7mr3570811igc.29.1359319195882; Sun, 27 Jan 2013 12:39:55 -0800 (PST) Received: from [127.0.0.1] (dsl-173-206-87-33.tor.primus.ca. [173.206.87.33]) by mx.google.com with ESMTPS id nj1sm4921513igc.3.2013.01.27.12.39.54 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 27 Jan 2013 12:39:55 -0800 (PST) Message-ID: <51059099.5080906@gmail.com> Date: Sun, 27 Jan 2013 15:39:53 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Softwires Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130127-0, 27/01/2013), Outbound message X-Antivirus-Status: Clean Subject: [Softwires] Required knowledge of destination port set in MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2013 20:39:57 -0000 I suppose it's the same as for any NAT situation, a node trying to send packets to another in a MAP domain has to know in advance what port to send to. Otherwise (for shared addresses), the packet is likely to be routed to the wrong CE. Should the examples mention that the port (e.g., port 9030 in example 2) is known in advance to be one that will reach the desired endpoint? Is there anything special about MAP compared with the general NAT situation that makes it easier or harder for senders to learn what ports they can send to? Tom Taylor From tom.taylor.stds@gmail.com Sun Jan 27 14:07:52 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A05CB21F866E for ; Sun, 27 Jan 2013 14:07:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.502 X-Spam-Level: X-Spam-Status: No, score=-0.502 tagged_above=-999 required=5 tests=[AWL=-0.550, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yKenxW4kjQsc for ; Sun, 27 Jan 2013 14:07:52 -0800 (PST) Received: from mail-ia0-x234.google.com (ia-in-x0234.1e100.net [IPv6:2607:f8b0:4001:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 277B921F87BA for ; Sun, 27 Jan 2013 14:07:52 -0800 (PST) Received: by mail-ia0-f180.google.com with SMTP id f27so3291421iae.39 for ; Sun, 27 Jan 2013 14:07:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding:x-antivirus :x-antivirus-status; bh=SF8m7La5jAwEo+CAg+BGmoy9tA6fSxvJi30EQacoDmw=; b=PO70A9/LjtPCAkXIrKy240FvOGwR5YhreTeGZCbLoyd4F/aCvsAbWBJu8sewEiMSOQ Zf9+E7H+N6pKClLLjhq/XnbiR9UC2TZouOn7XPyQJiw2GrjWCxOw80Odlq/0ldb/9dve AC/d0SIQ5hM6N2KRrEsRc+NHxuHIZEuGk2RWHGg6b8Jg4tZ6uMAqYG2XviVl/DS4NFAy ksFYInZeB/EWC22pMl8GsDcghJmDtlnBmeYThfn4XPr9eieqXY8rFiByE+jq3YdgADDS MNNY0QPJfKqUKwaDZa1r7F2XPbD6/JPoJTawmvlv6Os7VEcQEy4vGyTBrc3SRuM6zCWb DgPQ== X-Received: by 10.50.1.201 with SMTP id 9mr3561093igo.80.1359324471604; Sun, 27 Jan 2013 14:07:51 -0800 (PST) Received: from [127.0.0.1] (dsl-173-206-87-33.tor.primus.ca. [173.206.87.33]) by mx.google.com with ESMTPS id ke8sm1515934igc.17.2013.01.27.14.07.50 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 27 Jan 2013 14:07:50 -0800 (PST) Message-ID: <5105A534.3080201@gmail.com> Date: Sun, 27 Jan 2013 17:07:48 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Softwires Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130127-0, 27/01/2013), Outbound message X-Antivirus-Status: Clean Subject: [Softwires] Limiting the length of the MAP endpoint IPv6 prefix X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2013 22:07:52 -0000 The examples in my previous note sort of provided backing for my view that the MAP endpoint IPv6 prefix can be limited to a maximum of a /64, thus making the IID fully conformant both to RFC 4291 and to RFC 6052. Obviously, the more IPv4 address bits you can stick into the EA bits, the fewer the number of MAP rules you have to provision. The picture of a MAP endpoint IPv6 prefix can be drawn like this: +-----------------------------+-------------------+-----------+ | Rule IPv6 prefix | IPv4 suffix | PSID | +-----------------------------+-------------------+-----------+ | | | | | Common to all CEs sharing | Common to all CEs | Unique to | | the same BMR | sharing the same | this CE | | | IPv4 address | | If we expect a Rule IPv6 prefix to be a /48 and a PSID to be no more than 8 bits in length (i.e. CEs get 512 ports each, sharing ratio is 128), limiting the endpoint IPv6 prefix to 64 bits leaves room for eight bits of suffix. That in turn means each mapping rule serves 16384 CEs. If the Rule IPv6 prefix backs off to a /40, we can get two million CEs per mapping rule. I think limiting the prefix length to 64 bits is reasonable. Comments? Tom Taylor From despres.remi@laposte.net Mon Jan 28 00:40:06 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2289D21F8423 for ; Mon, 28 Jan 2013 00:40:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HTLMeZJmseDu for ; Mon, 28 Jan 2013 00:40:04 -0800 (PST) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.13]) by ietfa.amsl.com (Postfix) with ESMTP id 3E1D121F841F for ; Mon, 28 Jan 2013 00:40:03 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2217.sfr.fr (SMTP Server) with ESMTP id 6B18C70036BB; Mon, 28 Jan 2013 09:40:02 +0100 (CET) Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2217.sfr.fr (SMTP Server) with ESMTP id 145237000052; Mon, 28 Jan 2013 09:40:02 +0100 (CET) X-SFR-UUID: 20130128084002833.145237000052@msfrf2217.sfr.fr Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= In-Reply-To: <510556AE.2070701@gmail.com> Date: Mon, 28 Jan 2013 09:40:02 +0100 Message-Id: References: <510556AE.2070701@gmail.com> To: Tom Taylor , "softwires@ietf.org WG" X-Mailer: Apple Mail (2.1499) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Softwires] [softwire] #19: IPv4 address superfluous in MAP-E Interface IDs X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 08:40:06 -0000 2013-01-27 17:32, Tom Taylor : > R=E9mi has a point. RFC 4291 doesn't seem to leave wiggle room. = Section 2.5.1 says: >=20 > For all unicast addresses, except those that start with the binary > value 000, Interface IDs are required to be 64 bits long and to be > constructed in Modified EUI-64 format. This sentence, because it applies to ALL unicast addresses that don't = start with 000, does apply to MAP addresses. Suggestion: delete any reference to subnet IDs longer than /64.=20 AFAIK, that's enough. Regards, RD =20 >=20 > However, the modified EUI-64 requirement is negotiable. Appendix A of = RFC 4291 says: >=20 > Links without Identifiers >=20 > There are a number of links that do not have any type of built-in > identifier. The most common of these are serial links and = configured > tunnels. Interface identifiers that are unique within a subnet > prefix must be chosen. >=20 > The MAP case is an example of "configured tunnels", I'd say. So there = is no requirement on the specific contents of the last 64 bits except = that the u bit has to be zero, since the IID isn't guaranteed to be = universally unique. >=20 > This leaves the requirement that the IID be 64 bits long. I can't see = how to get around this one without going to 6man and asking for a = change. >=20 > Just a further thought: requiring that the first subnet (the = all-zeroes subnet) be reserved for MAP doesn't mean much if the prefix = doesn't contain a subnet field. Does this provision have to change if = the prefix reaches 64 bits in length? >=20 > Arithmetic example of what I would consider reasonable: > - /56 assigned to the subscriber > - sharing ratio =3D 64, implying 6 bits for the PSID field > - BMR shared only between CEs sharing the same IPv4 address, hence no = address bits needed in the EA bits field > =3D> 6 EA bits, Rule IPv6 prefix is a /50. >=20 > Here's an alternative example (assuming we can say something sensible = about what gets reserved if there is no subnet ID field): > - /64 assigned to the subscriber > - same assumptions as above on sharing > =3D> Rule IPv6 prefix is a /58 >=20 > Tom Taylor >=20 >=20 > On 26/01/2013 5:50 AM, R=E9mi Despr=E9s wrote: >> Hi, Senthil, >>=20 >> 2013-01-25 =E0 21:20, Senthil Sivakumar (ssenthil) = : >>=20 >>>=20 >>>=20 >>> On 1/25/13 1:09 PM, "Tom Taylor" wrote: >>>=20 >>>> We have two choices on this one: >>>>=20 >>>> a) prohibit the use of an end user IPv6 prefix of length greater = than 64 >>>> bits; >>>=20 >>> I would think that is restrictive. >>=20 >> Why? >> RFC 4291 says "For all unicast addresses, except those that start = with the binary value 000, Interface IDs are required to be 64 bits long = ...". >> Doesn't this imply that MAP subnet prefixes always have 64 bits too? >>=20 >> RD >>=20 >>=20 >>>=20 >>>>=20 >>>> b) simply remove the reference to RFC6052, or qualify it by saying = that >>>> the IID conforms to Section 2.2 of RFC 6052 except in the case of = end >>>> user IPv6 prefixes of length greater than 64 bits. >>>=20 >>> That would be fine, but it is not clear now in the current draft if = we >>> should skip the u bits >>> or overwrite them if the prefix length is greater than 64. >>>=20 >>> Senthil >>>=20 >>>>=20 >>>> Any preferences? >>>>=20 >>>> On 24/01/2013 7:22 PM, Ole Troan wrote: >>>>> Tom, >>>>>=20 >>>>>> I believe that makes the IID non-conformant to RFC 6052. >>>>>=20 >>>>> it uses an IID similar to 6052... any better suggestion? >>>>> (my personal view is that 6052 got things wrong with the U octet, = but >>>>> that's another matter) >>>>>=20 >>>>> cheers, >>>>> Ole >>>>>=20 >>>>>=20 >>>> _______________________________________________ >>>> Softwires mailing list >>>> Softwires@ietf.org >>>> https://www.ietf.org/mailman/listinfo/softwires >>>=20 >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >>=20 From despres.remi@laposte.net Mon Jan 28 00:43:04 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4077021F8430 for ; Mon, 28 Jan 2013 00:43:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iXBVBPIos+7L for ; Mon, 28 Jan 2013 00:43:03 -0800 (PST) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.13]) by ietfa.amsl.com (Postfix) with ESMTP id 9FF6721F8585 for ; Mon, 28 Jan 2013 00:43:03 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2217.sfr.fr (SMTP Server) with ESMTP id 0ACBC700026C; Mon, 28 Jan 2013 09:43:03 +0100 (CET) Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2217.sfr.fr (SMTP Server) with ESMTP id E0B69700004E; Mon, 28 Jan 2013 09:43:02 +0100 (CET) X-SFR-UUID: 20130128084302920.E0B69700004E@msfrf2217.sfr.fr Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= In-Reply-To: <5105A534.3080201@gmail.com> Date: Mon, 28 Jan 2013 09:43:03 +0100 Message-Id: References: <5105A534.3080201@gmail.com> To: Tom Taylor X-Mailer: Apple Mail (2.1499) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Softwires Subject: Re: [Softwires] Limiting the length of the MAP endpoint IPv6 prefix X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 08:43:04 -0000 Le 2013-01-27 =E0 23:07, Tom Taylor a =E9crit = : > The examples in my previous note sort of provided backing for my view = that the MAP endpoint IPv6 prefix can be limited to a maximum of a /64, = thus making the IID fully conformant both to RFC 4291 and to RFC 6052. >=20 > Obviously, the more IPv4 address bits you can stick into the EA bits, = the fewer the number of MAP rules you have to provision. The picture of = a MAP endpoint IPv6 prefix can be drawn like this: >=20 >=20 > +-----------------------------+-------------------+-----------+ > | Rule IPv6 prefix | IPv4 suffix | PSID | > +-----------------------------+-------------------+-----------+ > | | | | > | Common to all CEs sharing | Common to all CEs | Unique to | > | the same BMR | sharing the same | this CE | > | | IPv4 address | | >=20 >=20 > If we expect a Rule IPv6 prefix to be a /48 and a PSID to be no more = than 8 bits in length (i.e. CEs get 512 ports each, sharing ratio is = 128), limiting the endpoint IPv6 prefix to 64 bits leaves room for eight = bits of suffix. That in turn means each mapping rule serves 16384 CEs. = If the Rule IPv6 prefix backs off to a /40, we can get two million CEs = per mapping rule. > I think limiting the prefix length to 64 bits is reasonable. Comments? +1 RD >=20 > Tom Taylor > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From otroan@employees.org Mon Jan 28 01:16:30 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF3D021F8414 for ; Mon, 28 Jan 2013 01:16:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5oiyHIlv0LQv for ; Mon, 28 Jan 2013 01:16:29 -0800 (PST) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 7805721F8230 for ; Mon, 28 Jan 2013 01:16:26 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,550,1355097600"; d="scan'208";a="11396132" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-4.cisco.com with ESMTP; 28 Jan 2013 09:16:25 +0000 Received: from dhcp-lys02-vla252-10-147-116-52.cisco.com (dhcp-lys02-vla252-10-147-116-52.cisco.com [10.147.116.52]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r0S9GPOs012977 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 28 Jan 2013 09:16:25 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ole Troan In-Reply-To: Date: Mon, 28 Jan 2013 10:16:24 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7E767618-52CB-4625-8BCC-E9D430A0AB32@employees.org> References: <510556AE.2070701@gmail.com> To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1499) Cc: "softwires@ietf.org WG" Subject: Re: [Softwires] [softwire] #19: IPv4 address superfluous in MAP-E Interface IDs X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 09:16:30 -0000 Remi, Tom, >> R=E9mi has a point. RFC 4291 doesn't seem to leave wiggle room. = Section 2.5.1 says: >>=20 >> For all unicast addresses, except those that start with the binary >> value 000, Interface IDs are required to be 64 bits long and to be >> constructed in Modified EUI-64 format. >=20 > This sentence, because it applies to ALL unicast addresses that don't = start with 000, does apply to MAP addresses. >=20 > Suggestion: delete any reference to subnet IDs longer than /64.=20 > AFAIK, that's enough. the choice of prefix length for the End-user IPv6 prefix is an = operator's choice, and not something we should limit in specification. for the purpose of MAP it could very well be a /128 for that matter. cheers, Ole= From otroan@employees.org Mon Jan 28 01:21:33 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A972021F8549 for ; Mon, 28 Jan 2013 01:21:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.587 X-Spam-Level: X-Spam-Status: No, score=-10.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nj6IS0ZUVjZW for ; Mon, 28 Jan 2013 01:21:30 -0800 (PST) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id BD2D221F8545 for ; Mon, 28 Jan 2013 01:21:24 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAKlCBlGQ/khN/2dsb2JhbABFvlsWc4IeAQEEATo/BQsLRlcGiB4Gvx+QRGEDplWCeA X-IronPort-AV: E=Sophos;i="4.84,550,1355097600"; d="scan'208";a="11396291" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-4.cisco.com with ESMTP; 28 Jan 2013 09:21:23 +0000 Received: from dhcp-lys02-vla252-10-147-116-52.cisco.com (dhcp-lys02-vla252-10-147-116-52.cisco.com [10.147.116.52]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r0S9LNB2006267 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 28 Jan 2013 09:21:23 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ole Troan In-Reply-To: <51059099.5080906@gmail.com> Date: Mon, 28 Jan 2013 10:21:23 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51059099.5080906@gmail.com> To: Tom Taylor X-Mailer: Apple Mail (2.1499) Cc: Softwires Subject: Re: [Softwires] Required knowledge of destination port set in MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 09:21:33 -0000 Tom, > I suppose it's the same as for any NAT situation, a node trying to = send packets to another in a MAP domain has to know in advance what port = to send to. Otherwise (for shared addresses), the packet is likely to be = routed to the wrong CE. Should the examples mention that the port (e.g., = port 9030 in example 2) is known in advance to be one that will reach = the desired endpoint? >=20 > Is there anything special about MAP compared with the general NAT = situation that makes it easier or harder for senders to learn what ports = they can send to? no, not as far as I can see. any end to end communication using TCP or UDP requires the initiator of = the communication to know which port to connect to. cheers, Ole= From despres.remi@laposte.net Mon Jan 28 01:26:17 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE6DA21F854E for ; Mon, 28 Jan 2013 01:26:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nHURi7Myd0PQ for ; Mon, 28 Jan 2013 01:26:17 -0800 (PST) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.13]) by ietfa.amsl.com (Postfix) with ESMTP id A5C2D21F854A for ; Mon, 28 Jan 2013 01:26:12 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2217.sfr.fr (SMTP Server) with ESMTP id 0E6E270036C1; Mon, 28 Jan 2013 10:26:12 +0100 (CET) Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2217.sfr.fr (SMTP Server) with ESMTP id E2B257000263; Mon, 28 Jan 2013 10:26:11 +0100 (CET) X-SFR-UUID: 20130128092611928.E2B257000263@msfrf2217.sfr.fr Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= In-Reply-To: <7E767618-52CB-4625-8BCC-E9D430A0AB32@employees.org> Date: Mon, 28 Jan 2013 10:26:12 +0100 Message-Id: <5F40ECF3-6C6D-46B4-AAC5-44128DF07F95@laposte.net> References: <510556AE.2070701@gmail.com> <7E767618-52CB-4625-8BCC-E9D430A0AB32@employees.org> To: Ole Troan X-Mailer: Apple Mail (2.1499) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "softwires@ietf.org WG" Subject: Re: [Softwires] [softwire] #19: IPv4 address superfluous in MAP-E Interface IDs X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 09:26:17 -0000 Le 2013-01-28 =E0 10:16, Ole Troan a =E9crit : > Remi, Tom, >=20 >>> R=E9mi has a point. RFC 4291 doesn't seem to leave wiggle room. = Section 2.5.1 says: >>>=20 (*) >>> For all unicast addresses, except those that start with the binary >>> value 000, Interface IDs are required to be 64 bits long and to be >>> constructed in Modified EUI-64 format. >>=20 >> This sentence, because it applies to ALL unicast addresses that don't = start with 000, does apply to MAP addresses. >>=20 >> Suggestion: delete any reference to subnet IDs longer than /64.=20 >> AFAIK, that's enough. >=20 > the choice of prefix length for the End-user IPv6 prefix is an = operator's choice, OK > and not something we should limit in specification. > for the purpose of MAP it could very well be a /128 for that matter. Different understanding of (*). RD >=20 > cheers, > Ole From otroan@employees.org Mon Jan 28 01:26:18 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E80A721F8573 for ; Mon, 28 Jan 2013 01:26:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.588 X-Spam-Level: X-Spam-Status: No, score=-10.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uz4wBauMGhSo for ; Mon, 28 Jan 2013 01:26:18 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 1855021F854E for ; Mon, 28 Jan 2013 01:26:17 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAPdCBlGQ/khL/2dsb2JhbABFvlsWc4IeAQEEATo/BQsLRlcGiB4Gvx+NCQuDMGEDplWCeIFl X-IronPort-AV: E=Sophos;i="4.84,550,1355097600"; d="scan'208";a="80046928" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 28 Jan 2013 09:26:16 +0000 Received: from dhcp-lys02-vla252-10-147-116-52.cisco.com (dhcp-lys02-vla252-10-147-116-52.cisco.com [10.147.116.52]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r0S9QGsM009293 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 28 Jan 2013 09:26:16 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ole Troan In-Reply-To: <5105A534.3080201@gmail.com> Date: Mon, 28 Jan 2013 10:26:16 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <563B6CD4-5F39-4392-A05D-A7E92F2670A1@employees.org> References: <5105A534.3080201@gmail.com> To: Tom Taylor X-Mailer: Apple Mail (2.1499) Cc: Softwires Subject: Re: [Softwires] Limiting the length of the MAP endpoint IPv6 prefix X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 09:26:19 -0000 Tom, > The examples in my previous note sort of provided backing for my view = that the MAP endpoint IPv6 prefix can be limited to a maximum of a /64, = thus making the IID fully conformant both to RFC 4291 and to RFC 6052. >=20 > Obviously, the more IPv4 address bits you can stick into the EA bits, = the fewer the number of MAP rules you have to provision. The picture of = a MAP endpoint IPv6 prefix can be drawn like this: >=20 >=20 > +-----------------------------+-------------------+-----------+ > | Rule IPv6 prefix | IPv4 suffix | PSID | > +-----------------------------+-------------------+-----------+ > | | | | > | Common to all CEs sharing | Common to all CEs | Unique to | > | the same BMR | sharing the same | this CE | > | | IPv4 address | | >=20 >=20 > If we expect a Rule IPv6 prefix to be a /48 and a PSID to be no more = than 8 bits in length (i.e. CEs get 512 ports each, sharing ratio is = 128), limiting the endpoint IPv6 prefix to 64 bits leaves room for eight = bits of suffix. That in turn means each mapping rule serves 16384 CEs. = If the Rule IPv6 prefix backs off to a /40, we can get two million CEs = per mapping rule. >=20 > I think limiting the prefix length to 64 bits is reasonable. Comments? I don't think that's reasonable. and I don't see what it buys us, given that supporting prefix lengths = longer than 64 is simple. IPv6 isn't classfull, there isn't anything magic with the 64 boundary. = ;-) cheers, Ole= From tom.taylor.stds@gmail.com Mon Jan 28 05:49:55 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C237121F862A for ; Mon, 28 Jan 2013 05:49:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.462 X-Spam-Level: X-Spam-Status: No, score=-0.462 tagged_above=-999 required=5 tests=[AWL=-0.510, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hBp+-50lDegq for ; Mon, 28 Jan 2013 05:49:55 -0800 (PST) Received: from mail-ia0-x231.google.com (ia-in-x0231.1e100.net [IPv6:2607:f8b0:4001:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 4C7BF21F862B for ; Mon, 28 Jan 2013 05:49:55 -0800 (PST) Received: by mail-ia0-f177.google.com with SMTP id h8so4235477iaa.36 for ; Mon, 28 Jan 2013 05:49:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-antivirus:x-antivirus-status; bh=A+IiCK5OVHSOIf9BAoDbsZn7qffjVT8+SYtV090V5WQ=; b=Y9zgJvJjucmCFExRhzyGfabGrJtn1RndIRsZNptepBO53xp6zUglypKptB6xB7gtw8 +PBhGsBsRa+E5OLecf9FeI4n+ToyK/8wf34nq9PAgHcTiTT5GAKRg0ErU1mjPYjrAuCC bSFhQYhkEM4JtO8TAF9m7EEtpWhoDBvEOI5a4Wpmi0uIxNgKlOEJs1iQj+ZiEYibxbE/ JkvZTlAjedRdidmhHJ6Al7VK/KntXdQDVajvp4tLIGzw2e+8/dDzFk3mt8gw9PbIqIxM f7zM4Xg5XD5DKlZCaT50JD7QoCMFOz4RYu7ZKBLGRmBGslSeQjYZm76ihL37ZgBuABM+ jaLw== X-Received: by 10.50.91.230 with SMTP id ch6mr5096633igb.92.1359380994724; Mon, 28 Jan 2013 05:49:54 -0800 (PST) Received: from [127.0.0.1] (dsl-173-206-87-33.tor.primus.ca. [173.206.87.33]) by mx.google.com with ESMTPS id s3sm6723621igb.14.2013.01.28.05.49.52 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Jan 2013 05:49:53 -0800 (PST) Message-ID: <51068200.8050509@gmail.com> Date: Mon, 28 Jan 2013 08:49:52 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Ole Troan References: <5105A534.3080201@gmail.com> <563B6CD4-5F39-4392-A05D-A7E92F2670A1@employees.org> In-Reply-To: <563B6CD4-5F39-4392-A05D-A7E92F2670A1@employees.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 130128-0, 28/01/2013), Outbound message X-Antivirus-Status: Clean Cc: Softwires Subject: Re: [Softwires] Limiting the length of the MAP endpoint IPv6 prefix X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 13:49:55 -0000 On 28/01/2013 4:26 AM, Ole Troan wrote: > Tom, > >> The examples in my previous note sort of provided backing for my view that the MAP endpoint IPv6 prefix can be limited to a maximum of a /64, thus making the IID fully conformant both to RFC 4291 and to RFC 6052. >> ... >> >> I think limiting the prefix length to 64 bits is reasonable. Comments? > > I don't think that's reasonable. > and I don't see what it buys us, given that supporting prefix lengths longer than 64 is simple. > IPv6 isn't classfull, there isn't anything magic with the 64 boundary. ;-) > > cheers, > Ole > OK, then I agree with Rmi. Drop mention of prefixes greater than 64 bits long and leave it to the reader to judge whether RFC 4291 imposes a limit. Tom From wdec.ietf@gmail.com Mon Jan 28 05:51:15 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 969F921F862B for ; Mon, 28 Jan 2013 05:51:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y51u5wPHjy5a for ; Mon, 28 Jan 2013 05:51:11 -0800 (PST) Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) by ietfa.amsl.com (Postfix) with ESMTP id 4939221F89CE for ; Mon, 28 Jan 2013 05:51:11 -0800 (PST) Received: by mail-qa0-f49.google.com with SMTP id o13so713688qaj.8 for ; Mon, 28 Jan 2013 05:51:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=uHT6Crg2/a7BuHmp3F28MfrT4oSIfBG0E3/vLuB0o40=; b=DEMuTTvkwzvfHAQxKmx1laWmx4W+6lN4lv1/hCXt+rRjBHEdQnDTDaTMVn1eUadp4X 8PvWjtRyePfsjJZGBNbyLwmFmWJR3rF0iV0Q4EfpbeQJBmbdfABgLZYAR/gKGvqGF1rL bviOoQWHC7rfhYPFf2dhcVHGc+jSHWQVheq/fwMhJQW9h7WzNJ0lSk2m3A2UvpCmQaEY +eJpMriGFvNOLGhUCBh6e8mME+D12r2o/059ctbvHavxjRa1S6mYc/aKYbHvQ0ngvNGY 2iFD88Ax8rlDVyoyTvJWpfz437G4AxpQZZ093XHMG09Wrg8UuFiyw2NsP6QaRwPbiqMw nnsQ== MIME-Version: 1.0 X-Received: by 10.229.76.35 with SMTP id a35mr3846792qck.13.1359381070676; Mon, 28 Jan 2013 05:51:10 -0800 (PST) Received: by 10.49.75.33 with HTTP; Mon, 28 Jan 2013 05:51:10 -0800 (PST) In-Reply-To: References: <063.9dc31682f59256171b5d58fdb1cdcc5e@tools.ietf.org> <078.5016b38f0fa45b1e08acdf73cc564147@tools.ietf.org> Date: Mon, 28 Jan 2013 13:51:10 +0000 Message-ID: From: Wojciech Dec To: Ole Troan Content-Type: multipart/alternative; boundary=002354188208d5036204d4599182 Cc: "softwires@ietf.org WG" , remi.despres@free.fr Subject: Re: [Softwires] [softwire] #19: IPv4 address superfluous in MAP-E Interface IDs X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 13:51:15 -0000 --002354188208d5036204d4599182 Content-Type: text/plain; charset=ISO-8859-1 Hi, the IPv4 and PSID in the IID are particularly useful in cases of address independence (ie 1:1). As said previously, the benefit is primarily in the ability an operational facilitation, where an operator can easily see/observe what IPv4 and PSID is being used by a given customer. This is easier than to look at the v6 prefix and use some magic decoder ring. In addition, it has the desirable characteristic of creating an IID. +1 Thus to keeping the IPv4 and PSID, likely in a fixed length (16 bit) field format. Regards, Woj. On 24 January 2013 16:27, Ole Troan wrote: > hi, > > can we please keep discussion on the list. not via the issue tracker? > > does anyone else have an opinion? > (if I don't hear anything from anyone else, I'll default to keep current > text.) > > cheers, > Ole > > On Jan 24, 2013, at 17:23 , softwire issue tracker < > trac+softwire@tools.ietf.org> wrote: > > > #19: IPv4 address superfluous in MAP-E Interface IDs > > > > Changes (by remi.despres@free.fr): > > > > * priority: trivial => major > > * status: closed => reopened > > * resolution: wontfix => > > > > > > Comment: > > > > Value of having the PSID in MAP-E IIDs for maintenance isn't clear at > all: > > - PSID length isn't determined in IIDs (there can be an unknown number of > > trailing zeroes) > > - all PSID bits are already readable in the first 64 bits > > > > Suggestion to close the issue: > > - keep IPv4 addresses in IIDs (they contains some bits that aren't in the > > first 64 bits) > > - don't keep the PSID in IIDs (insufficiently justified complexity) > > > > -- > > > -------------------------+------------------------------------------------- > > Reporter: | Owner: draft-ietf-softwire- > > remi.despres@free.fr | map@tools.ietf.org > > Type: defect | Status: reopened > > Priority: major | Milestone: > > Component: map-e | Version: > > Severity: Candidate | Resolution: > > WG Document | > > Keywords: | > > > -------------------------+------------------------------------------------- > > > > Ticket URL: < > http://trac.tools.ietf.org/wg/softwire/trac/ticket/19#comment:4> > > softwire > > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --002354188208d5036204d4599182 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

the IPv4 and PSID in the IID are particularly useful in cases of= address independence (ie 1:1). As said previously, the benefit is primaril= y in the ability an operational facilitation, where an operator can easily = see/observe what IPv4 and PSID is being used by a given customer. This is e= asier than to look at the v6 prefix and use some magic decoder ring.
In addition, it has the desirable characteristic of creating an IID.
+1 Thus to keeping the IPv4 and PSID, likely in a fixed length (16 bit) fi= eld format.

Regards,
Woj.

On 24= January 2013 16:27, Ole Troan <otroan@employees.org> wro= te:
hi,

can we please keep discussion on the list. not via the issue tracker?

does anyone else have an opinion?
(if I don't hear anything from anyone else, I'll default to keep cu= rrent text.)

cheers,
Ole

On Jan 24, 2013, at 17:23 , softwire issue tracker <trac+softwire@tools.ietf.org> wrote:
> #19: IPv4 address superfluous in MAP-E Interface IDs
>
> Changes (by remi.despres@free.= fr):
>
> * priority: =A0trivial =3D> major
> * status: =A0closed =3D> reopened
> * resolution: =A0wontfix =3D>
>
>
> Comment:
>
> Value of having the PSID in MAP-E IIDs for maintenance isn't clear= at all:
> - PSID length isn't determined in IIDs (there can be an unknown nu= mber of
> trailing zeroes)
> - all PSID bits are already readable in the first 64 bits
>
> Suggestion to close the issue:
> - keep IPv4 addresses in IIDs (they contains some bits that aren't= in the
> first 64 bits)
> - don't keep the PSID in IIDs (insufficiently justified complexity= )
>
> --
> -------------------------+--------------------------------------------= -----
> Reporter: =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 Owner: =A0draft-ie= tf-softwire-
> =A0remi.despres@free.fr = =A0 | =A0map@tools.ietf.org
> =A0 =A0 Type: =A0defect =A0 =A0 =A0 | =A0 =A0 =A0Status: =A0reopened > Priority: =A0major =A0 =A0 =A0 =A0| =A0 Milestone:
> Component: =A0map-e =A0 =A0 =A0 =A0| =A0 =A0 Version:
> Severity: =A0Candidate =A0 =A0| =A0Resolution:
> =A0WG Document =A0 =A0 =A0 =A0 =A0 =A0|
> Keywords: =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
> -------------------------+--------------------------------------------= -----
>
> Ticket URL: <http://trac.tools.ietf.org/wg/softw= ire/trac/ticket/19#comment:4>
> softwire <http://tools.ietf.org/softwire/>
>

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

--002354188208d5036204d4599182-- From otroan@employees.org Mon Jan 28 05:59:50 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD24921F8464 for ; Mon, 28 Jan 2013 05:59:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.589 X-Spam-Level: X-Spam-Status: No, score=-10.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id seigjD10Rq-k for ; Mon, 28 Jan 2013 05:59:50 -0800 (PST) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 066A921F8999 for ; Mon, 28 Jan 2013 05:59:49 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAAeBBlGQ/khM/2dsb2JhbABFvloWc4IfAQV5EAtGVwaIJL9XjRQBgy9hA6ZVgniBZQEf X-IronPort-AV: E=Sophos;i="4.84,551,1355097600"; d="scan'208";a="11392118" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-3.cisco.com with ESMTP; 28 Jan 2013 13:59:48 +0000 Received: from dhcp-lys02-vla252-10-147-116-52.cisco.com (dhcp-lys02-vla252-10-147-116-52.cisco.com [10.147.116.52]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r0SDxl3k015474 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 28 Jan 2013 13:59:47 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ole Troan In-Reply-To: <51068200.8050509@gmail.com> Date: Mon, 28 Jan 2013 14:59:48 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5105A534.3080201@gmail.com> <563B6CD4-5F39-4392-A05D-A7E92F2670A1@employees.org> <51068200.8050509@gmail.com> To: Tom Taylor X-Mailer: Apple Mail (2.1499) Cc: Softwires Subject: Re: [Softwires] Limiting the length of the MAP endpoint IPv6 prefix X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 13:59:50 -0000 >>>=20 >>> The examples in my previous note sort of provided backing for my = view that the MAP endpoint IPv6 prefix can be limited to a maximum of a = /64, thus making the IID fully conformant both to RFC 4291 and to RFC = 6052. >>>=20 > ... >=20 >>>=20 >>> I think limiting the prefix length to 64 bits is reasonable. = Comments? >>=20 >> I don't think that's reasonable. >> and I don't see what it buys us, given that supporting prefix lengths = longer than 64 is simple. >> IPv6 isn't classfull, there isn't anything magic with the 64 = boundary. ;-) >>=20 >> cheers, >> Ole >>=20 >=20 > OK, then I agree with R=E9mi. Drop mention of prefixes greater than 64 = bits long and leave it to the reader to judge whether RFC 4291 imposes a = limit. you want this removed: If the End-user IPv6 prefix length is larger than 64, the most significant parts of the interface identifier is overwritten by = the prefix. I disagree. this is the only text in there suggesting to an implementor = that prefix lengths can be any value between 0-128. Tom, Remi and I have stated our opinions. does anyone else have a view = on the matter? cheers, Ole= From rajiva@cisco.com Mon Jan 28 06:23:17 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB0D621F86DE for ; Mon, 28 Jan 2013 06:23:17 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKBeXN9mbnmm for ; Mon, 28 Jan 2013 06:23:17 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id EAD7B21F8605 for ; Mon, 28 Jan 2013 06:23:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1848; q=dns/txt; s=iport; t=1359382997; x=1360592597; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=JndmsmFYJJlN51UcQSZPAO/n6ke/TAuzuUhSz4MCnyA=; b=MXlgXZh81q23rKfW5VKW/oQlWTzDH3XFDso7FfoKF+38ZkSz9ZmsNjFw oRJxQ63bDpSJk77wSdXcgPKn2+MOfvEuCoSrNu+s1IRI0MdNG//glrOi1 BzI3kQov5HXKJJ7pENhNFkuj6X3rQY034L+e7FGYNz4LEQGKn1xVzXSnX A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EACOJBlGtJXG+/2dsb2JhbABFvloWc4IfAQEEAQEBawsQAgEIDjgnCyUCBA4FiBEMv1gEjRQBgy9hA4gsjWGQSIJ3gWYBHw X-IronPort-AV: E=Sophos;i="4.84,551,1355097600"; d="scan'208";a="169173437" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 28 Jan 2013 14:23:16 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r0SENGPI012416 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 28 Jan 2013 14:23:16 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.193]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Mon, 28 Jan 2013 08:23:16 -0600 From: "Rajiv Asati (rajiva)" To: Ole Troan Thread-Topic: [Softwires] Limiting the length of the MAP endpoint IPv6 prefix Thread-Index: AQHN/NrF6Lo0/54q4E6k5W7dtJnASZhe3eoAgABJpwCAAALGAP//ofn6 Date: Mon, 28 Jan 2013 14:23:15 +0000 Message-ID: <0B7B5FE1-CAFD-4515-B335-7672D202DC0D@cisco.com> References: <5105A534.3080201@gmail.com> <563B6CD4-5F39-4392-A05D-A7E92F2670A1@employees.org> <51068200.8050509@gmail.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Softwires Subject: Re: [Softwires] Limiting the length of the MAP endpoint IPv6 prefix X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 14:23:17 -0000 Let's not leave anything in the drafts as loose-ends for the readers (e.g. = Implementors, designers, architects) to (mis)interpret.=20 We better provide recommendations, if/as needed in case of ambiguity or dis= agreement. IMO, /64 (or less) usage for end-user prefix is better off as a MAP (-E) re= commendation, but not as an enforcement. =20 Cheers, Rajiv Sent from my Phone On Jan 28, 2013, at 8:59 AM, "Ole Troan" wrote: >>>>=20 >>>> The examples in my previous note sort of provided backing for my view = that the MAP endpoint IPv6 prefix can be limited to a maximum of a /64, thu= s making the IID fully conformant both to RFC 4291 and to RFC 6052. >> ... >>=20 >>>>=20 >>>> I think limiting the prefix length to 64 bits is reasonable. Comments? >>>=20 >>> I don't think that's reasonable. >>> and I don't see what it buys us, given that supporting prefix lengths l= onger than 64 is simple. >>> IPv6 isn't classfull, there isn't anything magic with the 64 boundary. = ;-) >>>=20 >>> cheers, >>> Ole >>=20 >> OK, then I agree with R=E9mi. Drop mention of prefixes greater than 64 b= its long and leave it to the reader to judge whether RFC 4291 imposes a lim= it. >=20 > you want this removed: > If the End-user IPv6 prefix length is larger than 64, the most > significant parts of the interface identifier is overwritten by the > prefix. >=20 > I disagree. this is the only text in there suggesting to an implementor t= hat prefix lengths can be any value between 0-128. >=20 > Tom, Remi and I have stated our opinions. does anyone else have a view on= the matter? >=20 > cheers, > Ole > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From ssenthil@cisco.com Mon Jan 28 06:24:21 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B29521F886F for ; Mon, 28 Jan 2013 06:24:21 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qwQw6xHh0Mlx for ; Mon, 28 Jan 2013 06:24:21 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 004ED21F8605 for ; Mon, 28 Jan 2013 06:24:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1571; q=dns/txt; s=iport; t=1359383061; x=1360592661; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=uiSFbB4/b+flGeOrD+5ioUkIQ0tjyujrt5QZO5GKVck=; b=ZSVgltPA1dppOazlmORegfD7fDbNbsRBmsqUUUP1mlBydm7SmRlQSdWW lgmgJt6ATLFWeXUAO0/XbPzhMh1+kZ6TSscq5IhBg+j1Tr9rNy7hvcv2l iCGu/ntHn1PnDCFjIpsx1GxPcWEqZ4q1S1uJjCY3RPrJCTZYlwOwZAUVX U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAPaIBlGtJV2c/2dsb2JhbABFvloWc4IgAQQBAQFrCxIBCA4USwslAgQBDQUIiAkMv1cEjRQBgy9hA4gsnimCd4FmAR8e X-IronPort-AV: E=Sophos;i="4.84,551,1355097600"; d="scan'208";a="169173490" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 28 Jan 2013 14:24:20 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r0SEOKav024900 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 28 Jan 2013 14:24:20 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.248]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0318.004; Mon, 28 Jan 2013 08:24:20 -0600 From: "Senthil Sivakumar (ssenthil)" To: Ole Troan , Tom Taylor Thread-Topic: [Softwires] Limiting the length of the MAP endpoint IPv6 prefix Thread-Index: AQHN/NrF2B0aLU6sVE2EGmWvbGzXKphe3eoAgABJpwCAAALGAP//swcA Date: Mon, 28 Jan 2013 14:24:19 +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.2.5.121010 x-originating-ip: [10.117.198.136] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Softwires Subject: Re: [Softwires] Limiting the length of the MAP endpoint IPv6 prefix X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 14:24:21 -0000 I believe the prefix length > 64 should be allowed. It is upto the operator to choose the prefix length of their choice. On 1/28/13 8:59 AM, "Ole Troan" wrote: >>>>=20 >>>> The examples in my previous note sort of provided backing for my view >>>>that the MAP endpoint IPv6 prefix can be limited to a maximum of a >>>>/64, thus making the IID fully conformant both to RFC 4291 and to RFC >>>>6052. >>>>=20 >> ... >>=20 >>>>=20 >>>> I think limiting the prefix length to 64 bits is reasonable. Comments? >>>=20 >>> I don't think that's reasonable. >>> and I don't see what it buys us, given that supporting prefix lengths >>>longer than 64 is simple. >>> IPv6 isn't classfull, there isn't anything magic with the 64 boundary. >>>;-) >>>=20 >>> cheers, >>> Ole >>>=20 >>=20 >> OK, then I agree with R=E9mi. Drop mention of prefixes greater than 64 >>bits long and leave it to the reader to judge whether RFC 4291 imposes a >>limit. > >you want this removed: > If the End-user IPv6 prefix length is larger than 64, the most > significant parts of the interface identifier is overwritten by the > prefix. > >I disagree. this is the only text in there suggesting to an implementor >that prefix lengths can be any value between 0-128. > >Tom, Remi and I have stated our opinions. does anyone else have a view on >the matter? > >cheers, >Ole >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires From despres.remi@laposte.net Mon Jan 28 08:16:36 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D074C21F870E for ; Mon, 28 Jan 2013 08:16:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LgVQ6oBpB3t0 for ; Mon, 28 Jan 2013 08:16:36 -0800 (PST) Received: from smtp25.services.sfr.fr (smtp25.services.sfr.fr [93.17.128.118]) by ietfa.amsl.com (Postfix) with ESMTP id E0E0221F86FF for ; Mon, 28 Jan 2013 08:16:35 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2518.sfr.fr (SMTP Server) with ESMTP id 3430170001A8; Mon, 28 Jan 2013 17:16:34 +0100 (CET) Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2518.sfr.fr (SMTP Server) with ESMTP id D67FF700018F; Mon, 28 Jan 2013 17:16:33 +0100 (CET) X-SFR-UUID: 20130128161633878.D67FF700018F@msfrf2518.sfr.fr Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Mon, 28 Jan 2013 17:16:32 +0100 Message-Id: <3466C6E7-9778-4D8A-9828-0D127FB46C1D@laposte.net> References: To: Senthil Sivakumar X-Mailer: Apple Mail (2.1499) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Softwires Subject: Re: [Softwires] Limiting the length of the MAP endpoint IPv6 prefix X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 16:16:36 -0000 Senthil, 2013-01-2815:24, Senthil Sivakumar (ssenthil) : > I believe the prefix length > 64 should be allowed. > It is upto the > operator to choose the prefix length of their choice. Agreed. No one suggest to say the contrary. Yet, operators have the constraint of RFC 4291 that "For all unicast = addresses, except those that start with the binary value 000, Interface = IDs are required to be 64 bits long and to be constructed in Modified = EUI-64 format". =20 The draft says that: (a) The PSID is: +--+---+---+---+---+---+---+---+---+ |PL| 8 16 24 32 40 48 56 | +--+---+---+---+---+---+---+---+---+ |64| u | IPv4 address | PSID | 0 | +--+---+---+---+---+---+---+---+---+ (b) "If the End-user IPv6 prefix length is larger than 64, the most = significant parts of the interface identifier is overwritten by the = prefix." This is particularly unclear: - What happens to the u octet? - And to the IPv4 address if the prefix is longer than /68?=20 - ... Of course, if a use case is provided where MAP-E would be actually used = with an IID shorter than 64 bits, it should be discussed. But: - There is no such use case so far.=20 - Looking for one doesn't seem useful.=20 Regards, RD =20 >=20 > On 1/28/13 8:59 AM, "Ole Troan" wrote: >=20 >>>>>=20 >>>>> The examples in my previous note sort of provided backing for my = view >>>>> that the MAP endpoint IPv6 prefix can be limited to a maximum of a >>>>> /64, thus making the IID fully conformant both to RFC 4291 and to = RFC >>>>> 6052. >>>>>=20 >>> ... >>>=20 >>>>>=20 >>>>> I think limiting the prefix length to 64 bits is reasonable. = Comments? >>>>=20 >>>> I don't think that's reasonable. >>>> and I don't see what it buys us, given that supporting prefix = lengths >>>> longer than 64 is simple. >>>> IPv6 isn't classfull, there isn't anything magic with the 64 = boundary. >>>> ;-) >>>>=20 >>>> cheers, >>>> Ole >>>>=20 >>>=20 >>> OK, then I agree with R=E9mi. Drop mention of prefixes greater than = 64 >>> bits long and leave it to the reader to judge whether RFC 4291 = imposes a >>> limit. >>=20 >> you want this removed: >> If the End-user IPv6 prefix length is larger than 64, the most >> significant parts of the interface identifier is overwritten by = the >> prefix. >>=20 >> I disagree. this is the only text in there suggesting to an = implementor >> that prefix lengths can be any value between 0-128. >>=20 >> Tom, Remi and I have stated our opinions. does anyone else have a = view on >> the matter? >>=20 >> cheers, >> Ole >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From otroan@employees.org Mon Jan 28 08:30:47 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E21AE21F87C4 for ; Mon, 28 Jan 2013 08:30:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.44 X-Spam-Level: X-Spam-Status: No, score=-10.44 tagged_above=-999 required=5 tests=[AWL=-0.141, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m1mYNhzDdFXZ for ; Mon, 28 Jan 2013 08:30:47 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 1CBFA21F8999 for ; Mon, 28 Jan 2013 08:30:46 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,551,1355097600"; d="scan'208";a="80064751" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 28 Jan 2013 16:30:45 +0000 Received: from dhcp-lys02-vla252-10-147-116-52.cisco.com (dhcp-lys02-vla252-10-147-116-52.cisco.com [10.147.116.52]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r0SGUiYR010249 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 28 Jan 2013 16:30:44 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ole Troan In-Reply-To: <3466C6E7-9778-4D8A-9828-0D127FB46C1D@laposte.net> Date: Mon, 28 Jan 2013 17:30:44 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3466C6E7-9778-4D8A-9828-0D127FB46C1D@laposte.net> To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1499) Cc: Softwires Subject: Re: [Softwires] Limiting the length of the MAP endpoint IPv6 prefix X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 16:30:48 -0000 Remi, >> I believe the prefix length > 64 should be allowed. >=20 >=20 >> It is upto the >> operator to choose the prefix length of their choice. >=20 > Agreed. > No one suggest to say the contrary. >=20 > Yet, operators have the constraint of RFC 4291 that "For all unicast = addresses, except those that start with the binary value 000, Interface = IDs are required to be 64 bits long and to be constructed in Modified = EUI-64 format". =20 I am not aware of any implementations that restrict the prefix length to = 64. I'm not aware of any implementation that applies any meaning to any bits = in the interface-id. I'm aware of operators using prefix lengths longer than /64. actual deployment and implementation trumps text. that doesn't even use = RFC2119 language. (and I know after annual discussions with one of the authors that the = intention with that line was not to make IPv6 classful.) >=20 > The draft says that: > (a) The PSID is: > +--+---+---+---+---+---+---+---+---+ > |PL| 8 16 24 32 40 48 56 | > +--+---+---+---+---+---+---+---+---+ > |64| u | IPv4 address | PSID | 0 | > +--+---+---+---+---+---+---+---+---+ > (b) "If the End-user IPv6 prefix length is larger than 64, the most = significant parts of the interface identifier is overwritten by the = prefix." >=20 > This is particularly unclear: > - What happens to the u octet? that's up to the operator. > - And to the IPv4 address if the prefix is longer than /68?=20 it gets overwritten by the prefix, isn't that what the text says? > - ... >=20 > Of course, if a use case is provided where MAP-E would be actually = used with an IID shorter than 64 bits, it should be discussed. But: > - There is no such use case so far.=20 > - Looking for one doesn't seem useful.=20 huh? provider wants to deploy with a prefix length of 128? single tunnel end = point address. isn't that obvious? cheers, Ole= From ssenthil@cisco.com Mon Jan 28 08:36:38 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8310321F87D3 for ; Mon, 28 Jan 2013 08:36:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQqRpNNcJoKG for ; Mon, 28 Jan 2013 08:36:36 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id C260221F87C4 for ; Mon, 28 Jan 2013 08:36:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4432; q=dns/txt; s=iport; t=1359390996; x=1360600596; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=/VQ4NANwhcpbas7kmcUTXLCD0bG5wG/hVkAcwopmfJE=; b=S6W10TukcuPyOXYM6XRfHqtigYMFCI1lXKsm9KEzvTlRLseP8zEvujUZ An9Ebs5STj2aNWzQDwJqxjx4oQ4HLcUjfz+y8REB4Cu4cArxJUKtd1mu3 aNx74FvhvtIAi/RW3Z5SUkSjVGnueJMTY7QAghsKSBnjvFEIuxk6zgBPn M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAMyoBlGtJV2b/2dsb2JhbABEvlMWc4IeAQEBBAEBAWsLEgEIGApLCyUCBA4FCId3Aw8MthQTiUsEjRQBgy9hA4gsnimCd4FmAR8e X-IronPort-AV: E=Sophos;i="4.84,551,1355097600"; d="scan'208";a="169309333" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 28 Jan 2013 16:36:36 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r0SGaaMW007774 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 28 Jan 2013 16:36:36 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.248]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Mon, 28 Jan 2013 10:36:36 -0600 From: "Senthil Sivakumar (ssenthil)" To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Thread-Topic: [Softwires] Limiting the length of the MAP endpoint IPv6 prefix Thread-Index: AQHN/NrF2B0aLU6sVE2EGmWvbGzXKphe3eoAgABJpwCAAALGAP//swcAgABzLQD//7HBgA== Date: Mon, 28 Jan 2013 16:36:35 +0000 Message-ID: In-Reply-To: <3466C6E7-9778-4D8A-9828-0D127FB46C1D@laposte.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [64.102.83.131] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Softwires Subject: Re: [Softwires] Limiting the length of the MAP endpoint IPv6 prefix X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 16:36:38 -0000 Hi Remi, On 1/28/13 11:16 AM, "R=E9mi Despr=E9s" wrote: >Senthil, > > >2013-01-2815:24, Senthil Sivakumar (ssenthil) : > >> I believe the prefix length > 64 should be allowed. > > >> It is upto the >> operator to choose the prefix length of their choice. > >Agreed. >No one suggest to say the contrary. > >Yet, operators have the constraint of RFC 4291 that "For all unicast >addresses, except those that start with the binary value 000, Interface >IDs are required to be 64 bits long and to be constructed in Modified >EUI-64 format". =20 Honestly, I don=B9t know the rationale behind this. > >The draft says that: >(a) The PSID is: >+--+---+---+---+---+---+---+---+---+ >|PL| 8 16 24 32 40 48 56 | >+--+---+---+---+---+---+---+---+---+ >|64| u | IPv4 address | PSID | 0 | >+--+---+---+---+---+---+---+---+---+ I believe this figure is misleading by placing the IPv4 address in a fixed location. Figure 3 and Figure 7 In the draft shows that the IID is not in a fixed location. Also, the text surrounding the above figure 8, says "The Interface identifier format of a MAP node is based on the format specified in section 2.2 of [RFC6052], with the added PSID field if present, as shown in figure Figure 8." But RFC 6052 doesn=B9t have the IPv4 address in a fixed location as per section 2.2. So I think this figure is misleading. | n bits | o bits | s bits | 128-n-o-s bits | +--------------------+-----------+---------+------------+----------+ | Rule IPv6 prefix | EA bits |subnet ID| interface ID | +--------------------+-----------+---------+-----------------------+ >(b) "If the End-user IPv6 prefix length is larger than 64, the most >significant parts of the interface identifier is overwritten by the >prefix." > >This is particularly unclear: True. >- What happens to the u octet? I guess that needs to be made clear in the draft. We struggled with that in our implementation. >- And to the IPv4 address if the prefix is longer than /68? >- ... > >Of course, if a use case is provided where MAP-E would be actually used >with an IID shorter than 64 bits, it should be discussed. But: >- There is no such use case so far. >- Looking for one doesn't seem useful. I would like to see the IPv4 address be present from bits 96-127, no need for the PSID to be repeated again. That would allow us to go upto /96 and being consistent with RFC 6052 which allows one to configure a prefix of upto /96. Thanks Senthil > > >Regards, >RD > >=20 >>=20 >> On 1/28/13 8:59 AM, "Ole Troan" wrote: >>=20 >>>>>>=20 >>>>>> The examples in my previous note sort of provided backing for my >>>>>>view >>>>>> that the MAP endpoint IPv6 prefix can be limited to a maximum of a >>>>>> /64, thus making the IID fully conformant both to RFC 4291 and to >>>>>>RFC >>>>>> 6052. >>>>>>=20 >>>> ... >>>>=20 >>>>>>=20 >>>>>> I think limiting the prefix length to 64 bits is reasonable. >>>>>>Comments? >>>>>=20 >>>>> I don't think that's reasonable. >>>>> and I don't see what it buys us, given that supporting prefix lengths >>>>> longer than 64 is simple. >>>>> IPv6 isn't classfull, there isn't anything magic with the 64 >>>>>boundary. >>>>> ;-) >>>>>=20 >>>>> cheers, >>>>> Ole >>>>>=20 >>>>=20 >>>> OK, then I agree with R=E9mi. Drop mention of prefixes greater than 64 >>>> bits long and leave it to the reader to judge whether RFC 4291 >>>>imposes a >>>> limit. >>>=20 >>> you want this removed: >>> If the End-user IPv6 prefix length is larger than 64, the most >>> significant parts of the interface identifier is overwritten by the >>> prefix. >>>=20 >>> I disagree. this is the only text in there suggesting to an implementor >>> that prefix lengths can be any value between 0-128. >>>=20 >>> Tom, Remi and I have stated our opinions. does anyone else have a view >>>on >>> the matter? >>>=20 >>> cheers, >>> Ole >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >>=20 >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires From despres.remi@laposte.net Mon Jan 28 08:57:21 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5072A21F8467 for ; Mon, 28 Jan 2013 08:57:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6QlimdBt36o for ; Mon, 28 Jan 2013 08:57:20 -0800 (PST) Received: from smtp25.services.sfr.fr (smtp25.services.sfr.fr [93.17.128.121]) by ietfa.amsl.com (Postfix) with ESMTP id 9065E21F844A for ; Mon, 28 Jan 2013 08:57:19 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2517.sfr.fr (SMTP Server) with ESMTP id 1A66E7000077; Mon, 28 Jan 2013 17:57:19 +0100 (CET) Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2517.sfr.fr (SMTP Server) with ESMTP id CE1BF7000065; Mon, 28 Jan 2013 17:57:18 +0100 (CET) X-SFR-UUID: 20130128165718844.CE1BF7000065@msfrf2517.sfr.fr Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Mon, 28 Jan 2013 17:57:18 +0100 Message-Id: <1196904B-BC49-4599-B8BA-D3D020B22D8A@laposte.net> References: <3466C6E7-9778-4D8A-9828-0D127FB46C1D@laposte.net> To: Ole Troan X-Mailer: Apple Mail (2.1499) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Softwires Subject: Re: [Softwires] Limiting the length of the MAP endpoint IPv6 prefix X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 16:57:21 -0000 Le 2013-01-28 =E0 17:30, Ole Troan a =E9crit : > Remi, >=20 >>> I believe the prefix length > 64 should be allowed. >>=20 >>=20 >>> It is upto the >>> operator to choose the prefix length of their choice. >>=20 >> Agreed. >> No one suggest to say the contrary. >>=20 >> Yet, operators have the constraint of RFC 4291 that "For all unicast = addresses, except those that start with the binary value 000, Interface = IDs are required to be 64 bits long and to be constructed in Modified = EUI-64 format". =20 >=20 > I am not aware of any implementations that restrict the prefix length = to 64. > I'm not aware of any implementation that applies any meaning to any = bits in the interface-id. > I'm aware of operators using prefix lengths longer than /64. >=20 > actual deployment and implementation trumps text. that doesn't even = use RFC2119 language. > (and I know after annual discussions with one of the authors that the = intention with that line was not to make IPv6 classful.) >=20 >>=20 >> The draft says that: >> (a) The PSID is: >> +--+---+---+---+---+---+---+---+---+ >> |PL| 8 16 24 32 40 48 56 | >> +--+---+---+---+---+---+---+---+---+ >> |64| u | IPv4 address | PSID | 0 | >> +--+---+---+---+---+---+---+---+---+ >> (b) "If the End-user IPv6 prefix length is larger than 64, the most = significant parts of the interface identifier is overwritten by the = prefix." >>=20 >> This is particularly unclear: >> - What happens to the u octet? >=20 > that's up to the operator. >=20 >> - And to the IPv4 address if the prefix is longer than /68?=20 >=20 > it gets overwritten by the prefix, isn't that what the text says? Partially overwritten, yes, thus creating confusion, for no known reason = to justify it. I wonder what use of the IPv4 address could one imagine in this case? >=20 >=20 >> - ... >>=20 >> Of course, if a use case is provided where MAP-E would be actually = used with an IID shorter than 64 bits, it should be discussed. But: >> - There is no such use case so far.=20 >> - Looking for one doesn't seem useful.=20 >=20 > huh? > provider wants to deploy with a prefix length of 128? single tunnel = end point address. isn't that obvious? Obvious, no! Could you please complete an example with a CE address and its BMR? Thanks, RD >=20 > cheers, > Ole From tom.taylor.stds@gmail.com Mon Jan 28 08:59:25 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA0021F8967 for ; Mon, 28 Jan 2013 08:59:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.428 X-Spam-Level: X-Spam-Status: No, score=-0.428 tagged_above=-999 required=5 tests=[AWL=-0.476, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4VD+gAGHcNnq for ; Mon, 28 Jan 2013 08:59:25 -0800 (PST) Received: from mail-ie0-x233.google.com (ie-in-x0233.1e100.net [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 0EE1621F8550 for ; Mon, 28 Jan 2013 08:59:24 -0800 (PST) Received: by mail-ie0-f179.google.com with SMTP id k13so793726iea.24 for ; Mon, 28 Jan 2013 08:59:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding:x-antivirus :x-antivirus-status; bh=/qt4y5WnS9eEg3Eb0E4bKai8ILPmAGii8htlXhybOzk=; b=p/P++jLwfSmviAd406C/642yjXLnXBDM10wt8IMMoYKcQN6/tAYDBVN57j5RDOZiHP effAjCVNxmxE83ZyIbboplCy6y6sD54WAQ6B8oU5C3vX/CeCGAmyB9gO9t8+M1U/tBw1 LPGtCxIeJpSJILvRxKrNd8FsYFjPbIXj6LuKynbkf1ausY3rxLDcld+GVD8ks7qWPOHd NTLpRrdwSDDMI/lPr1lUhf4nK73YxbXRt19Fm8D924c9OifHBwFUD6aJ1M9ZT9P9ULha g2ph9evo3/K7u7zpuFAKSZMWtMlS4B1/r3ijavj847TrALN4rNU05KzjurBz6Y2nFbWN G1IQ== X-Received: by 10.42.212.8 with SMTP id gq8mr9124876icb.48.1359392364565; Mon, 28 Jan 2013 08:59:24 -0800 (PST) Received: from [127.0.0.1] (dsl-173-206-87-33.tor.primus.ca. [173.206.87.33]) by mx.google.com with ESMTPS id df6sm6425651igb.15.2013.01.28.08.59.22 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Jan 2013 08:59:23 -0800 (PST) Message-ID: <5106AE69.80705@gmail.com> Date: Mon, 28 Jan 2013 11:59:21 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Softwires Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130128-0, 28/01/2013), Outbound message X-Antivirus-Status: Clean Subject: [Softwires] Section 5.1 of the MAP draft X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 16:59:25 -0000 I made some editorial comments about Section 5.1 the other day. I have a substantive comment now, and a text proposal to pull it all together. Comment: the statement "For a = 0, A MAY be 0 to allow for the provisioning of the system ports." just below Figure 2 is illogical, since if a = 0, the value A does not exist. In fact, a = 0 returns us to the naive approach in the second paragraph of Section 5.1. Hence I propose alternative text for the section. Note two changes to Figure 2: removed extra bit 16 and changed the title. Proposed text: 5.1. Port Mapping Algorithm The port mapping algorithm is used to represent the port numbers allocated to a given CE if the CE has been given a shared IPv4 address. The simplest way to allocate ports is to allocate one range of consecutive ports to each CE sharing an address. The Port-Set Identifier (PSID) is an index over the sequence of allocated ranges, starting from zero. In this case, assuming that the number of port numbers in each allocated range is a power of 2, the set of port numbers allocated to a given CE can be represented using a notation similar to CIDR [RFC4632], but with 16 bits instead of 32. For example, assuming a range size of 256 port numbers, the first 256 ports are represented as port prefix 0.0/8, the last 256 ports as 255.0/8. In hexadecimal, 0x0000/8 (PSID = 0) and 0xFF00/8 (PSID = 0xFF). It can be seen from the example that the lowest PSID values allocate ports in the system port range [I-D.ietf-tsvwg-iana-ports] to one or more CEs. To avoid this, the lowest PSID values (0x00 to 0x03 in the example) should not be used. A more sophisticated approach allocates ports in a series of blocks, where each CE sharing an address receives one range from each block. This can be represented as shown in Figure 2. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-------+-----------+----------+ Ports in | A | PSID | M | the CE port set | > 0 | |any value | +-------+-----------+----------+ |a bits | k bits | m bits | Figure 2: Three-Part Decomposition of Allocated Port Numbers A Indexes the blocks of port numbers. The lowest block number (A = 0) and possibly others contain the system port numbers, and hence should not be used if port numbers 0-1023 are to be avoided. a Width of the field containing the block index A. Indirectly a determines the block size, by the formula: Block size = 65536 / 2^a a = 0 brings us back to the simple (single block) model described above, where the PSID value rather than the value of A must be restricted to avoid the system ports. The value of a is optionally provisioned as part of the mapping rule. The default value for a is 4, to place the start of the PSID on a nibble boundary. This leaves ports in the range 0-4095 unallocated. PSID Indexes the position of the allocated range for a given CE within each block. In the more general model, where A > 0, PSID values can begin at 0 without causing system ports to be allocated. k Width of the field containing the PSID. The number of CEs sharing the same IPv4 address is given by 2^k, except when a = 0 and the lowest PSID values are excluded. M Indexes a specific port number within a range determined by the values of A and the PSID. m Width of the port index field. The number of ports in each allocated range is given by 2^m. From otroan@employees.org Mon Jan 28 09:48:29 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B118621F87E0 for ; Mon, 28 Jan 2013 09:48:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.431 X-Spam-Level: X-Spam-Status: No, score=-10.431 tagged_above=-999 required=5 tests=[AWL=-0.132, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Lw+CEuoKg8E for ; Mon, 28 Jan 2013 09:48:28 -0800 (PST) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 99DDB21F84C0 for ; Mon, 28 Jan 2013 09:48:28 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,553,1355097600"; d="scan'208";a="11404056" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-3.cisco.com with ESMTP; 28 Jan 2013 17:48:27 +0000 Received: from dhcp-10-61-106-14.cisco.com (dhcp-10-61-106-14.cisco.com [10.61.106.14]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r0SHmRFM027090 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 28 Jan 2013 17:48:27 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ole Troan In-Reply-To: <1196904B-BC49-4599-B8BA-D3D020B22D8A@laposte.net> Date: Mon, 28 Jan 2013 18:48:26 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <87D442A3-56C7-4578-A999-AC63D5DEE9F4@employees.org> References: <3466C6E7-9778-4D8A-9828-0D127FB46C1D@laposte.net> <1196904B-BC49-4599-B8BA-D3D020B22D8A@laposte.net> To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1499) Cc: Softwires Subject: Re: [Softwires] Limiting the length of the MAP endpoint IPv6 prefix X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 17:48:29 -0000 Remi, [...] >>> - And to the IPv4 address if the prefix is longer than /68?=20 >>=20 >> it gets overwritten by the prefix, isn't that what the text says? >=20 > Partially overwritten, yes, thus creating confusion, for no known = reason to justify it. > I wonder what use of the IPv4 address could one imagine in this case? no, fully overwritten. >>> - ... >>>=20 >>> Of course, if a use case is provided where MAP-E would be actually = used with an IID shorter than 64 bits, it should be discussed. But: >>> - There is no such use case so far.=20 >>> - Looking for one doesn't seem useful.=20 >>=20 >> huh? >> provider wants to deploy with a prefix length of 128? single tunnel = end point address. isn't that obvious? >=20 > Obvious, no! >=20 > Could you please complete an example with a CE address and its BMR? BMR: Rule IPv6 prefix: 2001:db8::1/128 Rule IPv4 prefix: 1.1.1.1/32 EA-bits length: 0 MAP IPv6 address 2001:db8::1. cheers, Ole From otroan@employees.org Mon Jan 28 09:56:47 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB27D21F89BF for ; Mon, 28 Jan 2013 09:56:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.574 X-Spam-Level: X-Spam-Status: No, score=-10.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id czAVVJ8D1zzz for ; Mon, 28 Jan 2013 09:56:47 -0800 (PST) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 27EFD21F89BA for ; Mon, 28 Jan 2013 09:56:47 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,553,1355097600"; d="scan'208";a="11404173" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-3.cisco.com with ESMTP; 28 Jan 2013 17:56:46 +0000 Received: from dhcp-10-61-106-14.cisco.com (dhcp-10-61-106-14.cisco.com [10.61.106.14]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r0SHujLA028580 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 28 Jan 2013 17:56:46 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ole Troan In-Reply-To: Date: Mon, 28 Jan 2013 18:56:45 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2928CE6C-CF5B-4410-BDA4-B32E4D7C7917@employees.org> References: To: "Senthil Sivakumar (ssenthil)" X-Mailer: Apple Mail (2.1499) Cc: Softwires Subject: Re: [Softwires] Limiting the length of the MAP endpoint IPv6 prefix X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 17:56:48 -0000 Senthil, [...] >> The draft says that: >> (a) The PSID is: >> +--+---+---+---+---+---+---+---+---+ >> |PL| 8 16 24 32 40 48 56 | >> +--+---+---+---+---+---+---+---+---+ >> |64| u | IPv4 address | PSID | 0 | >> +--+---+---+---+---+---+---+---+---+ >=20 > I believe this figure is misleading by placing the IPv4 address in a = fixed > location. Figure 3 and Figure 7 > In the draft shows that the IID is not in a fixed location. Also, the = text > surrounding the above figure 8, says > "The Interface identifier format of a MAP node is based on the format > specified in section 2.2 of [RFC6052], with the added PSID field if > present, as shown in figure Figure 8." >=20 >=20 > But RFC 6052 doesn=B9t have the IPv4 address in a fixed location as = per > section 2.2. So I think this figure is misleading. perhaps we should just remove the RFC6052 reference then? with a 48 bits of PSID + IPv4 address. I don't mind if it is just IPv4 address, but then someone need to drive = that discussion. > | n bits | o bits | s bits | 128-n-o-s bits | > +--------------------+-----------+---------+------------+----------+ > | Rule IPv6 prefix | EA bits |subnet ID| interface ID | > +--------------------+-----------+---------+-----------------------+ >=20 >=20 >> (b) "If the End-user IPv6 prefix length is larger than 64, the most >> significant parts of the interface identifier is overwritten by the >> prefix." >>=20 >> This is particularly unclear: >=20 > True. >> - What happens to the u octet? >=20 > I guess that needs to be made clear in the draft. We struggled with = that > in our implementation. if we remove the 6052 reference, there is no u-octet. >> - And to the IPv4 address if the prefix is longer than /68? >> - ... >>=20 >> Of course, if a use case is provided where MAP-E would be actually = used >> with an IID shorter than 64 bits, it should be discussed. But: >> - There is no such use case so far. >> - Looking for one doesn't seem useful. >=20 > I would like to see the IPv4 address be present from bits 96-127, no = need > for the PSID to be repeated again. That would allow us to go upto /96 = and > being consistent with RFC 6052 which allows one to configure a prefix = of > upto /96. just put the IPv4 address in the bottom bits, and allow it to be = overwritten by the prefix. it is just there for 'pretty printing' anyway. cheers, Ole= From wang.cui1@zte.com.cn Mon Jan 28 18:38:24 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB8EC21E8042; Mon, 28 Jan 2013 18:38:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -91.136 X-Spam-Level: X-Spam-Status: No, score=-91.136 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KkZlPoxsYrz2; Mon, 28 Jan 2013 18:38:23 -0800 (PST) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 9370011E8097; Mon, 28 Jan 2013 18:38:22 -0800 (PST) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id 7F46C7BFCFE; Tue, 29 Jan 2013 10:39:35 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id r0T2c1vu022743; Tue, 29 Jan 2013 10:38:01 +0800 (GMT-8) (envelope-from wang.cui1@zte.com.cn) In-Reply-To: To: Wojciech Dec MIME-Version: 1.0 X-KeepSent: 2880B962:F59FB127-48257B02:000DA253; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: wang.cui1@zte.com.cn Date: Tue, 29 Jan 2013 10:38:01 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2013-01-29 10:37:58, Serialize complete at 2013-01-29 10:37:58 Content-Type: multipart/alternative; boundary="=_alternative 000E6F9448257B02_=" X-MAIL: mse02.zte.com.cn r0T2c1vu022743 Cc: "softwires@ietf.org WG" , remi.despres@free.fr, softwires-bounces@ietf.org Subject: [Softwires] =?gb2312?b?tPC4tDogUmU6ICBbc29mdHdpcmVdICMxOTogSVB2?= =?gb2312?b?NCBhZGRyZXNzIHN1cGVyZmx1b3VzIGluIE1BUC1FIEludGVyZmFjZSBJRHM=?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 02:38:24 -0000 This is a multipart message in MIME format. --=_alternative 000E6F9448257B02_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksDQoNCiAgS2VlcGluZyBQU0lEIGluIElJRHMgc2VlbXMgcmVwZWF0ZWQgZnJvbSB0aGUgYXNw ZWN0IG9mIDEyOC1iaXQgSVB2NiANCmFkZHJlc3MsIGJ1dCBmcm9tIHRoZSBhc3BlY3Qgb2YgNjQt Yml0IElJRHMsIElQdjQgYWRkcmVzcyBhbmQgUFNJRCANCmd1YXJhbnRlZSBJSURzIHRvIGJlIHVu aXZlcnNhbGx5IHVuaXF1ZS4gDQoNCiAgU28sICsxIEtlZXBpbmcgdGhlIElQdjQgYW5kIFBTSUQg aW4gSUlEcy4NCg0KQlJzDQpMaW5kYSBXYW5nDQoNCg0KDQoNCldvamNpZWNoIERlYyA8d2RlYy5p ZXRmQGdtYWlsLmNvbT4gDQq3orz+yMs6ICBzb2Z0d2lyZXMtYm91bmNlc0BpZXRmLm9yZw0KMjAx My0wMS0yOCAyMTo1MQ0KDQrK1bz+yMsNCk9sZSBUcm9hbiA8b3Ryb2FuQGVtcGxveWVlcy5vcmc+ DQqzrcvNDQoic29mdHdpcmVzQGlldGYub3JnIFdHIiA8c29mdHdpcmVzQGlldGYub3JnPiwgcmVt aS5kZXNwcmVzQGZyZWUuZnINCtb3zOINClJlOiBbU29mdHdpcmVzXSBbc29mdHdpcmVdICMxOTog SVB2NCBhZGRyZXNzIHN1cGVyZmx1b3VzIGluIE1BUC1FIA0KSW50ZXJmYWNlIElEcw0KDQoNCg0K DQoNCg0KSGksDQoNCnRoZSBJUHY0IGFuZCBQU0lEIGluIHRoZSBJSUQgYXJlIHBhcnRpY3VsYXJs eSB1c2VmdWwgaW4gY2FzZXMgb2YgYWRkcmVzcyANCmluZGVwZW5kZW5jZSAoaWUgMToxKS4gQXMg c2FpZCBwcmV2aW91c2x5LCB0aGUgYmVuZWZpdCBpcyBwcmltYXJpbHkgaW4gdGhlIA0KYWJpbGl0 eSBhbiBvcGVyYXRpb25hbCBmYWNpbGl0YXRpb24sIHdoZXJlIGFuIG9wZXJhdG9yIGNhbiBlYXNp bHkgDQpzZWUvb2JzZXJ2ZSB3aGF0IElQdjQgYW5kIFBTSUQgaXMgYmVpbmcgdXNlZCBieSBhIGdp dmVuIGN1c3RvbWVyLiBUaGlzIGlzIA0KZWFzaWVyIHRoYW4gdG8gbG9vayBhdCB0aGUgdjYgcHJl Zml4IGFuZCB1c2Ugc29tZSBtYWdpYyBkZWNvZGVyIHJpbmcuDQpJbiBhZGRpdGlvbiwgaXQgaGFz IHRoZSBkZXNpcmFibGUgY2hhcmFjdGVyaXN0aWMgb2YgY3JlYXRpbmcgYW4gSUlELg0KDQorMSBU aHVzIHRvIGtlZXBpbmcgdGhlIElQdjQgYW5kIFBTSUQsIGxpa2VseSBpbiBhIGZpeGVkIGxlbmd0 aCAoMTYgYml0KSANCmZpZWxkIGZvcm1hdC4NCg0KUmVnYXJkcywNCldvai4NCg0KT24gMjQgSmFu dWFyeSAyMDEzIDE2OjI3LCBPbGUgVHJvYW4gPG90cm9hbkBlbXBsb3llZXMub3JnPiB3cm90ZToN CmhpLA0KDQpjYW4gd2UgcGxlYXNlIGtlZXAgZGlzY3Vzc2lvbiBvbiB0aGUgbGlzdC4gbm90IHZp YSB0aGUgaXNzdWUgdHJhY2tlcj8NCg0KZG9lcyBhbnlvbmUgZWxzZSBoYXZlIGFuIG9waW5pb24/ DQooaWYgSSBkb24ndCBoZWFyIGFueXRoaW5nIGZyb20gYW55b25lIGVsc2UsIEknbGwgZGVmYXVs dCB0byBrZWVwIGN1cnJlbnQgDQp0ZXh0LikNCg0KY2hlZXJzLA0KT2xlDQoNCk9uIEphbiAyNCwg MjAxMywgYXQgMTc6MjMgLCBzb2Z0d2lyZSBpc3N1ZSB0cmFja2VyIDwNCnRyYWMrc29mdHdpcmVA dG9vbHMuaWV0Zi5vcmc+IHdyb3RlOg0KDQo+ICMxOTogSVB2NCBhZGRyZXNzIHN1cGVyZmx1b3Vz IGluIE1BUC1FIEludGVyZmFjZSBJRHMNCj4NCj4gQ2hhbmdlcyAoYnkgcmVtaS5kZXNwcmVzQGZy ZWUuZnIpOg0KPg0KPiAqIHByaW9yaXR5OiAgdHJpdmlhbCA9PiBtYWpvcg0KPiAqIHN0YXR1czog IGNsb3NlZCA9PiByZW9wZW5lZA0KPiAqIHJlc29sdXRpb246ICB3b250Zml4ID0+DQo+DQo+DQo+ IENvbW1lbnQ6DQo+DQo+IFZhbHVlIG9mIGhhdmluZyB0aGUgUFNJRCBpbiBNQVAtRSBJSURzIGZv ciBtYWludGVuYW5jZSBpc24ndCBjbGVhciBhdCANCmFsbDoNCj4gLSBQU0lEIGxlbmd0aCBpc24n dCBkZXRlcm1pbmVkIGluIElJRHMgKHRoZXJlIGNhbiBiZSBhbiB1bmtub3duIG51bWJlciANCm9m DQo+IHRyYWlsaW5nIHplcm9lcykNCj4gLSBhbGwgUFNJRCBiaXRzIGFyZSBhbHJlYWR5IHJlYWRh YmxlIGluIHRoZSBmaXJzdCA2NCBiaXRzDQo+DQo+IFN1Z2dlc3Rpb24gdG8gY2xvc2UgdGhlIGlz c3VlOg0KPiAtIGtlZXAgSVB2NCBhZGRyZXNzZXMgaW4gSUlEcyAodGhleSBjb250YWlucyBzb21l IGJpdHMgdGhhdCBhcmVuJ3QgaW4gDQp0aGUNCj4gZmlyc3QgNjQgYml0cykNCj4gLSBkb24ndCBr ZWVwIHRoZSBQU0lEIGluIElJRHMgKGluc3VmZmljaWVudGx5IGp1c3RpZmllZCBjb21wbGV4aXR5 KQ0KPg0KPiAtLQ0KPiANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBSZXBvcnRlcjogICAgICAgICAg ICAgICB8ICAgICAgIE93bmVyOiAgZHJhZnQtaWV0Zi1zb2Z0d2lyZS0NCj4gIHJlbWkuZGVzcHJl c0BmcmVlLmZyICAgfCAgbWFwQHRvb2xzLmlldGYub3JnDQo+ICAgICBUeXBlOiAgZGVmZWN0ICAg ICAgIHwgICAgICBTdGF0dXM6ICByZW9wZW5lZA0KPiBQcmlvcml0eTogIG1ham9yICAgICAgICB8 ICAgTWlsZXN0b25lOg0KPiBDb21wb25lbnQ6ICBtYXAtZSAgICAgICAgfCAgICAgVmVyc2lvbjoN Cj4gU2V2ZXJpdHk6ICBDYW5kaWRhdGUgICAgfCAgUmVzb2x1dGlvbjoNCj4gIFdHIERvY3VtZW50 ICAgICAgICAgICAgfA0KPiBLZXl3b3JkczogICAgICAgICAgICAgICB8DQo+IA0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQo+DQo+IFRpY2tldCBVUkw6IDwNCmh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3Jn L3dnL3NvZnR3aXJlL3RyYWMvdGlja2V0LzE5I2NvbW1lbnQ6ND4NCj4gc29mdHdpcmUgPGh0dHA6 Ly90b29scy5pZXRmLm9yZy9zb2Z0d2lyZS8+DQo+DQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpTb2Z0d2lyZXMgbWFpbGluZyBsaXN0DQpTb2Z0d2ly ZXNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc29mdHdp cmVzDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KU29m dHdpcmVzIG1haWxpbmcgbGlzdA0KU29mdHdpcmVzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NvZnR3aXJlcw0KDQoNCg== --=_alternative 000E6F9448257B02_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLDwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7IEtlZXBpbmcgUFNJRCBpbiBJ SURzIHNlZW1zIHJlcGVhdGVkDQpmcm9tIHRoZSBhc3BlY3Qgb2YgMTI4LWJpdCBJUHY2IGFkZHJl c3MsIGJ1dCBmcm9tIHRoZSBhc3BlY3Qgb2YgNjQtYml0DQpJSURzLCBJUHY0IGFkZHJlc3MgYW5k IFBTSUQgPC9mb250Pjx0dD48Zm9udCBzaXplPTI+Z3VhcmFudGVlIElJRHMgdG8gYmUNCnVuaXZl cnNhbGx5IHVuaXF1ZS48L2ZvbnQ+PC90dD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ IDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7 IFNvLCArMSBLZWVwaW5nIHRoZSBJUHY0IGFuZCBQU0lEDQppbiBJSURzLjwvZm9udD4NCjxicj4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QlJzPC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5MaW5kYSBXYW5nPC9mb250Pg0KPGJyPg0KPGJyPg0K PGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0 aD0zNiU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPldvamNpZWNoIERlYyAmbHQ7 d2RlYy5pZXRmQGdtYWlsLmNvbSZndDs8L2I+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPreivP7IyzogJm5ic3A7c29mdHdpcmVzLWJvdW5jZXNAaWV0Zi5vcmc8 L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAxMy0wMS0yOCAyMTo1 MTwvZm9udD4NCjx0ZCB3aWR0aD02MyU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249 dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij5PbGUgVHJvYW4gJmx0O290cm9hbkBlbXBsb3llZXMub3JnJmd0OzwvZm9udD4NCjx0ciB2YWxp Z249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+JnF1b3Q7c29mdHdpcmVzQGlldGYub3JnIFdHJnF1b3Q7ICZsdDtzb2Z0d2lyZXNAaWV0Zi5v cmcmZ3Q7LA0KcmVtaS5kZXNwcmVzQGZyZWUuZnI8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0 ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8 L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJlOiBbU29m dHdpcmVzXSBbc29mdHdpcmVdICMxOTogSVB2NA0KYWRkcmVzcyBzdXBlcmZsdW91cyBpbiBNQVAt RSBJbnRlcmZhY2UgSURzPC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWdu PXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+ PGZvbnQgc2l6ZT0zPkhpLDxicj4NCjxicj4NCnRoZSBJUHY0IGFuZCBQU0lEIGluIHRoZSBJSUQg YXJlIHBhcnRpY3VsYXJseSB1c2VmdWwgaW4gY2FzZXMgb2YgYWRkcmVzcw0KaW5kZXBlbmRlbmNl IChpZSAxOjEpLiBBcyBzYWlkIHByZXZpb3VzbHksIHRoZSBiZW5lZml0IGlzIHByaW1hcmlseSBp bg0KdGhlIGFiaWxpdHkgYW4gb3BlcmF0aW9uYWwgZmFjaWxpdGF0aW9uLCB3aGVyZSBhbiBvcGVy YXRvciBjYW4gZWFzaWx5IHNlZS9vYnNlcnZlDQp3aGF0IElQdjQgYW5kIFBTSUQgaXMgYmVpbmcg dXNlZCBieSBhIGdpdmVuIGN1c3RvbWVyLiBUaGlzIGlzIGVhc2llciB0aGFuDQp0byBsb29rIGF0 IHRoZSB2NiBwcmVmaXggYW5kIHVzZSBzb21lIG1hZ2ljIGRlY29kZXIgcmluZy48YnI+DQpJbiBh ZGRpdGlvbiwgaXQgaGFzIHRoZSBkZXNpcmFibGUgY2hhcmFjdGVyaXN0aWMgb2YgY3JlYXRpbmcg YW4gSUlELjxicj4NCjxicj4NCisxIFRodXMgdG8ga2VlcGluZyB0aGUgSVB2NCBhbmQgUFNJRCwg bGlrZWx5IGluIGEgZml4ZWQgbGVuZ3RoICgxNiBiaXQpDQpmaWVsZCBmb3JtYXQuPGJyPg0KPGJy Pg0KUmVnYXJkcyw8YnI+DQpXb2ouPGJyPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz5PbiAy NCBKYW51YXJ5IDIwMTMgMTY6MjcsIE9sZSBUcm9hbiAmbHQ7PC9mb250PjxhIGhyZWY9bWFpbHRv Om90cm9hbkBlbXBsb3llZXMub3JnIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0zIGNvbG9yPWJs dWU+PHU+b3Ryb2FuQGVtcGxveWVlcy5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTM+Jmd0 Ow0Kd3JvdGU6PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz5oaSw8YnI+DQo8YnI+DQpjYW4gd2Ug cGxlYXNlIGtlZXAgZGlzY3Vzc2lvbiBvbiB0aGUgbGlzdC4gbm90IHZpYSB0aGUgaXNzdWUgdHJh Y2tlcj88YnI+DQo8YnI+DQpkb2VzIGFueW9uZSBlbHNlIGhhdmUgYW4gb3Bpbmlvbj88YnI+DQoo aWYgSSBkb24ndCBoZWFyIGFueXRoaW5nIGZyb20gYW55b25lIGVsc2UsIEknbGwgZGVmYXVsdCB0 byBrZWVwIGN1cnJlbnQNCnRleHQuKTxicj4NCjxicj4NCmNoZWVycyw8YnI+DQpPbGU8YnI+DQo8 YnI+DQpPbiBKYW4gMjQsIDIwMTMsIGF0IDE3OjIzICwgc29mdHdpcmUgaXNzdWUgdHJhY2tlciAm bHQ7PC9mb250PjxhIGhyZWY9bWFpbHRvOnRyYWMlMkJzb2Z0d2lyZUB0b29scy5pZXRmLm9yZz48 Zm9udCBzaXplPTMgY29sb3I9Ymx1ZT48dT50cmFjK3NvZnR3aXJlQHRvb2xzLmlldGYub3JnPC91 PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zPiZndDsNCndyb3RlOjxicj4NCjxicj4NCiZndDsgIzE5 OiBJUHY0IGFkZHJlc3Mgc3VwZXJmbHVvdXMgaW4gTUFQLUUgSW50ZXJmYWNlIElEczxicj4NCiZn dDs8YnI+DQomZ3Q7IENoYW5nZXMgKGJ5IDwvZm9udD48YSBocmVmPW1haWx0bzpyZW1pLmRlc3By ZXNAZnJlZS5mcj48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZT48dT5yZW1pLmRlc3ByZXNAZnJlZS5m cjwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9Mz4pOjxicj4NCiZndDs8YnI+DQomZ3Q7ICogcHJp b3JpdHk6ICZuYnNwO3RyaXZpYWwgPSZndDsgbWFqb3I8YnI+DQomZ3Q7ICogc3RhdHVzOiAmbmJz cDtjbG9zZWQgPSZndDsgcmVvcGVuZWQ8YnI+DQomZ3Q7ICogcmVzb2x1dGlvbjogJm5ic3A7d29u dGZpeCA9Jmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBDb21tZW50Ojxicj4NCiZn dDs8YnI+DQomZ3Q7IFZhbHVlIG9mIGhhdmluZyB0aGUgUFNJRCBpbiBNQVAtRSBJSURzIGZvciBt YWludGVuYW5jZSBpc24ndCBjbGVhcg0KYXQgYWxsOjxicj4NCiZndDsgLSBQU0lEIGxlbmd0aCBp c24ndCBkZXRlcm1pbmVkIGluIElJRHMgKHRoZXJlIGNhbiBiZSBhbiB1bmtub3duIG51bWJlcg0K b2Y8YnI+DQomZ3Q7IHRyYWlsaW5nIHplcm9lcyk8YnI+DQomZ3Q7IC0gYWxsIFBTSUQgYml0cyBh cmUgYWxyZWFkeSByZWFkYWJsZSBpbiB0aGUgZmlyc3QgNjQgYml0czxicj4NCiZndDs8YnI+DQom Z3Q7IFN1Z2dlc3Rpb24gdG8gY2xvc2UgdGhlIGlzc3VlOjxicj4NCiZndDsgLSBrZWVwIElQdjQg YWRkcmVzc2VzIGluIElJRHMgKHRoZXkgY29udGFpbnMgc29tZSBiaXRzIHRoYXQgYXJlbid0DQpp biB0aGU8YnI+DQomZ3Q7IGZpcnN0IDY0IGJpdHMpPGJyPg0KJmd0OyAtIGRvbid0IGtlZXAgdGhl IFBTSUQgaW4gSUlEcyAoaW5zdWZmaWNpZW50bHkganVzdGlmaWVkIGNvbXBsZXhpdHkpPGJyPg0K Jmd0Ozxicj4NCiZndDsgLS08YnI+DQomZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDsg UmVwb3J0ZXI6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyB8ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyBPd25lcjogJm5ic3A7ZHJhZnQtaWV0Zi1zb2Z0d2ly ZS08YnI+DQomZ3Q7ICZuYnNwOzwvZm9udD48YSBocmVmPW1haWx0bzpyZW1pLmRlc3ByZXNAZnJl ZS5mcj48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZT48dT5yZW1pLmRlc3ByZXNAZnJlZS5mcjwvdT48 L2ZvbnQ+PC9hPjxmb250IHNpemU9Mz4NCiZuYnNwOyB8ICZuYnNwOzwvZm9udD48YSBocmVmPW1h aWx0bzptYXBAdG9vbHMuaWV0Zi5vcmc+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWU+PHU+bWFwQHRv b2xzLmlldGYub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zPjxicj4NCiZndDsgJm5ic3A7 ICZuYnNwOyBUeXBlOiAmbmJzcDtkZWZlY3QgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDsg Jm5ic3A7DQombmJzcDtTdGF0dXM6ICZuYnNwO3Jlb3BlbmVkPGJyPg0KJmd0OyBQcmlvcml0eTog Jm5ic3A7bWFqb3IgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCAmbmJzcDsgTWlsZXN0b25l Ojxicj4NCiZndDsgQ29tcG9uZW50OiAmbmJzcDttYXAtZSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDt8ICZuYnNwOyAmbmJzcDsNClZlcnNpb246PGJyPg0KJmd0OyBTZXZlcml0eTogJm5ic3A7 Q2FuZGlkYXRlICZuYnNwOyAmbmJzcDt8ICZuYnNwO1Jlc29sdXRpb246PGJyPg0KJmd0OyAmbmJz cDtXRyBEb2N1bWVudCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3w8 YnI+DQomZ3Q7IEtleXdvcmRzOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgfDxicj4NCiZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0Ozxicj4N CiZndDsgVGlja2V0IFVSTDogJmx0OzwvZm9udD48YSBocmVmPWh0dHA6Ly90cmFjLnRvb2xzLmll dGYub3JnL3dnL3NvZnR3aXJlL3RyYWMvdGlja2V0LzE5I2NvbW1lbnQ6NCB0YXJnZXQ9X2JsYW5r Pjxmb250IHNpemU9MyBjb2xvcj1ibHVlPjx1Pmh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dn L3NvZnR3aXJlL3RyYWMvdGlja2V0LzE5I2NvbW1lbnQ6NDwvdT48L2ZvbnQ+PC9hPjxmb250IHNp emU9Mz4mZ3Q7PGJyPg0KJmd0OyBzb2Z0d2lyZSAmbHQ7PC9mb250PjxhIGhyZWY9aHR0cDovL3Rv b2xzLmlldGYub3JnL3NvZnR3aXJlLyB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MyBjb2xvcj1i bHVlPjx1Pmh0dHA6Ly90b29scy5pZXRmLm9yZy9zb2Z0d2lyZS88L3U+PC9mb250PjwvYT48Zm9u dCBzaXplPTM+Jmd0Ozxicj4NCiZndDs8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NClNvZnR3aXJlcyBtYWlsaW5nIGxpc3Q8L2Zv bnQ+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWU+PHU+PGJyPg0KPC91PjwvZm9udD48YSBocmVmPW1h aWx0bzpTb2Z0d2lyZXNAaWV0Zi5vcmc+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWU+PHU+U29mdHdp cmVzQGlldGYub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWU+PHU+PGJy Pg0KPC91PjwvZm9udD48YSBocmVmPWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc29mdHdpcmVzIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWU+PHU+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zb2Z0d2lyZXM8L3U+PC9mb250Pjwv YT4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPg0KU29mdHdpcmVzIG1haWxpbmcgbGlzdDxicj4NClNvZnR3aXJl c0BpZXRmLm9yZzxicj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc29m dHdpcmVzPGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+DQo= --=_alternative 000E6F9448257B02_=-- From ssenthil@cisco.com Mon Jan 28 18:50:02 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA56021E8049 for ; Mon, 28 Jan 2013 18:50:01 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XBLe8-8cPPUa for ; Mon, 28 Jan 2013 18:50:01 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 29E7221E8042 for ; Mon, 28 Jan 2013 18:50:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2955; q=dns/txt; s=iport; t=1359427801; x=1360637401; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=pSPuP4gQ/jzabuJeLaMDJe9WKIXCBr88ghr09zLba04=; b=IN4Eb02+gEaeD9sBL7FjJRAyZXaMlL2yM5YANp0I+8YRRGiIJretfsyV qOASouhFbJNqVyV2foR+P6+zw3kYuzSB9hsZ3qLTN4juFxsBCf8geo67M vemUg7n2iu9rtO91HhFO1Q8+qtGKjEi3rjvr84GqBHmbl92s5Tj4EU0R3 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EANY3B1GtJV2a/2dsb2JhbABEvloWc4IgAQR5EgEIDhRWJQIEDgUIiAmwRpARkCRhA4gsnimCag2CJA X-IronPort-AV: E=Sophos;i="4.84,555,1355097600"; d="scan'208";a="166567513" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP; 29 Jan 2013 02:50:00 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r0T2o0E4019996 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Jan 2013 02:50:00 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.248]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Mon, 28 Jan 2013 20:50:00 -0600 From: "Senthil Sivakumar (ssenthil)" To: Ole Troan Thread-Topic: [Softwires] Limiting the length of the MAP endpoint IPv6 prefix Thread-Index: AQHN/NrF2B0aLU6sVE2EGmWvbGzXKphe3eoAgABJpwCAAALGAP//swcAgABzLQD//7HBgIAAaj+AgABBKQA= Date: Tue, 29 Jan 2013 02:49:59 +0000 Message-ID: In-Reply-To: <2928CE6C-CF5B-4410-BDA4-B32E4D7C7917@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.117.198.136] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <01F6EA8974BCF54BA4593AEE2B899E07@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Softwires Subject: Re: [Softwires] Limiting the length of the MAP endpoint IPv6 prefix X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 02:50:02 -0000 On 1/28/13 12:56 PM, "Ole Troan" wrote: >Senthil, > >[...] > >>> The draft says that: >>> (a) The PSID is: >>> +--+---+---+---+---+---+---+---+---+ >>> |PL| 8 16 24 32 40 48 56 | >>> +--+---+---+---+---+---+---+---+---+ >>> |64| u | IPv4 address | PSID | 0 | >>> +--+---+---+---+---+---+---+---+---+ >>=20 >> I believe this figure is misleading by placing the IPv4 address in a >>fixed >> location. Figure 3 and Figure 7 >> In the draft shows that the IID is not in a fixed location. Also, the >>text >> surrounding the above figure 8, says >> "The Interface identifier format of a MAP node is based on the format >> specified in section 2.2 of [RFC6052], with the added PSID field if >> present, as shown in figure Figure 8." >>=20 >>=20 >> But RFC 6052 doesn=B9t have the IPv4 address in a fixed location as per >> section 2.2. So I think this figure is misleading. > >perhaps we should just remove the RFC6052 reference then? >with a 48 bits of PSID + IPv4 address. >I don't mind if it is just IPv4 address, but then someone need to drive >that discussion. I think the above figure should be clarified as an example when the prefix-length+EA <=3D 64. If the prefix length is greater than 64, the IPv4 address appears after the prefix length and U bits are overwritten. If we clarify the above two points and remove the reference to rfc6052, that would be fine. Thanks Senthil > >> | n bits | o bits | s bits | 128-n-o-s bits | >> +--------------------+-----------+---------+------------+----------+ >> | Rule IPv6 prefix | EA bits |subnet ID| interface ID | >> +--------------------+-----------+---------+-----------------------+ >>=20 >>=20 >>> (b) "If the End-user IPv6 prefix length is larger than 64, the most >>> significant parts of the interface identifier is overwritten by the >>> prefix." >>>=20 >>> This is particularly unclear: >>=20 >> True. >>> - What happens to the u octet? >>=20 >> I guess that needs to be made clear in the draft. We struggled with that >> in our implementation. > >if we remove the 6052 reference, there is no u-octet. > >>> - And to the IPv4 address if the prefix is longer than /68? >>> - ... >>>=20 >>> Of course, if a use case is provided where MAP-E would be actually used >>> with an IID shorter than 64 bits, it should be discussed. But: >>> - There is no such use case so far. >>> - Looking for one doesn't seem useful. >>=20 >> I would like to see the IPv4 address be present from bits 96-127, no >>need >> for the PSID to be repeated again. That would allow us to go upto /96 >>and >> being consistent with RFC 6052 which allows one to configure a prefix of >> upto /96. > >just put the IPv4 address in the bottom bits, and allow it to be >overwritten by the prefix. >it is just there for 'pretty printing' anyway. > >cheers, >Ole From tom.taylor.stds@gmail.com Mon Jan 28 20:32:10 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBAE821E8087 for ; Mon, 28 Jan 2013 20:32:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.399 X-Spam-Level: X-Spam-Status: No, score=-0.399 tagged_above=-999 required=5 tests=[AWL=-0.447, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WpoJtn2ss34A for ; Mon, 28 Jan 2013 20:32:10 -0800 (PST) Received: from mail-ia0-x22a.google.com (ia-in-x022a.1e100.net [IPv6:2607:f8b0:4001:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 60E3721E8083 for ; Mon, 28 Jan 2013 20:32:10 -0800 (PST) Received: by mail-ia0-f170.google.com with SMTP id k20so34512iak.15 for ; Mon, 28 Jan 2013 20:32:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding:x-antivirus :x-antivirus-status; bh=SMJ4tEjTQWJKiSW1lvpmkO9dfp2K1WEpjOGbfnqNBhc=; b=T6uFqxgI5wuB2qYBEgdBG++Dspz2Qnlg0ewOsX1yPgefDG11knlR+dxBPXrqWLIf+J /VlDrCZc7NEIJrgM5fCLwdxyaoJNBVcz5AF2dW03A22xHpVhaW0zUX1wCrXOEH4K5EXA NW0OhGfdHIBYCZ/OW9a9FbLWIF3MP2OGmgYHx2TnJ5sVUdGAiwcvetVKu4qCcFfDau4r sh6Lrn/XK7UtzJOkmaXvi07GnMPhvkGg8+DXdzSHTxvAQCe8y5qiPoRKX4ZRfAUKG3/p 39S3V5vTmL8kcFhYahXtPpVBANyFmGJzYfN+o0RXx764lOlZTy/DkOD6HLtleTeQWkwQ AFyg== X-Received: by 10.50.150.135 with SMTP id ui7mr131282igb.55.1359433929863; Mon, 28 Jan 2013 20:32:09 -0800 (PST) Received: from [127.0.0.1] (dsl-173-206-87-33.tor.primus.ca. [173.206.87.33]) by mx.google.com with ESMTPS id hg2sm940481igc.3.2013.01.28.20.32.08 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Jan 2013 20:32:09 -0800 (PST) Message-ID: <510750C7.2010804@gmail.com> Date: Mon, 28 Jan 2013 23:32:07 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Softwires Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130128-0, 28/01/2013), Outbound message X-Antivirus-Status: Clean Subject: [Softwires] draft-cui-softwire-b4-translated-ds-lite and MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 04:32:11 -0000 I figured it was time to pick on someone else, so I reviewed draft-cui-softwire-b4-translated-ds-lite. I found it really easy to understand, and all I found to change was a couple of typos. Of course, one reason lw4o6 easier to read than MAP is because it does not describe a port mapping algorithm. The other reason is because the MAP document has to describe the EA bits and their use. But that's a fundamental difference between the two approaches, and I can't see much chance to simplify MAP. The only possibility is to change the provisioning approach to provision the Rule IPv6 prefix, the complete shared IPv4 address, and the PSID explicitly, then describe how to construct the MAP endpoint IPv6 address. Getting back to draft-cui-softwire-b4-translated-ds-lite, I'd say it's ready to be adopted. Tom Taylor From sunqi.csnet.thu@gmail.com Mon Jan 28 21:29:18 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A673D21E808F for ; Mon, 28 Jan 2013 21:29:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hp19HEsMygym for ; Mon, 28 Jan 2013 21:29:18 -0800 (PST) Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com [209.85.220.48]) by ietfa.amsl.com (Postfix) with ESMTP id 13C3321E8083 for ; Mon, 28 Jan 2013 21:29:18 -0800 (PST) Received: by mail-pa0-f48.google.com with SMTP id fa1so162154pad.35 for ; Mon, 28 Jan 2013 21:29:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=RUyD1GGdZ9cEk8BHCSUuLWyj1c5ODeyjo96thtsrw1c=; b=jcctrvy74fgVaBhBdkxJ63oXwrYDKF1IVuAdATjZBAwRwc4LPczAiaWBI/nEZz1ShH Jry/wUYyNFbAKTAb5E1gltQfWS8v+U9JWVAyjEhITEZ7CIL6a+WCRhyVlCuqTnTFe+Ly 9ntlLKNEDac/SB8CePPX0Brxm7DAgFYDK1frxJpsLlbetwHap/WKP2SnyNnqf/eNxpyN u7An1fIQSAkqoz95jkQbQ2VoL6ezZrE4+ymSsPAuRollCIF3BCEoCW6FzgX5dIA8auv6 VHl39GeIKljWyRLFQPg9bcyobgoFKX2V5JbLYsHeUg+RdrUwLSfrhKG2J7ViZN3xkhNp wRMQ== X-Received: by 10.68.227.33 with SMTP id rx1mr887503pbc.67.1359437357826; Mon, 28 Jan 2013 21:29:17 -0800 (PST) Received: from [10.1.1.121] ([219.243.220.10]) by mx.google.com with ESMTPS id bi2sm8190472pab.18.2013.01.28.21.28.57 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Jan 2013 21:29:17 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=utf-8 From: Qi Sun In-Reply-To: <510750C7.2010804@gmail.com> Date: Tue, 29 Jan 2013 13:28:55 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <510750C7.2010804@gmail.com> To: Tom Taylor X-Mailer: Apple Mail (2.1084) Cc: Softwires Subject: Re: [Softwires] draft-cui-softwire-b4-translated-ds-lite and MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 05:29:18 -0000 Dear Tom & all, IMHO, in addition to Tom's points, = draft-cui-softwire-b4-translated-ds-lite is easier for OAM because there = is no port mapping algorithm. It does not require operators to plan IPv6 = and IPv4 address pool together, which is convenient for operators whose = IPv4 address pools are scattered, or IPv4/IPv6 address resources are = managed by different servers.=20 Also, I think draft-cui-* is ready to move forward. Best Regards, Qi Sun On 2013-1-29, at =E4=B8=8B=E5=8D=8812:32, Tom Taylor wrote: > I figured it was time to pick on someone else, so I reviewed = draft-cui-softwire-b4-translated-ds-lite. I found it really easy to = understand, and all I found to change was a couple of typos. >=20 > Of course, one reason lw4o6 easier to read than MAP is because it does = not describe a port mapping algorithm. The other reason is because the = MAP document has to describe the EA bits and their use. But that's a = fundamental difference between the two approaches, and I can't see much = chance to simplify MAP. The only possibility is to change the = provisioning approach to provision the Rule IPv6 prefix, the complete = shared IPv4 address, and the PSID explicitly, then describe how to = construct the MAP endpoint IPv6 address. >=20 > Getting back to draft-cui-softwire-b4-translated-ds-lite, I'd say it's = ready to be adopted. >=20 > Tom Taylor > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From sunqi.csnet.thu@gmail.com Mon Jan 28 21:54:36 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C08E021F8696 for ; Mon, 28 Jan 2013 21:54:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iiGAGCH1Q+K5 for ; Mon, 28 Jan 2013 21:54:36 -0800 (PST) Received: from mail-pa0-f51.google.com (mail-pa0-f51.google.com [209.85.220.51]) by ietfa.amsl.com (Postfix) with ESMTP id 1237321F85B2 for ; Mon, 28 Jan 2013 21:54:36 -0800 (PST) Received: by mail-pa0-f51.google.com with SMTP id fb11so177887pad.10 for ; Mon, 28 Jan 2013 21:54:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=p5WMiBsTgbA/cETPaj4bsJy+Bf8WnEoqFfxxnx6wpws=; b=V5aNQ2Q6DDtP4Z8OdCLO18ecc+Nv/9B0u1Qpn0gUcG58M3qk5IfKyPd7nd23+XQGFf 2SUa3p7a0E83EeWQZplAMFnlhMMj2l0N1qSeeCvHm3HHDwmX0CZY1LbgjGnKukwtbgP8 YmknLtdwEcaQ2AhmE/AZCjqXcKn9hujO37kNqnoRPmE1Um6vJ3I3JPfL6mShSU5RKtdy AKg9gPlWF4X3NxS1d3G6AnjoXyyvaVHMU6x3JGpkZot/11EVJXUpN7U5Q+utVZkW3iT0 8SjA29yvnC+yIvWAN+m3JV3RKjsGPdlse3f3jWUcLpJUoJsUGhW3XNUcMKO6uDoUvpfz 8eSQ== X-Received: by 10.66.81.231 with SMTP id d7mr2150787pay.27.1359438875785; Mon, 28 Jan 2013 21:54:35 -0800 (PST) Received: from [10.1.1.121] ([219.243.220.10]) by mx.google.com with ESMTPS id d8sm8232644pax.23.2013.01.28.21.54.30 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Jan 2013 21:54:35 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=utf-8 From: Qi Sun In-Reply-To: <5106AE69.80705@gmail.com> Date: Tue, 29 Jan 2013 13:54:27 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5106AE69.80705@gmail.com> To: Tom Taylor X-Mailer: Apple Mail (2.1084) Cc: Softwires Subject: Re: [Softwires] Section 5.1 of the MAP draft X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 05:54:36 -0000 Dear Tom, IMHO, these are valuable comments. However, I'm kind of lost on this = part: > A Indexes the blocks of port numbers. The lowest block number > (A =3D 0) and possibly others contain the system port numbers, > and hence should not be used if port numbers 0-1023 are to > be avoided. >=20 > a Width of the field containing the block index A. Indirectly > a determines the block size, by the formula: > Block size =3D 65536 / 2^a I'm not sure of the meaning of 'Block size', which is equal to 2^(k+m). = As I interpret, each CE can get 2^(a+m) ports and each port range is = 2^m. What can we use the 'Block size' for? Thanks in advance! Best Regards, Qi Sun On 2013-1-29, at =E4=B8=8A=E5=8D=8812:59, Tom Taylor wrote: > I made some editorial comments about Section 5.1 the other day. I have = a substantive comment now, and a text proposal to pull it all together. >=20 > Comment: the statement >=20 > "For a =3D 0, A MAY be 0 to > allow for the provisioning of the system ports." >=20 > just below Figure 2 is illogical, since if a =3D 0, the value A does = not exist. In fact, a =3D 0 returns us to the naive approach in the = second paragraph of Section 5.1. Hence I propose alternative text for = the section. Note two changes to Figure 2: removed extra bit 16 and = changed the title. >=20 >=20 > Proposed text: >=20 > 5.1. Port Mapping Algorithm >=20 > The port mapping algorithm is used to represent the port numbers = allocated to a given CE if the CE has been given a shared IPv4 address. >=20 > The simplest way to allocate ports is to allocate one range of = consecutive ports to each CE sharing an address. The Port-Set Identifier = (PSID) is an index over the sequence of allocated ranges, starting from = zero. In this case, assuming that the number of port numbers in each = allocated range is a power of 2, the set of port numbers allocated to a = given CE can be represented using a notation similar to CIDR [RFC4632], = but with 16 bits instead of 32. For example, assuming a range size of = 256 port numbers, the first 256 ports are > represented as port prefix 0.0/8, the last 256 ports as 255.0/8. In > hexadecimal, 0x0000/8 (PSID =3D 0) and 0xFF00/8 (PSID =3D 0xFF). >=20 > It can be seen from the example that the lowest PSID values allocate = ports in the system port range [I-D.ietf-tsvwg-iana-ports] to one or = more CEs. To avoid this, the lowest PSID values (0x00 to 0x03 in the = example) should not be used. >=20 > A more sophisticated approach allocates ports in a series of blocks, = where each CE sharing an address receives one range from each block. = This can be represented as shown in Figure 2. >=20 > 0 1 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > +-------+-----------+----------+ > Ports in | A | PSID | M | > the CE port set | > 0 | |any value | > +-------+-----------+----------+ > |a bits | k bits | m bits | >=20 > Figure 2: Three-Part Decomposition of Allocated Port Numbers >=20 > A Indexes the blocks of port numbers. The lowest block number > (A =3D 0) and possibly others contain the system port numbers, > and hence should not be used if port numbers 0-1023 are to > be avoided. >=20 > a Width of the field containing the block index A. Indirectly > a determines the block size, by the formula: > Block size =3D 65536 / 2^a >=20 > a =3D 0 brings us back to the simple (single block) model > described above, where the PSID value rather than the value > of A must be restricted to avoid the system ports. The value > of a is optionally provisioned as part of the mapping rule. > The default value for a is 4, to place the start of the PSID > on a nibble boundary. This leaves ports in the range 0-4095 > unallocated. >=20 > PSID Indexes the position of the allocated range for a given CE > within each block. In the more general model, where A > 0, > PSID values can begin at 0 without causing system ports to > be allocated. >=20 > k Width of the field containing the PSID. The number of CEs > sharing the same IPv4 address is given by 2^k, except when > a =3D 0 and the lowest PSID values are excluded. >=20 > M Indexes a specific port number within a range determined by > the values of A and the PSID. >=20 > m Width of the port index field. The number of ports in each > allocated range is given by 2^m. > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From sunqi.csnet.thu@gmail.com Mon Jan 28 22:01:08 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F11D21F879D for ; Mon, 28 Jan 2013 22:01:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BIjOXgI3CO79 for ; Mon, 28 Jan 2013 22:01:07 -0800 (PST) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by ietfa.amsl.com (Postfix) with ESMTP id 7475E21F879A for ; Mon, 28 Jan 2013 22:01:07 -0800 (PST) Received: by mail-pb0-f54.google.com with SMTP id rr4so63469pbb.41 for ; Mon, 28 Jan 2013 22:01:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:message-id:references:to:x-mailer; bh=M/y0bdCTcjEOT0IZGHjXx/pBxOk7uJ5e5FB2Kvhm21Q=; b=AsDhAFHHqRo697C5VqRHBSgV85kSA+6fbfOisE8xeP+FKtdLXAoApRYa3q4vqvuucW v43zxYcGAqJAYe99cFFR5oYiKhv2+o+1TAhZbXzfXMFz/YmpOox9LIXfPATX+GRTzb77 YjUImOIvdnnrfidEDbshA8FH2wf+egw1GurM9oIE68AvOo9C3tUekN6Crz9FXaRF1CKu XD/GALvD53qRwOHdiFUCWVtHox0t8IWmHe4vr8jao0yalksV87UXeIBjJZYFIVgV3a5X 8RqJ1SdSG/+t4X5R6BppQzEUzxLC3RCS4j/Akwhz0qhxkpbODNfu/4ywsgklF2oQ14N7 CIUA== X-Received: by 10.68.132.232 with SMTP id ox8mr1122559pbb.46.1359439267270; Mon, 28 Jan 2013 22:01:07 -0800 (PST) Received: from [10.1.1.121] ([219.243.220.10]) by mx.google.com with ESMTPS id ua10sm3935223pbc.68.2013.01.28.22.00.58 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Jan 2013 22:01:06 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-1-1027450565 From: Qi Sun In-Reply-To: Date: Tue, 29 Jan 2013 14:00:56 +0800 Message-Id: <56493EE7-F585-460B-A07F-774165D63763@gmail.com> References: <063.9dc31682f59256171b5d58fdb1cdcc5e@tools.ietf.org> <078.5016b38f0fa45b1e08acdf73cc564147@tools.ietf.org> To: Wojciech Dec X-Mailer: Apple Mail (2.1084) Cc: "softwires@ietf.org WG" , remi.despres@free.fr Subject: Re: [Softwires] [softwire] #19: IPv4 address superfluous in MAP-E Interface IDs X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 06:01:08 -0000 --Apple-Mail-1-1027450565 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Woj , > the IPv4 and PSID in the IID are particularly useful in cases of = address independence (ie 1:1).=20 Now that IPv4 and PSID is put in the IPv6 address, why is it a case of = address independence? Best Regards, Qi Sun On 2013-1-28, at =E4=B8=8B=E5=8D=889:51, Wojciech Dec wrote: > Hi, >=20 > the IPv4 and PSID in the IID are particularly useful in cases of = address independence (ie 1:1). As said previously, the benefit is = primarily in the ability an operational facilitation, where an operator = can easily see/observe what IPv4 and PSID is being used by a given = customer. This is easier than to look at the v6 prefix and use some = magic decoder ring. > In addition, it has the desirable characteristic of creating an IID. >=20 > +1 Thus to keeping the IPv4 and PSID, likely in a fixed length (16 = bit) field format. >=20 > Regards, > Woj. >=20 > On 24 January 2013 16:27, Ole Troan wrote: > hi, >=20 > can we please keep discussion on the list. not via the issue tracker? >=20 > does anyone else have an opinion? > (if I don't hear anything from anyone else, I'll default to keep = current text.) >=20 > cheers, > Ole >=20 > On Jan 24, 2013, at 17:23 , softwire issue tracker = wrote: >=20 > > #19: IPv4 address superfluous in MAP-E Interface IDs > > > > Changes (by remi.despres@free.fr): > > > > * priority: trivial =3D> major > > * status: closed =3D> reopened > > * resolution: wontfix =3D> > > > > > > Comment: > > > > Value of having the PSID in MAP-E IIDs for maintenance isn't clear = at all: > > - PSID length isn't determined in IIDs (there can be an unknown = number of > > trailing zeroes) > > - all PSID bits are already readable in the first 64 bits > > > > Suggestion to close the issue: > > - keep IPv4 addresses in IIDs (they contains some bits that aren't = in the > > first 64 bits) > > - don't keep the PSID in IIDs (insufficiently justified complexity) > > > > -- > > = -------------------------+------------------------------------------------= - > > Reporter: | Owner: draft-ietf-softwire- > > remi.despres@free.fr | map@tools.ietf.org > > Type: defect | Status: reopened > > Priority: major | Milestone: > > Component: map-e | Version: > > Severity: Candidate | Resolution: > > WG Document | > > Keywords: | > > = -------------------------+------------------------------------------------= - > > > > Ticket URL: = > > softwire > > >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires --Apple-Mail-1-1027450565 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Woj = ,

the IPv4 and PSID = in the IID are particularly useful in cases of address independence (ie = 1:1). 

Now that IPv4 and PSID is put in = the IPv6 address, why is it a case of address = independence?


Best = Regards,
Qi = Sun
On 2013-1-28, at =E4=B8=8B=E5=8D=889:51, Wojciech Dec = wrote:

Hi,

the IPv4 and PSID in the IID are particularly = useful in cases of address independence (ie 1:1). As said previously, = the benefit is primarily in the ability an operational facilitation, = where an operator can easily see/observe what IPv4 and PSID is being = used by a given customer. This is easier than to look at the v6 prefix = and use some magic decoder ring.
In addition, it has the desirable characteristic of creating an = IID.

+1 Thus to keeping the IPv4 and PSID, likely in a fixed = length (16 bit) field format.

Regards,
Woj.

On 24 January 2013 16:27, Ole Troan <otroan@employees.org> wrote:
hi,

can we please keep discussion on the list. not via the issue = tracker?

does anyone else have an opinion?
(if I don't hear anything from anyone else, I'll default to keep current = text.)

cheers,
Ole

On Jan 24, 2013, at 17:23 , softwire issue tracker <trac+softwire@tools.ietf.or= g> wrote:

> #19: IPv4 address superfluous in MAP-E Interface IDs
>
> Changes (by remi.despres@free.fr):
>
> * priority:  trivial =3D> major
> * status:  closed =3D> reopened
> * resolution:  wontfix =3D>
>
>
> Comment:
>
> Value of having the PSID in MAP-E IIDs for maintenance isn't clear = at all:
> - PSID length isn't determined in IIDs (there can be an unknown = number of
> trailing zeroes)
> - all PSID bits are already readable in the first 64 bits
>
> Suggestion to close the issue:
> - keep IPv4 addresses in IIDs (they contains some bits that aren't = in the
> first 64 bits)
> - don't keep the PSID in IIDs (insufficiently justified = complexity)
>
> --
> = -------------------------+------------------------------------------------= -
> Reporter:               |   =     Owner:  draft-ietf-softwire-
>  remi.despres@free.fr   | =  map@tools.ietf.org
>     Type:  defect       |   =    Status:  reopened
> Priority:  major        |   = Milestone:
> Component:  map-e        |     = Version:
> Severity:  Candidate    |  Resolution:
>  WG Document            |
> Keywords:               |
> = -------------------------+------------------------------------------------= -
>
> Ticket URL: <http://trac.tools.ietf.org/wg/softwire/trac/ticket/19#co= mment:4>
> softwire <http://tools.ietf.org/softwire/>
>

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

_______________________________________________
Softwires mailing = list
Softwires@ietf.org
https://www.i= etf.org/mailman/listinfo/softwires

= --Apple-Mail-1-1027450565-- From wang.cui1@zte.com.cn Mon Jan 28 22:54:56 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF7821F8A74; Mon, 28 Jan 2013 22:54:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.445 X-Spam-Level: X-Spam-Status: No, score=-94.445 tagged_above=-999 required=5 tests=[AWL=3.309, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fxBaBYbvxGBu; Mon, 28 Jan 2013 22:54:55 -0800 (PST) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id A47A221F8A6F; Mon, 28 Jan 2013 22:54:54 -0800 (PST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 16C24A78350; Tue, 29 Jan 2013 14:56:02 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id r0T6sUE8074330; Tue, 29 Jan 2013 14:54:30 +0800 (GMT-8) (envelope-from wang.cui1@zte.com.cn) In-Reply-To: <3466C6E7-9778-4D8A-9828-0D127FB46C1D@laposte.net> To: =?GB2312?B?UqimbWkgRGVzcHKopnM=?= MIME-Version: 1.0 X-KeepSent: 5A63D8EE:DC98DF90-48257B02:0025B71B; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: wang.cui1@zte.com.cn Date: Tue, 29 Jan 2013 14:54:30 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2013-01-29 14:54:27, Serialize complete at 2013-01-29 14:54:27 Content-Type: multipart/alternative; boundary="=_alternative 0025EAF348257B02_=" X-MAIL: mse01.zte.com.cn r0T6sUE8074330 Cc: Softwires , softwires-bounces@ietf.org Subject: [Softwires] =?gb2312?b?tPC4tDogUmU6ICBMaW1pdGluZyB0aGUgbGVuZ3Ro?= =?gb2312?b?IG9mIHRoZSBNQVAgZW5kcG9pbnQgSVB2NiBwcmVmaXg=?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 06:54:56 -0000 This is a multipart message in MIME format. --=_alternative 0025EAF348257B02_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGksUmVtaQ0KIA0KDQpzb2Z0d2lyZXMtYm91bmNlc0BpZXRmLm9yZyDlhpnkuo4gMjAxMy0wMS0y OSAwMDoxNjozMjoNCg0KPiBTZW50aGlsLA0KPiANCj4gDQo+IDIwMTMtMDEtMjgxNToyNCwgU2Vu dGhpbCBTaXZha3VtYXIgKHNzZW50aGlsKSA8c3NlbnRoaWxAY2lzY28uY29tPiAgOg0KPiANCj4g PiBJIGJlbGlldmUgdGhlIHByZWZpeCBsZW5ndGggPiA2NCBzaG91bGQgYmUgYWxsb3dlZC4NCj4g DQo+IA0KPiA+IEl0IGlzIHVwdG8gdGhlDQo+ID4gb3BlcmF0b3IgdG8gY2hvb3NlIHRoZSBwcmVm aXggbGVuZ3RoIG9mIHRoZWlyIGNob2ljZS4NCj4gDQo+IEFncmVlZC4NCj4gTm8gb25lIHN1Z2dl c3QgdG8gc2F5IHRoZSBjb250cmFyeS4NCj4gDQo+IFlldCwgb3BlcmF0b3JzIGhhdmUgdGhlIGNv bnN0cmFpbnQgb2YgUkZDIDQyOTEgdGhhdCAiRm9yIGFsbCB1bmljYXN0DQo+IGFkZHJlc3Nlcywg ZXhjZXB0IHRob3NlIHRoYXQgc3RhcnQgd2l0aCB0aGUgYmluYXJ5IHZhbHVlIDAwMCwgDQo+IElu dGVyZmFjZSBJRHMgYXJlIHJlcXVpcmVkIHRvIGJlIDY0IGJpdHMgbG9uZyBhbmQgdG8gYmUgY29u c3RydWN0ZWQgDQo+IGluIE1vZGlmaWVkIEVVSS02NCBmb3JtYXQiLiANCj4gDQo+IFRoZSBkcmFm dCBzYXlzIHRoYXQ6DQo+IChhKSBUaGUgUFNJRCBpczoNCj4gKy0tKy0tLSstLS0rLS0tKy0tLSst LS0rLS0tKy0tLSstLS0rDQo+IHxQTHwgICA4ICAxNiAgMjQgIDMyICA0MCAgNDggIDU2ICAgfA0K PiArLS0rLS0tKy0tLSstLS0rLS0tKy0tLSstLS0rLS0tKy0tLSsNCj4gfDY0fCB1IHwgSVB2NCBh ZGRyZXNzICB8ICBQU0lEIHwgMCB8DQo+ICstLSstLS0rLS0tKy0tLSstLS0rLS0tKy0tLSstLS0r LS0tKw0KPiAoYikgIklmIHRoZSBFbmQtdXNlciBJUHY2IHByZWZpeCBsZW5ndGggaXMgbGFyZ2Vy IHRoYW4gNjQsIHRoZSBtb3N0IA0KPiBzaWduaWZpY2FudCBwYXJ0cyBvZiB0aGUgaW50ZXJmYWNl IGlkZW50aWZpZXIgaXMgb3ZlcndyaXR0ZW4gYnkgdGhlIA0KcHJlZml4LiINCj4gDQo+IFRoaXMg aXMgcGFydGljdWxhcmx5IHVuY2xlYXI6DQo+IC0gV2hhdCBoYXBwZW5zIHRvIHRoZSB1IG9jdGV0 Pw0KPiAtIEFuZCB0byB0aGUgSVB2NCBhZGRyZXNzIGlmIHRoZSBwcmVmaXggaXMgbG9uZ2VyIHRo YW4gLzY4PyANCg0KUmVtaSwgeW91IG1lYW4gdGhlIHByZWZpeCBpcyBsb25nZXIgdGhhbiAvNjgg b3IgLzc4PyAgICBJIHRoaW5rIC82OCg2NCs0KSANCnByZWZpeCBkb2Vzbid0IG92ZXJ3cml0ZSBJ UHY0IGFkZHJlc3MuDQoNCkJScw0KTGluZGEgV2FuZw0KDQoNCj4gLSAuLi4NCj4gDQo+IE9mIGNv dXJzZSwgaWYgYSB1c2UgY2FzZSBpcyBwcm92aWRlZCB3aGVyZSBNQVAtRSB3b3VsZCBiZSBhY3R1 YWxseSANCj4gdXNlZCB3aXRoIGFuIElJRCBzaG9ydGVyIHRoYW4gNjQgYml0cywgaXQgc2hvdWxk IGJlIGRpc2N1c3NlZC4gQnV0Og0KPiAtIFRoZXJlIGlzIG5vIHN1Y2ggdXNlIGNhc2Ugc28gZmFy LiANCj4gLSBMb29raW5nIGZvciBvbmUgZG9lc24ndCBzZWVtIHVzZWZ1bC4gDQo+IA0KPiANCj4g UmVnYXJkcywNCj4gUkQNCj4gDQo+IA0KPiA+IA0KPiA+IE9uIDEvMjgvMTMgODo1OSBBTSwgIk9s ZSBUcm9hbiIgPG90cm9hbkBlbXBsb3llZXMub3JnPiB3cm90ZToNCj4gPiANCj4gPj4+Pj4gDQo+ ID4+Pj4+IFRoZSBleGFtcGxlcyBpbiBteSBwcmV2aW91cyBub3RlIHNvcnQgb2YgcHJvdmlkZWQg YmFja2luZyBmb3IgbXkgDQp2aWV3DQo+ID4+Pj4+IHRoYXQgdGhlIE1BUCBlbmRwb2ludCBJUHY2 IHByZWZpeCBjYW4gYmUgbGltaXRlZCB0byBhIG1heGltdW0gb2YgYQ0KPiA+Pj4+PiAvNjQsIHRo dXMgbWFraW5nIHRoZSBJSUQgZnVsbHkgY29uZm9ybWFudCBib3RoIHRvIFJGQyA0MjkxIGFuZCB0 byANClJGQw0KPiA+Pj4+PiA2MDUyLg0KPiA+Pj4+PiANCj4gPj4+IC4uLg0KPiA+Pj4gDQo+ID4+ Pj4+IA0KPiA+Pj4+PiBJIHRoaW5rIGxpbWl0aW5nIHRoZSBwcmVmaXggbGVuZ3RoIHRvIDY0IGJp dHMgaXMgcmVhc29uYWJsZS4gDQpDb21tZW50cz8NCj4gPj4+PiANCj4gPj4+PiBJIGRvbid0IHRo aW5rIHRoYXQncyByZWFzb25hYmxlLg0KPiA+Pj4+IGFuZCBJIGRvbid0IHNlZSB3aGF0IGl0IGJ1 eXMgdXMsIGdpdmVuIHRoYXQgc3VwcG9ydGluZyBwcmVmaXggDQpsZW5ndGhzDQo+ID4+Pj4gbG9u Z2VyIHRoYW4gNjQgaXMgc2ltcGxlLg0KPiA+Pj4+IElQdjYgaXNuJ3QgY2xhc3NmdWxsLCB0aGVy ZSBpc24ndCBhbnl0aGluZyBtYWdpYyB3aXRoIHRoZSA2NCANCmJvdW5kYXJ5Lg0KPiA+Pj4+IDst KQ0KPiA+Pj4+IA0KPiA+Pj4+IGNoZWVycywNCj4gPj4+PiBPbGUNCj4gPj4+PiANCj4gPj4+IA0K PiA+Pj4gT0ssIHRoZW4gSSBhZ3JlZSB3aXRoIFLDqW1pLiBEcm9wIG1lbnRpb24gb2YgcHJlZml4 ZXMgZ3JlYXRlciB0aGFuIDY0DQo+ID4+PiBiaXRzIGxvbmcgYW5kIGxlYXZlIGl0IHRvIHRoZSBy ZWFkZXIgdG8ganVkZ2Ugd2hldGhlciBSRkMgNDI5MSANCmltcG9zZXMgYQ0KPiA+Pj4gbGltaXQu DQo+ID4+IA0KPiA+PiB5b3Ugd2FudCB0aGlzIHJlbW92ZWQ6DQo+ID4+ICAgICA8dD5JZiB0aGUg RW5kLXVzZXIgSVB2NiBwcmVmaXggbGVuZ3RoIGlzIGxhcmdlciB0aGFuIDY0LCB0aGUgbW9zdA0K PiA+PiAgICAgc2lnbmlmaWNhbnQgcGFydHMgb2YgdGhlIGludGVyZmFjZSBpZGVudGlmaWVyIGlz IG92ZXJ3cml0dGVuIGJ5IA0KdGhlDQo+ID4+ICAgICBwcmVmaXguPC90Pg0KPiA+PiANCj4gPj4g SSBkaXNhZ3JlZS4gdGhpcyBpcyB0aGUgb25seSB0ZXh0IGluIHRoZXJlIHN1Z2dlc3RpbmcgdG8g YW4gDQppbXBsZW1lbnRvcg0KPiA+PiB0aGF0IHByZWZpeCBsZW5ndGhzIGNhbiBiZSBhbnkgdmFs dWUgYmV0d2VlbiAwLTEyOC4NCj4gPj4gDQo+ID4+IFRvbSwgUmVtaSBhbmQgSSBoYXZlIHN0YXRl ZCBvdXIgb3BpbmlvbnMuIGRvZXMgYW55b25lIGVsc2UgaGF2ZSBhIA0KdmlldyBvbg0KPiA+PiB0 aGUgbWF0dGVyPw0KPiA+PiANCj4gPj4gY2hlZXJzLA0KPiA+PiBPbGUNCj4gPj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4gU29mdHdpcmVzIG1h aWxpbmcgbGlzdA0KPiA+PiBTb2Z0d2lyZXNAaWV0Zi5vcmcNCj4gPj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zb2Z0d2lyZXMNCj4gPiANCj4gPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IFNvZnR3aXJlcyBtYWlsaW5n IGxpc3QNCj4gPiBTb2Z0d2lyZXNAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NvZnR3aXJlcw0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiBTb2Z0d2lyZXMgbWFpbGluZyBsaXN0DQo+IFNvZnR3aXJl c0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NvZnR3 aXJlcw0KDQo= --=_alternative 0025EAF348257B02_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLFJlbWk8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD4NCjxicj4NCjxicj48 dHQ+PGZvbnQgc2l6ZT0yPnNvZnR3aXJlcy1ib3VuY2VzQGlldGYub3JnIOWGmeS6jiAyMDEzLTAx LTI5IDAwOjE2OjMyOjxicj4NCjxicj4NCiZndDsgU2VudGhpbCw8YnI+DQomZ3Q7IDxicj4NCiZn dDsgPGJyPg0KJmd0OyAyMDEzLTAxLTI4MTU6MjQsIFNlbnRoaWwgU2l2YWt1bWFyIChzc2VudGhp bCkgJmx0O3NzZW50aGlsQGNpc2NvLmNvbSZndDsNCiZuYnNwOzo8YnI+DQomZ3Q7IDxicj4NCiZn dDsgJmd0OyBJIGJlbGlldmUgdGhlIHByZWZpeCBsZW5ndGggJmd0OyA2NCBzaG91bGQgYmUgYWxs b3dlZC48YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IEl0IGlzIHVwdG8gdGhl PGJyPg0KJmd0OyAmZ3Q7IG9wZXJhdG9yIHRvIGNob29zZSB0aGUgcHJlZml4IGxlbmd0aCBvZiB0 aGVpciBjaG9pY2UuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEFncmVlZC48YnI+DQomZ3Q7IE5vIG9u ZSBzdWdnZXN0IHRvIHNheSB0aGUgY29udHJhcnkuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFlldCwg b3BlcmF0b3JzIGhhdmUgdGhlIGNvbnN0cmFpbnQgb2YgUkZDIDQyOTEgdGhhdCAmcXVvdDtGb3Ig YWxsDQp1bmljYXN0PGJyPg0KJmd0OyBhZGRyZXNzZXMsIGV4Y2VwdCB0aG9zZSB0aGF0IHN0YXJ0 IHdpdGggdGhlIGJpbmFyeSB2YWx1ZSAwMDAsIDxicj4NCiZndDsgSW50ZXJmYWNlIElEcyBhcmUg cmVxdWlyZWQgdG8gYmUgNjQgYml0cyBsb25nIGFuZCB0byBiZSBjb25zdHJ1Y3RlZA0KPGJyPg0K Jmd0OyBpbiBNb2RpZmllZCBFVUktNjQgZm9ybWF0JnF1b3Q7LiAmbmJzcDs8YnI+DQomZ3Q7IDxi cj4NCiZndDsgVGhlIGRyYWZ0IHNheXMgdGhhdDo8YnI+DQomZ3Q7IChhKSBUaGUgUFNJRCBpczo8 YnI+DQomZ3Q7ICstLSstLS0rLS0tKy0tLSstLS0rLS0tKy0tLSstLS0rLS0tKzxicj4NCiZndDsg fFBMfCAmbmJzcDsgOCAmbmJzcDsxNiAmbmJzcDsyNCAmbmJzcDszMiAmbmJzcDs0MCAmbmJzcDs0 OCAmbmJzcDs1Ng0KJm5ic3A7IHw8YnI+DQomZ3Q7ICstLSstLS0rLS0tKy0tLSstLS0rLS0tKy0t LSstLS0rLS0tKzxicj4NCiZndDsgfDY0fCB1IHwgSVB2NCBhZGRyZXNzICZuYnNwO3wgJm5ic3A7 UFNJRCB8IDAgfDxicj4NCiZndDsgKy0tKy0tLSstLS0rLS0tKy0tLSstLS0rLS0tKy0tLSstLS0r PGJyPg0KJmd0OyAoYikgJnF1b3Q7SWYgdGhlIEVuZC11c2VyIElQdjYgcHJlZml4IGxlbmd0aCBp cyBsYXJnZXIgdGhhbiA2NCwgdGhlDQptb3N0IDxicj4NCiZndDsgc2lnbmlmaWNhbnQgcGFydHMg b2YgdGhlIGludGVyZmFjZSBpZGVudGlmaWVyIGlzIG92ZXJ3cml0dGVuIGJ5IHRoZQ0KcHJlZml4 LiZxdW90Ozxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGlzIGlzIHBhcnRpY3VsYXJseSB1bmNsZWFy Ojxicj4NCiZndDsgLSBXaGF0IGhhcHBlbnMgdG8gdGhlIHUgb2N0ZXQ/PGJyPg0KJmd0OyAtIEFu ZCB0byB0aGUgSVB2NCBhZGRyZXNzIGlmIHRoZSBwcmVmaXggaXMgbG9uZ2VyIHRoYW4gLzY4PyA8 L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPlJlbWksIHlvdSBtZWFuIHRo ZSBwcmVmaXggaXMgbG9uZ2VyIHRoYW4gLzY4IG9yIC83OD8NCiZuYnNwOyAmbmJzcDtJIHRoaW5r IC82OCg2NCs0KSBwcmVmaXggZG9lc24ndCBvdmVyd3JpdGUgSVB2NCBhZGRyZXNzLjwvZm9udD48 L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+QlJzPC9mb250PjwvdHQ+DQo8YnI+PHR0 Pjxmb250IHNpemU9Mj5MaW5kYSBXYW5nPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250 IHNpemU9Mj48YnI+DQomZ3Q7IC0gLi4uPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE9mIGNvdXJzZSwg aWYgYSB1c2UgY2FzZSBpcyBwcm92aWRlZCB3aGVyZSBNQVAtRSB3b3VsZCBiZSBhY3R1YWxseQ0K PGJyPg0KJmd0OyB1c2VkIHdpdGggYW4gSUlEIHNob3J0ZXIgdGhhbiA2NCBiaXRzLCBpdCBzaG91 bGQgYmUgZGlzY3Vzc2VkLiBCdXQ6PGJyPg0KJmd0OyAtIFRoZXJlIGlzIG5vIHN1Y2ggdXNlIGNh c2Ugc28gZmFyLiA8YnI+DQomZ3Q7IC0gTG9va2luZyBmb3Igb25lIGRvZXNuJ3Qgc2VlbSB1c2Vm dWwuIDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFJlZ2FyZHMsPGJyPg0KJmd0OyBS RDxicj4NCiZndDsgPGJyPg0KJmd0OyAmbmJzcDs8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAm Z3Q7IE9uIDEvMjgvMTMgODo1OSBBTSwgJnF1b3Q7T2xlIFRyb2FuJnF1b3Q7ICZsdDtvdHJvYW5A ZW1wbG95ZWVzLm9yZyZndDsNCndyb3RlOjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhlIGV4YW1w bGVzIGluIG15IHByZXZpb3VzIG5vdGUgc29ydCBvZiBwcm92aWRlZA0KYmFja2luZyBmb3IgbXkg dmlldzxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhhdCB0aGUgTUFQIGVuZHBvaW50 IElQdjYgcHJlZml4IGNhbiBiZSBsaW1pdGVkDQp0byBhIG1heGltdW0gb2YgYTxicj4NCiZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgLzY0LCB0aHVzIG1ha2luZyB0aGUgSUlEIGZ1bGx5IGNvbmZv cm1hbnQgYm90aA0KdG8gUkZDIDQyOTEgYW5kIHRvIFJGQzxicj4NCiZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsgNjA1Mi48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsg Jmd0OyZndDsmZ3Q7IC4uLjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJIHRoaW5rIGxp bWl0aW5nIHRoZSBwcmVmaXggbGVuZ3RoIHRvIDY0IGJpdHMNCmlzIHJlYXNvbmFibGUuIENvbW1l bnRzPzxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsgSSBkb24ndCB0aGluayB0aGF0J3MgcmVhc29uYWJsZS48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsgYW5kIEkgZG9uJ3Qgc2VlIHdoYXQgaXQgYnV5cyB1cywgZ2l2ZW4gdGhhdCBzdXBwb3J0 aW5nDQpwcmVmaXggbGVuZ3Roczxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBsb25nZXIgdGhh biA2NCBpcyBzaW1wbGUuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IElQdjYgaXNuJ3QgY2xh c3NmdWxsLCB0aGVyZSBpc24ndCBhbnl0aGluZyBtYWdpYw0Kd2l0aCB0aGUgNjQgYm91bmRhcnku PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IDstKTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgY2hlZXJzLDxicj4NCiZndDsgJmd0OyZndDsm Z3Q7Jmd0OyBPbGU8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0 OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgT0ssIHRoZW4gSSBhZ3JlZSB3aXRoIFLDqW1p LiBEcm9wIG1lbnRpb24gb2YgcHJlZml4ZXMNCmdyZWF0ZXIgdGhhbiA2NDxicj4NCiZndDsgJmd0 OyZndDsmZ3Q7IGJpdHMgbG9uZyBhbmQgbGVhdmUgaXQgdG8gdGhlIHJlYWRlciB0byBqdWRnZSB3 aGV0aGVyDQpSRkMgNDI5MSBpbXBvc2VzIGE8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBsaW1pdC48 YnI+DQomZ3Q7ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZndDsgeW91IHdhbnQgdGhpcyByZW1v dmVkOjxicj4NCiZndDsgJmd0OyZndDsgJm5ic3A7ICZuYnNwOyAmbHQ7dCZndDtJZiB0aGUgRW5k LXVzZXIgSVB2NiBwcmVmaXggbGVuZ3RoDQppcyBsYXJnZXIgdGhhbiA2NCwgdGhlIG1vc3Q8YnI+ DQomZ3Q7ICZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgc2lnbmlmaWNhbnQgcGFydHMgb2YgdGhlIGlu dGVyZmFjZSBpZGVudGlmaWVyDQppcyBvdmVyd3JpdHRlbiBieSB0aGU8YnI+DQomZ3Q7ICZndDsm Z3Q7ICZuYnNwOyAmbmJzcDsgcHJlZml4LiZsdDsvdCZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IDxi cj4NCiZndDsgJmd0OyZndDsgSSBkaXNhZ3JlZS4gdGhpcyBpcyB0aGUgb25seSB0ZXh0IGluIHRo ZXJlIHN1Z2dlc3RpbmcgdG8NCmFuIGltcGxlbWVudG9yPGJyPg0KJmd0OyAmZ3Q7Jmd0OyB0aGF0 IHByZWZpeCBsZW5ndGhzIGNhbiBiZSBhbnkgdmFsdWUgYmV0d2VlbiAwLTEyOC48YnI+DQomZ3Q7 ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZndDsgVG9tLCBSZW1pIGFuZCBJIGhhdmUgc3RhdGVk IG91ciBvcGluaW9ucy4gZG9lcyBhbnlvbmUgZWxzZQ0KaGF2ZSBhIHZpZXcgb248YnI+DQomZ3Q7 ICZndDsmZ3Q7IHRoZSBtYXR0ZXI/PGJyPg0KJmd0OyAmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsm Z3Q7IGNoZWVycyw8YnI+DQomZ3Q7ICZndDsmZ3Q7IE9sZTxicj4NCiZndDsgJmd0OyZndDsgX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7ICZn dDsmZ3Q7IFNvZnR3aXJlcyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZndDsmZ3Q7IFNvZnR3aXJl c0BpZXRmLm9yZzxicj4NCiZndDsgJmd0OyZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9zb2Z0d2lyZXM8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7 IFNvZnR3aXJlcyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZndDsgU29mdHdpcmVzQGlldGYub3Jn PGJyPg0KJmd0OyAmZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc29m dHdpcmVzPGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCiZndDsgU29mdHdpcmVzIG1haWxpbmcgbGlzdDxicj4NCiZndDsgU29mdHdp cmVzQGlldGYub3JnPGJyPg0KJmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NvZnR3aXJlczxicj4NCjwvZm9udD48L3R0Pg0K --=_alternative 0025EAF348257B02_=-- From wang.cui1@zte.com.cn Mon Jan 28 23:03:41 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F43121F8A7E; Mon, 28 Jan 2013 23:03:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.153 X-Spam-Level: X-Spam-Status: No, score=-97.153 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 67IPDyfx3g-3; Mon, 28 Jan 2013 23:03:40 -0800 (PST) Received: from zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 60F9C21F8A74; Mon, 28 Jan 2013 23:03:40 -0800 (PST) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id E8E72112D523; Tue, 29 Jan 2013 15:03:14 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 978011939CCA; Tue, 29 Jan 2013 15:05:55 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id r0T73COr089238; Tue, 29 Jan 2013 15:03:14 +0800 (GMT-8) (envelope-from wang.cui1@zte.com.cn) In-Reply-To: To: "Senthil Sivakumar (ssenthil)" MIME-Version: 1.0 X-KeepSent: D000FA39:271E2890-48257B02:00266240; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: wang.cui1@zte.com.cn Date: Tue, 29 Jan 2013 15:03:13 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2013-01-29 15:03:11, Serialize complete at 2013-01-29 15:03:11 Content-Type: multipart/alternative; boundary="=_alternative 0026B74D48257B02_=" X-MAIL: mse01.zte.com.cn r0T73COr089238 Cc: Softwires , softwires-bounces@ietf.org Subject: [Softwires] =?gb2312?b?tPC4tDogUmU6ICBMaW1pdGluZyB0aGUgbGVuZ3Ro?= =?gb2312?b?IG9mIHRoZSBNQVAgZW5kcG9pbnQgSVB2NiBwcmVmaXg=?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 07:03:41 -0000 This is a multipart message in MIME format. --=_alternative 0026B74D48257B02_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGksIFNlbnRoaWwsDQoNCnNvZnR3aXJlcy1ib3VuY2VzQGlldGYub3JnIOWGmeS6jiAyMDEzLTAx LTI5IDEwOjQ5OjU5Og0KDQo+IA0KPiANCj4gT24gMS8yOC8xMyAxMjo1NiBQTSwgIk9sZSBUcm9h biIgPG90cm9hbkBlbXBsb3llZXMub3JnPiB3cm90ZToNCj4gDQo+ID5TZW50aGlsLA0KPiA+DQo+ ID5bLi4uXQ0KPiA+DQo+ID4+PiBUaGUgZHJhZnQgc2F5cyB0aGF0Og0KPiA+Pj4gKGEpIFRoZSBQ U0lEIGlzOg0KPiA+Pj4gKy0tKy0tLSstLS0rLS0tKy0tLSstLS0rLS0tKy0tLSstLS0rDQo+ID4+ PiB8UEx8ICAgOCAgMTYgIDI0ICAzMiAgNDAgIDQ4ICA1NiAgIHwNCj4gPj4+ICstLSstLS0rLS0t Ky0tLSstLS0rLS0tKy0tLSstLS0rLS0tKw0KPiA+Pj4gfDY0fCB1IHwgSVB2NCBhZGRyZXNzICB8 ICBQU0lEIHwgMCB8DQo+ID4+PiArLS0rLS0tKy0tLSstLS0rLS0tKy0tLSstLS0rLS0tKy0tLSsN Cj4gPj4gDQo+ID4+IEkgYmVsaWV2ZSB0aGlzIGZpZ3VyZSBpcyBtaXNsZWFkaW5nIGJ5IHBsYWNp bmcgdGhlIElQdjQgYWRkcmVzcyBpbiBhDQo+ID4+Zml4ZWQNCj4gPj4gbG9jYXRpb24uIEZpZ3Vy ZSAzIGFuZCBGaWd1cmUgNw0KPiA+PiBJbiB0aGUgZHJhZnQgc2hvd3MgdGhhdCB0aGUgSUlEIGlz IG5vdCBpbiBhIGZpeGVkIGxvY2F0aW9uLiBBbHNvLCB0aGUNCj4gPj50ZXh0DQo+ID4+IHN1cnJv dW5kaW5nIHRoZSBhYm92ZSBmaWd1cmUgOCwgc2F5cw0KPiA+PiAiVGhlIEludGVyZmFjZSBpZGVu dGlmaWVyIGZvcm1hdCBvZiBhIE1BUCBub2RlIGlzIGJhc2VkIG9uIHRoZSBmb3JtYXQNCj4gPj4g ICBzcGVjaWZpZWQgaW4gc2VjdGlvbiAyLjIgb2YgW1JGQzYwNTJdLCB3aXRoIHRoZSBhZGRlZCBQ U0lEIGZpZWxkIGlmDQo+ID4+ICAgcHJlc2VudCwgYXMgc2hvd24gaW4gZmlndXJlIEZpZ3VyZSA4 LiINCj4gPj4gDQo+ID4+IA0KPiA+PiBCdXQgUkZDIDYwNTIgZG9lc27CuXQgaGF2ZSB0aGUgSVB2 NCBhZGRyZXNzIGluIGEgZml4ZWQgbG9jYXRpb24gYXMgcGVyDQo+ID4+IHNlY3Rpb24gMi4yLiBT byBJIHRoaW5rIHRoaXMgZmlndXJlIGlzIG1pc2xlYWRpbmcuDQo+ID4NCj4gPnBlcmhhcHMgd2Ug c2hvdWxkIGp1c3QgcmVtb3ZlIHRoZSBSRkM2MDUyIHJlZmVyZW5jZSB0aGVuPw0KPiA+d2l0aCBh IDQ4IGJpdHMgb2YgUFNJRCArIElQdjQgYWRkcmVzcy4NCj4gPkkgZG9uJ3QgbWluZCBpZiBpdCBp cyBqdXN0IElQdjQgYWRkcmVzcywgYnV0IHRoZW4gc29tZW9uZSBuZWVkIHRvIGRyaXZlDQo+ID50 aGF0IGRpc2N1c3Npb24uDQo+IA0KPiBJIHRoaW5rIHRoZSBhYm92ZSBmaWd1cmUgc2hvdWxkIGJl IGNsYXJpZmllZCBhcyBhbiBleGFtcGxlIHdoZW4gdGhlDQo+IHByZWZpeC1sZW5ndGgrRUEgPD0g NjQuDQo+IElmIHRoZSBwcmVmaXggbGVuZ3RoIGlzIGdyZWF0ZXIgdGhhbiA2NCwgdGhlIElQdjQg YWRkcmVzcyBhcHBlYXJzIGFmdGVyDQo+IHRoZSBwcmVmaXggbGVuZ3RoIGFuZA0KPiBVIGJpdHMg YXJlIG92ZXJ3cml0dGVuLg0KDQpGb3IgZXhhbXBsZSwgcHJlZml4IGlzIC82OCwgdGhlbiBJUHY0 IGFkZHJlc3MgYXBwZWFycyBhdCB0aGUgNjktMTAwIGJpdHMgDQpvciB0aGVyZSBhcmUgc3RpbGwg NC1iaXQgZm9yIHUgYml0cyxhbmQgSVB2NCBhZGRyZXNzIGFwcGVhcnMgYXQgNzMtMTA0IA0KYml0 cz8NCg0KQlJzDQpMaW5kYSBXYW5nDQoNCg0KPiBJZiB3ZSBjbGFyaWZ5IHRoZSBhYm92ZSB0d28g cG9pbnRzIGFuZCByZW1vdmUgdGhlIHJlZmVyZW5jZSB0byByZmM2MDUyLA0KPiB0aGF0IHdvdWxk IGJlIGZpbmUuDQo+IA0KPiANCj4gVGhhbmtzDQo+IFNlbnRoaWwNCj4gPg0KPiA+PiB8ICAgICBu IGJpdHMgICAgICAgICB8ICBvIGJpdHMgICB8IHMgYml0cyAgfCAgIDEyOC1uLW8tcyBiaXRzICAg ICAgfA0KPiA+PiArLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0rLS0tLS0tLS0tKy0t LS0tLS0tLS0tLSstLS0tLS0tLS0tKw0KPiA+PiAgIHwgIFJ1bGUgSVB2NiBwcmVmaXggIHwgIEVB IGJpdHMgIHxzdWJuZXQgSUR8ICAgICBpbnRlcmZhY2UgSUQgfA0KPiA+PiArLS0tLS0tLS0tLS0t LS0tLS0tLS0rLS0tLS0tLS0tLS0rLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0K PiA+PiANCj4gPj4gDQo+ID4+PiAoYikgIklmIHRoZSBFbmQtdXNlciBJUHY2IHByZWZpeCBsZW5n dGggaXMgbGFyZ2VyIHRoYW4gNjQsIHRoZSBtb3N0DQo+ID4+PiBzaWduaWZpY2FudCBwYXJ0cyBv ZiB0aGUgaW50ZXJmYWNlIGlkZW50aWZpZXIgaXMgb3ZlcndyaXR0ZW4gYnkgdGhlDQo+ID4+PiBw cmVmaXguIg0KPiA+Pj4gDQo+ID4+PiBUaGlzIGlzIHBhcnRpY3VsYXJseSB1bmNsZWFyOg0KPiA+ PiANCj4gPj4gVHJ1ZS4NCj4gPj4+IC0gV2hhdCBoYXBwZW5zIHRvIHRoZSB1IG9jdGV0Pw0KPiA+ PiANCj4gPj4gSSBndWVzcyB0aGF0IG5lZWRzIHRvIGJlIG1hZGUgY2xlYXIgaW4gdGhlIGRyYWZ0 LiBXZSBzdHJ1Z2dsZWQgd2l0aCANCnRoYXQNCj4gPj4gaW4gb3VyIGltcGxlbWVudGF0aW9uLg0K PiA+DQo+ID5pZiB3ZSByZW1vdmUgdGhlIDYwNTIgcmVmZXJlbmNlLCB0aGVyZSBpcyBubyB1LW9j dGV0Lg0KPiA+DQo+ID4+PiAtIEFuZCB0byB0aGUgSVB2NCBhZGRyZXNzIGlmIHRoZSBwcmVmaXgg aXMgbG9uZ2VyIHRoYW4gLzY4Pw0KPiA+Pj4gLSAuLi4NCj4gPj4+IA0KPiA+Pj4gT2YgY291cnNl LCBpZiBhIHVzZSBjYXNlIGlzIHByb3ZpZGVkIHdoZXJlIE1BUC1FIHdvdWxkIGJlIGFjdHVhbGx5 IA0KdXNlZA0KPiA+Pj4gd2l0aCBhbiBJSUQgc2hvcnRlciB0aGFuIDY0IGJpdHMsIGl0IHNob3Vs ZCBiZSBkaXNjdXNzZWQuIEJ1dDoNCj4gPj4+IC0gVGhlcmUgaXMgbm8gc3VjaCB1c2UgY2FzZSBz byBmYXIuDQo+ID4+PiAtIExvb2tpbmcgZm9yIG9uZSBkb2Vzbid0IHNlZW0gdXNlZnVsLg0KPiA+ PiANCj4gPj4gSSB3b3VsZCBsaWtlIHRvIHNlZSB0aGUgSVB2NCBhZGRyZXNzIGJlIHByZXNlbnQg ZnJvbSBiaXRzIDk2LTEyNywgbm8NCj4gPj5uZWVkDQo+ID4+IGZvciB0aGUgUFNJRCB0byBiZSBy ZXBlYXRlZCBhZ2Fpbi4gVGhhdCB3b3VsZCBhbGxvdyB1cyB0byBnbyB1cHRvIC85Ng0KPiA+PmFu ZA0KPiA+PiBiZWluZyBjb25zaXN0ZW50IHdpdGggUkZDIDYwNTIgd2hpY2ggYWxsb3dzIG9uZSB0 byBjb25maWd1cmUgYSBwcmVmaXggDQpvZg0KPiA+PiB1cHRvIC85Ni4NCj4gPg0KPiA+anVzdCBw dXQgdGhlIElQdjQgYWRkcmVzcyBpbiB0aGUgYm90dG9tIGJpdHMsIGFuZCBhbGxvdyBpdCB0byBi ZQ0KPiA+b3ZlcndyaXR0ZW4gYnkgdGhlIHByZWZpeC4NCj4gPml0IGlzIGp1c3QgdGhlcmUgZm9y ICdwcmV0dHkgcHJpbnRpbmcnIGFueXdheS4NCj4gPg0KPiA+Y2hlZXJzLA0KPiA+T2xlDQo+IA0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBTb2Z0 d2lyZXMgbWFpbGluZyBsaXN0DQo+IFNvZnR3aXJlc0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NvZnR3aXJlcw0KDQo= --=_alternative 0026B74D48257B02_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLCBTZW50aGlsLDwvZm9udD4N Cjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPnNvZnR3aXJlcy1ib3VuY2VzQGlldGYub3JnIOWG meS6jiAyMDEzLTAxLTI5IDEwOjQ5OjU5Ojxicj4NCjxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+ DQomZ3Q7IE9uIDEvMjgvMTMgMTI6NTYgUE0sICZxdW90O09sZSBUcm9hbiZxdW90OyAmbHQ7b3Ry b2FuQGVtcGxveWVlcy5vcmcmZ3Q7DQp3cm90ZTo8YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0O1Nl bnRoaWwsPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Wy4uLl08YnI+DQomZ3Q7ICZndDs8 YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBUaGUgZHJhZnQgc2F5cyB0aGF0Ojxicj4NCiZndDsgJmd0 OyZndDsmZ3Q7IChhKSBUaGUgUFNJRCBpczo8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyArLS0rLS0t Ky0tLSstLS0rLS0tKy0tLSstLS0rLS0tKy0tLSs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyB8UEx8 ICZuYnNwOyA4ICZuYnNwOzE2ICZuYnNwOzI0ICZuYnNwOzMyICZuYnNwOzQwICZuYnNwOzQ4DQom bmJzcDs1NiAmbmJzcDsgfDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7ICstLSstLS0rLS0tKy0tLSst LS0rLS0tKy0tLSstLS0rLS0tKzxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IHw2NHwgdSB8IElQdjQg YWRkcmVzcyAmbmJzcDt8ICZuYnNwO1BTSUQgfCAwIHw8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyAr LS0rLS0tKy0tLSstLS0rLS0tKy0tLSstLS0rLS0tKy0tLSs8YnI+DQomZ3Q7ICZndDsmZ3Q7IDxi cj4NCiZndDsgJmd0OyZndDsgSSBiZWxpZXZlIHRoaXMgZmlndXJlIGlzIG1pc2xlYWRpbmcgYnkg cGxhY2luZyB0aGUgSVB2NCBhZGRyZXNzDQppbiBhPGJyPg0KJmd0OyAmZ3Q7Jmd0O2ZpeGVkPGJy Pg0KJmd0OyAmZ3Q7Jmd0OyBsb2NhdGlvbi4gRmlndXJlIDMgYW5kIEZpZ3VyZSA3PGJyPg0KJmd0 OyAmZ3Q7Jmd0OyBJbiB0aGUgZHJhZnQgc2hvd3MgdGhhdCB0aGUgSUlEIGlzIG5vdCBpbiBhIGZp eGVkIGxvY2F0aW9uLg0KQWxzbywgdGhlPGJyPg0KJmd0OyAmZ3Q7Jmd0O3RleHQ8YnI+DQomZ3Q7 ICZndDsmZ3Q7IHN1cnJvdW5kaW5nIHRoZSBhYm92ZSBmaWd1cmUgOCwgc2F5czxicj4NCiZndDsg Jmd0OyZndDsgJnF1b3Q7VGhlIEludGVyZmFjZSBpZGVudGlmaWVyIGZvcm1hdCBvZiBhIE1BUCBu b2RlIGlzIGJhc2VkDQpvbiB0aGUgZm9ybWF0PGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmbmJzcDsgc3Bl Y2lmaWVkIGluIHNlY3Rpb24gMi4yIG9mIFtSRkM2MDUyXSwgd2l0aCB0aGUgYWRkZWQNClBTSUQg ZmllbGQgaWY8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZuYnNwOyBwcmVzZW50LCBhcyBzaG93biBpbiBm aWd1cmUgRmlndXJlIDguJnF1b3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsm Z3Q7IDxicj4NCiZndDsgJmd0OyZndDsgQnV0IFJGQyA2MDUyIGRvZXNuwrl0IGhhdmUgdGhlIElQ djQgYWRkcmVzcyBpbiBhIGZpeGVkIGxvY2F0aW9uDQphcyBwZXI8YnI+DQomZ3Q7ICZndDsmZ3Q7 IHNlY3Rpb24gMi4yLiBTbyBJIHRoaW5rIHRoaXMgZmlndXJlIGlzIG1pc2xlYWRpbmcuPGJyPg0K Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7cGVyaGFwcyB3ZSBzaG91bGQganVzdCByZW1vdmUgdGhl IFJGQzYwNTIgcmVmZXJlbmNlIHRoZW4/PGJyPg0KJmd0OyAmZ3Q7d2l0aCBhIDQ4IGJpdHMgb2Yg UFNJRCArIElQdjQgYWRkcmVzcy48YnI+DQomZ3Q7ICZndDtJIGRvbid0IG1pbmQgaWYgaXQgaXMg anVzdCBJUHY0IGFkZHJlc3MsIGJ1dCB0aGVuIHNvbWVvbmUgbmVlZA0KdG8gZHJpdmU8YnI+DQom Z3Q7ICZndDt0aGF0IGRpc2N1c3Npb24uPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEkgdGhpbmsgdGhl IGFib3ZlIGZpZ3VyZSBzaG91bGQgYmUgY2xhcmlmaWVkIGFzIGFuIGV4YW1wbGUgd2hlbiB0aGU8 YnI+DQomZ3Q7IHByZWZpeC1sZW5ndGgrRUEgJmx0Oz0gNjQuPGJyPg0KJmd0OyBJZiB0aGUgcHJl Zml4IGxlbmd0aCBpcyBncmVhdGVyIHRoYW4gNjQsIHRoZSBJUHY0IGFkZHJlc3MgYXBwZWFycw0K YWZ0ZXI8YnI+DQomZ3Q7IHRoZSBwcmVmaXggbGVuZ3RoIGFuZDxicj4NCiZndDsgVSBiaXRzIGFy ZSBvdmVyd3JpdHRlbi48L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPkZv ciBleGFtcGxlLCBwcmVmaXggaXMgLzY4LCB0aGVuIElQdjQgYWRkcmVzcyBhcHBlYXJzDQphdCB0 aGUgNjktMTAwIGJpdHMgb3IgdGhlcmUgYXJlIHN0aWxsIDQtYml0IGZvciB1IGJpdHMsYW5kIElQ djQgYWRkcmVzcw0KYXBwZWFycyBhdCA3My0xMDQgYml0cz88L2ZvbnQ+PC90dD4NCjxicj4NCjxi cj48dHQ+PGZvbnQgc2l6ZT0yPkJSczwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+ TGluZGEgV2FuZzwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+PGJyPg0K Jmd0OyBJZiB3ZSBjbGFyaWZ5IHRoZSBhYm92ZSB0d28gcG9pbnRzIGFuZCByZW1vdmUgdGhlIHJl ZmVyZW5jZSB0byByZmM2MDUyLDxicj4NCiZndDsgdGhhdCB3b3VsZCBiZSBmaW5lLjxicj4NCiZn dDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoYW5rczxicj4NCiZndDsgU2VudGhpbDxicj4NCiZn dDsgJmd0Ozxicj4NCiZndDsgJmd0OyZndDsgfCAmbmJzcDsgJm5ic3A7IG4gYml0cyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDtvDQpiaXRzICZuYnNwOyB8IHMgYml0cyAmbmJz cDt8ICZuYnNwOyAxMjgtbi1vLXMgYml0cyAmbmJzcDsgJm5ic3A7ICZuYnNwO3w8YnI+DQomZ3Q7 ICZndDsmZ3Q7ICZuYnNwOyArLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0rLS0tLS0t LS0tKy0tLS0tLS0tLS0tLSstLS0tLS0tLS0tKzxicj4NCiZndDsgJmd0OyZndDsgJm5ic3A7IHwg Jm5ic3A7UnVsZSBJUHY2IHByZWZpeCAmbmJzcDt8ICZuYnNwO0VBIGJpdHMgJm5ic3A7fHN1Ym5l dA0KSUR8ICZuYnNwOyAmbmJzcDsgaW50ZXJmYWNlIElEICZuYnNwOyAmbmJzcDsgJm5ic3A7fDxi cj4NCiZndDsgJmd0OyZndDsgJm5ic3A7ICstLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0t LSstLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rPGJyPg0KJmd0OyAmZ3Q7Jmd0OyA8 YnI+DQomZ3Q7ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IChiKSAmcXVvdDtJZiB0 aGUgRW5kLXVzZXIgSVB2NiBwcmVmaXggbGVuZ3RoIGlzIGxhcmdlcg0KdGhhbiA2NCwgdGhlIG1v c3Q8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBzaWduaWZpY2FudCBwYXJ0cyBvZiB0aGUgaW50ZXJm YWNlIGlkZW50aWZpZXIgaXMgb3ZlcndyaXR0ZW4NCmJ5IHRoZTxicj4NCiZndDsgJmd0OyZndDsm Z3Q7IHByZWZpeC4mcXVvdDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsm Z3Q7Jmd0OyBUaGlzIGlzIHBhcnRpY3VsYXJseSB1bmNsZWFyOjxicj4NCiZndDsgJmd0OyZndDsg PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBUcnVlLjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IC0gV2hhdCBo YXBwZW5zIHRvIHRoZSB1IG9jdGV0Pzxicj4NCiZndDsgJmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7 Jmd0OyBJIGd1ZXNzIHRoYXQgbmVlZHMgdG8gYmUgbWFkZSBjbGVhciBpbiB0aGUgZHJhZnQuIFdl IHN0cnVnZ2xlZA0Kd2l0aCB0aGF0PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBpbiBvdXIgaW1wbGVtZW50 YXRpb24uPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7aWYgd2UgcmVtb3ZlIHRoZSA2MDUy IHJlZmVyZW5jZSwgdGhlcmUgaXMgbm8gdS1vY3RldC48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7 ICZndDsmZ3Q7Jmd0OyAtIEFuZCB0byB0aGUgSVB2NCBhZGRyZXNzIGlmIHRoZSBwcmVmaXggaXMg bG9uZ2VyIHRoYW4NCi82OD88YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyAtIC4uLjxicj4NCiZndDsg Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IE9mIGNvdXJzZSwgaWYgYSB1c2Ug Y2FzZSBpcyBwcm92aWRlZCB3aGVyZSBNQVAtRSB3b3VsZA0KYmUgYWN0dWFsbHkgdXNlZDxicj4N CiZndDsgJmd0OyZndDsmZ3Q7IHdpdGggYW4gSUlEIHNob3J0ZXIgdGhhbiA2NCBiaXRzLCBpdCBz aG91bGQgYmUgZGlzY3Vzc2VkLg0KQnV0Ojxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IC0gVGhlcmUg aXMgbm8gc3VjaCB1c2UgY2FzZSBzbyBmYXIuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgLSBMb29r aW5nIGZvciBvbmUgZG9lc24ndCBzZWVtIHVzZWZ1bC48YnI+DQomZ3Q7ICZndDsmZ3Q7IDxicj4N CiZndDsgJmd0OyZndDsgSSB3b3VsZCBsaWtlIHRvIHNlZSB0aGUgSVB2NCBhZGRyZXNzIGJlIHBy ZXNlbnQgZnJvbSBiaXRzDQo5Ni0xMjcsIG5vPGJyPg0KJmd0OyAmZ3Q7Jmd0O25lZWQ8YnI+DQom Z3Q7ICZndDsmZ3Q7IGZvciB0aGUgUFNJRCB0byBiZSByZXBlYXRlZCBhZ2Fpbi4gVGhhdCB3b3Vs ZCBhbGxvdyB1cyB0bw0KZ28gdXB0byAvOTY8YnI+DQomZ3Q7ICZndDsmZ3Q7YW5kPGJyPg0KJmd0 OyAmZ3Q7Jmd0OyBiZWluZyBjb25zaXN0ZW50IHdpdGggUkZDIDYwNTIgd2hpY2ggYWxsb3dzIG9u ZSB0byBjb25maWd1cmUNCmEgcHJlZml4IG9mPGJyPg0KJmd0OyAmZ3Q7Jmd0OyB1cHRvIC85Ni48 YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDtqdXN0IHB1dCB0aGUgSVB2NCBhZGRyZXNzIGlu IHRoZSBib3R0b20gYml0cywgYW5kIGFsbG93IGl0IHRvDQpiZTxicj4NCiZndDsgJmd0O292ZXJ3 cml0dGVuIGJ5IHRoZSBwcmVmaXguPGJyPg0KJmd0OyAmZ3Q7aXQgaXMganVzdCB0aGVyZSBmb3Ig J3ByZXR0eSBwcmludGluZycgYW55d2F5Ljxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0O2No ZWVycyw8YnI+DQomZ3Q7ICZndDtPbGU8YnI+DQomZ3Q7IDxicj4NCiZndDsgX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IFNvZnR3aXJlcyBt YWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IFNvZnR3aXJlc0BpZXRmLm9yZzxicj4NCiZndDsgaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zb2Z0d2lyZXM8YnI+DQo8L2ZvbnQ+PC90 dD4NCg== --=_alternative 0026B74D48257B02_=-- From fibrib@gmail.com Mon Jan 28 23:09:39 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7AF321F8A6F for ; Mon, 28 Jan 2013 23:09:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.148 X-Spam-Level: X-Spam-Status: No, score=-1.148 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QPyEIJuPBlZ7 for ; Mon, 28 Jan 2013 23:09:37 -0800 (PST) Received: from mail-oa0-f48.google.com (mail-oa0-f48.google.com [209.85.219.48]) by ietfa.amsl.com (Postfix) with ESMTP id B947A21F8A96 for ; Mon, 28 Jan 2013 23:09:37 -0800 (PST) Received: by mail-oa0-f48.google.com with SMTP id h2so109277oag.7 for ; Mon, 28 Jan 2013 23:09:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=P9lCmovyPrPZ7S2o1Cl7Li/1ZvfbfUJe2/yPhs2u+ng=; b=ULk5eDDYazHXstt4gRL3lrrEp34Is5nYBbzIcG7rRZlY3PEO6O+GPmnKoRWVVSyzg1 OveKQek/fI5huBZt5+OCTbG/FmS/pSqXo2PYtLS1oPMWiAIWD9M6NBjPSuY2dDbB2CDJ dhpUMjctBWIDXUC889JMJjyZlz+SBeTUpG4bW9Ze9Fi6AwEAUVgTeAuJ+LNdsE/VSsZt 0geYChPJCOVap0jMOyvv/euBYLHbAQlJctUhnPjAwZI7DvdPRxdLu3CMGQPJrt3fqePq 65xNVIafqmGlDjmh65A2jP4lVMKFHf2yXX+y5ek83YBd5U5Ps50NpjBMK5JbiBdA1DD3 b4XQ== MIME-Version: 1.0 X-Received: by 10.182.92.70 with SMTP id ck6mr370339obb.46.1359443377217; Mon, 28 Jan 2013 23:09:37 -0800 (PST) Received: by 10.76.154.8 with HTTP; Mon, 28 Jan 2013 23:09:37 -0800 (PST) In-Reply-To: <56493EE7-F585-460B-A07F-774165D63763@gmail.com> References: <063.9dc31682f59256171b5d58fdb1cdcc5e@tools.ietf.org> <078.5016b38f0fa45b1e08acdf73cc564147@tools.ietf.org> <56493EE7-F585-460B-A07F-774165D63763@gmail.com> Date: Tue, 29 Jan 2013 16:09:37 +0900 Message-ID: From: Maoke To: Qi Sun Content-Type: multipart/alternative; boundary=14dae93b63da975ef804d4681350 Cc: "softwires@ietf.org WG" , remi.despres@free.fr Subject: Re: [Softwires] [softwire] #19: IPv4 address superfluous in MAP-E Interface IDs X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 07:09:39 -0000 --14dae93b63da975ef804d4681350 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable 2013/1/29 Qi Sun > > Woj , > > the IPv4 and PSID in the IID are particularly useful in cases of address > independence (ie 1:1). > > > Now that IPv4 and PSID is put in the IPv6 address, why is it a case of > address independence? > IPv4-address independent MAP rule .. ;-) - maoke > > > Best Regards, > Qi Sun > > > On 2013-1-28, at =CF=C2=CE=E79:51, Wojciech Dec wrote: > > Hi, > > the IPv4 and PSID in the IID are particularly useful in cases of address > independence (ie 1:1). As said previously, the benefit is primarily in th= e > ability an operational facilitation, where an operator can easily > see/observe what IPv4 and PSID is being used by a given customer. This is > easier than to look at the v6 prefix and use some magic decoder ring. > In addition, it has the desirable characteristic of creating an IID. > > +1 Thus to keeping the IPv4 and PSID, likely in a fixed length (16 bit) > field format. > > Regards, > Woj. > > On 24 January 2013 16:27, Ole Troan wrote: > >> hi, >> >> can we please keep discussion on the list. not via the issue tracker? >> >> does anyone else have an opinion? >> (if I don't hear anything from anyone else, I'll default to keep current >> text.) >> >> cheers, >> Ole >> >> On Jan 24, 2013, at 17:23 , softwire issue tracker < >> trac+softwire@tools.ietf.org> wrote: >> >> > #19: IPv4 address superfluous in MAP-E Interface IDs >> > >> > Changes (by remi.despres@free.fr): >> > >> > * priority: trivial =3D> major >> > * status: closed =3D> reopened >> > * resolution: wontfix =3D> >> > >> > >> > Comment: >> > >> > Value of having the PSID in MAP-E IIDs for maintenance isn't clear at >> all: >> > - PSID length isn't determined in IIDs (there can be an unknown number >> of >> > trailing zeroes) >> > - all PSID bits are already readable in the first 64 bits >> > >> > Suggestion to close the issue: >> > - keep IPv4 addresses in IIDs (they contains some bits that aren't in >> the >> > first 64 bits) >> > - don't keep the PSID in IIDs (insufficiently justified complexity) >> > >> > -- >> > >> -------------------------+----------------------------------------------= --- >> > Reporter: | Owner: draft-ietf-softwire- >> > remi.despres@free.fr | map@tools.ietf.org >> > Type: defect | Status: reopened >> > Priority: major | Milestone: >> > Component: map-e | Version: >> > Severity: Candidate | Resolution: >> > WG Document | >> > Keywords: | >> > >> -------------------------+----------------------------------------------= --- >> > >> > Ticket URL: < >> http://trac.tools.ietf.org/wg/softwire/trac/ticket/19#comment:4> >> > softwire >> > >> >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >> > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > > --14dae93b63da975ef804d4681350 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable

2013/1/29 Qi Sun <<= a href=3D"mailto:sunqi.csnet.thu@gmail.com" target=3D"_blank">sunqi.csnet.t= hu@gmail.com>

Woj ,

the IPv4 and PSID in the IID are particularly useful in cases of addre= ss independence (ie 1:1). 

Now that I= Pv4 and PSID is put in the IPv6 address, why is it a case of address indepe= ndence?

IPv4-address independent MAP rule .. ;-) - maoke
 
=


Best Regards,
Qi Sun

<= /span>

On 2013-1-28, at =CF=C2=CE=E79:51, Wojciech Dec wrote:
<= br>
Hi,

the IPv4 and PSID in the IID are pa= rticularly useful in cases of address independence (ie 1:1). As said previo= usly, the benefit is primarily in the ability an operational facilitation, = where an operator can easily see/observe what IPv4 and PSID is being used b= y a given customer. This is easier than to look at the v6 prefix and use so= me magic decoder ring.
In addition, it has the desirable characteristic of creating an IID.
+1 Thus to keeping the IPv4 and PSID, likely in a fixed length (16 bit) fi= eld format.

Regards,
Woj.

On 24= January 2013 16:27, Ole Troan <otroan@employees.org> wro= te:
hi,

can we please keep discussion on the list. not via the issue tracker?

does anyone else have an opinion?
(if I don't hear anything from anyone else, I'll default to keep cu= rrent text.)

cheers,
Ole

On Jan 24, 2013, at 17:23 , softwire issue tracker <trac+softwire@tools.ietf.or= g> wrote:

> #19: IPv4 address superfluous in MAP-E Interface IDs
>
> Changes (by = remi.despres@free.fr):
>
> * priority:  trivial =3D> major
> * status:  closed =3D> reopened
> * resolution:  wontfix =3D>
>
>
> Comment:
>
> Value of having the PSID in MAP-E IIDs for maintenance isn't clear= at all:
> - PSID length isn't determined in IIDs (there can be an unknown nu= mber of
> trailing zeroes)
> - all PSID bits are already readable in the first 64 bits
>
> Suggestion to close the issue:
> - keep IPv4 addresses in IIDs (they contains some bits that aren't= in the
> first 64 bits)
> - don't keep the PSID in IIDs (insufficiently justified complexity= )
>
> --
> -------------------------+--------------------------------------------= -----
> Reporter:               |   &n= bsp;   Owner:  draft-ietf-softwire-
>  remi.d= espres@free.fr   |  map@tools.ietf.org
>     Type:  defect       |     =  Status:  reopened
> Priority:  major        |   Milestone: > Component:  map-e        |     Vers= ion:
> Severity:  Candidate    |  Resolution:
>  WG Document            |
> Keywords:               |
> -------------------------+--------------------------------------------= -----
>
> Ticket URL: <http://trac.tools.ietf.org/wg/softw= ire/trac/ticket/19#comment:4>
> softwire <http://tools.ietf.org/softwire/>
>

_______________________________________________
Softwires mailing list
Softwires@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/softwires

_______________________________________________
Softwires mailing listSoftwires@ietf.or= g
https://www.ietf.org/mailman/listinfo/softwires


______________________________= _________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires


--14dae93b63da975ef804d4681350-- From fibrib@gmail.com Mon Jan 28 23:14:12 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBE4B21F8AA8 for ; Mon, 28 Jan 2013 23:14:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.148 X-Spam-Level: X-Spam-Status: No, score=-1.148 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZaP1Q1L+Qrq2 for ; Mon, 28 Jan 2013 23:14:11 -0800 (PST) Received: from mail-ob0-f170.google.com (mail-ob0-f170.google.com [209.85.214.170]) by ietfa.amsl.com (Postfix) with ESMTP id 2C14E21F8AA0 for ; Mon, 28 Jan 2013 23:14:11 -0800 (PST) Received: by mail-ob0-f170.google.com with SMTP id wc20so113609obb.29 for ; Mon, 28 Jan 2013 23:14:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=JRWhF6NRi+TXg3BcJeD2U2BIKe3gD+HQoB0nt1Q6o48=; b=HVqn0JehJkpKzCU+s3AyFoa04b/05yZPRhXq51Q5eMqQdQcHtXe9C3KczcRn5sM99t 1PUJKvwFD5nd7FF99HwODjIXKcvy7R00dc94s5t82CJEbXdYWyE0v5A/FCiMirq2KJ8B WWjzUlE83JzF7a5TQtlYNrAxoG5WhMBiW7kLgBqBEPP3Y6eX+W0pGQ6IT13sKSJV37zF 7souTMBQUyLY9A75pJ4GUZ2XV3kR5TMF8U3+LHppQ+Ib5Obgx66ml0o0XBu4ct3jSMuL cVrqrhmGaa6r+ZqpXB44gLFu/0z8KBX/+EaPWyt52dONIe4wvqQ+2Q2xGLbrRAiOQztF v8Sw== MIME-Version: 1.0 X-Received: by 10.60.31.227 with SMTP id d3mr368053oei.70.1359443650695; Mon, 28 Jan 2013 23:14:10 -0800 (PST) Received: by 10.76.154.8 with HTTP; Mon, 28 Jan 2013 23:14:10 -0800 (PST) In-Reply-To: References: <063.9dc31682f59256171b5d58fdb1cdcc5e@tools.ietf.org> <078.5016b38f0fa45b1e08acdf73cc564147@tools.ietf.org> <56493EE7-F585-460B-A07F-774165D63763@gmail.com> Date: Tue, 29 Jan 2013 16:14:10 +0900 Message-ID: From: Maoke To: Qi Sun Content-Type: multipart/alternative; boundary=e89a8fb1fc36e4516b04d468237d Cc: "softwires@ietf.org WG" , remi.despres@free.fr Subject: Re: [Softwires] [softwire] #19: IPv4 address superfluous in MAP-E Interface IDs X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 07:14:12 -0000 --e89a8fb1fc36e4516b04d468237d Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable 2013/1/29 Maoke > > > 2013/1/29 Qi Sun > >> >> Woj , >> >> the IPv4 and PSID in the IID are particularly useful in cases of address >> independence (ie 1:1). >> >> >> Now that IPv4 and PSID is put in the IPv6 address, why is it a case of >> address independence? >> > > IPv4-address independent MAP rule .. ;-) - maoke > sorry IPv4-address independent MAP rule-IPv6-prefix. :P - maoke > > >> >> >> Best Regards, >> Qi Sun >> >> >> On 2013-1-28, at =CF=C2=CE=E79:51, Wojciech Dec wrote: >> >> Hi, >> >> the IPv4 and PSID in the IID are particularly useful in cases of address >> independence (ie 1:1). As said previously, the benefit is primarily in t= he >> ability an operational facilitation, where an operator can easily >> see/observe what IPv4 and PSID is being used by a given customer. This i= s >> easier than to look at the v6 prefix and use some magic decoder ring. >> In addition, it has the desirable characteristic of creating an IID. >> >> +1 Thus to keeping the IPv4 and PSID, likely in a fixed length (16 bit) >> field format. >> >> Regards, >> Woj. >> >> On 24 January 2013 16:27, Ole Troan wrote: >> >>> hi, >>> >>> can we please keep discussion on the list. not via the issue tracker? >>> >>> does anyone else have an opinion? >>> (if I don't hear anything from anyone else, I'll default to keep curren= t >>> text.) >>> >>> cheers, >>> Ole >>> >>> On Jan 24, 2013, at 17:23 , softwire issue tracker < >>> trac+softwire@tools.ietf.org> wrote: >>> >>> > #19: IPv4 address superfluous in MAP-E Interface IDs >>> > >>> > Changes (by remi.despres@free.fr): >>> > >>> > * priority: trivial =3D> major >>> > * status: closed =3D> reopened >>> > * resolution: wontfix =3D> >>> > >>> > >>> > Comment: >>> > >>> > Value of having the PSID in MAP-E IIDs for maintenance isn't clear at >>> all: >>> > - PSID length isn't determined in IIDs (there can be an unknown numbe= r >>> of >>> > trailing zeroes) >>> > - all PSID bits are already readable in the first 64 bits >>> > >>> > Suggestion to close the issue: >>> > - keep IPv4 addresses in IIDs (they contains some bits that aren't in >>> the >>> > first 64 bits) >>> > - don't keep the PSID in IIDs (insufficiently justified complexity) >>> > >>> > -- >>> > >>> -------------------------+---------------------------------------------= ---- >>> > Reporter: | Owner: draft-ietf-softwire- >>> > remi.despres@free.fr | map@tools.ietf.org >>> > Type: defect | Status: reopened >>> > Priority: major | Milestone: >>> > Component: map-e | Version: >>> > Severity: Candidate | Resolution: >>> > WG Document | >>> > Keywords: | >>> > >>> -------------------------+---------------------------------------------= ---- >>> > >>> > Ticket URL: < >>> http://trac.tools.ietf.org/wg/softwire/trac/ticket/19#comment:4> >>> > softwire >>> > >>> >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >>> >> >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >> >> >> >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >> >> > --e89a8fb1fc36e4516b04d468237d Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable

2013/1/29 Maoke <fibrib@gmail.com>= ;


2013/1/29 Qi Sun <sunqi.csnet.thu@gmail.com>

Woj ,

the IPv4= and PSID in the IID are particularly useful in cases of address independen= ce (ie 1:1). 

Now that IPv4 and PSID = is put in the IPv6 address, why is it a case of address independence?

IPv4-address independent MAP rule .. ;-) - maoke
=

sorry IPv4-address independent MAP rule-IPv6-prefix. = :P - maoke
 
 
=


Best Regards,
Qi Sun

<= /span>

On 2013-1-28, at =CF=C2=CE=E79:51, Wojciech Dec wrote:
<= br>
Hi,

the IPv4 and PSID in the IID are pa= rticularly useful in cases of address independence (ie 1:1). As said previo= usly, the benefit is primarily in the ability an operational facilitation, = where an operator can easily see/observe what IPv4 and PSID is being used b= y a given customer. This is easier than to look at the v6 prefix and use so= me magic decoder ring.
In addition, it has the desirable characteristic of creating an IID.
+1 Thus to keeping the IPv4 and PSID, likely in a fixed length (16 bit) fi= eld format.

Regards,
Woj.

On 24= January 2013 16:27, Ole Troan <otroan@employees.org> wro= te:
hi,

can we please keep discussion on the list. not via the issue tracker?

does anyone else have an opinion?
(if I don't hear anything from anyone else, I'll default to keep cu= rrent text.)

cheers,
Ole

On Jan 24, 2013, at 17:23 , softwire issue tracker <trac+softwire@tools.ietf.or= g> wrote:

> #19: IPv4 address superfluous in MAP-E Interface IDs
>
> Changes (by = remi.despres@free.fr):
>
> * priority:  trivial =3D> major
> * status:  closed =3D> reopened
> * resolution:  wontfix =3D>
>
>
> Comment:
>
> Value of having the PSID in MAP-E IIDs for maintenance isn't clear= at all:
> - PSID length isn't determined in IIDs (there can be an unknown nu= mber of
> trailing zeroes)
> - all PSID bits are already readable in the first 64 bits
>
> Suggestion to close the issue:
> - keep IPv4 addresses in IIDs (they contains some bits that aren't= in the
> first 64 bits)
> - don't keep the PSID in IIDs (insufficiently justified complexity= )
>
> --
> -------------------------+--------------------------------------------= -----
> Reporter:               |   &n= bsp;   Owner:  draft-ietf-softwire-
>  remi.d= espres@free.fr   |  map@tools.ietf.org
>     Type:  defect       |     =  Status:  reopened
> Priority:  major        |   Milestone: > Component:  map-e        |     Vers= ion:
> Severity:  Candidate    |  Resolution:
>  WG Document            |
> Keywords:               |
> -------------------------+--------------------------------------------= -----
>
> Ticket URL: <http://trac.tools.ietf.org/wg/softw= ire/trac/ticket/19#comment:4>
> softwire <http://tools.ietf.org/softwire/>
>

_______________________________________________
Softwires mailing list
Softwires@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/softwires

_______________________________________________
Softwires mailing listSoftwires@ietf.or= g
https://www.ietf.org/mailman/listinfo/softwires


______________________________= _________________
Softwires mailing list
Softwires@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/softwires



--e89a8fb1fc36e4516b04d468237d-- From wdec.ietf@gmail.com Tue Jan 29 01:00:29 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF0421F8840 for ; Tue, 29 Jan 2013 01:00:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 49wQjspwFXdL for ; Tue, 29 Jan 2013 01:00:28 -0800 (PST) Received: from mail-qa0-f43.google.com (mail-qa0-f43.google.com [209.85.216.43]) by ietfa.amsl.com (Postfix) with ESMTP id E0A6D21F880F for ; Tue, 29 Jan 2013 01:00:27 -0800 (PST) Received: by mail-qa0-f43.google.com with SMTP id p6so1278510qad.9 for ; Tue, 29 Jan 2013 01:00:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=SgL14BwpJvCu6T133LJwhQiSiSWKyvfBRVHMJzbRnDw=; b=1EfKLiAQZrEFhq5dxuE+kntkssdIP22kEOLzF9Moj/1qAM50gorZEaqzyPfA2a6p2c OV86VOHbx94wfLVNuXmP5WV2u+C/od6D+b4UnG9sNga39PlILud+fmferHq9wfV30vqo CqJ+RO/y3WhlyJIn/JO7UdzxDerYaHkBS2HxVkck0gfSkvYRJGWvdkbyOn+hInlQpYUO vqvQzKxw63D7ZNWddvG+Ff9oRRDq4cOelg9dOcx3aKUsUD97kRsBzfqkJjEdL2yZbUWT JN+Y8/ujqMV0rfs0meMKcLPCYNph8dFowIOHw/KnoJjuZTST/K3eA7sj+rRpPAlqB668 Qbrg== MIME-Version: 1.0 X-Received: by 10.224.186.83 with SMTP id cr19mr346964qab.51.1359450027241; Tue, 29 Jan 2013 01:00:27 -0800 (PST) Received: by 10.49.75.33 with HTTP; Tue, 29 Jan 2013 01:00:27 -0800 (PST) In-Reply-To: References: <063.9dc31682f59256171b5d58fdb1cdcc5e@tools.ietf.org> <078.5016b38f0fa45b1e08acdf73cc564147@tools.ietf.org> <56493EE7-F585-460B-A07F-774165D63763@gmail.com> Date: Tue, 29 Jan 2013 09:00:27 +0000 Message-ID: From: Wojciech Dec To: Maoke Content-Type: multipart/alternative; boundary=20cf30363f75f6b06c04d4699feb Cc: "softwires@ietf.org WG" Subject: Re: [Softwires] [softwire] #19: IPv4 address superfluous in MAP-E Interface IDs X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 09:00:29 -0000 --20cf30363f75f6b06c04d4699feb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Correct. Thanks Maoke. On 29 January 2013 07:14, Maoke wrote: > > > 2013/1/29 Maoke > >> >> >> 2013/1/29 Qi Sun >> >>> >>> Woj , >>> >>> the IPv4 and PSID in the IID are particularly useful in cases of addres= s >>> independence (ie 1:1). >>> >>> >>> Now that IPv4 and PSID is put in the IPv6 address, why is it a case of >>> address independence? >>> >> >> IPv4-address independent MAP rule .. ;-) - maoke >> > > sorry IPv4-address independent MAP rule-IPv6-prefix. :P - maoke > > >> >> >>> >>> >>> Best Regards, >>> Qi Sun >>> >>> >>> On 2013-1-28, at =E4=B8=8B=E5=8D=889:51, Wojciech Dec wrote: >>> >>> Hi, >>> >>> the IPv4 and PSID in the IID are particularly useful in cases of addres= s >>> independence (ie 1:1). As said previously, the benefit is primarily in = the >>> ability an operational facilitation, where an operator can easily >>> see/observe what IPv4 and PSID is being used by a given customer. This = is >>> easier than to look at the v6 prefix and use some magic decoder ring. >>> In addition, it has the desirable characteristic of creating an IID. >>> >>> +1 Thus to keeping the IPv4 and PSID, likely in a fixed length (16 bit) >>> field format. >>> >>> Regards, >>> Woj. >>> >>> On 24 January 2013 16:27, Ole Troan wrote: >>> >>>> hi, >>>> >>>> can we please keep discussion on the list. not via the issue tracker? >>>> >>>> does anyone else have an opinion? >>>> (if I don't hear anything from anyone else, I'll default to keep >>>> current text.) >>>> >>>> cheers, >>>> Ole >>>> >>>> On Jan 24, 2013, at 17:23 , softwire issue tracker < >>>> trac+softwire@tools.ietf.org> wrote: >>>> >>>> > #19: IPv4 address superfluous in MAP-E Interface IDs >>>> > >>>> > Changes (by remi.despres@free.fr): >>>> > >>>> > * priority: trivial =3D> major >>>> > * status: closed =3D> reopened >>>> > * resolution: wontfix =3D> >>>> > >>>> > >>>> > Comment: >>>> > >>>> > Value of having the PSID in MAP-E IIDs for maintenance isn't clear a= t >>>> all: >>>> > - PSID length isn't determined in IIDs (there can be an unknown >>>> number of >>>> > trailing zeroes) >>>> > - all PSID bits are already readable in the first 64 bits >>>> > >>>> > Suggestion to close the issue: >>>> > - keep IPv4 addresses in IIDs (they contains some bits that aren't i= n >>>> the >>>> > first 64 bits) >>>> > - don't keep the PSID in IIDs (insufficiently justified complexity) >>>> > >>>> > -- >>>> > >>>> -------------------------+--------------------------------------------= ----- >>>> > Reporter: | Owner: draft-ietf-softwire- >>>> > remi.despres@free.fr | map@tools.ietf.org >>>> > Type: defect | Status: reopened >>>> > Priority: major | Milestone: >>>> > Component: map-e | Version: >>>> > Severity: Candidate | Resolution: >>>> > WG Document | >>>> > Keywords: | >>>> > >>>> -------------------------+--------------------------------------------= ----- >>>> > >>>> > Ticket URL: < >>>> http://trac.tools.ietf.org/wg/softwire/trac/ticket/19#comment:4> >>>> > softwire >>>> > >>>> >>>> _______________________________________________ >>>> Softwires mailing list >>>> Softwires@ietf.org >>>> https://www.ietf.org/mailman/listinfo/softwires >>>> >>> >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >>> >>> >>> >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >>> >>> >> > --20cf30363f75f6b06c04d4699feb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Correct. Thanks Maoke.

On 29 January 2013= 07:14, Maoke <fibrib@gmail.com> wrote:


2013/1/29 Maoke <fibri= b@gmail.com>


2013/1/29 Qi Sun = <sunqi.cs= net.thu@gmail.com>

Woj ,

the IPv4= and PSID in the IID are particularly useful in cases of address independen= ce (ie 1:1).=C2=A0

Now that IPv4 and PSID = is put in the IPv6 address, why is it a case of address independence?

IPv4-address independent MAP rule .. ;-) - maoke
=

sorry IPv4-address independent MAP rule-IPv6-pr= efix. :P - maoke
=C2=A0
=C2=A0
=


Best Regards,
Qi Sun

<= /span>

On 2013-1-28, at =E4=B8=8B=E5=8D=889:51, Wojciech Dec wrote:<= /div>
Hi,

the IPv4 and PSID in the IID = are particularly useful in cases of address independence (ie 1:1). As said = previously, the benefit is primarily in the ability an operational facilita= tion, where an operator can easily see/observe what IPv4 and PSID is being = used by a given customer. This is easier than to look at the v6 prefix and = use some magic decoder ring.
In addition, it has the desirable characteristic of creating an IID.
+1 Thus to keeping the IPv4 and PSID, likely in a fixed length (16 bit) fi= eld format.

Regards,
Woj.

On 24= January 2013 16:27, Ole Troan <otroan@employees.org> wro= te:
hi,

can we please keep discussion on the list. not via the issue tracker?

does anyone else have an opinion?
(if I don't hear anything from anyone else, I'll default to keep cu= rrent text.)

cheers,
Ole

On Jan 24, 2013, at 17:23 , softwire issue tracker <trac+softwire@tools.ietf.or= g> wrote:

> #19: IPv4 address superfluous in MAP-E Interface IDs
>
> Changes (by = remi.despres@free.fr):
>
> * priority: =C2=A0trivial =3D> major
> * status: =C2=A0closed =3D> reopened
> * resolution: =C2=A0wontfix =3D>
>
>
> Comment:
>
> Value of having the PSID in MAP-E IIDs for maintenance isn't clear= at all:
> - PSID length isn't determined in IIDs (there can be an unknown nu= mber of
> trailing zeroes)
> - all PSID bits are already readable in the first 64 bits
>
> Suggestion to close the issue:
> - keep IPv4 addresses in IIDs (they contains some bits that aren't= in the
> first 64 bits)
> - don't keep the PSID in IIDs (insufficiently justified complexity= )
>
> --
> -------------------------+--------------------------------------------= -----
> Reporter: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 = =C2=A0 =C2=A0 Owner: =C2=A0draft-ietf-softwire-
> =C2=A0remi.d= espres@free.fr =C2=A0 | =C2=A0map@tools.ietf.org
> =C2=A0 =C2=A0 Type: =C2=A0defect =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 = =C2=A0Status: =C2=A0reopened
> Priority: =C2=A0major =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 Milestone: > Component: =C2=A0map-e =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 Vers= ion:
> Severity: =C2=A0Candidate =C2=A0 =C2=A0| =C2=A0Resolution:
> =C2=A0WG Document =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
> Keywords: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
> -------------------------+--------------------------------------------= -----
>
> Ticket URL: <http://trac.tools.ietf.org/wg/softw= ire/trac/ticket/19#comment:4>
> softwire <http://tools.ietf.org/softwire/>
>

_______________________________________________
Softwires mailing list
Softwires@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/softwires

_______________________________________________
Softwires mailing listSoftwires@ietf.or= g
https://www.ietf.org/mailman/listinfo/softwires


______________________________= _________________
Softwires mailing list
Softwires@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/softwires




--20cf30363f75f6b06c04d4699feb-- From despres.remi@laposte.net Tue Jan 29 01:37:35 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4884121F84DC for ; Tue, 29 Jan 2013 01:37:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UyKVu01jtl7X for ; Tue, 29 Jan 2013 01:37:34 -0800 (PST) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.20]) by ietfa.amsl.com (Postfix) with ESMTP id 7DDEE21F85C3 for ; Tue, 29 Jan 2013 01:37:33 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2306.sfr.fr (SMTP Server) with ESMTP id DCC9C7000219; Tue, 29 Jan 2013 10:37:32 +0100 (CET) Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2306.sfr.fr (SMTP Server) with ESMTP id C31CE7000217; Tue, 29 Jan 2013 10:37:32 +0100 (CET) X-SFR-UUID: 20130129093732799.C31CE7000217@msfrf2306.sfr.fr Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 29 Jan 2013 10:37:32 +0100 Message-Id: References: <063.9dc31682f59256171b5d58fdb1cdcc5e@tools.ietf.org> <078.5016b38f0fa45b1e08acdf73cc564147@tools.ietf.org> To: "softwires@ietf.org WG" X-Mailer: Apple Mail (2.1499) Content-Type: multipart/alternative; boundary="Apple-Mail=_50A4A5FC-ED2F-4C18-8CFA-F2371C88FB89" Subject: Re: [Softwires] [softwire] #19: IPv4 address superfluous in MAP-E Interface IDs X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 09:37:35 -0000 --Apple-Mail=_50A4A5FC-ED2F-4C18-8CFA-F2371C88FB89 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 The key is "keep it simple", with neither IPv4 addresses nor PSIDs in = MAP-E IIDs.=20 More explanations below. 2013-01-28 14:51, Wojciech Dec t : > Hi, >=20 > the IPv4 and PSID in the IID are particularly useful in cases of = address independence (ie 1:1). As said previously, the benefit is = primarily in the ability an operational facilitation, where an operator = can easily see/observe what IPv4 and PSID is being used by a given = customer. This is easier than to look at the v6 prefix and use some = magic decoder ring. (a) The IPv4 address already readable in the encapsulated IPv4 packet = (the subject is only MAP-E, not MAP-T or 4rd). (b) With the proposed IID format, the length of the PSID cannot be = determined without looking at the applicable mapping rule. (As already = noted, the number of zeroes at the end of the PSID isn't specified in = the address).=20 (c) Once the rule is looked at, getting the PSID is easy (no more magic = needed than to get find the PSID length ;-)). =20 > In addition, it has the desirable characteristic of creating an IID. A constant IID was the logic proposal for the original Encapsulation = solution (then called "4rd" before becoming "MAP-E", ref. = tools.ietf.org/html/draft-murakami-softwire-4rd-01). It is only when we tried to merge -E it with -T that we abandoned this = simplicity.=20 (Incidentally, to avoid limitation (b) above, we introduced that at that = time a PSID-length field in IIDs (ref. = www.ietf.org/mail-archive/web/softwires/current/msg02994.html), but this = complexity would be superfluous for MAP-E.)=20 Regards, RD =20 --Apple-Mail=_50A4A5FC-ED2F-4C18-8CFA-F2371C88FB89 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
More explanations = below.

2013-01-28 14:51, Wojciech Dec <wdec.ietf@gmail.com>t = :

Hi,

the IPv4 and PSID in the IID are particularly = useful in cases of address independence (ie 1:1). As said previously, = the benefit is primarily in the ability an operational facilitation, = where an operator can easily see/observe what IPv4 and PSID is being = used by a given customer. This is easier than to look at the v6 prefix = and use some magic decoder ring.

(a) = The IPv4 address already readable in the encapsulated IPv4 packet (the = subject is only MAP-E, not MAP-T or 4rd).
(b) With the = proposed IID format, the length of the PSID cannot be determined without = looking at the applicable mapping rule. (As already noted, the = number of zeroes at the end of the PSID isn't specified in the = address). 
(c) Once the rule is looked at, getting the = PSID is easy (no more magic needed than to get find the PSID length = ;-)).
 
In addition, it has the desirable characteristic of creating an = IID.

A constant IID was the logic = proposal for the original Encapsulation solution (then called = "4rd" before becoming "MAP-E", ref. tools.i= etf.org/html/draft-murakami-softwire-4rd-01).
It is only = when we tried to merge -E it with -T that we abandoned this = simplicity. 
(Incidentally, to avoid limitation = (b) above, we introduced that at that time a = PSID-length field in IIDs (ref. www.ietf.org/mail-archive/web/softwires/current/msg02994.html), = but this complexity would be superfluous for = MAP-E.) 

Regards,
RD
&nb= sp; 

= --Apple-Mail=_50A4A5FC-ED2F-4C18-8CFA-F2371C88FB89-- From otroan@employees.org Tue Jan 29 01:50:16 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 022EE21F8903 for ; Tue, 29 Jan 2013 01:50:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.425 X-Spam-Level: X-Spam-Status: No, score=-10.425 tagged_above=-999 required=5 tests=[AWL=-0.126, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c3Ptd9HoD88B for ; Tue, 29 Jan 2013 01:50:15 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id C0D4D21F87DC for ; Tue, 29 Jan 2013 01:50:14 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAFSaB1GQ/khL/2dsb2JhbABEvlcWc4IeAQEEAUkwBQsLRiE2BhMJEodkAwkGDLBAhkINiVWMEIEKgwphA5Q3gnKKGoUSgniBbg X-IronPort-AV: E=Sophos;i="4.84,559,1355097600"; d="scan'208";a="149888272" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 29 Jan 2013 09:50:12 +0000 Received: from dhcp-lys01-vla250-10-147-112-56.cisco.com (dhcp-lys01-vla250-10-147-112-56.cisco.com [10.147.112.56]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r0T9oC6S006257 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 29 Jan 2013 09:50:12 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ole Troan In-Reply-To: Date: Tue, 29 Jan 2013 10:50:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8B5A2979-6E57-4E1F-B3A8-5450F9B39CD8@employees.org> References: <063.9dc31682f59256171b5d58fdb1cdcc5e@tools.ietf.org> <078.5016b38f0fa45b1e08acdf73cc564147@tools.ietf.org> To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1499) Cc: "softwires@ietf.org WG" Subject: Re: [Softwires] [softwire] #19: IPv4 address superfluous in MAP-E Interface IDs X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 09:50:16 -0000 Remi, > The key is "keep it simple", with neither IPv4 addresses nor PSIDs in = MAP-E IIDs.=20 > More explanations below. >=20 > 2013-01-28 14:51, Wojciech Dec t : >=20 >> Hi, >>=20 >> the IPv4 and PSID in the IID are particularly useful in cases of = address independence (ie 1:1). As said previously, the benefit is = primarily in the ability an operational facilitation, where an operator = can easily see/observe what IPv4 and PSID is being used by a given = customer. This is easier than to look at the v6 prefix and use some = magic decoder ring. >=20 > (a) The IPv4 address already readable in the encapsulated IPv4 packet = (the subject is only MAP-E, not MAP-T or 4rd). yes. > (b) With the proposed IID format, the length of the PSID cannot be = determined without looking at the applicable mapping rule. (As already = noted, the number of zeroes at the end of the PSID isn't specified in = the address).=20 correct. > (c) Once the rule is looked at, getting the PSID is easy (no more = magic needed than to get find the PSID length ;-)). unless you are in 1:1 mode. >> In addition, it has the desirable characteristic of creating an IID. >=20 > A constant IID was the logic proposal for the original Encapsulation = solution (then called "4rd" before becoming "MAP-E", ref. = tools.ietf.org/html/draft-murakami-softwire-4rd-01). > It is only when we tried to merge -E it with -T that we abandoned this = simplicity.=20 simplicity for whom? the interface-id is constant for the MAP node. I have not heard any = implementors state it is hard enough to be worth arguing over whether to write an IPv4 address in there rather than a set = of zeroes. what is simplest for the operator? having to calculate the IPv4 address = based on the rules? or look at the IPv4 address in the IID? > (Incidentally, to avoid limitation (b) above, we introduced that at = that time a PSID-length field in IIDs (ref. = www.ietf.org/mail-archive/web/softwires/current/msg02994.html), but this = complexity would be superfluous for MAP-E.)=20 to summarise, your proposal is to overlap with the subnet router anycast = address, i.e. all zeroes? cheers, Ole= From wdec.ietf@gmail.com Tue Jan 29 02:41:23 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B2F121F881E for ; Tue, 29 Jan 2013 02:41:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.448 X-Spam-Level: X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bbaqE-078t+4 for ; Tue, 29 Jan 2013 02:41:22 -0800 (PST) Received: from mail-qa0-f53.google.com (mail-qa0-f53.google.com [209.85.216.53]) by ietfa.amsl.com (Postfix) with ESMTP id 8D83621F881D for ; Tue, 29 Jan 2013 02:41:22 -0800 (PST) Received: by mail-qa0-f53.google.com with SMTP id z4so210646qan.12 for ; Tue, 29 Jan 2013 02:41:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=aIrJacnYZEQLyus29iVzZOsJ//MA793lc7aCH4k5+Yc=; b=N7C359/Up96PoBW8Y7pHnGWwEuk/WhN/GZhDOuL+9yLSPZegRSQSqIVTvNsSBbrKQD fuPxS++tV3jp3EPW6Jf720Eq+SpdmfbPodK2cn91nmudrZyEy/JmjkbhL+ObtKWEVO/5 DrO41sUJS15HRSgB37OIjwCGTbrqdNVNb2XS9MLfcgyFsMJW9yjvyBMkFViyo4Qv58cG HoK2rDvoG05z1kuzx5QPmT4ghHAU+8CFzHbTKhwYAZ0/q0XvQq7uy0nOAQWcBEkgVVx6 vkk+or/RuNOVFqZfM+Pdv3wdp05Wav2Dn9KEc1MNMoVCqlG8Sk8RTjxOh6rKq0Ds0rPU 6bdg== MIME-Version: 1.0 X-Received: by 10.49.133.68 with SMTP id pa4mr552918qeb.50.1359456081923; Tue, 29 Jan 2013 02:41:21 -0800 (PST) Received: by 10.49.75.33 with HTTP; Tue, 29 Jan 2013 02:41:21 -0800 (PST) In-Reply-To: References: <063.9dc31682f59256171b5d58fdb1cdcc5e@tools.ietf.org> <078.5016b38f0fa45b1e08acdf73cc564147@tools.ietf.org> Date: Tue, 29 Jan 2013 10:41:21 +0000 Message-ID: From: Wojciech Dec To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: multipart/alternative; boundary=047d7bd6b99cd9cffb04d46b08da Cc: "softwires@ietf.org WG" Subject: Re: [Softwires] [softwire] #19: IPv4 address superfluous in MAP-E Interface IDs X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 10:41:23 -0000 --047d7bd6b99cd9cffb04d46b08da Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 29 January 2013 09:37, R=E9mi Despr=E9s wrote= : > > The key is "keep it simple", with neither IPv4 addresses nor PSIDs in > MAP-E IIDs. > More explanations below. > An IID needs to be there. The IPv4+PSID is computed in any case and makes such a decent IID, without increasing implementation complexity. Peeking across layers, possibly encapsulation layers to obtain such useful, according to some operators, info is not conductive to making things simpler for anyone operating the network. It also does not complicate matters for those operators not planning to make any use of this info. As I mentioned, having a fixed length IPv4+PSID would be my preference. Regards, Woj. > > 2013-01-28 14:51, Wojciech Dec t : > > Hi, > > the IPv4 and PSID in the IID are particularly useful in cases of address > independence (ie 1:1). As said previously, the benefit is primarily in th= e > ability an operational facilitation, where an operator can easily > see/observe what IPv4 and PSID is being used by a given customer. This is > easier than to look at the v6 prefix and use some magic decoder ring. > > > (a) The IPv4 address already readable in the encapsulated IPv4 packet (th= e > subject is only MAP-E, not MAP-T or 4rd). > (b) With the proposed IID format, the length of the PSID cannot be > determined without looking at the applicable mapping rule. (As already > noted, the number of zeroes at the end of the PSID isn't specified in the > address). > (c) Once the rule is looked at, getting the PSID is easy (no more magic > needed than to get find the PSID length ;-)). > > > In addition, it has the desirable characteristic of creating an IID. > > > A constant IID was the logic proposal for the original Encapsulation > solution (then called "4rd" before becoming "MAP-E", ref. > tools.ietf.org/html/draft-murakami-softwire-4rd-01). > It is only when we tried to merge -E it with -T that we abandoned this > simplicity. > (Incidentally, to avoid limitation (b) above, we introduced that at that > time a PSID-length field in IIDs (ref. > www.ietf.org/mail-archive/web/softwires/current/msg02994.html), but this > complexity would be superfluous for MAP-E.) > > Regards, > RD > > > --047d7bd6b99cd9cffb04d46b08da Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 29 January 2013 09:37, R=E9mi Despr= =E9s <despres.remi@laposte.net> wrote:

The key is "ke= ep it simple", with neither IPv4 addresses nor PSIDs in MAP-E IIDs.=A0=
More explanations below.

An IID= needs to be there. The IPv4+PSID is computed in any case and makes such a = decent IID, without increasing implementation complexity. Peeking across la= yers, possibly encapsulation layers to obtain such useful, according to som= e operators, info is not conductive to making things simpler for anyone ope= rating the network. It also does not complicate matters for those operators= not planning to make any use of this info.

As I mentioned, having a fixed length IPv4+PSID would be my preference.=

Regards,
Woj.

2013-01-28 14:51, Wojciech Dec <wdec.ietf@gmail.com>t :

Hi,

the IPv4 and PSID i= n the IID are particularly useful in cases of address independence (ie 1:1)= . As said previously, the benefit is primarily in the ability an operationa= l facilitation, where an operator can easily see/observe what IPv4 and PSID= is being used by a given customer. This is easier than to look at the v6 p= refix and use some magic decoder ring.

(a) The IPv4 address already readabl= e in the encapsulated IPv4 packet (the subject is only MAP-E, not MAP-T or = 4rd).
(b) With the proposed IID format, the length of the PSID ca= nnot be determined without looking at the applicable mapping rule. (As alre= ady noted,=A0the number of=A0zeroes at the end of the PSID isn't specif= ied in the address).=A0
(c) Once the rule is looked at, getting the PSID is easy (no more magi= c needed than to get find the PSID length ;-)).
=A0
In addition, it has the desirable characteristic of creating an IID.

A constant IID was the logic proposal for th= e=A0original=A0Encapsulation solution (then called "4rd" before b= ecoming "MAP-E", ref.=A0tools.ietf.org/html/draft-mu= rakami-softwire-4rd-01).
It is only when we tried to merge -E it with -T that we abandoned this= simplicity.=A0
(Incidentally,=A0to avoid=A0limitation (b) above,= =A0we introduced=A0that=A0at that time=A0a PSID-length field in IIDs (ref. = www.ietf.org/mail-archive/web/softwires/current/msg= 02994.html), but this complexity would be superfluous for MAP-E.)=A0

Regards,
RD
=A0=A0


--047d7bd6b99cd9cffb04d46b08da-- From xing@cernet.edu.cn Tue Jan 29 05:35:01 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86F9C21F87CE for ; Tue, 29 Jan 2013 05:35:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -93.036 X-Spam-Level: X-Spam-Status: No, score=-93.036 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ng6LE5MRznjg for ; Tue, 29 Jan 2013 05:35:00 -0800 (PST) Received: from cernet.edu.cn (mail.cernet.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with ESMTP id 167A021F87CB for ; Tue, 29 Jan 2013 05:34:59 -0800 (PST) Received: by ajax-webmail-centos (Coremail) ; Tue, 29 Jan 2013 21:34:29 +0800 (CST) Date: Tue, 29 Jan 2013 21:34:29 +0800 (CST) From: =?GBK?B?wO7Qxw==?= To: wdec.ietf@gmail.com, softwires@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3853_17036063.1359466469930" X-Originating-IP: [203.126.197.101] X-Priority: 3 X-Mailer: Coremail Webmail Server Version XT2.1.3 build 110627(13838.3863.3865) Copyright (c) 2002-2013 www.mailtech.cn cernet X-CM-TRANSID: AQAAf3CboATmzwdRuxkHAA--.447W X-CM-SenderInfo: p0lqwqxfhu0vvwohv3gofq/1tbiAQAODE58k3BJtQABsv X-Coremail-Antispam: 1Ur529EdanIXcx71UUUUU7IcSsGvfJ3iIAIbVAYjsxI4VW3Jw CS07vEb4IE77IF4wCS07vE1I0E4x80FVAKz4kxMIAIbVAFxVCaYxvI4VCIwcAKzIAtYxBI daVFxhVjvjDU= Subject: Re: [Softwires] [softwire] #19: IPv4 address superfluous in MAP-E Interface IDs X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 13:35:01 -0000 ------=_Part_3853_17036063.1359466469930 Content-Type: text/plain; charset=GBK Content-Transfer-Encoding: base64 V29qY2llY2ggRGVjINC0tcA6CgoKT24gMjkgSmFudWFyeSAyMDEzIDA5OjM3LCBSqKZtaSBEZXNw cqimczxkZXNwcmVzLnJlbWlAbGFwb3N0ZS5uZXQ+IHdyb3RlOgoKCgpUaGUga2V5IGlzICJrZWVw IGl0IHNpbXBsZSIsIHdpdGggbmVpdGhlciBJUHY0IGFkZHJlc3NlcyBub3IgUFNJRHMgaW4gTUFQ LUUgSUlEcy4gCk1vcmUgZXhwbGFuYXRpb25zIGJlbG93LgoKQW4gSUlEIG5lZWRzIHRvIGJlIHRo ZXJlLiBUaGUgSVB2NCtQU0lEIGlzIGNvbXB1dGVkIGluIGFueSBjYXNlIGFuZCBtYWtlcyBzdWNo IGEgZGVjZW50IElJRCwgd2l0aG91dCBpbmNyZWFzaW5nIGltcGxlbWVudGF0aW9uIGNvbXBsZXhp dHkuIFBlZWtpbmcgYWNyb3NzIGxheWVycywgcG9zc2libHkgZW5jYXBzdWxhdGlvbiBsYXllcnMg dG8gb2J0YWluIHN1Y2ggdXNlZnVsLCBhY2NvcmRpbmcgdG8gc29tZSBvcGVyYXRvcnMsIGluZm8g aXMgbm90IGNvbmR1Y3RpdmUgdG8gbWFraW5nIHRoaW5ncyBzaW1wbGVyIGZvciBhbnlvbmUgb3Bl cmF0aW5nIHRoZSBuZXR3b3JrLiBJdCBhbHNvIGRvZXMgbm90IGNvbXBsaWNhdGUgbWF0dGVycyBm b3IgdGhvc2Ugb3BlcmF0b3JzIG5vdCBwbGFubmluZyB0byBtYWtlIGFueSB1c2Ugb2YgdGhpcyBp bmZvLgoKQXMgSSBtZW50aW9uZWQsIGhhdmluZyBhIGZpeGVkIGxlbmd0aCBJUHY0K1BTSUQgd291 bGQgYmUgbXkgcHJlZmVyZW5jZS4KCgpmdWxseSBhZ3JlZSB3aXRoIFdvai4geGluZwoKCgpSZWdh cmRzLApXb2ouCgoKCjIwMTMtMDEtMjggMTQ6NTEsIFdvamNpZWNoIERlYyA8d2RlYy5pZXRmQGdt YWlsLmNvbT50IDoKCkhpLAoKdGhlIElQdjQgYW5kIFBTSUQgaW4gdGhlIElJRCBhcmUgcGFydGlj dWxhcmx5IHVzZWZ1bCBpbiBjYXNlcyBvZiBhZGRyZXNzIGluZGVwZW5kZW5jZSAoaWUgMToxKS4g QXMgc2FpZCBwcmV2aW91c2x5LCB0aGUgYmVuZWZpdCBpcyBwcmltYXJpbHkgaW4gdGhlIGFiaWxp dHkgYW4gb3BlcmF0aW9uYWwgZmFjaWxpdGF0aW9uLCB3aGVyZSBhbiBvcGVyYXRvciBjYW4gZWFz aWx5IHNlZS9vYnNlcnZlIHdoYXQgSVB2NCBhbmQgUFNJRCBpcyBiZWluZyB1c2VkIGJ5IGEgZ2l2 ZW4gY3VzdG9tZXIuIFRoaXMgaXMgZWFzaWVyIHRoYW4gdG8gbG9vayBhdCB0aGUgdjYgcHJlZml4 IGFuZCB1c2Ugc29tZSBtYWdpYyBkZWNvZGVyIHJpbmcuCgoKCihhKSBUaGUgSVB2NCBhZGRyZXNz IGFscmVhZHkgcmVhZGFibGUgaW4gdGhlIGVuY2Fwc3VsYXRlZCBJUHY0IHBhY2tldCAodGhlIHN1 YmplY3QgaXMgb25seSBNQVAtRSwgbm90IE1BUC1UIG9yIDRyZCkuCihiKSBXaXRoIHRoZSBwcm9w b3NlZCBJSUQgZm9ybWF0LCB0aGUgbGVuZ3RoIG9mIHRoZSBQU0lEIGNhbm5vdCBiZSBkZXRlcm1p bmVkIHdpdGhvdXQgbG9va2luZyBhdCB0aGUgYXBwbGljYWJsZSBtYXBwaW5nIHJ1bGUuIChBcyBh bHJlYWR5IG5vdGVkLCB0aGUgbnVtYmVyIG9mIHplcm9lcyBhdCB0aGUgZW5kIG9mIHRoZSBQU0lE IGlzbid0IHNwZWNpZmllZCBpbiB0aGUgYWRkcmVzcykuIAooYykgT25jZSB0aGUgcnVsZSBpcyBs b29rZWQgYXQsIGdldHRpbmcgdGhlIFBTSUQgaXMgZWFzeSAobm8gbW9yZSBtYWdpYyBuZWVkZWQg dGhhbiB0byBnZXQgZmluZCB0aGUgUFNJRCBsZW5ndGggOy0pKS4KIApJbiBhZGRpdGlvbiwgaXQg aGFzIHRoZSBkZXNpcmFibGUgY2hhcmFjdGVyaXN0aWMgb2YgY3JlYXRpbmcgYW4gSUlELgoKCgpB IGNvbnN0YW50IElJRCB3YXMgdGhlIGxvZ2ljIHByb3Bvc2FsIGZvciB0aGUgb3JpZ2luYWwgRW5j YXBzdWxhdGlvbiBzb2x1dGlvbiAodGhlbiBjYWxsZWQgIjRyZCIgYmVmb3JlIGJlY29taW5nICJN QVAtRSIsIHJlZi4gdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1tdXJha2FtaS1zb2Z0d2lyZS00 cmQtMDEpLgpJdCBpcyBvbmx5IHdoZW4gd2UgdHJpZWQgdG8gbWVyZ2UgLUUgaXQgd2l0aCAtVCB0 aGF0IHdlIGFiYW5kb25lZCB0aGlzIHNpbXBsaWNpdHkuIAooSW5jaWRlbnRhbGx5LCB0byBhdm9p ZCBsaW1pdGF0aW9uIChiKSBhYm92ZSwgd2UgaW50cm9kdWNlZCB0aGF0IGF0IHRoYXQgdGltZSBh IFBTSUQtbGVuZ3RoIGZpZWxkIGluIElJRHMgKHJlZi53d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZl L3dlYi9zb2Z0d2lyZXMvY3VycmVudC9tc2cwMjk5NC5odG1sKSwgYnV0IHRoaXMgY29tcGxleGl0 eSB3b3VsZCBiZSBzdXBlcmZsdW91cyBmb3IgTUFQLUUuKSAKCgpSZWdhcmRzLApSRAogIAoKCgoK CgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClNvZnR3 aXJlcyBtYWlsaW5nIGxpc3QKU29mdHdpcmVzQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc29mdHdpcmVzCgoKCgo= ------=_Part_3853_17036063.1359466469930 Content-Type: text/html; charset=GBK Content-Transfer-Encoding: base64 V29qY2llY2ggRGVjINC0tcA6CjxibG9ja3F1b3RlIGNpdGU9Im1pZDpDQUZGalc0aFJVaWk1WHpG aTBtbTJSQk9aSk81Y0hTS0E1VGkyZE51akQwRVVhWnhxa1FAbWFpbC5nbWFpbC5jb20iIHR5cGU9 ImNpdGUiPjxicj4KICA8YnI+CiAgPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIDI5IEphbnVh cnkgMjAxMyAwOTozNywgUqimbWkgRGVzcHKopnMgPHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBtb3ot ZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9Im1haWx0bzpkZXNwcmVzLnJlbWlAbGFwb3N0ZS5uZXQi IHRhcmdldD0iX2JsYW5rIj5kZXNwcmVzLnJlbWlAbGFwb3N0ZS5uZXQ8L2E+Jmd0Ozwvc3Bhbj4g d3JvdGU6PGJyPjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9ImJvcmRlci1s ZWZ0OiAxcHggc29saWQgcmdiKDIwNCwgMjA0LCAyMDQpOyBtYXJnaW46IDBwdCAwcHQgMHB0IDAu OGV4OyBwYWRkaW5nLWxlZnQ6IDFleDsiPgo8ZGl2IHN0eWxlPSIiPjxkaXY+PGJyPjwvZGl2Pjxk aXY+VGhlIGtleSBpcyAia2VlcCBpdCBzaW1wbGUiLCB3aXRoIG5laXRoZXIgSVB2NCBhZGRyZXNz ZXMgbm9yIFBTSURzIGluIE1BUC1FIElJRHMuJm5ic3A7PC9kaXY+PGRpdj5Nb3JlIGV4cGxhbmF0 aW9ucyBiZWxvdy48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PGRpdj48YnI+QW4KSUlEIG5lZWRz IHRvIGJlIHRoZXJlLiBUaGUgSVB2NCtQU0lEIGlzIGNvbXB1dGVkIGluIGFueSBjYXNlIGFuZCBt YWtlcwpzdWNoIGEgZGVjZW50IElJRCwgd2l0aG91dCBpbmNyZWFzaW5nIGltcGxlbWVudGF0aW9u IGNvbXBsZXhpdHkuClBlZWtpbmcgYWNyb3NzIGxheWVycywgcG9zc2libHkgZW5jYXBzdWxhdGlv biBsYXllcnMgdG8gb2J0YWluIHN1Y2gKdXNlZnVsLCBhY2NvcmRpbmcgdG8gc29tZSBvcGVyYXRv cnMsIGluZm8gaXMgbm90IGNvbmR1Y3RpdmUgdG8gbWFraW5nCnRoaW5ncyBzaW1wbGVyIGZvciBh bnlvbmUgb3BlcmF0aW5nIHRoZSBuZXR3b3JrLiBJdCBhbHNvIGRvZXMgbm90CmNvbXBsaWNhdGUg bWF0dGVycyBmb3IgdGhvc2Ugb3BlcmF0b3JzIG5vdCBwbGFubmluZyB0byBtYWtlIGFueSB1c2Ug b2YKdGhpcyBpbmZvLjxicj4KPGJyPkFzIEkgbWVudGlvbmVkLCBoYXZpbmcgYSBmaXhlZCBsZW5n dGggSVB2NCtQU0lEIHdvdWxkIGJlIG15IHByZWZlcmVuY2UuIDxicj48L2Rpdj48L2Rpdj4KPC9i bG9ja3F1b3RlPgo8YnI+CmZ1bGx5IGFncmVlIHdpdGggV29qLiB4aW5nPGJyPgo8YnI+CjxibG9j a3F1b3RlIGNpdGU9Im1pZDpDQUZGalc0aFJVaWk1WHpGaTBtbTJSQk9aSk81Y0hTS0E1VGkyZE51 akQwRVVhWnhxa1FAbWFpbC5nbWFpbC5jb20iIHR5cGU9ImNpdGUiPgogIDxkaXYgY2xhc3M9Imdt YWlsX3F1b3RlIj4KICA8ZGl2Pjxicj5SZWdhcmRzLDxicj5Xb2ouPGJyPjwvZGl2Pgo8YmxvY2tx dW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJib3JkZXItbGVmdDogMXB4IHNvbGlkIHJn YigyMDQsIDIwNCwgMjA0KTsgbWFyZ2luOiAwcHQgMHB0IDBwdCAwLjhleDsgcGFkZGluZy1sZWZ0 OiAxZXg7Ij48ZGl2IHN0eWxlPSIiPgo8ZGl2Pjxicj48ZGl2PjxkaXY+MjAxMy0wMS0yOCAxNDo1 MSwgV29qY2llY2ggRGVjICZsdDs8YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9Im1haWx0 bzp3ZGVjLmlldGZAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+d2RlYy5pZXRmQGdtYWlsLmNv bTwvYT4mZ3Q7dCA6PC9kaXY+PGRpdiBjbGFzcz0iaW0iPjxicj48YmxvY2txdW90ZSB0eXBlPSJj aXRlIj5IaSw8YnI+PGJyPnRoZQpJUHY0IGFuZCBQU0lEIGluIHRoZSBJSUQgYXJlIHBhcnRpY3Vs YXJseSB1c2VmdWwgaW4gY2FzZXMgb2YgYWRkcmVzcwppbmRlcGVuZGVuY2UgKGllIDE6MSkuIEFz IHNhaWQgcHJldmlvdXNseSwgdGhlIGJlbmVmaXQgaXMgcHJpbWFyaWx5IGluCnRoZSBhYmlsaXR5 IGFuIG9wZXJhdGlvbmFsIGZhY2lsaXRhdGlvbiwgd2hlcmUgYW4gb3BlcmF0b3IgY2FuIGVhc2ls eQpzZWUvb2JzZXJ2ZSB3aGF0IElQdjQgYW5kIFBTSUQgaXMgYmVpbmcgdXNlZCBieSBhIGdpdmVu IGN1c3RvbWVyLiBUaGlzCmlzIGVhc2llciB0aGFuIHRvIGxvb2sgYXQgdGhlIHY2IHByZWZpeCBh bmQgdXNlIHNvbWUgbWFnaWMgZGVjb2RlciByaW5nLjxicj4KPC9ibG9ja3F1b3RlPjxkaXY+PGJy PjwvZGl2PjwvZGl2PjxkaXY+KGEpIFRoZSBJUHY0IGFkZHJlc3MgYWxyZWFkeSByZWFkYWJsZSBp biB0aGUgZW5jYXBzdWxhdGVkIElQdjQgcGFja2V0ICh0aGUgc3ViamVjdCBpcyBvbmx5IE1BUC1F LCBub3QgTUFQLVQgb3IgNHJkKS48L2Rpdj48ZGl2PihiKQpXaXRoIHRoZSBwcm9wb3NlZCBJSUQg Zm9ybWF0LCB0aGUgbGVuZ3RoIG9mIHRoZSBQU0lEIGNhbm5vdCBiZQpkZXRlcm1pbmVkIHdpdGhv dXQgbG9va2luZyBhdCB0aGUgYXBwbGljYWJsZSBtYXBwaW5nIHJ1bGUuIChBcyBhbHJlYWR5Cm5v dGVkLCZuYnNwO3RoZSBudW1iZXIgb2YmbmJzcDt6ZXJvZXMgYXQgdGhlIGVuZCBvZiB0aGUgUFNJ RCBpc24ndCBzcGVjaWZpZWQgaW4KdGhlIGFkZHJlc3MpLiZuYnNwOzwvZGl2Pgo8ZGl2PihjKSBP bmNlIHRoZSBydWxlIGlzIGxvb2tlZCBhdCwgZ2V0dGluZyB0aGUgUFNJRCBpcyBlYXN5IChubyBt b3JlIG1hZ2ljIG5lZWRlZCB0aGFuIHRvIGdldCBmaW5kIHRoZSBQU0lEIGxlbmd0aCA7LSkpLjwv ZGl2PjxkaXYgY2xhc3M9ImltIj48ZGl2PiZuYnNwOzwvZGl2PjxibG9ja3F1b3RlIHR5cGU9ImNp dGUiPgpJbiBhZGRpdGlvbiwgaXQgaGFzIHRoZSBkZXNpcmFibGUgY2hhcmFjdGVyaXN0aWMgb2Yg Y3JlYXRpbmcgYW4gSUlELjxicj48L2Jsb2NrcXVvdGU+PGRpdj48YnI+PC9kaXY+PC9kaXY+QSBj b25zdGFudCBJSUQgd2FzIHRoZSBsb2dpYyBwcm9wb3NhbCBmb3IgdGhlJm5ic3A7b3JpZ2luYWwm bmJzcDtFbmNhcHN1bGF0aW9uIHNvbHV0aW9uICh0aGVuIGNhbGxlZCAiNHJkIiBiZWZvcmUgYmVj b21pbmcgIk1BUC1FIiwgcmVmLiZuYnNwOzxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgaHJlZj0i aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbXVyYWthbWktc29mdHdpcmUtNHJkLTAx IiB0YXJnZXQ9Il9ibGFuayI+dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1tdXJha2FtaS1zb2Z0 d2lyZS00cmQtMDE8L2E+KS48L2Rpdj4KPGRpdj5JdCBpcyBvbmx5IHdoZW4gd2UgdHJpZWQgdG8g bWVyZ2UgLUUgaXQgd2l0aCAtVCB0aGF0IHdlIGFiYW5kb25lZCB0aGlzIHNpbXBsaWNpdHkuJm5i c3A7PC9kaXY+PGRpdj4oSW5jaWRlbnRhbGx5LCZuYnNwO3RvIGF2b2lkJm5ic3A7bGltaXRhdGlv biAoYikgYWJvdmUsJm5ic3A7d2UgaW50cm9kdWNlZCZuYnNwO3RoYXQmbmJzcDthdCB0aGF0IHRp bWUmbmJzcDthIFBTSUQtbGVuZ3RoIGZpZWxkIGluIElJRHMgKHJlZi4gPGEgbW96LWRvLW5vdC1z ZW5kPSJ0cnVlIiBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvc29m dHdpcmVzL2N1cnJlbnQvbXNnMDI5OTQuaHRtbCIgdGFyZ2V0PSJfYmxhbmsiPnd3dy5pZXRmLm9y Zy9tYWlsLWFyY2hpdmUvd2ViL3NvZnR3aXJlcy9jdXJyZW50L21zZzAyOTk0Lmh0bWw8L2E+KSwg YnV0IHRoaXMgY29tcGxleGl0eSB3b3VsZCBiZSBzdXBlcmZsdW91cyBmb3IgTUFQLUUuKSZuYnNw OzwvZGl2Pgo8ZGl2Pjxicj48L2Rpdj48ZGl2PlJlZ2FyZHMsPC9kaXY+PGRpdj5SRDwvZGl2Pjxk aXY+Jm5ic3A7Jm5ic3A7PGJyPjwvZGl2Pjxicj48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PC9k aXY+CiAgPGJyPgoKCiAgPHByZSB3cmFwPSIiPjxicj48aHIgc2l6ZT0iNCIgd2lkdGg9IjkwJSI+ PGJyPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPlNv ZnR3aXJlcyBtYWlsaW5nIGxpc3Q8YnI+U29mdHdpcmVzQGlldGYub3JnPGJyPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc29mdHdpcmVzPGJyPjwvcHJlPgo8L2Jsb2NrcXVv dGU+Cjxicj48YnI+PGJyPjxzcGFuPjwvc3Bhbj4= ------=_Part_3853_17036063.1359466469930-- From chenycmx@gmail.com Tue Jan 29 06:07:21 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC6E721F85AB for ; Tue, 29 Jan 2013 06:07:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.148 X-Spam-Level: X-Spam-Status: No, score=-1.148 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jsyNdd4zMPus for ; Tue, 29 Jan 2013 06:07:21 -0800 (PST) Received: from mail-ve0-f174.google.com (mail-ve0-f174.google.com [209.85.128.174]) by ietfa.amsl.com (Postfix) with ESMTP id E292621F85A4 for ; Tue, 29 Jan 2013 06:07:20 -0800 (PST) Received: by mail-ve0-f174.google.com with SMTP id c13so295240vea.33 for ; Tue, 29 Jan 2013 06:07:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=zst79jW5/WZIBXMB0rSVZ4ndFbKGdOEfDBf4mH9ATgs=; b=fK+PZnanCL8bX4Sa33woTIvl0TRfOlZnS1vC301YmpYMY1g/jmjZcn0PyPqgQWn9mM ymU8WCy8zQ5nOpXFxTeKogm5QD7YNO5JjV71BbL1Z4BQgrVsGLN9sGqp5fIqxj8kweJ+ kxCrZQpBoRNBOb3Dfzr4Yc00Nv33ILiJAbxcLpUFFOXEHyVNiUKoGHCrEGAo0ESV2qSN lyczCVjcj6tvHeKFY9xFKhnea8i1yHmpgtbIaIdQfLaN/+3bFACZA1P0SDfa9QVWWozj bXfORjOiWppmXRPD5oV+Dhgl7T56WYfx23+9/9fe3++jS93etzz8Rjhi5wdrpMYtq6CO C10Q== MIME-Version: 1.0 X-Received: by 10.52.69.74 with SMTP id c10mr983235vdu.3.1359468440245; Tue, 29 Jan 2013 06:07:20 -0800 (PST) Received: by 10.220.25.207 with HTTP; Tue, 29 Jan 2013 06:07:19 -0800 (PST) In-Reply-To: References: <510750C7.2010804@gmail.com> Date: Tue, 29 Jan 2013 22:07:19 +0800 Message-ID: From: Yuchi Chen To: Qi Sun , Tom Taylor Content-Type: multipart/alternative; boundary=bcaec501606576d75704d46de90a Cc: Softwires Subject: Re: [Softwires] draft-cui-softwire-b4-translated-ds-lite and MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 14:07:21 -0000 --bcaec501606576d75704d46de90a Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Dear Tom and Qi, Thanks for your support for moving lw4o6 forward. Lw4o6 is simple and easy to understand. The tests and trials that have been carried out show that lw4o6 is easy to implement and deploy, and it can work well in the address sharing scenario. As a participant of the lw4o6 demo in Atlanta, I was very glad and considered it a great honor to show out all the great features of lw4o6. IMHO, draft-cui-softwire-b4-translated-ds-lite is ready to move forward as well. Best regards! Yuchi Chen 2013/1/29 Qi Sun > > Dear Tom & all, > > IMHO, in addition to Tom's points, > draft-cui-softwire-b4-translated-ds-lite is easier for OAM because there = is > no port mapping algorithm. It does not require operators to plan IPv6 and > IPv4 address pool together, which is convenient for operators whose IPv4 > address pools are scattered, or IPv4/IPv6 address resources are managed b= y > different servers. > > Also, I think draft-cui-* is ready to move forward. > > > Best Regards, > Qi Sun > > > On 2013-1-29, at =CF=C2=CE=E712:32, Tom Taylor wrote: > > > I figured it was time to pick on someone else, so I reviewed > draft-cui-softwire-b4-translated-ds-lite. I found it really easy to > understand, and all I found to change was a couple of typos. > > > > Of course, one reason lw4o6 easier to read than MAP is because it does > not describe a port mapping algorithm. The other reason is because the MA= P > document has to describe the EA bits and their use. But that's a > fundamental difference between the two approaches, and I can't see much > chance to simplify MAP. The only possibility is to change the provisionin= g > approach to provision the Rule IPv6 prefix, the complete shared IPv4 > address, and the PSID explicitly, then describe how to construct the MAP > endpoint IPv6 address. > > > > Getting back to draft-cui-softwire-b4-translated-ds-lite, I'd say it's > ready to be adopted. > > > > Tom Taylor > > _______________________________________________ > > Softwires mailing list > > Softwires@ietf.org > > https://www.ietf.org/mailman/listinfo/softwires > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > --bcaec501606576d75704d46de90a Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable Dear Tom and Qi,

Thanks for your support for moving lw4o= 6 forward. Lw4o6 is simple and easy to understand. The tests and trials tha= t have been carried out show that lw4o6 is easy to implement and deploy, an= d it can work well in the address sharing scenario. As a participant of the= lw4o6 demo in Atlanta, I was very glad and considered it a great honor to = show out all the great features of lw4o6. IMHO, draft-cui-softwire-b4-trans= lated-ds-lite is ready to move forward as well. 
 
Best regards!
Yuchi Chen

2013/1/29 Qi Sun <sunqi.csnet.thu@gmail.com>

Dear Tom & all,

IMHO, in addition to Tom's points, draft-cui-softwire-b4-translated-ds-= lite is easier for OAM because there is no port mapping algorithm. It does = not require operators to plan IPv6 and IPv4 address pool together, which is= convenient for operators whose IPv4 address pools are scattered, or IPv4/I= Pv6 address resources are managed by different servers.

Also, I think draft-cui-* is ready to move forward.


Best Regards,
Qi Sun


On 2013-1-29, at =CF=C2=CE=E712:32, Tom Taylor wrote:

> I figured it was time to pick on someone else, so I reviewed draft-cui= -softwire-b4-translated-ds-lite. I found it really easy to understand, and = all I found to change was a couple of typos.
>
> Of course, one reason lw4o6 easier to read than MAP is because it does= not describe a port mapping algorithm. The other reason is because the MAP= document has to describe the EA bits and their use. But that's a funda= mental difference between the two approaches, and I can't see much chan= ce to simplify MAP. The only possibility is to change the provisioning appr= oach to provision the Rule IPv6 prefix, the complete shared IPv4 address, a= nd the PSID explicitly, then describe how to construct the MAP endpoint IPv= 6 address.
>
> Getting back to draft-cui-softwire-b4-translated-ds-lite, I'd say = it's ready to be adopted.
>
> Tom Taylor
> _______________________________________________
> Softwires mailing list
> Softwires@ietf= .org
> https://www.ietf.org/mailman/listinfo/softwires

_______________________________________________
Softwires mailing list
Softwires@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/softwires

--bcaec501606576d75704d46de90a-- From rajiva@cisco.com Tue Jan 29 06:59:57 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84CD221F8904; Tue, 29 Jan 2013 06:59:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IUJvjmCp3JoW; Tue, 29 Jan 2013 06:59:56 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 6646421F88A6; Tue, 29 Jan 2013 06:59:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5058; q=dns/txt; s=iport; t=1359471596; x=1360681196; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=w5dQrVPrc8YtHBOkccrJHEaNQPPhhSRjuxXqgTfPpUY=; b=lEHB0Xm4+WkAa+uIRUnOmpdzaDxNsfaRfFvecMIQACVwTgZATRGSZv8N p8KYoHkr/ZsVOYDYTOQsnhsG1i036Ea7/4JlTCq8/DEriMNtPrkMwLS7a uIucZrWwcm1rj0rbf1znRMHNfirEpBsPMyZJA1MaC7L8uVoHEBiYyA9dA Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAI3jB1GtJV2a/2dsb2JhbABEhka0HYMIcxZzgh4BAQEEAQEBMToLDAYBBgIRAwECAQQGHQUEHwYLFAYDCAIEAQ0FCId3AwYJDJM1mncIgj6GUgwBiVWBH4p1gRSCSjZhA5Q3gnKKHQOFD4J3giQ X-IronPort-AV: E=Sophos;i="4.84,561,1355097600"; d="scan'208";a="169819754" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP; 29 Jan 2013 14:59:33 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r0TExXRN011129 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Jan 2013 14:59:33 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.193]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Tue, 29 Jan 2013 08:59:32 -0600 From: "Rajiv Asati (rajiva)" To: "wang.cui1@zte.com.cn" , Wojciech Dec Thread-Topic: =?gb2312?B?W1NvZnR3aXJlc10gtPC4tDogUmU6ICBbc29mdHdpcmVdICMxOTogSVB2NCBh?= =?gb2312?Q?ddress_superfluous_in_MAP-E_Interface_IDs?= Thread-Index: AQHN/cm9GO4lAu0Nc0uF97eU1eCFCJhgd6gA Date: Tue, 29 Jan 2013 14:59:32 +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.2.5.121010 x-originating-ip: [10.82.214.169] Content-Type: text/plain; charset="gb2312" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "softwires@ietf.org WG" , "remi.despres@free.fr" , "softwires-bounces@ietf.org" Subject: Re: [Softwires] =?gb2312?b?tPC4tDogUmU6ICBbc29mdHdpcmVdICMxOTogSVB2?= =?gb2312?b?NCBhZGRyZXNzIHN1cGVyZmx1b3VzIGluIE1BUC1FIEludGVyZmFjZSBJRHM=?= X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 14:59:57 -0000 KzEgaW4ga2VlcGluZyBib3RoLg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog IndhbmcuY3VpMUB6dGUuY29tLmNuIiA8d2FuZy5jdWkxQHp0ZS5jb20uY24+DQpEYXRlOiBNb25k YXksIEphbnVhcnkgMjgsIDIwMTMgOTozOCBQTQ0KVG86IFdvamNpZWNoIERlYyA8d2RlYy5pZXRm QGdtYWlsLmNvbT4NCkNjOiBTb2Z0d2lyZXMtd2cgbGlzdCA8c29mdHdpcmVzQGlldGYub3JnPiwg InJlbWkuZGVzcHJlc0BmcmVlLmZyIg0KPHJlbWkuZGVzcHJlc0BmcmVlLmZyPiwgInNvZnR3aXJl cy1ib3VuY2VzQGlldGYub3JnIg0KPHNvZnR3aXJlcy1ib3VuY2VzQGlldGYub3JnPg0KU3ViamVj dDogW1NvZnR3aXJlc10gtPC4tDogUmU6ICBbc29mdHdpcmVdICMxOTogSVB2NCBhZGRyZXNzIHN1 cGVyZmx1b3VzIGluDQpNQVAtRSBJbnRlcmZhY2UgSURzDQoNCj4NCj5IaSwgDQo+DQo+ICBLZWVw aW5nIFBTSUQgaW4gSUlEcyBzZWVtcyByZXBlYXRlZCBmcm9tIHRoZSBhc3BlY3Qgb2YgMTI4LWJp dCBJUHY2DQo+YWRkcmVzcywgYnV0IGZyb20gdGhlIGFzcGVjdCBvZiA2NC1iaXQgSUlEcywgSVB2 NCBhZGRyZXNzIGFuZCBQU0lEDQo+Z3VhcmFudGVlIElJRHMgdG8gYmUgdW5pdmVyc2FsbHkgdW5p cXVlLg0KPg0KPiAgU28sICsxIEtlZXBpbmcgdGhlIElQdjQgYW5kIFBTSUQgaW4gSUlEcy4NCj4N Cj5CUnMgDQo+TGluZGEgV2FuZyANCj4NCj4NCj4NCj5Xb2pjaWVjaCBEZWMgPHdkZWMuaWV0ZkBn bWFpbC5jb20+DQo+t6K8/sjLOiAgc29mdHdpcmVzLWJvdW5jZXNAaWV0Zi5vcmcyMDEzLTAxLTI4 IDIxOjUxDQo+ytW8/sjLDQo+T2xlIFRyb2FuIDxvdHJvYW5AZW1wbG95ZWVzLm9yZz4gs63LzQ0K PiJzb2Z0d2lyZXNAaWV0Zi5vcmcgV0ciIDxzb2Z0d2lyZXNAaWV0Zi5vcmc+LCByZW1pLmRlc3By ZXNAZnJlZS5mctb3zOINCj5SZTogW1NvZnR3aXJlc10gW3NvZnR3aXJlXSAjMTk6IElQdjQgYWRk cmVzcyBzdXBlcmZsdW91cyBpbiBNQVAtRQ0KPkludGVyZmFjZSBJRHMNCj4NCj4NCj4NCj4NCj5I aSwNCj4NCj50aGUgSVB2NCBhbmQgUFNJRCBpbiB0aGUgSUlEIGFyZSBwYXJ0aWN1bGFybHkgdXNl ZnVsIGluIGNhc2VzIG9mIGFkZHJlc3MNCj5pbmRlcGVuZGVuY2UgKGllIDE6MSkuIEFzIHNhaWQg cHJldmlvdXNseSwgdGhlIGJlbmVmaXQgaXMgcHJpbWFyaWx5IGluDQo+dGhlIGFiaWxpdHkgYW4g b3BlcmF0aW9uYWwgZmFjaWxpdGF0aW9uLCB3aGVyZSBhbiBvcGVyYXRvciBjYW4gZWFzaWx5DQo+ c2VlL29ic2VydmUgd2hhdCBJUHY0IGFuZCBQU0lEIGlzIGJlaW5nIHVzZWQNCj4gYnkgYSBnaXZl biBjdXN0b21lci4gVGhpcyBpcyBlYXNpZXIgdGhhbiB0byBsb29rIGF0IHRoZSB2NiBwcmVmaXgg YW5kDQo+dXNlIHNvbWUgbWFnaWMgZGVjb2RlciByaW5nLg0KPkluIGFkZGl0aW9uLCBpdCBoYXMg dGhlIGRlc2lyYWJsZSBjaGFyYWN0ZXJpc3RpYyBvZiBjcmVhdGluZyBhbiBJSUQuDQo+DQo+KzEg VGh1cyB0byBrZWVwaW5nIHRoZSBJUHY0IGFuZCBQU0lELCBsaWtlbHkgaW4gYSBmaXhlZCBsZW5n dGggKDE2IGJpdCkNCj5maWVsZCBmb3JtYXQuDQo+DQo+UmVnYXJkcywNCj5Xb2ouDQo+DQo+T24g MjQgSmFudWFyeSAyMDEzIDE2OjI3LCBPbGUgVHJvYW4gPG90cm9hbkBlbXBsb3llZXMub3JnPiB3 cm90ZToNCj5oaSwNCj4NCj5jYW4gd2UgcGxlYXNlIGtlZXAgZGlzY3Vzc2lvbiBvbiB0aGUgbGlz dC4gbm90IHZpYSB0aGUgaXNzdWUgdHJhY2tlcj8NCj4NCj5kb2VzIGFueW9uZSBlbHNlIGhhdmUg YW4gb3Bpbmlvbj8NCj4oaWYgSSBkb24ndCBoZWFyIGFueXRoaW5nIGZyb20gYW55b25lIGVsc2Us IEknbGwgZGVmYXVsdCB0byBrZWVwIGN1cnJlbnQNCj50ZXh0LikNCj4NCj5jaGVlcnMsDQo+T2xl DQo+DQo+T24gSmFuIDI0LCAyMDEzLCBhdCAxNzoyMyAsIHNvZnR3aXJlIGlzc3VlIHRyYWNrZXIN Cj48dHJhYytzb2Z0d2lyZUB0b29scy5pZXRmLm9yZyA8bWFpbHRvOnRyYWMlMkJzb2Z0d2lyZUB0 b29scy5pZXRmLm9yZz4+DQo+d3JvdGU6DQo+DQo+PiAjMTk6IElQdjQgYWRkcmVzcyBzdXBlcmZs dW91cyBpbiBNQVAtRSBJbnRlcmZhY2UgSURzDQo+Pg0KPj4gQ2hhbmdlcyAoYnkgcmVtaS5kZXNw cmVzQGZyZWUuZnIpOg0KPj4NCj4+ICogcHJpb3JpdHk6ICB0cml2aWFsID0+IG1ham9yDQo+PiAq IHN0YXR1czogIGNsb3NlZCA9PiByZW9wZW5lZA0KPj4gKiByZXNvbHV0aW9uOiAgd29udGZpeCA9 Pg0KPj4NCj4+DQo+PiBDb21tZW50Og0KPj4NCj4+IFZhbHVlIG9mIGhhdmluZyB0aGUgUFNJRCBp biBNQVAtRSBJSURzIGZvciBtYWludGVuYW5jZSBpc24ndCBjbGVhciBhdA0KPj5hbGw6DQo+PiAt IFBTSUQgbGVuZ3RoIGlzbid0IGRldGVybWluZWQgaW4gSUlEcyAodGhlcmUgY2FuIGJlIGFuIHVu a25vd24gbnVtYmVyDQo+Pm9mDQo+PiB0cmFpbGluZyB6ZXJvZXMpDQo+PiAtIGFsbCBQU0lEIGJp dHMgYXJlIGFscmVhZHkgcmVhZGFibGUgaW4gdGhlIGZpcnN0IDY0IGJpdHMNCj4+DQo+PiBTdWdn ZXN0aW9uIHRvIGNsb3NlIHRoZSBpc3N1ZToNCj4+IC0ga2VlcCBJUHY0IGFkZHJlc3NlcyBpbiBJ SURzICh0aGV5IGNvbnRhaW5zIHNvbWUgYml0cyB0aGF0IGFyZW4ndCBpbg0KPj50aGUNCj4+IGZp cnN0IDY0IGJpdHMpDQo+PiAtIGRvbid0IGtlZXAgdGhlIFBTSUQgaW4gSUlEcyAoaW5zdWZmaWNp ZW50bHkganVzdGlmaWVkIGNvbXBsZXhpdHkpDQo+Pg0KPj4gLS0NCj4+IA0KPj4tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQo+Pi0tDQo+PiBSZXBvcnRlcjogICAgICAgICAgICAgICB8ICAgICAgIE93bmVyOiAg ZHJhZnQtaWV0Zi1zb2Z0d2lyZS0NCj4+ICByZW1pLmRlc3ByZXNAZnJlZS5mciAgIHwgIG1hcEB0 b29scy5pZXRmLm9yZw0KPj4gICAgIFR5cGU6ICBkZWZlY3QgICAgICAgfCAgICAgIFN0YXR1czog IHJlb3BlbmVkDQo+PiBQcmlvcml0eTogIG1ham9yICAgICAgICB8ICAgTWlsZXN0b25lOg0KPj4g Q29tcG9uZW50OiAgbWFwLWUgICAgICAgIHwgICAgIFZlcnNpb246DQo+PiBTZXZlcml0eTogIENh bmRpZGF0ZSAgICB8ICBSZXNvbHV0aW9uOg0KPj4gIFdHIERvY3VtZW50ICAgICAgICAgICAgfA0K Pj4gS2V5d29yZHM6ICAgICAgICAgICAgICAgfA0KPj4gDQo+Pi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+ LS0NCj4+DQo+PiBUaWNrZXQgVVJMOiANCj4+PGh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dn L3NvZnR3aXJlL3RyYWMvdGlja2V0LzE5I2NvbW1lbnQ6ND4NCj4+IHNvZnR3aXJlIDxodHRwOi8v dG9vbHMuaWV0Zi5vcmcvc29mdHdpcmUvPg0KPj4NCj4NCj5fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPlNvZnR3aXJlcyBtYWlsaW5nIGxpc3QNCj5Tb2Z0 d2lyZXNAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Nv ZnR3aXJlcw0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+U29mdHdpcmVzIG1haWxpbmcgbGlzdA0KPlNvZnR3aXJlc0BpZXRmLm9yZw0KPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc29mdHdpcmVzDQo+DQoNCg== From bingxuere@gmail.com Tue Jan 29 07:23:02 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3626F21F886C for ; Tue, 29 Jan 2013 07:23:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.765 X-Spam-Level: X-Spam-Status: No, score=-2.765 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id muFYT-v9WHRl for ; Tue, 29 Jan 2013 07:23:01 -0800 (PST) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by ietfa.amsl.com (Postfix) with ESMTP id C290F21F85E8 for ; Tue, 29 Jan 2013 07:23:00 -0800 (PST) Received: by mail-ob0-f182.google.com with SMTP id va7so512131obc.41 for ; Tue, 29 Jan 2013 07:23:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=/nTfQ//+1AYifRJ2Hod7sWRJHixuZlH8BFXcDrf6tPk=; b=eQlfGtxBu3/js48rFB/UtdFKkvwONDo00Z2ES5w+Yv7JzSm2o34FDU+gZHdRoXCSLv f2AMImqmwjUS1FJKLQkpk3aph9Emtg6r19ATYWi19UP3/YuXobC6btVK3BgP+GNQd0WV HEuaEOc2JAGLDhnSozWaoM/1XQj4zb5LtJO9ZuZuIrilrKZjNYUagF/u1Af2ymvxGPZz 2+C9DuSmJy3W3hdiOVX5rjhRsYVU8L90/tdEWvzdFrex5A1B7jpT7/yGRmVtFK+7jKkc 3GQbu1f+TKNv2VwskUAhDpyr+E08NMEiZjVizy2QGL6C0gN4MSsZg5BnpfTEdJb1vAjg AnHQ== X-Received: by 10.182.207.70 with SMTP id lu6mr947463obc.78.1359472980284; Tue, 29 Jan 2013 07:23:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.80.133 with HTTP; Tue, 29 Jan 2013 07:22:20 -0800 (PST) In-Reply-To: <510750C7.2010804@gmail.com> References: <510750C7.2010804@gmail.com> From: Qiong Date: Tue, 29 Jan 2013 23:22:20 +0800 Message-ID: To: Tom Taylor Content-Type: multipart/alternative; boundary=e89a8f5039aa1254c804d46ef807 Cc: Softwires Subject: Re: [Softwires] draft-cui-softwire-b4-translated-ds-lite and MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 15:23:02 -0000 --e89a8f5039aa1254c804d46ef807 Content-Type: text/plain; charset=UTF-8 Dear Tom, On Tue, Jan 29, 2013 at 12:32 PM, Tom Taylor wrote: > I figured it was time to pick on someone else, so I reviewed > draft-cui-softwire-b4-**translated-ds-lite. I found it really easy to > understand, and all I found to change was a couple of typos. > > Of course, one reason lw4o6 easier to read than MAP is because it does not > describe a port mapping algorithm. The other reason is because the MAP > document has to describe the EA bits and their use. But that's a > fundamental difference between the two approaches, and I can't see much > chance to simplify MAP. The only possibility is to change the provisioning > approach to provision the Rule IPv6 prefix, the complete shared IPv4 > address, and the PSID explicitly, then describe how to construct the MAP > endpoint IPv6 address. > [Qiong] Right. You have just pointed out some essential differences between MAP and lw4o6. Actually, the major difference is not to use an algorithm or not . Even for DS-Lite and NAT444, most vendors have already implemented some kind of algorithm in AFTR to map between IPv6 address pool, IPv4 address pool and port-set. The key here is whether to import these algorithm parameters EXPLICITLY into IPv6 address or not. Lw4o6 does not import anything into IPv6 address. The AFTR can/or can not implement an algorithm for mapping between IPv6 address pool, IPv4 address pool and port-set, which is only an implementation choice. But it can truely gain more flexibility for operators to use/define freely of their own IPv6 address, and you can also achieve very good features like scalibility, no-NAT in AFTR, reduced syslog messages, etc. Besides, I have to say again that this solution is quite simple. Before the demo in IETF85, most vendors only took 3~4 weeks to understand, design, and finish implementing the whole functionalities. For operators, we also find it very simple to run it, just configuring your available IPv6 address pools, IPv4 address pools and port-set quota is enough. That's why we like it, and hope it will be helpful for more people. Best wishes Qiong > > Getting back to draft-cui-softwire-b4-**translated-ds-lite, I'd say it's > ready to be adopted. > > Tom Taylor > ______________________________**_________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/**listinfo/softwires > -- ============================================== Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/* PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * =============================================== --e89a8f5039aa1254c804d46ef807 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Tom,

On Tue, Jan 29, 2013 at 12:32 PM, Tom Taylor <tom.ta= ylor.stds@gmail.com> wrote:
I figured it was time to pick on someone else, so I review= ed draft-cui-softwire-b4-translated-ds-lite. I found it really easy = to understand, and all I found to change was a couple of typos.

Of course, one reason lw4o6 easier to read than MAP is because it does not = describe a port mapping algorithm. The other reason is because the MAP docu= ment has to describe the EA bits and their use. But that's a fundamenta= l difference between the two approaches, and I can't see much chance to= simplify MAP. The only possibility is to change the provisioning approach = to provision the Rule IPv6 prefix, the complete shared IPv4 address, and th= e PSID explicitly, then describe how to construct the MAP endpoint IPv6 add= ress.
[Qiong] Right. You have just pointed out some essen= tial differences between MAP and lw4o6.=C2=A0

Actually, the major difference is not to use an algorithm or not . = Even for DS-Lite and NAT444, most vendors have already implemented some kin= d of algorithm in AFTR to map between IPv6 address pool, IPv4 address pool = and port-set. The key here is whether to import these algorithm parameters = EXPLICITLY into IPv6 address or not.=C2=A0Lw4o6 does not import anything in= to IPv6 address. The AFTR can/or can not implement an algorithm for mapping= between=C2=A0IPv6 address pool, IPv4 address pool and port-set, which is o= nly an implementation choice. But it can truely=C2=A0gain more flexibility = for operators to use/define freely of their own IPv6 address, and you can a= lso achieve very good features like scalibility, no-NAT in AFTR, reduced sy= slog messages, etc.=C2=A0

Besides, I have to say again that this solu= tion is quite simple. Before the demo in IETF85, most vendors only took 3~4= weeks to understand, design, and finish implementing the whole functionali= ties. For operators, we also find it very simple to run it, just configurin= g your available IPv6 address pools, IPv4 address pools and port-set quota = is enough.=C2=A0

That's why we like it, and hope it will= be helpful for more people.

Best wish= es
Qiong
=C2=A0=C2=A0

Getting back to draft-cui-softwire-b4-translated-ds-lite, I'd sa= y it's ready to be adopted.
Tom Taylor
_______________________________________________
Softwires mailing list
Softwires@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/softwires



-- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 cod= e:
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
--e89a8f5039aa1254c804d46ef807-- From despres.remi@laposte.net Tue Jan 29 07:24:25 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 127E321F886F for ; Tue, 29 Jan 2013 07:24:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZlX82iheKCX4 for ; Tue, 29 Jan 2013 07:24:24 -0800 (PST) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19A8821F886C for ; Tue, 29 Jan 2013 07:24:24 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2121.sfr.fr (SMTP Server) with ESMTP id 00CEF700020B; Tue, 29 Jan 2013 16:24:23 +0100 (CET) Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2121.sfr.fr (SMTP Server) with ESMTP id A812A7000047; Tue, 29 Jan 2013 16:24:22 +0100 (CET) X-SFR-UUID: 20130129152422688.A812A7000047@msfrf2121.sfr.fr Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= In-Reply-To: <8B5A2979-6E57-4E1F-B3A8-5450F9B39CD8@employees.org> Date: Tue, 29 Jan 2013 16:24:22 +0100 Message-Id: <8B11B4F3-8406-4B92-86AE-C4ADBC708417@laposte.net> References: <063.9dc31682f59256171b5d58fdb1cdcc5e@tools.ietf.org> <078.5016b38f0fa45b1e08acdf73cc564147@tools.ietf.org> <8B5A2979-6E57-4E1F-B3A8-5450F9B39CD8@employees.org> To: "softwires@ietf.org WG" X-Mailer: Apple Mail (2.1499) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [Softwires] 1:1 MAP-E with shared addresses X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 15:24:25 -0000 2013-01-29 10:50, Ole Troan : > ... >> (c) Once the rule is looked at, getting the PSID is easy (no more = magic needed than to get find the PSID length ;-)). >=20 > unless you are in 1:1 mode. There is a point here which AFAIK has never been discussed before. =20 (A reference is welcome if there is one I missed). This point concerns 1:1 mappings (if needed in MAP-E), when combined = with shared IPv4 addresses:=20 - To be assigned a shared address, a CE needs a PSID in addition to its = IPv4 address. - Currently, this PSID cannot be found in the 1:1 rule itself (ref. = http://tools.ietf.org/html/draft-ietf-softwire-map-dhcp-01.) The approach that is in my understanding implied by Ole is that each = concerned CE will be delegated a MAP-E IPv6 prefix, in addition to that = used for native IPv6 addressing, with the PSID in it. (The detailed = format isn't specified yet AFAIK, but specifying one is possible.)=20 Another approach, AFAIK much simpler in operations, is to add a rule = parameter to assign a PSID, present in 1:1 rules.=20 This eliminates the need to delegate to each CE an additional IPv6 = prefix.=20 Example: . CE delegated prefix: 2001:db8:0:100::/56 . BMR for this CE Rule IPv6 prefix : 2001:db8:0:100:/56 EA-bits length : 0 Rule IPv4 prefix : 1.1.1.1/32 PSID : 0x11 =20 Conclusion: if 1:1 mappings are part of MAP-E, add a PSID parameter in = 1:1 mapping rules. (Otherwise: (1) specify detailed formats of MAP-E specific delegated = prefixes > /64; (2) explain why delegated prefixes used for IPV6 aren't = found sufficient.) Regards, RD >>>> 2001:db8::1 >>>> Rule IPv6 prefix: 2001:db8::1/128 >>>> Rule IPv4 prefix: 1.1.1.1/32 >>>> EA-bits length: 0 >>> In addition, it has the desirable characteristic of creating an IID. >>=20 >> A constant IID was the logic proposal for the original Encapsulation = solution (then called "4rd" before becoming "MAP-E", ref. = tools.ietf.org/html/draft-murakami-softwire-4rd-01). >> It is only when we tried to merge -E it with -T that we abandoned = this simplicity.=20 >=20 > simplicity for whom? > the interface-id is constant for the MAP node. I have not heard any = implementors state it is hard enough to be worth > arguing over whether to write an IPv4 address in there rather than a = set of zeroes. > what is simplest for the operator? having to calculate the IPv4 = address based on the rules? or look at the IPv4 address in the IID? >=20 >> (Incidentally, to avoid limitation (b) above, we introduced that at = that time a PSID-length field in IIDs (ref. = www.ietf.org/mail-archive/web/softwires/current/msg02994.html), but this = complexity would be superfluous for MAP-E.)=20 >=20 > to summarise, your proposal is to overlap with the subnet router = anycast address, i.e. all zeroes? This has been discussed long ago. Following a comment made by Wojciech = if I remember right, the constant value can be a 1 to avoid any risk of = conflict with the subnet router anycast address. =20 >=20 > cheers, > Ole From despres.remi@laposte.net Tue Jan 29 08:16:49 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98DF821F87BB; Tue, 29 Jan 2013 08:16:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0KGcaUgkOjdz; Tue, 29 Jan 2013 08:16:48 -0800 (PST) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.82]) by ietfa.amsl.com (Postfix) with ESMTP id 4D0D021F86A8; Tue, 29 Jan 2013 08:16:48 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2408.sfr.fr (SMTP Server) with ESMTP id 1F3737000676; Tue, 29 Jan 2013 17:16:47 +0100 (CET) Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2408.sfr.fr (SMTP Server) with ESMTP id B15BD7000673; Tue, 29 Jan 2013 17:16:46 +0100 (CET) X-SFR-UUID: 20130129161646726.B15BD7000673@msfrf2408.sfr.fr Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 29 Jan 2013 17:16:47 +0100 Message-Id: <48EF9535-C8FC-47BB-8371-05692F791A3E@laposte.net> References: To: wang.cui1@zte.com.cn X-Mailer: Apple Mail (2.1499) Content-Type: multipart/alternative; boundary="Apple-Mail=_AF3594C5-F163-48CE-A129-504899A74A85" Cc: Softwires , softwires-bounces@ietf.org Subject: Re: [Softwires] Limiting the length of the MAP endpoint IPv6 prefix X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 16:16:49 -0000 --Apple-Mail=_AF3594C5-F163-48CE-A129-504899A74A85 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Linda, 2013-01-29 =C3=A0 07:54, wang.cui1@zte.com.cn a =C3=A9crit : >=20 > Hi,Remi=20 > =20 >=20 > softwires-bounces@ietf.org =E5=86=99=E4=BA=8E 2013-01-29 00:16:32: >=20 > > Senthil, > >=20 > >=20 > > 2013-01-2815:24, Senthil Sivakumar (ssenthil) = : > >=20 > > > I believe the prefix length > 64 should be allowed. > >=20 > >=20 > > > It is upto the > > > operator to choose the prefix length of their choice. > >=20 > > Agreed. > > No one suggest to say the contrary. > >=20 > > Yet, operators have the constraint of RFC 4291 that "For all unicast > > addresses, except those that start with the binary value 000,=20 > > Interface IDs are required to be 64 bits long and to be constructed=20= > > in Modified EUI-64 format". =20 > >=20 > > The draft says that: > > (a) The PSID is: > > +--+---+---+---+---+---+---+---+---+ > > |PL| 8 16 24 32 40 48 56 | > > +--+---+---+---+---+---+---+---+---+ > > |64| u | IPv4 address | PSID | 0 | > > +--+---+---+---+---+---+---+---+---+ > > (b) "If the End-user IPv6 prefix length is larger than 64, the most=20= > > significant parts of the interface identifier is overwritten by the = prefix." > >=20 > > This is particularly unclear: > > - What happens to the u octet? > > - And to the IPv4 address if the prefix is longer than /68?=20 >=20 > Remi, you mean the prefix is longer than /68 or /78? Oops, I meant longer than 64 + 8, i.e. 72. Thank you. > I think /68(64+4) prefix doesn't overwrite IPv4 address.=20 >=20 > BRs=20 > Linda Wang=20 >=20 >=20 > > - ... > >=20 > > Of course, if a use case is provided where MAP-E would be actually=20= > > used with an IID shorter than 64 bits, it should be discussed. But: > > - There is no such use case so far.=20 > > - Looking for one doesn't seem useful.=20 > >=20 > >=20 > > Regards, > > RD > >=20 > > =20 > > >=20 > > > On 1/28/13 8:59 AM, "Ole Troan" wrote: > > >=20 > > >>>>>=20 > > >>>>> The examples in my previous note sort of provided backing for = my view > > >>>>> that the MAP endpoint IPv6 prefix can be limited to a maximum = of a > > >>>>> /64, thus making the IID fully conformant both to RFC 4291 and = to RFC > > >>>>> 6052. > > >>>>>=20 > > >>> ... > > >>>=20 > > >>>>>=20 > > >>>>> I think limiting the prefix length to 64 bits is reasonable. = Comments? > > >>>>=20 > > >>>> I don't think that's reasonable. > > >>>> and I don't see what it buys us, given that supporting prefix = lengths > > >>>> longer than 64 is simple. > > >>>> IPv6 isn't classfull, there isn't anything magic with the 64 = boundary. > > >>>> ;-) > > >>>>=20 > > >>>> cheers, > > >>>> Ole > > >>>>=20 > > >>>=20 > > >>> OK, then I agree with R=C3=A9mi. Drop mention of prefixes = greater than 64 > > >>> bits long and leave it to the reader to judge whether RFC 4291 = imposes a > > >>> limit. > > >>=20 > > >> you want this removed: > > >> If the End-user IPv6 prefix length is larger than 64, the = most > > >> significant parts of the interface identifier is overwritten = by the > > >> prefix. > > >>=20 > > >> I disagree. this is the only text in there suggesting to an = implementor > > >> that prefix lengths can be any value between 0-128. > > >>=20 > > >> Tom, Remi and I have stated our opinions. does anyone else have a = view on > > >> the matter? > > >>=20 > > >> cheers, > > >> Ole > > >> _______________________________________________ > > >> Softwires mailing list > > >> Softwires@ietf.org > > >> https://www.ietf.org/mailman/listinfo/softwires > > >=20 > > > _______________________________________________ > > > Softwires mailing list > > > Softwires@ietf.org > > > https://www.ietf.org/mailman/listinfo/softwires > > _______________________________________________ > > Softwires mailing list > > Softwires@ietf.org > > https://www.ietf.org/mailman/listinfo/softwires --Apple-Mail=_AF3594C5-F163-48CE-A129-504899A74A85 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, = Linda,

2013-01-29 =C3=A0 07:54, wang.cui1@zte.com.cn a =C3=A9crit= :

=
Hi,Remi
 

softwires-bounces@ietf.org = =E5=86=99=E4=BA=8E 2013-01-29 00:16:32:

> Senthil,
>
>
> 2013-01-2815:24, Senthil Sivakumar (ssenthil) <ssenthil@cisco.com>  :
>
> > I believe the prefix length > 64 should be allowed.
>
>
> > It is upto the
> > operator to choose the prefix length of their choice.
>
> Agreed.
> No one suggest to say the contrary.
>
> Yet, operators have the constraint of RFC 4291 that "For all unicast
> addresses, except those that start with the binary value 000,
> Interface IDs are required to be 64 bits long and to be constructed
> in Modified EUI-64 format".  
>
> The draft says that:
> (a) The PSID is:
> +--+---+---+---+---+---+---+---+---+
> |PL|   8  16  24  32  40  48  56   |
> +--+---+---+---+---+---+---+---+---+
> |64| u | IPv4 address  |  PSID | 0 |
> +--+---+---+---+---+---+---+---+---+
> (b) "If the End-user IPv6 prefix length is larger than 64, the most
> significant parts of the interface identifier is overwritten by the prefix."
>
> This is particularly unclear:
> - What happens to the u octet?
> - And to the IPv4 address if the prefix is longer than /68? =

Remi, you mean the prefix is longer than /68 or = /78?

Oops, I meant longer than 64 = + 8, i.e. 72.
Thank you.

   I think /68(64+4) prefix doesn't overwrite IPv4 = address.

BRs
Linda Wang


> - ...
>
> Of course, if a use case is provided where MAP-E would be actually
> used with an IID shorter than 64 bits, it should be discussed. = But:
> - There is no such use case so far.
> - Looking for one doesn't seem useful.
>
>
> Regards,
> RD
>
>  
> >
> > On 1/28/13 8:59 AM, "Ole Troan" <otroan@employees.org> wrote:
> >
> >>>>>
> >>>>> The examples in my previous note sort of = provided backing for my view
> >>>>> that the MAP endpoint IPv6 prefix can be = limited to a maximum of a
> >>>>> /64, thus making the IID fully conformant both to RFC 4291 and to RFC
> >>>>> 6052.
> >>>>>
> >>> ...
> >>>
> >>>>>
> >>>>> I think limiting the prefix length to 64 bits is reasonable. Comments?
> >>>>
> >>>> I don't think that's reasonable.
> >>>> and I don't see what it buys us, given that = supporting prefix lengths
> >>>> longer than 64 is simple.
> >>>> IPv6 isn't classfull, there isn't anything magic with the 64 boundary.
> >>>> ;-)
> >>>>
> >>>> cheers,
> >>>> Ole
> >>>>
> >>>
> >>> OK, then I agree with R=C3=A9mi. Drop mention of = prefixes greater than 64
> >>> bits long and leave it to the reader to judge whether RFC 4291 imposes a
> >>> limit.
> >>
> >> you want this removed:
> >>     <t>If the End-user IPv6 prefix length is larger than 64, the most
> >>     significant parts of the interface = identifier is overwritten by the
> >>     prefix.</t>
> >>
> >> I disagree. this is the only text in there suggesting to an implementor
> >> that prefix lengths can be any value between 0-128.
> >>
> >> Tom, Remi and I have stated our opinions. does anyone else have a view on
> >> the matter?
> >>
> >> cheers,
> >> Ole
> >> _______________________________________________
> >> Softwires mailing list
> >> Softwires@ietf.org
> >> https://www.ietf.= org/mailman/listinfo/softwires
> >
> > _______________________________________________
> > Softwires mailing list
> > Softwires@ietf.org
= > > https://www.ietf.= org/mailman/listinfo/softwires
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.= org/mailman/listinfo/softwires

= --Apple-Mail=_AF3594C5-F163-48CE-A129-504899A74A85-- From otroan@employees.org Tue Jan 29 09:28:43 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C525821F8A89 for ; Tue, 29 Jan 2013 09:28:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.42 X-Spam-Level: X-Spam-Status: No, score=-10.42 tagged_above=-999 required=5 tests=[AWL=-0.121, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aEZGB6hYeTl6 for ; Tue, 29 Jan 2013 09:28:42 -0800 (PST) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 631EE21F8A61 for ; Tue, 29 Jan 2013 09:28:42 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EANIFCFGQ/khL/2dsb2JhbABEvl4Wc4IeAQEEAXkFCwtGVwaIHgYMsQuQKpAoYQOXKY8vgng X-IronPort-AV: E=Sophos;i="4.84,561,1355097600"; d="scan'208";a="11431200" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-3.cisco.com with ESMTP; 29 Jan 2013 17:28:41 +0000 Received: from dhcp-10-61-106-28.cisco.com (dhcp-10-61-106-28.cisco.com [10.61.106.28]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r0THSeKY003521 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 29 Jan 2013 17:28:41 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ole Troan In-Reply-To: <8B11B4F3-8406-4B92-86AE-C4ADBC708417@laposte.net> Date: Tue, 29 Jan 2013 18:14:56 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <84FA528F-009D-4CAE-84F7-537A2ED402B9@employees.org> References: <063.9dc31682f59256171b5d58fdb1cdcc5e@tools.ietf.org> <078.5016b38f0fa45b1e08acdf73cc564147@tools.ietf.org> <8B5A2979-6E57-4E1F-B3A8-5450F9B39CD8@employees.org> <8B11B4F3-8406-4B92-86AE-C4ADBC708417@laposte.net> To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1499) Cc: "softwires@ietf.org WG" Subject: Re: [Softwires] 1:1 MAP-E with shared addresses X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 17:28:43 -0000 Remi, >>> (c) Once the rule is looked at, getting the PSID is easy (no more = magic needed than to get find the PSID length ;-)). >>=20 >> unless you are in 1:1 mode. >=20 > There is a point here which AFAIK has never been discussed before. =20 > (A reference is welcome if there is one I missed). this has been covered in the 1:1 discussions. > This point concerns 1:1 mappings (if needed in MAP-E), when combined = with shared IPv4 addresses:=20 > - To be assigned a shared address, a CE needs a PSID in addition to = its IPv4 address. > - Currently, this PSID cannot be found in the 1:1 rule itself (ref. = http://tools.ietf.org/html/draft-ietf-softwire-map-dhcp-01.) there is no separate 1:1 rule. PSID is defined in OPTION_MAP_PORTPARAMS. > The approach that is in my understanding implied by Ole is that each = concerned CE will be delegated a MAP-E IPv6 prefix, in addition to that = used for native IPv6 addressing, with the PSID in it. (The detailed = format isn't specified yet AFAIK, but specifying one is possible.)=20 no, then you have misunderstood. > Another approach, AFAIK much simpler in operations, is to add a rule = parameter to assign a PSID, present in 1:1 rules.=20 > This eliminates the need to delegate to each CE an additional IPv6 = prefix.=20 >=20 > Example: > . CE delegated prefix: 2001:db8:0:100::/56 > . BMR for this CE > Rule IPv6 prefix : 2001:db8:0:100:/56 > EA-bits length : 0 > Rule IPv4 prefix : 1.1.1.1/32 > PSID : 0x11 =20 >=20 > Conclusion: if 1:1 mappings are part of MAP-E, add a PSID parameter in = 1:1 mapping rules. yes, that's how I at least have intended it to be. > (Otherwise: (1) specify detailed formats of MAP-E specific delegated = prefixes > /64; (2) explain why delegated prefixes used for IPV6 aren't = found sufficient.) MAP should not put any restrictions for what prefix length a provider = wishes to delegate to an end user. it should also allow the use of a separate address (or prefix) for MAP. = I don't see why we want to artificially restrict the prefix lengths. cheers, Ole From rajiva@cisco.com Tue Jan 29 09:56:36 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4E0421F8955 for ; Tue, 29 Jan 2013 09:56:36 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3EuURyL04yXG for ; Tue, 29 Jan 2013 09:56:36 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id EBBA621F8A89 for ; Tue, 29 Jan 2013 09:56:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3754; q=dns/txt; s=iport; t=1359482196; x=1360691796; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=K8LoDe0uQbyzuL+NTGNEDmzXvB+x/JrAOkd9q4l0Muw=; b=MMJwSjZULwtJWllcOgA8pk5w9QTRy8umpxlYlH4/K95kJpjcUgfpDrrp 5ewDMc896/OxzaqPmdyQR9R4F9+ua14xO8MlxHWj3kriLHe2VbxJhVgpv jdvsdg1HoBjhfFV9vqyPvkISvihX6ADIi4kMkK4+5t8yF8vhM+vcHXlZb c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAPULCFGtJV2a/2dsb2JhbABEvl4Wc4IeAQEBAwEBAQE3MgIIAwUHBgEIEQMBAgEKFDEGCx0IAgQBDQUIE4dkAwkGDLEJhkoNiVWMFIEMgwhhA5Q3gnKKHYUSgneBZz0 X-IronPort-AV: E=Sophos;i="4.84,561,1355097600"; d="scan'208";a="169971277" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 29 Jan 2013 17:56:26 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r0THuPPJ021528 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Jan 2013 17:56:25 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.193]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Tue, 29 Jan 2013 11:56:25 -0600 From: "Rajiv Asati (rajiva)" To: Qiong , Tom Taylor Thread-Topic: [Softwires] draft-cui-softwire-b4-translated-ds-lite and MAP Thread-Index: AQHN/dmfjY8TMHmAxUWt5AsQgA4MM5hg0b0A///XN4A= Date: Tue, 29 Jan 2013 17:56:25 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.82.249.228] Content-Type: text/plain; charset="us-ascii" Content-ID: <336C386EDCC09448852F9060AB23E31D@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Softwires Subject: Re: [Softwires] draft-cui-softwire-b4-translated-ds-lite and MAP X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 17:56:36 -0000 > is whether to import these algorithm parameters EXPLICITLY into IPv6 >address or not. > Lw4o6 does not import anything into IPv6 address. Nor does MAP in a typical deployment. IOW, MAP doesn't require IPv6 prefix assignment (or addressing policy) to be different from what it would be without MAP. It is about parsing part of IPv6 prefix such that it means something (for MAP). Cheers, Rajiv -----Original Message----- From: Qiong Date: Tuesday, January 29, 2013 10:22 AM To: Tom Taylor Cc: Softwires-wg list Subject: Re: [Softwires] draft-cui-softwire-b4-translated-ds-lite and MAP >Dear Tom, > >On Tue, Jan 29, 2013 at 12:32 PM, Tom Taylor > wrote: > >I figured it was time to pick on someone else, so I reviewed >draft-cui-softwire-b4-translated-ds-lite. I found it really easy to >understand, and all I found to change was a couple of typos. > >Of course, one reason lw4o6 easier to read than MAP is because it does >not describe a port mapping algorithm. The other reason is because the >MAP document has to describe the EA bits and their use. But that's a >fundamental difference between the two approaches, > and I can't see much chance to simplify MAP. The only possibility is to >change the provisioning approach to provision the Rule IPv6 prefix, the >complete shared IPv4 address, and the PSID explicitly, then describe how >to construct the MAP endpoint IPv6 address. > > >[Qiong] Right. You have just pointed out some essential differences >between MAP and lw4o6. > > >Actually, the major difference is not to use an algorithm or not . Even >for DS-Lite and NAT444, most vendors have already implemented some kind >of algorithm in AFTR to map between IPv6 address pool, IPv4 address pool >and port-set. The key here > is whether to import these algorithm parameters EXPLICITLY into IPv6 >address or not. Lw4o6 does not import anything into IPv6 address. The >AFTR can/or can not implement an algorithm for mapping between IPv6 >address pool, IPv4 address pool and port-set, which > is only an implementation choice. But it can truely gain more >flexibility for operators to use/define freely of their own IPv6 address, >and you can also achieve very good features like scalibility, no-NAT in >AFTR, reduced syslog messages, etc. > > >Besides, I have to say again that this solution is quite simple. Before >the demo in IETF85, most vendors only took 3~4 weeks to understand, >design, and finish implementing the whole functionalities. For operators, >we also find it very simple to > run it, just configuring your available IPv6 address pools, IPv4 address >pools and port-set quota is enough. > > >That's why we like it, and hope it will be helpful for more people. > > >Best wishes >Qiong > =20 > > >Getting back to draft-cui-softwire-b4-translated-ds-lite, I'd say it's >ready to be adopted. > >Tom Taylor >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires > > > > > > > >--=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 Institude > > >Open source code: >lightweight 4over6: http://sourceforge.net/projects/laft6/ >PCP-natcoord:=20 >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 > > > > From despres.remi@laposte.net Tue Jan 29 10:24:37 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09C6821F8955 for ; Tue, 29 Jan 2013 10:24:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZGjlcTAWiaF6 for ; Tue, 29 Jan 2013 10:24:36 -0800 (PST) Received: from smtp25.services.sfr.fr (smtp25.services.sfr.fr [93.17.128.118]) by ietfa.amsl.com (Postfix) with ESMTP id 3DED721F890D for ; Tue, 29 Jan 2013 10:24:36 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2503.sfr.fr (SMTP Server) with ESMTP id 240B57000108; Tue, 29 Jan 2013 19:24:35 +0100 (CET) Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2503.sfr.fr (SMTP Server) with ESMTP id 055DF70000FD; Tue, 29 Jan 2013 19:24:34 +0100 (CET) X-SFR-UUID: 20130129182435220.055DF70000FD@msfrf2503.sfr.fr Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= In-Reply-To: <84FA528F-009D-4CAE-84F7-537A2ED402B9@employees.org> Date: Tue, 29 Jan 2013 19:24:36 +0100 Message-Id: <74CC5E6E-6B78-4153-B9A3-8873026C6D0B@laposte.net> References: <063.9dc31682f59256171b5d58fdb1cdcc5e@tools.ietf.org> <078.5016b38f0fa45b1e08acdf73cc564147@tools.ietf.org> <8B5A2979-6E57-4E1F-B3A8-5450F9B39CD8@employees.org> <8B11B4F3-8406-4B92-86AE-C4ADBC708417@laposte.net> <84FA528F-009D-4CAE-84F7-537A2ED402B9@employees.org> To: Ole Troan X-Mailer: Apple Mail (2.1499) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "softwires@ietf.org WG" Subject: Re: [Softwires] 1:1 MAP-E with shared addresses X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 18:24:37 -0000 Ole, Thanks for the clarification. More comments inline. 2013-01-29 =E0 18:14, Ole Troan : > Remi, >=20 >>>> (c) Once the rule is looked at, getting the PSID is easy (no more = magic needed than to get find the PSID length ;-)). >>>=20 >>> unless you are in 1:1 mode. >>=20 >> There is a point here which AFAIK has never been discussed before. =20= >> (A reference is welcome if there is one I missed). >=20 > this has been covered in the 1:1 discussions. Let's proceed without a reference. (This isn't one.) >=20 >> This point concerns 1:1 mappings (if needed in MAP-E), when combined = with shared IPv4 addresses:=20 >> - To be assigned a shared address, a CE needs a PSID in addition to = its IPv4 address. >> - Currently, this PSID cannot be found in the 1:1 rule itself (ref. = http://tools.ietf.org/html/draft-ietf-softwire-map-dhcp-01.) >=20 > there is no separate 1:1 rule. PSID is defined in = OPTION_MAP_PORTPARAMS. Acknowledged. (I had missed this parameter.) >=20 >> The approach that is in my understanding implied by Ole is that each = concerned CE will be delegated a MAP-E IPv6 prefix, in addition to that = used for native IPv6 addressing, with the PSID in it. (The detailed = format isn't specified yet AFAIK, but specifying one is possible.)=20 >=20 > no, then you have misunderstood. Acknowledged. >=20 >> Another approach, AFAIK much simpler in operations, is to add a rule = parameter to assign a PSID, present in 1:1 rules.=20 >> This eliminates the need to delegate to each CE an additional IPv6 = prefix.=20 >>=20 >> Example: >> . CE delegated prefix: 2001:db8:0:100::/56 >> . BMR for this CE >> Rule IPv6 prefix : 2001:db8:0:100:/56 >> EA-bits length : 0 >> Rule IPv4 prefix : 1.1.1.1/32 >> PSID : 0x11 =20 >>=20 >> Conclusion: if 1:1 mappings are part of MAP-E, add a PSID parameter = in 1:1 mapping rules. >=20 > yes, that's how I at least have intended it to be. Acknowledged. >=20 >> (Otherwise: (1) specify detailed formats of MAP-E specific delegated = prefixes > /64; (2) explain why delegated prefixes used for IPV6 aren't = found sufficient.) >=20 > MAP should not put any restrictions for what prefix length a provider = wishes to delegate to an end user. > it should also allow the use of a separate address (or prefix) for = MAP. I don't see why we want to artificially > restrict the prefix lengths. Conclusion: it is now clarified that, even if 1:1 with shared addresses = has to be covered, there is no need for any MAP-E prefix longer than 64 = bits. Consequence: the sentence about overwriting "the most significant parts = of the interface identifier" in case of such extra-long prefixes, isn't = needed.=20 It should be deleted.=20 Regards, RD >=20 > cheers, > Ole >=20 From otroan@employees.org Tue Jan 29 10:54:31 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8898621F8626 for ; Tue, 29 Jan 2013 10:54:31 -0800 (PST) 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=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YF0771-RSTTe for ; Tue, 29 Jan 2013 10:54:31 -0800 (PST) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id 34A3E21F84D5 for ; Tue, 29 Jan 2013 10:54:31 -0800 (PST) Received: from dhcp-10-61-104-108.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id BC1985F88; Tue, 29 Jan 2013 10:54:29 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ole Troan In-Reply-To: <74CC5E6E-6B78-4153-B9A3-8873026C6D0B@laposte.net> Date: Tue, 29 Jan 2013 19:54:27 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <02771B6A-4540-47E0-9A8B-C263DBF407B7@employees.org> References: <063.9dc31682f59256171b5d58fdb1cdcc5e@tools.ietf.org> <078.5016b38f0fa45b1e08acdf73cc564147@tools.ietf.org> <8B5A2979-6E57-4E1F-B3A8-5450F9B39CD8@employees.org> <8B11B4F3-8406-4B92-86AE-C4ADBC708417@laposte.net> <84FA528F-009D-4CAE-84F7-537A2ED402B9@employees.org> <74CC5E6E-6B78-4153-B9A3-8873026C6D0B@laposte.net> To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1499) Cc: "softwires@ietf.org WG" Subject: Re: [Softwires] 1:1 MAP-E with shared addresses X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 18:54:31 -0000 Remi, > Conclusion: it is now clarified that, even if 1:1 with shared = addresses has to be covered, there is no need for any MAP-E prefix = longer than 64 bits. >=20 > Consequence: the sentence about overwriting "the most significant = parts of the interface identifier" in case of such extra-long prefixes, = isn't needed.=20 > It should be deleted.=20 that doesn't follow, and the above discussion is a different point. can we please hold back a little and let other people in the working = group voice their opinion? cheers, Ole= From tom.taylor.stds@gmail.com Tue Jan 29 16:49:42 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 498A721F8868 for ; Tue, 29 Jan 2013 16:49:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.372 X-Spam-Level: X-Spam-Status: No, score=-0.372 tagged_above=-999 required=5 tests=[AWL=-0.420, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PcW-3REKV1lE for ; Tue, 29 Jan 2013 16:49:41 -0800 (PST) Received: from mail-ia0-x232.google.com (mail-ia0-x232.google.com [IPv6:2607:f8b0:4001:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 6674E21F86EF for ; Tue, 29 Jan 2013 16:49:41 -0800 (PST) Received: by mail-ia0-f178.google.com with SMTP id y26so1552115iab.9 for ; Tue, 29 Jan 2013 16:49:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-antivirus:x-antivirus-status; bh=v+lnJ2TUzw/cGNfGf45ID7ZlZK4evhPmioMGBwarIvk=; b=XxnG0sjLo46AsWT0TB+3IW75Ap+LAQbgzqz0jwakFQ3tehBM8zXju92zla8nO5Iw6g 8lBPws1ZR2crvAlEJeUz++Ebm/dwWuXJk0aluoBDkuluazEFJI4SjLU2N6rRCoKAT7dU wcybcmA7PvK+SUXmJCZ6UVeWTii/u4/U4BSt9lTwmBhQrgHbsd5kYgiHKfgug2TRRk0A IfOGwt8/HpqjLerG9CwrUU0Gey0OCb9s+Ji0XADDR43I6vIM93KEAcAUB37z6shEm0Ic WRBy+CFeSw+tZPjdp7TEbM9D2obVrRDUnpHgt0B2tbS8WB3m7LGc+m8MLW4TpbVzqljC TmfA== X-Received: by 10.42.26.142 with SMTP id f14mr702014icc.38.1359506970678; Tue, 29 Jan 2013 16:49:30 -0800 (PST) Received: from [127.0.0.1] (dsl-173-206-87-33.tor.primus.ca. [173.206.87.33]) by mx.google.com with ESMTPS id fa6sm4014180igb.2.2013.01.29.16.49.29 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Jan 2013 16:49:29 -0800 (PST) Message-ID: <51086E17.10603@gmail.com> Date: Tue, 29 Jan 2013 19:49:27 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Qi Sun References: <5106AE69.80705@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 130129-3, 29/01/2013), Outbound message X-Antivirus-Status: Clean Cc: Softwires Subject: Re: [Softwires] Section 5.1 of the MAP draft X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 00:49:42 -0000 Taking your comment literally, I'd say that the number of blocks is more relevant than the block size, so maybe the formula shouldn't be there. Just in case you didn't understand what a block is, I illustrate the ideas below. The basic idea is that, instead of assigning a single sequence of ports to a CE, the port space from whatever to 65535 is divided up into equal-size chunks, or blocks, and the CE is assigned a sequence of m ports from each block. I assume that this is done to make a port-guessing attacker's job more difficult, but I'm not sure it does so if the attacker knows the algorithm. My own view is that the MAP document could get rid of a bunch of complexity if, like lw4o6, it left the *port* mapping algorithm to a separate draft. The PSID could stay, since it is needed, but the only thing important to MAP is the *address* mapping algorithm. Anyway, here is your illustration. Assume for example that a = 4, implying a block size of 4096 (0x1000) port numbers. Thus port number space is divided up into 16 blocks as shown in the figure below. Hex notation is used for neatness. What is also shown below is the set of ports allocated to a particular CE, represented by P..P. This is a sequence occuring at the same relative position in every block. The PSID is an index that points to that relative position. The first port number, in fact, is PSID * m from the beginning of the block, where m is the total number of ports in the sequence P..P. Port ---- 0x0000 Block not used -- contains system ports. 0x0FFF ---- 0x1000 P..P 0X1FFF ---- 0x2000 . . . . 0xEFFF ---- 0xF000 P..P 0xFFFF ---- On 29/01/2013 12:54 AM, Qi Sun wrote: > > Dear Tom, > > IMHO, these are valuable comments. However, I'm kind of lost on this > part: > >> A Indexes the blocks of port numbers. The lowest block number >> (A = 0) and possibly others contain the system port numbers, and >> hence should not be used if port numbers 0-1023 are to be avoided. >> >> a Width of the field containing the block index A. Indirectly a >> determines the block size, by the formula: Block size = 65536 / >> 2^a > > > I'm not sure of the meaning of 'Block size', which is equal to > 2^(k+m). As I interpret, each CE can get 2^(a+m) ports and each port > range is 2^m. What can we use the 'Block size' for? > > Thanks in advance! > > Best Regards, Qi Sun > > > On 2013-1-29, at 上午12:59, Tom Taylor wrote: > ... From despres.remi@laposte.net Wed Jan 30 00:47:18 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA16C21F84C2 for ; Wed, 30 Jan 2013 00:47:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.885 X-Spam-Level: X-Spam-Status: No, score=-1.885 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9w1gq9QNPgg for ; Wed, 30 Jan 2013 00:47:18 -0800 (PST) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.13]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF7621F84BA for ; Wed, 30 Jan 2013 00:47:17 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2216.sfr.fr (SMTP Server) with ESMTP id 3FF327000202; Wed, 30 Jan 2013 09:47:16 +0100 (CET) Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2216.sfr.fr (SMTP Server) with ESMTP id F0101700007D; Wed, 30 Jan 2013 09:47:15 +0100 (CET) X-SFR-UUID: 20130130084715983.F0101700007D@msfrf2216.sfr.fr Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= In-Reply-To: <02771B6A-4540-47E0-9A8B-C263DBF407B7@employees.org> Date: Wed, 30 Jan 2013 09:47:15 +0100 Message-Id: <292F101C-8937-493D-86CB-88EB8A96C59B@laposte.net> References: <063.9dc31682f59256171b5d58fdb1cdcc5e@tools.ietf.org> <078.5016b38f0fa45b1e08acdf73cc564147@tools.ietf.org> <8B5A2979-6E57-4E1F-B3A8-5450F9B39CD8@employees.org> <8B11B4F3-8406-4B92-86AE-C4ADBC708417@laposte.net> <84FA528F-009D-4CAE-84F7-537A2ED402B9@employees.org> <74CC5E6E-6B78-4153-B9A3-8873026C6D0B@laposte.net> <02771B6A-4540-47E0-9A8B-C263DBF407B7@employees.org> To: Ole Troan X-Mailer: Apple Mail (2.1499) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "softwires@ietf.org WG" Subject: [Softwires] MAP-E CE address format X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 08:47:18 -0000 2013-01-29 19:54, Ole Troan : > Remi, > ... > can we please hold back a little and let other people in the working = group voice their opinion? To make progress, I feel it should be acceptable to continue to: - ask for clarifications on some points that IMHO remain obscure (e.g. = the purpose of overwriting "the most significant parts of the interface = identifier" for CE IPv6 prefixes of lengths > 64, especially since it = conflicts with RFC 6052). - react to statements or assumptions that are AFAIK inaccurate (e.g. = that, with MAP-E IID formats as specified, maintenance could determine = PSID values from IIDs alone.) Cheers, RD From otroan@employees.org Wed Jan 30 01:04:41 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59B1A21F8585 for ; Wed, 30 Jan 2013 01:04:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.415 X-Spam-Level: X-Spam-Status: No, score=-10.415 tagged_above=-999 required=5 tests=[AWL=-0.116, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3TcTEGfLb0yn for ; Wed, 30 Jan 2013 01:04:40 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 9A9EF21F84EA for ; Wed, 30 Jan 2013 01:04:40 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAAzhCFGQ/khN/2dsb2JhbABEvxAWc4IeAQEEAXkQC0ZXBogeBsFWkClhA6ZYgng X-IronPort-AV: E=Sophos;i="4.84,566,1355097600"; d="scan'208";a="80111524" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 30 Jan 2013 09:04:39 +0000 Received: from dhcp-lys02-vla252-10-147-116-47.cisco.com (dhcp-lys02-vla252-10-147-116-47.cisco.com [10.147.116.47]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r0U94c3U000483 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 30 Jan 2013 09:04:39 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ole Troan In-Reply-To: <292F101C-8937-493D-86CB-88EB8A96C59B@laposte.net> Date: Wed, 30 Jan 2013 10:04:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <063.9dc31682f59256171b5d58fdb1cdcc5e@tools.ietf.org> <078.5016b38f0fa45b1e08acdf73cc564147@tools.ietf.org> <8B5A2979-6E57-4E1F-B3A8-5450F9B39CD8@employees.org> <8B11B4F3-8406-4B92-86AE-C4ADBC708417@laposte.net> <84FA528F-009D-4CAE-84F7-537A2ED402B9@employees.org> <74CC5E6E-6B78-4153-B9A3-8873026C6D0B@laposte.net> <02771B6A-4540-47E0-9A8B-C263DBF407B7@employees.org> <292F101C-8937-493D-86CB-88EB8A96C59B@laposte.net> To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1499) Cc: "softwires@ietf.org WG" Subject: Re: [Softwires] MAP-E CE address format X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 09:04:41 -0000 Remi, >> can we please hold back a little and let other people in the working = group voice their opinion? >=20 >=20 > To make progress, I feel it should be acceptable to continue to: > - ask for clarifications on some points that IMHO remain obscure (e.g. = the purpose of overwriting "the most significant parts of the interface = identifier" for CE IPv6 prefixes of lengths > 64, especially since it = conflicts with RFC 6052). I don't quite agree that it conflicts, but looking back at comments from = several people it might be best to remove the 6052 reference. > - react to statements or assumptions that are AFAIK inaccurate (e.g. = that, with MAP-E IID formats as specified, maintenance could determine = PSID values from IIDs alone.) agree, but you can get a 'fair' idea. given that both the IPv4 address = and PSID are fixed length fields at fixed offsets. I'm defending status quo largely because that gives me the least amount = of work. ;) please convince the working group of your scheme, and provide the text, = and I'll put that in the document. so far I have seen more support for the existing scheme than the "::1" = though. cheers, Ole= From despres.remi@laposte.net Wed Jan 30 01:56:33 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE9521F8712 for ; Wed, 30 Jan 2013 01:56:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mHvblZeQIM3N for ; Wed, 30 Jan 2013 01:56:32 -0800 (PST) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.13]) by ietfa.amsl.com (Postfix) with ESMTP id 67F6121F86F5 for ; Wed, 30 Jan 2013 01:56:31 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2216.sfr.fr (SMTP Server) with ESMTP id D0A6570001F3; Wed, 30 Jan 2013 10:56:30 +0100 (CET) Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2216.sfr.fr (SMTP Server) with ESMTP id A3C8B70001E9; Wed, 30 Jan 2013 10:56:30 +0100 (CET) X-SFR-UUID: 20130130095630670.A3C8B70001E9@msfrf2216.sfr.fr Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 30 Jan 2013 10:56:30 +0100 Message-Id: References: <063.9dc31682f59256171b5d58fdb1cdcc5e@tools.ietf.org> <078.5016b38f0fa45b1e08acdf73cc564147@tools.ietf.org> <8B5A2979-6E57-4E1F-B3A8-5450F9B39CD8@employees.org> <8B11B4F3-8406-4B92-86AE-C4ADBC708417@laposte.net> <84FA528F-009D-4CAE-84F7-537A2ED402B9@employees.org> <74CC5E6E-6B78-4153-B9A3-8873026C6D0B@laposte.net> <02771B6A-4540-47E0-9A8B-C263DBF407B7@employees.org> <292F101C-8937-493D-86CB-88EB8A96C59B@laposte.net> To: Ole Troan X-Mailer: Apple Mail (2.1499) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "softwires@ietf.org WG" Subject: Re: [Softwires] MAP-E CE address format X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 09:56:33 -0000 Le 2013-01-30 =E0 10:04, Ole Troan a =E9crit : > Remi, >=20 >>> can we please hold back a little and let other people in the working = group voice their opinion? >>=20 >>=20 >> To make progress, I feel it should be acceptable to continue to: >> - ask for clarifications on some points that IMHO remain obscure = (e.g. the purpose of overwriting "the most significant parts of the = interface identifier" for CE IPv6 prefixes of lengths > 64, especially = since it conflicts with RFC 6052). >=20 > I don't quite agree that it conflicts, but looking back at comments = from several people it might be best to remove the 6052 reference. Removing the reference does eliminate the conflict. What remains unknown is the purpose of IPv4-address and PSID fields if = they may be partially overwritten, e.g. with IPv6 prefixes of 96 or 120 = bits. >> - react to statements or assumptions that are AFAIK inaccurate (e.g. = that, with MAP-E IID formats as specified, maintenance could determine = PSID values from IIDs alone.) >=20 > agree, Good. > but you can get a 'fair' idea. given that both the IPv4 address and = PSID are fixed length fields at fixed offsets. 'Fair' idea is unclear but yes, if the PSID length is known to be fixed, = one can find the PSID (only in that case).=20 > I'm defending status quo largely because that gives me the least = amount of work. ;) >=20 > please convince the working group of your scheme, and provide the = text, and I'll put that in the document. > so far I have seen more support for the existing scheme than the "::1" = though. Provided the IID "overwriting" is clarified (see above), I agree that = whatever the majority prefers will become the standard, even if = unnecessarily redundant.=20 My contribution is simply to suggest an application of the KISS = principle. Regards, RD >=20 > cheers, > Ole From ot@cisco.com Wed Jan 30 02:41:12 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 329B921F8840 for ; Wed, 30 Jan 2013 02:41:12 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b8DvO+BD0uU1 for ; Wed, 30 Jan 2013 02:41:11 -0800 (PST) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 3755A21F871D for ; Wed, 30 Jan 2013 02:41:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3468; q=dns/txt; s=iport; t=1359542471; x=1360752071; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=EF9J9T43yzarzq9cdGPQ+LGlApeHosUxfHTpQcq2I7E=; b=OxvgXSzzhFz3Rr76h75m9iUslehBJLU+yjffb7CzTMRqm81eiRoZ1+rb NhN/EexfDvCLLnWbqF8JOo6yCNONpywytN2wh4Aj6IzhyxlPpdHmoKSPI wVmvYd0sGROuru5i2G8FfapqvyunzJtWnYCmYStYhUWkbisbEOXenPgmg 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAJr3CFGQ/khL/2dsb2JhbABFhke4SRZzgh4BAQEDAQEBASBLCwULCQIYAgImAgInMAYTiAsGDJNrmn+SWQSBI45UMmEDlg2QS4J4 X-IronPort-AV: E=Sophos;i="4.84,567,1355097600"; d="scan'208";a="11450989" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-3.cisco.com with ESMTP; 30 Jan 2013 10:41:10 +0000 Received: from dhcp-lys02-vla252-10-147-116-47.cisco.com (dhcp-lys02-vla252-10-147-116-47.cisco.com [10.147.116.47]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r0UAf9bX000918 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 30 Jan 2013 10:41:09 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ole Troan In-Reply-To: <51086E17.10603@gmail.com> Date: Wed, 30 Jan 2013 11:41:09 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5106AE69.80705@gmail.com> <51086E17.10603@gmail.com> To: Tom Taylor X-Mailer: Apple Mail (2.1499) Cc: Softwires Subject: Re: [Softwires] Section 5.1 of the MAP draft X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 10:41:12 -0000 Tom, > Taking your comment literally, I'd say that the number of blocks is = more relevant than the block size, so maybe the formula shouldn't be = there. Just in case you didn't understand what a block is, I illustrate = the ideas below. >=20 > The basic idea is that, instead of assigning a single sequence of = ports to a CE, the port space from whatever to 65535 is divided up into = equal-size chunks, or blocks, and the CE is assigned a sequence of m = ports from each block. I assume that this is done to make a = port-guessing attacker's job more difficult, but I'm not sure it does so = if the attacker knows the algorithm. My own view is that the MAP = document could get rid of a bunch of complexity if, like lw4o6, it left = the *port* mapping algorithm to a separate draft. The PSID could stay, = since it is needed, but the only thing important to MAP is the *address* = mapping algorithm. no, the port mapping algorithm in MAP is _not_ written the way it is to = make an attackers job more difficult. the port mapping algorithm in MAP is the simplest algorithm we could = think of, that would exclude the well known ports with arbitrary values of PSID. I don't at all see why moving the port mapping algorithm out of the = document would make things simpler. it would make it a lot more complex. then you'd end up with having to = support many different port algorithms. cheers, Ole > Anyway, here is your illustration. Assume for example that a =3D 4, = implying a block size of 4096 (0x1000) port numbers. Thus port number = space is divided up into 16 blocks as shown in the figure below. Hex = notation is used for neatness. >=20 > What is also shown below is the set of ports allocated to a particular = CE, represented by P..P. This is a sequence occuring at the same = relative position in every block. The PSID is an index that points to = that relative position. The first port number, in fact, is PSID * m from = the beginning of the block, where m is the total number of ports in the = sequence P..P. >=20 > Port >=20 > ---- > 0x0000 >=20 >=20 > Block not used -- contains system ports. >=20 >=20 >=20 >=20 > 0x0FFF > ---- > 0x1000 >=20 >=20 > P..P >=20 >=20 >=20 >=20 > 0X1FFF > ---- > 0x2000 > . > . > . > . > 0xEFFF > ---- > 0xF000 >=20 >=20 > P..P >=20 >=20 >=20 >=20 >=20 > 0xFFFF > ---- >=20 > On 29/01/2013 12:54 AM, Qi Sun wrote: >>=20 >> Dear Tom, >>=20 >> IMHO, these are valuable comments. However, I'm kind of lost on this >> part: >>=20 >>> A Indexes the blocks of port numbers. The lowest block number >>> (A =3D 0) and possibly others contain the system port numbers, and >>> hence should not be used if port numbers 0-1023 are to be avoided. >>>=20 >>> a Width of the field containing the block index A. Indirectly a >>> determines the block size, by the formula: Block size =3D 65536 / >>> 2^a >>=20 >>=20 >> I'm not sure of the meaning of 'Block size', which is equal to >> 2^(k+m). As I interpret, each CE can get 2^(a+m) ports and each port >> range is 2^m. What can we use the 'Block size' for? >>=20 >> Thanks in advance! >>=20 >> Best Regards, Qi Sun >>=20 >>=20 >> On 2013-1-29, at =E4=B8=8A=E5=8D=8812:59, Tom Taylor wrote: >>=20 > ... > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From tom.taylor.stds@gmail.com Wed Jan 30 04:41:03 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2AA621F895B for ; Wed, 30 Jan 2013 04:41:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.349 X-Spam-Level: X-Spam-Status: No, score=-0.349 tagged_above=-999 required=5 tests=[AWL=-0.397, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ONnWLbYtzHGd for ; Wed, 30 Jan 2013 04:41:03 -0800 (PST) Received: from mail-ie0-x22c.google.com (ie-in-x022c.1e100.net [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 40A4121F894C for ; Wed, 30 Jan 2013 04:41:03 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c10so1194347ieb.17 for ; Wed, 30 Jan 2013 04:41:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-antivirus:x-antivirus-status; bh=wq5wAr/xvAmSG7fm1O0IoxDgN9FT8C0yDyfJoazk9ZQ=; b=pVUrHZLYY6I9RnPeleM7pyHexjx4k8dOzTcPdToIDmp0Uhsx0/aBYxV6IJmcoglPFZ w2zzyjww+pL9ahlO0aaPe0naPk/2+coWEepTRuTa1CBOK/hNmR5thQK5zDrjxZhZNPwV XZx8A5xtVXU4CfNZ9Qpv4fmlWPxDd4dUImrlkFy3IqbmGWUfdjdaZCUpU+9fmvK6V5We 7Nlnqi5YVJkVLN2339LyOFY+Qgz9hG+YrA51z/WCA5oA5rIp2J3I33veFfvlr1/IHz0p CTO0e4gEQUeRfgQdWzhzzdWn8hbkmCS3R81NDSUf9WKqVQq237SWUEKs/qlXil+wNKis AZ4w== X-Received: by 10.50.12.226 with SMTP id b2mr3256163igc.28.1359549662610; Wed, 30 Jan 2013 04:41:02 -0800 (PST) Received: from [127.0.0.1] (dsl-173-206-87-33.tor.primus.ca. [173.206.87.33]) by mx.google.com with ESMTPS id vq4sm4199267igb.10.2013.01.30.04.41.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Jan 2013 04:41:01 -0800 (PST) Message-ID: <510914DC.3090507@gmail.com> Date: Wed, 30 Jan 2013 07:41:00 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Ole Troan References: <5106AE69.80705@gmail.com> <51086E17.10603@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130130-0, 30/01/2013), Outbound message X-Antivirus-Status: Clean Cc: Softwires Subject: Re: [Softwires] Section 5.1 of the MAP draft X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 12:41:03 -0000 Below. On 30/01/2013 5:41 AM, Ole Troan wrote: > Tom, > ... >> >> The basic idea is that, instead of assigning a single sequence of >> ports to a CE, the port space from whatever to 65535 is divided up >> into equal-size chunks, or blocks, and the CE is assigned a >> sequence of m ports from each block. I assume that this is done to >> make a port-guessing attacker's job more difficult, but I'm not >> sure it does so if the attacker knows the algorithm. My own view is >> that the MAP document could get rid of a bunch of complexity if, >> like lw4o6, it left the *port* mapping algorithm to a separate >> draft. The PSID could stay, since it is needed, but the only thing >> important to MAP is the *address* mapping algorithm. > > no, the port mapping algorithm in MAP is _not_ written the way it is > to make an attackers job more difficult. the port mapping algorithm > in MAP is the simplest algorithm we could think of, that would > exclude the well known ports with arbitrary values of PSID. > > I don't at all see why moving the port mapping algorithm out of the > document would make things simpler. it would make it a lot more > complex. then you'd end up with having to support many different port > algorithms. > > cheers, Ole > My first reaction to that is to say: unless we fix a at 4, you're going to be stuck with implementing the a = 0 case anyway, so you might as well use that and exclude the lowest values of PSID if you want to keep things simple. The WG really needs to have an opinion on which direction to go here. Thinking in terms of the broader picture, I still wonder if the port mapping algorithm should be documented separately with MAP having a normative dependency on it, just so the algorithm is reusable amongst all A+P variants. Tom From ot@cisco.com Wed Jan 30 04:47:26 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6231A21F8574 for ; Wed, 30 Jan 2013 04:47:26 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pX8vTCuggZCX for ; Wed, 30 Jan 2013 04:47:25 -0800 (PST) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 625E221F85A1 for ; Wed, 30 Jan 2013 04:47:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1343; q=dns/txt; s=iport; t=1359550045; x=1360759645; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=AjKe4DNfSjZff5HwZC4NW8iO+Zh067NufP4a3Mjejvs=; b=fLF8MHhaGRbc+g1BLPBfLoaKcVhBNpKEGmfU2SBbwKF9wNHH0IshfmSX UNVgSjWwVd+Zg3osuCjzz8up7fqDVb6NqQqL8PgjwwP8Xa1POTO6Sdale LpTVzDGKrBiV/QT9zHtLMJyVlw3ylfUsN8H3l1XNGbSwMjOBLpCV8RwGK k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAIIUCVGQ/khL/2dsb2JhbABFvxIWc4IeAQEBAwE6OgUFCwtGVwaIHgbBO5ApYQOWDZBLgng X-IronPort-AV: E=Sophos;i="4.84,568,1355097600"; d="scan'208";a="11466445" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-4.cisco.com with ESMTP; 30 Jan 2013 12:47:22 +0000 Received: from dhcp-lys02-vla252-10-147-116-47.cisco.com (dhcp-lys02-vla252-10-147-116-47.cisco.com [10.147.116.47]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r0UClMx0030329 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 30 Jan 2013 12:47:22 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ole Troan In-Reply-To: <510914DC.3090507@gmail.com> Date: Wed, 30 Jan 2013 13:47:21 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2BE59159-2F6D-4D6A-98F9-F0E7775322E9@cisco.com> References: <5106AE69.80705@gmail.com> <51086E17.10603@gmail.com> <510914DC.3090507@gmail.com> To: Tom Taylor X-Mailer: Apple Mail (2.1499) Cc: Softwires Subject: Re: [Softwires] Section 5.1 of the MAP draft X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 12:47:26 -0000 Tom, [...] >> I don't at all see why moving the port mapping algorithm out of the >> document would make things simpler. it would make it a lot more >> complex. then you'd end up with having to support many different port >> algorithms. >>=20 >>=20 > My first reaction to that is to say: unless we fix a at 4, you're = going to be stuck with implementing the a =3D 0 case anyway, so you = might as well use that and exclude the lowest values of PSID if you want = to keep things simple. The WG really needs to have an opinion on which = direction to go here. a premise of MAP is to not put any dependency on the IPv6 addressing = plan of the ISP. excluding e.g. PSID =3D 0, would require the ISP to not delegate that prefix to the end-user. that's a dependency we do = not want. I'm fine with fixing a to 4. if an end user needs well known ports, give her a full address. > Thinking in terms of the broader picture, I still wonder if the port = mapping algorithm should be documented separately with MAP having a = normative dependency on it, just so the algorithm is reusable amongst = all A+P variants. that is really water under the bridge at this stage. we have been there and tried that. that's how we started with MAP as the = base document, and separate MAP-E and MAP-T documents. cheers, Ole= From tom.taylor.stds@gmail.com Wed Jan 30 05:42:22 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 657B321F8450 for ; Wed, 30 Jan 2013 05:42:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.328 X-Spam-Level: X-Spam-Status: No, score=-0.328 tagged_above=-999 required=5 tests=[AWL=-0.376, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JVkxMpAhqcsy for ; Wed, 30 Jan 2013 05:42:22 -0800 (PST) Received: from mail-ia0-x22b.google.com (ia-in-x022b.1e100.net [IPv6:2607:f8b0:4001:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id D50FF21F8449 for ; Wed, 30 Jan 2013 05:42:21 -0800 (PST) Received: by mail-ia0-f171.google.com with SMTP id z13so2322641iaz.16 for ; Wed, 30 Jan 2013 05:42:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-antivirus:x-antivirus-status; bh=hs2Md33jCLapZKymq9uGkTOctfuGRK8UIMaB5tks2t4=; b=hEy2bIJYqK8a3d7mF3vq5KEAiyKSI78QeJ3khJaSsaGK9XS+IGcg5q40T7ClzeP7mz SowifmKm93wTlekWtvlezQWwVVwXAhFsaCvHrc7mA5QUrlc2i0C5YhUrpg3ivbmRS5F3 tVlFv7QabDBCLY3AywIk6XZw+ew/NG4iiDNGBqJw3tLk82Br3hYs4gJGL+ffFr6oKiPU vLReaNR385hKZuNlDXRq0QN/vJfP3kfuFbD6c24ao9gJXM70dFsEiQu47n9AZvEJVDYf yAFfQOvBoOw9hntwcGmHojYoBrjoQdTdtjLFqDnUzyGHTpsU79a9m2H8l61vibzdD9DY KTSg== X-Received: by 10.50.88.199 with SMTP id bi7mr3585488igb.9.1359553341081; Wed, 30 Jan 2013 05:42:21 -0800 (PST) Received: from [127.0.0.1] (dsl-173-206-87-33.tor.primus.ca. [173.206.87.33]) by mx.google.com with ESMTPS id fb10sm1738532igb.1.2013.01.30.05.42.19 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Jan 2013 05:42:20 -0800 (PST) Message-ID: <5109233A.9070901@gmail.com> Date: Wed, 30 Jan 2013 08:42:18 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Ole Troan References: <5106AE69.80705@gmail.com> <51086E17.10603@gmail.com> <510914DC.3090507@gmail.com> <2BE59159-2F6D-4D6A-98F9-F0E7775322E9@cisco.com> In-Reply-To: <2BE59159-2F6D-4D6A-98F9-F0E7775322E9@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130130-0, 30/01/2013), Outbound message X-Antivirus-Status: Clean Cc: Softwires Subject: Re: [Softwires] Section 5.1 of the MAP draft X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 13:42:22 -0000 Below, with [PTT]. On 30/01/2013 7:47 AM, Ole Troan wrote: > Tom, > > [...] > >>> I don't at all see why moving the port mapping algorithm out of >>> the document would make things simpler. it would make it a lot >>> more complex. then you'd end up with having to support many >>> different port algorithms. >>> >>> >> My first reaction to that is to say: unless we fix a at 4, you're >> going to be stuck with implementing the a = 0 case anyway, so you >> might as well use that and exclude the lowest values of PSID if you >> want to keep things simple. The WG really needs to have an opinion >> on which direction to go here. > > a premise of MAP is to not put any dependency on the IPv6 addressing > plan of the ISP. excluding e.g. PSID = 0, would require the ISP to > not delegate that prefix to the end-user. that's a dependency we do > not want. > [PTT] OK, that statement is in 5.1 now, but I didn't understand it. I'll look at the original text again. > I'm fine with fixing a to 4. if an end user needs well known ports, > give her a full address. > [PTT] I have no opinion on the value of a. Agreed about needing a full address to get system ports. >> Thinking in terms of the broader picture, I still wonder if the >> port mapping algorithm should be documented separately with MAP >> having a normative dependency on it, just so the algorithm is >> reusable amongst all A+P variants. > > that is really water under the bridge at this stage. we have been > there and tried that. that's how we started with MAP as the base > document, and separate MAP-E and MAP-T documents. > > cheers, Ole > From despres.remi@laposte.net Wed Jan 30 06:56:37 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D56DD21F8A68 for ; Wed, 30 Jan 2013 06:56:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZylN6UPRqFF for ; Wed, 30 Jan 2013 06:56:37 -0800 (PST) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.83]) by ietfa.amsl.com (Postfix) with ESMTP id 1D15021F8B37 for ; Wed, 30 Jan 2013 06:56:36 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2413.sfr.fr (SMTP Server) with ESMTP id 56C807000142; Wed, 30 Jan 2013 15:56:36 +0100 (CET) Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2413.sfr.fr (SMTP Server) with ESMTP id EA5F770000BB; Wed, 30 Jan 2013 15:56:35 +0100 (CET) X-SFR-UUID: 20130130145635960.EA5F770000BB@msfrf2413.sfr.fr Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= In-Reply-To: <2BE59159-2F6D-4D6A-98F9-F0E7775322E9@cisco.com> Date: Wed, 30 Jan 2013 15:56:36 +0100 Message-Id: References: <5106AE69.80705@gmail.com> <51086E17.10603@gmail.com> <510914DC.3090507@gmail.com> <2BE59159-2F6D-4D6A-98F9-F0E7775322E9@cisco.com> To: Tom Taylor , Ole Troan X-Mailer: Apple Mail (2.1499) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: Softwires WG Subject: Re: [Softwires] Section 5.1 of the MAP draft X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 14:56:38 -0000 Le 2013-01-30 13:47, Ole Troan : > Tom, >=20 > [...] >=20 >>> I don't at all see why moving the port mapping algorithm out of the >>> document would make things simpler. it would make it a lot more >>> complex. then you'd end up with having to support many different = port >>> algorithms. >>>=20 >>>=20 >> My first reaction to that is to say: unless we fix a at 4, you're = going to be stuck with implementing the a =3D 0 case anyway, so you = might as well use that and exclude the lowest values of PSID if you want = to keep things simple. The WG really needs to have an opinion on which = direction to go here. >=20 > a premise of MAP is to not put any dependency on the IPv6 addressing = plan of the ISP. excluding e.g. PSID =3D 0, would require the ISP > to not delegate that prefix to the end-user. that's a dependency we do = not want. >=20 > I'm fine with fixing a to 4. > if an end user needs well known ports, give her a full address. An alternative is possible that - permits ISPs that want it to assign well-known ports to some = privileged users without necessarily giving them full IPv4 addresses; - uses a trivially simple algorithm. That which has been chosen for 4rd can be used for MAP-E as well. It = uses for this an option to be used if well-nown ports must be = assignable. It is specified in two sentences, in = http://tools.ietf.org/html/draft-ietf-softwire-4rd-04#page-15, at the = end of the first paragraph.=20 Its complete picture representation is in a part of Figure 5: =20 (by default) (If WKPs authorized) : : : : +---+----+---------+ +----+-------------+ Ports in |> 0|PSID|any value| OR |PSID| any value | the CE port set +---+----+---------+ +----+-------------+ : 4 : 12 : : 16 : Regards, RD >> Thinking in terms of the broader picture, I still wonder if the port = mapping algorithm should be documented separately with MAP having a = normative dependency on it, just so the algorithm is reusable amongst = all A+P variants. >=20 > that is really water under the bridge at this stage. > we have been there and tried that. that's how we started with MAP as = the base document, and separate MAP-E and MAP-T documents. >=20 > cheers, > Ole > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires From tom.taylor.stds@gmail.com Wed Jan 30 07:52:09 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6799921F8732 for ; Wed, 30 Jan 2013 07:52:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.159 X-Spam-Level: X-Spam-Status: No, score=-0.159 tagged_above=-999 required=5 tests=[AWL=-0.507, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, MIME_8BIT_HEADER=0.3, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rCQxySGLkxnh for ; Wed, 30 Jan 2013 07:52:08 -0800 (PST) Received: from mail-ie0-x232.google.com (ie-in-x0232.1e100.net [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 693C621F869E for ; Wed, 30 Jan 2013 07:52:08 -0800 (PST) Received: by mail-ie0-f178.google.com with SMTP id c13so1375266ieb.23 for ; Wed, 30 Jan 2013 07:52:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-antivirus:x-antivirus-status; bh=TucgrOI1xNowPCSKxFsMOJIBw81hSwLxKyvNH1Gqu20=; b=sWbWMo1BYlbdLClp2e1JPbhmsC40ZpVgMUxphaJURu8vXLjBx3t5XcnyVmhDiUyaDX yCU8Zl0lEKBA8RymWQr8u6ZoL5PTU8pzjCCPcThX+/sdHNLvZYtQMtvzrys4daCC7efE VTuUmRCnOcqz34DGzJwNFT1iWPSbx8t7pf5yJQdb592IN0O2sa//PX9V3RkDyyQxru8J gZQGKxxjOc+VUjDYgHoXZKjHVfhlIRRa14EBDhaCiJcGy1fwDTAZlvaklNl2FamF1fLg xmA3yTVEknKd3nd7Of8mM5wClyLr3hKzx+6Ys1iDv0MrkjosAbG0XvbZoULYuf7dyFMX yuTw== X-Received: by 10.42.18.138 with SMTP id x10mr3412924ica.22.1359561127810; Wed, 30 Jan 2013 07:52:07 -0800 (PST) Received: from [127.0.0.1] (dsl-173-206-87-33.tor.primus.ca. [173.206.87.33]) by mx.google.com with ESMTPS id kf2sm2197822igc.0.2013.01.30.07.52.06 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Jan 2013 07:52:06 -0800 (PST) Message-ID: <510941A5.7090108@gmail.com> Date: Wed, 30 Jan 2013 10:52:05 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= References: <5106AE69.80705@gmail.com> <51086E17.10603@gmail.com> <510914DC.3090507@gmail.com> <2BE59159-2F6D-4D6A-98F9-F0E7775322E9@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 130130-0, 30/01/2013), Outbound message X-Antivirus-Status: Clean Cc: Softwires WG , Ole Troan Subject: Re: [Softwires] Section 5.1 of the MAP draft X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 15:52:09 -0000 On 30/01/2013 9:56 AM, Rmi Desprs wrote: > > Le 2013-01-30 13:47, Ole Troan : > >> Tom, >> >> [...] >> >> [Ole said:] >> I'm fine with fixing a to 4. >> if an end user needs well known ports, give her a full address. > [Rmi said:] > An alternative is possible that > - permits ISPs that want it to assign well-known ports to some privileged users without necessarily giving them full IPv4 addresses; > - uses a trivially simple algorithm. > > That which has been chosen for 4rd can be used for MAP-E as well. It uses for this an option to be used if well-nown ports must be assignable. > > It is specified in two sentences, in http://tools.ietf.org/html/draft-ietf-softwire-4rd-04#page-15, at the end of the first paragraph. > Its complete picture representation is in a part of Figure 5: > > (by default) (If WKPs authorized) > : : : : > +---+----+---------+ +----+-------------+ > Ports in |> 0|PSID|any value| OR |PSID| any value | > the CE port set +---+----+---------+ +----+-------------+ > : 4 : 12 : : 16 : > ... OK, this explains the bit about system ports in the text, when a = 0. The one objection I see to that is again the matter of address dependency -- the system ports are available only for the first few PSIDs, the PSIDs appear as part of the MAP endpoint prefix, so the prefix value becomes constrained. Since devices requiring system ports are likely to be servers, the full address solution makes sense on another level too. Tom Taylor From ssenthil@cisco.com Wed Jan 30 08:12:21 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC67921F8443 for ; Wed, 30 Jan 2013 08:12:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TBlNLPWRjTRt for ; Wed, 30 Jan 2013 08:12:17 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 2392121F8441 for ; Wed, 30 Jan 2013 08:12:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2590; q=dns/txt; s=iport; t=1359562337; x=1360771937; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=W1I8suMw68HyD/OmCCbTvDbZtEJAvc3767ovYyUjA8I=; b=YtSp1f0b4vHa4bfFFLcOC/+Cax78cfA1DWPZtoYVQiEZ1cmRs0yWQCLI HBdWtkxLiWZnmuWOWP4j5525PHgNCeKAG9VAuc1KeSNHH16ckC9u8LyjM E8JAv8qm6kRVED0O1H2Q9MDLYAkj3m8YYMREjqj/UhcuVtNHlfVoQ/bUH 0=; X-IronPort-AV: E=Sophos;i="4.84,569,1355097600"; d="scan'208";a="170592443" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 30 Jan 2013 16:12:16 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r0UGCGJo011790 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Jan 2013 16:12:16 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.248]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Wed, 30 Jan 2013 10:12:15 -0600 From: "Senthil Sivakumar (ssenthil)" To: Tom Taylor , =?iso-8859-1?Q?R=E9mi_Despr=E9s?= Thread-Topic: [Softwires] Section 5.1 of the MAP draft Thread-Index: AQHN/XjY81cCISLjbkCTTltIdFW7ophgM9WAgAE9HYCAAKVSgIAAIXwAgAABxoCAACQdAIAAD4GA//+xzwA= Date: Wed, 30 Jan 2013 16:12:15 +0000 Message-ID: In-Reply-To: <510941A5.7090108@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.117.198.136] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <6A6CDD1A1E1A5749A0B54D67A04CB8F9@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Softwires WG , Ole Troan Subject: Re: [Softwires] Section 5.1 of the MAP draft X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 16:12:21 -0000 On 1/30/13 10:52 AM, "Tom Taylor" wrote: >On 30/01/2013 9:56 AM, R=E9mi Despr=E9s wrote: >> >> Le 2013-01-30 13:47, Ole Troan : >> >>> Tom, >>> >>> [...] >>> >>> >[Ole said:] >>> I'm fine with fixing a to 4. >>> if an end user needs well known ports, give her a full address. >> >[R=E9mi said:] >> An alternative is possible that >> - permits ISPs that want it to assign well-known ports to some >>privileged users without necessarily giving them full IPv4 addresses; >> - uses a trivially simple algorithm. >> >> That which has been chosen for 4rd can be used for MAP-E as well. It >>uses for this an option to be used if well-nown ports must be assignable. >> >> It is specified in two sentences, in >>http://tools.ietf.org/html/draft-ietf-softwire-4rd-04#page-15, at the >>end of the first paragraph. >> Its complete picture representation is in a part of Figure 5: >> >> (by default) (If WKPs authorized) >> : : : : >> +---+----+---------+ +----+-------------+ >> Ports in |> 0|PSID|any value| OR |PSID| any value | >> the CE port set +---+----+---------+ +----+-------------+ >> : 4 : 12 : : 16 : >> >... > >OK, this explains the bit about system ports in the text, when a =3D 0. >The one objection I see to that is again the matter of address >dependency -- the system ports are available only for the first few >PSIDs, the PSIDs appear as part of the MAP endpoint prefix, so the >prefix value becomes constrained. > >Since devices requiring system ports are likely to be servers, the full >address solution makes sense on another level too. I agree, that a full address for servers running in a map domain makes the most sense. However, since all the well known ports are defined to be < 1024, it seems that it is advantageous to exclude just that range. The draft says "To simplify the port mapping algorithm the defaults are chosen so that the PSID field starts on a nibble boundary and the excluded port range (0-1023) is extended to 0-4095." How important is to have the PSID start on a nibble boundary? There are already a lot of bit manipulations involved, I don't see it hard to implement in a non-nibble boundary. Thanks Senthil > >Tom Taylor >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires From despres.remi@laposte.net Wed Jan 30 08:15:27 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 779BC21F88C7 for ; Wed, 30 Jan 2013 08:15:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BXW9ahtcqBjJ for ; Wed, 30 Jan 2013 08:15:26 -0800 (PST) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.4]) by ietfa.amsl.com (Postfix) with ESMTP id 4C20D21F8444 for ; Wed, 30 Jan 2013 08:15:25 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2101.sfr.fr (SMTP Server) with ESMTP id 2EC187000215; Wed, 30 Jan 2013 17:15:24 +0100 (CET) Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2101.sfr.fr (SMTP Server) with ESMTP id 9EA0C7000212; Wed, 30 Jan 2013 17:15:23 +0100 (CET) X-SFR-UUID: 20130130161523649.9EA0C7000212@msfrf2101.sfr.fr Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 30 Jan 2013 17:15:23 +0100 Message-Id: References: To: Senthil Sivakumar X-Mailer: Apple Mail (2.1499) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Softwires Subject: Re: [Softwires] Limiting the length of the MAP endpoint IPv6 prefix X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 16:15:27 -0000 2013-01-28 17:36, Senthil Sivakumar (ssenthil) : ... >> Yet, operators have the constraint of RFC 4291 that "For all unicast >> addresses, except those that start with the binary value 000, = Interface >> IDs are required to be 64 bits long and to be constructed in Modified >> EUI-64 format". =20 >=20 > Honestly, I don=B9t know the rationale behind this. I wasn't present when this was written but can see that, at least, it = made IIDs of LAN interfaces to be unique if based on MAC addresses that = are assigned by LAN adapters by vendors in compliance with IEEE rules.=20= This is AFAIK used by default in major OSes.=20 >=20 >>=20 >> The draft says that: >> (a) The PSID is: >> +--+---+---+---+---+---+---+---+---+ >> |PL| 8 16 24 32 40 48 56 | >> +--+---+---+---+---+---+---+---+---+ >> |64| u | IPv4 address | PSID | 0 | >> +--+---+---+---+---+---+---+---+---+ >=20 > I believe this figure is misleading by placing the IPv4 address in a = fixed > location. Figure 3 and Figure 7 > In the draft shows that the IID is not in a fixed location. Also, the = text > surrounding the above figure 8, says > "The Interface identifier format of a MAP node is based on the format > specified in section 2.2 of [RFC6052], with the added PSID field if > present, as shown in figure Figure 8." >=20 >=20 > But RFC 6052 doesn=B9t have the IPv4 address in a fixed location as = per > section 2.2. So I think this figure is misleading. >=20 >=20 >=20 >=20 > | n bits | o bits | s bits | 128-n-o-s bits | > +--------------------+-----------+---------+------------+----------+ > | Rule IPv6 prefix | EA bits |subnet ID| interface ID | > +--------------------+-----------+---------+-----------------------+ >=20 >=20 >> (b) "If the End-user IPv6 prefix length is larger than 64, the most >> significant parts of the interface identifier is overwritten by the >> prefix." >>=20 >> This is particularly unclear: >=20 > True. >> - What happens to the u octet? >=20 > I guess that needs to be made clear in the draft. We struggled with = that > in our implementation. >=20 >=20 >> - And to the IPv4 address if the prefix is longer than /68? >> - ... >>=20 >> Of course, if a use case is provided where MAP-E would be actually = used >> with an IID shorter than 64 bits, it should be discussed. But: >> - There is no such use case so far. >> - Looking for one doesn't seem useful. >=20 > I would like to see the IPv4 address be present from bits 96-127, no = need > for the PSID to be repeated again. That would allow us to go upto /96 = and > being consistent with RFC 6052 which allows one to configure a prefix = of > upto /96. Even simpler: don't repeat IPv4 addresses anywhere in IIDs. - IPv4 are already available in encapsulated IPv4 headers, at fixed = places - With IPv4 addresses in IIDs, different treatments and interpretations = are needed for CEs that are assigned IPv4 prefixes shorter than /32: . Zero padding up to 32 bits . No way in the IID itself to determine that the IPv4 address field = contains a source or destination prefix as opposed to the source or = destination IPv4 address. Regards, RD >=20 > Thanks > Senthil >=20 >>=20 >>=20 >> Regards, >> RD >>=20 >>=20 >>>=20 >>> On 1/28/13 8:59 AM, "Ole Troan" wrote: >>>=20 >>>>>>>=20 >>>>>>> The examples in my previous note sort of provided backing for my >>>>>>> view >>>>>>> that the MAP endpoint IPv6 prefix can be limited to a maximum of = a >>>>>>> /64, thus making the IID fully conformant both to RFC 4291 and = to >>>>>>> RFC >>>>>>> 6052. >>>>>>>=20 >>>>> ... >>>>>=20 >>>>>>>=20 >>>>>>> I think limiting the prefix length to 64 bits is reasonable. >>>>>>> Comments? >>>>>>=20 >>>>>> I don't think that's reasonable. >>>>>> and I don't see what it buys us, given that supporting prefix = lengths >>>>>> longer than 64 is simple. >>>>>> IPv6 isn't classfull, there isn't anything magic with the 64 >>>>>> boundary. >>>>>> ;-) >>>>>>=20 >>>>>> cheers, >>>>>> Ole >>>>>>=20 >>>>>=20 >>>>> OK, then I agree with R=E9mi. Drop mention of prefixes greater = than 64 >>>>> bits long and leave it to the reader to judge whether RFC 4291 >>>>> imposes a >>>>> limit. >>>>=20 >>>> you want this removed: >>>> If the End-user IPv6 prefix length is larger than 64, the = most >>>> significant parts of the interface identifier is overwritten by = the >>>> prefix. >>>>=20 >>>> I disagree. this is the only text in there suggesting to an = implementor >>>> that prefix lengths can be any value between 0-128. >>>>=20 >>>> Tom, Remi and I have stated our opinions. does anyone else have a = view >>>> on >>>> the matter? >>>>=20 >>>> cheers, >>>> Ole >>>> _______________________________________________ >>>> Softwires mailing list >>>> Softwires@ietf.org >>>> https://www.ietf.org/mailman/listinfo/softwires >>>=20 >>> _______________________________________________ >>> Softwires mailing list >>> Softwires@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >=20 From despres.remi@laposte.net Wed Jan 30 08:47:18 2013 Return-Path: X-Original-To: softwires@ietfa.amsl.com Delivered-To: softwires@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F196021F8467 for ; Wed, 30 Jan 2013 08:47:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.859 X-Spam-Level: X-Spam-Status: No, score=-1.859 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fCitAx6JSVsH for ; Wed, 30 Jan 2013 08:47:17 -0800 (PST) Received: from smtp25.services.sfr.fr (smtp25.services.sfr.fr [93.17.128.120]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF0221F843F for ; Wed, 30 Jan 2013 08:47:15 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2512.sfr.fr (SMTP Server) with ESMTP id 039BE70000A6; Wed, 30 Jan 2013 17:47:13 +0100 (CET) Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2512.sfr.fr (SMTP Server) with ESMTP id AF71D7000089; Wed, 30 Jan 2013 17:47:12 +0100 (CET) X-SFR-UUID: 20130130164712718.AF71D7000089@msfrf2512.sfr.fr Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: =?iso-8859-1?q?R=E9mi_Despr=E9s?= In-Reply-To: <510941A5.7090108@gmail.com> Date: Wed, 30 Jan 2013 17:47:12 +0100 Message-Id: <87FB8635-1894-4689-BADE-40EAEEAF0CB3@laposte.net> References: <5106AE69.80705@gmail.com> <51086E17.10603@gmail.com> <510914DC.3090507@gmail.com> <2BE59159-2F6D-4D6A-98F9-F0E7775322E9@cisco.com> <510941A5.7090108@gmail.com> To: Tom Taylor X-Mailer: Apple Mail (2.1499) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Softwires WG , Ole Troan Subject: Re: [Softwires] Section 5.1 of the MAP draft X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 16:47:18 -0000 2013-01-30 16:52, Tom Taylor : > On 30/01/2013 9:56 AM, R=E9mi Despr=E9s wrote: >>=20 >> Le 2013-01-30 13:47, Ole Troan : >>=20 >>> Tom, >>>=20 >>> [...] >>>=20 >>>=20 > [Ole said:] >>> I'm fine with fixing a to 4. >>> if an end user needs well known ports, give her a full address. >>=20 > [R=E9mi said:] >> An alternative is possible that >> - permits ISPs that want it to assign well-known ports to some = privileged users without necessarily giving them full IPv4 addresses; >> - uses a trivially simple algorithm. >>=20 >> That which has been chosen for 4rd can be used for MAP-E as well. It = uses for this an option to be used if well-nown ports must be = assignable. >>=20 >> It is specified in two sentences, in = http://tools.ietf.org/html/draft-ietf-softwire-4rd-04#page-15, at the = end of the first paragraph. >> Its complete picture representation is in a part of Figure 5: >>=20 >> (by default) (If WKPs authorized) >> : : : : >> +---+----+---------+ +----+-------------+ >> Ports in |> 0|PSID|any value| OR |PSID| any value | >> the CE port set +---+----+---------+ +----+-------------+ >> : 4 : 12 : : 16 : >>=20 > ... >=20 > OK, this explains the bit about system ports in the text, when a =3D = 0. The one objection I see to that is again the matter of address = dependency -- the system ports are available only for the first few = PSIDs, the PSIDs appear as part of the MAP endpoint prefix, so the = prefix value becomes constrained. >=20 > Since devices requiring system ports are likely to be servers, the = full address solution makes sense on another level too. Agreed, it does make sense, and I believe that many ISPs may make this = choice. (I personally argued in this direction long ago.) But there has been a firm requirement in the WG that, even for shared = addresses, one of the CE could have the well-known ports.=20 The WKPs-authorized option has been added to 4rd to satisfy this = requirement.=20 I don't think this requirement has disappeared. A copy of this mail is addressed to Maoke who was involved in this = discussion. Regards, RD >=20 > Tom Taylor